Merge branch 'master' of ssh://master.kernel.org/pub/scm/linux/kernel/git/kaber/nf-2.6
This commit is contained in:
Patrick McHardy
Коммит
b32e3dc786
4
.mailmap
4
.mailmap
|
|
@ -20,6 +20,7 @@ Andreas Herrmann <aherrman@de.ibm.com>
|
|||
Andrew Morton <akpm@osdl.org>
|
||||
Andrew Vasquez <andrew.vasquez@qlogic.com>
|
||||
Andy Adamson <andros@citi.umich.edu>
|
||||
Archit Taneja <archit@ti.com>
|
||||
Arnaud Patard <arnaud.patard@rtp-net.org>
|
||||
Arnd Bergmann <arnd@arndb.de>
|
||||
Axel Dyks <xl@xlsigned.net>
|
||||
|
|
@ -70,6 +71,7 @@ Leonid I Ananiev <leonid.i.ananiev@intel.com>
|
|||
Linas Vepstas <linas@austin.ibm.com>
|
||||
Mark Brown <broonie@sirena.org.uk>
|
||||
Matthieu CASTET <castet.matthieu@free.fr>
|
||||
Mayuresh Janorkar <mayur@ti.com>
|
||||
Michael Buesch <mb@bu3sch.de>
|
||||
Michael Buesch <mbuesch@freenet.de>
|
||||
Michel Dänzer <michel@tungstengraphics.com>
|
||||
|
|
@ -78,6 +80,7 @@ Morten Welinder <terra@gnome.org>
|
|||
Morten Welinder <welinder@anemone.rentec.com>
|
||||
Morten Welinder <welinder@darter.rentec.com>
|
||||
Morten Welinder <welinder@troll.com>
|
||||
Mythri P K <mythripk@ti.com>
|
||||
Nguyen Anh Quynh <aquynh@gmail.com>
|
||||
Paolo 'Blaisorblade' Giarrusso <blaisorblade@yahoo.it>
|
||||
Patrick Mochel <mochel@digitalimplant.org>
|
||||
|
|
@ -98,6 +101,7 @@ S.Çağlar Onur <caglar@pardus.org.tr>
|
|||
Simon Kelley <simon@thekelleys.org.uk>
|
||||
Stéphane Witzmann <stephane.witzmann@ubpmes.univ-bpclermont.fr>
|
||||
Stephen Hemminger <shemminger@osdl.org>
|
||||
Sumit Semwal <sumit.semwal@ti.com>
|
||||
Tejun Heo <htejun@gmail.com>
|
||||
Thomas Graf <tgraf@suug.ch>
|
||||
Tony Luck <tony.luck@intel.com>
|
||||
|
|
|
|||
|
|
@ -34,3 +34,23 @@ Contact: Richard Purdie <rpurdie@rpsys.net>
|
|||
Description:
|
||||
Maximum brightness for <backlight>.
|
||||
Users: HAL
|
||||
|
||||
What: /sys/class/backlight/<backlight>/type
|
||||
Date: September 2010
|
||||
KernelVersion: 2.6.37
|
||||
Contact: Matthew Garrett <mjg@redhat.com>
|
||||
Description:
|
||||
The type of interface controlled by <backlight>.
|
||||
"firmware": The driver uses a standard firmware interface
|
||||
"platform": The driver uses a platform-specific interface
|
||||
"raw": The driver controls hardware registers directly
|
||||
|
||||
In the general case, when multiple backlight
|
||||
interfaces are available for a single device, firmware
|
||||
control should be preferred to platform control should
|
||||
be preferred to raw control. Using a firmware
|
||||
interface reduces the probability of confusion with
|
||||
the hardware and the OS independently updating the
|
||||
backlight state. Platform interfaces are mostly a
|
||||
holdover from pre-standardisation of firmware
|
||||
interfaces.
|
||||
|
|
|
|||
|
|
@ -0,0 +1,31 @@
|
|||
What: /config/pcie-gadget
|
||||
Date: Feb 2011
|
||||
KernelVersion: 2.6.37
|
||||
Contact: Pratyush Anand <pratyush.anand@st.com>
|
||||
Description:
|
||||
|
||||
Interface is used to configure selected dual mode PCIe controller
|
||||
as device and then program its various registers to configure it
|
||||
as a particular device type.
|
||||
This interfaces can be used to show spear's PCIe device capability.
|
||||
|
||||
Nodes are only visible when configfs is mounted. To mount configfs
|
||||
in /config directory use:
|
||||
# mount -t configfs none /config/
|
||||
|
||||
For nth PCIe Device Controller
|
||||
/config/pcie-gadget.n/
|
||||
link ... used to enable ltssm and read its status.
|
||||
int_type ...used to configure and read type of supported
|
||||
interrupt
|
||||
no_of_msi ... used to configure number of MSI vector needed and
|
||||
to read no of MSI granted.
|
||||
inta ... write 1 to assert INTA and 0 to de-assert.
|
||||
send_msi ... write MSI vector to be sent.
|
||||
vendor_id ... used to write and read vendor id (hex)
|
||||
device_id ... used to write and read device id (hex)
|
||||
bar0_size ... used to write and read bar0_size
|
||||
bar0_address ... used to write and read bar0 mapped area in hex.
|
||||
bar0_rw_offset ... used to write and read offset of bar0 where
|
||||
bar0_data will be written or read.
|
||||
bar0_data ... used to write and read data at bar0_rw_offset.
|
||||
|
|
@ -1,6 +1,6 @@
|
|||
Where: /dev/pstore/...
|
||||
Date: January 2011
|
||||
Kernel Version: 2.6.38
|
||||
Date: March 2011
|
||||
Kernel Version: 2.6.39
|
||||
Contact: tony.luck@intel.com
|
||||
Description: Generic interface to platform dependent persistent storage.
|
||||
|
||||
|
|
@ -11,7 +11,7 @@ Description: Generic interface to platform dependent persistent storage.
|
|||
of the console log is captured, but other interesting
|
||||
data can also be saved.
|
||||
|
||||
# mount -t pstore - /dev/pstore
|
||||
# mount -t pstore -o kmsg_bytes=8000 - /dev/pstore
|
||||
|
||||
$ ls -l /dev/pstore
|
||||
total 0
|
||||
|
|
@ -33,3 +33,9 @@ Description: Generic interface to platform dependent persistent storage.
|
|||
will be saved elsewhere and erased from persistent store
|
||||
soon after boot to free up space ready for the next
|
||||
catastrophe.
|
||||
|
||||
The 'kmsg_bytes' mount option changes the target amount of
|
||||
data saved on each oops/panic. Pstore saves (possibly
|
||||
multiple) files based on the record size of the underlying
|
||||
persistent storage until at least this amount is reached.
|
||||
Default is 10 Kbytes.
|
||||
|
|
|
|||
|
|
@ -0,0 +1,6 @@
|
|||
What: /sys/bus/media/devices/.../model
|
||||
Date: January 2011
|
||||
Contact: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
||||
linux-media@vger.kernel.org
|
||||
Description: Contains the device model name in UTF-8. The device version is
|
||||
is not be appended to the model name.
|
||||
|
|
@ -59,3 +59,15 @@ Kernel Version: 2.6.31
|
|||
Contact: iss_storagedev@hp.com
|
||||
Description: Displays the usage count (number of opens) of logical drive Y
|
||||
of controller X.
|
||||
|
||||
Where: /sys/bus/pci/devices/<dev>/ccissX/resettable
|
||||
Date: February 2011
|
||||
Kernel Version: 2.6.38
|
||||
Contact: iss_storagedev@hp.com
|
||||
Description: Value of 1 indicates the controller can honor the reset_devices
|
||||
kernel parameter. Value of 0 indicates reset_devices cannot be
|
||||
honored. This is to allow, for example, kexec tools to be able
|
||||
to warn the user if they designate an unresettable device as
|
||||
a dump device, as kdump requires resetting the device in order
|
||||
to work reliably.
|
||||
|
||||
|
|
|
|||
|
|
@ -1,6 +1,6 @@
|
|||
What: /sys/bus/rbd/
|
||||
Date: November 2010
|
||||
Contact: Yehuda Sadeh <yehuda@hq.newdream.net>,
|
||||
Contact: Yehuda Sadeh <yehuda@newdream.net>,
|
||||
Sage Weil <sage@newdream.net>
|
||||
Description:
|
||||
|
||||
|
|
|
|||
|
|
@ -0,0 +1,21 @@
|
|||
What: /sys/devices/.../mmc_host/mmcX/mmcX:XXXX/enhanced_area_offset
|
||||
Date: January 2011
|
||||
Contact: Chuanxiao Dong <chuanxiao.dong@intel.com>
|
||||
Description:
|
||||
Enhanced area is a new feature defined in eMMC4.4 standard.
|
||||
eMMC4.4 or later card can support such feature. This kind of
|
||||
area can help to improve the card performance. If the feature
|
||||
is enabled, this attribute will indicate the start address of
|
||||
enhanced data area. If not, this attribute will be -EINVAL.
|
||||
Unit Byte. Format decimal.
|
||||
|
||||
What: /sys/devices/.../mmc_host/mmcX/mmcX:XXXX/enhanced_area_size
|
||||
Date: January 2011
|
||||
Contact: Chuanxiao Dong <chuanxiao.dong@intel.com>
|
||||
Description:
|
||||
Enhanced area is a new feature defined in eMMC4.4 standard.
|
||||
eMMC4.4 or later card can support such feature. This kind of
|
||||
area can help to improve the card performance. If the feature
|
||||
is enabled, this attribute will indicate the size of enhanced
|
||||
data area. If not, this attribute will be -EINVAL.
|
||||
Unit KByte. Format decimal.
|
||||
|
|
@ -0,0 +1,19 @@
|
|||
What: /sys/devices/platform/samsung/performance_level
|
||||
Date: January 1, 2010
|
||||
KernelVersion: 2.6.33
|
||||
Contact: Greg Kroah-Hartman <gregkh@suse.de>
|
||||
Description: Some Samsung laptops have different "performance levels"
|
||||
that are can be modified by a function key, and by this
|
||||
sysfs file. These values don't always make a whole lot
|
||||
of sense, but some users like to modify them to keep
|
||||
their fans quiet at all costs. Reading from this file
|
||||
will show the current performance level. Writing to the
|
||||
file can change this value.
|
||||
Valid options:
|
||||
"silent"
|
||||
"normal"
|
||||
"overclock"
|
||||
Note that not all laptops support all of these options.
|
||||
Specifically, not all support the "overclock" option,
|
||||
and it's still unknown if this value even changes
|
||||
anything, other than making the user feel a bit better.
|
||||
|
|
@ -48,7 +48,7 @@ Description:
|
|||
will have its blocks allocated out of its own unique
|
||||
preallocation pool.
|
||||
|
||||
What: /sys/fs/ext4/<disk>/inode_readahead
|
||||
What: /sys/fs/ext4/<disk>/inode_readahead_blks
|
||||
Date: March 2008
|
||||
Contact: "Theodore Ts'o" <tytso@mit.edu>
|
||||
Description:
|
||||
|
|
@ -85,7 +85,14 @@ Date: June 2008
|
|||
Contact: "Theodore Ts'o" <tytso@mit.edu>
|
||||
Description:
|
||||
Tuning parameter which (if non-zero) controls the goal
|
||||
inode used by the inode allocator in p0reference to
|
||||
all other allocation hueristics. This is intended for
|
||||
inode used by the inode allocator in preference to
|
||||
all other allocation heuristics. This is intended for
|
||||
debugging use only, and should be 0 on production
|
||||
systems.
|
||||
|
||||
What: /sys/fs/ext4/<disk>/max_writeback_mb_bump
|
||||
Date: September 2009
|
||||
Contact: "Theodore Ts'o" <tytso@mit.edu>
|
||||
Description:
|
||||
The maximum number of megabytes the writeback code will
|
||||
try to write out before move on to another inode.
|
||||
|
|
|
|||
|
|
@ -1,7 +0,0 @@
|
|||
What: /sys/fs/pstore/kmsg_bytes
|
||||
Date: January 2011
|
||||
Kernel Version: 2.6.38
|
||||
Contact: "Tony Luck" <tony.luck@intel.com>
|
||||
Description:
|
||||
Controls amount of console log that will be saved
|
||||
to persistent store on oops/panic.
|
||||
|
|
@ -0,0 +1,31 @@
|
|||
What: /sys/devices/platform/<platform>/cpufv
|
||||
Date: Oct 2010
|
||||
KernelVersion: 2.6.37
|
||||
Contact: "Corentin Chary" <corentincj@iksaif.net>
|
||||
Description:
|
||||
Change CPU clock configuration (write-only).
|
||||
There are three available clock configuration:
|
||||
* 0 -> Super Performance Mode
|
||||
* 1 -> High Performance Mode
|
||||
* 2 -> Power Saving Mode
|
||||
|
||||
What: /sys/devices/platform/<platform>/camera
|
||||
Date: Jan 2010
|
||||
KernelVersion: 2.6.39
|
||||
Contact: "Corentin Chary" <corentincj@iksaif.net>
|
||||
Description:
|
||||
Control the camera. 1 means on, 0 means off.
|
||||
|
||||
What: /sys/devices/platform/<platform>/cardr
|
||||
Date: Jan 2010
|
||||
KernelVersion: 2.6.39
|
||||
Contact: "Corentin Chary" <corentincj@iksaif.net>
|
||||
Description:
|
||||
Control the card reader. 1 means on, 0 means off.
|
||||
|
||||
What: /sys/devices/platform/<platform>/touchpad
|
||||
Date: Jan 2010
|
||||
KernelVersion: 2.6.39
|
||||
Contact: "Corentin Chary" <corentincj@iksaif.net>
|
||||
Description:
|
||||
Control the card touchpad. 1 means on, 0 means off.
|
||||
|
|
@ -1,10 +0,0 @@
|
|||
What: /sys/devices/platform/eeepc-wmi/cpufv
|
||||
Date: Oct 2010
|
||||
KernelVersion: 2.6.37
|
||||
Contact: "Corentin Chary" <corentincj@iksaif.net>
|
||||
Description:
|
||||
Change CPU clock configuration (write-only).
|
||||
There are three available clock configuration:
|
||||
* 0 -> Super Performance Mode
|
||||
* 1 -> High Performance Mode
|
||||
* 2 -> Power Saving Mode
|
||||
|
|
@ -35,7 +35,7 @@ o util-linux 2.10o # fdformat --version
|
|||
o module-init-tools 0.9.10 # depmod -V
|
||||
o e2fsprogs 1.41.4 # e2fsck -V
|
||||
o jfsutils 1.1.3 # fsck.jfs -V
|
||||
o reiserfsprogs 3.6.3 # reiserfsck -V 2>&1|grep reiserfsprogs
|
||||
o reiserfsprogs 3.6.3 # reiserfsck -V
|
||||
o xfsprogs 2.6.0 # xfs_db -V
|
||||
o squashfs-tools 4.0 # mksquashfs -version
|
||||
o btrfs-progs 0.18 # btrfsck
|
||||
|
|
@ -46,9 +46,9 @@ o isdn4k-utils 3.1pre1 # isdnctrl 2>&1|grep version
|
|||
o nfs-utils 1.0.5 # showmount --version
|
||||
o procps 3.2.0 # ps --version
|
||||
o oprofile 0.9 # oprofiled --version
|
||||
o udev 081 # udevinfo -V
|
||||
o grub 0.93 # grub --version
|
||||
o mcelog 0.6
|
||||
o udev 081 # udevd --version
|
||||
o grub 0.93 # grub --version || grub-install --version
|
||||
o mcelog 0.6 # mcelog --version
|
||||
o iptables 1.4.2 # iptables -V
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -168,6 +168,13 @@ Do not unnecessarily use braces where a single statement will do.
|
|||
if (condition)
|
||||
action();
|
||||
|
||||
and
|
||||
|
||||
if (condition)
|
||||
do_this();
|
||||
else
|
||||
do_that();
|
||||
|
||||
This does not apply if one branch of a conditional statement is a single
|
||||
statement. Use braces in both branches.
|
||||
|
||||
|
|
|
|||
|
|
@ -53,7 +53,9 @@ MAN := $(patsubst %.xml, %.9, $(BOOKS))
|
|||
mandocs: $(MAN)
|
||||
|
||||
build_images = mkdir -p $(objtree)/Documentation/DocBook/media/ && \
|
||||
cp $(srctree)/Documentation/DocBook/dvb/*.png $(srctree)/Documentation/DocBook/v4l/*.gif $(objtree)/Documentation/DocBook/media/
|
||||
cp $(srctree)/Documentation/DocBook/dvb/*.png \
|
||||
$(srctree)/Documentation/DocBook/v4l/*.gif \
|
||||
$(objtree)/Documentation/DocBook/media/
|
||||
|
||||
xmldoclinks:
|
||||
ifneq ($(objtree),$(srctree))
|
||||
|
|
|
|||
|
|
@ -11,6 +11,10 @@
|
|||
<!ENTITY func-select "<link linkend='func-select'><function>select()</function></link>">
|
||||
<!ENTITY func-write "<link linkend='func-write'><function>write()</function></link>">
|
||||
|
||||
<!ENTITY media-func-close "<link linkend='media-func-close'><function>close()</function></link>">
|
||||
<!ENTITY media-func-ioctl "<link linkend='media-func-ioctl'><function>ioctl()</function></link>">
|
||||
<!ENTITY media-func-open "<link linkend='media-func-open'><function>open()</function></link>">
|
||||
|
||||
<!-- Ioctls -->
|
||||
<!ENTITY VIDIOC-CROPCAP "<link linkend='vidioc-cropcap'><constant>VIDIOC_CROPCAP</constant></link>">
|
||||
<!ENTITY VIDIOC-DBG-G-CHIP-IDENT "<link linkend='vidioc-dbg-g-chip-ident'><constant>VIDIOC_DBG_G_CHIP_IDENT</constant></link>">
|
||||
|
|
@ -82,11 +86,24 @@
|
|||
<!ENTITY VIDIOC-S-PRIORITY "<link linkend='vidioc-g-priority'><constant>VIDIOC_S_PRIORITY</constant></link>">
|
||||
<!ENTITY VIDIOC-S-STD "<link linkend='vidioc-g-std'><constant>VIDIOC_S_STD</constant></link>">
|
||||
<!ENTITY VIDIOC-S-TUNER "<link linkend='vidioc-g-tuner'><constant>VIDIOC_S_TUNER</constant></link>">
|
||||
<!ENTITY VIDIOC-SUBDEV-ENUM-FRAME-SIZE "<link linkend='vidioc-subdev-enum-frame-size'><constant>VIDIOC_SUBDEV_ENUM_FRAME_SIZE</constant></link>">
|
||||
<!ENTITY VIDIOC-SUBDEV-ENUM-MBUS-CODE "<link linkend='vidioc-subdev-enum-mbus-code'><constant>VIDIOC_SUBDEV_ENUM_MBUS_CODE</constant></link>">
|
||||
<!ENTITY VIDIOC-SUBDEV-G-CROP "<link linkend='vidioc-subdev-g-crop'><constant>VIDIOC_SUBDEV_G_CROP</constant></link>">
|
||||
<!ENTITY VIDIOC-SUBDEV-G-FMT "<link linkend='vidioc-subdev-g-fmt'><constant>VIDIOC_SUBDEV_G_FMT</constant></link>">
|
||||
<!ENTITY VIDIOC-SUBDEV-G-FRAME-INTERVAL "<link linkend='vidioc-subdev-g-frame-interval'><constant>VIDIOC_SUBDEV_G_FRAME_INTERVAL</constant></link>">
|
||||
<!ENTITY VIDIOC-SUBDEV-S-CROP "<link linkend='vidioc-subdev-g-crop'><constant>VIDIOC_SUBDEV_S_CROP</constant></link>">
|
||||
<!ENTITY VIDIOC-SUBDEV-S-FMT "<link linkend='vidioc-subdev-g-fmt'><constant>VIDIOC_SUBDEV_S_FMT</constant></link>">
|
||||
<!ENTITY VIDIOC-SUBDEV-S-FRAME-INTERVAL "<link linkend='vidioc-subdev-g-frame-interval'><constant>VIDIOC_SUBDEV_S_FRAME_INTERVAL</constant></link>">
|
||||
<!ENTITY VIDIOC-TRY-ENCODER-CMD "<link linkend='vidioc-encoder-cmd'><constant>VIDIOC_TRY_ENCODER_CMD</constant></link>">
|
||||
<!ENTITY VIDIOC-TRY-EXT-CTRLS "<link linkend='vidioc-g-ext-ctrls'><constant>VIDIOC_TRY_EXT_CTRLS</constant></link>">
|
||||
<!ENTITY VIDIOC-TRY-FMT "<link linkend='vidioc-g-fmt'><constant>VIDIOC_TRY_FMT</constant></link>">
|
||||
<!ENTITY VIDIOC-UNSUBSCRIBE-EVENT "<link linkend='vidioc-subscribe-event'><constant>VIDIOC_UNSUBSCRIBE_EVENT</constant></link>">
|
||||
|
||||
<!ENTITY MEDIA-IOC-DEVICE-INFO "<link linkend='media-ioc-device-info'><constant>MEDIA_IOC_DEVICE_INFO</constant></link>">
|
||||
<!ENTITY MEDIA-IOC-ENUM-ENTITIES "<link linkend='media-ioc-enum-entities'><constant>MEDIA_IOC_ENUM_ENTITIES</constant></link>">
|
||||
<!ENTITY MEDIA-IOC-ENUM-LINKS "<link linkend='media-ioc-enum-links'><constant>MEDIA_IOC_ENUM_LINKS</constant></link>">
|
||||
<!ENTITY MEDIA-IOC-SETUP-LINK "<link linkend='media-ioc-setup-link'><constant>MEDIA_IOC_SETUP_LINK</constant></link>">
|
||||
|
||||
<!-- Types -->
|
||||
<!ENTITY v4l2-std-id "<link linkend='v4l2-std-id'>v4l2_std_id</link>">
|
||||
|
||||
|
|
@ -98,6 +115,7 @@
|
|||
<!ENTITY v4l2-field "enum <link linkend='v4l2-field'>v4l2_field</link>">
|
||||
<!ENTITY v4l2-frmivaltypes "enum <link linkend='v4l2-frmivaltypes'>v4l2_frmivaltypes</link>">
|
||||
<!ENTITY v4l2-frmsizetypes "enum <link linkend='v4l2-frmsizetypes'>v4l2_frmsizetypes</link>">
|
||||
<!ENTITY v4l2-mbus-pixelcode "enum <link linkend='v4l2-mbus-pixelcode'>v4l2_mbus_pixelcode</link>">
|
||||
<!ENTITY v4l2-memory "enum <link linkend='v4l2-memory'>v4l2_memory</link>">
|
||||
<!ENTITY v4l2-mpeg-audio-ac3-bitrate "enum <link linkend='v4l2-mpeg-audio-ac3-bitrate'>v4l2_mpeg_audio_ac3_bitrate</link>">
|
||||
<!ENTITY v4l2-mpeg-audio-crc "enum <link linkend='v4l2-mpeg-audio-crc'>v4l2_mpeg_audio_crc</link>">
|
||||
|
|
@ -121,6 +139,7 @@
|
|||
<!ENTITY v4l2-mpeg-video-encoding "enum <link linkend='v4l2-mpeg-video-encoding'>v4l2_mpeg_video_encoding</link>">
|
||||
<!ENTITY v4l2-power-line-frequency "enum <link linkend='v4l2-power-line-frequency'>v4l2_power_line_frequency</link>">
|
||||
<!ENTITY v4l2-priority "enum <link linkend='v4l2-priority'>v4l2_priority</link>">
|
||||
<!ENTITY v4l2-subdev-format-whence "enum <link linkend='v4l2-subdev-format-whence'>v4l2_subdev_format_whence</link>">
|
||||
<!ENTITY v4l2-tuner-type "enum <link linkend='v4l2-tuner-type'>v4l2_tuner_type</link>">
|
||||
<!ENTITY v4l2-preemphasis "enum <link linkend='v4l2-preemphasis'>v4l2_preemphasis</link>">
|
||||
|
||||
|
|
@ -129,6 +148,7 @@
|
|||
<!ENTITY v4l2-audioout "struct <link linkend='v4l2-audioout'>v4l2_audioout</link>">
|
||||
<!ENTITY v4l2-bt-timings "struct <link linkend='v4l2-bt-timings'>v4l2_bt_timings</link>">
|
||||
<!ENTITY v4l2-buffer "struct <link linkend='v4l2-buffer'>v4l2_buffer</link>">
|
||||
<!ENTITY v4l2-plane "struct <link linkend='v4l2-plane'>v4l2_plane</link>">
|
||||
<!ENTITY v4l2-capability "struct <link linkend='v4l2-capability'>v4l2_capability</link>">
|
||||
<!ENTITY v4l2-captureparm "struct <link linkend='v4l2-captureparm'>v4l2_captureparm</link>">
|
||||
<!ENTITY v4l2-clip "struct <link linkend='v4l2-clip'>v4l2_clip</link>">
|
||||
|
|
@ -162,11 +182,14 @@
|
|||
<!ENTITY v4l2-hw-freq-seek "struct <link linkend='v4l2-hw-freq-seek'>v4l2_hw_freq_seek</link>">
|
||||
<!ENTITY v4l2-input "struct <link linkend='v4l2-input'>v4l2_input</link>">
|
||||
<!ENTITY v4l2-jpegcompression "struct <link linkend='v4l2-jpegcompression'>v4l2_jpegcompression</link>">
|
||||
<!ENTITY v4l2-mbus-framefmt "struct <link linkend='v4l2-mbus-framefmt'>v4l2_mbus_framefmt</link>">
|
||||
<!ENTITY v4l2-modulator "struct <link linkend='v4l2-modulator'>v4l2_modulator</link>">
|
||||
<!ENTITY v4l2-mpeg-vbi-fmt-ivtv "struct <link linkend='v4l2-mpeg-vbi-fmt-ivtv'>v4l2_mpeg_vbi_fmt_ivtv</link>">
|
||||
<!ENTITY v4l2-output "struct <link linkend='v4l2-output'>v4l2_output</link>">
|
||||
<!ENTITY v4l2-outputparm "struct <link linkend='v4l2-outputparm'>v4l2_outputparm</link>">
|
||||
<!ENTITY v4l2-pix-format "struct <link linkend='v4l2-pix-format'>v4l2_pix_format</link>">
|
||||
<!ENTITY v4l2-pix-format-mplane "struct <link linkend='v4l2-pix-format-mplane'>v4l2_pix_format_mplane</link>">
|
||||
<!ENTITY v4l2-plane-pix-format "struct <link linkend='v4l2-plane-pix-format'>v4l2_plane_pix_format</link>">
|
||||
<!ENTITY v4l2-queryctrl "struct <link linkend='v4l2-queryctrl'>v4l2_queryctrl</link>">
|
||||
<!ENTITY v4l2-querymenu "struct <link linkend='v4l2-querymenu'>v4l2_querymenu</link>">
|
||||
<!ENTITY v4l2-rect "struct <link linkend='v4l2-rect'>v4l2_rect</link>">
|
||||
|
|
@ -174,6 +197,12 @@
|
|||
<!ENTITY v4l2-sliced-vbi-cap "struct <link linkend='v4l2-sliced-vbi-cap'>v4l2_sliced_vbi_cap</link>">
|
||||
<!ENTITY v4l2-sliced-vbi-data "struct <link linkend='v4l2-sliced-vbi-data'>v4l2_sliced_vbi_data</link>">
|
||||
<!ENTITY v4l2-sliced-vbi-format "struct <link linkend='v4l2-sliced-vbi-format'>v4l2_sliced_vbi_format</link>">
|
||||
<!ENTITY v4l2-subdev-frame-interval "struct <link linkend='v4l2-subdev-frame-interval'>v4l2_subdev_frame_interval</link>">
|
||||
<!ENTITY v4l2-subdev-frame-interval-enum "struct <link linkend='v4l2-subdev-frame-interval-enum'>v4l2_subdev_frame_interval_enum</link>">
|
||||
<!ENTITY v4l2-subdev-frame-size-enum "struct <link linkend='v4l2-subdev-frame-size-enum'>v4l2_subdev_frame_size_enum</link>">
|
||||
<!ENTITY v4l2-subdev-crop "struct <link linkend='v4l2-subdev-crop'>v4l2_subdev_crop</link>">
|
||||
<!ENTITY v4l2-subdev-format "struct <link linkend='v4l2-subdev-format'>v4l2_subdev_format</link>">
|
||||
<!ENTITY v4l2-subdev-mbus-code-enum "struct <link linkend='v4l2-subdev-mbus-code-enum'>v4l2_subdev_mbus_code_enum</link>">
|
||||
<!ENTITY v4l2-standard "struct <link linkend='v4l2-standard'>v4l2_standard</link>">
|
||||
<!ENTITY v4l2-streamparm "struct <link linkend='v4l2-streamparm'>v4l2_streamparm</link>">
|
||||
<!ENTITY v4l2-timecode "struct <link linkend='v4l2-timecode'>v4l2_timecode</link>">
|
||||
|
|
@ -181,6 +210,12 @@
|
|||
<!ENTITY v4l2-vbi-format "struct <link linkend='v4l2-vbi-format'>v4l2_vbi_format</link>">
|
||||
<!ENTITY v4l2-window "struct <link linkend='v4l2-window'>v4l2_window</link>">
|
||||
|
||||
<!ENTITY media-device-info "struct <link linkend='media-device-info'>media_device_info</link>">
|
||||
<!ENTITY media-entity-desc "struct <link linkend='media-entity-desc'>media_entity_desc</link>">
|
||||
<!ENTITY media-links-enum "struct <link linkend='media-links-enum'>media_links_enum</link>">
|
||||
<!ENTITY media-pad-desc "struct <link linkend='media-pad-desc'>media_pad_desc</link>">
|
||||
<!ENTITY media-link-desc "struct <link linkend='media-link-desc'>media_link_desc</link>">
|
||||
|
||||
<!-- Error Codes -->
|
||||
<!ENTITY EACCES "<errorcode>EACCES</errorcode> error code">
|
||||
<!ENTITY EAGAIN "<errorcode>EAGAIN</errorcode> error code">
|
||||
|
|
@ -197,11 +232,13 @@
|
|||
<!ENTITY ENXIO "<errorcode>ENXIO</errorcode> error code">
|
||||
<!ENTITY EMFILE "<errorcode>EMFILE</errorcode> error code">
|
||||
<!ENTITY EPERM "<errorcode>EPERM</errorcode> error code">
|
||||
<!ENTITY EPIPE "<errorcode>EPIPE</errorcode> error code">
|
||||
<!ENTITY ERANGE "<errorcode>ERANGE</errorcode> error code">
|
||||
|
||||
<!-- Subsections -->
|
||||
<!ENTITY sub-biblio SYSTEM "v4l/biblio.xml">
|
||||
<!ENTITY sub-common SYSTEM "v4l/common.xml">
|
||||
<!ENTITY sub-planar-apis SYSTEM "v4l/planar-apis.xml">
|
||||
<!ENTITY sub-compat SYSTEM "v4l/compat.xml">
|
||||
<!ENTITY sub-controls SYSTEM "v4l/controls.xml">
|
||||
<!ENTITY sub-dev-capture SYSTEM "v4l/dev-capture.xml">
|
||||
|
|
@ -215,6 +252,7 @@
|
|||
<!ENTITY sub-dev-raw-vbi SYSTEM "v4l/dev-raw-vbi.xml">
|
||||
<!ENTITY sub-dev-rds SYSTEM "v4l/dev-rds.xml">
|
||||
<!ENTITY sub-dev-sliced-vbi SYSTEM "v4l/dev-sliced-vbi.xml">
|
||||
<!ENTITY sub-dev-subdev SYSTEM "v4l/dev-subdev.xml">
|
||||
<!ENTITY sub-dev-teletext SYSTEM "v4l/dev-teletext.xml">
|
||||
<!ENTITY sub-driver SYSTEM "v4l/driver.xml">
|
||||
<!ENTITY sub-libv4l SYSTEM "v4l/libv4l.xml">
|
||||
|
|
@ -233,6 +271,8 @@
|
|||
<!ENTITY sub-io SYSTEM "v4l/io.xml">
|
||||
<!ENTITY sub-grey SYSTEM "v4l/pixfmt-grey.xml">
|
||||
<!ENTITY sub-nv12 SYSTEM "v4l/pixfmt-nv12.xml">
|
||||
<!ENTITY sub-nv12m SYSTEM "v4l/pixfmt-nv12m.xml">
|
||||
<!ENTITY sub-nv12mt SYSTEM "v4l/pixfmt-nv12mt.xml">
|
||||
<!ENTITY sub-nv16 SYSTEM "v4l/pixfmt-nv16.xml">
|
||||
<!ENTITY sub-packed-rgb SYSTEM "v4l/pixfmt-packed-rgb.xml">
|
||||
<!ENTITY sub-packed-yuv SYSTEM "v4l/pixfmt-packed-yuv.xml">
|
||||
|
|
@ -247,6 +287,7 @@
|
|||
<!ENTITY sub-yuv410 SYSTEM "v4l/pixfmt-yuv410.xml">
|
||||
<!ENTITY sub-yuv411p SYSTEM "v4l/pixfmt-yuv411p.xml">
|
||||
<!ENTITY sub-yuv420 SYSTEM "v4l/pixfmt-yuv420.xml">
|
||||
<!ENTITY sub-yuv420m SYSTEM "v4l/pixfmt-yuv420m.xml">
|
||||
<!ENTITY sub-yuv422p SYSTEM "v4l/pixfmt-yuv422p.xml">
|
||||
<!ENTITY sub-yuyv SYSTEM "v4l/pixfmt-yuyv.xml">
|
||||
<!ENTITY sub-yvyu SYSTEM "v4l/pixfmt-yvyu.xml">
|
||||
|
|
@ -298,6 +339,13 @@
|
|||
<!ENTITY sub-reqbufs SYSTEM "v4l/vidioc-reqbufs.xml">
|
||||
<!ENTITY sub-s-hw-freq-seek SYSTEM "v4l/vidioc-s-hw-freq-seek.xml">
|
||||
<!ENTITY sub-streamon SYSTEM "v4l/vidioc-streamon.xml">
|
||||
<!ENTITY sub-subdev-enum-frame-interval SYSTEM "v4l/vidioc-subdev-enum-frame-interval.xml">
|
||||
<!ENTITY sub-subdev-enum-frame-size SYSTEM "v4l/vidioc-subdev-enum-frame-size.xml">
|
||||
<!ENTITY sub-subdev-enum-mbus-code SYSTEM "v4l/vidioc-subdev-enum-mbus-code.xml">
|
||||
<!ENTITY sub-subdev-formats SYSTEM "v4l/subdev-formats.xml">
|
||||
<!ENTITY sub-subdev-g-crop SYSTEM "v4l/vidioc-subdev-g-crop.xml">
|
||||
<!ENTITY sub-subdev-g-fmt SYSTEM "v4l/vidioc-subdev-g-fmt.xml">
|
||||
<!ENTITY sub-subdev-g-frame-interval SYSTEM "v4l/vidioc-subdev-g-frame-interval.xml">
|
||||
<!ENTITY sub-capture-c SYSTEM "v4l/capture.c.xml">
|
||||
<!ENTITY sub-keytable-c SYSTEM "v4l/keytable.c.xml">
|
||||
<!ENTITY sub-v4l2grab-c SYSTEM "v4l/v4l2grab.c.xml">
|
||||
|
|
@ -321,6 +369,15 @@
|
|||
<!ENTITY sub-media-entities SYSTEM "media-entities.tmpl">
|
||||
<!ENTITY sub-media-indices SYSTEM "media-indices.tmpl">
|
||||
|
||||
<!ENTITY sub-media-controller SYSTEM "v4l/media-controller.xml">
|
||||
<!ENTITY sub-media-open SYSTEM "v4l/media-func-open.xml">
|
||||
<!ENTITY sub-media-close SYSTEM "v4l/media-func-close.xml">
|
||||
<!ENTITY sub-media-ioctl SYSTEM "v4l/media-func-ioctl.xml">
|
||||
<!ENTITY sub-media-ioc-device-info SYSTEM "v4l/media-ioc-device-info.xml">
|
||||
<!ENTITY sub-media-ioc-enum-entities SYSTEM "v4l/media-ioc-enum-entities.xml">
|
||||
<!ENTITY sub-media-ioc-enum-links SYSTEM "v4l/media-ioc-enum-links.xml">
|
||||
<!ENTITY sub-media-ioc-setup-link SYSTEM "v4l/media-ioc-setup-link.xml">
|
||||
|
||||
<!-- Function Reference -->
|
||||
<!ENTITY close SYSTEM "v4l/func-close.xml">
|
||||
<!ENTITY ioctl SYSTEM "v4l/func-ioctl.xml">
|
||||
|
|
@ -333,6 +390,7 @@
|
|||
<!ENTITY write SYSTEM "v4l/func-write.xml">
|
||||
<!ENTITY grey SYSTEM "v4l/pixfmt-grey.xml">
|
||||
<!ENTITY nv12 SYSTEM "v4l/pixfmt-nv12.xml">
|
||||
<!ENTITY nv12m SYSTEM "v4l/pixfmt-nv12m.xml">
|
||||
<!ENTITY nv16 SYSTEM "v4l/pixfmt-nv16.xml">
|
||||
<!ENTITY packed-rgb SYSTEM "v4l/pixfmt-packed-rgb.xml">
|
||||
<!ENTITY packed-yuv SYSTEM "v4l/pixfmt-packed-yuv.xml">
|
||||
|
|
@ -347,6 +405,7 @@
|
|||
<!ENTITY yuv410 SYSTEM "v4l/pixfmt-yuv410.xml">
|
||||
<!ENTITY yuv411p SYSTEM "v4l/pixfmt-yuv411p.xml">
|
||||
<!ENTITY yuv420 SYSTEM "v4l/pixfmt-yuv420.xml">
|
||||
<!ENTITY yuv420m SYSTEM "v4l/pixfmt-yuv420m.xml">
|
||||
<!ENTITY yuv422p SYSTEM "v4l/pixfmt-yuv422p.xml">
|
||||
<!ENTITY yuyv SYSTEM "v4l/pixfmt-yuyv.xml">
|
||||
<!ENTITY yvyu SYSTEM "v4l/pixfmt-yvyu.xml">
|
||||
|
|
|
|||
|
|
@ -106,6 +106,9 @@ Foundation. A copy of the license is included in the chapter entitled
|
|||
&sub-remote_controllers;
|
||||
</chapter>
|
||||
</part>
|
||||
<part id="media_common">
|
||||
&sub-media-controller;
|
||||
</part>
|
||||
|
||||
&sub-fdl-appendix;
|
||||
|
||||
|
|
|
|||
|
|
@ -133,7 +133,6 @@
|
|||
!Idrivers/rapidio/rio-sysfs.c
|
||||
</sect1>
|
||||
<sect1 id="PPC32_support"><title>PPC32 support</title>
|
||||
!Earch/powerpc/sysdev/fsl_rio.c
|
||||
!Iarch/powerpc/sysdev/fsl_rio.c
|
||||
</sect1>
|
||||
</chapter>
|
||||
|
|
|
|||
Двоичный файл не отображается.
Двоичный файл не отображается.
|
После Ширина: | Высота: | Размер: 9.5 KiB |
|
|
@ -846,6 +846,8 @@ conversion routine or library for integration into applications.</para>
|
|||
</section>
|
||||
</section>
|
||||
|
||||
&sub-planar-apis;
|
||||
|
||||
<section id="crop">
|
||||
<title>Image Cropping, Insertion and Scaling</title>
|
||||
|
||||
|
|
|
|||
|
|
@ -1711,8 +1711,8 @@ ioctl would enumerate the available audio inputs. An ioctl to
|
|||
determine the current audio input, if more than one combines with the
|
||||
current video input, did not exist. So
|
||||
<constant>VIDIOC_G_AUDIO</constant> was renamed to
|
||||
<constant>VIDIOC_G_AUDIO_OLD</constant>, this ioctl will be removed in
|
||||
the future. The &VIDIOC-ENUMAUDIO; ioctl was added to enumerate
|
||||
<constant>VIDIOC_G_AUDIO_OLD</constant>, this ioctl was removed on
|
||||
Kernel 2.6.39. The &VIDIOC-ENUMAUDIO; ioctl was added to enumerate
|
||||
audio inputs, while &VIDIOC-G-AUDIO; now reports the current audio
|
||||
input.</para>
|
||||
<para>The same changes were made to &VIDIOC-G-AUDOUT; and
|
||||
|
|
@ -1726,7 +1726,7 @@ must be updated to successfully compile again.</para>
|
|||
<para>The &VIDIOC-OVERLAY; ioctl was incorrectly defined with
|
||||
write-read parameter. It was changed to write-only, while the write-read
|
||||
version was renamed to <constant>VIDIOC_OVERLAY_OLD</constant>. The old
|
||||
ioctl will be removed in the future. Until further the "videodev"
|
||||
ioctl was removed on Kernel 2.6.39. Until further the "videodev"
|
||||
kernel module will automatically translate to the new version, so drivers
|
||||
must be recompiled, but not applications.</para>
|
||||
</listitem>
|
||||
|
|
@ -1744,7 +1744,7 @@ surface can be seen.</para>
|
|||
defined with write-only parameter, inconsistent with other ioctls
|
||||
modifying their argument. They were changed to write-read, while a
|
||||
<constant>_OLD</constant> suffix was added to the write-only versions.
|
||||
The old ioctls will be removed in the future. Drivers and
|
||||
The old ioctls were removed on Kernel 2.6.39. Drivers and
|
||||
applications assuming a constant parameter need an update.</para>
|
||||
</listitem>
|
||||
</orderedlist>
|
||||
|
|
@ -1815,8 +1815,8 @@ yet to be addressed, for details see <xref
|
|||
<para>The &VIDIOC-CROPCAP; ioctl was incorrectly defined
|
||||
with read-only parameter. It is now defined as write-read ioctl, while
|
||||
the read-only version was renamed to
|
||||
<constant>VIDIOC_CROPCAP_OLD</constant>. The old ioctl will be removed
|
||||
in the future.</para>
|
||||
<constant>VIDIOC_CROPCAP_OLD</constant>. The old ioctl was removed
|
||||
on Kernel 2.6.39.</para>
|
||||
</listitem>
|
||||
</orderedlist>
|
||||
</section>
|
||||
|
|
@ -2353,6 +2353,20 @@ that used it. It was originally scheduled for removal in 2.6.35.
|
|||
</listitem>
|
||||
</orderedlist>
|
||||
</section>
|
||||
<section>
|
||||
<title>V4L2 in Linux 2.6.39</title>
|
||||
<orderedlist>
|
||||
<listitem>
|
||||
<para>The old VIDIOC_*_OLD symbols and V4L1 support were removed.</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>Multi-planar API added. Does not affect the compatibility of
|
||||
current drivers and applications. See
|
||||
<link linkend="planar-apis">multi-planar API</link>
|
||||
for details.</para>
|
||||
</listitem>
|
||||
</orderedlist>
|
||||
</section>
|
||||
|
||||
<section id="other">
|
||||
<title>Relation of V4L2 to other Linux multimedia APIs</title>
|
||||
|
|
|
|||
|
|
@ -18,7 +18,8 @@ files are used for video output devices.</para>
|
|||
<title>Querying Capabilities</title>
|
||||
|
||||
<para>Devices supporting the video capture interface set the
|
||||
<constant>V4L2_CAP_VIDEO_CAPTURE</constant> flag in the
|
||||
<constant>V4L2_CAP_VIDEO_CAPTURE</constant> or
|
||||
<constant>V4L2_CAP_VIDEO_CAPTURE_MPLANE</constant> flag in the
|
||||
<structfield>capabilities</structfield> field of &v4l2-capability;
|
||||
returned by the &VIDIOC-QUERYCAP; ioctl. As secondary device functions
|
||||
they may also support the <link linkend="overlay">video overlay</link>
|
||||
|
|
@ -64,9 +65,11 @@ linkend="crop" />.</para>
|
|||
|
||||
<para>To query the current image format applications set the
|
||||
<structfield>type</structfield> field of a &v4l2-format; to
|
||||
<constant>V4L2_BUF_TYPE_VIDEO_CAPTURE</constant> and call the
|
||||
<constant>V4L2_BUF_TYPE_VIDEO_CAPTURE</constant> or
|
||||
<constant>V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE</constant> and call the
|
||||
&VIDIOC-G-FMT; ioctl with a pointer to this structure. Drivers fill
|
||||
the &v4l2-pix-format; <structfield>pix</structfield> member of the
|
||||
the &v4l2-pix-format; <structfield>pix</structfield> or the
|
||||
&v4l2-pix-format-mplane; <structfield>pix_mp</structfield> member of the
|
||||
<structfield>fmt</structfield> union.</para>
|
||||
|
||||
<para>To request different parameters applications set the
|
||||
|
|
@ -84,8 +87,8 @@ adjust the parameters and finally return the actual parameters as
|
|||
without disabling I/O or possibly time consuming hardware
|
||||
preparations.</para>
|
||||
|
||||
<para>The contents of &v4l2-pix-format; are discussed in <xref
|
||||
linkend="pixfmt" />. See also the specification of the
|
||||
<para>The contents of &v4l2-pix-format; and &v4l2-pix-format-mplane;
|
||||
are discussed in <xref linkend="pixfmt" />. See also the specification of the
|
||||
<constant>VIDIOC_G_FMT</constant>, <constant>VIDIOC_S_FMT</constant>
|
||||
and <constant>VIDIOC_TRY_FMT</constant> ioctls for details. Video
|
||||
capture devices must implement both the
|
||||
|
|
|
|||
|
|
@ -17,7 +17,8 @@ files are used for video capture devices.</para>
|
|||
<title>Querying Capabilities</title>
|
||||
|
||||
<para>Devices supporting the video output interface set the
|
||||
<constant>V4L2_CAP_VIDEO_OUTPUT</constant> flag in the
|
||||
<constant>V4L2_CAP_VIDEO_OUTPUT</constant> or
|
||||
<constant>V4L2_CAP_VIDEO_OUTPUT_MPLANE</constant> flag in the
|
||||
<structfield>capabilities</structfield> field of &v4l2-capability;
|
||||
returned by the &VIDIOC-QUERYCAP; ioctl. As secondary device functions
|
||||
they may also support the <link linkend="raw-vbi">raw VBI
|
||||
|
|
@ -60,9 +61,11 @@ linkend="crop" />.</para>
|
|||
|
||||
<para>To query the current image format applications set the
|
||||
<structfield>type</structfield> field of a &v4l2-format; to
|
||||
<constant>V4L2_BUF_TYPE_VIDEO_OUTPUT</constant> and call the
|
||||
<constant>V4L2_BUF_TYPE_VIDEO_OUTPUT</constant> or
|
||||
<constant>V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE</constant> and call the
|
||||
&VIDIOC-G-FMT; ioctl with a pointer to this structure. Drivers fill
|
||||
the &v4l2-pix-format; <structfield>pix</structfield> member of the
|
||||
the &v4l2-pix-format; <structfield>pix</structfield> or the
|
||||
&v4l2-pix-format-mplane; <structfield>pix_mp</structfield> member of the
|
||||
<structfield>fmt</structfield> union.</para>
|
||||
|
||||
<para>To request different parameters applications set the
|
||||
|
|
@ -80,8 +83,8 @@ adjust the parameters and finally return the actual parameters as
|
|||
without disabling I/O or possibly time consuming hardware
|
||||
preparations.</para>
|
||||
|
||||
<para>The contents of &v4l2-pix-format; are discussed in <xref
|
||||
linkend="pixfmt" />. See also the specification of the
|
||||
<para>The contents of &v4l2-pix-format; and &v4l2-pix-format-mplane;
|
||||
are discussed in <xref linkend="pixfmt" />. See also the specification of the
|
||||
<constant>VIDIOC_G_FMT</constant>, <constant>VIDIOC_S_FMT</constant>
|
||||
and <constant>VIDIOC_TRY_FMT</constant> ioctls for details. Video
|
||||
output devices must implement both the
|
||||
|
|
|
|||
|
|
@ -0,0 +1,313 @@
|
|||
<title>Sub-device Interface</title>
|
||||
|
||||
<note>
|
||||
<title>Experimental</title>
|
||||
<para>This is an <link linkend="experimental">experimental</link>
|
||||
interface and may change in the future.</para>
|
||||
</note>
|
||||
|
||||
<para>The complex nature of V4L2 devices, where hardware is often made of
|
||||
several integrated circuits that need to interact with each other in a
|
||||
controlled way, leads to complex V4L2 drivers. The drivers usually reflect
|
||||
the hardware model in software, and model the different hardware components
|
||||
as software blocks called sub-devices.</para>
|
||||
|
||||
<para>V4L2 sub-devices are usually kernel-only objects. If the V4L2 driver
|
||||
implements the media device API, they will automatically inherit from media
|
||||
entities. Applications will be able to enumerate the sub-devices and discover
|
||||
the hardware topology using the media entities, pads and links enumeration
|
||||
API.</para>
|
||||
|
||||
<para>In addition to make sub-devices discoverable, drivers can also choose
|
||||
to make them directly configurable by applications. When both the sub-device
|
||||
driver and the V4L2 device driver support this, sub-devices will feature a
|
||||
character device node on which ioctls can be called to
|
||||
<itemizedlist>
|
||||
<listitem><para>query, read and write sub-devices controls</para></listitem>
|
||||
<listitem><para>subscribe and unsubscribe to events and retrieve them</para></listitem>
|
||||
<listitem><para>negotiate image formats on individual pads</para></listitem>
|
||||
</itemizedlist>
|
||||
</para>
|
||||
|
||||
<para>Sub-device character device nodes, conventionally named
|
||||
<filename>/dev/v4l-subdev*</filename>, use major number 81.</para>
|
||||
|
||||
<section>
|
||||
<title>Controls</title>
|
||||
<para>Most V4L2 controls are implemented by sub-device hardware. Drivers
|
||||
usually merge all controls and expose them through video device nodes.
|
||||
Applications can control all sub-devices through a single interface.</para>
|
||||
|
||||
<para>Complex devices sometimes implement the same control in different
|
||||
pieces of hardware. This situation is common in embedded platforms, where
|
||||
both sensors and image processing hardware implement identical functions,
|
||||
such as contrast adjustment, white balance or faulty pixels correction. As
|
||||
the V4L2 controls API doesn't support several identical controls in a single
|
||||
device, all but one of the identical controls are hidden.</para>
|
||||
|
||||
<para>Applications can access those hidden controls through the sub-device
|
||||
node with the V4L2 control API described in <xref linkend="control" />. The
|
||||
ioctls behave identically as when issued on V4L2 device nodes, with the
|
||||
exception that they deal only with controls implemented in the sub-device.
|
||||
</para>
|
||||
|
||||
<para>Depending on the driver, those controls might also be exposed through
|
||||
one (or several) V4L2 device nodes.</para>
|
||||
</section>
|
||||
|
||||
<section>
|
||||
<title>Events</title>
|
||||
<para>V4L2 sub-devices can notify applications of events as described in
|
||||
<xref linkend="event" />. The API behaves identically as when used on V4L2
|
||||
device nodes, with the exception that it only deals with events generated by
|
||||
the sub-device. Depending on the driver, those events might also be reported
|
||||
on one (or several) V4L2 device nodes.</para>
|
||||
</section>
|
||||
|
||||
<section id="pad-level-formats">
|
||||
<title>Pad-level Formats</title>
|
||||
|
||||
<warning><para>Pad-level formats are only applicable to very complex device that
|
||||
need to expose low-level format configuration to user space. Generic V4L2
|
||||
applications do <emphasis>not</emphasis> need to use the API described in
|
||||
this section.</para></warning>
|
||||
|
||||
<note><para>For the purpose of this section, the term
|
||||
<wordasword>format</wordasword> means the combination of media bus data
|
||||
format, frame width and frame height.</para></note>
|
||||
|
||||
<para>Image formats are typically negotiated on video capture and output
|
||||
devices using the <link linkend="crop">cropping and scaling</link> ioctls.
|
||||
The driver is responsible for configuring every block in the video pipeline
|
||||
according to the requested format at the pipeline input and/or
|
||||
output.</para>
|
||||
|
||||
<para>For complex devices, such as often found in embedded systems,
|
||||
identical image sizes at the output of a pipeline can be achieved using
|
||||
different hardware configurations. One such example is shown on
|
||||
<xref linkend="pipeline-scaling" />, where
|
||||
image scaling can be performed on both the video sensor and the host image
|
||||
processing hardware.</para>
|
||||
|
||||
<figure id="pipeline-scaling">
|
||||
<title>Image Format Negotation on Pipelines</title>
|
||||
<mediaobject>
|
||||
<imageobject>
|
||||
<imagedata fileref="pipeline.pdf" format="PS" />
|
||||
</imageobject>
|
||||
<imageobject>
|
||||
<imagedata fileref="pipeline.png" format="PNG" />
|
||||
</imageobject>
|
||||
<textobject>
|
||||
<phrase>High quality and high speed pipeline configuration</phrase>
|
||||
</textobject>
|
||||
</mediaobject>
|
||||
</figure>
|
||||
|
||||
<para>The sensor scaler is usually of less quality than the host scaler, but
|
||||
scaling on the sensor is required to achieve higher frame rates. Depending
|
||||
on the use case (quality vs. speed), the pipeline must be configured
|
||||
differently. Applications need to configure the formats at every point in
|
||||
the pipeline explicitly.</para>
|
||||
|
||||
<para>Drivers that implement the <link linkend="media-controller-intro">media
|
||||
API</link> can expose pad-level image format configuration to applications.
|
||||
When they do, applications can use the &VIDIOC-SUBDEV-G-FMT; and
|
||||
&VIDIOC-SUBDEV-S-FMT; ioctls. to negotiate formats on a per-pad basis.</para>
|
||||
|
||||
<para>Applications are responsible for configuring coherent parameters on
|
||||
the whole pipeline and making sure that connected pads have compatible
|
||||
formats. The pipeline is checked for formats mismatch at &VIDIOC-STREAMON;
|
||||
time, and an &EPIPE; is then returned if the configuration is
|
||||
invalid.</para>
|
||||
|
||||
<para>Pad-level image format configuration support can be tested by calling
|
||||
the &VIDIOC-SUBDEV-G-FMT; ioctl on pad 0. If the driver returns an &EINVAL;
|
||||
pad-level format configuration is not supported by the sub-device.</para>
|
||||
|
||||
<section>
|
||||
<title>Format Negotiation</title>
|
||||
|
||||
<para>Acceptable formats on pads can (and usually do) depend on a number
|
||||
of external parameters, such as formats on other pads, active links, or
|
||||
even controls. Finding a combination of formats on all pads in a video
|
||||
pipeline, acceptable to both application and driver, can't rely on formats
|
||||
enumeration only. A format negotiation mechanism is required.</para>
|
||||
|
||||
<para>Central to the format negotiation mechanism are the get/set format
|
||||
operations. When called with the <structfield>which</structfield> argument
|
||||
set to <constant>V4L2_SUBDEV_FORMAT_TRY</constant>, the
|
||||
&VIDIOC-SUBDEV-G-FMT; and &VIDIOC-SUBDEV-S-FMT; ioctls operate on a set of
|
||||
formats parameters that are not connected to the hardware configuration.
|
||||
Modifying those 'try' formats leaves the device state untouched (this
|
||||
applies to both the software state stored in the driver and the hardware
|
||||
state stored in the device itself).</para>
|
||||
|
||||
<para>While not kept as part of the device state, try formats are stored
|
||||
in the sub-device file handles. A &VIDIOC-SUBDEV-G-FMT; call will return
|
||||
the last try format set <emphasis>on the same sub-device file
|
||||
handle</emphasis>. Several applications querying the same sub-device at
|
||||
the same time will thus not interact with each other.</para>
|
||||
|
||||
<para>To find out whether a particular format is supported by the device,
|
||||
applications use the &VIDIOC-SUBDEV-S-FMT; ioctl. Drivers verify and, if
|
||||
needed, change the requested <structfield>format</structfield> based on
|
||||
device requirements and return the possibly modified value. Applications
|
||||
can then choose to try a different format or accept the returned value and
|
||||
continue.</para>
|
||||
|
||||
<para>Formats returned by the driver during a negotiation iteration are
|
||||
guaranteed to be supported by the device. In particular, drivers guarantee
|
||||
that a returned format will not be further changed if passed to an
|
||||
&VIDIOC-SUBDEV-S-FMT; call as-is (as long as external parameters, such as
|
||||
formats on other pads or links' configuration are not changed).</para>
|
||||
|
||||
<para>Drivers automatically propagate formats inside sub-devices. When a
|
||||
try or active format is set on a pad, corresponding formats on other pads
|
||||
of the same sub-device can be modified by the driver. Drivers are free to
|
||||
modify formats as required by the device. However, they should comply with
|
||||
the following rules when possible:
|
||||
<itemizedlist>
|
||||
<listitem><para>Formats should be propagated from sink pads to source pads.
|
||||
Modifying a format on a source pad should not modify the format on any
|
||||
sink pad.</para></listitem>
|
||||
<listitem><para>Sub-devices that scale frames using variable scaling factors
|
||||
should reset the scale factors to default values when sink pads formats
|
||||
are modified. If the 1:1 scaling ratio is supported, this means that
|
||||
source pads formats should be reset to the sink pads formats.</para></listitem>
|
||||
</itemizedlist>
|
||||
</para>
|
||||
|
||||
<para>Formats are not propagated across links, as that would involve
|
||||
propagating them from one sub-device file handle to another. Applications
|
||||
must then take care to configure both ends of every link explicitly with
|
||||
compatible formats. Identical formats on the two ends of a link are
|
||||
guaranteed to be compatible. Drivers are free to accept different formats
|
||||
matching device requirements as being compatible.</para>
|
||||
|
||||
<para><xref linkend="sample-pipeline-config" />
|
||||
shows a sample configuration sequence for the pipeline described in
|
||||
<xref linkend="pipeline-scaling" /> (table
|
||||
columns list entity names and pad numbers).</para>
|
||||
|
||||
<table pgwide="0" frame="none" id="sample-pipeline-config">
|
||||
<title>Sample Pipeline Configuration</title>
|
||||
<tgroup cols="3">
|
||||
<colspec colname="what"/>
|
||||
<colspec colname="sensor-0" />
|
||||
<colspec colname="frontend-0" />
|
||||
<colspec colname="frontend-1" />
|
||||
<colspec colname="scaler-0" />
|
||||
<colspec colname="scaler-1" />
|
||||
<thead>
|
||||
<row>
|
||||
<entry></entry>
|
||||
<entry>Sensor/0</entry>
|
||||
<entry>Frontend/0</entry>
|
||||
<entry>Frontend/1</entry>
|
||||
<entry>Scaler/0</entry>
|
||||
<entry>Scaler/1</entry>
|
||||
</row>
|
||||
</thead>
|
||||
<tbody valign="top">
|
||||
<row>
|
||||
<entry>Initial state</entry>
|
||||
<entry>2048x1536</entry>
|
||||
<entry>-</entry>
|
||||
<entry>-</entry>
|
||||
<entry>-</entry>
|
||||
<entry>-</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry>Configure frontend input</entry>
|
||||
<entry>2048x1536</entry>
|
||||
<entry><emphasis>2048x1536</emphasis></entry>
|
||||
<entry><emphasis>2046x1534</emphasis></entry>
|
||||
<entry>-</entry>
|
||||
<entry>-</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry>Configure scaler input</entry>
|
||||
<entry>2048x1536</entry>
|
||||
<entry>2048x1536</entry>
|
||||
<entry>2046x1534</entry>
|
||||
<entry><emphasis>2046x1534</emphasis></entry>
|
||||
<entry><emphasis>2046x1534</emphasis></entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry>Configure scaler output</entry>
|
||||
<entry>2048x1536</entry>
|
||||
<entry>2048x1536</entry>
|
||||
<entry>2046x1534</entry>
|
||||
<entry>2046x1534</entry>
|
||||
<entry><emphasis>1280x960</emphasis></entry>
|
||||
</row>
|
||||
</tbody>
|
||||
</tgroup>
|
||||
</table>
|
||||
|
||||
<para>
|
||||
<orderedlist>
|
||||
<listitem><para>Initial state. The sensor output is set to its native 3MP
|
||||
resolution. Resolutions on the host frontend and scaler input and output
|
||||
pads are undefined.</para></listitem>
|
||||
<listitem><para>The application configures the frontend input pad resolution to
|
||||
2048x1536. The driver propagates the format to the frontend output pad.
|
||||
Note that the propagated output format can be different, as in this case,
|
||||
than the input format, as the hardware might need to crop pixels (for
|
||||
instance when converting a Bayer filter pattern to RGB or YUV).</para></listitem>
|
||||
<listitem><para>The application configures the scaler input pad resolution to
|
||||
2046x1534 to match the frontend output resolution. The driver propagates
|
||||
the format to the scaler output pad.</para></listitem>
|
||||
<listitem><para>The application configures the scaler output pad resolution to
|
||||
1280x960.</para></listitem>
|
||||
</orderedlist>
|
||||
</para>
|
||||
|
||||
<para>When satisfied with the try results, applications can set the active
|
||||
formats by setting the <structfield>which</structfield> argument to
|
||||
<constant>V4L2_SUBDEV_FORMAT_TRY</constant>. Active formats are changed
|
||||
exactly as try formats by drivers. To avoid modifying the hardware state
|
||||
during format negotiation, applications should negotiate try formats first
|
||||
and then modify the active settings using the try formats returned during
|
||||
the last negotiation iteration. This guarantees that the active format
|
||||
will be applied as-is by the driver without being modified.
|
||||
</para>
|
||||
</section>
|
||||
|
||||
<section>
|
||||
<title>Cropping and scaling</title>
|
||||
|
||||
<para>Many sub-devices support cropping frames on their input or output
|
||||
pads (or possible even on both). Cropping is used to select the area of
|
||||
interest in an image, typically on a video sensor or video decoder. It can
|
||||
also be used as part of digital zoom implementations to select the area of
|
||||
the image that will be scaled up.</para>
|
||||
|
||||
<para>Crop settings are defined by a crop rectangle and represented in a
|
||||
&v4l2-rect; by the coordinates of the top left corner and the rectangle
|
||||
size. Both the coordinates and sizes are expressed in pixels.</para>
|
||||
|
||||
<para>The crop rectangle is retrieved and set using the
|
||||
&VIDIOC-SUBDEV-G-CROP; and &VIDIOC-SUBDEV-S-CROP; ioctls. Like for pad
|
||||
formats, drivers store try and active crop rectangles. The format
|
||||
negotiation mechanism applies to crop settings as well.</para>
|
||||
|
||||
<para>On input pads, cropping is applied relatively to the current pad
|
||||
format. The pad format represents the image size as received by the
|
||||
sub-device from the previous block in the pipeline, and the crop rectangle
|
||||
represents the sub-image that will be transmitted further inside the
|
||||
sub-device for processing. The crop rectangle be entirely containted
|
||||
inside the input image size.</para>
|
||||
|
||||
<para>Input crop rectangle are reset to their default value when the input
|
||||
image format is modified. Drivers should use the input image size as the
|
||||
crop rectangle default value, but hardware requirements may prevent this.
|
||||
</para>
|
||||
|
||||
<para>Cropping behaviour on output pads is not defined.</para>
|
||||
|
||||
</section>
|
||||
</section>
|
||||
|
||||
&sub-subdev-formats;
|
||||
|
|
@ -45,7 +45,10 @@ just specify a <constant>NULL</constant> pointer here.</para>
|
|||
<listitem>
|
||||
<para>Length of the memory area to map. This must be the
|
||||
same value as returned by the driver in the &v4l2-buffer;
|
||||
<structfield>length</structfield> field.</para>
|
||||
<structfield>length</structfield> field for the
|
||||
single-planar API, and the same value as returned by the driver
|
||||
in the &v4l2-plane; <structfield>length</structfield> field for the
|
||||
multi-planar API.</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
<varlistentry>
|
||||
|
|
@ -106,7 +109,10 @@ flag.</para>
|
|||
<listitem>
|
||||
<para>Offset of the buffer in device memory. This must be the
|
||||
same value as returned by the driver in the &v4l2-buffer;
|
||||
<structfield>m</structfield> union <structfield>offset</structfield> field.</para>
|
||||
<structfield>m</structfield> union <structfield>offset</structfield> field for
|
||||
the single-planar API, and the same value as returned by the driver
|
||||
in the &v4l2-plane; <structfield>m</structfield> union
|
||||
<structfield>mem_offset</structfield> field for the multi-planar API.</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
</variablelist>
|
||||
|
|
|
|||
|
|
@ -37,7 +37,8 @@
|
|||
<para>Length of the mapped buffer. This must be the same
|
||||
value as given to <function>mmap()</function> and returned by the
|
||||
driver in the &v4l2-buffer; <structfield>length</structfield>
|
||||
field.</para>
|
||||
field for the single-planar API and in the &v4l2-plane;
|
||||
<structfield>length</structfield> field for the multi-planar API.</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
</variablelist>
|
||||
|
|
|
|||
|
|
@ -121,18 +121,22 @@ mapped.</para>
|
|||
<para>Before applications can access the buffers they must map
|
||||
them into their address space with the &func-mmap; function. The
|
||||
location of the buffers in device memory can be determined with the
|
||||
&VIDIOC-QUERYBUF; ioctl. The <structfield>m.offset</structfield> and
|
||||
<structfield>length</structfield> returned in a &v4l2-buffer; are
|
||||
passed as sixth and second parameter to the
|
||||
<function>mmap()</function> function. The offset and length values
|
||||
must not be modified. Remember the buffers are allocated in physical
|
||||
memory, as opposed to virtual memory which can be swapped out to disk.
|
||||
Applications should free the buffers as soon as possible with the
|
||||
&func-munmap; function.</para>
|
||||
&VIDIOC-QUERYBUF; ioctl. In the single-planar API case, the
|
||||
<structfield>m.offset</structfield> and <structfield>length</structfield>
|
||||
returned in a &v4l2-buffer; are passed as sixth and second parameter to the
|
||||
<function>mmap()</function> function. When using the multi-planar API,
|
||||
struct &v4l2-buffer; contains an array of &v4l2-plane; structures, each
|
||||
containing its own <structfield>m.offset</structfield> and
|
||||
<structfield>length</structfield>. When using the multi-planar API, every
|
||||
plane of every buffer has to be mapped separately, so the number of
|
||||
calls to &func-mmap; should be equal to number of buffers times number of
|
||||
planes in each buffer. The offset and length values must not be modified.
|
||||
Remember, the buffers are allocated in physical memory, as opposed to virtual
|
||||
memory, which can be swapped out to disk. Applications should free the buffers
|
||||
as soon as possible with the &func-munmap; function.</para>
|
||||
|
||||
<example>
|
||||
<title>Mapping buffers</title>
|
||||
|
||||
<title>Mapping buffers in the single-planar API</title>
|
||||
<programlisting>
|
||||
&v4l2-requestbuffers; reqbuf;
|
||||
struct {
|
||||
|
|
@ -141,63 +145,145 @@ struct {
|
|||
} *buffers;
|
||||
unsigned int i;
|
||||
|
||||
memset (&reqbuf, 0, sizeof (reqbuf));
|
||||
memset(&reqbuf, 0, sizeof(reqbuf));
|
||||
reqbuf.type = V4L2_BUF_TYPE_VIDEO_CAPTURE;
|
||||
reqbuf.memory = V4L2_MEMORY_MMAP;
|
||||
reqbuf.count = 20;
|
||||
|
||||
if (-1 == ioctl (fd, &VIDIOC-REQBUFS;, &reqbuf)) {
|
||||
if (errno == EINVAL)
|
||||
printf ("Video capturing or mmap-streaming is not supported\n");
|
||||
printf("Video capturing or mmap-streaming is not supported\n");
|
||||
else
|
||||
perror ("VIDIOC_REQBUFS");
|
||||
perror("VIDIOC_REQBUFS");
|
||||
|
||||
exit (EXIT_FAILURE);
|
||||
exit(EXIT_FAILURE);
|
||||
}
|
||||
|
||||
/* We want at least five buffers. */
|
||||
|
||||
if (reqbuf.count < 5) {
|
||||
/* You may need to free the buffers here. */
|
||||
printf ("Not enough buffer memory\n");
|
||||
exit (EXIT_FAILURE);
|
||||
printf("Not enough buffer memory\n");
|
||||
exit(EXIT_FAILURE);
|
||||
}
|
||||
|
||||
buffers = calloc (reqbuf.count, sizeof (*buffers));
|
||||
assert (buffers != NULL);
|
||||
buffers = calloc(reqbuf.count, sizeof(*buffers));
|
||||
assert(buffers != NULL);
|
||||
|
||||
for (i = 0; i < reqbuf.count; i++) {
|
||||
&v4l2-buffer; buffer;
|
||||
|
||||
memset (&buffer, 0, sizeof (buffer));
|
||||
memset(&buffer, 0, sizeof(buffer));
|
||||
buffer.type = reqbuf.type;
|
||||
buffer.memory = V4L2_MEMORY_MMAP;
|
||||
buffer.index = i;
|
||||
|
||||
if (-1 == ioctl (fd, &VIDIOC-QUERYBUF;, &buffer)) {
|
||||
perror ("VIDIOC_QUERYBUF");
|
||||
exit (EXIT_FAILURE);
|
||||
perror("VIDIOC_QUERYBUF");
|
||||
exit(EXIT_FAILURE);
|
||||
}
|
||||
|
||||
buffers[i].length = buffer.length; /* remember for munmap() */
|
||||
|
||||
buffers[i].start = mmap (NULL, buffer.length,
|
||||
PROT_READ | PROT_WRITE, /* recommended */
|
||||
MAP_SHARED, /* recommended */
|
||||
fd, buffer.m.offset);
|
||||
buffers[i].start = mmap(NULL, buffer.length,
|
||||
PROT_READ | PROT_WRITE, /* recommended */
|
||||
MAP_SHARED, /* recommended */
|
||||
fd, buffer.m.offset);
|
||||
|
||||
if (MAP_FAILED == buffers[i].start) {
|
||||
/* If you do not exit here you should unmap() and free()
|
||||
the buffers mapped so far. */
|
||||
perror ("mmap");
|
||||
exit (EXIT_FAILURE);
|
||||
perror("mmap");
|
||||
exit(EXIT_FAILURE);
|
||||
}
|
||||
}
|
||||
|
||||
/* Cleanup. */
|
||||
|
||||
for (i = 0; i < reqbuf.count; i++)
|
||||
munmap (buffers[i].start, buffers[i].length);
|
||||
munmap(buffers[i].start, buffers[i].length);
|
||||
</programlisting>
|
||||
</example>
|
||||
|
||||
<example>
|
||||
<title>Mapping buffers in the multi-planar API</title>
|
||||
<programlisting>
|
||||
&v4l2-requestbuffers; reqbuf;
|
||||
/* Our current format uses 3 planes per buffer */
|
||||
#define FMT_NUM_PLANES = 3;
|
||||
|
||||
struct {
|
||||
void *start[FMT_NUM_PLANES];
|
||||
size_t length[FMT_NUM_PLANES];
|
||||
} *buffers;
|
||||
unsigned int i, j;
|
||||
|
||||
memset(&reqbuf, 0, sizeof(reqbuf));
|
||||
reqbuf.type = V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE;
|
||||
reqbuf.memory = V4L2_MEMORY_MMAP;
|
||||
reqbuf.count = 20;
|
||||
|
||||
if (ioctl(fd, &VIDIOC-REQBUFS;, &reqbuf) < 0) {
|
||||
if (errno == EINVAL)
|
||||
printf("Video capturing or mmap-streaming is not supported\n");
|
||||
else
|
||||
perror("VIDIOC_REQBUFS");
|
||||
|
||||
exit(EXIT_FAILURE);
|
||||
}
|
||||
|
||||
/* We want at least five buffers. */
|
||||
|
||||
if (reqbuf.count < 5) {
|
||||
/* You may need to free the buffers here. */
|
||||
printf("Not enough buffer memory\n");
|
||||
exit(EXIT_FAILURE);
|
||||
}
|
||||
|
||||
buffers = calloc(reqbuf.count, sizeof(*buffers));
|
||||
assert(buffers != NULL);
|
||||
|
||||
for (i = 0; i < reqbuf.count; i++) {
|
||||
&v4l2-buffer; buffer;
|
||||
&v4l2-plane; planes[FMT_NUM_PLANES];
|
||||
|
||||
memset(&buffer, 0, sizeof(buffer));
|
||||
buffer.type = reqbuf.type;
|
||||
buffer.memory = V4L2_MEMORY_MMAP;
|
||||
buffer.index = i;
|
||||
/* length in struct v4l2_buffer in multi-planar API stores the size
|
||||
* of planes array. */
|
||||
buffer.length = FMT_NUM_PLANES;
|
||||
buffer.m.planes = planes;
|
||||
|
||||
if (ioctl(fd, &VIDIOC-QUERYBUF;, &buffer) < 0) {
|
||||
perror("VIDIOC_QUERYBUF");
|
||||
exit(EXIT_FAILURE);
|
||||
}
|
||||
|
||||
/* Every plane has to be mapped separately */
|
||||
for (j = 0; j < FMT_NUM_PLANES; j++) {
|
||||
buffers[i].length[j] = buffer.m.planes[j].length; /* remember for munmap() */
|
||||
|
||||
buffers[i].start[j] = mmap(NULL, buffer.m.planes[j].length,
|
||||
PROT_READ | PROT_WRITE, /* recommended */
|
||||
MAP_SHARED, /* recommended */
|
||||
fd, buffer.m.planes[j].m.offset);
|
||||
|
||||
if (MAP_FAILED == buffers[i].start[j]) {
|
||||
/* If you do not exit here you should unmap() and free()
|
||||
the buffers and planes mapped so far. */
|
||||
perror("mmap");
|
||||
exit(EXIT_FAILURE);
|
||||
}
|
||||
}
|
||||
}
|
||||
|
||||
/* Cleanup. */
|
||||
|
||||
for (i = 0; i < reqbuf.count; i++)
|
||||
for (j = 0; j < FMT_NUM_PLANES; j++)
|
||||
munmap(buffers[i].start[j], buffers[i].length[j]);
|
||||
</programlisting>
|
||||
</example>
|
||||
|
||||
|
|
@ -286,13 +372,13 @@ pointer method (not only memory mapping) is supported must be
|
|||
determined by calling the &VIDIOC-REQBUFS; ioctl.</para>
|
||||
|
||||
<para>This I/O method combines advantages of the read/write and
|
||||
memory mapping methods. Buffers are allocated by the application
|
||||
memory mapping methods. Buffers (planes) are allocated by the application
|
||||
itself, and can reside for example in virtual or shared memory. Only
|
||||
pointers to data are exchanged, these pointers and meta-information
|
||||
are passed in &v4l2-buffer;. The driver must be switched
|
||||
into user pointer I/O mode by calling the &VIDIOC-REQBUFS; with the
|
||||
desired buffer type. No buffers are allocated beforehands,
|
||||
consequently they are not indexed and cannot be queried like mapped
|
||||
are passed in &v4l2-buffer; (or in &v4l2-plane; in the multi-planar API case).
|
||||
The driver must be switched into user pointer I/O mode by calling the
|
||||
&VIDIOC-REQBUFS; with the desired buffer type. No buffers (planes) are allocated
|
||||
beforehand, consequently they are not indexed and cannot be queried like mapped
|
||||
buffers with the <constant>VIDIOC_QUERYBUF</constant> ioctl.</para>
|
||||
|
||||
<example>
|
||||
|
|
@ -316,7 +402,7 @@ if (ioctl (fd, &VIDIOC-REQBUFS;, &reqbuf) == -1) {
|
|||
</programlisting>
|
||||
</example>
|
||||
|
||||
<para>Buffer addresses and sizes are passed on the fly with the
|
||||
<para>Buffer (plane) addresses and sizes are passed on the fly with the
|
||||
&VIDIOC-QBUF; ioctl. Although buffers are commonly cycled,
|
||||
applications can pass different addresses and sizes at each
|
||||
<constant>VIDIOC_QBUF</constant> call. If required by the hardware the
|
||||
|
|
@ -396,11 +482,18 @@ rest should be evident.</para>
|
|||
<title>Buffers</title>
|
||||
|
||||
<para>A buffer contains data exchanged by application and
|
||||
driver using one of the Streaming I/O methods. Only pointers to
|
||||
buffers are exchanged, the data itself is not copied. These pointers,
|
||||
together with meta-information like timestamps or field parity, are
|
||||
stored in a struct <structname>v4l2_buffer</structname>, argument to
|
||||
the &VIDIOC-QUERYBUF;, &VIDIOC-QBUF; and &VIDIOC-DQBUF; ioctl.</para>
|
||||
driver using one of the Streaming I/O methods. In the multi-planar API, the
|
||||
data is held in planes, while the buffer structure acts as a container
|
||||
for the planes. Only pointers to buffers (planes) are exchanged, the data
|
||||
itself is not copied. These pointers, together with meta-information like
|
||||
timestamps or field parity, are stored in a struct
|
||||
<structname>v4l2_buffer</structname>, argument to
|
||||
the &VIDIOC-QUERYBUF;, &VIDIOC-QBUF; and &VIDIOC-DQBUF; ioctl.
|
||||
In the multi-planar API, some plane-specific members of struct
|
||||
<structname>v4l2_buffer</structname>, such as pointers and sizes for each
|
||||
plane, are stored in struct <structname>v4l2_plane</structname> instead.
|
||||
In that case, struct <structname>v4l2_buffer</structname> contains an array of
|
||||
plane structures.</para>
|
||||
|
||||
<para>Nominally timestamps refer to the first data byte transmitted.
|
||||
In practice however the wide range of hardware covered by the V4L2 API
|
||||
|
|
@ -551,26 +644,40 @@ in accordance with the selected I/O method.</entry>
|
|||
<entry></entry>
|
||||
<entry>__u32</entry>
|
||||
<entry><structfield>offset</structfield></entry>
|
||||
<entry>When <structfield>memory</structfield> is
|
||||
<constant>V4L2_MEMORY_MMAP</constant> this is the offset of the buffer
|
||||
from the start of the device memory. The value is returned by the
|
||||
driver and apart of serving as parameter to the &func-mmap; function
|
||||
not useful for applications. See <xref linkend="mmap" /> for details.</entry>
|
||||
<entry>For the single-planar API and when
|
||||
<structfield>memory</structfield> is <constant>V4L2_MEMORY_MMAP</constant> this
|
||||
is the offset of the buffer from the start of the device memory. The value is
|
||||
returned by the driver and apart of serving as parameter to the &func-mmap;
|
||||
function not useful for applications. See <xref linkend="mmap" /> for details
|
||||
</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry></entry>
|
||||
<entry>unsigned long</entry>
|
||||
<entry><structfield>userptr</structfield></entry>
|
||||
<entry>When <structfield>memory</structfield> is
|
||||
<constant>V4L2_MEMORY_USERPTR</constant> this is a pointer to the
|
||||
buffer (casted to unsigned long type) in virtual memory, set by the
|
||||
application. See <xref linkend="userp" /> for details.</entry>
|
||||
<entry>For the single-planar API and when
|
||||
<structfield>memory</structfield> is <constant>V4L2_MEMORY_USERPTR</constant>
|
||||
this is a pointer to the buffer (casted to unsigned long type) in virtual
|
||||
memory, set by the application. See <xref linkend="userp" /> for details.
|
||||
</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry></entry>
|
||||
<entry>struct v4l2_plane</entry>
|
||||
<entry><structfield>*planes</structfield></entry>
|
||||
<entry>When using the multi-planar API, contains a userspace pointer
|
||||
to an array of &v4l2-plane;. The size of the array should be put
|
||||
in the <structfield>length</structfield> field of this
|
||||
<structname>v4l2_buffer</structname> structure.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry>__u32</entry>
|
||||
<entry><structfield>length</structfield></entry>
|
||||
<entry></entry>
|
||||
<entry>Size of the buffer (not the payload) in bytes.</entry>
|
||||
<entry>Size of the buffer (not the payload) in bytes for the
|
||||
single-planar API. For the multi-planar API should contain the
|
||||
number of elements in the <structfield>planes</structfield> array.
|
||||
</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry>__u32</entry>
|
||||
|
|
@ -596,6 +703,66 @@ should set this to 0.</entry>
|
|||
</tgroup>
|
||||
</table>
|
||||
|
||||
<table frame="none" pgwide="1" id="v4l2-plane">
|
||||
<title>struct <structname>v4l2_plane</structname></title>
|
||||
<tgroup cols="4">
|
||||
&cs-ustr;
|
||||
<tbody valign="top">
|
||||
<row>
|
||||
<entry>__u32</entry>
|
||||
<entry><structfield>bytesused</structfield></entry>
|
||||
<entry></entry>
|
||||
<entry>The number of bytes occupied by data in the plane
|
||||
(its payload).</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry>__u32</entry>
|
||||
<entry><structfield>length</structfield></entry>
|
||||
<entry></entry>
|
||||
<entry>Size in bytes of the plane (not its payload).</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry>union</entry>
|
||||
<entry><structfield>m</structfield></entry>
|
||||
<entry></entry>
|
||||
<entry></entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry></entry>
|
||||
<entry>__u32</entry>
|
||||
<entry><structfield>mem_offset</structfield></entry>
|
||||
<entry>When the memory type in the containing &v4l2-buffer; is
|
||||
<constant>V4L2_MEMORY_MMAP</constant>, this is the value that
|
||||
should be passed to &func-mmap;, similar to the
|
||||
<structfield>offset</structfield> field in &v4l2-buffer;.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry></entry>
|
||||
<entry>__unsigned long</entry>
|
||||
<entry><structfield>userptr</structfield></entry>
|
||||
<entry>When the memory type in the containing &v4l2-buffer; is
|
||||
<constant>V4L2_MEMORY_USERPTR</constant>, this is a userspace
|
||||
pointer to the memory allocated for this plane by an application.
|
||||
</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry>__u32</entry>
|
||||
<entry><structfield>data_offset</structfield></entry>
|
||||
<entry></entry>
|
||||
<entry>Offset in bytes to video data in the plane, if applicable.
|
||||
</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry>__u32</entry>
|
||||
<entry><structfield>reserved[11]</structfield></entry>
|
||||
<entry></entry>
|
||||
<entry>Reserved for future use. Should be zeroed by an
|
||||
application.</entry>
|
||||
</row>
|
||||
</tbody>
|
||||
</tgroup>
|
||||
</table>
|
||||
|
||||
<table frame="none" pgwide="1" id="v4l2-buf-type">
|
||||
<title>enum v4l2_buf_type</title>
|
||||
<tgroup cols="3">
|
||||
|
|
@ -604,13 +771,27 @@ should set this to 0.</entry>
|
|||
<row>
|
||||
<entry><constant>V4L2_BUF_TYPE_VIDEO_CAPTURE</constant></entry>
|
||||
<entry>1</entry>
|
||||
<entry>Buffer of a video capture stream, see <xref
|
||||
<entry>Buffer of a single-planar video capture stream, see <xref
|
||||
linkend="capture" />.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry><constant>V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE</constant>
|
||||
</entry>
|
||||
<entry>9</entry>
|
||||
<entry>Buffer of a multi-planar video capture stream, see <xref
|
||||
linkend="capture" />.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry><constant>V4L2_BUF_TYPE_VIDEO_OUTPUT</constant></entry>
|
||||
<entry>2</entry>
|
||||
<entry>Buffer of a video output stream, see <xref
|
||||
<entry>Buffer of a single-planar video output stream, see <xref
|
||||
linkend="output" />.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry><constant>V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE</constant>
|
||||
</entry>
|
||||
<entry>10</entry>
|
||||
<entry>Buffer of a multi-planar video output stream, see <xref
|
||||
linkend="output" />.</entry>
|
||||
</row>
|
||||
<row>
|
||||
|
|
|
|||
|
|
@ -45,7 +45,7 @@ describing an IR signal are read from the chardev.</para>
|
|||
<para>The data written to the chardev is a pulse/space sequence of integer
|
||||
values. Pulses and spaces are only marked implicitly by their position. The
|
||||
data must start and end with a pulse, therefore, the data must always include
|
||||
an unevent number of samples. The write function must block until the data has
|
||||
an uneven number of samples. The write function must block until the data has
|
||||
been transmitted by the hardware.</para>
|
||||
</section>
|
||||
|
||||
|
|
|
|||
|
|
@ -0,0 +1,89 @@
|
|||
<partinfo>
|
||||
<authorgroup>
|
||||
<author>
|
||||
<firstname>Laurent</firstname>
|
||||
<surname>Pinchart</surname>
|
||||
<affiliation><address><email>laurent.pinchart@ideasonboard.com</email></address></affiliation>
|
||||
<contrib>Initial version.</contrib>
|
||||
</author>
|
||||
</authorgroup>
|
||||
<copyright>
|
||||
<year>2010</year>
|
||||
<holder>Laurent Pinchart</holder>
|
||||
</copyright>
|
||||
|
||||
<revhistory>
|
||||
<!-- Put document revisions here, newest first. -->
|
||||
<revision>
|
||||
<revnumber>1.0.0</revnumber>
|
||||
<date>2010-11-10</date>
|
||||
<authorinitials>lp</authorinitials>
|
||||
<revremark>Initial revision</revremark>
|
||||
</revision>
|
||||
</revhistory>
|
||||
</partinfo>
|
||||
|
||||
<title>Media Controller API</title>
|
||||
|
||||
<chapter id="media_controller">
|
||||
<title>Media Controller</title>
|
||||
|
||||
<section id="media-controller-intro">
|
||||
<title>Introduction</title>
|
||||
<para>Media devices increasingly handle multiple related functions. Many USB
|
||||
cameras include microphones, video capture hardware can also output video,
|
||||
or SoC camera interfaces also perform memory-to-memory operations similar to
|
||||
video codecs.</para>
|
||||
<para>Independent functions, even when implemented in the same hardware, can
|
||||
be modelled as separate devices. A USB camera with a microphone will be
|
||||
presented to userspace applications as V4L2 and ALSA capture devices. The
|
||||
devices' relationships (when using a webcam, end-users shouldn't have to
|
||||
manually select the associated USB microphone), while not made available
|
||||
directly to applications by the drivers, can usually be retrieved from
|
||||
sysfs.</para>
|
||||
<para>With more and more advanced SoC devices being introduced, the current
|
||||
approach will not scale. Device topologies are getting increasingly complex
|
||||
and can't always be represented by a tree structure. Hardware blocks are
|
||||
shared between different functions, creating dependencies between seemingly
|
||||
unrelated devices.</para>
|
||||
<para>Kernel abstraction APIs such as V4L2 and ALSA provide means for
|
||||
applications to access hardware parameters. As newer hardware expose an
|
||||
increasingly high number of those parameters, drivers need to guess what
|
||||
applications really require based on limited information, thereby
|
||||
implementing policies that belong to userspace.</para>
|
||||
<para>The media controller API aims at solving those problems.</para>
|
||||
</section>
|
||||
|
||||
<section id="media-controller-model">
|
||||
<title>Media device model</title>
|
||||
<para>Discovering a device internal topology, and configuring it at runtime,
|
||||
is one of the goals of the media controller API. To achieve this, hardware
|
||||
devices are modelled as an oriented graph of building blocks called entities
|
||||
connected through pads.</para>
|
||||
<para>An entity is a basic media hardware or software building block. It can
|
||||
correspond to a large variety of logical blocks such as physical hardware
|
||||
devices (CMOS sensor for instance), logical hardware devices (a building
|
||||
block in a System-on-Chip image processing pipeline), DMA channels or
|
||||
physical connectors.</para>
|
||||
<para>A pad is a connection endpoint through which an entity can interact
|
||||
with other entities. Data (not restricted to video) produced by an entity
|
||||
flows from the entity's output to one or more entity inputs. Pads should not
|
||||
be confused with physical pins at chip boundaries.</para>
|
||||
<para>A link is a point-to-point oriented connection between two pads,
|
||||
either on the same entity or on different entities. Data flows from a source
|
||||
pad to a sink pad.</para>
|
||||
</section>
|
||||
</chapter>
|
||||
|
||||
<appendix id="media-user-func">
|
||||
<title>Function Reference</title>
|
||||
<!-- Keep this alphabetically sorted. -->
|
||||
&sub-media-open;
|
||||
&sub-media-close;
|
||||
&sub-media-ioctl;
|
||||
<!-- All ioctls go here. -->
|
||||
&sub-media-ioc-device-info;
|
||||
&sub-media-ioc-enum-entities;
|
||||
&sub-media-ioc-enum-links;
|
||||
&sub-media-ioc-setup-link;
|
||||
</appendix>
|
||||
|
|
@ -0,0 +1,59 @@
|
|||
<refentry id="media-func-close">
|
||||
<refmeta>
|
||||
<refentrytitle>media close()</refentrytitle>
|
||||
&manvol;
|
||||
</refmeta>
|
||||
|
||||
<refnamediv>
|
||||
<refname>media-close</refname>
|
||||
<refpurpose>Close a media device</refpurpose>
|
||||
</refnamediv>
|
||||
|
||||
<refsynopsisdiv>
|
||||
<funcsynopsis>
|
||||
<funcsynopsisinfo>#include <unistd.h></funcsynopsisinfo>
|
||||
<funcprototype>
|
||||
<funcdef>int <function>close</function></funcdef>
|
||||
<paramdef>int <parameter>fd</parameter></paramdef>
|
||||
</funcprototype>
|
||||
</funcsynopsis>
|
||||
</refsynopsisdiv>
|
||||
|
||||
<refsect1>
|
||||
<title>Arguments</title>
|
||||
|
||||
<variablelist>
|
||||
<varlistentry>
|
||||
<term><parameter>fd</parameter></term>
|
||||
<listitem>
|
||||
<para>&fd;</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
</variablelist>
|
||||
</refsect1>
|
||||
|
||||
<refsect1>
|
||||
<title>Description</title>
|
||||
|
||||
<para>Closes the media device. Resources associated with the file descriptor
|
||||
are freed. The device configuration remain unchanged.</para>
|
||||
</refsect1>
|
||||
|
||||
<refsect1>
|
||||
<title>Return Value</title>
|
||||
|
||||
<para><function>close</function> returns 0 on success. On error, -1 is
|
||||
returned, and <varname>errno</varname> is set appropriately. Possible error
|
||||
codes are:</para>
|
||||
|
||||
<variablelist>
|
||||
<varlistentry>
|
||||
<term><errorcode>EBADF</errorcode></term>
|
||||
<listitem>
|
||||
<para><parameter>fd</parameter> is not a valid open file descriptor.
|
||||
</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
</variablelist>
|
||||
</refsect1>
|
||||
</refentry>
|
||||
|
|
@ -0,0 +1,116 @@
|
|||
<refentry id="media-func-ioctl">
|
||||
<refmeta>
|
||||
<refentrytitle>media ioctl()</refentrytitle>
|
||||
&manvol;
|
||||
</refmeta>
|
||||
|
||||
<refnamediv>
|
||||
<refname>media-ioctl</refname>
|
||||
<refpurpose>Control a media device</refpurpose>
|
||||
</refnamediv>
|
||||
|
||||
<refsynopsisdiv>
|
||||
<funcsynopsis>
|
||||
<funcsynopsisinfo>#include <sys/ioctl.h></funcsynopsisinfo>
|
||||
<funcprototype>
|
||||
<funcdef>int <function>ioctl</function></funcdef>
|
||||
<paramdef>int <parameter>fd</parameter></paramdef>
|
||||
<paramdef>int <parameter>request</parameter></paramdef>
|
||||
<paramdef>void *<parameter>argp</parameter></paramdef>
|
||||
</funcprototype>
|
||||
</funcsynopsis>
|
||||
</refsynopsisdiv>
|
||||
|
||||
<refsect1>
|
||||
<title>Arguments</title>
|
||||
|
||||
<variablelist>
|
||||
<varlistentry>
|
||||
<term><parameter>fd</parameter></term>
|
||||
<listitem>
|
||||
<para>&fd;</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
<varlistentry>
|
||||
<term><parameter>request</parameter></term>
|
||||
<listitem>
|
||||
<para>Media ioctl request code as defined in the media.h header file,
|
||||
for example MEDIA_IOC_SETUP_LINK.</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
<varlistentry>
|
||||
<term><parameter>argp</parameter></term>
|
||||
<listitem>
|
||||
<para>Pointer to a request-specific structure.</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
</variablelist>
|
||||
</refsect1>
|
||||
|
||||
<refsect1>
|
||||
<title>Description</title>
|
||||
<para>The <function>ioctl()</function> function manipulates media device
|
||||
parameters. The argument <parameter>fd</parameter> must be an open file
|
||||
descriptor.</para>
|
||||
<para>The ioctl <parameter>request</parameter> code specifies the media
|
||||
function to be called. It has encoded in it whether the argument is an
|
||||
input, output or read/write parameter, and the size of the argument
|
||||
<parameter>argp</parameter> in bytes.</para>
|
||||
<para>Macros and structures definitions specifying media ioctl requests and
|
||||
their parameters are located in the media.h header file. All media ioctl
|
||||
requests, their respective function and parameters are specified in
|
||||
<xref linkend="media-user-func" />.</para>
|
||||
</refsect1>
|
||||
|
||||
<refsect1>
|
||||
<title>Return Value</title>
|
||||
|
||||
<para><function>ioctl()</function> returns <returnvalue>0</returnvalue> on
|
||||
success. On failure, <returnvalue>-1</returnvalue> is returned, and the
|
||||
<varname>errno</varname> variable is set appropriately. Generic error codes
|
||||
are listed below, and request-specific error codes are listed in the
|
||||
individual requests descriptions.</para>
|
||||
<para>When an ioctl that takes an output or read/write parameter fails,
|
||||
the parameter remains unmodified.</para>
|
||||
|
||||
<variablelist>
|
||||
<varlistentry>
|
||||
<term><errorcode>EBADF</errorcode></term>
|
||||
<listitem>
|
||||
<para><parameter>fd</parameter> is not a valid open file descriptor.
|
||||
</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
<varlistentry>
|
||||
<term><errorcode>EFAULT</errorcode></term>
|
||||
<listitem>
|
||||
<para><parameter>argp</parameter> references an inaccessible memory
|
||||
area.</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
<varlistentry>
|
||||
<term><errorcode>EINVAL</errorcode></term>
|
||||
<listitem>
|
||||
<para>The <parameter>request</parameter> or the data pointed to by
|
||||
<parameter>argp</parameter> is not valid. This is a very common error
|
||||
code, see the individual ioctl requests listed in
|
||||
<xref linkend="media-user-func" /> for actual causes.</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
<varlistentry>
|
||||
<term><errorcode>ENOMEM</errorcode></term>
|
||||
<listitem>
|
||||
<para>Insufficient kernel memory was available to complete the
|
||||
request.</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
<varlistentry>
|
||||
<term><errorcode>ENOTTY</errorcode></term>
|
||||
<listitem>
|
||||
<para><parameter>fd</parameter> is not associated with a character
|
||||
special device.</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
</variablelist>
|
||||
</refsect1>
|
||||
</refentry>
|
||||
|
|
@ -0,0 +1,94 @@
|
|||
<refentry id="media-func-open">
|
||||
<refmeta>
|
||||
<refentrytitle>media open()</refentrytitle>
|
||||
&manvol;
|
||||
</refmeta>
|
||||
|
||||
<refnamediv>
|
||||
<refname>media-open</refname>
|
||||
<refpurpose>Open a media device</refpurpose>
|
||||
</refnamediv>
|
||||
|
||||
<refsynopsisdiv>
|
||||
<funcsynopsis>
|
||||
<funcsynopsisinfo>#include <fcntl.h></funcsynopsisinfo>
|
||||
<funcprototype>
|
||||
<funcdef>int <function>open</function></funcdef>
|
||||
<paramdef>const char *<parameter>device_name</parameter></paramdef>
|
||||
<paramdef>int <parameter>flags</parameter></paramdef>
|
||||
</funcprototype>
|
||||
</funcsynopsis>
|
||||
</refsynopsisdiv>
|
||||
|
||||
<refsect1>
|
||||
<title>Arguments</title>
|
||||
|
||||
<variablelist>
|
||||
<varlistentry>
|
||||
<term><parameter>device_name</parameter></term>
|
||||
<listitem>
|
||||
<para>Device to be opened.</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
<varlistentry>
|
||||
<term><parameter>flags</parameter></term>
|
||||
<listitem>
|
||||
<para>Open flags. Access mode must be either <constant>O_RDONLY</constant>
|
||||
or <constant>O_RDWR</constant>. Other flags have no effect.</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
</variablelist>
|
||||
</refsect1>
|
||||
<refsect1>
|
||||
<title>Description</title>
|
||||
<para>To open a media device applications call <function>open()</function>
|
||||
with the desired device name. The function has no side effects; the device
|
||||
configuration remain unchanged.</para>
|
||||
<para>When the device is opened in read-only mode, attemps to modify its
|
||||
configuration will result in an error, and <varname>errno</varname> will be
|
||||
set to <errorcode>EBADF</errorcode>.</para>
|
||||
</refsect1>
|
||||
<refsect1>
|
||||
<title>Return Value</title>
|
||||
|
||||
<para><function>open</function> returns the new file descriptor on success.
|
||||
On error, -1 is returned, and <varname>errno</varname> is set appropriately.
|
||||
Possible error codes are:</para>
|
||||
|
||||
<variablelist>
|
||||
<varlistentry>
|
||||
<term><errorcode>EACCES</errorcode></term>
|
||||
<listitem>
|
||||
<para>The requested access to the file is not allowed.</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
<varlistentry>
|
||||
<term><errorcode>EMFILE</errorcode></term>
|
||||
<listitem>
|
||||
<para>The process already has the maximum number of files open.
|
||||
</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
<varlistentry>
|
||||
<term><errorcode>ENFILE</errorcode></term>
|
||||
<listitem>
|
||||
<para>The system limit on the total number of open files has been
|
||||
reached.</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
<varlistentry>
|
||||
<term><errorcode>ENOMEM</errorcode></term>
|
||||
<listitem>
|
||||
<para>Insufficient kernel memory was available.</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
<varlistentry>
|
||||
<term><errorcode>ENXIO</errorcode></term>
|
||||
<listitem>
|
||||
<para>No device corresponding to this device special file exists.
|
||||
</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
</variablelist>
|
||||
</refsect1>
|
||||
</refentry>
|
||||
|
|
@ -0,0 +1,133 @@
|
|||
<refentry id="media-ioc-device-info">
|
||||
<refmeta>
|
||||
<refentrytitle>ioctl MEDIA_IOC_DEVICE_INFO</refentrytitle>
|
||||
&manvol;
|
||||
</refmeta>
|
||||
|
||||
<refnamediv>
|
||||
<refname>MEDIA_IOC_DEVICE_INFO</refname>
|
||||
<refpurpose>Query device information</refpurpose>
|
||||
</refnamediv>
|
||||
|
||||
<refsynopsisdiv>
|
||||
<funcsynopsis>
|
||||
<funcprototype>
|
||||
<funcdef>int <function>ioctl</function></funcdef>
|
||||
<paramdef>int <parameter>fd</parameter></paramdef>
|
||||
<paramdef>int <parameter>request</parameter></paramdef>
|
||||
<paramdef>struct media_device_info *<parameter>argp</parameter></paramdef>
|
||||
</funcprototype>
|
||||
</funcsynopsis>
|
||||
</refsynopsisdiv>
|
||||
|
||||
<refsect1>
|
||||
<title>Arguments</title>
|
||||
|
||||
<variablelist>
|
||||
<varlistentry>
|
||||
<term><parameter>fd</parameter></term>
|
||||
<listitem>
|
||||
<para>File descriptor returned by
|
||||
<link linkend='media-func-open'><function>open()</function></link>.</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
<varlistentry>
|
||||
<term><parameter>request</parameter></term>
|
||||
<listitem>
|
||||
<para>MEDIA_IOC_DEVICE_INFO</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
<varlistentry>
|
||||
<term><parameter>argp</parameter></term>
|
||||
<listitem>
|
||||
<para></para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
</variablelist>
|
||||
</refsect1>
|
||||
|
||||
<refsect1>
|
||||
<title>Description</title>
|
||||
|
||||
<para>All media devices must support the <constant>MEDIA_IOC_DEVICE_INFO</constant>
|
||||
ioctl. To query device information, applications call the ioctl with a
|
||||
pointer to a &media-device-info;. The driver fills the structure and returns
|
||||
the information to the application.
|
||||
The ioctl never fails.</para>
|
||||
|
||||
<table pgwide="1" frame="none" id="media-device-info">
|
||||
<title>struct <structname>media_device_info</structname></title>
|
||||
<tgroup cols="3">
|
||||
&cs-str;
|
||||
<tbody valign="top">
|
||||
<row>
|
||||
<entry>char</entry>
|
||||
<entry><structfield>driver</structfield>[16]</entry>
|
||||
<entry><para>Name of the driver implementing the media API as a
|
||||
NUL-terminated ASCII string. The driver version is stored in the
|
||||
<structfield>driver_version</structfield> field.</para>
|
||||
<para>Driver specific applications can use this information to
|
||||
verify the driver identity. It is also useful to work around
|
||||
known bugs, or to identify drivers in error reports.</para></entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry>char</entry>
|
||||
<entry><structfield>model</structfield>[32]</entry>
|
||||
<entry>Device model name as a NUL-terminated UTF-8 string. The
|
||||
device version is stored in the <structfield>device_version</structfield>
|
||||
field and is not be appended to the model name.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry>char</entry>
|
||||
<entry><structfield>serial</structfield>[40]</entry>
|
||||
<entry>Serial number as a NUL-terminated ASCII string.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry>char</entry>
|
||||
<entry><structfield>bus_info</structfield>[32]</entry>
|
||||
<entry>Location of the device in the system as a NUL-terminated
|
||||
ASCII string. This includes the bus type name (PCI, USB, ...) and a
|
||||
bus-specific identifier.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry>__u32</entry>
|
||||
<entry><structfield>media_version</structfield></entry>
|
||||
<entry>Media API version, formatted with the
|
||||
<constant>KERNEL_VERSION()</constant> macro.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry>__u32</entry>
|
||||
<entry><structfield>hw_revision</structfield></entry>
|
||||
<entry>Hardware device revision in a driver-specific format.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry>__u32</entry>
|
||||
<entry><structfield>media_version</structfield></entry>
|
||||
<entry>Media device driver version, formatted with the
|
||||
<constant>KERNEL_VERSION()</constant> macro. Together with the
|
||||
<structfield>driver</structfield> field this identifies a particular
|
||||
driver.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry>__u32</entry>
|
||||
<entry><structfield>reserved</structfield>[31]</entry>
|
||||
<entry>Reserved for future extensions. Drivers and applications must
|
||||
set this array to zero.</entry>
|
||||
</row>
|
||||
</tbody>
|
||||
</tgroup>
|
||||
</table>
|
||||
<para>The <structfield>serial</structfield> and <structfield>bus_info</structfield>
|
||||
fields can be used to distinguish between multiple instances of otherwise
|
||||
identical hardware. The serial number takes precedence when provided and can
|
||||
be assumed to be unique. If the serial number is an empty string, the
|
||||
<structfield>bus_info</structfield> field can be used instead. The
|
||||
<structfield>bus_info</structfield> field is guaranteed to be unique, but
|
||||
can vary across reboots or device unplug/replug.</para>
|
||||
</refsect1>
|
||||
|
||||
<refsect1>
|
||||
<title>Return value</title>
|
||||
<para>This function doesn't return specific error codes.</para>
|
||||
</refsect1>
|
||||
</refentry>
|
||||
|
|
@ -0,0 +1,308 @@
|
|||
<refentry id="media-ioc-enum-entities">
|
||||
<refmeta>
|
||||
<refentrytitle>ioctl MEDIA_IOC_ENUM_ENTITIES</refentrytitle>
|
||||
&manvol;
|
||||
</refmeta>
|
||||
|
||||
<refnamediv>
|
||||
<refname>MEDIA_IOC_ENUM_ENTITIES</refname>
|
||||
<refpurpose>Enumerate entities and their properties</refpurpose>
|
||||
</refnamediv>
|
||||
|
||||
<refsynopsisdiv>
|
||||
<funcsynopsis>
|
||||
<funcprototype>
|
||||
<funcdef>int <function>ioctl</function></funcdef>
|
||||
<paramdef>int <parameter>fd</parameter></paramdef>
|
||||
<paramdef>int <parameter>request</parameter></paramdef>
|
||||
<paramdef>struct media_entity_desc *<parameter>argp</parameter></paramdef>
|
||||
</funcprototype>
|
||||
</funcsynopsis>
|
||||
</refsynopsisdiv>
|
||||
|
||||
<refsect1>
|
||||
<title>Arguments</title>
|
||||
|
||||
<variablelist>
|
||||
<varlistentry>
|
||||
<term><parameter>fd</parameter></term>
|
||||
<listitem>
|
||||
<para>File descriptor returned by
|
||||
<link linkend='media-func-open'><function>open()</function></link>.</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
<varlistentry>
|
||||
<term><parameter>request</parameter></term>
|
||||
<listitem>
|
||||
<para>MEDIA_IOC_ENUM_ENTITIES</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
<varlistentry>
|
||||
<term><parameter>argp</parameter></term>
|
||||
<listitem>
|
||||
<para></para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
</variablelist>
|
||||
</refsect1>
|
||||
|
||||
<refsect1>
|
||||
<title>Description</title>
|
||||
<para>To query the attributes of an entity, applications set the id field
|
||||
of a &media-entity-desc; structure and call the MEDIA_IOC_ENUM_ENTITIES
|
||||
ioctl with a pointer to this structure. The driver fills the rest of the
|
||||
structure or returns an &EINVAL; when the id is invalid.</para>
|
||||
<para>Entities can be enumerated by or'ing the id with the
|
||||
<constant>MEDIA_ENT_ID_FLAG_NEXT</constant> flag. The driver will return
|
||||
information about the entity with the smallest id strictly larger than the
|
||||
requested one ('next entity'), or the &EINVAL; if there is none.</para>
|
||||
<para>Entity IDs can be non-contiguous. Applications must
|
||||
<emphasis>not</emphasis> try to enumerate entities by calling
|
||||
MEDIA_IOC_ENUM_ENTITIES with increasing id's until they get an error.</para>
|
||||
<para>Two or more entities that share a common non-zero
|
||||
<structfield>group_id</structfield> value are considered as logically
|
||||
grouped. Groups are used to report
|
||||
<itemizedlist>
|
||||
<listitem><para>ALSA, VBI and video nodes that carry the same media
|
||||
stream</para></listitem>
|
||||
<listitem><para>lens and flash controllers associated with a sensor</para></listitem>
|
||||
</itemizedlist>
|
||||
</para>
|
||||
|
||||
<table pgwide="1" frame="none" id="media-entity-desc">
|
||||
<title>struct <structname>media_entity_desc</structname></title>
|
||||
<tgroup cols="5">
|
||||
<colspec colname="c1" />
|
||||
<colspec colname="c2" />
|
||||
<colspec colname="c3" />
|
||||
<colspec colname="c4" />
|
||||
<colspec colname="c5" />
|
||||
<tbody valign="top">
|
||||
<row>
|
||||
<entry>__u32</entry>
|
||||
<entry><structfield>id</structfield></entry>
|
||||
<entry></entry>
|
||||
<entry></entry>
|
||||
<entry>Entity id, set by the application. When the id is or'ed with
|
||||
<constant>MEDIA_ENT_ID_FLAG_NEXT</constant>, the driver clears the
|
||||
flag and returns the first entity with a larger id.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry>char</entry>
|
||||
<entry><structfield>name</structfield>[32]</entry>
|
||||
<entry></entry>
|
||||
<entry></entry>
|
||||
<entry>Entity name as an UTF-8 NULL-terminated string.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry>__u32</entry>
|
||||
<entry><structfield>type</structfield></entry>
|
||||
<entry></entry>
|
||||
<entry></entry>
|
||||
<entry>Entity type, see <xref linkend="media-entity-type" /> for details.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry>__u32</entry>
|
||||
<entry><structfield>revision</structfield></entry>
|
||||
<entry></entry>
|
||||
<entry></entry>
|
||||
<entry>Entity revision in a driver/hardware specific format.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry>__u32</entry>
|
||||
<entry><structfield>flags</structfield></entry>
|
||||
<entry></entry>
|
||||
<entry></entry>
|
||||
<entry>Entity flags, see <xref linkend="media-entity-flag" /> for details.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry>__u32</entry>
|
||||
<entry><structfield>group_id</structfield></entry>
|
||||
<entry></entry>
|
||||
<entry></entry>
|
||||
<entry>Entity group ID</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry>__u16</entry>
|
||||
<entry><structfield>pads</structfield></entry>
|
||||
<entry></entry>
|
||||
<entry></entry>
|
||||
<entry>Number of pads</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry>__u16</entry>
|
||||
<entry><structfield>links</structfield></entry>
|
||||
<entry></entry>
|
||||
<entry></entry>
|
||||
<entry>Total number of outbound links. Inbound links are not counted
|
||||
in this field.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry>union</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry></entry>
|
||||
<entry>struct</entry>
|
||||
<entry><structfield>v4l</structfield></entry>
|
||||
<entry></entry>
|
||||
<entry>Valid for V4L sub-devices and nodes only.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry></entry>
|
||||
<entry></entry>
|
||||
<entry>__u32</entry>
|
||||
<entry><structfield>major</structfield></entry>
|
||||
<entry>V4L device node major number. For V4L sub-devices with no
|
||||
device node, set by the driver to 0.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry></entry>
|
||||
<entry></entry>
|
||||
<entry>__u32</entry>
|
||||
<entry><structfield>minor</structfield></entry>
|
||||
<entry>V4L device node minor number. For V4L sub-devices with no
|
||||
device node, set by the driver to 0.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry></entry>
|
||||
<entry>struct</entry>
|
||||
<entry><structfield>fb</structfield></entry>
|
||||
<entry></entry>
|
||||
<entry>Valid for frame buffer nodes only.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry></entry>
|
||||
<entry></entry>
|
||||
<entry>__u32</entry>
|
||||
<entry><structfield>major</structfield></entry>
|
||||
<entry>Frame buffer device node major number.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry></entry>
|
||||
<entry></entry>
|
||||
<entry>__u32</entry>
|
||||
<entry><structfield>minor</structfield></entry>
|
||||
<entry>Frame buffer device node minor number.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry></entry>
|
||||
<entry>struct</entry>
|
||||
<entry><structfield>alsa</structfield></entry>
|
||||
<entry></entry>
|
||||
<entry>Valid for ALSA devices only.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry></entry>
|
||||
<entry></entry>
|
||||
<entry>__u32</entry>
|
||||
<entry><structfield>card</structfield></entry>
|
||||
<entry>ALSA card number</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry></entry>
|
||||
<entry></entry>
|
||||
<entry>__u32</entry>
|
||||
<entry><structfield>device</structfield></entry>
|
||||
<entry>ALSA device number</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry></entry>
|
||||
<entry></entry>
|
||||
<entry>__u32</entry>
|
||||
<entry><structfield>subdevice</structfield></entry>
|
||||
<entry>ALSA sub-device number</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry></entry>
|
||||
<entry>int</entry>
|
||||
<entry><structfield>dvb</structfield></entry>
|
||||
<entry></entry>
|
||||
<entry>DVB card number</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry></entry>
|
||||
<entry>__u8</entry>
|
||||
<entry><structfield>raw</structfield>[180]</entry>
|
||||
<entry></entry>
|
||||
<entry></entry>
|
||||
</row>
|
||||
</tbody>
|
||||
</tgroup>
|
||||
</table>
|
||||
|
||||
<table frame="none" pgwide="1" id="media-entity-type">
|
||||
<title>Media entity types</title>
|
||||
<tgroup cols="2">
|
||||
<colspec colname="c1"/>
|
||||
<colspec colname="c2"/>
|
||||
<tbody valign="top">
|
||||
<row>
|
||||
<entry><constant>MEDIA_ENT_T_DEVNODE</constant></entry>
|
||||
<entry>Unknown device node</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry><constant>MEDIA_ENT_T_DEVNODE_V4L</constant></entry>
|
||||
<entry>V4L video, radio or vbi device node</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry><constant>MEDIA_ENT_T_DEVNODE_FB</constant></entry>
|
||||
<entry>Frame buffer device node</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry><constant>MEDIA_ENT_T_DEVNODE_ALSA</constant></entry>
|
||||
<entry>ALSA card</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry><constant>MEDIA_ENT_T_DEVNODE_DVB</constant></entry>
|
||||
<entry>DVB card</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry><constant>MEDIA_ENT_T_V4L2_SUBDEV</constant></entry>
|
||||
<entry>Unknown V4L sub-device</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry><constant>MEDIA_ENT_T_V4L2_SUBDEV_SENSOR</constant></entry>
|
||||
<entry>Video sensor</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry><constant>MEDIA_ENT_T_V4L2_SUBDEV_FLASH</constant></entry>
|
||||
<entry>Flash controller</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry><constant>MEDIA_ENT_T_V4L2_SUBDEV_LENS</constant></entry>
|
||||
<entry>Lens controller</entry>
|
||||
</row>
|
||||
</tbody>
|
||||
</tgroup>
|
||||
</table>
|
||||
|
||||
<table frame="none" pgwide="1" id="media-entity-flag">
|
||||
<title>Media entity flags</title>
|
||||
<tgroup cols="2">
|
||||
<colspec colname="c1"/>
|
||||
<colspec colname="c2"/>
|
||||
<tbody valign="top">
|
||||
<row>
|
||||
<entry><constant>MEDIA_ENT_FL_DEFAULT</constant></entry>
|
||||
<entry>Default entity for its type. Used to discover the default
|
||||
audio, VBI and video devices, the default camera sensor, ...</entry>
|
||||
</row>
|
||||
</tbody>
|
||||
</tgroup>
|
||||
</table>
|
||||
</refsect1>
|
||||
|
||||
<refsect1>
|
||||
&return-value;
|
||||
|
||||
<variablelist>
|
||||
<varlistentry>
|
||||
<term><errorcode>EINVAL</errorcode></term>
|
||||
<listitem>
|
||||
<para>The &media-entity-desc; <structfield>id</structfield> references
|
||||
a non-existing entity.</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
</variablelist>
|
||||
</refsect1>
|
||||
</refentry>
|
||||
|
|
@ -0,0 +1,207 @@
|
|||
<refentry id="media-ioc-enum-links">
|
||||
<refmeta>
|
||||
<refentrytitle>ioctl MEDIA_IOC_ENUM_LINKS</refentrytitle>
|
||||
&manvol;
|
||||
</refmeta>
|
||||
|
||||
<refnamediv>
|
||||
<refname>MEDIA_IOC_ENUM_LINKS</refname>
|
||||
<refpurpose>Enumerate all pads and links for a given entity</refpurpose>
|
||||
</refnamediv>
|
||||
|
||||
<refsynopsisdiv>
|
||||
<funcsynopsis>
|
||||
<funcprototype>
|
||||
<funcdef>int <function>ioctl</function></funcdef>
|
||||
<paramdef>int <parameter>fd</parameter></paramdef>
|
||||
<paramdef>int <parameter>request</parameter></paramdef>
|
||||
<paramdef>struct media_links_enum *<parameter>argp</parameter></paramdef>
|
||||
</funcprototype>
|
||||
</funcsynopsis>
|
||||
</refsynopsisdiv>
|
||||
|
||||
<refsect1>
|
||||
<title>Arguments</title>
|
||||
|
||||
<variablelist>
|
||||
<varlistentry>
|
||||
<term><parameter>fd</parameter></term>
|
||||
<listitem>
|
||||
<para>File descriptor returned by
|
||||
<link linkend='media-func-open'><function>open()</function></link>.</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
<varlistentry>
|
||||
<term><parameter>request</parameter></term>
|
||||
<listitem>
|
||||
<para>MEDIA_IOC_ENUM_LINKS</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
<varlistentry>
|
||||
<term><parameter>argp</parameter></term>
|
||||
<listitem>
|
||||
<para></para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
</variablelist>
|
||||
</refsect1>
|
||||
|
||||
<refsect1>
|
||||
<title>Description</title>
|
||||
|
||||
<para>To enumerate pads and/or links for a given entity, applications set
|
||||
the entity field of a &media-links-enum; structure and initialize the
|
||||
&media-pad-desc; and &media-link-desc; structure arrays pointed by the
|
||||
<structfield>pads</structfield> and <structfield>links</structfield> fields.
|
||||
They then call the MEDIA_IOC_ENUM_LINKS ioctl with a pointer to this
|
||||
structure.</para>
|
||||
<para>If the <structfield>pads</structfield> field is not NULL, the driver
|
||||
fills the <structfield>pads</structfield> array with information about the
|
||||
entity's pads. The array must have enough room to store all the entity's
|
||||
pads. The number of pads can be retrieved with the &MEDIA-IOC-ENUM-ENTITIES;
|
||||
ioctl.</para>
|
||||
<para>If the <structfield>links</structfield> field is not NULL, the driver
|
||||
fills the <structfield>links</structfield> array with information about the
|
||||
entity's outbound links. The array must have enough room to store all the
|
||||
entity's outbound links. The number of outbound links can be retrieved with
|
||||
the &MEDIA-IOC-ENUM-ENTITIES; ioctl.</para>
|
||||
<para>Only forward links that originate at one of the entity's source pads
|
||||
are returned during the enumeration process.</para>
|
||||
|
||||
<table pgwide="1" frame="none" id="media-links-enum">
|
||||
<title>struct <structname>media_links_enum</structname></title>
|
||||
<tgroup cols="3">
|
||||
&cs-str;
|
||||
<tbody valign="top">
|
||||
<row>
|
||||
<entry>__u32</entry>
|
||||
<entry><structfield>entity</structfield></entry>
|
||||
<entry>Entity id, set by the application.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry>struct &media-pad-desc;</entry>
|
||||
<entry>*<structfield>pads</structfield></entry>
|
||||
<entry>Pointer to a pads array allocated by the application. Ignored
|
||||
if NULL.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry>struct &media-link-desc;</entry>
|
||||
<entry>*<structfield>links</structfield></entry>
|
||||
<entry>Pointer to a links array allocated by the application. Ignored
|
||||
if NULL.</entry>
|
||||
</row>
|
||||
</tbody>
|
||||
</tgroup>
|
||||
</table>
|
||||
|
||||
<table pgwide="1" frame="none" id="media-pad-desc">
|
||||
<title>struct <structname>media_pad_desc</structname></title>
|
||||
<tgroup cols="3">
|
||||
&cs-str;
|
||||
<tbody valign="top">
|
||||
<row>
|
||||
<entry>__u32</entry>
|
||||
<entry><structfield>entity</structfield></entry>
|
||||
<entry>ID of the entity this pad belongs to.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry>__u16</entry>
|
||||
<entry><structfield>index</structfield></entry>
|
||||
<entry>0-based pad index.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry>__u32</entry>
|
||||
<entry><structfield>flags</structfield></entry>
|
||||
<entry>Pad flags, see <xref linkend="media-pad-flag" /> for more details.</entry>
|
||||
</row>
|
||||
</tbody>
|
||||
</tgroup>
|
||||
</table>
|
||||
|
||||
<table frame="none" pgwide="1" id="media-pad-flag">
|
||||
<title>Media pad flags</title>
|
||||
<tgroup cols="2">
|
||||
<colspec colname="c1"/>
|
||||
<colspec colname="c2"/>
|
||||
<tbody valign="top">
|
||||
<row>
|
||||
<entry><constant>MEDIA_PAD_FL_SINK</constant></entry>
|
||||
<entry>Input pad, relative to the entity. Input pads sink data and
|
||||
are targets of links.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry><constant>MEDIA_PAD_FL_SOURCE</constant></entry>
|
||||
<entry>Output pad, relative to the entity. Output pads source data
|
||||
and are origins of links.</entry>
|
||||
</row>
|
||||
</tbody>
|
||||
</tgroup>
|
||||
</table>
|
||||
|
||||
<table pgwide="1" frame="none" id="media-link-desc">
|
||||
<title>struct <structname>media_links_desc</structname></title>
|
||||
<tgroup cols="3">
|
||||
&cs-str;
|
||||
<tbody valign="top">
|
||||
<row>
|
||||
<entry>struct &media-pad-desc;</entry>
|
||||
<entry><structfield>source</structfield></entry>
|
||||
<entry>Pad at the origin of this link.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry>struct &media-pad-desc;</entry>
|
||||
<entry><structfield>sink</structfield></entry>
|
||||
<entry>Pad at the target of this link.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry>__u32</entry>
|
||||
<entry><structfield>flags</structfield></entry>
|
||||
<entry>Link flags, see <xref linkend="media-link-flag" /> for more details.</entry>
|
||||
</row>
|
||||
</tbody>
|
||||
</tgroup>
|
||||
</table>
|
||||
|
||||
<table frame="none" pgwide="1" id="media-link-flag">
|
||||
<title>Media link flags</title>
|
||||
<tgroup cols="2">
|
||||
<colspec colname="c1"/>
|
||||
<colspec colname="c2"/>
|
||||
<tbody valign="top">
|
||||
<row>
|
||||
<entry><constant>MEDIA_LNK_FL_ENABLED</constant></entry>
|
||||
<entry>The link is enabled and can be used to transfer media data.
|
||||
When two or more links target a sink pad, only one of them can be
|
||||
enabled at a time.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry><constant>MEDIA_LNK_FL_IMMUTABLE</constant></entry>
|
||||
<entry>The link enabled state can't be modified at runtime. An
|
||||
immutable link is always enabled.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry><constant>MEDIA_LNK_FL_DYNAMIC</constant></entry>
|
||||
<entry>The link enabled state can be modified during streaming. This
|
||||
flag is set by drivers and is read-only for applications.</entry>
|
||||
</row>
|
||||
</tbody>
|
||||
</tgroup>
|
||||
</table>
|
||||
<para>One and only one of <constant>MEDIA_PAD_FL_SINK</constant> and
|
||||
<constant>MEDIA_PAD_FL_SOURCE</constant> must be set for every pad.</para>
|
||||
</refsect1>
|
||||
|
||||
<refsect1>
|
||||
&return-value;
|
||||
|
||||
<variablelist>
|
||||
<varlistentry>
|
||||
<term><errorcode>EINVAL</errorcode></term>
|
||||
<listitem>
|
||||
<para>The &media-links-enum; <structfield>id</structfield> references
|
||||
a non-existing entity.</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
</variablelist>
|
||||
</refsect1>
|
||||
</refentry>
|
||||
|
|
@ -0,0 +1,93 @@
|
|||
<refentry id="media-ioc-setup-link">
|
||||
<refmeta>
|
||||
<refentrytitle>ioctl MEDIA_IOC_SETUP_LINK</refentrytitle>
|
||||
&manvol;
|
||||
</refmeta>
|
||||
|
||||
<refnamediv>
|
||||
<refname>MEDIA_IOC_SETUP_LINK</refname>
|
||||
<refpurpose>Modify the properties of a link</refpurpose>
|
||||
</refnamediv>
|
||||
|
||||
<refsynopsisdiv>
|
||||
<funcsynopsis>
|
||||
<funcprototype>
|
||||
<funcdef>int <function>ioctl</function></funcdef>
|
||||
<paramdef>int <parameter>fd</parameter></paramdef>
|
||||
<paramdef>int <parameter>request</parameter></paramdef>
|
||||
<paramdef>struct media_link_desc *<parameter>argp</parameter></paramdef>
|
||||
</funcprototype>
|
||||
</funcsynopsis>
|
||||
</refsynopsisdiv>
|
||||
|
||||
<refsect1>
|
||||
<title>Arguments</title>
|
||||
|
||||
<variablelist>
|
||||
<varlistentry>
|
||||
<term><parameter>fd</parameter></term>
|
||||
<listitem>
|
||||
<para>File descriptor returned by
|
||||
<link linkend='media-func-open'><function>open()</function></link>.</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
<varlistentry>
|
||||
<term><parameter>request</parameter></term>
|
||||
<listitem>
|
||||
<para>MEDIA_IOC_ENUM_LINKS</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
<varlistentry>
|
||||
<term><parameter>argp</parameter></term>
|
||||
<listitem>
|
||||
<para></para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
</variablelist>
|
||||
</refsect1>
|
||||
|
||||
<refsect1>
|
||||
<title>Description</title>
|
||||
|
||||
<para>To change link properties applications fill a &media-link-desc; with
|
||||
link identification information (source and sink pad) and the new requested
|
||||
link flags. They then call the MEDIA_IOC_SETUP_LINK ioctl with a pointer to
|
||||
that structure.</para>
|
||||
<para>The only configurable property is the <constant>ENABLED</constant>
|
||||
link flag to enable/disable a link. Links marked with the
|
||||
<constant>IMMUTABLE</constant> link flag can not be enabled or disabled.
|
||||
</para>
|
||||
<para>Link configuration has no side effect on other links. If an enabled
|
||||
link at the sink pad prevents the link from being enabled, the driver
|
||||
returns with an &EBUSY;.</para>
|
||||
<para>Only links marked with the <constant>DYNAMIC</constant> link flag can
|
||||
be enabled/disabled while streaming media data. Attempting to enable or
|
||||
disable a streaming non-dynamic link will return an &EBUSY;.</para>
|
||||
<para>If the specified link can't be found the driver returns with an
|
||||
&EINVAL;.</para>
|
||||
</refsect1>
|
||||
|
||||
<refsect1>
|
||||
&return-value;
|
||||
|
||||
<variablelist>
|
||||
<varlistentry>
|
||||
<term><errorcode>EBUSY</errorcode></term>
|
||||
<listitem>
|
||||
<para>The link properties can't be changed because the link is
|
||||
currently busy. This can be caused, for instance, by an active media
|
||||
stream (audio or video) on the link. The ioctl shouldn't be retried if
|
||||
no other action is performed before to fix the problem.</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
<varlistentry>
|
||||
<term><errorcode>EINVAL</errorcode></term>
|
||||
<listitem>
|
||||
<para>The &media-link-desc; references a non-existing link, or the
|
||||
link is immutable and an attempt to modify its configuration was made.
|
||||
</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
</variablelist>
|
||||
</refsect1>
|
||||
</refentry>
|
||||
Двоичный файл не отображается.
|
После Ширина: | Высота: | Размер: 2.1 KiB |
Двоичный файл не отображается.
|
После Ширина: | Высота: | Размер: 6.7 KiB |
Двоичный файл не отображается.
Двоичный файл не отображается.
|
После Ширина: | Высота: | Размер: 12 KiB |
|
|
@ -0,0 +1,154 @@
|
|||
<refentry id="V4L2-PIX-FMT-NV12M">
|
||||
<refmeta>
|
||||
<refentrytitle>V4L2_PIX_FMT_NV12M ('NV12M')</refentrytitle>
|
||||
&manvol;
|
||||
</refmeta>
|
||||
<refnamediv>
|
||||
<refname> <constant>V4L2_PIX_FMT_NV12M</constant></refname>
|
||||
<refpurpose>Variation of <constant>V4L2_PIX_FMT_NV12</constant> with planes
|
||||
non contiguous in memory. </refpurpose>
|
||||
</refnamediv>
|
||||
<refsect1>
|
||||
<title>Description</title>
|
||||
|
||||
<para>This is a multi-planar, two-plane version of the YUV 4:2:0 format.
|
||||
The three components are separated into two sub-images or planes.
|
||||
<constant>V4L2_PIX_FMT_NV12M</constant> differs from <constant>V4L2_PIX_FMT_NV12
|
||||
</constant> in that the two planes are non-contiguous in memory, i.e. the chroma
|
||||
plane do not necessarily immediately follows the luma plane.
|
||||
The luminance data occupies the first plane. The Y plane has one byte per pixel.
|
||||
In the second plane there is a chrominance data with alternating chroma samples.
|
||||
The CbCr plane is the same width, in bytes, as the Y plane (and of the image),
|
||||
but is half as tall in pixels. Each CbCr pair belongs to four pixels. For example,
|
||||
Cb<subscript>0</subscript>/Cr<subscript>0</subscript> belongs to
|
||||
Y'<subscript>00</subscript>, Y'<subscript>01</subscript>,
|
||||
Y'<subscript>10</subscript>, Y'<subscript>11</subscript>. </para>
|
||||
|
||||
<para><constant>V4L2_PIX_FMT_NV12M</constant> is intended to be
|
||||
used only in drivers and applications that support the multi-planar API,
|
||||
described in <xref linkend="planar-apis"/>. </para>
|
||||
|
||||
<para>If the Y plane has pad bytes after each row, then the
|
||||
CbCr plane has as many pad bytes after its rows.</para>
|
||||
|
||||
<example>
|
||||
<title><constant>V4L2_PIX_FMT_NV12M</constant> 4 × 4 pixel image</title>
|
||||
|
||||
<formalpara>
|
||||
<title>Byte Order.</title>
|
||||
<para>Each cell is one byte.
|
||||
<informaltable frame="none">
|
||||
<tgroup cols="5" align="center">
|
||||
<colspec align="left" colwidth="2*" />
|
||||
<tbody valign="top">
|
||||
<row>
|
||||
<entry>start0 + 0:</entry>
|
||||
<entry>Y'<subscript>00</subscript></entry>
|
||||
<entry>Y'<subscript>01</subscript></entry>
|
||||
<entry>Y'<subscript>02</subscript></entry>
|
||||
<entry>Y'<subscript>03</subscript></entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry>start0 + 4:</entry>
|
||||
<entry>Y'<subscript>10</subscript></entry>
|
||||
<entry>Y'<subscript>11</subscript></entry>
|
||||
<entry>Y'<subscript>12</subscript></entry>
|
||||
<entry>Y'<subscript>13</subscript></entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry>start0 + 8:</entry>
|
||||
<entry>Y'<subscript>20</subscript></entry>
|
||||
<entry>Y'<subscript>21</subscript></entry>
|
||||
<entry>Y'<subscript>22</subscript></entry>
|
||||
<entry>Y'<subscript>23</subscript></entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry>start0 + 12:</entry>
|
||||
<entry>Y'<subscript>30</subscript></entry>
|
||||
<entry>Y'<subscript>31</subscript></entry>
|
||||
<entry>Y'<subscript>32</subscript></entry>
|
||||
<entry>Y'<subscript>33</subscript></entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry></entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry>start1 + 0:</entry>
|
||||
<entry>Cb<subscript>00</subscript></entry>
|
||||
<entry>Cr<subscript>00</subscript></entry>
|
||||
<entry>Cb<subscript>01</subscript></entry>
|
||||
<entry>Cr<subscript>01</subscript></entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry>start1 + 4:</entry>
|
||||
<entry>Cb<subscript>10</subscript></entry>
|
||||
<entry>Cr<subscript>10</subscript></entry>
|
||||
<entry>Cb<subscript>11</subscript></entry>
|
||||
<entry>Cr<subscript>11</subscript></entry>
|
||||
</row>
|
||||
</tbody>
|
||||
</tgroup>
|
||||
</informaltable>
|
||||
</para>
|
||||
</formalpara>
|
||||
|
||||
<formalpara>
|
||||
<title>Color Sample Location.</title>
|
||||
<para>
|
||||
<informaltable frame="none">
|
||||
<tgroup cols="7" align="center">
|
||||
<tbody valign="top">
|
||||
<row>
|
||||
<entry></entry>
|
||||
<entry>0</entry><entry></entry><entry>1</entry><entry></entry>
|
||||
<entry>2</entry><entry></entry><entry>3</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry>0</entry>
|
||||
<entry>Y</entry><entry></entry><entry>Y</entry><entry></entry>
|
||||
<entry>Y</entry><entry></entry><entry>Y</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry></entry>
|
||||
<entry></entry><entry>C</entry><entry></entry><entry></entry>
|
||||
<entry></entry><entry>C</entry><entry></entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry>1</entry>
|
||||
<entry>Y</entry><entry></entry><entry>Y</entry><entry></entry>
|
||||
<entry>Y</entry><entry></entry><entry>Y</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry></entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry>2</entry>
|
||||
<entry>Y</entry><entry></entry><entry>Y</entry><entry></entry>
|
||||
<entry>Y</entry><entry></entry><entry>Y</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry></entry>
|
||||
<entry></entry><entry>C</entry><entry></entry><entry></entry>
|
||||
<entry></entry><entry>C</entry><entry></entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry>3</entry>
|
||||
<entry>Y</entry><entry></entry><entry>Y</entry><entry></entry>
|
||||
<entry>Y</entry><entry></entry><entry>Y</entry>
|
||||
</row>
|
||||
</tbody>
|
||||
</tgroup>
|
||||
</informaltable>
|
||||
</para>
|
||||
</formalpara>
|
||||
</example>
|
||||
</refsect1>
|
||||
</refentry>
|
||||
|
||||
<!--
|
||||
Local Variables:
|
||||
mode: sgml
|
||||
sgml-parent-document: "pixfmt.sgml"
|
||||
indent-tabs-mode: nil
|
||||
End:
|
||||
-->
|
||||
|
|
@ -0,0 +1,74 @@
|
|||
<refentry>
|
||||
<refmeta>
|
||||
<refentrytitle>V4L2_PIX_FMT_NV12MT ('TM12')</refentrytitle>
|
||||
&manvol;
|
||||
</refmeta>
|
||||
<refnamediv>
|
||||
<refname id="V4L2-PIX-FMT-NV12MT"><constant>V4L2_PIX_FMT_NV12MT
|
||||
</constant></refname>
|
||||
<refpurpose>Formats with ½ horizontal and vertical
|
||||
chroma resolution. This format has two planes - one for luminance and one for
|
||||
chrominance. Chroma samples are interleaved. The difference to
|
||||
<constant>V4L2_PIX_FMT_NV12</constant> is the memory layout. Pixels are
|
||||
grouped in macroblocks of 64x32 size. The order of macroblocks in memory is
|
||||
also not standard.
|
||||
</refpurpose>
|
||||
</refnamediv>
|
||||
<refsect1>
|
||||
<title>Description</title>
|
||||
|
||||
<para>This is the two-plane versions of the YUV 4:2:0 format where data
|
||||
is grouped into 64x32 macroblocks. The three components are separated into two
|
||||
sub-images or planes. The Y plane has one byte per pixel and pixels are grouped
|
||||
into 64x32 macroblocks. The CbCr plane has the same width, in bytes, as the Y
|
||||
plane (and the image), but is half as tall in pixels. The chroma plane is also
|
||||
grouped into 64x32 macroblocks.</para>
|
||||
<para>Width of the buffer has to be aligned to the multiple of 128, and
|
||||
height alignment is 32. Every four adjactent buffers - two horizontally and two
|
||||
vertically are grouped together and are located in memory in Z or flipped Z
|
||||
order. </para>
|
||||
<para>Layout of macroblocks in memory is presented in the following
|
||||
figure.</para>
|
||||
<para><figure id="nv12mt">
|
||||
<title><constant>V4L2_PIX_FMT_NV12MT</constant> macroblock Z shape
|
||||
memory layout</title>
|
||||
<mediaobject>
|
||||
<imageobject>
|
||||
<imagedata fileref="nv12mt.gif" format="GIF" />
|
||||
</imageobject>
|
||||
</mediaobject>
|
||||
</figure>
|
||||
The requirement that width is multiple of 128 is implemented because,
|
||||
the Z shape cannot be cut in half horizontally. In case the vertical resolution
|
||||
of macroblocks is odd then the last row of macroblocks is arranged in a linear
|
||||
order. </para>
|
||||
<para>In case of chroma the layout is identical. Cb and Cr samples are
|
||||
interleaved. Height of the buffer is aligned to 32.
|
||||
</para>
|
||||
<example>
|
||||
<title>Memory layout of macroblocks in <constant>V4L2_PIX_FMT_NV12
|
||||
</constant> format pixel image - extreme case</title>
|
||||
<para>
|
||||
<figure id="nv12mt_ex">
|
||||
<title>Example <constant>V4L2_PIX_FMT_NV12MT</constant> memory
|
||||
layout of macroblocks</title>
|
||||
<mediaobject>
|
||||
<imageobject>
|
||||
<imagedata fileref="nv12mt_example.gif" format="GIF" />
|
||||
</imageobject>
|
||||
</mediaobject>
|
||||
</figure>
|
||||
Memory layout of macroblocks of <constant>V4L2_PIX_FMT_NV12MT
|
||||
</constant> format in most extreme case.
|
||||
</para>
|
||||
</example>
|
||||
</refsect1>
|
||||
</refentry>
|
||||
|
||||
<!--
|
||||
Local Variables:
|
||||
mode: sgml
|
||||
sgml-parent-document: "pixfmt.sgml"
|
||||
indent-tabs-mode: nil
|
||||
End:
|
||||
-->
|
||||
|
|
@ -0,0 +1,90 @@
|
|||
<refentry>
|
||||
<refmeta>
|
||||
<refentrytitle>V4L2_PIX_FMT_SRGGB12 ('RG12'),
|
||||
V4L2_PIX_FMT_SGRBG12 ('BA12'),
|
||||
V4L2_PIX_FMT_SGBRG12 ('GB12'),
|
||||
V4L2_PIX_FMT_SBGGR12 ('BG12'),
|
||||
</refentrytitle>
|
||||
&manvol;
|
||||
</refmeta>
|
||||
<refnamediv>
|
||||
<refname id="V4L2-PIX-FMT-SRGGB12"><constant>V4L2_PIX_FMT_SRGGB12</constant></refname>
|
||||
<refname id="V4L2-PIX-FMT-SGRBG12"><constant>V4L2_PIX_FMT_SGRBG12</constant></refname>
|
||||
<refname id="V4L2-PIX-FMT-SGBRG12"><constant>V4L2_PIX_FMT_SGBRG12</constant></refname>
|
||||
<refname id="V4L2-PIX-FMT-SBGGR12"><constant>V4L2_PIX_FMT_SBGGR12</constant></refname>
|
||||
<refpurpose>12-bit Bayer formats expanded to 16 bits</refpurpose>
|
||||
</refnamediv>
|
||||
<refsect1>
|
||||
<title>Description</title>
|
||||
|
||||
<para>The following four pixel formats are raw sRGB / Bayer formats with
|
||||
12 bits per colour. Each colour component is stored in a 16-bit word, with 6
|
||||
unused high bits filled with zeros. Each n-pixel row contains n/2 green samples
|
||||
and n/2 blue or red samples, with alternating red and blue rows. Bytes are
|
||||
stored in memory in little endian order. They are conventionally described
|
||||
as GRGR... BGBG..., RGRG... GBGB..., etc. Below is an example of one of these
|
||||
formats</para>
|
||||
|
||||
<example>
|
||||
<title><constant>V4L2_PIX_FMT_SBGGR12</constant> 4 × 4
|
||||
pixel image</title>
|
||||
|
||||
<formalpara>
|
||||
<title>Byte Order.</title>
|
||||
<para>Each cell is one byte, high 6 bits in high bytes are 0.
|
||||
<informaltable frame="none">
|
||||
<tgroup cols="5" align="center">
|
||||
<colspec align="left" colwidth="2*" />
|
||||
<tbody valign="top">
|
||||
<row>
|
||||
<entry>start + 0:</entry>
|
||||
<entry>B<subscript>00low</subscript></entry>
|
||||
<entry>B<subscript>00high</subscript></entry>
|
||||
<entry>G<subscript>01low</subscript></entry>
|
||||
<entry>G<subscript>01high</subscript></entry>
|
||||
<entry>B<subscript>02low</subscript></entry>
|
||||
<entry>B<subscript>02high</subscript></entry>
|
||||
<entry>G<subscript>03low</subscript></entry>
|
||||
<entry>G<subscript>03high</subscript></entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry>start + 8:</entry>
|
||||
<entry>G<subscript>10low</subscript></entry>
|
||||
<entry>G<subscript>10high</subscript></entry>
|
||||
<entry>R<subscript>11low</subscript></entry>
|
||||
<entry>R<subscript>11high</subscript></entry>
|
||||
<entry>G<subscript>12low</subscript></entry>
|
||||
<entry>G<subscript>12high</subscript></entry>
|
||||
<entry>R<subscript>13low</subscript></entry>
|
||||
<entry>R<subscript>13high</subscript></entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry>start + 16:</entry>
|
||||
<entry>B<subscript>20low</subscript></entry>
|
||||
<entry>B<subscript>20high</subscript></entry>
|
||||
<entry>G<subscript>21low</subscript></entry>
|
||||
<entry>G<subscript>21high</subscript></entry>
|
||||
<entry>B<subscript>22low</subscript></entry>
|
||||
<entry>B<subscript>22high</subscript></entry>
|
||||
<entry>G<subscript>23low</subscript></entry>
|
||||
<entry>G<subscript>23high</subscript></entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry>start + 24:</entry>
|
||||
<entry>G<subscript>30low</subscript></entry>
|
||||
<entry>G<subscript>30high</subscript></entry>
|
||||
<entry>R<subscript>31low</subscript></entry>
|
||||
<entry>R<subscript>31high</subscript></entry>
|
||||
<entry>G<subscript>32low</subscript></entry>
|
||||
<entry>G<subscript>32high</subscript></entry>
|
||||
<entry>R<subscript>33low</subscript></entry>
|
||||
<entry>R<subscript>33high</subscript></entry>
|
||||
</row>
|
||||
</tbody>
|
||||
</tgroup>
|
||||
</informaltable>
|
||||
</para>
|
||||
</formalpara>
|
||||
</example>
|
||||
</refsect1>
|
||||
</refentry>
|
||||
|
|
@ -0,0 +1,162 @@
|
|||
<refentry id="V4L2-PIX-FMT-YUV420M">
|
||||
<refmeta>
|
||||
<refentrytitle>V4L2_PIX_FMT_YUV420M ('YU12M')</refentrytitle>
|
||||
&manvol;
|
||||
</refmeta>
|
||||
<refnamediv>
|
||||
<refname> <constant>V4L2_PIX_FMT_YUV420M</constant></refname>
|
||||
<refpurpose>Variation of <constant>V4L2_PIX_FMT_YUV420</constant>
|
||||
with planes non contiguous in memory. </refpurpose>
|
||||
</refnamediv>
|
||||
|
||||
<refsect1>
|
||||
<title>Description</title>
|
||||
|
||||
<para>This is a multi-planar format, as opposed to a packed format.
|
||||
The three components are separated into three sub- images or planes.
|
||||
|
||||
The Y plane is first. The Y plane has one byte per pixel. The Cb data
|
||||
constitutes the second plane which is half the width and half
|
||||
the height of the Y plane (and of the image). Each Cb belongs to four
|
||||
pixels, a two-by-two square of the image. For example,
|
||||
Cb<subscript>0</subscript> belongs to Y'<subscript>00</subscript>,
|
||||
Y'<subscript>01</subscript>, Y'<subscript>10</subscript>, and
|
||||
Y'<subscript>11</subscript>. The Cr data, just like the Cb plane, is
|
||||
in the third plane. </para>
|
||||
|
||||
<para>If the Y plane has pad bytes after each row, then the Cb
|
||||
and Cr planes have half as many pad bytes after their rows. In other
|
||||
words, two Cx rows (including padding) is exactly as long as one Y row
|
||||
(including padding).</para>
|
||||
|
||||
<para><constant>V4L2_PIX_FMT_NV12M</constant> is intended to be
|
||||
used only in drivers and applications that support the multi-planar API,
|
||||
described in <xref linkend="planar-apis"/>. </para>
|
||||
|
||||
<example>
|
||||
<title><constant>V4L2_PIX_FMT_YVU420M</constant> 4 × 4
|
||||
pixel image</title>
|
||||
|
||||
<formalpara>
|
||||
<title>Byte Order.</title>
|
||||
<para>Each cell is one byte.
|
||||
<informaltable frame="none">
|
||||
<tgroup cols="5" align="center">
|
||||
<colspec align="left" colwidth="2*" />
|
||||
<tbody valign="top">
|
||||
<row>
|
||||
<entry>start0 + 0:</entry>
|
||||
<entry>Y'<subscript>00</subscript></entry>
|
||||
<entry>Y'<subscript>01</subscript></entry>
|
||||
<entry>Y'<subscript>02</subscript></entry>
|
||||
<entry>Y'<subscript>03</subscript></entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry>start0 + 4:</entry>
|
||||
<entry>Y'<subscript>10</subscript></entry>
|
||||
<entry>Y'<subscript>11</subscript></entry>
|
||||
<entry>Y'<subscript>12</subscript></entry>
|
||||
<entry>Y'<subscript>13</subscript></entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry>start0 + 8:</entry>
|
||||
<entry>Y'<subscript>20</subscript></entry>
|
||||
<entry>Y'<subscript>21</subscript></entry>
|
||||
<entry>Y'<subscript>22</subscript></entry>
|
||||
<entry>Y'<subscript>23</subscript></entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry>start0 + 12:</entry>
|
||||
<entry>Y'<subscript>30</subscript></entry>
|
||||
<entry>Y'<subscript>31</subscript></entry>
|
||||
<entry>Y'<subscript>32</subscript></entry>
|
||||
<entry>Y'<subscript>33</subscript></entry>
|
||||
</row>
|
||||
<row><entry></entry></row>
|
||||
<row>
|
||||
<entry>start1 + 0:</entry>
|
||||
<entry>Cb<subscript>00</subscript></entry>
|
||||
<entry>Cb<subscript>01</subscript></entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry>start1 + 2:</entry>
|
||||
<entry>Cb<subscript>10</subscript></entry>
|
||||
<entry>Cb<subscript>11</subscript></entry>
|
||||
</row>
|
||||
<row><entry></entry></row>
|
||||
<row>
|
||||
<entry>start2 + 0:</entry>
|
||||
<entry>Cr<subscript>00</subscript></entry>
|
||||
<entry>Cr<subscript>01</subscript></entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry>start2 + 2:</entry>
|
||||
<entry>Cr<subscript>10</subscript></entry>
|
||||
<entry>Cr<subscript>11</subscript></entry>
|
||||
</row>
|
||||
</tbody>
|
||||
</tgroup>
|
||||
</informaltable>
|
||||
</para>
|
||||
</formalpara>
|
||||
|
||||
<formalpara>
|
||||
<title>Color Sample Location.</title>
|
||||
<para>
|
||||
<informaltable frame="none">
|
||||
<tgroup cols="7" align="center">
|
||||
<tbody valign="top">
|
||||
<row>
|
||||
<entry></entry>
|
||||
<entry>0</entry><entry></entry><entry>1</entry><entry></entry>
|
||||
<entry>2</entry><entry></entry><entry>3</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry>0</entry>
|
||||
<entry>Y</entry><entry></entry><entry>Y</entry><entry></entry>
|
||||
<entry>Y</entry><entry></entry><entry>Y</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry></entry>
|
||||
<entry></entry><entry>C</entry><entry></entry><entry></entry>
|
||||
<entry></entry><entry>C</entry><entry></entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry>1</entry>
|
||||
<entry>Y</entry><entry></entry><entry>Y</entry><entry></entry>
|
||||
<entry>Y</entry><entry></entry><entry>Y</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry></entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry>2</entry>
|
||||
<entry>Y</entry><entry></entry><entry>Y</entry><entry></entry>
|
||||
<entry>Y</entry><entry></entry><entry>Y</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry></entry>
|
||||
<entry></entry><entry>C</entry><entry></entry><entry></entry>
|
||||
<entry></entry><entry>C</entry><entry></entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry>3</entry>
|
||||
<entry>Y</entry><entry></entry><entry>Y</entry><entry></entry>
|
||||
<entry>Y</entry><entry></entry><entry>Y</entry>
|
||||
</row>
|
||||
</tbody>
|
||||
</tgroup>
|
||||
</informaltable>
|
||||
</para>
|
||||
</formalpara>
|
||||
</example>
|
||||
</refsect1>
|
||||
</refentry>
|
||||
|
||||
<!--
|
||||
Local Variables:
|
||||
mode: sgml
|
||||
sgml-parent-document: "pixfmt.sgml"
|
||||
indent-tabs-mode: nil
|
||||
End:
|
||||
-->
|
||||
|
|
@ -2,12 +2,16 @@
|
|||
|
||||
<para>The V4L2 API was primarily designed for devices exchanging
|
||||
image data with applications. The
|
||||
<structname>v4l2_pix_format</structname> structure defines the format
|
||||
and layout of an image in memory. Image formats are negotiated with
|
||||
the &VIDIOC-S-FMT; ioctl. (The explanations here focus on video
|
||||
<structname>v4l2_pix_format</structname> and <structname>v4l2_pix_format_mplane
|
||||
</structname> structures define the format and layout of an image in memory.
|
||||
The former is used with the single-planar API, while the latter is used with the
|
||||
multi-planar version (see <xref linkend="planar-apis"/>). Image formats are
|
||||
negotiated with the &VIDIOC-S-FMT; ioctl. (The explanations here focus on video
|
||||
capturing and output, for overlay frame buffer formats see also
|
||||
&VIDIOC-G-FBUF;.)</para>
|
||||
|
||||
<section>
|
||||
<title>Single-planar format structure</title>
|
||||
<table pgwide="1" frame="none" id="v4l2-pix-format">
|
||||
<title>struct <structname>v4l2_pix_format</structname></title>
|
||||
<tgroup cols="3">
|
||||
|
|
@ -106,6 +110,98 @@ set this field to zero.</entry>
|
|||
</tbody>
|
||||
</tgroup>
|
||||
</table>
|
||||
</section>
|
||||
|
||||
<section>
|
||||
<title>Multi-planar format structures</title>
|
||||
<para>The <structname>v4l2_plane_pix_format</structname> structures define
|
||||
size and layout for each of the planes in a multi-planar format.
|
||||
The <structname>v4l2_pix_format_mplane</structname> structure contains
|
||||
information common to all planes (such as image width and height) and
|
||||
an array of <structname>v4l2_plane_pix_format</structname> structures,
|
||||
describing all planes of that format.</para>
|
||||
<table pgwide="1" frame="none" id="v4l2-plane-pix-format">
|
||||
<title>struct <structname>vl42_plane_pix_format</structname></title>
|
||||
<tgroup cols="3">
|
||||
&cs-str;
|
||||
<tbody valign="top">
|
||||
<row>
|
||||
<entry>__u32</entry>
|
||||
<entry><structfield>sizeimage</structfield></entry>
|
||||
<entry>Maximum size in bytes required for image data in this plane.
|
||||
</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry>__u16</entry>
|
||||
<entry><structfield>bytesperline</structfield></entry>
|
||||
<entry>Distance in bytes between the leftmost pixels in two adjacent
|
||||
lines.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry>__u16</entry>
|
||||
<entry><structfield>reserved[7]</structfield></entry>
|
||||
<entry>Reserved for future extensions. Should be zeroed by the
|
||||
application.</entry>
|
||||
</row>
|
||||
</tbody>
|
||||
</tgroup>
|
||||
</table>
|
||||
<table pgwide="1" frame="none" id="v4l2-pix-format-mplane">
|
||||
<title>struct <structname>v4l2_pix_format_mplane</structname></title>
|
||||
<tgroup cols="3">
|
||||
&cs-str;
|
||||
<tbody valign="top">
|
||||
<row>
|
||||
<entry>__u32</entry>
|
||||
<entry><structfield>width</structfield></entry>
|
||||
<entry>Image width in pixels.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry>__u32</entry>
|
||||
<entry><structfield>height</structfield></entry>
|
||||
<entry>Image height in pixels.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry>__u32</entry>
|
||||
<entry><structfield>pixelformat</structfield></entry>
|
||||
<entry>The pixel format. Both single- and multi-planar four character
|
||||
codes can be used.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry>&v4l2-field;</entry>
|
||||
<entry><structfield>field</structfield></entry>
|
||||
<entry>See &v4l2-pix-format;.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry>&v4l2-colorspace;</entry>
|
||||
<entry><structfield>colorspace</structfield></entry>
|
||||
<entry>See &v4l2-pix-format;.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry>&v4l2-plane-pix-format;</entry>
|
||||
<entry><structfield>plane_fmt[VIDEO_MAX_PLANES]</structfield></entry>
|
||||
<entry>An array of structures describing format of each plane this
|
||||
pixel format consists of. The number of valid entries in this array
|
||||
has to be put in the <structfield>num_planes</structfield>
|
||||
field.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry>__u8</entry>
|
||||
<entry><structfield>num_planes</structfield></entry>
|
||||
<entry>Number of planes (i.e. separate memory buffers) for this format
|
||||
and the number of valid entries in the
|
||||
<structfield>plane_fmt</structfield> array.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry>__u8</entry>
|
||||
<entry><structfield>reserved[11]</structfield></entry>
|
||||
<entry>Reserved for future extensions. Should be zeroed by the
|
||||
application.</entry>
|
||||
</row>
|
||||
</tbody>
|
||||
</tgroup>
|
||||
</table>
|
||||
</section>
|
||||
|
||||
<section>
|
||||
<title>Standard Image Formats</title>
|
||||
|
|
@ -142,11 +238,19 @@ leftmost pixel of the second row from the top, and so on. The last row
|
|||
has just as many pad bytes after it as the other rows.</para>
|
||||
|
||||
<para>In V4L2 each format has an identifier which looks like
|
||||
<constant>PIX_FMT_XXX</constant>, defined in the <filename>videodev2.h</filename>
|
||||
header file. These identifiers
|
||||
represent <link linkend="v4l2-fourcc">four character codes</link>
|
||||
<constant>PIX_FMT_XXX</constant>, defined in the <link
|
||||
linkend="videodev">videodev.h</link> header file. These identifiers
|
||||
represent <link linkend="v4l2-fourcc">four character (FourCC) codes</link>
|
||||
which are also listed below, however they are not the same as those
|
||||
used in the Windows world.</para>
|
||||
|
||||
<para>For some formats, data is stored in separate, discontiguous
|
||||
memory buffers. Those formats are identified by a separate set of FourCC codes
|
||||
and are referred to as "multi-planar formats". For example, a YUV422 frame is
|
||||
normally stored in one memory buffer, but it can also be placed in two or three
|
||||
separate buffers, with Y component in one buffer and CbCr components in another
|
||||
in the 2-planar version or with each component in its own buffer in the
|
||||
3-planar case. Those sub-buffers are referred to as "planes".</para>
|
||||
</section>
|
||||
|
||||
<section id="colorspaces">
|
||||
|
|
@ -599,10 +703,13 @@ information.</para>
|
|||
&sub-vyuy;
|
||||
&sub-y41p;
|
||||
&sub-yuv420;
|
||||
&sub-yuv420m;
|
||||
&sub-yuv410;
|
||||
&sub-yuv422p;
|
||||
&sub-yuv411p;
|
||||
&sub-nv12;
|
||||
&sub-nv12m;
|
||||
&sub-nv12mt;
|
||||
&sub-nv16;
|
||||
</section>
|
||||
|
||||
|
|
|
|||
|
|
@ -0,0 +1,62 @@
|
|||
<section id="planar-apis">
|
||||
<title>Single- and multi-planar APIs</title>
|
||||
|
||||
<para>Some devices require data for each input or output video frame
|
||||
to be placed in discontiguous memory buffers. In such cases, one
|
||||
video frame has to be addressed using more than one memory address, i.e. one
|
||||
pointer per "plane". A plane is a sub-buffer of the current frame. For
|
||||
examples of such formats see <xref linkend="pixfmt" />.</para>
|
||||
|
||||
<para>Initially, V4L2 API did not support multi-planar buffers and a set of
|
||||
extensions has been introduced to handle them. Those extensions constitute
|
||||
what is being referred to as the "multi-planar API".</para>
|
||||
|
||||
<para>Some of the V4L2 API calls and structures are interpreted differently,
|
||||
depending on whether single- or multi-planar API is being used. An application
|
||||
can choose whether to use one or the other by passing a corresponding buffer
|
||||
type to its ioctl calls. Multi-planar versions of buffer types are suffixed
|
||||
with an `_MPLANE' string. For a list of available multi-planar buffer types
|
||||
see &v4l2-buf-type;.
|
||||
</para>
|
||||
|
||||
<section>
|
||||
<title>Multi-planar formats</title>
|
||||
<para>Multi-planar API introduces new multi-planar formats. Those formats
|
||||
use a separate set of FourCC codes. It is important to distinguish between
|
||||
the multi-planar API and a multi-planar format. Multi-planar API calls can
|
||||
handle all single-planar formats as well (as long as they are passed in
|
||||
multi-planar API structures), while the single-planar API cannot
|
||||
handle multi-planar formats.</para>
|
||||
</section>
|
||||
|
||||
<section>
|
||||
<title>Calls that distinguish between single and multi-planar APIs</title>
|
||||
<variablelist>
|
||||
<varlistentry>
|
||||
<term>&VIDIOC-QUERYCAP;</term>
|
||||
<listitem><para>Two additional multi-planar capabilities are added. They can
|
||||
be set together with non-multi-planar ones for devices that handle
|
||||
both single- and multi-planar formats.</para></listitem>
|
||||
</varlistentry>
|
||||
<varlistentry>
|
||||
<term>&VIDIOC-G-FMT;, &VIDIOC-S-FMT;, &VIDIOC-TRY-FMT;</term>
|
||||
<listitem><para>New structures for describing multi-planar formats are added:
|
||||
&v4l2-pix-format-mplane; and &v4l2-plane-pix-format;. Drivers may
|
||||
define new multi-planar formats, which have distinct FourCC codes from
|
||||
the existing single-planar ones.</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
<varlistentry>
|
||||
<term>&VIDIOC-QBUF;, &VIDIOC-DQBUF;, &VIDIOC-QUERYBUF;</term>
|
||||
<listitem><para>A new &v4l2-plane; structure for describing planes is added.
|
||||
Arrays of this structure are passed in the new
|
||||
<structfield>m.planes</structfield> field of &v4l2-buffer;.</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
<varlistentry>
|
||||
<term>&VIDIOC-REQBUFS;</term>
|
||||
<listitem><para>Will allocate multi-planar buffers as requested.</para></listitem>
|
||||
</varlistentry>
|
||||
</variablelist>
|
||||
</section>
|
||||
</section>
|
||||
Разница между файлами не показана из-за своего большого размера
Загрузить разницу
|
|
@ -85,6 +85,17 @@ Remote Controller chapter.</contrib>
|
|||
</address>
|
||||
</affiliation>
|
||||
</author>
|
||||
|
||||
<author>
|
||||
<firstname>Pawel</firstname>
|
||||
<surname>Osciak</surname>
|
||||
<contrib>Designed and documented the multi-planar API.</contrib>
|
||||
<affiliation>
|
||||
<address>
|
||||
<email>pawel AT osciak.com</email>
|
||||
</address>
|
||||
</affiliation>
|
||||
</author>
|
||||
</authorgroup>
|
||||
|
||||
<copyright>
|
||||
|
|
@ -102,7 +113,8 @@ Remote Controller chapter.</contrib>
|
|||
<year>2010</year>
|
||||
<year>2011</year>
|
||||
<holder>Bill Dirks, Michael H. Schimek, Hans Verkuil, Martin
|
||||
Rubli, Andy Walls, Muralidharan Karicheri, Mauro Carvalho Chehab</holder>
|
||||
Rubli, Andy Walls, Muralidharan Karicheri, Mauro Carvalho Chehab,
|
||||
Pawel Osciak</holder>
|
||||
</copyright>
|
||||
<legalnotice>
|
||||
<para>Except when explicitly stated as GPL, programming examples within
|
||||
|
|
@ -115,6 +127,13 @@ structs, ioctls) must be noted in more detail in the history chapter
|
|||
(compat.xml), along with the possible impact on existing drivers and
|
||||
applications. -->
|
||||
|
||||
<revision>
|
||||
<revnumber>2.6.39</revnumber>
|
||||
<date>2011-03-01</date>
|
||||
<authorinitials>mcc, po</authorinitials>
|
||||
<revremark>Removed VIDIOC_*_OLD from videodev2.h header and update it to reflect latest changes. Added the <link linkend="planar-apis">multi-planar API</link>.</revremark>
|
||||
</revision>
|
||||
|
||||
<revision>
|
||||
<revnumber>2.6.37</revnumber>
|
||||
<date>2010-08-06</date>
|
||||
|
|
@ -382,7 +401,7 @@ and discussions on the V4L mailing list.</revremark>
|
|||
</partinfo>
|
||||
|
||||
<title>Video for Linux Two API Specification</title>
|
||||
<subtitle>Revision 2.6.38</subtitle>
|
||||
<subtitle>Revision 2.6.39</subtitle>
|
||||
|
||||
<chapter id="common">
|
||||
&sub-common;
|
||||
|
|
@ -411,6 +430,7 @@ and discussions on the V4L mailing list.</revremark>
|
|||
<section id="radio"> &sub-dev-radio; </section>
|
||||
<section id="rds"> &sub-dev-rds; </section>
|
||||
<section id="event"> &sub-dev-event; </section>
|
||||
<section id="subdev"> &sub-dev-subdev; </section>
|
||||
</chapter>
|
||||
|
||||
<chapter id="driver">
|
||||
|
|
@ -478,6 +498,12 @@ and discussions on the V4L mailing list.</revremark>
|
|||
&sub-reqbufs;
|
||||
&sub-s-hw-freq-seek;
|
||||
&sub-streamon;
|
||||
&sub-subdev-enum-frame-interval;
|
||||
&sub-subdev-enum-frame-size;
|
||||
&sub-subdev-enum-mbus-code;
|
||||
&sub-subdev-g-crop;
|
||||
&sub-subdev-g-fmt;
|
||||
&sub-subdev-g-frame-interval;
|
||||
&sub-subscribe-event;
|
||||
<!-- End of ioctls. -->
|
||||
&sub-mmap;
|
||||
|
|
|
|||
|
|
@ -71,6 +71,7 @@
|
|||
* Moved from videodev.h
|
||||
*/
|
||||
#define VIDEO_MAX_FRAME 32
|
||||
#define VIDEO_MAX_PLANES 8
|
||||
|
||||
#ifndef __KERNEL__
|
||||
|
||||
|
|
@ -158,9 +159,23 @@ enum <link linkend="v4l2-buf-type">v4l2_buf_type</link> {
|
|||
/* Experimental */
|
||||
V4L2_BUF_TYPE_VIDEO_OUTPUT_OVERLAY = 8,
|
||||
#endif
|
||||
V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE = 9,
|
||||
V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE = 10,
|
||||
V4L2_BUF_TYPE_PRIVATE = 0x80,
|
||||
};
|
||||
|
||||
#define V4L2_TYPE_IS_MULTIPLANAR(type) \
|
||||
((type) == V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE \
|
||||
|| (type) == V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE)
|
||||
|
||||
#define V4L2_TYPE_IS_OUTPUT(type) \
|
||||
((type) == V4L2_BUF_TYPE_VIDEO_OUTPUT \
|
||||
|| (type) == V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE \
|
||||
|| (type) == V4L2_BUF_TYPE_VIDEO_OVERLAY \
|
||||
|| (type) == V4L2_BUF_TYPE_VIDEO_OUTPUT_OVERLAY \
|
||||
|| (type) == V4L2_BUF_TYPE_VBI_OUTPUT \
|
||||
|| (type) == V4L2_BUF_TYPE_SLICED_VBI_OUTPUT)
|
||||
|
||||
enum <link linkend="v4l2-tuner-type">v4l2_tuner_type</link> {
|
||||
V4L2_TUNER_RADIO = 1,
|
||||
V4L2_TUNER_ANALOG_TV = 2,
|
||||
|
|
@ -246,6 +261,11 @@ struct <link linkend="v4l2-capability">v4l2_capability</link> {
|
|||
#define V4L2_CAP_HW_FREQ_SEEK 0x00000400 /* Can do hardware frequency seek */
|
||||
#define V4L2_CAP_RDS_OUTPUT 0x00000800 /* Is an RDS encoder */
|
||||
|
||||
/* Is a video capture device that supports multiplanar formats */
|
||||
#define V4L2_CAP_VIDEO_CAPTURE_MPLANE 0x00001000
|
||||
/* Is a video output device that supports multiplanar formats */
|
||||
#define V4L2_CAP_VIDEO_OUTPUT_MPLANE 0x00002000
|
||||
|
||||
#define V4L2_CAP_TUNER 0x00010000 /* has a tuner */
|
||||
#define V4L2_CAP_AUDIO 0x00020000 /* has audio support */
|
||||
#define V4L2_CAP_RADIO 0x00040000 /* is a radio device */
|
||||
|
|
@ -320,6 +340,13 @@ struct <link linkend="v4l2-pix-format">v4l2_pix_format</link> {
|
|||
#define <link linkend="V4L2-PIX-FMT-NV16">V4L2_PIX_FMT_NV16</link> v4l2_fourcc('N', 'V', '1', '6') /* 16 Y/CbCr 4:2:2 */
|
||||
#define <link linkend="V4L2-PIX-FMT-NV61">V4L2_PIX_FMT_NV61</link> v4l2_fourcc('N', 'V', '6', '1') /* 16 Y/CrCb 4:2:2 */
|
||||
|
||||
/* two non contiguous planes - one Y, one Cr + Cb interleaved */
|
||||
#define <link linkend="V4L2-PIX-FMT-NV12M">V4L2_PIX_FMT_NV12M</link> v4l2_fourcc('N', 'M', '1', '2') /* 12 Y/CbCr 4:2:0 */
|
||||
#define <link linkend="V4L2-PIX-FMT-NV12MT">V4L2_PIX_FMT_NV12MT</link> v4l2_fourcc('T', 'M', '1', '2') /* 12 Y/CbCr 4:2:0 64x32 macroblocks */
|
||||
|
||||
/* three non contiguous planes - Y, Cb, Cr */
|
||||
#define <link linkend="V4L2-PIX-FMT-YUV420M">V4L2_PIX_FMT_YUV420M</link> v4l2_fourcc('Y', 'M', '1', '2') /* 12 YUV420 planar */
|
||||
|
||||
/* Bayer formats - see http://www.siliconimaging.com/RGB%20Bayer.htm */
|
||||
#define <link linkend="V4L2-PIX-FMT-SBGGR8">V4L2_PIX_FMT_SBGGR8</link> v4l2_fourcc('B', 'A', '8', '1') /* 8 BGBG.. GRGR.. */
|
||||
#define <link linkend="V4L2-PIX-FMT-SGBRG8">V4L2_PIX_FMT_SGBRG8</link> v4l2_fourcc('G', 'B', 'R', 'G') /* 8 GBGB.. RGRG.. */
|
||||
|
|
@ -518,6 +545,62 @@ struct <link linkend="v4l2-requestbuffers">v4l2_requestbuffers</link> {
|
|||
__u32 reserved[2];
|
||||
};
|
||||
|
||||
/**
|
||||
* struct <link linkend="v4l2-plane">v4l2_plane</link> - plane info for multi-planar buffers
|
||||
* @bytesused: number of bytes occupied by data in the plane (payload)
|
||||
* @length: size of this plane (NOT the payload) in bytes
|
||||
* @mem_offset: when memory in the associated struct <link linkend="v4l2-buffer">v4l2_buffer</link> is
|
||||
* V4L2_MEMORY_MMAP, equals the offset from the start of
|
||||
* the device memory for this plane (or is a "cookie" that
|
||||
* should be passed to mmap() called on the video node)
|
||||
* @userptr: when memory is V4L2_MEMORY_USERPTR, a userspace pointer
|
||||
* pointing to this plane
|
||||
* @data_offset: offset in the plane to the start of data; usually 0,
|
||||
* unless there is a header in front of the data
|
||||
*
|
||||
* Multi-planar buffers consist of one or more planes, e.g. an YCbCr buffer
|
||||
* with two planes can have one plane for Y, and another for interleaved CbCr
|
||||
* components. Each plane can reside in a separate memory buffer, or even in
|
||||
* a completely separate memory node (e.g. in embedded devices).
|
||||
*/
|
||||
struct <link linkend="v4l2-plane">v4l2_plane</link> {
|
||||
__u32 bytesused;
|
||||
__u32 length;
|
||||
union {
|
||||
__u32 mem_offset;
|
||||
unsigned long userptr;
|
||||
} m;
|
||||
__u32 data_offset;
|
||||
__u32 reserved[11];
|
||||
};
|
||||
|
||||
/**
|
||||
* struct <link linkend="v4l2-buffer">v4l2_buffer</link> - video buffer info
|
||||
* @index: id number of the buffer
|
||||
* @type: buffer type (type == *_MPLANE for multiplanar buffers)
|
||||
* @bytesused: number of bytes occupied by data in the buffer (payload);
|
||||
* unused (set to 0) for multiplanar buffers
|
||||
* @flags: buffer informational flags
|
||||
* @field: field order of the image in the buffer
|
||||
* @timestamp: frame timestamp
|
||||
* @timecode: frame timecode
|
||||
* @sequence: sequence count of this frame
|
||||
* @memory: the method, in which the actual video data is passed
|
||||
* @offset: for non-multiplanar buffers with memory == V4L2_MEMORY_MMAP;
|
||||
* offset from the start of the device memory for this plane,
|
||||
* (or a "cookie" that should be passed to mmap() as offset)
|
||||
* @userptr: for non-multiplanar buffers with memory == V4L2_MEMORY_USERPTR;
|
||||
* a userspace pointer pointing to this buffer
|
||||
* @planes: for multiplanar buffers; userspace pointer to the array of plane
|
||||
* info structs for this buffer
|
||||
* @length: size in bytes of the buffer (NOT its payload) for single-plane
|
||||
* buffers (when type != *_MPLANE); number of elements in the
|
||||
* planes array for multi-plane buffers
|
||||
* @input: input number from which the video data has has been captured
|
||||
*
|
||||
* Contains data exchanged by application and driver using one of the Streaming
|
||||
* I/O methods.
|
||||
*/
|
||||
struct <link linkend="v4l2-buffer">v4l2_buffer</link> {
|
||||
__u32 index;
|
||||
enum <link linkend="v4l2-buf-type">v4l2_buf_type</link> type;
|
||||
|
|
@ -533,6 +616,7 @@ struct <link linkend="v4l2-buffer">v4l2_buffer</link> {
|
|||
union {
|
||||
__u32 offset;
|
||||
unsigned long userptr;
|
||||
struct <link linkend="v4l2-plane">v4l2_plane</link> *planes;
|
||||
} m;
|
||||
__u32 length;
|
||||
__u32 input;
|
||||
|
|
@ -1623,12 +1707,56 @@ struct <link linkend="v4l2-mpeg-vbi-fmt-ivtv">v4l2_mpeg_vbi_fmt_ivtv</link> {
|
|||
* A G G R E G A T E S T R U C T U R E S
|
||||
*/
|
||||
|
||||
/* Stream data format
|
||||
/**
|
||||
* struct <link linkend="v4l2-plane-pix-format">v4l2_plane_pix_format</link> - additional, per-plane format definition
|
||||
* @sizeimage: maximum size in bytes required for data, for which
|
||||
* this plane will be used
|
||||
* @bytesperline: distance in bytes between the leftmost pixels in two
|
||||
* adjacent lines
|
||||
*/
|
||||
struct <link linkend="v4l2-plane-pix-format">v4l2_plane_pix_format</link> {
|
||||
__u32 sizeimage;
|
||||
__u16 bytesperline;
|
||||
__u16 reserved[7];
|
||||
} __attribute__ ((packed));
|
||||
|
||||
/**
|
||||
* struct <link linkend="v4l2-pix-format-mplane">v4l2_pix_format_mplane</link> - multiplanar format definition
|
||||
* @width: image width in pixels
|
||||
* @height: image height in pixels
|
||||
* @pixelformat: little endian four character code (fourcc)
|
||||
* @field: field order (for interlaced video)
|
||||
* @colorspace: supplemental to pixelformat
|
||||
* @plane_fmt: per-plane information
|
||||
* @num_planes: number of planes for this format
|
||||
*/
|
||||
struct <link linkend="v4l2-pix-format-mplane">v4l2_pix_format_mplane</link> {
|
||||
__u32 width;
|
||||
__u32 height;
|
||||
__u32 pixelformat;
|
||||
enum <link linkend="v4l2-field">v4l2_field</link> field;
|
||||
enum <link linkend="v4l2-colorspace">v4l2_colorspace</link> colorspace;
|
||||
|
||||
struct <link linkend="v4l2-plane-pix-format">v4l2_plane_pix_format</link> plane_fmt[VIDEO_MAX_PLANES];
|
||||
__u8 num_planes;
|
||||
__u8 reserved[11];
|
||||
} __attribute__ ((packed));
|
||||
|
||||
/**
|
||||
* struct <link linkend="v4l2-format">v4l2_format</link> - stream data format
|
||||
* @type: type of the data stream
|
||||
* @pix: definition of an image format
|
||||
* @pix_mp: definition of a multiplanar image format
|
||||
* @win: definition of an overlaid image
|
||||
* @vbi: raw VBI capture or output parameters
|
||||
* @sliced: sliced VBI capture or output parameters
|
||||
* @raw_data: placeholder for future extensions and custom formats
|
||||
*/
|
||||
struct <link linkend="v4l2-format">v4l2_format</link> {
|
||||
enum <link linkend="v4l2-buf-type">v4l2_buf_type</link> type;
|
||||
union {
|
||||
struct <link linkend="v4l2-pix-format">v4l2_pix_format</link> pix; /* V4L2_BUF_TYPE_VIDEO_CAPTURE */
|
||||
struct <link linkend="v4l2-pix-format-mplane">v4l2_pix_format_mplane</link> pix_mp; /* V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE */
|
||||
struct <link linkend="v4l2-window">v4l2_window</link> win; /* V4L2_BUF_TYPE_VIDEO_OVERLAY */
|
||||
struct <link linkend="v4l2-vbi-format">v4l2_vbi_format</link> vbi; /* V4L2_BUF_TYPE_VBI_CAPTURE */
|
||||
struct <link linkend="v4l2-sliced-vbi-format">v4l2_sliced_vbi_format</link> sliced; /* V4L2_BUF_TYPE_SLICED_VBI_CAPTURE */
|
||||
|
|
@ -1636,7 +1764,6 @@ struct <link linkend="v4l2-format">v4l2_format</link> {
|
|||
} fmt;
|
||||
};
|
||||
|
||||
|
||||
/* Stream type-dependent parameters
|
||||
*/
|
||||
struct <link linkend="v4l2-streamparm">v4l2_streamparm</link> {
|
||||
|
|
@ -1809,16 +1936,6 @@ struct <link linkend="v4l2-dbg-chip-ident">v4l2_dbg_chip_ident</link> {
|
|||
/* Reminder: when adding new ioctls please add support for them to
|
||||
drivers/media/video/v4l2-compat-ioctl32.c as well! */
|
||||
|
||||
#ifdef __OLD_VIDIOC_
|
||||
/* for compatibility, will go away some day */
|
||||
#define VIDIOC_OVERLAY_OLD _IOWR('V', 14, int)
|
||||
#define VIDIOC_S_PARM_OLD _IOW('V', 22, struct <link linkend="v4l2-streamparm">v4l2_streamparm</link>)
|
||||
#define VIDIOC_S_CTRL_OLD _IOW('V', 28, struct <link linkend="v4l2-control">v4l2_control</link>)
|
||||
#define VIDIOC_G_AUDIO_OLD _IOWR('V', 33, struct <link linkend="v4l2-audio">v4l2_audio</link>)
|
||||
#define VIDIOC_G_AUDOUT_OLD _IOWR('V', 49, struct <link linkend="v4l2-audioout">v4l2_audioout</link>)
|
||||
#define VIDIOC_CROPCAP_OLD _IOR('V', 58, struct <link linkend="v4l2-cropcap">v4l2_cropcap</link>)
|
||||
#endif
|
||||
|
||||
#define BASE_VIDIOC_PRIVATE 192 /* 192-255 are private */
|
||||
|
||||
#endif /* __LINUX_VIDEODEV2_H */
|
||||
|
|
|
|||
|
|
@ -76,7 +76,9 @@ pixelformat</structfield> field.</entry>
|
|||
<entry>Type of the data stream, set by the application.
|
||||
Only these types are valid here:
|
||||
<constant>V4L2_BUF_TYPE_VIDEO_CAPTURE</constant>,
|
||||
<constant>V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE</constant>,
|
||||
<constant>V4L2_BUF_TYPE_VIDEO_OUTPUT</constant>,
|
||||
<constant>V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE</constant>,
|
||||
<constant>V4L2_BUF_TYPE_VIDEO_OVERLAY</constant>, and custom (driver
|
||||
defined) types with code <constant>V4L2_BUF_TYPE_PRIVATE</constant>
|
||||
and higher.</entry>
|
||||
|
|
|
|||
|
|
@ -60,11 +60,13 @@ application.</para>
|
|||
<structfield>type</structfield> field of a struct
|
||||
<structname>v4l2_format</structname> to the respective buffer (stream)
|
||||
type. For example video capture devices use
|
||||
<constant>V4L2_BUF_TYPE_VIDEO_CAPTURE</constant>. When the application
|
||||
<constant>V4L2_BUF_TYPE_VIDEO_CAPTURE</constant> or
|
||||
<constant>V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE</constant>. When the application
|
||||
calls the <constant>VIDIOC_G_FMT</constant> ioctl with a pointer to
|
||||
this structure the driver fills the respective member of the
|
||||
<structfield>fmt</structfield> union. In case of video capture devices
|
||||
that is the &v4l2-pix-format; <structfield>pix</structfield> member.
|
||||
that is either the &v4l2-pix-format; <structfield>pix</structfield> or
|
||||
the &v4l2-pix-format-mplane; <structfield>pix_mp</structfield> member.
|
||||
When the requested buffer type is not supported drivers return an
|
||||
&EINVAL;.</para>
|
||||
|
||||
|
|
@ -131,6 +133,15 @@ this ioctl.</para>
|
|||
<entry>Definition of an image format, see <xref
|
||||
linkend="pixfmt" />, used by video capture and output
|
||||
devices.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry></entry>
|
||||
<entry>&v4l2-pix-format-mplane;</entry>
|
||||
<entry><structfield>pix_mp</structfield></entry>
|
||||
<entry>Definition of an image format, see <xref
|
||||
linkend="pixfmt" />, used by video capture and output
|
||||
devices that support the <link linkend="planar-apis">multi-planar
|
||||
version of the API</link>.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry></entry>
|
||||
|
|
|
|||
|
|
@ -64,7 +64,8 @@ zero to the number of buffers allocated with &VIDIOC-REQBUFS;
|
|||
contents of the struct <structname>v4l2_buffer</structname> returned
|
||||
by a &VIDIOC-QUERYBUF; ioctl will do as well. When the buffer is
|
||||
intended for output (<structfield>type</structfield> is
|
||||
<constant>V4L2_BUF_TYPE_VIDEO_OUTPUT</constant> or
|
||||
<constant>V4L2_BUF_TYPE_VIDEO_OUTPUT</constant>,
|
||||
<constant>V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE</constant>, or
|
||||
<constant>V4L2_BUF_TYPE_VBI_OUTPUT</constant>) applications must also
|
||||
initialize the <structfield>bytesused</structfield>,
|
||||
<structfield>field</structfield> and
|
||||
|
|
@ -75,7 +76,11 @@ supports capturing from specific video inputs and you want to specify a video
|
|||
input, then <structfield>flags</structfield> should be set to
|
||||
<constant>V4L2_BUF_FLAG_INPUT</constant> and the field
|
||||
<structfield>input</structfield> must be initialized to the desired input.
|
||||
The <structfield>reserved</structfield> field must be set to 0.
|
||||
The <structfield>reserved</structfield> field must be set to 0. When using
|
||||
the <link linkend="planar-apis">multi-planar API</link>, the
|
||||
<structfield>m.planes</structfield> field must contain a userspace pointer
|
||||
to a filled-in array of &v4l2-plane; and the <structfield>length</structfield>
|
||||
field must be set to the number of elements in that array.
|
||||
</para>
|
||||
|
||||
<para>To enqueue a <link linkend="mmap">memory mapped</link>
|
||||
|
|
@ -93,10 +98,13 @@ structure the driver sets the
|
|||
buffer applications set the <structfield>memory</structfield>
|
||||
field to <constant>V4L2_MEMORY_USERPTR</constant>, the
|
||||
<structfield>m.userptr</structfield> field to the address of the
|
||||
buffer and <structfield>length</structfield> to its size.
|
||||
When <constant>VIDIOC_QBUF</constant> is called with a pointer to this
|
||||
structure the driver sets the <constant>V4L2_BUF_FLAG_QUEUED</constant>
|
||||
flag and clears the <constant>V4L2_BUF_FLAG_MAPPED</constant> and
|
||||
buffer and <structfield>length</structfield> to its size. When the multi-planar
|
||||
API is used, <structfield>m.userptr</structfield> and
|
||||
<structfield>length</structfield> members of the passed array of &v4l2-plane;
|
||||
have to be used instead. When <constant>VIDIOC_QBUF</constant> is called with
|
||||
a pointer to this structure the driver sets the
|
||||
<constant>V4L2_BUF_FLAG_QUEUED</constant> flag and clears the
|
||||
<constant>V4L2_BUF_FLAG_MAPPED</constant> and
|
||||
<constant>V4L2_BUF_FLAG_DONE</constant> flags in the
|
||||
<structfield>flags</structfield> field, or it returns an error code.
|
||||
This ioctl locks the memory pages of the buffer in physical memory,
|
||||
|
|
@ -115,7 +123,9 @@ remaining fields or returns an error code. The driver may also set
|
|||
<constant>V4L2_BUF_FLAG_ERROR</constant> in the <structfield>flags</structfield>
|
||||
field. It indicates a non-critical (recoverable) streaming error. In such case
|
||||
the application may continue as normal, but should be aware that data in the
|
||||
dequeued buffer might be corrupted.</para>
|
||||
dequeued buffer might be corrupted. When using the multi-planar API, the
|
||||
planes array does not have to be passed; the <structfield>m.planes</structfield>
|
||||
member must be set to NULL in that case.</para>
|
||||
|
||||
<para>By default <constant>VIDIOC_DQBUF</constant> blocks when no
|
||||
buffer is in the outgoing queue. When the
|
||||
|
|
|
|||
|
|
@ -61,6 +61,10 @@ buffer at any time after buffers have been allocated with the
|
|||
to the number of buffers allocated with &VIDIOC-REQBUFS;
|
||||
(&v4l2-requestbuffers; <structfield>count</structfield>) minus one.
|
||||
The <structfield>reserved</structfield> field should to set to 0.
|
||||
When using the <link linkend="planar-apis">multi-planar API</link>, the
|
||||
<structfield>m.planes</structfield> field must contain a userspace pointer to an
|
||||
array of &v4l2-plane; and the <structfield>length</structfield> field has
|
||||
to be set to the number of elements in that array.
|
||||
After calling <constant>VIDIOC_QUERYBUF</constant> with a pointer to
|
||||
this structure drivers return an error code or fill the rest of
|
||||
the structure.</para>
|
||||
|
|
@ -70,11 +74,13 @@ the structure.</para>
|
|||
<constant>V4L2_BUF_FLAG_QUEUED</constant> and
|
||||
<constant>V4L2_BUF_FLAG_DONE</constant> flags will be valid. The
|
||||
<structfield>memory</structfield> field will be set to the current
|
||||
I/O method, the <structfield>m.offset</structfield>
|
||||
I/O method. For the single-planar API, the <structfield>m.offset</structfield>
|
||||
contains the offset of the buffer from the start of the device memory,
|
||||
the <structfield>length</structfield> field its size. The driver may
|
||||
or may not set the remaining fields and flags, they are meaningless in
|
||||
this context.</para>
|
||||
the <structfield>length</structfield> field its size. For the multi-planar API,
|
||||
fields <structfield>m.mem_offset</structfield> and
|
||||
<structfield>length</structfield> in the <structfield>m.planes</structfield>
|
||||
array elements will be used instead. The driver may or may not set the remaining
|
||||
fields and flags, they are meaningless in this context.</para>
|
||||
|
||||
<para>The <structname>v4l2_buffer</structname> structure is
|
||||
specified in <xref linkend="buffer" />.</para>
|
||||
|
|
|
|||
|
|
@ -142,15 +142,29 @@ this array to zero.</entry>
|
|||
<row>
|
||||
<entry><constant>V4L2_CAP_VIDEO_CAPTURE</constant></entry>
|
||||
<entry>0x00000001</entry>
|
||||
<entry>The device supports the <link
|
||||
<entry>The device supports the single-planar API through the <link
|
||||
linkend="capture">Video Capture</link> interface.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry><constant>V4L2_CAP_VIDEO_CAPTURE_MPLANE</constant></entry>
|
||||
<entry>0x00001000</entry>
|
||||
<entry>The device supports the
|
||||
<link linkend="planar-apis">multi-planar API</link> through the
|
||||
<link linkend="capture">Video Capture</link> interface.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry><constant>V4L2_CAP_VIDEO_OUTPUT</constant></entry>
|
||||
<entry>0x00000002</entry>
|
||||
<entry>The device supports the <link
|
||||
<entry>The device supports the single-planar API through the <link
|
||||
linkend="output">Video Output</link> interface.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry><constant>V4L2_CAP_VIDEO_OUTPUT_MPLANE</constant></entry>
|
||||
<entry>0x00002000</entry>
|
||||
<entry>The device supports the
|
||||
<link linkend="planar-apis">multi-planar API</link> through the
|
||||
<link linkend="output">Video Output</link> interface.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry><constant>V4L2_CAP_VIDEO_OVERLAY</constant></entry>
|
||||
<entry>0x00000004</entry>
|
||||
|
|
|
|||
|
|
@ -93,6 +93,15 @@ synchronize with other events.</para>
|
|||
been allocated (memory mapping) or enqueued (output) yet.</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
<varlistentry>
|
||||
<term><errorcode>EPIPE</errorcode></term>
|
||||
<listitem>
|
||||
<para>The driver implements <link
|
||||
linkend="pad-level-formats">pad-level format configuration</link> and
|
||||
the pipeline configuration is invalid.
|
||||
</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
</variablelist>
|
||||
</refsect1>
|
||||
</refentry>
|
||||
|
|
|
|||
|
|
@ -0,0 +1,152 @@
|
|||
<refentry id="vidioc-subdev-enum-frame-interval">
|
||||
<refmeta>
|
||||
<refentrytitle>ioctl VIDIOC_SUBDEV_ENUM_FRAME_INTERVAL</refentrytitle>
|
||||
&manvol;
|
||||
</refmeta>
|
||||
|
||||
<refnamediv>
|
||||
<refname>VIDIOC_SUBDEV_ENUM_FRAME_INTERVAL</refname>
|
||||
<refpurpose>Enumerate frame intervals</refpurpose>
|
||||
</refnamediv>
|
||||
|
||||
<refsynopsisdiv>
|
||||
<funcsynopsis>
|
||||
<funcprototype>
|
||||
<funcdef>int <function>ioctl</function></funcdef>
|
||||
<paramdef>int <parameter>fd</parameter></paramdef>
|
||||
<paramdef>int <parameter>request</parameter></paramdef>
|
||||
<paramdef>struct v4l2_subdev_frame_interval_enum *
|
||||
<parameter>argp</parameter></paramdef>
|
||||
</funcprototype>
|
||||
</funcsynopsis>
|
||||
</refsynopsisdiv>
|
||||
|
||||
<refsect1>
|
||||
<title>Arguments</title>
|
||||
|
||||
<variablelist>
|
||||
<varlistentry>
|
||||
<term><parameter>fd</parameter></term>
|
||||
<listitem>
|
||||
<para>&fd;</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
<varlistentry>
|
||||
<term><parameter>request</parameter></term>
|
||||
<listitem>
|
||||
<para>VIDIOC_SUBDEV_ENUM_FRAME_INTERVAL</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
<varlistentry>
|
||||
<term><parameter>argp</parameter></term>
|
||||
<listitem>
|
||||
<para></para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
</variablelist>
|
||||
</refsect1>
|
||||
|
||||
<refsect1>
|
||||
<title>Description</title>
|
||||
|
||||
<note>
|
||||
<title>Experimental</title>
|
||||
<para>This is an <link linkend="experimental">experimental</link>
|
||||
interface and may change in the future.</para>
|
||||
</note>
|
||||
|
||||
<para>This ioctl lets applications enumerate available frame intervals on a
|
||||
given sub-device pad. Frame intervals only makes sense for sub-devices that
|
||||
can control the frame period on their own. This includes, for instance,
|
||||
image sensors and TV tuners.</para>
|
||||
|
||||
<para>For the common use case of image sensors, the frame intervals
|
||||
available on the sub-device output pad depend on the frame format and size
|
||||
on the same pad. Applications must thus specify the desired format and size
|
||||
when enumerating frame intervals.</para>
|
||||
|
||||
<para>To enumerate frame intervals applications initialize the
|
||||
<structfield>index</structfield>, <structfield>pad</structfield>,
|
||||
<structfield>code</structfield>, <structfield>width</structfield> and
|
||||
<structfield>height</structfield> fields of
|
||||
&v4l2-subdev-frame-interval-enum; and call the
|
||||
<constant>VIDIOC_SUBDEV_ENUM_FRAME_INTERVAL</constant> ioctl with a pointer
|
||||
to this structure. Drivers fill the rest of the structure or return
|
||||
an &EINVAL; if one of the input fields is invalid. All frame intervals are
|
||||
enumerable by beginning at index zero and incrementing by one until
|
||||
<errorcode>EINVAL</errorcode> is returned.</para>
|
||||
|
||||
<para>Available frame intervals may depend on the current 'try' formats
|
||||
at other pads of the sub-device, as well as on the current active links. See
|
||||
&VIDIOC-SUBDEV-G-FMT; for more information about the try formats.</para>
|
||||
|
||||
<para>Sub-devices that support the frame interval enumeration ioctl should
|
||||
implemented it on a single pad only. Its behaviour when supported on
|
||||
multiple pads of the same sub-device is not defined.</para>
|
||||
|
||||
<table pgwide="1" frame="none" id="v4l2-subdev-frame-interval-enum">
|
||||
<title>struct <structname>v4l2_subdev_frame_interval_enum</structname></title>
|
||||
<tgroup cols="3">
|
||||
&cs-str;
|
||||
<tbody valign="top">
|
||||
<row>
|
||||
<entry>__u32</entry>
|
||||
<entry><structfield>index</structfield></entry>
|
||||
<entry>Number of the format in the enumeration, set by the
|
||||
application.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry>__u32</entry>
|
||||
<entry><structfield>pad</structfield></entry>
|
||||
<entry>Pad number as reported by the media controller API.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry>__u32</entry>
|
||||
<entry><structfield>code</structfield></entry>
|
||||
<entry>The media bus format code, as defined in
|
||||
<xref linkend="v4l2-mbus-format" />.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry>__u32</entry>
|
||||
<entry><structfield>width</structfield></entry>
|
||||
<entry>Frame width, in pixels.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry>__u32</entry>
|
||||
<entry><structfield>height</structfield></entry>
|
||||
<entry>Frame height, in pixels.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry>&v4l2-fract;</entry>
|
||||
<entry><structfield>interval</structfield></entry>
|
||||
<entry>Period, in seconds, between consecutive video frames.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry>__u32</entry>
|
||||
<entry><structfield>reserved</structfield>[9]</entry>
|
||||
<entry>Reserved for future extensions. Applications and drivers must
|
||||
set the array to zero.</entry>
|
||||
</row>
|
||||
</tbody>
|
||||
</tgroup>
|
||||
</table>
|
||||
</refsect1>
|
||||
|
||||
<refsect1>
|
||||
&return-value;
|
||||
|
||||
<variablelist>
|
||||
<varlistentry>
|
||||
<term><errorcode>EINVAL</errorcode></term>
|
||||
<listitem>
|
||||
<para>The &v4l2-subdev-frame-interval-enum;
|
||||
<structfield>pad</structfield> references a non-existing pad, one of
|
||||
the <structfield>code</structfield>, <structfield>width</structfield>
|
||||
or <structfield>height</structfield> fields are invalid for the given
|
||||
pad or the <structfield>index</structfield> field is out of bounds.
|
||||
</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
</variablelist>
|
||||
</refsect1>
|
||||
</refentry>
|
||||
|
|
@ -0,0 +1,154 @@
|
|||
<refentry id="vidioc-subdev-enum-frame-size">
|
||||
<refmeta>
|
||||
<refentrytitle>ioctl VIDIOC_SUBDEV_ENUM_FRAME_SIZE</refentrytitle>
|
||||
&manvol;
|
||||
</refmeta>
|
||||
|
||||
<refnamediv>
|
||||
<refname>VIDIOC_SUBDEV_ENUM_FRAME_SIZE</refname>
|
||||
<refpurpose>Enumerate media bus frame sizes</refpurpose>
|
||||
</refnamediv>
|
||||
|
||||
<refsynopsisdiv>
|
||||
<funcsynopsis>
|
||||
<funcprototype>
|
||||
<funcdef>int <function>ioctl</function></funcdef>
|
||||
<paramdef>int <parameter>fd</parameter></paramdef>
|
||||
<paramdef>int <parameter>request</parameter></paramdef>
|
||||
<paramdef>struct v4l2_subdev_frame_size_enum *
|
||||
<parameter>argp</parameter></paramdef>
|
||||
</funcprototype>
|
||||
</funcsynopsis>
|
||||
</refsynopsisdiv>
|
||||
|
||||
<refsect1>
|
||||
<title>Arguments</title>
|
||||
|
||||
<variablelist>
|
||||
<varlistentry>
|
||||
<term><parameter>fd</parameter></term>
|
||||
<listitem>
|
||||
<para>&fd;</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
<varlistentry>
|
||||
<term><parameter>request</parameter></term>
|
||||
<listitem>
|
||||
<para>VIDIOC_SUBDEV_ENUM_FRAME_SIZE</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
<varlistentry>
|
||||
<term><parameter>argp</parameter></term>
|
||||
<listitem>
|
||||
<para></para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
</variablelist>
|
||||
</refsect1>
|
||||
|
||||
<refsect1>
|
||||
<title>Description</title>
|
||||
|
||||
<note>
|
||||
<title>Experimental</title>
|
||||
<para>This is an <link linkend="experimental">experimental</link>
|
||||
interface and may change in the future.</para>
|
||||
</note>
|
||||
|
||||
<para>This ioctl allows applications to enumerate all frame sizes
|
||||
supported by a sub-device on the given pad for the given media bus format.
|
||||
Supported formats can be retrieved with the &VIDIOC-SUBDEV-ENUM-MBUS-CODE;
|
||||
ioctl.</para>
|
||||
|
||||
<para>To enumerate frame sizes applications initialize the
|
||||
<structfield>pad</structfield>, <structfield>code</structfield> and
|
||||
<structfield>index</structfield> fields of the
|
||||
&v4l2-subdev-mbus-code-enum; and call the
|
||||
<constant>VIDIOC_SUBDEV_ENUM_FRAME_SIZE</constant> ioctl with a pointer to
|
||||
the structure. Drivers fill the minimum and maximum frame sizes or return
|
||||
an &EINVAL; if one of the input parameters is invalid.</para>
|
||||
|
||||
<para>Sub-devices that only support discrete frame sizes (such as most
|
||||
sensors) will return one or more frame sizes with identical minimum and
|
||||
maximum values.</para>
|
||||
|
||||
<para>Not all possible sizes in given [minimum, maximum] ranges need to be
|
||||
supported. For instance, a scaler that uses a fixed-point scaling ratio
|
||||
might not be able to produce every frame size between the minimum and
|
||||
maximum values. Applications must use the &VIDIOC-SUBDEV-S-FMT; ioctl to
|
||||
try the sub-device for an exact supported frame size.</para>
|
||||
|
||||
<para>Available frame sizes may depend on the current 'try' formats at other
|
||||
pads of the sub-device, as well as on the current active links and the
|
||||
current values of V4L2 controls. See &VIDIOC-SUBDEV-G-FMT; for more
|
||||
information about try formats.</para>
|
||||
|
||||
<table pgwide="1" frame="none" id="v4l2-subdev-frame-size-enum">
|
||||
<title>struct <structname>v4l2_subdev_frame_size_enum</structname></title>
|
||||
<tgroup cols="3">
|
||||
&cs-str;
|
||||
<tbody valign="top">
|
||||
<row>
|
||||
<entry>__u32</entry>
|
||||
<entry><structfield>index</structfield></entry>
|
||||
<entry>Number of the format in the enumeration, set by the
|
||||
application.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry>__u32</entry>
|
||||
<entry><structfield>pad</structfield></entry>
|
||||
<entry>Pad number as reported by the media controller API.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry>__u32</entry>
|
||||
<entry><structfield>code</structfield></entry>
|
||||
<entry>The media bus format code, as defined in
|
||||
<xref linkend="v4l2-mbus-format" />.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry>__u32</entry>
|
||||
<entry><structfield>min_width</structfield></entry>
|
||||
<entry>Minimum frame width, in pixels.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry>__u32</entry>
|
||||
<entry><structfield>max_width</structfield></entry>
|
||||
<entry>Maximum frame width, in pixels.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry>__u32</entry>
|
||||
<entry><structfield>min_height</structfield></entry>
|
||||
<entry>Minimum frame height, in pixels.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry>__u32</entry>
|
||||
<entry><structfield>max_height</structfield></entry>
|
||||
<entry>Maximum frame height, in pixels.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry>__u32</entry>
|
||||
<entry><structfield>reserved</structfield>[9]</entry>
|
||||
<entry>Reserved for future extensions. Applications and drivers must
|
||||
set the array to zero.</entry>
|
||||
</row>
|
||||
</tbody>
|
||||
</tgroup>
|
||||
</table>
|
||||
</refsect1>
|
||||
|
||||
<refsect1>
|
||||
&return-value;
|
||||
|
||||
<variablelist>
|
||||
<varlistentry>
|
||||
<term><errorcode>EINVAL</errorcode></term>
|
||||
<listitem>
|
||||
<para>The &v4l2-subdev-frame-size-enum; <structfield>pad</structfield>
|
||||
references a non-existing pad, the <structfield>code</structfield> is
|
||||
invalid for the given pad or the <structfield>index</structfield>
|
||||
field is out of bounds.</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
</variablelist>
|
||||
</refsect1>
|
||||
</refentry>
|
||||
|
|
@ -0,0 +1,119 @@
|
|||
<refentry id="vidioc-subdev-enum-mbus-code">
|
||||
<refmeta>
|
||||
<refentrytitle>ioctl VIDIOC_SUBDEV_ENUM_MBUS_CODE</refentrytitle>
|
||||
&manvol;
|
||||
</refmeta>
|
||||
|
||||
<refnamediv>
|
||||
<refname>VIDIOC_SUBDEV_ENUM_MBUS_CODE</refname>
|
||||
<refpurpose>Enumerate media bus formats</refpurpose>
|
||||
</refnamediv>
|
||||
|
||||
<refsynopsisdiv>
|
||||
<funcsynopsis>
|
||||
<funcprototype>
|
||||
<funcdef>int <function>ioctl</function></funcdef>
|
||||
<paramdef>int <parameter>fd</parameter></paramdef>
|
||||
<paramdef>int <parameter>request</parameter></paramdef>
|
||||
<paramdef>struct v4l2_subdev_mbus_code_enum *
|
||||
<parameter>argp</parameter></paramdef>
|
||||
</funcprototype>
|
||||
</funcsynopsis>
|
||||
</refsynopsisdiv>
|
||||
|
||||
<refsect1>
|
||||
<title>Arguments</title>
|
||||
|
||||
<variablelist>
|
||||
<varlistentry>
|
||||
<term><parameter>fd</parameter></term>
|
||||
<listitem>
|
||||
<para>&fd;</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
<varlistentry>
|
||||
<term><parameter>request</parameter></term>
|
||||
<listitem>
|
||||
<para>VIDIOC_SUBDEV_ENUM_MBUS_CODE</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
<varlistentry>
|
||||
<term><parameter>argp</parameter></term>
|
||||
<listitem>
|
||||
<para></para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
</variablelist>
|
||||
</refsect1>
|
||||
|
||||
<refsect1>
|
||||
<title>Description</title>
|
||||
|
||||
<note>
|
||||
<title>Experimental</title>
|
||||
<para>This is an <link linkend="experimental">experimental</link>
|
||||
interface and may change in the future.</para>
|
||||
</note>
|
||||
|
||||
<para>To enumerate media bus formats available at a given sub-device pad
|
||||
applications initialize the <structfield>pad</structfield> and
|
||||
<structfield>index</structfield> fields of &v4l2-subdev-mbus-code-enum; and
|
||||
call the <constant>VIDIOC_SUBDEV_ENUM_MBUS_CODE</constant> ioctl with a
|
||||
pointer to this structure. Drivers fill the rest of the structure or return
|
||||
an &EINVAL; if either the <structfield>pad</structfield> or
|
||||
<structfield>index</structfield> are invalid. All media bus formats are
|
||||
enumerable by beginning at index zero and incrementing by one until
|
||||
<errorcode>EINVAL</errorcode> is returned.</para>
|
||||
|
||||
<para>Available media bus formats may depend on the current 'try' formats
|
||||
at other pads of the sub-device, as well as on the current active links. See
|
||||
&VIDIOC-SUBDEV-G-FMT; for more information about the try formats.</para>
|
||||
|
||||
<table pgwide="1" frame="none" id="v4l2-subdev-mbus-code-enum">
|
||||
<title>struct <structname>v4l2_subdev_mbus_code_enum</structname></title>
|
||||
<tgroup cols="3">
|
||||
&cs-str;
|
||||
<tbody valign="top">
|
||||
<row>
|
||||
<entry>__u32</entry>
|
||||
<entry><structfield>pad</structfield></entry>
|
||||
<entry>Pad number as reported by the media controller API.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry>__u32</entry>
|
||||
<entry><structfield>index</structfield></entry>
|
||||
<entry>Number of the format in the enumeration, set by the
|
||||
application.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry>__u32</entry>
|
||||
<entry><structfield>code</structfield></entry>
|
||||
<entry>The media bus format code, as defined in
|
||||
<xref linkend="v4l2-mbus-format" />.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry>__u32</entry>
|
||||
<entry><structfield>reserved</structfield>[9]</entry>
|
||||
<entry>Reserved for future extensions. Applications and drivers must
|
||||
set the array to zero.</entry>
|
||||
</row>
|
||||
</tbody>
|
||||
</tgroup>
|
||||
</table>
|
||||
</refsect1>
|
||||
|
||||
<refsect1>
|
||||
&return-value;
|
||||
|
||||
<variablelist>
|
||||
<varlistentry>
|
||||
<term><errorcode>EINVAL</errorcode></term>
|
||||
<listitem>
|
||||
<para>The &v4l2-subdev-mbus-code-enum; <structfield>pad</structfield>
|
||||
references a non-existing pad, or the <structfield>index</structfield>
|
||||
field is out of bounds.</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
</variablelist>
|
||||
</refsect1>
|
||||
</refentry>
|
||||
|
|
@ -0,0 +1,155 @@
|
|||
<refentry id="vidioc-subdev-g-crop">
|
||||
<refmeta>
|
||||
<refentrytitle>ioctl VIDIOC_SUBDEV_G_CROP, VIDIOC_SUBDEV_S_CROP</refentrytitle>
|
||||
&manvol;
|
||||
</refmeta>
|
||||
|
||||
<refnamediv>
|
||||
<refname>VIDIOC_SUBDEV_G_CROP</refname>
|
||||
<refname>VIDIOC_SUBDEV_S_CROP</refname>
|
||||
<refpurpose>Get or set the crop rectangle on a subdev pad</refpurpose>
|
||||
</refnamediv>
|
||||
|
||||
<refsynopsisdiv>
|
||||
<funcsynopsis>
|
||||
<funcprototype>
|
||||
<funcdef>int <function>ioctl</function></funcdef>
|
||||
<paramdef>int <parameter>fd</parameter></paramdef>
|
||||
<paramdef>int <parameter>request</parameter></paramdef>
|
||||
<paramdef>struct v4l2_subdev_crop *<parameter>argp</parameter></paramdef>
|
||||
</funcprototype>
|
||||
</funcsynopsis>
|
||||
<funcsynopsis>
|
||||
<funcprototype>
|
||||
<funcdef>int <function>ioctl</function></funcdef>
|
||||
<paramdef>int <parameter>fd</parameter></paramdef>
|
||||
<paramdef>int <parameter>request</parameter></paramdef>
|
||||
<paramdef>const struct v4l2_subdev_crop *<parameter>argp</parameter></paramdef>
|
||||
</funcprototype>
|
||||
</funcsynopsis>
|
||||
</refsynopsisdiv>
|
||||
|
||||
<refsect1>
|
||||
<title>Arguments</title>
|
||||
|
||||
<variablelist>
|
||||
<varlistentry>
|
||||
<term><parameter>fd</parameter></term>
|
||||
<listitem>
|
||||
<para>&fd;</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
<varlistentry>
|
||||
<term><parameter>request</parameter></term>
|
||||
<listitem>
|
||||
<para>VIDIOC_SUBDEV_G_CROP, VIDIOC_SUBDEV_S_CROP</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
<varlistentry>
|
||||
<term><parameter>argp</parameter></term>
|
||||
<listitem>
|
||||
<para></para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
</variablelist>
|
||||
</refsect1>
|
||||
|
||||
<refsect1>
|
||||
<title>Description</title>
|
||||
|
||||
<note>
|
||||
<title>Experimental</title>
|
||||
<para>This is an <link linkend="experimental">experimental</link>
|
||||
interface and may change in the future.</para>
|
||||
</note>
|
||||
|
||||
<para>To retrieve the current crop rectangle applications set the
|
||||
<structfield>pad</structfield> field of a &v4l2-subdev-crop; to the
|
||||
desired pad number as reported by the media API and the
|
||||
<structfield>which</structfield> field to
|
||||
<constant>V4L2_SUBDEV_FORMAT_ACTIVE</constant>. They then call the
|
||||
<constant>VIDIOC_SUBDEV_G_CROP</constant> ioctl with a pointer to this
|
||||
structure. The driver fills the members of the <structfield>rect</structfield>
|
||||
field or returns &EINVAL; if the input arguments are invalid, or if cropping
|
||||
is not supported on the given pad.</para>
|
||||
|
||||
<para>To change the current crop rectangle applications set both the
|
||||
<structfield>pad</structfield> and <structfield>which</structfield> fields
|
||||
and all members of the <structfield>rect</structfield> field. They then call
|
||||
the <constant>VIDIOC_SUBDEV_S_CROP</constant> ioctl with a pointer to this
|
||||
structure. The driver verifies the requested crop rectangle, adjusts it
|
||||
based on the hardware capabilities and configures the device. Upon return
|
||||
the &v4l2-subdev-crop; contains the current format as would be returned
|
||||
by a <constant>VIDIOC_SUBDEV_G_CROP</constant> call.</para>
|
||||
|
||||
<para>Applications can query the device capabilities by setting the
|
||||
<structfield>which</structfield> to
|
||||
<constant>V4L2_SUBDEV_FORMAT_TRY</constant>. When set, 'try' crop
|
||||
rectangles are not applied to the device by the driver, but are mangled
|
||||
exactly as active crop rectangles and stored in the sub-device file handle.
|
||||
Two applications querying the same sub-device would thus not interact with
|
||||
each other.</para>
|
||||
|
||||
<para>Drivers must not return an error solely because the requested crop
|
||||
rectangle doesn't match the device capabilities. They must instead modify
|
||||
the rectangle to match what the hardware can provide. The modified format
|
||||
should be as close as possible to the original request.</para>
|
||||
|
||||
<table pgwide="1" frame="none" id="v4l2-subdev-crop">
|
||||
<title>struct <structname>v4l2_subdev_crop</structname></title>
|
||||
<tgroup cols="3">
|
||||
&cs-str;
|
||||
<tbody valign="top">
|
||||
<row>
|
||||
<entry>__u32</entry>
|
||||
<entry><structfield>pad</structfield></entry>
|
||||
<entry>Pad number as reported by the media framework.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry>__u32</entry>
|
||||
<entry><structfield>which</structfield></entry>
|
||||
<entry>Crop rectangle to get or set, from
|
||||
&v4l2-subdev-format-whence;.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry>&v4l2-rect;</entry>
|
||||
<entry><structfield>rect</structfield></entry>
|
||||
<entry>Crop rectangle boundaries, in pixels.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry>__u32</entry>
|
||||
<entry><structfield>reserved</structfield>[8]</entry>
|
||||
<entry>Reserved for future extensions. Applications and drivers must
|
||||
set the array to zero.</entry>
|
||||
</row>
|
||||
</tbody>
|
||||
</tgroup>
|
||||
</table>
|
||||
</refsect1>
|
||||
|
||||
<refsect1>
|
||||
&return-value;
|
||||
|
||||
<variablelist>
|
||||
<varlistentry>
|
||||
<term><errorcode>EBUSY</errorcode></term>
|
||||
<listitem>
|
||||
<para>The crop rectangle can't be changed because the pad is currently
|
||||
busy. This can be caused, for instance, by an active video stream on
|
||||
the pad. The ioctl must not be retried without performing another
|
||||
action to fix the problem first. Only returned by
|
||||
<constant>VIDIOC_SUBDEV_S_CROP</constant></para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
<varlistentry>
|
||||
<term><errorcode>EINVAL</errorcode></term>
|
||||
<listitem>
|
||||
<para>The &v4l2-subdev-crop; <structfield>pad</structfield>
|
||||
references a non-existing pad, the <structfield>which</structfield>
|
||||
field references a non-existing format, or cropping is not supported
|
||||
on the given subdev pad.</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
</variablelist>
|
||||
</refsect1>
|
||||
</refentry>
|
||||
|
|
@ -0,0 +1,180 @@
|
|||
<refentry id="vidioc-subdev-g-fmt">
|
||||
<refmeta>
|
||||
<refentrytitle>ioctl VIDIOC_SUBDEV_G_FMT, VIDIOC_SUBDEV_S_FMT</refentrytitle>
|
||||
&manvol;
|
||||
</refmeta>
|
||||
|
||||
<refnamediv>
|
||||
<refname>VIDIOC_SUBDEV_G_FMT</refname>
|
||||
<refname>VIDIOC_SUBDEV_S_FMT</refname>
|
||||
<refpurpose>Get or set the data format on a subdev pad</refpurpose>
|
||||
</refnamediv>
|
||||
|
||||
<refsynopsisdiv>
|
||||
<funcsynopsis>
|
||||
<funcprototype>
|
||||
<funcdef>int <function>ioctl</function></funcdef>
|
||||
<paramdef>int <parameter>fd</parameter></paramdef>
|
||||
<paramdef>int <parameter>request</parameter></paramdef>
|
||||
<paramdef>struct v4l2_subdev_format *<parameter>argp</parameter>
|
||||
</paramdef>
|
||||
</funcprototype>
|
||||
</funcsynopsis>
|
||||
</refsynopsisdiv>
|
||||
|
||||
<refsect1>
|
||||
<title>Arguments</title>
|
||||
|
||||
<variablelist>
|
||||
<varlistentry>
|
||||
<term><parameter>fd</parameter></term>
|
||||
<listitem>
|
||||
<para>&fd;</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
<varlistentry>
|
||||
<term><parameter>request</parameter></term>
|
||||
<listitem>
|
||||
<para>VIDIOC_SUBDEV_G_FMT, VIDIOC_SUBDEV_S_FMT</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
<varlistentry>
|
||||
<term><parameter>argp</parameter></term>
|
||||
<listitem>
|
||||
<para></para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
</variablelist>
|
||||
</refsect1>
|
||||
|
||||
<refsect1>
|
||||
<title>Description</title>
|
||||
|
||||
<note>
|
||||
<title>Experimental</title>
|
||||
<para>This is an <link linkend="experimental">experimental</link>
|
||||
interface and may change in the future.</para>
|
||||
</note>
|
||||
|
||||
<para>These ioctls are used to negotiate the frame format at specific
|
||||
subdev pads in the image pipeline.</para>
|
||||
|
||||
<para>To retrieve the current format applications set the
|
||||
<structfield>pad</structfield> field of a &v4l2-subdev-format; to the
|
||||
desired pad number as reported by the media API and the
|
||||
<structfield>which</structfield> field to
|
||||
<constant>V4L2_SUBDEV_FORMAT_ACTIVE</constant>. When they call the
|
||||
<constant>VIDIOC_SUBDEV_G_FMT</constant> ioctl with a pointer to this
|
||||
structure the driver fills the members of the <structfield>format</structfield>
|
||||
field.</para>
|
||||
|
||||
<para>To change the current format applications set both the
|
||||
<structfield>pad</structfield> and <structfield>which</structfield> fields
|
||||
and all members of the <structfield>format</structfield> field. When they
|
||||
call the <constant>VIDIOC_SUBDEV_S_FMT</constant> ioctl with a pointer to this
|
||||
structure the driver verifies the requested format, adjusts it based on the
|
||||
hardware capabilities and configures the device. Upon return the
|
||||
&v4l2-subdev-format; contains the current format as would be returned by a
|
||||
<constant>VIDIOC_SUBDEV_G_FMT</constant> call.</para>
|
||||
|
||||
<para>Applications can query the device capabilities by setting the
|
||||
<structfield>which</structfield> to
|
||||
<constant>V4L2_SUBDEV_FORMAT_TRY</constant>. When set, 'try' formats are not
|
||||
applied to the device by the driver, but are changed exactly as active
|
||||
formats and stored in the sub-device file handle. Two applications querying
|
||||
the same sub-device would thus not interact with each other.</para>
|
||||
|
||||
<para>For instance, to try a format at the output pad of a sub-device,
|
||||
applications would first set the try format at the sub-device input with the
|
||||
<constant>VIDIOC_SUBDEV_S_FMT</constant> ioctl. They would then either
|
||||
retrieve the default format at the output pad with the
|
||||
<constant>VIDIOC_SUBDEV_G_FMT</constant> ioctl, or set the desired output
|
||||
pad format with the <constant>VIDIOC_SUBDEV_S_FMT</constant> ioctl and check
|
||||
the returned value.</para>
|
||||
|
||||
<para>Try formats do not depend on active formats, but can depend on the
|
||||
current links configuration or sub-device controls value. For instance, a
|
||||
low-pass noise filter might crop pixels at the frame boundaries, modifying
|
||||
its output frame size.</para>
|
||||
|
||||
<para>Drivers must not return an error solely because the requested format
|
||||
doesn't match the device capabilities. They must instead modify the format
|
||||
to match what the hardware can provide. The modified format should be as
|
||||
close as possible to the original request.</para>
|
||||
|
||||
<table pgwide="1" frame="none" id="v4l2-subdev-format">
|
||||
<title>struct <structname>v4l2_subdev_format</structname></title>
|
||||
<tgroup cols="3">
|
||||
&cs-str;
|
||||
<tbody valign="top">
|
||||
<row>
|
||||
<entry>__u32</entry>
|
||||
<entry><structfield>pad</structfield></entry>
|
||||
<entry>Pad number as reported by the media controller API.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry>__u32</entry>
|
||||
<entry><structfield>which</structfield></entry>
|
||||
<entry>Format to modified, from &v4l2-subdev-format-whence;.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry>&v4l2-mbus-framefmt;</entry>
|
||||
<entry><structfield>format</structfield></entry>
|
||||
<entry>Definition of an image format, see <xref
|
||||
linkend="v4l2-mbus-framefmt" /> for details.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry>__u32</entry>
|
||||
<entry><structfield>reserved</structfield>[8]</entry>
|
||||
<entry>Reserved for future extensions. Applications and drivers must
|
||||
set the array to zero.</entry>
|
||||
</row>
|
||||
</tbody>
|
||||
</tgroup>
|
||||
</table>
|
||||
|
||||
<table pgwide="1" frame="none" id="v4l2-subdev-format-whence">
|
||||
<title>enum <structname>v4l2_subdev_format_whence</structname></title>
|
||||
<tgroup cols="3">
|
||||
&cs-def;
|
||||
<tbody valign="top">
|
||||
<row>
|
||||
<entry>V4L2_SUBDEV_FORMAT_TRY</entry>
|
||||
<entry>0</entry>
|
||||
<entry>Try formats, used for querying device capabilities.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry>V4L2_SUBDEV_FORMAT_ACTIVE</entry>
|
||||
<entry>1</entry>
|
||||
<entry>Active formats, applied to the hardware.</entry>
|
||||
</row>
|
||||
</tbody>
|
||||
</tgroup>
|
||||
</table>
|
||||
</refsect1>
|
||||
|
||||
<refsect1>
|
||||
&return-value;
|
||||
|
||||
<variablelist>
|
||||
<varlistentry>
|
||||
<term><errorcode>EBUSY</errorcode></term>
|
||||
<listitem>
|
||||
<para>The format can't be changed because the pad is currently busy.
|
||||
This can be caused, for instance, by an active video stream on the
|
||||
pad. The ioctl must not be retried without performing another action
|
||||
to fix the problem first. Only returned by
|
||||
<constant>VIDIOC_SUBDEV_S_FMT</constant></para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
<varlistentry>
|
||||
<term><errorcode>EINVAL</errorcode></term>
|
||||
<listitem>
|
||||
<para>The &v4l2-subdev-format; <structfield>pad</structfield>
|
||||
references a non-existing pad, or the <structfield>which</structfield>
|
||||
field references a non-existing format.</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
</variablelist>
|
||||
</refsect1>
|
||||
</refentry>
|
||||
|
|
@ -0,0 +1,141 @@
|
|||
<refentry id="vidioc-subdev-g-frame-interval">
|
||||
<refmeta>
|
||||
<refentrytitle>ioctl VIDIOC_SUBDEV_G_FRAME_INTERVAL, VIDIOC_SUBDEV_S_FRAME_INTERVAL</refentrytitle>
|
||||
&manvol;
|
||||
</refmeta>
|
||||
|
||||
<refnamediv>
|
||||
<refname>VIDIOC_SUBDEV_G_FRAME_INTERVAL</refname>
|
||||
<refname>VIDIOC_SUBDEV_S_FRAME_INTERVAL</refname>
|
||||
<refpurpose>Get or set the frame interval on a subdev pad</refpurpose>
|
||||
</refnamediv>
|
||||
|
||||
<refsynopsisdiv>
|
||||
<funcsynopsis>
|
||||
<funcprototype>
|
||||
<funcdef>int <function>ioctl</function></funcdef>
|
||||
<paramdef>int <parameter>fd</parameter></paramdef>
|
||||
<paramdef>int <parameter>request</parameter></paramdef>
|
||||
<paramdef>struct v4l2_subdev_frame_interval *<parameter>argp</parameter>
|
||||
</paramdef>
|
||||
</funcprototype>
|
||||
</funcsynopsis>
|
||||
</refsynopsisdiv>
|
||||
|
||||
<refsect1>
|
||||
<title>Arguments</title>
|
||||
|
||||
<variablelist>
|
||||
<varlistentry>
|
||||
<term><parameter>fd</parameter></term>
|
||||
<listitem>
|
||||
<para>&fd;</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
<varlistentry>
|
||||
<term><parameter>request</parameter></term>
|
||||
<listitem>
|
||||
<para>VIDIOC_SUBDEV_G_FRAME_INTERVAL, VIDIOC_SUBDEV_S_FRAME_INTERVAL</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
<varlistentry>
|
||||
<term><parameter>argp</parameter></term>
|
||||
<listitem>
|
||||
<para></para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
</variablelist>
|
||||
</refsect1>
|
||||
|
||||
<refsect1>
|
||||
<title>Description</title>
|
||||
|
||||
<note>
|
||||
<title>Experimental</title>
|
||||
<para>This is an <link linkend="experimental">experimental</link>
|
||||
interface and may change in the future.</para>
|
||||
</note>
|
||||
|
||||
<para>These ioctls are used to get and set the frame interval at specific
|
||||
subdev pads in the image pipeline. The frame interval only makes sense for
|
||||
sub-devices that can control the frame period on their own. This includes,
|
||||
for instance, image sensors and TV tuners. Sub-devices that don't support
|
||||
frame intervals must not implement these ioctls.</para>
|
||||
|
||||
<para>To retrieve the current frame interval applications set the
|
||||
<structfield>pad</structfield> field of a &v4l2-subdev-frame-interval; to
|
||||
the desired pad number as reported by the media controller API. When they
|
||||
call the <constant>VIDIOC_SUBDEV_G_FRAME_INTERVAL</constant> ioctl with a
|
||||
pointer to this structure the driver fills the members of the
|
||||
<structfield>interval</structfield> field.</para>
|
||||
|
||||
<para>To change the current frame interval applications set both the
|
||||
<structfield>pad</structfield> field and all members of the
|
||||
<structfield>interval</structfield> field. When they call the
|
||||
<constant>VIDIOC_SUBDEV_S_FRAME_INTERVAL</constant> ioctl with a pointer to
|
||||
this structure the driver verifies the requested interval, adjusts it based
|
||||
on the hardware capabilities and configures the device. Upon return the
|
||||
&v4l2-subdev-frame-interval; contains the current frame interval as would be
|
||||
returned by a <constant>VIDIOC_SUBDEV_G_FRAME_INTERVAL</constant> call.
|
||||
</para>
|
||||
|
||||
<para>Drivers must not return an error solely because the requested interval
|
||||
doesn't match the device capabilities. They must instead modify the interval
|
||||
to match what the hardware can provide. The modified interval should be as
|
||||
close as possible to the original request.</para>
|
||||
|
||||
<para>Sub-devices that support the frame interval ioctls should implement
|
||||
them on a single pad only. Their behaviour when supported on multiple pads
|
||||
of the same sub-device is not defined.</para>
|
||||
|
||||
<table pgwide="1" frame="none" id="v4l2-subdev-frame-interval">
|
||||
<title>struct <structname>v4l2_subdev_frame_interval</structname></title>
|
||||
<tgroup cols="3">
|
||||
&cs-str;
|
||||
<tbody valign="top">
|
||||
<row>
|
||||
<entry>__u32</entry>
|
||||
<entry><structfield>pad</structfield></entry>
|
||||
<entry>Pad number as reported by the media controller API.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry>&v4l2-fract;</entry>
|
||||
<entry><structfield>interval</structfield></entry>
|
||||
<entry>Period, in seconds, between consecutive video frames.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry>__u32</entry>
|
||||
<entry><structfield>reserved</structfield>[9]</entry>
|
||||
<entry>Reserved for future extensions. Applications and drivers must
|
||||
set the array to zero.</entry>
|
||||
</row>
|
||||
</tbody>
|
||||
</tgroup>
|
||||
</table>
|
||||
</refsect1>
|
||||
|
||||
<refsect1>
|
||||
&return-value;
|
||||
|
||||
<variablelist>
|
||||
<varlistentry>
|
||||
<term><errorcode>EBUSY</errorcode></term>
|
||||
<listitem>
|
||||
<para>The frame interval can't be changed because the pad is currently
|
||||
busy. This can be caused, for instance, by an active video stream on
|
||||
the pad. The ioctl must not be retried without performing another
|
||||
action to fix the problem first. Only returned by
|
||||
<constant>VIDIOC_SUBDEV_S_FRAME_INTERVAL</constant></para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
<varlistentry>
|
||||
<term><errorcode>EINVAL</errorcode></term>
|
||||
<listitem>
|
||||
<para>The &v4l2-subdev-frame-interval; <structfield>pad</structfield>
|
||||
references a non-existing pad, or the pad doesn't support frame
|
||||
intervals.</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
</variablelist>
|
||||
</refsect1>
|
||||
</refentry>
|
||||
|
|
@ -92,6 +92,11 @@ vendor_id: <integer>, device_id: <integer>
|
|||
class_code: <integer>]
|
||||
[serial number: <integer>, <integer>]
|
||||
[bridge: secondary_status: <integer>, control: <integer>]
|
||||
[aer_status: <integer>, aer_mask: <integer>
|
||||
<aer status string>
|
||||
[aer_uncor_severity: <integer>]
|
||||
aer_layer=<aer layer string>, aer_agent=<aer agent string>
|
||||
aer_tlp_header: <integer> <integer> <integer> <integer>]
|
||||
|
||||
<pcie port type string>* := PCIe end point | legacy PCI end point | \
|
||||
unknown | unknown | root port | upstream switch port | \
|
||||
|
|
@ -99,6 +104,26 @@ downstream switch port | PCIe to PCI/PCI-X bridge | \
|
|||
PCI/PCI-X to PCIe bridge | root complex integrated endpoint device | \
|
||||
root complex event collector
|
||||
|
||||
if section severity is fatal or recoverable
|
||||
<aer status string># :=
|
||||
unknown | unknown | unknown | unknown | Data Link Protocol | \
|
||||
unknown | unknown | unknown | unknown | unknown | unknown | unknown | \
|
||||
Poisoned TLP | Flow Control Protocol | Completion Timeout | \
|
||||
Completer Abort | Unexpected Completion | Receiver Overflow | \
|
||||
Malformed TLP | ECRC | Unsupported Request
|
||||
else
|
||||
<aer status string># :=
|
||||
Receiver Error | unknown | unknown | unknown | unknown | unknown | \
|
||||
Bad TLP | Bad DLLP | RELAY_NUM Rollover | unknown | unknown | unknown | \
|
||||
Replay Timer Timeout | Advisory Non-Fatal
|
||||
fi
|
||||
|
||||
<aer layer string> :=
|
||||
Physical Layer | Data Link Layer | Transaction Layer
|
||||
|
||||
<aer agent string> :=
|
||||
Receiver ID | Requester ID | Completer ID | Transmitter ID
|
||||
|
||||
Where, [] designate corresponding content is optional
|
||||
|
||||
All <field string> description with * has the following format:
|
||||
|
|
|
|||
|
|
@ -963,11 +963,6 @@ elevator_dispatch_fn* fills the dispatch queue with ready requests.
|
|||
|
||||
elevator_add_req_fn* called to add a new request into the scheduler
|
||||
|
||||
elevator_queue_empty_fn returns true if the merge queue is empty.
|
||||
Drivers shouldn't use this, but rather check
|
||||
if elv_next_request is NULL (without losing the
|
||||
request if one exists!)
|
||||
|
||||
elevator_former_req_fn
|
||||
elevator_latter_req_fn These return the request before or after the
|
||||
one specified in disk sort order. Used by the
|
||||
|
|
|
|||
|
|
@ -140,7 +140,7 @@ Proportional weight policy files
|
|||
- Specifies per cgroup weight. This is default weight of the group
|
||||
on all the devices until and unless overridden by per device rule.
|
||||
(See blkio.weight_device).
|
||||
Currently allowed range of weights is from 100 to 1000.
|
||||
Currently allowed range of weights is from 10 to 1000.
|
||||
|
||||
- blkio.weight_device
|
||||
- One can specify per cgroup per device rules using this interface.
|
||||
|
|
@ -343,34 +343,6 @@ Common files among various policies
|
|||
|
||||
CFQ sysfs tunable
|
||||
=================
|
||||
/sys/block/<disk>/queue/iosched/group_isolation
|
||||
-----------------------------------------------
|
||||
|
||||
If group_isolation=1, it provides stronger isolation between groups at the
|
||||
expense of throughput. By default group_isolation is 0. In general that
|
||||
means that if group_isolation=0, expect fairness for sequential workload
|
||||
only. Set group_isolation=1 to see fairness for random IO workload also.
|
||||
|
||||
Generally CFQ will put random seeky workload in sync-noidle category. CFQ
|
||||
will disable idling on these queues and it does a collective idling on group
|
||||
of such queues. Generally these are slow moving queues and if there is a
|
||||
sync-noidle service tree in each group, that group gets exclusive access to
|
||||
disk for certain period. That means it will bring the throughput down if
|
||||
group does not have enough IO to drive deeper queue depths and utilize disk
|
||||
capacity to the fullest in the slice allocated to it. But the flip side is
|
||||
that even a random reader should get better latencies and overall throughput
|
||||
if there are lots of sequential readers/sync-idle workload running in the
|
||||
system.
|
||||
|
||||
If group_isolation=0, then CFQ automatically moves all the random seeky queues
|
||||
in the root group. That means there will be no service differentiation for
|
||||
that kind of workload. This leads to better throughput as we do collective
|
||||
idling on root sync-noidle tree.
|
||||
|
||||
By default one should run with group_isolation=0. If that is not sufficient
|
||||
and one wants stronger isolation between groups, then set group_isolation=1
|
||||
but this will come at cost of reduced throughput.
|
||||
|
||||
/sys/block/<disk>/queue/iosched/slice_idle
|
||||
------------------------------------------
|
||||
On a faster hardware CFQ can be slow, especially with sequential workload.
|
||||
|
|
|
|||
|
|
@ -56,13 +56,13 @@ information on kernel development.
|
|||
|
||||
1.2: WHAT THIS DOCUMENT IS ABOUT
|
||||
|
||||
The Linux kernel, at over 6 million lines of code and well over 1000 active
|
||||
contributors, is one of the largest and most active free software projects
|
||||
in existence. Since its humble beginning in 1991, this kernel has evolved
|
||||
into a best-of-breed operating system component which runs on pocket-sized
|
||||
digital music players, desktop PCs, the largest supercomputers in
|
||||
existence, and all types of systems in between. It is a robust, efficient,
|
||||
and scalable solution for almost any situation.
|
||||
The Linux kernel, at over 8 million lines of code and well over 1000
|
||||
contributors to each release, is one of the largest and most active free
|
||||
software projects in existence. Since its humble beginning in 1991, this
|
||||
kernel has evolved into a best-of-breed operating system component which
|
||||
runs on pocket-sized digital music players, desktop PCs, the largest
|
||||
supercomputers in existence, and all types of systems in between. It is a
|
||||
robust, efficient, and scalable solution for almost any situation.
|
||||
|
||||
With the growth of Linux has come an increase in the number of developers
|
||||
(and companies) wishing to participate in its development. Hardware
|
||||
|
|
@ -115,7 +115,7 @@ This document was written by Jonathan Corbet, corbet@lwn.net. It has been
|
|||
improved by comments from Johannes Berg, James Berry, Alex Chiang, Roland
|
||||
Dreier, Randy Dunlap, Jake Edge, Jiri Kosina, Matt Mackall, Arthur Marsh,
|
||||
Amanda McPherson, Andrew Morton, Andrew Price, Tsugikazu Shibata, and
|
||||
Jochen Voß.
|
||||
Jochen Voß.
|
||||
|
||||
This work was supported by the Linux Foundation; thanks especially to
|
||||
Amanda McPherson, who saw the value of this effort and made it all happen.
|
||||
|
|
@ -221,7 +221,7 @@ include:
|
|||
- Everything that was said above about code review applies doubly to
|
||||
closed-source code. Since this code is not available at all, it cannot
|
||||
have been reviewed by the community and will, beyond doubt, have serious
|
||||
problems.
|
||||
problems.
|
||||
|
||||
Makers of embedded systems, in particular, may be tempted to disregard much
|
||||
of what has been said in this section in the belief that they are shipping
|
||||
|
|
|
|||
|
|
@ -14,16 +14,15 @@ The kernel developers use a loosely time-based release process, with a new
|
|||
major kernel release happening every two or three months. The recent
|
||||
release history looks like this:
|
||||
|
||||
2.6.26 July 13, 2008
|
||||
2.6.25 April 16, 2008
|
||||
2.6.24 January 24, 2008
|
||||
2.6.23 October 9, 2007
|
||||
2.6.22 July 8, 2007
|
||||
2.6.21 April 25, 2007
|
||||
2.6.20 February 4, 2007
|
||||
2.6.38 March 14, 2011
|
||||
2.6.37 January 4, 2011
|
||||
2.6.36 October 20, 2010
|
||||
2.6.35 August 1, 2010
|
||||
2.6.34 May 15, 2010
|
||||
2.6.33 February 24, 2010
|
||||
|
||||
Every 2.6.x release is a major kernel release with new features, internal
|
||||
API changes, and more. A typical 2.6 release can contain over 10,000
|
||||
API changes, and more. A typical 2.6 release can contain nearly 10,000
|
||||
changesets with changes to several hundred thousand lines of code. 2.6 is
|
||||
thus the leading edge of Linux kernel development; the kernel uses a
|
||||
rolling development model which is continually integrating major changes.
|
||||
|
|
@ -42,13 +41,13 @@ merge window do not come out of thin air; they have been collected, tested,
|
|||
and staged ahead of time. How that process works will be described in
|
||||
detail later on).
|
||||
|
||||
The merge window lasts for two weeks. At the end of this time, Linus
|
||||
Torvalds will declare that the window is closed and release the first of
|
||||
the "rc" kernels. For the kernel which is destined to be 2.6.26, for
|
||||
example, the release which happens at the end of the merge window will be
|
||||
called 2.6.26-rc1. The -rc1 release is the signal that the time to merge
|
||||
new features has passed, and that the time to stabilize the next kernel has
|
||||
begun.
|
||||
The merge window lasts for approximately two weeks. At the end of this
|
||||
time, Linus Torvalds will declare that the window is closed and release the
|
||||
first of the "rc" kernels. For the kernel which is destined to be 2.6.40,
|
||||
for example, the release which happens at the end of the merge window will
|
||||
be called 2.6.40-rc1. The -rc1 release is the signal that the time to
|
||||
merge new features has passed, and that the time to stabilize the next
|
||||
kernel has begun.
|
||||
|
||||
Over the next six to ten weeks, only patches which fix problems should be
|
||||
submitted to the mainline. On occasion a more significant change will be
|
||||
|
|
@ -66,20 +65,19 @@ will get up to somewhere between -rc6 and -rc9 before the kernel is
|
|||
considered to be sufficiently stable and the final 2.6.x release is made.
|
||||
At that point the whole process starts over again.
|
||||
|
||||
As an example, here is how the 2.6.25 development cycle went (all dates in
|
||||
2008):
|
||||
As an example, here is how the 2.6.38 development cycle went (all dates in
|
||||
2011):
|
||||
|
||||
January 24 2.6.24 stable release
|
||||
February 10 2.6.25-rc1, merge window closes
|
||||
February 15 2.6.25-rc2
|
||||
February 24 2.6.25-rc3
|
||||
March 4 2.6.25-rc4
|
||||
March 9 2.6.25-rc5
|
||||
March 16 2.6.25-rc6
|
||||
March 25 2.6.25-rc7
|
||||
April 1 2.6.25-rc8
|
||||
April 11 2.6.25-rc9
|
||||
April 16 2.6.25 stable release
|
||||
January 4 2.6.37 stable release
|
||||
January 18 2.6.38-rc1, merge window closes
|
||||
January 21 2.6.38-rc2
|
||||
February 1 2.6.38-rc3
|
||||
February 7 2.6.38-rc4
|
||||
February 15 2.6.38-rc5
|
||||
February 21 2.6.38-rc6
|
||||
March 1 2.6.38-rc7
|
||||
March 7 2.6.38-rc8
|
||||
March 14 2.6.38 stable release
|
||||
|
||||
How do the developers decide when to close the development cycle and create
|
||||
the stable release? The most significant metric used is the list of
|
||||
|
|
@ -87,7 +85,7 @@ regressions from previous releases. No bugs are welcome, but those which
|
|||
break systems which worked in the past are considered to be especially
|
||||
serious. For this reason, patches which cause regressions are looked upon
|
||||
unfavorably and are quite likely to be reverted during the stabilization
|
||||
period.
|
||||
period.
|
||||
|
||||
The developers' goal is to fix all known regressions before the stable
|
||||
release is made. In the real world, this kind of perfection is hard to
|
||||
|
|
@ -99,26 +97,34 @@ kernels go out with a handful of known regressions though, hopefully, none
|
|||
of them are serious.
|
||||
|
||||
Once a stable release is made, its ongoing maintenance is passed off to the
|
||||
"stable team," currently comprised of Greg Kroah-Hartman and Chris Wright.
|
||||
The stable team will release occasional updates to the stable release using
|
||||
the 2.6.x.y numbering scheme. To be considered for an update release, a
|
||||
patch must (1) fix a significant bug, and (2) already be merged into the
|
||||
mainline for the next development kernel. Continuing our 2.6.25 example,
|
||||
the history (as of this writing) is:
|
||||
"stable team," currently consisting of Greg Kroah-Hartman. The stable team
|
||||
will release occasional updates to the stable release using the 2.6.x.y
|
||||
numbering scheme. To be considered for an update release, a patch must (1)
|
||||
fix a significant bug, and (2) already be merged into the mainline for the
|
||||
next development kernel. Kernels will typically receive stable updates for
|
||||
a little more than one development cycle past their initial release. So,
|
||||
for example, the 2.6.36 kernel's history looked like:
|
||||
|
||||
May 1 2.6.25.1
|
||||
May 6 2.6.25.2
|
||||
May 9 2.6.25.3
|
||||
May 15 2.6.25.4
|
||||
June 7 2.6.25.5
|
||||
June 9 2.6.25.6
|
||||
June 16 2.6.25.7
|
||||
June 21 2.6.25.8
|
||||
June 24 2.6.25.9
|
||||
October 10 2.6.36 stable release
|
||||
November 22 2.6.36.1
|
||||
December 9 2.6.36.2
|
||||
January 7 2.6.36.3
|
||||
February 17 2.6.36.4
|
||||
|
||||
Stable updates for a given kernel are made for approximately six months;
|
||||
after that, the maintenance of stable releases is solely the responsibility
|
||||
of the distributors which have shipped that particular kernel.
|
||||
2.6.36.4 was the final stable update for the 2.6.36 release.
|
||||
|
||||
Some kernels are designated "long term" kernels; they will receive support
|
||||
for a longer period. As of this writing, the current long term kernels
|
||||
and their maintainers are:
|
||||
|
||||
2.6.27 Willy Tarreau (Deep-frozen stable kernel)
|
||||
2.6.32 Greg Kroah-Hartman
|
||||
2.6.35 Andi Kleen (Embedded flag kernel)
|
||||
|
||||
The selection of a kernel for long-term support is purely a matter of a
|
||||
maintainer having the need and the time to maintain that release. There
|
||||
are no known plans for long-term support for any specific upcoming
|
||||
release.
|
||||
|
||||
|
||||
2.2: THE LIFECYCLE OF A PATCH
|
||||
|
|
@ -130,7 +136,7 @@ each patch implements a change which is desirable to have in the mainline.
|
|||
This process can happen quickly for minor fixes, or, in the case of large
|
||||
and controversial changes, go on for years. Much developer frustration
|
||||
comes from a lack of understanding of this process or from attempts to
|
||||
circumvent it.
|
||||
circumvent it.
|
||||
|
||||
In the hopes of reducing that frustration, this document will describe how
|
||||
a patch gets into the kernel. What follows below is an introduction which
|
||||
|
|
@ -193,8 +199,8 @@ involved.
|
|||
2.3: HOW PATCHES GET INTO THE KERNEL
|
||||
|
||||
There is exactly one person who can merge patches into the mainline kernel
|
||||
repository: Linus Torvalds. But, of the over 12,000 patches which went
|
||||
into the 2.6.25 kernel, only 250 (around 2%) were directly chosen by Linus
|
||||
repository: Linus Torvalds. But, of the over 9,500 patches which went
|
||||
into the 2.6.38 kernel, only 112 (around 1.3%) were directly chosen by Linus
|
||||
himself. The kernel project has long since grown to a size where no single
|
||||
developer could possibly inspect and select every patch unassisted. The
|
||||
way the kernel developers have addressed this growth is through the use of
|
||||
|
|
@ -229,7 +235,7 @@ first in trees dedicated to network device drivers, wireless networking,
|
|||
etc. This chain of repositories can be arbitrarily long, though it rarely
|
||||
exceeds two or three links. Since each maintainer in the chain trusts
|
||||
those managing lower-level trees, this process is known as the "chain of
|
||||
trust."
|
||||
trust."
|
||||
|
||||
Clearly, in a system like this, getting patches into the kernel depends on
|
||||
finding the right maintainer. Sending patches directly to Linus is not
|
||||
|
|
@ -254,7 +260,7 @@ The answer comes in the form of -next trees, where subsystem trees are
|
|||
collected for testing and review. The older of these trees, maintained by
|
||||
Andrew Morton, is called "-mm" (for memory management, which is how it got
|
||||
started). The -mm tree integrates patches from a long list of subsystem
|
||||
trees; it also has some patches aimed at helping with debugging.
|
||||
trees; it also has some patches aimed at helping with debugging.
|
||||
|
||||
Beyond that, -mm contains a significant collection of patches which have
|
||||
been selected by Andrew directly. These patches may have been posted on a
|
||||
|
|
@ -264,8 +270,8 @@ subsystem tree of last resort; if there is no other obvious path for a
|
|||
patch into the mainline, it is likely to end up in -mm. Miscellaneous
|
||||
patches which accumulate in -mm will eventually either be forwarded on to
|
||||
an appropriate subsystem tree or be sent directly to Linus. In a typical
|
||||
development cycle, approximately 10% of the patches going into the mainline
|
||||
get there via -mm.
|
||||
development cycle, approximately 5-10% of the patches going into the
|
||||
mainline get there via -mm.
|
||||
|
||||
The current -mm patch is available in the "mmotm" (-mm of the moment)
|
||||
directory at:
|
||||
|
|
@ -275,7 +281,7 @@ directory at:
|
|||
Use of the MMOTM tree is likely to be a frustrating experience, though;
|
||||
there is a definite chance that it will not even compile.
|
||||
|
||||
The other -next tree, started more recently, is linux-next, maintained by
|
||||
The primary tree for next-cycle patch merging is linux-next, maintained by
|
||||
Stephen Rothwell. The linux-next tree is, by design, a snapshot of what
|
||||
the mainline is expected to look like after the next merge window closes.
|
||||
Linux-next trees are announced on the linux-kernel and linux-next mailing
|
||||
|
|
@ -287,25 +293,14 @@ Some information about linux-next has been gathered at:
|
|||
|
||||
http://linux.f-seidel.de/linux-next/pmwiki/
|
||||
|
||||
How the linux-next tree will fit into the development process is still
|
||||
changing. As of this writing, the first full development cycle involving
|
||||
linux-next (2.6.26) is coming to an end; thus far, it has proved to be a
|
||||
valuable resource for finding and fixing integration problems before the
|
||||
beginning of the merge window. See http://lwn.net/Articles/287155/ for
|
||||
more information on how linux-next has worked to set up the 2.6.27 merge
|
||||
window.
|
||||
Linux-next has become an integral part of the kernel development process;
|
||||
all patches merged during a given merge window should really have found
|
||||
their way into linux-next some time before the merge window opens.
|
||||
|
||||
Some developers have begun to suggest that linux-next should be used as the
|
||||
target for future development as well. The linux-next tree does tend to be
|
||||
far ahead of the mainline and is more representative of the tree into which
|
||||
any new work will be merged. The downside to this idea is that the
|
||||
volatility of linux-next tends to make it a difficult development target.
|
||||
See http://lwn.net/Articles/289013/ for more information on this topic, and
|
||||
stay tuned; much is still in flux where linux-next is involved.
|
||||
|
||||
2.4.1: STAGING TREES
|
||||
|
||||
The kernel source tree now contains the drivers/staging/ directory, where
|
||||
The kernel source tree contains the drivers/staging/ directory, where
|
||||
many sub-directories for drivers or filesystems that are on their way to
|
||||
being added to the kernel tree live. They remain in drivers/staging while
|
||||
they still need more work; once complete, they can be moved into the
|
||||
|
|
@ -313,15 +308,23 @@ kernel proper. This is a way to keep track of drivers that aren't
|
|||
up to Linux kernel coding or quality standards, but people may want to use
|
||||
them and track development.
|
||||
|
||||
Greg Kroah-Hartman currently (as of 2.6.36) maintains the staging tree.
|
||||
Drivers that still need work are sent to him, with each driver having
|
||||
its own subdirectory in drivers/staging/. Along with the driver source
|
||||
files, a TODO file should be present in the directory as well. The TODO
|
||||
file lists the pending work that the driver needs for acceptance into
|
||||
the kernel proper, as well as a list of people that should be Cc'd for any
|
||||
patches to the driver. Staging drivers that don't currently build should
|
||||
have their config entries depend upon CONFIG_BROKEN. Once they can
|
||||
be successfully built without outside patches, CONFIG_BROKEN can be removed.
|
||||
Greg Kroah-Hartman currently maintains the staging tree. Drivers that
|
||||
still need work are sent to him, with each driver having its own
|
||||
subdirectory in drivers/staging/. Along with the driver source files, a
|
||||
TODO file should be present in the directory as well. The TODO file lists
|
||||
the pending work that the driver needs for acceptance into the kernel
|
||||
proper, as well as a list of people that should be Cc'd for any patches to
|
||||
the driver. Current rules require that drivers contributed to staging
|
||||
must, at a minimum, compile properly.
|
||||
|
||||
Staging can be a relatively easy way to get new drivers into the mainline
|
||||
where, with luck, they will come to the attention of other developers and
|
||||
improve quickly. Entry into staging is not the end of the story, though;
|
||||
code in staging which is not seeing regular progress will eventually be
|
||||
removed. Distributors also tend to be relatively reluctant to enable
|
||||
staging drivers. So staging is, at best, a stop on the way toward becoming
|
||||
a proper mainline driver.
|
||||
|
||||
|
||||
2.5: TOOLS
|
||||
|
||||
|
|
@ -347,11 +350,7 @@ page at:
|
|||
|
||||
http://git-scm.com/
|
||||
|
||||
That page has pointers to documentation and tutorials. One should be
|
||||
aware, in particular, of the Kernel Hacker's Guide to git, which has
|
||||
information specific to kernel development:
|
||||
|
||||
http://linux.yyz.us/git-howto.html
|
||||
That page has pointers to documentation and tutorials.
|
||||
|
||||
Among the kernel developers who do not use git, the most popular choice is
|
||||
almost certainly Mercurial:
|
||||
|
|
@ -408,7 +407,7 @@ There are a few hints which can help with linux-kernel survival:
|
|||
important to filter on both the topic of interest (though note that
|
||||
long-running conversations can drift away from the original subject
|
||||
without changing the email subject line) and the people who are
|
||||
participating.
|
||||
participating.
|
||||
|
||||
- Do not feed the trolls. If somebody is trying to stir up an angry
|
||||
response, ignore them.
|
||||
|
|
|
|||
|
|
@ -110,8 +110,8 @@ the kernel community's standards. Some examples include:
|
|||
|
||||
- The AppArmor security module made use of internal virtual filesystem
|
||||
data structures in ways which were considered to be unsafe and
|
||||
unreliable. This code has since been significantly reworked, but
|
||||
remains outside of the mainline.
|
||||
unreliable. This concern (among others) kept AppArmor out of the
|
||||
mainline for years.
|
||||
|
||||
In each of these cases, a great deal of pain and extra work could have been
|
||||
avoided with some early discussion with the kernel developers.
|
||||
|
|
@ -138,6 +138,19 @@ patches, and who, if anybody, is attaching Signed-off-by lines to those
|
|||
patches. Those are the people who will be best placed to help with a new
|
||||
development project.
|
||||
|
||||
The task of finding the right maintainer is sometimes challenging enough
|
||||
that the kernel developers have added a script to ease the process:
|
||||
|
||||
.../scripts/get_maintainer.pl
|
||||
|
||||
This script will return the current maintainer(s) for a given file or
|
||||
directory when given the "-f" option. If passed a patch on the
|
||||
command line, it will list the maintainers who should probably receive
|
||||
copies of the patch. There are a number of options regulating how hard
|
||||
get_maintainer.pl will search for maintainers; please be careful about
|
||||
using the more aggressive options as you may end up including developers
|
||||
who have no real interest in the code you are modifying.
|
||||
|
||||
If all else fails, talking to Andrew Morton can be an effective way to
|
||||
track down a maintainer for a specific piece of code.
|
||||
|
||||
|
|
@ -155,11 +168,15 @@ reaction, but, instead, little or no reaction at all. The sad truth of the
|
|||
matter is (1) kernel developers tend to be busy, (2) there is no shortage
|
||||
of people with grand plans and little code (or even prospect of code) to
|
||||
back them up, and (3) nobody is obligated to review or comment on ideas
|
||||
posted by others. If a request-for-comments posting yields little in the
|
||||
way of comments, do not assume that it means there is no interest in the
|
||||
project. Unfortunately, you also cannot assume that there are no problems
|
||||
with your idea. The best thing to do in this situation is to proceed,
|
||||
keeping the community informed as you go.
|
||||
posted by others. Beyond that, high-level designs often hide problems
|
||||
which are only reviewed when somebody actually tries to implement those
|
||||
designs; for that reason, kernel developers would rather see the code.
|
||||
|
||||
If a request-for-comments posting yields little in the way of comments, do
|
||||
not assume that it means there is no interest in the project.
|
||||
Unfortunately, you also cannot assume that there are no problems with your
|
||||
idea. The best thing to do in this situation is to proceed, keeping the
|
||||
community informed as you go.
|
||||
|
||||
|
||||
3.5: GETTING OFFICIAL BUY-IN
|
||||
|
|
|
|||
|
|
@ -131,6 +131,11 @@ classic time/space tradeoff taught in beginning data structures classes
|
|||
often does not apply to contemporary hardware. Space *is* time, in that a
|
||||
larger program will run slower than one which is more compact.
|
||||
|
||||
More recent compilers take an increasingly active role in deciding whether
|
||||
a given function should actually be inlined or not. So the liberal
|
||||
placement of "inline" keywords may not just be excessive; it could also be
|
||||
irrelevant.
|
||||
|
||||
|
||||
* Locking
|
||||
|
||||
|
|
@ -285,6 +290,13 @@ be found at https://sparse.wiki.kernel.org/index.php/Main_Page if your
|
|||
distributor does not package it); it can then be run on the code by adding
|
||||
"C=1" to your make command.
|
||||
|
||||
The "Coccinelle" tool (http://coccinelle.lip6.fr/) is able to find a wide
|
||||
variety of potential coding problems; it can also propose fixes for those
|
||||
problems. Quite a few "semantic patches" for the kernel have been packaged
|
||||
under the scripts/coccinelle directory; running "make coccicheck" will run
|
||||
through those semantic patches and report on any problems found. See
|
||||
Documentation/coccinelle.txt for more information.
|
||||
|
||||
Other kinds of portability errors are best found by compiling your code for
|
||||
other architectures. If you do not happen to have an S/390 system or a
|
||||
Blackfin development board handy, you can still perform the compilation
|
||||
|
|
@ -308,7 +320,9 @@ The first piece of documentation for any patch is its associated
|
|||
changelog. Log entries should describe the problem being solved, the form
|
||||
of the solution, the people who worked on the patch, any relevant
|
||||
effects on performance, and anything else that might be needed to
|
||||
understand the patch.
|
||||
understand the patch. Be sure that the changelog says *why* the patch is
|
||||
worth applying; a surprising number of developers fail to provide that
|
||||
information.
|
||||
|
||||
Any code which adds a new user-space interface - including new sysfs or
|
||||
/proc files - should include documentation of that interface which enables
|
||||
|
|
@ -321,7 +335,7 @@ boot-time parameters. Any patch which adds new parameters should add the
|
|||
appropriate entries to this file.
|
||||
|
||||
Any new configuration options must be accompanied by help text which
|
||||
clearly explains the options and when the user might want to select them.
|
||||
clearly explains the options and when the user might want to select them.
|
||||
|
||||
Internal API information for many subsystems is documented by way of
|
||||
specially-formatted comments; these comments can be extracted and formatted
|
||||
|
|
@ -372,7 +386,8 @@ which is broken by the change. For a widely-used function, this duty can
|
|||
lead to literally hundreds or thousands of changes - many of which are
|
||||
likely to conflict with work being done by other developers. Needless to
|
||||
say, this can be a large job, so it is best to be sure that the
|
||||
justification is solid.
|
||||
justification is solid. Note that the Coccinelle tool can help with
|
||||
wide-ranging API changes.
|
||||
|
||||
When making an incompatible API change, one should, whenever possible,
|
||||
ensure that code which has not been updated is caught by the compiler.
|
||||
|
|
|
|||
|
|
@ -60,12 +60,15 @@ even in the short term.
|
|||
|
||||
Patches must be prepared against a specific version of the kernel. As a
|
||||
general rule, a patch should be based on the current mainline as found in
|
||||
Linus's git tree. It may become necessary to make versions against -mm,
|
||||
linux-next, or a subsystem tree, though, to facilitate wider testing and
|
||||
review. Depending on the area of your patch and what is going on
|
||||
elsewhere, basing a patch against these other trees can require a
|
||||
significant amount of work resolving conflicts and dealing with API
|
||||
changes.
|
||||
Linus's git tree. When basing on mainline, start with a well-known release
|
||||
point - a stable or -rc release - rather than branching off the mainline at
|
||||
an arbitrary spot.
|
||||
|
||||
It may become necessary to make versions against -mm, linux-next, or a
|
||||
subsystem tree, though, to facilitate wider testing and review. Depending
|
||||
on the area of your patch and what is going on elsewhere, basing a patch
|
||||
against these other trees can require a significant amount of work
|
||||
resolving conflicts and dealing with API changes.
|
||||
|
||||
Only the most simple changes should be formatted as a single patch;
|
||||
everything else should be made as a logical series of changes. Splitting
|
||||
|
|
@ -100,11 +103,11 @@ rules of thumb, however, which can help considerably:
|
|||
result is a broken kernel, you will make life harder for developers and
|
||||
users who are engaging in the noble work of tracking down problems.
|
||||
|
||||
- Do not overdo it, though. One developer recently posted a set of edits
|
||||
- Do not overdo it, though. One developer once posted a set of edits
|
||||
to a single file as 500 separate patches - an act which did not make him
|
||||
the most popular person on the kernel mailing list. A single patch can
|
||||
be reasonably large as long as it still contains a single *logical*
|
||||
change.
|
||||
change.
|
||||
|
||||
- It can be tempting to add a whole new infrastructure with a series of
|
||||
patches, but to leave that infrastructure unused until the final patch
|
||||
|
|
@ -162,7 +165,8 @@ To that end, the summary line should describe the effects of and motivation
|
|||
for the change as well as possible given the one-line constraint. The
|
||||
detailed description can then amplify on those topics and provide any
|
||||
needed additional information. If the patch fixes a bug, cite the commit
|
||||
which introduced the bug if possible. If a problem is associated with
|
||||
which introduced the bug if possible (and please provide both the commit ID
|
||||
and the title when citing commits). If a problem is associated with
|
||||
specific log or compiler output, include that output to help others
|
||||
searching for a solution to the same problem. If the change is meant to
|
||||
support other changes coming in later patch, say so. If internal APIs are
|
||||
|
|
@ -230,7 +234,7 @@ take care of:
|
|||
which have had gratuitous white-space changes or line wrapping performed
|
||||
by the mail client will not apply at the other end, and often will not
|
||||
be examined in any detail. If there is any doubt at all, mail the patch
|
||||
to yourself and convince yourself that it shows up intact.
|
||||
to yourself and convince yourself that it shows up intact.
|
||||
|
||||
Documentation/email-clients.txt has some helpful hints on making
|
||||
specific mail clients work for sending patches.
|
||||
|
|
@ -287,7 +291,7 @@ something like:
|
|||
|
||||
where "nn" is the ordinal number of the patch, "mm" is the total number of
|
||||
patches in the series, and "subsys" is the name of the affected subsystem.
|
||||
Clearly, nn/mm can be omitted for a single, standalone patch.
|
||||
Clearly, nn/mm can be omitted for a single, standalone patch.
|
||||
|
||||
If you have a significant series of patches, it is customary to send an
|
||||
introductory description as part zero. This convention is not universally
|
||||
|
|
@ -299,5 +303,5 @@ In general, the second and following parts of a multi-part patch should be
|
|||
sent as a reply to the first part so that they all thread together at the
|
||||
receiving end. Tools like git and quilt have commands to mail out a set of
|
||||
patches with the proper threading. If you have a long series, though, and
|
||||
are using git, please provide the --no-chain-reply-to option to avoid
|
||||
are using git, please stay away from the --chain-reply-to option to avoid
|
||||
creating exceptionally deep nesting.
|
||||
|
|
|
|||
|
|
@ -66,6 +66,11 @@ be easy to become blinded by your own solution to a problem to the point
|
|||
that you don't realize that something is fundamentally wrong or, perhaps,
|
||||
you're not even solving the right problem.
|
||||
|
||||
Andrew Morton has suggested that every review comment which does not result
|
||||
in a code change should result in an additional code comment instead; that
|
||||
can help future reviewers avoid the questions which came up the first time
|
||||
around.
|
||||
|
||||
One fatal mistake is to ignore review comments in the hope that they will
|
||||
go away. They will not go away. If you repost code without having
|
||||
responded to the comments you got the time before, you're likely to find
|
||||
|
|
@ -100,7 +105,7 @@ entry into a subsystem maintainer's tree. How that works varies from one
|
|||
subsystem to the next; each maintainer has his or her own way of doing
|
||||
things. In particular, there may be more than one tree - one, perhaps,
|
||||
dedicated to patches planned for the next merge window, and another for
|
||||
longer-term work.
|
||||
longer-term work.
|
||||
|
||||
For patches applying to areas for which there is no obvious subsystem tree
|
||||
(memory management patches, for example), the default tree often ends up
|
||||
|
|
@ -109,11 +114,10 @@ through the -mm tree.
|
|||
|
||||
Inclusion into a subsystem tree can bring a higher level of visibility to a
|
||||
patch. Now other developers working with that tree will get the patch by
|
||||
default. Subsystem trees typically feed into -mm and linux-next as well,
|
||||
making their contents visible to the development community as a whole. At
|
||||
this point, there's a good chance that you will get more comments from a
|
||||
new set of reviewers; these comments need to be answered as in the previous
|
||||
round.
|
||||
default. Subsystem trees typically feed linux-next as well, making their
|
||||
contents visible to the development community as a whole. At this point,
|
||||
there's a good chance that you will get more comments from a new set of
|
||||
reviewers; these comments need to be answered as in the previous round.
|
||||
|
||||
What may also happen at this point, depending on the nature of your patch,
|
||||
is that conflicts with work being done by others turn up. In the worst
|
||||
|
|
|
|||
|
|
@ -119,7 +119,7 @@ can affect your ability to get trees pulled in the future. Quoting Linus:
|
|||
to trust things *without* then having to go and check every
|
||||
individual change by hand.
|
||||
|
||||
(http://lwn.net/Articles/224135/).
|
||||
(http://lwn.net/Articles/224135/).
|
||||
|
||||
To avoid this kind of situation, ensure that all patches within a given
|
||||
branch stick closely to the associated topic; a "driver fixes" branch
|
||||
|
|
@ -138,7 +138,7 @@ When requesting a pull, be sure to give all the relevant information: where
|
|||
your tree is, what branch to pull, and what changes will result from the
|
||||
pull. The git request-pull command can be helpful in this regard; it will
|
||||
format the request as other developers expect, and will also check to be
|
||||
sure that you have remembered to push those changes to the public server.
|
||||
sure that you have remembered to push those changes to the public server.
|
||||
|
||||
|
||||
7.2: REVIEWING PATCHES
|
||||
|
|
|
|||
|
|
@ -0,0 +1,17 @@
|
|||
dm-flakey
|
||||
=========
|
||||
|
||||
This target is the same as the linear target except that it returns I/O
|
||||
errors periodically. It's been found useful in simulating failing
|
||||
devices for testing purposes.
|
||||
|
||||
Starting from the time the table is loaded, the device is available for
|
||||
<up interval> seconds, then returns errors for <down interval> seconds,
|
||||
and then this cycle repeats.
|
||||
|
||||
Parameters: <dev path> <offset> <up interval> <down interval>
|
||||
<dev path>: Full pathname to the underlying block-device, or a
|
||||
"major:minor" device-number.
|
||||
<offset>: Starting sector within the device.
|
||||
<up interval>: Number of seconds device is available.
|
||||
<down interval>: Number of seconds device returns errors.
|
||||
|
|
@ -0,0 +1,34 @@
|
|||
* SM SM501
|
||||
|
||||
The SM SM501 is a LCD controller, with proper hardware, it can also
|
||||
drive DVI monitors.
|
||||
|
||||
Required properties:
|
||||
- compatible : should be "smi,sm501".
|
||||
- reg : contain two entries:
|
||||
- First entry: System Configuration register
|
||||
- Second entry: IO space (Display Controller register)
|
||||
- interrupts : SMI interrupt to the cpu should be described here.
|
||||
- interrupt-parent : the phandle for the interrupt controller that
|
||||
services interrupts for this device.
|
||||
|
||||
Optional properties:
|
||||
- mode : select a video mode:
|
||||
<xres>x<yres>[-<bpp>][@<refresh>]
|
||||
- edid : verbatim EDID data block describing attached display.
|
||||
Data from the detailed timing descriptor will be used to
|
||||
program the display controller.
|
||||
- little-endian: availiable on big endian systems, to
|
||||
set different foreign endian.
|
||||
- big-endian: availiable on little endian systems, to
|
||||
set different foreign endian.
|
||||
|
||||
Example for MPC5200:
|
||||
display@1,0 {
|
||||
compatible = "smi,sm501";
|
||||
reg = <1 0x00000000 0x00800000
|
||||
1 0x03e00000 0x00200000>;
|
||||
interrupts = <1 1 3>;
|
||||
mode = "640x480-32@60";
|
||||
edid = [edid-data];
|
||||
};
|
||||
|
|
@ -0,0 +1,73 @@
|
|||
ADS1015 (I2C)
|
||||
|
||||
This device is a 12-bit A-D converter with 4 inputs.
|
||||
|
||||
The inputs can be used single ended or in certain differential combinations.
|
||||
|
||||
For configuration all possible combinations are mapped to 8 channels:
|
||||
0: Voltage over AIN0 and AIN1.
|
||||
1: Voltage over AIN0 and AIN3.
|
||||
2: Voltage over AIN1 and AIN3.
|
||||
3: Voltage over AIN2 and AIN3.
|
||||
4: Voltage over AIN0 and GND.
|
||||
5: Voltage over AIN1 and GND.
|
||||
6: Voltage over AIN2 and GND.
|
||||
7: Voltage over AIN3 and GND.
|
||||
|
||||
Each channel can be configured individually:
|
||||
- pga is the programmable gain amplifier (values are full scale)
|
||||
0: +/- 6.144 V
|
||||
1: +/- 4.096 V
|
||||
2: +/- 2.048 V (default)
|
||||
3: +/- 1.024 V
|
||||
4: +/- 0.512 V
|
||||
5: +/- 0.256 V
|
||||
- data_rate in samples per second
|
||||
0: 128
|
||||
1: 250
|
||||
2: 490
|
||||
3: 920
|
||||
4: 1600 (default)
|
||||
5: 2400
|
||||
6: 3300
|
||||
|
||||
1) The /ads1015 node
|
||||
|
||||
Required properties:
|
||||
|
||||
- compatible : must be "ti,ads1015"
|
||||
- reg : I2C bus address of the device
|
||||
- #address-cells : must be <1>
|
||||
- #size-cells : must be <0>
|
||||
|
||||
The node contains child nodes for each channel that the platform uses.
|
||||
|
||||
Example ADS1015 node:
|
||||
|
||||
ads1015@49 {
|
||||
compatible = "ti,ads1015";
|
||||
reg = <0x49>;
|
||||
#address-cells = <1>;
|
||||
#size-cells = <0>;
|
||||
|
||||
[ child node definitions... ]
|
||||
}
|
||||
|
||||
2) channel nodes
|
||||
|
||||
Required properties:
|
||||
|
||||
- reg : the channel number
|
||||
|
||||
Optional properties:
|
||||
|
||||
- ti,gain : the programmable gain amplifier setting
|
||||
- ti,datarate : the converter data rate
|
||||
|
||||
Example ADS1015 channel node:
|
||||
|
||||
channel@4 {
|
||||
reg = <4>;
|
||||
ti,gain = <3>;
|
||||
ti,datarate = <5>;
|
||||
};
|
||||
|
|
@ -0,0 +1,98 @@
|
|||
* Open PIC Binding
|
||||
|
||||
This binding specifies what properties must be available in the device tree
|
||||
representation of an Open PIC compliant interrupt controller. This binding is
|
||||
based on the binding defined for Open PIC in [1] and is a superset of that
|
||||
binding.
|
||||
|
||||
Required properties:
|
||||
|
||||
NOTE: Many of these descriptions were paraphrased here from [1] to aid
|
||||
readability.
|
||||
|
||||
- compatible: Specifies the compatibility list for the PIC. The type
|
||||
shall be <string> and the value shall include "open-pic".
|
||||
|
||||
- reg: Specifies the base physical address(s) and size(s) of this
|
||||
PIC's addressable register space. The type shall be <prop-encoded-array>.
|
||||
|
||||
- interrupt-controller: The presence of this property identifies the node
|
||||
as an Open PIC. No property value shall be defined.
|
||||
|
||||
- #interrupt-cells: Specifies the number of cells needed to encode an
|
||||
interrupt source. The type shall be a <u32> and the value shall be 2.
|
||||
|
||||
- #address-cells: Specifies the number of cells needed to encode an
|
||||
address. The type shall be <u32> and the value shall be 0. As such,
|
||||
'interrupt-map' nodes do not have to specify a parent unit address.
|
||||
|
||||
Optional properties:
|
||||
|
||||
- pic-no-reset: The presence of this property indicates that the PIC
|
||||
shall not be reset during runtime initialization. No property value shall
|
||||
be defined. The presence of this property also mandates that any
|
||||
initialization related to interrupt sources shall be limited to sources
|
||||
explicitly referenced in the device tree.
|
||||
|
||||
* Interrupt Specifier Definition
|
||||
|
||||
Interrupt specifiers consists of 2 cells encoded as
|
||||
follows:
|
||||
|
||||
- <1st-cell>: The interrupt-number that identifies the interrupt source.
|
||||
|
||||
- <2nd-cell>: The level-sense information, encoded as follows:
|
||||
0 = low-to-high edge triggered
|
||||
1 = active low level-sensitive
|
||||
2 = active high level-sensitive
|
||||
3 = high-to-low edge triggered
|
||||
|
||||
* Examples
|
||||
|
||||
Example 1:
|
||||
|
||||
/*
|
||||
* An Open PIC interrupt controller
|
||||
*/
|
||||
mpic: pic@40000 {
|
||||
// This is an interrupt controller node.
|
||||
interrupt-controller;
|
||||
|
||||
// No address cells so that 'interrupt-map' nodes which reference
|
||||
// this Open PIC node do not need a parent address specifier.
|
||||
#address-cells = <0>;
|
||||
|
||||
// Two cells to encode interrupt sources.
|
||||
#interrupt-cells = <2>;
|
||||
|
||||
// Offset address of 0x40000 and size of 0x40000.
|
||||
reg = <0x40000 0x40000>;
|
||||
|
||||
// Compatible with Open PIC.
|
||||
compatible = "open-pic";
|
||||
|
||||
// The PIC shall not be reset.
|
||||
pic-no-reset;
|
||||
};
|
||||
|
||||
Example 2:
|
||||
|
||||
/*
|
||||
* An interrupt generating device that is wired to an Open PIC.
|
||||
*/
|
||||
serial0: serial@4500 {
|
||||
// Interrupt source '42' that is active high level-sensitive.
|
||||
// Note that there are only two cells as specified in the interrupt
|
||||
// parent's '#interrupt-cells' property.
|
||||
interrupts = <42 2>;
|
||||
|
||||
// The interrupt controller that this device is wired to.
|
||||
interrupt-parent = <&mpic>;
|
||||
};
|
||||
|
||||
* References
|
||||
|
||||
[1] Power.org (TM) Standard for Embedded Power Architecture (TM) Platform
|
||||
Requirements (ePAPR), Version 1.0, July 2008.
|
||||
(http://www.power.org/resources/downloads/Power_ePAPR_APPROVED_v1.0.pdf)
|
||||
|
||||
|
|
@ -556,6 +556,9 @@ sub ngene {
|
|||
my $hash1 = "d798d5a757121174f0dbc5f2833c0c85";
|
||||
my $file2 = "ngene_17.fw";
|
||||
my $hash2 = "26b687136e127b8ac24b81e0eeafc20b";
|
||||
my $url2 = "http://l4m-daten.de/downloads/firmware/dvb-s2/linux/all/";
|
||||
my $file3 = "ngene_18.fw";
|
||||
my $hash3 = "ebce3ea769a53e3e0b0197c3b3f127e3";
|
||||
|
||||
checkstandard();
|
||||
|
||||
|
|
@ -565,7 +568,10 @@ sub ngene {
|
|||
wgetfile($file2, $url . $file2);
|
||||
verify($file2, $hash2);
|
||||
|
||||
"$file1, $file2";
|
||||
wgetfile($file3, $url2 . $file3);
|
||||
verify($file3, $hash3);
|
||||
|
||||
"$file1, $file2, $file3";
|
||||
}
|
||||
|
||||
sub az6027{
|
||||
|
|
|
|||
|
|
@ -4,7 +4,7 @@ following file(s) to this directory.
|
|||
for DM04+/QQBOX LME2510C (Sharp 7395 Tuner)
|
||||
-------------------------------------------
|
||||
|
||||
The Sharp 7395 driver can be found in windows/system32/driver
|
||||
The Sharp 7395 driver can be found in windows/system32/drivers
|
||||
|
||||
US2A0D.sys (dated 17 Mar 2009)
|
||||
|
||||
|
|
@ -44,7 +44,7 @@ and run
|
|||
|
||||
|
||||
Other LG firmware can be extracted manually from US280D.sys
|
||||
only found in windows/system32/driver.
|
||||
only found in windows/system32/drivers
|
||||
|
||||
dd if=US280D.sys ibs=1 skip=42360 count=3924 of=dvb-usb-lme2510-lg.fw
|
||||
|
||||
|
|
@ -55,4 +55,16 @@ dd if=US280D.sys ibs=1 skip=35200 count=3850 of=dvb-usb-lme2510c-lg.fw
|
|||
|
||||
---------------------------------------------------------------------
|
||||
|
||||
The Sharp 0194 tuner driver can be found in windows/system32/drivers
|
||||
|
||||
US290D.sys (dated 09 Apr 2009)
|
||||
|
||||
For LME2510
|
||||
dd if=US290D.sys ibs=1 skip=36856 count=3976 of=dvb-usb-lme2510-s0194.fw
|
||||
|
||||
|
||||
For LME2510C
|
||||
dd if=US290D.sys ibs=1 skip=33152 count=3697 of=dvb-usb-lme2510c-s0194.fw
|
||||
|
||||
|
||||
Copy the firmware file(s) to /lib/firmware
|
||||
|
|
|
|||
|
|
@ -6,7 +6,7 @@ This document describes how to use the dynamic debug (ddebug) feature.
|
|||
|
||||
Dynamic debug is designed to allow you to dynamically enable/disable kernel
|
||||
code to obtain additional kernel information. Currently, if
|
||||
CONFIG_DYNAMIC_DEBUG is set, then all pr_debug()/dev_debug() calls can be
|
||||
CONFIG_DYNAMIC_DEBUG is set, then all pr_debug()/dev_dbg() calls can be
|
||||
dynamically enabled per-callsite.
|
||||
|
||||
Dynamic debug has even more useful features:
|
||||
|
|
@ -26,7 +26,7 @@ Dynamic debug has even more useful features:
|
|||
Controlling dynamic debug Behaviour
|
||||
===================================
|
||||
|
||||
The behaviour of pr_debug()/dev_debug()s are controlled via writing to a
|
||||
The behaviour of pr_debug()/dev_dbg()s are controlled via writing to a
|
||||
control file in the 'debugfs' filesystem. Thus, you must first mount the debugfs
|
||||
filesystem, in order to make use of this feature. Subsequently, we refer to the
|
||||
control file as: <debugfs>/dynamic_debug/control. For example, if you want to
|
||||
|
|
|
|||
|
|
@ -0,0 +1,10 @@
|
|||
Configuration:
|
||||
|
||||
You can pass the following kernel command line options to sm501 videoframebuffer:
|
||||
|
||||
sm501fb.bpp= SM501 Display driver:
|
||||
Specifiy bits-per-pixel if not specified by 'mode'
|
||||
|
||||
sm501fb.mode= SM501 Display driver:
|
||||
Specify resolution as
|
||||
"<xres>x<yres>[-<bpp>][@<refresh>]"
|
||||
|
|
@ -108,42 +108,6 @@ Who: Pavel Machek <pavel@ucw.cz>
|
|||
|
||||
---------------------------
|
||||
|
||||
What: Video4Linux obsolete drivers using V4L1 API
|
||||
When: kernel 2.6.39
|
||||
Files: drivers/staging/se401/* drivers/staging/usbvideo/*
|
||||
Check: drivers/staging/se401/se401.c drivers/staging/usbvideo/usbvideo.c
|
||||
Why: There are some drivers still using V4L1 API, despite all efforts we've done
|
||||
to migrate. Those drivers are for obsolete hardware that the old maintainer
|
||||
didn't care (or not have the hardware anymore), and that no other developer
|
||||
could find any hardware to buy. They probably have no practical usage today,
|
||||
and people with such old hardware could probably keep using an older version
|
||||
of the kernel. Those drivers will be moved to staging on 2.6.38 and, if nobody
|
||||
cares enough to port and test them with V4L2 API, they'll be removed on 2.6.39.
|
||||
Who: Mauro Carvalho Chehab <mchehab@infradead.org>
|
||||
|
||||
---------------------------
|
||||
|
||||
What: Video4Linux: Remove obsolete ioctl's
|
||||
When: kernel 2.6.39
|
||||
Files: include/media/videodev2.h
|
||||
Why: Some ioctl's were defined wrong on 2.6.2 and 2.6.6, using the wrong
|
||||
type of R/W arguments. They were fixed, but the old ioctl names are
|
||||
still there, maintained to avoid breaking binary compatibility:
|
||||
#define VIDIOC_OVERLAY_OLD _IOWR('V', 14, int)
|
||||
#define VIDIOC_S_PARM_OLD _IOW('V', 22, struct v4l2_streamparm)
|
||||
#define VIDIOC_S_CTRL_OLD _IOW('V', 28, struct v4l2_control)
|
||||
#define VIDIOC_G_AUDIO_OLD _IOWR('V', 33, struct v4l2_audio)
|
||||
#define VIDIOC_G_AUDOUT_OLD _IOWR('V', 49, struct v4l2_audioout)
|
||||
#define VIDIOC_CROPCAP_OLD _IOR('V', 58, struct v4l2_cropcap)
|
||||
There's no sense on preserving those forever, as it is very doubtful
|
||||
that someone would try to use a such old binary with a modern kernel.
|
||||
Removing them will allow us to remove some magic done at the V4L ioctl
|
||||
handler.
|
||||
|
||||
Who: Mauro Carvalho Chehab <mchehab@infradead.org>
|
||||
|
||||
---------------------------
|
||||
|
||||
What: sys_sysctl
|
||||
When: September 2010
|
||||
Option: CONFIG_SYSCTL_SYSCALL
|
||||
|
|
@ -270,14 +234,6 @@ Who: Zhang Rui <rui.zhang@intel.com>
|
|||
|
||||
---------------------------
|
||||
|
||||
What: /proc/acpi/button
|
||||
When: August 2007
|
||||
Why: /proc/acpi/button has been replaced by events to the input layer
|
||||
since 2.6.20.
|
||||
Who: Len Brown <len.brown@intel.com>
|
||||
|
||||
---------------------------
|
||||
|
||||
What: /proc/acpi/event
|
||||
When: February 2008
|
||||
Why: /proc/acpi/event has been replaced by events via the input layer
|
||||
|
|
@ -585,16 +541,6 @@ Who: NeilBrown <neilb@suse.de>
|
|||
|
||||
----------------------------
|
||||
|
||||
What: i2c_adapter.id
|
||||
When: June 2011
|
||||
Why: This field is deprecated. I2C device drivers shouldn't change their
|
||||
behavior based on the underlying I2C adapter. Instead, the I2C
|
||||
adapter driver should instantiate the I2C devices and provide the
|
||||
needed platform-specific information.
|
||||
Who: Jean Delvare <khali@linux-fr.org>
|
||||
|
||||
----------------------------
|
||||
|
||||
What: cancel_rearming_delayed_work[queue]()
|
||||
When: 2.6.39
|
||||
|
||||
|
|
@ -645,3 +591,12 @@ Who: Florian Westphal <fw@strlen.de>
|
|||
Files: include/linux/netfilter_ipv4/ipt_addrtype.h
|
||||
|
||||
----------------------------
|
||||
|
||||
What: i2c_driver.attach_adapter
|
||||
i2c_driver.detach_adapter
|
||||
When: September 2011
|
||||
Why: These legacy callbacks should no longer be used as i2c-core offers
|
||||
a variety of preferable alternative ways to instantiate I2C devices.
|
||||
Who: Jean Delvare <khali@linux-fr.org>
|
||||
|
||||
----------------------------
|
||||
|
|
|
|||
|
|
@ -128,7 +128,7 @@ alloc_inode:
|
|||
destroy_inode:
|
||||
dirty_inode: (must not sleep)
|
||||
write_inode:
|
||||
drop_inode: !!!inode_lock!!!
|
||||
drop_inode: !!!inode->i_lock!!!
|
||||
evict_inode:
|
||||
put_super: write
|
||||
write_super: read
|
||||
|
|
|
|||
|
|
@ -9,6 +9,9 @@ Mount options for ADFS
|
|||
will be nnn. Default 0700.
|
||||
othmask=nnn The permission mask for ADFS 'other' permissions
|
||||
will be nnn. Default 0077.
|
||||
ftsuffix=n When ftsuffix=0, no file type suffix will be applied.
|
||||
When ftsuffix=1, a hexadecimal suffix corresponding to
|
||||
the RISC OS file type will be added. Default 0.
|
||||
|
||||
Mapping of ADFS permissions to Linux permissions
|
||||
------------------------------------------------
|
||||
|
|
@ -55,3 +58,18 @@ Mapping of ADFS permissions to Linux permissions
|
|||
|
||||
You can therefore tailor the permission translation to whatever you
|
||||
desire the permissions should be under Linux.
|
||||
|
||||
RISC OS file type suffix
|
||||
------------------------
|
||||
|
||||
RISC OS file types are stored in bits 19..8 of the file load address.
|
||||
|
||||
To enable non-RISC OS systems to be used to store files without losing
|
||||
file type information, a file naming convention was devised (initially
|
||||
for use with NFS) such that a hexadecimal suffix of the form ,xyz
|
||||
denoted the file type: e.g. BasicFile,ffb is a BASIC (0xffb) file. This
|
||||
naming convention is now also used by RISC OS emulators such as RPCEmu.
|
||||
|
||||
Mounting an ADFS disc with option ftsuffix=1 will cause appropriate file
|
||||
type suffixes to be appended to file names read from a directory. If the
|
||||
ftsuffix option is zero or omitted, no file type suffixes will be added.
|
||||
|
|
|
|||
|
|
@ -104,7 +104,15 @@ Where:
|
|||
exofs specific options: Options are separated by commas (,)
|
||||
pid=<integer> - The partition number to mount/create as
|
||||
container of the filesystem.
|
||||
This option is mandatory.
|
||||
This option is mandatory. integer can be
|
||||
Hex by pre-pending an 0x to the number.
|
||||
osdname=<id> - Mount by a device's osdname.
|
||||
osdname is usually a 36 character uuid of the
|
||||
form "d2683732-c906-4ee1-9dbd-c10c27bb40df".
|
||||
It is one of the device's uuid specified in the
|
||||
mkfs.exofs format command.
|
||||
If this option is specified then the /dev/osdX
|
||||
above can be empty and is ignored.
|
||||
to=<integer> - Timeout in ticks for a single command.
|
||||
default is (60 * HZ) [for debugging only]
|
||||
|
||||
|
|
|
|||
|
|
@ -367,12 +367,47 @@ init_itable=n The lazy itable init code will wait n times the
|
|||
minimizes the impact on the systme performance
|
||||
while file system's inode table is being initialized.
|
||||
|
||||
discard Controls whether ext4 should issue discard/TRIM
|
||||
discard Controls whether ext4 should issue discard/TRIM
|
||||
nodiscard(*) commands to the underlying block device when
|
||||
blocks are freed. This is useful for SSD devices
|
||||
and sparse/thinly-provisioned LUNs, but it is off
|
||||
by default until sufficient testing has been done.
|
||||
|
||||
nouid32 Disables 32-bit UIDs and GIDs. This is for
|
||||
interoperability with older kernels which only
|
||||
store and expect 16-bit values.
|
||||
|
||||
resize Allows to resize filesystem to the end of the last
|
||||
existing block group, further resize has to be done
|
||||
with resize2fs either online, or offline. It can be
|
||||
used only with conjunction with remount.
|
||||
|
||||
block_validity This options allows to enables/disables the in-kernel
|
||||
noblock_validity facility for tracking filesystem metadata blocks
|
||||
within internal data structures. This allows multi-
|
||||
block allocator and other routines to quickly locate
|
||||
extents which might overlap with filesystem metadata
|
||||
blocks. This option is intended for debugging
|
||||
purposes and since it negatively affects the
|
||||
performance, it is off by default.
|
||||
|
||||
dioread_lock Controls whether or not ext4 should use the DIO read
|
||||
dioread_nolock locking. If the dioread_nolock option is specified
|
||||
ext4 will allocate uninitialized extent before buffer
|
||||
write and convert the extent to initialized after IO
|
||||
completes. This approach allows ext4 code to avoid
|
||||
using inode mutex, which improves scalability on high
|
||||
speed storages. However this does not work with nobh
|
||||
option and the mount will fail. Nor does it work with
|
||||
data journaling and dioread_nolock option will be
|
||||
ignored with kernel warning. Note that dioread_nolock
|
||||
code path is only used for extent-based files.
|
||||
Because of the restrictions this options comprises
|
||||
it is off by default (e.g. dioread_lock).
|
||||
|
||||
i_version Enable 64-bit inode version support. This option is
|
||||
off by default.
|
||||
|
||||
Data Mode
|
||||
=========
|
||||
There are 3 different data modes:
|
||||
|
|
@ -400,6 +435,176 @@ needs to be read from and written to disk at the same time where it
|
|||
outperforms all others modes. Currently ext4 does not have delayed
|
||||
allocation support if this data journalling mode is selected.
|
||||
|
||||
/proc entries
|
||||
=============
|
||||
|
||||
Information about mounted ext4 file systems can be found in
|
||||
/proc/fs/ext4. Each mounted filesystem will have a directory in
|
||||
/proc/fs/ext4 based on its device name (i.e., /proc/fs/ext4/hdc or
|
||||
/proc/fs/ext4/dm-0). The files in each per-device directory are shown
|
||||
in table below.
|
||||
|
||||
Files in /proc/fs/ext4/<devname>
|
||||
..............................................................................
|
||||
File Content
|
||||
mb_groups details of multiblock allocator buddy cache of free blocks
|
||||
..............................................................................
|
||||
|
||||
/sys entries
|
||||
============
|
||||
|
||||
Information about mounted ext4 file systems can be found in
|
||||
/sys/fs/ext4. Each mounted filesystem will have a directory in
|
||||
/sys/fs/ext4 based on its device name (i.e., /sys/fs/ext4/hdc or
|
||||
/sys/fs/ext4/dm-0). The files in each per-device directory are shown
|
||||
in table below.
|
||||
|
||||
Files in /sys/fs/ext4/<devname>
|
||||
(see also Documentation/ABI/testing/sysfs-fs-ext4)
|
||||
..............................................................................
|
||||
File Content
|
||||
|
||||
delayed_allocation_blocks This file is read-only and shows the number of
|
||||
blocks that are dirty in the page cache, but
|
||||
which do not have their location in the
|
||||
filesystem allocated yet.
|
||||
|
||||
inode_goal Tuning parameter which (if non-zero) controls
|
||||
the goal inode used by the inode allocator in
|
||||
preference to all other allocation heuristics.
|
||||
This is intended for debugging use only, and
|
||||
should be 0 on production systems.
|
||||
|
||||
inode_readahead_blks Tuning parameter which controls the maximum
|
||||
number of inode table blocks that ext4's inode
|
||||
table readahead algorithm will pre-read into
|
||||
the buffer cache
|
||||
|
||||
lifetime_write_kbytes This file is read-only and shows the number of
|
||||
kilobytes of data that have been written to this
|
||||
filesystem since it was created.
|
||||
|
||||
max_writeback_mb_bump The maximum number of megabytes the writeback
|
||||
code will try to write out before move on to
|
||||
another inode.
|
||||
|
||||
mb_group_prealloc The multiblock allocator will round up allocation
|
||||
requests to a multiple of this tuning parameter if
|
||||
the stripe size is not set in the ext4 superblock
|
||||
|
||||
mb_max_to_scan The maximum number of extents the multiblock
|
||||
allocator will search to find the best extent
|
||||
|
||||
mb_min_to_scan The minimum number of extents the multiblock
|
||||
allocator will search to find the best extent
|
||||
|
||||
mb_order2_req Tuning parameter which controls the minimum size
|
||||
for requests (as a power of 2) where the buddy
|
||||
cache is used
|
||||
|
||||
mb_stats Controls whether the multiblock allocator should
|
||||
collect statistics, which are shown during the
|
||||
unmount. 1 means to collect statistics, 0 means
|
||||
not to collect statistics
|
||||
|
||||
mb_stream_req Files which have fewer blocks than this tunable
|
||||
parameter will have their blocks allocated out
|
||||
of a block group specific preallocation pool, so
|
||||
that small files are packed closely together.
|
||||
Each large file will have its blocks allocated
|
||||
out of its own unique preallocation pool.
|
||||
|
||||
session_write_kbytes This file is read-only and shows the number of
|
||||
kilobytes of data that have been written to this
|
||||
filesystem since it was mounted.
|
||||
..............................................................................
|
||||
|
||||
Ioctls
|
||||
======
|
||||
|
||||
There is some Ext4 specific functionality which can be accessed by applications
|
||||
through the system call interfaces. The list of all Ext4 specific ioctls are
|
||||
shown in the table below.
|
||||
|
||||
Table of Ext4 specific ioctls
|
||||
..............................................................................
|
||||
Ioctl Description
|
||||
EXT4_IOC_GETFLAGS Get additional attributes associated with inode.
|
||||
The ioctl argument is an integer bitfield, with
|
||||
bit values described in ext4.h. This ioctl is an
|
||||
alias for FS_IOC_GETFLAGS.
|
||||
|
||||
EXT4_IOC_SETFLAGS Set additional attributes associated with inode.
|
||||
The ioctl argument is an integer bitfield, with
|
||||
bit values described in ext4.h. This ioctl is an
|
||||
alias for FS_IOC_SETFLAGS.
|
||||
|
||||
EXT4_IOC_GETVERSION
|
||||
EXT4_IOC_GETVERSION_OLD
|
||||
Get the inode i_generation number stored for
|
||||
each inode. The i_generation number is normally
|
||||
changed only when new inode is created and it is
|
||||
particularly useful for network filesystems. The
|
||||
'_OLD' version of this ioctl is an alias for
|
||||
FS_IOC_GETVERSION.
|
||||
|
||||
EXT4_IOC_SETVERSION
|
||||
EXT4_IOC_SETVERSION_OLD
|
||||
Set the inode i_generation number stored for
|
||||
each inode. The '_OLD' version of this ioctl
|
||||
is an alias for FS_IOC_SETVERSION.
|
||||
|
||||
EXT4_IOC_GROUP_EXTEND This ioctl has the same purpose as the resize
|
||||
mount option. It allows to resize filesystem
|
||||
to the end of the last existing block group,
|
||||
further resize has to be done with resize2fs,
|
||||
either online, or offline. The argument points
|
||||
to the unsigned logn number representing the
|
||||
filesystem new block count.
|
||||
|
||||
EXT4_IOC_MOVE_EXT Move the block extents from orig_fd (the one
|
||||
this ioctl is pointing to) to the donor_fd (the
|
||||
one specified in move_extent structure passed
|
||||
as an argument to this ioctl). Then, exchange
|
||||
inode metadata between orig_fd and donor_fd.
|
||||
This is especially useful for online
|
||||
defragmentation, because the allocator has the
|
||||
opportunity to allocate moved blocks better,
|
||||
ideally into one contiguous extent.
|
||||
|
||||
EXT4_IOC_GROUP_ADD Add a new group descriptor to an existing or
|
||||
new group descriptor block. The new group
|
||||
descriptor is described by ext4_new_group_input
|
||||
structure, which is passed as an argument to
|
||||
this ioctl. This is especially useful in
|
||||
conjunction with EXT4_IOC_GROUP_EXTEND,
|
||||
which allows online resize of the filesystem
|
||||
to the end of the last existing block group.
|
||||
Those two ioctls combined is used in userspace
|
||||
online resize tool (e.g. resize2fs).
|
||||
|
||||
EXT4_IOC_MIGRATE This ioctl operates on the filesystem itself.
|
||||
It converts (migrates) ext3 indirect block mapped
|
||||
inode to ext4 extent mapped inode by walking
|
||||
through indirect block mapping of the original
|
||||
inode and converting contiguous block ranges
|
||||
into ext4 extents of the temporary inode. Then,
|
||||
inodes are swapped. This ioctl might help, when
|
||||
migrating from ext3 to ext4 filesystem, however
|
||||
suggestion is to create fresh ext4 filesystem
|
||||
and copy data from the backup. Note, that
|
||||
filesystem has to support extents for this ioctl
|
||||
to work.
|
||||
|
||||
EXT4_IOC_ALLOC_DA_BLKS Force all of the delay allocated blocks to be
|
||||
allocated to preserve application-expected ext3
|
||||
behaviour. Note that this will also start
|
||||
triggering a write of the data blocks, but this
|
||||
behaviour may change in the future as it is
|
||||
not necessary and has been done this way only
|
||||
for sake of simplicity.
|
||||
..............................................................................
|
||||
|
||||
References
|
||||
==========
|
||||
|
||||
|
|
|
|||
|
|
@ -298,11 +298,14 @@ be used instead. It gets called whenever the inode is evicted, whether it has
|
|||
remaining links or not. Caller does *not* evict the pagecache or inode-associated
|
||||
metadata buffers; getting rid of those is responsibility of method, as it had
|
||||
been for ->delete_inode().
|
||||
->drop_inode() returns int now; it's called on final iput() with inode_lock
|
||||
held and it returns true if filesystems wants the inode to be dropped. As before,
|
||||
generic_drop_inode() is still the default and it's been updated appropriately.
|
||||
generic_delete_inode() is also alive and it consists simply of return 1. Note that
|
||||
all actual eviction work is done by caller after ->drop_inode() returns.
|
||||
|
||||
->drop_inode() returns int now; it's called on final iput() with
|
||||
inode->i_lock held and it returns true if filesystems wants the inode to be
|
||||
dropped. As before, generic_drop_inode() is still the default and it's been
|
||||
updated appropriately. generic_delete_inode() is also alive and it consists
|
||||
simply of return 1. Note that all actual eviction work is done by caller after
|
||||
->drop_inode() returns.
|
||||
|
||||
clear_inode() is gone; use end_writeback() instead. As before, it must
|
||||
be called exactly once on each call of ->evict_inode() (as it used to be for
|
||||
each call of ->delete_inode()). Unlike before, if you are using inode-associated
|
||||
|
|
@ -395,6 +398,9 @@ Currently you can only have FALLOC_FL_PUNCH_HOLE with FALLOC_FL_KEEP_SIZE set,
|
|||
so the i_size should not change when hole punching, even when puching the end of
|
||||
a file off.
|
||||
|
||||
--
|
||||
[mandatory]
|
||||
|
||||
--
|
||||
[mandatory]
|
||||
->get_sb() is gone. Switch to use of ->mount(). Typically it's just
|
||||
|
|
|
|||
|
|
@ -59,12 +59,15 @@ obtained from this site also.
|
|||
3. SQUASHFS FILESYSTEM DESIGN
|
||||
-----------------------------
|
||||
|
||||
A squashfs filesystem consists of a maximum of eight parts, packed together on a byte
|
||||
alignment:
|
||||
A squashfs filesystem consists of a maximum of nine parts, packed together on a
|
||||
byte alignment:
|
||||
|
||||
---------------
|
||||
| superblock |
|
||||
|---------------|
|
||||
| compression |
|
||||
| options |
|
||||
|---------------|
|
||||
| datablocks |
|
||||
| & fragments |
|
||||
|---------------|
|
||||
|
|
@ -91,7 +94,14 @@ the source directory, and checked for duplicates. Once all file data has been
|
|||
written the completed inode, directory, fragment, export and uid/gid lookup
|
||||
tables are written.
|
||||
|
||||
3.1 Inodes
|
||||
3.1 Compression options
|
||||
-----------------------
|
||||
|
||||
Compressors can optionally support compression specific options (e.g.
|
||||
dictionary size). If non-default compression options have been used, then
|
||||
these are stored here.
|
||||
|
||||
3.2 Inodes
|
||||
----------
|
||||
|
||||
Metadata (inodes and directories) are compressed in 8Kbyte blocks. Each
|
||||
|
|
@ -114,7 +124,7 @@ directory inode are defined: inodes optimised for frequently occurring
|
|||
regular files and directories, and extended types where extra
|
||||
information has to be stored.
|
||||
|
||||
3.2 Directories
|
||||
3.3 Directories
|
||||
---------------
|
||||
|
||||
Like inodes, directories are packed into compressed metadata blocks, stored
|
||||
|
|
@ -144,7 +154,7 @@ decompressed to do a lookup irrespective of the length of the directory.
|
|||
This scheme has the advantage that it doesn't require extra memory overhead
|
||||
and doesn't require much extra storage on disk.
|
||||
|
||||
3.3 File data
|
||||
3.4 File data
|
||||
-------------
|
||||
|
||||
Regular files consist of a sequence of contiguous compressed blocks, and/or a
|
||||
|
|
@ -163,7 +173,7 @@ Larger files use multiple slots, with 1.75 TiB files using all 8 slots.
|
|||
The index cache is designed to be memory efficient, and by default uses
|
||||
16 KiB.
|
||||
|
||||
3.4 Fragment lookup table
|
||||
3.5 Fragment lookup table
|
||||
-------------------------
|
||||
|
||||
Regular files can contain a fragment index which is mapped to a fragment
|
||||
|
|
@ -173,7 +183,7 @@ A second index table is used to locate these. This second index table for
|
|||
speed of access (and because it is small) is read at mount time and cached
|
||||
in memory.
|
||||
|
||||
3.5 Uid/gid lookup table
|
||||
3.6 Uid/gid lookup table
|
||||
------------------------
|
||||
|
||||
For space efficiency regular files store uid and gid indexes, which are
|
||||
|
|
@ -182,7 +192,7 @@ stored compressed into metadata blocks. A second index table is used to
|
|||
locate these. This second index table for speed of access (and because it
|
||||
is small) is read at mount time and cached in memory.
|
||||
|
||||
3.6 Export table
|
||||
3.7 Export table
|
||||
----------------
|
||||
|
||||
To enable Squashfs filesystems to be exportable (via NFS etc.) filesystems
|
||||
|
|
@ -196,7 +206,7 @@ This table is stored compressed into metadata blocks. A second index table is
|
|||
used to locate these. This second index table for speed of access (and because
|
||||
it is small) is read at mount time and cached in memory.
|
||||
|
||||
3.7 Xattr table
|
||||
3.8 Xattr table
|
||||
---------------
|
||||
|
||||
The xattr table contains extended attributes for each inode. The xattrs
|
||||
|
|
|
|||
|
|
@ -254,7 +254,7 @@ or bottom half).
|
|||
should be synchronous or not, not all filesystems check this flag.
|
||||
|
||||
drop_inode: called when the last access to the inode is dropped,
|
||||
with the inode_lock spinlock held.
|
||||
with the inode->i_lock spinlock held.
|
||||
|
||||
This method should be either NULL (normal UNIX filesystem
|
||||
semantics) or "generic_delete_inode" (for filesystems that do not
|
||||
|
|
|
|||
|
|
@ -791,10 +791,3 @@ mount option. Fundamentally, there is no reason why the log manager would not
|
|||
be able to swap methods automatically and transparently depending on load
|
||||
characteristics, but this should not be necessary if delayed logging works as
|
||||
designed.
|
||||
|
||||
Roadmap:
|
||||
|
||||
2.6.39 Switch default mount option to use delayed logging
|
||||
=> should be roughly 12 months after initial merge
|
||||
=> enough time to shake out remaining problems before next round of
|
||||
enterprise distro kernel rebases
|
||||
|
|
|
|||
|
|
@ -0,0 +1,72 @@
|
|||
Kernel driver ads1015
|
||||
=====================
|
||||
|
||||
Supported chips:
|
||||
* Texas Instruments ADS1015
|
||||
Prefix: 'ads1015'
|
||||
Datasheet: Publicly available at the Texas Instruments website :
|
||||
http://focus.ti.com/lit/ds/symlink/ads1015.pdf
|
||||
|
||||
Authors:
|
||||
Dirk Eibach, Guntermann & Drunck GmbH <eibach@gdsys.de>
|
||||
|
||||
Description
|
||||
-----------
|
||||
|
||||
This driver implements support for the Texas Instruments ADS1015.
|
||||
|
||||
This device is a 12-bit A-D converter with 4 inputs.
|
||||
|
||||
The inputs can be used single ended or in certain differential combinations.
|
||||
|
||||
The inputs can be made available by 8 sysfs input files in0_input - in7_input:
|
||||
in0: Voltage over AIN0 and AIN1.
|
||||
in1: Voltage over AIN0 and AIN3.
|
||||
in2: Voltage over AIN1 and AIN3.
|
||||
in3: Voltage over AIN2 and AIN3.
|
||||
in4: Voltage over AIN0 and GND.
|
||||
in5: Voltage over AIN1 and GND.
|
||||
in6: Voltage over AIN2 and GND.
|
||||
in7: Voltage over AIN3 and GND.
|
||||
|
||||
Which inputs are available can be configured using platform data or devicetree.
|
||||
|
||||
By default all inputs are exported.
|
||||
|
||||
Platform Data
|
||||
-------------
|
||||
|
||||
In linux/i2c/ads1015.h platform data is defined, channel_data contains
|
||||
configuration data for the used input combinations:
|
||||
- pga is the programmable gain amplifier (values are full scale)
|
||||
0: +/- 6.144 V
|
||||
1: +/- 4.096 V
|
||||
2: +/- 2.048 V
|
||||
3: +/- 1.024 V
|
||||
4: +/- 0.512 V
|
||||
5: +/- 0.256 V
|
||||
- data_rate in samples per second
|
||||
0: 128
|
||||
1: 250
|
||||
2: 490
|
||||
3: 920
|
||||
4: 1600
|
||||
5: 2400
|
||||
6: 3300
|
||||
|
||||
Example:
|
||||
struct ads1015_platform_data data = {
|
||||
.channel_data = {
|
||||
[2] = { .enabled = true, .pga = 1, .data_rate = 0 },
|
||||
[4] = { .enabled = true, .pga = 4, .data_rate = 5 },
|
||||
}
|
||||
};
|
||||
|
||||
In this case only in2_input (FS +/- 4.096 V, 128 SPS) and in4_input
|
||||
(FS +/- 0.512 V, 2400 SPS) would be created.
|
||||
|
||||
Devicetree
|
||||
----------
|
||||
|
||||
Configuration is also possible via devicetree:
|
||||
Documentation/devicetree/bindings/hwmon/ads1015.txt
|
||||
|
|
@ -2,6 +2,10 @@ Kernel driver f71882fg
|
|||
======================
|
||||
|
||||
Supported chips:
|
||||
* Fintek F71808E
|
||||
Prefix: 'f71808e'
|
||||
Addresses scanned: none, address read from Super I/O config space
|
||||
Datasheet: Not public
|
||||
* Fintek F71858FG
|
||||
Prefix: 'f71858fg'
|
||||
Addresses scanned: none, address read from Super I/O config space
|
||||
|
|
@ -26,10 +30,25 @@ Supported chips:
|
|||
Prefix: 'f71889ed'
|
||||
Addresses scanned: none, address read from Super I/O config space
|
||||
Datasheet: Should become available on the Fintek website soon
|
||||
* Fintek F71889A
|
||||
Prefix: 'f71889a'
|
||||
Addresses scanned: none, address read from Super I/O config space
|
||||
Datasheet: Should become available on the Fintek website soon
|
||||
* Fintek F8000
|
||||
Prefix: 'f8000'
|
||||
Addresses scanned: none, address read from Super I/O config space
|
||||
Datasheet: Not public
|
||||
* Fintek F81801U
|
||||
Prefix: 'f71889fg'
|
||||
Addresses scanned: none, address read from Super I/O config space
|
||||
Datasheet: Not public
|
||||
Note: This is the 64-pin variant of the F71889FG, they have the
|
||||
same device ID and are fully compatible as far as hardware
|
||||
monitoring is concerned.
|
||||
* Fintek F81865F
|
||||
Prefix: 'f81865f'
|
||||
Addresses scanned: none, address read from Super I/O config space
|
||||
Datasheet: Available from the Fintek website
|
||||
|
||||
Author: Hans de Goede <hdegoede@redhat.com>
|
||||
|
||||
|
|
|
|||
|
|
@ -7,6 +7,11 @@ Supported chips:
|
|||
Addresses scanned: I2C 0x48 - 0x4f
|
||||
Datasheet: Publicly available at the National Semiconductor website
|
||||
http://www.national.com/
|
||||
* National Semiconductor LM75A
|
||||
Prefix: 'lm75a'
|
||||
Addresses scanned: I2C 0x48 - 0x4f
|
||||
Datasheet: Publicly available at the National Semiconductor website
|
||||
http://www.national.com/
|
||||
* Dallas Semiconductor DS75
|
||||
Prefix: 'lm75'
|
||||
Addresses scanned: I2C 0x48 - 0x4f
|
||||
|
|
|
|||
|
|
@ -0,0 +1,22 @@
|
|||
Kernel driver sch5627
|
||||
=====================
|
||||
|
||||
Supported chips:
|
||||
* SMSC SCH5627
|
||||
Prefix: 'sch5627'
|
||||
Addresses scanned: none, address read from Super I/O config space
|
||||
Datasheet: Application Note available upon request
|
||||
|
||||
Author: Hans de Goede <hdegoede@redhat.com>
|
||||
|
||||
|
||||
Description
|
||||
-----------
|
||||
|
||||
SMSC SCH5627 Super I/O chips include complete hardware monitoring
|
||||
capabilities. They can monitor up to 5 voltages, 4 fans and 8 temperatures.
|
||||
|
||||
The hardware monitoring part of the SMSC SCH5627 is accessed by talking
|
||||
through an embedded microcontroller. An application note describing the
|
||||
protocol for communicating with the microcontroller is available upon
|
||||
request. Please mail me if you want a copy.
|
||||
|
|
@ -0,0 +1,45 @@
|
|||
Kernel driver twl4030-madc
|
||||
=========================
|
||||
|
||||
Supported chips:
|
||||
* Texas Instruments TWL4030
|
||||
Prefix: 'twl4030-madc'
|
||||
|
||||
|
||||
Authors:
|
||||
J Keerthy <j-keerthy@ti.com>
|
||||
|
||||
Description
|
||||
-----------
|
||||
|
||||
The Texas Instruments TWL4030 is a Power Management and Audio Circuit. Among
|
||||
other things it contains a 10-bit A/D converter MADC. The converter has 16
|
||||
channels which can be used in different modes.
|
||||
|
||||
|
||||
See this table for the meaning of the different channels
|
||||
|
||||
Channel Signal
|
||||
------------------------------------------
|
||||
0 Battery type(BTYPE)
|
||||
1 BCI: Battery temperature (BTEMP)
|
||||
2 GP analog input
|
||||
3 GP analog input
|
||||
4 GP analog input
|
||||
5 GP analog input
|
||||
6 GP analog input
|
||||
7 GP analog input
|
||||
8 BCI: VBUS voltage(VBUS)
|
||||
9 Backup Battery voltage (VBKP)
|
||||
10 BCI: Battery charger current (ICHG)
|
||||
11 BCI: Battery charger voltage (VCHG)
|
||||
12 BCI: Main battery voltage (VBAT)
|
||||
13 Reserved
|
||||
14 Reserved
|
||||
15 VRUSB Supply/Speaker left/Speaker right polarization level
|
||||
|
||||
|
||||
The Sysfs nodes will represent the voltage in the units of mV,
|
||||
the temperature channel shows the converted temperature in
|
||||
degree celcius. The Battery charging current channel represents
|
||||
battery charging current in mA.
|
||||
|
|
@ -0,0 +1,127 @@
|
|||
Kernel driver w83795
|
||||
====================
|
||||
|
||||
Supported chips:
|
||||
* Winbond/Nuvoton W83795G
|
||||
Prefix: 'w83795g'
|
||||
Addresses scanned: I2C 0x2c - 0x2f
|
||||
Datasheet: Available for download on nuvoton.com
|
||||
* Winbond/Nuvoton W83795ADG
|
||||
Prefix: 'w83795adg'
|
||||
Addresses scanned: I2C 0x2c - 0x2f
|
||||
Datasheet: Available for download on nuvoton.com
|
||||
|
||||
Authors:
|
||||
Wei Song (Nuvoton)
|
||||
Jean Delvare <khali@linux-fr.org>
|
||||
|
||||
|
||||
Pin mapping
|
||||
-----------
|
||||
|
||||
Here is a summary of the pin mapping for the W83795G and W83795ADG.
|
||||
This can be useful to convert data provided by board manufacturers
|
||||
into working libsensors configuration statements.
|
||||
|
||||
W83795G |
|
||||
Pin | Name | Register | Sysfs attribute
|
||||
------------------------------------------------------------------
|
||||
13 | VSEN1 (VCORE1) | 10h | in0
|
||||
14 | VSEN2 (VCORE2) | 11h | in1
|
||||
15 | VSEN3 (VCORE3) | 12h | in2
|
||||
16 | VSEN4 | 13h | in3
|
||||
17 | VSEN5 | 14h | in4
|
||||
18 | VSEN6 | 15h | in5
|
||||
19 | VSEN7 | 16h | in6
|
||||
20 | VSEN8 | 17h | in7
|
||||
21 | VSEN9 | 18h | in8
|
||||
22 | VSEN10 | 19h | in9
|
||||
23 | VSEN11 | 1Ah | in10
|
||||
28 | VTT | 1Bh | in11
|
||||
24 | 3VDD | 1Ch | in12
|
||||
25 | 3VSB | 1Dh | in13
|
||||
26 | VBAT | 1Eh | in14
|
||||
3 | VSEN12/TR5 | 1Fh | in15/temp5
|
||||
4 | VSEN13/TR5 | 20h | in16/temp6
|
||||
5/ 6 | VDSEN14/TR1/TD1 | 21h | in17/temp1
|
||||
7/ 8 | VDSEN15/TR2/TD2 | 22h | in18/temp2
|
||||
9/ 10 | VDSEN16/TR3/TD3 | 23h | in19/temp3
|
||||
11/ 12 | VDSEN17/TR4/TD4 | 24h | in20/temp4
|
||||
40 | FANIN1 | 2Eh | fan1
|
||||
42 | FANIN2 | 2Fh | fan2
|
||||
44 | FANIN3 | 30h | fan3
|
||||
46 | FANIN4 | 31h | fan4
|
||||
48 | FANIN5 | 32h | fan5
|
||||
50 | FANIN6 | 33h | fan6
|
||||
52 | FANIN7 | 34h | fan7
|
||||
54 | FANIN8 | 35h | fan8
|
||||
57 | FANIN9 | 36h | fan9
|
||||
58 | FANIN10 | 37h | fan10
|
||||
59 | FANIN11 | 38h | fan11
|
||||
60 | FANIN12 | 39h | fan12
|
||||
31 | FANIN13 | 3Ah | fan13
|
||||
35 | FANIN14 | 3Bh | fan14
|
||||
41 | FANCTL1 | 10h (bank 2) | pwm1
|
||||
43 | FANCTL2 | 11h (bank 2) | pwm2
|
||||
45 | FANCTL3 | 12h (bank 2) | pwm3
|
||||
47 | FANCTL4 | 13h (bank 2) | pwm4
|
||||
49 | FANCTL5 | 14h (bank 2) | pwm5
|
||||
51 | FANCTL6 | 15h (bank 2) | pwm6
|
||||
53 | FANCTL7 | 16h (bank 2) | pwm7
|
||||
55 | FANCTL8 | 17h (bank 2) | pwm8
|
||||
29/ 30 | PECI/TSI (DTS1) | 26h | temp7
|
||||
29/ 30 | PECI/TSI (DTS2) | 27h | temp8
|
||||
29/ 30 | PECI/TSI (DTS3) | 28h | temp9
|
||||
29/ 30 | PECI/TSI (DTS4) | 29h | temp10
|
||||
29/ 30 | PECI/TSI (DTS5) | 2Ah | temp11
|
||||
29/ 30 | PECI/TSI (DTS6) | 2Bh | temp12
|
||||
29/ 30 | PECI/TSI (DTS7) | 2Ch | temp13
|
||||
29/ 30 | PECI/TSI (DTS8) | 2Dh | temp14
|
||||
27 | CASEOPEN# | 46h | intrusion0
|
||||
|
||||
W83795ADG |
|
||||
Pin | Name | Register | Sysfs attribute
|
||||
------------------------------------------------------------------
|
||||
10 | VSEN1 (VCORE1) | 10h | in0
|
||||
11 | VSEN2 (VCORE2) | 11h | in1
|
||||
12 | VSEN3 (VCORE3) | 12h | in2
|
||||
13 | VSEN4 | 13h | in3
|
||||
14 | VSEN5 | 14h | in4
|
||||
15 | VSEN6 | 15h | in5
|
||||
16 | VSEN7 | 16h | in6
|
||||
17 | VSEN8 | 17h | in7
|
||||
22 | VTT | 1Bh | in11
|
||||
18 | 3VDD | 1Ch | in12
|
||||
19 | 3VSB | 1Dh | in13
|
||||
20 | VBAT | 1Eh | in14
|
||||
48 | VSEN12/TR5 | 1Fh | in15/temp5
|
||||
1 | VSEN13/TR5 | 20h | in16/temp6
|
||||
2/ 3 | VDSEN14/TR1/TD1 | 21h | in17/temp1
|
||||
4/ 5 | VDSEN15/TR2/TD2 | 22h | in18/temp2
|
||||
6/ 7 | VDSEN16/TR3/TD3 | 23h | in19/temp3
|
||||
8/ 9 | VDSEN17/TR4/TD4 | 24h | in20/temp4
|
||||
32 | FANIN1 | 2Eh | fan1
|
||||
34 | FANIN2 | 2Fh | fan2
|
||||
36 | FANIN3 | 30h | fan3
|
||||
37 | FANIN4 | 31h | fan4
|
||||
38 | FANIN5 | 32h | fan5
|
||||
39 | FANIN6 | 33h | fan6
|
||||
40 | FANIN7 | 34h | fan7
|
||||
41 | FANIN8 | 35h | fan8
|
||||
43 | FANIN9 | 36h | fan9
|
||||
44 | FANIN10 | 37h | fan10
|
||||
45 | FANIN11 | 38h | fan11
|
||||
46 | FANIN12 | 39h | fan12
|
||||
24 | FANIN13 | 3Ah | fan13
|
||||
28 | FANIN14 | 3Bh | fan14
|
||||
33 | FANCTL1 | 10h (bank 2) | pwm1
|
||||
35 | FANCTL2 | 11h (bank 2) | pwm2
|
||||
23 | PECI (DTS1) | 26h | temp7
|
||||
23 | PECI (DTS2) | 27h | temp8
|
||||
23 | PECI (DTS3) | 28h | temp9
|
||||
23 | PECI (DTS4) | 29h | temp10
|
||||
23 | PECI (DTS5) | 2Ah | temp11
|
||||
23 | PECI (DTS6) | 2Bh | temp12
|
||||
23 | PECI (DTS7) | 2Ch | temp13
|
||||
23 | PECI (DTS8) | 2Dh | temp14
|
||||
21 | CASEOPEN# | 46h | intrusion0
|
||||
|
|
@ -0,0 +1,26 @@
|
|||
Kernel driver i2c-diolan-u2c
|
||||
|
||||
Supported adapters:
|
||||
* Diolan U2C-12 I2C-USB adapter
|
||||
Documentation:
|
||||
http://www.diolan.com/i2c/u2c12.html
|
||||
|
||||
Author: Guenter Roeck <guenter.roeck@ericsson.com>
|
||||
|
||||
Description
|
||||
-----------
|
||||
|
||||
This is the driver for the Diolan U2C-12 USB-I2C adapter.
|
||||
|
||||
The Diolan U2C-12 I2C-USB Adapter provides a low cost solution to connect
|
||||
a computer to I2C slave devices using a USB interface. It also supports
|
||||
connectivity to SPI devices.
|
||||
|
||||
This driver only supports the I2C interface of U2C-12. The driver does not use
|
||||
interrupts.
|
||||
|
||||
|
||||
Module parameters
|
||||
-----------------
|
||||
|
||||
* frequency: I2C bus frequency
|
||||
|
|
@ -16,8 +16,9 @@ Supported adapters:
|
|||
* Intel EP80579 (Tolapai)
|
||||
* Intel 82801JI (ICH10)
|
||||
* Intel 5/3400 Series (PCH)
|
||||
* Intel Cougar Point (PCH)
|
||||
* Intel 6 Series (PCH)
|
||||
* Intel Patsburg (PCH)
|
||||
* Intel DH89xxCC (PCH)
|
||||
Datasheets: Publicly available at the Intel website
|
||||
|
||||
On Intel Patsburg and later chipsets, both the normal host SMBus controller
|
||||
|
|
|
|||
|
|
@ -100,7 +100,7 @@ static int __devinit usb_hcd_pnx4008_probe(struct platform_device *pdev)
|
|||
(...)
|
||||
i2c_adap = i2c_get_adapter(2);
|
||||
memset(&i2c_info, 0, sizeof(struct i2c_board_info));
|
||||
strlcpy(i2c_info.name, "isp1301_pnx", I2C_NAME_SIZE);
|
||||
strlcpy(i2c_info.type, "isp1301_pnx", I2C_NAME_SIZE);
|
||||
isp1301_i2c_client = i2c_new_probed_device(i2c_adap, &i2c_info,
|
||||
normal_i2c, NULL);
|
||||
i2c_put_adapter(i2c_adap);
|
||||
|
|
|
|||
|
|
@ -61,7 +61,7 @@ static int example_attach(struct i2c_adapter *adap, int addr, int kind)
|
|||
return 0;
|
||||
}
|
||||
|
||||
static int __devexit example_detach(struct i2c_client *client)
|
||||
static int example_detach(struct i2c_client *client)
|
||||
{
|
||||
struct example_state *state = i2c_get_clientdata(client);
|
||||
|
||||
|
|
@ -81,7 +81,7 @@ static struct i2c_driver example_driver = {
|
|||
.name = "example",
|
||||
},
|
||||
.attach_adapter = example_attach_adapter,
|
||||
.detach_client = __devexit_p(example_detach),
|
||||
.detach_client = example_detach,
|
||||
.suspend = example_suspend,
|
||||
.resume = example_resume,
|
||||
};
|
||||
|
|
@ -93,7 +93,7 @@ Updating the client
|
|||
The new style binding model will check against a list of supported
|
||||
devices and their associated address supplied by the code registering
|
||||
the busses. This means that the driver .attach_adapter and
|
||||
.detach_adapter methods can be removed, along with the addr_data,
|
||||
.detach_client methods can be removed, along with the addr_data,
|
||||
as follows:
|
||||
|
||||
- static struct i2c_driver example_driver;
|
||||
|
|
@ -110,14 +110,14 @@ as follows:
|
|||
|
||||
static struct i2c_driver example_driver = {
|
||||
- .attach_adapter = example_attach_adapter,
|
||||
- .detach_client = __devexit_p(example_detach),
|
||||
- .detach_client = example_detach,
|
||||
}
|
||||
|
||||
Add the probe and remove methods to the i2c_driver, as so:
|
||||
|
||||
static struct i2c_driver example_driver = {
|
||||
+ .probe = example_probe,
|
||||
+ .remove = __devexit_p(example_remove),
|
||||
+ .remove = example_remove,
|
||||
}
|
||||
|
||||
Change the example_attach method to accept the new parameters
|
||||
|
|
@ -199,8 +199,8 @@ to delete the i2c_detach_client call. It is possible that you
|
|||
can also remove the ret variable as it is not not needed for
|
||||
any of the core functions.
|
||||
|
||||
- static int __devexit example_detach(struct i2c_client *client)
|
||||
+ static int __devexit example_remove(struct i2c_client *client)
|
||||
- static int example_detach(struct i2c_client *client)
|
||||
+ static int example_remove(struct i2c_client *client)
|
||||
{
|
||||
struct example_state *state = i2c_get_clientdata(client);
|
||||
|
||||
|
|
@ -253,7 +253,7 @@ static int example_probe(struct i2c_client *client,
|
|||
return 0;
|
||||
}
|
||||
|
||||
static int __devexit example_remove(struct i2c_client *client)
|
||||
static int example_remove(struct i2c_client *client)
|
||||
{
|
||||
struct example_state *state = i2c_get_clientdata(client);
|
||||
|
||||
|
|
@ -275,7 +275,7 @@ static struct i2c_driver example_driver = {
|
|||
},
|
||||
.id_table = example_idtable,
|
||||
.probe = example_probe,
|
||||
.remove = __devexit_p(example_remove),
|
||||
.remove = example_remove,
|
||||
.suspend = example_suspend,
|
||||
.resume = example_resume,
|
||||
};
|
||||
|
|
|
|||
Некоторые файлы не были показаны из-за слишком большого количества измененных файлов Показать больше
Загрузка…
Ссылка в новой задаче