microsoft
/
WSL2-Linux-Kernel
зеркало из https://github.com/microsoft/WSL2-Linux-Kernel.git
1
0
Форкнуть 0
Код Задачи Пакеты Проекты Релизы Вики Активность

Merge branch 'master' of ssh://master.kernel.org/pub/scm/linux/kernel/git/kaber/nf-2.6

This commit is contained in:
Patrick McHardy 2011-04-13 13:32:28 +02:00
Родитель 6604271c5b 96120d86fe
Коммит b32e3dc786
3328 изменённых файлов: 178773 добавлений и 70433 удалений
Показать статистику Скачать Patch файл Скачать Diff файл Показать все файлы Свернуть все файлы

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>

20
Documentation/ABI/stable/sysfs-class-backlight
Просмотреть файл

@ -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.

31
Documentation/ABI/testing/configfs-spear-pcie-gadget Normal file
Просмотреть файл

@ -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.

12
Documentation/ABI/testing/pstore
Просмотреть файл

@ -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.

6
Documentation/ABI/testing/sysfs-bus-media Normal file
Просмотреть файл

@ -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.

12
Documentation/ABI/testing/sysfs-bus-pci-devices-cciss
Просмотреть файл

@ -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.

2
Documentation/ABI/testing/sysfs-bus-rbd
Просмотреть файл

@ -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:

21
Documentation/ABI/testing/sysfs-devices-mmc Normal file
Просмотреть файл

@ -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.

19
Documentation/ABI/testing/sysfs-driver-samsung-laptop Normal file
Просмотреть файл

@ -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.

13
Documentation/ABI/testing/sysfs-fs-ext4
Просмотреть файл

@ -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.

7
Documentation/ABI/testing/sysfs-fs-pstore
Просмотреть файл

@ -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.

31
Documentation/ABI/testing/sysfs-platform-asus-wmi Normal file
Просмотреть файл

@ -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.

10
Documentation/ABI/testing/sysfs-platform-eeepc-wmi
Просмотреть файл

@ -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

8
Documentation/Changes
Просмотреть файл

@ -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

7
Documentation/CodingStyle
Просмотреть файл

@ -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.

4
Documentation/DocBook/Makefile
Просмотреть файл

@ -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))

59
Documentation/DocBook/media-entities.tmpl
Просмотреть файл

@ -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&nbsp;<link linkend='v4l2-field'>v4l2_field</link>">
<!ENTITY v4l2-frmivaltypes "enum&nbsp;<link linkend='v4l2-frmivaltypes'>v4l2_frmivaltypes</link>">
<!ENTITY v4l2-frmsizetypes "enum&nbsp;<link linkend='v4l2-frmsizetypes'>v4l2_frmsizetypes</link>">
<!ENTITY v4l2-mbus-pixelcode "enum&nbsp;<link linkend='v4l2-mbus-pixelcode'>v4l2_mbus_pixelcode</link>">
<!ENTITY v4l2-memory "enum&nbsp;<link linkend='v4l2-memory'>v4l2_memory</link>">
<!ENTITY v4l2-mpeg-audio-ac3-bitrate "enum&nbsp;<link linkend='v4l2-mpeg-audio-ac3-bitrate'>v4l2_mpeg_audio_ac3_bitrate</link>">
<!ENTITY v4l2-mpeg-audio-crc "enum&nbsp;<link linkend='v4l2-mpeg-audio-crc'>v4l2_mpeg_audio_crc</link>">
@ -121,6 +139,7 @@
<!ENTITY v4l2-mpeg-video-encoding "enum&nbsp;<link linkend='v4l2-mpeg-video-encoding'>v4l2_mpeg_video_encoding</link>">
<!ENTITY v4l2-power-line-frequency "enum&nbsp;<link linkend='v4l2-power-line-frequency'>v4l2_power_line_frequency</link>">
<!ENTITY v4l2-priority "enum&nbsp;<link linkend='v4l2-priority'>v4l2_priority</link>">
<!ENTITY v4l2-subdev-format-whence "enum&nbsp;<link linkend='v4l2-subdev-format-whence'>v4l2_subdev_format_whence</link>">
<!ENTITY v4l2-tuner-type "enum&nbsp;<link linkend='v4l2-tuner-type'>v4l2_tuner_type</link>">
<!ENTITY v4l2-preemphasis "enum&nbsp;<link linkend='v4l2-preemphasis'>v4l2_preemphasis</link>">
@ -129,6 +148,7 @@
<!ENTITY v4l2-audioout "struct&nbsp;<link linkend='v4l2-audioout'>v4l2_audioout</link>">
<!ENTITY v4l2-bt-timings "struct&nbsp;<link linkend='v4l2-bt-timings'>v4l2_bt_timings</link>">
<!ENTITY v4l2-buffer "struct&nbsp;<link linkend='v4l2-buffer'>v4l2_buffer</link>">
<!ENTITY v4l2-plane "struct&nbsp;<link linkend='v4l2-plane'>v4l2_plane</link>">
<!ENTITY v4l2-capability "struct&nbsp;<link linkend='v4l2-capability'>v4l2_capability</link>">
<!ENTITY v4l2-captureparm "struct&nbsp;<link linkend='v4l2-captureparm'>v4l2_captureparm</link>">
<!ENTITY v4l2-clip "struct&nbsp;<link linkend='v4l2-clip'>v4l2_clip</link>">
@ -162,11 +182,14 @@
<!ENTITY v4l2-hw-freq-seek "struct&nbsp;<link linkend='v4l2-hw-freq-seek'>v4l2_hw_freq_seek</link>">
<!ENTITY v4l2-input "struct&nbsp;<link linkend='v4l2-input'>v4l2_input</link>">
<!ENTITY v4l2-jpegcompression "struct&nbsp;<link linkend='v4l2-jpegcompression'>v4l2_jpegcompression</link>">
<!ENTITY v4l2-mbus-framefmt "struct&nbsp;<link linkend='v4l2-mbus-framefmt'>v4l2_mbus_framefmt</link>">
<!ENTITY v4l2-modulator "struct&nbsp;<link linkend='v4l2-modulator'>v4l2_modulator</link>">
<!ENTITY v4l2-mpeg-vbi-fmt-ivtv "struct&nbsp;<link linkend='v4l2-mpeg-vbi-fmt-ivtv'>v4l2_mpeg_vbi_fmt_ivtv</link>">
<!ENTITY v4l2-output "struct&nbsp;<link linkend='v4l2-output'>v4l2_output</link>">
<!ENTITY v4l2-outputparm "struct&nbsp;<link linkend='v4l2-outputparm'>v4l2_outputparm</link>">
<!ENTITY v4l2-pix-format "struct&nbsp;<link linkend='v4l2-pix-format'>v4l2_pix_format</link>">
<!ENTITY v4l2-pix-format-mplane "struct&nbsp;<link linkend='v4l2-pix-format-mplane'>v4l2_pix_format_mplane</link>">
<!ENTITY v4l2-plane-pix-format "struct&nbsp;<link linkend='v4l2-plane-pix-format'>v4l2_plane_pix_format</link>">
<!ENTITY v4l2-queryctrl "struct&nbsp;<link linkend='v4l2-queryctrl'>v4l2_queryctrl</link>">
<!ENTITY v4l2-querymenu "struct&nbsp;<link linkend='v4l2-querymenu'>v4l2_querymenu</link>">
<!ENTITY v4l2-rect "struct&nbsp;<link linkend='v4l2-rect'>v4l2_rect</link>">
@ -174,6 +197,12 @@
<!ENTITY v4l2-sliced-vbi-cap "struct&nbsp;<link linkend='v4l2-sliced-vbi-cap'>v4l2_sliced_vbi_cap</link>">
<!ENTITY v4l2-sliced-vbi-data "struct&nbsp;<link linkend='v4l2-sliced-vbi-data'>v4l2_sliced_vbi_data</link>">
<!ENTITY v4l2-sliced-vbi-format "struct&nbsp;<link linkend='v4l2-sliced-vbi-format'>v4l2_sliced_vbi_format</link>">
<!ENTITY v4l2-subdev-frame-interval "struct&nbsp;<link linkend='v4l2-subdev-frame-interval'>v4l2_subdev_frame_interval</link>">
<!ENTITY v4l2-subdev-frame-interval-enum "struct&nbsp;<link linkend='v4l2-subdev-frame-interval-enum'>v4l2_subdev_frame_interval_enum</link>">
<!ENTITY v4l2-subdev-frame-size-enum "struct&nbsp;<link linkend='v4l2-subdev-frame-size-enum'>v4l2_subdev_frame_size_enum</link>">
<!ENTITY v4l2-subdev-crop "struct&nbsp;<link linkend='v4l2-subdev-crop'>v4l2_subdev_crop</link>">
<!ENTITY v4l2-subdev-format "struct&nbsp;<link linkend='v4l2-subdev-format'>v4l2_subdev_format</link>">
<!ENTITY v4l2-subdev-mbus-code-enum "struct&nbsp;<link linkend='v4l2-subdev-mbus-code-enum'>v4l2_subdev_mbus_code_enum</link>">
<!ENTITY v4l2-standard "struct&nbsp;<link linkend='v4l2-standard'>v4l2_standard</link>">
<!ENTITY v4l2-streamparm "struct&nbsp;<link linkend='v4l2-streamparm'>v4l2_streamparm</link>">
<!ENTITY v4l2-timecode "struct&nbsp;<link linkend='v4l2-timecode'>v4l2_timecode</link>">
@ -181,6 +210,12 @@
<!ENTITY v4l2-vbi-format "struct&nbsp;<link linkend='v4l2-vbi-format'>v4l2_vbi_format</link>">
<!ENTITY v4l2-window "struct&nbsp;<link linkend='v4l2-window'>v4l2_window</link>">
<!ENTITY media-device-info "struct&nbsp;<link linkend='media-device-info'>media_device_info</link>">
<!ENTITY media-entity-desc "struct&nbsp;<link linkend='media-entity-desc'>media_entity_desc</link>">
<!ENTITY media-links-enum "struct&nbsp;<link linkend='media-links-enum'>media_links_enum</link>">
<!ENTITY media-pad-desc "struct&nbsp;<link linkend='media-pad-desc'>media_pad_desc</link>">
<!ENTITY media-link-desc "struct&nbsp;<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">

3
Documentation/DocBook/media.tmpl
Просмотреть файл

@ -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;

1
Documentation/DocBook/rapidio.tmpl
Просмотреть файл

@ -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>

Двоичные данные
Documentation/DocBook/v4l/bayer.pdf Normal file
Просмотреть файл

Двоичный файл не отображается.

Двоичные данные
Documentation/DocBook/v4l/bayer.png Normal file
Просмотреть файл

Двоичный файл не отображается.
Режим "рядом"

После

Ширина:  |  Высота:  |  Размер: 9.5 KiB

2
Documentation/DocBook/v4l/common.xml
Просмотреть файл

@ -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>

26
Documentation/DocBook/v4l/compat.xml
Просмотреть файл

@ -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>

13
Documentation/DocBook/v4l/dev-capture.xml
Просмотреть файл

@ -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

13
Documentation/DocBook/v4l/dev-output.xml
Просмотреть файл

@ -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

313
Documentation/DocBook/v4l/dev-subdev.xml Normal file
Просмотреть файл

@ -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;

10
Documentation/DocBook/v4l/func-mmap.xml
Просмотреть файл

@ -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>

3
Documentation/DocBook/v4l/func-munmap.xml
Просмотреть файл

@ -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>

283
Documentation/DocBook/v4l/io.xml
Просмотреть файл

@ -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 (&amp;reqbuf, 0, sizeof (reqbuf));
memset(&amp;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;, &amp;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 &lt; 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 &lt; reqbuf.count; i++) {
&v4l2-buffer; buffer;
memset (&amp;buffer, 0, sizeof (buffer));
memset(&amp;buffer, 0, sizeof(buffer));
buffer.type = reqbuf.type;
buffer.memory = V4L2_MEMORY_MMAP;
buffer.index = i;
if (-1 == ioctl (fd, &VIDIOC-QUERYBUF;, &amp;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 &lt; 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(&amp;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;, &amp;reqbuf) &lt; 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 &lt; 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 &lt; reqbuf.count; i++) {
&v4l2-buffer; buffer;
&v4l2-plane; planes[FMT_NUM_PLANES];
memset(&amp;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;, &amp;buffer) &lt; 0) {
perror("VIDIOC_QUERYBUF");
exit(EXIT_FAILURE);
}
/* Every plane has to be mapped separately */
for (j = 0; j &lt; 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 &lt; reqbuf.count; i++)
for (j = 0; j &lt; 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;, &amp;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>

2
Documentation/DocBook/v4l/lirc_device_interface.xml
Просмотреть файл

@ -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>

89
Documentation/DocBook/v4l/media-controller.xml Normal file
Просмотреть файл

@ -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>

59
Documentation/DocBook/v4l/media-func-close.xml Normal file
Просмотреть файл

@ -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 &lt;unistd.h&gt;</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>

116
Documentation/DocBook/v4l/media-func-ioctl.xml Normal file
Просмотреть файл

@ -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 &lt;sys/ioctl.h&gt;</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>

94
Documentation/DocBook/v4l/media-func-open.xml Normal file
Просмотреть файл

@ -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 &lt;fcntl.h&gt;</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>

133
Documentation/DocBook/v4l/media-ioc-device-info.xml Normal file
Просмотреть файл

@ -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>

308
Documentation/DocBook/v4l/media-ioc-enum-entities.xml Normal file
Просмотреть файл

@ -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>

207
Documentation/DocBook/v4l/media-ioc-enum-links.xml Normal file
Просмотреть файл

@ -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>

93
Documentation/DocBook/v4l/media-ioc-setup-link.xml Normal file
Просмотреть файл

@ -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>

Двоичные данные
Documentation/DocBook/v4l/nv12mt.gif Normal file
Просмотреть файл

Двоичный файл не отображается.
Режим "рядом"

После

Ширина:  |  Высота:  |  Размер: 2.1 KiB

Двоичные данные
Documentation/DocBook/v4l/nv12mt_example.gif Normal file
Просмотреть файл

Двоичный файл не отображается.
Режим "рядом"

После

Ширина:  |  Высота:  |  Размер: 6.7 KiB

Двоичные данные
Documentation/DocBook/v4l/pipeline.pdf Normal file
Просмотреть файл

Двоичный файл не отображается.

Двоичные данные
Documentation/DocBook/v4l/pipeline.png Normal file
Просмотреть файл

Двоичный файл не отображается.
Режим "рядом"

После

Ширина:  |  Высота:  |  Размер: 12 KiB

154
Documentation/DocBook/v4l/pixfmt-nv12m.xml Normal file
Просмотреть файл

@ -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 &times; 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&nbsp;+&nbsp;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&nbsp;+&nbsp;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&nbsp;+&nbsp;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&nbsp;+&nbsp;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&nbsp;+&nbsp;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&nbsp;+&nbsp;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:
-->

74
Documentation/DocBook/v4l/pixfmt-nv12mt.xml Normal file
Просмотреть файл

@ -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 &frac12; 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:
-->

90
Documentation/DocBook/v4l/pixfmt-srggb12.xml Normal file
Просмотреть файл

@ -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 &times; 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&nbsp;+&nbsp;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&nbsp;+&nbsp;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&nbsp;+&nbsp;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&nbsp;+&nbsp;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>

162
Documentation/DocBook/v4l/pixfmt-yuv420m.xml Normal file
Просмотреть файл

@ -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 &times; 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&nbsp;+&nbsp;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&nbsp;+&nbsp;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&nbsp;+&nbsp;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&nbsp;+&nbsp;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&nbsp;+&nbsp;0:</entry>
<entry>Cb<subscript>00</subscript></entry>
<entry>Cb<subscript>01</subscript></entry>
</row>
<row>
<entry>start1&nbsp;+&nbsp;2:</entry>
<entry>Cb<subscript>10</subscript></entry>
<entry>Cb<subscript>11</subscript></entry>
</row>
<row><entry></entry></row>
<row>
<entry>start2&nbsp;+&nbsp;0:</entry>
<entry>Cr<subscript>00</subscript></entry>
<entry>Cr<subscript>01</subscript></entry>
</row>
<row>
<entry>start2&nbsp;+&nbsp;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:
-->

119
Documentation/DocBook/v4l/pixfmt.xml
Просмотреть файл

@ -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>

62
Documentation/DocBook/v4l/planar-apis.xml Normal file
Просмотреть файл

@ -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>

2467
Documentation/DocBook/v4l/subdev-formats.xml Normal file
Просмотреть файл

Разница между файлами не показана из-за своего большого размера Загрузить разницу

30
Documentation/DocBook/v4l/v4l2.xml
Просмотреть файл

@ -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;

141
Documentation/DocBook/v4l/videodev2.h.xml
Просмотреть файл

@ -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 */

2
Documentation/DocBook/v4l/vidioc-enum-fmt.xml
Просмотреть файл

@ -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>

15
Documentation/DocBook/v4l/vidioc-g-fmt.xml
Просмотреть файл

@ -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>

24
Documentation/DocBook/v4l/vidioc-qbuf.xml
Просмотреть файл

@ -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

14
Documentation/DocBook/v4l/vidioc-querybuf.xml
Просмотреть файл

@ -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>

18
Documentation/DocBook/v4l/vidioc-querycap.xml
Просмотреть файл

@ -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>

9
Documentation/DocBook/v4l/vidioc-streamon.xml
Просмотреть файл

@ -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>

152
Documentation/DocBook/v4l/vidioc-subdev-enum-frame-interval.xml Normal file
Просмотреть файл

@ -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>

154
Documentation/DocBook/v4l/vidioc-subdev-enum-frame-size.xml Normal file
Просмотреть файл

@ -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>

119
Documentation/DocBook/v4l/vidioc-subdev-enum-mbus-code.xml Normal file
Просмотреть файл

@ -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>

155
Documentation/DocBook/v4l/vidioc-subdev-g-crop.xml Normal file
Просмотреть файл

@ -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>

180
Documentation/DocBook/v4l/vidioc-subdev-g-fmt.xml Normal file
Просмотреть файл

@ -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>

141
Documentation/DocBook/v4l/vidioc-subdev-g-frame-interval.xml Normal file
Просмотреть файл

@ -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>

25
Documentation/acpi/apei/output_format.txt
Просмотреть файл

@ -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:

5
Documentation/block/biodoc.txt
Просмотреть файл

@ -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

30
Documentation/cgroups/blkio-controller.txt
Просмотреть файл

@ -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.

18
Documentation/development-process/1.Intro
Просмотреть файл

@ -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

169
Documentation/development-process/2.Process
Просмотреть файл

@ -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.

31
Documentation/development-process/3.Early-stage
Просмотреть файл

@ -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

21
Documentation/development-process/4.Coding
Просмотреть файл

@ -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.

28
Documentation/development-process/5.Posting
Просмотреть файл

@ -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.

16
Documentation/development-process/6.Followthrough
Просмотреть файл

@ -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

4
Documentation/development-process/7.AdvancedTopics
Просмотреть файл

@ -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

17
Documentation/device-mapper/dm-flakey.txt Normal file
Просмотреть файл

@ -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.

34
Documentation/devicetree/bindings/fb/sm501fb.txt Normal file
Просмотреть файл

@ -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];
};

73
Documentation/devicetree/bindings/hwmon/ads1015.txt Normal file
Просмотреть файл

@ -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>;
};

98
Documentation/devicetree/bindings/open-pic.txt Normal file
Просмотреть файл

@ -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)

8
Documentation/dvb/get_dvb_firmware
Просмотреть файл

@ -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{

16
Documentation/dvb/lmedm04.txt
Просмотреть файл

@ -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

4
Documentation/dynamic-debug-howto.txt
Просмотреть файл

@ -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

10
Documentation/fb/sm501.txt Normal file
Просмотреть файл

@ -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>]"

63
Documentation/feature-removal-schedule.txt
Просмотреть файл

@ -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>
----------------------------

2
Documentation/filesystems/Locking
Просмотреть файл

@ -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

18
Documentation/filesystems/adfs.txt
Просмотреть файл

@ -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.

10
Documentation/filesystems/exofs.txt
Просмотреть файл

@ -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]

207
Documentation/filesystems/ext4.txt
Просмотреть файл

@ -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
==========

16
Documentation/filesystems/porting
Просмотреть файл

@ -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

28
Documentation/filesystems/squashfs.txt
Просмотреть файл

@ -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

2
Documentation/filesystems/vfs.txt
Просмотреть файл

@ -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

7
Documentation/filesystems/xfs-delayed-logging-design.txt
Просмотреть файл

@ -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

72
Documentation/hwmon/ads1015 Normal file
Просмотреть файл

@ -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

19
Documentation/hwmon/f71882fg
Просмотреть файл

@ -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>

5
Documentation/hwmon/lm75
Просмотреть файл

@ -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

22
Documentation/hwmon/sch5627 Normal file
Просмотреть файл

@ -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.

45
Documentation/hwmon/twl4030-madc-hwmon Normal file
Просмотреть файл

@ -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.

127
Documentation/hwmon/w83795 Normal file
Просмотреть файл

@ -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

26
Documentation/i2c/busses/i2c-diolan-u2c Normal file
Просмотреть файл

@ -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

3
Documentation/i2c/busses/i2c-i801
Просмотреть файл

@ -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

2
Documentation/i2c/instantiating-devices
Просмотреть файл

@ -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);

18
Documentation/i2c/upgrading-clients
Просмотреть файл

@ -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,
};

Некоторые файлы не были показаны из-за слишком большого количества измененных файлов Показать больше