diff options
| author | Thomas Gleixner <tglx@linutronix.de> | 2010-02-21 20:17:22 +0100 |
|---|---|---|
| committer | Thomas Gleixner <tglx@linutronix.de> | 2010-02-21 20:17:22 +0100 |
| commit | 5f854cfc024622e4aae14d7cf422f6ff86278688 (patch) | |
| tree | 426e77c6f6e4939c80440bf1fabcb020e3ee145b /Documentation | |
| parent | cc24da0742870f152ddf1002aa39dfcd83f7cf9c (diff) | |
| parent | 4ec62b2b2e6bd7ddef7b6cea6e5db7b5578a6532 (diff) | |
| download | lwn-5f854cfc024622e4aae14d7cf422f6ff86278688.tar.gz lwn-5f854cfc024622e4aae14d7cf422f6ff86278688.zip | |
Forward to 2.6.33-rc8
Merge branch 'linus' into rt/head with a pile of conflicts.
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Diffstat (limited to 'Documentation')
432 files changed, 52354 insertions, 4217 deletions
diff --git a/Documentation/00-INDEX b/Documentation/00-INDEX index d05737aaa84b..06b982affe76 100644 --- a/Documentation/00-INDEX +++ b/Documentation/00-INDEX @@ -82,6 +82,8 @@ block/ - info on the Block I/O (BIO) layer. blockdev/ - info on block devices & drivers +btmrvl.txt + - info on Marvell Bluetooth driver usage. cachetlb.txt - describes the cache/TLB flushing interfaces Linux uses. cdrom/ diff --git a/Documentation/ABI/stable/sysfs-class-backlight b/Documentation/ABI/stable/sysfs-class-backlight new file mode 100644 index 000000000000..4d637e1c4ff7 --- /dev/null +++ b/Documentation/ABI/stable/sysfs-class-backlight @@ -0,0 +1,36 @@ +What: /sys/class/backlight/<backlight>/bl_power +Date: April 2005 +KernelVersion: 2.6.12 +Contact: Richard Purdie <rpurdie@rpsys.net> +Description: + Control BACKLIGHT power, values are FB_BLANK_* from fb.h + - FB_BLANK_UNBLANK (0) : power on. + - FB_BLANK_POWERDOWN (4) : power off +Users: HAL + +What: /sys/class/backlight/<backlight>/brightness +Date: April 2005 +KernelVersion: 2.6.12 +Contact: Richard Purdie <rpurdie@rpsys.net> +Description: + Control the brightness for this <backlight>. Values + are between 0 and max_brightness. This file will also + show the brightness level stored in the driver, which + may not be the actual brightness (see actual_brightness). +Users: HAL + +What: /sys/class/backlight/<backlight>/actual_brightness +Date: March 2006 +KernelVersion: 2.6.17 +Contact: Richard Purdie <rpurdie@rpsys.net> +Description: + Show the actual brightness by querying the hardware. +Users: HAL + +What: /sys/class/backlight/<backlight>/max_brightness +Date: April 2005 +KernelVersion: 2.6.12 +Contact: Richard Purdie <rpurdie@rpsys.net> +Description: + Maximum brightness for <backlight>. +Users: HAL diff --git a/Documentation/ABI/stable/sysfs-driver-qla2xxx b/Documentation/ABI/stable/sysfs-driver-qla2xxx new file mode 100644 index 000000000000..9a59d84497ed --- /dev/null +++ b/Documentation/ABI/stable/sysfs-driver-qla2xxx @@ -0,0 +1,8 @@ +What: /sys/bus/pci/drivers/qla2xxx/.../devices/* +Date: September 2009 +Contact: QLogic Linux Driver <linux-driver@qlogic.com> +Description: qla2xxx-udev.sh currently looks for uevent CHANGE events to + signal a firmware-dump has been generated by the driver and is + ready for retrieval. +Users: qla2xxx-udev.sh. Proposed changes should be mailed to + linux-driver@qlogic.com diff --git a/Documentation/ABI/testing/ima_policy b/Documentation/ABI/testing/ima_policy index 6434f0df012e..6cd6daefaaed 100644 --- a/Documentation/ABI/testing/ima_policy +++ b/Documentation/ABI/testing/ima_policy @@ -20,7 +20,7 @@ Description: lsm: [[subj_user=] [subj_role=] [subj_type=] [obj_user=] [obj_role=] [obj_type=]] - base: func:= [BPRM_CHECK][FILE_MMAP][INODE_PERMISSION] + base: func:= [BPRM_CHECK][FILE_MMAP][FILE_CHECK] mask:= [MAY_READ] [MAY_WRITE] [MAY_APPEND] [MAY_EXEC] fsmagic:= hex value uid:= decimal value @@ -40,11 +40,11 @@ Description: measure func=BPRM_CHECK measure func=FILE_MMAP mask=MAY_EXEC - measure func=INODE_PERM mask=MAY_READ uid=0 + measure func=FILE_CHECK mask=MAY_READ uid=0 The default policy measures all executables in bprm_check, all files mmapped executable in file_mmap, and all files - open for read by root in inode_permission. + open for read by root in do_filp_open. Examples of LSM specific definitions: @@ -54,8 +54,8 @@ Description: dont_measure obj_type=var_log_t dont_measure obj_type=auditd_log_t - measure subj_user=system_u func=INODE_PERM mask=MAY_READ - measure subj_role=system_r func=INODE_PERM mask=MAY_READ + measure subj_user=system_u func=FILE_CHECK mask=MAY_READ + measure subj_role=system_r func=FILE_CHECK mask=MAY_READ Smack: - measure subj_user=_ func=INODE_PERM mask=MAY_READ + measure subj_user=_ func=FILE_CHECK mask=MAY_READ diff --git a/Documentation/ABI/testing/procfs-diskstats b/Documentation/ABI/testing/procfs-diskstats index 99233902e09e..f91a973a37fe 100644 --- a/Documentation/ABI/testing/procfs-diskstats +++ b/Documentation/ABI/testing/procfs-diskstats @@ -8,7 +8,7 @@ Description: 1 - major number 2 - minor mumber 3 - device name - 4 - reads completed succesfully + 4 - reads completed successfully 5 - reads merged 6 - sectors read 7 - time spent reading (ms) diff --git a/Documentation/ABI/testing/sysfs-block b/Documentation/ABI/testing/sysfs-block index 5f3bedaf8e35..d2f90334bb93 100644 --- a/Documentation/ABI/testing/sysfs-block +++ b/Documentation/ABI/testing/sysfs-block @@ -4,7 +4,7 @@ Contact: Jerome Marchand <jmarchan@redhat.com> Description: The /sys/block/<disk>/stat files displays the I/O statistics of disk <disk>. They contain 11 fields: - 1 - reads completed succesfully + 1 - reads completed successfully 2 - reads merged 3 - sectors read 4 - time spent reading (ms) diff --git a/Documentation/ABI/testing/sysfs-bus-pci b/Documentation/ABI/testing/sysfs-bus-pci index 6bf68053e4b8..25be3250f7d6 100644 --- a/Documentation/ABI/testing/sysfs-bus-pci +++ b/Documentation/ABI/testing/sysfs-bus-pci @@ -84,6 +84,16 @@ Description: from this part of the device tree. Depends on CONFIG_HOTPLUG. +What: /sys/bus/pci/devices/.../reset +Date: July 2009 +Contact: Michael S. Tsirkin <mst@redhat.com> +Description: + Some devices allow an individual function to be reset + without affecting other functions in the same device. + For devices that have this support, a file named reset + will be present in sysfs. Writing 1 to this file + will perform reset. + What: /sys/bus/pci/devices/.../vpd Date: February 2008 Contact: Ben Hutchings <bhutchings@solarflare.com> diff --git a/Documentation/ABI/testing/sysfs-bus-pci-devices-cciss b/Documentation/ABI/testing/sysfs-bus-pci-devices-cciss index 0a92a7c93a62..4f29e5f1ebfa 100644 --- a/Documentation/ABI/testing/sysfs-bus-pci-devices-cciss +++ b/Documentation/ABI/testing/sysfs-bus-pci-devices-cciss @@ -31,3 +31,31 @@ Date: March 2009 Kernel Version: 2.6.30 Contact: iss_storagedev@hp.com Description: A symbolic link to /sys/block/cciss!cXdY + +Where: /sys/bus/pci/devices/<dev>/ccissX/rescan +Date: August 2009 +Kernel Version: 2.6.31 +Contact: iss_storagedev@hp.com +Description: Kicks of a rescan of the controller to discover logical + drive topology changes. + +Where: /sys/bus/pci/devices/<dev>/ccissX/cXdY/lunid +Date: August 2009 +Kernel Version: 2.6.31 +Contact: iss_storagedev@hp.com +Description: Displays the 8-byte LUN ID used to address logical + drive Y of controller X. + +Where: /sys/bus/pci/devices/<dev>/ccissX/cXdY/raid_level +Date: August 2009 +Kernel Version: 2.6.31 +Contact: iss_storagedev@hp.com +Description: Displays the RAID level of logical drive Y of + controller X. + +Where: /sys/bus/pci/devices/<dev>/ccissX/cXdY/usage_count +Date: August 2009 +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. diff --git a/Documentation/ABI/testing/sysfs-bus-usb b/Documentation/ABI/testing/sysfs-bus-usb index 7772928ee48f..a07c0f366f91 100644 --- a/Documentation/ABI/testing/sysfs-bus-usb +++ b/Documentation/ABI/testing/sysfs-bus-usb @@ -21,25 +21,27 @@ Contact: Alan Stern <stern@rowland.harvard.edu> Description: Each USB device directory will contain a file named power/level. This file holds a power-level setting for - the device, one of "on", "auto", or "suspend". + the device, either "on" or "auto". "on" means that the device is not allowed to autosuspend, although normal suspends for system sleep will still be honored. "auto" means the device will autosuspend and autoresume in the usual manner, according to the - capabilities of its driver. "suspend" means the device - is forced into a suspended state and it will not autoresume - in response to I/O requests. However remote-wakeup requests - from the device may still be enabled (the remote-wakeup - setting is controlled separately by the power/wakeup - attribute). + capabilities of its driver. During normal use, devices should be left in the "auto" - level. The other levels are meant for administrative uses. + level. The "on" level is meant for administrative uses. If you want to suspend a device immediately but leave it free to wake up in response to I/O requests, you should write "0" to power/autosuspend. + Device not capable of proper suspend and resume should be + left in the "on" level. Although the USB spec requires + devices to support suspend/resume, many of them do not. + In fact so many don't that by default, the USB core + initializes all non-hub devices in the "on" level. Some + drivers may change this setting when they are bound. + What: /sys/bus/usb/devices/.../power/persist Date: May 2007 KernelVersion: 2.6.23 @@ -144,3 +146,16 @@ Description: Write a 1 to force the device to disconnect (equivalent to unplugging a wired USB device). + +What: /sys/bus/usb/drivers/.../remove_id +Date: November 2009 +Contact: CHENG Renquan <rqcheng@smu.edu.sg> +Description: + Writing a device ID to this file will remove an ID + that was dynamically added via the new_id sysfs entry. + The format for the device ID is: + idVendor idProduct. After successfully + removing an ID, the driver will no longer support the + device. This is useful to ensure auto probing won't + match the driver to the device. For example: + # echo "046d c315" > /sys/bus/usb/drivers/foo/remove_id diff --git a/Documentation/ABI/testing/sysfs-class-lcd b/Documentation/ABI/testing/sysfs-class-lcd new file mode 100644 index 000000000000..35906bf7aa70 --- /dev/null +++ b/Documentation/ABI/testing/sysfs-class-lcd @@ -0,0 +1,23 @@ +What: /sys/class/lcd/<lcd>/lcd_power +Date: April 2005 +KernelVersion: 2.6.12 +Contact: Richard Purdie <rpurdie@rpsys.net> +Description: + Control LCD power, values are FB_BLANK_* from fb.h + - FB_BLANK_UNBLANK (0) : power on. + - FB_BLANK_POWERDOWN (4) : power off + +What: /sys/class/lcd/<lcd>/contrast +Date: April 2005 +KernelVersion: 2.6.12 +Contact: Richard Purdie <rpurdie@rpsys.net> +Description: + Current contrast of this LCD device. Value is between 0 and + /sys/class/lcd/<lcd>/max_contrast. + +What: /sys/class/lcd/<lcd>/max_contrast +Date: April 2005 +KernelVersion: 2.6.12 +Contact: Richard Purdie <rpurdie@rpsys.net> +Description: + Maximum contrast for this LCD device. diff --git a/Documentation/ABI/testing/sysfs-class-led b/Documentation/ABI/testing/sysfs-class-led new file mode 100644 index 000000000000..9e4541d71cb6 --- /dev/null +++ b/Documentation/ABI/testing/sysfs-class-led @@ -0,0 +1,28 @@ +What: /sys/class/leds/<led>/brightness +Date: March 2006 +KernelVersion: 2.6.17 +Contact: Richard Purdie <rpurdie@rpsys.net> +Description: + Set the brightness of the LED. Most LEDs don't + have hardware brightness support so will just be turned on for + non-zero brightness settings. The value is between 0 and + /sys/class/leds/<led>/max_brightness. + +What: /sys/class/leds/<led>/max_brightness +Date: March 2006 +KernelVersion: 2.6.17 +Contact: Richard Purdie <rpurdie@rpsys.net> +Description: + Maximum brightness level for this led, default is 255 (LED_FULL). + +What: /sys/class/leds/<led>/trigger +Date: March 2006 +KernelVersion: 2.6.17 +Contact: Richard Purdie <rpurdie@rpsys.net> +Description: + Set the trigger for this LED. A trigger is a kernel based source + of led events. + You can change triggers in a similar manner to the way an IO + scheduler is chosen. Trigger specific parameters can appear in + /sys/class/leds/<led> once a given trigger is selected. + diff --git a/Documentation/ABI/testing/sysfs-class-usb_host b/Documentation/ABI/testing/sysfs-class-uwb_rc-wusbhc index 46b66ad1f1b4..25b1e751b777 100644 --- a/Documentation/ABI/testing/sysfs-class-usb_host +++ b/Documentation/ABI/testing/sysfs-class-uwb_rc-wusbhc @@ -1,4 +1,4 @@ -What: /sys/class/usb_host/usb_hostN/wusb_chid +What: /sys/class/uwb_rc/uwbN/wusbhc/wusb_chid Date: July 2008 KernelVersion: 2.6.27 Contact: David Vrabel <david.vrabel@csr.com> @@ -9,7 +9,7 @@ Description: Set an all zero CHID to stop the host controller. -What: /sys/class/usb_host/usb_hostN/wusb_trust_timeout +What: /sys/class/uwb_rc/uwbN/wusbhc/wusb_trust_timeout Date: July 2008 KernelVersion: 2.6.27 Contact: David Vrabel <david.vrabel@csr.com> @@ -23,3 +23,16 @@ Description: Since this relates to security (specifically, the lifetime of PTKs and GTKs) it should not be changed from the default. + +What: /sys/class/uwb_rc/uwbN/wusbhc/wusb_phy_rate +Date: August 2009 +KernelVersion: 2.6.32 +Contact: David Vrabel <david.vrabel@csr.com> +Description: + The maximum PHY rate to use for all connected devices. + This is only of limited use for testing and + development as the hardware's automatic rate + adaptation is better then this simple control. + + Refer to [ECMA-368] section 10.3.1.1 for the value to + use. diff --git a/Documentation/ABI/testing/sysfs-devices-cache_disable b/Documentation/ABI/testing/sysfs-devices-cache_disable deleted file mode 100644 index 175bb4f70512..000000000000 --- a/Documentation/ABI/testing/sysfs-devices-cache_disable +++ /dev/null @@ -1,18 +0,0 @@ -What: /sys/devices/system/cpu/cpu*/cache/index*/cache_disable_X -Date: August 2008 -KernelVersion: 2.6.27 -Contact: mark.langsdorf@amd.com -Description: These files exist in every cpu's cache index directories. - There are currently 2 cache_disable_# files in each - directory. Reading from these files on a supported - processor will return that cache disable index value - for that processor and node. Writing to one of these - files will cause the specificed cache index to be disabled. - - Currently, only AMD Family 10h Processors support cache index - disable, and only for their L3 caches. See the BIOS and - Kernel Developer's Guide at - http://www.amd.com/us-en/assets/content_type/white_papers_and_tech_docs/31116-Public-GH-BKDG_3.20_2-4-09.pdf - for formatting information and other details on the - cache index disable. -Users: joachim.deguara@amd.com diff --git a/Documentation/ABI/testing/sysfs-devices-memory b/Documentation/ABI/testing/sysfs-devices-memory index 9fe91c02ee40..bf1627b02a03 100644 --- a/Documentation/ABI/testing/sysfs-devices-memory +++ b/Documentation/ABI/testing/sysfs-devices-memory @@ -60,6 +60,19 @@ Description: Users: hotplug memory remove tools https://w3.opensource.ibm.com/projects/powerpc-utils/ + +What: /sys/devices/system/memoryX/nodeY +Date: October 2009 +Contact: Linux Memory Management list <linux-mm@kvack.org> +Description: + When CONFIG_NUMA is enabled, a symbolic link that + points to the corresponding NUMA node directory. + + For example, the following symbolic link is created for + memory section 9 on node0: + /sys/devices/system/memory/memory9/node0 -> ../../node/node0 + + What: /sys/devices/system/node/nodeX/memoryY Date: September 2008 Contact: Gary Hade <garyhade@us.ibm.com> @@ -70,4 +83,3 @@ Description: memory section directory. For example, the following symbolic link is created for memory section 9 on node0. /sys/devices/system/node/node0/memory9 -> ../../memory/memory9 - diff --git a/Documentation/ABI/testing/sysfs-devices-system-cpu b/Documentation/ABI/testing/sysfs-devices-system-cpu new file mode 100644 index 000000000000..84a710f87c64 --- /dev/null +++ b/Documentation/ABI/testing/sysfs-devices-system-cpu @@ -0,0 +1,203 @@ +What: /sys/devices/system/cpu/ +Date: pre-git history +Contact: Linux kernel mailing list <linux-kernel@vger.kernel.org> +Description: + A collection of both global and individual CPU attributes + + Individual CPU attributes are contained in subdirectories + named by the kernel's logical CPU number, e.g.: + + /sys/devices/system/cpu/cpu#/ + +What: /sys/devices/system/cpu/sched_mc_power_savings + /sys/devices/system/cpu/sched_smt_power_savings +Date: June 2006 +Contact: Linux kernel mailing list <linux-kernel@vger.kernel.org> +Description: Discover and adjust the kernel's multi-core scheduler support. + + Possible values are: + + 0 - No power saving load balance (default value) + 1 - Fill one thread/core/package first for long running threads + 2 - Also bias task wakeups to semi-idle cpu package for power + savings + + sched_mc_power_savings is dependent upon SCHED_MC, which is + itself architecture dependent. + + sched_smt_power_savings is dependent upon SCHED_SMT, which + is itself architecture dependent. + + The two files are independent of each other. It is possible + that one file may be present without the other. + + Introduced by git commit 5c45bf27. + + +What: /sys/devices/system/cpu/kernel_max + /sys/devices/system/cpu/offline + /sys/devices/system/cpu/online + /sys/devices/system/cpu/possible + /sys/devices/system/cpu/present +Date: December 2008 +Contact: Linux kernel mailing list <linux-kernel@vger.kernel.org> +Description: CPU topology files that describe kernel limits related to + hotplug. Briefly: + + kernel_max: the maximum cpu index allowed by the kernel + configuration. + + offline: cpus that are not online because they have been + HOTPLUGGED off or exceed the limit of cpus allowed by the + kernel configuration (kernel_max above). + + online: cpus that are online and being scheduled. + + possible: cpus that have been allocated resources and can be + brought online if they are present. + + present: cpus that have been identified as being present in + the system. + + See Documentation/cputopology.txt for more information. + + +What: /sys/devices/system/cpu/probe + /sys/devices/system/cpu/release +Date: November 2009 +Contact: Linux kernel mailing list <linux-kernel@vger.kernel.org> +Description: Dynamic addition and removal of CPU's. This is not hotplug + removal, this is meant complete removal/addition of the CPU + from the system. + + probe: writes to this file will dynamically add a CPU to the + system. Information written to the file to add CPU's is + architecture specific. + + release: writes to this file dynamically remove a CPU from + the system. Information writtento the file to remove CPU's + is architecture specific. + +What: /sys/devices/system/cpu/cpu#/node +Date: October 2009 +Contact: Linux memory management mailing list <linux-mm@kvack.org> +Description: Discover NUMA node a CPU belongs to + + When CONFIG_NUMA is enabled, a symbolic link that points + to the corresponding NUMA node directory. + + For example, the following symlink is created for cpu42 + in NUMA node 2: + + /sys/devices/system/cpu/cpu42/node2 -> ../../node/node2 + + +What: /sys/devices/system/cpu/cpu#/node +Date: October 2009 +Contact: Linux memory management mailing list <linux-mm@kvack.org> +Description: Discover NUMA node a CPU belongs to + + When CONFIG_NUMA is enabled, a symbolic link that points + to the corresponding NUMA node directory. + + For example, the following symlink is created for cpu42 + in NUMA node 2: + + /sys/devices/system/cpu/cpu42/node2 -> ../../node/node2 + + +What: /sys/devices/system/cpu/cpu#/topology/core_id + /sys/devices/system/cpu/cpu#/topology/core_siblings + /sys/devices/system/cpu/cpu#/topology/core_siblings_list + /sys/devices/system/cpu/cpu#/topology/physical_package_id + /sys/devices/system/cpu/cpu#/topology/thread_siblings + /sys/devices/system/cpu/cpu#/topology/thread_siblings_list +Date: December 2008 +Contact: Linux kernel mailing list <linux-kernel@vger.kernel.org> +Description: CPU topology files that describe a logical CPU's relationship + to other cores and threads in the same physical package. + + One cpu# directory is created per logical CPU in the system, + e.g. /sys/devices/system/cpu/cpu42/. + + Briefly, the files above are: + + core_id: the CPU core ID of cpu#. Typically it is the + hardware platform's identifier (rather than the kernel's). + The actual value is architecture and platform dependent. + + core_siblings: internal kernel map of cpu#'s hardware threads + within the same physical_package_id. + + core_siblings_list: human-readable list of the logical CPU + numbers within the same physical_package_id as cpu#. + + physical_package_id: physical package id of cpu#. Typically + corresponds to a physical socket number, but the actual value + is architecture and platform dependent. + + thread_siblings: internel kernel map of cpu#'s hardware + threads within the same core as cpu# + + thread_siblings_list: human-readable list of cpu#'s hardware + threads within the same core as cpu# + + See Documentation/cputopology.txt for more information. + + +What: /sys/devices/system/cpu/cpuidle/current_driver + /sys/devices/system/cpu/cpuidle/current_governer_ro +Date: September 2007 +Contact: Linux kernel mailing list <linux-kernel@vger.kernel.org> +Description: Discover cpuidle policy and mechanism + + Various CPUs today support multiple idle levels that are + differentiated by varying exit latencies and power + consumption during idle. + + Idle policy (governor) is differentiated from idle mechanism + (driver) + + current_driver: displays current idle mechanism + + current_governor_ro: displays current idle policy + + See files in Documentation/cpuidle/ for more information. + + +What: /sys/devices/system/cpu/cpu#/cpufreq/* +Date: pre-git history +Contact: cpufreq@vger.kernel.org +Description: Discover and change clock speed of CPUs + + Clock scaling allows you to change the clock speed of the + CPUs on the fly. This is a nice method to save battery + power, because the lower the clock speed, the less power + the CPU consumes. + + There are many knobs to tweak in this directory. + + See files in Documentation/cpu-freq/ for more information. + + In particular, read Documentation/cpu-freq/user-guide.txt + to learn how to control the knobs. + + +What: /sys/devices/system/cpu/cpu*/cache/index*/cache_disable_X +Date: August 2008 +KernelVersion: 2.6.27 +Contact: mark.langsdorf@amd.com +Description: These files exist in every cpu's cache index directories. + There are currently 2 cache_disable_# files in each + directory. Reading from these files on a supported + processor will return that cache disable index value + for that processor and node. Writing to one of these + files will cause the specificed cache index to be disabled. + + Currently, only AMD Family 10h Processors support cache index + disable, and only for their L3 caches. See the BIOS and + Kernel Developer's Guide at + http://www.amd.com/us-en/assets/content_type/white_papers_and_tech_docs/31116-Public-GH-BKDG_3.20_2-4-09.pdf + for formatting information and other details on the + cache index disable. +Users: joachim.deguara@amd.com diff --git a/Documentation/ABI/testing/sysfs-gpio b/Documentation/ABI/testing/sysfs-gpio index 8aab8092ad35..80f4c94c7bef 100644 --- a/Documentation/ABI/testing/sysfs-gpio +++ b/Documentation/ABI/testing/sysfs-gpio @@ -19,6 +19,7 @@ Description: /gpioN ... for each exported GPIO #N /value ... always readable, writes fail for input GPIOs /direction ... r/w as: in, out (default low); write: high, low + /edge ... r/w as: none, falling, rising, both /gpiochipN ... for each gpiochip; #N is its first GPIO /base ... (r/o) same as N /label ... (r/o) descriptive, not necessarily unique diff --git a/Documentation/ABI/testing/sysfs-kernel-slab b/Documentation/ABI/testing/sysfs-kernel-slab index 6dcf75e594fb..8b093f8222d3 100644 --- a/Documentation/ABI/testing/sysfs-kernel-slab +++ b/Documentation/ABI/testing/sysfs-kernel-slab @@ -45,8 +45,9 @@ KernelVersion: 2.6.25 Contact: Pekka Enberg <penberg@cs.helsinki.fi>, Christoph Lameter <cl@linux-foundation.org> Description: - The alloc_fastpath file is read-only and specifies how many - objects have been allocated using the fast path. + The alloc_fastpath file shows how many objects have been + allocated using the fast path. It can be written to clear the + current count. Available when CONFIG_SLUB_STATS is enabled. What: /sys/kernel/slab/cache/alloc_from_partial @@ -55,9 +56,10 @@ KernelVersion: 2.6.25 Contact: Pekka Enberg <penberg@cs.helsinki.fi>, Christoph Lameter <cl@linux-foundation.org> Description: - The alloc_from_partial file is read-only and specifies how - many times a cpu slab has been full and it has been refilled - by using a slab from the list of partially used slabs. + The alloc_from_partial file shows how many times a cpu slab has + been full and it has been refilled by using a slab from the list + of partially used slabs. It can be written to clear the current + count. Available when CONFIG_SLUB_STATS is enabled. What: /sys/kernel/slab/cache/alloc_refill @@ -66,9 +68,9 @@ KernelVersion: 2.6.25 Contact: Pekka Enberg <penberg@cs.helsinki.fi>, Christoph Lameter <cl@linux-foundation.org> Description: - The alloc_refill file is read-only and specifies how many - times the per-cpu freelist was empty but there were objects - available as the result of remote cpu frees. + The alloc_refill file shows how many times the per-cpu freelist + was empty but there were objects available as the result of + remote cpu frees. It can be written to clear the current count. Available when CONFIG_SLUB_STATS is enabled. What: /sys/kernel/slab/cache/alloc_slab @@ -77,8 +79,9 @@ KernelVersion: 2.6.25 Contact: Pekka Enberg <penberg@cs.helsinki.fi>, Christoph Lameter <cl@linux-foundation.org> Description: - The alloc_slab file is read-only and specifies how many times - a new slab had to be allocated from the page allocator. + The alloc_slab file is shows how many times a new slab had to + be allocated from the page allocator. It can be written to + clear the current count. Available when CONFIG_SLUB_STATS is enabled. What: /sys/kernel/slab/cache/alloc_slowpath @@ -87,9 +90,10 @@ KernelVersion: 2.6.25 Contact: Pekka Enberg <penberg@cs.helsinki.fi>, Christoph Lameter <cl@linux-foundation.org> Description: - The alloc_slowpath file is read-only and specifies how many - objects have been allocated using the slow path because of a - refill or allocation from a partial or new slab. + The alloc_slowpath file shows how many objects have been + allocated using the slow path because of a refill or + allocation from a partial or new slab. It can be written to + clear the current count. Available when CONFIG_SLUB_STATS is enabled. What: /sys/kernel/slab/cache/cache_dma @@ -117,10 +121,11 @@ KernelVersion: 2.6.31 Contact: Pekka Enberg <penberg@cs.helsinki.fi>, Christoph Lameter <cl@linux-foundation.org> Description: - The file cpuslab_flush is read-only and specifies how many - times a cache's cpu slabs have been flushed as the result of - destroying or shrinking a cache, a cpu going offline, or as - the result of forcing an allocation from a certain node. + The file cpuslab_flush shows how many times a cache's cpu slabs + have been flushed as the result of destroying or shrinking a + cache, a cpu going offline, or as the result of forcing an + allocation from a certain node. It can be written to clear the + current count. Available when CONFIG_SLUB_STATS is enabled. What: /sys/kernel/slab/cache/ctor @@ -139,8 +144,8 @@ KernelVersion: 2.6.25 Contact: Pekka Enberg <penberg@cs.helsinki.fi>, Christoph Lameter <cl@linux-foundation.org> Description: - The file deactivate_empty is read-only and specifies how many - times an empty cpu slab was deactivated. + The deactivate_empty file shows how many times an empty cpu slab + was deactivated. It can be written to clear the current count. Available when CONFIG_SLUB_STATS is enabled. What: /sys/kernel/slab/cache/deactivate_full @@ -149,8 +154,8 @@ KernelVersion: 2.6.25 Contact: Pekka Enberg <penberg@cs.helsinki.fi>, Christoph Lameter <cl@linux-foundation.org> Description: - The file deactivate_full is read-only and specifies how many - times a full cpu slab was deactivated. + The deactivate_full file shows how many times a full cpu slab + was deactivated. It can be written to clear the current count. Available when CONFIG_SLUB_STATS is enabled. What: /sys/kernel/slab/cache/deactivate_remote_frees @@ -159,9 +164,9 @@ KernelVersion: 2.6.25 Contact: Pekka Enberg <penberg@cs.helsinki.fi>, Christoph Lameter <cl@linux-foundation.org> Description: - The file deactivate_remote_frees is read-only and specifies how - many times a cpu slab has been deactivated and contained free - objects that were freed remotely. + The deactivate_remote_frees file shows how many times a cpu slab + has been deactivated and contained free objects that were freed + remotely. It can be written to clear the current count. Available when CONFIG_SLUB_STATS is enabled. What: /sys/kernel/slab/cache/deactivate_to_head @@ -170,9 +175,9 @@ KernelVersion: 2.6.25 Contact: Pekka Enberg <penberg@cs.helsinki.fi>, Christoph Lameter <cl@linux-foundation.org> Description: - The file deactivate_to_head is read-only and specifies how - many times a partial cpu slab was deactivated and added to the - head of its node's partial list. + The deactivate_to_head file shows how many times a partial cpu + slab was deactivated and added to the head of its node's partial + list. It can be written to clear the current count. Available when CONFIG_SLUB_STATS is enabled. What: /sys/kernel/slab/cache/deactivate_to_tail @@ -181,9 +186,9 @@ KernelVersion: 2.6.25 Contact: Pekka Enberg <penberg@cs.helsinki.fi>, Christoph Lameter <cl@linux-foundation.org> Description: - The file deactivate_to_tail is read-only and specifies how - many times a partial cpu slab was deactivated and added to the - tail of its node's partial list. + The deactivate_to_tail file shows how many times a partial cpu + slab was deactivated and added to the tail of its node's partial + list. It can be written to clear the current count. Available when CONFIG_SLUB_STATS is enabled. What: /sys/kernel/slab/cache/destroy_by_rcu @@ -201,9 +206,9 @@ KernelVersion: 2.6.25 Contact: Pekka Enberg <penberg@cs.helsinki.fi>, Christoph Lameter <cl@linux-foundation.org> Description: - The file free_add_partial is read-only and specifies how many - times an object has been freed in a full slab so that it had to - added to its node's partial list. + The free_add_partial file shows how many times an object has + been freed in a full slab so that it had to added to its node's + partial list. It can be written to clear the current count. Available when CONFIG_SLUB_STATS is enabled. What: /sys/kernel/slab/cache/free_calls @@ -222,9 +227,9 @@ KernelVersion: 2.6.25 Contact: Pekka Enberg <penberg@cs.helsinki.fi>, Christoph Lameter <cl@linux-foundation.org> Description: - The free_fastpath file is read-only and specifies how many - objects have been freed using the fast path because it was an - object from the cpu slab. + The free_fastpath file shows how many objects have been freed + using the fast path because it was an object from the cpu slab. + It can be written to clear the current count. Available when CONFIG_SLUB_STATS is enabled. What: /sys/kernel/slab/cache/free_frozen @@ -233,9 +238,9 @@ KernelVersion: 2.6.25 Contact: Pekka Enberg <penberg@cs.helsinki.fi>, Christoph Lameter <cl@linux-foundation.org> Description: - The free_frozen file is read-only and specifies how many - objects have been freed to a frozen slab (i.e. a remote cpu - slab). + The free_frozen file shows how many objects have been freed to + a frozen slab (i.e. a remote cpu slab). It can be written to + clear the current count. Available when CONFIG_SLUB_STATS is enabled. What: /sys/kernel/slab/cache/free_remove_partial @@ -244,9 +249,10 @@ KernelVersion: 2.6.25 Contact: Pekka Enberg <penberg@cs.helsinki.fi>, Christoph Lameter <cl@linux-foundation.org> Description: - The file free_remove_partial is read-only and specifies how - many times an object has been freed to a now-empty slab so - that it had to be removed from its node's partial list. + The free_remove_partial file shows how many times an object has + been freed to a now-empty slab so that it had to be removed from + its node's partial list. It can be written to clear the current + count. Available when CONFIG_SLUB_STATS is enabled. What: /sys/kernel/slab/cache/free_slab @@ -255,8 +261,9 @@ KernelVersion: 2.6.25 Contact: Pekka Enberg <penberg@cs.helsinki.fi>, Christoph Lameter <cl@linux-foundation.org> Description: - The free_slab file is read-only and specifies how many times an - empty slab has been freed back to the page allocator. + The free_slab file shows how many times an empty slab has been + freed back to the page allocator. It can be written to clear + the current count. Available when CONFIG_SLUB_STATS is enabled. What: /sys/kernel/slab/cache/free_slowpath @@ -265,9 +272,9 @@ KernelVersion: 2.6.25 Contact: Pekka Enberg <penberg@cs.helsinki.fi>, Christoph Lameter <cl@linux-foundation.org> Description: - The free_slowpath file is read-only and specifies how many - objects have been freed using the slow path (i.e. to a full or - partial slab). + The free_slowpath file shows how many objects have been freed + using the slow path (i.e. to a full or partial slab). It can + be written to clear the current count. Available when CONFIG_SLUB_STATS is enabled. What: /sys/kernel/slab/cache/hwcache_align @@ -346,10 +353,10 @@ KernelVersion: 2.6.26 Contact: Pekka Enberg <penberg@cs.helsinki.fi>, Christoph Lameter <cl@linux-foundation.org> Description: - The file order_fallback is read-only and specifies how many - times an allocation of a new slab has not been possible at the - cache's order and instead fallen back to its minimum possible - order. + The order_fallback file shows how many times an allocation of a + new slab has not been possible at the cache's order and instead + fallen back to its minimum possible order. It can be written to + clear the current count. Available when CONFIG_SLUB_STATS is enabled. What: /sys/kernel/slab/cache/partial diff --git a/Documentation/ABI/testing/sysfs-memory-page-offline b/Documentation/ABI/testing/sysfs-memory-page-offline new file mode 100644 index 000000000000..e14703f12fdf --- /dev/null +++ b/Documentation/ABI/testing/sysfs-memory-page-offline @@ -0,0 +1,44 @@ +What: /sys/devices/system/memory/soft_offline_page +Date: Sep 2009 +KernelVersion: 2.6.33 +Contact: andi@firstfloor.org +Description: + Soft-offline the memory page containing the physical address + written into this file. Input is a hex number specifying the + physical address of the page. The kernel will then attempt + to soft-offline it, by moving the contents elsewhere or + dropping it if possible. The kernel will then be placed + on the bad page list and never be reused. + + The offlining is done in kernel specific granuality. + Normally it's the base page size of the kernel, but + this might change. + + The page must be still accessible, not poisoned. The + kernel will never kill anything for this, but rather + fail the offline. Return value is the size of the + number, or a error when the offlining failed. Reading + the file is not allowed. + +What: /sys/devices/system/memory/hard_offline_page +Date: Sep 2009 +KernelVersion: 2.6.33 +Contact: andi@firstfloor.org +Description: + Hard-offline the memory page containing the physical + address written into this file. Input is a hex number + specifying the physical address of the page. The + kernel will then attempt to hard-offline the page, by + trying to drop the page or killing any owner or + triggering IO errors if needed. Note this may kill + any processes owning the page. The kernel will avoid + to access this page assuming it's poisoned by the + hardware. + + The offlining is done in kernel specific granuality. + Normally it's the base page size of the kernel, but + this might change. + + Return value is the size of the number, or a error when + the offlining failed. + Reading the file is not allowed. diff --git a/Documentation/ABI/testing/sysfs-platform-asus-laptop b/Documentation/ABI/testing/sysfs-platform-asus-laptop new file mode 100644 index 000000000000..a1cb660c50cf --- /dev/null +++ b/Documentation/ABI/testing/sysfs-platform-asus-laptop @@ -0,0 +1,52 @@ +What: /sys/devices/platform/asus-laptop/display +Date: January 2007 +KernelVersion: 2.6.20 +Contact: "Corentin Chary" <corentincj@iksaif.net> +Description: + This file allows display switching. The value + is composed by 4 bits and defined as follow: + 4321 + |||`- LCD + ||`-- CRT + |`--- TV + `---- DVI + Ex: - 0 (0000b) means no display + - 3 (0011b) CRT+LCD. + +What: /sys/devices/platform/asus-laptop/gps +Date: January 2007 +KernelVersion: 2.6.20 +Contact: "Corentin Chary" <corentincj@iksaif.net> +Description: + Control the gps device. 1 means on, 0 means off. +Users: Lapsus + +What: /sys/devices/platform/asus-laptop/ledd +Date: January 2007 +KernelVersion: 2.6.20 +Contact: "Corentin Chary" <corentincj@iksaif.net> +Description: + Some models like the W1N have a LED display that can be + used to display several informations. + To control the LED display, use the following : + echo 0x0T000DDD > /sys/devices/platform/asus-laptop/ + where T control the 3 letters display, and DDD the 3 digits display. + The DDD table can be found in Documentation/laptops/asus-laptop.txt + +What: /sys/devices/platform/asus-laptop/bluetooth +Date: January 2007 +KernelVersion: 2.6.20 +Contact: "Corentin Chary" <corentincj@iksaif.net> +Description: + Control the bluetooth device. 1 means on, 0 means off. + This may control the led, the device or both. +Users: Lapsus + +What: /sys/devices/platform/asus-laptop/wlan +Date: January 2007 +KernelVersion: 2.6.20 +Contact: "Corentin Chary" <corentincj@iksaif.net> +Description: + Control the bluetooth device. 1 means on, 0 means off. + This may control the led, the device or both. +Users: Lapsus diff --git a/Documentation/ABI/testing/sysfs-platform-eeepc-laptop b/Documentation/ABI/testing/sysfs-platform-eeepc-laptop new file mode 100644 index 000000000000..7445dfb321b5 --- /dev/null +++ b/Documentation/ABI/testing/sysfs-platform-eeepc-laptop @@ -0,0 +1,50 @@ +What: /sys/devices/platform/eeepc-laptop/disp +Date: May 2008 +KernelVersion: 2.6.26 +Contact: "Corentin Chary" <corentincj@iksaif.net> +Description: + This file allows display switching. + - 1 = LCD + - 2 = CRT + - 3 = LCD+CRT + If you run X11, you should use xrandr instead. + +What: /sys/devices/platform/eeepc-laptop/camera +Date: May 2008 +KernelVersion: 2.6.26 +Contact: "Corentin Chary" <corentincj@iksaif.net> +Description: + Control the camera. 1 means on, 0 means off. + +What: /sys/devices/platform/eeepc-laptop/cardr +Date: May 2008 +KernelVersion: 2.6.26 +Contact: "Corentin Chary" <corentincj@iksaif.net> +Description: + Control the card reader. 1 means on, 0 means off. + +What: /sys/devices/platform/eeepc-laptop/cpufv +Date: Jun 2009 +KernelVersion: 2.6.31 +Contact: "Corentin Chary" <corentincj@iksaif.net> +Description: + Change CPU clock configuration. + On the Eee PC 1000H there are three available clock configuration: + * 0 -> Super Performance Mode + * 1 -> High Performance Mode + * 2 -> Power Saving Mode + On Eee PC 701 there is only 2 available clock configurations. + Available configuration are listed in available_cpufv file. + Reading this file will show the raw hexadecimal value which + is defined as follow: + | 8 bit | 8 bit | + | `---- Current mode + `------------ Availables modes + For example, 0x301 means: mode 1 selected, 3 available modes. + +What: /sys/devices/platform/eeepc-laptop/available_cpufv +Date: Jun 2009 +KernelVersion: 2.6.31 +Contact: "Corentin Chary" <corentincj@iksaif.net> +Description: + List available cpufv modes. diff --git a/Documentation/Changes b/Documentation/Changes index 6d0f1efc5bf6..f08b313cd235 100644 --- a/Documentation/Changes +++ b/Documentation/Changes @@ -49,6 +49,8 @@ o oprofile 0.9 # oprofiled --version o udev 081 # udevinfo -V o grub 0.93 # grub --version o mcelog 0.6 +o iptables 1.4.1 # iptables -V + Kernel compilation ================== diff --git a/Documentation/DocBook/Makefile b/Documentation/DocBook/Makefile index 9632444f6c62..325cfd1d6d99 100644 --- a/Documentation/DocBook/Makefile +++ b/Documentation/DocBook/Makefile @@ -8,13 +8,13 @@ DOCBOOKS := z8530book.xml mcabook.xml device-drivers.xml \ kernel-hacking.xml kernel-locking.xml deviceiobook.xml \ - procfs-guide.xml writing_usb_driver.xml networking.xml \ + writing_usb_driver.xml networking.xml \ kernel-api.xml filesystems.xml lsm.xml usb.xml kgdb.xml \ gadget.xml libata.xml mtdnand.xml librs.xml rapidio.xml \ genericirq.xml s390-drivers.xml uio-howto.xml scsi.xml \ mac80211.xml debugobjects.xml sh.xml regulator.xml \ alsa-driver-api.xml writing-an-alsa-driver.xml \ - tracepoint.xml + tracepoint.xml media.xml ### # The build process is as follows (targets): @@ -32,10 +32,10 @@ PS_METHOD = $(prefer-db2x) ### # The targets that may be used. -PHONY += xmldocs sgmldocs psdocs pdfdocs htmldocs mandocs installmandocs cleandocs +PHONY += xmldocs sgmldocs psdocs pdfdocs htmldocs mandocs installmandocs cleandocs xmldoclinks BOOKS := $(addprefix $(obj)/,$(DOCBOOKS)) -xmldocs: $(BOOKS) +xmldocs: $(BOOKS) xmldoclinks sgmldocs: xmldocs PS := $(patsubst %.xml, %.ps, $(BOOKS)) @@ -47,10 +47,23 @@ pdfdocs: $(PDF) HTML := $(sort $(patsubst %.xml, %.html, $(BOOKS))) htmldocs: $(HTML) $(call build_main_index) + $(call build_images) 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/ + +xmldoclinks: +ifneq ($(objtree),$(srctree)) + for dep in dvb media-entities.tmpl media-indices.tmpl v4l; do \ + rm -f $(objtree)/Documentation/DocBook/$$dep \ + && ln -s $(srctree)/Documentation/DocBook/$$dep $(objtree)/Documentation/DocBook/ \ + || exit; \ + done +endif + installmandocs: mandocs mkdir -p /usr/local/man/man9/ install Documentation/DocBook/man/*.9.gz /usr/local/man/man9/ @@ -61,7 +74,7 @@ KERNELDOC = $(srctree)/scripts/kernel-doc DOCPROC = $(objtree)/scripts/basic/docproc XMLTOFLAGS = -m $(srctree)/Documentation/DocBook/stylesheet.xsl -#XMLTOFLAGS += --skip-validation +XMLTOFLAGS += --skip-validation ### # DOCPROC is used for two purposes: @@ -97,17 +110,6 @@ endif # Changes in kernel-doc force a rebuild of all documentation $(BOOKS): $(KERNELDOC) -### -# procfs guide uses a .c file as example code. -# This requires an explicit dependency -C-procfs-example = procfs_example.xml -C-procfs-example2 = $(addprefix $(obj)/,$(C-procfs-example)) -$(obj)/procfs-guide.xml: $(C-procfs-example2) - -# List of programs to build -##oops, this is a kernel module::hostprogs-y := procfs_example -obj-m += procfs_example.o - # Tell kbuild to always build the programs always := $(hostprogs-y) @@ -234,7 +236,7 @@ clean-files := $(DOCBOOKS) \ $(patsubst %.xml, %.pdf, $(DOCBOOKS)) \ $(patsubst %.xml, %.html, $(DOCBOOKS)) \ $(patsubst %.xml, %.9, $(DOCBOOKS)) \ - $(C-procfs-example) $(index) + $(index) clean-dirs := $(patsubst %.xml,%,$(DOCBOOKS)) man diff --git a/Documentation/DocBook/device-drivers.tmpl b/Documentation/DocBook/device-drivers.tmpl index 94a20fe8fedf..f9a6e2c75f12 100644 --- a/Documentation/DocBook/device-drivers.tmpl +++ b/Documentation/DocBook/device-drivers.tmpl @@ -293,10 +293,23 @@ X!Idrivers/video/console/fonts.c <chapter id="input_subsystem"> <title>Input Subsystem</title> + <sect1><title>Input core</title> !Iinclude/linux/input.h !Edrivers/input/input.c !Edrivers/input/ff-core.c !Edrivers/input/ff-memless.c + </sect1> + <sect1><title>Polled input devices</title> +!Iinclude/linux/input-polldev.h +!Edrivers/input/input-polldev.c + </sect1> + <sect1><title>Matrix keyboars/keypads</title> +!Iinclude/linux/input/matrix_keypad.h + </sect1> + <sect1><title>Sparse keymap support</title> +!Iinclude/linux/input/sparse-keymap.h +!Edrivers/input/sparse-keymap.c + </sect1> </chapter> <chapter id="spi"> diff --git a/Documentation/DocBook/dvb/.gitignore b/Documentation/DocBook/dvb/.gitignore new file mode 100644 index 000000000000..d7ec32eafac9 --- /dev/null +++ b/Documentation/DocBook/dvb/.gitignore @@ -0,0 +1 @@ +!*.xml diff --git a/Documentation/DocBook/dvb/audio.xml b/Documentation/DocBook/dvb/audio.xml new file mode 100644 index 000000000000..eeb96b8a0864 --- /dev/null +++ b/Documentation/DocBook/dvb/audio.xml @@ -0,0 +1,1473 @@ +<title>DVB Audio Device</title> +<para>The DVB audio device controls the MPEG2 audio decoder of the DVB hardware. It +can be accessed through <emphasis role="tt">/dev/dvb/adapter0/audio0</emphasis>. Data types and and +ioctl definitions can be accessed by including <emphasis role="tt">linux/dvb/video.h</emphasis> in your +application. +</para> +<para>Please note that some DVB cards don’t have their own MPEG decoder, which results in +the omission of the audio and video device. +</para> + +<section id="audio_data_types"> +<title>Audio Data Types</title> +<para>This section describes the structures, data types and defines used when talking to the +audio device. +</para> + +<section id="audio_stream_source_t"> +<title>audio_stream_source_t</title> +<para>The audio stream source is set through the AUDIO_SELECT_SOURCE call and can take +the following values, depending on whether we are replaying from an internal (demux) or +external (user write) source. +</para> +<programlisting> + typedef enum { + AUDIO_SOURCE_DEMUX, + AUDIO_SOURCE_MEMORY + } audio_stream_source_t; +</programlisting> +<para>AUDIO_SOURCE_DEMUX selects the demultiplexer (fed either by the frontend or the +DVR device) as the source of the video stream. If AUDIO_SOURCE_MEMORY +is selected the stream comes from the application through the <emphasis role="tt">write()</emphasis> system +call. +</para> + +</section> +<section id="audio_play_state_t"> +<title>audio_play_state_t</title> +<para>The following values can be returned by the AUDIO_GET_STATUS call representing the +state of audio playback. +</para> +<programlisting> + typedef enum { + AUDIO_STOPPED, + AUDIO_PLAYING, + AUDIO_PAUSED + } audio_play_state_t; +</programlisting> + +</section> +<section id="audio_channel_select_t"> +<title>audio_channel_select_t</title> +<para>The audio channel selected via AUDIO_CHANNEL_SELECT is determined by the +following values. +</para> +<programlisting> + typedef enum { + AUDIO_STEREO, + AUDIO_MONO_LEFT, + AUDIO_MONO_RIGHT, + } audio_channel_select_t; +</programlisting> + +</section> +<section id="struct_audio_status"> +<title>struct audio_status</title> +<para>The AUDIO_GET_STATUS call returns the following structure informing about various +states of the playback operation. +</para> +<programlisting> + typedef struct audio_status { + boolean AV_sync_state; + boolean mute_state; + audio_play_state_t play_state; + audio_stream_source_t stream_source; + audio_channel_select_t channel_select; + boolean bypass_mode; + } audio_status_t; +</programlisting> + +</section> +<section id="struct_audio_mixer"> +<title>struct audio_mixer</title> +<para>The following structure is used by the AUDIO_SET_MIXER call to set the audio +volume. +</para> +<programlisting> + typedef struct audio_mixer { + unsigned int volume_left; + unsigned int volume_right; + } audio_mixer_t; +</programlisting> + +</section> +<section id="audio_encodings"> +<title>audio encodings</title> +<para>A call to AUDIO_GET_CAPABILITIES returns an unsigned integer with the following +bits set according to the hardwares capabilities. +</para> +<programlisting> + #define AUDIO_CAP_DTS 1 + #define AUDIO_CAP_LPCM 2 + #define AUDIO_CAP_MP1 4 + #define AUDIO_CAP_MP2 8 + #define AUDIO_CAP_MP3 16 + #define AUDIO_CAP_AAC 32 + #define AUDIO_CAP_OGG 64 + #define AUDIO_CAP_SDDS 128 + #define AUDIO_CAP_AC3 256 +</programlisting> + +</section> +<section id="struct_audio_karaoke"> +<title>struct audio_karaoke</title> +<para>The ioctl AUDIO_SET_KARAOKE uses the following format: +</para> +<programlisting> + typedef + struct audio_karaoke{ + int vocal1; + int vocal2; + int melody; + } audio_karaoke_t; +</programlisting> +<para>If Vocal1 or Vocal2 are non-zero, they get mixed into left and right t at 70% each. If both, +Vocal1 and Vocal2 are non-zero, Vocal1 gets mixed into the left channel and Vocal2 into the +right channel at 100% each. Ff Melody is non-zero, the melody channel gets mixed into left +and right. +</para> + +</section> +<section id="audio_attributes"> +<title>audio attributes</title> +<para>The following attributes can be set by a call to AUDIO_SET_ATTRIBUTES: +</para> +<programlisting> + typedef uint16_t audio_attributes_t; + /⋆ bits: descr. ⋆/ + /⋆ 15-13 audio coding mode (0=ac3, 2=mpeg1, 3=mpeg2ext, 4=LPCM, 6=DTS, ⋆/ + /⋆ 12 multichannel extension ⋆/ + /⋆ 11-10 audio type (0=not spec, 1=language included) ⋆/ + /⋆ 9- 8 audio application mode (0=not spec, 1=karaoke, 2=surround) ⋆/ + /⋆ 7- 6 Quantization / DRC (mpeg audio: 1=DRC exists)(lpcm: 0=16bit, ⋆/ + /⋆ 5- 4 Sample frequency fs (0=48kHz, 1=96kHz) ⋆/ + /⋆ 2- 0 number of audio channels (n+1 channels) ⋆/ +</programlisting> + </section></section> +<section id="audio_function_calls"> +<title>Audio Function Calls</title> + + +<section id="audio_fopen"> +<title>open()</title> +<para>DESCRIPTION +</para> +<informaltable><tgroup cols="1"><tbody><row><entry + align="char"> +<para>This system call opens a named audio device (e.g. /dev/dvb/adapter0/audio0) + for subsequent use. When an open() call has succeeded, the device will be ready + for use. The significance of blocking or non-blocking mode is described in the + documentation for functions where there is a difference. It does not affect the + semantics of the open() call itself. A device opened in blocking mode can later + be put into non-blocking mode (and vice versa) using the F_SETFL command + of the fcntl system call. This is a standard system call, documented in the Linux + manual page for fcntl. Only one user can open the Audio Device in O_RDWR + mode. All other attempts to open the device in this mode will fail, and an error + code will be returned. If the Audio Device is opened in O_RDONLY mode, the + only ioctl call that can be used is AUDIO_GET_STATUS. All other call will + return with an error code.</para> +</entry> + </row></tbody></tgroup></informaltable> +<para>SYNOPSIS +</para> +<informaltable><tgroup cols="1"><tbody><row><entry + align="char"> +<para>int open(const char ⋆deviceName, int flags);</para> +</entry> + </row></tbody></tgroup></informaltable> +<para>PARAMETERS +</para> +<informaltable><tgroup cols="2"><tbody><row><entry + align="char"> +<para>const char + *deviceName</para> +</entry><entry + align="char"> +<para>Name of specific audio device.</para> +</entry> + </row><row><entry + align="char"> +<para>int flags</para> +</entry><entry + align="char"> +<para>A bit-wise OR of the following flags:</para> +</entry> + </row><row><entry + align="char"> +</entry><entry + align="char"> +<para>O_RDONLY read-only access</para> +</entry> + </row><row><entry + align="char"> +</entry><entry + align="char"> +<para>O_RDWR read/write access</para> +</entry> + </row><row><entry + align="char"> +</entry><entry + align="char"> +<para>O_NONBLOCK open in non-blocking mode</para> +</entry> + </row><row><entry + align="char"> +</entry><entry + align="char"> +<para>(blocking mode is the default)</para> +</entry> + </row></tbody></tgroup></informaltable> +<para>ERRORS +</para> +<informaltable><tgroup cols="2"><tbody><row><entry + align="char"> +<para>ENODEV</para> +</entry><entry + align="char"> +<para>Device driver not loaded/available.</para> +</entry> + </row><row><entry + align="char"> +<para>EINTERNAL</para> +</entry><entry + align="char"> +<para>Internal error.</para> +</entry> + </row><row><entry + align="char"> +<para>EBUSY</para> +</entry><entry + align="char"> +<para>Device or resource busy.</para> +</entry> + </row><row><entry + align="char"> +<para>EINVAL</para> +</entry><entry + align="char"> +<para>Invalid argument.</para> +</entry> + </row></tbody></tgroup></informaltable> + +</section> +<section id="audio_fclose"> +<title>close()</title> +<para>DESCRIPTION +</para> +<informaltable><tgroup cols="1"><tbody><row><entry + align="char"> +<para>This system call closes a previously opened audio device.</para> +</entry> + </row></tbody></tgroup></informaltable> +<para>SYNOPSIS +</para> +<informaltable><tgroup cols="1"><tbody><row><entry + align="char"> +<para>int close(int fd);</para> +</entry> + </row></tbody></tgroup></informaltable> +<para>PARAMETERS +</para> +<informaltable><tgroup cols="2"><tbody><row><entry + align="char"> +<para>int fd</para> +</entry><entry + align="char"> +<para>File descriptor returned by a previous call to open().</para> +</entry> + </row></tbody></tgroup></informaltable> +<para>ERRORS +</para> +<informaltable><tgroup cols="2"><tbody><row><entry + align="char"> +<para>EBADF</para> +</entry><entry + align="char"> +<para>fd is not a valid open file descriptor.</para> +</entry> + </row></tbody></tgroup></informaltable> + +</section> +<section id="audio_fwrite"> +<title>write()</title> +<para>DESCRIPTION +</para> +<informaltable><tgroup cols="1"><tbody><row><entry + align="char"> +<para>This system call can only be used if AUDIO_SOURCE_MEMORY is selected + in the ioctl call AUDIO_SELECT_SOURCE. The data provided shall be in + PES format. If O_NONBLOCK is not specified the function will block until + buffer space is available. The amount of data to be transferred is implied by + count.</para> +</entry> + </row></tbody></tgroup></informaltable> +<para>SYNOPSIS +</para> +<informaltable><tgroup cols="1"><tbody><row><entry + align="char"> +<para>size_t write(int fd, const void ⋆buf, size_t count);</para> +</entry> + </row></tbody></tgroup></informaltable> +<para>PARAMETERS +</para> +<informaltable><tgroup cols="2"><tbody><row><entry + align="char"> +<para>int fd</para> +</entry><entry + align="char"> +<para>File descriptor returned by a previous call to open().</para> +</entry> + </row><row><entry + align="char"> +<para>void *buf</para> +</entry><entry + align="char"> +<para>Pointer to the buffer containing the PES data.</para> +</entry> + </row><row><entry + align="char"> +<para>size_t count</para> +</entry><entry + align="char"> +<para>Size of buf.</para> +</entry> + </row></tbody></tgroup></informaltable> +<para>ERRORS +</para> +<informaltable><tgroup cols="2"><tbody><row><entry + align="char"> +<para>EPERM</para> +</entry><entry + align="char"> +<para>Mode AUDIO_SOURCE_MEMORY not selected.</para> +</entry> + </row><row><entry + align="char"> +<para>ENOMEM</para> +</entry><entry + align="char"> +<para>Attempted to write more data than the internal buffer can + hold.</para> +</entry> + </row><row><entry + align="char"> +<para>EBADF</para> +</entry><entry + align="char"> +<para>fd is not a valid open file descriptor.</para> +</entry> + </row></tbody></tgroup></informaltable> + +</section><section +role="subsection"><title>AUDIO_STOP</title> +<para>DESCRIPTION +</para> +<informaltable><tgroup cols="1"><tbody><row><entry + align="char"> +<para>This ioctl call asks the Audio Device to stop playing the current stream.</para> +</entry> + </row></tbody></tgroup></informaltable> +<para>SYNOPSIS +</para> +<informaltable><tgroup cols="1"><tbody><row><entry + align="char"> +<para>int ioctl(int fd, int request = AUDIO_STOP);</para> +</entry> + </row></tbody></tgroup></informaltable> +<para>PARAMETERS +</para> +<informaltable><tgroup cols="2"><tbody><row><entry + align="char"> +<para>int fd</para> +</entry><entry + align="char"> +<para>File descriptor returned by a previous call to open().</para> +</entry> + </row><row><entry + align="char"> +<para>int request</para> +</entry><entry + align="char"> +<para>Equals AUDIO_STOP for this command.</para> +</entry> + </row></tbody></tgroup></informaltable> +<para>ERRORS +</para> +<informaltable><tgroup cols="2"><tbody><row><entry + align="char"> +<para>EBADF</para> +</entry><entry + align="char"> +<para>fd is not a valid open file descriptor</para> +</entry> + </row><row><entry + align="char"> +<para>EINTERNAL</para> +</entry><entry + align="char"> +<para>Internal error.</para> +</entry> + </row></tbody></tgroup></informaltable> + +</section><section +role="subsection"><title>AUDIO_PLAY</title> +<para>DESCRIPTION +</para> +<informaltable><tgroup cols="1"><tbody><row><entry + align="char"> +<para>This ioctl call asks the Audio Device to start playing an audio stream from the + selected source.</para> +</entry> + </row></tbody></tgroup></informaltable> +<para>SYNOPSIS +</para> +<informaltable><tgroup cols="1"><tbody><row><entry + align="char"> +<para>int ioctl(int fd, int request = AUDIO_PLAY);</para> +</entry> + </row></tbody></tgroup></informaltable> +<para>PARAMETERS +</para> +<informaltable><tgroup cols="2"><tbody><row><entry + align="char"> +<para>int fd</para> +</entry><entry + align="char"> +<para>File descriptor returned by a previous call to open().</para> +</entry> + </row><row><entry + align="char"> +<para>int request</para> +</entry><entry + align="char"> +<para>Equals AUDIO_PLAY for this command.</para> +</entry> + </row></tbody></tgroup></informaltable> +<para>ERRORS +</para> +<informaltable><tgroup cols="2"><tbody><row><entry + align="char"> +<para>EBADF</para> +</entry><entry + align="char"> +<para>fd is not a valid open file descriptor</para> +</entry> + </row><row><entry + align="char"> +<para>EINTERNAL</para> +</entry><entry + align="char"> +<para>Internal error.</para> +</entry> + </row></tbody></tgroup></informaltable> + +</section><section +role="subsection"><title>AUDIO_PAUSE</title> +<para>DESCRIPTION +</para> +<informaltable><tgroup cols="1"><tbody><row><entry + align="char"> +<para>This ioctl call suspends the audio stream being played. Decoding and playing + are paused. It is then possible to restart again decoding and playing process of + the audio stream using AUDIO_CONTINUE command.</para> +</entry> + </row><row><entry + align="char"> +<para>If AUDIO_SOURCE_MEMORY is selected in the ioctl call + AUDIO_SELECT_SOURCE, the DVB-subsystem will not decode (consume) + any more data until the ioctl call AUDIO_CONTINUE or AUDIO_PLAY is + performed.</para> +</entry> + </row></tbody></tgroup></informaltable> +<para>SYNOPSIS +</para> +<informaltable><tgroup cols="1"><tbody><row><entry + align="char"> +<para>int ioctl(int fd, int request = AUDIO_PAUSE);</para> +</entry> + </row></tbody></tgroup></informaltable> +<para>PARAMETERS +</para> +<informaltable><tgroup cols="2"><tbody><row><entry + align="char"> +<para>int fd</para> +</entry><entry + align="char"> +<para>File descriptor returned by a previous call to open().</para> +</entry> + </row><row><entry + align="char"> +<para>int request</para> +</entry><entry + align="char"> +<para>Equals AUDIO_PAUSE for this command.</para> +</entry> + </row></tbody></tgroup></informaltable> +<para>ERRORS +</para> +<informaltable><tgroup cols="2"><tbody><row><entry + align="char"> +<para>EBADF</para> +</entry><entry + align="char"> +<para>fd is not a valid open file descriptor.</para> +</entry> + </row><row><entry + align="char"> +<para>EINTERNAL</para> +</entry><entry + align="char"> +<para>Internal error.</para> +</entry> + </row></tbody></tgroup></informaltable> + +</section><section +role="subsection"><title>AUDIO_SELECT_SOURCE</title> +<para>DESCRIPTION +</para> +<informaltable><tgroup cols="1"><tbody><row><entry + align="char"> +<para>This ioctl call informs the audio device which source shall be used + for the input data. The possible sources are demux or memory. If + AUDIO_SOURCE_MEMORY is selected, the data is fed to the Audio Device + through the write command.</para> +</entry> + </row></tbody></tgroup></informaltable> +<para>SYNOPSIS +</para> +<informaltable><tgroup cols="1"><tbody><row><entry + align="char"> +<para>int ioctl(int fd, int request = AUDIO_SELECT_SOURCE, + audio_stream_source_t source);</para> +</entry> + </row></tbody></tgroup></informaltable> +<para>PARAMETERS +</para> +<informaltable><tgroup cols="2"><tbody><row><entry + align="char"> +<para>int fd</para> +</entry><entry + align="char"> +<para>File descriptor returned by a previous call to open().</para> +</entry> + </row><row><entry + align="char"> +<para>int request</para> +</entry><entry + align="char"> +<para>Equals AUDIO_SELECT_SOURCE for this command.</para> +</entry> + </row><row><entry + align="char"> +<para>audio_stream_source_t + source</para> +</entry><entry + align="char"> +<para>Indicates the source that shall be used for the Audio + stream.</para> +</entry> + </row></tbody></tgroup></informaltable> +<para>ERRORS +</para> +<informaltable><tgroup cols="2"><tbody><row><entry + align="char"> +<para>EBADF</para> +</entry><entry + align="char"> +<para>fd is not a valid open file descriptor.</para> +</entry> + </row><row><entry + align="char"> +<para>EINTERNAL</para> +</entry><entry + align="char"> +<para>Internal error.</para> +</entry> + </row><row><entry + align="char"> +<para>EINVAL</para> +</entry><entry + align="char"> +<para>Illegal input parameter.</para> +</entry> + </row></tbody></tgroup></informaltable> + +</section><section +role="subsection"><title>AUDIO_SET_MUTE</title> +<para>DESCRIPTION +</para> +<informaltable><tgroup cols="1"><tbody><row><entry + align="char"> +<para>This ioctl call asks the audio device to mute the stream that is currently being + played.</para> +</entry> + </row></tbody></tgroup></informaltable> +<para>SYNOPSIS +</para> +<informaltable><tgroup cols="1"><tbody><row><entry + align="char"> +<para>int ioctl(int fd, int request = AUDIO_SET_MUTE, + boolean state);</para> +</entry> + </row></tbody></tgroup></informaltable> +<para>PARAMETERS +</para> +<informaltable><tgroup cols="2"><tbody><row><entry + align="char"> +<para>int fd</para> +</entry><entry + align="char"> +<para>File descriptor returned by a previous call to open().</para> +</entry> + </row><row><entry + align="char"> +<para>int request</para> +</entry><entry + align="char"> +<para>Equals AUDIO_SET_MUTE for this command.</para> +</entry> + </row><row><entry + align="char"> +<para>boolean state</para> +</entry><entry + align="char"> +<para>Indicates if audio device shall mute or not.</para> +</entry> + </row><row><entry + align="char"> +</entry><entry + align="char"> +<para>TRUE Audio Mute</para> +</entry> + </row><row><entry + align="char"> +</entry><entry + align="char"> +<para>FALSE Audio Un-mute</para> +</entry> + </row></tbody></tgroup></informaltable> +<para>ERRORS +</para> +<informaltable><tgroup cols="2"><tbody><row><entry + align="char"> +<para>EBADF</para> +</entry><entry + align="char"> +<para>fd is not a valid open file descriptor.</para> +</entry> + </row><row><entry + align="char"> +<para>EINTERNAL</para> +</entry><entry + align="char"> +<para>Internal error.</para> +</entry> + </row><row><entry + align="char"> +<para>EINVAL</para> +</entry><entry + align="char"> +<para>Illegal input parameter.</para> +</entry> + </row></tbody></tgroup></informaltable> + +</section><section +role="subsection"><title>AUDIO_SET_AV_SYNC</title> +<para>DESCRIPTION +</para> +<informaltable><tgroup cols="1"><tbody><row><entry + align="char"> +<para>This ioctl call asks the Audio Device to turn ON or OFF A/V synchronization.</para> +</entry> + </row></tbody></tgroup></informaltable> +<para>SYNOPSIS +</para> +<informaltable><tgroup cols="1"><tbody><row><entry + align="char"> +<para>int ioctl(int fd, int request = AUDIO_SET_AV_SYNC, + boolean state);</para> +</entry> + </row></tbody></tgroup></informaltable> +<para>PARAMETERS +</para> +<informaltable><tgroup cols="2"><tbody><row><entry + align="char"> +<para>int fd</para> +</entry><entry + align="char"> +<para>File descriptor returned by a previous call to open().</para> +</entry> + </row><row><entry + align="char"> +<para>int request</para> +</entry><entry + align="char"> +<para>Equals AUDIO_AV_SYNC for this command.</para> +</entry> + </row><row><entry + align="char"> +<para>boolean state</para> +</entry><entry + align="char"> +<para>Tells the DVB subsystem if A/V synchronization shall be + ON or OFF.</para> +</entry> + </row><row><entry + align="char"> +</entry><entry + align="char"> +<para>TRUE AV-sync ON</para> +</entry> + </row><row><entry + align="char"> +</entry><entry + align="char"> +<para>FALSE AV-sync OFF</para> +</entry> + </row></tbody></tgroup></informaltable> +<para>ERRORS +</para> +<informaltable><tgroup cols="2"><tbody><row><entry + align="char"> +<para>EBADF</para> +</entry><entry + align="char"> +<para>fd is not a valid open file descriptor.</para> +</entry> + </row><row><entry + align="char"> +<para>EINTERNAL</para> +</entry><entry + align="char"> +<para>Internal error.</para> +</entry> + </row><row><entry + align="char"> +<para>EINVAL</para> +</entry><entry + align="char"> +<para>Illegal input parameter.</para> +</entry> + </row></tbody></tgroup></informaltable> + +</section><section +role="subsection"><title>AUDIO_SET_BYPASS_MODE</title> +<para>DESCRIPTION +</para> +<informaltable><tgroup cols="1"><tbody><row><entry + align="char"> +<para>This ioctl call asks the Audio Device to bypass the Audio decoder and forward + the stream without decoding. This mode shall be used if streams that can’t be + handled by the DVB system shall be decoded. Dolby DigitalTM streams are + automatically forwarded by the DVB subsystem if the hardware can handle it.</para> +</entry> + </row></tbody></tgroup></informaltable> +<para>SYNOPSIS +</para> +<informaltable><tgroup cols="1"><tbody><row><entry + align="char"> +<para>int ioctl(int fd, int request = + AUDIO_SET_BYPASS_MODE, boolean mode);</para> +</entry> + </row></tbody></tgroup></informaltable> +<para>PARAMETERS +</para> +<informaltable><tgroup cols="2"><tbody><row><entry + align="char"> +<para>int fd</para> +</entry><entry + align="char"> +<para>File descriptor returned by a previous call to open().</para> +</entry> + </row><row><entry + align="char"> +<para>int request</para> +</entry><entry + align="char"> +<para>Equals AUDIO_SET_BYPASS_MODE for this + command.</para> +</entry> + </row><row><entry + align="char"> +<para>boolean mode</para> +</entry><entry + align="char"> +<para>Enables or disables the decoding of the current Audio + stream in the DVB subsystem.</para> +</entry> + </row><row><entry + align="char"> +</entry><entry + align="char"> +<para>TRUE Bypass is disabled</para> +</entry> + </row><row><entry + align="char"> +</entry><entry + align="char"> +<para>FALSE Bypass is enabled</para> +</entry> + </row></tbody></tgroup></informaltable> +<para>ERRORS +</para> +<informaltable><tgroup cols="2"><tbody><row><entry + align="char"> +<para>EBADF</para> +</entry><entry + align="char"> +<para>fd is not a valid open file descriptor.</para> +</entry> + </row><row><entry + align="char"> +<para>EINTERNAL</para> +</entry><entry + align="char"> +<para>Internal error.</para> +</entry> + </row><row><entry + align="char"> +<para>EINVAL</para> +</entry><entry + align="char"> +<para>Illegal input parameter.</para> +</entry> + </row></tbody></tgroup></informaltable> + +</section><section +role="subsection"><title>AUDIO_CHANNEL_SELECT</title> +<para>DESCRIPTION +</para> +<informaltable><tgroup cols="1"><tbody><row><entry + align="char"> +<para>This ioctl call asks the Audio Device to select the requested channel if possible.</para> +</entry> + </row></tbody></tgroup></informaltable> +<para>SYNOPSIS +</para> +<informaltable><tgroup cols="1"><tbody><row><entry + align="char"> +<para>int ioctl(int fd, int request = + AUDIO_CHANNEL_SELECT, audio_channel_select_t);</para> +</entry> + </row></tbody></tgroup></informaltable> +<para>PARAMETERS +</para> +<informaltable><tgroup cols="2"><tbody><row><entry + align="char"> +<para>int fd</para> +</entry><entry + align="char"> +<para>File descriptor returned by a previous call to open().</para> +</entry> + </row><row><entry + align="char"> +<para>int request</para> +</entry><entry + align="char"> +<para>Equals AUDIO_CHANNEL_SELECT for this + command.</para> +</entry> + </row><row><entry + align="char"> +<para>audio_channel_select_t + ch</para> +</entry><entry + align="char"> +<para>Select the output format of the audio (mono left/right, + stereo).</para> +</entry> + </row></tbody></tgroup></informaltable> +<para>ERRORS +</para> +<informaltable><tgroup cols="2"><tbody><row><entry + align="char"> +<para>EBADF</para> +</entry><entry + align="char"> +<para>fd is not a valid open file descriptor.</para> +</entry> + </row><row><entry + align="char"> +<para>EINTERNAL</para> +</entry><entry + align="char"> +<para>Internal error.</para> +</entry> + </row><row><entry + align="char"> +<para>EINVAL</para> +</entry><entry + align="char"> +<para>Illegal input parameter ch.</para> +</entry> + </row></tbody></tgroup></informaltable> + +</section><section +role="subsection"><title>AUDIO_GET_STATUS</title> +<para>DESCRIPTION +</para> +<informaltable><tgroup cols="1"><tbody><row><entry + align="char"> +<para>This ioctl call asks the Audio Device to return the current state of the Audio + Device.</para> +</entry> + </row></tbody></tgroup></informaltable> +<para>SYNOPSIS +</para> +<informaltable><tgroup cols="1"><tbody><row><entry + align="char"> +<para>int ioctl(int fd, int request = AUDIO_GET_STATUS, + struct audio_status ⋆status);</para> +</entry> + </row></tbody></tgroup></informaltable> +<para>PARAMETERS +</para> +<informaltable><tgroup cols="2"><tbody><row><entry + align="char"> +<para>int fd</para> +</entry><entry + align="char"> +<para>File descriptor returned by a previous call to open().</para> +</entry> + </row><row><entry + align="char"> +<para>int request</para> +</entry><entry + align="char"> +<para>Equals AUDIO_GET_STATUS for this command.</para> +</entry> + </row><row><entry + align="char"> +<para>struct audio_status + *status</para> +</entry><entry + align="char"> +<para>Returns the current state of Audio Device.</para> +</entry> + </row></tbody></tgroup></informaltable> +<para>ERRORS +</para> +<informaltable><tgroup cols="2"><tbody><row><entry + align="char"> +<para>EBADF</para> +</entry><entry + align="char"> +<para>fd is not a valid open file descriptor.</para> +</entry> + </row><row><entry + align="char"> +<para>EINTERNAL</para> +</entry><entry + align="char"> +<para>Internal error.</para> +</entry> + </row><row><entry + align="char"> +<para>EFAULT</para> +</entry><entry + align="char"> +<para>status points to invalid address.</para> +</entry> + </row></tbody></tgroup></informaltable> + +</section><section +role="subsection"><title>AUDIO_GET_CAPABILITIES</title> +<para>DESCRIPTION +</para> +<informaltable><tgroup cols="1"><tbody><row><entry + align="char"> +<para>This ioctl call asks the Audio Device to tell us about the decoding capabilities + of the audio hardware.</para> +</entry> + </row></tbody></tgroup></informaltable> +<para>SYNOPSIS +</para> +<informaltable><tgroup cols="1"><tbody><row><entry + align="char"> +<para>int ioctl(int fd, int request = + AUDIO_GET_CAPABILITIES, unsigned int ⋆cap);</para> +</entry> + </row></tbody></tgroup></informaltable> +<para>PARAMETERS +</para> +<informaltable><tgroup cols="2"><tbody><row><entry + align="char"> +<para>int fd</para> +</entry><entry + align="char"> +<para>File descriptor returned by a previous call to open().</para> +</entry> + </row><row><entry + align="char"> +<para>int request</para> +</entry><entry + align="char"> +<para>Equals AUDIO_GET_CAPABILITIES for this + command.</para> +</entry> + </row><row><entry + align="char"> +<para>unsigned int *cap</para> +</entry><entry + align="char"> +<para>Returns a bit array of supported sound formats.</para> +</entry> + </row></tbody></tgroup></informaltable> +<para>ERRORS +</para> +<informaltable><tgroup cols="2"><tbody><row><entry + align="char"> +<para>EBADF</para> +</entry><entry + align="char"> +<para>fd is not a valid open file descriptor.</para> +</entry> + </row><row><entry + align="char"> +<para>EINTERNAL</para> +</entry><entry + align="char"> +<para>Internal error.</para> +</entry> + </row><row><entry + align="char"> +<para>EFAULT</para> +</entry><entry + align="char"> +<para>cap points to an invalid address.</para> +</entry> + </row></tbody></tgroup></informaltable> + +</section><section +role="subsection"><title>AUDIO_CLEAR_BUFFER</title> +<para>DESCRIPTION +</para> +<informaltable><tgroup cols="1"><tbody><row><entry + align="char"> +<para>This ioctl call asks the Audio Device to clear all software and hardware buffers + of the audio decoder device.</para> +</entry> + </row></tbody></tgroup></informaltable> +<para>SYNOPSIS +</para> +<informaltable><tgroup cols="1"><tbody><row><entry + align="char"> +<para>int ioctl(int fd, int request = AUDIO_CLEAR_BUFFER);</para> +</entry> + </row></tbody></tgroup></informaltable> +<para>PARAMETERS +</para> +<informaltable><tgroup cols="2"><tbody><row><entry + align="char"> +<para>int fd</para> +</entry><entry + align="char"> +<para>File descriptor returned by a previous call to open().</para> +</entry> + </row><row><entry + align="char"> +<para>int request</para> +</entry><entry + align="char"> +<para>Equals AUDIO_CLEAR_BUFFER for this command.</para> +</entry> + </row></tbody></tgroup></informaltable> +<para>ERRORS +</para> +<informaltable><tgroup cols="2"><tbody><row><entry + align="char"> +<para>EBADF</para> +</entry><entry + align="char"> +<para>fd is not a valid open file descriptor.</para> +</entry> + </row><row><entry + align="char"> +<para>EINTERNAL</para> +</entry><entry + align="char"> +<para>Internal error.</para> +</entry> + </row></tbody></tgroup></informaltable> + +</section><section +role="subsection"><title>AUDIO_SET_ID</title> +<para>DESCRIPTION +</para> +<informaltable><tgroup cols="1"><tbody><row><entry + align="char"> +<para>This ioctl selects which sub-stream is to be decoded if a program or system + stream is sent to the video device. If no audio stream type is set the id has to be + in [0xC0,0xDF] for MPEG sound, in [0x80,0x87] for AC3 and in [0xA0,0xA7] + for LPCM. More specifications may follow for other stream types. If the stream + type is set the id just specifies the substream id of the audio stream and only + the first 5 bits are recognized.</para> +</entry> + </row></tbody></tgroup></informaltable> +<para>SYNOPSIS +</para> +<informaltable><tgroup cols="1"><tbody><row><entry + align="char"> +<para>int ioctl(int fd, int request = AUDIO_SET_ID, int + id);</para> +</entry> + </row></tbody></tgroup></informaltable> +<para>PARAMETERS +</para> +<informaltable><tgroup cols="2"><tbody><row><entry + align="char"> +<para>int fd</para> +</entry><entry + align="char"> +<para>File descriptor returned by a previous call to open().</para> +</entry> + </row><row><entry + align="char"> +<para>int request</para> +</entry><entry + align="char"> +<para>Equals AUDIO_SET_ID for this command.</para> +</entry> + </row><row><entry + align="char"> +<para>int id</para> +</entry><entry + align="char"> +<para>audio sub-stream id</para> +</entry> + </row></tbody></tgroup></informaltable> +<para>ERRORS +</para> +<informaltable><tgroup cols="2"><tbody><row><entry + align="char"> +<para>EBADF</para> +</entry><entry + align="char"> +<para>fd is not a valid open file descriptor.</para> +</entry> + </row><row><entry + align="char"> +<para>EINTERNAL</para> +</entry><entry + align="char"> +<para>Internal error.</para> +</entry> + </row><row><entry + align="char"> +<para>EINVAL</para> +</entry><entry + align="char"> +<para>Invalid sub-stream id.</para> +</entry> + </row></tbody></tgroup></informaltable> + +</section><section +role="subsection"><title>AUDIO_SET_MIXER</title> +<para>DESCRIPTION +</para> +<informaltable><tgroup cols="1"><tbody><row><entry + align="char"> +<para>This ioctl lets you adjust the mixer settings of the audio decoder.</para> +</entry> + </row></tbody></tgroup></informaltable> +<para>SYNOPSIS +</para> +<informaltable><tgroup cols="1"><tbody><row><entry + align="char"> +<para>int ioctl(int fd, int request = AUDIO_SET_MIXER, + audio_mixer_t ⋆mix);</para> +</entry> + </row></tbody></tgroup></informaltable> +<para>PARAMETERS +</para> +<informaltable><tgroup cols="2"><tbody><row><entry + align="char"> +<para>int fd</para> +</entry><entry + align="char"> +<para>File descriptor returned by a previous call to open().</para> +</entry> + </row><row><entry + align="char"> +<para>int request</para> +</entry><entry + align="char"> +<para>Equals AUDIO_SET_ID for this command.</para> +</entry> + </row><row><entry + align="char"> +<para>audio_mixer_t *mix</para> +</entry><entry + align="char"> +<para>mixer settings.</para> +</entry> + </row></tbody></tgroup></informaltable> +<para>ERRORS +</para> +<informaltable><tgroup cols="2"><tbody><row><entry + align="char"> +<para>EBADF</para> +</entry><entry + align="char"> +<para>fd is not a valid open file descriptor.</para> +</entry> + </row><row><entry + align="char"> +<para>EINTERNAL</para> +</entry><entry + align="char"> +<para>Internal error.</para> +</entry> + </row><row><entry + align="char"> +<para>EFAULT</para> +</entry><entry + align="char"> +<para>mix points to an invalid address.</para> +</entry> + </row></tbody></tgroup></informaltable> + +</section><section +role="subsection"><title>AUDIO_SET_STREAMTYPE</title> +<para>DESCRIPTION +</para> +<informaltable><tgroup cols="1"><tbody><row><entry + align="char"> +<para>This ioctl tells the driver which kind of audio stream to expect. This is useful + if the stream offers several audio sub-streams like LPCM and AC3.</para> +</entry> + </row></tbody></tgroup></informaltable> +<para>SYNOPSIS +</para> +<informaltable><tgroup cols="1"><tbody><row><entry + align="char"> +<para>int ioctl(fd, int request = AUDIO_SET_STREAMTYPE, + int type);</para> +</entry> + </row></tbody></tgroup></informaltable> +<para>PARAMETERS +</para> +<informaltable><tgroup cols="2"><tbody><row><entry + align="char"> +<para>int fd</para> +</entry><entry + align="char"> +<para>File descriptor returned by a previous call to open().</para> +</entry> + </row><row><entry + align="char"> +<para>int request</para> +</entry><entry + align="char"> +<para>Equals AUDIO_SET_STREAMTYPE for this + command.</para> +</entry> + </row><row><entry + align="char"> +<para>int type</para> +</entry><entry + align="char"> +<para>stream type</para> +</entry> + </row></tbody></tgroup></informaltable> +<para>ERRORS +</para> +<informaltable><tgroup cols="2"><tbody><row><entry + align="char"> +<para>EBADF</para> +</entry><entry + align="char"> +<para>fd is not a valid open file descriptor</para> +</entry> + </row><row><entry + align="char"> +<para>EINVAL</para> +</entry><entry + align="char"> +<para>type is not a valid or supported stream type.</para> +</entry> + </row></tbody></tgroup></informaltable> + +</section><section +role="subsection"><title>AUDIO_SET_EXT_ID</title> +<para>DESCRIPTION +</para> +<informaltable><tgroup cols="1"><tbody><row><entry + align="char"> +<para>This ioctl can be used to set the extension id for MPEG streams in DVD + playback. Only the first 3 bits are recognized.</para> +</entry> + </row></tbody></tgroup></informaltable> +<para>SYNOPSIS +</para> +<informaltable><tgroup cols="1"><tbody><row><entry + align="char"> +<para>int ioctl(fd, int request = AUDIO_SET_EXT_ID, int + id);</para> +</entry> + </row></tbody></tgroup></informaltable> +<para>PARAMETERS +</para> +<informaltable><tgroup cols="2"><tbody><row><entry + align="char"> +<para>int fd</para> +</entry><entry + align="char"> +<para>File descriptor returned by a previous call to open().</para> +</entry> + </row><row><entry + align="char"> +<para>int request</para> +</entry><entry + align="char"> +<para>Equals AUDIO_SET_EXT_ID for this command.</para> +</entry> + </row><row><entry + align="char"> +<para>int id</para> +</entry><entry + align="char"> +<para>audio sub_stream_id</para> +</entry> + </row></tbody></tgroup></informaltable> +<para>ERRORS +</para> +<informaltable><tgroup cols="2"><tbody><row><entry + align="char"> +<para>EBADF</para> +</entry><entry + align="char"> +<para>fd is not a valid open file descriptor</para> +</entry> + </row><row><entry + align="char"> +<para>EINVAL</para> +</entry><entry + align="char"> +<para>id is not a valid id.</para> +</entry> + </row></tbody></tgroup></informaltable> + +</section><section +role="subsection"><title>AUDIO_SET_ATTRIBUTES</title> +<para>DESCRIPTION +</para> +<informaltable><tgroup cols="1"><tbody><row><entry + align="char"> +<para>This ioctl is intended for DVD playback and allows you to set certain + information about the audio stream.</para> +</entry> + </row></tbody></tgroup></informaltable> +<para>SYNOPSIS +</para> +<informaltable><tgroup cols="1"><tbody><row><entry + align="char"> +<para>int ioctl(fd, int request = AUDIO_SET_ATTRIBUTES, + audio_attributes_t attr );</para> +</entry> + </row></tbody></tgroup></informaltable> +<para>PARAMETERS +</para> +<informaltable><tgroup cols="2"><tbody><row><entry + align="char"> +<para>int fd</para> +</entry><entry + align="char"> +<para>File descriptor returned by a previous call to open().</para> +</entry> + </row><row><entry + align="char"> +<para>int request</para> +</entry><entry + align="char"> +<para>Equals AUDIO_SET_ATTRIBUTES for this command.</para> +</entry> + </row><row><entry + align="char"> +<para>audio_attributes_t + attr</para> +</entry><entry + align="char"> +<para>audio attributes according to section ??</para> +</entry> + </row></tbody></tgroup></informaltable> +<para>ERRORS +</para> +<informaltable><tgroup cols="2"><tbody><row><entry + align="char"> +<para>EBADF</para> +</entry><entry + align="char"> +<para>fd is not a valid open file descriptor</para> +</entry> + </row><row><entry + align="char"> +<para>EINVAL</para> +</entry><entry + align="char"> +<para>attr is not a valid or supported attribute setting.</para> +</entry> + </row></tbody></tgroup></informaltable> + +</section><section +role="subsection"><title>AUDIO_SET_KARAOKE</title> +<para>DESCRIPTION +</para> +<informaltable><tgroup cols="1"><tbody><row><entry + align="char"> +<para>This ioctl allows one to set the mixer settings for a karaoke DVD.</para> +</entry> + </row></tbody></tgroup></informaltable> +<para>SYNOPSIS +</para> +<informaltable><tgroup cols="1"><tbody><row><entry + align="char"> +<para>int ioctl(fd, int request = AUDIO_SET_STREAMTYPE, + audio_karaoke_t ⋆karaoke);</para> +</entry> + </row></tbody></tgroup></informaltable> +<para>PARAMETERS +</para> +<informaltable><tgroup cols="2"><tbody><row><entry + align="char"> +<para>int fd</para> +</entry><entry + align="char"> +<para>File descriptor returned by a previous call to open().</para> +</entry> + </row><row><entry + align="char"> +<para>int request</para> +</entry><entry + align="char"> +<para>Equals AUDIO_SET_STREAMTYPE for this + command.</para> +</entry> + </row><row><entry + align="char"> +<para>audio_karaoke_t + *karaoke</para> +</entry><entry + align="char"> +<para>karaoke settings according to section ??.</para> +</entry> + </row></tbody></tgroup></informaltable> +<para>ERRORS +</para> +<informaltable><tgroup cols="2"><tbody><row><entry + align="char"> +<para>EBADF</para> +</entry><entry + align="char"> +<para>fd is not a valid open file descriptor</para> +</entry> + </row><row><entry + align="char"> +<para>EINVAL</para> +</entry><entry + align="char"> +<para>karaoke is not a valid or supported karaoke setting.</para> +</entry> + </row></tbody></tgroup></informaltable> + </section> +</section> diff --git a/Documentation/DocBook/dvb/ca.xml b/Documentation/DocBook/dvb/ca.xml new file mode 100644 index 000000000000..b1f1d2fad654 --- /dev/null +++ b/Documentation/DocBook/dvb/ca.xml @@ -0,0 +1,221 @@ +<title>DVB CA Device</title> +<para>The DVB CA device controls the conditional access hardware. It can be accessed through +<emphasis role="tt">/dev/dvb/adapter0/ca0</emphasis>. Data types and and ioctl definitions can be accessed by +including <emphasis role="tt">linux/dvb/ca.h</emphasis> in your application. +</para> + +<section id="ca_data_types"> +<title>CA Data Types</title> + + +<section id="ca_slot_info_t"> +<title>ca_slot_info_t</title> + <programlisting> + /⋆ slot interface types and info ⋆/ + + typedef struct ca_slot_info_s { + int num; /⋆ slot number ⋆/ + + int type; /⋆ CA interface this slot supports ⋆/ + #define CA_CI 1 /⋆ CI high level interface ⋆/ + #define CA_CI_LINK 2 /⋆ CI link layer level interface ⋆/ + #define CA_CI_PHYS 4 /⋆ CI physical layer level interface ⋆/ + #define CA_SC 128 /⋆ simple smart card interface ⋆/ + + unsigned int flags; + #define CA_CI_MODULE_PRESENT 1 /⋆ module (or card) inserted ⋆/ + #define CA_CI_MODULE_READY 2 + } ca_slot_info_t; +</programlisting> + +</section> +<section id="ca_descr_info_t"> +<title>ca_descr_info_t</title> + <programlisting> + typedef struct ca_descr_info_s { + unsigned int num; /⋆ number of available descramblers (keys) ⋆/ + unsigned int type; /⋆ type of supported scrambling system ⋆/ + #define CA_ECD 1 + #define CA_NDS 2 + #define CA_DSS 4 + } ca_descr_info_t; +</programlisting> + +</section> +<section id="ca_cap_t"> +<title>ca_cap_t</title> + <programlisting> + typedef struct ca_cap_s { + unsigned int slot_num; /⋆ total number of CA card and module slots ⋆/ + unsigned int slot_type; /⋆ OR of all supported types ⋆/ + unsigned int descr_num; /⋆ total number of descrambler slots (keys) ⋆/ + unsigned int descr_type;/⋆ OR of all supported types ⋆/ + } ca_cap_t; +</programlisting> + +</section> +<section id="ca_msg_t"> +<title>ca_msg_t</title> + <programlisting> + /⋆ a message to/from a CI-CAM ⋆/ + typedef struct ca_msg_s { + unsigned int index; + unsigned int type; + unsigned int length; + unsigned char msg[256]; + } ca_msg_t; +</programlisting> + +</section> +<section id="ca_descr_t"> +<title>ca_descr_t</title> + <programlisting> + typedef struct ca_descr_s { + unsigned int index; + unsigned int parity; + unsigned char cw[8]; + } ca_descr_t; +</programlisting> + </section></section> +<section id="ca_function_calls"> +<title>CA Function Calls</title> + + +<section id="ca_fopen"> +<title>open()</title> +<para>DESCRIPTION +</para> +<informaltable><tgroup cols="1"><tbody><row><entry + align="char"> +<para>This system call opens a named ca device (e.g. /dev/ost/ca) for subsequent use.</para> +<para>When an open() call has succeeded, the device will be ready for use. + The significance of blocking or non-blocking mode is described in the + documentation for functions where there is a difference. It does not affect the + semantics of the open() call itself. A device opened in blocking mode can later + be put into non-blocking mode (and vice versa) using the F_SETFL command + of the fcntl system call. This is a standard system call, documented in the Linux + manual page for fcntl. Only one user can open the CA Device in O_RDWR + mode. All other attempts to open the device in this mode will fail, and an error + code will be returned.</para> +</entry> + </row></tbody></tgroup></informaltable> +<para>SYNOPSIS +</para> +<informaltable><tgroup cols="1"><tbody><row><entry + align="char"> +<para>int open(const char ⋆deviceName, int flags);</para> +</entry> + </row></tbody></tgroup></informaltable> +<para>PARAMETERS +</para> +<informaltable><tgroup cols="2"><tbody><row><entry + align="char"> +<para>const char + *deviceName</para> +</entry><entry + align="char"> +<para>Name of specific video device.</para> +</entry> + </row><row><entry + align="char"> +<para>int flags</para> +</entry><entry + align="char"> +<para>A bit-wise OR of the following flags:</para> +</entry> + </row><row><entry + align="char"> +</entry><entry + align="char"> +<para>O_RDONLY read-only access</para> +</entry> + </row><row><entry + align="char"> +</entry><entry + align="char"> +<para>O_RDWR read/write access</para> +</entry> + </row><row><entry + align="char"> +</entry><entry + align="char"> +<para>O_NONBLOCK open in non-blocking mode</para> +</entry> + </row><row><entry + align="char"> +</entry><entry + align="char"> +<para>(blocking mode is the default)</para> +</entry> + </row></tbody></tgroup></informaltable> +<para>ERRORS +</para> +<informaltable><tgroup cols="2"><tbody><row><entry + align="char"> +<para>ENODEV</para> +</entry><entry + align="char"> +<para>Device driver not loaded/available.</para> +</entry> + </row><row><entry + align="char"> +<para>EINTERNAL</para> +</entry><entry + align="char"> +<para>Internal error.</para> +</entry> + </row><row><entry + align="char"> +<para>EBUSY</para> +</entry><entry + align="char"> +<para>Device or resource busy.</para> +</entry> + </row><row><entry + align="char"> +<para>EINVAL</para> +</entry><entry + align="char"> +<para>Invalid argument.</para> +</entry> + </row></tbody></tgroup></informaltable> + +</section> +<section id="ca_fclose"> +<title>close()</title> +<para>DESCRIPTION +</para> +<informaltable><tgroup cols="1"><tbody><row><entry + align="char"> +<para>This system call closes a previously opened audio device.</para> +</entry> + </row></tbody></tgroup></informaltable> +<para>SYNOPSIS +</para> +<informaltable><tgroup cols="1"><tbody><row><entry + align="char"> +<para>int close(int fd);</para> +</entry> + </row></tbody></tgroup></informaltable> +<para>PARAMETERS +</para> +<informaltable><tgroup cols="2"><tbody><row><entry + align="char"> +<para>int fd</para> +</entry><entry + align="char"> +<para>File descriptor returned by a previous call to open().</para> +</entry> + </row></tbody></tgroup></informaltable> +<para>ERRORS +</para> +<informaltable><tgroup cols="2"><tbody><row><entry + align="char"> +<para>EBADF</para> +</entry><entry + align="char"> +<para>fd is not a valid open file descriptor.</para> +</entry> + </row></tbody></tgroup></informaltable> + </section> +</section> diff --git a/Documentation/DocBook/dvb/demux.xml b/Documentation/DocBook/dvb/demux.xml new file mode 100644 index 000000000000..1b8c4e9835b9 --- /dev/null +++ b/Documentation/DocBook/dvb/demux.xml @@ -0,0 +1,973 @@ +<title>DVB Demux Device</title> + +<para>The DVB demux device controls the filters of the DVB hardware/software. It can be +accessed through <emphasis role="tt">/dev/adapter0/demux0</emphasis>. Data types and and ioctl definitions can be +accessed by including <emphasis role="tt">linux/dvb/dmx.h</emphasis> in your application. +</para> +<section id="dmx_types"> +<title>Demux Data Types</title> + +<section id="dmx_output_t"> +<title>dmx_output_t</title> + <programlisting> + typedef enum + { + DMX_OUT_DECODER, + DMX_OUT_TAP, + DMX_OUT_TS_TAP + } dmx_output_t; +</programlisting> +<para><emphasis role="tt">DMX_OUT_TAP</emphasis> delivers the stream output to the demux device on which the ioctl is +called. +</para> +<para><emphasis role="tt">DMX_OUT_TS_TAP</emphasis> routes output to the logical DVR device <emphasis role="tt">/dev/dvb/adapter0/dvr0</emphasis>, +which delivers a TS multiplexed from all filters for which <emphasis role="tt">DMX_OUT_TS_TAP</emphasis> was +specified. +</para> +</section> + +<section id="dmx_input_t"> +<title>dmx_input_t</title> + <programlisting> + typedef enum + { + DMX_IN_FRONTEND, + DMX_IN_DVR + } dmx_input_t; +</programlisting> +</section> + +<section id="dmx_pes_type_t"> +<title>dmx_pes_type_t</title> + <programlisting> + typedef enum + { + DMX_PES_AUDIO, + DMX_PES_VIDEO, + DMX_PES_TELETEXT, + DMX_PES_SUBTITLE, + DMX_PES_PCR, + DMX_PES_OTHER + } dmx_pes_type_t; +</programlisting> +</section> + +<section id="dmx_event_t"> +<title>dmx_event_t</title> + <programlisting> + typedef enum + { + DMX_SCRAMBLING_EV, + DMX_FRONTEND_EV + } dmx_event_t; +</programlisting> +</section> + +<section id="dmx_scrambling_status_t"> +<title>dmx_scrambling_status_t</title> + <programlisting> + typedef enum + { + DMX_SCRAMBLING_OFF, + DMX_SCRAMBLING_ON + } dmx_scrambling_status_t; +</programlisting> +</section> + +<section id="dmx_filter"> +<title>struct dmx_filter</title> + <programlisting> + typedef struct dmx_filter + { + uint8_t filter[DMX_FILTER_SIZE]; + uint8_t mask[DMX_FILTER_SIZE]; + } dmx_filter_t; +</programlisting> +</section> + +<section id="dmx_sct_filter_params"> +<title>struct dmx_sct_filter_params</title> + <programlisting> + struct dmx_sct_filter_params + { + uint16_t pid; + dmx_filter_t filter; + uint32_t timeout; + uint32_t flags; + #define DMX_CHECK_CRC 1 + #define DMX_ONESHOT 2 + #define DMX_IMMEDIATE_START 4 + }; +</programlisting> +</section> + +<section id="dmx_pes_filter_params"> +<title>struct dmx_pes_filter_params</title> + <programlisting> + struct dmx_pes_filter_params + { + uint16_t pid; + dmx_input_t input; + dmx_output_t output; + dmx_pes_type_t pes_type; + uint32_t flags; + }; +</programlisting> +</section> + +<section id="dmx_event"> +<title>struct dmx_event</title> + <programlisting> + struct dmx_event + { + dmx_event_t event; + time_t timeStamp; + union + { + dmx_scrambling_status_t scrambling; + } u; + }; +</programlisting> +</section> + +<section id="dmx_stc"> +<title>struct dmx_stc</title> + <programlisting> + struct dmx_stc { + unsigned int num; /⋆ input : which STC? 0..N ⋆/ + unsigned int base; /⋆ output: divisor for stc to get 90 kHz clock ⋆/ + uint64_t stc; /⋆ output: stc in 'base'⋆90 kHz units ⋆/ + }; +</programlisting> + </section> + +</section> + +<section id="dmx_fcalls"> +<title>Demux Function Calls</title> + +<section id="dmx_fopen"> +<title>open()</title> +<para>DESCRIPTION +</para> +<informaltable><tgroup cols="1"><tbody><row><entry + align="char"> +<para>This system call, used with a device name of /dev/dvb/adapter0/demux0, + allocates a new filter and returns a handle which can be used for subsequent + control of that filter. This call has to be made for each filter to be used, i.e. every + returned file descriptor is a reference to a single filter. /dev/dvb/adapter0/dvr0 + is a logical device to be used for retrieving Transport Streams for digital + video recording. When reading from this device a transport stream containing + the packets from all PES filters set in the corresponding demux device + (/dev/dvb/adapter0/demux0) having the output set to DMX_OUT_TS_TAP. A + recorded Transport Stream is replayed by writing to this device. </para> +<para>The significance of blocking or non-blocking mode is described in the + documentation for functions where there is a difference. It does not affect the + semantics of the open() call itself. A device opened in blocking mode can later + be put into non-blocking mode (and vice versa) using the F_SETFL command + of the fcntl system call.</para> +</entry> + </row></tbody></tgroup></informaltable> +<para>SYNOPSIS +</para> +<informaltable><tgroup cols="1"><tbody><row><entry + align="char"> +<para>int open(const char ⋆deviceName, int flags);</para> +</entry> + </row></tbody></tgroup></informaltable> +<para>PARAMETERS +</para> +<informaltable><tgroup cols="2"><tbody><row><entry + align="char"> +<para>const char + *deviceName</para> +</entry><entry + align="char"> +<para>Name of demux device.</para> +</entry> + </row><row><entry + align="char"> +<para>int flags</para> +</entry><entry + align="char"> +<para>A bit-wise OR of the following flags:</para> +</entry> + </row><row><entry + align="char"> +</entry><entry + align="char"> +<para>O_RDWR read/write access</para> +</entry> + </row><row><entry + align="char"> +</entry><entry + align="char"> +<para>O_NONBLOCK open in non-blocking mode</para> +</entry> + </row><row><entry + align="char"> +</entry><entry + align="char"> +<para>(blocking mode is the default)</para> +</entry> + </row></tbody></tgroup></informaltable> +<para>ERRORS +</para> +<informaltable><tgroup cols="2"><tbody><row><entry + align="char"> +<para>ENODEV</para> +</entry><entry + align="char"> +<para>Device driver not loaded/available.</para> +</entry> + </row><row><entry + align="char"> +<para>EINVAL</para> +</entry><entry + align="char"> +<para>Invalid argument.</para> +</entry> + </row><row><entry + align="char"> +<para>EMFILE</para> +</entry><entry + align="char"> +<para>“Too many open files”, i.e. no more filters available.</para> +</entry> + </row><row><entry + align="char"> +<para>ENOMEM</para> +</entry><entry + align="char"> +<para>The driver failed to allocate enough memory.</para> +</entry> + </row></tbody></tgroup></informaltable> +</section> + +<section id="dmx_fclose"> +<title>close()</title> +<para>DESCRIPTION +</para> +<informaltable><tgroup cols="1"><tbody><row><entry + align="char"> +<para>This system call deactivates and deallocates a filter that was previously + allocated via the open() call.</para> +</entry> + </row></tbody></tgroup></informaltable> +<para>SYNOPSIS +</para> +<informaltable><tgroup cols="1"><tbody><row><entry + align="char"> +<para>int close(int fd);</para> +</entry> + </row></tbody></tgroup></informaltable> +<para>PARAMETERS +</para> +<informaltable><tgroup cols="2"><tbody><row><entry + align="char"> +<para>int fd</para> +</entry><entry + align="char"> +<para>File descriptor returned by a previous call to open().</para> +</entry> + </row></tbody></tgroup></informaltable> +<para>ERRORS +</para> +<informaltable><tgroup cols="2"><tbody><row><entry + align="char"> +<para>EBADF</para> +</entry><entry + align="char"> +<para>fd is not a valid open file descriptor.</para> +</entry> + </row></tbody></tgroup></informaltable> +</section> + +<section id="dmx_fread"> +<title>read()</title> +<para>DESCRIPTION +</para> +<informaltable><tgroup cols="1"><tbody><row><entry + align="char"> +<para>This system call returns filtered data, which might be section or PES data. The + filtered data is transferred from the driver’s internal circular buffer to buf. The + maximum amount of data to be transferred is implied by count.</para> +</entry> + </row><row><entry + align="char"> +<para>When returning section data the driver always tries to return a complete single + section (even though buf would provide buffer space for more data). If the size + of the buffer is smaller than the section as much as possible will be returned, + and the remaining data will be provided in subsequent calls.</para> +</entry> + </row><row><entry + align="char"> +<para>The size of the internal buffer is 2 * 4096 bytes (the size of two maximum + sized sections) by default. The size of this buffer may be changed by using the + DMX_SET_BUFFER_SIZE function. If the buffer is not large enough, or if + the read operations are not performed fast enough, this may result in a buffer + overflow error. In this case EOVERFLOW will be returned, and the circular + buffer will be emptied. This call is blocking if there is no data to return, i.e. the + process will be put to sleep waiting for data, unless the O_NONBLOCK flag + is specified.</para> +</entry> + </row><row><entry + align="char"> +<para>Note that in order to be able to read, the filtering process has to be started + by defining either a section or a PES filter by means of the ioctl functions, + and then starting the filtering process via the DMX_START ioctl function + or by setting the DMX_IMMEDIATE_START flag. If the reading is done + from a logical DVR demux device, the data will constitute a Transport Stream + including the packets from all PES filters in the corresponding demux device + /dev/dvb/adapter0/demux0 having the output set to DMX_OUT_TS_TAP.</para> +</entry> + </row></tbody></tgroup></informaltable> +<para>SYNOPSIS +</para> +<informaltable><tgroup cols="1"><tbody><row><entry + align="char"> +<para>size_t read(int fd, void ⋆buf, size_t count);</para> +</entry> + </row></tbody></tgroup></informaltable> +<para>PARAMETERS +</para> +<informaltable><tgroup cols="2"><tbody><row><entry + align="char"> +<para>int fd</para> +</entry><entry + align="char"> +<para>File descriptor returned by a previous call to open().</para> +</entry> + </row><row><entry + align="char"> +<para>void *buf</para> +</entry><entry + align="char"> +<para>Pointer to the buffer to be used for returned filtered data.</para> +</entry> + </row><row><entry + align="char"> +<para>size_t count</para> +</entry><entry + align="char"> +<para>Size of buf.</para> +</entry> + </row></tbody></tgroup></informaltable> +<para>ERRORS +</para> +<informaltable><tgroup cols="2"><tbody><row><entry + align="char"> +<para>EWOULDBLOCK</para> +</entry><entry + align="char"> +<para>No data to return and O_NONBLOCK was specified.</para> +</entry> + </row><row><entry + align="char"> +<para>EBADF</para> +</entry><entry + align="char"> +<para>fd is not a valid open file descriptor.</para> +</entry> + </row><row><entry + align="char"> +<para>ECRC</para> +</entry><entry + align="char"> +<para>Last section had a CRC error - no data returned. The + buffer is flushed.</para> +</entry> + </row><row><entry + align="char"> +<para>EOVERFLOW</para> +</entry><entry + align="char"> +</entry> + </row><row><entry + align="char"> +</entry><entry + align="char"> +<para>The filtered data was not read from the buffer in due + time, resulting in non-read data being lost. The buffer is + flushed.</para> +</entry> + </row><row><entry + align="char"> +<para>ETIMEDOUT</para> +</entry><entry + align="char"> +<para>The section was not loaded within the stated timeout + period. See ioctl DMX_SET_FILTER for how to set a + timeout.</para> +</entry> + </row><row><entry + align="char"> +<para>EFAULT</para> +</entry><entry + align="char"> +<para>The driver failed to write to the callers buffer due to an + invalid *buf pointer.</para> +</entry> + </row></tbody></tgroup></informaltable> +</section> + +<section id="dmx_fwrite"> +<title>write()</title> +<para>DESCRIPTION +</para> +<informaltable><tgroup cols="1"><tbody><row><entry + align="char"> +<para>This system call is only provided by the logical device /dev/dvb/adapter0/dvr0, + associated with the physical demux device that provides the actual DVR + functionality. It is used for replay of a digitally recorded Transport Stream. + Matching filters have to be defined in the corresponding physical demux + device, /dev/dvb/adapter0/demux0. The amount of data to be transferred is + implied by count.</para> +</entry> + </row></tbody></tgroup></informaltable> +<para>SYNOPSIS +</para> +<informaltable><tgroup cols="1"><tbody><row><entry + align="char"> +<para>ssize_t write(int fd, const void ⋆buf, size_t + count);</para> +</entry> + </row></tbody></tgroup></informaltable> +<para>PARAMETERS +</para> +<informaltable><tgroup cols="2"><tbody><row><entry + align="char"> +<para>int fd</para> +</entry><entry + align="char"> +<para>File descriptor returned by a previous call to open().</para> +</entry> + </row><row><entry + align="char"> +<para>void *buf</para> +</entry><entry + align="char"> +<para>Pointer to the buffer containing the Transport Stream.</para> +</entry> + </row><row><entry + align="char"> +<para>size_t count</para> +</entry><entry + align="char"> +<para>Size of buf.</para> +</entry> + </row></tbody></tgroup></informaltable> +<para>ERRORS +</para> +<informaltable><tgroup cols="2"><tbody><row><entry + align="char"> +<para>EWOULDBLOCK</para> +</entry><entry + align="char"> +<para>No data was written. This + might happen if O_NONBLOCK was specified and there + is no more buffer space available (if O_NONBLOCK is + not specified the function will block until buffer space is + available).</para> +</entry> + </row><row><entry + align="char"> +<para>EBUSY</para> +</entry><entry + align="char"> +<para>This error code indicates that there are conflicting + requests. The corresponding demux device is setup to + receive data from the front- end. Make sure that these + filters are stopped and that the filters with input set to + DMX_IN_DVR are started.</para> +</entry> + </row><row><entry + align="char"> +<para>EBADF</para> +</entry><entry + align="char"> +<para>fd is not a valid open file descriptor.</para> +</entry> + </row></tbody></tgroup></informaltable> +</section> + +<section id="dmx_start"> +<title>DMX_START</title> +<para>DESCRIPTION +</para> +<informaltable><tgroup cols="1"><tbody><row><entry + align="char"> +<para>This ioctl call is used to start the actual filtering operation defined via the ioctl + calls DMX_SET_FILTER or DMX_SET_PES_FILTER.</para> +</entry> + </row></tbody></tgroup></informaltable> +<para>SYNOPSIS +</para> +<informaltable><tgroup cols="1"><tbody><row><entry + align="char"> +<para>int ioctl( int fd, int request = DMX_START);</para> +</entry> + </row></tbody></tgroup></informaltable> +<para>PARAMETERS +</para> +<informaltable><tgroup cols="2"><tbody><row><entry + align="char"> +<para>int fd</para> +</entry><entry + align="char"> +<para>File descriptor returned by a previous call to open().</para> +</entry> + </row><row><entry + align="char"> +<para>int request</para> +</entry><entry + align="char"> +<para>Equals DMX_START for this command.</para> +</entry> + </row></tbody></tgroup></informaltable> +<para>ERRORS +</para> +<informaltable><tgroup cols="2"><tbody><row><entry + align="char"> +<para>EBADF</para> +</entry><entry + align="char"> +<para>fd is not a valid file descriptor.</para> +</entry> + </row><row><entry + align="char"> +<para>EINVAL</para> +</entry><entry + align="char"> +<para>Invalid argument, i.e. no filtering parameters provided via + the DMX_SET_FILTER or DMX_SET_PES_FILTER + functions.</para> +</entry> + </row><row><entry + align="char"> +<para>EBUSY</para> +</entry><entry + align="char"> +<para>This error code indicates that there are conflicting + requests. There are active filters filtering data from + another input source. Make sure that these filters are + stopped before starting this filter.</para> +</entry> + </row></tbody></tgroup></informaltable> +</section> + +<section id="dmx_stop"> +<title>DMX_STOP</title> +<para>DESCRIPTION +</para> +<informaltable><tgroup cols="1"><tbody><row><entry + align="char"> +<para>This ioctl call is used to stop the actual filtering operation defined via the + ioctl calls DMX_SET_FILTER or DMX_SET_PES_FILTER and started via + the DMX_START command.</para> +</entry> + </row></tbody></tgroup></informaltable> +<para>SYNOPSIS +</para> +<informaltable><tgroup cols="1"><tbody><row><entry + align="char"> +<para>int ioctl( int fd, int request = DMX_STOP);</para> +</entry> + </row></tbody></tgroup></informaltable> +<para>PARAMETERS +</para> +<informaltable><tgroup cols="2"><tbody><row><entry + align="char"> +<para>int fd</para> +</entry><entry + align="char"> +<para>File descriptor returned by a previous call to open().</para> +</entry> + </row><row><entry + align="char"> +<para>int request</para> +</entry><entry + align="char"> +<para>Equals DMX_STOP for this command.</para> +</entry> + </row></tbody></tgroup></informaltable> +<para>ERRORS +</para> +<informaltable><tgroup cols="2"><tbody><row><entry + align="char"> +<para>EBADF</para> +</entry><entry + align="char"> +<para>fd is not a valid file descriptor.</para> +</entry> + </row></tbody></tgroup></informaltable> +</section> + +<section id="dmx_set_filter"> +<title>DMX_SET_FILTER</title> +<para>DESCRIPTION +</para> +<informaltable><tgroup cols="1"><tbody><row><entry + align="char"> +<para>This ioctl call sets up a filter according to the filter and mask parameters + provided. A timeout may be defined stating number of seconds to wait for a + section to be loaded. A value of 0 means that no timeout should be applied. + Finally there is a flag field where it is possible to state whether a section should + be CRC-checked, whether the filter should be a ”one-shot” filter, i.e. if the + filtering operation should be stopped after the first section is received, and + whether the filtering operation should be started immediately (without waiting + for a DMX_START ioctl call). If a filter was previously set-up, this filter will + be canceled, and the receive buffer will be flushed.</para> +</entry> + </row></tbody></tgroup></informaltable> +<para>SYNOPSIS +</para> +<informaltable><tgroup cols="1"><tbody><row><entry + align="char"> +<para>int ioctl( int fd, int request = DMX_SET_FILTER, + struct dmx_sct_filter_params ⋆params);</para> +</entry> + </row></tbody></tgroup></informaltable> +<para>PARAMETERS +</para> +<informaltable><tgroup cols="2"><tbody><row><entry + align="char"> +<para>int fd</para> +</entry><entry + align="char"> +<para>File descriptor returned by a previous call to open().</para> +</entry> + </row><row><entry + align="char"> +<para>int request</para> +</entry><entry + align="char"> +<para>Equals DMX_SET_FILTER for this command.</para> +</entry> + </row><row><entry + align="char"> +<para>struct + dmx_sct_filter_params + *params</para> +</entry><entry + align="char"> +<para>Pointer to structure containing filter parameters.</para> +</entry> + </row></tbody></tgroup></informaltable> +<para>ERRORS +</para> +<informaltable><tgroup cols="2"><tbody><row><entry + align="char"> +<para>EBADF</para> +</entry><entry + align="char"> +<para>fd is not a valid file descriptor.</para> +</entry> + </row><row><entry + align="char"> +<para>EINVAL</para> +</entry><entry + align="char"> +<para>Invalid argument.</para> +</entry> + </row></tbody></tgroup></informaltable> +</section> + +<section id="dmx_set_pes_filter"> +<title>DMX_SET_PES_FILTER</title> +<para>DESCRIPTION +</para> +<informaltable><tgroup cols="1"><tbody><row><entry + align="char"> +<para>This ioctl call sets up a PES filter according to the parameters provided. By a + PES filter is meant a filter that is based just on the packet identifier (PID), i.e. + no PES header or payload filtering capability is supported.</para> +</entry> + </row><row><entry + align="char"> +<para>The transport stream destination for the filtered output may be set. Also the + PES type may be stated in order to be able to e.g. direct a video stream directly + to the video decoder. Finally there is a flag field where it is possible to state + whether the filtering operation should be started immediately (without waiting + for a DMX_START ioctl call). If a filter was previously set-up, this filter will + be cancelled, and the receive buffer will be flushed.</para> +</entry> + </row></tbody></tgroup></informaltable> +<para>SYNOPSIS +</para> +<informaltable><tgroup cols="1"><tbody><row><entry + align="char"> +<para>int ioctl( int fd, int request = DMX_SET_PES_FILTER, + struct dmx_pes_filter_params ⋆params);</para> +</entry> + </row></tbody></tgroup></informaltable> +<para>PARAMETERS +</para> +<informaltable><tgroup cols="2"><tbody><row><entry + align="char"> +<para>int fd</para> +</entry><entry + align="char"> +<para>File descriptor returned by a previous call to open().</para> +</entry> + </row><row><entry + align="char"> +<para>int request</para> +</entry><entry + align="char"> +<para>Equals DMX_SET_PES_FILTER for this command.</para> +</entry> + </row><row><entry + align="char"> +<para>struct + dmx_pes_filter_params + *params</para> +</entry><entry + align="char"> +<para>Pointer to structure containing filter parameters.</para> +</entry> + </row></tbody></tgroup></informaltable> +<para>ERRORS +</para> +<informaltable><tgroup cols="2"><tbody><row><entry + align="char"> +<para>EBADF</para> +</entry><entry + align="char"> +<para>fd is not a valid file descriptor.</para> +</entry> + </row><row><entry + align="char"> +<para>EINVAL</para> +</entry><entry + align="char"> +<para>Invalid argument.</para> +</entry> + </row><row><entry + align="char"> +<para>EBUSY</para> +</entry><entry + align="char"> +<para>This error code indicates that there are conflicting + requests. There are active filters filtering data from + another input source. Make sure that these filters are + stopped before starting this filter.</para> +</entry> + </row></tbody></tgroup></informaltable> +</section> + +<section id="dms_set_buffer_size"> +<title>DMX_SET_BUFFER_SIZE</title> +<para>DESCRIPTION +</para> +<informaltable><tgroup cols="1"><tbody><row><entry + align="char"> +<para>This ioctl call is used to set the size of the circular buffer used for filtered data. + The default size is two maximum sized sections, i.e. if this function is not called + a buffer size of 2 * 4096 bytes will be used.</para> +</entry> + </row></tbody></tgroup></informaltable> +<para>SYNOPSIS +</para> +<informaltable><tgroup cols="1"><tbody><row><entry + align="char"> +<para>int ioctl( int fd, int request = + DMX_SET_BUFFER_SIZE, unsigned long size);</para> +</entry> + </row></tbody></tgroup></informaltable> +<para>PARAMETERS +</para> +<informaltable><tgroup cols="2"><tbody><row><entry + align="char"> +<para>int fd</para> +</entry><entry + align="char"> +<para>File descriptor returned by a previous call to open().</para> +</entry> + </row><row><entry + align="char"> +<para>int request</para> +</entry><entry + align="char"> +<para>Equals DMX_SET_BUFFER_SIZE for this command.</para> +</entry> + </row><row><entry + align="char"> +<para>unsigned long size</para> +</entry><entry + align="char"> +<para>Size of circular buffer.</para> +</entry> + </row></tbody></tgroup></informaltable> +<para>ERRORS +</para> +<informaltable><tgroup cols="2"><tbody><row><entry + align="char"> +<para>EBADF</para> +</entry><entry + align="char"> +<para>fd is not a valid file descriptor.</para> +</entry> + </row><row><entry + align="char"> +<para>ENOMEM</para> +</entry><entry + align="char"> +<para>The driver was not able to allocate a buffer of the + requested size.</para> +</entry> + </row></tbody></tgroup></informaltable> +</section> + +<section id="dmx_get_event"> +<title>DMX_GET_EVENT</title> +<para>DESCRIPTION +</para> +<informaltable><tgroup cols="1"><tbody><row><entry + align="char"> +<para>This ioctl call returns an event if available. If an event is not available, + the behavior depends on whether the device is in blocking or non-blocking + mode. In the latter case, the call fails immediately with errno set to + EWOULDBLOCK. In the former case, the call blocks until an event becomes + available.</para> +</entry> + </row><row><entry + align="char"> +<para>The standard Linux poll() and/or select() system calls can be used with the + device file descriptor to watch for new events. For select(), the file descriptor + should be included in the exceptfds argument, and for poll(), POLLPRI should + be specified as the wake-up condition. Only the latest event for each filter is + saved.</para> +</entry> + </row></tbody></tgroup></informaltable> +<para>SYNOPSIS +</para> +<informaltable><tgroup cols="1"><tbody><row><entry + align="char"> +<para>int ioctl( int fd, int request = DMX_GET_EVENT, + struct dmx_event ⋆ev);</para> +</entry> + </row></tbody></tgroup></informaltable> +<para>PARAMETERS +</para> +<informaltable><tgroup cols="2"><tbody><row><entry + align="char"> +<para>int fd</para> +</entry><entry + align="char"> +<para>File descriptor returned by a previous call to open().</para> +</entry> + </row><row><entry + align="char"> +<para>int request</para> +</entry><entry + align="char"> +<para>Equals DMX_GET_EVENT for this command.</para> +</entry> + </row><row><entry + align="char"> +<para>struct dmx_event *ev</para> +</entry><entry + align="char"> +<para>Pointer to the location where the event is to be stored.</para> +</entry> + </row></tbody></tgroup></informaltable> +<para>ERRORS +</para> +<informaltable><tgroup cols="2"><tbody><row><entry + align="char"> +<para>EBADF</para> +</entry><entry + align="char"> +<para>fd is not a valid file descriptor.</para> +</entry> + </row><row><entry + align="char"> +<para>EFAULT</para> +</entry><entry + align="char"> +<para>ev points to an invalid address.</para> +</entry> + </row><row><entry + align="char"> +<para>EWOULDBLOCK</para> +</entry><entry + align="char"> +<para>There is no event pending, and the device is in + non-blocking mode.</para> +</entry> + </row></tbody></tgroup></informaltable> +</section> + +<section id="dmx_get_stc"> +<title>DMX_GET_STC</title> +<para>DESCRIPTION +</para> +<informaltable><tgroup cols="1"><tbody><row><entry + align="char"> +<para>This ioctl call returns the current value of the system time counter (which is driven + by a PES filter of type DMX_PES_PCR). Some hardware supports more than one + STC, so you must specify which one by setting the num field of stc before the ioctl + (range 0...n). The result is returned in form of a ratio with a 64 bit numerator + and a 32 bit denominator, so the real 90kHz STC value is stc->stc / + stc->base + .</para> +</entry> + </row></tbody></tgroup></informaltable> +<para>SYNOPSIS +</para> +<informaltable><tgroup cols="1"><tbody><row><entry + align="char"> +<para>int ioctl( int fd, int request = DMX_GET_STC, struct + dmx_stc ⋆stc);</para> +</entry> + </row></tbody></tgroup></informaltable> +<para>PARAMETERS +</para> +<informaltable><tgroup cols="2"><tbody><row><entry + align="char"> +<para>int fd</para> +</entry><entry + align="char"> +<para>File descriptor returned by a previous call to open().</para> +</entry> + </row><row><entry + align="char"> +<para>int request</para> +</entry><entry + align="char"> +<para>Equals DMX_GET_STC for this command.</para> +</entry> + </row><row><entry + align="char"> +<para>struct dmx_stc *stc</para> +</entry><entry + align="char"> +<para>Pointer to the location where the stc is to be stored.</para> +</entry> + </row></tbody></tgroup></informaltable> +<para>ERRORS +</para> +<informaltable><tgroup cols="2"><tbody><row><entry + align="char"> +<para>EBADF</para> +</entry><entry + align="char"> +<para>fd is not a valid file descriptor.</para> +</entry> + </row><row><entry + align="char"> +<para>EFAULT</para> +</entry><entry + align="char"> +<para>stc points to an invalid address.</para> +</entry> + </row><row><entry + align="char"> +<para>EINVAL</para> +</entry><entry + align="char"> +<para>Invalid stc number.</para> +</entry> + </row></tbody></tgroup></informaltable> + </section></section> diff --git a/Documentation/DocBook/dvb/dvbapi.xml b/Documentation/DocBook/dvb/dvbapi.xml new file mode 100644 index 000000000000..63c528fee624 --- /dev/null +++ b/Documentation/DocBook/dvb/dvbapi.xml @@ -0,0 +1,100 @@ +<partinfo> +<authorgroup> +<author> +<firstname>Ralph</firstname> +<surname>Metzler</surname> +<othername role="mi">J. K.</othername> +<affiliation><address><email>rjkm@metzlerbros.de</email></address></affiliation> +</author> +<author> +<firstname>Marcus</firstname> +<surname>Metzler</surname> +<othername role="mi">O. C.</othername> +<affiliation><address><email>rjkm@metzlerbros.de</email></address></affiliation> +</author> +<author> +<firstname>Mauro</firstname> +<surname>Chehab</surname> +<othername role="mi">Carvalho</othername> +<affiliation><address><email>mchehab@redhat.com</email></address></affiliation> +<contrib>Ported document to Docbook XML.</contrib> +</author> +</authorgroup> +<copyright> + <year>2002</year> + <year>2003</year> + <year>2009</year> + <holder>Convergence GmbH</holder> +</copyright> + +<revhistory> +<!-- Put document revisions here, newest first. --> +<revision> + <revnumber>2.0.2</revnumber> + <date>2009-10-25</date> + <authorinitials>mcc</authorinitials> + <revremark> + documents FE_SET_FRONTEND_TUNE_MODE and FE_DISHETWORK_SEND_LEGACY_CMD ioctls. + </revremark> +</revision> +<revision> +<revnumber>2.0.1</revnumber> +<date>2009-09-16</date> +<authorinitials>mcc</authorinitials> +<revremark> +Added ISDB-T test originally written by Patrick Boettcher +</revremark> +</revision> +<revision> +<revnumber>2.0.0</revnumber> +<date>2009-09-06</date> +<authorinitials>mcc</authorinitials> +<revremark>Conversion from LaTex to DocBook XML. The + contents is the same as the original LaTex version.</revremark> +</revision> +<revision> +<revnumber>1.0.0</revnumber> +<date>2003-07-24</date> +<authorinitials>rjkm</authorinitials> +<revremark>Initial revision on LaTEX.</revremark> +</revision> +</revhistory> +</partinfo> + + +<title>LINUX DVB API</title> +<subtitle>Version 3</subtitle> +<!-- ADD THE CHAPTERS HERE --> + <chapter id="dvb_introdution"> + &sub-intro; + </chapter> + <chapter id="dvb_frontend"> + &sub-frontend; + </chapter> + <chapter id="dvb_demux"> + &sub-demux; + </chapter> + <chapter id="dvb_video"> + &sub-video; + </chapter> + <chapter id="dvb_audio"> + &sub-audio; + </chapter> + <chapter id="dvb_ca"> + &sub-ca; + </chapter> + <chapter id="dvb_net"> + &sub-net; + </chapter> + <chapter id="dvb_kdapi"> + &sub-kdapi; + </chapter> + <chapter id="dvb_examples"> + &sub-examples; + </chapter> +<!-- END OF CHAPTERS --> + <appendix id="frontend_h"> + <title>DVB Frontend Header File</title> + &sub-frontend-h; + </appendix> + diff --git a/Documentation/DocBook/dvb/dvbproperty.xml b/Documentation/DocBook/dvb/dvbproperty.xml new file mode 100644 index 000000000000..5f57c7ccd4ba --- /dev/null +++ b/Documentation/DocBook/dvb/dvbproperty.xml @@ -0,0 +1,318 @@ +<section id="FE_GET_PROPERTY"> +<title>FE_GET_PROPERTY/FE_SET_PROPERTY</title> + +<section id="isdbt"> + <title>ISDB-T frontend</title> + <para>This section describes shortly what are the possible parameters in the Linux + DVB-API called "S2API" and now DVB API 5 in order to tune an ISDB-T/ISDB-Tsb + demodulator:</para> + + <para>This ISDB-T/ISDB-Tsb API extension should reflect all information + needed to tune any ISDB-T/ISDB-Tsb hardware. Of course it is possible + that some very sophisticated devices won't need certain parameters to + tune.</para> + + <para>The information given here should help application writers to know how + to handle ISDB-T and ISDB-Tsb hardware using the Linux DVB-API.</para> + + <para>The details given here about ISDB-T and ISDB-Tsb are just enough to + basically show the dependencies between the needed parameter values, + but surely some information is left out. For more detailed information + see the following documents:</para> + + <para>ARIB STD-B31 - "Transmission System for Digital Terrestrial + Television Broadcasting" and</para> + <para>ARIB TR-B14 - "Operational Guidelines for Digital Terrestrial + Television Broadcasting".</para> + + <para>In order to read this document one has to have some knowledge the + channel structure in ISDB-T and ISDB-Tsb. I.e. it has to be known to + the reader that an ISDB-T channel consists of 13 segments, that it can + have up to 3 layer sharing those segments, and things like that.</para> + + <para>Parameters used by ISDB-T and ISDB-Tsb.</para> + + <section id="isdbt-parms"> + <title>Parameters that are common with DVB-T and ATSC</title> + + <section id="isdbt-freq"> + <title><constant>DTV_FREQUENCY</constant></title> + + <para>Central frequency of the channel.</para> + + <para>For ISDB-T the channels are usally transmitted with an offset of 143kHz. E.g. a + valid frequncy could be 474143 kHz. The stepping is bound to the bandwidth of + the channel which is 6MHz.</para> + + <para>As in ISDB-Tsb the channel consists of only one or three segments the + frequency step is 429kHz, 3*429 respectively. As for ISDB-T the + central frequency of the channel is expected.</para> + </section> + + <section id="isdbt-bw"> + <title><constant>DTV_BANDWIDTH_HZ</constant> (optional)</title> + + <para>Possible values:</para> + + <para>For ISDB-T it should be always 6000000Hz (6MHz)</para> + <para>For ISDB-Tsb it can vary depending on the number of connected segments</para> + + <para>Note: Hardware specific values might be given here, but standard + applications should not bother to set a value to this field as + standard demods are ignoring it anyway.</para> + + <para>Bandwidth in ISDB-T is fixed (6MHz) or can be easily derived from + other parameters (DTV_ISDBT_SB_SEGMENT_IDX, + DTV_ISDBT_SB_SEGMENT_COUNT).</para> + </section> + + <section id="isdbt-delivery-sys"> + <title><constant>DTV_DELIVERY_SYSTEM</constant></title> + + <para>Possible values: <constant>SYS_ISDBT</constant></para> + </section> + + <section id="isdbt-tx-mode"> + <title><constant>DTV_TRANSMISSION_MODE</constant></title> + + <para>ISDB-T supports three carrier/symbol-size: 8K, 4K, 2K. It is called + 'mode' in the standard: Mode 1 is 2K, mode 2 is 4K, mode 3 is 8K</para> + + <para>Possible values: <constant>TRANSMISSION_MODE_2K</constant>, <constant>TRANSMISSION_MODE_8K</constant>, + <constant>TRANSMISSION_MODE_AUTO</constant>, <constant>TRANSMISSION_MODE_4K</constant></para> + + <para>If <constant>DTV_TRANSMISSION_MODE</constant> is set the <constant>TRANSMISSION_MODE_AUTO</constant> the + hardware will try to find the correct FFT-size (if capable) and will + use TMCC to fill in the missing parameters.</para> + + <para><constant>TRANSMISSION_MODE_4K</constant> is added at the same time as the other new parameters.</para> + </section> + + <section id="isdbt-guard-interval"> + <title><constant>DTV_GUARD_INTERVAL</constant></title> + + <para>Possible values: <constant>GUARD_INTERVAL_1_32</constant>, <constant>GUARD_INTERVAL_1_16</constant>, <constant>GUARD_INTERVAL_1_8</constant>, + <constant>GUARD_INTERVAL_1_4</constant>, <constant>GUARD_INTERVAL_AUTO</constant></para> + + <para>If <constant>DTV_GUARD_INTERVAL</constant> is set the <constant>GUARD_INTERVAL_AUTO</constant> the hardware will + try to find the correct guard interval (if capable) and will use TMCC to fill + in the missing parameters.</para> + </section> + </section> + <section id="isdbt-new-parms"> + <title>ISDB-T only parameters</title> + + <section id="isdbt-part-rec"> + <title><constant>DTV_ISDBT_PARTIAL_RECEPTION</constant></title> + + <para><constant>If DTV_ISDBT_SOUND_BROADCASTING</constant> is '0' this bit-field represents whether + the channel is in partial reception mode or not.</para> + + <para>If '1' <constant>DTV_ISDBT_LAYERA_*</constant> values are assigned to the center segment and + <constant>DTV_ISDBT_LAYERA_SEGMENT_COUNT</constant> has to be '1'.</para> + + <para>If in addition <constant>DTV_ISDBT_SOUND_BROADCASTING</constant> is '1' + <constant>DTV_ISDBT_PARTIAL_RECEPTION</constant> represents whether this ISDB-Tsb channel + is consisting of one segment and layer or three segments and two layers.</para> + + <para>Possible values: 0, 1, -1 (AUTO)</para> + </section> + + <section id="isdbt-sound-bcast"> + <title><constant>DTV_ISDBT_SOUND_BROADCASTING</constant></title> + + <para>This field represents whether the other DTV_ISDBT_*-parameters are + referring to an ISDB-T and an ISDB-Tsb channel. (See also + <constant>DTV_ISDBT_PARTIAL_RECEPTION</constant>).</para> + + <para>Possible values: 0, 1, -1 (AUTO)</para> + </section> + + <section id="isdbt-sb-ch-id"> + <title><constant>DTV_ISDBT_SB_SUBCHANNEL_ID</constant></title> + + <para>This field only applies if <constant>DTV_ISDBT_SOUND_BROADCASTING</constant> is '1'.</para> + + <para>(Note of the author: This might not be the correct description of the + <constant>SUBCHANNEL-ID</constant> in all details, but it is my understanding of the technical + background needed to program a device)</para> + + <para>An ISDB-Tsb channel (1 or 3 segments) can be broadcasted alone or in a + set of connected ISDB-Tsb channels. In this set of channels every + channel can be received independently. The number of connected + ISDB-Tsb segment can vary, e.g. depending on the frequency spectrum + bandwidth available.</para> + + <para>Example: Assume 8 ISDB-Tsb connected segments are broadcasted. The + broadcaster has several possibilities to put those channels in the + air: Assuming a normal 13-segment ISDB-T spectrum he can align the 8 + segments from position 1-8 to 5-13 or anything in between.</para> + + <para>The underlying layer of segments are subchannels: each segment is + consisting of several subchannels with a predefined IDs. A sub-channel + is used to help the demodulator to synchronize on the channel.</para> + + <para>An ISDB-T channel is always centered over all sub-channels. As for + the example above, in ISDB-Tsb it is no longer as simple as that.</para> + + <para><constant>The DTV_ISDBT_SB_SUBCHANNEL_ID</constant> parameter is used to give the + sub-channel ID of the segment to be demodulated.</para> + + <para>Possible values: 0 .. 41, -1 (AUTO)</para> + </section> + + <section id="isdbt-sb-seg-idx"> + + <title><constant>DTV_ISDBT_SB_SEGMENT_IDX</constant></title> + + <para>This field only applies if <constant>DTV_ISDBT_SOUND_BROADCASTING</constant> is '1'.</para> + + <para><constant>DTV_ISDBT_SB_SEGMENT_IDX</constant> gives the index of the segment to be + demodulated for an ISDB-Tsb channel where several of them are + transmitted in the connected manner.</para> + + <para>Possible values: 0 .. <constant>DTV_ISDBT_SB_SEGMENT_COUNT</constant> - 1</para> + + <para>Note: This value cannot be determined by an automatic channel search.</para> + </section> + + <section id="isdbt-sb-seg-cnt"> + <title><constant>DTV_ISDBT_SB_SEGMENT_COUNT</constant></title> + + <para>This field only applies if <constant>DTV_ISDBT_SOUND_BROADCASTING</constant> is '1'.</para> + + <para><constant>DTV_ISDBT_SB_SEGMENT_COUNT</constant> gives the total count of connected ISDB-Tsb + channels.</para> + + <para>Possible values: 1 .. 13</para> + + <para>Note: This value cannot be determined by an automatic channel search.</para> + </section> + + <section id="isdb-hierq-layers"> + <title>Hierarchical layers</title> + + <para>ISDB-T channels can be coded hierarchically. As opposed to DVB-T in + ISDB-T hierarchical layers can be decoded simultaneously. For that + reason a ISDB-T demodulator has 3 viterbi and 3 reed-solomon-decoders.</para> + + <para>ISDB-T has 3 hierarchical layers which each can use a part of the + available segments. The total number of segments over all layers has + to 13 in ISDB-T.</para> + + <section id="isdbt-layer-ena"> + <title><constant>DTV_ISDBT_LAYER_ENABLED</constant></title> + + <para>Hierarchical reception in ISDB-T is achieved by enabling or disabling + layers in the decoding process. Setting all bits of + <constant>DTV_ISDBT_LAYER_ENABLED</constant> to '1' forces all layers (if applicable) to be + demodulated. This is the default.</para> + + <para>If the channel is in the partial reception mode + (<constant>DTV_ISDBT_PARTIAL_RECEPTION</constant> = 1) the central segment can be decoded + independently of the other 12 segments. In that mode layer A has to + have a <constant>SEGMENT_COUNT</constant> of 1.</para> + + <para>In ISDB-Tsb only layer A is used, it can be 1 or 3 in ISDB-Tsb + according to <constant>DTV_ISDBT_PARTIAL_RECEPTION</constant>. <constant>SEGMENT_COUNT</constant> must be filled + accordingly.</para> + + <para>Possible values: 0x1, 0x2, 0x4 (|-able)</para> + + <para><constant>DTV_ISDBT_LAYER_ENABLED[0:0]</constant> - layer A</para> + <para><constant>DTV_ISDBT_LAYER_ENABLED[1:1]</constant> - layer B</para> + <para><constant>DTV_ISDBT_LAYER_ENABLED[2:2]</constant> - layer C</para> + <para><constant>DTV_ISDBT_LAYER_ENABLED[31:3]</constant> unused</para> + </section> + + <section id="isdbt-layer-fec"> + <title><constant>DTV_ISDBT_LAYER*_FEC</constant></title> + + <para>Possible values: <constant>FEC_AUTO</constant>, <constant>FEC_1_2</constant>, <constant>FEC_2_3</constant>, <constant>FEC_3_4</constant>, <constant>FEC_5_6</constant>, <constant>FEC_7_8</constant></para> + </section> + + <section id="isdbt-layer-mod"> + <title><constant>DTV_ISDBT_LAYER*_MODULATION</constant></title> + + <para>Possible values: <constant>QAM_AUTO</constant>, QP<constant>SK, QAM_16</constant>, <constant>QAM_64</constant>, <constant>DQPSK</constant></para> + + <para>Note: If layer C is <constant>DQPSK</constant> layer B has to be <constant>DQPSK</constant>. If layer B is <constant>DQPSK</constant> + and <constant>DTV_ISDBT_PARTIAL_RECEPTION</constant>=0 layer has to be <constant>DQPSK</constant>.</para> + </section> + + <section id="isdbt-layer-seg-cnt"> + <title><constant>DTV_ISDBT_LAYER*_SEGMENT_COUNT</constant></title> + + <para>Possible values: 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, -1 (AUTO)</para> + + <para>Note: Truth table for <constant>DTV_ISDBT_SOUND_BROADCASTING</constant> and + <constant>DTV_ISDBT_PARTIAL_RECEPTION</constant> and <constant>LAYER</constant>*_SEGMENT_COUNT</para> + + <informaltable id="isdbt-layer_seg-cnt-table"> + <tgroup cols="6"> + + <tbody> + <row> + <entry>PR</entry> + <entry>SB</entry> + <entry>Layer A width</entry> + <entry>Layer B width</entry> + <entry>Layer C width</entry> + <entry>total width</entry> + </row> + + <row> + <entry>0</entry> + <entry>0</entry> + <entry>1 .. 13</entry> + <entry>1 .. 13</entry> + <entry>1 .. 13</entry> + <entry>13</entry> + </row> + + <row> + <entry>1</entry> + <entry>0</entry> + <entry>1</entry> + <entry>1 .. 13</entry> + <entry>1 .. 13</entry> + <entry>13</entry> + </row> + + <row> + <entry>0</entry> + <entry>1</entry> + <entry>1</entry> + <entry>0</entry> + <entry>0</entry> + <entry>1</entry> + </row> + + <row> + <entry>1</entry> + <entry>1</entry> + <entry>1</entry> + <entry>2</entry> + <entry>0</entry> + <entry>13</entry> + </row> + </tbody> + + </tgroup> + </informaltable> + + </section> + + <section id="isdbt_layer_t_interl"> + <title><constant>DTV_ISDBT_LAYER*_TIME_INTERLEAVING</constant></title> + + <para>Possible values: 0, 1, 2, 3, -1 (AUTO)</para> + + <para>Note: The real inter-leaver depth-names depend on the mode (fft-size); the values + here are referring to what can be found in the TMCC-structure - + independent of the mode.</para> + </section> + </section> + </section> +</section> +</section> diff --git a/Documentation/DocBook/dvb/dvbstb.pdf b/Documentation/DocBook/dvb/dvbstb.pdf Binary files differnew file mode 100644 index 000000000000..0fa75d90c3eb --- /dev/null +++ b/Documentation/DocBook/dvb/dvbstb.pdf diff --git a/Documentation/DocBook/dvb/dvbstb.png b/Documentation/DocBook/dvb/dvbstb.png Binary files differnew file mode 100644 index 000000000000..9b8f372e7afd --- /dev/null +++ b/Documentation/DocBook/dvb/dvbstb.png diff --git a/Documentation/DocBook/dvb/examples.xml b/Documentation/DocBook/dvb/examples.xml new file mode 100644 index 000000000000..f037e568eb6e --- /dev/null +++ b/Documentation/DocBook/dvb/examples.xml @@ -0,0 +1,365 @@ +<title>Examples</title> +<para>In this section we would like to present some examples for using the DVB API. +</para> +<para>Maintainer note: This section is out of date. Please refer to the sample programs packaged +with the driver distribution from <ulink url="http://linuxtv.org/hg/dvb-apps" />. +</para> + +<section id="tuning"> +<title>Tuning</title> +<para>We will start with a generic tuning subroutine that uses the frontend and SEC, as well as +the demux devices. The example is given for QPSK tuners, but can easily be adjusted for +QAM. +</para> +<programlisting> + #include <sys/ioctl.h> + #include <stdio.h> + #include <stdint.h> + #include <sys/types.h> + #include <sys/stat.h> + #include <fcntl.h> + #include <time.h> + #include <unistd.h> + + #include <linux/dvb/dmx.h> + #include <linux/dvb/frontend.h> + #include <linux/dvb/sec.h> + #include <sys/poll.h> + + #define DMX "/dev/dvb/adapter0/demux1" + #define FRONT "/dev/dvb/adapter0/frontend1" + #define SEC "/dev/dvb/adapter0/sec1" + + /⋆ routine for checking if we have a signal and other status information⋆/ + int FEReadStatus(int fd, fe_status_t ⋆stat) + { + int ans; + + if ( (ans = ioctl(fd,FE_READ_STATUS,stat) < 0)){ + perror("FE READ STATUS: "); + return -1; + } + + if (⋆stat & FE_HAS_POWER) + printf("FE HAS POWER\n"); + + if (⋆stat & FE_HAS_SIGNAL) + printf("FE HAS SIGNAL\n"); + + if (⋆stat & FE_SPECTRUM_INV) + printf("SPEKTRUM INV\n"); + + return 0; + } + + + /⋆ tune qpsk ⋆/ + /⋆ freq: frequency of transponder ⋆/ + /⋆ vpid, apid, tpid: PIDs of video, audio and teletext TS packets ⋆/ + /⋆ diseqc: DiSEqC address of the used LNB ⋆/ + /⋆ pol: Polarisation ⋆/ + /⋆ srate: Symbol Rate ⋆/ + /⋆ fec. FEC ⋆/ + /⋆ lnb_lof1: local frequency of lower LNB band ⋆/ + /⋆ lnb_lof2: local frequency of upper LNB band ⋆/ + /⋆ lnb_slof: switch frequency of LNB ⋆/ + + int set_qpsk_channel(int freq, int vpid, int apid, int tpid, + int diseqc, int pol, int srate, int fec, int lnb_lof1, + int lnb_lof2, int lnb_slof) + { + struct secCommand scmd; + struct secCmdSequence scmds; + struct dmx_pes_filter_params pesFilterParams; + FrontendParameters frp; + struct pollfd pfd[1]; + FrontendEvent event; + int demux1, demux2, demux3, front; + + frequency = (uint32_t) freq; + symbolrate = (uint32_t) srate; + + if((front = open(FRONT,O_RDWR)) < 0){ + perror("FRONTEND DEVICE: "); + return -1; + } + + if((sec = open(SEC,O_RDWR)) < 0){ + perror("SEC DEVICE: "); + return -1; + } + + if (demux1 < 0){ + if ((demux1=open(DMX, O_RDWR|O_NONBLOCK)) + < 0){ + perror("DEMUX DEVICE: "); + return -1; + } + } + + if (demux2 < 0){ + if ((demux2=open(DMX, O_RDWR|O_NONBLOCK)) + < 0){ + perror("DEMUX DEVICE: "); + return -1; + } + } + + if (demux3 < 0){ + if ((demux3=open(DMX, O_RDWR|O_NONBLOCK)) + < 0){ + perror("DEMUX DEVICE: "); + return -1; + } + } + + if (freq < lnb_slof) { + frp.Frequency = (freq - lnb_lof1); + scmds.continuousTone = SEC_TONE_OFF; + } else { + frp.Frequency = (freq - lnb_lof2); + scmds.continuousTone = SEC_TONE_ON; + } + frp.Inversion = INVERSION_AUTO; + if (pol) scmds.voltage = SEC_VOLTAGE_18; + else scmds.voltage = SEC_VOLTAGE_13; + + scmd.type=0; + scmd.u.diseqc.addr=0x10; + scmd.u.diseqc.cmd=0x38; + scmd.u.diseqc.numParams=1; + scmd.u.diseqc.params[0] = 0xF0 | ((diseqc ⋆ 4) & 0x0F) | + (scmds.continuousTone == SEC_TONE_ON ? 1 : 0) | + (scmds.voltage==SEC_VOLTAGE_18 ? 2 : 0); + + scmds.miniCommand=SEC_MINI_NONE; + scmds.numCommands=1; + scmds.commands=&scmd; + if (ioctl(sec, SEC_SEND_SEQUENCE, &scmds) < 0){ + perror("SEC SEND: "); + return -1; + } + + if (ioctl(sec, SEC_SEND_SEQUENCE, &scmds) < 0){ + perror("SEC SEND: "); + return -1; + } + + frp.u.qpsk.SymbolRate = srate; + frp.u.qpsk.FEC_inner = fec; + + if (ioctl(front, FE_SET_FRONTEND, &frp) < 0){ + perror("QPSK TUNE: "); + return -1; + } + + pfd[0].fd = front; + pfd[0].events = POLLIN; + + if (poll(pfd,1,3000)){ + if (pfd[0].revents & POLLIN){ + printf("Getting QPSK event\n"); + if ( ioctl(front, FE_GET_EVENT, &event) + + == -EOVERFLOW){ + perror("qpsk get event"); + return -1; + } + printf("Received "); + switch(event.type){ + case FE_UNEXPECTED_EV: + printf("unexpected event\n"); + return -1; + case FE_FAILURE_EV: + printf("failure event\n"); + return -1; + + case FE_COMPLETION_EV: + printf("completion event\n"); + } + } + } + + + pesFilterParams.pid = vpid; + pesFilterParams.input = DMX_IN_FRONTEND; + pesFilterParams.output = DMX_OUT_DECODER; + pesFilterParams.pes_type = DMX_PES_VIDEO; + pesFilterParams.flags = DMX_IMMEDIATE_START; + if (ioctl(demux1, DMX_SET_PES_FILTER, &pesFilterParams) < 0){ + perror("set_vpid"); + return -1; + } + + pesFilterParams.pid = apid; + pesFilterParams.input = DMX_IN_FRONTEND; + pesFilterParams.output = DMX_OUT_DECODER; + pesFilterParams.pes_type = DMX_PES_AUDIO; + pesFilterParams.flags = DMX_IMMEDIATE_START; + if (ioctl(demux2, DMX_SET_PES_FILTER, &pesFilterParams) < 0){ + perror("set_apid"); + return -1; + } + + pesFilterParams.pid = tpid; + pesFilterParams.input = DMX_IN_FRONTEND; + pesFilterParams.output = DMX_OUT_DECODER; + pesFilterParams.pes_type = DMX_PES_TELETEXT; + pesFilterParams.flags = DMX_IMMEDIATE_START; + if (ioctl(demux3, DMX_SET_PES_FILTER, &pesFilterParams) < 0){ + perror("set_tpid"); + return -1; + } + + return has_signal(fds); + } + +</programlisting> +<para>The program assumes that you are using a universal LNB and a standard DiSEqC +switch with up to 4 addresses. Of course, you could build in some more checking if +tuning was successful and maybe try to repeat the tuning process. Depending on the +external hardware, i.e. LNB and DiSEqC switch, and weather conditions this may be +necessary. +</para> +</section> + +<section id="the_dvr_device"> +<title>The DVR device</title> +<para>The following program code shows how to use the DVR device for recording. +</para> +<programlisting> + #include <sys/ioctl.h> + #include <stdio.h> + #include <stdint.h> + #include <sys/types.h> + #include <sys/stat.h> + #include <fcntl.h> + #include <time.h> + #include <unistd.h> + + #include <linux/dvb/dmx.h> + #include <linux/dvb/video.h> + #include <sys/poll.h> + #define DVR "/dev/dvb/adapter0/dvr1" + #define AUDIO "/dev/dvb/adapter0/audio1" + #define VIDEO "/dev/dvb/adapter0/video1" + + #define BUFFY (188⋆20) + #define MAX_LENGTH (1024⋆1024⋆5) /⋆ record 5MB ⋆/ + + + /⋆ switch the demuxes to recording, assuming the transponder is tuned ⋆/ + + /⋆ demux1, demux2: file descriptor of video and audio filters ⋆/ + /⋆ vpid, apid: PIDs of video and audio channels ⋆/ + + int switch_to_record(int demux1, int demux2, uint16_t vpid, uint16_t apid) + { + struct dmx_pes_filter_params pesFilterParams; + + if (demux1 < 0){ + if ((demux1=open(DMX, O_RDWR|O_NONBLOCK)) + < 0){ + perror("DEMUX DEVICE: "); + return -1; + } + } + + if (demux2 < 0){ + if ((demux2=open(DMX, O_RDWR|O_NONBLOCK)) + < 0){ + perror("DEMUX DEVICE: "); + return -1; + } + } + + pesFilterParams.pid = vpid; + pesFilterParams.input = DMX_IN_FRONTEND; + pesFilterParams.output = DMX_OUT_TS_TAP; + pesFilterParams.pes_type = DMX_PES_VIDEO; + pesFilterParams.flags = DMX_IMMEDIATE_START; + if (ioctl(demux1, DMX_SET_PES_FILTER, &pesFilterParams) < 0){ + perror("DEMUX DEVICE"); + return -1; + } + pesFilterParams.pid = apid; + pesFilterParams.input = DMX_IN_FRONTEND; + pesFilterParams.output = DMX_OUT_TS_TAP; + pesFilterParams.pes_type = DMX_PES_AUDIO; + pesFilterParams.flags = DMX_IMMEDIATE_START; + if (ioctl(demux2, DMX_SET_PES_FILTER, &pesFilterParams) < 0){ + perror("DEMUX DEVICE"); + return -1; + } + return 0; + } + + /⋆ start recording MAX_LENGTH , assuming the transponder is tuned ⋆/ + + /⋆ demux1, demux2: file descriptor of video and audio filters ⋆/ + /⋆ vpid, apid: PIDs of video and audio channels ⋆/ + int record_dvr(int demux1, int demux2, uint16_t vpid, uint16_t apid) + { + int i; + int len; + int written; + uint8_t buf[BUFFY]; + uint64_t length; + struct pollfd pfd[1]; + int dvr, dvr_out; + + /⋆ open dvr device ⋆/ + if ((dvr = open(DVR, O_RDONLY|O_NONBLOCK)) < 0){ + perror("DVR DEVICE"); + return -1; + } + + /⋆ switch video and audio demuxes to dvr ⋆/ + printf ("Switching dvr on\n"); + i = switch_to_record(demux1, demux2, vpid, apid); + printf("finished: "); + + printf("Recording %2.0f MB of test file in TS format\n", + MAX_LENGTH/(1024.0⋆1024.0)); + length = 0; + + /⋆ open output file ⋆/ + if ((dvr_out = open(DVR_FILE,O_WRONLY|O_CREAT + |O_TRUNC, S_IRUSR|S_IWUSR + |S_IRGRP|S_IWGRP|S_IROTH| + S_IWOTH)) < 0){ + perror("Can't open file for dvr test"); + return -1; + } + + pfd[0].fd = dvr; + pfd[0].events = POLLIN; + + /⋆ poll for dvr data and write to file ⋆/ + while (length < MAX_LENGTH ) { + if (poll(pfd,1,1)){ + if (pfd[0].revents & POLLIN){ + len = read(dvr, buf, BUFFY); + if (len < 0){ + perror("recording"); + return -1; + } + if (len > 0){ + written = 0; + while (written < len) + written += + write (dvr_out, + buf, len); + length += len; + printf("written %2.0f MB\r", + length/1024./1024.); + } + } + } + } + return 0; + } + +</programlisting> + +</section> diff --git a/Documentation/DocBook/dvb/frontend.h.xml b/Documentation/DocBook/dvb/frontend.h.xml new file mode 100644 index 000000000000..b99644f5340a --- /dev/null +++ b/Documentation/DocBook/dvb/frontend.h.xml @@ -0,0 +1,415 @@ +<programlisting> +/* + * frontend.h + * + * Copyright (C) 2000 Marcus Metzler <marcus@convergence.de> + * Ralph Metzler <ralph@convergence.de> + * Holger Waechtler <holger@convergence.de> + * Andre Draszik <ad@convergence.de> + * for convergence integrated media GmbH + * + * This program is free software; you can redistribute it and/or + * modify it under the terms of the GNU Lesser General Public License + * as published by the Free Software Foundation; either version 2.1 + * of the License, or (at your option) any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU Lesser General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA. + * + */ + +#ifndef _DVBFRONTEND_H_ +#define _DVBFRONTEND_H_ + +#include <linux/types.h> + +typedef enum fe_type { + FE_QPSK, + FE_QAM, + FE_OFDM, + FE_ATSC +} fe_type_t; + + +typedef enum fe_caps { + FE_IS_STUPID = 0, + FE_CAN_INVERSION_AUTO = 0x1, + FE_CAN_FEC_1_2 = 0x2, + FE_CAN_FEC_2_3 = 0x4, + FE_CAN_FEC_3_4 = 0x8, + FE_CAN_FEC_4_5 = 0x10, + FE_CAN_FEC_5_6 = 0x20, + FE_CAN_FEC_6_7 = 0x40, + FE_CAN_FEC_7_8 = 0x80, + FE_CAN_FEC_8_9 = 0x100, + FE_CAN_FEC_AUTO = 0x200, + FE_CAN_QPSK = 0x400, + FE_CAN_QAM_16 = 0x800, + FE_CAN_QAM_32 = 0x1000, + FE_CAN_QAM_64 = 0x2000, + FE_CAN_QAM_128 = 0x4000, + FE_CAN_QAM_256 = 0x8000, + FE_CAN_QAM_AUTO = 0x10000, + FE_CAN_TRANSMISSION_MODE_AUTO = 0x20000, + FE_CAN_BANDWIDTH_AUTO = 0x40000, + FE_CAN_GUARD_INTERVAL_AUTO = 0x80000, + FE_CAN_HIERARCHY_AUTO = 0x100000, + FE_CAN_8VSB = 0x200000, + FE_CAN_16VSB = 0x400000, + FE_HAS_EXTENDED_CAPS = 0x800000, /* We need more bitspace for newer APIs, indicate this. */ + FE_CAN_2G_MODULATION = 0x10000000, /* frontend supports "2nd generation modulation" (DVB-S2) */ + FE_NEEDS_BENDING = 0x20000000, /* not supported anymore, don't use (frontend requires frequency bending) */ + FE_CAN_RECOVER = 0x40000000, /* frontend can recover from a cable unplug automatically */ + FE_CAN_MUTE_TS = 0x80000000 /* frontend can stop spurious TS data output */ +} fe_caps_t; + + +struct dvb_frontend_info { + char name[128]; + fe_type_t type; + __u32 frequency_min; + __u32 frequency_max; + __u32 frequency_stepsize; + __u32 frequency_tolerance; + __u32 symbol_rate_min; + __u32 symbol_rate_max; + __u32 symbol_rate_tolerance; /* ppm */ + __u32 notifier_delay; /* DEPRECATED */ + fe_caps_t caps; +}; + + +/** + * Check out the DiSEqC bus spec available on http://www.eutelsat.org/ for + * the meaning of this struct... + */ +struct dvb_diseqc_master_cmd { + __u8 msg [6]; /* { framing, address, command, data [3] } */ + __u8 msg_len; /* valid values are 3...6 */ +}; + + +struct dvb_diseqc_slave_reply { + __u8 msg [4]; /* { framing, data [3] } */ + __u8 msg_len; /* valid values are 0...4, 0 means no msg */ + int timeout; /* return from ioctl after timeout ms with */ +}; /* errorcode when no message was received */ + + +typedef enum fe_sec_voltage { + SEC_VOLTAGE_13, + SEC_VOLTAGE_18, + SEC_VOLTAGE_OFF +} fe_sec_voltage_t; + + +typedef enum fe_sec_tone_mode { + SEC_TONE_ON, + SEC_TONE_OFF +} fe_sec_tone_mode_t; + + +typedef enum fe_sec_mini_cmd { + SEC_MINI_A, + SEC_MINI_B +} fe_sec_mini_cmd_t; + + +typedef enum fe_status { + FE_HAS_SIGNAL = 0x01, /* found something above the noise level */ + FE_HAS_CARRIER = 0x02, /* found a DVB signal */ + FE_HAS_VITERBI = 0x04, /* FEC is stable */ + FE_HAS_SYNC = 0x08, /* found sync bytes */ + FE_HAS_LOCK = 0x10, /* everything's working... */ + FE_TIMEDOUT = 0x20, /* no lock within the last ~2 seconds */ + FE_REINIT = 0x40 /* frontend was reinitialized, */ +} fe_status_t; /* application is recommended to reset */ + /* DiSEqC, tone and parameters */ + +typedef enum fe_spectral_inversion { + INVERSION_OFF, + INVERSION_ON, + INVERSION_AUTO +} fe_spectral_inversion_t; + + +typedef enum fe_code_rate { + FEC_NONE = 0, + FEC_1_2, + FEC_2_3, + FEC_3_4, + FEC_4_5, + FEC_5_6, + FEC_6_7, + FEC_7_8, + FEC_8_9, + FEC_AUTO, + FEC_3_5, + FEC_9_10, +} fe_code_rate_t; + + +typedef enum fe_modulation { + QPSK, + QAM_16, + QAM_32, + QAM_64, + QAM_128, + QAM_256, + QAM_AUTO, + VSB_8, + VSB_16, + PSK_8, + APSK_16, + APSK_32, + DQPSK, +} fe_modulation_t; + +typedef enum fe_transmit_mode { + TRANSMISSION_MODE_2K, + TRANSMISSION_MODE_8K, + TRANSMISSION_MODE_AUTO, + TRANSMISSION_MODE_4K +} fe_transmit_mode_t; + +typedef enum fe_bandwidth { + BANDWIDTH_8_MHZ, + BANDWIDTH_7_MHZ, + BANDWIDTH_6_MHZ, + BANDWIDTH_AUTO +} fe_bandwidth_t; + + +typedef enum fe_guard_interval { + GUARD_INTERVAL_1_32, + GUARD_INTERVAL_1_16, + GUARD_INTERVAL_1_8, + GUARD_INTERVAL_1_4, + GUARD_INTERVAL_AUTO +} fe_guard_interval_t; + + +typedef enum fe_hierarchy { + HIERARCHY_NONE, + HIERARCHY_1, + HIERARCHY_2, + HIERARCHY_4, + HIERARCHY_AUTO +} fe_hierarchy_t; + + +struct dvb_qpsk_parameters { + __u32 symbol_rate; /* symbol rate in Symbols per second */ + fe_code_rate_t fec_inner; /* forward error correction (see above) */ +}; + +struct dvb_qam_parameters { + __u32 symbol_rate; /* symbol rate in Symbols per second */ + fe_code_rate_t fec_inner; /* forward error correction (see above) */ + fe_modulation_t modulation; /* modulation type (see above) */ +}; + +struct dvb_vsb_parameters { + fe_modulation_t modulation; /* modulation type (see above) */ +}; + +struct dvb_ofdm_parameters { + fe_bandwidth_t bandwidth; + fe_code_rate_t code_rate_HP; /* high priority stream code rate */ + fe_code_rate_t code_rate_LP; /* low priority stream code rate */ + fe_modulation_t constellation; /* modulation type (see above) */ + fe_transmit_mode_t transmission_mode; + fe_guard_interval_t guard_interval; + fe_hierarchy_t hierarchy_information; +}; + + +struct dvb_frontend_parameters { + __u32 frequency; /* (absolute) frequency in Hz for QAM/OFDM/ATSC */ + /* intermediate frequency in kHz for QPSK */ + fe_spectral_inversion_t inversion; + union { + struct dvb_qpsk_parameters qpsk; + struct dvb_qam_parameters qam; + struct dvb_ofdm_parameters ofdm; + struct dvb_vsb_parameters vsb; + } u; +}; + + +struct dvb_frontend_event { + fe_status_t status; + struct dvb_frontend_parameters parameters; +}; + +/* S2API Commands */ +#define DTV_UNDEFINED 0 +#define DTV_TUNE 1 +#define DTV_CLEAR 2 +#define DTV_FREQUENCY 3 +#define DTV_MODULATION 4 +#define DTV_BANDWIDTH_HZ 5 +#define DTV_INVERSION 6 +#define DTV_DISEQC_MASTER 7 +#define DTV_SYMBOL_RATE 8 +#define DTV_INNER_FEC 9 +#define DTV_VOLTAGE 10 +#define DTV_TONE 11 +#define DTV_PILOT 12 +#define DTV_ROLLOFF 13 +#define DTV_DISEQC_SLAVE_REPLY 14 + +/* Basic enumeration set for querying unlimited capabilities */ +#define DTV_FE_CAPABILITY_COUNT 15 +#define DTV_FE_CAPABILITY 16 +#define DTV_DELIVERY_SYSTEM 17 + +/* ISDB-T and ISDB-Tsb */ +#define DTV_ISDBT_PARTIAL_RECEPTION 18 +#define DTV_ISDBT_SOUND_BROADCASTING 19 + +#define DTV_ISDBT_SB_SUBCHANNEL_ID 20 +#define DTV_ISDBT_SB_SEGMENT_IDX 21 +#define DTV_ISDBT_SB_SEGMENT_COUNT 22 + +#define DTV_ISDBT_LAYERA_FEC 23 +#define DTV_ISDBT_LAYERA_MODULATION 24 +#define DTV_ISDBT_LAYERA_SEGMENT_COUNT 25 +#define DTV_ISDBT_LAYERA_TIME_INTERLEAVING 26 + +#define DTV_ISDBT_LAYERB_FEC 27 +#define DTV_ISDBT_LAYERB_MODULATION 28 +#define DTV_ISDBT_LAYERB_SEGMENT_COUNT 29 +#define DTV_ISDBT_LAYERB_TIME_INTERLEAVING 30 + +#define DTV_ISDBT_LAYERC_FEC 31 +#define DTV_ISDBT_LAYERC_MODULATION 32 +#define DTV_ISDBT_LAYERC_SEGMENT_COUNT 33 +#define DTV_ISDBT_LAYERC_TIME_INTERLEAVING 34 + +#define DTV_API_VERSION 35 + +#define DTV_CODE_RATE_HP 36 +#define DTV_CODE_RATE_LP 37 +#define DTV_GUARD_INTERVAL 38 +#define DTV_TRANSMISSION_MODE 39 +#define DTV_HIERARCHY 40 + +#define DTV_ISDBT_LAYER_ENABLED 41 + +#define DTV_ISDBS_TS_ID 42 + +#define DTV_MAX_COMMAND DTV_ISDBS_TS_ID + +typedef enum fe_pilot { + PILOT_ON, + PILOT_OFF, + PILOT_AUTO, +} fe_pilot_t; + +typedef enum fe_rolloff { + ROLLOFF_35, /* Implied value in DVB-S, default for DVB-S2 */ + ROLLOFF_20, + ROLLOFF_25, + ROLLOFF_AUTO, +} fe_rolloff_t; + +typedef enum fe_delivery_system { + SYS_UNDEFINED, + SYS_DVBC_ANNEX_AC, + SYS_DVBC_ANNEX_B, + SYS_DVBT, + SYS_DSS, + SYS_DVBS, + SYS_DVBS2, + SYS_DVBH, + SYS_ISDBT, + SYS_ISDBS, + SYS_ISDBC, + SYS_ATSC, + SYS_ATSCMH, + SYS_DMBTH, + SYS_CMMB, + SYS_DAB, +} fe_delivery_system_t; + +struct dtv_cmds_h { + char *name; /* A display name for debugging purposes */ + + __u32 cmd; /* A unique ID */ + + /* Flags */ + __u32 set:1; /* Either a set or get property */ + __u32 buffer:1; /* Does this property use the buffer? */ + __u32 reserved:30; /* Align */ +}; + +struct dtv_property { + __u32 cmd; + __u32 reserved[3]; + union { + __u32 data; + struct { + __u8 data[32]; + __u32 len; + __u32 reserved1[3]; + void *reserved2; + } buffer; + } u; + int result; +} __attribute__ ((packed)); + +/* num of properties cannot exceed DTV_IOCTL_MAX_MSGS per ioctl */ +#define DTV_IOCTL_MAX_MSGS 64 + +struct dtv_properties { + __u32 num; + struct dtv_property *props; +}; + +#define <link linkend="FE_GET_PROPERTY">FE_SET_PROPERTY</link> _IOW('o', 82, struct dtv_properties) +#define <link linkend="FE_GET_PROPERTY">FE_GET_PROPERTY</link> _IOR('o', 83, struct dtv_properties) + + +/** + * When set, this flag will disable any zigzagging or other "normal" tuning + * behaviour. Additionally, there will be no automatic monitoring of the lock + * status, and hence no frontend events will be generated. If a frontend device + * is closed, this flag will be automatically turned off when the device is + * reopened read-write. + */ +#define FE_TUNE_MODE_ONESHOT 0x01 + + +#define <link linkend="FE_GET_INFO">FE_GET_INFO</link> _IOR('o', 61, struct dvb_frontend_info) + +#define <link linkend="FE_DISEQC_RESET_OVERLOAD">FE_DISEQC_RESET_OVERLOAD</link> _IO('o', 62) +#define <link linkend="FE_DISEQC_SEND_MASTER_CMD">FE_DISEQC_SEND_MASTER_CMD</link> _IOW('o', 63, struct dvb_diseqc_master_cmd) +#define <link linkend="FE_DISEQC_RECV_SLAVE_REPLY">FE_DISEQC_RECV_SLAVE_REPLY</link> _IOR('o', 64, struct dvb_diseqc_slave_reply) +#define <link linkend="FE_DISEQC_SEND_BURST">FE_DISEQC_SEND_BURST</link> _IO('o', 65) /* fe_sec_mini_cmd_t */ + +#define <link linkend="FE_SET_TONE">FE_SET_TONE</link> _IO('o', 66) /* fe_sec_tone_mode_t */ +#define <link linkend="FE_SET_VOLTAGE">FE_SET_VOLTAGE</link> _IO('o', 67) /* fe_sec_voltage_t */ +#define <link linkend="FE_ENABLE_HIGH_LNB_VOLTAGE">FE_ENABLE_HIGH_LNB_VOLTAGE</link> _IO('o', 68) /* int */ + +#define <link linkend="FE_READ_STATUS">FE_READ_STATUS</link> _IOR('o', 69, fe_status_t) +#define <link linkend="FE_READ_BER">FE_READ_BER</link> _IOR('o', 70, __u32) +#define <link linkend="FE_READ_SIGNAL_STRENGTH">FE_READ_SIGNAL_STRENGTH</link> _IOR('o', 71, __u16) +#define <link linkend="FE_READ_SNR">FE_READ_SNR</link> _IOR('o', 72, __u16) +#define <link linkend="FE_READ_UNCORRECTED_BLOCKS">FE_READ_UNCORRECTED_BLOCKS</link> _IOR('o', 73, __u32) + +#define <link linkend="FE_SET_FRONTEND">FE_SET_FRONTEND</link> _IOW('o', 76, struct dvb_frontend_parameters) +#define <link linkend="FE_GET_FRONTEND">FE_GET_FRONTEND</link> _IOR('o', 77, struct dvb_frontend_parameters) +#define <link linkend="FE_SET_FRONTEND_TUNE_MODE">FE_SET_FRONTEND_TUNE_MODE</link> _IO('o', 81) /* unsigned int */ +#define <link linkend="FE_GET_EVENT">FE_GET_EVENT</link> _IOR('o', 78, struct dvb_frontend_event) + +#define <link linkend="FE_DISHNETWORK_SEND_LEGACY_CMD">FE_DISHNETWORK_SEND_LEGACY_CMD</link> _IO('o', 80) /* unsigned int */ + +#endif /*_DVBFRONTEND_H_*/ +</programlisting> diff --git a/Documentation/DocBook/dvb/frontend.xml b/Documentation/DocBook/dvb/frontend.xml new file mode 100644 index 000000000000..300ba1f04177 --- /dev/null +++ b/Documentation/DocBook/dvb/frontend.xml @@ -0,0 +1,1845 @@ +<title>DVB Frontend API</title> + +<para>The DVB frontend device controls the tuner and DVB demodulator +hardware. It can be accessed through <emphasis +role="tt">/dev/dvb/adapter0/frontend0</emphasis>. Data types and and +ioctl definitions can be accessed by including <emphasis +role="tt">linux/dvb/frontend.h</emphasis> in your application.</para> + +<para>DVB frontends come in three varieties: DVB-S (satellite), DVB-C +(cable) and DVB-T (terrestrial). Transmission via the internet (DVB-IP) +is not yet handled by this API but a future extension is possible. For +DVB-S the frontend device also supports satellite equipment control +(SEC) via DiSEqC and V-SEC protocols. The DiSEqC (digital SEC) +specification is available from +<ulink url="http://www.eutelsat.com/satellites/4_5_5.html">Eutelsat</ulink>.</para> + +<para>Note that the DVB API may also be used for MPEG decoder-only PCI +cards, in which case there exists no frontend device.</para> + +<section id="frontend_types"> +<title>Frontend Data Types</title> + +<section id="frontend_type"> +<title>frontend type</title> + +<para>For historical reasons frontend types are named after the type of modulation used in +transmission.</para> +<programlisting> + typedef enum fe_type { + FE_QPSK, /⋆ DVB-S ⋆/ + FE_QAM, /⋆ DVB-C ⋆/ + FE_OFDM /⋆ DVB-T ⋆/ + } fe_type_t; +</programlisting> + +</section> + +<section id="frontend_caps"> +<title>frontend capabilities</title> + +<para>Capabilities describe what a frontend can do. Some capabilities can only be supported for +a specific frontend type.</para> +<programlisting> + typedef enum fe_caps { + FE_IS_STUPID = 0, + FE_CAN_INVERSION_AUTO = 0x1, + FE_CAN_FEC_1_2 = 0x2, + FE_CAN_FEC_2_3 = 0x4, + FE_CAN_FEC_3_4 = 0x8, + FE_CAN_FEC_4_5 = 0x10, + FE_CAN_FEC_5_6 = 0x20, + FE_CAN_FEC_6_7 = 0x40, + FE_CAN_FEC_7_8 = 0x80, + FE_CAN_FEC_8_9 = 0x100, + FE_CAN_FEC_AUTO = 0x200, + FE_CAN_QPSK = 0x400, + FE_CAN_QAM_16 = 0x800, + FE_CAN_QAM_32 = 0x1000, + FE_CAN_QAM_64 = 0x2000, + FE_CAN_QAM_128 = 0x4000, + FE_CAN_QAM_256 = 0x8000, + FE_CAN_QAM_AUTO = 0x10000, + FE_CAN_TRANSMISSION_MODE_AUTO = 0x20000, + FE_CAN_BANDWIDTH_AUTO = 0x40000, + FE_CAN_GUARD_INTERVAL_AUTO = 0x80000, + FE_CAN_HIERARCHY_AUTO = 0x100000, + FE_CAN_MUTE_TS = 0x80000000, + FE_CAN_CLEAN_SETUP = 0x40000000 + } fe_caps_t; +</programlisting> +</section> + +<section id="frontend_info"> +<title>frontend information</title> + +<para>Information about the frontend ca be queried with + <link linkend="FE_GET_INFO">FE_GET_INFO</link>.</para> + +<programlisting> + struct dvb_frontend_info { + char name[128]; + fe_type_t type; + uint32_t frequency_min; + uint32_t frequency_max; + uint32_t frequency_stepsize; + uint32_t frequency_tolerance; + uint32_t symbol_rate_min; + uint32_t symbol_rate_max; + uint32_t symbol_rate_tolerance; /⋆ ppm ⋆/ + uint32_t notifier_delay; /⋆ ms ⋆/ + fe_caps_t caps; + }; +</programlisting> +</section> + +<section id="frontend_diseqc"> +<title>diseqc master command</title> + +<para>A message sent from the frontend to DiSEqC capable equipment.</para> +<programlisting> + struct dvb_diseqc_master_cmd { + uint8_t msg [6]; /⋆ { framing, address, command, data[3] } ⋆/ + uint8_t msg_len; /⋆ valid values are 3...6 ⋆/ + }; +</programlisting> +</section> +<section role="subsection"> +<title>diseqc slave reply</title> + +<para>A reply to the frontend from DiSEqC 2.0 capable equipment.</para> +<programlisting> + struct dvb_diseqc_slave_reply { + uint8_t msg [4]; /⋆ { framing, data [3] } ⋆/ + uint8_t msg_len; /⋆ valid values are 0...4, 0 means no msg ⋆/ + int timeout; /⋆ return from ioctl after timeout ms with ⋆/ + }; /⋆ errorcode when no message was received ⋆/ +</programlisting> +</section> + +<section id="frontend_diseqc_slave_reply"> +<title>diseqc slave reply</title> +<para>The voltage is usually used with non-DiSEqC capable LNBs to switch the polarzation +(horizontal/vertical). When using DiSEqC epuipment this voltage has to be switched +consistently to the DiSEqC commands as described in the DiSEqC spec.</para> +<programlisting> + typedef enum fe_sec_voltage { + SEC_VOLTAGE_13, + SEC_VOLTAGE_18 + } fe_sec_voltage_t; +</programlisting> +</section> + +<section id="frontend_sec_tone"> +<title>SEC continuous tone</title> + +<para>The continous 22KHz tone is usually used with non-DiSEqC capable LNBs to switch the +high/low band of a dual-band LNB. When using DiSEqC epuipment this voltage has to +be switched consistently to the DiSEqC commands as described in the DiSEqC +spec.</para> +<programlisting> + typedef enum fe_sec_tone_mode { + SEC_TONE_ON, + SEC_TONE_OFF + } fe_sec_tone_mode_t; +</programlisting> +</section> + +<section id="frontend_sec_burst"> +<title>SEC tone burst</title> + +<para>The 22KHz tone burst is usually used with non-DiSEqC capable switches to select +between two connected LNBs/satellites. When using DiSEqC epuipment this voltage has to +be switched consistently to the DiSEqC commands as described in the DiSEqC +spec.</para> +<programlisting> + typedef enum fe_sec_mini_cmd { + SEC_MINI_A, + SEC_MINI_B + } fe_sec_mini_cmd_t; +</programlisting> + +<para></para> +</section> + +<section id="frontend_status"> +<title>frontend status</title> +<para>Several functions of the frontend device use the fe_status data type defined +by</para> +<programlisting> + typedef enum fe_status { + FE_HAS_SIGNAL = 0x01, /⋆ found something above the noise level ⋆/ + FE_HAS_CARRIER = 0x02, /⋆ found a DVB signal ⋆/ + FE_HAS_VITERBI = 0x04, /⋆ FEC is stable ⋆/ + FE_HAS_SYNC = 0x08, /⋆ found sync bytes ⋆/ + FE_HAS_LOCK = 0x10, /⋆ everything's working... ⋆/ + FE_TIMEDOUT = 0x20, /⋆ no lock within the last ~2 seconds ⋆/ + FE_REINIT = 0x40 /⋆ frontend was reinitialized, ⋆/ + } fe_status_t; /⋆ application is recommned to reset ⋆/ +</programlisting> +<para>to indicate the current state and/or state changes of the frontend hardware. +</para> + +</section> + +<section id="frontend_params"> +<title>frontend parameters</title> +<para>The kind of parameters passed to the frontend device for tuning depend on +the kind of hardware you are using. All kinds of parameters are combined as an +union in the FrontendParameters structure:</para> +<programlisting> + struct dvb_frontend_parameters { + uint32_t frequency; /⋆ (absolute) frequency in Hz for QAM/OFDM ⋆/ + /⋆ intermediate frequency in kHz for QPSK ⋆/ + fe_spectral_inversion_t inversion; + union { + struct dvb_qpsk_parameters qpsk; + struct dvb_qam_parameters qam; + struct dvb_ofdm_parameters ofdm; + } u; + }; +</programlisting> +<para>For satellite QPSK frontends you have to use the <constant>QPSKParameters</constant> member defined by</para> +<programlisting> + struct dvb_qpsk_parameters { + uint32_t symbol_rate; /⋆ symbol rate in Symbols per second ⋆/ + fe_code_rate_t fec_inner; /⋆ forward error correction (see above) ⋆/ + }; +</programlisting> +<para>for cable QAM frontend you use the <constant>QAMParameters</constant> structure</para> +<programlisting> + struct dvb_qam_parameters { + uint32_t symbol_rate; /⋆ symbol rate in Symbols per second ⋆/ + fe_code_rate_t fec_inner; /⋆ forward error correction (see above) ⋆/ + fe_modulation_t modulation; /⋆ modulation type (see above) ⋆/ + }; +</programlisting> +<para>DVB-T frontends are supported by the <constant>OFDMParamters</constant> structure +</para> +<programlisting> + struct dvb_ofdm_parameters { + fe_bandwidth_t bandwidth; + fe_code_rate_t code_rate_HP; /⋆ high priority stream code rate ⋆/ + fe_code_rate_t code_rate_LP; /⋆ low priority stream code rate ⋆/ + fe_modulation_t constellation; /⋆ modulation type (see above) ⋆/ + fe_transmit_mode_t transmission_mode; + fe_guard_interval_t guard_interval; + fe_hierarchy_t hierarchy_information; + }; +</programlisting> +<para>In the case of QPSK frontends the <constant>Frequency</constant> field specifies the intermediate +frequency, i.e. the offset which is effectively added to the local oscillator frequency (LOF) of +the LNB. The intermediate frequency has to be specified in units of kHz. For QAM and +OFDM frontends the Frequency specifies the absolute frequency and is given in +Hz. +</para> +<para>The Inversion field can take one of these values: +</para> +<programlisting> + typedef enum fe_spectral_inversion { + INVERSION_OFF, + INVERSION_ON, + INVERSION_AUTO + } fe_spectral_inversion_t; +</programlisting> +<para>It indicates if spectral inversion should be presumed or not. In the automatic setting +(<constant>INVERSION_AUTO</constant>) the hardware will try to figure out the correct setting by +itself. +</para> +<para>The possible values for the <constant>FEC_inner</constant> field are +</para> +<programlisting> + typedef enum fe_code_rate { + FEC_NONE = 0, + FEC_1_2, + FEC_2_3, + FEC_3_4, + FEC_4_5, + FEC_5_6, + FEC_6_7, + FEC_7_8, + FEC_8_9, + FEC_AUTO + } fe_code_rate_t; +</programlisting> +<para>which correspond to error correction rates of 1/2, 2/3, etc., no error correction or auto +detection. +</para> +<para>For cable and terrestrial frontends (QAM and OFDM) one also has to specify the quadrature +modulation mode which can be one of the following: +</para> +<programlisting> + typedef enum fe_modulation { + QPSK, + QAM_16, + QAM_32, + QAM_64, + QAM_128, + QAM_256, + QAM_AUTO + } fe_modulation_t; +</programlisting> +<para>Finally, there are several more parameters for OFDM: +</para> +<programlisting> + typedef enum fe_transmit_mode { + TRANSMISSION_MODE_2K, + TRANSMISSION_MODE_8K, + TRANSMISSION_MODE_AUTO + } fe_transmit_mode_t; +</programlisting> + <programlisting> + typedef enum fe_bandwidth { + BANDWIDTH_8_MHZ, + BANDWIDTH_7_MHZ, + BANDWIDTH_6_MHZ, + BANDWIDTH_AUTO + } fe_bandwidth_t; +</programlisting> + <programlisting> + typedef enum fe_guard_interval { + GUARD_INTERVAL_1_32, + GUARD_INTERVAL_1_16, + GUARD_INTERVAL_1_8, + GUARD_INTERVAL_1_4, + GUARD_INTERVAL_AUTO + } fe_guard_interval_t; +</programlisting> + <programlisting> + typedef enum fe_hierarchy { + HIERARCHY_NONE, + HIERARCHY_1, + HIERARCHY_2, + HIERARCHY_4, + HIERARCHY_AUTO + } fe_hierarchy_t; +</programlisting> + +</section> + +<section id="frontend_events"> +<title>frontend events</title> + <programlisting> + struct dvb_frontend_event { + fe_status_t status; + struct dvb_frontend_parameters parameters; + }; +</programlisting> + </section> +</section> + + +<section id="frontend_fcalls"> +<title>Frontend Function Calls</title> + +<section id="frontend_f_open"> +<title>open()</title> +<para>DESCRIPTION</para> +<informaltable><tgroup cols="1"><tbody><row> +<entry align="char"> +<para>This system call opens a named frontend device (/dev/dvb/adapter0/frontend0) + for subsequent use. Usually the first thing to do after a successful open is to + find out the frontend type with <link linkend="FE_GET_INFO">FE_GET_INFO</link>.</para> +<para>The device can be opened in read-only mode, which only allows monitoring of + device status and statistics, or read/write mode, which allows any kind of use + (e.g. performing tuning operations.) +</para> +<para>In a system with multiple front-ends, it is usually the case that multiple devices + cannot be open in read/write mode simultaneously. As long as a front-end + device is opened in read/write mode, other open() calls in read/write mode will + either fail or block, depending on whether non-blocking or blocking mode was + specified. A front-end device opened in blocking mode can later be put into + non-blocking mode (and vice versa) using the F_SETFL command of the fcntl + system call. This is a standard system call, documented in the Linux manual + page for fcntl. When an open() call has succeeded, the device will be ready + for use in the specified mode. This implies that the corresponding hardware is + powered up, and that other front-ends may have been powered down to make + that possible.</para> +</entry> + </row></tbody></tgroup></informaltable> + +<para>SYNOPSIS</para> +<informaltable><tgroup cols="1"><tbody><row><entry + align="char"> +<para>int open(const char ⋆deviceName, int flags);</para> +</entry> + </row></tbody></tgroup></informaltable> +<para>PARAMETERS +</para> +<informaltable><tgroup cols="2"><tbody><row><entry + align="char"> +<para>const char + *deviceName</para> +</entry><entry + align="char"> +<para>Name of specific video device.</para> +</entry> + </row><row><entry + align="char"> +<para>int flags</para> +</entry><entry + align="char"> +<para>A bit-wise OR of the following flags:</para> +</entry> + </row><row><entry + align="char"> +</entry><entry + align="char"> +<para>O_RDONLY read-only access</para> +</entry> + </row><row><entry + align="char"> +</entry><entry + align="char"> +<para>O_RDWR read/write access</para> +</entry> + </row><row><entry + align="char"> +</entry><entry + align="char"> +<para>O_NONBLOCK open in non-blocking mode</para> +</entry> + </row><row><entry + align="char"> +</entry><entry + align="char"> +<para>(blocking mode is the default)</para> +</entry> + </row></tbody></tgroup></informaltable> +<para>ERRORS +</para> +<informaltable><tgroup cols="2"><tbody><row><entry + align="char"> +<para>ENODEV</para> +</entry><entry + align="char"> +<para>Device driver not loaded/available.</para> +</entry> + </row><row><entry + align="char"> +<para>EINTERNAL</para> +</entry><entry + align="char"> +<para>Internal error.</para> +</entry> + </row><row><entry + align="char"> +<para>EBUSY</para> +</entry><entry + align="char"> +<para>Device or resource busy.</para> +</entry> + </row><row><entry + align="char"> +<para>EINVAL</para> +</entry><entry + align="char"> +<para>Invalid argument.</para> +</entry> + </row></tbody></tgroup></informaltable> +</section> + +<section id="frontend_f_close"> +<title>close()</title> +<para>DESCRIPTION +</para> +<informaltable><tgroup cols="1"><tbody><row><entry + align="char"> +<para>This system call closes a previously opened front-end device. After closing + a front-end device, its corresponding hardware might be powered down + automatically.</para> +</entry> + </row></tbody></tgroup></informaltable> +<para>SYNOPSIS +</para> +<informaltable><tgroup cols="1"><tbody><row><entry + align="char"> +<para>int close(int fd);</para> +</entry> + </row></tbody></tgroup></informaltable> +<para>PARAMETERS +</para> +<informaltable><tgroup cols="2"><tbody><row><entry + align="char"> +<para>int fd</para> +</entry><entry + align="char"> +<para>File descriptor returned by a previous call to open().</para> +</entry> + </row></tbody></tgroup></informaltable> +<para>ERRORS +</para> +<informaltable><tgroup cols="2"><tbody><row><entry + align="char"> +<para>EBADF</para> +</entry><entry + align="char"> +<para>fd is not a valid open file descriptor.</para> +</entry> + </row></tbody></tgroup></informaltable> +</section> + +<section id="FE_READ_STATUS"> +<title>FE_READ_STATUS</title> +<para>DESCRIPTION +</para> +<informaltable><tgroup cols="1"><tbody><row><entry + align="char"> +<para>This ioctl call returns status information about the front-end. This call only + requires read-only access to the device.</para> +</entry> + </row></tbody></tgroup></informaltable> +<para>SYNOPSIS +</para> +<informaltable><tgroup cols="1"><tbody><row><entry + align="char"> +<para>int ioctl(int fd, int request = <link linkend="FE_READ_STATUS">FE_READ_STATUS</link>, + fe_status_t ⋆status);</para> +</entry> + </row></tbody></tgroup></informaltable> +<para>PARAMETERS +</para> + +<informaltable><tgroup cols="2"><tbody><row><entry + align="char"> +<para>int fd</para> +</entry><entry + align="char"> +<para>File descriptor returned by a previous call to open().</para> +</entry> + </row><row><entry + align="char"> +<para>int request</para> +</entry><entry + align="char"> +<para>Equals <link linkend="FE_READ_STATUS">FE_READ_STATUS</link> for this command.</para> +</entry> + </row><row><entry + align="char"> +<para>struct fe_status_t + *status</para> +</entry><entry + align="char"> +<para>Points to the location where the front-end status word is + to be stored.</para> +</entry> + </row></tbody></tgroup></informaltable> +<para>ERRORS +</para> +<informaltable><tgroup cols="2"><tbody><row><entry + align="char"> +<para>EBADF</para> +</entry><entry + align="char"> +<para>fd is not a valid open file descriptor.</para> +</entry> + </row><row><entry + align="char"> +<para>EFAULT</para> +</entry><entry + align="char"> +<para>status points to invalid address.</para> +</entry> + </row></tbody></tgroup></informaltable> +</section> + +<section id="FE_READ_BER"> +<title>FE_READ_BER</title> +<para>DESCRIPTION +</para> +<informaltable><tgroup cols="1"><tbody><row><entry + align="char"> +<para>This ioctl call returns the bit error rate for the signal currently + received/demodulated by the front-end. For this command, read-only access to + the device is sufficient.</para> +</entry> + </row></tbody></tgroup></informaltable> +<para>SYNOPSIS +</para> +<informaltable><tgroup cols="1"><tbody><row><entry + align="char"> +<para>int ioctl(int fd, int request = <link linkend="FE_READ_BER">FE_READ_BER</link>, + uint32_t ⋆ber);</para> +</entry> + </row></tbody></tgroup></informaltable> +<para>PARAMETERS +</para> +<informaltable><tgroup cols="2"><tbody><row><entry + align="char"> +<para>int fd</para> +</entry><entry + align="char"> +<para>File descriptor returned by a previous call to open().</para> +</entry> + </row><row><entry + align="char"> +<para>int request</para> +</entry><entry + align="char"> +<para>Equals <link linkend="FE_READ_BER">FE_READ_BER</link> for this command.</para> +</entry> + </row><row><entry + align="char"> +<para>uint32_t *ber</para> +</entry><entry + align="char"> +<para>The bit error rate is stored into *ber.</para> +</entry> + </row></tbody></tgroup></informaltable> +<para>ERRORS +</para> +<informaltable><tgroup cols="2"><tbody><row><entry + align="char"> +<para>EBADF</para> +</entry><entry + align="char"> +<para>fd is not a valid open file descriptor.</para> +</entry> + </row><row><entry + align="char"> +<para>EFAULT</para> +</entry><entry + align="char"> +<para>ber points to invalid address.</para> +</entry> + </row><row><entry + align="char"> +<para>ENOSIGNAL</para> +</entry><entry + align="char"> +<para>There is no signal, thus no meaningful bit error rate. Also + returned if the front-end is not turned on.</para> +</entry> + </row><row><entry + align="char"> +<para>ENOSYS</para> +</entry><entry + align="char"> +<para>Function not available for this device.</para> +</entry> + </row></tbody></tgroup></informaltable> +</section> + +<section id="FE_READ_SNR"> +<title>FE_READ_SNR</title> + +<para>DESCRIPTION +</para> +<informaltable><tgroup cols="1"><tbody><row><entry + align="char"> +<para>This ioctl call returns the signal-to-noise ratio for the signal currently received + by the front-end. For this command, read-only access to the device is sufficient.</para> +</entry> + </row></tbody></tgroup></informaltable> +<para>SYNOPSIS +</para> +<informaltable><tgroup cols="1"><tbody><row><entry + align="char"> +<para>int ioctl(int fd, int request = <link linkend="FE_READ_SNR">FE_READ_SNR</link>, int16_t + ⋆snr);</para> +</entry> + </row></tbody></tgroup></informaltable> +<para>PARAMETERS +</para> +<informaltable><tgroup cols="2"><tbody><row><entry + align="char"> +<para>int fd</para> +</entry><entry + align="char"> +<para>File descriptor returned by a previous call to open().</para> +</entry> + </row><row><entry + align="char"> +<para>int request</para> +</entry><entry + align="char"> +<para>Equals <link linkend="FE_READ_SNR">FE_READ_SNR</link> for this command.</para> +</entry> + </row><row><entry + align="char"> +<para>int16_t *snr</para> +</entry><entry + align="char"> +<para>The signal-to-noise ratio is stored into *snr.</para> +</entry> + </row></tbody></tgroup></informaltable> + +<para>ERRORS +</para> +<informaltable><tgroup cols="2"><tbody><row><entry + align="char"> +<para>EBADF</para> +</entry><entry + align="char"> +<para>fd is not a valid open file descriptor.</para> +</entry> + </row><row><entry + align="char"> +<para>EFAULT</para> +</entry><entry + align="char"> +<para>snr points to invalid address.</para> +</entry> + </row><row><entry + align="char"> +<para>ENOSIGNAL</para> +</entry><entry + align="char"> +<para>There is no signal, thus no meaningful signal strength + value. Also returned if front-end is not turned on.</para> +</entry> + </row><row><entry + align="char"> +<para>ENOSYS</para> +</entry><entry + align="char"> +<para>Function not available for this device.</para> +</entry> + </row></tbody></tgroup></informaltable> +</section> + +<section id="FE_READ_SIGNAL_STRENGTH"> +<title>FE_READ_SIGNAL_STRENGTH</title> +<para>DESCRIPTION +</para> +<informaltable><tgroup cols="1"><tbody><row><entry + align="char"> +<para>This ioctl call returns the signal strength value for the signal currently received + by the front-end. For this command, read-only access to the device is sufficient.</para> +</entry> + </row></tbody></tgroup></informaltable> +<para>SYNOPSIS +</para> +<informaltable><tgroup cols="1"><tbody><row><entry + align="char"> +<para>int ioctl( int fd, int request = + <link linkend="FE_READ_SIGNAL_STRENGTH">FE_READ_SIGNAL_STRENGTH</link>, int16_t ⋆strength);</para> +</entry> + </row></tbody></tgroup></informaltable> + +<para>PARAMETERS +</para> +<informaltable><tgroup cols="2"><tbody><row><entry + align="char"> +<para>int fd</para> +</entry><entry + align="char"> +<para>File descriptor returned by a previous call to open().</para> +</entry> + </row><row><entry + align="char"> +<para>int request</para> +</entry><entry + align="char"> +<para>Equals <link linkend="FE_READ_SIGNAL_STRENGTH">FE_READ_SIGNAL_STRENGTH</link> for this + command.</para> +</entry> + </row><row><entry + align="char"> +<para>int16_t *strength</para> +</entry><entry + align="char"> +<para>The signal strength value is stored into *strength.</para> +</entry> + </row></tbody></tgroup></informaltable> +<para>ERRORS +</para> +<informaltable><tgroup cols="2"><tbody><row><entry + align="char"> +<para>EBADF</para> +</entry><entry + align="char"> +<para>fd is not a valid open file descriptor.</para> +</entry> + </row><row><entry + align="char"> +<para>EFAULT</para> +</entry><entry + align="char"> +<para>status points to invalid address.</para> +</entry> + </row><row><entry + align="char"> +<para>ENOSIGNAL</para> +</entry><entry + align="char"> +<para>There is no signal, thus no meaningful signal strength + value. Also returned if front-end is not turned on.</para> +</entry> + </row><row><entry + align="char"> +<para>ENOSYS</para> +</entry><entry + align="char"> +<para>Function not available for this device.</para> +</entry> + </row></tbody></tgroup></informaltable> +</section> + +<section id="FE_READ_UNCORRECTED_BLOCKS"> +<title>FE_READ_UNCORRECTED_BLOCKS</title> +<para>DESCRIPTION +</para> +<informaltable><tgroup cols="1"><tbody><row><entry + align="char"> +<para>This ioctl call returns the number of uncorrected blocks detected by the device + driver during its lifetime. For meaningful measurements, the increment in block + count during a specific time interval should be calculated. For this command, + read-only access to the device is sufficient.</para> +</entry> + </row><row><entry + align="char"> +<para>Note that the counter will wrap to zero after its maximum count has been + reached.</para> +</entry> + </row></tbody></tgroup></informaltable> +<para>SYNOPSIS +</para> +<informaltable><tgroup cols="1"><tbody><row><entry + align="char"> +<para>int ioctl( int fd, int request = + <link linkend="FE_READ_UNCORRECTED_BLOCKS">FE_READ_UNCORRECTED_BLOCKS</link>, uint32_t ⋆ublocks);</para> +</entry> + </row></tbody></tgroup></informaltable> +<para>PARAMETERS +</para> +<informaltable><tgroup cols="2"><tbody><row><entry + align="char"> +<para>int fd</para> +</entry><entry + align="char"> +<para>File descriptor returned by a previous call to open().</para> +</entry> + </row><row><entry + align="char"> +<para>int request</para> +</entry><entry + align="char"> +<para>Equals <link linkend="FE_READ_UNCORRECTED_BLOCKS">FE_READ_UNCORRECTED_BLOCKS</link> for this + command.</para> +</entry> + </row><row><entry + align="char"> +<para>uint32_t *ublocks</para> +</entry><entry + align="char"> +<para>The total number of uncorrected blocks seen by the driver + so far.</para> +</entry> + </row></tbody></tgroup></informaltable> +<para>ERRORS +</para> +<informaltable><tgroup cols="2"><tbody><row><entry + align="char"> +<para>EBADF</para> +</entry><entry + align="char"> +<para>fd is not a valid open file descriptor.</para> +</entry> + </row><row><entry + align="char"> +<para>EFAULT</para> +</entry><entry + align="char"> +<para>ublocks points to invalid address.</para> +</entry> + </row><row><entry + align="char"> +<para>ENOSYS</para> +</entry><entry + align="char"> +<para>Function not available for this device.</para> +</entry> + </row></tbody></tgroup></informaltable> +</section> + +<section id="FE_SET_FRONTEND"> +<title>FE_SET_FRONTEND</title> +<para>DESCRIPTION +</para> +<informaltable><tgroup cols="1"><tbody><row><entry + align="char"> +<para>This ioctl call starts a tuning operation using specified parameters. The result + of this call will be successful if the parameters were valid and the tuning could + be initiated. The result of the tuning operation in itself, however, will arrive + asynchronously as an event (see documentation for <link linkend="FE_GET_EVENT">FE_GET_EVENT</link> and + FrontendEvent.) If a new <link linkend="FE_SET_FRONTEND">FE_SET_FRONTEND</link> operation is initiated before + the previous one was completed, the previous operation will be aborted in favor + of the new one. This command requires read/write access to the device.</para> +</entry> + </row></tbody></tgroup></informaltable> + +<para>SYNOPSIS +</para> +<informaltable><tgroup cols="1"><tbody><row><entry + align="char"> +<para>int ioctl(int fd, int request = <link linkend="FE_SET_FRONTEND">FE_SET_FRONTEND</link>, + struct dvb_frontend_parameters ⋆p);</para> +</entry> + </row></tbody></tgroup></informaltable> +<para>PARAMETERS +</para> +<informaltable><tgroup cols="2"><tbody><row><entry + align="char"> +<para>int fd</para> +</entry><entry + align="char"> +<para>File descriptor returned by a previous call to open().</para> +</entry> + </row><row><entry + align="char"> +<para>int request</para> +</entry><entry + align="char"> +<para>Equals <link linkend="FE_SET_FRONTEND">FE_SET_FRONTEND</link> for this command.</para> +</entry> + </row><row><entry + align="char"> +<para>struct + dvb_frontend_parameters + *p</para> +</entry><entry + align="char"> +<para>Points to parameters for tuning operation.</para> +</entry> + </row></tbody></tgroup></informaltable> +<para>ERRORS +</para> +<informaltable><tgroup cols="2"><tbody><row><entry + align="char"> +<para>EBADF</para> +</entry><entry + align="char"> +<para>fd is not a valid open file descriptor.</para> +</entry> + </row><row><entry + align="char"> +<para>EFAULT</para> +</entry><entry + align="char"> +<para>p points to invalid address.</para> +</entry> + </row><row><entry + align="char"> +<para>EINVAL</para> +</entry><entry + align="char"> +<para>Maximum supported symbol rate reached.</para> +</entry> +</row></tbody></tgroup></informaltable> +</section> + +<section id="FE_GET_FRONTEND"> +<title>FE_GET_FRONTEND</title> +<para>DESCRIPTION +</para> +<informaltable><tgroup cols="1"><tbody><row><entry + align="char"> +<para>This ioctl call queries the currently effective frontend parameters. For this + command, read-only access to the device is sufficient.</para> +</entry> + </row></tbody></tgroup></informaltable> + +<para>SYNOPSIS +</para> +<informaltable><tgroup cols="1"><tbody><row><entry + align="char"> +<para>int ioctl(int fd, int request = <link linkend="FE_GET_FRONTEND">FE_GET_FRONTEND</link>, + struct dvb_frontend_parameters ⋆p);</para> +</entry> + </row></tbody></tgroup></informaltable> + +<para>PARAMETERS +</para> +<informaltable><tgroup cols="2"><tbody><row><entry + align="char"> +<para>int fd</para> +</entry><entry + align="char"> +<para>File descriptor returned by a previous call to open().</para> +</entry> + </row><row><entry + align="char"> +<para>int request</para> +</entry><entry + align="char"> +<para>Equals <link linkend="FE_SET_FRONTEND">FE_SET_FRONTEND</link> for this command.</para> +</entry> + </row><row><entry + align="char"> +<para>struct + dvb_frontend_parameters + *p</para> +</entry><entry + align="char"> +<para>Points to parameters for tuning operation.</para> +</entry> + </row></tbody></tgroup></informaltable> + +<para>ERRORS +</para> + +<informaltable><tgroup cols="2"><tbody><row><entry + align="char"> +<para>EBADF</para> +</entry><entry + align="char"> +<para>fd is not a valid open file descriptor.</para> +</entry> + </row><row><entry + align="char"> +<para>EFAULT</para> +</entry><entry + align="char"> +<para>p points to invalid address.</para> +</entry> + </row><row><entry + align="char"> +<para>EINVAL</para> +</entry><entry + align="char"> +<para>Maximum supported symbol rate reached.</para> +</entry> + </row></tbody></tgroup></informaltable> + +</section> + +<section id="FE_GET_EVENT"> +<title>FE_GET_EVENT</title> +<para>DESCRIPTION +</para> +<informaltable><tgroup cols="1"><tbody><row><entry + align="char"> +<para>This ioctl call returns a frontend event if available. If an event is not + available, the behavior depends on whether the device is in blocking or + non-blocking mode. In the latter case, the call fails immediately with errno + set to EWOULDBLOCK. In the former case, the call blocks until an event + becomes available.</para> +</entry> + </row><row><entry + align="char"> +<para>The standard Linux poll() and/or select() system calls can be used with the + device file descriptor to watch for new events. For select(), the file descriptor + should be included in the exceptfds argument, and for poll(), POLLPRI should + be specified as the wake-up condition. Since the event queue allocated is + rather small (room for 8 events), the queue must be serviced regularly to avoid + overflow. If an overflow happens, the oldest event is discarded from the queue, + and an error (EOVERFLOW) occurs the next time the queue is read. After + reporting the error condition in this fashion, subsequent + <link linkend="FE_GET_EVENT">FE_GET_EVENT</link> + calls will return events from the queue as usual.</para> +</entry> + </row><row><entry + align="char"> +<para>For the sake of implementation simplicity, this command requires read/write + access to the device.</para> +</entry> + </row></tbody></tgroup></informaltable> + +<para>SYNOPSIS +</para> +<informaltable><tgroup cols="1"><tbody><row><entry + align="char"> +<para>int ioctl(int fd, int request = QPSK_GET_EVENT, + struct dvb_frontend_event ⋆ev);</para> +</entry> + </row></tbody></tgroup></informaltable> + +<para>PARAMETERS +</para> +<informaltable><tgroup cols="2"><tbody><row><entry + align="char"> +<para>int fd</para> +</entry><entry + align="char"> +<para>File descriptor returned by a previous call to open().</para> +</entry> + </row><row><entry + align="char"> +<para>int request</para> +</entry><entry + align="char"> +<para>Equals <link linkend="FE_GET_EVENT">FE_GET_EVENT</link> for this command.</para> +</entry> + </row><row><entry + align="char"> +<para>struct + dvb_frontend_event + *ev</para> +</entry><entry + align="char"> +<para>Points to the location where the event,</para> +</entry> + </row><row><entry + align="char"> +</entry><entry + align="char"> +<para>if any, is to be stored.</para> +</entry> + </row></tbody></tgroup></informaltable> + +<para>ERRORS +</para> +<informaltable><tgroup cols="2"><tbody><row><entry + align="char"> +<para>EBADF</para> +</entry><entry + align="char"> +<para>fd is not a valid open file descriptor.</para> +</entry> + </row><row><entry + align="char"> +<para>EFAULT</para> +</entry><entry + align="char"> +<para>ev points to invalid address.</para> +</entry> + </row><row><entry + align="char"> +<para>EWOULDBLOCK</para> +</entry><entry + align="char"> +<para>There is no event pending, and the device is in + non-blocking mode.</para> +</entry> + </row><row><entry + align="char"> +<para>EOVERFLOW</para> +</entry><entry + align="char"> +</entry> + </row><row><entry + align="char"> +</entry><entry + align="char"> +<para>Overflow in event queue - one or more events were lost.</para> +</entry> +</row></tbody></tgroup></informaltable> +</section> + +<section id="FE_GET_INFO"> +<title>FE_GET_INFO</title> +<para>DESCRIPTION +</para> +<informaltable><tgroup cols="1"><tbody><row><entry + align="char"> +<para>This ioctl call returns information about the front-end. This call only requires + read-only access to the device.</para> +</entry> + </row></tbody></tgroup></informaltable> +<para>SYNOPSIS +</para> + +<informaltable><tgroup cols="1"><tbody><row><entry + align="char"> +<para> int ioctl(int fd, int request = <link linkend="FE_GET_INFO">FE_GET_INFO</link>, struct + dvb_frontend_info ⋆info);</para> +</entry> + </row></tbody></tgroup></informaltable> +<para>PARAMETERS +</para> + +<informaltable><tgroup cols="2"><tbody><row><entry + align="char"> +<para>int fd</para> +</entry><entry + align="char"> +<para>File descriptor returned by a previous call to open().</para> +</entry> + </row><row><entry + align="char"> +<para>int request</para> +</entry><entry + align="char"> +<para>Equals <link linkend="FE_GET_INFO">FE_GET_INFO</link> for this command.</para> +</entry> + </row><row><entry + align="char"> +<para>struct + dvb_frontend_info + *info</para> +</entry><entry + align="char"> +<para>Points to the location where the front-end information is + to be stored.</para> +</entry> + </row></tbody></tgroup></informaltable> +<para>ERRORS +</para> +<informaltable><tgroup cols="2"><tbody><row><entry + align="char"> +<para>EBADF</para> +</entry><entry + align="char"> +<para>fd is not a valid open file descriptor.</para> +</entry> + </row><row><entry + align="char"> +<para>EFAULT</para> +</entry><entry + align="char"> +<para>info points to invalid address.</para> +</entry> +</row></tbody></tgroup></informaltable> +</section> + +<section id="FE_DISEQC_RESET_OVERLOAD"> +<title>FE_DISEQC_RESET_OVERLOAD</title> +<para>DESCRIPTION +</para> +<informaltable><tgroup cols="1"><tbody><row><entry + align="char"> +<para>If the bus has been automatically powered off due to power overload, this ioctl + call restores the power to the bus. The call requires read/write access to the + device. This call has no effect if the device is manually powered off. Not all + DVB adapters support this ioctl.</para> +</entry> + </row></tbody></tgroup></informaltable> + +<para>SYNOPSIS +</para> +<informaltable><tgroup cols="1"><tbody><row><entry + align="char"> +<para>int ioctl(int fd, int request = + <link linkend="FE_DISEQC_RESET_OVERLOAD">FE_DISEQC_RESET_OVERLOAD</link>);</para> +</entry> + </row></tbody></tgroup></informaltable> +<para>PARAMETERS +</para> +<informaltable><tgroup cols="2"><tbody><row><entry + align="char"> +<para>int fd</para> +</entry><entry + align="char"> +<para>File descriptor returned by a previous call to open().</para> +</entry> + </row><row><entry + align="char"> +<para>int request</para> +</entry><entry + align="char"> +<para>Equals <link linkend="FE_DISEQC_RESET_OVERLOAD">FE_DISEQC_RESET_OVERLOAD</link> for this + command.</para> +</entry> + </row></tbody></tgroup></informaltable> + +<para>ERRORS +</para> +<informaltable><tgroup cols="2"><tbody><row><entry + align="char"> +<para>EBADF</para> +</entry><entry + align="char"> +<para>fd is not a valid file descriptor.</para> +</entry> + </row><row><entry + align="char"> +<para>EPERM</para> +</entry><entry + align="char"> +<para>Permission denied (needs read/write access).</para> +</entry> + </row><row><entry + align="char"> +<para>EINTERNAL</para> +</entry><entry + align="char"> +<para>Internal error in the device driver.</para> +</entry> +</row></tbody></tgroup></informaltable> +</section> + +<section id="FE_DISEQC_SEND_MASTER_CMD"> +<title>FE_DISEQC_SEND_MASTER_CMD</title> +<para>DESCRIPTION +</para> +<informaltable><tgroup cols="1"><tbody><row><entry + align="char"> +<para>This ioctl call is used to send a a DiSEqC command.</para> +</entry> + </row></tbody></tgroup></informaltable> +<para>SYNOPSIS +</para> +<informaltable><tgroup cols="1"><tbody><row><entry + align="char"> +<para>int ioctl(int fd, int request = + <link linkend="FE_DISEQC_SEND_MASTER_CMD">FE_DISEQC_SEND_MASTER_CMD</link>, struct + dvb_diseqc_master_cmd ⋆cmd);</para> +</entry> + </row></tbody></tgroup></informaltable> + +<para>PARAMETERS +</para> +<informaltable><tgroup cols="2"><tbody><row><entry + align="char"> +<para>int fd</para> +</entry><entry + align="char"> +<para>File descriptor returned by a previous call to open().</para> +</entry> + </row><row><entry + align="char"> +<para>int request</para> +</entry><entry + align="char"> +<para>Equals <link linkend="FE_DISEQC_SEND_MASTER_CMD">FE_DISEQC_SEND_MASTER_CMD</link> for this + command.</para> +</entry> + </row><row><entry + align="char"> +<para>struct + dvb_diseqc_master_cmd + *cmd</para> +</entry><entry + align="char"> +<para>Pointer to the command to be transmitted.</para> +</entry> + </row></tbody></tgroup></informaltable> + +<para>ERRORS +</para> +<informaltable><tgroup cols="2"><tbody><row><entry + align="char"> +<para>EBADF</para> +</entry><entry + align="char"> +<para>fd is not a valid file descriptor.</para> +</entry> + </row><row><entry + align="char"> +<para>EFAULT</para> +</entry><entry + align="char"> +<para>Seq points to an invalid address.</para> +</entry> + </row><row><entry + align="char"> +<para>EINVAL</para> +</entry><entry + align="char"> +<para>The data structure referred to by seq is invalid in some + way.</para> +</entry> + </row><row><entry + align="char"> +<para>EPERM</para> +</entry><entry + align="char"> +<para>Permission denied (needs read/write access).</para> +</entry> + </row><row><entry + align="char"> +<para>EINTERNAL</para> +</entry><entry + align="char"> +<para>Internal error in the device driver.</para> +</entry> +</row></tbody></tgroup></informaltable> +</section> + +<section id="FE_DISEQC_RECV_SLAVE_REPLY"> +<title>FE_DISEQC_RECV_SLAVE_REPLY</title> +<para>DESCRIPTION +</para> +<informaltable><tgroup cols="1"><tbody><row><entry + align="char"> +<para>This ioctl call is used to receive reply to a DiSEqC 2.0 command.</para> +</entry> + </row></tbody></tgroup></informaltable> + +<para>SYNOPSIS +</para> +<informaltable><tgroup cols="1"><tbody><row><entry + align="char"> +<para>int ioctl(int fd, int request = + <link linkend="FE_DISEQC_RECV_SLAVE_REPLY">FE_DISEQC_RECV_SLAVE_REPLY</link>, struct + dvb_diseqc_slave_reply ⋆reply);</para> +</entry> + </row></tbody></tgroup></informaltable> + +<para>PARAMETERS +</para> +<informaltable><tgroup cols="2"><tbody><row><entry + align="char"> +<para>int fd</para> +</entry><entry + align="char"> +<para>File descriptor returned by a previous call to open().</para> +</entry> + </row><row><entry + align="char"> +<para>int request</para> +</entry><entry + align="char"> +<para>Equals <link linkend="FE_DISEQC_RECV_SLAVE_REPLY">FE_DISEQC_RECV_SLAVE_REPLY</link> for this + command.</para> +</entry> + </row><row><entry + align="char"> +<para>struct + dvb_diseqc_slave_reply + *reply</para> +</entry><entry + align="char"> +<para>Pointer to the command to be received.</para> +</entry> + </row></tbody></tgroup></informaltable> +<para>ERRORS +</para> +<informaltable><tgroup cols="2"><tbody><row><entry + align="char"> +<para>EBADF</para> +</entry><entry + align="char"> +<para>fd is not a valid file descriptor.</para> +</entry> + </row><row><entry + align="char"> +<para>EFAULT</para> +</entry><entry + align="char"> +<para>Seq points to an invalid address.</para> +</entry> + </row><row><entry + align="char"> +<para>EINVAL</para> +</entry><entry + align="char"> +<para>The data structure referred to by seq is invalid in some + way.</para> +</entry> + </row><row><entry + align="char"> +<para>EPERM</para> +</entry><entry + align="char"> +<para>Permission denied (needs read/write access).</para> +</entry> + </row><row><entry + align="char"> +<para>EINTERNAL</para> +</entry><entry + align="char"> +<para>Internal error in the device driver.</para> +</entry> + </row></tbody></tgroup></informaltable> +</section> + +<section id="FE_DISEQC_SEND_BURST"> +<title>FE_DISEQC_SEND_BURST</title> +<para>DESCRIPTION +</para> +<informaltable><tgroup cols="1"><tbody><row><entry + align="char"> +<para>This ioctl call is used to send a 22KHz tone burst.</para> +</entry> + </row></tbody></tgroup></informaltable> + +<para>SYNOPSIS +</para> +<informaltable><tgroup cols="1"><tbody><row><entry + align="char"> +<para>int ioctl(int fd, int request = + <link linkend="FE_DISEQC_SEND_BURST">FE_DISEQC_SEND_BURST</link>, fe_sec_mini_cmd_t burst);</para> +</entry> + </row></tbody></tgroup></informaltable> + +<para>PARAMETERS +</para> +<informaltable><tgroup cols="2"><tbody><row><entry + align="char"> +<para>int fd</para> +</entry><entry + align="char"> +<para>File descriptor returned by a previous call to open().</para> +</entry> + </row><row><entry + align="char"> +<para>int request</para> +</entry><entry + align="char"> +<para>Equals <link linkend="FE_DISEQC_SEND_BURST">FE_DISEQC_SEND_BURST</link> for this command.</para> +</entry> + </row><row><entry + align="char"> +<para>fe_sec_mini_cmd_t + burst</para> +</entry><entry + align="char"> +<para>burst A or B.</para> +</entry> + </row></tbody></tgroup></informaltable> + +<para>ERRORS +</para> +<informaltable><tgroup cols="2"><tbody><row><entry + align="char"> +<para>EBADF</para> +</entry><entry + align="char"> +<para>fd is not a valid file descriptor.</para> +</entry> + </row><row><entry + align="char"> +<para>EFAULT</para> +</entry><entry + align="char"> +<para>Seq points to an invalid address.</para> +</entry> + </row><row><entry + align="char"> +<para>EINVAL</para> +</entry><entry + align="char"> +<para>The data structure referred to by seq is invalid in some + way.</para> +</entry> + </row><row><entry + align="char"> +<para>EPERM</para> +</entry><entry + align="char"> +<para>Permission denied (needs read/write access).</para> +</entry> + </row><row><entry + align="char"> +<para>EINTERNAL</para> +</entry><entry + align="char"> +<para>Internal error in the device driver.</para> +</entry> +</row></tbody></tgroup></informaltable> +</section> + +<section id="FE_SET_TONE"> +<title>FE_SET_TONE</title> +<para>DESCRIPTION +</para> +<informaltable><tgroup cols="1"><tbody><row><entry + align="char"> +<para>This call is used to set the generation of the continuous 22kHz tone. This call + requires read/write permissions.</para> +</entry> + </row></tbody></tgroup></informaltable> +<para>SYNOPSIS +</para> +<informaltable><tgroup cols="1"><tbody><row><entry + align="char"> +<para>int ioctl(int fd, int request = <link linkend="FE_SET_TONE">FE_SET_TONE</link>, + fe_sec_tone_mode_t tone);</para> +</entry> + </row></tbody></tgroup></informaltable> +<para>PARAMETERS +</para> +<informaltable><tgroup cols="2"><tbody><row><entry + align="char"> +<para>int fd</para> +</entry><entry + align="char"> +<para>File descriptor returned by a previous call to open().</para> +</entry> + </row><row><entry + align="char"> +<para>int request</para> +</entry><entry + align="char"> +<para>Equals <link linkend="FE_SET_TONE">FE_SET_TONE</link> for this command.</para> +</entry> + </row><row><entry + align="char"> +<para>fe_sec_tone_mode_t + tone</para> +</entry><entry + align="char"> +<para>The requested tone generation mode (on/off).</para> +</entry> + </row></tbody></tgroup></informaltable> +<para>ERRORS +</para> +<informaltable><tgroup cols="2"><tbody><row><entry + align="char"> +<para>ENODEV</para> +</entry><entry + align="char"> +<para>Device driver not loaded/available.</para> +</entry> + </row><row><entry + align="char"> +<para>EBUSY</para> +</entry><entry + align="char"> +<para>Device or resource busy.</para> +</entry> + </row><row><entry + align="char"> +<para>EINVAL</para> +</entry><entry + align="char"> +<para>Invalid argument.</para> +</entry> + </row><row><entry + align="char"> +<para>EPERM</para> +</entry><entry + align="char"> +<para>File not opened with read permissions.</para> +</entry> + </row><row><entry + align="char"> +<para>EINTERNAL</para> +</entry><entry + align="char"> +<para>Internal error in the device driver.</para> +</entry> +</row></tbody></tgroup></informaltable> +</section> + +<section id="FE_SET_VOLTAGE"> +<title>FE_SET_VOLTAGE</title> +<para>DESCRIPTION +</para> +<informaltable><tgroup cols="1"><tbody><row><entry + align="char"> +<para>This call is used to set the bus voltage. This call requires read/write + permissions.</para> +</entry> + </row></tbody></tgroup></informaltable> +<para>SYNOPSIS +</para> +<informaltable><tgroup cols="1"><tbody><row><entry + align="char"> +<para>int ioctl(int fd, int request = <link linkend="FE_SET_VOLTAGE">FE_SET_VOLTAGE</link>, + fe_sec_voltage_t voltage);</para> +</entry> + </row></tbody></tgroup></informaltable> + +<para>PARAMETERS +</para> +<informaltable><tgroup cols="2"><tbody><row><entry + align="char"> +<para>int fd</para> +</entry><entry + align="char"> +<para>File descriptor returned by a previous call to open().</para> +</entry> + </row><row><entry + align="char"> +<para>int request</para> +</entry><entry + align="char"> +<para>Equals <link linkend="FE_SET_VOLTAGE">FE_SET_VOLTAGE</link> for this command.</para> +</entry> + </row><row><entry + align="char"> +<para>fe_sec_voltage_t + voltage</para> +</entry><entry + align="char"> +<para>The requested bus voltage.</para> +</entry> + </row></tbody></tgroup></informaltable> + +<para>ERRORS +</para> +<informaltable><tgroup cols="2"><tbody><row><entry + align="char"> +<para>ENODEV</para> +</entry><entry + align="char"> +<para>Device driver not loaded/available.</para> +</entry> + </row><row><entry + align="char"> +<para>EBUSY</para> +</entry><entry + align="char"> +<para>Device or resource busy.</para> +</entry> + </row><row><entry + align="char"> +<para>EINVAL</para> +</entry><entry + align="char"> +<para>Invalid argument.</para> +</entry> + </row><row><entry + align="char"> +<para>EPERM</para> +</entry><entry + align="char"> +<para>File not opened with read permissions.</para> +</entry> + </row><row><entry + align="char"> +<para>EINTERNAL</para> +</entry><entry + align="char"> +<para>Internal error in the device driver.</para> +</entry> + </row></tbody></tgroup></informaltable> +</section> + +<section id="FE_ENABLE_HIGH_LNB_VOLTAGE"> +<title>FE_ENABLE_HIGH_LNB_VOLTAGE</title> +<para>DESCRIPTION +</para> +<informaltable><tgroup cols="1"><tbody><row><entry + align="char"> +<para>If high != 0 enables slightly higher voltages instead of 13/18V (to compensate + for long cables). This call requires read/write permissions. Not all DVB + adapters support this ioctl.</para> +</entry> + </row></tbody></tgroup></informaltable> + +<para>SYNOPSIS +</para> +<informaltable><tgroup cols="1"><tbody><row><entry + align="char"> +<para>int ioctl(int fd, int request = + <link linkend="FE_ENABLE_HIGH_LNB_VOLTAGE">FE_ENABLE_HIGH_LNB_VOLTAGE</link>, int high);</para> +</entry> + </row></tbody></tgroup></informaltable> + +<para>PARAMETERS +</para> +<informaltable><tgroup cols="2"><tbody><row><entry + align="char"> +<para>int fd</para> +</entry><entry + align="char"> +<para>File descriptor returned by a previous call to open().</para> +</entry> + </row><row><entry + align="char"> +<para>int request</para> +</entry><entry + align="char"> +<para>Equals <link linkend="FE_SET_VOLTAGE">FE_SET_VOLTAGE</link> for this command.</para> +</entry> + </row><row><entry + align="char"> +<para>int high</para> +</entry><entry + align="char"> +<para>The requested bus voltage.</para> +</entry> + </row></tbody></tgroup></informaltable> + +<para>ERRORS +</para> +<informaltable><tgroup cols="2"><tbody><row><entry + align="char"> +<para>ENODEV</para> +</entry><entry + align="char"> +<para>Device driver not loaded/available.</para> +</entry> + </row><row><entry + align="char"> +<para>EBUSY</para> +</entry><entry + align="char"> +<para>Device or resource busy.</para> +</entry> + </row><row><entry + align="char"> +<para>EINVAL</para> +</entry><entry + align="char"> +<para>Invalid argument.</para> +</entry> + </row><row><entry + align="char"> +<para>EPERM</para> +</entry><entry + align="char"> +<para>File not opened with read permissions.</para> +</entry> + </row><row><entry + align="char"> +<para>EINTERNAL</para> +</entry><entry + align="char"> +<para>Internal error in the device driver.</para> +</entry> + </row></tbody></tgroup></informaltable> +</section> + +<section id="FE_SET_FRONTEND_TUNE_MODE"> +<title>FE_SET_FRONTEND_TUNE_MODE</title> +<para>DESCRIPTION</para> +<informaltable><tgroup cols="1"><tbody><row> +<entry align="char"> +<para>Allow setting tuner mode flags to the frontend.</para> +</entry> +</row></tbody></tgroup></informaltable> + +<para>SYNOPSIS</para> +<informaltable><tgroup cols="1"><tbody><row> +<entry align="char"> +<para>int ioctl(int fd, int request = +<link linkend="FE_SET_FRONTEND_TUNE_MODE">FE_SET_FRONTEND_TUNE_MODE</link>, unsigned int flags);</para> +</entry> +</row></tbody></tgroup></informaltable> + +<para>PARAMETERS</para> +<informaltable><tgroup cols="2"><tbody><row> +<entry align="char"> + <para>unsigned int flags</para> +</entry> +<entry align="char"> +<para> +FE_TUNE_MODE_ONESHOT When set, this flag will disable any zigzagging or other "normal" tuning behaviour. Additionally, there will be no automatic monitoring of the lock status, and hence no frontend events will be generated. If a frontend device is closed, this flag will be automatically turned off when the device is reopened read-write. +</para> +</entry> + </row></tbody></tgroup></informaltable> + +<para>ERRORS</para> +<informaltable><tgroup cols="2"><tbody><row> +<entry align="char"><para>EINVAL</para></entry> +<entry align="char"><para>Invalid argument.</para></entry> + </row></tbody></tgroup></informaltable> +</section> + +<section id="FE_DISHNETWORK_SEND_LEGACY_CMD"> + <title>FE_DISHNETWORK_SEND_LEGACY_CMD</title> +<para>DESCRIPTION</para> +<informaltable><tgroup cols="1"><tbody><row> +<entry align="char"> +<para>WARNING: This is a very obscure legacy command, used only at stv0299 driver. Should not be used on newer drivers.</para> +<para>It provides a non-standard method for selecting Diseqc voltage on the frontend, for Dish Network legacy switches.</para> +<para>As support for this ioctl were added in 2004, this means that such dishes were already legacy in 2004.</para> +</entry> +</row></tbody></tgroup></informaltable> + +<para>SYNOPSIS</para> +<informaltable><tgroup cols="1"><tbody><row> +<entry align="char"> +<para>int ioctl(int fd, int request = + <link linkend="FE_DISHNETWORK_SEND_LEGACY_CMD">FE_DISHNETWORK_SEND_LEGACY_CMD</link>, unsigned long cmd);</para> +</entry> +</row></tbody></tgroup></informaltable> + +<para>PARAMETERS</para> +<informaltable><tgroup cols="2"><tbody><row> +<entry align="char"> + <para>unsigned long cmd</para> +</entry> +<entry align="char"> +<para> +sends the specified raw cmd to the dish via DISEqC. +</para> +</entry> + </row></tbody></tgroup></informaltable> + +<para>ERRORS</para> +<informaltable><tgroup cols="1"><tbody><row> +<entry align="char"> + <para>There are no errors in use for this call</para> +</entry> +</row></tbody></tgroup></informaltable> +</section> + +</section> + +&sub-dvbproperty; diff --git a/Documentation/DocBook/dvb/intro.xml b/Documentation/DocBook/dvb/intro.xml new file mode 100644 index 000000000000..0dc83f672ea2 --- /dev/null +++ b/Documentation/DocBook/dvb/intro.xml @@ -0,0 +1,191 @@ +<title>Introduction</title> + +<section id="requisites"> +<title>What you need to know</title> + +<para>The reader of this document is required to have some knowledge in +the area of digital video broadcasting (DVB) and should be familiar with +part I of the MPEG2 specification ISO/IEC 13818 (aka ITU-T H.222), i.e +you should know what a program/transport stream (PS/TS) is and what is +meant by a packetized elementary stream (PES) or an I-frame.</para> + +<para>Various DVB standards documents are available from +<ulink url="http://www.dvb.org" /> and/or +<ulink url="http://www.etsi.org" />.</para> + +<para>It is also necessary to know how to access unix/linux devices and +how to use ioctl calls. This also includes the knowledge of C or C++. +</para> +</section> + +<section id="history"> +<title>History</title> + +<para>The first API for DVB cards we used at Convergence in late 1999 +was an extension of the Video4Linux API which was primarily developed +for frame grabber cards. As such it was not really well suited to be +used for DVB cards and their new features like recording MPEG streams +and filtering several section and PES data streams at the same time. +</para> + +<para>In early 2000, we were approached by Nokia with a proposal for a +new standard Linux DVB API. As a commitment to the development of +terminals based on open standards, Nokia and Convergence made it +available to all Linux developers and published it on +<ulink url="http://www.linuxtv.org/" /> in September 2000. +Convergence is the maintainer of the Linux DVB API. Together with the +LinuxTV community (i.e. you, the reader of this document), the Linux DVB +API will be constantly reviewed and improved. With the Linux driver for +the Siemens/Hauppauge DVB PCI card Convergence provides a first +implementation of the Linux DVB API.</para> +</section> + +<section id="overview"> +<title>Overview</title> + +<figure id="stb_components"> +<title>Components of a DVB card/STB</title> +<mediaobject> +<imageobject> +<imagedata fileref="dvbstb.pdf" format="PS" /> +</imageobject> +<imageobject> +<imagedata fileref="dvbstb.png" format="PNG" /> +</imageobject> +</mediaobject> +</figure> + +<para>A DVB PCI card or DVB set-top-box (STB) usually consists of the +following main hardware components: </para> + +<itemizedlist> + <listitem> + +<para>Frontend consisting of tuner and DVB demodulator</para> + +<para>Here the raw signal reaches the DVB hardware from a satellite dish +or antenna or directly from cable. The frontend down-converts and +demodulates this signal into an MPEG transport stream (TS). In case of a +satellite frontend, this includes a facility for satellite equipment +control (SEC), which allows control of LNB polarization, multi feed +switches or dish rotors.</para> + +</listitem> + <listitem> + +<para>Conditional Access (CA) hardware like CI adapters and smartcard slots +</para> + +<para>The complete TS is passed through the CA hardware. Programs to +which the user has access (controlled by the smart card) are decoded in +real time and re-inserted into the TS.</para> + +</listitem> + <listitem> + <para>Demultiplexer which filters the incoming DVB stream</para> + +<para>The demultiplexer splits the TS into its components like audio and +video streams. Besides usually several of such audio and video streams +it also contains data streams with information about the programs +offered in this or other streams of the same provider.</para> + +</listitem> +<listitem> + +<para>MPEG2 audio and video decoder</para> + +<para>The main targets of the demultiplexer are the MPEG2 audio and +video decoders. After decoding they pass on the uncompressed audio and +video to the computer screen or (through a PAL/NTSC encoder) to a TV +set.</para> + + +</listitem> +</itemizedlist> + +<para><xref linkend="stb_components" /> shows a crude schematic of the control and data flow +between those components.</para> + +<para>On a DVB PCI card not all of these have to be present since some +functionality can be provided by the main CPU of the PC (e.g. MPEG +picture and sound decoding) or is not needed (e.g. for data-only uses +like “internet over satellite”). Also not every card or STB +provides conditional access hardware.</para> + +</section> + +<section id="dvb_devices"> +<title>Linux DVB Devices</title> + +<para>The Linux DVB API lets you control these hardware components +through currently six Unix-style character devices for video, audio, +frontend, demux, CA and IP-over-DVB networking. The video and audio +devices control the MPEG2 decoder hardware, the frontend device the +tuner and the DVB demodulator. The demux device gives you control over +the PES and section filters of the hardware. If the hardware does not +support filtering these filters can be implemented in software. Finally, +the CA device controls all the conditional access capabilities of the +hardware. It can depend on the individual security requirements of the +platform, if and how many of the CA functions are made available to the +application through this device.</para> + +<para>All devices can be found in the <emphasis role="tt">/dev</emphasis> +tree under <emphasis role="tt">/dev/dvb</emphasis>. The individual devices +are called:</para> + +<itemizedlist> +<listitem> + +<para><emphasis role="tt">/dev/dvb/adapterN/audioM</emphasis>,</para> +</listitem> +<listitem> +<para><emphasis role="tt">/dev/dvb/adapterN/videoM</emphasis>,</para> +</listitem> +<listitem> +<para><emphasis role="tt">/dev/dvb/adapterN/frontendM</emphasis>,</para> +</listitem> + <listitem> + +<para><emphasis role="tt">/dev/dvb/adapterN/netM</emphasis>,</para> +</listitem> + <listitem> + +<para><emphasis role="tt">/dev/dvb/adapterN/demuxM</emphasis>,</para> +</listitem> + <listitem> + +<para><emphasis role="tt">/dev/dvb/adapterN/caM</emphasis>,</para></listitem></itemizedlist> + +<para>where N enumerates the DVB PCI cards in a system starting +from 0, and M enumerates the devices of each type within each +adapter, starting from 0, too. We will omit the “<emphasis +role="tt">/dev/dvb/adapterN/</emphasis>” in the further dicussion +of these devices. The naming scheme for the devices is the same wheter +devfs is used or not.</para> + +<para>More details about the data structures and function calls of all +the devices are described in the following chapters.</para> + +</section> + +<section id="include_files"> +<title>API include files</title> + +<para>For each of the DVB devices a corresponding include file exists. +The DVB API include files should be included in application sources with +a partial path like:</para> + + +<programlisting> + #include <linux/dvb/frontend.h> +</programlisting> + +<para>To enable applications to support different API version, an +additional include file <emphasis +role="tt">linux/dvb/version.h</emphasis> exists, which defines the +constant <emphasis role="tt">DVB_API_VERSION</emphasis>. This document +describes <emphasis role="tt">DVB_API_VERSION 3</emphasis>. +</para> + +</section> + diff --git a/Documentation/DocBook/dvb/kdapi.xml b/Documentation/DocBook/dvb/kdapi.xml new file mode 100644 index 000000000000..6c67481eaa4b --- /dev/null +++ b/Documentation/DocBook/dvb/kdapi.xml @@ -0,0 +1,2309 @@ +<title>Kernel Demux API</title> +<para>The kernel demux API defines a driver-internal interface for registering low-level, +hardware specific driver to a hardware independent demux layer. It is only of interest for +DVB device driver writers. The header file for this API is named <emphasis role="tt">demux.h</emphasis> and located in +<emphasis role="tt">drivers/media/dvb/dvb-core</emphasis>. +</para> +<para>Maintainer note: This section must be reviewed. It is probably out of date. +</para> + +<section id="kernel_demux_data_types"> +<title>Kernel Demux Data Types</title> + + +<section id="dmx_success_t"> +<title>dmx_success_t</title> + <programlisting> + typedef enum { + DMX_OK = 0, /⋆ Received Ok ⋆/ + DMX_LENGTH_ERROR, /⋆ Incorrect length ⋆/ + DMX_OVERRUN_ERROR, /⋆ Receiver ring buffer overrun ⋆/ + DMX_CRC_ERROR, /⋆ Incorrect CRC ⋆/ + DMX_FRAME_ERROR, /⋆ Frame alignment error ⋆/ + DMX_FIFO_ERROR, /⋆ Receiver FIFO overrun ⋆/ + DMX_MISSED_ERROR /⋆ Receiver missed packet ⋆/ + } dmx_success_t; +</programlisting> + +</section> +<section id="ts_filter_types"> +<title>TS filter types</title> + <programlisting> + /⋆--------------------------------------------------------------------------⋆/ + /⋆ TS packet reception ⋆/ + /⋆--------------------------------------------------------------------------⋆/ + + /⋆ TS filter type for set_type() ⋆/ + + #define TS_PACKET 1 /⋆ send TS packets (188 bytes) to callback (default) ⋆/ + #define TS_PAYLOAD_ONLY 2 /⋆ in case TS_PACKET is set, only send the TS + payload (<=184 bytes per packet) to callback ⋆/ + #define TS_DECODER 4 /⋆ send stream to built-in decoder (if present) ⋆/ +</programlisting> + +</section> +<section id="dmx_ts_pes_t"> +<title>dmx_ts_pes_t</title> +<para>The structure +</para> +<programlisting> + typedef enum + { + DMX_TS_PES_AUDIO, /⋆ also send packets to audio decoder (if it exists) ⋆/ + DMX_TS_PES_VIDEO, /⋆ ... ⋆/ + DMX_TS_PES_TELETEXT, + DMX_TS_PES_SUBTITLE, + DMX_TS_PES_PCR, + DMX_TS_PES_OTHER, + } dmx_ts_pes_t; +</programlisting> +<para>describes the PES type for filters which write to a built-in decoder. The correspond (and +should be kept identical) to the types in the demux device. +</para> +<programlisting> + struct dmx_ts_feed_s { + int is_filtering; /⋆ Set to non-zero when filtering in progress ⋆/ + struct dmx_demux_s⋆ parent; /⋆ Back-pointer ⋆/ + void⋆ priv; /⋆ Pointer to private data of the API client ⋆/ + int (⋆set) (struct dmx_ts_feed_s⋆ feed, + __u16 pid, + size_t callback_length, + size_t circular_buffer_size, + int descramble, + struct timespec timeout); + int (⋆start_filtering) (struct dmx_ts_feed_s⋆ feed); + int (⋆stop_filtering) (struct dmx_ts_feed_s⋆ feed); + int (⋆set_type) (struct dmx_ts_feed_s⋆ feed, + int type, + dmx_ts_pes_t pes_type); + }; + + typedef struct dmx_ts_feed_s dmx_ts_feed_t; +</programlisting> + <programlisting> + /⋆--------------------------------------------------------------------------⋆/ + /⋆ PES packet reception (not supported yet) ⋆/ + /⋆--------------------------------------------------------------------------⋆/ + + typedef struct dmx_pes_filter_s { + struct dmx_pes_s⋆ parent; /⋆ Back-pointer ⋆/ + void⋆ priv; /⋆ Pointer to private data of the API client ⋆/ + } dmx_pes_filter_t; +</programlisting> + <programlisting> + typedef struct dmx_pes_feed_s { + int is_filtering; /⋆ Set to non-zero when filtering in progress ⋆/ + struct dmx_demux_s⋆ parent; /⋆ Back-pointer ⋆/ + void⋆ priv; /⋆ Pointer to private data of the API client ⋆/ + int (⋆set) (struct dmx_pes_feed_s⋆ feed, + __u16 pid, + size_t circular_buffer_size, + int descramble, + struct timespec timeout); + int (⋆start_filtering) (struct dmx_pes_feed_s⋆ feed); + int (⋆stop_filtering) (struct dmx_pes_feed_s⋆ feed); + int (⋆allocate_filter) (struct dmx_pes_feed_s⋆ feed, + dmx_pes_filter_t⋆⋆ filter); + int (⋆release_filter) (struct dmx_pes_feed_s⋆ feed, + dmx_pes_filter_t⋆ filter); + } dmx_pes_feed_t; +</programlisting> + <programlisting> + typedef struct { + __u8 filter_value [DMX_MAX_FILTER_SIZE]; + __u8 filter_mask [DMX_MAX_FILTER_SIZE]; + struct dmx_section_feed_s⋆ parent; /⋆ Back-pointer ⋆/ + void⋆ priv; /⋆ Pointer to private data of the API client ⋆/ + } dmx_section_filter_t; +</programlisting> + <programlisting> + struct dmx_section_feed_s { + int is_filtering; /⋆ Set to non-zero when filtering in progress ⋆/ + struct dmx_demux_s⋆ parent; /⋆ Back-pointer ⋆/ + void⋆ priv; /⋆ Pointer to private data of the API client ⋆/ + int (⋆set) (struct dmx_section_feed_s⋆ feed, + __u16 pid, + size_t circular_buffer_size, + int descramble, + int check_crc); + int (⋆allocate_filter) (struct dmx_section_feed_s⋆ feed, + dmx_section_filter_t⋆⋆ filter); + int (⋆release_filter) (struct dmx_section_feed_s⋆ feed, + dmx_section_filter_t⋆ filter); + int (⋆start_filtering) (struct dmx_section_feed_s⋆ feed); + int (⋆stop_filtering) (struct dmx_section_feed_s⋆ feed); + }; + typedef struct dmx_section_feed_s dmx_section_feed_t; + + /⋆--------------------------------------------------------------------------⋆/ + /⋆ Callback functions ⋆/ + /⋆--------------------------------------------------------------------------⋆/ + + typedef int (⋆dmx_ts_cb) ( __u8 ⋆ buffer1, + size_t buffer1_length, + __u8 ⋆ buffer2, + size_t buffer2_length, + dmx_ts_feed_t⋆ source, + dmx_success_t success); + + typedef int (⋆dmx_section_cb) ( __u8 ⋆ buffer1, + size_t buffer1_len, + __u8 ⋆ buffer2, + size_t buffer2_len, + dmx_section_filter_t ⋆ source, + dmx_success_t success); + + typedef int (⋆dmx_pes_cb) ( __u8 ⋆ buffer1, + size_t buffer1_len, + __u8 ⋆ buffer2, + size_t buffer2_len, + dmx_pes_filter_t⋆ source, + dmx_success_t success); + + /⋆--------------------------------------------------------------------------⋆/ + /⋆ DVB Front-End ⋆/ + /⋆--------------------------------------------------------------------------⋆/ + + typedef enum { + DMX_OTHER_FE = 0, + DMX_SATELLITE_FE, + DMX_CABLE_FE, + DMX_TERRESTRIAL_FE, + DMX_LVDS_FE, + DMX_ASI_FE, /⋆ DVB-ASI interface ⋆/ + DMX_MEMORY_FE + } dmx_frontend_source_t; + + typedef struct { + /⋆ The following char⋆ fields point to NULL terminated strings ⋆/ + char⋆ id; /⋆ Unique front-end identifier ⋆/ + char⋆ vendor; /⋆ Name of the front-end vendor ⋆/ + char⋆ model; /⋆ Name of the front-end model ⋆/ + struct list_head connectivity_list; /⋆ List of front-ends that can + be connected to a particular + demux ⋆/ + void⋆ priv; /⋆ Pointer to private data of the API client ⋆/ + dmx_frontend_source_t source; + } dmx_frontend_t; + + /⋆--------------------------------------------------------------------------⋆/ + /⋆ MPEG-2 TS Demux ⋆/ + /⋆--------------------------------------------------------------------------⋆/ + + /⋆ + ⋆ Flags OR'ed in the capabilites field of struct dmx_demux_s. + ⋆/ + + #define DMX_TS_FILTERING 1 + #define DMX_PES_FILTERING 2 + #define DMX_SECTION_FILTERING 4 + #define DMX_MEMORY_BASED_FILTERING 8 /⋆ write() available ⋆/ + #define DMX_CRC_CHECKING 16 + #define DMX_TS_DESCRAMBLING 32 + #define DMX_SECTION_PAYLOAD_DESCRAMBLING 64 + #define DMX_MAC_ADDRESS_DESCRAMBLING 128 +</programlisting> + +</section> +<section id="demux_demux_t"> +<title>demux_demux_t</title> + <programlisting> + /⋆ + ⋆ DMX_FE_ENTRY(): Casts elements in the list of registered + ⋆ front-ends from the generic type struct list_head + ⋆ to the type ⋆ dmx_frontend_t + ⋆. + ⋆/ + + #define DMX_FE_ENTRY(list) list_entry(list, dmx_frontend_t, connectivity_list) + + struct dmx_demux_s { + /⋆ The following char⋆ fields point to NULL terminated strings ⋆/ + char⋆ id; /⋆ Unique demux identifier ⋆/ + char⋆ vendor; /⋆ Name of the demux vendor ⋆/ + char⋆ model; /⋆ Name of the demux model ⋆/ + __u32 capabilities; /⋆ Bitfield of capability flags ⋆/ + dmx_frontend_t⋆ frontend; /⋆ Front-end connected to the demux ⋆/ + struct list_head reg_list; /⋆ List of registered demuxes ⋆/ + void⋆ priv; /⋆ Pointer to private data of the API client ⋆/ + int users; /⋆ Number of users ⋆/ + int (⋆open) (struct dmx_demux_s⋆ demux); + int (⋆close) (struct dmx_demux_s⋆ demux); + int (⋆write) (struct dmx_demux_s⋆ demux, const char⋆ buf, size_t count); + int (⋆allocate_ts_feed) (struct dmx_demux_s⋆ demux, + dmx_ts_feed_t⋆⋆ feed, + dmx_ts_cb callback); + int (⋆release_ts_feed) (struct dmx_demux_s⋆ demux, + dmx_ts_feed_t⋆ feed); + int (⋆allocate_pes_feed) (struct dmx_demux_s⋆ demux, + dmx_pes_feed_t⋆⋆ feed, + dmx_pes_cb callback); + int (⋆release_pes_feed) (struct dmx_demux_s⋆ demux, + dmx_pes_feed_t⋆ feed); + int (⋆allocate_section_feed) (struct dmx_demux_s⋆ demux, + dmx_section_feed_t⋆⋆ feed, + dmx_section_cb callback); + int (⋆release_section_feed) (struct dmx_demux_s⋆ demux, + dmx_section_feed_t⋆ feed); + int (⋆descramble_mac_address) (struct dmx_demux_s⋆ demux, + __u8⋆ buffer1, + size_t buffer1_length, + __u8⋆ buffer2, + size_t buffer2_length, + __u16 pid); + int (⋆descramble_section_payload) (struct dmx_demux_s⋆ demux, + __u8⋆ buffer1, + size_t buffer1_length, + __u8⋆ buffer2, size_t buffer2_length, + __u16 pid); + int (⋆add_frontend) (struct dmx_demux_s⋆ demux, + dmx_frontend_t⋆ frontend); + int (⋆remove_frontend) (struct dmx_demux_s⋆ demux, + dmx_frontend_t⋆ frontend); + struct list_head⋆ (⋆get_frontends) (struct dmx_demux_s⋆ demux); + int (⋆connect_frontend) (struct dmx_demux_s⋆ demux, + dmx_frontend_t⋆ frontend); + int (⋆disconnect_frontend) (struct dmx_demux_s⋆ demux); + + + /⋆ added because js cannot keep track of these himself ⋆/ + int (⋆get_pes_pids) (struct dmx_demux_s⋆ demux, __u16 ⋆pids); + }; + typedef struct dmx_demux_s dmx_demux_t; +</programlisting> + +</section> +<section id="demux_directory"> +<title>Demux directory</title> + <programlisting> + /⋆ + ⋆ DMX_DIR_ENTRY(): Casts elements in the list of registered + ⋆ demuxes from the generic type struct list_head⋆ to the type dmx_demux_t + ⋆. + ⋆/ + + #define DMX_DIR_ENTRY(list) list_entry(list, dmx_demux_t, reg_list) + + int dmx_register_demux (dmx_demux_t⋆ demux); + int dmx_unregister_demux (dmx_demux_t⋆ demux); + struct list_head⋆ dmx_get_demuxes (void); +</programlisting> + </section></section> +<section id="demux_directory_api"> +<title>Demux Directory API</title> +<para>The demux directory is a Linux kernel-wide facility for registering and accessing the +MPEG-2 TS demuxes in the system. Run-time registering and unregistering of demux drivers +is possible using this API. +</para> +<para>All demux drivers in the directory implement the abstract interface dmx_demux_t. +</para> + +<section +role="subsection"><title>dmx_register_demux()</title> +<para>DESCRIPTION +</para> +<informaltable><tgroup cols="1"><tbody><row><entry + align="char"> +<para>This function makes a demux driver interface available to the Linux kernel. It is + usually called by the init_module() function of the kernel module that contains + the demux driver. The caller of this function is responsible for allocating + dynamic or static memory for the demux structure and for initializing its fields + before calling this function. The memory allocated for the demux structure + must not be freed before calling dmx_unregister_demux(),</para> +</entry> + </row></tbody></tgroup></informaltable> +<para>SYNOPSIS +</para> +<informaltable><tgroup cols="1"><tbody><row><entry + align="char"> +<para>int dmx_register_demux ( dmx_demux_t ⋆demux )</para> +</entry> + </row></tbody></tgroup></informaltable> +<para>PARAMETERS +</para> +<informaltable><tgroup cols="2"><tbody><row><entry + align="char"> +<para>dmx_demux_t* + demux</para> +</entry><entry + align="char"> +<para>Pointer to the demux structure.</para> +</entry> + </row></tbody></tgroup></informaltable> +<para>RETURNS +</para> +<informaltable><tgroup cols="2"><tbody><row><entry + align="char"> +<para>0</para> +</entry><entry + align="char"> +<para>The function was completed without errors.</para> +</entry> + </row><row><entry + align="char"> +<para>-EEXIST</para> +</entry><entry + align="char"> +<para>A demux with the same value of the id field already stored + in the directory.</para> +</entry> + </row><row><entry + align="char"> +<para>-ENOSPC</para> +</entry><entry + align="char"> +<para>No space left in the directory.</para> +</entry> + </row></tbody></tgroup></informaltable> + +</section><section +role="subsection"><title>dmx_unregister_demux()</title> +<para>DESCRIPTION +</para> +<informaltable><tgroup cols="1"><tbody><row><entry + align="char"> +<para>This function is called to indicate that the given demux interface is no + longer available. The caller of this function is responsible for freeing the + memory of the demux structure, if it was dynamically allocated before calling + dmx_register_demux(). The cleanup_module() function of the kernel module + that contains the demux driver should call this function. Note that this function + fails if the demux is currently in use, i.e., release_demux() has not been called + for the interface.</para> +</entry> + </row></tbody></tgroup></informaltable> +<para>SYNOPSIS +</para> +<informaltable><tgroup cols="1"><tbody><row><entry + align="char"> +<para>int dmx_unregister_demux ( dmx_demux_t ⋆demux )</para> +</entry> + </row></tbody></tgroup></informaltable> +<para>PARAMETERS +</para> +<informaltable><tgroup cols="2"><tbody><row><entry + align="char"> +<para>dmx_demux_t* + demux</para> +</entry><entry + align="char"> +<para>Pointer to the demux structure which is to be + unregistered.</para> +</entry> + </row></tbody></tgroup></informaltable> +<para>RETURNS +</para> +<informaltable><tgroup cols="2"><tbody><row><entry + align="char"> +<para>0</para> +</entry><entry + align="char"> +<para>The function was completed without errors.</para> +</entry> + </row><row><entry + align="char"> +<para>ENODEV</para> +</entry><entry + align="char"> +<para>The specified demux is not registered in the demux + directory.</para> +</entry> + </row><row><entry + align="char"> +<para>EBUSY</para> +</entry><entry + align="char"> +<para>The specified demux is currently in use.</para> +</entry> + </row></tbody></tgroup></informaltable> + +</section><section +role="subsection"><title>dmx_get_demuxes()</title> +<para>DESCRIPTION +</para> +<informaltable><tgroup cols="1"><tbody><row><entry + align="char"> +<para>Provides the caller with the list of registered demux interfaces, using the + standard list structure defined in the include file linux/list.h. The include file + demux.h defines the macro DMX_DIR_ENTRY() for converting an element of + the generic type struct list_head* to the type dmx_demux_t*. The caller must + not free the memory of any of the elements obtained via this function call.</para> +</entry> + </row></tbody></tgroup></informaltable> +<para>SYNOPSIS +</para> +<informaltable><tgroup cols="1"><tbody><row><entry + align="char"> +<para>struct list_head ⋆dmx_get_demuxes ()</para> +</entry> + </row></tbody></tgroup></informaltable> +<para>PARAMETERS +</para> +<informaltable><tgroup cols="2"><tbody><row><entry + align="char"> +<para>none</para> +</entry> + </row></tbody></tgroup></informaltable> +<para>RETURNS +</para> +<informaltable><tgroup cols="2"><tbody><row><entry + align="char"> +<para>struct list_head *</para> +</entry><entry + align="char"> +<para>A list of demux interfaces, or NULL in the case of an + empty list.</para> +</entry> + </row></tbody></tgroup></informaltable> + </section></section> +<section id="demux_api"> +<title>Demux API</title> +<para>The demux API should be implemented for each demux in the system. It is used to select +the TS source of a demux and to manage the demux resources. When the demux +client allocates a resource via the demux API, it receives a pointer to the API of that +resource. +</para> +<para>Each demux receives its TS input from a DVB front-end or from memory, as set via the +demux API. In a system with more than one front-end, the API can be used to select one of +the DVB front-ends as a TS source for a demux, unless this is fixed in the HW platform. The +demux API only controls front-ends regarding their connections with demuxes; the APIs +used to set the other front-end parameters, such as tuning, are not defined in this +document. +</para> +<para>The functions that implement the abstract interface demux should be defined static or +module private and registered to the Demux Directory for external access. It is not necessary +to implement every function in the demux_t struct, however (for example, a demux interface +might support Section filtering, but not TS or PES filtering). The API client is expected to +check the value of any function pointer before calling the function: the value of NULL means +“function not available”. +</para> +<para>Whenever the functions of the demux API modify shared data, the possibilities of lost +update and race condition problems should be addressed, e.g. by protecting parts of code with +mutexes. This is especially important on multi-processor hosts. +</para> +<para>Note that functions called from a bottom half context must not sleep, at least in the 2.2.x +kernels. Even a simple memory allocation can result in a kernel thread being put to sleep if +swapping is needed. For example, the Linux kernel calls the functions of a network device +interface from a bottom half context. Thus, if a demux API function is called from network +device code, the function must not sleep. +</para> + + +<section id="kdapi_fopen"> +<title>open()</title> +<para>DESCRIPTION +</para> +<informaltable><tgroup cols="1"><tbody><row><entry + align="char"> +<para>This function reserves the demux for use by the caller and, if necessary, + initializes the demux. When the demux is no longer needed, the function close() + should be called. It should be possible for multiple clients to access the demux + at the same time. Thus, the function implementation should increment the + demux usage count when open() is called and decrement it when close() is + called.</para> +</entry> + </row></tbody></tgroup></informaltable> +<para>SYNOPSIS +</para> +<informaltable><tgroup cols="1"><tbody><row><entry + align="char"> +<para>int open ( demux_t⋆ demux );</para> +</entry> + </row></tbody></tgroup></informaltable> +<para>PARAMETERS +</para> +<informaltable><tgroup cols="2"><tbody><row><entry + align="char"> +<para>demux_t* demux</para> +</entry><entry + align="char"> +<para>Pointer to the demux API and instance data.</para> +</entry> + </row></tbody></tgroup></informaltable> +<para>RETURNS +</para> +<informaltable><tgroup cols="2"><tbody><row><entry + align="char"> +<para>0</para> +</entry><entry + align="char"> +<para>The function was completed without errors.</para> +</entry> + </row><row><entry + align="char"> +<para>-EUSERS</para> +</entry><entry + align="char"> +<para>Maximum usage count reached.</para> +</entry> + </row><row><entry + align="char"> +<para>-EINVAL</para> +</entry><entry + align="char"> +<para>Bad parameter.</para> +</entry> + </row></tbody></tgroup></informaltable> + +</section> +<section id="kdapi_fclose"> +<title>close()</title> +<para>DESCRIPTION +</para> +<informaltable><tgroup cols="1"><tbody><row><entry + align="char"> +<para>This function reserves the demux for use by the caller and, if necessary, + initializes the demux. When the demux is no longer needed, the function close() + should be called. It should be possible for multiple clients to access the demux + at the same time. Thus, the function implementation should increment the + demux usage count when open() is called and decrement it when close() is + called.</para> +</entry> + </row></tbody></tgroup></informaltable> +<para>SYNOPSIS +</para> +<informaltable><tgroup cols="1"><tbody><row><entry + align="char"> +<para>int close(demux_t⋆ demux);</para> +</entry> + </row></tbody></tgroup></informaltable> +<para>PARAMETERS +</para> +<informaltable><tgroup cols="2"><tbody><row><entry + align="char"> +<para>demux_t* demux</para> +</entry><entry + align="char"> +<para>Pointer to the demux API and instance data.</para> +</entry> + </row></tbody></tgroup></informaltable> +<para>RETURNS +</para> +<informaltable><tgroup cols="2"><tbody><row><entry + align="char"> +<para>0</para> +</entry><entry + align="char"> +<para>The function was completed without errors.</para> +</entry> + </row><row><entry + align="char"> +<para>-ENODEV</para> +</entry><entry + align="char"> +<para>The demux was not in use.</para> +</entry> + </row><row><entry + align="char"> +<para>-EINVAL</para> +</entry><entry + align="char"> +<para>Bad parameter.</para> +</entry> + </row></tbody></tgroup></informaltable> + +</section> +<section id="kdapi_fwrite"> +<title>write()</title> +<para>DESCRIPTION +</para> +<informaltable><tgroup cols="1"><tbody><row><entry + align="char"> +<para>This function provides the demux driver with a memory buffer containing TS + packets. Instead of receiving TS packets from the DVB front-end, the demux + driver software will read packets from memory. Any clients of this demux + with active TS, PES or Section filters will receive filtered data via the Demux + callback API (see 0). The function returns when all the data in the buffer has + been consumed by the demux. Demux hardware typically cannot read TS from + memory. If this is the case, memory-based filtering has to be implemented + entirely in software.</para> +</entry> + </row></tbody></tgroup></informaltable> +<para>SYNOPSIS +</para> +<informaltable><tgroup cols="1"><tbody><row><entry + align="char"> +<para>int write(demux_t⋆ demux, const char⋆ buf, size_t + count);</para> +</entry> + </row></tbody></tgroup></informaltable> +<para>PARAMETERS +</para> +<informaltable><tgroup cols="2"><tbody><row><entry + align="char"> +<para>demux_t* demux</para> +</entry><entry + align="char"> +<para>Pointer to the demux API and instance data.</para> +</entry> + </row><row><entry + align="char"> +<para>const char* buf</para> +</entry><entry + align="char"> +<para>Pointer to the TS data in kernel-space memory.</para> +</entry> + </row><row><entry + align="char"> +<para>size_t length</para> +</entry><entry + align="char"> +<para>Length of the TS data.</para> +</entry> + </row></tbody></tgroup></informaltable> +<para>RETURNS +</para> +<informaltable><tgroup cols="2"><tbody><row><entry + align="char"> +<para>0</para> +</entry><entry + align="char"> +<para>The function was completed without errors.</para> +</entry> + </row><row><entry + align="char"> +<para>-ENOSYS</para> +</entry><entry + align="char"> +<para>The command is not implemented.</para> +</entry> + </row><row><entry + align="char"> +<para>-EINVAL</para> +</entry><entry + align="char"> +<para>Bad parameter.</para> +</entry> + </row></tbody></tgroup></informaltable> + +</section><section +role="subsection"><title>allocate_ts_feed()</title> +<para>DESCRIPTION +</para> +<informaltable><tgroup cols="1"><tbody><row><entry + align="char"> +<para>Allocates a new TS feed, which is used to filter the TS packets carrying a + certain PID. The TS feed normally corresponds to a hardware PID filter on the + demux chip.</para> +</entry> + </row></tbody></tgroup></informaltable> +<para>SYNOPSIS +</para> +<informaltable><tgroup cols="1"><tbody><row><entry + align="char"> +<para>int allocate_ts_feed(dmx_demux_t⋆ demux, + dmx_ts_feed_t⋆⋆ feed, dmx_ts_cb callback);</para> +</entry> + </row></tbody></tgroup></informaltable> +<para>PARAMETERS +</para> +<informaltable><tgroup cols="2"><tbody><row><entry + align="char"> +<para>demux_t* demux</para> +</entry><entry + align="char"> +<para>Pointer to the demux API and instance data.</para> +</entry> + </row><row><entry + align="char"> +<para>dmx_ts_feed_t** + feed</para> +</entry><entry + align="char"> +<para>Pointer to the TS feed API and instance data.</para> +</entry> + </row><row><entry + align="char"> +<para>dmx_ts_cb callback</para> +</entry><entry + align="char"> +<para>Pointer to the callback function for passing received TS + packet</para> +</entry> + </row></tbody></tgroup></informaltable> +<para>RETURNS +</para> +<informaltable><tgroup cols="2"><tbody><row><entry + align="char"> +<para>0</para> +</entry><entry + align="char"> +<para>The function was completed without errors.</para> +</entry> + </row><row><entry + align="char"> +<para>-EBUSY</para> +</entry><entry + align="char"> +<para>No more TS feeds available.</para> +</entry> + </row><row><entry + align="char"> +<para>-ENOSYS</para> +</entry><entry + align="char"> +<para>The command is not implemented.</para> +</entry> + </row><row><entry + align="char"> +<para>-EINVAL</para> +</entry><entry + align="char"> +<para>Bad parameter.</para> +</entry> + </row></tbody></tgroup></informaltable> + +</section><section +role="subsection"><title>release_ts_feed()</title> +<para>DESCRIPTION +</para> +<informaltable><tgroup cols="1"><tbody><row><entry + align="char"> +<para>Releases the resources allocated with allocate_ts_feed(). Any filtering in + progress on the TS feed should be stopped before calling this function.</para> +</entry> + </row></tbody></tgroup></informaltable> +<para>SYNOPSIS +</para> +<informaltable><tgroup cols="1"><tbody><row><entry + align="char"> +<para>int release_ts_feed(dmx_demux_t⋆ demux, + dmx_ts_feed_t⋆ feed);</para> +</entry> + </row></tbody></tgroup></informaltable> +<para>PARAMETERS +</para> +<informaltable><tgroup cols="2"><tbody><row><entry + align="char"> +<para>demux_t* demux</para> +</entry><entry + align="char"> +<para>Pointer to the demux API and instance data.</para> +</entry> + </row><row><entry + align="char"> +<para>dmx_ts_feed_t* feed</para> +</entry><entry + align="char"> +<para>Pointer to the TS feed API and instance data.</para> +</entry> + </row></tbody></tgroup></informaltable> +<para>RETURNS +</para> +<informaltable><tgroup cols="2"><tbody><row><entry + align="char"> +<para>0</para> +</entry><entry + align="char"> +<para>The function was completed without errors.</para> +</entry> + </row><row><entry + align="char"> +<para>-EINVAL</para> +</entry><entry + align="char"> +<para>Bad parameter.</para> +</entry> + </row></tbody></tgroup></informaltable> + +</section><section +role="subsection"><title>allocate_section_feed()</title> +<para>DESCRIPTION +</para> +<informaltable><tgroup cols="1"><tbody><row><entry + align="char"> +<para>Allocates a new section feed, i.e. a demux resource for filtering and receiving + sections. On platforms with hardware support for section filtering, a section + feed is directly mapped to the demux HW. On other platforms, TS packets are + first PID filtered in hardware and a hardware section filter then emulated in + software. The caller obtains an API pointer of type dmx_section_feed_t as an + out parameter. Using this API the caller can set filtering parameters and start + receiving sections.</para> +</entry> + </row></tbody></tgroup></informaltable> +<para>SYNOPSIS +</para> +<informaltable><tgroup cols="1"><tbody><row><entry + align="char"> +<para>int allocate_section_feed(dmx_demux_t⋆ demux, + dmx_section_feed_t ⋆⋆feed, dmx_section_cb callback);</para> +</entry> + </row></tbody></tgroup></informaltable> +<para>PARAMETERS +</para> +<informaltable><tgroup cols="2"><tbody><row><entry + align="char"> +<para>demux_t *demux</para> +</entry><entry + align="char"> +<para>Pointer to the demux API and instance data.</para> +</entry> + </row><row><entry + align="char"> +<para>dmx_section_feed_t + **feed</para> +</entry><entry + align="char"> +<para>Pointer to the section feed API and instance data.</para> +</entry> + </row><row><entry + align="char"> +<para>dmx_section_cb + callback</para> +</entry><entry + align="char"> +<para>Pointer to the callback function for passing received + sections.</para> +</entry> + </row></tbody></tgroup></informaltable> +<para>RETURNS +</para> +<informaltable><tgroup cols="2"><tbody><row><entry + align="char"> +<para>0</para> +</entry><entry + align="char"> +<para>The function was completed without errors.</para> +</entry> + </row><row><entry + align="char"> +<para>-EBUSY</para> +</entry><entry + align="char"> +<para>No more section feeds available.</para> +</entry> + </row><row><entry + align="char"> +<para>-ENOSYS</para> +</entry><entry + align="char"> +<para>The command is not implemented.</para> +</entry> + </row><row><entry + align="char"> +<para>-EINVAL</para> +</entry><entry + align="char"> +<para>Bad parameter.</para> +</entry> + </row></tbody></tgroup></informaltable> + +</section><section +role="subsection"><title>release_section_feed()</title> +<para>DESCRIPTION +</para> +<informaltable><tgroup cols="1"><tbody><row><entry + align="char"> +<para>Releases the resources allocated with allocate_section_feed(), including + allocated filters. Any filtering in progress on the section feed should be stopped + before calling this function.</para> +</entry> + </row></tbody></tgroup></informaltable> +<para>SYNOPSIS +</para> +<informaltable><tgroup cols="1"><tbody><row><entry + align="char"> +<para>int release_section_feed(dmx_demux_t⋆ demux, + dmx_section_feed_t ⋆feed);</para> +</entry> + </row></tbody></tgroup></informaltable> +<para>PARAMETERS +</para> +<informaltable><tgroup cols="2"><tbody><row><entry + align="char"> +<para>demux_t *demux</para> +</entry><entry + align="char"> +<para>Pointer to the demux API and instance data.</para> +</entry> + </row><row><entry + align="char"> +<para>dmx_section_feed_t + *feed</para> +</entry><entry + align="char"> +<para>Pointer to the section feed API and instance data.</para> +</entry> + </row></tbody></tgroup></informaltable> +<para>RETURNS +</para> +<informaltable><tgroup cols="2"><tbody><row><entry + align="char"> +<para>0</para> +</entry><entry + align="char"> +<para>The function was completed without errors.</para> +</entry> + </row><row><entry + align="char"> +<para>-EINVAL</para> +</entry><entry + align="char"> +<para>Bad parameter.</para> +</entry> + </row></tbody></tgroup></informaltable> + +</section><section +role="subsection"><title>descramble_mac_address()</title> +<para>DESCRIPTION +</para> +<informaltable><tgroup cols="1"><tbody><row><entry + align="char"> +<para>This function runs a descrambling algorithm on the destination MAC + address field of a DVB Datagram Section, replacing the original address + with its un-encrypted version. Otherwise, the description on the function + descramble_section_payload() applies also to this function.</para> +</entry> + </row></tbody></tgroup></informaltable> +<para>SYNOPSIS +</para> +<informaltable><tgroup cols="1"><tbody><row><entry + align="char"> +<para>int descramble_mac_address(dmx_demux_t⋆ demux, __u8 + ⋆buffer1, size_t buffer1_length, __u8 ⋆buffer2, + size_t buffer2_length, __u16 pid);</para> +</entry> + </row></tbody></tgroup></informaltable> +<para>PARAMETERS +</para> +<informaltable><tgroup cols="2"><tbody><row><entry + align="char"> +<para>dmx_demux_t + *demux</para> +</entry><entry + align="char"> +<para>Pointer to the demux API and instance data.</para> +</entry> + </row><row><entry + align="char"> +<para>__u8 *buffer1</para> +</entry><entry + align="char"> +<para>Pointer to the first byte of the section.</para> +</entry> + </row><row><entry + align="char"> +<para>size_t buffer1_length</para> +</entry><entry + align="char"> +<para>Length of the section data, including headers and CRC, + in buffer1.</para> +</entry> + </row><row><entry + align="char"> +<para>__u8* buffer2</para> +</entry><entry + align="char"> +<para>Pointer to the tail of the section data, or NULL. The + pointer has a non-NULL value if the section wraps past + the end of a circular buffer.</para> +</entry> + </row><row><entry + align="char"> +<para>size_t buffer2_length</para> +</entry><entry + align="char"> +<para>Length of the section data, including headers and CRC, + in buffer2.</para> +</entry> + </row><row><entry + align="char"> +<para>__u16 pid</para> +</entry><entry + align="char"> +<para>The PID on which the section was received. Useful + for obtaining the descrambling key, e.g. from a DVB + Common Access facility.</para> +</entry> + </row></tbody></tgroup></informaltable> +<para>RETURNS +</para> +<informaltable><tgroup cols="2"><tbody><row><entry + align="char"> +<para>0</para> +</entry><entry + align="char"> +<para>The function was completed without errors.</para> +</entry> + </row><row><entry + align="char"> +<para>-ENOSYS</para> +</entry><entry + align="char"> +<para>No descrambling facility available.</para> +</entry> + </row><row><entry + align="char"> +<para>-EINVAL</para> +</entry><entry + align="char"> +<para>Bad parameter.</para> +</entry> + </row></tbody></tgroup></informaltable> + +</section><section +role="subsection"><title>descramble_section_payload()</title> +<para>DESCRIPTION +</para> +<informaltable><tgroup cols="1"><tbody><row><entry + align="char"> +<para>This function runs a descrambling algorithm on the payload of a DVB + Datagram Section, replacing the original payload with its un-encrypted + version. The function will be called from the demux API implementation; + the API client need not call this function directly. Section-level scrambling + algorithms are currently standardized only for DVB-RCC (return channel + over 2-directional cable TV network) systems. For all other DVB networks, + encryption schemes are likely to be proprietary to each data broadcaster. Thus, + it is expected that this function pointer will have the value of NULL (i.e., + function not available) in most demux API implementations. Nevertheless, it + should be possible to use the function pointer as a hook for dynamically adding + a “plug-in” descrambling facility to a demux driver.</para> +</entry> + </row><row><entry + align="char"> +<para>While this function is not needed with hardware-based section descrambling, + the descramble_section_payload function pointer can be used to override the + default hardware-based descrambling algorithm: if the function pointer has a + non-NULL value, the corresponding function should be used instead of any + descrambling hardware.</para> +</entry> + </row></tbody></tgroup></informaltable> +<para>SYNOPSIS +</para> +<informaltable><tgroup cols="1"><tbody><row><entry + align="char"> +<para>int descramble_section_payload(dmx_demux_t⋆ demux, + __u8 ⋆buffer1, size_t buffer1_length, __u8 ⋆buffer2, + size_t buffer2_length, __u16 pid);</para> +</entry> + </row></tbody></tgroup></informaltable> +<para>PARAMETERS +</para> +<informaltable><tgroup cols="2"><tbody><row><entry + align="char"> +<para>dmx_demux_t + *demux</para> +</entry><entry + align="char"> +<para>Pointer to the demux API and instance data.</para> +</entry> + </row><row><entry + align="char"> +<para>__u8 *buffer1</para> +</entry><entry + align="char"> +<para>Pointer to the first byte of the section.</para> +</entry> + </row><row><entry + align="char"> +<para>size_t buffer1_length</para> +</entry><entry + align="char"> +<para>Length of the section data, including headers and CRC, + in buffer1.</para> +</entry> + </row><row><entry + align="char"> +<para>__u8 *buffer2</para> +</entry><entry + align="char"> +<para>Pointer to the tail of the section data, or NULL. The + pointer has a non-NULL value if the section wraps past + the end of a circular buffer.</para> +</entry> + </row><row><entry + align="char"> +<para>size_t buffer2_length</para> +</entry><entry + align="char"> +<para>Length of the section data, including headers and CRC, + in buffer2.</para> +</entry> + </row><row><entry + align="char"> +<para>__u16 pid</para> +</entry><entry + align="char"> +<para>The PID on which the section was received. Useful + for obtaining the descrambling key, e.g. from a DVB + Common Access facility.</para> +</entry> + </row></tbody></tgroup></informaltable> +<para>RETURNS +</para> +<informaltable><tgroup cols="2"><tbody><row><entry + align="char"> +<para>0</para> +</entry><entry + align="char"> +<para>The function was completed without errors.</para> +</entry> + </row><row><entry + align="char"> +<para>-ENOSYS</para> +</entry><entry + align="char"> +<para>No descrambling facility available.</para> +</entry> + </row><row><entry + align="char"> +<para>-EINVAL</para> +</entry><entry + align="char"> +<para>Bad parameter.</para> +</entry> + </row></tbody></tgroup></informaltable> + +</section><section +role="subsection"><title>add_frontend()</title> +<para>DESCRIPTION +</para> +<informaltable><tgroup cols="1"><tbody><row><entry + align="char"> +<para>Registers a connectivity between a demux and a front-end, i.e., indicates that + the demux can be connected via a call to connect_frontend() to use the given + front-end as a TS source. The client of this function has to allocate dynamic or + static memory for the frontend structure and initialize its fields before calling + this function. This function is normally called during the driver initialization. + The caller must not free the memory of the frontend struct before successfully + calling remove_frontend().</para> +</entry> + </row></tbody></tgroup></informaltable> +<para>SYNOPSIS +</para> +<informaltable><tgroup cols="1"><tbody><row><entry + align="char"> +<para>int add_frontend(dmx_demux_t ⋆demux, dmx_frontend_t + ⋆frontend);</para> +</entry> + </row></tbody></tgroup></informaltable> +<para>PARAMETERS +</para> +<informaltable><tgroup cols="2"><tbody><row><entry + align="char"> +<para>dmx_demux_t* + demux</para> +</entry><entry + align="char"> +<para>Pointer to the demux API and instance data.</para> +</entry> + </row><row><entry + align="char"> +<para>dmx_frontend_t* + frontend</para> +</entry><entry + align="char"> +<para>Pointer to the front-end instance data.</para> +</entry> + </row></tbody></tgroup></informaltable> +<para>RETURNS +</para> +<informaltable><tgroup cols="2"><tbody><row><entry + align="char"> +<para>0</para> +</entry><entry + align="char"> +<para>The function was completed without errors.</para> +</entry> + </row><row><entry + align="char"> +<para>-EEXIST</para> +</entry><entry + align="char"> +<para>A front-end with the same value of the id field already + registered.</para> +</entry> + </row><row><entry + align="char"> +<para>-EINUSE</para> +</entry><entry + align="char"> +<para>The demux is in use.</para> +</entry> + </row><row><entry + align="char"> +<para>-ENOMEM</para> +</entry><entry + align="char"> +<para>No more front-ends can be added.</para> +</entry> + </row><row><entry + align="char"> +<para>-EINVAL</para> +</entry><entry + align="char"> +<para>Bad parameter.</para> +</entry> + </row></tbody></tgroup></informaltable> + +</section><section +role="subsection"><title>remove_frontend()</title> +<para>DESCRIPTION +</para> +<informaltable><tgroup cols="1"><tbody><row><entry + align="char"> +<para>Indicates that the given front-end, registered by a call to add_frontend(), can + no longer be connected as a TS source by this demux. The function should be + called when a front-end driver or a demux driver is removed from the system. + If the front-end is in use, the function fails with the return value of -EBUSY. + After successfully calling this function, the caller can free the memory of + the frontend struct if it was dynamically allocated before the add_frontend() + operation.</para> +</entry> + </row></tbody></tgroup></informaltable> +<para>SYNOPSIS +</para> +<informaltable><tgroup cols="1"><tbody><row><entry + align="char"> +<para>int remove_frontend(dmx_demux_t⋆ demux, + dmx_frontend_t⋆ frontend);</para> +</entry> + </row></tbody></tgroup></informaltable> +<para>PARAMETERS +</para> +<informaltable><tgroup cols="2"><tbody><row><entry + align="char"> +<para>dmx_demux_t* + demux</para> +</entry><entry + align="char"> +<para>Pointer to the demux API and instance data.</para> +</entry> + </row><row><entry + align="char"> +<para>dmx_frontend_t* + frontend</para> +</entry><entry + align="char"> +<para>Pointer to the front-end instance data.</para> +</entry> + </row></tbody></tgroup></informaltable> +<para>RETURNS +</para> +<informaltable><tgroup cols="2"><tbody><row><entry + align="char"> +<para>0</para> +</entry><entry + align="char"> +<para>The function was completed without errors.</para> +</entry> + </row><row><entry + align="char"> +<para>-EINVAL</para> +</entry><entry + align="char"> +<para>Bad parameter.</para> +</entry> + </row><row><entry + align="char"> +<para>-EBUSY</para> +</entry><entry + align="char"> +<para>The front-end is in use, i.e. a call to connect_frontend() + has not been followed by a call to disconnect_frontend().</para> +</entry> + </row></tbody></tgroup></informaltable> + +</section><section +role="subsection"><title>get_frontends()</title> +<para>DESCRIPTION +</para> +<informaltable><tgroup cols="1"><tbody><row><entry + align="char"> +<para>Provides the APIs of the front-ends that have been registered for this demux. + Any of the front-ends obtained with this call can be used as a parameter for + connect_frontend().</para> +</entry> + </row><row><entry + align="char"> +<para>The include file demux.h contains the macro DMX_FE_ENTRY() for + converting an element of the generic type struct list_head* to the type + dmx_frontend_t*. The caller must not free the memory of any of the elements + obtained via this function call.</para> +</entry> + </row></tbody></tgroup></informaltable> +<para>SYNOPSIS +</para> +<informaltable><tgroup cols="1"><tbody><row><entry + align="char"> +<para>struct list_head⋆ get_frontends(dmx_demux_t⋆ demux);</para> +</entry> + </row></tbody></tgroup></informaltable> +<para>PARAMETERS +</para> +<informaltable><tgroup cols="2"><tbody><row><entry + align="char"> +<para>dmx_demux_t* + demux</para> +</entry><entry + align="char"> +<para>Pointer to the demux API and instance data.</para> +</entry> + </row></tbody></tgroup></informaltable> +<para>RETURNS +</para> +<informaltable><tgroup cols="2"><tbody><row><entry + align="char"> +<para>dmx_demux_t*</para> +</entry><entry + align="char"> +<para>A list of front-end interfaces, or NULL in the case of an + empty list.</para> +</entry> + </row></tbody></tgroup></informaltable> + +</section><section +role="subsection"><title>connect_frontend()</title> +<para>DESCRIPTION +</para> +<informaltable><tgroup cols="1"><tbody><row><entry + align="char"> +<para>Connects the TS output of the front-end to the input of the demux. A demux + can only be connected to a front-end registered to the demux with the function + add_frontend().</para> +</entry> + </row><row><entry + align="char"> +<para>It may or may not be possible to connect multiple demuxes to the same + front-end, depending on the capabilities of the HW platform. When not used, + the front-end should be released by calling disconnect_frontend().</para> +</entry> + </row></tbody></tgroup></informaltable> +<para>SYNOPSIS +</para> +<informaltable><tgroup cols="1"><tbody><row><entry + align="char"> +<para>int connect_frontend(dmx_demux_t⋆ demux, + dmx_frontend_t⋆ frontend);</para> +</entry> + </row></tbody></tgroup></informaltable> +<para>PARAMETERS +</para> +<informaltable><tgroup cols="2"><tbody><row><entry + align="char"> +<para>dmx_demux_t* + demux</para> +</entry><entry + align="char"> +<para>Pointer to the demux API and instance data.</para> +</entry> + </row><row><entry + align="char"> +<para>dmx_frontend_t* + frontend</para> +</entry><entry + align="char"> +<para>Pointer to the front-end instance data.</para> +</entry> + </row></tbody></tgroup></informaltable> +<para>RETURNS +</para> +<informaltable><tgroup cols="2"><tbody><row><entry + align="char"> +<para>0</para> +</entry><entry + align="char"> +<para>The function was completed without errors.</para> +</entry> + </row><row><entry + align="char"> +<para>-EINVAL</para> +</entry><entry + align="char"> +<para>Bad parameter.</para> +</entry> + </row><row><entry + align="char"> +<para>-EBUSY</para> +</entry><entry + align="char"> +<para>The front-end is in use.</para> +</entry> + </row></tbody></tgroup></informaltable> + +</section><section +role="subsection"><title>disconnect_frontend()</title> +<para>DESCRIPTION +</para> +<informaltable><tgroup cols="1"><tbody><row><entry + align="char"> +<para>Disconnects the demux and a front-end previously connected by a + connect_frontend() call.</para> +</entry> + </row></tbody></tgroup></informaltable> +<para>SYNOPSIS +</para> +<informaltable><tgroup cols="1"><tbody><row><entry + align="char"> +<para>int disconnect_frontend(dmx_demux_t⋆ demux);</para> +</entry> + </row></tbody></tgroup></informaltable> +<para>PARAMETERS +</para> +<informaltable><tgroup cols="2"><tbody><row><entry + align="char"> +<para>dmx_demux_t* + demux</para> +</entry><entry + align="char"> +<para>Pointer to the demux API and instance data.</para> +</entry> + </row></tbody></tgroup></informaltable> +<para>RETURNS +</para> +<informaltable><tgroup cols="2"><tbody><row><entry + align="char"> +<para>0</para> +</entry><entry + align="char"> +<para>The function was completed without errors.</para> +</entry> + </row><row><entry + align="char"> +<para>-EINVAL</para> +</entry><entry + align="char"> +<para>Bad parameter.</para> +</entry> + </row></tbody></tgroup></informaltable> + </section></section> +<section id="demux_callback_api"> +<title>Demux Callback API</title> +<para>This kernel-space API comprises the callback functions that deliver filtered data to the +demux client. Unlike the other APIs, these API functions are provided by the client and called +from the demux code. +</para> +<para>The function pointers of this abstract interface are not packed into a structure as in the +other demux APIs, because the callback functions are registered and used independent +of each other. As an example, it is possible for the API client to provide several +callback functions for receiving TS packets and no callbacks for PES packets or +sections. +</para> +<para>The functions that implement the callback API need not be re-entrant: when a demux +driver calls one of these functions, the driver is not allowed to call the function again before +the original call returns. If a callback is triggered by a hardware interrupt, it is recommended +to use the Linux “bottom half” mechanism or start a tasklet instead of making the callback +function call directly from a hardware interrupt. +</para> + +<section +role="subsection"><title>dmx_ts_cb()</title> +<para>DESCRIPTION +</para> +<informaltable><tgroup cols="1"><tbody><row><entry + align="char"> +<para>This function, provided by the client of the demux API, is called from the + demux code. The function is only called when filtering on this TS feed has + been enabled using the start_filtering() function.</para> +</entry> + </row><row><entry + align="char"> +<para>Any TS packets that match the filter settings are copied to a circular buffer. The + filtered TS packets are delivered to the client using this callback function. The + size of the circular buffer is controlled by the circular_buffer_size parameter + of the set() function in the TS Feed API. It is expected that the buffer1 and + buffer2 callback parameters point to addresses within the circular buffer, but + other implementations are also possible. Note that the called party should not + try to free the memory the buffer1 and buffer2 parameters point to.</para> +</entry> + </row><row><entry + align="char"> +<para>When this function is called, the buffer1 parameter typically points to the + start of the first undelivered TS packet within a circular buffer. The buffer2 + buffer parameter is normally NULL, except when the received TS packets have + crossed the last address of the circular buffer and ”wrapped” to the beginning + of the buffer. In the latter case the buffer1 parameter would contain an address + within the circular buffer, while the buffer2 parameter would contain the first + address of the circular buffer.</para> +</entry> + </row><row><entry + align="char"> +<para>The number of bytes delivered with this function (i.e. buffer1_length + + buffer2_length) is usually equal to the value of callback_length parameter + given in the set() function, with one exception: if a timeout occurs before + receiving callback_length bytes of TS data, any undelivered packets are + immediately delivered to the client by calling this function. The timeout + duration is controlled by the set() function in the TS Feed API.</para> +</entry> + </row><row><entry + align="char"> +<para>If a TS packet is received with errors that could not be fixed by the TS-level + forward error correction (FEC), the Transport_error_indicator flag of the TS + packet header should be set. The TS packet should not be discarded, as + the error can possibly be corrected by a higher layer protocol. If the called + party is slow in processing the callback, it is possible that the circular buffer + eventually fills up. If this happens, the demux driver should discard any TS + packets received while the buffer is full. The error should be indicated to the + client on the next callback by setting the success parameter to the value of + DMX_OVERRUN_ERROR.</para> +</entry> + </row><row><entry + align="char"> +<para>The type of data returned to the callback can be selected by the new + function int (*set_type) (struct dmx_ts_feed_s* feed, int type, dmx_ts_pes_t + pes_type) which is part of the dmx_ts_feed_s struct (also cf. to the + include file ost/demux.h) The type parameter decides if the raw TS packet + (TS_PACKET) or just the payload (TS_PACKET—TS_PAYLOAD_ONLY) + should be returned. If additionally the TS_DECODER bit is set the stream + will also be sent to the hardware MPEG decoder. In this case, the second + flag decides as what kind of data the stream should be interpreted. The + possible choices are one of DMX_TS_PES_AUDIO, DMX_TS_PES_VIDEO, + DMX_TS_PES_TELETEXT, DMX_TS_PES_SUBTITLE, + DMX_TS_PES_PCR, or DMX_TS_PES_OTHER.</para> +</entry> + </row></tbody></tgroup></informaltable> +<para>SYNOPSIS +</para> +<informaltable><tgroup cols="1"><tbody><row><entry + align="char"> +<para>int dmx_ts_cb(__u8⋆ buffer1, size_t buffer1_length, + __u8⋆ buffer2, size_t buffer2_length, dmx_ts_feed_t⋆ + source, dmx_success_t success);</para> +</entry> + </row></tbody></tgroup></informaltable> +<para>PARAMETERS +</para> +<informaltable><tgroup cols="2"><tbody><row><entry + align="char"> +<para>__u8* buffer1</para> +</entry><entry + align="char"> +<para>Pointer to the start of the filtered TS packets.</para> +</entry> + </row><row><entry + align="char"> +<para>size_t buffer1_length</para> +</entry><entry + align="char"> +<para>Length of the TS data in buffer1.</para> +</entry> + </row><row><entry + align="char"> +<para>__u8* buffer2</para> +</entry><entry + align="char"> +<para>Pointer to the tail of the filtered TS packets, or NULL.</para> +</entry> + </row><row><entry + align="char"> +<para>size_t buffer2_length</para> +</entry><entry + align="char"> +<para>Length of the TS data in buffer2.</para> +</entry> + </row><row><entry + align="char"> +<para>dmx_ts_feed_t* + source</para> +</entry><entry + align="char"> +<para>Indicates which TS feed is the source of the callback.</para> +</entry> + </row><row><entry + align="char"> +<para>dmx_success_t + success</para> +</entry><entry + align="char"> +<para>Indicates if there was an error in TS reception.</para> +</entry> + </row></tbody></tgroup></informaltable> +<para>RETURNS +</para> +<informaltable><tgroup cols="2"><tbody><row><entry + align="char"> +<para>0</para> +</entry><entry + align="char"> +<para>Continue filtering.</para> +</entry> + </row><row><entry + align="char"> +<para>-1</para> +</entry><entry + align="char"> +<para>Stop filtering - has the same effect as a call to + stop_filtering() on the TS Feed API.</para> +</entry> + </row></tbody></tgroup></informaltable> + +</section><section +role="subsection"><title>dmx_section_cb()</title> +<para>DESCRIPTION +</para> +<informaltable><tgroup cols="1"><tbody><row><entry + align="char"> +<para>This function, provided by the client of the demux API, is called from the + demux code. The function is only called when filtering of sections has been + enabled using the function start_filtering() of the section feed API. When the + demux driver has received a complete section that matches at least one section + filter, the client is notified via this callback function. Normally this function is + called for each received section; however, it is also possible to deliver multiple + sections with one callback, for example when the system load is high. If an + error occurs while receiving a section, this function should be called with + the corresponding error type set in the success field, whether or not there is + data to deliver. The Section Feed implementation should maintain a circular + buffer for received sections. However, this is not necessary if the Section Feed + API is implemented as a client of the TS Feed API, because the TS Feed + implementation then buffers the received data. The size of the circular buffer + can be configured using the set() function in the Section Feed API. If there + is no room in the circular buffer when a new section is received, the section + must be discarded. If this happens, the value of the success parameter should + be DMX_OVERRUN_ERROR on the next callback.</para> +</entry> + </row></tbody></tgroup></informaltable> +<para>SYNOPSIS +</para> +<informaltable><tgroup cols="1"><tbody><row><entry + align="char"> +<para>int dmx_section_cb(__u8⋆ buffer1, size_t + buffer1_length, __u8⋆ buffer2, size_t + buffer2_length, dmx_section_filter_t⋆ source, + dmx_success_t success);</para> +</entry> + </row></tbody></tgroup></informaltable> +<para>PARAMETERS +</para> +<informaltable><tgroup cols="2"><tbody><row><entry + align="char"> +<para>__u8* buffer1</para> +</entry><entry + align="char"> +<para>Pointer to the start of the filtered section, e.g. within the + circular buffer of the demux driver.</para> +</entry> + </row><row><entry + align="char"> +<para>size_t buffer1_length</para> +</entry><entry + align="char"> +<para>Length of the filtered section data in buffer1, including + headers and CRC.</para> +</entry> + </row><row><entry + align="char"> +<para>__u8* buffer2</para> +</entry><entry + align="char"> +<para>Pointer to the tail of the filtered section data, or NULL. + Useful to handle the wrapping of a circular buffer.</para> +</entry> + </row><row><entry + align="char"> +<para>size_t buffer2_length</para> +</entry><entry + align="char"> +<para>Length of the filtered section data in buffer2, including + headers and CRC.</para> +</entry> + </row><row><entry + align="char"> +<para>dmx_section_filter_t* + filter</para> +</entry><entry + align="char"> +<para>Indicates the filter that triggered the callback.</para> +</entry> + </row><row><entry + align="char"> +<para>dmx_success_t + success</para> +</entry><entry + align="char"> +<para>Indicates if there was an error in section reception.</para> +</entry> + </row></tbody></tgroup></informaltable> +<para>RETURNS +</para> +<informaltable><tgroup cols="2"><tbody><row><entry + align="char"> +<para>0</para> +</entry><entry + align="char"> +<para>Continue filtering.</para> +</entry> + </row><row><entry + align="char"> +<para>-1</para> +</entry><entry + align="char"> +<para>Stop filtering - has the same effect as a call to + stop_filtering() on the Section Feed API.</para> +</entry> + </row></tbody></tgroup></informaltable> + </section></section> +<section id="ts_feed_api"> +<title>TS Feed API</title> +<para>A TS feed is typically mapped to a hardware PID filter on the demux chip. +Using this API, the client can set the filtering properties to start/stop filtering TS +packets on a particular TS feed. The API is defined as an abstract interface of the type +dmx_ts_feed_t. +</para> +<para>The functions that implement the interface should be defined static or module private. The +client can get the handle of a TS feed API by calling the function allocate_ts_feed() in the +demux API. +</para> + +<section +role="subsection"><title>set()</title> +<para>DESCRIPTION +</para> +<informaltable><tgroup cols="1"><tbody><row><entry + align="char"> +<para>This function sets the parameters of a TS feed. Any filtering in progress on the + TS feed must be stopped before calling this function.</para> +</entry> + </row></tbody></tgroup></informaltable> +<para>SYNOPSIS +</para> +<informaltable><tgroup cols="1"><tbody><row><entry + align="char"> +<para>int set ( dmx_ts_feed_t⋆ feed, __u16 pid, size_t + callback_length, size_t circular_buffer_size, int + descramble, struct timespec timeout);</para> +</entry> + </row></tbody></tgroup></informaltable> +<para>PARAMETERS +</para> +<informaltable><tgroup cols="2"><tbody><row><entry + align="char"> +<para>dmx_ts_feed_t* feed</para> +</entry><entry + align="char"> +<para>Pointer to the TS feed API and instance data.</para> +</entry> + </row><row><entry + align="char"> +<para>__u16 pid</para> +</entry><entry + align="char"> +<para>PID value to filter. Only the TS packets carrying the + specified PID will be passed to the API client.</para> +</entry> + </row><row><entry + align="char"> +<para>size_t + callback_length</para> +</entry><entry + align="char"> +<para>Number of bytes to deliver with each call to the + dmx_ts_cb() callback function. The value of this + parameter should be a multiple of 188.</para> +</entry> + </row><row><entry + align="char"> +<para>size_t + circular_buffer_size</para> +</entry><entry + align="char"> +<para>Size of the circular buffer for the filtered TS packets.</para> +</entry> + </row><row><entry + align="char"> +<para>int descramble</para> +</entry><entry + align="char"> +<para>If non-zero, descramble the filtered TS packets.</para> +</entry> + </row><row><entry + align="char"> +<para>struct timespec + timeout</para> +</entry><entry + align="char"> +<para>Maximum time to wait before delivering received TS + packets to the client.</para> +</entry> + </row></tbody></tgroup></informaltable> +<para>RETURNS +</para> +<informaltable><tgroup cols="2"><tbody><row><entry + align="char"> +<para>0</para> +</entry><entry + align="char"> +<para>The function was completed without errors.</para> +</entry> + </row><row><entry + align="char"> +<para>-ENOMEM</para> +</entry><entry + align="char"> +<para>Not enough memory for the requested buffer size.</para> +</entry> + </row><row><entry + align="char"> +<para>-ENOSYS</para> +</entry><entry + align="char"> +<para>No descrambling facility available for TS.</para> +</entry> + </row><row><entry + align="char"> +<para>-EINVAL</para> +</entry><entry + align="char"> +<para>Bad parameter.</para> +</entry> + </row></tbody></tgroup></informaltable> + +</section><section +role="subsection"><title>start_filtering()</title> +<para>DESCRIPTION +</para> +<informaltable><tgroup cols="1"><tbody><row><entry + align="char"> +<para>Starts filtering TS packets on this TS feed, according to its settings. The PID + value to filter can be set by the API client. All matching TS packets are + delivered asynchronously to the client, using the callback function registered + with allocate_ts_feed().</para> +</entry> + </row></tbody></tgroup></informaltable> +<para>SYNOPSIS +</para> +<informaltable><tgroup cols="1"><tbody><row><entry + align="char"> +<para>int start_filtering(dmx_ts_feed_t⋆ feed);</para> +</entry> + </row></tbody></tgroup></informaltable> +<para>PARAMETERS +</para> +<informaltable><tgroup cols="2"><tbody><row><entry + align="char"> +<para>dmx_ts_feed_t* feed</para> +</entry><entry + align="char"> +<para>Pointer to the TS feed API and instance data.</para> +</entry> + </row></tbody></tgroup></informaltable> +<para>RETURNS +</para> +<informaltable><tgroup cols="2"><tbody><row><entry + align="char"> +<para>0</para> +</entry><entry + align="char"> +<para>The function was completed without errors.</para> +</entry> + </row><row><entry + align="char"> +<para>-EINVAL</para> +</entry><entry + align="char"> +<para>Bad parameter.</para> +</entry> + </row></tbody></tgroup></informaltable> + +</section><section +role="subsection"><title>stop_filtering()</title> +<para>DESCRIPTION +</para> +<informaltable><tgroup cols="1"><tbody><row><entry + align="char"> +<para>Stops filtering TS packets on this TS feed.</para> +</entry> + </row></tbody></tgroup></informaltable> +<para>SYNOPSIS +</para> +<informaltable><tgroup cols="1"><tbody><row><entry + align="char"> +<para>int stop_filtering(dmx_ts_feed_t⋆ feed);</para> +</entry> + </row></tbody></tgroup></informaltable> +<para>PARAMETERS +</para> +<informaltable><tgroup cols="2"><tbody><row><entry + align="char"> +<para>dmx_ts_feed_t* feed</para> +</entry><entry + align="char"> +<para>Pointer to the TS feed API and instance data.</para> +</entry> + </row></tbody></tgroup></informaltable> +<para>RETURNS +</para> +<informaltable><tgroup cols="2"><tbody><row><entry + align="char"> +<para>0</para> +</entry><entry + align="char"> +<para>The function was completed without errors.</para> +</entry> + </row><row><entry + align="char"> +<para>-EINVAL</para> +</entry><entry + align="char"> +<para>Bad parameter.</para> +</entry> + </row></tbody></tgroup></informaltable> + </section></section> +<section id="section_feed_api"> +<title>Section Feed API</title> +<para>A section feed is a resource consisting of a PID filter and a set of section filters. Using this +API, the client can set the properties of a section feed and to start/stop filtering. The API is +defined as an abstract interface of the type dmx_section_feed_t. The functions that implement +the interface should be defined static or module private. The client can get the handle of +a section feed API by calling the function allocate_section_feed() in the demux +API. +</para> +<para>On demux platforms that provide section filtering in hardware, the Section Feed API +implementation provides a software wrapper for the demux hardware. Other platforms may +support only PID filtering in hardware, requiring that TS packets are converted to sections in +software. In the latter case the Section Feed API implementation can be a client of the TS +Feed API. +</para> + +</section> +<section id="kdapi_set"> +<title>set()</title> +<para>DESCRIPTION +</para> +<informaltable><tgroup cols="1"><tbody><row><entry + align="char"> +<para>This function sets the parameters of a section feed. Any filtering in progress on + the section feed must be stopped before calling this function. If descrambling + is enabled, the payload_scrambling_control and address_scrambling_control + fields of received DVB datagram sections should be observed. If either one is + non-zero, the section should be descrambled either in hardware or using the + functions descramble_mac_address() and descramble_section_payload() of the + demux API. Note that according to the MPEG-2 Systems specification, only + the payloads of private sections can be scrambled while the rest of the section + data must be sent in the clear.</para> +</entry> + </row></tbody></tgroup></informaltable> +<para>SYNOPSIS +</para> +<informaltable><tgroup cols="1"><tbody><row><entry + align="char"> +<para>int set(dmx_section_feed_t⋆ feed, __u16 pid, size_t + circular_buffer_size, int descramble, int + check_crc);</para> +</entry> + </row></tbody></tgroup></informaltable> +<para>PARAMETERS +</para> +<informaltable><tgroup cols="2"><tbody><row><entry + align="char"> +<para>dmx_section_feed_t* + feed</para> +</entry><entry + align="char"> +<para>Pointer to the section feed API and instance data.</para> +</entry> + </row><row><entry + align="char"> +<para>__u16 pid</para> +</entry><entry + align="char"> +<para>PID value to filter; only the TS packets carrying the + specified PID will be accepted.</para> +</entry> + </row><row><entry + align="char"> +<para>size_t + circular_buffer_size</para> +</entry><entry + align="char"> +<para>Size of the circular buffer for filtered sections.</para> +</entry> + </row><row><entry + align="char"> +<para>int descramble</para> +</entry><entry + align="char"> +<para>If non-zero, descramble any sections that are scrambled.</para> +</entry> + </row><row><entry + align="char"> +<para>int check_crc</para> +</entry><entry + align="char"> +<para>If non-zero, check the CRC values of filtered sections.</para> +</entry> + </row></tbody></tgroup></informaltable> +<para>RETURNS +</para> +<informaltable><tgroup cols="2"><tbody><row><entry + align="char"> +<para>0</para> +</entry><entry + align="char"> +<para>The function was completed without errors.</para> +</entry> + </row><row><entry + align="char"> +<para>-ENOMEM</para> +</entry><entry + align="char"> +<para>Not enough memory for the requested buffer size.</para> +</entry> + </row><row><entry + align="char"> +<para>-ENOSYS</para> +</entry><entry + align="char"> +<para>No descrambling facility available for sections.</para> +</entry> + </row><row><entry + align="char"> +<para>-EINVAL</para> +</entry><entry + align="char"> +<para>Bad parameters.</para> +</entry> + </row></tbody></tgroup></informaltable> + +</section><section +role="subsection"><title>allocate_filter()</title> +<para>DESCRIPTION +</para> +<informaltable><tgroup cols="1"><tbody><row><entry + align="char"> +<para>This function is used to allocate a section filter on the demux. It should only be + called when no filtering is in progress on this section feed. If a filter cannot be + allocated, the function fails with -ENOSPC. See in section ?? for the format of + the section filter.</para> +</entry> + </row><row><entry + align="char"> +<para>The bitfields filter_mask and filter_value should only be modified when no + filtering is in progress on this section feed. filter_mask controls which bits of + filter_value are compared with the section headers/payload. On a binary value + of 1 in filter_mask, the corresponding bits are compared. The filter only accepts + sections that are equal to filter_value in all the tested bit positions. Any changes + to the values of filter_mask and filter_value are guaranteed to take effect only + when the start_filtering() function is called next time. The parent pointer in + the struct is initialized by the API implementation to the value of the feed + parameter. The priv pointer is not used by the API implementation, and can + thus be freely utilized by the caller of this function. Any data pointed to by the + priv pointer is available to the recipient of the dmx_section_cb() function call.</para> +</entry> + </row><row><entry + align="char"> +<para>While the maximum section filter length (DMX_MAX_FILTER_SIZE) is + currently set at 16 bytes, hardware filters of that size are not available on all + platforms. Therefore, section filtering will often take place first in hardware, + followed by filtering in software for the header bytes that were not covered + by a hardware filter. The filter_mask field can be checked to determine how + many bytes of the section filter are actually used, and if the hardware filter will + suffice. Additionally, software-only section filters can optionally be allocated + to clients when all hardware section filters are in use. Note that on most demux + hardware it is not possible to filter on the section_length field of the section + header – thus this field is ignored, even though it is included in filter_value and + filter_mask fields.</para> +</entry> + </row></tbody></tgroup></informaltable> +<para>SYNOPSIS +</para> +<informaltable><tgroup cols="1"><tbody><row><entry + align="char"> +<para>int allocate_filter(dmx_section_feed_t⋆ feed, + dmx_section_filter_t⋆⋆ filter);</para> +</entry> + </row></tbody></tgroup></informaltable> +<para>PARAMETERS +</para> +<informaltable><tgroup cols="2"><tbody><row><entry + align="char"> +<para>dmx_section_feed_t* + feed</para> +</entry><entry + align="char"> +<para>Pointer to the section feed API and instance data.</para> +</entry> + </row><row><entry + align="char"> +<para>dmx_section_filter_t** + filter</para> +</entry><entry + align="char"> +<para>Pointer to the allocated filter.</para> +</entry> + </row></tbody></tgroup></informaltable> +<para>RETURNS +</para> +<informaltable><tgroup cols="2"><tbody><row><entry + align="char"> +<para>0</para> +</entry><entry + align="char"> +<para>The function was completed without errors.</para> +</entry> + </row><row><entry + align="char"> +<para>-ENOSPC</para> +</entry><entry + align="char"> +<para>No filters of given type and length available.</para> +</entry> + </row><row><entry + align="char"> +<para>-EINVAL</para> +</entry><entry + align="char"> +<para>Bad parameters.</para> +</entry> + </row></tbody></tgroup></informaltable> + +</section><section +role="subsection"><title>release_filter()</title> +<para>DESCRIPTION +</para> +<informaltable><tgroup cols="1"><tbody><row><entry + align="char"> +<para>This function releases all the resources of a previously allocated section filter. + The function should not be called while filtering is in progress on this section + feed. After calling this function, the caller should not try to dereference the + filter pointer.</para> +</entry> + </row></tbody></tgroup></informaltable> +<para>SYNOPSIS +</para> +<informaltable><tgroup cols="1"><tbody><row><entry + align="char"> +<para>int release_filter ( dmx_section_feed_t⋆ feed, + dmx_section_filter_t⋆ filter);</para> +</entry> + </row></tbody></tgroup></informaltable> +<para>PARAMETERS +</para> +<informaltable><tgroup cols="2"><tbody><row><entry + align="char"> +<para>dmx_section_feed_t* + feed</para> +</entry><entry + align="char"> +<para>Pointer to the section feed API and instance data.</para> +</entry> + </row><row><entry + align="char"> +<para>dmx_section_filter_t* + filter</para> +</entry><entry + align="char"> +<para>I/O Pointer to the instance data of a section filter.</para> +</entry> + </row></tbody></tgroup></informaltable> +<para>RETURNS +</para> +<informaltable><tgroup cols="2"><tbody><row><entry + align="char"> +<para>0</para> +</entry><entry + align="char"> +<para>The function was completed without errors.</para> +</entry> + </row><row><entry + align="char"> +<para>-ENODEV</para> +</entry><entry + align="char"> +<para>No such filter allocated.</para> +</entry> + </row><row><entry + align="char"> +<para>-EINVAL</para> +</entry><entry + align="char"> +<para>Bad parameter.</para> +</entry> + </row></tbody></tgroup></informaltable> + +</section><section +role="subsection"><title>start_filtering()</title> +<para>DESCRIPTION +</para> +<informaltable><tgroup cols="1"><tbody><row><entry + align="char"> +<para>Starts filtering sections on this section feed, according to its settings. Sections + are first filtered based on their PID and then matched with the section + filters allocated for this feed. If the section matches the PID filter and + at least one section filter, it is delivered to the API client. The section + is delivered asynchronously using the callback function registered with + allocate_section_feed().</para> +</entry> + </row></tbody></tgroup></informaltable> +<para>SYNOPSIS +</para> +<informaltable><tgroup cols="1"><tbody><row><entry + align="char"> +<para>int start_filtering ( dmx_section_feed_t⋆ feed );</para> +</entry> + </row></tbody></tgroup></informaltable> +<para>PARAMETERS +</para> +<informaltable><tgroup cols="2"><tbody><row><entry + align="char"> +<para>dmx_section_feed_t* + feed</para> +</entry><entry + align="char"> +<para>Pointer to the section feed API and instance data.</para> +</entry> + </row></tbody></tgroup></informaltable> +<para>RETURNS +</para> +<informaltable><tgroup cols="2"><tbody><row><entry + align="char"> +<para>0</para> +</entry><entry + align="char"> +<para>The function was completed without errors.</para> +</entry> + </row><row><entry + align="char"> +<para>-EINVAL</para> +</entry><entry + align="char"> +<para>Bad parameter.</para> +</entry> + </row></tbody></tgroup></informaltable> + +</section><section +role="subsection"><title>stop_filtering()</title> +<para>DESCRIPTION +</para> +<informaltable><tgroup cols="1"><tbody><row><entry + align="char"> +<para>Stops filtering sections on this section feed. Note that any changes to the + filtering parameters (filter_value, filter_mask, etc.) should only be made when + filtering is stopped.</para> +</entry> + </row></tbody></tgroup></informaltable> +<para>SYNOPSIS +</para> +<informaltable><tgroup cols="1"><tbody><row><entry + align="char"> +<para>int stop_filtering ( dmx_section_feed_t⋆ feed );</para> +</entry> + </row></tbody></tgroup></informaltable> +<para>PARAMETERS +</para> +<informaltable><tgroup cols="2"><tbody><row><entry + align="char"> +<para>dmx_section_feed_t* + feed</para> +</entry><entry + align="char"> +<para>Pointer to the section feed API and instance data.</para> +</entry> + </row></tbody></tgroup></informaltable> +<para>RETURNS +</para> +<informaltable><tgroup cols="2"><tbody><row><entry + align="char"> +<para>0</para> +</entry><entry + align="char"> +<para>The function was completed without errors.</para> +</entry> + </row><row><entry + align="char"> +<para>-EINVAL</para> +</entry><entry + align="char"> +<para>Bad parameter.</para> +</entry> + </row></tbody></tgroup></informaltable> + +</section> diff --git a/Documentation/DocBook/dvb/net.xml b/Documentation/DocBook/dvb/net.xml new file mode 100644 index 000000000000..94e388d94c0d --- /dev/null +++ b/Documentation/DocBook/dvb/net.xml @@ -0,0 +1,12 @@ +<title>DVB Network API</title> +<para>The DVB net device enables feeding of MPE (multi protocol encapsulation) packets +received via DVB into the Linux network protocol stack, e.g. for internet via satellite +applications. It can be accessed through <emphasis role="tt">/dev/dvb/adapter0/net0</emphasis>. Data types and +and ioctl definitions can be accessed by including <emphasis role="tt">linux/dvb/net.h</emphasis> in your +application. +</para> +<section id="dvb_net_types"> +<title>DVB Net Data Types</title> +<para>To be written… +</para> +</section> diff --git a/Documentation/DocBook/dvb/video.xml b/Documentation/DocBook/dvb/video.xml new file mode 100644 index 000000000000..7bb287e67c8e --- /dev/null +++ b/Documentation/DocBook/dvb/video.xml @@ -0,0 +1,1971 @@ +<title>DVB Video Device</title> +<para>The DVB video device controls the MPEG2 video decoder of the DVB hardware. It +can be accessed through <emphasis role="tt">/dev/dvb/adapter0/video0</emphasis>. Data types and and +ioctl definitions can be accessed by including <emphasis role="tt">linux/dvb/video.h</emphasis> in your +application. +</para> +<para>Note that the DVB video device only controls decoding of the MPEG video stream, not +its presentation on the TV or computer screen. On PCs this is typically handled by an +associated video4linux device, e.g. <emphasis role="tt">/dev/video</emphasis>, which allows scaling and defining output +windows. +</para> +<para>Some DVB cards don’t have their own MPEG decoder, which results in the omission of +the audio and video device as well as the video4linux device. +</para> +<para>The ioctls that deal with SPUs (sub picture units) and navigation packets are only +supported on some MPEG decoders made for DVD playback. +</para> +<section id="video_types"> +<title>Video Data Types</title> + +<section id="video_format_t"> +<title>video_format_t</title> +<para>The <emphasis role="tt">video_format_t</emphasis> data type defined by +</para> +<programlisting> + typedef enum { + VIDEO_FORMAT_4_3, + VIDEO_FORMAT_16_9 + } video_format_t; +</programlisting> +<para>is used in the VIDEO_SET_FORMAT function (??) to tell the driver which aspect ratio +the output hardware (e.g. TV) has. It is also used in the data structures video_status +(??) returned by VIDEO_GET_STATUS (??) and video_event (??) returned by +VIDEO_GET_EVENT (??) which report about the display format of the current video +stream. +</para> +</section> + +<section id="video_display_format_t"> +<title>video_display_format_t</title> +<para>In case the display format of the video stream and of the display hardware differ the +application has to specify how to handle the cropping of the picture. This can be done using +the VIDEO_SET_DISPLAY_FORMAT call (??) which accepts +</para> +<programlisting> + typedef enum { + VIDEO_PAN_SCAN, + VIDEO_LETTER_BOX, + VIDEO_CENTER_CUT_OUT + } video_display_format_t; +</programlisting> +<para>as argument. +</para> +</section> + +<section id="video_stream_source"> +<title>video stream source</title> +<para>The video stream source is set through the VIDEO_SELECT_SOURCE call and can take +the following values, depending on whether we are replaying from an internal (demuxer) or +external (user write) source. +</para> +<programlisting> + typedef enum { + VIDEO_SOURCE_DEMUX, + VIDEO_SOURCE_MEMORY + } video_stream_source_t; +</programlisting> +<para>VIDEO_SOURCE_DEMUX selects the demultiplexer (fed either by the frontend or the +DVR device) as the source of the video stream. If VIDEO_SOURCE_MEMORY +is selected the stream comes from the application through the <emphasis role="tt">write()</emphasis> system +call. +</para> +</section> + +<section id="video_play_state"> +<title>video play state</title> +<para>The following values can be returned by the VIDEO_GET_STATUS call representing the +state of video playback. +</para> +<programlisting> + typedef enum { + VIDEO_STOPPED, + VIDEO_PLAYING, + VIDEO_FREEZED + } video_play_state_t; +</programlisting> +</section> + +<section id="video_event"> +<title>struct video_event</title> +<para>The following is the structure of a video event as it is returned by the VIDEO_GET_EVENT +call. +</para> +<programlisting> + struct video_event { + int32_t type; + time_t timestamp; + union { + video_format_t video_format; + } u; + }; +</programlisting> +</section> + +<section id="video_status"> +<title>struct video_status</title> +<para>The VIDEO_GET_STATUS call returns the following structure informing about various +states of the playback operation. +</para> +<programlisting> + struct video_status { + boolean video_blank; + video_play_state_t play_state; + video_stream_source_t stream_source; + video_format_t video_format; + video_displayformat_t display_format; + }; +</programlisting> +<para>If video_blank is set video will be blanked out if the channel is changed or if playback is +stopped. Otherwise, the last picture will be displayed. play_state indicates if the video is +currently frozen, stopped, or being played back. The stream_source corresponds to the seleted +source for the video stream. It can come either from the demultiplexer or from memory. +The video_format indicates the aspect ratio (one of 4:3 or 16:9) of the currently +played video stream. Finally, display_format corresponds to the selected cropping +mode in case the source video format is not the same as the format of the output +device. +</para> +</section> + +<section id="video_still_picture"> +<title>struct video_still_picture</title> +<para>An I-frame displayed via the VIDEO_STILLPICTURE call is passed on within the +following structure. +</para> +<programlisting> + /⋆ pointer to and size of a single iframe in memory ⋆/ + struct video_still_picture { + char ⋆iFrame; + int32_t size; + }; +</programlisting> +</section> + +<section id="video_caps"> +<title>video capabilities</title> +<para>A call to VIDEO_GET_CAPABILITIES returns an unsigned integer with the following +bits set according to the hardwares capabilities. +</para> +<programlisting> + /⋆ bit definitions for capabilities: ⋆/ + /⋆ can the hardware decode MPEG1 and/or MPEG2? ⋆/ + #define VIDEO_CAP_MPEG1 1 + #define VIDEO_CAP_MPEG2 2 + /⋆ can you send a system and/or program stream to video device? + (you still have to open the video and the audio device but only + send the stream to the video device) ⋆/ + #define VIDEO_CAP_SYS 4 + #define VIDEO_CAP_PROG 8 + /⋆ can the driver also handle SPU, NAVI and CSS encoded data? + (CSS API is not present yet) ⋆/ + #define VIDEO_CAP_SPU 16 + #define VIDEO_CAP_NAVI 32 + #define VIDEO_CAP_CSS 64 +</programlisting> +</section> + +<section id="video_system"> +<title>video system</title> +<para>A call to VIDEO_SET_SYSTEM sets the desired video system for TV output. The +following system types can be set: +</para> +<programlisting> + typedef enum { + VIDEO_SYSTEM_PAL, + VIDEO_SYSTEM_NTSC, + VIDEO_SYSTEM_PALN, + VIDEO_SYSTEM_PALNc, + VIDEO_SYSTEM_PALM, + VIDEO_SYSTEM_NTSC60, + VIDEO_SYSTEM_PAL60, + VIDEO_SYSTEM_PALM60 + } video_system_t; +</programlisting> +</section> + +<section id="video_highlight"> +<title>struct video_highlight</title> +<para>Calling the ioctl VIDEO_SET_HIGHLIGHTS posts the SPU highlight information. The +call expects the following format for that information: +</para> +<programlisting> + typedef + struct video_highlight { + boolean active; /⋆ 1=show highlight, 0=hide highlight ⋆/ + uint8_t contrast1; /⋆ 7- 4 Pattern pixel contrast ⋆/ + /⋆ 3- 0 Background pixel contrast ⋆/ + uint8_t contrast2; /⋆ 7- 4 Emphasis pixel-2 contrast ⋆/ + /⋆ 3- 0 Emphasis pixel-1 contrast ⋆/ + uint8_t color1; /⋆ 7- 4 Pattern pixel color ⋆/ + /⋆ 3- 0 Background pixel color ⋆/ + uint8_t color2; /⋆ 7- 4 Emphasis pixel-2 color ⋆/ + /⋆ 3- 0 Emphasis pixel-1 color ⋆/ + uint32_t ypos; /⋆ 23-22 auto action mode ⋆/ + /⋆ 21-12 start y ⋆/ + /⋆ 9- 0 end y ⋆/ + uint32_t xpos; /⋆ 23-22 button color number ⋆/ + /⋆ 21-12 start x ⋆/ + /⋆ 9- 0 end x ⋆/ + } video_highlight_t; +</programlisting> + +</section> +<section id="video_spu"> +<title>video SPU</title> +<para>Calling VIDEO_SET_SPU deactivates or activates SPU decoding, according to the +following format: +</para> +<programlisting> + typedef + struct video_spu { + boolean active; + int stream_id; + } video_spu_t; +</programlisting> + +</section> +<section id="video_spu_palette"> +<title>video SPU palette</title> +<para>The following structure is used to set the SPU palette by calling VIDEO_SPU_PALETTE: +</para> +<programlisting> + typedef + struct video_spu_palette{ + int length; + uint8_t ⋆palette; + } video_spu_palette_t; +</programlisting> + +</section> +<section id="video_navi_pack"> +<title>video NAVI pack</title> +<para>In order to get the navigational data the following structure has to be passed to the ioctl +VIDEO_GET_NAVI: +</para> +<programlisting> + typedef + struct video_navi_pack{ + int length; /⋆ 0 ... 1024 ⋆/ + uint8_t data[1024]; + } video_navi_pack_t; +</programlisting> +</section> + + +<section id="video_attributes"> +<title>video attributes</title> +<para>The following attributes can be set by a call to VIDEO_SET_ATTRIBUTES: +</para> +<programlisting> + typedef uint16_t video_attributes_t; + /⋆ bits: descr. ⋆/ + /⋆ 15-14 Video compression mode (0=MPEG-1, 1=MPEG-2) ⋆/ + /⋆ 13-12 TV system (0=525/60, 1=625/50) ⋆/ + /⋆ 11-10 Aspect ratio (0=4:3, 3=16:9) ⋆/ + /⋆ 9- 8 permitted display mode on 4:3 monitor (0=both, 1=only pan-sca ⋆/ + /⋆ 7 line 21-1 data present in GOP (1=yes, 0=no) ⋆/ + /⋆ 6 line 21-2 data present in GOP (1=yes, 0=no) ⋆/ + /⋆ 5- 3 source resolution (0=720x480/576, 1=704x480/576, 2=352x480/57 ⋆/ + /⋆ 2 source letterboxed (1=yes, 0=no) ⋆/ + /⋆ 0 film/camera mode (0=camera, 1=film (625/50 only)) ⋆/ +</programlisting> +</section></section> + + +<section id="video_function_calls"> +<title>Video Function Calls</title> + + +<section id="video_fopen"> +<title>open()</title> +<para>DESCRIPTION +</para> +<informaltable><tgroup cols="1"><tbody><row><entry + align="char"> +<para>This system call opens a named video device (e.g. /dev/dvb/adapter0/video0) + for subsequent use.</para> +<para>When an open() call has succeeded, the device will be ready for use. + The significance of blocking or non-blocking mode is described in the + documentation for functions where there is a difference. It does not affect the + semantics of the open() call itself. A device opened in blocking mode can later + be put into non-blocking mode (and vice versa) using the F_SETFL command + of the fcntl system call. This is a standard system call, documented in the Linux + manual page for fcntl. Only one user can open the Video Device in O_RDWR + mode. All other attempts to open the device in this mode will fail, and an + error-code will be returned. If the Video Device is opened in O_RDONLY + mode, the only ioctl call that can be used is VIDEO_GET_STATUS. All other + call will return an error code.</para> +</entry> + </row></tbody></tgroup></informaltable> + +<para>SYNOPSIS +</para> +<informaltable><tgroup cols="1"><tbody><row><entry + align="char"> +<para>int open(const char ⋆deviceName, int flags);</para> +</entry> + </row></tbody></tgroup></informaltable> +<para>PARAMETERS +</para> +<informaltable><tgroup cols="2"><tbody><row><entry + align="char"> +<para>const char + *deviceName</para> +</entry><entry + align="char"> +<para>Name of specific video device.</para> +</entry> + </row><row><entry + align="char"> +<para>int flags</para> +</entry><entry + align="char"> +<para>A bit-wise OR of the following flags:</para> +</entry> + </row><row><entry + align="char"> +</entry><entry + align="char"> +<para>O_RDONLY read-only access</para> +</entry> + </row><row><entry + align="char"> +</entry><entry + align="char"> +<para>O_RDWR read/write access</para> +</entry> + </row><row><entry + align="char"> +</entry><entry + align="char"> +<para>O_NONBLOCK open in non-blocking mode</para> +</entry> + </row><row><entry + align="char"> +</entry><entry + align="char"> +<para>(blocking mode is the default)</para> +</entry> + </row></tbody></tgroup></informaltable> +<para>ERRORS +</para> +<informaltable><tgroup cols="2"><tbody><row><entry + align="char"> +<para>ENODEV</para> +</entry><entry + align="char"> +<para>Device driver not loaded/available.</para> +</entry> + </row><row><entry + align="char"> +<para>EINTERNAL</para> +</entry><entry + align="char"> +<para>Internal error.</para> +</entry> + </row><row><entry + align="char"> +<para>EBUSY</para> +</entry><entry + align="char"> +<para>Device or resource busy.</para> +</entry> + </row><row><entry + align="char"> +<para>EINVAL</para> +</entry><entry + align="char"> +<para>Invalid argument.</para> +</entry> + </row></tbody></tgroup></informaltable> + +</section> +<section id="video_fclose"> +<title>close()</title> +<para>DESCRIPTION +</para> +<informaltable><tgroup cols="1"><tbody><row><entry + align="char"> +<para>This system call closes a previously opened video device.</para> +</entry> + </row></tbody></tgroup></informaltable> +<para>SYNOPSIS +</para> +<informaltable><tgroup cols="1"><tbody><row><entry + align="char"> +<para>int close(int fd);</para> +</entry> + </row></tbody></tgroup></informaltable> +<para>PARAMETERS +</para> +<informaltable><tgroup cols="2"><tbody><row><entry + align="char"> +<para>int fd</para> +</entry><entry + align="char"> +<para>File descriptor returned by a previous call to open().</para> +</entry> + </row></tbody></tgroup></informaltable> +<para>ERRORS +</para> +<informaltable><tgroup cols="2"><tbody><row><entry + align="char"> +<para>EBADF</para> +</entry><entry + align="char"> +<para>fd is not a valid open file descriptor.</para> +</entry> + </row></tbody></tgroup></informaltable> + +</section> +<section id="video_fwrite"> +<title>write()</title> +<para>DESCRIPTION +</para> +<informaltable><tgroup cols="1"><tbody><row><entry + align="char"> +<para>This system call can only be used if VIDEO_SOURCE_MEMORY is selected + in the ioctl call VIDEO_SELECT_SOURCE. The data provided shall be in + PES format, unless the capability allows other formats. If O_NONBLOCK is + not specified the function will block until buffer space is available. The amount + of data to be transferred is implied by count.</para> +</entry> + </row></tbody></tgroup></informaltable> +<para>SYNOPSIS +</para> +<informaltable><tgroup cols="1"><tbody><row><entry + align="char"> +<para>size_t write(int fd, const void ⋆buf, size_t count);</para> +</entry> + </row></tbody></tgroup></informaltable> +<para>PARAMETERS +</para> +<informaltable><tgroup cols="2"><tbody><row><entry + align="char"> +<para>int fd</para> +</entry><entry + align="char"> +<para>File descriptor returned by a previous call to open().</para> +</entry> + </row><row><entry + align="char"> +<para>void *buf</para> +</entry><entry + align="char"> +<para>Pointer to the buffer containing the PES data.</para> +</entry> + </row><row><entry + align="char"> +<para>size_t count</para> +</entry><entry + align="char"> +<para>Size of buf.</para> +</entry> + </row></tbody></tgroup></informaltable> +<para>ERRORS +</para> +<informaltable><tgroup cols="2"><tbody><row><entry + align="char"> +<para>EPERM</para> +</entry><entry + align="char"> +<para>Mode VIDEO_SOURCE_MEMORY not selected.</para> +</entry> + </row><row><entry + align="char"> +<para>ENOMEM</para> +</entry><entry + align="char"> +<para>Attempted to write more data than the internal buffer can + hold.</para> +</entry> + </row><row><entry + align="char"> +<para>EBADF</para> +</entry><entry + align="char"> +<para>fd is not a valid open file descriptor.</para> +</entry> + </row></tbody></tgroup></informaltable> + +</section><section +role="subsection"><title>VIDEO_STOP</title> +<para>DESCRIPTION +</para> +<informaltable><tgroup cols="1"><tbody><row><entry + align="char"> +<para>This ioctl call asks the Video Device to stop playing the current stream. + Depending on the input parameter, the screen can be blanked out or displaying + the last decoded frame.</para> +</entry> + </row></tbody></tgroup></informaltable> +<para>SYNOPSIS +</para> +<informaltable><tgroup cols="1"><tbody><row><entry + align="char"> +<para>int ioctl(fd, int request = VIDEO_STOP, boolean + mode);</para> +</entry> + </row></tbody></tgroup></informaltable> +<para>PARAMETERS +</para> +<informaltable><tgroup cols="2"><tbody><row><entry + align="char"> +<para>int fd</para> +</entry><entry + align="char"> +<para>File descriptor returned by a previous call to open().</para> +</entry> + </row><row><entry + align="char"> +<para>int request</para> +</entry><entry + align="char"> +<para>Equals VIDEO_STOP for this command.</para> +</entry> + </row><row><entry + align="char"> +<para>Boolean mode</para> +</entry><entry + align="char"> +<para>Indicates how the screen shall be handled.</para> +</entry> + </row><row><entry + align="char"> +</entry><entry + align="char"> +<para>TRUE: Blank screen when stop.</para> +</entry> + </row><row><entry + align="char"> +</entry><entry + align="char"> +<para>FALSE: Show last decoded frame.</para> +</entry> + </row></tbody></tgroup></informaltable> +<para>ERRORS +</para> +<informaltable><tgroup cols="2"><tbody><row><entry + align="char"> +<para>EBADF</para> +</entry><entry + align="char"> +<para>fd is not a valid open file descriptor</para> +</entry> + </row><row><entry + align="char"> +<para>EINTERNAL</para> +</entry><entry + align="char"> +<para>Internal error, possibly in the communication with the + DVB subsystem.</para> +</entry> + </row></tbody></tgroup></informaltable> + +</section><section +role="subsection"><title>VIDEO_PLAY</title> +<para>DESCRIPTION +</para> +<informaltable><tgroup cols="1"><tbody><row><entry + align="char"> +<para>This ioctl call asks the Video Device to start playing a video stream from the + selected source.</para> +</entry> + </row></tbody></tgroup></informaltable> +<para>SYNOPSIS +</para> +<informaltable><tgroup cols="1"><tbody><row><entry + align="char"> +<para>int ioctl(fd, int request = VIDEO_PLAY);</para> +</entry> + </row></tbody></tgroup></informaltable> +<para>PARAMETERS +</para> +<informaltable><tgroup cols="2"><tbody><row><entry + align="char"> +<para>int fd</para> +</entry><entry + align="char"> +<para>File descriptor returned by a previous call to open().</para> +</entry> + </row><row><entry + align="char"> +<para>int request</para> +</entry><entry + align="char"> +<para>Equals VIDEO_PLAY for this command.</para> +</entry> + </row></tbody></tgroup></informaltable> +<para>ERRORS +</para> +<informaltable><tgroup cols="2"><tbody><row><entry + align="char"> +<para>EBADF</para> +</entry><entry + align="char"> +<para>fd is not a valid open file descriptor</para> +</entry> + </row><row><entry + align="char"> +<para>EINTERNAL</para> +</entry><entry + align="char"> +<para>Internal error, possibly in the communication with the + DVB subsystem.</para> +</entry> + </row></tbody></tgroup></informaltable> + +</section><section +role="subsection"><title>VIDEO_FREEZE</title> +<para>DESCRIPTION +</para> +<informaltable><tgroup cols="1"><tbody><row><entry + align="char"> +<para>This ioctl call suspends the live video stream being played. Decoding + and playing are frozen. It is then possible to restart the decoding + and playing process of the video stream using the VIDEO_CONTINUE + command. If VIDEO_SOURCE_MEMORY is selected in the ioctl call + VIDEO_SELECT_SOURCE, the DVB subsystem will not decode any more + data until the ioctl call VIDEO_CONTINUE or VIDEO_PLAY is performed.</para> +</entry> + </row></tbody></tgroup></informaltable> +<para>SYNOPSIS +</para> +<informaltable><tgroup cols="1"><tbody><row><entry + align="char"> +<para>int ioctl(fd, int request = VIDEO_FREEZE);</para> +</entry> + </row></tbody></tgroup></informaltable> +<para>PARAMETERS +</para> +<informaltable><tgroup cols="2"><tbody><row><entry + align="char"> +<para>int fd</para> +</entry><entry + align="char"> +<para>File descriptor returned by a previous call to open().</para> +</entry> + </row><row><entry + align="char"> +<para>int request</para> +</entry><entry + align="char"> +<para>Equals VIDEO_FREEZE for this command.</para> +</entry> + </row></tbody></tgroup></informaltable> +<para>ERRORS +</para> +<informaltable><tgroup cols="2"><tbody><row><entry + align="char"> +<para>EBADF</para> +</entry><entry + align="char"> +<para>fd is not a valid open file descriptor</para> +</entry> + </row><row><entry + align="char"> +<para>EINTERNAL</para> +</entry><entry + align="char"> +<para>Internal error, possibly in the communication with the + DVB subsystem.</para> +</entry> + </row></tbody></tgroup></informaltable> + +</section><section +role="subsection"><title>VIDEO_CONTINUE</title> +<para>DESCRIPTION +</para> +<informaltable><tgroup cols="1"><tbody><row><entry + align="char"> +<para>This ioctl call restarts decoding and playing processes of the video stream + which was played before a call to VIDEO_FREEZE was made.</para> +</entry> + </row></tbody></tgroup></informaltable> +<para>SYNOPSIS +</para> +<informaltable><tgroup cols="1"><tbody><row><entry + align="char"> +<para>int ioctl(fd, int request = VIDEO_CONTINUE);</para> +</entry> + </row></tbody></tgroup></informaltable> +<para>PARAMETERS +</para> +<informaltable><tgroup cols="2"><tbody><row><entry + align="char"> +<para>int fd</para> +</entry><entry + align="char"> +<para>File descriptor returned by a previous call to open().</para> +</entry> + </row><row><entry + align="char"> +<para>int request</para> +</entry><entry + align="char"> +<para>Equals VIDEO_CONTINUE for this command.</para> +</entry> + </row></tbody></tgroup></informaltable> +<para>ERRORS +</para> +<informaltable><tgroup cols="2"><tbody><row><entry + align="char"> +<para>EBADF</para> +</entry><entry + align="char"> +<para>fd is not a valid open file descriptor</para> +</entry> + </row><row><entry + align="char"> +<para>EINTERNAL</para> +</entry><entry + align="char"> +<para>Internal error, possibly in the communication with the + DVB subsystem.</para> +</entry> + </row></tbody></tgroup></informaltable> + +</section><section +role="subsection"><title>VIDEO_SELECT_SOURCE</title> +<para>DESCRIPTION +</para> +<informaltable><tgroup cols="1"><tbody><row><entry + align="char"> +<para>This ioctl call informs the video device which source shall be used for the input + data. The possible sources are demux or memory. If memory is selected, the + data is fed to the video device through the write command.</para> +</entry> + </row></tbody></tgroup></informaltable> +<para>SYNOPSIS +</para> +<informaltable><tgroup cols="1"><tbody><row><entry + align="char"> +<para>int ioctl(fd, int request = VIDEO_SELECT_SOURCE, + video_stream_source_t source);</para> +</entry> + </row></tbody></tgroup></informaltable> +<para>PARAMETERS +</para> +<informaltable><tgroup cols="2"><tbody><row><entry + align="char"> +<para>int fd</para> +</entry><entry + align="char"> +<para>File descriptor returned by a previous call to open().</para> +</entry> + </row><row><entry + align="char"> +<para>int request</para> +</entry><entry + align="char"> +<para>Equals VIDEO_SELECT_SOURCE for this command.</para> +</entry> + </row><row><entry + align="char"> +<para>video_stream_source_t + source</para> +</entry><entry + align="char"> +<para>Indicates which source shall be used for the Video stream.</para> +</entry> + </row></tbody></tgroup></informaltable> +<para>ERRORS +</para> +<informaltable><tgroup cols="2"><tbody><row><entry + align="char"> +<para>EBADF</para> +</entry><entry + align="char"> +<para>fd is not a valid open file descriptor</para> +</entry> + </row><row><entry + align="char"> +<para>EINTERNAL</para> +</entry><entry + align="char"> +<para>Internal error, possibly in the communication with the + DVB subsystem.</para> +</entry> + </row></tbody></tgroup></informaltable> + +</section><section +role="subsection"><title>VIDEO_SET_BLANK</title> +<para>DESCRIPTION +</para> +<informaltable><tgroup cols="1"><tbody><row><entry + align="char"> +<para>This ioctl call asks the Video Device to blank out the picture.</para> +</entry> + </row></tbody></tgroup></informaltable> +<para>SYNOPSIS +</para> +<informaltable><tgroup cols="1"><tbody><row><entry + align="char"> +<para>int ioctl(fd, int request = VIDEO_SET_BLANK, boolean + mode);</para> +</entry> + </row></tbody></tgroup></informaltable> +<para>PARAMETERS +</para> +<informaltable><tgroup cols="2"><tbody><row><entry + align="char"> +<para>int fd</para> +</entry><entry + align="char"> +<para>File descriptor returned by a previous call to open().</para> +</entry> + </row><row><entry + align="char"> +<para>int request</para> +</entry><entry + align="char"> +<para>Equals VIDEO_SET_BLANK for this command.</para> +</entry> + </row><row><entry + align="char"> +<para>boolean mode</para> +</entry><entry + align="char"> +<para>TRUE: Blank screen when stop.</para> +</entry> + </row><row><entry + align="char"> +</entry><entry + align="char"> +<para>FALSE: Show last decoded frame.</para> +</entry> + </row></tbody></tgroup></informaltable> +<para>ERRORS +</para> +<informaltable><tgroup cols="2"><tbody><row><entry + align="char"> +<para>EBADF</para> +</entry><entry + align="char"> +<para>fd is not a valid open file descriptor</para> +</entry> + </row><row><entry + align="char"> +<para>EINTERNAL</para> +</entry><entry + align="char"> +<para>Internal error, possibly in the communication with the + DVB subsystem.</para> +</entry> + </row><row><entry + align="char"> +<para>EINVAL</para> +</entry><entry + align="char"> +<para>Illegal input parameter</para> +</entry> + </row></tbody></tgroup></informaltable> + +</section><section +role="subsection"><title>VIDEO_GET_STATUS</title> +<para>DESCRIPTION +</para> +<informaltable><tgroup cols="1"><tbody><row><entry + align="char"> +<para>This ioctl call asks the Video Device to return the current status of the device.</para> +</entry> + </row></tbody></tgroup></informaltable> +<para>SYNOPSIS +</para> +<informaltable><tgroup cols="1"><tbody><row><entry + align="char"> +<para> int ioctl(fd, int request = VIDEO_GET_STATUS, struct + video_status ⋆status);</para> +</entry> + </row></tbody></tgroup></informaltable> +<para>PARAMETERS +</para> +<informaltable><tgroup cols="2"><tbody><row><entry + align="char"> +<para>int fd</para> +</entry><entry + align="char"> +<para>File descriptor returned by a previous call to open().</para> +</entry> + </row><row><entry + align="char"> +<para>int request</para> +</entry><entry + align="char"> +<para>Equals VIDEO_GET_STATUS for this command.</para> +</entry> + </row><row><entry + align="char"> +<para>struct video_status + *status</para> +</entry><entry + align="char"> +<para>Returns the current status of the Video Device.</para> +</entry> + </row></tbody></tgroup></informaltable> +<para>ERRORS +</para> +<informaltable><tgroup cols="2"><tbody><row><entry + align="char"> +<para>EBADF</para> +</entry><entry + align="char"> +<para>fd is not a valid open file descriptor</para> +</entry> + </row><row><entry + align="char"> +<para>EINTERNAL</para> +</entry><entry + align="char"> +<para>Internal error, possibly in the communication with the + DVB subsystem.</para> +</entry> + </row><row><entry + align="char"> +<para>EFAULT</para> +</entry><entry + align="char"> +<para>status points to invalid address</para> +</entry> + </row></tbody></tgroup></informaltable> + +</section><section +role="subsection"><title>VIDEO_GET_EVENT</title> +<para>DESCRIPTION +</para> +<informaltable><tgroup cols="1"><tbody><row><entry + align="char"> +<para>This ioctl call returns an event of type video_event if available. If an event is + not available, the behavior depends on whether the device is in blocking or + non-blocking mode. In the latter case, the call fails immediately with errno + set to EWOULDBLOCK. In the former case, the call blocks until an event + becomes available. The standard Linux poll() and/or select() system calls can + be used with the device file descriptor to watch for new events. For select(), + the file descriptor should be included in the exceptfds argument, and for + poll(), POLLPRI should be specified as the wake-up condition. Read-only + permissions are sufficient for this ioctl call.</para> +</entry> + </row></tbody></tgroup></informaltable> +<para>SYNOPSIS +</para> +<informaltable><tgroup cols="1"><tbody><row><entry + align="char"> +<para> int ioctl(fd, int request = VIDEO_GET_EVENT, struct + video_event ⋆ev);</para> +</entry> + </row></tbody></tgroup></informaltable> +<para>PARAMETERS +</para> +<informaltable><tgroup cols="2"><tbody><row><entry + align="char"> +<para>int fd</para> +</entry><entry + align="char"> +<para>File descriptor returned by a previous call to open().</para> +</entry> + </row><row><entry + align="char"> +<para>int request</para> +</entry><entry + align="char"> +<para>Equals VIDEO_GET_EVENT for this command.</para> +</entry> + </row><row><entry + align="char"> +<para>struct video_event + *ev</para> +</entry><entry + align="char"> +<para>Points to the location where the event, if any, is to be + stored.</para> +</entry> + </row></tbody></tgroup></informaltable> +<para>ERRORS +</para> +<informaltable><tgroup cols="2"><tbody><row><entry + align="char"> +<para>EBADF</para> +</entry><entry + align="char"> +<para>fd is not a valid open file descriptor</para> +</entry> + </row><row><entry + align="char"> +<para>EFAULT</para> +</entry><entry + align="char"> +<para>ev points to invalid address</para> +</entry> + </row><row><entry + align="char"> +<para>EWOULDBLOCK</para> +</entry><entry + align="char"> +<para>There is no event pending, and the device is in + non-blocking mode.</para> +</entry> + </row><row><entry + align="char"> +<para>EOVERFLOW</para> +</entry><entry + align="char"> +</entry> + </row><row><entry + align="char"> +</entry><entry + align="char"> +<para>Overflow in event queue - one or more events were lost.</para> +</entry> + </row></tbody></tgroup></informaltable> + +</section><section +role="subsection"><title>VIDEO_SET_DISPLAY_FORMAT</title> +<para>DESCRIPTION +</para> +<informaltable><tgroup cols="1"><tbody><row><entry + align="char"> +<para>This ioctl call asks the Video Device to select the video format to be applied + by the MPEG chip on the video.</para> +</entry> + </row></tbody></tgroup></informaltable> +<para>SYNOPSIS +</para> +<informaltable><tgroup cols="1"><tbody><row><entry + align="char"> +<para> int ioctl(fd, int request = + VIDEO_SET_DISPLAY_FORMAT, video_display_format_t + format);</para> +</entry> + </row></tbody></tgroup></informaltable> +<para>PARAMETERS +</para> +<informaltable><tgroup cols="2"><tbody><row><entry + align="char"> +<para>int fd</para> +</entry><entry + align="char"> +<para>File descriptor returned by a previous call to open().</para> +</entry> + </row><row><entry + align="char"> +<para>int request</para> +</entry><entry + align="char"> +<para>Equals VIDEO_SET_DISPLAY_FORMAT for this + command.</para> +</entry> + </row><row><entry + align="char"> +<para>video_display_format_t + format</para> +</entry><entry + align="char"> +<para>Selects the video format to be used.</para> +</entry> + </row></tbody></tgroup></informaltable> +<para>ERRORS +</para> +<informaltable><tgroup cols="2"><tbody><row><entry + align="char"> +<para>EBADF</para> +</entry><entry + align="char"> +<para>fd is not a valid open file descriptor</para> +</entry> + </row><row><entry + align="char"> +<para>EINTERNAL</para> +</entry><entry + align="char"> +<para>Internal error.</para> +</entry> + </row><row><entry + align="char"> +<para>EINVAL</para> +</entry><entry + align="char"> +<para>Illegal parameter format.</para> +</entry> + </row></tbody></tgroup></informaltable> + +</section><section +role="subsection"><title>VIDEO_STILLPICTURE</title> +<para>DESCRIPTION +</para> +<informaltable><tgroup cols="1"><tbody><row><entry + align="char"> +<para>This ioctl call asks the Video Device to display a still picture (I-frame). The + input data shall contain an I-frame. If the pointer is NULL, then the current + displayed still picture is blanked.</para> +</entry> + </row></tbody></tgroup></informaltable> +<para>SYNOPSIS +</para> +<informaltable><tgroup cols="1"><tbody><row><entry + align="char"> +<para>int ioctl(fd, int request = VIDEO_STILLPICTURE, + struct video_still_picture ⋆sp);</para> +</entry> + </row></tbody></tgroup></informaltable> +<para>PARAMETERS +</para> +<informaltable><tgroup cols="2"><tbody><row><entry + align="char"> +<para>int fd</para> +</entry><entry + align="char"> +<para>File descriptor returned by a previous call to open().</para> +</entry> + </row><row><entry + align="char"> +<para>int request</para> +</entry><entry + align="char"> +<para>Equals VIDEO_STILLPICTURE for this command.</para> +</entry> + </row><row><entry + align="char"> +<para>struct + video_still_picture + *sp</para> +</entry><entry + align="char"> +<para>Pointer to a location where an I-frame and size is stored.</para> +</entry> + </row></tbody></tgroup></informaltable> +<para>ERRORS +</para> +<informaltable><tgroup cols="2"><tbody><row><entry + align="char"> +<para>EBADF</para> +</entry><entry + align="char"> +<para>fd is not a valid open file descriptor</para> +</entry> + </row><row><entry + align="char"> +<para>EINTERNAL</para> +</entry><entry + align="char"> +<para>Internal error.</para> +</entry> + </row><row><entry + align="char"> +<para>EFAULT</para> +</entry><entry + align="char"> +<para>sp points to an invalid iframe.</para> +</entry> + </row></tbody></tgroup></informaltable> + +</section><section +role="subsection"><title>VIDEO_FAST_FORWARD</title> +<para>DESCRIPTION +</para> +<informaltable><tgroup cols="1"><tbody><row><entry + align="char"> +<para>This ioctl call asks the Video Device to skip decoding of N number of I-frames. + This call can only be used if VIDEO_SOURCE_MEMORY is selected.</para> +</entry> + </row></tbody></tgroup></informaltable> +<para>SYNOPSIS +</para> +<informaltable><tgroup cols="1"><tbody><row><entry + align="char"> +<para>int ioctl(fd, int request = VIDEO_FAST_FORWARD, int + nFrames);</para> +</entry> + </row></tbody></tgroup></informaltable> +<para>PARAMETERS +</para> +<informaltable><tgroup cols="2"><tbody><row><entry + align="char"> +<para>int fd</para> +</entry><entry + align="char"> +<para>File descriptor returned by a previous call to open().</para> +</entry> + </row><row><entry + align="char"> +<para>int request</para> +</entry><entry + align="char"> +<para>Equals VIDEO_FAST_FORWARD for this command.</para> +</entry> + </row><row><entry + align="char"> +<para>int nFrames</para> +</entry><entry + align="char"> +<para>The number of frames to skip.</para> +</entry> + </row></tbody></tgroup></informaltable> +<para>ERRORS +</para> +<informaltable><tgroup cols="2"><tbody><row><entry + align="char"> +<para>EBADF</para> +</entry><entry + align="char"> +<para>fd is not a valid open file descriptor</para> +</entry> + </row><row><entry + align="char"> +<para>EINTERNAL</para> +</entry><entry + align="char"> +<para>Internal error.</para> +</entry> + </row><row><entry + align="char"> +<para>EPERM</para> +</entry><entry + align="char"> +<para>Mode VIDEO_SOURCE_MEMORY not selected.</para> +</entry> + </row><row><entry + align="char"> +<para>EINVAL</para> +</entry><entry + align="char"> +<para>Illegal parameter format.</para> +</entry> + </row></tbody></tgroup></informaltable> + +</section><section +role="subsection"><title>VIDEO_SLOWMOTION</title> +<para>DESCRIPTION +</para> +<informaltable><tgroup cols="1"><tbody><row><entry + align="char"> +<para>This ioctl call asks the video device to repeat decoding frames N number of + times. This call can only be used if VIDEO_SOURCE_MEMORY is selected.</para> +</entry> + </row></tbody></tgroup></informaltable> +<para>SYNOPSIS +</para> +<informaltable><tgroup cols="1"><tbody><row><entry + align="char"> +<para>int ioctl(fd, int request = VIDEO_SLOWMOTION, int + nFrames);</para> +</entry> + </row></tbody></tgroup></informaltable> +<para>PARAMETERS +</para> +<informaltable><tgroup cols="2"><tbody><row><entry + align="char"> +<para>int fd</para> +</entry><entry + align="char"> +<para>File descriptor returned by a previous call to open().</para> +</entry> + </row><row><entry + align="char"> +<para>int request</para> +</entry><entry + align="char"> +<para>Equals VIDEO_SLOWMOTION for this command.</para> +</entry> + </row><row><entry + align="char"> +<para>int nFrames</para> +</entry><entry + align="char"> +<para>The number of times to repeat each frame.</para> +</entry> + </row></tbody></tgroup></informaltable> +<para>ERRORS +</para> +<informaltable><tgroup cols="2"><tbody><row><entry + align="char"> +<para>EBADF</para> +</entry><entry + align="char"> +<para>fd is not a valid open file descriptor</para> +</entry> + </row><row><entry + align="char"> +<para>EINTERNAL</para> +</entry><entry + align="char"> +<para>Internal error.</para> +</entry> + </row><row><entry + align="char"> +<para>EPERM</para> +</entry><entry + align="char"> +<para>Mode VIDEO_SOURCE_MEMORY not selected.</para> +</entry> + </row><row><entry + align="char"> +<para>EINVAL</para> +</entry><entry + align="char"> +<para>Illegal parameter format.</para> +</entry> + </row></tbody></tgroup></informaltable> + +</section><section +role="subsection"><title>VIDEO_GET_CAPABILITIES</title> +<para>DESCRIPTION +</para> +<informaltable><tgroup cols="1"><tbody><row><entry + align="char"> +<para>This ioctl call asks the video device about its decoding capabilities. On success + it returns and integer which has bits set according to the defines in section ??.</para> +</entry> + </row></tbody></tgroup></informaltable> +<para>SYNOPSIS +</para> +<informaltable><tgroup cols="1"><tbody><row><entry + align="char"> +<para>int ioctl(fd, int request = VIDEO_GET_CAPABILITIES, + unsigned int ⋆cap);</para> +</entry> + </row></tbody></tgroup></informaltable> +<para>PARAMETERS +</para> +<informaltable><tgroup cols="2"><tbody><row><entry + align="char"> +<para>int fd</para> +</entry><entry + align="char"> +<para>File descriptor returned by a previous call to open().</para> +</entry> + </row><row><entry + align="char"> +<para>int request</para> +</entry><entry + align="char"> +<para>Equals VIDEO_GET_CAPABILITIES for this + command.</para> +</entry> + </row><row><entry + align="char"> +<para>unsigned int *cap</para> +</entry><entry + align="char"> +<para>Pointer to a location where to store the capability + information.</para> +</entry> + </row></tbody></tgroup></informaltable> +<para>ERRORS +</para> +<informaltable><tgroup cols="2"><tbody><row><entry + align="char"> +<para>EBADF</para> +</entry><entry + align="char"> +<para>fd is not a valid open file descriptor</para> +</entry> + </row><row><entry + align="char"> +<para>EFAULT</para> +</entry><entry + align="char"> +<para>cap points to an invalid iframe.</para> +</entry> + </row></tbody></tgroup></informaltable> + +</section><section +role="subsection"><title>VIDEO_SET_ID</title> +<para>DESCRIPTION +</para> +<informaltable><tgroup cols="1"><tbody><row><entry + align="char"> +<para>This ioctl selects which sub-stream is to be decoded if a program or system + stream is sent to the video device.</para> +</entry> + </row></tbody></tgroup></informaltable> +<para>SYNOPSIS +</para> +<informaltable><tgroup cols="1"><tbody><row><entry + align="char"> +<para>int ioctl(int fd, int request = VIDEO_SET_ID, int + id);</para> +</entry> + </row></tbody></tgroup></informaltable> +<para>PARAMETERS +</para> +<informaltable><tgroup cols="2"><tbody><row><entry + align="char"> +<para>int fd</para> +</entry><entry + align="char"> +<para>File descriptor returned by a previous call to open().</para> +</entry> + </row><row><entry + align="char"> +<para>int request</para> +</entry><entry + align="char"> +<para>Equals VIDEO_SET_ID for this command.</para> +</entry> + </row><row><entry + align="char"> +<para>int id</para> +</entry><entry + align="char"> +<para>video sub-stream id</para> +</entry> + </row></tbody></tgroup></informaltable> +<para>ERRORS +</para> +<informaltable><tgroup cols="2"><tbody><row><entry + align="char"> +<para>EBADF</para> +</entry><entry + align="char"> +<para>fd is not a valid open file descriptor.</para> +</entry> + </row><row><entry + align="char"> +<para>EINTERNAL</para> +</entry><entry + align="char"> +<para>Internal error.</para> +</entry> + </row><row><entry + align="char"> +<para>EINVAL</para> +</entry><entry + align="char"> +<para>Invalid sub-stream id.</para> +</entry> + </row></tbody></tgroup></informaltable> + +</section><section +role="subsection"><title>VIDEO_CLEAR_BUFFER</title> +<para>DESCRIPTION +</para> +<informaltable><tgroup cols="1"><tbody><row><entry + align="char"> +<para>This ioctl call clears all video buffers in the driver and in the decoder hardware.</para> +</entry> + </row></tbody></tgroup></informaltable> +<para>SYNOPSIS +</para> +<informaltable><tgroup cols="1"><tbody><row><entry + align="char"> +<para>int ioctl(fd, int request = VIDEO_CLEAR_BUFFER);</para> +</entry> + </row></tbody></tgroup></informaltable> +<para>PARAMETERS +</para> +<informaltable><tgroup cols="2"><tbody><row><entry + align="char"> +<para>int fd</para> +</entry><entry + align="char"> +<para>File descriptor returned by a previous call to open().</para> +</entry> + </row><row><entry + align="char"> +<para>int request</para> +</entry><entry + align="char"> +<para>Equals VIDEO_CLEAR_BUFFER for this command.</para> +</entry> + </row></tbody></tgroup></informaltable> +<para>ERRORS +</para> +<informaltable><tgroup cols="2"><tbody><row><entry + align="char"> +<para>EBADF</para> +</entry><entry + align="char"> +<para>fd is not a valid open file descriptor</para> +</entry> + </row></tbody></tgroup></informaltable> + +</section><section +role="subsection"><title>VIDEO_SET_STREAMTYPE</title> +<para>DESCRIPTION +</para> +<informaltable><tgroup cols="1"><tbody><row><entry + align="char"> +<para>This ioctl tells the driver which kind of stream to expect being written to it. If + this call is not used the default of video PES is used. Some drivers might not + support this call and always expect PES.</para> +</entry> + </row></tbody></tgroup></informaltable> +<para>SYNOPSIS +</para> +<informaltable><tgroup cols="1"><tbody><row><entry + align="char"> +<para>int ioctl(fd, int request = VIDEO_SET_STREAMTYPE, + int type);</para> +</entry> + </row></tbody></tgroup></informaltable> +<para>PARAMETERS +</para> +<informaltable><tgroup cols="2"><tbody><row><entry + align="char"> +<para>int fd</para> +</entry><entry + align="char"> +<para>File descriptor returned by a previous call to open().</para> +</entry> + </row><row><entry + align="char"> +<para>int request</para> +</entry><entry + align="char"> +<para>Equals VIDEO_SET_STREAMTYPE for this command.</para> +</entry> + </row><row><entry + align="char"> +<para>int type</para> +</entry><entry + align="char"> +<para>stream type</para> +</entry> + </row></tbody></tgroup></informaltable> +<para>ERRORS +</para> +<informaltable><tgroup cols="2"><tbody><row><entry + align="char"> +<para>EBADF</para> +</entry><entry + align="char"> +<para>fd is not a valid open file descriptor</para> +</entry> + </row><row><entry + align="char"> +<para>EINVAL</para> +</entry><entry + align="char"> +<para>type is not a valid or supported stream type.</para> +</entry> + </row></tbody></tgroup></informaltable> + +</section><section +role="subsection"><title>VIDEO_SET_FORMAT</title> +<para>DESCRIPTION +</para> +<informaltable><tgroup cols="1"><tbody><row><entry + align="char"> +<para>This ioctl sets the screen format (aspect ratio) of the connected output device + (TV) so that the output of the decoder can be adjusted accordingly.</para> +</entry> + </row></tbody></tgroup></informaltable> +<para>SYNOPSIS +</para> +<informaltable><tgroup cols="1"><tbody><row><entry + align="char"> +<para> int ioctl(fd, int request = VIDEO_SET_FORMAT, + video_format_t format);</para> +</entry> + </row></tbody></tgroup></informaltable> +<para>PARAMETERS +</para> +<informaltable><tgroup cols="2"><tbody><row><entry + align="char"> +<para>int fd</para> +</entry><entry + align="char"> +<para>File descriptor returned by a previous call to open().</para> +</entry> + </row><row><entry + align="char"> +<para>int request</para> +</entry><entry + align="char"> +<para>Equals VIDEO_SET_FORMAT for this command.</para> +</entry> + </row><row><entry + align="char"> +<para>video_format_t + format</para> +</entry><entry + align="char"> +<para>video format of TV as defined in section ??.</para> +</entry> + </row></tbody></tgroup></informaltable> +<para>ERRORS +</para> +<informaltable><tgroup cols="2"><tbody><row><entry + align="char"> +<para>EBADF</para> +</entry><entry + align="char"> +<para>fd is not a valid open file descriptor</para> +</entry> + </row><row><entry + align="char"> +<para>EINVAL</para> +</entry><entry + align="char"> +<para>format is not a valid video format.</para> +</entry> + </row></tbody></tgroup></informaltable> + +</section><section +role="subsection"><title>VIDEO_SET_SYSTEM</title> +<para>DESCRIPTION +</para> +<informaltable><tgroup cols="1"><tbody><row><entry + align="char"> +<para>This ioctl sets the television output format. The format (see section ??) may + vary from the color format of the displayed MPEG stream. If the hardware is + not able to display the requested format the call will return an error.</para> +</entry> + </row></tbody></tgroup></informaltable> +<para>SYNOPSIS +</para> +<informaltable><tgroup cols="1"><tbody><row><entry + align="char"> +<para> int ioctl(fd, int request = VIDEO_SET_SYSTEM , + video_system_t system);</para> +</entry> + </row></tbody></tgroup></informaltable> +<para>PARAMETERS +</para> +<informaltable><tgroup cols="2"><tbody><row><entry + align="char"> +<para>int fd</para> +</entry><entry + align="char"> +<para>File descriptor returned by a previous call to open().</para> +</entry> + </row><row><entry + align="char"> +<para>int request</para> +</entry><entry + align="char"> +<para>Equals VIDEO_SET_FORMAT for this command.</para> +</entry> + </row><row><entry + align="char"> +<para>video_system_t + system</para> +</entry><entry + align="char"> +<para>video system of TV output.</para> +</entry> + </row></tbody></tgroup></informaltable> +<para>ERRORS +</para> +<informaltable><tgroup cols="2"><tbody><row><entry + align="char"> +<para>EBADF</para> +</entry><entry + align="char"> +<para>fd is not a valid open file descriptor</para> +</entry> + </row><row><entry + align="char"> +<para>EINVAL</para> +</entry><entry + align="char"> +<para>system is not a valid or supported video system.</para> +</entry> + </row></tbody></tgroup></informaltable> + +</section><section +role="subsection"><title>VIDEO_SET_HIGHLIGHT</title> +<para>DESCRIPTION +</para> +<informaltable><tgroup cols="1"><tbody><row><entry + align="char"> +<para>This ioctl sets the SPU highlight information for the menu access of a DVD.</para> +</entry> + </row></tbody></tgroup></informaltable> +<para>SYNOPSIS +</para> +<informaltable><tgroup cols="1"><tbody><row><entry + align="char"> +<para> int ioctl(fd, int request = VIDEO_SET_HIGHLIGHT + ,video_highlight_t ⋆vhilite)</para> +</entry> + </row></tbody></tgroup></informaltable> +<para>PARAMETERS +</para> +<informaltable><tgroup cols="2"><tbody><row><entry + align="char"> +<para>int fd</para> +</entry><entry + align="char"> +<para>File descriptor returned by a previous call to open().</para> +</entry> + </row><row><entry + align="char"> +<para>int request</para> +</entry><entry + align="char"> +<para>Equals VIDEO_SET_HIGHLIGHT for this command.</para> +</entry> + </row><row><entry + align="char"> +<para>video_highlight_t + *vhilite</para> +</entry><entry + align="char"> +<para>SPU Highlight information according to section ??.</para> +</entry> + </row></tbody></tgroup></informaltable> +<para>ERRORS +</para> +<informaltable><tgroup cols="2"><tbody><row><entry + align="char"> +<para>EBADF</para> +</entry><entry + align="char"> +<para>fd is not a valid open file descriptor.</para> +</entry> + </row><row><entry + align="char"> +<para>EINVAL</para> +</entry><entry + align="char"> +<para>input is not a valid highlight setting.</para> +</entry> + </row></tbody></tgroup></informaltable> + +</section><section +role="subsection"><title>VIDEO_SET_SPU</title> +<para>DESCRIPTION +</para> +<informaltable><tgroup cols="1"><tbody><row><entry + align="char"> +<para>This ioctl activates or deactivates SPU decoding in a DVD input stream. It can + only be used, if the driver is able to handle a DVD stream.</para> +</entry> + </row></tbody></tgroup></informaltable> +<para>SYNOPSIS +</para> +<informaltable><tgroup cols="1"><tbody><row><entry + align="char"> +<para> int ioctl(fd, int request = VIDEO_SET_SPU , + video_spu_t ⋆spu)</para> +</entry> + </row></tbody></tgroup></informaltable> +<para>PARAMETERS +</para> +<informaltable><tgroup cols="2"><tbody><row><entry + align="char"> +<para>int fd</para> +</entry><entry + align="char"> +<para>File descriptor returned by a previous call to open().</para> +</entry> + </row><row><entry + align="char"> +<para>int request</para> +</entry><entry + align="char"> +<para>Equals VIDEO_SET_SPU for this command.</para> +</entry> + </row><row><entry + align="char"> +<para>video_spu_t *spu</para> +</entry><entry + align="char"> +<para>SPU decoding (de)activation and subid setting according + to section ??.</para> +</entry> + </row></tbody></tgroup></informaltable> +<para>ERRORS +</para> +<informaltable><tgroup cols="2"><tbody><row><entry + align="char"> +<para>EBADF</para> +</entry><entry + align="char"> +<para>fd is not a valid open file descriptor</para> +</entry> + </row><row><entry + align="char"> +<para>EINVAL</para> +</entry><entry + align="char"> +<para>input is not a valid spu setting or driver cannot handle + SPU.</para> +</entry> + </row></tbody></tgroup></informaltable> + +</section><section +role="subsection"><title>VIDEO_SET_SPU_PALETTE</title> +<para>DESCRIPTION +</para> +<informaltable><tgroup cols="1"><tbody><row><entry + align="char"> +<para>This ioctl sets the SPU color palette.</para> +</entry> + </row></tbody></tgroup></informaltable> +<para>SYNOPSIS +</para> +<informaltable><tgroup cols="1"><tbody><row><entry + align="char"> +<para> int ioctl(fd, int request = VIDEO_SET_SPU_PALETTE + ,video_spu_palette_t ⋆palette )</para> +</entry> + </row></tbody></tgroup></informaltable> +<para>PARAMETERS +</para> +<informaltable><tgroup cols="2"><tbody><row><entry + align="char"> +<para>int fd</para> +</entry><entry + align="char"> +<para>File descriptor returned by a previous call to open().</para> +</entry> + </row><row><entry + align="char"> +<para>int request</para> +</entry><entry + align="char"> +<para>Equals VIDEO_SET_SPU_PALETTE for this command.</para> +</entry> + </row><row><entry + align="char"> +<para>video_spu_palette_t + *palette</para> +</entry><entry + align="char"> +<para>SPU palette according to section ??.</para> +</entry> + </row></tbody></tgroup></informaltable> +<para>ERRORS +</para> +<informaltable><tgroup cols="2"><tbody><row><entry + align="char"> +<para>EBADF</para> +</entry><entry + align="char"> +<para>fd is not a valid open file descriptor</para> +</entry> + </row><row><entry + align="char"> +<para>EINVAL</para> +</entry><entry + align="char"> +<para>input is not a valid palette or driver doesn’t handle SPU.</para> +</entry> + </row></tbody></tgroup></informaltable> + +</section><section +role="subsection"><title>VIDEO_GET_NAVI</title> +<para>DESCRIPTION +</para> +<informaltable><tgroup cols="1"><tbody><row><entry + align="char"> +<para>This ioctl returns navigational information from the DVD stream. This is + especially needed if an encoded stream has to be decoded by the hardware.</para> +</entry> + </row></tbody></tgroup></informaltable> +<para>SYNOPSIS +</para> +<informaltable><tgroup cols="1"><tbody><row><entry + align="char"> +<para> int ioctl(fd, int request = VIDEO_GET_NAVI , + video_navi_pack_t ⋆navipack)</para> +</entry> + </row></tbody></tgroup></informaltable> +<para>PARAMETERS +</para> +<informaltable><tgroup cols="2"><tbody><row><entry + align="char"> +<para>int fd</para> +</entry><entry + align="char"> +<para>File descriptor returned by a previous call to open().</para> +</entry> + </row><row><entry + align="char"> +<para>int request</para> +</entry><entry + align="char"> +<para>Equals VIDEO_GET_NAVI for this command.</para> +</entry> + </row><row><entry + align="char"> +<para>video_navi_pack_t + *navipack</para> +</entry><entry + align="char"> +<para>PCI or DSI pack (private stream 2) according to section + ??.</para> +</entry> + </row></tbody></tgroup></informaltable> +<para>ERRORS +</para> +<informaltable><tgroup cols="2"><tbody><row><entry + align="char"> +<para>EBADF</para> +</entry><entry + align="char"> +<para>fd is not a valid open file descriptor</para> +</entry> + </row><row><entry + align="char"> +<para>EFAULT</para> +</entry><entry + align="char"> +<para>driver is not able to return navigational information</para> +</entry> + </row></tbody></tgroup></informaltable> + +</section><section +role="subsection"><title>VIDEO_SET_ATTRIBUTES</title> +<para>DESCRIPTION +</para> +<informaltable><tgroup cols="1"><tbody><row><entry + align="char"> +<para>This ioctl is intended for DVD playback and allows you to set certain + information about the stream. Some hardware may not need this information, + but the call also tells the hardware to prepare for DVD playback.</para> +</entry> + </row></tbody></tgroup></informaltable> +<para>SYNOPSIS +</para> +<informaltable><tgroup cols="1"><tbody><row><entry + align="char"> +<para> int ioctl(fd, int request = VIDEO_SET_ATTRIBUTE + ,video_attributes_t vattr)</para> +</entry> + </row></tbody></tgroup></informaltable> +<para>PARAMETERS +</para> +<informaltable><tgroup cols="2"><tbody><row><entry + align="char"> +<para>int fd</para> +</entry><entry + align="char"> +<para>File descriptor returned by a previous call to open().</para> +</entry> + </row><row><entry + align="char"> +<para>int request</para> +</entry><entry + align="char"> +<para>Equals VIDEO_SET_ATTRIBUTE for this command.</para> +</entry> + </row><row><entry + align="char"> +<para>video_attributes_t + vattr</para> +</entry><entry + align="char"> +<para>video attributes according to section ??.</para> +</entry> + </row></tbody></tgroup></informaltable> +<para>ERRORS +</para> +<informaltable><tgroup cols="2"><tbody><row><entry + align="char"> +<para>EBADF</para> +</entry><entry + align="char"> +<para>fd is not a valid open file descriptor</para> +</entry> + </row><row><entry + align="char"> +<para>EINVAL</para> +</entry><entry + align="char"> +<para>input is not a valid attribute setting.</para> +</entry> + </row></tbody></tgroup></informaltable> + </section></section> diff --git a/Documentation/DocBook/genericirq.tmpl b/Documentation/DocBook/genericirq.tmpl index c671a0168096..1448b33fd222 100644 --- a/Documentation/DocBook/genericirq.tmpl +++ b/Documentation/DocBook/genericirq.tmpl @@ -417,8 +417,8 @@ desc->chip->end(); </para> <para> To make use of the split implementation, replace the call to - __do_IRQ by a call to desc->chip->handle_irq() and associate - the appropriate handler function to desc->chip->handle_irq(). + __do_IRQ by a call to desc->handle_irq() and associate + the appropriate handler function to desc->handle_irq(). In most cases the generic handler implementations should be sufficient. </para> diff --git a/Documentation/DocBook/kernel-hacking.tmpl b/Documentation/DocBook/kernel-hacking.tmpl index 992e67e6be7f..7b3f49363413 100644 --- a/Documentation/DocBook/kernel-hacking.tmpl +++ b/Documentation/DocBook/kernel-hacking.tmpl @@ -352,7 +352,7 @@ asmlinkage long sys_mycall(int arg) </para> <programlisting> -if (signal_pending()) +if (signal_pending(current)) return -ERESTARTSYS; </programlisting> diff --git a/Documentation/DocBook/media-entities.tmpl b/Documentation/DocBook/media-entities.tmpl new file mode 100644 index 000000000000..c725cb852c54 --- /dev/null +++ b/Documentation/DocBook/media-entities.tmpl @@ -0,0 +1,383 @@ +<!-- Generated file! Do not edit. --> + +<!-- Functions --> +<!ENTITY func-close "<link linkend='func-close'><function>close()</function></link>"> +<!ENTITY func-ioctl "<link linkend='func-ioctl'><function>ioctl()</function></link>"> +<!ENTITY func-mmap "<link linkend='func-mmap'><function>mmap()</function></link>"> +<!ENTITY func-munmap "<link linkend='func-munmap'><function>munmap()</function></link>"> +<!ENTITY func-open "<link linkend='func-open'><function>open()</function></link>"> +<!ENTITY func-poll "<link linkend='func-poll'><function>poll()</function></link>"> +<!ENTITY func-read "<link linkend='func-read'><function>read()</function></link>"> +<!ENTITY func-select "<link linkend='func-select'><function>select()</function></link>"> +<!ENTITY func-write "<link linkend='func-write'><function>write()</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>"> +<!ENTITY VIDIOC-DBG-G-REGISTER "<link linkend='vidioc-dbg-g-register'><constant>VIDIOC_DBG_G_REGISTER</constant></link>"> +<!ENTITY VIDIOC-DBG-S-REGISTER "<link linkend='vidioc-dbg-g-register'><constant>VIDIOC_DBG_S_REGISTER</constant></link>"> +<!ENTITY VIDIOC-DQBUF "<link linkend='vidioc-qbuf'><constant>VIDIOC_DQBUF</constant></link>"> +<!ENTITY VIDIOC-ENCODER-CMD "<link linkend='vidioc-encoder-cmd'><constant>VIDIOC_ENCODER_CMD</constant></link>"> +<!ENTITY VIDIOC-ENUMAUDIO "<link linkend='vidioc-enumaudio'><constant>VIDIOC_ENUMAUDIO</constant></link>"> +<!ENTITY VIDIOC-ENUMAUDOUT "<link linkend='vidioc-enumaudioout'><constant>VIDIOC_ENUMAUDOUT</constant></link>"> +<!ENTITY VIDIOC-ENUMINPUT "<link linkend='vidioc-enuminput'><constant>VIDIOC_ENUMINPUT</constant></link>"> +<!ENTITY VIDIOC-ENUMOUTPUT "<link linkend='vidioc-enumoutput'><constant>VIDIOC_ENUMOUTPUT</constant></link>"> +<!ENTITY VIDIOC-ENUMSTD "<link linkend='vidioc-enumstd'><constant>VIDIOC_ENUMSTD</constant></link>"> +<!ENTITY VIDIOC-ENUM-DV-PRESETS "<link linkend='vidioc-enum-dv-presets'><constant>VIDIOC_ENUM_DV_PRESETS</constant></link>"> +<!ENTITY VIDIOC-ENUM-FMT "<link linkend='vidioc-enum-fmt'><constant>VIDIOC_ENUM_FMT</constant></link>"> +<!ENTITY VIDIOC-ENUM-FRAMEINTERVALS "<link linkend='vidioc-enum-frameintervals'><constant>VIDIOC_ENUM_FRAMEINTERVALS</constant></link>"> +<!ENTITY VIDIOC-ENUM-FRAMESIZES "<link linkend='vidioc-enum-framesizes'><constant>VIDIOC_ENUM_FRAMESIZES</constant></link>"> +<!ENTITY VIDIOC-G-AUDIO "<link linkend='vidioc-g-audio'><constant>VIDIOC_G_AUDIO</constant></link>"> +<!ENTITY VIDIOC-G-AUDOUT "<link linkend='vidioc-g-audioout'><constant>VIDIOC_G_AUDOUT</constant></link>"> +<!ENTITY VIDIOC-G-CROP "<link linkend='vidioc-g-crop'><constant>VIDIOC_G_CROP</constant></link>"> +<!ENTITY VIDIOC-G-CTRL "<link linkend='vidioc-g-ctrl'><constant>VIDIOC_G_CTRL</constant></link>"> +<!ENTITY VIDIOC-G-DV-PRESET "<link linkend='vidioc-g-dv-preset'><constant>VIDIOC_G_DV_PRESET</constant></link>"> +<!ENTITY VIDIOC-G-DV-TIMINGS "<link linkend='vidioc-g-dv-timings'><constant>VIDIOC_G_DV_TIMINGS</constant></link>"> +<!ENTITY VIDIOC-G-ENC-INDEX "<link linkend='vidioc-g-enc-index'><constant>VIDIOC_G_ENC_INDEX</constant></link>"> +<!ENTITY VIDIOC-G-EXT-CTRLS "<link linkend='vidioc-g-ext-ctrls'><constant>VIDIOC_G_EXT_CTRLS</constant></link>"> +<!ENTITY VIDIOC-G-FBUF "<link linkend='vidioc-g-fbuf'><constant>VIDIOC_G_FBUF</constant></link>"> +<!ENTITY VIDIOC-G-FMT "<link linkend='vidioc-g-fmt'><constant>VIDIOC_G_FMT</constant></link>"> +<!ENTITY VIDIOC-G-FREQUENCY "<link linkend='vidioc-g-frequency'><constant>VIDIOC_G_FREQUENCY</constant></link>"> +<!ENTITY VIDIOC-G-INPUT "<link linkend='vidioc-g-input'><constant>VIDIOC_G_INPUT</constant></link>"> +<!ENTITY VIDIOC-G-JPEGCOMP "<link linkend='vidioc-g-jpegcomp'><constant>VIDIOC_G_JPEGCOMP</constant></link>"> +<!ENTITY VIDIOC-G-MPEGCOMP "<link linkend=''><constant>VIDIOC_G_MPEGCOMP</constant></link>"> +<!ENTITY VIDIOC-G-MODULATOR "<link linkend='vidioc-g-modulator'><constant>VIDIOC_G_MODULATOR</constant></link>"> +<!ENTITY VIDIOC-G-OUTPUT "<link linkend='vidioc-g-output'><constant>VIDIOC_G_OUTPUT</constant></link>"> +<!ENTITY VIDIOC-G-PARM "<link linkend='vidioc-g-parm'><constant>VIDIOC_G_PARM</constant></link>"> +<!ENTITY VIDIOC-G-PRIORITY "<link linkend='vidioc-g-priority'><constant>VIDIOC_G_PRIORITY</constant></link>"> +<!ENTITY VIDIOC-G-SLICED-VBI-CAP "<link linkend='vidioc-g-sliced-vbi-cap'><constant>VIDIOC_G_SLICED_VBI_CAP</constant></link>"> +<!ENTITY VIDIOC-G-STD "<link linkend='vidioc-g-std'><constant>VIDIOC_G_STD</constant></link>"> +<!ENTITY VIDIOC-G-TUNER "<link linkend='vidioc-g-tuner'><constant>VIDIOC_G_TUNER</constant></link>"> +<!ENTITY VIDIOC-LOG-STATUS "<link linkend='vidioc-log-status'><constant>VIDIOC_LOG_STATUS</constant></link>"> +<!ENTITY VIDIOC-OVERLAY "<link linkend='vidioc-overlay'><constant>VIDIOC_OVERLAY</constant></link>"> +<!ENTITY VIDIOC-QBUF "<link linkend='vidioc-qbuf'><constant>VIDIOC_QBUF</constant></link>"> +<!ENTITY VIDIOC-QUERYBUF "<link linkend='vidioc-querybuf'><constant>VIDIOC_QUERYBUF</constant></link>"> +<!ENTITY VIDIOC-QUERYCAP "<link linkend='vidioc-querycap'><constant>VIDIOC_QUERYCAP</constant></link>"> +<!ENTITY VIDIOC-QUERYCTRL "<link linkend='vidioc-queryctrl'><constant>VIDIOC_QUERYCTRL</constant></link>"> +<!ENTITY VIDIOC-QUERYMENU "<link linkend='vidioc-queryctrl'><constant>VIDIOC_QUERYMENU</constant></link>"> +<!ENTITY VIDIOC-QUERYSTD "<link linkend='vidioc-querystd'><constant>VIDIOC_QUERYSTD</constant></link>"> +<!ENTITY VIDIOC-QUERY-DV-PRESET "<link linkend='vidioc-query-dv-preset'><constant>VIDIOC_QUERY_DV_PRESET</constant></link>"> +<!ENTITY VIDIOC-REQBUFS "<link linkend='vidioc-reqbufs'><constant>VIDIOC_REQBUFS</constant></link>"> +<!ENTITY VIDIOC-STREAMOFF "<link linkend='vidioc-streamon'><constant>VIDIOC_STREAMOFF</constant></link>"> +<!ENTITY VIDIOC-STREAMON "<link linkend='vidioc-streamon'><constant>VIDIOC_STREAMON</constant></link>"> +<!ENTITY VIDIOC-S-AUDIO "<link linkend='vidioc-g-audio'><constant>VIDIOC_S_AUDIO</constant></link>"> +<!ENTITY VIDIOC-S-AUDOUT "<link linkend='vidioc-g-audioout'><constant>VIDIOC_S_AUDOUT</constant></link>"> +<!ENTITY VIDIOC-S-CROP "<link linkend='vidioc-g-crop'><constant>VIDIOC_S_CROP</constant></link>"> +<!ENTITY VIDIOC-S-CTRL "<link linkend='vidioc-g-ctrl'><constant>VIDIOC_S_CTRL</constant></link>"> +<!ENTITY VIDIOC-S-DV-PRESET "<link linkend='vidioc-g-dv-preset'><constant>VIDIOC_S_DV_PRESET</constant></link>"> +<!ENTITY VIDIOC-S-DV-TIMINGS "<link linkend='vidioc-g-dv-timings'><constant>VIDIOC_S_DV_TIMINGS</constant></link>"> +<!ENTITY VIDIOC-S-EXT-CTRLS "<link linkend='vidioc-g-ext-ctrls'><constant>VIDIOC_S_EXT_CTRLS</constant></link>"> +<!ENTITY VIDIOC-S-FBUF "<link linkend='vidioc-g-fbuf'><constant>VIDIOC_S_FBUF</constant></link>"> +<!ENTITY VIDIOC-S-FMT "<link linkend='vidioc-g-fmt'><constant>VIDIOC_S_FMT</constant></link>"> +<!ENTITY VIDIOC-S-FREQUENCY "<link linkend='vidioc-g-frequency'><constant>VIDIOC_S_FREQUENCY</constant></link>"> +<!ENTITY VIDIOC-S-HW-FREQ-SEEK "<link linkend='vidioc-s-hw-freq-seek'><constant>VIDIOC_S_HW_FREQ_SEEK</constant></link>"> +<!ENTITY VIDIOC-S-INPUT "<link linkend='vidioc-g-input'><constant>VIDIOC_S_INPUT</constant></link>"> +<!ENTITY VIDIOC-S-JPEGCOMP "<link linkend='vidioc-g-jpegcomp'><constant>VIDIOC_S_JPEGCOMP</constant></link>"> +<!ENTITY VIDIOC-S-MPEGCOMP "<link linkend=''><constant>VIDIOC_S_MPEGCOMP</constant></link>"> +<!ENTITY VIDIOC-S-MODULATOR "<link linkend='vidioc-g-modulator'><constant>VIDIOC_S_MODULATOR</constant></link>"> +<!ENTITY VIDIOC-S-OUTPUT "<link linkend='vidioc-g-output'><constant>VIDIOC_S_OUTPUT</constant></link>"> +<!ENTITY VIDIOC-S-PARM "<link linkend='vidioc-g-parm'><constant>VIDIOC_S_PARM</constant></link>"> +<!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-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>"> + +<!-- Types --> +<!ENTITY v4l2-std-id "<link linkend='v4l2-std-id'>v4l2_std_id</link>"> + +<!-- Enums --> +<!ENTITY v4l2-buf-type "enum <link linkend='v4l2-buf-type'>v4l2_buf_type</link>"> +<!ENTITY v4l2-colorspace "enum <link linkend='v4l2-colorspace'>v4l2_colorspace</link>"> +<!ENTITY v4l2-ctrl-type "enum <link linkend='v4l2-ctrl-type'>v4l2_ctrl_type</link>"> +<!ENTITY v4l2-exposure-auto-type "enum <link linkend='v4l2-exposure-auto-type'>v4l2_exposure_auto_type</link>"> +<!ENTITY v4l2-field "enum <link linkend='v4l2-field'>v4l2_field</link>"> +<!ENTITY v4l2-frmivaltypes "enum <link linkend='v4l2-frmivaltypes'>v4l2_frmivaltypes</link>"> +<!ENTITY v4l2-frmsizetypes "enum <link linkend='v4l2-frmsizetypes'>v4l2_frmsizetypes</link>"> +<!ENTITY v4l2-memory "enum <link linkend='v4l2-memory'>v4l2_memory</link>"> +<!ENTITY v4l2-mpeg-audio-ac3-bitrate "enum <link linkend='v4l2-mpeg-audio-ac3-bitrate'>v4l2_mpeg_audio_ac3_bitrate</link>"> +<!ENTITY v4l2-mpeg-audio-crc "enum <link linkend='v4l2-mpeg-audio-crc'>v4l2_mpeg_audio_crc</link>"> +<!ENTITY v4l2-mpeg-audio-emphasis "enum <link linkend='v4l2-mpeg-audio-emphasis'>v4l2_mpeg_audio_emphasis</link>"> +<!ENTITY v4l2-mpeg-audio-encoding "enum <link linkend='v4l2-mpeg-audio-encoding'>v4l2_mpeg_audio_encoding</link>"> +<!ENTITY v4l2-mpeg-audio-l1-bitrate "enum <link linkend='v4l2-mpeg-audio-l1-bitrate'>v4l2_mpeg_audio_l1_bitrate</link>"> +<!ENTITY v4l2-mpeg-audio-l2-bitrate "enum <link linkend='v4l2-mpeg-audio-l2-bitrate'>v4l2_mpeg_audio_l2_bitrate</link>"> +<!ENTITY v4l2-mpeg-audio-l3-bitrate "enum <link linkend='v4l2-mpeg-audio-l3-bitrate'>v4l2_mpeg_audio_l3_bitrate</link>"> +<!ENTITY v4l2-mpeg-audio-mode "enum <link linkend='v4l2-mpeg-audio-mode'>v4l2_mpeg_audio_mode</link>"> +<!ENTITY v4l2-mpeg-audio-mode-extension "enum <link linkend='v4l2-mpeg-audio-mode-extension'>v4l2_mpeg_audio_mode_extension</link>"> +<!ENTITY v4l2-mpeg-audio-sampling-freq "enum <link linkend='v4l2-mpeg-audio-sampling-freq'>v4l2_mpeg_audio_sampling_freq</link>"> +<!ENTITY chroma-spatial-filter-type "enum <link linkend='chroma-spatial-filter-type'>v4l2_mpeg_cx2341x_video_chroma_spatial_filter_type</link>"> +<!ENTITY luma-spatial-filter-type "enum <link linkend='luma-spatial-filter-type'>v4l2_mpeg_cx2341x_video_luma_spatial_filter_type</link>"> +<!ENTITY v4l2-mpeg-cx2341x-video-median-filter-type "enum <link linkend='v4l2-mpeg-cx2341x-video-median-filter-type'>v4l2_mpeg_cx2341x_video_median_filter_type</link>"> +<!ENTITY v4l2-mpeg-cx2341x-video-spatial-filter-mode "enum <link linkend='v4l2-mpeg-cx2341x-video-spatial-filter-mode'>v4l2_mpeg_cx2341x_video_spatial_filter_mode</link>"> +<!ENTITY v4l2-mpeg-cx2341x-video-temporal-filter-mode "enum <link linkend='v4l2-mpeg-cx2341x-video-temporal-filter-mode'>v4l2_mpeg_cx2341x_video_temporal_filter_mode</link>"> +<!ENTITY v4l2-mpeg-stream-type "enum <link linkend='v4l2-mpeg-stream-type'>v4l2_mpeg_stream_type</link>"> +<!ENTITY v4l2-mpeg-stream-vbi-fmt "enum <link linkend='v4l2-mpeg-stream-vbi-fmt'>v4l2_mpeg_stream_vbi_fmt</link>"> +<!ENTITY v4l2-mpeg-video-aspect "enum <link linkend='v4l2-mpeg-video-aspect'>v4l2_mpeg_video_aspect</link>"> +<!ENTITY v4l2-mpeg-video-bitrate-mode "enum <link linkend='v4l2-mpeg-video-bitrate-mode'>v4l2_mpeg_video_bitrate_mode</link>"> +<!ENTITY v4l2-mpeg-video-encoding "enum <link linkend='v4l2-mpeg-video-encoding'>v4l2_mpeg_video_encoding</link>"> +<!ENTITY v4l2-power-line-frequency "enum <link linkend='v4l2-power-line-frequency'>v4l2_power_line_frequency</link>"> +<!ENTITY v4l2-priority "enum <link linkend='v4l2-priority'>v4l2_priority</link>"> +<!ENTITY v4l2-tuner-type "enum <link linkend='v4l2-tuner-type'>v4l2_tuner_type</link>"> +<!ENTITY v4l2-preemphasis "enum <link linkend='v4l2-preemphasis'>v4l2_preemphasis</link>"> + +<!-- Structures --> +<!ENTITY v4l2-audio "struct <link linkend='v4l2-audio'>v4l2_audio</link>"> +<!ENTITY v4l2-audioout "struct <link linkend='v4l2-audioout'>v4l2_audioout</link>"> +<!ENTITY v4l2-bt-timings "struct <link linkend='v4l2-bt-timings'>v4l2_bt_timings</link>"> +<!ENTITY v4l2-buffer "struct <link linkend='v4l2-buffer'>v4l2_buffer</link>"> +<!ENTITY v4l2-capability "struct <link linkend='v4l2-capability'>v4l2_capability</link>"> +<!ENTITY v4l2-captureparm "struct <link linkend='v4l2-captureparm'>v4l2_captureparm</link>"> +<!ENTITY v4l2-clip "struct <link linkend='v4l2-clip'>v4l2_clip</link>"> +<!ENTITY v4l2-control "struct <link linkend='v4l2-control'>v4l2_control</link>"> +<!ENTITY v4l2-crop "struct <link linkend='v4l2-crop'>v4l2_crop</link>"> +<!ENTITY v4l2-cropcap "struct <link linkend='v4l2-cropcap'>v4l2_cropcap</link>"> +<!ENTITY v4l2-dbg-chip-ident "struct <link linkend='v4l2-dbg-chip-ident'>v4l2_dbg_chip_ident</link>"> +<!ENTITY v4l2-dbg-match "struct <link linkend='v4l2-dbg-match'>v4l2_dbg_match</link>"> +<!ENTITY v4l2-dbg-register "struct <link linkend='v4l2-dbg-register'>v4l2_dbg_register</link>"> +<!ENTITY v4l2-dv-enum-preset "struct <link linkend='v4l2-dv-enum-preset'>v4l2_dv_enum_preset</link>"> +<!ENTITY v4l2-dv-preset "struct <link linkend='v4l2-dv-preset'>v4l2_dv_preset</link>"> +<!ENTITY v4l2-dv-timings "struct <link linkend='v4l2-dv-timings'>v4l2_dv_timings</link>"> +<!ENTITY v4l2-enc-idx "struct <link linkend='v4l2-enc-idx'>v4l2_enc_idx</link>"> +<!ENTITY v4l2-enc-idx-entry "struct <link linkend='v4l2-enc-idx-entry'>v4l2_enc_idx_entry</link>"> +<!ENTITY v4l2-encoder-cmd "struct <link linkend='v4l2-encoder-cmd'>v4l2_encoder_cmd</link>"> +<!ENTITY v4l2-ext-control "struct <link linkend='v4l2-ext-control'>v4l2_ext_control</link>"> +<!ENTITY v4l2-ext-controls "struct <link linkend='v4l2-ext-controls'>v4l2_ext_controls</link>"> +<!ENTITY v4l2-fmtdesc "struct <link linkend='v4l2-fmtdesc'>v4l2_fmtdesc</link>"> +<!ENTITY v4l2-format "struct <link linkend='v4l2-format'>v4l2_format</link>"> +<!ENTITY v4l2-fract "struct <link linkend='v4l2-fract'>v4l2_fract</link>"> +<!ENTITY v4l2-framebuffer "struct <link linkend='v4l2-framebuffer'>v4l2_framebuffer</link>"> +<!ENTITY v4l2-frequency "struct <link linkend='v4l2-frequency'>v4l2_frequency</link>"> +<!ENTITY v4l2-frmival-stepwise "struct <link linkend='v4l2-frmival-stepwise'>v4l2_frmival_stepwise</link>"> +<!ENTITY v4l2-frmivalenum "struct <link linkend='v4l2-frmivalenum'>v4l2_frmivalenum</link>"> +<!ENTITY v4l2-frmsize-discrete "struct <link linkend='v4l2-frmsize-discrete'>v4l2_frmsize_discrete</link>"> +<!ENTITY v4l2-frmsize-stepwise "struct <link linkend='v4l2-frmsize-stepwise'>v4l2_frmsize_stepwise</link>"> +<!ENTITY v4l2-frmsizeenum "struct <link linkend='v4l2-frmsizeenum'>v4l2_frmsizeenum</link>"> +<!ENTITY v4l2-hw-freq-seek "struct <link linkend='v4l2-hw-freq-seek'>v4l2_hw_freq_seek</link>"> +<!ENTITY v4l2-input "struct <link linkend='v4l2-input'>v4l2_input</link>"> +<!ENTITY v4l2-jpegcompression "struct <link linkend='v4l2-jpegcompression'>v4l2_jpegcompression</link>"> +<!ENTITY v4l2-modulator "struct <link linkend='v4l2-modulator'>v4l2_modulator</link>"> +<!ENTITY v4l2-mpeg-vbi-fmt-ivtv "struct <link linkend='v4l2-mpeg-vbi-fmt-ivtv'>v4l2_mpeg_vbi_fmt_ivtv</link>"> +<!ENTITY v4l2-output "struct <link linkend='v4l2-output'>v4l2_output</link>"> +<!ENTITY v4l2-outputparm "struct <link linkend='v4l2-outputparm'>v4l2_outputparm</link>"> +<!ENTITY v4l2-pix-format "struct <link linkend='v4l2-pix-format'>v4l2_pix_format</link>"> +<!ENTITY v4l2-queryctrl "struct <link linkend='v4l2-queryctrl'>v4l2_queryctrl</link>"> +<!ENTITY v4l2-querymenu "struct <link linkend='v4l2-querymenu'>v4l2_querymenu</link>"> +<!ENTITY v4l2-rect "struct <link linkend='v4l2-rect'>v4l2_rect</link>"> +<!ENTITY v4l2-requestbuffers "struct <link linkend='v4l2-requestbuffers'>v4l2_requestbuffers</link>"> +<!ENTITY v4l2-sliced-vbi-cap "struct <link linkend='v4l2-sliced-vbi-cap'>v4l2_sliced_vbi_cap</link>"> +<!ENTITY v4l2-sliced-vbi-data "struct <link linkend='v4l2-sliced-vbi-data'>v4l2_sliced_vbi_data</link>"> +<!ENTITY v4l2-sliced-vbi-format "struct <link linkend='v4l2-sliced-vbi-format'>v4l2_sliced_vbi_format</link>"> +<!ENTITY v4l2-standard "struct <link linkend='v4l2-standard'>v4l2_standard</link>"> +<!ENTITY v4l2-streamparm "struct <link linkend='v4l2-streamparm'>v4l2_streamparm</link>"> +<!ENTITY v4l2-timecode "struct <link linkend='v4l2-timecode'>v4l2_timecode</link>"> +<!ENTITY v4l2-tuner "struct <link linkend='v4l2-tuner'>v4l2_tuner</link>"> +<!ENTITY v4l2-vbi-format "struct <link linkend='v4l2-vbi-format'>v4l2_vbi_format</link>"> +<!ENTITY v4l2-window "struct <link linkend='v4l2-window'>v4l2_window</link>"> + +<!-- Error Codes --> +<!ENTITY EACCES "<errorcode>EACCES</errorcode> error code"> +<!ENTITY EAGAIN "<errorcode>EAGAIN</errorcode> error code"> +<!ENTITY EBADF "<errorcode>EBADF</errorcode> error code"> +<!ENTITY EBUSY "<errorcode>EBUSY</errorcode> error code"> +<!ENTITY EFAULT "<errorcode>EFAULT</errorcode> error code"> +<!ENTITY EIO "<errorcode>EIO</errorcode> error code"> +<!ENTITY EINTR "<errorcode>EINTR</errorcode> error code"> +<!ENTITY EINVAL "<errorcode>EINVAL</errorcode> error code"> +<!ENTITY ENFILE "<errorcode>ENFILE</errorcode> error code"> +<!ENTITY ENOMEM "<errorcode>ENOMEM</errorcode> error code"> +<!ENTITY ENOSPC "<errorcode>ENOSPC</errorcode> error code"> +<!ENTITY ENOTTY "<errorcode>ENOTTY</errorcode> error code"> +<!ENTITY ENXIO "<errorcode>ENXIO</errorcode> error code"> +<!ENTITY EMFILE "<errorcode>EMFILE</errorcode> error code"> +<!ENTITY EPERM "<errorcode>EPERM</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-compat SYSTEM "v4l/compat.xml"> +<!ENTITY sub-controls SYSTEM "v4l/controls.xml"> +<!ENTITY sub-dev-capture SYSTEM "v4l/dev-capture.xml"> +<!ENTITY sub-dev-codec SYSTEM "v4l/dev-codec.xml"> +<!ENTITY sub-dev-effect SYSTEM "v4l/dev-effect.xml"> +<!ENTITY sub-dev-osd SYSTEM "v4l/dev-osd.xml"> +<!ENTITY sub-dev-output SYSTEM "v4l/dev-output.xml"> +<!ENTITY sub-dev-overlay SYSTEM "v4l/dev-overlay.xml"> +<!ENTITY sub-dev-radio SYSTEM "v4l/dev-radio.xml"> +<!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-teletext SYSTEM "v4l/dev-teletext.xml"> +<!ENTITY sub-driver SYSTEM "v4l/driver.xml"> +<!ENTITY sub-libv4l SYSTEM "v4l/libv4l.xml"> +<!ENTITY sub-remote_controllers SYSTEM "v4l/remote_controllers.xml"> +<!ENTITY sub-fdl-appendix SYSTEM "v4l/fdl-appendix.xml"> +<!ENTITY sub-close SYSTEM "v4l/func-close.xml"> +<!ENTITY sub-ioctl SYSTEM "v4l/func-ioctl.xml"> +<!ENTITY sub-mmap SYSTEM "v4l/func-mmap.xml"> +<!ENTITY sub-munmap SYSTEM "v4l/func-munmap.xml"> +<!ENTITY sub-open SYSTEM "v4l/func-open.xml"> +<!ENTITY sub-poll SYSTEM "v4l/func-poll.xml"> +<!ENTITY sub-read SYSTEM "v4l/func-read.xml"> +<!ENTITY sub-select SYSTEM "v4l/func-select.xml"> +<!ENTITY sub-write SYSTEM "v4l/func-write.xml"> +<!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-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"> +<!ENTITY sub-sbggr16 SYSTEM "v4l/pixfmt-sbggr16.xml"> +<!ENTITY sub-sbggr8 SYSTEM "v4l/pixfmt-sbggr8.xml"> +<!ENTITY sub-sgbrg8 SYSTEM "v4l/pixfmt-sgbrg8.xml"> +<!ENTITY sub-sgrbg8 SYSTEM "v4l/pixfmt-sgrbg8.xml"> +<!ENTITY sub-uyvy SYSTEM "v4l/pixfmt-uyvy.xml"> +<!ENTITY sub-vyuy SYSTEM "v4l/pixfmt-vyuy.xml"> +<!ENTITY sub-y16 SYSTEM "v4l/pixfmt-y16.xml"> +<!ENTITY sub-y41p SYSTEM "v4l/pixfmt-y41p.xml"> +<!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-yuv422p SYSTEM "v4l/pixfmt-yuv422p.xml"> +<!ENTITY sub-yuyv SYSTEM "v4l/pixfmt-yuyv.xml"> +<!ENTITY sub-yvyu SYSTEM "v4l/pixfmt-yvyu.xml"> +<!ENTITY sub-pixfmt SYSTEM "v4l/pixfmt.xml"> +<!ENTITY sub-cropcap SYSTEM "v4l/vidioc-cropcap.xml"> +<!ENTITY sub-dbg-g-register SYSTEM "v4l/vidioc-dbg-g-register.xml"> +<!ENTITY sub-encoder-cmd SYSTEM "v4l/vidioc-encoder-cmd.xml"> +<!ENTITY sub-enum-fmt SYSTEM "v4l/vidioc-enum-fmt.xml"> +<!ENTITY sub-enum-frameintervals SYSTEM "v4l/vidioc-enum-frameintervals.xml"> +<!ENTITY sub-enum-framesizes SYSTEM "v4l/vidioc-enum-framesizes.xml"> +<!ENTITY sub-enumaudio SYSTEM "v4l/vidioc-enumaudio.xml"> +<!ENTITY sub-enumaudioout SYSTEM "v4l/vidioc-enumaudioout.xml"> +<!ENTITY sub-enuminput SYSTEM "v4l/vidioc-enuminput.xml"> +<!ENTITY sub-enumoutput SYSTEM "v4l/vidioc-enumoutput.xml"> +<!ENTITY sub-enum-dv-presets SYSTEM "v4l/vidioc-enum-dv-presets.xml"> +<!ENTITY sub-g-dv-preset SYSTEM "v4l/vidioc-g-dv-preset.xml"> +<!ENTITY sub-query-dv-preset SYSTEM "v4l/vidioc-query-dv-preset.xml"> +<!ENTITY sub-g-dv-timings SYSTEM "v4l/vidioc-g-dv-timings.xml"> +<!ENTITY sub-enumstd SYSTEM "v4l/vidioc-enumstd.xml"> +<!ENTITY sub-g-audio SYSTEM "v4l/vidioc-g-audio.xml"> +<!ENTITY sub-g-audioout SYSTEM "v4l/vidioc-g-audioout.xml"> +<!ENTITY sub-dbg-g-chip-ident SYSTEM "v4l/vidioc-dbg-g-chip-ident.xml"> +<!ENTITY sub-g-crop SYSTEM "v4l/vidioc-g-crop.xml"> +<!ENTITY sub-g-ctrl SYSTEM "v4l/vidioc-g-ctrl.xml"> +<!ENTITY sub-g-enc-index SYSTEM "v4l/vidioc-g-enc-index.xml"> +<!ENTITY sub-g-ext-ctrls SYSTEM "v4l/vidioc-g-ext-ctrls.xml"> +<!ENTITY sub-g-fbuf SYSTEM "v4l/vidioc-g-fbuf.xml"> +<!ENTITY sub-g-fmt SYSTEM "v4l/vidioc-g-fmt.xml"> +<!ENTITY sub-g-frequency SYSTEM "v4l/vidioc-g-frequency.xml"> +<!ENTITY sub-g-input SYSTEM "v4l/vidioc-g-input.xml"> +<!ENTITY sub-g-jpegcomp SYSTEM "v4l/vidioc-g-jpegcomp.xml"> +<!ENTITY sub-g-modulator SYSTEM "v4l/vidioc-g-modulator.xml"> +<!ENTITY sub-g-output SYSTEM "v4l/vidioc-g-output.xml"> +<!ENTITY sub-g-parm SYSTEM "v4l/vidioc-g-parm.xml"> +<!ENTITY sub-g-priority SYSTEM "v4l/vidioc-g-priority.xml"> +<!ENTITY sub-g-sliced-vbi-cap SYSTEM "v4l/vidioc-g-sliced-vbi-cap.xml"> +<!ENTITY sub-g-std SYSTEM "v4l/vidioc-g-std.xml"> +<!ENTITY sub-g-tuner SYSTEM "v4l/vidioc-g-tuner.xml"> +<!ENTITY sub-log-status SYSTEM "v4l/vidioc-log-status.xml"> +<!ENTITY sub-overlay SYSTEM "v4l/vidioc-overlay.xml"> +<!ENTITY sub-qbuf SYSTEM "v4l/vidioc-qbuf.xml"> +<!ENTITY sub-querybuf SYSTEM "v4l/vidioc-querybuf.xml"> +<!ENTITY sub-querycap SYSTEM "v4l/vidioc-querycap.xml"> +<!ENTITY sub-queryctrl SYSTEM "v4l/vidioc-queryctrl.xml"> +<!ENTITY sub-querystd SYSTEM "v4l/vidioc-querystd.xml"> +<!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-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"> +<!ENTITY sub-videodev2-h SYSTEM "v4l/videodev2.h.xml"> +<!ENTITY sub-v4l2 SYSTEM "v4l/v4l2.xml"> +<!ENTITY sub-intro SYSTEM "dvb/intro.xml"> +<!ENTITY sub-frontend SYSTEM "dvb/frontend.xml"> +<!ENTITY sub-dvbproperty SYSTEM "dvb/dvbproperty.xml"> +<!ENTITY sub-demux SYSTEM "dvb/demux.xml"> +<!ENTITY sub-video SYSTEM "dvb/video.xml"> +<!ENTITY sub-audio SYSTEM "dvb/audio.xml"> +<!ENTITY sub-ca SYSTEM "dvb/ca.xml"> +<!ENTITY sub-net SYSTEM "dvb/net.xml"> +<!ENTITY sub-kdapi SYSTEM "dvb/kdapi.xml"> +<!ENTITY sub-examples SYSTEM "dvb/examples.xml"> +<!ENTITY sub-frontend-h SYSTEM "dvb/frontend.h.xml"> +<!ENTITY sub-dvbapi SYSTEM "dvb/dvbapi.xml"> +<!ENTITY sub-media SYSTEM "media.xml"> +<!ENTITY sub-media-entities SYSTEM "media-entities.tmpl"> +<!ENTITY sub-media-indices SYSTEM "media-indices.tmpl"> + +<!-- Function Reference --> +<!ENTITY close SYSTEM "v4l/func-close.xml"> +<!ENTITY ioctl SYSTEM "v4l/func-ioctl.xml"> +<!ENTITY mmap SYSTEM "v4l/func-mmap.xml"> +<!ENTITY munmap SYSTEM "v4l/func-munmap.xml"> +<!ENTITY open SYSTEM "v4l/func-open.xml"> +<!ENTITY poll SYSTEM "v4l/func-poll.xml"> +<!ENTITY read SYSTEM "v4l/func-read.xml"> +<!ENTITY select SYSTEM "v4l/func-select.xml"> +<!ENTITY write SYSTEM "v4l/func-write.xml"> +<!ENTITY grey SYSTEM "v4l/pixfmt-grey.xml"> +<!ENTITY nv12 SYSTEM "v4l/pixfmt-nv12.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"> +<!ENTITY sbggr16 SYSTEM "v4l/pixfmt-sbggr16.xml"> +<!ENTITY sbggr8 SYSTEM "v4l/pixfmt-sbggr8.xml"> +<!ENTITY sgbrg8 SYSTEM "v4l/pixfmt-sgbrg8.xml"> +<!ENTITY sgrbg8 SYSTEM "v4l/pixfmt-sgrbg8.xml"> +<!ENTITY uyvy SYSTEM "v4l/pixfmt-uyvy.xml"> +<!ENTITY vyuy SYSTEM "v4l/pixfmt-vyuy.xml"> +<!ENTITY y16 SYSTEM "v4l/pixfmt-y16.xml"> +<!ENTITY y41p SYSTEM "v4l/pixfmt-y41p.xml"> +<!ENTITY yuv410 SYSTEM "v4l/pixfmt-yuv410.xml"> +<!ENTITY yuv411p SYSTEM "v4l/pixfmt-yuv411p.xml"> +<!ENTITY yuv420 SYSTEM "v4l/pixfmt-yuv420.xml"> +<!ENTITY yuv422p SYSTEM "v4l/pixfmt-yuv422p.xml"> +<!ENTITY yuyv SYSTEM "v4l/pixfmt-yuyv.xml"> +<!ENTITY yvyu SYSTEM "v4l/pixfmt-yvyu.xml"> +<!ENTITY cropcap SYSTEM "v4l/vidioc-cropcap.xml"> +<!ENTITY dbg-g-register SYSTEM "v4l/vidioc-dbg-g-register.xml"> +<!ENTITY encoder-cmd SYSTEM "v4l/vidioc-encoder-cmd.xml"> +<!ENTITY enum-fmt SYSTEM "v4l/vidioc-enum-fmt.xml"> +<!ENTITY enum-frameintervals SYSTEM "v4l/vidioc-enum-frameintervals.xml"> +<!ENTITY enum-framesizes SYSTEM "v4l/vidioc-enum-framesizes.xml"> +<!ENTITY enumaudio SYSTEM "v4l/vidioc-enumaudio.xml"> +<!ENTITY enumaudioout SYSTEM "v4l/vidioc-enumaudioout.xml"> +<!ENTITY enuminput SYSTEM "v4l/vidioc-enuminput.xml"> +<!ENTITY enumoutput SYSTEM "v4l/vidioc-enumoutput.xml"> +<!ENTITY enum-dv-presets SYSTEM "v4l/vidioc-enum-dv-presets.xml"> +<!ENTITY g-dv-preset SYSTEM "v4l/vidioc-g-dv-preset.xml"> +<!ENTITY query-dv-preset SYSTEM "v4l/vidioc-query-dv-preset.xml"> +<!ENTITY g-dv-timings SYSTEM "v4l/vidioc-g-dv-timings.xml"> +<!ENTITY enumstd SYSTEM "v4l/vidioc-enumstd.xml"> +<!ENTITY g-audio SYSTEM "v4l/vidioc-g-audio.xml"> +<!ENTITY g-audioout SYSTEM "v4l/vidioc-g-audioout.xml"> +<!ENTITY dbg-g-chip-ident SYSTEM "v4l/vidioc-dbg-g-chip-ident.xml"> +<!ENTITY g-crop SYSTEM "v4l/vidioc-g-crop.xml"> +<!ENTITY g-ctrl SYSTEM "v4l/vidioc-g-ctrl.xml"> +<!ENTITY g-enc-index SYSTEM "v4l/vidioc-g-enc-index.xml"> +<!ENTITY g-ext-ctrls SYSTEM "v4l/vidioc-g-ext-ctrls.xml"> +<!ENTITY g-fbuf SYSTEM "v4l/vidioc-g-fbuf.xml"> +<!ENTITY g-fmt SYSTEM "v4l/vidioc-g-fmt.xml"> +<!ENTITY g-frequency SYSTEM "v4l/vidioc-g-frequency.xml"> +<!ENTITY g-input SYSTEM "v4l/vidioc-g-input.xml"> +<!ENTITY g-jpegcomp SYSTEM "v4l/vidioc-g-jpegcomp.xml"> +<!ENTITY g-modulator SYSTEM "v4l/vidioc-g-modulator.xml"> +<!ENTITY g-output SYSTEM "v4l/vidioc-g-output.xml"> +<!ENTITY g-parm SYSTEM "v4l/vidioc-g-parm.xml"> +<!ENTITY g-priority SYSTEM "v4l/vidioc-g-priority.xml"> +<!ENTITY g-sliced-vbi-cap SYSTEM "v4l/vidioc-g-sliced-vbi-cap.xml"> +<!ENTITY g-std SYSTEM "v4l/vidioc-g-std.xml"> +<!ENTITY g-tuner SYSTEM "v4l/vidioc-g-tuner.xml"> +<!ENTITY log-status SYSTEM "v4l/vidioc-log-status.xml"> +<!ENTITY overlay SYSTEM "v4l/vidioc-overlay.xml"> +<!ENTITY qbuf SYSTEM "v4l/vidioc-qbuf.xml"> +<!ENTITY querybuf SYSTEM "v4l/vidioc-querybuf.xml"> +<!ENTITY querycap SYSTEM "v4l/vidioc-querycap.xml"> +<!ENTITY queryctrl SYSTEM "v4l/vidioc-queryctrl.xml"> +<!ENTITY querystd SYSTEM "v4l/vidioc-querystd.xml"> +<!ENTITY reqbufs SYSTEM "v4l/vidioc-reqbufs.xml"> +<!ENTITY s-hw-freq-seek SYSTEM "v4l/vidioc-s-hw-freq-seek.xml"> +<!ENTITY streamon SYSTEM "v4l/vidioc-streamon.xml"> diff --git a/Documentation/DocBook/media-indices.tmpl b/Documentation/DocBook/media-indices.tmpl new file mode 100644 index 000000000000..78d6031de001 --- /dev/null +++ b/Documentation/DocBook/media-indices.tmpl @@ -0,0 +1,89 @@ +<!-- Generated file! Do not edit. --> + +<index><title>List of Types</title> +<indexentry><primaryie><link linkend='v4l2-std-id'>v4l2_std_id</link></primaryie></indexentry> +<indexentry><primaryie>enum <link linkend='v4l2-buf-type'>v4l2_buf_type</link></primaryie></indexentry> +<indexentry><primaryie>enum <link linkend='v4l2-colorspace'>v4l2_colorspace</link></primaryie></indexentry> +<indexentry><primaryie>enum <link linkend='v4l2-ctrl-type'>v4l2_ctrl_type</link></primaryie></indexentry> +<indexentry><primaryie>enum <link linkend='v4l2-exposure-auto-type'>v4l2_exposure_auto_type</link></primaryie></indexentry> +<indexentry><primaryie>enum <link linkend='v4l2-field'>v4l2_field</link></primaryie></indexentry> +<indexentry><primaryie>enum <link linkend='v4l2-frmivaltypes'>v4l2_frmivaltypes</link></primaryie></indexentry> +<indexentry><primaryie>enum <link linkend='v4l2-frmsizetypes'>v4l2_frmsizetypes</link></primaryie></indexentry> +<indexentry><primaryie>enum <link linkend='v4l2-memory'>v4l2_memory</link></primaryie></indexentry> +<indexentry><primaryie>enum <link linkend='v4l2-mpeg-audio-ac3-bitrate'>v4l2_mpeg_audio_ac3_bitrate</link></primaryie></indexentry> +<indexentry><primaryie>enum <link linkend='v4l2-mpeg-audio-crc'>v4l2_mpeg_audio_crc</link></primaryie></indexentry> +<indexentry><primaryie>enum <link linkend='v4l2-mpeg-audio-emphasis'>v4l2_mpeg_audio_emphasis</link></primaryie></indexentry> +<indexentry><primaryie>enum <link linkend='v4l2-mpeg-audio-encoding'>v4l2_mpeg_audio_encoding</link></primaryie></indexentry> +<indexentry><primaryie>enum <link linkend='v4l2-mpeg-audio-l1-bitrate'>v4l2_mpeg_audio_l1_bitrate</link></primaryie></indexentry> +<indexentry><primaryie>enum <link linkend='v4l2-mpeg-audio-l2-bitrate'>v4l2_mpeg_audio_l2_bitrate</link></primaryie></indexentry> +<indexentry><primaryie>enum <link linkend='v4l2-mpeg-audio-l3-bitrate'>v4l2_mpeg_audio_l3_bitrate</link></primaryie></indexentry> +<indexentry><primaryie>enum <link linkend='v4l2-mpeg-audio-mode'>v4l2_mpeg_audio_mode</link></primaryie></indexentry> +<indexentry><primaryie>enum <link linkend='v4l2-mpeg-audio-mode-extension'>v4l2_mpeg_audio_mode_extension</link></primaryie></indexentry> +<indexentry><primaryie>enum <link linkend='v4l2-mpeg-audio-sampling-freq'>v4l2_mpeg_audio_sampling_freq</link></primaryie></indexentry> +<indexentry><primaryie>enum <link linkend='chroma-spatial-filter-type'>v4l2_mpeg_cx2341x_video_chroma_spatial_filter_type</link></primaryie></indexentry> +<indexentry><primaryie>enum <link linkend='luma-spatial-filter-type'>v4l2_mpeg_cx2341x_video_luma_spatial_filter_type</link></primaryie></indexentry> +<indexentry><primaryie>enum <link linkend='v4l2-mpeg-cx2341x-video-median-filter-type'>v4l2_mpeg_cx2341x_video_median_filter_type</link></primaryie></indexentry> +<indexentry><primaryie>enum <link linkend='v4l2-mpeg-cx2341x-video-spatial-filter-mode'>v4l2_mpeg_cx2341x_video_spatial_filter_mode</link></primaryie></indexentry> +<indexentry><primaryie>enum <link linkend='v4l2-mpeg-cx2341x-video-temporal-filter-mode'>v4l2_mpeg_cx2341x_video_temporal_filter_mode</link></primaryie></indexentry> +<indexentry><primaryie>enum <link linkend='v4l2-mpeg-stream-type'>v4l2_mpeg_stream_type</link></primaryie></indexentry> +<indexentry><primaryie>enum <link linkend='v4l2-mpeg-stream-vbi-fmt'>v4l2_mpeg_stream_vbi_fmt</link></primaryie></indexentry> +<indexentry><primaryie>enum <link linkend='v4l2-mpeg-video-aspect'>v4l2_mpeg_video_aspect</link></primaryie></indexentry> +<indexentry><primaryie>enum <link linkend='v4l2-mpeg-video-bitrate-mode'>v4l2_mpeg_video_bitrate_mode</link></primaryie></indexentry> +<indexentry><primaryie>enum <link linkend='v4l2-mpeg-video-encoding'>v4l2_mpeg_video_encoding</link></primaryie></indexentry> +<indexentry><primaryie>enum <link linkend='v4l2-power-line-frequency'>v4l2_power_line_frequency</link></primaryie></indexentry> +<indexentry><primaryie>enum <link linkend='v4l2-priority'>v4l2_priority</link></primaryie></indexentry> +<indexentry><primaryie>enum <link linkend='v4l2-tuner-type'>v4l2_tuner_type</link></primaryie></indexentry> +<indexentry><primaryie>enum <link linkend='v4l2-preemphasis'>v4l2_preemphasis</link></primaryie></indexentry> +<indexentry><primaryie>struct <link linkend='v4l2-audio'>v4l2_audio</link></primaryie></indexentry> +<indexentry><primaryie>struct <link linkend='v4l2-audioout'>v4l2_audioout</link></primaryie></indexentry> +<indexentry><primaryie>struct <link linkend='v4l2-bt-timings'>v4l2_bt_timings</link></primaryie></indexentry> +<indexentry><primaryie>struct <link linkend='v4l2-buffer'>v4l2_buffer</link></primaryie></indexentry> +<indexentry><primaryie>struct <link linkend='v4l2-capability'>v4l2_capability</link></primaryie></indexentry> +<indexentry><primaryie>struct <link linkend='v4l2-captureparm'>v4l2_captureparm</link></primaryie></indexentry> +<indexentry><primaryie>struct <link linkend='v4l2-clip'>v4l2_clip</link></primaryie></indexentry> +<indexentry><primaryie>struct <link linkend='v4l2-control'>v4l2_control</link></primaryie></indexentry> +<indexentry><primaryie>struct <link linkend='v4l2-crop'>v4l2_crop</link></primaryie></indexentry> +<indexentry><primaryie>struct <link linkend='v4l2-cropcap'>v4l2_cropcap</link></primaryie></indexentry> +<indexentry><primaryie>struct <link linkend='v4l2-dbg-chip-ident'>v4l2_dbg_chip_ident</link></primaryie></indexentry> +<indexentry><primaryie>struct <link linkend='v4l2-dbg-match'>v4l2_dbg_match</link></primaryie></indexentry> +<indexentry><primaryie>struct <link linkend='v4l2-dbg-register'>v4l2_dbg_register</link></primaryie></indexentry> +<indexentry><primaryie>struct <link linkend='v4l2-dv-enum-preset'>v4l2_dv_enum_preset</link></primaryie></indexentry> +<indexentry><primaryie>struct <link linkend='v4l2-dv-preset'>v4l2_dv_preset</link></primaryie></indexentry> +<indexentry><primaryie>struct <link linkend='v4l2-dv-timings'>v4l2_dv_timings</link></primaryie></indexentry> +<indexentry><primaryie>struct <link linkend='v4l2-enc-idx'>v4l2_enc_idx</link></primaryie></indexentry> +<indexentry><primaryie>struct <link linkend='v4l2-enc-idx-entry'>v4l2_enc_idx_entry</link></primaryie></indexentry> +<indexentry><primaryie>struct <link linkend='v4l2-encoder-cmd'>v4l2_encoder_cmd</link></primaryie></indexentry> +<indexentry><primaryie>struct <link linkend='v4l2-ext-control'>v4l2_ext_control</link></primaryie></indexentry> +<indexentry><primaryie>struct <link linkend='v4l2-ext-controls'>v4l2_ext_controls</link></primaryie></indexentry> +<indexentry><primaryie>struct <link linkend='v4l2-fmtdesc'>v4l2_fmtdesc</link></primaryie></indexentry> +<indexentry><primaryie>struct <link linkend='v4l2-format'>v4l2_format</link></primaryie></indexentry> +<indexentry><primaryie>struct <link linkend='v4l2-fract'>v4l2_fract</link></primaryie></indexentry> +<indexentry><primaryie>struct <link linkend='v4l2-framebuffer'>v4l2_framebuffer</link></primaryie></indexentry> +<indexentry><primaryie>struct <link linkend='v4l2-frequency'>v4l2_frequency</link></primaryie></indexentry> +<indexentry><primaryie>struct <link linkend='v4l2-frmival-stepwise'>v4l2_frmival_stepwise</link></primaryie></indexentry> +<indexentry><primaryie>struct <link linkend='v4l2-frmivalenum'>v4l2_frmivalenum</link></primaryie></indexentry> +<indexentry><primaryie>struct <link linkend='v4l2-frmsize-discrete'>v4l2_frmsize_discrete</link></primaryie></indexentry> +<indexentry><primaryie>struct <link linkend='v4l2-frmsize-stepwise'>v4l2_frmsize_stepwise</link></primaryie></indexentry> +<indexentry><primaryie>struct <link linkend='v4l2-frmsizeenum'>v4l2_frmsizeenum</link></primaryie></indexentry> +<indexentry><primaryie>struct <link linkend='v4l2-hw-freq-seek'>v4l2_hw_freq_seek</link></primaryie></indexentry> +<indexentry><primaryie>struct <link linkend='v4l2-input'>v4l2_input</link></primaryie></indexentry> +<indexentry><primaryie>struct <link linkend='v4l2-jpegcompression'>v4l2_jpegcompression</link></primaryie></indexentry> +<indexentry><primaryie>struct <link linkend='v4l2-modulator'>v4l2_modulator</link></primaryie></indexentry> +<indexentry><primaryie>struct <link linkend='v4l2-mpeg-vbi-fmt-ivtv'>v4l2_mpeg_vbi_fmt_ivtv</link></primaryie></indexentry> +<indexentry><primaryie>struct <link linkend='v4l2-output'>v4l2_output</link></primaryie></indexentry> +<indexentry><primaryie>struct <link linkend='v4l2-outputparm'>v4l2_outputparm</link></primaryie></indexentry> +<indexentry><primaryie>struct <link linkend='v4l2-pix-format'>v4l2_pix_format</link></primaryie></indexentry> +<indexentry><primaryie>struct <link linkend='v4l2-queryctrl'>v4l2_queryctrl</link></primaryie></indexentry> +<indexentry><primaryie>struct <link linkend='v4l2-querymenu'>v4l2_querymenu</link></primaryie></indexentry> +<indexentry><primaryie>struct <link linkend='v4l2-rect'>v4l2_rect</link></primaryie></indexentry> +<indexentry><primaryie>struct <link linkend='v4l2-requestbuffers'>v4l2_requestbuffers</link></primaryie></indexentry> +<indexentry><primaryie>struct <link linkend='v4l2-sliced-vbi-cap'>v4l2_sliced_vbi_cap</link></primaryie></indexentry> +<indexentry><primaryie>struct <link linkend='v4l2-sliced-vbi-data'>v4l2_sliced_vbi_data</link></primaryie></indexentry> +<indexentry><primaryie>struct <link linkend='v4l2-sliced-vbi-format'>v4l2_sliced_vbi_format</link></primaryie></indexentry> +<indexentry><primaryie>struct <link linkend='v4l2-standard'>v4l2_standard</link></primaryie></indexentry> +<indexentry><primaryie>struct <link linkend='v4l2-streamparm'>v4l2_streamparm</link></primaryie></indexentry> +<indexentry><primaryie>struct <link linkend='v4l2-timecode'>v4l2_timecode</link></primaryie></indexentry> +<indexentry><primaryie>struct <link linkend='v4l2-tuner'>v4l2_tuner</link></primaryie></indexentry> +<indexentry><primaryie>struct <link linkend='v4l2-vbi-format'>v4l2_vbi_format</link></primaryie></indexentry> +<indexentry><primaryie>struct <link linkend='v4l2-window'>v4l2_window</link></primaryie></indexentry> +</index> diff --git a/Documentation/DocBook/media.tmpl b/Documentation/DocBook/media.tmpl new file mode 100644 index 000000000000..eea564bb12cb --- /dev/null +++ b/Documentation/DocBook/media.tmpl @@ -0,0 +1,112 @@ +<?xml version="1.0"?> +<!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook XML V4.1.2//EN" + "http://www.oasis-open.org/docbook/xml/4.1.2/docbookx.dtd" [ +<!ENTITY % media-entities SYSTEM "./media-entities.tmpl"> %media-entities; +<!ENTITY media-indices SYSTEM "./media-indices.tmpl"> + +<!ENTITY eg "e. g."> +<!ENTITY ie "i. e."> +<!ENTITY fd "File descriptor returned by <link linkend='func-open'><function>open()</function></link>."> +<!ENTITY i2c "I<superscript>2</superscript>C"> +<!ENTITY return-value "<title>Return Value</title><para>On success <returnvalue>0</returnvalue> is returned, on error <returnvalue>-1</returnvalue> and the <varname>errno</varname> variable is set appropriately:</para>"> +<!ENTITY manvol "<manvolnum>2</manvolnum>"> + +<!-- Table templates: structs, structs w/union, defines. --> +<!ENTITY cs-str "<colspec colname='c1' colwidth='1*' /><colspec colname='c2' colwidth='1*' /><colspec colname='c3' colwidth='2*' /><spanspec spanname='hspan' namest='c1' nameend='c3' />"> +<!ENTITY cs-ustr "<colspec colname='c1' colwidth='1*' /><colspec colname='c2' colwidth='1*' /><colspec colname='c3' colwidth='1*' /><colspec colname='c4' colwidth='2*' /><spanspec spanname='hspan' namest='c1' nameend='c4' />"> +<!ENTITY cs-def "<colspec colname='c1' colwidth='3*' /><colspec colname='c2' colwidth='1*' /><colspec colname='c3' colwidth='4*' /><spanspec spanname='hspan' namest='c1' nameend='c3' />"> + +<!-- Video for Linux mailing list address. --> +<!ENTITY v4l-ml "<ulink url='http://www.linuxtv.org/lists.php'>http://www.linuxtv.org/lists.php</ulink>"> + +<!-- LinuxTV v4l-dvb repository. --> +<!ENTITY v4l-dvb "<ulink url='http://linuxtv.org/repo/'>http://linuxtv.org/repo/</ulink>"> +]> + +<book id="media_api"> +<bookinfo> +<title>LINUX MEDIA INFRASTRUCTURE API</title> + +<copyright> + <year>2009</year> + <holder>LinuxTV Developers</holder> +</copyright> + +<legalnotice> + +<para>Permission is granted to copy, distribute and/or modify +this document under the terms of the GNU Free Documentation License, +Version 1.1 or any later version published by the Free Software +Foundation. A copy of the license is included in the chapter entitled +"GNU Free Documentation License"</para> +</legalnotice> + +</bookinfo> + +<toc></toc> <!-- autogenerated --> + +<preface> + <title>Introduction</title> + + <para>This document covers the Linux Kernel to Userspace API's used by + video and radio straming devices, including video cameras, + analog and digital TV receiver cards, AM/FM receiver cards, + streaming capture devices.</para> + <para>It is divided into three parts.</para> + <para>The first part covers radio, capture, + cameras and analog TV devices.</para> + <para>The second part covers the + API used for digital TV and Internet reception via one of the + several digital tv standards. While it is called as DVB API, + in fact it covers several different video standards including + DVB-T, DVB-S, DVB-C and ATSC. The API is currently being updated + to documment support also for DVB-S2, ISDB-T and ISDB-S.</para> + <para>The third part covers other API's used by all media infrastructure devices</para> + <para>For additional information and for the latest development code, + see: <ulink url="http://linuxtv.org">http://linuxtv.org</ulink>.</para> + <para>For discussing improvements, reporting troubles, sending new drivers, etc, please mail to: <ulink url="http://vger.kernel.org/vger-lists.html#linux-media">Linux Media Mailing List (LMML).</ulink>.</para> + +</preface> + +<part id="v4l2spec"> +&sub-v4l2; +</part> +<part id="dvbapi"> +&sub-dvbapi; +</part> +<part id="v4ldvb_common"> +<partinfo> +<authorgroup> +<author> +<firstname>Mauro</firstname> +<surname>Chehab</surname> +<othername role="mi">Carvalho</othername> +<affiliation><address><email>mchehab@redhat.com</email></address></affiliation> +<contrib>Initial version.</contrib> +</author> +</authorgroup> +<copyright> + <year>2009</year> + <holder>Mauro Carvalho Chehab</holder> +</copyright> + +<revhistory> +<!-- Put document revisions here, newest first. --> +<revision> +<revnumber>1.0.0</revnumber> +<date>2009-09-06</date> +<authorinitials>mcc</authorinitials> +<revremark>Initial revision</revremark> +</revision> +</revhistory> +</partinfo> + +<title>Other API's used by media infrastructure drivers</title> +<chapter id="remote_controllers"> +&sub-remote_controllers; +</chapter> +</part> + +&sub-fdl-appendix; + +</book> diff --git a/Documentation/DocBook/mtdnand.tmpl b/Documentation/DocBook/mtdnand.tmpl index 8e145857fc9d..5e7d84b48505 100644 --- a/Documentation/DocBook/mtdnand.tmpl +++ b/Documentation/DocBook/mtdnand.tmpl @@ -174,7 +174,7 @@ </para> <programlisting> static struct mtd_info *board_mtd; -static unsigned long baseaddr; +static void __iomem *baseaddr; </programlisting> <para> Static example @@ -182,7 +182,7 @@ static unsigned long baseaddr; <programlisting> static struct mtd_info board_mtd; static struct nand_chip board_chip; -static unsigned long baseaddr; +static void __iomem *baseaddr; </programlisting> </sect1> <sect1 id="Partition_defines"> @@ -283,8 +283,8 @@ int __init board_init (void) } /* map physical address */ - baseaddr = (unsigned long)ioremap(CHIP_PHYSICAL_ADDRESS, 1024); - if(!baseaddr){ + baseaddr = ioremap(CHIP_PHYSICAL_ADDRESS, 1024); + if (!baseaddr) { printk("Ioremap to access NAND chip failed\n"); err = -EIO; goto out_mtd; @@ -316,7 +316,7 @@ int __init board_init (void) goto out; out_ior: - iounmap((void *)baseaddr); + iounmap(baseaddr); out_mtd: kfree (board_mtd); out: @@ -341,7 +341,7 @@ static void __exit board_cleanup (void) nand_release (board_mtd); /* unmap physical address */ - iounmap((void *)baseaddr); + iounmap(baseaddr); /* Free the MTD device structure */ kfree (board_mtd); @@ -362,7 +362,7 @@ module_exit(board_cleanup); <sect1 id="Multiple_chip_control"> <title>Multiple chip control</title> <para> - The nand driver can control chip arrays. Therefor the + The nand driver can control chip arrays. Therefore the board driver must provide an own select_chip function. This function must (de)select the requested chip. The function pointer in the nand_chip structure must @@ -568,7 +568,7 @@ static void board_select_chip (struct mtd_info *mtd, int chip) <para> The blocks in which the tables are stored are procteted against accidental access by marking them bad in the memory bad block - table. The bad block table managment functions are allowed + table. The bad block table management functions are allowed to circumvernt this protection. </para> <para> diff --git a/Documentation/DocBook/procfs-guide.tmpl b/Documentation/DocBook/procfs-guide.tmpl deleted file mode 100644 index 9eba4b7af73d..000000000000 --- a/Documentation/DocBook/procfs-guide.tmpl +++ /dev/null @@ -1,626 +0,0 @@ -<?xml version="1.0" encoding="UTF-8"?> -<!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook XML V4.1.2//EN" - "http://www.oasis-open.org/docbook/xml/4.1.2/docbookx.dtd" [ -<!ENTITY procfsexample SYSTEM "procfs_example.xml"> -]> - -<book id="LKProcfsGuide"> - <bookinfo> - <title>Linux Kernel Procfs Guide</title> - - <authorgroup> - <author> - <firstname>Erik</firstname> - <othername>(J.A.K.)</othername> - <surname>Mouw</surname> - <affiliation> - <address> - <email>mouw@nl.linux.org</email> - </address> - </affiliation> - </author> - <othercredit> - <contrib> - This software and documentation were written while working on the - LART computing board - (<ulink url="http://www.lartmaker.nl/">http://www.lartmaker.nl/</ulink>), - which was sponsored by the Delt University of Technology projects - Mobile Multi-media Communications and Ubiquitous Communications. - </contrib> - </othercredit> - </authorgroup> - - <revhistory> - <revision> - <revnumber>1.0</revnumber> - <date>May 30, 2001</date> - <revremark>Initial revision posted to linux-kernel</revremark> - </revision> - <revision> - <revnumber>1.1</revnumber> - <date>June 3, 2001</date> - <revremark>Revised after comments from linux-kernel</revremark> - </revision> - </revhistory> - - <copyright> - <year>2001</year> - <holder>Erik Mouw</holder> - </copyright> - - - <legalnotice> - <para> - This documentation is free software; you can redistribute it - and/or modify it under the terms of the GNU General Public - License as published by the Free Software Foundation; either - version 2 of the License, or (at your option) any later - version. - </para> - - <para> - This documentation is distributed in the hope that it will be - useful, but WITHOUT ANY WARRANTY; without even the implied - warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR - PURPOSE. See the GNU General Public License for more details. - </para> - - <para> - You should have received a copy of the GNU General Public - License along with this program; if not, write to the Free - Software Foundation, Inc., 59 Temple Place, Suite 330, Boston, - MA 02111-1307 USA - </para> - - <para> - For more details see the file COPYING in the source - distribution of Linux. - </para> - </legalnotice> - </bookinfo> - - - - - <toc> - </toc> - - - - - <preface id="Preface"> - <title>Preface</title> - - <para> - This guide describes the use of the procfs file system from - within the Linux kernel. The idea to write this guide came up on - the #kernelnewbies IRC channel (see <ulink - url="http://www.kernelnewbies.org/">http://www.kernelnewbies.org/</ulink>), - when Jeff Garzik explained the use of procfs and forwarded me a - message Alexander Viro wrote to the linux-kernel mailing list. I - agreed to write it up nicely, so here it is. - </para> - - <para> - I'd like to thank Jeff Garzik - <email>jgarzik@pobox.com</email> and Alexander Viro - <email>viro@parcelfarce.linux.theplanet.co.uk</email> for their input, - Tim Waugh <email>twaugh@redhat.com</email> for his <ulink - url="http://people.redhat.com/twaugh/docbook/selfdocbook/">Selfdocbook</ulink>, - and Marc Joosen <email>marcj@historia.et.tudelft.nl</email> for - proofreading. - </para> - - <para> - Erik - </para> - </preface> - - - - - <chapter id="intro"> - <title>Introduction</title> - - <para> - The <filename class="directory">/proc</filename> file system - (procfs) is a special file system in the linux kernel. It's a - virtual file system: it is not associated with a block device - but exists only in memory. The files in the procfs are there to - allow userland programs access to certain information from the - kernel (like process information in <filename - class="directory">/proc/[0-9]+/</filename>), but also for debug - purposes (like <filename>/proc/ksyms</filename>). - </para> - - <para> - This guide describes the use of the procfs file system from - within the Linux kernel. It starts by introducing all relevant - functions to manage the files within the file system. After that - it shows how to communicate with userland, and some tips and - tricks will be pointed out. Finally a complete example will be - shown. - </para> - - <para> - Note that the files in <filename - class="directory">/proc/sys</filename> are sysctl files: they - don't belong to procfs and are governed by a completely - different API described in the Kernel API book. - </para> - </chapter> - - - - - <chapter id="managing"> - <title>Managing procfs entries</title> - - <para> - This chapter describes the functions that various kernel - components use to populate the procfs with files, symlinks, - device nodes, and directories. - </para> - - <para> - A minor note before we start: if you want to use any of the - procfs functions, be sure to include the correct header file! - This should be one of the first lines in your code: - </para> - - <programlisting> -#include <linux/proc_fs.h> - </programlisting> - - - - - <sect1 id="regularfile"> - <title>Creating a regular file</title> - - <funcsynopsis> - <funcprototype> - <funcdef>struct proc_dir_entry* <function>create_proc_entry</function></funcdef> - <paramdef>const char* <parameter>name</parameter></paramdef> - <paramdef>mode_t <parameter>mode</parameter></paramdef> - <paramdef>struct proc_dir_entry* <parameter>parent</parameter></paramdef> - </funcprototype> - </funcsynopsis> - - <para> - This function creates a regular file with the name - <parameter>name</parameter>, file mode - <parameter>mode</parameter> in the directory - <parameter>parent</parameter>. To create a file in the root of - the procfs, use <constant>NULL</constant> as - <parameter>parent</parameter> parameter. When successful, the - function will return a pointer to the freshly created - <structname>struct proc_dir_entry</structname>; otherwise it - will return <constant>NULL</constant>. <xref - linkend="userland"/> describes how to do something useful with - regular files. - </para> - - <para> - Note that it is specifically supported that you can pass a - path that spans multiple directories. For example - <function>create_proc_entry</function>(<parameter>"drivers/via0/info"</parameter>) - will create the <filename class="directory">via0</filename> - directory if necessary, with standard - <constant>0755</constant> permissions. - </para> - - <para> - If you only want to be able to read the file, the function - <function>create_proc_read_entry</function> described in <xref - linkend="convenience"/> may be used to create and initialise - the procfs entry in one single call. - </para> - </sect1> - - - - - <sect1 id="Creating_a_symlink"> - <title>Creating a symlink</title> - - <funcsynopsis> - <funcprototype> - <funcdef>struct proc_dir_entry* - <function>proc_symlink</function></funcdef> <paramdef>const - char* <parameter>name</parameter></paramdef> - <paramdef>struct proc_dir_entry* - <parameter>parent</parameter></paramdef> <paramdef>const - char* <parameter>dest</parameter></paramdef> - </funcprototype> - </funcsynopsis> - - <para> - This creates a symlink in the procfs directory - <parameter>parent</parameter> that points from - <parameter>name</parameter> to - <parameter>dest</parameter>. This translates in userland to - <literal>ln -s</literal> <parameter>dest</parameter> - <parameter>name</parameter>. - </para> - </sect1> - - <sect1 id="Creating_a_directory"> - <title>Creating a directory</title> - - <funcsynopsis> - <funcprototype> - <funcdef>struct proc_dir_entry* <function>proc_mkdir</function></funcdef> - <paramdef>const char* <parameter>name</parameter></paramdef> - <paramdef>struct proc_dir_entry* <parameter>parent</parameter></paramdef> - </funcprototype> - </funcsynopsis> - - <para> - Create a directory <parameter>name</parameter> in the procfs - directory <parameter>parent</parameter>. - </para> - </sect1> - - - - - <sect1 id="Removing_an_entry"> - <title>Removing an entry</title> - - <funcsynopsis> - <funcprototype> - <funcdef>void <function>remove_proc_entry</function></funcdef> - <paramdef>const char* <parameter>name</parameter></paramdef> - <paramdef>struct proc_dir_entry* <parameter>parent</parameter></paramdef> - </funcprototype> - </funcsynopsis> - - <para> - Removes the entry <parameter>name</parameter> in the directory - <parameter>parent</parameter> from the procfs. Entries are - removed by their <emphasis>name</emphasis>, not by the - <structname>struct proc_dir_entry</structname> returned by the - various create functions. Note that this function doesn't - recursively remove entries. - </para> - - <para> - Be sure to free the <structfield>data</structfield> entry from - the <structname>struct proc_dir_entry</structname> before - <function>remove_proc_entry</function> is called (that is: if - there was some <structfield>data</structfield> allocated, of - course). See <xref linkend="usingdata"/> for more information - on using the <structfield>data</structfield> entry. - </para> - </sect1> - </chapter> - - - - - <chapter id="userland"> - <title>Communicating with userland</title> - - <para> - Instead of reading (or writing) information directly from - kernel memory, procfs works with <emphasis>call back - functions</emphasis> for files: functions that are called when - a specific file is being read or written. Such functions have - to be initialised after the procfs file is created by setting - the <structfield>read_proc</structfield> and/or - <structfield>write_proc</structfield> fields in the - <structname>struct proc_dir_entry*</structname> that the - function <function>create_proc_entry</function> returned: - </para> - - <programlisting> -struct proc_dir_entry* entry; - -entry->read_proc = read_proc_foo; -entry->write_proc = write_proc_foo; - </programlisting> - - <para> - If you only want to use a the - <structfield>read_proc</structfield>, the function - <function>create_proc_read_entry</function> described in <xref - linkend="convenience"/> may be used to create and initialise the - procfs entry in one single call. - </para> - - - - <sect1 id="Reading_data"> - <title>Reading data</title> - - <para> - The read function is a call back function that allows userland - processes to read data from the kernel. The read function - should have the following format: - </para> - - <funcsynopsis> - <funcprototype> - <funcdef>int <function>read_func</function></funcdef> - <paramdef>char* <parameter>buffer</parameter></paramdef> - <paramdef>char** <parameter>start</parameter></paramdef> - <paramdef>off_t <parameter>off</parameter></paramdef> - <paramdef>int <parameter>count</parameter></paramdef> - <paramdef>int* <parameter>peof</parameter></paramdef> - <paramdef>void* <parameter>data</parameter></paramdef> - </funcprototype> - </funcsynopsis> - - <para> - The read function should write its information into the - <parameter>buffer</parameter>, which will be exactly - <literal>PAGE_SIZE</literal> bytes long. - </para> - - <para> - The parameter - <parameter>peof</parameter> should be used to signal that the - end of the file has been reached by writing - <literal>1</literal> to the memory location - <parameter>peof</parameter> points to. - </para> - - <para> - The <parameter>data</parameter> - parameter can be used to create a single call back function for - several files, see <xref linkend="usingdata"/>. - </para> - - <para> - The rest of the parameters and the return value are described - by a comment in <filename>fs/proc/generic.c</filename> as follows: - </para> - - <blockquote> - <para> - You have three ways to return data: - </para> - <orderedlist> - <listitem> - <para> - Leave <literal>*start = NULL</literal>. (This is the default.) - Put the data of the requested offset at that - offset within the buffer. Return the number (<literal>n</literal>) - of bytes there are from the beginning of the - buffer up to the last byte of data. If the - number of supplied bytes (<literal>= n - offset</literal>) is - greater than zero and you didn't signal eof - and the reader is prepared to take more data - you will be called again with the requested - offset advanced by the number of bytes - absorbed. This interface is useful for files - no larger than the buffer. - </para> - </listitem> - <listitem> - <para> - Set <literal>*start</literal> to an unsigned long value less than - the buffer address but greater than zero. - Put the data of the requested offset at the - beginning of the buffer. Return the number of - bytes of data placed there. If this number is - greater than zero and you didn't signal eof - and the reader is prepared to take more data - you will be called again with the requested - offset advanced by <literal>*start</literal>. This interface is - useful when you have a large file consisting - of a series of blocks which you want to count - and return as wholes. - (Hack by Paul.Russell@rustcorp.com.au) - </para> - </listitem> - <listitem> - <para> - Set <literal>*start</literal> to an address within the buffer. - Put the data of the requested offset at <literal>*start</literal>. - Return the number of bytes of data placed there. - If this number is greater than zero and you - didn't signal eof and the reader is prepared to - take more data you will be called again with the - requested offset advanced by the number of bytes - absorbed. - </para> - </listitem> - </orderedlist> - </blockquote> - - <para> - <xref linkend="example"/> shows how to use a read call back - function. - </para> - </sect1> - - - - - <sect1 id="Writing_data"> - <title>Writing data</title> - - <para> - The write call back function allows a userland process to write - data to the kernel, so it has some kind of control over the - kernel. The write function should have the following format: - </para> - - <funcsynopsis> - <funcprototype> - <funcdef>int <function>write_func</function></funcdef> - <paramdef>struct file* <parameter>file</parameter></paramdef> - <paramdef>const char* <parameter>buffer</parameter></paramdef> - <paramdef>unsigned long <parameter>count</parameter></paramdef> - <paramdef>void* <parameter>data</parameter></paramdef> - </funcprototype> - </funcsynopsis> - - <para> - The write function should read <parameter>count</parameter> - bytes at maximum from the <parameter>buffer</parameter>. Note - that the <parameter>buffer</parameter> doesn't live in the - kernel's memory space, so it should first be copied to kernel - space with <function>copy_from_user</function>. The - <parameter>file</parameter> parameter is usually - ignored. <xref linkend="usingdata"/> shows how to use the - <parameter>data</parameter> parameter. - </para> - - <para> - Again, <xref linkend="example"/> shows how to use this call back - function. - </para> - </sect1> - - - - - <sect1 id="usingdata"> - <title>A single call back for many files</title> - - <para> - When a large number of almost identical files is used, it's - quite inconvenient to use a separate call back function for - each file. A better approach is to have a single call back - function that distinguishes between the files by using the - <structfield>data</structfield> field in <structname>struct - proc_dir_entry</structname>. First of all, the - <structfield>data</structfield> field has to be initialised: - </para> - - <programlisting> -struct proc_dir_entry* entry; -struct my_file_data *file_data; - -file_data = kmalloc(sizeof(struct my_file_data), GFP_KERNEL); -entry->data = file_data; - </programlisting> - - <para> - The <structfield>data</structfield> field is a <type>void - *</type>, so it can be initialised with anything. - </para> - - <para> - Now that the <structfield>data</structfield> field is set, the - <function>read_proc</function> and - <function>write_proc</function> can use it to distinguish - between files because they get it passed into their - <parameter>data</parameter> parameter: - </para> - - <programlisting> -int foo_read_func(char *page, char **start, off_t off, - int count, int *eof, void *data) -{ - int len; - - if(data == file_data) { - /* special case for this file */ - } else { - /* normal processing */ - } - - return len; -} - </programlisting> - - <para> - Be sure to free the <structfield>data</structfield> data field - when removing the procfs entry. - </para> - </sect1> - </chapter> - - - - - <chapter id="tips"> - <title>Tips and tricks</title> - - - - - <sect1 id="convenience"> - <title>Convenience functions</title> - - <funcsynopsis> - <funcprototype> - <funcdef>struct proc_dir_entry* <function>create_proc_read_entry</function></funcdef> - <paramdef>const char* <parameter>name</parameter></paramdef> - <paramdef>mode_t <parameter>mode</parameter></paramdef> - <paramdef>struct proc_dir_entry* <parameter>parent</parameter></paramdef> - <paramdef>read_proc_t* <parameter>read_proc</parameter></paramdef> - <paramdef>void* <parameter>data</parameter></paramdef> - </funcprototype> - </funcsynopsis> - - <para> - This function creates a regular file in exactly the same way - as <function>create_proc_entry</function> from <xref - linkend="regularfile"/> does, but also allows to set the read - function <parameter>read_proc</parameter> in one call. This - function can set the <parameter>data</parameter> as well, like - explained in <xref linkend="usingdata"/>. - </para> - </sect1> - - - - <sect1 id="Modules"> - <title>Modules</title> - - <para> - If procfs is being used from within a module, be sure to set - the <structfield>owner</structfield> field in the - <structname>struct proc_dir_entry</structname> to - <constant>THIS_MODULE</constant>. - </para> - - <programlisting> -struct proc_dir_entry* entry; - -entry->owner = THIS_MODULE; - </programlisting> - </sect1> - - - - - <sect1 id="Mode_and_ownership"> - <title>Mode and ownership</title> - - <para> - Sometimes it is useful to change the mode and/or ownership of - a procfs entry. Here is an example that shows how to achieve - that: - </para> - - <programlisting> -struct proc_dir_entry* entry; - -entry->mode = S_IWUSR |S_IRUSR | S_IRGRP | S_IROTH; -entry->uid = 0; -entry->gid = 100; - </programlisting> - - </sect1> - </chapter> - - - - - <chapter id="example"> - <title>Example</title> - - <!-- be careful with the example code: it shouldn't be wider than - approx. 60 columns, or otherwise it won't fit properly on a page - --> - -&procfsexample; - - </chapter> -</book> diff --git a/Documentation/DocBook/procfs_example.c b/Documentation/DocBook/procfs_example.c deleted file mode 100644 index a5b11793b1e0..000000000000 --- a/Documentation/DocBook/procfs_example.c +++ /dev/null @@ -1,201 +0,0 @@ -/* - * procfs_example.c: an example proc interface - * - * Copyright (C) 2001, Erik Mouw (mouw@nl.linux.org) - * - * This file accompanies the procfs-guide in the Linux kernel - * source. Its main use is to demonstrate the concepts and - * functions described in the guide. - * - * This software has been developed while working on the LART - * computing board (http://www.lartmaker.nl), which was sponsored - * by the Delt University of Technology projects Mobile Multi-media - * Communications and Ubiquitous Communications. - * - * This program is free software; you can redistribute - * it and/or modify it under the terms of the GNU General - * Public License as published by the Free Software - * Foundation; either version 2 of the License, or (at your - * option) any later version. - * - * This program is distributed in the hope that it will be - * useful, but WITHOUT ANY WARRANTY; without even the implied - * warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR - * PURPOSE. See the GNU General Public License for more - * details. - * - * You should have received a copy of the GNU General Public - * License along with this program; if not, write to the - * Free Software Foundation, Inc., 59 Temple Place, - * Suite 330, Boston, MA 02111-1307 USA - * - */ - -#include <linux/module.h> -#include <linux/kernel.h> -#include <linux/init.h> -#include <linux/proc_fs.h> -#include <linux/jiffies.h> -#include <asm/uaccess.h> - - -#define MODULE_VERS "1.0" -#define MODULE_NAME "procfs_example" - -#define FOOBAR_LEN 8 - -struct fb_data_t { - char name[FOOBAR_LEN + 1]; - char value[FOOBAR_LEN + 1]; -}; - - -static struct proc_dir_entry *example_dir, *foo_file, - *bar_file, *jiffies_file, *symlink; - - -struct fb_data_t foo_data, bar_data; - - -static int proc_read_jiffies(char *page, char **start, - off_t off, int count, - int *eof, void *data) -{ - int len; - - len = sprintf(page, "jiffies = %ld\n", - jiffies); - - return len; -} - - -static int proc_read_foobar(char *page, char **start, - off_t off, int count, - int *eof, void *data) -{ - int len; - struct fb_data_t *fb_data = (struct fb_data_t *)data; - - /* DON'T DO THAT - buffer overruns are bad */ - len = sprintf(page, "%s = '%s'\n", - fb_data->name, fb_data->value); - - return len; -} - - -static int proc_write_foobar(struct file *file, - const char *buffer, - unsigned long count, - void *data) -{ - int len; - struct fb_data_t *fb_data = (struct fb_data_t *)data; - - if(count > FOOBAR_LEN) - len = FOOBAR_LEN; - else - len = count; - - if(copy_from_user(fb_data->value, buffer, len)) - return -EFAULT; - - fb_data->value[len] = '\0'; - - return len; -} - - -static int __init init_procfs_example(void) -{ - int rv = 0; - - /* create directory */ - example_dir = proc_mkdir(MODULE_NAME, NULL); - if(example_dir == NULL) { - rv = -ENOMEM; - goto out; - } - /* create jiffies using convenience function */ - jiffies_file = create_proc_read_entry("jiffies", - 0444, example_dir, - proc_read_jiffies, - NULL); - if(jiffies_file == NULL) { - rv = -ENOMEM; - goto no_jiffies; - } - - /* create foo and bar files using same callback - * functions - */ - foo_file = create_proc_entry("foo", 0644, example_dir); - if(foo_file == NULL) { - rv = -ENOMEM; - goto no_foo; - } - - strcpy(foo_data.name, "foo"); - strcpy(foo_data.value, "foo"); - foo_file->data = &foo_data; - foo_file->read_proc = proc_read_foobar; - foo_file->write_proc = proc_write_foobar; - - bar_file = create_proc_entry("bar", 0644, example_dir); - if(bar_file == NULL) { - rv = -ENOMEM; - goto no_bar; - } - - strcpy(bar_data.name, "bar"); - strcpy(bar_data.value, "bar"); - bar_file->data = &bar_data; - bar_file->read_proc = proc_read_foobar; - bar_file->write_proc = proc_write_foobar; - - /* create symlink */ - symlink = proc_symlink("jiffies_too", example_dir, - "jiffies"); - if(symlink == NULL) { - rv = -ENOMEM; - goto no_symlink; - } - - /* everything OK */ - printk(KERN_INFO "%s %s initialised\n", - MODULE_NAME, MODULE_VERS); - return 0; - -no_symlink: - remove_proc_entry("bar", example_dir); -no_bar: - remove_proc_entry("foo", example_dir); -no_foo: - remove_proc_entry("jiffies", example_dir); -no_jiffies: - remove_proc_entry(MODULE_NAME, NULL); -out: - return rv; -} - - -static void __exit cleanup_procfs_example(void) -{ - remove_proc_entry("jiffies_too", example_dir); - remove_proc_entry("bar", example_dir); - remove_proc_entry("foo", example_dir); - remove_proc_entry("jiffies", example_dir); - remove_proc_entry(MODULE_NAME, NULL); - - printk(KERN_INFO "%s %s removed\n", - MODULE_NAME, MODULE_VERS); -} - - -module_init(init_procfs_example); -module_exit(cleanup_procfs_example); - -MODULE_AUTHOR("Erik Mouw"); -MODULE_DESCRIPTION("procfs examples"); -MODULE_LICENSE("GPL"); diff --git a/Documentation/DocBook/scsi.tmpl b/Documentation/DocBook/scsi.tmpl index 10a150ae2a7e..d87f4569e768 100644 --- a/Documentation/DocBook/scsi.tmpl +++ b/Documentation/DocBook/scsi.tmpl @@ -317,7 +317,7 @@ <para> The SAS transport class contains common code to deal with SAS HBAs, an aproximated representation of SAS topologies in the driver model, - and various sysfs attributes to expose these topologies and managment + and various sysfs attributes to expose these topologies and management interfaces to userspace. </para> <para> diff --git a/Documentation/DocBook/stylesheet.xsl b/Documentation/DocBook/stylesheet.xsl index 974e17ccf106..254c1d5d2e50 100644 --- a/Documentation/DocBook/stylesheet.xsl +++ b/Documentation/DocBook/stylesheet.xsl @@ -3,6 +3,7 @@ <param name="chunk.quietly">1</param> <param name="funcsynopsis.style">ansi</param> <param name="funcsynopsis.tabular.threshold">80</param> +<param name="callout.graphics">0</param> <!-- <param name="paper.type">A4</param> --> <param name="generate.section.toc.level">2</param> </stylesheet> diff --git a/Documentation/DocBook/tracepoint.tmpl b/Documentation/DocBook/tracepoint.tmpl index b0756d0fd579..8bca1d5cec09 100644 --- a/Documentation/DocBook/tracepoint.tmpl +++ b/Documentation/DocBook/tracepoint.tmpl @@ -86,4 +86,9 @@ !Iinclude/trace/events/irq.h </chapter> + <chapter id="signal"> + <title>SIGNAL</title> +!Iinclude/trace/events/signal.h + </chapter> + </book> diff --git a/Documentation/DocBook/uio-howto.tmpl b/Documentation/DocBook/uio-howto.tmpl index 8f6e3b2403c7..4d4ce0e61e42 100644 --- a/Documentation/DocBook/uio-howto.tmpl +++ b/Documentation/DocBook/uio-howto.tmpl @@ -25,6 +25,10 @@ <year>2006-2008</year> <holder>Hans-Jürgen Koch.</holder> </copyright> +<copyright> + <year>2009</year> + <holder>Red Hat Inc, Michael S. Tsirkin (mst@redhat.com)</holder> +</copyright> <legalnotice> <para> @@ -42,6 +46,13 @@ GPL version 2. <revhistory> <revision> + <revnumber>0.9</revnumber> + <date>2009-07-16</date> + <authorinitials>mst</authorinitials> + <revremark>Added generic pci driver + </revremark> + </revision> + <revision> <revnumber>0.8</revnumber> <date>2008-12-24</date> <authorinitials>hjk</authorinitials> @@ -809,6 +820,158 @@ framework to set up sysfs files for this region. Simply leave it alone. </chapter> +<chapter id="uio_pci_generic" xreflabel="Using Generic driver for PCI cards"> +<?dbhtml filename="uio_pci_generic.html"?> +<title>Generic PCI UIO driver</title> + <para> + The generic driver is a kernel module named uio_pci_generic. + It can work with any device compliant to PCI 2.3 (circa 2002) and + any compliant PCI Express device. Using this, you only need to + write the userspace driver, removing the need to write + a hardware-specific kernel module. + </para> + +<sect1 id="uio_pci_generic_binding"> +<title>Making the driver recognize the device</title> + <para> +Since the driver does not declare any device ids, it will not get loaded +automatically and will not automatically bind to any devices, you must load it +and allocate id to the driver yourself. For example: + <programlisting> + modprobe uio_pci_generic + echo "8086 10f5" > /sys/bus/pci/drivers/uio_pci_generic/new_id + </programlisting> + </para> + <para> +If there already is a hardware specific kernel driver for your device, the +generic driver still won't bind to it, in this case if you want to use the +generic driver (why would you?) you'll have to manually unbind the hardware +specific driver and bind the generic driver, like this: + <programlisting> + echo -n 0000:00:19.0 > /sys/bus/pci/drivers/e1000e/unbind + echo -n 0000:00:19.0 > /sys/bus/pci/drivers/uio_pci_generic/bind + </programlisting> + </para> + <para> +You can verify that the device has been bound to the driver +by looking for it in sysfs, for example like the following: + <programlisting> + ls -l /sys/bus/pci/devices/0000:00:19.0/driver + </programlisting> +Which if successful should print + <programlisting> + .../0000:00:19.0/driver -> ../../../bus/pci/drivers/uio_pci_generic + </programlisting> +Note that the generic driver will not bind to old PCI 2.2 devices. +If binding the device failed, run the following command: + <programlisting> + dmesg + </programlisting> +and look in the output for failure reasons + </para> +</sect1> + +<sect1 id="uio_pci_generic_internals"> +<title>Things to know about uio_pci_generic</title> + <para> +Interrupts are handled using the Interrupt Disable bit in the PCI command +register and Interrupt Status bit in the PCI status register. All devices +compliant to PCI 2.3 (circa 2002) and all compliant PCI Express devices should +support these bits. uio_pci_generic detects this support, and won't bind to +devices which do not support the Interrupt Disable Bit in the command register. + </para> + <para> +On each interrupt, uio_pci_generic sets the Interrupt Disable bit. +This prevents the device from generating further interrupts +until the bit is cleared. The userspace driver should clear this +bit before blocking and waiting for more interrupts. + </para> +</sect1> +<sect1 id="uio_pci_generic_userspace"> +<title>Writing userspace driver using uio_pci_generic</title> + <para> +Userspace driver can use pci sysfs interface, or the +libpci libray that wraps it, to talk to the device and to +re-enable interrupts by writing to the command register. + </para> +</sect1> +<sect1 id="uio_pci_generic_example"> +<title>Example code using uio_pci_generic</title> + <para> +Here is some sample userspace driver code using uio_pci_generic: +<programlisting> +#include <stdlib.h> +#include <stdio.h> +#include <unistd.h> +#include <sys/types.h> +#include <sys/stat.h> +#include <fcntl.h> +#include <errno.h> + +int main() +{ + int uiofd; + int configfd; + int err; + int i; + unsigned icount; + unsigned char command_high; + + uiofd = open("/dev/uio0", O_RDONLY); + if (uiofd < 0) { + perror("uio open:"); + return errno; + } + configfd = open("/sys/class/uio/uio0/device/config", O_RDWR); + if (uiofd < 0) { + perror("config open:"); + return errno; + } + + /* Read and cache command value */ + err = pread(configfd, &command_high, 1, 5); + if (err != 1) { + perror("command config read:"); + return errno; + } + command_high &= ~0x4; + + for(i = 0;; ++i) { + /* Print out a message, for debugging. */ + if (i == 0) + fprintf(stderr, "Started uio test driver.\n"); + else + fprintf(stderr, "Interrupts: %d\n", icount); + + /****************************************/ + /* Here we got an interrupt from the + device. Do something to it. */ + /****************************************/ + + /* Re-enable interrupts. */ + err = pwrite(configfd, &command_high, 1, 5); + if (err != 1) { + perror("config write:"); + break; + } + + /* Wait for next interrupt. */ + err = read(uiofd, &icount, 4); + if (err != 4) { + perror("uio read:"); + break; + } + + } + return errno; +} + +</programlisting> + </para> +</sect1> + +</chapter> + <appendix id="app1"> <title>Further information</title> <itemizedlist> diff --git a/Documentation/DocBook/v4l/.gitignore b/Documentation/DocBook/v4l/.gitignore new file mode 100644 index 000000000000..d7ec32eafac9 --- /dev/null +++ b/Documentation/DocBook/v4l/.gitignore @@ -0,0 +1 @@ +!*.xml diff --git a/Documentation/DocBook/v4l/biblio.xml b/Documentation/DocBook/v4l/biblio.xml new file mode 100644 index 000000000000..afc8a0dd2601 --- /dev/null +++ b/Documentation/DocBook/v4l/biblio.xml @@ -0,0 +1,188 @@ + <bibliography> + <title>References</title> + + <biblioentry id="eia608"> + <abbrev>EIA 608-B</abbrev> + <authorgroup> + <corpauthor>Electronic Industries Alliance (<ulink +url="http://www.eia.org">http://www.eia.org</ulink>)</corpauthor> + </authorgroup> + <title>EIA 608-B "Recommended Practice for Line 21 Data +Service"</title> + </biblioentry> + + <biblioentry id="en300294"> + <abbrev>EN 300 294</abbrev> + <authorgroup> + <corpauthor>European Telecommunication Standards Institute +(<ulink url="http://www.etsi.org">http://www.etsi.org</ulink>)</corpauthor> + </authorgroup> + <title>EN 300 294 "625-line television Wide Screen Signalling +(WSS)"</title> + </biblioentry> + + <biblioentry id="ets300231"> + <abbrev>ETS 300 231</abbrev> + <authorgroup> + <corpauthor>European Telecommunication Standards Institute +(<ulink +url="http://www.etsi.org">http://www.etsi.org</ulink>)</corpauthor> + </authorgroup> + <title>ETS 300 231 "Specification of the domestic video +Programme Delivery Control system (PDC)"</title> + </biblioentry> + + <biblioentry id="ets300706"> + <abbrev>ETS 300 706</abbrev> + <authorgroup> + <corpauthor>European Telecommunication Standards Institute +(<ulink url="http://www.etsi.org">http://www.etsi.org</ulink>)</corpauthor> + </authorgroup> + <title>ETS 300 706 "Enhanced Teletext specification"</title> + </biblioentry> + + <biblioentry id="mpeg2part1"> + <abbrev>ISO 13818-1</abbrev> + <authorgroup> + <corpauthor>International Telecommunication Union (<ulink +url="http://www.itu.ch">http://www.itu.ch</ulink>), International +Organisation for Standardisation (<ulink +url="http://www.iso.ch">http://www.iso.ch</ulink>)</corpauthor> + </authorgroup> + <title>ITU-T Rec. H.222.0 | ISO/IEC 13818-1 "Information +technology — Generic coding of moving pictures and associated +audio information: Systems"</title> + </biblioentry> + + <biblioentry id="mpeg2part2"> + <abbrev>ISO 13818-2</abbrev> + <authorgroup> + <corpauthor>International Telecommunication Union (<ulink +url="http://www.itu.ch">http://www.itu.ch</ulink>), International +Organisation for Standardisation (<ulink +url="http://www.iso.ch">http://www.iso.ch</ulink>)</corpauthor> + </authorgroup> + <title>ITU-T Rec. H.262 | ISO/IEC 13818-2 "Information +technology — Generic coding of moving pictures and associated +audio information: Video"</title> + </biblioentry> + + <biblioentry id="itu470"> + <abbrev>ITU BT.470</abbrev> + <authorgroup> + <corpauthor>International Telecommunication Union (<ulink +url="http://www.itu.ch">http://www.itu.ch</ulink>)</corpauthor> + </authorgroup> + <title>ITU-R Recommendation BT.470-6 "Conventional Television +Systems"</title> + </biblioentry> + + <biblioentry id="itu601"> + <abbrev>ITU BT.601</abbrev> + <authorgroup> + <corpauthor>International Telecommunication Union (<ulink +url="http://www.itu.ch">http://www.itu.ch</ulink>)</corpauthor> + </authorgroup> + <title>ITU-R Recommendation BT.601-5 "Studio Encoding Parameters +of Digital Television for Standard 4:3 and Wide-Screen 16:9 Aspect +Ratios"</title> + </biblioentry> + + <biblioentry id="itu653"> + <abbrev>ITU BT.653</abbrev> + <authorgroup> + <corpauthor>International Telecommunication Union (<ulink +url="http://www.itu.ch">http://www.itu.ch</ulink>)</corpauthor> + </authorgroup> + <title>ITU-R Recommendation BT.653-3 "Teletext systems"</title> + </biblioentry> + + <biblioentry id="itu709"> + <abbrev>ITU BT.709</abbrev> + <authorgroup> + <corpauthor>International Telecommunication Union (<ulink +url="http://www.itu.ch">http://www.itu.ch</ulink>)</corpauthor> + </authorgroup> + <title>ITU-R Recommendation BT.709-5 "Parameter values for the +HDTV standards for production and international programme +exchange"</title> + </biblioentry> + + <biblioentry id="itu1119"> + <abbrev>ITU BT.1119</abbrev> + <authorgroup> + <corpauthor>International Telecommunication Union (<ulink +url="http://www.itu.ch">http://www.itu.ch</ulink>)</corpauthor> + </authorgroup> + <title>ITU-R Recommendation BT.1119 "625-line +television Wide Screen Signalling (WSS)"</title> + </biblioentry> + + <biblioentry id="jfif"> + <abbrev>JFIF</abbrev> + <authorgroup> + <corpauthor>Independent JPEG Group (<ulink +url="http://www.ijg.org">http://www.ijg.org</ulink>)</corpauthor> + </authorgroup> + <title>JPEG File Interchange Format</title> + <subtitle>Version 1.02</subtitle> + </biblioentry> + + <biblioentry id="smpte12m"> + <abbrev>SMPTE 12M</abbrev> + <authorgroup> + <corpauthor>Society of Motion Picture and Television Engineers +(<ulink url="http://www.smpte.org">http://www.smpte.org</ulink>)</corpauthor> + </authorgroup> + <title>SMPTE 12M-1999 "Television, Audio and Film - Time and +Control Code"</title> + </biblioentry> + + <biblioentry id="smpte170m"> + <abbrev>SMPTE 170M</abbrev> + <authorgroup> + <corpauthor>Society of Motion Picture and Television Engineers +(<ulink url="http://www.smpte.org">http://www.smpte.org</ulink>)</corpauthor> + </authorgroup> + <title>SMPTE 170M-1999 "Television - Composite Analog Video +Signal - NTSC for Studio Applications"</title> + </biblioentry> + + <biblioentry id="smpte240m"> + <abbrev>SMPTE 240M</abbrev> + <authorgroup> + <corpauthor>Society of Motion Picture and Television Engineers +(<ulink url="http://www.smpte.org">http://www.smpte.org</ulink>)</corpauthor> + </authorgroup> + <title>SMPTE 240M-1999 "Television - Signal Parameters - +1125-Line High-Definition Production"</title> + </biblioentry> + + <biblioentry id="en50067"> + <abbrev>EN 50067</abbrev> + <authorgroup> + <corpauthor>European Committee for Electrotechnical Standardization +(<ulink url="http://www.cenelec.eu">http://www.cenelec.eu</ulink>)</corpauthor> + </authorgroup> + <title>Specification of the radio data system (RDS) for VHF/FM sound broadcasting +in the frequency range from 87,5 to 108,0 MHz</title> + </biblioentry> + + <biblioentry id="nrsc4"> + <abbrev>NRSC-4</abbrev> + <authorgroup> + <corpauthor>National Radio Systems Committee +(<ulink url="http://www.nrscstandards.org">http://www.nrscstandards.org</ulink>)</corpauthor> + </authorgroup> + <title>NTSC-4: United States RBDS Standard</title> + </biblioentry> + + </bibliography> + + <!-- +Local Variables: +mode: sgml +sgml-parent-document: "v4l2.sgml" +indent-tabs-mode: nil +End: + --> diff --git a/Documentation/DocBook/v4l/capture.c.xml b/Documentation/DocBook/v4l/capture.c.xml new file mode 100644 index 000000000000..1c5c49a2de59 --- /dev/null +++ b/Documentation/DocBook/v4l/capture.c.xml @@ -0,0 +1,659 @@ +<programlisting> +/* + * V4L2 video capture example + * + * This program can be used and distributed without restrictions. + * + * This program is provided with the V4L2 API + * see http://linuxtv.org/docs.php for more information + */ + +#include <stdio.h> +#include <stdlib.h> +#include <string.h> +#include <assert.h> + +#include <getopt.h> /* getopt_long() */ + +#include <fcntl.h> /* low-level i/o */ +#include <unistd.h> +#include <errno.h> +#include <sys/stat.h> +#include <sys/types.h> +#include <sys/time.h> +#include <sys/mman.h> +#include <sys/ioctl.h> + +#include <linux/videodev2.h> + +#define CLEAR(x) memset(&(x), 0, sizeof(x)) + +enum io_method { + IO_METHOD_READ, + IO_METHOD_MMAP, + IO_METHOD_USERPTR, +}; + +struct buffer { + void *start; + size_t length; +}; + +static char *dev_name; +static enum io_method io = IO_METHOD_MMAP; +static int fd = -1; +struct buffer *buffers; +static unsigned int n_buffers; +static int out_buf; +static int force_format; +static int frame_count = 70; + +static void errno_exit(const char *s) +{ + fprintf(stderr, "%s error %d, %s\n", s, errno, strerror(errno)); + exit(EXIT_FAILURE); +} + +static int xioctl(int fh, int request, void *arg) +{ + int r; + + do { + r = ioctl(fh, request, arg); + } while (-1 == r && EINTR == errno); + + return r; +} + +static void process_image(const void *p, int size) +{ + if (out_buf) + fwrite(p, size, 1, stdout); + + fflush(stderr); + fprintf(stderr, "."); + fflush(stdout); +} + +static int read_frame(void) +{ + struct <link linkend="v4l2-buffer">v4l2_buffer</link> buf; + unsigned int i; + + switch (io) { + case IO_METHOD_READ: + if (-1 == read(fd, buffers[0].start, buffers[0].length)) { + switch (errno) { + case EAGAIN: + return 0; + + case EIO: + /* Could ignore EIO, see spec. */ + + /* fall through */ + + default: + errno_exit("read"); + } + } + + process_image(buffers[0].start, buffers[0].length); + break; + + case IO_METHOD_MMAP: + CLEAR(buf); + + buf.type = V4L2_BUF_TYPE_VIDEO_CAPTURE; + buf.memory = V4L2_MEMORY_MMAP; + + if (-1 == xioctl(fd, VIDIOC_DQBUF, &buf)) { + switch (errno) { + case EAGAIN: + return 0; + + case EIO: + /* Could ignore EIO, see spec. */ + + /* fall through */ + + default: + errno_exit("VIDIOC_DQBUF"); + } + } + + assert(buf.index < n_buffers); + + process_image(buffers[buf.index].start, buf.bytesused); + + if (-1 == xioctl(fd, VIDIOC_QBUF, &buf)) + errno_exit("VIDIOC_QBUF"); + break; + + case IO_METHOD_USERPTR: + CLEAR(buf); + + buf.type = V4L2_BUF_TYPE_VIDEO_CAPTURE; + buf.memory = V4L2_MEMORY_USERPTR; + + if (-1 == xioctl(fd, VIDIOC_DQBUF, &buf)) { + switch (errno) { + case EAGAIN: + return 0; + + case EIO: + /* Could ignore EIO, see spec. */ + + /* fall through */ + + default: + errno_exit("VIDIOC_DQBUF"); + } + } + + for (i = 0; i < n_buffers; ++i) + if (buf.m.userptr == (unsigned long)buffers[i].start + && buf.length == buffers[i].length) + break; + + assert(i < n_buffers); + + process_image((void *)buf.m.userptr, buf.bytesused); + + if (-1 == xioctl(fd, VIDIOC_QBUF, &buf)) + errno_exit("VIDIOC_QBUF"); + break; + } + + return 1; +} + +static void mainloop(void) +{ + unsigned int count; + + count = frame_count; + + while (count-- > 0) { + for (;;) { + fd_set fds; + struct timeval tv; + int r; + + FD_ZERO(&fds); + FD_SET(fd, &fds); + + /* Timeout. */ + tv.tv_sec = 2; + tv.tv_usec = 0; + + r = select(fd + 1, &fds, NULL, NULL, &tv); + + if (-1 == r) { + if (EINTR == errno) + continue; + errno_exit("select"); + } + + if (0 == r) { + fprintf(stderr, "select timeout\n"); + exit(EXIT_FAILURE); + } + + if (read_frame()) + break; + /* EAGAIN - continue select loop. */ + } + } +} + +static void stop_capturing(void) +{ + enum <link linkend="v4l2-buf-type">v4l2_buf_type</link> type; + + switch (io) { + case IO_METHOD_READ: + /* Nothing to do. */ + break; + + case IO_METHOD_MMAP: + case IO_METHOD_USERPTR: + type = V4L2_BUF_TYPE_VIDEO_CAPTURE; + if (-1 == xioctl(fd, VIDIOC_STREAMOFF, &type)) + errno_exit("VIDIOC_STREAMOFF"); + break; + } +} + +static void start_capturing(void) +{ + unsigned int i; + enum <link linkend="v4l2-buf-type">v4l2_buf_type</link> type; + + switch (io) { + case IO_METHOD_READ: + /* Nothing to do. */ + break; + + case IO_METHOD_MMAP: + for (i = 0; i < n_buffers; ++i) { + struct <link linkend="v4l2-buffer">v4l2_buffer</link> buf; + + CLEAR(buf); + buf.type = V4L2_BUF_TYPE_VIDEO_CAPTURE; + buf.memory = V4L2_MEMORY_MMAP; + buf.index = i; + + if (-1 == xioctl(fd, VIDIOC_QBUF, &buf)) + errno_exit("VIDIOC_QBUF"); + } + type = V4L2_BUF_TYPE_VIDEO_CAPTURE; + if (-1 == xioctl(fd, VIDIOC_STREAMON, &type)) + errno_exit("VIDIOC_STREAMON"); + break; + + case IO_METHOD_USERPTR: + for (i = 0; i < n_buffers; ++i) { + struct <link linkend="v4l2-buffer">v4l2_buffer</link> buf; + + CLEAR(buf); + buf.type = V4L2_BUF_TYPE_VIDEO_CAPTURE; + buf.memory = V4L2_MEMORY_USERPTR; + buf.index = i; + buf.m.userptr = (unsigned long)buffers[i].start; + buf.length = buffers[i].length; + + if (-1 == xioctl(fd, VIDIOC_QBUF, &buf)) + errno_exit("VIDIOC_QBUF"); + } + type = V4L2_BUF_TYPE_VIDEO_CAPTURE; + if (-1 == xioctl(fd, VIDIOC_STREAMON, &type)) + errno_exit("VIDIOC_STREAMON"); + break; + } +} + +static void uninit_device(void) +{ + unsigned int i; + + switch (io) { + case IO_METHOD_READ: + free(buffers[0].start); + break; + + case IO_METHOD_MMAP: + for (i = 0; i < n_buffers; ++i) + if (-1 == munmap(buffers[i].start, buffers[i].length)) + errno_exit("munmap"); + break; + + case IO_METHOD_USERPTR: + for (i = 0; i < n_buffers; ++i) + free(buffers[i].start); + break; + } + + free(buffers); +} + +static void init_read(unsigned int buffer_size) +{ + buffers = calloc(1, sizeof(*buffers)); + + if (!buffers) { + fprintf(stderr, "Out of memory\n"); + exit(EXIT_FAILURE); + } + + buffers[0].length = buffer_size; + buffers[0].start = malloc(buffer_size); + + if (!buffers[0].start) { + fprintf(stderr, "Out of memory\n"); + exit(EXIT_FAILURE); + } +} + +static void init_mmap(void) +{ + struct <link linkend="v4l2-requestbuffers">v4l2_requestbuffers</link> req; + + CLEAR(req); + + req.count = 4; + req.type = V4L2_BUF_TYPE_VIDEO_CAPTURE; + req.memory = V4L2_MEMORY_MMAP; + + if (-1 == xioctl(fd, VIDIOC_REQBUFS, &req)) { + if (EINVAL == errno) { + fprintf(stderr, "%s does not support " + "memory mapping\n", dev_name); + exit(EXIT_FAILURE); + } else { + errno_exit("VIDIOC_REQBUFS"); + } + } + + if (req.count < 2) { + fprintf(stderr, "Insufficient buffer memory on %s\n", + dev_name); + exit(EXIT_FAILURE); + } + + buffers = calloc(req.count, sizeof(*buffers)); + + if (!buffers) { + fprintf(stderr, "Out of memory\n"); + exit(EXIT_FAILURE); + } + + for (n_buffers = 0; n_buffers < req.count; ++n_buffers) { + struct <link linkend="v4l2-buffer">v4l2_buffer</link> buf; + + CLEAR(buf); + + buf.type = V4L2_BUF_TYPE_VIDEO_CAPTURE; + buf.memory = V4L2_MEMORY_MMAP; + buf.index = n_buffers; + + if (-1 == xioctl(fd, VIDIOC_QUERYBUF, &buf)) + errno_exit("VIDIOC_QUERYBUF"); + + buffers[n_buffers].length = buf.length; + buffers[n_buffers].start = + mmap(NULL /* start anywhere */, + buf.length, + PROT_READ | PROT_WRITE /* required */, + MAP_SHARED /* recommended */, + fd, buf.m.offset); + + if (MAP_FAILED == buffers[n_buffers].start) + errno_exit("mmap"); + } +} + +static void init_userp(unsigned int buffer_size) +{ + struct <link linkend="v4l2-requestbuffers">v4l2_requestbuffers</link> req; + + CLEAR(req); + + req.count = 4; + req.type = V4L2_BUF_TYPE_VIDEO_CAPTURE; + req.memory = V4L2_MEMORY_USERPTR; + + if (-1 == xioctl(fd, VIDIOC_REQBUFS, &req)) { + if (EINVAL == errno) { + fprintf(stderr, "%s does not support " + "user pointer i/o\n", dev_name); + exit(EXIT_FAILURE); + } else { + errno_exit("VIDIOC_REQBUFS"); + } + } + + buffers = calloc(4, sizeof(*buffers)); + + if (!buffers) { + fprintf(stderr, "Out of memory\n"); + exit(EXIT_FAILURE); + } + + for (n_buffers = 0; n_buffers < 4; ++n_buffers) { + buffers[n_buffers].length = buffer_size; + buffers[n_buffers].start = malloc(buffer_size); + + if (!buffers[n_buffers].start) { + fprintf(stderr, "Out of memory\n"); + exit(EXIT_FAILURE); + } + } +} + +static void init_device(void) +{ + struct <link linkend="v4l2-capability">v4l2_capability</link> cap; + struct <link linkend="v4l2-cropcap">v4l2_cropcap</link> cropcap; + struct <link linkend="v4l2-crop">v4l2_crop</link> crop; + struct <link linkend="v4l2-format">v4l2_format</link> fmt; + unsigned int min; + + if (-1 == xioctl(fd, VIDIOC_QUERYCAP, &cap)) { + if (EINVAL == errno) { + fprintf(stderr, "%s is no V4L2 device\n", + dev_name); + exit(EXIT_FAILURE); + } else { + errno_exit("VIDIOC_QUERYCAP"); + } + } + + if (!(cap.capabilities & V4L2_CAP_VIDEO_CAPTURE)) { + fprintf(stderr, "%s is no video capture device\n", + dev_name); + exit(EXIT_FAILURE); + } + + switch (io) { + case IO_METHOD_READ: + if (!(cap.capabilities & V4L2_CAP_READWRITE)) { + fprintf(stderr, "%s does not support read i/o\n", + dev_name); + exit(EXIT_FAILURE); + } + break; + + case IO_METHOD_MMAP: + case IO_METHOD_USERPTR: + if (!(cap.capabilities & V4L2_CAP_STREAMING)) { + fprintf(stderr, "%s does not support streaming i/o\n", + dev_name); + exit(EXIT_FAILURE); + } + break; + } + + + /* Select video input, video standard and tune here. */ + + + CLEAR(cropcap); + + cropcap.type = V4L2_BUF_TYPE_VIDEO_CAPTURE; + + if (0 == xioctl(fd, VIDIOC_CROPCAP, &cropcap)) { + crop.type = V4L2_BUF_TYPE_VIDEO_CAPTURE; + crop.c = cropcap.defrect; /* reset to default */ + + if (-1 == xioctl(fd, VIDIOC_S_CROP, &crop)) { + switch (errno) { + case EINVAL: + /* Cropping not supported. */ + break; + default: + /* Errors ignored. */ + break; + } + } + } else { + /* Errors ignored. */ + } + + + CLEAR(fmt); + + fmt.type = V4L2_BUF_TYPE_VIDEO_CAPTURE; + if (force_format) { + fmt.fmt.pix.width = 640; + fmt.fmt.pix.height = 480; + fmt.fmt.pix.pixelformat = V4L2_PIX_FMT_YUYV; + fmt.fmt.pix.field = V4L2_FIELD_INTERLACED; + + if (-1 == xioctl(fd, VIDIOC_S_FMT, &fmt)) + errno_exit("VIDIOC_S_FMT"); + + /* Note VIDIOC_S_FMT may change width and height. */ + } else { + /* Preserve original settings as set by v4l2-ctl for example */ + if (-1 == xioctl(fd, VIDIOC_G_FMT, &fmt)) + errno_exit("VIDIOC_G_FMT"); + } + + /* Buggy driver paranoia. */ + min = fmt.fmt.pix.width * 2; + if (fmt.fmt.pix.bytesperline < min) + fmt.fmt.pix.bytesperline = min; + min = fmt.fmt.pix.bytesperline * fmt.fmt.pix.height; + if (fmt.fmt.pix.sizeimage < min) + fmt.fmt.pix.sizeimage = min; + + switch (io) { + case IO_METHOD_READ: + init_read(fmt.fmt.pix.sizeimage); + break; + + case IO_METHOD_MMAP: + init_mmap(); + break; + + case IO_METHOD_USERPTR: + init_userp(fmt.fmt.pix.sizeimage); + break; + } +} + +static void close_device(void) +{ + if (-1 == close(fd)) + errno_exit("close"); + + fd = -1; +} + +static void open_device(void) +{ + struct stat st; + + if (-1 == stat(dev_name, &st)) { + fprintf(stderr, "Cannot identify '%s': %d, %s\n", + dev_name, errno, strerror(errno)); + exit(EXIT_FAILURE); + } + + if (!S_ISCHR(st.st_mode)) { + fprintf(stderr, "%s is no device\n", dev_name); + exit(EXIT_FAILURE); + } + + fd = open(dev_name, O_RDWR /* required */ | O_NONBLOCK, 0); + + if (-1 == fd) { + fprintf(stderr, "Cannot open '%s': %d, %s\n", + dev_name, errno, strerror(errno)); + exit(EXIT_FAILURE); + } +} + +static void usage(FILE *fp, int argc, char **argv) +{ + fprintf(fp, + "Usage: %s [options]\n\n" + "Version 1.3\n" + "Options:\n" + "-d | --device name Video device name [%s]\n" + "-h | --help Print this message\n" + "-m | --mmap Use memory mapped buffers [default]\n" + "-r | --read Use read() calls\n" + "-u | --userp Use application allocated buffers\n" + "-o | --output Outputs stream to stdout\n" + "-f | --format Force format to 640x480 YUYV\n" + "-c | --count Number of frames to grab [%i]\n" + "", + argv[0], dev_name, frame_count); +} + +static const char short_options[] = "d:hmruofc:"; + +static const struct option +long_options[] = { + { "device", required_argument, NULL, 'd' }, + { "help", no_argument, NULL, 'h' }, + { "mmap", no_argument, NULL, 'm' }, + { "read", no_argument, NULL, 'r' }, + { "userp", no_argument, NULL, 'u' }, + { "output", no_argument, NULL, 'o' }, + { "format", no_argument, NULL, 'f' }, + { "count", required_argument, NULL, 'c' }, + { 0, 0, 0, 0 } +}; + +int main(int argc, char **argv) +{ + dev_name = "/dev/video0"; + + for (;;) { + int idx; + int c; + + c = getopt_long(argc, argv, + short_options, long_options, &idx); + + if (-1 == c) + break; + + switch (c) { + case 0: /* getopt_long() flag */ + break; + + case 'd': + dev_name = optarg; + break; + + case 'h': + usage(stdout, argc, argv); + exit(EXIT_SUCCESS); + + case 'm': + io = IO_METHOD_MMAP; + break; + + case 'r': + io = IO_METHOD_READ; + break; + + case 'u': + io = IO_METHOD_USERPTR; + break; + + case 'o': + out_buf++; + break; + + case 'f': + force_format++; + break; + + case 'c': + errno = 0; + frame_count = strtol(optarg, NULL, 0); + if (errno) + errno_exit(optarg); + break; + + default: + usage(stderr, argc, argv); + exit(EXIT_FAILURE); + } + } + + open_device(); + init_device(); + start_capturing(); + mainloop(); + stop_capturing(); + uninit_device(); + close_device(); + fprintf(stderr, "\n"); + return 0; +} +</programlisting> diff --git a/Documentation/DocBook/v4l/common.xml b/Documentation/DocBook/v4l/common.xml new file mode 100644 index 000000000000..c65f0ac9b6ee --- /dev/null +++ b/Documentation/DocBook/v4l/common.xml @@ -0,0 +1,1195 @@ + <title>Common API Elements</title> + + <para>Programming a V4L2 device consists of these +steps:</para> + + <itemizedlist> + <listitem> + <para>Opening the device</para> + </listitem> + <listitem> + <para>Changing device properties, selecting a video and audio +input, video standard, picture brightness a. o.</para> + </listitem> + <listitem> + <para>Negotiating a data format</para> + </listitem> + <listitem> + <para>Negotiating an input/output method</para> + </listitem> + <listitem> + <para>The actual input/output loop</para> + </listitem> + <listitem> + <para>Closing the device</para> + </listitem> + </itemizedlist> + + <para>In practice most steps are optional and can be executed out of +order. It depends on the V4L2 device type, you can read about the +details in <xref linkend="devices" />. In this chapter we will discuss +the basic concepts applicable to all devices.</para> + + <section id="open"> + <title>Opening and Closing Devices</title> + + <section> + <title>Device Naming</title> + + <para>V4L2 drivers are implemented as kernel modules, loaded +manually by the system administrator or automatically when a device is +first opened. The driver modules plug into the "videodev" kernel +module. It provides helper functions and a common application +interface specified in this document.</para> + + <para>Each driver thus loaded registers one or more device nodes +with major number 81 and a minor number between 0 and 255. Assigning +minor numbers to V4L2 devices is entirely up to the system administrator, +this is primarily intended to solve conflicts between devices.<footnote> + <para>Access permissions are associated with character +device special files, hence we must ensure device numbers cannot +change with the module load order. To this end minor numbers are no +longer automatically assigned by the "videodev" module as in V4L but +requested by the driver. The defaults will suffice for most people +unless two drivers compete for the same minor numbers.</para> + </footnote> The module options to select minor numbers are named +after the device special file with a "_nr" suffix. For example "video_nr" +for <filename>/dev/video</filename> video capture devices. The number is +an offset to the base minor number associated with the device type. +<footnote> + <para>In earlier versions of the V4L2 API the module options +where named after the device special file with a "unit_" prefix, expressing +the minor number itself, not an offset. Rationale for this change is unknown. +Lastly the naming and semantics are just a convention among driver writers, +the point to note is that minor numbers are not supposed to be hardcoded +into drivers.</para> + </footnote> When the driver supports multiple devices of the same +type more than one minor number can be assigned, separated by commas: +<informalexample> + <screen> +> insmod mydriver.o video_nr=0,1 radio_nr=0,1</screen> + </informalexample></para> + + <para>In <filename>/etc/modules.conf</filename> this may be +written as: <informalexample> + <screen> +alias char-major-81-0 mydriver +alias char-major-81-1 mydriver +alias char-major-81-64 mydriver <co id="alias" /> +options mydriver video_nr=0,1 radio_nr=0,1 <co id="options" /> + </screen> + <calloutlist> + <callout arearefs="alias"> + <para>When an application attempts to open a device +special file with major number 81 and minor number 0, 1, or 64, load +"mydriver" (and the "videodev" module it depends upon).</para> + </callout> + <callout arearefs="options"> + <para>Register the first two video capture devices with +minor number 0 and 1 (base number is 0), the first two radio device +with minor number 64 and 65 (base 64).</para> + </callout> + </calloutlist> + </informalexample> When no minor number is given as module +option the driver supplies a default. <xref linkend="devices" /> +recommends the base minor numbers to be used for the various device +types. Obviously minor numbers must be unique. When the number is +already in use the <emphasis>offending device</emphasis> will not be +registered. <!-- Blessed by Linus Torvalds on +linux-kernel@vger.kernel.org, 2002-11-20. --></para> + + <para>By convention system administrators create various +character device special files with these major and minor numbers in +the <filename>/dev</filename> directory. The names recomended for the +different V4L2 device types are listed in <xref linkend="devices" />. +</para> + + <para>The creation of character special files (with +<application>mknod</application>) is a privileged operation and +devices cannot be opened by major and minor number. That means +applications cannot <emphasis>reliable</emphasis> scan for loaded or +installed drivers. The user must enter a device name, or the +application can try the conventional device names.</para> + + <para>Under the device filesystem (devfs) the minor number +options are ignored. V4L2 drivers (or by proxy the "videodev" module) +automatically create the required device files in the +<filename>/dev/v4l</filename> directory using the conventional device +names above.</para> + </section> + + <section id="related"> + <title>Related Devices</title> + + <para>Devices can support several related functions. For example +video capturing, video overlay and VBI capturing are related because +these functions share, amongst other, the same video input and tuner +frequency. V4L and earlier versions of V4L2 used the same device name +and minor number for video capturing and overlay, but different ones +for VBI. Experience showed this approach has several problems<footnote> + <para>Given a device file name one cannot reliable find +related devices. For once names are arbitrary and in a system with +multiple devices, where only some support VBI capturing, a +<filename>/dev/video2</filename> is not necessarily related to +<filename>/dev/vbi2</filename>. The V4L +<constant>VIDIOCGUNIT</constant> ioctl would require a search for a +device file with a particular major and minor number.</para> + </footnote>, and to make things worse the V4L videodev module +used to prohibit multiple opens of a device.</para> + + <para>As a remedy the present version of the V4L2 API relaxed the +concept of device types with specific names and minor numbers. For +compatibility with old applications drivers must still register different +minor numbers to assign a default function to the device. But if related +functions are supported by the driver they must be available under all +registered minor numbers. The desired function can be selected after +opening the device as described in <xref linkend="devices" />.</para> + + <para>Imagine a driver supporting video capturing, video +overlay, raw VBI capturing, and FM radio reception. It registers three +devices with minor number 0, 64 and 224 (this numbering scheme is +inherited from the V4L API). Regardless if +<filename>/dev/video</filename> (81, 0) or +<filename>/dev/vbi</filename> (81, 224) is opened the application can +select any one of the video capturing, overlay or VBI capturing +functions. Without programming (e. g. reading from the device +with <application>dd</application> or <application>cat</application>) +<filename>/dev/video</filename> captures video images, while +<filename>/dev/vbi</filename> captures raw VBI data. +<filename>/dev/radio</filename> (81, 64) is invariable a radio device, +unrelated to the video functions. Being unrelated does not imply the +devices can be used at the same time, however. The &func-open; +function may very well return an &EBUSY;.</para> + + <para>Besides video input or output the hardware may also +support audio sampling or playback. If so, these functions are +implemented as OSS or ALSA PCM devices and eventually OSS or ALSA +audio mixer. The V4L2 API makes no provisions yet to find these +related devices. If you have an idea please write to the linux-media +mailing list: &v4l-ml;.</para> + </section> + + <section> + <title>Multiple Opens</title> + + <para>In general, V4L2 devices can be opened more than once. +When this is supported by the driver, users can for example start a +"panel" application to change controls like brightness or audio +volume, while another application captures video and audio. In other words, panel +applications are comparable to an OSS or ALSA audio mixer application. +When a device supports multiple functions like capturing and overlay +<emphasis>simultaneously</emphasis>, multiple opens allow concurrent +use of the device by forked processes or specialized applications.</para> + + <para>Multiple opens are optional, although drivers should +permit at least concurrent accesses without data exchange, &ie; panel +applications. This implies &func-open; can return an &EBUSY; when the +device is already in use, as well as &func-ioctl; functions initiating +data exchange (namely the &VIDIOC-S-FMT; ioctl), and the &func-read; +and &func-write; functions.</para> + + <para>Mere opening a V4L2 device does not grant exclusive +access.<footnote> + <para>Drivers could recognize the +<constant>O_EXCL</constant> open flag. Presently this is not required, +so applications cannot know if it really works.</para> + </footnote> Initiating data exchange however assigns the right +to read or write the requested type of data, and to change related +properties, to this file descriptor. Applications can request +additional access privileges using the priority mechanism described in +<xref linkend="app-pri" />.</para> + </section> + + <section> + <title>Shared Data Streams</title> + + <para>V4L2 drivers should not support multiple applications +reading or writing the same data stream on a device by copying +buffers, time multiplexing or similar means. This is better handled by +a proxy application in user space. When the driver supports stream +sharing anyway it must be implemented transparently. The V4L2 API does +not specify how conflicts are solved. <!-- For example O_EXCL when the +application does not want to be preempted, PROT_READ mmapped buffers +which can be mapped twice, what happens when image formats do not +match etc.--></para> + </section> + + <section> + <title>Functions</title> + + <para>To open and close V4L2 devices applications use the +&func-open; and &func-close; function, respectively. Devices are +programmed using the &func-ioctl; function as explained in the +following sections.</para> + </section> + </section> + + <section id="querycap"> + <title>Querying Capabilities</title> + + <para>Because V4L2 covers a wide variety of devices not all +aspects of the API are equally applicable to all types of devices. +Furthermore devices of the same type have different capabilities and +this specification permits the omission of a few complicated and less +important parts of the API.</para> + + <para>The &VIDIOC-QUERYCAP; ioctl is available to check if the kernel +device is compatible with this specification, and to query the <link +linkend="devices">functions</link> and <link linkend="io">I/O +methods</link> supported by the device. Other features can be queried +by calling the respective ioctl, for example &VIDIOC-ENUMINPUT; +to learn about the number, types and names of video connectors on the +device. Although abstraction is a major objective of this API, the +ioctl also allows driver specific applications to reliable identify +the driver.</para> + + <para>All V4L2 drivers must support +<constant>VIDIOC_QUERYCAP</constant>. Applications should always call +this ioctl after opening the device.</para> + </section> + + <section id="app-pri"> + <title>Application Priority</title> + + <para>When multiple applications share a device it may be +desirable to assign them different priorities. Contrary to the +traditional "rm -rf /" school of thought a video recording application +could for example block other applications from changing video +controls or switching the current TV channel. Another objective is to +permit low priority applications working in background, which can be +preempted by user controlled applications and automatically regain +control of the device at a later time.</para> + + <para>Since these features cannot be implemented entirely in user +space V4L2 defines the &VIDIOC-G-PRIORITY; and &VIDIOC-S-PRIORITY; +ioctls to request and query the access priority associate with a file +descriptor. Opening a device assigns a medium priority, compatible +with earlier versions of V4L2 and drivers not supporting these ioctls. +Applications requiring a different priority will usually call +<constant>VIDIOC_S_PRIORITY</constant> after verifying the device with +the &VIDIOC-QUERYCAP; ioctl.</para> + + <para>Ioctls changing driver properties, such as &VIDIOC-S-INPUT;, +return an &EBUSY; after another application obtained higher priority. +An event mechanism to notify applications about asynchronous property +changes has been proposed but not added yet.</para> + </section> + + <section id="video"> + <title>Video Inputs and Outputs</title> + + <para>Video inputs and outputs are physical connectors of a +device. These can be for example RF connectors (antenna/cable), CVBS +a.k.a. Composite Video, S-Video or RGB connectors. Only video and VBI +capture devices have inputs, output devices have outputs, at least one +each. Radio devices have no video inputs or outputs.</para> + + <para>To learn about the number and attributes of the +available inputs and outputs applications can enumerate them with the +&VIDIOC-ENUMINPUT; and &VIDIOC-ENUMOUTPUT; ioctl, respectively. The +&v4l2-input; returned by the <constant>VIDIOC_ENUMINPUT</constant> +ioctl also contains signal status information applicable when the +current video input is queried.</para> + + <para>The &VIDIOC-G-INPUT; and &VIDIOC-G-OUTPUT; ioctl return the +index of the current video input or output. To select a different +input or output applications call the &VIDIOC-S-INPUT; and +&VIDIOC-S-OUTPUT; ioctl. Drivers must implement all the input ioctls +when the device has one or more inputs, all the output ioctls when the +device has one or more outputs.</para> + + <!-- + <figure id=io-tree> + <title>Input and output enumeration is the root of most device properties.</title> + <mediaobject> + <imageobject> + <imagedata fileref="links.pdf" format="ps" /> + </imageobject> + <imageobject> + <imagedata fileref="links.gif" format="gif" /> + </imageobject> + <textobject> + <phrase>Links between various device property structures.</phrase> + </textobject> + </mediaobject> + </figure> + --> + + <example> + <title>Information about the current video input</title> + + <programlisting> +&v4l2-input; input; +int index; + +if (-1 == ioctl (fd, &VIDIOC-G-INPUT;, &index)) { + perror ("VIDIOC_G_INPUT"); + exit (EXIT_FAILURE); +} + +memset (&input, 0, sizeof (input)); +input.index = index; + +if (-1 == ioctl (fd, &VIDIOC-ENUMINPUT;, &input)) { + perror ("VIDIOC_ENUMINPUT"); + exit (EXIT_FAILURE); +} + +printf ("Current input: %s\n", input.name); + </programlisting> + </example> + + <example> + <title>Switching to the first video input</title> + + <programlisting> +int index; + +index = 0; + +if (-1 == ioctl (fd, &VIDIOC-S-INPUT;, &index)) { + perror ("VIDIOC_S_INPUT"); + exit (EXIT_FAILURE); +} + </programlisting> + </example> + </section> + + <section id="audio"> + <title>Audio Inputs and Outputs</title> + + <para>Audio inputs and outputs are physical connectors of a +device. Video capture devices have inputs, output devices have +outputs, zero or more each. Radio devices have no audio inputs or +outputs. They have exactly one tuner which in fact +<emphasis>is</emphasis> an audio source, but this API associates +tuners with video inputs or outputs only, and radio devices have +none of these.<footnote> + <para>Actually &v4l2-audio; ought to have a +<structfield>tuner</structfield> field like &v4l2-input;, not only +making the API more consistent but also permitting radio devices with +multiple tuners.</para> + </footnote> A connector on a TV card to loop back the received +audio signal to a sound card is not considered an audio output.</para> + + <para>Audio and video inputs and outputs are associated. Selecting +a video source also selects an audio source. This is most evident when +the video and audio source is a tuner. Further audio connectors can +combine with more than one video input or output. Assumed two +composite video inputs and two audio inputs exist, there may be up to +four valid combinations. The relation of video and audio connectors +is defined in the <structfield>audioset</structfield> field of the +respective &v4l2-input; or &v4l2-output;, where each bit represents +the index number, starting at zero, of one audio input or output.</para> + + <para>To learn about the number and attributes of the +available inputs and outputs applications can enumerate them with the +&VIDIOC-ENUMAUDIO; and &VIDIOC-ENUMAUDOUT; ioctl, respectively. The +&v4l2-audio; returned by the <constant>VIDIOC_ENUMAUDIO</constant> ioctl +also contains signal status information applicable when the current +audio input is queried.</para> + + <para>The &VIDIOC-G-AUDIO; and &VIDIOC-G-AUDOUT; ioctl report +the current audio input and output, respectively. Note that, unlike +&VIDIOC-G-INPUT; and &VIDIOC-G-OUTPUT; these ioctls return a structure +as <constant>VIDIOC_ENUMAUDIO</constant> and +<constant>VIDIOC_ENUMAUDOUT</constant> do, not just an index.</para> + + <para>To select an audio input and change its properties +applications call the &VIDIOC-S-AUDIO; ioctl. To select an audio +output (which presently has no changeable properties) applications +call the &VIDIOC-S-AUDOUT; ioctl.</para> + + <para>Drivers must implement all input ioctls when the device +has one or more inputs, all output ioctls when the device has one +or more outputs. When the device has any audio inputs or outputs the +driver must set the <constant>V4L2_CAP_AUDIO</constant> flag in the +&v4l2-capability; returned by the &VIDIOC-QUERYCAP; ioctl.</para> + + <example> + <title>Information about the current audio input</title> + + <programlisting> +&v4l2-audio; audio; + +memset (&audio, 0, sizeof (audio)); + +if (-1 == ioctl (fd, &VIDIOC-G-AUDIO;, &audio)) { + perror ("VIDIOC_G_AUDIO"); + exit (EXIT_FAILURE); +} + +printf ("Current input: %s\n", audio.name); + </programlisting> + </example> + + <example> + <title>Switching to the first audio input</title> + + <programlisting> +&v4l2-audio; audio; + +memset (&audio, 0, sizeof (audio)); /* clear audio.mode, audio.reserved */ + +audio.index = 0; + +if (-1 == ioctl (fd, &VIDIOC-S-AUDIO;, &audio)) { + perror ("VIDIOC_S_AUDIO"); + exit (EXIT_FAILURE); +} + </programlisting> + </example> + </section> + + <section id="tuner"> + <title>Tuners and Modulators</title> + + <section> + <title>Tuners</title> + + <para>Video input devices can have one or more tuners +demodulating a RF signal. Each tuner is associated with one or more +video inputs, depending on the number of RF connectors on the tuner. +The <structfield>type</structfield> field of the respective +&v4l2-input; returned by the &VIDIOC-ENUMINPUT; ioctl is set to +<constant>V4L2_INPUT_TYPE_TUNER</constant> and its +<structfield>tuner</structfield> field contains the index number of +the tuner.</para> + + <para>Radio devices have exactly one tuner with index zero, no +video inputs.</para> + + <para>To query and change tuner properties applications use the +&VIDIOC-G-TUNER; and &VIDIOC-S-TUNER; ioctl, respectively. The +&v4l2-tuner; returned by <constant>VIDIOC_G_TUNER</constant> also +contains signal status information applicable when the tuner of the +current video input, or a radio tuner is queried. Note that +<constant>VIDIOC_S_TUNER</constant> does not switch the current tuner, +when there is more than one at all. The tuner is solely determined by +the current video input. Drivers must support both ioctls and set the +<constant>V4L2_CAP_TUNER</constant> flag in the &v4l2-capability; +returned by the &VIDIOC-QUERYCAP; ioctl when the device has one or +more tuners.</para> + </section> + + <section> + <title>Modulators</title> + + <para>Video output devices can have one or more modulators, uh, +modulating a video signal for radiation or connection to the antenna +input of a TV set or video recorder. Each modulator is associated with +one or more video outputs, depending on the number of RF connectors on +the modulator. The <structfield>type</structfield> field of the +respective &v4l2-output; returned by the &VIDIOC-ENUMOUTPUT; ioctl is +set to <constant>V4L2_OUTPUT_TYPE_MODULATOR</constant> and its +<structfield>modulator</structfield> field contains the index number +of the modulator. This specification does not define radio output +devices.</para> + + <para>To query and change modulator properties applications use +the &VIDIOC-G-MODULATOR; and &VIDIOC-S-MODULATOR; ioctl. Note that +<constant>VIDIOC_S_MODULATOR</constant> does not switch the current +modulator, when there is more than one at all. The modulator is solely +determined by the current video output. Drivers must support both +ioctls and set the <constant>V4L2_CAP_MODULATOR</constant> flag in +the &v4l2-capability; returned by the &VIDIOC-QUERYCAP; ioctl when the +device has one or more modulators.</para> + </section> + + <section> + <title>Radio Frequency</title> + + <para>To get and set the tuner or modulator radio frequency +applications use the &VIDIOC-G-FREQUENCY; and &VIDIOC-S-FREQUENCY; +ioctl which both take a pointer to a &v4l2-frequency;. These ioctls +are used for TV and radio devices alike. Drivers must support both +ioctls when the tuner or modulator ioctls are supported, or +when the device is a radio device.</para> + </section> + </section> + + <section id="standard"> + <title>Video Standards</title> + + <para>Video devices typically support one or more different video +standards or variations of standards. Each video input and output may +support another set of standards. This set is reported by the +<structfield>std</structfield> field of &v4l2-input; and +&v4l2-output; returned by the &VIDIOC-ENUMINPUT; and +&VIDIOC-ENUMOUTPUT; ioctl, respectively.</para> + + <para>V4L2 defines one bit for each analog video standard +currently in use worldwide, and sets aside bits for driver defined +standards, ⪚ hybrid standards to watch NTSC video tapes on PAL TVs +and vice versa. Applications can use the predefined bits to select a +particular standard, although presenting the user a menu of supported +standards is preferred. To enumerate and query the attributes of the +supported standards applications use the &VIDIOC-ENUMSTD; ioctl.</para> + + <para>Many of the defined standards are actually just variations +of a few major standards. The hardware may in fact not distinguish +between them, or do so internal and switch automatically. Therefore +enumerated standards also contain sets of one or more standard +bits.</para> + + <para>Assume a hypothetic tuner capable of demodulating B/PAL, +G/PAL and I/PAL signals. The first enumerated standard is a set of B +and G/PAL, switched automatically depending on the selected radio +frequency in UHF or VHF band. Enumeration gives a "PAL-B/G" or "PAL-I" +choice. Similar a Composite input may collapse standards, enumerating +"PAL-B/G/H/I", "NTSC-M" and "SECAM-D/K".<footnote> + <para>Some users are already confused by technical terms PAL, +NTSC and SECAM. There is no point asking them to distinguish between +B, G, D, or K when the software or hardware can do that +automatically.</para> + </footnote></para> + + <para>To query and select the standard used by the current video +input or output applications call the &VIDIOC-G-STD; and +&VIDIOC-S-STD; ioctl, respectively. The <emphasis>received</emphasis> +standard can be sensed with the &VIDIOC-QUERYSTD; ioctl. Note parameter of all these ioctls is a pointer to a &v4l2-std-id; type (a standard set), <emphasis>not</emphasis> an index into the standard enumeration.<footnote> + <para>An alternative to the current scheme is to use pointers +to indices as arguments of <constant>VIDIOC_G_STD</constant> and +<constant>VIDIOC_S_STD</constant>, the &v4l2-input; and +&v4l2-output; <structfield>std</structfield> field would be a set of +indices like <structfield>audioset</structfield>.</para> + <para>Indices are consistent with the rest of the API +and identify the standard unambiguously. In the present scheme of +things an enumerated standard is looked up by &v4l2-std-id;. Now the +standards supported by the inputs of a device can overlap. Just +assume the tuner and composite input in the example above both +exist on a device. An enumeration of "PAL-B/G", "PAL-H/I" suggests +a choice which does not exist. We cannot merge or omit sets, because +applications would be unable to find the standards reported by +<constant>VIDIOC_G_STD</constant>. That leaves separate enumerations +for each input. Also selecting a standard by &v4l2-std-id; can be +ambiguous. Advantage of this method is that applications need not +identify the standard indirectly, after enumerating.</para><para>So in +summary, the lookup itself is unavoidable. The difference is only +whether the lookup is necessary to find an enumerated standard or to +switch to a standard by &v4l2-std-id;.</para> + </footnote> Drivers must implement all video standard ioctls +when the device has one or more video inputs or outputs.</para> + + <para>Special rules apply to USB cameras where the notion of video +standards makes little sense. More generally any capture device, +output devices accordingly, which is <itemizedlist> + <listitem> + <para>incapable of capturing fields or frames at the nominal +rate of the video standard, or</para> + </listitem> + <listitem> + <para>where <link linkend="buffer">timestamps</link> refer +to the instant the field or frame was received by the driver, not the +capture time, or</para> + </listitem> + <listitem> + <para>where <link linkend="buffer">sequence numbers</link> +refer to the frames received by the driver, not the captured +frames.</para> + </listitem> + </itemizedlist> Here the driver shall set the +<structfield>std</structfield> field of &v4l2-input; and &v4l2-output; +to zero, the <constant>VIDIOC_G_STD</constant>, +<constant>VIDIOC_S_STD</constant>, +<constant>VIDIOC_QUERYSTD</constant> and +<constant>VIDIOC_ENUMSTD</constant> ioctls shall return the +&EINVAL;.<footnote> + <para>See <xref linkend="buffer" /> for a rationale. Probably +even USB cameras follow some well known video standard. It might have +been better to explicitly indicate elsewhere if a device cannot live +up to normal expectations, instead of this exception.</para> + </footnote></para> + + <example> + <title>Information about the current video standard</title> + + <programlisting> +&v4l2-std-id; std_id; +&v4l2-standard; standard; + +if (-1 == ioctl (fd, &VIDIOC-G-STD;, &std_id)) { + /* Note when VIDIOC_ENUMSTD always returns EINVAL this + is no video device or it falls under the USB exception, + and VIDIOC_G_STD returning EINVAL is no error. */ + + perror ("VIDIOC_G_STD"); + exit (EXIT_FAILURE); +} + +memset (&standard, 0, sizeof (standard)); +standard.index = 0; + +while (0 == ioctl (fd, &VIDIOC-ENUMSTD;, &standard)) { + if (standard.id & std_id) { + printf ("Current video standard: %s\n", standard.name); + exit (EXIT_SUCCESS); + } + + standard.index++; +} + +/* EINVAL indicates the end of the enumeration, which cannot be + empty unless this device falls under the USB exception. */ + +if (errno == EINVAL || standard.index == 0) { + perror ("VIDIOC_ENUMSTD"); + exit (EXIT_FAILURE); +} + </programlisting> + </example> + + <example> + <title>Listing the video standards supported by the current +input</title> + + <programlisting> +&v4l2-input; input; +&v4l2-standard; standard; + +memset (&input, 0, sizeof (input)); + +if (-1 == ioctl (fd, &VIDIOC-G-INPUT;, &input.index)) { + perror ("VIDIOC_G_INPUT"); + exit (EXIT_FAILURE); +} + +if (-1 == ioctl (fd, &VIDIOC-ENUMINPUT;, &input)) { + perror ("VIDIOC_ENUM_INPUT"); + exit (EXIT_FAILURE); +} + +printf ("Current input %s supports:\n", input.name); + +memset (&standard, 0, sizeof (standard)); +standard.index = 0; + +while (0 == ioctl (fd, &VIDIOC-ENUMSTD;, &standard)) { + if (standard.id & input.std) + printf ("%s\n", standard.name); + + standard.index++; +} + +/* EINVAL indicates the end of the enumeration, which cannot be + empty unless this device falls under the USB exception. */ + +if (errno != EINVAL || standard.index == 0) { + perror ("VIDIOC_ENUMSTD"); + exit (EXIT_FAILURE); +} + </programlisting> + </example> + + <example> + <title>Selecting a new video standard</title> + + <programlisting> +&v4l2-input; input; +&v4l2-std-id; std_id; + +memset (&input, 0, sizeof (input)); + +if (-1 == ioctl (fd, &VIDIOC-G-INPUT;, &input.index)) { + perror ("VIDIOC_G_INPUT"); + exit (EXIT_FAILURE); +} + +if (-1 == ioctl (fd, &VIDIOC-ENUMINPUT;, &input)) { + perror ("VIDIOC_ENUM_INPUT"); + exit (EXIT_FAILURE); +} + +if (0 == (input.std & V4L2_STD_PAL_BG)) { + fprintf (stderr, "Oops. B/G PAL is not supported.\n"); + exit (EXIT_FAILURE); +} + +/* Note this is also supposed to work when only B + <emphasis>or</emphasis> G/PAL is supported. */ + +std_id = V4L2_STD_PAL_BG; + +if (-1 == ioctl (fd, &VIDIOC-S-STD;, &std_id)) { + perror ("VIDIOC_S_STD"); + exit (EXIT_FAILURE); +} + </programlisting> + </example> + <section id="dv-timings"> + <title>Digital Video (DV) Timings</title> + <para> + The video standards discussed so far has been dealing with Analog TV and the +corresponding video timings. Today there are many more different hardware interfaces +such as High Definition TV interfaces (HDMI), VGA, DVI connectors etc., that carry +video signals and there is a need to extend the API to select the video timings +for these interfaces. Since it is not possible to extend the &v4l2-std-id; due to +the limited bits available, a new set of IOCTLs is added to set/get video timings at +the input and output: </para><itemizedlist> + <listitem> + <para>DV Presets: Digital Video (DV) presets. These are IDs representing a +video timing at the input/output. Presets are pre-defined timings implemented +by the hardware according to video standards. A __u32 data type is used to represent +a preset unlike the bit mask that is used in &v4l2-std-id; allowing future extensions +to support as many different presets as needed.</para> + </listitem> + <listitem> + <para>Custom DV Timings: This will allow applications to define more detailed +custom video timings for the interface. This includes parameters such as width, height, +polarities, frontporch, backporch etc. + </para> + </listitem> + </itemizedlist> + <para>To enumerate and query the attributes of DV presets supported by a device, +applications use the &VIDIOC-ENUM-DV-PRESETS; ioctl. To get the current DV preset, +applications use the &VIDIOC-G-DV-PRESET; ioctl and to set a preset they use the +&VIDIOC-S-DV-PRESET; ioctl.</para> + <para>To set custom DV timings for the device, applications use the +&VIDIOC-S-DV-TIMINGS; ioctl and to get current custom DV timings they use the +&VIDIOC-G-DV-TIMINGS; ioctl.</para> + <para>Applications can make use of the <xref linkend="input-capabilities" /> and +<xref linkend="output-capabilities"/> flags to decide what ioctls are available to set the +video timings for the device.</para> + </section> + </section> + + &sub-controls; + + <section id="format"> + <title>Data Formats</title> + + <section> + <title>Data Format Negotiation</title> + + <para>Different devices exchange different kinds of data with +applications, for example video images, raw or sliced VBI data, RDS +datagrams. Even within one kind many different formats are possible, +in particular an abundance of image formats. Although drivers must +provide a default and the selection persists across closing and +reopening a device, applications should always negotiate a data format +before engaging in data exchange. Negotiation means the application +asks for a particular format and the driver selects and reports the +best the hardware can do to satisfy the request. Of course +applications can also just query the current selection.</para> + + <para>A single mechanism exists to negotiate all data formats +using the aggregate &v4l2-format; and the &VIDIOC-G-FMT; and +&VIDIOC-S-FMT; ioctls. Additionally the &VIDIOC-TRY-FMT; ioctl can be +used to examine what the hardware <emphasis>could</emphasis> do, +without actually selecting a new data format. The data formats +supported by the V4L2 API are covered in the respective device section +in <xref linkend="devices" />. For a closer look at image formats see +<xref linkend="pixfmt" />.</para> + + <para>The <constant>VIDIOC_S_FMT</constant> ioctl is a major +turning-point in the initialization sequence. Prior to this point +multiple panel applications can access the same device concurrently to +select the current input, change controls or modify other properties. +The first <constant>VIDIOC_S_FMT</constant> assigns a logical stream +(video data, VBI data etc.) exclusively to one file descriptor.</para> + + <para>Exclusive means no other application, more precisely no +other file descriptor, can grab this stream or change device +properties inconsistent with the negotiated parameters. A video +standard change for example, when the new standard uses a different +number of scan lines, can invalidate the selected image format. +Therefore only the file descriptor owning the stream can make +invalidating changes. Accordingly multiple file descriptors which +grabbed different logical streams prevent each other from interfering +with their settings. When for example video overlay is about to start +or already in progress, simultaneous video capturing may be restricted +to the same cropping and image size.</para> + + <para>When applications omit the +<constant>VIDIOC_S_FMT</constant> ioctl its locking side effects are +implied by the next step, the selection of an I/O method with the +&VIDIOC-REQBUFS; ioctl or implicit with the first &func-read; or +&func-write; call.</para> + + <para>Generally only one logical stream can be assigned to a +file descriptor, the exception being drivers permitting simultaneous +video capturing and overlay using the same file descriptor for +compatibility with V4L and earlier versions of V4L2. Switching the +logical stream or returning into "panel mode" is possible by closing +and reopening the device. Drivers <emphasis>may</emphasis> support a +switch using <constant>VIDIOC_S_FMT</constant>.</para> + + <para>All drivers exchanging data with +applications must support the <constant>VIDIOC_G_FMT</constant> and +<constant>VIDIOC_S_FMT</constant> ioctl. Implementation of the +<constant>VIDIOC_TRY_FMT</constant> is highly recommended but +optional.</para> + </section> + + <section> + <title>Image Format Enumeration</title> + + <para>Apart of the generic format negotiation functions +a special ioctl to enumerate all image formats supported by video +capture, overlay or output devices is available.<footnote> + <para>Enumerating formats an application has no a-priori +knowledge of (otherwise it could explicitly ask for them and need not +enumerate) seems useless, but there are applications serving as proxy +between drivers and the actual video applications for which this is +useful.</para> + </footnote></para> + + <para>The &VIDIOC-ENUM-FMT; ioctl must be supported +by all drivers exchanging image data with applications.</para> + + <important> + <para>Drivers are not supposed to convert image formats in +kernel space. They must enumerate only formats directly supported by +the hardware. If necessary driver writers should publish an example +conversion routine or library for integration into applications.</para> + </important> + </section> + </section> + + <section id="crop"> + <title>Image Cropping, Insertion and Scaling</title> + + <para>Some video capture devices can sample a subsection of the +picture and shrink or enlarge it to an image of arbitrary size. We +call these abilities cropping and scaling. Some video output devices +can scale an image up or down and insert it at an arbitrary scan line +and horizontal offset into a video signal.</para> + + <para>Applications can use the following API to select an area in +the video signal, query the default area and the hardware limits. +<emphasis>Despite their name, the &VIDIOC-CROPCAP;, &VIDIOC-G-CROP; +and &VIDIOC-S-CROP; ioctls apply to input as well as output +devices.</emphasis></para> + + <para>Scaling requires a source and a target. On a video capture +or overlay device the source is the video signal, and the cropping +ioctls determine the area actually sampled. The target are images +read by the application or overlaid onto the graphics screen. Their +size (and position for an overlay) is negotiated with the +&VIDIOC-G-FMT; and &VIDIOC-S-FMT; ioctls.</para> + + <para>On a video output device the source are the images passed in +by the application, and their size is again negotiated with the +<constant>VIDIOC_G/S_FMT</constant> ioctls, or may be encoded in a +compressed video stream. The target is the video signal, and the +cropping ioctls determine the area where the images are +inserted.</para> + + <para>Source and target rectangles are defined even if the device +does not support scaling or the <constant>VIDIOC_G/S_CROP</constant> +ioctls. Their size (and position where applicable) will be fixed in +this case. <emphasis>All capture and output device must support the +<constant>VIDIOC_CROPCAP</constant> ioctl such that applications can +determine if scaling takes place.</emphasis></para> + + <section> + <title>Cropping Structures</title> + + <figure id="crop-scale"> + <title>Image Cropping, Insertion and Scaling</title> + <mediaobject> + <imageobject> + <imagedata fileref="crop.pdf" format="PS" /> + </imageobject> + <imageobject> + <imagedata fileref="crop.gif" format="GIF" /> + </imageobject> + <textobject> + <phrase>The cropping, insertion and scaling process</phrase> + </textobject> + </mediaobject> + </figure> + + <para>For capture devices the coordinates of the top left +corner, width and height of the area which can be sampled is given by +the <structfield>bounds</structfield> substructure of the +&v4l2-cropcap; returned by the <constant>VIDIOC_CROPCAP</constant> +ioctl. To support a wide range of hardware this specification does not +define an origin or units. However by convention drivers should +horizontally count unscaled samples relative to 0H (the leading edge +of the horizontal sync pulse, see <xref linkend="vbi-hsync" />). +Vertically ITU-R line +numbers of the first field (<xref linkend="vbi-525" />, <xref +linkend="vbi-625" />), multiplied by two if the driver can capture both +fields.</para> + + <para>The top left corner, width and height of the source +rectangle, that is the area actually sampled, is given by &v4l2-crop; +using the same coordinate system as &v4l2-cropcap;. Applications can +use the <constant>VIDIOC_G_CROP</constant> and +<constant>VIDIOC_S_CROP</constant> ioctls to get and set this +rectangle. It must lie completely within the capture boundaries and +the driver may further adjust the requested size and/or position +according to hardware limitations.</para> + + <para>Each capture device has a default source rectangle, given +by the <structfield>defrect</structfield> substructure of +&v4l2-cropcap;. The center of this rectangle shall align with the +center of the active picture area of the video signal, and cover what +the driver writer considers the complete picture. Drivers shall reset +the source rectangle to the default when the driver is first loaded, +but not later.</para> + + <para>For output devices these structures and ioctls are used +accordingly, defining the <emphasis>target</emphasis> rectangle where +the images will be inserted into the video signal.</para> + + </section> + + <section> + <title>Scaling Adjustments</title> + + <para>Video hardware can have various cropping, insertion and +scaling limitations. It may only scale up or down, support only +discrete scaling factors, or have different scaling abilities in +horizontal and vertical direction. Also it may not support scaling at +all. At the same time the &v4l2-crop; rectangle may have to be +aligned, and both the source and target rectangles may have arbitrary +upper and lower size limits. In particular the maximum +<structfield>width</structfield> and <structfield>height</structfield> +in &v4l2-crop; may be smaller than the +&v4l2-cropcap;.<structfield>bounds</structfield> area. Therefore, as +usual, drivers are expected to adjust the requested parameters and +return the actual values selected.</para> + + <para>Applications can change the source or the target rectangle +first, as they may prefer a particular image size or a certain area in +the video signal. If the driver has to adjust both to satisfy hardware +limitations, the last requested rectangle shall take priority, and the +driver should preferably adjust the opposite one. The &VIDIOC-TRY-FMT; +ioctl however shall not change the driver state and therefore only +adjust the requested rectangle.</para> + + <para>Suppose scaling on a video capture device is restricted to +a factor 1:1 or 2:1 in either direction and the target image size must +be a multiple of 16 × 16 pixels. The source cropping +rectangle is set to defaults, which are also the upper limit in this +example, of 640 × 400 pixels at offset 0, 0. An +application requests an image size of 300 × 225 +pixels, assuming video will be scaled down from the "full picture" +accordingly. The driver sets the image size to the closest possible +values 304 × 224, then chooses the cropping rectangle +closest to the requested size, that is 608 × 224 +(224 × 2:1 would exceed the limit 400). The offset +0, 0 is still valid, thus unmodified. Given the default cropping +rectangle reported by <constant>VIDIOC_CROPCAP</constant> the +application can easily propose another offset to center the cropping +rectangle.</para> + + <para>Now the application may insist on covering an area using a +picture aspect ratio closer to the original request, so it asks for a +cropping rectangle of 608 × 456 pixels. The present +scaling factors limit cropping to 640 × 384, so the +driver returns the cropping size 608 × 384 and adjusts +the image size to closest possible 304 × 192.</para> + + </section> + + <section> + <title>Examples</title> + + <para>Source and target rectangles shall remain unchanged across +closing and reopening a device, such that piping data into or out of a +device will work without special preparations. More advanced +applications should ensure the parameters are suitable before starting +I/O.</para> + + <example> + <title>Resetting the cropping parameters</title> + + <para>(A video capture device is assumed; change +<constant>V4L2_BUF_TYPE_VIDEO_CAPTURE</constant> for other +devices.)</para> + + <programlisting> +&v4l2-cropcap; cropcap; +&v4l2-crop; crop; + +memset (&cropcap, 0, sizeof (cropcap)); +cropcap.type = V4L2_BUF_TYPE_VIDEO_CAPTURE; + +if (-1 == ioctl (fd, &VIDIOC-CROPCAP;, &cropcap)) { + perror ("VIDIOC_CROPCAP"); + exit (EXIT_FAILURE); +} + +memset (&crop, 0, sizeof (crop)); +crop.type = V4L2_BUF_TYPE_VIDEO_CAPTURE; +crop.c = cropcap.defrect; + +/* Ignore if cropping is not supported (EINVAL). */ + +if (-1 == ioctl (fd, &VIDIOC-S-CROP;, &crop) + && errno != EINVAL) { + perror ("VIDIOC_S_CROP"); + exit (EXIT_FAILURE); +} + </programlisting> + </example> + + <example> + <title>Simple downscaling</title> + + <para>(A video capture device is assumed.)</para> + + <programlisting> +&v4l2-cropcap; cropcap; +&v4l2-format; format; + +reset_cropping_parameters (); + +/* Scale down to 1/4 size of full picture. */ + +memset (&format, 0, sizeof (format)); /* defaults */ + +format.type = V4L2_BUF_TYPE_VIDEO_CAPTURE; + +format.fmt.pix.width = cropcap.defrect.width >> 1; +format.fmt.pix.height = cropcap.defrect.height >> 1; +format.fmt.pix.pixelformat = V4L2_PIX_FMT_YUYV; + +if (-1 == ioctl (fd, &VIDIOC-S-FMT;, &format)) { + perror ("VIDIOC_S_FORMAT"); + exit (EXIT_FAILURE); +} + +/* We could check the actual image size now, the actual scaling factor + or if the driver can scale at all. */ + </programlisting> + </example> + + <example> + <title>Selecting an output area</title> + + <programlisting> +&v4l2-cropcap; cropcap; +&v4l2-crop; crop; + +memset (&cropcap, 0, sizeof (cropcap)); +cropcap.type = V4L2_BUF_TYPE_VIDEO_OUTPUT; + +if (-1 == ioctl (fd, VIDIOC_CROPCAP;, &cropcap)) { + perror ("VIDIOC_CROPCAP"); + exit (EXIT_FAILURE); +} + +memset (&crop, 0, sizeof (crop)); + +crop.type = V4L2_BUF_TYPE_VIDEO_OUTPUT; +crop.c = cropcap.defrect; + +/* Scale the width and height to 50 % of their original size + and center the output. */ + +crop.c.width /= 2; +crop.c.height /= 2; +crop.c.left += crop.c.width / 2; +crop.c.top += crop.c.height / 2; + +/* Ignore if cropping is not supported (EINVAL). */ + +if (-1 == ioctl (fd, VIDIOC_S_CROP, &crop) + && errno != EINVAL) { + perror ("VIDIOC_S_CROP"); + exit (EXIT_FAILURE); +} +</programlisting> + </example> + + <example> + <title>Current scaling factor and pixel aspect</title> + + <para>(A video capture device is assumed.)</para> + + <programlisting> +&v4l2-cropcap; cropcap; +&v4l2-crop; crop; +&v4l2-format; format; +double hscale, vscale; +double aspect; +int dwidth, dheight; + +memset (&cropcap, 0, sizeof (cropcap)); +cropcap.type = V4L2_BUF_TYPE_VIDEO_CAPTURE; + +if (-1 == ioctl (fd, &VIDIOC-CROPCAP;, &cropcap)) { + perror ("VIDIOC_CROPCAP"); + exit (EXIT_FAILURE); +} + +memset (&crop, 0, sizeof (crop)); +crop.type = V4L2_BUF_TYPE_VIDEO_CAPTURE; + +if (-1 == ioctl (fd, &VIDIOC-G-CROP;, &crop)) { + if (errno != EINVAL) { + perror ("VIDIOC_G_CROP"); + exit (EXIT_FAILURE); + } + + /* Cropping not supported. */ + crop.c = cropcap.defrect; +} + +memset (&format, 0, sizeof (format)); +format.fmt.type = V4L2_BUF_TYPE_VIDEO_CAPTURE; + +if (-1 == ioctl (fd, &VIDIOC-G-FMT;, &format)) { + perror ("VIDIOC_G_FMT"); + exit (EXIT_FAILURE); +} + +/* The scaling applied by the driver. */ + +hscale = format.fmt.pix.width / (double) crop.c.width; +vscale = format.fmt.pix.height / (double) crop.c.height; + +aspect = cropcap.pixelaspect.numerator / + (double) cropcap.pixelaspect.denominator; +aspect = aspect * hscale / vscale; + +/* Devices following ITU-R BT.601 do not capture + square pixels. For playback on a computer monitor + we should scale the images to this size. */ + +dwidth = format.fmt.pix.width / aspect; +dheight = format.fmt.pix.height; + </programlisting> + </example> + </section> + </section> + + <section id="streaming-par"> + <title>Streaming Parameters</title> + + <para>Streaming parameters are intended to optimize the video +capture process as well as I/O. Presently applications can request a +high quality capture mode with the &VIDIOC-S-PARM; ioctl.</para> + + <para>The current video standard determines a nominal number of +frames per second. If less than this number of frames is to be +captured or output, applications can request frame skipping or +duplicating on the driver side. This is especially useful when using +the &func-read; or &func-write;, which are not augmented by timestamps +or sequence counters, and to avoid unneccessary data copying.</para> + + <para>Finally these ioctls can be used to determine the number of +buffers used internally by a driver in read/write mode. For +implications see the section discussing the &func-read; +function.</para> + + <para>To get and set the streaming parameters applications call +the &VIDIOC-G-PARM; and &VIDIOC-S-PARM; ioctl, respectively. They take +a pointer to a &v4l2-streamparm;, which contains a union holding +separate parameters for input and output devices.</para> + + <para>These ioctls are optional, drivers need not implement +them. If so, they return the &EINVAL;.</para> + </section> + + <!-- +Local Variables: +mode: sgml +sgml-parent-document: "v4l2.sgml" +indent-tabs-mode: nil +End: + --> diff --git a/Documentation/DocBook/v4l/compat.xml b/Documentation/DocBook/v4l/compat.xml new file mode 100644 index 000000000000..b9dbdf9e6d29 --- /dev/null +++ b/Documentation/DocBook/v4l/compat.xml @@ -0,0 +1,2465 @@ + <title>Changes</title> + + <para>The following chapters document the evolution of the V4L2 API, +errata or extensions. They are also intended to help application and +driver writers to port or update their code.</para> + + <section id="diff-v4l"> + <title>Differences between V4L and V4L2</title> + + <para>The Video For Linux API was first introduced in Linux 2.1 to +unify and replace various TV and radio device related interfaces, +developed independently by driver writers in prior years. Starting +with Linux 2.5 the much improved V4L2 API replaces the V4L API, +although existing drivers will continue to support V4L applications in +the future, either directly or through the V4L2 compatibility layer in +the <filename>videodev</filename> kernel module translating ioctls on +the fly. For a transition period not all drivers will support the V4L2 +API.</para> + + <section> + <title>Opening and Closing Devices</title> + + <para>For compatibility reasons the character device file names +recommended for V4L2 video capture, overlay, radio, teletext and raw +vbi capture devices did not change from those used by V4L. They are +listed in <xref linkend="devices" /> and below in <xref + linkend="v4l-dev" />.</para> + + <para>The V4L <filename>videodev</filename> module automatically +assigns minor numbers to drivers in load order, depending on the +registered device type. We recommend that V4L2 drivers by default +register devices with the same numbers, but the system administrator +can assign arbitrary minor numbers using driver module options. The +major device number remains 81.</para> + + <table id="v4l-dev"> + <title>V4L Device Types, Names and Numbers</title> + <tgroup cols="3"> + <thead> + <row> + <entry>Device Type</entry> + <entry>File Name</entry> + <entry>Minor Numbers</entry> + </row> + </thead> + <tbody valign="top"> + <row> + <entry>Video capture and overlay</entry> + <entry><para><filename>/dev/video</filename> and +<filename>/dev/bttv0</filename><footnote> <para>According to +Documentation/devices.txt these should be symbolic links to +<filename>/dev/video0</filename>. Note the original bttv interface is +not compatible with V4L or V4L2.</para> </footnote>, +<filename>/dev/video0</filename> to +<filename>/dev/video63</filename></para></entry> + <entry>0-63</entry> + </row> + <row> + <entry>Radio receiver</entry> + <entry><para><filename>/dev/radio</filename><footnote> + <para>According to +<filename>Documentation/devices.txt</filename> a symbolic link to +<filename>/dev/radio0</filename>.</para> + </footnote>, <filename>/dev/radio0</filename> to +<filename>/dev/radio63</filename></para></entry> + <entry>64-127</entry> + </row> + <row> + <entry>Teletext decoder</entry> + <entry><para><filename>/dev/vtx</filename>, +<filename>/dev/vtx0</filename> to +<filename>/dev/vtx31</filename></para></entry> + <entry>192-223</entry> + </row> + <row> + <entry>Raw VBI capture</entry> + <entry><para><filename>/dev/vbi</filename>, +<filename>/dev/vbi0</filename> to +<filename>/dev/vbi31</filename></para></entry> + <entry>224-255</entry> + </row> + </tbody> + </tgroup> + </table> + + <para>V4L prohibits (or used to prohibit) multiple opens of a +device file. V4L2 drivers <emphasis>may</emphasis> support multiple +opens, see <xref linkend="open" /> for details and consequences.</para> + + <para>V4L drivers respond to V4L2 ioctls with an &EINVAL;. The +compatibility layer in the V4L2 <filename>videodev</filename> module +can translate V4L ioctl requests to their V4L2 counterpart, however a +V4L2 driver usually needs more preparation to become fully V4L +compatible. This is covered in more detail in <xref + linkend="driver" />.</para> + </section> + + <section> + <title>Querying Capabilities</title> + + <para>The V4L <constant>VIDIOCGCAP</constant> ioctl is +equivalent to V4L2's &VIDIOC-QUERYCAP;.</para> + + <para>The <structfield>name</structfield> field in struct +<structname>video_capability</structname> became +<structfield>card</structfield> in &v4l2-capability;, +<structfield>type</structfield> was replaced by +<structfield>capabilities</structfield>. Note V4L2 does not +distinguish between device types like this, better think of basic +video input, video output and radio devices supporting a set of +related functions like video capturing, video overlay and VBI +capturing. See <xref linkend="open" /> for an +introduction.<informaltable> + <tgroup cols="3"> + <thead> + <row> + <entry>struct +<structname>video_capability</structname> +<structfield>type</structfield></entry> + <entry>&v4l2-capability; +<structfield>capabilities</structfield> flags</entry> + <entry>Purpose</entry> + </row> + </thead> + <tbody valign="top"> + <row> + <entry><constant>VID_TYPE_CAPTURE</constant></entry> + <entry><constant>V4L2_CAP_VIDEO_CAPTURE</constant></entry> + <entry>The <link linkend="capture">video +capture</link> interface is supported.</entry> + </row> + <row> + <entry><constant>VID_TYPE_TUNER</constant></entry> + <entry><constant>V4L2_CAP_TUNER</constant></entry> + <entry>The device has a <link linkend="tuner">tuner or +modulator</link>.</entry> + </row> + <row> + <entry><constant>VID_TYPE_TELETEXT</constant></entry> + <entry><constant>V4L2_CAP_VBI_CAPTURE</constant></entry> + <entry>The <link linkend="raw-vbi">raw VBI +capture</link> interface is supported.</entry> + </row> + <row> + <entry><constant>VID_TYPE_OVERLAY</constant></entry> + <entry><constant>V4L2_CAP_VIDEO_OVERLAY</constant></entry> + <entry>The <link linkend="overlay">video +overlay</link> interface is supported.</entry> + </row> + <row> + <entry><constant>VID_TYPE_CHROMAKEY</constant></entry> + <entry><constant>V4L2_FBUF_CAP_CHROMAKEY</constant> in +field <structfield>capability</structfield> of +&v4l2-framebuffer;</entry> + <entry>Whether chromakey overlay is supported. For +more information on overlay see +<xref linkend="overlay" />.</entry> + </row> + <row> + <entry><constant>VID_TYPE_CLIPPING</constant></entry> + <entry><constant>V4L2_FBUF_CAP_LIST_CLIPPING</constant> +and <constant>V4L2_FBUF_CAP_BITMAP_CLIPPING</constant> in field +<structfield>capability</structfield> of &v4l2-framebuffer;</entry> + <entry>Whether clipping the overlaid image is +supported, see <xref linkend="overlay" />.</entry> + </row> + <row> + <entry><constant>VID_TYPE_FRAMERAM</constant></entry> + <entry><constant>V4L2_FBUF_CAP_EXTERNOVERLAY</constant> +<emphasis>not set</emphasis> in field +<structfield>capability</structfield> of &v4l2-framebuffer;</entry> + <entry>Whether overlay overwrites frame buffer memory, +see <xref linkend="overlay" />.</entry> + </row> + <row> + <entry><constant>VID_TYPE_SCALES</constant></entry> + <entry><constant>-</constant></entry> + <entry>This flag indicates if the hardware can scale +images. The V4L2 API implies the scale factor by setting the cropping +dimensions and image size with the &VIDIOC-S-CROP; and &VIDIOC-S-FMT; +ioctl, respectively. The driver returns the closest sizes possible. +For more information on cropping and scaling see <xref + linkend="crop" />.</entry> + </row> + <row> + <entry><constant>VID_TYPE_MONOCHROME</constant></entry> + <entry><constant>-</constant></entry> + <entry>Applications can enumerate the supported image +formats with the &VIDIOC-ENUM-FMT; ioctl to determine if the device +supports grey scale capturing only. For more information on image +formats see <xref linkend="pixfmt" />.</entry> + </row> + <row> + <entry><constant>VID_TYPE_SUBCAPTURE</constant></entry> + <entry><constant>-</constant></entry> + <entry>Applications can call the &VIDIOC-G-CROP; ioctl +to determine if the device supports capturing a subsection of the full +picture ("cropping" in V4L2). If not, the ioctl returns the &EINVAL;. +For more information on cropping and scaling see <xref + linkend="crop" />.</entry> + </row> + <row> + <entry><constant>VID_TYPE_MPEG_DECODER</constant></entry> + <entry><constant>-</constant></entry> + <entry>Applications can enumerate the supported image +formats with the &VIDIOC-ENUM-FMT; ioctl to determine if the device +supports MPEG streams.</entry> + </row> + <row> + <entry><constant>VID_TYPE_MPEG_ENCODER</constant></entry> + <entry><constant>-</constant></entry> + <entry>See above.</entry> + </row> + <row> + <entry><constant>VID_TYPE_MJPEG_DECODER</constant></entry> + <entry><constant>-</constant></entry> + <entry>See above.</entry> + </row> + <row> + <entry><constant>VID_TYPE_MJPEG_ENCODER</constant></entry> + <entry><constant>-</constant></entry> + <entry>See above.</entry> + </row> + </tbody> + </tgroup> + </informaltable></para> + + <para>The <structfield>audios</structfield> field was replaced +by <structfield>capabilities</structfield> flag +<constant>V4L2_CAP_AUDIO</constant>, indicating +<emphasis>if</emphasis> the device has any audio inputs or outputs. To +determine their number applications can enumerate audio inputs with +the &VIDIOC-G-AUDIO; ioctl. The audio ioctls are described in <xref + linkend="audio" />.</para> + + <para>The <structfield>maxwidth</structfield>, +<structfield>maxheight</structfield>, +<structfield>minwidth</structfield> and +<structfield>minheight</structfield> fields were removed. Calling the +&VIDIOC-S-FMT; or &VIDIOC-TRY-FMT; ioctl with the desired dimensions +returns the closest size possible, taking into account the current +video standard, cropping and scaling limitations.</para> + </section> + + <section> + <title>Video Sources</title> + + <para>V4L provides the <constant>VIDIOCGCHAN</constant> and +<constant>VIDIOCSCHAN</constant> ioctl using struct +<structname>video_channel</structname> to enumerate +the video inputs of a V4L device. The equivalent V4L2 ioctls +are &VIDIOC-ENUMINPUT;, &VIDIOC-G-INPUT; and &VIDIOC-S-INPUT; +using &v4l2-input; as discussed in <xref linkend="video" />.</para> + + <para>The <structfield>channel</structfield> field counting +inputs was renamed to <structfield>index</structfield>, the video +input types were renamed as follows: <informaltable> + <tgroup cols="2"> + <thead> + <row> + <entry>struct <structname>video_channel</structname> +<structfield>type</structfield></entry> + <entry>&v4l2-input; +<structfield>type</structfield></entry> + </row> + </thead> + <tbody valign="top"> + <row> + <entry><constant>VIDEO_TYPE_TV</constant></entry> + <entry><constant>V4L2_INPUT_TYPE_TUNER</constant></entry> + </row> + <row> + <entry><constant>VIDEO_TYPE_CAMERA</constant></entry> + <entry><constant>V4L2_INPUT_TYPE_CAMERA</constant></entry> + </row> + </tbody> + </tgroup> + </informaltable></para> + + <para>Unlike the <structfield>tuners</structfield> field +expressing the number of tuners of this input, V4L2 assumes each video +input is connected to at most one tuner. However a tuner can have more +than one input, &ie; RF connectors, and a device can have multiple +tuners. The index number of the tuner associated with the input, if +any, is stored in field <structfield>tuner</structfield> of +&v4l2-input;. Enumeration of tuners is discussed in <xref + linkend="tuner" />.</para> + + <para>The redundant <constant>VIDEO_VC_TUNER</constant> flag was +dropped. Video inputs associated with a tuner are of type +<constant>V4L2_INPUT_TYPE_TUNER</constant>. The +<constant>VIDEO_VC_AUDIO</constant> flag was replaced by the +<structfield>audioset</structfield> field. V4L2 considers devices with +up to 32 audio inputs. Each set bit in the +<structfield>audioset</structfield> field represents one audio input +this video input combines with. For information about audio inputs and +how to switch between them see <xref linkend="audio" />.</para> + + <para>The <structfield>norm</structfield> field describing the +supported video standards was replaced by +<structfield>std</structfield>. The V4L specification mentions a flag +<constant>VIDEO_VC_NORM</constant> indicating whether the standard can +be changed. This flag was a later addition together with the +<structfield>norm</structfield> field and has been removed in the +meantime. V4L2 has a similar, albeit more comprehensive approach +to video standards, see <xref linkend="standard" /> for more +information.</para> + </section> + + <section> + <title>Tuning</title> + + <para>The V4L <constant>VIDIOCGTUNER</constant> and +<constant>VIDIOCSTUNER</constant> ioctl and struct +<structname>video_tuner</structname> can be used to enumerate the +tuners of a V4L TV or radio device. The equivalent V4L2 ioctls are +&VIDIOC-G-TUNER; and &VIDIOC-S-TUNER; using &v4l2-tuner;. Tuners are +covered in <xref linkend="tuner" />.</para> + + <para>The <structfield>tuner</structfield> field counting tuners +was renamed to <structfield>index</structfield>. The fields +<structfield>name</structfield>, <structfield>rangelow</structfield> +and <structfield>rangehigh</structfield> remained unchanged.</para> + + <para>The <constant>VIDEO_TUNER_PAL</constant>, +<constant>VIDEO_TUNER_NTSC</constant> and +<constant>VIDEO_TUNER_SECAM</constant> flags indicating the supported +video standards were dropped. This information is now contained in the +associated &v4l2-input;. No replacement exists for the +<constant>VIDEO_TUNER_NORM</constant> flag indicating whether the +video standard can be switched. The <structfield>mode</structfield> +field to select a different video standard was replaced by a whole new +set of ioctls and structures described in <xref linkend="standard" />. +Due to its ubiquity it should be mentioned the BTTV driver supports +several standards in addition to the regular +<constant>VIDEO_MODE_PAL</constant> (0), +<constant>VIDEO_MODE_NTSC</constant>, +<constant>VIDEO_MODE_SECAM</constant> and +<constant>VIDEO_MODE_AUTO</constant> (3). Namely N/PAL Argentina, +M/PAL, N/PAL, and NTSC Japan with numbers 3-6 (sic).</para> + + <para>The <constant>VIDEO_TUNER_STEREO_ON</constant> flag +indicating stereo reception became +<constant>V4L2_TUNER_SUB_STEREO</constant> in field +<structfield>rxsubchans</structfield>. This field also permits the +detection of monaural and bilingual audio, see the definition of +&v4l2-tuner; for details. Presently no replacement exists for the +<constant>VIDEO_TUNER_RDS_ON</constant> and +<constant>VIDEO_TUNER_MBS_ON</constant> flags.</para> + + <para> The <constant>VIDEO_TUNER_LOW</constant> flag was renamed +to <constant>V4L2_TUNER_CAP_LOW</constant> in the &v4l2-tuner; +<structfield>capability</structfield> field.</para> + + <para>The <constant>VIDIOCGFREQ</constant> and +<constant>VIDIOCSFREQ</constant> ioctl to change the tuner frequency +where renamed to &VIDIOC-G-FREQUENCY; and &VIDIOC-S-FREQUENCY;. They +take a pointer to a &v4l2-frequency; instead of an unsigned long +integer.</para> + </section> + + <section id="v4l-image-properties"> + <title>Image Properties</title> + + <para>V4L2 has no equivalent of the +<constant>VIDIOCGPICT</constant> and <constant>VIDIOCSPICT</constant> +ioctl and struct <structname>video_picture</structname>. The following +fields where replaced by V4L2 controls accessible with the +&VIDIOC-QUERYCTRL;, &VIDIOC-G-CTRL; and &VIDIOC-S-CTRL; ioctls:<informaltable> + <tgroup cols="2"> + <thead> + <row> + <entry>struct <structname>video_picture</structname></entry> + <entry>V4L2 Control ID</entry> + </row> + </thead> + <tbody valign="top"> + <row> + <entry><structfield>brightness</structfield></entry> + <entry><constant>V4L2_CID_BRIGHTNESS</constant></entry> + </row> + <row> + <entry><structfield>hue</structfield></entry> + <entry><constant>V4L2_CID_HUE</constant></entry> + </row> + <row> + <entry><structfield>colour</structfield></entry> + <entry><constant>V4L2_CID_SATURATION</constant></entry> + </row> + <row> + <entry><structfield>contrast</structfield></entry> + <entry><constant>V4L2_CID_CONTRAST</constant></entry> + </row> + <row> + <entry><structfield>whiteness</structfield></entry> + <entry><constant>V4L2_CID_WHITENESS</constant></entry> + </row> + </tbody> + </tgroup> + </informaltable></para> + + <para>The V4L picture controls are assumed to range from 0 to +65535 with no particular reset value. The V4L2 API permits arbitrary +limits and defaults which can be queried with the &VIDIOC-QUERYCTRL; +ioctl. For general information about controls see <xref +linkend="control" />.</para> + + <para>The <structfield>depth</structfield> (average number of +bits per pixel) of a video image is implied by the selected image +format. V4L2 does not explicitely provide such information assuming +applications recognizing the format are aware of the image depth and +others need not know. The <structfield>palette</structfield> field +moved into the &v4l2-pix-format;:<informaltable> + <tgroup cols="2"> + <thead> + <row> + <entry>struct <structname>video_picture</structname> +<structfield>palette</structfield></entry> + <entry>&v4l2-pix-format; +<structfield>pixfmt</structfield></entry> + </row> + </thead> + <tbody valign="top"> + <row> + <entry><constant>VIDEO_PALETTE_GREY</constant></entry> + <entry><para><link +linkend="V4L2-PIX-FMT-GREY"><constant>V4L2_PIX_FMT_GREY</constant></link></para></entry> + </row> + <row> + <entry><constant>VIDEO_PALETTE_HI240</constant></entry> + <entry><para><link +linkend="pixfmt-reserved"><constant>V4L2_PIX_FMT_HI240</constant></link><footnote> + <para>This is a custom format used by the BTTV +driver, not one of the V4L2 standard formats.</para> + </footnote></para></entry> + </row> + <row> + <entry><constant>VIDEO_PALETTE_RGB565</constant></entry> + <entry><para><link +linkend="pixfmt-rgb"><constant>V4L2_PIX_FMT_RGB565</constant></link></para></entry> + </row> + <row> + <entry><constant>VIDEO_PALETTE_RGB555</constant></entry> + <entry><para><link +linkend="pixfmt-rgb"><constant>V4L2_PIX_FMT_RGB555</constant></link></para></entry> + </row> + <row> + <entry><constant>VIDEO_PALETTE_RGB24</constant></entry> + <entry><para><link +linkend="pixfmt-rgb"><constant>V4L2_PIX_FMT_BGR24</constant></link></para></entry> + </row> + <row> + <entry><constant>VIDEO_PALETTE_RGB32</constant></entry> + <entry><para><link +linkend="pixfmt-rgb"><constant>V4L2_PIX_FMT_BGR32</constant></link><footnote> + <para>Presumably all V4L RGB formats are +little-endian, although some drivers might interpret them according to machine endianess. V4L2 defines little-endian, big-endian and red/blue +swapped variants. For details see <xref linkend="pixfmt-rgb" />.</para> + </footnote></para></entry> + </row> + <row> + <entry><constant>VIDEO_PALETTE_YUV422</constant></entry> + <entry><para><link +linkend="V4L2-PIX-FMT-YUYV"><constant>V4L2_PIX_FMT_YUYV</constant></link></para></entry> + </row> + <row> + <entry><para><constant>VIDEO_PALETTE_YUYV</constant><footnote> + <para><constant>VIDEO_PALETTE_YUV422</constant> +and <constant>VIDEO_PALETTE_YUYV</constant> are the same formats. Some +V4L drivers respond to one, some to the other.</para> + </footnote></para></entry> + <entry><para><link +linkend="V4L2-PIX-FMT-YUYV"><constant>V4L2_PIX_FMT_YUYV</constant></link></para></entry> + </row> + <row> + <entry><constant>VIDEO_PALETTE_UYVY</constant></entry> + <entry><para><link +linkend="V4L2-PIX-FMT-UYVY"><constant>V4L2_PIX_FMT_UYVY</constant></link></para></entry> + </row> + <row> + <entry><constant>VIDEO_PALETTE_YUV420</constant></entry> + <entry>None</entry> + </row> + <row> + <entry><constant>VIDEO_PALETTE_YUV411</constant></entry> + <entry><para><link +linkend="V4L2-PIX-FMT-Y41P"><constant>V4L2_PIX_FMT_Y41P</constant></link><footnote> + <para>Not to be confused with +<constant>V4L2_PIX_FMT_YUV411P</constant>, which is a planar +format.</para> </footnote></para></entry> + </row> + <row> + <entry><constant>VIDEO_PALETTE_RAW</constant></entry> + <entry><para>None<footnote> <para>V4L explains this +as: "RAW capture (BT848)"</para> </footnote></para></entry> + </row> + <row> + <entry><constant>VIDEO_PALETTE_YUV422P</constant></entry> + <entry><para><link +linkend="V4L2-PIX-FMT-YUV422P"><constant>V4L2_PIX_FMT_YUV422P</constant></link></para></entry> + </row> + <row> + <entry><constant>VIDEO_PALETTE_YUV411P</constant></entry> + <entry><para><link +linkend="V4L2-PIX-FMT-YUV411P"><constant>V4L2_PIX_FMT_YUV411P</constant></link><footnote> + <para>Not to be confused with +<constant>V4L2_PIX_FMT_Y41P</constant>, which is a packed +format.</para> </footnote></para></entry> + </row> + <row> + <entry><constant>VIDEO_PALETTE_YUV420P</constant></entry> + <entry><para><link +linkend="V4L2-PIX-FMT-YVU420"><constant>V4L2_PIX_FMT_YVU420</constant></link></para></entry> + </row> + <row> + <entry><constant>VIDEO_PALETTE_YUV410P</constant></entry> + <entry><para><link +linkend="V4L2-PIX-FMT-YVU410"><constant>V4L2_PIX_FMT_YVU410</constant></link></para></entry> + </row> + </tbody> + </tgroup> + </informaltable></para> + + <para>V4L2 image formats are defined in <xref +linkend="pixfmt" />. The image format can be selected with the +&VIDIOC-S-FMT; ioctl.</para> + </section> + + <section> + <title>Audio</title> + + <para>The <constant>VIDIOCGAUDIO</constant> and +<constant>VIDIOCSAUDIO</constant> ioctl and struct +<structname>video_audio</structname> are used to enumerate the +audio inputs of a V4L device. The equivalent V4L2 ioctls are +&VIDIOC-G-AUDIO; and &VIDIOC-S-AUDIO; using &v4l2-audio; as +discussed in <xref linkend="audio" />.</para> + + <para>The <structfield>audio</structfield> "channel number" +field counting audio inputs was renamed to +<structfield>index</structfield>.</para> + + <para>On <constant>VIDIOCSAUDIO</constant> the +<structfield>mode</structfield> field selects <emphasis>one</emphasis> +of the <constant>VIDEO_SOUND_MONO</constant>, +<constant>VIDEO_SOUND_STEREO</constant>, +<constant>VIDEO_SOUND_LANG1</constant> or +<constant>VIDEO_SOUND_LANG2</constant> audio demodulation modes. When +the current audio standard is BTSC +<constant>VIDEO_SOUND_LANG2</constant> refers to SAP and +<constant>VIDEO_SOUND_LANG1</constant> is meaningless. Also +undocumented in the V4L specification, there is no way to query the +selected mode. On <constant>VIDIOCGAUDIO</constant> the driver returns +the <emphasis>actually received</emphasis> audio programmes in this +field. In the V4L2 API this information is stored in the &v4l2-tuner; +<structfield>rxsubchans</structfield> and +<structfield>audmode</structfield> fields, respectively. See <xref +linkend="tuner" /> for more information on tuners. Related to audio +modes &v4l2-audio; also reports if this is a mono or stereo +input, regardless if the source is a tuner.</para> + + <para>The following fields where replaced by V4L2 controls +accessible with the &VIDIOC-QUERYCTRL;, &VIDIOC-G-CTRL; and +&VIDIOC-S-CTRL; ioctls:<informaltable> + <tgroup cols="2"> + <thead> + <row> + <entry>struct +<structname>video_audio</structname></entry> + <entry>V4L2 Control ID</entry> + </row> + </thead> + <tbody valign="top"> + <row> + <entry><structfield>volume</structfield></entry> + <entry><constant>V4L2_CID_AUDIO_VOLUME</constant></entry> + </row> + <row> + <entry><structfield>bass</structfield></entry> + <entry><constant>V4L2_CID_AUDIO_BASS</constant></entry> + </row> + <row> + <entry><structfield>treble</structfield></entry> + <entry><constant>V4L2_CID_AUDIO_TREBLE</constant></entry> + </row> + <row> + <entry><structfield>balance</structfield></entry> + <entry><constant>V4L2_CID_AUDIO_BALANCE</constant></entry> + </row> + </tbody> + </tgroup> + </informaltable></para> + + <para>To determine which of these controls are supported by a +driver V4L provides the <structfield>flags</structfield> +<constant>VIDEO_AUDIO_VOLUME</constant>, +<constant>VIDEO_AUDIO_BASS</constant>, +<constant>VIDEO_AUDIO_TREBLE</constant> and +<constant>VIDEO_AUDIO_BALANCE</constant>. In the V4L2 API the +&VIDIOC-QUERYCTRL; ioctl reports if the respective control is +supported. Accordingly the <constant>VIDEO_AUDIO_MUTABLE</constant> +and <constant>VIDEO_AUDIO_MUTE</constant> flags where replaced by the +boolean <constant>V4L2_CID_AUDIO_MUTE</constant> control.</para> + + <para>All V4L2 controls have a <structfield>step</structfield> +attribute replacing the struct <structname>video_audio</structname> +<structfield>step</structfield> field. The V4L audio controls are +assumed to range from 0 to 65535 with no particular reset value. The +V4L2 API permits arbitrary limits and defaults which can be queried +with the &VIDIOC-QUERYCTRL; ioctl. For general information about +controls see <xref linkend="control" />.</para> + </section> + + <section> + <title>Frame Buffer Overlay</title> + + <para>The V4L2 ioctls equivalent to +<constant>VIDIOCGFBUF</constant> and <constant>VIDIOCSFBUF</constant> +are &VIDIOC-G-FBUF; and &VIDIOC-S-FBUF;. The +<structfield>base</structfield> field of struct +<structname>video_buffer</structname> remained unchanged, except V4L2 +defines a flag to indicate non-destructive overlays instead of a +<constant>NULL</constant> pointer. All other fields moved into the +&v4l2-pix-format; <structfield>fmt</structfield> substructure of +&v4l2-framebuffer;. The <structfield>depth</structfield> field was +replaced by <structfield>pixelformat</structfield>. See <xref + linkend="pixfmt-rgb" /> for a list of RGB formats and their +respective color depths.</para> + + <para>Instead of the special ioctls +<constant>VIDIOCGWIN</constant> and <constant>VIDIOCSWIN</constant> +V4L2 uses the general-purpose data format negotiation ioctls +&VIDIOC-G-FMT; and &VIDIOC-S-FMT;. They take a pointer to a +&v4l2-format; as argument. Here the <structfield>win</structfield> +member of the <structfield>fmt</structfield> union is used, a +&v4l2-window;.</para> + + <para>The <structfield>x</structfield>, +<structfield>y</structfield>, <structfield>width</structfield> and +<structfield>height</structfield> fields of struct +<structname>video_window</structname> moved into &v4l2-rect; +substructure <structfield>w</structfield> of struct +<structname>v4l2_window</structname>. The +<structfield>chromakey</structfield>, +<structfield>clips</structfield>, and +<structfield>clipcount</structfield> fields remained unchanged. Struct +<structname>video_clip</structname> was renamed to &v4l2-clip;, also +containing a struct <structname>v4l2_rect</structname>, but the +semantics are still the same.</para> + + <para>The <constant>VIDEO_WINDOW_INTERLACE</constant> flag was +dropped. Instead applications must set the +<structfield>field</structfield> field to +<constant>V4L2_FIELD_ANY</constant> or +<constant>V4L2_FIELD_INTERLACED</constant>. The +<constant>VIDEO_WINDOW_CHROMAKEY</constant> flag moved into +&v4l2-framebuffer;, under the new name +<constant>V4L2_FBUF_FLAG_CHROMAKEY</constant>.</para> + + <para>In V4L, storing a bitmap pointer in +<structfield>clips</structfield> and setting +<structfield>clipcount</structfield> to +<constant>VIDEO_CLIP_BITMAP</constant> (-1) requests bitmap +clipping, using a fixed size bitmap of 1024 × 625 bits. Struct +<structname>v4l2_window</structname> has a separate +<structfield>bitmap</structfield> pointer field for this purpose and +the bitmap size is determined by <structfield>w.width</structfield> and +<structfield>w.height</structfield>.</para> + + <para>The <constant>VIDIOCCAPTURE</constant> ioctl to enable or +disable overlay was renamed to &VIDIOC-OVERLAY;.</para> + </section> + + <section> + <title>Cropping</title> + + <para>To capture only a subsection of the full picture V4L +defines the <constant>VIDIOCGCAPTURE</constant> and +<constant>VIDIOCSCAPTURE</constant> ioctls using struct +<structname>video_capture</structname>. The equivalent V4L2 ioctls are +&VIDIOC-G-CROP; and &VIDIOC-S-CROP; using &v4l2-crop;, and the related +&VIDIOC-CROPCAP; ioctl. This is a rather complex matter, see +<xref linkend="crop" /> for details.</para> + + <para>The <structfield>x</structfield>, +<structfield>y</structfield>, <structfield>width</structfield> and +<structfield>height</structfield> fields moved into &v4l2-rect; +substructure <structfield>c</structfield> of struct +<structname>v4l2_crop</structname>. The +<structfield>decimation</structfield> field was dropped. In the V4L2 +API the scaling factor is implied by the size of the cropping +rectangle and the size of the captured or overlaid image.</para> + + <para>The <constant>VIDEO_CAPTURE_ODD</constant> +and <constant>VIDEO_CAPTURE_EVEN</constant> flags to capture only the +odd or even field, respectively, were replaced by +<constant>V4L2_FIELD_TOP</constant> and +<constant>V4L2_FIELD_BOTTOM</constant> in the field named +<structfield>field</structfield> of &v4l2-pix-format; and +&v4l2-window;. These structures are used to select a capture or +overlay format with the &VIDIOC-S-FMT; ioctl.</para> + </section> + + <section> + <title>Reading Images, Memory Mapping</title> + + <section> + <title>Capturing using the read method</title> + + <para>There is no essential difference between reading images +from a V4L or V4L2 device using the &func-read; function, however V4L2 +drivers are not required to support this I/O method. Applications can +determine if the function is available with the &VIDIOC-QUERYCAP; +ioctl. All V4L2 devices exchanging data with applications must support +the &func-select; and &func-poll; functions.</para> + + <para>To select an image format and size, V4L provides the +<constant>VIDIOCSPICT</constant> and <constant>VIDIOCSWIN</constant> +ioctls. V4L2 uses the general-purpose data format negotiation ioctls +&VIDIOC-G-FMT; and &VIDIOC-S-FMT;. They take a pointer to a +&v4l2-format; as argument, here the &v4l2-pix-format; named +<structfield>pix</structfield> of its <structfield>fmt</structfield> +union is used.</para> + + <para>For more information about the V4L2 read interface see +<xref linkend="rw" />.</para> + </section> + <section> + <title>Capturing using memory mapping</title> + + <para>Applications can read from V4L devices by mapping +buffers in device memory, or more often just buffers allocated in +DMA-able system memory, into their address space. This avoids the data +copying overhead of the read method. V4L2 supports memory mapping as +well, with a few differences.</para> + + <informaltable> + <tgroup cols="2"> + <thead> + <row> + <entry>V4L</entry> + <entry>V4L2</entry> + </row> + </thead> + <tbody valign="top"> + <row> + <entry></entry> + <entry>The image format must be selected before +buffers are allocated, with the &VIDIOC-S-FMT; ioctl. When no format +is selected the driver may use the last, possibly by another +application requested format.</entry> + </row> + <row> + <entry><para>Applications cannot change the number of +buffers. The it is built into the driver, unless it has a module +option to change the number when the driver module is +loaded.</para></entry> + <entry><para>The &VIDIOC-REQBUFS; ioctl allocates the +desired number of buffers, this is a required step in the initialization +sequence.</para></entry> + </row> + <row> + <entry><para>Drivers map all buffers as one contiguous +range of memory. The <constant>VIDIOCGMBUF</constant> ioctl is +available to query the number of buffers, the offset of each buffer +from the start of the virtual file, and the overall amount of memory +used, which can be used as arguments for the &func-mmap; +function.</para></entry> + <entry><para>Buffers are individually mapped. The +offset and size of each buffer can be determined with the +&VIDIOC-QUERYBUF; ioctl.</para></entry> + </row> + <row> + <entry><para>The <constant>VIDIOCMCAPTURE</constant> +ioctl prepares a buffer for capturing. It also determines the image +format for this buffer. The ioctl returns immediately, eventually with +an &EAGAIN; if no video signal had been detected. When the driver +supports more than one buffer applications can call the ioctl multiple +times and thus have multiple outstanding capture +requests.</para><para>The <constant>VIDIOCSYNC</constant> ioctl +suspends execution until a particular buffer has been +filled.</para></entry> + <entry><para>Drivers maintain an incoming and outgoing +queue. &VIDIOC-QBUF; enqueues any empty buffer into the incoming +queue. Filled buffers are dequeued from the outgoing queue with the +&VIDIOC-DQBUF; ioctl. To wait until filled buffers become available this +function, &func-select; or &func-poll; can be used. The +&VIDIOC-STREAMON; ioctl must be called once after enqueuing one or +more buffers to start capturing. Its counterpart +&VIDIOC-STREAMOFF; stops capturing and dequeues all buffers from both +queues. Applications can query the signal status, if known, with the +&VIDIOC-ENUMINPUT; ioctl.</para></entry> + </row> + </tbody> + </tgroup> + </informaltable> + + <para>For a more in-depth discussion of memory mapping and +examples, see <xref linkend="mmap" />.</para> + </section> + </section> + + <section> + <title>Reading Raw VBI Data</title> + + <para>Originally the V4L API did not specify a raw VBI capture +interface, only the device file <filename>/dev/vbi</filename> was +reserved for this purpose. The only driver supporting this interface +was the BTTV driver, de-facto defining the V4L VBI interface. Reading +from the device yields a raw VBI image with the following +parameters:<informaltable> + <tgroup cols="2"> + <thead> + <row> + <entry>&v4l2-vbi-format;</entry> + <entry>V4L, BTTV driver</entry> + </row> + </thead> + <tbody valign="top"> + <row> + <entry>sampling_rate</entry> + <entry>28636363 Hz NTSC (or any other 525-line +standard); 35468950 Hz PAL and SECAM (625-line standards)</entry> + </row> + <row> + <entry>offset</entry> + <entry>?</entry> + </row> + <row> + <entry>samples_per_line</entry> + <entry>2048</entry> + </row> + <row> + <entry>sample_format</entry> + <entry>V4L2_PIX_FMT_GREY. The last four bytes (a +machine endianess integer) contain a frame counter.</entry> + </row> + <row> + <entry>start[]</entry> + <entry>10, 273 NTSC; 22, 335 PAL and SECAM</entry> + </row> + <row> + <entry>count[]</entry> + <entry><para>16, 16<footnote><para>Old driver +versions used different values, eventually the custom +<constant>BTTV_VBISIZE</constant> ioctl was added to query the +correct values.</para></footnote></para></entry> + </row> + <row> + <entry>flags</entry> + <entry>0</entry> + </row> + </tbody> + </tgroup> + </informaltable></para> + + <para>Undocumented in the V4L specification, in Linux 2.3 the +<constant>VIDIOCGVBIFMT</constant> and +<constant>VIDIOCSVBIFMT</constant> ioctls using struct +<structname>vbi_format</structname> were added to determine the VBI +image parameters. These ioctls are only partially compatible with the +V4L2 VBI interface specified in <xref linkend="raw-vbi" />.</para> + + <para>An <structfield>offset</structfield> field does not +exist, <structfield>sample_format</structfield> is supposed to be +<constant>VIDEO_PALETTE_RAW</constant>, equivalent to +<constant>V4L2_PIX_FMT_GREY</constant>. The remaining fields are +probably equivalent to &v4l2-vbi-format;.</para> + + <para>Apparently only the Zoran (ZR 36120) driver implements +these ioctls. The semantics differ from those specified for V4L2 in two +ways. The parameters are reset on &func-open; and +<constant>VIDIOCSVBIFMT</constant> always returns an &EINVAL; if the +parameters are invalid.</para> + </section> + + <section> + <title>Miscellaneous</title> + + <para>V4L2 has no equivalent of the +<constant>VIDIOCGUNIT</constant> ioctl. Applications can find the VBI +device associated with a video capture device (or vice versa) by +reopening the device and requesting VBI data. For details see +<xref linkend="open" />.</para> + + <para>No replacement exists for <constant>VIDIOCKEY</constant>, +and the V4L functions for microcode programming. A new interface for +MPEG compression and playback devices is documented in <xref + linkend="extended-controls" />.</para> + </section> + + </section> + + <section id="hist-v4l2"> + <title>Changes of the V4L2 API</title> + + <para>Soon after the V4L API was added to the kernel it was +criticised as too inflexible. In August 1998 Bill Dirks proposed a +number of improvements and began to work on documentation, example +drivers and applications. With the help of other volunteers this +eventually became the V4L2 API, not just an extension but a +replacement for the V4L API. However it took another four years and +two stable kernel releases until the new API was finally accepted for +inclusion into the kernel in its present form.</para> + + <section> + <title>Early Versions</title> + <para>1998-08-20: First version.</para> + + <para>1998-08-27: The &func-select; function was introduced.</para> + + <para>1998-09-10: New video standard interface.</para> + + <para>1998-09-18: The <constant>VIDIOC_NONCAP</constant> ioctl +was replaced by the otherwise meaningless <constant>O_TRUNC</constant> +&func-open; flag, and the aliases <constant>O_NONCAP</constant> and +<constant>O_NOIO</constant> were defined. Applications can set this +flag if they intend to access controls only, as opposed to capture +applications which need exclusive access. The +<constant>VIDEO_STD_XXX</constant> identifiers are now ordinals +instead of flags, and the <function>video_std_construct()</function> +helper function takes id and transmission arguments.</para> + + <para>1998-09-28: Revamped video standard. Made video controls +individually enumerable.</para> + + <para>1998-10-02: The <structfield>id</structfield> field was +removed from struct <structname>video_standard</structname> and the +color subcarrier fields were renamed. The &VIDIOC-QUERYSTD; ioctl was +renamed to &VIDIOC-ENUMSTD;, &VIDIOC-G-INPUT; to &VIDIOC-ENUMINPUT;. A +first draft of the Codec API was released.</para> + + <para>1998-11-08: Many minor changes. Most symbols have been +renamed. Some material changes to &v4l2-capability;.</para> + + <para>1998-11-12: The read/write directon of some ioctls was misdefined.</para> + + <para>1998-11-14: <constant>V4L2_PIX_FMT_RGB24</constant> +changed to <constant>V4L2_PIX_FMT_BGR24</constant>, and +<constant>V4L2_PIX_FMT_RGB32</constant> changed to +<constant>V4L2_PIX_FMT_BGR32</constant>. Audio controls are now +accessible with the &VIDIOC-G-CTRL; and &VIDIOC-S-CTRL; ioctls under +names starting with <constant>V4L2_CID_AUDIO</constant>. The +<constant>V4L2_MAJOR</constant> define was removed from +<filename>videodev.h</filename> since it was only used once in the +<filename>videodev</filename> kernel module. The +<constant>YUV422</constant> and <constant>YUV411</constant> planar +image formats were added.</para> + + <para>1998-11-28: A few ioctl symbols changed. Interfaces for codecs and +video output devices were added.</para> + + <para>1999-01-14: A raw VBI capture interface was added.</para> + + <para>1999-01-19: The <constant>VIDIOC_NEXTBUF</constant> ioctl + was removed.</para> + </section> + + <section> + <title>V4L2 Version 0.16 1999-01-31</title> + <para>1999-01-27: There is now one QBUF ioctl, VIDIOC_QWBUF and VIDIOC_QRBUF +are gone. VIDIOC_QBUF takes a v4l2_buffer as a parameter. Added +digital zoom (cropping) controls.</para> + </section> + + <!-- Where's 0.17? mhs couldn't find that videodev.h, perhaps Bill + forgot to bump the version number or never released it. --> + + <section> + <title>V4L2 Version 0.18 1999-03-16</title> + <para>Added a v4l to V4L2 ioctl compatibility layer to +videodev.c. Driver writers, this changes how you implement your ioctl +handler. See the Driver Writer's Guide. Added some more control id +codes.</para> + </section> + + <section> + <title>V4L2 Version 0.19 1999-06-05</title> + <para>1999-03-18: Fill in the category and catname fields of +v4l2_queryctrl objects before passing them to the driver. Required a +minor change to the VIDIOC_QUERYCTRL handlers in the sample +drivers.</para> + <para>1999-03-31: Better compatibility for v4l memory capture +ioctls. Requires changes to drivers to fully support new compatibility +features, see Driver Writer's Guide and v4l2cap.c. Added new control +IDs: V4L2_CID_HFLIP, _VFLIP. Changed V4L2_PIX_FMT_YUV422P to _YUV422P, +and _YUV411P to _YUV411P.</para> + <para>1999-04-04: Added a few more control IDs.</para> + <para>1999-04-07: Added the button control type.</para> + <para>1999-05-02: Fixed a typo in videodev.h, and added the +V4L2_CTRL_FLAG_GRAYED (later V4L2_CTRL_FLAG_GRABBED) flag.</para> + <para>1999-05-20: Definition of VIDIOC_G_CTRL was wrong causing +a malfunction of this ioctl.</para> + <para>1999-06-05: Changed the value of +V4L2_CID_WHITENESS.</para> + </section> + + <section> + <title>V4L2 Version 0.20 (1999-09-10)</title> + + <para>Version 0.20 introduced a number of changes which were +<emphasis>not backward compatible</emphasis> with 0.19 and earlier +versions. Purpose of these changes was to simplify the API, while +making it more extensible and following common Linux driver API +conventions.</para> + + <orderedlist> + <listitem> + <para>Some typos in <constant>V4L2_FMT_FLAG</constant> +symbols were fixed. &v4l2-clip; was changed for compatibility with +v4l. (1999-08-30)</para> + </listitem> + + <listitem> + <para><constant>V4L2_TUNER_SUB_LANG1</constant> was added. +(1999-09-05)</para> + </listitem> + + <listitem> + <para>All ioctl() commands that used an integer argument now +take a pointer to an integer. Where it makes sense, ioctls will return +the actual new value in the integer pointed to by the argument, a +common convention in the V4L2 API. The affected ioctls are: +VIDIOC_PREVIEW, VIDIOC_STREAMON, VIDIOC_STREAMOFF, VIDIOC_S_FREQ, +VIDIOC_S_INPUT, VIDIOC_S_OUTPUT, VIDIOC_S_EFFECT. For example +<programlisting> +err = ioctl (fd, VIDIOC_XXX, V4L2_XXX); +</programlisting> becomes <programlisting> +int a = V4L2_XXX; err = ioctl(fd, VIDIOC_XXX, &a); +</programlisting> + </para> + </listitem> + + <listitem> + <para>All the different get- and set-format commands were +swept into one &VIDIOC-G-FMT; and &VIDIOC-S-FMT; ioctl taking a union +and a type field selecting the union member as parameter. Purpose is to +simplify the API by eliminating several ioctls and to allow new and +driver private data streams without adding new ioctls.</para> + + <para>This change obsoletes the following ioctls: +<constant>VIDIOC_S_INFMT</constant>, +<constant>VIDIOC_G_INFMT</constant>, +<constant>VIDIOC_S_OUTFMT</constant>, +<constant>VIDIOC_G_OUTFMT</constant>, +<constant>VIDIOC_S_VBIFMT</constant> and +<constant>VIDIOC_G_VBIFMT</constant>. The image format structure +<structname>v4l2_format</structname> was renamed to &v4l2-pix-format;, +while &v4l2-format; is now the envelopping structure for all format +negotiations.</para> + </listitem> + + <listitem> + <para>Similar to the changes above, the +<constant>VIDIOC_G_PARM</constant> and +<constant>VIDIOC_S_PARM</constant> ioctls were merged with +<constant>VIDIOC_G_OUTPARM</constant> and +<constant>VIDIOC_S_OUTPARM</constant>. A +<structfield>type</structfield> field in the new &v4l2-streamparm; +selects the respective union member.</para> + + <para>This change obsoletes the +<constant>VIDIOC_G_OUTPARM</constant> and +<constant>VIDIOC_S_OUTPARM</constant> ioctls.</para> + </listitem> + + <listitem> + <para>Control enumeration was simplified, and two new +control flags were introduced and one dropped. The +<structfield>catname</structfield> field was replaced by a +<structfield>group</structfield> field.</para> + + <para>Drivers can now flag unsupported and temporarily +unavailable controls with <constant>V4L2_CTRL_FLAG_DISABLED</constant> +and <constant>V4L2_CTRL_FLAG_GRABBED</constant> respectively. The +<structfield>group</structfield> name indicates a possibly narrower +classification than the <structfield>category</structfield>. In other +words, there may be multiple groups within a category. Controls within +a group would typically be drawn within a group box. Controls in +different categories might have a greater separation, or may even +appear in separate windows.</para> + </listitem> + + <listitem> + <para>The &v4l2-buffer; <structfield>timestamp</structfield> +was changed to a 64 bit integer, containing the sampling or output +time of the frame in nanoseconds. Additionally timestamps will be in +absolute system time, not starting from zero at the beginning of a +stream. The data type name for timestamps is stamp_t, defined as a +signed 64-bit integer. Output devices should not send a buffer out +until the time in the timestamp field has arrived. I would like to +follow SGI's lead, and adopt a multimedia timestamping system like +their UST (Unadjusted System Time). See +http://reality.sgi.com/cpirazzi_engr/lg/time/intro.html. [This link is +no longer valid.] UST uses timestamps that are 64-bit signed integers +(not struct timeval's) and given in nanosecond units. The UST clock +starts at zero when the system is booted and runs continuously and +uniformly. It takes a little over 292 years for UST to overflow. There +is no way to set the UST clock. The regular Linux time-of-day clock +can be changed periodically, which would cause errors if it were being +used for timestamping a multimedia stream. A real UST style clock will +require some support in the kernel that is not there yet. But in +anticipation, I will change the timestamp field to a 64-bit integer, +and I will change the v4l2_masterclock_gettime() function (used only +by drivers) to return a 64-bit integer.</para> + </listitem> + + <listitem> + <para>A <structfield>sequence</structfield> field was added +to &v4l2-buffer;. The <structfield>sequence</structfield> field counts +captured frames, it is ignored by output devices. When a capture +driver drops a frame, the sequence number of that frame is +skipped.</para> + </listitem> + </orderedlist> + </section> + + <section> + <title>V4L2 Version 0.20 incremental changes</title> + <!-- Version number didn't change anymore, reason unknown. --> + + <para>1999-12-23: In &v4l2-vbi-format; the +<structfield>reserved1</structfield> field became +<structfield>offset</structfield>. Previously drivers were required to +clear the <structfield>reserved1</structfield> field.</para> + + <para>2000-01-13: The + <constant>V4L2_FMT_FLAG_NOT_INTERLACED</constant> flag was added.</para> + + <para>2000-07-31: The <filename>linux/poll.h</filename> header +is now included by <filename>videodev.h</filename> for compatibility +with the original <filename>videodev.h</filename> file.</para> + + <para>2000-11-20: <constant>V4L2_TYPE_VBI_OUTPUT</constant> and +<constant>V4L2_PIX_FMT_Y41P</constant> were added.</para> + + <para>2000-11-25: <constant>V4L2_TYPE_VBI_INPUT</constant> was +added.</para> + + <para>2000-12-04: A couple typos in symbol names were fixed.</para> + + <para>2001-01-18: To avoid namespace conflicts the +<constant>fourcc</constant> macro defined in the +<filename>videodev.h</filename> header file was renamed to +<constant>v4l2_fourcc</constant>.</para> + + <para>2001-01-25: A possible driver-level compatibility problem +between the <filename>videodev.h</filename> file in Linux 2.4.0 and +the <filename>videodev.h</filename> file included in the +<filename>videodevX</filename> patch was fixed. Users of an earlier +version of <filename>videodevX</filename> on Linux 2.4.0 should +recompile their V4L and V4L2 drivers.</para> + + <para>2001-01-26: A possible kernel-level incompatibility +between the <filename>videodev.h</filename> file in the +<filename>videodevX</filename> patch and the +<filename>videodev.h</filename> file in Linux 2.2.x with devfs patches +applied was fixed.</para> + + <para>2001-03-02: Certain V4L ioctls which pass data in both +direction although they are defined with read-only parameter, did not +work correctly through the backward compatibility layer. +[Solution?]</para> + + <para>2001-04-13: Big endian 16-bit RGB formats were added.</para> + + <para>2001-09-17: New YUV formats and the &VIDIOC-G-FREQUENCY; and +&VIDIOC-S-FREQUENCY; ioctls were added. (The old +<constant>VIDIOC_G_FREQ</constant> and +<constant>VIDIOC_S_FREQ</constant> ioctls did not take multiple tuners +into account.)</para> + + <para>2000-09-18: <constant>V4L2_BUF_TYPE_VBI</constant> was +added. This may <emphasis>break compatibility</emphasis> as the +&VIDIOC-G-FMT; and &VIDIOC-S-FMT; ioctls may fail now if the struct +<structname>v4l2_fmt</structname> <structfield>type</structfield> +field does not contain <constant>V4L2_BUF_TYPE_VBI</constant>. In the +documentation of the &v4l2-vbi-format; +<structfield>offset</structfield> field the ambiguous phrase "rising +edge" was changed to "leading edge".</para> + </section> + + <section> + <title>V4L2 Version 0.20 2000-11-23</title> + + <para>A number of changes were made to the raw VBI +interface.</para> + + <orderedlist> + <listitem> + <para>Figures clarifying the line numbering scheme were +added to the V4L2 API specification. The +<structfield>start</structfield>[0] and +<structfield>start</structfield>[1] fields no longer count line +numbers beginning at zero. Rationale: a) The previous definition was +unclear. b) The <structfield>start</structfield>[] values are ordinal +numbers. c) There is no point in inventing a new line numbering +scheme. We now use line number as defined by ITU-R, period. +Compatibility: Add one to the start values. Applications depending on +the previous semantics may not function correctly.</para> + </listitem> + + <listitem> + <para>The restriction "count[0] > 0 and count[1] > 0" +has been relaxed to "(count[0] + count[1]) > 0". Rationale: +Drivers may allocate resources at scan line granularity and some data +services are transmitted only on the first field. The comment that +both <structfield>count</structfield> values will usually be equal is +misleading and pointless and has been removed. This change +<emphasis>breaks compatibility</emphasis> with earlier versions: +Drivers may return EINVAL, applications may not function +correctly.</para> + </listitem> + + <listitem> + <para>Drivers are again permitted to return negative +(unknown) start values as proposed earlier. Why this feature was +dropped is unclear. This change may <emphasis>break +compatibility</emphasis> with applications depending on the start +values being positive. The use of <constant>EBUSY</constant> and +<constant>EINVAL</constant> error codes with the &VIDIOC-S-FMT; ioctl +was clarified. The &EBUSY; was finally documented, and the +<structfield>reserved2</structfield> field which was previously +mentioned only in the <filename>videodev.h</filename> header +file.</para> + </listitem> + + <listitem> + <para>New buffer types +<constant>V4L2_TYPE_VBI_INPUT</constant> and +<constant>V4L2_TYPE_VBI_OUTPUT</constant> were added. The former is an +alias for the old <constant>V4L2_TYPE_VBI</constant>, the latter was +missing in the <filename>videodev.h</filename> file.</para> + </listitem> + </orderedlist> + </section> + + <section> + <title>V4L2 Version 0.20 2002-07-25</title> + <para>Added sliced VBI interface proposal.</para> + </section> + + <section> + <title>V4L2 in Linux 2.5.46, 2002-10</title> + + <para>Around October-November 2002, prior to an announced +feature freeze of Linux 2.5, the API was revised, drawing from +experience with V4L2 0.20. This unnamed version was finally merged +into Linux 2.5.46.</para> + + <orderedlist> + <listitem> + <para>As specified in <xref linkend="related" />, drivers +must make related device functions available under all minor device +numbers.</para> + </listitem> + + <listitem> + <para>The &func-open; function requires access mode +<constant>O_RDWR</constant> regardless of the device type. All V4L2 +drivers exchanging data with applications must support the +<constant>O_NONBLOCK</constant> flag. The <constant>O_NOIO</constant> +flag, a V4L2 symbol which aliased the meaningless +<constant>O_TRUNC</constant> to indicate accesses without data +exchange (panel applications) was dropped. Drivers must stay in "panel +mode" until the application attempts to initiate a data exchange, see +<xref linkend="open" />.</para> + </listitem> + + <listitem> + <para>The &v4l2-capability; changed dramatically. Note that +also the size of the structure changed, which is encoded in the ioctl +request code, thus older V4L2 devices will respond with an &EINVAL; to +the new &VIDIOC-QUERYCAP; ioctl.</para> + + <para>There are new fields to identify the driver, a new RDS +device function <constant>V4L2_CAP_RDS_CAPTURE</constant>, the +<constant>V4L2_CAP_AUDIO</constant> flag indicates if the device has +any audio connectors, another I/O capability +<constant>V4L2_CAP_ASYNCIO</constant> can be flagged. In response to +these changes the <structfield>type</structfield> field became a bit +set and was merged into the <structfield>flags</structfield> field. +<constant>V4L2_FLAG_TUNER</constant> was renamed to +<constant>V4L2_CAP_TUNER</constant>, +<constant>V4L2_CAP_VIDEO_OVERLAY</constant> replaced +<constant>V4L2_FLAG_PREVIEW</constant> and +<constant>V4L2_CAP_VBI_CAPTURE</constant> and +<constant>V4L2_CAP_VBI_OUTPUT</constant> replaced +<constant>V4L2_FLAG_DATA_SERVICE</constant>. +<constant>V4L2_FLAG_READ</constant> and +<constant>V4L2_FLAG_WRITE</constant> were merged into +<constant>V4L2_CAP_READWRITE</constant>.</para> + + <para>The redundant fields +<structfield>inputs</structfield>, <structfield>outputs</structfield> +and <structfield>audios</structfield> were removed. These properties +can be determined as described in <xref linkend="video" /> and <xref +linkend="audio" />.</para> + + <para>The somewhat volatile and therefore barely useful +fields <structfield>maxwidth</structfield>, +<structfield>maxheight</structfield>, +<structfield>minwidth</structfield>, +<structfield>minheight</structfield>, +<structfield>maxframerate</structfield> were removed. This information +is available as described in <xref linkend="format" /> and +<xref linkend="standard" />.</para> + + <para><constant>V4L2_FLAG_SELECT</constant> was removed. We +believe the select() function is important enough to require support +of it in all V4L2 drivers exchanging data with applications. The +redundant <constant>V4L2_FLAG_MONOCHROME</constant> flag was removed, +this information is available as described in <xref + linkend="format" />.</para> + </listitem> + + <listitem> + <para>In &v4l2-input; the +<structfield>assoc_audio</structfield> field and the +<structfield>capability</structfield> field and its only flag +<constant>V4L2_INPUT_CAP_AUDIO</constant> was replaced by the new +<structfield>audioset</structfield> field. Instead of linking one +video input to one audio input this field reports all audio inputs +this video input combines with.</para> + + <para>New fields are <structfield>tuner</structfield> +(reversing the former link from tuners to video inputs), +<structfield>std</structfield> and +<structfield>status</structfield>.</para> + + <para>Accordingly &v4l2-output; lost its +<structfield>capability</structfield> and +<structfield>assoc_audio</structfield> fields. +<structfield>audioset</structfield>, +<structfield>modulator</structfield> and +<structfield>std</structfield> where added instead.</para> + </listitem> + + <listitem> + <para>The &v4l2-audio; field +<structfield>audio</structfield> was renamed to +<structfield>index</structfield>, for consistency with other +structures. A new capability flag +<constant>V4L2_AUDCAP_STEREO</constant> was added to indicated if the +audio input in question supports stereo sound. +<constant>V4L2_AUDCAP_EFFECTS</constant> and the corresponding +<constant>V4L2_AUDMODE</constant> flags where removed. This can be +easily implemented using controls. (However the same applies to AVL +which is still there.)</para> + + <para>Again for consistency the &v4l2-audioout; field +<structfield>audio</structfield> was renamed to +<structfield>index</structfield>.</para> + </listitem> + + <listitem> + <para>The &v4l2-tuner; +<structfield>input</structfield> field was replaced by an +<structfield>index</structfield> field, permitting devices with +multiple tuners. The link between video inputs and tuners is now +reversed, inputs point to their tuner. The +<structfield>std</structfield> substructure became a +simple set (more about this below) and moved into &v4l2-input;. A +<structfield>type</structfield> field was added.</para> + + <para>Accordingly in &v4l2-modulator; the +<structfield>output</structfield> was replaced by an +<structfield>index</structfield> field.</para> + + <para>In &v4l2-frequency; the +<structfield>port</structfield> field was replaced by a +<structfield>tuner</structfield> field containing the respective tuner +or modulator index number. A tuner <structfield>type</structfield> +field was added and the <structfield>reserved</structfield> field +became larger for future extensions (satellite tuners in +particular).</para> + </listitem> + + <listitem> + <para>The idea of completely transparent video standards was +dropped. Experience showed that applications must be able to work with +video standards beyond presenting the user a menu. Instead of +enumerating supported standards with an ioctl applications can now +refer to standards by &v4l2-std-id; and symbols defined in the +<filename>videodev2.h</filename> header file. For details see <xref + linkend="standard" />. The &VIDIOC-G-STD; and +&VIDIOC-S-STD; now take a pointer to this type as argument. +&VIDIOC-QUERYSTD; was added to autodetect the received standard, if +the hardware has this capability. In &v4l2-standard; an +<structfield>index</structfield> field was added for &VIDIOC-ENUMSTD;. +A &v4l2-std-id; field named <structfield>id</structfield> was added as +machine readable identifier, also replacing the +<structfield>transmission</structfield> field. The misleading +<structfield>framerate</structfield> field was renamed +to <structfield>frameperiod</structfield>. The now obsolete +<structfield>colorstandard</structfield> information, originally +needed to distguish between variations of standards, were +removed.</para> + + <para>Struct <structname>v4l2_enumstd</structname> ceased to +be. &VIDIOC-ENUMSTD; now takes a pointer to a &v4l2-standard; +directly. The information which standards are supported by a +particular video input or output moved into &v4l2-input; and +&v4l2-output; fields named <structfield>std</structfield>, +respectively.</para> + </listitem> + + <listitem> + <para>The &v4l2-queryctrl; fields +<structfield>category</structfield> and +<structfield>group</structfield> did not catch on and/or were not +implemented as expected and therefore removed.</para> + </listitem> + + <listitem> + <para>The &VIDIOC-TRY-FMT; ioctl was added to negotiate data +formats as with &VIDIOC-S-FMT;, but without the overhead of +programming the hardware and regardless of I/O in progress.</para> + + <para>In &v4l2-format; the <structfield>fmt</structfield> +union was extended to contain &v4l2-window;. All image format +negotiations are now possible with <constant>VIDIOC_G_FMT</constant>, +<constant>VIDIOC_S_FMT</constant> and +<constant>VIDIOC_TRY_FMT</constant>; ioctl. The +<constant>VIDIOC_G_WIN</constant> and +<constant>VIDIOC_S_WIN</constant> ioctls to prepare for a video +overlay were removed. The <structfield>type</structfield> field +changed to type &v4l2-buf-type; and the buffer type names changed as +follows.<informaltable> + <tgroup cols="2"> + <thead> + <row> + <entry>Old defines</entry> + <entry>&v4l2-buf-type;</entry> + </row> + </thead> + <tbody valign="top"> + <row> + <entry><constant>V4L2_BUF_TYPE_CAPTURE</constant></entry> + <entry><constant>V4L2_BUF_TYPE_VIDEO_CAPTURE</constant></entry> + </row> + <row> + <entry><constant>V4L2_BUF_TYPE_CODECIN</constant></entry> + <entry>Omitted for now</entry> + </row> + <row> + <entry><constant>V4L2_BUF_TYPE_CODECOUT</constant></entry> + <entry>Omitted for now</entry> + </row> + <row> + <entry><constant>V4L2_BUF_TYPE_EFFECTSIN</constant></entry> + <entry>Omitted for now</entry> + </row> + <row> + <entry><constant>V4L2_BUF_TYPE_EFFECTSIN2</constant></entry> + <entry>Omitted for now</entry> + </row> + <row> + <entry><constant>V4L2_BUF_TYPE_EFFECTSOUT</constant></entry> + <entry>Omitted for now</entry> + </row> + <row> + <entry><constant>V4L2_BUF_TYPE_VIDEOOUT</constant></entry> + <entry><constant>V4L2_BUF_TYPE_VIDEO_OUTPUT</constant></entry> + </row> + <row> + <entry><constant>-</constant></entry> + <entry><constant>V4L2_BUF_TYPE_VIDEO_OVERLAY</constant></entry> + </row> + <row> + <entry><constant>-</constant></entry> + <entry><constant>V4L2_BUF_TYPE_VBI_CAPTURE</constant></entry> + </row> + <row> + <entry><constant>-</constant></entry> + <entry><constant>V4L2_BUF_TYPE_VBI_OUTPUT</constant></entry> + </row> + <row> + <entry><constant>-</constant></entry> + <entry><constant>V4L2_BUF_TYPE_SLICED_VBI_CAPTURE</constant></entry> + </row> + <row> + <entry><constant>-</constant></entry> + <entry><constant>V4L2_BUF_TYPE_SLICED_VBI_OUTPUT</constant></entry> + </row> + <row> + <entry><constant>V4L2_BUF_TYPE_PRIVATE_BASE</constant></entry> + <entry><constant>V4L2_BUF_TYPE_PRIVATE</constant></entry> + </row> + </tbody> + </tgroup> + </informaltable></para> + </listitem> + + <listitem> + <para>In &v4l2-fmtdesc; a &v4l2-buf-type; field named +<structfield>type</structfield> was added as in &v4l2-format;. The +<constant>VIDIOC_ENUM_FBUFFMT</constant> ioctl is no longer needed and +was removed. These calls can be replaced by &VIDIOC-ENUM-FMT; with +type <constant>V4L2_BUF_TYPE_VIDEO_OVERLAY</constant>.</para> + </listitem> + + <listitem> + <para>In &v4l2-pix-format; the +<structfield>depth</structfield> field was removed, assuming +applications which recognize the format by its four-character-code +already know the color depth, and others do not care about it. The +same rationale lead to the removal of the +<constant>V4L2_FMT_FLAG_COMPRESSED</constant> flag. The +<constant>V4L2_FMT_FLAG_SWCONVECOMPRESSED</constant> flag was removed +because drivers are not supposed to convert images in kernel space. A +user library of conversion functions should be provided instead. The +<constant>V4L2_FMT_FLAG_BYTESPERLINE</constant> flag was redundant. +Applications can set the <structfield>bytesperline</structfield> field +to zero to get a reasonable default. Since the remaining flags were +replaced as well, the <structfield>flags</structfield> field itself +was removed.</para> + <para>The interlace flags were replaced by a &v4l2-field; +value in a newly added <structfield>field</structfield> +field.<informaltable> + <tgroup cols="2"> + <thead> + <row> + <entry>Old flag</entry> + <entry>&v4l2-field;</entry> + </row> + </thead> + <tbody valign="top"> + <row> + <entry><constant>V4L2_FMT_FLAG_NOT_INTERLACED</constant></entry> + <entry>?</entry> + </row> + <row> + <entry><constant>V4L2_FMT_FLAG_INTERLACED</constant> += <constant>V4L2_FMT_FLAG_COMBINED</constant></entry> + <entry><constant>V4L2_FIELD_INTERLACED</constant></entry> + </row> + <row> + <entry><constant>V4L2_FMT_FLAG_TOPFIELD</constant> += <constant>V4L2_FMT_FLAG_ODDFIELD</constant></entry> + <entry><constant>V4L2_FIELD_TOP</constant></entry> + </row> + <row> + <entry><constant>V4L2_FMT_FLAG_BOTFIELD</constant> += <constant>V4L2_FMT_FLAG_EVENFIELD</constant></entry> + <entry><constant>V4L2_FIELD_BOTTOM</constant></entry> + </row> + <row> + <entry><constant>-</constant></entry> + <entry><constant>V4L2_FIELD_SEQ_TB</constant></entry> + </row> + <row> + <entry><constant>-</constant></entry> + <entry><constant>V4L2_FIELD_SEQ_BT</constant></entry> + </row> + <row> + <entry><constant>-</constant></entry> + <entry><constant>V4L2_FIELD_ALTERNATE</constant></entry> + </row> + </tbody> + </tgroup> + </informaltable></para> + + <para>The color space flags were replaced by a +&v4l2-colorspace; value in a newly added +<structfield>colorspace</structfield> field, where one of +<constant>V4L2_COLORSPACE_SMPTE170M</constant>, +<constant>V4L2_COLORSPACE_BT878</constant>, +<constant>V4L2_COLORSPACE_470_SYSTEM_M</constant> or +<constant>V4L2_COLORSPACE_470_SYSTEM_BG</constant> replaces +<constant>V4L2_FMT_CS_601YUV</constant>.</para> + </listitem> + + <listitem> + <para>In &v4l2-requestbuffers; the +<structfield>type</structfield> field was properly defined as +&v4l2-buf-type;. Buffer types changed as mentioned above. A new +<structfield>memory</structfield> field of type &v4l2-memory; was +added to distinguish between I/O methods using buffers allocated +by the driver or the application. See <xref linkend="io" /> for +details.</para> + </listitem> + + <listitem> + <para>In &v4l2-buffer; the <structfield>type</structfield> +field was properly defined as &v4l2-buf-type;. Buffer types changed as +mentioned above. A <structfield>field</structfield> field of type +&v4l2-field; was added to indicate if a buffer contains a top or +bottom field. The old field flags were removed. Since no unadjusted +system time clock was added to the kernel as planned, the +<structfield>timestamp</structfield> field changed back from type +stamp_t, an unsigned 64 bit integer expressing the sample time in +nanoseconds, to struct <structname>timeval</structname>. With the +addition of a second memory mapping method the +<structfield>offset</structfield> field moved into union +<structfield>m</structfield>, and a new +<structfield>memory</structfield> field of type &v4l2-memory; was +added to distinguish between I/O methods. See <xref linkend="io" /> +for details.</para> + + <para>The <constant>V4L2_BUF_REQ_CONTIG</constant> +flag was used by the V4L compatibility layer, after changes to this +code it was no longer needed. The +<constant>V4L2_BUF_ATTR_DEVICEMEM</constant> flag would indicate if +the buffer was indeed allocated in device memory rather than DMA-able +system memory. It was barely useful and so was removed.</para> + </listitem> + + <listitem> + <para>In &v4l2-framebuffer; the +<structfield>base[3]</structfield> array anticipating double- and +triple-buffering in off-screen video memory, however without defining +a synchronization mechanism, was replaced by a single pointer. The +<constant>V4L2_FBUF_CAP_SCALEUP</constant> and +<constant>V4L2_FBUF_CAP_SCALEDOWN</constant> flags were removed. +Applications can determine this capability more accurately using the +new cropping and scaling interface. The +<constant>V4L2_FBUF_CAP_CLIPPING</constant> flag was replaced by +<constant>V4L2_FBUF_CAP_LIST_CLIPPING</constant> and +<constant>V4L2_FBUF_CAP_BITMAP_CLIPPING</constant>.</para> + </listitem> + + <listitem> + <para>In &v4l2-clip; the <structfield>x</structfield>, +<structfield>y</structfield>, <structfield>width</structfield> and +<structfield>height</structfield> field moved into a +<structfield>c</structfield> substructure of type &v4l2-rect;. The +<structfield>x</structfield> and <structfield>y</structfield> fields +were renamed to <structfield>left</structfield> and +<structfield>top</structfield>, &ie; offsets to a context dependent +origin.</para> + </listitem> + + <listitem> + <para>In &v4l2-window; the <structfield>x</structfield>, +<structfield>y</structfield>, <structfield>width</structfield> and +<structfield>height</structfield> field moved into a +<structfield>w</structfield> substructure as above. A +<structfield>field</structfield> field of type %v4l2-field; was added +to distinguish between field and frame (interlaced) overlay.</para> + </listitem> + + <listitem> + <para>The digital zoom interface, including struct +<structname>v4l2_zoomcap</structname>, struct +<structname>v4l2_zoom</structname>, +<constant>V4L2_ZOOM_NONCAP</constant> and +<constant>V4L2_ZOOM_WHILESTREAMING</constant> was replaced by a new +cropping and scaling interface. The previously unused struct +<structname>v4l2_cropcap</structname> and +<structname>v4l2_crop</structname> where redefined for this purpose. +See <xref linkend="crop" /> for details.</para> + </listitem> + + <listitem> + <para>In &v4l2-vbi-format; the +<structfield>SAMPLE_FORMAT</structfield> field now contains a +four-character-code as used to identify video image formats and +<constant>V4L2_PIX_FMT_GREY</constant> replaces the +<constant>V4L2_VBI_SF_UBYTE</constant> define. The +<structfield>reserved</structfield> field was extended.</para> + </listitem> + + <listitem> + <para>In &v4l2-captureparm; the type of the +<structfield>timeperframe</structfield> field changed from unsigned +long to &v4l2-fract;. This allows the accurate expression of multiples +of the NTSC-M frame rate 30000 / 1001. A new field +<structfield>readbuffers</structfield> was added to control the driver +behaviour in read I/O mode.</para> + + <para>Similar changes were made to &v4l2-outputparm;.</para> + </listitem> + + <listitem> + <para>The struct <structname>v4l2_performance</structname> +and <constant>VIDIOC_G_PERF</constant> ioctl were dropped. Except when +using the <link linkend="rw">read/write I/O method</link>, which is +limited anyway, this information is already available to +applications.</para> + </listitem> + + <listitem> + <para>The example transformation from RGB to YCbCr color +space in the old V4L2 documentation was inaccurate, this has been +corrected in <xref linkend="pixfmt" />.<!-- 0.5670G should be +0.587, and 127/112 != 255/224 --></para> + </listitem> + </orderedlist> + </section> + + <section> + <title>V4L2 2003-06-19</title> + + <orderedlist> + <listitem> + <para>A new capability flag +<constant>V4L2_CAP_RADIO</constant> was added for radio devices. Prior +to this change radio devices would identify solely by having exactly one +tuner whose type field reads <constant>V4L2_TUNER_RADIO</constant>.</para> + </listitem> + + <listitem> + <para>An optional driver access priority mechanism was +added, see <xref linkend="app-pri" /> for details.</para> + </listitem> + + <listitem> + <para>The audio input and output interface was found to be +incomplete.</para> + <para>Previously the &VIDIOC-G-AUDIO; +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 +audio inputs, while &VIDIOC-G-AUDIO; now reports the current audio +input.</para> + <para>The same changes were made to &VIDIOC-G-AUDOUT; and +&VIDIOC-ENUMAUDOUT;.</para> + <para>Until further the "videodev" module will automatically +translate between the old and new ioctls, but drivers and applications +must be updated to successfully compile again.</para> + </listitem> + + <listitem> + <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" +kernel module will automatically translate to the new version, so drivers +must be recompiled, but not applications.</para> + </listitem> + + <listitem> + <para><xref linkend="overlay" /> incorrectly stated that +clipping rectangles define regions where the video can be seen. +Correct is that clipping rectangles define regions where +<emphasis>no</emphasis> video shall be displayed and so the graphics +surface can be seen.</para> + </listitem> + + <listitem> + <para>The &VIDIOC-S-PARM; and &VIDIOC-S-CTRL; ioctls were +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 +applications assuming a constant parameter need an update.</para> + </listitem> + </orderedlist> + </section> + + <section> + <title>V4L2 2003-11-05</title> + <orderedlist> + <listitem> + <para>In <xref linkend="pixfmt-rgb" /> the following pixel +formats were incorrectly transferred from Bill Dirks' V4L2 +specification. Descriptions below refer to bytes in memory, in +ascending address order.<informaltable> + <tgroup cols="3"> + <thead> + <row> + <entry>Symbol</entry> + <entry>In this document prior to revision +0.5</entry> + <entry>Corrected</entry> + </row> + </thead> + <tbody valign="top"> + <row> + <entry><constant>V4L2_PIX_FMT_RGB24</constant></entry> + <entry>B, G, R</entry> + <entry>R, G, B</entry> + </row> + <row> + <entry><constant>V4L2_PIX_FMT_BGR24</constant></entry> + <entry>R, G, B</entry> + <entry>B, G, R</entry> + </row> + <row> + <entry><constant>V4L2_PIX_FMT_RGB32</constant></entry> + <entry>B, G, R, X</entry> + <entry>R, G, B, X</entry> + </row> + <row> + <entry><constant>V4L2_PIX_FMT_BGR32</constant></entry> + <entry>R, G, B, X</entry> + <entry>B, G, R, X</entry> + </row> + </tbody> + </tgroup> + </informaltable> The +<constant>V4L2_PIX_FMT_BGR24</constant> example was always +correct.</para> + <para>In <xref linkend="v4l-image-properties" /> the mapping +of the V4L <constant>VIDEO_PALETTE_RGB24</constant> and +<constant>VIDEO_PALETTE_RGB32</constant> formats to V4L2 pixel formats +was accordingly corrected.</para> + </listitem> + + <listitem> + <para>Unrelated to the fixes above, drivers may still +interpret some V4L2 RGB pixel formats differently. These issues have +yet to be addressed, for details see <xref + linkend="pixfmt-rgb" />.</para> + </listitem> + </orderedlist> + </section> + + <section> + <title>V4L2 in Linux 2.6.6, 2004-05-09</title> + <orderedlist> + <listitem> + <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> + </listitem> + </orderedlist> + </section> + + <section> + <title>V4L2 in Linux 2.6.8</title> + <orderedlist> + <listitem> + <para>A new field <structfield>input</structfield> (former +<structfield>reserved[0]</structfield>) was added to the &v4l2-buffer; +structure. Purpose of this field is to alternate between video inputs +(⪚ cameras) in step with the video capturing process. This function +must be enabled with the new <constant>V4L2_BUF_FLAG_INPUT</constant> +flag. The <structfield>flags</structfield> field is no longer +read-only.</para> + </listitem> + </orderedlist> + </section> + + <section> + <title>V4L2 spec erratum 2004-08-01</title> + + <orderedlist> + <listitem> + <para>The return value of the +<xref linkend="func-open" /> function was incorrectly documented.</para> + </listitem> + + <listitem> + <para>Audio output ioctls end in -AUDOUT, not -AUDIOOUT.</para> + </listitem> + + <listitem> + <para>In the Current Audio Input example the +<constant>VIDIOC_G_AUDIO</constant> ioctl took the wrong +argument.</para> + </listitem> + + <listitem> + <para>The documentation of the &VIDIOC-QBUF; and +&VIDIOC-DQBUF; ioctls did not mention the &v4l2-buffer; +<structfield>memory</structfield> field. It was also missing from +examples. Also on the <constant>VIDIOC_DQBUF</constant> page the &EIO; +was not documented.</para> + </listitem> + </orderedlist> + </section> + + <section> + <title>V4L2 in Linux 2.6.14</title> + <orderedlist> + <listitem> + <para>A new sliced VBI interface was added. It is documented +in <xref linkend="sliced" /> and replaces the interface first +proposed in V4L2 specification 0.8.</para> + </listitem> + </orderedlist> + </section> + + <section> + <title>V4L2 in Linux 2.6.15</title> + <orderedlist> + <listitem> + <para>The &VIDIOC-LOG-STATUS; ioctl was added.</para> + </listitem> + + <listitem> + <para>New video standards +<constant>V4L2_STD_NTSC_443</constant>, +<constant>V4L2_STD_SECAM_LC</constant>, +<constant>V4L2_STD_SECAM_DK</constant> (a set of SECAM D, K and K1), +and <constant>V4L2_STD_ATSC</constant> (a set of +<constant>V4L2_STD_ATSC_8_VSB</constant> and +<constant>V4L2_STD_ATSC_16_VSB</constant>) were defined. Note the +<constant>V4L2_STD_525_60</constant> set now includes +<constant>V4L2_STD_NTSC_443</constant>. See also <xref + linkend="v4l2-std-id" />.</para> + </listitem> + + <listitem> + <para>The <constant>VIDIOC_G_COMP</constant> and +<constant>VIDIOC_S_COMP</constant> ioctl were renamed to +<constant>VIDIOC_G_MPEGCOMP</constant> and +<constant>VIDIOC_S_MPEGCOMP</constant> respectively. Their argument +was replaced by a struct +<structname>v4l2_mpeg_compression</structname> pointer. (The +<constant>VIDIOC_G_MPEGCOMP</constant> and +<constant>VIDIOC_S_MPEGCOMP</constant> ioctls where removed in Linux +2.6.25.)</para> + </listitem> + </orderedlist> + </section> + + <section> + <title>V4L2 spec erratum 2005-11-27</title> + <para>The capture example in <xref linkend="capture-example" /> +called the &VIDIOC-S-CROP; ioctl without checking if cropping is +supported. In the video standard selection example in +<xref linkend="standard" /> the &VIDIOC-S-STD; call used the wrong +argument type.</para> + </section> + + <section> + <title>V4L2 spec erratum 2006-01-10</title> + <orderedlist> + <listitem> + <para>The <constant>V4L2_IN_ST_COLOR_KILL</constant> flag in +&v4l2-input; not only indicates if the color killer is enabled, but +also if it is active. (The color killer disables color decoding when +it detects no color in the video signal to improve the image +quality.)</para> + </listitem> + + <listitem> + <para>&VIDIOC-S-PARM; is a write-read ioctl, not write-only as +stated on its reference page. The ioctl changed in 2003 as noted above.</para> + </listitem> + </orderedlist> + </section> + + <section> + <title>V4L2 spec erratum 2006-02-03</title> + <orderedlist> + <listitem> + <para>In &v4l2-captureparm; and &v4l2-outputparm; the +<structfield>timeperframe</structfield> field gives the time in +seconds, not microseconds.</para> + </listitem> + </orderedlist> + </section> + + <section> + <title>V4L2 spec erratum 2006-02-04</title> + <orderedlist> + <listitem> + <para>The <structfield>clips</structfield> field in +&v4l2-window; must point to an array of &v4l2-clip;, not a linked +list, because drivers ignore the struct +<structname>v4l2_clip</structname>.<structfield>next</structfield> +pointer.</para> + </listitem> + </orderedlist> + </section> + + <section> + <title>V4L2 in Linux 2.6.17</title> + <orderedlist> + <listitem> + <para>New video standard macros were added: +<constant>V4L2_STD_NTSC_M_KR</constant> (NTSC M South Korea), and the +sets <constant>V4L2_STD_MN</constant>, +<constant>V4L2_STD_B</constant>, <constant>V4L2_STD_GH</constant> and +<constant>V4L2_STD_DK</constant>. The +<constant>V4L2_STD_NTSC</constant> and +<constant>V4L2_STD_SECAM</constant> sets now include +<constant>V4L2_STD_NTSC_M_KR</constant> and +<constant>V4L2_STD_SECAM_LC</constant> respectively.</para> + </listitem> + + <listitem> + <para>A new <constant>V4L2_TUNER_MODE_LANG1_LANG2</constant> +was defined to record both languages of a bilingual program. The +use of <constant>V4L2_TUNER_MODE_STEREO</constant> for this purpose +is deprecated now. See the &VIDIOC-G-TUNER; section for +details.</para> + </listitem> + </orderedlist> + </section> + + <section> + <title>V4L2 spec erratum 2006-09-23 (Draft 0.15)</title> + <orderedlist> + <listitem> + <para>In various places +<constant>V4L2_BUF_TYPE_SLICED_VBI_CAPTURE</constant> and +<constant>V4L2_BUF_TYPE_SLICED_VBI_OUTPUT</constant> of the sliced VBI +interface were not mentioned along with other buffer types.</para> + </listitem> + + <listitem> + <para>In <xref linkend="vidioc-g-audio" /> it was clarified +that the &v4l2-audio; <structfield>mode</structfield> field is a flags +field.</para> + </listitem> + + <listitem> + <para><xref linkend="vidioc-querycap" /> did not mention the +sliced VBI and radio capability flags.</para> + </listitem> + + <listitem> + <para>In <xref linkend="vidioc-g-frequency" /> it was +clarified that applications must initialize the tuner +<structfield>type</structfield> field of &v4l2-frequency; before +calling &VIDIOC-S-FREQUENCY;.</para> + </listitem> + + <listitem> + <para>The <structfield>reserved</structfield> array +in &v4l2-requestbuffers; has 2 elements, not 32.</para> + </listitem> + + <listitem> + <para>In <xref linkend="output" /> and <xref + linkend="raw-vbi" /> the device file names +<filename>/dev/vout</filename> which never caught on were replaced +by <filename>/dev/video</filename>.</para> + </listitem> + + <listitem> + <para>With Linux 2.6.15 the possible range for VBI device minor +numbers was extended from 224-239 to 224-255. Accordingly device file names +<filename>/dev/vbi0</filename> to <filename>/dev/vbi31</filename> are +possible now.</para> + </listitem> + </orderedlist> + </section> + + <section> + <title>V4L2 in Linux 2.6.18</title> + <orderedlist> + <listitem> + <para>New ioctls &VIDIOC-G-EXT-CTRLS;, &VIDIOC-S-EXT-CTRLS; +and &VIDIOC-TRY-EXT-CTRLS; were added, a flag to skip unsupported +controls with &VIDIOC-QUERYCTRL;, new control types +<constant>V4L2_CTRL_TYPE_INTEGER64</constant> and +<constant>V4L2_CTRL_TYPE_CTRL_CLASS</constant> (<xref + linkend="v4l2-ctrl-type" />), and new control flags +<constant>V4L2_CTRL_FLAG_READ_ONLY</constant>, +<constant>V4L2_CTRL_FLAG_UPDATE</constant>, +<constant>V4L2_CTRL_FLAG_INACTIVE</constant> and +<constant>V4L2_CTRL_FLAG_SLIDER</constant> (<xref + linkend="control-flags" />). See <xref + linkend="extended-controls" /> for details.</para> + </listitem> + </orderedlist> + </section> + + <section> + <title>V4L2 in Linux 2.6.19</title> + <orderedlist> + <listitem> + <para>In &v4l2-sliced-vbi-cap; a buffer type field was added +replacing a reserved field. Note on architectures where the size of +enum types differs from int types the size of the structure changed. +The &VIDIOC-G-SLICED-VBI-CAP; ioctl was redefined from being read-only +to write-read. Applications must initialize the type field and clear +the reserved fields now. These changes may <emphasis>break the +compatibility</emphasis> with older drivers and applications.</para> + </listitem> + + <listitem> + <para>The ioctls &VIDIOC-ENUM-FRAMESIZES; and +&VIDIOC-ENUM-FRAMEINTERVALS; were added.</para> + </listitem> + + <listitem> + <para>A new pixel format <constant>V4L2_PIX_FMT_RGB444</constant> (<xref +linkend="rgb-formats" />) was added.</para> + </listitem> + </orderedlist> + </section> + + <section> + <title>V4L2 spec erratum 2006-10-12 (Draft 0.17)</title> + <orderedlist> + <listitem> + <para><constant>V4L2_PIX_FMT_HM12</constant> (<xref +linkend="reserved-formats" />) is a YUV 4:2:0, not 4:2:2 format.</para> + </listitem> + </orderedlist> + </section> + + <section> + <title>V4L2 in Linux 2.6.21</title> + <orderedlist> + <listitem> + <para>The <filename>videodev2.h</filename> header file is +now dual licensed under GNU General Public License version two or +later, and under a 3-clause BSD-style license.</para> + </listitem> + </orderedlist> + </section> + + <section> + <title>V4L2 in Linux 2.6.22</title> + <orderedlist> + <listitem> + <para>Two new field orders + <constant>V4L2_FIELD_INTERLACED_TB</constant> and + <constant>V4L2_FIELD_INTERLACED_BT</constant> were + added. See <xref linkend="v4l2-field" /> for details.</para> + </listitem> + + <listitem> + <para>Three new clipping/blending methods with a global or +straight or inverted local alpha value were added to the video overlay +interface. See the description of the &VIDIOC-G-FBUF; and +&VIDIOC-S-FBUF; ioctls for details.</para> + <para>A new <structfield>global_alpha</structfield> field +was added to <link +linkend="v4l2-window"><structname>v4l2_window</structname></link>, +extending the structure. This may <emphasis>break +compatibility</emphasis> with applications using a struct +<structname>v4l2_window</structname> directly. However the <link +linkend="vidioc-g-fmt">VIDIOC_G/S/TRY_FMT</link> ioctls, which take a +pointer to a <link linkend="v4l2-format">v4l2_format</link> parent +structure with padding bytes at the end, are not affected.</para> + </listitem> + + <listitem> + <para>The format of the <structfield>chromakey</structfield> +field in &v4l2-window; changed from "host order RGB32" to a pixel +value in the same format as the framebuffer. This may <emphasis>break +compatibility</emphasis> with existing applications. Drivers +supporting the "host order RGB32" format are not known.</para> + </listitem> + + </orderedlist> + </section> + + <section> + <title>V4L2 in Linux 2.6.24</title> + <orderedlist> + <listitem> + <para>The pixel formats +<constant>V4L2_PIX_FMT_PAL8</constant>, +<constant>V4L2_PIX_FMT_YUV444</constant>, +<constant>V4L2_PIX_FMT_YUV555</constant>, +<constant>V4L2_PIX_FMT_YUV565</constant> and +<constant>V4L2_PIX_FMT_YUV32</constant> were added.</para> + </listitem> + </orderedlist> + </section> + + <section> + <title>V4L2 in Linux 2.6.25</title> + <orderedlist> + <listitem> + <para>The pixel formats <link linkend="V4L2-PIX-FMT-Y16"> +<constant>V4L2_PIX_FMT_Y16</constant></link> and <link +linkend="V4L2-PIX-FMT-SBGGR16"> +<constant>V4L2_PIX_FMT_SBGGR16</constant></link> were added.</para> + </listitem> + <listitem> + <para>New <link linkend="control">controls</link> +<constant>V4L2_CID_POWER_LINE_FREQUENCY</constant>, +<constant>V4L2_CID_HUE_AUTO</constant>, +<constant>V4L2_CID_WHITE_BALANCE_TEMPERATURE</constant>, +<constant>V4L2_CID_SHARPNESS</constant> and +<constant>V4L2_CID_BACKLIGHT_COMPENSATION</constant> were added. The +controls <constant>V4L2_CID_BLACK_LEVEL</constant>, +<constant>V4L2_CID_WHITENESS</constant>, +<constant>V4L2_CID_HCENTER</constant> and +<constant>V4L2_CID_VCENTER</constant> were deprecated. +</para> + </listitem> + <listitem> + <para>A <link linkend="camera-controls">Camera controls +class</link> was added, with the new controls +<constant>V4L2_CID_EXPOSURE_AUTO</constant>, +<constant>V4L2_CID_EXPOSURE_ABSOLUTE</constant>, +<constant>V4L2_CID_EXPOSURE_AUTO_PRIORITY</constant>, +<constant>V4L2_CID_PAN_RELATIVE</constant>, +<constant>V4L2_CID_TILT_RELATIVE</constant>, +<constant>V4L2_CID_PAN_RESET</constant>, +<constant>V4L2_CID_TILT_RESET</constant>, +<constant>V4L2_CID_PAN_ABSOLUTE</constant>, +<constant>V4L2_CID_TILT_ABSOLUTE</constant>, +<constant>V4L2_CID_FOCUS_ABSOLUTE</constant>, +<constant>V4L2_CID_FOCUS_RELATIVE</constant> and +<constant>V4L2_CID_FOCUS_AUTO</constant>.</para> + </listitem> + <listitem> + <para>The <constant>VIDIOC_G_MPEGCOMP</constant> and +<constant>VIDIOC_S_MPEGCOMP</constant> ioctls, which were superseded +by the <link linkend="extended-controls">extended controls</link> +interface in Linux 2.6.18, where finally removed from the +<filename>videodev2.h</filename> header file.</para> + </listitem> + </orderedlist> + </section> + + <section> + <title>V4L2 in Linux 2.6.26</title> + <orderedlist> + <listitem> + <para>The pixel formats +<constant>V4L2_PIX_FMT_Y16</constant> and +<constant>V4L2_PIX_FMT_SBGGR16</constant> were added.</para> + </listitem> + <listitem> + <para>Added user controls +<constant>V4L2_CID_CHROMA_AGC</constant> and +<constant>V4L2_CID_COLOR_KILLER</constant>.</para> + </listitem> + </orderedlist> + </section> + + <section> + <title>V4L2 in Linux 2.6.27</title> + <orderedlist> + <listitem> + <para>The &VIDIOC-S-HW-FREQ-SEEK; ioctl and the +<constant>V4L2_CAP_HW_FREQ_SEEK</constant> capability were added.</para> + </listitem> + <listitem> + <para>The pixel formats +<constant>V4L2_PIX_FMT_YVYU</constant>, +<constant>V4L2_PIX_FMT_PCA501</constant>, +<constant>V4L2_PIX_FMT_PCA505</constant>, +<constant>V4L2_PIX_FMT_PCA508</constant>, +<constant>V4L2_PIX_FMT_PCA561</constant>, +<constant>V4L2_PIX_FMT_SGBRG8</constant>, +<constant>V4L2_PIX_FMT_PAC207</constant> and +<constant>V4L2_PIX_FMT_PJPG</constant> were added.</para> + </listitem> + </orderedlist> + </section> + + <section> + <title>V4L2 in Linux 2.6.28</title> + <orderedlist> + <listitem> + <para>Added <constant>V4L2_MPEG_AUDIO_ENCODING_AAC</constant> and +<constant>V4L2_MPEG_AUDIO_ENCODING_AC3</constant> MPEG audio encodings.</para> + </listitem> + <listitem> + <para>Added <constant>V4L2_MPEG_VIDEO_ENCODING_MPEG_4_AVC</constant> MPEG +video encoding.</para> + </listitem> + <listitem> + <para>The pixel formats +<constant>V4L2_PIX_FMT_SGRBG10</constant> and +<constant>V4L2_PIX_FMT_SGRBG10DPCM8</constant> were added.</para> + </listitem> + </orderedlist> + </section> + + <section> + <title>V4L2 in Linux 2.6.29</title> + <orderedlist> + <listitem> + <para>The <constant>VIDIOC_G_CHIP_IDENT</constant> ioctl was renamed +to <constant>VIDIOC_G_CHIP_IDENT_OLD</constant> and &VIDIOC-DBG-G-CHIP-IDENT; +was introduced in its place. The old struct <structname>v4l2_chip_ident</structname> +was renamed to <structname id="v4l2-chip-ident-old">v4l2_chip_ident_old</structname>.</para> + </listitem> + <listitem> + <para>The pixel formats +<constant>V4L2_PIX_FMT_VYUY</constant>, +<constant>V4L2_PIX_FMT_NV16</constant> and +<constant>V4L2_PIX_FMT_NV61</constant> were added.</para> + </listitem> + <listitem> + <para>Added camera controls +<constant>V4L2_CID_ZOOM_ABSOLUTE</constant>, +<constant>V4L2_CID_ZOOM_RELATIVE</constant>, +<constant>V4L2_CID_ZOOM_CONTINUOUS</constant> and +<constant>V4L2_CID_PRIVACY</constant>.</para> + </listitem> + </orderedlist> + </section> + <section> + <title>V4L2 in Linux 2.6.30</title> + <orderedlist> + <listitem> + <para>New control flag <constant>V4L2_CTRL_FLAG_WRITE_ONLY</constant> was added.</para> + </listitem> + <listitem> + <para>New control <constant>V4L2_CID_COLORFX</constant> was added.</para> + </listitem> + </orderedlist> + </section> + <section> + <title>V4L2 in Linux 2.6.32</title> + <orderedlist> + <listitem> + <para>In order to be easier to compare a V4L2 API and a kernel +version, now V4L2 API is numbered using the Linux Kernel version numeration.</para> + </listitem> + <listitem> + <para>Finalized the RDS capture API. See <xref linkend="rds" /> for +more information.</para> + </listitem> + <listitem> + <para>Added new capabilities for modulators and RDS encoders.</para> + </listitem> + <listitem> + <para>Add description for libv4l API.</para> + </listitem> + <listitem> + <para>Added support for string controls via new type <constant>V4L2_CTRL_TYPE_STRING</constant>.</para> + </listitem> + <listitem> + <para>Added <constant>V4L2_CID_BAND_STOP_FILTER</constant> documentation.</para> + </listitem> + <listitem> + <para>Added FM Modulator (FM TX) Extended Control Class: <constant>V4L2_CTRL_CLASS_FM_TX</constant> and their Control IDs.</para> + </listitem> + <listitem> + <para>Added Remote Controller chapter, describing the default Remote Controller mapping for media devices.</para> + </listitem> + </orderedlist> + </section> + <section> + <title>V4L2 in Linux 2.6.33</title> + <orderedlist> + <listitem> + <para>Added support for Digital Video timings in order to support HDTV receivers and transmitters.</para> + </listitem> + </orderedlist> + </section> + </section> + + <section id="other"> + <title>Relation of V4L2 to other Linux multimedia APIs</title> + + <section id="xvideo"> + <title>X Video Extension</title> + + <para>The X Video Extension (abbreviated XVideo or just Xv) is +an extension of the X Window system, implemented for example by the +XFree86 project. Its scope is similar to V4L2, an API to video capture +and output devices for X clients. Xv allows applications to display +live video in a window, send window contents to a TV output, and +capture or output still images in XPixmaps<footnote> + <para>This is not implemented in XFree86.</para> + </footnote>. With their implementation XFree86 makes the +extension available across many operating systems and +architectures.</para> + + <para>Because the driver is embedded into the X server Xv has a +number of advantages over the V4L2 <link linkend="overlay">video +overlay interface</link>. The driver can easily determine the overlay +target, &ie; visible graphics memory or off-screen buffers for a +destructive overlay. It can program the RAMDAC for a non-destructive +overlay, scaling or color-keying, or the clipping functions of the +video capture hardware, always in sync with drawing operations or +windows moving or changing their stacking order.</para> + + <para>To combine the advantages of Xv and V4L a special Xv +driver exists in XFree86 and XOrg, just programming any overlay capable +Video4Linux device it finds. To enable it +<filename>/etc/X11/XF86Config</filename> must contain these lines:</para> + <para><screen> +Section "Module" + Load "v4l" +EndSection</screen></para> + + <para>As of XFree86 4.2 this driver still supports only V4L +ioctls, however it should work just fine with all V4L2 devices through +the V4L2 backward-compatibility layer. Since V4L2 permits multiple +opens it is possible (if supported by the V4L2 driver) to capture +video while an X client requested video overlay. Restrictions of +simultaneous capturing and overlay are discussed in <xref + linkend="overlay" /> apply.</para> + + <para>Only marginally related to V4L2, XFree86 extended Xv to +support hardware YUV to RGB conversion and scaling for faster video +playback, and added an interface to MPEG-2 decoding hardware. This API +is useful to display images captured with V4L2 devices.</para> + </section> + + <section> + <title>Digital Video</title> + + <para>V4L2 does not support digital terrestrial, cable or +satellite broadcast. A separate project aiming at digital receivers +exists. You can find its homepage at <ulink +url="http://linuxtv.org">http://linuxtv.org</ulink>. The Linux DVB API +has no connection to the V4L2 API except that drivers for hybrid +hardware may support both.</para> + </section> + + <section> + <title>Audio Interfaces</title> + + <para>[to do - OSS/ALSA]</para> + </section> + </section> + + <section id="experimental"> + <title>Experimental API Elements</title> + + <para>The following V4L2 API elements are currently experimental +and may change in the future.</para> + + <itemizedlist> + <listitem> + <para>Video Output Overlay (OSD) Interface, <xref + linkend="osd" />.</para> + </listitem> + <listitem> + <para><constant>V4L2_BUF_TYPE_VIDEO_OUTPUT_OVERLAY</constant>, + &v4l2-buf-type;, <xref linkend="v4l2-buf-type" />.</para> + </listitem> + <listitem> + <para><constant>V4L2_CAP_VIDEO_OUTPUT_OVERLAY</constant>, +&VIDIOC-QUERYCAP; ioctl, <xref linkend="device-capabilities" />.</para> + </listitem> + <listitem> + <para>&VIDIOC-ENUM-FRAMESIZES; and +&VIDIOC-ENUM-FRAMEINTERVALS; ioctls.</para> + </listitem> + <listitem> + <para>&VIDIOC-G-ENC-INDEX; ioctl.</para> + </listitem> + <listitem> + <para>&VIDIOC-ENCODER-CMD; and &VIDIOC-TRY-ENCODER-CMD; +ioctls.</para> + </listitem> + <listitem> + <para>&VIDIOC-DBG-G-REGISTER; and &VIDIOC-DBG-S-REGISTER; +ioctls.</para> + </listitem> + <listitem> + <para>&VIDIOC-DBG-G-CHIP-IDENT; ioctl.</para> + </listitem> + </itemizedlist> + </section> + + <section id="obsolete"> + <title>Obsolete API Elements</title> + + <para>The following V4L2 API elements were superseded by new +interfaces and should not be implemented in new drivers.</para> + + <itemizedlist> + <listitem> + <para><constant>VIDIOC_G_MPEGCOMP</constant> and +<constant>VIDIOC_S_MPEGCOMP</constant> ioctls. Use Extended Controls, +<xref linkend="extended-controls" />.</para> + </listitem> + </itemizedlist> + </section> + + <!-- +Local Variables: +mode: sgml +sgml-parent-document: "v4l2.sgml" +indent-tabs-mode: nil +End: + --> diff --git a/Documentation/DocBook/v4l/controls.xml b/Documentation/DocBook/v4l/controls.xml new file mode 100644 index 000000000000..f46450610412 --- /dev/null +++ b/Documentation/DocBook/v4l/controls.xml @@ -0,0 +1,2067 @@ + <section id="control"> + <title>User Controls</title> + + <para>Devices typically have a number of user-settable controls +such as brightness, saturation and so on, which would be presented to +the user on a graphical user interface. But, different devices +will have different controls available, and furthermore, the range of +possible values, and the default value will vary from device to +device. The control ioctls provide the information and a mechanism to +create a nice user interface for these controls that will work +correctly with any device.</para> + + <para>All controls are accessed using an ID value. V4L2 defines +several IDs for specific purposes. Drivers can also implement their +own custom controls using <constant>V4L2_CID_PRIVATE_BASE</constant> +and higher values. The pre-defined control IDs have the prefix +<constant>V4L2_CID_</constant>, and are listed in <xref +linkend="control-id" />. The ID is used when querying the attributes of +a control, and when getting or setting the current value.</para> + + <para>Generally applications should present controls to the user +without assumptions about their purpose. Each control comes with a +name string the user is supposed to understand. When the purpose is +non-intuitive the driver writer should provide a user manual, a user +interface plug-in or a driver specific panel application. Predefined +IDs were introduced to change a few controls programmatically, for +example to mute a device during a channel switch.</para> + + <para>Drivers may enumerate different controls after switching +the current video input or output, tuner or modulator, or audio input +or output. Different in the sense of other bounds, another default and +current value, step size or other menu items. A control with a certain +<emphasis>custom</emphasis> ID can also change name and +type.<footnote> + <para>It will be more convenient for applications if drivers +make use of the <constant>V4L2_CTRL_FLAG_DISABLED</constant> flag, but +that was never required.</para> + </footnote> Control values are stored globally, they do not +change when switching except to stay within the reported bounds. They +also do not change ⪚ when the device is opened or closed, when the +tuner radio frequency is changed or generally never without +application request. Since V4L2 specifies no event mechanism, panel +applications intended to cooperate with other panel applications (be +they built into a larger application, as a TV viewer) may need to +regularly poll control values to update their user +interface.<footnote> + <para>Applications could call an ioctl to request events. +After another process called &VIDIOC-S-CTRL; or another ioctl changing +shared properties the &func-select; function would indicate +readability until any ioctl (querying the properties) is +called.</para> + </footnote></para> + + <table pgwide="1" frame="none" id="control-id"> + <title>Control IDs</title> + <tgroup cols="3"> + &cs-def; + <thead> + <row> + <entry>ID</entry> + <entry>Type</entry> + <entry>Description</entry> + </row> + </thead> + <tbody valign="top"> + <row> + <entry><constant>V4L2_CID_BASE</constant></entry> + <entry></entry> + <entry>First predefined ID, equal to +<constant>V4L2_CID_BRIGHTNESS</constant>.</entry> + </row> + <row> + <entry><constant>V4L2_CID_USER_BASE</constant></entry> + <entry></entry> + <entry>Synonym of <constant>V4L2_CID_BASE</constant>.</entry> + </row> + <row> + <entry><constant>V4L2_CID_BRIGHTNESS</constant></entry> + <entry>integer</entry> + <entry>Picture brightness, or more precisely, the black +level.</entry> + </row> + <row> + <entry><constant>V4L2_CID_CONTRAST</constant></entry> + <entry>integer</entry> + <entry>Picture contrast or luma gain.</entry> + </row> + <row> + <entry><constant>V4L2_CID_SATURATION</constant></entry> + <entry>integer</entry> + <entry>Picture color saturation or chroma gain.</entry> + </row> + <row> + <entry><constant>V4L2_CID_HUE</constant></entry> + <entry>integer</entry> + <entry>Hue or color balance.</entry> + </row> + <row> + <entry><constant>V4L2_CID_AUDIO_VOLUME</constant></entry> + <entry>integer</entry> + <entry>Overall audio volume. Note some drivers also +provide an OSS or ALSA mixer interface.</entry> + </row> + <row> + <entry><constant>V4L2_CID_AUDIO_BALANCE</constant></entry> + <entry>integer</entry> + <entry>Audio stereo balance. Minimum corresponds to all +the way left, maximum to right.</entry> + </row> + <row> + <entry><constant>V4L2_CID_AUDIO_BASS</constant></entry> + <entry>integer</entry> + <entry>Audio bass adjustment.</entry> + </row> + <row> + <entry><constant>V4L2_CID_AUDIO_TREBLE</constant></entry> + <entry>integer</entry> + <entry>Audio treble adjustment.</entry> + </row> + <row> + <entry><constant>V4L2_CID_AUDIO_MUTE</constant></entry> + <entry>boolean</entry> + <entry>Mute audio, &ie; set the volume to zero, however +without affecting <constant>V4L2_CID_AUDIO_VOLUME</constant>. Like +ALSA drivers, V4L2 drivers must mute at load time to avoid excessive +noise. Actually the entire device should be reset to a low power +consumption state.</entry> + </row> + <row> + <entry><constant>V4L2_CID_AUDIO_LOUDNESS</constant></entry> + <entry>boolean</entry> + <entry>Loudness mode (bass boost).</entry> + </row> + <row> + <entry><constant>V4L2_CID_BLACK_LEVEL</constant></entry> + <entry>integer</entry> + <entry>Another name for brightness (not a synonym of +<constant>V4L2_CID_BRIGHTNESS</constant>). This control is deprecated +and should not be used in new drivers and applications.</entry> + </row> + <row> + <entry><constant>V4L2_CID_AUTO_WHITE_BALANCE</constant></entry> + <entry>boolean</entry> + <entry>Automatic white balance (cameras).</entry> + </row> + <row> + <entry><constant>V4L2_CID_DO_WHITE_BALANCE</constant></entry> + <entry>button</entry> + <entry>This is an action control. When set (the value is +ignored), the device will do a white balance and then hold the current +setting. Contrast this with the boolean +<constant>V4L2_CID_AUTO_WHITE_BALANCE</constant>, which, when +activated, keeps adjusting the white balance.</entry> + </row> + <row> + <entry><constant>V4L2_CID_RED_BALANCE</constant></entry> + <entry>integer</entry> + <entry>Red chroma balance.</entry> + </row> + <row> + <entry><constant>V4L2_CID_BLUE_BALANCE</constant></entry> + <entry>integer</entry> + <entry>Blue chroma balance.</entry> + </row> + <row> + <entry><constant>V4L2_CID_GAMMA</constant></entry> + <entry>integer</entry> + <entry>Gamma adjust.</entry> + </row> + <row> + <entry><constant>V4L2_CID_WHITENESS</constant></entry> + <entry>integer</entry> + <entry>Whiteness for grey-scale devices. This is a synonym +for <constant>V4L2_CID_GAMMA</constant>. This control is deprecated +and should not be used in new drivers and applications.</entry> + </row> + <row> + <entry><constant>V4L2_CID_EXPOSURE</constant></entry> + <entry>integer</entry> + <entry>Exposure (cameras). [Unit?]</entry> + </row> + <row> + <entry><constant>V4L2_CID_AUTOGAIN</constant></entry> + <entry>boolean</entry> + <entry>Automatic gain/exposure control.</entry> + </row> + <row> + <entry><constant>V4L2_CID_GAIN</constant></entry> + <entry>integer</entry> + <entry>Gain control.</entry> + </row> + <row> + <entry><constant>V4L2_CID_HFLIP</constant></entry> + <entry>boolean</entry> + <entry>Mirror the picture horizontally.</entry> + </row> + <row> + <entry><constant>V4L2_CID_VFLIP</constant></entry> + <entry>boolean</entry> + <entry>Mirror the picture vertically.</entry> + </row> + <row> + <entry><constant>V4L2_CID_HCENTER_DEPRECATED</constant> (formerly <constant>V4L2_CID_HCENTER</constant>)</entry> + <entry>integer</entry> + <entry>Horizontal image centering. This control is +deprecated. New drivers and applications should use the <link +linkend="camera-controls">Camera class controls</link> +<constant>V4L2_CID_PAN_ABSOLUTE</constant>, +<constant>V4L2_CID_PAN_RELATIVE</constant> and +<constant>V4L2_CID_PAN_RESET</constant> instead.</entry> + </row> + <row> + <entry><constant>V4L2_CID_VCENTER_DEPRECATED</constant> + (formerly <constant>V4L2_CID_VCENTER</constant>)</entry> + <entry>integer</entry> + <entry>Vertical image centering. Centering is intended to +<emphasis>physically</emphasis> adjust cameras. For image cropping see +<xref linkend="crop" />, for clipping <xref linkend="overlay" />. This +control is deprecated. New drivers and applications should use the +<link linkend="camera-controls">Camera class controls</link> +<constant>V4L2_CID_TILT_ABSOLUTE</constant>, +<constant>V4L2_CID_TILT_RELATIVE</constant> and +<constant>V4L2_CID_TILT_RESET</constant> instead.</entry> + </row> + <row id="v4l2-power-line-frequency"> + <entry><constant>V4L2_CID_POWER_LINE_FREQUENCY</constant></entry> + <entry>enum</entry> + <entry>Enables a power line frequency filter to avoid +flicker. Possible values for <constant>enum v4l2_power_line_frequency</constant> are: +<constant>V4L2_CID_POWER_LINE_FREQUENCY_DISABLED</constant> (0), +<constant>V4L2_CID_POWER_LINE_FREQUENCY_50HZ</constant> (1) and +<constant>V4L2_CID_POWER_LINE_FREQUENCY_60HZ</constant> (2).</entry> + </row> + <row> + <entry><constant>V4L2_CID_HUE_AUTO</constant></entry> + <entry>boolean</entry> + <entry>Enables automatic hue control by the device. The +effect of setting <constant>V4L2_CID_HUE</constant> while automatic +hue control is enabled is undefined, drivers should ignore such +request.</entry> + </row> + <row> + <entry><constant>V4L2_CID_WHITE_BALANCE_TEMPERATURE</constant></entry> + <entry>integer</entry> + <entry>This control specifies the white balance settings +as a color temperature in Kelvin. A driver should have a minimum of +2800 (incandescent) to 6500 (daylight). For more information about +color temperature see <ulink +url="http://en.wikipedia.org/wiki/Color_temperature">Wikipedia</ulink>.</entry> + </row> + <row> + <entry><constant>V4L2_CID_SHARPNESS</constant></entry> + <entry>integer</entry> + <entry>Adjusts the sharpness filters in a camera. The +minimum value disables the filters, higher values give a sharper +picture.</entry> + </row> + <row> + <entry><constant>V4L2_CID_BACKLIGHT_COMPENSATION</constant></entry> + <entry>integer</entry> + <entry>Adjusts the backlight compensation in a camera. The +minimum value disables backlight compensation.</entry> + </row> + <row> + <entry><constant>V4L2_CID_CHROMA_AGC</constant></entry> + <entry>boolean</entry> + <entry>Chroma automatic gain control.</entry> + </row> + <row> + <entry><constant>V4L2_CID_COLOR_KILLER</constant></entry> + <entry>boolean</entry> + <entry>Enable the color killer (&ie; force a black & white image in case of a weak video signal).</entry> + </row> + <row id="v4l2-colorfx"> + <entry><constant>V4L2_CID_COLORFX</constant></entry> + <entry>enum</entry> + <entry>Selects a color effect. Possible values for +<constant>enum v4l2_colorfx</constant> are: +<constant>V4L2_COLORFX_NONE</constant> (0), +<constant>V4L2_COLORFX_BW</constant> (1) and +<constant>V4L2_COLORFX_SEPIA</constant> (2).</entry> + </row> + <row> + <entry><constant>V4L2_CID_ROTATE</constant></entry> + <entry>integer</entry> + <entry>Rotates the image by specified angle. Common angles are 90, + 270 and 180. Rotating the image to 90 and 270 will reverse the height + and width of the display window. It is necessary to set the new height and + width of the picture using the &VIDIOC-S-FMT; ioctl according to + the rotation angle selected.</entry> + </row> + <row> + <entry><constant>V4L2_CID_BG_COLOR</constant></entry> + <entry>integer</entry> + <entry>Sets the background color on the current output device. + Background color needs to be specified in the RGB24 format. The + supplied 32 bit value is interpreted as bits 0-7 Red color information, + bits 8-15 Green color information, bits 16-23 Blue color + information and bits 24-31 must be zero.</entry> + </row> + <row> + <entry><constant>V4L2_CID_LASTP1</constant></entry> + <entry></entry> + <entry>End of the predefined control IDs (currently +<constant>V4L2_CID_BG_COLOR</constant> + 1).</entry> + </row> + <row> + <entry><constant>V4L2_CID_PRIVATE_BASE</constant></entry> + <entry></entry> + <entry>ID of the first custom (driver specific) control. +Applications depending on particular custom controls should check the +driver name and version, see <xref linkend="querycap" />.</entry> + </row> + </tbody> + </tgroup> + </table> + + <para>Applications can enumerate the available controls with the +&VIDIOC-QUERYCTRL; and &VIDIOC-QUERYMENU; ioctls, get and set a +control value with the &VIDIOC-G-CTRL; and &VIDIOC-S-CTRL; ioctls. +Drivers must implement <constant>VIDIOC_QUERYCTRL</constant>, +<constant>VIDIOC_G_CTRL</constant> and +<constant>VIDIOC_S_CTRL</constant> when the device has one or more +controls, <constant>VIDIOC_QUERYMENU</constant> when it has one or +more menu type controls.</para> + + <example> + <title>Enumerating all controls</title> + + <programlisting> +&v4l2-queryctrl; queryctrl; +&v4l2-querymenu; querymenu; + +static void +enumerate_menu (void) +{ + printf (" Menu items:\n"); + + memset (&querymenu, 0, sizeof (querymenu)); + querymenu.id = queryctrl.id; + + for (querymenu.index = queryctrl.minimum; + querymenu.index <= queryctrl.maximum; + querymenu.index++) { + if (0 == ioctl (fd, &VIDIOC-QUERYMENU;, &querymenu)) { + printf (" %s\n", querymenu.name); + } else { + perror ("VIDIOC_QUERYMENU"); + exit (EXIT_FAILURE); + } + } +} + +memset (&queryctrl, 0, sizeof (queryctrl)); + +for (queryctrl.id = V4L2_CID_BASE; + queryctrl.id < V4L2_CID_LASTP1; + queryctrl.id++) { + if (0 == ioctl (fd, &VIDIOC-QUERYCTRL;, &queryctrl)) { + if (queryctrl.flags & V4L2_CTRL_FLAG_DISABLED) + continue; + + printf ("Control %s\n", queryctrl.name); + + if (queryctrl.type == V4L2_CTRL_TYPE_MENU) + enumerate_menu (); + } else { + if (errno == EINVAL) + continue; + + perror ("VIDIOC_QUERYCTRL"); + exit (EXIT_FAILURE); + } +} + +for (queryctrl.id = V4L2_CID_PRIVATE_BASE;; + queryctrl.id++) { + if (0 == ioctl (fd, &VIDIOC-QUERYCTRL;, &queryctrl)) { + if (queryctrl.flags & V4L2_CTRL_FLAG_DISABLED) + continue; + + printf ("Control %s\n", queryctrl.name); + + if (queryctrl.type == V4L2_CTRL_TYPE_MENU) + enumerate_menu (); + } else { + if (errno == EINVAL) + break; + + perror ("VIDIOC_QUERYCTRL"); + exit (EXIT_FAILURE); + } +} +</programlisting> + </example> + + <example> + <title>Changing controls</title> + + <programlisting> +&v4l2-queryctrl; queryctrl; +&v4l2-control; control; + +memset (&queryctrl, 0, sizeof (queryctrl)); +queryctrl.id = V4L2_CID_BRIGHTNESS; + +if (-1 == ioctl (fd, &VIDIOC-QUERYCTRL;, &queryctrl)) { + if (errno != EINVAL) { + perror ("VIDIOC_QUERYCTRL"); + exit (EXIT_FAILURE); + } else { + printf ("V4L2_CID_BRIGHTNESS is not supported\n"); + } +} else if (queryctrl.flags & V4L2_CTRL_FLAG_DISABLED) { + printf ("V4L2_CID_BRIGHTNESS is not supported\n"); +} else { + memset (&control, 0, sizeof (control)); + control.id = V4L2_CID_BRIGHTNESS; + control.value = queryctrl.default_value; + + if (-1 == ioctl (fd, &VIDIOC-S-CTRL;, &control)) { + perror ("VIDIOC_S_CTRL"); + exit (EXIT_FAILURE); + } +} + +memset (&control, 0, sizeof (control)); +control.id = V4L2_CID_CONTRAST; + +if (0 == ioctl (fd, &VIDIOC-G-CTRL;, &control)) { + control.value += 1; + + /* The driver may clamp the value or return ERANGE, ignored here */ + + if (-1 == ioctl (fd, &VIDIOC-S-CTRL;, &control) + && errno != ERANGE) { + perror ("VIDIOC_S_CTRL"); + exit (EXIT_FAILURE); + } +/* Ignore if V4L2_CID_CONTRAST is unsupported */ +} else if (errno != EINVAL) { + perror ("VIDIOC_G_CTRL"); + exit (EXIT_FAILURE); +} + +control.id = V4L2_CID_AUDIO_MUTE; +control.value = TRUE; /* silence */ + +/* Errors ignored */ +ioctl (fd, VIDIOC_S_CTRL, &control); +</programlisting> + </example> + </section> + + <section id="extended-controls"> + <title>Extended Controls</title> + + <section> + <title>Introduction</title> + + <para>The control mechanism as originally designed was meant +to be used for user settings (brightness, saturation, etc). However, +it turned out to be a very useful model for implementing more +complicated driver APIs where each driver implements only a subset of +a larger API.</para> + + <para>The MPEG encoding API was the driving force behind +designing and implementing this extended control mechanism: the MPEG +standard is quite large and the currently supported hardware MPEG +encoders each only implement a subset of this standard. Further more, +many parameters relating to how the video is encoded into an MPEG +stream are specific to the MPEG encoding chip since the MPEG standard +only defines the format of the resulting MPEG stream, not how the +video is actually encoded into that format.</para> + + <para>Unfortunately, the original control API lacked some +features needed for these new uses and so it was extended into the +(not terribly originally named) extended control API.</para> + + <para>Even though the MPEG encoding API was the first effort +to use the Extended Control API, nowadays there are also other classes +of Extended Controls, such as Camera Controls and FM Transmitter Controls. +The Extended Controls API as well as all Extended Controls classes are +described in the following text.</para> + </section> + + <section> + <title>The Extended Control API</title> + + <para>Three new ioctls are available: &VIDIOC-G-EXT-CTRLS;, +&VIDIOC-S-EXT-CTRLS; and &VIDIOC-TRY-EXT-CTRLS;. These ioctls act on +arrays of controls (as opposed to the &VIDIOC-G-CTRL; and +&VIDIOC-S-CTRL; ioctls that act on a single control). This is needed +since it is often required to atomically change several controls at +once.</para> + + <para>Each of the new ioctls expects a pointer to a +&v4l2-ext-controls;. This structure contains a pointer to the control +array, a count of the number of controls in that array and a control +class. Control classes are used to group similar controls into a +single class. For example, control class +<constant>V4L2_CTRL_CLASS_USER</constant> contains all user controls +(&ie; all controls that can also be set using the old +<constant>VIDIOC_S_CTRL</constant> ioctl). Control class +<constant>V4L2_CTRL_CLASS_MPEG</constant> contains all controls +relating to MPEG encoding, etc.</para> + + <para>All controls in the control array must belong to the +specified control class. An error is returned if this is not the +case.</para> + + <para>It is also possible to use an empty control array (count +== 0) to check whether the specified control class is +supported.</para> + + <para>The control array is a &v4l2-ext-control; array. The +<structname>v4l2_ext_control</structname> structure is very similar to +&v4l2-control;, except for the fact that it also allows for 64-bit +values and pointers to be passed.</para> + + <para>It is important to realize that due to the flexibility of +controls it is necessary to check whether the control you want to set +actually is supported in the driver and what the valid range of values +is. So use the &VIDIOC-QUERYCTRL; and &VIDIOC-QUERYMENU; ioctls to +check this. Also note that it is possible that some of the menu +indices in a control of type <constant>V4L2_CTRL_TYPE_MENU</constant> +may not be supported (<constant>VIDIOC_QUERYMENU</constant> will +return an error). A good example is the list of supported MPEG audio +bitrates. Some drivers only support one or two bitrates, others +support a wider range.</para> + </section> + + <section> + <title>Enumerating Extended Controls</title> + + <para>The recommended way to enumerate over the extended +controls is by using &VIDIOC-QUERYCTRL; in combination with the +<constant>V4L2_CTRL_FLAG_NEXT_CTRL</constant> flag:</para> + + <informalexample> + <programlisting> +&v4l2-queryctrl; qctrl; + +qctrl.id = V4L2_CTRL_FLAG_NEXT_CTRL; +while (0 == ioctl (fd, &VIDIOC-QUERYCTRL;, &qctrl)) { + /* ... */ + qctrl.id |= V4L2_CTRL_FLAG_NEXT_CTRL; +} +</programlisting> + </informalexample> + + <para>The initial control ID is set to 0 ORed with the +<constant>V4L2_CTRL_FLAG_NEXT_CTRL</constant> flag. The +<constant>VIDIOC_QUERYCTRL</constant> ioctl will return the first +control with a higher ID than the specified one. When no such controls +are found an error is returned.</para> + + <para>If you want to get all controls within a specific control +class, then you can set the initial +<structfield>qctrl.id</structfield> value to the control class and add +an extra check to break out of the loop when a control of another +control class is found:</para> + + <informalexample> + <programlisting> +qctrl.id = V4L2_CTRL_CLASS_MPEG | V4L2_CTRL_FLAG_NEXT_CTRL; +while (0 == ioctl (fd, &VIDIOC-QUERYCTRL;, &qctrl)) { + if (V4L2_CTRL_ID2CLASS (qctrl.id) != V4L2_CTRL_CLASS_MPEG) + break; + /* ... */ + qctrl.id |= V4L2_CTRL_FLAG_NEXT_CTRL; + } +</programlisting> + </informalexample> + + <para>The 32-bit <structfield>qctrl.id</structfield> value is +subdivided into three bit ranges: the top 4 bits are reserved for +flags (⪚ <constant>V4L2_CTRL_FLAG_NEXT_CTRL</constant>) and are not +actually part of the ID. The remaining 28 bits form the control ID, of +which the most significant 12 bits define the control class and the +least significant 16 bits identify the control within the control +class. It is guaranteed that these last 16 bits are always non-zero +for controls. The range of 0x1000 and up are reserved for +driver-specific controls. The macro +<constant>V4L2_CTRL_ID2CLASS(id)</constant> returns the control class +ID based on a control ID.</para> + + <para>If the driver does not support extended controls, then +<constant>VIDIOC_QUERYCTRL</constant> will fail when used in +combination with <constant>V4L2_CTRL_FLAG_NEXT_CTRL</constant>. In +that case the old method of enumerating control should be used (see +1.8). But if it is supported, then it is guaranteed to enumerate over +all controls, including driver-private controls.</para> + </section> + + <section> + <title>Creating Control Panels</title> + + <para>It is possible to create control panels for a graphical +user interface where the user can select the various controls. +Basically you will have to iterate over all controls using the method +described above. Each control class starts with a control of type +<constant>V4L2_CTRL_TYPE_CTRL_CLASS</constant>. +<constant>VIDIOC_QUERYCTRL</constant> will return the name of this +control class which can be used as the title of a tab page within a +control panel.</para> + + <para>The flags field of &v4l2-queryctrl; also contains hints on +the behavior of the control. See the &VIDIOC-QUERYCTRL; documentation +for more details.</para> + </section> + + <section id="mpeg-controls"> + <title>MPEG Control Reference</title> + + <para>Below all controls within the MPEG control class are +described. First the generic controls, then controls specific for +certain hardware.</para> + + <section> + <title>Generic MPEG Controls</title> + + <table pgwide="1" frame="none" id="mpeg-control-id"> + <title>MPEG Control IDs</title> + <tgroup cols="4"> + <colspec colname="c1" colwidth="1*" /> + <colspec colname="c2" colwidth="6*" /> + <colspec colname="c3" colwidth="2*" /> + <colspec colname="c4" colwidth="6*" /> + <spanspec namest="c1" nameend="c2" spanname="id" /> + <spanspec namest="c2" nameend="c4" spanname="descr" /> + <thead> + <row> + <entry spanname="id" align="left">ID</entry> + <entry align="left">Type</entry> + </row><row rowsep="1"><entry spanname="descr" align="left">Description</entry> + </row> + </thead> + <tbody valign="top"> + <row><entry></entry></row> + <row> + <entry spanname="id"><constant>V4L2_CID_MPEG_CLASS</constant> </entry> + <entry>class</entry> + </row><row><entry spanname="descr">The MPEG class +descriptor. Calling &VIDIOC-QUERYCTRL; for this control will return a +description of this control class. This description can be used as the +caption of a Tab page in a GUI, for example.</entry> + </row> + <row><entry></entry></row> + <row id="v4l2-mpeg-stream-type"> + <entry spanname="id"><constant>V4L2_CID_MPEG_STREAM_TYPE</constant> </entry> + <entry>enum v4l2_mpeg_stream_type</entry> + </row><row><entry spanname="descr">The MPEG-1, -2 or -4 +output stream type. One cannot assume anything here. Each hardware +MPEG encoder tends to support different subsets of the available MPEG +stream types. The currently defined stream types are:</entry> + </row> + <row> + <entrytbl spanname="descr" cols="2"> + <tbody valign="top"> + <row> + <entry><constant>V4L2_MPEG_STREAM_TYPE_MPEG2_PS</constant> </entry> + <entry>MPEG-2 program stream</entry> + </row> + <row> + <entry><constant>V4L2_MPEG_STREAM_TYPE_MPEG2_TS</constant> </entry> + <entry>MPEG-2 transport stream</entry> + </row> + <row> + <entry><constant>V4L2_MPEG_STREAM_TYPE_MPEG1_SS</constant> </entry> + <entry>MPEG-1 system stream</entry> + </row> + <row> + <entry><constant>V4L2_MPEG_STREAM_TYPE_MPEG2_DVD</constant> </entry> + <entry>MPEG-2 DVD-compatible stream</entry> + </row> + <row> + <entry><constant>V4L2_MPEG_STREAM_TYPE_MPEG1_VCD</constant> </entry> + <entry>MPEG-1 VCD-compatible stream</entry> + </row> + <row> + <entry><constant>V4L2_MPEG_STREAM_TYPE_MPEG2_SVCD</constant> </entry> + <entry>MPEG-2 SVCD-compatible stream</entry> + </row> + </tbody> + </entrytbl> + </row> + <row><entry></entry></row> + <row> + <entry spanname="id"><constant>V4L2_CID_MPEG_STREAM_PID_PMT</constant> </entry> + <entry>integer</entry> + </row><row><entry spanname="descr">Program Map Table +Packet ID for the MPEG transport stream (default 16)</entry> + </row> + <row><entry></entry></row> + <row> + <entry spanname="id"><constant>V4L2_CID_MPEG_STREAM_PID_AUDIO</constant> </entry> + <entry>integer</entry> + </row><row><entry spanname="descr">Audio Packet ID for +the MPEG transport stream (default 256)</entry> + </row> + <row><entry></entry></row> + <row> + <entry spanname="id"><constant>V4L2_CID_MPEG_STREAM_PID_VIDEO</constant> </entry> + <entry>integer</entry> + </row><row><entry spanname="descr">Video Packet ID for +the MPEG transport stream (default 260)</entry> + </row> + <row><entry></entry></row> + <row> + <entry spanname="id"><constant>V4L2_CID_MPEG_STREAM_PID_PCR</constant> </entry> + <entry>integer</entry> + </row><row><entry spanname="descr">Packet ID for the +MPEG transport stream carrying PCR fields (default 259)</entry> + </row> + <row><entry></entry></row> + <row> + <entry spanname="id"><constant>V4L2_CID_MPEG_STREAM_PES_ID_AUDIO</constant> </entry> + <entry>integer</entry> + </row><row><entry spanname="descr">Audio ID for MPEG +PES</entry> + </row> + <row><entry></entry></row> + <row> + <entry spanname="id"><constant>V4L2_CID_MPEG_STREAM_PES_ID_VIDEO</constant> </entry> + <entry>integer</entry> + </row><row><entry spanname="descr">Video ID for MPEG +PES</entry> + </row> + <row><entry></entry></row> + <row id="v4l2-mpeg-stream-vbi-fmt"> + <entry spanname="id"><constant>V4L2_CID_MPEG_STREAM_VBI_FMT</constant> </entry> + <entry>enum v4l2_mpeg_stream_vbi_fmt</entry> + </row><row><entry spanname="descr">Some cards can embed +VBI data (⪚ Closed Caption, Teletext) into the MPEG stream. This +control selects whether VBI data should be embedded, and if so, what +embedding method should be used. The list of possible VBI formats +depends on the driver. The currently defined VBI format types +are:</entry> + </row> + <row> + <entrytbl spanname="descr" cols="2"> + <tbody valign="top"> + <row> + <entry><constant>V4L2_MPEG_STREAM_VBI_FMT_NONE</constant> </entry> + <entry>No VBI in the MPEG stream</entry> + </row> + <row> + <entry><constant>V4L2_MPEG_STREAM_VBI_FMT_IVTV</constant> </entry> + <entry>VBI in private packets, IVTV format (documented +in the kernel sources in the file <filename>Documentation/video4linux/cx2341x/README.vbi</filename>)</entry> + </row> + </tbody> + </entrytbl> + </row> + <row><entry></entry></row> + <row id="v4l2-mpeg-audio-sampling-freq"> + <entry spanname="id"><constant>V4L2_CID_MPEG_AUDIO_SAMPLING_FREQ</constant> </entry> + <entry>enum v4l2_mpeg_audio_sampling_freq</entry> + </row><row><entry spanname="descr">MPEG Audio sampling +frequency. Possible values are:</entry> + </row> + <row> + <entrytbl spanname="descr" cols="2"> + <tbody valign="top"> + <row> + <entry><constant>V4L2_MPEG_AUDIO_SAMPLING_FREQ_44100</constant> </entry> + <entry>44.1 kHz</entry> + </row> + <row> + <entry><constant>V4L2_MPEG_AUDIO_SAMPLING_FREQ_48000</constant> </entry> + <entry>48 kHz</entry> + </row> + <row> + <entry><constant>V4L2_MPEG_AUDIO_SAMPLING_FREQ_32000</constant> </entry> + <entry>32 kHz</entry> + </row> + </tbody> + </entrytbl> + </row> + <row><entry></entry></row> + <row id="v4l2-mpeg-audio-encoding"> + <entry spanname="id"><constant>V4L2_CID_MPEG_AUDIO_ENCODING</constant> </entry> + <entry>enum v4l2_mpeg_audio_encoding</entry> + </row><row><entry spanname="descr">MPEG Audio encoding. +Possible values are:</entry> + </row> + <row> + <entrytbl spanname="descr" cols="2"> + <tbody valign="top"> + <row> + <entry><constant>V4L2_MPEG_AUDIO_ENCODING_LAYER_1</constant> </entry> + <entry>MPEG-1/2 Layer I encoding</entry> + </row> + <row> + <entry><constant>V4L2_MPEG_AUDIO_ENCODING_LAYER_2</constant> </entry> + <entry>MPEG-1/2 Layer II encoding</entry> + </row> + <row> + <entry><constant>V4L2_MPEG_AUDIO_ENCODING_LAYER_3</constant> </entry> + <entry>MPEG-1/2 Layer III encoding</entry> + </row> + <row> + <entry><constant>V4L2_MPEG_AUDIO_ENCODING_AAC</constant> </entry> + <entry>MPEG-2/4 AAC (Advanced Audio Coding)</entry> + </row> + <row> + <entry><constant>V4L2_MPEG_AUDIO_ENCODING_AC3</constant> </entry> + <entry>AC-3 aka ATSC A/52 encoding</entry> + </row> + </tbody> + </entrytbl> + </row> + <row><entry></entry></row> + <row id="v4l2-mpeg-audio-l1-bitrate"> + <entry spanname="id"><constant>V4L2_CID_MPEG_AUDIO_L1_BITRATE</constant> </entry> + <entry>enum v4l2_mpeg_audio_l1_bitrate</entry> + </row><row><entry spanname="descr">MPEG-1/2 Layer I bitrate. +Possible values are:</entry> + </row> + <row> + <entrytbl spanname="descr" cols="2"> + <tbody valign="top"> + <row> + <entry><constant>V4L2_MPEG_AUDIO_L1_BITRATE_32K</constant> </entry> + <entry>32 kbit/s</entry></row> + <row> + <entry><constant>V4L2_MPEG_AUDIO_L1_BITRATE_64K</constant> </entry> + <entry>64 kbit/s</entry> + </row> + <row> + <entry><constant>V4L2_MPEG_AUDIO_L1_BITRATE_96K</constant> </entry> + <entry>96 kbit/s</entry> + </row> + <row> + <entry><constant>V4L2_MPEG_AUDIO_L1_BITRATE_128K</constant> </entry> + <entry>128 kbit/s</entry> + </row> + <row> + <entry><constant>V4L2_MPEG_AUDIO_L1_BITRATE_160K</constant> </entry> + <entry>160 kbit/s</entry> + </row> + <row> + <entry><constant>V4L2_MPEG_AUDIO_L1_BITRATE_192K</constant> </entry> + <entry>192 kbit/s</entry> + </row> + <row> + <entry><constant>V4L2_MPEG_AUDIO_L1_BITRATE_224K</constant> </entry> + <entry>224 kbit/s</entry> + </row> + <row> + <entry><constant>V4L2_MPEG_AUDIO_L1_BITRATE_256K</constant> </entry> + <entry>256 kbit/s</entry> + </row> + <row> + <entry><constant>V4L2_MPEG_AUDIO_L1_BITRATE_288K</constant> </entry> + <entry>288 kbit/s</entry> + </row> + <row> + <entry><constant>V4L2_MPEG_AUDIO_L1_BITRATE_320K</constant> </entry> + <entry>320 kbit/s</entry> + </row> + <row> + <entry><constant>V4L2_MPEG_AUDIO_L1_BITRATE_352K</constant> </entry> + <entry>352 kbit/s</entry> + </row> + <row> + <entry><constant>V4L2_MPEG_AUDIO_L1_BITRATE_384K</constant> </entry> + <entry>384 kbit/s</entry> + </row> + <row> + <entry><constant>V4L2_MPEG_AUDIO_L1_BITRATE_416K</constant> </entry> + <entry>416 kbit/s</entry> + </row> + <row> + <entry><constant>V4L2_MPEG_AUDIO_L1_BITRATE_448K</constant> </entry> + <entry>448 kbit/s</entry> + </row> + </tbody> + </entrytbl> + </row> + <row><entry></entry></row> + <row id="v4l2-mpeg-audio-l2-bitrate"> + <entry spanname="id"><constant>V4L2_CID_MPEG_AUDIO_L2_BITRATE</constant> </entry> + <entry>enum v4l2_mpeg_audio_l2_bitrate</entry> + </row><row><entry spanname="descr">MPEG-1/2 Layer II bitrate. +Possible values are:</entry> + </row> + <row> + <entrytbl spanname="descr" cols="2"> + <tbody valign="top"> + <row> + <entry><constant>V4L2_MPEG_AUDIO_L2_BITRATE_32K</constant> </entry> + <entry>32 kbit/s</entry> + </row> + <row> + <entry><constant>V4L2_MPEG_AUDIO_L2_BITRATE_48K</constant> </entry> + <entry>48 kbit/s</entry> + </row> + <row> + <entry><constant>V4L2_MPEG_AUDIO_L2_BITRATE_56K</constant> </entry> + <entry>56 kbit/s</entry> + </row> + <row> + <entry><constant>V4L2_MPEG_AUDIO_L2_BITRATE_64K</constant> </entry> + <entry>64 kbit/s</entry> + </row> + <row> + <entry><constant>V4L2_MPEG_AUDIO_L2_BITRATE_80K</constant> </entry> + <entry>80 kbit/s</entry> + </row> + <row> + <entry><constant>V4L2_MPEG_AUDIO_L2_BITRATE_96K</constant> </entry> + <entry>96 kbit/s</entry> + </row> + <row> + <entry><constant>V4L2_MPEG_AUDIO_L2_BITRATE_112K</constant> </entry> + <entry>112 kbit/s</entry> + </row> + <row> + <entry><constant>V4L2_MPEG_AUDIO_L2_BITRATE_128K</constant> </entry> + <entry>128 kbit/s</entry> + </row> + <row> + <entry><constant>V4L2_MPEG_AUDIO_L2_BITRATE_160K</constant> </entry> + <entry>160 kbit/s</entry> + </row> + <row> + <entry><constant>V4L2_MPEG_AUDIO_L2_BITRATE_192K</constant> </entry> + <entry>192 kbit/s</entry> + </row> + <row> + <entry><constant>V4L2_MPEG_AUDIO_L2_BITRATE_224K</constant> </entry> + <entry>224 kbit/s</entry> + </row> + <row> + <entry><constant>V4L2_MPEG_AUDIO_L2_BITRATE_256K</constant> </entry> + <entry>256 kbit/s</entry> + </row> + <row> + <entry><constant>V4L2_MPEG_AUDIO_L2_BITRATE_320K</constant> </entry> + <entry>320 kbit/s</entry> + </row> + <row> + <entry><constant>V4L2_MPEG_AUDIO_L2_BITRATE_384K</constant> </entry> + <entry>384 kbit/s</entry> + </row> + </tbody> + </entrytbl> + </row> + <row><entry></entry></row> + <row id="v4l2-mpeg-audio-l3-bitrate"> + <entry spanname="id"><constant>V4L2_CID_MPEG_AUDIO_L3_BITRATE</constant> </entry> + <entry>enum v4l2_mpeg_audio_l3_bitrate</entry> + </row><row><entry spanname="descr">MPEG-1/2 Layer III bitrate. +Possible values are:</entry> + </row> + <row> + <entrytbl spanname="descr" cols="2"> + <tbody valign="top"> + <row> + <entry><constant>V4L2_MPEG_AUDIO_L3_BITRATE_32K</constant> </entry> + <entry>32 kbit/s</entry> + </row> + <row> + <entry><constant>V4L2_MPEG_AUDIO_L3_BITRATE_40K</constant> </entry> + <entry>40 kbit/s</entry> + </row> + <row> + <entry><constant>V4L2_MPEG_AUDIO_L3_BITRATE_48K</constant> </entry> + <entry>48 kbit/s</entry> + </row> + <row> + <entry><constant>V4L2_MPEG_AUDIO_L3_BITRATE_56K</constant> </entry> + <entry>56 kbit/s</entry> + </row> + <row> + <entry><constant>V4L2_MPEG_AUDIO_L3_BITRATE_64K</constant> </entry> + <entry>64 kbit/s</entry> + </row> + <row> + <entry><constant>V4L2_MPEG_AUDIO_L3_BITRATE_80K</constant> </entry> + <entry>80 kbit/s</entry> + </row> + <row> + <entry><constant>V4L2_MPEG_AUDIO_L3_BITRATE_96K</constant> </entry> + <entry>96 kbit/s</entry> + </row> + <row> + <entry><constant>V4L2_MPEG_AUDIO_L3_BITRATE_112K</constant> </entry> + <entry>112 kbit/s</entry> + </row> + <row> + <entry><constant>V4L2_MPEG_AUDIO_L3_BITRATE_128K</constant> </entry> + <entry>128 kbit/s</entry> + </row> + <row> + <entry><constant>V4L2_MPEG_AUDIO_L3_BITRATE_160K</constant> </entry> + <entry>160 kbit/s</entry> + </row> + <row> + <entry><constant>V4L2_MPEG_AUDIO_L3_BITRATE_192K</constant> </entry> + <entry>192 kbit/s</entry> + </row> + <row> + <entry><constant>V4L2_MPEG_AUDIO_L3_BITRATE_224K</constant> </entry> + <entry>224 kbit/s</entry> + </row> + <row> + <entry><constant>V4L2_MPEG_AUDIO_L3_BITRATE_256K</constant> </entry> + <entry>256 kbit/s</entry> + </row> + <row> + <entry><constant>V4L2_MPEG_AUDIO_L3_BITRATE_320K</constant> </entry> + <entry>320 kbit/s</entry> + </row> + </tbody> + </entrytbl> + </row> + <row><entry></entry></row> + <row> + <entry spanname="id"><constant>V4L2_CID_MPEG_AUDIO_AAC_BITRATE</constant> </entry> + <entry>integer</entry> + </row><row><entry spanname="descr">AAC bitrate in bits per second.</entry> + </row> + <row><entry></entry></row> + <row id="v4l2-mpeg-audio-ac3-bitrate"> + <entry spanname="id"><constant>V4L2_CID_MPEG_AUDIO_AC3_BITRATE</constant> </entry> + <entry>enum v4l2_mpeg_audio_ac3_bitrate</entry> + </row><row><entry spanname="descr">AC-3 bitrate. +Possible values are:</entry> + </row> + <row> + <entrytbl spanname="descr" cols="2"> + <tbody valign="top"> + <row> + <entry><constant>V4L2_MPEG_AUDIO_AC3_BITRATE_32K</constant> </entry> + <entry>32 kbit/s</entry> + </row> + <row> + <entry><constant>V4L2_MPEG_AUDIO_AC3_BITRATE_40K</constant> </entry> + <entry>40 kbit/s</entry> + </row> + <row> + <entry><constant>V4L2_MPEG_AUDIO_AC3_BITRATE_48K</constant> </entry> + <entry>48 kbit/s</entry> + </row> + <row> + <entry><constant>V4L2_MPEG_AUDIO_AC3_BITRATE_56K</constant> </entry> + <entry>56 kbit/s</entry> + </row> + <row> + <entry><constant>V4L2_MPEG_AUDIO_AC3_BITRATE_64K</constant> </entry> + <entry>64 kbit/s</entry> + </row> + <row> + <entry><constant>V4L2_MPEG_AUDIO_AC3_BITRATE_80K</constant> </entry> + <entry>80 kbit/s</entry> + </row> + <row> + <entry><constant>V4L2_MPEG_AUDIO_AC3_BITRATE_96K</constant> </entry> + <entry>96 kbit/s</entry> + </row> + <row> + <entry><constant>V4L2_MPEG_AUDIO_AC3_BITRATE_112K</constant> </entry> + <entry>112 kbit/s</entry> + </row> + <row> + <entry><constant>V4L2_MPEG_AUDIO_AC3_BITRATE_128K</constant> </entry> + <entry>128 kbit/s</entry> + </row> + <row> + <entry><constant>V4L2_MPEG_AUDIO_AC3_BITRATE_160K</constant> </entry> + <entry>160 kbit/s</entry> + </row> + <row> + <entry><constant>V4L2_MPEG_AUDIO_AC3_BITRATE_192K</constant> </entry> + <entry>192 kbit/s</entry> + </row> + <row> + <entry><constant>V4L2_MPEG_AUDIO_AC3_BITRATE_224K</constant> </entry> + <entry>224 kbit/s</entry> + </row> + <row> + <entry><constant>V4L2_MPEG_AUDIO_AC3_BITRATE_256K</constant> </entry> + <entry>256 kbit/s</entry> + </row> + <row> + <entry><constant>V4L2_MPEG_AUDIO_AC3_BITRATE_320K</constant> </entry> + <entry>320 kbit/s</entry> + </row> + <row> + <entry><constant>V4L2_MPEG_AUDIO_AC3_BITRATE_384K</constant> </entry> + <entry>384 kbit/s</entry> + </row> + <row> + <entry><constant>V4L2_MPEG_AUDIO_AC3_BITRATE_448K</constant> </entry> + <entry>448 kbit/s</entry> + </row> + <row> + <entry><constant>V4L2_MPEG_AUDIO_AC3_BITRATE_512K</constant> </entry> + <entry>512 kbit/s</entry> + </row> + <row> + <entry><constant>V4L2_MPEG_AUDIO_AC3_BITRATE_576K</constant> </entry> + <entry>576 kbit/s</entry> + </row> + <row> + <entry><constant>V4L2_MPEG_AUDIO_AC3_BITRATE_640K</constant> </entry> + <entry>640 kbit/s</entry> + </row> + </tbody> + </entrytbl> + </row> + <row><entry></entry></row> + <row id="v4l2-mpeg-audio-mode"> + <entry spanname="id"><constant>V4L2_CID_MPEG_AUDIO_MODE</constant> </entry> + <entry>enum v4l2_mpeg_audio_mode</entry> + </row><row><entry spanname="descr">MPEG Audio mode. +Possible values are:</entry> + </row> + <row> + <entrytbl spanname="descr" cols="2"> + <tbody valign="top"> + <row> + <entry><constant>V4L2_MPEG_AUDIO_MODE_STEREO</constant> </entry> + <entry>Stereo</entry> + </row> + <row> + <entry><constant>V4L2_MPEG_AUDIO_MODE_JOINT_STEREO</constant> </entry> + <entry>Joint Stereo</entry> + </row> + <row> + <entry><constant>V4L2_MPEG_AUDIO_MODE_DUAL</constant> </entry> + <entry>Bilingual</entry> + </row> + <row> + <entry><constant>V4L2_MPEG_AUDIO_MODE_MONO</constant> </entry> + <entry>Mono</entry> + </row> + </tbody> + </entrytbl> + </row> + <row><entry></entry></row> + <row id="v4l2-mpeg-audio-mode-extension"> + <entry spanname="id"><constant>V4L2_CID_MPEG_AUDIO_MODE_EXTENSION</constant> </entry> + <entry>enum v4l2_mpeg_audio_mode_extension</entry> + </row><row><entry spanname="descr">Joint Stereo +audio mode extension. In Layer I and II they indicate which subbands +are in intensity stereo. All other subbands are coded in stereo. Layer +III is not (yet) supported. Possible values +are:</entry> + </row> + <row> + <entrytbl spanname="descr" cols="2"> + <tbody valign="top"> + <row> + <entry><constant>V4L2_MPEG_AUDIO_MODE_EXTENSION_BOUND_4</constant> </entry> + <entry>Subbands 4-31 in intensity stereo</entry> + </row> + <row> + <entry><constant>V4L2_MPEG_AUDIO_MODE_EXTENSION_BOUND_8</constant> </entry> + <entry>Subbands 8-31 in intensity stereo</entry> + </row> + <row> + <entry><constant>V4L2_MPEG_AUDIO_MODE_EXTENSION_BOUND_12</constant> </entry> + <entry>Subbands 12-31 in intensity stereo</entry> + </row> + <row> + <entry><constant>V4L2_MPEG_AUDIO_MODE_EXTENSION_BOUND_16</constant> </entry> + <entry>Subbands 16-31 in intensity stereo</entry> + </row> + </tbody> + </entrytbl> + </row> + <row><entry></entry></row> + <row id="v4l2-mpeg-audio-emphasis"> + <entry spanname="id"><constant>V4L2_CID_MPEG_AUDIO_EMPHASIS</constant> </entry> + <entry>enum v4l2_mpeg_audio_emphasis</entry> + </row><row><entry spanname="descr">Audio Emphasis. +Possible values are:</entry> + </row> + <row> + <entrytbl spanname="descr" cols="2"> + <tbody valign="top"> + <row> + <entry><constant>V4L2_MPEG_AUDIO_EMPHASIS_NONE</constant> </entry> + <entry>None</entry> + </row> + <row> + <entry><constant>V4L2_MPEG_AUDIO_EMPHASIS_50_DIV_15_uS</constant> </entry> + <entry>50/15 microsecond emphasis</entry> + </row> + <row> + <entry><constant>V4L2_MPEG_AUDIO_EMPHASIS_CCITT_J17</constant> </entry> + <entry>CCITT J.17</entry> + </row> + </tbody> + </entrytbl> + </row> + <row><entry></entry></row> + <row id="v4l2-mpeg-audio-crc"> + <entry spanname="id"><constant>V4L2_CID_MPEG_AUDIO_CRC</constant> </entry> + <entry>enum v4l2_mpeg_audio_crc</entry> + </row><row><entry spanname="descr">CRC method. Possible +values are:</entry> + </row> + <row> + <entrytbl spanname="descr" cols="2"> + <tbody valign="top"> + <row> + <entry><constant>V4L2_MPEG_AUDIO_CRC_NONE</constant> </entry> + <entry>None</entry> + </row> + <row> + <entry><constant>V4L2_MPEG_AUDIO_CRC_CRC16</constant> </entry> + <entry>16 bit parity check</entry> + </row> + </tbody> + </entrytbl> + </row> + <row><entry></entry></row> + <row> + <entry spanname="id"><constant>V4L2_CID_MPEG_AUDIO_MUTE</constant> </entry> + <entry>boolean</entry> + </row><row><entry spanname="descr">Mutes the audio when +capturing. This is not done by muting audio hardware, which can still +produce a slight hiss, but in the encoder itself, guaranteeing a fixed +and reproducable audio bitstream. 0 = unmuted, 1 = muted.</entry> + </row> + <row><entry></entry></row> + <row id="v4l2-mpeg-video-encoding"> + <entry spanname="id"><constant>V4L2_CID_MPEG_VIDEO_ENCODING</constant> </entry> + <entry>enum v4l2_mpeg_video_encoding</entry> + </row><row><entry spanname="descr">MPEG Video encoding +method. Possible values are:</entry> + </row> + <row> + <entrytbl spanname="descr" cols="2"> + <tbody valign="top"> + <row> + <entry><constant>V4L2_MPEG_VIDEO_ENCODING_MPEG_1</constant> </entry> + <entry>MPEG-1 Video encoding</entry> + </row> + <row> + <entry><constant>V4L2_MPEG_VIDEO_ENCODING_MPEG_2</constant> </entry> + <entry>MPEG-2 Video encoding</entry> + </row> + <row> + <entry><constant>V4L2_MPEG_VIDEO_ENCODING_MPEG_4_AVC</constant> </entry> + <entry>MPEG-4 AVC (H.264) Video encoding</entry> + </row> + </tbody> + </entrytbl> + </row> + <row><entry></entry></row> + <row id="v4l2-mpeg-video-aspect"> + <entry spanname="id"><constant>V4L2_CID_MPEG_VIDEO_ASPECT</constant> </entry> + <entry>enum v4l2_mpeg_video_aspect</entry> + </row><row><entry spanname="descr">Video aspect. +Possible values are:</entry> + </row> + <row> + <entrytbl spanname="descr" cols="2"> + <tbody valign="top"> + <row> + <entry><constant>V4L2_MPEG_VIDEO_ASPECT_1x1</constant> </entry> + </row> + <row> + <entry><constant>V4L2_MPEG_VIDEO_ASPECT_4x3</constant> </entry> + </row> + <row> + <entry><constant>V4L2_MPEG_VIDEO_ASPECT_16x9</constant> </entry> + </row> + <row> + <entry><constant>V4L2_MPEG_VIDEO_ASPECT_221x100</constant> </entry> + </row> + </tbody> + </entrytbl> + </row> + <row><entry></entry></row> + <row> + <entry spanname="id"><constant>V4L2_CID_MPEG_VIDEO_B_FRAMES</constant> </entry> + <entry>integer</entry> + </row><row><entry spanname="descr">Number of B-Frames +(default 2)</entry> + </row> + <row><entry></entry></row> + <row> + <entry spanname="id"><constant>V4L2_CID_MPEG_VIDEO_GOP_SIZE</constant> </entry> + <entry>integer</entry> + </row><row><entry spanname="descr">GOP size (default +12)</entry> + </row> + <row><entry></entry></row> + <row> + <entry spanname="id"><constant>V4L2_CID_MPEG_VIDEO_GOP_CLOSURE</constant> </entry> + <entry>boolean</entry> + </row><row><entry spanname="descr">GOP closure (default +1)</entry> + </row> + <row><entry></entry></row> + <row> + <entry spanname="id"><constant>V4L2_CID_MPEG_VIDEO_PULLDOWN</constant> </entry> + <entry>boolean</entry> + </row><row><entry spanname="descr">Enable 3:2 pulldown +(default 0)</entry> + </row> + <row><entry></entry></row> + <row id="v4l2-mpeg-video-bitrate-mode"> + <entry spanname="id"><constant>V4L2_CID_MPEG_VIDEO_BITRATE_MODE</constant> </entry> + <entry>enum v4l2_mpeg_video_bitrate_mode</entry> + </row><row><entry spanname="descr">Video bitrate mode. +Possible values are:</entry> + </row> + <row> + <entrytbl spanname="descr" cols="2"> + <tbody valign="top"> + <row> + <entry><constant>V4L2_MPEG_VIDEO_BITRATE_MODE_VBR</constant> </entry> + <entry>Variable bitrate</entry> + </row> + <row> + <entry><constant>V4L2_MPEG_VIDEO_BITRATE_MODE_CBR</constant> </entry> + <entry>Constant bitrate</entry> + </row> + </tbody> + </entrytbl> + </row> + <row><entry></entry></row> + <row> + <entry spanname="id"><constant>V4L2_CID_MPEG_VIDEO_BITRATE</constant> </entry> + <entry>integer</entry> + </row><row><entry spanname="descr">Video bitrate in bits +per second.</entry> + </row> + <row><entry></entry></row> + <row> + <entry spanname="id"><constant>V4L2_CID_MPEG_VIDEO_BITRATE_PEAK</constant> </entry> + <entry>integer</entry> + </row><row><entry spanname="descr">Peak video bitrate in +bits per second. Must be larger or equal to the average video bitrate. +It is ignored if the video bitrate mode is set to constant +bitrate.</entry> + </row> + <row><entry></entry></row> + <row> + <entry spanname="id"><constant>V4L2_CID_MPEG_VIDEO_TEMPORAL_DECIMATION</constant> </entry> + <entry>integer</entry> + </row><row><entry spanname="descr">For every captured +frame, skip this many subsequent frames (default 0).</entry> + </row> + <row><entry></entry></row> + <row> + <entry spanname="id"><constant>V4L2_CID_MPEG_VIDEO_MUTE</constant> </entry> + <entry>boolean</entry> + </row> + <row><entry spanname="descr">"Mutes" the video to a +fixed color when capturing. This is useful for testing, to produce a +fixed video bitstream. 0 = unmuted, 1 = muted.</entry> + </row> + <row><entry></entry></row> + <row> + <entry spanname="id"><constant>V4L2_CID_MPEG_VIDEO_MUTE_YUV</constant> </entry> + <entry>integer</entry> + </row><row><entry spanname="descr">Sets the "mute" color +of the video. The supplied 32-bit integer is interpreted as follows (bit +0 = least significant bit):</entry> + </row> + <row> + <entrytbl spanname="descr" cols="2"> + <tbody valign="top"> + <row> + <entry>Bit 0:7</entry> + <entry>V chrominance information</entry> + </row> + <row> + <entry>Bit 8:15</entry> + <entry>U chrominance information</entry> + </row> + <row> + <entry>Bit 16:23</entry> + <entry>Y luminance information</entry> + </row> + <row> + <entry>Bit 24:31</entry> + <entry>Must be zero.</entry> + </row> + </tbody> + </entrytbl> + </row> + </tbody> + </tgroup> + </table> + </section> + + <section> + <title>CX2341x MPEG Controls</title> + + <para>The following MPEG class controls deal with MPEG +encoding settings that are specific to the Conexant CX23415 and +CX23416 MPEG encoding chips.</para> + + <table pgwide="1" frame="none" id="cx2341x-control-id"> + <title>CX2341x Control IDs</title> + <tgroup cols="4"> + <colspec colname="c1" colwidth="1*" /> + <colspec colname="c2" colwidth="6*" /> + <colspec colname="c3" colwidth="2*" /> + <colspec colname="c4" colwidth="6*" /> + <spanspec namest="c1" nameend="c2" spanname="id" /> + <spanspec namest="c2" nameend="c4" spanname="descr" /> + <thead> + <row> + <entry spanname="id" align="left">ID</entry> + <entry align="left">Type</entry> + </row><row><entry spanname="descr" align="left">Description</entry> + </row> + </thead> + <tbody valign="top"> + <row><entry></entry></row> + <row id="v4l2-mpeg-cx2341x-video-spatial-filter-mode"> + <entry spanname="id"><constant>V4L2_CID_MPEG_CX2341X_VIDEO_SPATIAL_FILTER_MODE</constant> </entry> + <entry>enum v4l2_mpeg_cx2341x_video_spatial_filter_mode</entry> + </row><row><entry spanname="descr">Sets the Spatial +Filter mode (default <constant>MANUAL</constant>). Possible values +are:</entry> + </row> + <row> + <entrytbl spanname="descr" cols="2"> + <tbody valign="top"> + <row> + <entry><constant>V4L2_MPEG_CX2341X_VIDEO_SPATIAL_FILTER_MODE_MANUAL</constant> </entry> + <entry>Choose the filter manually</entry> + </row> + <row> + <entry><constant>V4L2_MPEG_CX2341X_VIDEO_SPATIAL_FILTER_MODE_AUTO</constant> </entry> + <entry>Choose the filter automatically</entry> + </row> + </tbody> + </entrytbl> + </row> + <row><entry></entry></row> + <row> + <entry spanname="id"><constant>V4L2_CID_MPEG_CX2341X_VIDEO_SPATIAL_FILTER</constant> </entry> + <entry>integer (0-15)</entry> + </row><row><entry spanname="descr">The setting for the +Spatial Filter. 0 = off, 15 = maximum. (Default is 0.)</entry> + </row> + <row><entry></entry></row> + <row id="luma-spatial-filter-type"> + <entry spanname="id"><constant>V4L2_CID_MPEG_CX2341X_VIDEO_LUMA_SPATIAL_FILTER_TYPE</constant> </entry> + <entry>enum v4l2_mpeg_cx2341x_video_luma_spatial_filter_type</entry> + </row><row><entry spanname="descr">Select the algorithm +to use for the Luma Spatial Filter (default +<constant>1D_HOR</constant>). Possible values:</entry> + </row> + <row> + <entrytbl spanname="descr" cols="2"> + <tbody valign="top"> + <row> + <entry><constant>V4L2_MPEG_CX2341X_VIDEO_LUMA_SPATIAL_FILTER_TYPE_OFF</constant> </entry> + <entry>No filter</entry> + </row> + <row> + <entry><constant>V4L2_MPEG_CX2341X_VIDEO_LUMA_SPATIAL_FILTER_TYPE_1D_HOR</constant> </entry> + <entry>One-dimensional horizontal</entry> + </row> + <row> + <entry><constant>V4L2_MPEG_CX2341X_VIDEO_LUMA_SPATIAL_FILTER_TYPE_1D_VERT</constant> </entry> + <entry>One-dimensional vertical</entry> + </row> + <row> + <entry><constant>V4L2_MPEG_CX2341X_VIDEO_LUMA_SPATIAL_FILTER_TYPE_2D_HV_SEPARABLE</constant> </entry> + <entry>Two-dimensional separable</entry> + </row> + <row> + <entry><constant>V4L2_MPEG_CX2341X_VIDEO_LUMA_SPATIAL_FILTER_TYPE_2D_SYM_NON_SEPARABLE</constant> </entry> + <entry>Two-dimensional symmetrical +non-separable</entry> + </row> + </tbody> + </entrytbl> + </row> + <row><entry></entry></row> + <row id="chroma-spatial-filter-type"> + <entry spanname="id"><constant>V4L2_CID_MPEG_CX2341X_VIDEO_CHROMA_SPATIAL_FILTER_TYPE</constant> </entry> + <entry>enum v4l2_mpeg_cx2341x_video_chroma_spatial_filter_type</entry> + </row><row><entry spanname="descr">Select the algorithm +for the Chroma Spatial Filter (default <constant>1D_HOR</constant>). +Possible values are:</entry> + </row> + <row> + <entrytbl spanname="descr" cols="2"> + <tbody valign="top"> + <row> + <entry><constant>V4L2_MPEG_CX2341X_VIDEO_CHROMA_SPATIAL_FILTER_TYPE_OFF</constant> </entry> + <entry>No filter</entry> + </row> + <row> + <entry><constant>V4L2_MPEG_CX2341X_VIDEO_CHROMA_SPATIAL_FILTER_TYPE_1D_HOR</constant> </entry> + <entry>One-dimensional horizontal</entry> + </row> + </tbody> + </entrytbl> + </row> + <row><entry></entry></row> + <row id="v4l2-mpeg-cx2341x-video-temporal-filter-mode"> + <entry spanname="id"><constant>V4L2_CID_MPEG_CX2341X_VIDEO_TEMPORAL_FILTER_MODE</constant> </entry> + <entry>enum v4l2_mpeg_cx2341x_video_temporal_filter_mode</entry> + </row><row><entry spanname="descr">Sets the Temporal +Filter mode (default <constant>MANUAL</constant>). Possible values +are:</entry> + </row> + <row> + <entrytbl spanname="descr" cols="2"> + <tbody valign="top"> + <row> + <entry><constant>V4L2_MPEG_CX2341X_VIDEO_TEMPORAL_FILTER_MODE_MANUAL</constant> </entry> + <entry>Choose the filter manually</entry> + </row> + <row> + <entry><constant>V4L2_MPEG_CX2341X_VIDEO_TEMPORAL_FILTER_MODE_AUTO</constant> </entry> + <entry>Choose the filter automatically</entry> + </row> + </tbody> + </entrytbl> + </row> + <row><entry></entry></row> + <row> + <entry spanname="id"><constant>V4L2_CID_MPEG_CX2341X_VIDEO_TEMPORAL_FILTER</constant> </entry> + <entry>integer (0-31)</entry> + </row><row><entry spanname="descr">The setting for the +Temporal Filter. 0 = off, 31 = maximum. (Default is 8 for full-scale +capturing and 0 for scaled capturing.)</entry> + </row> + <row><entry></entry></row> + <row id="v4l2-mpeg-cx2341x-video-median-filter-type"> + <entry spanname="id"><constant>V4L2_CID_MPEG_CX2341X_VIDEO_MEDIAN_FILTER_TYPE</constant> </entry> + <entry>enum v4l2_mpeg_cx2341x_video_median_filter_type</entry> + </row><row><entry spanname="descr">Median Filter Type +(default <constant>OFF</constant>). Possible values are:</entry> + </row> + <row> + <entrytbl spanname="descr" cols="2"> + <tbody valign="top"> + <row> + <entry><constant>V4L2_MPEG_CX2341X_VIDEO_MEDIAN_FILTER_TYPE_OFF</constant> </entry> + <entry>No filter</entry> + </row> + <row> + <entry><constant>V4L2_MPEG_CX2341X_VIDEO_MEDIAN_FILTER_TYPE_HOR</constant> </entry> + <entry>Horizontal filter</entry> + </row> + <row> + <entry><constant>V4L2_MPEG_CX2341X_VIDEO_MEDIAN_FILTER_TYPE_VERT</constant> </entry> + <entry>Vertical filter</entry> + </row> + <row> + <entry><constant>V4L2_MPEG_CX2341X_VIDEO_MEDIAN_FILTER_TYPE_HOR_VERT</constant> </entry> + <entry>Horizontal and vertical filter</entry> + </row> + <row> + <entry><constant>V4L2_MPEG_CX2341X_VIDEO_MEDIAN_FILTER_TYPE_DIAG</constant> </entry> + <entry>Diagonal filter</entry> + </row> + </tbody> + </entrytbl> + </row> + <row><entry></entry></row> + <row> + <entry spanname="id"><constant>V4L2_CID_MPEG_CX2341X_VIDEO_LUMA_MEDIAN_FILTER_BOTTOM</constant> </entry> + <entry>integer (0-255)</entry> + </row><row><entry spanname="descr">Threshold above which +the luminance median filter is enabled (default 0)</entry> + </row> + <row><entry></entry></row> + <row> + <entry spanname="id"><constant>V4L2_CID_MPEG_CX2341X_VIDEO_LUMA_MEDIAN_FILTER_TOP</constant> </entry> + <entry>integer (0-255)</entry> + </row><row><entry spanname="descr">Threshold below which +the luminance median filter is enabled (default 255)</entry> + </row> + <row><entry></entry></row> + <row> + <entry spanname="id"><constant>V4L2_CID_MPEG_CX2341X_VIDEO_CHROMA_MEDIAN_FILTER_BOTTOM</constant> </entry> + <entry>integer (0-255)</entry> + </row><row><entry spanname="descr">Threshold above which +the chroma median filter is enabled (default 0)</entry> + </row> + <row><entry></entry></row> + <row> + <entry spanname="id"><constant>V4L2_CID_MPEG_CX2341X_VIDEO_CHROMA_MEDIAN_FILTER_TOP</constant> </entry> + <entry>integer (0-255)</entry> + </row><row><entry spanname="descr">Threshold below which +the chroma median filter is enabled (default 255)</entry> + </row> + <row><entry></entry></row> + <row> + <entry spanname="id"><constant>V4L2_CID_MPEG_CX2341X_STREAM_INSERT_NAV_PACKETS</constant> </entry> + <entry>boolean</entry> + </row> + <row><entry spanname="descr">The CX2341X MPEG encoder +can insert one empty MPEG-2 PES packet into the stream between every +four video frames. The packet size is 2048 bytes, including the +packet_start_code_prefix and stream_id fields. The stream_id is 0xBF +(private stream 2). The payload consists of 0x00 bytes, to be filled +in by the application. 0 = do not insert, 1 = insert packets.</entry> + </row> + </tbody> + </tgroup> + </table> + </section> + </section> + + <section id="camera-controls"> + <title>Camera Control Reference</title> + + <para>The Camera class includes controls for mechanical (or +equivalent digital) features of a device such as controllable lenses +or sensors.</para> + + <table pgwide="1" frame="none" id="camera-control-id"> + <title>Camera Control IDs</title> + <tgroup cols="4"> + <colspec colname="c1" colwidth="1*" /> + <colspec colname="c2" colwidth="6*" /> + <colspec colname="c3" colwidth="2*" /> + <colspec colname="c4" colwidth="6*" /> + <spanspec namest="c1" nameend="c2" spanname="id" /> + <spanspec namest="c2" nameend="c4" spanname="descr" /> + <thead> + <row> + <entry spanname="id" align="left">ID</entry> + <entry align="left">Type</entry> + </row><row rowsep="1"><entry spanname="descr" align="left">Description</entry> + </row> + </thead> + <tbody valign="top"> + <row><entry></entry></row> + <row> + <entry spanname="id"><constant>V4L2_CID_CAMERA_CLASS</constant> </entry> + <entry>class</entry> + </row><row><entry spanname="descr">The Camera class +descriptor. Calling &VIDIOC-QUERYCTRL; for this control will return a +description of this control class.</entry> + </row> + <row><entry></entry></row> + + <row id="v4l2-exposure-auto-type"> + <entry spanname="id"><constant>V4L2_CID_EXPOSURE_AUTO</constant> </entry> + <entry>enum v4l2_exposure_auto_type</entry> + </row><row><entry spanname="descr">Enables automatic +adjustments of the exposure time and/or iris aperture. The effect of +manual changes of the exposure time or iris aperture while these +features are enabled is undefined, drivers should ignore such +requests. Possible values are:</entry> + </row> + <row> + <entrytbl spanname="descr" cols="2"> + <tbody valign="top"> + <row> + <entry><constant>V4L2_EXPOSURE_AUTO</constant> </entry> + <entry>Automatic exposure time, automatic iris +aperture.</entry> + </row> + <row> + <entry><constant>V4L2_EXPOSURE_MANUAL</constant> </entry> + <entry>Manual exposure time, manual iris.</entry> + </row> + <row> + <entry><constant>V4L2_EXPOSURE_SHUTTER_PRIORITY</constant> </entry> + <entry>Manual exposure time, auto iris.</entry> + </row> + <row> + <entry><constant>V4L2_EXPOSURE_APERTURE_PRIORITY</constant> </entry> + <entry>Auto exposure time, manual iris.</entry> + </row> + </tbody> + </entrytbl> + </row> + <row><entry></entry></row> + + <row> + <entry spanname="id"><constant>V4L2_CID_EXPOSURE_ABSOLUTE</constant> </entry> + <entry>integer</entry> + </row><row><entry spanname="descr">Determines the exposure +time of the camera sensor. The exposure time is limited by the frame +interval. Drivers should interpret the values as 100 µs units, +where the value 1 stands for 1/10000th of a second, 10000 for 1 second +and 100000 for 10 seconds.</entry> + </row> + <row><entry></entry></row> + + <row> + <entry spanname="id"><constant>V4L2_CID_EXPOSURE_AUTO_PRIORITY</constant> </entry> + <entry>boolean</entry> + </row><row><entry spanname="descr">When +<constant>V4L2_CID_EXPOSURE_AUTO</constant> is set to +<constant>AUTO</constant> or <constant>APERTURE_PRIORITY</constant>, +this control determines if the device may dynamically vary the frame +rate. By default this feature is disabled (0) and the frame rate must +remain constant.</entry> + </row> + <row><entry></entry></row> + + <row> + <entry spanname="id"><constant>V4L2_CID_PAN_RELATIVE</constant> </entry> + <entry>integer</entry> + </row><row><entry spanname="descr">This control turns the +camera horizontally by the specified amount. The unit is undefined. A +positive value moves the camera to the right (clockwise when viewed +from above), a negative value to the left. A value of zero does not +cause motion. This is a write-only control.</entry> + </row> + <row><entry></entry></row> + + <row> + <entry spanname="id"><constant>V4L2_CID_TILT_RELATIVE</constant> </entry> + <entry>integer</entry> + </row><row><entry spanname="descr">This control turns the +camera vertically by the specified amount. The unit is undefined. A +positive value moves the camera up, a negative value down. A value of +zero does not cause motion. This is a write-only control.</entry> + </row> + <row><entry></entry></row> + + <row> + <entry spanname="id"><constant>V4L2_CID_PAN_RESET</constant> </entry> + <entry>button</entry> + </row><row><entry spanname="descr">When this control is set, +the camera moves horizontally to the default position.</entry> + </row> + <row><entry></entry></row> + + <row> + <entry spanname="id"><constant>V4L2_CID_TILT_RESET</constant> </entry> + <entry>button</entry> + </row><row><entry spanname="descr">When this control is set, +the camera moves vertically to the default position.</entry> + </row> + <row><entry></entry></row> + + <row> + <entry spanname="id"><constant>V4L2_CID_PAN_ABSOLUTE</constant> </entry> + <entry>integer</entry> + </row><row><entry spanname="descr">This control +turns the camera horizontally to the specified position. Positive +values move the camera to the right (clockwise when viewed from above), +negative values to the left. Drivers should interpret the values as arc +seconds, with valid values between -180 * 3600 and +180 * 3600 +inclusive.</entry> + </row> + <row><entry></entry></row> + + <row> + <entry spanname="id"><constant>V4L2_CID_TILT_ABSOLUTE</constant> </entry> + <entry>integer</entry> + </row><row><entry spanname="descr">This control +turns the camera vertically to the specified position. Positive values +move the camera up, negative values down. Drivers should interpret the +values as arc seconds, with valid values between -180 * 3600 and +180 +* 3600 inclusive.</entry> + </row> + <row><entry></entry></row> + + <row> + <entry spanname="id"><constant>V4L2_CID_FOCUS_ABSOLUTE</constant> </entry> + <entry>integer</entry> + </row><row><entry spanname="descr">This control sets the +focal point of the camera to the specified position. The unit is +undefined. Positive values set the focus closer to the camera, +negative values towards infinity.</entry> + </row> + <row><entry></entry></row> + + <row> + <entry spanname="id"><constant>V4L2_CID_FOCUS_RELATIVE</constant> </entry> + <entry>integer</entry> + </row><row><entry spanname="descr">This control moves the +focal point of the camera by the specified amount. The unit is +undefined. Positive values move the focus closer to the camera, +negative values towards infinity. This is a write-only control.</entry> + </row> + <row><entry></entry></row> + + <row> + <entry spanname="id"><constant>V4L2_CID_FOCUS_AUTO</constant> </entry> + <entry>boolean</entry> + </row><row><entry spanname="descr">Enables automatic focus +adjustments. The effect of manual focus adjustments while this feature +is enabled is undefined, drivers should ignore such requests.</entry> + </row> + <row><entry></entry></row> + + <row> + <entry spanname="id"><constant>V4L2_CID_ZOOM_ABSOLUTE</constant> </entry> + <entry>integer</entry> + </row><row><entry spanname="descr">Specify the objective lens +focal length as an absolute value. The zoom unit is driver-specific and its +value should be a positive integer.</entry> + </row> + <row><entry></entry></row> + + <row> + <entry spanname="id"><constant>V4L2_CID_ZOOM_RELATIVE</constant> </entry> + <entry>integer</entry> + </row><row><entry spanname="descr">Specify the objective lens +focal length relatively to the current value. Positive values move the zoom +lens group towards the telephoto direction, negative values towards the +wide-angle direction. The zoom unit is driver-specific. This is a write-only control.</entry> + </row> + <row><entry></entry></row> + + <row> + <entry spanname="id"><constant>V4L2_CID_ZOOM_CONTINUOUS</constant> </entry> + <entry>integer</entry> + </row><row><entry spanname="descr">Move the objective lens group +at the specified speed until it reaches physical device limits or until an +explicit request to stop the movement. A positive value moves the zoom lens +group towards the telephoto direction. A value of zero stops the zoom lens +group movement. A negative value moves the zoom lens group towards the +wide-angle direction. The zoom speed unit is driver-specific.</entry> + </row> + <row><entry></entry></row> + + <row> + <entry spanname="id"><constant>V4L2_CID_PRIVACY</constant> </entry> + <entry>boolean</entry> + </row><row><entry spanname="descr">Prevent video from being acquired +by the camera. When this control is set to <constant>TRUE</constant> (1), no +image can be captured by the camera. Common means to enforce privacy are +mechanical obturation of the sensor and firmware image processing, but the +device is not restricted to these methods. Devices that implement the privacy +control must support read access and may support write access.</entry> + </row> + + <row> + <entry spanname="id"><constant>V4L2_CID_BAND_STOP_FILTER</constant> </entry> + <entry>integer</entry> + </row><row><entry spanname="descr">Switch the band-stop filter of a +camera sensor on or off, or specify its strength. Such band-stop filters can +be used, for example, to filter out the fluorescent light component.</entry> + </row> + <row><entry></entry></row> + </tbody> + </tgroup> + </table> + </section> + + <section id="fm-tx-controls"> + <title>FM Transmitter Control Reference</title> + + <para>The FM Transmitter (FM_TX) class includes controls for common features of +FM transmissions capable devices. Currently this class includes parameters for audio +compression, pilot tone generation, audio deviation limiter, RDS transmission and +tuning power features.</para> + + <table pgwide="1" frame="none" id="fm-tx-control-id"> + <title>FM_TX Control IDs</title> + + <tgroup cols="4"> + <colspec colname="c1" colwidth="1*" /> + <colspec colname="c2" colwidth="6*" /> + <colspec colname="c3" colwidth="2*" /> + <colspec colname="c4" colwidth="6*" /> + <spanspec namest="c1" nameend="c2" spanname="id" /> + <spanspec namest="c2" nameend="c4" spanname="descr" /> + <thead> + <row> + <entry spanname="id" align="left">ID</entry> + <entry align="left">Type</entry> + </row><row rowsep="1"><entry spanname="descr" align="left">Description</entry> + </row> + </thead> + <tbody valign="top"> + <row><entry></entry></row> + <row> + <entry spanname="id"><constant>V4L2_CID_FM_TX_CLASS</constant> </entry> + <entry>class</entry> + </row><row><entry spanname="descr">The FM_TX class +descriptor. Calling &VIDIOC-QUERYCTRL; for this control will return a +description of this control class.</entry> + </row> + <row> + <entry spanname="id"><constant>V4L2_CID_RDS_TX_DEVIATION</constant> </entry> + <entry>integer</entry> + </row> + <row><entry spanname="descr">Configures RDS signal frequency deviation level in Hz. +The range and step are driver-specific.</entry> + </row> + <row> + <entry spanname="id"><constant>V4L2_CID_RDS_TX_PI</constant> </entry> + <entry>integer</entry> + </row> + <row><entry spanname="descr">Sets the RDS Programme Identification field +for transmission.</entry> + </row> + <row> + <entry spanname="id"><constant>V4L2_CID_RDS_TX_PTY</constant> </entry> + <entry>integer</entry> + </row> + <row><entry spanname="descr">Sets the RDS Programme Type field for transmission. +This encodes up to 31 pre-defined programme types.</entry> + </row> + <row> + <entry spanname="id"><constant>V4L2_CID_RDS_TX_PS_NAME</constant> </entry> + <entry>string</entry> + </row> + <row><entry spanname="descr">Sets the Programme Service name (PS_NAME) for transmission. +It is intended for static display on a receiver. It is the primary aid to listeners in programme service +identification and selection. In Annex E of <xref linkend="en50067" />, the RDS specification, +there is a full description of the correct character encoding for Programme Service name strings. +Also from RDS specification, PS is usually a single eight character text. However, it is also possible +to find receivers which can scroll strings sized as 8 x N characters. So, this control must be configured +with steps of 8 characters. The result is it must always contain a string with size multiple of 8.</entry> + </row> + <row> + <entry spanname="id"><constant>V4L2_CID_RDS_TX_RADIO_TEXT</constant> </entry> + <entry>string</entry> + </row> + <row><entry spanname="descr">Sets the Radio Text info for transmission. It is a textual description of +what is being broadcasted. RDS Radio Text can be applied when broadcaster wishes to transmit longer PS names, +programme-related information or any other text. In these cases, RadioText should be used in addition to +<constant>V4L2_CID_RDS_TX_PS_NAME</constant>. The encoding for Radio Text strings is also fully described +in Annex E of <xref linkend="en50067" />. The length of Radio Text strings depends on which RDS Block is being +used to transmit it, either 32 (2A block) or 64 (2B block). However, it is also possible +to find receivers which can scroll strings sized as 32 x N or 64 x N characters. So, this control must be configured +with steps of 32 or 64 characters. The result is it must always contain a string with size multiple of 32 or 64. </entry> + </row> + <row> + <entry spanname="id"><constant>V4L2_CID_AUDIO_LIMITER_ENABLED</constant> </entry> + <entry>boolean</entry> + </row> + <row><entry spanname="descr">Enables or disables the audio deviation limiter feature. +The limiter is useful when trying to maximize the audio volume, minimize receiver-generated +distortion and prevent overmodulation. +</entry> + </row> + <row> + <entry spanname="id"><constant>V4L2_CID_AUDIO_LIMITER_RELEASE_TIME</constant> </entry> + <entry>integer</entry> + </row> + <row><entry spanname="descr">Sets the audio deviation limiter feature release time. +Unit is in useconds. Step and range are driver-specific.</entry> + </row> + <row> + <entry spanname="id"><constant>V4L2_CID_AUDIO_LIMITER_DEVIATION</constant> </entry> + <entry>integer</entry> + </row> + <row><entry spanname="descr">Configures audio frequency deviation level in Hz. +The range and step are driver-specific.</entry> + </row> + <row> + <entry spanname="id"><constant>V4L2_CID_AUDIO_COMPRESSION_ENABLED</constant> </entry> + <entry>boolean</entry> + </row> + <row><entry spanname="descr">Enables or disables the audio compression feature. +This feature amplifies signals below the threshold by a fixed gain and compresses audio +signals above the threshold by the ratio of Threshold/(Gain + Threshold).</entry> + </row> + <row> + <entry spanname="id"><constant>V4L2_CID_AUDIO_COMPRESSION_GAIN</constant> </entry> + <entry>integer</entry> + </row> + <row><entry spanname="descr">Sets the gain for audio compression feature. It is +a dB value. The range and step are driver-specific.</entry> + </row> + <row> + <entry spanname="id"><constant>V4L2_CID_AUDIO_COMPRESSION_THRESHOLD</constant> </entry> + <entry>integer</entry> + </row> + <row><entry spanname="descr">Sets the threshold level for audio compression freature. +It is a dB value. The range and step are driver-specific.</entry> + </row> + <row> + <entry spanname="id"><constant>V4L2_CID_AUDIO_COMPRESSION_ATTACK_TIME</constant> </entry> + <entry>integer</entry> + </row> + <row><entry spanname="descr">Sets the attack time for audio compression feature. +It is a useconds value. The range and step are driver-specific.</entry> + </row> + <row> + <entry spanname="id"><constant>V4L2_CID_AUDIO_COMPRESSION_RELEASE_TIME</constant> </entry> + <entry>integer</entry> + </row> + <row><entry spanname="descr">Sets the release time for audio compression feature. +It is a useconds value. The range and step are driver-specific.</entry> + </row> + <row> + <entry spanname="id"><constant>V4L2_CID_PILOT_TONE_ENABLED</constant> </entry> + <entry>boolean</entry> + </row> + <row><entry spanname="descr">Enables or disables the pilot tone generation feature.</entry> + </row> + <row> + <entry spanname="id"><constant>V4L2_CID_PILOT_TONE_DEVIATION</constant> </entry> + <entry>integer</entry> + </row> + <row><entry spanname="descr">Configures pilot tone frequency deviation level. Unit is +in Hz. The range and step are driver-specific.</entry> + </row> + <row> + <entry spanname="id"><constant>V4L2_CID_PILOT_TONE_FREQUENCY</constant> </entry> + <entry>integer</entry> + </row> + <row><entry spanname="descr">Configures pilot tone frequency value. Unit is +in Hz. The range and step are driver-specific.</entry> + </row> + <row> + <entry spanname="id"><constant>V4L2_CID_TUNE_PREEMPHASIS</constant> </entry> + <entry>integer</entry> + </row> + <row id="v4l2-preemphasis"><entry spanname="descr">Configures the pre-emphasis value for broadcasting. +A pre-emphasis filter is applied to the broadcast to accentuate the high audio frequencies. +Depending on the region, a time constant of either 50 or 75 useconds is used. The enum v4l2_preemphasis +defines possible values for pre-emphasis. Here they are:</entry> + </row><row> + <entrytbl spanname="descr" cols="2"> + <tbody valign="top"> + <row> + <entry><constant>V4L2_PREEMPHASIS_DISABLED</constant> </entry> + <entry>No pre-emphasis is applied.</entry> + </row> + <row> + <entry><constant>V4L2_PREEMPHASIS_50_uS</constant> </entry> + <entry>A pre-emphasis of 50 uS is used.</entry> + </row> + <row> + <entry><constant>V4L2_PREEMPHASIS_75_uS</constant> </entry> + <entry>A pre-emphasis of 75 uS is used.</entry> + </row> + </tbody> + </entrytbl> + + </row> + <row> + <entry spanname="id"><constant>V4L2_CID_TUNE_POWER_LEVEL</constant> </entry> + <entry>integer</entry> + </row> + <row><entry spanname="descr">Sets the output power level for signal transmission. +Unit is in dBuV. Range and step are driver-specific.</entry> + </row> + <row> + <entry spanname="id"><constant>V4L2_CID_TUNE_ANTENNA_CAPACITOR</constant> </entry> + <entry>integer</entry> + </row> + <row><entry spanname="descr">This selects the value of antenna tuning capacitor +manually or automatically if set to zero. Unit, range and step are driver-specific.</entry> + </row> + <row><entry></entry></row> + </tbody> + </tgroup> + </table> + +<para>For more details about RDS specification, refer to +<xref linkend="en50067" /> document, from CENELEC.</para> + </section> +</section> + + <!-- +Local Variables: +mode: sgml +sgml-parent-document: "common.sgml" +indent-tabs-mode: nil +End: + --> diff --git a/Documentation/DocBook/v4l/crop.gif b/Documentation/DocBook/v4l/crop.gif Binary files differnew file mode 100644 index 000000000000..3b9e7d836d4b --- /dev/null +++ b/Documentation/DocBook/v4l/crop.gif diff --git a/Documentation/DocBook/v4l/crop.pdf b/Documentation/DocBook/v4l/crop.pdf Binary files differnew file mode 100644 index 000000000000..c9fb81cd32f3 --- /dev/null +++ b/Documentation/DocBook/v4l/crop.pdf diff --git a/Documentation/DocBook/v4l/dev-capture.xml b/Documentation/DocBook/v4l/dev-capture.xml new file mode 100644 index 000000000000..32807e43f170 --- /dev/null +++ b/Documentation/DocBook/v4l/dev-capture.xml @@ -0,0 +1,115 @@ + <title>Video Capture Interface</title> + + <para>Video capture devices sample an analog video signal and store +the digitized images in memory. Today nearly all devices can capture +at full 25 or 30 frames/second. With this interface applications can +control the capture process and move images from the driver into user +space.</para> + + <para>Conventionally V4L2 video capture devices are accessed through +character device special files named <filename>/dev/video</filename> +and <filename>/dev/video0</filename> to +<filename>/dev/video63</filename> with major number 81 and minor +numbers 0 to 63. <filename>/dev/video</filename> is typically a +symbolic link to the preferred video device. Note the same device +files are used for video output devices.</para> + + <section> + <title>Querying Capabilities</title> + + <para>Devices supporting the video capture interface set the +<constant>V4L2_CAP_VIDEO_CAPTURE</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> +(<constant>V4L2_CAP_VIDEO_OVERLAY</constant>) and the <link +linkend="raw-vbi">raw VBI capture</link> +(<constant>V4L2_CAP_VBI_CAPTURE</constant>) interface. At least one of +the read/write or streaming I/O methods must be supported. Tuners and +audio inputs are optional.</para> + </section> + + <section> + <title>Supplemental Functions</title> + + <para>Video capture devices shall support <link +linkend="audio">audio input</link>, <link +linkend="tuner">tuner</link>, <link linkend="control">controls</link>, +<link linkend="crop">cropping and scaling</link> and <link +linkend="streaming-par">streaming parameter</link> ioctls as needed. +The <link linkend="video">video input</link> and <link +linkend="standard">video standard</link> ioctls must be supported by +all video capture devices.</para> + </section> + + <section> + <title>Image Format Negotiation</title> + + <para>The result of a capture operation is determined by +cropping and image format parameters. The former select an area of the +video picture to capture, the latter how images are stored in memory, +&ie; in RGB or YUV format, the number of bits per pixel or width and +height. Together they also define how images are scaled in the +process.</para> + + <para>As usual these parameters are <emphasis>not</emphasis> reset +at &func-open; time to permit Unix tool chains, programming a device +and then reading from it as if it was a plain file. Well written V4L2 +applications ensure they really get what they want, including cropping +and scaling.</para> + + <para>Cropping initialization at minimum requires to reset the +parameters to defaults. An example is given in <xref +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 +&VIDIOC-G-FMT; ioctl with a pointer to this structure. Drivers fill +the &v4l2-pix-format; <structfield>pix</structfield> member of the +<structfield>fmt</structfield> union.</para> + + <para>To request different parameters applications set the +<structfield>type</structfield> field of a &v4l2-format; as above and +initialize all fields of the &v4l2-pix-format; +<structfield>vbi</structfield> member of the +<structfield>fmt</structfield> union, or better just modify the +results of <constant>VIDIOC_G_FMT</constant>, and call the +&VIDIOC-S-FMT; ioctl with a pointer to this structure. Drivers may +adjust the parameters and finally return the actual parameters as +<constant>VIDIOC_G_FMT</constant> does.</para> + + <para>Like <constant>VIDIOC_S_FMT</constant> the +&VIDIOC-TRY-FMT; ioctl can be used to learn about hardware limitations +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 +<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 +<constant>VIDIOC_G_FMT</constant> and +<constant>VIDIOC_S_FMT</constant> ioctl, even if +<constant>VIDIOC_S_FMT</constant> ignores all requests and always +returns default parameters as <constant>VIDIOC_G_FMT</constant> does. +<constant>VIDIOC_TRY_FMT</constant> is optional.</para> + </section> + + <section> + <title>Reading Images</title> + + <para>A video capture device may support the <link +linkend="rw">read() function</link> and/or streaming (<link +linkend="mmap">memory mapping</link> or <link +linkend="userp">user pointer</link>) I/O. See <xref +linkend="io" /> for details.</para> + </section> + + <!-- +Local Variables: +mode: sgml +sgml-parent-document: "v4l2.sgml" +indent-tabs-mode: nil +End: + --> diff --git a/Documentation/DocBook/v4l/dev-codec.xml b/Documentation/DocBook/v4l/dev-codec.xml new file mode 100644 index 000000000000..6e156dc45b94 --- /dev/null +++ b/Documentation/DocBook/v4l/dev-codec.xml @@ -0,0 +1,26 @@ + <title>Codec Interface</title> + + <note> + <title>Suspended</title> + + <para>This interface has been be suspended from the V4L2 API +implemented in Linux 2.6 until we have more experience with codec +device interfaces.</para> + </note> + + <para>A V4L2 codec can compress, decompress, transform, or otherwise +convert video data from one format into another format, in memory. +Applications send data to be converted to the driver through a +&func-write; call, and receive the converted data through a +&func-read; call. For efficiency a driver may also support streaming +I/O.</para> + + <para>[to do]</para> + + <!-- +Local Variables: +mode: sgml +sgml-parent-document: "v4l2.sgml" +indent-tabs-mode: nil +End: + --> diff --git a/Documentation/DocBook/v4l/dev-effect.xml b/Documentation/DocBook/v4l/dev-effect.xml new file mode 100644 index 000000000000..9c243beba0e6 --- /dev/null +++ b/Documentation/DocBook/v4l/dev-effect.xml @@ -0,0 +1,25 @@ + <title>Effect Devices Interface</title> + + <note> + <title>Suspended</title> + + <para>This interface has been be suspended from the V4L2 API +implemented in Linux 2.6 until we have more experience with effect +device interfaces.</para> + </note> + + <para>A V4L2 video effect device can do image effects, filtering, or +combine two or more images or image streams. For example video +transitions or wipes. Applications send data to be processed and +receive the result data either with &func-read; and &func-write; +functions, or through the streaming I/O mechanism.</para> + + <para>[to do]</para> + + <!-- +Local Variables: +mode: sgml +sgml-parent-document: "v4l2.sgml" +indent-tabs-mode: nil +End: + --> diff --git a/Documentation/DocBook/v4l/dev-osd.xml b/Documentation/DocBook/v4l/dev-osd.xml new file mode 100644 index 000000000000..c9a68a2ccd33 --- /dev/null +++ b/Documentation/DocBook/v4l/dev-osd.xml @@ -0,0 +1,164 @@ + <title>Video Output Overlay Interface</title> + <subtitle>Also known as On-Screen Display (OSD)</subtitle> + + <note> + <title>Experimental</title> + + <para>This is an <link linkend="experimental">experimental</link> +interface and may change in the future.</para> + </note> + + <para>Some video output devices can overlay a framebuffer image onto +the outgoing video signal. Applications can set up such an overlay +using this interface, which borrows structures and ioctls of the <link +linkend="overlay">Video Overlay</link> interface.</para> + + <para>The OSD function is accessible through the same character +special file as the <link linkend="capture">Video Output</link> function. +Note the default function of such a <filename>/dev/video</filename> device +is video capturing or output. The OSD function is only available after +calling the &VIDIOC-S-FMT; ioctl.</para> + + <section> + <title>Querying Capabilities</title> + + <para>Devices supporting the <wordasword>Video Output +Overlay</wordasword> interface set the +<constant>V4L2_CAP_VIDEO_OUTPUT_OVERLAY</constant> flag in the +<structfield>capabilities</structfield> field of &v4l2-capability; +returned by the &VIDIOC-QUERYCAP; ioctl.</para> + </section> + + <section> + <title>Framebuffer</title> + + <para>Contrary to the <wordasword>Video Overlay</wordasword> +interface the framebuffer is normally implemented on the TV card and +not the graphics card. On Linux it is accessible as a framebuffer +device (<filename>/dev/fbN</filename>). Given a V4L2 device, +applications can find the corresponding framebuffer device by calling +the &VIDIOC-G-FBUF; ioctl. It returns, amongst other information, the +physical address of the framebuffer in the +<structfield>base</structfield> field of &v4l2-framebuffer;. The +framebuffer device ioctl <constant>FBIOGET_FSCREENINFO</constant> +returns the same address in the <structfield>smem_start</structfield> +field of struct <structname>fb_fix_screeninfo</structname>. The +<constant>FBIOGET_FSCREENINFO</constant> ioctl and struct +<structname>fb_fix_screeninfo</structname> are defined in the +<filename>linux/fb.h</filename> header file.</para> + + <para>The width and height of the framebuffer depends on the +current video standard. A V4L2 driver may reject attempts to change +the video standard (or any other ioctl which would imply a framebuffer +size change) with an &EBUSY; until all applications closed the +framebuffer device.</para> + + <example> + <title>Finding a framebuffer device for OSD</title> + + <programlisting> +#include <linux/fb.h> + +&v4l2-framebuffer; fbuf; +unsigned int i; +int fb_fd; + +if (-1 == ioctl (fd, VIDIOC_G_FBUF, &fbuf)) { + perror ("VIDIOC_G_FBUF"); + exit (EXIT_FAILURE); +} + +for (i = 0; i > 30; ++i) { + char dev_name[16]; + struct fb_fix_screeninfo si; + + snprintf (dev_name, sizeof (dev_name), "/dev/fb%u", i); + + fb_fd = open (dev_name, O_RDWR); + if (-1 == fb_fd) { + switch (errno) { + case ENOENT: /* no such file */ + case ENXIO: /* no driver */ + continue; + + default: + perror ("open"); + exit (EXIT_FAILURE); + } + } + + if (0 == ioctl (fb_fd, FBIOGET_FSCREENINFO, &si)) { + if (si.smem_start == (unsigned long) fbuf.base) + break; + } else { + /* Apparently not a framebuffer device. */ + } + + close (fb_fd); + fb_fd = -1; +} + +/* fb_fd is the file descriptor of the framebuffer device + for the video output overlay, or -1 if no device was found. */ +</programlisting> + </example> + </section> + + <section> + <title>Overlay Window and Scaling</title> + + <para>The overlay is controlled by source and target rectangles. +The source rectangle selects a subsection of the framebuffer image to +be overlaid, the target rectangle an area in the outgoing video signal +where the image will appear. Drivers may or may not support scaling, +and arbitrary sizes and positions of these rectangles. Further drivers +may support any (or none) of the clipping/blending methods defined for +the <link linkend="overlay">Video Overlay</link> interface.</para> + + <para>A &v4l2-window; defines the size of the source rectangle, +its position in the framebuffer and the clipping/blending method to be +used for the overlay. To get the current parameters applications set +the <structfield>type</structfield> field of a &v4l2-format; to +<constant>V4L2_BUF_TYPE_VIDEO_OUTPUT_OVERLAY</constant> and call the +&VIDIOC-G-FMT; ioctl. The driver fills the +<structname>v4l2_window</structname> substructure named +<structfield>win</structfield>. It is not possible to retrieve a +previously programmed clipping list or bitmap.</para> + + <para>To program the source rectangle applications set the +<structfield>type</structfield> field of a &v4l2-format; to +<constant>V4L2_BUF_TYPE_VIDEO_OUTPUT_OVERLAY</constant>, initialize +the <structfield>win</structfield> substructure and call the +&VIDIOC-S-FMT; ioctl. The driver adjusts the parameters against +hardware limits and returns the actual parameters as +<constant>VIDIOC_G_FMT</constant> does. Like +<constant>VIDIOC_S_FMT</constant>, the &VIDIOC-TRY-FMT; ioctl can be +used to learn about driver capabilities without actually changing +driver state. Unlike <constant>VIDIOC_S_FMT</constant> this also works +after the overlay has been enabled.</para> + + <para>A &v4l2-crop; defines the size and position of the target +rectangle. The scaling factor of the overlay is implied by the width +and height given in &v4l2-window; and &v4l2-crop;. The cropping API +applies to <wordasword>Video Output</wordasword> and <wordasword>Video +Output Overlay</wordasword> devices in the same way as to +<wordasword>Video Capture</wordasword> and <wordasword>Video +Overlay</wordasword> devices, merely reversing the direction of the +data flow. For more information see <xref linkend="crop" />.</para> + </section> + + <section> + <title>Enabling Overlay</title> + + <para>There is no V4L2 ioctl to enable or disable the overlay, +however the framebuffer interface of the driver may support the +<constant>FBIOBLANK</constant> ioctl.</para> + </section> + + <!-- +Local Variables: +mode: sgml +sgml-parent-document: "v4l2.sgml" +indent-tabs-mode: nil +End: + --> diff --git a/Documentation/DocBook/v4l/dev-output.xml b/Documentation/DocBook/v4l/dev-output.xml new file mode 100644 index 000000000000..63c3c20e5a72 --- /dev/null +++ b/Documentation/DocBook/v4l/dev-output.xml @@ -0,0 +1,111 @@ + <title>Video Output Interface</title> + + <para>Video output devices encode stills or image sequences as +analog video signal. With this interface applications can +control the encoding process and move images from user space to +the driver.</para> + + <para>Conventionally V4L2 video output devices are accessed through +character device special files named <filename>/dev/video</filename> +and <filename>/dev/video0</filename> to +<filename>/dev/video63</filename> with major number 81 and minor +numbers 0 to 63. <filename>/dev/video</filename> is typically a +symbolic link to the preferred video device. Note the same device +files are used for video capture devices.</para> + + <section> + <title>Querying Capabilities</title> + + <para>Devices supporting the video output interface set the +<constant>V4L2_CAP_VIDEO_OUTPUT</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 +output</link> (<constant>V4L2_CAP_VBI_OUTPUT</constant>) interface. At +least one of the read/write or streaming I/O methods must be +supported. Modulators and audio outputs are optional.</para> + </section> + + <section> + <title>Supplemental Functions</title> + + <para>Video output devices shall support <link +linkend="audio">audio output</link>, <link +linkend="tuner">modulator</link>, <link linkend="control">controls</link>, +<link linkend="crop">cropping and scaling</link> and <link +linkend="streaming-par">streaming parameter</link> ioctls as needed. +The <link linkend="video">video output</link> and <link +linkend="standard">video standard</link> ioctls must be supported by +all video output devices.</para> + </section> + + <section> + <title>Image Format Negotiation</title> + + <para>The output is determined by cropping and image format +parameters. The former select an area of the video picture where the +image will appear, the latter how images are stored in memory, &ie; in +RGB or YUV format, the number of bits per pixel or width and height. +Together they also define how images are scaled in the process.</para> + + <para>As usual these parameters are <emphasis>not</emphasis> reset +at &func-open; time to permit Unix tool chains, programming a device +and then writing to it as if it was a plain file. Well written V4L2 +applications ensure they really get what they want, including cropping +and scaling.</para> + + <para>Cropping initialization at minimum requires to reset the +parameters to defaults. An example is given in <xref +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 +&VIDIOC-G-FMT; ioctl with a pointer to this structure. Drivers fill +the &v4l2-pix-format; <structfield>pix</structfield> member of the +<structfield>fmt</structfield> union.</para> + + <para>To request different parameters applications set the +<structfield>type</structfield> field of a &v4l2-format; as above and +initialize all fields of the &v4l2-pix-format; +<structfield>vbi</structfield> member of the +<structfield>fmt</structfield> union, or better just modify the +results of <constant>VIDIOC_G_FMT</constant>, and call the +&VIDIOC-S-FMT; ioctl with a pointer to this structure. Drivers may +adjust the parameters and finally return the actual parameters as +<constant>VIDIOC_G_FMT</constant> does.</para> + + <para>Like <constant>VIDIOC_S_FMT</constant> the +&VIDIOC-TRY-FMT; ioctl can be used to learn about hardware limitations +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 +<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 +<constant>VIDIOC_G_FMT</constant> and +<constant>VIDIOC_S_FMT</constant> ioctl, even if +<constant>VIDIOC_S_FMT</constant> ignores all requests and always +returns default parameters as <constant>VIDIOC_G_FMT</constant> does. +<constant>VIDIOC_TRY_FMT</constant> is optional.</para> + </section> + + <section> + <title>Writing Images</title> + + <para>A video output device may support the <link +linkend="rw">write() function</link> and/or streaming (<link +linkend="mmap">memory mapping</link> or <link +linkend="userp">user pointer</link>) I/O. See <xref +linkend="io" /> for details.</para> + </section> + + <!-- +Local Variables: +mode: sgml +sgml-parent-document: "v4l2.sgml" +indent-tabs-mode: nil +End: + --> diff --git a/Documentation/DocBook/v4l/dev-overlay.xml b/Documentation/DocBook/v4l/dev-overlay.xml new file mode 100644 index 000000000000..92513cf79150 --- /dev/null +++ b/Documentation/DocBook/v4l/dev-overlay.xml @@ -0,0 +1,379 @@ + <title>Video Overlay Interface</title> + <subtitle>Also known as Framebuffer Overlay or Previewing</subtitle> + + <para>Video overlay devices have the ability to genlock (TV-)video +into the (VGA-)video signal of a graphics card, or to store captured +images directly in video memory of a graphics card, typically with +clipping. This can be considerable more efficient than capturing +images and displaying them by other means. In the old days when only +nuclear power plants needed cooling towers this used to be the only +way to put live video into a window.</para> + + <para>Video overlay devices are accessed through the same character +special files as <link linkend="capture">video capture</link> devices. +Note the default function of a <filename>/dev/video</filename> device +is video capturing. The overlay function is only available after +calling the &VIDIOC-S-FMT; ioctl.</para> + + <para>The driver may support simultaneous overlay and capturing +using the read/write and streaming I/O methods. If so, operation at +the nominal frame rate of the video standard is not guaranteed. Frames +may be directed away from overlay to capture, or one field may be used +for overlay and the other for capture if the capture parameters permit +this.</para> + + <para>Applications should use different file descriptors for +capturing and overlay. This must be supported by all drivers capable +of simultaneous capturing and overlay. Optionally these drivers may +also permit capturing and overlay with a single file descriptor for +compatibility with V4L and earlier versions of V4L2.<footnote> + <para>A common application of two file descriptors is the +XFree86 <link linkend="xvideo">Xv/V4L</link> interface driver and +a V4L2 application. While the X server controls video overlay, the +application can take advantage of memory mapping and DMA.</para> + <para>In the opinion of the designers of this API, no driver +writer taking the efforts to support simultaneous capturing and +overlay will restrict this ability by requiring a single file +descriptor, as in V4L and earlier versions of V4L2. Making this +optional means applications depending on two file descriptors need +backup routines to be compatible with all drivers, which is +considerable more work than using two fds in applications which do +not. Also two fd's fit the general concept of one file descriptor for +each logical stream. Hence as a complexity trade-off drivers +<emphasis>must</emphasis> support two file descriptors and +<emphasis>may</emphasis> support single fd operation.</para> + </footnote></para> + + <section> + <title>Querying Capabilities</title> + + <para>Devices supporting the video overlay interface set the +<constant>V4L2_CAP_VIDEO_OVERLAY</constant> flag in the +<structfield>capabilities</structfield> field of &v4l2-capability; +returned by the &VIDIOC-QUERYCAP; ioctl. The overlay I/O method specified +below must be supported. Tuners and audio inputs are optional.</para> + </section> + + <section> + <title>Supplemental Functions</title> + + <para>Video overlay devices shall support <link +linkend="audio">audio input</link>, <link +linkend="tuner">tuner</link>, <link linkend="control">controls</link>, +<link linkend="crop">cropping and scaling</link> and <link +linkend="streaming-par">streaming parameter</link> ioctls as needed. +The <link linkend="video">video input</link> and <link +linkend="standard">video standard</link> ioctls must be supported by +all video overlay devices.</para> + </section> + + <section> + <title>Setup</title> + + <para>Before overlay can commence applications must program the +driver with frame buffer parameters, namely the address and size of +the frame buffer and the image format, for example RGB 5:6:5. The +&VIDIOC-G-FBUF; and &VIDIOC-S-FBUF; ioctls are available to get +and set these parameters, respectively. The +<constant>VIDIOC_S_FBUF</constant> ioctl is privileged because it +allows to set up DMA into physical memory, bypassing the memory +protection mechanisms of the kernel. Only the superuser can change the +frame buffer address and size. Users are not supposed to run TV +applications as root or with SUID bit set. A small helper application +with suitable privileges should query the graphics system and program +the V4L2 driver at the appropriate time.</para> + + <para>Some devices add the video overlay to the output signal +of the graphics card. In this case the frame buffer is not modified by +the video device, and the frame buffer address and pixel format are +not needed by the driver. The <constant>VIDIOC_S_FBUF</constant> ioctl +is not privileged. An application can check for this type of device by +calling the <constant>VIDIOC_G_FBUF</constant> ioctl.</para> + + <para>A driver may support any (or none) of five clipping/blending +methods:<orderedlist> + <listitem> + <para>Chroma-keying displays the overlaid image only where +pixels in the primary graphics surface assume a certain color.</para> + </listitem> + <listitem> + <para>A bitmap can be specified where each bit corresponds +to a pixel in the overlaid image. When the bit is set, the +corresponding video pixel is displayed, otherwise a pixel of the +graphics surface.</para> + </listitem> + <listitem> + <para>A list of clipping rectangles can be specified. In +these regions <emphasis>no</emphasis> video is displayed, so the +graphics surface can be seen here.</para> + </listitem> + <listitem> + <para>The framebuffer has an alpha channel that can be used +to clip or blend the framebuffer with the video.</para> + </listitem> + <listitem> + <para>A global alpha value can be specified to blend the +framebuffer contents with video images.</para> + </listitem> + </orderedlist></para> + + <para>When simultaneous capturing and overlay is supported and +the hardware prohibits different image and frame buffer formats, the +format requested first takes precedence. The attempt to capture +(&VIDIOC-S-FMT;) or overlay (&VIDIOC-S-FBUF;) may fail with an +&EBUSY; or return accordingly modified parameters..</para> + </section> + + <section> + <title>Overlay Window</title> + + <para>The overlaid image is determined by cropping and overlay +window parameters. The former select an area of the video picture to +capture, the latter how images are overlaid and clipped. Cropping +initialization at minimum requires to reset the parameters to +defaults. An example is given in <xref linkend="crop" />.</para> + + <para>The overlay window is described by a &v4l2-window;. It +defines the size of the image, its position over the graphics surface +and the clipping to be applied. To get the current parameters +applications set the <structfield>type</structfield> field of a +&v4l2-format; to <constant>V4L2_BUF_TYPE_VIDEO_OVERLAY</constant> and +call the &VIDIOC-G-FMT; ioctl. The driver fills the +<structname>v4l2_window</structname> substructure named +<structfield>win</structfield>. It is not possible to retrieve a +previously programmed clipping list or bitmap.</para> + + <para>To program the overlay window applications set the +<structfield>type</structfield> field of a &v4l2-format; to +<constant>V4L2_BUF_TYPE_VIDEO_OVERLAY</constant>, initialize the +<structfield>win</structfield> substructure and call the +&VIDIOC-S-FMT; ioctl. The driver adjusts the parameters against +hardware limits and returns the actual parameters as +<constant>VIDIOC_G_FMT</constant> does. Like +<constant>VIDIOC_S_FMT</constant>, the &VIDIOC-TRY-FMT; ioctl can be +used to learn about driver capabilities without actually changing +driver state. Unlike <constant>VIDIOC_S_FMT</constant> this also works +after the overlay has been enabled.</para> + + <para>The scaling factor of the overlaid image is implied by the +width and height given in &v4l2-window; and the size of the cropping +rectangle. For more information see <xref linkend="crop" />.</para> + + <para>When simultaneous capturing and overlay is supported and +the hardware prohibits different image and window sizes, the size +requested first takes precedence. The attempt to capture or overlay as +well (&VIDIOC-S-FMT;) may fail with an &EBUSY; or return accordingly +modified parameters.</para> + + <table pgwide="1" frame="none" id="v4l2-window"> + <title>struct <structname>v4l2_window</structname></title> + <tgroup cols="3"> + &cs-str; + <tbody valign="top"> + <row> + <entry>&v4l2-rect;</entry> + <entry><structfield>w</structfield></entry> + <entry>Size and position of the window relative to the +top, left corner of the frame buffer defined with &VIDIOC-S-FBUF;. The +window can extend the frame buffer width and height, the +<structfield>x</structfield> and <structfield>y</structfield> +coordinates can be negative, and it can lie completely outside the +frame buffer. The driver clips the window accordingly, or if that is +not possible, modifies its size and/or position.</entry> + </row> + <row> + <entry>&v4l2-field;</entry> + <entry><structfield>field</structfield></entry> + <entry>Applications set this field to determine which +video field shall be overlaid, typically one of +<constant>V4L2_FIELD_ANY</constant> (0), +<constant>V4L2_FIELD_TOP</constant>, +<constant>V4L2_FIELD_BOTTOM</constant> or +<constant>V4L2_FIELD_INTERLACED</constant>. Drivers may have to choose +a different field order and return the actual setting here.</entry> + </row> + <row> + <entry>__u32</entry> + <entry><structfield>chromakey</structfield></entry> + <entry>When chroma-keying has been negotiated with +&VIDIOC-S-FBUF; applications set this field to the desired pixel value +for the chroma key. The format is the same as the pixel format of the +framebuffer (&v4l2-framebuffer; +<structfield>fmt.pixelformat</structfield> field), with bytes in host +order. E. g. for <link +linkend="V4L2-PIX-FMT-BGR32"><constant>V4L2_PIX_FMT_BGR24</constant></link> +the value should be 0xRRGGBB on a little endian, 0xBBGGRR on a big +endian host.</entry> + </row> + <row> + <entry>&v4l2-clip; *</entry> + <entry><structfield>clips</structfield></entry> + <entry>When chroma-keying has <emphasis>not</emphasis> +been negotiated and &VIDIOC-G-FBUF; indicated this capability, +applications can set this field to point to an array of +clipping rectangles.</entry> + </row> + <row> + <entry></entry> + <entry></entry> + <entry>Like the window coordinates +<structfield>w</structfield>, clipping rectangles are defined relative +to the top, left corner of the frame buffer. However clipping +rectangles must not extend the frame buffer width and height, and they +must not overlap. If possible applications should merge adjacent +rectangles. Whether this must create x-y or y-x bands, or the order of +rectangles, is not defined. When clip lists are not supported the +driver ignores this field. Its contents after calling &VIDIOC-S-FMT; +are undefined.</entry> + </row> + <row> + <entry>__u32</entry> + <entry><structfield>clipcount</structfield></entry> + <entry>When the application set the +<structfield>clips</structfield> field, this field must contain the +number of clipping rectangles in the list. When clip lists are not +supported the driver ignores this field, its contents after calling +<constant>VIDIOC_S_FMT</constant> are undefined. When clip lists are +supported but no clipping is desired this field must be set to +zero.</entry> + </row> + <row> + <entry>void *</entry> + <entry><structfield>bitmap</structfield></entry> + <entry>When chroma-keying has +<emphasis>not</emphasis> been negotiated and &VIDIOC-G-FBUF; indicated +this capability, applications can set this field to point to a +clipping bit mask.</entry> + </row> + <row> + <entry spanname="hspan"><para>It must be of the same size +as the window, <structfield>w.width</structfield> and +<structfield>w.height</structfield>. Each bit corresponds to a pixel +in the overlaid image, which is displayed only when the bit is +<emphasis>set</emphasis>. Pixel coordinates translate to bits like: +<programlisting> +((__u8 *) <structfield>bitmap</structfield>)[<structfield>w.width</structfield> * y + x / 8] & (1 << (x & 7))</programlisting></para><para>where <structfield>0</structfield> ≤ x < +<structfield>w.width</structfield> and <structfield>0</structfield> ≤ +y <<structfield>w.height</structfield>.<footnote> + <para>Should we require + <structfield>w.width</structfield> to be a multiple of + eight?</para> + </footnote></para><para>When a clipping +bit mask is not supported the driver ignores this field, its contents +after calling &VIDIOC-S-FMT; are undefined. When a bit mask is supported +but no clipping is desired this field must be set to +<constant>NULL</constant>.</para><para>Applications need not create a +clip list or bit mask. When they pass both, or despite negotiating +chroma-keying, the results are undefined. Regardless of the chosen +method, the clipping abilities of the hardware may be limited in +quantity or quality. The results when these limits are exceeded are +undefined.<footnote> + <para>When the image is written into frame buffer +memory it will be undesirable if the driver clips out less pixels +than expected, because the application and graphics system are not +aware these regions need to be refreshed. The driver should clip out +more pixels or not write the image at all.</para> + </footnote></para></entry> + </row> + <row> + <entry>__u8</entry> + <entry><structfield>global_alpha</structfield></entry> + <entry>The global alpha value used to blend the +framebuffer with video images, if global alpha blending has been +negotiated (<constant>V4L2_FBUF_FLAG_GLOBAL_ALPHA</constant>, see +&VIDIOC-S-FBUF;, <xref linkend="framebuffer-flags" />).</entry> + </row> + <row> + <entry></entry> + <entry></entry> + <entry>Note this field was added in Linux 2.6.23, extending the structure. However +the <link linkend="vidioc-g-fmt">VIDIOC_G/S/TRY_FMT</link> ioctls, +which take a pointer to a <link +linkend="v4l2-format">v4l2_format</link> parent structure with padding +bytes at the end, are not affected.</entry> + </row> + </tbody> + </tgroup> + </table> + + <table pgwide="1" frame="none" id="v4l2-clip"> + <title>struct <structname>v4l2_clip</structname><footnote> + <para>The X Window system defines "regions" which are +vectors of struct BoxRec { short x1, y1, x2, y2; } with width = x2 - +x1 and height = y2 - y1, so one cannot pass X11 clip lists +directly.</para> + </footnote></title> + <tgroup cols="3"> + &cs-str; + <tbody valign="top"> + <row> + <entry>&v4l2-rect;</entry> + <entry><structfield>c</structfield></entry> + <entry>Coordinates of the clipping rectangle, relative to +the top, left corner of the frame buffer. Only window pixels +<emphasis>outside</emphasis> all clipping rectangles are +displayed.</entry> + </row> + <row> + <entry>&v4l2-clip; *</entry> + <entry><structfield>next</structfield></entry> + <entry>Pointer to the next clipping rectangle, NULL when +this is the last rectangle. Drivers ignore this field, it cannot be +used to pass a linked list of clipping rectangles.</entry> + </row> + </tbody> + </tgroup> + </table> + + <!-- NB for easier reading this table is duplicated + in the vidioc-cropcap chapter.--> + + <table pgwide="1" frame="none" id="v4l2-rect"> + <title>struct <structname>v4l2_rect</structname></title> + <tgroup cols="3"> + &cs-str; + <tbody valign="top"> + <row> + <entry>__s32</entry> + <entry><structfield>left</structfield></entry> + <entry>Horizontal offset of the top, left corner of the +rectangle, in pixels.</entry> + </row> + <row> + <entry>__s32</entry> + <entry><structfield>top</structfield></entry> + <entry>Vertical offset of the top, left corner of the +rectangle, in pixels. Offsets increase to the right and down.</entry> + </row> + <row> + <entry>__s32</entry> + <entry><structfield>width</structfield></entry> + <entry>Width of the rectangle, in pixels.</entry> + </row> + <row> + <entry>__s32</entry> + <entry><structfield>height</structfield></entry> + <entry>Height of the rectangle, in pixels. Width and +height cannot be negative, the fields are signed for hysterical +reasons. <!-- video4linux-list@redhat.com on 22 Oct 2002 subject +"Re:[V4L][patches!] Re:v4l2/kernel-2.5" --></entry> + </row> + </tbody> + </tgroup> + </table> + </section> + + <section> + <title>Enabling Overlay</title> + + <para>To start or stop the frame buffer overlay applications call +the &VIDIOC-OVERLAY; ioctl.</para> + </section> + + <!-- +Local Variables: +mode: sgml +sgml-parent-document: "v4l2.sgml" +indent-tabs-mode: nil +End: + --> diff --git a/Documentation/DocBook/v4l/dev-radio.xml b/Documentation/DocBook/v4l/dev-radio.xml new file mode 100644 index 000000000000..73aa90b45b34 --- /dev/null +++ b/Documentation/DocBook/v4l/dev-radio.xml @@ -0,0 +1,57 @@ + <title>Radio Interface</title> + + <para>This interface is intended for AM and FM (analog) radio +receivers and transmitters.</para> + + <para>Conventionally V4L2 radio devices are accessed through +character device special files named <filename>/dev/radio</filename> +and <filename>/dev/radio0</filename> to +<filename>/dev/radio63</filename> with major number 81 and minor +numbers 64 to 127.</para> + + <section> + <title>Querying Capabilities</title> + + <para>Devices supporting the radio interface set the +<constant>V4L2_CAP_RADIO</constant> and +<constant>V4L2_CAP_TUNER</constant> or +<constant>V4L2_CAP_MODULATOR</constant> flag in the +<structfield>capabilities</structfield> field of &v4l2-capability; +returned by the &VIDIOC-QUERYCAP; ioctl. Other combinations of +capability flags are reserved for future extensions.</para> + </section> + + <section> + <title>Supplemental Functions</title> + + <para>Radio devices can support <link +linkend="control">controls</link>, and must support the <link +linkend="tuner">tuner or modulator</link> ioctls.</para> + + <para>They do not support the video input or output, audio input +or output, video standard, cropping and scaling, compression and +streaming parameter, or overlay ioctls. All other ioctls and I/O +methods are reserved for future extensions.</para> + </section> + + <section> + <title>Programming</title> + + <para>Radio devices may have a couple audio controls (as discussed +in <xref linkend="control" />) such as a volume control, possibly custom +controls. Further all radio devices have one tuner or modulator (these are +discussed in <xref linkend="tuner" />) with index number zero to select +the radio frequency and to determine if a monaural or FM stereo +program is received/emitted. Drivers switch automatically between AM and FM +depending on the selected frequency. The &VIDIOC-G-TUNER; or +&VIDIOC-G-MODULATOR; ioctl +reports the supported frequency range.</para> + </section> + +<!-- +Local Variables: +mode: sgml +sgml-parent-document: "v4l2.sgml" +indent-tabs-mode: nil +End: + --> diff --git a/Documentation/DocBook/v4l/dev-raw-vbi.xml b/Documentation/DocBook/v4l/dev-raw-vbi.xml new file mode 100644 index 000000000000..c5a70bdfaf27 --- /dev/null +++ b/Documentation/DocBook/v4l/dev-raw-vbi.xml @@ -0,0 +1,347 @@ + <title>Raw VBI Data Interface</title> + + <para>VBI is an abbreviation of Vertical Blanking Interval, a gap +in the sequence of lines of an analog video signal. During VBI +no picture information is transmitted, allowing some time while the +electron beam of a cathode ray tube TV returns to the top of the +screen. Using an oscilloscope you will find here the vertical +synchronization pulses and short data packages ASK +modulated<footnote><para>ASK: Amplitude-Shift Keying. A high signal +level represents a '1' bit, a low level a '0' bit.</para></footnote> +onto the video signal. These are transmissions of services such as +Teletext or Closed Caption.</para> + + <para>Subject of this interface type is raw VBI data, as sampled off +a video signal, or to be added to a signal for output. +The data format is similar to uncompressed video images, a number of +lines times a number of samples per line, we call this a VBI image.</para> + + <para>Conventionally V4L2 VBI devices are accessed through character +device special files named <filename>/dev/vbi</filename> and +<filename>/dev/vbi0</filename> to <filename>/dev/vbi31</filename> with +major number 81 and minor numbers 224 to 255. +<filename>/dev/vbi</filename> is typically a symbolic link to the +preferred VBI device. This convention applies to both input and output +devices.</para> + + <para>To address the problems of finding related video and VBI +devices VBI capturing and output is also available as device function +under <filename>/dev/video</filename>. To capture or output raw VBI +data with these devices applications must call the &VIDIOC-S-FMT; +ioctl. Accessed as <filename>/dev/vbi</filename>, raw VBI capturing +or output is the default device function.</para> + + <section> + <title>Querying Capabilities</title> + + <para>Devices supporting the raw VBI capturing or output API set +the <constant>V4L2_CAP_VBI_CAPTURE</constant> or +<constant>V4L2_CAP_VBI_OUTPUT</constant> flags, respectively, in the +<structfield>capabilities</structfield> field of &v4l2-capability; +returned by the &VIDIOC-QUERYCAP; ioctl. At least one of the +read/write, streaming or asynchronous I/O methods must be +supported. VBI devices may or may not have a tuner or modulator.</para> + </section> + + <section> + <title>Supplemental Functions</title> + + <para>VBI devices shall support <link linkend="video">video +input or output</link>, <link linkend="tuner">tuner or +modulator</link>, and <link linkend="control">controls</link> ioctls +as needed. The <link linkend="standard">video standard</link> ioctls provide +information vital to program a VBI device, therefore must be +supported.</para> + </section> + + <section> + <title>Raw VBI Format Negotiation</title> + + <para>Raw VBI sampling abilities can vary, in particular the +sampling frequency. To properly interpret the data V4L2 specifies an +ioctl to query the sampling parameters. Moreover, to allow for some +flexibility applications can also suggest different parameters.</para> + + <para>As usual these parameters are <emphasis>not</emphasis> +reset at &func-open; time to permit Unix tool chains, programming a +device and then reading from it as if it was a plain file. Well +written V4L2 applications should always ensure they really get what +they want, requesting reasonable parameters and then checking if the +actual parameters are suitable.</para> + + <para>To query the current raw VBI capture parameters +applications set the <structfield>type</structfield> field of a +&v4l2-format; to <constant>V4L2_BUF_TYPE_VBI_CAPTURE</constant> or +<constant>V4L2_BUF_TYPE_VBI_OUTPUT</constant>, and call the +&VIDIOC-G-FMT; ioctl with a pointer to this structure. Drivers fill +the &v4l2-vbi-format; <structfield>vbi</structfield> member of the +<structfield>fmt</structfield> union.</para> + + <para>To request different parameters applications set the +<structfield>type</structfield> field of a &v4l2-format; as above and +initialize all fields of the &v4l2-vbi-format; +<structfield>vbi</structfield> member of the +<structfield>fmt</structfield> union, or better just modify the +results of <constant>VIDIOC_G_FMT</constant>, and call the +&VIDIOC-S-FMT; ioctl with a pointer to this structure. Drivers return +an &EINVAL; only when the given parameters are ambiguous, otherwise +they modify the parameters according to the hardware capabilites and +return the actual parameters. When the driver allocates resources at +this point, it may return an &EBUSY; to indicate the returned +parameters are valid but the required resources are currently not +available. That may happen for instance when the video and VBI areas +to capture would overlap, or when the driver supports multiple opens +and another process already requested VBI capturing or output. Anyway, +applications must expect other resource allocation points which may +return <errorcode>EBUSY</errorcode>, at the &VIDIOC-STREAMON; ioctl +and the first read(), write() and select() call.</para> + + <para>VBI devices must implement both the +<constant>VIDIOC_G_FMT</constant> and +<constant>VIDIOC_S_FMT</constant> ioctl, even if +<constant>VIDIOC_S_FMT</constant> ignores all requests and always +returns default parameters as <constant>VIDIOC_G_FMT</constant> does. +<constant>VIDIOC_TRY_FMT</constant> is optional.</para> + + <table pgwide="1" frame="none" id="v4l2-vbi-format"> + <title>struct <structname>v4l2_vbi_format</structname></title> + <tgroup cols="3"> + &cs-str; + <tbody valign="top"> + <row> + <entry>__u32</entry> + <entry><structfield>sampling_rate</structfield></entry> + <entry>Samples per second, i. e. unit 1 Hz.</entry> + </row> + <row> + <entry>__u32</entry> + <entry><structfield>offset</structfield></entry> + <entry><para>Horizontal offset of the VBI image, +relative to the leading edge of the line synchronization pulse and +counted in samples: The first sample in the VBI image will be located +<structfield>offset</structfield> / +<structfield>sampling_rate</structfield> seconds following the leading +edge. See also <xref linkend="vbi-hsync" />.</para></entry> + </row> + <row> + <entry>__u32</entry> + <entry><structfield>samples_per_line</structfield></entry> + <entry></entry> + </row> + <row> + <entry>__u32</entry> + <entry><structfield>sample_format</structfield></entry> + <entry><para>Defines the sample format as in <xref +linkend="pixfmt" />, a four-character-code.<footnote> + <para>A few devices may be unable to +sample VBI data at all but can extend the video capture window to the +VBI region.</para> + </footnote> Usually this is +<constant>V4L2_PIX_FMT_GREY</constant>, i. e. each sample +consists of 8 bits with lower values oriented towards the black level. +Do not assume any other correlation of values with the signal level. +For example, the MSB does not necessarily indicate if the signal is +'high' or 'low' because 128 may not be the mean value of the +signal. Drivers shall not convert the sample format by software.</para></entry> + </row> + <row> + <entry>__u32</entry> + <entry><structfield>start</structfield>[2]</entry> + <entry>This is the scanning system line number +associated with the first line of the VBI image, of the first and the +second field respectively. See <xref linkend="vbi-525" /> and +<xref linkend="vbi-625" /> for valid values. VBI input drivers can +return start values 0 if the hardware cannot reliable identify +scanning lines, VBI acquisition may not require this +information.</entry> + </row> + <row> + <entry>__u32</entry> + <entry><structfield>count</structfield>[2]</entry> + <entry>The number of lines in the first and second +field image, respectively.</entry> + </row> + <row> + <entry spanname="hspan"><para>Drivers should be as +flexibility as possible. For example, it may be possible to extend or +move the VBI capture window down to the picture area, implementing a +'full field mode' to capture data service transmissions embedded in +the picture.</para><para>An application can set the first or second +<structfield>count</structfield> value to zero if no data is required +from the respective field; <structfield>count</structfield>[1] if the +scanning system is progressive, &ie; not interlaced. The +corresponding start value shall be ignored by the application and +driver. Anyway, drivers may not support single field capturing and +return both count values non-zero.</para><para>Both +<structfield>count</structfield> values set to zero, or line numbers +outside the bounds depicted in <xref linkend="vbi-525" /> and <xref + linkend="vbi-625" />, or a field image covering +lines of two fields, are invalid and shall not be returned by the +driver.</para><para>To initialize the <structfield>start</structfield> +and <structfield>count</structfield> fields, applications must first +determine the current video standard selection. The &v4l2-std-id; or +the <structfield>framelines</structfield> field of &v4l2-standard; can +be evaluated for this purpose.</para></entry> + </row> + <row> + <entry>__u32</entry> + <entry><structfield>flags</structfield></entry> + <entry>See <xref linkend="vbifmt-flags" /> below. Currently +only drivers set flags, applications must set this field to +zero.</entry> + </row> + <row> + <entry>__u32</entry> + <entry><structfield>reserved</structfield>[2]</entry> + <entry>This array is reserved for future extensions. +Drivers and applications must set it to zero.</entry> + </row> + </tbody> + </tgroup> + </table> + + <table pgwide="1" frame="none" id="vbifmt-flags"> + <title>Raw VBI Format Flags</title> + <tgroup cols="3"> + &cs-def; + <tbody valign="top"> + <row> + <entry><constant>V4L2_VBI_UNSYNC</constant></entry> + <entry>0x0001</entry> + <entry><para>This flag indicates hardware which does not +properly distinguish between fields. Normally the VBI image stores the +first field (lower scanning line numbers) first in memory. This may be +a top or bottom field depending on the video standard. When this flag +is set the first or second field may be stored first, however the +fields are still in correct temporal order with the older field first +in memory.<footnote> + <para>Most VBI services transmit on both fields, but +some have different semantics depending on the field number. These +cannot be reliable decoded or encoded when +<constant>V4L2_VBI_UNSYNC</constant> is set.</para> + </footnote></para></entry> + </row> + <row> + <entry><constant>V4L2_VBI_INTERLACED</constant></entry> + <entry>0x0002</entry> + <entry>By default the two field images will be passed +sequentially; all lines of the first field followed by all lines of +the second field (compare <xref linkend="field-order" /> +<constant>V4L2_FIELD_SEQ_TB</constant> and +<constant>V4L2_FIELD_SEQ_BT</constant>, whether the top or bottom +field is first in memory depends on the video standard). When this +flag is set, the two fields are interlaced (cf. +<constant>V4L2_FIELD_INTERLACED</constant>). The first line of the +first field followed by the first line of the second field, then the +two second lines, and so on. Such a layout may be necessary when the +hardware has been programmed to capture or output interlaced video +images and is unable to separate the fields for VBI capturing at +the same time. For simplicity setting this flag implies that both +<structfield>count</structfield> values are equal and non-zero.</entry> + </row> + </tbody> + </tgroup> + </table> + + <figure id="vbi-hsync"> + <title>Line synchronization</title> + <mediaobject> + <imageobject> + <imagedata fileref="vbi_hsync.pdf" format="PS" /> + </imageobject> + <imageobject> + <imagedata fileref="vbi_hsync.gif" format="GIF" /> + </imageobject> + <textobject> + <phrase>Line synchronization diagram</phrase> + </textobject> + </mediaobject> + </figure> + + <figure id="vbi-525"> + <title>ITU-R 525 line numbering (M/NTSC and M/PAL)</title> + <mediaobject> + <imageobject> + <imagedata fileref="vbi_525.pdf" format="PS" /> + </imageobject> + <imageobject> + <imagedata fileref="vbi_525.gif" format="GIF" /> + </imageobject> + <textobject> + <phrase>NTSC field synchronization diagram</phrase> + </textobject> + <caption> + <para>(1) For the purpose of this specification field 2 +starts in line 264 and not 263.5 because half line capturing is not +supported.</para> + </caption> + </mediaobject> + </figure> + + <figure id="vbi-625"> + <title>ITU-R 625 line numbering</title> + <mediaobject> + <imageobject> + <imagedata fileref="vbi_625.pdf" format="PS" /> + </imageobject> + <imageobject> + <imagedata fileref="vbi_625.gif" format="GIF" /> + </imageobject> + <textobject> + <phrase>PAL/SECAM field synchronization diagram</phrase> + </textobject> + <caption> + <para>(1) For the purpose of this specification field 2 +starts in line 314 and not 313.5 because half line capturing is not +supported.</para> + </caption> + </mediaobject> + </figure> + + <para>Remember the VBI image format depends on the selected +video standard, therefore the application must choose a new standard or +query the current standard first. Attempts to read or write data ahead +of format negotiation, or after switching the video standard which may +invalidate the negotiated VBI parameters, should be refused by the +driver. A format change during active I/O is not permitted.</para> + </section> + + <section> + <title>Reading and writing VBI images</title> + + <para>To assure synchronization with the field number and easier +implementation, the smallest unit of data passed at a time is one +frame, consisting of two fields of VBI images immediately following in +memory.</para> + + <para>The total size of a frame computes as follows:</para> + + <programlisting> +(<structfield>count</structfield>[0] + <structfield>count</structfield>[1]) * +<structfield>samples_per_line</structfield> * sample size in bytes</programlisting> + + <para>The sample size is most likely always one byte, +applications must check the <structfield>sample_format</structfield> +field though, to function properly with other drivers.</para> + + <para>A VBI device may support <link + linkend="rw">read/write</link> and/or streaming (<link + linkend="mmap">memory mapping</link> or <link + linkend="userp">user pointer</link>) I/O. The latter bears the +possibility of synchronizing video and +VBI data by using buffer timestamps.</para> + + <para>Remember the &VIDIOC-STREAMON; ioctl and the first read(), +write() and select() call can be resource allocation points returning +an &EBUSY; if the required hardware resources are temporarily +unavailable, for example the device is already in use by another +process.</para> + </section> + + <!-- +Local Variables: +mode: sgml +sgml-parent-document: "v4l2.sgml" +indent-tabs-mode: nil +End: + --> diff --git a/Documentation/DocBook/v4l/dev-rds.xml b/Documentation/DocBook/v4l/dev-rds.xml new file mode 100644 index 000000000000..0869d701b1e5 --- /dev/null +++ b/Documentation/DocBook/v4l/dev-rds.xml @@ -0,0 +1,168 @@ + <title>RDS Interface</title> + + <para>The Radio Data System transmits supplementary +information in binary format, for example the station name or travel +information, on an inaudible audio subcarrier of a radio program. This +interface is aimed at devices capable of receiving and decoding RDS +information.</para> + + <para>For more information see the core RDS standard <xref linkend="en50067" /> +and the RBDS standard <xref linkend="nrsc4" />.</para> + + <para>Note that the RBDS standard as is used in the USA is almost identical +to the RDS standard. Any RDS decoder can also handle RBDS. Only some of the fields +have slightly different meanings. See the RBDS standard for more information.</para> + + <para>The RBDS standard also specifies support for MMBS (Modified Mobile Search). +This is a proprietary format which seems to be discontinued. The RDS interface does not +support this format. Should support for MMBS (or the so-called 'E blocks' in general) +be needed, then please contact the linux-media mailing list: &v4l-ml;.</para> + + <section> + <title>Querying Capabilities</title> + + <para>Devices supporting the RDS capturing API +set the <constant>V4L2_CAP_RDS_CAPTURE</constant> flag in +the <structfield>capabilities</structfield> field of &v4l2-capability; +returned by the &VIDIOC-QUERYCAP; ioctl. +Any tuner that supports RDS will set the +<constant>V4L2_TUNER_CAP_RDS</constant> flag in the <structfield>capability</structfield> +field of &v4l2-tuner;. +Whether an RDS signal is present can be detected by looking at +the <structfield>rxsubchans</structfield> field of &v4l2-tuner;: the +<constant>V4L2_TUNER_SUB_RDS</constant> will be set if RDS data was detected.</para> + + <para>Devices supporting the RDS output API +set the <constant>V4L2_CAP_RDS_OUTPUT</constant> flag in +the <structfield>capabilities</structfield> field of &v4l2-capability; +returned by the &VIDIOC-QUERYCAP; ioctl. +Any modulator that supports RDS will set the +<constant>V4L2_TUNER_CAP_RDS</constant> flag in the <structfield>capability</structfield> +field of &v4l2-modulator;. +In order to enable the RDS transmission one must set the <constant>V4L2_TUNER_SUB_RDS</constant> +bit in the <structfield>txsubchans</structfield> field of &v4l2-modulator;.</para> + + </section> + + <section> + <title>Reading RDS data</title> + + <para>RDS data can be read from the radio device +with the &func-read; function. The data is packed in groups of three bytes, +as follows:</para> + <table frame="none" pgwide="1" id="v4l2-rds-data"> + <title>struct +<structname>v4l2_rds_data</structname></title> + <tgroup cols="3"> + <colspec colname="c1" colwidth="1*" /> + <colspec colname="c2" colwidth="1*" /> + <colspec colname="c3" colwidth="5*" /> + <tbody valign="top"> + <row> + <entry>__u8</entry> + <entry><structfield>lsb</structfield></entry> + <entry>Least Significant Byte of RDS Block</entry> + </row> + <row> + <entry>__u8</entry> + <entry><structfield>msb</structfield></entry> + <entry>Most Significant Byte of RDS Block</entry> + </row> + <row> + <entry>__u8</entry> + <entry><structfield>block</structfield></entry> + <entry>Block description</entry> + </row> + </tbody> + </tgroup> + </table> + <table frame="none" pgwide="1" id="v4l2-rds-block"> + <title>Block description</title> + <tgroup cols="2"> + <colspec colname="c1" colwidth="1*" /> + <colspec colname="c2" colwidth="5*" /> + <tbody valign="top"> + <row> + <entry>Bits 0-2</entry> + <entry>Block (aka offset) of the received data.</entry> + </row> + <row> + <entry>Bits 3-5</entry> + <entry>Deprecated. Currently identical to bits 0-2. Do not use these bits.</entry> + </row> + <row> + <entry>Bit 6</entry> + <entry>Corrected bit. Indicates that an error was corrected for this data block.</entry> + </row> + <row> + <entry>Bit 7</entry> + <entry>Error bit. Indicates that an uncorrectable error occurred during reception of this block.</entry> + </row> + </tbody> + </tgroup> + </table> + + <table frame="none" pgwide="1" id="v4l2-rds-block-codes"> + <title>Block defines</title> + <tgroup cols="3"> + <colspec colname="c1" colwidth="1*" /> + <colspec colname="c2" colwidth="1*" /> + <colspec colname="c3" colwidth="5*" /> + <tbody valign="top"> + <row> + <entry>V4L2_RDS_BLOCK_MSK</entry> + <entry>7</entry> + <entry>Mask for bits 0-2 to get the block ID.</entry> + </row> + <row> + <entry>V4L2_RDS_BLOCK_A</entry> + <entry>0</entry> + <entry>Block A.</entry> + </row> + <row> + <entry>V4L2_RDS_BLOCK_B</entry> + <entry>1</entry> + <entry>Block B.</entry> + </row> + <row> + <entry>V4L2_RDS_BLOCK_C</entry> + <entry>2</entry> + <entry>Block C.</entry> + </row> + <row> + <entry>V4L2_RDS_BLOCK_D</entry> + <entry>3</entry> + <entry>Block D.</entry> + </row> + <row> + <entry>V4L2_RDS_BLOCK_C_ALT</entry> + <entry>4</entry> + <entry>Block C'.</entry> + </row> + <row> + <entry>V4L2_RDS_BLOCK_INVALID</entry> + <entry>7</entry> + <entry>An invalid block.</entry> + </row> + <row> + <entry>V4L2_RDS_BLOCK_CORRECTED</entry> + <entry>0x40</entry> + <entry>A bit error was detected but corrected.</entry> + </row> + <row> + <entry>V4L2_RDS_BLOCK_ERROR</entry> + <entry>0x80</entry> + <entry>An incorrectable error occurred.</entry> + </row> + </tbody> + </tgroup> + </table> + </section> + +<!-- +Local Variables: +mode: sgml +sgml-parent-document: "v4l2.sgml" +indent-tabs-mode: nil +End: + --> diff --git a/Documentation/DocBook/v4l/dev-sliced-vbi.xml b/Documentation/DocBook/v4l/dev-sliced-vbi.xml new file mode 100644 index 000000000000..69e789fa7f7b --- /dev/null +++ b/Documentation/DocBook/v4l/dev-sliced-vbi.xml @@ -0,0 +1,708 @@ + <title>Sliced VBI Data Interface</title> + + <para>VBI stands for Vertical Blanking Interval, a gap in the +sequence of lines of an analog video signal. During VBI no picture +information is transmitted, allowing some time while the electron beam +of a cathode ray tube TV returns to the top of the screen.</para> + + <para>Sliced VBI devices use hardware to demodulate data transmitted +in the VBI. V4L2 drivers shall <emphasis>not</emphasis> do this by +software, see also the <link linkend="raw-vbi">raw VBI +interface</link>. The data is passed as short packets of fixed size, +covering one scan line each. The number of packets per video frame is +variable.</para> + + <para>Sliced VBI capture and output devices are accessed through the +same character special files as raw VBI devices. When a driver +supports both interfaces, the default function of a +<filename>/dev/vbi</filename> device is <emphasis>raw</emphasis> VBI +capturing or output, and the sliced VBI function is only available +after calling the &VIDIOC-S-FMT; ioctl as defined below. Likewise a +<filename>/dev/video</filename> device may support the sliced VBI API, +however the default function here is video capturing or output. +Different file descriptors must be used to pass raw and sliced VBI +data simultaneously, if this is supported by the driver.</para> + + <section> + <title>Querying Capabilities</title> + + <para>Devices supporting the sliced VBI capturing or output API +set the <constant>V4L2_CAP_SLICED_VBI_CAPTURE</constant> or +<constant>V4L2_CAP_SLICED_VBI_OUTPUT</constant> flag respectively, in +the <structfield>capabilities</structfield> field of &v4l2-capability; +returned by the &VIDIOC-QUERYCAP; ioctl. At least one of the +read/write, streaming or asynchronous <link linkend="io">I/O +methods</link> must be supported. Sliced VBI devices may have a tuner +or modulator.</para> + </section> + + <section> + <title>Supplemental Functions</title> + + <para>Sliced VBI devices shall support <link linkend="video">video +input or output</link> and <link linkend="tuner">tuner or +modulator</link> ioctls if they have these capabilities, and they may +support <link linkend="control">control</link> ioctls. The <link +linkend="standard">video standard</link> ioctls provide information +vital to program a sliced VBI device, therefore must be +supported.</para> + </section> + + <section id="sliced-vbi-format-negotitation"> + <title>Sliced VBI Format Negotiation</title> + + <para>To find out which data services are supported by the +hardware applications can call the &VIDIOC-G-SLICED-VBI-CAP; ioctl. +All drivers implementing the sliced VBI interface must support this +ioctl. The results may differ from those of the &VIDIOC-S-FMT; ioctl +when the number of VBI lines the hardware can capture or output per +frame, or the number of services it can identify on a given line are +limited. For example on PAL line 16 the hardware may be able to look +for a VPS or Teletext signal, but not both at the same time.</para> + + <para>To determine the currently selected services applications +set the <structfield>type </structfield> field of &v4l2-format; to +<constant> V4L2_BUF_TYPE_SLICED_VBI_CAPTURE</constant> or <constant> +V4L2_BUF_TYPE_SLICED_VBI_OUTPUT</constant>, and the &VIDIOC-G-FMT; +ioctl fills the <structfield>fmt.sliced</structfield> member, a +&v4l2-sliced-vbi-format;.</para> + + <para>Applications can request different parameters by +initializing or modifying the <structfield>fmt.sliced</structfield> +member and calling the &VIDIOC-S-FMT; ioctl with a pointer to the +<structname>v4l2_format</structname> structure.</para> + + <para>The sliced VBI API is more complicated than the raw VBI API +because the hardware must be told which VBI service to expect on each +scan line. Not all services may be supported by the hardware on all +lines (this is especially true for VBI output where Teletext is often +unsupported and other services can only be inserted in one specific +line). In many cases, however, it is sufficient to just set the +<structfield>service_set</structfield> field to the required services +and let the driver fill the <structfield>service_lines</structfield> +array according to hardware capabilities. Only if more precise control +is needed should the programmer set the +<structfield>service_lines</structfield> array explicitly.</para> + + <para>The &VIDIOC-S-FMT; ioctl modifies the parameters +according to hardware capabilities. When the driver allocates +resources at this point, it may return an &EBUSY; if the required +resources are temporarily unavailable. Other resource allocation +points which may return <errorcode>EBUSY</errorcode> can be the +&VIDIOC-STREAMON; ioctl and the first &func-read;, &func-write; and +&func-select; call.</para> + + <table frame="none" pgwide="1" id="v4l2-sliced-vbi-format"> + <title>struct +<structname>v4l2_sliced_vbi_format</structname></title> + <tgroup cols="5"> + <colspec colname="c1" colwidth="3*" /> + <colspec colname="c2" colwidth="3*" /> + <colspec colname="c3" colwidth="2*" /> + <colspec colname="c4" colwidth="2*" /> + <colspec colname="c5" colwidth="2*" /> + <spanspec namest="c3" nameend="c5" spanname="hspan" /> + <tbody valign="top"> + <row> + <entry>__u32</entry> + <entry><structfield>service_set</structfield></entry> + <entry spanname="hspan"><para>If +<structfield>service_set</structfield> is non-zero when passed with +&VIDIOC-S-FMT; or &VIDIOC-TRY-FMT;, the +<structfield>service_lines</structfield> array will be filled by the +driver according to the services specified in this field. For example, +if <structfield>service_set</structfield> is initialized with +<constant>V4L2_SLICED_TELETEXT_B | V4L2_SLICED_WSS_625</constant>, a +driver for the cx25840 video decoder sets lines 7-22 of both +fields<footnote><para>According to <link +linkend="ets300706">ETS 300 706</link> lines 6-22 of the +first field and lines 5-22 of the second field may carry Teletext +data.</para></footnote> to <constant>V4L2_SLICED_TELETEXT_B</constant> +and line 23 of the first field to +<constant>V4L2_SLICED_WSS_625</constant>. If +<structfield>service_set</structfield> is set to zero, then the values +of <structfield>service_lines</structfield> will be used instead. +</para><para>On return the driver sets this field to the union of all +elements of the returned <structfield>service_lines</structfield> +array. It may contain less services than requested, perhaps just one, +if the hardware cannot handle more services simultaneously. It may be +empty (zero) if none of the requested services are supported by the +hardware.</para></entry> + </row> + <row> + <entry>__u16</entry> + <entry><structfield>service_lines</structfield>[2][24]</entry> + <entry spanname="hspan"><para>Applications initialize this +array with sets of data services the driver shall look for or insert +on the respective scan line. Subject to hardware capabilities drivers +return the requested set, a subset, which may be just a single +service, or an empty set. When the hardware cannot handle multiple +services on the same line the driver shall choose one. No assumptions +can be made on which service the driver chooses.</para><para>Data +services are defined in <xref linkend="vbi-services2" />. Array indices +map to ITU-R line numbers (see also <xref linkend="vbi-525" /> and <xref + linkend="vbi-625" />) as follows: <!-- No nested +tables, sigh. --></para></entry> + </row> + <row> + <entry></entry> + <entry></entry> + <entry>Element</entry> + <entry>525 line systems</entry> + <entry>625 line systems</entry> + </row> + <row> + <entry></entry> + <entry></entry> + <entry><structfield>service_lines</structfield>[0][1]</entry> + <entry align="center">1</entry> + <entry align="center">1</entry> + </row> + <row> + <entry></entry> + <entry></entry> + <entry><structfield>service_lines</structfield>[0][23]</entry> + <entry align="center">23</entry> + <entry align="center">23</entry> + </row> + <row> + <entry></entry> + <entry></entry> + <entry><structfield>service_lines</structfield>[1][1]</entry> + <entry align="center">264</entry> + <entry align="center">314</entry> + </row> + <row> + <entry></entry> + <entry></entry> + <entry><structfield>service_lines</structfield>[1][23]</entry> + <entry align="center">286</entry> + <entry align="center">336</entry> + </row> + <!-- End of line numbers table. --> + <row> + <entry></entry> + <entry></entry> + <entry spanname="hspan">Drivers must set +<structfield>service_lines</structfield>[0][0] and +<structfield>service_lines</structfield>[1][0] to zero.</entry> + </row> + <row> + <entry>__u32</entry> + <entry><structfield>io_size</structfield></entry> + <entry spanname="hspan">Maximum number of bytes passed by +one &func-read; or &func-write; call, and the buffer size in bytes for +the &VIDIOC-QBUF; and &VIDIOC-DQBUF; ioctl. Drivers set this field to +the size of &v4l2-sliced-vbi-data; times the number of non-zero +elements in the returned <structfield>service_lines</structfield> +array (that is the number of lines potentially carrying data).</entry> + </row> + <row> + <entry>__u32</entry> + <entry><structfield>reserved</structfield>[2]</entry> + <entry spanname="hspan">This array is reserved for future +extensions. Applications and drivers must set it to zero.</entry> + </row> + </tbody> + </tgroup> + </table> + + <!-- See also vidioc-g-sliced-vbi-cap.sgml --> + <table frame="none" pgwide="1" id="vbi-services2"> + <title>Sliced VBI services</title> + <tgroup cols="5"> + <colspec colname="c1" colwidth="2*" /> + <colspec colname="c2" colwidth="1*" /> + <colspec colname="c3" colwidth="1*" /> + <colspec colname="c4" colwidth="2*" /> + <colspec colname="c5" colwidth="2*" /> + <spanspec namest="c3" nameend="c5" spanname="rlp" /> + <thead> + <row> + <entry>Symbol</entry> + <entry>Value</entry> + <entry>Reference</entry> + <entry>Lines, usually</entry> + <entry>Payload</entry> + </row> + </thead> + <tbody valign="top"> + <row> + <entry><constant>V4L2_SLICED_TELETEXT_B</constant> +(Teletext System B)</entry> + <entry>0x0001</entry> + <entry><xref linkend="ets300706" />, <xref linkend="itu653" /></entry> + <entry>PAL/SECAM line 7-22, 320-335 (second field 7-22)</entry> + <entry>Last 42 of the 45 byte Teletext packet, that is +without clock run-in and framing code, lsb first transmitted.</entry> + </row> + <row> + <entry><constant>V4L2_SLICED_VPS</constant></entry> + <entry>0x0400</entry> + <entry><xref linkend="ets300231" /></entry> + <entry>PAL line 16</entry> + <entry>Byte number 3 to 15 according to Figure 9 of +ETS 300 231, lsb first transmitted.</entry> + </row> + <row> + <entry><constant>V4L2_SLICED_CAPTION_525</constant></entry> + <entry>0x1000</entry> + <entry><xref linkend="eia608" /></entry> + <entry>NTSC line 21, 284 (second field 21)</entry> + <entry>Two bytes in transmission order, including parity +bit, lsb first transmitted.</entry> + </row> + <row> + <entry><constant>V4L2_SLICED_WSS_625</constant></entry> + <entry>0x4000</entry> + <entry><xref linkend="itu1119" />, <xref linkend="en300294" /></entry> + <entry>PAL/SECAM line 23</entry> + <entry><screen> +Byte 0 1 + msb lsb msb lsb + Bit 7 6 5 4 3 2 1 0 x x 13 12 11 10 9 +</screen></entry> + </row> + <row> + <entry><constant>V4L2_SLICED_VBI_525</constant></entry> + <entry>0x1000</entry> + <entry spanname="rlp">Set of services applicable to 525 +line systems.</entry> + </row> + <row> + <entry><constant>V4L2_SLICED_VBI_625</constant></entry> + <entry>0x4401</entry> + <entry spanname="rlp">Set of services applicable to 625 +line systems.</entry> + </row> + </tbody> + </tgroup> + </table> + + <para>Drivers may return an &EINVAL; when applications attempt to +read or write data without prior format negotiation, after switching +the video standard (which may invalidate the negotiated VBI +parameters) and after switching the video input (which may change the +video standard as a side effect). The &VIDIOC-S-FMT; ioctl may return +an &EBUSY; when applications attempt to change the format while i/o is +in progress (between a &VIDIOC-STREAMON; and &VIDIOC-STREAMOFF; call, +and after the first &func-read; or &func-write; call).</para> + </section> + + <section> + <title>Reading and writing sliced VBI data</title> + + <para>A single &func-read; or &func-write; call must pass all data +belonging to one video frame. That is an array of +<structname>v4l2_sliced_vbi_data</structname> structures with one or +more elements and a total size not exceeding +<structfield>io_size</structfield> bytes. Likewise in streaming I/O +mode one buffer of <structfield>io_size</structfield> bytes must +contain data of one video frame. The <structfield>id</structfield> of +unused <structname>v4l2_sliced_vbi_data</structname> elements must be +zero.</para> + + <table frame="none" pgwide="1" id="v4l2-sliced-vbi-data"> + <title>struct +<structname>v4l2_sliced_vbi_data</structname></title> + <tgroup cols="3"> + &cs-def; + <tbody valign="top"> + <row> + <entry>__u32</entry> + <entry><structfield>id</structfield></entry> + <entry>A flag from <xref linkend="vbi-services" /> +identifying the type of data in this packet. Only a single bit must be +set. When the <structfield>id</structfield> of a captured packet is +zero, the packet is empty and the contents of other fields are +undefined. Applications shall ignore empty packets. When the +<structfield>id</structfield> of a packet for output is zero the +contents of the <structfield>data</structfield> field are undefined +and the driver must no longer insert data on the requested +<structfield>field</structfield> and +<structfield>line</structfield>.</entry> + </row> + <row> + <entry>__u32</entry> + <entry><structfield>field</structfield></entry> + <entry>The video field number this data has been captured +from, or shall be inserted at. <constant>0</constant> for the first +field, <constant>1</constant> for the second field.</entry> + </row> + <row> + <entry>__u32</entry> + <entry><structfield>line</structfield></entry> + <entry>The field (as opposed to frame) line number this +data has been captured from, or shall be inserted at. See <xref + linkend="vbi-525" /> and <xref linkend="vbi-625" /> for valid +values. Sliced VBI capture devices can set the line number of all +packets to <constant>0</constant> if the hardware cannot reliably +identify scan lines. The field number must always be valid.</entry> + </row> + <row> + <entry>__u32</entry> + <entry><structfield>reserved</structfield></entry> + <entry>This field is reserved for future extensions. +Applications and drivers must set it to zero.</entry> + </row> + <row> + <entry>__u8</entry> + <entry><structfield>data</structfield>[48]</entry> + <entry>The packet payload. See <xref + linkend="vbi-services" /> for the contents and number of +bytes passed for each data type. The contents of padding bytes at the +end of this array are undefined, drivers and applications shall ignore +them.</entry> + </row> + </tbody> + </tgroup> + </table> + + <para>Packets are always passed in ascending line number order, +without duplicate line numbers. The &func-write; function and the +&VIDIOC-QBUF; ioctl must return an &EINVAL; when applications violate +this rule. They must also return an &EINVAL; when applications pass an +incorrect field or line number, or a combination of +<structfield>field</structfield>, <structfield>line</structfield> and +<structfield>id</structfield> which has not been negotiated with the +&VIDIOC-G-FMT; or &VIDIOC-S-FMT; ioctl. When the line numbers are +unknown the driver must pass the packets in transmitted order. The +driver can insert empty packets with <structfield>id</structfield> set +to zero anywhere in the packet array.</para> + + <para>To assure synchronization and to distinguish from frame +dropping, when a captured frame does not carry any of the requested +data services drivers must pass one or more empty packets. When an +application fails to pass VBI data in time for output, the driver +must output the last VPS and WSS packet again, and disable the output +of Closed Caption and Teletext data, or output data which is ignored +by Closed Caption and Teletext decoders.</para> + + <para>A sliced VBI device may support <link +linkend="rw">read/write</link> and/or streaming (<link +linkend="mmap">memory mapping</link> and/or <link linkend="userp">user +pointer</link>) I/O. The latter bears the possibility of synchronizing +video and VBI data by using buffer timestamps.</para> + + </section> + + <section> + <title>Sliced VBI Data in MPEG Streams</title> + + <para>If a device can produce an MPEG output stream, it may be +capable of providing <link +linkend="sliced-vbi-format-negotitation">negotiated sliced VBI +services</link> as data embedded in the MPEG stream. Users or +applications control this sliced VBI data insertion with the <link +linkend="v4l2-mpeg-stream-vbi-fmt">V4L2_CID_MPEG_STREAM_VBI_FMT</link> +control.</para> + + <para>If the driver does not provide the <link +linkend="v4l2-mpeg-stream-vbi-fmt">V4L2_CID_MPEG_STREAM_VBI_FMT</link> +control, or only allows that control to be set to <link +linkend="v4l2-mpeg-stream-vbi-fmt"><constant> +V4L2_MPEG_STREAM_VBI_FMT_NONE</constant></link>, then the device +cannot embed sliced VBI data in the MPEG stream.</para> + + <para>The <link linkend="v4l2-mpeg-stream-vbi-fmt"> +V4L2_CID_MPEG_STREAM_VBI_FMT</link> control does not implicitly set +the device driver to capture nor cease capturing sliced VBI data. The +control only indicates to embed sliced VBI data in the MPEG stream, if +an application has negotiated sliced VBI service be captured.</para> + + <para>It may also be the case that a device can embed sliced VBI +data in only certain types of MPEG streams: for example in an MPEG-2 +PS but not an MPEG-2 TS. In this situation, if sliced VBI data +insertion is requested, the sliced VBI data will be embedded in MPEG +stream types when supported, and silently omitted from MPEG stream +types where sliced VBI data insertion is not supported by the device. +</para> + + <para>The following subsections specify the format of the +embedded sliced VBI data.</para> + + <section> + <title>MPEG Stream Embedded, Sliced VBI Data Format: NONE</title> + <para>The <link linkend="v4l2-mpeg-stream-vbi-fmt"><constant> +V4L2_MPEG_STREAM_VBI_FMT_NONE</constant></link> embedded sliced VBI +format shall be interpreted by drivers as a control to cease +embedding sliced VBI data in MPEG streams. Neither the device nor +driver shall insert "empty" embedded sliced VBI data packets in the +MPEG stream when this format is set. No MPEG stream data structures +are specified for this format.</para> + </section> + + <section> + <title>MPEG Stream Embedded, Sliced VBI Data Format: IVTV</title> + <para>The <link linkend="v4l2-mpeg-stream-vbi-fmt"><constant> +V4L2_MPEG_STREAM_VBI_FMT_IVTV</constant></link> embedded sliced VBI +format, when supported, indicates to the driver to embed up to 36 +lines of sliced VBI data per frame in an MPEG-2 <emphasis>Private +Stream 1 PES</emphasis> packet encapsulated in an MPEG-2 <emphasis> +Program Pack</emphasis> in the MPEG stream.</para> + + <para><emphasis>Historical context</emphasis>: This format +specification originates from a custom, embedded, sliced VBI data +format used by the <filename>ivtv</filename> driver. This format +has already been informally specified in the kernel sources in the +file <filename>Documentation/video4linux/cx2341x/README.vbi</filename> +. The maximum size of the payload and other aspects of this format +are driven by the CX23415 MPEG decoder's capabilities and limitations +with respect to extracting, decoding, and displaying sliced VBI data +embedded within an MPEG stream.</para> + + <para>This format's use is <emphasis>not</emphasis> exclusive to +the <filename>ivtv</filename> driver <emphasis>nor</emphasis> +exclusive to CX2341x devices, as the sliced VBI data packet insertion +into the MPEG stream is implemented in driver software. At least the +<filename>cx18</filename> driver provides sliced VBI data insertion +into an MPEG-2 PS in this format as well.</para> + + <para>The following definitions specify the payload of the +MPEG-2 <emphasis>Private Stream 1 PES</emphasis> packets that contain +sliced VBI data when <link linkend="v4l2-mpeg-stream-vbi-fmt"> +<constant>V4L2_MPEG_STREAM_VBI_FMT_IVTV</constant></link> is set. +(The MPEG-2 <emphasis>Private Stream 1 PES</emphasis> packet header +and encapsulating MPEG-2 <emphasis>Program Pack</emphasis> header are +not detailed here. Please refer to the MPEG-2 specifications for +details on those packet headers.)</para> + + <para>The payload of the MPEG-2 <emphasis>Private Stream 1 PES +</emphasis> packets that contain sliced VBI data is specified by +&v4l2-mpeg-vbi-fmt-ivtv;. The payload is variable +length, depending on the actual number of lines of sliced VBI data +present in a video frame. The payload may be padded at the end with +unspecified fill bytes to align the end of the payload to a 4-byte +boundary. The payload shall never exceed 1552 bytes (2 fields with +18 lines/field with 43 bytes of data/line and a 4 byte magic number). +</para> + + <table frame="none" pgwide="1" id="v4l2-mpeg-vbi-fmt-ivtv"> + <title>struct <structname>v4l2_mpeg_vbi_fmt_ivtv</structname> + </title> + <tgroup cols="4"> + &cs-ustr; + <tbody valign="top"> + <row> + <entry>__u8</entry> + <entry><structfield>magic</structfield>[4]</entry> + <entry></entry> + <entry>A "magic" constant from <xref + linkend="v4l2-mpeg-vbi-fmt-ivtv-magic" /> that indicates +this is a valid sliced VBI data payload and also indicates which +member of the anonymous union, <structfield>itv0</structfield> or +<structfield>ITV0</structfield>, to use for the payload data.</entry> + </row> + <row> + <entry>union</entry> + <entry>(anonymous)</entry> + </row> + <row> + <entry></entry> + <entry>struct <link linkend="v4l2-mpeg-vbi-itv0"> + <structname>v4l2_mpeg_vbi_itv0</structname></link> + </entry> + <entry><structfield>itv0</structfield></entry> + <entry>The primary form of the sliced VBI data payload +that contains anywhere from 1 to 35 lines of sliced VBI data. +Line masks are provided in this form of the payload indicating +which VBI lines are provided.</entry> + </row> + <row> + <entry></entry> + <entry>struct <link linkend="v4l2-mpeg-vbi-itv0-1"> + <structname>v4l2_mpeg_vbi_ITV0</structname></link> + </entry> + <entry><structfield>ITV0</structfield></entry> + <entry>An alternate form of the sliced VBI data payload +used when 36 lines of sliced VBI data are present. No line masks are +provided in this form of the payload; all valid line mask bits are +implcitly set.</entry> + </row> + </tbody> + </tgroup> + </table> + + <table frame="none" pgwide="1" id="v4l2-mpeg-vbi-fmt-ivtv-magic"> + <title>Magic Constants for &v4l2-mpeg-vbi-fmt-ivtv; + <structfield>magic</structfield> field</title> + <tgroup cols="3"> + &cs-def; + <thead> + <row> + <entry align="left">Defined Symbol</entry> + <entry align="left">Value</entry> + <entry align="left">Description</entry> + </row> + </thead> + <tbody valign="top"> + <row> + <entry><constant>V4L2_MPEG_VBI_IVTV_MAGIC0</constant> + </entry> + <entry>"itv0"</entry> + <entry>Indicates the <structfield>itv0</structfield> +member of the union in &v4l2-mpeg-vbi-fmt-ivtv; is valid.</entry> + </row> + <row> + <entry><constant>V4L2_MPEG_VBI_IVTV_MAGIC1</constant> + </entry> + <entry>"ITV0"</entry> + <entry>Indicates the <structfield>ITV0</structfield> +member of the union in &v4l2-mpeg-vbi-fmt-ivtv; is valid and +that 36 lines of sliced VBI data are present.</entry> + </row> + </tbody> + </tgroup> + </table> + + <table frame="none" pgwide="1" id="v4l2-mpeg-vbi-itv0"> + <title>struct <structname>v4l2_mpeg_vbi_itv0</structname> + </title> + <tgroup cols="3"> + &cs-str; + <tbody valign="top"> + <row> + <entry>__le32</entry> + <entry><structfield>linemask</structfield>[2]</entry> + <entry><para>Bitmasks indicating the VBI service lines +present. These <structfield>linemask</structfield> values are stored +in little endian byte order in the MPEG stream. Some reference +<structfield>linemask</structfield> bit positions with their +corresponding VBI line number and video field are given below. +b<subscript>0</subscript> indicates the least significant bit of a +<structfield>linemask</structfield> value:<screen> +<structfield>linemask</structfield>[0] b<subscript>0</subscript>: line 6 first field +<structfield>linemask</structfield>[0] b<subscript>17</subscript>: line 23 first field +<structfield>linemask</structfield>[0] b<subscript>18</subscript>: line 6 second field +<structfield>linemask</structfield>[0] b<subscript>31</subscript>: line 19 second field +<structfield>linemask</structfield>[1] b<subscript>0</subscript>: line 20 second field +<structfield>linemask</structfield>[1] b<subscript>3</subscript>: line 23 second field +<structfield>linemask</structfield>[1] b<subscript>4</subscript>-b<subscript>31</subscript>: unused and set to 0</screen></para></entry> + </row> + <row> + <entry>struct <link linkend="v4l2-mpeg-vbi-itv0-line"> + <structname>v4l2_mpeg_vbi_itv0_line</structname></link> + </entry> + <entry><structfield>line</structfield>[35]</entry> + <entry>This is a variable length array that holds from 1 +to 35 lines of sliced VBI data. The sliced VBI data lines present +correspond to the bits set in the <structfield>linemask</structfield> +array, starting from b<subscript>0</subscript> of <structfield> +linemask</structfield>[0] up through b<subscript>31</subscript> of +<structfield>linemask</structfield>[0], and from b<subscript>0 +</subscript> of <structfield>linemask</structfield>[1] up through b +<subscript>3</subscript> of <structfield>linemask</structfield>[1]. +<structfield>line</structfield>[0] corresponds to the first bit +found set in the <structfield>linemask</structfield> array, +<structfield>line</structfield>[1] corresponds to the second bit +found set in the <structfield>linemask</structfield> array, etc. +If no <structfield>linemask</structfield> array bits are set, then +<structfield>line</structfield>[0] may contain one line of +unspecified data that should be ignored by applications.</entry> + </row> + </tbody> + </tgroup> + </table> + + <table frame="none" pgwide="1" id="v4l2-mpeg-vbi-itv0-1"> + <title>struct <structname>v4l2_mpeg_vbi_ITV0</structname> + </title> + <tgroup cols="3"> + &cs-str; + <tbody valign="top"> + <row> + <entry>struct <link linkend="v4l2-mpeg-vbi-itv0-line"> + <structname>v4l2_mpeg_vbi_itv0_line</structname></link> + </entry> + <entry><structfield>line</structfield>[36]</entry> + <entry>A fixed length array of 36 lines of sliced VBI +data. <structfield>line</structfield>[0] through <structfield>line +</structfield>[17] correspond to lines 6 through 23 of the +first field. <structfield>line</structfield>[18] through +<structfield>line</structfield>[35] corresponds to lines 6 +through 23 of the second field.</entry> + </row> + </tbody> + </tgroup> + </table> + + <table frame="none" pgwide="1" id="v4l2-mpeg-vbi-itv0-line"> + <title>struct <structname>v4l2_mpeg_vbi_itv0_line</structname> + </title> + <tgroup cols="3"> + &cs-str; + <tbody valign="top"> + <row> + <entry>__u8</entry> + <entry><structfield>id</structfield></entry> + <entry>A line identifier value from +<xref linkend="ITV0-Line-Identifier-Constants" /> that indicates +the type of sliced VBI data stored on this line.</entry> + </row> + <row> + <entry>__u8</entry> + <entry><structfield>data</structfield>[42]</entry> + <entry>The sliced VBI data for the line.</entry> + </row> + </tbody> + </tgroup> + </table> + + <table frame="none" pgwide="1" id="ITV0-Line-Identifier-Constants"> + <title>Line Identifiers for struct <link + linkend="v4l2-mpeg-vbi-itv0-line"><structname> +v4l2_mpeg_vbi_itv0_line</structname></link> <structfield>id +</structfield> field</title> + <tgroup cols="3"> + &cs-def; + <thead> + <row> + <entry align="left">Defined Symbol</entry> + <entry align="left">Value</entry> + <entry align="left">Description</entry> + </row> + </thead> + <tbody valign="top"> + <row> + <entry><constant>V4L2_MPEG_VBI_IVTV_TELETEXT_B</constant> + </entry> + <entry>1</entry> + <entry>Refer to <link linkend="vbi-services2"> +Sliced VBI services</link> for a description of the line payload.</entry> + </row> + <row> + <entry><constant>V4L2_MPEG_VBI_IVTV_CAPTION_525</constant> + </entry> + <entry>4</entry> + <entry>Refer to <link linkend="vbi-services2"> +Sliced VBI services</link> for a description of the line payload.</entry> + </row> + <row> + <entry><constant>V4L2_MPEG_VBI_IVTV_WSS_625</constant> + </entry> + <entry>5</entry> + <entry>Refer to <link linkend="vbi-services2"> +Sliced VBI services</link> for a description of the line payload.</entry> + </row> + <row> + <entry><constant>V4L2_MPEG_VBI_IVTV_VPS</constant> + </entry> + <entry>7</entry> + <entry>Refer to <link linkend="vbi-services2"> +Sliced VBI services</link> for a description of the line payload.</entry> + </row> + </tbody> + </tgroup> + </table> + + </section> + </section> + + +<!-- +Local Variables: +mode: sgml +sgml-parent-document: "v4l2.sgml" +indent-tabs-mode: nil +End: + --> diff --git a/Documentation/DocBook/v4l/dev-teletext.xml b/Documentation/DocBook/v4l/dev-teletext.xml new file mode 100644 index 000000000000..76184e8ed618 --- /dev/null +++ b/Documentation/DocBook/v4l/dev-teletext.xml @@ -0,0 +1,40 @@ + <title>Teletext Interface</title> + + <para>This interface aims at devices receiving and demodulating +Teletext data [<xref linkend="ets300706" />, <xref linkend="itu653" />], evaluating the +Teletext packages and storing formatted pages in cache memory. Such +devices are usually implemented as microcontrollers with serial +interface (I<superscript>2</superscript>C) and can be found on older +TV cards, dedicated Teletext decoding cards and home-brew devices +connected to the PC parallel port.</para> + + <para>The Teletext API was designed by Martin Buck. It is defined in +the kernel header file <filename>linux/videotext.h</filename>, the +specification is available from <ulink url="ftp://ftp.gwdg.de/pub/linux/misc/videotext/"> +ftp://ftp.gwdg.de/pub/linux/misc/videotext/</ulink>. (Videotext is the name of +the German public television Teletext service.) Conventional character +device file names are <filename>/dev/vtx</filename> and +<filename>/dev/vttuner</filename>, with device number 83, 0 and 83, 16 +respectively. A similar interface exists for the Philips SAA5249 +Teletext decoder [specification?] with character device file names +<filename>/dev/tlkN</filename>, device number 102, N.</para> + + <para>Eventually the Teletext API was integrated into the V4L API +with character device file names <filename>/dev/vtx0</filename> to +<filename>/dev/vtx31</filename>, device major number 81, minor numbers +192 to 223. For reference the V4L Teletext API specification is +reproduced here in full: "Teletext interfaces talk the existing VTX +API." Teletext devices with major number 83 and 102 will be removed in +Linux 2.6.</para> + + <para>There are no plans to replace the Teletext API or to integrate +it into V4L2. Please write to the linux-media mailing list: &v4l-ml; +when the need arises.</para> + + <!-- +Local Variables: +mode: sgml +sgml-parent-document: "v4l2.sgml" +indent-tabs-mode: nil +End: + --> diff --git a/Documentation/DocBook/v4l/driver.xml b/Documentation/DocBook/v4l/driver.xml new file mode 100644 index 000000000000..1f7eea5c4ec3 --- /dev/null +++ b/Documentation/DocBook/v4l/driver.xml @@ -0,0 +1,208 @@ + <title>V4L2 Driver Programming</title> + + <!-- This part defines the interface between the "videodev" + module and individual drivers. --> + + <para>to do</para> +<!-- + <para>V4L2 is a two-layer driver system. The top layer is the "videodev" +kernel module. When videodev initializes it registers as character device +with major number 81, and it registers a set of file operations. All V4L2 +drivers are really clients of videodev, which calls V4L2 drivers through +driver method functions. V4L2 drivers are also written as kernel modules. +After probing the hardware they register one or more devices with +videodev.</para> + + <section id="driver-modules"> + <title>Driver Modules</title> + + <para>V4L2 driver modules must have an initialization function which is +called after the module was loaded into kernel, an exit function whis is +called before the module is removed. When the driver is compiled into the +kernel these functions called at system boot and shutdown time.</para> + + <informalexample> + <programlisting> +#include <linux/module.h> + +/* Export information about this module. For details and other useful + macros see <filename>linux/module.h</filename>. */ +MODULE_DESCRIPTION("my - driver for my hardware"); +MODULE_AUTHOR("Your name here"); +MODULE_LICENSE("GPL"); + +static void +my_module_exit (void) +{ + /* Free all resources allocated by my_module_init(). */ +} + +static int +my_module_init (void) +{ + /* Bind the driver to the supported hardware, see + <link linkend="driver-pci"> and + <link linkend="driver-usb"> for examples. */ + + return 0; /* a negative value on error, 0 on success. */ +} + +/* Export module functions. */ +module_init (my_module_init); +module_exit (my_module_exit); +</programlisting> + </informalexample> + + <para>Users can add parameters when kernel modules are inserted:</para> + + <informalexample> + <programlisting> +include <linux/moduleparam.h> + +static int my_option = 123; +static int my_option_array[47]; + +/* Export the symbol, an int, with access permissions 0664. + See <filename>linux/moduleparam.h</filename> for other types. */ +module_param (my_option, int, 0644); +module_param_array (my_option_array, int, NULL, 0644); + +MODULE_PARM_DESC (my_option, "Does magic things, default 123"); +</programlisting> + </informalexample> + + <para>One parameter should be supported by all V4L2 drivers, the minor +number of the device it will register. Purpose is to predictably link V4L2 +drivers to device nodes if more than one video device is installed. Use the +name of the device node followed by a "_nr" suffix, for example "video_nr" +for <filename>/dev/video</filename>.</para> + + <informalexample> + <programlisting> +/* Minor number of the device, -1 to allocate the first unused. */ +static int video_nr = -1; + +module_param (video_nr, int, 0444); +</programlisting> + </informalexample> + </section> + + <section id="driver-pci"> + <title>PCI Devices</title> + + <para>PCI devices are initialized like this:</para> + + <informalexample> + <programlisting> +typedef struct { + /* State of one physical device. */ +} my_device; + +static int +my_resume (struct pci_dev * pci_dev) +{ + /* Restore the suspended device to working state. */ +} + +static int +my_suspend (struct pci_dev * pci_dev, + pm_message_t state) +{ + /* This function is called before the system goes to sleep. + Stop all DMAs and disable interrupts, then put the device + into a low power state. For details see the kernel + sources under <filename>Documentation/power</filename>. */ + + return 0; /* a negative value on error, 0 on success. */ +} + +static void __devexit +my_remove (struct pci_dev * pci_dev) +{ + my_device *my = pci_get_drvdata (pci_dev); + + /* Describe me. */ +} + +static int __devinit +my_probe (struct pci_dev * pci_dev, + const struct pci_device_id * pci_id) +{ + my_device *my; + + /* Describe me. */ + + /* You can allocate per-device data here and store a pointer + to it in the pci_dev structure. */ + my = ...; + pci_set_drvdata (pci_dev, my); + + return 0; /* a negative value on error, 0 on success. */ +} + +/* A list of supported PCI devices. */ +static struct pci_device_id +my_pci_device_ids [] = { + { PCI_VENDOR_ID_FOO, PCI_DEVICE_ID_BAR, + PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0 }, + { 0 } /* end of list */ +}; + +/* Load our module if supported PCI devices are installed. */ +MODULE_DEVICE_TABLE (pci, my_pci_device_ids); + +static struct pci_driver +my_pci_driver = { + .name = "my", + .id_table = my_pci_device_ids, + + .probe = my_probe, + .remove = __devexit_p (my_remove), + + /* Power management functions. */ + .suspend = my_suspend, + .resume = my_resume, +}; + +static void +my_module_exit (void) +{ + pci_unregister_driver (&my_pci_driver); +} + +static int +my_module_init (void) +{ + return pci_register_driver (&my_pci_driver); +} +</programlisting> + </informalexample> + </section> + + <section id="driver-usb"> + <title>USB Devices</title> + <para>to do</para> + </section> + <section id="driver-registering"> + <title>Registering V4L2 Drivers</title> + + <para>After a V4L2 driver probed the hardware it registers one or more +devices with the videodev module.</para> + </section> + <section id="driver-file-ops"> + <title>File Operations</title> + <para>to do</para> + </section> + <section id="driver-internal-api"> + <title>Internal API</title> + <para>to do</para> + </section> +--> + +<!-- +Local Variables: +mode: sgml +sgml-parent-document: "v4l2.sgml" +indent-tabs-mode: nil +End: +--> diff --git a/Documentation/DocBook/v4l/fdl-appendix.xml b/Documentation/DocBook/v4l/fdl-appendix.xml new file mode 100644 index 000000000000..b6ce50dbe492 --- /dev/null +++ b/Documentation/DocBook/v4l/fdl-appendix.xml @@ -0,0 +1,671 @@ +<!-- + The GNU Free Documentation License 1.1 in DocBook + Markup by Eric Baudais <baudais@okstate.edu> + Maintained by the GNOME Documentation Project + http://developer.gnome.org/projects/gdp + Version: 1.0.1 + Last Modified: Nov 16, 2000 +--> + +<appendix id="fdl"> + <appendixinfo> + <releaseinfo> + Version 1.1, March 2000 + </releaseinfo> + <copyright> + <year>2000</year><holder>Free Software Foundation, Inc.</holder> + </copyright> + <legalnotice id="fdl-legalnotice"> + <para> + <address>Free Software Foundation, Inc. <street>59 Temple Place, + Suite 330</street>, <city>Boston</city>, <state>MA</state> + <postcode>02111-1307</postcode> <country>USA</country></address> + Everyone is permitted to copy and distribute verbatim copies of this + license document, but changing it is not allowed. + </para> + </legalnotice> + </appendixinfo> + <title>GNU Free Documentation License</title> + + <sect1 id="fdl-preamble"> + <title>0. PREAMBLE</title> + <para> + The purpose of this License is to make a manual, textbook, or + other written document <quote>free</quote> in the sense of + freedom: to assure everyone the effective freedom to copy and + redistribute it, with or without modifying it, either + commercially or noncommercially. Secondarily, this License + preserves for the author and publisher a way to get credit for + their work, while not being considered responsible for + modifications made by others. + </para> + + <para> + This License is a kind of <quote>copyleft</quote>, which means + that derivative works of the document must themselves be free in + the same sense. It complements the GNU General Public License, + which is a copyleft license designed for free software. + </para> + + <para> + We have designed this License in order to use it for manuals for + free software, because free software needs free documentation: a + free program should come with manuals providing the same + freedoms that the software does. But this License is not limited + to software manuals; it can be used for any textual work, + regardless of subject matter or whether it is published as a + printed book. We recommend this License principally for works + whose purpose is instruction or reference. + </para> + </sect1> + <sect1 id="fdl-section1"> + <title>1. APPLICABILITY AND DEFINITIONS</title> + <para id="fdl-document"> + This License applies to any manual or other work that contains a + notice placed by the copyright holder saying it can be + distributed under the terms of this License. The + <quote>Document</quote>, below, refers to any such manual or + work. Any member of the public is a licensee, and is addressed + as <quote>you</quote>. + </para> + + <para id="fdl-modified"> + A <quote>Modified Version</quote> of the Document means any work + containing the Document or a portion of it, either copied + verbatim, or with modifications and/or translated into another + language. + </para> + + <para id="fdl-secondary"> + A <quote>Secondary Section</quote> is a named appendix or a + front-matter section of the <link + linkend="fdl-document">Document</link> that deals exclusively + with the relationship of the publishers or authors of the + Document to the Document's overall subject (or to related + matters) and contains nothing that could fall directly within + that overall subject. (For example, if the Document is in part a + textbook of mathematics, a Secondary Section may not explain any + mathematics.) The relationship could be a matter of historical + connection with the subject or with related matters, or of + legal, commercial, philosophical, ethical or political position + regarding them. + </para> + + <para id="fdl-invariant"> + The <quote>Invariant Sections</quote> are certain <link + linkend="fdl-secondary"> Secondary Sections</link> whose titles + are designated, as being those of Invariant Sections, in the + notice that says that the <link + linkend="fdl-document">Document</link> is released under this + License. + </para> + + <para id="fdl-cover-texts"> + The <quote>Cover Texts</quote> are certain short passages of + text that are listed, as Front-Cover Texts or Back-Cover Texts, + in the notice that says that the <link + linkend="fdl-document">Document</link> is released under this + License. + </para> + + <para id="fdl-transparent"> + A <quote>Transparent</quote> copy of the <link + linkend="fdl-document"> Document</link> means a machine-readable + copy, represented in a format whose specification is available + to the general public, whose contents can be viewed and edited + directly and straightforwardly with generic text editors or (for + images composed of pixels) generic paint programs or (for + drawings) some widely available drawing editor, and that is + suitable for input to text formatters or for automatic + translation to a variety of formats suitable for input to text + formatters. A copy made in an otherwise Transparent file format + whose markup has been designed to thwart or discourage + subsequent modification by readers is not Transparent. A copy + that is not <quote>Transparent</quote> is called + <quote>Opaque</quote>. + </para> + + <para> + Examples of suitable formats for Transparent copies include + plain ASCII without markup, Texinfo input format, LaTeX input + format, SGML or XML using a publicly available DTD, and + standard-conforming simple HTML designed for human + modification. Opaque formats include PostScript, PDF, + proprietary formats that can be read and edited only by + proprietary word processors, SGML or XML for which the DTD + and/or processing tools are not generally available, and the + machine-generated HTML produced by some word processors for + output purposes only. + </para> + + <para id="fdl-title-page"> + The <quote>Title Page</quote> means, for a printed book, the + title page itself, plus such following pages as are needed to + hold, legibly, the material this License requires to appear in + the title page. For works in formats which do not have any title + page as such, <quote>Title Page</quote> means the text near the + most prominent appearance of the work's title, preceding the + beginning of the body of the text. + </para> + </sect1> + + <sect1 id="fdl-section2"> + <title>2. VERBATIM COPYING</title> + <para> + You may copy and distribute the <link + linkend="fdl-document">Document</link> in any medium, either + commercially or noncommercially, provided that this License, the + copyright notices, and the license notice saying this License + applies to the Document are reproduced in all copies, and that + you add no other conditions whatsoever to those of this + License. You may not use technical measures to obstruct or + control the reading or further copying of the copies you make or + distribute. However, you may accept compensation in exchange for + copies. If you distribute a large enough number of copies you + must also follow the conditions in <link + linkend="fdl-section3">section 3</link>. + </para> + + <para> + You may also lend copies, under the same conditions stated + above, and you may publicly display copies. + </para> + </sect1> + + <sect1 id="fdl-section3"> + <title>3. COPYING IN QUANTITY</title> + <para> + If you publish printed copies of the <link + linkend="fdl-document">Document</link> numbering more than 100, + and the Document's license notice requires <link + linkend="fdl-cover-texts">Cover Texts</link>, you must enclose + the copies in covers that carry, clearly and legibly, all these + Cover Texts: Front-Cover Texts on the front cover, and + Back-Cover Texts on the back cover. Both covers must also + clearly and legibly identify you as the publisher of these + copies. The front cover must present the full title with all + words of the title equally prominent and visible. You may add + other material on the covers in addition. Copying with changes + limited to the covers, as long as they preserve the title of the + <link linkend="fdl-document">Document</link> and satisfy these + conditions, can be treated as verbatim copying in other + respects. + </para> + + <para> + If the required texts for either cover are too voluminous to fit + legibly, you should put the first ones listed (as many as fit + reasonably) on the actual cover, and continue the rest onto + adjacent pages. + </para> + + <para> + If you publish or distribute <link + linkend="fdl-transparent">Opaque</link> copies of the <link + linkend="fdl-document">Document</link> numbering more than 100, + you must either include a machine-readable <link + linkend="fdl-transparent">Transparent</link> copy along with + each Opaque copy, or state in or with each Opaque copy a + publicly-accessible computer-network location containing a + complete Transparent copy of the Document, free of added + material, which the general network-using public has access to + download anonymously at no charge using public-standard network + protocols. If you use the latter option, you must take + reasonably prudent steps, when you begin distribution of Opaque + copies in quantity, to ensure that this Transparent copy will + remain thus accessible at the stated location until at least one + year after the last time you distribute an Opaque copy (directly + or through your agents or retailers) of that edition to the + public. + </para> + + <para> + It is requested, but not required, that you contact the authors + of the <link linkend="fdl-document">Document</link> well before + redistributing any large number of copies, to give them a chance + to provide you with an updated version of the Document. + </para> + </sect1> + + <sect1 id="fdl-section4"> + <title>4. MODIFICATIONS</title> + <para> + You may copy and distribute a <link + linkend="fdl-modified">Modified Version</link> of the <link + linkend="fdl-document">Document</link> under the conditions of + sections <link linkend="fdl-section2">2</link> and <link + linkend="fdl-section3">3</link> above, provided that you release + the Modified Version under precisely this License, with the + Modified Version filling the role of the Document, thus + licensing distribution and modification of the Modified Version + to whoever possesses a copy of it. In addition, you must do + these things in the Modified Version: + </para> + + <itemizedlist mark="opencircle"> + <listitem> + <formalpara> + <title>A</title> + <para> + Use in the <link linkend="fdl-title-page">Title + Page</link> (and on the covers, if any) a title distinct + from that of the <link + linkend="fdl-document">Document</link>, and from those of + previous versions (which should, if there were any, be + listed in the History section of the Document). You may + use the same title as a previous version if the original + publisher of that version gives permission. + </para> + </formalpara> + </listitem> + + <listitem> + <formalpara> + <title>B</title> + <para> + List on the <link linkend="fdl-title-page">Title + Page</link>, as authors, one or more persons or entities + responsible for authorship of the modifications in the + <link linkend="fdl-modified">Modified Version</link>, + together with at least five of the principal authors of + the <link linkend="fdl-document">Document</link> (all of + its principal authors, if it has less than five). + </para> + </formalpara> + </listitem> + + <listitem> + <formalpara> + <title>C</title> + <para> + State on the <link linkend="fdl-title-page">Title + Page</link> the name of the publisher of the <link + linkend="fdl-modified">Modified Version</link>, as the + publisher. + </para> + </formalpara> + </listitem> + + <listitem> + <formalpara> + <title>D</title> + <para> + Preserve all the copyright notices of the <link + linkend="fdl-document">Document</link>. + </para> + </formalpara> + </listitem> + + <listitem> + <formalpara> + <title>E</title> + <para> + Add an appropriate copyright notice for your modifications + adjacent to the other copyright notices. + </para> + </formalpara> + </listitem> + + <listitem> + <formalpara> + <title>F</title> + <para> + Include, immediately after the copyright notices, a + license notice giving the public permission to use the + <link linkend="fdl-modified">Modified Version</link> under + the terms of this License, in the form shown in the + Addendum below. + </para> + </formalpara> + </listitem> + + <listitem> + <formalpara> + <title>G</title> + <para> + Preserve in that license notice the full lists of <link + linkend="fdl-invariant"> Invariant Sections</link> and + required <link linkend="fdl-cover-texts">Cover + Texts</link> given in the <link + linkend="fdl-document">Document's</link> license notice. + </para> + </formalpara> + </listitem> + + <listitem> + <formalpara> + <title>H</title> + <para> + Include an unaltered copy of this License. + </para> + </formalpara> + </listitem> + + <listitem> + <formalpara> + <title>I</title> + <para> + Preserve the section entitled <quote>History</quote>, and + its title, and add to it an item stating at least the + title, year, new authors, and publisher of the <link + linkend="fdl-modified">Modified Version </link>as given on + the <link linkend="fdl-title-page">Title Page</link>. If + there is no section entitled <quote>History</quote> in the + <link linkend="fdl-document">Document</link>, create one + stating the title, year, authors, and publisher of the + Document as given on its Title Page, then add an item + describing the Modified Version as stated in the previous + sentence. + </para> + </formalpara> + </listitem> + + <listitem> + <formalpara> + <title>J</title> + <para> + Preserve the network location, if any, given in the <link + linkend="fdl-document">Document</link> for public access + to a <link linkend="fdl-transparent">Transparent</link> + copy of the Document, and likewise the network locations + given in the Document for previous versions it was based + on. These may be placed in the <quote>History</quote> + section. You may omit a network location for a work that + was published at least four years before the Document + itself, or if the original publisher of the version it + refers to gives permission. + </para> + </formalpara> + </listitem> + + <listitem> + <formalpara> + <title>K</title> + <para> + In any section entitled <quote>Acknowledgements</quote> or + <quote>Dedications</quote>, preserve the section's title, + and preserve in the section all the substance and tone of + each of the contributor acknowledgements and/or + dedications given therein. + </para> + </formalpara> + </listitem> + + <listitem> + <formalpara> + <title>L</title> + <para> + Preserve all the <link linkend="fdl-invariant">Invariant + Sections</link> of the <link + linkend="fdl-document">Document</link>, unaltered in their + text and in their titles. Section numbers or the + equivalent are not considered part of the section titles. + </para> + </formalpara> + </listitem> + + <listitem> + <formalpara> + <title>M</title> + <para> + Delete any section entitled + <quote>Endorsements</quote>. Such a section may not be + included in the <link linkend="fdl-modified">Modified + Version</link>. + </para> + </formalpara> + </listitem> + + <listitem> + <formalpara> + <title>N</title> + <para> + Do not retitle any existing section as + <quote>Endorsements</quote> or to conflict in title with + any <link linkend="fdl-invariant">Invariant + Section</link>. + </para> + </formalpara> + </listitem> + </itemizedlist> + + <para> + If the <link linkend="fdl-modified">Modified Version</link> + includes new front-matter sections or appendices that qualify as + <link linkend="fdl-secondary">Secondary Sections</link> and + contain no material copied from the Document, you may at your + option designate some or all of these sections as invariant. To + do this, add their titles to the list of <link + linkend="fdl-invariant">Invariant Sections</link> in the + Modified Version's license notice. These titles must be + distinct from any other section titles. + </para> + + <para> + You may add a section entitled <quote>Endorsements</quote>, + provided it contains nothing but endorsements of your <link + linkend="fdl-modified">Modified Version</link> by various + parties--for example, statements of peer review or that the text + has been approved by an organization as the authoritative + definition of a standard. + </para> + + <para> + You may add a passage of up to five words as a <link + linkend="fdl-cover-texts">Front-Cover Text</link>, and a passage + of up to 25 words as a <link + linkend="fdl-cover-texts">Back-Cover Text</link>, to the end of + the list of <link linkend="fdl-cover-texts">Cover Texts</link> + in the <link linkend="fdl-modified">Modified Version</link>. + Only one passage of Front-Cover Text and one of Back-Cover Text + may be added by (or through arrangements made by) any one + entity. If the <link linkend="fdl-document">Document</link> + already includes a cover text for the same cover, previously + added by you or by arrangement made by the same entity you are + acting on behalf of, you may not add another; but you may + replace the old one, on explicit permission from the previous + publisher that added the old one. + </para> + + <para> + The author(s) and publisher(s) of the <link + linkend="fdl-document">Document</link> do not by this License + give permission to use their names for publicity for or to + assert or imply endorsement of any <link + linkend="fdl-modified">Modified Version </link>. + </para> + </sect1> + + <sect1 id="fdl-section5"> + <title>5. COMBINING DOCUMENTS</title> + <para> + You may combine the <link linkend="fdl-document">Document</link> + with other documents released under this License, under the + terms defined in <link linkend="fdl-section4">section 4</link> + above for modified versions, provided that you include in the + combination all of the <link linkend="fdl-invariant">Invariant + Sections</link> of all of the original documents, unmodified, + and list them all as Invariant Sections of your combined work in + its license notice. + </para> + + <para> + The combined work need only contain one copy of this License, + and multiple identical <link linkend="fdl-invariant">Invariant + Sections</link> may be replaced with a single copy. If there are + multiple Invariant Sections with the same name but different + contents, make the title of each such section unique by adding + at the end of it, in parentheses, the name of the original + author or publisher of that section if known, or else a unique + number. Make the same adjustment to the section titles in the + list of Invariant Sections in the license notice of the combined + work. + </para> + + <para> + In the combination, you must combine any sections entitled + <quote>History</quote> in the various original documents, + forming one section entitled <quote>History</quote>; likewise + combine any sections entitled <quote>Acknowledgements</quote>, + and any sections entitled <quote>Dedications</quote>. You must + delete all sections entitled <quote>Endorsements.</quote> + </para> + </sect1> + + <sect1 id="fdl-section6"> + <title>6. COLLECTIONS OF DOCUMENTS</title> + <para> + You may make a collection consisting of the <link + linkend="fdl-document">Document</link> and other documents + released under this License, and replace the individual copies + of this License in the various documents with a single copy that + is included in the collection, provided that you follow the + rules of this License for verbatim copying of each of the + documents in all other respects. + </para> + + <para> + You may extract a single document from such a collection, and + dispbibute it individually under this License, provided you + insert a copy of this License into the extracted document, and + follow this License in all other respects regarding verbatim + copying of that document. + </para> + </sect1> + + <sect1 id="fdl-section7"> + <title>7. AGGREGATION WITH INDEPENDENT WORKS</title> + <para> + A compilation of the <link + linkend="fdl-document">Document</link> or its derivatives with + other separate and independent documents or works, in or on a + volume of a storage or distribution medium, does not as a whole + count as a <link linkend="fdl-modified">Modified Version</link> + of the Document, provided no compilation copyright is claimed + for the compilation. Such a compilation is called an + <quote>aggregate</quote>, and this License does not apply to the + other self-contained works thus compiled with the Document , on + account of their being thus compiled, if they are not themselves + derivative works of the Document. If the <link + linkend="fdl-cover-texts">Cover Text</link> requirement of <link + linkend="fdl-section3">section 3</link> is applicable to these + copies of the Document, then if the Document is less than one + quarter of the entire aggregate, the Document's Cover Texts may + be placed on covers that surround only the Document within the + aggregate. Otherwise they must appear on covers around the whole + aggregate. + </para> + </sect1> + + <sect1 id="fdl-section8"> + <title>8. TRANSLATION</title> + <para> + Translation is considered a kind of modification, so you may + distribute translations of the <link + linkend="fdl-document">Document</link> under the terms of <link + linkend="fdl-section4">section 4</link>. Replacing <link + linkend="fdl-invariant"> Invariant Sections</link> with + translations requires special permission from their copyright + holders, but you may include translations of some or all + Invariant Sections in addition to the original versions of these + Invariant Sections. You may include a translation of this + License provided that you also include the original English + version of this License. In case of a disagreement between the + translation and the original English version of this License, + the original English version will prevail. + </para> + </sect1> + + <sect1 id="fdl-section9"> + <title>9. TERMINATION</title> + <para> + You may not copy, modify, sublicense, or distribute the <link + linkend="fdl-document">Document</link> except as expressly + provided for under this License. Any other attempt to copy, + modify, sublicense or distribute the Document is void, and will + automatically terminate your rights under this License. However, + parties who have received copies, or rights, from you under this + License will not have their licenses terminated so long as such + parties remain in full compliance. + </para> + </sect1> + + <sect1 id="fdl-section10"> + <title>10. FUTURE REVISIONS OF THIS LICENSE</title> + <para> + The <ulink type="http" + url="http://www.gnu.org/fsf/fsf.html">Free Software + Foundation</ulink> may publish new, revised versions of the GNU + Free Documentation License from time to time. Such new versions + will be similar in spirit to the present version, but may differ + in detail to address new problems or concerns. See <ulink + type="http" + url="http://www.gnu.org/copyleft">http://www.gnu.org/copyleft/</ulink>. + </para> + + <para> + Each version of the License is given a distinguishing version + number. If the <link linkend="fdl-document">Document</link> + specifies that a particular numbered version of this License + <quote>or any later version</quote> applies to it, you have the + option of following the terms and conditions either of that + specified version or of any later version that has been + published (not as a draft) by the Free Software Foundation. If + the Document does not specify a version number of this License, + you may choose any version ever published (not as a draft) by + the Free Software Foundation. + </para> + </sect1> + + <sect1 id="fdl-using"> + <title>Addendum</title> + <para> + To use this License in a document you have written, include a copy of + the License in the document and put the following copyright and + license notices just after the title page: + </para> + + <blockquote> + <para> + Copyright © YEAR YOUR NAME. + </para> + <para> + Permission is granted to copy, distribute and/or modify this + document under the terms of the GNU Free Documentation + License, Version 1.1 or any later version published by the + Free Software Foundation; with the <link + linkend="fdl-invariant">Invariant Sections</link> being LIST + THEIR TITLES, with the <link + linkend="fdl-cover-texts">Front-Cover Texts</link> being LIST, + and with the <link linkend="fdl-cover-texts">Back-Cover + Texts</link> being LIST. A copy of the license is included in + the section entitled <quote>GNU Free Documentation + License</quote>. + </para> + </blockquote> + + <para> + If you have no <link linkend="fdl-invariant">Invariant + Sections</link>, write <quote>with no Invariant Sections</quote> + instead of saying which ones are invariant. If you have no + <link linkend="fdl-cover-texts">Front-Cover Texts</link>, write + <quote>no Front-Cover Texts</quote> instead of + <quote>Front-Cover Texts being LIST</quote>; likewise for <link + linkend="fdl-cover-texts">Back-Cover Texts</link>. + </para> + + <para> + If your document contains nontrivial examples of program code, + we recommend releasing these examples in parallel under your + choice of free software license, such as the <ulink type="http" + url="http://www.gnu.org/copyleft/gpl.html"> GNU General Public + License</ulink>, to permit their use in free software. + </para> + </sect1> +</appendix> + + + + + + diff --git a/Documentation/DocBook/v4l/fieldseq_bt.gif b/Documentation/DocBook/v4l/fieldseq_bt.gif Binary files differnew file mode 100644 index 000000000000..60e8569a76c9 --- /dev/null +++ b/Documentation/DocBook/v4l/fieldseq_bt.gif diff --git a/Documentation/DocBook/v4l/fieldseq_bt.pdf b/Documentation/DocBook/v4l/fieldseq_bt.pdf Binary files differnew file mode 100644 index 000000000000..26598b23f80d --- /dev/null +++ b/Documentation/DocBook/v4l/fieldseq_bt.pdf diff --git a/Documentation/DocBook/v4l/fieldseq_tb.gif b/Documentation/DocBook/v4l/fieldseq_tb.gif Binary files differnew file mode 100644 index 000000000000..718492f1cfc7 --- /dev/null +++ b/Documentation/DocBook/v4l/fieldseq_tb.gif diff --git a/Documentation/DocBook/v4l/fieldseq_tb.pdf b/Documentation/DocBook/v4l/fieldseq_tb.pdf Binary files differnew file mode 100644 index 000000000000..4965b22ddb3a --- /dev/null +++ b/Documentation/DocBook/v4l/fieldseq_tb.pdf diff --git a/Documentation/DocBook/v4l/func-close.xml b/Documentation/DocBook/v4l/func-close.xml new file mode 100644 index 000000000000..dfb41cbbbec3 --- /dev/null +++ b/Documentation/DocBook/v4l/func-close.xml @@ -0,0 +1,70 @@ +<refentry id="func-close"> + <refmeta> + <refentrytitle>V4L2 close()</refentrytitle> + &manvol; + </refmeta> + + <refnamediv> + <refname>v4l2-close</refname> + <refpurpose>Close a V4L2 device</refpurpose> + </refnamediv> + + <refsynopsisdiv> + <funcsynopsis> + <funcsynopsisinfo>#include <unistd.h></funcsynopsisinfo> + <funcprototype> + <funcdef>int <function>close</function></funcdef> + <paramdef>int <parameter>fd</parameter></paramdef> + </funcprototype> + </funcsynopsis> + </refsynopsisdiv> + + <refsect1> + <title>Arguments</title> + + <variablelist> + <varlistentry> + <term><parameter>fd</parameter></term> + <listitem> + <para>&fd;</para> + </listitem> + </varlistentry> + </variablelist> + </refsect1> + + <refsect1> + <title>Description</title> + + <para>Closes the device. Any I/O in progress is terminated and +resources associated with the file descriptor are freed. However data +format parameters, current input or output, control values or other +properties remain unchanged.</para> + </refsect1> + + <refsect1> + <title>Return Value</title> + + <para>The function returns <returnvalue>0</returnvalue> on +success, <returnvalue>-1</returnvalue> on failure and the +<varname>errno</varname> is set appropriately. Possible error +codes:</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> + +<!-- +Local Variables: +mode: sgml +sgml-parent-document: "v4l2.sgml" +indent-tabs-mode: nil +End: +--> diff --git a/Documentation/DocBook/v4l/func-ioctl.xml b/Documentation/DocBook/v4l/func-ioctl.xml new file mode 100644 index 000000000000..00f9690e1c28 --- /dev/null +++ b/Documentation/DocBook/v4l/func-ioctl.xml @@ -0,0 +1,146 @@ +<refentry id="func-ioctl"> + <refmeta> + <refentrytitle>V4L2 ioctl()</refentrytitle> + &manvol; + </refmeta> + + <refnamediv> + <refname>v4l2-ioctl</refname> + <refpurpose>Program a V4L2 device</refpurpose> + </refnamediv> + + <refsynopsisdiv> + <funcsynopsis> + <funcsynopsisinfo>#include <sys/ioctl.h></funcsynopsisinfo> + <funcprototype> + <funcdef>int <function>ioctl</function></funcdef> + <paramdef>int <parameter>fd</parameter></paramdef> + <paramdef>int <parameter>request</parameter></paramdef> + <paramdef>void *<parameter>argp</parameter></paramdef> + </funcprototype> + </funcsynopsis> + </refsynopsisdiv> + + <refsect1> + <title>Arguments</title> + + <variablelist> + <varlistentry> + <term><parameter>fd</parameter></term> + <listitem> + <para>&fd;</para> + </listitem> + </varlistentry> + <varlistentry> + <term><parameter>request</parameter></term> + <listitem> + <para>V4L2 ioctl request code as defined in the <link +linkend="videodev">videodev.h</link> header file, for example +VIDIOC_QUERYCAP.</para> + </listitem> + </varlistentry> + <varlistentry> + <term><parameter>argp</parameter></term> + <listitem> + <para>Pointer to a function parameter, usually a structure.</para> + </listitem> + </varlistentry> + </variablelist> + </refsect1> + + <refsect1> + <title>Description</title> + + <para>The <function>ioctl()</function> function is used to program +V4L2 devices. The argument <parameter>fd</parameter> must be an open +file descriptor. An ioctl <parameter>request</parameter> 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. Macros and defines specifying V4L2 ioctl requests are located +in the <link linkend="videodev">videodev.h</link> header file. +Applications should use their own copy, not include the version in the +kernel sources on the system they compile on. All V4L2 ioctl requests, +their respective function and parameters are specified in <xref + linkend="user-func" />.</para> + </refsect1> + + <refsect1> + <title>Return Value</title> + + <para>On success the <function>ioctl()</function> function returns +<returnvalue>0</returnvalue> and does not reset the +<varname>errno</varname> variable. On failure +<returnvalue>-1</returnvalue> is returned, when the ioctl takes an +output or read/write parameter it remains unmodified, and the +<varname>errno</varname> variable is set appropriately. See below for +possible error codes. Generic errors like <errorcode>EBADF</errorcode> +or <errorcode>EFAULT</errorcode> are not listed in the sections +discussing individual ioctl requests.</para> + <para>Note ioctls may return undefined error codes. Since errors +may have side effects such as a driver reset applications should +abort on unexpected errors.</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>EBUSY</errorcode></term> + <listitem> + <para>The property cannot be changed right now. Typically +this error code is returned when I/O is in progress or the driver +supports multiple opens and another process locked the property.</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>ENOTTY</errorcode></term> + <listitem> + <para><parameter>fd</parameter> is not associated with a +character special device.</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="user-func" /> for actual causes.</para> + </listitem> + </varlistentry> + <varlistentry> + <term><errorcode>ENOMEM</errorcode></term> + <listitem> + <para>Not enough physical or virtual memory was available to +complete the request.</para> + </listitem> + </varlistentry> + <varlistentry> + <term><errorcode>ERANGE</errorcode></term> + <listitem> + <para>The application attempted to set a control with the +&VIDIOC-S-CTRL; ioctl to a value which is out of bounds.</para> + </listitem> + </varlistentry> + </variablelist> + </refsect1> +</refentry> + +<!-- +Local Variables: +mode: sgml +sgml-parent-document: "v4l2.sgml" +indent-tabs-mode: nil +End: +--> diff --git a/Documentation/DocBook/v4l/func-mmap.xml b/Documentation/DocBook/v4l/func-mmap.xml new file mode 100644 index 000000000000..2e2fc3933aea --- /dev/null +++ b/Documentation/DocBook/v4l/func-mmap.xml @@ -0,0 +1,185 @@ +<refentry id="func-mmap"> + <refmeta> + <refentrytitle>V4L2 mmap()</refentrytitle> + &manvol; + </refmeta> + + <refnamediv> + <refname>v4l2-mmap</refname> + <refpurpose>Map device memory into application address space</refpurpose> + </refnamediv> + + <refsynopsisdiv> + <funcsynopsis> + <funcsynopsisinfo> +#include <unistd.h> +#include <sys/mman.h></funcsynopsisinfo> + <funcprototype> + <funcdef>void *<function>mmap</function></funcdef> + <paramdef>void *<parameter>start</parameter></paramdef> + <paramdef>size_t <parameter>length</parameter></paramdef> + <paramdef>int <parameter>prot</parameter></paramdef> + <paramdef>int <parameter>flags</parameter></paramdef> + <paramdef>int <parameter>fd</parameter></paramdef> + <paramdef>off_t <parameter>offset</parameter></paramdef> + </funcprototype> + </funcsynopsis> + </refsynopsisdiv> + + <refsect1> + <title>Arguments</title> + <variablelist> + <varlistentry> + <term><parameter>start</parameter></term> + <listitem> + <para>Map the buffer to this address in the +application's address space. When the <constant>MAP_FIXED</constant> +flag is specified, <parameter>start</parameter> must be a multiple of the +pagesize and mmap will fail when the specified address +cannot be used. Use of this option is discouraged; applications should +just specify a <constant>NULL</constant> pointer here.</para> + </listitem> + </varlistentry> + <varlistentry> + <term><parameter>length</parameter></term> + <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> + </listitem> + </varlistentry> + <varlistentry> + <term><parameter>prot</parameter></term> + <listitem> + <para>The <parameter>prot</parameter> argument describes the +desired memory protection. Regardless of the device type and the +direction of data exchange it should be set to +<constant>PROT_READ</constant> | <constant>PROT_WRITE</constant>, +permitting read and write access to image buffers. Drivers should +support at least this combination of flags. Note the Linux +<filename>video-buf</filename> kernel module, which is used by the +bttv, saa7134, saa7146, cx88 and vivi driver supports only +<constant>PROT_READ</constant> | <constant>PROT_WRITE</constant>. When +the driver does not support the desired protection the +<function>mmap()</function> function fails.</para> + <para>Note device memory accesses (⪚ the memory on a +graphics card with video capturing hardware) may incur a performance +penalty compared to main memory accesses, or reads may be +significantly slower than writes or vice versa. Other I/O methods may +be more efficient in this case.</para> + </listitem> + </varlistentry> + <varlistentry> + <term><parameter>flags</parameter></term> + <listitem> + <para>The <parameter>flags</parameter> parameter +specifies the type of the mapped object, mapping options and whether +modifications made to the mapped copy of the page are private to the +process or are to be shared with other references.</para> + <para><constant>MAP_FIXED</constant> requests that the +driver selects no other address than the one specified. If the +specified address cannot be used, <function>mmap()</function> will fail. If +<constant>MAP_FIXED</constant> is specified, +<parameter>start</parameter> must be a multiple of the pagesize. Use +of this option is discouraged.</para> + <para>One of the <constant>MAP_SHARED</constant> or +<constant>MAP_PRIVATE</constant> flags must be set. +<constant>MAP_SHARED</constant> allows applications to share the +mapped memory with other (⪚ child-) processes. Note the Linux +<filename>video-buf</filename> module which is used by the bttv, +saa7134, saa7146, cx88 and vivi driver supports only +<constant>MAP_SHARED</constant>. <constant>MAP_PRIVATE</constant> +requests copy-on-write semantics. V4L2 applications should not set the +<constant>MAP_PRIVATE</constant>, <constant>MAP_DENYWRITE</constant>, +<constant>MAP_EXECUTABLE</constant> or <constant>MAP_ANON</constant> +flag.</para> + </listitem> + </varlistentry> + <varlistentry> + <term><parameter>fd</parameter></term> + <listitem> + <para>&fd;</para> + </listitem> + </varlistentry> + <varlistentry> + <term><parameter>offset</parameter></term> + <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> + </listitem> + </varlistentry> + </variablelist> + </refsect1> + + <refsect1> + <title>Description</title> + + <para>The <function>mmap()</function> function asks to map +<parameter>length</parameter> bytes starting at +<parameter>offset</parameter> in the memory of the device specified by +<parameter>fd</parameter> into the application address space, +preferably at address <parameter>start</parameter>. This latter +address is a hint only, and is usually specified as 0.</para> + + <para>Suitable length and offset parameters are queried with the +&VIDIOC-QUERYBUF; ioctl. Buffers must be allocated with the +&VIDIOC-REQBUFS; ioctl before they can be queried.</para> + + <para>To unmap buffers the &func-munmap; function is used.</para> + </refsect1> + + <refsect1> + <title>Return Value</title> + + <para>On success <function>mmap()</function> returns a pointer to +the mapped buffer. On error <constant>MAP_FAILED</constant> (-1) is +returned, and the <varname>errno</varname> variable is set +appropriately. Possible error codes are:</para> + + <variablelist> + <varlistentry> + <term><errorcode>EBADF</errorcode></term> + <listitem> + <para><parameter>fd</parameter> is not a valid file +descriptor.</para> + </listitem> + </varlistentry> + <varlistentry> + <term><errorcode>EACCES</errorcode></term> + <listitem> + <para><parameter>fd</parameter> is +not open for reading and writing.</para> + </listitem> + </varlistentry> + <varlistentry> + <term><errorcode>EINVAL</errorcode></term> + <listitem> + <para>The <parameter>start</parameter> or +<parameter>length</parameter> or <parameter>offset</parameter> are not +suitable. (E. g. they are too large, or not aligned on a +<constant>PAGESIZE</constant> boundary.)</para> + <para>The <parameter>flags</parameter> or +<parameter>prot</parameter> value is not supported.</para> + <para>No buffers have been allocated with the +&VIDIOC-REQBUFS; ioctl.</para> + </listitem> + </varlistentry> + <varlistentry> + <term><errorcode>ENOMEM</errorcode></term> + <listitem> + <para>Not enough physical or virtual memory was available to +complete the request.</para> + </listitem> + </varlistentry> + </variablelist> + </refsect1> +</refentry> + +<!-- +Local Variables: +mode: sgml +sgml-parent-document: "v4l2.sgml" +indent-tabs-mode: nil +End: +--> diff --git a/Documentation/DocBook/v4l/func-munmap.xml b/Documentation/DocBook/v4l/func-munmap.xml new file mode 100644 index 000000000000..502ed49323b0 --- /dev/null +++ b/Documentation/DocBook/v4l/func-munmap.xml @@ -0,0 +1,83 @@ +<refentry id="func-munmap"> + <refmeta> + <refentrytitle>V4L2 munmap()</refentrytitle> + &manvol; + </refmeta> + + <refnamediv> + <refname>v4l2-munmap</refname> + <refpurpose>Unmap device memory</refpurpose> + </refnamediv> + + <refsynopsisdiv> + <funcsynopsis> + <funcsynopsisinfo> +#include <unistd.h> +#include <sys/mman.h></funcsynopsisinfo> + <funcprototype> + <funcdef>int <function>munmap</function></funcdef> + <paramdef>void *<parameter>start</parameter></paramdef> + <paramdef>size_t <parameter>length</parameter></paramdef> + </funcprototype> + </funcsynopsis> + </refsynopsisdiv> + <refsect1> + <title>Arguments</title> + <variablelist> + <varlistentry> + <term><parameter>start</parameter></term> + <listitem> + <para>Address of the mapped buffer as returned by the +&func-mmap; function.</para> + </listitem> + </varlistentry> + <varlistentry> + <term><parameter>length</parameter></term> + <listitem> + <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> + </listitem> + </varlistentry> + </variablelist> + </refsect1> + + <refsect1> + <title>Description</title> + + <para>Unmaps a previously with the &func-mmap; function mapped +buffer and frees it, if possible. <!-- ? This function (not freeing) +has no impact on I/O in progress, specifically it does not imply +&VIDIOC-STREAMOFF; to terminate I/O. Unmapped buffers can still be +enqueued, dequeued or queried, they are just not accessible by the +application.--></para> + </refsect1> + + <refsect1> + <title>Return Value</title> + + <para>On success <function>munmap()</function> returns 0, on +failure -1 and the <varname>errno</varname> variable is set +appropriately:</para> + + <variablelist> + <varlistentry> + <term><errorcode>EINVAL</errorcode></term> + <listitem> + <para>The <parameter>start</parameter> or +<parameter>length</parameter> is incorrect, or no buffers have been +mapped yet.</para> + </listitem> + </varlistentry> + </variablelist> + </refsect1> +</refentry> + +<!-- +Local Variables: +mode: sgml +sgml-parent-document: "v4l2.sgml" +indent-tabs-mode: nil +End: +--> diff --git a/Documentation/DocBook/v4l/func-open.xml b/Documentation/DocBook/v4l/func-open.xml new file mode 100644 index 000000000000..7595d07a8c72 --- /dev/null +++ b/Documentation/DocBook/v4l/func-open.xml @@ -0,0 +1,121 @@ +<refentry id="func-open"> + <refmeta> + <refentrytitle>V4L2 open()</refentrytitle> + &manvol; + </refmeta> + + <refnamediv> + <refname>v4l2-open</refname> + <refpurpose>Open a V4L2 device</refpurpose> + </refnamediv> + + <refsynopsisdiv> + <funcsynopsis> + <funcsynopsisinfo>#include <fcntl.h></funcsynopsisinfo> + <funcprototype> + <funcdef>int <function>open</function></funcdef> + <paramdef>const char *<parameter>device_name</parameter></paramdef> + <paramdef>int <parameter>flags</parameter></paramdef> + </funcprototype> + </funcsynopsis> + </refsynopsisdiv> + + <refsect1> + <title>Arguments</title> + + <variablelist> + <varlistentry> + <term><parameter>device_name</parameter></term> + <listitem> + <para>Device to be opened.</para> + </listitem> + </varlistentry> + <varlistentry> + <term><parameter>flags</parameter></term> + <listitem> + <para>Open flags. Access mode must be +<constant>O_RDWR</constant>. This is just a technicality, input devices +still support only reading and output devices only writing.</para> + <para>When the <constant>O_NONBLOCK</constant> flag is +given, the read() function and the &VIDIOC-DQBUF; ioctl will return +the &EAGAIN; when no data is available or no buffer is in the driver +outgoing queue, otherwise these functions block until data becomes +available. All V4L2 drivers exchanging data with applications must +support the <constant>O_NONBLOCK</constant> flag.</para> + <para>Other flags have no effect.</para> + </listitem> + </varlistentry> + </variablelist> + </refsect1> + <refsect1> + <title>Description</title> + + <para>To open a V4L2 device applications call +<function>open()</function> with the desired device name. This +function has no side effects; all data format parameters, current +input or output, control values or other properties remain unchanged. +At the first <function>open()</function> call after loading the driver +they will be reset to default values, drivers are never in an +undefined state.</para> + </refsect1> + <refsect1> + <title>Return Value</title> + + <para>On success <function>open</function> returns the new file +descriptor. On error -1 is returned, and the <varname>errno</varname> +variable is set appropriately. Possible error codes are:</para> + + <variablelist> + <varlistentry> + <term><errorcode>EACCES</errorcode></term> + <listitem> + <para>The caller has no permission to access the +device.</para> + </listitem> + </varlistentry> + <varlistentry> + <term><errorcode>EBUSY</errorcode></term> + <listitem> + <para>The driver does not support multiple opens and the +device is already in use.</para> + </listitem> + </varlistentry> + <varlistentry> + <term><errorcode>ENXIO</errorcode></term> + <listitem> + <para>No device corresponding to this device special file +exists.</para> + </listitem> + </varlistentry> + <varlistentry> + <term><errorcode>ENOMEM</errorcode></term> + <listitem> + <para>Not enough kernel memory was available to complete the +request.</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 limit on the total number of files open on the +system has been reached.</para> + </listitem> + </varlistentry> + </variablelist> + </refsect1> +</refentry> + +<!-- +Local Variables: +mode: sgml +sgml-parent-document: "v4l2.sgml" +indent-tabs-mode: nil +End: +--> diff --git a/Documentation/DocBook/v4l/func-poll.xml b/Documentation/DocBook/v4l/func-poll.xml new file mode 100644 index 000000000000..ec3c718f5963 --- /dev/null +++ b/Documentation/DocBook/v4l/func-poll.xml @@ -0,0 +1,127 @@ +<refentry id="func-poll"> + <refmeta> + <refentrytitle>V4L2 poll()</refentrytitle> + &manvol; + </refmeta> + + <refnamediv> + <refname>v4l2-poll</refname> + <refpurpose>Wait for some event on a file descriptor</refpurpose> + </refnamediv> + + <refsynopsisdiv> + <funcsynopsis> + <funcsynopsisinfo>#include <sys/poll.h></funcsynopsisinfo> + <funcprototype> + <funcdef>int <function>poll</function></funcdef> + <paramdef>struct pollfd *<parameter>ufds</parameter></paramdef> + <paramdef>unsigned int <parameter>nfds</parameter></paramdef> + <paramdef>int <parameter>timeout</parameter></paramdef> + </funcprototype> + </funcsynopsis> + </refsynopsisdiv> + + <refsect1> + <title>Description</title> + + <para>With the <function>poll()</function> function applications +can suspend execution until the driver has captured data or is ready +to accept data for output.</para> + + <para>When streaming I/O has been negotiated this function waits +until a buffer has been filled or displayed and can be dequeued with +the &VIDIOC-DQBUF; ioctl. When buffers are already in the outgoing +queue of the driver the function returns immediately.</para> + + <para>On success <function>poll()</function> returns the number of +file descriptors that have been selected (that is, file descriptors +for which the <structfield>revents</structfield> field of the +respective <structname>pollfd</structname> structure is non-zero). +Capture devices set the <constant>POLLIN</constant> and +<constant>POLLRDNORM</constant> flags in the +<structfield>revents</structfield> field, output devices the +<constant>POLLOUT</constant> and <constant>POLLWRNORM</constant> +flags. When the function timed out it returns a value of zero, on +failure it returns <returnvalue>-1</returnvalue> and the +<varname>errno</varname> variable is set appropriately. When the +application did not call &VIDIOC-QBUF; or &VIDIOC-STREAMON; yet the +<function>poll()</function> function succeeds, but sets the +<constant>POLLERR</constant> flag in the +<structfield>revents</structfield> field.</para> + + <para>When use of the <function>read()</function> function has +been negotiated and the driver does not capture yet, the +<function>poll</function> function starts capturing. When that fails +it returns a <constant>POLLERR</constant> as above. Otherwise it waits +until data has been captured and can be read. When the driver captures +continuously (as opposed to, for example, still images) the function +may return immediately.</para> + + <para>When use of the <function>write()</function> function has +been negotiated the <function>poll</function> function just waits +until the driver is ready for a non-blocking +<function>write()</function> call.</para> + + <para>All drivers implementing the <function>read()</function> or +<function>write()</function> function or streaming I/O must also +support the <function>poll()</function> function.</para> + + <para>For more details see the +<function>poll()</function> manual page.</para> + </refsect1> + + <refsect1> + <title>Return Value</title> + + <para>On success, <function>poll()</function> returns the number +structures which have non-zero <structfield>revents</structfield> +fields, or zero if the call timed out. On error +<returnvalue>-1</returnvalue> is returned, and the +<varname>errno</varname> variable is set appropriately:</para> + + <variablelist> + <varlistentry> + <term><errorcode>EBADF</errorcode></term> + <listitem> + <para>One or more of the <parameter>ufds</parameter> members +specify an invalid file descriptor.</para> + </listitem> + </varlistentry> + <varlistentry> + <term><errorcode>EBUSY</errorcode></term> + <listitem> + <para>The driver does not support multiple read or write +streams and the device is already in use.</para> + </listitem> + </varlistentry> + <varlistentry> + <term><errorcode>EFAULT</errorcode></term> + <listitem> + <para><parameter>ufds</parameter> references an inaccessible +memory area.</para> + </listitem> + </varlistentry> + <varlistentry> + <term><errorcode>EINTR</errorcode></term> + <listitem> + <para>The call was interrupted by a signal.</para> + </listitem> + </varlistentry> + <varlistentry> + <term><errorcode>EINVAL</errorcode></term> + <listitem> + <para>The <parameter>nfds</parameter> argument is greater +than <constant>OPEN_MAX</constant>.</para> + </listitem> + </varlistentry> + </variablelist> + </refsect1> +</refentry> + +<!-- +Local Variables: +mode: sgml +sgml-parent-document: "v4l2.sgml" +indent-tabs-mode: nil +End: +--> diff --git a/Documentation/DocBook/v4l/func-read.xml b/Documentation/DocBook/v4l/func-read.xml new file mode 100644 index 000000000000..a5089bf8873d --- /dev/null +++ b/Documentation/DocBook/v4l/func-read.xml @@ -0,0 +1,189 @@ +<refentry id="func-read"> + <refmeta> + <refentrytitle>V4L2 read()</refentrytitle> + &manvol; + </refmeta> + + <refnamediv> + <refname>v4l2-read</refname> + <refpurpose>Read from a V4L2 device</refpurpose> + </refnamediv> + + <refsynopsisdiv> + <funcsynopsis> + <funcsynopsisinfo>#include <unistd.h></funcsynopsisinfo> + <funcprototype> + <funcdef>ssize_t <function>read</function></funcdef> + <paramdef>int <parameter>fd</parameter></paramdef> + <paramdef>void *<parameter>buf</parameter></paramdef> + <paramdef>size_t <parameter>count</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>buf</parameter></term> + <listitem> + <para></para> + </listitem> + </varlistentry> + <varlistentry> + <term><parameter>count</parameter></term> + <listitem> + <para></para> + </listitem> + </varlistentry> + </variablelist> + </refsect1> + + <refsect1> + <title>Description</title> + + <para><function>read()</function> attempts to read up to +<parameter>count</parameter> bytes from file descriptor +<parameter>fd</parameter> into the buffer starting at +<parameter>buf</parameter>. The layout of the data in the buffer is +discussed in the respective device interface section, see ##. If <parameter>count</parameter> is zero, +<function>read()</function> returns zero and has no other results. If +<parameter>count</parameter> is greater than +<constant>SSIZE_MAX</constant>, the result is unspecified. Regardless +of the <parameter>count</parameter> value each +<function>read()</function> call will provide at most one frame (two +fields) worth of data.</para> + + <para>By default <function>read()</function> blocks until data +becomes available. When the <constant>O_NONBLOCK</constant> flag was +given to the &func-open; function it +returns immediately with an &EAGAIN; when no data is available. The +&func-select; or &func-poll; functions +can always be used to suspend execution until data becomes available. All +drivers supporting the <function>read()</function> function must also +support <function>select()</function> and +<function>poll()</function>.</para> + + <para>Drivers can implement read functionality in different +ways, using a single or multiple buffers and discarding the oldest or +newest frames once the internal buffers are filled.</para> + + <para><function>read()</function> never returns a "snapshot" of a +buffer being filled. Using a single buffer the driver will stop +capturing when the application starts reading the buffer until the +read is finished. Thus only the period of the vertical blanking +interval is available for reading, or the capture rate must fall below +the nominal frame rate of the video standard.</para> + +<para>The behavior of +<function>read()</function> when called during the active picture +period or the vertical blanking separating the top and bottom field +depends on the discarding policy. A driver discarding the oldest +frames keeps capturing into an internal buffer, continuously +overwriting the previously, not read frame, and returns the frame +being received at the time of the <function>read()</function> call as +soon as it is complete.</para> + + <para>A driver discarding the newest frames stops capturing until +the next <function>read()</function> call. The frame being received at +<function>read()</function> time is discarded, returning the following +frame instead. Again this implies a reduction of the capture rate to +one half or less of the nominal frame rate. An example of this model +is the video read mode of the bttv driver, initiating a DMA to user +memory when <function>read()</function> is called and returning when +the DMA finished.</para> + + <para>In the multiple buffer model drivers maintain a ring of +internal buffers, automatically advancing to the next free buffer. +This allows continuous capturing when the application can empty the +buffers fast enough. Again, the behavior when the driver runs out of +free buffers depends on the discarding policy.</para> + + <para>Applications can get and set the number of buffers used +internally by the driver with the &VIDIOC-G-PARM; and &VIDIOC-S-PARM; +ioctls. They are optional, however. The discarding policy is not +reported and cannot be changed. For minimum requirements see <xref + linkend="devices" />.</para> + </refsect1> + + <refsect1> + <title>Return Value</title> + + <para>On success, the number of bytes read is returned. It is not +an error if this number is smaller than the number of bytes requested, +or the amount of data required for one frame. This may happen for +example because <function>read()</function> was interrupted by a +signal. On error, -1 is returned, and the <varname>errno</varname> +variable is set appropriately. In this case the next read will start +at the beginning of a new frame. Possible error codes are:</para> + + <variablelist> + <varlistentry> + <term><errorcode>EAGAIN</errorcode></term> + <listitem> + <para>Non-blocking I/O has been selected using +O_NONBLOCK and no data was immediately available for reading.</para> + </listitem> + </varlistentry> + <varlistentry> + <term><errorcode>EBADF</errorcode></term> + <listitem> + <para><parameter>fd</parameter> is not a valid file +descriptor or is not open for reading, or the process already has the +maximum number of files open.</para> + </listitem> + </varlistentry> + <varlistentry> + <term><errorcode>EBUSY</errorcode></term> + <listitem> + <para>The driver does not support multiple read streams and the +device is already in use.</para> + </listitem> + </varlistentry> + <varlistentry> + <term><errorcode>EFAULT</errorcode></term> + <listitem> + <para><parameter>buf</parameter> references an inaccessible +memory area.</para> + </listitem> + </varlistentry> + <varlistentry> + <term><errorcode>EINTR</errorcode></term> + <listitem> + <para>The call was interrupted by a signal before any +data was read.</para> + </listitem> + </varlistentry> + <varlistentry> + <term><errorcode>EIO</errorcode></term> + <listitem> + <para>I/O error. This indicates some hardware problem or a +failure to communicate with a remote device (USB camera etc.).</para> + </listitem> + </varlistentry> + <varlistentry> + <term><errorcode>EINVAL</errorcode></term> + <listitem> + <para>The <function>read()</function> function is not +supported by this driver, not on this device, or generally not on this +type of device.</para> + </listitem> + </varlistentry> + </variablelist> + </refsect1> +</refentry> + +<!-- +Local Variables: +mode: sgml +sgml-parent-document: "v4l2.sgml" +indent-tabs-mode: nil +End: +--> diff --git a/Documentation/DocBook/v4l/func-select.xml b/Documentation/DocBook/v4l/func-select.xml new file mode 100644 index 000000000000..b6713623181f --- /dev/null +++ b/Documentation/DocBook/v4l/func-select.xml @@ -0,0 +1,138 @@ +<refentry id="func-select"> + <refmeta> + <refentrytitle>V4L2 select()</refentrytitle> + &manvol; + </refmeta> + + <refnamediv> + <refname>v4l2-select</refname> + <refpurpose>Synchronous I/O multiplexing</refpurpose> + </refnamediv> + + <refsynopsisdiv> + <funcsynopsis> + <funcsynopsisinfo> +#include <sys/time.h> +#include <sys/types.h> +#include <unistd.h></funcsynopsisinfo> + <funcprototype> + <funcdef>int <function>select</function></funcdef> + <paramdef>int <parameter>nfds</parameter></paramdef> + <paramdef>fd_set *<parameter>readfds</parameter></paramdef> + <paramdef>fd_set *<parameter>writefds</parameter></paramdef> + <paramdef>fd_set *<parameter>exceptfds</parameter></paramdef> + <paramdef>struct timeval *<parameter>timeout</parameter></paramdef> + </funcprototype> + </funcsynopsis> + </refsynopsisdiv> + + <refsect1> + <title>Description</title> + + <para>With the <function>select()</function> function applications +can suspend execution until the driver has captured data or is ready +to accept data for output.</para> + + <para>When streaming I/O has been negotiated this function waits +until a buffer has been filled or displayed and can be dequeued with +the &VIDIOC-DQBUF; ioctl. When buffers are already in the outgoing +queue of the driver the function returns immediately.</para> + + <para>On success <function>select()</function> returns the total +number of bits set in the <structname>fd_set</structname>s. When the +function timed out it returns a value of zero. On failure it returns +<returnvalue>-1</returnvalue> and the <varname>errno</varname> +variable is set appropriately. When the application did not call +&VIDIOC-QBUF; or &VIDIOC-STREAMON; yet the +<function>select()</function> function succeeds, setting the bit of +the file descriptor in <parameter>readfds</parameter> or +<parameter>writefds</parameter>, but subsequent &VIDIOC-DQBUF; calls +will fail.<footnote><para>The Linux kernel implements +<function>select()</function> like the &func-poll; function, but +<function>select()</function> cannot return a +<constant>POLLERR</constant>.</para> + </footnote></para> + + <para>When use of the <function>read()</function> function has +been negotiated and the driver does not capture yet, the +<function>select()</function> function starts capturing. When that +fails, <function>select()</function> returns successful and a +subsequent <function>read()</function> call, which also attempts to +start capturing, will return an appropriate error code. When the +driver captures continuously (as opposed to, for example, still +images) and data is already available the +<function>select()</function> function returns immediately.</para> + + <para>When use of the <function>write()</function> function has +been negotiated the <function>select()</function> function just waits +until the driver is ready for a non-blocking +<function>write()</function> call.</para> + + <para>All drivers implementing the <function>read()</function> or +<function>write()</function> function or streaming I/O must also +support the <function>select()</function> function.</para> + + <para>For more details see the <function>select()</function> +manual page.</para> + + </refsect1> + + <refsect1> + <title>Return Value</title> + + <para>On success, <function>select()</function> returns the number +of descriptors contained in the three returned descriptor sets, which +will be zero if the timeout expired. On error +<returnvalue>-1</returnvalue> is returned, and the +<varname>errno</varname> variable is set appropriately; the sets and +<parameter>timeout</parameter> are undefined. Possible error codes +are:</para> + + <variablelist> + <varlistentry> + <term><errorcode>EBADF</errorcode></term> + <listitem> + <para>One or more of the file descriptor sets specified a +file descriptor that is not open.</para> + </listitem> + </varlistentry> + <varlistentry> + <term><errorcode>EBUSY</errorcode></term> + <listitem> + <para>The driver does not support multiple read or write +streams and the device is already in use.</para> + </listitem> + </varlistentry> + <varlistentry> + <term><errorcode>EFAULT</errorcode></term> + <listitem> + <para>The <parameter>readfds</parameter>, +<parameter>writefds</parameter>, <parameter>exceptfds</parameter> or +<parameter>timeout</parameter> pointer references an inaccessible memory +area.</para> + </listitem> + </varlistentry> + <varlistentry> + <term><errorcode>EINTR</errorcode></term> + <listitem> + <para>The call was interrupted by a signal.</para> + </listitem> + </varlistentry> + <varlistentry> + <term><errorcode>EINVAL</errorcode></term> + <listitem> + <para>The <parameter>nfds</parameter> argument is less than +zero or greater than <constant>FD_SETSIZE</constant>.</para> + </listitem> + </varlistentry> + </variablelist> + </refsect1> +</refentry> + +<!-- +Local Variables: +mode: sgml +sgml-parent-document: "v4l2.sgml" +indent-tabs-mode: nil +End: +--> diff --git a/Documentation/DocBook/v4l/func-write.xml b/Documentation/DocBook/v4l/func-write.xml new file mode 100644 index 000000000000..2c09c09371c3 --- /dev/null +++ b/Documentation/DocBook/v4l/func-write.xml @@ -0,0 +1,136 @@ +<refentry id="func-write"> + <refmeta> + <refentrytitle>V4L2 write()</refentrytitle> + &manvol; + </refmeta> + + <refnamediv> + <refname>v4l2-write</refname> + <refpurpose>Write to a V4L2 device</refpurpose> + </refnamediv> + + <refsynopsisdiv> + <funcsynopsis> + <funcsynopsisinfo>#include <unistd.h></funcsynopsisinfo> + <funcprototype> + <funcdef>ssize_t <function>write</function></funcdef> + <paramdef>int <parameter>fd</parameter></paramdef> + <paramdef>void *<parameter>buf</parameter></paramdef> + <paramdef>size_t <parameter>count</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>buf</parameter></term> + <listitem> + <para></para> + </listitem> + </varlistentry> + <varlistentry> + <term><parameter>count</parameter></term> + <listitem> + <para></para> + </listitem> + </varlistentry> + </variablelist> + </refsect1> + + <refsect1> + <title>Description</title> + + <para><function>write()</function> writes up to +<parameter>count</parameter> bytes to the device referenced by the +file descriptor <parameter>fd</parameter> from the buffer starting at +<parameter>buf</parameter>. When the hardware outputs are not active +yet, this function enables them. When <parameter>count</parameter> is +zero, <function>write()</function> returns +<returnvalue>0</returnvalue> without any other effect.</para> + + <para>When the application does not provide more data in time, the +previous video frame, raw VBI image, sliced VPS or WSS data is +displayed again. Sliced Teletext or Closed Caption data is not +repeated, the driver inserts a blank line instead.</para> + </refsect1> + + <refsect1> + <title>Return Value</title> + + <para>On success, the number of bytes written are returned. Zero +indicates nothing was written. On error, <returnvalue>-1</returnvalue> +is returned, and the <varname>errno</varname> variable is set +appropriately. In this case the next write will start at the beginning +of a new frame. Possible error codes are:</para> + + <variablelist> + <varlistentry> + <term><errorcode>EAGAIN</errorcode></term> + <listitem> + <para>Non-blocking I/O has been selected using the <link +linkend="func-open"><constant>O_NONBLOCK</constant></link> flag and no +buffer space was available to write the data immediately.</para> + </listitem> + </varlistentry> + <varlistentry> + <term><errorcode>EBADF</errorcode></term> + <listitem> + <para><parameter>fd</parameter> is not a valid file +descriptor or is not open for writing.</para> + </listitem> + </varlistentry> + <varlistentry> + <term><errorcode>EBUSY</errorcode></term> + <listitem> + <para>The driver does not support multiple write streams and the +device is already in use.</para> + </listitem> + </varlistentry> + <varlistentry> + <term><errorcode>EFAULT</errorcode></term> + <listitem> + <para><parameter>buf</parameter> references an inaccessible +memory area.</para> + </listitem> + </varlistentry> + <varlistentry> + <term><errorcode>EINTR</errorcode></term> + <listitem> + <para>The call was interrupted by a signal before any +data was written.</para> + </listitem> + </varlistentry> + <varlistentry> + <term><errorcode>EIO</errorcode></term> + <listitem> + <para>I/O error. This indicates some hardware problem.</para> + </listitem> + </varlistentry> + <varlistentry> + <term><errorcode>EINVAL</errorcode></term> + <listitem> + <para>The <function>write()</function> function is not +supported by this driver, not on this device, or generally not on this +type of device.</para> + </listitem> + </varlistentry> + </variablelist> + </refsect1> +</refentry> + +<!-- +Local Variables: +mode: sgml +sgml-parent-document: "v4l2.sgml" +indent-tabs-mode: nil +End: +--> diff --git a/Documentation/DocBook/v4l/io.xml b/Documentation/DocBook/v4l/io.xml new file mode 100644 index 000000000000..f92f24323b2a --- /dev/null +++ b/Documentation/DocBook/v4l/io.xml @@ -0,0 +1,1073 @@ + <title>Input/Output</title> + + <para>The V4L2 API defines several different methods to read from or +write to a device. All drivers exchanging data with applications must +support at least one of them.</para> + + <para>The classic I/O method using the <function>read()</function> +and <function>write()</function> function is automatically selected +after opening a V4L2 device. When the driver does not support this +method attempts to read or write will fail at any time.</para> + + <para>Other methods must be negotiated. To select the streaming I/O +method with memory mapped or user buffers applications call the +&VIDIOC-REQBUFS; ioctl. The asynchronous I/O method is not defined +yet.</para> + + <para>Video overlay can be considered another I/O method, although +the application does not directly receive the image data. It is +selected by initiating video overlay with the &VIDIOC-S-FMT; ioctl. +For more information see <xref linkend="overlay" />.</para> + + <para>Generally exactly one I/O method, including overlay, is +associated with each file descriptor. The only exceptions are +applications not exchanging data with a driver ("panel applications", +see <xref linkend="open" />) and drivers permitting simultaneous video capturing +and overlay using the same file descriptor, for compatibility with V4L +and earlier versions of V4L2.</para> + + <para><constant>VIDIOC_S_FMT</constant> and +<constant>VIDIOC_REQBUFS</constant> would permit this to some degree, +but for simplicity drivers need not support switching the I/O method +(after first switching away from read/write) other than by closing +and reopening the device.</para> + + <para>The following sections describe the various I/O methods in +more detail.</para> + + <section id="rw"> + <title>Read/Write</title> + + <para>Input and output devices support the +<function>read()</function> and <function>write()</function> function, +respectively, when the <constant>V4L2_CAP_READWRITE</constant> flag in +the <structfield>capabilities</structfield> field of &v4l2-capability; +returned by the &VIDIOC-QUERYCAP; ioctl is set.</para> + + <para>Drivers may need the CPU to copy the data, but they may also +support DMA to or from user memory, so this I/O method is not +necessarily less efficient than other methods merely exchanging buffer +pointers. It is considered inferior though because no meta-information +like frame counters or timestamps are passed. This information is +necessary to recognize frame dropping and to synchronize with other +data streams. However this is also the simplest I/O method, requiring +little or no setup to exchange data. It permits command line stunts +like this (the <application>vidctrl</application> tool is +fictitious):</para> + + <informalexample> + <screen> +> vidctrl /dev/video --input=0 --format=YUYV --size=352x288 +> dd if=/dev/video of=myimage.422 bs=202752 count=1 +</screen> + </informalexample> + + <para>To read from the device applications use the +&func-read; function, to write the &func-write; function. +Drivers must implement one I/O method if they +exchange data with applications, but it need not be this.<footnote> + <para>It would be desirable if applications could depend on +drivers supporting all I/O interfaces, but as much as the complex +memory mapping I/O can be inadequate for some devices we have no +reason to require this interface, which is most useful for simple +applications capturing still images.</para> + </footnote> When reading or writing is supported, the driver +must also support the &func-select; and &func-poll; +function.<footnote> + <para>At the driver level <function>select()</function> and +<function>poll()</function> are the same, and +<function>select()</function> is too important to be optional.</para> + </footnote></para> + </section> + + <section id="mmap"> + <title>Streaming I/O (Memory Mapping)</title> + + <para>Input and output devices support this I/O method when the +<constant>V4L2_CAP_STREAMING</constant> flag in the +<structfield>capabilities</structfield> field of &v4l2-capability; +returned by the &VIDIOC-QUERYCAP; ioctl is set. There are two +streaming methods, to determine if the memory mapping flavor is +supported applications must call the &VIDIOC-REQBUFS; ioctl.</para> + + <para>Streaming is an I/O method where only pointers to buffers +are exchanged between application and driver, the data itself is not +copied. Memory mapping is primarily intended to map buffers in device +memory into the application's address space. Device memory can be for +example the video memory on a graphics card with a video capture +add-on. However, being the most efficient I/O method available for a +long time, many other drivers support streaming as well, allocating +buffers in DMA-able main memory.</para> + + <para>A driver can support many sets of buffers. Each set is +identified by a unique buffer type value. The sets are independent and +each set can hold a different type of data. To access different sets +at the same time different file descriptors must be used.<footnote> + <para>One could use one file descriptor and set the buffer +type field accordingly when calling &VIDIOC-QBUF; etc., but it makes +the <function>select()</function> function ambiguous. We also like the +clean approach of one file descriptor per logical stream. Video +overlay for example is also a logical stream, although the CPU is not +needed for continuous operation.</para> + </footnote></para> + + <para>To allocate device buffers applications call the +&VIDIOC-REQBUFS; ioctl with the desired number of buffers and buffer +type, for example <constant>V4L2_BUF_TYPE_VIDEO_CAPTURE</constant>. +This ioctl can also be used to change the number of buffers or to free +the allocated memory, provided none of the buffers are still +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> + + <example> + <title>Mapping buffers</title> + + <programlisting> +&v4l2-requestbuffers; reqbuf; +struct { + void *start; + size_t length; +} *buffers; +unsigned int i; + +memset (&reqbuf, 0, sizeof (reqbuf)); +reqbuf.type = V4L2_BUF_TYPE_VIDEO_CAPTURE; +reqbuf.memory = V4L2_MEMORY_MMAP; +reqbuf.count = 20; + +if (-1 == ioctl (fd, &VIDIOC-REQBUFS;, &reqbuf)) { + if (errno == EINVAL) + printf ("Video capturing or mmap-streaming is not supported\n"); + else + perror ("VIDIOC_REQBUFS"); + + exit (EXIT_FAILURE); +} + +/* We want at least five buffers. */ + +if (reqbuf.count < 5) { + /* You may need to free the buffers here. */ + printf ("Not enough buffer memory\n"); + exit (EXIT_FAILURE); +} + +buffers = calloc (reqbuf.count, sizeof (*buffers)); +assert (buffers != NULL); + +for (i = 0; i < reqbuf.count; i++) { + &v4l2-buffer; buffer; + + memset (&buffer, 0, sizeof (buffer)); + buffer.type = reqbuf.type; + buffer.memory = V4L2_MEMORY_MMAP; + buffer.index = i; + + if (-1 == ioctl (fd, &VIDIOC-QUERYBUF;, &buffer)) { + perror ("VIDIOC_QUERYBUF"); + exit (EXIT_FAILURE); + } + + 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); + + 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); + } +} + +/* Cleanup. */ + +for (i = 0; i < reqbuf.count; i++) + munmap (buffers[i].start, buffers[i].length); + </programlisting> + </example> + + <para>Conceptually streaming drivers maintain two buffer queues, an incoming +and an outgoing queue. They separate the synchronous capture or output +operation locked to a video clock from the application which is +subject to random disk or network delays and preemption by +other processes, thereby reducing the probability of data loss. +The queues are organized as FIFOs, buffers will be +output in the order enqueued in the incoming FIFO, and were +captured in the order dequeued from the outgoing FIFO.</para> + + <para>The driver may require a minimum number of buffers enqueued +at all times to function, apart of this no limit exists on the number +of buffers applications can enqueue in advance, or dequeue and +process. They can also enqueue in a different order than buffers have +been dequeued, and the driver can <emphasis>fill</emphasis> enqueued +<emphasis>empty</emphasis> buffers in any order. <footnote> + <para>Random enqueue order permits applications processing +images out of order (such as video codecs) to return buffers earlier, +reducing the probability of data loss. Random fill order allows +drivers to reuse buffers on a LIFO-basis, taking advantage of caches +holding scatter-gather lists and the like.</para> + </footnote> The index number of a buffer (&v4l2-buffer; +<structfield>index</structfield>) plays no role here, it only +identifies the buffer.</para> + + <para>Initially all mapped buffers are in dequeued state, +inaccessible by the driver. For capturing applications it is customary +to first enqueue all mapped buffers, then to start capturing and enter +the read loop. Here the application waits until a filled buffer can be +dequeued, and re-enqueues the buffer when the data is no longer +needed. Output applications fill and enqueue buffers, when enough +buffers are stacked up the output is started with +<constant>VIDIOC_STREAMON</constant>. In the write loop, when +the application runs out of free buffers, it must wait until an empty +buffer can be dequeued and reused.</para> + + <para>To enqueue and dequeue a buffer applications use the +&VIDIOC-QBUF; and &VIDIOC-DQBUF; ioctl. The status of a buffer being +mapped, enqueued, full or empty can be determined at any time using the +&VIDIOC-QUERYBUF; ioctl. Two methods exist to suspend execution of the +application until one or more buffers can be dequeued. By default +<constant>VIDIOC_DQBUF</constant> blocks when no buffer is in the +outgoing queue. When the <constant>O_NONBLOCK</constant> flag was +given to the &func-open; function, <constant>VIDIOC_DQBUF</constant> +returns immediately with an &EAGAIN; when no buffer is available. The +&func-select; or &func-poll; function are always available.</para> + + <para>To start and stop capturing or output applications call the +&VIDIOC-STREAMON; and &VIDIOC-STREAMOFF; ioctl. Note +<constant>VIDIOC_STREAMOFF</constant> removes all buffers from both +queues as a side effect. Since there is no notion of doing anything +"now" on a multitasking system, if an application needs to synchronize +with another event it should examine the &v4l2-buffer; +<structfield>timestamp</structfield> of captured buffers, or set the +field before enqueuing buffers for output.</para> + + <para>Drivers implementing memory mapping I/O must +support the <constant>VIDIOC_REQBUFS</constant>, +<constant>VIDIOC_QUERYBUF</constant>, +<constant>VIDIOC_QBUF</constant>, <constant>VIDIOC_DQBUF</constant>, +<constant>VIDIOC_STREAMON</constant> and +<constant>VIDIOC_STREAMOFF</constant> ioctl, the +<function>mmap()</function>, <function>munmap()</function>, +<function>select()</function> and <function>poll()</function> +function.<footnote> + <para>At the driver level <function>select()</function> and +<function>poll()</function> are the same, and +<function>select()</function> is too important to be optional. The +rest should be evident.</para> + </footnote></para> + + <para>[capture example]</para> + + </section> + + <section id="userp"> + <title>Streaming I/O (User Pointers)</title> + + <para>Input and output devices support this I/O method when the +<constant>V4L2_CAP_STREAMING</constant> flag in the +<structfield>capabilities</structfield> field of &v4l2-capability; +returned by the &VIDIOC-QUERYCAP; ioctl is set. If the particular user +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 +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 +buffers with the <constant>VIDIOC_QUERYBUF</constant> ioctl.</para> + + <example> + <title>Initiating streaming I/O with user pointers</title> + + <programlisting> +&v4l2-requestbuffers; reqbuf; + +memset (&reqbuf, 0, sizeof (reqbuf)); +reqbuf.type = V4L2_BUF_TYPE_VIDEO_CAPTURE; +reqbuf.memory = V4L2_MEMORY_USERPTR; + +if (ioctl (fd, &VIDIOC-REQBUFS;, &reqbuf) == -1) { + if (errno == EINVAL) + printf ("Video capturing or user pointer streaming is not supported\n"); + else + perror ("VIDIOC_REQBUFS"); + + exit (EXIT_FAILURE); +} + </programlisting> + </example> + + <para>Buffer 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 +driver swaps memory pages within physical memory to create a +continuous area of memory. This happens transparently to the +application in the virtual memory subsystem of the kernel. When buffer +pages have been swapped out to disk they are brought back and finally +locked in physical memory for DMA.<footnote> + <para>We expect that frequently used buffers are typically not +swapped out. Anyway, the process of swapping, locking or generating +scatter-gather lists may be time consuming. The delay can be masked by +the depth of the incoming buffer queue, and perhaps by maintaining +caches assuming a buffer will be soon enqueued again. On the other +hand, to optimize memory usage drivers can limit the number of buffers +locked in advance and recycle the most recently used buffers first. Of +course, the pages of empty buffers in the incoming queue need not be +saved to disk. Output buffers must be saved on the incoming and +outgoing queue because an application may share them with other +processes.</para> + </footnote></para> + + <para>Filled or displayed buffers are dequeued with the +&VIDIOC-DQBUF; ioctl. The driver can unlock the memory pages at any +time between the completion of the DMA and this ioctl. The memory is +also unlocked when &VIDIOC-STREAMOFF; is called, &VIDIOC-REQBUFS;, or +when the device is closed. Applications must take care not to free +buffers without dequeuing. For once, the buffers remain locked until +further, wasting physical memory. Second the driver will not be +notified when the memory is returned to the application's free list +and subsequently reused for other purposes, possibly completing the +requested DMA and overwriting valuable data.</para> + + <para>For capturing applications it is customary to enqueue a +number of empty buffers, to start capturing and enter the read loop. +Here the application waits until a filled buffer can be dequeued, and +re-enqueues the buffer when the data is no longer needed. Output +applications fill and enqueue buffers, when enough buffers are stacked +up output is started. In the write loop, when the application +runs out of free buffers it must wait until an empty buffer can be +dequeued and reused. Two methods exist to suspend execution of the +application until one or more buffers can be dequeued. By default +<constant>VIDIOC_DQBUF</constant> blocks when no buffer is in the +outgoing queue. When the <constant>O_NONBLOCK</constant> flag was +given to the &func-open; function, <constant>VIDIOC_DQBUF</constant> +returns immediately with an &EAGAIN; when no buffer is available. The +&func-select; or &func-poll; function are always available.</para> + + <para>To start and stop capturing or output applications call the +&VIDIOC-STREAMON; and &VIDIOC-STREAMOFF; ioctl. Note +<constant>VIDIOC_STREAMOFF</constant> removes all buffers from both +queues and unlocks all buffers as a side effect. Since there is no +notion of doing anything "now" on a multitasking system, if an +application needs to synchronize with another event it should examine +the &v4l2-buffer; <structfield>timestamp</structfield> of captured +buffers, or set the field before enqueuing buffers for output.</para> + + <para>Drivers implementing user pointer I/O must +support the <constant>VIDIOC_REQBUFS</constant>, +<constant>VIDIOC_QBUF</constant>, <constant>VIDIOC_DQBUF</constant>, +<constant>VIDIOC_STREAMON</constant> and +<constant>VIDIOC_STREAMOFF</constant> ioctl, the +<function>select()</function> and <function>poll()</function> function.<footnote> + <para>At the driver level <function>select()</function> and +<function>poll()</function> are the same, and +<function>select()</function> is too important to be optional. The +rest should be evident.</para> + </footnote></para> + </section> + + <section id="async"> + <title>Asynchronous I/O</title> + + <para>This method is not defined yet.</para> + </section> + + <section id="buffer"> + <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> + + <para>Nominally timestamps refer to the first data byte transmitted. +In practice however the wide range of hardware covered by the V4L2 API +limits timestamp accuracy. Often an interrupt routine will +sample the system clock shortly after the field or frame was stored +completely in memory. So applications must expect a constant +difference up to one field or frame period plus a small (few scan +lines) random error. The delay and error can be much +larger due to compression or transmission over an external bus when +the frames are not properly stamped by the sender. This is frequently +the case with USB cameras. Here timestamps refer to the instant the +field or frame was received by the driver, not the capture time. These +devices identify by not enumerating any video standards, see <xref +linkend="standard" />.</para> + + <para>Similar limitations apply to output timestamps. Typically +the video hardware locks to a clock controlling the video timing, the +horizontal and vertical synchronization pulses. At some point in the +line sequence, possibly the vertical blanking, an interrupt routine +samples the system clock, compares against the timestamp and programs +the hardware to repeat the previous field or frame, or to display the +buffer contents.</para> + + <para>Apart of limitations of the video device and natural +inaccuracies of all clocks, it should be noted system time itself is +not perfectly stable. It can be affected by power saving cycles, +warped to insert leap seconds, or even turned back or forth by the +system administrator affecting long term measurements. <footnote> + <para>Since no other Linux multimedia +API supports unadjusted time it would be foolish to introduce here. We +must use a universally supported clock to synchronize different media, +hence time of day.</para> + </footnote></para> + + <table frame="none" pgwide="1" id="v4l2-buffer"> + <title>struct <structname>v4l2_buffer</structname></title> + <tgroup cols="4"> + &cs-ustr; + <tbody valign="top"> + <row> + <entry>__u32</entry> + <entry><structfield>index</structfield></entry> + <entry></entry> + <entry>Number of the buffer, set by the application. This +field is only used for <link linkend="mmap">memory mapping</link> I/O +and can range from zero to the number of buffers allocated +with the &VIDIOC-REQBUFS; ioctl (&v4l2-requestbuffers; <structfield>count</structfield>) minus one.</entry> + </row> + <row> + <entry>&v4l2-buf-type;</entry> + <entry><structfield>type</structfield></entry> + <entry></entry> + <entry>Type of the buffer, same as &v4l2-format; +<structfield>type</structfield> or &v4l2-requestbuffers; +<structfield>type</structfield>, set by the application.</entry> + </row> + <row> + <entry>__u32</entry> + <entry><structfield>bytesused</structfield></entry> + <entry></entry> + <entry>The number of bytes occupied by the data in the +buffer. It depends on the negotiated data format and may change with +each buffer for compressed variable size data like JPEG images. +Drivers must set this field when <structfield>type</structfield> +refers to an input stream, applications when an output stream.</entry> + </row> + <row> + <entry>__u32</entry> + <entry><structfield>flags</structfield></entry> + <entry></entry> + <entry>Flags set by the application or driver, see <xref +linkend="buffer-flags" />.</entry> + </row> + <row> + <entry>&v4l2-field;</entry> + <entry><structfield>field</structfield></entry> + <entry></entry> + <entry>Indicates the field order of the image in the +buffer, see <xref linkend="v4l2-field" />. This field is not used when +the buffer contains VBI data. Drivers must set it when +<structfield>type</structfield> refers to an input stream, +applications when an output stream.</entry> + </row> + <row> + <entry>struct timeval</entry> + <entry><structfield>timestamp</structfield></entry> + <entry></entry> + <entry><para>For input streams this is the +system time (as returned by the <function>gettimeofday()</function> +function) when the first data byte was captured. For output streams +the data will not be displayed before this time, secondary to the +nominal frame rate determined by the current video standard in +enqueued order. Applications can for example zero this field to +display frames as soon as possible. The driver stores the time at +which the first data byte was actually sent out in the +<structfield>timestamp</structfield> field. This permits +applications to monitor the drift between the video and system +clock.</para></entry> + </row> + <row> + <entry>&v4l2-timecode;</entry> + <entry><structfield>timecode</structfield></entry> + <entry></entry> + <entry>When <structfield>type</structfield> is +<constant>V4L2_BUF_TYPE_VIDEO_CAPTURE</constant> and the +<constant>V4L2_BUF_FLAG_TIMECODE</constant> flag is set in +<structfield>flags</structfield>, this structure contains a frame +timecode. In <link linkend="v4l2-field">V4L2_FIELD_ALTERNATE</link> +mode the top and bottom field contain the same timecode. +Timecodes are intended to help video editing and are typically recorded on +video tapes, but also embedded in compressed formats like MPEG. This +field is independent of the <structfield>timestamp</structfield> and +<structfield>sequence</structfield> fields.</entry> + </row> + <row> + <entry>__u32</entry> + <entry><structfield>sequence</structfield></entry> + <entry></entry> + <entry>Set by the driver, counting the frames in the +sequence.</entry> + </row> + <row> + <entry spanname="hspan"><para>In <link +linkend="v4l2-field">V4L2_FIELD_ALTERNATE</link> mode the top and +bottom field have the same sequence number. The count starts at zero +and includes dropped or repeated frames. A dropped frame was received +by an input device but could not be stored due to lack of free buffer +space. A repeated frame was displayed again by an output device +because the application did not pass new data in +time.</para><para>Note this may count the frames received +e.g. over USB, without taking into account the frames dropped by the +remote hardware due to limited compression throughput or bus +bandwidth. These devices identify by not enumerating any video +standards, see <xref linkend="standard" />.</para></entry> + </row> + <row> + <entry>&v4l2-memory;</entry> + <entry><structfield>memory</structfield></entry> + <entry></entry> + <entry>This field must be set by applications and/or drivers +in accordance with the selected I/O method.</entry> + </row> + <row> + <entry>union</entry> + <entry><structfield>m</structfield></entry> + </row> + <row> + <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> + </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> + </row> + <row> + <entry>__u32</entry> + <entry><structfield>length</structfield></entry> + <entry></entry> + <entry>Size of the buffer (not the payload) in bytes.</entry> + </row> + <row> + <entry>__u32</entry> + <entry><structfield>input</structfield></entry> + <entry></entry> + <entry>Some video capture drivers support rapid and +synchronous video input changes, a function useful for example in +video surveillance applications. For this purpose applications set the +<constant>V4L2_BUF_FLAG_INPUT</constant> flag, and this field to the +number of a video input as in &v4l2-input; field +<structfield>index</structfield>.</entry> + </row> + <row> + <entry>__u32</entry> + <entry><structfield>reserved</structfield></entry> + <entry></entry> + <entry>A place holder for future extensions and custom +(driver defined) buffer types +<constant>V4L2_BUF_TYPE_PRIVATE</constant> and higher.</entry> + </row> + </tbody> + </tgroup> + </table> + + <table frame="none" pgwide="1" id="v4l2-buf-type"> + <title>enum v4l2_buf_type</title> + <tgroup cols="3"> + &cs-def; + <tbody valign="top"> + <row> + <entry><constant>V4L2_BUF_TYPE_VIDEO_CAPTURE</constant></entry> + <entry>1</entry> + <entry>Buffer of a 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 + linkend="output" />.</entry> + </row> + <row> + <entry><constant>V4L2_BUF_TYPE_VIDEO_OVERLAY</constant></entry> + <entry>3</entry> + <entry>Buffer for video overlay, see <xref linkend="overlay" />.</entry> + </row> + <row> + <entry><constant>V4L2_BUF_TYPE_VBI_CAPTURE</constant></entry> + <entry>4</entry> + <entry>Buffer of a raw VBI capture stream, see <xref + linkend="raw-vbi" />.</entry> + </row> + <row> + <entry><constant>V4L2_BUF_TYPE_VBI_OUTPUT</constant></entry> + <entry>5</entry> + <entry>Buffer of a raw VBI output stream, see <xref + linkend="raw-vbi" />.</entry> + </row> + <row> + <entry><constant>V4L2_BUF_TYPE_SLICED_VBI_CAPTURE</constant></entry> + <entry>6</entry> + <entry>Buffer of a sliced VBI capture stream, see <xref + linkend="sliced" />.</entry> + </row> + <row> + <entry><constant>V4L2_BUF_TYPE_SLICED_VBI_OUTPUT</constant></entry> + <entry>7</entry> + <entry>Buffer of a sliced VBI output stream, see <xref + linkend="sliced" />.</entry> + </row> + <row> + <entry><constant>V4L2_BUF_TYPE_VIDEO_OUTPUT_OVERLAY</constant></entry> + <entry>8</entry> + <entry>Buffer for video output overlay (OSD), see <xref + linkend="osd" />. Status: <link +linkend="experimental">Experimental</link>.</entry> + </row> + <row> + <entry><constant>V4L2_BUF_TYPE_PRIVATE</constant></entry> + <entry>0x80</entry> + <entry>This and higher values are reserved for custom +(driver defined) buffer types.</entry> + </row> + </tbody> + </tgroup> + </table> + + <table frame="none" pgwide="1" id="buffer-flags"> + <title>Buffer Flags</title> + <tgroup cols="3"> + &cs-def; + <tbody valign="top"> + <row> + <entry><constant>V4L2_BUF_FLAG_MAPPED</constant></entry> + <entry>0x0001</entry> + <entry>The buffer resides in device memory and has been mapped +into the application's address space, see <xref linkend="mmap" /> for details. +Drivers set or clear this flag when the +<link linkend="vidioc-querybuf">VIDIOC_QUERYBUF</link>, <link + linkend="vidioc-qbuf">VIDIOC_QBUF</link> or <link + linkend="vidioc-qbuf">VIDIOC_DQBUF</link> ioctl is called. Set by the driver.</entry> + </row> + <row> + <entry><constant>V4L2_BUF_FLAG_QUEUED</constant></entry> + <entry>0x0002</entry> + <entry>Internally drivers maintain two buffer queues, an +incoming and outgoing queue. When this flag is set, the buffer is +currently on the incoming queue. It automatically moves to the +outgoing queue after the buffer has been filled (capture devices) or +displayed (output devices). Drivers set or clear this flag when the +<constant>VIDIOC_QUERYBUF</constant> ioctl is called. After +(successful) calling the <constant>VIDIOC_QBUF </constant>ioctl it is +always set and after <constant>VIDIOC_DQBUF</constant> always +cleared.</entry> + </row> + <row> + <entry><constant>V4L2_BUF_FLAG_DONE</constant></entry> + <entry>0x0004</entry> + <entry>When this flag is set, the buffer is currently on +the outgoing queue, ready to be dequeued from the driver. Drivers set +or clear this flag when the <constant>VIDIOC_QUERYBUF</constant> ioctl +is called. After calling the <constant>VIDIOC_QBUF</constant> or +<constant>VIDIOC_DQBUF</constant> it is always cleared. Of course a +buffer cannot be on both queues at the same time, the +<constant>V4L2_BUF_FLAG_QUEUED</constant> and +<constant>V4L2_BUF_FLAG_DONE</constant> flag are mutually exclusive. +They can be both cleared however, then the buffer is in "dequeued" +state, in the application domain to say so.</entry> + </row> + <row> + <entry><constant>V4L2_BUF_FLAG_KEYFRAME</constant></entry> + <entry>0x0008</entry> + <entry>Drivers set or clear this flag when calling the +<constant>VIDIOC_DQBUF</constant> ioctl. It may be set by video +capture devices when the buffer contains a compressed image which is a +key frame (or field), &ie; can be decompressed on its own.</entry> + </row> + <row> + <entry><constant>V4L2_BUF_FLAG_PFRAME</constant></entry> + <entry>0x0010</entry> + <entry>Similar to <constant>V4L2_BUF_FLAG_KEYFRAME</constant> +this flags predicted frames or fields which contain only differences to a +previous key frame.</entry> + </row> + <row> + <entry><constant>V4L2_BUF_FLAG_BFRAME</constant></entry> + <entry>0x0020</entry> + <entry>Similar to <constant>V4L2_BUF_FLAG_PFRAME</constant> + this is a bidirectional predicted frame or field. [ooc tbd]</entry> + </row> + <row> + <entry><constant>V4L2_BUF_FLAG_TIMECODE</constant></entry> + <entry>0x0100</entry> + <entry>The <structfield>timecode</structfield> field is valid. +Drivers set or clear this flag when the <constant>VIDIOC_DQBUF</constant> +ioctl is called.</entry> + </row> + <row> + <entry><constant>V4L2_BUF_FLAG_INPUT</constant></entry> + <entry>0x0200</entry> + <entry>The <structfield>input</structfield> field is valid. +Applications set or clear this flag before calling the +<constant>VIDIOC_QBUF</constant> ioctl.</entry> + </row> + </tbody> + </tgroup> + </table> + + <table pgwide="1" frame="none" id="v4l2-memory"> + <title>enum v4l2_memory</title> + <tgroup cols="3"> + &cs-def; + <tbody valign="top"> + <row> + <entry><constant>V4L2_MEMORY_MMAP</constant></entry> + <entry>1</entry> + <entry>The buffer is used for <link linkend="mmap">memory +mapping</link> I/O.</entry> + </row> + <row> + <entry><constant>V4L2_MEMORY_USERPTR</constant></entry> + <entry>2</entry> + <entry>The buffer is used for <link linkend="userp">user +pointer</link> I/O.</entry> + </row> + <row> + <entry><constant>V4L2_MEMORY_OVERLAY</constant></entry> + <entry>3</entry> + <entry>[to do]</entry> + </row> + </tbody> + </tgroup> + </table> + + <section> + <title>Timecodes</title> + + <para>The <structname>v4l2_timecode</structname> structure is +designed to hold a <xref linkend="smpte12m" /> or similar timecode. +(struct <structname>timeval</structname> timestamps are stored in +&v4l2-buffer; field <structfield>timestamp</structfield>.)</para> + + <table frame="none" pgwide="1" id="v4l2-timecode"> + <title>struct <structname>v4l2_timecode</structname></title> + <tgroup cols="3"> + &cs-str; + <tbody valign="top"> + <row> + <entry>__u32</entry> + <entry><structfield>type</structfield></entry> + <entry>Frame rate the timecodes are based on, see <xref + linkend="timecode-type" />.</entry> + </row> + <row> + <entry>__u32</entry> + <entry><structfield>flags</structfield></entry> + <entry>Timecode flags, see <xref linkend="timecode-flags" />.</entry> + </row> + <row> + <entry>__u8</entry> + <entry><structfield>frames</structfield></entry> + <entry>Frame count, 0 ... 23/24/29/49/59, depending on the + type of timecode.</entry> + </row> + <row> + <entry>__u8</entry> + <entry><structfield>seconds</structfield></entry> + <entry>Seconds count, 0 ... 59. This is a binary, not BCD number.</entry> + </row> + <row> + <entry>__u8</entry> + <entry><structfield>minutes</structfield></entry> + <entry>Minutes count, 0 ... 59. This is a binary, not BCD number.</entry> + </row> + <row> + <entry>__u8</entry> + <entry><structfield>hours</structfield></entry> + <entry>Hours count, 0 ... 29. This is a binary, not BCD number.</entry> + </row> + <row> + <entry>__u8</entry> + <entry><structfield>userbits</structfield>[4]</entry> + <entry>The "user group" bits from the timecode.</entry> + </row> + </tbody> + </tgroup> + </table> + + <table frame="none" pgwide="1" id="timecode-type"> + <title>Timecode Types</title> + <tgroup cols="3"> + &cs-def; + <tbody valign="top"> + <row> + <entry><constant>V4L2_TC_TYPE_24FPS</constant></entry> + <entry>1</entry> + <entry>24 frames per second, i. e. film.</entry> + </row> + <row> + <entry><constant>V4L2_TC_TYPE_25FPS</constant></entry> + <entry>2</entry> + <entry>25 frames per second, &ie; PAL or SECAM video.</entry> + </row> + <row> + <entry><constant>V4L2_TC_TYPE_30FPS</constant></entry> + <entry>3</entry> + <entry>30 frames per second, &ie; NTSC video.</entry> + </row> + <row> + <entry><constant>V4L2_TC_TYPE_50FPS</constant></entry> + <entry>4</entry> + <entry></entry> + </row> + <row> + <entry><constant>V4L2_TC_TYPE_60FPS</constant></entry> + <entry>5</entry> + <entry></entry> + </row> + </tbody> + </tgroup> + </table> + + <table frame="none" pgwide="1" id="timecode-flags"> + <title>Timecode Flags</title> + <tgroup cols="3"> + &cs-def; + <tbody valign="top"> + <row> + <entry><constant>V4L2_TC_FLAG_DROPFRAME</constant></entry> + <entry>0x0001</entry> + <entry>Indicates "drop frame" semantics for counting frames +in 29.97 fps material. When set, frame numbers 0 and 1 at the start of +each minute, except minutes 0, 10, 20, 30, 40, 50 are omitted from the +count.</entry> + </row> + <row> + <entry><constant>V4L2_TC_FLAG_COLORFRAME</constant></entry> + <entry>0x0002</entry> + <entry>The "color frame" flag.</entry> + </row> + <row> + <entry><constant>V4L2_TC_USERBITS_field</constant></entry> + <entry>0x000C</entry> + <entry>Field mask for the "binary group flags".</entry> + </row> + <row> + <entry><constant>V4L2_TC_USERBITS_USERDEFINED</constant></entry> + <entry>0x0000</entry> + <entry>Unspecified format.</entry> + </row> + <row> + <entry><constant>V4L2_TC_USERBITS_8BITCHARS</constant></entry> + <entry>0x0008</entry> + <entry>8-bit ISO characters.</entry> + </row> + </tbody> + </tgroup> + </table> + </section> + </section> + + <section id="field-order"> + <title>Field Order</title> + + <para>We have to distinguish between progressive and interlaced +video. Progressive video transmits all lines of a video image +sequentially. Interlaced video divides an image into two fields, +containing only the odd and even lines of the image, respectively. +Alternating the so called odd and even field are transmitted, and due +to a small delay between fields a cathode ray TV displays the lines +interleaved, yielding the original frame. This curious technique was +invented because at refresh rates similar to film the image would +fade out too quickly. Transmitting fields reduces the flicker without +the necessity of doubling the frame rate and with it the bandwidth +required for each channel.</para> + + <para>It is important to understand a video camera does not expose +one frame at a time, merely transmitting the frames separated into +fields. The fields are in fact captured at two different instances in +time. An object on screen may well move between one field and the +next. For applications analysing motion it is of paramount importance +to recognize which field of a frame is older, the <emphasis>temporal +order</emphasis>.</para> + + <para>When the driver provides or accepts images field by field +rather than interleaved, it is also important applications understand +how the fields combine to frames. We distinguish between top and +bottom fields, the <emphasis>spatial order</emphasis>: The first line +of the top field is the first line of an interlaced frame, the first +line of the bottom field is the second line of that frame.</para> + + <para>However because fields were captured one after the other, +arguing whether a frame commences with the top or bottom field is +pointless. Any two successive top and bottom, or bottom and top fields +yield a valid frame. Only when the source was progressive to begin +with, ⪚ when transferring film to video, two fields may come from +the same frame, creating a natural order.</para> + + <para>Counter to intuition the top field is not necessarily the +older field. Whether the older field contains the top or bottom lines +is a convention determined by the video standard. Hence the +distinction between temporal and spatial order of fields. The diagrams +below should make this clearer.</para> + + <para>All video capture and output devices must report the current +field order. Some drivers may permit the selection of a different +order, to this end applications initialize the +<structfield>field</structfield> field of &v4l2-pix-format; before +calling the &VIDIOC-S-FMT; ioctl. If this is not desired it should +have the value <constant>V4L2_FIELD_ANY</constant> (0).</para> + + <table frame="none" pgwide="1" id="v4l2-field"> + <title>enum v4l2_field</title> + <tgroup cols="3"> + &cs-def; + <tbody valign="top"> + <row> + <entry><constant>V4L2_FIELD_ANY</constant></entry> + <entry>0</entry> + <entry>Applications request this field order when any +one of the <constant>V4L2_FIELD_NONE</constant>, +<constant>V4L2_FIELD_TOP</constant>, +<constant>V4L2_FIELD_BOTTOM</constant>, or +<constant>V4L2_FIELD_INTERLACED</constant> formats is acceptable. +Drivers choose depending on hardware capabilities or e. g. the +requested image size, and return the actual field order. &v4l2-buffer; +<structfield>field</structfield> can never be +<constant>V4L2_FIELD_ANY</constant>.</entry> + </row> + <row> + <entry><constant>V4L2_FIELD_NONE</constant></entry> + <entry>1</entry> + <entry>Images are in progressive format, not interlaced. +The driver may also indicate this order when it cannot distinguish +between <constant>V4L2_FIELD_TOP</constant> and +<constant>V4L2_FIELD_BOTTOM</constant>.</entry> + </row> + <row> + <entry><constant>V4L2_FIELD_TOP</constant></entry> + <entry>2</entry> + <entry>Images consist of the top field only.</entry> + </row> + <row> + <entry><constant>V4L2_FIELD_BOTTOM</constant></entry> + <entry>3</entry> + <entry>Images consist of the bottom field only. +Applications may wish to prevent a device from capturing interlaced +images because they will have "comb" or "feathering" artefacts around +moving objects.</entry> + </row> + <row> + <entry><constant>V4L2_FIELD_INTERLACED</constant></entry> + <entry>4</entry> + <entry>Images contain both fields, interleaved line by +line. The temporal order of the fields (whether the top or bottom +field is first transmitted) depends on the current video standard. +M/NTSC transmits the bottom field first, all other standards the top +field first.</entry> + </row> + <row> + <entry><constant>V4L2_FIELD_SEQ_TB</constant></entry> + <entry>5</entry> + <entry>Images contain both fields, the top field lines +are stored first in memory, immediately followed by the bottom field +lines. Fields are always stored in temporal order, the older one first +in memory. Image sizes refer to the frame, not fields.</entry> + </row> + <row> + <entry><constant>V4L2_FIELD_SEQ_BT</constant></entry> + <entry>6</entry> + <entry>Images contain both fields, the bottom field +lines are stored first in memory, immediately followed by the top +field lines. Fields are always stored in temporal order, the older one +first in memory. Image sizes refer to the frame, not fields.</entry> + </row> + <row> + <entry><constant>V4L2_FIELD_ALTERNATE</constant></entry> + <entry>7</entry> + <entry>The two fields of a frame are passed in separate +buffers, in temporal order, &ie; the older one first. To indicate the field +parity (whether the current field is a top or bottom field) the driver +or application, depending on data direction, must set &v4l2-buffer; +<structfield>field</structfield> to +<constant>V4L2_FIELD_TOP</constant> or +<constant>V4L2_FIELD_BOTTOM</constant>. Any two successive fields pair +to build a frame. If fields are successive, without any dropped fields +between them (fields can drop individually), can be determined from +the &v4l2-buffer; <structfield>sequence</structfield> field. Image +sizes refer to the frame, not fields. This format cannot be selected +when using the read/write I/O method.<!-- Where it's indistinguishable +from V4L2_FIELD_SEQ_*. --></entry> + </row> + <row> + <entry><constant>V4L2_FIELD_INTERLACED_TB</constant></entry> + <entry>8</entry> + <entry>Images contain both fields, interleaved line by +line, top field first. The top field is transmitted first.</entry> + </row> + <row> + <entry><constant>V4L2_FIELD_INTERLACED_BT</constant></entry> + <entry>9</entry> + <entry>Images contain both fields, interleaved line by +line, top field first. The bottom field is transmitted first.</entry> + </row> + </tbody> + </tgroup> + </table> + + <figure id="fieldseq-tb"> + <title>Field Order, Top Field First Transmitted</title> + <mediaobject> + <imageobject> + <imagedata fileref="fieldseq_tb.pdf" format="PS" /> + </imageobject> + <imageobject> + <imagedata fileref="fieldseq_tb.gif" format="GIF" /> + </imageobject> + </mediaobject> + </figure> + + <figure id="fieldseq-bt"> + <title>Field Order, Bottom Field First Transmitted</title> + <mediaobject> + <imageobject> + <imagedata fileref="fieldseq_bt.pdf" format="PS" /> + </imageobject> + <imageobject> + <imagedata fileref="fieldseq_bt.gif" format="GIF" /> + </imageobject> + </mediaobject> + </figure> + </section> + + <!-- +Local Variables: +mode: sgml +sgml-parent-document: "v4l2.sgml" +indent-tabs-mode: nil +End: + --> diff --git a/Documentation/DocBook/v4l/keytable.c.xml b/Documentation/DocBook/v4l/keytable.c.xml new file mode 100644 index 000000000000..d53254a3be15 --- /dev/null +++ b/Documentation/DocBook/v4l/keytable.c.xml @@ -0,0 +1,172 @@ +<programlisting> +/* keytable.c - This program allows checking/replacing keys at IR + + Copyright (C) 2006-2009 Mauro Carvalho Chehab <mchehab@infradead.org> + + This program is free software; you can redistribute it and/or modify + it under the terms of the GNU General Public License as published by + the Free Software Foundation, version 2 of the License. + + This program is distributed in the hope that it will be useful, + but WITHOUT ANY WARRANTY; without even the implied warranty of + MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + GNU General Public License for more details. + */ + +#include <ctype.h> +#include <errno.h> +#include <fcntl.h> +#include <stdio.h> +#include <stdlib.h> +#include <string.h> +#include <linux/input.h> +#include <sys/ioctl.h> + +#include "parse.h" + +void prtcode (int *codes) +{ + struct parse_key *p; + + for (p=keynames;p->name!=NULL;p++) { + if (p->value == (unsigned)codes[1]) { + printf("scancode 0x%04x = %s (0x%02x)\n", codes[0], p->name, codes[1]); + return; + } + } + + if (isprint (codes[1])) + printf("scancode %d = '%c' (0x%02x)\n", codes[0], codes[1], codes[1]); + else + printf("scancode %d = 0x%02x\n", codes[0], codes[1]); +} + +int parse_code(char *string) +{ + struct parse_key *p; + + for (p=keynames;p->name!=NULL;p++) { + if (!strcasecmp(p->name, string)) { + return p->value; + } + } + return -1; +} + +int main (int argc, char *argv[]) +{ + int fd; + unsigned int i, j; + int codes[2]; + + if (argc<2 || argc>4) { + printf ("usage: %s <device> to get table; or\n" + " %s <device> <scancode> <keycode>\n" + " %s <device> <keycode_file>\n",*argv,*argv,*argv); + return -1; + } + + if ((fd = open(argv[1], O_RDONLY)) < 0) { + perror("Couldn't open input device"); + return(-1); + } + + if (argc==4) { + int value; + + value=parse_code(argv[3]); + + if (value==-1) { + value = strtol(argv[3], NULL, 0); + if (errno) + perror("value"); + } + + codes [0] = (unsigned) strtol(argv[2], NULL, 0); + codes [1] = (unsigned) value; + + if(ioctl(fd, EVIOCSKEYCODE, codes)) + perror ("EVIOCSKEYCODE"); + + if(ioctl(fd, EVIOCGKEYCODE, codes)==0) + prtcode(codes); + return 0; + } + + if (argc==3) { + FILE *fin; + int value; + char *scancode, *keycode, s[2048]; + + fin=fopen(argv[2],"r"); + if (fin==NULL) { + perror ("opening keycode file"); + return -1; + } + + /* Clears old table */ + for (j = 0; j < 256; j++) { + for (i = 0; i < 256; i++) { + codes[0] = (j << 8) | i; + codes[1] = KEY_RESERVED; + ioctl(fd, EVIOCSKEYCODE, codes); + } + } + + while (fgets(s,sizeof(s),fin)) { + scancode=strtok(s,"\n\t =:"); + if (!scancode) { + perror ("parsing input file scancode"); + return -1; + } + if (!strcasecmp(scancode, "scancode")) { + scancode = strtok(NULL,"\n\t =:"); + if (!scancode) { + perror ("parsing input file scancode"); + return -1; + } + } + + keycode=strtok(NULL,"\n\t =:("); + if (!keycode) { + perror ("parsing input file keycode"); + return -1; + } + + // printf ("parsing %s=%s:", scancode, keycode); + value=parse_code(keycode); + // printf ("\tvalue=%d\n",value); + + if (value==-1) { + value = strtol(keycode, NULL, 0); + if (errno) + perror("value"); + } + + codes [0] = (unsigned) strtol(scancode, NULL, 0); + codes [1] = (unsigned) value; + + // printf("\t%04x=%04x\n",codes[0], codes[1]); + if(ioctl(fd, EVIOCSKEYCODE, codes)) { + fprintf(stderr, "Setting scancode 0x%04x with 0x%04x via ",codes[0], codes[1]); + perror ("EVIOCSKEYCODE"); + } + + if(ioctl(fd, EVIOCGKEYCODE, codes)==0) + prtcode(codes); + } + return 0; + } + + /* Get scancode table */ + for (j = 0; j < 256; j++) { + for (i = 0; i < 256; i++) { + codes[0] = (j << 8) | i; + if (!ioctl(fd, EVIOCGKEYCODE, codes) && codes[1] != KEY_RESERVED) + prtcode(codes); + } + } + return 0; +} + +</programlisting> diff --git a/Documentation/DocBook/v4l/libv4l.xml b/Documentation/DocBook/v4l/libv4l.xml new file mode 100644 index 000000000000..c14fc3db2a81 --- /dev/null +++ b/Documentation/DocBook/v4l/libv4l.xml @@ -0,0 +1,167 @@ +<title>Libv4l Userspace Library</title> +<section id="libv4l-introduction"> + <title>Introduction</title> + + <para>libv4l is a collection of libraries which adds a thin abstraction +layer on top of video4linux2 devices. The purpose of this (thin) layer +is to make it easy for application writers to support a wide variety of +devices without having to write separate code for different devices in the +same class.</para> +<para>An example of using libv4l is provided by +<link linkend='v4l2grab-example'>v4l2grab</link>. +</para> + + <para>libv4l consists of 3 different libraries:</para> + <section> + <title>libv4lconvert</title> + + <para>libv4lconvert is a library that converts several +different pixelformats found in V4L2 drivers into a few common RGB and +YUY formats.</para> + <para>It currently accepts the following V4L2 driver formats: +<link linkend="V4L2-PIX-FMT-BGR24"><constant>V4L2_PIX_FMT_BGR24</constant></link>, +<link linkend="V4L2-PIX-FMT-HM12"><constant>V4L2_PIX_FMT_HM12</constant></link>, +<link linkend="V4L2-PIX-FMT-JPEG"><constant>V4L2_PIX_FMT_JPEG</constant></link>, +<link linkend="V4L2-PIX-FMT-MJPEG"><constant>V4L2_PIX_FMT_MJPEG</constant></link>, +<link linkend="V4L2-PIX-FMT-MR97310A"><constant>V4L2_PIX_FMT_MR97310A</constant></link>, +<link linkend="V4L2-PIX-FMT-OV511"><constant>V4L2_PIX_FMT_OV511</constant></link>, +<link linkend="V4L2-PIX-FMT-OV518"><constant>V4L2_PIX_FMT_OV518</constant></link>, +<link linkend="V4L2-PIX-FMT-PAC207"><constant>V4L2_PIX_FMT_PAC207</constant></link>, +<link linkend="V4L2-PIX-FMT-PJPG"><constant>V4L2_PIX_FMT_PJPG</constant></link>, +<link linkend="V4L2-PIX-FMT-RGB24"><constant>V4L2_PIX_FMT_RGB24</constant></link>, +<link linkend="V4L2-PIX-FMT-SBGGR8"><constant>V4L2_PIX_FMT_SBGGR8</constant></link>, +<link linkend="V4L2-PIX-FMT-SGBRG8"><constant>V4L2_PIX_FMT_SGBRG8</constant></link>, +<link linkend="V4L2-PIX-FMT-SGRBG8"><constant>V4L2_PIX_FMT_SGRBG8</constant></link>, +<link linkend="V4L2-PIX-FMT-SN9C10X"><constant>V4L2_PIX_FMT_SN9C10X</constant></link>, +<link linkend="V4L2-PIX-FMT-SN9C20X-I420"><constant>V4L2_PIX_FMT_SN9C20X_I420</constant></link>, +<link linkend="V4L2-PIX-FMT-SPCA501"><constant>V4L2_PIX_FMT_SPCA501</constant></link>, +<link linkend="V4L2-PIX-FMT-SPCA505"><constant>V4L2_PIX_FMT_SPCA505</constant></link>, +<link linkend="V4L2-PIX-FMT-SPCA508"><constant>V4L2_PIX_FMT_SPCA508</constant></link>, +<link linkend="V4L2-PIX-FMT-SPCA561"><constant>V4L2_PIX_FMT_SPCA561</constant></link>, +<link linkend="V4L2-PIX-FMT-SQ905C"><constant>V4L2_PIX_FMT_SQ905C</constant></link>, +<constant>V4L2_PIX_FMT_SRGGB8</constant>, +<link linkend="V4L2-PIX-FMT-UYVY"><constant>V4L2_PIX_FMT_UYVY</constant></link>, +<link linkend="V4L2-PIX-FMT-YUV420"><constant>V4L2_PIX_FMT_YUV420</constant></link>, +<link linkend="V4L2-PIX-FMT-YUYV"><constant>V4L2_PIX_FMT_YUYV</constant></link>, +<link linkend="V4L2-PIX-FMT-YVU420"><constant>V4L2_PIX_FMT_YVU420</constant></link>, +and <link linkend="V4L2-PIX-FMT-YVYU"><constant>V4L2_PIX_FMT_YVYU</constant></link>. +</para> + <para>Later on libv4lconvert was expanded to also be able to do +various video processing functions to improve webcam video quality. +The video processing is split in to 2 parts: libv4lconvert/control and +libv4lconvert/processing.</para> + + <para>The control part is used to offer video controls which can +be used to control the video processing functions made available by + libv4lconvert/processing. These controls are stored application wide +(until reboot) by using a persistent shared memory object.</para> + + <para>libv4lconvert/processing offers the actual video +processing functionality.</para> + </section> + <section> + <title>libv4l1</title> + <para>This library offers functions that can be used to quickly +make v4l1 applications work with v4l2 devices. These functions work exactly +like the normal open/close/etc, except that libv4l1 does full emulation of +the v4l1 api on top of v4l2 drivers, in case of v4l1 drivers it +will just pass calls through.</para> + <para>Since those functions are emulations of the old V4L1 API, +it shouldn't be used for new applications.</para> + </section> + <section> + <title>libv4l2</title> + <para>This library should be used for all modern V4L2 +applications.</para> + <para>It provides handles to call V4L2 open/ioctl/close/poll +methods. Instead of just providing the raw output of the device, it enhances +the calls in the sense that it will use libv4lconvert to provide more video +formats and to enhance the image quality.</para> + <para>In most cases, libv4l2 just passes the calls directly +through to the v4l2 driver, intercepting the calls to +<link linkend='vidioc-g-fmt'><constant>VIDIOC_TRY_FMT</constant></link>, +<link linkend='vidioc-g-fmt'><constant>VIDIOC_G_FMT</constant></link> +<link linkend='vidioc-g-fmt'><constant>VIDIOC_S_FMT</constant></link> +<link linkend='vidioc-enum-framesizes'><constant>VIDIOC_ENUM_FRAMESIZES</constant></link> +and <link linkend='vidioc-enum-frameintervals'><constant>VIDIOC_ENUM_FRAMEINTERVALS</constant></link> +in order to emulate the formats +<link linkend="V4L2-PIX-FMT-BGR24"><constant>V4L2_PIX_FMT_BGR24</constant></link>, +<link linkend="V4L2-PIX-FMT-RGB24"><constant>V4L2_PIX_FMT_RGB24</constant></link>, +<link linkend="V4L2-PIX-FMT-YUV420"><constant>V4L2_PIX_FMT_YUV420</constant></link>, +and <link linkend="V4L2-PIX-FMT-YVU420"><constant>V4L2_PIX_FMT_YVU420</constant></link>, +if they aren't available in the driver. +<link linkend='vidioc-enum-fmt'><constant>VIDIOC_ENUM_FMT</constant></link> +keeps enumerating the hardware supported formats, plus the emulated formats +offered by libv4l at the end. +</para> + <section id="libv4l-ops"> + <title>Libv4l device control functions</title> + <para>The common file operation methods are provided by +libv4l.</para> + <para>Those functions operate just like glibc +open/close/dup/ioctl/read/mmap/munmap:</para> +<itemizedlist><listitem> + <para>int v4l2_open(const char *file, int oflag, +...) - +operates like the standard <link linkend='func-open'>open()</link> function. +</para></listitem><listitem> + <para>int v4l2_close(int fd) - +operates like the standard <link linkend='func-close'>close()</link> function. +</para></listitem><listitem> + <para>int v4l2_dup(int fd) - +operates like the standard dup() function, duplicating a file handler. +</para></listitem><listitem> + <para>int v4l2_ioctl (int fd, unsigned long int request, ...) - +operates like the standard <link linkend='func-ioctl'>ioctl()</link> function. +</para></listitem><listitem> + <para>int v4l2_read (int fd, void* buffer, size_t n) - +operates like the standard <link linkend='func-read'>read()</link> function. +</para></listitem><listitem> + <para>void v4l2_mmap(void *start, size_t length, int prot, int flags, int fd, int64_t offset); - +operates like the standard <link linkend='func-mmap'>mmap()</link> function. +</para></listitem><listitem> + <para>int v4l2_munmap(void *_start, size_t length); - +operates like the standard <link linkend='func-munmap'>munmap()</link> function. +</para></listitem> +</itemizedlist> + <para>Those functions provide additional control:</para> +<itemizedlist><listitem> + <para>int v4l2_fd_open(int fd, int v4l2_flags) - +opens an already opened fd for further use through v4l2lib and possibly +modify libv4l2's default behavior through the v4l2_flags argument. +Currently, v4l2_flags can be <constant>V4L2_DISABLE_CONVERSION</constant>, +to disable format conversion. +</para></listitem><listitem> + <para>int v4l2_set_control(int fd, int cid, int value) - +This function takes a value of 0 - 65535, and then scales that range to +the actual range of the given v4l control id, and then if the cid exists +and is not locked sets the cid to the scaled value. +</para></listitem><listitem> + <para>int v4l2_get_control(int fd, int cid) - +This function returns a value of 0 - 65535, scaled to from the actual range +of the given v4l control id. when the cid does not exist, could not be +accessed for some reason, or some error occured 0 is returned. +</para></listitem> +</itemizedlist> + </section> + </section> + <section> + + <title>v4l1compat.so wrapper library</title> + + <para>This library intercepts calls to +open/close/ioctl/mmap/mmunmap operations and redirects them to the libv4l +counterparts, by using LD_PRELOAD=/usr/lib/v4l1compat.so. It also +emulates V4L1 calls via V4L2 API.</para> + <para>It allows usage of binary legacy applications that +still don't use libv4l.</para> + </section> + +</section> +<!-- +Local Variables: +mode: sgml +sgml-parent-document: "v4l2.sgml" +indent-tabs-mode: nil +End: +--> diff --git a/Documentation/DocBook/v4l/pixfmt-grey.xml b/Documentation/DocBook/v4l/pixfmt-grey.xml new file mode 100644 index 000000000000..3b72bc6b2de7 --- /dev/null +++ b/Documentation/DocBook/v4l/pixfmt-grey.xml @@ -0,0 +1,70 @@ + <refentry id="V4L2-PIX-FMT-GREY"> + <refmeta> + <refentrytitle>V4L2_PIX_FMT_GREY ('GREY')</refentrytitle> + &manvol; + </refmeta> + <refnamediv> + <refname><constant>V4L2_PIX_FMT_GREY</constant></refname> + <refpurpose>Grey-scale image</refpurpose> + </refnamediv> + <refsect1> + <title>Description</title> + + <para>This is a grey-scale image. It is really a degenerate +Y'CbCr format which simply contains no Cb or Cr data.</para> + + <example> + <title><constant>V4L2_PIX_FMT_GREY</constant> 4 × 4 +pixel image</title> + + <formalpara> + <title>Byte Order.</title> + <para>Each cell is one byte. + <informaltable frame="none"> + <tgroup cols="5" align="center"> + <colspec align="left" colwidth="2*" /> + <tbody valign="top"> + <row> + <entry>start + 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>start + 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>start + 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>start + 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> + </tbody> + </tgroup> + </informaltable> + </para> + </formalpara> + </example> + </refsect1> + </refentry> + + <!-- +Local Variables: +mode: sgml +sgml-parent-document: "pixfmt.sgml" +indent-tabs-mode: nil +End: + --> diff --git a/Documentation/DocBook/v4l/pixfmt-nv12.xml b/Documentation/DocBook/v4l/pixfmt-nv12.xml new file mode 100644 index 000000000000..873f67035181 --- /dev/null +++ b/Documentation/DocBook/v4l/pixfmt-nv12.xml @@ -0,0 +1,151 @@ + <refentry> + <refmeta> + <refentrytitle>V4L2_PIX_FMT_NV12 ('NV12'), V4L2_PIX_FMT_NV21 ('NV21')</refentrytitle> + &manvol; + </refmeta> + <refnamediv> + <refname id="V4L2-PIX-FMT-NV12"><constant>V4L2_PIX_FMT_NV12</constant></refname> + <refname id="V4L2-PIX-FMT-NV21"><constant>V4L2_PIX_FMT_NV21</constant></refname> + <refpurpose>Formats with ½ horizontal and vertical +chroma resolution, also known as YUV 4:2:0. One luminance and one +chrominance plane with alternating chroma samples as opposed to +<constant>V4L2_PIX_FMT_YVU420</constant></refpurpose> + </refnamediv> + <refsect1> + <title>Description</title> + + <para>These are two-plane versions of the YUV 4:2:0 format. +The three components are separated into two sub-images or planes. The +Y plane is first. The Y plane has one byte per pixel. For +<constant>V4L2_PIX_FMT_NV12</constant>, a combined CbCr plane +immediately follows the Y plane in memory. 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>. +<constant>V4L2_PIX_FMT_NV21</constant> is the same except the Cb and +Cr bytes are swapped, the CrCb plane starts with a Cr byte.</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_NV12</constant> 4 × 4 +pixel image</title> + + <formalpara> + <title>Byte Order.</title> + <para>Each cell is one byte. + <informaltable frame="none"> + <tgroup cols="5" align="center"> + <colspec align="left" colwidth="2*" /> + <tbody valign="top"> + <row> + <entry>start + 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>start + 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>start + 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>start + 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>start + 16:</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>start + 20:</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: + --> diff --git a/Documentation/DocBook/v4l/pixfmt-nv16.xml b/Documentation/DocBook/v4l/pixfmt-nv16.xml new file mode 100644 index 000000000000..26094035fc04 --- /dev/null +++ b/Documentation/DocBook/v4l/pixfmt-nv16.xml @@ -0,0 +1,174 @@ + <refentry> + <refmeta> + <refentrytitle>V4L2_PIX_FMT_NV16 ('NV16'), V4L2_PIX_FMT_NV61 ('NV61')</refentrytitle> + &manvol; + </refmeta> + <refnamediv> + <refname id="V4L2-PIX-FMT-NV16"><constant>V4L2_PIX_FMT_NV16</constant></refname> + <refname id="V4L2-PIX-FMT-NV61"><constant>V4L2_PIX_FMT_NV61</constant></refname> + <refpurpose>Formats with ½ horizontal +chroma resolution, also known as YUV 4:2:2. One luminance and one +chrominance plane with alternating chroma samples as opposed to +<constant>V4L2_PIX_FMT_YVU420</constant></refpurpose> + </refnamediv> + <refsect1> + <title>Description</title> + + <para>These are two-plane versions of the YUV 4:2:2 format. +The three components are separated into two sub-images or planes. The +Y plane is first. The Y plane has one byte per pixel. For +<constant>V4L2_PIX_FMT_NV16</constant>, a combined CbCr plane +immediately follows the Y plane in memory. The CbCr plane is the same +width and height, in bytes, as the Y plane (and of the image). +Each CbCr pair belongs to two pixels. For example, +Cb<subscript>0</subscript>/Cr<subscript>0</subscript> belongs to +Y'<subscript>00</subscript>, Y'<subscript>01</subscript>. +<constant>V4L2_PIX_FMT_NV61</constant> is the same except the Cb and +Cr bytes are swapped, the CrCb plane starts with a Cr byte.</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_NV16</constant> 4 × 4 +pixel image</title> + + <formalpara> + <title>Byte Order.</title> + <para>Each cell is one byte. + <informaltable frame="none"> + <tgroup cols="5" align="center"> + <colspec align="left" colwidth="2*" /> + <tbody valign="top"> + <row> + <entry>start + 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>start + 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>start + 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>start + 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>start + 16:</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>start + 20:</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> + <row> + <entry>start + 24:</entry> + <entry>Cb<subscript>20</subscript></entry> + <entry>Cr<subscript>20</subscript></entry> + <entry>Cb<subscript>21</subscript></entry> + <entry>Cr<subscript>21</subscript></entry> + </row> + <row> + <entry>start + 28:</entry> + <entry>Cb<subscript>30</subscript></entry> + <entry>Cr<subscript>30</subscript></entry> + <entry>Cb<subscript>31</subscript></entry> + <entry>Cr<subscript>31</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> + <entry></entry><entry>C</entry><entry></entry><entry></entry> + <entry></entry><entry>C</entry><entry></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> + <row> + <entry></entry> + <entry></entry><entry>C</entry><entry></entry><entry></entry> + <entry></entry><entry>C</entry><entry></entry> + </row> + </tbody> + </tgroup> + </informaltable> + </para> + </formalpara> + </example> + </refsect1> + </refentry> + + <!-- +Local Variables: +mode: sgml +sgml-parent-document: "pixfmt.sgml" +indent-tabs-mode: nil +End: + --> diff --git a/Documentation/DocBook/v4l/pixfmt-packed-rgb.xml b/Documentation/DocBook/v4l/pixfmt-packed-rgb.xml new file mode 100644 index 000000000000..d2dd697a81d8 --- /dev/null +++ b/Documentation/DocBook/v4l/pixfmt-packed-rgb.xml @@ -0,0 +1,862 @@ +<refentry id="packed-rgb"> + <refmeta> + <refentrytitle>Packed RGB formats</refentrytitle> + &manvol; + </refmeta> + <refnamediv> + <refname>Packed RGB formats</refname> + <refpurpose>Packed RGB formats</refpurpose> + </refnamediv> + <refsect1> + <title>Description</title> + + <para>These formats are designed to match the pixel formats of +typical PC graphics frame buffers. They occupy 8, 16, 24 or 32 bits +per pixel. These are all packed-pixel formats, meaning all the data +for a pixel lie next to each other in memory.</para> + + <para>When one of these formats is used, drivers shall report the +colorspace <constant>V4L2_COLORSPACE_SRGB</constant>.</para> + + <table pgwide="1" frame="none" id="rgb-formats"> + <title>Packed RGB Image Formats</title> + <tgroup cols="37" align="center"> + <colspec colname="id" align="left" /> + <colspec colname="fourcc" /> + <colspec colname="bit" /> + + <colspec colnum="4" colname="b07" align="center" /> + <colspec colnum="5" colname="b06" align="center" /> + <colspec colnum="6" colname="b05" align="center" /> + <colspec colnum="7" colname="b04" align="center" /> + <colspec colnum="8" colname="b03" align="center" /> + <colspec colnum="9" colname="b02" align="center" /> + <colspec colnum="10" colname="b01" align="center" /> + <colspec colnum="11" colname="b00" align="center" /> + + <colspec colnum="13" colname="b17" align="center" /> + <colspec colnum="14" colname="b16" align="center" /> + <colspec colnum="15" colname="b15" align="center" /> + <colspec colnum="16" colname="b14" align="center" /> + <colspec colnum="17" colname="b13" align="center" /> + <colspec colnum="18" colname="b12" align="center" /> + <colspec colnum="19" colname="b11" align="center" /> + <colspec colnum="20" colname="b10" align="center" /> + + <colspec colnum="22" colname="b27" align="center" /> + <colspec colnum="23" colname="b26" align="center" /> + <colspec colnum="24" colname="b25" align="center" /> + <colspec colnum="25" colname="b24" align="center" /> + <colspec colnum="26" colname="b23" align="center" /> + <colspec colnum="27" colname="b22" align="center" /> + <colspec colnum="28" colname="b21" align="center" /> + <colspec colnum="29" colname="b20" align="center" /> + + <colspec colnum="31" colname="b37" align="center" /> + <colspec colnum="32" colname="b36" align="center" /> + <colspec colnum="33" colname="b35" align="center" /> + <colspec colnum="34" colname="b34" align="center" /> + <colspec colnum="35" colname="b33" align="center" /> + <colspec colnum="36" colname="b32" align="center" /> + <colspec colnum="37" colname="b31" align="center" /> + <colspec colnum="38" colname="b30" align="center" /> + + <spanspec namest="b07" nameend="b00" spanname="b0" /> + <spanspec namest="b17" nameend="b10" spanname="b1" /> + <spanspec namest="b27" nameend="b20" spanname="b2" /> + <spanspec namest="b37" nameend="b30" spanname="b3" /> + <thead> + <row> + <entry>Identifier</entry> + <entry>Code</entry> + <entry> </entry> + <entry spanname="b0">Byte 0 in memory</entry> + <entry spanname="b1">Byte 1</entry> + <entry spanname="b2">Byte 2</entry> + <entry spanname="b3">Byte 3</entry> + </row> + <row> + <entry> </entry> + <entry> </entry> + <entry>Bit</entry> + <entry>7</entry> + <entry>6</entry> + <entry>5</entry> + <entry>4</entry> + <entry>3</entry> + <entry>2</entry> + <entry>1</entry> + <entry>0</entry> + <entry> </entry> + <entry>7</entry> + <entry>6</entry> + <entry>5</entry> + <entry>4</entry> + <entry>3</entry> + <entry>2</entry> + <entry>1</entry> + <entry>0</entry> + <entry> </entry> + <entry>7</entry> + <entry>6</entry> + <entry>5</entry> + <entry>4</entry> + <entry>3</entry> + <entry>2</entry> + <entry>1</entry> + <entry>0</entry> + <entry> </entry> + <entry>7</entry> + <entry>6</entry> + <entry>5</entry> + <entry>4</entry> + <entry>3</entry> + <entry>2</entry> + <entry>1</entry> + <entry>0</entry> + </row> + </thead> + <tbody valign="top"> + <row id="V4L2-PIX-FMT-RGB332"> + <entry><constant>V4L2_PIX_FMT_RGB332</constant></entry> + <entry>'RGB1'</entry> + <entry></entry> + <entry>b<subscript>1</subscript></entry> + <entry>b<subscript>0</subscript></entry> + <entry>g<subscript>2</subscript></entry> + <entry>g<subscript>1</subscript></entry> + <entry>g<subscript>0</subscript></entry> + <entry>r<subscript>2</subscript></entry> + <entry>r<subscript>1</subscript></entry> + <entry>r<subscript>0</subscript></entry> + </row> + <row id="V4L2-PIX-FMT-RGB444"> + <entry><constant>V4L2_PIX_FMT_RGB444</constant></entry> + <entry>'R444'</entry> + <entry></entry> + <entry>g<subscript>3</subscript></entry> + <entry>g<subscript>2</subscript></entry> + <entry>g<subscript>1</subscript></entry> + <entry>g<subscript>0</subscript></entry> + <entry>b<subscript>3</subscript></entry> + <entry>b<subscript>2</subscript></entry> + <entry>b<subscript>1</subscript></entry> + <entry>b<subscript>0</subscript></entry> + <entry></entry> + <entry>a<subscript>3</subscript></entry> + <entry>a<subscript>2</subscript></entry> + <entry>a<subscript>1</subscript></entry> + <entry>a<subscript>0</subscript></entry> + <entry>r<subscript>3</subscript></entry> + <entry>r<subscript>2</subscript></entry> + <entry>r<subscript>1</subscript></entry> + <entry>r<subscript>0</subscript></entry> + </row> + <row id="V4L2-PIX-FMT-RGB555"> + <entry><constant>V4L2_PIX_FMT_RGB555</constant></entry> + <entry>'RGBO'</entry> + <entry></entry> + <entry>g<subscript>2</subscript></entry> + <entry>g<subscript>1</subscript></entry> + <entry>g<subscript>0</subscript></entry> + <entry>r<subscript>4</subscript></entry> + <entry>r<subscript>3</subscript></entry> + <entry>r<subscript>2</subscript></entry> + <entry>r<subscript>1</subscript></entry> + <entry>r<subscript>0</subscript></entry> + <entry></entry> + <entry>a</entry> + <entry>b<subscript>4</subscript></entry> + <entry>b<subscript>3</subscript></entry> + <entry>b<subscript>2</subscript></entry> + <entry>b<subscript>1</subscript></entry> + <entry>b<subscript>0</subscript></entry> + <entry>g<subscript>4</subscript></entry> + <entry>g<subscript>3</subscript></entry> + </row> + <row id="V4L2-PIX-FMT-RGB565"> + <entry><constant>V4L2_PIX_FMT_RGB565</constant></entry> + <entry>'RGBP'</entry> + <entry></entry> + <entry>g<subscript>2</subscript></entry> + <entry>g<subscript>1</subscript></entry> + <entry>g<subscript>0</subscript></entry> + <entry>r<subscript>4</subscript></entry> + <entry>r<subscript>3</subscript></entry> + <entry>r<subscript>2</subscript></entry> + <entry>r<subscript>1</subscript></entry> + <entry>r<subscript>0</subscript></entry> + <entry></entry> + <entry>b<subscript>4</subscript></entry> + <entry>b<subscript>3</subscript></entry> + <entry>b<subscript>2</subscript></entry> + <entry>b<subscript>1</subscript></entry> + <entry>b<subscript>0</subscript></entry> + <entry>g<subscript>5</subscript></entry> + <entry>g<subscript>4</subscript></entry> + <entry>g<subscript>3</subscript></entry> + </row> + <row id="V4L2-PIX-FMT-RGB555X"> + <entry><constant>V4L2_PIX_FMT_RGB555X</constant></entry> + <entry>'RGBQ'</entry> + <entry></entry> + <entry>a</entry> + <entry>b<subscript>4</subscript></entry> + <entry>b<subscript>3</subscript></entry> + <entry>b<subscript>2</subscript></entry> + <entry>b<subscript>1</subscript></entry> + <entry>b<subscript>0</subscript></entry> + <entry>g<subscript>4</subscript></entry> + <entry>g<subscript>3</subscript></entry> + <entry></entry> + <entry>g<subscript>2</subscript></entry> + <entry>g<subscript>1</subscript></entry> + <entry>g<subscript>0</subscript></entry> + <entry>r<subscript>4</subscript></entry> + <entry>r<subscript>3</subscript></entry> + <entry>r<subscript>2</subscript></entry> + <entry>r<subscript>1</subscript></entry> + <entry>r<subscript>0</subscript></entry> + </row> + <row id="V4L2-PIX-FMT-RGB565X"> + <entry><constant>V4L2_PIX_FMT_RGB565X</constant></entry> + <entry>'RGBR'</entry> + <entry></entry> + <entry>b<subscript>4</subscript></entry> + <entry>b<subscript>3</subscript></entry> + <entry>b<subscript>2</subscript></entry> + <entry>b<subscript>1</subscript></entry> + <entry>b<subscript>0</subscript></entry> + <entry>g<subscript>5</subscript></entry> + <entry>g<subscript>4</subscript></entry> + <entry>g<subscript>3</subscript></entry> + <entry></entry> + <entry>g<subscript>2</subscript></entry> + <entry>g<subscript>1</subscript></entry> + <entry>g<subscript>0</subscript></entry> + <entry>r<subscript>4</subscript></entry> + <entry>r<subscript>3</subscript></entry> + <entry>r<subscript>2</subscript></entry> + <entry>r<subscript>1</subscript></entry> + <entry>r<subscript>0</subscript></entry> + </row> + <row id="V4L2-PIX-FMT-BGR24"> + <entry><constant>V4L2_PIX_FMT_BGR24</constant></entry> + <entry>'BGR3'</entry> + <entry></entry> + <entry>b<subscript>7</subscript></entry> + <entry>b<subscript>6</subscript></entry> + <entry>b<subscript>5</subscript></entry> + <entry>b<subscript>4</subscript></entry> + <entry>b<subscript>3</subscript></entry> + <entry>b<subscript>2</subscript></entry> + <entry>b<subscript>1</subscript></entry> + <entry>b<subscript>0</subscript></entry> + <entry></entry> + <entry>g<subscript>7</subscript></entry> + <entry>g<subscript>6</subscript></entry> + <entry>g<subscript>5</subscript></entry> + <entry>g<subscript>4</subscript></entry> + <entry>g<subscript>3</subscript></entry> + <entry>g<subscript>2</subscript></entry> + <entry>g<subscript>1</subscript></entry> + <entry>g<subscript>0</subscript></entry> + <entry></entry> + <entry>r<subscript>7</subscript></entry> + <entry>r<subscript>6</subscript></entry> + <entry>r<subscript>5</subscript></entry> + <entry>r<subscript>4</subscript></entry> + <entry>r<subscript>3</subscript></entry> + <entry>r<subscript>2</subscript></entry> + <entry>r<subscript>1</subscript></entry> + <entry>r<subscript>0</subscript></entry> + </row> + <row id="V4L2-PIX-FMT-RGB24"> + <entry><constant>V4L2_PIX_FMT_RGB24</constant></entry> + <entry>'RGB3'</entry> + <entry></entry> + <entry>r<subscript>7</subscript></entry> + <entry>r<subscript>6</subscript></entry> + <entry>r<subscript>5</subscript></entry> + <entry>r<subscript>4</subscript></entry> + <entry>r<subscript>3</subscript></entry> + <entry>r<subscript>2</subscript></entry> + <entry>r<subscript>1</subscript></entry> + <entry>r<subscript>0</subscript></entry> + <entry></entry> + <entry>g<subscript>7</subscript></entry> + <entry>g<subscript>6</subscript></entry> + <entry>g<subscript>5</subscript></entry> + <entry>g<subscript>4</subscript></entry> + <entry>g<subscript>3</subscript></entry> + <entry>g<subscript>2</subscript></entry> + <entry>g<subscript>1</subscript></entry> + <entry>g<subscript>0</subscript></entry> + <entry></entry> + <entry>b<subscript>7</subscript></entry> + <entry>b<subscript>6</subscript></entry> + <entry>b<subscript>5</subscript></entry> + <entry>b<subscript>4</subscript></entry> + <entry>b<subscript>3</subscript></entry> + <entry>b<subscript>2</subscript></entry> + <entry>b<subscript>1</subscript></entry> + <entry>b<subscript>0</subscript></entry> + </row> + <row id="V4L2-PIX-FMT-BGR32"> + <entry><constant>V4L2_PIX_FMT_BGR32</constant></entry> + <entry>'BGR4'</entry> + <entry></entry> + <entry>b<subscript>7</subscript></entry> + <entry>b<subscript>6</subscript></entry> + <entry>b<subscript>5</subscript></entry> + <entry>b<subscript>4</subscript></entry> + <entry>b<subscript>3</subscript></entry> + <entry>b<subscript>2</subscript></entry> + <entry>b<subscript>1</subscript></entry> + <entry>b<subscript>0</subscript></entry> + <entry></entry> + <entry>g<subscript>7</subscript></entry> + <entry>g<subscript>6</subscript></entry> + <entry>g<subscript>5</subscript></entry> + <entry>g<subscript>4</subscript></entry> + <entry>g<subscript>3</subscript></entry> + <entry>g<subscript>2</subscript></entry> + <entry>g<subscript>1</subscript></entry> + <entry>g<subscript>0</subscript></entry> + <entry></entry> + <entry>r<subscript>7</subscript></entry> + <entry>r<subscript>6</subscript></entry> + <entry>r<subscript>5</subscript></entry> + <entry>r<subscript>4</subscript></entry> + <entry>r<subscript>3</subscript></entry> + <entry>r<subscript>2</subscript></entry> + <entry>r<subscript>1</subscript></entry> + <entry>r<subscript>0</subscript></entry> + <entry></entry> + <entry>a<subscript>7</subscript></entry> + <entry>a<subscript>6</subscript></entry> + <entry>a<subscript>5</subscript></entry> + <entry>a<subscript>4</subscript></entry> + <entry>a<subscript>3</subscript></entry> + <entry>a<subscript>2</subscript></entry> + <entry>a<subscript>1</subscript></entry> + <entry>a<subscript>0</subscript></entry> + </row> + <row id="V4L2-PIX-FMT-RGB32"> + <entry><constant>V4L2_PIX_FMT_RGB32</constant></entry> + <entry>'RGB4'</entry> + <entry></entry> + <entry>r<subscript>7</subscript></entry> + <entry>r<subscript>6</subscript></entry> + <entry>r<subscript>5</subscript></entry> + <entry>r<subscript>4</subscript></entry> + <entry>r<subscript>3</subscript></entry> + <entry>r<subscript>2</subscript></entry> + <entry>r<subscript>1</subscript></entry> + <entry>r<subscript>0</subscript></entry> + <entry></entry> + <entry>g<subscript>7</subscript></entry> + <entry>g<subscript>6</subscript></entry> + <entry>g<subscript>5</subscript></entry> + <entry>g<subscript>4</subscript></entry> + <entry>g<subscript>3</subscript></entry> + <entry>g<subscript>2</subscript></entry> + <entry>g<subscript>1</subscript></entry> + <entry>g<subscript>0</subscript></entry> + <entry></entry> + <entry>b<subscript>7</subscript></entry> + <entry>b<subscript>6</subscript></entry> + <entry>b<subscript>5</subscript></entry> + <entry>b<subscript>4</subscript></entry> + <entry>b<subscript>3</subscript></entry> + <entry>b<subscript>2</subscript></entry> + <entry>b<subscript>1</subscript></entry> + <entry>b<subscript>0</subscript></entry> + <entry></entry> + <entry>a<subscript>7</subscript></entry> + <entry>a<subscript>6</subscript></entry> + <entry>a<subscript>5</subscript></entry> + <entry>a<subscript>4</subscript></entry> + <entry>a<subscript>3</subscript></entry> + <entry>a<subscript>2</subscript></entry> + <entry>a<subscript>1</subscript></entry> + <entry>a<subscript>0</subscript></entry> + </row> + </tbody> + </tgroup> + </table> + + <para>Bit 7 is the most significant bit. The value of a = alpha +bits is undefined when reading from the driver, ignored when writing +to the driver, except when alpha blending has been negotiated for a +<link linkend="overlay">Video Overlay</link> or <link +linkend="osd">Video Output Overlay</link>.</para> + + <example> + <title><constant>V4L2_PIX_FMT_BGR24</constant> 4 × 4 pixel +image</title> + + <formalpara> + <title>Byte Order.</title> + <para>Each cell is one byte. + <informaltable frame="none"> + <tgroup cols="13" align="center"> + <colspec align="left" colwidth="2*" /> + <tbody valign="top"> + <row> + <entry>start + 0:</entry> + <entry>B<subscript>00</subscript></entry> + <entry>G<subscript>00</subscript></entry> + <entry>R<subscript>00</subscript></entry> + <entry>B<subscript>01</subscript></entry> + <entry>G<subscript>01</subscript></entry> + <entry>R<subscript>01</subscript></entry> + <entry>B<subscript>02</subscript></entry> + <entry>G<subscript>02</subscript></entry> + <entry>R<subscript>02</subscript></entry> + <entry>B<subscript>03</subscript></entry> + <entry>G<subscript>03</subscript></entry> + <entry>R<subscript>03</subscript></entry> + </row> + <row> + <entry>start + 12:</entry> + <entry>B<subscript>10</subscript></entry> + <entry>G<subscript>10</subscript></entry> + <entry>R<subscript>10</subscript></entry> + <entry>B<subscript>11</subscript></entry> + <entry>G<subscript>11</subscript></entry> + <entry>R<subscript>11</subscript></entry> + <entry>B<subscript>12</subscript></entry> + <entry>G<subscript>12</subscript></entry> + <entry>R<subscript>12</subscript></entry> + <entry>B<subscript>13</subscript></entry> + <entry>G<subscript>13</subscript></entry> + <entry>R<subscript>13</subscript></entry> + </row> + <row> + <entry>start + 24:</entry> + <entry>B<subscript>20</subscript></entry> + <entry>G<subscript>20</subscript></entry> + <entry>R<subscript>20</subscript></entry> + <entry>B<subscript>21</subscript></entry> + <entry>G<subscript>21</subscript></entry> + <entry>R<subscript>21</subscript></entry> + <entry>B<subscript>22</subscript></entry> + <entry>G<subscript>22</subscript></entry> + <entry>R<subscript>22</subscript></entry> + <entry>B<subscript>23</subscript></entry> + <entry>G<subscript>23</subscript></entry> + <entry>R<subscript>23</subscript></entry> + </row> + <row> + <entry>start + 36:</entry> + <entry>B<subscript>30</subscript></entry> + <entry>G<subscript>30</subscript></entry> + <entry>R<subscript>30</subscript></entry> + <entry>B<subscript>31</subscript></entry> + <entry>G<subscript>31</subscript></entry> + <entry>R<subscript>31</subscript></entry> + <entry>B<subscript>32</subscript></entry> + <entry>G<subscript>32</subscript></entry> + <entry>R<subscript>32</subscript></entry> + <entry>B<subscript>33</subscript></entry> + <entry>G<subscript>33</subscript></entry> + <entry>R<subscript>33</subscript></entry> + </row> + </tbody> + </tgroup> + </informaltable> + </para> + </formalpara> + </example> + + <important> + <para>Drivers may interpret these formats differently.</para> + </important> + + <para>Some RGB formats above are uncommon and were probably +defined in error. Drivers may interpret them as in <xref + linkend="rgb-formats-corrected" />.</para> + + <table pgwide="1" frame="none" id="rgb-formats-corrected"> + <title>Packed RGB Image Formats (corrected)</title> + <tgroup cols="37" align="center"> + <colspec colname="id" align="left" /> + <colspec colname="fourcc" /> + <colspec colname="bit" /> + + <colspec colnum="4" colname="b07" align="center" /> + <colspec colnum="5" colname="b06" align="center" /> + <colspec colnum="6" colname="b05" align="center" /> + <colspec colnum="7" colname="b04" align="center" /> + <colspec colnum="8" colname="b03" align="center" /> + <colspec colnum="9" colname="b02" align="center" /> + <colspec colnum="10" colname="b01" align="center" /> + <colspec colnum="11" colname="b00" align="center" /> + + <colspec colnum="13" colname="b17" align="center" /> + <colspec colnum="14" colname="b16" align="center" /> + <colspec colnum="15" colname="b15" align="center" /> + <colspec colnum="16" colname="b14" align="center" /> + <colspec colnum="17" colname="b13" align="center" /> + <colspec colnum="18" colname="b12" align="center" /> + <colspec colnum="19" colname="b11" align="center" /> + <colspec colnum="20" colname="b10" align="center" /> + + <colspec colnum="22" colname="b27" align="center" /> + <colspec colnum="23" colname="b26" align="center" /> + <colspec colnum="24" colname="b25" align="center" /> + <colspec colnum="25" colname="b24" align="center" /> + <colspec colnum="26" colname="b23" align="center" /> + <colspec colnum="27" colname="b22" align="center" /> + <colspec colnum="28" colname="b21" align="center" /> + <colspec colnum="29" colname="b20" align="center" /> + + <colspec colnum="31" colname="b37" align="center" /> + <colspec colnum="32" colname="b36" align="center" /> + <colspec colnum="33" colname="b35" align="center" /> + <colspec colnum="34" colname="b34" align="center" /> + <colspec colnum="35" colname="b33" align="center" /> + <colspec colnum="36" colname="b32" align="center" /> + <colspec colnum="37" colname="b31" align="center" /> + <colspec colnum="38" colname="b30" align="center" /> + + <spanspec namest="b07" nameend="b00" spanname="b0" /> + <spanspec namest="b17" nameend="b10" spanname="b1" /> + <spanspec namest="b27" nameend="b20" spanname="b2" /> + <spanspec namest="b37" nameend="b30" spanname="b3" /> + <thead> + <row> + <entry>Identifier</entry> + <entry>Code</entry> + <entry> </entry> + <entry spanname="b0">Byte 0 in memory</entry> + <entry spanname="b1">Byte 1</entry> + <entry spanname="b2">Byte 2</entry> + <entry spanname="b3">Byte 3</entry> + </row> + <row> + <entry> </entry> + <entry> </entry> + <entry>Bit</entry> + <entry>7</entry> + <entry>6</entry> + <entry>5</entry> + <entry>4</entry> + <entry>3</entry> + <entry>2</entry> + <entry>1</entry> + <entry>0</entry> + <entry> </entry> + <entry>7</entry> + <entry>6</entry> + <entry>5</entry> + <entry>4</entry> + <entry>3</entry> + <entry>2</entry> + <entry>1</entry> + <entry>0</entry> + <entry> </entry> + <entry>7</entry> + <entry>6</entry> + <entry>5</entry> + <entry>4</entry> + <entry>3</entry> + <entry>2</entry> + <entry>1</entry> + <entry>0</entry> + <entry> </entry> + <entry>7</entry> + <entry>6</entry> + <entry>5</entry> + <entry>4</entry> + <entry>3</entry> + <entry>2</entry> + <entry>1</entry> + <entry>0</entry> + </row> + </thead> + <tbody valign="top"> + <row><!-- id="V4L2-PIX-FMT-RGB332" --> + <entry><constant>V4L2_PIX_FMT_RGB332</constant></entry> + <entry>'RGB1'</entry> + <entry></entry> + <entry>r<subscript>2</subscript></entry> + <entry>r<subscript>1</subscript></entry> + <entry>r<subscript>0</subscript></entry> + <entry>g<subscript>2</subscript></entry> + <entry>g<subscript>1</subscript></entry> + <entry>g<subscript>0</subscript></entry> + <entry>b<subscript>1</subscript></entry> + <entry>b<subscript>0</subscript></entry> + </row> + <row><!-- id="V4L2-PIX-FMT-RGB444" --> + <entry><constant>V4L2_PIX_FMT_RGB444</constant></entry> + <entry>'R444'</entry> + <entry></entry> + <entry>g<subscript>3</subscript></entry> + <entry>g<subscript>2</subscript></entry> + <entry>g<subscript>1</subscript></entry> + <entry>g<subscript>0</subscript></entry> + <entry>b<subscript>3</subscript></entry> + <entry>b<subscript>2</subscript></entry> + <entry>b<subscript>1</subscript></entry> + <entry>b<subscript>0</subscript></entry> + <entry></entry> + <entry>a<subscript>3</subscript></entry> + <entry>a<subscript>2</subscript></entry> + <entry>a<subscript>1</subscript></entry> + <entry>a<subscript>0</subscript></entry> + <entry>r<subscript>3</subscript></entry> + <entry>r<subscript>2</subscript></entry> + <entry>r<subscript>1</subscript></entry> + <entry>r<subscript>0</subscript></entry> + </row> + <row><!-- id="V4L2-PIX-FMT-RGB555" --> + <entry><constant>V4L2_PIX_FMT_RGB555</constant></entry> + <entry>'RGBO'</entry> + <entry></entry> + <entry>g<subscript>2</subscript></entry> + <entry>g<subscript>1</subscript></entry> + <entry>g<subscript>0</subscript></entry> + <entry>b<subscript>4</subscript></entry> + <entry>b<subscript>3</subscript></entry> + <entry>b<subscript>2</subscript></entry> + <entry>b<subscript>1</subscript></entry> + <entry>b<subscript>0</subscript></entry> + <entry></entry> + <entry>a</entry> + <entry>r<subscript>4</subscript></entry> + <entry>r<subscript>3</subscript></entry> + <entry>r<subscript>2</subscript></entry> + <entry>r<subscript>1</subscript></entry> + <entry>r<subscript>0</subscript></entry> + <entry>g<subscript>4</subscript></entry> + <entry>g<subscript>3</subscript></entry> + </row> + <row><!-- id="V4L2-PIX-FMT-RGB565" --> + <entry><constant>V4L2_PIX_FMT_RGB565</constant></entry> + <entry>'RGBP'</entry> + <entry></entry> + <entry>g<subscript>2</subscript></entry> + <entry>g<subscript>1</subscript></entry> + <entry>g<subscript>0</subscript></entry> + <entry>b<subscript>4</subscript></entry> + <entry>b<subscript>3</subscript></entry> + <entry>b<subscript>2</subscript></entry> + <entry>b<subscript>1</subscript></entry> + <entry>b<subscript>0</subscript></entry> + <entry></entry> + <entry>r<subscript>4</subscript></entry> + <entry>r<subscript>3</subscript></entry> + <entry>r<subscript>2</subscript></entry> + <entry>r<subscript>1</subscript></entry> + <entry>r<subscript>0</subscript></entry> + <entry>g<subscript>5</subscript></entry> + <entry>g<subscript>4</subscript></entry> + <entry>g<subscript>3</subscript></entry> + </row> + <row><!-- id="V4L2-PIX-FMT-RGB555X" --> + <entry><constant>V4L2_PIX_FMT_RGB555X</constant></entry> + <entry>'RGBQ'</entry> + <entry></entry> + <entry>a</entry> + <entry>r<subscript>4</subscript></entry> + <entry>r<subscript>3</subscript></entry> + <entry>r<subscript>2</subscript></entry> + <entry>r<subscript>1</subscript></entry> + <entry>r<subscript>0</subscript></entry> + <entry>g<subscript>4</subscript></entry> + <entry>g<subscript>3</subscript></entry> + <entry></entry> + <entry>g<subscript>2</subscript></entry> + <entry>g<subscript>1</subscript></entry> + <entry>g<subscript>0</subscript></entry> + <entry>b<subscript>4</subscript></entry> + <entry>b<subscript>3</subscript></entry> + <entry>b<subscript>2</subscript></entry> + <entry>b<subscript>1</subscript></entry> + <entry>b<subscript>0</subscript></entry> + </row> + <row><!-- id="V4L2-PIX-FMT-RGB565X" --> + <entry><constant>V4L2_PIX_FMT_RGB565X</constant></entry> + <entry>'RGBR'</entry> + <entry></entry> + <entry>r<subscript>4</subscript></entry> + <entry>r<subscript>3</subscript></entry> + <entry>r<subscript>2</subscript></entry> + <entry>r<subscript>1</subscript></entry> + <entry>r<subscript>0</subscript></entry> + <entry>g<subscript>5</subscript></entry> + <entry>g<subscript>4</subscript></entry> + <entry>g<subscript>3</subscript></entry> + <entry></entry> + <entry>g<subscript>2</subscript></entry> + <entry>g<subscript>1</subscript></entry> + <entry>g<subscript>0</subscript></entry> + <entry>b<subscript>4</subscript></entry> + <entry>b<subscript>3</subscript></entry> + <entry>b<subscript>2</subscript></entry> + <entry>b<subscript>1</subscript></entry> + <entry>b<subscript>0</subscript></entry> + </row> + <row><!-- id="V4L2-PIX-FMT-BGR24" --> + <entry><constant>V4L2_PIX_FMT_BGR24</constant></entry> + <entry>'BGR3'</entry> + <entry></entry> + <entry>b<subscript>7</subscript></entry> + <entry>b<subscript>6</subscript></entry> + <entry>b<subscript>5</subscript></entry> + <entry>b<subscript>4</subscript></entry> + <entry>b<subscript>3</subscript></entry> + <entry>b<subscript>2</subscript></entry> + <entry>b<subscript>1</subscript></entry> + <entry>b<subscript>0</subscript></entry> + <entry></entry> + <entry>g<subscript>7</subscript></entry> + <entry>g<subscript>6</subscript></entry> + <entry>g<subscript>5</subscript></entry> + <entry>g<subscript>4</subscript></entry> + <entry>g<subscript>3</subscript></entry> + <entry>g<subscript>2</subscript></entry> + <entry>g<subscript>1</subscript></entry> + <entry>g<subscript>0</subscript></entry> + <entry></entry> + <entry>r<subscript>7</subscript></entry> + <entry>r<subscript>6</subscript></entry> + <entry>r<subscript>5</subscript></entry> + <entry>r<subscript>4</subscript></entry> + <entry>r<subscript>3</subscript></entry> + <entry>r<subscript>2</subscript></entry> + <entry>r<subscript>1</subscript></entry> + <entry>r<subscript>0</subscript></entry> + </row> + <row><!-- id="V4L2-PIX-FMT-RGB24" --> + <entry><constant>V4L2_PIX_FMT_RGB24</constant></entry> + <entry>'RGB3'</entry> + <entry></entry> + <entry>r<subscript>7</subscript></entry> + <entry>r<subscript>6</subscript></entry> + <entry>r<subscript>5</subscript></entry> + <entry>r<subscript>4</subscript></entry> + <entry>r<subscript>3</subscript></entry> + <entry>r<subscript>2</subscript></entry> + <entry>r<subscript>1</subscript></entry> + <entry>r<subscript>0</subscript></entry> + <entry></entry> + <entry>g<subscript>7</subscript></entry> + <entry>g<subscript>6</subscript></entry> + <entry>g<subscript>5</subscript></entry> + <entry>g<subscript>4</subscript></entry> + <entry>g<subscript>3</subscript></entry> + <entry>g<subscript>2</subscript></entry> + <entry>g<subscript>1</subscript></entry> + <entry>g<subscript>0</subscript></entry> + <entry></entry> + <entry>b<subscript>7</subscript></entry> + <entry>b<subscript>6</subscript></entry> + <entry>b<subscript>5</subscript></entry> + <entry>b<subscript>4</subscript></entry> + <entry>b<subscript>3</subscript></entry> + <entry>b<subscript>2</subscript></entry> + <entry>b<subscript>1</subscript></entry> + <entry>b<subscript>0</subscript></entry> + </row> + <row><!-- id="V4L2-PIX-FMT-BGR32" --> + <entry><constant>V4L2_PIX_FMT_BGR32</constant></entry> + <entry>'BGR4'</entry> + <entry></entry> + <entry>b<subscript>7</subscript></entry> + <entry>b<subscript>6</subscript></entry> + <entry>b<subscript>5</subscript></entry> + <entry>b<subscript>4</subscript></entry> + <entry>b<subscript>3</subscript></entry> + <entry>b<subscript>2</subscript></entry> + <entry>b<subscript>1</subscript></entry> + <entry>b<subscript>0</subscript></entry> + <entry></entry> + <entry>g<subscript>7</subscript></entry> + <entry>g<subscript>6</subscript></entry> + <entry>g<subscript>5</subscript></entry> + <entry>g<subscript>4</subscript></entry> + <entry>g<subscript>3</subscript></entry> + <entry>g<subscript>2</subscript></entry> + <entry>g<subscript>1</subscript></entry> + <entry>g<subscript>0</subscript></entry> + <entry></entry> + <entry>r<subscript>7</subscript></entry> + <entry>r<subscript>6</subscript></entry> + <entry>r<subscript>5</subscript></entry> + <entry>r<subscript>4</subscript></entry> + <entry>r<subscript>3</subscript></entry> + <entry>r<subscript>2</subscript></entry> + <entry>r<subscript>1</subscript></entry> + <entry>r<subscript>0</subscript></entry> + <entry></entry> + <entry>a<subscript>7</subscript></entry> + <entry>a<subscript>6</subscript></entry> + <entry>a<subscript>5</subscript></entry> + <entry>a<subscript>4</subscript></entry> + <entry>a<subscript>3</subscript></entry> + <entry>a<subscript>2</subscript></entry> + <entry>a<subscript>1</subscript></entry> + <entry>a<subscript>0</subscript></entry> + </row> + <row><!-- id="V4L2-PIX-FMT-RGB32" --> + <entry><constant>V4L2_PIX_FMT_RGB32</constant></entry> + <entry>'RGB4'</entry> + <entry></entry> + <entry>a<subscript>7</subscript></entry> + <entry>a<subscript>6</subscript></entry> + <entry>a<subscript>5</subscript></entry> + <entry>a<subscript>4</subscript></entry> + <entry>a<subscript>3</subscript></entry> + <entry>a<subscript>2</subscript></entry> + <entry>a<subscript>1</subscript></entry> + <entry>a<subscript>0</subscript></entry> + <entry></entry> + <entry>r<subscript>7</subscript></entry> + <entry>r<subscript>6</subscript></entry> + <entry>r<subscript>5</subscript></entry> + <entry>r<subscript>4</subscript></entry> + <entry>r<subscript>3</subscript></entry> + <entry>r<subscript>2</subscript></entry> + <entry>r<subscript>1</subscript></entry> + <entry>r<subscript>0</subscript></entry> + <entry></entry> + <entry>g<subscript>7</subscript></entry> + <entry>g<subscript>6</subscript></entry> + <entry>g<subscript>5</subscript></entry> + <entry>g<subscript>4</subscript></entry> + <entry>g<subscript>3</subscript></entry> + <entry>g<subscript>2</subscript></entry> + <entry>g<subscript>1</subscript></entry> + <entry>g<subscript>0</subscript></entry> + <entry></entry> + <entry>b<subscript>7</subscript></entry> + <entry>b<subscript>6</subscript></entry> + <entry>b<subscript>5</subscript></entry> + <entry>b<subscript>4</subscript></entry> + <entry>b<subscript>3</subscript></entry> + <entry>b<subscript>2</subscript></entry> + <entry>b<subscript>1</subscript></entry> + <entry>b<subscript>0</subscript></entry> + </row> + </tbody> + </tgroup> + </table> + + <para>A test utility to determine which RGB formats a driver +actually supports is available from the LinuxTV v4l-dvb repository. +See &v4l-dvb; for access instructions.</para> + + </refsect1> + </refentry> + + <!-- +Local Variables: +mode: sgml +sgml-parent-document: "pixfmt.sgml" +indent-tabs-mode: nil +End: + --> diff --git a/Documentation/DocBook/v4l/pixfmt-packed-yuv.xml b/Documentation/DocBook/v4l/pixfmt-packed-yuv.xml new file mode 100644 index 000000000000..3cab5d0ca75d --- /dev/null +++ b/Documentation/DocBook/v4l/pixfmt-packed-yuv.xml @@ -0,0 +1,244 @@ +<refentry id="packed-yuv"> + <refmeta> + <refentrytitle>Packed YUV formats</refentrytitle> + &manvol; + </refmeta> + <refnamediv> + <refname>Packed YUV formats</refname> + <refpurpose>Packed YUV formats</refpurpose> + </refnamediv> + <refsect1> + <title>Description</title> + + <para>Similar to the packed RGB formats these formats store +the Y, Cb and Cr component of each pixel in one 16 or 32 bit +word.</para> + + <table pgwide="1" frame="none"> + <title>Packed YUV Image Formats</title> + <tgroup cols="37" align="center"> + <colspec colname="id" align="left" /> + <colspec colname="fourcc" /> + <colspec colname="bit" /> + + <colspec colnum="4" colname="b07" align="center" /> + <colspec colnum="5" colname="b06" align="center" /> + <colspec colnum="6" colname="b05" align="center" /> + <colspec colnum="7" colname="b04" align="center" /> + <colspec colnum="8" colname="b03" align="center" /> + <colspec colnum="9" colname="b02" align="center" /> + <colspec colnum="10" colname="b01" align="center" /> + <colspec colnum="11" colname="b00" align="center" /> + + <colspec colnum="13" colname="b17" align="center" /> + <colspec colnum="14" colname="b16" align="center" /> + <colspec colnum="15" colname="b15" align="center" /> + <colspec colnum="16" colname="b14" align="center" /> + <colspec colnum="17" colname="b13" align="center" /> + <colspec colnum="18" colname="b12" align="center" /> + <colspec colnum="19" colname="b11" align="center" /> + <colspec colnum="20" colname="b10" align="center" /> + + <colspec colnum="22" colname="b27" align="center" /> + <colspec colnum="23" colname="b26" align="center" /> + <colspec colnum="24" colname="b25" align="center" /> + <colspec colnum="25" colname="b24" align="center" /> + <colspec colnum="26" colname="b23" align="center" /> + <colspec colnum="27" colname="b22" align="center" /> + <colspec colnum="28" colname="b21" align="center" /> + <colspec colnum="29" colname="b20" align="center" /> + + <colspec colnum="31" colname="b37" align="center" /> + <colspec colnum="32" colname="b36" align="center" /> + <colspec colnum="33" colname="b35" align="center" /> + <colspec colnum="34" colname="b34" align="center" /> + <colspec colnum="35" colname="b33" align="center" /> + <colspec colnum="36" colname="b32" align="center" /> + <colspec colnum="37" colname="b31" align="center" /> + <colspec colnum="38" colname="b30" align="center" /> + + <spanspec namest="b07" nameend="b00" spanname="b0" /> + <spanspec namest="b17" nameend="b10" spanname="b1" /> + <spanspec namest="b27" nameend="b20" spanname="b2" /> + <spanspec namest="b37" nameend="b30" spanname="b3" /> + <thead> + <row> + <entry>Identifier</entry> + <entry>Code</entry> + <entry> </entry> + <entry spanname="b0">Byte 0 in memory</entry> + <entry spanname="b1">Byte 1</entry> + <entry spanname="b2">Byte 2</entry> + <entry spanname="b3">Byte 3</entry> + </row> + <row> + <entry> </entry> + <entry> </entry> + <entry>Bit</entry> + <entry>7</entry> + <entry>6</entry> + <entry>5</entry> + <entry>4</entry> + <entry>3</entry> + <entry>2</entry> + <entry>1</entry> + <entry>0</entry> + <entry> </entry> + <entry>7</entry> + <entry>6</entry> + <entry>5</entry> + <entry>4</entry> + <entry>3</entry> + <entry>2</entry> + <entry>1</entry> + <entry>0</entry> + <entry> </entry> + <entry>7</entry> + <entry>6</entry> + <entry>5</entry> + <entry>4</entry> + <entry>3</entry> + <entry>2</entry> + <entry>1</entry> + <entry>0</entry> + <entry> </entry> + <entry>7</entry> + <entry>6</entry> + <entry>5</entry> + <entry>4</entry> + <entry>3</entry> + <entry>2</entry> + <entry>1</entry> + <entry>0</entry> + </row> + </thead> + <tbody valign="top"> + <row id="V4L2-PIX-FMT-YUV444"> + <entry><constant>V4L2_PIX_FMT_YUV444</constant></entry> + <entry>'Y444'</entry> + <entry></entry> + <entry>Cb<subscript>3</subscript></entry> + <entry>Cb<subscript>2</subscript></entry> + <entry>Cb<subscript>1</subscript></entry> + <entry>Cb<subscript>0</subscript></entry> + <entry>Cr<subscript>3</subscript></entry> + <entry>Cr<subscript>2</subscript></entry> + <entry>Cr<subscript>1</subscript></entry> + <entry>Cr<subscript>0</subscript></entry> + <entry></entry> + <entry>a<subscript>3</subscript></entry> + <entry>a<subscript>2</subscript></entry> + <entry>a<subscript>1</subscript></entry> + <entry>a<subscript>0</subscript></entry> + <entry>Y'<subscript>3</subscript></entry> + <entry>Y'<subscript>2</subscript></entry> + <entry>Y'<subscript>1</subscript></entry> + <entry>Y'<subscript>0</subscript></entry> + </row> + + <row id="V4L2-PIX-FMT-YUV555"> + <entry><constant>V4L2_PIX_FMT_YUV555</constant></entry> + <entry>'YUVO'</entry> + <entry></entry> + <entry>Cb<subscript>2</subscript></entry> + <entry>Cb<subscript>1</subscript></entry> + <entry>Cb<subscript>0</subscript></entry> + <entry>Cr<subscript>4</subscript></entry> + <entry>Cr<subscript>3</subscript></entry> + <entry>Cr<subscript>2</subscript></entry> + <entry>Cr<subscript>1</subscript></entry> + <entry>Cr<subscript>0</subscript></entry> + <entry></entry> + <entry>a</entry> + <entry>Y'<subscript>4</subscript></entry> + <entry>Y'<subscript>3</subscript></entry> + <entry>Y'<subscript>2</subscript></entry> + <entry>Y'<subscript>1</subscript></entry> + <entry>Y'<subscript>0</subscript></entry> + <entry>Cb<subscript>4</subscript></entry> + <entry>Cb<subscript>3</subscript></entry> + </row> + + <row id="V4L2-PIX-FMT-YUV565"> + <entry><constant>V4L2_PIX_FMT_YUV565</constant></entry> + <entry>'YUVP'</entry> + <entry></entry> + <entry>Cb<subscript>2</subscript></entry> + <entry>Cb<subscript>1</subscript></entry> + <entry>Cb<subscript>0</subscript></entry> + <entry>Cr<subscript>4</subscript></entry> + <entry>Cr<subscript>3</subscript></entry> + <entry>Cr<subscript>2</subscript></entry> + <entry>Cr<subscript>1</subscript></entry> + <entry>Cr<subscript>0</subscript></entry> + <entry></entry> + <entry>Y'<subscript>4</subscript></entry> + <entry>Y'<subscript>3</subscript></entry> + <entry>Y'<subscript>2</subscript></entry> + <entry>Y'<subscript>1</subscript></entry> + <entry>Y'<subscript>0</subscript></entry> + <entry>Cb<subscript>5</subscript></entry> + <entry>Cb<subscript>4</subscript></entry> + <entry>Cb<subscript>3</subscript></entry> + </row> + + <row id="V4L2-PIX-FMT-YUV32"> + <entry><constant>V4L2_PIX_FMT_YUV32</constant></entry> + <entry>'YUV4'</entry> + <entry></entry> + <entry>a<subscript>7</subscript></entry> + <entry>a<subscript>6</subscript></entry> + <entry>a<subscript>5</subscript></entry> + <entry>a<subscript>4</subscript></entry> + <entry>a<subscript>3</subscript></entry> + <entry>a<subscript>2</subscript></entry> + <entry>a<subscript>1</subscript></entry> + <entry>a<subscript>0</subscript></entry> + <entry></entry> + <entry>Y'<subscript>7</subscript></entry> + <entry>Y'<subscript>6</subscript></entry> + <entry>Y'<subscript>5</subscript></entry> + <entry>Y'<subscript>4</subscript></entry> + <entry>Y'<subscript>3</subscript></entry> + <entry>Y'<subscript>2</subscript></entry> + <entry>Y'<subscript>1</subscript></entry> + <entry>Y'<subscript>0</subscript></entry> + <entry></entry> + <entry>Cb<subscript>7</subscript></entry> + <entry>Cb<subscript>6</subscript></entry> + <entry>Cb<subscript>5</subscript></entry> + <entry>Cb<subscript>4</subscript></entry> + <entry>Cb<subscript>3</subscript></entry> + <entry>Cb<subscript>2</subscript></entry> + <entry>Cb<subscript>1</subscript></entry> + <entry>Cb<subscript>0</subscript></entry> + <entry></entry> + <entry>Cr<subscript>7</subscript></entry> + <entry>Cr<subscript>6</subscript></entry> + <entry>Cr<subscript>5</subscript></entry> + <entry>Cr<subscript>4</subscript></entry> + <entry>Cr<subscript>3</subscript></entry> + <entry>Cr<subscript>2</subscript></entry> + <entry>Cr<subscript>1</subscript></entry> + <entry>Cr<subscript>0</subscript></entry> + </row> + </tbody> + </tgroup> + </table> + + <para>Bit 7 is the most significant bit. The value of a = alpha +bits is undefined when reading from the driver, ignored when writing +to the driver, except when alpha blending has been negotiated for a +<link linkend="overlay">Video Overlay</link> or <link +linkend="osd">Video Output Overlay</link>.</para> + + </refsect1> + </refentry> + + <!-- +Local Variables: +mode: sgml +sgml-parent-document: "pixfmt.sgml" +indent-tabs-mode: nil +End: + --> diff --git a/Documentation/DocBook/v4l/pixfmt-sbggr16.xml b/Documentation/DocBook/v4l/pixfmt-sbggr16.xml new file mode 100644 index 000000000000..519a9efbac10 --- /dev/null +++ b/Documentation/DocBook/v4l/pixfmt-sbggr16.xml @@ -0,0 +1,91 @@ +<refentry id="V4L2-PIX-FMT-SBGGR16"> + <refmeta> + <refentrytitle>V4L2_PIX_FMT_SBGGR16 ('BYR2')</refentrytitle> + &manvol; + </refmeta> + <refnamediv> + <refname><constant>V4L2_PIX_FMT_SBGGR16</constant></refname> + <refpurpose>Bayer RGB format</refpurpose> + </refnamediv> + <refsect1> + <title>Description</title> + + <para>This format is similar to <link +linkend="V4L2-PIX-FMT-SBGGR8"> +<constant>V4L2_PIX_FMT_SBGGR8</constant></link>, except each pixel has +a depth of 16 bits. The least significant byte is stored at lower +memory addresses (little-endian). Note the actual sampling precision +may be lower than 16 bits, for example 10 bits per pixel with values +in range 0 to 1023.</para> + + <example> + <title><constant>V4L2_PIX_FMT_SBGGR16</constant> 4 × 4 +pixel image</title> + + <formalpara> + <title>Byte Order.</title> + <para>Each cell is one byte. + <informaltable frame="none"> + <tgroup cols="5" align="center"> + <colspec align="left" colwidth="2*" /> + <tbody valign="top"> + <row> + <entry>start + 0:</entry> + <entry>B<subscript>00low</subscript></entry> + <entry>B<subscript>00high</subscript></entry> + <entry>G<subscript>01low</subscript></entry> + <entry>G<subscript>01high</subscript></entry> + <entry>B<subscript>02low</subscript></entry> + <entry>B<subscript>02high</subscript></entry> + <entry>G<subscript>03low</subscript></entry> + <entry>G<subscript>03high</subscript></entry> + </row> + <row> + <entry>start + 8:</entry> + <entry>G<subscript>10low</subscript></entry> + <entry>G<subscript>10high</subscript></entry> + <entry>R<subscript>11low</subscript></entry> + <entry>R<subscript>11high</subscript></entry> + <entry>G<subscript>12low</subscript></entry> + <entry>G<subscript>12high</subscript></entry> + <entry>R<subscript>13low</subscript></entry> + <entry>R<subscript>13high</subscript></entry> + </row> + <row> + <entry>start + 16:</entry> + <entry>B<subscript>20low</subscript></entry> + <entry>B<subscript>20high</subscript></entry> + <entry>G<subscript>21low</subscript></entry> + <entry>G<subscript>21high</subscript></entry> + <entry>B<subscript>22low</subscript></entry> + <entry>B<subscript>22high</subscript></entry> + <entry>G<subscript>23low</subscript></entry> + <entry>G<subscript>23high</subscript></entry> + </row> + <row> + <entry>start + 24:</entry> + <entry>G<subscript>30low</subscript></entry> + <entry>G<subscript>30high</subscript></entry> + <entry>R<subscript>31low</subscript></entry> + <entry>R<subscript>31high</subscript></entry> + <entry>G<subscript>32low</subscript></entry> + <entry>G<subscript>32high</subscript></entry> + <entry>R<subscript>33low</subscript></entry> + <entry>R<subscript>33high</subscript></entry> + </row> + </tbody> + </tgroup> + </informaltable> + </para> + </formalpara> + </example> + </refsect1> +</refentry> + + <!-- +Local Variables: +mode: sgml +sgml-parent-document: "pixfmt.sgml" +indent-tabs-mode: nil +End: + --> diff --git a/Documentation/DocBook/v4l/pixfmt-sbggr8.xml b/Documentation/DocBook/v4l/pixfmt-sbggr8.xml new file mode 100644 index 000000000000..5fe84ecc2ebe --- /dev/null +++ b/Documentation/DocBook/v4l/pixfmt-sbggr8.xml @@ -0,0 +1,75 @@ + <refentry id="V4L2-PIX-FMT-SBGGR8"> + <refmeta> + <refentrytitle>V4L2_PIX_FMT_SBGGR8 ('BA81')</refentrytitle> + &manvol; + </refmeta> + <refnamediv> + <refname><constant>V4L2_PIX_FMT_SBGGR8</constant></refname> + <refpurpose>Bayer RGB format</refpurpose> + </refnamediv> + <refsect1> + <title>Description</title> + + <para>This is commonly the native format of digital cameras, +reflecting the arrangement of sensors on the CCD device. Only one red, +green or blue value is given for each pixel. Missing components must +be interpolated from neighbouring pixels. From left to right the first +row consists of a blue and green value, the second row of a green and +red value. This scheme repeats to the right and down for every two +columns and rows.</para> + + <example> + <title><constant>V4L2_PIX_FMT_SBGGR8</constant> 4 × 4 +pixel image</title> + + <formalpara> + <title>Byte Order.</title> + <para>Each cell is one byte. + <informaltable frame="none"> + <tgroup cols="5" align="center"> + <colspec align="left" colwidth="2*" /> + <tbody valign="top"> + <row> + <entry>start + 0:</entry> + <entry>B<subscript>00</subscript></entry> + <entry>G<subscript>01</subscript></entry> + <entry>B<subscript>02</subscript></entry> + <entry>G<subscript>03</subscript></entry> + </row> + <row> + <entry>start + 4:</entry> + <entry>G<subscript>10</subscript></entry> + <entry>R<subscript>11</subscript></entry> + <entry>G<subscript>12</subscript></entry> + <entry>R<subscript>13</subscript></entry> + </row> + <row> + <entry>start + 8:</entry> + <entry>B<subscript>20</subscript></entry> + <entry>G<subscript>21</subscript></entry> + <entry>B<subscript>22</subscript></entry> + <entry>G<subscript>23</subscript></entry> + </row> + <row> + <entry>start + 12:</entry> + <entry>G<subscript>30</subscript></entry> + <entry>R<subscript>31</subscript></entry> + <entry>G<subscript>32</subscript></entry> + <entry>R<subscript>33</subscript></entry> + </row> + </tbody> + </tgroup> + </informaltable> + </para> + </formalpara> + </example> + </refsect1> + </refentry> + + <!-- +Local Variables: +mode: sgml +sgml-parent-document: "pixfmt.sgml" +indent-tabs-mode: nil +End: + --> diff --git a/Documentation/DocBook/v4l/pixfmt-sgbrg8.xml b/Documentation/DocBook/v4l/pixfmt-sgbrg8.xml new file mode 100644 index 000000000000..d67a472b0880 --- /dev/null +++ b/Documentation/DocBook/v4l/pixfmt-sgbrg8.xml @@ -0,0 +1,75 @@ + <refentry id="V4L2-PIX-FMT-SGBRG8"> + <refmeta> + <refentrytitle>V4L2_PIX_FMT_SGBRG8 ('GBRG')</refentrytitle> + &manvol; + </refmeta> + <refnamediv> + <refname><constant>V4L2_PIX_FMT_SGBRG8</constant></refname> + <refpurpose>Bayer RGB format</refpurpose> + </refnamediv> + <refsect1> + <title>Description</title> + + <para>This is commonly the native format of digital cameras, +reflecting the arrangement of sensors on the CCD device. Only one red, +green or blue value is given for each pixel. Missing components must +be interpolated from neighbouring pixels. From left to right the first +row consists of a green and blue value, the second row of a red and +green value. This scheme repeats to the right and down for every two +columns and rows.</para> + + <example> + <title><constant>V4L2_PIX_FMT_SGBRG8</constant> 4 × 4 +pixel image</title> + + <formalpara> + <title>Byte Order.</title> + <para>Each cell is one byte. + <informaltable frame="none"> + <tgroup cols="5" align="center"> + <colspec align="left" colwidth="2*" /> + <tbody valign="top"> + <row> + <entry>start + 0:</entry> + <entry>G<subscript>00</subscript></entry> + <entry>B<subscript>01</subscript></entry> + <entry>G<subscript>02</subscript></entry> + <entry>B<subscript>03</subscript></entry> + </row> + <row> + <entry>start + 4:</entry> + <entry>R<subscript>10</subscript></entry> + <entry>G<subscript>11</subscript></entry> + <entry>R<subscript>12</subscript></entry> + <entry>G<subscript>13</subscript></entry> + </row> + <row> + <entry>start + 8:</entry> + <entry>G<subscript>20</subscript></entry> + <entry>B<subscript>21</subscript></entry> + <entry>G<subscript>22</subscript></entry> + <entry>B<subscript>23</subscript></entry> + </row> + <row> + <entry>start + 12:</entry> + <entry>R<subscript>30</subscript></entry> + <entry>G<subscript>31</subscript></entry> + <entry>R<subscript>32</subscript></entry> + <entry>G<subscript>33</subscript></entry> + </row> + </tbody> + </tgroup> + </informaltable> + </para> + </formalpara> + </example> + </refsect1> + </refentry> + + <!-- +Local Variables: +mode: sgml +sgml-parent-document: "pixfmt.sgml" +indent-tabs-mode: nil +End: + --> diff --git a/Documentation/DocBook/v4l/pixfmt-sgrbg8.xml b/Documentation/DocBook/v4l/pixfmt-sgrbg8.xml new file mode 100644 index 000000000000..0cdf13b8ac1c --- /dev/null +++ b/Documentation/DocBook/v4l/pixfmt-sgrbg8.xml @@ -0,0 +1,75 @@ + <refentry id="V4L2-PIX-FMT-SGRBG8"> + <refmeta> + <refentrytitle>V4L2_PIX_FMT_SGRBG8 ('GRBG')</refentrytitle> + &manvol; + </refmeta> + <refnamediv> + <refname><constant>V4L2_PIX_FMT_SGRBG8</constant></refname> + <refpurpose>Bayer RGB format</refpurpose> + </refnamediv> + <refsect1> + <title>Description</title> + + <para>This is commonly the native format of digital cameras, +reflecting the arrangement of sensors on the CCD device. Only one red, +green or blue value is given for each pixel. Missing components must +be interpolated from neighbouring pixels. From left to right the first +row consists of a green and blue value, the second row of a red and +green value. This scheme repeats to the right and down for every two +columns and rows.</para> + + <example> + <title><constant>V4L2_PIX_FMT_SGRBG8</constant> 4 × +4 pixel image</title> + + <formalpara> + <title>Byte Order.</title> + <para>Each cell is one byte. + <informaltable frame="none"> + <tgroup cols="5" align="center"> + <colspec align="left" colwidth="2*" /> + <tbody valign="top"> + <row> + <entry>start + 0:</entry> + <entry>G<subscript>00</subscript></entry> + <entry>R<subscript>01</subscript></entry> + <entry>G<subscript>02</subscript></entry> + <entry>R<subscript>03</subscript></entry> + </row> + <row> + <entry>start + 4:</entry> + <entry>R<subscript>10</subscript></entry> + <entry>B<subscript>11</subscript></entry> + <entry>R<subscript>12</subscript></entry> + <entry>B<subscript>13</subscript></entry> + </row> + <row> + <entry>start + 8:</entry> + <entry>G<subscript>20</subscript></entry> + <entry>R<subscript>21</subscript></entry> + <entry>G<subscript>22</subscript></entry> + <entry>R<subscript>23</subscript></entry> + </row> + <row> + <entry>start + 12:</entry> + <entry>R<subscript>30</subscript></entry> + <entry>B<subscript>31</subscript></entry> + <entry>R<subscript>32</subscript></entry> + <entry>B<subscript>33</subscript></entry> + </row> + </tbody> + </tgroup> + </informaltable> + </para> + </formalpara> + </example> + </refsect1> + </refentry> + + <!-- +Local Variables: +mode: sgml +sgml-parent-document: "pixfmt.sgml" +indent-tabs-mode: nil +End: + --> diff --git a/Documentation/DocBook/v4l/pixfmt-uyvy.xml b/Documentation/DocBook/v4l/pixfmt-uyvy.xml new file mode 100644 index 000000000000..816c8d467c16 --- /dev/null +++ b/Documentation/DocBook/v4l/pixfmt-uyvy.xml @@ -0,0 +1,128 @@ + <refentry id="V4L2-PIX-FMT-UYVY"> + <refmeta> + <refentrytitle>V4L2_PIX_FMT_UYVY ('UYVY')</refentrytitle> + &manvol; + </refmeta> + <refnamediv> + <refname><constant>V4L2_PIX_FMT_UYVY</constant></refname> + <refpurpose>Variation of +<constant>V4L2_PIX_FMT_YUYV</constant> with different order of samples +in memory</refpurpose> + </refnamediv> + <refsect1> + <title>Description</title> + + <para>In this format each four bytes is two pixels. Each four +bytes is two Y's, a Cb and a Cr. Each Y goes to one of the pixels, and +the Cb and Cr belong to both pixels. As you can see, the Cr and Cb +components have half the horizontal resolution of the Y +component.</para> + + <example> + <title><constant>V4L2_PIX_FMT_UYVY</constant> 4 × 4 +pixel image</title> + + <formalpara> + <title>Byte Order.</title> + <para>Each cell is one byte. + <informaltable frame="none"> + <tgroup cols="9" align="center"> + <colspec align="left" colwidth="2*" /> + <tbody valign="top"> + <row> + <entry>start + 0:</entry> + <entry>Cb<subscript>00</subscript></entry> + <entry>Y'<subscript>00</subscript></entry> + <entry>Cr<subscript>00</subscript></entry> + <entry>Y'<subscript>01</subscript></entry> + <entry>Cb<subscript>01</subscript></entry> + <entry>Y'<subscript>02</subscript></entry> + <entry>Cr<subscript>01</subscript></entry> + <entry>Y'<subscript>03</subscript></entry> + </row> + <row> + <entry>start + 8:</entry> + <entry>Cb<subscript>10</subscript></entry> + <entry>Y'<subscript>10</subscript></entry> + <entry>Cr<subscript>10</subscript></entry> + <entry>Y'<subscript>11</subscript></entry> + <entry>Cb<subscript>11</subscript></entry> + <entry>Y'<subscript>12</subscript></entry> + <entry>Cr<subscript>11</subscript></entry> + <entry>Y'<subscript>13</subscript></entry> + </row> + <row> + <entry>start + 16:</entry> + <entry>Cb<subscript>20</subscript></entry> + <entry>Y'<subscript>20</subscript></entry> + <entry>Cr<subscript>20</subscript></entry> + <entry>Y'<subscript>21</subscript></entry> + <entry>Cb<subscript>21</subscript></entry> + <entry>Y'<subscript>22</subscript></entry> + <entry>Cr<subscript>21</subscript></entry> + <entry>Y'<subscript>23</subscript></entry> + </row> + <row> + <entry>start + 24:</entry> + <entry>Cb<subscript>30</subscript></entry> + <entry>Y'<subscript>30</subscript></entry> + <entry>Cr<subscript>30</subscript></entry> + <entry>Y'<subscript>31</subscript></entry> + <entry>Cb<subscript>31</subscript></entry> + <entry>Y'<subscript>32</subscript></entry> + <entry>Cr<subscript>31</subscript></entry> + <entry>Y'<subscript>33</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>C</entry><entry>Y</entry><entry></entry> + <entry>Y</entry><entry>C</entry><entry>Y</entry> + </row> + <row> + <entry>1</entry> + <entry>Y</entry><entry>C</entry><entry>Y</entry><entry></entry> + <entry>Y</entry><entry>C</entry><entry>Y</entry> + </row> + <row> + <entry>2</entry> + <entry>Y</entry><entry>C</entry><entry>Y</entry><entry></entry> + <entry>Y</entry><entry>C</entry><entry>Y</entry> + </row> + <row> + <entry>3</entry> + <entry>Y</entry><entry>C</entry><entry>Y</entry><entry></entry> + <entry>Y</entry><entry>C</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: + --> diff --git a/Documentation/DocBook/v4l/pixfmt-vyuy.xml b/Documentation/DocBook/v4l/pixfmt-vyuy.xml new file mode 100644 index 000000000000..61f12a5e68d9 --- /dev/null +++ b/Documentation/DocBook/v4l/pixfmt-vyuy.xml @@ -0,0 +1,128 @@ + <refentry id="V4L2-PIX-FMT-VYUY"> + <refmeta> + <refentrytitle>V4L2_PIX_FMT_VYUY ('VYUY')</refentrytitle> + &manvol; + </refmeta> + <refnamediv> + <refname><constant>V4L2_PIX_FMT_VYUY</constant></refname> + <refpurpose>Variation of +<constant>V4L2_PIX_FMT_YUYV</constant> with different order of samples +in memory</refpurpose> + </refnamediv> + <refsect1> + <title>Description</title> + + <para>In this format each four bytes is two pixels. Each four +bytes is two Y's, a Cb and a Cr. Each Y goes to one of the pixels, and +the Cb and Cr belong to both pixels. As you can see, the Cr and Cb +components have half the horizontal resolution of the Y +component.</para> + + <example> + <title><constant>V4L2_PIX_FMT_VYUY</constant> 4 × 4 +pixel image</title> + + <formalpara> + <title>Byte Order.</title> + <para>Each cell is one byte. + <informaltable frame="none"> + <tgroup cols="9" align="center"> + <colspec align="left" colwidth="2*" /> + <tbody valign="top"> + <row> + <entry>start + 0:</entry> + <entry>Cr<subscript>00</subscript></entry> + <entry>Y'<subscript>00</subscript></entry> + <entry>Cb<subscript>00</subscript></entry> + <entry>Y'<subscript>01</subscript></entry> + <entry>Cr<subscript>01</subscript></entry> + <entry>Y'<subscript>02</subscript></entry> + <entry>Cb<subscript>01</subscript></entry> + <entry>Y'<subscript>03</subscript></entry> + </row> + <row> + <entry>start + 8:</entry> + <entry>Cr<subscript>10</subscript></entry> + <entry>Y'<subscript>10</subscript></entry> + <entry>Cb<subscript>10</subscript></entry> + <entry>Y'<subscript>11</subscript></entry> + <entry>Cr<subscript>11</subscript></entry> + <entry>Y'<subscript>12</subscript></entry> + <entry>Cb<subscript>11</subscript></entry> + <entry>Y'<subscript>13</subscript></entry> + </row> + <row> + <entry>start + 16:</entry> + <entry>Cr<subscript>20</subscript></entry> + <entry>Y'<subscript>20</subscript></entry> + <entry>Cb<subscript>20</subscript></entry> + <entry>Y'<subscript>21</subscript></entry> + <entry>Cr<subscript>21</subscript></entry> + <entry>Y'<subscript>22</subscript></entry> + <entry>Cb<subscript>21</subscript></entry> + <entry>Y'<subscript>23</subscript></entry> + </row> + <row> + <entry>start + 24:</entry> + <entry>Cr<subscript>30</subscript></entry> + <entry>Y'<subscript>30</subscript></entry> + <entry>Cb<subscript>30</subscript></entry> + <entry>Y'<subscript>31</subscript></entry> + <entry>Cr<subscript>31</subscript></entry> + <entry>Y'<subscript>32</subscript></entry> + <entry>Cb<subscript>31</subscript></entry> + <entry>Y'<subscript>33</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>C</entry><entry>Y</entry><entry></entry> + <entry>Y</entry><entry>C</entry><entry>Y</entry> + </row> + <row> + <entry>1</entry> + <entry>Y</entry><entry>C</entry><entry>Y</entry><entry></entry> + <entry>Y</entry><entry>C</entry><entry>Y</entry> + </row> + <row> + <entry>2</entry> + <entry>Y</entry><entry>C</entry><entry>Y</entry><entry></entry> + <entry>Y</entry><entry>C</entry><entry>Y</entry> + </row> + <row> + <entry>3</entry> + <entry>Y</entry><entry>C</entry><entry>Y</entry><entry></entry> + <entry>Y</entry><entry>C</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: + --> diff --git a/Documentation/DocBook/v4l/pixfmt-y16.xml b/Documentation/DocBook/v4l/pixfmt-y16.xml new file mode 100644 index 000000000000..d58404015078 --- /dev/null +++ b/Documentation/DocBook/v4l/pixfmt-y16.xml @@ -0,0 +1,89 @@ +<refentry id="V4L2-PIX-FMT-Y16"> + <refmeta> + <refentrytitle>V4L2_PIX_FMT_Y16 ('Y16 ')</refentrytitle> + &manvol; + </refmeta> + <refnamediv> + <refname><constant>V4L2_PIX_FMT_Y16</constant></refname> + <refpurpose>Grey-scale image</refpurpose> + </refnamediv> + <refsect1> + <title>Description</title> + + <para>This is a grey-scale image with a depth of 16 bits per +pixel. The least significant byte is stored at lower memory addresses +(little-endian). Note the actual sampling precision may be lower than +16 bits, for example 10 bits per pixel with values in range 0 to +1023.</para> + + <example> + <title><constant>V4L2_PIX_FMT_Y16</constant> 4 × 4 +pixel image</title> + + <formalpara> + <title>Byte Order.</title> + <para>Each cell is one byte. + <informaltable frame="none"> + <tgroup cols="9" align="center"> + <colspec align="left" colwidth="2*" /> + <tbody valign="top"> + <row> + <entry>start + 0:</entry> + <entry>Y'<subscript>00low</subscript></entry> + <entry>Y'<subscript>00high</subscript></entry> + <entry>Y'<subscript>01low</subscript></entry> + <entry>Y'<subscript>01high</subscript></entry> + <entry>Y'<subscript>02low</subscript></entry> + <entry>Y'<subscript>02high</subscript></entry> + <entry>Y'<subscript>03low</subscript></entry> + <entry>Y'<subscript>03high</subscript></entry> + </row> + <row> + <entry>start + 8:</entry> + <entry>Y'<subscript>10low</subscript></entry> + <entry>Y'<subscript>10high</subscript></entry> + <entry>Y'<subscript>11low</subscript></entry> + <entry>Y'<subscript>11high</subscript></entry> + <entry>Y'<subscript>12low</subscript></entry> + <entry>Y'<subscript>12high</subscript></entry> + <entry>Y'<subscript>13low</subscript></entry> + <entry>Y'<subscript>13high</subscript></entry> + </row> + <row> + <entry>start + 16:</entry> + <entry>Y'<subscript>20low</subscript></entry> + <entry>Y'<subscript>20high</subscript></entry> + <entry>Y'<subscript>21low</subscript></entry> + <entry>Y'<subscript>21high</subscript></entry> + <entry>Y'<subscript>22low</subscript></entry> + <entry>Y'<subscript>22high</subscript></entry> + <entry>Y'<subscript>23low</subscript></entry> + <entry>Y'<subscript>23high</subscript></entry> + </row> + <row> + <entry>start + 24:</entry> + <entry>Y'<subscript>30low</subscript></entry> + <entry>Y'<subscript>30high</subscript></entry> + <entry>Y'<subscript>31low</subscript></entry> + <entry>Y'<subscript>31high</subscript></entry> + <entry>Y'<subscript>32low</subscript></entry> + <entry>Y'<subscript>32high</subscript></entry> + <entry>Y'<subscript>33low</subscript></entry> + <entry>Y'<subscript>33high</subscript></entry> + </row> + </tbody> + </tgroup> + </informaltable> + </para> + </formalpara> + </example> + </refsect1> +</refentry> + + <!-- +Local Variables: +mode: sgml +sgml-parent-document: "pixfmt.sgml" +indent-tabs-mode: nil +End: + --> diff --git a/Documentation/DocBook/v4l/pixfmt-y41p.xml b/Documentation/DocBook/v4l/pixfmt-y41p.xml new file mode 100644 index 000000000000..73c8536efb05 --- /dev/null +++ b/Documentation/DocBook/v4l/pixfmt-y41p.xml @@ -0,0 +1,157 @@ + <refentry id="V4L2-PIX-FMT-Y41P"> + <refmeta> + <refentrytitle>V4L2_PIX_FMT_Y41P ('Y41P')</refentrytitle> + &manvol; + </refmeta> + <refnamediv> + <refname><constant>V4L2_PIX_FMT_Y41P</constant></refname> + <refpurpose>Format with ¼ horizontal chroma +resolution, also known as YUV 4:1:1</refpurpose> + </refnamediv> + <refsect1> + <title>Description</title> + + <para>In this format each 12 bytes is eight pixels. In the +twelve bytes are two CbCr pairs and eight Y's. The first CbCr pair +goes with the first four Y's, and the second CbCr pair goes with the +other four Y's. The Cb and Cr components have one fourth the +horizontal resolution of the Y component.</para> + + <para>Do not confuse this format with <link +linkend="V4L2-PIX-FMT-YUV411P"><constant>V4L2_PIX_FMT_YUV411P</constant></link>. +Y41P is derived from "YUV 4:1:1 <emphasis>packed</emphasis>", while +YUV411P stands for "YUV 4:1:1 <emphasis>planar</emphasis>".</para> + + <example> + <title><constant>V4L2_PIX_FMT_Y41P</constant> 8 × 4 +pixel image</title> + + <formalpara> + <title>Byte Order</title> + <para>Each cell is one byte. + <informaltable frame="none"> + <tgroup cols="13" align="center"> + <colspec align="left" colwidth="2*" /> + <tbody valign="top"> + <row> + <entry>start + 0:</entry> + <entry>Cb<subscript>00</subscript></entry> + <entry>Y'<subscript>00</subscript></entry> + <entry>Cr<subscript>00</subscript></entry> + <entry>Y'<subscript>01</subscript></entry> + <entry>Cb<subscript>01</subscript></entry> + <entry>Y'<subscript>02</subscript></entry> + <entry>Cr<subscript>01</subscript></entry> + <entry>Y'<subscript>03</subscript></entry> + <entry>Y'<subscript>04</subscript></entry> + <entry>Y'<subscript>05</subscript></entry> + <entry>Y'<subscript>06</subscript></entry> + <entry>Y'<subscript>07</subscript></entry> + </row> + <row> + <entry>start + 12:</entry> + <entry>Cb<subscript>10</subscript></entry> + <entry>Y'<subscript>10</subscript></entry> + <entry>Cr<subscript>10</subscript></entry> + <entry>Y'<subscript>11</subscript></entry> + <entry>Cb<subscript>11</subscript></entry> + <entry>Y'<subscript>12</subscript></entry> + <entry>Cr<subscript>11</subscript></entry> + <entry>Y'<subscript>13</subscript></entry> + <entry>Y'<subscript>14</subscript></entry> + <entry>Y'<subscript>15</subscript></entry> + <entry>Y'<subscript>16</subscript></entry> + <entry>Y'<subscript>17</subscript></entry> + </row> + <row> + <entry>start + 24:</entry> + <entry>Cb<subscript>20</subscript></entry> + <entry>Y'<subscript>20</subscript></entry> + <entry>Cr<subscript>20</subscript></entry> + <entry>Y'<subscript>21</subscript></entry> + <entry>Cb<subscript>21</subscript></entry> + <entry>Y'<subscript>22</subscript></entry> + <entry>Cr<subscript>21</subscript></entry> + <entry>Y'<subscript>23</subscript></entry> + <entry>Y'<subscript>24</subscript></entry> + <entry>Y'<subscript>25</subscript></entry> + <entry>Y'<subscript>26</subscript></entry> + <entry>Y'<subscript>27</subscript></entry> + </row> + <row> + <entry>start + 36:</entry> + <entry>Cb<subscript>30</subscript></entry> + <entry>Y'<subscript>30</subscript></entry> + <entry>Cr<subscript>30</subscript></entry> + <entry>Y'<subscript>31</subscript></entry> + <entry>Cb<subscript>31</subscript></entry> + <entry>Y'<subscript>32</subscript></entry> + <entry>Cr<subscript>31</subscript></entry> + <entry>Y'<subscript>33</subscript></entry> + <entry>Y'<subscript>34</subscript></entry> + <entry>Y'<subscript>35</subscript></entry> + <entry>Y'<subscript>36</subscript></entry> + <entry>Y'<subscript>37</subscript></entry> + </row> + </tbody> + </tgroup> + </informaltable></para> + </formalpara> + + <formalpara> + <title>Color Sample Location.</title> + <para> + <informaltable frame="none"> + <tgroup cols="15" 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><entry></entry> + <entry>4</entry><entry></entry><entry>5</entry><entry></entry> + <entry>6</entry><entry></entry><entry>7</entry> + </row> + <row> + <entry>0</entry> + <entry>Y</entry><entry></entry><entry>Y</entry><entry>C</entry> + <entry>Y</entry><entry></entry><entry>Y</entry><entry></entry> + <entry>Y</entry><entry></entry><entry>Y</entry><entry>C</entry> + <entry>Y</entry><entry></entry><entry>Y</entry> + </row> + <row> + <entry>1</entry> + <entry>Y</entry><entry></entry><entry>Y</entry><entry>C</entry> + <entry>Y</entry><entry></entry><entry>Y</entry><entry></entry> + <entry>Y</entry><entry></entry><entry>Y</entry><entry>C</entry> + <entry>Y</entry><entry></entry><entry>Y</entry> + </row> + <row> + <entry>2</entry> + <entry>Y</entry><entry></entry><entry>Y</entry><entry>C</entry> + <entry>Y</entry><entry></entry><entry>Y</entry><entry></entry> + <entry>Y</entry><entry></entry><entry>Y</entry><entry>C</entry> + <entry>Y</entry><entry></entry><entry>Y</entry> + </row> + <row> + <entry>3</entry> + <entry>Y</entry><entry></entry><entry>Y</entry><entry>C</entry> + <entry>Y</entry><entry></entry><entry>Y</entry><entry></entry> + <entry>Y</entry><entry></entry><entry>Y</entry><entry>C</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: + --> diff --git a/Documentation/DocBook/v4l/pixfmt-yuv410.xml b/Documentation/DocBook/v4l/pixfmt-yuv410.xml new file mode 100644 index 000000000000..8eb4a193d770 --- /dev/null +++ b/Documentation/DocBook/v4l/pixfmt-yuv410.xml @@ -0,0 +1,141 @@ + <refentry> + <refmeta> + <refentrytitle>V4L2_PIX_FMT_YVU410 ('YVU9'), V4L2_PIX_FMT_YUV410 ('YUV9')</refentrytitle> + &manvol; + </refmeta> + <refnamediv> + <refname id="V4L2-PIX-FMT-YVU410"><constant>V4L2_PIX_FMT_YVU410</constant></refname> + <refname id="V4L2-PIX-FMT-YUV410"><constant>V4L2_PIX_FMT_YUV410</constant></refname> + <refpurpose>Planar formats with ¼ horizontal and +vertical chroma resolution, also known as YUV 4:1:0</refpurpose> + </refnamediv> + <refsect1> + <title>Description</title> + + <para>These are planar formats, 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. For +<constant>V4L2_PIX_FMT_YVU410</constant>, the Cr plane immediately +follows the Y plane in memory. The Cr plane is ¼ the width and +¼ the height of the Y plane (and of the image). Each Cr belongs +to 16 pixels, a four-by-four square of the image. Following the Cr +plane is the Cb plane, just like the Cr plane. +<constant>V4L2_PIX_FMT_YUV410</constant> is the same, except the Cb +plane comes first, then the Cr plane.</para> + + <para>If the Y plane has pad bytes after each row, then the Cr +and Cb planes have ¼ as many pad bytes after their rows. In +other words, four Cx rows (including padding) are exactly as long as +one Y row (including padding).</para> + + <example> + <title><constant>V4L2_PIX_FMT_YVU410</constant> 4 × 4 +pixel image</title> + + <formalpara> + <title>Byte Order.</title> + <para>Each cell is one byte. + <informaltable frame="none"> + <tgroup cols="5" align="center"> + <colspec align="left" colwidth="2*" /> + <tbody valign="top"> + <row> + <entry>start + 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>start + 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>start + 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>start + 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>start + 16:</entry> + <entry>Cr<subscript>00</subscript></entry> + </row> + <row> + <entry>start + 17:</entry> + <entry>Cb<subscript>00</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> + </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> + <entry></entry><entry></entry><entry></entry><entry>C</entry> + <entry></entry><entry></entry><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> + </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: + --> diff --git a/Documentation/DocBook/v4l/pixfmt-yuv411p.xml b/Documentation/DocBook/v4l/pixfmt-yuv411p.xml new file mode 100644 index 000000000000..00e0960a9869 --- /dev/null +++ b/Documentation/DocBook/v4l/pixfmt-yuv411p.xml @@ -0,0 +1,155 @@ + <refentry id="V4L2-PIX-FMT-YUV411P"> + <refmeta> + <refentrytitle>V4L2_PIX_FMT_YUV411P ('411P')</refentrytitle> + &manvol; + </refmeta> + <refnamediv> + <refname><constant>V4L2_PIX_FMT_YUV411P</constant></refname> + <refpurpose>Format with ¼ horizontal chroma resolution, +also known as YUV 4:1:1. Planar layout as opposed to +<constant>V4L2_PIX_FMT_Y41P</constant></refpurpose> + </refnamediv> + <refsect1> + <title>Description</title> + + <para>This format is not commonly used. This is a planar +format similar to the 4:2:2 planar format except with half as many +chroma. 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 plane immediately follows the Y plane in memory. The Cb plane is +¼ the width of the Y plane (and of the image). Each Cb belongs +to 4 pixels all on the same row. For example, +Cb<subscript>0</subscript> belongs to Y'<subscript>00</subscript>, +Y'<subscript>01</subscript>, Y'<subscript>02</subscript> and +Y'<subscript>03</subscript>. Following the Cb plane is the Cr plane, +just like the Cb plane.</para> + + <para>If the Y plane has pad bytes after each row, then the Cr +and Cb planes have ¼ as many pad bytes after their rows. In +other words, four C x rows (including padding) is exactly as long as +one Y row (including padding).</para> + + <example> + <title><constant>V4L2_PIX_FMT_YUV411P</constant> 4 × 4 +pixel image</title> + + <formalpara> + <title>Byte Order.</title> + <para>Each cell is one byte. + <informaltable frame="none"> + <tgroup cols="5" align="center"> + <colspec align="left" colwidth="2*" /> + <tbody valign="top"> + <row> + <entry>start + 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>start + 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>start + 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>start + 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>start + 16:</entry> + <entry>Cb<subscript>00</subscript></entry> + </row> + <row> + <entry>start + 17:</entry> + <entry>Cb<subscript>10</subscript></entry> + </row> + <row> + <entry>start + 18:</entry> + <entry>Cb<subscript>20</subscript></entry> + </row> + <row> + <entry>start + 19:</entry> + <entry>Cb<subscript>30</subscript></entry> + </row> + <row> + <entry>start + 20:</entry> + <entry>Cr<subscript>00</subscript></entry> + </row> + <row> + <entry>start + 21:</entry> + <entry>Cr<subscript>10</subscript></entry> + </row> + <row> + <entry>start + 22:</entry> + <entry>Cr<subscript>20</subscript></entry> + </row> + <row> + <entry>start + 23:</entry> + <entry>Cr<subscript>30</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>C</entry> + <entry>Y</entry><entry></entry><entry>Y</entry> + </row> + <row> + <entry>1</entry> + <entry>Y</entry><entry></entry><entry>Y</entry><entry>C</entry> + <entry>Y</entry><entry></entry><entry>Y</entry> + </row> + <row> + <entry>2</entry> + <entry>Y</entry><entry></entry><entry>Y</entry><entry>C</entry> + <entry>Y</entry><entry></entry><entry>Y</entry> + </row> + <row> + <entry>3</entry> + <entry>Y</entry><entry></entry><entry>Y</entry><entry>C</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: "v4l2.sgml" +indent-tabs-mode: nil +End: + --> diff --git a/Documentation/DocBook/v4l/pixfmt-yuv420.xml b/Documentation/DocBook/v4l/pixfmt-yuv420.xml new file mode 100644 index 000000000000..42d7de5e456d --- /dev/null +++ b/Documentation/DocBook/v4l/pixfmt-yuv420.xml @@ -0,0 +1,157 @@ + <refentry> + <refmeta> + <refentrytitle>V4L2_PIX_FMT_YVU420 ('YV12'), V4L2_PIX_FMT_YUV420 ('YU12')</refentrytitle> + &manvol; + </refmeta> + <refnamediv> + <refname id="V4L2-PIX-FMT-YVU420"><constant>V4L2_PIX_FMT_YVU420</constant></refname> + <refname id="V4L2-PIX-FMT-YUV420"><constant>V4L2_PIX_FMT_YUV420</constant></refname> + <refpurpose>Planar formats with ½ horizontal and +vertical chroma resolution, also known as YUV 4:2:0</refpurpose> + </refnamediv> + <refsect1> + <title>Description</title> + + <para>These are planar formats, 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. For +<constant>V4L2_PIX_FMT_YVU420</constant>, the Cr plane immediately +follows the Y plane in memory. The Cr plane is half the width and half +the height of the Y plane (and of the image). Each Cr belongs to four +pixels, a two-by-two square of the image. For example, +Cr<subscript>0</subscript> belongs to Y'<subscript>00</subscript>, +Y'<subscript>01</subscript>, Y'<subscript>10</subscript>, and +Y'<subscript>11</subscript>. Following the Cr plane is the Cb plane, +just like the Cr plane. <constant>V4L2_PIX_FMT_YUV420</constant> is +the same except the Cb plane comes first, then the Cr plane.</para> + + <para>If the Y plane has pad bytes after each row, then the Cr +and Cb 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> + + <example> + <title><constant>V4L2_PIX_FMT_YVU420</constant> 4 × 4 +pixel image</title> + + <formalpara> + <title>Byte Order.</title> + <para>Each cell is one byte. + <informaltable frame="none"> + <tgroup cols="5" align="center"> + <colspec align="left" colwidth="2*" /> + <tbody valign="top"> + <row> + <entry>start + 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>start + 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>start + 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>start + 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>start + 16:</entry> + <entry>Cr<subscript>00</subscript></entry> + <entry>Cr<subscript>01</subscript></entry> + </row> + <row> + <entry>start + 18:</entry> + <entry>Cr<subscript>10</subscript></entry> + <entry>Cr<subscript>11</subscript></entry> + </row> + <row> + <entry>start + 20:</entry> + <entry>Cb<subscript>00</subscript></entry> + <entry>Cb<subscript>01</subscript></entry> + </row> + <row> + <entry>start + 22:</entry> + <entry>Cb<subscript>10</subscript></entry> + <entry>Cb<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: + --> diff --git a/Documentation/DocBook/v4l/pixfmt-yuv422p.xml b/Documentation/DocBook/v4l/pixfmt-yuv422p.xml new file mode 100644 index 000000000000..4348bd9f0d01 --- /dev/null +++ b/Documentation/DocBook/v4l/pixfmt-yuv422p.xml @@ -0,0 +1,161 @@ + <refentry id="V4L2-PIX-FMT-YUV422P"> + <refmeta> + <refentrytitle>V4L2_PIX_FMT_YUV422P ('422P')</refentrytitle> + &manvol; + </refmeta> + <refnamediv> + <refname><constant>V4L2_PIX_FMT_YUV422P</constant></refname> + <refpurpose>Format with ½ horizontal chroma resolution, +also known as YUV 4:2:2. Planar layout as opposed to +<constant>V4L2_PIX_FMT_YUYV</constant></refpurpose> + </refnamediv> + <refsect1> + <title>Description</title> + + <para>This format is not commonly used. This is a planar +version of the YUYV 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 plane immediately follows the Y plane in +memory. The Cb plane is half the width of the Y plane (and of the +image). Each Cb belongs to two pixels. For example, +Cb<subscript>0</subscript> belongs to Y'<subscript>00</subscript>, +Y'<subscript>01</subscript>. Following the Cb plane is the Cr plane, +just like the Cb plane.</para> + + <para>If the Y plane has pad bytes after each row, then the Cr +and Cb 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> + + <example> + <title><constant>V4L2_PIX_FMT_YUV422P</constant> 4 × 4 +pixel image</title> + + <formalpara> + <title>Byte Order.</title> + <para>Each cell is one byte. + <informaltable frame="none"> + <tgroup cols="5" align="center"> + <colspec align="left" colwidth="2*" /> + <tbody valign="top"> + <row> + <entry>start + 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>start + 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>start + 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>start + 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>start + 16:</entry> + <entry>Cb<subscript>00</subscript></entry> + <entry>Cb<subscript>01</subscript></entry> + </row> + <row> + <entry>start + 18:</entry> + <entry>Cb<subscript>10</subscript></entry> + <entry>Cb<subscript>11</subscript></entry> + </row> + <row> + <entry>start + 20:</entry> + <entry>Cb<subscript>20</subscript></entry> + <entry>Cb<subscript>21</subscript></entry> + </row> + <row> + <entry>start + 22:</entry> + <entry>Cb<subscript>30</subscript></entry> + <entry>Cb<subscript>31</subscript></entry> + </row> + <row> + <entry>start + 24:</entry> + <entry>Cr<subscript>00</subscript></entry> + <entry>Cr<subscript>01</subscript></entry> + </row> + <row> + <entry>start + 26:</entry> + <entry>Cr<subscript>10</subscript></entry> + <entry>Cr<subscript>11</subscript></entry> + </row> + <row> + <entry>start + 28:</entry> + <entry>Cr<subscript>20</subscript></entry> + <entry>Cr<subscript>21</subscript></entry> + </row> + <row> + <entry>start + 30:</entry> + <entry>Cr<subscript>30</subscript></entry> + <entry>Cr<subscript>31</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>C</entry><entry>Y</entry><entry></entry> + <entry>Y</entry><entry>C</entry><entry>Y</entry> + </row> + <row> + <entry>1</entry> + <entry>Y</entry><entry>C</entry><entry>Y</entry><entry></entry> + <entry>Y</entry><entry>C</entry><entry>Y</entry> + </row> + <row> + <entry>2</entry> + <entry>Y</entry><entry>C</entry><entry>Y</entry><entry></entry> + <entry>Y</entry><entry>C</entry><entry>Y</entry> + </row> + <row> + <entry>3</entry> + <entry>Y</entry><entry>C</entry><entry>Y</entry><entry></entry> + <entry>Y</entry><entry>C</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: + --> diff --git a/Documentation/DocBook/v4l/pixfmt-yuyv.xml b/Documentation/DocBook/v4l/pixfmt-yuyv.xml new file mode 100644 index 000000000000..bdb2ffacbbcc --- /dev/null +++ b/Documentation/DocBook/v4l/pixfmt-yuyv.xml @@ -0,0 +1,128 @@ + <refentry id="V4L2-PIX-FMT-YUYV"> + <refmeta> + <refentrytitle>V4L2_PIX_FMT_YUYV ('YUYV')</refentrytitle> + &manvol; + </refmeta> + <refnamediv> + <refname><constant>V4L2_PIX_FMT_YUYV</constant></refname> + <refpurpose>Packed format with ½ horizontal chroma +resolution, also known as YUV 4:2:2</refpurpose> + </refnamediv> + <refsect1> + <title>Description</title> + + <para>In this format each four bytes is two pixels. Each four +bytes is two Y's, a Cb and a Cr. Each Y goes to one of the pixels, and +the Cb and Cr belong to both pixels. As you can see, the Cr and Cb +components have half the horizontal resolution of the Y component. +<constant>V4L2_PIX_FMT_YUYV </constant> is known in the Windows +environment as YUY2.</para> + + <example> + <title><constant>V4L2_PIX_FMT_YUYV</constant> 4 × 4 +pixel image</title> + + <formalpara> + <title>Byte Order.</title> + <para>Each cell is one byte. + <informaltable frame="none"> + <tgroup cols="9" align="center"> + <colspec align="left" colwidth="2*" /> + <tbody valign="top"> + <row> + <entry>start + 0:</entry> + <entry>Y'<subscript>00</subscript></entry> + <entry>Cb<subscript>00</subscript></entry> + <entry>Y'<subscript>01</subscript></entry> + <entry>Cr<subscript>00</subscript></entry> + <entry>Y'<subscript>02</subscript></entry> + <entry>Cb<subscript>01</subscript></entry> + <entry>Y'<subscript>03</subscript></entry> + <entry>Cr<subscript>01</subscript></entry> + </row> + <row> + <entry>start + 8:</entry> + <entry>Y'<subscript>10</subscript></entry> + <entry>Cb<subscript>10</subscript></entry> + <entry>Y'<subscript>11</subscript></entry> + <entry>Cr<subscript>10</subscript></entry> + <entry>Y'<subscript>12</subscript></entry> + <entry>Cb<subscript>11</subscript></entry> + <entry>Y'<subscript>13</subscript></entry> + <entry>Cr<subscript>11</subscript></entry> + </row> + <row> + <entry>start + 16:</entry> + <entry>Y'<subscript>20</subscript></entry> + <entry>Cb<subscript>20</subscript></entry> + <entry>Y'<subscript>21</subscript></entry> + <entry>Cr<subscript>20</subscript></entry> + <entry>Y'<subscript>22</subscript></entry> + <entry>Cb<subscript>21</subscript></entry> + <entry>Y'<subscript>23</subscript></entry> + <entry>Cr<subscript>21</subscript></entry> + </row> + <row> + <entry>start + 24:</entry> + <entry>Y'<subscript>30</subscript></entry> + <entry>Cb<subscript>30</subscript></entry> + <entry>Y'<subscript>31</subscript></entry> + <entry>Cr<subscript>30</subscript></entry> + <entry>Y'<subscript>32</subscript></entry> + <entry>Cb<subscript>31</subscript></entry> + <entry>Y'<subscript>33</subscript></entry> + <entry>Cr<subscript>31</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>C</entry><entry>Y</entry><entry></entry> + <entry>Y</entry><entry>C</entry><entry>Y</entry> + </row> + <row> + <entry>1</entry> + <entry>Y</entry><entry>C</entry><entry>Y</entry><entry></entry> + <entry>Y</entry><entry>C</entry><entry>Y</entry> + </row> + <row> + <entry>2</entry> + <entry>Y</entry><entry>C</entry><entry>Y</entry><entry></entry> + <entry>Y</entry><entry>C</entry><entry>Y</entry> + </row> + <row> + <entry>3</entry> + <entry>Y</entry><entry>C</entry><entry>Y</entry><entry></entry> + <entry>Y</entry><entry>C</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: + --> diff --git a/Documentation/DocBook/v4l/pixfmt-yvyu.xml b/Documentation/DocBook/v4l/pixfmt-yvyu.xml new file mode 100644 index 000000000000..40d17ae39dde --- /dev/null +++ b/Documentation/DocBook/v4l/pixfmt-yvyu.xml @@ -0,0 +1,128 @@ + <refentry id="V4L2-PIX-FMT-YVYU"> + <refmeta> + <refentrytitle>V4L2_PIX_FMT_YVYU ('YVYU')</refentrytitle> + &manvol; + </refmeta> + <refnamediv> + <refname><constant>V4L2_PIX_FMT_YVYU</constant></refname> + <refpurpose>Variation of +<constant>V4L2_PIX_FMT_YUYV</constant> with different order of samples +in memory</refpurpose> + </refnamediv> + <refsect1> + <title>Description</title> + + <para>In this format each four bytes is two pixels. Each four +bytes is two Y's, a Cb and a Cr. Each Y goes to one of the pixels, and +the Cb and Cr belong to both pixels. As you can see, the Cr and Cb +components have half the horizontal resolution of the Y +component.</para> + + <example> + <title><constant>V4L2_PIX_FMT_YVYU</constant> 4 × 4 +pixel image</title> + + <formalpara> + <title>Byte Order.</title> + <para>Each cell is one byte. + <informaltable frame="none"> + <tgroup cols="9" align="center"> + <colspec align="left" colwidth="2*" /> + <tbody valign="top"> + <row> + <entry>start + 0:</entry> + <entry>Y'<subscript>00</subscript></entry> + <entry>Cr<subscript>00</subscript></entry> + <entry>Y'<subscript>01</subscript></entry> + <entry>Cb<subscript>00</subscript></entry> + <entry>Y'<subscript>02</subscript></entry> + <entry>Cr<subscript>01</subscript></entry> + <entry>Y'<subscript>03</subscript></entry> + <entry>Cb<subscript>01</subscript></entry> + </row> + <row> + <entry>start + 8:</entry> + <entry>Y'<subscript>10</subscript></entry> + <entry>Cr<subscript>10</subscript></entry> + <entry>Y'<subscript>11</subscript></entry> + <entry>Cb<subscript>10</subscript></entry> + <entry>Y'<subscript>12</subscript></entry> + <entry>Cr<subscript>11</subscript></entry> + <entry>Y'<subscript>13</subscript></entry> + <entry>Cb<subscript>11</subscript></entry> + </row> + <row> + <entry>start + 16:</entry> + <entry>Y'<subscript>20</subscript></entry> + <entry>Cr<subscript>20</subscript></entry> + <entry>Y'<subscript>21</subscript></entry> + <entry>Cb<subscript>20</subscript></entry> + <entry>Y'<subscript>22</subscript></entry> + <entry>Cr<subscript>21</subscript></entry> + <entry>Y'<subscript>23</subscript></entry> + <entry>Cb<subscript>21</subscript></entry> + </row> + <row> + <entry>start + 24:</entry> + <entry>Y'<subscript>30</subscript></entry> + <entry>Cr<subscript>30</subscript></entry> + <entry>Y'<subscript>31</subscript></entry> + <entry>Cb<subscript>30</subscript></entry> + <entry>Y'<subscript>32</subscript></entry> + <entry>Cr<subscript>31</subscript></entry> + <entry>Y'<subscript>33</subscript></entry> + <entry>Cb<subscript>31</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>C</entry><entry>Y</entry><entry></entry> + <entry>Y</entry><entry>C</entry><entry>Y</entry> + </row> + <row> + <entry>1</entry> + <entry>Y</entry><entry>C</entry><entry>Y</entry><entry></entry> + <entry>Y</entry><entry>C</entry><entry>Y</entry> + </row> + <row> + <entry>2</entry> + <entry>Y</entry><entry>C</entry><entry>Y</entry><entry></entry> + <entry>Y</entry><entry>C</entry><entry>Y</entry> + </row> + <row> + <entry>3</entry> + <entry>Y</entry><entry>C</entry><entry>Y</entry><entry></entry> + <entry>Y</entry><entry>C</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: + --> diff --git a/Documentation/DocBook/v4l/pixfmt.xml b/Documentation/DocBook/v4l/pixfmt.xml new file mode 100644 index 000000000000..885968d6a2fc --- /dev/null +++ b/Documentation/DocBook/v4l/pixfmt.xml @@ -0,0 +1,806 @@ + <title>Image Formats</title> + + <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 +capturing and output, for overlay frame buffer formats see also +&VIDIOC-G-FBUF;.)</para> + + <table pgwide="1" frame="none" id="v4l2-pix-format"> + <title>struct <structname>v4l2_pix_format</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 spanname="hspan">Applications set these fields to +request an image size, drivers return the closest possible values. In +case of planar formats the <structfield>width</structfield> and +<structfield>height</structfield> applies to the largest plane. To +avoid ambiguities drivers must return values rounded up to a multiple +of the scale factor of any smaller planes. For example when the image +format is YUV 4:2:0, <structfield>width</structfield> and +<structfield>height</structfield> must be multiples of two.</entry> + </row> + <row> + <entry>__u32</entry> + <entry><structfield>pixelformat</structfield></entry> + <entry>The pixel format or type of compression, set by the +application. This is a little endian <link +linkend="v4l2-fourcc">four character code</link>. V4L2 defines +standard RGB formats in <xref linkend="rgb-formats" />, YUV formats in <xref +linkend="yuv-formats" />, and reserved codes in <xref +linkend="reserved-formats" /></entry> + </row> + <row> + <entry>&v4l2-field;</entry> + <entry><structfield>field</structfield></entry> + <entry>Video images are typically interlaced. Applications +can request to capture or output only the top or bottom field, or both +fields interlaced or sequentially stored in one buffer or alternating +in separate buffers. Drivers return the actual field order selected. +For details see <xref linkend="field-order" />.</entry> + </row> + <row> + <entry>__u32</entry> + <entry><structfield>bytesperline</structfield></entry> + <entry>Distance in bytes between the leftmost pixels in two +adjacent lines.</entry> + </row> + <row> + <entry spanname="hspan"><para>Both applications and drivers +can set this field to request padding bytes at the end of each line. +Drivers however may ignore the value requested by the application, +returning <structfield>width</structfield> times bytes per pixel or a +larger value required by the hardware. That implies applications can +just set this field to zero to get a reasonable +default.</para><para>Video hardware may access padding bytes, +therefore they must reside in accessible memory. Consider cases where +padding bytes after the last line of an image cross a system page +boundary. Input devices may write padding bytes, the value is +undefined. Output devices ignore the contents of padding +bytes.</para><para>When the image format is planar the +<structfield>bytesperline</structfield> value applies to the largest +plane and is divided by the same factor as the +<structfield>width</structfield> field for any smaller planes. For +example the Cb and Cr planes of a YUV 4:2:0 image have half as many +padding bytes following each line as the Y plane. To avoid ambiguities +drivers must return a <structfield>bytesperline</structfield> value +rounded up to a multiple of the scale factor.</para></entry> + </row> + <row> + <entry>__u32</entry> + <entry><structfield>sizeimage</structfield></entry> + <entry>Size in bytes of the buffer to hold a complete image, +set by the driver. Usually this is +<structfield>bytesperline</structfield> times +<structfield>height</structfield>. When the image consists of variable +length compressed data this is the maximum number of bytes required to +hold an image.</entry> + </row> + <row> + <entry>&v4l2-colorspace;</entry> + <entry><structfield>colorspace</structfield></entry> + <entry>This information supplements the +<structfield>pixelformat</structfield> and must be set by the driver, +see <xref linkend="colorspaces" />.</entry> + </row> + <row> + <entry>__u32</entry> + <entry><structfield>priv</structfield></entry> + <entry>Reserved for custom (driver defined) additional +information about formats. When not used drivers and applications must +set this field to zero.</entry> + </row> + </tbody> + </tgroup> + </table> + + <section> + <title>Standard Image Formats</title> + + <para>In order to exchange images between drivers and +applications, it is necessary to have standard image data formats +which both sides will interpret the same way. V4L2 includes several +such formats, and this section is intended to be an unambiguous +specification of the standard image data formats in V4L2.</para> + + <para>V4L2 drivers are not limited to these formats, however. +Driver-specific formats are possible. In that case the application may +depend on a codec to convert images to one of the standard formats +when needed. But the data can still be stored and retrieved in the +proprietary format. For example, a device may support a proprietary +compressed format. Applications can still capture and save the data in +the compressed format, saving much disk space, and later use a codec +to convert the images to the X Windows screen format when the video is +to be displayed.</para> + + <para>Even so, ultimately, some standard formats are needed, so +the V4L2 specification would not be complete without well-defined +standard formats.</para> + + <para>The V4L2 standard formats are mainly uncompressed formats. The +pixels are always arranged in memory from left to right, and from top +to bottom. The first byte of data in the image buffer is always for +the leftmost pixel of the topmost row. Following that is the pixel +immediately to its right, and so on until the end of the top row of +pixels. Following the rightmost pixel of the row there may be zero or +more bytes of padding to guarantee that each row of pixel data has a +certain alignment. Following the pad bytes, if any, is data for the +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 <link +linkend="videodev">videodev.h</link> header file. These identifiers +represent <link linkend="v4l2-fourcc">four character codes</link> +which are also listed below, however they are not the same as those +used in the Windows world.</para> + </section> + + <section id="colorspaces"> + <title>Colorspaces</title> + + <para>[intro]</para> + + <!-- See proposal by Billy Biggs, video4linux-list@redhat.com +on 11 Oct 2002, subject: "Re: [V4L] Re: v4l2 api", and +http://vektor.theorem.ca/graphics/ycbcr/ and +http://www.poynton.com/notes/colour_and_gamma/ColorFAQ.html --> + + <para> + <variablelist> + <varlistentry> + <term>Gamma Correction</term> + <listitem> + <para>[to do]</para> + <para>E'<subscript>R</subscript> = f(R)</para> + <para>E'<subscript>G</subscript> = f(G)</para> + <para>E'<subscript>B</subscript> = f(B)</para> + </listitem> + </varlistentry> + <varlistentry> + <term>Construction of luminance and color-difference +signals</term> + <listitem> + <para>[to do]</para> + <para>E'<subscript>Y</subscript> = +Coeff<subscript>R</subscript> E'<subscript>R</subscript> ++ Coeff<subscript>G</subscript> E'<subscript>G</subscript> ++ Coeff<subscript>B</subscript> E'<subscript>B</subscript></para> + <para>(E'<subscript>R</subscript> - E'<subscript>Y</subscript>) = E'<subscript>R</subscript> +- Coeff<subscript>R</subscript> E'<subscript>R</subscript> +- Coeff<subscript>G</subscript> E'<subscript>G</subscript> +- Coeff<subscript>B</subscript> E'<subscript>B</subscript></para> + <para>(E'<subscript>B</subscript> - E'<subscript>Y</subscript>) = E'<subscript>B</subscript> +- Coeff<subscript>R</subscript> E'<subscript>R</subscript> +- Coeff<subscript>G</subscript> E'<subscript>G</subscript> +- Coeff<subscript>B</subscript> E'<subscript>B</subscript></para> + </listitem> + </varlistentry> + <varlistentry> + <term>Re-normalized color-difference signals</term> + <listitem> + <para>The color-difference signals are scaled back to unity +range [-0.5;+0.5]:</para> + <para>K<subscript>B</subscript> = 0.5 / (1 - Coeff<subscript>B</subscript>)</para> + <para>K<subscript>R</subscript> = 0.5 / (1 - Coeff<subscript>R</subscript>)</para> + <para>P<subscript>B</subscript> = +K<subscript>B</subscript> (E'<subscript>B</subscript> - E'<subscript>Y</subscript>) = + 0.5 (Coeff<subscript>R</subscript> / Coeff<subscript>B</subscript>) E'<subscript>R</subscript> ++ 0.5 (Coeff<subscript>G</subscript> / Coeff<subscript>B</subscript>) E'<subscript>G</subscript> ++ 0.5 E'<subscript>B</subscript></para> + <para>P<subscript>R</subscript> = +K<subscript>R</subscript> (E'<subscript>R</subscript> - E'<subscript>Y</subscript>) = + 0.5 E'<subscript>R</subscript> ++ 0.5 (Coeff<subscript>G</subscript> / Coeff<subscript>R</subscript>) E'<subscript>G</subscript> ++ 0.5 (Coeff<subscript>B</subscript> / Coeff<subscript>R</subscript>) E'<subscript>B</subscript></para> + </listitem> + </varlistentry> + <varlistentry> + <term>Quantization</term> + <listitem> + <para>[to do]</para> + <para>Y' = (Lum. Levels - 1) · E'<subscript>Y</subscript> + Lum. Offset</para> + <para>C<subscript>B</subscript> = (Chrom. Levels - 1) +· P<subscript>B</subscript> + Chrom. Offset</para> + <para>C<subscript>R</subscript> = (Chrom. Levels - 1) +· P<subscript>R</subscript> + Chrom. Offset</para> + <para>Rounding to the nearest integer and clamping to the range +[0;255] finally yields the digital color components Y'CbCr +stored in YUV images.</para> + </listitem> + </varlistentry> + </variablelist> + </para> + + <example> + <title>ITU-R Rec. BT.601 color conversion</title> + + <para>Forward Transformation</para> + + <programlisting> +int ER, EG, EB; /* gamma corrected RGB input [0;255] */ +int Y1, Cb, Cr; /* output [0;255] */ + +double r, g, b; /* temporaries */ +double y1, pb, pr; + +int +clamp (double x) +{ + int r = x; /* round to nearest */ + + if (r < 0) return 0; + else if (r > 255) return 255; + else return r; +} + +r = ER / 255.0; +g = EG / 255.0; +b = EB / 255.0; + +y1 = 0.299 * r + 0.587 * g + 0.114 * b; +pb = -0.169 * r - 0.331 * g + 0.5 * b; +pr = 0.5 * r - 0.419 * g - 0.081 * b; + +Y1 = clamp (219 * y1 + 16); +Cb = clamp (224 * pb + 128); +Cr = clamp (224 * pr + 128); + +/* or shorter */ + +y1 = 0.299 * ER + 0.587 * EG + 0.114 * EB; + +Y1 = clamp ( (219 / 255.0) * y1 + 16); +Cb = clamp (((224 / 255.0) / (2 - 2 * 0.114)) * (EB - y1) + 128); +Cr = clamp (((224 / 255.0) / (2 - 2 * 0.299)) * (ER - y1) + 128); + </programlisting> + + <para>Inverse Transformation</para> + + <programlisting> +int Y1, Cb, Cr; /* gamma pre-corrected input [0;255] */ +int ER, EG, EB; /* output [0;255] */ + +double r, g, b; /* temporaries */ +double y1, pb, pr; + +int +clamp (double x) +{ + int r = x; /* round to nearest */ + + if (r < 0) return 0; + else if (r > 255) return 255; + else return r; +} + +y1 = (255 / 219.0) * (Y1 - 16); +pb = (255 / 224.0) * (Cb - 128); +pr = (255 / 224.0) * (Cr - 128); + +r = 1.0 * y1 + 0 * pb + 1.402 * pr; +g = 1.0 * y1 - 0.344 * pb - 0.714 * pr; +b = 1.0 * y1 + 1.772 * pb + 0 * pr; + +ER = clamp (r * 255); /* [ok? one should prob. limit y1,pb,pr] */ +EG = clamp (g * 255); +EB = clamp (b * 255); + </programlisting> + </example> + + <table pgwide="1" id="v4l2-colorspace" orient="land"> + <title>enum v4l2_colorspace</title> + <tgroup cols="11" align="center"> + <colspec align="left" /> + <colspec align="center" /> + <colspec align="left" /> + <colspec colname="cr" /> + <colspec colname="cg" /> + <colspec colname="cb" /> + <colspec colname="wp" /> + <colspec colname="gc" /> + <colspec colname="lum" /> + <colspec colname="qy" /> + <colspec colname="qc" /> + <spanspec namest="cr" nameend="cb" spanname="chrom" /> + <spanspec namest="qy" nameend="qc" spanname="quant" /> + <spanspec namest="lum" nameend="qc" spanname="spam" /> + <thead> + <row> + <entry morerows="1">Identifier</entry> + <entry morerows="1">Value</entry> + <entry morerows="1">Description</entry> + <entry spanname="chrom">Chromaticities<footnote> + <para>The coordinates of the color primaries are +given in the CIE system (1931)</para> + </footnote></entry> + <entry morerows="1">White Point</entry> + <entry morerows="1">Gamma Correction</entry> + <entry morerows="1">Luminance E'<subscript>Y</subscript></entry> + <entry spanname="quant">Quantization</entry> + </row> + <row> + <entry>Red</entry> + <entry>Green</entry> + <entry>Blue</entry> + <entry>Y'</entry> + <entry>Cb, Cr</entry> + </row> + </thead> + <tbody valign="top"> + <row> + <entry><constant>V4L2_COLORSPACE_SMPTE170M</constant></entry> + <entry>1</entry> + <entry>NTSC/PAL according to <xref linkend="smpte170m" />, +<xref linkend="itu601" /></entry> + <entry>x = 0.630, y = 0.340</entry> + <entry>x = 0.310, y = 0.595</entry> + <entry>x = 0.155, y = 0.070</entry> + <entry>x = 0.3127, y = 0.3290, + Illuminant D<subscript>65</subscript></entry> + <entry>E' = 4.5 I for I ≤0.018, +1.099 I<superscript>0.45</superscript> - 0.099 for 0.018 < I</entry> + <entry>0.299 E'<subscript>R</subscript> ++ 0.587 E'<subscript>G</subscript> ++ 0.114 E'<subscript>B</subscript></entry> + <entry>219 E'<subscript>Y</subscript> + 16</entry> + <entry>224 P<subscript>B,R</subscript> + 128</entry> + </row> + <row> + <entry><constant>V4L2_COLORSPACE_SMPTE240M</constant></entry> + <entry>2</entry> + <entry>1125-Line (US) HDTV, see <xref +linkend="smpte240m" /></entry> + <entry>x = 0.630, y = 0.340</entry> + <entry>x = 0.310, y = 0.595</entry> + <entry>x = 0.155, y = 0.070</entry> + <entry>x = 0.3127, y = 0.3290, + Illuminant D<subscript>65</subscript></entry> + <entry>E' = 4 I for I ≤0.0228, +1.1115 I<superscript>0.45</superscript> - 0.1115 for 0.0228 < I</entry> + <entry>0.212 E'<subscript>R</subscript> ++ 0.701 E'<subscript>G</subscript> ++ 0.087 E'<subscript>B</subscript></entry> + <entry>219 E'<subscript>Y</subscript> + 16</entry> + <entry>224 P<subscript>B,R</subscript> + 128</entry> + </row> + <row> + <entry><constant>V4L2_COLORSPACE_REC709</constant></entry> + <entry>3</entry> + <entry>HDTV and modern devices, see <xref +linkend="itu709" /></entry> + <entry>x = 0.640, y = 0.330</entry> + <entry>x = 0.300, y = 0.600</entry> + <entry>x = 0.150, y = 0.060</entry> + <entry>x = 0.3127, y = 0.3290, + Illuminant D<subscript>65</subscript></entry> + <entry>E' = 4.5 I for I ≤0.018, +1.099 I<superscript>0.45</superscript> - 0.099 for 0.018 < I</entry> + <entry>0.2125 E'<subscript>R</subscript> ++ 0.7154 E'<subscript>G</subscript> ++ 0.0721 E'<subscript>B</subscript></entry> + <entry>219 E'<subscript>Y</subscript> + 16</entry> + <entry>224 P<subscript>B,R</subscript> + 128</entry> + </row> + <row> + <entry><constant>V4L2_COLORSPACE_BT878</constant></entry> + <entry>4</entry> + <entry>Broken Bt878 extents<footnote> + <para>The ubiquitous Bt878 video capture chip +quantizes E'<subscript>Y</subscript> to 238 levels, yielding a range +of Y' = 16 … 253, unlike Rec. 601 Y' = 16 … +235. This is not a typo in the Bt878 documentation, it has been +implemented in silicon. The chroma extents are unclear.</para> + </footnote>, <xref linkend="itu601" /></entry> + <entry>?</entry> + <entry>?</entry> + <entry>?</entry> + <entry>?</entry> + <entry>?</entry> + <entry>0.299 E'<subscript>R</subscript> ++ 0.587 E'<subscript>G</subscript> ++ 0.114 E'<subscript>B</subscript></entry> + <entry><emphasis>237</emphasis> E'<subscript>Y</subscript> + 16</entry> + <entry>224 P<subscript>B,R</subscript> + 128 (probably)</entry> + </row> + <row> + <entry><constant>V4L2_COLORSPACE_470_SYSTEM_M</constant></entry> + <entry>5</entry> + <entry>M/NTSC<footnote> + <para>No identifier exists for M/PAL which uses +the chromaticities of M/NTSC, the remaining parameters are equal to B and +G/PAL.</para> + </footnote> according to <xref linkend="itu470" />, <xref + linkend="itu601" /></entry> + <entry>x = 0.67, y = 0.33</entry> + <entry>x = 0.21, y = 0.71</entry> + <entry>x = 0.14, y = 0.08</entry> + <entry>x = 0.310, y = 0.316, Illuminant C</entry> + <entry>?</entry> + <entry>0.299 E'<subscript>R</subscript> ++ 0.587 E'<subscript>G</subscript> ++ 0.114 E'<subscript>B</subscript></entry> + <entry>219 E'<subscript>Y</subscript> + 16</entry> + <entry>224 P<subscript>B,R</subscript> + 128</entry> + </row> + <row> + <entry><constant>V4L2_COLORSPACE_470_SYSTEM_BG</constant></entry> + <entry>6</entry> + <entry>625-line PAL and SECAM systems according to <xref +linkend="itu470" />, <xref linkend="itu601" /></entry> + <entry>x = 0.64, y = 0.33</entry> + <entry>x = 0.29, y = 0.60</entry> + <entry>x = 0.15, y = 0.06</entry> + <entry>x = 0.313, y = 0.329, +Illuminant D<subscript>65</subscript></entry> + <entry>?</entry> + <entry>0.299 E'<subscript>R</subscript> ++ 0.587 E'<subscript>G</subscript> ++ 0.114 E'<subscript>B</subscript></entry> + <entry>219 E'<subscript>Y</subscript> + 16</entry> + <entry>224 P<subscript>B,R</subscript> + 128</entry> + </row> + <row> + <entry><constant>V4L2_COLORSPACE_JPEG</constant></entry> + <entry>7</entry> + <entry>JPEG Y'CbCr, see <xref linkend="jfif" />, <xref linkend="itu601" /></entry> + <entry>?</entry> + <entry>?</entry> + <entry>?</entry> + <entry>?</entry> + <entry>?</entry> + <entry>0.299 E'<subscript>R</subscript> ++ 0.587 E'<subscript>G</subscript> ++ 0.114 E'<subscript>B</subscript></entry> + <entry>256 E'<subscript>Y</subscript> + 16<footnote> + <para>Note JFIF quantizes +Y'P<subscript>B</subscript>P<subscript>R</subscript> in range [0;+1] and +[-0.5;+0.5] to <emphasis>257</emphasis> levels, however Y'CbCr signals +are still clamped to [0;255].</para> + </footnote></entry> + <entry>256 P<subscript>B,R</subscript> + 128</entry> + </row> + <row> + <entry><constant>V4L2_COLORSPACE_SRGB</constant></entry> + <entry>8</entry> + <entry>[?]</entry> + <entry>x = 0.640, y = 0.330</entry> + <entry>x = 0.300, y = 0.600</entry> + <entry>x = 0.150, y = 0.060</entry> + <entry>x = 0.3127, y = 0.3290, + Illuminant D<subscript>65</subscript></entry> + <entry>E' = 4.5 I for I ≤0.018, +1.099 I<superscript>0.45</superscript> - 0.099 for 0.018 < I</entry> + <entry spanname="spam">n/a</entry> + </row> + </tbody> + </tgroup> + </table> + </section> + + <section id="pixfmt-indexed"> + <title>Indexed Format</title> + + <para>In this format each pixel is represented by an 8 bit index +into a 256 entry ARGB palette. It is intended for <link +linkend="osd">Video Output Overlays</link> only. There are no ioctls to +access the palette, this must be done with ioctls of the Linux framebuffer API.</para> + + <table pgwide="0" frame="none"> + <title>Indexed Image Format</title> + <tgroup cols="37" align="center"> + <colspec colname="id" align="left" /> + <colspec colname="fourcc" /> + <colspec colname="bit" /> + + <colspec colnum="4" colname="b07" align="center" /> + <colspec colnum="5" colname="b06" align="center" /> + <colspec colnum="6" colname="b05" align="center" /> + <colspec colnum="7" colname="b04" align="center" /> + <colspec colnum="8" colname="b03" align="center" /> + <colspec colnum="9" colname="b02" align="center" /> + <colspec colnum="10" colname="b01" align="center" /> + <colspec colnum="11" colname="b00" align="center" /> + + <spanspec namest="b07" nameend="b00" spanname="b0" /> + <spanspec namest="b17" nameend="b10" spanname="b1" /> + <spanspec namest="b27" nameend="b20" spanname="b2" /> + <spanspec namest="b37" nameend="b30" spanname="b3" /> + <thead> + <row> + <entry>Identifier</entry> + <entry>Code</entry> + <entry> </entry> + <entry spanname="b0">Byte 0</entry> + </row> + <row> + <entry> </entry> + <entry> </entry> + <entry>Bit</entry> + <entry>7</entry> + <entry>6</entry> + <entry>5</entry> + <entry>4</entry> + <entry>3</entry> + <entry>2</entry> + <entry>1</entry> + <entry>0</entry> + </row> + </thead> + <tbody valign="top"> + <row id="V4L2-PIX-FMT-PAL8"> + <entry><constant>V4L2_PIX_FMT_PAL8</constant></entry> + <entry>'PAL8'</entry> + <entry></entry> + <entry>i<subscript>7</subscript></entry> + <entry>i<subscript>6</subscript></entry> + <entry>i<subscript>5</subscript></entry> + <entry>i<subscript>4</subscript></entry> + <entry>i<subscript>3</subscript></entry> + <entry>i<subscript>2</subscript></entry> + <entry>i<subscript>1</subscript></entry> + <entry>i<subscript>0</subscript></entry> + </row> + </tbody> + </tgroup> + </table> + </section> + + <section id="pixfmt-rgb"> + <title>RGB Formats</title> + + &sub-packed-rgb; + &sub-sbggr8; + &sub-sgbrg8; + &sub-sgrbg8; + &sub-sbggr16; + </section> + + <section id="yuv-formats"> + <title>YUV Formats</title> + + <para>YUV is the format native to TV broadcast and composite video +signals. It separates the brightness information (Y) from the color +information (U and V or Cb and Cr). The color information consists of +red and blue <emphasis>color difference</emphasis> signals, this way +the green component can be reconstructed by subtracting from the +brightness component. See <xref linkend="colorspaces" /> for conversion +examples. YUV was chosen because early television would only transmit +brightness information. To add color in a way compatible with existing +receivers a new signal carrier was added to transmit the color +difference signals. Secondary in the YUV format the U and V components +usually have lower resolution than the Y component. This is an analog +video compression technique taking advantage of a property of the +human visual system, being more sensitive to brightness +information.</para> + + &sub-packed-yuv; + &sub-grey; + &sub-y16; + &sub-yuyv; + &sub-uyvy; + &sub-yvyu; + &sub-vyuy; + &sub-y41p; + &sub-yuv420; + &sub-yuv410; + &sub-yuv422p; + &sub-yuv411p; + &sub-nv12; + &sub-nv16; + </section> + + <section> + <title>Compressed Formats</title> + + <table pgwide="1" frame="none" id="compressed-formats"> + <title>Compressed Image Formats</title> + <tgroup cols="3" align="left"> + &cs-def; + <thead> + <row> + <entry>Identifier</entry> + <entry>Code</entry> + <entry>Details</entry> + </row> + </thead> + <tbody valign="top"> + <row id="V4L2-PIX-FMT-JPEG"> + <entry><constant>V4L2_PIX_FMT_JPEG</constant></entry> + <entry>'JPEG'</entry> + <entry>TBD. See also &VIDIOC-G-JPEGCOMP;, + &VIDIOC-S-JPEGCOMP;.</entry> + </row> + <row id="V4L2-PIX-FMT-MPEG"> + <entry><constant>V4L2_PIX_FMT_MPEG</constant></entry> + <entry>'MPEG'</entry> + <entry>MPEG stream. The actual format is determined by +extended control <constant>V4L2_CID_MPEG_STREAM_TYPE</constant>, see +<xref linkend="mpeg-control-id" />.</entry> + </row> + </tbody> + </tgroup> + </table> + </section> + + <section id="pixfmt-reserved"> + <title>Reserved Format Identifiers</title> + + <para>These formats are not defined by this specification, they +are just listed for reference and to avoid naming conflicts. If you +want to register your own format, send an e-mail to the linux-media mailing +list &v4l-ml; for inclusion in the <filename>videodev2.h</filename> +file. If you want to share your format with other developers add a +link to your documentation and send a copy to the linux-media mailing list +for inclusion in this section. If you think your format should be listed +in a standard format section please make a proposal on the linux-media mailing +list.</para> + + <table pgwide="1" frame="none" id="reserved-formats"> + <title>Reserved Image Formats</title> + <tgroup cols="3" align="left"> + &cs-def; + <thead> + <row> + <entry>Identifier</entry> + <entry>Code</entry> + <entry>Details</entry> + </row> + </thead> + <tbody valign="top"> + <row id="V4L2-PIX-FMT-DV"> + <entry><constant>V4L2_PIX_FMT_DV</constant></entry> + <entry>'dvsd'</entry> + <entry>unknown</entry> + </row> + <row id="V4L2-PIX-FMT-ET61X251"> + <entry><constant>V4L2_PIX_FMT_ET61X251</constant></entry> + <entry>'E625'</entry> + <entry>Compressed format of the ET61X251 driver.</entry> + </row> + <row id="V4L2-PIX-FMT-HI240"> + <entry><constant>V4L2_PIX_FMT_HI240</constant></entry> + <entry>'HI24'</entry> + <entry><para>8 bit RGB format used by the BTTV driver.</para></entry> + </row> + <row id="V4L2-PIX-FMT-HM12"> + <entry><constant>V4L2_PIX_FMT_HM12</constant></entry> + <entry>'HM12'</entry> + <entry><para>YUV 4:2:0 format used by the +IVTV driver, <ulink url="http://www.ivtvdriver.org/"> +http://www.ivtvdriver.org/</ulink></para><para>The format is documented in the +kernel sources in the file <filename>Documentation/video4linux/cx2341x/README.hm12</filename> +</para></entry> + </row> + <row id="V4L2-PIX-FMT-SPCA501"> + <entry><constant>V4L2_PIX_FMT_SPCA501</constant></entry> + <entry>'S501'</entry> + <entry>YUYV per line used by the gspca driver.</entry> + </row> + <row id="V4L2-PIX-FMT-SPCA505"> + <entry><constant>V4L2_PIX_FMT_SPCA505</constant></entry> + <entry>'S505'</entry> + <entry>YYUV per line used by the gspca driver.</entry> + </row> + <row id="V4L2-PIX-FMT-SPCA508"> + <entry><constant>V4L2_PIX_FMT_SPCA508</constant></entry> + <entry>'S508'</entry> + <entry>YUVY per line used by the gspca driver.</entry> + </row> + <row id="V4L2-PIX-FMT-SPCA561"> + <entry><constant>V4L2_PIX_FMT_SPCA561</constant></entry> + <entry>'S561'</entry> + <entry>Compressed GBRG Bayer format used by the gspca driver.</entry> + </row> + <row id="V4L2-PIX-FMT-SGRBG10"> + <entry><constant>V4L2_PIX_FMT_SGRBG10</constant></entry> + <entry>'DA10'</entry> + <entry>10 bit raw Bayer, expanded to 16 bits.</entry> + </row> + <row id="V4L2-PIX-FMT-SGRBG10DPCM8"> + <entry><constant>V4L2_PIX_FMT_SGRBG10DPCM8</constant></entry> + <entry>'DB10'</entry> + <entry>10 bit raw Bayer DPCM compressed to 8 bits.</entry> + </row> + <row id="V4L2-PIX-FMT-PAC207"> + <entry><constant>V4L2_PIX_FMT_PAC207</constant></entry> + <entry>'P207'</entry> + <entry>Compressed BGGR Bayer format used by the gspca driver.</entry> + </row> + <row id="V4L2-PIX-FMT-MR97310A"> + <entry><constant>V4L2_PIX_FMT_MR97310A</constant></entry> + <entry>'M310'</entry> + <entry>Compressed BGGR Bayer format used by the gspca driver.</entry> + </row> + <row id="V4L2-PIX-FMT-OV511"> + <entry><constant>V4L2_PIX_FMT_OV511</constant></entry> + <entry>'O511'</entry> + <entry>OV511 JPEG format used by the gspca driver.</entry> + </row> + <row id="V4L2-PIX-FMT-OV518"> + <entry><constant>V4L2_PIX_FMT_OV518</constant></entry> + <entry>'O518'</entry> + <entry>OV518 JPEG format used by the gspca driver.</entry> + </row> + <row id="V4L2-PIX-FMT-PJPG"> + <entry><constant>V4L2_PIX_FMT_PJPG</constant></entry> + <entry>'PJPG'</entry> + <entry>Pixart 73xx JPEG format used by the gspca driver.</entry> + </row> + <row id="V4L2-PIX-FMT-SQ905C"> + <entry><constant>V4L2_PIX_FMT_SQ905C</constant></entry> + <entry>'905C'</entry> + <entry>Compressed RGGB bayer format used by the gspca driver.</entry> + </row> + <row id="V4L2-PIX-FMT-MJPEG"> + <entry><constant>V4L2_PIX_FMT_MJPEG</constant></entry> + <entry>'MJPG'</entry> + <entry>Compressed format used by the Zoran driver</entry> + </row> + <row id="V4L2-PIX-FMT-PWC1"> + <entry><constant>V4L2_PIX_FMT_PWC1</constant></entry> + <entry>'PWC1'</entry> + <entry>Compressed format of the PWC driver.</entry> + </row> + <row id="V4L2-PIX-FMT-PWC2"> + <entry><constant>V4L2_PIX_FMT_PWC2</constant></entry> + <entry>'PWC2'</entry> + <entry>Compressed format of the PWC driver.</entry> + </row> + <row id="V4L2-PIX-FMT-SN9C10X"> + <entry><constant>V4L2_PIX_FMT_SN9C10X</constant></entry> + <entry>'S910'</entry> + <entry>Compressed format of the SN9C102 driver.</entry> + </row> + <row id="V4L2-PIX-FMT-SN9C20X-I420"> + <entry><constant>V4L2_PIX_FMT_SN9C20X_I420</constant></entry> + <entry>'S920'</entry> + <entry>YUV 4:2:0 format of the gspca sn9c20x driver.</entry> + </row> + <row id="V4L2-PIX-FMT-STV0680"> + <entry><constant>V4L2_PIX_FMT_STV0680</constant></entry> + <entry>'S680'</entry> + <entry>Bayer format of the gspca stv0680 driver.</entry> + </row> + <row id="V4L2-PIX-FMT-WNVA"> + <entry><constant>V4L2_PIX_FMT_WNVA</constant></entry> + <entry>'WNVA'</entry> + <entry><para>Used by the Winnov Videum driver, <ulink +url="http://www.thedirks.org/winnov/"> +http://www.thedirks.org/winnov/</ulink></para></entry> + </row> + <row id="V4L2-PIX-FMT-TM6000"> + <entry><constant>V4L2_PIX_FMT_TM6000</constant></entry> + <entry>'TM60'</entry> + <entry><para>Used by Trident tm6000</para></entry> + </row> + <row id="V4L2-PIX-FMT-YYUV"> + <entry><constant>V4L2_PIX_FMT_YYUV</constant></entry> + <entry>'YYUV'</entry> + <entry>unknown</entry> + </row> + </tbody> + </tgroup> + </table> + </section> + + <!-- +Local Variables: +mode: sgml +sgml-parent-document: "v4l2.sgml" +indent-tabs-mode: nil +End: + --> diff --git a/Documentation/DocBook/v4l/remote_controllers.xml b/Documentation/DocBook/v4l/remote_controllers.xml new file mode 100644 index 000000000000..73f5eab091f4 --- /dev/null +++ b/Documentation/DocBook/v4l/remote_controllers.xml @@ -0,0 +1,175 @@ +<title>Remote Controllers</title> +<section id="Remote_controllers_Intro"> +<title>Introduction</title> + +<para>Currently, most analog and digital devices have a Infrared input for remote controllers. Each +manufacturer has their own type of control. It is not rare for the same manufacturer to ship different +types of controls, depending on the device.</para> +<para>Unfortunately, for several years, there was no effort to create uniform IR keycodes for +different devices. This caused the same IR keyname to be mapped completely differently on +different IR devices. This resulted that the same IR keyname to be mapped completely different on +different IR's. Due to that, V4L2 API now specifies a standard for mapping Media keys on IR.</para> +<para>This standard should be used by both V4L/DVB drivers and userspace applications</para> +<para>The modules register the remote as keyboard within the linux input layer. This means that the IR key strokes will look like normal keyboard key strokes (if CONFIG_INPUT_KEYBOARD is enabled). Using the event devices (CONFIG_INPUT_EVDEV) it is possible for applications to access the remote via /dev/input/event devices.</para> + +<table pgwide="1" frame="none" id="rc_standard_keymap"> +<title>IR default keymapping</title> +<tgroup cols="3"> +&cs-str; +<tbody valign="top"> +<row> +<entry>Key code</entry> +<entry>Meaning</entry> +<entry>Key examples on IR</entry> +</row> + +<row><entry><emphasis role="bold">Numeric keys</emphasis></entry></row> + +<row><entry><constant>KEY_0</constant></entry><entry>Keyboard digit 0</entry><entry>0</entry></row> +<row><entry><constant>KEY_1</constant></entry><entry>Keyboard digit 1</entry><entry>1</entry></row> +<row><entry><constant>KEY_2</constant></entry><entry>Keyboard digit 2</entry><entry>2</entry></row> +<row><entry><constant>KEY_3</constant></entry><entry>Keyboard digit 3</entry><entry>3</entry></row> +<row><entry><constant>KEY_4</constant></entry><entry>Keyboard digit 4</entry><entry>4</entry></row> +<row><entry><constant>KEY_5</constant></entry><entry>Keyboard digit 5</entry><entry>5</entry></row> +<row><entry><constant>KEY_6</constant></entry><entry>Keyboard digit 6</entry><entry>6</entry></row> +<row><entry><constant>KEY_7</constant></entry><entry>Keyboard digit 7</entry><entry>7</entry></row> +<row><entry><constant>KEY_8</constant></entry><entry>Keyboard digit 8</entry><entry>8</entry></row> +<row><entry><constant>KEY_9</constant></entry><entry>Keyboard digit 9</entry><entry>9</entry></row> + +<row><entry><emphasis role="bold">Movie play control</emphasis></entry></row> + +<row><entry><constant>KEY_FORWARD</constant></entry><entry>Instantly advance in time</entry><entry>>> / FORWARD</entry></row> +<row><entry><constant>KEY_BACK</constant></entry><entry>Instantly go back in time</entry><entry><<< / BACK</entry></row> +<row><entry><constant>KEY_FASTFORWARD</constant></entry><entry>Play movie faster</entry><entry>>>> / FORWARD</entry></row> +<row><entry><constant>KEY_REWIND</constant></entry><entry>Play movie back</entry><entry>REWIND / BACKWARD</entry></row> +<row><entry><constant>KEY_NEXT</constant></entry><entry>Select next chapter / sub-chapter / interval</entry><entry>NEXT / SKIP</entry></row> +<row><entry><constant>KEY_PREVIOUS</constant></entry><entry>Select previous chapter / sub-chapter / interval</entry><entry><< / PREV / PREVIOUS</entry></row> +<row><entry><constant>KEY_AGAIN</constant></entry><entry>Repeat the video or a video interval</entry><entry>REPEAT / LOOP / RECALL</entry></row> +<row><entry><constant>KEY_PAUSE</constant></entry><entry>Pause sroweam</entry><entry>PAUSE / FREEZE</entry></row> +<row><entry><constant>KEY_PLAY</constant></entry><entry>Play movie at the normal timeshift</entry><entry>NORMAL TIMESHIFT / LIVE / ></entry></row> +<row><entry><constant>KEY_PLAYPAUSE</constant></entry><entry>Alternate between play and pause</entry><entry>PLAY / PAUSE</entry></row> +<row><entry><constant>KEY_STOP</constant></entry><entry>Stop sroweam</entry><entry>STOP</entry></row> +<row><entry><constant>KEY_RECORD</constant></entry><entry>Start/stop recording sroweam</entry><entry>CAPTURE / REC / RECORD/PAUSE</entry></row> +<row><entry><constant>KEY_CAMERA</constant></entry><entry>Take a picture of the image</entry><entry>CAMERA ICON / CAPTURE / SNAPSHOT</entry></row> +<row><entry><constant>KEY_SHUFFLE</constant></entry><entry>Enable shuffle mode</entry><entry>SHUFFLE</entry></row> +<row><entry><constant>KEY_TIME</constant></entry><entry>Activate time shift mode</entry><entry>TIME SHIFT</entry></row> +<row><entry><constant>KEY_TITLE</constant></entry><entry>Allow changing the chapter</entry><entry>CHAPTER</entry></row> +<row><entry><constant>KEY_SUBTITLE</constant></entry><entry>Allow changing the subtitle</entry><entry>SUBTITLE</entry></row> + +<row><entry><emphasis role="bold">Image control</emphasis></entry></row> + +<row><entry><constant>KEY_BRIGHTNESSDOWN</constant></entry><entry>Decrease Brightness</entry><entry>BRIGHTNESS DECREASE</entry></row> +<row><entry><constant>KEY_BRIGHTNESSUP</constant></entry><entry>Increase Brightness</entry><entry>BRIGHTNESS INCREASE</entry></row> + +<row><entry><constant>KEY_ANGLE</constant></entry><entry>Switch video camera angle (on videos with more than one angle stored)</entry><entry>ANGLE / SWAP</entry></row> +<row><entry><constant>KEY_EPG</constant></entry><entry>Open the Elecrowonic Play Guide (EPG)</entry><entry>EPG / GUIDE</entry></row> +<row><entry><constant>KEY_TEXT</constant></entry><entry>Activate/change closed caption mode</entry><entry>CLOSED CAPTION/TELETEXT / DVD TEXT / TELETEXT / TTX</entry></row> + +<row><entry><emphasis role="bold">Audio control</emphasis></entry></row> + +<row><entry><constant>KEY_AUDIO</constant></entry><entry>Change audio source</entry><entry>AUDIO SOURCE / AUDIO / MUSIC</entry></row> +<row><entry><constant>KEY_MUTE</constant></entry><entry>Mute/unmute audio</entry><entry>MUTE / DEMUTE / UNMUTE</entry></row> +<row><entry><constant>KEY_VOLUMEDOWN</constant></entry><entry>Decrease volume</entry><entry>VOLUME- / VOLUME DOWN</entry></row> +<row><entry><constant>KEY_VOLUMEUP</constant></entry><entry>Increase volume</entry><entry>VOLUME+ / VOLUME UP</entry></row> +<row><entry><constant>KEY_MODE</constant></entry><entry>Change sound mode</entry><entry>MONO/STEREO</entry></row> +<row><entry><constant>KEY_LANGUAGE</constant></entry><entry>Select Language</entry><entry>1ST / 2ND LANGUAGE / DVD LANG / MTS/SAP / MTS SEL</entry></row> + +<row><entry><emphasis role="bold">Channel control</emphasis></entry></row> + +<row><entry><constant>KEY_CHANNEL</constant></entry><entry>Go to the next favorite channel</entry><entry>ALT / CHANNEL / CH SURFING / SURF / FAV</entry></row> +<row><entry><constant>KEY_CHANNELDOWN</constant></entry><entry>Decrease channel sequencially</entry><entry>CHANNEL - / CHANNEL DOWN / DOWN</entry></row> +<row><entry><constant>KEY_CHANNELUP</constant></entry><entry>Increase channel sequencially</entry><entry>CHANNEL + / CHANNEL UP / UP</entry></row> +<row><entry><constant>KEY_DIGITS</constant></entry><entry>Use more than one digit for channel</entry><entry>PLUS / 100/ 1xx / xxx / -/-- / Single Double Triple Digit</entry></row> +<row><entry><constant>KEY_SEARCH</constant></entry><entry>Start channel autoscan</entry><entry>SCAN / AUTOSCAN</entry></row> + +<row><entry><emphasis role="bold">Colored keys</emphasis></entry></row> + +<row><entry><constant>KEY_BLUE</constant></entry><entry>IR Blue key</entry><entry>BLUE</entry></row> +<row><entry><constant>KEY_GREEN</constant></entry><entry>IR Green Key</entry><entry>GREEN</entry></row> +<row><entry><constant>KEY_RED</constant></entry><entry>IR Red key</entry><entry>RED</entry></row> +<row><entry><constant>KEY_YELLOW</constant></entry><entry>IR Yellow key</entry><entry> YELLOW</entry></row> + +<row><entry><emphasis role="bold">Media selection</emphasis></entry></row> + +<row><entry><constant>KEY_CD</constant></entry><entry>Change input source to Compact Disc</entry><entry>CD</entry></row> +<row><entry><constant>KEY_DVD</constant></entry><entry>Change input to DVD</entry><entry>DVD / DVD MENU</entry></row> +<row><entry><constant>KEY_EJECTCLOSECD</constant></entry><entry>Open/close the CD/DVD player</entry><entry>-> ) / CLOSE / OPEN</entry></row> + +<row><entry><constant>KEY_MEDIA</constant></entry><entry>Turn on/off Media application</entry><entry>PC/TV / TURN ON/OFF APP</entry></row> +<row><entry><constant>KEY_PC</constant></entry><entry>Selects from TV to PC</entry><entry>PC</entry></row> +<row><entry><constant>KEY_RADIO</constant></entry><entry>Put into AM/FM radio mode</entry><entry>RADIO / TV/FM / TV/RADIO / FM / FM/RADIO</entry></row> +<row><entry><constant>KEY_TV</constant></entry><entry>Select tv mode</entry><entry>TV / LIVE TV</entry></row> +<row><entry><constant>KEY_TV2</constant></entry><entry>Select Cable mode</entry><entry>AIR/CBL</entry></row> +<row><entry><constant>KEY_VCR</constant></entry><entry>Select VCR mode</entry><entry>VCR MODE / DTR</entry></row> +<row><entry><constant>KEY_VIDEO</constant></entry><entry>Alternate between input modes</entry><entry>SOURCE / SELECT / DISPLAY / SWITCH INPUTS / VIDEO</entry></row> + +<row><entry><emphasis role="bold">Power control</emphasis></entry></row> + +<row><entry><constant>KEY_POWER</constant></entry><entry>Turn on/off computer</entry><entry>SYSTEM POWER / COMPUTER POWER</entry></row> +<row><entry><constant>KEY_POWER2</constant></entry><entry>Turn on/off application</entry><entry>TV ON/OFF / POWER</entry></row> +<row><entry><constant>KEY_SLEEP</constant></entry><entry>Activate sleep timer</entry><entry>SLEEP / SLEEP TIMER</entry></row> +<row><entry><constant>KEY_SUSPEND</constant></entry><entry>Put computer into suspend mode</entry><entry>STANDBY / SUSPEND</entry></row> + +<row><entry><emphasis role="bold">Window control</emphasis></entry></row> + +<row><entry><constant>KEY_CLEAR</constant></entry><entry>Stop sroweam and return to default input video/audio</entry><entry>CLEAR / RESET / BOSS KEY</entry></row> +<row><entry><constant>KEY_CYCLEWINDOWS</constant></entry><entry>Minimize windows and move to the next one</entry><entry>ALT-TAB / MINIMIZE / DESKTOP</entry></row> +<row><entry><constant>KEY_FAVORITES</constant></entry><entry>Open the favorites sroweam window</entry><entry>TV WALL / Favorites</entry></row> +<row><entry><constant>KEY_MENU</constant></entry><entry>Call application menu</entry><entry>2ND CONTROLS (USA: MENU) / DVD/MENU / SHOW/HIDE CTRL</entry></row> +<row><entry><constant>KEY_NEW</constant></entry><entry>Open/Close Picture in Picture</entry><entry>PIP</entry></row> +<row><entry><constant>KEY_OK</constant></entry><entry>Send a confirmation code to application</entry><entry>OK / ENTER / RETURN</entry></row> +<row><entry><constant>KEY_SCREEN</constant></entry><entry>Select screen aspect ratio</entry><entry>4:3 16:9 SELECT</entry></row> +<row><entry><constant>KEY_ZOOM</constant></entry><entry>Put device into zoom/full screen mode</entry><entry>ZOOM / FULL SCREEN / ZOOM+ / HIDE PANNEL / SWITCH</entry></row> + +<row><entry><emphasis role="bold">Navigation keys</emphasis></entry></row> + +<row><entry><constant>KEY_ESC</constant></entry><entry>Cancel current operation</entry><entry>CANCEL / BACK</entry></row> +<row><entry><constant>KEY_HELP</constant></entry><entry>Open a Help window</entry><entry>HELP</entry></row> +<row><entry><constant>KEY_HOMEPAGE</constant></entry><entry>Navigate to Homepage</entry><entry>HOME</entry></row> +<row><entry><constant>KEY_INFO</constant></entry><entry>Open On Screen Display</entry><entry>DISPLAY INFORMATION / OSD</entry></row> +<row><entry><constant>KEY_WWW</constant></entry><entry>Open the default browser</entry><entry>WEB</entry></row> +<row><entry><constant>KEY_UP</constant></entry><entry>Up key</entry><entry>UP</entry></row> +<row><entry><constant>KEY_DOWN</constant></entry><entry>Down key</entry><entry>DOWN</entry></row> +<row><entry><constant>KEY_LEFT</constant></entry><entry>Left key</entry><entry>LEFT</entry></row> +<row><entry><constant>KEY_RIGHT</constant></entry><entry>Right key</entry><entry>RIGHT</entry></row> + +<row><entry><emphasis role="bold">Miscelaneous keys</emphasis></entry></row> + +<row><entry><constant>KEY_DOT</constant></entry><entry>Return a dot</entry><entry>.</entry></row> +<row><entry><constant>KEY_FN</constant></entry><entry>Select a function</entry><entry>FUNCTION</entry></row> + +</tbody> +</tgroup> +</table> + +<para>It should be noticed that, sometimes, there some fundamental missing keys at some cheaper IR's. Due to that, it is recommended to:</para> + +<table pgwide="1" frame="none" id="rc_keymap_notes"> +<title>Notes</title> +<tgroup cols="1"> +&cs-str; +<tbody valign="top"> +<row> +<entry>On simpler IR's, without separate channel keys, you need to map UP as <constant>KEY_CHANNELUP</constant></entry> +</row><row> +<entry>On simpler IR's, without separate channel keys, you need to map DOWN as <constant>KEY_CHANNELDOWN</constant></entry> +</row><row> +<entry>On simpler IR's, without separate volume keys, you need to map LEFT as <constant>KEY_VOLUMEDOWN</constant></entry> +</row><row> +<entry>On simpler IR's, without separate volume keys, you need to map RIGHT as <constant>KEY_VOLUMEUP</constant></entry> +</row> +</tbody> +</tgroup> +</table> + +</section> + +<section id="Remote_controllers_table_change"> +<title>Changing default Remote Controller mappings</title> +<para>The event interface provides two ioctls to be used against +the /dev/input/event device, to allow changing the default +keymapping.</para> + +<para>This program demonstrates how to replace the keymap tables.</para> +&sub-keytable-c; +</section> diff --git a/Documentation/DocBook/v4l/v4l2.xml b/Documentation/DocBook/v4l/v4l2.xml new file mode 100644 index 000000000000..060105af49e5 --- /dev/null +++ b/Documentation/DocBook/v4l/v4l2.xml @@ -0,0 +1,501 @@ + <partinfo> + <authorgroup> + <author> + <firstname>Michael</firstname> + <surname>Schimek</surname> + <othername role="mi">H</othername> + <affiliation> + <address> + <email>mschimek@gmx.at</email> + </address> + </affiliation> + </author> + + <author> + <firstname>Bill</firstname> + <surname>Dirks</surname> + <!-- Commented until Bill opts in to be spammed. + <affiliation> + <address> + <email>bill@thedirks.org</email> + </address> + </affiliation> --> + <contrib>Original author of the V4L2 API and +documentation.</contrib> + </author> + + <author> + <firstname>Hans</firstname> + <surname>Verkuil</surname> + <contrib>Designed and documented the VIDIOC_LOG_STATUS ioctl, +the extended control ioctls and major parts of the sliced VBI +API.</contrib> + <affiliation> + <address> + <email>hverkuil@xs4all.nl</email> + </address> + </affiliation> + </author> + + <author> + <firstname>Martin</firstname> + <surname>Rubli</surname> + <!-- + <affiliation> + <address> + <email>martin_rubli@logitech.com</email> + </address> + </affiliation> --> + <contrib>Designed and documented the VIDIOC_ENUM_FRAMESIZES +and VIDIOC_ENUM_FRAMEINTERVALS ioctls.</contrib> + </author> + + <author> + <firstname>Andy</firstname> + <surname>Walls</surname> + <contrib>Documented the fielded V4L2_MPEG_STREAM_VBI_FMT_IVTV +MPEG stream embedded, sliced VBI data format in this specification. +</contrib> + <affiliation> + <address> + <email>awalls@radix.net</email> + </address> + </affiliation> + </author> + + <author> + <firstname>Mauro</firstname> + <surname>Carvalho Chehab</surname> + <contrib>Documented libv4l, designed and added v4l2grab example, +Remote Controller chapter.</contrib> + <affiliation> + <address> + <email>mchehab@redhat.com</email> + </address> + </affiliation> + </author> + + <author> + <firstname>Muralidharan</firstname> + <surname>Karicheri</surname> + <contrib>Documented the Digital Video timings API.</contrib> + <affiliation> + <address> + <email>m-karicheri2@ti.com</email> + </address> + </affiliation> + </author> + </authorgroup> + + <copyright> + <year>1999</year> + <year>2000</year> + <year>2001</year> + <year>2002</year> + <year>2003</year> + <year>2004</year> + <year>2005</year> + <year>2006</year> + <year>2007</year> + <year>2008</year> + <year>2009</year> + <holder>Bill Dirks, Michael H. Schimek, Hans Verkuil, Martin +Rubli, Andy Walls, Muralidharan Karicheri, Mauro Carvalho Chehab</holder> + </copyright> + <legalnotice> + <para>Except when explicitly stated as GPL, programming examples within + this part can be used and distributed without restrictions.</para> + </legalnotice> + <revhistory> + <!-- Put document revisions here, newest first. --> + <!-- API revisions (changes and additions of defines, enums, +structs, ioctls) must be noted in more detail in the history chapter +(compat.sgml), along with the possible impact on existing drivers and +applications. --> + + <revision> + <revnumber>2.6.33</revnumber> + <date>2009-12-03</date> + <authorinitials>mk</authorinitials> + <revremark>Added documentation for the Digital Video timings API.</revremark> + </revision> + + <revision> + <revnumber>2.6.32</revnumber> + <date>2009-08-31</date> + <authorinitials>mcc</authorinitials> + <revremark>Now, revisions will match the kernel version where +the V4L2 API changes will be used by the Linux Kernel. +Also added Remote Controller chapter.</revremark> + </revision> + + <revision> + <revnumber>0.29</revnumber> + <date>2009-08-26</date> + <authorinitials>ev</authorinitials> + <revremark>Added documentation for string controls and for FM Transmitter controls.</revremark> + </revision> + + <revision> + <revnumber>0.28</revnumber> + <date>2009-08-26</date> + <authorinitials>gl</authorinitials> + <revremark>Added V4L2_CID_BAND_STOP_FILTER documentation.</revremark> + </revision> + + <revision> + <revnumber>0.27</revnumber> + <date>2009-08-15</date> + <authorinitials>mcc</authorinitials> + <revremark>Added libv4l and Remote Controller documentation; +added v4l2grab and keytable application examples.</revremark> + </revision> + + <revision> + <revnumber>0.26</revnumber> + <date>2009-07-23</date> + <authorinitials>hv</authorinitials> + <revremark>Finalized the RDS capture API. Added modulator and RDS encoder +capabilities. Added support for string controls.</revremark> + </revision> + + <revision> + <revnumber>0.25</revnumber> + <date>2009-01-18</date> + <authorinitials>hv</authorinitials> + <revremark>Added pixel formats VYUY, NV16 and NV61, and changed +the debug ioctls VIDIOC_DBG_G/S_REGISTER and VIDIOC_DBG_G_CHIP_IDENT. +Added camera controls V4L2_CID_ZOOM_ABSOLUTE, V4L2_CID_ZOOM_RELATIVE, +V4L2_CID_ZOOM_CONTINUOUS and V4L2_CID_PRIVACY.</revremark> + </revision> + + <revision> + <revnumber>0.24</revnumber> + <date>2008-03-04</date> + <authorinitials>mhs</authorinitials> + <revremark>Added pixel formats Y16 and SBGGR16, new controls +and a camera controls class. Removed VIDIOC_G/S_MPEGCOMP.</revremark> + </revision> + + <revision> + <revnumber>0.23</revnumber> + <date>2007-08-30</date> + <authorinitials>mhs</authorinitials> + <revremark>Fixed a typo in VIDIOC_DBG_G/S_REGISTER. +Clarified the byte order of packed pixel formats.</revremark> + </revision> + + <revision> + <revnumber>0.22</revnumber> + <date>2007-08-29</date> + <authorinitials>mhs</authorinitials> + <revremark>Added the Video Output Overlay interface, new MPEG +controls, V4L2_FIELD_INTERLACED_TB and V4L2_FIELD_INTERLACED_BT, +VIDIOC_DBG_G/S_REGISTER, VIDIOC_(TRY_)ENCODER_CMD, +VIDIOC_G_CHIP_IDENT, VIDIOC_G_ENC_INDEX, new pixel formats. +Clarifications in the cropping chapter, about RGB pixel formats, the +mmap(), poll(), select(), read() and write() functions. Typographical +fixes.</revremark> + </revision> + + <revision> + <revnumber>0.21</revnumber> + <date>2006-12-19</date> + <authorinitials>mhs</authorinitials> + <revremark>Fixed a link in the VIDIOC_G_EXT_CTRLS section.</revremark> + </revision> + + <revision> + <revnumber>0.20</revnumber> + <date>2006-11-24</date> + <authorinitials>mhs</authorinitials> + <revremark>Clarified the purpose of the audioset field in +struct v4l2_input and v4l2_output.</revremark> + </revision> + + <revision> + <revnumber>0.19</revnumber> + <date>2006-10-19</date> + <authorinitials>mhs</authorinitials> + <revremark>Documented V4L2_PIX_FMT_RGB444.</revremark> + </revision> + + <revision> + <revnumber>0.18</revnumber> + <date>2006-10-18</date> + <authorinitials>mhs</authorinitials> + <revremark>Added the description of extended controls by Hans +Verkuil. Linked V4L2_PIX_FMT_MPEG to V4L2_CID_MPEG_STREAM_TYPE.</revremark> + </revision> + + <revision> + <revnumber>0.17</revnumber> + <date>2006-10-12</date> + <authorinitials>mhs</authorinitials> + <revremark>Corrected V4L2_PIX_FMT_HM12 description.</revremark> + </revision> + + <revision> + <revnumber>0.16</revnumber> + <date>2006-10-08</date> + <authorinitials>mhs</authorinitials> + <revremark>VIDIOC_ENUM_FRAMESIZES and +VIDIOC_ENUM_FRAMEINTERVALS are now part of the API.</revremark> + </revision> + + <revision> + <revnumber>0.15</revnumber> + <date>2006-09-23</date> + <authorinitials>mhs</authorinitials> + <revremark>Cleaned up the bibliography, added BT.653 and +BT.1119. capture.c/start_capturing() for user pointer I/O did not +initialize the buffer index. Documented the V4L MPEG and MJPEG +VID_TYPEs and V4L2_PIX_FMT_SBGGR8. Updated the list of reserved pixel +formats. See the history chapter for API changes.</revremark> + </revision> + + <revision> + <revnumber>0.14</revnumber> + <date>2006-09-14</date> + <authorinitials>mr</authorinitials> + <revremark>Added VIDIOC_ENUM_FRAMESIZES and +VIDIOC_ENUM_FRAMEINTERVALS proposal for frame format enumeration of +digital devices.</revremark> + </revision> + + <revision> + <revnumber>0.13</revnumber> + <date>2006-04-07</date> + <authorinitials>mhs</authorinitials> + <revremark>Corrected the description of struct v4l2_window +clips. New V4L2_STD_ and V4L2_TUNER_MODE_LANG1_LANG2 +defines.</revremark> + </revision> + + <revision> + <revnumber>0.12</revnumber> + <date>2006-02-03</date> + <authorinitials>mhs</authorinitials> + <revremark>Corrected the description of struct +v4l2_captureparm and v4l2_outputparm.</revremark> + </revision> + + <revision> + <revnumber>0.11</revnumber> + <date>2006-01-27</date> + <authorinitials>mhs</authorinitials> + <revremark>Improved the description of struct +v4l2_tuner.</revremark> + </revision> + + <revision> + <revnumber>0.10</revnumber> + <date>2006-01-10</date> + <authorinitials>mhs</authorinitials> + <revremark>VIDIOC_G_INPUT and VIDIOC_S_PARM +clarifications.</revremark> + </revision> + + <revision> + <revnumber>0.9</revnumber> + <date>2005-11-27</date> + <authorinitials>mhs</authorinitials> + <revremark>Improved the 525 line numbering diagram. Hans +Verkuil and I rewrote the sliced VBI section. He also contributed a +VIDIOC_LOG_STATUS page. Fixed VIDIOC_S_STD call in the video standard +selection example. Various updates.</revremark> + </revision> + + <revision> + <revnumber>0.8</revnumber> + <date>2004-10-04</date> + <authorinitials>mhs</authorinitials> + <revremark>Somehow a piece of junk slipped into the capture +example, removed.</revremark> + </revision> + + <revision> + <revnumber>0.7</revnumber> + <date>2004-09-19</date> + <authorinitials>mhs</authorinitials> + <revremark>Fixed video standard selection, control +enumeration, downscaling and aspect example. Added read and user +pointer i/o to video capture example.</revremark> + </revision> + + <revision> + <revnumber>0.6</revnumber> + <date>2004-08-01</date> + <authorinitials>mhs</authorinitials> + <revremark>v4l2_buffer changes, added video capture example, +various corrections.</revremark> + </revision> + + <revision> + <revnumber>0.5</revnumber> + <date>2003-11-05</date> + <authorinitials>mhs</authorinitials> + <revremark>Pixel format erratum.</revremark> + </revision> + + <revision> + <revnumber>0.4</revnumber> + <date>2003-09-17</date> + <authorinitials>mhs</authorinitials> + <revremark>Corrected source and Makefile to generate a PDF. +SGML fixes. Added latest API changes. Closed gaps in the history +chapter.</revremark> + </revision> + + <revision> + <revnumber>0.3</revnumber> + <date>2003-02-05</date> + <authorinitials>mhs</authorinitials> + <revremark>Another draft, more corrections.</revremark> + </revision> + + <revision> + <revnumber>0.2</revnumber> + <date>2003-01-15</date> + <authorinitials>mhs</authorinitials> + <revremark>Second draft, with corrections pointed out by Gerd +Knorr.</revremark> + </revision> + + <revision> + <revnumber>0.1</revnumber> + <date>2002-12-01</date> + <authorinitials>mhs</authorinitials> + <revremark>First draft, based on documentation by Bill Dirks +and discussions on the V4L mailing list.</revremark> + </revision> + </revhistory> +</partinfo> + +<title>Video for Linux Two API Specification</title> + <subtitle>Revision 2.6.33</subtitle> + + <chapter id="common"> + &sub-common; + </chapter> + + <chapter id="pixfmt"> + &sub-pixfmt; + </chapter> + + <chapter id="io"> + &sub-io; + </chapter> + + <chapter id="devices"> + <title>Interfaces</title> + + <section id="capture"> &sub-dev-capture; </section> + <section id="overlay"> &sub-dev-overlay; </section> + <section id="output"> &sub-dev-output; </section> + <section id="osd"> &sub-dev-osd; </section> + <section id="codec"> &sub-dev-codec; </section> + <section id="effect"> &sub-dev-effect; </section> + <section id="raw-vbi"> &sub-dev-raw-vbi; </section> + <section id="sliced"> &sub-dev-sliced-vbi; </section> + <section id="ttx"> &sub-dev-teletext; </section> + <section id="radio"> &sub-dev-radio; </section> + <section id="rds"> &sub-dev-rds; </section> + </chapter> + + <chapter id="driver"> + &sub-driver; + </chapter> + + <chapter id="libv4l"> + &sub-libv4l; + </chapter> + + <chapter id="compat"> + &sub-compat; + </chapter> + + <appendix id="user-func"> + <title>Function Reference</title> + + <!-- Keep this alphabetically sorted. --> + + &sub-close; + &sub-ioctl; + <!-- All ioctls go here. --> + &sub-cropcap; + &sub-dbg-g-chip-ident; + &sub-dbg-g-register; + &sub-encoder-cmd; + &sub-enumaudio; + &sub-enumaudioout; + &sub-enum-dv-presets; + &sub-enum-fmt; + &sub-enum-framesizes; + &sub-enum-frameintervals; + &sub-enuminput; + &sub-enumoutput; + &sub-enumstd; + &sub-g-audio; + &sub-g-audioout; + &sub-g-crop; + &sub-g-ctrl; + &sub-g-dv-preset; + &sub-g-dv-timings; + &sub-g-enc-index; + &sub-g-ext-ctrls; + &sub-g-fbuf; + &sub-g-fmt; + &sub-g-frequency; + &sub-g-input; + &sub-g-jpegcomp; + &sub-g-modulator; + &sub-g-output; + &sub-g-parm; + &sub-g-priority; + &sub-g-sliced-vbi-cap; + &sub-g-std; + &sub-g-tuner; + &sub-log-status; + &sub-overlay; + &sub-qbuf; + &sub-querybuf; + &sub-querycap; + &sub-queryctrl; + &sub-query-dv-preset; + &sub-querystd; + &sub-reqbufs; + &sub-s-hw-freq-seek; + &sub-streamon; + <!-- End of ioctls. --> + &sub-mmap; + &sub-munmap; + &sub-open; + &sub-poll; + &sub-read; + &sub-select; + &sub-write; + </appendix> + + <appendix id="videodev"> + <title>Video For Linux Two Header File</title> + &sub-videodev2-h; + </appendix> + + <appendix id="capture-example"> + <title>Video Capture Example</title> + &sub-capture-c; + </appendix> + + <appendix id="v4l2grab-example"> + <title>Video Grabber example using libv4l</title> + <para>This program demonstrates how to grab V4L2 images in ppm format by +using libv4l handlers. The advantage is that this grabber can potentially work +with any V4L2 driver.</para> + &sub-v4l2grab-c; + </appendix> + + &sub-media-indices; + + &sub-biblio; + diff --git a/Documentation/DocBook/v4l/v4l2grab.c.xml b/Documentation/DocBook/v4l/v4l2grab.c.xml new file mode 100644 index 000000000000..bed12e40be27 --- /dev/null +++ b/Documentation/DocBook/v4l/v4l2grab.c.xml @@ -0,0 +1,164 @@ +<programlisting> +/* V4L2 video picture grabber + Copyright (C) 2009 Mauro Carvalho Chehab <mchehab@infradead.org> + + This program is free software; you can redistribute it and/or modify + it under the terms of the GNU General Public License as published by + the Free Software Foundation version 2 of the License. + + This program is distributed in the hope that it will be useful, + but WITHOUT ANY WARRANTY; without even the implied warranty of + MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + GNU General Public License for more details. + */ + +#include <stdio.h> +#include <stdlib.h> +#include <string.h> +#include <fcntl.h> +#include <errno.h> +#include <sys/ioctl.h> +#include <sys/types.h> +#include <sys/time.h> +#include <sys/mman.h> +#include <linux/videodev2.h> +#include "../libv4l/include/libv4l2.h" + +#define CLEAR(x) memset(&(x), 0, sizeof(x)) + +struct buffer { + void *start; + size_t length; +}; + +static void xioctl(int fh, int request, void *arg) +{ + int r; + + do { + r = v4l2_ioctl(fh, request, arg); + } while (r == -1 && ((errno == EINTR) || (errno == EAGAIN))); + + if (r == -1) { + fprintf(stderr, "error %d, %s\n", errno, strerror(errno)); + exit(EXIT_FAILURE); + } +} + +int main(int argc, char **argv) +{ + struct <link linkend="v4l2-format">v4l2_format</link> fmt; + struct <link linkend="v4l2-buffer">v4l2_buffer</link> buf; + struct <link linkend="v4l2-requestbuffers">v4l2_requestbuffers</link> req; + enum <link linkend="v4l2-buf-type">v4l2_buf_type</link> type; + fd_set fds; + struct timeval tv; + int r, fd = -1; + unsigned int i, n_buffers; + char *dev_name = "/dev/video0"; + char out_name[256]; + FILE *fout; + struct buffer *buffers; + + fd = v4l2_open(dev_name, O_RDWR | O_NONBLOCK, 0); + if (fd < 0) { + perror("Cannot open device"); + exit(EXIT_FAILURE); + } + + CLEAR(fmt); + fmt.type = V4L2_BUF_TYPE_VIDEO_CAPTURE; + fmt.fmt.pix.width = 640; + fmt.fmt.pix.height = 480; + fmt.fmt.pix.pixelformat = V4L2_PIX_FMT_RGB24; + fmt.fmt.pix.field = V4L2_FIELD_INTERLACED; + xioctl(fd, VIDIOC_S_FMT, &fmt); + if (fmt.fmt.pix.pixelformat != V4L2_PIX_FMT_RGB24) { + printf("Libv4l didn't accept RGB24 format. Can't proceed.\n"); + exit(EXIT_FAILURE); + } + if ((fmt.fmt.pix.width != 640) || (fmt.fmt.pix.height != 480)) + printf("Warning: driver is sending image at %dx%d\n", + fmt.fmt.pix.width, fmt.fmt.pix.height); + + CLEAR(req); + req.count = 2; + req.type = V4L2_BUF_TYPE_VIDEO_CAPTURE; + req.memory = V4L2_MEMORY_MMAP; + xioctl(fd, VIDIOC_REQBUFS, &req); + + buffers = calloc(req.count, sizeof(*buffers)); + for (n_buffers = 0; n_buffers < req.count; ++n_buffers) { + CLEAR(buf); + + buf.type = V4L2_BUF_TYPE_VIDEO_CAPTURE; + buf.memory = V4L2_MEMORY_MMAP; + buf.index = n_buffers; + + xioctl(fd, VIDIOC_QUERYBUF, &buf); + + buffers[n_buffers].length = buf.length; + buffers[n_buffers].start = v4l2_mmap(NULL, buf.length, + PROT_READ | PROT_WRITE, MAP_SHARED, + fd, buf.m.offset); + + if (MAP_FAILED == buffers[n_buffers].start) { + perror("mmap"); + exit(EXIT_FAILURE); + } + } + + for (i = 0; i < n_buffers; ++i) { + CLEAR(buf); + buf.type = V4L2_BUF_TYPE_VIDEO_CAPTURE; + buf.memory = V4L2_MEMORY_MMAP; + buf.index = i; + xioctl(fd, VIDIOC_QBUF, &buf); + } + type = V4L2_BUF_TYPE_VIDEO_CAPTURE; + + xioctl(fd, VIDIOC_STREAMON, &type); + for (i = 0; i < 20; i++) { + do { + FD_ZERO(&fds); + FD_SET(fd, &fds); + + /* Timeout. */ + tv.tv_sec = 2; + tv.tv_usec = 0; + + r = select(fd + 1, &fds, NULL, NULL, &tv); + } while ((r == -1 && (errno = EINTR))); + if (r == -1) { + perror("select"); + return errno; + } + + CLEAR(buf); + buf.type = V4L2_BUF_TYPE_VIDEO_CAPTURE; + buf.memory = V4L2_MEMORY_MMAP; + xioctl(fd, VIDIOC_DQBUF, &buf); + + sprintf(out_name, "out%03d.ppm", i); + fout = fopen(out_name, "w"); + if (!fout) { + perror("Cannot open image"); + exit(EXIT_FAILURE); + } + fprintf(fout, "P6\n%d %d 255\n", + fmt.fmt.pix.width, fmt.fmt.pix.height); + fwrite(buffers[buf.index].start, buf.bytesused, 1, fout); + fclose(fout); + + xioctl(fd, VIDIOC_QBUF, &buf); + } + + type = V4L2_BUF_TYPE_VIDEO_CAPTURE; + xioctl(fd, VIDIOC_STREAMOFF, &type); + for (i = 0; i < n_buffers; ++i) + v4l2_munmap(buffers[i].start, buffers[i].length); + v4l2_close(fd); + + return 0; +} +</programlisting> diff --git a/Documentation/DocBook/v4l/vbi_525.gif b/Documentation/DocBook/v4l/vbi_525.gif Binary files differnew file mode 100644 index 000000000000..5580b690d504 --- /dev/null +++ b/Documentation/DocBook/v4l/vbi_525.gif diff --git a/Documentation/DocBook/v4l/vbi_525.pdf b/Documentation/DocBook/v4l/vbi_525.pdf Binary files differnew file mode 100644 index 000000000000..9e72c25b208d --- /dev/null +++ b/Documentation/DocBook/v4l/vbi_525.pdf diff --git a/Documentation/DocBook/v4l/vbi_625.gif b/Documentation/DocBook/v4l/vbi_625.gif Binary files differnew file mode 100644 index 000000000000..34e3251983c4 --- /dev/null +++ b/Documentation/DocBook/v4l/vbi_625.gif diff --git a/Documentation/DocBook/v4l/vbi_625.pdf b/Documentation/DocBook/v4l/vbi_625.pdf Binary files differnew file mode 100644 index 000000000000..765235e33a4d --- /dev/null +++ b/Documentation/DocBook/v4l/vbi_625.pdf diff --git a/Documentation/DocBook/v4l/vbi_hsync.gif b/Documentation/DocBook/v4l/vbi_hsync.gif Binary files differnew file mode 100644 index 000000000000..b02434d3b356 --- /dev/null +++ b/Documentation/DocBook/v4l/vbi_hsync.gif diff --git a/Documentation/DocBook/v4l/vbi_hsync.pdf b/Documentation/DocBook/v4l/vbi_hsync.pdf Binary files differnew file mode 100644 index 000000000000..200b668189bf --- /dev/null +++ b/Documentation/DocBook/v4l/vbi_hsync.pdf diff --git a/Documentation/DocBook/v4l/videodev2.h.xml b/Documentation/DocBook/v4l/videodev2.h.xml new file mode 100644 index 000000000000..068325940658 --- /dev/null +++ b/Documentation/DocBook/v4l/videodev2.h.xml @@ -0,0 +1,1757 @@ +<programlisting> +/* + * Video for Linux Two header file + * + * Copyright (C) 1999-2007 the contributors + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; either version 2 of the License, or + * (at your option) any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * Alternatively you can redistribute this file under the terms of the + * BSD license as stated below: + * + * Redistribution and use in source and binary forms, with or without + * modification, are permitted provided that the following conditions + * are met: + * 1. Redistributions of source code must retain the above copyright + * notice, this list of conditions and the following disclaimer. + * 2. Redistributions in binary form must reproduce the above copyright + * notice, this list of conditions and the following disclaimer in + * the documentation and/or other materials provided with the + * distribution. + * 3. The names of its contributors may not be used to endorse or promote + * products derived from this software without specific prior written + * permission. + * + * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS + * "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT + * LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR + * A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT + * OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, + * SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED + * TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR + * PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF + * LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING + * NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS + * SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. + * + * Header file for v4l or V4L2 drivers and applications + * with public API. + * All kernel-specific stuff were moved to media/v4l2-dev.h, so + * no #if __KERNEL tests are allowed here + * + * See http://linuxtv.org for more info + * + * Author: Bill Dirks <bill@thedirks.org> + * Justin Schoeman + * Hans Verkuil <hverkuil@xs4all.nl> + * et al. + */ +#ifndef __LINUX_VIDEODEV2_H +#define __LINUX_VIDEODEV2_H + +#ifdef __KERNEL__ +#include <linux/time.h> /* need struct timeval */ +#else +#include <sys/time.h> +#endif +#include <linux/compiler.h> +#include <linux/ioctl.h> +#include <linux/types.h> + +/* + * Common stuff for both V4L1 and V4L2 + * Moved from videodev.h + */ +#define VIDEO_MAX_FRAME 32 + +#ifndef __KERNEL__ + +/* These defines are V4L1 specific and should not be used with the V4L2 API! + They will be removed from this header in the future. */ + +#define VID_TYPE_CAPTURE 1 /* Can capture */ +#define VID_TYPE_TUNER 2 /* Can tune */ +#define VID_TYPE_TELETEXT 4 /* Does teletext */ +#define VID_TYPE_OVERLAY 8 /* Overlay onto frame buffer */ +#define VID_TYPE_CHROMAKEY 16 /* Overlay by chromakey */ +#define VID_TYPE_CLIPPING 32 /* Can clip */ +#define VID_TYPE_FRAMERAM 64 /* Uses the frame buffer memory */ +#define VID_TYPE_SCALES 128 /* Scalable */ +#define VID_TYPE_MONOCHROME 256 /* Monochrome only */ +#define VID_TYPE_SUBCAPTURE 512 /* Can capture subareas of the image */ +#define VID_TYPE_MPEG_DECODER 1024 /* Can decode MPEG streams */ +#define VID_TYPE_MPEG_ENCODER 2048 /* Can encode MPEG streams */ +#define VID_TYPE_MJPEG_DECODER 4096 /* Can decode MJPEG streams */ +#define VID_TYPE_MJPEG_ENCODER 8192 /* Can encode MJPEG streams */ +#endif + +/* + * M I S C E L L A N E O U S + */ + +/* Four-character-code (FOURCC) */ +#define v4l2_fourcc(a, b, c, d)\ + ((__u32)(a) | ((__u32)(b) << 8) | ((__u32)(c) << 16) | ((__u32)(d) << 24)) + +/* + * E N U M S + */ +enum <link linkend="v4l2-field">v4l2_field</link> { + V4L2_FIELD_ANY = 0, /* driver can choose from none, + top, bottom, interlaced + depending on whatever it thinks + is approximate ... */ + V4L2_FIELD_NONE = 1, /* this device has no fields ... */ + V4L2_FIELD_TOP = 2, /* top field only */ + V4L2_FIELD_BOTTOM = 3, /* bottom field only */ + V4L2_FIELD_INTERLACED = 4, /* both fields interlaced */ + V4L2_FIELD_SEQ_TB = 5, /* both fields sequential into one + buffer, top-bottom order */ + V4L2_FIELD_SEQ_BT = 6, /* same as above + bottom-top order */ + V4L2_FIELD_ALTERNATE = 7, /* both fields alternating into + separate buffers */ + V4L2_FIELD_INTERLACED_TB = 8, /* both fields interlaced, top field + first and the top field is + transmitted first */ + V4L2_FIELD_INTERLACED_BT = 9, /* both fields interlaced, top field + first and the bottom field is + transmitted first */ +}; +#define V4L2_FIELD_HAS_TOP(field) \ + ((field) == V4L2_FIELD_TOP ||\ + (field) == V4L2_FIELD_INTERLACED ||\ + (field) == V4L2_FIELD_INTERLACED_TB ||\ + (field) == V4L2_FIELD_INTERLACED_BT ||\ + (field) == V4L2_FIELD_SEQ_TB ||\ + (field) == V4L2_FIELD_SEQ_BT) +#define V4L2_FIELD_HAS_BOTTOM(field) \ + ((field) == V4L2_FIELD_BOTTOM ||\ + (field) == V4L2_FIELD_INTERLACED ||\ + (field) == V4L2_FIELD_INTERLACED_TB ||\ + (field) == V4L2_FIELD_INTERLACED_BT ||\ + (field) == V4L2_FIELD_SEQ_TB ||\ + (field) == V4L2_FIELD_SEQ_BT) +#define V4L2_FIELD_HAS_BOTH(field) \ + ((field) == V4L2_FIELD_INTERLACED ||\ + (field) == V4L2_FIELD_INTERLACED_TB ||\ + (field) == V4L2_FIELD_INTERLACED_BT ||\ + (field) == V4L2_FIELD_SEQ_TB ||\ + (field) == V4L2_FIELD_SEQ_BT) + +enum <link linkend="v4l2-buf-type">v4l2_buf_type</link> { + V4L2_BUF_TYPE_VIDEO_CAPTURE = 1, + V4L2_BUF_TYPE_VIDEO_OUTPUT = 2, + V4L2_BUF_TYPE_VIDEO_OVERLAY = 3, + V4L2_BUF_TYPE_VBI_CAPTURE = 4, + V4L2_BUF_TYPE_VBI_OUTPUT = 5, + V4L2_BUF_TYPE_SLICED_VBI_CAPTURE = 6, + V4L2_BUF_TYPE_SLICED_VBI_OUTPUT = 7, +#if 1 /*KEEP*/ + /* Experimental */ + V4L2_BUF_TYPE_VIDEO_OUTPUT_OVERLAY = 8, +#endif + V4L2_BUF_TYPE_PRIVATE = 0x80, +}; + +enum <link linkend="v4l2-ctrl-type">v4l2_ctrl_type</link> { + V4L2_CTRL_TYPE_INTEGER = 1, + V4L2_CTRL_TYPE_BOOLEAN = 2, + V4L2_CTRL_TYPE_MENU = 3, + V4L2_CTRL_TYPE_BUTTON = 4, + V4L2_CTRL_TYPE_INTEGER64 = 5, + V4L2_CTRL_TYPE_CTRL_CLASS = 6, + V4L2_CTRL_TYPE_STRING = 7, +}; + +enum <link linkend="v4l2-tuner-type">v4l2_tuner_type</link> { + V4L2_TUNER_RADIO = 1, + V4L2_TUNER_ANALOG_TV = 2, + V4L2_TUNER_DIGITAL_TV = 3, +}; + +enum <link linkend="v4l2-memory">v4l2_memory</link> { + V4L2_MEMORY_MMAP = 1, + V4L2_MEMORY_USERPTR = 2, + V4L2_MEMORY_OVERLAY = 3, +}; + +/* see also http://vektor.theorem.ca/graphics/ycbcr/ */ +enum <link linkend="v4l2-colorspace">v4l2_colorspace</link> { + /* ITU-R 601 -- broadcast NTSC/PAL */ + V4L2_COLORSPACE_SMPTE170M = 1, + + /* 1125-Line (US) HDTV */ + V4L2_COLORSPACE_SMPTE240M = 2, + + /* HD and modern captures. */ + V4L2_COLORSPACE_REC709 = 3, + + /* broken BT878 extents (601, luma range 16-253 instead of 16-235) */ + V4L2_COLORSPACE_BT878 = 4, + + /* These should be useful. Assume 601 extents. */ + V4L2_COLORSPACE_470_SYSTEM_M = 5, + V4L2_COLORSPACE_470_SYSTEM_BG = 6, + + /* I know there will be cameras that send this. So, this is + * unspecified chromaticities and full 0-255 on each of the + * Y'CbCr components + */ + V4L2_COLORSPACE_JPEG = 7, + + /* For RGB colourspaces, this is probably a good start. */ + V4L2_COLORSPACE_SRGB = 8, +}; + +enum <link linkend="v4l2-priority">v4l2_priority</link> { + V4L2_PRIORITY_UNSET = 0, /* not initialized */ + V4L2_PRIORITY_BACKGROUND = 1, + V4L2_PRIORITY_INTERACTIVE = 2, + V4L2_PRIORITY_RECORD = 3, + V4L2_PRIORITY_DEFAULT = V4L2_PRIORITY_INTERACTIVE, +}; + +struct <link linkend="v4l2-rect">v4l2_rect</link> { + __s32 left; + __s32 top; + __s32 width; + __s32 height; +}; + +struct <link linkend="v4l2-fract">v4l2_fract</link> { + __u32 numerator; + __u32 denominator; +}; + +/* + * D R I V E R C A P A B I L I T I E S + */ +struct <link linkend="v4l2-capability">v4l2_capability</link> { + __u8 driver[16]; /* i.e.ie; "bttv" */ + __u8 card[32]; /* i.e.ie; "Hauppauge WinTV" */ + __u8 bus_info[32]; /* "PCI:" + pci_name(pci_dev) */ + __u32 version; /* should use KERNEL_VERSION() */ + __u32 capabilities; /* Device capabilities */ + __u32 reserved[4]; +}; + +/* Values for 'capabilities' field */ +#define V4L2_CAP_VIDEO_CAPTURE 0x00000001 /* Is a video capture device */ +#define V4L2_CAP_VIDEO_OUTPUT 0x00000002 /* Is a video output device */ +#define V4L2_CAP_VIDEO_OVERLAY 0x00000004 /* Can do video overlay */ +#define V4L2_CAP_VBI_CAPTURE 0x00000010 /* Is a raw VBI capture device */ +#define V4L2_CAP_VBI_OUTPUT 0x00000020 /* Is a raw VBI output device */ +#define V4L2_CAP_SLICED_VBI_CAPTURE 0x00000040 /* Is a sliced VBI capture device */ +#define V4L2_CAP_SLICED_VBI_OUTPUT 0x00000080 /* Is a sliced VBI output device */ +#define V4L2_CAP_RDS_CAPTURE 0x00000100 /* RDS data capture */ +#define V4L2_CAP_VIDEO_OUTPUT_OVERLAY 0x00000200 /* Can do video output overlay */ +#define V4L2_CAP_HW_FREQ_SEEK 0x00000400 /* Can do hardware frequency seek */ +#define V4L2_CAP_RDS_OUTPUT 0x00000800 /* Is an RDS encoder */ + +#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 */ +#define V4L2_CAP_MODULATOR 0x00080000 /* has a modulator */ + +#define V4L2_CAP_READWRITE 0x01000000 /* read/write systemcalls */ +#define V4L2_CAP_ASYNCIO 0x02000000 /* async I/O */ +#define V4L2_CAP_STREAMING 0x04000000 /* streaming I/O ioctls */ + +/* + * V I D E O I M A G E F O R M A T + */ +struct <link linkend="v4l2-pix-format">v4l2_pix_format</link> { + __u32 width; + __u32 height; + __u32 pixelformat; + enum <link linkend="v4l2-field">v4l2_field</link> field; + __u32 bytesperline; /* for padding, zero if unused */ + __u32 sizeimage; + enum <link linkend="v4l2-colorspace">v4l2_colorspace</link> colorspace; + __u32 priv; /* private data, depends on pixelformat */ +}; + +/* Pixel format FOURCC depth Description */ + +/* RGB formats */ +#define <link linkend="V4L2-PIX-FMT-RGB332">V4L2_PIX_FMT_RGB332</link> v4l2_fourcc('R', 'G', 'B', '1') /* 8 RGB-3-3-2 */ +#define <link linkend="V4L2-PIX-FMT-RGB444">V4L2_PIX_FMT_RGB444</link> v4l2_fourcc('R', '4', '4', '4') /* 16 xxxxrrrr ggggbbbb */ +#define <link linkend="V4L2-PIX-FMT-RGB555">V4L2_PIX_FMT_RGB555</link> v4l2_fourcc('R', 'G', 'B', 'O') /* 16 RGB-5-5-5 */ +#define <link linkend="V4L2-PIX-FMT-RGB565">V4L2_PIX_FMT_RGB565</link> v4l2_fourcc('R', 'G', 'B', 'P') /* 16 RGB-5-6-5 */ +#define <link linkend="V4L2-PIX-FMT-RGB555X">V4L2_PIX_FMT_RGB555X</link> v4l2_fourcc('R', 'G', 'B', 'Q') /* 16 RGB-5-5-5 BE */ +#define <link linkend="V4L2-PIX-FMT-RGB565X">V4L2_PIX_FMT_RGB565X</link> v4l2_fourcc('R', 'G', 'B', 'R') /* 16 RGB-5-6-5 BE */ +#define <link linkend="V4L2-PIX-FMT-BGR24">V4L2_PIX_FMT_BGR24</link> v4l2_fourcc('B', 'G', 'R', '3') /* 24 BGR-8-8-8 */ +#define <link linkend="V4L2-PIX-FMT-RGB24">V4L2_PIX_FMT_RGB24</link> v4l2_fourcc('R', 'G', 'B', '3') /* 24 RGB-8-8-8 */ +#define <link linkend="V4L2-PIX-FMT-BGR32">V4L2_PIX_FMT_BGR32</link> v4l2_fourcc('B', 'G', 'R', '4') /* 32 BGR-8-8-8-8 */ +#define <link linkend="V4L2-PIX-FMT-RGB32">V4L2_PIX_FMT_RGB32</link> v4l2_fourcc('R', 'G', 'B', '4') /* 32 RGB-8-8-8-8 */ + +/* Grey formats */ +#define <link linkend="V4L2-PIX-FMT-GREY">V4L2_PIX_FMT_GREY</link> v4l2_fourcc('G', 'R', 'E', 'Y') /* 8 Greyscale */ +#define <link linkend="V4L2-PIX-FMT-Y16">V4L2_PIX_FMT_Y16</link> v4l2_fourcc('Y', '1', '6', ' ') /* 16 Greyscale */ + +/* Palette formats */ +#define <link linkend="V4L2-PIX-FMT-PAL8">V4L2_PIX_FMT_PAL8</link> v4l2_fourcc('P', 'A', 'L', '8') /* 8 8-bit palette */ + +/* Luminance+Chrominance formats */ +#define <link linkend="V4L2-PIX-FMT-YVU410">V4L2_PIX_FMT_YVU410</link> v4l2_fourcc('Y', 'V', 'U', '9') /* 9 YVU 4:1:0 */ +#define <link linkend="V4L2-PIX-FMT-YVU420">V4L2_PIX_FMT_YVU420</link> v4l2_fourcc('Y', 'V', '1', '2') /* 12 YVU 4:2:0 */ +#define <link linkend="V4L2-PIX-FMT-YUYV">V4L2_PIX_FMT_YUYV</link> v4l2_fourcc('Y', 'U', 'Y', 'V') /* 16 YUV 4:2:2 */ +#define <link linkend="V4L2-PIX-FMT-YYUV">V4L2_PIX_FMT_YYUV</link> v4l2_fourcc('Y', 'Y', 'U', 'V') /* 16 YUV 4:2:2 */ +#define <link linkend="V4L2-PIX-FMT-YVYU">V4L2_PIX_FMT_YVYU</link> v4l2_fourcc('Y', 'V', 'Y', 'U') /* 16 YVU 4:2:2 */ +#define <link linkend="V4L2-PIX-FMT-UYVY">V4L2_PIX_FMT_UYVY</link> v4l2_fourcc('U', 'Y', 'V', 'Y') /* 16 YUV 4:2:2 */ +#define <link linkend="V4L2-PIX-FMT-VYUY">V4L2_PIX_FMT_VYUY</link> v4l2_fourcc('V', 'Y', 'U', 'Y') /* 16 YUV 4:2:2 */ +#define <link linkend="V4L2-PIX-FMT-YUV422P">V4L2_PIX_FMT_YUV422P</link> v4l2_fourcc('4', '2', '2', 'P') /* 16 YVU422 planar */ +#define <link linkend="V4L2-PIX-FMT-YUV411P">V4L2_PIX_FMT_YUV411P</link> v4l2_fourcc('4', '1', '1', 'P') /* 16 YVU411 planar */ +#define <link linkend="V4L2-PIX-FMT-Y41P">V4L2_PIX_FMT_Y41P</link> v4l2_fourcc('Y', '4', '1', 'P') /* 12 YUV 4:1:1 */ +#define <link linkend="V4L2-PIX-FMT-YUV444">V4L2_PIX_FMT_YUV444</link> v4l2_fourcc('Y', '4', '4', '4') /* 16 xxxxyyyy uuuuvvvv */ +#define <link linkend="V4L2-PIX-FMT-YUV555">V4L2_PIX_FMT_YUV555</link> v4l2_fourcc('Y', 'U', 'V', 'O') /* 16 YUV-5-5-5 */ +#define <link linkend="V4L2-PIX-FMT-YUV565">V4L2_PIX_FMT_YUV565</link> v4l2_fourcc('Y', 'U', 'V', 'P') /* 16 YUV-5-6-5 */ +#define <link linkend="V4L2-PIX-FMT-YUV32">V4L2_PIX_FMT_YUV32</link> v4l2_fourcc('Y', 'U', 'V', '4') /* 32 YUV-8-8-8-8 */ +#define <link linkend="V4L2-PIX-FMT-YUV410">V4L2_PIX_FMT_YUV410</link> v4l2_fourcc('Y', 'U', 'V', '9') /* 9 YUV 4:1:0 */ +#define <link linkend="V4L2-PIX-FMT-YUV420">V4L2_PIX_FMT_YUV420</link> v4l2_fourcc('Y', 'U', '1', '2') /* 12 YUV 4:2:0 */ +#define <link linkend="V4L2-PIX-FMT-HI240">V4L2_PIX_FMT_HI240</link> v4l2_fourcc('H', 'I', '2', '4') /* 8 8-bit color */ +#define <link linkend="V4L2-PIX-FMT-HM12">V4L2_PIX_FMT_HM12</link> v4l2_fourcc('H', 'M', '1', '2') /* 8 YUV 4:2:0 16x16 macroblocks */ + +/* two planes -- one Y, one Cr + Cb interleaved */ +#define <link linkend="V4L2-PIX-FMT-NV12">V4L2_PIX_FMT_NV12</link> v4l2_fourcc('N', 'V', '1', '2') /* 12 Y/CbCr 4:2:0 */ +#define <link linkend="V4L2-PIX-FMT-NV21">V4L2_PIX_FMT_NV21</link> v4l2_fourcc('N', 'V', '2', '1') /* 12 Y/CrCb 4:2:0 */ +#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 */ + +/* 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.. */ +#define <link linkend="V4L2-PIX-FMT-SGRBG8">V4L2_PIX_FMT_SGRBG8</link> v4l2_fourcc('G', 'R', 'B', 'G') /* 8 GRGR.. BGBG.. */ +#define <link linkend="V4L2-PIX-FMT-SGRBG10">V4L2_PIX_FMT_SGRBG10</link> v4l2_fourcc('B', 'A', '1', '0') /* 10bit raw bayer */ + /* 10bit raw bayer DPCM compressed to 8 bits */ +#define <link linkend="V4L2-PIX-FMT-SGRBG10DPCM8">V4L2_PIX_FMT_SGRBG10DPCM8</link> v4l2_fourcc('B', 'D', '1', '0') + /* + * 10bit raw bayer, expanded to 16 bits + * xxxxrrrrrrrrrrxxxxgggggggggg xxxxggggggggggxxxxbbbbbbbbbb... + */ +#define <link linkend="V4L2-PIX-FMT-SBGGR16">V4L2_PIX_FMT_SBGGR16</link> v4l2_fourcc('B', 'Y', 'R', '2') /* 16 BGBG.. GRGR.. */ + +/* compressed formats */ +#define <link linkend="V4L2-PIX-FMT-MJPEG">V4L2_PIX_FMT_MJPEG</link> v4l2_fourcc('M', 'J', 'P', 'G') /* Motion-JPEG */ +#define <link linkend="V4L2-PIX-FMT-JPEG">V4L2_PIX_FMT_JPEG</link> v4l2_fourcc('J', 'P', 'E', 'G') /* JFIF JPEG */ +#define <link linkend="V4L2-PIX-FMT-DV">V4L2_PIX_FMT_DV</link> v4l2_fourcc('d', 'v', 's', 'd') /* 1394 */ +#define <link linkend="V4L2-PIX-FMT-MPEG">V4L2_PIX_FMT_MPEG</link> v4l2_fourcc('M', 'P', 'E', 'G') /* MPEG-1/2/4 */ + +/* Vendor-specific formats */ +#define <link linkend="V4L2-PIX-FMT-WNVA">V4L2_PIX_FMT_WNVA</link> v4l2_fourcc('W', 'N', 'V', 'A') /* Winnov hw compress */ +#define <link linkend="V4L2-PIX-FMT-SN9C10X">V4L2_PIX_FMT_SN9C10X</link> v4l2_fourcc('S', '9', '1', '0') /* SN9C10x compression */ +#define <link linkend="V4L2-PIX-FMT-SN9C20X-I420">V4L2_PIX_FMT_SN9C20X_I420</link> v4l2_fourcc('S', '9', '2', '0') /* SN9C20x YUV 4:2:0 */ +#define <link linkend="V4L2-PIX-FMT-PWC1">V4L2_PIX_FMT_PWC1</link> v4l2_fourcc('P', 'W', 'C', '1') /* pwc older webcam */ +#define <link linkend="V4L2-PIX-FMT-PWC2">V4L2_PIX_FMT_PWC2</link> v4l2_fourcc('P', 'W', 'C', '2') /* pwc newer webcam */ +#define <link linkend="V4L2-PIX-FMT-ET61X251">V4L2_PIX_FMT_ET61X251</link> v4l2_fourcc('E', '6', '2', '5') /* ET61X251 compression */ +#define <link linkend="V4L2-PIX-FMT-SPCA501">V4L2_PIX_FMT_SPCA501</link> v4l2_fourcc('S', '5', '0', '1') /* YUYV per line */ +#define <link linkend="V4L2-PIX-FMT-SPCA505">V4L2_PIX_FMT_SPCA505</link> v4l2_fourcc('S', '5', '0', '5') /* YYUV per line */ +#define <link linkend="V4L2-PIX-FMT-SPCA508">V4L2_PIX_FMT_SPCA508</link> v4l2_fourcc('S', '5', '0', '8') /* YUVY per line */ +#define <link linkend="V4L2-PIX-FMT-SPCA561">V4L2_PIX_FMT_SPCA561</link> v4l2_fourcc('S', '5', '6', '1') /* compressed GBRG bayer */ +#define <link linkend="V4L2-PIX-FMT-PAC207">V4L2_PIX_FMT_PAC207</link> v4l2_fourcc('P', '2', '0', '7') /* compressed BGGR bayer */ +#define <link linkend="V4L2-PIX-FMT-MR97310A">V4L2_PIX_FMT_MR97310A</link> v4l2_fourcc('M', '3', '1', '0') /* compressed BGGR bayer */ +#define <link linkend="V4L2-PIX-FMT-SQ905C">V4L2_PIX_FMT_SQ905C</link> v4l2_fourcc('9', '0', '5', 'C') /* compressed RGGB bayer */ +#define <link linkend="V4L2-PIX-FMT-PJPG">V4L2_PIX_FMT_PJPG</link> v4l2_fourcc('P', 'J', 'P', 'G') /* Pixart 73xx JPEG */ +#define <link linkend="V4L2-PIX-FMT-OV511">V4L2_PIX_FMT_OV511</link> v4l2_fourcc('O', '5', '1', '1') /* ov511 JPEG */ +#define <link linkend="V4L2-PIX-FMT-OV518">V4L2_PIX_FMT_OV518</link> v4l2_fourcc('O', '5', '1', '8') /* ov518 JPEG */ +#define <link linkend="V4L2-PIX-FMT-TM6000">V4L2_PIX_FMT_TM6000</link> v4l2_fourcc('T', 'M', '6', '0') /* tm5600/tm60x0 */ +#define <link linkend="V4L2-PIX-FMT-STV0680">V4L2_PIX_FMT_STV0680</link> v4l2_fourcc('S', '6', '8', '0') /* stv0680 bayer */ + +/* + * F O R M A T E N U M E R A T I O N + */ +struct <link linkend="v4l2-fmtdesc">v4l2_fmtdesc</link> { + __u32 index; /* Format number */ + enum <link linkend="v4l2-buf-type">v4l2_buf_type</link> type; /* buffer type */ + __u32 flags; + __u8 description[32]; /* Description string */ + __u32 pixelformat; /* Format fourcc */ + __u32 reserved[4]; +}; + +#define V4L2_FMT_FLAG_COMPRESSED 0x0001 +#define V4L2_FMT_FLAG_EMULATED 0x0002 + +#if 1 /*KEEP*/ + /* Experimental Frame Size and frame rate enumeration */ +/* + * F R A M E S I Z E E N U M E R A T I O N + */ +enum <link linkend="v4l2-frmsizetypes">v4l2_frmsizetypes</link> { + V4L2_FRMSIZE_TYPE_DISCRETE = 1, + V4L2_FRMSIZE_TYPE_CONTINUOUS = 2, + V4L2_FRMSIZE_TYPE_STEPWISE = 3, +}; + +struct <link linkend="v4l2-frmsize-discrete">v4l2_frmsize_discrete</link> { + __u32 width; /* Frame width [pixel] */ + __u32 height; /* Frame height [pixel] */ +}; + +struct <link linkend="v4l2-frmsize-stepwise">v4l2_frmsize_stepwise</link> { + __u32 min_width; /* Minimum frame width [pixel] */ + __u32 max_width; /* Maximum frame width [pixel] */ + __u32 step_width; /* Frame width step size [pixel] */ + __u32 min_height; /* Minimum frame height [pixel] */ + __u32 max_height; /* Maximum frame height [pixel] */ + __u32 step_height; /* Frame height step size [pixel] */ +}; + +struct <link linkend="v4l2-frmsizeenum">v4l2_frmsizeenum</link> { + __u32 index; /* Frame size number */ + __u32 pixel_format; /* Pixel format */ + __u32 type; /* Frame size type the device supports. */ + + union { /* Frame size */ + struct <link linkend="v4l2-frmsize-discrete">v4l2_frmsize_discrete</link> discrete; + struct <link linkend="v4l2-frmsize-stepwise">v4l2_frmsize_stepwise</link> stepwise; + }; + + __u32 reserved[2]; /* Reserved space for future use */ +}; + +/* + * F R A M E R A T E E N U M E R A T I O N + */ +enum <link linkend="v4l2-frmivaltypes">v4l2_frmivaltypes</link> { + V4L2_FRMIVAL_TYPE_DISCRETE = 1, + V4L2_FRMIVAL_TYPE_CONTINUOUS = 2, + V4L2_FRMIVAL_TYPE_STEPWISE = 3, +}; + +struct <link linkend="v4l2-frmival-stepwise">v4l2_frmival_stepwise</link> { + struct <link linkend="v4l2-fract">v4l2_fract</link> min; /* Minimum frame interval [s] */ + struct <link linkend="v4l2-fract">v4l2_fract</link> max; /* Maximum frame interval [s] */ + struct <link linkend="v4l2-fract">v4l2_fract</link> step; /* Frame interval step size [s] */ +}; + +struct <link linkend="v4l2-frmivalenum">v4l2_frmivalenum</link> { + __u32 index; /* Frame format index */ + __u32 pixel_format; /* Pixel format */ + __u32 width; /* Frame width */ + __u32 height; /* Frame height */ + __u32 type; /* Frame interval type the device supports. */ + + union { /* Frame interval */ + struct <link linkend="v4l2-fract">v4l2_fract</link> discrete; + struct <link linkend="v4l2-frmival-stepwise">v4l2_frmival_stepwise</link> stepwise; + }; + + __u32 reserved[2]; /* Reserved space for future use */ +}; +#endif + +/* + * T I M E C O D E + */ +struct <link linkend="v4l2-timecode">v4l2_timecode</link> { + __u32 type; + __u32 flags; + __u8 frames; + __u8 seconds; + __u8 minutes; + __u8 hours; + __u8 userbits[4]; +}; + +/* Type */ +#define V4L2_TC_TYPE_24FPS 1 +#define V4L2_TC_TYPE_25FPS 2 +#define V4L2_TC_TYPE_30FPS 3 +#define V4L2_TC_TYPE_50FPS 4 +#define V4L2_TC_TYPE_60FPS 5 + +/* Flags */ +#define V4L2_TC_FLAG_DROPFRAME 0x0001 /* "drop-frame" mode */ +#define V4L2_TC_FLAG_COLORFRAME 0x0002 +#define V4L2_TC_USERBITS_field 0x000C +#define V4L2_TC_USERBITS_USERDEFINED 0x0000 +#define V4L2_TC_USERBITS_8BITCHARS 0x0008 +/* The above is based on SMPTE timecodes */ + +struct <link linkend="v4l2-jpegcompression">v4l2_jpegcompression</link> { + int quality; + + int APPn; /* Number of APP segment to be written, + * must be 0..15 */ + int APP_len; /* Length of data in JPEG APPn segment */ + char APP_data[60]; /* Data in the JPEG APPn segment. */ + + int COM_len; /* Length of data in JPEG COM segment */ + char COM_data[60]; /* Data in JPEG COM segment */ + + __u32 jpeg_markers; /* Which markers should go into the JPEG + * output. Unless you exactly know what + * you do, leave them untouched. + * Inluding less markers will make the + * resulting code smaller, but there will + * be fewer applications which can read it. + * The presence of the APP and COM marker + * is influenced by APP_len and COM_len + * ONLY, not by this property! */ + +#define V4L2_JPEG_MARKER_DHT (1<<3) /* Define Huffman Tables */ +#define V4L2_JPEG_MARKER_DQT (1<<4) /* Define Quantization Tables */ +#define V4L2_JPEG_MARKER_DRI (1<<5) /* Define Restart Interval */ +#define V4L2_JPEG_MARKER_COM (1<<6) /* Comment segment */ +#define V4L2_JPEG_MARKER_APP (1<<7) /* App segment, driver will + * allways use APP0 */ +}; + +/* + * M E M O R Y - M A P P I N G B U F F E R S + */ +struct <link linkend="v4l2-requestbuffers">v4l2_requestbuffers</link> { + __u32 count; + enum <link linkend="v4l2-buf-type">v4l2_buf_type</link> type; + enum <link linkend="v4l2-memory">v4l2_memory</link> memory; + __u32 reserved[2]; +}; + +struct <link linkend="v4l2-buffer">v4l2_buffer</link> { + __u32 index; + enum <link linkend="v4l2-buf-type">v4l2_buf_type</link> type; + __u32 bytesused; + __u32 flags; + enum <link linkend="v4l2-field">v4l2_field</link> field; + struct timeval timestamp; + struct <link linkend="v4l2-timecode">v4l2_timecode</link> timecode; + __u32 sequence; + + /* memory location */ + enum <link linkend="v4l2-memory">v4l2_memory</link> memory; + union { + __u32 offset; + unsigned long userptr; + } m; + __u32 length; + __u32 input; + __u32 reserved; +}; + +/* Flags for 'flags' field */ +#define V4L2_BUF_FLAG_MAPPED 0x0001 /* Buffer is mapped (flag) */ +#define V4L2_BUF_FLAG_QUEUED 0x0002 /* Buffer is queued for processing */ +#define V4L2_BUF_FLAG_DONE 0x0004 /* Buffer is ready */ +#define V4L2_BUF_FLAG_KEYFRAME 0x0008 /* Image is a keyframe (I-frame) */ +#define V4L2_BUF_FLAG_PFRAME 0x0010 /* Image is a P-frame */ +#define V4L2_BUF_FLAG_BFRAME 0x0020 /* Image is a B-frame */ +#define V4L2_BUF_FLAG_TIMECODE 0x0100 /* timecode field is valid */ +#define V4L2_BUF_FLAG_INPUT 0x0200 /* input field is valid */ + +/* + * O V E R L A Y P R E V I E W + */ +struct <link linkend="v4l2-framebuffer">v4l2_framebuffer</link> { + __u32 capability; + __u32 flags; +/* FIXME: in theory we should pass something like PCI device + memory + * region + offset instead of some physical address */ + void *base; + struct <link linkend="v4l2-pix-format">v4l2_pix_format</link> fmt; +}; +/* Flags for the 'capability' field. Read only */ +#define V4L2_FBUF_CAP_EXTERNOVERLAY 0x0001 +#define V4L2_FBUF_CAP_CHROMAKEY 0x0002 +#define V4L2_FBUF_CAP_LIST_CLIPPING 0x0004 +#define V4L2_FBUF_CAP_BITMAP_CLIPPING 0x0008 +#define V4L2_FBUF_CAP_LOCAL_ALPHA 0x0010 +#define V4L2_FBUF_CAP_GLOBAL_ALPHA 0x0020 +#define V4L2_FBUF_CAP_LOCAL_INV_ALPHA 0x0040 +#define V4L2_FBUF_CAP_SRC_CHROMAKEY 0x0080 +/* Flags for the 'flags' field. */ +#define V4L2_FBUF_FLAG_PRIMARY 0x0001 +#define V4L2_FBUF_FLAG_OVERLAY 0x0002 +#define V4L2_FBUF_FLAG_CHROMAKEY 0x0004 +#define V4L2_FBUF_FLAG_LOCAL_ALPHA 0x0008 +#define V4L2_FBUF_FLAG_GLOBAL_ALPHA 0x0010 +#define V4L2_FBUF_FLAG_LOCAL_INV_ALPHA 0x0020 +#define V4L2_FBUF_FLAG_SRC_CHROMAKEY 0x0040 + +struct <link linkend="v4l2-clip">v4l2_clip</link> { + struct <link linkend="v4l2-rect">v4l2_rect</link> c; + struct <link linkend="v4l2-clip">v4l2_clip</link> __user *next; +}; + +struct <link linkend="v4l2-window">v4l2_window</link> { + struct <link linkend="v4l2-rect">v4l2_rect</link> w; + enum <link linkend="v4l2-field">v4l2_field</link> field; + __u32 chromakey; + struct <link linkend="v4l2-clip">v4l2_clip</link> __user *clips; + __u32 clipcount; + void __user *bitmap; + __u8 global_alpha; +}; + +/* + * C A P T U R E P A R A M E T E R S + */ +struct <link linkend="v4l2-captureparm">v4l2_captureparm</link> { + __u32 capability; /* Supported modes */ + __u32 capturemode; /* Current mode */ + struct <link linkend="v4l2-fract">v4l2_fract</link> timeperframe; /* Time per frame in .1us units */ + __u32 extendedmode; /* Driver-specific extensions */ + __u32 readbuffers; /* # of buffers for read */ + __u32 reserved[4]; +}; + +/* Flags for 'capability' and 'capturemode' fields */ +#define V4L2_MODE_HIGHQUALITY 0x0001 /* High quality imaging mode */ +#define V4L2_CAP_TIMEPERFRAME 0x1000 /* timeperframe field is supported */ + +struct <link linkend="v4l2-outputparm">v4l2_outputparm</link> { + __u32 capability; /* Supported modes */ + __u32 outputmode; /* Current mode */ + struct <link linkend="v4l2-fract">v4l2_fract</link> timeperframe; /* Time per frame in seconds */ + __u32 extendedmode; /* Driver-specific extensions */ + __u32 writebuffers; /* # of buffers for write */ + __u32 reserved[4]; +}; + +/* + * I N P U T I M A G E C R O P P I N G + */ +struct <link linkend="v4l2-cropcap">v4l2_cropcap</link> { + enum <link linkend="v4l2-buf-type">v4l2_buf_type</link> type; + struct <link linkend="v4l2-rect">v4l2_rect</link> bounds; + struct <link linkend="v4l2-rect">v4l2_rect</link> defrect; + struct <link linkend="v4l2-fract">v4l2_fract</link> pixelaspect; +}; + +struct <link linkend="v4l2-crop">v4l2_crop</link> { + enum <link linkend="v4l2-buf-type">v4l2_buf_type</link> type; + struct <link linkend="v4l2-rect">v4l2_rect</link> c; +}; + +/* + * A N A L O G V I D E O S T A N D A R D + */ + +typedef __u64 v4l2_std_id; + +/* one bit for each */ +#define V4L2_STD_PAL_B ((v4l2_std_id)0x00000001) +#define V4L2_STD_PAL_B1 ((v4l2_std_id)0x00000002) +#define V4L2_STD_PAL_G ((v4l2_std_id)0x00000004) +#define V4L2_STD_PAL_H ((v4l2_std_id)0x00000008) +#define V4L2_STD_PAL_I ((v4l2_std_id)0x00000010) +#define V4L2_STD_PAL_D ((v4l2_std_id)0x00000020) +#define V4L2_STD_PAL_D1 ((v4l2_std_id)0x00000040) +#define V4L2_STD_PAL_K ((v4l2_std_id)0x00000080) + +#define V4L2_STD_PAL_M ((v4l2_std_id)0x00000100) +#define V4L2_STD_PAL_N ((v4l2_std_id)0x00000200) +#define V4L2_STD_PAL_Nc ((v4l2_std_id)0x00000400) +#define V4L2_STD_PAL_60 ((v4l2_std_id)0x00000800) + +#define V4L2_STD_NTSC_M ((v4l2_std_id)0x00001000) +#define V4L2_STD_NTSC_M_JP ((v4l2_std_id)0x00002000) +#define V4L2_STD_NTSC_443 ((v4l2_std_id)0x00004000) +#define V4L2_STD_NTSC_M_KR ((v4l2_std_id)0x00008000) + +#define V4L2_STD_SECAM_B ((v4l2_std_id)0x00010000) +#define V4L2_STD_SECAM_D ((v4l2_std_id)0x00020000) +#define V4L2_STD_SECAM_G ((v4l2_std_id)0x00040000) +#define V4L2_STD_SECAM_H ((v4l2_std_id)0x00080000) +#define V4L2_STD_SECAM_K ((v4l2_std_id)0x00100000) +#define V4L2_STD_SECAM_K1 ((v4l2_std_id)0x00200000) +#define V4L2_STD_SECAM_L ((v4l2_std_id)0x00400000) +#define V4L2_STD_SECAM_LC ((v4l2_std_id)0x00800000) + +/* ATSC/HDTV */ +#define V4L2_STD_ATSC_8_VSB ((v4l2_std_id)0x01000000) +#define V4L2_STD_ATSC_16_VSB ((v4l2_std_id)0x02000000) + +/* FIXME: + Although std_id is 64 bits, there is an issue on PPC32 architecture that + makes switch(__u64) to break. So, there's a hack on v4l2-common.c rounding + this value to 32 bits. + As, currently, the max value is for V4L2_STD_ATSC_16_VSB (30 bits wide), + it should work fine. However, if needed to add more than two standards, + v4l2-common.c should be fixed. + */ + +/* some merged standards */ +#define V4L2_STD_MN (V4L2_STD_PAL_M|V4L2_STD_PAL_N|V4L2_STD_PAL_Nc|V4L2_STD_NTSC) +#define V4L2_STD_B (V4L2_STD_PAL_B|V4L2_STD_PAL_B1|V4L2_STD_SECAM_B) +#define V4L2_STD_GH (V4L2_STD_PAL_G|V4L2_STD_PAL_H|V4L2_STD_SECAM_G|V4L2_STD_SECAM_H) +#define V4L2_STD_DK (V4L2_STD_PAL_DK|V4L2_STD_SECAM_DK) + +/* some common needed stuff */ +#define V4L2_STD_PAL_BG (V4L2_STD_PAL_B |\ + V4L2_STD_PAL_B1 |\ + V4L2_STD_PAL_G) +#define V4L2_STD_PAL_DK (V4L2_STD_PAL_D |\ + V4L2_STD_PAL_D1 |\ + V4L2_STD_PAL_K) +#define V4L2_STD_PAL (V4L2_STD_PAL_BG |\ + V4L2_STD_PAL_DK |\ + V4L2_STD_PAL_H |\ + V4L2_STD_PAL_I) +#define V4L2_STD_NTSC (V4L2_STD_NTSC_M |\ + V4L2_STD_NTSC_M_JP |\ + V4L2_STD_NTSC_M_KR) +#define V4L2_STD_SECAM_DK (V4L2_STD_SECAM_D |\ + V4L2_STD_SECAM_K |\ + V4L2_STD_SECAM_K1) +#define V4L2_STD_SECAM (V4L2_STD_SECAM_B |\ + V4L2_STD_SECAM_G |\ + V4L2_STD_SECAM_H |\ + V4L2_STD_SECAM_DK |\ + V4L2_STD_SECAM_L |\ + V4L2_STD_SECAM_LC) + +#define V4L2_STD_525_60 (V4L2_STD_PAL_M |\ + V4L2_STD_PAL_60 |\ + V4L2_STD_NTSC |\ + V4L2_STD_NTSC_443) +#define V4L2_STD_625_50 (V4L2_STD_PAL |\ + V4L2_STD_PAL_N |\ + V4L2_STD_PAL_Nc |\ + V4L2_STD_SECAM) +#define V4L2_STD_ATSC (V4L2_STD_ATSC_8_VSB |\ + V4L2_STD_ATSC_16_VSB) + +#define V4L2_STD_UNKNOWN 0 +#define V4L2_STD_ALL (V4L2_STD_525_60 |\ + V4L2_STD_625_50) + +struct <link linkend="v4l2-standard">v4l2_standard</link> { + __u32 index; + v4l2_std_id id; + __u8 name[24]; + struct <link linkend="v4l2-fract">v4l2_fract</link> frameperiod; /* Frames, not fields */ + __u32 framelines; + __u32 reserved[4]; +}; + +/* + * V I D E O T I M I N G S D V P R E S E T + */ +struct <link linkend="v4l2-dv-preset">v4l2_dv_preset</link> { + __u32 preset; + __u32 reserved[4]; +}; + +/* + * D V P R E S E T S E N U M E R A T I O N + */ +struct <link linkend="v4l2-dv-enum-preset">v4l2_dv_enum_preset</link> { + __u32 index; + __u32 preset; + __u8 name[32]; /* Name of the preset timing */ + __u32 width; + __u32 height; + __u32 reserved[4]; +}; + +/* + * D V P R E S E T V A L U E S + */ +#define V4L2_DV_INVALID 0 +#define V4L2_DV_480P59_94 1 /* BT.1362 */ +#define V4L2_DV_576P50 2 /* BT.1362 */ +#define V4L2_DV_720P24 3 /* SMPTE 296M */ +#define V4L2_DV_720P25 4 /* SMPTE 296M */ +#define V4L2_DV_720P30 5 /* SMPTE 296M */ +#define V4L2_DV_720P50 6 /* SMPTE 296M */ +#define V4L2_DV_720P59_94 7 /* SMPTE 274M */ +#define V4L2_DV_720P60 8 /* SMPTE 274M/296M */ +#define V4L2_DV_1080I29_97 9 /* BT.1120/ SMPTE 274M */ +#define V4L2_DV_1080I30 10 /* BT.1120/ SMPTE 274M */ +#define V4L2_DV_1080I25 11 /* BT.1120 */ +#define V4L2_DV_1080I50 12 /* SMPTE 296M */ +#define V4L2_DV_1080I60 13 /* SMPTE 296M */ +#define V4L2_DV_1080P24 14 /* SMPTE 296M */ +#define V4L2_DV_1080P25 15 /* SMPTE 296M */ +#define V4L2_DV_1080P30 16 /* SMPTE 296M */ +#define V4L2_DV_1080P50 17 /* BT.1120 */ +#define V4L2_DV_1080P60 18 /* BT.1120 */ + +/* + * D V B T T I M I N G S + */ + +/* BT.656/BT.1120 timing data */ +struct <link linkend="v4l2-bt-timings">v4l2_bt_timings</link> { + __u32 width; /* width in pixels */ + __u32 height; /* height in lines */ + __u32 interlaced; /* Interlaced or progressive */ + __u32 polarities; /* Positive or negative polarity */ + __u64 pixelclock; /* Pixel clock in HZ. Ex. 74.25MHz->74250000 */ + __u32 hfrontporch; /* Horizpontal front porch in pixels */ + __u32 hsync; /* Horizontal Sync length in pixels */ + __u32 hbackporch; /* Horizontal back porch in pixels */ + __u32 vfrontporch; /* Vertical front porch in pixels */ + __u32 vsync; /* Vertical Sync length in lines */ + __u32 vbackporch; /* Vertical back porch in lines */ + __u32 il_vfrontporch; /* Vertical front porch for bottom field of + * interlaced field formats + */ + __u32 il_vsync; /* Vertical sync length for bottom field of + * interlaced field formats + */ + __u32 il_vbackporch; /* Vertical back porch for bottom field of + * interlaced field formats + */ + __u32 reserved[16]; +} __attribute__ ((packed)); + +/* Interlaced or progressive format */ +#define V4L2_DV_PROGRESSIVE 0 +#define V4L2_DV_INTERLACED 1 + +/* Polarities. If bit is not set, it is assumed to be negative polarity */ +#define V4L2_DV_VSYNC_POS_POL 0x00000001 +#define V4L2_DV_HSYNC_POS_POL 0x00000002 + + +/* DV timings */ +struct <link linkend="v4l2-dv-timings">v4l2_dv_timings</link> { + __u32 type; + union { + struct <link linkend="v4l2-bt-timings">v4l2_bt_timings</link> bt; + __u32 reserved[32]; + }; +} __attribute__ ((packed)); + +/* Values for the type field */ +#define V4L2_DV_BT_656_1120 0 /* BT.656/1120 timing type */ + +/* + * V I D E O I N P U T S + */ +struct <link linkend="v4l2-input">v4l2_input</link> { + __u32 index; /* Which input */ + __u8 name[32]; /* Label */ + __u32 type; /* Type of input */ + __u32 audioset; /* Associated audios (bitfield) */ + __u32 tuner; /* Associated tuner */ + v4l2_std_id std; + __u32 status; + __u32 capabilities; + __u32 reserved[3]; +}; + +/* Values for the 'type' field */ +#define V4L2_INPUT_TYPE_TUNER 1 +#define V4L2_INPUT_TYPE_CAMERA 2 + +/* field 'status' - general */ +#define V4L2_IN_ST_NO_POWER 0x00000001 /* Attached device is off */ +#define V4L2_IN_ST_NO_SIGNAL 0x00000002 +#define V4L2_IN_ST_NO_COLOR 0x00000004 + +/* field 'status' - sensor orientation */ +/* If sensor is mounted upside down set both bits */ +#define V4L2_IN_ST_HFLIP 0x00000010 /* Frames are flipped horizontally */ +#define V4L2_IN_ST_VFLIP 0x00000020 /* Frames are flipped vertically */ + +/* field 'status' - analog */ +#define V4L2_IN_ST_NO_H_LOCK 0x00000100 /* No horizontal sync lock */ +#define V4L2_IN_ST_COLOR_KILL 0x00000200 /* Color killer is active */ + +/* field 'status' - digital */ +#define V4L2_IN_ST_NO_SYNC 0x00010000 /* No synchronization lock */ +#define V4L2_IN_ST_NO_EQU 0x00020000 /* No equalizer lock */ +#define V4L2_IN_ST_NO_CARRIER 0x00040000 /* Carrier recovery failed */ + +/* field 'status' - VCR and set-top box */ +#define V4L2_IN_ST_MACROVISION 0x01000000 /* Macrovision detected */ +#define V4L2_IN_ST_NO_ACCESS 0x02000000 /* Conditional access denied */ +#define V4L2_IN_ST_VTR 0x04000000 /* VTR time constant */ + +/* capabilities flags */ +#define V4L2_IN_CAP_PRESETS 0x00000001 /* Supports S_DV_PRESET */ +#define V4L2_IN_CAP_CUSTOM_TIMINGS 0x00000002 /* Supports S_DV_TIMINGS */ +#define V4L2_IN_CAP_STD 0x00000004 /* Supports S_STD */ + +/* + * V I D E O O U T P U T S + */ +struct <link linkend="v4l2-output">v4l2_output</link> { + __u32 index; /* Which output */ + __u8 name[32]; /* Label */ + __u32 type; /* Type of output */ + __u32 audioset; /* Associated audios (bitfield) */ + __u32 modulator; /* Associated modulator */ + v4l2_std_id std; + __u32 capabilities; + __u32 reserved[3]; +}; +/* Values for the 'type' field */ +#define V4L2_OUTPUT_TYPE_MODULATOR 1 +#define V4L2_OUTPUT_TYPE_ANALOG 2 +#define V4L2_OUTPUT_TYPE_ANALOGVGAOVERLAY 3 + +/* capabilities flags */ +#define V4L2_OUT_CAP_PRESETS 0x00000001 /* Supports S_DV_PRESET */ +#define V4L2_OUT_CAP_CUSTOM_TIMINGS 0x00000002 /* Supports S_DV_TIMINGS */ +#define V4L2_OUT_CAP_STD 0x00000004 /* Supports S_STD */ + +/* + * C O N T R O L S + */ +struct <link linkend="v4l2-control">v4l2_control</link> { + __u32 id; + __s32 value; +}; + +struct <link linkend="v4l2-ext-control">v4l2_ext_control</link> { + __u32 id; + __u32 size; + __u32 reserved2[1]; + union { + __s32 value; + __s64 value64; + char *string; + }; +} __attribute__ ((packed)); + +struct <link linkend="v4l2-ext-controls">v4l2_ext_controls</link> { + __u32 ctrl_class; + __u32 count; + __u32 error_idx; + __u32 reserved[2]; + struct <link linkend="v4l2-ext-control">v4l2_ext_control</link> *controls; +}; + +/* Values for ctrl_class field */ +#define V4L2_CTRL_CLASS_USER 0x00980000 /* Old-style 'user' controls */ +#define V4L2_CTRL_CLASS_MPEG 0x00990000 /* MPEG-compression controls */ +#define V4L2_CTRL_CLASS_CAMERA 0x009a0000 /* Camera class controls */ +#define V4L2_CTRL_CLASS_FM_TX 0x009b0000 /* FM Modulator control class */ + +#define V4L2_CTRL_ID_MASK (0x0fffffff) +#define V4L2_CTRL_ID2CLASS(id) ((id) & 0x0fff0000UL) +#define V4L2_CTRL_DRIVER_PRIV(id) (((id) & 0xffff) >= 0x1000) + +/* Used in the VIDIOC_QUERYCTRL ioctl for querying controls */ +struct <link linkend="v4l2-queryctrl">v4l2_queryctrl</link> { + __u32 id; + enum <link linkend="v4l2-ctrl-type">v4l2_ctrl_type</link> type; + __u8 name[32]; /* Whatever */ + __s32 minimum; /* Note signedness */ + __s32 maximum; + __s32 step; + __s32 default_value; + __u32 flags; + __u32 reserved[2]; +}; + +/* Used in the VIDIOC_QUERYMENU ioctl for querying menu items */ +struct <link linkend="v4l2-querymenu">v4l2_querymenu</link> { + __u32 id; + __u32 index; + __u8 name[32]; /* Whatever */ + __u32 reserved; +}; + +/* Control flags */ +#define V4L2_CTRL_FLAG_DISABLED 0x0001 +#define V4L2_CTRL_FLAG_GRABBED 0x0002 +#define V4L2_CTRL_FLAG_READ_ONLY 0x0004 +#define V4L2_CTRL_FLAG_UPDATE 0x0008 +#define V4L2_CTRL_FLAG_INACTIVE 0x0010 +#define V4L2_CTRL_FLAG_SLIDER 0x0020 +#define V4L2_CTRL_FLAG_WRITE_ONLY 0x0040 + +/* Query flag, to be ORed with the control ID */ +#define V4L2_CTRL_FLAG_NEXT_CTRL 0x80000000 + +/* User-class control IDs defined by V4L2 */ +#define V4L2_CID_BASE (V4L2_CTRL_CLASS_USER | 0x900) +#define V4L2_CID_USER_BASE V4L2_CID_BASE +/* IDs reserved for driver specific controls */ +#define V4L2_CID_PRIVATE_BASE 0x08000000 + +#define V4L2_CID_USER_CLASS (V4L2_CTRL_CLASS_USER | 1) +#define V4L2_CID_BRIGHTNESS (V4L2_CID_BASE+0) +#define V4L2_CID_CONTRAST (V4L2_CID_BASE+1) +#define V4L2_CID_SATURATION (V4L2_CID_BASE+2) +#define V4L2_CID_HUE (V4L2_CID_BASE+3) +#define V4L2_CID_AUDIO_VOLUME (V4L2_CID_BASE+5) +#define V4L2_CID_AUDIO_BALANCE (V4L2_CID_BASE+6) +#define V4L2_CID_AUDIO_BASS (V4L2_CID_BASE+7) +#define V4L2_CID_AUDIO_TREBLE (V4L2_CID_BASE+8) +#define V4L2_CID_AUDIO_MUTE (V4L2_CID_BASE+9) +#define V4L2_CID_AUDIO_LOUDNESS (V4L2_CID_BASE+10) +#define V4L2_CID_BLACK_LEVEL (V4L2_CID_BASE+11) /* Deprecated */ +#define V4L2_CID_AUTO_WHITE_BALANCE (V4L2_CID_BASE+12) +#define V4L2_CID_DO_WHITE_BALANCE (V4L2_CID_BASE+13) +#define V4L2_CID_RED_BALANCE (V4L2_CID_BASE+14) +#define V4L2_CID_BLUE_BALANCE (V4L2_CID_BASE+15) +#define V4L2_CID_GAMMA (V4L2_CID_BASE+16) +#define V4L2_CID_WHITENESS (V4L2_CID_GAMMA) /* Deprecated */ +#define V4L2_CID_EXPOSURE (V4L2_CID_BASE+17) +#define V4L2_CID_AUTOGAIN (V4L2_CID_BASE+18) +#define V4L2_CID_GAIN (V4L2_CID_BASE+19) +#define V4L2_CID_HFLIP (V4L2_CID_BASE+20) +#define V4L2_CID_VFLIP (V4L2_CID_BASE+21) + +/* Deprecated; use V4L2_CID_PAN_RESET and V4L2_CID_TILT_RESET */ +#define V4L2_CID_HCENTER (V4L2_CID_BASE+22) +#define V4L2_CID_VCENTER (V4L2_CID_BASE+23) + +#define V4L2_CID_POWER_LINE_FREQUENCY (V4L2_CID_BASE+24) +enum <link linkend="v4l2-power-line-frequency">v4l2_power_line_frequency</link> { + V4L2_CID_POWER_LINE_FREQUENCY_DISABLED = 0, + V4L2_CID_POWER_LINE_FREQUENCY_50HZ = 1, + V4L2_CID_POWER_LINE_FREQUENCY_60HZ = 2, +}; +#define V4L2_CID_HUE_AUTO (V4L2_CID_BASE+25) +#define V4L2_CID_WHITE_BALANCE_TEMPERATURE (V4L2_CID_BASE+26) +#define V4L2_CID_SHARPNESS (V4L2_CID_BASE+27) +#define V4L2_CID_BACKLIGHT_COMPENSATION (V4L2_CID_BASE+28) +#define V4L2_CID_CHROMA_AGC (V4L2_CID_BASE+29) +#define V4L2_CID_COLOR_KILLER (V4L2_CID_BASE+30) +#define V4L2_CID_COLORFX (V4L2_CID_BASE+31) +enum <link linkend="v4l2-colorfx">v4l2_colorfx</link> { + V4L2_COLORFX_NONE = 0, + V4L2_COLORFX_BW = 1, + V4L2_COLORFX_SEPIA = 2, +}; +#define V4L2_CID_AUTOBRIGHTNESS (V4L2_CID_BASE+32) +#define V4L2_CID_BAND_STOP_FILTER (V4L2_CID_BASE+33) + +#define V4L2_CID_ROTATE (V4L2_CID_BASE+34) +#define V4L2_CID_BG_COLOR (V4L2_CID_BASE+35) +/* last CID + 1 */ +#define V4L2_CID_LASTP1 (V4L2_CID_BASE+36) + +/* MPEG-class control IDs defined by V4L2 */ +#define V4L2_CID_MPEG_BASE (V4L2_CTRL_CLASS_MPEG | 0x900) +#define V4L2_CID_MPEG_CLASS (V4L2_CTRL_CLASS_MPEG | 1) + +/* MPEG streams */ +#define V4L2_CID_MPEG_STREAM_TYPE (V4L2_CID_MPEG_BASE+0) +enum <link linkend="v4l2-mpeg-stream-type">v4l2_mpeg_stream_type</link> { + V4L2_MPEG_STREAM_TYPE_MPEG2_PS = 0, /* MPEG-2 program stream */ + V4L2_MPEG_STREAM_TYPE_MPEG2_TS = 1, /* MPEG-2 transport stream */ + V4L2_MPEG_STREAM_TYPE_MPEG1_SS = 2, /* MPEG-1 system stream */ + V4L2_MPEG_STREAM_TYPE_MPEG2_DVD = 3, /* MPEG-2 DVD-compatible stream */ + V4L2_MPEG_STREAM_TYPE_MPEG1_VCD = 4, /* MPEG-1 VCD-compatible stream */ + V4L2_MPEG_STREAM_TYPE_MPEG2_SVCD = 5, /* MPEG-2 SVCD-compatible stream */ +}; +#define V4L2_CID_MPEG_STREAM_PID_PMT (V4L2_CID_MPEG_BASE+1) +#define V4L2_CID_MPEG_STREAM_PID_AUDIO (V4L2_CID_MPEG_BASE+2) +#define V4L2_CID_MPEG_STREAM_PID_VIDEO (V4L2_CID_MPEG_BASE+3) +#define V4L2_CID_MPEG_STREAM_PID_PCR (V4L2_CID_MPEG_BASE+4) +#define V4L2_CID_MPEG_STREAM_PES_ID_AUDIO (V4L2_CID_MPEG_BASE+5) +#define V4L2_CID_MPEG_STREAM_PES_ID_VIDEO (V4L2_CID_MPEG_BASE+6) +#define V4L2_CID_MPEG_STREAM_VBI_FMT (V4L2_CID_MPEG_BASE+7) +enum <link linkend="v4l2-mpeg-stream-vbi-fmt">v4l2_mpeg_stream_vbi_fmt</link> { + V4L2_MPEG_STREAM_VBI_FMT_NONE = 0, /* No VBI in the MPEG stream */ + V4L2_MPEG_STREAM_VBI_FMT_IVTV = 1, /* VBI in private packets, IVTV format */ +}; + +/* MPEG audio */ +#define V4L2_CID_MPEG_AUDIO_SAMPLING_FREQ (V4L2_CID_MPEG_BASE+100) +enum <link linkend="v4l2-mpeg-audio-sampling-freq">v4l2_mpeg_audio_sampling_freq</link> { + V4L2_MPEG_AUDIO_SAMPLING_FREQ_44100 = 0, + V4L2_MPEG_AUDIO_SAMPLING_FREQ_48000 = 1, + V4L2_MPEG_AUDIO_SAMPLING_FREQ_32000 = 2, +}; +#define V4L2_CID_MPEG_AUDIO_ENCODING (V4L2_CID_MPEG_BASE+101) +enum <link linkend="v4l2-mpeg-audio-encoding">v4l2_mpeg_audio_encoding</link> { + V4L2_MPEG_AUDIO_ENCODING_LAYER_1 = 0, + V4L2_MPEG_AUDIO_ENCODING_LAYER_2 = 1, + V4L2_MPEG_AUDIO_ENCODING_LAYER_3 = 2, + V4L2_MPEG_AUDIO_ENCODING_AAC = 3, + V4L2_MPEG_AUDIO_ENCODING_AC3 = 4, +}; +#define V4L2_CID_MPEG_AUDIO_L1_BITRATE (V4L2_CID_MPEG_BASE+102) +enum <link linkend="v4l2-mpeg-audio-l1-bitrate">v4l2_mpeg_audio_l1_bitrate</link> { + V4L2_MPEG_AUDIO_L1_BITRATE_32K = 0, + V4L2_MPEG_AUDIO_L1_BITRATE_64K = 1, + V4L2_MPEG_AUDIO_L1_BITRATE_96K = 2, + V4L2_MPEG_AUDIO_L1_BITRATE_128K = 3, + V4L2_MPEG_AUDIO_L1_BITRATE_160K = 4, + V4L2_MPEG_AUDIO_L1_BITRATE_192K = 5, + V4L2_MPEG_AUDIO_L1_BITRATE_224K = 6, + V4L2_MPEG_AUDIO_L1_BITRATE_256K = 7, + V4L2_MPEG_AUDIO_L1_BITRATE_288K = 8, + V4L2_MPEG_AUDIO_L1_BITRATE_320K = 9, + V4L2_MPEG_AUDIO_L1_BITRATE_352K = 10, + V4L2_MPEG_AUDIO_L1_BITRATE_384K = 11, + V4L2_MPEG_AUDIO_L1_BITRATE_416K = 12, + V4L2_MPEG_AUDIO_L1_BITRATE_448K = 13, +}; +#define V4L2_CID_MPEG_AUDIO_L2_BITRATE (V4L2_CID_MPEG_BASE+103) +enum <link linkend="v4l2-mpeg-audio-l2-bitrate">v4l2_mpeg_audio_l2_bitrate</link> { + V4L2_MPEG_AUDIO_L2_BITRATE_32K = 0, + V4L2_MPEG_AUDIO_L2_BITRATE_48K = 1, + V4L2_MPEG_AUDIO_L2_BITRATE_56K = 2, + V4L2_MPEG_AUDIO_L2_BITRATE_64K = 3, + V4L2_MPEG_AUDIO_L2_BITRATE_80K = 4, + V4L2_MPEG_AUDIO_L2_BITRATE_96K = 5, + V4L2_MPEG_AUDIO_L2_BITRATE_112K = 6, + V4L2_MPEG_AUDIO_L2_BITRATE_128K = 7, + V4L2_MPEG_AUDIO_L2_BITRATE_160K = 8, + V4L2_MPEG_AUDIO_L2_BITRATE_192K = 9, + V4L2_MPEG_AUDIO_L2_BITRATE_224K = 10, + V4L2_MPEG_AUDIO_L2_BITRATE_256K = 11, + V4L2_MPEG_AUDIO_L2_BITRATE_320K = 12, + V4L2_MPEG_AUDIO_L2_BITRATE_384K = 13, +}; +#define V4L2_CID_MPEG_AUDIO_L3_BITRATE (V4L2_CID_MPEG_BASE+104) +enum <link linkend="v4l2-mpeg-audio-l3-bitrate">v4l2_mpeg_audio_l3_bitrate</link> { + V4L2_MPEG_AUDIO_L3_BITRATE_32K = 0, + V4L2_MPEG_AUDIO_L3_BITRATE_40K = 1, + V4L2_MPEG_AUDIO_L3_BITRATE_48K = 2, + V4L2_MPEG_AUDIO_L3_BITRATE_56K = 3, + V4L2_MPEG_AUDIO_L3_BITRATE_64K = 4, + V4L2_MPEG_AUDIO_L3_BITRATE_80K = 5, + V4L2_MPEG_AUDIO_L3_BITRATE_96K = 6, + V4L2_MPEG_AUDIO_L3_BITRATE_112K = 7, + V4L2_MPEG_AUDIO_L3_BITRATE_128K = 8, + V4L2_MPEG_AUDIO_L3_BITRATE_160K = 9, + V4L2_MPEG_AUDIO_L3_BITRATE_192K = 10, + V4L2_MPEG_AUDIO_L3_BITRATE_224K = 11, + V4L2_MPEG_AUDIO_L3_BITRATE_256K = 12, + V4L2_MPEG_AUDIO_L3_BITRATE_320K = 13, +}; +#define V4L2_CID_MPEG_AUDIO_MODE (V4L2_CID_MPEG_BASE+105) +enum <link linkend="v4l2-mpeg-audio-mode">v4l2_mpeg_audio_mode</link> { + V4L2_MPEG_AUDIO_MODE_STEREO = 0, + V4L2_MPEG_AUDIO_MODE_JOINT_STEREO = 1, + V4L2_MPEG_AUDIO_MODE_DUAL = 2, + V4L2_MPEG_AUDIO_MODE_MONO = 3, +}; +#define V4L2_CID_MPEG_AUDIO_MODE_EXTENSION (V4L2_CID_MPEG_BASE+106) +enum <link linkend="v4l2-mpeg-audio-mode-extension">v4l2_mpeg_audio_mode_extension</link> { + V4L2_MPEG_AUDIO_MODE_EXTENSION_BOUND_4 = 0, + V4L2_MPEG_AUDIO_MODE_EXTENSION_BOUND_8 = 1, + V4L2_MPEG_AUDIO_MODE_EXTENSION_BOUND_12 = 2, + V4L2_MPEG_AUDIO_MODE_EXTENSION_BOUND_16 = 3, +}; +#define V4L2_CID_MPEG_AUDIO_EMPHASIS (V4L2_CID_MPEG_BASE+107) +enum <link linkend="v4l2-mpeg-audio-emphasis">v4l2_mpeg_audio_emphasis</link> { + V4L2_MPEG_AUDIO_EMPHASIS_NONE = 0, + V4L2_MPEG_AUDIO_EMPHASIS_50_DIV_15_uS = 1, + V4L2_MPEG_AUDIO_EMPHASIS_CCITT_J17 = 2, +}; +#define V4L2_CID_MPEG_AUDIO_CRC (V4L2_CID_MPEG_BASE+108) +enum <link linkend="v4l2-mpeg-audio-crc">v4l2_mpeg_audio_crc</link> { + V4L2_MPEG_AUDIO_CRC_NONE = 0, + V4L2_MPEG_AUDIO_CRC_CRC16 = 1, +}; +#define V4L2_CID_MPEG_AUDIO_MUTE (V4L2_CID_MPEG_BASE+109) +#define V4L2_CID_MPEG_AUDIO_AAC_BITRATE (V4L2_CID_MPEG_BASE+110) +#define V4L2_CID_MPEG_AUDIO_AC3_BITRATE (V4L2_CID_MPEG_BASE+111) +enum <link linkend="v4l2-mpeg-audio-ac3-bitrate">v4l2_mpeg_audio_ac3_bitrate</link> { + V4L2_MPEG_AUDIO_AC3_BITRATE_32K = 0, + V4L2_MPEG_AUDIO_AC3_BITRATE_40K = 1, + V4L2_MPEG_AUDIO_AC3_BITRATE_48K = 2, + V4L2_MPEG_AUDIO_AC3_BITRATE_56K = 3, + V4L2_MPEG_AUDIO_AC3_BITRATE_64K = 4, + V4L2_MPEG_AUDIO_AC3_BITRATE_80K = 5, + V4L2_MPEG_AUDIO_AC3_BITRATE_96K = 6, + V4L2_MPEG_AUDIO_AC3_BITRATE_112K = 7, + V4L2_MPEG_AUDIO_AC3_BITRATE_128K = 8, + V4L2_MPEG_AUDIO_AC3_BITRATE_160K = 9, + V4L2_MPEG_AUDIO_AC3_BITRATE_192K = 10, + V4L2_MPEG_AUDIO_AC3_BITRATE_224K = 11, + V4L2_MPEG_AUDIO_AC3_BITRATE_256K = 12, + V4L2_MPEG_AUDIO_AC3_BITRATE_320K = 13, + V4L2_MPEG_AUDIO_AC3_BITRATE_384K = 14, + V4L2_MPEG_AUDIO_AC3_BITRATE_448K = 15, + V4L2_MPEG_AUDIO_AC3_BITRATE_512K = 16, + V4L2_MPEG_AUDIO_AC3_BITRATE_576K = 17, + V4L2_MPEG_AUDIO_AC3_BITRATE_640K = 18, +}; + +/* MPEG video */ +#define V4L2_CID_MPEG_VIDEO_ENCODING (V4L2_CID_MPEG_BASE+200) +enum <link linkend="v4l2-mpeg-video-encoding">v4l2_mpeg_video_encoding</link> { + V4L2_MPEG_VIDEO_ENCODING_MPEG_1 = 0, + V4L2_MPEG_VIDEO_ENCODING_MPEG_2 = 1, + V4L2_MPEG_VIDEO_ENCODING_MPEG_4_AVC = 2, +}; +#define V4L2_CID_MPEG_VIDEO_ASPECT (V4L2_CID_MPEG_BASE+201) +enum <link linkend="v4l2-mpeg-video-aspect">v4l2_mpeg_video_aspect</link> { + V4L2_MPEG_VIDEO_ASPECT_1x1 = 0, + V4L2_MPEG_VIDEO_ASPECT_4x3 = 1, + V4L2_MPEG_VIDEO_ASPECT_16x9 = 2, + V4L2_MPEG_VIDEO_ASPECT_221x100 = 3, +}; +#define V4L2_CID_MPEG_VIDEO_B_FRAMES (V4L2_CID_MPEG_BASE+202) +#define V4L2_CID_MPEG_VIDEO_GOP_SIZE (V4L2_CID_MPEG_BASE+203) +#define V4L2_CID_MPEG_VIDEO_GOP_CLOSURE (V4L2_CID_MPEG_BASE+204) +#define V4L2_CID_MPEG_VIDEO_PULLDOWN (V4L2_CID_MPEG_BASE+205) +#define V4L2_CID_MPEG_VIDEO_BITRATE_MODE (V4L2_CID_MPEG_BASE+206) +enum <link linkend="v4l2-mpeg-video-bitrate-mode">v4l2_mpeg_video_bitrate_mode</link> { + V4L2_MPEG_VIDEO_BITRATE_MODE_VBR = 0, + V4L2_MPEG_VIDEO_BITRATE_MODE_CBR = 1, +}; +#define V4L2_CID_MPEG_VIDEO_BITRATE (V4L2_CID_MPEG_BASE+207) +#define V4L2_CID_MPEG_VIDEO_BITRATE_PEAK (V4L2_CID_MPEG_BASE+208) +#define V4L2_CID_MPEG_VIDEO_TEMPORAL_DECIMATION (V4L2_CID_MPEG_BASE+209) +#define V4L2_CID_MPEG_VIDEO_MUTE (V4L2_CID_MPEG_BASE+210) +#define V4L2_CID_MPEG_VIDEO_MUTE_YUV (V4L2_CID_MPEG_BASE+211) + +/* MPEG-class control IDs specific to the CX2341x driver as defined by V4L2 */ +#define V4L2_CID_MPEG_CX2341X_BASE (V4L2_CTRL_CLASS_MPEG | 0x1000) +#define V4L2_CID_MPEG_CX2341X_VIDEO_SPATIAL_FILTER_MODE (V4L2_CID_MPEG_CX2341X_BASE+0) +enum <link linkend="v4l2-mpeg-cx2341x-video-spatial-filter-mode">v4l2_mpeg_cx2341x_video_spatial_filter_mode</link> { + V4L2_MPEG_CX2341X_VIDEO_SPATIAL_FILTER_MODE_MANUAL = 0, + V4L2_MPEG_CX2341X_VIDEO_SPATIAL_FILTER_MODE_AUTO = 1, +}; +#define V4L2_CID_MPEG_CX2341X_VIDEO_SPATIAL_FILTER (V4L2_CID_MPEG_CX2341X_BASE+1) +#define V4L2_CID_MPEG_CX2341X_VIDEO_LUMA_SPATIAL_FILTER_TYPE (V4L2_CID_MPEG_CX2341X_BASE+2) +enum <link linkend="luma-spatial-filter-type">v4l2_mpeg_cx2341x_video_luma_spatial_filter_type</link> { + V4L2_MPEG_CX2341X_VIDEO_LUMA_SPATIAL_FILTER_TYPE_OFF = 0, + V4L2_MPEG_CX2341X_VIDEO_LUMA_SPATIAL_FILTER_TYPE_1D_HOR = 1, + V4L2_MPEG_CX2341X_VIDEO_LUMA_SPATIAL_FILTER_TYPE_1D_VERT = 2, + V4L2_MPEG_CX2341X_VIDEO_LUMA_SPATIAL_FILTER_TYPE_2D_HV_SEPARABLE = 3, + V4L2_MPEG_CX2341X_VIDEO_LUMA_SPATIAL_FILTER_TYPE_2D_SYM_NON_SEPARABLE = 4, +}; +#define V4L2_CID_MPEG_CX2341X_VIDEO_CHROMA_SPATIAL_FILTER_TYPE (V4L2_CID_MPEG_CX2341X_BASE+3) +enum <link linkend="chroma-spatial-filter-type">v4l2_mpeg_cx2341x_video_chroma_spatial_filter_type</link> { + V4L2_MPEG_CX2341X_VIDEO_CHROMA_SPATIAL_FILTER_TYPE_OFF = 0, + V4L2_MPEG_CX2341X_VIDEO_CHROMA_SPATIAL_FILTER_TYPE_1D_HOR = 1, +}; +#define V4L2_CID_MPEG_CX2341X_VIDEO_TEMPORAL_FILTER_MODE (V4L2_CID_MPEG_CX2341X_BASE+4) +enum <link linkend="v4l2-mpeg-cx2341x-video-temporal-filter-mode">v4l2_mpeg_cx2341x_video_temporal_filter_mode</link> { + V4L2_MPEG_CX2341X_VIDEO_TEMPORAL_FILTER_MODE_MANUAL = 0, + V4L2_MPEG_CX2341X_VIDEO_TEMPORAL_FILTER_MODE_AUTO = 1, +}; +#define V4L2_CID_MPEG_CX2341X_VIDEO_TEMPORAL_FILTER (V4L2_CID_MPEG_CX2341X_BASE+5) +#define V4L2_CID_MPEG_CX2341X_VIDEO_MEDIAN_FILTER_TYPE (V4L2_CID_MPEG_CX2341X_BASE+6) +enum <link linkend="v4l2-mpeg-cx2341x-video-median-filter-type">v4l2_mpeg_cx2341x_video_median_filter_type</link> { + V4L2_MPEG_CX2341X_VIDEO_MEDIAN_FILTER_TYPE_OFF = 0, + V4L2_MPEG_CX2341X_VIDEO_MEDIAN_FILTER_TYPE_HOR = 1, + V4L2_MPEG_CX2341X_VIDEO_MEDIAN_FILTER_TYPE_VERT = 2, + V4L2_MPEG_CX2341X_VIDEO_MEDIAN_FILTER_TYPE_HOR_VERT = 3, + V4L2_MPEG_CX2341X_VIDEO_MEDIAN_FILTER_TYPE_DIAG = 4, +}; +#define V4L2_CID_MPEG_CX2341X_VIDEO_LUMA_MEDIAN_FILTER_BOTTOM (V4L2_CID_MPEG_CX2341X_BASE+7) +#define V4L2_CID_MPEG_CX2341X_VIDEO_LUMA_MEDIAN_FILTER_TOP (V4L2_CID_MPEG_CX2341X_BASE+8) +#define V4L2_CID_MPEG_CX2341X_VIDEO_CHROMA_MEDIAN_FILTER_BOTTOM (V4L2_CID_MPEG_CX2341X_BASE+9) +#define V4L2_CID_MPEG_CX2341X_VIDEO_CHROMA_MEDIAN_FILTER_TOP (V4L2_CID_MPEG_CX2341X_BASE+10) +#define V4L2_CID_MPEG_CX2341X_STREAM_INSERT_NAV_PACKETS (V4L2_CID_MPEG_CX2341X_BASE+11) + +/* Camera class control IDs */ +#define V4L2_CID_CAMERA_CLASS_BASE (V4L2_CTRL_CLASS_CAMERA | 0x900) +#define V4L2_CID_CAMERA_CLASS (V4L2_CTRL_CLASS_CAMERA | 1) + +#define V4L2_CID_EXPOSURE_AUTO (V4L2_CID_CAMERA_CLASS_BASE+1) +enum <link linkend="v4l2-exposure-auto-type">v4l2_exposure_auto_type</link> { + V4L2_EXPOSURE_AUTO = 0, + V4L2_EXPOSURE_MANUAL = 1, + V4L2_EXPOSURE_SHUTTER_PRIORITY = 2, + V4L2_EXPOSURE_APERTURE_PRIORITY = 3 +}; +#define V4L2_CID_EXPOSURE_ABSOLUTE (V4L2_CID_CAMERA_CLASS_BASE+2) +#define V4L2_CID_EXPOSURE_AUTO_PRIORITY (V4L2_CID_CAMERA_CLASS_BASE+3) + +#define V4L2_CID_PAN_RELATIVE (V4L2_CID_CAMERA_CLASS_BASE+4) +#define V4L2_CID_TILT_RELATIVE (V4L2_CID_CAMERA_CLASS_BASE+5) +#define V4L2_CID_PAN_RESET (V4L2_CID_CAMERA_CLASS_BASE+6) +#define V4L2_CID_TILT_RESET (V4L2_CID_CAMERA_CLASS_BASE+7) + +#define V4L2_CID_PAN_ABSOLUTE (V4L2_CID_CAMERA_CLASS_BASE+8) +#define V4L2_CID_TILT_ABSOLUTE (V4L2_CID_CAMERA_CLASS_BASE+9) + +#define V4L2_CID_FOCUS_ABSOLUTE (V4L2_CID_CAMERA_CLASS_BASE+10) +#define V4L2_CID_FOCUS_RELATIVE (V4L2_CID_CAMERA_CLASS_BASE+11) +#define V4L2_CID_FOCUS_AUTO (V4L2_CID_CAMERA_CLASS_BASE+12) + +#define V4L2_CID_ZOOM_ABSOLUTE (V4L2_CID_CAMERA_CLASS_BASE+13) +#define V4L2_CID_ZOOM_RELATIVE (V4L2_CID_CAMERA_CLASS_BASE+14) +#define V4L2_CID_ZOOM_CONTINUOUS (V4L2_CID_CAMERA_CLASS_BASE+15) + +#define V4L2_CID_PRIVACY (V4L2_CID_CAMERA_CLASS_BASE+16) + +/* FM Modulator class control IDs */ +#define V4L2_CID_FM_TX_CLASS_BASE (V4L2_CTRL_CLASS_FM_TX | 0x900) +#define V4L2_CID_FM_TX_CLASS (V4L2_CTRL_CLASS_FM_TX | 1) + +#define V4L2_CID_RDS_TX_DEVIATION (V4L2_CID_FM_TX_CLASS_BASE + 1) +#define V4L2_CID_RDS_TX_PI (V4L2_CID_FM_TX_CLASS_BASE + 2) +#define V4L2_CID_RDS_TX_PTY (V4L2_CID_FM_TX_CLASS_BASE + 3) +#define V4L2_CID_RDS_TX_PS_NAME (V4L2_CID_FM_TX_CLASS_BASE + 5) +#define V4L2_CID_RDS_TX_RADIO_TEXT (V4L2_CID_FM_TX_CLASS_BASE + 6) + +#define V4L2_CID_AUDIO_LIMITER_ENABLED (V4L2_CID_FM_TX_CLASS_BASE + 64) +#define V4L2_CID_AUDIO_LIMITER_RELEASE_TIME (V4L2_CID_FM_TX_CLASS_BASE + 65) +#define V4L2_CID_AUDIO_LIMITER_DEVIATION (V4L2_CID_FM_TX_CLASS_BASE + 66) + +#define V4L2_CID_AUDIO_COMPRESSION_ENABLED (V4L2_CID_FM_TX_CLASS_BASE + 80) +#define V4L2_CID_AUDIO_COMPRESSION_GAIN (V4L2_CID_FM_TX_CLASS_BASE + 81) +#define V4L2_CID_AUDIO_COMPRESSION_THRESHOLD (V4L2_CID_FM_TX_CLASS_BASE + 82) +#define V4L2_CID_AUDIO_COMPRESSION_ATTACK_TIME (V4L2_CID_FM_TX_CLASS_BASE + 83) +#define V4L2_CID_AUDIO_COMPRESSION_RELEASE_TIME (V4L2_CID_FM_TX_CLASS_BASE + 84) + +#define V4L2_CID_PILOT_TONE_ENABLED (V4L2_CID_FM_TX_CLASS_BASE + 96) +#define V4L2_CID_PILOT_TONE_DEVIATION (V4L2_CID_FM_TX_CLASS_BASE + 97) +#define V4L2_CID_PILOT_TONE_FREQUENCY (V4L2_CID_FM_TX_CLASS_BASE + 98) + +#define V4L2_CID_TUNE_PREEMPHASIS (V4L2_CID_FM_TX_CLASS_BASE + 112) +enum <link linkend="v4l2-preemphasis">v4l2_preemphasis</link> { + V4L2_PREEMPHASIS_DISABLED = 0, + V4L2_PREEMPHASIS_50_uS = 1, + V4L2_PREEMPHASIS_75_uS = 2, +}; +#define V4L2_CID_TUNE_POWER_LEVEL (V4L2_CID_FM_TX_CLASS_BASE + 113) +#define V4L2_CID_TUNE_ANTENNA_CAPACITOR (V4L2_CID_FM_TX_CLASS_BASE + 114) + +/* + * T U N I N G + */ +struct <link linkend="v4l2-tuner">v4l2_tuner</link> { + __u32 index; + __u8 name[32]; + enum <link linkend="v4l2-tuner-type">v4l2_tuner_type</link> type; + __u32 capability; + __u32 rangelow; + __u32 rangehigh; + __u32 rxsubchans; + __u32 audmode; + __s32 signal; + __s32 afc; + __u32 reserved[4]; +}; + +struct <link linkend="v4l2-modulator">v4l2_modulator</link> { + __u32 index; + __u8 name[32]; + __u32 capability; + __u32 rangelow; + __u32 rangehigh; + __u32 txsubchans; + __u32 reserved[4]; +}; + +/* Flags for the 'capability' field */ +#define V4L2_TUNER_CAP_LOW 0x0001 +#define V4L2_TUNER_CAP_NORM 0x0002 +#define V4L2_TUNER_CAP_STEREO 0x0010 +#define V4L2_TUNER_CAP_LANG2 0x0020 +#define V4L2_TUNER_CAP_SAP 0x0020 +#define V4L2_TUNER_CAP_LANG1 0x0040 +#define V4L2_TUNER_CAP_RDS 0x0080 + +/* Flags for the 'rxsubchans' field */ +#define V4L2_TUNER_SUB_MONO 0x0001 +#define V4L2_TUNER_SUB_STEREO 0x0002 +#define V4L2_TUNER_SUB_LANG2 0x0004 +#define V4L2_TUNER_SUB_SAP 0x0004 +#define V4L2_TUNER_SUB_LANG1 0x0008 +#define V4L2_TUNER_SUB_RDS 0x0010 + +/* Values for the 'audmode' field */ +#define V4L2_TUNER_MODE_MONO 0x0000 +#define V4L2_TUNER_MODE_STEREO 0x0001 +#define V4L2_TUNER_MODE_LANG2 0x0002 +#define V4L2_TUNER_MODE_SAP 0x0002 +#define V4L2_TUNER_MODE_LANG1 0x0003 +#define V4L2_TUNER_MODE_LANG1_LANG2 0x0004 + +struct <link linkend="v4l2-frequency">v4l2_frequency</link> { + __u32 tuner; + enum <link linkend="v4l2-tuner-type">v4l2_tuner_type</link> type; + __u32 frequency; + __u32 reserved[8]; +}; + +struct <link linkend="v4l2-hw-freq-seek">v4l2_hw_freq_seek</link> { + __u32 tuner; + enum <link linkend="v4l2-tuner-type">v4l2_tuner_type</link> type; + __u32 seek_upward; + __u32 wrap_around; + __u32 reserved[8]; +}; + +/* + * R D S + */ + +struct <link linkend="v4l2-rds-data">v4l2_rds_data</link> { + __u8 lsb; + __u8 msb; + __u8 block; +} __attribute__ ((packed)); + +#define V4L2_RDS_BLOCK_MSK 0x7 +#define V4L2_RDS_BLOCK_A 0 +#define V4L2_RDS_BLOCK_B 1 +#define V4L2_RDS_BLOCK_C 2 +#define V4L2_RDS_BLOCK_D 3 +#define V4L2_RDS_BLOCK_C_ALT 4 +#define V4L2_RDS_BLOCK_INVALID 7 + +#define V4L2_RDS_BLOCK_CORRECTED 0x40 +#define V4L2_RDS_BLOCK_ERROR 0x80 + +/* + * A U D I O + */ +struct <link linkend="v4l2-audio">v4l2_audio</link> { + __u32 index; + __u8 name[32]; + __u32 capability; + __u32 mode; + __u32 reserved[2]; +}; + +/* Flags for the 'capability' field */ +#define V4L2_AUDCAP_STEREO 0x00001 +#define V4L2_AUDCAP_AVL 0x00002 + +/* Flags for the 'mode' field */ +#define V4L2_AUDMODE_AVL 0x00001 + +struct <link linkend="v4l2-audioout">v4l2_audioout</link> { + __u32 index; + __u8 name[32]; + __u32 capability; + __u32 mode; + __u32 reserved[2]; +}; + +/* + * M P E G S E R V I C E S + * + * NOTE: EXPERIMENTAL API + */ +#if 1 /*KEEP*/ +#define V4L2_ENC_IDX_FRAME_I (0) +#define V4L2_ENC_IDX_FRAME_P (1) +#define V4L2_ENC_IDX_FRAME_B (2) +#define V4L2_ENC_IDX_FRAME_MASK (0xf) + +struct <link linkend="v4l2-enc-idx-entry">v4l2_enc_idx_entry</link> { + __u64 offset; + __u64 pts; + __u32 length; + __u32 flags; + __u32 reserved[2]; +}; + +#define V4L2_ENC_IDX_ENTRIES (64) +struct <link linkend="v4l2-enc-idx">v4l2_enc_idx</link> { + __u32 entries; + __u32 entries_cap; + __u32 reserved[4]; + struct <link linkend="v4l2-enc-idx-entry">v4l2_enc_idx_entry</link> entry[V4L2_ENC_IDX_ENTRIES]; +}; + + +#define V4L2_ENC_CMD_START (0) +#define V4L2_ENC_CMD_STOP (1) +#define V4L2_ENC_CMD_PAUSE (2) +#define V4L2_ENC_CMD_RESUME (3) + +/* Flags for V4L2_ENC_CMD_STOP */ +#define V4L2_ENC_CMD_STOP_AT_GOP_END (1 << 0) + +struct <link linkend="v4l2-encoder-cmd">v4l2_encoder_cmd</link> { + __u32 cmd; + __u32 flags; + union { + struct { + __u32 data[8]; + } raw; + }; +}; + +#endif + + +/* + * D A T A S E R V I C E S ( V B I ) + * + * Data services API by Michael Schimek + */ + +/* Raw VBI */ +struct <link linkend="v4l2-vbi-format">v4l2_vbi_format</link> { + __u32 sampling_rate; /* in 1 Hz */ + __u32 offset; + __u32 samples_per_line; + __u32 sample_format; /* V4L2_PIX_FMT_* */ + __s32 start[2]; + __u32 count[2]; + __u32 flags; /* V4L2_VBI_* */ + __u32 reserved[2]; /* must be zero */ +}; + +/* VBI flags */ +#define V4L2_VBI_UNSYNC (1 << 0) +#define V4L2_VBI_INTERLACED (1 << 1) + +/* Sliced VBI + * + * This implements is a proposal V4L2 API to allow SLICED VBI + * required for some hardware encoders. It should change without + * notice in the definitive implementation. + */ + +struct <link linkend="v4l2-sliced-vbi-format">v4l2_sliced_vbi_format</link> { + __u16 service_set; + /* service_lines[0][...] specifies lines 0-23 (1-23 used) of the first field + service_lines[1][...] specifies lines 0-23 (1-23 used) of the second field + (equals frame lines 313-336 for 625 line video + standards, 263-286 for 525 line standards) */ + __u16 service_lines[2][24]; + __u32 io_size; + __u32 reserved[2]; /* must be zero */ +}; + +/* Teletext World System Teletext + (WST), defined on ITU-R BT.653-2 */ +#define V4L2_SLICED_TELETEXT_B (0x0001) +/* Video Program System, defined on ETS 300 231*/ +#define V4L2_SLICED_VPS (0x0400) +/* Closed Caption, defined on EIA-608 */ +#define V4L2_SLICED_CAPTION_525 (0x1000) +/* Wide Screen System, defined on ITU-R BT1119.1 */ +#define V4L2_SLICED_WSS_625 (0x4000) + +#define V4L2_SLICED_VBI_525 (V4L2_SLICED_CAPTION_525) +#define V4L2_SLICED_VBI_625 (V4L2_SLICED_TELETEXT_B | V4L2_SLICED_VPS | V4L2_SLICED_WSS_625) + +struct <link linkend="v4l2-sliced-vbi-cap">v4l2_sliced_vbi_cap</link> { + __u16 service_set; + /* service_lines[0][...] specifies lines 0-23 (1-23 used) of the first field + service_lines[1][...] specifies lines 0-23 (1-23 used) of the second field + (equals frame lines 313-336 for 625 line video + standards, 263-286 for 525 line standards) */ + __u16 service_lines[2][24]; + enum <link linkend="v4l2-buf-type">v4l2_buf_type</link> type; + __u32 reserved[3]; /* must be 0 */ +}; + +struct <link linkend="v4l2-sliced-vbi-data">v4l2_sliced_vbi_data</link> { + __u32 id; + __u32 field; /* 0: first field, 1: second field */ + __u32 line; /* 1-23 */ + __u32 reserved; /* must be 0 */ + __u8 data[48]; +}; + +/* + * Sliced VBI data inserted into MPEG Streams + */ + +/* + * V4L2_MPEG_STREAM_VBI_FMT_IVTV: + * + * Structure of payload contained in an MPEG 2 Private Stream 1 PES Packet in an + * MPEG-2 Program Pack that contains V4L2_MPEG_STREAM_VBI_FMT_IVTV Sliced VBI + * data + * + * Note, the MPEG-2 Program Pack and Private Stream 1 PES packet header + * definitions are not included here. See the MPEG-2 specifications for details + * on these headers. + */ + +/* Line type IDs */ +#define V4L2_MPEG_VBI_IVTV_TELETEXT_B (1) +#define V4L2_MPEG_VBI_IVTV_CAPTION_525 (4) +#define V4L2_MPEG_VBI_IVTV_WSS_625 (5) +#define V4L2_MPEG_VBI_IVTV_VPS (7) + +struct <link linkend="v4l2-mpeg-vbi-itv0-line">v4l2_mpeg_vbi_itv0_line</link> { + __u8 id; /* One of V4L2_MPEG_VBI_IVTV_* above */ + __u8 data[42]; /* Sliced VBI data for the line */ +} __attribute__ ((packed)); + +struct <link linkend="v4l2-mpeg-vbi-itv0">v4l2_mpeg_vbi_itv0</link> { + __le32 linemask[2]; /* Bitmasks of VBI service lines present */ + struct <link linkend="v4l2-mpeg-vbi-itv0-line">v4l2_mpeg_vbi_itv0_line</link> line[35]; +} __attribute__ ((packed)); + +struct <link linkend="v4l2-mpeg-vbi-itv0-1">v4l2_mpeg_vbi_ITV0</link> { + struct <link linkend="v4l2-mpeg-vbi-itv0-line">v4l2_mpeg_vbi_itv0_line</link> line[36]; +} __attribute__ ((packed)); + +#define V4L2_MPEG_VBI_IVTV_MAGIC0 "itv0" +#define V4L2_MPEG_VBI_IVTV_MAGIC1 "ITV0" + +struct <link linkend="v4l2-mpeg-vbi-fmt-ivtv">v4l2_mpeg_vbi_fmt_ivtv</link> { + __u8 magic[4]; + union { + struct <link linkend="v4l2-mpeg-vbi-itv0">v4l2_mpeg_vbi_itv0</link> itv0; + struct <link linkend="v4l2-mpeg-vbi-itv0-1">v4l2_mpeg_vbi_ITV0</link> ITV0; + }; +} __attribute__ ((packed)); + +/* + * 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-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-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 */ + __u8 raw_data[200]; /* user-defined */ + } fmt; +}; + + +/* Stream type-dependent parameters + */ +struct <link linkend="v4l2-streamparm">v4l2_streamparm</link> { + enum <link linkend="v4l2-buf-type">v4l2_buf_type</link> type; + union { + struct <link linkend="v4l2-captureparm">v4l2_captureparm</link> capture; + struct <link linkend="v4l2-outputparm">v4l2_outputparm</link> output; + __u8 raw_data[200]; /* user-defined */ + } parm; +}; + +/* + * A D V A N C E D D E B U G G I N G + * + * NOTE: EXPERIMENTAL API, NEVER RELY ON THIS IN APPLICATIONS! + * FOR DEBUGGING, TESTING AND INTERNAL USE ONLY! + */ + +/* VIDIOC_DBG_G_REGISTER and VIDIOC_DBG_S_REGISTER */ + +#define V4L2_CHIP_MATCH_HOST 0 /* Match against chip ID on host (0 for the host) */ +#define V4L2_CHIP_MATCH_I2C_DRIVER 1 /* Match against I2C driver name */ +#define V4L2_CHIP_MATCH_I2C_ADDR 2 /* Match against I2C 7-bit address */ +#define V4L2_CHIP_MATCH_AC97 3 /* Match against anciliary AC97 chip */ + +struct <link linkend="v4l2-dbg-match">v4l2_dbg_match</link> { + __u32 type; /* Match type */ + union { /* Match this chip, meaning determined by type */ + __u32 addr; + char name[32]; + }; +} __attribute__ ((packed)); + +struct <link linkend="v4l2-dbg-register">v4l2_dbg_register</link> { + struct <link linkend="v4l2-dbg-match">v4l2_dbg_match</link> match; + __u32 size; /* register size in bytes */ + __u64 reg; + __u64 val; +} __attribute__ ((packed)); + +/* VIDIOC_DBG_G_CHIP_IDENT */ +struct <link linkend="v4l2-dbg-chip-ident">v4l2_dbg_chip_ident</link> { + struct <link linkend="v4l2-dbg-match">v4l2_dbg_match</link> match; + __u32 ident; /* chip identifier as specified in <media/v4l2-chip-ident.h> */ + __u32 revision; /* chip revision, chip specific */ +} __attribute__ ((packed)); + +/* + * I O C T L C O D E S F O R V I D E O D E V I C E S + * + */ +#define VIDIOC_QUERYCAP _IOR('V', 0, struct <link linkend="v4l2-capability">v4l2_capability</link>) +#define VIDIOC_RESERVED _IO('V', 1) +#define VIDIOC_ENUM_FMT _IOWR('V', 2, struct <link linkend="v4l2-fmtdesc">v4l2_fmtdesc</link>) +#define VIDIOC_G_FMT _IOWR('V', 4, struct <link linkend="v4l2-format">v4l2_format</link>) +#define VIDIOC_S_FMT _IOWR('V', 5, struct <link linkend="v4l2-format">v4l2_format</link>) +#define VIDIOC_REQBUFS _IOWR('V', 8, struct <link linkend="v4l2-requestbuffers">v4l2_requestbuffers</link>) +#define VIDIOC_QUERYBUF _IOWR('V', 9, struct <link linkend="v4l2-buffer">v4l2_buffer</link>) +#define VIDIOC_G_FBUF _IOR('V', 10, struct <link linkend="v4l2-framebuffer">v4l2_framebuffer</link>) +#define VIDIOC_S_FBUF _IOW('V', 11, struct <link linkend="v4l2-framebuffer">v4l2_framebuffer</link>) +#define VIDIOC_OVERLAY _IOW('V', 14, int) +#define VIDIOC_QBUF _IOWR('V', 15, struct <link linkend="v4l2-buffer">v4l2_buffer</link>) +#define VIDIOC_DQBUF _IOWR('V', 17, struct <link linkend="v4l2-buffer">v4l2_buffer</link>) +#define VIDIOC_STREAMON _IOW('V', 18, int) +#define VIDIOC_STREAMOFF _IOW('V', 19, int) +#define VIDIOC_G_PARM _IOWR('V', 21, struct <link linkend="v4l2-streamparm">v4l2_streamparm</link>) +#define VIDIOC_S_PARM _IOWR('V', 22, struct <link linkend="v4l2-streamparm">v4l2_streamparm</link>) +#define VIDIOC_G_STD _IOR('V', 23, v4l2_std_id) +#define VIDIOC_S_STD _IOW('V', 24, v4l2_std_id) +#define VIDIOC_ENUMSTD _IOWR('V', 25, struct <link linkend="v4l2-standard">v4l2_standard</link>) +#define VIDIOC_ENUMINPUT _IOWR('V', 26, struct <link linkend="v4l2-input">v4l2_input</link>) +#define VIDIOC_G_CTRL _IOWR('V', 27, struct <link linkend="v4l2-control">v4l2_control</link>) +#define VIDIOC_S_CTRL _IOWR('V', 28, struct <link linkend="v4l2-control">v4l2_control</link>) +#define VIDIOC_G_TUNER _IOWR('V', 29, struct <link linkend="v4l2-tuner">v4l2_tuner</link>) +#define VIDIOC_S_TUNER _IOW('V', 30, struct <link linkend="v4l2-tuner">v4l2_tuner</link>) +#define VIDIOC_G_AUDIO _IOR('V', 33, struct <link linkend="v4l2-audio">v4l2_audio</link>) +#define VIDIOC_S_AUDIO _IOW('V', 34, struct <link linkend="v4l2-audio">v4l2_audio</link>) +#define VIDIOC_QUERYCTRL _IOWR('V', 36, struct <link linkend="v4l2-queryctrl">v4l2_queryctrl</link>) +#define VIDIOC_QUERYMENU _IOWR('V', 37, struct <link linkend="v4l2-querymenu">v4l2_querymenu</link>) +#define VIDIOC_G_INPUT _IOR('V', 38, int) +#define VIDIOC_S_INPUT _IOWR('V', 39, int) +#define VIDIOC_G_OUTPUT _IOR('V', 46, int) +#define VIDIOC_S_OUTPUT _IOWR('V', 47, int) +#define VIDIOC_ENUMOUTPUT _IOWR('V', 48, struct <link linkend="v4l2-output">v4l2_output</link>) +#define VIDIOC_G_AUDOUT _IOR('V', 49, struct <link linkend="v4l2-audioout">v4l2_audioout</link>) +#define VIDIOC_S_AUDOUT _IOW('V', 50, struct <link linkend="v4l2-audioout">v4l2_audioout</link>) +#define VIDIOC_G_MODULATOR _IOWR('V', 54, struct <link linkend="v4l2-modulator">v4l2_modulator</link>) +#define VIDIOC_S_MODULATOR _IOW('V', 55, struct <link linkend="v4l2-modulator">v4l2_modulator</link>) +#define VIDIOC_G_FREQUENCY _IOWR('V', 56, struct <link linkend="v4l2-frequency">v4l2_frequency</link>) +#define VIDIOC_S_FREQUENCY _IOW('V', 57, struct <link linkend="v4l2-frequency">v4l2_frequency</link>) +#define VIDIOC_CROPCAP _IOWR('V', 58, struct <link linkend="v4l2-cropcap">v4l2_cropcap</link>) +#define VIDIOC_G_CROP _IOWR('V', 59, struct <link linkend="v4l2-crop">v4l2_crop</link>) +#define VIDIOC_S_CROP _IOW('V', 60, struct <link linkend="v4l2-crop">v4l2_crop</link>) +#define VIDIOC_G_JPEGCOMP _IOR('V', 61, struct <link linkend="v4l2-jpegcompression">v4l2_jpegcompression</link>) +#define VIDIOC_S_JPEGCOMP _IOW('V', 62, struct <link linkend="v4l2-jpegcompression">v4l2_jpegcompression</link>) +#define VIDIOC_QUERYSTD _IOR('V', 63, v4l2_std_id) +#define VIDIOC_TRY_FMT _IOWR('V', 64, struct <link linkend="v4l2-format">v4l2_format</link>) +#define VIDIOC_ENUMAUDIO _IOWR('V', 65, struct <link linkend="v4l2-audio">v4l2_audio</link>) +#define VIDIOC_ENUMAUDOUT _IOWR('V', 66, struct <link linkend="v4l2-audioout">v4l2_audioout</link>) +#define VIDIOC_G_PRIORITY _IOR('V', 67, enum <link linkend="v4l2-priority">v4l2_priority</link>) +#define VIDIOC_S_PRIORITY _IOW('V', 68, enum <link linkend="v4l2-priority">v4l2_priority</link>) +#define VIDIOC_G_SLICED_VBI_CAP _IOWR('V', 69, struct <link linkend="v4l2-sliced-vbi-cap">v4l2_sliced_vbi_cap</link>) +#define VIDIOC_LOG_STATUS _IO('V', 70) +#define VIDIOC_G_EXT_CTRLS _IOWR('V', 71, struct <link linkend="v4l2-ext-controls">v4l2_ext_controls</link>) +#define VIDIOC_S_EXT_CTRLS _IOWR('V', 72, struct <link linkend="v4l2-ext-controls">v4l2_ext_controls</link>) +#define VIDIOC_TRY_EXT_CTRLS _IOWR('V', 73, struct <link linkend="v4l2-ext-controls">v4l2_ext_controls</link>) +#if 1 /*KEEP*/ +#define VIDIOC_ENUM_FRAMESIZES _IOWR('V', 74, struct <link linkend="v4l2-frmsizeenum">v4l2_frmsizeenum</link>) +#define VIDIOC_ENUM_FRAMEINTERVALS _IOWR('V', 75, struct <link linkend="v4l2-frmivalenum">v4l2_frmivalenum</link>) +#define VIDIOC_G_ENC_INDEX _IOR('V', 76, struct <link linkend="v4l2-enc-idx">v4l2_enc_idx</link>) +#define VIDIOC_ENCODER_CMD _IOWR('V', 77, struct <link linkend="v4l2-encoder-cmd">v4l2_encoder_cmd</link>) +#define VIDIOC_TRY_ENCODER_CMD _IOWR('V', 78, struct <link linkend="v4l2-encoder-cmd">v4l2_encoder_cmd</link>) +#endif + +#if 1 /*KEEP*/ +/* Experimental, meant for debugging, testing and internal use. + Only implemented if CONFIG_VIDEO_ADV_DEBUG is defined. + You must be root to use these ioctls. Never use these in applications! */ +#define VIDIOC_DBG_S_REGISTER _IOW('V', 79, struct <link linkend="v4l2-dbg-register">v4l2_dbg_register</link>) +#define VIDIOC_DBG_G_REGISTER _IOWR('V', 80, struct <link linkend="v4l2-dbg-register">v4l2_dbg_register</link>) + +/* Experimental, meant for debugging, testing and internal use. + Never use this ioctl in applications! */ +#define VIDIOC_DBG_G_CHIP_IDENT _IOWR('V', 81, struct <link linkend="v4l2-dbg-chip-ident">v4l2_dbg_chip_ident</link>) +#endif + +#define VIDIOC_S_HW_FREQ_SEEK _IOW('V', 82, struct <link linkend="v4l2-hw-freq-seek">v4l2_hw_freq_seek</link>) +#define VIDIOC_ENUM_DV_PRESETS _IOWR('V', 83, struct <link linkend="v4l2-dv-enum-preset">v4l2_dv_enum_preset</link>) +#define VIDIOC_S_DV_PRESET _IOWR('V', 84, struct <link linkend="v4l2-dv-preset">v4l2_dv_preset</link>) +#define VIDIOC_G_DV_PRESET _IOWR('V', 85, struct <link linkend="v4l2-dv-preset">v4l2_dv_preset</link>) +#define VIDIOC_QUERY_DV_PRESET _IOR('V', 86, struct <link linkend="v4l2-dv-preset">v4l2_dv_preset</link>) +#define VIDIOC_S_DV_TIMINGS _IOWR('V', 87, struct <link linkend="v4l2-dv-timings">v4l2_dv_timings</link>) +#define VIDIOC_G_DV_TIMINGS _IOWR('V', 88, struct <link linkend="v4l2-dv-timings">v4l2_dv_timings</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 */ +</programlisting> diff --git a/Documentation/DocBook/v4l/vidioc-cropcap.xml b/Documentation/DocBook/v4l/vidioc-cropcap.xml new file mode 100644 index 000000000000..816e90e283c5 --- /dev/null +++ b/Documentation/DocBook/v4l/vidioc-cropcap.xml @@ -0,0 +1,174 @@ +<refentry id="vidioc-cropcap"> + <refmeta> + <refentrytitle>ioctl VIDIOC_CROPCAP</refentrytitle> + &manvol; + </refmeta> + + <refnamediv> + <refname>VIDIOC_CROPCAP</refname> + <refpurpose>Information about the video cropping and scaling abilities</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_cropcap +*<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_CROPCAP</para> + </listitem> + </varlistentry> + <varlistentry> + <term><parameter>argp</parameter></term> + <listitem> + <para></para> + </listitem> + </varlistentry> + </variablelist> + </refsect1> + + <refsect1> + <title>Description</title> + + <para>Applications use this function to query the cropping +limits, the pixel aspect of images and to calculate scale factors. +They set the <structfield>type</structfield> field of a v4l2_cropcap +structure to the respective buffer (stream) type and call the +<constant>VIDIOC_CROPCAP</constant> ioctl with a pointer to this +structure. Drivers fill the rest of the structure. The results are +constant except when switching the video standard. Remember this +switch can occur implicit when switching the video input or +output.</para> + + <table pgwide="1" frame="none" id="v4l2-cropcap"> + <title>struct <structname>v4l2_cropcap</structname></title> + <tgroup cols="3"> + &cs-str; + <tbody valign="top"> + <row> + <entry>&v4l2-buf-type;</entry> + <entry><structfield>type</structfield></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_OUTPUT</constant>, +<constant>V4L2_BUF_TYPE_VIDEO_OVERLAY</constant>, and custom (driver +defined) types with code <constant>V4L2_BUF_TYPE_PRIVATE</constant> +and higher.</entry> + </row> + <row> + <entry>struct <link linkend="v4l2-rect-crop">v4l2_rect</link></entry> + <entry><structfield>bounds</structfield></entry> + <entry>Defines the window within capturing or output is +possible, this may exclude for example the horizontal and vertical +blanking areas. The cropping rectangle cannot exceed these limits. +Width and height are defined in pixels, the driver writer is free to +choose origin and units of the coordinate system in the analog +domain.</entry> + </row> + <row> + <entry>struct <link linkend="v4l2-rect-crop">v4l2_rect</link></entry> + <entry><structfield>defrect</structfield></entry> + <entry>Default cropping rectangle, it shall cover the +"whole picture". Assuming pixel aspect 1/1 this could be for example a +640 × 480 rectangle for NTSC, a +768 × 576 rectangle for PAL and SECAM centered over +the active picture area. The same co-ordinate system as for + <structfield>bounds</structfield> is used.</entry> + </row> + <row> + <entry>&v4l2-fract;</entry> + <entry><structfield>pixelaspect</structfield></entry> + <entry><para>This is the pixel aspect (y / x) when no +scaling is applied, the ratio of the actual sampling +frequency and the frequency required to get square +pixels.</para><para>When cropping coordinates refer to square pixels, +the driver sets <structfield>pixelaspect</structfield> to 1/1. Other +common values are 54/59 for PAL and SECAM, 11/10 for NTSC sampled +according to [<xref linkend="itu601" />].</para></entry> + </row> + </tbody> + </tgroup> + </table> + + <!-- NB this table is duplicated in the overlay chapter. --> + + <table pgwide="1" frame="none" id="v4l2-rect-crop"> + <title>struct <structname>v4l2_rect</structname></title> + <tgroup cols="3"> + &cs-str; + <tbody valign="top"> + <row> + <entry>__s32</entry> + <entry><structfield>left</structfield></entry> + <entry>Horizontal offset of the top, left corner of the +rectangle, in pixels.</entry> + </row> + <row> + <entry>__s32</entry> + <entry><structfield>top</structfield></entry> + <entry>Vertical offset of the top, left corner of the +rectangle, in pixels.</entry> + </row> + <row> + <entry>__s32</entry> + <entry><structfield>width</structfield></entry> + <entry>Width of the rectangle, in pixels.</entry> + </row> + <row> + <entry>__s32</entry> + <entry><structfield>height</structfield></entry> + <entry>Height of the rectangle, in pixels. Width +and height cannot be negative, the fields are signed for +hysterical reasons. <!-- video4linux-list@redhat.com +on 22 Oct 2002 subject "Re:[V4L][patches!] Re:v4l2/kernel-2.5" --> +</entry> + </row> + </tbody> + </tgroup> + </table> + </refsect1> + + <refsect1> + &return-value; + + <variablelist> + <varlistentry> + <term><errorcode>EINVAL</errorcode></term> + <listitem> + <para>The &v4l2-cropcap; <structfield>type</structfield> is +invalid or the ioctl is not supported. This is not permitted for +video capture, output and overlay devices, which must support +<constant>VIDIOC_CROPCAP</constant>.</para> + </listitem> + </varlistentry> + </variablelist> + </refsect1> +</refentry> + +<!-- +Local Variables: +mode: sgml +sgml-parent-document: "v4l2.sgml" +indent-tabs-mode: nil +End: +--> diff --git a/Documentation/DocBook/v4l/vidioc-dbg-g-chip-ident.xml b/Documentation/DocBook/v4l/vidioc-dbg-g-chip-ident.xml new file mode 100644 index 000000000000..4a09e203af0f --- /dev/null +++ b/Documentation/DocBook/v4l/vidioc-dbg-g-chip-ident.xml @@ -0,0 +1,275 @@ +<refentry id="vidioc-dbg-g-chip-ident"> + <refmeta> + <refentrytitle>ioctl VIDIOC_DBG_G_CHIP_IDENT</refentrytitle> + &manvol; + </refmeta> + + <refnamediv> + <refname>VIDIOC_DBG_G_CHIP_IDENT</refname> + <refpurpose>Identify the chips on a TV card</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_dbg_chip_ident +*<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_DBG_G_CHIP_IDENT</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>For driver debugging purposes this ioctl allows test +applications to query the driver about the chips present on the TV +card. Regular applications must not use it. When you found a chip +specific bug, please contact the linux-media mailing list (&v4l-ml;) +so it can be fixed.</para> + + <para>To query the driver applications must initialize the +<structfield>match.type</structfield> and +<structfield>match.addr</structfield> or <structfield>match.name</structfield> +fields of a &v4l2-dbg-chip-ident; +and call <constant>VIDIOC_DBG_G_CHIP_IDENT</constant> with a pointer to +this structure. On success the driver stores information about the +selected chip in the <structfield>ident</structfield> and +<structfield>revision</structfield> fields. On failure the structure +remains unchanged.</para> + + <para>When <structfield>match.type</structfield> is +<constant>V4L2_CHIP_MATCH_HOST</constant>, +<structfield>match.addr</structfield> selects the nth non-&i2c; chip +on the TV card. You can enumerate all chips by starting at zero and +incrementing <structfield>match.addr</structfield> by one until +<constant>VIDIOC_DBG_G_CHIP_IDENT</constant> fails with an &EINVAL;. +The number zero always selects the host chip, ⪚ the chip connected +to the PCI or USB bus.</para> + + <para>When <structfield>match.type</structfield> is +<constant>V4L2_CHIP_MATCH_I2C_DRIVER</constant>, +<structfield>match.name</structfield> contains the I2C driver name. +For instance +<constant>"saa7127"</constant> will match any chip +supported by the saa7127 driver, regardless of its &i2c; bus address. +When multiple chips supported by the same driver are present, the +ioctl will return <constant>V4L2_IDENT_AMBIGUOUS</constant> in the +<structfield>ident</structfield> field.</para> + + <para>When <structfield>match.type</structfield> is +<constant>V4L2_CHIP_MATCH_I2C_ADDR</constant>, +<structfield>match.addr</structfield> selects a chip by its 7 bit +&i2c; bus address.</para> + + <para>When <structfield>match.type</structfield> is +<constant>V4L2_CHIP_MATCH_AC97</constant>, +<structfield>match.addr</structfield> selects the nth AC97 chip +on the TV card. You can enumerate all chips by starting at zero and +incrementing <structfield>match.addr</structfield> by one until +<constant>VIDIOC_DBG_G_CHIP_IDENT</constant> fails with an &EINVAL;.</para> + + <para>On success, the <structfield>ident</structfield> field will +contain a chip ID from the Linux +<filename>media/v4l2-chip-ident.h</filename> header file, and the +<structfield>revision</structfield> field will contain a driver +specific value, or zero if no particular revision is associated with +this chip.</para> + + <para>When the driver could not identify the selected chip, +<structfield>ident</structfield> will contain +<constant>V4L2_IDENT_UNKNOWN</constant>. When no chip matched +the ioctl will succeed but the +<structfield>ident</structfield> field will contain +<constant>V4L2_IDENT_NONE</constant>. If multiple chips matched, +<structfield>ident</structfield> will contain +<constant>V4L2_IDENT_AMBIGUOUS</constant>. In all these cases the +<structfield>revision</structfield> field remains unchanged.</para> + + <para>This ioctl is optional, not all drivers may support it. It +was introduced in Linux 2.6.21, but the API was changed to the +one described here in 2.6.29.</para> + + <para>We recommended the <application>v4l2-dbg</application> +utility over calling this ioctl directly. It is available from the +LinuxTV v4l-dvb repository; see <ulink +url="http://linuxtv.org/repo/">http://linuxtv.org/repo/</ulink> for +access instructions.</para> + + <!-- Note for convenience vidioc-dbg-g-register.sgml + contains a duplicate of this table. --> + <table pgwide="1" frame="none" id="ident-v4l2-dbg-match"> + <title>struct <structname>v4l2_dbg_match</structname></title> + <tgroup cols="4"> + &cs-ustr; + <tbody valign="top"> + <row> + <entry>__u32</entry> + <entry><structfield>type</structfield></entry> + <entry>See <xref linkend="ident-chip-match-types" /> for a list of +possible types.</entry> + </row> + <row> + <entry>union</entry> + <entry>(anonymous)</entry> + </row> + <row> + <entry></entry> + <entry>__u32</entry> + <entry><structfield>addr</structfield></entry> + <entry>Match a chip by this number, interpreted according +to the <structfield>type</structfield> field.</entry> + </row> + <row> + <entry></entry> + <entry>char</entry> + <entry><structfield>name[32]</structfield></entry> + <entry>Match a chip by this name, interpreted according +to the <structfield>type</structfield> field.</entry> + </row> + </tbody> + </tgroup> + </table> + + <table pgwide="1" frame="none" id="v4l2-dbg-chip-ident"> + <title>struct <structname>v4l2_dbg_chip_ident</structname></title> + <tgroup cols="3"> + &cs-str; + <tbody valign="top"> + <row> + <entry>struct v4l2_dbg_match</entry> + <entry><structfield>match</structfield></entry> + <entry>How to match the chip, see <xref linkend="ident-v4l2-dbg-match" />.</entry> + </row> + <row> + <entry>__u32</entry> + <entry><structfield>ident</structfield></entry> + <entry>A chip identifier as defined in the Linux +<filename>media/v4l2-chip-ident.h</filename> header file, or one of +the values from <xref linkend="chip-ids" />.</entry> + </row> + <row> + <entry>__u32</entry> + <entry><structfield>revision</structfield></entry> + <entry>A chip revision, chip and driver specific.</entry> + </row> + </tbody> + </tgroup> + </table> + + <!-- Note for convenience vidioc-dbg-g-register.sgml + contains a duplicate of this table. --> + <table pgwide="1" frame="none" id="ident-chip-match-types"> + <title>Chip Match Types</title> + <tgroup cols="3"> + &cs-def; + <tbody valign="top"> + <row> + <entry><constant>V4L2_CHIP_MATCH_HOST</constant></entry> + <entry>0</entry> + <entry>Match the nth chip on the card, zero for the + host chip. Does not match &i2c; chips.</entry> + </row> + <row> + <entry><constant>V4L2_CHIP_MATCH_I2C_DRIVER</constant></entry> + <entry>1</entry> + <entry>Match an &i2c; chip by its driver name.</entry> + </row> + <row> + <entry><constant>V4L2_CHIP_MATCH_I2C_ADDR</constant></entry> + <entry>2</entry> + <entry>Match a chip by its 7 bit &i2c; bus address.</entry> + </row> + <row> + <entry><constant>V4L2_CHIP_MATCH_AC97</constant></entry> + <entry>3</entry> + <entry>Match the nth anciliary AC97 chip.</entry> + </row> + </tbody> + </tgroup> + </table> + + <!-- This is an anonymous enum in media/v4l2-chip-ident.h. --> + <table pgwide="1" frame="none" id="chip-ids"> + <title>Chip Identifiers</title> + <tgroup cols="3"> + &cs-def; + <tbody valign="top"> + <row> + <entry><constant>V4L2_IDENT_NONE</constant></entry> + <entry>0</entry> + <entry>No chip matched.</entry> + </row> + <row> + <entry><constant>V4L2_IDENT_AMBIGUOUS</constant></entry> + <entry>1</entry> + <entry>Multiple chips matched.</entry> + </row> + <row> + <entry><constant>V4L2_IDENT_UNKNOWN</constant></entry> + <entry>2</entry> + <entry>A chip is present at this address, but the driver +could not identify it.</entry> + </row> + </tbody> + </tgroup> + </table> + </refsect1> + + <refsect1> + &return-value; + + <variablelist> + <varlistentry> + <term><errorcode>EINVAL</errorcode></term> + <listitem> + <para>The driver does not support this ioctl, or the +<structfield>match_type</structfield> is invalid.</para> + </listitem> + </varlistentry> + </variablelist> + </refsect1> +</refentry> + +<!-- +Local Variables: +mode: sgml +sgml-parent-document: "v4l2.sgml" +indent-tabs-mode: nil +End: +--> diff --git a/Documentation/DocBook/v4l/vidioc-dbg-g-register.xml b/Documentation/DocBook/v4l/vidioc-dbg-g-register.xml new file mode 100644 index 000000000000..980c7f3e2fd6 --- /dev/null +++ b/Documentation/DocBook/v4l/vidioc-dbg-g-register.xml @@ -0,0 +1,275 @@ +<refentry id="vidioc-dbg-g-register"> + <refmeta> + <refentrytitle>ioctl VIDIOC_DBG_G_REGISTER, VIDIOC_DBG_S_REGISTER</refentrytitle> + &manvol; + </refmeta> + + <refnamediv> + <refname>VIDIOC_DBG_G_REGISTER</refname> + <refname>VIDIOC_DBG_S_REGISTER</refname> + <refpurpose>Read or write hardware registers</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_dbg_register *<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_dbg_register +*<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_DBG_G_REGISTER, VIDIOC_DBG_S_REGISTER</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>For driver debugging purposes these ioctls allow test +applications to access hardware registers directly. Regular +applications must not use them.</para> + + <para>Since writing or even reading registers can jeopardize the +system security, its stability and damage the hardware, both ioctls +require superuser privileges. Additionally the Linux kernel must be +compiled with the <constant>CONFIG_VIDEO_ADV_DEBUG</constant> option +to enable these ioctls.</para> + + <para>To write a register applications must initialize all fields +of a &v4l2-dbg-register; and call +<constant>VIDIOC_DBG_S_REGISTER</constant> with a pointer to this +structure. The <structfield>match.type</structfield> and +<structfield>match.addr</structfield> or <structfield>match.name</structfield> +fields select a chip on the TV +card, the <structfield>reg</structfield> field specifies a register +number and the <structfield>val</structfield> field the value to be +written into the register.</para> + + <para>To read a register applications must initialize the +<structfield>match.type</structfield>, +<structfield>match.chip</structfield> or <structfield>match.name</structfield> and +<structfield>reg</structfield> fields, and call +<constant>VIDIOC_DBG_G_REGISTER</constant> with a pointer to this +structure. On success the driver stores the register value in the +<structfield>val</structfield> field. On failure the structure remains +unchanged.</para> + + <para>When <structfield>match.type</structfield> is +<constant>V4L2_CHIP_MATCH_HOST</constant>, +<structfield>match.addr</structfield> selects the nth non-&i2c; chip +on the TV card. The number zero always selects the host chip, ⪚ the +chip connected to the PCI or USB bus. You can find out which chips are +present with the &VIDIOC-DBG-G-CHIP-IDENT; ioctl.</para> + + <para>When <structfield>match.type</structfield> is +<constant>V4L2_CHIP_MATCH_I2C_DRIVER</constant>, +<structfield>match.name</structfield> contains the I2C driver name. +For instance +<constant>"saa7127"</constant> will match any chip +supported by the saa7127 driver, regardless of its &i2c; bus address. +When multiple chips supported by the same driver are present, the +effect of these ioctls is undefined. Again with the +&VIDIOC-DBG-G-CHIP-IDENT; ioctl you can find out which &i2c; chips are +present.</para> + + <para>When <structfield>match.type</structfield> is +<constant>V4L2_CHIP_MATCH_I2C_ADDR</constant>, +<structfield>match.addr</structfield> selects a chip by its 7 bit &i2c; +bus address.</para> + + <para>When <structfield>match.type</structfield> is +<constant>V4L2_CHIP_MATCH_AC97</constant>, +<structfield>match.addr</structfield> selects the nth AC97 chip +on the TV card.</para> + + <note> + <title>Success not guaranteed</title> + + <para>Due to a flaw in the Linux &i2c; bus driver these ioctls may +return successfully without actually reading or writing a register. To +catch the most likely failure we recommend a &VIDIOC-DBG-G-CHIP-IDENT; +call confirming the presence of the selected &i2c; chip.</para> + </note> + + <para>These ioctls are optional, not all drivers may support them. +However when a driver supports these ioctls it must also support +&VIDIOC-DBG-G-CHIP-IDENT;. Conversely it may support +<constant>VIDIOC_DBG_G_CHIP_IDENT</constant> but not these ioctls.</para> + + <para><constant>VIDIOC_DBG_G_REGISTER</constant> and +<constant>VIDIOC_DBG_S_REGISTER</constant> were introduced in Linux +2.6.21, but their API was changed to the one described here in kernel 2.6.29.</para> + + <para>We recommended the <application>v4l2-dbg</application> +utility over calling these ioctls directly. It is available from the +LinuxTV v4l-dvb repository; see <ulink +url="http://linuxtv.org/repo/">http://linuxtv.org/repo/</ulink> for +access instructions.</para> + + <!-- Note for convenience vidioc-dbg-g-chip-ident.sgml + contains a duplicate of this table. --> + <table pgwide="1" frame="none" id="v4l2-dbg-match"> + <title>struct <structname>v4l2_dbg_match</structname></title> + <tgroup cols="4"> + &cs-ustr; + <tbody valign="top"> + <row> + <entry>__u32</entry> + <entry><structfield>type</structfield></entry> + <entry>See <xref linkend="ident-chip-match-types" /> for a list of +possible types.</entry> + </row> + <row> + <entry>union</entry> + <entry>(anonymous)</entry> + </row> + <row> + <entry></entry> + <entry>__u32</entry> + <entry><structfield>addr</structfield></entry> + <entry>Match a chip by this number, interpreted according +to the <structfield>type</structfield> field.</entry> + </row> + <row> + <entry></entry> + <entry>char</entry> + <entry><structfield>name[32]</structfield></entry> + <entry>Match a chip by this name, interpreted according +to the <structfield>type</structfield> field.</entry> + </row> + </tbody> + </tgroup> + </table> + + + <table pgwide="1" frame="none" id="v4l2-dbg-register"> + <title>struct <structname>v4l2_dbg_register</structname></title> + <tgroup cols="4"> + <colspec colname="c1" /> + <colspec colname="c2" /> + <colspec colname="c4" /> + <tbody valign="top"> + <row> + <entry>struct v4l2_dbg_match</entry> + <entry><structfield>match</structfield></entry> + <entry>How to match the chip, see <xref linkend="v4l2-dbg-match" />.</entry> + </row> + <row> + <entry>__u64</entry> + <entry><structfield>reg</structfield></entry> + <entry>A register number.</entry> + </row> + <row> + <entry>__u64</entry> + <entry><structfield>val</structfield></entry> + <entry>The value read from, or to be written into the +register.</entry> + </row> + </tbody> + </tgroup> + </table> + + <!-- Note for convenience vidioc-dbg-g-chip-ident.sgml + contains a duplicate of this table. --> + <table pgwide="1" frame="none" id="chip-match-types"> + <title>Chip Match Types</title> + <tgroup cols="3"> + &cs-def; + <tbody valign="top"> + <row> + <entry><constant>V4L2_CHIP_MATCH_HOST</constant></entry> + <entry>0</entry> + <entry>Match the nth chip on the card, zero for the + host chip. Does not match &i2c; chips.</entry> + </row> + <row> + <entry><constant>V4L2_CHIP_MATCH_I2C_DRIVER</constant></entry> + <entry>1</entry> + <entry>Match an &i2c; chip by its driver name.</entry> + </row> + <row> + <entry><constant>V4L2_CHIP_MATCH_I2C_ADDR</constant></entry> + <entry>2</entry> + <entry>Match a chip by its 7 bit &i2c; bus address.</entry> + </row> + <row> + <entry><constant>V4L2_CHIP_MATCH_AC97</constant></entry> + <entry>3</entry> + <entry>Match the nth anciliary AC97 chip.</entry> + </row> + </tbody> + </tgroup> + </table> + </refsect1> + + <refsect1> + &return-value; + + <variablelist> + <varlistentry> + <term><errorcode>EINVAL</errorcode></term> + <listitem> + <para>The driver does not support this ioctl, or the kernel +was not compiled with the <constant>CONFIG_VIDEO_ADV_DEBUG</constant> +option, or the <structfield>match_type</structfield> is invalid, or the +selected chip or register does not exist.</para> + </listitem> + </varlistentry> + <varlistentry> + <term><errorcode>EPERM</errorcode></term> + <listitem> + <para>Insufficient permissions. Root privileges are required +to execute these ioctls.</para> + </listitem> + </varlistentry> + </variablelist> + </refsect1> +</refentry> + +<!-- +Local Variables: +mode: sgml +sgml-parent-document: "v4l2.sgml" +indent-tabs-mode: nil +End: +--> diff --git a/Documentation/DocBook/v4l/vidioc-encoder-cmd.xml b/Documentation/DocBook/v4l/vidioc-encoder-cmd.xml new file mode 100644 index 000000000000..b0dde943825c --- /dev/null +++ b/Documentation/DocBook/v4l/vidioc-encoder-cmd.xml @@ -0,0 +1,204 @@ +<refentry id="vidioc-encoder-cmd"> + <refmeta> + <refentrytitle>ioctl VIDIOC_ENCODER_CMD, VIDIOC_TRY_ENCODER_CMD</refentrytitle> + &manvol; + </refmeta> + + <refnamediv> + <refname>VIDIOC_ENCODER_CMD</refname> + <refname>VIDIOC_TRY_ENCODER_CMD</refname> + <refpurpose>Execute an encoder command</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_encoder_cmd *<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_ENCODER_CMD, VIDIOC_TRY_ENCODER_CMD</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 control an audio/video (usually MPEG-) encoder. +<constant>VIDIOC_ENCODER_CMD</constant> sends a command to the +encoder, <constant>VIDIOC_TRY_ENCODER_CMD</constant> can be used to +try a command without actually executing it.</para> + + <para>To send a command applications must initialize all fields of a + &v4l2-encoder-cmd; and call + <constant>VIDIOC_ENCODER_CMD</constant> or + <constant>VIDIOC_TRY_ENCODER_CMD</constant> with a pointer to this + structure.</para> + + <para>The <structfield>cmd</structfield> field must contain the +command code. The <structfield>flags</structfield> field is currently +only used by the STOP command and contains one bit: If the +<constant>V4L2_ENC_CMD_STOP_AT_GOP_END</constant> flag is set, +encoding will continue until the end of the current <wordasword>Group +Of Pictures</wordasword>, otherwise it will stop immediately.</para> + + <para>A <function>read</function>() call sends a START command to +the encoder if it has not been started yet. After a STOP command, +<function>read</function>() calls will read the remaining data +buffered by the driver. When the buffer is empty, +<function>read</function>() will return zero and the next +<function>read</function>() call will restart the encoder.</para> + + <para>A <function>close</function>() call sends an immediate STOP +to the encoder, and all buffered data is discarded.</para> + + <para>These ioctls are optional, not all drivers may support +them. They were introduced in Linux 2.6.21.</para> + + <table pgwide="1" frame="none" id="v4l2-encoder-cmd"> + <title>struct <structname>v4l2_encoder_cmd</structname></title> + <tgroup cols="3"> + &cs-str; + <tbody valign="top"> + <row> + <entry>__u32</entry> + <entry><structfield>cmd</structfield></entry> + <entry>The encoder command, see <xref linkend="encoder-cmds" />.</entry> + </row> + <row> + <entry>__u32</entry> + <entry><structfield>flags</structfield></entry> + <entry>Flags to go with the command, see <xref + linkend="encoder-flags" />. If no flags are defined for +this command, drivers and applications must set this field to +zero.</entry> + </row> + <row> + <entry>__u32</entry> + <entry><structfield>data</structfield>[8]</entry> + <entry>Reserved for future extensions. Drivers and +applications must set the array to zero.</entry> + </row> + </tbody> + </tgroup> + </table> + + <table pgwide="1" frame="none" id="encoder-cmds"> + <title>Encoder Commands</title> + <tgroup cols="3"> + &cs-def; + <tbody valign="top"> + <row> + <entry><constant>V4L2_ENC_CMD_START</constant></entry> + <entry>0</entry> + <entry>Start the encoder. When the encoder is already +running or paused, this command does nothing. No flags are defined for +this command.</entry> + </row> + <row> + <entry><constant>V4L2_ENC_CMD_STOP</constant></entry> + <entry>1</entry> + <entry>Stop the encoder. When the +<constant>V4L2_ENC_CMD_STOP_AT_GOP_END</constant> flag is set, +encoding will continue until the end of the current <wordasword>Group +Of Pictures</wordasword>, otherwise encoding will stop immediately. +When the encoder is already stopped, this command does +nothing.</entry> + </row> + <row> + <entry><constant>V4L2_ENC_CMD_PAUSE</constant></entry> + <entry>2</entry> + <entry>Pause the encoder. When the encoder has not been +started yet, the driver will return an &EPERM;. When the encoder is +already paused, this command does nothing. No flags are defined for +this command.</entry> + </row> + <row> + <entry><constant>V4L2_ENC_CMD_RESUME</constant></entry> + <entry>3</entry> + <entry>Resume encoding after a PAUSE command. When the +encoder has not been started yet, the driver will return an &EPERM;. +When the encoder is already running, this command does nothing. No +flags are defined for this command.</entry> + </row> + </tbody> + </tgroup> + </table> + + <table pgwide="1" frame="none" id="encoder-flags"> + <title>Encoder Command Flags</title> + <tgroup cols="3"> + &cs-def; + <tbody valign="top"> + <row> + <entry><constant>V4L2_ENC_CMD_STOP_AT_GOP_END</constant></entry> + <entry>0x0001</entry> + <entry>Stop encoding at the end of the current <wordasword>Group Of +Pictures</wordasword>, rather than immediately.</entry> + </row> + </tbody> + </tgroup> + </table> + </refsect1> + + <refsect1> + &return-value; + + <variablelist> + <varlistentry> + <term><errorcode>EINVAL</errorcode></term> + <listitem> + <para>The driver does not support this ioctl, or the +<structfield>cmd</structfield> field is invalid.</para> + </listitem> + </varlistentry> + <varlistentry> + <term><errorcode>EPERM</errorcode></term> + <listitem> + <para>The application sent a PAUSE or RESUME command when +the encoder was not running.</para> + </listitem> + </varlistentry> + </variablelist> + </refsect1> +</refentry> + +<!-- +Local Variables: +mode: sgml +sgml-parent-document: "v4l2.sgml" +indent-tabs-mode: nil +End: +--> diff --git a/Documentation/DocBook/v4l/vidioc-enum-dv-presets.xml b/Documentation/DocBook/v4l/vidioc-enum-dv-presets.xml new file mode 100644 index 000000000000..1d31427edd1b --- /dev/null +++ b/Documentation/DocBook/v4l/vidioc-enum-dv-presets.xml @@ -0,0 +1,238 @@ +<refentry id="vidioc-enum-dv-presets"> + <refmeta> + <refentrytitle>ioctl VIDIOC_ENUM_DV_PRESETS</refentrytitle> + &manvol; + </refmeta> + + <refnamediv> + <refname>VIDIOC_ENUM_DV_PRESETS</refname> + <refpurpose>Enumerate supported Digital Video presets</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_dv_enum_preset *<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_ENUM_DV_PRESETS</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 a DV preset, applications initialize the +<structfield>index</structfield> field and zero the reserved array of &v4l2-dv-enum-preset; +and call the <constant>VIDIOC_ENUM_DV_PRESETS</constant> ioctl with a pointer to this +structure. Drivers fill the rest of the structure or return an +&EINVAL; when the index is out of bounds. To enumerate all DV Presets supported, +applications shall begin at index zero, incrementing by one until the +driver returns <errorcode>EINVAL</errorcode>. Drivers may enumerate a +different set of DV presets after switching the video input or +output.</para> + + <table pgwide="1" frame="none" id="v4l2-dv-enum-preset"> + <title>struct <structname>v4l2_dv_enum_presets</structname></title> + <tgroup cols="3"> + &cs-str; + <tbody valign="top"> + <row> + <entry>__u32</entry> + <entry><structfield>index</structfield></entry> + <entry>Number of the DV preset, set by the +application.</entry> + </row> + <row> + <entry>__u32</entry> + <entry><structfield>preset</structfield></entry> + <entry>This field identifies one of the DV preset values listed in <xref linkend="v4l2-dv-presets-vals"/>.</entry> + </row> + <row> + <entry>__u8</entry> + <entry><structfield>name</structfield>[24]</entry> + <entry>Name of the preset, a NUL-terminated ASCII string, for example: "720P-60", "1080I-60". This information is +intended for the user.</entry> + </row> + <row> + <entry>__u32</entry> + <entry><structfield>width</structfield></entry> + <entry>Width of the active video in pixels for the DV preset.</entry> + </row> + <row> + <entry>__u32</entry> + <entry><structfield>height</structfield></entry> + <entry>Height of the active video in lines for the DV preset.</entry> + </row> + <row> + <entry>__u32</entry> + <entry><structfield>reserved</structfield>[4]</entry> + <entry>Reserved for future extensions. Drivers must set the array to zero.</entry> + </row> + </tbody> + </tgroup> + </table> + + <table pgwide="1" frame="none" id="v4l2-dv-presets-vals"> + <title>struct <structname>DV Presets</structname></title> + <tgroup cols="3"> + &cs-str; + <tbody valign="top"> + <row> + <entry>Preset</entry> + <entry>Preset value</entry> + <entry>Description</entry> + </row> + <row> + <entry></entry> + <entry></entry> + <entry></entry> + </row> + <row> + <entry>V4L2_DV_INVALID</entry> + <entry>0</entry> + <entry>Invalid preset value.</entry> + </row> + <row> + <entry>V4L2_DV_480P59_94</entry> + <entry>1</entry> + <entry>720x480 progressive video at 59.94 fps as per BT.1362.</entry> + </row> + <row> + <entry>V4L2_DV_576P50</entry> + <entry>2</entry> + <entry>720x576 progressive video at 50 fps as per BT.1362.</entry> + </row> + <row> + <entry>V4L2_DV_720P24</entry> + <entry>3</entry> + <entry>1280x720 progressive video at 24 fps as per SMPTE 296M.</entry> + </row> + <row> + <entry>V4L2_DV_720P25</entry> + <entry>4</entry> + <entry>1280x720 progressive video at 25 fps as per SMPTE 296M.</entry> + </row> + <row> + <entry>V4L2_DV_720P30</entry> + <entry>5</entry> + <entry>1280x720 progressive video at 30 fps as per SMPTE 296M.</entry> + </row> + <row> + <entry>V4L2_DV_720P50</entry> + <entry>6</entry> + <entry>1280x720 progressive video at 50 fps as per SMPTE 296M.</entry> + </row> + <row> + <entry>V4L2_DV_720P59_94</entry> + <entry>7</entry> + <entry>1280x720 progressive video at 59.94 fps as per SMPTE 274M.</entry> + </row> + <row> + <entry>V4L2_DV_720P60</entry> + <entry>8</entry> + <entry>1280x720 progressive video at 60 fps as per SMPTE 274M/296M.</entry> + </row> + <row> + <entry>V4L2_DV_1080I29_97</entry> + <entry>9</entry> + <entry>1920x1080 interlaced video at 29.97 fps as per BT.1120/SMPTE 274M.</entry> + </row> + <row> + <entry>V4L2_DV_1080I30</entry> + <entry>10</entry> + <entry>1920x1080 interlaced video at 30 fps as per BT.1120/SMPTE 274M.</entry> + </row> + <row> + <entry>V4L2_DV_1080I25</entry> + <entry>11</entry> + <entry>1920x1080 interlaced video at 25 fps as per BT.1120.</entry> + </row> + <row> + <entry>V4L2_DV_1080I50</entry> + <entry>12</entry> + <entry>1920x1080 interlaced video at 50 fps as per SMPTE 296M.</entry> + </row> + <row> + <entry>V4L2_DV_1080I60</entry> + <entry>13</entry> + <entry>1920x1080 interlaced video at 60 fps as per SMPTE 296M.</entry> + </row> + <row> + <entry>V4L2_DV_1080P24</entry> + <entry>14</entry> + <entry>1920x1080 progressive video at 24 fps as per SMPTE 296M.</entry> + </row> + <row> + <entry>V4L2_DV_1080P25</entry> + <entry>15</entry> + <entry>1920x1080 progressive video at 25 fps as per SMPTE 296M.</entry> + </row> + <row> + <entry>V4L2_DV_1080P30</entry> + <entry>16</entry> + <entry>1920x1080 progressive video at 30 fps as per SMPTE 296M.</entry> + </row> + <row> + <entry>V4L2_DV_1080P50</entry> + <entry>17</entry> + <entry>1920x1080 progressive video at 50 fps as per BT.1120.</entry> + </row> + <row> + <entry>V4L2_DV_1080P60</entry> + <entry>18</entry> + <entry>1920x1080 progressive video at 60 fps as per BT.1120.</entry> + </row> + </tbody> + </tgroup> + </table> + </refsect1> + + <refsect1> + &return-value; + + <variablelist> + <varlistentry> + <term><errorcode>EINVAL</errorcode></term> + <listitem> + <para>The &v4l2-dv-enum-preset; <structfield>index</structfield> +is out of bounds.</para> + </listitem> + </varlistentry> + </variablelist> + </refsect1> +</refentry> + +<!-- +Local Variables: +mode: sgml +sgml-parent-document: "v4l2.sgml" +indent-tabs-mode: nil +End: +--> diff --git a/Documentation/DocBook/v4l/vidioc-enum-fmt.xml b/Documentation/DocBook/v4l/vidioc-enum-fmt.xml new file mode 100644 index 000000000000..960d44615ca6 --- /dev/null +++ b/Documentation/DocBook/v4l/vidioc-enum-fmt.xml @@ -0,0 +1,164 @@ +<refentry id="vidioc-enum-fmt"> + <refmeta> + <refentrytitle>ioctl VIDIOC_ENUM_FMT</refentrytitle> + &manvol; + </refmeta> + + <refnamediv> + <refname>VIDIOC_ENUM_FMT</refname> + <refpurpose>Enumerate image 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_fmtdesc +*<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_ENUM_FMT</para> + </listitem> + </varlistentry> + <varlistentry> + <term><parameter>argp</parameter></term> + <listitem> + <para></para> + </listitem> + </varlistentry> + </variablelist> + </refsect1> + + <refsect1> + <title>Description</title> + + <para>To enumerate image formats applications initialize the +<structfield>type</structfield> and <structfield>index</structfield> +field of &v4l2-fmtdesc; and call the +<constant>VIDIOC_ENUM_FMT</constant> ioctl with a pointer to this +structure. Drivers fill the rest of the structure or return an +&EINVAL;. All formats are enumerable by beginning at index zero and +incrementing by one until <errorcode>EINVAL</errorcode> is +returned.</para> + + <table pgwide="1" frame="none" id="v4l2-fmtdesc"> + <title>struct <structname>v4l2_fmtdesc</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. This is in no way related to the <structfield> +pixelformat</structfield> field.</entry> + </row> + <row> + <entry>&v4l2-buf-type;</entry> + <entry><structfield>type</structfield></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_OUTPUT</constant>, +<constant>V4L2_BUF_TYPE_VIDEO_OVERLAY</constant>, and custom (driver +defined) types with code <constant>V4L2_BUF_TYPE_PRIVATE</constant> +and higher.</entry> + </row> + <row> + <entry>__u32</entry> + <entry><structfield>flags</structfield></entry> + <entry>See <xref linkend="fmtdesc-flags" /></entry> + </row> + <row> + <entry>__u8</entry> + <entry><structfield>description</structfield>[32]</entry> + <entry>Description of the format, a NUL-terminated ASCII +string. This information is intended for the user, for example: "YUV +4:2:2".</entry> + </row> + <row> + <entry>__u32</entry> + <entry><structfield>pixelformat</structfield></entry> + <entry>The image format identifier. This is a +four character code as computed by the v4l2_fourcc() +macro:</entry> + </row> + <row> + <entry spanname="hspan"><para><programlisting id="v4l2-fourcc"> +#define v4l2_fourcc(a,b,c,d) (((__u32)(a)<<0)|((__u32)(b)<<8)|((__u32)(c)<<16)|((__u32)(d)<<24)) +</programlisting></para><para>Several image formats are already +defined by this specification in <xref linkend="pixfmt" />. Note these +codes are not the same as those used in the Windows world.</para></entry> + </row> + <row> + <entry>__u32</entry> + <entry><structfield>reserved</structfield>[4]</entry> + <entry>Reserved for future extensions. Drivers must set +the array to zero.</entry> + </row> + </tbody> + </tgroup> + </table> + + <table pgwide="1" frame="none" id="fmtdesc-flags"> + <title>Image Format Description Flags</title> + <tgroup cols="3"> + &cs-def; + <tbody valign="top"> + <row> + <entry><constant>V4L2_FMT_FLAG_COMPRESSED</constant></entry> + <entry>0x0001</entry> + <entry>This is a compressed format.</entry> + </row> + <row> + <entry><constant>V4L2_FMT_FLAG_EMULATED</constant></entry> + <entry>0x0002</entry> + <entry>This format is not native to the device but emulated +through software (usually libv4l2), where possible try to use a native format +instead for better performance.</entry> + </row> + </tbody> + </tgroup> + </table> + </refsect1> + + <refsect1> + &return-value; + + <variablelist> + <varlistentry> + <term><errorcode>EINVAL</errorcode></term> + <listitem> + <para>The &v4l2-fmtdesc; <structfield>type</structfield> +is not supported or the <structfield>index</structfield> is out of +bounds.</para> + </listitem> + </varlistentry> + </variablelist> + </refsect1> +</refentry> + +<!-- +Local Variables: +mode: sgml +sgml-parent-document: "v4l2.sgml" +indent-tabs-mode: nil +End: +--> diff --git a/Documentation/DocBook/v4l/vidioc-enum-frameintervals.xml b/Documentation/DocBook/v4l/vidioc-enum-frameintervals.xml new file mode 100644 index 000000000000..3c216e113a54 --- /dev/null +++ b/Documentation/DocBook/v4l/vidioc-enum-frameintervals.xml @@ -0,0 +1,270 @@ +<refentry id="vidioc-enum-frameintervals"> + + <refmeta> + <refentrytitle>ioctl VIDIOC_ENUM_FRAMEINTERVALS</refentrytitle> + &manvol; + </refmeta> + + <refnamediv> + <refname>VIDIOC_ENUM_FRAMEINTERVALS</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_frmivalenum *<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_ENUM_FRAMEINTERVALS</para> + </listitem> + </varlistentry> + <varlistentry> + <term><parameter>argp</parameter></term> + <listitem> + <para>Pointer to a &v4l2-frmivalenum; structure that +contains a pixel format and size and receives a frame interval.</para> + </listitem> + </varlistentry> + </variablelist> + </refsect1> + + <refsect1> + <title>Description</title> + + <para>This ioctl allows applications to enumerate all frame +intervals that the device supports for the given pixel format and +frame size.</para> + <para>The supported pixel formats and frame sizes can be obtained +by using the &VIDIOC-ENUM-FMT; and &VIDIOC-ENUM-FRAMESIZES; +functions.</para> + <para>The return value and the content of the +<structfield>v4l2_frmivalenum.type</structfield> field depend on the +type of frame intervals the device supports. Here are the semantics of +the function for the different cases:</para> + <itemizedlist> + <listitem> + <para><emphasis role="bold">Discrete:</emphasis> The function +returns success if the given index value (zero-based) is valid. The +application should increase the index by one for each call until +<constant>EINVAL</constant> is returned. The `v4l2_frmivalenum.type` +field is set to `V4L2_FRMIVAL_TYPE_DISCRETE` by the driver. Of the +union only the `discrete` member is valid.</para> + </listitem> + <listitem> + <para><emphasis role="bold">Step-wise:</emphasis> The function +returns success if the given index value is zero and +<constant>EINVAL</constant> for any other index value. The +<structfield>v4l2_frmivalenum.type</structfield> field is set to +<constant>V4L2_FRMIVAL_TYPE_STEPWISE</constant> by the driver. Of the +union only the <structfield>stepwise</structfield> member is +valid.</para> + </listitem> + <listitem> + <para><emphasis role="bold">Continuous:</emphasis> This is a +special case of the step-wise type above. The function returns success +if the given index value is zero and <constant>EINVAL</constant> for +any other index value. The +<structfield>v4l2_frmivalenum.type</structfield> field is set to +<constant>V4L2_FRMIVAL_TYPE_CONTINUOUS</constant> by the driver. Of +the union only the <structfield>stepwise</structfield> member is valid +and the <structfield>step</structfield> value is set to 1.</para> + </listitem> + </itemizedlist> + + <para>When the application calls the function with index zero, it +must check the <structfield>type</structfield> field to determine the +type of frame interval enumeration the device supports. Only for the +<constant>V4L2_FRMIVAL_TYPE_DISCRETE</constant> type does it make +sense to increase the index value to receive more frame +intervals.</para> + <para>Note that the order in which the frame intervals are +returned has no special meaning. In particular does it not say +anything about potential default frame intervals.</para> + <para>Applications can assume that the enumeration data does not +change without any interaction from the application itself. This means +that the enumeration data is consistent if the application does not +perform any other ioctl calls while it runs the frame interval +enumeration.</para> + </refsect1> + + <refsect1> + <title>Notes</title> + + <itemizedlist> + <listitem> + <para><emphasis role="bold">Frame intervals and frame +rates:</emphasis> The V4L2 API uses frame intervals instead of frame +rates. Given the frame interval the frame rate can be computed as +follows:<screen>frame_rate = 1 / frame_interval</screen></para> + </listitem> + </itemizedlist> + + </refsect1> + + <refsect1> + <title>Structs</title> + + <para>In the structs below, <emphasis>IN</emphasis> denotes a +value that has to be filled in by the application, +<emphasis>OUT</emphasis> denotes values that the driver fills in. The +application should zero out all members except for the +<emphasis>IN</emphasis> fields.</para> + + <table pgwide="1" frame="none" id="v4l2-frmival-stepwise"> + <title>struct <structname>v4l2_frmival_stepwise</structname></title> + <tgroup cols="3"> + &cs-str; + <tbody valign="top"> + <row> + <entry>&v4l2-fract;</entry> + <entry><structfield>min</structfield></entry> + <entry>Minimum frame interval [s].</entry> + </row> + <row> + <entry>&v4l2-fract;</entry> + <entry><structfield>max</structfield></entry> + <entry>Maximum frame interval [s].</entry> + </row> + <row> + <entry>&v4l2-fract;</entry> + <entry><structfield>step</structfield></entry> + <entry>Frame interval step size [s].</entry> + </row> + </tbody> + </tgroup> + </table> + + <table pgwide="1" frame="none" id="v4l2-frmivalenum"> + <title>struct <structname>v4l2_frmivalenum</structname></title> + <tgroup cols="4"> + <colspec colname="c1" /> + <colspec colname="c2" /> + <colspec colname="c3" /> + <colspec colname="c4" /> + <tbody valign="top"> + <row> + <entry>__u32</entry> + <entry><structfield>index</structfield></entry> + <entry></entry> + <entry>IN: Index of the given frame interval in the +enumeration.</entry> + </row> + <row> + <entry>__u32</entry> + <entry><structfield>pixel_format</structfield></entry> + <entry></entry> + <entry>IN: Pixel format for which the frame intervals are +enumerated.</entry> + </row> + <row> + <entry>__u32</entry> + <entry><structfield>width</structfield></entry> + <entry></entry> + <entry>IN: Frame width for which the frame intervals are +enumerated.</entry> + </row> + <row> + <entry>__u32</entry> + <entry><structfield>height</structfield></entry> + <entry></entry> + <entry>IN: Frame height for which the frame intervals are +enumerated.</entry> + </row> + <row> + <entry>__u32</entry> + <entry><structfield>type</structfield></entry> + <entry></entry> + <entry>OUT: Frame interval type the device supports.</entry> + </row> + <row> + <entry>union</entry> + <entry></entry> + <entry></entry> + <entry>OUT: Frame interval with the given index.</entry> + </row> + <row> + <entry></entry> + <entry>&v4l2-fract;</entry> + <entry><structfield>discrete</structfield></entry> + <entry>Frame interval [s].</entry> + </row> + <row> + <entry></entry> + <entry>&v4l2-frmival-stepwise;</entry> + <entry><structfield>stepwise</structfield></entry> + <entry></entry> + </row> + <row> + <entry>__u32</entry> + <entry><structfield>reserved[2]</structfield></entry> + <entry></entry> + <entry>Reserved space for future use.</entry> + </row> + </tbody> + </tgroup> + </table> + </refsect1> + + <refsect1> + <title>Enums</title> + + <table pgwide="1" frame="none" id="v4l2-frmivaltypes"> + <title>enum <structname>v4l2_frmivaltypes</structname></title> + <tgroup cols="3"> + &cs-def; + <tbody valign="top"> + <row> + <entry><constant>V4L2_FRMIVAL_TYPE_DISCRETE</constant></entry> + <entry>1</entry> + <entry>Discrete frame interval.</entry> + </row> + <row> + <entry><constant>V4L2_FRMIVAL_TYPE_CONTINUOUS</constant></entry> + <entry>2</entry> + <entry>Continuous frame interval.</entry> + </row> + <row> + <entry><constant>V4L2_FRMIVAL_TYPE_STEPWISE</constant></entry> + <entry>3</entry> + <entry>Step-wise defined frame interval.</entry> + </row> + </tbody> + </tgroup> + </table> + </refsect1> + + <refsect1> + &return-value; + + <para>See the description section above for a list of return +values that <varname>errno</varname> can have.</para> + </refsect1> + +</refentry> + +<!-- +Local Variables: +mode: sgml +sgml-parent-document: "v4l2.sgml" +indent-tabs-mode: nil +End: +--> diff --git a/Documentation/DocBook/v4l/vidioc-enum-framesizes.xml b/Documentation/DocBook/v4l/vidioc-enum-framesizes.xml new file mode 100644 index 000000000000..6afa4542c818 --- /dev/null +++ b/Documentation/DocBook/v4l/vidioc-enum-framesizes.xml @@ -0,0 +1,282 @@ +<refentry id="vidioc-enum-framesizes"> + + <refmeta> + <refentrytitle>ioctl VIDIOC_ENUM_FRAMESIZES</refentrytitle> + &manvol; + </refmeta> + + <refnamediv> + <refname>VIDIOC_ENUM_FRAMESIZES</refname> + <refpurpose>Enumerate 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_frmsizeenum *<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_ENUM_FRAMESIZES</para> + </listitem> + </varlistentry> + <varlistentry> + <term><parameter>argp</parameter></term> + <listitem> + <para>Pointer to a &v4l2-frmsizeenum; that contains an index +and pixel format and receives a frame width and height.</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 +(&ie; width and height in pixels) that the device supports for the +given pixel format.</para> + <para>The supported pixel formats can be obtained by using the +&VIDIOC-ENUM-FMT; function.</para> + <para>The return value and the content of the +<structfield>v4l2_frmsizeenum.type</structfield> field depend on the +type of frame sizes the device supports. Here are the semantics of the +function for the different cases:</para> + + <itemizedlist> + <listitem> + <para><emphasis role="bold">Discrete:</emphasis> The function +returns success if the given index value (zero-based) is valid. The +application should increase the index by one for each call until +<constant>EINVAL</constant> is returned. The +<structfield>v4l2_frmsizeenum.type</structfield> field is set to +<constant>V4L2_FRMSIZE_TYPE_DISCRETE</constant> by the driver. Of the +union only the <structfield>discrete</structfield> member is +valid.</para> + </listitem> + <listitem> + <para><emphasis role="bold">Step-wise:</emphasis> The function +returns success if the given index value is zero and +<constant>EINVAL</constant> for any other index value. The +<structfield>v4l2_frmsizeenum.type</structfield> field is set to +<constant>V4L2_FRMSIZE_TYPE_STEPWISE</constant> by the driver. Of the +union only the <structfield>stepwise</structfield> member is +valid.</para> + </listitem> + <listitem> + <para><emphasis role="bold">Continuous:</emphasis> This is a +special case of the step-wise type above. The function returns success +if the given index value is zero and <constant>EINVAL</constant> for +any other index value. The +<structfield>v4l2_frmsizeenum.type</structfield> field is set to +<constant>V4L2_FRMSIZE_TYPE_CONTINUOUS</constant> by the driver. Of +the union only the <structfield>stepwise</structfield> member is valid +and the <structfield>step_width</structfield> and +<structfield>step_height</structfield> values are set to 1.</para> + </listitem> + </itemizedlist> + + <para>When the application calls the function with index zero, it +must check the <structfield>type</structfield> field to determine the +type of frame size enumeration the device supports. Only for the +<constant>V4L2_FRMSIZE_TYPE_DISCRETE</constant> type does it make +sense to increase the index value to receive more frame sizes.</para> + <para>Note that the order in which the frame sizes are returned +has no special meaning. In particular does it not say anything about +potential default format sizes.</para> + <para>Applications can assume that the enumeration data does not +change without any interaction from the application itself. This means +that the enumeration data is consistent if the application does not +perform any other ioctl calls while it runs the frame size +enumeration.</para> + </refsect1> + + <refsect1> + <title>Structs</title> + + <para>In the structs below, <emphasis>IN</emphasis> denotes a +value that has to be filled in by the application, +<emphasis>OUT</emphasis> denotes values that the driver fills in. The +application should zero out all members except for the +<emphasis>IN</emphasis> fields.</para> + + <table pgwide="1" frame="none" id="v4l2-frmsize-discrete"> + <title>struct <structname>v4l2_frmsize_discrete</structname></title> + <tgroup cols="3"> + &cs-str; + <tbody valign="top"> + <row> + <entry>__u32</entry> + <entry><structfield>width</structfield></entry> + <entry>Width of the frame [pixel].</entry> + </row> + <row> + <entry>__u32</entry> + <entry><structfield>height</structfield></entry> + <entry>Height of the frame [pixel].</entry> + </row> + </tbody> + </tgroup> + </table> + + <table pgwide="1" frame="none" id="v4l2-frmsize-stepwise"> + <title>struct <structname>v4l2_frmsize_stepwise</structname></title> + <tgroup cols="3"> + &cs-str; + <tbody valign="top"> + <row> + <entry>__u32</entry> + <entry><structfield>min_width</structfield></entry> + <entry>Minimum frame width [pixel].</entry> + </row> + <row> + <entry>__u32</entry> + <entry><structfield>max_width</structfield></entry> + <entry>Maximum frame width [pixel].</entry> + </row> + <row> + <entry>__u32</entry> + <entry><structfield>step_width</structfield></entry> + <entry>Frame width step size [pixel].</entry> + </row> + <row> + <entry>__u32</entry> + <entry><structfield>min_height</structfield></entry> + <entry>Minimum frame height [pixel].</entry> + </row> + <row> + <entry>__u32</entry> + <entry><structfield>max_height</structfield></entry> + <entry>Maximum frame height [pixel].</entry> + </row> + <row> + <entry>__u32</entry> + <entry><structfield>step_height</structfield></entry> + <entry>Frame height step size [pixel].</entry> + </row> + </tbody> + </tgroup> + </table> + + <table pgwide="1" frame="none" id="v4l2-frmsizeenum"> + <title>struct <structname>v4l2_frmsizeenum</structname></title> + <tgroup cols="4"> + <colspec colname="c1" /> + <colspec colname="c2" /> + <colspec colname="c3" /> + <colspec colname="c4" /> + <tbody valign="top"> + <row> + <entry>__u32</entry> + <entry><structfield>index</structfield></entry> + <entry></entry> + <entry>IN: Index of the given frame size in the enumeration.</entry> + </row> + <row> + <entry>__u32</entry> + <entry><structfield>pixel_format</structfield></entry> + <entry></entry> + <entry>IN: Pixel format for which the frame sizes are enumerated.</entry> + </row> + <row> + <entry>__u32</entry> + <entry><structfield>type</structfield></entry> + <entry></entry> + <entry>OUT: Frame size type the device supports.</entry> + </row> + <row> + <entry>union</entry> + <entry></entry> + <entry></entry> + <entry>OUT: Frame size with the given index.</entry> + </row> + <row> + <entry></entry> + <entry>&v4l2-frmsize-discrete;</entry> + <entry><structfield>discrete</structfield></entry> + <entry></entry> + </row> + <row> + <entry></entry> + <entry>&v4l2-frmsize-stepwise;</entry> + <entry><structfield>stepwise</structfield></entry> + <entry></entry> + </row> + <row> + <entry>__u32</entry> + <entry><structfield>reserved[2]</structfield></entry> + <entry></entry> + <entry>Reserved space for future use.</entry> + </row> + </tbody> + </tgroup> + </table> + </refsect1> + + <refsect1> + <title>Enums</title> + + <table pgwide="1" frame="none" id="v4l2-frmsizetypes"> + <title>enum <structname>v4l2_frmsizetypes</structname></title> + <tgroup cols="3"> + &cs-def; + <tbody valign="top"> + <row> + <entry><constant>V4L2_FRMSIZE_TYPE_DISCRETE</constant></entry> + <entry>1</entry> + <entry>Discrete frame size.</entry> + </row> + <row> + <entry><constant>V4L2_FRMSIZE_TYPE_CONTINUOUS</constant></entry> + <entry>2</entry> + <entry>Continuous frame size.</entry> + </row> + <row> + <entry><constant>V4L2_FRMSIZE_TYPE_STEPWISE</constant></entry> + <entry>3</entry> + <entry>Step-wise defined frame size.</entry> + </row> + </tbody> + </tgroup> + </table> + </refsect1> + + <refsect1> + &return-value; + + <para>See the description section above for a list of return +values that <varname>errno</varname> can have.</para> + </refsect1> +</refentry> + +<!-- +Local Variables: +mode: sgml +sgml-parent-document: "v4l2.sgml" +indent-tabs-mode: nil +End: +--> diff --git a/Documentation/DocBook/v4l/vidioc-enumaudio.xml b/Documentation/DocBook/v4l/vidioc-enumaudio.xml new file mode 100644 index 000000000000..9ae8f2d3a96f --- /dev/null +++ b/Documentation/DocBook/v4l/vidioc-enumaudio.xml @@ -0,0 +1,86 @@ +<refentry id="vidioc-enumaudio"> + <refmeta> + <refentrytitle>ioctl VIDIOC_ENUMAUDIO</refentrytitle> + &manvol; + </refmeta> + + <refnamediv> + <refname>VIDIOC_ENUMAUDIO</refname> + <refpurpose>Enumerate audio inputs</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_audio *<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_ENUMAUDIO</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 audio input applications +initialize the <structfield>index</structfield> field and zero out the +<structfield>reserved</structfield> array of a &v4l2-audio; +and call the <constant>VIDIOC_ENUMAUDIO</constant> ioctl with a pointer +to this structure. Drivers fill the rest of the structure or return an +&EINVAL; when the index is out of bounds. To enumerate all audio +inputs applications shall begin at index zero, incrementing by one +until the driver returns <errorcode>EINVAL</errorcode>.</para> + + <para>See <xref linkend="vidioc-g-audio" /> for a description of +&v4l2-audio;.</para> + </refsect1> + + <refsect1> + &return-value; + + <variablelist> + <varlistentry> + <term><errorcode>EINVAL</errorcode></term> + <listitem> + <para>The number of the audio input is out of bounds, or +there are no audio inputs at all and this ioctl is not +supported.</para> + </listitem> + </varlistentry> + </variablelist> + </refsect1> +</refentry> + +<!-- +Local Variables: +mode: sgml +sgml-parent-document: "v4l2.sgml" +indent-tabs-mode: nil +End: +--> diff --git a/Documentation/DocBook/v4l/vidioc-enumaudioout.xml b/Documentation/DocBook/v4l/vidioc-enumaudioout.xml new file mode 100644 index 000000000000..d3d7c0ab17b8 --- /dev/null +++ b/Documentation/DocBook/v4l/vidioc-enumaudioout.xml @@ -0,0 +1,89 @@ +<refentry id="vidioc-enumaudioout"> + <refmeta> + <refentrytitle>ioctl VIDIOC_ENUMAUDOUT</refentrytitle> + &manvol; + </refmeta> + + <refnamediv> + <refname>VIDIOC_ENUMAUDOUT</refname> + <refpurpose>Enumerate audio outputs</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_audioout *<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_ENUMAUDOUT</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 audio output applications +initialize the <structfield>index</structfield> field and zero out the +<structfield>reserved</structfield> array of a &v4l2-audioout; and +call the <constant>VIDIOC_G_AUDOUT</constant> ioctl with a pointer +to this structure. Drivers fill the rest of the structure or return an +&EINVAL; when the index is out of bounds. To enumerate all audio +outputs applications shall begin at index zero, incrementing by one +until the driver returns <errorcode>EINVAL</errorcode>.</para> + + <para>Note connectors on a TV card to loop back the received audio +signal to a sound card are not audio outputs in this sense.</para> + + <para>See <xref linkend="vidioc-g-audioout" /> for a description of +&v4l2-audioout;.</para> + </refsect1> + + <refsect1> + &return-value; + + <variablelist> + <varlistentry> + <term><errorcode>EINVAL</errorcode></term> + <listitem> + <para>The number of the audio output is out of bounds, or +there are no audio outputs at all and this ioctl is not +supported.</para> + </listitem> + </varlistentry> + </variablelist> + </refsect1> +</refentry> + +<!-- +Local Variables: +mode: sgml +sgml-parent-document: "v4l2.sgml" +indent-tabs-mode: nil +End: +--> diff --git a/Documentation/DocBook/v4l/vidioc-enuminput.xml b/Documentation/DocBook/v4l/vidioc-enuminput.xml new file mode 100644 index 000000000000..71b868e2fb8f --- /dev/null +++ b/Documentation/DocBook/v4l/vidioc-enuminput.xml @@ -0,0 +1,321 @@ +<refentry id="vidioc-enuminput"> + <refmeta> + <refentrytitle>ioctl VIDIOC_ENUMINPUT</refentrytitle> + &manvol; + </refmeta> + + <refnamediv> + <refname>VIDIOC_ENUMINPUT</refname> + <refpurpose>Enumerate video inputs</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_input +*<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_ENUMINPUT</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 a video input applications +initialize the <structfield>index</structfield> field of &v4l2-input; +and call the <constant>VIDIOC_ENUMINPUT</constant> ioctl with a +pointer to this structure. Drivers fill the rest of the structure or +return an &EINVAL; when the index is out of bounds. To enumerate all +inputs applications shall begin at index zero, incrementing by one +until the driver returns <errorcode>EINVAL</errorcode>.</para> + + <table frame="none" pgwide="1" id="v4l2-input"> + <title>struct <structname>v4l2_input</structname></title> + <tgroup cols="3"> + &cs-str; + <tbody valign="top"> + <row> + <entry>__u32</entry> + <entry><structfield>index</structfield></entry> + <entry>Identifies the input, set by the +application.</entry> + </row> + <row> + <entry>__u8</entry> + <entry><structfield>name</structfield>[32]</entry> + <entry>Name of the video input, a NUL-terminated ASCII +string, for example: "Vin (Composite 2)". This information is intended +for the user, preferably the connector label on the device itself.</entry> + </row> + <row> + <entry>__u32</entry> + <entry><structfield>type</structfield></entry> + <entry>Type of the input, see <xref + linkend="input-type" />.</entry> + </row> + <row> + <entry>__u32</entry> + <entry><structfield>audioset</structfield></entry> + <entry><para>Drivers can enumerate up to 32 video and +audio inputs. This field shows which audio inputs were selectable as +audio source if this was the currently selected video input. It is a +bit mask. The LSB corresponds to audio input 0, the MSB to input 31. +Any number of bits can be set, or none.</para><para>When the driver +does not enumerate audio inputs no bits must be set. Applications +shall not interpret this as lack of audio support. Some drivers +automatically select audio sources and do not enumerate them since +there is no choice anyway.</para><para>For details on audio inputs and +how to select the current input see <xref + linkend="audio" />.</para></entry> + </row> + <row> + <entry>__u32</entry> + <entry><structfield>tuner</structfield></entry> + <entry>Capture devices can have zero or more tuners (RF +demodulators). When the <structfield>type</structfield> is set to +<constant>V4L2_INPUT_TYPE_TUNER</constant> this is an RF connector and +this field identifies the tuner. It corresponds to +&v4l2-tuner; field <structfield>index</structfield>. For details on +tuners see <xref linkend="tuner" />.</entry> + </row> + <row> + <entry>&v4l2-std-id;</entry> + <entry><structfield>std</structfield></entry> + <entry>Every video input supports one or more different +video standards. This field is a set of all supported standards. For +details on video standards and how to switch see <xref +linkend="standard" />.</entry> + </row> + <row> + <entry>__u32</entry> + <entry><structfield>status</structfield></entry> + <entry>This field provides status information about the +input. See <xref linkend="input-status" /> for flags. +With the exception of the sensor orientation bits <structfield>status</structfield> is only valid when this is the +current input.</entry> + </row> + <row> + <entry>__u32</entry> + <entry><structfield>capabilities</structfield></entry> + <entry>This field provides capabilities for the +input. See <xref linkend="input-capabilities" /> for flags.</entry> + </row> + <row> + <entry>__u32</entry> + <entry><structfield>reserved</structfield>[3]</entry> + <entry>Reserved for future extensions. Drivers must set +the array to zero.</entry> + </row> + </tbody> + </tgroup> + </table> + + <table frame="none" pgwide="1" id="input-type"> + <title>Input Types</title> + <tgroup cols="3"> + &cs-def; + <tbody valign="top"> + <row> + <entry><constant>V4L2_INPUT_TYPE_TUNER</constant></entry> + <entry>1</entry> + <entry>This input uses a tuner (RF demodulator).</entry> + </row> + <row> + <entry><constant>V4L2_INPUT_TYPE_CAMERA</constant></entry> + <entry>2</entry> + <entry>Analog baseband input, for example CVBS / +Composite Video, S-Video, RGB.</entry> + </row> + </tbody> + </tgroup> + </table> + + <!-- Status flags based on proposal by Mark McClelland, +video4linux-list@redhat.com on 18 Oct 2002, subject "Re: [V4L] Re: +v4l2 api". "Why are some of them inverted? So that the driver doesn't +have to lie about the status in cases where it can't tell one way or +the other. Plus, a status of zero would generally mean that everything +is OK." --> + + <table frame="none" pgwide="1" id="input-status"> + <title>Input Status Flags</title> + <tgroup cols="3"> + <colspec colname="c1" /> + <colspec colname="c2" align="center" /> + <colspec colname="c3" /> + <spanspec namest="c1" nameend="c3" spanname="hspan" + align="left" /> + <tbody valign="top"> + <row> + <entry spanname="hspan">General</entry> + </row> + <row> + <entry><constant>V4L2_IN_ST_NO_POWER</constant></entry> + <entry>0x00000001</entry> + <entry>Attached device is off.</entry> + </row> + <row> + <entry><constant>V4L2_IN_ST_NO_SIGNAL</constant></entry> + <entry>0x00000002</entry> + <entry></entry> + </row> + <row> + <entry><constant>V4L2_IN_ST_NO_COLOR</constant></entry> + <entry>0x00000004</entry> + <entry>The hardware supports color decoding, but does not +detect color modulation in the signal.</entry> + </row> + <row> + <entry spanname="hspan">Sensor Orientation</entry> + </row> + <row> + <entry><constant>V4L2_IN_ST_HFLIP</constant></entry> + <entry>0x00000010</entry> + <entry>The input is connected to a device that produces a signal +that is flipped horizontally and does not correct this before passing the +signal to userspace.</entry> + </row> + <row> + <entry><constant>V4L2_IN_ST_VFLIP</constant></entry> + <entry>0x00000020</entry> + <entry>The input is connected to a device that produces a signal +that is flipped vertically and does not correct this before passing the +signal to userspace. Note that a 180 degree rotation is the same as HFLIP | VFLIP</entry> + </row> + <row> + <entry spanname="hspan">Analog Video</entry> + </row> + <row> + <entry><constant>V4L2_IN_ST_NO_H_LOCK</constant></entry> + <entry>0x00000100</entry> + <entry>No horizontal sync lock.</entry> + </row> + <row> + <entry><constant>V4L2_IN_ST_COLOR_KILL</constant></entry> + <entry>0x00000200</entry> + <entry>A color killer circuit automatically disables color +decoding when it detects no color modulation. When this flag is set +the color killer is enabled <emphasis>and</emphasis> has shut off +color decoding.</entry> + </row> + <row> + <entry spanname="hspan">Digital Video</entry> + </row> + <row> + <entry><constant>V4L2_IN_ST_NO_SYNC</constant></entry> + <entry>0x00010000</entry> + <entry>No synchronization lock.</entry> + </row> + <row> + <entry><constant>V4L2_IN_ST_NO_EQU</constant></entry> + <entry>0x00020000</entry> + <entry>No equalizer lock.</entry> + </row> + <row> + <entry><constant>V4L2_IN_ST_NO_CARRIER</constant></entry> + <entry>0x00040000</entry> + <entry>Carrier recovery failed.</entry> + </row> + <row> + <entry spanname="hspan">VCR and Set-Top Box</entry> + </row> + <row> + <entry><constant>V4L2_IN_ST_MACROVISION</constant></entry> + <entry>0x01000000</entry> + <entry>Macrovision is an analog copy prevention system +mangling the video signal to confuse video recorders. When this +flag is set Macrovision has been detected.</entry> + </row> + <row> + <entry><constant>V4L2_IN_ST_NO_ACCESS</constant></entry> + <entry>0x02000000</entry> + <entry>Conditional access denied.</entry> + </row> + <row> + <entry><constant>V4L2_IN_ST_VTR</constant></entry> + <entry>0x04000000</entry> + <entry>VTR time constant. [?]</entry> + </row> + </tbody> + </tgroup> + </table> + + <!-- Capability flags based on video timings RFC by Muralidharan +Karicheri, titled RFC (v1.2): V4L - Support for video timings at the +input/output interface to linux-media@vger.kernel.org on 19 Oct 2009. + --> + <table frame="none" pgwide="1" id="input-capabilities"> + <title>Input capabilities</title> + <tgroup cols="3"> + &cs-def; + <tbody valign="top"> + <row> + <entry><constant>V4L2_IN_CAP_PRESETS</constant></entry> + <entry>0x00000001</entry> + <entry>This input supports setting DV presets by using VIDIOC_S_DV_PRESET.</entry> + </row> + <row> + <entry><constant>V4L2_OUT_CAP_CUSTOM_TIMINGS</constant></entry> + <entry>0x00000002</entry> + <entry>This input supports setting custom video timings by using VIDIOC_S_DV_TIMINGS.</entry> + </row> + <row> + <entry><constant>V4L2_IN_CAP_STD</constant></entry> + <entry>0x00000004</entry> + <entry>This input supports setting the TV standard by using VIDIOC_S_STD.</entry> + </row> + </tbody> + </tgroup> + </table> + </refsect1> + + <refsect1> + &return-value; + + <variablelist> + <varlistentry> + <term><errorcode>EINVAL</errorcode></term> + <listitem> + <para>The &v4l2-input; <structfield>index</structfield> is +out of bounds.</para> + </listitem> + </varlistentry> + </variablelist> + </refsect1> +</refentry> + +<!-- +Local Variables: +mode: sgml +sgml-parent-document: "v4l2.sgml" +indent-tabs-mode: nil +End: +--> diff --git a/Documentation/DocBook/v4l/vidioc-enumoutput.xml b/Documentation/DocBook/v4l/vidioc-enumoutput.xml new file mode 100644 index 000000000000..a281d26a195f --- /dev/null +++ b/Documentation/DocBook/v4l/vidioc-enumoutput.xml @@ -0,0 +1,206 @@ +<refentry id="vidioc-enumoutput"> + <refmeta> + <refentrytitle>ioctl VIDIOC_ENUMOUTPUT</refentrytitle> + &manvol; + </refmeta> + + <refnamediv> + <refname>VIDIOC_ENUMOUTPUT</refname> + <refpurpose>Enumerate video outputs</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_output *<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_ENUMOUTPUT</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 a video outputs applications +initialize the <structfield>index</structfield> field of &v4l2-output; +and call the <constant>VIDIOC_ENUMOUTPUT</constant> ioctl with a +pointer to this structure. Drivers fill the rest of the structure or +return an &EINVAL; when the index is out of bounds. To enumerate all +outputs applications shall begin at index zero, incrementing by one +until the driver returns <errorcode>EINVAL</errorcode>.</para> + + <table frame="none" pgwide="1" id="v4l2-output"> + <title>struct <structname>v4l2_output</structname></title> + <tgroup cols="3"> + &cs-str; + <tbody valign="top"> + <row> + <entry>__u32</entry> + <entry><structfield>index</structfield></entry> + <entry>Identifies the output, set by the +application.</entry> + </row> + <row> + <entry>__u8</entry> + <entry><structfield>name</structfield>[32]</entry> + <entry>Name of the video output, a NUL-terminated ASCII +string, for example: "Vout". This information is intended for the +user, preferably the connector label on the device itself.</entry> + </row> + <row> + <entry>__u32</entry> + <entry><structfield>type</structfield></entry> + <entry>Type of the output, see <xref + linkend="output-type" />.</entry> + </row> + <row> + <entry>__u32</entry> + <entry><structfield>audioset</structfield></entry> + <entry><para>Drivers can enumerate up to 32 video and +audio outputs. This field shows which audio outputs were +selectable as the current output if this was the currently selected +video output. It is a bit mask. The LSB corresponds to audio output 0, +the MSB to output 31. Any number of bits can be set, or +none.</para><para>When the driver does not enumerate audio outputs no +bits must be set. Applications shall not interpret this as lack of +audio support. Drivers may automatically select audio outputs without +enumerating them.</para><para>For details on audio outputs and how to +select the current output see <xref linkend="audio" />.</para></entry> + </row> + <row> + <entry>__u32</entry> + <entry><structfield>modulator</structfield></entry> + <entry>Output devices can have zero or more RF modulators. +When the <structfield>type</structfield> is +<constant>V4L2_OUTPUT_TYPE_MODULATOR</constant> this is an RF +connector and this field identifies the modulator. It corresponds to +&v4l2-modulator; field <structfield>index</structfield>. For details +on modulators see <xref linkend="tuner" />.</entry> + </row> + <row> + <entry>&v4l2-std-id;</entry> + <entry><structfield>std</structfield></entry> + <entry>Every video output supports one or more different +video standards. This field is a set of all supported standards. For +details on video standards and how to switch see <xref + linkend="standard" />.</entry> + </row> + <row> + <entry>__u32</entry> + <entry><structfield>capabilities</structfield></entry> + <entry>This field provides capabilities for the +output. See <xref linkend="output-capabilities" /> for flags.</entry> + </row> + <row> + <entry>__u32</entry> + <entry><structfield>reserved</structfield>[3]</entry> + <entry>Reserved for future extensions. Drivers must set +the array to zero.</entry> + </row> + </tbody> + </tgroup> + </table> + + <table frame="none" pgwide="1" id="output-type"> + <title>Output Type</title> + <tgroup cols="3"> + &cs-def; + <tbody valign="top"> + <row> + <entry><constant>V4L2_OUTPUT_TYPE_MODULATOR</constant></entry> + <entry>1</entry> + <entry>This output is an analog TV modulator.</entry> + </row> + <row> + <entry><constant>V4L2_OUTPUT_TYPE_ANALOG</constant></entry> + <entry>2</entry> + <entry>Analog baseband output, for example Composite / +CVBS, S-Video, RGB.</entry> + </row> + <row> + <entry><constant>V4L2_OUTPUT_TYPE_ANALOGVGAOVERLAY</constant></entry> + <entry>3</entry> + <entry>[?]</entry> + </row> + </tbody> + </tgroup> + </table> + + <!-- Capabilities flags based on video timings RFC by Muralidharan +Karicheri, titled RFC (v1.2): V4L - Support for video timings at the +input/output interface to linux-media@vger.kernel.org on 19 Oct 2009. + --> + <table frame="none" pgwide="1" id="output-capabilities"> + <title>Output capabilities</title> + <tgroup cols="3"> + &cs-def; + <tbody valign="top"> + <row> + <entry><constant>V4L2_OUT_CAP_PRESETS</constant></entry> + <entry>0x00000001</entry> + <entry>This output supports setting DV presets by using VIDIOC_S_DV_PRESET.</entry> + </row> + <row> + <entry><constant>V4L2_OUT_CAP_CUSTOM_TIMINGS</constant></entry> + <entry>0x00000002</entry> + <entry>This output supports setting custom video timings by using VIDIOC_S_DV_TIMINGS.</entry> + </row> + <row> + <entry><constant>V4L2_OUT_CAP_STD</constant></entry> + <entry>0x00000004</entry> + <entry>This output supports setting the TV standard by using VIDIOC_S_STD.</entry> + </row> + </tbody> + </tgroup> + </table> + + </refsect1> + <refsect1> + &return-value; + + <variablelist> + <varlistentry> + <term><errorcode>EINVAL</errorcode></term> + <listitem> + <para>The &v4l2-output; <structfield>index</structfield> +is out of bounds.</para> + </listitem> + </varlistentry> + </variablelist> + </refsect1> +</refentry> + +<!-- +Local Variables: +mode: sgml +sgml-parent-document: "v4l2.sgml" +indent-tabs-mode: nil +End: +--> diff --git a/Documentation/DocBook/v4l/vidioc-enumstd.xml b/Documentation/DocBook/v4l/vidioc-enumstd.xml new file mode 100644 index 000000000000..95803fe2c8e4 --- /dev/null +++ b/Documentation/DocBook/v4l/vidioc-enumstd.xml @@ -0,0 +1,391 @@ +<refentry id="vidioc-enumstd"> + <refmeta> + <refentrytitle>ioctl VIDIOC_ENUMSTD</refentrytitle> + &manvol; + </refmeta> + + <refnamediv> + <refname>VIDIOC_ENUMSTD</refname> + <refpurpose>Enumerate supported video standards</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_standard *<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_ENUMSTD</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 a video standard, +especially a custom (driver defined) one, applications initialize the +<structfield>index</structfield> field of &v4l2-standard; and call the +<constant>VIDIOC_ENUMSTD</constant> ioctl with a pointer to this +structure. Drivers fill the rest of the structure or return an +&EINVAL; when the index is out of bounds. To enumerate all standards +applications shall begin at index zero, incrementing by one until the +driver returns <errorcode>EINVAL</errorcode>. Drivers may enumerate a +different set of standards after switching the video input or +output.<footnote> + <para>The supported standards may overlap and we need an +unambiguous set to find the current standard returned by +<constant>VIDIOC_G_STD</constant>.</para> + </footnote></para> + + <table pgwide="1" frame="none" id="v4l2-standard"> + <title>struct <structname>v4l2_standard</structname></title> + <tgroup cols="3"> + &cs-str; + <tbody valign="top"> + <row> + <entry>__u32</entry> + <entry><structfield>index</structfield></entry> + <entry>Number of the video standard, set by the +application.</entry> + </row> + <row> + <entry>&v4l2-std-id;</entry> + <entry><structfield>id</structfield></entry> + <entry>The bits in this field identify the standard as +one of the common standards listed in <xref linkend="v4l2-std-id" />, +or if bits 32 to 63 are set as custom standards. Multiple bits can be +set if the hardware does not distinguish between these standards, +however separate indices do not indicate the opposite. The +<structfield>id</structfield> must be unique. No other enumerated +<structname>v4l2_standard</structname> structure, for this input or +output anyway, can contain the same set of bits.</entry> + </row> + <row> + <entry>__u8</entry> + <entry><structfield>name</structfield>[24]</entry> + <entry>Name of the standard, a NUL-terminated ASCII +string, for example: "PAL-B/G", "NTSC Japan". This information is +intended for the user.</entry> + </row> + <row> + <entry>&v4l2-fract;</entry> + <entry><structfield>frameperiod</structfield></entry> + <entry>The frame period (not field period) is numerator +/ denominator. For example M/NTSC has a frame period of 1001 / +30000 seconds.</entry> + </row> + <row> + <entry>__u32</entry> + <entry><structfield>framelines</structfield></entry> + <entry>Total lines per frame including blanking, +e. g. 625 for B/PAL.</entry> + </row> + <row> + <entry>__u32</entry> + <entry><structfield>reserved</structfield>[4]</entry> + <entry>Reserved for future extensions. Drivers must set +the array to zero.</entry> + </row> + </tbody> + </tgroup> + </table> + + <table pgwide="1" frame="none" id="v4l2-fract"> + <title>struct <structname>v4l2_fract</structname></title> + <tgroup cols="3"> + &cs-str; + <tbody valign="top"> + <row> + <entry>__u32</entry> + <entry><structfield>numerator</structfield></entry> + <entry></entry> + </row> + <row> + <entry>__u32</entry> + <entry><structfield>denominator</structfield></entry> + <entry></entry> + </row> + </tbody> + </tgroup> + </table> + + <table pgwide="1" frame="none" id="v4l2-std-id"> + <title>typedef <structname>v4l2_std_id</structname></title> + <tgroup cols="3"> + &cs-str; + <tbody valign="top"> + <row> + <entry>__u64</entry> + <entry><structfield>v4l2_std_id</structfield></entry> + <entry>This type is a set, each bit representing another +video standard as listed below and in <xref +linkend="video-standards" />. The 32 most significant bits are reserved +for custom (driver defined) video standards.</entry> + </row> + </tbody> + </tgroup> + </table> + + <para><programlisting> +#define V4L2_STD_PAL_B ((v4l2_std_id)0x00000001) +#define V4L2_STD_PAL_B1 ((v4l2_std_id)0x00000002) +#define V4L2_STD_PAL_G ((v4l2_std_id)0x00000004) +#define V4L2_STD_PAL_H ((v4l2_std_id)0x00000008) +#define V4L2_STD_PAL_I ((v4l2_std_id)0x00000010) +#define V4L2_STD_PAL_D ((v4l2_std_id)0x00000020) +#define V4L2_STD_PAL_D1 ((v4l2_std_id)0x00000040) +#define V4L2_STD_PAL_K ((v4l2_std_id)0x00000080) + +#define V4L2_STD_PAL_M ((v4l2_std_id)0x00000100) +#define V4L2_STD_PAL_N ((v4l2_std_id)0x00000200) +#define V4L2_STD_PAL_Nc ((v4l2_std_id)0x00000400) +#define V4L2_STD_PAL_60 ((v4l2_std_id)0x00000800) +</programlisting></para><para><constant>V4L2_STD_PAL_60</constant> is +a hybrid standard with 525 lines, 60 Hz refresh rate, and PAL color +modulation with a 4.43 MHz color subcarrier. Some PAL video recorders +can play back NTSC tapes in this mode for display on a 50/60 Hz agnostic +PAL TV.</para><para><programlisting> +#define V4L2_STD_NTSC_M ((v4l2_std_id)0x00001000) +#define V4L2_STD_NTSC_M_JP ((v4l2_std_id)0x00002000) +#define V4L2_STD_NTSC_443 ((v4l2_std_id)0x00004000) +</programlisting></para><para><constant>V4L2_STD_NTSC_443</constant> +is a hybrid standard with 525 lines, 60 Hz refresh rate, and NTSC +color modulation with a 4.43 MHz color +subcarrier.</para><para><programlisting> +#define V4L2_STD_NTSC_M_KR ((v4l2_std_id)0x00008000) + +#define V4L2_STD_SECAM_B ((v4l2_std_id)0x00010000) +#define V4L2_STD_SECAM_D ((v4l2_std_id)0x00020000) +#define V4L2_STD_SECAM_G ((v4l2_std_id)0x00040000) +#define V4L2_STD_SECAM_H ((v4l2_std_id)0x00080000) +#define V4L2_STD_SECAM_K ((v4l2_std_id)0x00100000) +#define V4L2_STD_SECAM_K1 ((v4l2_std_id)0x00200000) +#define V4L2_STD_SECAM_L ((v4l2_std_id)0x00400000) +#define V4L2_STD_SECAM_LC ((v4l2_std_id)0x00800000) + +/* ATSC/HDTV */ +#define V4L2_STD_ATSC_8_VSB ((v4l2_std_id)0x01000000) +#define V4L2_STD_ATSC_16_VSB ((v4l2_std_id)0x02000000) +</programlisting></para><para><!-- ATSC proposal by Mark McClelland, +video4linux-list@redhat.com on 17 Oct 2002 +--><constant>V4L2_STD_ATSC_8_VSB</constant> and +<constant>V4L2_STD_ATSC_16_VSB</constant> are U.S. terrestrial digital +TV standards. Presently the V4L2 API does not support digital TV. See +also the Linux DVB API at <ulink +url="http://linuxtv.org">http://linuxtv.org</ulink>.</para> +<para><programlisting> +#define V4L2_STD_PAL_BG (V4L2_STD_PAL_B |\ + V4L2_STD_PAL_B1 |\ + V4L2_STD_PAL_G) +#define V4L2_STD_B (V4L2_STD_PAL_B |\ + V4L2_STD_PAL_B1 |\ + V4L2_STD_SECAM_B) +#define V4L2_STD_GH (V4L2_STD_PAL_G |\ + V4L2_STD_PAL_H |\ + V4L2_STD_SECAM_G |\ + V4L2_STD_SECAM_H) +#define V4L2_STD_PAL_DK (V4L2_STD_PAL_D |\ + V4L2_STD_PAL_D1 |\ + V4L2_STD_PAL_K) +#define V4L2_STD_PAL (V4L2_STD_PAL_BG |\ + V4L2_STD_PAL_DK |\ + V4L2_STD_PAL_H |\ + V4L2_STD_PAL_I) +#define V4L2_STD_NTSC (V4L2_STD_NTSC_M |\ + V4L2_STD_NTSC_M_JP |\ + V4L2_STD_NTSC_M_KR) +#define V4L2_STD_MN (V4L2_STD_PAL_M |\ + V4L2_STD_PAL_N |\ + V4L2_STD_PAL_Nc |\ + V4L2_STD_NTSC) +#define V4L2_STD_SECAM_DK (V4L2_STD_SECAM_D |\ + V4L2_STD_SECAM_K |\ + V4L2_STD_SECAM_K1) +#define V4L2_STD_DK (V4L2_STD_PAL_DK |\ + V4L2_STD_SECAM_DK) + +#define V4L2_STD_SECAM (V4L2_STD_SECAM_B |\ + V4L2_STD_SECAM_G |\ + V4L2_STD_SECAM_H |\ + V4L2_STD_SECAM_DK |\ + V4L2_STD_SECAM_L |\ + V4L2_STD_SECAM_LC) + +#define V4L2_STD_525_60 (V4L2_STD_PAL_M |\ + V4L2_STD_PAL_60 |\ + V4L2_STD_NTSC |\ + V4L2_STD_NTSC_443) +#define V4L2_STD_625_50 (V4L2_STD_PAL |\ + V4L2_STD_PAL_N |\ + V4L2_STD_PAL_Nc |\ + V4L2_STD_SECAM) + +#define V4L2_STD_UNKNOWN 0 +#define V4L2_STD_ALL (V4L2_STD_525_60 |\ + V4L2_STD_625_50) +</programlisting></para> + + <table pgwide="1" id="video-standards" orient="land"> + <title>Video Standards (based on [<xref linkend="itu470" />])</title> + <tgroup cols="12" colsep="1" rowsep="1" align="center"> + <colspec colname="c1" align="left" /> + <colspec colname="c2" /> + <colspec colname="c3" /> + <colspec colname="c4" /> + <colspec colname="c5" /> + <colspec colnum="7" colname="c7" /> + <colspec colnum="9" colname="c9" /> + <colspec colnum="12" colname="c12" /> + <spanspec namest="c2" nameend="c3" spanname="m" align="center" /> + <spanspec namest="c4" nameend="c12" spanname="x" align="center" /> + <spanspec namest="c5" nameend="c7" spanname="b" align="center" /> + <spanspec namest="c9" nameend="c12" spanname="s" align="center" /> + <thead> + <row> + <entry>Characteristics</entry> + <entry><para>M/NTSC<footnote><para>Japan uses a standard +similar to M/NTSC +(V4L2_STD_NTSC_M_JP).</para></footnote></para></entry> + <entry>M/PAL</entry> + <entry><para>N/PAL<footnote><para> The values in +brackets apply to the combination N/PAL a.k.a. +N<subscript>C</subscript> used in Argentina +(V4L2_STD_PAL_Nc).</para></footnote></para></entry> + <entry align="center">B, B1, G/PAL</entry> + <entry align="center">D, D1, K/PAL</entry> + <entry align="center">H/PAL</entry> + <entry align="center">I/PAL</entry> + <entry align="center">B, G/SECAM</entry> + <entry align="center">D, K/SECAM</entry> + <entry align="center">K1/SECAM</entry> + <entry align="center">L/SECAM</entry> + </row> + </thead> + <tbody valign="top"> + <row> + <entry>Frame lines</entry> + <entry spanname="m">525</entry> + <entry spanname="x">625</entry> + </row> + <row> + <entry>Frame period (s)</entry> + <entry spanname="m">1001/30000</entry> + <entry spanname="x">1/25</entry> + </row> + <row> + <entry>Chrominance sub-carrier frequency (Hz)</entry> + <entry>3579545 ± 10</entry> + <entry>3579611.49 ± 10</entry> + <entry>4433618.75 ± 5 (3582056.25 +± 5)</entry> + <entry spanname="b">4433618.75 ± 5</entry> + <entry>4433618.75 ± 1</entry> + <entry spanname="s">f<subscript>OR</subscript> = +4406250 ± 2000, f<subscript>OB</subscript> = 4250000 +± 2000</entry> + </row> + <row> + <entry>Nominal radio-frequency channel bandwidth +(MHz)</entry> + <entry>6</entry> + <entry>6</entry> + <entry>6</entry> + <entry>B: 7; B1, G: 8</entry> + <entry>8</entry> + <entry>8</entry> + <entry>8</entry> + <entry>8</entry> + <entry>8</entry> + <entry>8</entry> + <entry>8</entry> + </row> + <row> + <entry>Sound carrier relative to vision carrier +(MHz)</entry> + <entry>+ 4.5</entry> + <entry>+ 4.5</entry> + <entry>+ 4.5</entry> + <entry><para>+ 5.5 ± 0.001 +<footnote><para>In the Federal Republic of Germany, Austria, Italy, +the Netherlands, Slovakia and Switzerland a system of two sound +carriers is used, the frequency of the second carrier being +242.1875 kHz above the frequency of the first sound carrier. For +stereophonic sound transmissions a similar system is used in +Australia.</para></footnote> <footnote><para>New Zealand uses a sound +carrier displaced 5.4996 ± 0.0005 MHz from the vision +carrier.</para></footnote> <footnote><para>In Denmark, Finland, New +Zealand, Sweden and Spain a system of two sound carriers is used. In +Iceland, Norway and Poland the same system is being introduced. The +second carrier is 5.85 MHz above the vision carrier and is DQPSK +modulated with 728 kbit/s sound and data multiplex. (NICAM +system)</para></footnote> <footnote><para>In the United Kingdom, a +system of two sound carriers is used. The second sound carrier is +6.552 MHz above the vision carrier and is DQPSK modulated with a +728 kbit/s sound and data multiplex able to carry two sound +channels. (NICAM system)</para></footnote></para></entry> + <entry>+ 6.5 ± 0.001</entry> + <entry>+ 5.5</entry> + <entry>+ 5.9996 ± 0.0005</entry> + <entry>+ 5.5 ± 0.001</entry> + <entry>+ 6.5 ± 0.001</entry> + <entry>+ 6.5</entry> + <entry><para>+ 6.5 <footnote><para>In France, a +digital carrier 5.85 MHz away from the vision carrier may be used in +addition to the main sound carrier. It is modulated in differentially +encoded QPSK with a 728 kbit/s sound and data multiplexer capable of +carrying two sound channels. (NICAM +system)</para></footnote></para></entry> + </row> + </tbody> + </tgroup> + </table> + </refsect1> + + <refsect1> + &return-value; + + <variablelist> + <varlistentry> + <term><errorcode>EINVAL</errorcode></term> + <listitem> + <para>The &v4l2-standard; <structfield>index</structfield> +is out of bounds.</para> + </listitem> + </varlistentry> + </variablelist> + </refsect1> +</refentry> + +<!-- +Local Variables: +mode: sgml +sgml-parent-document: "v4l2.sgml" +indent-tabs-mode: nil +End: +--> diff --git a/Documentation/DocBook/v4l/vidioc-g-audio.xml b/Documentation/DocBook/v4l/vidioc-g-audio.xml new file mode 100644 index 000000000000..65361a8c2b05 --- /dev/null +++ b/Documentation/DocBook/v4l/vidioc-g-audio.xml @@ -0,0 +1,188 @@ +<refentry id="vidioc-g-audio"> + <refmeta> + <refentrytitle>ioctl VIDIOC_G_AUDIO, VIDIOC_S_AUDIO</refentrytitle> + &manvol; + </refmeta> + + <refnamediv> + <refname>VIDIOC_G_AUDIO</refname> + <refname>VIDIOC_S_AUDIO</refname> + <refpurpose>Query or select the current audio input and its +attributes</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_audio *<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_audio *<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_G_AUDIO, VIDIOC_S_AUDIO</para> + </listitem> + </varlistentry> + <varlistentry> + <term><parameter>argp</parameter></term> + <listitem> + <para></para> + </listitem> + </varlistentry> + </variablelist> + </refsect1> + + <refsect1> + <title>Description</title> + + <para>To query the current audio input applications zero out the +<structfield>reserved</structfield> array of a &v4l2-audio; +and call the <constant>VIDIOC_G_AUDIO</constant> ioctl with a pointer +to this structure. Drivers fill the rest of the structure or return an +&EINVAL; when the device has no audio inputs, or none which combine +with the current video input.</para> + + <para>Audio inputs have one writable property, the audio mode. To +select the current audio input <emphasis>and</emphasis> change the +audio mode, applications initialize the +<structfield>index</structfield> and <structfield>mode</structfield> +fields, and the +<structfield>reserved</structfield> array of a +<structname>v4l2_audio</structname> structure and call the +<constant>VIDIOC_S_AUDIO</constant> ioctl. Drivers may switch to a +different audio mode if the request cannot be satisfied. However, this +is a write-only ioctl, it does not return the actual new audio +mode.</para> + + <table pgwide="1" frame="none" id="v4l2-audio"> + <title>struct <structname>v4l2_audio</structname></title> + <tgroup cols="3"> + &cs-str; + <tbody valign="top"> + <row> + <entry>__u32</entry> + <entry><structfield>index</structfield></entry> + <entry>Identifies the audio input, set by the +driver or application.</entry> + </row> + <row> + <entry>__u8</entry> + <entry><structfield>name</structfield>[32]</entry> + <entry>Name of the audio input, a NUL-terminated ASCII +string, for example: "Line In". This information is intended for the +user, preferably the connector label on the device itself.</entry> + </row> + <row> + <entry>__u32</entry> + <entry><structfield>capability</structfield></entry> + <entry>Audio capability flags, see <xref + linkend="audio-capability" />.</entry> + </row> + <row> + <entry>__u32</entry> + <entry><structfield>mode</structfield></entry> + <entry>Audio mode flags set by drivers and applications (on + <constant>VIDIOC_S_AUDIO</constant> ioctl), see <xref linkend="audio-mode" />.</entry> + </row> + <row> + <entry>__u32</entry> + <entry><structfield>reserved</structfield>[2]</entry> + <entry>Reserved for future extensions. Drivers and +applications must set the array to zero.</entry> + </row> + </tbody> + </tgroup> + </table> + + <table pgwide="1" frame="none" id="audio-capability"> + <title>Audio Capability Flags</title> + <tgroup cols="3"> + &cs-def; + <tbody valign="top"> + <row> + <entry><constant>V4L2_AUDCAP_STEREO</constant></entry> + <entry>0x00001</entry> + <entry>This is a stereo input. The flag is intended to +automatically disable stereo recording etc. when the signal is always +monaural. The API provides no means to detect if stereo is +<emphasis>received</emphasis>, unless the audio input belongs to a +tuner.</entry> + </row> + <row> + <entry><constant>V4L2_AUDCAP_AVL</constant></entry> + <entry>0x00002</entry> + <entry>Automatic Volume Level mode is supported.</entry> + </row> + </tbody> + </tgroup> + </table> + + <table pgwide="1" frame="none" id="audio-mode"> + <title>Audio Mode Flags</title> + <tgroup cols="3"> + &cs-def; + <tbody valign="top"> + <row> + <entry><constant>V4L2_AUDMODE_AVL</constant></entry> + <entry>0x00001</entry> + <entry>AVL mode is on.</entry> + </row> + </tbody> + </tgroup> + </table> + </refsect1> + + <refsect1> + &return-value; + + <variablelist> + <varlistentry> + <term><errorcode>EINVAL</errorcode></term> + <listitem> + <para>No audio inputs combine with the current video input, +or the number of the selected audio input is out of bounds or it does +not combine, or there are no audio inputs at all and the ioctl is not +supported.</para> + </listitem> + </varlistentry> + <varlistentry> + <term><errorcode>EBUSY</errorcode></term> + <listitem> + <para>I/O is in progress, the input cannot be +switched.</para> + </listitem> + </varlistentry> + </variablelist> + </refsect1> +</refentry> + +<!-- +Local Variables: +mode: sgml +sgml-parent-document: "v4l2.sgml" +indent-tabs-mode: nil +End: +--> diff --git a/Documentation/DocBook/v4l/vidioc-g-audioout.xml b/Documentation/DocBook/v4l/vidioc-g-audioout.xml new file mode 100644 index 000000000000..3632730c5c6e --- /dev/null +++ b/Documentation/DocBook/v4l/vidioc-g-audioout.xml @@ -0,0 +1,154 @@ +<refentry id="vidioc-g-audioout"> + <refmeta> + <refentrytitle>ioctl VIDIOC_G_AUDOUT, VIDIOC_S_AUDOUT</refentrytitle> + &manvol; + </refmeta> + + <refnamediv> + <refname>VIDIOC_G_AUDOUT</refname> + <refname>VIDIOC_S_AUDOUT</refname> + <refpurpose>Query or select the current audio output</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_audioout *<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_audioout *<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_G_AUDOUT, VIDIOC_S_AUDOUT</para> + </listitem> + </varlistentry> + <varlistentry> + <term><parameter>argp</parameter></term> + <listitem> + <para></para> + </listitem> + </varlistentry> + </variablelist> + </refsect1> + + <refsect1> + <title>Description</title> + + <para>To query the current audio output applications zero out the +<structfield>reserved</structfield> array of a &v4l2-audioout; and +call the <constant>VIDIOC_G_AUDOUT</constant> ioctl with a pointer +to this structure. Drivers fill the rest of the structure or return an +&EINVAL; when the device has no audio inputs, or none which combine +with the current video output.</para> + + <para>Audio outputs have no writable properties. Nevertheless, to +select the current audio output applications can initialize the +<structfield>index</structfield> field and +<structfield>reserved</structfield> array (which in the future may +contain writable properties) of a +<structname>v4l2_audioout</structname> structure and call the +<constant>VIDIOC_S_AUDOUT</constant> ioctl. Drivers switch to the +requested output or return the &EINVAL; when the index is out of +bounds. This is a write-only ioctl, it does not return the current +audio output attributes as <constant>VIDIOC_G_AUDOUT</constant> +does.</para> + + <para>Note connectors on a TV card to loop back the received audio +signal to a sound card are not audio outputs in this sense.</para> + + <table pgwide="1" frame="none" id="v4l2-audioout"> + <title>struct <structname>v4l2_audioout</structname></title> + <tgroup cols="3"> + &cs-str; + <tbody valign="top"> + <row> + <entry>__u32</entry> + <entry><structfield>index</structfield></entry> + <entry>Identifies the audio output, set by the +driver or application.</entry> + </row> + <row> + <entry>__u8</entry> + <entry><structfield>name</structfield>[32]</entry> + <entry>Name of the audio output, a NUL-terminated ASCII +string, for example: "Line Out". This information is intended for the +user, preferably the connector label on the device itself.</entry> + </row> + <row> + <entry>__u32</entry> + <entry><structfield>capability</structfield></entry> + <entry>Audio capability flags, none defined yet. Drivers +must set this field to zero.</entry> + </row> + <row> + <entry>__u32</entry> + <entry><structfield>mode</structfield></entry> + <entry>Audio mode, none defined yet. Drivers and +applications (on <constant>VIDIOC_S_AUDOUT</constant>) must set this +field to zero.</entry> + </row> + <row> + <entry>__u32</entry> + <entry><structfield>reserved</structfield>[2]</entry> + <entry>Reserved for future extensions. Drivers and +applications must set the array to zero.</entry> + </row> + </tbody> + </tgroup> + </table> + </refsect1> + + <refsect1> + &return-value; + + <variablelist> + <varlistentry> + <term><errorcode>EINVAL</errorcode></term> + <listitem> + <para>No audio outputs combine with the current video +output, or the number of the selected audio output is out of bounds or +it does not combine, or there are no audio outputs at all and the +ioctl is not supported.</para> + </listitem> + </varlistentry> + <varlistentry> + <term><errorcode>EBUSY</errorcode></term> + <listitem> + <para>I/O is in progress, the output cannot be +switched.</para> + </listitem> + </varlistentry> + </variablelist> + </refsect1> +</refentry> + +<!-- +Local Variables: +mode: sgml +sgml-parent-document: "v4l2.sgml" +indent-tabs-mode: nil +End: +--> diff --git a/Documentation/DocBook/v4l/vidioc-g-crop.xml b/Documentation/DocBook/v4l/vidioc-g-crop.xml new file mode 100644 index 000000000000..d235b1dedbed --- /dev/null +++ b/Documentation/DocBook/v4l/vidioc-g-crop.xml @@ -0,0 +1,143 @@ +<refentry id="vidioc-g-crop"> + <refmeta> + <refentrytitle>ioctl VIDIOC_G_CROP, VIDIOC_S_CROP</refentrytitle> + &manvol; + </refmeta> + + <refnamediv> + <refname>VIDIOC_G_CROP</refname> + <refname>VIDIOC_S_CROP</refname> + <refpurpose>Get or set the current cropping rectangle</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_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_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_G_CROP, VIDIOC_S_CROP</para> + </listitem> + </varlistentry> + <varlistentry> + <term><parameter>argp</parameter></term> + <listitem> + <para></para> + </listitem> + </varlistentry> + </variablelist> + </refsect1> + + <refsect1> + <title>Description</title> + + <para>To query the cropping rectangle size and position +applications set the <structfield>type</structfield> field of a +<structname>v4l2_crop</structname> structure to the respective buffer +(stream) type and call the <constant>VIDIOC_G_CROP</constant> ioctl +with a pointer to this structure. The driver fills the rest of the +structure or returns the &EINVAL; if cropping is not supported.</para> + + <para>To change the cropping rectangle applications initialize the +<structfield>type</structfield> and &v4l2-rect; substructure named +<structfield>c</structfield> of a v4l2_crop structure and call the +<constant>VIDIOC_S_CROP</constant> ioctl with a pointer to this +structure.</para> + + <para>The driver first adjusts the requested dimensions against +hardware limits, &ie; the bounds given by the capture/output window, +and it rounds to the closest possible values of horizontal and +vertical offset, width and height. In particular the driver must round +the vertical offset of the cropping rectangle to frame lines modulo +two, such that the field order cannot be confused.</para> + + <para>Second the driver adjusts the image size (the opposite +rectangle of the scaling process, source or target depending on the +data direction) to the closest size possible while maintaining the +current horizontal and vertical scaling factor.</para> + + <para>Finally the driver programs the hardware with the actual +cropping and image parameters. <constant>VIDIOC_S_CROP</constant> is a +write-only ioctl, it does not return the actual parameters. To query +them applications must call <constant>VIDIOC_G_CROP</constant> and +&VIDIOC-G-FMT;. When the parameters are unsuitable the application may +modify the cropping or image parameters and repeat the cycle until +satisfactory parameters have been negotiated.</para> + + <para>When cropping is not supported then no parameters are +changed and <constant>VIDIOC_S_CROP</constant> returns the +&EINVAL;.</para> + + <table pgwide="1" frame="none" id="v4l2-crop"> + <title>struct <structname>v4l2_crop</structname></title> + <tgroup cols="3"> + &cs-str; + <tbody valign="top"> + <row> + <entry>&v4l2-buf-type;</entry> + <entry><structfield>type</structfield></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_OUTPUT</constant>, +<constant>V4L2_BUF_TYPE_VIDEO_OVERLAY</constant>, and custom (driver +defined) types with code <constant>V4L2_BUF_TYPE_PRIVATE</constant> +and higher.</entry> + </row> + <row> + <entry>&v4l2-rect;</entry> + <entry><structfield>c</structfield></entry> + <entry>Cropping rectangle. The same co-ordinate system as +for &v4l2-cropcap; <structfield>bounds</structfield> is used.</entry> + </row> + </tbody> + </tgroup> + </table> + </refsect1> + + <refsect1> + &return-value; + + <variablelist> + <varlistentry> + <term><errorcode>EINVAL</errorcode></term> + <listitem> + <para>Cropping is not supported.</para> + </listitem> + </varlistentry> + </variablelist> + </refsect1> +</refentry> + +<!-- +Local Variables: +mode: sgml +sgml-parent-document: "v4l2.sgml" +indent-tabs-mode: nil +End: +--> diff --git a/Documentation/DocBook/v4l/vidioc-g-ctrl.xml b/Documentation/DocBook/v4l/vidioc-g-ctrl.xml new file mode 100644 index 000000000000..8b5e6ff7f3df --- /dev/null +++ b/Documentation/DocBook/v4l/vidioc-g-ctrl.xml @@ -0,0 +1,130 @@ +<refentry id="vidioc-g-ctrl"> + <refmeta> + <refentrytitle>ioctl VIDIOC_G_CTRL, VIDIOC_S_CTRL</refentrytitle> + &manvol; + </refmeta> + + <refnamediv> + <refname>VIDIOC_G_CTRL</refname> + <refname>VIDIOC_S_CTRL</refname> + <refpurpose>Get or set the value of a control</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_control +*<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_G_CTRL, VIDIOC_S_CTRL</para> + </listitem> + </varlistentry> + <varlistentry> + <term><parameter>argp</parameter></term> + <listitem> + <para></para> + </listitem> + </varlistentry> + </variablelist> + </refsect1> + + <refsect1> + <title>Description</title> + + <para>To get the current value of a control applications +initialize the <structfield>id</structfield> field of a struct +<structname>v4l2_control</structname> and call the +<constant>VIDIOC_G_CTRL</constant> ioctl with a pointer to this +structure. To change the value of a control applications initialize +the <structfield>id</structfield> and <structfield>value</structfield> +fields of a struct <structname>v4l2_control</structname> and call the +<constant>VIDIOC_S_CTRL</constant> ioctl.</para> + + <para>When the <structfield>id</structfield> is invalid drivers +return an &EINVAL;. When the <structfield>value</structfield> is out +of bounds drivers can choose to take the closest valid value or return +an &ERANGE;, whatever seems more appropriate. However, +<constant>VIDIOC_S_CTRL</constant> is a write-only ioctl, it does not +return the actual new value.</para> + + <para>These ioctls work only with user controls. For other +control classes the &VIDIOC-G-EXT-CTRLS;, &VIDIOC-S-EXT-CTRLS; or +&VIDIOC-TRY-EXT-CTRLS; must be used.</para> + + <table pgwide="1" frame="none" id="v4l2-control"> + <title>struct <structname>v4l2_control</structname></title> + <tgroup cols="3"> + &cs-str; + <tbody valign="top"> + <row> + <entry>__u32</entry> + <entry><structfield>id</structfield></entry> + <entry>Identifies the control, set by the +application.</entry> + </row> + <row> + <entry>__s32</entry> + <entry><structfield>value</structfield></entry> + <entry>New value or current value.</entry> + </row> + </tbody> + </tgroup> + </table> + </refsect1> + + <refsect1> + &return-value; + + <variablelist> + <varlistentry> + <term><errorcode>EINVAL</errorcode></term> + <listitem> + <para>The &v4l2-control; <structfield>id</structfield> is +invalid.</para> + </listitem> + </varlistentry> + <varlistentry> + <term><errorcode>ERANGE</errorcode></term> + <listitem> + <para>The &v4l2-control; <structfield>value</structfield> +is out of bounds.</para> + </listitem> + </varlistentry> + <varlistentry> + <term><errorcode>EBUSY</errorcode></term> + <listitem> + <para>The control is temporarily not changeable, possibly +because another applications took over control of the device function +this control belongs to.</para> + </listitem> + </varlistentry> + </variablelist> + </refsect1> +</refentry> + +<!-- +Local Variables: +mode: sgml +sgml-parent-document: "v4l2.sgml" +indent-tabs-mode: nil +End: +--> diff --git a/Documentation/DocBook/v4l/vidioc-g-dv-preset.xml b/Documentation/DocBook/v4l/vidioc-g-dv-preset.xml new file mode 100644 index 000000000000..3c6784e132f3 --- /dev/null +++ b/Documentation/DocBook/v4l/vidioc-g-dv-preset.xml @@ -0,0 +1,111 @@ +<refentry id="vidioc-g-dv-preset"> + <refmeta> + <refentrytitle>ioctl VIDIOC_G_DV_PRESET, VIDIOC_S_DV_PRESET</refentrytitle> + &manvol; + </refmeta> + + <refnamediv> + <refname>VIDIOC_G_DV_PRESET</refname> + <refname>VIDIOC_S_DV_PRESET</refname> + <refpurpose>Query or select the DV preset of the current input or output</refpurpose> + </refnamediv> + + <refsynopsisdiv> + <funcsynopsis> + <funcprototype> + <funcdef>int <function>ioctl</function></funcdef> + <paramdef>int <parameter>fd</parameter></paramdef> + <paramdef>int <parameter>request</parameter></paramdef> + <paramdef>&v4l2-dv-preset; +*<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_G_DV_PRESET, VIDIOC_S_DV_PRESET</para> + </listitem> + </varlistentry> + <varlistentry> + <term><parameter>argp</parameter></term> + <listitem> + <para></para> + </listitem> + </varlistentry> + </variablelist> + </refsect1> + + <refsect1> + <title>Description</title> + <para>To query and select the current DV preset, applications +use the <constant>VIDIOC_G_DV_PRESET</constant> and <constant>VIDIOC_S_DV_PRESET</constant> +ioctls which take a pointer to a &v4l2-dv-preset; type as argument. +Applications must zero the reserved array in &v4l2-dv-preset;. +<constant>VIDIOC_G_DV_PRESET</constant> returns a dv preset in the field +<structfield>preset</structfield> of &v4l2-dv-preset;.</para> + + <para><constant>VIDIOC_S_DV_PRESET</constant> accepts a pointer to a &v4l2-dv-preset; +that has the preset value to be set. Applications must zero the reserved array in &v4l2-dv-preset;. +If the preset is not supported, it returns an &EINVAL; </para> + </refsect1> + + <refsect1> + &return-value; + + <variablelist> + <varlistentry> + <term><errorcode>EINVAL</errorcode></term> + <listitem> + <para>This ioctl is not supported, or the +<constant>VIDIOC_S_DV_PRESET</constant>,<constant>VIDIOC_S_DV_PRESET</constant> parameter was unsuitable.</para> + </listitem> + </varlistentry> + <varlistentry> + <term><errorcode>EBUSY</errorcode></term> + <listitem> + <para>The device is busy and therefore can not change the preset.</para> + </listitem> + </varlistentry> + </variablelist> + + <table pgwide="1" frame="none" id="v4l2-dv-preset"> + <title>struct <structname>v4l2_dv_preset</structname></title> + <tgroup cols="3"> + &cs-str; + <tbody valign="top"> + <row> + <entry>__u32</entry> + <entry><structfield>preset</structfield></entry> + <entry>Preset value to represent the digital video timings</entry> + </row> + <row> + <entry>__u32</entry> + <entry><structfield>reserved[4]</structfield></entry> + <entry>Reserved fields for future use</entry> + </row> + </tbody> + </tgroup> + </table> + + </refsect1> +</refentry> + +<!-- +Local Variables: +mode: sgml +sgml-parent-document: "v4l2.sgml" +indent-tabs-mode: nil +End: +--> diff --git a/Documentation/DocBook/v4l/vidioc-g-dv-timings.xml b/Documentation/DocBook/v4l/vidioc-g-dv-timings.xml new file mode 100644 index 000000000000..ecc19576bb8f --- /dev/null +++ b/Documentation/DocBook/v4l/vidioc-g-dv-timings.xml @@ -0,0 +1,224 @@ +<refentry id="vidioc-g-dv-timings"> + <refmeta> + <refentrytitle>ioctl VIDIOC_G_DV_TIMINGS, VIDIOC_S_DV_TIMINGS</refentrytitle> + &manvol; + </refmeta> + + <refnamediv> + <refname>VIDIOC_G_DV_TIMINGS</refname> + <refname>VIDIOC_S_DV_TIMINGS</refname> + <refpurpose>Get or set custom DV timings for input or output</refpurpose> + </refnamediv> + + <refsynopsisdiv> + <funcsynopsis> + <funcprototype> + <funcdef>int <function>ioctl</function></funcdef> + <paramdef>int <parameter>fd</parameter></paramdef> + <paramdef>int <parameter>request</parameter></paramdef> + <paramdef>&v4l2-dv-timings; +*<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_G_DV_TIMINGS, VIDIOC_S_DV_TIMINGS</para> + </listitem> + </varlistentry> + <varlistentry> + <term><parameter>argp</parameter></term> + <listitem> + <para></para> + </listitem> + </varlistentry> + </variablelist> + </refsect1> + + <refsect1> + <title>Description</title> + <para>To set custom DV timings for the input or output, applications use the +<constant>VIDIOC_S_DV_TIMINGS</constant> ioctl and to get the current custom timings, +applications use the <constant>VIDIOC_G_DV_TIMINGS</constant> ioctl. The detailed timing +information is filled in using the structure &v4l2-dv-timings;. These ioctls take +a pointer to the &v4l2-dv-timings; structure as argument. If the ioctl is not supported +or the timing values are not correct, the driver returns &EINVAL;.</para> + </refsect1> + + <refsect1> + &return-value; + + <variablelist> + <varlistentry> + <term><errorcode>EINVAL</errorcode></term> + <listitem> + <para>This ioctl is not supported, or the +<constant>VIDIOC_S_DV_TIMINGS</constant> parameter was unsuitable.</para> + </listitem> + </varlistentry> + <varlistentry> + <term><errorcode>EBUSY</errorcode></term> + <listitem> + <para>The device is busy and therefore can not change the timings.</para> + </listitem> + </varlistentry> + </variablelist> + + <table pgwide="1" frame="none" id="v4l2-bt-timings"> + <title>struct <structname>v4l2_bt_timings</structname></title> + <tgroup cols="3"> + &cs-str; + <tbody valign="top"> + <row> + <entry>__u32</entry> + <entry><structfield>width</structfield></entry> + <entry>Width of the active video in pixels</entry> + </row> + <row> + <entry>__u32</entry> + <entry><structfield>height</structfield></entry> + <entry>Height of the active video in lines</entry> + </row> + <row> + <entry>__u32</entry> + <entry><structfield>interlaced</structfield></entry> + <entry>Progressive (0) or interlaced (1)</entry> + </row> + <row> + <entry>__u32</entry> + <entry><structfield>polarities</structfield></entry> + <entry>This is a bit mask that defines polarities of sync signals. +bit 0 (V4L2_DV_VSYNC_POS_POL) is for vertical sync polarity and bit 1 (V4L2_DV_HSYNC_POS_POL) is for horizontal sync polarity. If the bit is set +(1) it is positive polarity and if is cleared (0), it is negative polarity.</entry> + </row> + <row> + <entry>__u64</entry> + <entry><structfield>pixelclock</structfield></entry> + <entry>Pixel clock in Hz. Ex. 74.25MHz->74250000</entry> + </row> + <row> + <entry>__u32</entry> + <entry><structfield>hfrontporch</structfield></entry> + <entry>Horizontal front porch in pixels</entry> + </row> + <row> + <entry>__u32</entry> + <entry><structfield>hsync</structfield></entry> + <entry>Horizontal sync length in pixels</entry> + </row> + <row> + <entry>__u32</entry> + <entry><structfield>hbackporch</structfield></entry> + <entry>Horizontal back porch in pixels</entry> + </row> + <row> + <entry>__u32</entry> + <entry><structfield>vfrontporch</structfield></entry> + <entry>Vertical front porch in lines</entry> + </row> + <row> + <entry>__u32</entry> + <entry><structfield>vsync</structfield></entry> + <entry>Vertical sync length in lines</entry> + </row> + <row> + <entry>__u32</entry> + <entry><structfield>vbackporch</structfield></entry> + <entry>Vertical back porch in lines</entry> + </row> + <row> + <entry>__u32</entry> + <entry><structfield>il_vfrontporch</structfield></entry> + <entry>Vertical front porch in lines for bottom field of interlaced field formats</entry> + </row> + <row> + <entry>__u32</entry> + <entry><structfield>il_vsync</structfield></entry> + <entry>Vertical sync length in lines for bottom field of interlaced field formats</entry> + </row> + <row> + <entry>__u32</entry> + <entry><structfield>il_vbackporch</structfield></entry> + <entry>Vertical back porch in lines for bottom field of interlaced field formats</entry> + </row> + </tbody> + </tgroup> + </table> + + <table pgwide="1" frame="none" id="v4l2-dv-timings"> + <title>struct <structname>v4l2_dv_timings</structname></title> + <tgroup cols="4"> + &cs-str; + <tbody valign="top"> + <row> + <entry>__u32</entry> + <entry><structfield>type</structfield></entry> + <entry></entry> + <entry>Type of DV timings as listed in <xref linkend="dv-timing-types"/>.</entry> + </row> + <row> + <entry>union</entry> + <entry><structfield></structfield></entry> + <entry></entry> + </row> + <row> + <entry></entry> + <entry>&v4l2-bt-timings;</entry> + <entry><structfield>bt</structfield></entry> + <entry>Timings defined by BT.656/1120 specifications</entry> + </row> + <row> + <entry></entry> + <entry>__u32</entry> + <entry><structfield>reserved</structfield>[32]</entry> + <entry></entry> + </row> + </tbody> + </tgroup> + </table> + + <table pgwide="1" frame="none" id="dv-timing-types"> + <title>DV Timing types</title> + <tgroup cols="3"> + &cs-str; + <tbody valign="top"> + <row> + <entry>Timing type</entry> + <entry>value</entry> + <entry>Description</entry> + </row> + <row> + <entry></entry> + <entry></entry> + <entry></entry> + </row> + <row> + <entry>V4L2_DV_BT_656_1120</entry> + <entry>0</entry> + <entry>BT.656/1120 timings</entry> + </row> + </tbody> + </tgroup> + </table> + </refsect1> +</refentry> + +<!-- +Local Variables: +mode: sgml +sgml-parent-document: "v4l2.sgml" +indent-tabs-mode: nil +End: +--> diff --git a/Documentation/DocBook/v4l/vidioc-g-enc-index.xml b/Documentation/DocBook/v4l/vidioc-g-enc-index.xml new file mode 100644 index 000000000000..9f242e4b2948 --- /dev/null +++ b/Documentation/DocBook/v4l/vidioc-g-enc-index.xml @@ -0,0 +1,213 @@ +<refentry id="vidioc-g-enc-index"> + <refmeta> + <refentrytitle>ioctl VIDIOC_G_ENC_INDEX</refentrytitle> + &manvol; + </refmeta> + + <refnamediv> + <refname>VIDIOC_G_ENC_INDEX</refname> + <refpurpose>Get meta data about a compressed video stream</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_enc_idx *<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_G_ENC_INDEX</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>The <constant>VIDIOC_G_ENC_INDEX</constant> ioctl provides +meta data about a compressed video stream the same or another +application currently reads from the driver, which is useful for +random access into the stream without decoding it.</para> + + <para>To read the data applications must call +<constant>VIDIOC_G_ENC_INDEX</constant> with a pointer to a +&v4l2-enc-idx;. On success the driver fills the +<structfield>entry</structfield> array, stores the number of elements +written in the <structfield>entries</structfield> field, and +initializes the <structfield>entries_cap</structfield> field.</para> + + <para>Each element of the <structfield>entry</structfield> array +contains meta data about one picture. A +<constant>VIDIOC_G_ENC_INDEX</constant> call reads up to +<constant>V4L2_ENC_IDX_ENTRIES</constant> entries from a driver +buffer, which can hold up to <structfield>entries_cap</structfield> +entries. This number can be lower or higher than +<constant>V4L2_ENC_IDX_ENTRIES</constant>, but not zero. When the +application fails to read the meta data in time the oldest entries +will be lost. When the buffer is empty or no capturing/encoding is in +progress, <structfield>entries</structfield> will be zero.</para> + + <para>Currently this ioctl is only defined for MPEG-2 program +streams and video elementary streams.</para> + + <table pgwide="1" frame="none" id="v4l2-enc-idx"> + <title>struct <structname>v4l2_enc_idx</structname></title> + <tgroup cols="3"> + &cs-str; + <tbody valign="top"> + <row> + <entry>__u32</entry> + <entry><structfield>entries</structfield></entry> + <entry>The number of entries the driver stored in the +<structfield>entry</structfield> array.</entry> + </row> + <row> + <entry>__u32</entry> + <entry><structfield>entries_cap</structfield></entry> + <entry>The number of entries the driver can +buffer. Must be greater than zero.</entry> + </row> + <row> + <entry>__u32</entry> + <entry><structfield>reserved</structfield>[4]</entry> + <entry spanname="hspan">Reserved for future extensions. +Drivers must set the array to zero.</entry> + </row> + <row> + <entry>&v4l2-enc-idx-entry;</entry> + <entry><structfield>entry</structfield>[<constant>V4L2_ENC_IDX_ENTRIES</constant>]</entry> + <entry>Meta data about a compressed video stream. Each +element of the array corresponds to one picture, sorted in ascending +order by their <structfield>offset</structfield>.</entry> + </row> + </tbody> + </tgroup> + </table> + + <table pgwide="1" frame="none" id="v4l2-enc-idx-entry"> + <title>struct <structname>v4l2_enc_idx_entry</structname></title> + <tgroup cols="3"> + &cs-str; + <tbody valign="top"> + <row> + <entry>__u64</entry> + <entry><structfield>offset</structfield></entry> + <entry>The offset in bytes from the beginning of the +compressed video stream to the beginning of this picture, that is a +<wordasword>PES packet header</wordasword> as defined in <xref + linkend="mpeg2part1" /> or a <wordasword>picture +header</wordasword> as defined in <xref linkend="mpeg2part2" />. When +the encoder is stopped, the driver resets the offset to zero.</entry> + </row> + <row> + <entry>__u64</entry> + <entry><structfield>pts</structfield></entry> + <entry>The 33 bit <wordasword>Presentation Time +Stamp</wordasword> of this picture as defined in <xref + linkend="mpeg2part1" />.</entry> + </row> + <row> + <entry>__u32</entry> + <entry><structfield>length</structfield></entry> + <entry>The length of this picture in bytes.</entry> + </row> + <row> + <entry>__u32</entry> + <entry><structfield>flags</structfield></entry> + <entry>Flags containing the coding type of this picture, see <xref + linkend="enc-idx-flags" />.</entry> + </row> + <row> + <entry>__u32</entry> + <entry><structfield>reserved</structfield>[2]</entry> + <entry>Reserved for future extensions. +Drivers must set the array to zero.</entry> + </row> + </tbody> + </tgroup> + </table> + + <table pgwide="1" frame="none" id="enc-idx-flags"> + <title>Index Entry Flags</title> + <tgroup cols="3"> + &cs-def; + <tbody valign="top"> + <row> + <entry><constant>V4L2_ENC_IDX_FRAME_I</constant></entry> + <entry>0x00</entry> + <entry>This is an Intra-coded picture.</entry> + </row> + <row> + <entry><constant>V4L2_ENC_IDX_FRAME_P</constant></entry> + <entry>0x01</entry> + <entry>This is a Predictive-coded picture.</entry> + </row> + <row> + <entry><constant>V4L2_ENC_IDX_FRAME_B</constant></entry> + <entry>0x02</entry> + <entry>This is a Bidirectionally predictive-coded +picture.</entry> + </row> + <row> + <entry><constant>V4L2_ENC_IDX_FRAME_MASK</constant></entry> + <entry>0x0F</entry> + <entry><wordasword>AND</wordasword> the flags field with +this mask to obtain the picture coding type.</entry> + </row> + </tbody> + </tgroup> + </table> + </refsect1> + + <refsect1> + &return-value; + + <variablelist> + <varlistentry> + <term><errorcode>EINVAL</errorcode></term> + <listitem> + <para>The driver does not support this ioctl.</para> + </listitem> + </varlistentry> + </variablelist> + </refsect1> +</refentry> + +<!-- +Local Variables: +mode: sgml +sgml-parent-document: "v4l2.sgml" +indent-tabs-mode: nil +End: +--> diff --git a/Documentation/DocBook/v4l/vidioc-g-ext-ctrls.xml b/Documentation/DocBook/v4l/vidioc-g-ext-ctrls.xml new file mode 100644 index 000000000000..3aa7f8f9ff0c --- /dev/null +++ b/Documentation/DocBook/v4l/vidioc-g-ext-ctrls.xml @@ -0,0 +1,307 @@ +<refentry id="vidioc-g-ext-ctrls"> + <refmeta> + <refentrytitle>ioctl VIDIOC_G_EXT_CTRLS, VIDIOC_S_EXT_CTRLS, +VIDIOC_TRY_EXT_CTRLS</refentrytitle> + &manvol; + </refmeta> + + <refnamediv> + <refname>VIDIOC_G_EXT_CTRLS</refname> + <refname>VIDIOC_S_EXT_CTRLS</refname> + <refname>VIDIOC_TRY_EXT_CTRLS</refname> + <refpurpose>Get or set the value of several controls, try control +values</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_ext_controls +*<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_G_EXT_CTRLS, VIDIOC_S_EXT_CTRLS, +VIDIOC_TRY_EXT_CTRLS</para> + </listitem> + </varlistentry> + <varlistentry> + <term><parameter>argp</parameter></term> + <listitem> + <para></para> + </listitem> + </varlistentry> + </variablelist> + </refsect1> + + <refsect1> + <title>Description</title> + + <para>These ioctls allow the caller to get or set multiple +controls atomically. Control IDs are grouped into control classes (see +<xref linkend="ctrl-class" />) and all controls in the control array +must belong to the same control class.</para> + + <para>Applications must always fill in the +<structfield>count</structfield>, +<structfield>ctrl_class</structfield>, +<structfield>controls</structfield> and +<structfield>reserved</structfield> fields of &v4l2-ext-controls;, and +initialize the &v4l2-ext-control; array pointed to by the +<structfield>controls</structfield> fields.</para> + + <para>To get the current value of a set of controls applications +initialize the <structfield>id</structfield>, +<structfield>size</structfield> and <structfield>reserved2</structfield> fields +of each &v4l2-ext-control; and call the +<constant>VIDIOC_G_EXT_CTRLS</constant> ioctl. String controls controls +must also set the <structfield>string</structfield> field.</para> + + <para>If the <structfield>size</structfield> is too small to +receive the control result (only relevant for pointer-type controls +like strings), then the driver will set <structfield>size</structfield> +to a valid value and return an &ENOSPC;. You should re-allocate the +string memory to this new size and try again. It is possible that the +same issue occurs again if the string has grown in the meantime. It is +recommended to call &VIDIOC-QUERYCTRL; first and use +<structfield>maximum</structfield>+1 as the new <structfield>size</structfield> +value. It is guaranteed that that is sufficient memory. +</para> + + <para>To change the value of a set of controls applications +initialize the <structfield>id</structfield>, <structfield>size</structfield>, +<structfield>reserved2</structfield> and +<structfield>value/string</structfield> fields of each &v4l2-ext-control; and +call the <constant>VIDIOC_S_EXT_CTRLS</constant> ioctl. The controls +will only be set if <emphasis>all</emphasis> control values are +valid.</para> + + <para>To check if a set of controls have correct values applications +initialize the <structfield>id</structfield>, <structfield>size</structfield>, +<structfield>reserved2</structfield> and +<structfield>value/string</structfield> fields of each &v4l2-ext-control; and +call the <constant>VIDIOC_TRY_EXT_CTRLS</constant> ioctl. It is up to +the driver whether wrong values are automatically adjusted to a valid +value or if an error is returned.</para> + + <para>When the <structfield>id</structfield> or +<structfield>ctrl_class</structfield> is invalid drivers return an +&EINVAL;. When the value is out of bounds drivers can choose to take +the closest valid value or return an &ERANGE;, whatever seems more +appropriate. In the first case the new value is set in +&v4l2-ext-control;.</para> + + <para>The driver will only set/get these controls if all control +values are correct. This prevents the situation where only some of the +controls were set/get. Only low-level errors (⪚ a failed i2c +command) can still cause this situation.</para> + + <table pgwide="1" frame="none" id="v4l2-ext-control"> + <title>struct <structname>v4l2_ext_control</structname></title> + <tgroup cols="4"> + &cs-ustr; + <tbody valign="top"> + <row> + <entry>__u32</entry> + <entry><structfield>id</structfield></entry> + <entry></entry> + <entry>Identifies the control, set by the +application.</entry> + </row> + <row> + <entry>__u32</entry> + <entry><structfield>size</structfield></entry> + <entry></entry> + <entry>The total size in bytes of the payload of this +control. This is normally 0, but for pointer controls this should be +set to the size of the memory containing the payload, or that will +receive the payload. If <constant>VIDIOC_G_EXT_CTRLS</constant> finds +that this value is less than is required to store +the payload result, then it is set to a value large enough to store the +payload result and ENOSPC is returned. Note that for string controls +this <structfield>size</structfield> field should not be confused with the length of the string. +This field refers to the size of the memory that contains the string. +The actual <emphasis>length</emphasis> of the string may well be much smaller. +</entry> + </row> + <row> + <entry>__u32</entry> + <entry><structfield>reserved2</structfield>[1]</entry> + <entry></entry> + <entry>Reserved for future extensions. Drivers and +applications must set the array to zero.</entry> + </row> + <row> + <entry>union</entry> + <entry>(anonymous)</entry> + </row> + <row> + <entry></entry> + <entry>__s32</entry> + <entry><structfield>value</structfield></entry> + <entry>New value or current value.</entry> + </row> + <row> + <entry></entry> + <entry>__s64</entry> + <entry><structfield>value64</structfield></entry> + <entry>New value or current value.</entry> + </row> + <row> + <entry></entry> + <entry>char *</entry> + <entry><structfield>string</structfield></entry> + <entry>A pointer to a string.</entry> + </row> + </tbody> + </tgroup> + </table> + + <table pgwide="1" frame="none" id="v4l2-ext-controls"> + <title>struct <structname>v4l2_ext_controls</structname></title> + <tgroup cols="3"> + &cs-str; + <tbody valign="top"> + <row> + <entry>__u32</entry> + <entry><structfield>ctrl_class</structfield></entry> + <entry>The control class to which all controls belong, see +<xref linkend="ctrl-class" />.</entry> + </row> + <row> + <entry>__u32</entry> + <entry><structfield>count</structfield></entry> + <entry>The number of controls in the controls array. May +also be zero.</entry> + </row> + <row> + <entry>__u32</entry> + <entry><structfield>error_idx</structfield></entry> + <entry>Set by the driver in case of an error. It is the +index of the control causing the error or equal to 'count' when the +error is not associated with a particular control. Undefined when the +ioctl returns 0 (success).</entry> + </row> + <row> + <entry>__u32</entry> + <entry><structfield>reserved</structfield>[2]</entry> + <entry>Reserved for future extensions. Drivers and +applications must set the array to zero.</entry> + </row> + <row> + <entry>&v4l2-ext-control; *</entry> + <entry><structfield>controls</structfield></entry> + <entry>Pointer to an array of +<structfield>count</structfield> v4l2_ext_control structures. Ignored +if <structfield>count</structfield> equals zero.</entry> + </row> + </tbody> + </tgroup> + </table> + + <table pgwide="1" frame="none" id="ctrl-class"> + <title>Control classes</title> + <tgroup cols="3"> + &cs-def; + <tbody valign="top"> + <row> + <entry><constant>V4L2_CTRL_CLASS_USER</constant></entry> + <entry>0x980000</entry> + <entry>The class containing user controls. These controls +are described in <xref linkend="control" />. All controls that can be set +using the &VIDIOC-S-CTRL; and &VIDIOC-G-CTRL; ioctl belong to this +class.</entry> + </row> + <row> + <entry><constant>V4L2_CTRL_CLASS_MPEG</constant></entry> + <entry>0x990000</entry> + <entry>The class containing MPEG compression controls. +These controls are described in <xref + linkend="mpeg-controls" />.</entry> + </row> + <row> + <entry><constant>V4L2_CTRL_CLASS_CAMERA</constant></entry> + <entry>0x9a0000</entry> + <entry>The class containing camera controls. +These controls are described in <xref + linkend="camera-controls" />.</entry> + </row> + <row> + <entry><constant>V4L2_CTRL_CLASS_FM_TX</constant></entry> + <entry>0x9b0000</entry> + <entry>The class containing FM Transmitter (FM TX) controls. +These controls are described in <xref + linkend="fm-tx-controls" />.</entry> + </row> + </tbody> + </tgroup> + </table> + + </refsect1> + + <refsect1> + &return-value; + + <variablelist> + <varlistentry> + <term><errorcode>EINVAL</errorcode></term> + <listitem> + <para>The &v4l2-ext-control; <structfield>id</structfield> +is invalid or the &v4l2-ext-controls; +<structfield>ctrl_class</structfield> is invalid. This error code is +also returned by the <constant>VIDIOC_S_EXT_CTRLS</constant> and +<constant>VIDIOC_TRY_EXT_CTRLS</constant> ioctls if two or more +control values are in conflict.</para> + </listitem> + </varlistentry> + <varlistentry> + <term><errorcode>ERANGE</errorcode></term> + <listitem> + <para>The &v4l2-ext-control; <structfield>value</structfield> +is out of bounds.</para> + </listitem> + </varlistentry> + <varlistentry> + <term><errorcode>EBUSY</errorcode></term> + <listitem> + <para>The control is temporarily not changeable, possibly +because another applications took over control of the device function +this control belongs to.</para> + </listitem> + </varlistentry> + <varlistentry> + <term><errorcode>ENOSPC</errorcode></term> + <listitem> + <para>The space reserved for the control's payload is insufficient. +The field <structfield>size</structfield> is set to a value that is enough +to store the payload and this error code is returned.</para> + </listitem> + </varlistentry> + </variablelist> + </refsect1> +</refentry> + +<!-- +Local Variables: +mode: sgml +sgml-parent-document: "v4l2.sgml" +indent-tabs-mode: nil +End: +--> diff --git a/Documentation/DocBook/v4l/vidioc-g-fbuf.xml b/Documentation/DocBook/v4l/vidioc-g-fbuf.xml new file mode 100644 index 000000000000..e7dda4822f04 --- /dev/null +++ b/Documentation/DocBook/v4l/vidioc-g-fbuf.xml @@ -0,0 +1,473 @@ +<refentry id="vidioc-g-fbuf"> + <refmeta> + <refentrytitle>ioctl VIDIOC_G_FBUF, VIDIOC_S_FBUF</refentrytitle> + &manvol; + </refmeta> + + <refnamediv> + <refname>VIDIOC_G_FBUF</refname> + <refname>VIDIOC_S_FBUF</refname> + <refpurpose>Get or set frame buffer overlay parameters</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_framebuffer *<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_framebuffer *<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_G_FBUF, VIDIOC_S_FBUF</para> + </listitem> + </varlistentry> + <varlistentry> + <term><parameter>argp</parameter></term> + <listitem> + <para></para> + </listitem> + </varlistentry> + </variablelist> + </refsect1> + + <refsect1> + <title>Description</title> + + <para>Applications can use the <constant>VIDIOC_G_FBUF</constant> and +<constant>VIDIOC_S_FBUF</constant> ioctl to get and set the +framebuffer parameters for a <link linkend="overlay">Video +Overlay</link> or <link linkend="osd">Video Output Overlay</link> +(OSD). The type of overlay is implied by the device type (capture or +output device) and can be determined with the &VIDIOC-QUERYCAP; ioctl. +One <filename>/dev/videoN</filename> device must not support both +kinds of overlay.</para> + + <para>The V4L2 API distinguishes destructive and non-destructive +overlays. A destructive overlay copies captured video images into the +video memory of a graphics card. A non-destructive overlay blends +video images into a VGA signal or graphics into a video signal. +<wordasword>Video Output Overlays</wordasword> are always +non-destructive.</para> + + <para>To get the current parameters applications call the +<constant>VIDIOC_G_FBUF</constant> ioctl with a pointer to a +<structname>v4l2_framebuffer</structname> structure. The driver fills +all fields of the structure or returns an &EINVAL; when overlays are +not supported.</para> + + <para>To set the parameters for a <wordasword>Video Output +Overlay</wordasword>, applications must initialize the +<structfield>flags</structfield> field of a struct +<structname>v4l2_framebuffer</structname>. Since the framebuffer is +implemented on the TV card all other parameters are determined by the +driver. When an application calls <constant>VIDIOC_S_FBUF</constant> +with a pointer to this structure, the driver prepares for the overlay +and returns the framebuffer parameters as +<constant>VIDIOC_G_FBUF</constant> does, or it returns an error +code.</para> + + <para>To set the parameters for a <wordasword>non-destructive +Video Overlay</wordasword>, applications must initialize the +<structfield>flags</structfield> field, the +<structfield>fmt</structfield> substructure, and call +<constant>VIDIOC_S_FBUF</constant>. Again the driver prepares for the +overlay and returns the framebuffer parameters as +<constant>VIDIOC_G_FBUF</constant> does, or it returns an error +code.</para> + + <para>For a <wordasword>destructive Video Overlay</wordasword> +applications must additionally provide a +<structfield>base</structfield> address. Setting up a DMA to a +random memory location can jeopardize the system security, its +stability or even damage the hardware, therefore only the superuser +can set the parameters for a destructive video overlay.</para> + + <!-- NB v4l2_pix_format is also specified in pixfmt.sgml.--> + + <table pgwide="1" frame="none" id="v4l2-framebuffer"> + <title>struct <structname>v4l2_framebuffer</structname></title> + <tgroup cols="4"> + &cs-ustr; + <tbody valign="top"> + <row> + <entry>__u32</entry> + <entry><structfield>capability</structfield></entry> + <entry></entry> + <entry>Overlay capability flags set by the driver, see +<xref linkend="framebuffer-cap" />.</entry> + </row> + <row> + <entry>__u32</entry> + <entry><structfield>flags</structfield></entry> + <entry></entry> + <entry>Overlay control flags set by application and +driver, see <xref linkend="framebuffer-flags" /></entry> + </row> + <row> + <entry>void *</entry> + <entry><structfield>base</structfield></entry> + <entry></entry> + <entry>Physical base address of the framebuffer, +that is the address of the pixel in the top left corner of the +framebuffer.<footnote><para>A physical base address may not suit all +platforms. GK notes in theory we should pass something like PCI device ++ memory region + offset instead. If you encounter problems please +discuss on the linux-media mailing list: &v4l-ml;.</para></footnote></entry> + </row> + <row> + <entry></entry> + <entry></entry> + <entry></entry> + <entry>This field is irrelevant to +<wordasword>non-destructive Video Overlays</wordasword>. For +<wordasword>destructive Video Overlays</wordasword> applications must +provide a base address. The driver may accept only base addresses +which are a multiple of two, four or eight bytes. For +<wordasword>Video Output Overlays</wordasword> the driver must return +a valid base address, so applications can find the corresponding Linux +framebuffer device (see <xref linkend="osd" />).</entry> + </row> + <row> + <entry>&v4l2-pix-format;</entry> + <entry><structfield>fmt</structfield></entry> + <entry></entry> + <entry>Layout of the frame buffer. The +<structname>v4l2_pix_format</structname> structure is defined in <xref +linkend="pixfmt" />, for clarification the fields and acceptable values + are listed below:</entry> + </row> + <row> + <entry></entry> + <entry>__u32</entry> + <entry><structfield>width</structfield></entry> + <entry>Width of the frame buffer in pixels.</entry> + </row> + <row> + <entry></entry> + <entry>__u32</entry> + <entry><structfield>height</structfield></entry> + <entry>Height of the frame buffer in pixels.</entry> + </row> + <row> + <entry></entry> + <entry>__u32</entry> + <entry><structfield>pixelformat</structfield></entry> + <entry>The pixel format of the +framebuffer.</entry> + </row> + <row> + <entry></entry> + <entry></entry> + <entry></entry> + <entry>For <wordasword>non-destructive Video +Overlays</wordasword> this field only defines a format for the +&v4l2-window; <structfield>chromakey</structfield> field.</entry> + </row> + <row> + <entry></entry> + <entry></entry> + <entry></entry> + <entry>For <wordasword>destructive Video +Overlays</wordasword> applications must initialize this field. For +<wordasword>Video Output Overlays</wordasword> the driver must return +a valid format.</entry> + </row> + <row> + <entry></entry> + <entry></entry> + <entry></entry> + <entry>Usually this is an RGB format (for example +<link linkend="V4L2-PIX-FMT-RGB565"><constant>V4L2_PIX_FMT_RGB565</constant></link>) +but YUV formats (only packed YUV formats when chroma keying is used, +not including <constant>V4L2_PIX_FMT_YUYV</constant> and +<constant>V4L2_PIX_FMT_UYVY</constant>) and the +<constant>V4L2_PIX_FMT_PAL8</constant> format are also permitted. The +behavior of the driver when an application requests a compressed +format is undefined. See <xref linkend="pixfmt" /> for information on +pixel formats.</entry> + </row> + <row> + <entry></entry> + <entry>&v4l2-field;</entry> + <entry><structfield>field</structfield></entry> + <entry>Drivers and applications shall ignore this field. +If applicable, the field order is selected with the &VIDIOC-S-FMT; +ioctl, using the <structfield>field</structfield> field of +&v4l2-window;.</entry> + </row> + <row> + <entry></entry> + <entry>__u32</entry> + <entry><structfield>bytesperline</structfield></entry> + <entry>Distance in bytes between the leftmost pixels in +two adjacent lines.</entry> + </row> + <row> + <entry spanname="hspan"><para>This field is irrelevant to +<wordasword>non-destructive Video +Overlays</wordasword>.</para><para>For <wordasword>destructive Video +Overlays</wordasword> both applications and drivers can set this field +to request padding bytes at the end of each line. Drivers however may +ignore the requested value, returning <structfield>width</structfield> +times bytes-per-pixel or a larger value required by the hardware. That +implies applications can just set this field to zero to get a +reasonable default.</para><para>For <wordasword>Video Output +Overlays</wordasword> the driver must return a valid +value.</para><para>Video hardware may access padding bytes, therefore +they must reside in accessible memory. Consider for example the case +where padding bytes after the last line of an image cross a system +page boundary. Capture devices may write padding bytes, the value is +undefined. Output devices ignore the contents of padding +bytes.</para><para>When the image format is planar the +<structfield>bytesperline</structfield> value applies to the largest +plane and is divided by the same factor as the +<structfield>width</structfield> field for any smaller planes. For +example the Cb and Cr planes of a YUV 4:2:0 image have half as many +padding bytes following each line as the Y plane. To avoid ambiguities +drivers must return a <structfield>bytesperline</structfield> value +rounded up to a multiple of the scale factor.</para></entry> + </row> + <row> + <entry></entry> + <entry>__u32</entry> + <entry><structfield>sizeimage</structfield></entry> + <entry><para>This field is irrelevant to +<wordasword>non-destructive Video Overlays</wordasword>. For +<wordasword>destructive Video Overlays</wordasword> applications must +initialize this field. For <wordasword>Video Output +Overlays</wordasword> the driver must return a valid +format.</para><para>Together with <structfield>base</structfield> it +defines the framebuffer memory accessible by the +driver.</para></entry> + </row> + <row> + <entry></entry> + <entry>&v4l2-colorspace;</entry> + <entry><structfield>colorspace</structfield></entry> + <entry>This information supplements the +<structfield>pixelformat</structfield> and must be set by the driver, +see <xref linkend="colorspaces" />.</entry> + </row> + <row> + <entry></entry> + <entry>__u32</entry> + <entry><structfield>priv</structfield></entry> + <entry>Reserved for additional information about custom +(driver defined) formats. When not used drivers and applications must +set this field to zero.</entry> + </row> + </tbody> + </tgroup> + </table> + + <table pgwide="1" frame="none" id="framebuffer-cap"> + <title>Frame Buffer Capability Flags</title> + <tgroup cols="3"> + &cs-def; + <tbody valign="top"> + <row> + <entry><constant>V4L2_FBUF_CAP_EXTERNOVERLAY</constant></entry> + <entry>0x0001</entry> + <entry>The device is capable of non-destructive overlays. +When the driver clears this flag, only destructive overlays are +supported. There are no drivers yet which support both destructive and +non-destructive overlays.</entry> + </row> + <row> + <entry><constant>V4L2_FBUF_CAP_CHROMAKEY</constant></entry> + <entry>0x0002</entry> + <entry>The device supports clipping by chroma-keying the +images. That is, image pixels replace pixels in the VGA or video +signal only where the latter assume a certain color. Chroma-keying +makes no sense for destructive overlays.</entry> + </row> + <row> + <entry><constant>V4L2_FBUF_CAP_LIST_CLIPPING</constant></entry> + <entry>0x0004</entry> + <entry>The device supports clipping using a list of clip +rectangles.</entry> + </row> + <row> + <entry><constant>V4L2_FBUF_CAP_BITMAP_CLIPPING</constant></entry> + <entry>0x0008</entry> + <entry>The device supports clipping using a bit mask.</entry> + </row> + <row> + <entry><constant>V4L2_FBUF_CAP_LOCAL_ALPHA</constant></entry> + <entry>0x0010</entry> + <entry>The device supports clipping/blending using the +alpha channel of the framebuffer or VGA signal. Alpha blending makes +no sense for destructive overlays.</entry> + </row> + <row> + <entry><constant>V4L2_FBUF_CAP_GLOBAL_ALPHA</constant></entry> + <entry>0x0020</entry> + <entry>The device supports alpha blending using a global +alpha value. Alpha blending makes no sense for destructive overlays.</entry> + </row> + <row> + <entry><constant>V4L2_FBUF_CAP_LOCAL_INV_ALPHA</constant></entry> + <entry>0x0040</entry> + <entry>The device supports clipping/blending using the +inverted alpha channel of the framebuffer or VGA signal. Alpha +blending makes no sense for destructive overlays.</entry> + </row> + <row> + <entry><constant>V4L2_FBUF_CAP_SRC_CHROMAKEY</constant></entry> + <entry>0x0080</entry> + <entry>The device supports Source Chroma-keying. Framebuffer pixels +with the chroma-key colors are replaced by video pixels, which is exactly opposite of +<constant>V4L2_FBUF_CAP_CHROMAKEY</constant></entry> + </row> + </tbody> + </tgroup> + </table> + + <table pgwide="1" frame="none" id="framebuffer-flags"> + <title>Frame Buffer Flags</title> + <tgroup cols="3"> + &cs-def; + <tbody valign="top"> + <row> + <entry><constant>V4L2_FBUF_FLAG_PRIMARY</constant></entry> + <entry>0x0001</entry> + <entry>The framebuffer is the primary graphics surface. +In other words, the overlay is destructive. [?]</entry> + </row> + <row> + <entry><constant>V4L2_FBUF_FLAG_OVERLAY</constant></entry> + <entry>0x0002</entry> + <entry>The frame buffer is an overlay surface the same +size as the capture. [?]</entry> + </row> + <row> + <entry spanname="hspan">The purpose of +<constant>V4L2_FBUF_FLAG_PRIMARY</constant> and +<constant>V4L2_FBUF_FLAG_OVERLAY</constant> was never quite clear. +Most drivers seem to ignore these flags. For compatibility with the +<wordasword>bttv</wordasword> driver applications should set the +<constant>V4L2_FBUF_FLAG_OVERLAY</constant> flag.</entry> + </row> + <row> + <entry><constant>V4L2_FBUF_FLAG_CHROMAKEY</constant></entry> + <entry>0x0004</entry> + <entry>Use chroma-keying. The chroma-key color is +determined by the <structfield>chromakey</structfield> field of +&v4l2-window; and negotiated with the &VIDIOC-S-FMT; ioctl, see <xref + linkend="overlay" /> +and + <xref linkend="osd" />.</entry> + </row> + <row> + <entry spanname="hspan">There are no flags to enable +clipping using a list of clip rectangles or a bitmap. These methods +are negotiated with the &VIDIOC-S-FMT; ioctl, see <xref + linkend="overlay" /> and <xref linkend="osd" />.</entry> + </row> + <row> + <entry><constant>V4L2_FBUF_FLAG_LOCAL_ALPHA</constant></entry> + <entry>0x0008</entry> + <entry>Use the alpha channel of the framebuffer to clip or +blend framebuffer pixels with video images. The blend +function is: output = framebuffer pixel * alpha + video pixel * (1 - +alpha). The actual alpha depth depends on the framebuffer pixel +format.</entry> + </row> + <row> + <entry><constant>V4L2_FBUF_FLAG_GLOBAL_ALPHA</constant></entry> + <entry>0x0010</entry> + <entry>Use a global alpha value to blend the framebuffer +with video images. The blend function is: output = (framebuffer pixel +* alpha + video pixel * (255 - alpha)) / 255. The alpha value is +determined by the <structfield>global_alpha</structfield> field of +&v4l2-window; and negotiated with the &VIDIOC-S-FMT; ioctl, see <xref + linkend="overlay" /> +and <xref linkend="osd" />.</entry> + </row> + <row> + <entry><constant>V4L2_FBUF_FLAG_LOCAL_INV_ALPHA</constant></entry> + <entry>0x0020</entry> + <entry>Like +<constant>V4L2_FBUF_FLAG_LOCAL_ALPHA</constant>, use the alpha channel +of the framebuffer to clip or blend framebuffer pixels with video +images, but with an inverted alpha value. The blend function is: +output = framebuffer pixel * (1 - alpha) + video pixel * alpha. The +actual alpha depth depends on the framebuffer pixel format.</entry> + </row> + <row> + <entry><constant>V4L2_FBUF_FLAG_SRC_CHROMAKEY</constant></entry> + <entry>0x0040</entry> + <entry>Use source chroma-keying. The source chroma-key color is +determined by the <structfield>chromakey</structfield> field of +&v4l2-window; and negotiated with the &VIDIOC-S-FMT; ioctl, see <xref +linkend="overlay" /> and <xref linkend="osd" />. +Both chroma-keying are mutual exclusive to each other, so same +<structfield>chromakey</structfield> field of &v4l2-window; is being used.</entry> + </row> + </tbody> + </tgroup> + </table> + </refsect1> + + <refsect1> + &return-value; + + <variablelist> + <varlistentry> + <term><errorcode>EPERM</errorcode></term> + <listitem> + <para><constant>VIDIOC_S_FBUF</constant> can only be called +by a privileged user to negotiate the parameters for a destructive +overlay.</para> + </listitem> + </varlistentry> + <varlistentry> + <term><errorcode>EBUSY</errorcode></term> + <listitem> + <para>The framebuffer parameters cannot be changed at this +time because overlay is already enabled, or capturing is enabled +and the hardware cannot capture and overlay simultaneously.</para> + </listitem> + </varlistentry> + <varlistentry> + <term><errorcode>EINVAL</errorcode></term> + <listitem> + <para>The ioctl is not supported or the +<constant>VIDIOC_S_FBUF</constant> parameters are unsuitable.</para> + </listitem> + </varlistentry> + </variablelist> + </refsect1> +</refentry> + +<!-- +Local Variables: +mode: sgml +sgml-parent-document: "v4l2.sgml" +indent-tabs-mode: nil +End: +--> diff --git a/Documentation/DocBook/v4l/vidioc-g-fmt.xml b/Documentation/DocBook/v4l/vidioc-g-fmt.xml new file mode 100644 index 000000000000..7c7d1b72c40d --- /dev/null +++ b/Documentation/DocBook/v4l/vidioc-g-fmt.xml @@ -0,0 +1,201 @@ +<refentry id="vidioc-g-fmt"> + <refmeta> + <refentrytitle>ioctl VIDIOC_G_FMT, VIDIOC_S_FMT, +VIDIOC_TRY_FMT</refentrytitle> + &manvol; + </refmeta> + + <refnamediv> + <refname>VIDIOC_G_FMT</refname> + <refname>VIDIOC_S_FMT</refname> + <refname>VIDIOC_TRY_FMT</refname> + <refpurpose>Get or set the data format, try a format</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_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_G_FMT, VIDIOC_S_FMT, VIDIOC_TRY_FMT</para> + </listitem> + </varlistentry> + <varlistentry> + <term><parameter>argp</parameter></term> + <listitem> + <para></para> + </listitem> + </varlistentry> + </variablelist> + </refsect1> + + <refsect1> + <title>Description</title> + + <para>These ioctls are used to negotiate the format of data +(typically image format) exchanged between driver and +application.</para> + + <para>To query the current parameters applications set the +<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 +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. +When the requested buffer type is not supported drivers return an +&EINVAL;.</para> + + <para>To change the current format parameters applications +initialize the <structfield>type</structfield> field and all +fields of the respective <structfield>fmt</structfield> +union member. For details see the documentation of the various devices +types in <xref linkend="devices" />. Good practice is to query the +current parameters first, and to +modify only those parameters not suitable for the application. When +the application calls the <constant>VIDIOC_S_FMT</constant> ioctl +with a pointer to a <structname>v4l2_format</structname> structure +the driver checks +and adjusts the parameters against hardware abilities. Drivers +should not return an error code unless the input is ambiguous, this is +a mechanism to fathom device capabilities and to approach parameters +acceptable for both the application and driver. On success the driver +may program the hardware, allocate resources and generally prepare for +data exchange. +Finally the <constant>VIDIOC_S_FMT</constant> ioctl returns the +current format parameters as <constant>VIDIOC_G_FMT</constant> does. +Very simple, inflexible devices may even ignore all input and always +return the default parameters. However all V4L2 devices exchanging +data with the application must implement the +<constant>VIDIOC_G_FMT</constant> and +<constant>VIDIOC_S_FMT</constant> ioctl. When the requested buffer +type is not supported drivers return an &EINVAL; on a +<constant>VIDIOC_S_FMT</constant> attempt. When I/O is already in +progress or the resource is not available for other reasons drivers +return the &EBUSY;.</para> + + <para>The <constant>VIDIOC_TRY_FMT</constant> ioctl is equivalent +to <constant>VIDIOC_S_FMT</constant> with one exception: it does not +change driver state. It can also be called at any time, never +returning <errorcode>EBUSY</errorcode>. This function is provided to +negotiate parameters, to learn about hardware limitations, without +disabling I/O or possibly time consuming hardware preparations. +Although strongly recommended drivers are not required to implement +this ioctl.</para> + + <table pgwide="1" frame="none" id="v4l2-format"> + <title>struct <structname>v4l2_format</structname></title> + <tgroup cols="4"> + <colspec colname="c1" /> + <colspec colname="c2" /> + <colspec colname="c3" /> + <colspec colname="c4" /> + <tbody valign="top"> + <row> + <entry>&v4l2-buf-type;</entry> + <entry><structfield>type</structfield></entry> + <entry></entry> + <entry>Type of the data stream, see <xref + linkend="v4l2-buf-type" />.</entry> + </row> + <row> + <entry>union</entry> + <entry><structfield>fmt</structfield></entry> + </row> + <row> + <entry></entry> + <entry>&v4l2-pix-format;</entry> + <entry><structfield>pix</structfield></entry> + <entry>Definition of an image format, see <xref + linkend="pixfmt" />, used by video capture and output +devices.</entry> + </row> + <row> + <entry></entry> + <entry>&v4l2-window;</entry> + <entry><structfield>win</structfield></entry> + <entry>Definition of an overlaid image, see <xref + linkend="overlay" />, used by video overlay devices.</entry> + </row> + <row> + <entry></entry> + <entry>&v4l2-vbi-format;</entry> + <entry><structfield>vbi</structfield></entry> + <entry>Raw VBI capture or output parameters. This is +discussed in more detail in <xref linkend="raw-vbi" />. Used by raw VBI +capture and output devices.</entry> + </row> + <row> + <entry></entry> + <entry>&v4l2-sliced-vbi-format;</entry> + <entry><structfield>sliced</structfield></entry> + <entry>Sliced VBI capture or output parameters. See +<xref linkend="sliced" /> for details. Used by sliced VBI +capture and output devices.</entry> + </row> + <row> + <entry></entry> + <entry>__u8</entry> + <entry><structfield>raw_data</structfield>[200]</entry> + <entry>Place holder for future extensions and custom +(driver defined) formats with <structfield>type</structfield> +<constant>V4L2_BUF_TYPE_PRIVATE</constant> and higher.</entry> + </row> + </tbody> + </tgroup> + </table> + </refsect1> + + <refsect1> + &return-value; + + <variablelist> + <varlistentry> + <term><errorcode>EBUSY</errorcode></term> + <listitem> + <para>The data format cannot be changed at this +time, for example because I/O is already in progress.</para> + </listitem> + </varlistentry> + <varlistentry> + <term><errorcode>EINVAL</errorcode></term> + <listitem> + <para>The &v4l2-format; <structfield>type</structfield> +field is invalid, the requested buffer type not supported, or +<constant>VIDIOC_TRY_FMT</constant> was called and is not +supported with this buffer type.</para> + </listitem> + </varlistentry> + </variablelist> + </refsect1> +</refentry> + +<!-- +Local Variables: +mode: sgml +sgml-parent-document: "v4l2.sgml" +indent-tabs-mode: nil +End: +--> diff --git a/Documentation/DocBook/v4l/vidioc-g-frequency.xml b/Documentation/DocBook/v4l/vidioc-g-frequency.xml new file mode 100644 index 000000000000..062d72069090 --- /dev/null +++ b/Documentation/DocBook/v4l/vidioc-g-frequency.xml @@ -0,0 +1,145 @@ +<refentry id="vidioc-g-frequency"> + <refmeta> + <refentrytitle>ioctl VIDIOC_G_FREQUENCY, VIDIOC_S_FREQUENCY</refentrytitle> + &manvol; + </refmeta> + + <refnamediv> + <refname>VIDIOC_G_FREQUENCY</refname> + <refname>VIDIOC_S_FREQUENCY</refname> + <refpurpose>Get or set tuner or modulator radio +frequency</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_frequency +*<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_frequency +*<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_G_FREQUENCY, VIDIOC_S_FREQUENCY</para> + </listitem> + </varlistentry> + <varlistentry> + <term><parameter>argp</parameter></term> + <listitem> + <para></para> + </listitem> + </varlistentry> + </variablelist> + </refsect1> + + <refsect1> + <title>Description</title> + + <para>To get the current tuner or modulator radio frequency +applications set the <structfield>tuner</structfield> field of a +&v4l2-frequency; to the respective tuner or modulator number (only +input devices have tuners, only output devices have modulators), zero +out the <structfield>reserved</structfield> array and +call the <constant>VIDIOC_G_FREQUENCY</constant> ioctl with a pointer +to this structure. The driver stores the current frequency in the +<structfield>frequency</structfield> field.</para> + + <para>To change the current tuner or modulator radio frequency +applications initialize the <structfield>tuner</structfield>, +<structfield>type</structfield> and +<structfield>frequency</structfield> fields, and the +<structfield>reserved</structfield> array of a &v4l2-frequency; and +call the <constant>VIDIOC_S_FREQUENCY</constant> ioctl with a pointer +to this structure. When the requested frequency is not possible the +driver assumes the closest possible value. However +<constant>VIDIOC_S_FREQUENCY</constant> is a write-only ioctl, it does +not return the actual new frequency.</para> + + <table pgwide="1" frame="none" id="v4l2-frequency"> + <title>struct <structname>v4l2_frequency</structname></title> + <tgroup cols="3"> + &cs-str; + <tbody valign="top"> + <row> + <entry>__u32</entry> + <entry><structfield>tuner</structfield></entry> + <entry>The tuner or modulator index number. This is the +same value as in the &v4l2-input; <structfield>tuner</structfield> +field and the &v4l2-tuner; <structfield>index</structfield> field, or +the &v4l2-output; <structfield>modulator</structfield> field and the +&v4l2-modulator; <structfield>index</structfield> field.</entry> + </row> + <row> + <entry>&v4l2-tuner-type;</entry> + <entry><structfield>type</structfield></entry> + <entry>The tuner type. This is the same value as in the +&v4l2-tuner; <structfield>type</structfield> field. The field is not +applicable to modulators, &ie; ignored by drivers.</entry> + </row> + <row> + <entry>__u32</entry> + <entry><structfield>frequency</structfield></entry> + <entry>Tuning frequency in units of 62.5 kHz, or if the +&v4l2-tuner; or &v4l2-modulator; <structfield>capabilities</structfield> flag +<constant>V4L2_TUNER_CAP_LOW</constant> is set, in units of 62.5 +Hz.</entry> + </row> + <row> + <entry>__u32</entry> + <entry><structfield>reserved</structfield>[8]</entry> + <entry>Reserved for future extensions. Drivers and + applications 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 <structfield>tuner</structfield> index is out of +bounds or the value in the <structfield>type</structfield> field is +wrong.</para> + </listitem> + </varlistentry> + </variablelist> + </refsect1> +</refentry> + +<!-- +Local Variables: +mode: sgml +sgml-parent-document: "v4l2.sgml" +indent-tabs-mode: nil +End: +--> diff --git a/Documentation/DocBook/v4l/vidioc-g-input.xml b/Documentation/DocBook/v4l/vidioc-g-input.xml new file mode 100644 index 000000000000..ed076e92760d --- /dev/null +++ b/Documentation/DocBook/v4l/vidioc-g-input.xml @@ -0,0 +1,100 @@ +<refentry id="vidioc-g-input"> + <refmeta> + <refentrytitle>ioctl VIDIOC_G_INPUT, VIDIOC_S_INPUT</refentrytitle> + &manvol; + </refmeta> + + <refnamediv> + <refname>VIDIOC_G_INPUT</refname> + <refname>VIDIOC_S_INPUT</refname> + <refpurpose>Query or select the current video input</refpurpose> + </refnamediv> + + <refsynopsisdiv> + <funcsynopsis> + <funcprototype> + <funcdef>int <function>ioctl</function></funcdef> + <paramdef>int <parameter>fd</parameter></paramdef> + <paramdef>int <parameter>request</parameter></paramdef> + <paramdef>int *<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_G_INPUT, VIDIOC_S_INPUT</para> + </listitem> + </varlistentry> + <varlistentry> + <term><parameter>argp</parameter></term> + <listitem> + <para></para> + </listitem> + </varlistentry> + </variablelist> + </refsect1> + + <refsect1> + <title>Description</title> + + <para>To query the current video input applications call the +<constant>VIDIOC_G_INPUT</constant> ioctl with a pointer to an integer +where the driver stores the number of the input, as in the +&v4l2-input; <structfield>index</structfield> field. This ioctl will +fail only when there are no video inputs, returning +<errorcode>EINVAL</errorcode>.</para> + + <para>To select a video input applications store the number of the +desired input in an integer and call the +<constant>VIDIOC_S_INPUT</constant> ioctl with a pointer to this +integer. Side effects are possible. For example inputs may support +different video standards, so the driver may implicitly switch the +current standard. It is good practice to select an input before +querying or negotiating any other parameters.</para> + + <para>Information about video inputs is available using the +&VIDIOC-ENUMINPUT; ioctl.</para> + </refsect1> + + <refsect1> + &return-value; + + <variablelist> + <varlistentry> + <term><errorcode>EINVAL</errorcode></term> + <listitem> + <para>The number of the video input is out of bounds, or +there are no video inputs at all and this ioctl is not +supported.</para> + </listitem> + </varlistentry> + <varlistentry> + <term><errorcode>EBUSY</errorcode></term> + <listitem> + <para>I/O is in progress, the input cannot be +switched.</para> + </listitem> + </varlistentry> + </variablelist> + </refsect1> +</refentry> + +<!-- +Local Variables: +mode: sgml +sgml-parent-document: "v4l2.sgml" +indent-tabs-mode: nil +End: +--> diff --git a/Documentation/DocBook/v4l/vidioc-g-jpegcomp.xml b/Documentation/DocBook/v4l/vidioc-g-jpegcomp.xml new file mode 100644 index 000000000000..77394b287411 --- /dev/null +++ b/Documentation/DocBook/v4l/vidioc-g-jpegcomp.xml @@ -0,0 +1,180 @@ +<refentry id="vidioc-g-jpegcomp"> + <refmeta> + <refentrytitle>ioctl VIDIOC_G_JPEGCOMP, VIDIOC_S_JPEGCOMP</refentrytitle> + &manvol; + </refmeta> + + <refnamediv> + <refname>VIDIOC_G_JPEGCOMP</refname> + <refname>VIDIOC_S_JPEGCOMP</refname> + <refpurpose></refpurpose> + </refnamediv> + + <refsynopsisdiv> + <funcsynopsis> + <funcprototype> + <funcdef>int <function>ioctl</function></funcdef> + <paramdef>int <parameter>fd</parameter></paramdef> + <paramdef>int <parameter>request</parameter></paramdef> + <paramdef>v4l2_jpegcompression *<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 v4l2_jpegcompression *<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_G_JPEGCOMP, VIDIOC_S_JPEGCOMP</para> + </listitem> + </varlistentry> + <varlistentry> + <term><parameter>argp</parameter></term> + <listitem> + <para></para> + </listitem> + </varlistentry> + </variablelist> + </refsect1> + + <refsect1> + <title>Description</title> + + <para>[to do]</para> + + <para>Ronald Bultje elaborates:</para> + + <!-- See video4linux-list@redhat.com on 16 Oct 2002, subject +"Re: [V4L] Re: v4l2 api / Zoran v4l2_jpegcompression" --> + + <para>APP is some application-specific information. The +application can set it itself, and it'll be stored in the JPEG-encoded +fields (eg; interlacing information for in an AVI or so). COM is the +same, but it's comments, like 'encoded by me' or so.</para> + + <para>jpeg_markers describes whether the huffman tables, +quantization tables and the restart interval information (all +JPEG-specific stuff) should be stored in the JPEG-encoded fields. +These define how the JPEG field is encoded. If you omit them, +applications assume you've used standard encoding. You usually do want +to add them.</para> + + <!-- NB VIDIOC_S_JPEGCOMP is w/o. --> + + <table pgwide="1" frame="none" id="v4l2-jpegcompression"> + <title>struct <structname>v4l2_jpegcompression</structname></title> + <tgroup cols="3"> + &cs-str; + <tbody valign="top"> + <row> + <entry>int</entry> + <entry><structfield>quality</structfield></entry> + <entry></entry> + </row> + <row> + <entry>int</entry> + <entry><structfield>APPn</structfield></entry> + <entry></entry> + </row> + <row> + <entry>int</entry> + <entry><structfield>APP_len</structfield></entry> + <entry></entry> + </row> + <row> + <entry>char</entry> + <entry><structfield>APP_data</structfield>[60]</entry> + <entry></entry> + </row> + <row> + <entry>int</entry> + <entry><structfield>COM_len</structfield></entry> + <entry></entry> + </row> + <row> + <entry>char</entry> + <entry><structfield>COM_data</structfield>[60]</entry> + <entry></entry> + </row> + <row> + <entry>__u32</entry> + <entry><structfield>jpeg_markers</structfield></entry> + <entry>See <xref linkend="jpeg-markers" />.</entry> + </row> + </tbody> + </tgroup> + </table> + + <table pgwide="1" frame="none" id="jpeg-markers"> + <title>JPEG Markers Flags</title> + <tgroup cols="3"> + &cs-def; + <tbody valign="top"> + <row> + <entry><constant>V4L2_JPEG_MARKER_DHT</constant></entry> + <entry>(1<<3)</entry> + <entry>Define Huffman Tables</entry> + </row> + <row> + <entry><constant>V4L2_JPEG_MARKER_DQT</constant></entry> + <entry>(1<<4)</entry> + <entry>Define Quantization Tables</entry> + </row> + <row> + <entry><constant>V4L2_JPEG_MARKER_DRI</constant></entry> + <entry>(1<<5)</entry> + <entry>Define Restart Interval</entry> + </row> + <row> + <entry><constant>V4L2_JPEG_MARKER_COM</constant></entry> + <entry>(1<<6)</entry> + <entry>Comment segment</entry> + </row> + <row> + <entry><constant>V4L2_JPEG_MARKER_APP</constant></entry> + <entry>(1<<7)</entry> + <entry>App segment, driver will always use APP0</entry> + </row> + </tbody> + </tgroup> + </table> + </refsect1> + + <refsect1> + &return-value; + + <variablelist> + <varlistentry> + <term><errorcode>EINVAL</errorcode></term> + <listitem> + <para>This ioctl is not supported.</para> + </listitem> + </varlistentry> + </variablelist> + </refsect1> +</refentry> + +<!-- +Local Variables: +mode: sgml +sgml-parent-document: "v4l2.sgml" +indent-tabs-mode: nil +End: +--> diff --git a/Documentation/DocBook/v4l/vidioc-g-modulator.xml b/Documentation/DocBook/v4l/vidioc-g-modulator.xml new file mode 100644 index 000000000000..15ce660f0f5a --- /dev/null +++ b/Documentation/DocBook/v4l/vidioc-g-modulator.xml @@ -0,0 +1,246 @@ +<refentry id="vidioc-g-modulator"> + <refmeta> + <refentrytitle>ioctl VIDIOC_G_MODULATOR, VIDIOC_S_MODULATOR</refentrytitle> + &manvol; + </refmeta> + + <refnamediv> + <refname>VIDIOC_G_MODULATOR</refname> + <refname>VIDIOC_S_MODULATOR</refname> + <refpurpose>Get or set modulator attributes</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_modulator +*<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_modulator +*<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_G_MODULATOR, VIDIOC_S_MODULATOR</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 a modulator applications initialize +the <structfield>index</structfield> field and zero out the +<structfield>reserved</structfield> array of a &v4l2-modulator; and +call the <constant>VIDIOC_G_MODULATOR</constant> ioctl with a pointer +to this structure. Drivers fill the rest of the structure or return an +&EINVAL; when the index is out of bounds. To enumerate all modulators +applications shall begin at index zero, incrementing by one until the +driver returns <errorcode>EINVAL</errorcode>.</para> + + <para>Modulators have two writable properties, an audio +modulation set and the radio frequency. To change the modulated audio +subprograms, applications initialize the <structfield>index +</structfield> and <structfield>txsubchans</structfield> fields and the +<structfield>reserved</structfield> array and call the +<constant>VIDIOC_S_MODULATOR</constant> ioctl. Drivers may choose a +different audio modulation if the request cannot be satisfied. However +this is a write-only ioctl, it does not return the actual audio +modulation selected.</para> + + <para>To change the radio frequency the &VIDIOC-S-FREQUENCY; ioctl +is available.</para> + + <table pgwide="1" frame="none" id="v4l2-modulator"> + <title>struct <structname>v4l2_modulator</structname></title> + <tgroup cols="3"> + &cs-str; + <tbody valign="top"> + <row> + <entry>__u32</entry> + <entry><structfield>index</structfield></entry> + <entry>Identifies the modulator, set by the +application.</entry> + </row> + <row> + <entry>__u8</entry> + <entry><structfield>name</structfield>[32]</entry> + <entry>Name of the modulator, a NUL-terminated ASCII +string. This information is intended for the user.</entry> + </row> + <row> + <entry>__u32</entry> + <entry><structfield>capability</structfield></entry> + <entry>Modulator capability flags. No flags are defined +for this field, the tuner flags in &v4l2-tuner; +are used accordingly. The audio flags indicate the ability +to encode audio subprograms. They will <emphasis>not</emphasis> +change for example with the current video standard.</entry> + </row> + <row> + <entry>__u32</entry> + <entry><structfield>rangelow</structfield></entry> + <entry>The lowest tunable frequency in units of 62.5 +KHz, or if the <structfield>capability</structfield> flag +<constant>V4L2_TUNER_CAP_LOW</constant> is set, in units of 62.5 +Hz.</entry> + </row> + <row> + <entry>__u32</entry> + <entry><structfield>rangehigh</structfield></entry> + <entry>The highest tunable frequency in units of 62.5 +KHz, or if the <structfield>capability</structfield> flag +<constant>V4L2_TUNER_CAP_LOW</constant> is set, in units of 62.5 +Hz.</entry> + </row> + <row> + <entry>__u32</entry> + <entry><structfield>txsubchans</structfield></entry> + <entry>With this field applications can determine how +audio sub-carriers shall be modulated. It contains a set of flags as +defined in <xref linkend="modulator-txsubchans" />. Note the tuner +<structfield>rxsubchans</structfield> flags are reused, but the +semantics are different. Video output devices are assumed to have an +analog or PCM audio input with 1-3 channels. The +<structfield>txsubchans</structfield> flags select one or more +channels for modulation, together with some audio subprogram +indicator, for example a stereo pilot tone.</entry> + </row> + <row> + <entry>__u32</entry> + <entry><structfield>reserved</structfield>[4]</entry> + <entry>Reserved for future extensions. Drivers and +applications must set the array to zero.</entry> + </row> + </tbody> + </tgroup> + </table> + + <table pgwide="1" frame="none" id="modulator-txsubchans"> + <title>Modulator Audio Transmission Flags</title> + <tgroup cols="3"> + &cs-def; + <tbody valign="top"> + <row> + <entry><constant>V4L2_TUNER_SUB_MONO</constant></entry> + <entry>0x0001</entry> + <entry>Modulate channel 1 as mono audio, when the input +has more channels, a down-mix of channel 1 and 2. This flag does not +combine with <constant>V4L2_TUNER_SUB_STEREO</constant> or +<constant>V4L2_TUNER_SUB_LANG1</constant>.</entry> + </row> + <row> + <entry><constant>V4L2_TUNER_SUB_STEREO</constant></entry> + <entry>0x0002</entry> + <entry>Modulate channel 1 and 2 as left and right +channel of a stereo audio signal. When the input has only one channel +or two channels and <constant>V4L2_TUNER_SUB_SAP</constant> is also +set, channel 1 is encoded as left and right channel. This flag does +not combine with <constant>V4L2_TUNER_SUB_MONO</constant> or +<constant>V4L2_TUNER_SUB_LANG1</constant>. When the driver does not +support stereo audio it shall fall back to mono.</entry> + </row> + <row> + <entry><constant>V4L2_TUNER_SUB_LANG1</constant></entry> + <entry>0x0008</entry> + <entry>Modulate channel 1 and 2 as primary and secondary +language of a bilingual audio signal. When the input has only one +channel it is used for both languages. It is not possible to encode +the primary or secondary language only. This flag does not combine +with <constant>V4L2_TUNER_SUB_MONO</constant>, +<constant>V4L2_TUNER_SUB_STEREO</constant> or +<constant>V4L2_TUNER_SUB_SAP</constant>. If the hardware does not +support the respective audio matrix, or the current video standard +does not permit bilingual audio the +<constant>VIDIOC_S_MODULATOR</constant> ioctl shall return an &EINVAL; +and the driver shall fall back to mono or stereo mode.</entry> + </row> + <row> + <entry><constant>V4L2_TUNER_SUB_LANG2</constant></entry> + <entry>0x0004</entry> + <entry>Same effect as +<constant>V4L2_TUNER_SUB_SAP</constant>.</entry> + </row> + <row> + <entry><constant>V4L2_TUNER_SUB_SAP</constant></entry> + <entry>0x0004</entry> + <entry>When combined with <constant>V4L2_TUNER_SUB_MONO +</constant> the first channel is encoded as mono audio, the last +channel as Second Audio Program. When the input has only one channel +it is used for both audio tracks. When the input has three channels +the mono track is a down-mix of channel 1 and 2. When combined with +<constant>V4L2_TUNER_SUB_STEREO</constant> channel 1 and 2 are +encoded as left and right stereo audio, channel 3 as Second Audio +Program. When the input has only two channels, the first is encoded as +left and right channel and the second as SAP. When the input has only +one channel it is used for all audio tracks. It is not possible to +encode a Second Audio Program only. This flag must combine with +<constant>V4L2_TUNER_SUB_MONO</constant> or +<constant>V4L2_TUNER_SUB_STEREO</constant>. If the hardware does not +support the respective audio matrix, or the current video standard +does not permit SAP the <constant>VIDIOC_S_MODULATOR</constant> ioctl +shall return an &EINVAL; and driver shall fall back to mono or stereo +mode.</entry> + </row> + <row> + <entry><constant>V4L2_TUNER_SUB_RDS</constant></entry> + <entry>0x0010</entry> + <entry>Enable the RDS encoder for a radio FM transmitter.</entry> + </row> + </tbody> + </tgroup> + </table> + </refsect1> + + <refsect1> + &return-value; + + <variablelist> + <varlistentry> + <term><errorcode>EINVAL</errorcode></term> + <listitem> + <para>The &v4l2-modulator; +<structfield>index</structfield> is out of bounds.</para> + </listitem> + </varlistentry> + </variablelist> + </refsect1> +</refentry> + +<!-- +Local Variables: +mode: sgml +sgml-parent-document: "v4l2.sgml" +indent-tabs-mode: nil +End: +--> diff --git a/Documentation/DocBook/v4l/vidioc-g-output.xml b/Documentation/DocBook/v4l/vidioc-g-output.xml new file mode 100644 index 000000000000..3ea8c0ed812e --- /dev/null +++ b/Documentation/DocBook/v4l/vidioc-g-output.xml @@ -0,0 +1,100 @@ +<refentry id="vidioc-g-output"> + <refmeta> + <refentrytitle>ioctl VIDIOC_G_OUTPUT, VIDIOC_S_OUTPUT</refentrytitle> + &manvol; + </refmeta> + + <refnamediv> + <refname>VIDIOC_G_OUTPUT</refname> + <refname>VIDIOC_S_OUTPUT</refname> + <refpurpose>Query or select the current video output</refpurpose> + </refnamediv> + + <refsynopsisdiv> + <funcsynopsis> + <funcprototype> + <funcdef>int <function>ioctl</function></funcdef> + <paramdef>int <parameter>fd</parameter></paramdef> + <paramdef>int <parameter>request</parameter></paramdef> + <paramdef>int *<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_G_OUTPUT, VIDIOC_S_OUTPUT</para> + </listitem> + </varlistentry> + <varlistentry> + <term><parameter>argp</parameter></term> + <listitem> + <para></para> + </listitem> + </varlistentry> + </variablelist> + </refsect1> + + <refsect1> + <title>Description</title> + + <para>To query the current video output applications call the +<constant>VIDIOC_G_OUTPUT</constant> ioctl with a pointer to an integer +where the driver stores the number of the output, as in the +&v4l2-output; <structfield>index</structfield> field. This ioctl +will fail only when there are no video outputs, returning the +&EINVAL;.</para> + + <para>To select a video output applications store the number of the +desired output in an integer and call the +<constant>VIDIOC_S_OUTPUT</constant> ioctl with a pointer to this integer. +Side effects are possible. For example outputs may support different +video standards, so the driver may implicitly switch the current +standard. It is good practice to select an output before querying or +negotiating any other parameters.</para> + + <para>Information about video outputs is available using the +&VIDIOC-ENUMOUTPUT; ioctl.</para> + </refsect1> + + <refsect1> + &return-value; + + <variablelist> + <varlistentry> + <term><errorcode>EINVAL</errorcode></term> + <listitem> + <para>The number of the video output is out of bounds, or +there are no video outputs at all and this ioctl is not +supported.</para> + </listitem> + </varlistentry> + <varlistentry> + <term><errorcode>EBUSY</errorcode></term> + <listitem> + <para>I/O is in progress, the output cannot be +switched.</para> + </listitem> + </varlistentry> + </variablelist> + </refsect1> +</refentry> + +<!-- +Local Variables: +mode: sgml +sgml-parent-document: "v4l2.sgml" +indent-tabs-mode: nil +End: +--> diff --git a/Documentation/DocBook/v4l/vidioc-g-parm.xml b/Documentation/DocBook/v4l/vidioc-g-parm.xml new file mode 100644 index 000000000000..78332d365ce9 --- /dev/null +++ b/Documentation/DocBook/v4l/vidioc-g-parm.xml @@ -0,0 +1,332 @@ +<refentry id="vidioc-g-parm"> + <refmeta> + <refentrytitle>ioctl VIDIOC_G_PARM, VIDIOC_S_PARM</refentrytitle> + &manvol; + </refmeta> + + <refnamediv> + <refname>VIDIOC_G_PARM</refname> + <refname>VIDIOC_S_PARM</refname> + <refpurpose>Get or set streaming parameters</refpurpose> + </refnamediv> + + <refsynopsisdiv> + <funcsynopsis> + <funcprototype> + <funcdef>int <function>ioctl</function></funcdef> + <paramdef>int <parameter>fd</parameter></paramdef> + <paramdef>int <parameter>request</parameter></paramdef> + <paramdef>v4l2_streamparm *<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_G_PARM, VIDIOC_S_PARM</para> + </listitem> + </varlistentry> + <varlistentry> + <term><parameter>argp</parameter></term> + <listitem> + <para></para> + </listitem> + </varlistentry> + </variablelist> + </refsect1> + + <refsect1> + <title>Description</title> + + <para>The current video standard determines a nominal number of +frames per second. If less than this number of frames is to be +captured or output, applications can request frame skipping or +duplicating on the driver side. This is especially useful when using +the <function>read()</function> or <function>write()</function>, which +are not augmented by timestamps or sequence counters, and to avoid +unneccessary data copying.</para> + + <para>Further these ioctls can be used to determine the number of +buffers used internally by a driver in read/write mode. For +implications see the section discussing the &func-read; +function.</para> + + <para>To get and set the streaming parameters applications call +the <constant>VIDIOC_G_PARM</constant> and +<constant>VIDIOC_S_PARM</constant> ioctl, respectively. They take a +pointer to a struct <structname>v4l2_streamparm</structname> which +contains a union holding separate parameters for input and output +devices.</para> + + <table pgwide="1" frame="none" id="v4l2-streamparm"> + <title>struct <structname>v4l2_streamparm</structname></title> + <tgroup cols="4"> + &cs-ustr; + <tbody valign="top"> + <row> + <entry>&v4l2-buf-type;</entry> + <entry><structfield>type</structfield></entry> + <entry></entry> + <entry>The buffer (stream) type, same as &v4l2-format; +<structfield>type</structfield>, set by the application.</entry> + </row> + <row> + <entry>union</entry> + <entry><structfield>parm</structfield></entry> + <entry></entry> + <entry></entry> + </row> + <row> + <entry></entry> + <entry>&v4l2-captureparm;</entry> + <entry><structfield>capture</structfield></entry> + <entry>Parameters for capture devices, used when +<structfield>type</structfield> is +<constant>V4L2_BUF_TYPE_VIDEO_CAPTURE</constant>.</entry> + </row> + <row> + <entry></entry> + <entry>&v4l2-outputparm;</entry> + <entry><structfield>output</structfield></entry> + <entry>Parameters for output devices, used when +<structfield>type</structfield> is +<constant>V4L2_BUF_TYPE_VIDEO_OUTPUT</constant>.</entry> + </row> + <row> + <entry></entry> + <entry>__u8</entry> + <entry><structfield>raw_data</structfield>[200]</entry> + <entry>A place holder for future extensions and custom +(driver defined) buffer types <constant>V4L2_BUF_TYPE_PRIVATE</constant> and +higher.</entry> + </row> + </tbody> + </tgroup> + </table> + + <table pgwide="1" frame="none" id="v4l2-captureparm"> + <title>struct <structname>v4l2_captureparm</structname></title> + <tgroup cols="3"> + &cs-str; + <tbody valign="top"> + <row> + <entry>__u32</entry> + <entry><structfield>capability</structfield></entry> + <entry>See <xref linkend="parm-caps" />.</entry> + </row> + <row> + <entry>__u32</entry> + <entry><structfield>capturemode</structfield></entry> + <entry>Set by drivers and applications, see <xref linkend="parm-flags" />.</entry> + </row> + <row> + <entry>&v4l2-fract;</entry> + <entry><structfield>timeperframe</structfield></entry> + <entry><para>This is is the desired period between +successive frames captured by the driver, in seconds. The +field is intended to skip frames on the driver side, saving I/O +bandwidth.</para><para>Applications store here the desired frame +period, drivers return the actual frame period, which must be greater +or equal to the nominal frame period determined by the current video +standard (&v4l2-standard; <structfield>frameperiod</structfield> +field). Changing the video standard (also implicitly by switching the +video input) may reset this parameter to the nominal frame period. To +reset manually applications can just set this field to +zero.</para><para>Drivers support this function only when they set the +<constant>V4L2_CAP_TIMEPERFRAME</constant> flag in the +<structfield>capability</structfield> field.</para></entry> + </row> + <row> + <entry>__u32</entry> + <entry><structfield>extendedmode</structfield></entry> + <entry>Custom (driver specific) streaming parameters. When +unused, applications and drivers must set this field to zero. +Applications using this field should check the driver name and +version, see <xref linkend="querycap" />.</entry> + </row> + <row> + <entry>__u32</entry> + <entry><structfield>readbuffers</structfield></entry> + <entry>Applications set this field to the desired number +of buffers used internally by the driver in &func-read; mode. Drivers +return the actual number of buffers. When an application requests zero +buffers, drivers should just return the current setting rather than +the minimum or an error code. For details see <xref + linkend="rw" />.</entry> + </row> + <row> + <entry>__u32</entry> + <entry><structfield>reserved</structfield>[4]</entry> + <entry>Reserved for future extensions. Drivers and +applications must set the array to zero.</entry> + </row> + </tbody> + </tgroup> + </table> + + <table pgwide="1" frame="none" id="v4l2-outputparm"> + <title>struct <structname>v4l2_outputparm</structname></title> + <tgroup cols="3"> + &cs-str; + <tbody valign="top"> + <row> + <entry>__u32</entry> + <entry><structfield>capability</structfield></entry> + <entry>See <xref linkend="parm-caps" />.</entry> + </row> + <row> + <entry>__u32</entry> + <entry><structfield>outputmode</structfield></entry> + <entry>Set by drivers and applications, see <xref + linkend="parm-flags" />.</entry> + </row> + <row> + <entry>&v4l2-fract;</entry> + <entry><structfield>timeperframe</structfield></entry> + <entry>This is is the desired period between +successive frames output by the driver, in seconds.</entry> + </row> + <row> + <entry spanname="hspan"><para>The field is intended to +repeat frames on the driver side in &func-write; mode (in streaming +mode timestamps can be used to throttle the output), saving I/O +bandwidth.</para><para>Applications store here the desired frame +period, drivers return the actual frame period, which must be greater +or equal to the nominal frame period determined by the current video +standard (&v4l2-standard; <structfield>frameperiod</structfield> +field). Changing the video standard (also implicitly by switching the +video output) may reset this parameter to the nominal frame period. To +reset manually applications can just set this field to +zero.</para><para>Drivers support this function only when they set the +<constant>V4L2_CAP_TIMEPERFRAME</constant> flag in the +<structfield>capability</structfield> field.</para></entry> + </row> + <row> + <entry>__u32</entry> + <entry><structfield>extendedmode</structfield></entry> + <entry>Custom (driver specific) streaming parameters. When +unused, applications and drivers must set this field to zero. +Applications using this field should check the driver name and +version, see <xref linkend="querycap" />.</entry> + </row> + <row> + <entry>__u32</entry> + <entry><structfield>writebuffers</structfield></entry> + <entry>Applications set this field to the desired number +of buffers used internally by the driver in +<function>write()</function> mode. Drivers return the actual number of +buffers. When an application requests zero buffers, drivers should +just return the current setting rather than the minimum or an error +code. For details see <xref linkend="rw" />.</entry> + </row> + <row> + <entry>__u32</entry> + <entry><structfield>reserved</structfield>[4]</entry> + <entry>Reserved for future extensions. Drivers and +applications must set the array to zero.</entry> + </row> + </tbody> + </tgroup> + </table> + + <table pgwide="1" frame="none" id="parm-caps"> + <title>Streaming Parameters Capabilites</title> + <tgroup cols="3"> + &cs-def; + <tbody valign="top"> + <row> + <entry><constant>V4L2_CAP_TIMEPERFRAME</constant></entry> + <entry>0x1000</entry> + <entry>The frame skipping/repeating controlled by the +<structfield>timeperframe</structfield> field is supported.</entry> + </row> + </tbody> + </tgroup> + </table> + + <table pgwide="1" frame="none" id="parm-flags"> + <title>Capture Parameters Flags</title> + <tgroup cols="3"> + &cs-def; + <tbody valign="top"> + <row> + <entry><constant>V4L2_MODE_HIGHQUALITY</constant></entry> + <entry>0x0001</entry> + <entry><para>High quality imaging mode. High quality mode +is intended for still imaging applications. The idea is to get the +best possible image quality that the hardware can deliver. It is not +defined how the driver writer may achieve that; it will depend on the +hardware and the ingenuity of the driver writer. High quality mode is +a different mode from the the regular motion video capture modes. In +high quality mode:<itemizedlist> + <listitem> + <para>The driver may be able to capture higher +resolutions than for motion capture.</para> + </listitem> + <listitem> + <para>The driver may support fewer pixel formats +than motion capture (eg; true color).</para> + </listitem> + <listitem> + <para>The driver may capture and arithmetically +combine multiple successive fields or frames to remove color edge +artifacts and reduce the noise in the video data. +</para> + </listitem> + <listitem> + <para>The driver may capture images in slices like +a scanner in order to handle larger format images than would otherwise +be possible. </para> + </listitem> + <listitem> + <para>An image capture operation may be +significantly slower than motion capture. </para> + </listitem> + <listitem> + <para>Moving objects in the image might have +excessive motion blur. </para> + </listitem> + <listitem> + <para>Capture might only work through the +<function>read()</function> call.</para> + </listitem> + </itemizedlist></para></entry> + </row> + </tbody> + </tgroup> + </table> + + </refsect1> + + <refsect1> + &return-value; + + <variablelist> + <varlistentry> + <term><errorcode>EINVAL</errorcode></term> + <listitem> + <para>This ioctl is not supported.</para> + </listitem> + </varlistentry> + </variablelist> + </refsect1> +</refentry> + +<!-- +Local Variables: +mode: sgml +sgml-parent-document: "v4l2.sgml" +indent-tabs-mode: nil +End: +--> diff --git a/Documentation/DocBook/v4l/vidioc-g-priority.xml b/Documentation/DocBook/v4l/vidioc-g-priority.xml new file mode 100644 index 000000000000..5fb001978645 --- /dev/null +++ b/Documentation/DocBook/v4l/vidioc-g-priority.xml @@ -0,0 +1,144 @@ +<refentry id="vidioc-g-priority"> + <refmeta> + <refentrytitle>ioctl VIDIOC_G_PRIORITY, VIDIOC_S_PRIORITY</refentrytitle> + &manvol; + </refmeta> + + <refnamediv> + <refname>VIDIOC_G_PRIORITY</refname> + <refname>VIDIOC_S_PRIORITY</refname> + <refpurpose>Query or request the access priority associated with a +file descriptor</refpurpose> + </refnamediv> + + <refsynopsisdiv> + <funcsynopsis> + <funcprototype> + <funcdef>int <function>ioctl</function></funcdef> + <paramdef>int <parameter>fd</parameter></paramdef> + <paramdef>int <parameter>request</parameter></paramdef> + <paramdef>enum v4l2_priority *<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 enum v4l2_priority *<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_G_PRIORITY, VIDIOC_S_PRIORITY</para> + </listitem> + </varlistentry> + <varlistentry> + <term><parameter>argp</parameter></term> + <listitem> + <para>Pointer to an enum v4l2_priority type.</para> + </listitem> + </varlistentry> + </variablelist> + </refsect1> + + <refsect1> + <title>Description</title> + + <para>To query the current access priority +applications call the <constant>VIDIOC_G_PRIORITY</constant> ioctl +with a pointer to an enum v4l2_priority variable where the driver stores +the current priority.</para> + + <para>To request an access priority applications store the +desired priority in an enum v4l2_priority variable and call +<constant>VIDIOC_S_PRIORITY</constant> ioctl with a pointer to this +variable.</para> + + <table frame="none" pgwide="1" id="v4l2-priority"> + <title>enum v4l2_priority</title> + <tgroup cols="3"> + &cs-def; + <tbody valign="top"> + <row> + <entry><constant>V4L2_PRIORITY_UNSET</constant></entry> + <entry>0</entry> + <entry></entry> + </row> + <row> + <entry><constant>V4L2_PRIORITY_BACKGROUND</constant></entry> + <entry>1</entry> + <entry>Lowest priority, usually applications running in +background, for example monitoring VBI transmissions. A proxy +application running in user space will be necessary if multiple +applications want to read from a device at this priority.</entry> + </row> + <row> + <entry><constant>V4L2_PRIORITY_INTERACTIVE</constant></entry> + <entry>2</entry> + <entry></entry> + </row> + <row> + <entry><constant>V4L2_PRIORITY_DEFAULT</constant></entry> + <entry>2</entry> + <entry>Medium priority, usually applications started and +interactively controlled by the user. For example TV viewers, Teletext +browsers, or just "panel" applications to change the channel or video +controls. This is the default priority unless an application requests +another.</entry> + </row> + <row> + <entry><constant>V4L2_PRIORITY_RECORD</constant></entry> + <entry>3</entry> + <entry>Highest priority. Only one file descriptor can have +this priority, it blocks any other fd from changing device properties. +Usually applications which must not be interrupted, like video +recording.</entry> + </row> + </tbody> + </tgroup> + </table> + </refsect1> + + <refsect1> + &return-value; + + <variablelist> + <varlistentry> + <term><errorcode>EINVAL</errorcode></term> + <listitem> + <para>The requested priority value is invalid, or the +driver does not support access priorities.</para> + </listitem> + </varlistentry> + <varlistentry> + <term><errorcode>EBUSY</errorcode></term> + <listitem> + <para>Another application already requested higher +priority.</para> + </listitem> + </varlistentry> + </variablelist> + </refsect1> +</refentry> + +<!-- +Local Variables: +mode: sgml +sgml-parent-document: "v4l2.sgml" +indent-tabs-mode: nil +End: +--> diff --git a/Documentation/DocBook/v4l/vidioc-g-sliced-vbi-cap.xml b/Documentation/DocBook/v4l/vidioc-g-sliced-vbi-cap.xml new file mode 100644 index 000000000000..10e721b17374 --- /dev/null +++ b/Documentation/DocBook/v4l/vidioc-g-sliced-vbi-cap.xml @@ -0,0 +1,264 @@ +<refentry id="vidioc-g-sliced-vbi-cap"> + <refmeta> + <refentrytitle>ioctl VIDIOC_G_SLICED_VBI_CAP</refentrytitle> + &manvol; + </refmeta> + + <refnamediv> + <refname>VIDIOC_G_SLICED_VBI_CAP</refname> + <refpurpose>Query sliced VBI capabilities</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_sliced_vbi_cap *<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_G_SLICED_VBI_CAP</para> + </listitem> + </varlistentry> + <varlistentry> + <term><parameter>argp</parameter></term> + <listitem> + <para></para> + </listitem> + </varlistentry> + </variablelist> + </refsect1> + + <refsect1> + <title>Description</title> + + <para>To find out which data services are supported by a sliced +VBI capture or output device, applications initialize the +<structfield>type</structfield> field of a &v4l2-sliced-vbi-cap;, +clear the <structfield>reserved</structfield> array and +call the <constant>VIDIOC_G_SLICED_VBI_CAP</constant> ioctl. The +driver fills in the remaining fields or returns an &EINVAL; if the +sliced VBI API is unsupported or <structfield>type</structfield> +is invalid.</para> + + <para>Note the <structfield>type</structfield> field was added, +and the ioctl changed from read-only to write-read, in Linux 2.6.19.</para> + + <table pgwide="1" frame="none" id="v4l2-sliced-vbi-cap"> + <title>struct <structname>v4l2_sliced_vbi_cap</structname></title> + <tgroup cols="5"> + <colspec colname="c1" colwidth="3*" /> + <colspec colname="c2" colwidth="3*" /> + <colspec colname="c3" colwidth="2*" /> + <colspec colname="c4" colwidth="2*" /> + <colspec colname="c5" colwidth="2*" /> + <spanspec spanname="hspan" namest="c3" nameend="c5" /> + <tbody valign="top"> + <row> + <entry>__u16</entry> + <entry><structfield>service_set</structfield></entry> + <entry spanname="hspan">A set of all data services +supported by the driver. Equal to the union of all elements of the +<structfield>service_lines </structfield> array.</entry> + </row> + <row> + <entry>__u16</entry> + <entry><structfield>service_lines</structfield>[2][24]</entry> + <entry spanname="hspan">Each element of this array +contains a set of data services the hardware can look for or insert +into a particular scan line. Data services are defined in <xref + linkend="vbi-services" />. Array indices map to ITU-R +line numbers (see also <xref + linkend="vbi-525" /> and <xref +linkend="vbi-625" />) as follows:</entry> + </row> + <row> + <entry></entry> + <entry></entry> + <entry>Element</entry> + <entry>525 line systems</entry> + <entry>625 line systems</entry> + </row> + <row> + <entry></entry> + <entry></entry> + <entry><structfield>service_lines</structfield>[0][1]</entry> + <entry align="center">1</entry> + <entry align="center">1</entry> + </row> + <row> + <entry></entry> + <entry></entry> + <entry><structfield>service_lines</structfield>[0][23]</entry> + <entry align="center">23</entry> + <entry align="center">23</entry> + </row> + <row> + <entry></entry> + <entry></entry> + <entry><structfield>service_lines</structfield>[1][1]</entry> + <entry align="center">264</entry> + <entry align="center">314</entry> + </row> + <row> + <entry></entry> + <entry></entry> + <entry><structfield>service_lines</structfield>[1][23]</entry> + <entry align="center">286</entry> + <entry align="center">336</entry> + </row> + <row> + <entry></entry> + </row> + <row> + <entry></entry> + <entry></entry> + <entry spanname="hspan">The number of VBI lines the +hardware can capture or output per frame, or the number of services it +can identify on a given line may be limited. For example on PAL line +16 the hardware may be able to look for a VPS or Teletext signal, but +not both at the same time. Applications can learn about these limits +using the &VIDIOC-S-FMT; ioctl as described in <xref + linkend="sliced" />.</entry> + </row> + <row> + <entry></entry> + </row> + <row> + <entry></entry> + <entry></entry> + <entry spanname="hspan">Drivers must set +<structfield>service_lines</structfield>[0][0] and +<structfield>service_lines</structfield>[1][0] to zero.</entry> + </row> + <row> + <entry>&v4l2-buf-type;</entry> + <entry><structfield>type</structfield></entry> + <entry>Type of the data stream, see <xref + linkend="v4l2-buf-type" />. Should be +<constant>V4L2_BUF_TYPE_SLICED_VBI_CAPTURE</constant> or +<constant>V4L2_BUF_TYPE_SLICED_VBI_OUTPUT</constant>.</entry> + </row> + <row> + <entry>__u32</entry> + <entry><structfield>reserved</structfield>[3]</entry> + <entry spanname="hspan">This array is reserved for future +extensions. Applications and drivers must set it to zero.</entry> + </row> + </tbody> + </tgroup> + </table> + + <!-- See also dev-sliced-vbi.sgml --> + <table pgwide="1" frame="none" id="vbi-services"> + <title>Sliced VBI services</title> + <tgroup cols="5"> + <colspec colname="c1" colwidth="2*" /> + <colspec colname="c2" colwidth="1*" /> + <colspec colname="c3" colwidth="1*" /> + <colspec colname="c4" colwidth="2*" /> + <colspec colname="c5" colwidth="2*" /> + <spanspec spanname='rlp' namest='c3' nameend='c5' /> + <thead> + <row> + <entry>Symbol</entry> + <entry>Value</entry> + <entry>Reference</entry> + <entry>Lines, usually</entry> + <entry>Payload</entry> + </row> + </thead> + <tbody valign="top"> + <row> + <entry><constant>V4L2_SLICED_TELETEXT_B</constant> (Teletext +System B)</entry> + <entry>0x0001</entry> + <entry><xref linkend="ets300706" />, <xref linkend="itu653" /></entry> + <entry>PAL/SECAM line 7-22, 320-335 (second field 7-22)</entry> + <entry>Last 42 of the 45 byte Teletext packet, that is +without clock run-in and framing code, lsb first transmitted.</entry> + </row> + <row> + <entry><constant>V4L2_SLICED_VPS</constant></entry> + <entry>0x0400</entry> + <entry><xref linkend="ets300231" /></entry> + <entry>PAL line 16</entry> + <entry>Byte number 3 to 15 according to Figure 9 of +ETS 300 231, lsb first transmitted.</entry> + </row> + <row> + <entry><constant>V4L2_SLICED_CAPTION_525</constant></entry> + <entry>0x1000</entry> + <entry><xref linkend="eia608" /></entry> + <entry>NTSC line 21, 284 (second field 21)</entry> + <entry>Two bytes in transmission order, including parity +bit, lsb first transmitted.</entry> + </row> + <row> + <entry><constant>V4L2_SLICED_WSS_625</constant></entry> + <entry>0x4000</entry> + <entry><xref linkend="en300294" />, <xref linkend="itu1119" /></entry> + <entry>PAL/SECAM line 23</entry> + <entry><screen> +Byte 0 1 + msb lsb msb lsb +Bit 7 6 5 4 3 2 1 0 x x 13 12 11 10 9 +</screen></entry> + </row> + <row> + <entry><constant>V4L2_SLICED_VBI_525</constant></entry> + <entry>0x1000</entry> + <entry spanname="rlp">Set of services applicable to 525 +line systems.</entry> + </row> + <row> + <entry><constant>V4L2_SLICED_VBI_625</constant></entry> + <entry>0x4401</entry> + <entry spanname="rlp">Set of services applicable to 625 +line systems.</entry> + </row> + </tbody> + </tgroup> + </table> + + </refsect1> + + <refsect1> + &return-value; + + <variablelist> + <varlistentry> + <term><errorcode>EINVAL</errorcode></term> + <listitem> + <para>The device does not support sliced VBI capturing or +output, or the value in the <structfield>type</structfield> field is +wrong.</para> + </listitem> + </varlistentry> + </variablelist> + </refsect1> +</refentry> + +<!-- +Local Variables: +mode: sgml +sgml-parent-document: "v4l2.sgml" +indent-tabs-mode: nil +End: +--> diff --git a/Documentation/DocBook/v4l/vidioc-g-std.xml b/Documentation/DocBook/v4l/vidioc-g-std.xml new file mode 100644 index 000000000000..912f8513e5da --- /dev/null +++ b/Documentation/DocBook/v4l/vidioc-g-std.xml @@ -0,0 +1,105 @@ +<refentry id="vidioc-g-std"> + <refmeta> + <refentrytitle>ioctl VIDIOC_G_STD, VIDIOC_S_STD</refentrytitle> + &manvol; + </refmeta> + + <refnamediv> + <refname>VIDIOC_G_STD</refname> + <refname>VIDIOC_S_STD</refname> + <refpurpose>Query or select the video standard of the current input</refpurpose> + </refnamediv> + + <refsynopsisdiv> + <funcsynopsis> + <funcprototype> + <funcdef>int <function>ioctl</function></funcdef> + <paramdef>int <parameter>fd</parameter></paramdef> + <paramdef>int <parameter>request</parameter></paramdef> + <paramdef>v4l2_std_id +*<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 v4l2_std_id +*<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_G_STD, VIDIOC_S_STD</para> + </listitem> + </varlistentry> + <varlistentry> + <term><parameter>argp</parameter></term> + <listitem> + <para></para> + </listitem> + </varlistentry> + </variablelist> + </refsect1> + + <refsect1> + <title>Description</title> + + <para>To query and select the current video standard applications +use the <constant>VIDIOC_G_STD</constant> and <constant>VIDIOC_S_STD</constant> ioctls which take a pointer to a +&v4l2-std-id; type as argument. <constant>VIDIOC_G_STD</constant> can +return a single flag or a set of flags as in &v4l2-standard; field +<structfield>id</structfield>. The flags must be unambiguous such +that they appear in only one enumerated <structname>v4l2_standard</structname> structure.</para> + + <para><constant>VIDIOC_S_STD</constant> accepts one or more +flags, being a write-only ioctl it does not return the actual new standard as +<constant>VIDIOC_G_STD</constant> does. When no flags are given or +the current input does not support the requested standard the driver +returns an &EINVAL;. When the standard set is ambiguous drivers may +return <errorcode>EINVAL</errorcode> or choose any of the requested +standards.</para> + </refsect1> + + <refsect1> + &return-value; + + <variablelist> + <varlistentry> + <term><errorcode>EINVAL</errorcode></term> + <listitem> + <para>This ioctl is not supported, or the +<constant>VIDIOC_S_STD</constant> parameter was unsuitable.</para> + </listitem> + </varlistentry> + <varlistentry> + <term><errorcode>EBUSY</errorcode></term> + <listitem> + <para>The device is busy and therefore can not change the standard</para> + </listitem> + </varlistentry> + </variablelist> + </refsect1> +</refentry> + +<!-- +Local Variables: +mode: sgml +sgml-parent-document: "v4l2.sgml" +indent-tabs-mode: nil +End: +--> diff --git a/Documentation/DocBook/v4l/vidioc-g-tuner.xml b/Documentation/DocBook/v4l/vidioc-g-tuner.xml new file mode 100644 index 000000000000..bd98c734c06b --- /dev/null +++ b/Documentation/DocBook/v4l/vidioc-g-tuner.xml @@ -0,0 +1,535 @@ +<refentry id="vidioc-g-tuner"> + <refmeta> + <refentrytitle>ioctl VIDIOC_G_TUNER, VIDIOC_S_TUNER</refentrytitle> + &manvol; + </refmeta> + + <refnamediv> + <refname>VIDIOC_G_TUNER</refname> + <refname>VIDIOC_S_TUNER</refname> + <refpurpose>Get or set tuner attributes</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_tuner +*<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_tuner +*<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_G_TUNER, VIDIOC_S_TUNER</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 a tuner applications initialize the +<structfield>index</structfield> field and zero out the +<structfield>reserved</structfield> array of a &v4l2-tuner; and call the +<constant>VIDIOC_G_TUNER</constant> ioctl with a pointer to this +structure. Drivers fill the rest of the structure or return an +&EINVAL; when the index is out of bounds. To enumerate all tuners +applications shall begin at index zero, incrementing by one until the +driver returns <errorcode>EINVAL</errorcode>.</para> + + <para>Tuners have two writable properties, the audio mode and +the radio frequency. To change the audio mode, applications initialize +the <structfield>index</structfield>, +<structfield>audmode</structfield> and +<structfield>reserved</structfield> fields and call the +<constant>VIDIOC_S_TUNER</constant> ioctl. This will +<emphasis>not</emphasis> change the current tuner, which is determined +by the current video input. Drivers may choose a different audio mode +if the requested mode is invalid or unsupported. Since this is a +<!-- FIXME -->write-only ioctl, it does not return the actually +selected audio mode.</para> + + <para>To change the radio frequency the &VIDIOC-S-FREQUENCY; ioctl +is available.</para> + + <table pgwide="1" frame="none" id="v4l2-tuner"> + <title>struct <structname>v4l2_tuner</structname></title> + <tgroup cols="3"> + <colspec colname="c1" colwidth="1*" /> + <colspec colname="c2" colwidth="1*" /> + <colspec colname="c3" colwidth="1*" /> + <colspec colname="c4" colwidth="1*" /> + <spanspec spanname="hspan" namest="c3" nameend="c4" /> + <tbody valign="top"> + <row> + <entry>__u32</entry> + <entry><structfield>index</structfield></entry> + <entry spanname="hspan">Identifies the tuner, set by the +application.</entry> + </row> + <row> + <entry>__u8</entry> + <entry><structfield>name</structfield>[32]</entry> + <entry spanname="hspan"><para>Name of the tuner, a +NUL-terminated ASCII string. This information is intended for the +user.<!-- FIXME Video inputs already have a name, the purpose of this +field is not quite clear.--></para></entry> + </row> + <row> + <entry>&v4l2-tuner-type;</entry> + <entry><structfield>type</structfield></entry> + <entry spanname="hspan">Type of the tuner, see <xref + linkend="v4l2-tuner-type" />.</entry> + </row> + <row> + <entry>__u32</entry> + <entry><structfield>capability</structfield></entry> + <entry spanname="hspan"><para>Tuner capability flags, see +<xref linkend="tuner-capability" />. Audio flags indicate the ability +to decode audio subprograms. They will <emphasis>not</emphasis> +change, for example with the current video standard.</para><para>When +the structure refers to a radio tuner only the +<constant>V4L2_TUNER_CAP_LOW</constant>, +<constant>V4L2_TUNER_CAP_STEREO</constant> and +<constant>V4L2_TUNER_CAP_RDS</constant> flags can be set.</para></entry> + </row> + <row> + <entry>__u32</entry> + <entry><structfield>rangelow</structfield></entry> + <entry spanname="hspan">The lowest tunable frequency in +units of 62.5 kHz, or if the <structfield>capability</structfield> +flag <constant>V4L2_TUNER_CAP_LOW</constant> is set, in units of 62.5 +Hz.</entry> + </row> + <row> + <entry>__u32</entry> + <entry><structfield>rangehigh</structfield></entry> + <entry spanname="hspan">The highest tunable frequency in +units of 62.5 kHz, or if the <structfield>capability</structfield> +flag <constant>V4L2_TUNER_CAP_LOW</constant> is set, in units of 62.5 +Hz.</entry> + </row> + <row> + <entry>__u32</entry> + <entry><structfield>rxsubchans</structfield></entry> + <entry spanname="hspan"><para>Some tuners or audio +decoders can determine the received audio subprograms by analyzing +audio carriers, pilot tones or other indicators. To pass this +information drivers set flags defined in <xref + linkend="tuner-rxsubchans" /> in this field. For +example:</para></entry> + </row> + <row> + <entry></entry> + <entry></entry> + <entry><constant>V4L2_TUNER_SUB_MONO</constant></entry> + <entry>receiving mono audio</entry> + </row> + <row> + <entry></entry> + <entry></entry> + <entry><constant>STEREO | SAP</constant></entry> + <entry>receiving stereo audio and a secondary audio +program</entry> + </row> + <row> + <entry></entry> + <entry></entry> + <entry><constant>MONO | STEREO</constant></entry> + <entry>receiving mono or stereo audio, the hardware cannot +distinguish</entry> + </row> + <row> + <entry></entry> + <entry></entry> + <entry><constant>LANG1 | LANG2</constant></entry> + <entry>receiving bilingual audio</entry> + </row> + <row> + <entry></entry> + <entry></entry> + <entry><constant>MONO | STEREO | LANG1 | LANG2</constant></entry> + <entry>receiving mono, stereo or bilingual +audio</entry> + </row> + <row> + <entry></entry> + <entry></entry> + <entry spanname="hspan"><para>When the +<constant>V4L2_TUNER_CAP_STEREO</constant>, +<constant>_LANG1</constant>, <constant>_LANG2</constant> or +<constant>_SAP</constant> flag is cleared in the +<structfield>capability</structfield> field, the corresponding +<constant>V4L2_TUNER_SUB_</constant> flag must not be set +here.</para><para>This field is valid only if this is the tuner of the +current video input, or when the structure refers to a radio +tuner.</para></entry> + </row> + <row> + <entry>__u32</entry> + <entry><structfield>audmode</structfield></entry> + <entry spanname="hspan"><para>The selected audio mode, see +<xref linkend="tuner-audmode" /> for valid values. The audio mode does +not affect audio subprogram detection, and like a <link +linkend="control">control</link> it does not automatically change +unless the requested mode is invalid or unsupported. See <xref + linkend="tuner-matrix" /> for possible results when +the selected and received audio programs do not +match.</para><para>Currently this is the only field of struct +<structname>v4l2_tuner</structname> applications can +change.</para></entry> + </row> + <row> + <entry>__u32</entry> + <entry><structfield>signal</structfield></entry> + <entry spanname="hspan">The signal strength if known, ranging +from 0 to 65535. Higher values indicate a better signal.</entry> + </row> + <row> + <entry>__s32</entry> + <entry><structfield>afc</structfield></entry> + <entry spanname="hspan">Automatic frequency control: When the +<structfield>afc</structfield> value is negative, the frequency is too +low, when positive too high.<!-- FIXME need example what to do when it never +settles at zero, &ie; range is what? --></entry> + </row> + <row> + <entry>__u32</entry> + <entry><structfield>reserved</structfield>[4]</entry> + <entry spanname="hspan">Reserved for future extensions. Drivers and +applications must set the array to zero.</entry> + </row> + </tbody> + </tgroup> + </table> + + <table pgwide="1" frame="none" id="v4l2-tuner-type"> + <title>enum v4l2_tuner_type</title> + <tgroup cols="3"> + &cs-def; + <tbody valign="top"> + <row> + <entry><constant>V4L2_TUNER_RADIO</constant></entry> + <entry>1</entry> + <entry></entry> + </row> + <row> + <entry><constant>V4L2_TUNER_ANALOG_TV</constant></entry> + <entry>2</entry> + <entry></entry> + </row> + </tbody> + </tgroup> + </table> + + <table pgwide="1" frame="none" id="tuner-capability"> + <title>Tuner and Modulator Capability Flags</title> + <tgroup cols="3"> + &cs-def; + <tbody valign="top"> + <row> + <entry><constant>V4L2_TUNER_CAP_LOW</constant></entry> + <entry>0x0001</entry> + <entry>When set, tuning frequencies are expressed in units of +62.5 Hz, otherwise in units of 62.5 kHz.</entry> + </row> + <row> + <entry><constant>V4L2_TUNER_CAP_NORM</constant></entry> + <entry>0x0002</entry> + <entry>This is a multi-standard tuner; the video standard +can or must be switched. (B/G PAL tuners for example are typically not + considered multi-standard because the video standard is automatically + determined from the frequency band.) The set of supported video + standards is available from the &v4l2-input; pointing to this tuner, + see the description of ioctl &VIDIOC-ENUMINPUT; for details. Only + <constant>V4L2_TUNER_ANALOG_TV</constant> tuners can have this capability.</entry> + </row> + <row> + <entry><constant>V4L2_TUNER_CAP_STEREO</constant></entry> + <entry>0x0010</entry> + <entry>Stereo audio reception is supported.</entry> + </row> + <row> + <entry><constant>V4L2_TUNER_CAP_LANG1</constant></entry> + <entry>0x0040</entry> + <entry>Reception of the primary language of a bilingual +audio program is supported. Bilingual audio is a feature of +two-channel systems, transmitting the primary language monaural on the +main audio carrier and a secondary language monaural on a second +carrier. Only + <constant>V4L2_TUNER_ANALOG_TV</constant> tuners can have this capability.</entry> + </row> + <row> + <entry><constant>V4L2_TUNER_CAP_LANG2</constant></entry> + <entry>0x0020</entry> + <entry>Reception of the secondary language of a bilingual +audio program is supported. Only + <constant>V4L2_TUNER_ANALOG_TV</constant> tuners can have this capability.</entry> + </row> + <row> + <entry><constant>V4L2_TUNER_CAP_SAP</constant></entry> + <entry>0x0020</entry> + <entry><para>Reception of a secondary audio program is +supported. This is a feature of the BTSC system which accompanies the +NTSC video standard. Two audio carriers are available for mono or +stereo transmissions of a primary language, and an independent third +carrier for a monaural secondary language. Only + <constant>V4L2_TUNER_ANALOG_TV</constant> tuners can have this capability.</para><para>Note the +<constant>V4L2_TUNER_CAP_LANG2</constant> and +<constant>V4L2_TUNER_CAP_SAP</constant> flags are synonyms. +<constant>V4L2_TUNER_CAP_SAP</constant> applies when the tuner +supports the <constant>V4L2_STD_NTSC_M</constant> video +standard.</para><!-- FIXME what if PAL+NTSC and Bi but not SAP? --></entry> + </row> + <row> + <entry><constant>V4L2_TUNER_CAP_RDS</constant></entry> + <entry>0x0080</entry> + <entry>RDS capture is supported. This capability is only valid for +radio tuners.</entry> + </row> + </tbody> + </tgroup> + </table> + + <table pgwide="1" frame="none" id="tuner-rxsubchans"> + <title>Tuner Audio Reception Flags</title> + <tgroup cols="3"> + &cs-def; + <tbody valign="top"> + <row> + <entry><constant>V4L2_TUNER_SUB_MONO</constant></entry> + <entry>0x0001</entry> + <entry>The tuner receives a mono audio signal.</entry> + </row> + <row> + <entry><constant>V4L2_TUNER_SUB_STEREO</constant></entry> + <entry>0x0002</entry> + <entry>The tuner receives a stereo audio signal.</entry> + </row> + <row> + <entry><constant>V4L2_TUNER_SUB_LANG1</constant></entry> + <entry>0x0008</entry> + <entry>The tuner receives the primary language of a +bilingual audio signal. Drivers must clear this flag when the current +video standard is <constant>V4L2_STD_NTSC_M</constant>.</entry> + </row> + <row> + <entry><constant>V4L2_TUNER_SUB_LANG2</constant></entry> + <entry>0x0004</entry> + <entry>The tuner receives the secondary language of a +bilingual audio signal (or a second audio program).</entry> + </row> + <row> + <entry><constant>V4L2_TUNER_SUB_SAP</constant></entry> + <entry>0x0004</entry> + <entry>The tuner receives a Second Audio Program. Note the +<constant>V4L2_TUNER_SUB_LANG2</constant> and +<constant>V4L2_TUNER_SUB_SAP</constant> flags are synonyms. The +<constant>V4L2_TUNER_SUB_SAP</constant> flag applies when the +current video standard is <constant>V4L2_STD_NTSC_M</constant>.</entry> + </row> + <row> + <entry><constant>V4L2_TUNER_SUB_RDS</constant></entry> + <entry>0x0010</entry> + <entry>The tuner receives an RDS channel.</entry> + </row> + </tbody> + </tgroup> + </table> + + <table pgwide="1" frame="none" id="tuner-audmode"> + <title>Tuner Audio Modes</title> + <tgroup cols="3"> + &cs-def; + <tbody valign="top"> + <row> + <entry><constant>V4L2_TUNER_MODE_MONO</constant></entry> + <entry>0</entry> + <entry>Play mono audio. When the tuner receives a stereo +signal this a down-mix of the left and right channel. When the tuner +receives a bilingual or SAP signal this mode selects the primary +language.</entry> + </row> + <row> + <entry><constant>V4L2_TUNER_MODE_STEREO</constant></entry> + <entry>1</entry> + <entry><para>Play stereo audio. When the tuner receives +bilingual audio it may play different languages on the left and right +channel or the primary language is played on both channels.</para><para>Playing +different languages in this mode is +deprecated. New drivers should do this only in +<constant>MODE_LANG1_LANG2</constant>.</para><para>When the tuner +receives no stereo signal or does not support stereo reception the +driver shall fall back to <constant>MODE_MONO</constant>.</para></entry> + </row> + <row> + <entry><constant>V4L2_TUNER_MODE_LANG1</constant></entry> + <entry>3</entry> + <entry>Play the primary language, mono or stereo. Only +<constant>V4L2_TUNER_ANALOG_TV</constant> tuners support this +mode.</entry> + </row> + <row> + <entry><constant>V4L2_TUNER_MODE_LANG2</constant></entry> + <entry>2</entry> + <entry>Play the secondary language, mono. When the tuner +receives no bilingual audio or SAP, or their reception is not +supported the driver shall fall back to mono or stereo mode. Only +<constant>V4L2_TUNER_ANALOG_TV</constant> tuners support this +mode.</entry> + </row> + <row> + <entry><constant>V4L2_TUNER_MODE_SAP</constant></entry> + <entry>2</entry> + <entry>Play the Second Audio Program. When the tuner +receives no bilingual audio or SAP, or their reception is not +supported the driver shall fall back to mono or stereo mode. Only +<constant>V4L2_TUNER_ANALOG_TV</constant> tuners support this mode. +Note the <constant>V4L2_TUNER_MODE_LANG2</constant> and +<constant>V4L2_TUNER_MODE_SAP</constant> are synonyms.</entry> + </row> + <row> + <entry><constant>V4L2_TUNER_MODE_LANG1_LANG2</constant></entry> + <entry>4</entry> + <entry>Play the primary language on the left channel, the +secondary language on the right channel. When the tuner receives no +bilingual audio or SAP, it shall fall back to +<constant>MODE_LANG1</constant> or <constant>MODE_MONO</constant>. +Only <constant>V4L2_TUNER_ANALOG_TV</constant> tuners support this +mode.</entry> + </row> + </tbody> + </tgroup> + </table> + + <table pgwide="1" frame="all" id="tuner-matrix"> + <title>Tuner Audio Matrix</title> + <tgroup cols="6" align="center"> + <colspec align="left" /> + <colspec colname="c2" colwidth="1*" /> + <colspec colwidth="1*" /> + <colspec colwidth="1*" /> + <colspec colnum="6" colname="c6" colwidth="1*" /> + <spanspec namest="c2" nameend="c6" spanname="hspan" align="center" /> + <thead> + <row> + <entry></entry> + <entry spanname="hspan">Selected +<constant>V4L2_TUNER_MODE_</constant></entry> + </row> + <row> + <entry>Received <constant>V4L2_TUNER_SUB_</constant></entry> + <entry><constant>MONO</constant></entry> + <entry><constant>STEREO</constant></entry> + <entry><constant>LANG1</constant></entry> + <entry><constant>LANG2 = SAP</constant></entry> + <entry><constant>LANG1_LANG2</constant><footnote><para>This +mode has been added in Linux 2.6.17 and may not be supported by older +drivers.</para></footnote></entry> + </row> + </thead> + <tbody valign="top"> + <row> + <entry><constant>MONO</constant></entry> + <entry>Mono</entry> + <entry>Mono/Mono</entry> + <entry>Mono</entry> + <entry>Mono</entry> + <entry>Mono/Mono</entry> + </row> + <row> + <entry><constant>MONO | SAP</constant></entry> + <entry>Mono</entry> + <entry>Mono/Mono</entry> + <entry>Mono</entry> + <entry>SAP</entry> + <entry>Mono/SAP (preferred) or Mono/Mono</entry> + </row> + <row> + <entry><constant>STEREO</constant></entry> + <entry>L+R</entry> + <entry>L/R</entry> + <entry>Stereo L/R (preferred) or Mono L+R</entry> + <entry>Stereo L/R (preferred) or Mono L+R</entry> + <entry>L/R (preferred) or L+R/L+R</entry> + </row> + <row> + <entry><constant>STEREO | SAP</constant></entry> + <entry>L+R</entry> + <entry>L/R</entry> + <entry>Stereo L/R (preferred) or Mono L+R</entry> + <entry>SAP</entry> + <entry>L+R/SAP (preferred) or L/R or L+R/L+R</entry> + </row> + <row> + <entry><constant>LANG1 | LANG2</constant></entry> + <entry>Language 1</entry> + <entry>Lang1/Lang2 (deprecated<footnote><para>Playback of +both languages in <constant>MODE_STEREO</constant> is deprecated. In +the future drivers should produce only the primary language in this +mode. Applications should request +<constant>MODE_LANG1_LANG2</constant> to record both languages or a +stereo signal.</para></footnote>) or +Lang1/Lang1</entry> + <entry>Language 1</entry> + <entry>Language 2</entry> + <entry>Lang1/Lang2 (preferred) or Lang1/Lang1</entry> + </row> + </tbody> + </tgroup> + </table> + </refsect1> + + <refsect1> + &return-value; + + <variablelist> + <varlistentry> + <term><errorcode>EINVAL</errorcode></term> + <listitem> + <para>The &v4l2-tuner; <structfield>index</structfield> is +out of bounds.</para> + </listitem> + </varlistentry> + </variablelist> + </refsect1> +</refentry> + +<!-- +Local Variables: +mode: sgml +sgml-parent-document: "v4l2.sgml" +indent-tabs-mode: nil +End: +--> diff --git a/Documentation/DocBook/v4l/vidioc-log-status.xml b/Documentation/DocBook/v4l/vidioc-log-status.xml new file mode 100644 index 000000000000..2634b7c88b58 --- /dev/null +++ b/Documentation/DocBook/v4l/vidioc-log-status.xml @@ -0,0 +1,58 @@ +<refentry id="vidioc-log-status"> + <refmeta> + <refentrytitle>ioctl VIDIOC_LOG_STATUS</refentrytitle> + &manvol; + </refmeta> + + <refnamediv> + <refname>VIDIOC_LOG_STATUS</refname> + <refpurpose>Log driver status information</refpurpose> + </refnamediv> + + <refsynopsisdiv> + <funcsynopsis> + <funcprototype> + <funcdef>int <function>ioctl</function></funcdef> + <paramdef>int <parameter>fd</parameter></paramdef> + <paramdef>int <parameter>request</parameter></paramdef> + </funcprototype> + </funcsynopsis> + </refsynopsisdiv> + + <refsect1> + <title>Description</title> + + <para>As the video/audio devices become more complicated it +becomes harder to debug problems. When this ioctl is called the driver +will output the current device status to the kernel log. This is +particular useful when dealing with problems like no sound, no video +and incorrectly tuned channels. Also many modern devices autodetect +video and audio standards and this ioctl will report what the device +thinks what the standard is. Mismatches may give an indication where +the problem is.</para> + + <para>This ioctl is optional and not all drivers support it. It +was introduced in Linux 2.6.15.</para> + </refsect1> + + <refsect1> + &return-value; + + <variablelist> + <varlistentry> + <term><errorcode>EINVAL</errorcode></term> + <listitem> + <para>The driver does not support this ioctl.</para> + </listitem> + </varlistentry> + </variablelist> + </refsect1> +</refentry> + +<!-- +Local Variables: +mode: sgml +sgml-parent-document: "v4l2.sgml" +indent-tabs-mode: nil +End: +--> diff --git a/Documentation/DocBook/v4l/vidioc-overlay.xml b/Documentation/DocBook/v4l/vidioc-overlay.xml new file mode 100644 index 000000000000..1036c582cc15 --- /dev/null +++ b/Documentation/DocBook/v4l/vidioc-overlay.xml @@ -0,0 +1,83 @@ +<refentry id="vidioc-overlay"> + <refmeta> + <refentrytitle>ioctl VIDIOC_OVERLAY</refentrytitle> + &manvol; + </refmeta> + + <refnamediv> + <refname>VIDIOC_OVERLAY</refname> + <refpurpose>Start or stop video overlay</refpurpose> + </refnamediv> + + <refsynopsisdiv> + <funcsynopsis> + <funcprototype> + <funcdef>int <function>ioctl</function></funcdef> + <paramdef>int <parameter>fd</parameter></paramdef> + <paramdef>int <parameter>request</parameter></paramdef> + <paramdef>const int *<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_OVERLAY</para> + </listitem> + </varlistentry> + <varlistentry> + <term><parameter>argp</parameter></term> + <listitem> + <para></para> + </listitem> + </varlistentry> + </variablelist> + </refsect1> + + <refsect1> + <title>Description</title> + + <para>This ioctl is part of the <link linkend="overlay">video + overlay</link> I/O method. Applications call + <constant>VIDIOC_OVERLAY</constant> to start or stop the + overlay. It takes a pointer to an integer which must be set to + zero by the application to stop overlay, to one to start.</para> + + <para>Drivers do not support &VIDIOC-STREAMON; or +&VIDIOC-STREAMOFF; with <constant>V4L2_BUF_TYPE_VIDEO_OVERLAY</constant>.</para> + </refsect1> + + <refsect1> + &return-value; + + <variablelist> + <varlistentry> + <term><errorcode>EINVAL</errorcode></term> + <listitem> + <para>Video overlay is not supported, or the +parameters have not been set up. See <xref +linkend="overlay" /> for the necessary steps.</para> + </listitem> + </varlistentry> + </variablelist> + </refsect1> +</refentry> + +<!-- +Local Variables: +mode: sgml +sgml-parent-document: "v4l2.sgml" +indent-tabs-mode: nil +End: +--> diff --git a/Documentation/DocBook/v4l/vidioc-qbuf.xml b/Documentation/DocBook/v4l/vidioc-qbuf.xml new file mode 100644 index 000000000000..187081778154 --- /dev/null +++ b/Documentation/DocBook/v4l/vidioc-qbuf.xml @@ -0,0 +1,168 @@ +<refentry id="vidioc-qbuf"> + <refmeta> + <refentrytitle>ioctl VIDIOC_QBUF, VIDIOC_DQBUF</refentrytitle> + &manvol; + </refmeta> + + <refnamediv> + <refname>VIDIOC_QBUF</refname> + <refname>VIDIOC_DQBUF</refname> + <refpurpose>Exchange a buffer with the driver</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_buffer *<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_QBUF, VIDIOC_DQBUF</para> + </listitem> + </varlistentry> + <varlistentry> + <term><parameter>argp</parameter></term> + <listitem> + <para></para> + </listitem> + </varlistentry> + </variablelist> + </refsect1> + + <refsect1> + <title>Description</title> + + <para>Applications call the <constant>VIDIOC_QBUF</constant> ioctl +to enqueue an empty (capturing) or filled (output) buffer in the +driver's incoming queue. The semantics depend on the selected I/O +method.</para> + + <para>To enqueue a <link linkend="mmap">memory mapped</link> +buffer applications set the <structfield>type</structfield> field of a +&v4l2-buffer; to the same buffer type as previously &v4l2-format; +<structfield>type</structfield> and &v4l2-requestbuffers; +<structfield>type</structfield>, the <structfield>memory</structfield> +field to <constant>V4L2_MEMORY_MMAP</constant> and the +<structfield>index</structfield> field. Valid index numbers range from +zero to the number of buffers allocated with &VIDIOC-REQBUFS; +(&v4l2-requestbuffers; <structfield>count</structfield>) minus one. The +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_VBI_OUTPUT</constant>) applications must also +initialize the <structfield>bytesused</structfield>, +<structfield>field</structfield> and +<structfield>timestamp</structfield> fields. See <xref + linkend="buffer" /> for details. When +<constant>VIDIOC_QBUF</constant> is called with a pointer to this +structure the driver sets the +<constant>V4L2_BUF_FLAG_MAPPED</constant> and +<constant>V4L2_BUF_FLAG_QUEUED</constant> flags and clears the +<constant>V4L2_BUF_FLAG_DONE</constant> flag in the +<structfield>flags</structfield> field, or it returns an +&EINVAL;.</para> + + <para>To enqueue a <link linkend="userp">user pointer</link> +buffer applications set the <structfield>type</structfield> field of a +&v4l2-buffer; to the same buffer type as previously &v4l2-format; +<structfield>type</structfield> and &v4l2-requestbuffers; +<structfield>type</structfield>, the <structfield>memory</structfield> +field to <constant>V4L2_MEMORY_USERPTR</constant> and the +<structfield>m.userptr</structfield> field to the address of the +buffer and <structfield>length</structfield> to its size. When the +buffer is intended for output additional fields must be set as above. +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, +they cannot be swapped out to disk. Buffers remain locked until +dequeued, until the &VIDIOC-STREAMOFF; or &VIDIOC-REQBUFS; ioctl are +called, or until the device is closed.</para> + + <para>Applications call the <constant>VIDIOC_DQBUF</constant> +ioctl to dequeue a filled (capturing) or displayed (output) buffer +from the driver's outgoing queue. They just set the +<structfield>type</structfield> and <structfield>memory</structfield> +fields of a &v4l2-buffer; as above, when <constant>VIDIOC_DQBUF</constant> +is called with a pointer to this structure the driver fills the +remaining fields or returns an error code.</para> + + <para>By default <constant>VIDIOC_DQBUF</constant> blocks when no +buffer is in the outgoing queue. When the +<constant>O_NONBLOCK</constant> flag was given to the &func-open; +function, <constant>VIDIOC_DQBUF</constant> returns immediately +with an &EAGAIN; when no buffer is available.</para> + + <para>The <structname>v4l2_buffer</structname> structure is +specified in <xref linkend="buffer" />.</para> + </refsect1> + + <refsect1> + &return-value; + + <variablelist> + <varlistentry> + <term><errorcode>EAGAIN</errorcode></term> + <listitem> + <para>Non-blocking I/O has been selected using +<constant>O_NONBLOCK</constant> and no buffer was in the outgoing +queue.</para> + </listitem> + </varlistentry> + <varlistentry> + <term><errorcode>EINVAL</errorcode></term> + <listitem> + <para>The buffer <structfield>type</structfield> is not +supported, or the <structfield>index</structfield> is out of bounds, +or no buffers have been allocated yet, or the +<structfield>userptr</structfield> or +<structfield>length</structfield> are invalid.</para> + </listitem> + </varlistentry> + <varlistentry> + <term><errorcode>ENOMEM</errorcode></term> + <listitem> + <para>Not enough physical or virtual memory was available to +enqueue a user pointer buffer.</para> + </listitem> + </varlistentry> + <varlistentry> + <term><errorcode>EIO</errorcode></term> + <listitem> + <para><constant>VIDIOC_DQBUF</constant> failed due to an +internal error. Can also indicate temporary problems like signal +loss. Note the driver might dequeue an (empty) buffer despite +returning an error, or even stop capturing.</para> + </listitem> + </varlistentry> + </variablelist> + </refsect1> +</refentry> + +<!-- +Local Variables: +mode: sgml +sgml-parent-document: "v4l2.sgml" +indent-tabs-mode: nil +End: +--> diff --git a/Documentation/DocBook/v4l/vidioc-query-dv-preset.xml b/Documentation/DocBook/v4l/vidioc-query-dv-preset.xml new file mode 100644 index 000000000000..87e4f0f6151c --- /dev/null +++ b/Documentation/DocBook/v4l/vidioc-query-dv-preset.xml @@ -0,0 +1,85 @@ +<refentry id="vidioc-query-dv-preset"> + <refmeta> + <refentrytitle>ioctl VIDIOC_QUERY_DV_PRESET</refentrytitle> + &manvol; + </refmeta> + + <refnamediv> + <refname>VIDIOC_QUERY_DV_PRESET</refname> + <refpurpose>Sense the DV preset received by the current +input</refpurpose> + </refnamediv> + + <refsynopsisdiv> + <funcsynopsis> + <funcprototype> + <funcdef>int <function>ioctl</function></funcdef> + <paramdef>int <parameter>fd</parameter></paramdef> + <paramdef>int <parameter>request</parameter></paramdef> + <paramdef>&v4l2-dv-preset; *<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_QUERY_DV_PRESET</para> + </listitem> + </varlistentry> + <varlistentry> + <term><parameter>argp</parameter></term> + <listitem> + <para></para> + </listitem> + </varlistentry> + </variablelist> + </refsect1> + + <refsect1> + <title>Description</title> + + <para>The hardware may be able to detect the current DV preset +automatically, similar to sensing the video standard. To do so, applications +call <constant> VIDIOC_QUERY_DV_PRESET</constant> with a pointer to a +&v4l2-dv-preset; type. Once the hardware detects a preset, that preset is +returned in the preset field of &v4l2-dv-preset;. When detection is not +possible or fails, the value V4L2_DV_INVALID is returned.</para> + </refsect1> + + <refsect1> + &return-value; + <variablelist> + <varlistentry> + <term><errorcode>EINVAL</errorcode></term> + <listitem> + <para>This ioctl is not supported.</para> + </listitem> + </varlistentry> + <varlistentry> + <term><errorcode>EBUSY</errorcode></term> + <listitem> + <para>The device is busy and therefore can not sense the preset</para> + </listitem> + </varlistentry> + </variablelist> + </refsect1> +</refentry> + +<!-- +Local Variables: +mode: sgml +sgml-parent-document: "v4l2.sgml" +indent-tabs-mode: nil +End: +--> diff --git a/Documentation/DocBook/v4l/vidioc-querybuf.xml b/Documentation/DocBook/v4l/vidioc-querybuf.xml new file mode 100644 index 000000000000..d834993e6191 --- /dev/null +++ b/Documentation/DocBook/v4l/vidioc-querybuf.xml @@ -0,0 +1,103 @@ +<refentry id="vidioc-querybuf"> + <refmeta> + <refentrytitle>ioctl VIDIOC_QUERYBUF</refentrytitle> + &manvol; + </refmeta> + + <refnamediv> + <refname>VIDIOC_QUERYBUF</refname> + <refpurpose>Query the status of a buffer</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_buffer *<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_QUERYBUF</para> + </listitem> + </varlistentry> + <varlistentry> + <term><parameter>argp</parameter></term> + <listitem> + <para></para> + </listitem> + </varlistentry> + </variablelist> + </refsect1> + + <refsect1> + <title>Description</title> + + <para>This ioctl is part of the <link linkend="mmap">memory +mapping</link> I/O method. It can be used to query the status of a +buffer at any time after buffers have been allocated with the +&VIDIOC-REQBUFS; ioctl.</para> + + <para>Applications set the <structfield>type</structfield> field + of a &v4l2-buffer; to the same buffer type as previously +&v4l2-format; <structfield>type</structfield> and &v4l2-requestbuffers; +<structfield>type</structfield>, and the <structfield>index</structfield> + field. Valid index numbers range from zero +to the number of buffers allocated with &VIDIOC-REQBUFS; + (&v4l2-requestbuffers; <structfield>count</structfield>) minus one. +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> + + <para>In the <structfield>flags</structfield> field the +<constant>V4L2_BUF_FLAG_MAPPED</constant>, +<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 +<constant>V4L2_MEMORY_MMAP</constant>, 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> + + <para>The <structname>v4l2_buffer</structname> structure is + specified in <xref linkend="buffer" />.</para> + </refsect1> + + <refsect1> + &return-value; + + <variablelist> + <varlistentry> + <term><errorcode>EINVAL</errorcode></term> + <listitem> + <para>The buffer <structfield>type</structfield> is not +supported, or the <structfield>index</structfield> is out of bounds.</para> + </listitem> + </varlistentry> + </variablelist> + </refsect1> +</refentry> + +<!-- +Local Variables: +mode: sgml +sgml-parent-document: "v4l2.sgml" +indent-tabs-mode: nil +End: +--> diff --git a/Documentation/DocBook/v4l/vidioc-querycap.xml b/Documentation/DocBook/v4l/vidioc-querycap.xml new file mode 100644 index 000000000000..6ab7e25b31b6 --- /dev/null +++ b/Documentation/DocBook/v4l/vidioc-querycap.xml @@ -0,0 +1,284 @@ +<refentry id="vidioc-querycap"> + <refmeta> + <refentrytitle>ioctl VIDIOC_QUERYCAP</refentrytitle> + &manvol; + </refmeta> + + <refnamediv> + <refname>VIDIOC_QUERYCAP</refname> + <refpurpose>Query device capabilities</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_capability *<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_QUERYCAP</para> + </listitem> + </varlistentry> + <varlistentry> + <term><parameter>argp</parameter></term> + <listitem> + <para></para> + </listitem> + </varlistentry> + </variablelist> + </refsect1> + + <refsect1> + <title>Description</title> + + <para>All V4L2 devices support the +<constant>VIDIOC_QUERYCAP</constant> ioctl. It is used to identify +kernel devices compatible with this specification and to obtain +information about driver and hardware capabilities. The ioctl takes a +pointer to a &v4l2-capability; which is filled by the driver. When the +driver is not compatible with this specification the ioctl returns an +&EINVAL;.</para> + + <table pgwide="1" frame="none" id="v4l2-capability"> + <title>struct <structname>v4l2_capability</structname></title> + <tgroup cols="3"> + &cs-str; + <tbody valign="top"> + <row> + <entry>__u8</entry> + <entry><structfield>driver</structfield>[16]</entry> + <entry><para>Name of the driver, a unique NUL-terminated +ASCII string. For example: "bttv". 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. +The driver version is stored in the <structfield>version</structfield> +field.</para><para>Storing strings in fixed sized arrays is bad +practice but unavoidable here. Drivers and applications should take +precautions to never read or write beyond the end of the array and to +make sure the strings are properly NUL-terminated.</para></entry> + </row> + <row> + <entry>__u8</entry> + <entry><structfield>card</structfield>[32]</entry> + <entry>Name of the device, a NUL-terminated ASCII string. +For example: "Yoyodyne TV/FM". One driver may support different brands +or models of video hardware. This information is intended for users, +for example in a menu of available devices. Since multiple TV cards of +the same brand may be installed which are supported by the same +driver, this name should be combined with the character device file +name (⪚ <filename>/dev/video2</filename>) or the +<structfield>bus_info</structfield> string to avoid +ambiguities.</entry> + </row> + <row> + <entry>__u8</entry> + <entry><structfield>bus_info</structfield>[32]</entry> + <entry>Location of the device in the system, a +NUL-terminated ASCII string. For example: "PCI Slot 4". This +information is intended for users, to distinguish multiple +identical devices. If no such information is available the field may +simply count the devices controlled by the driver, or contain the +empty string (<structfield>bus_info</structfield>[0] = 0).<!-- XXX pci_dev->slot_name example --></entry> + </row> + <row> + <entry>__u32</entry> + <entry><structfield>version</structfield></entry> + <entry><para>Version number of the driver. Together with +the <structfield>driver</structfield> field this identifies a +particular driver. The version number is formatted using the +<constant>KERNEL_VERSION()</constant> macro:</para></entry> + </row> + <row> + <entry spanname="hspan"><para> +<programlisting> +#define KERNEL_VERSION(a,b,c) (((a) << 16) + ((b) << 8) + (c)) + +__u32 version = KERNEL_VERSION(0, 8, 1); + +printf ("Version: %u.%u.%u\n", + (version >> 16) & 0xFF, + (version >> 8) & 0xFF, + version & 0xFF); +</programlisting></para></entry> + </row> + <row> + <entry>__u32</entry> + <entry><structfield>capabilities</structfield></entry> + <entry>Device capabilities, see <xref + linkend="device-capabilities" />.</entry> + </row> + <row> + <entry>__u32</entry> + <entry><structfield>reserved</structfield>[4]</entry> + <entry>Reserved for future extensions. Drivers must set +this array to zero.</entry> + </row> + </tbody> + </tgroup> + </table> + + <table pgwide="1" frame="none" id="device-capabilities"> + <title>Device Capabilities Flags</title> + <tgroup cols="3"> + &cs-def; + <tbody valign="top"> + <row> + <entry><constant>V4L2_CAP_VIDEO_CAPTURE</constant></entry> + <entry>0x00000001</entry> + <entry>The device supports 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 +linkend="output">Video Output</link> interface.</entry> + </row> + <row> + <entry><constant>V4L2_CAP_VIDEO_OVERLAY</constant></entry> + <entry>0x00000004</entry> + <entry>The device supports the <link +linkend="overlay">Video Overlay</link> interface. A video overlay device +typically stores captured images directly in the video memory of a +graphics card, with hardware clipping and scaling.</entry> + </row> + <row> + <entry><constant>V4L2_CAP_VBI_CAPTURE</constant></entry> + <entry>0x00000010</entry> + <entry>The device supports the <link linkend="raw-vbi">Raw +VBI Capture</link> interface, providing Teletext and Closed Caption +data.</entry> + </row> + <row> + <entry><constant>V4L2_CAP_VBI_OUTPUT</constant></entry> + <entry>0x00000020</entry> + <entry>The device supports the <link linkend="raw-vbi">Raw VBI Output</link> interface.</entry> + </row> + <row> + <entry><constant>V4L2_CAP_SLICED_VBI_CAPTURE</constant></entry> + <entry>0x00000040</entry> + <entry>The device supports the <link linkend="sliced">Sliced VBI Capture</link> interface.</entry> + </row> + <row> + <entry><constant>V4L2_CAP_SLICED_VBI_OUTPUT</constant></entry> + <entry>0x00000080</entry> + <entry>The device supports the <link linkend="sliced">Sliced VBI Output</link> interface.</entry> + </row> + <row> + <entry><constant>V4L2_CAP_RDS_CAPTURE</constant></entry> + <entry>0x00000100</entry> + <entry>The device supports the <link linkend="rds">RDS</link> interface.</entry> + </row> + <row> + <entry><constant>V4L2_CAP_VIDEO_OUTPUT_OVERLAY</constant></entry> + <entry>0x00000200</entry> + <entry>The device supports the <link linkend="osd">Video +Output Overlay</link> (OSD) interface. Unlike the <wordasword>Video +Overlay</wordasword> interface, this is a secondary function of video +output devices and overlays an image onto an outgoing video signal. +When the driver sets this flag, it must clear the +<constant>V4L2_CAP_VIDEO_OVERLAY</constant> flag and vice +versa.<footnote><para>The &v4l2-framebuffer; lacks an +&v4l2-buf-type; field, therefore the type of overlay is implied by the +driver capabilities.</para></footnote></entry> + </row> + <row> + <entry><constant>V4L2_CAP_HW_FREQ_SEEK</constant></entry> + <entry>0x00000400</entry> + <entry>The device supports the &VIDIOC-S-HW-FREQ-SEEK; ioctl for +hardware frequency seeking.</entry> + </row> + <row> + <entry><constant>V4L2_CAP_TUNER</constant></entry> + <entry>0x00010000</entry> + <entry>The device has some sort of tuner to +receive RF-modulated video signals. For more information about +tuner programming see +<xref linkend="tuner" />.</entry> + </row> + <row> + <entry><constant>V4L2_CAP_AUDIO</constant></entry> + <entry>0x00020000</entry> + <entry>The device has audio inputs or outputs. It may or +may not support audio recording or playback, in PCM or compressed +formats. PCM audio support must be implemented as ALSA or OSS +interface. For more information on audio inputs and outputs see <xref + linkend="audio" />.</entry> + </row> + <row> + <entry><constant>V4L2_CAP_RADIO</constant></entry> + <entry>0x00040000</entry> + <entry>This is a radio receiver.</entry> + </row> + <row> + <entry><constant>V4L2_CAP_MODULATOR</constant></entry> + <entry>0x00080000</entry> + <entry>The device has some sort of modulator to +emit RF-modulated video/audio signals. For more information about +modulator programming see +<xref linkend="tuner" />.</entry> + </row> + <row> + <entry><constant>V4L2_CAP_READWRITE</constant></entry> + <entry>0x01000000</entry> + <entry>The device supports the <link +linkend="rw">read()</link> and/or <link linkend="rw">write()</link> +I/O methods.</entry> + </row> + <row> + <entry><constant>V4L2_CAP_ASYNCIO</constant></entry> + <entry>0x02000000</entry> + <entry>The device supports the <link +linkend="async">asynchronous</link> I/O methods.</entry> + </row> + <row> + <entry><constant>V4L2_CAP_STREAMING</constant></entry> + <entry>0x04000000</entry> + <entry>The device supports the <link +linkend="mmap">streaming</link> I/O method.</entry> + </row> + </tbody> + </tgroup> + </table> + </refsect1> + + <refsect1> + &return-value; + + <variablelist> + <varlistentry> + <term><errorcode>EINVAL</errorcode></term> + <listitem> + <para>The device is not compatible with this +specification.</para> + </listitem> + </varlistentry> + </variablelist> + </refsect1> +</refentry> + +<!-- +Local Variables: +mode: sgml +sgml-parent-document: "v4l2.sgml" +indent-tabs-mode: nil +End: +--> + diff --git a/Documentation/DocBook/v4l/vidioc-queryctrl.xml b/Documentation/DocBook/v4l/vidioc-queryctrl.xml new file mode 100644 index 000000000000..4876ff1a1a04 --- /dev/null +++ b/Documentation/DocBook/v4l/vidioc-queryctrl.xml @@ -0,0 +1,428 @@ +<refentry id="vidioc-queryctrl"> + <refmeta> + <refentrytitle>ioctl VIDIOC_QUERYCTRL, VIDIOC_QUERYMENU</refentrytitle> + &manvol; + </refmeta> + + <refnamediv> + <refname>VIDIOC_QUERYCTRL</refname> + <refname>VIDIOC_QUERYMENU</refname> + <refpurpose>Enumerate controls and menu control items</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_queryctrl *<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>struct v4l2_querymenu *<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_QUERYCTRL, VIDIOC_QUERYMENU</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 a control applications set the +<structfield>id</structfield> field of a &v4l2-queryctrl; and call the +<constant>VIDIOC_QUERYCTRL</constant> ioctl with a pointer to this +structure. The driver fills the rest of the structure or returns an +&EINVAL; when the <structfield>id</structfield> is invalid.</para> + + <para>It is possible to enumerate controls by calling +<constant>VIDIOC_QUERYCTRL</constant> with successive +<structfield>id</structfield> values starting from +<constant>V4L2_CID_BASE</constant> up to and exclusive +<constant>V4L2_CID_BASE_LASTP1</constant>. Drivers may return +<errorcode>EINVAL</errorcode> if a control in this range is not +supported. Further applications can enumerate private controls, which +are not defined in this specification, by starting at +<constant>V4L2_CID_PRIVATE_BASE</constant> and incrementing +<structfield>id</structfield> until the driver returns +<errorcode>EINVAL</errorcode>.</para> + + <para>In both cases, when the driver sets the +<constant>V4L2_CTRL_FLAG_DISABLED</constant> flag in the +<structfield>flags</structfield> field this control is permanently +disabled and should be ignored by the application.<footnote> + <para><constant>V4L2_CTRL_FLAG_DISABLED</constant> was +intended for two purposes: Drivers can skip predefined controls not +supported by the hardware (although returning EINVAL would do as +well), or disable predefined and private controls after hardware +detection without the trouble of reordering control arrays and indices +(EINVAL cannot be used to skip private controls because it would +prematurely end the enumeration).</para></footnote></para> + + <para>When the application ORs <structfield>id</structfield> with +<constant>V4L2_CTRL_FLAG_NEXT_CTRL</constant> the driver returns the +next supported control, or <errorcode>EINVAL</errorcode> if there is +none. Drivers which do not support this flag yet always return +<errorcode>EINVAL</errorcode>.</para> + + <para>Additional information is required for menu controls: the +names of the menu items. To query them applications set the +<structfield>id</structfield> and <structfield>index</structfield> +fields of &v4l2-querymenu; and call the +<constant>VIDIOC_QUERYMENU</constant> ioctl with a pointer to this +structure. The driver fills the rest of the structure or returns an +&EINVAL; when the <structfield>id</structfield> or +<structfield>index</structfield> is invalid. Menu items are enumerated +by calling <constant>VIDIOC_QUERYMENU</constant> with successive +<structfield>index</structfield> values from &v4l2-queryctrl; +<structfield>minimum</structfield> (0) to +<structfield>maximum</structfield>, inclusive.</para> + + <para>See also the examples in <xref linkend="control" />.</para> + + <table pgwide="1" frame="none" id="v4l2-queryctrl"> + <title>struct <structname>v4l2_queryctrl</structname></title> + <tgroup cols="3"> + &cs-str; + <tbody valign="top"> + <row> + <entry>__u32</entry> + <entry><structfield>id</structfield></entry> + <entry>Identifies the control, set by the application. See +<xref linkend="control-id" /> for predefined IDs. When the ID is ORed +with V4L2_CTRL_FLAG_NEXT_CTRL the driver clears the flag and returns +the first control with a higher ID. Drivers which do not support this +flag yet always return an &EINVAL;.</entry> + </row> + <row> + <entry>&v4l2-ctrl-type;</entry> + <entry><structfield>type</structfield></entry> + <entry>Type of control, see <xref + linkend="v4l2-ctrl-type" />.</entry> + </row> + <row> + <entry>__u8</entry> + <entry><structfield>name</structfield>[32]</entry> + <entry>Name of the control, a NUL-terminated ASCII +string. This information is intended for the user.</entry> + </row> + <row> + <entry>__s32</entry> + <entry><structfield>minimum</structfield></entry> + <entry>Minimum value, inclusive. This field gives a lower +bound for <constant>V4L2_CTRL_TYPE_INTEGER</constant> controls and the +lowest valid index (always 0) for <constant>V4L2_CTRL_TYPE_MENU</constant> controls. +For <constant>V4L2_CTRL_TYPE_STRING</constant> controls the minimum value +gives the minimum length of the string. This length <emphasis>does not include the terminating +zero</emphasis>. It may not be valid for any other type of control, including +<constant>V4L2_CTRL_TYPE_INTEGER64</constant> controls. Note that this is a +signed value.</entry> + </row> + <row> + <entry>__s32</entry> + <entry><structfield>maximum</structfield></entry> + <entry>Maximum value, inclusive. This field gives an upper +bound for <constant>V4L2_CTRL_TYPE_INTEGER</constant> controls and the +highest valid index for <constant>V4L2_CTRL_TYPE_MENU</constant> +controls. +For <constant>V4L2_CTRL_TYPE_STRING</constant> controls the maximum value +gives the maximum length of the string. This length <emphasis>does not include the terminating +zero</emphasis>. It may not be valid for any other type of control, including +<constant>V4L2_CTRL_TYPE_INTEGER64</constant> controls. Note that this is a +signed value.</entry> + </row> + <row> + <entry>__s32</entry> + <entry><structfield>step</structfield></entry> + <entry><para>This field gives a step size for +<constant>V4L2_CTRL_TYPE_INTEGER</constant> controls. For +<constant>V4L2_CTRL_TYPE_STRING</constant> controls this field refers to +the string length that has to be a multiple of this step size. +It may not be valid for any other type of control, including +<constant>V4L2_CTRL_TYPE_INTEGER64</constant> +controls.</para><para>Generally drivers should not scale hardware +control values. It may be necessary for example when the +<structfield>name</structfield> or <structfield>id</structfield> imply +a particular unit and the hardware actually accepts only multiples of +said unit. If so, drivers must take care values are properly rounded +when scaling, such that errors will not accumulate on repeated +read-write cycles.</para><para>This field gives the smallest change of +an integer control actually affecting hardware. Often the information +is needed when the user can change controls by keyboard or GUI +buttons, rather than a slider. When for example a hardware register +accepts values 0-511 and the driver reports 0-65535, step should be +128.</para><para>Note that although signed, the step value is supposed to +be always positive.</para></entry> + </row> + <row> + <entry>__s32</entry> + <entry><structfield>default_value</structfield></entry> + <entry>The default value of a +<constant>V4L2_CTRL_TYPE_INTEGER</constant>, +<constant>_BOOLEAN</constant> or <constant>_MENU</constant> control. +Not valid for other types of controls. Drivers reset controls only +when the driver is loaded, not later, in particular not when the +func-open; is called.</entry> + </row> + <row> + <entry>__u32</entry> + <entry><structfield>flags</structfield></entry> + <entry>Control flags, see <xref + linkend="control-flags" />.</entry> + </row> + <row> + <entry>__u32</entry> + <entry><structfield>reserved</structfield>[2]</entry> + <entry>Reserved for future extensions. Drivers must set +the array to zero.</entry> + </row> + </tbody> + </tgroup> + </table> + + <table pgwide="1" frame="none" id="v4l2-querymenu"> + <title>struct <structname>v4l2_querymenu</structname></title> + <tgroup cols="3"> + &cs-str; + <tbody valign="top"> + <row> + <entry>__u32</entry> + <entry><structfield>id</structfield></entry> + <entry>Identifies the control, set by the application +from the respective &v4l2-queryctrl; +<structfield>id</structfield>.</entry> + </row> + <row> + <entry>__u32</entry> + <entry><structfield>index</structfield></entry> + <entry>Index of the menu item, starting at zero, set by + the application.</entry> + </row> + <row> + <entry>__u8</entry> + <entry><structfield>name</structfield>[32]</entry> + <entry>Name of the menu item, a NUL-terminated ASCII +string. This information is intended for the user.</entry> + </row> + <row> + <entry>__u32</entry> + <entry><structfield>reserved</structfield></entry> + <entry>Reserved for future extensions. Drivers must set +the array to zero.</entry> + </row> + </tbody> + </tgroup> + </table> + + <table pgwide="1" frame="none" id="v4l2-ctrl-type"> + <title>enum v4l2_ctrl_type</title> + <tgroup cols="5" align="left"> + <colspec colwidth="30*" /> + <colspec colwidth="5*" align="center" /> + <colspec colwidth="5*" align="center" /> + <colspec colwidth="5*" align="center" /> + <colspec colwidth="55*" /> + <thead> + <row> + <entry>Type</entry> + <entry><structfield>minimum</structfield></entry> + <entry><structfield>step</structfield></entry> + <entry><structfield>maximum</structfield></entry> + <entry>Description</entry> + </row> + </thead> + <tbody valign="top"> + <row> + <entry><constant>V4L2_CTRL_TYPE_INTEGER</constant></entry> + <entry>any</entry> + <entry>any</entry> + <entry>any</entry> + <entry>An integer-valued control ranging from minimum to +maximum inclusive. The step value indicates the increment between +values which are actually different on the hardware.</entry> + </row> + <row> + <entry><constant>V4L2_CTRL_TYPE_BOOLEAN</constant></entry> + <entry>0</entry> + <entry>1</entry> + <entry>1</entry> + <entry>A boolean-valued control. Zero corresponds to +"disabled", and one means "enabled".</entry> + </row> + <row> + <entry><constant>V4L2_CTRL_TYPE_MENU</constant></entry> + <entry>0</entry> + <entry>1</entry> + <entry>N-1</entry> + <entry>The control has a menu of N choices. The names of +the menu items can be enumerated with the +<constant>VIDIOC_QUERYMENU</constant> ioctl.</entry> + </row> + <row> + <entry><constant>V4L2_CTRL_TYPE_BUTTON</constant></entry> + <entry>0</entry> + <entry>0</entry> + <entry>0</entry> + <entry>A control which performs an action when set. +Drivers must ignore the value passed with +<constant>VIDIOC_S_CTRL</constant> and return an &EINVAL; on a +<constant>VIDIOC_G_CTRL</constant> attempt.</entry> + </row> + <row> + <entry><constant>V4L2_CTRL_TYPE_INTEGER64</constant></entry> + <entry>n/a</entry> + <entry>n/a</entry> + <entry>n/a</entry> + <entry>A 64-bit integer valued control. Minimum, maximum +and step size cannot be queried.</entry> + </row> + <row> + <entry><constant>V4L2_CTRL_TYPE_STRING</constant></entry> + <entry>≥ 0</entry> + <entry>≥ 1</entry> + <entry>≥ 0</entry> + <entry>The minimum and maximum string lengths. The step size +means that the string must be (minimum + N * step) characters long for +N ≥ 0. These lengths do not include the terminating zero, so in order to +pass a string of length 8 to &VIDIOC-S-EXT-CTRLS; you need to set the +<structfield>size</structfield> field of &v4l2-ext-control; to 9. For &VIDIOC-G-EXT-CTRLS; you can +set the <structfield>size</structfield> field to <structfield>maximum</structfield> + 1. +Which character encoding is used will depend on the string control itself and +should be part of the control documentation.</entry> + </row> + <row> + <entry><constant>V4L2_CTRL_TYPE_CTRL_CLASS</constant></entry> + <entry>n/a</entry> + <entry>n/a</entry> + <entry>n/a</entry> + <entry>This is not a control. When +<constant>VIDIOC_QUERYCTRL</constant> is called with a control ID +equal to a control class code (see <xref linkend="ctrl-class" />), the +ioctl returns the name of the control class and this control type. +Older drivers which do not support this feature return an +&EINVAL;.</entry> + </row> + </tbody> + </tgroup> + </table> + + <table pgwide="1" frame="none" id="control-flags"> + <title>Control Flags</title> + <tgroup cols="3"> + &cs-def; + <tbody valign="top"> + <row> + <entry><constant>V4L2_CTRL_FLAG_DISABLED</constant></entry> + <entry>0x0001</entry> + <entry>This control is permanently disabled and should be +ignored by the application. Any attempt to change the control will +result in an &EINVAL;.</entry> + </row> + <row> + <entry><constant>V4L2_CTRL_FLAG_GRABBED</constant></entry> + <entry>0x0002</entry> + <entry>This control is temporarily unchangeable, for +example because another application took over control of the +respective resource. Such controls may be displayed specially in a +user interface. Attempts to change the control may result in an +&EBUSY;.</entry> + </row> + <row> + <entry><constant>V4L2_CTRL_FLAG_READ_ONLY</constant></entry> + <entry>0x0004</entry> + <entry>This control is permanently readable only. Any +attempt to change the control will result in an &EINVAL;.</entry> + </row> + <row> + <entry><constant>V4L2_CTRL_FLAG_UPDATE</constant></entry> + <entry>0x0008</entry> + <entry>A hint that changing this control may affect the +value of other controls within the same control class. Applications +should update their user interface accordingly.</entry> + </row> + <row> + <entry><constant>V4L2_CTRL_FLAG_INACTIVE</constant></entry> + <entry>0x0010</entry> + <entry>This control is not applicable to the current +configuration and should be displayed accordingly in a user interface. +For example the flag may be set on a MPEG audio level 2 bitrate +control when MPEG audio encoding level 1 was selected with another +control.</entry> + </row> + <row> + <entry><constant>V4L2_CTRL_FLAG_SLIDER</constant></entry> + <entry>0x0020</entry> + <entry>A hint that this control is best represented as a +slider-like element in a user interface.</entry> + </row> + <row> + <entry><constant>V4L2_CTRL_FLAG_WRITE_ONLY</constant></entry> + <entry>0x0040</entry> + <entry>This control is permanently writable only. Any +attempt to read the control will result in an &EACCES; error code. This +flag is typically present for relative controls or action controls where +writing a value will cause the device to carry out a given action +(⪚ motor control) but no meaningful value can be returned.</entry> + </row> + </tbody> + </tgroup> + </table> + </refsect1> + + <refsect1> + &return-value; + + <variablelist> + <varlistentry> + <term><errorcode>EINVAL</errorcode></term> + <listitem> + <para>The &v4l2-queryctrl; <structfield>id</structfield> +is invalid. The &v4l2-querymenu; <structfield>id</structfield> or +<structfield>index</structfield> is invalid.</para> + </listitem> + </varlistentry> + <varlistentry> + <term><errorcode>EACCES</errorcode></term> + <listitem> + <para>An attempt was made to read a write-only control.</para> + </listitem> + </varlistentry> + </variablelist> + </refsect1> +</refentry> + +<!-- +Local Variables: +mode: sgml +sgml-parent-document: "v4l2.sgml" +indent-tabs-mode: nil +End: +--> diff --git a/Documentation/DocBook/v4l/vidioc-querystd.xml b/Documentation/DocBook/v4l/vidioc-querystd.xml new file mode 100644 index 000000000000..1a9e60393091 --- /dev/null +++ b/Documentation/DocBook/v4l/vidioc-querystd.xml @@ -0,0 +1,89 @@ +<refentry id="vidioc-querystd"> + <refmeta> + <refentrytitle>ioctl VIDIOC_QUERYSTD</refentrytitle> + &manvol; + </refmeta> + + <refnamediv> + <refname>VIDIOC_QUERYSTD</refname> + <refpurpose>Sense the video standard received by the current +input</refpurpose> + </refnamediv> + + <refsynopsisdiv> + <funcsynopsis> + <funcprototype> + <funcdef>int <function>ioctl</function></funcdef> + <paramdef>int <parameter>fd</parameter></paramdef> + <paramdef>int <parameter>request</parameter></paramdef> + <paramdef>v4l2_std_id *<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_QUERYSTD</para> + </listitem> + </varlistentry> + <varlistentry> + <term><parameter>argp</parameter></term> + <listitem> + <para></para> + </listitem> + </varlistentry> + </variablelist> + </refsect1> + + <refsect1> + <title>Description</title> + + <para>The hardware may be able to detect the current video +standard automatically. To do so, applications call <constant> +VIDIOC_QUERYSTD</constant> with a pointer to a &v4l2-std-id; type. The +driver stores here a set of candidates, this can be a single flag or a +set of supported standards if for example the hardware can only +distinguish between 50 and 60 Hz systems. When detection is not +possible or fails, the set must contain all standards supported by the +current video input or output.</para> + + </refsect1> + + <refsect1> + &return-value; + + <variablelist> + <varlistentry> + <term><errorcode>EINVAL</errorcode></term> + <listitem> + <para>This ioctl is not supported.</para> + </listitem> + </varlistentry> + <varlistentry> + <term><errorcode>EBUSY</errorcode></term> + <listitem> + <para>The device is busy and therefore can not detect the standard</para> + </listitem> + </varlistentry> + </variablelist> + </refsect1> +</refentry> + +<!-- +Local Variables: +mode: sgml +sgml-parent-document: "v4l2.sgml" +indent-tabs-mode: nil +End: +--> diff --git a/Documentation/DocBook/v4l/vidioc-reqbufs.xml b/Documentation/DocBook/v4l/vidioc-reqbufs.xml new file mode 100644 index 000000000000..bab38084454f --- /dev/null +++ b/Documentation/DocBook/v4l/vidioc-reqbufs.xml @@ -0,0 +1,160 @@ +<refentry id="vidioc-reqbufs"> + <refmeta> + <refentrytitle>ioctl VIDIOC_REQBUFS</refentrytitle> + &manvol; + </refmeta> + + <refnamediv> + <refname>VIDIOC_REQBUFS</refname> + <refpurpose>Initiate Memory Mapping or User Pointer I/O</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_requestbuffers *<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_REQBUFS</para> + </listitem> + </varlistentry> + <varlistentry> + <term><parameter>argp</parameter></term> + <listitem> + <para></para> + </listitem> + </varlistentry> + </variablelist> + </refsect1> + + <refsect1> + <title>Description</title> + + <para>This ioctl is used to initiate <link linkend="mmap">memory +mapped</link> or <link linkend="userp">user pointer</link> +I/O. Memory mapped buffers are located in device memory and must be +allocated with this ioctl before they can be mapped into the +application's address space. User buffers are allocated by +applications themselves, and this ioctl is merely used to switch the +driver into user pointer I/O mode.</para> + + <para>To allocate device buffers applications initialize three +fields of a <structname>v4l2_requestbuffers</structname> structure. +They set the <structfield>type</structfield> field to the respective +stream or buffer type, the <structfield>count</structfield> field to +the desired number of buffers, and <structfield>memory</structfield> +must be set to <constant>V4L2_MEMORY_MMAP</constant>. When the ioctl +is called with a pointer to this structure the driver attempts to +allocate the requested number of buffers and stores the actual number +allocated in the <structfield>count</structfield> field. It can be +smaller than the number requested, even zero, when the driver runs out +of free memory. A larger number is possible when the driver requires +more buffers to function correctly.<footnote> + <para>For example video output requires at least two buffers, +one displayed and one filled by the application.</para> + </footnote> When memory mapping I/O is not supported the ioctl +returns an &EINVAL;.</para> + + <para>Applications can call <constant>VIDIOC_REQBUFS</constant> +again to change the number of buffers, however this cannot succeed +when any buffers are still mapped. A <structfield>count</structfield> +value of zero frees all buffers, after aborting or finishing any DMA +in progress, an implicit &VIDIOC-STREAMOFF;. <!-- mhs: I see no +reason why munmap()ping one or even all buffers must imply +streamoff.--></para> + + <para>To negotiate user pointer I/O, applications initialize only +the <structfield>type</structfield> field and set +<structfield>memory</structfield> to +<constant>V4L2_MEMORY_USERPTR</constant>. When the ioctl is called +with a pointer to this structure the driver prepares for user pointer +I/O, when this I/O method is not supported the ioctl returns an +&EINVAL;.</para> + + <table pgwide="1" frame="none" id="v4l2-requestbuffers"> + <title>struct <structname>v4l2_requestbuffers</structname></title> + <tgroup cols="3"> + &cs-str; + <tbody valign="top"> + <row> + <entry>__u32</entry> + <entry><structfield>count</structfield></entry> + <entry>The number of buffers requested or granted. This +field is only used when <structfield>memory</structfield> is set to +<constant>V4L2_MEMORY_MMAP</constant>.</entry> + </row> + <row> + <entry>&v4l2-buf-type;</entry> + <entry><structfield>type</structfield></entry> + <entry>Type of the stream or buffers, this is the same +as the &v4l2-format; <structfield>type</structfield> field. See <xref + linkend="v4l2-buf-type" /> for valid values.</entry> + </row> + <row> + <entry>&v4l2-memory;</entry> + <entry><structfield>memory</structfield></entry> + <entry>Applications set this field to +<constant>V4L2_MEMORY_MMAP</constant> or +<constant>V4L2_MEMORY_USERPTR</constant>.</entry> + </row> + <row> + <entry>__u32</entry> + <entry><structfield>reserved</structfield>[2]</entry> + <entry>A place holder for future extensions and custom +(driver defined) buffer types <constant>V4L2_BUF_TYPE_PRIVATE</constant> and +higher.</entry> + </row> + </tbody> + </tgroup> + </table> + </refsect1> + + <refsect1> + &return-value; + + <variablelist> + <varlistentry> + <term><errorcode>EBUSY</errorcode></term> + <listitem> + <para>The driver supports multiple opens and I/O is already +in progress, or reallocation of buffers was attempted although one or +more are still mapped.</para> + </listitem> + </varlistentry> + <varlistentry> + <term><errorcode>EINVAL</errorcode></term> + <listitem> + <para>The buffer type (<structfield>type</structfield> field) or the +requested I/O method (<structfield>memory</structfield>) is not +supported.</para> + </listitem> + </varlistentry> + </variablelist> + </refsect1> +</refentry> + +<!-- +Local Variables: +mode: sgml +sgml-parent-document: "v4l2.sgml" +indent-tabs-mode: nil +End: +--> diff --git a/Documentation/DocBook/v4l/vidioc-s-hw-freq-seek.xml b/Documentation/DocBook/v4l/vidioc-s-hw-freq-seek.xml new file mode 100644 index 000000000000..14b3ec7ed75b --- /dev/null +++ b/Documentation/DocBook/v4l/vidioc-s-hw-freq-seek.xml @@ -0,0 +1,129 @@ +<refentry id="vidioc-s-hw-freq-seek"> + <refmeta> + <refentrytitle>ioctl VIDIOC_S_HW_FREQ_SEEK</refentrytitle> + &manvol; + </refmeta> + + <refnamediv> + <refname>VIDIOC_S_HW_FREQ_SEEK</refname> + <refpurpose>Perform a hardware frequency seek</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_hw_freq_seek +*<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_S_HW_FREQ_SEEK</para> + </listitem> + </varlistentry> + <varlistentry> + <term><parameter>argp</parameter></term> + <listitem> + <para></para> + </listitem> + </varlistentry> + </variablelist> + </refsect1> + + <refsect1> + <title>Description</title> + + <para>Start a hardware frequency seek from the current frequency. +To do this applications initialize the <structfield>tuner</structfield>, +<structfield>type</structfield>, <structfield>seek_upward</structfield> and +<structfield>wrap_around</structfield> fields, and zero out the +<structfield>reserved</structfield> array of a &v4l2-hw-freq-seek; and +call the <constant>VIDIOC_S_HW_FREQ_SEEK</constant> ioctl with a pointer +to this structure.</para> + + <para>This ioctl is supported if the <constant>V4L2_CAP_HW_FREQ_SEEK</constant> capability is set.</para> + + <table pgwide="1" frame="none" id="v4l2-hw-freq-seek"> + <title>struct <structname>v4l2_hw_freq_seek</structname></title> + <tgroup cols="3"> + &cs-str; + <tbody valign="top"> + <row> + <entry>__u32</entry> + <entry><structfield>tuner</structfield></entry> + <entry>The tuner index number. This is the +same value as in the &v4l2-input; <structfield>tuner</structfield> +field and the &v4l2-tuner; <structfield>index</structfield> field.</entry> + </row> + <row> + <entry>&v4l2-tuner-type;</entry> + <entry><structfield>type</structfield></entry> + <entry>The tuner type. This is the same value as in the +&v4l2-tuner; <structfield>type</structfield> field.</entry> + </row> + <row> + <entry>__u32</entry> + <entry><structfield>seek_upward</structfield></entry> + <entry>If non-zero, seek upward from the current frequency, else seek downward.</entry> + </row> + <row> + <entry>__u32</entry> + <entry><structfield>wrap_around</structfield></entry> + <entry>If non-zero, wrap around when at the end of the frequency range, else stop seeking.</entry> + </row> + <row> + <entry>__u32</entry> + <entry><structfield>reserved</structfield>[8]</entry> + <entry>Reserved for future extensions. Drivers and + applications 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 <structfield>tuner</structfield> index is out of +bounds or the value in the <structfield>type</structfield> field is +wrong.</para> + </listitem> + </varlistentry> + <varlistentry> + <term><errorcode>EAGAIN</errorcode></term> + <listitem> + <para>The ioctl timed-out. Try again.</para> + </listitem> + </varlistentry> + </variablelist> + </refsect1> +</refentry> + +<!-- +Local Variables: +mode: sgml +sgml-parent-document: "v4l2.sgml" +indent-tabs-mode: nil +End: +--> diff --git a/Documentation/DocBook/v4l/vidioc-streamon.xml b/Documentation/DocBook/v4l/vidioc-streamon.xml new file mode 100644 index 000000000000..e42bff1f2c0a --- /dev/null +++ b/Documentation/DocBook/v4l/vidioc-streamon.xml @@ -0,0 +1,106 @@ +<refentry id="vidioc-streamon"> + <refmeta> + <refentrytitle>ioctl VIDIOC_STREAMON, VIDIOC_STREAMOFF</refentrytitle> + &manvol; + </refmeta> + + <refnamediv> + <refname>VIDIOC_STREAMON</refname> + <refname>VIDIOC_STREAMOFF</refname> + <refpurpose>Start or stop streaming I/O</refpurpose> + </refnamediv> + + <refsynopsisdiv> + <funcsynopsis> + <funcprototype> + <funcdef>int <function>ioctl</function></funcdef> + <paramdef>int <parameter>fd</parameter></paramdef> + <paramdef>int <parameter>request</parameter></paramdef> + <paramdef>const int *<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_STREAMON, VIDIOC_STREAMOFF</para> + </listitem> + </varlistentry> + <varlistentry> + <term><parameter>argp</parameter></term> + <listitem> + <para></para> + </listitem> + </varlistentry> + </variablelist> + </refsect1> + + <refsect1> + <title>Description</title> + + <para>The <constant>VIDIOC_STREAMON</constant> and +<constant>VIDIOC_STREAMOFF</constant> ioctl start and stop the capture +or output process during streaming (<link linkend="mmap">memory +mapping</link> or <link linkend="userp">user pointer</link>) I/O.</para> + + <para>Specifically the capture hardware is disabled and no input +buffers are filled (if there are any empty buffers in the incoming +queue) until <constant>VIDIOC_STREAMON</constant> has been called. +Accordingly the output hardware is disabled, no video signal is +produced until <constant>VIDIOC_STREAMON</constant> has been called. +The ioctl will succeed only when at least one output buffer is in the +incoming queue.</para> + + <para>The <constant>VIDIOC_STREAMOFF</constant> ioctl, apart of +aborting or finishing any DMA in progress, unlocks any user pointer +buffers locked in physical memory, and it removes all buffers from the +incoming and outgoing queues. That means all images captured but not +dequeued yet will be lost, likewise all images enqueued for output but +not transmitted yet. I/O returns to the same state as after calling +&VIDIOC-REQBUFS; and can be restarted accordingly.</para> + + <para>Both ioctls take a pointer to an integer, the desired buffer or +stream type. This is the same as &v4l2-requestbuffers; +<structfield>type</structfield>.</para> + + <para>Note applications can be preempted for unknown periods right +before or after the <constant>VIDIOC_STREAMON</constant> or +<constant>VIDIOC_STREAMOFF</constant> calls, there is no notion of +starting or stopping "now". Buffer timestamps can be used to +synchronize with other events.</para> + </refsect1> + + <refsect1> + &return-value; + + <variablelist> + <varlistentry> + <term><errorcode>EINVAL</errorcode></term> + <listitem> + <para>Streaming I/O is not supported, the buffer +<structfield>type</structfield> is not supported, or no buffers have +been allocated (memory mapping) or enqueued (output) yet.</para> + </listitem> + </varlistentry> + </variablelist> + </refsect1> +</refentry> + +<!-- +Local Variables: +mode: sgml +sgml-parent-document: "v4l2.sgml" +indent-tabs-mode: nil +End: +--> diff --git a/Documentation/DocBook/writing-an-alsa-driver.tmpl b/Documentation/DocBook/writing-an-alsa-driver.tmpl index 7a2e0e98986a..0d0f7b4d4b1a 100644 --- a/Documentation/DocBook/writing-an-alsa-driver.tmpl +++ b/Documentation/DocBook/writing-an-alsa-driver.tmpl @@ -5318,7 +5318,7 @@ struct _snd_pcm_runtime { pages of the given size and map them onto the virtually contiguous memory. The virtual pointer is addressed in runtime->dma_area. The physical address (runtime->dma_addr) is set to zero, - because the buffer is physically non-contigous. + because the buffer is physically non-contiguous. The physical address table is set up in sgbuf->table. You can get the physical address at a certain offset via <function>snd_pcm_sgbuf_get_addr()</function>. diff --git a/Documentation/IO-mapping.txt b/Documentation/IO-mapping.txt index 78a440695e11..1b5aa10df845 100644 --- a/Documentation/IO-mapping.txt +++ b/Documentation/IO-mapping.txt @@ -157,7 +157,7 @@ For such memory, you can do things like * access only the 640k-1MB area, so anything else * has to be remapped. */ - char * baseptr = ioremap(0xFC000000, 1024*1024); + void __iomem *baseptr = ioremap(0xFC000000, 1024*1024); /* write a 'A' to the offset 10 of the area */ writeb('A',baseptr+10); diff --git a/Documentation/Intel-IOMMU.txt b/Documentation/Intel-IOMMU.txt index 21bc416d887e..cf9431db8731 100644 --- a/Documentation/Intel-IOMMU.txt +++ b/Documentation/Intel-IOMMU.txt @@ -56,11 +56,7 @@ Graphics Problems? ------------------ If you encounter issues with graphics devices, you can try adding option intel_iommu=igfx_off to turn off the integrated graphics engine. - -If it happens to be a PCI device included in the INCLUDE_ALL Engine, -then try enabling CONFIG_DMAR_GFX_WA to setup a 1-1 map. We hear -graphics drivers may be in process of using DMA api's in the near -future and at that time this option can be yanked out. +If this fixes anything, please ensure you file a bug reporting the problem. Some exceptions to IOVA ----------------------- diff --git a/Documentation/DMA-mapping.txt b/Documentation/PCI/PCI-DMA-mapping.txt index 01f24e94bdb6..ecad88d9fe59 100644 --- a/Documentation/DMA-mapping.txt +++ b/Documentation/PCI/PCI-DMA-mapping.txt @@ -214,7 +214,7 @@ most specific mask. Here is pseudo-code showing how this might be done: #define PLAYBACK_ADDRESS_BITS DMA_BIT_MASK(32) - #define RECORD_ADDRESS_BITS 0x00ffffff + #define RECORD_ADDRESS_BITS DMA_BIT_MASK(24) struct my_sound_card *card; struct pci_dev *pdev; @@ -224,14 +224,14 @@ Here is pseudo-code showing how this might be done: card->playback_enabled = 1; } else { card->playback_enabled = 0; - printk(KERN_WARN "%s: Playback disabled due to DMA limitations.\n", + printk(KERN_WARNING "%s: Playback disabled due to DMA limitations.\n", card->name); } if (!pci_set_dma_mask(pdev, RECORD_ADDRESS_BITS)) { card->record_enabled = 1; } else { card->record_enabled = 0; - printk(KERN_WARN "%s: Record disabled due to DMA limitations.\n", + printk(KERN_WARNING "%s: Record disabled due to DMA limitations.\n", card->name); } diff --git a/Documentation/PCI/pci-error-recovery.txt b/Documentation/PCI/pci-error-recovery.txt index 6650af432523..e83f2ea76415 100644 --- a/Documentation/PCI/pci-error-recovery.txt +++ b/Documentation/PCI/pci-error-recovery.txt @@ -4,15 +4,17 @@ February 2, 2006 Current document maintainer: - Linas Vepstas <linas@austin.ibm.com> + Linas Vepstas <linasvepstas@gmail.com> + updated by Richard Lary <rlary@us.ibm.com> + and Mike Mason <mmlnx@us.ibm.com> on 27-Jul-2009 Many PCI bus controllers are able to detect a variety of hardware PCI errors on the bus, such as parity errors on the data and address busses, as well as SERR and PERR errors. Some of the more advanced chipsets are able to deal with these errors; these include PCI-E chipsets, -and the PCI-host bridges found on IBM Power4 and Power5-based pSeries -boxes. A typical action taken is to disconnect the affected device, +and the PCI-host bridges found on IBM Power4, Power5 and Power6-based +pSeries boxes. A typical action taken is to disconnect the affected device, halting all I/O to it. The goal of a disconnection is to avoid system corruption; for example, to halt system memory corruption due to DMA's to "wild" addresses. Typically, a reconnection mechanism is also @@ -37,10 +39,11 @@ is forced by the need to handle multi-function devices, that is, devices that have multiple device drivers associated with them. In the first stage, each driver is allowed to indicate what type of reset it desires, the choices being a simple re-enabling of I/O -or requesting a hard reset (a full electrical #RST of the PCI card). -If any driver requests a full reset, that is what will be done. +or requesting a slot reset. -After a full reset and/or a re-enabling of I/O, all drivers are +If any driver requests a slot reset, that is what will be done. + +After a reset and/or a re-enabling of I/O, all drivers are again notified, so that they may then perform any device setup/config that may be required. After these have all completed, a final "resume normal operations" event is sent out. @@ -101,7 +104,7 @@ if it implements any, it must implement error_detected(). If a callback is not implemented, the corresponding feature is considered unsupported. For example, if mmio_enabled() and resume() aren't there, then it is assumed that the driver is not doing any direct recovery and requires -a reset. If link_reset() is not implemented, the card is assumed as +a slot reset. If link_reset() is not implemented, the card is assumed to not care about link resets. Typically a driver will want to know about a slot_reset(). @@ -111,7 +114,7 @@ sequence described below. STEP 0: Error Event ------------------- -PCI bus error is detect by the PCI hardware. On powerpc, the slot +A PCI bus error is detected by the PCI hardware. On powerpc, the slot is isolated, in that all I/O is blocked: all reads return 0xffffffff, all writes are ignored. @@ -139,7 +142,7 @@ The driver must return one of the following result codes: a chance to extract some diagnostic information (see mmio_enable, below). - PCI_ERS_RESULT_NEED_RESET: - Driver returns this if it can't recover without a hard + Driver returns this if it can't recover without a slot reset. - PCI_ERS_RESULT_DISCONNECT: Driver returns this if it doesn't want to recover at all. @@ -169,11 +172,11 @@ is STEP 6 (Permanent Failure). >>> The current powerpc implementation doesn't much care if the device >>> attempts I/O at this point, or not. I/O's will fail, returning ->>> a value of 0xff on read, and writes will be dropped. If the device ->>> driver attempts more than 10K I/O's to a frozen adapter, it will ->>> assume that the device driver has gone into an infinite loop, and ->>> it will panic the kernel. There doesn't seem to be any other ->>> way of stopping a device driver that insists on spinning on I/O. +>>> a value of 0xff on read, and writes will be dropped. If more than +>>> EEH_MAX_FAILS I/O's are attempted to a frozen adapter, EEH +>>> assumes that the device driver has gone into an infinite loop +>>> and prints an error to syslog. A reboot is then required to +>>> get the device working again. STEP 2: MMIO Enabled ------------------- @@ -182,15 +185,14 @@ DMA), and then calls the mmio_enabled() callback on all affected device drivers. This is the "early recovery" call. IOs are allowed again, but DMA is -not (hrm... to be discussed, I prefer not), with some restrictions. This -is NOT a callback for the driver to start operations again, only to -peek/poke at the device, extract diagnostic information, if any, and -eventually do things like trigger a device local reset or some such, -but not restart operations. This is callback is made if all drivers on -a segment agree that they can try to recover and if no automatic link reset -was performed by the HW. If the platform can't just re-enable IOs without -a slot reset or a link reset, it wont call this callback, and instead -will have gone directly to STEP 3 (Link Reset) or STEP 4 (Slot Reset) +not, with some restrictions. This is NOT a callback for the driver to +start operations again, only to peek/poke at the device, extract diagnostic +information, if any, and eventually do things like trigger a device local +reset or some such, but not restart operations. This callback is made if +all drivers on a segment agree that they can try to recover and if no automatic +link reset was performed by the HW. If the platform can't just re-enable IOs +without a slot reset or a link reset, it will not call this callback, and +instead will have gone directly to STEP 3 (Link Reset) or STEP 4 (Slot Reset) >>> The following is proposed; no platform implements this yet: >>> Proposal: All I/O's should be done _synchronously_ from within @@ -228,9 +230,6 @@ proceeds to either STEP3 (Link Reset) or to STEP 5 (Resume Operations). If any driver returned PCI_ERS_RESULT_NEED_RESET, then the platform proceeds to STEP 4 (Slot Reset) ->>> The current powerpc implementation does not implement this callback. - - STEP 3: Link Reset ------------------ The platform resets the link, and then calls the link_reset() callback @@ -253,16 +252,33 @@ The platform then proceeds to either STEP 4 (Slot Reset) or STEP 5 >>> The current powerpc implementation does not implement this callback. - STEP 4: Slot Reset ------------------ -The platform performs a soft or hard reset of the device, and then -calls the slot_reset() callback. -A soft reset consists of asserting the adapter #RST line and then +In response to a return value of PCI_ERS_RESULT_NEED_RESET, the +the platform will peform a slot reset on the requesting PCI device(s). +The actual steps taken by a platform to perform a slot reset +will be platform-dependent. Upon completion of slot reset, the +platform will call the device slot_reset() callback. + +Powerpc platforms implement two levels of slot reset: +soft reset(default) and fundamental(optional) reset. + +Powerpc soft reset consists of asserting the adapter #RST line and then restoring the PCI BAR's and PCI configuration header to a state that is equivalent to what it would be after a fresh system power-on followed by power-on BIOS/system firmware initialization. +Soft reset is also known as hot-reset. + +Powerpc fundamental reset is supported by PCI Express cards only +and results in device's state machines, hardware logic, port states and +configuration registers to initialize to their default conditions. + +For most PCI devices, a soft reset will be sufficient for recovery. +Optional fundamental reset is provided to support a limited number +of PCI Express PCI devices for which a soft reset is not sufficient +for recovery. + If the platform supports PCI hotplug, then the reset might be performed by toggling the slot electrical power off/on. @@ -274,10 +290,12 @@ may result in hung devices, kernel panics, or silent data corruption. This call gives drivers the chance to re-initialize the hardware (re-download firmware, etc.). At this point, the driver may assume -that he card is in a fresh state and is fully functional. In -particular, interrupt generation should work normally. +that the card is in a fresh state and is fully functional. The slot +is unfrozen and the driver has full access to PCI config space, +memory mapped I/O space and DMA. Interrupts (Legacy, MSI, or MSI-X) +will also be available. -Drivers should not yet restart normal I/O processing operations +Drivers should not restart normal I/O processing operations at this point. If all device drivers report success on this callback, the platform will call resume() to complete the sequence, and let the driver restart normal I/O processing. @@ -302,11 +320,21 @@ driver performs device init only from PCI function 0: - PCI_ERS_RESULT_DISCONNECT Same as above. +Drivers for PCI Express cards that require a fundamental reset must +set the needs_freset bit in the pci_dev structure in their probe function. +For example, the QLogic qla2xxx driver sets the needs_freset bit for certain +PCI card types: + ++ /* Set EEH reset type to fundamental if required by hba */ ++ if (IS_QLA24XX(ha) || IS_QLA25XX(ha) || IS_QLA81XX(ha)) ++ pdev->needs_freset = 1; ++ + Platform proceeds either to STEP 5 (Resume Operations) or STEP 6 (Permanent Failure). ->>> The current powerpc implementation does not currently try a ->>> power-cycle reset if the driver returned PCI_ERS_RESULT_DISCONNECT. +>>> The current powerpc implementation does not try a power-cycle +>>> reset if the driver returned PCI_ERS_RESULT_DISCONNECT. >>> However, it probably should. @@ -348,7 +376,7 @@ software errors. Conclusion; General Remarks --------------------------- -The way those callbacks are called is platform policy. A platform with +The way the callbacks are called is platform policy. A platform with no slot reset capability may want to just "ignore" drivers that can't recover (disconnect them) and try to let other cards on the same segment recover. Keep in mind that in most real life cases, though, there will @@ -361,8 +389,8 @@ That is, the recovery API only requires that: - There is no guarantee that interrupt delivery can proceed from any device on the segment starting from the error detection and until the -resume callback is sent, at which point interrupts are expected to be -fully operational. +slot_reset callback is called, at which point interrupts are expected +to be fully operational. - There is no guarantee that interrupt delivery is stopped, that is, a driver that gets an interrupt after detecting an error, or that detects @@ -381,16 +409,23 @@ anyway :) >>> Implementation details for the powerpc platform are discussed in >>> the file Documentation/powerpc/eeh-pci-error-recovery.txt ->>> As of this writing, there are six device drivers with patches ->>> implementing error recovery. Not all of these patches are in +>>> As of this writing, there is a growing list of device drivers with +>>> patches implementing error recovery. Not all of these patches are in >>> mainline yet. These may be used as "examples": >>> ->>> drivers/scsi/ipr.c ->>> drivers/scsi/sym53cxx_2 +>>> drivers/scsi/ipr +>>> drivers/scsi/sym53c8xx_2 +>>> drivers/scsi/qla2xxx +>>> drivers/scsi/lpfc +>>> drivers/next/bnx2.c >>> drivers/next/e100.c >>> drivers/net/e1000 +>>> drivers/net/e1000e >>> drivers/net/ixgb +>>> drivers/net/ixgbe +>>> drivers/net/cxgb3 >>> drivers/net/s2io.c +>>> drivers/net/qlge The End ------- diff --git a/Documentation/RCU/RTFP.txt b/Documentation/RCU/RTFP.txt index 9f711d2df91b..d2b85237c76e 100644 --- a/Documentation/RCU/RTFP.txt +++ b/Documentation/RCU/RTFP.txt @@ -743,3 +743,80 @@ Revised: RCU, realtime RCU, sleepable RCU, performance. " } + +@article{PaulEMcKenney2008RCUOSR +,author="Paul E. McKenney and Jonathan Walpole" +,title="Introducing technology into the {Linux} kernel: a case study" +,Year="2008" +,journal="SIGOPS Oper. Syst. Rev." +,volume="42" +,number="5" +,pages="4--17" +,issn="0163-5980" +,doi={http://doi.acm.org/10.1145/1400097.1400099} +,publisher="ACM" +,address="New York, NY, USA" +,annotation={ + Linux changed RCU to a far greater degree than RCU has changed Linux. +} +} + +@unpublished{PaulEMcKenney2008HierarchicalRCU +,Author="Paul E. McKenney" +,Title="Hierarchical {RCU}" +,month="November" +,day="3" +,year="2008" +,note="Available: +\url{http://lwn.net/Articles/305782/} +[Viewed November 6, 2008]" +,annotation=" + RCU with combining-tree-based grace-period detection, + permitting it to handle thousands of CPUs. +" +} + +@conference{PaulEMcKenney2009MaliciousURCU +,Author="Paul E. McKenney" +,Title="Using a Malicious User-Level {RCU} to Torture {RCU}-Based Algorithms" +,Booktitle="linux.conf.au 2009" +,month="January" +,year="2009" +,address="Hobart, Australia" +,note="Available: +\url{http://www.rdrop.com/users/paulmck/RCU/urcutorture.2009.01.22a.pdf} +[Viewed February 2, 2009]" +,annotation=" + Realtime RCU and torture-testing RCU uses. +" +} + +@unpublished{MathieuDesnoyers2009URCU +,Author="Mathieu Desnoyers" +,Title="[{RFC} git tree] Userspace {RCU} (urcu) for {Linux}" +,month="February" +,day="5" +,year="2009" +,note="Available: +\url{http://lkml.org/lkml/2009/2/5/572} +\url{git://lttng.org/userspace-rcu.git} +[Viewed February 20, 2009]" +,annotation=" + Mathieu Desnoyers's user-space RCU implementation. + git://lttng.org/userspace-rcu.git +" +} + +@unpublished{PaulEMcKenney2009BloatWatchRCU +,Author="Paul E. McKenney" +,Title="{RCU}: The {Bloatwatch} Edition" +,month="March" +,day="17" +,year="2009" +,note="Available: +\url{http://lwn.net/Articles/323929/} +[Viewed March 20, 2009]" +,annotation=" + Uniprocessor assumptions allow simplified RCU implementation. +" +} diff --git a/Documentation/RCU/UP.txt b/Documentation/RCU/UP.txt index aab4a9ec3931..90ec5341ee98 100644 --- a/Documentation/RCU/UP.txt +++ b/Documentation/RCU/UP.txt @@ -2,14 +2,13 @@ RCU on Uniprocessor Systems A common misconception is that, on UP systems, the call_rcu() primitive -may immediately invoke its function, and that the synchronize_rcu() -primitive may return immediately. The basis of this misconception +may immediately invoke its function. The basis of this misconception is that since there is only one CPU, it should not be necessary to wait for anything else to get done, since there are no other CPUs for anything else to be happening on. Although this approach will -sort- -of- work a surprising amount of the time, it is a very bad idea in general. -This document presents three examples that demonstrate exactly how bad an -idea this is. +This document presents three examples that demonstrate exactly how bad +an idea this is. Example 1: softirq Suicide @@ -82,11 +81,18 @@ Quick Quiz #2: What locking restriction must RCU callbacks respect? Summary -Permitting call_rcu() to immediately invoke its arguments or permitting -synchronize_rcu() to immediately return breaks RCU, even on a UP system. -So do not do it! Even on a UP system, the RCU infrastructure -must- -respect grace periods, and -must- invoke callbacks from a known environment -in which no locks are held. +Permitting call_rcu() to immediately invoke its arguments breaks RCU, +even on a UP system. So do not do it! Even on a UP system, the RCU +infrastructure -must- respect grace periods, and -must- invoke callbacks +from a known environment in which no locks are held. + +It -is- safe for synchronize_sched() and synchronize_rcu_bh() to return +immediately on an UP system. It is also safe for synchronize_rcu() +to return immediately on UP systems, except when running preemptable +RCU. + +Quick Quiz #3: Why can't synchronize_rcu() return immediately on + UP systems running preemptable RCU? Answer to Quick Quiz #1: @@ -117,3 +123,13 @@ Answer to Quick Quiz #2: callbacks acquire locks directly. However, a great many RCU callbacks do acquire locks -indirectly-, for example, via the kfree() primitive. + +Answer to Quick Quiz #3: + Why can't synchronize_rcu() return immediately on UP systems + running preemptable RCU? + + Because some other task might have been preempted in the middle + of an RCU read-side critical section. If synchronize_rcu() + simply immediately returned, it would prematurely signal the + end of the grace period, which would come as a nasty shock to + that other thread when it started running again. diff --git a/Documentation/RCU/checklist.txt b/Documentation/RCU/checklist.txt index accfe2f5247d..51525a30e8b4 100644 --- a/Documentation/RCU/checklist.txt +++ b/Documentation/RCU/checklist.txt @@ -11,7 +11,10 @@ over a rather long period of time, but improvements are always welcome! structure is updated more than about 10% of the time, then you should strongly consider some other approach, unless detailed performance measurements show that RCU is nonetheless - the right tool for the job. + the right tool for the job. Yes, you might think of RCU + as simply cutting overhead off of the readers and imposing it + on the writers. That is exactly why normal uses of RCU will + do much more reading than updating. Another exception is where performance is not an issue, and RCU provides a simpler implementation. An example of this situation @@ -240,10 +243,11 @@ over a rather long period of time, but improvements are always welcome! instead need to use synchronize_irq() or synchronize_sched(). 12. Any lock acquired by an RCU callback must be acquired elsewhere - with irq disabled, e.g., via spin_lock_irqsave(). Failing to - disable irq on a given acquisition of that lock will result in - deadlock as soon as the RCU callback happens to interrupt that - acquisition's critical section. + with softirq disabled, e.g., via spin_lock_irqsave(), + spin_lock_bh(), etc. Failing to disable irq on a given + acquisition of that lock will result in deadlock as soon as the + RCU callback happens to interrupt that acquisition's critical + section. 13. RCU callbacks can be and are executed in parallel. In many cases, the callback code simply wrappers around kfree(), so that this @@ -310,3 +314,9 @@ over a rather long period of time, but improvements are always welcome! Because these primitives only wait for pre-existing readers, it is the caller's responsibility to guarantee safety to any subsequent readers. + +16. The various RCU read-side primitives do -not- contain memory + barriers. The CPU (and in some cases, the compiler) is free + to reorder code into and out of RCU read-side critical sections. + It is the responsibility of the RCU update-side primitives to + deal with this. diff --git a/Documentation/RCU/rcu.txt b/Documentation/RCU/rcu.txt index 7aa2002ade77..2a23523ce471 100644 --- a/Documentation/RCU/rcu.txt +++ b/Documentation/RCU/rcu.txt @@ -36,7 +36,7 @@ o How can the updater tell when a grace period has completed executed in user mode, or executed in the idle loop, we can safely free up that item. - Preemptible variants of RCU (CONFIG_PREEMPT_RCU) get the + Preemptible variants of RCU (CONFIG_TREE_PREEMPT_RCU) get the same effect, but require that the readers manipulate CPU-local counters. These counters allow limited types of blocking within RCU read-side critical sections. SRCU also uses @@ -79,10 +79,10 @@ o I hear that RCU is patented? What is with that? o I hear that RCU needs work in order to support realtime kernels? This work is largely completed. Realtime-friendly RCU can be - enabled via the CONFIG_PREEMPT_RCU kernel configuration parameter. - However, work is in progress for enabling priority boosting of - preempted RCU read-side critical sections. This is needed if you - have CPU-bound realtime threads. + enabled via the CONFIG_TREE_PREEMPT_RCU kernel configuration + parameter. However, work is in progress for enabling priority + boosting of preempted RCU read-side critical sections. This is + needed if you have CPU-bound realtime threads. o Where can I find more information on RCU? diff --git a/Documentation/RCU/rcubarrier.txt b/Documentation/RCU/rcubarrier.txt index 909602d409bb..e439a0edee22 100644 --- a/Documentation/RCU/rcubarrier.txt +++ b/Documentation/RCU/rcubarrier.txt @@ -170,6 +170,13 @@ module invokes call_rcu() from timers, you will need to first cancel all the timers, and only then invoke rcu_barrier() to wait for any remaining RCU callbacks to complete. +Of course, if you module uses call_rcu_bh(), you will need to invoke +rcu_barrier_bh() before unloading. Similarly, if your module uses +call_rcu_sched(), you will need to invoke rcu_barrier_sched() before +unloading. If your module uses call_rcu(), call_rcu_bh(), -and- +call_rcu_sched(), then you will need to invoke each of rcu_barrier(), +rcu_barrier_bh(), and rcu_barrier_sched(). + Implementing rcu_barrier() diff --git a/Documentation/RCU/torture.txt b/Documentation/RCU/torture.txt index a342b6e1cc10..9dba3bb90e60 100644 --- a/Documentation/RCU/torture.txt +++ b/Documentation/RCU/torture.txt @@ -76,8 +76,10 @@ torture_type The type of RCU to test: "rcu" for the rcu_read_lock() API, "rcu_sync" for rcu_read_lock() with synchronous reclamation, "rcu_bh" for the rcu_read_lock_bh() API, "rcu_bh_sync" for rcu_read_lock_bh() with synchronous reclamation, "srcu" for - the "srcu_read_lock()" API, and "sched" for the use of - preempt_disable() together with synchronize_sched(). + the "srcu_read_lock()" API, "sched" for the use of + preempt_disable() together with synchronize_sched(), + and "sched_expedited" for the use of preempt_disable() + with synchronize_sched_expedited(). verbose Enable debug printk()s. Default is disabled. @@ -162,6 +164,23 @@ of the "old" and "current" counters for the corresponding CPU. The "idx" value maps the "old" and "current" values to the underlying array, and is useful for debugging. +Similarly, sched_expedited RCU provides the following: + + sched_expedited-torture: rtc: d0000000016c1880 ver: 1090796 tfle: 0 rta: 1090796 rtaf: 0 rtf: 1090787 rtmbe: 0 nt: 27713319 + sched_expedited-torture: Reader Pipe: 12660320201 95875 0 0 0 0 0 0 0 0 0 + sched_expedited-torture: Reader Batch: 12660424885 0 0 0 0 0 0 0 0 0 0 + sched_expedited-torture: Free-Block Circulation: 1090795 1090795 1090794 1090793 1090792 1090791 1090790 1090789 1090788 1090787 0 + state: -1 / 0:0 3:0 4:0 + +As before, the first four lines are similar to those for RCU. +The last line shows the task-migration state. The first number is +-1 if synchronize_sched_expedited() is idle, -2 if in the process of +posting wakeups to the migration kthreads, and N when waiting on CPU N. +Each of the colon-separated fields following the "/" is a CPU:state pair. +Valid states are "0" for idle, "1" for waiting for quiescent state, +"2" for passed through quiescent state, and "3" when a race with a +CPU-hotplug event forces use of the synchronize_sched() primitive. + USAGE diff --git a/Documentation/RCU/trace.txt b/Documentation/RCU/trace.txt index 02cced183b2d..8608fd85e921 100644 --- a/Documentation/RCU/trace.txt +++ b/Documentation/RCU/trace.txt @@ -1,185 +1,10 @@ CONFIG_RCU_TRACE debugfs Files and Formats -The rcupreempt and rcutree implementations of RCU provide debugfs trace -output that summarizes counters and state. This information is useful for -debugging RCU itself, and can sometimes also help to debug abuses of RCU. -Note that the rcuclassic implementation of RCU does not provide debugfs -trace output. - -The following sections describe the debugfs files and formats for -preemptable RCU (rcupreempt) and hierarchical RCU (rcutree). - - -Preemptable RCU debugfs Files and Formats - -This implementation of RCU provides three debugfs files under the -top-level directory RCU: rcu/rcuctrs (which displays the per-CPU -counters used by preemptable RCU) rcu/rcugp (which displays grace-period -counters), and rcu/rcustats (which internal counters for debugging RCU). - -The output of "cat rcu/rcuctrs" looks as follows: - -CPU last cur F M - 0 5 -5 0 0 - 1 -1 0 0 0 - 2 0 1 0 0 - 3 0 1 0 0 - 4 0 1 0 0 - 5 0 1 0 0 - 6 0 2 0 0 - 7 0 -1 0 0 - 8 0 1 0 0 -ggp = 26226, state = waitzero - -The per-CPU fields are as follows: - -o "CPU" gives the CPU number. Offline CPUs are not displayed. - -o "last" gives the value of the counter that is being decremented - for the current grace period phase. In the example above, - the counters sum to 4, indicating that there are still four - RCU read-side critical sections still running that started - before the last counter flip. - -o "cur" gives the value of the counter that is currently being - both incremented (by rcu_read_lock()) and decremented (by - rcu_read_unlock()). In the example above, the counters sum to - 1, indicating that there is only one RCU read-side critical section - still running that started after the last counter flip. - -o "F" indicates whether RCU is waiting for this CPU to acknowledge - a counter flip. In the above example, RCU is not waiting on any, - which is consistent with the state being "waitzero" rather than - "waitack". - -o "M" indicates whether RCU is waiting for this CPU to execute a - memory barrier. In the above example, RCU is not waiting on any, - which is consistent with the state being "waitzero" rather than - "waitmb". - -o "ggp" is the global grace-period counter. - -o "state" is the RCU state, which can be one of the following: - - o "idle": there is no grace period in progress. - - o "waitack": RCU just incremented the global grace-period - counter, which has the effect of reversing the roles of - the "last" and "cur" counters above, and is waiting for - all the CPUs to acknowledge the flip. Once the flip has - been acknowledged, CPUs will no longer be incrementing - what are now the "last" counters, so that their sum will - decrease monotonically down to zero. - - o "waitzero": RCU is waiting for the sum of the "last" counters - to decrease to zero. - - o "waitmb": RCU is waiting for each CPU to execute a memory - barrier, which ensures that instructions from a given CPU's - last RCU read-side critical section cannot be reordered - with instructions following the memory-barrier instruction. - -The output of "cat rcu/rcugp" looks as follows: - -oldggp=48870 newggp=48873 - -Note that reading from this file provokes a synchronize_rcu(). The -"oldggp" value is that of "ggp" from rcu/rcuctrs above, taken before -executing the synchronize_rcu(), and the "newggp" value is also the -"ggp" value, but taken after the synchronize_rcu() command returns. - - -The output of "cat rcu/rcugp" looks as follows: - -na=1337955 nl=40 wa=1337915 wl=44 da=1337871 dl=0 dr=1337871 di=1337871 -1=50989 e1=6138 i1=49722 ie1=82 g1=49640 a1=315203 ae1=265563 a2=49640 -z1=1401244 ze1=1351605 z2=49639 m1=5661253 me1=5611614 m2=49639 - -These are counters tracking internal preemptable-RCU events, however, -some of them may be useful for debugging algorithms using RCU. In -particular, the "nl", "wl", and "dl" values track the number of RCU -callbacks in various states. The fields are as follows: - -o "na" is the total number of RCU callbacks that have been enqueued - since boot. - -o "nl" is the number of RCU callbacks waiting for the previous - grace period to end so that they can start waiting on the next - grace period. - -o "wa" is the total number of RCU callbacks that have started waiting - for a grace period since boot. "na" should be roughly equal to - "nl" plus "wa". - -o "wl" is the number of RCU callbacks currently waiting for their - grace period to end. - -o "da" is the total number of RCU callbacks whose grace periods - have completed since boot. "wa" should be roughly equal to - "wl" plus "da". - -o "dr" is the total number of RCU callbacks that have been removed - from the list of callbacks ready to invoke. "dr" should be roughly - equal to "da". - -o "di" is the total number of RCU callbacks that have been invoked - since boot. "di" should be roughly equal to "da", though some - early versions of preemptable RCU had a bug so that only the - last CPU's count of invocations was displayed, rather than the - sum of all CPU's counts. - -o "1" is the number of calls to rcu_try_flip(). This should be - roughly equal to the sum of "e1", "i1", "a1", "z1", and "m1" - described below. In other words, the number of times that - the state machine is visited should be equal to the sum of the - number of times that each state is visited plus the number of - times that the state-machine lock acquisition failed. - -o "e1" is the number of times that rcu_try_flip() was unable to - acquire the fliplock. - -o "i1" is the number of calls to rcu_try_flip_idle(). - -o "ie1" is the number of times rcu_try_flip_idle() exited early - due to the calling CPU having no work for RCU. - -o "g1" is the number of times that rcu_try_flip_idle() decided - to start a new grace period. "i1" should be roughly equal to - "ie1" plus "g1". - -o "a1" is the number of calls to rcu_try_flip_waitack(). - -o "ae1" is the number of times that rcu_try_flip_waitack() found - that at least one CPU had not yet acknowledge the new grace period - (AKA "counter flip"). - -o "a2" is the number of time rcu_try_flip_waitack() found that - all CPUs had acknowledged. "a1" should be roughly equal to - "ae1" plus "a2". (This particular output was collected on - a 128-CPU machine, hence the smaller-than-usual fraction of - calls to rcu_try_flip_waitack() finding all CPUs having already - acknowledged.) - -o "z1" is the number of calls to rcu_try_flip_waitzero(). - -o "ze1" is the number of times that rcu_try_flip_waitzero() found - that not all of the old RCU read-side critical sections had - completed. - -o "z2" is the number of times that rcu_try_flip_waitzero() finds - the sum of the counters equal to zero, in other words, that - all of the old RCU read-side critical sections had completed. - The value of "z1" should be roughly equal to "ze1" plus - "z2". - -o "m1" is the number of calls to rcu_try_flip_waitmb(). - -o "me1" is the number of times that rcu_try_flip_waitmb() finds - that at least one CPU has not yet executed a memory barrier. - -o "m2" is the number of times that rcu_try_flip_waitmb() finds that - all CPUs have executed a memory barrier. +The rcutree implementation of RCU provides debugfs trace output that +summarizes counters and state. This information is useful for debugging +RCU itself, and can sometimes also help to debug abuses of RCU. +The following sections describe the debugfs files and formats. Hierarchical RCU debugfs Files and Formats @@ -191,8 +16,7 @@ rcu/rcuhier (which displays the struct rcu_node hierarchy). The output of "cat rcu/rcudata" looks as follows: -rcu: -rcu: +rcu_sched: 0 c=17829 g=17829 pq=1 pqc=17829 qp=0 dt=10951/1 dn=0 df=1101 of=0 ri=36 ql=0 b=10 1 c=17829 g=17829 pq=1 pqc=17829 qp=0 dt=16117/1 dn=0 df=1015 of=0 ri=0 ql=0 b=10 2 c=17829 g=17829 pq=1 pqc=17829 qp=0 dt=1445/1 dn=0 df=1839 of=0 ri=0 ql=0 b=10 @@ -211,9 +35,10 @@ rcu_bh: 6 c=-275 g=-275 pq=1 pqc=-275 qp=0 dt=859/1 dn=0 df=15 of=0 ri=0 ql=0 b=10 7 c=-275 g=-275 pq=1 pqc=-275 qp=0 dt=3761/1 dn=0 df=15 of=0 ri=0 ql=0 b=10 -The first section lists the rcu_data structures for rcu, the second for -rcu_bh. Each section has one line per CPU, or eight for this 8-CPU system. -The fields are as follows: +The first section lists the rcu_data structures for rcu_sched, the second +for rcu_bh. Note that CONFIG_TREE_PREEMPT_RCU kernels will have an +additional section for rcu_preempt. Each section has one line per CPU, +or eight for this 8-CPU system. The fields are as follows: o The number at the beginning of each line is the CPU number. CPUs numbers followed by an exclamation mark are offline, @@ -224,9 +49,9 @@ o The number at the beginning of each line is the CPU number. o "c" is the count of grace periods that this CPU believes have completed. CPUs in dynticks idle mode may lag quite a ways - behind, for example, CPU 4 under "rcu" above, which has slept - through the past 25 RCU grace periods. It is not unusual to - see CPUs lagging by thousands of grace periods. + behind, for example, CPU 4 under "rcu_sched" above, which has + slept through the past 25 RCU grace periods. It is not unusual + to see CPUs lagging by thousands of grace periods. o "g" is the count of grace periods that this CPU believes have started. Again, CPUs in dynticks idle mode may lag behind. @@ -306,11 +131,13 @@ comma-separated-variable spreadsheet format. The output of "cat rcu/rcugp" looks as follows: -rcu: completed=33062 gpnum=33063 +rcu_sched: completed=33062 gpnum=33063 rcu_bh: completed=464 gpnum=464 -Again, this output is for both "rcu" and "rcu_bh". The fields are -taken from the rcu_state structure, and are as follows: +Again, this output is for both "rcu_sched" and "rcu_bh". Note that +kernels built with CONFIG_TREE_PREEMPT_RCU will have an additional +"rcu_preempt" line. The fields are taken from the rcu_state structure, +and are as follows: o "completed" is the number of grace periods that have completed. It is comparable to the "c" field from rcu/rcudata in that a @@ -325,23 +152,24 @@ o "gpnum" is the number of grace periods that have started. It is If these two fields are equal (as they are for "rcu_bh" above), then there is no grace period in progress, in other words, RCU is idle. On the other hand, if the two fields differ (as they - do for "rcu" above), then an RCU grace period is in progress. + do for "rcu_sched" above), then an RCU grace period is in progress. The output of "cat rcu/rcuhier" looks as follows, with very long lines: -c=6902 g=6903 s=2 jfq=3 j=72c7 nfqs=13142/nfqsng=0(13142) fqlh=6 -1/1 0:127 ^0 -3/3 0:35 ^0 0/0 36:71 ^1 0/0 72:107 ^2 0/0 108:127 ^3 -3/3f 0:5 ^0 2/3 6:11 ^1 0/0 12:17 ^2 0/0 18:23 ^3 0/0 24:29 ^4 0/0 30:35 ^5 0/0 36:41 ^0 0/0 42:47 ^1 0/0 48:53 ^2 0/0 54:59 ^3 0/0 60:65 ^4 0/0 66:71 ^5 0/0 72:77 ^0 0/0 78:83 ^1 0/0 84:89 ^2 0/0 90:95 ^3 0/0 96:101 ^4 0/0 102:107 ^5 0/0 108:113 ^0 0/0 114:119 ^1 0/0 120:125 ^2 0/0 126:127 ^3 +c=6902 g=6903 s=2 jfq=3 j=72c7 nfqs=13142/nfqsng=0(13142) fqlh=6 oqlen=0 +1/1 .>. 0:127 ^0 +3/3 .>. 0:35 ^0 0/0 .>. 36:71 ^1 0/0 .>. 72:107 ^2 0/0 .>. 108:127 ^3 +3/3f .>. 0:5 ^0 2/3 .>. 6:11 ^1 0/0 .>. 12:17 ^2 0/0 .>. 18:23 ^3 0/0 .>. 24:29 ^4 0/0 .>. 30:35 ^5 0/0 .>. 36:41 ^0 0/0 .>. 42:47 ^1 0/0 .>. 48:53 ^2 0/0 .>. 54:59 ^3 0/0 .>. 60:65 ^4 0/0 .>. 66:71 ^5 0/0 .>. 72:77 ^0 0/0 .>. 78:83 ^1 0/0 .>. 84:89 ^2 0/0 .>. 90:95 ^3 0/0 .>. 96:101 ^4 0/0 .>. 102:107 ^5 0/0 .>. 108:113 ^0 0/0 .>. 114:119 ^1 0/0 .>. 120:125 ^2 0/0 .>. 126:127 ^3 rcu_bh: -c=-226 g=-226 s=1 jfq=-5701 j=72c7 nfqs=88/nfqsng=0(88) fqlh=0 -0/1 0:127 ^0 -0/3 0:35 ^0 0/0 36:71 ^1 0/0 72:107 ^2 0/0 108:127 ^3 -0/3f 0:5 ^0 0/3 6:11 ^1 0/0 12:17 ^2 0/0 18:23 ^3 0/0 24:29 ^4 0/0 30:35 ^5 0/0 36:41 ^0 0/0 42:47 ^1 0/0 48:53 ^2 0/0 54:59 ^3 0/0 60:65 ^4 0/0 66:71 ^5 0/0 72:77 ^0 0/0 78:83 ^1 0/0 84:89 ^2 0/0 90:95 ^3 0/0 96:101 ^4 0/0 102:107 ^5 0/0 108:113 ^0 0/0 114:119 ^1 0/0 120:125 ^2 0/0 126:127 ^3 +c=-226 g=-226 s=1 jfq=-5701 j=72c7 nfqs=88/nfqsng=0(88) fqlh=0 oqlen=0 +0/1 .>. 0:127 ^0 +0/3 .>. 0:35 ^0 0/0 .>. 36:71 ^1 0/0 .>. 72:107 ^2 0/0 .>. 108:127 ^3 +0/3f .>. 0:5 ^0 0/3 .>. 6:11 ^1 0/0 .>. 12:17 ^2 0/0 .>. 18:23 ^3 0/0 .>. 24:29 ^4 0/0 .>. 30:35 ^5 0/0 .>. 36:41 ^0 0/0 .>. 42:47 ^1 0/0 .>. 48:53 ^2 0/0 .>. 54:59 ^3 0/0 .>. 60:65 ^4 0/0 .>. 66:71 ^5 0/0 .>. 72:77 ^0 0/0 .>. 78:83 ^1 0/0 .>. 84:89 ^2 0/0 .>. 90:95 ^3 0/0 .>. 96:101 ^4 0/0 .>. 102:107 ^5 0/0 .>. 108:113 ^0 0/0 .>. 114:119 ^1 0/0 .>. 120:125 ^2 0/0 .>. 126:127 ^3 -This is once again split into "rcu" and "rcu_bh" portions. The fields are -as follows: +This is once again split into "rcu_sched" and "rcu_bh" portions, +and CONFIG_TREE_PREEMPT_RCU kernels will again have an additional +"rcu_preempt" section. The fields are as follows: o "c" is exactly the same as "completed" under rcu/rcugp. @@ -373,6 +201,11 @@ o "fqlh" is the number of calls to force_quiescent_state() that exited immediately (without even being counted in nfqs above) due to contention on ->fqslock. +o "oqlen" is the number of callbacks on the "orphan" callback + list. RCU callbacks are placed on this list by CPUs going + offline, and are "adopted" either by the CPU helping the outgoing + CPU or by the next rcu_barrier*() call, whichever comes first. + o Each element of the form "1/1 0:127 ^0" represents one struct rcu_node. Each line represents one level of the hierarchy, from root to leaves. It is best to think of the rcu_data structures @@ -380,7 +213,7 @@ o Each element of the form "1/1 0:127 ^0" represents one struct might be either one, two, or three levels of rcu_node structures, depending on the relationship between CONFIG_RCU_FANOUT and CONFIG_NR_CPUS. - + o The numbers separated by the "/" are the qsmask followed by the qsmaskinit. The qsmask will have one bit set for each entity in the next lower level that @@ -390,10 +223,19 @@ o Each element of the form "1/1 0:127 ^0" represents one struct The value of qsmaskinit is assigned to that of qsmask at the beginning of each grace period. - For example, for "rcu", the qsmask of the first entry - of the lowest level is 0x14, meaning that we are still - waiting for CPUs 2 and 4 to check in for the current - grace period. + For example, for "rcu_sched", the qsmask of the first + entry of the lowest level is 0x14, meaning that we + are still waiting for CPUs 2 and 4 to check in for the + current grace period. + + o The characters separated by the ">" indicate the state + of the blocked-tasks lists. A "T" preceding the ">" + indicates that at least one task blocked in an RCU + read-side critical section blocks the current grace + period, while a "." preceding the ">" indicates otherwise. + The character following the ">" indicates similarly for + the next grace period. A "T" should appear in this + field only for rcu-preempt. o The numbers separated by the ":" are the range of CPUs served by this struct rcu_node. This can be helpful @@ -413,7 +255,7 @@ o Each element of the form "1/1 0:127 ^0" represents one struct The output of "cat rcu/rcu_pending" looks as follows: -rcu: +rcu_sched: 0 np=255892 qsp=53936 cbr=0 cng=14417 gpc=10033 gps=24320 nf=6445 nn=146741 1 np=261224 qsp=54638 cbr=0 cng=25723 gpc=16310 gps=2849 nf=5912 nn=155792 2 np=237496 qsp=49664 cbr=0 cng=2762 gpc=45478 gps=1762 nf=1201 nn=136629 @@ -432,8 +274,9 @@ rcu_bh: 6 np=120834 qsp=9902 cbr=0 cng=0 gpc=6 gps=3 nf=2 nn=110921 7 np=144888 qsp=26336 cbr=0 cng=0 gpc=8 gps=2 nf=0 nn=118542 -As always, this is once again split into "rcu" and "rcu_bh" portions. -The fields are as follows: +As always, this is once again split into "rcu_sched" and "rcu_bh" +portions, with CONFIG_TREE_PREEMPT_RCU kernels having an additional +"rcu_preempt" section. The fields are as follows: o "np" is the number of times that __rcu_pending() has been invoked for the corresponding flavor of RCU. diff --git a/Documentation/RCU/whatisRCU.txt b/Documentation/RCU/whatisRCU.txt index 96170824a717..d542ca243b80 100644 --- a/Documentation/RCU/whatisRCU.txt +++ b/Documentation/RCU/whatisRCU.txt @@ -136,10 +136,10 @@ rcu_read_lock() Used by a reader to inform the reclaimer that the reader is entering an RCU read-side critical section. It is illegal to block while in an RCU read-side critical section, though - kernels built with CONFIG_PREEMPT_RCU can preempt RCU read-side - critical sections. Any RCU-protected data structure accessed - during an RCU read-side critical section is guaranteed to remain - unreclaimed for the full duration of that critical section. + kernels built with CONFIG_TREE_PREEMPT_RCU can preempt RCU + read-side critical sections. Any RCU-protected data structure + accessed during an RCU read-side critical section is guaranteed to + remain unreclaimed for the full duration of that critical section. Reference counts may be used in conjunction with RCU to maintain longer-term references to data structures. @@ -785,6 +785,7 @@ RCU pointer/list traversal: rcu_dereference list_for_each_entry_rcu hlist_for_each_entry_rcu + hlist_nulls_for_each_entry_rcu list_for_each_continue_rcu (to be deprecated in favor of new list_for_each_entry_continue_rcu) @@ -807,26 +808,33 @@ RCU: Critical sections Grace period Barrier rcu_read_lock synchronize_net rcu_barrier rcu_read_unlock synchronize_rcu + synchronize_rcu_expedited call_rcu bh: Critical sections Grace period Barrier rcu_read_lock_bh call_rcu_bh rcu_barrier_bh - rcu_read_unlock_bh + rcu_read_unlock_bh synchronize_rcu_bh + synchronize_rcu_bh_expedited sched: Critical sections Grace period Barrier - [preempt_disable] synchronize_sched rcu_barrier_sched - [and friends] call_rcu_sched + rcu_read_lock_sched synchronize_sched rcu_barrier_sched + rcu_read_unlock_sched call_rcu_sched + [preempt_disable] synchronize_sched_expedited + [and friends] SRCU: Critical sections Grace period Barrier srcu_read_lock synchronize_srcu N/A - srcu_read_unlock + srcu_read_unlock synchronize_srcu_expedited +SRCU: Initialization/cleanup + init_srcu_struct + cleanup_srcu_struct See the comment headers in the source code (or the docbook generated from them) for more information. diff --git a/Documentation/SubmitChecklist b/Documentation/SubmitChecklist index 78a9168ff377..1053a56be3b1 100644 --- a/Documentation/SubmitChecklist +++ b/Documentation/SubmitChecklist @@ -15,7 +15,7 @@ kernel patches. 2: Passes allnoconfig, allmodconfig 3: Builds on multiple CPU architectures by using local cross-compile tools - or something like PLM at OSDL. + or some other build farm. 4: ppc64 is a good architecture for cross-compilation checking because it tends to use `unsigned long' for 64-bit quantities. @@ -88,3 +88,6 @@ kernel patches. 24: All memory barriers {e.g., barrier(), rmb(), wmb()} need a comment in the source code that explains the logic of what they are doing and why. + +25: If any ioctl's are added by the patch, then also update + Documentation/ioctl/ioctl-number.txt. diff --git a/Documentation/SubmittingPatches b/Documentation/SubmittingPatches index 5c555a8b39e5..72651f788f4e 100644 --- a/Documentation/SubmittingPatches +++ b/Documentation/SubmittingPatches @@ -183,7 +183,7 @@ the MAN-PAGES maintainer (as listed in the MAINTAINERS file) a man-pages patch, or at least a notification of the change, so that some information makes its way into the manual pages. -Even if the maintainer did not respond in step #4, make sure to ALWAYS +Even if the maintainer did not respond in step #5, make sure to ALWAYS copy the maintainer when you change their code. For small patches you may want to CC the Trivial Patch Monkey @@ -232,7 +232,7 @@ your e-mail client so that it sends your patches untouched. When sending patches to Linus, always follow step #7. Large changes are not appropriate for mailing lists, and some -maintainers. If your patch, uncompressed, exceeds 40 kB in size, +maintainers. If your patch, uncompressed, exceeds 300 kB in size, it is preferred that you store your patch on an Internet-accessible server, and provide instead a URL (link) pointing to your patch. diff --git a/Documentation/accounting/getdelays.c b/Documentation/accounting/getdelays.c index aa73e72fd793..6e25c2659e0a 100644 --- a/Documentation/accounting/getdelays.c +++ b/Documentation/accounting/getdelays.c @@ -116,7 +116,7 @@ error: } -int send_cmd(int sd, __u16 nlmsg_type, __u32 nlmsg_pid, +static int send_cmd(int sd, __u16 nlmsg_type, __u32 nlmsg_pid, __u8 genl_cmd, __u16 nla_type, void *nla_data, int nla_len) { @@ -160,7 +160,7 @@ int send_cmd(int sd, __u16 nlmsg_type, __u32 nlmsg_pid, * Probe the controller in genetlink to find the family id * for the TASKSTATS family */ -int get_family_id(int sd) +static int get_family_id(int sd) { struct { struct nlmsghdr n; @@ -190,7 +190,7 @@ int get_family_id(int sd) return id; } -void print_delayacct(struct taskstats *t) +static void print_delayacct(struct taskstats *t) { printf("\n\nCPU %15s%15s%15s%15s\n" " %15llu%15llu%15llu%15llu\n" @@ -216,7 +216,7 @@ void print_delayacct(struct taskstats *t) (unsigned long long)t->freepages_delay_total); } -void task_context_switch_counts(struct taskstats *t) +static void task_context_switch_counts(struct taskstats *t) { printf("\n\nTask %15s%15s\n" " %15llu%15llu\n", @@ -224,7 +224,7 @@ void task_context_switch_counts(struct taskstats *t) (unsigned long long)t->nvcsw, (unsigned long long)t->nivcsw); } -void print_cgroupstats(struct cgroupstats *c) +static void print_cgroupstats(struct cgroupstats *c) { printf("sleeping %llu, blocked %llu, running %llu, stopped %llu, " "uninterruptible %llu\n", (unsigned long long)c->nr_sleeping, @@ -235,7 +235,7 @@ void print_cgroupstats(struct cgroupstats *c) } -void print_ioacct(struct taskstats *t) +static void print_ioacct(struct taskstats *t) { printf("%s: read=%llu, write=%llu, cancelled_write=%llu\n", t->ac_comm, diff --git a/Documentation/acpi/method-customizing.txt b/Documentation/acpi/method-customizing.txt new file mode 100644 index 000000000000..e628cd23ca80 --- /dev/null +++ b/Documentation/acpi/method-customizing.txt @@ -0,0 +1,66 @@ +Linux ACPI Custom Control Method How To +======================================= + +Written by Zhang Rui <rui.zhang@intel.com> + + +Linux supports customizing ACPI control methods at runtime. + +Users can use this to +1. override an existing method which may not work correctly, + or just for debugging purposes. +2. insert a completely new method in order to create a missing + method such as _OFF, _ON, _STA, _INI, etc. +For these cases, it is far simpler to dynamically install a single +control method rather than override the entire DSDT, because kernel +rebuild/reboot is not needed and test result can be got in minutes. + +Note: Only ACPI METHOD can be overridden, any other object types like + "Device", "OperationRegion", are not recognized. +Note: The same ACPI control method can be overridden for many times, + and it's always the latest one that used by Linux/kernel. + +1. override an existing method + a) get the ACPI table via ACPI sysfs I/F. e.g. to get the DSDT, + just run "cat /sys/firmware/acpi/tables/DSDT > /tmp/dsdt.dat" + b) disassemble the table by running "iasl -d dsdt.dat". + c) rewrite the ASL code of the method and save it in a new file, + d) package the new file (psr.asl) to an ACPI table format. + Here is an example of a customized \_SB._AC._PSR method, + + DefinitionBlock ("", "SSDT", 1, "", "", 0x20080715) + { + External (ACON) + + Method (\_SB_.AC._PSR, 0, NotSerialized) + { + Store ("In AC _PSR", Debug) + Return (ACON) + } + } + Note that the full pathname of the method in ACPI namespace + should be used. + And remember to use "External" to declare external objects. + e) assemble the file to generate the AML code of the method. + e.g. "iasl psr.asl" (psr.aml is generated as a result) + f) mount debugfs by "mount -t debugfs none /sys/kernel/debug" + g) override the old method via the debugfs by running + "cat /tmp/psr.aml > /sys/kernel/debug/acpi/custom_method" + +2. insert a new method + This is easier than overriding an existing method. + We just need to create the ASL code of the method we want to + insert and then follow the step c) ~ g) in section 1. + +3. undo your changes + The "undo" operation is not supported for a new inserted method + right now, i.e. we can not remove a method currently. + For an overrided method, in order to undo your changes, please + save a copy of the method original ASL code in step c) section 1, + and redo step c) ~ g) to override the method with the original one. + + +Note: We can use a kernel with multiple custom ACPI method running, + But each individual write to debugfs can implement a SINGLE + method override. i.e. if we want to insert/override multiple + ACPI methods, we need to redo step c) ~ g) for multiple times. diff --git a/Documentation/arm/OMAP/DSS b/Documentation/arm/OMAP/DSS new file mode 100644 index 000000000000..0af0e9eed5d6 --- /dev/null +++ b/Documentation/arm/OMAP/DSS @@ -0,0 +1,317 @@ +OMAP2/3 Display Subsystem +------------------------- + +This is an almost total rewrite of the OMAP FB driver in drivers/video/omap +(let's call it DSS1). The main differences between DSS1 and DSS2 are DSI, +TV-out and multiple display support, but there are lots of small improvements +also. + +The DSS2 driver (omapdss module) is in arch/arm/plat-omap/dss/, and the FB, +panel and controller drivers are in drivers/video/omap2/. DSS1 and DSS2 live +currently side by side, you can choose which one to use. + +Features +-------- + +Working and tested features include: + +- MIPI DPI (parallel) output +- MIPI DSI output in command mode +- MIPI DBI (RFBI) output +- SDI output +- TV output +- All pieces can be compiled as a module or inside kernel +- Use DISPC to update any of the outputs +- Use CPU to update RFBI or DSI output +- OMAP DISPC planes +- RGB16, RGB24 packed, RGB24 unpacked +- YUV2, UYVY +- Scaling +- Adjusting DSS FCK to find a good pixel clock +- Use DSI DPLL to create DSS FCK + +Tested boards include: +- OMAP3 SDP board +- Beagle board +- N810 + +omapdss driver +-------------- + +The DSS driver does not itself have any support for Linux framebuffer, V4L or +such like the current ones, but it has an internal kernel API that upper level +drivers can use. + +The DSS driver models OMAP's overlays, overlay managers and displays in a +flexible way to enable non-common multi-display configuration. In addition to +modelling the hardware overlays, omapdss supports virtual overlays and overlay +managers. These can be used when updating a display with CPU or system DMA. + +Panel and controller drivers +---------------------------- + +The drivers implement panel or controller specific functionality and are not +usually visible to users except through omapfb driver. They register +themselves to the DSS driver. + +omapfb driver +------------- + +The omapfb driver implements arbitrary number of standard linux framebuffers. +These framebuffers can be routed flexibly to any overlays, thus allowing very +dynamic display architecture. + +The driver exports some omapfb specific ioctls, which are compatible with the +ioctls in the old driver. + +The rest of the non standard features are exported via sysfs. Whether the final +implementation will use sysfs, or ioctls, is still open. + +V4L2 drivers +------------ + +V4L2 is being implemented in TI. + +From omapdss point of view the V4L2 drivers should be similar to framebuffer +driver. + +Architecture +-------------------- + +Some clarification what the different components do: + + - Framebuffer is a memory area inside OMAP's SRAM/SDRAM that contains the + pixel data for the image. Framebuffer has width and height and color + depth. + - Overlay defines where the pixels are read from and where they go on the + screen. The overlay may be smaller than framebuffer, thus displaying only + part of the framebuffer. The position of the overlay may be changed if + the overlay is smaller than the display. + - Overlay manager combines the overlays in to one image and feeds them to + display. + - Display is the actual physical display device. + +A framebuffer can be connected to multiple overlays to show the same pixel data +on all of the overlays. Note that in this case the overlay input sizes must be +the same, but, in case of video overlays, the output size can be different. Any +framebuffer can be connected to any overlay. + +An overlay can be connected to one overlay manager. Also DISPC overlays can be +connected only to DISPC overlay managers, and virtual overlays can be only +connected to virtual overlays. + +An overlay manager can be connected to one display. There are certain +restrictions which kinds of displays an overlay manager can be connected: + + - DISPC TV overlay manager can be only connected to TV display. + - Virtual overlay managers can only be connected to DBI or DSI displays. + - DISPC LCD overlay manager can be connected to all displays, except TV + display. + +Sysfs +----- +The sysfs interface is mainly used for testing. I don't think sysfs +interface is the best for this in the final version, but I don't quite know +what would be the best interfaces for these things. + +The sysfs interface is divided to two parts: DSS and FB. + +/sys/class/graphics/fb? directory: +mirror 0=off, 1=on +rotate Rotation 0-3 for 0, 90, 180, 270 degrees +rotate_type 0 = DMA rotation, 1 = VRFB rotation +overlays List of overlay numbers to which framebuffer pixels go +phys_addr Physical address of the framebuffer +virt_addr Virtual address of the framebuffer +size Size of the framebuffer + +/sys/devices/platform/omapdss/overlay? directory: +enabled 0=off, 1=on +input_size width,height (ie. the framebuffer size) +manager Destination overlay manager name +name +output_size width,height +position x,y +screen_width width +global_alpha global alpha 0-255 0=transparent 255=opaque + +/sys/devices/platform/omapdss/manager? directory: +display Destination display +name +alpha_blending_enabled 0=off, 1=on +trans_key_enabled 0=off, 1=on +trans_key_type gfx-destination, video-source +trans_key_value transparency color key (RGB24) +default_color default background color (RGB24) + +/sys/devices/platform/omapdss/display? directory: +ctrl_name Controller name +mirror 0=off, 1=on +update_mode 0=off, 1=auto, 2=manual +enabled 0=off, 1=on +name +rotate Rotation 0-3 for 0, 90, 180, 270 degrees +timings Display timings (pixclock,xres/hfp/hbp/hsw,yres/vfp/vbp/vsw) + When writing, two special timings are accepted for tv-out: + "pal" and "ntsc" +panel_name +tear_elim Tearing elimination 0=off, 1=on + +There are also some debugfs files at <debugfs>/omapdss/ which show information +about clocks and registers. + +Examples +-------- + +The following definitions have been made for the examples below: + +ovl0=/sys/devices/platform/omapdss/overlay0 +ovl1=/sys/devices/platform/omapdss/overlay1 +ovl2=/sys/devices/platform/omapdss/overlay2 + +mgr0=/sys/devices/platform/omapdss/manager0 +mgr1=/sys/devices/platform/omapdss/manager1 + +lcd=/sys/devices/platform/omapdss/display0 +dvi=/sys/devices/platform/omapdss/display1 +tv=/sys/devices/platform/omapdss/display2 + +fb0=/sys/class/graphics/fb0 +fb1=/sys/class/graphics/fb1 +fb2=/sys/class/graphics/fb2 + +Default setup on OMAP3 SDP +-------------------------- + +Here's the default setup on OMAP3 SDP board. All planes go to LCD. DVI +and TV-out are not in use. The columns from left to right are: +framebuffers, overlays, overlay managers, displays. Framebuffers are +handled by omapfb, and the rest by the DSS. + +FB0 --- GFX -\ DVI +FB1 --- VID1 --+- LCD ---- LCD +FB2 --- VID2 -/ TV ----- TV + +Example: Switch from LCD to DVI +---------------------- + +w=`cat $dvi/timings | cut -d "," -f 2 | cut -d "/" -f 1` +h=`cat $dvi/timings | cut -d "," -f 3 | cut -d "/" -f 1` + +echo "0" > $lcd/enabled +echo "" > $mgr0/display +fbset -fb /dev/fb0 -xres $w -yres $h -vxres $w -vyres $h +# at this point you have to switch the dvi/lcd dip-switch from the omap board +echo "dvi" > $mgr0/display +echo "1" > $dvi/enabled + +After this the configuration looks like: + +FB0 --- GFX -\ -- DVI +FB1 --- VID1 --+- LCD -/ LCD +FB2 --- VID2 -/ TV ----- TV + +Example: Clone GFX overlay to LCD and TV +------------------------------- + +w=`cat $tv/timings | cut -d "," -f 2 | cut -d "/" -f 1` +h=`cat $tv/timings | cut -d "," -f 3 | cut -d "/" -f 1` + +echo "0" > $ovl0/enabled +echo "0" > $ovl1/enabled + +echo "" > $fb1/overlays +echo "0,1" > $fb0/overlays + +echo "$w,$h" > $ovl1/output_size +echo "tv" > $ovl1/manager + +echo "1" > $ovl0/enabled +echo "1" > $ovl1/enabled + +echo "1" > $tv/enabled + +After this the configuration looks like (only relevant parts shown): + +FB0 +-- GFX ---- LCD ---- LCD + \- VID1 ---- TV ---- TV + +Misc notes +---------- + +OMAP FB allocates the framebuffer memory using the OMAP VRAM allocator. + +Using DSI DPLL to generate pixel clock it is possible produce the pixel clock +of 86.5MHz (max possible), and with that you get 1280x1024@57 output from DVI. + +Rotation and mirroring currently only supports RGB565 and RGB8888 modes. VRFB +does not support mirroring. + +VRFB rotation requires much more memory than non-rotated framebuffer, so you +probably need to increase your vram setting before using VRFB rotation. Also, +many applications may not work with VRFB if they do not pay attention to all +framebuffer parameters. + +Kernel boot arguments +--------------------- + +vram=<size> + - Amount of total VRAM to preallocate. For example, "10M". omapfb + allocates memory for framebuffers from VRAM. + +omapfb.mode=<display>:<mode>[,...] + - Default video mode for specified displays. For example, + "dvi:800x400MR-24@60". See drivers/video/modedb.c. + There are also two special modes: "pal" and "ntsc" that + can be used to tv out. + +omapfb.vram=<fbnum>:<size>[@<physaddr>][,...] + - VRAM allocated for a framebuffer. Normally omapfb allocates vram + depending on the display size. With this you can manually allocate + more or define the physical address of each framebuffer. For example, + "1:4M" to allocate 4M for fb1. + +omapfb.debug=<y|n> + - Enable debug printing. You have to have OMAPFB debug support enabled + in kernel config. + +omapfb.test=<y|n> + - Draw test pattern to framebuffer whenever framebuffer settings change. + You need to have OMAPFB debug support enabled in kernel config. + +omapfb.vrfb=<y|n> + - Use VRFB rotation for all framebuffers. + +omapfb.rotate=<angle> + - Default rotation applied to all framebuffers. + 0 - 0 degree rotation + 1 - 90 degree rotation + 2 - 180 degree rotation + 3 - 270 degree rotation + +omapfb.mirror=<y|n> + - Default mirror for all framebuffers. Only works with DMA rotation. + +omapdss.def_disp=<display> + - Name of default display, to which all overlays will be connected. + Common examples are "lcd" or "tv". + +omapdss.debug=<y|n> + - Enable debug printing. You have to have DSS debug support enabled in + kernel config. + +TODO +---- + +DSS locking + +Error checking +- Lots of checks are missing or implemented just as BUG() + +System DMA update for DSI +- Can be used for RGB16 and RGB24P modes. Probably not for RGB24U (how + to skip the empty byte?) + +OMAP1 support +- Not sure if needed + diff --git a/Documentation/arm/OMAP/omap_pm b/Documentation/arm/OMAP/omap_pm new file mode 100644 index 000000000000..5389440aade3 --- /dev/null +++ b/Documentation/arm/OMAP/omap_pm @@ -0,0 +1,129 @@ + +The OMAP PM interface +===================== + +This document describes the temporary OMAP PM interface. Driver +authors use these functions to communicate minimum latency or +throughput constraints to the kernel power management code. +Over time, the intention is to merge features from the OMAP PM +interface into the Linux PM QoS code. + +Drivers need to express PM parameters which: + +- support the range of power management parameters present in the TI SRF; + +- separate the drivers from the underlying PM parameter + implementation, whether it is the TI SRF or Linux PM QoS or Linux + latency framework or something else; + +- specify PM parameters in terms of fundamental units, such as + latency and throughput, rather than units which are specific to OMAP + or to particular OMAP variants; + +- allow drivers which are shared with other architectures (e.g., + DaVinci) to add these constraints in a way which won't affect non-OMAP + systems, + +- can be implemented immediately with minimal disruption of other + architectures. + + +This document proposes the OMAP PM interface, including the following +five power management functions for driver code: + +1. Set the maximum MPU wakeup latency: + (*pdata->set_max_mpu_wakeup_lat)(struct device *dev, unsigned long t) + +2. Set the maximum device wakeup latency: + (*pdata->set_max_dev_wakeup_lat)(struct device *dev, unsigned long t) + +3. Set the maximum system DMA transfer start latency (CORE pwrdm): + (*pdata->set_max_sdma_lat)(struct device *dev, long t) + +4. Set the minimum bus throughput needed by a device: + (*pdata->set_min_bus_tput)(struct device *dev, u8 agent_id, unsigned long r) + +5. Return the number of times the device has lost context + (*pdata->get_dev_context_loss_count)(struct device *dev) + + +Further documentation for all OMAP PM interface functions can be +found in arch/arm/plat-omap/include/mach/omap-pm.h. + + +The OMAP PM layer is intended to be temporary +--------------------------------------------- + +The intention is that eventually the Linux PM QoS layer should support +the range of power management features present in OMAP3. As this +happens, existing drivers using the OMAP PM interface can be modified +to use the Linux PM QoS code; and the OMAP PM interface can disappear. + + +Driver usage of the OMAP PM functions +------------------------------------- + +As the 'pdata' in the above examples indicates, these functions are +exposed to drivers through function pointers in driver .platform_data +structures. The function pointers are initialized by the board-*.c +files to point to the corresponding OMAP PM functions: +.set_max_dev_wakeup_lat will point to +omap_pm_set_max_dev_wakeup_lat(), etc. Other architectures which do +not support these functions should leave these function pointers set +to NULL. Drivers should use the following idiom: + + if (pdata->set_max_dev_wakeup_lat) + (*pdata->set_max_dev_wakeup_lat)(dev, t); + +The most common usage of these functions will probably be to specify +the maximum time from when an interrupt occurs, to when the device +becomes accessible. To accomplish this, driver writers should use the +set_max_mpu_wakeup_lat() function to to constrain the MPU wakeup +latency, and the set_max_dev_wakeup_lat() function to constrain the +device wakeup latency (from clk_enable() to accessibility). For +example, + + /* Limit MPU wakeup latency */ + if (pdata->set_max_mpu_wakeup_lat) + (*pdata->set_max_mpu_wakeup_lat)(dev, tc); + + /* Limit device powerdomain wakeup latency */ + if (pdata->set_max_dev_wakeup_lat) + (*pdata->set_max_dev_wakeup_lat)(dev, td); + + /* total wakeup latency in this example: (tc + td) */ + +The PM parameters can be overwritten by calling the function again +with the new value. The settings can be removed by calling the +function with a t argument of -1 (except in the case of +set_max_bus_tput(), which should be called with an r argument of 0). + +The fifth function above, omap_pm_get_dev_context_loss_count(), +is intended as an optimization to allow drivers to determine whether the +device has lost its internal context. If context has been lost, the +driver must restore its internal context before proceeding. + + +Other specialized interface functions +------------------------------------- + +The five functions listed above are intended to be usable by any +device driver. DSPBridge and CPUFreq have a few special requirements. +DSPBridge expresses target DSP performance levels in terms of OPP IDs. +CPUFreq expresses target MPU performance levels in terms of MPU +frequency. The OMAP PM interface contains functions for these +specialized cases to convert that input information (OPPs/MPU +frequency) into the form that the underlying power management +implementation needs: + +6. (*pdata->dsp_get_opp_table)(void) + +7. (*pdata->dsp_set_min_opp)(u8 opp_id) + +8. (*pdata->dsp_get_opp)(void) + +9. (*pdata->cpu_get_freq_table)(void) + +10. (*pdata->cpu_set_freq)(unsigned long f) + +11. (*pdata->cpu_get_freq)(void) diff --git a/Documentation/arm/SA1100/ADSBitsy b/Documentation/arm/SA1100/ADSBitsy index ab47c3833908..7197a9e958ee 100644 --- a/Documentation/arm/SA1100/ADSBitsy +++ b/Documentation/arm/SA1100/ADSBitsy @@ -40,4 +40,4 @@ Notes: mode, the timing is off so the image is corrupted. This will be fixed soon. -Any contribution can be sent to nico@cam.org and will be greatly welcome! +Any contribution can be sent to nico@fluxnic.net and will be greatly welcome! diff --git a/Documentation/arm/SA1100/Assabet b/Documentation/arm/SA1100/Assabet index 78bc1c1b04e5..91f7ce7ba426 100644 --- a/Documentation/arm/SA1100/Assabet +++ b/Documentation/arm/SA1100/Assabet @@ -240,7 +240,7 @@ Then, rebooting the Assabet is just a matter of waiting for the login prompt. Nicolas Pitre -nico@cam.org +nico@fluxnic.net June 12, 2001 diff --git a/Documentation/arm/SA1100/Brutus b/Documentation/arm/SA1100/Brutus index 2254c8f0b326..b1cfd405dccc 100644 --- a/Documentation/arm/SA1100/Brutus +++ b/Documentation/arm/SA1100/Brutus @@ -60,7 +60,7 @@ little modifications. Any contribution is welcome. -Please send patches to nico@cam.org +Please send patches to nico@fluxnic.net Have Fun ! diff --git a/Documentation/arm/SA1100/GraphicsClient b/Documentation/arm/SA1100/GraphicsClient index 8fa7e8027ff1..6c9c4f5a36e1 100644 --- a/Documentation/arm/SA1100/GraphicsClient +++ b/Documentation/arm/SA1100/GraphicsClient @@ -4,7 +4,7 @@ For more details, contact Applied Data Systems or see http://www.applieddata.net/products.html The original Linux support for this product has been provided by -Nicolas Pitre <nico@cam.org>. Continued development work by +Nicolas Pitre <nico@fluxnic.net>. Continued development work by Woojung Huh <whuh@applieddata.net> It's currently possible to mount a root filesystem via NFS providing a @@ -94,5 +94,5 @@ Notes: mode, the timing is off so the image is corrupted. This will be fixed soon. -Any contribution can be sent to nico@cam.org and will be greatly welcome! +Any contribution can be sent to nico@fluxnic.net and will be greatly welcome! diff --git a/Documentation/arm/SA1100/GraphicsMaster b/Documentation/arm/SA1100/GraphicsMaster index dd28745ac521..ee7c6595f23f 100644 --- a/Documentation/arm/SA1100/GraphicsMaster +++ b/Documentation/arm/SA1100/GraphicsMaster @@ -4,7 +4,7 @@ For more details, contact Applied Data Systems or see http://www.applieddata.net/products.html The original Linux support for this product has been provided by -Nicolas Pitre <nico@cam.org>. Continued development work by +Nicolas Pitre <nico@fluxnic.net>. Continued development work by Woojung Huh <whuh@applieddata.net> Use 'make graphicsmaster_config' before any 'make config'. @@ -50,4 +50,4 @@ Notes: mode, the timing is off so the image is corrupted. This will be fixed soon. -Any contribution can be sent to nico@cam.org and will be greatly welcome! +Any contribution can be sent to nico@fluxnic.net and will be greatly welcome! diff --git a/Documentation/arm/SA1100/Victor b/Documentation/arm/SA1100/Victor index 01e81fc49461..f938a29fdc20 100644 --- a/Documentation/arm/SA1100/Victor +++ b/Documentation/arm/SA1100/Victor @@ -9,7 +9,7 @@ Of course Victor is using Linux as its main operating system. The Victor implementation for Linux is maintained by Nicolas Pitre: nico@visuaide.com - nico@cam.org + nico@fluxnic.net For any comments, please feel free to contact me through the above addresses. diff --git a/Documentation/arm/Samsung-S3C24XX/CPUfreq.txt b/Documentation/arm/Samsung-S3C24XX/CPUfreq.txt new file mode 100644 index 000000000000..76b3a11e90be --- /dev/null +++ b/Documentation/arm/Samsung-S3C24XX/CPUfreq.txt @@ -0,0 +1,75 @@ + S3C24XX CPUfreq support + ======================= + +Introduction +------------ + + The S3C24XX series support a number of power saving systems, such as + the ability to change the core, memory and peripheral operating + frequencies. The core control is exported via the CPUFreq driver + which has a number of different manual or automatic controls over the + rate the core is running at. + + There are two forms of the driver depending on the specific CPU and + how the clocks are arranged. The first implementation used as single + PLL to feed the ARM, memory and peripherals via a series of dividers + and muxes and this is the implementation that is documented here. A + newer version where there is a seperate PLL and clock divider for the + ARM core is available as a seperate driver. + + +Layout +------ + + The code core manages the CPU specific drivers, any data that they + need to register and the interface to the generic drivers/cpufreq + system. Each CPU registers a driver to control the PLL, clock dividers + and anything else associated with it. Any board that wants to use this + framework needs to supply at least basic details of what is required. + + The core registers with drivers/cpufreq at init time if all the data + necessary has been supplied. + + +CPU support +----------- + + The support for each CPU depends on the facilities provided by the + SoC and the driver as each device has different PLL and clock chains + associated with it. + + +Slow Mode +--------- + + The SLOW mode where the PLL is turned off altogether and the + system is fed by the external crystal input is currently not + supported. + + +sysfs +----- + + The core code exports extra information via sysfs in the directory + devices/system/cpu/cpu0/arch-freq. + + +Board Support +------------- + + Each board that wants to use the cpufreq code must register some basic + information with the core driver to provide information about what the + board requires and any restrictions being placed on it. + + The board needs to supply information about whether it needs the IO bank + timings changing, any maximum frequency limits and information about the + SDRAM refresh rate. + + + + +Document Author +--------------- + +Ben Dooks, Copyright 2009 Simtec Electronics +Licensed under GPLv2 diff --git a/Documentation/arm/Samsung-S3C24XX/EB2410ITX.txt b/Documentation/arm/Samsung-S3C24XX/EB2410ITX.txt index 26422f0f9080..b87292e05f2f 100644 --- a/Documentation/arm/Samsung-S3C24XX/EB2410ITX.txt +++ b/Documentation/arm/Samsung-S3C24XX/EB2410ITX.txt @@ -55,4 +55,4 @@ Maintainers This board is maintained by Simtec Electronics. -(c) 2004 Ben Dooks, Simtec Electronics +Copyright 2004 Ben Dooks, Simtec Electronics diff --git a/Documentation/arm/Samsung-S3C24XX/GPIO.txt b/Documentation/arm/Samsung-S3C24XX/GPIO.txt index 948c8718d967..2af2cf39915f 100644 --- a/Documentation/arm/Samsung-S3C24XX/GPIO.txt +++ b/Documentation/arm/Samsung-S3C24XX/GPIO.txt @@ -134,4 +134,4 @@ Authour Ben Dooks, 03 October 2004 -(c) 2004 Ben Dooks, Simtec Electronics +Copyright 2004 Ben Dooks, Simtec Electronics diff --git a/Documentation/arm/Samsung-S3C24XX/Overview.txt b/Documentation/arm/Samsung-S3C24XX/Overview.txt index cff6227b4484..081892df4fda 100644 --- a/Documentation/arm/Samsung-S3C24XX/Overview.txt +++ b/Documentation/arm/Samsung-S3C24XX/Overview.txt @@ -299,4 +299,4 @@ Port Contributors Document Author --------------- -Ben Dooks, (c) 2004-2005,2006 Simtec Electronics +Ben Dooks, Copyright 2004-2006 Simtec Electronics diff --git a/Documentation/arm/Samsung-S3C24XX/S3C2412.txt b/Documentation/arm/Samsung-S3C24XX/S3C2412.txt index 295d971a15ed..f057876b920b 100644 --- a/Documentation/arm/Samsung-S3C24XX/S3C2412.txt +++ b/Documentation/arm/Samsung-S3C24XX/S3C2412.txt @@ -117,4 +117,4 @@ ATA Document Author --------------- -Ben Dooks, (c) 2006 Simtec Electronics +Ben Dooks, Copyright 2006 Simtec Electronics diff --git a/Documentation/arm/Samsung-S3C24XX/S3C2413.txt b/Documentation/arm/Samsung-S3C24XX/S3C2413.txt index ab2a88858f12..909bdc7dd7b5 100644 --- a/Documentation/arm/Samsung-S3C24XX/S3C2413.txt +++ b/Documentation/arm/Samsung-S3C24XX/S3C2413.txt @@ -18,4 +18,4 @@ Camera Interface Document Author --------------- -Ben Dooks, (c) 2006 Simtec Electronics +Ben Dooks, Copyright 2006 Simtec Electronics diff --git a/Documentation/arm/Samsung-S3C24XX/Suspend.txt b/Documentation/arm/Samsung-S3C24XX/Suspend.txt index a30fe510572b..7edd0e2e6c5b 100644 --- a/Documentation/arm/Samsung-S3C24XX/Suspend.txt +++ b/Documentation/arm/Samsung-S3C24XX/Suspend.txt @@ -133,5 +133,5 @@ Configuration Document Author --------------- -Ben Dooks, (c) 2004 Simtec Electronics +Ben Dooks, Copyright 2004 Simtec Electronics diff --git a/Documentation/arm/Samsung-S3C24XX/USB-Host.txt b/Documentation/arm/Samsung-S3C24XX/USB-Host.txt index 67671eba4231..f82b1faefad5 100644 --- a/Documentation/arm/Samsung-S3C24XX/USB-Host.txt +++ b/Documentation/arm/Samsung-S3C24XX/USB-Host.txt @@ -90,4 +90,4 @@ Platform Data Document Author --------------- -Ben Dooks, (c) 2005 Simtec Electronics +Ben Dooks, Copyright 2005 Simtec Electronics diff --git a/Documentation/arm/tcm.txt b/Documentation/arm/tcm.txt new file mode 100644 index 000000000000..77fd9376e6d7 --- /dev/null +++ b/Documentation/arm/tcm.txt @@ -0,0 +1,147 @@ +ARM TCM (Tightly-Coupled Memory) handling in Linux +---- +Written by Linus Walleij <linus.walleij@stericsson.com> + +Some ARM SoC:s have a so-called TCM (Tightly-Coupled Memory). +This is usually just a few (4-64) KiB of RAM inside the ARM +processor. + +Due to being embedded inside the CPU The TCM has a +Harvard-architecture, so there is an ITCM (instruction TCM) +and a DTCM (data TCM). The DTCM can not contain any +instructions, but the ITCM can actually contain data. +The size of DTCM or ITCM is minimum 4KiB so the typical +minimum configuration is 4KiB ITCM and 4KiB DTCM. + +ARM CPU:s have special registers to read out status, physical +location and size of TCM memories. arch/arm/include/asm/cputype.h +defines a CPUID_TCM register that you can read out from the +system control coprocessor. Documentation from ARM can be found +at http://infocenter.arm.com, search for "TCM Status Register" +to see documents for all CPUs. Reading this register you can +determine if ITCM (bit 0) and/or DTCM (bit 16) is present in the +machine. + +There is further a TCM region register (search for "TCM Region +Registers" at the ARM site) that can report and modify the location +size of TCM memories at runtime. This is used to read out and modify +TCM location and size. Notice that this is not a MMU table: you +actually move the physical location of the TCM around. At the +place you put it, it will mask any underlying RAM from the +CPU so it is usually wise not to overlap any physical RAM with +the TCM. + +The TCM memory can then be remapped to another address again using +the MMU, but notice that the TCM if often used in situations where +the MMU is turned off. To avoid confusion the current Linux +implementation will map the TCM 1 to 1 from physical to virtual +memory in the location specified by the machine. + +TCM is used for a few things: + +- FIQ and other interrupt handlers that need deterministic + timing and cannot wait for cache misses. + +- Idle loops where all external RAM is set to self-refresh + retention mode, so only on-chip RAM is accessible by + the CPU and then we hang inside ITCM waiting for an + interrupt. + +- Other operations which implies shutting off or reconfiguring + the external RAM controller. + +There is an interface for using TCM on the ARM architecture +in <asm/tcm.h>. Using this interface it is possible to: + +- Define the physical address and size of ITCM and DTCM. + +- Tag functions to be compiled into ITCM. + +- Tag data and constants to be allocated to DTCM and ITCM. + +- Have the remaining TCM RAM added to a special + allocation pool with gen_pool_create() and gen_pool_add() + and provice tcm_alloc() and tcm_free() for this + memory. Such a heap is great for things like saving + device state when shutting off device power domains. + +A machine that has TCM memory shall select HAVE_TCM in +arch/arm/Kconfig for itself, and then the +rest of the functionality will depend on the physical +location and size of ITCM and DTCM to be defined in +mach/memory.h for the machine. Code that needs to use +TCM shall #include <asm/tcm.h> If the TCM is not located +at the place given in memory.h it will be moved using +the TCM Region registers. + +Functions to go into itcm can be tagged like this: +int __tcmfunc foo(int bar); + +Variables to go into dtcm can be tagged like this: +int __tcmdata foo; + +Constants can be tagged like this: +int __tcmconst foo; + +To put assembler into TCM just use +.section ".tcm.text" or .section ".tcm.data" +respectively. + +Example code: + +#include <asm/tcm.h> + +/* Uninitialized data */ +static u32 __tcmdata tcmvar; +/* Initialized data */ +static u32 __tcmdata tcmassigned = 0x2BADBABEU; +/* Constant */ +static const u32 __tcmconst tcmconst = 0xCAFEBABEU; + +static void __tcmlocalfunc tcm_to_tcm(void) +{ + int i; + for (i = 0; i < 100; i++) + tcmvar ++; +} + +static void __tcmfunc hello_tcm(void) +{ + /* Some abstract code that runs in ITCM */ + int i; + for (i = 0; i < 100; i++) { + tcmvar ++; + } + tcm_to_tcm(); +} + +static void __init test_tcm(void) +{ + u32 *tcmem; + int i; + + hello_tcm(); + printk("Hello TCM executed from ITCM RAM\n"); + + printk("TCM variable from testrun: %u @ %p\n", tcmvar, &tcmvar); + tcmvar = 0xDEADBEEFU; + printk("TCM variable: 0x%x @ %p\n", tcmvar, &tcmvar); + + printk("TCM assigned variable: 0x%x @ %p\n", tcmassigned, &tcmassigned); + + printk("TCM constant: 0x%x @ %p\n", tcmconst, &tcmconst); + + /* Allocate some TCM memory from the pool */ + tcmem = tcm_alloc(20); + if (tcmem) { + printk("TCM Allocated 20 bytes of TCM @ %p\n", tcmem); + tcmem[0] = 0xDEADBEEFU; + tcmem[1] = 0x2BADBABEU; + tcmem[2] = 0xCAFEBABEU; + tcmem[3] = 0xDEADBEEFU; + tcmem[4] = 0x2BADBABEU; + for (i = 0; i < 5; i++) + printk("TCM tcmem[%d] = %08x\n", i, tcmem[i]); + tcm_free(tcmem, 20); + } +} diff --git a/Documentation/auxdisplay/cfag12864b-example.c b/Documentation/auxdisplay/cfag12864b-example.c index 2caeea5e4993..e7823ffb1ca0 100644 --- a/Documentation/auxdisplay/cfag12864b-example.c +++ b/Documentation/auxdisplay/cfag12864b-example.c @@ -62,7 +62,7 @@ unsigned char cfag12864b_buffer[CFAG12864B_SIZE]; * Unable to open: return = -1 * Unable to mmap: return = -2 */ -int cfag12864b_init(char *path) +static int cfag12864b_init(char *path) { cfag12864b_fd = open(path, O_RDWR); if (cfag12864b_fd == -1) @@ -81,7 +81,7 @@ int cfag12864b_init(char *path) /* * exit a cfag12864b framebuffer device */ -void cfag12864b_exit(void) +static void cfag12864b_exit(void) { munmap(cfag12864b_mem, CFAG12864B_SIZE); close(cfag12864b_fd); @@ -90,7 +90,7 @@ void cfag12864b_exit(void) /* * set (x, y) pixel */ -void cfag12864b_set(unsigned char x, unsigned char y) +static void cfag12864b_set(unsigned char x, unsigned char y) { if (CFAG12864B_CHECK(x, y)) cfag12864b_buffer[CFAG12864B_ADDRESS(x, y)] |= @@ -100,7 +100,7 @@ void cfag12864b_set(unsigned char x, unsigned char y) /* * unset (x, y) pixel */ -void cfag12864b_unset(unsigned char x, unsigned char y) +static void cfag12864b_unset(unsigned char x, unsigned char y) { if (CFAG12864B_CHECK(x, y)) cfag12864b_buffer[CFAG12864B_ADDRESS(x, y)] &= @@ -113,7 +113,7 @@ void cfag12864b_unset(unsigned char x, unsigned char y) * Pixel off: return = 0 * Pixel on: return = 1 */ -unsigned char cfag12864b_isset(unsigned char x, unsigned char y) +static unsigned char cfag12864b_isset(unsigned char x, unsigned char y) { if (CFAG12864B_CHECK(x, y)) if (cfag12864b_buffer[CFAG12864B_ADDRESS(x, y)] & @@ -126,7 +126,7 @@ unsigned char cfag12864b_isset(unsigned char x, unsigned char y) /* * not (x, y) pixel */ -void cfag12864b_not(unsigned char x, unsigned char y) +static void cfag12864b_not(unsigned char x, unsigned char y) { if (cfag12864b_isset(x, y)) cfag12864b_unset(x, y); @@ -137,7 +137,7 @@ void cfag12864b_not(unsigned char x, unsigned char y) /* * fill (set all pixels) */ -void cfag12864b_fill(void) +static void cfag12864b_fill(void) { unsigned short i; @@ -148,7 +148,7 @@ void cfag12864b_fill(void) /* * clear (unset all pixels) */ -void cfag12864b_clear(void) +static void cfag12864b_clear(void) { unsigned short i; @@ -162,7 +162,7 @@ void cfag12864b_clear(void) * Pixel off: src[i] = 0 * Pixel on: src[i] > 0 */ -void cfag12864b_format(unsigned char * matrix) +static void cfag12864b_format(unsigned char * matrix) { unsigned char i, j, n; @@ -182,7 +182,7 @@ void cfag12864b_format(unsigned char * matrix) /* * blit buffer to lcd */ -void cfag12864b_blit(void) +static void cfag12864b_blit(void) { memcpy(cfag12864b_mem, cfag12864b_buffer, CFAG12864B_SIZE); } @@ -194,11 +194,10 @@ void cfag12864b_blit(void) */ #include <stdio.h> -#include <string.h> #define EXAMPLES 6 -void example(unsigned char n) +static void example(unsigned char n) { unsigned short i, j; unsigned char matrix[CFAG12864B_WIDTH * CFAG12864B_HEIGHT]; diff --git a/Documentation/blackfin/00-INDEX b/Documentation/blackfin/00-INDEX index d6840a91e1e1..c34e12440fec 100644 --- a/Documentation/blackfin/00-INDEX +++ b/Documentation/blackfin/00-INDEX @@ -1,9 +1,6 @@ 00-INDEX - This file -cache-lock.txt - - HOWTO for blackfin cache locking. - cachefeatures.txt - Supported cache features. diff --git a/Documentation/blackfin/Makefile b/Documentation/blackfin/Makefile new file mode 100644 index 000000000000..773dbb103f1c --- /dev/null +++ b/Documentation/blackfin/Makefile @@ -0,0 +1,6 @@ +obj-m := gptimers-example.o + +all: modules + +modules clean: + $(MAKE) -C ../.. SUBDIRS=$(PWD) $@ diff --git a/Documentation/blackfin/cache-lock.txt b/Documentation/blackfin/cache-lock.txt deleted file mode 100644 index 88ba1e6c31c3..000000000000 --- a/Documentation/blackfin/cache-lock.txt +++ /dev/null @@ -1,48 +0,0 @@ -/* - * File: Documentation/blackfin/cache-lock.txt - * Based on: - * Author: - * - * Created: - * Description: This file contains the simple DMA Implementation for Blackfin - * - * Rev: $Id: cache-lock.txt 2384 2006-11-01 04:12:43Z magicyang $ - * - * Modified: - * Copyright 2004-2006 Analog Devices Inc. - * - * Bugs: Enter bugs at http://blackfin.uclinux.org/ - * - */ - -How to lock your code in cache in uClinux/blackfin --------------------------------------------------- - -There are only a few steps required to lock your code into the cache. -Currently you can lock the code by Way. - -Below are the interface provided for locking the cache. - - -1. cache_grab_lock(int Ways); - -This function grab the lock for locking your code into the cache specified -by Ways. - - -2. cache_lock(int Ways); - -This function should be called after your critical code has been executed. -Once the critical code exits, the code is now loaded into the cache. This -function locks the code into the cache. - - -So, the example sequence will be: - - cache_grab_lock(WAY0_L); /* Grab the lock */ - - critical_code(); /* Execute the code of interest */ - - cache_lock(WAY0_L); /* Lock the cache */ - -Where WAY0_L signifies WAY0 locking. diff --git a/Documentation/blackfin/cachefeatures.txt b/Documentation/blackfin/cachefeatures.txt index 0fbec23becb5..75de51f94515 100644 --- a/Documentation/blackfin/cachefeatures.txt +++ b/Documentation/blackfin/cachefeatures.txt @@ -41,16 +41,6 @@ icplb_flush(); dcplb_flush(); - - Locking the cache. - - cache_grab_lock(); - cache_lock(); - - Please refer linux-2.6.x/Documentation/blackfin/cache-lock.txt for how to - lock the cache. - - Locking the cache is optional feature. - - Miscellaneous cache functions. flush_cache_all(); diff --git a/Documentation/blackfin/gptimers-example.c b/Documentation/blackfin/gptimers-example.c new file mode 100644 index 000000000000..b1bd6340e748 --- /dev/null +++ b/Documentation/blackfin/gptimers-example.c @@ -0,0 +1,83 @@ +/* + * Simple gptimers example + * http://docs.blackfin.uclinux.org/doku.php?id=linux-kernel:drivers:gptimers + * + * Copyright 2007-2009 Analog Devices Inc. + * + * Licensed under the GPL-2 or later. + */ + +#include <linux/interrupt.h> +#include <linux/module.h> + +#include <asm/gptimers.h> +#include <asm/portmux.h> + +/* ... random driver includes ... */ + +#define DRIVER_NAME "gptimer_example" + +struct gptimer_data { + uint32_t period, width; +}; +static struct gptimer_data data; + +/* ... random driver state ... */ + +static irqreturn_t gptimer_example_irq(int irq, void *dev_id) +{ + struct gptimer_data *data = dev_id; + + /* make sure it was our timer which caused the interrupt */ + if (!get_gptimer_intr(TIMER5_id)) + return IRQ_NONE; + + /* read the width/period values that were captured for the waveform */ + data->width = get_gptimer_pwidth(TIMER5_id); + data->period = get_gptimer_period(TIMER5_id); + + /* acknowledge the interrupt */ + clear_gptimer_intr(TIMER5_id); + + /* tell the upper layers we took care of things */ + return IRQ_HANDLED; +} + +/* ... random driver code ... */ + +static int __init gptimer_example_init(void) +{ + int ret; + + /* grab the peripheral pins */ + ret = peripheral_request(P_TMR5, DRIVER_NAME); + if (ret) { + printk(KERN_NOTICE DRIVER_NAME ": peripheral request failed\n"); + return ret; + } + + /* grab the IRQ for the timer */ + ret = request_irq(IRQ_TIMER5, gptimer_example_irq, IRQF_SHARED, DRIVER_NAME, &data); + if (ret) { + printk(KERN_NOTICE DRIVER_NAME ": IRQ request failed\n"); + peripheral_free(P_TMR5); + return ret; + } + + /* setup the timer and enable it */ + set_gptimer_config(TIMER5_id, WDTH_CAP | PULSE_HI | PERIOD_CNT | IRQ_ENA); + enable_gptimers(TIMER5bit); + + return 0; +} +module_init(gptimer_example_init); + +static void __exit gptimer_example_exit(void) +{ + disable_gptimers(TIMER5bit); + free_irq(IRQ_TIMER5, &data); + peripheral_free(P_TMR5); +} +module_exit(gptimer_example_exit); + +MODULE_LICENSE("BSD"); diff --git a/Documentation/block/00-INDEX b/Documentation/block/00-INDEX index 961a0513f8c3..a406286f6f3e 100644 --- a/Documentation/block/00-INDEX +++ b/Documentation/block/00-INDEX @@ -1,7 +1,5 @@ 00-INDEX - This file -as-iosched.txt - - Anticipatory IO scheduler barrier.txt - I/O Barriers biodoc.txt diff --git a/Documentation/block/as-iosched.txt b/Documentation/block/as-iosched.txt deleted file mode 100644 index 738b72be128e..000000000000 --- a/Documentation/block/as-iosched.txt +++ /dev/null @@ -1,172 +0,0 @@ -Anticipatory IO scheduler -------------------------- -Nick Piggin <piggin@cyberone.com.au> 13 Sep 2003 - -Attention! Database servers, especially those using "TCQ" disks should -investigate performance with the 'deadline' IO scheduler. Any system with high -disk performance requirements should do so, in fact. - -If you see unusual performance characteristics of your disk systems, or you -see big performance regressions versus the deadline scheduler, please email -me. Database users don't bother unless you're willing to test a lot of patches -from me ;) its a known issue. - -Also, users with hardware RAID controllers, doing striping, may find -highly variable performance results with using the as-iosched. The -as-iosched anticipatory implementation is based on the notion that a disk -device has only one physical seeking head. A striped RAID controller -actually has a head for each physical device in the logical RAID device. - -However, setting the antic_expire (see tunable parameters below) produces -very similar behavior to the deadline IO scheduler. - -Selecting IO schedulers ------------------------ -Refer to Documentation/block/switching-sched.txt for information on -selecting an io scheduler on a per-device basis. - -Anticipatory IO scheduler Policies ----------------------------------- -The as-iosched implementation implements several layers of policies -to determine when an IO request is dispatched to the disk controller. -Here are the policies outlined, in order of application. - -1. one-way Elevator algorithm. - -The elevator algorithm is similar to that used in deadline scheduler, with -the addition that it allows limited backward movement of the elevator -(i.e. seeks backwards). A seek backwards can occur when choosing between -two IO requests where one is behind the elevator's current position, and -the other is in front of the elevator's position. If the seek distance to -the request in back of the elevator is less than half the seek distance to -the request in front of the elevator, then the request in back can be chosen. -Backward seeks are also limited to a maximum of MAXBACK (1024*1024) sectors. -This favors forward movement of the elevator, while allowing opportunistic -"short" backward seeks. - -2. FIFO expiration times for reads and for writes. - -This is again very similar to the deadline IO scheduler. The expiration -times for requests on these lists is tunable using the parameters read_expire -and write_expire discussed below. When a read or a write expires in this way, -the IO scheduler will interrupt its current elevator sweep or read anticipation -to service the expired request. - -3. Read and write request batching - -A batch is a collection of read requests or a collection of write -requests. The as scheduler alternates dispatching read and write batches -to the driver. In the case a read batch, the scheduler submits read -requests to the driver as long as there are read requests to submit, and -the read batch time limit has not been exceeded (read_batch_expire). -The read batch time limit begins counting down only when there are -competing write requests pending. - -In the case of a write batch, the scheduler submits write requests to -the driver as long as there are write requests available, and the -write batch time limit has not been exceeded (write_batch_expire). -However, the length of write batches will be gradually shortened -when read batches frequently exceed their time limit. - -When changing between batch types, the scheduler waits for all requests -from the previous batch to complete before scheduling requests for the -next batch. - -The read and write fifo expiration times described in policy 2 above -are checked only when in scheduling IO of a batch for the corresponding -(read/write) type. So for example, the read FIFO timeout values are -tested only during read batches. Likewise, the write FIFO timeout -values are tested only during write batches. For this reason, -it is generally not recommended for the read batch time -to be longer than the write expiration time, nor for the write batch -time to exceed the read expiration time (see tunable parameters below). - -When the IO scheduler changes from a read to a write batch, -it begins the elevator from the request that is on the head of the -write expiration FIFO. Likewise, when changing from a write batch to -a read batch, scheduler begins the elevator from the first entry -on the read expiration FIFO. - -4. Read anticipation. - -Read anticipation occurs only when scheduling a read batch. -This implementation of read anticipation allows only one read request -to be dispatched to the disk controller at a time. In -contrast, many write requests may be dispatched to the disk controller -at a time during a write batch. It is this characteristic that can make -the anticipatory scheduler perform anomalously with controllers supporting -TCQ, or with hardware striped RAID devices. Setting the antic_expire -queue parameter (see below) to zero disables this behavior, and the -anticipatory scheduler behaves essentially like the deadline scheduler. - -When read anticipation is enabled (antic_expire is not zero), reads -are dispatched to the disk controller one at a time. -At the end of each read request, the IO scheduler examines its next -candidate read request from its sorted read list. If that next request -is from the same process as the request that just completed, -or if the next request in the queue is "very close" to the -just completed request, it is dispatched immediately. Otherwise, -statistics (average think time, average seek distance) on the process -that submitted the just completed request are examined. If it seems -likely that that process will submit another request soon, and that -request is likely to be near the just completed request, then the IO -scheduler will stop dispatching more read requests for up to (antic_expire) -milliseconds, hoping that process will submit a new request near the one -that just completed. If such a request is made, then it is dispatched -immediately. If the antic_expire wait time expires, then the IO scheduler -will dispatch the next read request from the sorted read queue. - -To decide whether an anticipatory wait is worthwhile, the scheduler -maintains statistics for each process that can be used to compute -mean "think time" (the time between read requests), and mean seek -distance for that process. One observation is that these statistics -are associated with each process, but those statistics are not associated -with a specific IO device. So for example, if a process is doing IO -on several file systems on separate devices, the statistics will be -a combination of IO behavior from all those devices. - - -Tuning the anticipatory IO scheduler ------------------------------------- -When using 'as', the anticipatory IO scheduler there are 5 parameters under -/sys/block/*/queue/iosched/. All are units of milliseconds. - -The parameters are: -* read_expire - Controls how long until a read request becomes "expired". It also controls the - interval between which expired requests are served, so set to 50, a request - might take anywhere < 100ms to be serviced _if_ it is the next on the - expired list. Obviously request expiration strategies won't make the disk - go faster. The result basically equates to the timeslice a single reader - gets in the presence of other IO. 100*((seek time / read_expire) + 1) is - very roughly the % streaming read efficiency your disk should get with - multiple readers. - -* read_batch_expire - Controls how much time a batch of reads is given before pending writes are - served. A higher value is more efficient. This might be set below read_expire - if writes are to be given higher priority than reads, but reads are to be - as efficient as possible when there are no writes. Generally though, it - should be some multiple of read_expire. - -* write_expire, and -* write_batch_expire are equivalent to the above, for writes. - -* antic_expire - Controls the maximum amount of time we can anticipate a good read (one - with a short seek distance from the most recently completed request) before - giving up. Many other factors may cause anticipation to be stopped early, - or some processes will not be "anticipated" at all. Should be a bit higher - for big seek time devices though not a linear correspondence - most - processes have only a few ms thinktime. - -In addition to the tunables above there is a read-only file named est_time -which, when read, will show: - - - The probability of a task exiting without a cooperating task - submitting an anticipated IO. - - - The current mean think time. - - - The seek distance used to determine if an incoming IO is better. - diff --git a/Documentation/block/biodoc.txt b/Documentation/block/biodoc.txt index 8d2158a1c6aa..6fab97ea7e6b 100644 --- a/Documentation/block/biodoc.txt +++ b/Documentation/block/biodoc.txt @@ -186,7 +186,7 @@ a virtual address mapping (unlike the earlier scheme of virtual address do not have a corresponding kernel virtual address space mapping) and low-memory pages. -Note: Please refer to Documentation/DMA-mapping.txt for a discussion +Note: Please refer to Documentation/PCI/PCI-DMA-mapping.txt for a discussion on PCI high mem DMA aspects and mapping of scatter gather lists, and support for 64 bit PCI. diff --git a/Documentation/blockdev/drbd/DRBD-8.3-data-packets.svg b/Documentation/blockdev/drbd/DRBD-8.3-data-packets.svg new file mode 100644 index 000000000000..f87cfa0dc2fb --- /dev/null +++ b/Documentation/blockdev/drbd/DRBD-8.3-data-packets.svg @@ -0,0 +1,588 @@ +<?xml version="1.0" encoding="UTF-8" standalone="no"?> +<!-- Created with Inkscape (http://www.inkscape.org/) --> +<svg + xmlns:svg="http://www.w3.org/2000/svg" + xmlns="http://www.w3.org/2000/svg" + version="1.0" + width="210mm" + height="297mm" + viewBox="0 0 21000 29700" + id="svg2" + style="fill-rule:evenodd"> + <defs + id="defs4" /> + <g + id="Default" + style="visibility:visible"> + <desc + id="desc180">Master slide</desc> + </g> + <path + d="M 11999,8601 L 11899,8301 L 12099,8301 L 11999,8601 z" + id="path193" + style="fill:#008000;visibility:visible" /> + <path + d="M 11999,7801 L 11999,8361" + id="path197" + style="fill:none;stroke:#008000;visibility:visible" /> + <path + d="M 7999,10401 L 7899,10101 L 8099,10101 L 7999,10401 z" + id="path209" + style="fill:#008000;visibility:visible" /> + <path + d="M 7999,9601 L 7999,10161" + id="path213" + style="fill:none;stroke:#008000;visibility:visible" /> + <path + d="M 11999,7801 L 11685,7840 L 11724,7644 L 11999,7801 z" + id="path225" + style="fill:#008000;visibility:visible" /> + <path + d="M 7999,7001 L 11764,7754" + id="path229" + style="fill:none;stroke:#008000;visibility:visible" /> + <g + transform="matrix(0.9895258,-0.1443562,0.1443562,0.9895258,-1244.4792,1416.5139)" + id="g245" + style="font-size:318px;font-weight:400;fill:#008000;visibility:visible;font-family:Helvetica embedded"> + <text + id="text247"> + <tspan + x="9139 9368 9579 9808 9986 10075 10252 10481 10659 10837 10909" + y="9284" + id="tspan249">RSDataReply</tspan> + </text> + </g> + <path + d="M 7999,9601 L 8281,9458 L 8311,9655 L 7999,9601 z" + id="path259" + style="fill:#008000;visibility:visible" /> + <path + d="M 11999,9001 L 8236,9565" + id="path263" + style="fill:none;stroke:#008000;visibility:visible" /> + <g + transform="matrix(0.9788674,0.2044961,-0.2044961,0.9788674,1620.9382,-1639.4947)" + id="g279" + style="font-size:318px;font-weight:400;fill:#008000;visibility:visible;font-family:Helvetica embedded"> + <text + id="text281"> + <tspan + x="8743 8972 9132 9310 9573 9801 10013 10242 10419 10597 10775 10953 11114" + y="7023" + id="tspan283">CsumRSRequest</tspan> + </text> + </g> + <text + id="text297" + style="font-size:318px;font-weight:400;fill:#008000;visibility:visible;font-family:Helvetica embedded"> + <tspan + x="4034 4263 4440 4703 4881 5042 5219 5397 5503 5681 5842 6003 6180 6341 6519 6625 6803 6980 7158 7336 7497 7586 7692" + y="5707" + id="tspan299">w_make_resync_request()</tspan> + </text> + <text + id="text313" + style="font-size:318px;font-weight:400;fill:#008000;visibility:visible;font-family:Helvetica embedded"> + <tspan + x="12199 12305 12483 12644 12821 12893 13054 13232 13410 13638 13816 13905 14083 14311 14489 14667 14845 15023 15184 15272 15378" + y="7806" + id="tspan315">receive_DataRequest()</tspan> + </text> + <text + id="text329" + style="font-size:318px;font-weight:400;fill:#008000;visibility:visible;font-family:Helvetica embedded"> + <tspan + x="12199 12377 12483 12660 12838 13016 13194 13372 13549 13621 13799 13977 14083 14261 14438 14616 14794 14955 15133 15294 15399" + y="8606" + id="tspan331">drbd_endio_read_sec()</tspan> + </text> + <text + id="text345" + style="font-size:318px;font-weight:400;fill:#008000;visibility:visible;font-family:Helvetica embedded"> + <tspan + x="12191 12420 12597 12775 12953 13131 13309 13486 13664 13825 13986 14164 14426 14604 14710 14871 15049 15154 15332 15510 15616" + y="9007" + id="tspan347">w_e_end_csum_rs_req()</tspan> + </text> + <text + id="text361" + style="font-size:318px;font-weight:400;fill:#008000;visibility:visible;font-family:Helvetica embedded"> + <tspan + x="4444 4550 4728 4889 5066 5138 5299 5477 5655 5883 6095 6324 6501 6590 6768 6997 7175 7352 7424 7585 7691" + y="9507" + id="tspan363">receive_RSDataReply()</tspan> + </text> + <text + id="text377" + style="font-size:318px;font-weight:400;fill:#008000;visibility:visible;font-family:Helvetica embedded"> + <tspan + x="4457 4635 4741 4918 5096 5274 5452 5630 5807 5879 6057 6235 6464 6569 6641 6730 6908 7086 7247 7425 7585 7691" + y="10407" + id="tspan379">drbd_endio_write_sec()</tspan> + </text> + <text + id="text393" + style="font-size:318px;font-weight:400;fill:#008000;visibility:visible;font-family:Helvetica embedded"> + <tspan + x="4647 4825 5003 5180 5358 5536 5714 5820 5997 6158 6319 6497 6658 6836 7013 7085 7263 7424 7585 7691" + y="10907" + id="tspan395">e_end_resync_block()</tspan> + </text> + <path + d="M 11999,11601 L 11685,11640 L 11724,11444 L 11999,11601 z" + id="path405" + style="fill:#000080;visibility:visible" /> + <path + d="M 7999,10801 L 11764,11554" + id="path409" + style="fill:none;stroke:#000080;visibility:visible" /> + <g + transform="matrix(0.9788674,0.2044961,-0.2044961,0.9788674,2434.7562,-1674.649)" + id="g425" + style="font-size:318px;font-weight:400;fill:#000080;visibility:visible;font-family:Helvetica embedded"> + <text + id="text427"> + <tspan + x="9320 9621 9726 9798 9887 10065 10277 10438" + y="10943" + id="tspan429">WriteAck</tspan> + </text> + </g> + <text + id="text443" + style="font-size:318px;font-weight:400;fill:#000080;visibility:visible;font-family:Helvetica embedded"> + <tspan + x="12199 12377 12555 12644 12821 13033 13105 13283 13444 13604 13816 13977 14138 14244" + y="11559" + id="tspan445">got_BlockAck()</tspan> + </text> + <text + id="text459" + style="font-size:423px;font-weight:400;fill:#000000;visibility:visible;font-family:Helvetica embedded"> + <tspan + x="7999 8304 8541 8778 8990 9201 9413 9650 10001 10120 10357 10594 10806 11043 11280 11398 11703 11940 12152 12364 12601 12812 12931 13049 13261 13498 13710 13947 14065 14302 14540 14658 14777 14870 15107 15225 15437 15649 15886" + y="4877" + id="tspan461">Checksum based Resync, case not in sync</tspan> + </text> + <text + id="text475" + style="font-size:423px;font-weight:400;fill:#000000;visibility:visible;font-family:Helvetica embedded"> + <tspan + x="6961 7266 7571 7854 8159 8299 8536 8654 8891 9010 9247 9484 9603 9840 9958 10077 10170 10407" + y="2806" + id="tspan477">DRBD-8.3 data flow</tspan> + </text> + <text + id="text491" + style="font-size:318px;font-weight:400;fill:#008000;visibility:visible;font-family:Helvetica embedded"> + <tspan + x="5190 5419 5596 5774 5952 6113 6291 6468 6646 6824 6985 7146 7324 7586 7692" + y="7005" + id="tspan493">w_e_send_csum()</tspan> + </text> + <path + d="M 11999,17601 L 11899,17301 L 12099,17301 L 11999,17601 z" + id="path503" + style="fill:#008000;visibility:visible" /> + <path + d="M 11999,16801 L 11999,17361" + id="path507" + style="fill:none;stroke:#008000;visibility:visible" /> + <path + d="M 11999,16801 L 11685,16840 L 11724,16644 L 11999,16801 z" + id="path519" + style="fill:#008000;visibility:visible" /> + <path + d="M 7999,16001 L 11764,16754" + id="path523" + style="fill:none;stroke:#008000;visibility:visible" /> + <g + transform="matrix(0.9895258,-0.1443562,0.1443562,0.9895258,-2539.5806,1529.3491)" + id="g539" + style="font-size:318px;font-weight:400;fill:#000080;visibility:visible;font-family:Helvetica embedded"> + <text + id="text541"> + <tspan + x="9269 9498 9709 9798 9959 10048 10226 10437 10598 10776" + y="18265" + id="tspan543">RSIsInSync</tspan> + </text> + </g> + <path + d="M 7999,18601 L 8281,18458 L 8311,18655 L 7999,18601 z" + id="path553" + style="fill:#000080;visibility:visible" /> + <path + d="M 11999,18001 L 8236,18565" + id="path557" + style="fill:none;stroke:#000080;visibility:visible" /> + <g + transform="matrix(0.9788674,0.2044961,-0.2044961,0.9788674,3461.4027,-1449.3012)" + id="g573" + style="font-size:318px;font-weight:400;fill:#008000;visibility:visible;font-family:Helvetica embedded"> + <text + id="text575"> + <tspan + x="8743 8972 9132 9310 9573 9801 10013 10242 10419 10597 10775 10953 11114" + y="16023" + id="tspan577">CsumRSRequest</tspan> + </text> + </g> + <text + id="text591" + style="font-size:318px;font-weight:400;fill:#008000;visibility:visible;font-family:Helvetica embedded"> + <tspan + x="12199 12305 12483 12644 12821 12893 13054 13232 13410 13638 13816 13905 14083 14311 14489 14667 14845 15023 15184 15272 15378" + y="16806" + id="tspan593">receive_DataRequest()</tspan> + </text> + <text + id="text607" + style="font-size:318px;font-weight:400;fill:#008000;visibility:visible;font-family:Helvetica embedded"> + <tspan + x="12199 12377 12483 12660 12838 13016 13194 13372 13549 13621 13799 13977 14083 14261 14438 14616 14794 14955 15133 15294 15399" + y="17606" + id="tspan609">drbd_endio_read_sec()</tspan> + </text> + <text + id="text623" + style="font-size:318px;font-weight:400;fill:#008000;visibility:visible;font-family:Helvetica embedded"> + <tspan + x="12191 12420 12597 12775 12953 13131 13309 13486 13664 13825 13986 14164 14426 14604 14710 14871 15049 15154 15332 15510 15616" + y="18007" + id="tspan625">w_e_end_csum_rs_req()</tspan> + </text> + <text + id="text639" + style="font-size:318px;font-weight:400;fill:#000080;visibility:visible;font-family:Helvetica embedded"> + <tspan + x="5735 5913 6091 6180 6357 6446 6607 6696 6874 7085 7246 7424 7585 7691" + y="18507" + id="tspan641">got_IsInSync()</tspan> + </text> + <text + id="text655" + style="font-size:423px;font-weight:400;fill:#000000;visibility:visible;font-family:Helvetica embedded"> + <tspan + x="7999 8304 8541 8778 8990 9201 9413 9650 10001 10120 10357 10594 10806 11043 11280 11398 11703 11940 12152 12364 12601 12812 12931 13049 13261 13498 13710 13947 14065 14159 14396 14514 14726 14937 15175" + y="13877" + id="tspan657">Checksum based Resync, case in sync</tspan> + </text> + <path + d="M 12000,24601 L 11900,24301 L 12100,24301 L 12000,24601 z" + id="path667" + style="fill:#008000;visibility:visible" /> + <path + d="M 12000,23801 L 12000,24361" + id="path671" + style="fill:none;stroke:#008000;visibility:visible" /> + <path + d="M 8000,26401 L 7900,26101 L 8100,26101 L 8000,26401 z" + id="path683" + style="fill:#008000;visibility:visible" /> + <path + d="M 8000,25601 L 8000,26161" + id="path687" + style="fill:none;stroke:#008000;visibility:visible" /> + <path + d="M 12000,23801 L 11686,23840 L 11725,23644 L 12000,23801 z" + id="path699" + style="fill:#008000;visibility:visible" /> + <path + d="M 8000,23001 L 11765,23754" + id="path703" + style="fill:none;stroke:#008000;visibility:visible" /> + <g + transform="matrix(0.9895258,-0.1443562,0.1443562,0.9895258,-3543.8452,1630.5143)" + id="g719" + style="font-size:318px;font-weight:400;fill:#008000;visibility:visible;font-family:Helvetica embedded"> + <text + id="text721"> + <tspan + x="9464 9710 9921 10150 10328 10505 10577" + y="25236" + id="tspan723">OVReply</tspan> + </text> + </g> + <path + d="M 8000,25601 L 8282,25458 L 8312,25655 L 8000,25601 z" + id="path733" + style="fill:#008000;visibility:visible" /> + <path + d="M 12000,25001 L 8237,25565" + id="path737" + style="fill:none;stroke:#008000;visibility:visible" /> + <g + transform="matrix(0.9788674,0.2044961,-0.2044961,0.9788674,4918.2801,-1381.2128)" + id="g753" + style="font-size:318px;font-weight:400;fill:#008000;visibility:visible;font-family:Helvetica embedded"> + <text + id="text755"> + <tspan + x="9142 9388 9599 9828 10006 10183 10361 10539 10700" + y="23106" + id="tspan757">OVRequest</tspan> + </text> + </g> + <text + id="text771" + style="font-size:318px;font-weight:400;fill:#008000;visibility:visible;font-family:Helvetica embedded"> + <tspan + x="12200 12306 12484 12645 12822 12894 13055 13233 13411 13656 13868 14097 14274 14452 14630 14808 14969 15058 15163" + y="23806" + id="tspan773">receive_OVRequest()</tspan> + </text> + <text + id="text787" + style="font-size:318px;font-weight:400;fill:#008000;visibility:visible;font-family:Helvetica embedded"> + <tspan + x="12200 12378 12484 12661 12839 13017 13195 13373 13550 13622 13800 13978 14084 14262 14439 14617 14795 14956 15134 15295 15400" + y="24606" + id="tspan789">drbd_endio_read_sec()</tspan> + </text> + <text + id="text803" + style="font-size:318px;font-weight:400;fill:#008000;visibility:visible;font-family:Helvetica embedded"> + <tspan + x="12192 12421 12598 12776 12954 13132 13310 13487 13665 13843 14004 14182 14288 14465 14643 14749" + y="25007" + id="tspan805">w_e_end_ov_req()</tspan> + </text> + <text + id="text819" + style="font-size:318px;font-weight:400;fill:#008000;visibility:visible;font-family:Helvetica embedded"> + <tspan + x="5101 5207 5385 5546 5723 5795 5956 6134 6312 6557 6769 6998 7175 7353 7425 7586 7692" + y="25507" + id="tspan821">receive_OVReply()</tspan> + </text> + <text + id="text835" + style="font-size:318px;font-weight:400;fill:#008000;visibility:visible;font-family:Helvetica embedded"> + <tspan + x="4492 4670 4776 4953 5131 5309 5487 5665 5842 5914 6092 6270 6376 6554 6731 6909 7087 7248 7426 7587 7692" + y="26407" + id="tspan837">drbd_endio_read_sec()</tspan> + </text> + <text + id="text851" + style="font-size:318px;font-weight:400;fill:#008000;visibility:visible;font-family:Helvetica embedded"> + <tspan + x="4902 5131 5308 5486 5664 5842 6020 6197 6375 6553 6714 6892 6998 7175 7353 7425 7586 7692" + y="26907" + id="tspan853">w_e_end_ov_reply()</tspan> + </text> + <path + d="M 12000,27601 L 11686,27640 L 11725,27444 L 12000,27601 z" + id="path863" + style="fill:#000080;visibility:visible" /> + <path + d="M 8000,26801 L 11765,27554" + id="path867" + style="fill:none;stroke:#000080;visibility:visible" /> + <g + transform="matrix(0.9788674,0.2044961,-0.2044961,0.9788674,5704.1907,-1328.312)" + id="g883" + style="font-size:318px;font-weight:400;fill:#000080;visibility:visible;font-family:Helvetica embedded"> + <text + id="text885"> + <tspan + x="9279 9525 9736 9965 10143 10303 10481 10553" + y="26935" + id="tspan887">OVResult</tspan> + </text> + </g> + <text + id="text901" + style="font-size:318px;font-weight:400;fill:#000080;visibility:visible;font-family:Helvetica embedded"> + <tspan + x="12200 12378 12556 12645 12822 13068 13280 13508 13686 13847 14025 14097 14185 14291" + y="27559" + id="tspan903">got_OVResult()</tspan> + </text> + <text + id="text917" + style="font-size:423px;font-weight:400;fill:#000000;visibility:visible;font-family:Helvetica embedded"> + <tspan + x="8000 8330 8567 8660 8754 8991 9228 9346 9558 9795 9935 10028 10146" + y="21877" + id="tspan919">Online verify</tspan> + </text> + <text + id="text933" + style="font-size:318px;font-weight:400;fill:#008000;visibility:visible;font-family:Helvetica embedded"> + <tspan + x="4641 4870 5047 5310 5488 5649 5826 6004 6182 6343 6521 6626 6804 6982 7160 7338 7499 7587 7693" + y="23005" + id="tspan935">w_make_ov_request()</tspan> + </text> + <path + d="M 8000,6500 L 7900,6200 L 8100,6200 L 8000,6500 z" + id="path945" + style="fill:#008000;visibility:visible" /> + <path + d="M 8000,5700 L 8000,6260" + id="path949" + style="fill:none;stroke:#008000;visibility:visible" /> + <path + d="M 3900,5500 L 3700,5500 L 3700,11000 L 3900,11000" + id="path961" + style="fill:none;stroke:#000000;visibility:visible" /> + <path + d="M 3900,14500 L 3700,14500 L 3700,18600 L 3900,18600" + id="path973" + style="fill:none;stroke:#000000;visibility:visible" /> + <path + d="M 3900,22800 L 3700,22800 L 3700,26900 L 3900,26900" + id="path985" + style="fill:none;stroke:#000000;visibility:visible" /> + <text + id="text1001" + style="font-size:318px;font-weight:400;fill:#008000;visibility:visible;font-family:Helvetica embedded"> + <tspan + x="4492 4670 4776 4953 5131 5309 5487 5665 5842 5914 6092 6270 6376 6554 6731 6909 7087 7248 7426 7587 7692" + y="6506" + id="tspan1003">drbd_endio_read_sec()</tspan> + </text> + <text + id="text1017" + style="font-size:318px;font-weight:400;fill:#008000;visibility:visible;font-family:Helvetica embedded"> + <tspan + x="4034 4263 4440 4703 4881 5042 5219 5397 5503 5681 5842 6003 6180 6341 6519 6625 6803 6980 7158 7336 7497 7586 7692" + y="14708" + id="tspan1019">w_make_resync_request()</tspan> + </text> + <text + id="text1033" + style="font-size:318px;font-weight:400;fill:#008000;visibility:visible;font-family:Helvetica embedded"> + <tspan + x="5190 5419 5596 5774 5952 6113 6291 6468 6646 6824 6985 7146 7324 7586 7692" + y="16006" + id="tspan1035">w_e_send_csum()</tspan> + </text> + <path + d="M 8000,15501 L 7900,15201 L 8100,15201 L 8000,15501 z" + id="path1045" + style="fill:#008000;visibility:visible" /> + <path + d="M 8000,14701 L 8000,15261" + id="path1049" + style="fill:none;stroke:#008000;visibility:visible" /> + <text + id="text1065" + style="font-size:318px;font-weight:400;fill:#008000;visibility:visible;font-family:Helvetica embedded"> + <tspan + x="4492 4670 4776 4953 5131 5309 5487 5665 5842 5914 6092 6270 6376 6554 6731 6909 7087 7248 7426 7587 7692" + y="15507" + id="tspan1067">drbd_endio_read_sec()</tspan> + </text> + <path + d="M 16100,9000 L 16300,9000 L 16300,7500 L 16100,7500" + id="path1077" + style="fill:none;stroke:#000000;visibility:visible" /> + <path + d="M 16100,18000 L 16300,18000 L 16300,16500 L 16100,16500" + id="path1089" + style="fill:none;stroke:#000000;visibility:visible" /> + <path + d="M 16100,25000 L 16300,25000 L 16300,23500 L 16100,23500" + id="path1101" + style="fill:none;stroke:#000000;visibility:visible" /> + <text + id="text1117" + style="font-size:318px;font-weight:400;fill:#000000;visibility:visible;font-family:Helvetica embedded"> + <tspan + x="2026 2132 2293 2471 2648 2826 3004 3076 3254 3431 3503 3681 3787" + y="5402" + id="tspan1119">rs_begin_io()</tspan> + </text> + <text + id="text1133" + style="font-size:318px;font-weight:400;fill:#000000;visibility:visible;font-family:Helvetica embedded"> + <tspan + x="2027 2133 2294 2472 2649 2827 3005 3077 3255 3432 3504 3682 3788" + y="14402" + id="tspan1135">rs_begin_io()</tspan> + </text> + <text + id="text1149" + style="font-size:318px;font-weight:400;fill:#000000;visibility:visible;font-family:Helvetica embedded"> + <tspan + x="2026 2132 2293 2471 2648 2826 3004 3076 3254 3431 3503 3681 3787" + y="22602" + id="tspan1151">rs_begin_io()</tspan> + </text> + <text + id="text1165" + style="font-size:318px;font-weight:400;fill:#000000;visibility:visible;font-family:Helvetica embedded"> + <tspan + x="1426 1532 1693 1871 2031 2209 2472 2649 2721 2899 2988 3166 3344 3416 3593 3699" + y="11302" + id="tspan1167">rs_complete_io()</tspan> + </text> + <text + id="text1181" + style="font-size:318px;font-weight:400;fill:#000000;visibility:visible;font-family:Helvetica embedded"> + <tspan + x="1526 1632 1793 1971 2131 2309 2572 2749 2821 2999 3088 3266 3444 3516 3693 3799" + y="18931" + id="tspan1183">rs_complete_io()</tspan> + </text> + <text + id="text1197" + style="font-size:318px;font-weight:400;fill:#000000;visibility:visible;font-family:Helvetica embedded"> + <tspan + x="1526 1632 1793 1971 2131 2309 2572 2749 2821 2999 3088 3266 3444 3516 3693 3799" + y="27231" + id="tspan1199">rs_complete_io()</tspan> + </text> + <text + id="text1213" + style="font-size:318px;font-weight:400;fill:#000000;visibility:visible;font-family:Helvetica embedded"> + <tspan + x="16126 16232 16393 16571 16748 16926 17104 17176 17354 17531 17603 17781 17887" + y="7402" + id="tspan1215">rs_begin_io()</tspan> + </text> + <text + id="text1229" + style="font-size:318px;font-weight:400;fill:#000000;visibility:visible;font-family:Helvetica embedded"> + <tspan + x="16127 16233 16394 16572 16749 16927 17105 17177 17355 17532 17604 17782 17888" + y="16331" + id="tspan1231">rs_begin_io()</tspan> + </text> + <text + id="text1245" + style="font-size:318px;font-weight:400;fill:#000000;visibility:visible;font-family:Helvetica embedded"> + <tspan + x="16127 16233 16394 16572 16749 16927 17105 17177 17355 17532 17604 17782 17888" + y="23302" + id="tspan1247">rs_begin_io()</tspan> + </text> + <text + id="text1261" + style="font-size:318px;font-weight:400;fill:#000000;visibility:visible;font-family:Helvetica embedded"> + <tspan + x="16115 16221 16382 16560 16720 16898 17161 17338 17410 17588 17677 17855 18033 18105 18282 18388" + y="9302" + id="tspan1263">rs_complete_io()</tspan> + </text> + <text + id="text1277" + style="font-size:318px;font-weight:400;fill:#000000;visibility:visible;font-family:Helvetica embedded"> + <tspan + x="16115 16221 16382 16560 16720 16898 17161 17338 17410 17588 17677 17855 18033 18105 18282 18388" + y="18331" + id="tspan1279">rs_complete_io()</tspan> + </text> + <text + id="text1293" + style="font-size:318px;font-weight:400;fill:#000000;visibility:visible;font-family:Helvetica embedded"> + <tspan + x="16126 16232 16393 16571 16731 16909 17172 17349 17421 17599 17688 17866 18044 18116 18293 18399" + y="25302" + id="tspan1295">rs_complete_io()</tspan> + </text> +</svg> diff --git a/Documentation/blockdev/drbd/DRBD-data-packets.svg b/Documentation/blockdev/drbd/DRBD-data-packets.svg new file mode 100644 index 000000000000..48a1e2165fec --- /dev/null +++ b/Documentation/blockdev/drbd/DRBD-data-packets.svg @@ -0,0 +1,459 @@ +<?xml version="1.0" encoding="UTF-8" standalone="no"?> +<!-- Created with Inkscape (http://www.inkscape.org/) --> +<svg + xmlns:svg="http://www.w3.org/2000/svg" + xmlns="http://www.w3.org/2000/svg" + version="1.0" + width="210mm" + height="297mm" + viewBox="0 0 21000 29700" + id="svg2" + style="fill-rule:evenodd"> + <defs + id="defs4" /> + <g + id="Default" + style="visibility:visible"> + <desc + id="desc176">Master slide</desc> + </g> + <path + d="M 11999,19601 L 11899,19301 L 12099,19301 L 11999,19601 z" + id="path189" + style="fill:#008000;visibility:visible" /> + <path + d="M 11999,18801 L 11999,19361" + id="path193" + style="fill:none;stroke:#008000;visibility:visible" /> + <path + d="M 7999,21401 L 7899,21101 L 8099,21101 L 7999,21401 z" + id="path205" + style="fill:#008000;visibility:visible" /> + <path + d="M 7999,20601 L 7999,21161" + id="path209" + style="fill:none;stroke:#008000;visibility:visible" /> + <path + d="M 11999,18801 L 11685,18840 L 11724,18644 L 11999,18801 z" + id="path221" + style="fill:#008000;visibility:visible" /> + <path + d="M 7999,18001 L 11764,18754" + id="path225" + style="fill:none;stroke:#008000;visibility:visible" /> + <text + x="-3023.845" + y="1106.8124" + transform="matrix(0.9895258,-0.1443562,0.1443562,0.9895258,0,0)" + id="text243" + style="font-size:318px;font-weight:400;fill:#008000;visibility:visible;font-family:Helvetica embedded"> + <tspan + x="6115.1553 6344.1553 6555.1553 6784.1553 6962.1553 7051.1553 7228.1553 7457.1553 7635.1553 7813.1553 7885.1553" + y="21390.812" + id="tspan245">RSDataReply</tspan> + </text> + <path + d="M 7999,20601 L 8281,20458 L 8311,20655 L 7999,20601 z" + id="path255" + style="fill:#008000;visibility:visible" /> + <path + d="M 11999,20001 L 8236,20565" + id="path259" + style="fill:none;stroke:#008000;visibility:visible" /> + <text + x="3502.5356" + y="-2184.6621" + transform="matrix(0.9788674,0.2044961,-0.2044961,0.9788674,0,0)" + id="text277" + style="font-size:318px;font-weight:400;fill:#008000;visibility:visible;font-family:Helvetica embedded"> + <tspan + x="12321.536 12550.536 12761.536 12990.536 13168.536 13257.536 13434.536 13663.536 13841.536 14019.536 14196.536 14374.536 14535.536" + y="15854.338" + id="tspan279">RSDataRequest</tspan> + </text> + <text + id="text293" + style="font-size:318px;font-weight:400;fill:#008000;visibility:visible;font-family:Helvetica embedded"> + <tspan + x="4034 4263 4440 4703 4881 5042 5219 5397 5503 5681 5842 6003 6180 6341 6519 6625 6803 6980 7158 7336 7497 7586 7692" + y="17807" + id="tspan295">w_make_resync_request()</tspan> + </text> + <text + id="text309" + style="font-size:318px;font-weight:400;fill:#008000;visibility:visible;font-family:Helvetica embedded"> + <tspan + x="12199 12305 12483 12644 12821 12893 13054 13232 13410 13638 13816 13905 14083 14311 14489 14667 14845 15023 15184 15272 15378" + y="18806" + id="tspan311">receive_DataRequest()</tspan> + </text> + <text + id="text325" + style="font-size:318px;font-weight:400;fill:#008000;visibility:visible;font-family:Helvetica embedded"> + <tspan + x="12199 12377 12483 12660 12838 13016 13194 13372 13549 13621 13799 13977 14083 14261 14438 14616 14794 14955 15133 15294 15399" + y="19606" + id="tspan327">drbd_endio_read_sec()</tspan> + </text> + <text + id="text341" + style="font-size:318px;font-weight:400;fill:#008000;visibility:visible;font-family:Helvetica embedded"> + <tspan + x="12191 12420 12597 12775 12953 13131 13309 13486 13664 13770 13931 14109 14287 14375 14553 14731 14837 15015 15192 15298" + y="20007" + id="tspan343">w_e_end_rsdata_req()</tspan> + </text> + <text + id="text357" + style="font-size:318px;font-weight:400;fill:#008000;visibility:visible;font-family:Helvetica embedded"> + <tspan + x="4444 4550 4728 4889 5066 5138 5299 5477 5655 5883 6095 6324 6501 6590 6768 6997 7175 7352 7424 7585 7691" + y="20507" + id="tspan359">receive_RSDataReply()</tspan> + </text> + <text + id="text373" + style="font-size:318px;font-weight:400;fill:#008000;visibility:visible;font-family:Helvetica embedded"> + <tspan + x="4457 4635 4741 4918 5096 5274 5452 5630 5807 5879 6057 6235 6464 6569 6641 6730 6908 7086 7247 7425 7585 7691" + y="21407" + id="tspan375">drbd_endio_write_sec()</tspan> + </text> + <text + id="text389" + style="font-size:318px;font-weight:400;fill:#008000;visibility:visible;font-family:Helvetica embedded"> + <tspan + x="4647 4825 5003 5180 5358 5536 5714 5820 5997 6158 6319 6497 6658 6836 7013 7085 7263 7424 7585 7691" + y="21907" + id="tspan391">e_end_resync_block()</tspan> + </text> + <path + d="M 11999,22601 L 11685,22640 L 11724,22444 L 11999,22601 z" + id="path401" + style="fill:#000080;visibility:visible" /> + <path + d="M 7999,21801 L 11764,22554" + id="path405" + style="fill:none;stroke:#000080;visibility:visible" /> + <text + x="4290.3008" + y="-2369.6162" + transform="matrix(0.9788674,0.2044961,-0.2044961,0.9788674,0,0)" + id="text423" + style="font-size:318px;font-weight:400;fill:#000080;visibility:visible;font-family:Helvetica embedded"> + <tspan + x="13610.301 13911.301 14016.301 14088.301 14177.301 14355.301 14567.301 14728.301" + y="19573.385" + id="tspan425">WriteAck</tspan> + </text> + <text + id="text439" + style="font-size:318px;font-weight:400;fill:#000080;visibility:visible;font-family:Helvetica embedded"> + <tspan + x="12199 12377 12555 12644 12821 13033 13105 13283 13444 13604 13816 13977 14138 14244" + y="22559" + id="tspan441">got_BlockAck()</tspan> + </text> + <text + id="text455" + style="font-size:423px;font-weight:400;fill:#000000;visibility:visible;font-family:Helvetica embedded"> + <tspan + x="7999 8304 8541 8753 8964 9201 9413 9531 9769 9862 10099 10310 10522 10734 10852 10971 11208 11348 11585 11822" + y="16877" + id="tspan457">Resync blocks, 4-32K</tspan> + </text> + <path + d="M 12000,7601 L 11900,7301 L 12100,7301 L 12000,7601 z" + id="path467" + style="fill:#008000;visibility:visible" /> + <path + d="M 12000,6801 L 12000,7361" + id="path471" + style="fill:none;stroke:#008000;visibility:visible" /> + <path + d="M 12000,6801 L 11686,6840 L 11725,6644 L 12000,6801 z" + id="path483" + style="fill:#008000;visibility:visible" /> + <path + d="M 8000,6001 L 11765,6754" + id="path487" + style="fill:none;stroke:#008000;visibility:visible" /> + <text + x="-1288.1796" + y="1279.7666" + transform="matrix(0.9895258,-0.1443562,0.1443562,0.9895258,0,0)" + id="text505" + style="font-size:318px;font-weight:400;fill:#000080;visibility:visible;font-family:Helvetica embedded"> + <tspan + x="8174.8208 8475.8203 8580.8203 8652.8203 8741.8203 8919.8203 9131.8203 9292.8203" + y="9516.7666" + id="tspan507">WriteAck</tspan> + </text> + <path + d="M 8000,8601 L 8282,8458 L 8312,8655 L 8000,8601 z" + id="path517" + style="fill:#000080;visibility:visible" /> + <path + d="M 12000,8001 L 8237,8565" + id="path521" + style="fill:none;stroke:#000080;visibility:visible" /> + <text + x="1065.6655" + y="-2097.7664" + transform="matrix(0.9788674,0.2044961,-0.2044961,0.9788674,0,0)" + id="text539" + style="font-size:318px;font-weight:400;fill:#008000;visibility:visible;font-family:Helvetica embedded"> + <tspan + x="10682.666 10911.666 11088.666 11177.666" + y="4107.2339" + id="tspan541">Data</tspan> + </text> + <text + id="text555" + style="font-size:318px;font-weight:400;fill:#008000;visibility:visible;font-family:Helvetica embedded"> + <tspan + x="4746 4924 5030 5207 5385 5563 5826 6003 6164 6342 6520 6626 6803 6981 7159 7337 7498 7587 7692" + y="5505" + id="tspan557">drbd_make_request()</tspan> + </text> + <text + id="text571" + style="font-size:318px;font-weight:400;fill:#008000;visibility:visible;font-family:Helvetica embedded"> + <tspan + x="12200 12306 12484 12645 12822 12894 13055 13233 13411 13639 13817 13906 14084 14190" + y="6806" + id="tspan573">receive_Data()</tspan> + </text> + <text + id="text587" + style="font-size:318px;font-weight:400;fill:#008000;visibility:visible;font-family:Helvetica embedded"> + <tspan + x="12200 12378 12484 12661 12839 13017 13195 13373 13550 13622 13800 13978 14207 14312 14384 14473 14651 14829 14990 15168 15328 15434" + y="7606" + id="tspan589">drbd_endio_write_sec()</tspan> + </text> + <text + id="text603" + style="font-size:318px;font-weight:400;fill:#008000;visibility:visible;font-family:Helvetica embedded"> + <tspan + x="12192 12370 12548 12725 12903 13081 13259 13437 13509 13686 13847 14008 14114" + y="8007" + id="tspan605">e_end_block()</tspan> + </text> + <text + id="text619" + style="font-size:318px;font-weight:400;fill:#000080;visibility:visible;font-family:Helvetica embedded"> + <tspan + x="5647 5825 6003 6092 6269 6481 6553 6731 6892 7052 7264 7425 7586 7692" + y="8606" + id="tspan621">got_BlockAck()</tspan> + </text> + <text + id="text635" + style="font-size:423px;font-weight:400;fill:#000000;visibility:visible;font-family:Helvetica embedded"> + <tspan + x="8000 8305 8542 8779 9016 9109 9346 9486 9604 9956 10049 10189 10328 10565 10705 10942 11179 11298 11603 11742 11835 11954 12191 12310 12428 12665 12902 13139 13279 13516 13753" + y="4877" + id="tspan637">Regular mirrored write, 512-32K</tspan> + </text> + <text + id="text651" + style="font-size:318px;font-weight:400;fill:#008000;visibility:visible;font-family:Helvetica embedded"> + <tspan + x="5381 5610 5787 5948 6126 6304 6482 6659 6837 7015 7087 7265 7426 7587 7692" + y="6003" + id="tspan653">w_send_dblock()</tspan> + </text> + <path + d="M 8000,6800 L 7900,6500 L 8100,6500 L 8000,6800 z" + id="path663" + style="fill:#008000;visibility:visible" /> + <path + d="M 8000,6000 L 8000,6560" + id="path667" + style="fill:none;stroke:#008000;visibility:visible" /> + <text + id="text683" + style="font-size:318px;font-weight:400;fill:#008000;visibility:visible;font-family:Helvetica embedded"> + <tspan + x="4602 4780 4886 5063 5241 5419 5597 5775 5952 6024 6202 6380 6609 6714 6786 6875 7053 7231 7409 7515 7587 7692" + y="6905" + id="tspan685">drbd_endio_write_pri()</tspan> + </text> + <path + d="M 12000,13602 L 11900,13302 L 12100,13302 L 12000,13602 z" + id="path695" + style="fill:#008000;visibility:visible" /> + <path + d="M 12000,12802 L 12000,13362" + id="path699" + style="fill:none;stroke:#008000;visibility:visible" /> + <path + d="M 12000,12802 L 11686,12841 L 11725,12645 L 12000,12802 z" + id="path711" + style="fill:#008000;visibility:visible" /> + <path + d="M 8000,12002 L 11765,12755" + id="path715" + style="fill:none;stroke:#008000;visibility:visible" /> + <text + x="-2155.5266" + y="1201.5964" + transform="matrix(0.9895258,-0.1443562,0.1443562,0.9895258,0,0)" + id="text733" + style="font-size:318px;font-weight:400;fill:#008000;visibility:visible;font-family:Helvetica embedded"> + <tspan + x="7202.4736 7431.4736 7608.4736 7697.4736 7875.4736 8104.4736 8282.4736 8459.4736 8531.4736" + y="15454.597" + id="tspan735">DataReply</tspan> + </text> + <path + d="M 8000,14602 L 8282,14459 L 8312,14656 L 8000,14602 z" + id="path745" + style="fill:#008000;visibility:visible" /> + <path + d="M 12000,14002 L 8237,14566" + id="path749" + style="fill:none;stroke:#008000;visibility:visible" /> + <text + x="2280.3804" + y="-2103.2141" + transform="matrix(0.9788674,0.2044961,-0.2044961,0.9788674,0,0)" + id="text767" + style="font-size:318px;font-weight:400;fill:#008000;visibility:visible;font-family:Helvetica embedded"> + <tspan + x="11316.381 11545.381 11722.381 11811.381 11989.381 12218.381 12396.381 12573.381 12751.381 12929.381 13090.381" + y="9981.7861" + id="tspan769">DataRequest</tspan> + </text> + <text + id="text783" + style="font-size:318px;font-weight:400;fill:#008000;visibility:visible;font-family:Helvetica embedded"> + <tspan + x="4746 4924 5030 5207 5385 5563 5826 6003 6164 6342 6520 6626 6803 6981 7159 7337 7498 7587 7692" + y="11506" + id="tspan785">drbd_make_request()</tspan> + </text> + <text + id="text799" + style="font-size:318px;font-weight:400;fill:#008000;visibility:visible;font-family:Helvetica embedded"> + <tspan + x="12200 12306 12484 12645 12822 12894 13055 13233 13411 13639 13817 13906 14084 14312 14490 14668 14846 15024 15185 15273 15379" + y="12807" + id="tspan801">receive_DataRequest()</tspan> + </text> + <text + id="text815" + style="font-size:318px;font-weight:400;fill:#008000;visibility:visible;font-family:Helvetica embedded"> + <tspan + x="12200 12378 12484 12661 12839 13017 13195 13373 13550 13622 13800 13978 14084 14262 14439 14617 14795 14956 15134 15295 15400" + y="13607" + id="tspan817">drbd_endio_read_sec()</tspan> + </text> + <text + id="text831" + style="font-size:318px;font-weight:400;fill:#008000;visibility:visible;font-family:Helvetica embedded"> + <tspan + x="12192 12421 12598 12776 12954 13132 13310 13487 13665 13843 14021 14110 14288 14465 14571 14749 14927 15033" + y="14008" + id="tspan833">w_e_end_data_req()</tspan> + </text> + <g + id="g835" + style="visibility:visible"> + <desc + id="desc837">Drawing</desc> + <text + id="text847" + style="font-size:318px;font-weight:400;fill:#008000;font-family:Helvetica embedded"> + <tspan + x="4885 4991 5169 5330 5507 5579 5740 5918 6096 6324 6502 6591 6769 6997 7175 7353 7425 7586 7692" + y="14607" + id="tspan849">receive_DataReply()</tspan> + </text> + </g> + <text + id="text863" + style="font-size:423px;font-weight:400;fill:#000000;visibility:visible;font-family:Helvetica embedded"> + <tspan + x="8000 8305 8398 8610 8821 8914 9151 9363 9575 9693 9833 10070 10307 10544 10663 10781 11018 11255 11493 11632 11869 12106" + y="10878" + id="tspan865">Diskless read, 512-32K</tspan> + </text> + <text + id="text879" + style="font-size:318px;font-weight:400;fill:#008000;visibility:visible;font-family:Helvetica embedded"> + <tspan + x="5029 5258 5435 5596 5774 5952 6130 6307 6413 6591 6769 6947 7125 7230 7408 7586 7692" + y="12004" + id="tspan881">w_send_read_req()</tspan> + </text> + <text + id="text895" + style="font-size:423px;font-weight:400;fill:#000000;visibility:visible;font-family:Helvetica embedded"> + <tspan + x="6961 7266 7571 7854 8159 8278 8515 8633 8870 9107 9226 9463 9581 9700 9793 10030" + y="2806" + id="tspan897">DRBD 8 data flow</tspan> + </text> + <path + d="M 3900,5300 L 3700,5300 L 3700,7000 L 3900,7000" + id="path907" + style="fill:none;stroke:#000000;visibility:visible" /> + <path + d="M 3900,17600 L 3700,17600 L 3700,22000 L 3900,22000" + id="path919" + style="fill:none;stroke:#000000;visibility:visible" /> + <path + d="M 16100,20000 L 16300,20000 L 16300,18500 L 16100,18500" + id="path931" + style="fill:none;stroke:#000000;visibility:visible" /> + <text + id="text947" + style="font-size:318px;font-weight:400;fill:#000000;visibility:visible;font-family:Helvetica embedded"> + <tspan + x="2126 2304 2376 2554 2731 2909 3087 3159 3337 3515 3587 3764 3870" + y="5202" + id="tspan949">al_begin_io()</tspan> + </text> + <text + id="text963" + style="font-size:318px;font-weight:400;fill:#000000;visibility:visible;font-family:Helvetica embedded"> + <tspan + x="1632 1810 1882 2060 2220 2398 2661 2839 2910 3088 3177 3355 3533 3605 3783 3888" + y="7331" + id="tspan965">al_complete_io()</tspan> + </text> + <text + id="text979" + style="font-size:318px;font-weight:400;fill:#000000;visibility:visible;font-family:Helvetica embedded"> + <tspan + x="2126 2232 2393 2571 2748 2926 3104 3176 3354 3531 3603 3781 3887" + y="17431" + id="tspan981">rs_begin_io()</tspan> + </text> + <text + id="text995" + style="font-size:318px;font-weight:400;fill:#000000;visibility:visible;font-family:Helvetica embedded"> + <tspan + x="1626 1732 1893 2071 2231 2409 2672 2849 2921 3099 3188 3366 3544 3616 3793 3899" + y="22331" + id="tspan997">rs_complete_io()</tspan> + </text> + <text + id="text1011" + style="font-size:318px;font-weight:400;fill:#000000;visibility:visible;font-family:Helvetica embedded"> + <tspan + x="16027 16133 16294 16472 16649 16827 17005 17077 17255 17432 17504 17682 17788" + y="18402" + id="tspan1013">rs_begin_io()</tspan> + </text> + <text + id="text1027" + style="font-size:318px;font-weight:400;fill:#000000;visibility:visible;font-family:Helvetica embedded"> + <tspan + x="16115 16221 16382 16560 16720 16898 17161 17338 17410 17588 17677 17855 18033 18105 18282 18388" + y="20331" + id="tspan1029">rs_complete_io()</tspan> + </text> +</svg> diff --git a/Documentation/blockdev/drbd/README.txt b/Documentation/blockdev/drbd/README.txt new file mode 100644 index 000000000000..627b0a1bf35e --- /dev/null +++ b/Documentation/blockdev/drbd/README.txt @@ -0,0 +1,16 @@ +Description + + DRBD is a shared-nothing, synchronously replicated block device. It + is designed to serve as a building block for high availability + clusters and in this context, is a "drop-in" replacement for shared + storage. Simplistically, you could see it as a network RAID 1. + + Please visit http://www.drbd.org to find out more. + +The here included files are intended to help understand the implementation + +DRBD-8.3-data-packets.svg, DRBD-data-packets.svg + relates some functions, and write packets. + +conn-states-8.dot, disk-states-8.dot, node-states-8.dot + The sub graphs of DRBD's state transitions diff --git a/Documentation/blockdev/drbd/conn-states-8.dot b/Documentation/blockdev/drbd/conn-states-8.dot new file mode 100644 index 000000000000..025e8cf5e64a --- /dev/null +++ b/Documentation/blockdev/drbd/conn-states-8.dot @@ -0,0 +1,18 @@ +digraph conn_states { + StandAllone -> WFConnection [ label = "ioctl_set_net()" ] + WFConnection -> Unconnected [ label = "unable to bind()" ] + WFConnection -> WFReportParams [ label = "in connect() after accept" ] + WFReportParams -> StandAllone [ label = "checks in receive_param()" ] + WFReportParams -> Connected [ label = "in receive_param()" ] + WFReportParams -> WFBitMapS [ label = "sync_handshake()" ] + WFReportParams -> WFBitMapT [ label = "sync_handshake()" ] + WFBitMapS -> SyncSource [ label = "receive_bitmap()" ] + WFBitMapT -> SyncTarget [ label = "receive_bitmap()" ] + SyncSource -> Connected + SyncTarget -> Connected + SyncSource -> PausedSyncS + SyncTarget -> PausedSyncT + PausedSyncS -> SyncSource + PausedSyncT -> SyncTarget + Connected -> WFConnection [ label = "* on network error" ] +} diff --git a/Documentation/blockdev/drbd/disk-states-8.dot b/Documentation/blockdev/drbd/disk-states-8.dot new file mode 100644 index 000000000000..d06cfb46fb98 --- /dev/null +++ b/Documentation/blockdev/drbd/disk-states-8.dot @@ -0,0 +1,16 @@ +digraph disk_states { + Diskless -> Inconsistent [ label = "ioctl_set_disk()" ] + Diskless -> Consistent [ label = "ioctl_set_disk()" ] + Diskless -> Outdated [ label = "ioctl_set_disk()" ] + Consistent -> Outdated [ label = "receive_param()" ] + Consistent -> UpToDate [ label = "receive_param()" ] + Consistent -> Inconsistent [ label = "start resync" ] + Outdated -> Inconsistent [ label = "start resync" ] + UpToDate -> Inconsistent [ label = "ioctl_replicate" ] + Inconsistent -> UpToDate [ label = "resync completed" ] + Consistent -> Failed [ label = "io completion error" ] + Outdated -> Failed [ label = "io completion error" ] + UpToDate -> Failed [ label = "io completion error" ] + Inconsistent -> Failed [ label = "io completion error" ] + Failed -> Diskless [ label = "sending notify to peer" ] +} diff --git a/Documentation/blockdev/drbd/drbd-connection-state-overview.dot b/Documentation/blockdev/drbd/drbd-connection-state-overview.dot new file mode 100644 index 000000000000..6d9cf0a7b11d --- /dev/null +++ b/Documentation/blockdev/drbd/drbd-connection-state-overview.dot @@ -0,0 +1,85 @@ +// vim: set sw=2 sts=2 : +digraph { + rankdir=BT + bgcolor=white + + node [shape=plaintext] + node [fontcolor=black] + + StandAlone [ style=filled,fillcolor=gray,label=StandAlone ] + + node [fontcolor=lightgray] + + Unconnected [ label=Unconnected ] + + CommTrouble [ shape=record, + label="{communication loss|{Timeout|BrokenPipe|NetworkFailure}}" ] + + node [fontcolor=gray] + + subgraph cluster_try_connect { + label="try to connect, handshake" + rank=max + WFConnection [ label=WFConnection ] + WFReportParams [ label=WFReportParams ] + } + + TearDown [ label=TearDown ] + + Connected [ label=Connected,style=filled,fillcolor=green,fontcolor=black ] + + node [fontcolor=lightblue] + + StartingSyncS [ label=StartingSyncS ] + StartingSyncT [ label=StartingSyncT ] + + subgraph cluster_bitmap_exchange { + node [fontcolor=red] + fontcolor=red + label="new application (WRITE?) requests blocked\lwhile bitmap is exchanged" + + WFBitMapT [ label=WFBitMapT ] + WFSyncUUID [ label=WFSyncUUID ] + WFBitMapS [ label=WFBitMapS ] + } + + node [fontcolor=blue] + + cluster_resync [ shape=record,label="{<any>resynchronisation process running\l'concurrent' application requests allowed|{{<T>PausedSyncT\nSyncTarget}|{<S>PausedSyncS\nSyncSource}}}" ] + + node [shape=box,fontcolor=black] + + // drbdadm [label="drbdadm connect"] + // handshake [label="drbd_connect()\ndrbd_do_handshake\ndrbd_sync_handshake() etc."] + // comm_error [label="communication trouble"] + + // + // edges + // -------------------------------------- + + StandAlone -> Unconnected [ label="drbdadm connect" ] + Unconnected -> StandAlone [ label="drbdadm disconnect\lor serious communication trouble" ] + Unconnected -> WFConnection [ label="receiver thread is started" ] + WFConnection -> WFReportParams [ headlabel="accept()\land/or \lconnect()\l" ] + + WFReportParams -> StandAlone [ label="during handshake\lpeers do not agree\labout something essential" ] + WFReportParams -> Connected [ label="data identical\lno sync needed",color=green,fontcolor=green ] + + WFReportParams -> WFBitMapS + WFReportParams -> WFBitMapT + WFBitMapT -> WFSyncUUID [minlen=0.1,constraint=false] + + WFBitMapS -> cluster_resync:S + WFSyncUUID -> cluster_resync:T + + edge [color=green] + cluster_resync:any -> Connected [ label="resnyc done",fontcolor=green ] + + edge [color=red] + WFReportParams -> CommTrouble + Connected -> CommTrouble + cluster_resync:any -> CommTrouble + edge [color=black] + CommTrouble -> Unconnected [label="receiver thread is stopped" ] + +} diff --git a/Documentation/blockdev/drbd/node-states-8.dot b/Documentation/blockdev/drbd/node-states-8.dot new file mode 100644 index 000000000000..4a2b00c23547 --- /dev/null +++ b/Documentation/blockdev/drbd/node-states-8.dot @@ -0,0 +1,14 @@ +digraph node_states { + Secondary -> Primary [ label = "ioctl_set_state()" ] + Primary -> Secondary [ label = "ioctl_set_state()" ] +} + +digraph peer_states { + Secondary -> Primary [ label = "recv state packet" ] + Primary -> Secondary [ label = "recv state packet" ] + Primary -> Unknown [ label = "connection lost" ] + Secondary -> Unknown [ label = "connection lost" ] + Unknown -> Primary [ label = "connected" ] + Unknown -> Secondary [ label = "connected" ] +} + diff --git a/Documentation/btmrvl.txt b/Documentation/btmrvl.txt new file mode 100644 index 000000000000..34916a46c099 --- /dev/null +++ b/Documentation/btmrvl.txt @@ -0,0 +1,119 @@ +======================================================================= + README for btmrvl driver +======================================================================= + + +All commands are used via debugfs interface. + +===================== +Set/get driver configurations: + +Path: /debug/btmrvl/config/ + +gpiogap=[n] +hscfgcmd + These commands are used to configure the host sleep parameters. + bit 8:0 -- Gap + bit 16:8 -- GPIO + + where GPIO is the pin number of GPIO used to wake up the host. + It could be any valid GPIO pin# (e.g. 0-7) or 0xff (SDIO interface + wakeup will be used instead). + + where Gap is the gap in milli seconds between wakeup signal and + wakeup event, or 0xff for special host sleep setting. + + Usage: + # Use SDIO interface to wake up the host and set GAP to 0x80: + echo 0xff80 > /debug/btmrvl/config/gpiogap + echo 1 > /debug/btmrvl/config/hscfgcmd + + # Use GPIO pin #3 to wake up the host and set GAP to 0xff: + echo 0x03ff > /debug/btmrvl/config/gpiogap + echo 1 > /debug/btmrvl/config/hscfgcmd + +psmode=[n] +pscmd + These commands are used to enable/disable auto sleep mode + + where the option is: + 1 -- Enable auto sleep mode + 0 -- Disable auto sleep mode + + Usage: + # Enable auto sleep mode + echo 1 > /debug/btmrvl/config/psmode + echo 1 > /debug/btmrvl/config/pscmd + + # Disable auto sleep mode + echo 0 > /debug/btmrvl/config/psmode + echo 1 > /debug/btmrvl/config/pscmd + + +hsmode=[n] +hscmd + These commands are used to enable host sleep or wake up firmware + + where the option is: + 1 -- Enable host sleep + 0 -- Wake up firmware + + Usage: + # Enable host sleep + echo 1 > /debug/btmrvl/config/hsmode + echo 1 > /debug/btmrvl/config/hscmd + + # Wake up firmware + echo 0 > /debug/btmrvl/config/hsmode + echo 1 > /debug/btmrvl/config/hscmd + + +====================== +Get driver status: + +Path: /debug/btmrvl/status/ + +Usage: + cat /debug/btmrvl/status/<args> + +where the args are: + +curpsmode + This command displays current auto sleep status. + +psstate + This command display the power save state. + +hsstate + This command display the host sleep state. + +txdnldrdy + This command displays the value of Tx download ready flag. + + +===================== + +Use hcitool to issue raw hci command, refer to hcitool manual + + Usage: Hcitool cmd <ogf> <ocf> [Parameters] + + Interface Control Command + hcitool cmd 0x3f 0x5b 0xf5 0x01 0x00 --Enable All interface + hcitool cmd 0x3f 0x5b 0xf5 0x01 0x01 --Enable Wlan interface + hcitool cmd 0x3f 0x5b 0xf5 0x01 0x02 --Enable BT interface + hcitool cmd 0x3f 0x5b 0xf5 0x00 0x00 --Disable All interface + hcitool cmd 0x3f 0x5b 0xf5 0x00 0x01 --Disable Wlan interface + hcitool cmd 0x3f 0x5b 0xf5 0x00 0x02 --Disable BT interface + +======================================================================= + + +SD8688 firmware: + +/lib/firmware/sd8688_helper.bin +/lib/firmware/sd8688.bin + + +The images can be downloaded from: + +git.infradead.org/users/dwmw2/linux-firmware.git/libertas/ diff --git a/Documentation/cgroups/blkio-controller.txt b/Documentation/cgroups/blkio-controller.txt new file mode 100644 index 000000000000..630879cd9a42 --- /dev/null +++ b/Documentation/cgroups/blkio-controller.txt @@ -0,0 +1,135 @@ + Block IO Controller + =================== +Overview +======== +cgroup subsys "blkio" implements the block io controller. There seems to be +a need of various kinds of IO control policies (like proportional BW, max BW) +both at leaf nodes as well as at intermediate nodes in a storage hierarchy. +Plan is to use the same cgroup based management interface for blkio controller +and based on user options switch IO policies in the background. + +In the first phase, this patchset implements proportional weight time based +division of disk policy. It is implemented in CFQ. Hence this policy takes +effect only on leaf nodes when CFQ is being used. + +HOWTO +===== +You can do a very simple testing of running two dd threads in two different +cgroups. Here is what you can do. + +- Enable group scheduling in CFQ + CONFIG_CFQ_GROUP_IOSCHED=y + +- Compile and boot into kernel and mount IO controller (blkio). + + mount -t cgroup -o blkio none /cgroup + +- Create two cgroups + mkdir -p /cgroup/test1/ /cgroup/test2 + +- Set weights of group test1 and test2 + echo 1000 > /cgroup/test1/blkio.weight + echo 500 > /cgroup/test2/blkio.weight + +- Create two same size files (say 512MB each) on same disk (file1, file2) and + launch two dd threads in different cgroup to read those files. + + sync + echo 3 > /proc/sys/vm/drop_caches + + dd if=/mnt/sdb/zerofile1 of=/dev/null & + echo $! > /cgroup/test1/tasks + cat /cgroup/test1/tasks + + dd if=/mnt/sdb/zerofile2 of=/dev/null & + echo $! > /cgroup/test2/tasks + cat /cgroup/test2/tasks + +- At macro level, first dd should finish first. To get more precise data, keep + on looking at (with the help of script), at blkio.disk_time and + blkio.disk_sectors files of both test1 and test2 groups. This will tell how + much disk time (in milli seconds), each group got and how many secotors each + group dispatched to the disk. We provide fairness in terms of disk time, so + ideally io.disk_time of cgroups should be in proportion to the weight. + +Various user visible config options +=================================== +CONFIG_CFQ_GROUP_IOSCHED + - Enables group scheduling in CFQ. Currently only 1 level of group + creation is allowed. + +CONFIG_DEBUG_CFQ_IOSCHED + - Enables some debugging messages in blktrace. Also creates extra + cgroup file blkio.dequeue. + +Config options selected automatically +===================================== +These config options are not user visible and are selected/deselected +automatically based on IO scheduler configuration. + +CONFIG_BLK_CGROUP + - Block IO controller. Selected by CONFIG_CFQ_GROUP_IOSCHED. + +CONFIG_DEBUG_BLK_CGROUP + - Debug help. Selected by CONFIG_DEBUG_CFQ_IOSCHED. + +Details of cgroup files +======================= +- blkio.weight + - Specifies per cgroup weight. + + Currently allowed range of weights is from 100 to 1000. + +- blkio.time + - disk time allocated to cgroup per device in milliseconds. First + two fields specify the major and minor number of the device and + third field specifies the disk time allocated to group in + milliseconds. + +- blkio.sectors + - number of sectors transferred to/from disk by the group. First + two fields specify the major and minor number of the device and + third field specifies the number of sectors transferred by the + group to/from the device. + +- blkio.dequeue + - Debugging aid only enabled if CONFIG_DEBUG_CFQ_IOSCHED=y. This + gives the statistics about how many a times a group was dequeued + from service tree of the device. First two fields specify the major + and minor number of the device and third field specifies the number + of times a group was dequeued from a particular device. + +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. + +What works +========== +- Currently only sync IO queues are support. All the buffered writes are + still system wide and not per group. Hence we will not see service + differentiation between buffered writes between groups. diff --git a/Documentation/cgroups/cgroups.txt b/Documentation/cgroups/cgroups.txt index 6eb1a97e88ce..0b33bfe7dde9 100644 --- a/Documentation/cgroups/cgroups.txt +++ b/Documentation/cgroups/cgroups.txt @@ -227,7 +227,14 @@ as the path relative to the root of the cgroup file system. Each cgroup is represented by a directory in the cgroup file system containing the following files describing that cgroup: - - tasks: list of tasks (by pid) attached to that cgroup + - tasks: list of tasks (by pid) attached to that cgroup. This list + is not guaranteed to be sorted. Writing a thread id into this file + moves the thread into this cgroup. + - cgroup.procs: list of tgids in the cgroup. This list is not + guaranteed to be sorted or free of duplicate tgids, and userspace + should sort/uniquify the list if this property is required. + Writing a tgid into this file moves all threads with that tgid into + this cgroup. - notify_on_release flag: run the release agent on exit? - release_agent: the path to use for release notifications (this file exists in the top cgroup only) @@ -374,7 +381,7 @@ Now you want to do something with this cgroup. In this directory you can find several files: # ls -notify_on_release tasks +cgroup.procs notify_on_release tasks (plus whatever files added by the attached subsystems) Now attach your shell to this cgroup: @@ -408,6 +415,26 @@ You can attach the current shell task by echoing 0: # echo 0 > tasks +2.3 Mounting hierarchies by name +-------------------------------- + +Passing the name=<x> option when mounting a cgroups hierarchy +associates the given name with the hierarchy. This can be used when +mounting a pre-existing hierarchy, in order to refer to it by name +rather than by its set of active subsystems. Each hierarchy is either +nameless, or has a unique name. + +The name should match [\w.-]+ + +When passing a name=<x> option for a new hierarchy, you need to +specify subsystems manually; the legacy behaviour of mounting all +subsystems when none are explicitly specified is not supported when +you give a subsystem a name. + +The name of the subsystem appears as part of the hierarchy description +in /proc/mounts and /proc/<pid>/cgroups. + + 3. Kernel API ============= @@ -501,7 +528,7 @@ rmdir() will fail with it. From this behavior, pre_destroy() can be called multiple times against a cgroup. int can_attach(struct cgroup_subsys *ss, struct cgroup *cgrp, - struct task_struct *task) + struct task_struct *task, bool threadgroup) (cgroup_mutex held by caller) Called prior to moving a task into a cgroup; if the subsystem @@ -509,14 +536,20 @@ returns an error, this will abort the attach operation. If a NULL task is passed, then a successful result indicates that *any* unspecified task can be moved into the cgroup. Note that this isn't called on a fork. If this method returns 0 (success) then this should -remain valid while the caller holds cgroup_mutex. +remain valid while the caller holds cgroup_mutex. If threadgroup is +true, then a successful result indicates that all threads in the given +thread's threadgroup can be moved together. void attach(struct cgroup_subsys *ss, struct cgroup *cgrp, - struct cgroup *old_cgrp, struct task_struct *task) + struct cgroup *old_cgrp, struct task_struct *task, + bool threadgroup) (cgroup_mutex held by caller) Called after the task has been attached to the cgroup, to allow any post-attachment activity that requires memory allocations or blocking. +If threadgroup is true, the subsystem should take care of all threads +in the specified thread's threadgroup. Currently does not support any +subsystem that might need the old_cgrp for every thread in the group. void fork(struct cgroup_subsy *ss, struct task_struct *task) diff --git a/Documentation/cgroups/memory.txt b/Documentation/cgroups/memory.txt index 23d1262c0775..b871f2552b45 100644 --- a/Documentation/cgroups/memory.txt +++ b/Documentation/cgroups/memory.txt @@ -179,6 +179,9 @@ The reclaim algorithm has not been modified for cgroups, except that pages that are selected for reclaiming come from the per cgroup LRU list. +NOTE: Reclaim does not work for the root cgroup, since we cannot set any +limits on the root cgroup. + 2. Locking The memory controller uses the following hierarchy @@ -210,6 +213,7 @@ We can alter the memory limit: NOTE: We can use a suffix (k, K, m, M, g or G) to indicate values in kilo, mega or gigabytes. NOTE: We can write "-1" to reset the *.limit_in_bytes(unlimited). +NOTE: We cannot set limits on the root cgroup any more. # cat /cgroups/0/memory.limit_in_bytes 4194304 @@ -375,7 +379,42 @@ cgroups created below it. NOTE2: This feature can be enabled/disabled per subtree. -7. TODO +7. Soft limits + +Soft limits allow for greater sharing of memory. The idea behind soft limits +is to allow control groups to use as much of the memory as needed, provided + +a. There is no memory contention +b. They do not exceed their hard limit + +When the system detects memory contention or low memory control groups +are pushed back to their soft limits. If the soft limit of each control +group is very high, they are pushed back as much as possible to make +sure that one control group does not starve the others of memory. + +Please note that soft limits is a best effort feature, it comes with +no guarantees, but it does its best to make sure that when memory is +heavily contended for, memory is allocated based on the soft limit +hints/setup. Currently soft limit based reclaim is setup such that +it gets invoked from balance_pgdat (kswapd). + +7.1 Interface + +Soft limits can be setup by using the following commands (in this example we +assume a soft limit of 256 megabytes) + +# echo 256M > memory.soft_limit_in_bytes + +If we want to change this to 1G, we can at any time use + +# echo 1G > memory.soft_limit_in_bytes + +NOTE1: Soft limits take effect over a long period of time, since they involve + reclaiming memory for balancing between memory cgroups +NOTE2: It is recommended to set the soft limit always below the hard limit, + otherwise the hard limit will take precedence. + +8. TODO 1. Add support for accounting huge pages (as a separate controller) 2. Make per-cgroup scanner reclaim not-shared pages first diff --git a/Documentation/connector/Makefile b/Documentation/connector/Makefile index 8df1a7285a06..d98e4df98e24 100644 --- a/Documentation/connector/Makefile +++ b/Documentation/connector/Makefile @@ -9,3 +9,8 @@ hostprogs-y := ucon always := $(hostprogs-y) HOSTCFLAGS_ucon.o += -I$(objtree)/usr/include + +all: modules + +modules clean: + $(MAKE) -C ../.. SUBDIRS=$(PWD) $@ diff --git a/Documentation/connector/cn_test.c b/Documentation/connector/cn_test.c index 6a5be5d5c8e4..b07add3467f1 100644 --- a/Documentation/connector/cn_test.c +++ b/Documentation/connector/cn_test.c @@ -19,6 +19,8 @@ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA */ +#define pr_fmt(fmt) "cn_test: " fmt + #include <linux/kernel.h> #include <linux/module.h> #include <linux/moduleparam.h> @@ -27,18 +29,17 @@ #include <linux/connector.h> -static struct cb_id cn_test_id = { 0x123, 0x456 }; +static struct cb_id cn_test_id = { CN_NETLINK_USERS + 3, 0x456 }; static char cn_test_name[] = "cn_test"; static struct sock *nls; static struct timer_list cn_test_timer; -void cn_test_callback(void *data) +static void cn_test_callback(struct cn_msg *msg, struct netlink_skb_parms *nsp) { - struct cn_msg *msg = (struct cn_msg *)data; - - printk("%s: %lu: idx=%x, val=%x, seq=%u, ack=%u, len=%d: %s.\n", - __func__, jiffies, msg->id.idx, msg->id.val, - msg->seq, msg->ack, msg->len, (char *)msg->data); + pr_info("%s: %lu: idx=%x, val=%x, seq=%u, ack=%u, len=%d: %s.\n", + __func__, jiffies, msg->id.idx, msg->id.val, + msg->seq, msg->ack, msg->len, + msg->len ? (char *)msg->data : ""); } /* @@ -63,9 +64,7 @@ static int cn_test_want_notify(void) skb = alloc_skb(size, GFP_ATOMIC); if (!skb) { - printk(KERN_ERR "Failed to allocate new skb with size=%u.\n", - size); - + pr_err("failed to allocate new skb with size=%u\n", size); return -ENOMEM; } @@ -114,12 +113,12 @@ static int cn_test_want_notify(void) //netlink_broadcast(nls, skb, 0, ctl->group, GFP_ATOMIC); netlink_unicast(nls, skb, 0, 0); - printk(KERN_INFO "Request was sent. Group=0x%x.\n", ctl->group); + pr_info("request was sent: group=0x%x\n", ctl->group); return 0; nlmsg_failure: - printk(KERN_ERR "Failed to send %u.%u\n", msg->seq, msg->ack); + pr_err("failed to send %u.%u\n", msg->seq, msg->ack); kfree_skb(skb); return -EINVAL; } @@ -131,6 +130,8 @@ static void cn_test_timer_func(unsigned long __data) struct cn_msg *m; char data[32]; + pr_debug("%s: timer fired with data %lu\n", __func__, __data); + m = kzalloc(sizeof(*m) + sizeof(data), GFP_ATOMIC); if (m) { @@ -150,7 +151,7 @@ static void cn_test_timer_func(unsigned long __data) cn_test_timer_counter++; - mod_timer(&cn_test_timer, jiffies + HZ); + mod_timer(&cn_test_timer, jiffies + msecs_to_jiffies(1000)); } static int cn_test_init(void) @@ -168,8 +169,10 @@ static int cn_test_init(void) } setup_timer(&cn_test_timer, cn_test_timer_func, 0); - cn_test_timer.expires = jiffies + HZ; - add_timer(&cn_test_timer); + mod_timer(&cn_test_timer, jiffies + msecs_to_jiffies(1000)); + + pr_info("initialized with id={%u.%u}\n", + cn_test_id.idx, cn_test_id.val); return 0; diff --git a/Documentation/connector/connector.txt b/Documentation/connector/connector.txt index ad6e0ba7b38c..78c9466a9aa8 100644 --- a/Documentation/connector/connector.txt +++ b/Documentation/connector/connector.txt @@ -5,10 +5,10 @@ Kernel Connector. Kernel connector - new netlink based userspace <-> kernel space easy to use communication module. -Connector driver adds possibility to connect various agents using -netlink based network. One must register callback and -identifier. When driver receives special netlink message with -appropriate identifier, appropriate callback will be called. +The Connector driver makes it easy to connect various agents using a +netlink based network. One must register a callback and an identifier. +When the driver receives a special netlink message with the appropriate +identifier, the appropriate callback will be called. From the userspace point of view it's quite straightforward: @@ -17,13 +17,13 @@ From the userspace point of view it's quite straightforward: send(); recv(); -But if kernelspace want to use full power of such connections, driver -writer must create special sockets, must know about struct sk_buff -handling... Connector allows any kernelspace agents to use netlink -based networking for inter-process communication in a significantly +But if kernelspace wants to use the full power of such connections, the +driver writer must create special sockets, must know about struct sk_buff +handling, etc... The Connector driver allows any kernelspace agents to use +netlink based networking for inter-process communication in a significantly easier way: -int cn_add_callback(struct cb_id *id, char *name, void (*callback) (void *)); +int cn_add_callback(struct cb_id *id, char *name, void (*callback) (struct cn_msg *, struct netlink_skb_parms *)); void cn_netlink_send(struct cn_msg *msg, u32 __group, int gfp_mask); struct cb_id @@ -32,15 +32,15 @@ struct cb_id __u32 val; }; -idx and val are unique identifiers which must be registered in -connector.h for in-kernel usage. void (*callback) (void *) - is a -callback function which will be called when message with above idx.val -will be received by connector core. Argument for that function must +idx and val are unique identifiers which must be registered in the +connector.h header for in-kernel usage. void (*callback) (void *) is a +callback function which will be called when a message with above idx.val +is received by the connector core. The argument for that function must be dereferenced to struct cn_msg *. struct cn_msg { - struct cb_id id; + struct cb_id id; __u32 seq; __u32 ack; @@ -53,94 +53,97 @@ struct cn_msg Connector interfaces. /*****************************************/ -int cn_add_callback(struct cb_id *id, char *name, void (*callback) (void *)); +int cn_add_callback(struct cb_id *id, char *name, void (*callback) (struct cn_msg *, struct netlink_skb_parms *)); -Registers new callback with connector core. + Registers new callback with connector core. + + struct cb_id *id - unique connector's user identifier. + It must be registered in connector.h for legal in-kernel users. + char *name - connector's callback symbolic name. + void (*callback) (struct cn..) - connector's callback. + cn_msg and the sender's credentials -struct cb_id *id - unique connector's user identifier. - It must be registered in connector.h for legal in-kernel users. -char *name - connector's callback symbolic name. -void (*callback) (void *) - connector's callback. - Argument must be dereferenced to struct cn_msg *. void cn_del_callback(struct cb_id *id); -Unregisters new callback with connector core. + Unregisters new callback with connector core. + + struct cb_id *id - unique connector's user identifier. -struct cb_id *id - unique connector's user identifier. int cn_netlink_send(struct cn_msg *msg, u32 __groups, int gfp_mask); -Sends message to the specified groups. It can be safely called from -softirq context, but may silently fail under strong memory pressure. -If there are no listeners for given group -ESRCH can be returned. + Sends message to the specified groups. It can be safely called from + softirq context, but may silently fail under strong memory pressure. + If there are no listeners for given group -ESRCH can be returned. -struct cn_msg * - message header(with attached data). -u32 __group - destination group. + struct cn_msg * - message header(with attached data). + u32 __group - destination group. If __group is zero, then appropriate group will be searched through all registered connector users, and message will be delivered to the group which was created for user with the same ID as in msg. If __group is not zero, then message will be delivered to the specified group. -int gfp_mask - GFP mask. + int gfp_mask - GFP mask. -Note: When registering new callback user, connector core assigns -netlink group to the user which is equal to it's id.idx. + Note: When registering new callback user, connector core assigns + netlink group to the user which is equal to it's id.idx. /*****************************************/ Protocol description. /*****************************************/ -Current offers transport layer with fixed header. Recommended -protocol which uses such header is following: +The current framework offers a transport layer with fixed headers. The +recommended protocol which uses such a header is as following: msg->seq and msg->ack are used to determine message genealogy. When -someone sends message it puts there locally unique sequence and random -acknowledge numbers. Sequence number may be copied into +someone sends a message, they use a locally unique sequence and random +acknowledge number. The sequence number may be copied into nlmsghdr->nlmsg_seq too. -Sequence number is incremented with each message to be sent. +The sequence number is incremented with each message sent. -If we expect reply to our message, then sequence number in received -message MUST be the same as in original message, and acknowledge -number MUST be the same + 1. +If you expect a reply to the message, then the sequence number in the +received message MUST be the same as in the original message, and the +acknowledge number MUST be the same + 1. -If we receive message and it's sequence number is not equal to one we -are expecting, then it is new message. If we receive message and it's -sequence number is the same as one we are expecting, but it's -acknowledge is not equal acknowledge number in original message + 1, -then it is new message. +If we receive a message and its sequence number is not equal to one we +are expecting, then it is a new message. If we receive a message and +its sequence number is the same as one we are expecting, but its +acknowledge is not equal to the acknowledge number in the original +message + 1, then it is a new message. -Obviously, protocol header contains above id. +Obviously, the protocol header contains the above id. -connector allows event notification in the following form: kernel +The connector allows event notification in the following form: kernel driver or userspace process can ask connector to notify it when -selected id's will be turned on or off(registered or unregistered it's -callback). It is done by sending special command to connector -driver(it also registers itself with id={-1, -1}). +selected ids will be turned on or off (registered or unregistered its +callback). It is done by sending a special command to the connector +driver (it also registers itself with id={-1, -1}). -As example of usage Documentation/connector now contains cn_test.c - -testing module which uses connector to request notification and to -send messages. +As example of this usage can be found in the cn_test.c module which +uses the connector to request notification and to send messages. /*****************************************/ Reliability. /*****************************************/ -Netlink itself is not reliable protocol, that means that messages can +Netlink itself is not a reliable protocol. That means that messages can be lost due to memory pressure or process' receiving queue overflowed, -so caller is warned must be prepared. That is why struct cn_msg [main -connector's message header] contains u32 seq and u32 ack fields. +so caller is warned that it must be prepared. That is why the struct +cn_msg [main connector's message header] contains u32 seq and u32 ack +fields. /*****************************************/ Userspace usage. /*****************************************/ + 2.6.14 has a new netlink socket implementation, which by default does not -allow to send data to netlink groups other than 1. -So, if to use netlink socket (for example using connector) -with different group number userspace application must subscribe to -that group. It can be achieved by following pseudocode: +allow people to send data to netlink groups other than 1. +So, if you wish to use a netlink socket (for example using connector) +with a different group number, the userspace application must subscribe to +that group first. It can be achieved by the following pseudocode: s = socket(PF_NETLINK, SOCK_DGRAM, NETLINK_CONNECTOR); @@ -160,8 +163,8 @@ if (bind(s, (struct sockaddr *)&l_local, sizeof(struct sockaddr_nl)) == -1) { } Where 270 above is SOL_NETLINK, and 1 is a NETLINK_ADD_MEMBERSHIP socket -option. To drop multicast subscription one should call above socket option -with NETLINK_DROP_MEMBERSHIP parameter which is defined as 0. +option. To drop a multicast subscription, one should call the above socket +option with the NETLINK_DROP_MEMBERSHIP parameter which is defined as 0. 2.6.14 netlink code only allows to select a group which is less or equal to the maximum group number, which is used at netlink_kernel_create() time. diff --git a/Documentation/connector/ucon.c b/Documentation/connector/ucon.c index c5092ad0ce4b..4848db8c71ff 100644 --- a/Documentation/connector/ucon.c +++ b/Documentation/connector/ucon.c @@ -30,18 +30,24 @@ #include <arpa/inet.h> +#include <stdbool.h> #include <stdio.h> #include <stdlib.h> #include <unistd.h> #include <string.h> #include <errno.h> #include <time.h> +#include <getopt.h> #include <linux/connector.h> #define DEBUG #define NETLINK_CONNECTOR 11 +/* Hopefully your userspace connector.h matches this kernel */ +#define CN_TEST_IDX CN_NETLINK_USERS + 3 +#define CN_TEST_VAL 0x456 + #ifdef DEBUG #define ulog(f, a...) fprintf(stdout, f, ##a) #else @@ -83,6 +89,25 @@ static int netlink_send(int s, struct cn_msg *msg) return err; } +static void usage(void) +{ + printf( + "Usage: ucon [options] [output file]\n" + "\n" + "\t-h\tthis help screen\n" + "\t-s\tsend buffers to the test module\n" + "\n" + "The default behavior of ucon is to subscribe to the test module\n" + "and wait for state messages. Any ones received are dumped to the\n" + "specified output file (or stdout). The test module is assumed to\n" + "have an id of {%u.%u}\n" + "\n" + "If you get no output, then verify the cn_test module id matches\n" + "the expected id above.\n" + , CN_TEST_IDX, CN_TEST_VAL + ); +} + int main(int argc, char *argv[]) { int s; @@ -94,17 +119,34 @@ int main(int argc, char *argv[]) FILE *out; time_t tm; struct pollfd pfd; + bool send_msgs = false; - if (argc < 2) - out = stdout; - else { - out = fopen(argv[1], "a+"); + while ((s = getopt(argc, argv, "hs")) != -1) { + switch (s) { + case 's': + send_msgs = true; + break; + + case 'h': + usage(); + return 0; + + default: + /* getopt() outputs an error for us */ + usage(); + return 1; + } + } + + if (argc != optind) { + out = fopen(argv[optind], "a+"); if (!out) { ulog("Unable to open %s for writing: %s\n", argv[1], strerror(errno)); out = stdout; } - } + } else + out = stdout; memset(buf, 0, sizeof(buf)); @@ -115,9 +157,11 @@ int main(int argc, char *argv[]) } l_local.nl_family = AF_NETLINK; - l_local.nl_groups = 0x123; /* bitmask of requested groups */ + l_local.nl_groups = -1; /* bitmask of requested groups */ l_local.nl_pid = 0; + ulog("subscribing to %u.%u\n", CN_TEST_IDX, CN_TEST_VAL); + if (bind(s, (struct sockaddr *)&l_local, sizeof(struct sockaddr_nl)) == -1) { perror("bind"); close(s); @@ -130,15 +174,15 @@ int main(int argc, char *argv[]) setsockopt(s, SOL_NETLINK, NETLINK_ADD_MEMBERSHIP, &on, sizeof(on)); } #endif - if (0) { + if (send_msgs) { int i, j; memset(buf, 0, sizeof(buf)); data = (struct cn_msg *)buf; - data->id.idx = 0x123; - data->id.val = 0x456; + data->id.idx = CN_TEST_IDX; + data->id.val = CN_TEST_VAL; data->seq = seq++; data->ack = 0; data->len = 0; diff --git a/Documentation/cpu-freq/cpu-drivers.txt b/Documentation/cpu-freq/cpu-drivers.txt index 75a58d14d3cf..6c30e930c122 100644 --- a/Documentation/cpu-freq/cpu-drivers.txt +++ b/Documentation/cpu-freq/cpu-drivers.txt @@ -92,9 +92,9 @@ policy->cpuinfo.max_freq - the minimum and maximum frequency (in kHz) which is supported by this CPU policy->cpuinfo.transition_latency the time it takes on this CPU to - switch between two frequencies (if - appropriate, else specify - CPUFREQ_ETERNAL) + switch between two frequencies in + nanoseconds (if appropriate, else + specify CPUFREQ_ETERNAL) policy->cur The current operating frequency of this CPU (if appropriate) diff --git a/Documentation/cpu-freq/governors.txt b/Documentation/cpu-freq/governors.txt index aed082f49d09..737988fca64d 100644 --- a/Documentation/cpu-freq/governors.txt +++ b/Documentation/cpu-freq/governors.txt @@ -145,8 +145,8 @@ show_sampling_rate_max: THIS INTERFACE IS DEPRECATED, DON'T USE IT. up_threshold: defines what the average CPU usage between the samplings of 'sampling_rate' needs to be for the kernel to make a decision on whether it should increase the frequency. For example when it is set -to its default value of '80' it means that between the checking -intervals the CPU needs to be on average more than 80% in use to then +to its default value of '95' it means that between the checking +intervals the CPU needs to be on average more than 95% in use to then decide that the CPU frequency needs to be increased. ignore_nice_load: this parameter takes a value of '0' or '1'. When diff --git a/Documentation/cpu-freq/user-guide.txt b/Documentation/cpu-freq/user-guide.txt index 5d5f5fadd1c2..04f6b32993e6 100644 --- a/Documentation/cpu-freq/user-guide.txt +++ b/Documentation/cpu-freq/user-guide.txt @@ -176,7 +176,9 @@ scaling_governor, and by "echoing" the name of another work on some specific architectures or processors. -cpuinfo_cur_freq : Current speed of the CPU, in KHz. +cpuinfo_cur_freq : Current frequency of the CPU as obtained from + the hardware, in KHz. This is the frequency + the CPU actually runs at. scaling_available_frequencies : List of available frequencies, in KHz. @@ -196,7 +198,21 @@ related_cpus : List of CPUs that need some sort of frequency scaling_driver : Hardware driver for cpufreq. -scaling_cur_freq : Current frequency of the CPU, in KHz. +scaling_cur_freq : Current frequency of the CPU as determined by + the governor and cpufreq core, in KHz. This is + the frequency the kernel thinks the CPU runs + at. + +bios_limit : If the BIOS tells the OS to limit a CPU to + lower frequencies, the user can read out the + maximum available frequency from this file. + This typically can happen through (often not + intended) BIOS settings, restrictions + triggered through a service processor or other + BIOS/HW based implementations. + This does not cover thermal ACPI limitations + which can be detected through the generic + thermal driver. If you have selected the "userspace" governor which allows you to set the CPU operating frequency to a specific value, you can read out diff --git a/Documentation/cpu-hotplug.txt b/Documentation/cpu-hotplug.txt index 9d620c153b04..a99d7031cdf9 100644 --- a/Documentation/cpu-hotplug.txt +++ b/Documentation/cpu-hotplug.txt @@ -49,6 +49,12 @@ maxcpus=n Restrict boot time cpus to n. Say if you have 4 cpus, using additional_cpus=n (*) Use this to limit hotpluggable cpus. This option sets cpu_possible_map = cpu_present_map + additional_cpus +cede_offline={"off","on"} Use this option to disable/enable putting offlined + processors to an extended H_CEDE state on + supported pseries platforms. + If nothing is specified, + cede_offline is set to "on". + (*) Option valid only for following architectures - ia64 @@ -309,41 +315,26 @@ A: The following are what is required for CPU hotplug infrastructure to work Q: I need to ensure that a particular cpu is not removed when there is some work specific to this cpu is in progress. -A: First switch the current thread context to preferred cpu +A: There are two ways. If your code can be run in interrupt context, use + smp_call_function_single(), otherwise use work_on_cpu(). Note that + work_on_cpu() is slow, and can fail due to out of memory: int my_func_on_cpu(int cpu) { - cpumask_t saved_mask, new_mask = CPU_MASK_NONE; - int curr_cpu, err = 0; - - saved_mask = current->cpus_allowed; - cpu_set(cpu, new_mask); - err = set_cpus_allowed(current, new_mask); - - if (err) - return err; - - /* - * If we got scheduled out just after the return from - * set_cpus_allowed() before running the work, this ensures - * we stay locked. - */ - curr_cpu = get_cpu(); - - if (curr_cpu != cpu) { - err = -EAGAIN; - goto ret; - } else { - /* - * Do work : But cant sleep, since get_cpu() disables preempt - */ - } - ret: - put_cpu(); - set_cpus_allowed(current, saved_mask); - return err; - } - + int err; + get_online_cpus(); + if (!cpu_online(cpu)) + err = -EINVAL; + else +#if NEEDS_BLOCKING + err = work_on_cpu(cpu, __my_func_on_cpu, NULL); +#else + smp_call_function_single(cpu, __my_func_on_cpu, &err, + true); +#endif + put_online_cpus(); + return err; + } Q: How do we determine how many CPUs are available for hotplug. A: There is no clear spec defined way from ACPI that can give us that diff --git a/Documentation/cputopology.txt b/Documentation/cputopology.txt index b41f3e58aefa..f1c5c4bccd3e 100644 --- a/Documentation/cputopology.txt +++ b/Documentation/cputopology.txt @@ -1,15 +1,28 @@ -Export cpu topology info via sysfs. Items (attributes) are similar +Export CPU topology info via sysfs. Items (attributes) are similar to /proc/cpuinfo. 1) /sys/devices/system/cpu/cpuX/topology/physical_package_id: -represent the physical package id of cpu X; + + physical package id of cpuX. Typically corresponds to a physical + socket number, but the actual value is architecture and platform + dependent. + 2) /sys/devices/system/cpu/cpuX/topology/core_id: -represent the cpu core id to cpu X; + + the CPU core ID of cpuX. Typically it is the hardware platform's + identifier (rather than the kernel's). The actual value is + architecture and platform dependent. + 3) /sys/devices/system/cpu/cpuX/topology/thread_siblings: -represent the thread siblings to cpu X in the same core; + + internel kernel map of cpuX's hardware threads within the same + core as cpuX + 4) /sys/devices/system/cpu/cpuX/topology/core_siblings: -represent the thread siblings to cpu X in the same physical package; + + internal kernel map of cpuX's hardware threads within the same + physical_package_id. To implement it in an architecture-neutral way, a new source file, drivers/base/topology.c, is to export the 4 attributes. @@ -32,32 +45,32 @@ not defined by include/asm-XXX/topology.h: 3) thread_siblings: just the given CPU 4) core_siblings: just the given CPU -Additionally, cpu topology information is provided under +Additionally, CPU topology information is provided under /sys/devices/system/cpu and includes these files. The internal source for the output is in brackets ("[]"). - kernel_max: the maximum cpu index allowed by the kernel configuration. + kernel_max: the maximum CPU index allowed by the kernel configuration. [NR_CPUS-1] - offline: cpus that are not online because they have been + offline: CPUs that are not online because they have been HOTPLUGGED off (see cpu-hotplug.txt) or exceed the limit - of cpus allowed by the kernel configuration (kernel_max + of CPUs allowed by the kernel configuration (kernel_max above). [~cpu_online_mask + cpus >= NR_CPUS] - online: cpus that are online and being scheduled [cpu_online_mask] + online: CPUs that are online and being scheduled [cpu_online_mask] - possible: cpus that have been allocated resources and can be + possible: CPUs that have been allocated resources and can be brought online if they are present. [cpu_possible_mask] - present: cpus that have been identified as being present in the + present: CPUs that have been identified as being present in the system. [cpu_present_mask] The format for the above output is compatible with cpulist_parse() [see <linux/cpumask.h>]. Some examples follow. -In this example, there are 64 cpus in the system but cpus 32-63 exceed +In this example, there are 64 CPUs in the system but cpus 32-63 exceed the kernel max which is limited to 0..31 by the NR_CPUS config option -being 32. Note also that cpus 2 and 4-31 are not online but could be +being 32. Note also that CPUs 2 and 4-31 are not online but could be brought online as they are both present and possible. kernel_max: 31 @@ -67,8 +80,8 @@ brought online as they are both present and possible. present: 0-31 In this example, the NR_CPUS config option is 128, but the kernel was -started with possible_cpus=144. There are 4 cpus in the system and cpu2 -was manually taken offline (and is the only cpu that can be brought +started with possible_cpus=144. There are 4 CPUs in the system and cpu2 +was manually taken offline (and is the only CPU that can be brought online.) kernel_max: 127 @@ -78,4 +91,4 @@ online.) present: 0-3 See cpu-hotplug.txt for the possible_cpus=NUM kernel start parameter -as well as more information on the various cpumask's. +as well as more information on the various cpumasks. diff --git a/Documentation/crypto/async-tx-api.txt b/Documentation/crypto/async-tx-api.txt index 9f59fcbf5d82..ba046b8fa92f 100644 --- a/Documentation/crypto/async-tx-api.txt +++ b/Documentation/crypto/async-tx-api.txt @@ -54,20 +54,23 @@ features surfaced as a result: 3.1 General format of the API: struct dma_async_tx_descriptor * -async_<operation>(<op specific parameters>, - enum async_tx_flags flags, - struct dma_async_tx_descriptor *dependency, - dma_async_tx_callback callback_routine, - void *callback_parameter); +async_<operation>(<op specific parameters>, struct async_submit ctl *submit) 3.2 Supported operations: -memcpy - memory copy between a source and a destination buffer -memset - fill a destination buffer with a byte value -xor - xor a series of source buffers and write the result to a - destination buffer -xor_zero_sum - xor a series of source buffers and set a flag if the - result is zero. The implementation attempts to prevent - writes to memory +memcpy - memory copy between a source and a destination buffer +memset - fill a destination buffer with a byte value +xor - xor a series of source buffers and write the result to a + destination buffer +xor_val - xor a series of source buffers and set a flag if the + result is zero. The implementation attempts to prevent + writes to memory +pq - generate the p+q (raid6 syndrome) from a series of source buffers +pq_val - validate that a p and or q buffer are in sync with a given series of + sources +datap - (raid6_datap_recov) recover a raid6 data block and the p block + from the given sources +2data - (raid6_2data_recov) recover 2 raid6 data blocks from the given + sources 3.3 Descriptor management: The return value is non-NULL and points to a 'descriptor' when the operation @@ -80,8 +83,8 @@ acknowledged by the application before the offload engine driver is allowed to recycle (or free) the descriptor. A descriptor can be acked by one of the following methods: 1/ setting the ASYNC_TX_ACK flag if no child operations are to be submitted -2/ setting the ASYNC_TX_DEP_ACK flag to acknowledge the parent - descriptor of a new operation. +2/ submitting an unacknowledged descriptor as a dependency to another + async_tx call will implicitly set the acknowledged state. 3/ calling async_tx_ack() on the descriptor. 3.4 When does the operation execute? @@ -119,30 +122,42 @@ of an operation. Perform a xor->copy->xor operation where each operation depends on the result from the previous operation: -void complete_xor_copy_xor(void *param) +void callback(void *param) { - printk("complete\n"); + struct completion *cmp = param; + + complete(cmp); } -int run_xor_copy_xor(struct page **xor_srcs, - int xor_src_cnt, - struct page *xor_dest, - size_t xor_len, - struct page *copy_src, - struct page *copy_dest, - size_t copy_len) +void run_xor_copy_xor(struct page **xor_srcs, + int xor_src_cnt, + struct page *xor_dest, + size_t xor_len, + struct page *copy_src, + struct page *copy_dest, + size_t copy_len) { struct dma_async_tx_descriptor *tx; + addr_conv_t addr_conv[xor_src_cnt]; + struct async_submit_ctl submit; + addr_conv_t addr_conv[NDISKS]; + struct completion cmp; + + init_async_submit(&submit, ASYNC_TX_XOR_DROP_DST, NULL, NULL, NULL, + addr_conv); + tx = async_xor(xor_dest, xor_srcs, 0, xor_src_cnt, xor_len, &submit) - tx = async_xor(xor_dest, xor_srcs, 0, xor_src_cnt, xor_len, - ASYNC_TX_XOR_DROP_DST, NULL, NULL, NULL); - tx = async_memcpy(copy_dest, copy_src, 0, 0, copy_len, - ASYNC_TX_DEP_ACK, tx, NULL, NULL); - tx = async_xor(xor_dest, xor_srcs, 0, xor_src_cnt, xor_len, - ASYNC_TX_XOR_DROP_DST | ASYNC_TX_DEP_ACK | ASYNC_TX_ACK, - tx, complete_xor_copy_xor, NULL); + submit->depend_tx = tx; + tx = async_memcpy(copy_dest, copy_src, 0, 0, copy_len, &submit); + + init_completion(&cmp); + init_async_submit(&submit, ASYNC_TX_XOR_DROP_DST | ASYNC_TX_ACK, tx, + callback, &cmp, addr_conv); + tx = async_xor(xor_dest, xor_srcs, 0, xor_src_cnt, xor_len, &submit); async_tx_issue_pending_all(); + + wait_for_completion(&cmp); } See include/linux/async_tx.h for more information on the flags. See the diff --git a/Documentation/debugging-via-ohci1394.txt b/Documentation/debugging-via-ohci1394.txt index 59a91e5c6909..611f5a5499b1 100644 --- a/Documentation/debugging-via-ohci1394.txt +++ b/Documentation/debugging-via-ohci1394.txt @@ -64,14 +64,14 @@ be used to view the printk buffer of a remote machine, even with live update. Bernhard Kaindl enhanced firescope to support accessing 64-bit machines from 32-bit firescope and vice versa: -- ftp://ftp.suse.de/private/bk/firewire/tools/firescope-0.2.2.tar.bz2 +- http://halobates.de/firewire/firescope-0.2.2.tar.bz2 and he implemented fast system dump (alpha version - read README.txt): -- ftp://ftp.suse.de/private/bk/firewire/tools/firedump-0.1.tar.bz2 +- http://halobates.de/firewire/firedump-0.1.tar.bz2 There is also a gdb proxy for firewire which allows to use gdb to access data which can be referenced from symbols found by gdb in vmlinux: -- ftp://ftp.suse.de/private/bk/firewire/tools/fireproxy-0.33.tar.bz2 +- http://halobates.de/firewire/fireproxy-0.33.tar.bz2 The latest version of this gdb proxy (fireproxy-0.34) can communicate (not yet stable) with kgdb over an memory-based communication module (kgdbom). @@ -178,7 +178,7 @@ Step-by-step instructions for using firescope with early OHCI initialization: Notes ----- -Documentation and specifications: ftp://ftp.suse.de/private/bk/firewire/docs +Documentation and specifications: http://halobates.de/firewire/ FireWire is a trademark of Apple Inc. - for more information please refer to: http://en.wikipedia.org/wiki/FireWire diff --git a/Documentation/device-mapper/snapshot.txt b/Documentation/device-mapper/snapshot.txt index a5009c8300f3..e3a77b215135 100644 --- a/Documentation/device-mapper/snapshot.txt +++ b/Documentation/device-mapper/snapshot.txt @@ -8,13 +8,19 @@ the block device which are also writable without interfering with the original content; *) To create device "forks", i.e. multiple different versions of the same data stream. +*) To merge a snapshot of a block device back into the snapshot's origin +device. +In the first two cases, dm copies only the chunks of data that get +changed and uses a separate copy-on-write (COW) block device for +storage. -In both cases, dm copies only the chunks of data that get changed and -uses a separate copy-on-write (COW) block device for storage. +For snapshot merge the contents of the COW storage are merged back into +the origin device. -There are two dm targets available: snapshot and snapshot-origin. +There are three dm targets available: +snapshot, snapshot-origin, and snapshot-merge. *) snapshot-origin <origin> @@ -40,8 +46,25 @@ The difference is that for transient snapshots less metadata must be saved on disk - they can be kept in memory by the kernel. -How this is used by LVM2 -======================== +* snapshot-merge <origin> <COW device> <persistent> <chunksize> + +takes the same table arguments as the snapshot target except it only +works with persistent snapshots. This target assumes the role of the +"snapshot-origin" target and must not be loaded if the "snapshot-origin" +is still present for <origin>. + +Creates a merging snapshot that takes control of the changed chunks +stored in the <COW device> of an existing snapshot, through a handover +procedure, and merges these chunks back into the <origin>. Once merging +has started (in the background) the <origin> may be opened and the merge +will continue while I/O is flowing to it. Changes to the <origin> are +deferred until the merging snapshot's corresponding chunk(s) have been +merged. Once merging has started the snapshot device, associated with +the "snapshot" target, will return -EIO when accessed. + + +How snapshot is used by LVM2 +============================ When you create the first LVM2 snapshot of a volume, four dm devices are used: 1) a device containing the original mapping table of the source volume; @@ -72,3 +95,30 @@ brw------- 1 root root 254, 12 29 ago 18:15 /dev/mapper/volumeGroup-snap-cow brw------- 1 root root 254, 13 29 ago 18:15 /dev/mapper/volumeGroup-snap brw------- 1 root root 254, 10 29 ago 18:14 /dev/mapper/volumeGroup-base + +How snapshot-merge is used by LVM2 +================================== +A merging snapshot assumes the role of the "snapshot-origin" while +merging. As such the "snapshot-origin" is replaced with +"snapshot-merge". The "-real" device is not changed and the "-cow" +device is renamed to <origin name>-cow to aid LVM2's cleanup of the +merging snapshot after it completes. The "snapshot" that hands over its +COW device to the "snapshot-merge" is deactivated (unless using lvchange +--refresh); but if it is left active it will simply return I/O errors. + +A snapshot will merge into its origin with the following command: + +lvconvert --merge volumeGroup/snap + +we'll now have this situation: + +# dmsetup table|grep volumeGroup + +volumeGroup-base-real: 0 2097152 linear 8:19 384 +volumeGroup-base-cow: 0 204800 linear 8:19 2097536 +volumeGroup-base: 0 2097152 snapshot-merge 254:11 254:12 P 16 + +# ls -lL /dev/mapper/volumeGroup-* +brw------- 1 root root 254, 11 29 ago 18:15 /dev/mapper/volumeGroup-base-real +brw------- 1 root root 254, 12 29 ago 18:16 /dev/mapper/volumeGroup-base-cow +brw------- 1 root root 254, 10 29 ago 18:16 /dev/mapper/volumeGroup-base diff --git a/Documentation/dontdiff b/Documentation/dontdiff index 88519daab6e9..3ad6acead949 100644 --- a/Documentation/dontdiff +++ b/Documentation/dontdiff @@ -65,6 +65,7 @@ aicdb.h* asm-offsets.h asm_offsets.h autoconf.h* +av_permissions.h bbootsect bin2c binkernel.spec @@ -95,12 +96,15 @@ docproc elf2ecoff elfconfig.h* fixdep +flask.h fore200e_mkfirm fore200e_pca_fw.c* gconf gen-devlist gen_crc32table gen_init_cpio +generated +genheaders genksyms *_gray256.c ihex2fw @@ -152,7 +156,6 @@ piggy.gz piggyback pnmtologo ppc_defs.h* -promcon_tbl.c pss_boot.h qconf raid6altivec*.c diff --git a/Documentation/driver-model/driver.txt b/Documentation/driver-model/driver.txt index 60120fb3b961..d2cd6fb8ba9e 100644 --- a/Documentation/driver-model/driver.txt +++ b/Documentation/driver-model/driver.txt @@ -226,5 +226,5 @@ struct driver_attribute driver_attr_debug; This can then be used to add and remove the attribute from the driver's directory using: -int driver_create_file(struct device_driver *, struct driver_attribute *); -void driver_remove_file(struct device_driver *, struct driver_attribute *); +int driver_create_file(struct device_driver *, const struct driver_attribute *); +void driver_remove_file(struct device_driver *, const struct driver_attribute *); diff --git a/Documentation/dvb/README.dvb-usb b/Documentation/dvb/README.dvb-usb index bf2a9cdfe7bb..c8238e44ed6b 100644 --- a/Documentation/dvb/README.dvb-usb +++ b/Documentation/dvb/README.dvb-usb @@ -85,7 +85,7 @@ http://www.linuxtv.org/wiki/index.php/DVB_USB - moved transfer control (pid filter, fifo control) from usb driver to frontend, it seems better settled there (added xfer_ops-struct) - created a common files for frontends (mc/p/mb) - 2004-09-28 - added support for a new device (Unkown, vendor ID is Hyper-Paltek) + 2004-09-28 - added support for a new device (Unknown, vendor ID is Hyper-Paltek) 2004-09-20 - added support for a new device (Compro DVB-U2000), thanks to Amaury Demol for reporting - changed usb TS transfer method (several urbs, stopping transfer diff --git a/Documentation/dvb/get_dvb_firmware b/Documentation/dvb/get_dvb_firmware index 3d1b0ab70c8e..14b7b5a3bcb9 100644 --- a/Documentation/dvb/get_dvb_firmware +++ b/Documentation/dvb/get_dvb_firmware @@ -25,7 +25,8 @@ use IO::Handle; "tda10046lifeview", "av7110", "dec2000t", "dec2540t", "dec3000s", "vp7041", "dibusb", "nxt2002", "nxt2004", "or51211", "or51132_qam", "or51132_vsb", "bluebird", - "opera1", "cx231xx", "cx18", "cx23885", "pvrusb2", "mpc718" ); + "opera1", "cx231xx", "cx18", "cx23885", "pvrusb2", "mpc718", + "af9015"); # Check args syntax() if (scalar(@ARGV) != 1); @@ -514,6 +515,40 @@ sub bluebird { $outfile; } +sub af9015 { + my $sourcefile = "download.ashx?file=57"; + my $url = "http://www.ite.com.tw/EN/Services/$sourcefile"; + my $hash = "ff5b096ed47c080870eacdab2de33ad6"; + my $outfile = "dvb-usb-af9015.fw"; + my $tmpdir = tempdir(DIR => "/tmp", CLEANUP => 1); + my $fwoffset = 0x22708; + my $fwlength = 18225; + my ($chunklength, $buf, $rcount); + + checkstandard(); + + wgetfile($sourcefile, $url); + unzip($sourcefile, $tmpdir); + verify("$tmpdir/Driver/Files/AF15BDA.sys", $hash); + + open INFILE, '<', "$tmpdir/Driver/Files/AF15BDA.sys"; + open OUTFILE, '>', $outfile; + + sysseek(INFILE, $fwoffset, SEEK_SET); + while($fwlength > 0) { + $chunklength = 55; + $chunklength = $fwlength if ($chunklength > $fwlength); + $rcount = sysread(INFILE, $buf, $chunklength); + die "Ran out of data\n" if ($rcount != $chunklength); + syswrite(OUTFILE, $buf); + sysread(INFILE, $buf, 8); + $fwlength -= $rcount + 8; + } + + close OUTFILE; + close INFILE; +} + # --------------------------------------------------------------- # Utilities diff --git a/Documentation/dvb/technisat.txt b/Documentation/dvb/technisat.txt index 3f435ffb289c..f0cc4f2d8365 100644 --- a/Documentation/dvb/technisat.txt +++ b/Documentation/dvb/technisat.txt @@ -4,9 +4,12 @@ How to set up the Technisat/B2C2 Flexcop devices 1) Find out what device you have ================================ +Important Notice: The driver does NOT support Technisat USB 2 devices! + First start your linux box with a shipped kernel: lspci -vvv for a PCI device (lsusb -vvv for an USB device) will show you for example: -02:0b.0 Network controller: Techsan Electronics Co Ltd B2C2 FlexCopII DVB chip / Technisat SkyStar2 DVB card (rev 02) +02:0b.0 Network controller: Techsan Electronics Co Ltd B2C2 FlexCopII DVB chip / + Technisat SkyStar2 DVB card (rev 02) dmesg | grep frontend may show you for example: DVB: registering frontend 0 (Conexant CX24123/CX24109)... @@ -14,62 +17,62 @@ DVB: registering frontend 0 (Conexant CX24123/CX24109)... 2) Kernel compilation: ====================== -If the Technisat is the only TV device in your box get rid of unnecessary modules and check this one: -"Multimedia devices" => "Customise analog and hybrid tuner modules to build" -In this directory uncheck every driver which is activated there (except "Simple tuner support" for case 9 only). +If the Flexcop / Technisat is the only DVB / TV / Radio device in your box + get rid of unnecessary modules and check this one: +"Multimedia support" => "Customise analog and hybrid tuner modules to build" +In this directory uncheck every driver which is activated there + (except "Simple tuner support" for ATSC 3rd generation only -> see case 9 please). Then please activate: 2a) Main module part: +"Multimedia support" => "DVB/ATSC adapters" + => "Technisat/B2C2 FlexcopII(b) and FlexCopIII adapters" -a.)"Multimedia devices" => "DVB/ATSC adapters" => "Technisat/B2C2 FlexcopII(b) and FlexCopIII adapters" -b.)"Multimedia devices" => "DVB/ATSC adapters" => "Technisat/B2C2 FlexcopII(b) and FlexCopIII adapters" => "Technisat/B2C2 Air/Sky/Cable2PC PCI" in case of a PCI card -OR -c.)"Multimedia devices" => "DVB/ATSC adapters" => "Technisat/B2C2 FlexcopII(b) and FlexCopIII adapters" => "Technisat/B2C2 Air/Sky/Cable2PC USB" in case of an USB 1.1 adapter -d.)"Multimedia devices" => "DVB/ATSC adapters" => "Technisat/B2C2 FlexcopII(b) and FlexCopIII adapters" => "Enable debug for the B2C2 FlexCop drivers" -Notice: d.) is helpful for troubleshooting +a.) => "Technisat/B2C2 Air/Sky/Cable2PC PCI" (PCI card) or +b.) => "Technisat/B2C2 Air/Sky/Cable2PC USB" (USB 1.1 adapter) + and for troubleshooting purposes: +c.) => "Enable debug for the B2C2 FlexCop drivers" -2b) Frontend module part: +2b) Frontend / Tuner / Demodulator module part: +"Multimedia support" => "DVB/ATSC adapters" + => "Customise the frontend modules to build" "Customise DVB frontends" => 1.) SkyStar DVB-S Revision 2.3: -a.)"Multimedia devices" => "Customise DVB frontends" => "Customise the frontend modules to build" -b.)"Multimedia devices" => "Customise DVB frontends" => "Zarlink VP310/MT312/ZL10313 based" +a.) => "Zarlink VP310/MT312/ZL10313 based" +b.) => "Generic I2C PLL based tuners" 2.) SkyStar DVB-S Revision 2.6: -a.)"Multimedia devices" => "Customise DVB frontends" => "Customise the frontend modules to build" -b.)"Multimedia devices" => "Customise DVB frontends" => "ST STV0299 based" +a.) => "ST STV0299 based" +b.) => "Generic I2C PLL based tuners" 3.) SkyStar DVB-S Revision 2.7: -a.)"Multimedia devices" => "Customise DVB frontends" => "Customise the frontend modules to build" -b.)"Multimedia devices" => "Customise DVB frontends" => "Samsung S5H1420 based" -c.)"Multimedia devices" => "Customise DVB frontends" => "Integrant ITD1000 Zero IF tuner for DVB-S/DSS" -d.)"Multimedia devices" => "Customise DVB frontends" => "ISL6421 SEC controller" +a.) => "Samsung S5H1420 based" +b.) => "Integrant ITD1000 Zero IF tuner for DVB-S/DSS" +c.) => "ISL6421 SEC controller" 4.) SkyStar DVB-S Revision 2.8: -a.)"Multimedia devices" => "Customise DVB frontends" => "Customise the frontend modules to build" -b.)"Multimedia devices" => "Customise DVB frontends" => "Conexant CX24113/CX24128 tuner for DVB-S/DSS" -c.)"Multimedia devices" => "Customise DVB frontends" => "Conexant CX24123 based" -d.)"Multimedia devices" => "Customise DVB frontends" => "ISL6421 SEC controller" +a.) => "Conexant CX24123 based" +b.) => "Conexant CX24113/CX24128 tuner for DVB-S/DSS" +c.) => "ISL6421 SEC controller" 5.) AirStar DVB-T card: -a.)"Multimedia devices" => "Customise DVB frontends" => "Customise the frontend modules to build" -b.)"Multimedia devices" => "Customise DVB frontends" => "Zarlink MT352 based" +a.) => "Zarlink MT352 based" +b.) => "Generic I2C PLL based tuners" 6.) CableStar DVB-C card: -a.)"Multimedia devices" => "Customise DVB frontends" => "Customise the frontend modules to build" -b.)"Multimedia devices" => "Customise DVB frontends" => "ST STV0297 based" +a.) => "ST STV0297 based" +b.) => "Generic I2C PLL based tuners" 7.) AirStar ATSC card 1st generation: -a.)"Multimedia devices" => "Customise DVB frontends" => "Customise the frontend modules to build" -b.)"Multimedia devices" => "Customise DVB frontends" => "Broadcom BCM3510" +a.) => "Broadcom BCM3510" 8.) AirStar ATSC card 2nd generation: -a.)"Multimedia devices" => "Customise DVB frontends" => "Customise the frontend modules to build" -b.)"Multimedia devices" => "Customise DVB frontends" => "NxtWave Communications NXT2002/NXT2004 based" -c.)"Multimedia devices" => "Customise DVB frontends" => "Generic I2C PLL based tuners" +a.) => "NxtWave Communications NXT2002/NXT2004 based" +b.) => "Generic I2C PLL based tuners" 9.) AirStar ATSC card 3rd generation: -a.)"Multimedia devices" => "Customise DVB frontends" => "Customise the frontend modules to build" -b.)"Multimedia devices" => "Customise DVB frontends" => "LG Electronics LGDT3302/LGDT3303 based" -c.)"Multimedia devices" => "Customise analog and hybrid tuner modules to build" => "Simple tuner support" +a.) => "LG Electronics LGDT3302/LGDT3303 based" +b.) "Multimedia support" => "Customise analog and hybrid tuner modules to build" + => "Simple tuner support" -Author: Uwe Bugla <uwe.bugla@gmx.de> February 2009 +Author: Uwe Bugla <uwe.bugla@gmx.de> August 2009 diff --git a/Documentation/edac.txt b/Documentation/edac.txt index 06f8f46692dc..79c533223762 100644 --- a/Documentation/edac.txt +++ b/Documentation/edac.txt @@ -80,7 +80,7 @@ is: broken_parity_status -as is located in /sys/devices/pci<XXX>/0000:XX:YY.Z directorys for +as is located in /sys/devices/pci<XXX>/0000:XX:YY.Z directories for PCI devices. FUTURE HARDWARE SCANNING @@ -288,9 +288,8 @@ Total UE count that had no information attribute fileY: 'ue_noinfo_count' - This attribute file displays the number of UEs that - have occurred have occurred with no informations as to which DIMM - slot is having errors. + This attribute file displays the number of UEs that have occurred + with no information as to which DIMM slot is having errors. Total Correctable Errors count attribute file: diff --git a/Documentation/fault-injection/fault-injection.txt b/Documentation/fault-injection/fault-injection.txt index 079305640790..7be15e44d481 100644 --- a/Documentation/fault-injection/fault-injection.txt +++ b/Documentation/fault-injection/fault-injection.txt @@ -143,8 +143,8 @@ o provide a way to configure fault attributes failslab, fail_page_alloc, and fail_make_request use this way. Helper functions: - init_fault_attr_entries(entries, attr, name); - void cleanup_fault_attr_entries(entries); + init_fault_attr_dentries(entries, attr, name); + void cleanup_fault_attr_dentries(entries); - module parameters diff --git a/Documentation/fb/ep93xx-fb.txt b/Documentation/fb/ep93xx-fb.txt new file mode 100644 index 000000000000..5af1bd9effae --- /dev/null +++ b/Documentation/fb/ep93xx-fb.txt @@ -0,0 +1,135 @@ +================================ +Driver for EP93xx LCD controller +================================ + +The EP93xx LCD controller can drive both standard desktop monitors and +embedded LCD displays. If you have a standard desktop monitor then you +can use the standard Linux video mode database. In your board file: + + static struct ep93xxfb_mach_info some_board_fb_info = { + .num_modes = EP93XXFB_USE_MODEDB, + .bpp = 16, + }; + +If you have an embedded LCD display then you need to define a video +mode for it as follows: + + static struct fb_videomode some_board_video_modes[] = { + { + .name = "some_lcd_name", + /* Pixel clock, porches, etc */ + }, + }; + +Note that the pixel clock value is in pico-seconds. You can use the +KHZ2PICOS macro to convert the pixel clock value. Most other values +are in pixel clocks. See Documentation/fb/framebuffer.txt for further +details. + +The ep93xxfb_mach_info structure for your board should look like the +following: + + static struct ep93xxfb_mach_info some_board_fb_info = { + .num_modes = ARRAY_SIZE(some_board_video_modes), + .modes = some_board_video_modes, + .default_mode = &some_board_video_modes[0], + .bpp = 16, + }; + +The framebuffer device can be registered by adding the following to +your board initialisation function: + + ep93xx_register_fb(&some_board_fb_info); + +===================== +Video Attribute Flags +===================== + +The ep93xxfb_mach_info structure has a flags field which can be used +to configure the controller. The video attributes flags are fully +documented in section 7 of the EP93xx users' guide. The following +flags are available: + +EP93XXFB_PCLK_FALLING Clock data on the falling edge of the + pixel clock. The default is to clock + data on the rising edge. + +EP93XXFB_SYNC_BLANK_HIGH Blank signal is active high. By + default the blank signal is active low. + +EP93XXFB_SYNC_HORIZ_HIGH Horizontal sync is active high. By + default the horizontal sync is active low. + +EP93XXFB_SYNC_VERT_HIGH Vertical sync is active high. By + default the vertical sync is active high. + +The physical address of the framebuffer can be controlled using the +following flags: + +EP93XXFB_USE_SDCSN0 Use SDCSn[0] for the framebuffer. This + is the default setting. + +EP93XXFB_USE_SDCSN1 Use SDCSn[1] for the framebuffer. + +EP93XXFB_USE_SDCSN2 Use SDCSn[2] for the framebuffer. + +EP93XXFB_USE_SDCSN3 Use SDCSn[3] for the framebuffer. + +================== +Platform callbacks +================== + +The EP93xx framebuffer driver supports three optional platform +callbacks: setup, teardown and blank. The setup and teardown functions +are called when the framebuffer driver is installed and removed +respectively. The blank function is called whenever the display is +blanked or unblanked. + +The setup and teardown devices pass the platform_device structure as +an argument. The fb_info and ep93xxfb_mach_info structures can be +obtained as follows: + + static int some_board_fb_setup(struct platform_device *pdev) + { + struct ep93xxfb_mach_info *mach_info = pdev->dev.platform_data; + struct fb_info *fb_info = platform_get_drvdata(pdev); + + /* Board specific framebuffer setup */ + } + +====================== +Setting the video mode +====================== + +The video mode is set using the following syntax: + + video=XRESxYRES[-BPP][@REFRESH] + +If the EP93xx video driver is built-in then the video mode is set on +the Linux kernel command line, for example: + + video=ep93xx-fb:800x600-16@60 + +If the EP93xx video driver is built as a module then the video mode is +set when the module is installed: + + modprobe ep93xx-fb video=320x240 + +============== +Screenpage bug +============== + +At least on the EP9315 there is a silicon bug which causes bit 27 of +the VIDSCRNPAGE (framebuffer physical offset) to be tied low. There is +an unofficial errata for this bug at: + http://marc.info/?l=linux-arm-kernel&m=110061245502000&w=2 + +By default the EP93xx framebuffer driver checks if the allocated physical +address has bit 27 set. If it does, then the memory is freed and an +error is returned. The check can be disabled by adding the following +option when loading the driver: + + ep93xx-fb.check_screenpage_bug=0 + +In some cases it may be possible to reconfigure your SDRAM layout to +avoid this bug. See section 13 of the EP93xx users' guide for details. diff --git a/Documentation/fb/framebuffer.txt b/Documentation/fb/framebuffer.txt index b3e3a0356839..fe79e3c8847d 100644 --- a/Documentation/fb/framebuffer.txt +++ b/Documentation/fb/framebuffer.txt @@ -312,10 +312,8 @@ and to the following documentation: 8. Mailing list --------------- -There are several frame buffer device related mailing lists at SourceForge: - - linux-fbdev-announce@lists.sourceforge.net, for announcements, - - linux-fbdev-user@lists.sourceforge.net, for generic user support, - - linux-fbdev-devel@lists.sourceforge.net, for project developers. +There is a frame buffer device related mailing list at kernel.org: +linux-fbdev@vger.kernel.org. Point your web browser to http://sourceforge.net/projects/linux-fbdev/ for subscription information and archive browsing. diff --git a/Documentation/fb/matroxfb.txt b/Documentation/fb/matroxfb.txt index ad7a67707d62..e5ce8a1a978b 100644 --- a/Documentation/fb/matroxfb.txt +++ b/Documentation/fb/matroxfb.txt @@ -186,9 +186,7 @@ noinverse - show true colors on screen. It is default. dev:X - bind driver to device X. Driver numbers device from 0 up to N, where device 0 is first `known' device found, 1 second and so on. lspci lists devices in this order. - Default is `every' known device for driver with multihead support - and first working device (usually dev:0) for driver without - multihead support. + Default is `every' known device. nohwcursor - disables hardware cursor (use software cursor instead). hwcursor - enables hardware cursor. It is default. If you are using non-accelerated mode (`noaccel' or `fbset -accel false'), software diff --git a/Documentation/fb/viafb.txt b/Documentation/fb/viafb.txt index 67dbf442b0b6..f3e046a6a987 100644 --- a/Documentation/fb/viafb.txt +++ b/Documentation/fb/viafb.txt @@ -7,7 +7,7 @@ VIA UniChrome Family(CLE266, PM800 / CN400 / CN300, P4M800CE / P4M800Pro / CN700 / VN800, CX700 / VX700, K8M890, P4M890, - CN896 / P4M900, VX800) + CN896 / P4M900, VX800, VX855) [Driver features] ------------------------ @@ -154,13 +154,6 @@ 0 : No Dual Edge Panel (default) 1 : Dual Edge Panel - viafb_video_dev: - This option is used to specify video output devices(CRT, DVI, LCD) for - duoview case. - For example: - To output video on DVI, we should use: - modprobe viafb viafb_video_dev=DVI... - viafb_lcd_port: This option is used to specify LCD output port, available values are "DVP0" "DVP1" "DFP_HIGHLOW" "DFP_HIGH" "DFP_LOW". @@ -181,9 +174,6 @@ Notes: and bpp, need to call VIAFB specified ioctl interface VIAFB_SET_DEVICE instead of calling common ioctl function FBIOPUT_VSCREENINFO since viafb doesn't support multi-head well, or it will cause screen crush. - 4. VX800 2D accelerator hasn't been supported in this driver yet. When - using driver on VX800, the driver will disable the acceleration - function as default. [Configure viafb with "fbset" tool] diff --git a/Documentation/feature-removal-schedule.txt b/Documentation/feature-removal-schedule.txt index 09e031c55887..0a46833c1b76 100644 --- a/Documentation/feature-removal-schedule.txt +++ b/Documentation/feature-removal-schedule.txt @@ -6,6 +6,50 @@ be removed from this file. --------------------------- +What: USER_SCHED +When: 2.6.34 + +Why: USER_SCHED was implemented as a proof of concept for group scheduling. + The effect of USER_SCHED can already be achieved from userspace with + the help of libcgroup. The removal of USER_SCHED will also simplify + the scheduler code with the removal of one major ifdef. There are also + issues USER_SCHED has with USER_NS. A decision was taken not to fix + those and instead remove USER_SCHED. Also new group scheduling + features will not be implemented for USER_SCHED. + +Who: Dhaval Giani <dhaval@linux.vnet.ibm.com> + +--------------------------- + +What: PRISM54 +When: 2.6.34 + +Why: prism54 FullMAC PCI / Cardbus devices used to be supported only by the + prism54 wireless driver. After Intersil stopped selling these + devices in preference for the newer more flexible SoftMAC devices + a SoftMAC device driver was required and prism54 did not support + them. The p54pci driver now exists and has been present in the kernel for + a while. This driver supports both SoftMAC devices and FullMAC devices. + The main difference between these devices was the amount of memory which + could be used for the firmware. The SoftMAC devices support a smaller + amount of memory. Because of this the SoftMAC firmware fits into FullMAC + devices's memory. p54pci supports not only PCI / Cardbus but also USB + and SPI. Since p54pci supports all devices prism54 supports + you will have a conflict. I'm not quite sure how distributions are + handling this conflict right now. prism54 was kept around due to + claims users may experience issues when using the SoftMAC driver. + Time has passed users have not reported issues. If you use prism54 + and for whatever reason you cannot use p54pci please let us know! + E-mail us at: linux-wireless@vger.kernel.org + + For more information see the p54 wiki page: + + http://wireless.kernel.org/en/users/Drivers/p54 + +Who: Luis R. Rodriguez <lrodriguez@atheros.com> + +--------------------------- + What: IRQF_SAMPLE_RANDOM Check: IRQF_SAMPLE_RANDOM When: July 2009 @@ -206,24 +250,6 @@ Who: Len Brown <len.brown@intel.com> --------------------------- -What: libata spindown skipping and warning -When: Dec 2008 -Why: Some halt(8) implementations synchronize caches for and spin - down libata disks because libata didn't use to spin down disk on - system halt (only synchronized caches). - Spin down on system halt is now implemented. sysfs node - /sys/class/scsi_disk/h:c:i:l/manage_start_stop is present if - spin down support is available. - Because issuing spin down command to an already spun down disk - makes some disks spin up just to spin down again, libata tracks - device spindown status to skip the extra spindown command and - warn about it. - This is to give userspace tools the time to get updated and will - be removed after userspace is reasonably updated. -Who: Tejun Heo <htejun@gmail.com> - ---------------------------- - What: i386/x86_64 bzImage symlinks When: April 2010 @@ -235,31 +261,6 @@ Who: Thomas Gleixner <tglx@linutronix.de> --------------------------- What (Why): - - include/linux/netfilter_ipv4/ipt_TOS.h ipt_tos.h header files - (superseded by xt_TOS/xt_tos target & match) - - - "forwarding" header files like ipt_mac.h in - include/linux/netfilter_ipv4/ and include/linux/netfilter_ipv6/ - - - xt_CONNMARK match revision 0 - (superseded by xt_CONNMARK match revision 1) - - - xt_MARK target revisions 0 and 1 - (superseded by xt_MARK match revision 2) - - - xt_connmark match revision 0 - (superseded by xt_connmark match revision 1) - - - xt_conntrack match revision 0 - (superseded by xt_conntrack match revision 1) - - - xt_iprange match revision 0, - include/linux/netfilter_ipv4/ipt_iprange.h - (superseded by xt_iprange match revision 1) - - - xt_mark match revision 0 - (superseded by xt_mark match revision 1) - - xt_recent: the old ipt_recent proc dir (superseded by /proc/net/xt_recent) @@ -290,22 +291,6 @@ Who: Michael Buesch <mb@bu3sch.de> --------------------------- -What: usedac i386 kernel parameter -When: 2.6.27 -Why: replaced by allowdac and no dac combination -Who: Glauber Costa <gcosta@redhat.com> - ---------------------------- - -What: print_fn_descriptor_symbol() -When: October 2009 -Why: The %pF vsprintf format provides the same functionality in a - simpler way. print_fn_descriptor_symbol() is deprecated but - still present to give out-of-tree modules time to change. -Who: Bjorn Helgaas <bjorn.helgaas@hp.com> - ---------------------------- - What: /sys/o2cb symlink When: January 2010 Why: /sys/fs/o2cb is the proper location for this information - /sys/o2cb @@ -316,18 +301,6 @@ Who: ocfs2-devel@oss.oracle.com --------------------------- -What: SCTP_GET_PEER_ADDRS_NUM_OLD, SCTP_GET_PEER_ADDRS_OLD, - SCTP_GET_LOCAL_ADDRS_NUM_OLD, SCTP_GET_LOCAL_ADDRS_OLD -When: June 2009 -Why: A newer version of the options have been introduced in 2005 that - removes the limitions of the old API. The sctp library has been - converted to use these new options at the same time. Any user - space app that directly uses the old options should convert to using - the new options. -Who: Vlad Yasevich <vladislav.yasevich@hp.com> - ---------------------------- - What: Ability for non root users to shm_get hugetlb pages based on mlock resource limits When: 2.6.31 @@ -368,14 +341,6 @@ Who: Krzysztof Piotr Oledzki <ole@ans.pl> --------------------------- -What: fscher and fscpos drivers -When: June 2009 -Why: Deprecated by the new fschmd driver. -Who: Hans de Goede <hdegoede@redhat.com> - Jean Delvare <khali@linux-fr.org> - ---------------------------- - What: sysfs ui for changing p4-clockmod parameters When: September 2009 Why: See commits 129f8ae9b1b5be94517da76009ea956e89104ce8 and @@ -394,15 +359,6 @@ Who: Thomas Gleixner <tglx@linutronix.de> ----------------------------- -What: obsolete generic irq defines and typedefs -When: 2.6.30 -Why: The defines and typedefs (hw_interrupt_type, no_irq_type, irq_desc_t) - have been kept around for migration reasons. After more than two years - it's time to remove them finally -Who: Thomas Gleixner <tglx@linutronix.de> - ---------------------------- - What: fakephp and associated sysfs files in /sys/bus/pci/slots/ When: 2011 Why: In 2.6.27, the semantics of /sys/bus/pci/slots was redefined to @@ -435,29 +391,18 @@ Who: Alex Chiang <achiang@hp.com> --------------------------- -What: i2c-voodoo3 driver -When: October 2009 -Why: Superseded by tdfxfb. I2C/DDC support used to live in a separate - driver but this caused driver conflicts. -Who: Jean Delvare <khali@linux-fr.org> - Krzysztof Helt <krzysztof.h1@wp.pl> - ---------------------------- - What: CONFIG_RFKILL_INPUT When: 2.6.33 Why: Should be implemented in userspace, policy daemon. Who: Johannes Berg <johannes@sipsolutions.net> ----------------------------- +--------------------------- -What: CONFIG_X86_OLD_MCE -When: 2.6.32 -Why: Remove the old legacy 32bit machine check code. This has been - superseded by the newer machine check code from the 64bit port, - but the old version has been kept around for easier testing. Note this - doesn't impact the old P5 and WinChip machine check handlers. -Who: Andi Kleen <andi@firstfloor.org> +What: CONFIG_INOTIFY +When: 2.6.33 +Why: last user (audit) will be converted to the newer more generic + and more easily maintained fsnotify subsystem +Who: Eric Paris <eparis@redhat.com> ---------------------------- @@ -468,3 +413,132 @@ Why: cpu_policy_rwsem has a new cleaner definition making it local to cpufreq core and contained inside cpufreq.c. Other dependent drivers should not use it in order to safely avoid lockdep issues. Who: Venkatesh Pallipadi <venkatesh.pallipadi@intel.com> + +---------------------------- + +What: sound-slot/service-* module aliases and related clutters in + sound/sound_core.c +When: August 2010 +Why: OSS sound_core grabs all legacy minors (0-255) of SOUND_MAJOR + (14) and requests modules using custom sound-slot/service-* + module aliases. The only benefit of doing this is allowing + use of custom module aliases which might as well be considered + a bug at this point. This preemptive claiming prevents + alternative OSS implementations. + + Till the feature is removed, the kernel will be requesting + both sound-slot/service-* and the standard char-major-* module + aliases and allow turning off the pre-claiming selectively via + CONFIG_SOUND_OSS_CORE_PRECLAIM and soundcore.preclaim_oss + kernel parameter. + + After the transition phase is complete, both the custom module + aliases and switches to disable it will go away. This removal + will also allow making ALSA OSS emulation independent of + sound_core. The dependency will be broken then too. +Who: Tejun Heo <tj@kernel.org> + +---------------------------- + +What: Support for VMware's guest paravirtuliazation technique [VMI] will be + dropped. +When: 2.6.37 or earlier. +Why: With the recent innovations in CPU hardware acceleration technologies + from Intel and AMD, VMware ran a few experiments to compare these + techniques to guest paravirtualization technique on VMware's platform. + These hardware assisted virtualization techniques have outperformed the + performance benefits provided by VMI in most of the workloads. VMware + expects that these hardware features will be ubiquitous in a couple of + years, as a result, VMware has started a phased retirement of this + feature from the hypervisor. We will be removing this feature from the + Kernel too. Right now we are targeting 2.6.37 but can retire earlier if + technical reasons (read opportunity to remove major chunk of pvops) + arise. + + Please note that VMI has always been an optimization and non-VMI kernels + still work fine on VMware's platform. + Latest versions of VMware's product which support VMI are, + Workstation 7.0 and VSphere 4.0 on ESX side, future maintainence + releases for these products will continue supporting VMI. + + For more details about VMI retirement take a look at this, + http://blogs.vmware.com/guestosguide/2009/09/vmi-retirement.html + +Who: Alok N Kataria <akataria@vmware.com> + +---------------------------- + +What: adt7473 hardware monitoring driver +When: February 2010 +Why: Obsoleted by the adt7475 driver. +Who: Jean Delvare <khali@linux-fr.org> + +--------------------------- +What: Support for lcd_switch and display_get in asus-laptop driver +When: March 2010 +Why: These two features use non-standard interfaces. There are the + only features that really need multiple path to guess what's + the right method name on a specific laptop. + + Removing them will allow to remove a lot of code an significantly + clean the drivers. + + This will affect the backlight code which won't be able to know + if the backlight is on or off. The platform display file will also be + write only (like the one in eeepc-laptop). + + This should'nt affect a lot of user because they usually know + when their display is on or off. + +Who: Corentin Chary <corentin.chary@gmail.com> + +---------------------------- + +What: usbvideo quickcam_messenger driver +When: 2.6.35 +Files: drivers/media/video/usbvideo/quickcam_messenger.[ch] +Why: obsolete v4l1 driver replaced by gspca_stv06xx +Who: Hans de Goede <hdegoede@redhat.com> + +---------------------------- + +What: ov511 v4l1 driver +When: 2.6.35 +Files: drivers/media/video/ov511.[ch] +Why: obsolete v4l1 driver replaced by gspca_ov519 +Who: Hans de Goede <hdegoede@redhat.com> + +---------------------------- + +What: w9968cf v4l1 driver +When: 2.6.35 +Files: drivers/media/video/w9968cf*.[ch] +Why: obsolete v4l1 driver replaced by gspca_ov519 +Who: Hans de Goede <hdegoede@redhat.com> + +---------------------------- + +What: ovcamchip sensor framework +When: 2.6.35 +Files: drivers/media/video/ovcamchip/* +Why: Only used by obsoleted v4l1 drivers +Who: Hans de Goede <hdegoede@redhat.com> + +---------------------------- + +What: stv680 v4l1 driver +When: 2.6.35 +Files: drivers/media/video/stv680.[ch] +Why: obsolete v4l1 driver replaced by gspca_stv0680 +Who: Hans de Goede <hdegoede@redhat.com> + +---------------------------- + +What: zc0301 v4l driver +When: 2.6.35 +Files: drivers/media/video/zc0301/* +Why: Duplicate functionality with the gspca_zc3xx driver, zc0301 only + supports 2 USB-ID's (because it only supports a limited set of + sensors) wich are also supported by the gspca_zc3xx driver + (which supports 53 USB-ID's in total) +Who: Hans de Goede <hdegoede@redhat.com> diff --git a/Documentation/filesystems/00-INDEX b/Documentation/filesystems/00-INDEX index f15621ee5599..875d49696b6e 100644 --- a/Documentation/filesystems/00-INDEX +++ b/Documentation/filesystems/00-INDEX @@ -1,7 +1,5 @@ 00-INDEX - this file (info on some of the filesystems supported by linux). -Exporting - - explanation of how to make filesystems exportable. Locking - info on locking rules as they pertain to Linux VFS. 9p.txt @@ -36,6 +34,8 @@ dnotify.txt - info about directory notification in Linux. ecryptfs.txt - docs on eCryptfs: stacked cryptographic filesystem for Linux. +exofs.txt + - info, usage, mount options, design about EXOFS. ext2.txt - info, mount options and specifications for the Ext2 filesystem. ext3.txt @@ -66,12 +66,8 @@ mandatory-locking.txt - info on the Linux implementation of Sys V mandatory file locking. ncpfs.txt - info on Novell Netware(tm) filesystem using NCP protocol. -nfs41-server.txt - - info on the Linux server implementation of NFSv4 minor version 1. -nfs-rdma.txt - - how to install and setup the Linux NFS/RDMA client and server software. -nfsroot.txt - - short guide on setting up a diskless box with NFS root filesystem. +nfs/ + - nfs-related documentation. nilfs2.txt - info and mount options for the NILFS2 filesystem. ntfs.txt @@ -90,8 +86,6 @@ relay.txt - info on relay, for efficient streaming from kernel to user space. romfs.txt - description of the ROMFS filesystem. -rpc-cache.txt - - introduction to the caching mechanisms in the sunrpc layer. seq_file.txt - how to use the seq_file API sharedsubtree.txt diff --git a/Documentation/filesystems/9p.txt b/Documentation/filesystems/9p.txt index 6208f55c44c3..57e0b80a5274 100644 --- a/Documentation/filesystems/9p.txt +++ b/Documentation/filesystems/9p.txt @@ -18,11 +18,11 @@ the 9p client is available in the form of a USENIX paper: Other applications are described in the following papers: * XCPU & Clustering - http://www.xcpu.org/xcpu-talk.pdf + http://xcpu.org/papers/xcpu-talk.pdf * KVMFS: control file system for KVM - http://www.xcpu.org/kvmfs.pdf - * CellFS: A New ProgrammingModel for the Cell BE - http://www.xcpu.org/cellfs-talk.pdf + http://xcpu.org/papers/kvmfs.pdf + * CellFS: A New Programming Model for the Cell BE + http://xcpu.org/papers/cellfs-talk.pdf * PROSE I/O: Using 9p to enable Application Partitions http://plan9.escet.urjc.es/iwp9/cready/PROSE_iwp9_2006.pdf @@ -48,6 +48,7 @@ OPTIONS (see rfdno and wfdno) virtio - connect to the next virtio channel available (from lguest or KVM with trans_virtio module) + rdma - connect to a specified RDMA channel uname=name user name to attempt mount as on the remote server. The server may override or ignore this value. Certain user @@ -59,16 +60,22 @@ OPTIONS cache=mode specifies a caching policy. By default, no caches are used. loose = no attempts are made at consistency, intended for exclusive, read-only mounts + fscache = use FS-Cache for a persistent, read-only + cache backend. debug=n specifies debug level. The debug level is a bitmask. - 0x01 = display verbose error messages - 0x02 = developer debug (DEBUG_CURRENT) - 0x04 = display 9p trace - 0x08 = display VFS trace - 0x10 = display Marshalling debug - 0x20 = display RPC debug - 0x40 = display transport debug - 0x80 = display allocation debug + 0x01 = display verbose error messages + 0x02 = developer debug (DEBUG_CURRENT) + 0x04 = display 9p trace + 0x08 = display VFS trace + 0x10 = display Marshalling debug + 0x20 = display RPC debug + 0x40 = display transport debug + 0x80 = display allocation debug + 0x100 = display protocol message debug + 0x200 = display Fid debug + 0x400 = display packet debug + 0x800 = display fscache tracing debug rfdno=n the file descriptor for reading with trans=fd @@ -100,6 +107,10 @@ OPTIONS any = v9fs does single attach and performs all operations as one user + cachetag cache tag to use the specified persistent cache. + cache tags for existing cache sessions can be listed at + /sys/fs/9p/caches. (applies only to cache=fscache) + RESOURCES ========= @@ -118,7 +129,7 @@ and export. A Linux version of the 9p server is now maintained under the npfs project on sourceforge (http://sourceforge.net/projects/npfs). The currently maintained version is the single-threaded version of the server (named spfs) -available from the same CVS repository. +available from the same SVN repository. There are user and developer mailing lists available through the v9fs project on sourceforge (http://sourceforge.net/projects/v9fs). @@ -126,7 +137,8 @@ on sourceforge (http://sourceforge.net/projects/v9fs). A stand-alone version of the module (which should build for any 2.6 kernel) is available via (http://github.com/ericvh/9p-sac/tree/master) -News and other information is maintained on SWiK (http://swik.net/v9fs). +News and other information is maintained on SWiK (http://swik.net/v9fs) +and the Wiki (http://sf.net/apps/mediawiki/v9fs/index.php). Bug reports may be issued through the kernel.org bugzilla (http://bugzilla.kernel.org) diff --git a/Documentation/filesystems/caching/fscache.txt b/Documentation/filesystems/caching/fscache.txt index 9e94b9491d89..a91e2e2095b0 100644 --- a/Documentation/filesystems/caching/fscache.txt +++ b/Documentation/filesystems/caching/fscache.txt @@ -235,6 +235,7 @@ proc files. neg=N Number of negative lookups made pos=N Number of positive lookups made crt=N Number of objects created by lookup + tmo=N Number of lookups timed out and requeued Updates n=N Number of update cookie requests seen nul=N Number of upd reqs given a NULL parent run=N Number of upd reqs granted CPU time @@ -250,8 +251,10 @@ proc files. ok=N Number of successful alloc reqs wt=N Number of alloc reqs that waited on lookup completion nbf=N Number of alloc reqs rejected -ENOBUFS + int=N Number of alloc reqs aborted -ERESTARTSYS ops=N Number of alloc reqs submitted owt=N Number of alloc reqs waited for CPU time + abt=N Number of alloc reqs aborted due to object death Retrvls n=N Number of retrieval (read) requests seen ok=N Number of successful retr reqs wt=N Number of retr reqs that waited on lookup completion @@ -261,6 +264,7 @@ proc files. oom=N Number of retr reqs failed -ENOMEM ops=N Number of retr reqs submitted owt=N Number of retr reqs waited for CPU time + abt=N Number of retr reqs aborted due to object death Stores n=N Number of storage (write) requests seen ok=N Number of successful store reqs agn=N Number of store reqs on a page already pending storage @@ -268,12 +272,37 @@ proc files. oom=N Number of store reqs failed -ENOMEM ops=N Number of store reqs submitted run=N Number of store reqs granted CPU time + pgs=N Number of pages given store req processing time + rxd=N Number of store reqs deleted from tracking tree + olm=N Number of store reqs over store limit + VmScan nos=N Number of release reqs against pages with no pending store + gon=N Number of release reqs against pages stored by time lock granted + bsy=N Number of release reqs ignored due to in-progress store + can=N Number of page stores cancelled due to release req Ops pend=N Number of times async ops added to pending queues run=N Number of times async ops given CPU time enq=N Number of times async ops queued for processing + can=N Number of async ops cancelled + rej=N Number of async ops rejected due to object lookup/create failure dfr=N Number of async ops queued for deferred release rel=N Number of async ops released gc=N Number of deferred-release async ops garbage collected + CacheOp alo=N Number of in-progress alloc_object() cache ops + luo=N Number of in-progress lookup_object() cache ops + luc=N Number of in-progress lookup_complete() cache ops + gro=N Number of in-progress grab_object() cache ops + upo=N Number of in-progress update_object() cache ops + dro=N Number of in-progress drop_object() cache ops + pto=N Number of in-progress put_object() cache ops + syn=N Number of in-progress sync_cache() cache ops + atc=N Number of in-progress attr_changed() cache ops + rap=N Number of in-progress read_or_alloc_page() cache ops + ras=N Number of in-progress read_or_alloc_pages() cache ops + alp=N Number of in-progress allocate_page() cache ops + als=N Number of in-progress allocate_pages() cache ops + wrp=N Number of in-progress write_page() cache ops + ucp=N Number of in-progress uncache_page() cache ops + dsp=N Number of in-progress dissociate_pages() cache ops (*) /proc/fs/fscache/histogram @@ -299,6 +328,87 @@ proc files. jiffy range covered, and the SECS field the equivalent number of seconds. +=========== +OBJECT LIST +=========== + +If CONFIG_FSCACHE_OBJECT_LIST is enabled, the FS-Cache facility will maintain a +list of all the objects currently allocated and allow them to be viewed +through: + + /proc/fs/fscache/objects + +This will look something like: + + [root@andromeda ~]# head /proc/fs/fscache/objects + OBJECT PARENT STAT CHLDN OPS OOP IPR EX READS EM EV F S | NETFS_COOKIE_DEF TY FL NETFS_DATA OBJECT_KEY, AUX_DATA + ======== ======== ==== ===== === === === == ===== == == = = | ================ == == ================ ================ + 17e4b 2 ACTV 0 0 0 0 0 0 7b 4 0 8 | NFS.fh DT 0 ffff88001dd82820 010006017edcf8bbc93b43298fdfbe71e50b57b13a172c0117f38472, e567634700000000000000000000000063f2404a000000000000000000000000c9030000000000000000000063f2404a + 1693a 2 ACTV 0 0 0 0 0 0 7b 4 0 8 | NFS.fh DT 0 ffff88002db23380 010006017edcf8bbc93b43298fdfbe71e50b57b1e0162c01a2df0ea6, 420ebc4a000000000000000000000000420ebc4a0000000000000000000000000e1801000000000000000000420ebc4a + +where the first set of columns before the '|' describe the object: + + COLUMN DESCRIPTION + ======= =============================================================== + OBJECT Object debugging ID (appears as OBJ%x in some debug messages) + PARENT Debugging ID of parent object + STAT Object state + CHLDN Number of child objects of this object + OPS Number of outstanding operations on this object + OOP Number of outstanding child object management operations + IPR + EX Number of outstanding exclusive operations + READS Number of outstanding read operations + EM Object's event mask + EV Events raised on this object + F Object flags + S Object slow-work work item flags + +and the second set of columns describe the object's cookie, if present: + + COLUMN DESCRIPTION + =============== ======================================================= + NETFS_COOKIE_DEF Name of netfs cookie definition + TY Cookie type (IX - index, DT - data, hex - special) + FL Cookie flags + NETFS_DATA Netfs private data stored in the cookie + OBJECT_KEY Object key } 1 column, with separating comma + AUX_DATA Object aux data } presence may be configured + +The data shown may be filtered by attaching the a key to an appropriate keyring +before viewing the file. Something like: + + keyctl add user fscache:objlist <restrictions> @s + +where <restrictions> are a selection of the following letters: + + K Show hexdump of object key (don't show if not given) + A Show hexdump of object aux data (don't show if not given) + +and the following paired letters: + + C Show objects that have a cookie + c Show objects that don't have a cookie + B Show objects that are busy + b Show objects that aren't busy + W Show objects that have pending writes + w Show objects that don't have pending writes + R Show objects that have outstanding reads + r Show objects that don't have outstanding reads + S Show objects that have slow work queued + s Show objects that don't have slow work queued + +If neither side of a letter pair is given, then both are implied. For example: + + keyctl add user fscache:objlist KB @s + +shows objects that are busy, and lists their object keys, but does not dump +their auxiliary data. It also implies "CcWwRrSs", but as 'B' is given, 'b' is +not implied. + +By default all objects and all fields will be shown. + + ========= DEBUGGING ========= diff --git a/Documentation/filesystems/caching/netfs-api.txt b/Documentation/filesystems/caching/netfs-api.txt index 2666b1ed5e9e..1902c57b72ef 100644 --- a/Documentation/filesystems/caching/netfs-api.txt +++ b/Documentation/filesystems/caching/netfs-api.txt @@ -641,7 +641,7 @@ data file must be retired (see the relinquish cookie function below). Furthermore, note that this does not cancel the asynchronous read or write operation started by the read/alloc and write functions, so the page -invalidation and release functions must use: +invalidation functions must use: bool fscache_check_page_write(struct fscache_cookie *cookie, struct page *page); @@ -654,6 +654,25 @@ to see if a page is being written to the cache, and: to wait for it to finish if it is. +When releasepage() is being implemented, a special FS-Cache function exists to +manage the heuristics of coping with vmscan trying to eject pages, which may +conflict with the cache trying to write pages to the cache (which may itself +need to allocate memory): + + bool fscache_maybe_release_page(struct fscache_cookie *cookie, + struct page *page, + gfp_t gfp); + +This takes the netfs cookie, and the page and gfp arguments as supplied to +releasepage(). It will return false if the page cannot be released yet for +some reason and if it returns true, the page has been uncached and can now be +released. + +To make a page available for release, this function may wait for an outstanding +storage request to complete, or it may attempt to cancel the storage request - +in which case the page will not be stored in the cache this time. + + ========================== INDEX AND DATA FILE UPDATE ========================== diff --git a/Documentation/filesystems/exofs.txt b/Documentation/filesystems/exofs.txt index 0ced74c2f73c..abd2a9b5b787 100644 --- a/Documentation/filesystems/exofs.txt +++ b/Documentation/filesystems/exofs.txt @@ -60,13 +60,13 @@ USAGE mkfs.exofs --pid=65536 --format /dev/osd0 - The --format is optional if not specified no OSD_FORMAT will be - preformed and a clean file system will be created in the specified pid, + The --format is optional. If not specified, no OSD_FORMAT will be + performed and a clean file system will be created in the specified pid, in the available space of the target. (Use --format=size_in_meg to limit the total LUN space available) - If pid already exist it will be deleted and a new one will be created in it's - place. Be careful. + If pid already exists, it will be deleted and a new one will be created in + its place. Be careful. An exofs lives inside a single OSD partition. You can create multiple exofs filesystems on the same device using multiple pids. @@ -81,7 +81,7 @@ USAGE 7. For reference (See do-exofs example script): do-exofs start - an example of how to perform the above steps. - do-exofs stop - an example of how to unmount the file system. + do-exofs stop - an example of how to unmount the file system. do-exofs format - an example of how to format and mkfs a new exofs. 8. Extra compilation flags (uncomment in fs/exofs/Kbuild): @@ -104,8 +104,8 @@ 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 - to=<integer> - Timeout in ticks for a single command + This option is mandatory. + to=<integer> - Timeout in ticks for a single command. default is (60 * HZ) [for debugging only] =============================================================================== @@ -116,7 +116,7 @@ DESIGN with a special ID (defined in common.h). Information included in the file system control block is used to fill the in-memory superblock structure at mount time. This object is created before - the file system is used by mkexofs.c It contains information such as: + the file system is used by mkexofs.c. It contains information such as: - The file system's magic number - The next inode number to be allocated @@ -134,8 +134,8 @@ DESIGN attributes. This applies to both regular files and other types (directories, device files, symlinks, etc.). -* Credentials are generated per object (inode and superblock) when they is - created in memory (read off disk or created). The credential works for all +* Credentials are generated per object (inode and superblock) when they are + created in memory (read from disk or created). The credential works for all operations and is used as long as the object remains in memory. * Async OSD operations are used whenever possible, but the target may execute @@ -145,7 +145,8 @@ DESIGN from executing in reverse order: - The following are handled with the OBJ_CREATED and OBJ_2BCREATED flags. OBJ_CREATED is set when we know the object exists on the OSD - - in create's callback function, and when we successfully do a read_inode. + in create's callback function, and when we successfully do a + read_inode. OBJ_2BCREATED is set in the beginning of the create function, so we know that we should wait. - create/delete: delete should wait until the object is created diff --git a/Documentation/filesystems/ext3.txt b/Documentation/filesystems/ext3.txt index 570f9bd9be2b..867c5b50cb42 100644 --- a/Documentation/filesystems/ext3.txt +++ b/Documentation/filesystems/ext3.txt @@ -32,8 +32,8 @@ journal_dev=devnum When the external journal device's major/minor numbers identified through its new major/minor numbers encoded in devnum. -noload Don't load the journal on mounting. Note that this forces - mount of inconsistent filesystem, which can lead to +norecovery Don't load the journal on mounting. Note that this forces +noload mount of inconsistent filesystem, which can lead to various problems. data=journal All data are committed into the journal prior to being @@ -123,10 +123,18 @@ resuid=n The user ID which may use the reserved blocks. sb=n Use alternate superblock at this location. -quota -noquota -grpquota -usrquota +quota These options are ignored by the filesystem. They +noquota are used only by quota tools to recognize volumes +grpquota where quota should be turned on. See documentation +usrquota in the quota-tools package for more details + (http://sourceforge.net/projects/linuxquota). + +jqfmt=<quota type> These options tell filesystem details about quota +usrjquota=<file> so that quota information can be properly updated +grpjquota=<file> during journal replay. They replace the above + quota options. See documentation in the quota-tools + package for more details + (http://sourceforge.net/projects/linuxquota). bh (*) ext3 associates buffer heads to data pages to nobh (a) cache disk block mapping information diff --git a/Documentation/filesystems/ext4.txt b/Documentation/filesystems/ext4.txt index 7be02ac5fa36..e1def1786e50 100644 --- a/Documentation/filesystems/ext4.txt +++ b/Documentation/filesystems/ext4.txt @@ -153,8 +153,8 @@ journal_dev=devnum When the external journal device's major/minor numbers identified through its new major/minor numbers encoded in devnum. -noload Don't load the journal on mounting. Note that - if the filesystem was not unmounted cleanly, +norecovery Don't load the journal on mounting. Note that +noload if the filesystem was not unmounted cleanly, skipping the journal replay will lead to the filesystem containing inconsistencies that can lead to any number of problems. @@ -196,7 +196,7 @@ nobarrier This also requires an IO stack which can support also be used to enable or disable barriers, for consistency with other ext4 mount options. -inode_readahead=n This tuning parameter controls the maximum +inode_readahead_blks=n This tuning parameter controls the maximum number of inode table blocks that ext4's inode table readahead algorithm will pre-read into the buffer cache. The default value is 32 blocks. @@ -263,10 +263,18 @@ resuid=n The user ID which may use the reserved blocks. sb=n Use alternate superblock at this location. -quota -noquota -grpquota -usrquota +quota These options are ignored by the filesystem. They +noquota are used only by quota tools to recognize volumes +grpquota where quota should be turned on. See documentation +usrquota in the quota-tools package for more details + (http://sourceforge.net/projects/linuxquota). + +jqfmt=<quota type> These options tell filesystem details about quota +usrjquota=<file> so that quota information can be properly updated +grpjquota=<file> during journal replay. They replace the above + quota options. See documentation in the quota-tools + package for more details + (http://sourceforge.net/projects/linuxquota). bh (*) ext4 associates buffer heads to data pages to nobh (a) cache disk block mapping information @@ -280,9 +288,16 @@ stripe=n Number of filesystem blocks that mballoc will try to use for allocation size and alignment. For RAID5/6 systems this should be the number of data disks * RAID chunk size in file system blocks. -delalloc (*) Deferring block allocation until write-out time. -nodelalloc Disable delayed allocation. Blocks are allocation - when data is copied from user to page cache. + +delalloc (*) Defer block allocation until just before ext4 + writes out the block(s) in question. This + allows ext4 to better allocation decisions + more efficiently. +nodelalloc Disable delayed allocation. Blocks are allocated + when the data is copied from userspace to the + page cache, either via the write(2) system call + or when an mmap'ed page which was previously + unallocated is written for the first time. max_batch_time=usec Maximum amount of time ext4 should wait for additional filesystem operations to be batch @@ -338,6 +353,12 @@ noauto_da_alloc replacing existing files via patterns such as system crashes before the delayed allocation blocks are forced to disk. +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. + Data Mode ========= There are 3 different data modes: diff --git a/Documentation/filesystems/gfs2-uevents.txt b/Documentation/filesystems/gfs2-uevents.txt new file mode 100644 index 000000000000..fd966dc9979a --- /dev/null +++ b/Documentation/filesystems/gfs2-uevents.txt @@ -0,0 +1,100 @@ + uevents and GFS2 + ================== + +During the lifetime of a GFS2 mount, a number of uevents are generated. +This document explains what the events are and what they are used +for (by gfs_controld in gfs2-utils). + +A list of GFS2 uevents +----------------------- + +1. ADD + +The ADD event occurs at mount time. It will always be the first +uevent generated by the newly created filesystem. If the mount +is successful, an ONLINE uevent will follow. If it is not successful +then a REMOVE uevent will follow. + +The ADD uevent has two environment variables: SPECTATOR=[0|1] +and RDONLY=[0|1] that specify the spectator status (a read-only mount +with no journal assigned), and read-only (with journal assigned) status +of the filesystem respectively. + +2. ONLINE + +The ONLINE uevent is generated after a successful mount or remount. It +has the same environment variables as the ADD uevent. The ONLINE +uevent, along with the two environment variables for spectator and +RDONLY are a relatively recent addition (2.6.32-rc+) and will not +be generated by older kernels. + +3. CHANGE + +The CHANGE uevent is used in two places. One is when reporting the +successful mount of the filesystem by the first node (FIRSTMOUNT=Done). +This is used as a signal by gfs_controld that it is then ok for other +nodes in the cluster to mount the filesystem. + +The other CHANGE uevent is used to inform of the completion +of journal recovery for one of the filesystems journals. It has +two environment variables, JID= which specifies the journal id which +has just been recovered, and RECOVERY=[Done|Failed] to indicate the +success (or otherwise) of the operation. These uevents are generated +for every journal recovered, whether it is during the initial mount +process or as the result of gfs_controld requesting a specific journal +recovery via the /sys/fs/gfs2/<fsname>/lock_module/recovery file. + +Because the CHANGE uevent was used (in early versions of gfs_controld) +without checking the environment variables to discover the state, we +cannot add any more functions to it without running the risk of +someone using an older version of the user tools and breaking their +cluster. For this reason the ONLINE uevent was used when adding a new +uevent for a successful mount or remount. + +4. OFFLINE + +The OFFLINE uevent is only generated due to filesystem errors and is used +as part of the "withdraw" mechanism. Currently this doesn't give any +information about what the error is, which is something that needs to +be fixed. + +5. REMOVE + +The REMOVE uevent is generated at the end of an unsuccessful mount +or at the end of a umount of the filesystem. All REMOVE uevents will +have been preceeded by at least an ADD uevent for the same fileystem, +and unlike the other uevents is generated automatically by the kernel's +kobject subsystem. + + +Information common to all GFS2 uevents (uevent environment variables) +---------------------------------------------------------------------- + +1. LOCKTABLE= + +The LOCKTABLE is a string, as supplied on the mount command +line (locktable=) or via fstab. It is used as a filesystem label +as well as providing the information for a lock_dlm mount to be +able to join the cluster. + +2. LOCKPROTO= + +The LOCKPROTO is a string, and its value depends on what is set +on the mount command line, or via fstab. It will be either +lock_nolock or lock_dlm. In the future other lock managers +may be supported. + +3. JOURNALID= + +If a journal is in use by the filesystem (journals are not +assigned for spectator mounts) then this will give the +numeric journal id in all GFS2 uevents. + +4. UUID= + +With recent versions of gfs2-utils, mkfs.gfs2 writes a UUID +into the filesystem superblock. If it exists, this will +be included in every uevent relating to the filesystem. + + + diff --git a/Documentation/filesystems/ncpfs.txt b/Documentation/filesystems/ncpfs.txt index f12c30c93f2f..5af164f4b37b 100644 --- a/Documentation/filesystems/ncpfs.txt +++ b/Documentation/filesystems/ncpfs.txt @@ -7,6 +7,6 @@ ftp.gwdg.de/pub/linux/misc/ncpfs, but sunsite and its many mirrors will have it as well. Related products are linware and mars_nwe, which will give Linux partial -NetWare server functionality. Linware's home site is -klokan.sh.cvut.cz/pub/linux/linware; mars_nwe can be found on -ftp.gwdg.de/pub/linux/misc/ncpfs. +NetWare server functionality. + +mars_nwe can be found on ftp.gwdg.de/pub/linux/misc/ncpfs. diff --git a/Documentation/filesystems/nfs/00-INDEX b/Documentation/filesystems/nfs/00-INDEX new file mode 100644 index 000000000000..2f68cd688769 --- /dev/null +++ b/Documentation/filesystems/nfs/00-INDEX @@ -0,0 +1,16 @@ +00-INDEX + - this file (nfs-related documentation). +Exporting + - explanation of how to make filesystems exportable. +knfsd-stats.txt + - statistics which the NFS server makes available to user space. +nfs.txt + - nfs client, and DNS resolution for fs_locations. +nfs41-server.txt + - info on the Linux server implementation of NFSv4 minor version 1. +nfs-rdma.txt + - how to install and setup the Linux NFS/RDMA client and server software +nfsroot.txt + - short guide on setting up a diskless box with NFS root filesystem. +rpc-cache.txt + - introduction to the caching mechanisms in the sunrpc layer. diff --git a/Documentation/filesystems/Exporting b/Documentation/filesystems/nfs/Exporting index 87019d2b5981..87019d2b5981 100644 --- a/Documentation/filesystems/Exporting +++ b/Documentation/filesystems/nfs/Exporting diff --git a/Documentation/filesystems/knfsd-stats.txt b/Documentation/filesystems/nfs/knfsd-stats.txt index 64ced5149d37..64ced5149d37 100644 --- a/Documentation/filesystems/knfsd-stats.txt +++ b/Documentation/filesystems/nfs/knfsd-stats.txt diff --git a/Documentation/filesystems/nfs-rdma.txt b/Documentation/filesystems/nfs/nfs-rdma.txt index e386f7e4bcee..e386f7e4bcee 100644 --- a/Documentation/filesystems/nfs-rdma.txt +++ b/Documentation/filesystems/nfs/nfs-rdma.txt diff --git a/Documentation/filesystems/nfs/nfs.txt b/Documentation/filesystems/nfs/nfs.txt new file mode 100644 index 000000000000..f50f26ce6cd0 --- /dev/null +++ b/Documentation/filesystems/nfs/nfs.txt @@ -0,0 +1,98 @@ + +The NFS client +============== + +The NFS version 2 protocol was first documented in RFC1094 (March 1989). +Since then two more major releases of NFS have been published, with NFSv3 +being documented in RFC1813 (June 1995), and NFSv4 in RFC3530 (April +2003). + +The Linux NFS client currently supports all the above published versions, +and work is in progress on adding support for minor version 1 of the NFSv4 +protocol. + +The purpose of this document is to provide information on some of the +upcall interfaces that are used in order to provide the NFS client with +some of the information that it requires in order to fully comply with +the NFS spec. + +The DNS resolver +================ + +NFSv4 allows for one server to refer the NFS client to data that has been +migrated onto another server by means of the special "fs_locations" +attribute. See + http://tools.ietf.org/html/rfc3530#section-6 +and + http://tools.ietf.org/html/draft-ietf-nfsv4-referrals-00 + +The fs_locations information can take the form of either an ip address and +a path, or a DNS hostname and a path. The latter requires the NFS client to +do a DNS lookup in order to mount the new volume, and hence the need for an +upcall to allow userland to provide this service. + +Assuming that the user has the 'rpc_pipefs' filesystem mounted in the usual +/var/lib/nfs/rpc_pipefs, the upcall consists of the following steps: + + (1) The process checks the dns_resolve cache to see if it contains a + valid entry. If so, it returns that entry and exits. + + (2) If no valid entry exists, the helper script '/sbin/nfs_cache_getent' + (may be changed using the 'nfs.cache_getent' kernel boot parameter) + is run, with two arguments: + - the cache name, "dns_resolve" + - the hostname to resolve + + (3) After looking up the corresponding ip address, the helper script + writes the result into the rpc_pipefs pseudo-file + '/var/lib/nfs/rpc_pipefs/cache/dns_resolve/channel' + in the following (text) format: + + "<ip address> <hostname> <ttl>\n" + + Where <ip address> is in the usual IPv4 (123.456.78.90) or IPv6 + (ffee:ddcc:bbaa:9988:7766:5544:3322:1100, ffee::1100, ...) format. + <hostname> is identical to the second argument of the helper + script, and <ttl> is the 'time to live' of this cache entry (in + units of seconds). + + Note: If <ip address> is invalid, say the string "0", then a negative + entry is created, which will cause the kernel to treat the hostname + as having no valid DNS translation. + + + + +A basic sample /sbin/nfs_cache_getent +===================================== + +#!/bin/bash +# +ttl=600 +# +cut=/usr/bin/cut +getent=/usr/bin/getent +rpc_pipefs=/var/lib/nfs/rpc_pipefs +# +die() +{ + echo "Usage: $0 cache_name entry_name" + exit 1 +} + +[ $# -lt 2 ] && die +cachename="$1" +cache_path=${rpc_pipefs}/cache/${cachename}/channel + +case "${cachename}" in + dns_resolve) + name="$2" + result="$(${getent} hosts ${name} | ${cut} -f1 -d\ )" + [ -z "${result}" ] && result="0" + ;; + *) + die + ;; +esac +echo "${result} ${name} ${ttl}" >${cache_path} + diff --git a/Documentation/filesystems/nfs41-server.txt b/Documentation/filesystems/nfs/nfs41-server.txt index 05d81cbcb2e1..1bd0d0c05171 100644 --- a/Documentation/filesystems/nfs41-server.txt +++ b/Documentation/filesystems/nfs/nfs41-server.txt @@ -11,6 +11,11 @@ the /proc/fs/nfsd/versions control file. Note that to write this control file, the nfsd service must be taken down. Use your user-mode nfs-utils to set this up; see rpc.nfsd(8) +(Warning: older servers will interpret "+4.1" and "-4.1" as "+4" and +"-4", respectively. Therefore, code meant to work on both new and old +kernels must turn 4.1 on or off *before* turning support for version 4 +on or off; rpc.nfsd does this correctly.) + The NFSv4 minorversion 1 (NFSv4.1) implementation in nfsd is based on the latest NFSv4.1 Internet Draft: http://tools.ietf.org/html/draft-ietf-nfsv4-minorversion1-29 @@ -25,6 +30,49 @@ are still under development out of tree. See http://wiki.linux-nfs.org/wiki/index.php/PNFS_prototype_design for more information. +The current implementation is intended for developers only: while it +does support ordinary file operations on clients we have tested against +(including the linux client), it is incomplete in ways which may limit +features unexpectedly, cause known bugs in rare cases, or cause +interoperability problems with future clients. Known issues: + + - gss support is questionable: currently mounts with kerberos + from a linux client are possible, but we aren't really + conformant with the spec (for example, we don't use kerberos + on the backchannel correctly). + - no trunking support: no clients currently take advantage of + trunking, but this is a mandatory feature, and its use is + recommended to clients in a number of places. (E.g. to ensure + timely renewal in case an existing connection's retry timeouts + have gotten too long; see section 8.3 of the draft.) + Therefore, lack of this feature may cause future clients to + fail. + - Incomplete backchannel support: incomplete backchannel gss + support and no support for BACKCHANNEL_CTL mean that + callbacks (hence delegations and layouts) may not be + available and clients confused by the incomplete + implementation may fail. + - Server reboot recovery is unsupported; if the server reboots, + clients may fail. + - We do not support SSV, which provides security for shared + client-server state (thus preventing unauthorized tampering + with locks and opens, for example). It is mandatory for + servers to support this, though no clients use it yet. + - Mandatory operations which we do not support, such as + DESTROY_CLIENTID, FREE_STATEID, SECINFO_NO_NAME, and + TEST_STATEID, are not currently used by clients, but will be + (and the spec recommends their uses in common cases), and + clients should not be expected to know how to recover from the + case where they are not supported. This will eventually cause + interoperability failures. + +In addition, some limitations are inherited from the current NFSv4 +implementation: + + - Incomplete delegation enforcement: if a file is renamed or + unlinked, a client holding a delegation may continue to + indefinitely allow opens of the file under the old name. + The table below, taken from the NFSv4.1 document, lists the operations that are mandatory to implement (REQ), optional (OPT), and NFSv4.0 operations that are required not to implement (MNI) @@ -142,6 +190,12 @@ NS*| CB_WANTS_CANCELLED | OPT | FDELG, | Section 20.10 | Implementation notes: +DELEGPURGE: +* mandatory only for servers that support CLAIM_DELEGATE_PREV and/or + CLAIM_DELEG_PREV_FH (which allows clients to keep delegations that + persist across client reboots). Thus we need not implement this for + now. + EXCHANGE_ID: * only SP4_NONE state protection supported * implementation ids are ignored @@ -159,3 +213,10 @@ The following cases aren't supported yet: DESTROY_CLIENTID, DESTROY_SESSION, EXCHANGE_ID. * DESTROY_SESSION MUST be the final operation in the COMPOUND request. +Nonstandard compound limitations: +* No support for a sessions fore channel RPC compound that requires both a + ca_maxrequestsize request and a ca_maxresponsesize reply, so we may + fail to live up to the promise we made in CREATE_SESSION fore channel + negotiation. +* No more than one IO operation (read, write, readdir) allowed per + compound. diff --git a/Documentation/filesystems/nfsroot.txt b/Documentation/filesystems/nfs/nfsroot.txt index 68baddf3c3e0..3ba0b945aaf8 100644 --- a/Documentation/filesystems/nfsroot.txt +++ b/Documentation/filesystems/nfs/nfsroot.txt @@ -105,7 +105,7 @@ ip=<client-ip>:<server-ip>:<gw-ip>:<netmask>:<hostname>:<device>:<autoconf> the client address and this parameter is NOT empty only replies from the specified server are accepted. - Only required for for NFS root. That is autoconfiguration + Only required for NFS root. That is autoconfiguration will not be triggered if it is missing and NFS root is not in operation. diff --git a/Documentation/filesystems/rpc-cache.txt b/Documentation/filesystems/nfs/rpc-cache.txt index 8a382bea6808..8a382bea6808 100644 --- a/Documentation/filesystems/rpc-cache.txt +++ b/Documentation/filesystems/nfs/rpc-cache.txt diff --git a/Documentation/filesystems/nilfs2.txt b/Documentation/filesystems/nilfs2.txt index 01539f410676..839efd8a8a8c 100644 --- a/Documentation/filesystems/nilfs2.txt +++ b/Documentation/filesystems/nilfs2.txt @@ -28,7 +28,7 @@ described in the man pages included in the package. Project web page: http://www.nilfs.org/en/ Download page: http://www.nilfs.org/en/download.html Git tree web page: http://www.nilfs.org/git/ -NILFS mailing lists: http://www.nilfs.org/mailman/listinfo/users +List info: http://vger.kernel.org/vger-lists.html#linux-nilfs Caveats ======= @@ -49,8 +49,7 @@ Mount options NILFS2 supports the following mount options: (*) == default -barrier=on(*) This enables/disables barriers. barrier=off disables - it, barrier=on enables it. +nobarrier Disables barriers. errors=continue(*) Keep going on a filesystem error. errors=remount-ro Remount the filesystem read-only on an error. errors=panic Panic and halt the machine if an error occurs. @@ -71,6 +70,10 @@ order=strict Apply strict in-order semantics that preserves sequence blocks. That means, it is guaranteed that no overtaking of events occurs in the recovered file system after a crash. +norecovery Disable recovery of the filesystem on mount. + This disables every write access on the device for + read-only mounts or snapshots. This option will fail + for r/w mounts on an unclean volume. NILFS2 usage ============ diff --git a/Documentation/filesystems/ocfs2.txt b/Documentation/filesystems/ocfs2.txt index c2a0871280a0..c58b9f5ba002 100644 --- a/Documentation/filesystems/ocfs2.txt +++ b/Documentation/filesystems/ocfs2.txt @@ -20,15 +20,16 @@ Lots of code taken from ext3 and other projects. Authors in alphabetical order: Joel Becker <joel.becker@oracle.com> Zach Brown <zach.brown@oracle.com> -Mark Fasheh <mark.fasheh@oracle.com> +Mark Fasheh <mfasheh@suse.com> Kurt Hackel <kurt.hackel@oracle.com> +Tao Ma <tao.ma@oracle.com> Sunil Mushran <sunil.mushran@oracle.com> Manish Singh <manish.singh@oracle.com> +Tiger Yang <tiger.yang@oracle.com> Caveats ======= Features which OCFS2 does not support yet: - - quotas - Directory change notification (F_NOTIFY) - Distributed Caching (F_SETLEASE/F_GETLEASE/break_lease) @@ -70,7 +71,6 @@ commit=nrsec (*) Ocfs2 can be told to sync all its data and metadata performance. localalloc=8(*) Allows custom localalloc size in MB. If the value is too large, the fs will silently revert it to the default. - Localalloc is not enabled for local mounts. localflocks This disables cluster aware flock. inode64 Indicates that Ocfs2 is allowed to create inodes at any location in the filesystem, including those which diff --git a/Documentation/filesystems/porting b/Documentation/filesystems/porting index 92b888d540a6..a7e9746ee7ea 100644 --- a/Documentation/filesystems/porting +++ b/Documentation/filesystems/porting @@ -140,7 +140,7 @@ Callers of notify_change() need ->i_mutex now. New super_block field "struct export_operations *s_export_op" for explicit support for exporting, e.g. via NFS. The structure is fully documented at its declaration in include/linux/fs.h, and in -Documentation/filesystems/Exporting. +Documentation/filesystems/nfs/Exporting. Briefly it allows for the definition of decode_fh and encode_fh operations to encode and decode filehandles, and allows the filesystem to use diff --git a/Documentation/filesystems/proc.txt b/Documentation/filesystems/proc.txt index ffead13f9443..0d07513a67a6 100644 --- a/Documentation/filesystems/proc.txt +++ b/Documentation/filesystems/proc.txt @@ -38,6 +38,7 @@ Table of Contents 3.3 /proc/<pid>/io - Display the IO accounting fields 3.4 /proc/<pid>/coredump_filter - Core dump filtering settings 3.5 /proc/<pid>/mountinfo - Information about mounts + 3.6 /proc/<pid>/comm & /proc/<pid>/task/<tid>/comm ------------------------------------------------------------------------------ @@ -307,7 +308,7 @@ address perms offset dev inode pathname 08049000-0804a000 rw-p 00001000 03:00 8312 /opt/test 0804a000-0806b000 rw-p 00000000 00:00 0 [heap] a7cb1000-a7cb2000 ---p 00000000 00:00 0 -a7cb2000-a7eb2000 rw-p 00000000 00:00 0 +a7cb2000-a7eb2000 rw-p 00000000 00:00 0 [threadstack:001ff4b4] a7eb2000-a7eb3000 ---p 00000000 00:00 0 a7eb3000-a7ed5000 rw-p 00000000 00:00 0 a7ed5000-a8008000 r-xp 00000000 03:00 4222 /lib/libc.so.6 @@ -343,6 +344,7 @@ is not associated with a file: [stack] = the stack of the main process [vdso] = the "virtual dynamic shared object", the kernel system call handler + [threadstack:xxxxxxxx] = the stack of the thread, xxxxxxxx is the stack size or if empty, the mapping is anonymous. @@ -375,6 +377,19 @@ of memory currently marked as referenced or accessed. This file is only present if the CONFIG_MMU kernel configuration option is enabled. +The /proc/PID/clear_refs is used to reset the PG_Referenced and ACCESSED/YOUNG +bits on both physical and virtual pages associated with a process. +To clear the bits for all the pages associated with the process + > echo 1 > /proc/PID/clear_refs + +To clear the bits for the anonymous pages associated with the process + > echo 2 > /proc/PID/clear_refs + +To clear the bits for the file mapped pages associated with the process + > echo 3 > /proc/PID/clear_refs +Any other value written to /proc/PID/clear_refs will have no effect. + + 1.2 Kernel data --------------- @@ -1032,9 +1047,9 @@ Various pieces of information about kernel activity are available in the since the system first booted. For a quick look, simply cat the file: > cat /proc/stat - cpu 2255 34 2290 22625563 6290 127 456 0 - cpu0 1132 34 1441 11311718 3675 127 438 0 - cpu1 1123 0 849 11313845 2614 0 18 0 + cpu 2255 34 2290 22625563 6290 127 456 0 0 + cpu0 1132 34 1441 11311718 3675 127 438 0 0 + cpu1 1123 0 849 11313845 2614 0 18 0 0 intr 114930548 113199788 3 0 5 263 0 4 [... lots more numbers ...] ctxt 1990473 btime 1062191376 @@ -1056,6 +1071,8 @@ second). The meanings of the columns are as follows, from left to right: - irq: servicing interrupts - softirq: servicing softirqs - steal: involuntary wait +- guest: running a normal guest +- guest_nice: running a niced guest The "intr" line gives counts of interrupts serviced since boot time, for each of the possible system interrupts. The first column is the total of all @@ -1071,8 +1088,8 @@ The "processes" line gives the number of processes and threads created, which includes (but is not limited to) those created by calls to the fork() and clone() system calls. -The "procs_running" line gives the number of processes currently running on -CPUs. +The "procs_running" line gives the total number of threads that are +running or ready to run (i.e., the total number of runnable threads). The "procs_blocked" line gives the number of processes currently blocked, waiting for I/O to complete. @@ -1096,7 +1113,6 @@ Table 1-12: Files in /proc/fs/ext4/<devname> .............................................................................. File Content mb_groups details of multiblock allocator buddy cache of free blocks - mb_history multiblock allocation history .............................................................................. @@ -1191,7 +1207,7 @@ The following heuristics are then applied: * if the task was reniced, its score doubles * superuser or direct hardware access tasks (CAP_SYS_ADMIN, CAP_SYS_RESOURCE or CAP_SYS_RAWIO) have their score divided by 4 - * if oom condition happened in one cpuset and checked task does not belong + * if oom condition happened in one cpuset and checked process does not belong to it, its score is divided by 8 * the resulting score is multiplied by two to the power of oom_adj, i.e. points <<= oom_adj when it is positive and @@ -1392,3 +1408,11 @@ For more information on mount propagation see: Documentation/filesystems/sharedsubtree.txt + +3.6 /proc/<pid>/comm & /proc/<pid>/task/<tid>/comm +-------------------------------------------------------- +These files provide a method to access a tasks comm value. It also allows for +a task to set its own or one of its thread siblings comm value. The comm value +is limited in size compared to the cmdline value, so writing anything longer +then the kernel's TASK_COMM_LEN (currently 16 chars) will result in a truncated +comm value. diff --git a/Documentation/filesystems/seq_file.txt b/Documentation/filesystems/seq_file.txt index b843743aa0b5..a1e2e0dda907 100644 --- a/Documentation/filesystems/seq_file.txt +++ b/Documentation/filesystems/seq_file.txt @@ -46,7 +46,7 @@ better to do. The file is seekable, in that one can do something like the following: dd if=/proc/sequence of=out1 count=1 - dd if=/proc/sequence skip=1 out=out2 count=1 + dd if=/proc/sequence skip=1 of=out2 count=1 Then concatenate the output files out1 and out2 and get the right result. Yes, it is a thoroughly useless module, but the point is to show @@ -248,9 +248,7 @@ code, that is done in the initialization code in the usual way: { struct proc_dir_entry *entry; - entry = create_proc_entry("sequence", 0, NULL); - if (entry) - entry->proc_fops = &ct_file_ops; + proc_create("sequence", 0, NULL, &ct_file_ops); return 0; } diff --git a/Documentation/filesystems/sharedsubtree.txt b/Documentation/filesystems/sharedsubtree.txt index 736540045dc7..23a181074f94 100644 --- a/Documentation/filesystems/sharedsubtree.txt +++ b/Documentation/filesystems/sharedsubtree.txt @@ -4,7 +4,7 @@ Shared Subtrees Contents: 1) Overview 2) Features - 3) smount command + 3) Setting mount states 4) Use-case 5) Detailed semantics 6) Quiz @@ -41,14 +41,14 @@ replicas continue to be exactly same. Here is an example: - Lets say /mnt has a mount that is shared. + Let's say /mnt has a mount that is shared. mount --make-shared /mnt - note: mount command does not yet support the --make-shared flag. - I have included a small C program which does the same by executing - 'smount /mnt shared' + Note: mount(8) command now supports the --make-shared flag, + so the sample 'smount' program is no longer needed and has been + removed. - #mount --bind /mnt /tmp + # mount --bind /mnt /tmp The above command replicates the mount at /mnt to the mountpoint /tmp and the contents of both the mounts remain identical. @@ -58,8 +58,8 @@ replicas continue to be exactly same. #ls /tmp a b c - Now lets say we mount a device at /tmp/a - #mount /dev/sd0 /tmp/a + Now let's say we mount a device at /tmp/a + # mount /dev/sd0 /tmp/a #ls /tmp/a t1 t2 t2 @@ -80,21 +80,20 @@ replicas continue to be exactly same. Here is an example: - Lets say /mnt has a mount which is shared. - #mount --make-shared /mnt + Let's say /mnt has a mount which is shared. + # mount --make-shared /mnt - Lets bind mount /mnt to /tmp - #mount --bind /mnt /tmp + Let's bind mount /mnt to /tmp + # mount --bind /mnt /tmp the new mount at /tmp becomes a shared mount and it is a replica of the mount at /mnt. - Now lets make the mount at /tmp; a slave of /mnt - #mount --make-slave /tmp - [or smount /tmp slave] + Now let's make the mount at /tmp; a slave of /mnt + # mount --make-slave /tmp - lets mount /dev/sd0 on /mnt/a - #mount /dev/sd0 /mnt/a + let's mount /dev/sd0 on /mnt/a + # mount /dev/sd0 /mnt/a #ls /mnt/a t1 t2 t3 @@ -104,9 +103,9 @@ replicas continue to be exactly same. Note the mount event has propagated to the mount at /tmp - However lets see what happens if we mount something on the mount at /tmp + However let's see what happens if we mount something on the mount at /tmp - #mount /dev/sd1 /tmp/b + # mount /dev/sd1 /tmp/b #ls /tmp/b s1 s2 s3 @@ -124,12 +123,11 @@ replicas continue to be exactly same. 2d) A unbindable mount is a unbindable private mount - lets say we have a mount at /mnt and we make is unbindable + let's say we have a mount at /mnt and we make is unbindable - #mount --make-unbindable /mnt - [ smount /mnt unbindable ] + # mount --make-unbindable /mnt - Lets try to bind mount this mount somewhere else. + Let's try to bind mount this mount somewhere else. # mount --bind /mnt /tmp mount: wrong fs type, bad option, bad superblock on /mnt, or too many mounted file systems @@ -137,149 +135,15 @@ replicas continue to be exactly same. Binding a unbindable mount is a invalid operation. -3) smount command +3) Setting mount states - Currently the mount command is not aware of shared subtree features. - Work is in progress to add the support in mount ( util-linux package ). - Till then use the following program. + The mount command (util-linux package) can be used to set mount + states: - ------------------------------------------------------------------------ - // - //this code was developed my Miklos Szeredi <miklos@szeredi.hu> - //and modified by Ram Pai <linuxram@us.ibm.com> - // sample usage: - // smount /tmp shared - // - #include <stdio.h> - #include <stdlib.h> - #include <unistd.h> - #include <string.h> - #include <sys/mount.h> - #include <sys/fsuid.h> - - #ifndef MS_REC - #define MS_REC 0x4000 /* 16384: Recursive loopback */ - #endif - - #ifndef MS_SHARED - #define MS_SHARED 1<<20 /* Shared */ - #endif - - #ifndef MS_PRIVATE - #define MS_PRIVATE 1<<18 /* Private */ - #endif - - #ifndef MS_SLAVE - #define MS_SLAVE 1<<19 /* Slave */ - #endif - - #ifndef MS_UNBINDABLE - #define MS_UNBINDABLE 1<<17 /* Unbindable */ - #endif - - int main(int argc, char *argv[]) - { - int type; - if(argc != 3) { - fprintf(stderr, "usage: %s dir " - "<rshared|rslave|rprivate|runbindable|shared|slave" - "|private|unbindable>\n" , argv[0]); - return 1; - } - - fprintf(stdout, "%s %s %s\n", argv[0], argv[1], argv[2]); - - if (strcmp(argv[2],"rshared")==0) - type=(MS_SHARED|MS_REC); - else if (strcmp(argv[2],"rslave")==0) - type=(MS_SLAVE|MS_REC); - else if (strcmp(argv[2],"rprivate")==0) - type=(MS_PRIVATE|MS_REC); - else if (strcmp(argv[2],"runbindable")==0) - type=(MS_UNBINDABLE|MS_REC); - else if (strcmp(argv[2],"shared")==0) - type=MS_SHARED; - else if (strcmp(argv[2],"slave")==0) - type=MS_SLAVE; - else if (strcmp(argv[2],"private")==0) - type=MS_PRIVATE; - else if (strcmp(argv[2],"unbindable")==0) - type=MS_UNBINDABLE; - else { - fprintf(stderr, "invalid operation: %s\n", argv[2]); - return 1; - } - setfsuid(getuid()); - - if(mount("", argv[1], "dontcare", type, "") == -1) { - perror("mount"); - return 1; - } - return 0; - } - ----------------------------------------------------------------------- - - Copy the above code snippet into smount.c - gcc -o smount smount.c - - - (i) To mark all the mounts under /mnt as shared execute the following - command: - - smount /mnt rshared - the corresponding syntax planned for mount command is - mount --make-rshared /mnt - - just to mark a mount /mnt as shared, execute the following - command: - smount /mnt shared - the corresponding syntax planned for mount command is - mount --make-shared /mnt - - (ii) To mark all the shared mounts under /mnt as slave execute the - following - - command: - smount /mnt rslave - the corresponding syntax planned for mount command is - mount --make-rslave /mnt - - just to mark a mount /mnt as slave, execute the following - command: - smount /mnt slave - the corresponding syntax planned for mount command is - mount --make-slave /mnt - - (iii) To mark all the mounts under /mnt as private execute the - following command: - - smount /mnt rprivate - the corresponding syntax planned for mount command is - mount --make-rprivate /mnt - - just to mark a mount /mnt as private, execute the following - command: - smount /mnt private - the corresponding syntax planned for mount command is - mount --make-private /mnt - - NOTE: by default all the mounts are created as private. But if - you want to change some shared/slave/unbindable mount as - private at a later point in time, this command can help. - - (iv) To mark all the mounts under /mnt as unbindable execute the - following - - command: - smount /mnt runbindable - the corresponding syntax planned for mount command is - mount --make-runbindable /mnt - - just to mark a mount /mnt as unbindable, execute the following - command: - smount /mnt unbindable - the corresponding syntax planned for mount command is - mount --make-unbindable /mnt + mount --make-shared mountpoint + mount --make-slave mountpoint + mount --make-private mountpoint + mount --make-unbindable mountpoint 4) Use cases @@ -350,7 +214,7 @@ replicas continue to be exactly same. mount --rbind / /view/v3 mount --rbind / /view/v4 - and if /usr has a versioning filesystem mounted, than that + and if /usr has a versioning filesystem mounted, then that mount appears at /view/v1/usr, /view/v2/usr, /view/v3/usr and /view/v4/usr too @@ -390,7 +254,7 @@ replicas continue to be exactly same. For example: mount --make-shared /mnt - mount --bin /mnt /tmp + mount --bind /mnt /tmp The mount at /mnt and that at /tmp are both shared and belong to the same peer group. Anything mounted or unmounted under @@ -558,7 +422,7 @@ replicas continue to be exactly same. then the subtree under the unbindable mount is pruned in the new location. - eg: lets say we have the following mount tree. + eg: let's say we have the following mount tree. A / \ @@ -566,7 +430,7 @@ replicas continue to be exactly same. / \ / \ D E F G - Lets say all the mount except the mount C in the tree are + Let's say all the mount except the mount C in the tree are of a type other than unbindable. If this tree is rbound to say Z @@ -683,13 +547,13 @@ replicas continue to be exactly same. 'b' on mounts that receive propagation from mount 'B' and does not have sub-mounts within them are unmounted. - Example: Lets say 'B1', 'B2', 'B3' are shared mounts that propagate to + Example: Let's say 'B1', 'B2', 'B3' are shared mounts that propagate to each other. - lets say 'A1', 'A2', 'A3' are first mounted at dentry 'b' on mount + let's say 'A1', 'A2', 'A3' are first mounted at dentry 'b' on mount 'B1', 'B2' and 'B3' respectively. - lets say 'C1', 'C2', 'C3' are next mounted at the same dentry 'b' on + let's say 'C1', 'C2', 'C3' are next mounted at the same dentry 'b' on mount 'B1', 'B2' and 'B3' respectively. if 'C1' is unmounted, all the mounts that are most-recently-mounted on @@ -710,7 +574,7 @@ replicas continue to be exactly same. A cloned namespace contains all the mounts as that of the parent namespace. - Lets say 'A' and 'B' are the corresponding mounts in the parent and the + Let's say 'A' and 'B' are the corresponding mounts in the parent and the child namespace. If 'A' is shared, then 'B' is also shared and 'A' and 'B' propagate to @@ -759,11 +623,11 @@ replicas continue to be exactly same. mount --make-slave /mnt At this point we have the first mount at /tmp and - its root dentry is 1. Lets call this mount 'A' + its root dentry is 1. Let's call this mount 'A' And then we have a second mount at /tmp1 with root - dentry 2. Lets call this mount 'B' + dentry 2. Let's call this mount 'B' Next we have a third mount at /mnt with root dentry - mnt. Lets call this mount 'C' + mnt. Let's call this mount 'C' 'B' is the slave of 'A' and 'C' is a slave of 'B' A -> B -> C @@ -794,7 +658,7 @@ replicas continue to be exactly same. Q3 Why is unbindable mount needed? - Lets say we want to replicate the mount tree at multiple + Let's say we want to replicate the mount tree at multiple locations within the same subtree. if one rbind mounts a tree within the same subtree 'n' times @@ -803,7 +667,7 @@ replicas continue to be exactly same. mounts. Here is a example. step 1: - lets say the root tree has just two directories with + let's say the root tree has just two directories with one vfsmount. root / \ @@ -875,7 +739,7 @@ replicas continue to be exactly same. Unclonable mounts come in handy here. step 1: - lets say the root tree has just two directories with + let's say the root tree has just two directories with one vfsmount. root / \ diff --git a/Documentation/filesystems/sysfs.txt b/Documentation/filesystems/sysfs.txt index b245d524d568..931c806642c5 100644 --- a/Documentation/filesystems/sysfs.txt +++ b/Documentation/filesystems/sysfs.txt @@ -91,8 +91,8 @@ struct device_attribute { const char *buf, size_t count); }; -int device_create_file(struct device *, struct device_attribute *); -void device_remove_file(struct device *, struct device_attribute *); +int device_create_file(struct device *, const struct device_attribute *); +void device_remove_file(struct device *, const struct device_attribute *); It also defines this helper for defining device attributes: @@ -316,8 +316,8 @@ DEVICE_ATTR(_name, _mode, _show, _store); Creation/Removal: -int device_create_file(struct device *device, struct device_attribute * attr); -void device_remove_file(struct device * dev, struct device_attribute * attr); +int device_create_file(struct device *dev, const struct device_attribute * attr); +void device_remove_file(struct device *dev, const struct device_attribute * attr); - bus drivers (include/linux/device.h) @@ -358,7 +358,7 @@ DRIVER_ATTR(_name, _mode, _show, _store) Creation/Removal: -int driver_create_file(struct device_driver *, struct driver_attribute *); -void driver_remove_file(struct device_driver *, struct driver_attribute *); +int driver_create_file(struct device_driver *, const struct driver_attribute *); +void driver_remove_file(struct device_driver *, const struct driver_attribute *); diff --git a/Documentation/filesystems/vfat.txt b/Documentation/filesystems/vfat.txt index b58b84b50fa2..eed520fd0c8e 100644 --- a/Documentation/filesystems/vfat.txt +++ b/Documentation/filesystems/vfat.txt @@ -102,7 +102,7 @@ shortname=lower|win95|winnt|mixed winnt: emulate the Windows NT rule for display/create. mixed: emulate the Windows NT rule for display, emulate the Windows 95 rule for create. - Default setting is `lower'. + Default setting is `mixed'. tz=UTC -- Interpret timestamps as UTC rather than local time. This option disables the conversion of timestamps diff --git a/Documentation/filesystems/vfs.txt b/Documentation/filesystems/vfs.txt index f49eecf2e573..3de2f32edd90 100644 --- a/Documentation/filesystems/vfs.txt +++ b/Documentation/filesystems/vfs.txt @@ -472,7 +472,7 @@ __sync_single_inode) to check if ->writepages has been successful in writing out the whole address_space. The Writeback tag is used by filemap*wait* and sync_page* functions, -via wait_on_page_writeback_range, to wait for all writeback to +via filemap_fdatawait_range, to wait for all writeback to complete. While waiting ->sync_page (if defined) will be called on each page that is found to require writeback. @@ -536,6 +536,7 @@ struct address_space_operations { /* migrate the contents of a page to the specified target */ int (*migratepage) (struct page *, struct page *); int (*launder_page) (struct page *); + int (*error_remove_page) (struct mapping *mapping, struct page *page); }; writepage: called by the VM to write a dirty page to backing store. @@ -694,6 +695,12 @@ struct address_space_operations { prevent redirtying the page, it is kept locked during the whole operation. + error_remove_page: normally set to generic_error_remove_page if truncation + is ok for this address space. Used for memory failure handling. + Setting this implies you deal with pages going away under you, + unless you have them locked or reference counts increased. + + The File Object =============== diff --git a/Documentation/flexible-arrays.txt b/Documentation/flexible-arrays.txt new file mode 100644 index 000000000000..cb8a3a00cc92 --- /dev/null +++ b/Documentation/flexible-arrays.txt @@ -0,0 +1,120 @@ +Using flexible arrays in the kernel +Last updated for 2.6.32 +Jonathan Corbet <corbet@lwn.net> + +Large contiguous memory allocations can be unreliable in the Linux kernel. +Kernel programmers will sometimes respond to this problem by allocating +pages with vmalloc(). This solution not ideal, though. On 32-bit systems, +memory from vmalloc() must be mapped into a relatively small address space; +it's easy to run out. On SMP systems, the page table changes required by +vmalloc() allocations can require expensive cross-processor interrupts on +all CPUs. And, on all systems, use of space in the vmalloc() range +increases pressure on the translation lookaside buffer (TLB), reducing the +performance of the system. + +In many cases, the need for memory from vmalloc() can be eliminated by +piecing together an array from smaller parts; the flexible array library +exists to make this task easier. + +A flexible array holds an arbitrary (within limits) number of fixed-sized +objects, accessed via an integer index. Sparse arrays are handled +reasonably well. Only single-page allocations are made, so memory +allocation failures should be relatively rare. The down sides are that the +arrays cannot be indexed directly, individual object size cannot exceed the +system page size, and putting data into a flexible array requires a copy +operation. It's also worth noting that flexible arrays do no internal +locking at all; if concurrent access to an array is possible, then the +caller must arrange for appropriate mutual exclusion. + +The creation of a flexible array is done with: + + #include <linux/flex_array.h> + + struct flex_array *flex_array_alloc(int element_size, + unsigned int total, + gfp_t flags); + +The individual object size is provided by element_size, while total is the +maximum number of objects which can be stored in the array. The flags +argument is passed directly to the internal memory allocation calls. With +the current code, using flags to ask for high memory is likely to lead to +notably unpleasant side effects. + +It is also possible to define flexible arrays at compile time with: + + DEFINE_FLEX_ARRAY(name, element_size, total); + +This macro will result in a definition of an array with the given name; the +element size and total will be checked for validity at compile time. + +Storing data into a flexible array is accomplished with a call to: + + int flex_array_put(struct flex_array *array, unsigned int element_nr, + void *src, gfp_t flags); + +This call will copy the data from src into the array, in the position +indicated by element_nr (which must be less than the maximum specified when +the array was created). If any memory allocations must be performed, flags +will be used. The return value is zero on success, a negative error code +otherwise. + +There might possibly be a need to store data into a flexible array while +running in some sort of atomic context; in this situation, sleeping in the +memory allocator would be a bad thing. That can be avoided by using +GFP_ATOMIC for the flags value, but, often, there is a better way. The +trick is to ensure that any needed memory allocations are done before +entering atomic context, using: + + int flex_array_prealloc(struct flex_array *array, unsigned int start, + unsigned int end, gfp_t flags); + +This function will ensure that memory for the elements indexed in the range +defined by start and end has been allocated. Thereafter, a +flex_array_put() call on an element in that range is guaranteed not to +block. + +Getting data back out of the array is done with: + + void *flex_array_get(struct flex_array *fa, unsigned int element_nr); + +The return value is a pointer to the data element, or NULL if that +particular element has never been allocated. + +Note that it is possible to get back a valid pointer for an element which +has never been stored in the array. Memory for array elements is allocated +one page at a time; a single allocation could provide memory for several +adjacent elements. Flexible array elements are normally initialized to the +value FLEX_ARRAY_FREE (defined as 0x6c in <linux/poison.h>), so errors +involving that number probably result from use of unstored array entries. +Note that, if array elements are allocated with __GFP_ZERO, they will be +initialized to zero and this poisoning will not happen. + +Individual elements in the array can be cleared with: + + int flex_array_clear(struct flex_array *array, unsigned int element_nr); + +This function will set the given element to FLEX_ARRAY_FREE and return +zero. If storage for the indicated element is not allocated for the array, +flex_array_clear() will return -EINVAL instead. Note that clearing an +element does not release the storage associated with it; to reduce the +allocated size of an array, call: + + int flex_array_shrink(struct flex_array *array); + +The return value will be the number of pages of memory actually freed. +This function works by scanning the array for pages containing nothing but +FLEX_ARRAY_FREE bytes, so (1) it can be expensive, and (2) it will not work +if the array's pages are allocated with __GFP_ZERO. + +It is possible to remove all elements of an array with a call to: + + void flex_array_free_parts(struct flex_array *array); + +This call frees all elements, but leaves the array itself in place. +Freeing the entire array is done with: + + void flex_array_free(struct flex_array *array); + +As of this writing, there are no users of flexible arrays in the mainline +kernel. The functions described here are also not exported to modules; +that will probably be fixed when somebody comes up with a need for it. diff --git a/Documentation/gcov.txt b/Documentation/gcov.txt index 40ec63352760..e7ca6478cd93 100644 --- a/Documentation/gcov.txt +++ b/Documentation/gcov.txt @@ -47,7 +47,7 @@ Possible uses: Configure the kernel with: - CONFIG_DEBUGFS=y + CONFIG_DEBUG_FS=y CONFIG_GCOV_KERNEL=y and to get coverage data for the entire kernel: diff --git a/Documentation/gpio.txt b/Documentation/gpio.txt index e4b6985044a2..1866c27eec69 100644 --- a/Documentation/gpio.txt +++ b/Documentation/gpio.txt @@ -380,7 +380,7 @@ rare; use gpiochip_remove() when it is unavoidable. Most often a gpio_chip is part of an instance-specific structure with state not exposed by the GPIO interfaces, such as addressing, power management, -and more. Chips such as codecs will have complex non-GPIO state, +and more. Chips such as codecs will have complex non-GPIO state. Any debugfs dump method should normally ignore signals which haven't been requested as GPIOs. They can use gpiochip_is_requested(), which returns @@ -524,7 +524,21 @@ and have the following read/write attributes: is configured as an output, this value may be written; any nonzero value is treated as high. -GPIO controllers have paths like /sys/class/gpio/chipchip42/ (for the + "edge" ... reads as either "none", "rising", "falling", or + "both". Write these strings to select the signal edge(s) + that will make poll(2) on the "value" file return. + + This file exists only if the pin can be configured as an + interrupt generating input pin. + + "active_low" ... reads as either 0 (false) or 1 (true). Write + any nonzero value to invert the value attribute both + for reading and writing. Existing and subsequent + poll(2) support configuration via the edge attribute + for "rising" and "falling" edges will follow this + setting. + +GPIO controllers have paths like /sys/class/gpio/gpiochip42/ (for the controller implementing GPIOs starting at #42) and have the following read-only attributes: @@ -555,6 +569,13 @@ requested using gpio_request(): /* reverse gpio_export() */ void gpio_unexport(); + /* create a sysfs link to an exported GPIO node */ + int gpio_export_link(struct device *dev, const char *name, + unsigned gpio) + + /* change the polarity of a GPIO node in sysfs */ + int gpio_sysfs_set_active_low(unsigned gpio, int value); + After a kernel driver requests a GPIO, it may only be made available in the sysfs interface by gpio_export(). The driver can control whether the signal direction may change. This helps drivers prevent userspace code @@ -563,3 +584,14 @@ from accidentally clobbering important system state. This explicit exporting can help with debugging (by making some kinds of experiments easier), or can provide an always-there interface that's suitable for documenting as part of a board support package. + +After the GPIO has been exported, gpio_export_link() allows creating +symlinks from elsewhere in sysfs to the GPIO sysfs node. Drivers can +use this to provide the interface under their own device in sysfs with +a descriptive name. + +Drivers can use gpio_sysfs_set_active_low() to hide GPIO line polarity +differences between boards from user space. This only affects the +sysfs interface. Polarity change can be done both before and after +gpio_export(), and previously enabled poll(2) support for either +rising or falling edge will be reconfigured to follow this setting. diff --git a/Documentation/hwmon/acpi_power_meter b/Documentation/hwmon/acpi_power_meter new file mode 100644 index 000000000000..c80399a00c50 --- /dev/null +++ b/Documentation/hwmon/acpi_power_meter @@ -0,0 +1,51 @@ +Kernel driver power_meter +========================= + +This driver talks to ACPI 4.0 power meters. + +Supported systems: + * Any recent system with ACPI 4.0. + Prefix: 'power_meter' + Datasheet: http://acpi.info/, section 10.4. + +Author: Darrick J. Wong + +Description +----------- + +This driver implements sensor reading support for the power meters exposed in +the ACPI 4.0 spec (Chapter 10.4). These devices have a simple set of +features--a power meter that returns average power use over a configurable +interval, an optional capping mechanism, and a couple of trip points. The +sysfs interface conforms with the specification outlined in the "Power" section +of Documentation/hwmon/sysfs-interface. + +Special Features +---------------- + +The power[1-*]_is_battery knob indicates if the power supply is a battery. +Both power[1-*]_average_{min,max} must be set before the trip points will work. +When both of them are set, an ACPI event will be broadcast on the ACPI netlink +socket and a poll notification will be sent to the appropriate +power[1-*]_average sysfs file. + +The power[1-*]_{model_number, serial_number, oem_info} fields display arbitrary +strings that ACPI provides with the meter. The measures/ directory contains +symlinks to the devices that this meter measures. + +Some computers have the ability to enforce a power cap in hardware. If this is +the case, the power[1-*]_cap and related sysfs files will appear. When the +average power consumption exceeds the cap, an ACPI event will be broadcast on +the netlink event socket and a poll notification will be sent to the +appropriate power[1-*]_alarm file to indicate that capping has begun, and the +hardware has taken action to reduce power consumption. Most likely this will +result in reduced performance. + +There are a few other ACPI notifications that can be sent by the firmware. In +all cases the ACPI event will be broadcast on the ACPI netlink event socket as +well as sent as a poll notification to a sysfs file. The events are as +follows: + +power[1-*]_cap will be notified if the firmware changes the power cap. +power[1-*]_interval will be notified if the firmware changes the averaging +interval. diff --git a/Documentation/hwmon/adt7473 b/Documentation/hwmon/adt7473 index 1cbf671822e2..446612bd1fb9 100644 --- a/Documentation/hwmon/adt7473 +++ b/Documentation/hwmon/adt7473 @@ -9,6 +9,8 @@ Supported chips: Author: Darrick J. Wong +This driver is depreacted, please use the adt7475 driver instead. + Description ----------- diff --git a/Documentation/hwmon/adt7475 b/Documentation/hwmon/adt7475 index a2b1abec850e..0502f2b464e1 100644 --- a/Documentation/hwmon/adt7475 +++ b/Documentation/hwmon/adt7475 @@ -1,87 +1,117 @@ -This describes the interface for the ADT7475 driver: - -(there are 4 fans, numbered fan1 to fan4): - -fanX_input Read the current speed of the fan (in RPMs) -fanX_min Read/write the minimum speed of the fan. Dropping - below this sets an alarm. - -(there are three PWMs, numbered pwm1 to pwm3): - -pwmX Read/write the current duty cycle of the PWM. Writes - only have effect when auto mode is turned off (see - below). Range is 0 - 255. - -pwmX_enable Fan speed control method: - - 0 - No control (fan at full speed) - 1 - Manual fan speed control (using pwm[1-*]) - 2 - Automatic fan speed control - -pwmX_auto_channels_temp Select which channels affect this PWM - - 1 - TEMP1 controls PWM - 2 - TEMP2 controls PWM - 4 - TEMP3 controls PWM - 6 - TEMP2 and TEMP3 control PWM - 7 - All three inputs control PWM - -pwmX_freq Read/write the PWM frequency in Hz. The number - should be one of the following: - - 11 Hz - 14 Hz - 22 Hz - 29 Hz - 35 Hz - 44 Hz - 58 Hz - 88 Hz - -pwmX_auto_point1_pwm Read/write the minimum PWM duty cycle in automatic mode - -pwmX_auto_point2_pwm Read/write the maximum PWM duty cycle in automatic mode - -(there are three temperature settings numbered temp1 to temp3): - -tempX_input Read the current temperature. The value is in milli - degrees of Celsius. - -tempX_max Read/write the upper temperature limit - exceeding this - will cause an alarm. - -tempX_min Read/write the lower temperature limit - exceeding this - will cause an alarm. - -tempX_offset Read/write the temperature adjustment offset - -tempX_crit Read/write the THERM limit for remote1. - -tempX_crit_hyst Set the temperature value below crit where the - fans will stay on - this helps drive the temperature - low enough so it doesn't stay near the edge and - cause THERM to keep tripping. - -tempX_auto_point1_temp Read/write the minimum temperature where the fans will - turn on in automatic mode. - -tempX_auto_point2_temp Read/write the maximum temperature over which the fans - will run in automatic mode. tempX_auto_point1_temp - and tempX_auto_point2_temp together define the - range of automatic control. - -tempX_alarm Read a 1 if the max/min alarm is set -tempX_fault Read a 1 if either temp1 or temp3 diode has a fault - -(There are two voltage settings, in1 and in2): - -inX_input Read the current voltage on VCC. Value is in - millivolts. - -inX_min read/write the minimum voltage limit. - Dropping below this causes an alarm. - -inX_max read/write the maximum voltage limit. - Exceeding this causes an alarm. - -inX_alarm Read a 1 if the max/min alarm is set. +Kernel driver adt7475 +===================== + +Supported chips: + * Analog Devices ADT7473 + Prefix: 'adt7473' + Addresses scanned: I2C 0x2C, 0x2D, 0x2E + Datasheet: Publicly available at the On Semiconductors website + * Analog Devices ADT7475 + Prefix: 'adt7475' + Addresses scanned: I2C 0x2E + Datasheet: Publicly available at the On Semiconductors website + * Analog Devices ADT7476 + Prefix: 'adt7476' + Addresses scanned: I2C 0x2C, 0x2D, 0x2E + Datasheet: Publicly available at the On Semiconductors website + * Analog Devices ADT7490 + Prefix: 'adt7490' + Addresses scanned: I2C 0x2C, 0x2D, 0x2E + Datasheet: Publicly available at the On Semiconductors website + +Authors: + Jordan Crouse + Hans de Goede + Darrick J. Wong (documentation) + Jean Delvare + + +Description +----------- + +This driver implements support for the Analog Devices ADT7473, ADT7475, +ADT7476 and ADT7490 chip family. The ADT7473 and ADT7475 differ only in +minor details. The ADT7476 has additional features, including extra voltage +measurement inputs and VID support. The ADT7490 also has additional +features, including extra voltage measurement inputs and PECI support. All +the supported chips will be collectively designed by the name "ADT747x" in +the rest of this document. + +The ADT747x uses the 2-wire interface compatible with the SMBus 2.0 +specification. Using an analog to digital converter it measures three (3) +temperatures and two (2) or more voltages. It has four (4) 16-bit counters +for measuring fan speed. There are three (3) PWM outputs that can be used +to control fan speed. + +A sophisticated control system for the PWM outputs is designed into the +ADT747x that allows fan speed to be adjusted automatically based on any of the +three temperature sensors. Each PWM output is individually adjustable and +programmable. Once configured, the ADT747x will adjust the PWM outputs in +response to the measured temperatures without further host intervention. +This feature can also be disabled for manual control of the PWM's. + +Each of the measured inputs (voltage, temperature, fan speed) has +corresponding high/low limit values. The ADT747x will signal an ALARM if +any measured value exceeds either limit. + +The ADT747x samples all inputs continuously. The driver will not read +the registers more often than once every other second. Further, +configuration data is only read once per minute. + +Chip Differences Summary +------------------------ + +ADT7473: + * 2 voltage inputs + * system acoustics optimizations (not implemented) + +ADT7475: + * 2 voltage inputs + +ADT7476: + * 5 voltage inputs + * VID support + +ADT7490: + * 6 voltage inputs + * 1 Imon input (not implemented) + * PECI support (not implemented) + * 2 GPIO pins (not implemented) + * system acoustics optimizations (not implemented) + +Special Features +---------------- + +The ADT747x has a 10-bit ADC and can therefore measure temperatures +with a resolution of 0.25 degree Celsius. Temperature readings can be +configured either for two's complement format or "Offset 64" format, +wherein 64 is subtracted from the raw value to get the temperature value. + +The datasheet is very detailed and describes a procedure for determining +an optimal configuration for the automatic PWM control. + +Fan Speed Control +----------------- + +The driver exposes two trip points per PWM channel. + +point1: Set the PWM speed at the lower temperature bound +point2: Set the PWM speed at the higher temperature bound + +The ADT747x will scale the PWM linearly between the lower and higher PWM +speed when the temperature is between the two temperature boundaries. +Temperature boundaries are associated to temperature channels rather than +PWM outputs, and a given PWM output can be controlled by several temperature +channels. As a result, the ADT747x may compute more than one PWM value +for a channel at a given time, in which case the maximum value (fastest +fan speed) is applied. PWM values range from 0 (off) to 255 (full speed). + +Fan speed may be set to maximum when the temperature sensor associated with +the PWM control exceeds temp#_max. + +Notes +----- + +The nVidia binary driver presents an ADT7473 chip via an on-card i2c bus. +Unfortunately, they fail to set the i2c adapter class, so this driver may +fail to find the chip until the nvidia driver is patched. diff --git a/Documentation/hwmon/amc6821 b/Documentation/hwmon/amc6821 new file mode 100644 index 000000000000..ced8359c50f8 --- /dev/null +++ b/Documentation/hwmon/amc6821 @@ -0,0 +1,102 @@ +Kernel driver amc6821 +===================== + +Supported chips: + Texas Instruments AMC6821 + Prefix: 'amc6821' + Addresses scanned: 0x18, 0x19, 0x1a, 0x2c, 0x2d, 0x2e, 0x4c, 0x4d, 0x4e + Datasheet: http://focus.ti.com/docs/prod/folders/print/amc6821.html + +Authors: + Tomaz Mertelj <tomaz.mertelj@guest.arnes.si> + + +Description +----------- + +This driver implements support for the Texas Instruments amc6821 chip. +The chip has one on-chip and one remote temperature sensor and one pwm fan +regulator. +The pwm can be controlled either from software or automatically. + +The driver provides the following sensor accesses in sysfs: + +temp1_input ro on-chip temperature +temp1_min rw " +temp1_max rw " +temp1_crit rw " +temp1_min_alarm ro " +temp1_max_alarm ro " +temp1_crit_alarm ro " + +temp2_input ro remote temperature +temp2_min rw " +temp2_max rw " +temp2_crit rw " +temp2_min_alarm ro " +temp2_max_alarm ro " +temp2_crit_alarm ro " +temp2_fault ro " + +fan1_input ro tachometer speed +fan1_min rw " +fan1_max rw " +fan1_fault ro " +fan1_div rw Fan divisor can be either 2 or 4. + +pwm1 rw pwm1 +pwm1_enable rw regulator mode, 1=open loop, 2=fan controlled + by remote temperature, 3=fan controlled by + combination of the on-chip temperature and + remote-sensor temperature, +pwm1_auto_channels_temp ro 1 if pwm_enable==2, 3 if pwm_enable==3 +pwm1_auto_point1_pwm ro Hardwired to 0, shared for both + temperature channels. +pwm1_auto_point2_pwm rw This value is shared for both temperature + channels. +pwm1_auto_point3_pwm rw Hardwired to 255, shared for both + temperature channels. + +temp1_auto_point1_temp ro Hardwired to temp2_auto_point1_temp + which is rw. Below this temperature fan stops. +temp1_auto_point2_temp rw The low-temperature limit of the proportional + range. Below this temperature + pwm1 = pwm1_auto_point2_pwm. It can go from + 0 degree C to 124 degree C in steps of + 4 degree C. Read it out after writing to get + the actual value. +temp1_auto_point3_temp rw Above this temperature fan runs at maximum + speed. It can go from temp1_auto_point2_temp. + It can only have certain discrete values + which depend on temp1_auto_point2_temp and + pwm1_auto_point2_pwm. Read it out after + writing to get the actual value. + +temp2_auto_point1_temp rw Must be between 0 degree C and 63 degree C and + it defines the passive cooling temperature. + Below this temperature the fan stops in + the closed loop mode. +temp2_auto_point2_temp rw The low-temperature limit of the proportional + range. Below this temperature + pwm1 = pwm1_auto_point2_pwm. It can go from + 0 degree C to 124 degree C in steps + of 4 degree C. + +temp2_auto_point3_temp rw Above this temperature fan runs at maximum + speed. It can only have certain discrete + values which depend on temp2_auto_point2_temp + and pwm1_auto_point2_pwm. Read it out after + writing to get actual value. + + +Module parameters +----------------- + +If your board has a BIOS that initializes the amc6821 correctly, you should +load the module with: init=0. + +If your board BIOS doesn't initialize the chip, or you want +different settings, you can set the following parameters: +init=1, +pwminv: 0 default pwm output, 1 inverts pwm output. + diff --git a/Documentation/hwmon/coretemp b/Documentation/hwmon/coretemp index dbbe6c7025b0..92267b62db59 100644 --- a/Documentation/hwmon/coretemp +++ b/Documentation/hwmon/coretemp @@ -4,7 +4,9 @@ Kernel driver coretemp Supported chips: * All Intel Core family Prefix: 'coretemp' - CPUID: family 0x6, models 0xe, 0xf, 0x16, 0x17 + CPUID: family 0x6, models 0xe (Pentium M DC), 0xf (Core 2 DC 65nm), + 0x16 (Core 2 SC 65nm), 0x17 (Penryn 45nm), + 0x1a (Nehalem), 0x1c (Atom), 0x1e (Lynnfield) Datasheet: Intel 64 and IA-32 Architectures Software Developer's Manual Volume 3A: System Programming Guide http://softwarecommunity.intel.com/Wiki/Mobility/720.htm diff --git a/Documentation/hwmon/f71882fg b/Documentation/hwmon/f71882fg index bee4c30bc1e2..a7952c2bd959 100644 --- a/Documentation/hwmon/f71882fg +++ b/Documentation/hwmon/f71882fg @@ -14,6 +14,10 @@ Supported chips: Prefix: 'f71882fg' Addresses scanned: none, address read from Super I/O config space Datasheet: Available from the Fintek website + * Fintek F71889FG + Prefix: 'f71889fg' + 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 @@ -51,6 +55,12 @@ supported. The right one to use depends on external circuitry on the motherboard, so the driver assumes that the BIOS set the method properly. +Note that the lowest numbered temperature zone trip point corresponds to +to the border between the highest and one but highest temperature zones, and +vica versa. So the temperature zone trip points 1-4 (or 1-2) go from high temp +to low temp! This is how things are implemented in the IC, and the driver +mimicks this. + There are 2 modes to specify the speed of the fan, PWM duty cycle (or DC voltage) mode, where 0-100% duty cycle (0-100% of 12V) is specified. And RPM mode where the actual RPM of the fan (as measured) is controlled and the speed diff --git a/Documentation/hwmon/fscher b/Documentation/hwmon/fscher deleted file mode 100644 index 64031659aff3..000000000000 --- a/Documentation/hwmon/fscher +++ /dev/null @@ -1,169 +0,0 @@ -Kernel driver fscher -==================== - -Supported chips: - * Fujitsu-Siemens Hermes chip - Prefix: 'fscher' - Addresses scanned: I2C 0x73 - -Authors: - Reinhard Nissl <rnissl@gmx.de> based on work - from Hermann Jung <hej@odn.de>, - Frodo Looijaard <frodol@dds.nl>, - Philip Edelbrock <phil@netroedge.com> - -Description ------------ - -This driver implements support for the Fujitsu-Siemens Hermes chip. It is -described in the 'Register Set Specification BMC Hermes based Systemboard' -from Fujitsu-Siemens. - -The Hermes chip implements a hardware-based system management, e.g. for -controlling fan speed and core voltage. There is also a watchdog counter on -the chip which can trigger an alarm and even shut the system down. - -The chip provides three temperature values (CPU, motherboard and -auxiliary), three voltage values (+12V, +5V and battery) and three fans -(power supply, CPU and auxiliary). - -Temperatures are measured in degrees Celsius. The resolution is 1 degree. - -Fan rotation speeds are reported in RPM (rotations per minute). The value -can be divided by a programmable divider (1, 2 or 4) which is stored on -the chip. - -Voltage sensors (also known as "in" sensors) report their values in volts. - -All values are reported as final values from the driver. There is no need -for further calculations. - - -Detailed description --------------------- - -Below you'll find a single line description of all the bit values. With -this information, you're able to decode e. g. alarms, wdog, etc. To make -use of the watchdog, you'll need to set the watchdog time and enable the -watchdog. After that it is necessary to restart the watchdog time within -the specified period of time, or a system reset will occur. - -* revision - READING & 0xff = 0x??: HERMES revision identification - -* alarms - READING & 0x80 = 0x80: CPU throttling active - READING & 0x80 = 0x00: CPU running at full speed - - READING & 0x10 = 0x10: software event (see control:1) - READING & 0x10 = 0x00: no software event - - READING & 0x08 = 0x08: watchdog event (see wdog:2) - READING & 0x08 = 0x00: no watchdog event - - READING & 0x02 = 0x02: thermal event (see temp*:1) - READING & 0x02 = 0x00: no thermal event - - READING & 0x01 = 0x01: fan event (see fan*:1) - READING & 0x01 = 0x00: no fan event - - READING & 0x13 ! 0x00: ALERT LED is flashing - -* control - READING & 0x01 = 0x01: software event - READING & 0x01 = 0x00: no software event - - WRITING & 0x01 = 0x01: set software event - WRITING & 0x01 = 0x00: clear software event - -* watchdog_control - READING & 0x80 = 0x80: power off on watchdog event while thermal event - READING & 0x80 = 0x00: watchdog power off disabled (just system reset enabled) - - READING & 0x40 = 0x40: watchdog timebase 60 seconds (see also wdog:1) - READING & 0x40 = 0x00: watchdog timebase 2 seconds - - READING & 0x10 = 0x10: watchdog enabled - READING & 0x10 = 0x00: watchdog disabled - - WRITING & 0x80 = 0x80: enable "power off on watchdog event while thermal event" - WRITING & 0x80 = 0x00: disable "power off on watchdog event while thermal event" - - WRITING & 0x40 = 0x40: set watchdog timebase to 60 seconds - WRITING & 0x40 = 0x00: set watchdog timebase to 2 seconds - - WRITING & 0x20 = 0x20: disable watchdog - - WRITING & 0x10 = 0x10: enable watchdog / restart watchdog time - -* watchdog_state - READING & 0x02 = 0x02: watchdog system reset occurred - READING & 0x02 = 0x00: no watchdog system reset occurred - - WRITING & 0x02 = 0x02: clear watchdog event - -* watchdog_preset - READING & 0xff = 0x??: configured watch dog time in units (see wdog:3 0x40) - - WRITING & 0xff = 0x??: configure watch dog time in units - -* in* (0: +5V, 1: +12V, 2: onboard 3V battery) - READING: actual voltage value - -* temp*_status (1: CPU sensor, 2: onboard sensor, 3: auxiliary sensor) - READING & 0x02 = 0x02: thermal event (overtemperature) - READING & 0x02 = 0x00: no thermal event - - READING & 0x01 = 0x01: sensor is working - READING & 0x01 = 0x00: sensor is faulty - - WRITING & 0x02 = 0x02: clear thermal event - -* temp*_input (1: CPU sensor, 2: onboard sensor, 3: auxiliary sensor) - READING: actual temperature value - -* fan*_status (1: power supply fan, 2: CPU fan, 3: auxiliary fan) - READING & 0x04 = 0x04: fan event (fan fault) - READING & 0x04 = 0x00: no fan event - - WRITING & 0x04 = 0x04: clear fan event - -* fan*_div (1: power supply fan, 2: CPU fan, 3: auxiliary fan) - Divisors 2,4 and 8 are supported, both for reading and writing - -* fan*_pwm (1: power supply fan, 2: CPU fan, 3: auxiliary fan) - READING & 0xff = 0x00: fan may be switched off - READING & 0xff = 0x01: fan must run at least at minimum speed (supply: 6V) - READING & 0xff = 0xff: fan must run at maximum speed (supply: 12V) - READING & 0xff = 0x??: fan must run at least at given speed (supply: 6V..12V) - - WRITING & 0xff = 0x00: fan may be switched off - WRITING & 0xff = 0x01: fan must run at least at minimum speed (supply: 6V) - WRITING & 0xff = 0xff: fan must run at maximum speed (supply: 12V) - WRITING & 0xff = 0x??: fan must run at least at given speed (supply: 6V..12V) - -* fan*_input (1: power supply fan, 2: CPU fan, 3: auxiliary fan) - READING: actual RPM value - - -Limitations ------------ - -* Measuring fan speed -It seems that the chip counts "ripples" (typical fans produce 2 ripples per -rotation while VERAX fans produce 18) in a 9-bit register. This register is -read out every second, then the ripple prescaler (2, 4 or 8) is applied and -the result is stored in the 8 bit output register. Due to the limitation of -the counting register to 9 bits, it is impossible to measure a VERAX fan -properly (even with a prescaler of 8). At its maximum speed of 3500 RPM the -fan produces 1080 ripples per second which causes the counting register to -overflow twice, leading to only 186 RPM. - -* Measuring input voltages -in2 ("battery") reports the voltage of the onboard lithium battery and not -+3.3V from the power supply. - -* Undocumented features -Fujitsu-Siemens Computers has not documented all features of the chip so -far. Their software, System Guard, shows that there are a still some -features which cannot be controlled by this implementation. diff --git a/Documentation/hwmon/hpfall.c b/Documentation/hwmon/hpfall.c index bbea1ccfd46a..681ec22b9d0e 100644 --- a/Documentation/hwmon/hpfall.c +++ b/Documentation/hwmon/hpfall.c @@ -16,6 +16,34 @@ #include <stdint.h> #include <errno.h> #include <signal.h> +#include <sys/mman.h> +#include <sched.h> + +char unload_heads_path[64]; + +int set_unload_heads_path(char *device) +{ + char devname[64]; + + if (strlen(device) <= 5 || strncmp(device, "/dev/", 5) != 0) + return -EINVAL; + strncpy(devname, device + 5, sizeof(devname)); + + snprintf(unload_heads_path, sizeof(unload_heads_path), + "/sys/block/%s/device/unload_heads", devname); + return 0; +} +int valid_disk(void) +{ + int fd = open(unload_heads_path, O_RDONLY); + if (fd < 0) { + perror(unload_heads_path); + return 0; + } + + close(fd); + return 1; +} void write_int(char *path, int i) { @@ -40,7 +68,7 @@ void set_led(int on) void protect(int seconds) { - write_int("/sys/block/sda/device/unload_heads", seconds*1000); + write_int(unload_heads_path, seconds*1000); } int on_ac(void) @@ -57,45 +85,62 @@ void ignore_me(void) { protect(0); set_led(0); - } -int main(int argc, char* argv[]) +int main(int argc, char **argv) { - int fd, ret; + int fd, ret; + struct sched_param param; + + if (argc == 1) + ret = set_unload_heads_path("/dev/sda"); + else if (argc == 2) + ret = set_unload_heads_path(argv[1]); + else + ret = -EINVAL; + + if (ret || !valid_disk()) { + fprintf(stderr, "usage: %s <device> (default: /dev/sda)\n", + argv[0]); + exit(1); + } + + fd = open("/dev/freefall", O_RDONLY); + if (fd < 0) { + perror("/dev/freefall"); + return EXIT_FAILURE; + } - fd = open("/dev/freefall", O_RDONLY); - if (fd < 0) { - perror("open"); - return EXIT_FAILURE; - } + daemon(0, 0); + param.sched_priority = sched_get_priority_max(SCHED_FIFO); + sched_setscheduler(0, SCHED_FIFO, ¶m); + mlockall(MCL_CURRENT|MCL_FUTURE); signal(SIGALRM, ignore_me); - for (;;) { - unsigned char count; - - ret = read(fd, &count, sizeof(count)); - alarm(0); - if ((ret == -1) && (errno == EINTR)) { - /* Alarm expired, time to unpark the heads */ - continue; - } - - if (ret != sizeof(count)) { - perror("read"); - break; - } - - protect(21); - set_led(1); - if (1 || on_ac() || lid_open()) { - alarm(2); - } else { - alarm(20); - } - } - - close(fd); - return EXIT_SUCCESS; + for (;;) { + unsigned char count; + + ret = read(fd, &count, sizeof(count)); + alarm(0); + if ((ret == -1) && (errno == EINTR)) { + /* Alarm expired, time to unpark the heads */ + continue; + } + + if (ret != sizeof(count)) { + perror("read"); + break; + } + + protect(21); + set_led(1); + if (1 || on_ac() || lid_open()) + alarm(2); + else + alarm(20); + } + + close(fd); + return EXIT_SUCCESS; } diff --git a/Documentation/hwmon/it87 b/Documentation/hwmon/it87 index 659315d98e00..f9ba96c0ac4a 100644 --- a/Documentation/hwmon/it87 +++ b/Documentation/hwmon/it87 @@ -86,7 +86,6 @@ The IT8712F and IT8716F additionally feature VID inputs, used to report the Vcore voltage of the processor. The early IT8712F have 5 VID pins, the IT8716F and late IT8712F have 6. They are shared with other functions though, so the functionality may not be available on a given system. -The driver dumbly assume it is there. The IT8718F and IT8720F also features VID inputs (up to 8 pins) but the value is stored in the Super-I/O configuration space. Due to technical limitations, diff --git a/Documentation/hwmon/k10temp b/Documentation/hwmon/k10temp new file mode 100644 index 000000000000..6526eee525a6 --- /dev/null +++ b/Documentation/hwmon/k10temp @@ -0,0 +1,65 @@ +Kernel driver k10temp +===================== + +Supported chips: +* AMD Family 10h processors: + Socket F: Quad-Core/Six-Core/Embedded Opteron (but see below) + Socket AM2+: Quad-Core Opteron, Phenom (II) X3/X4, Athlon X2 (but see below) + Socket AM3: Quad-Core Opteron, Athlon/Phenom II X2/X3/X4, Sempron II + Socket S1G3: Athlon II, Sempron, Turion II +* AMD Family 11h processors: + Socket S1G2: Athlon (X2), Sempron (X2), Turion X2 (Ultra) + + Prefix: 'k10temp' + Addresses scanned: PCI space + Datasheets: + BIOS and Kernel Developer's Guide (BKDG) For AMD Family 10h Processors: + http://support.amd.com/us/Processor_TechDocs/31116.pdf + BIOS and Kernel Developer's Guide (BKDG) for AMD Family 11h Processors: + http://support.amd.com/us/Processor_TechDocs/41256.pdf + Revision Guide for AMD Family 10h Processors: + http://support.amd.com/us/Processor_TechDocs/41322.pdf + Revision Guide for AMD Family 11h Processors: + http://support.amd.com/us/Processor_TechDocs/41788.pdf + AMD Family 11h Processor Power and Thermal Data Sheet for Notebooks: + http://support.amd.com/us/Processor_TechDocs/43373.pdf + AMD Family 10h Server and Workstation Processor Power and Thermal Data Sheet: + http://support.amd.com/us/Processor_TechDocs/43374.pdf + AMD Family 10h Desktop Processor Power and Thermal Data Sheet: + http://support.amd.com/us/Processor_TechDocs/43375.pdf + +Author: Clemens Ladisch <clemens@ladisch.de> + +Description +----------- + +This driver permits reading of the internal temperature sensor of AMD +Family 10h and 11h processors. + +All these processors have a sensor, but on those for Socket F or AM2+, +the sensor may return inconsistent values (erratum 319). The driver +will refuse to load on these revisions unless you specify the "force=1" +module parameter. + +Due to technical reasons, the driver can detect only the mainboard's +socket type, not the processor's actual capabilities. Therefore, if you +are using an AM3 processor on an AM2+ mainboard, you can safely use the +"force=1" parameter. + +There is one temperature measurement value, available as temp1_input in +sysfs. It is measured in degrees Celsius with a resolution of 1/8th degree. +Please note that it is defined as a relative value; to quote the AMD manual: + + Tctl is the processor temperature control value, used by the platform to + control cooling systems. Tctl is a non-physical temperature on an + arbitrary scale measured in degrees. It does _not_ represent an actual + physical temperature like die or case temperature. Instead, it specifies + the processor temperature relative to the point at which the system must + supply the maximum cooling for the processor's specified maximum case + temperature and maximum thermal power dissipation. + +The maximum value for Tctl is available in the file temp1_max. + +If the BIOS has enabled hardware temperature control, the threshold at +which the processor will throttle itself to avoid damage is available in +temp1_crit and temp1_crit_hyst. diff --git a/Documentation/hwmon/lis3lv02d b/Documentation/hwmon/lis3lv02d index effe949a7282..06534f25e643 100644 --- a/Documentation/hwmon/lis3lv02d +++ b/Documentation/hwmon/lis3lv02d @@ -3,7 +3,8 @@ Kernel driver lis3lv02d Supported chips: - * STMicroelectronics LIS3LV02DL and LIS3LV02DQ + * STMicroelectronics LIS3LV02DL, LIS3LV02DQ (12 bits precision) + * STMicroelectronics LIS302DL, LIS3L02DQ, LIS331DL (8 bits) Authors: Yan Burman <burman.yan@gmail.com> @@ -13,32 +14,52 @@ Authors: Description ----------- -This driver provides support for the accelerometer found in various HP -laptops sporting the feature officially called "HP Mobile Data -Protection System 3D" or "HP 3D DriveGuard". It detects automatically -laptops with this sensor. Known models (for now the HP 2133, nc6420, -nc2510, nc8510, nc84x0, nw9440 and nx9420) will have their axis -automatically oriented on standard way (eg: you can directly play -neverball). The accelerometer data is readable via -/sys/devices/platform/lis3lv02d. +This driver provides support for the accelerometer found in various HP laptops +sporting the feature officially called "HP Mobile Data Protection System 3D" or +"HP 3D DriveGuard". It detects automatically laptops with this sensor. Known +models (full list can be found in drivers/hwmon/hp_accel.c) will have their +axis automatically oriented on standard way (eg: you can directly play +neverball). The accelerometer data is readable via +/sys/devices/platform/lis3lv02d. Reported values are scaled +to mg values (1/1000th of earth gravity). Sysfs attributes under /sys/devices/platform/lis3lv02d/: position - 3D position that the accelerometer reports. Format: "(x,y,z)" -calibrate - read: values (x, y, z) that are used as the base for input - class device operation. - write: forces the base to be recalibrated with the current - position. -rate - reports the sampling rate of the accelerometer device in HZ +rate - read reports the sampling rate of the accelerometer device in HZ. + write changes sampling rate of the accelerometer device. + Only values which are supported by HW are accepted. +selftest - performs selftest for the chip as specified by chip manufacturer. This driver also provides an absolute input class device, allowing -the laptop to act as a pinball machine-esque joystick. +the laptop to act as a pinball machine-esque joystick. Joystick device can be +calibrated. Joystick device can be in two different modes. +By default output values are scaled between -32768 .. 32767. In joystick raw +mode, joystick and sysfs position entry have the same scale. There can be +small difference due to input system fuzziness feature. +Events are also available as input event device. + +Selftest is meant only for hardware diagnostic purposes. It is not meant to be +used during normal operations. Position data is not corrupted during selftest +but interrupt behaviour is not guaranteed to work reliably. In test mode, the +sensing element is internally moved little bit. Selftest measures difference +between normal mode and test mode. Chip specifications tell the acceptance +limit for each type of the chip. Limits are provided via platform data +to allow adjustment of the limits without a change to the actual driver. +Seltest returns either "OK x y z" or "FAIL x y z" where x, y and z are +measured difference between modes. Axes are not remapped in selftest mode. +Measurement values are provided to help HW diagnostic applications to make +final decision. + +On HP laptops, if the led infrastructure is activated, support for a led +indicating disk protection will be provided as /sys/class/leds/hp::hddprotect. Another feature of the driver is misc device called "freefall" that acts similar to /dev/rtc and reacts on free-fall interrupts received from the device. It supports blocking operations, poll/select and fasync operation modes. You must read 1 bytes from the device. The result is number of free-fall interrupts since the last successful -read (or 255 if number of interrupts would not fit). +read (or 255 if number of interrupts would not fit). See the hpfall.c +file for an example on using the device. Axes orientation @@ -55,7 +76,7 @@ the accelerometer are converted into a "standard" organisation of the axes * If the laptop is put upside-down, Z becomes negative If your laptop model is not recognized (cf "dmesg"), you can send an -email to the authors to add it to the database. When reporting a new +email to the maintainer to add it to the database. When reporting a new laptop, please include the output of "dmidecode" plus the value of /sys/devices/platform/lis3lv02d/position in these four cases. diff --git a/Documentation/hwmon/ltc4215 b/Documentation/hwmon/ltc4215 index 2e6a21eb656c..c196a1846259 100644 --- a/Documentation/hwmon/ltc4215 +++ b/Documentation/hwmon/ltc4215 @@ -22,12 +22,13 @@ Usage Notes ----------- This driver does not probe for LTC4215 devices, due to the fact that some -of the possible addresses are unfriendly to probing. You will need to use -the "force" parameter to tell the driver where to find the device. +of the possible addresses are unfriendly to probing. You will have to +instantiate the devices explicitly. Example: the following will load the driver for an LTC4215 at address 0x44 on I2C bus #0: -$ modprobe ltc4215 force=0,0x44 +$ modprobe ltc4215 +$ echo ltc4215 0x44 > /sys/bus/i2c/devices/i2c-0/new_device Sysfs entries diff --git a/Documentation/hwmon/ltc4245 b/Documentation/hwmon/ltc4245 index bae7a3adc5d8..02838a47d862 100644 --- a/Documentation/hwmon/ltc4245 +++ b/Documentation/hwmon/ltc4245 @@ -23,12 +23,13 @@ Usage Notes ----------- This driver does not probe for LTC4245 devices, due to the fact that some -of the possible addresses are unfriendly to probing. You will need to use -the "force" parameter to tell the driver where to find the device. +of the possible addresses are unfriendly to probing. You will have to +instantiate the devices explicitly. Example: the following will load the driver for an LTC4245 at address 0x23 on I2C bus #1: -$ modprobe ltc4245 force=1,0x23 +$ modprobe ltc4245 +$ echo ltc4245 0x23 > /sys/bus/i2c/devices/i2c-1/new_device Sysfs entries diff --git a/Documentation/hwmon/mc13783-adc b/Documentation/hwmon/mc13783-adc new file mode 100644 index 000000000000..044531a86405 --- /dev/null +++ b/Documentation/hwmon/mc13783-adc @@ -0,0 +1,50 @@ +Kernel driver mc13783-adc +========================= + +Supported chips: + * Freescale Atlas MC13783 + Prefix: 'mc13783_adc' + Datasheet: http://www.freescale.com/files/rf_if/doc/data_sheet/MC13783.pdf?fsrch=1 + +Authors: + Sascha Hauer <s.hauer@pengutronix.de> + Luotao Fu <l.fu@pengutronix.de> + +Description +----------- + +The Freescale MC13783 is a Power Management and Audio Circuit. Among +other things it contains a 10-bit A/D converter. The converter has 16 +channels which can be used in different modes. +The A/D converter has a resolution of 2.25mV. Channels 0-4 have +a dedicated meaning with chip internal scaling applied. Channels 5-7 +can be used as general purpose inputs or alternatively in a dedicated +mode. Channels 12-15 are occupied by the touchscreen if it's active. + +Currently the driver only supports channels 2 and 5-15 with no alternative +modes for channels 5-7. + +See this table for the meaning of the different channels and their chip +internal scaling: + +Channel Signal Input Range Scaling +------------------------------------------------------------------------------- +0 Battery Voltage (BATT) 2.50 - 4.65V -2.40V +1 Battery Current (BATT - BATTISNS) -50 - 50 mV x20 +2 Application Supply (BP) 2.50 - 4.65V -2.40V +3 Charger Voltage (CHRGRAW) 0 - 10V / /5 + 0 - 20V /10 +4 Charger Current (CHRGISNSP-CHRGISNSN) -0.25V - 0.25V x4 +5 General Purpose ADIN5 / Battery Pack Thermistor 0 - 2.30V No +6 General Purpose ADIN6 / Backup Voltage (LICELL) 0 - 2.30V / No / + 1.50 - 3.50V -1.20V +7 General Purpose ADIN7 / UID / Die Temperature 0 - 2.30V / No / + 0 - 2.55V / x0.9 / No +8 General Purpose ADIN8 0 - 2.30V No +9 General Purpose ADIN9 0 - 2.30V No +10 General Purpose ADIN10 0 - 2.30V No +11 General Purpose ADIN11 0 - 2.30V No +12 General Purpose TSX1 / Touchscreen X-plate 1 0 - 2.30V No +13 General Purpose TSX2 / Touchscreen X-plate 2 0 - 2.30V No +14 General Purpose TSY1 / Touchscreen Y-plate 1 0 - 2.30V No +15 General Purpose TSY2 / Touchscreen Y-plate 2 0 - 2.30V No diff --git a/Documentation/hwmon/pc87427 b/Documentation/hwmon/pc87427 index d1ebbe510f35..db5cc1227a83 100644 --- a/Documentation/hwmon/pc87427 +++ b/Documentation/hwmon/pc87427 @@ -34,5 +34,5 @@ Fan rotation speeds are reported as 14-bit values from a gated clock signal. Speeds down to 83 RPM can be measured. An alarm is triggered if the rotation speed drops below a programmable -limit. Another alarm is triggered if the speed is too low to to be measured +limit. Another alarm is triggered if the speed is too low to be measured (including stalled or missing fan). diff --git a/Documentation/hwmon/pcf8591 b/Documentation/hwmon/pcf8591 index 5628fcf4207f..e76a7892f68e 100644 --- a/Documentation/hwmon/pcf8591 +++ b/Documentation/hwmon/pcf8591 @@ -2,11 +2,11 @@ Kernel driver pcf8591 ===================== Supported chips: - * Philips PCF8591 + * Philips/NXP PCF8591 Prefix: 'pcf8591' Addresses scanned: I2C 0x48 - 0x4f - Datasheet: Publicly available at the Philips Semiconductor website - http://www.semiconductors.philips.com/pip/PCF8591P.html + Datasheet: Publicly available at the NXP website + http://www.nxp.com/pip/PCF8591_6.html Authors: Aurelien Jarno <aurelien@aurel32.net> @@ -16,9 +16,10 @@ Authors: Description ----------- + The PCF8591 is an 8-bit A/D and D/A converter (4 analog inputs and one -analog output) for the I2C bus produced by Philips Semiconductors. It -is designed to provide a byte I2C interface to up to 4 separate devices. +analog output) for the I2C bus produced by Philips Semiconductors (now NXP). +It is designed to provide a byte I2C interface to up to 4 separate devices. The PCF8591 has 4 analog inputs programmable as single-ended or differential inputs : @@ -58,8 +59,8 @@ Accessing PCF8591 via /sys interface ------------------------------------- ! Be careful ! -The PCF8591 is plainly impossible to detect ! Stupid chip. -So every chip with address in the interval [48..4f] is +The PCF8591 is plainly impossible to detect! Stupid chip. +So every chip with address in the interval [0x48..0x4f] is detected as PCF8591. If you have other chips in this address range, the workaround is to load this module after the one for your others chips. @@ -67,19 +68,20 @@ for your others chips. On detection (i.e. insmod, modprobe et al.), directories are being created for each detected PCF8591: -/sys/bus/devices/<0>-<1>/ +/sys/bus/i2c/devices/<0>-<1>/ where <0> is the bus the chip was detected on (e. g. i2c-0) and <1> the chip address ([48..4f]) Inside these directories, there are such files: -in0, in1, in2, in3, out0_enable, out0_output, name +in0_input, in1_input, in2_input, in3_input, out0_enable, out0_output, name Name contains chip name. -The in0, in1, in2 and in3 files are RO. Reading gives the value of the -corresponding channel. Depending on the current analog inputs configuration, -files in2 and/or in3 do not exist. Values range are from 0 to 255 for single -ended inputs and -128 to +127 for differential inputs (8-bit ADC). +The in0_input, in1_input, in2_input and in3_input files are RO. Reading gives +the value of the corresponding channel. Depending on the current analog inputs +configuration, files in2_input and in3_input may not exist. Values range +from 0 to 255 for single ended inputs and -128 to +127 for differential inputs +(8-bit ADC). The out0_enable file is RW. Reading gives "1" for analog output enabled and "0" for analog output disabled. Writing accepts "0" and "1" accordingly. diff --git a/Documentation/hwmon/sysfs-interface b/Documentation/hwmon/sysfs-interface index dcbd502c8792..3de6b0bcb147 100644 --- a/Documentation/hwmon/sysfs-interface +++ b/Documentation/hwmon/sysfs-interface @@ -225,8 +225,6 @@ pwm[1-*]_auto_point[1-*]_temp_hyst to PWM output channels. RW -OR - temp[1-*]_auto_point[1-*]_pwm temp[1-*]_auto_point[1-*]_temp temp[1-*]_auto_point[1-*]_temp_hyst @@ -235,6 +233,15 @@ temp[1-*]_auto_point[1-*]_temp_hyst to temperature channels. RW +There is a third case where trip points are associated to both PWM output +channels and temperature channels: the PWM values are associated to PWM +output channels while the temperature values are associated to temperature +channels. In that case, the result is determined by the mapping between +temperature inputs and PWM outputs. When several temperature inputs are +mapped to a given PWM output, this leads to several candidate PWM values. +The actual result is up to the chip, but in general the highest candidate +value (fastest fan speed) wins. + **************** * Temperatures * @@ -353,10 +360,20 @@ power[1-*]_average Average power use Unit: microWatt RO -power[1-*]_average_interval Power use averaging interval +power[1-*]_average_interval Power use averaging interval. A poll + notification is sent to this file if the + hardware changes the averaging interval. Unit: milliseconds RW +power[1-*]_average_interval_max Maximum power use averaging interval + Unit: milliseconds + RO + +power[1-*]_average_interval_min Minimum power use averaging interval + Unit: milliseconds + RO + power[1-*]_average_highest Historical average maximum power use Unit: microWatt RO @@ -365,6 +382,18 @@ power[1-*]_average_lowest Historical average minimum power use Unit: microWatt RO +power[1-*]_average_max A poll notification is sent to + power[1-*]_average when power use + rises above this value. + Unit: microWatt + RW + +power[1-*]_average_min A poll notification is sent to + power[1-*]_average when power use + sinks below this value. + Unit: microWatt + RW + power[1-*]_input Instantaneous power use Unit: microWatt RO @@ -381,6 +410,39 @@ power[1-*]_reset_history Reset input_highest, input_lowest, average_highest and average_lowest. WO +power[1-*]_accuracy Accuracy of the power meter. + Unit: Percent + RO + +power[1-*]_alarm 1 if the system is drawing more power than the + cap allows; 0 otherwise. A poll notification is + sent to this file when the power use exceeds the + cap. This file only appears if the cap is known + to be enforced by hardware. + RO + +power[1-*]_cap If power use rises above this limit, the + system should take action to reduce power use. + A poll notification is sent to this file if the + cap is changed by the hardware. The *_cap + files only appear if the cap is known to be + enforced by hardware. + Unit: microWatt + RW + +power[1-*]_cap_hyst Margin of hysteresis built around capping and + notification. + Unit: microWatt + RW + +power[1-*]_cap_max Maximum cap that can be set. + Unit: microWatt + RO + +power[1-*]_cap_min Minimum cap that can be set. + Unit: microWatt + RO + ********** * Energy * ********** diff --git a/Documentation/hwmon/tmp421 b/Documentation/hwmon/tmp421 new file mode 100644 index 000000000000..0cf07f824741 --- /dev/null +++ b/Documentation/hwmon/tmp421 @@ -0,0 +1,36 @@ +Kernel driver tmp421 +==================== + +Supported chips: + * Texas Instruments TMP421 + Prefix: 'tmp421' + Addresses scanned: I2C 0x2a, 0x4c, 0x4d, 0x4e and 0x4f + Datasheet: http://focus.ti.com/docs/prod/folders/print/tmp421.html + * Texas Instruments TMP422 + Prefix: 'tmp422' + Addresses scanned: I2C 0x2a, 0x4c, 0x4d, 0x4e and 0x4f + Datasheet: http://focus.ti.com/docs/prod/folders/print/tmp421.html + * Texas Instruments TMP423 + Prefix: 'tmp423' + Addresses scanned: I2C 0x2a, 0x4c, 0x4d, 0x4e and 0x4f + Datasheet: http://focus.ti.com/docs/prod/folders/print/tmp421.html + +Authors: + Andre Prendel <andre.prendel@gmx.de> + +Description +----------- + +This driver implements support for Texas Instruments TMP421, TMP422 +and TMP423 temperature sensor chips. These chips implement one local +and up to one (TMP421), up to two (TMP422) or up to three (TMP423) +remote sensors. Temperature is measured in degrees Celsius. The chips +are wired over I2C/SMBus and specified over a temperature range of -40 +to +125 degrees Celsius. Resolution for both the local and remote +channels is 0.0625 degree C. + +The chips support only temperature measurement. The driver exports +the temperature values via the following sysfs files: + +temp[1-4]_input +temp[2-4]_fault diff --git a/Documentation/hwmon/w83627ehf b/Documentation/hwmon/w83627ehf index 02b74899edaf..b7e42ec4b26b 100644 --- a/Documentation/hwmon/w83627ehf +++ b/Documentation/hwmon/w83627ehf @@ -81,8 +81,14 @@ pwm[1-4] - this file stores PWM duty cycle or DC value (fan speed) in range: 0 (stop) to 255 (full) pwm[1-4]_enable - this file controls mode of fan/temperature control: - * 1 Manual Mode, write to pwm file any value 0-255 (full speed) - * 2 Thermal Cruise + * 1 Manual mode, write to pwm file any value 0-255 (full speed) + * 2 "Thermal Cruise" mode + * 3 "Fan Speed Cruise" mode + * 4 "Smart Fan III" mode + +pwm[1-4]_mode - controls if output is PWM or DC level + * 0 DC output (0 - 12v) + * 1 PWM output Thermal Cruise mode ------------------- diff --git a/Documentation/hwmon/w83627hf b/Documentation/hwmon/w83627hf index 6ee36dbafd64..44dd2bcc72bd 100644 --- a/Documentation/hwmon/w83627hf +++ b/Documentation/hwmon/w83627hf @@ -32,8 +32,6 @@ Authors: Module Parameters ----------------- -* force_addr: int - Initialize the ISA address of the sensors * force_i2c: int Initialize the I2C address of the sensors * init: int @@ -70,3 +68,30 @@ doesn't help, you may just ignore the bogus VID reading with no harm done. For further information on this driver see the w83781d driver documentation. [1] http://www.lm-sensors.org/browser/lm-sensors/trunk/doc/vid + +Forcing the address +------------------- + +The driver used to have a module parameter named force_addr, which could +be used to force the base I/O address of the hardware monitoring block. +This was meant as a workaround for mainboards with a broken BIOS. This +module parameter is gone for technical reasons. If you need this feature, +you can obtain the same result by using the isaset tool (part of +lm-sensors) before loading the driver: + +# Enter the Super I/O config space +isaset -y -f 0x2e 0x87 +isaset -y -f 0x2e 0x87 + +# Select the hwmon logical device +isaset -y 0x2e 0x2f 0x07 0x0b + +# Set the base I/O address (to 0x290 in this example) +isaset -y 0x2e 0x2f 0x60 0x02 +isaset -y 0x2e 0x2f 0x61 0x90 + +# Exit the Super-I/O config space +isaset -y -f 0x2e 0xaa + +The above sequence assumes a Super-I/O config space at 0x2e/0x2f, but +0x4e/0x4f is also possible. diff --git a/Documentation/hwmon/wm831x b/Documentation/hwmon/wm831x new file mode 100644 index 000000000000..24f47d8f6a42 --- /dev/null +++ b/Documentation/hwmon/wm831x @@ -0,0 +1,37 @@ +Kernel driver wm831x-hwmon +========================== + +Supported chips: + * Wolfson Microelectronics WM831x PMICs + Prefix: 'wm831x' + Datasheet: + http://www.wolfsonmicro.com/products/WM8310 + http://www.wolfsonmicro.com/products/WM8311 + http://www.wolfsonmicro.com/products/WM8312 + +Authors: Mark Brown <broonie@opensource.wolfsonmicro.com> + +Description +----------- + +The WM831x series of PMICs include an AUXADC which can be used to +monitor a range of system operating parameters, including the voltages +of the major supplies within the system. Currently the driver provides +reporting of all the input values but does not provide any alarms. + +Voltage Monitoring +------------------ + +Voltages are sampled by a 12 bit ADC. Voltages in milivolts are 1.465 +times the ADC value. + +Temperature Monitoring +---------------------- + +Temperatures are sampled by a 12 bit ADC. Chip and battery temperatures +are available. The chip temperature is calculated as: + + Degrees celsius = (512.18 - data) / 1.0983 + +while the battery temperature calculation will depend on the NTC +thermistor component. diff --git a/Documentation/hwmon/wm8350 b/Documentation/hwmon/wm8350 new file mode 100644 index 000000000000..98f923bd2e92 --- /dev/null +++ b/Documentation/hwmon/wm8350 @@ -0,0 +1,26 @@ +Kernel driver wm8350-hwmon +========================== + +Supported chips: + * Wolfson Microelectronics WM835x PMICs + Prefix: 'wm8350' + Datasheet: + http://www.wolfsonmicro.com/products/WM8350 + http://www.wolfsonmicro.com/products/WM8351 + http://www.wolfsonmicro.com/products/WM8352 + +Authors: Mark Brown <broonie@opensource.wolfsonmicro.com> + +Description +----------- + +The WM835x series of PMICs include an AUXADC which can be used to +monitor a range of system operating parameters, including the voltages +of the major supplies within the system. Currently the driver provides +simple access to these major supplies. + +Voltage Monitoring +------------------ + +Voltages are sampled by a 12 bit ADC. For the internal supplies the ADC +is referenced to the system VRTC. diff --git a/Documentation/i2c/busses/i2c-piix4 b/Documentation/i2c/busses/i2c-piix4 index f889481762b5..ac540c71c7eb 100644 --- a/Documentation/i2c/busses/i2c-piix4 +++ b/Documentation/i2c/busses/i2c-piix4 @@ -8,6 +8,8 @@ Supported adapters: Datasheet: Only available via NDA from ServerWorks * ATI IXP200, IXP300, IXP400, SB600, SB700 and SB800 southbridges Datasheet: Not publicly available + * AMD Hudson-2 + Datasheet: Not publicly available * Standard Microsystems (SMSC) SLC90E66 (Victory66) southbridge Datasheet: Publicly available at the SMSC website http://www.smsc.com diff --git a/Documentation/i2c/busses/i2c-voodoo3 b/Documentation/i2c/busses/i2c-voodoo3 deleted file mode 100644 index 62d90a454d39..000000000000 --- a/Documentation/i2c/busses/i2c-voodoo3 +++ /dev/null @@ -1,62 +0,0 @@ -Kernel driver i2c-voodoo3 - -Supported adapters: - * 3dfx Voodoo3 based cards - * Voodoo Banshee based cards - -Authors: - Frodo Looijaard <frodol@dds.nl>, - Philip Edelbrock <phil@netroedge.com>, - Ralph Metzler <rjkm@thp.uni-koeln.de>, - Mark D. Studebaker <mdsxyz123@yahoo.com> - -Main contact: Philip Edelbrock <phil@netroedge.com> - -The code is based upon Ralph's test code (he did the hard stuff ;') - -Description ------------ - -The 3dfx Voodoo3 chip contains two I2C interfaces (aka a I2C 'master' or -'host'). - -The first interface is used for DDC (Data Display Channel) which is a -serial channel through the VGA monitor connector to a DDC-compliant -monitor. This interface is defined by the Video Electronics Standards -Association (VESA). The standards are available for purchase at -http://www.vesa.org . - -The second interface is a general-purpose I2C bus. The intent by 3dfx was -to allow manufacturers to add extra chips to the video card such as a -TV-out chip such as the BT869 or possibly even I2C based temperature -sensors like the ADM1021 or LM75. - -Stability ---------- - -Seems to be stable on the test machine, but needs more testing on other -machines. Simultaneous accesses of the DDC and I2C busses may cause errors. - -Supported Devices ------------------ - -Specifically, this driver was written and tested on the '3dfx Voodoo3 AGP -3000' which has a tv-out feature (s-video or composite). According to the -docs and discussions, this code should work for any Voodoo3 based cards as -well as Voodoo Banshee based cards. The DDC interface has been tested on a -Voodoo Banshee card. - -Issues ------- - -Probably many, but it seems to work OK on my system. :') - - -External Device Connection --------------------------- - -The digital video input jumpers give availability to the I2C bus. -Specifically, pins 13 and 25 (bottom row middle, and bottom right-end) are -the I2C clock and I2C data lines, respectively. +5V and GND are probably -also easily available making the addition of extra I2C/SMBus devices easy -to implement. diff --git a/Documentation/i2c/chips/pca9539 b/Documentation/i2c/chips/pca9539 deleted file mode 100644 index 6aff890088b1..000000000000 --- a/Documentation/i2c/chips/pca9539 +++ /dev/null @@ -1,58 +0,0 @@ -Kernel driver pca9539 -===================== - -NOTE: this driver is deprecated and will be dropped soon, use -drivers/gpio/pca9539.c instead. - -Supported chips: - * Philips PCA9539 - Prefix: 'pca9539' - Addresses scanned: none - Datasheet: - http://www.semiconductors.philips.com/acrobat/datasheets/PCA9539_2.pdf - -Author: Ben Gardner <bgardner@wabtec.com> - - -Description ------------ - -The Philips PCA9539 is a 16 bit low power I/O device. -All 16 lines can be individually configured as an input or output. -The input sense can also be inverted. -The 16 lines are split between two bytes. - - -Detection ---------- - -The PCA9539 is difficult to detect and not commonly found in PC machines, -so you have to pass the I2C bus and address of the installed PCA9539 -devices explicitly to the driver at load time via the force=... parameter. - - -Sysfs entries -------------- - -Each is a byte that maps to the 8 I/O bits. -A '0' suffix is for bits 0-7, while '1' is for bits 8-15. - -input[01] - read the current value -output[01] - sets the output value -direction[01] - direction of each bit: 1=input, 0=output -invert[01] - toggle the input bit sense - -input reads the actual state of the line and is always available. -The direction defaults to input for all channels. - - -General Remarks ---------------- - -Note that each output, direction, and invert entry controls 8 lines. -You should use the read, modify, write sequence. -For example. to set output bit 0 of 1. - val=$(cat output0) - val=$(( $val | 1 )) - echo $val > output0 - diff --git a/Documentation/i2c/chips/pcf8574 b/Documentation/i2c/chips/pcf8574 deleted file mode 100644 index 235815c075ff..000000000000 --- a/Documentation/i2c/chips/pcf8574 +++ /dev/null @@ -1,65 +0,0 @@ -Kernel driver pcf8574 -===================== - -Supported chips: - * Philips PCF8574 - Prefix: 'pcf8574' - Addresses scanned: none - Datasheet: Publicly available at the Philips Semiconductors website - http://www.semiconductors.philips.com/pip/PCF8574P.html - - * Philips PCF8574A - Prefix: 'pcf8574a' - Addresses scanned: none - Datasheet: Publicly available at the Philips Semiconductors website - http://www.semiconductors.philips.com/pip/PCF8574P.html - -Authors: - Frodo Looijaard <frodol@dds.nl>, - Philip Edelbrock <phil@netroedge.com>, - Dan Eaton <dan.eaton@rocketlogix.com>, - Aurelien Jarno <aurelien@aurel32.net>, - Jean Delvare <khali@linux-fr.org>, - - -Description ------------ -The PCF8574(A) is an 8-bit I/O expander for the I2C bus produced by Philips -Semiconductors. It is designed to provide a byte I2C interface to up to 16 -separate devices (8 x PCF8574 and 8 x PCF8574A). - -This device consists of a quasi-bidirectional port. Each of the eight I/Os -can be independently used as an input or output. To setup an I/O as an -input, you have to write a 1 to the corresponding output. - -For more informations see the datasheet. - - -Accessing PCF8574(A) via /sys interface -------------------------------------- - -The PCF8574(A) is plainly impossible to detect ! Stupid chip. -So, you have to pass the I2C bus and address of the installed PCF857A -and PCF8574A devices explicitly to the driver at load time via the -force=... parameter. - -On detection (i.e. insmod, modprobe et al.), directories are being -created for each detected PCF8574(A): - -/sys/bus/i2c/devices/<0>-<1>/ -where <0> is the bus the chip was detected on (e. g. i2c-0) -and <1> the chip address ([20..27] or [38..3f]): - -(example: /sys/bus/i2c/devices/1-0020/) - -Inside these directories, there are two files each: -read and write (and one file with chip name). - -The read file is read-only. Reading gives you the current I/O input -if the corresponding output is set as 1, otherwise the current output -value, that is to say 0. - -The write file is read/write. Writing a value outputs it on the I/O -port. Reading returns the last written value. As it is not possible -to read this value from the chip, you need to write at least once to -this file before you can read back from it. diff --git a/Documentation/i2c/chips/pcf8575 b/Documentation/i2c/chips/pcf8575 deleted file mode 100644 index 40b268eb276f..000000000000 --- a/Documentation/i2c/chips/pcf8575 +++ /dev/null @@ -1,69 +0,0 @@ -About the PCF8575 chip and the pcf8575 kernel driver -==================================================== - -The PCF8575 chip is produced by the following manufacturers: - - * Philips NXP - http://www.nxp.com/#/pip/cb=[type=product,path=50807/41735/41850,final=PCF8575_3]|pip=[pip=PCF8575_3][0] - - * Texas Instruments - http://focus.ti.com/docs/prod/folders/print/pcf8575.html - - -Some vendors sell small PCB's with the PCF8575 mounted on it. You can connect -such a board to a Linux host via e.g. an USB to I2C interface. Examples of -PCB boards with a PCF8575: - - * SFE Breakout Board for PCF8575 I2C Expander by RobotShop - http://www.robotshop.ca/home/products/robot-parts/electronics/adapters-converters/sfe-pcf8575-i2c-expander-board.html - - * Breakout Board for PCF8575 I2C Expander by Spark Fun Electronics - http://www.sparkfun.com/commerce/product_info.php?products_id=8130 - - -Description ------------ -The PCF8575 chip is a 16-bit I/O expander for the I2C bus. Up to eight of -these chips can be connected to the same I2C bus. You can find this -chip on some custom designed hardware, but you won't find it on PC -motherboards. - -The PCF8575 chip consists of a 16-bit quasi-bidirectional port and an I2C-bus -interface. Each of the sixteen I/O's can be independently used as an input or -an output. To set up an I/O pin as an input, you have to write a 1 to the -corresponding output. - -For more information please see the datasheet. - - -Detection ---------- - -There is no method known to detect whether a chip on a given I2C address is -a PCF8575 or whether it is any other I2C device, so you have to pass the I2C -bus and address of the installed PCF8575 devices explicitly to the driver at -load time via the force=... parameter. - -/sys interface --------------- - -For each address on which a PCF8575 chip was found or forced the following -files will be created under /sys: -* /sys/bus/i2c/devices/<bus>-<address>/read -* /sys/bus/i2c/devices/<bus>-<address>/write -where bus is the I2C bus number (0, 1, ...) and address is the four-digit -hexadecimal representation of the 7-bit I2C address of the PCF8575 -(0020 .. 0027). - -The read file is read-only. Reading it will trigger an I2C read and will hence -report the current input state for the pins configured as inputs, and the -current output value for the pins configured as outputs. - -The write file is read-write. Writing a value to it will configure all pins -as output for which the corresponding bit is zero. Reading the write file will -return the value last written, or -EAGAIN if no value has yet been written to -the write file. - -On module initialization the configuration of the chip is not changed -- the -chip is left in the state it was already configured in through either power-up -or through previous I2C write actions. diff --git a/Documentation/i2c/i2c-stub b/Documentation/i2c/i2c-stub index 0d8be1c20c16..fa4b669c166b 100644 --- a/Documentation/i2c/i2c-stub +++ b/Documentation/i2c/i2c-stub @@ -2,9 +2,9 @@ MODULE: i2c-stub DESCRIPTION: -This module is a very simple fake I2C/SMBus driver. It implements four -types of SMBus commands: write quick, (r/w) byte, (r/w) byte data, and -(r/w) word data. +This module is a very simple fake I2C/SMBus driver. It implements five +types of SMBus commands: write quick, (r/w) byte, (r/w) byte data, (r/w) +word data, and (r/w) I2C block data. You need to provide chip addresses as a module parameter when loading this driver, which will then only react to SMBus commands to these addresses. @@ -21,8 +21,8 @@ EEPROMs, among others. The typical use-case is like this: 1. load this module - 2. use i2cset (from lm_sensors project) to pre-load some data - 3. load the target sensors chip driver module + 2. use i2cset (from the i2c-tools project) to pre-load some data + 3. load the target chip driver module 4. observe its behavior in the kernel log There's a script named i2c-stub-from-dump in the i2c-tools package which @@ -33,6 +33,12 @@ PARAMETERS: int chip_addr[10]: The SMBus addresses to emulate chips at. +unsigned long functionality: + Functionality override, to disable some commands. See I2C_FUNC_* + constants in <linux/i2c.h> for the suitable values. For example, + value 0x1f0000 would only enable the quick, byte and byte data + commands. + CAVEATS: If your target driver polls some byte or word waiting for it to change, the diff --git a/Documentation/i2c/instantiating-devices b/Documentation/i2c/instantiating-devices index c740b7b41088..e89490270aba 100644 --- a/Documentation/i2c/instantiating-devices +++ b/Documentation/i2c/instantiating-devices @@ -188,7 +188,7 @@ segment, the address is sufficient to uniquely identify the device to be deleted. Example: -# echo eeprom 0x50 > /sys/class/i2c-adapter/i2c-3/new_device +# echo eeprom 0x50 > /sys/bus/i2c/devices/i2c-3/new_device While this interface should only be used when in-kernel device declaration can't be done, there is a variety of cases where it can be helpful: diff --git a/Documentation/i2c/old-module-parameters b/Documentation/i2c/old-module-parameters new file mode 100644 index 000000000000..8e2b629d533c --- /dev/null +++ b/Documentation/i2c/old-module-parameters @@ -0,0 +1,44 @@ +I2C device driver binding control from user-space +================================================= + +Up to kernel 2.6.32, many i2c drivers used helper macros provided by +<linux/i2c.h> which created standard module parameters to let the user +control how the driver would probe i2c buses and attach to devices. These +parameters were known as "probe" (to let the driver probe for an extra +address), "force" (to forcibly attach the driver to a given device) and +"ignore" (to prevent a driver from probing a given address). + +With the conversion of the i2c subsystem to the standard device driver +binding model, it became clear that these per-module parameters were no +longer needed, and that a centralized implementation was possible. The new, +sysfs-based interface is described in the documentation file +"instantiating-devices", section "Method 4: Instantiate from user-space". + +Below is a mapping from the old module parameters to the new interface. + +Attaching a driver to an I2C device +----------------------------------- + +Old method (module parameters): +# modprobe <driver> probe=1,0x2d +# modprobe <driver> force=1,0x2d +# modprobe <driver> force_<device>=1,0x2d + +New method (sysfs interface): +# echo <device> 0x2d > /sys/bus/i2c/devices/i2c-1/new_device + +Preventing a driver from attaching to an I2C device +--------------------------------------------------- + +Old method (module parameters): +# modprobe <driver> ignore=1,0x2f + +New method (sysfs interface): +# echo dummy 0x2f > /sys/bus/i2c/devices/i2c-1/new_device +# modprobe <driver> + +Of course, it is important to instantiate the "dummy" device before loading +the driver. The dummy device will be handled by i2c-core itself, preventing +other drivers from binding to it later on. If there is a real device at the +problematic address, and you want another driver to bind to it, then simply +pass the name of the device in question instead of "dummy". diff --git a/Documentation/i2c/writing-clients b/Documentation/i2c/writing-clients index 7860aafb483d..0a74603eb671 100644 --- a/Documentation/i2c/writing-clients +++ b/Documentation/i2c/writing-clients @@ -44,7 +44,7 @@ static struct i2c_driver foo_driver = { /* if device autodetection is needed: */ .class = I2C_CLASS_SOMETHING, .detect = foo_detect, - .address_data = &addr_data, + .address_list = normal_i2c, .shutdown = foo_shutdown, /* optional */ .suspend = foo_suspend, /* optional */ diff --git a/Documentation/ia64/aliasing-test.c b/Documentation/ia64/aliasing-test.c index d23610fb2ff9..3dfb76ca6931 100644 --- a/Documentation/ia64/aliasing-test.c +++ b/Documentation/ia64/aliasing-test.c @@ -24,7 +24,7 @@ int sum; -int map_mem(char *path, off_t offset, size_t length, int touch) +static int map_mem(char *path, off_t offset, size_t length, int touch) { int fd, rc; void *addr; @@ -62,7 +62,7 @@ int map_mem(char *path, off_t offset, size_t length, int touch) return 0; } -int scan_tree(char *path, char *file, off_t offset, size_t length, int touch) +static int scan_tree(char *path, char *file, off_t offset, size_t length, int touch) { struct dirent **namelist; char *name, *path2; @@ -119,7 +119,7 @@ skip: char buf[1024]; -int read_rom(char *path) +static int read_rom(char *path) { int fd, rc; size_t size = 0; @@ -146,7 +146,7 @@ int read_rom(char *path) return size; } -int scan_rom(char *path, char *file) +static int scan_rom(char *path, char *file) { struct dirent **namelist; char *name, *path2; diff --git a/Documentation/infiniband/ipoib.txt b/Documentation/infiniband/ipoib.txt index 6d40f00b358c..64eeb55d0c09 100644 --- a/Documentation/infiniband/ipoib.txt +++ b/Documentation/infiniband/ipoib.txt @@ -36,11 +36,11 @@ Datagram vs Connected modes fabric with a 2K MTU, the IPoIB MTU will be 2048 - 4 = 2044 bytes. In connected mode, the IB RC (Reliable Connected) transport is used. - Connected mode is to takes advantage of the connected nature of the - IB transport and allows an MTU up to the maximal IP packet size of - 64K, which reduces the number of IP packets needed for handling - large UDP datagrams, TCP segments, etc and increases the performance - for large messages. + Connected mode takes advantage of the connected nature of the IB + transport and allows an MTU up to the maximal IP packet size of 64K, + which reduces the number of IP packets needed for handling large UDP + datagrams, TCP segments, etc and increases the performance for large + messages. In connected mode, the interface's UD QP is still used for multicast and communication with peers that don't support connected mode. In diff --git a/Documentation/infiniband/user_mad.txt b/Documentation/infiniband/user_mad.txt index 744687dd195b..8a366959f5cc 100644 --- a/Documentation/infiniband/user_mad.txt +++ b/Documentation/infiniband/user_mad.txt @@ -128,8 +128,8 @@ Setting IsSM Capability Bit To create the appropriate character device files automatically with udev, a rule like - KERNEL="umad*", NAME="infiniband/%k" - KERNEL="issm*", NAME="infiniband/%k" + KERNEL=="umad*", NAME="infiniband/%k" + KERNEL=="issm*", NAME="infiniband/%k" can be used. This will create device nodes named diff --git a/Documentation/infiniband/user_verbs.txt b/Documentation/infiniband/user_verbs.txt index f847501e50b5..afe3f8da9018 100644 --- a/Documentation/infiniband/user_verbs.txt +++ b/Documentation/infiniband/user_verbs.txt @@ -58,7 +58,7 @@ Memory pinning To create the appropriate character device files automatically with udev, a rule like - KERNEL="uverbs*", NAME="infiniband/%k" + KERNEL=="uverbs*", NAME="infiniband/%k" can be used. This will create device nodes named diff --git a/Documentation/input/multi-touch-protocol.txt b/Documentation/input/multi-touch-protocol.txt index a12ea3b586e6..8490480ce432 100644 --- a/Documentation/input/multi-touch-protocol.txt +++ b/Documentation/input/multi-touch-protocol.txt @@ -27,12 +27,30 @@ set of events/packets. A set of ABS_MT events with the desired properties is defined. The events are divided into categories, to allow for partial implementation. The -minimum set consists of ABS_MT_TOUCH_MAJOR, ABS_MT_POSITION_X and -ABS_MT_POSITION_Y, which allows for multiple fingers to be tracked. If the -device supports it, the ABS_MT_WIDTH_MAJOR may be used to provide the size -of the approaching finger. Anisotropy and direction may be specified with -ABS_MT_TOUCH_MINOR, ABS_MT_WIDTH_MINOR and ABS_MT_ORIENTATION. The -ABS_MT_TOOL_TYPE may be used to specify whether the touching tool is a +minimum set consists of ABS_MT_POSITION_X and ABS_MT_POSITION_Y, which +allows for multiple fingers to be tracked. If the device supports it, the +ABS_MT_TOUCH_MAJOR and ABS_MT_WIDTH_MAJOR may be used to provide the size +of the contact area and approaching finger, respectively. + +The TOUCH and WIDTH parameters have a geometrical interpretation; imagine +looking through a window at someone gently holding a finger against the +glass. You will see two regions, one inner region consisting of the part +of the finger actually touching the glass, and one outer region formed by +the perimeter of the finger. The diameter of the inner region is the +ABS_MT_TOUCH_MAJOR, the diameter of the outer region is +ABS_MT_WIDTH_MAJOR. Now imagine the person pressing the finger harder +against the glass. The inner region will increase, and in general, the +ratio ABS_MT_TOUCH_MAJOR / ABS_MT_WIDTH_MAJOR, which is always smaller than +unity, is related to the finger pressure. For pressure-based devices, +ABS_MT_PRESSURE may be used to provide the pressure on the contact area +instead. + +In addition to the MAJOR parameters, the oval shape of the finger can be +described by adding the MINOR parameters, such that MAJOR and MINOR are the +major and minor axis of an ellipse. Finally, the orientation of the oval +shape can be describe with the ORIENTATION parameter. + +The ABS_MT_TOOL_TYPE may be used to specify whether the touching tool is a finger or a pen or something else. Devices with more granular information may specify general shapes as blobs, i.e., as a sequence of rectangular shapes grouped together by an ABS_MT_BLOB_ID. Finally, for the few devices @@ -42,11 +60,9 @@ report finger tracking from hardware [5]. Here is what a minimal event sequence for a two-finger touch would look like: - ABS_MT_TOUCH_MAJOR ABS_MT_POSITION_X ABS_MT_POSITION_Y SYN_MT_REPORT - ABS_MT_TOUCH_MAJOR ABS_MT_POSITION_X ABS_MT_POSITION_Y SYN_MT_REPORT @@ -87,6 +103,12 @@ the contact. The ratio ABS_MT_TOUCH_MAJOR / ABS_MT_WIDTH_MAJOR approximates the notion of pressure. The fingers of the hand and the palm all have different characteristic widths [1]. +ABS_MT_PRESSURE + +The pressure, in arbitrary units, on the contact area. May be used instead +of TOUCH and WIDTH for pressure-based devices or any device with a spatial +signal intensity distribution. + ABS_MT_ORIENTATION The orientation of the ellipse. The value should describe a signed quarter @@ -170,6 +192,16 @@ There are a few devices that support trackingID in hardware. User space can make use of these native identifiers to reduce bandwidth and cpu usage. +Gestures +-------- + +In the specific application of creating gesture events, the TOUCH and WIDTH +parameters can be used to, e.g., approximate finger pressure or distinguish +between index finger and thumb. With the addition of the MINOR parameters, +one can also distinguish between a sweeping finger and a pointing finger, +and with ORIENTATION, one can detect twisting of fingers. + + Notes ----- diff --git a/Documentation/input/sentelic.txt b/Documentation/input/sentelic.txt new file mode 100644 index 000000000000..f7160a2fb6a2 --- /dev/null +++ b/Documentation/input/sentelic.txt @@ -0,0 +1,475 @@ +Copyright (C) 2002-2008 Sentelic Corporation. +Last update: Oct-31-2008 + +============================================================================== +* Finger Sensing Pad Intellimouse Mode(scrolling wheel, 4th and 5th buttons) +============================================================================== +A) MSID 4: Scrolling wheel mode plus Forward page(4th button) and Backward + page (5th button) +@1. Set sample rate to 200; +@2. Set sample rate to 200; +@3. Set sample rate to 80; +@4. Issuing the "Get device ID" command (0xF2) and waits for the response; +@5. FSP will respond 0x04. + +Packet 1 + Bit 7 6 5 4 3 2 1 0 7 6 5 4 3 2 1 0 7 6 5 4 3 2 1 0 7 6 5 4 3 2 1 0 +BYTE |---------------|BYTE |---------------|BYTE|---------------|BYTE|---------------| + 1 |Y|X|y|x|1|M|R|L| 2 |X|X|X|X|X|X|X|X| 3 |Y|Y|Y|Y|Y|Y|Y|Y| 4 | | |B|F|W|W|W|W| + |---------------| |---------------| |---------------| |---------------| + +Byte 1: Bit7 => Y overflow + Bit6 => X overflow + Bit5 => Y sign bit + Bit4 => X sign bit + Bit3 => 1 + Bit2 => Middle Button, 1 is pressed, 0 is not pressed. + Bit1 => Right Button, 1 is pressed, 0 is not pressed. + Bit0 => Left Button, 1 is pressed, 0 is not pressed. +Byte 2: X Movement(9-bit 2's complement integers) +Byte 3: Y Movement(9-bit 2's complement integers) +Byte 4: Bit3~Bit0 => the scrolling wheel's movement since the last data report. + valid values, -8 ~ +7 + Bit4 => 1 = 4th mouse button is pressed, Forward one page. + 0 = 4th mouse button is not pressed. + Bit5 => 1 = 5th mouse button is pressed, Backward one page. + 0 = 5th mouse button is not pressed. + +B) MSID 6: Horizontal and Vertical scrolling. +@ Set bit 1 in register 0x40 to 1 + +# FSP replaces scrolling wheel's movement as 4 bits to show horizontal and + vertical scrolling. + +Packet 1 + Bit 7 6 5 4 3 2 1 0 7 6 5 4 3 2 1 0 7 6 5 4 3 2 1 0 7 6 5 4 3 2 1 0 +BYTE |---------------|BYTE |---------------|BYTE|---------------|BYTE|---------------| + 1 |Y|X|y|x|1|M|R|L| 2 |X|X|X|X|X|X|X|X| 3 |Y|Y|Y|Y|Y|Y|Y|Y| 4 | | |B|F|l|r|u|d| + |---------------| |---------------| |---------------| |---------------| + +Byte 1: Bit7 => Y overflow + Bit6 => X overflow + Bit5 => Y sign bit + Bit4 => X sign bit + Bit3 => 1 + Bit2 => Middle Button, 1 is pressed, 0 is not pressed. + Bit1 => Right Button, 1 is pressed, 0 is not pressed. + Bit0 => Left Button, 1 is pressed, 0 is not pressed. +Byte 2: X Movement(9-bit 2's complement integers) +Byte 3: Y Movement(9-bit 2's complement integers) +Byte 4: Bit0 => the Vertical scrolling movement downward. + Bit1 => the Vertical scrolling movement upward. + Bit2 => the Vertical scrolling movement rightward. + Bit3 => the Vertical scrolling movement leftward. + Bit4 => 1 = 4th mouse button is pressed, Forward one page. + 0 = 4th mouse button is not pressed. + Bit5 => 1 = 5th mouse button is pressed, Backward one page. + 0 = 5th mouse button is not pressed. + +C) MSID 7: +# FSP uses 2 packets(8 Bytes) data to represent Absolute Position + so we have PACKET NUMBER to identify packets. + If PACKET NUMBER is 0, the packet is Packet 1. + If PACKET NUMBER is 1, the packet is Packet 2. + Please count this number in program. + +# MSID6 special packet will be enable at the same time when enable MSID 7. + +============================================================================== +* Absolute position for STL3886-G0. +============================================================================== +@ Set bit 2 or 3 in register 0x40 to 1 +@ Set bit 6 in register 0x40 to 1 + +Packet 1 (ABSOLUTE POSITION) + Bit 7 6 5 4 3 2 1 0 7 6 5 4 3 2 1 0 7 6 5 4 3 2 1 0 7 6 5 4 3 2 1 0 +BYTE |---------------|BYTE |---------------|BYTE|---------------|BYTE|---------------| + 1 |0|1|V|1|1|M|R|L| 2 |X|X|X|X|X|X|X|X| 3 |Y|Y|Y|Y|Y|Y|Y|Y| 4 |r|l|d|u|X|X|Y|Y| + |---------------| |---------------| |---------------| |---------------| + +Byte 1: Bit7~Bit6 => 00, Normal data packet + => 01, Absolute coordination packet + => 10, Notify packet + Bit5 => valid bit + Bit4 => 1 + Bit3 => 1 + Bit2 => Middle Button, 1 is pressed, 0 is not pressed. + Bit1 => Right Button, 1 is pressed, 0 is not pressed. + Bit0 => Left Button, 1 is pressed, 0 is not pressed. +Byte 2: X coordinate (xpos[9:2]) +Byte 3: Y coordinate (ypos[9:2]) +Byte 4: Bit1~Bit0 => Y coordinate (xpos[1:0]) + Bit3~Bit2 => X coordinate (ypos[1:0]) + Bit4 => scroll up + Bit5 => scroll down + Bit6 => scroll left + Bit7 => scroll right + +Notify Packet for G0 + Bit 7 6 5 4 3 2 1 0 7 6 5 4 3 2 1 0 7 6 5 4 3 2 1 0 7 6 5 4 3 2 1 0 +BYTE |---------------|BYTE |---------------|BYTE|---------------|BYTE|---------------| + 1 |1|0|0|1|1|M|R|L| 2 |C|C|C|C|C|C|C|C| 3 |M|M|M|M|M|M|M|M| 4 |0|0|0|0|0|0|0|0| + |---------------| |---------------| |---------------| |---------------| + +Byte 1: Bit7~Bit6 => 00, Normal data packet + => 01, Absolute coordination packet + => 10, Notify packet + Bit5 => 0 + Bit4 => 1 + Bit3 => 1 + Bit2 => Middle Button, 1 is pressed, 0 is not pressed. + Bit1 => Right Button, 1 is pressed, 0 is not pressed. + Bit0 => Left Button, 1 is pressed, 0 is not pressed. +Byte 2: Message Type => 0x5A (Enable/Disable status packet) + Mode Type => 0xA5 (Normal/Icon mode status) +Byte 3: Message Type => 0x00 (Disabled) + => 0x01 (Enabled) + Mode Type => 0x00 (Normal) + => 0x01 (Icon) +Byte 4: Bit7~Bit0 => Don't Care + +============================================================================== +* Absolute position for STL3888-A0. +============================================================================== +Packet 1 (ABSOLUTE POSITION) + Bit 7 6 5 4 3 2 1 0 7 6 5 4 3 2 1 0 7 6 5 4 3 2 1 0 7 6 5 4 3 2 1 0 +BYTE |---------------|BYTE |---------------|BYTE|---------------|BYTE|---------------| + 1 |0|1|V|A|1|L|0|1| 2 |X|X|X|X|X|X|X|X| 3 |Y|Y|Y|Y|Y|Y|Y|Y| 4 |x|x|y|y|X|X|Y|Y| + |---------------| |---------------| |---------------| |---------------| + +Byte 1: Bit7~Bit6 => 00, Normal data packet + => 01, Absolute coordination packet + => 10, Notify packet + Bit5 => Valid bit, 0 means that the coordinate is invalid or finger up. + When both fingers are up, the last two reports have zero valid + bit. + Bit4 => arc + Bit3 => 1 + Bit2 => Left Button, 1 is pressed, 0 is released. + Bit1 => 0 + Bit0 => 1 +Byte 2: X coordinate (xpos[9:2]) +Byte 3: Y coordinate (ypos[9:2]) +Byte 4: Bit1~Bit0 => Y coordinate (xpos[1:0]) + Bit3~Bit2 => X coordinate (ypos[1:0]) + Bit5~Bit4 => y1_g + Bit7~Bit6 => x1_g + +Packet 2 (ABSOLUTE POSITION) + Bit 7 6 5 4 3 2 1 0 7 6 5 4 3 2 1 0 7 6 5 4 3 2 1 0 7 6 5 4 3 2 1 0 +BYTE |---------------|BYTE |---------------|BYTE|---------------|BYTE|---------------| + 1 |0|1|V|A|1|R|1|0| 2 |X|X|X|X|X|X|X|X| 3 |Y|Y|Y|Y|Y|Y|Y|Y| 4 |x|x|y|y|X|X|Y|Y| + |---------------| |---------------| |---------------| |---------------| + +Byte 1: Bit7~Bit6 => 00, Normal data packet + => 01, Absolute coordinates packet + => 10, Notify packet + Bit5 => Valid bit, 0 means that the coordinate is invalid or finger up. + When both fingers are up, the last two reports have zero valid + bit. + Bit4 => arc + Bit3 => 1 + Bit2 => Right Button, 1 is pressed, 0 is released. + Bit1 => 1 + Bit0 => 0 +Byte 2: X coordinate (xpos[9:2]) +Byte 3: Y coordinate (ypos[9:2]) +Byte 4: Bit1~Bit0 => Y coordinate (xpos[1:0]) + Bit3~Bit2 => X coordinate (ypos[1:0]) + Bit5~Bit4 => y2_g + Bit7~Bit6 => x2_g + +Notify Packet for STL3888-A0 + Bit 7 6 5 4 3 2 1 0 7 6 5 4 3 2 1 0 7 6 5 4 3 2 1 0 7 6 5 4 3 2 1 0 +BYTE |---------------|BYTE |---------------|BYTE|---------------|BYTE|---------------| + 1 |1|0|1|P|1|M|R|L| 2 |C|C|C|C|C|C|C|C| 3 |0|0|F|F|0|0|0|i| 4 |r|l|d|u|0|0|0|0| + |---------------| |---------------| |---------------| |---------------| + +Byte 1: Bit7~Bit6 => 00, Normal data packet + => 01, Absolute coordination packet + => 10, Notify packet + Bit5 => 1 + Bit4 => when in absolute coordinates mode (valid when EN_PKT_GO is 1): + 0: left button is generated by the on-pad command + 1: left button is generated by the external button + Bit3 => 1 + Bit2 => Middle Button, 1 is pressed, 0 is not pressed. + Bit1 => Right Button, 1 is pressed, 0 is not pressed. + Bit0 => Left Button, 1 is pressed, 0 is not pressed. +Byte 2: Message Type => 0xB7 (Multi Finger, Multi Coordinate mode) +Byte 3: Bit7~Bit6 => Don't care + Bit5~Bit4 => Number of fingers + Bit3~Bit1 => Reserved + Bit0 => 1: enter gesture mode; 0: leaving gesture mode +Byte 4: Bit7 => scroll right button + Bit6 => scroll left button + Bit5 => scroll down button + Bit4 => scroll up button + * Note that if gesture and additional button (Bit4~Bit7) + happen at the same time, the button information will not + be sent. + Bit3~Bit0 => Reserved + +Sample sequence of Multi-finger, Multi-coordinate mode: + + notify packet (valid bit == 1), abs pkt 1, abs pkt 2, abs pkt 1, + abs pkt 2, ..., notify packet(valid bit == 0) + +============================================================================== +* FSP Enable/Disable packet +============================================================================== + Bit 7 6 5 4 3 2 1 0 7 6 5 4 3 2 1 0 7 6 5 4 3 2 1 0 7 6 5 4 3 2 1 0 +BYTE |---------------|BYTE |---------------|BYTE|---------------|BYTE|---------------| + 1 |Y|X|0|0|1|M|R|L| 2 |0|1|0|1|1|0|1|E| 3 | | | | | | | | | 4 | | | | | | | | | + |---------------| |---------------| |---------------| |---------------| + +FSP will send out enable/disable packet when FSP receive PS/2 enable/disable +command. Host will receive the packet which Middle, Right, Left button will +be set. The packet only use byte 0 and byte 1 as a pattern of original packet. +Ignore the other bytes of the packet. + +Byte 1: Bit7 => 0, Y overflow + Bit6 => 0, X overflow + Bit5 => 0, Y sign bit + Bit4 => 0, X sign bit + Bit3 => 1 + Bit2 => 1, Middle Button + Bit1 => 1, Right Button + Bit0 => 1, Left Button +Byte 2: Bit7~1 => (0101101b) + Bit0 => 1 = Enable + 0 = Disable +Byte 3: Don't care +Byte 4: Don't care (MOUSE ID 3, 4) +Byte 5~8: Don't care (Absolute packet) + +============================================================================== +* PS/2 Command Set +============================================================================== + +FSP supports basic PS/2 commanding set and modes, refer to following URL for +details about PS/2 commands: + +http://www.computer-engineering.org/index.php?title=PS/2_Mouse_Interface + +============================================================================== +* Programming Sequence for Determining Packet Parsing Flow +============================================================================== +1. Identify FSP by reading device ID(0x00) and version(0x01) register + +2. Determine number of buttons by reading status2 (0x0b) register + + buttons = reg[0x0b] & 0x30 + + if buttons == 0x30 or buttons == 0x20: + # two/four buttons + Refer to 'Finger Sensing Pad PS/2 Mouse Intellimouse' + section A for packet parsing detail(ignore byte 4, bit ~ 7) + elif buttons == 0x10: + # 6 buttons + Refer to 'Finger Sensing Pad PS/2 Mouse Intellimouse' + section B for packet parsing detail + elif buttons == 0x00: + # 6 buttons + Refer to 'Finger Sensing Pad PS/2 Mouse Intellimouse' + section A for packet parsing detail + +============================================================================== +* Programming Sequence for Register Reading/Writing +============================================================================== + +Register inversion requirement: + + Following values needed to be inverted(the '~' operator in C) before being +sent to FSP: + + 0xe9, 0xee, 0xf2 and 0xff. + +Register swapping requirement: + + Following values needed to have their higher 4 bits and lower 4 bits being +swapped before being sent to FSP: + + 10, 20, 40, 60, 80, 100 and 200. + +Register reading sequence: + + 1. send 0xf3 PS/2 command to FSP; + + 2. send 0x66 PS/2 command to FSP; + + 3. send 0x88 PS/2 command to FSP; + + 4. send 0xf3 PS/2 command to FSP; + + 5. if the register address being to read is not required to be + inverted(refer to the 'Register inversion requirement' section), + goto step 6 + + 5a. send 0x68 PS/2 command to FSP; + + 5b. send the inverted register address to FSP and goto step 8; + + 6. if the register address being to read is not required to be + swapped(refer to the 'Register swapping requirement' section), + goto step 7 + + 6a. send 0xcc PS/2 command to FSP; + + 6b. send the swapped register address to FSP and goto step 8; + + 7. send 0x66 PS/2 command to FSP; + + 7a. send the original register address to FSP and goto step 8; + + 8. send 0xe9(status request) PS/2 command to FSP; + + 9. the response read from FSP should be the requested register value. + +Register writing sequence: + + 1. send 0xf3 PS/2 command to FSP; + + 2. if the register address being to write is not required to be + inverted(refer to the 'Register inversion requirement' section), + goto step 3 + + 2a. send 0x74 PS/2 command to FSP; + + 2b. send the inverted register address to FSP and goto step 5; + + 3. if the register address being to write is not required to be + swapped(refer to the 'Register swapping requirement' section), + goto step 4 + + 3a. send 0x77 PS/2 command to FSP; + + 3b. send the swapped register address to FSP and goto step 5; + + 4. send 0x55 PS/2 command to FSP; + + 4a. send the register address to FSP and goto step 5; + + 5. send 0xf3 PS/2 command to FSP; + + 6. if the register value being to write is not required to be + inverted(refer to the 'Register inversion requirement' section), + goto step 7 + + 6a. send 0x47 PS/2 command to FSP; + + 6b. send the inverted register value to FSP and goto step 9; + + 7. if the register value being to write is not required to be + swapped(refer to the 'Register swapping requirement' section), + goto step 8 + + 7a. send 0x44 PS/2 command to FSP; + + 7b. send the swapped register value to FSP and goto step 9; + + 8. send 0x33 PS/2 command to FSP; + + 8a. send the register value to FSP; + + 9. the register writing sequence is completed. + +============================================================================== +* Register Listing +============================================================================== + +offset width default r/w name +0x00 bit7~bit0 0x01 RO device ID + +0x01 bit7~bit0 0xc0 RW version ID + +0x02 bit7~bit0 0x01 RO vendor ID + +0x03 bit7~bit0 0x01 RO product ID + +0x04 bit3~bit0 0x01 RW revision ID + +0x0b RO test mode status 1 + bit3 1 RO 0: rotate 180 degree, 1: no rotation + + bit5~bit4 RO number of buttons + 11 => 2, lbtn/rbtn + 10 => 4, lbtn/rbtn/scru/scrd + 01 => 6, lbtn/rbtn/scru/scrd/scrl/scrr + 00 => 6, lbtn/rbtn/scru/scrd/fbtn/bbtn + +0x0f RW register file page control + bit0 0 RW 1 to enable page 1 register files + +0x10 RW system control 1 + bit0 1 RW Reserved, must be 1 + bit1 0 RW Reserved, must be 0 + bit4 1 RW Reserved, must be 0 + bit5 0 RW register clock gating enable + 0: read only, 1: read/write enable + (Note that following registers does not require clock gating being + enabled prior to write: 05 06 07 08 09 0c 0f 10 11 12 16 17 18 23 2e + 40 41 42 43.) + +0x31 RW on-pad command detection + bit7 0 RW on-pad command left button down tag + enable + 0: disable, 1: enable + +0x34 RW on-pad command control 5 + bit4~bit0 0x05 RW XLO in 0s/4/1, so 03h = 0010.1b = 2.5 + (Note that position unit is in 0.5 scanline) + + bit7 0 RW on-pad tap zone enable + 0: disable, 1: enable + +0x35 RW on-pad command control 6 + bit4~bit0 0x1d RW XHI in 0s/4/1, so 19h = 1100.1b = 12.5 + (Note that position unit is in 0.5 scanline) + +0x36 RW on-pad command control 7 + bit4~bit0 0x04 RW YLO in 0s/4/1, so 03h = 0010.1b = 2.5 + (Note that position unit is in 0.5 scanline) + +0x37 RW on-pad command control 8 + bit4~bit0 0x13 RW YHI in 0s/4/1, so 11h = 1000.1b = 8.5 + (Note that position unit is in 0.5 scanline) + +0x40 RW system control 5 + bit1 0 RW FSP Intellimouse mode enable + 0: disable, 1: enable + + bit2 0 RW movement + abs. coordinate mode enable + 0: disable, 1: enable + (Note that this function has the functionality of bit 1 even when + bit 1 is not set. However, the format is different from that of bit 1. + In addition, when bit 1 and bit 2 are set at the same time, bit 2 will + override bit 1.) + + bit3 0 RW abs. coordinate only mode enable + 0: disable, 1: enable + (Note that this function has the functionality of bit 1 even when + bit 1 is not set. However, the format is different from that of bit 1. + In addition, when bit 1, bit 2 and bit 3 are set at the same time, + bit 3 will override bit 1 and 2.) + + bit5 0 RW auto switch enable + 0: disable, 1: enable + + bit6 0 RW G0 abs. + notify packet format enable + 0: disable, 1: enable + (Note that the absolute/relative coordinate output still depends on + bit 2 and 3. That is, if any of those bit is 1, host will receive + absolute coordinates; otherwise, host only receives packets with + relative coordinate.) + +0x43 RW on-pad control + bit0 0 RW on-pad control enable + 0: disable, 1: enable + (Note that if this bit is cleared, bit 3/5 will be ineffective) + + bit3 0 RW on-pad fix vertical scrolling enable + 0: disable, 1: enable + + bit5 0 RW on-pad fix horizontal scrolling enable + 0: disable, 1: enable diff --git a/Documentation/intel_txt.txt b/Documentation/intel_txt.txt new file mode 100644 index 000000000000..f40a1f030019 --- /dev/null +++ b/Documentation/intel_txt.txt @@ -0,0 +1,210 @@ +Intel(R) TXT Overview: +===================== + +Intel's technology for safer computing, Intel(R) Trusted Execution +Technology (Intel(R) TXT), defines platform-level enhancements that +provide the building blocks for creating trusted platforms. + +Intel TXT was formerly known by the code name LaGrande Technology (LT). + +Intel TXT in Brief: +o Provides dynamic root of trust for measurement (DRTM) +o Data protection in case of improper shutdown +o Measurement and verification of launched environment + +Intel TXT is part of the vPro(TM) brand and is also available some +non-vPro systems. It is currently available on desktop systems +based on the Q35, X38, Q45, and Q43 Express chipsets (e.g. Dell +Optiplex 755, HP dc7800, etc.) and mobile systems based on the GM45, +PM45, and GS45 Express chipsets. + +For more information, see http://www.intel.com/technology/security/. +This site also has a link to the Intel TXT MLE Developers Manual, +which has been updated for the new released platforms. + +Intel TXT has been presented at various events over the past few +years, some of which are: + LinuxTAG 2008: + http://www.linuxtag.org/2008/en/conf/events/vp-donnerstag/ + details.html?talkid=110 + TRUST2008: + http://www.trust2008.eu/downloads/Keynote-Speakers/ + 3_David-Grawrock_The-Front-Door-of-Trusted-Computing.pdf + IDF 2008, Shanghai: + http://inteldeveloperforum.com.edgesuite.net/shanghai_2008/ + aep/PROS003/index.html + IDFs 2006, 2007 (I'm not sure if/where they are online) + +Trusted Boot Project Overview: +============================= + +Trusted Boot (tboot) is an open source, pre- kernel/VMM module that +uses Intel TXT to perform a measured and verified launch of an OS +kernel/VMM. + +It is hosted on SourceForge at http://sourceforge.net/projects/tboot. +The mercurial source repo is available at http://www.bughost.org/ +repos.hg/tboot.hg. + +Tboot currently supports launching Xen (open source VMM/hypervisor +w/ TXT support since v3.2), and now Linux kernels. + + +Value Proposition for Linux or "Why should you care?" +===================================================== + +While there are many products and technologies that attempt to +measure or protect the integrity of a running kernel, they all +assume the kernel is "good" to begin with. The Integrity +Measurement Architecture (IMA) and Linux Integrity Module interface +are examples of such solutions. + +To get trust in the initial kernel without using Intel TXT, a +static root of trust must be used. This bases trust in BIOS +starting at system reset and requires measurement of all code +executed between system reset through the completion of the kernel +boot as well as data objects used by that code. In the case of a +Linux kernel, this means all of BIOS, any option ROMs, the +bootloader and the boot config. In practice, this is a lot of +code/data, much of which is subject to change from boot to boot +(e.g. changing NICs may change option ROMs). Without reference +hashes, these measurement changes are difficult to assess or +confirm as benign. This process also does not provide DMA +protection, memory configuration/alias checks and locks, crash +protection, or policy support. + +By using the hardware-based root of trust that Intel TXT provides, +many of these issues can be mitigated. Specifically: many +pre-launch components can be removed from the trust chain, DMA +protection is provided to all launched components, a large number +of platform configuration checks are performed and values locked, +protection is provided for any data in the event of an improper +shutdown, and there is support for policy-based execution/verification. +This provides a more stable measurement and a higher assurance of +system configuration and initial state than would be otherwise +possible. Since the tboot project is open source, source code for +almost all parts of the trust chain is available (excepting SMM and +Intel-provided firmware). + +How Does it Work? +================= + +o Tboot is an executable that is launched by the bootloader as + the "kernel" (the binary the bootloader executes). +o It performs all of the work necessary to determine if the + platform supports Intel TXT and, if so, executes the GETSEC[SENTER] + processor instruction that initiates the dynamic root of trust. + - If tboot determines that the system does not support Intel TXT + or is not configured correctly (e.g. the SINIT AC Module was + incorrect), it will directly launch the kernel with no changes + to any state. + - Tboot will output various information about its progress to the + terminal, serial port, and/or an in-memory log; the output + locations can be configured with a command line switch. +o The GETSEC[SENTER] instruction will return control to tboot and + tboot then verifies certain aspects of the environment (e.g. TPM NV + lock, e820 table does not have invalid entries, etc.). +o It will wake the APs from the special sleep state the GETSEC[SENTER] + instruction had put them in and place them into a wait-for-SIPI + state. + - Because the processors will not respond to an INIT or SIPI when + in the TXT environment, it is necessary to create a small VT-x + guest for the APs. When they run in this guest, they will + simply wait for the INIT-SIPI-SIPI sequence, which will cause + VMEXITs, and then disable VT and jump to the SIPI vector. This + approach seemed like a better choice than having to insert + special code into the kernel's MP wakeup sequence. +o Tboot then applies an (optional) user-defined launch policy to + verify the kernel and initrd. + - This policy is rooted in TPM NV and is described in the tboot + project. The tboot project also contains code for tools to + create and provision the policy. + - Policies are completely under user control and if not present + then any kernel will be launched. + - Policy action is flexible and can include halting on failures + or simply logging them and continuing. +o Tboot adjusts the e820 table provided by the bootloader to reserve + its own location in memory as well as to reserve certain other + TXT-related regions. +o As part of it's launch, tboot DMA protects all of RAM (using the + VT-d PMRs). Thus, the kernel must be booted with 'intel_iommu=on' + in order to remove this blanket protection and use VT-d's + page-level protection. +o Tboot will populate a shared page with some data about itself and + pass this to the Linux kernel as it transfers control. + - The location of the shared page is passed via the boot_params + struct as a physical address. +o The kernel will look for the tboot shared page address and, if it + exists, map it. +o As one of the checks/protections provided by TXT, it makes a copy + of the VT-d DMARs in a DMA-protected region of memory and verifies + them for correctness. The VT-d code will detect if the kernel was + launched with tboot and use this copy instead of the one in the + ACPI table. +o At this point, tboot and TXT are out of the picture until a + shutdown (S<n>) +o In order to put a system into any of the sleep states after a TXT + launch, TXT must first be exited. This is to prevent attacks that + attempt to crash the system to gain control on reboot and steal + data left in memory. + - The kernel will perform all of its sleep preparation and + populate the shared page with the ACPI data needed to put the + platform in the desired sleep state. + - Then the kernel jumps into tboot via the vector specified in the + shared page. + - Tboot will clean up the environment and disable TXT, then use the + kernel-provided ACPI information to actually place the platform + into the desired sleep state. + - In the case of S3, tboot will also register itself as the resume + vector. This is necessary because it must re-establish the + measured environment upon resume. Once the TXT environment + has been restored, it will restore the TPM PCRs and then + transfer control back to the kernel's S3 resume vector. + In order to preserve system integrity across S3, the kernel + provides tboot with a set of memory ranges (kernel + code/data/bss, S3 resume code, and AP trampoline) that tboot + will calculate a MAC (message authentication code) over and then + seal with the TPM. On resume and once the measured environment + has been re-established, tboot will re-calculate the MAC and + verify it against the sealed value. Tboot's policy determines + what happens if the verification fails. + +That's pretty much it for TXT support. + + +Configuring the System: +====================== + +This code works with 32bit, 32bit PAE, and 64bit (x86_64) kernels. + +In BIOS, the user must enable: TPM, TXT, VT-x, VT-d. Not all BIOSes +allow these to be individually enabled/disabled and the screens in +which to find them are BIOS-specific. + +grub.conf needs to be modified as follows: + title Linux 2.6.29-tip w/ tboot + root (hd0,0) + kernel /tboot.gz logging=serial,vga,memory + module /vmlinuz-2.6.29-tip intel_iommu=on ro + root=LABEL=/ rhgb console=ttyS0,115200 3 + module /initrd-2.6.29-tip.img + module /Q35_SINIT_17.BIN + +The kernel option for enabling Intel TXT support is found under the +Security top-level menu and is called "Enable Intel(R) Trusted +Execution Technology (TXT)". It is marked as EXPERIMENTAL and +depends on the generic x86 support (to allow maximum flexibility in +kernel build options), since the tboot code will detect whether the +platform actually supports Intel TXT and thus whether any of the +kernel code is executed. + +The Q35_SINIT_17.BIN file is what Intel TXT refers to as an +Authenticated Code Module. It is specific to the chipset in the +system and can also be found on the Trusted Boot site. It is an +(unencrypted) module signed by Intel that is used as part of the +DRTM process to verify and configure the system. It is signed +because it operates at a higher privilege level in the system than +any other macrocode and its correct operation is critical to the +establishment of the DRTM. The process for determining the correct +SINIT ACM for a system is documented in the SINIT-guide.txt file +that is on the tboot SourceForge site under the SINIT ACM downloads. diff --git a/Documentation/ioctl/ioctl-number.txt b/Documentation/ioctl/ioctl-number.txt index dbea4f95fc85..35cf64d4436d 100644 --- a/Documentation/ioctl/ioctl-number.txt +++ b/Documentation/ioctl/ioctl-number.txt @@ -56,10 +56,11 @@ Following this convention is good because: (5) When following the convention, the driver code can use generic code to copy the parameters between user and kernel space. -This table lists ioctls visible from user land for Linux/i386. It contains -most drivers up to 2.3.14, but I know I am missing some. +This table lists ioctls visible from user land for Linux/x86. It contains +most drivers up to 2.6.31, but I know I am missing some. There has been +no attempt to list non-X86 architectures or ioctls from drivers/staging/. -Code Seq# Include File Comments +Code Seq#(hex) Include File Comments ======================================================== 0x00 00-1F linux/fs.h conflict! 0x00 00-1F scsi/scsi_ioctl.h conflict! @@ -69,117 +70,228 @@ Code Seq# Include File Comments 0x03 all linux/hdreg.h 0x04 D2-DC linux/umsdos_fs.h Dead since 2.6.11, but don't reuse these. 0x06 all linux/lp.h -0x09 all linux/md.h +0x09 all linux/raid/md_u.h +0x10 00-0F drivers/char/s390/vmcp.h 0x12 all linux/fs.h linux/blkpg.h 0x1b all InfiniBand Subsystem <http://www.openib.org/> 0x20 all drivers/cdrom/cm206.h 0x22 all scsi/sg.h '#' 00-3F IEEE 1394 Subsystem Block for the entire subsystem +'$' 00-0F linux/perf_counter.h, linux/perf_event.h '1' 00-1F <linux/timepps.h> PPS kit from Ulrich Windl <ftp://ftp.de.kernel.org/pub/linux/daemons/ntp/PPS/> +'2' 01-04 linux/i2o.h +'3' 00-0F drivers/s390/char/raw3270.h conflict! +'3' 00-1F linux/suspend_ioctls.h conflict! + and kernel/power/user.c '8' all SNP8023 advanced NIC card <mailto:mcr@solidum.com> -'A' 00-1F linux/apm_bios.h +'@' 00-0F linux/radeonfb.h conflict! +'@' 00-0F drivers/video/aty/aty128fb.c conflict! +'A' 00-1F linux/apm_bios.h conflict! +'A' 00-0F linux/agpgart.h conflict! + and drivers/char/agp/compat_ioctl.h +'A' 00-7F sound/asound.h conflict! +'B' 00-1F linux/cciss_ioctl.h conflict! +'B' 00-0F include/linux/pmu.h conflict! 'B' C0-FF advanced bbus <mailto:maassen@uni-freiburg.de> -'C' all linux/soundcard.h +'C' all linux/soundcard.h conflict! +'C' 01-2F linux/capi.h conflict! +'C' F0-FF drivers/net/wan/cosa.h conflict! 'D' all arch/s390/include/asm/dasd.h -'E' all linux/input.h -'F' all linux/fb.h -'H' all linux/hiddev.h -'I' all linux/isdn.h +'D' 40-5F drivers/scsi/dpt/dtpi_ioctl.h +'D' 05 drivers/scsi/pmcraid.h +'E' all linux/input.h conflict! +'E' 00-0F xen/evtchn.h conflict! +'F' all linux/fb.h conflict! +'F' 01-02 drivers/scsi/pmcraid.h conflict! +'F' 20 drivers/video/fsl-diu-fb.h conflict! +'F' 20 drivers/video/intelfb/intelfb.h conflict! +'F' 20 linux/ivtvfb.h conflict! +'F' 20 linux/matroxfb.h conflict! +'F' 20 drivers/video/aty/atyfb_base.c conflict! +'F' 00-0F video/da8xx-fb.h conflict! +'F' 80-8F linux/arcfb.h conflict! +'F' DD video/sstfb.h conflict! +'G' 00-3F drivers/misc/sgi-gru/grulib.h conflict! +'G' 00-0F linux/gigaset_dev.h conflict! +'H' 00-7F linux/hiddev.h conflict! +'H' 00-0F linux/hidraw.h conflict! +'H' 00-0F sound/asound.h conflict! +'H' 20-40 sound/asound_fm.h conflict! +'H' 80-8F sound/sfnt_info.h conflict! +'H' 10-8F sound/emu10k1.h conflict! +'H' 10-1F sound/sb16_csp.h conflict! +'H' 10-1F sound/hda_hwdep.h conflict! +'H' 40-4F sound/hdspm.h conflict! +'H' 40-4F sound/hdsp.h conflict! +'H' 90 sound/usb/usx2y/usb_stream.h +'H' C0-F0 net/bluetooth/hci.h conflict! +'H' C0-DF net/bluetooth/hidp/hidp.h conflict! +'H' C0-DF net/bluetooth/cmtp/cmtp.h conflict! +'H' C0-DF net/bluetooth/bnep/bnep.h conflict! +'I' all linux/isdn.h conflict! +'I' 00-0F drivers/isdn/divert/isdn_divert.h conflict! +'I' 40-4F linux/mISDNif.h conflict! 'J' 00-1F drivers/scsi/gdth_ioctl.h 'K' all linux/kd.h -'L' 00-1F linux/loop.h -'L' 20-2F driver/usb/misc/vstusb.h +'L' 00-1F linux/loop.h conflict! +'L' 10-1F drivers/scsi/mpt2sas/mpt2sas_ctl.h conflict! +'L' 20-2F linux/usb/vstusb.h 'L' E0-FF linux/ppdd.h encrypted disk device driver <http://linux01.gwdg.de/~alatham/ppdd.html> -'M' all linux/soundcard.h +'M' all linux/soundcard.h conflict! +'M' 01-16 mtd/mtd-abi.h conflict! + and drivers/mtd/mtdchar.c +'M' 01-03 drivers/scsi/megaraid/megaraid_sas.h +'M' 00-0F drivers/video/fsl-diu-fb.h conflict! 'N' 00-1F drivers/usb/scanner.h -'O' 00-02 include/mtd/ubi-user.h UBI -'P' all linux/soundcard.h +'O' 00-06 mtd/ubi-user.h UBI +'P' all linux/soundcard.h conflict! +'P' 60-6F sound/sscape_ioctl.h conflict! +'P' 00-0F drivers/usb/class/usblp.c conflict! 'Q' all linux/soundcard.h -'R' 00-1F linux/random.h +'R' 00-1F linux/random.h conflict! +'R' 01 linux/rfkill.h conflict! +'R' 01-0F media/rds.h conflict! +'R' C0-DF net/bluetooth/rfcomm.h 'S' all linux/cdrom.h conflict! 'S' 80-81 scsi/scsi_ioctl.h conflict! 'S' 82-FF scsi/scsi.h conflict! +'S' 00-7F sound/asequencer.h conflict! 'T' all linux/soundcard.h conflict! +'T' 00-AF sound/asound.h conflict! 'T' all arch/x86/include/asm/ioctls.h conflict! -'U' 00-EF linux/drivers/usb/usb.h -'V' all linux/vt.h +'T' C0-DF linux/if_tun.h conflict! +'U' all sound/asound.h conflict! +'U' 00-0F drivers/media/video/uvc/uvcvideo.h conflict! +'U' 00-CF linux/uinput.h conflict! +'U' 00-EF linux/usbdevice_fs.h +'U' C0-CF drivers/bluetooth/hci_uart.h +'V' all linux/vt.h conflict! +'V' all linux/videodev2.h conflict! +'V' C0 linux/ivtvfb.h conflict! +'V' C0 linux/ivtv.h conflict! +'V' C0 media/davinci/vpfe_capture.h conflict! +'V' C0 media/si4713.h conflict! +'V' C0-CF drivers/media/video/mxb.h conflict! 'W' 00-1F linux/watchdog.h conflict! 'W' 00-1F linux/wanrouter.h conflict! -'X' all linux/xfs_fs.h +'W' 00-3F sound/asound.h conflict! +'X' all fs/xfs/xfs_fs.h conflict! + and fs/xfs/linux-2.6/xfs_ioctl32.h + and include/linux/falloc.h + and linux/fs.h +'X' all fs/ocfs2/ocfs_fs.h conflict! +'X' 01 linux/pktcdvd.h conflict! 'Y' all linux/cyclades.h -'[' 00-07 linux/usb/usbtmc.h USB Test and Measurement Devices +'Z' 14-15 drivers/message/fusion/mptctl.h +'[' 00-07 linux/usb/tmc.h USB Test and Measurement Devices <mailto:gregkh@suse.de> -'a' all ATM on linux +'a' all linux/atm*.h, linux/sonet.h ATM on linux <http://lrcwww.epfl.ch/linux-atm/magic.html> -'b' 00-FF bit3 vme host bridge +'b' 00-FF conflict! bit3 vme host bridge <mailto:natalia@nikhefk.nikhef.nl> +'b' 00-0F media/bt819.h conflict! +'c' all linux/cm4000_cs.h conflict! 'c' 00-7F linux/comstats.h conflict! 'c' 00-7F linux/coda.h conflict! -'c' 80-9F arch/s390/include/asm/chsc.h +'c' 00-1F linux/chio.h conflict! +'c' 80-9F arch/s390/include/asm/chsc.h conflict! +'c' A0-AF arch/x86/include/asm/msr.h conflict! 'd' 00-FF linux/char/drm/drm/h conflict! +'d' 02-40 pcmcia/ds.h conflict! +'d' 10-3F drivers/media/video/dabusb.h conflict! +'d' C0-CF drivers/media/video/saa7191.h conflict! 'd' F0-FF linux/digi1.h 'e' all linux/digi1.h conflict! -'e' 00-1F net/irda/irtty.h conflict! -'f' 00-1F linux/ext2_fs.h -'h' 00-7F Charon filesystem +'e' 00-1F drivers/net/irda/irtty-sir.h conflict! +'f' 00-1F linux/ext2_fs.h conflict! +'f' 00-1F linux/ext3_fs.h conflict! +'f' 00-0F fs/jfs/jfs_dinode.h conflict! +'f' 00-0F fs/ext4/ext4.h conflict! +'f' 00-0F linux/fs.h conflict! +'f' 00-0F fs/ocfs2/ocfs2_fs.h conflict! +'g' 00-0F linux/usb/gadgetfs.h +'g' 20-2F linux/usb/g_printer.h +'h' 00-7F conflict! Charon filesystem <mailto:zapman@interlan.net> -'i' 00-3F linux/i2o.h +'h' 00-1F linux/hpet.h conflict! +'i' 00-3F linux/i2o-dev.h conflict! +'i' 0B-1F linux/ipmi.h conflict! +'i' 80-8F linux/i8k.h 'j' 00-3F linux/joystick.h +'k' 00-0F linux/spi/spidev.h conflict! +'k' 00-05 video/kyro.h conflict! 'l' 00-3F linux/tcfs_fs.h transparent cryptographic file system <http://mikonos.dia.unisa.it/tcfs> 'l' 40-7F linux/udf_fs_i.h in development: <http://sourceforge.net/projects/linux-udf/> +'m' 00-09 linux/mmtimer.h conflict! 'm' all linux/mtio.h conflict! 'm' all linux/soundcard.h conflict! 'm' all linux/synclink.h conflict! +'m' 00-19 drivers/message/fusion/mptctl.h conflict! +'m' 00 drivers/scsi/megaraid/megaraid_ioctl.h conflict! 'm' 00-1F net/irda/irmod.h conflict! -'n' 00-7F linux/ncp_fs.h +'n' 00-7F linux/ncp_fs.h and fs/ncpfs/ioctl.c 'n' 80-8F linux/nilfs2_fs.h NILFS2 -'n' E0-FF video/matrox.h matroxfb +'n' E0-FF linux/matroxfb.h matroxfb 'o' 00-1F fs/ocfs2/ocfs2_fs.h OCFS2 -'o' 00-03 include/mtd/ubi-user.h conflict! (OCFS2 and UBI overlaps) -'o' 40-41 include/mtd/ubi-user.h UBI -'o' 01-A1 include/linux/dvb/*.h DVB +'o' 00-03 mtd/ubi-user.h conflict! (OCFS2 and UBI overlaps) +'o' 40-41 mtd/ubi-user.h UBI +'o' 01-A1 linux/dvb/*.h DVB 'p' 00-0F linux/phantom.h conflict! (OpenHaptics needs this) +'p' 00-1F linux/rtc.h conflict! 'p' 00-3F linux/mc146818rtc.h conflict! 'p' 40-7F linux/nvram.h -'p' 80-9F user-space parport +'p' 80-9F linux/ppdev.h user-space parport <mailto:tim@cyberelk.net> -'p' a1-a4 linux/pps.h LinuxPPS +'p' A1-A4 linux/pps.h LinuxPPS <mailto:giometti@linux.it> 'q' 00-1F linux/serio.h -'q' 80-FF Internet PhoneJACK, Internet LineJACK - <http://www.quicknet.net> -'r' 00-1F linux/msdos_fs.h +'q' 80-FF linux/telephony.h Internet PhoneJACK, Internet LineJACK + linux/ixjuser.h <http://www.quicknet.net> +'r' 00-1F linux/msdos_fs.h and fs/fat/dir.c 's' all linux/cdk.h 't' 00-7F linux/if_ppp.h 't' 80-8F linux/isdn_ppp.h +'t' 90 linux/toshiba.h 'u' 00-1F linux/smb_fs.h -'v' 00-1F linux/ext2_fs.h conflict! 'v' all linux/videodev.h conflict! +'v' 00-1F linux/ext2_fs.h conflict! +'v' 00-1F linux/fs.h conflict! +'v' 00-0F linux/sonypi.h conflict! +'v' C0-CF drivers/media/video/ov511.h conflict! +'v' C0-DF media/pwc-ioctl.h conflict! +'v' C0-FF linux/meye.h conflict! +'v' C0-CF drivers/media/video/zoran/zoran.h conflict! +'v' D0-DF drivers/media/video/cpia2/cpia2dev.h conflict! 'w' all CERN SCI driver 'y' 00-1F packet based user level communications <mailto:zapman@interlan.net> -'z' 00-3F CAN bus card +'z' 00-3F CAN bus card conflict! <mailto:hdstich@connectu.ulm.circular.de> -'z' 40-7F CAN bus card +'z' 40-7F CAN bus card conflict! <mailto:oe@port.de> +'z' 10-4F drivers/s390/crypto/zcrypt_api.h conflict! 0x80 00-1F linux/fb.h 0x81 00-1F linux/videotext.h +0x88 00-3F media/ovcamchip.h 0x89 00-06 arch/x86/include/asm/sockios.h 0x89 0B-DF linux/sockios.h 0x89 E0-EF linux/sockios.h SIOCPROTOPRIVATE range +0x89 E0-EF linux/dn.h PROTOPRIVATE range 0x89 F0-FF linux/sockios.h SIOCDEVPRIVATE range 0x8B all linux/wireless.h 0x8C 00-3F WiNRADiO driver <http://www.proximity.com.au/~brian/winradio/> 0x90 00 drivers/cdrom/sbpcd.h +0x92 00-0F drivers/usb/mon/mon_bin.c 0x93 60-7F linux/auto_fs.h +0x94 all fs/btrfs/ioctl.h 0x99 00-0F 537-Addinboard driver <mailto:buk@buks.ipn.de> 0xA0 all linux/sdp/sdp.h Industrial Device Project @@ -190,17 +302,22 @@ Code Seq# Include File Comments 0xAB 00-1F linux/nbd.h 0xAC 00-1F linux/raw.h 0xAD 00 Netfilter device in development: - <mailto:rusty@rustcorp.com.au> + <mailto:rusty@rustcorp.com.au> 0xAE all linux/kvm.h Kernel-based Virtual Machine - <mailto:kvm-devel@lists.sourceforge.net> + <mailto:kvm@vger.kernel.org> 0xB0 all RATIO devices in development: <mailto:vgo@ratio.de> 0xB1 00-1F PPPoX <mailto:mostrows@styx.uwaterloo.ca> +0xC0 00-0F linux/usb/iowarrior.h 0xCB 00-1F CBM serial IEC bus in development: <mailto:michael.klein@puffin.lb.shuttle.de> +0xCD 01 linux/reiserfs_fs.h +0xCF 02 fs/cifs/ioctl.c +0xDB 00-0F drivers/char/mwave/mwavepub.h 0xDD 00-3F ZFCP device driver see drivers/s390/scsi/ <mailto:aherrman@de.ibm.com> -0xF3 00-3F video/sisfb.h sisfb (in development) +0xF3 00-3F drivers/usb/misc/sisusbvga/sisusb.h sisfb (in development) <mailto:thomas@winischhofer.net> 0xF4 00-1F video/mbxfb.h mbxfb <mailto:raph@8d.com> +0xFD all linux/dm-ioctl.h diff --git a/Documentation/isdn/INTERFACE.CAPI b/Documentation/isdn/INTERFACE.CAPI index 686e107923ec..5fe8de5cc727 100644 --- a/Documentation/isdn/INTERFACE.CAPI +++ b/Documentation/isdn/INTERFACE.CAPI @@ -60,10 +60,9 @@ open() operation on regular files or character devices. After a successful return from register_appl(), CAPI messages from the application may be passed to the driver for the device via calls to the -send_message() callback function. The CAPI message to send is stored in the -data portion of an skb. Conversely, the driver may call Kernel CAPI's -capi_ctr_handle_message() function to pass a received CAPI message to Kernel -CAPI for forwarding to an application, specifying its ApplID. +send_message() callback function. Conversely, the driver may call Kernel +CAPI's capi_ctr_handle_message() function to pass a received CAPI message to +Kernel CAPI for forwarding to an application, specifying its ApplID. Deregistration requests (CAPI operation CAPI_RELEASE) from applications are forwarded as calls to the release_appl() callback function, passing the same @@ -142,6 +141,7 @@ u16 (*send_message)(struct capi_ctr *ctrlr, struct sk_buff *skb) to accepting or queueing the message. Errors occurring during the actual processing of the message should be signaled with an appropriate reply message. + May be called in process or interrupt context. Calls to this function are not serialized by Kernel CAPI, ie. it must be prepared to be re-entered. @@ -154,7 +154,8 @@ read_proc_t *ctr_read_proc system entry, /proc/capi/controllers/<n>; will be called with a pointer to the device's capi_ctr structure as the last (data) argument -Note: Callback functions are never called in interrupt context. +Note: Callback functions except send_message() are never called in interrupt +context. - to be filled in before calling capi_ctr_ready(): @@ -171,14 +172,40 @@ u8 serial[CAPI_SERIAL_LEN] value to return for CAPI_GET_SERIAL -4.3 The _cmsg Structure +4.3 SKBs + +CAPI messages are passed between Kernel CAPI and the driver via send_message() +and capi_ctr_handle_message(), stored in the data portion of a socket buffer +(skb). Each skb contains a single CAPI message coded according to the CAPI 2.0 +standard. + +For the data transfer messages, DATA_B3_REQ and DATA_B3_IND, the actual +payload data immediately follows the CAPI message itself within the same skb. +The Data and Data64 parameters are not used for processing. The Data64 +parameter may be omitted by setting the length field of the CAPI message to 22 +instead of 30. + + +4.4 The _cmsg Structure (declared in <linux/isdn/capiutil.h>) The _cmsg structure stores the contents of a CAPI 2.0 message in an easily -accessible form. It contains members for all possible CAPI 2.0 parameters, of -which only those appearing in the message type currently being processed are -actually used. Unused members should be set to zero. +accessible form. It contains members for all possible CAPI 2.0 parameters, +including subparameters of the Additional Info and B Protocol structured +parameters, with the following exceptions: + +* second Calling party number (CONNECT_IND) + +* Data64 (DATA_B3_REQ and DATA_B3_IND) + +* Sending complete (subparameter of Additional Info, CONNECT_REQ and INFO_REQ) + +* Global Configuration (subparameter of B Protocol, CONNECT_REQ, CONNECT_RESP + and SELECT_B_PROTOCOL_REQ) + +Only those parameters appearing in the message type currently being processed +are actually used. Unused members should be set to zero. Members are named after the CAPI 2.0 standard names of the parameters they represent. See <linux/isdn/capiutil.h> for the exact spelling. Member data @@ -190,18 +217,19 @@ u16 for CAPI parameters of type 'word' u32 for CAPI parameters of type 'dword' -_cstruct for CAPI parameters of type 'struct' not containing any - variably-sized (struct) subparameters (eg. 'Called Party Number') +_cstruct for CAPI parameters of type 'struct' The member is a pointer to a buffer containing the parameter in CAPI encoding (length + content). It may also be NULL, which will be taken to represent an empty (zero length) parameter. + Subparameters are stored in encoded form within the content part. -_cmstruct for CAPI parameters of type 'struct' containing 'struct' - subparameters ('Additional Info' and 'B Protocol') +_cmstruct alternative representation for CAPI parameters of type 'struct' + (used only for the 'Additional Info' and 'B Protocol' parameters) The representation is a single byte containing one of the values: - CAPI_DEFAULT: the parameter is empty - CAPI_COMPOSE: the values of the subparameters are stored - individually in the corresponding _cmsg structure members + CAPI_DEFAULT: The parameter is empty/absent. + CAPI_COMPOSE: The parameter is present. + Subparameter values are stored individually in the corresponding + _cmsg structure members. Functions capi_cmsg2message() and capi_message2cmsg() are provided to convert messages between their transport encoding described in the CAPI 2.0 standard @@ -297,3 +325,26 @@ char *capi_cmd2str(u8 Command, u8 Subcommand) be NULL if the command/subcommand is not one of those defined in the CAPI 2.0 standard. + +7. Debugging + +The module kernelcapi has a module parameter showcapimsgs controlling some +debugging output produced by the module. It can only be set when the module is +loaded, via a parameter "showcapimsgs=<n>" to the modprobe command, either on +the command line or in the configuration file. + +If the lowest bit of showcapimsgs is set, kernelcapi logs controller and +application up and down events. + +In addition, every registered CAPI controller has an associated traceflag +parameter controlling how CAPI messages sent from and to tha controller are +logged. The traceflag parameter is initialized with the value of the +showcapimsgs parameter when the controller is registered, but can later be +changed via the MANUFACTURER_REQ command KCAPI_CMD_TRACE. + +If the value of traceflag is non-zero, CAPI messages are logged. +DATA_B3 messages are only logged if the value of traceflag is > 2. + +If the lowest bit of traceflag is set, only the command/subcommand and message +length are logged. Otherwise, kernelcapi logs a readable representation of +the entire message. diff --git a/Documentation/isdn/README.gigaset b/Documentation/isdn/README.gigaset index f9963103ae3d..794941fc9493 100644 --- a/Documentation/isdn/README.gigaset +++ b/Documentation/isdn/README.gigaset @@ -5,7 +5,7 @@ GigaSet 307x Device Driver ------------ 1.1. Hardware -------- - This release supports the connection of the Gigaset 307x/417x family of + This driver supports the connection of the Gigaset 307x/417x family of ISDN DECT bases via Gigaset M101 Data, Gigaset M105 Data or direct USB connection. The following devices are reported to be compatible: @@ -33,7 +33,7 @@ GigaSet 307x Device Driver http://gigaset307x.sourceforge.net/ We had also reports from users of Gigaset M105 who could use the drivers - with SX 100 and CX 100 ISDN bases (only in unimodem mode, see section 2.4.) + with SX 100 and CX 100 ISDN bases (only in unimodem mode, see section 2.5.) If you have another device that works with our driver, please let us know. Chances of getting an USB device to work are good if the output of @@ -49,7 +49,7 @@ GigaSet 307x Device Driver -------- The driver works with ISDN4linux and so can be used with any software which is able to use ISDN4linux for ISDN connections (voice or data). - CAPI4Linux support is planned but not yet available. + Experimental Kernel CAPI support is available as a compilation option. There are some user space tools available at http://sourceforge.net/projects/gigaset307x/ @@ -68,22 +68,38 @@ GigaSet 307x Device Driver for troubleshooting or to pass module parameters. The module ser_gigaset provides a serial line discipline N_GIGASET_M101 - which drives the device through the regular serial line driver. It must - be attached to the serial line to which the M101 is connected with the - ldattach(8) command (requires util-linux-ng release 2.14 or later), for - example: - ldattach GIGASET_M101 /dev/ttyS1 + which uses the regular serial port driver to access the device, and must + therefore be attached to the serial device to which the M101 is connected. + The ldattach(8) command (included in util-linux-ng release 2.14 or later) + can be used for that purpose, for example: + ldattach GIGASET_M101 /dev/ttyS1 This will open the device file, attach the line discipline to it, and then sleep in the background, keeping the device open so that the line discipline remains active. To deactivate it, kill the daemon, for example with - killall ldattach + killall ldattach before disconnecting the device. To have this happen automatically at system startup/shutdown on an LSB compatible system, create and activate an appropriate LSB startup script /etc/init.d/gigaset. (The init name 'gigaset' is officially assigned to this project by LANANA.) Alternatively, just add the 'ldattach' command line to /etc/rc.local. + The modules accept the following parameters: + + Module Parameter Meaning + + gigaset debug debug level (see section 3.2.) + + startmode initial operation mode (see section 2.5.): + bas_gigaset ) 1=ISDN4linux/CAPI (default), 0=Unimodem + ser_gigaset ) + usb_gigaset ) cidmode initial Call-ID mode setting (see section + 2.5.): 1=on (default), 0=off + + Depending on your distribution you may want to create a separate module + configuration file /etc/modprobe.d/gigaset for these, or add them to a + custom file like /etc/modprobe.conf.local. + 2.2. Device nodes for user space programs ------------------------------------ The device can be accessed from user space (eg. by the user space tools @@ -93,29 +109,83 @@ GigaSet 307x Device Driver - /dev/ttyGU0 for M105 (USB data boxes) - /dev/ttyGB0 for the base driver (direct USB connection) - You can also select a "default device" which is used by the frontends when + If you connect more than one device of a type, they will get consecutive + device nodes, eg. /dev/ttyGU1 for a second M105. + + You can also set a "default device" for the user space tools to use when no device node is given as parameter, by creating a symlink /dev/ttyG to one of them, eg.: - ln -s /dev/ttyGB0 /dev/ttyG + ln -s /dev/ttyGB0 /dev/ttyG + + The devices accept the following device specific ioctl calls + (defined in gigaset_dev.h): + + ioctl(int fd, GIGASET_REDIR, int *cmd); + If cmd==1, the device is set to be controlled exclusively through the + character device node; access from the ISDN subsystem is blocked. + If cmd==0, the device is set to be used from the ISDN subsystem and does + not communicate through the character device node. + + ioctl(int fd, GIGASET_CONFIG, int *cmd); + (ser_gigaset and usb_gigaset only) + If cmd==1, the device is set to adapter configuration mode where commands + are interpreted by the M10x DECT adapter itself instead of being + forwarded to the base station. In this mode, the device accepts the + commands described in Siemens document "AT-Kommando Alignment M10x Data" + for setting the operation mode, associating with a base station and + querying parameters like field strengh and signal quality. + Note that there is no ioctl command for leaving adapter configuration + mode and returning to regular operation. In order to leave adapter + configuration mode, write the command ATO to the device. + + ioctl(int fd, GIGASET_BRKCHARS, unsigned char brkchars[6]); + (usb_gigaset only) + Set the break characters on an M105's internal serial adapter to the six + bytes stored in brkchars[]. Unused bytes should be set to zero. + + ioctl(int fd, GIGASET_VERSION, unsigned version[4]); + Retrieve version information from the driver. version[0] must be set to + one of: + - GIGVER_DRIVER: retrieve driver version + - GIGVER_COMPAT: retrieve interface compatibility version + - GIGVER_FWBASE: retrieve the firmware version of the base + Upon return, version[] is filled with the requested version information. 2.3. ISDN4linux ---------- This is the "normal" mode of operation. After loading the module you can - set up the ISDN system just as you'd do with any ISDN card. - Your distribution should provide some configuration utility. - If not, you can use some HOWTOs like + set up the ISDN system just as you'd do with any ISDN card supported by + the ISDN4Linux subsystem. Most distributions provide some configuration + utility. If not, you can use some HOWTOs like http://www.linuxhaven.de/dlhp/HOWTO/DE-ISDN-HOWTO-5.html - If this doesn't work, because you have some recent device like SX100 where + If this doesn't work, because you have some device like SX100 where debug output (see section 3.2.) shows something like this when dialing CMD Received: ERROR Available Params: 0 Connection State: 0, Response: -1 gigaset_process_response: resp_code -1 in ConState 0 ! Timeout occurred - you might need to use unimodem mode: - -2.4. Unimodem mode + you probably need to use unimodem mode. (see section 2.5.) + +2.4. CAPI + ---- + If the driver is compiled with CAPI support (kernel configuration option + GIGASET_CAPI, experimental) it can also be used with CAPI 2.0 kernel and + user space applications. For user space access, the module capi.ko must + be loaded. The capiinit command (included in the capi4k-utils package) + does this for you. + + The CAPI variant of the driver supports legacy ISDN4Linux applications + via the capidrv compatibility driver. The kernel module capidrv.ko must + be loaded explicitly with the command + modprobe capidrv + if needed, and cannot be unloaded again without unloading the driver + first. (These are limitations of capidrv.) + + The note about unimodem mode in the preceding section applies here, too. + +2.5. Unimodem mode ------------- This is needed for some devices [e.g. SX100] as they have problems with the "normal" commands. @@ -126,9 +196,14 @@ GigaSet 307x Device Driver You can switch back using gigacontr --mode isdn - You can also load the driver using e.g. - modprobe usb_gigaset startmode=0 - to prevent the driver from starting in "isdn4linux mode". + You can also put the driver directly into Unimodem mode when it's loaded, + by passing the module parameter startmode=0 to the hardware specific + module, e.g. + modprobe usb_gigaset startmode=0 + or by adding a line like + options usb_gigaset startmode=0 + to an appropriate module configuration file, like /etc/modprobe.d/gigaset + or /etc/modprobe.conf.local. In this mode the device works like a modem connected to a serial port (the /dev/ttyGU0, ... mentioned above) which understands the commands @@ -156,11 +231,10 @@ GigaSet 307x Device Driver options ppp_async flag_time=0 - to /etc/modprobe.conf. If your distribution has some local module - configuration file like /etc/modprobe.conf.local, - using that should be preferred. + to an appropriate module configuration file, like /etc/modprobe.d/gigaset + or /etc/modprobe.conf.local. -2.5. Call-ID (CID) mode +2.6. Call-ID (CID) mode ------------------ Call-IDs are numbers used to tag commands to, and responses from, the Gigaset base in order to support the simultaneous handling of multiple @@ -181,14 +255,15 @@ GigaSet 307x Device Driver settings (CID mode). - If you have several DECT data devices (M10x) which you want to use in turn, select Unimodem mode by passing the parameter "cidmode=0" to - the driver ("modprobe usb_gigaset cidmode=0" or modprobe.conf). + the appropriate driver module (ser_gigaset or usb_gigaset). If you want both of these at once, you are out of luck. - You can also use /sys/class/tty/ttyGxy/cidmode for changing the CID mode - setting (ttyGxy is ttyGU0 or ttyGB0). + You can also use the tty class parameter "cidmode" of the device to + change its CID mode while the driver is loaded, eg. + echo 0 > /sys/class/tty/ttyGU0/cidmode -2.6. Unregistered Wireless Devices (M101/M105) +2.7. Unregistered Wireless Devices (M101/M105) ----------------------------------------- The main purpose of the ser_gigaset and usb_gigaset drivers is to allow the M101 and M105 wireless devices to be used as ISDN devices for ISDN @@ -200,7 +275,7 @@ GigaSet 307x Device Driver driver. In that situation, a restricted set of functions is available which includes, in particular, those necessary for registering the device to a base or for switching it between Fixed Part and Portable Part - modes. + modes. See the gigacontr(8) manpage for details. 3. Troubleshooting --------------- @@ -214,9 +289,7 @@ GigaSet 307x Device Driver options isdn dialtimeout=15 - to /etc/modprobe.conf. If your distribution has some local module - configuration file like /etc/modprobe.conf.local, - using that should be preferred. + to /etc/modprobe.d/gigaset, /etc/modprobe.conf.local or a similar file. Problem: Your isdn script aborts with a message about isdnlog. @@ -228,7 +301,7 @@ GigaSet 307x Device Driver You have two or more DECT data adapters (M101/M105) and only the first one you turn on works. Solution: - Select Unimodem mode for all DECT data adapters. (see section 2.4.) + Select Unimodem mode for all DECT data adapters. (see section 2.5.) Problem: Messages like this: @@ -236,7 +309,7 @@ GigaSet 307x Device Driver appear in your syslog. Solution: Check whether your M10x wireless device is correctly registered to the - Gigaset base. (see section 2.6.) + Gigaset base. (see section 2.7.) 3.2. Telling the driver to provide more information ---------------------------------------------- @@ -256,7 +329,8 @@ GigaSet 307x Device Driver The initial value can be set using the debug parameter when loading the module "gigaset", e.g. by adding a line options gigaset debug=0 - to /etc/modprobe.conf, ... + to your module configuration file, eg. /etc/modprobe.d/gigaset or + /etc/modprobe.conf.local. Generated debugging information can be found - as output of the command diff --git a/Documentation/kbuild/kbuild.txt b/Documentation/kbuild/kbuild.txt index f3355b6812df..6f8c1cabbc5d 100644 --- a/Documentation/kbuild/kbuild.txt +++ b/Documentation/kbuild/kbuild.txt @@ -1,3 +1,17 @@ +Output files + +modules.order +-------------------------------------------------- +This file records the order in which modules appear in Makefiles. This +is used by modprobe to deterministically resolve aliases that match +multiple modules. + +modules.builtin +-------------------------------------------------- +This file lists all modules that are built into the kernel. This is used +by modprobe to not fail when trying to load something builtin. + + Environment variables KCPPFLAGS @@ -65,6 +79,22 @@ INSTALL_PATH INSTALL_PATH specifies where to place the updated kernel and system map images. Default is /boot, but you can set it to other values. +INSTALLKERNEL +-------------------------------------------------- +Install script called when using "make install". +The default name is "installkernel". + +The script will be called with the following arguments: + $1 - kernel version + $2 - kernel image file + $3 - kernel map file + $4 - default install path (use root directory if blank) + +The implmentation of "make install" is architecture specific +and it may differ from the above. + +INSTALLKERNEL is provided to enable the possibility to +specify a custom installer when cross compiling a kernel. MODLIB -------------------------------------------------- diff --git a/Documentation/kbuild/kconfig.txt b/Documentation/kbuild/kconfig.txt index 849b5e56d06f..49efae703979 100644 --- a/Documentation/kbuild/kconfig.txt +++ b/Documentation/kbuild/kconfig.txt @@ -103,10 +103,16 @@ KCONFIG_AUTOCONFIG This environment variable can be set to specify the path & name of the "auto.conf" file. Its default value is "include/config/auto.conf". +KCONFIG_TRISTATE +-------------------------------------------------- +This environment variable can be set to specify the path & name of the +"tristate.conf" file. Its default value is "include/config/tristate.conf". + KCONFIG_AUTOHEADER -------------------------------------------------- This environment variable can be set to specify the path & name of the -"autoconf.h" (header) file. Its default value is "include/linux/autoconf.h". +"autoconf.h" (header) file. +Its default value is "include/generated/autoconf.h". ====================================================================== diff --git a/Documentation/kbuild/makefiles.txt b/Documentation/kbuild/makefiles.txt index d76cfd8712e1..71c602d61680 100644 --- a/Documentation/kbuild/makefiles.txt +++ b/Documentation/kbuild/makefiles.txt @@ -18,6 +18,7 @@ This document describes the Linux kernel Makefiles. --- 3.9 Dependency tracking --- 3.10 Special Rules --- 3.11 $(CC) support functions + --- 3.12 $(LD) support functions === 4 Host Program support --- 4.1 Simple Host Program @@ -435,14 +436,14 @@ more details, with real examples. The second argument is optional, and if supplied will be used if first argument is not supported. - ld-option - ld-option is used to check if $(CC) when used to link object files + cc-ldoption + cc-ldoption is used to check if $(CC) when used to link object files supports the given option. An optional second option may be specified if first option are not supported. Example: #arch/i386/kernel/Makefile - vsyscall-flags += $(call ld-option, -Wl$(comma)--hash-style=sysv) + vsyscall-flags += $(call cc-ldoption, -Wl$(comma)--hash-style=sysv) In the above example, vsyscall-flags will be assigned the option -Wl$(comma)--hash-style=sysv if it is supported by $(CC). @@ -570,6 +571,19 @@ more details, with real examples. endif endif +--- 3.12 $(LD) support functions + + ld-option + ld-option is used to check if $(LD) supports the supplied option. + ld-option takes two options as arguments. + The second argument is an optional option that can be used if the + first option is not supported by $(LD). + + Example: + #Makefile + LDFLAGS_vmlinux += $(call really-ld-option, -X) + + === 4 Host Program support Kbuild supports building executables on the host for use during the diff --git a/Documentation/kernel-doc-nano-HOWTO.txt b/Documentation/kernel-doc-nano-HOWTO.txt index 4d04572b6549..27a52b35d55b 100644 --- a/Documentation/kernel-doc-nano-HOWTO.txt +++ b/Documentation/kernel-doc-nano-HOWTO.txt @@ -66,7 +66,9 @@ Example kernel-doc function comment: * The longer description can have multiple paragraphs. */ -The first line, with the short description, must be on a single line. +The short description following the subject can span multiple lines +and ends with an @argument description, an empty line or the end of +the comment block. The @argument descriptions must begin on the very next line following this opening short function description line, with no intervening @@ -212,11 +214,13 @@ The format of the block comment is like this: * (section header: (section description)? )* (*)?*/ -The short function description ***cannot be multiline***, but the other -descriptions can be (and they can contain blank lines). If you continue -that initial short description onto a second line, that second line will -appear further down at the beginning of the description section, which is -almost certainly not what you had in mind. +All "description" text can span multiple lines, although the +function_name & its short description are traditionally on a single line. +Description text may also contain blank lines (i.e., lines that contain +only a "*"). + +"section header:" names must be unique per function (or struct, +union, typedef, enum). Avoid putting a spurious blank line after the function name, or else the description will be repeated! diff --git a/Documentation/kernel-parameters.txt b/Documentation/kernel-parameters.txt index 8e91863190e8..826b6e148316 100644 --- a/Documentation/kernel-parameters.txt +++ b/Documentation/kernel-parameters.txt @@ -57,6 +57,7 @@ parameter is applicable: ISAPNP ISA PnP code is enabled. ISDN Appropriate ISDN support is enabled. JOY Appropriate joystick support is enabled. + KVM Kernel Virtual Machine support is enabled. LIBATA Libata driver is enabled LP Printer support is enabled. LOOP Loopback device support is enabled. @@ -84,7 +85,6 @@ parameter is applicable: PPT Parallel port support is enabled. PS2 Appropriate PS/2 support is enabled. RAM RAM disk support is enabled. - ROOTPLUG The example Root Plug LSM is enabled. S390 S390 architecture is enabled. SCSI Appropriate SCSI support is enabled. A lot of drivers has their options described inside of @@ -199,6 +199,10 @@ and is between 256 and 4096 characters. It is defined in the file acpi_display_output=video See above. + acpi_early_pdc_eval [HW,ACPI] Evaluate processor _PDC methods + early. Needed on some platforms to properly + initialize the EC. + acpi_irq_balance [HW,ACPI] ACPI will balance active IRQs default in APIC mode @@ -240,7 +244,7 @@ and is between 256 and 4096 characters. It is defined in the file acpi_sleep= [HW,ACPI] Sleep options Format: { s3_bios, s3_mode, s3_beep, s4_nohwsig, - old_ordering, s4_nonvs } + old_ordering, s4_nonvs, sci_force_enable } See Documentation/power/video.txt for information on s3_bios and s3_mode. s3_beep is for debugging; it makes the PC's speaker beep @@ -253,6 +257,9 @@ and is between 256 and 4096 characters. It is defined in the file of _PTS is used by default). s4_nonvs prevents the kernel from saving/restoring the ACPI NVS memory during hibernation. + sci_force_enable causes the kernel to set SCI_EN directly + on resume from S1/S3 (which is against the ACPI spec, + but some broken systems don't work without it). acpi_use_timer_override [HW,ACPI] Use timer override. For some broken Nvidia NF5 boards @@ -344,6 +351,15 @@ and is between 256 and 4096 characters. It is defined in the file Change the amount of debugging information output when initialising the APIC and IO-APIC components. + show_lapic= [APIC,X86] Advanced Programmable Interrupt Controller + Limit apic dumping. The parameter defines the maximal + number of local apics being dumped. Also it is possible + to set it to "all" by meaning -- no limit here. + Format: { 1 (default) | 2 | ... | all }. + The parameter valid if only apic=debug or + apic=verbose is specified. + Example: apic=debug show_lapic=all + apm= [APM] Advanced Power Management See header of arch/x86/kernel/apm_32.c. @@ -670,7 +686,8 @@ and is between 256 and 4096 characters. It is defined in the file earlyprintk= [X86,SH,BLACKFIN] earlyprintk=vga earlyprintk=serial[,ttySn[,baudrate]] - earlyprintk=dbgp + earlyprintk=ttySn[,baudrate] + earlyprintk=dbgp[debugController#] Append ",keep" to not disable it when the real console takes over. @@ -777,6 +794,13 @@ and is between 256 and 4096 characters. It is defined in the file by the set_ftrace_notrace file in the debugfs tracing directory. + ftrace_graph_filter=[function-list] + [FTRACE] Limit the top level callers functions traced + by the function graph tracer at boot up. + function-list is a comma separated list of functions + that can be changed at run time by the + set_graph_function file in the debugfs tracing directory. + gamecon.map[2|3]= [HW,JOY] Multisystem joystick and NES/SNES/PSX pad support via parallel port (up to 5 devices per port) @@ -932,7 +956,7 @@ and is between 256 and 4096 characters. It is defined in the file 1 -- enable informational integrity auditing messages. ima_hash= [IMA] - Formt: { "sha1" | "md5" } + Format: { "sha1" | "md5" } default: "sha1" ima_tcb [IMA] @@ -1015,7 +1039,7 @@ and is between 256 and 4096 characters. It is defined in the file No delay ip= [IP_PNP] - See Documentation/filesystems/nfsroot.txt. + See Documentation/filesystems/nfs/nfsroot.txt. ip2= [HW] Set IO/IRQ pairs for up to 4 IntelliPort boards See comment before ip2_setup() in @@ -1098,6 +1122,44 @@ and is between 256 and 4096 characters. It is defined in the file kstack=N [X86] Print N words from the kernel stack in oops dumps. + kvm.ignore_msrs=[KVM] Ignore guest accesses to unhandled MSRs. + Default is 0 (don't ignore, but inject #GP) + + kvm.oos_shadow= [KVM] Disable out-of-sync shadow paging. + Default is 1 (enabled) + + kvm-amd.nested= [KVM,AMD] Allow nested virtualization in KVM/SVM. + Default is 0 (off) + + kvm-amd.npt= [KVM,AMD] Disable nested paging (virtualized MMU) + for all guests. + Default is 1 (enabled) if in 64bit or 32bit-PAE mode + + kvm-intel.bypass_guest_pf= + [KVM,Intel] Disables bypassing of guest page faults + on Intel chips. Default is 1 (enabled) + + kvm-intel.ept= [KVM,Intel] Disable extended page tables + (virtualized MMU) support on capable Intel chips. + Default is 1 (enabled) + + kvm-intel.emulate_invalid_guest_state= + [KVM,Intel] Enable emulation of invalid guest states + Default is 0 (disabled) + + kvm-intel.flexpriority= + [KVM,Intel] Disable FlexPriority feature (TPR shadow). + Default is 1 (enabled) + + kvm-intel.unrestricted_guest= + [KVM,Intel] Disable unrestricted guest feature + (virtualized real and unpaged mode) on capable + Intel chips. Default is 1 (enabled) + + kvm-intel.vpid= [KVM,Intel] Disable Virtual Processor Identification + feature (tagged TLBs) on capable Intel chips. + Default is 1 (enabled) + l2cr= [PPC] l3cr= [PPC] @@ -1247,6 +1309,10 @@ and is between 256 and 4096 characters. It is defined in the file (machvec) in a generic kernel. Example: machvec=hpzx1_swiotlb + machtype= [Loongson] Share the same kernel image file between different + yeeloong laptop. + Example: machtype=lemote-yeeloong-2f-7inch + max_addr=nn[KMG] [KNL,BOOT,ia64] All physical memory greater than or equal to this physical address is ignored. @@ -1494,15 +1560,23 @@ and is between 256 and 4096 characters. It is defined in the file going to be removed in 2.6.29. nfsaddrs= [NFS] - See Documentation/filesystems/nfsroot.txt. + See Documentation/filesystems/nfs/nfsroot.txt. nfsroot= [NFS] nfs root filesystem for disk-less boxes. - See Documentation/filesystems/nfsroot.txt. + See Documentation/filesystems/nfs/nfsroot.txt. nfs.callback_tcpport= [NFS] set the TCP port on which the NFSv4 callback channel should listen. + nfs.cache_getent= + [NFS] sets the pathname to the program which is used + to update the NFS client cache entries. + + nfs.cache_getent_timeout= + [NFS] sets the timeout after which an attempt to + update a cache entry is deemed to have failed. + nfs.idmap_cache_timeout= [NFS] set the maximum lifetime for idmapper cache entries. @@ -1514,7 +1588,7 @@ and is between 256 and 4096 characters. It is defined in the file of returning the full 64-bit number. The default is to return 64-bit inode numbers. - nmi_debug= [KNL,AVR32] Specify one or more actions to take + nmi_debug= [KNL,AVR32,SH] Specify one or more actions to take when a NMI is triggered. Format: [state][,regs][,debounce][,die] @@ -1535,6 +1609,11 @@ and is between 256 and 4096 characters. It is defined in the file symbolic names: lapic and ioapic Example: nmi_watchdog=2 or nmi_watchdog=panic,lapic + netpoll.carrier_timeout= + [NET] Specifies amount of time (in seconds) that + netpoll should wait for a carrier. By default netpoll + waits 4 seconds. + no387 [BUGS=X86-32] Tells the kernel to use the 387 maths emulation library even if a 387 maths coprocessor is present. @@ -1715,6 +1794,11 @@ and is between 256 and 4096 characters. It is defined in the file waiting for the ACK, so if this is set too high interrupts *may* be lost! + omap_mux= [OMAP] Override bootloader pin multiplexing. + Format: <mux_mode0.mode_name=value>... + For example, to override I2C bus2: + omap_mux=i2c2_scl.i2c2_scl=0x100,i2c2_sda.i2c2_sda=0x100 + opl3= [HW,OSS] Format: <io> @@ -1919,11 +2003,12 @@ and is between 256 and 4096 characters. It is defined in the file Format: { 0 | 1 } See arch/parisc/kernel/pdc_chassis.c - percpu_alloc= [X86] Select which percpu first chunk allocator to use. - Allowed values are one of "lpage", "embed" and "4k". - See comments in arch/x86/kernel/setup_percpu.c for - details on each allocator. This parameter is primarily - for debugging and performance comparison. + percpu_alloc= Select which percpu first chunk allocator to use. + Currently supported values are "embed" and "page". + Archs may support subset or none of the selections. + See comments in mm/percpu.c for details on each + allocator. This parameter is primarily for debugging + and performance comparison. pf. [PARIDE] See Documentation/blockdev/paride.txt. @@ -1974,8 +2059,15 @@ and is between 256 and 4096 characters. It is defined in the file print-fatal-signals= [KNL] debug: print fatal signals - print-fatal-signals=1: print segfault info to - the kernel console. + + If enabled, warn about various signal handling + related application anomalies: too many signals, + too many POSIX.1 timers, fatal signals causing a + coredump - etc. + + If you hit the warning due to signal overflow, + you might want to try "ulimit -i unlimited". + default: off. printk.time= Show timing data prefixed to each printk message line @@ -2106,15 +2198,6 @@ and is between 256 and 4096 characters. It is defined in the file Useful for devices that are detected asynchronously (e.g. USB and MMC devices). - root_plug.vendor_id= - [ROOTPLUG] Override the default vendor ID - - root_plug.product_id= - [ROOTPLUG] Override the default product ID - - root_plug.debug= - [ROOTPLUG] Enable debugging output - rw [KNL] Mount root device read-write on boot S [KNL] Run init in single mode @@ -2124,6 +2207,8 @@ and is between 256 and 4096 characters. It is defined in the file sbni= [NET] Granch SBNI12 leased line adapter + sched_debug [KNL] Enables verbose scheduler debug messages. + sc1200wdt= [HW,WDT] SC1200 WDT (watchdog) driver Format: <io>[,<timeout>[,<isapnp>]] @@ -2395,6 +2480,18 @@ and is between 256 and 4096 characters. It is defined in the file stifb= [HW] Format: bpp:<bpp1>[:<bpp2>[:<bpp3>...]] + sunrpc.min_resvport= + sunrpc.max_resvport= + [NFS,SUNRPC] + SunRPC servers often require that client requests + originate from a privileged port (i.e. a port in the + range 0 < portnr < 1024). + An administrator who wishes to reserve some of these + ports for other uses may adjust the range that the + kernel's sunrpc client considers to be privileged + using these two parameters to set the minimum and + maximum port values. + sunrpc.pool_mode= [NFS] Control how the NFS server code allocates CPUs to @@ -2411,6 +2508,15 @@ and is between 256 and 4096 characters. It is defined in the file pernode one pool for each NUMA node (equivalent to global on non-NUMA machines) + sunrpc.tcp_slot_table_entries= + sunrpc.udp_slot_table_entries= + [NFS,SUNRPC] + Sets the upper limit on the number of simultaneous + RPC calls that can be sent from the client to a + server. Increasing these values may allow you to + improve throughput, but will also increase the + amount of memory reserved for use by the client. + swiotlb= [IA-64] Number of I/O TLB slabs switches= [HW,M68k] @@ -2511,6 +2617,9 @@ and is between 256 and 4096 characters. It is defined in the file uart6850= [HW,OSS] Format: <io>,<irq> + uhash_entries= [KNL,NET] + Set number of hash buckets for UDP/UDP-Lite connections + uhci-hcd.ignore_oc= [USB] Ignore overcurrent events (default N). Some badly-designed motherboards generate lots of @@ -2566,6 +2675,8 @@ and is between 256 and 4096 characters. It is defined in the file to a common usb-storage quirk flag as follows: a = SANE_SENSE (collect more than 18 bytes of sense data); + b = BAD_SENSE (don't collect more than 18 + bytes of sense data); c = FIX_CAPACITY (decrease the reported device capacity by one sector); h = CAPACITY_HEURISTICS (decrease the @@ -2625,6 +2736,11 @@ and is between 256 and 4096 characters. It is defined in the file vmpoff= [KNL,S390] Perform z/VM CP command after power off. Format: <command> + vt.cur_default= [VT] Default cursor shape. + Format: 0xCCBBAA, where AA, BB, and CC are the same as + the parameters of the <Esc>[?A;B;Cc escape sequence; + see VGA-softcursor.txt. Default: 2 = underline. + vt.default_blu= [VT] Format: <blue0>,<blue1>,<blue2>,...,<blue15> Change the default blue palette of the console. @@ -2650,6 +2766,15 @@ and is between 256 and 4096 characters. It is defined in the file Default is 1, i.e. UTF-8 mode is enabled for all newly opened terminals. + vt.global_cursor_default= + [VT] + Format=<-1|0|1> + Set system-wide default for whether a cursor + is shown on new VTs. Default is -1, + i.e. cursors will be created by default unless + overridden by individual drivers. 0 will hide + cursors, 1 will display them. + waveartist= [HW,OSS] Format: <io>,<irq>,<dma>,<dma2> diff --git a/Documentation/keys.txt b/Documentation/keys.txt index b56aacc1fff8..e4dbbdb1bd96 100644 --- a/Documentation/keys.txt +++ b/Documentation/keys.txt @@ -26,7 +26,7 @@ This document has the following sections: - Notes on accessing payload contents - Defining a key type - Request-key callback service - - Key access filesystem + - Garbage collection ============ @@ -113,6 +113,9 @@ Each key has a number of attributes: (*) Dead. The key's type was unregistered, and so the key is now useless. +Keys in the last three states are subject to garbage collection. See the +section on "Garbage collection". + ==================== KEY SERVICE OVERVIEW @@ -754,6 +757,26 @@ The keyctl syscall functions are: successful. + (*) Install the calling process's session keyring on its parent. + + long keyctl(KEYCTL_SESSION_TO_PARENT); + + This functions attempts to install the calling process's session keyring + on to the calling process's parent, replacing the parent's current session + keyring. + + The calling process must have the same ownership as its parent, the + keyring must have the same ownership as the calling process, the calling + process must have LINK permission on the keyring and the active LSM module + mustn't deny permission, otherwise error EPERM will be returned. + + Error ENOMEM will be returned if there was insufficient memory to complete + the operation, otherwise 0 will be returned to indicate success. + + The keyring will be replaced next time the parent process leaves the + kernel and resumes executing userspace. + + =============== KERNEL SERVICES =============== @@ -1231,3 +1254,17 @@ by executing: In this case, the program isn't required to actually attach the key to a ring; the rings are provided for reference. + + +================== +GARBAGE COLLECTION +================== + +Dead keys (for which the type has been removed) will be automatically unlinked +from those keyrings that point to them and deleted as soon as possible by a +background garbage collector. + +Similarly, revoked and expired keys will be garbage collected, but only after a +certain amount of time has passed. This time is set as a number of seconds in: + + /proc/sys/kernel/keys/gc_delay diff --git a/Documentation/kmemcheck.txt b/Documentation/kmemcheck.txt index 363044609dad..c28f82895d6b 100644 --- a/Documentation/kmemcheck.txt +++ b/Documentation/kmemcheck.txt @@ -43,26 +43,7 @@ feature. 1. Downloading ============== -kmemcheck can only be downloaded using git. If you want to write patches -against the current code, you should use the kmemcheck development branch of -the tip tree. It is also possible to use the linux-next tree, which also -includes the latest version of kmemcheck. - -Assuming that you've already cloned the linux-2.6.git repository, all you -have to do is add the -tip tree as a remote, like this: - - $ git remote add tip git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip.git - -To actually download the tree, fetch the remote: - - $ git fetch tip - -And to check out a new local branch with the kmemcheck code: - - $ git checkout -b kmemcheck tip/kmemcheck - -General instructions for the -tip tree can be found here: -http://people.redhat.com/mingo/tip.git/readme.txt +As of version 2.6.31-rc1, kmemcheck is included in the mainline kernel. 2. Configuring and compiling diff --git a/Documentation/kmemleak.txt b/Documentation/kmemleak.txt index 89068030b01b..34f6638aa5ac 100644 --- a/Documentation/kmemleak.txt +++ b/Documentation/kmemleak.txt @@ -27,6 +27,13 @@ To trigger an intermediate memory scan: # echo scan > /sys/kernel/debug/kmemleak +To clear the list of all current possible memory leaks: + + # echo clear > /sys/kernel/debug/kmemleak + +New leaks will then come up upon reading /sys/kernel/debug/kmemleak +again. + Note that the orphan objects are listed in the order they were allocated and one object at the beginning of the list may cause other subsequent objects to be reported as orphan. @@ -42,6 +49,9 @@ Memory scanning parameters can be modified at run-time by writing to the scan=<secs> - set the automatic memory scanning period in seconds (default 600, 0 to stop the automatic scanning) scan - trigger a memory scan + clear - clear list of current memory leak suspects, done by + marking all current reported unreferenced objects grey + dump=<addr> - dump information about the object found at <addr> Kmemleak can also be disabled at boot-time by passing "kmemleak=off" on the kernel command line. @@ -86,6 +96,27 @@ avoid this, kmemleak can also store the number of values pointing to an address inside the block address range that need to be found so that the block is not considered a leak. One example is __vmalloc(). +Testing specific sections with kmemleak +--------------------------------------- + +Upon initial bootup your /sys/kernel/debug/kmemleak output page may be +quite extensive. This can also be the case if you have very buggy code +when doing development. To work around these situations you can use the +'clear' command to clear all reported unreferenced objects from the +/sys/kernel/debug/kmemleak output. By issuing a 'scan' after a 'clear' +you can find new unreferenced objects; this should help with testing +specific sections of code. + +To test a critical section on demand with a clean kmemleak do: + + # echo clear > /sys/kernel/debug/kmemleak + ... test your kernel or modules ... + # echo scan > /sys/kernel/debug/kmemleak + +Then as usual to get your report with: + + # cat /sys/kernel/debug/kmemleak + Kmemleak API ------------ diff --git a/Documentation/kref.txt b/Documentation/kref.txt index 130b6e87aa7e..ae203f91ee9b 100644 --- a/Documentation/kref.txt +++ b/Documentation/kref.txt @@ -84,7 +84,6 @@ int my_data_handler(void) task = kthread_run(more_data_handling, data, "more_data_handling"); if (task == ERR_PTR(-ENOMEM)) { rv = -ENOMEM; - kref_put(&data->refcount, data_release); goto out; } diff --git a/Documentation/kvm/api.txt b/Documentation/kvm/api.txt new file mode 100644 index 000000000000..2811e452f756 --- /dev/null +++ b/Documentation/kvm/api.txt @@ -0,0 +1,876 @@ +The Definitive KVM (Kernel-based Virtual Machine) API Documentation +=================================================================== + +1. General description + +The kvm API is a set of ioctls that are issued to control various aspects +of a virtual machine. The ioctls belong to three classes + + - System ioctls: These query and set global attributes which affect the + whole kvm subsystem. In addition a system ioctl is used to create + virtual machines + + - VM ioctls: These query and set attributes that affect an entire virtual + machine, for example memory layout. In addition a VM ioctl is used to + create virtual cpus (vcpus). + + Only run VM ioctls from the same process (address space) that was used + to create the VM. + + - vcpu ioctls: These query and set attributes that control the operation + of a single virtual cpu. + + Only run vcpu ioctls from the same thread that was used to create the + vcpu. + +2. File descritpors + +The kvm API is centered around file descriptors. An initial +open("/dev/kvm") obtains a handle to the kvm subsystem; this handle +can be used to issue system ioctls. A KVM_CREATE_VM ioctl on this +handle will create a VM file descripror which can be used to issue VM +ioctls. A KVM_CREATE_VCPU ioctl on a VM fd will create a virtual cpu +and return a file descriptor pointing to it. Finally, ioctls on a vcpu +fd can be used to control the vcpu, including the important task of +actually running guest code. + +In general file descriptors can be migrated among processes by means +of fork() and the SCM_RIGHTS facility of unix domain socket. These +kinds of tricks are explicitly not supported by kvm. While they will +not cause harm to the host, their actual behavior is not guaranteed by +the API. The only supported use is one virtual machine per process, +and one vcpu per thread. + +3. Extensions + +As of Linux 2.6.22, the KVM ABI has been stabilized: no backward +incompatible change are allowed. However, there is an extension +facility that allows backward-compatible extensions to the API to be +queried and used. + +The extension mechanism is not based on on the Linux version number. +Instead, kvm defines extension identifiers and a facility to query +whether a particular extension identifier is available. If it is, a +set of ioctls is available for application use. + +4. API description + +This section describes ioctls that can be used to control kvm guests. +For each ioctl, the following information is provided along with a +description: + + Capability: which KVM extension provides this ioctl. Can be 'basic', + which means that is will be provided by any kernel that supports + API version 12 (see section 4.1), or a KVM_CAP_xyz constant, which + means availability needs to be checked with KVM_CHECK_EXTENSION + (see section 4.4). + + Architectures: which instruction set architectures provide this ioctl. + x86 includes both i386 and x86_64. + + Type: system, vm, or vcpu. + + Parameters: what parameters are accepted by the ioctl. + + Returns: the return value. General error numbers (EBADF, ENOMEM, EINVAL) + are not detailed, but errors with specific meanings are. + +4.1 KVM_GET_API_VERSION + +Capability: basic +Architectures: all +Type: system ioctl +Parameters: none +Returns: the constant KVM_API_VERSION (=12) + +This identifies the API version as the stable kvm API. It is not +expected that this number will change. However, Linux 2.6.20 and +2.6.21 report earlier versions; these are not documented and not +supported. Applications should refuse to run if KVM_GET_API_VERSION +returns a value other than 12. If this check passes, all ioctls +described as 'basic' will be available. + +4.2 KVM_CREATE_VM + +Capability: basic +Architectures: all +Type: system ioctl +Parameters: none +Returns: a VM fd that can be used to control the new virtual machine. + +The new VM has no virtual cpus and no memory. An mmap() of a VM fd +will access the virtual machine's physical address space; offset zero +corresponds to guest physical address zero. Use of mmap() on a VM fd +is discouraged if userspace memory allocation (KVM_CAP_USER_MEMORY) is +available. + +4.3 KVM_GET_MSR_INDEX_LIST + +Capability: basic +Architectures: x86 +Type: system +Parameters: struct kvm_msr_list (in/out) +Returns: 0 on success; -1 on error +Errors: + E2BIG: the msr index list is to be to fit in the array specified by + the user. + +struct kvm_msr_list { + __u32 nmsrs; /* number of msrs in entries */ + __u32 indices[0]; +}; + +This ioctl returns the guest msrs that are supported. The list varies +by kvm version and host processor, but does not change otherwise. The +user fills in the size of the indices array in nmsrs, and in return +kvm adjusts nmsrs to reflect the actual number of msrs and fills in +the indices array with their numbers. + +4.4 KVM_CHECK_EXTENSION + +Capability: basic +Architectures: all +Type: system ioctl +Parameters: extension identifier (KVM_CAP_*) +Returns: 0 if unsupported; 1 (or some other positive integer) if supported + +The API allows the application to query about extensions to the core +kvm API. Userspace passes an extension identifier (an integer) and +receives an integer that describes the extension availability. +Generally 0 means no and 1 means yes, but some extensions may report +additional information in the integer return value. + +4.5 KVM_GET_VCPU_MMAP_SIZE + +Capability: basic +Architectures: all +Type: system ioctl +Parameters: none +Returns: size of vcpu mmap area, in bytes + +The KVM_RUN ioctl (cf.) communicates with userspace via a shared +memory region. This ioctl returns the size of that region. See the +KVM_RUN documentation for details. + +4.6 KVM_SET_MEMORY_REGION + +Capability: basic +Architectures: all +Type: vm ioctl +Parameters: struct kvm_memory_region (in) +Returns: 0 on success, -1 on error + +struct kvm_memory_region { + __u32 slot; + __u32 flags; + __u64 guest_phys_addr; + __u64 memory_size; /* bytes */ +}; + +/* for kvm_memory_region::flags */ +#define KVM_MEM_LOG_DIRTY_PAGES 1UL + +This ioctl allows the user to create or modify a guest physical memory +slot. When changing an existing slot, it may be moved in the guest +physical memory space, or its flags may be modified. It may not be +resized. Slots may not overlap. + +The flags field supports just one flag, KVM_MEM_LOG_DIRTY_PAGES, which +instructs kvm to keep track of writes to memory within the slot. See +the KVM_GET_DIRTY_LOG ioctl. + +It is recommended to use the KVM_SET_USER_MEMORY_REGION ioctl instead +of this API, if available. This newer API allows placing guest memory +at specified locations in the host address space, yielding better +control and easy access. + +4.6 KVM_CREATE_VCPU + +Capability: basic +Architectures: all +Type: vm ioctl +Parameters: vcpu id (apic id on x86) +Returns: vcpu fd on success, -1 on error + +This API adds a vcpu to a virtual machine. The vcpu id is a small integer +in the range [0, max_vcpus). + +4.7 KVM_GET_DIRTY_LOG (vm ioctl) + +Capability: basic +Architectures: x86 +Type: vm ioctl +Parameters: struct kvm_dirty_log (in/out) +Returns: 0 on success, -1 on error + +/* for KVM_GET_DIRTY_LOG */ +struct kvm_dirty_log { + __u32 slot; + __u32 padding; + union { + void __user *dirty_bitmap; /* one bit per page */ + __u64 padding; + }; +}; + +Given a memory slot, return a bitmap containing any pages dirtied +since the last call to this ioctl. Bit 0 is the first page in the +memory slot. Ensure the entire structure is cleared to avoid padding +issues. + +4.8 KVM_SET_MEMORY_ALIAS + +Capability: basic +Architectures: x86 +Type: vm ioctl +Parameters: struct kvm_memory_alias (in) +Returns: 0 (success), -1 (error) + +struct kvm_memory_alias { + __u32 slot; /* this has a different namespace than memory slots */ + __u32 flags; + __u64 guest_phys_addr; + __u64 memory_size; + __u64 target_phys_addr; +}; + +Defines a guest physical address space region as an alias to another +region. Useful for aliased address, for example the VGA low memory +window. Should not be used with userspace memory. + +4.9 KVM_RUN + +Capability: basic +Architectures: all +Type: vcpu ioctl +Parameters: none +Returns: 0 on success, -1 on error +Errors: + EINTR: an unmasked signal is pending + +This ioctl is used to run a guest virtual cpu. While there are no +explicit parameters, there is an implicit parameter block that can be +obtained by mmap()ing the vcpu fd at offset 0, with the size given by +KVM_GET_VCPU_MMAP_SIZE. The parameter block is formatted as a 'struct +kvm_run' (see below). + +4.10 KVM_GET_REGS + +Capability: basic +Architectures: all +Type: vcpu ioctl +Parameters: struct kvm_regs (out) +Returns: 0 on success, -1 on error + +Reads the general purpose registers from the vcpu. + +/* x86 */ +struct kvm_regs { + /* out (KVM_GET_REGS) / in (KVM_SET_REGS) */ + __u64 rax, rbx, rcx, rdx; + __u64 rsi, rdi, rsp, rbp; + __u64 r8, r9, r10, r11; + __u64 r12, r13, r14, r15; + __u64 rip, rflags; +}; + +4.11 KVM_SET_REGS + +Capability: basic +Architectures: all +Type: vcpu ioctl +Parameters: struct kvm_regs (in) +Returns: 0 on success, -1 on error + +Writes the general purpose registers into the vcpu. + +See KVM_GET_REGS for the data structure. + +4.12 KVM_GET_SREGS + +Capability: basic +Architectures: x86 +Type: vcpu ioctl +Parameters: struct kvm_sregs (out) +Returns: 0 on success, -1 on error + +Reads special registers from the vcpu. + +/* x86 */ +struct kvm_sregs { + struct kvm_segment cs, ds, es, fs, gs, ss; + struct kvm_segment tr, ldt; + struct kvm_dtable gdt, idt; + __u64 cr0, cr2, cr3, cr4, cr8; + __u64 efer; + __u64 apic_base; + __u64 interrupt_bitmap[(KVM_NR_INTERRUPTS + 63) / 64]; +}; + +interrupt_bitmap is a bitmap of pending external interrupts. At most +one bit may be set. This interrupt has been acknowledged by the APIC +but not yet injected into the cpu core. + +4.13 KVM_SET_SREGS + +Capability: basic +Architectures: x86 +Type: vcpu ioctl +Parameters: struct kvm_sregs (in) +Returns: 0 on success, -1 on error + +Writes special registers into the vcpu. See KVM_GET_SREGS for the +data structures. + +4.14 KVM_TRANSLATE + +Capability: basic +Architectures: x86 +Type: vcpu ioctl +Parameters: struct kvm_translation (in/out) +Returns: 0 on success, -1 on error + +Translates a virtual address according to the vcpu's current address +translation mode. + +struct kvm_translation { + /* in */ + __u64 linear_address; + + /* out */ + __u64 physical_address; + __u8 valid; + __u8 writeable; + __u8 usermode; + __u8 pad[5]; +}; + +4.15 KVM_INTERRUPT + +Capability: basic +Architectures: x86 +Type: vcpu ioctl +Parameters: struct kvm_interrupt (in) +Returns: 0 on success, -1 on error + +Queues a hardware interrupt vector to be injected. This is only +useful if in-kernel local APIC is not used. + +/* for KVM_INTERRUPT */ +struct kvm_interrupt { + /* in */ + __u32 irq; +}; + +Note 'irq' is an interrupt vector, not an interrupt pin or line. + +4.16 KVM_DEBUG_GUEST + +Capability: basic +Architectures: none +Type: vcpu ioctl +Parameters: none) +Returns: -1 on error + +Support for this has been removed. Use KVM_SET_GUEST_DEBUG instead. + +4.17 KVM_GET_MSRS + +Capability: basic +Architectures: x86 +Type: vcpu ioctl +Parameters: struct kvm_msrs (in/out) +Returns: 0 on success, -1 on error + +Reads model-specific registers from the vcpu. Supported msr indices can +be obtained using KVM_GET_MSR_INDEX_LIST. + +struct kvm_msrs { + __u32 nmsrs; /* number of msrs in entries */ + __u32 pad; + + struct kvm_msr_entry entries[0]; +}; + +struct kvm_msr_entry { + __u32 index; + __u32 reserved; + __u64 data; +}; + +Application code should set the 'nmsrs' member (which indicates the +size of the entries array) and the 'index' member of each array entry. +kvm will fill in the 'data' member. + +4.18 KVM_SET_MSRS + +Capability: basic +Architectures: x86 +Type: vcpu ioctl +Parameters: struct kvm_msrs (in) +Returns: 0 on success, -1 on error + +Writes model-specific registers to the vcpu. See KVM_GET_MSRS for the +data structures. + +Application code should set the 'nmsrs' member (which indicates the +size of the entries array), and the 'index' and 'data' members of each +array entry. + +4.19 KVM_SET_CPUID + +Capability: basic +Architectures: x86 +Type: vcpu ioctl +Parameters: struct kvm_cpuid (in) +Returns: 0 on success, -1 on error + +Defines the vcpu responses to the cpuid instruction. Applications +should use the KVM_SET_CPUID2 ioctl if available. + + +struct kvm_cpuid_entry { + __u32 function; + __u32 eax; + __u32 ebx; + __u32 ecx; + __u32 edx; + __u32 padding; +}; + +/* for KVM_SET_CPUID */ +struct kvm_cpuid { + __u32 nent; + __u32 padding; + struct kvm_cpuid_entry entries[0]; +}; + +4.20 KVM_SET_SIGNAL_MASK + +Capability: basic +Architectures: x86 +Type: vcpu ioctl +Parameters: struct kvm_signal_mask (in) +Returns: 0 on success, -1 on error + +Defines which signals are blocked during execution of KVM_RUN. This +signal mask temporarily overrides the threads signal mask. Any +unblocked signal received (except SIGKILL and SIGSTOP, which retain +their traditional behaviour) will cause KVM_RUN to return with -EINTR. + +Note the signal will only be delivered if not blocked by the original +signal mask. + +/* for KVM_SET_SIGNAL_MASK */ +struct kvm_signal_mask { + __u32 len; + __u8 sigset[0]; +}; + +4.21 KVM_GET_FPU + +Capability: basic +Architectures: x86 +Type: vcpu ioctl +Parameters: struct kvm_fpu (out) +Returns: 0 on success, -1 on error + +Reads the floating point state from the vcpu. + +/* for KVM_GET_FPU and KVM_SET_FPU */ +struct kvm_fpu { + __u8 fpr[8][16]; + __u16 fcw; + __u16 fsw; + __u8 ftwx; /* in fxsave format */ + __u8 pad1; + __u16 last_opcode; + __u64 last_ip; + __u64 last_dp; + __u8 xmm[16][16]; + __u32 mxcsr; + __u32 pad2; +}; + +4.22 KVM_SET_FPU + +Capability: basic +Architectures: x86 +Type: vcpu ioctl +Parameters: struct kvm_fpu (in) +Returns: 0 on success, -1 on error + +Writes the floating point state to the vcpu. + +/* for KVM_GET_FPU and KVM_SET_FPU */ +struct kvm_fpu { + __u8 fpr[8][16]; + __u16 fcw; + __u16 fsw; + __u8 ftwx; /* in fxsave format */ + __u8 pad1; + __u16 last_opcode; + __u64 last_ip; + __u64 last_dp; + __u8 xmm[16][16]; + __u32 mxcsr; + __u32 pad2; +}; + +4.23 KVM_CREATE_IRQCHIP + +Capability: KVM_CAP_IRQCHIP +Architectures: x86, ia64 +Type: vm ioctl +Parameters: none +Returns: 0 on success, -1 on error + +Creates an interrupt controller model in the kernel. On x86, creates a virtual +ioapic, a virtual PIC (two PICs, nested), and sets up future vcpus to have a +local APIC. IRQ routing for GSIs 0-15 is set to both PIC and IOAPIC; GSI 16-23 +only go to the IOAPIC. On ia64, a IOSAPIC is created. + +4.24 KVM_IRQ_LINE + +Capability: KVM_CAP_IRQCHIP +Architectures: x86, ia64 +Type: vm ioctl +Parameters: struct kvm_irq_level +Returns: 0 on success, -1 on error + +Sets the level of a GSI input to the interrupt controller model in the kernel. +Requires that an interrupt controller model has been previously created with +KVM_CREATE_IRQCHIP. Note that edge-triggered interrupts require the level +to be set to 1 and then back to 0. + +struct kvm_irq_level { + union { + __u32 irq; /* GSI */ + __s32 status; /* not used for KVM_IRQ_LEVEL */ + }; + __u32 level; /* 0 or 1 */ +}; + +4.25 KVM_GET_IRQCHIP + +Capability: KVM_CAP_IRQCHIP +Architectures: x86, ia64 +Type: vm ioctl +Parameters: struct kvm_irqchip (in/out) +Returns: 0 on success, -1 on error + +Reads the state of a kernel interrupt controller created with +KVM_CREATE_IRQCHIP into a buffer provided by the caller. + +struct kvm_irqchip { + __u32 chip_id; /* 0 = PIC1, 1 = PIC2, 2 = IOAPIC */ + __u32 pad; + union { + char dummy[512]; /* reserving space */ + struct kvm_pic_state pic; + struct kvm_ioapic_state ioapic; + } chip; +}; + +4.26 KVM_SET_IRQCHIP + +Capability: KVM_CAP_IRQCHIP +Architectures: x86, ia64 +Type: vm ioctl +Parameters: struct kvm_irqchip (in) +Returns: 0 on success, -1 on error + +Sets the state of a kernel interrupt controller created with +KVM_CREATE_IRQCHIP from a buffer provided by the caller. + +struct kvm_irqchip { + __u32 chip_id; /* 0 = PIC1, 1 = PIC2, 2 = IOAPIC */ + __u32 pad; + union { + char dummy[512]; /* reserving space */ + struct kvm_pic_state pic; + struct kvm_ioapic_state ioapic; + } chip; +}; + +4.27 KVM_XEN_HVM_CONFIG + +Capability: KVM_CAP_XEN_HVM +Architectures: x86 +Type: vm ioctl +Parameters: struct kvm_xen_hvm_config (in) +Returns: 0 on success, -1 on error + +Sets the MSR that the Xen HVM guest uses to initialize its hypercall +page, and provides the starting address and size of the hypercall +blobs in userspace. When the guest writes the MSR, kvm copies one +page of a blob (32- or 64-bit, depending on the vcpu mode) to guest +memory. + +struct kvm_xen_hvm_config { + __u32 flags; + __u32 msr; + __u64 blob_addr_32; + __u64 blob_addr_64; + __u8 blob_size_32; + __u8 blob_size_64; + __u8 pad2[30]; +}; + +4.27 KVM_GET_CLOCK + +Capability: KVM_CAP_ADJUST_CLOCK +Architectures: x86 +Type: vm ioctl +Parameters: struct kvm_clock_data (out) +Returns: 0 on success, -1 on error + +Gets the current timestamp of kvmclock as seen by the current guest. In +conjunction with KVM_SET_CLOCK, it is used to ensure monotonicity on scenarios +such as migration. + +struct kvm_clock_data { + __u64 clock; /* kvmclock current value */ + __u32 flags; + __u32 pad[9]; +}; + +4.28 KVM_SET_CLOCK + +Capability: KVM_CAP_ADJUST_CLOCK +Architectures: x86 +Type: vm ioctl +Parameters: struct kvm_clock_data (in) +Returns: 0 on success, -1 on error + +Sets the current timestamp of kvmclock to the valued specific in its parameter. +In conjunction with KVM_GET_CLOCK, it is used to ensure monotonicity on scenarios +such as migration. + +struct kvm_clock_data { + __u64 clock; /* kvmclock current value */ + __u32 flags; + __u32 pad[9]; +}; + +4.29 KVM_GET_VCPU_EVENTS + +Capability: KVM_CAP_VCPU_EVENTS +Architectures: x86 +Type: vm ioctl +Parameters: struct kvm_vcpu_event (out) +Returns: 0 on success, -1 on error + +Gets currently pending exceptions, interrupts, and NMIs as well as related +states of the vcpu. + +struct kvm_vcpu_events { + struct { + __u8 injected; + __u8 nr; + __u8 has_error_code; + __u8 pad; + __u32 error_code; + } exception; + struct { + __u8 injected; + __u8 nr; + __u8 soft; + __u8 pad; + } interrupt; + struct { + __u8 injected; + __u8 pending; + __u8 masked; + __u8 pad; + } nmi; + __u32 sipi_vector; + __u32 flags; +}; + +4.30 KVM_SET_VCPU_EVENTS + +Capability: KVM_CAP_VCPU_EVENTS +Architectures: x86 +Type: vm ioctl +Parameters: struct kvm_vcpu_event (in) +Returns: 0 on success, -1 on error + +Set pending exceptions, interrupts, and NMIs as well as related states of the +vcpu. + +See KVM_GET_VCPU_EVENTS for the data structure. + +Fields that may be modified asynchronously by running VCPUs can be excluded +from the update. These fields are nmi.pending and sipi_vector. Keep the +corresponding bits in the flags field cleared to suppress overwriting the +current in-kernel state. The bits are: + +KVM_VCPUEVENT_VALID_NMI_PENDING - transfer nmi.pending to the kernel +KVM_VCPUEVENT_VALID_SIPI_VECTOR - transfer sipi_vector + + +5. The kvm_run structure + +Application code obtains a pointer to the kvm_run structure by +mmap()ing a vcpu fd. From that point, application code can control +execution by changing fields in kvm_run prior to calling the KVM_RUN +ioctl, and obtain information about the reason KVM_RUN returned by +looking up structure members. + +struct kvm_run { + /* in */ + __u8 request_interrupt_window; + +Request that KVM_RUN return when it becomes possible to inject external +interrupts into the guest. Useful in conjunction with KVM_INTERRUPT. + + __u8 padding1[7]; + + /* out */ + __u32 exit_reason; + +When KVM_RUN has returned successfully (return value 0), this informs +application code why KVM_RUN has returned. Allowable values for this +field are detailed below. + + __u8 ready_for_interrupt_injection; + +If request_interrupt_window has been specified, this field indicates +an interrupt can be injected now with KVM_INTERRUPT. + + __u8 if_flag; + +The value of the current interrupt flag. Only valid if in-kernel +local APIC is not used. + + __u8 padding2[2]; + + /* in (pre_kvm_run), out (post_kvm_run) */ + __u64 cr8; + +The value of the cr8 register. Only valid if in-kernel local APIC is +not used. Both input and output. + + __u64 apic_base; + +The value of the APIC BASE msr. Only valid if in-kernel local +APIC is not used. Both input and output. + + union { + /* KVM_EXIT_UNKNOWN */ + struct { + __u64 hardware_exit_reason; + } hw; + +If exit_reason is KVM_EXIT_UNKNOWN, the vcpu has exited due to unknown +reasons. Further architecture-specific information is available in +hardware_exit_reason. + + /* KVM_EXIT_FAIL_ENTRY */ + struct { + __u64 hardware_entry_failure_reason; + } fail_entry; + +If exit_reason is KVM_EXIT_FAIL_ENTRY, the vcpu could not be run due +to unknown reasons. Further architecture-specific information is +available in hardware_entry_failure_reason. + + /* KVM_EXIT_EXCEPTION */ + struct { + __u32 exception; + __u32 error_code; + } ex; + +Unused. + + /* KVM_EXIT_IO */ + struct { +#define KVM_EXIT_IO_IN 0 +#define KVM_EXIT_IO_OUT 1 + __u8 direction; + __u8 size; /* bytes */ + __u16 port; + __u32 count; + __u64 data_offset; /* relative to kvm_run start */ + } io; + +If exit_reason is KVM_EXIT_IO_IN or KVM_EXIT_IO_OUT, then the vcpu has +executed a port I/O instruction which could not be satisfied by kvm. +data_offset describes where the data is located (KVM_EXIT_IO_OUT) or +where kvm expects application code to place the data for the next +KVM_RUN invocation (KVM_EXIT_IO_IN). Data format is a patcked array. + + struct { + struct kvm_debug_exit_arch arch; + } debug; + +Unused. + + /* KVM_EXIT_MMIO */ + struct { + __u64 phys_addr; + __u8 data[8]; + __u32 len; + __u8 is_write; + } mmio; + +If exit_reason is KVM_EXIT_MMIO or KVM_EXIT_IO_OUT, then the vcpu has +executed a memory-mapped I/O instruction which could not be satisfied +by kvm. The 'data' member contains the written data if 'is_write' is +true, and should be filled by application code otherwise. + + /* KVM_EXIT_HYPERCALL */ + struct { + __u64 nr; + __u64 args[6]; + __u64 ret; + __u32 longmode; + __u32 pad; + } hypercall; + +Unused. + + /* KVM_EXIT_TPR_ACCESS */ + struct { + __u64 rip; + __u32 is_write; + __u32 pad; + } tpr_access; + +To be documented (KVM_TPR_ACCESS_REPORTING). + + /* KVM_EXIT_S390_SIEIC */ + struct { + __u8 icptcode; + __u64 mask; /* psw upper half */ + __u64 addr; /* psw lower half */ + __u16 ipa; + __u32 ipb; + } s390_sieic; + +s390 specific. + + /* KVM_EXIT_S390_RESET */ +#define KVM_S390_RESET_POR 1 +#define KVM_S390_RESET_CLEAR 2 +#define KVM_S390_RESET_SUBSYSTEM 4 +#define KVM_S390_RESET_CPU_INIT 8 +#define KVM_S390_RESET_IPL 16 + __u64 s390_reset_flags; + +s390 specific. + + /* KVM_EXIT_DCR */ + struct { + __u32 dcrn; + __u32 data; + __u8 is_write; + } dcr; + +powerpc specific. + + /* Fix the size of the union. */ + char padding[256]; + }; +}; diff --git a/Documentation/laptops/asus-laptop.txt b/Documentation/laptops/asus-laptop.txt new file mode 100644 index 000000000000..c1c5be84e4b1 --- /dev/null +++ b/Documentation/laptops/asus-laptop.txt @@ -0,0 +1,258 @@ +Asus Laptop Extras + +Version 0.1 +August 6, 2009 + +Corentin Chary <corentincj@iksaif.net> +http://acpi4asus.sf.net/ + + This driver provides support for extra features of ACPI-compatible ASUS laptops. + It may also support some MEDION, JVC or VICTOR laptops (such as MEDION 9675 or + VICTOR XP7210 for example). It makes all the extra buttons generate standard + ACPI events that go through /proc/acpi/events and input events (like keyboards). + On some models adds support for changing the display brightness and output, + switching the LCD backlight on and off, and most importantly, allows you to + blink those fancy LEDs intended for reporting mail and wireless status. + +This driver supercedes the old asus_acpi driver. + +Requirements +------------ + + Kernel 2.6.X sources, configured for your computer, with ACPI support. + You also need CONFIG_INPUT and CONFIG_ACPI. + +Status +------ + + The features currently supported are the following (see below for + detailed description): + + - Fn key combinations + - Bluetooth enable and disable + - Wlan enable and disable + - GPS enable and disable + - Video output switching + - Ambient Light Sensor on and off + - LED control + - LED Display control + - LCD brightness control + - LCD on and off + + A compatibility table by model and feature is maintained on the web + site, http://acpi4asus.sf.net/. + +Usage +----- + + Try "modprobe asus_acpi". Check your dmesg (simply type dmesg). You should + see some lines like this : + + Asus Laptop Extras version 0.42 + L2D model detected. + + If it is not the output you have on your laptop, send it (and the laptop's + DSDT) to me. + + That's all, now, all the events generated by the hotkeys of your laptop + should be reported in your /proc/acpi/event entry. You can check with + "acpi_listen". + + Hotkeys are also reported as input keys (like keyboards) you can check + which key are supported using "xev" under X11. + + You can get informations on the version of your DSDT table by reading the + /sys/devices/platform/asus-laptop/infos entry. If you have a question or a + bug report to do, please include the output of this entry. + +LEDs +---- + + You can modify LEDs be echoing values to /sys/class/leds/asus::*/brightness : + echo 1 > /sys/class/leds/asus::mail/brightness + will switch the mail LED on. + You can also know if they are on/off by reading their content and use + kernel triggers like ide-disk or heartbeat. + +Backlight +--------- + + You can control lcd backlight power and brightness with + /sys/class/backlight/asus-laptop/. Brightness Values are between 0 and 15. + +Wireless devices +--------------- + + You can turn the internal Bluetooth adapter on/off with the bluetooth entry + (only on models with Bluetooth). This usually controls the associated LED. + Same for Wlan adapter. + +Display switching +----------------- + + Note: the display switching code is currently considered EXPERIMENTAL. + + Switching works for the following models: + L3800C + A2500H + L5800C + M5200N + W1000N (albeit with some glitches) + M6700R + A6JC + F3J + + Switching doesn't work for the following: + M3700N + L2X00D (locks the laptop under certain conditions) + + To switch the displays, echo values from 0 to 15 to + /sys/devices/platform/asus-laptop/display. The significance of those values + is as follows: + + +-------+-----+-----+-----+-----+-----+ + | Bin | Val | DVI | TV | CRT | LCD | + +-------+-----+-----+-----+-----+-----+ + + 0000 + 0 + + + + + + +-------+-----+-----+-----+-----+-----+ + + 0001 + 1 + + + + X + + +-------+-----+-----+-----+-----+-----+ + + 0010 + 2 + + + X + + + +-------+-----+-----+-----+-----+-----+ + + 0011 + 3 + + + X + X + + +-------+-----+-----+-----+-----+-----+ + + 0100 + 4 + + X + + + + +-------+-----+-----+-----+-----+-----+ + + 0101 + 5 + + X + + X + + +-------+-----+-----+-----+-----+-----+ + + 0110 + 6 + + X + X + + + +-------+-----+-----+-----+-----+-----+ + + 0111 + 7 + + X + X + X + + +-------+-----+-----+-----+-----+-----+ + + 1000 + 8 + X + + + + + +-------+-----+-----+-----+-----+-----+ + + 1001 + 9 + X + + + X + + +-------+-----+-----+-----+-----+-----+ + + 1010 + 10 + X + + X + + + +-------+-----+-----+-----+-----+-----+ + + 1011 + 11 + X + + X + X + + +-------+-----+-----+-----+-----+-----+ + + 1100 + 12 + X + X + + + + +-------+-----+-----+-----+-----+-----+ + + 1101 + 13 + X + X + + X + + +-------+-----+-----+-----+-----+-----+ + + 1110 + 14 + X + X + X + + + +-------+-----+-----+-----+-----+-----+ + + 1111 + 15 + X + X + X + X + + +-------+-----+-----+-----+-----+-----+ + + In most cases, the appropriate displays must be plugged in for the above + combinations to work. TV-Out may need to be initialized at boot time. + + Debugging: + 1) Check whether the Fn+F8 key: + a) does not lock the laptop (try disabling CONFIG_X86_UP_APIC or boot with + noapic / nolapic if it does) + b) generates events (0x6n, where n is the value corresponding to the + configuration above) + c) actually works + Record the disp value at every configuration. + 2) Echo values from 0 to 15 to /sys/devices/platform/asus-laptop/display. + Record its value, note any change. If nothing changes, try a broader range, + up to 65535. + 3) Send ANY output (both positive and negative reports are needed, unless your + machine is already listed above) to the acpi4asus-user mailing list. + + Note: on some machines (e.g. L3C), after the module has been loaded, only 0x6n + events are generated and no actual switching occurs. In such a case, a line + like: + + echo $((10#$arg-60)) > /sys/devices/platform/asus-laptop/display + + will usually do the trick ($arg is the 0000006n-like event passed to acpid). + + Note: there is currently no reliable way to read display status on xxN + (Centrino) models. + +LED display +----------- + + Some models like the W1N have a LED display that can be used to display + several informations. + + LED display works for the following models: + W1000N + W1J + + To control the LED display, use the following : + + echo 0x0T000DDD > /sys/devices/platform/asus-laptop/ + + where T control the 3 letters display, and DDD the 3 digits display, + according to the tables below. + + DDD (digits) + 000 to 999 = display digits + AAA = --- + BBB to FFF = turn-off + + T (type) + 0 = off + 1 = dvd + 2 = vcd + 3 = mp3 + 4 = cd + 5 = tv + 6 = cpu + 7 = vol + + For example "echo 0x01000001 >/sys/devices/platform/asus-laptop/ledd" + would display "DVD001". + +Driver options: +--------------- + + Options can be passed to the asus-laptop driver using the standard + module argument syntax (<param>=<value> when passing the option to the + module or asus-laptop.<param>=<value> on the kernel boot line when + asus-laptop is statically linked into the kernel). + + wapf: WAPF defines the behavior of the Fn+Fx wlan key + The significance of values is yet to be found, but + most of the time: + - 0x0 should do nothing + - 0x1 should allow to control the device with Fn+Fx key. + - 0x4 should send an ACPI event (0x88) while pressing the Fn+Fx key + - 0x5 like 0x1 or 0x4 + + The default value is 0x1. + +Unsupported models +------------------ + + These models will never be supported by this module, as they use a completely + different mechanism to handle LEDs and extra stuff (meaning we have no clue + how it works): + + - ASUS A1300 (A1B), A1370D + - ASUS L7300G + - ASUS L8400 + +Patches, Errors, Questions: +-------------------------- + + I appreciate any success or failure + reports, especially if they add to or correct the compatibility table. + Please include the following information in your report: + + - Asus model name + - a copy of your ACPI tables, using the "acpidump" utility + - a copy of /sys/devices/platform/asus-laptop/infos + - which driver features work and which don't + - the observed behavior of non-working features + + Any other comments or patches are also more than welcome. + + acpi4asus-user@lists.sourceforge.net + http://sourceforge.net/projects/acpi4asus + diff --git a/Documentation/laptops/thinkpad-acpi.txt b/Documentation/laptops/thinkpad-acpi.txt index e2ddcdeb61b6..75afa1229fd7 100644 --- a/Documentation/laptops/thinkpad-acpi.txt +++ b/Documentation/laptops/thinkpad-acpi.txt @@ -1,7 +1,7 @@ ThinkPad ACPI Extras Driver - Version 0.23 - April 10th, 2009 + Version 0.24 + December 11th, 2009 Borislav Deianov <borislav@users.sf.net> Henrique de Moraes Holschuh <hmh@hmh.eng.br> @@ -199,18 +199,22 @@ kind to allow it (and it often doesn't!). Not all bits in the mask can be modified. Not all bits that can be modified do anything. Not all hot keys can be individually controlled -by the mask. Some models do not support the mask at all, and in those -models, hot keys cannot be controlled individually. The behaviour of -the mask is, therefore, highly dependent on the ThinkPad model. +by the mask. Some models do not support the mask at all. The behaviour +of the mask is, therefore, highly dependent on the ThinkPad model. + +The driver will filter out any unmasked hotkeys, so even if the firmware +doesn't allow disabling an specific hotkey, the driver will not report +events for unmasked hotkeys. Note that unmasking some keys prevents their default behavior. For example, if Fn+F5 is unmasked, that key will no longer enable/disable -Bluetooth by itself. +Bluetooth by itself in firmware. -Note also that not all Fn key combinations are supported through ACPI. -For example, on the X40, the brightness, volume and "Access IBM" buttons -do not generate ACPI events even with this driver. They *can* be used -through the "ThinkPad Buttons" utility, see http://www.nongnu.org/tpb/ +Note also that not all Fn key combinations are supported through ACPI +depending on the ThinkPad model and firmware version. On those +ThinkPads, it is still possible to support some extra hotkeys by +polling the "CMOS NVRAM" at least 10 times per second. The driver +attempts to enables this functionality automatically when required. procfs notes: @@ -219,7 +223,7 @@ The following commands can be written to the /proc/acpi/ibm/hotkey file: echo 0xffffffff > /proc/acpi/ibm/hotkey -- enable all hot keys echo 0 > /proc/acpi/ibm/hotkey -- disable all possible hot keys ... any other 8-hex-digit mask ... - echo reset > /proc/acpi/ibm/hotkey -- restore the original mask + echo reset > /proc/acpi/ibm/hotkey -- restore the recommended mask The following commands have been deprecated and will cause the kernel to log a warning: @@ -240,9 +244,13 @@ sysfs notes: Returns 0. hotkey_bios_mask: + DEPRECATED, DON'T USE, WILL BE REMOVED IN THE FUTURE. + Returns the hot keys mask when thinkpad-acpi was loaded. Upon module unload, the hot keys mask will be restored - to this value. + to this value. This is always 0x80c, because those are + the hotkeys that were supported by ancient firmware + without mask support. hotkey_enable: DEPRECATED, WILL BE REMOVED SOON. @@ -251,18 +259,11 @@ sysfs notes: 1: does nothing hotkey_mask: - bit mask to enable driver-handling (and depending on + bit mask to enable reporting (and depending on the firmware, ACPI event generation) for each hot key (see above). Returns the current status of the hot keys mask, and allows one to modify it. - Note: when NVRAM polling is active, the firmware mask - will be different from the value returned by - hotkey_mask. The driver will retain enabled bits for - hotkeys that are under NVRAM polling even if the - firmware refuses them, and will not set these bits on - the firmware hot key mask. - hotkey_all_mask: bit mask that should enable event reporting for all supported hot keys, when echoed to hotkey_mask above. @@ -275,7 +276,8 @@ sysfs notes: bit mask that should enable event reporting for all supported hot keys, except those which are always handled by the firmware anyway. Echo it to - hotkey_mask above, to use. + hotkey_mask above, to use. This is the default mask + used by the driver. hotkey_source_mask: bit mask that selects which hot keys will the driver @@ -283,9 +285,10 @@ sysfs notes: based on the capabilities reported by the ACPI firmware, but it can be overridden at runtime. - Hot keys whose bits are set in both hotkey_source_mask - and also on hotkey_mask are polled for in NVRAM. Only a - few hot keys are available through CMOS NVRAM polling. + Hot keys whose bits are set in hotkey_source_mask are + polled for in NVRAM, and reported as hotkey events if + enabled in hotkey_mask. Only a few hot keys are + available through CMOS NVRAM polling. Warning: when in NVRAM mode, the volume up/down/mute keys are synthesized according to changes in the mixer, @@ -457,6 +460,8 @@ event code Key Notes For Lenovo ThinkPads with a new BIOS, it has to be handled either by the ACPI OSI, or by userspace. + The driver does the right thing, + never mess with this. 0x1011 0x10 FN+END Brightness down. See brightness up for details. @@ -521,6 +526,7 @@ compatibility purposes when hotkey_report_mode is set to 1. 0x2305 System is waking up from suspend to eject bay 0x2404 System is waking up from hibernation to undock 0x2405 System is waking up from hibernation to eject bay +0x5010 Brightness level changed/control event The above events are never propagated by the driver. @@ -528,7 +534,6 @@ The above events are never propagated by the driver. 0x4003 Undocked (see 0x2x04), can sleep again 0x500B Tablet pen inserted into its storage bay 0x500C Tablet pen removed from its storage bay -0x5010 Brightness level changed (newer Lenovo BIOSes) The above events are propagated by the driver. @@ -579,44 +584,15 @@ with hotkey_report_mode. Brightness hotkey notes: -These are the current sane choices for brightness key mapping in -thinkpad-acpi: - -For IBM and Lenovo models *without* ACPI backlight control (the ones on -which thinkpad-acpi will autoload its backlight interface by default, -and on which ACPI video does not export a backlight interface): - -1. Don't enable or map the brightness hotkeys in thinkpad-acpi, as - these older firmware versions unfortunately won't respect the hotkey - mask for brightness keys anyway, and always reacts to them. This - usually work fine, unless X.org drivers are doing something to block - the BIOS. In that case, use (3) below. This is the default mode of - operation. - -2. Enable the hotkeys, but map them to something else that is NOT - KEY_BRIGHTNESS_UP/DOWN or any other keycode that would cause - userspace to try to change the backlight level, and use that as an - on-screen-display hint. - -3. IF AND ONLY IF X.org drivers find a way to block the firmware from - automatically changing the brightness, enable the hotkeys and map - them to KEY_BRIGHTNESS_UP and KEY_BRIGHTNESS_DOWN, and feed that to - something that calls xbacklight. thinkpad-acpi will not be able to - change brightness in that case either, so you should disable its - backlight interface. - -For Lenovo models *with* ACPI backlight control: +Don't mess with the brightness hotkeys in a Thinkpad. If you want +notifications for OSD, use the sysfs backlight class event support. -1. Load up ACPI video and use that. ACPI video will report ACPI - events for brightness change keys. Do not mess with thinkpad-acpi - defaults in this case. thinkpad-acpi should not have anything to do - with backlight events in a scenario where ACPI video is loaded: - brightness hotkeys must be disabled, and the backlight interface is - to be kept disabled as well. This is the default mode of operation. - -2. Do *NOT* load up ACPI video, enable the hotkeys in thinkpad-acpi, - and map them to KEY_BRIGHTNESS_UP and KEY_BRIGHTNESS_DOWN. Process - these keys on userspace somehow (e.g. by calling xbacklight). +The driver will issue KEY_BRIGHTNESS_UP and KEY_BRIGHTNESS_DOWN events +automatically for the cases were userspace has to do something to +implement brightness changes. When you override these events, you will +either fail to handle properly the ThinkPads that require explicit +action to change backlight brightness, or the ThinkPads that require +that no action be taken to work properly. Bluetooth @@ -1116,25 +1092,103 @@ WARNING: its level up and down at every change. -Volume control -- /proc/acpi/ibm/volume ---------------------------------------- +Volume control (Console Audio control) +-------------------------------------- + +procfs: /proc/acpi/ibm/volume +ALSA: "ThinkPad Console Audio Control", default ID: "ThinkPadEC" + +NOTE: by default, the volume control interface operates in read-only +mode, as it is supposed to be used for on-screen-display purposes. +The read/write mode can be enabled through the use of the +"volume_control=1" module parameter. + +NOTE: distros are urged to not enable volume_control by default, this +should be done by the local admin only. The ThinkPad UI is for the +console audio control to be done through the volume keys only, and for +the desktop environment to just provide on-screen-display feedback. +Software volume control should be done only in the main AC97/HDA +mixer. + + +About the ThinkPad Console Audio control: + +ThinkPads have a built-in amplifier and muting circuit that drives the +console headphone and speakers. This circuit is after the main AC97 +or HDA mixer in the audio path, and under exclusive control of the +firmware. + +ThinkPads have three special hotkeys to interact with the console +audio control: volume up, volume down and mute. -This feature allows volume control on ThinkPad models which don't have -a hardware volume knob. The available commands are: +It is worth noting that the normal way the mute function works (on +ThinkPads that do not have a "mute LED") is: + +1. Press mute to mute. It will *always* mute, you can press it as + many times as you want, and the sound will remain mute. + +2. Press either volume key to unmute the ThinkPad (it will _not_ + change the volume, it will just unmute). + +This is a very superior design when compared to the cheap software-only +mute-toggle solution found on normal consumer laptops: you can be +absolutely sure the ThinkPad will not make noise if you press the mute +button, no matter the previous state. + +The IBM ThinkPads, and the earlier Lenovo ThinkPads have variable-gain +amplifiers driving the speakers and headphone output, and the firmware +also handles volume control for the headphone and speakers on these +ThinkPads without any help from the operating system (this volume +control stage exists after the main AC97 or HDA mixer in the audio +path). + +The newer Lenovo models only have firmware mute control, and depend on +the main HDA mixer to do volume control (which is done by the operating +system). In this case, the volume keys are filtered out for unmute +key press (there are some firmware bugs in this area) and delivered as +normal key presses to the operating system (thinkpad-acpi is not +involved). + + +The ThinkPad-ACPI volume control: + +The preferred way to interact with the Console Audio control is the +ALSA interface. + +The legacy procfs interface allows one to read the current state, +and if volume control is enabled, accepts the following commands: echo up >/proc/acpi/ibm/volume echo down >/proc/acpi/ibm/volume echo mute >/proc/acpi/ibm/volume + echo unmute >/proc/acpi/ibm/volume echo 'level <level>' >/proc/acpi/ibm/volume -The <level> number range is 0 to 15 although not all of them may be -distinct. The unmute the volume after the mute command, use either the -up or down command (the level command will not unmute the volume). -The current volume level and mute state is shown in the file. +The <level> number range is 0 to 14 although not all of them may be +distinct. To unmute the volume after the mute command, use either the +up or down command (the level command will not unmute the volume), or +the unmute command. + +You can use the volume_capabilities parameter to tell the driver +whether your thinkpad has volume control or mute-only control: +volume_capabilities=1 for mixers with mute and volume control, +volume_capabilities=2 for mixers with only mute control. + +If the driver misdetects the capabilities for your ThinkPad model, +please report this to ibm-acpi-devel@lists.sourceforge.net, so that we +can update the driver. + +There are two strategies for volume control. To select which one +should be used, use the volume_mode module parameter: volume_mode=1 +selects EC mode, and volume_mode=3 selects EC mode with NVRAM backing +(so that volume/mute changes are remembered across shutdown/reboot). -The ALSA mixer interface to this feature is still missing, but patches -to add it exist. That problem should be addressed in the not so -distant future. +The driver will operate in volume_mode=3 by default. If that does not +work well on your ThinkPad model, please report this to +ibm-acpi-devel@lists.sourceforge.net. + +The driver supports the standard ALSA module parameters. If the ALSA +mixer is disabled, the driver will disable all volume functionality. Fan control and monitoring: fan speed, fan enable/disable @@ -1400,6 +1454,7 @@ to enable more than one output class, just add their values. 0x0008 HKEY event interface, hotkeys 0x0010 Fan control 0x0020 Backlight brightness + 0x0040 Audio mixer/volume control There is also a kernel build option to enable more debugging information, which may be necessary to debug driver problems. @@ -1455,3 +1510,14 @@ Sysfs interface changelog: 0x020400: Marker for 16 LEDs support. Also, LEDs that are known to not exist in a given model are not registered with the LED sysfs class anymore. + +0x020500: Updated hotkey driver, hotkey_mask is always available + and it is always able to disable hot keys. Very old + thinkpads are properly supported. hotkey_bios_mask + is deprecated and marked for removal. + +0x020600: Marker for backlight change event support. + +0x020700: Support for mute-only mixers. + Volume control in read-only mode by default. + Marker for ALSA mixer support. diff --git a/Documentation/leds-class.txt b/Documentation/leds-class.txt index 6399557cdab3..8fd5ca2ae32d 100644 --- a/Documentation/leds-class.txt +++ b/Documentation/leds-class.txt @@ -1,3 +1,4 @@ + LED handling under Linux ======================== @@ -5,10 +6,10 @@ If you're reading this and thinking about keyboard leds, these are handled by the input subsystem and the led class is *not* needed. In its simplest form, the LED class just allows control of LEDs from -userspace. LEDs appear in /sys/class/leds/. The brightness file will -set the brightness of the LED (taking a value 0-255). Most LEDs don't -have hardware brightness support so will just be turned on for non-zero -brightness settings. +userspace. LEDs appear in /sys/class/leds/. The maximum brightness of the +LED is defined in max_brightness file. The brightness file will set the brightness +of the LED (taking a value 0-max_brightness). Most LEDs don't have hardware +brightness support so will just be turned on for non-zero brightness settings. The class also introduces the optional concept of an LED trigger. A trigger is a kernel based source of led events. Triggers can either be simple or diff --git a/Documentation/lguest/lguest.c b/Documentation/lguest/lguest.c index 950cde6d6e58..42208511b5c0 100644 --- a/Documentation/lguest/lguest.c +++ b/Documentation/lguest/lguest.c @@ -133,6 +133,9 @@ struct device { /* Is it operational */ bool running; + /* Does Guest want an intrrupt on empty? */ + bool irq_on_empty; + /* Device-specific data. */ void *priv; }; @@ -301,7 +304,7 @@ static void *map_zeroed_pages(unsigned int num) addr = mmap(NULL, getpagesize() * num, PROT_READ|PROT_WRITE|PROT_EXEC, MAP_PRIVATE, fd, 0); if (addr == MAP_FAILED) - err(1, "Mmaping %u pages of /dev/zero", num); + err(1, "Mmapping %u pages of /dev/zero", num); /* * One neat mmap feature is that you can close the fd, and it @@ -623,10 +626,13 @@ static void trigger_irq(struct virtqueue *vq) return; vq->pending_used = 0; - /* If they don't want an interrupt, don't send one, unless empty. */ - if ((vq->vring.avail->flags & VRING_AVAIL_F_NO_INTERRUPT) - && lg_last_avail(vq) != vq->vring.avail->idx) - return; + /* If they don't want an interrupt, don't send one... */ + if (vq->vring.avail->flags & VRING_AVAIL_F_NO_INTERRUPT) { + /* ... unless they've asked us to force one on empty. */ + if (!vq->dev->irq_on_empty + || lg_last_avail(vq) != vq->vring.avail->idx) + return; + } /* Send the Guest an interrupt tell them we used something up. */ if (write(lguest_fd, buf, sizeof(buf)) != 0) @@ -1042,6 +1048,15 @@ static void create_thread(struct virtqueue *vq) close(vq->eventfd); } +static bool accepted_feature(struct device *dev, unsigned int bit) +{ + const u8 *features = get_feature_bits(dev) + dev->feature_len; + + if (dev->feature_len < bit / CHAR_BIT) + return false; + return features[bit / CHAR_BIT] & (1 << (bit % CHAR_BIT)); +} + static void start_device(struct device *dev) { unsigned int i; @@ -1055,6 +1070,8 @@ static void start_device(struct device *dev) verbose(" %02x", get_feature_bits(dev) [dev->feature_len+i]); + dev->irq_on_empty = accepted_feature(dev, VIRTIO_F_NOTIFY_ON_EMPTY); + for (vq = dev->vq; vq; vq = vq->next) { if (vq->service) create_thread(vq); diff --git a/Documentation/lockstat.txt b/Documentation/lockstat.txt index 9cb9138f7a79..65f4c795015d 100644 --- a/Documentation/lockstat.txt +++ b/Documentation/lockstat.txt @@ -62,8 +62,20 @@ applicable). It also tracks 4 contention points per class. A contention point is a call site that had to wait on lock acquisition. + - CONFIGURATION + +Lock statistics are enabled via CONFIG_LOCK_STATS. + - USAGE +Enable collection of statistics: + +# echo 1 >/proc/sys/kernel/lock_stat + +Disable collection of statistics: + +# echo 0 >/proc/sys/kernel/lock_stat + Look at the current lock statistics: ( line numbers not part of actual output, done for clarity in the explanation diff --git a/Documentation/markers.txt b/Documentation/markers.txt deleted file mode 100644 index d2b3d0e91b26..000000000000 --- a/Documentation/markers.txt +++ /dev/null @@ -1,104 +0,0 @@ - Using the Linux Kernel Markers - - Mathieu Desnoyers - - -This document introduces Linux Kernel Markers and their use. It provides -examples of how to insert markers in the kernel and connect probe functions to -them and provides some examples of probe functions. - - -* Purpose of markers - -A marker placed in code provides a hook to call a function (probe) that you can -provide at runtime. A marker can be "on" (a probe is connected to it) or "off" -(no probe is attached). When a marker is "off" it has no effect, except for -adding a tiny time penalty (checking a condition for a branch) and space -penalty (adding a few bytes for the function call at the end of the -instrumented function and adds a data structure in a separate section). When a -marker is "on", the function you provide is called each time the marker is -executed, in the execution context of the caller. When the function provided -ends its execution, it returns to the caller (continuing from the marker site). - -You can put markers at important locations in the code. Markers are -lightweight hooks that can pass an arbitrary number of parameters, -described in a printk-like format string, to the attached probe function. - -They can be used for tracing and performance accounting. - - -* Usage - -In order to use the macro trace_mark, you should include linux/marker.h. - -#include <linux/marker.h> - -And, - -trace_mark(subsystem_event, "myint %d mystring %s", someint, somestring); -Where : -- subsystem_event is an identifier unique to your event - - subsystem is the name of your subsystem. - - event is the name of the event to mark. -- "myint %d mystring %s" is the formatted string for the serializer. "myint" and - "mystring" are repectively the field names associated with the first and - second parameter. -- someint is an integer. -- somestring is a char pointer. - -Connecting a function (probe) to a marker is done by providing a probe (function -to call) for the specific marker through marker_probe_register() and can be -activated by calling marker_arm(). Marker deactivation can be done by calling -marker_disarm() as many times as marker_arm() has been called. Removing a probe -is done through marker_probe_unregister(); it will disarm the probe. - -marker_synchronize_unregister() must be called between probe unregistration and -the first occurrence of -- the end of module exit function, - to make sure there is no caller left using the probe; -- the free of any resource used by the probes, - to make sure the probes wont be accessing invalid data. -This, and the fact that preemption is disabled around the probe call, make sure -that probe removal and module unload are safe. See the "Probe example" section -below for a sample probe module. - -The marker mechanism supports inserting multiple instances of the same marker. -Markers can be put in inline functions, inlined static functions, and -unrolled loops as well as regular functions. - -The naming scheme "subsystem_event" is suggested here as a convention intended -to limit collisions. Marker names are global to the kernel: they are considered -as being the same whether they are in the core kernel image or in modules. -Conflicting format strings for markers with the same name will cause the markers -to be detected to have a different format string not to be armed and will output -a printk warning which identifies the inconsistency: - -"Format mismatch for probe probe_name (format), marker (format)" - -Another way to use markers is to simply define the marker without generating any -function call to actually call into the marker. This is useful in combination -with tracepoint probes in a scheme like this : - -void probe_tracepoint_name(unsigned int arg1, struct task_struct *tsk); - -DEFINE_MARKER_TP(marker_eventname, tracepoint_name, probe_tracepoint_name, - "arg1 %u pid %d"); - -notrace void probe_tracepoint_name(unsigned int arg1, struct task_struct *tsk) -{ - struct marker *marker = &GET_MARKER(kernel_irq_entry); - /* write data to trace buffers ... */ -} - -* Probe / marker example - -See the example provided in samples/markers/src - -Compile them with your kernel. - -Run, as root : -modprobe marker-example (insmod order is not important) -modprobe probe-example -cat /proc/marker-example (returns an expected error) -rmmod marker-example probe-example -dmesg diff --git a/Documentation/md.txt b/Documentation/md.txt index 4edd39ec7db9..188f4768f1d5 100644 --- a/Documentation/md.txt +++ b/Documentation/md.txt @@ -233,9 +233,9 @@ All md devices contain: resync_start The point at which resync should start. If no resync is needed, - this will be a very large number. At array creation it will - default to 0, though starting the array as 'clean' will - set it much larger. + this will be a very large number (or 'none' since 2.6.30-rc1). At + array creation it will default to 0, though starting the array as + 'clean' will set it much larger. new_dev This file can be written but not read. The value written should @@ -296,6 +296,51 @@ All md devices contain: active-idle like active, but no writes have been seen for a while (safe_mode_delay). + bitmap/location + This indicates where the write-intent bitmap for the array is + stored. + It can be one of "none", "file" or "[+-]N". + "file" may later be extended to "file:/file/name" + "[+-]N" means that many sectors from the start of the metadata. + This is replicated on all devices. For arrays with externally + managed metadata, the offset is from the beginning of the + device. + bitmap/chunksize + The size, in bytes, of the chunk which will be represented by a + single bit. For RAID456, it is a portion of an individual + device. For RAID10, it is a portion of the array. For RAID1, it + is both (they come to the same thing). + bitmap/time_base + The time, in seconds, between looking for bits in the bitmap to + be cleared. In the current implementation, a bit will be cleared + between 2 and 3 times "time_base" after all the covered blocks + are known to be in-sync. + bitmap/backlog + When write-mostly devices are active in a RAID1, write requests + to those devices proceed in the background - the filesystem (or + other user of the device) does not have to wait for them. + 'backlog' sets a limit on the number of concurrent background + writes. If there are more than this, new writes will by + synchronous. + bitmap/metadata + This can be either 'internal' or 'external'. + 'internal' is the default and means the metadata for the bitmap + is stored in the first 256 bytes of the allocated space and is + managed by the md module. + 'external' means that bitmap metadata is managed externally to + the kernel (i.e. by some userspace program) + bitmap/can_clear + This is either 'true' or 'false'. If 'true', then bits in the + bitmap will be cleared when the corresponding blocks are thought + to be in-sync. If 'false', bits will never be cleared. + This is automatically set to 'false' if a write happens on a + degraded array, or if the array becomes degraded during a write. + When metadata is managed externally, it should be set to true + once the array becomes non-degraded, and this fact has been + recorded in the metadata. + + + As component devices are added to an md array, they appear in the 'md' directory as new directories named @@ -334,8 +379,9 @@ Each directory contains: Writing "writemostly" sets the writemostly flag. Writing "-writemostly" clears the writemostly flag. Writing "blocked" sets the "blocked" flag. - Writing "-blocked" clear the "blocked" flag and allows writes + Writing "-blocked" clears the "blocked" flag and allows writes to complete. + Writing "in_sync" sets the in_sync flag. This file responds to select/poll. Any change to 'faulty' or 'blocked' causes an event. @@ -372,6 +418,24 @@ Each directory contains: array. If a value less than the current component_size is written, it will be rejected. + recovery_start + + When the device is not 'in_sync', this records the number of + sectors from the start of the device which are known to be + correct. This is normally zero, but during a recovery + operation is will steadily increase, and if the recovery is + interrupted, restoring this value can cause recovery to + avoid repeating the earlier blocks. With v1.x metadata, this + value is saved and restored automatically. + + This can be set whenever the device is not an active member of + the array, either before the array is activated, or before + the 'slot' is set. + + Setting this to 'none' is equivalent to setting 'in_sync'. + Setting to any other value also clears the 'in_sync' flag. + + An active md device will also contain and entry for each active device in the array. These are named diff --git a/Documentation/memory-hotplug.txt b/Documentation/memory-hotplug.txt index bbc8a6a36921..57e7e9cc1870 100644 --- a/Documentation/memory-hotplug.txt +++ b/Documentation/memory-hotplug.txt @@ -160,12 +160,15 @@ Under each section, you can see 4 files. NOTE: These directories/files appear after physical memory hotplug phase. -If CONFIG_NUMA is enabled the -/sys/devices/system/memory/memoryXXX memory section -directories can also be accessed via symbolic links located in -the /sys/devices/system/node/node* directories. For example: +If CONFIG_NUMA is enabled the memoryXXX/ directories can also be accessed +via symbolic links located in the /sys/devices/system/node/node* directories. + +For example: /sys/devices/system/node/node0/memory9 -> ../../memory/memory9 +A backlink will also be created: +/sys/devices/system/memory/memory9/node0 -> ../../node/node0 + -------------------------------- 4. Physical memory hot-add phase -------------------------------- diff --git a/Documentation/memory.txt b/Documentation/memory.txt index 2b3dedd39538..802efe58647c 100644 --- a/Documentation/memory.txt +++ b/Documentation/memory.txt @@ -1,18 +1,7 @@ There are several classic problems related to memory on Linux systems. - 1) There are some buggy motherboards which cannot properly - deal with the memory above 16MB. Consider exchanging - your motherboard. - - 2) You cannot do DMA on the ISA bus to addresses above - 16M. Most device drivers under Linux allow the use - of bounce buffers which work around this problem. Drivers - that don't use bounce buffers will be unstable with - more than 16M installed. Drivers that use bounce buffers - will be OK, but may have slightly higher overhead. - - 3) There are some motherboards that will not cache above + 1) There are some motherboards that will not cache above a certain quantity of memory. If you have one of these motherboards, your system will be SLOWER, not faster as you add more memory. Consider exchanging your @@ -24,7 +13,7 @@ It can also tell Linux to use less memory than is actually installed. If you use "mem=" on a machine with PCI, consider using "memmap=" to avoid physical address space collisions. -See the documentation of your boot loader (LILO, loadlin, etc.) about +See the documentation of your boot loader (LILO, grub, loadlin, etc.) about how to pass options to the kernel. There are other memory problems which Linux cannot deal with. Random @@ -42,19 +31,3 @@ Try: with the vendor. Consider testing it with memtest86 yourself. * Exchanging your CPU, cache, or motherboard for one that works. - - * Disabling the cache from the BIOS. - - * Try passing the "mem=4M" option to the kernel to limit - Linux to using a very small amount of memory. Use "memmap="-option - together with "mem=" on systems with PCI to avoid physical address - space collisions. - - -Other tricks: - - * Try passing the "no-387" option to the kernel to ignore - a buggy FPU. - - * Try passing the "no-hlt" option to disable the potentially - buggy HLT instruction in your CPU. diff --git a/Documentation/misc-devices/ad525x_dpot.txt b/Documentation/misc-devices/ad525x_dpot.txt new file mode 100644 index 000000000000..0c9413b1cbf3 --- /dev/null +++ b/Documentation/misc-devices/ad525x_dpot.txt @@ -0,0 +1,57 @@ +--------------------------------- + AD525x Digital Potentiometers +--------------------------------- + +The ad525x_dpot driver exports a simple sysfs interface. This allows you to +work with the immediate resistance settings as well as update the saved startup +settings. Access to the factory programmed tolerance is also provided, but +interpretation of this settings is required by the end application according to +the specific part in use. + +--------- + Files +--------- + +Each dpot device will have a set of eeprom, rdac, and tolerance files. How +many depends on the actual part you have, as will the range of allowed values. + +The eeprom files are used to program the startup value of the device. + +The rdac files are used to program the immediate value of the device. + +The tolerance files are the read-only factory programmed tolerance settings +and may vary greatly on a part-by-part basis. For exact interpretation of +this field, please consult the datasheet for your part. This is presented +as a hex file for easier parsing. + +----------- + Example +----------- + +Locate the device in your sysfs tree. This is probably easiest by going into +the common i2c directory and locating the device by the i2c slave address. + + # ls /sys/bus/i2c/devices/ + 0-0022 0-0027 0-002f + +So assuming the device in question is on the first i2c bus and has the slave +address of 0x2f, we descend (unrelated sysfs entries have been trimmed). + + # ls /sys/bus/i2c/devices/0-002f/ + eeprom0 rdac0 tolerance0 + +You can use simple reads/writes to access these files: + + # cd /sys/bus/i2c/devices/0-002f/ + + # cat eeprom0 + 0 + # echo 10 > eeprom0 + # cat eeprom0 + 10 + + # cat rdac0 + 5 + # echo 3 > rdac0 + # cat rdac0 + 3 diff --git a/Documentation/c2port.txt b/Documentation/misc-devices/c2port.txt index d9bf93ea4398..d9bf93ea4398 100644 --- a/Documentation/c2port.txt +++ b/Documentation/misc-devices/c2port.txt diff --git a/Documentation/i2c/chips/eeprom b/Documentation/misc-devices/eeprom index f7e8104b5764..f7e8104b5764 100644 --- a/Documentation/i2c/chips/eeprom +++ b/Documentation/misc-devices/eeprom diff --git a/Documentation/ics932s401 b/Documentation/misc-devices/ics932s401 index 07a739f406d8..07a739f406d8 100644 --- a/Documentation/ics932s401 +++ b/Documentation/misc-devices/ics932s401 diff --git a/Documentation/i2c/chips/max6875 b/Documentation/misc-devices/max6875 index 10ca43cd1a72..1e89ee3ccc1b 100644 --- a/Documentation/i2c/chips/max6875 +++ b/Documentation/misc-devices/max6875 @@ -42,10 +42,12 @@ General Remarks Valid addresses for the MAX6875 are 0x50 and 0x52. Valid addresses for the MAX6874 are 0x50, 0x52, 0x54 and 0x56. -The driver does not probe any address, so you must force the address. +The driver does not probe any address, so you explicitly instantiate the +devices. Example: -$ modprobe max6875 force=0,0x50 +$ modprobe max6875 +$ echo max6875 0x50 > /sys/bus/i2c/devices/i2c-0/new_device The MAX6874/MAX6875 ignores address bit 0, so this driver attaches to multiple addresses. For example, for address 0x50, it also reserves 0x51. diff --git a/Documentation/networking/00-INDEX b/Documentation/networking/00-INDEX index 1634c6dcecae..50189bf07d53 100644 --- a/Documentation/networking/00-INDEX +++ b/Documentation/networking/00-INDEX @@ -60,6 +60,8 @@ framerelay.txt - info on using Frame Relay/Data Link Connection Identifier (DLCI). generic_netlink.txt - info on Generic Netlink +ieee802154.txt + - Linux IEEE 802.15.4 implementation, API and drivers ip-sysctl.txt - /proc/sys/net/ipv4/* variables ip_dynaddr.txt diff --git a/Documentation/networking/3c509.txt b/Documentation/networking/3c509.txt index 0643e3b7168c..3c45d5dcd63b 100644 --- a/Documentation/networking/3c509.txt +++ b/Documentation/networking/3c509.txt @@ -48,11 +48,11 @@ for LILO parameters for doing this: This configures the first found 3c509 card for IRQ 10, base I/O 0x310, and transceiver type 3 (10base2). The flag "0x3c509" must be set to avoid conflicts with other card types when overriding the I/O address. When the driver is -loaded as a module, only the IRQ and transceiver setting may be overridden. -For example, setting two cards to 10base2/IRQ10 and AUI/IRQ11 is done by using -the xcvr and irq module options: +loaded as a module, only the IRQ may be overridden. For example, +setting two cards to IRQ10 and IRQ11 is done by using the irq module +option: - options 3c509 xcvr=3,1 irq=10,11 + options 3c509 irq=10,11 (2) Full-duplex mode @@ -77,6 +77,8 @@ operation. itself full-duplex capable. This is almost certainly one of two things: a full- duplex-capable Ethernet switch (*not* a hub), or a full-duplex-capable NIC on another system that's connected directly to the 3c509B via a crossover cable. + +Full-duplex mode can be enabled using 'ethtool'. /////Extremely important caution concerning full-duplex mode///// Understand that the 3c509B's hardware's full-duplex support is much more @@ -113,6 +115,8 @@ This insured that merely upgrading the driver from an earlier version would never automatically enable full-duplex mode in an existing installation; it must always be explicitly enabled via one of these code in order to be activated. + +The transceiver type can be changed using 'ethtool'. (4a) Interpretation of error messages and common problems diff --git a/Documentation/networking/bonding.txt b/Documentation/networking/bonding.txt index d5181ce9ff62..61f516b135b4 100644 --- a/Documentation/networking/bonding.txt +++ b/Documentation/networking/bonding.txt @@ -1,7 +1,7 @@ Linux Ethernet Bonding Driver HOWTO - Latest update: 12 November 2007 + Latest update: 23 September 2009 Initial release : Thomas Davis <tadavis at lbl.gov> Corrections, HA extensions : 2000/10/03-15 : @@ -614,6 +614,46 @@ primary The primary option is only valid for active-backup mode. +primary_reselect + + Specifies the reselection policy for the primary slave. This + affects how the primary slave is chosen to become the active slave + when failure of the active slave or recovery of the primary slave + occurs. This option is designed to prevent flip-flopping between + the primary slave and other slaves. Possible values are: + + always or 0 (default) + + The primary slave becomes the active slave whenever it + comes back up. + + better or 1 + + The primary slave becomes the active slave when it comes + back up, if the speed and duplex of the primary slave is + better than the speed and duplex of the current active + slave. + + failure or 2 + + The primary slave becomes the active slave only if the + current active slave fails and the primary slave is up. + + The primary_reselect setting is ignored in two cases: + + If no slaves are active, the first slave to recover is + made the active slave. + + When initially enslaved, the primary slave is always made + the active slave. + + Changing the primary_reselect policy via sysfs will cause an + immediate selection of the best active slave according to the new + policy. This may or may not result in a change of the active + slave, depending upon the circumstances. + + This option was added for bonding version 3.6.0. + updelay Specifies the time, in milliseconds, to wait before enabling a diff --git a/Documentation/networking/ieee802154.txt b/Documentation/networking/ieee802154.txt index a0280ad2edc9..23c995e64032 100644 --- a/Documentation/networking/ieee802154.txt +++ b/Documentation/networking/ieee802154.txt @@ -22,7 +22,7 @@ int sd = socket(PF_IEEE802154, SOCK_DGRAM, 0); ..... The address family, socket addresses etc. are defined in the -include/net/ieee802154/af_ieee802154.h header or in the special header +include/net/af_ieee802154.h header or in the special header in our userspace package (see either linux-zigbee sourceforge download page or git tree at git://linux-zigbee.git.sourceforge.net/gitroot/linux-zigbee). @@ -33,7 +33,7 @@ MLME - MAC Level Management ============================ Most of IEEE 802.15.4 MLME interfaces are directly mapped on netlink commands. -See the include/net/ieee802154/nl802154.h header. Our userspace tools package +See the include/net/nl802154.h header. Our userspace tools package (see above) provides CLI configuration utility for radio interfaces and simple coordinator for IEEE 802.15.4 networks as an example users of MLME protocol. @@ -54,10 +54,14 @@ Those types of devices require different approach to be hooked into Linux kernel HardMAC ======= -See the header include/net/ieee802154/netdevice.h. You have to implement Linux +See the header include/net/ieee802154_netdev.h. You have to implement Linux net_device, with .type = ARPHRD_IEEE802154. Data is exchanged with socket family -code via plain sk_buffs. The control block of sk_buffs will contain additional -info as described in the struct ieee802154_mac_cb. +code via plain sk_buffs. On skb reception skb->cb must contain additional +info as described in the struct ieee802154_mac_cb. During packet transmission +the skb->cb is used to provide additional data to device's header_ops->create +function. Be aware, that this data can be overriden later (when socket code +submits skb to qdisc), so if you need something from that cb later, you should +store info in the skb->data on your own. To hook the MLME interface you have to populate the ml_priv field of your net_device with a pointer to struct ieee802154_mlme_ops instance. All fields are @@ -69,8 +73,8 @@ We provide an example of simple HardMAC driver at drivers/ieee802154/fakehard.c SoftMAC ======= -We are going to provide intermediate layer impelementing IEEE 802.15.4 MAC +We are going to provide intermediate layer implementing IEEE 802.15.4 MAC in software. This is currently WIP. -See header include/net/ieee802154/mac802154.h and several drivers in -drivers/ieee802154/ +See header include/net/mac802154.h and several drivers in drivers/ieee802154/. + diff --git a/Documentation/networking/ip-sysctl.txt b/Documentation/networking/ip-sysctl.txt index 8be76235fe67..006b39dec87d 100644 --- a/Documentation/networking/ip-sysctl.txt +++ b/Documentation/networking/ip-sysctl.txt @@ -164,6 +164,14 @@ tcp_congestion_control - STRING additional choices may be available based on kernel configuration. Default is set as part of kernel configuration. +tcp_cookie_size - INTEGER + Default size of TCP Cookie Transactions (TCPCT) option, that may be + overridden on a per socket basis by the TCPCT socket option. + Values greater than the maximum (16) are interpreted as the maximum. + Values greater than zero and less than the minimum (8) are interpreted + as the minimum. Odd values are interpreted as the next even value. + Default: 0 (off). + tcp_dsack - BOOLEAN Allows TCP to send "duplicate" SACKs. @@ -311,9 +319,12 @@ tcp_no_metrics_save - BOOLEAN connections. tcp_orphan_retries - INTEGER - How may times to retry before killing TCP connection, closed - by our side. Default value 7 corresponds to ~50sec-16min - depending on RTO. If you machine is loaded WEB server, + This value influences the timeout of a locally closed TCP connection, + when RTO retransmissions remain unacknowledged. + See tcp_retries2 for more details. + + The default value is 7. + If your machine is a loaded WEB server, you should think about lowering this value, such sockets may consume significant resources. Cf. tcp_max_orphans. @@ -327,16 +338,28 @@ tcp_retrans_collapse - BOOLEAN certain TCP stacks. tcp_retries1 - INTEGER - How many times to retry before deciding that something is wrong - and it is necessary to report this suspicion to network layer. - Minimal RFC value is 3, it is default, which corresponds - to ~3sec-8min depending on RTO. + This value influences the time, after which TCP decides, that + something is wrong due to unacknowledged RTO retransmissions, + and reports this suspicion to the network layer. + See tcp_retries2 for more details. + + RFC 1122 recommends at least 3 retransmissions, which is the + default. tcp_retries2 - INTEGER - How may times to retry before killing alive TCP connection. - RFC1122 says that the limit should be longer than 100 sec. - It is too small number. Default value 15 corresponds to ~13-30min - depending on RTO. + This value influences the timeout of an alive TCP connection, + when RTO retransmissions remain unacknowledged. + Given a value of N, a hypothetical TCP connection following + exponential backoff with an initial RTO of TCP_RTO_MIN would + retransmit N times before killing the connection at the (N+1)th RTO. + + The default value of 15 yields a hypothetical timeout of 924.6 + seconds and is a lower bound for the effective timeout. + TCP will effectively time out at the first RTO which exceeds the + hypothetical timeout. + + RFC 1122 recommends at least 100 seconds for the timeout, + which corresponds to a value of at least 8. tcp_rfc1337 - BOOLEAN If set, the TCP stack behaves conforming to RFC1337. If unset, @@ -708,6 +731,12 @@ accept_source_route - BOOLEAN default TRUE (router) FALSE (host) +accept_local - BOOLEAN + Accept packets with local source addresses. In combination with + suitable routing, this can be used to direct packets between two + local interfaces over the wire and have them accepted properly. + default FALSE + rp_filter - INTEGER 0 - No source validation. 1 - Strict mode as defined in RFC3704 Strict Reverse Path @@ -723,8 +752,8 @@ rp_filter - INTEGER to prevent IP spoofing from DDos attacks. If using asymmetric routing or other complicated routing, then loose mode is recommended. - conf/all/rp_filter must also be set to non-zero to do source validation - on the interface + The max value from conf/{all,interface}/rp_filter is used + when doing source validation on the {interface}. Default value is 0. Note that some distributions enable it in startup scripts. @@ -1071,6 +1100,24 @@ accept_dad - INTEGER 2: Enable DAD, and disable IPv6 operation if MAC-based duplicate link-local address has been found. +force_tllao - BOOLEAN + Enable sending the target link-layer address option even when + responding to a unicast neighbor solicitation. + Default: FALSE + + Quoting from RFC 2461, section 4.4, Target link-layer address: + + "The option MUST be included for multicast solicitations in order to + avoid infinite Neighbor Solicitation "recursion" when the peer node + does not have a cache entry to return a Neighbor Advertisements + message. When responding to unicast solicitations, the option can be + omitted since the sender of the solicitation has the correct link- + layer address; otherwise it would not have be able to send the unicast + solicitation in the first place. However, including the link-layer + address in this case adds little overhead and eliminates a potential + race condition where the sender deletes the cached link-layer address + prior to receiving a response to a previous solicitation." + icmp/*: ratelimit - INTEGER Limit the maximal rates for sending ICMPv6 packets. @@ -1282,6 +1329,16 @@ sctp_rmem - vector of 3 INTEGERs: min, default, max sctp_wmem - vector of 3 INTEGERs: min, default, max See tcp_wmem for a description. +addr_scope_policy - INTEGER + Control IPv4 address scoping - draft-stewart-tsvwg-sctp-ipv4-00 + + 0 - Disable IPv4 address scoping + 1 - Enable IPv4 address scoping + 2 - Follow draft but allow IPv4 private addresses + 3 - Follow draft but allow IPv4 link local addresses + + Default: 1 + /proc/sys/net/core/* dev_weight - INTEGER diff --git a/Documentation/networking/pktgen.txt b/Documentation/networking/pktgen.txt index c6cf4a3c16e0..61bb645d50e0 100644 --- a/Documentation/networking/pktgen.txt +++ b/Documentation/networking/pktgen.txt @@ -90,6 +90,11 @@ Examples: pgset "dstmac 00:00:00:00:00:00" sets MAC destination address pgset "srcmac 00:00:00:00:00:00" sets MAC source address + pgset "queue_map_min 0" Sets the min value of tx queue interval + pgset "queue_map_max 7" Sets the max value of tx queue interval, for multiqueue devices + To select queue 1 of a given device, + use queue_map_min=1 and queue_map_max=1 + pgset "src_mac_count 1" Sets the number of MACs we'll range through. The 'minimum' MAC is what you set with srcmac. @@ -101,6 +106,9 @@ Examples: IPDST_RND, UDPSRC_RND, UDPDST_RND, MACSRC_RND, MACDST_RND MPLS_RND, VID_RND, SVID_RND + QUEUE_MAP_RND # queue map random + QUEUE_MAP_CPU # queue map mirrors smp_processor_id() + pgset "udp_src_min 9" set UDP source port min, If < udp_src_max, then cycle through the port range. diff --git a/Documentation/networking/regulatory.txt b/Documentation/networking/regulatory.txt index eaa1a25946c1..ee31369e9e5b 100644 --- a/Documentation/networking/regulatory.txt +++ b/Documentation/networking/regulatory.txt @@ -96,7 +96,7 @@ Example code - drivers hinting an alpha2: This example comes from the zd1211rw device driver. You can start by having a mapping of your device's EEPROM country/regulatory -domain value to to a specific alpha2 as follows: +domain value to a specific alpha2 as follows: static struct zd_reg_alpha2_map reg_alpha2_map[] = { { ZD_REGDOMAIN_FCC, "US" }, diff --git a/Documentation/networking/timestamping/timestamping.c b/Documentation/networking/timestamping/timestamping.c index 43d143104210..a7936fe8444a 100644 --- a/Documentation/networking/timestamping/timestamping.c +++ b/Documentation/networking/timestamping/timestamping.c @@ -381,7 +381,7 @@ int main(int argc, char **argv) memset(&hwtstamp, 0, sizeof(hwtstamp)); strncpy(hwtstamp.ifr_name, interface, sizeof(hwtstamp.ifr_name)); hwtstamp.ifr_data = (void *)&hwconfig; - memset(&hwconfig, 0, sizeof(&hwconfig)); + memset(&hwconfig, 0, sizeof(hwconfig)); hwconfig.tx_type = (so_timestamping_flags & SOF_TIMESTAMPING_TX_HARDWARE) ? HWTSTAMP_TX_ON : HWTSTAMP_TX_OFF; diff --git a/Documentation/nommu-mmap.txt b/Documentation/nommu-mmap.txt index b565e8279d13..8e1ddec2c78a 100644 --- a/Documentation/nommu-mmap.txt +++ b/Documentation/nommu-mmap.txt @@ -119,6 +119,32 @@ FURTHER NOTES ON NO-MMU MMAP granule but will only discard the excess if appropriately configured as this has an effect on fragmentation. + (*) The memory allocated by a request for an anonymous mapping will normally + be cleared by the kernel before being returned in accordance with the + Linux man pages (ver 2.22 or later). + + In the MMU case this can be achieved with reasonable performance as + regions are backed by virtual pages, with the contents only being mapped + to cleared physical pages when a write happens on that specific page + (prior to which, the pages are effectively mapped to the global zero page + from which reads can take place). This spreads out the time it takes to + initialize the contents of a page - depending on the write-usage of the + mapping. + + In the no-MMU case, however, anonymous mappings are backed by physical + pages, and the entire map is cleared at allocation time. This can cause + significant delays during a userspace malloc() as the C library does an + anonymous mapping and the kernel then does a memset for the entire map. + + However, for memory that isn't required to be precleared - such as that + returned by malloc() - mmap() can take a MAP_UNINITIALIZED flag to + indicate to the kernel that it shouldn't bother clearing the memory before + returning it. Note that CONFIG_MMAP_ALLOW_UNINITIALIZED must be enabled + to permit this, otherwise the flag will be ignored. + + uClibc uses this to speed up malloc(), and the ELF-FDPIC binfmt uses this + to allocate the brk and stack region. + (*) A list of all the private copy and anonymous mappings on the system is visible through /proc/maps in no-MMU mode. diff --git a/Documentation/numastat.txt b/Documentation/numastat.txt index 80133ace1eb2..9fcc9a608dc0 100644 --- a/Documentation/numastat.txt +++ b/Documentation/numastat.txt @@ -7,10 +7,10 @@ All units are pages. Hugepages have separate counters. numa_hit A process wanted to allocate memory from this node, and succeeded. -numa_miss A process wanted to allocate memory from this node, - but ended up with memory from another. -numa_foreign A process wanted to allocate on another node, - but ended up with memory from this one. +numa_miss A process wanted to allocate memory from another node, + but ended up with memory from this node. +numa_foreign A process wanted to allocate on this node, + but ended up with memory from another one. local_node A process ran on this node and got memory from it. other_node A process ran on this node and got memory from another node. interleave_hit Interleaving wanted to allocate from this node diff --git a/Documentation/oops-tracing.txt b/Documentation/oops-tracing.txt index b152e81da592..c10c022b911c 100644 --- a/Documentation/oops-tracing.txt +++ b/Documentation/oops-tracing.txt @@ -257,6 +257,8 @@ characters, each representing a particular tainted value. 10: 'W' if a warning has previously been issued by the kernel. + 11: 'C' if a staging driver has been loaded. + The primary reason for the 'Tainted: ' string is to tell kernel debuggers if this is a clean kernel or if anything unusual has occurred. Tainting is permanent: even if an offending module is diff --git a/Documentation/pcmcia/crc32hash.c b/Documentation/pcmcia/crc32hash.c index 4210e5abab8a..44f8beea7260 100644 --- a/Documentation/pcmcia/crc32hash.c +++ b/Documentation/pcmcia/crc32hash.c @@ -8,7 +8,7 @@ $ ./crc32hash "Dual Speed" #include <ctype.h> #include <stdlib.h> -unsigned int crc32(unsigned char const *p, unsigned int len) +static unsigned int crc32(unsigned char const *p, unsigned int len) { int i; unsigned int crc = 0; diff --git a/Documentation/pcmcia/driver-changes.txt b/Documentation/pcmcia/driver-changes.txt index 059934363caf..446f43b309df 100644 --- a/Documentation/pcmcia/driver-changes.txt +++ b/Documentation/pcmcia/driver-changes.txt @@ -1,5 +1,17 @@ This file details changes in 2.6 which affect PCMCIA card driver authors: +* no cs_error / CS_CHECK / CONFIG_PCMCIA_DEBUG (as of 2.6.33) + Instead of the cs_error() callback or the CS_CHECK() macro, please use + Linux-style checking of return values, and -- if necessary -- debug + messages using "dev_dbg()" or "pr_debug()". + +* New CIS tuple access (as of 2.6.33) + Instead of pcmcia_get_{first,next}_tuple(), pcmcia_get_tuple_data() and + pcmcia_parse_tuple(), a driver shall use "pcmcia_get_tuple()" if it is + only interested in one (raw) tuple, or "pcmcia_loop_tuple()" if it is + interested in all tuples of one type. To decode the MAC from CISTPL_FUNCE, + a new helper "pcmcia_get_mac_from_cis()" was added. + * New configuration loop helper (as of 2.6.28) By calling pcmcia_loop_config(), a driver can iterate over all available configuration options. During a driver's probe() phase, one doesn't need diff --git a/Documentation/power/power_supply_class.txt b/Documentation/power/power_supply_class.txt index c6cd4956047c..9f16c5178b66 100644 --- a/Documentation/power/power_supply_class.txt +++ b/Documentation/power/power_supply_class.txt @@ -76,6 +76,11 @@ STATUS - this attribute represents operating status (charging, full, discharging (i.e. powering a load), etc.). This corresponds to BATTERY_STATUS_* values, as defined in battery.h. +CHARGE_TYPE - batteries can typically charge at different rates. +This defines trickle and fast charges. For batteries that +are already charged or discharging, 'n/a' can be displayed (or +'unknown', if the status is not known). + HEALTH - represents health of the battery, values corresponds to POWER_SUPPLY_HEALTH_*, defined in battery.h. @@ -108,6 +113,8 @@ relative, time-based measurements. ENERGY_FULL, ENERGY_EMPTY - same as above but for energy. CAPACITY - capacity in percents. +CAPACITY_LEVEL - capacity level. This corresponds to +POWER_SUPPLY_CAPACITY_LEVEL_*. TEMP - temperature of the power supply. TEMP_AMBIENT - ambient temperature. diff --git a/Documentation/power/regulator/consumer.txt b/Documentation/power/regulator/consumer.txt index 5f83fd24ea84..cdebb5145c25 100644 --- a/Documentation/power/regulator/consumer.txt +++ b/Documentation/power/regulator/consumer.txt @@ -104,7 +104,7 @@ to set the limit to 500mA when supplying power. Consumers can control their supply current limit by calling :- -int regulator_set_current_limit(regulator, min_uV, max_uV); +int regulator_set_current_limit(regulator, min_uA, max_uA); Where min_uA and max_uA are the minimum and maximum acceptable current limit in microamps. diff --git a/Documentation/power/regulator/design.txt b/Documentation/power/regulator/design.txt new file mode 100644 index 000000000000..f9b56b72b782 --- /dev/null +++ b/Documentation/power/regulator/design.txt @@ -0,0 +1,33 @@ +Regulator API design notes +========================== + +This document provides a brief, partially structured, overview of some +of the design considerations which impact the regulator API design. + +Safety +------ + + - Errors in regulator configuration can have very serious consequences + for the system, potentially including lasting hardware damage. + - It is not possible to automatically determine the power confugration + of the system - software-equivalent variants of the same chip may + have different power requirments, and not all components with power + requirements are visible to software. + + => The API should make no changes to the hardware state unless it has + specific knowledge that these changes are safe to do perform on + this particular system. + +Consumer use cases +------------------ + + - The overwhelming majority of devices in a system will have no + requirement to do any runtime configuration of their power beyond + being able to turn it on or off. + + - Many of the power supplies in the system will be shared between many + different consumers. + + => The consumer API should be structured so that these use cases are + very easy to handle and so that consumers will work with shared + supplies without any additional effort. diff --git a/Documentation/power/regulator/machine.txt b/Documentation/power/regulator/machine.txt index ce3487d99abe..63728fed620b 100644 --- a/Documentation/power/regulator/machine.txt +++ b/Documentation/power/regulator/machine.txt @@ -87,7 +87,7 @@ static struct platform_device regulator_devices[] = { }, }; /* register regulator 1 device */ -platform_device_register(&wm8350_regulator_devices[0]); +platform_device_register(®ulator_devices[0]); /* register regulator 2 device */ -platform_device_register(&wm8350_regulator_devices[1]); +platform_device_register(®ulator_devices[1]); diff --git a/Documentation/power/regulator/overview.txt b/Documentation/power/regulator/overview.txt index 0cded696ca01..ffd185bb6054 100644 --- a/Documentation/power/regulator/overview.txt +++ b/Documentation/power/regulator/overview.txt @@ -29,7 +29,7 @@ Some terms used in this document:- o PMIC - Power Management IC. An IC that contains numerous regulators - and often contains other susbsystems. + and often contains other subsystems. o Consumer - Electronic device that is supplied power by a regulator. @@ -168,4 +168,4 @@ relevant to non SoC devices and is split into the following four interfaces:- userspace via sysfs. This could be used to help monitor device power consumption and status. - See Documentation/ABI/testing/regulator-sysfs.txt + See Documentation/ABI/testing/sysfs-class-regulator diff --git a/Documentation/power/regulator/regulator.txt b/Documentation/power/regulator/regulator.txt index 4200accb9bba..3f8b528f237e 100644 --- a/Documentation/power/regulator/regulator.txt +++ b/Documentation/power/regulator/regulator.txt @@ -10,8 +10,9 @@ Registration Drivers can register a regulator by calling :- -struct regulator_dev *regulator_register(struct device *dev, - struct regulator_desc *regulator_desc); +struct regulator_dev *regulator_register(struct regulator_desc *regulator_desc, + struct device *dev, struct regulator_init_data *init_data, + void *driver_data); This will register the regulators capabilities and operations to the regulator core. diff --git a/Documentation/power/runtime_pm.txt b/Documentation/power/runtime_pm.txt new file mode 100644 index 000000000000..356fd86f4ea8 --- /dev/null +++ b/Documentation/power/runtime_pm.txt @@ -0,0 +1,433 @@ +Run-time Power Management Framework for I/O Devices + +(C) 2009 Rafael J. Wysocki <rjw@sisk.pl>, Novell Inc. + +1. Introduction + +Support for run-time power management (run-time PM) of I/O devices is provided +at the power management core (PM core) level by means of: + +* The power management workqueue pm_wq in which bus types and device drivers can + put their PM-related work items. It is strongly recommended that pm_wq be + used for queuing all work items related to run-time PM, because this allows + them to be synchronized with system-wide power transitions (suspend to RAM, + hibernation and resume from system sleep states). pm_wq is declared in + include/linux/pm_runtime.h and defined in kernel/power/main.c. + +* A number of run-time PM fields in the 'power' member of 'struct device' (which + is of the type 'struct dev_pm_info', defined in include/linux/pm.h) that can + be used for synchronizing run-time PM operations with one another. + +* Three device run-time PM callbacks in 'struct dev_pm_ops' (defined in + include/linux/pm.h). + +* A set of helper functions defined in drivers/base/power/runtime.c that can be + used for carrying out run-time PM operations in such a way that the + synchronization between them is taken care of by the PM core. Bus types and + device drivers are encouraged to use these functions. + +The run-time PM callbacks present in 'struct dev_pm_ops', the device run-time PM +fields of 'struct dev_pm_info' and the core helper functions provided for +run-time PM are described below. + +2. Device Run-time PM Callbacks + +There are three device run-time PM callbacks defined in 'struct dev_pm_ops': + +struct dev_pm_ops { + ... + int (*runtime_suspend)(struct device *dev); + int (*runtime_resume)(struct device *dev); + int (*runtime_idle)(struct device *dev); + ... +}; + +The ->runtime_suspend(), ->runtime_resume() and ->runtime_idle() callbacks are +executed by the PM core for either the bus type, or device type (if the bus +type's callback is not defined), or device class (if the bus type's and device +type's callbacks are not defined) of given device. The bus type, device type +and device class callbacks are referred to as subsystem-level callbacks in what +follows. + +The subsystem-level suspend callback is _entirely_ _responsible_ for handling +the suspend of the device as appropriate, which may, but need not include +executing the device driver's own ->runtime_suspend() callback (from the +PM core's point of view it is not necessary to implement a ->runtime_suspend() +callback in a device driver as long as the subsystem-level suspend callback +knows what to do to handle the device). + + * Once the subsystem-level suspend callback has completed successfully + for given device, the PM core regards the device as suspended, which need + not mean that the device has been put into a low power state. It is + supposed to mean, however, that the device will not process data and will + not communicate with the CPU(s) and RAM until the subsystem-level resume + callback is executed for it. The run-time PM status of a device after + successful execution of the subsystem-level suspend callback is 'suspended'. + + * If the subsystem-level suspend callback returns -EBUSY or -EAGAIN, + the device's run-time PM status is 'active', which means that the device + _must_ be fully operational afterwards. + + * If the subsystem-level suspend callback returns an error code different + from -EBUSY or -EAGAIN, the PM core regards this as a fatal error and will + refuse to run the helper functions described in Section 4 for the device, + until the status of it is directly set either to 'active', or to 'suspended' + (the PM core provides special helper functions for this purpose). + +In particular, if the driver requires remote wake-up capability (i.e. hardware +mechanism allowing the device to request a change of its power state, such as +PCI PME) for proper functioning and device_run_wake() returns 'false' for the +device, then ->runtime_suspend() should return -EBUSY. On the other hand, if +device_run_wake() returns 'true' for the device and the device is put into a low +power state during the execution of the subsystem-level suspend callback, it is +expected that remote wake-up will be enabled for the device. Generally, remote +wake-up should be enabled for all input devices put into a low power state at +run time. + +The subsystem-level resume callback is _entirely_ _responsible_ for handling the +resume of the device as appropriate, which may, but need not include executing +the device driver's own ->runtime_resume() callback (from the PM core's point of +view it is not necessary to implement a ->runtime_resume() callback in a device +driver as long as the subsystem-level resume callback knows what to do to handle +the device). + + * Once the subsystem-level resume callback has completed successfully, the PM + core regards the device as fully operational, which means that the device + _must_ be able to complete I/O operations as needed. The run-time PM status + of the device is then 'active'. + + * If the subsystem-level resume callback returns an error code, the PM core + regards this as a fatal error and will refuse to run the helper functions + described in Section 4 for the device, until its status is directly set + either to 'active' or to 'suspended' (the PM core provides special helper + functions for this purpose). + +The subsystem-level idle callback is executed by the PM core whenever the device +appears to be idle, which is indicated to the PM core by two counters, the +device's usage counter and the counter of 'active' children of the device. + + * If any of these counters is decreased using a helper function provided by + the PM core and it turns out to be equal to zero, the other counter is + checked. If that counter also is equal to zero, the PM core executes the + subsystem-level idle callback with the device as an argument. + +The action performed by a subsystem-level idle callback is totally dependent on +the subsystem in question, but the expected and recommended action is to check +if the device can be suspended (i.e. if all of the conditions necessary for +suspending the device are satisfied) and to queue up a suspend request for the +device in that case. The value returned by this callback is ignored by the PM +core. + +The helper functions provided by the PM core, described in Section 4, guarantee +that the following constraints are met with respect to the bus type's run-time +PM callbacks: + +(1) The callbacks are mutually exclusive (e.g. it is forbidden to execute + ->runtime_suspend() in parallel with ->runtime_resume() or with another + instance of ->runtime_suspend() for the same device) with the exception that + ->runtime_suspend() or ->runtime_resume() can be executed in parallel with + ->runtime_idle() (although ->runtime_idle() will not be started while any + of the other callbacks is being executed for the same device). + +(2) ->runtime_idle() and ->runtime_suspend() can only be executed for 'active' + devices (i.e. the PM core will only execute ->runtime_idle() or + ->runtime_suspend() for the devices the run-time PM status of which is + 'active'). + +(3) ->runtime_idle() and ->runtime_suspend() can only be executed for a device + the usage counter of which is equal to zero _and_ either the counter of + 'active' children of which is equal to zero, or the 'power.ignore_children' + flag of which is set. + +(4) ->runtime_resume() can only be executed for 'suspended' devices (i.e. the + PM core will only execute ->runtime_resume() for the devices the run-time + PM status of which is 'suspended'). + +Additionally, the helper functions provided by the PM core obey the following +rules: + + * If ->runtime_suspend() is about to be executed or there's a pending request + to execute it, ->runtime_idle() will not be executed for the same device. + + * A request to execute or to schedule the execution of ->runtime_suspend() + will cancel any pending requests to execute ->runtime_idle() for the same + device. + + * If ->runtime_resume() is about to be executed or there's a pending request + to execute it, the other callbacks will not be executed for the same device. + + * A request to execute ->runtime_resume() will cancel any pending or + scheduled requests to execute the other callbacks for the same device. + +3. Run-time PM Device Fields + +The following device run-time PM fields are present in 'struct dev_pm_info', as +defined in include/linux/pm.h: + + struct timer_list suspend_timer; + - timer used for scheduling (delayed) suspend request + + unsigned long timer_expires; + - timer expiration time, in jiffies (if this is different from zero, the + timer is running and will expire at that time, otherwise the timer is not + running) + + struct work_struct work; + - work structure used for queuing up requests (i.e. work items in pm_wq) + + wait_queue_head_t wait_queue; + - wait queue used if any of the helper functions needs to wait for another + one to complete + + spinlock_t lock; + - lock used for synchronisation + + atomic_t usage_count; + - the usage counter of the device + + atomic_t child_count; + - the count of 'active' children of the device + + unsigned int ignore_children; + - if set, the value of child_count is ignored (but still updated) + + unsigned int disable_depth; + - used for disabling the helper funcions (they work normally if this is + equal to zero); the initial value of it is 1 (i.e. run-time PM is + initially disabled for all devices) + + unsigned int runtime_error; + - if set, there was a fatal error (one of the callbacks returned error code + as described in Section 2), so the helper funtions will not work until + this flag is cleared; this is the error code returned by the failing + callback + + unsigned int idle_notification; + - if set, ->runtime_idle() is being executed + + unsigned int request_pending; + - if set, there's a pending request (i.e. a work item queued up into pm_wq) + + enum rpm_request request; + - type of request that's pending (valid if request_pending is set) + + unsigned int deferred_resume; + - set if ->runtime_resume() is about to be run while ->runtime_suspend() is + being executed for that device and it is not practical to wait for the + suspend to complete; means "start a resume as soon as you've suspended" + + unsigned int run_wake; + - set if the device is capable of generating run-time wake-up events + + enum rpm_status runtime_status; + - the run-time PM status of the device; this field's initial value is + RPM_SUSPENDED, which means that each device is initially regarded by the + PM core as 'suspended', regardless of its real hardware status + +All of the above fields are members of the 'power' member of 'struct device'. + +4. Run-time PM Device Helper Functions + +The following run-time PM helper functions are defined in +drivers/base/power/runtime.c and include/linux/pm_runtime.h: + + void pm_runtime_init(struct device *dev); + - initialize the device run-time PM fields in 'struct dev_pm_info' + + void pm_runtime_remove(struct device *dev); + - make sure that the run-time PM of the device will be disabled after + removing the device from device hierarchy + + int pm_runtime_idle(struct device *dev); + - execute the subsystem-level idle callback for the device; returns 0 on + success or error code on failure, where -EINPROGRESS means that + ->runtime_idle() is already being executed + + int pm_runtime_suspend(struct device *dev); + - execute the subsystem-level suspend callback for the device; returns 0 on + success, 1 if the device's run-time PM status was already 'suspended', or + error code on failure, where -EAGAIN or -EBUSY means it is safe to attempt + to suspend the device again in future + + int pm_runtime_resume(struct device *dev); + - execute the subsystem-leve resume callback for the device; returns 0 on + success, 1 if the device's run-time PM status was already 'active' or + error code on failure, where -EAGAIN means it may be safe to attempt to + resume the device again in future, but 'power.runtime_error' should be + checked additionally + + int pm_request_idle(struct device *dev); + - submit a request to execute the subsystem-level idle callback for the + device (the request is represented by a work item in pm_wq); returns 0 on + success or error code if the request has not been queued up + + int pm_schedule_suspend(struct device *dev, unsigned int delay); + - schedule the execution of the subsystem-level suspend callback for the + device in future, where 'delay' is the time to wait before queuing up a + suspend work item in pm_wq, in milliseconds (if 'delay' is zero, the work + item is queued up immediately); returns 0 on success, 1 if the device's PM + run-time status was already 'suspended', or error code if the request + hasn't been scheduled (or queued up if 'delay' is 0); if the execution of + ->runtime_suspend() is already scheduled and not yet expired, the new + value of 'delay' will be used as the time to wait + + int pm_request_resume(struct device *dev); + - submit a request to execute the subsystem-level resume callback for the + device (the request is represented by a work item in pm_wq); returns 0 on + success, 1 if the device's run-time PM status was already 'active', or + error code if the request hasn't been queued up + + void pm_runtime_get_noresume(struct device *dev); + - increment the device's usage counter + + int pm_runtime_get(struct device *dev); + - increment the device's usage counter, run pm_request_resume(dev) and + return its result + + int pm_runtime_get_sync(struct device *dev); + - increment the device's usage counter, run pm_runtime_resume(dev) and + return its result + + void pm_runtime_put_noidle(struct device *dev); + - decrement the device's usage counter + + int pm_runtime_put(struct device *dev); + - decrement the device's usage counter, run pm_request_idle(dev) and return + its result + + int pm_runtime_put_sync(struct device *dev); + - decrement the device's usage counter, run pm_runtime_idle(dev) and return + its result + + void pm_runtime_enable(struct device *dev); + - enable the run-time PM helper functions to run the device bus type's + run-time PM callbacks described in Section 2 + + int pm_runtime_disable(struct device *dev); + - prevent the run-time PM helper functions from running subsystem-level + run-time PM callbacks for the device, make sure that all of the pending + run-time PM operations on the device are either completed or canceled; + returns 1 if there was a resume request pending and it was necessary to + execute the subsystem-level resume callback for the device to satisfy that + request, otherwise 0 is returned + + void pm_suspend_ignore_children(struct device *dev, bool enable); + - set/unset the power.ignore_children flag of the device + + int pm_runtime_set_active(struct device *dev); + - clear the device's 'power.runtime_error' flag, set the device's run-time + PM status to 'active' and update its parent's counter of 'active' + children as appropriate (it is only valid to use this function if + 'power.runtime_error' is set or 'power.disable_depth' is greater than + zero); it will fail and return error code if the device has a parent + which is not active and the 'power.ignore_children' flag of which is unset + + void pm_runtime_set_suspended(struct device *dev); + - clear the device's 'power.runtime_error' flag, set the device's run-time + PM status to 'suspended' and update its parent's counter of 'active' + children as appropriate (it is only valid to use this function if + 'power.runtime_error' is set or 'power.disable_depth' is greater than + zero) + +It is safe to execute the following helper functions from interrupt context: + +pm_request_idle() +pm_schedule_suspend() +pm_request_resume() +pm_runtime_get_noresume() +pm_runtime_get() +pm_runtime_put_noidle() +pm_runtime_put() +pm_suspend_ignore_children() +pm_runtime_set_active() +pm_runtime_set_suspended() +pm_runtime_enable() + +5. Run-time PM Initialization, Device Probing and Removal + +Initially, the run-time PM is disabled for all devices, which means that the +majority of the run-time PM helper funtions described in Section 4 will return +-EAGAIN until pm_runtime_enable() is called for the device. + +In addition to that, the initial run-time PM status of all devices is +'suspended', but it need not reflect the actual physical state of the device. +Thus, if the device is initially active (i.e. it is able to process I/O), its +run-time PM status must be changed to 'active', with the help of +pm_runtime_set_active(), before pm_runtime_enable() is called for the device. + +However, if the device has a parent and the parent's run-time PM is enabled, +calling pm_runtime_set_active() for the device will affect the parent, unless +the parent's 'power.ignore_children' flag is set. Namely, in that case the +parent won't be able to suspend at run time, using the PM core's helper +functions, as long as the child's status is 'active', even if the child's +run-time PM is still disabled (i.e. pm_runtime_enable() hasn't been called for +the child yet or pm_runtime_disable() has been called for it). For this reason, +once pm_runtime_set_active() has been called for the device, pm_runtime_enable() +should be called for it too as soon as reasonably possible or its run-time PM +status should be changed back to 'suspended' with the help of +pm_runtime_set_suspended(). + +If the default initial run-time PM status of the device (i.e. 'suspended') +reflects the actual state of the device, its bus type's or its driver's +->probe() callback will likely need to wake it up using one of the PM core's +helper functions described in Section 4. In that case, pm_runtime_resume() +should be used. Of course, for this purpose the device's run-time PM has to be +enabled earlier by calling pm_runtime_enable(). + +If the device bus type's or driver's ->probe() or ->remove() callback runs +pm_runtime_suspend() or pm_runtime_idle() or their asynchronous counterparts, +they will fail returning -EAGAIN, because the device's usage counter is +incremented by the core before executing ->probe() and ->remove(). Still, it +may be desirable to suspend the device as soon as ->probe() or ->remove() has +finished, so the PM core uses pm_runtime_idle_sync() to invoke the +subsystem-level idle callback for the device at that time. + +6. Run-time PM and System Sleep + +Run-time PM and system sleep (i.e., system suspend and hibernation, also known +as suspend-to-RAM and suspend-to-disk) interact with each other in a couple of +ways. If a device is active when a system sleep starts, everything is +straightforward. But what should happen if the device is already suspended? + +The device may have different wake-up settings for run-time PM and system sleep. +For example, remote wake-up may be enabled for run-time suspend but disallowed +for system sleep (device_may_wakeup(dev) returns 'false'). When this happens, +the subsystem-level system suspend callback is responsible for changing the +device's wake-up setting (it may leave that to the device driver's system +suspend routine). It may be necessary to resume the device and suspend it again +in order to do so. The same is true if the driver uses different power levels +or other settings for run-time suspend and system sleep. + +During system resume, devices generally should be brought back to full power, +even if they were suspended before the system sleep began. There are several +reasons for this, including: + + * The device might need to switch power levels, wake-up settings, etc. + + * Remote wake-up events might have been lost by the firmware. + + * The device's children may need the device to be at full power in order + to resume themselves. + + * The driver's idea of the device state may not agree with the device's + physical state. This can happen during resume from hibernation. + + * The device might need to be reset. + + * Even though the device was suspended, if its usage counter was > 0 then most + likely it would need a run-time resume in the near future anyway. + + * Always going back to full power is simplest. + +If the device was suspended before the sleep began, then its run-time PM status +will have to be updated to reflect the actual post-system sleep status. The way +to do this is: + + pm_runtime_disable(dev); + pm_runtime_set_active(dev); + pm_runtime_enable(dev); + +The PM core always increments the run-time usage counter before calling the +->prepare() callback and decrements it after calling the ->complete() callback. +Hence disabling run-time PM temporarily like this will not cause any run-time +suspend callbacks to be lost. diff --git a/Documentation/powerpc/dts-bindings/4xx/ppc440spe-adma.txt b/Documentation/powerpc/dts-bindings/4xx/ppc440spe-adma.txt new file mode 100644 index 000000000000..515ebcf1b97d --- /dev/null +++ b/Documentation/powerpc/dts-bindings/4xx/ppc440spe-adma.txt @@ -0,0 +1,93 @@ +PPC440SPe DMA/XOR (DMA Controller and XOR Accelerator) + +Device nodes needed for operation of the ppc440spe-adma driver +are specified hereby. These are I2O/DMA, DMA and XOR nodes +for DMA engines and Memory Queue Module node. The latter is used +by ADMA driver for configuration of RAID-6 H/W capabilities of +the PPC440SPe. In addition to the nodes and properties described +below, the ranges property of PLB node must specify ranges for +DMA devices. + + i) The I2O node + + Required properties: + + - compatible : "ibm,i2o-440spe"; + - reg : <registers mapping> + - dcr-reg : <DCR registers range> + + Example: + + I2O: i2o@400100000 { + compatible = "ibm,i2o-440spe"; + reg = <0x00000004 0x00100000 0x100>; + dcr-reg = <0x060 0x020>; + }; + + + ii) The DMA node + + Required properties: + + - compatible : "ibm,dma-440spe"; + - cell-index : 1 cell, hardware index of the DMA engine + (typically 0x0 and 0x1 for DMA0 and DMA1) + - reg : <registers mapping> + - dcr-reg : <DCR registers range> + - interrupts : <interrupt mapping for DMA0/1 interrupts sources: + 2 sources: DMAx CS FIFO Needs Service IRQ (on UIC0) + and DMA Error IRQ (on UIC1). The latter is common + for both DMA engines>. + - interrupt-parent : needed for interrupt mapping + + Example: + + DMA0: dma0@400100100 { + compatible = "ibm,dma-440spe"; + cell-index = <0>; + reg = <0x00000004 0x00100100 0x100>; + dcr-reg = <0x060 0x020>; + interrupt-parent = <&DMA0>; + interrupts = <0 1>; + #interrupt-cells = <1>; + #address-cells = <0>; + #size-cells = <0>; + interrupt-map = < + 0 &UIC0 0x14 4 + 1 &UIC1 0x16 4>; + }; + + + iii) XOR Accelerator node + + Required properties: + + - compatible : "amcc,xor-accelerator"; + - reg : <registers mapping> + - interrupts : <interrupt mapping for XOR interrupt source> + - interrupt-parent : for interrupt mapping + + Example: + + xor-accel@400200000 { + compatible = "amcc,xor-accelerator"; + reg = <0x00000004 0x00200000 0x400>; + interrupt-parent = <&UIC1>; + interrupts = <0x1f 4>; + }; + + + iv) Memory Queue Module node + + Required properties: + + - compatible : "ibm,mq-440spe"; + - dcr-reg : <DCR registers range> + + Example: + + MQ0: mq { + compatible = "ibm,mq-440spe"; + dcr-reg = <0x040 0x020>; + }; + diff --git a/Documentation/powerpc/dts-bindings/fsl/board.txt b/Documentation/powerpc/dts-bindings/fsl/board.txt index e8b5bc24d0ac..39e941515a36 100644 --- a/Documentation/powerpc/dts-bindings/fsl/board.txt +++ b/Documentation/powerpc/dts-bindings/fsl/board.txt @@ -20,12 +20,16 @@ Required properities: - compatible : should be "fsl,fpga-pixis". - reg : should contain the address and the length of the FPPGA register set. +- interrupt-parent: should specify phandle for the interrupt controller. +- interrupts : should specify event (wakeup) IRQ. Example (MPC8610HPCD): board-control@e8000000 { compatible = "fsl,fpga-pixis"; reg = <0xe8000000 32>; + interrupt-parent = <&mpic>; + interrupts = <8 8>; }; * Freescale BCSR GPIO banks diff --git a/Documentation/powerpc/dts-bindings/fsl/esdhc.txt b/Documentation/powerpc/dts-bindings/fsl/esdhc.txt index 3ed3797b5086..8a0040738969 100644 --- a/Documentation/powerpc/dts-bindings/fsl/esdhc.txt +++ b/Documentation/powerpc/dts-bindings/fsl/esdhc.txt @@ -10,6 +10,8 @@ Required properties: - interrupts : should contain eSDHC interrupt. - interrupt-parent : interrupt source phandle. - clock-frequency : specifies eSDHC base clock frequency. + - sdhci,wp-inverted : (optional) specifies that eSDHC controller + reports inverted write-protect state; - sdhci,1-bit-only : (optional) specifies that a controller can only handle 1-bit data transfers. diff --git a/Documentation/powerpc/dts-bindings/fsl/mpc5200.txt b/Documentation/powerpc/dts-bindings/fsl/mpc5200.txt index 8447fd7090d0..5c6602dbfdc2 100644 --- a/Documentation/powerpc/dts-bindings/fsl/mpc5200.txt +++ b/Documentation/powerpc/dts-bindings/fsl/mpc5200.txt @@ -103,7 +103,22 @@ fsl,mpc5200-gpt nodes --------------------- On the mpc5200 and 5200b, GPT0 has a watchdog timer function. If the board design supports the internal wdt, then the device node for GPT0 should -include the empty property 'fsl,has-wdt'. +include the empty property 'fsl,has-wdt'. Note that this does not activate +the watchdog. The timer will function as a GPT if the timer api is used, and +it will function as watchdog if the watchdog device is used. The watchdog +mode has priority over the gpt mode, i.e. if the watchdog is activated, any +gpt api call to this timer will fail with -EBUSY. + +If you add the property + fsl,wdt-on-boot = <n>; +GPT0 will be marked as in-use watchdog, i.e. blocking every gpt access to it. +If n>0, the watchdog is started with a timeout of n seconds. If n=0, the +configuration of the watchdog is not touched. This is useful in two cases: +- just mark GPT0 as watchdog, blocking gpt accesses, and configure it later; +- do not touch a configuration assigned by the boot loader which supervises + the boot process itself. + +The watchdog will respect the CONFIG_WATCHDOG_NOWAYOUT option. An mpc5200-gpt can be used as a single line GPIO controller. To do so, add the following properties to the gpt node: @@ -178,3 +193,13 @@ External interrupts: external irq3: interrupts = <1 3 n>; 'n' is sense (0: level high, 1: edge rising, 2: edge falling 3: level low) +fsl,mpc5200-mscan nodes +----------------------- +In addition to the required compatible-, reg- and interrupt-properites, you can +also specify which clock source shall be used for the controller: + +- fsl,mscan-clock-source- a string describing the clock source. Valid values + are: "ip" for ip bus clock + "ref" for reference clock (XTAL) + "ref" is default in case this property is not + present. diff --git a/Documentation/powerpc/dts-bindings/fsl/mpic.txt b/Documentation/powerpc/dts-bindings/fsl/mpic.txt new file mode 100644 index 000000000000..71e39cf3215b --- /dev/null +++ b/Documentation/powerpc/dts-bindings/fsl/mpic.txt @@ -0,0 +1,42 @@ +* OpenPIC and its interrupt numbers on Freescale's e500/e600 cores + +The OpenPIC specification does not specify which interrupt source has to +become which interrupt number. This is up to the software implementation +of the interrupt controller. The only requirement is that every +interrupt source has to have an unique interrupt number / vector number. +To accomplish this the current implementation assigns the number zero to +the first source, the number one to the second source and so on until +all interrupt sources have their unique number. +Usually the assigned vector number equals the interrupt number mentioned +in the documentation for a given core / CPU. This is however not true +for the e500 cores (MPC85XX CPUs) where the documentation distinguishes +between internal and external interrupt sources and starts counting at +zero for both of them. + +So what to write for external interrupt source X or internal interrupt +source Y into the device tree? Here is an example: + +The memory map for the interrupt controller in the MPC8544[0] shows, +that the first interrupt source starts at 0x5_0000 (PIC Register Address +Map-Interrupt Source Configuration Registers). This source becomes the +number zero therefore: + External interrupt 0 = interrupt number 0 + External interrupt 1 = interrupt number 1 + External interrupt 2 = interrupt number 2 + ... +Every interrupt number allocates 0x20 bytes register space. So to get +its number it is sufficient to shift the lower 16bits to right by five. +So for the external interrupt 10 we have: + 0x0140 >> 5 = 10 + +After the external sources, the internal sources follow. The in core I2C +controller on the MPC8544 for instance has the internal source number +27. Oo obtain its interrupt number we take the lower 16bits of its memory +address (0x5_0560) and shift it right: + 0x0560 >> 5 = 43 + +Therefore the I2C device node for the MPC8544 CPU has to have the +interrupt number 43 specified in the device tree. + +[0] MPC8544E PowerQUICCTM III, Integrated Host Processor Family Reference Manual + MPC8544ERM Rev. 1 10/2007 diff --git a/Documentation/powerpc/dts-bindings/marvell.txt b/Documentation/powerpc/dts-bindings/marvell.txt index 3708a2fd4747..f1533d91953a 100644 --- a/Documentation/powerpc/dts-bindings/marvell.txt +++ b/Documentation/powerpc/dts-bindings/marvell.txt @@ -32,7 +32,7 @@ prefixed with the string "marvell,", for Marvell Technology Group Ltd. devices. This field represents the number of cells needed to represent the address of the memory-mapped registers of devices within the system controller chip. - - #size-cells : Size representation for for the memory-mapped + - #size-cells : Size representation for the memory-mapped registers within the system controller chip. - #interrupt-cells : Defines the width of cells used to represent interrupts. diff --git a/Documentation/powerpc/dts-bindings/mtd-physmap.txt b/Documentation/powerpc/dts-bindings/mtd-physmap.txt index 667c9bde8699..80152cb567d9 100644 --- a/Documentation/powerpc/dts-bindings/mtd-physmap.txt +++ b/Documentation/powerpc/dts-bindings/mtd-physmap.txt @@ -1,18 +1,19 @@ -CFI or JEDEC memory-mapped NOR flash +CFI or JEDEC memory-mapped NOR flash, MTD-RAM (NVRAM...) Flash chips (Memory Technology Devices) are often used for solid state file systems on embedded devices. - - compatible : should contain the specific model of flash chip(s) - used, if known, followed by either "cfi-flash" or "jedec-flash" - - reg : Address range(s) of the flash chip(s) + - compatible : should contain the specific model of mtd chip(s) + used, if known, followed by either "cfi-flash", "jedec-flash" + or "mtd-ram". + - reg : Address range(s) of the mtd chip(s) It's possible to (optionally) define multiple "reg" tuples so that - non-identical NOR chips can be described in one flash node. - - bank-width : Width (in bytes) of the flash bank. Equal to the + non-identical chips can be described in one node. + - bank-width : Width (in bytes) of the bank. Equal to the device width times the number of interleaved chips. - - device-width : (optional) Width of a single flash chip. If + - device-width : (optional) Width of a single mtd chip. If omitted, assumed to be equal to 'bank-width'. - - #address-cells, #size-cells : Must be present if the flash has + - #address-cells, #size-cells : Must be present if the device has sub-nodes representing partitions (see below). In this case both #address-cells and #size-cells must be equal to 1. @@ -22,24 +23,24 @@ are defined: - vendor-id : Contains the flash chip's vendor id (1 byte). - device-id : Contains the flash chip's device id (1 byte). -In addition to the information on the flash bank itself, the +In addition to the information on the mtd bank itself, the device tree may optionally contain additional information -describing partitions of the flash address space. This can be +describing partitions of the address space. This can be used on platforms which have strong conventions about which -portions of the flash are used for what purposes, but which don't +portions of a flash are used for what purposes, but which don't use an on-flash partition table such as RedBoot. -Each partition is represented as a sub-node of the flash device. +Each partition is represented as a sub-node of the mtd device. Each node's name represents the name of the corresponding -partition of the flash device. +partition of the mtd device. Flash partitions - - reg : The partition's offset and size within the flash bank. - - label : (optional) The label / name for this flash partition. + - reg : The partition's offset and size within the mtd bank. + - label : (optional) The label / name for this partition. If omitted, the label is taken from the node name (excluding the unit address). - read-only : (optional) This parameter, if present, is a hint to - Linux that this flash partition should only be mounted + Linux that this partition should only be mounted read-only. This is usually used for flash partitions containing early-boot firmware images or data which should not be clobbered. @@ -78,3 +79,12 @@ Here an example with multiple "reg" tuples: reg = <0 0x04000000>; }; }; + +An example using SRAM: + + sram@2,0 { + compatible = "samsung,k6f1616u6a", "mtd-ram"; + reg = <2 0 0x00200000>; + bank-width = <2>; + }; + diff --git a/Documentation/powerpc/dts-bindings/nintendo/gamecube.txt b/Documentation/powerpc/dts-bindings/nintendo/gamecube.txt new file mode 100644 index 000000000000..b558585b1aaf --- /dev/null +++ b/Documentation/powerpc/dts-bindings/nintendo/gamecube.txt @@ -0,0 +1,109 @@ + +Nintendo GameCube device tree +============================= + +1) The "flipper" node + + This node represents the multi-function "Flipper" chip, which packages + many of the devices found in the Nintendo GameCube. + + Required properties: + + - compatible : Should be "nintendo,flipper" + +1.a) The Video Interface (VI) node + + Represents the interface between the graphics processor and a external + video encoder. + + Required properties: + + - compatible : should be "nintendo,flipper-vi" + - reg : should contain the VI registers location and length + - interrupts : should contain the VI interrupt + +1.b) The Processor Interface (PI) node + + Represents the data and control interface between the main processor + and graphics and audio processor. + + Required properties: + + - compatible : should be "nintendo,flipper-pi" + - reg : should contain the PI registers location and length + +1.b.i) The "Flipper" interrupt controller node + + Represents the interrupt controller within the "Flipper" chip. + The node for the "Flipper" interrupt controller must be placed under + the PI node. + + Required properties: + + - compatible : should be "nintendo,flipper-pic" + +1.c) The Digital Signal Procesor (DSP) node + + Represents the digital signal processor interface, designed to offload + audio related tasks. + + Required properties: + + - compatible : should be "nintendo,flipper-dsp" + - reg : should contain the DSP registers location and length + - interrupts : should contain the DSP interrupt + +1.c.i) The Auxiliary RAM (ARAM) node + + Represents the non cpu-addressable ram designed mainly to store audio + related information. + The ARAM node must be placed under the DSP node. + + Required properties: + + - compatible : should be "nintendo,flipper-aram" + - reg : should contain the ARAM start (zero-based) and length + +1.d) The Disk Interface (DI) node + + Represents the interface used to communicate with mass storage devices. + + Required properties: + + - compatible : should be "nintendo,flipper-di" + - reg : should contain the DI registers location and length + - interrupts : should contain the DI interrupt + +1.e) The Audio Interface (AI) node + + Represents the interface to the external 16-bit stereo digital-to-analog + converter. + + Required properties: + + - compatible : should be "nintendo,flipper-ai" + - reg : should contain the AI registers location and length + - interrupts : should contain the AI interrupt + +1.f) The Serial Interface (SI) node + + Represents the interface to the four single bit serial interfaces. + The SI is a proprietary serial interface used normally to control gamepads. + It's NOT a RS232-type interface. + + Required properties: + + - compatible : should be "nintendo,flipper-si" + - reg : should contain the SI registers location and length + - interrupts : should contain the SI interrupt + +1.g) The External Interface (EXI) node + + Represents the multi-channel SPI-like interface. + + Required properties: + + - compatible : should be "nintendo,flipper-exi" + - reg : should contain the EXI registers location and length + - interrupts : should contain the EXI interrupt + diff --git a/Documentation/powerpc/dts-bindings/nintendo/wii.txt b/Documentation/powerpc/dts-bindings/nintendo/wii.txt new file mode 100644 index 000000000000..a7e155a023b8 --- /dev/null +++ b/Documentation/powerpc/dts-bindings/nintendo/wii.txt @@ -0,0 +1,184 @@ + +Nintendo Wii device tree +======================== + +0) The root node + + This node represents the Nintendo Wii video game console. + + Required properties: + + - model : Should be "nintendo,wii" + - compatible : Should be "nintendo,wii" + +1) The "hollywood" node + + This node represents the multi-function "Hollywood" chip, which packages + many of the devices found in the Nintendo Wii. + + Required properties: + + - compatible : Should be "nintendo,hollywood" + +1.a) The Video Interface (VI) node + + Represents the interface between the graphics processor and a external + video encoder. + + Required properties: + + - compatible : should be "nintendo,hollywood-vi","nintendo,flipper-vi" + - reg : should contain the VI registers location and length + - interrupts : should contain the VI interrupt + +1.b) The Processor Interface (PI) node + + Represents the data and control interface between the main processor + and graphics and audio processor. + + Required properties: + + - compatible : should be "nintendo,hollywood-pi","nintendo,flipper-pi" + - reg : should contain the PI registers location and length + +1.b.i) The "Flipper" interrupt controller node + + Represents the "Flipper" interrupt controller within the "Hollywood" chip. + The node for the "Flipper" interrupt controller must be placed under + the PI node. + + Required properties: + + - #interrupt-cells : <1> + - compatible : should be "nintendo,flipper-pic" + - interrupt-controller + +1.c) The Digital Signal Procesor (DSP) node + + Represents the digital signal processor interface, designed to offload + audio related tasks. + + Required properties: + + - compatible : should be "nintendo,hollywood-dsp","nintendo,flipper-dsp" + - reg : should contain the DSP registers location and length + - interrupts : should contain the DSP interrupt + +1.d) The Serial Interface (SI) node + + Represents the interface to the four single bit serial interfaces. + The SI is a proprietary serial interface used normally to control gamepads. + It's NOT a RS232-type interface. + + Required properties: + + - compatible : should be "nintendo,hollywood-si","nintendo,flipper-si" + - reg : should contain the SI registers location and length + - interrupts : should contain the SI interrupt + +1.e) The Audio Interface (AI) node + + Represents the interface to the external 16-bit stereo digital-to-analog + converter. + + Required properties: + + - compatible : should be "nintendo,hollywood-ai","nintendo,flipper-ai" + - reg : should contain the AI registers location and length + - interrupts : should contain the AI interrupt + +1.f) The External Interface (EXI) node + + Represents the multi-channel SPI-like interface. + + Required properties: + + - compatible : should be "nintendo,hollywood-exi","nintendo,flipper-exi" + - reg : should contain the EXI registers location and length + - interrupts : should contain the EXI interrupt + +1.g) The Open Host Controller Interface (OHCI) nodes + + Represent the USB 1.x Open Host Controller Interfaces. + + Required properties: + + - compatible : should be "nintendo,hollywood-usb-ohci","usb-ohci" + - reg : should contain the OHCI registers location and length + - interrupts : should contain the OHCI interrupt + +1.h) The Enhanced Host Controller Interface (EHCI) node + + Represents the USB 2.0 Enhanced Host Controller Interface. + + Required properties: + + - compatible : should be "nintendo,hollywood-usb-ehci","usb-ehci" + - reg : should contain the EHCI registers location and length + - interrupts : should contain the EHCI interrupt + +1.i) The Secure Digital Host Controller Interface (SDHCI) nodes + + Represent the Secure Digital Host Controller Interfaces. + + Required properties: + + - compatible : should be "nintendo,hollywood-sdhci","sdhci" + - reg : should contain the SDHCI registers location and length + - interrupts : should contain the SDHCI interrupt + +1.j) The Inter-Processsor Communication (IPC) node + + Represent the Inter-Processor Communication interface. This interface + enables communications between the Broadway and the Starlet processors. + + - compatible : should be "nintendo,hollywood-ipc" + - reg : should contain the IPC registers location and length + - interrupts : should contain the IPC interrupt + +1.k) The "Hollywood" interrupt controller node + + Represents the "Hollywood" interrupt controller within the + "Hollywood" chip. + + Required properties: + + - #interrupt-cells : <1> + - compatible : should be "nintendo,hollywood-pic" + - reg : should contain the controller registers location and length + - interrupt-controller + - interrupts : should contain the cascade interrupt of the "flipper" pic + - interrupt-parent: should contain the phandle of the "flipper" pic + +1.l) The General Purpose I/O (GPIO) controller node + + Represents the dual access 32 GPIO controller interface. + + Required properties: + + - #gpio-cells : <2> + - compatible : should be "nintendo,hollywood-gpio" + - reg : should contain the IPC registers location and length + - gpio-controller + +1.m) The control node + + Represents the control interface used to setup several miscellaneous + settings of the "Hollywood" chip like boot memory mappings, resets, + disk interface mode, etc. + + Required properties: + + - compatible : should be "nintendo,hollywood-control" + - reg : should contain the control registers location and length + +1.n) The Disk Interface (DI) node + + Represents the interface used to communicate with mass storage devices. + + Required properties: + + - compatible : should be "nintendo,hollywood-di" + - reg : should contain the DI registers location and length + - interrupts : should contain the DI interrupt + diff --git a/Documentation/powerpc/dts-bindings/xilinx.txt b/Documentation/powerpc/dts-bindings/xilinx.txt index 80339fe4300b..ea68046bb9cb 100644 --- a/Documentation/powerpc/dts-bindings/xilinx.txt +++ b/Documentation/powerpc/dts-bindings/xilinx.txt @@ -292,4 +292,15 @@ - reg-offset : A value of 3 is required - reg-shift : A value of 2 is required + vii) Xilinx USB Host controller + + The Xilinx USB host controller is EHCI compatible but with a different + base address for the EHCI registers, and it is always a big-endian + USB Host controller. The hardware can be configured as high speed only, + or high speed/full speed hybrid. + + Required properties: + - xlnx,support-usb-fs: A value 0 means the core is built as high speed + only. A value 1 means the core also supports + full speed devices. diff --git a/Documentation/rtc.txt b/Documentation/rtc.txt index 8deffcd68cb8..9104c1062084 100644 --- a/Documentation/rtc.txt +++ b/Documentation/rtc.txt @@ -135,6 +135,30 @@ a high functionality RTC is integrated into the SOC. That system might read the system clock from the discrete RTC, but use the integrated one for all other tasks, because of its greater functionality. +SYSFS INTERFACE +--------------- + +The sysfs interface under /sys/class/rtc/rtcN provides access to various +rtc attributes without requiring the use of ioctls. All dates and times +are in the RTC's timezone, rather than in system time. + +date: RTC-provided date +hctosys: 1 if the RTC provided the system time at boot via the + CONFIG_RTC_HCTOSYS kernel option, 0 otherwise +max_user_freq: The maximum interrupt rate an unprivileged user may request + from this RTC. +name: The name of the RTC corresponding to this sysfs directory +since_epoch: The number of seconds since the epoch according to the RTC +time: RTC-provided time +wakealarm: The time at which the clock will generate a system wakeup + event. This is a one shot wakeup event, so must be reset + after wake if a daily wakeup is required. Format is either + seconds since the epoch or, if there's a leading +, seconds + in the future. + +IOCTL INTERFACE +--------------- + The ioctl() calls supported by /dev/rtc are also supported by the RTC class framework. However, because the chips and systems are not standardized, some PC/AT functionality might not be provided. And in the same way, some @@ -185,6 +209,8 @@ driver returns ENOIOCTLCMD. Some common examples: hardware in the irq_set_freq function. If it isn't, return -EINVAL. If you cannot actually change the frequency, do not define irq_set_freq. + * RTC_PIE_ON, RTC_PIE_OFF: the irq_set_state function will be called. + If all else fails, check out the rtc-test.c driver! diff --git a/Documentation/s390/s390dbf.txt b/Documentation/s390/s390dbf.txt index 2d10053dd97e..ae66f9b90a25 100644 --- a/Documentation/s390/s390dbf.txt +++ b/Documentation/s390/s390dbf.txt @@ -495,6 +495,13 @@ and for each vararg a long value. So e.g. for a debug entry with a format string plus two varargs one would need to allocate a (3 * sizeof(long)) byte data area in the debug_register() function. +IMPORTANT: Using "%s" in sprintf event functions is dangerous. You can only +use "%s" in the sprintf event functions, if the memory for the passed string is +available as long as the debug feature exists. The reason behind this is that +due to performance considerations only a pointer to the string is stored in +the debug feature. If you log a string that is freed afterwards, you will get +an OOPS when inspecting the debug feature, because then the debug feature will +access the already freed memory. NOTE: If using the sprintf view do NOT use other event/exception functions than the sprintf-event and -exception functions. diff --git a/Documentation/scsi/ChangeLog.megaraid b/Documentation/scsi/ChangeLog.megaraid index eaa4801f2ce6..38e9e7cadc90 100644 --- a/Documentation/scsi/ChangeLog.megaraid +++ b/Documentation/scsi/ChangeLog.megaraid @@ -514,7 +514,7 @@ iv. Remove yield() while mailbox handshake in synchronous commands v. Remove redundant __megaraid_busywait_mbox routine -vi. Fix bug in the managment module, which causes a system lockup when the +vi. Fix bug in the management module, which causes a system lockup when the IO module is loaded and then unloaded, followed by executing any management utility. The current version of management module does not handle the adapter unregister properly. diff --git a/Documentation/scsi/ChangeLog.megaraid_sas b/Documentation/scsi/ChangeLog.megaraid_sas index c851ef497795..17ffa0607712 100644 --- a/Documentation/scsi/ChangeLog.megaraid_sas +++ b/Documentation/scsi/ChangeLog.megaraid_sas @@ -1,3 +1,65 @@ +1 Release Date : Tues. July 28, 2009 10:12:45 PST 2009 - + (emaild-id:megaraidlinux@lsi.com) + Bo Yang + +2 Current Version : 00.00.04.12 +3 Older Version : 00.00.04.10 + +1. Change the AEN sys PD update from scsi_scan to + scsi_add_device and scsi_remove_device. +2. Takeoff the debug print-out in aen_polling routine. + +1 Release Date : Thur. July 02, 2009 10:12:45 PST 2009 - + (emaild-id:megaraidlinux@lsi.com) + Bo Yang + +2 Current Version : 00.00.04.10 +3 Older Version : 00.00.04.08 + +1. Add the 3 mins timeout during the controller initialize. +2. Add the fix for 64bit sense date errors. + +1 Release Date : Tues. May 05, 2009 10:12:45 PST 2009 - + (emaild-id:megaraidlinux@lsi.com) + Bo Yang + +2 Current Version : 00.00.04.08 +3 Older Version : 00.00.04.06 + +1. Add the fix of pending in FW after deleted the logic drives. +2. Add the fix of deallocating memory after get pdlist. + +1 Release Date : Tues. March 26, 2009 10:12:45 PST 2009 - + (emaild-id:megaraidlinux@lsi.com) + Bo Yang + +2 Current Version : 00.00.04.06 +3 Older Version : 00.00.04.04 + +1. Add the fix of the driver cmd empty fix of the driver cmd empty. +2. Add the fix of the driver MSM AEN CMD cause the system slow. + +1 Release Date : Tues. March 03, 2009 10:12:45 PST 2009 - + (emaild-id:megaraidlinux@lsi.com) + Bo Yang + +2 Current Version : 00.00.04.04 +3 Older Version : 00.00.04.01 + +1. Add the Tape drive fix to the driver: If the command is for + the tape device, set the pthru timeout to the os layer timeout value. + +2. Add Poll_wait mechanism to Gen-2 Linux driv. + In the aen handler, driver needs to wakeup poll handler similar to + the way it raises SIGIO. + +3. Add new controller new SAS2 support to the driver. + +4. Report the unconfigured PD (system PD) to OS. + +5. Add the IEEE SGL support to the driver + +6. Reasign the Application cmds to SAS2 controller 1 Release Date : Thur.July. 24 11:41:51 PST 2008 - (emaild-id:megaraidlinux@lsi.com) @@ -185,7 +247,7 @@ ii. FW enables WCE bit in Mode Sense cmd for drives that are configured Disks are exposed with WCE=1. User is advised to enable Write Back mode only when the controller has battery backup. At this time Synhronize cache is not supported by the FW. Driver will short-cycle - the cmd and return sucess without sending down to FW. + the cmd and return success without sending down to FW. 1 Release Date : Sun Jan. 14 11:21:32 PDT 2007 - Sumant Patro <Sumant.Patro@lsil.com>/Bo Yang diff --git a/Documentation/scsi/hptiop.txt b/Documentation/scsi/hptiop.txt index a6eb4add1be6..9605179711f4 100644 --- a/Documentation/scsi/hptiop.txt +++ b/Documentation/scsi/hptiop.txt @@ -3,6 +3,25 @@ HIGHPOINT ROCKETRAID 3xxx/4xxx ADAPTER DRIVER (hptiop) Controller Register Map ------------------------- +For RR44xx Intel IOP based adapters, the controller IOP is accessed via PCI BAR0 and BAR2: + + BAR0 offset Register + 0x11C5C Link Interface IRQ Set + 0x11C60 Link Interface IRQ Clear + + BAR2 offset Register + 0x10 Inbound Message Register 0 + 0x14 Inbound Message Register 1 + 0x18 Outbound Message Register 0 + 0x1C Outbound Message Register 1 + 0x20 Inbound Doorbell Register + 0x24 Inbound Interrupt Status Register + 0x28 Inbound Interrupt Mask Register + 0x30 Outbound Interrupt Status Register + 0x34 Outbound Interrupt Mask Register + 0x40 Inbound Queue Port + 0x44 Outbound Queue Port + For Intel IOP based adapters, the controller IOP is accessed via PCI BAR0: BAR0 offset Register @@ -93,7 +112,7 @@ The driver exposes following sysfs attributes: ----------------------------------------------------------------------------- -Copyright (C) 2006-2007 HighPoint Technologies, Inc. All Rights Reserved. +Copyright (C) 2006-2009 HighPoint Technologies, Inc. All Rights Reserved. This file is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of diff --git a/Documentation/scsi/scsi_fc_transport.txt b/Documentation/scsi/scsi_fc_transport.txt index d7f181701dc2..aec6549ab097 100644 --- a/Documentation/scsi/scsi_fc_transport.txt +++ b/Documentation/scsi/scsi_fc_transport.txt @@ -378,7 +378,7 @@ Vport Disable/Enable: int vport_disable(struct fc_vport *vport, bool disable) where: - vport: Is vport to to be enabled or disabled + vport: Is vport to be enabled or disabled disable: If "true", the vport is to be disabled. If "false", the vport is to be enabled. diff --git a/Documentation/serial/hayes-esp.txt b/Documentation/serial/hayes-esp.txt deleted file mode 100644 index 09b5d5856758..000000000000 --- a/Documentation/serial/hayes-esp.txt +++ /dev/null @@ -1,154 +0,0 @@ -HAYES ESP DRIVER VERSION 2.1 - -A big thanks to the people at Hayes, especially Alan Adamson. Their support -has enabled me to provide enhancements to the driver. - -Please report your experiences with this driver to me (arobinso@nyx.net). I -am looking for both positive and negative feedback. - -*** IMPORTANT CHANGES FOR 2.1 *** -Support for PIO mode. Five situations will cause PIO mode to be used: -1) A multiport card is detected. PIO mode will always be used. (8 port cards -do not support DMA). -2) The DMA channel is set to an invalid value (anything other than 1 or 3). -3) The DMA buffer/channel could not be allocated. The port will revert to PIO -mode until it is reopened. -4) Less than a specified number of bytes need to be transferred to/from the -FIFOs. PIO mode will be used for that transfer only. -5) A port needs to do a DMA transfer and another port is already using the -DMA channel. PIO mode will be used for that transfer only. - -Since the Hayes ESP seems to conflict with other cards (notably sound cards) -when using DMA, DMA is turned off by default. To use DMA, it must be turned -on explicitly, either with the "dma=" option described below or with -setserial. A multiport card can be forced into DMA mode by using setserial; -however, most multiport cards don't support DMA. - -The latest version of setserial allows the enhanced configuration of the ESP -card to be viewed and modified. -*** - -This package contains the files needed to compile a module to support the Hayes -ESP card. The drivers are basically a modified version of the serial drivers. - -Features: - -- Uses the enhanced mode of the ESP card, allowing a wider range of - interrupts and features than compatibility mode -- Uses DMA and 16 bit PIO mode to transfer data to and from the ESP's FIFOs, - reducing CPU load -- Supports primary and secondary ports - - -If the driver is compiled as a module, the IRQs to use can be specified by -using the irq= option. The format is: - -irq=[0x100],[0x140],[0x180],[0x200],[0x240],[0x280],[0x300],[0x380] - -The address in brackets is the base address of the card. The IRQ of -nonexistent cards can be set to 0. If an IRQ of a card that does exist is set -to 0, the driver will attempt to guess at the correct IRQ. For example, to set -the IRQ of the card at address 0x300 to 12, the insmod command would be: - -insmod esp irq=0,0,0,0,0,0,12,0 - -The custom divisor can be set by using the divisor= option. The format is the -same as for the irq= option. Each divisor value is a series of hex digits, -with each digit representing the divisor to use for a corresponding port. The -divisor value is constructed RIGHT TO LEFT. Specifying a nonzero divisor value -will automatically set the spd_cust flag. To calculate the divisor to use for -a certain baud rate, divide the port's base baud (generally 921600) by the -desired rate. For example, to set the divisor of the primary port at 0x300 to -4 and the divisor of the secondary port at 0x308 to 8, the insmod command would -be: - -insmod esp divisor=0,0,0,0,0,0,0x84,0 - -The dma= option can be used to set the DMA channel. The channel can be either -1 or 3. Specifying any other value will force the driver to use PIO mode. -For example, to set the DMA channel to 3, the insmod command would be: - -insmod esp dma=3 - -The rx_trigger= and tx_trigger= options can be used to set the FIFO trigger -levels. They specify when the ESP card should send an interrupt. Larger -values will decrease the number of interrupts; however, a value too high may -result in data loss. Valid values are 1 through 1023, with 768 being the -default. For example, to set the receive trigger level to 512 bytes and the -transmit trigger level to 700 bytes, the insmod command would be: - -insmod esp rx_trigger=512 tx_trigger=700 - -The flow_off= and flow_on= options can be used to set the hardware flow off/ -flow on levels. The flow on level must be lower than the flow off level, and -the flow off level should be higher than rx_trigger. Valid values are 1 -through 1023, with 1016 being the default flow off level and 944 being the -default flow on level. For example, to set the flow off level to 1000 bytes -and the flow on level to 935 bytes, the insmod command would be: - -insmod esp flow_off=1000 flow_on=935 - -The rx_timeout= option can be used to set the receive timeout value. This -value indicates how long after receiving the last character that the ESP card -should wait before signalling an interrupt. Valid values are 0 though 255, -with 128 being the default. A value too high will increase latency, and a -value too low will cause unnecessary interrupts. For example, to set the -receive timeout to 255, the insmod command would be: - -insmod esp rx_timeout=255 - -The pio_threshold= option sets the threshold (in number of characters) for -using PIO mode instead of DMA mode. For example, if this value is 32, -transfers of 32 bytes or less will always use PIO mode. - -insmod esp pio_threshold=32 - -Multiple options can be listed on the insmod command line by separating each -option with a space. For example: - -insmod esp dma=3 trigger=512 - -The esp module can be automatically loaded when needed. To cause this to -happen, add the following lines to /etc/modprobe.conf (replacing the last line -with options for your configuration): - -alias char-major-57 esp -alias char-major-58 esp -options esp irq=0,0,0,0,0,0,3,0 divisor=0,0,0,0,0,0,0x4,0 - -You may also need to run 'depmod -a'. - -Devices must be created manually. To create the devices, note the output from -the module after it is inserted. The output will appear in the location where -kernel messages usually appear (usually /var/adm/messages). Create two devices -for each 'tty' mentioned, one with major of 57 and the other with major of 58. -The minor number should be the same as the tty number reported. The commands -would be (replace ? with the tty number): - -mknod /dev/ttyP? c 57 ? -mknod /dev/cup? c 58 ? - -For example, if the following line appears: - -Oct 24 18:17:23 techno kernel: ttyP8 at 0x0140 (irq = 3) is an ESP primary port - -...two devices should be created: - -mknod /dev/ttyP8 c 57 8 -mknod /dev/cup8 c 58 8 - -You may need to set the permissions on the devices: - -chmod 666 /dev/ttyP* -chmod 666 /dev/cup* - -The ESP module and the serial module should not conflict (they can be used at -the same time). After the ESP module has been loaded the ports on the ESP card -will no longer be accessible by the serial driver. - -If I/O errors are experienced when accessing the port, check for IRQ and DMA -conflicts ('cat /proc/interrupts' and 'cat /proc/dma' for a list of IRQs and -DMAs currently in use). - -Enjoy! -Andrew J. Robinson <arobinso@nyx.net> diff --git a/Documentation/serial/tty.txt b/Documentation/serial/tty.txt index 8e65c4498c52..5e5349a4fcd2 100644 --- a/Documentation/serial/tty.txt +++ b/Documentation/serial/tty.txt @@ -42,7 +42,8 @@ TTY side interfaces: open() - Called when the line discipline is attached to the terminal. No other call into the line discipline for this tty will occur until it - completes successfully. Can sleep. + completes successfully. Returning an error will + prevent the ldisc from being attached. Can sleep. close() - This is called on a terminal when the line discipline is being unplugged. At the point of @@ -52,7 +53,7 @@ close() - This is called on a terminal when the line hangup() - Called when the tty line is hung up. The line discipline should cease I/O to the tty. No further calls into the ldisc code will occur. - Can sleep. + The return value is ignored. Can sleep. write() - A process is writing data through the line discipline. Multiple write calls are serialized @@ -83,6 +84,10 @@ ioctl() - Called when an ioctl is handed to the tty layer that might be for the ldisc. Multiple ioctl calls may occur in parallel. May sleep. +compat_ioctl() - Called when a 32 bit ioctl is handed to the tty layer + that might be for the ldisc. Multiple ioctl calls + may occur in parallel. May sleep. + Driver Side Interfaces: receive_buf() - Hand buffers of bytes from the driver to the ldisc diff --git a/Documentation/slow-work.txt b/Documentation/slow-work.txt index ebc50f808ea4..9dbf4470c7e1 100644 --- a/Documentation/slow-work.txt +++ b/Documentation/slow-work.txt @@ -41,6 +41,13 @@ expand files, provided the time taken to do so isn't too long. Operations of both types may sleep during execution, thus tying up the thread loaned to it. +A further class of work item is available, based on the slow work item class: + + (*) Delayed slow work items. + +These are slow work items that have a timer to defer queueing of the item for +a while. + THREAD-TO-CLASS ALLOCATION -------------------------- @@ -64,9 +71,11 @@ USING SLOW WORK ITEMS Firstly, a module or subsystem wanting to make use of slow work items must register its interest: - int ret = slow_work_register_user(); + int ret = slow_work_register_user(struct module *module); -This will return 0 if successful, or a -ve error upon failure. +This will return 0 if successful, or a -ve error upon failure. The module +pointer should be the module interested in using this facility (almost +certainly THIS_MODULE). Slow work items may then be set up by: @@ -93,6 +102,10 @@ Slow work items may then be set up by: or: + delayed_slow_work_init(&myitem, &myitem_ops); + + or: + vslow_work_init(&myitem, &myitem_ops); depending on its class. @@ -102,15 +115,92 @@ A suitably set up work item can then be enqueued for processing: int ret = slow_work_enqueue(&myitem); This will return a -ve error if the thread pool is unable to gain a reference -on the item, 0 otherwise. +on the item, 0 otherwise, or (for delayed work): + + int ret = delayed_slow_work_enqueue(&myitem, my_jiffy_delay); The items are reference counted, so there ought to be no need for a flush -operation. When all a module's slow work items have been processed, and the +operation. But as the reference counting is optional, means to cancel +existing work items are also included: + + cancel_slow_work(&myitem); + cancel_delayed_slow_work(&myitem); + +can be used to cancel pending work. The above cancel function waits for +existing work to have been executed (or prevent execution of them, depending +on timing). + + +When all a module's slow work items have been processed, and the module has no further interest in the facility, it should unregister its interest: - slow_work_unregister_user(); + slow_work_unregister_user(struct module *module); + +The module pointer is used to wait for all outstanding work items for that +module before completing the unregistration. This prevents the put_ref() code +from being taken away before it completes. module should almost certainly be +THIS_MODULE. + + +================ +HELPER FUNCTIONS +================ + +The slow-work facility provides a function by which it can be determined +whether or not an item is queued for later execution: + + bool queued = slow_work_is_queued(struct slow_work *work); + +If it returns false, then the item is not on the queue (it may be executing +with a requeue pending). This can be used to work out whether an item on which +another depends is on the queue, thus allowing a dependent item to be queued +after it. + +If the above shows an item on which another depends not to be queued, then the +owner of the dependent item might need to wait. However, to avoid locking up +the threads unnecessarily be sleeping in them, it can make sense under some +circumstances to return the work item to the queue, thus deferring it until +some other items have had a chance to make use of the yielded thread. + +To yield a thread and defer an item, the work function should simply enqueue +the work item again and return. However, this doesn't work if there's nothing +actually on the queue, as the thread just vacated will jump straight back into +the item's work function, thus busy waiting on a CPU. + +Instead, the item should use the thread to wait for the dependency to go away, +but rather than using schedule() or schedule_timeout() to sleep, it should use +the following function: + + bool requeue = slow_work_sleep_till_thread_needed( + struct slow_work *work, + signed long *_timeout); + +This will add a second wait and then sleep, such that it will be woken up if +either something appears on the queue that could usefully make use of the +thread - and behind which this item can be queued, or if the event the caller +set up to wait for happens. True will be returned if something else appeared +on the queue and this work function should perhaps return, of false if +something else woke it up. The timeout is as for schedule_timeout(). + +For example: + + wq = bit_waitqueue(&my_flags, MY_BIT); + init_wait(&wait); + requeue = false; + do { + prepare_to_wait(wq, &wait, TASK_UNINTERRUPTIBLE); + if (!test_bit(MY_BIT, &my_flags)) + break; + requeue = slow_work_sleep_till_thread_needed(&my_work, + &timeout); + } while (timeout > 0 && !requeue); + finish_wait(wq, &wait); + if (!test_bit(MY_BIT, &my_flags) + goto do_my_thing; + if (requeue) + return; // to slow_work =============== @@ -118,7 +208,8 @@ ITEM OPERATIONS =============== Each work item requires a table of operations of type struct slow_work_ops. -All members are required: +Only ->execute() is required; the getting and putting of a reference and the +describing of an item are all optional. (*) Get a reference on an item: @@ -148,6 +239,16 @@ All members are required: This should perform the work required of the item. It may sleep, it may perform disk I/O and it may wait for locks. + (*) View an item through /proc: + + void (*desc)(struct slow_work *work, struct seq_file *m); + + If supplied, this should print to 'm' a small string describing the work + the item is to do. This should be no more than about 40 characters, and + shouldn't include a newline character. + + See the 'Viewing executing and queued items' section below. + ================== POOL CONFIGURATION @@ -172,3 +273,50 @@ The slow-work thread pool has a number of configurables: is bounded to between 1 and one fewer than the number of active threads. This ensures there is always at least one thread that can process very slow work items, and always at least one thread that won't. + + +================================== +VIEWING EXECUTING AND QUEUED ITEMS +================================== + +If CONFIG_SLOW_WORK_DEBUG is enabled, a debugfs file is made available: + + /sys/kernel/debug/slow_work/runqueue + +through which the list of work items being executed and the queues of items to +be executed may be viewed. The owner of a work item is given the chance to +add some information of its own. + +The contents look something like the following: + + THR PID ITEM ADDR FL MARK DESC + === ===== ================ == ===== ========== + 0 3005 ffff880023f52348 a 952ms FSC: OBJ17d3: LOOK + 1 3006 ffff880024e33668 2 160ms FSC: OBJ17e5 OP60d3b: Write1/Store fl=2 + 2 3165 ffff8800296dd180 a 424ms FSC: OBJ17e4: LOOK + 3 4089 ffff8800262c8d78 a 212ms FSC: OBJ17ea: CRTN + 4 4090 ffff88002792bed8 2 388ms FSC: OBJ17e8 OP60d36: Write1/Store fl=2 + 5 4092 ffff88002a0ef308 2 388ms FSC: OBJ17e7 OP60d2e: Write1/Store fl=2 + 6 4094 ffff88002abaf4b8 2 132ms FSC: OBJ17e2 OP60d4e: Write1/Store fl=2 + 7 4095 ffff88002bb188e0 a 388ms FSC: OBJ17e9: CRTN + vsq - ffff880023d99668 1 308ms FSC: OBJ17e0 OP60f91: Write1/EnQ fl=2 + vsq - ffff8800295d1740 1 212ms FSC: OBJ16be OP4d4b6: Write1/EnQ fl=2 + vsq - ffff880025ba3308 1 160ms FSC: OBJ179a OP58dec: Write1/EnQ fl=2 + vsq - ffff880024ec83e0 1 160ms FSC: OBJ17ae OP599f2: Write1/EnQ fl=2 + vsq - ffff880026618e00 1 160ms FSC: OBJ17e6 OP60d33: Write1/EnQ fl=2 + vsq - ffff880025a2a4b8 1 132ms FSC: OBJ16a2 OP4d583: Write1/EnQ fl=2 + vsq - ffff880023cbe6d8 9 212ms FSC: OBJ17eb: LOOK + vsq - ffff880024d37590 9 212ms FSC: OBJ17ec: LOOK + vsq - ffff880027746cb0 9 212ms FSC: OBJ17ed: LOOK + vsq - ffff880024d37ae8 9 212ms FSC: OBJ17ee: LOOK + vsq - ffff880024d37cb0 9 212ms FSC: OBJ17ef: LOOK + vsq - ffff880025036550 9 212ms FSC: OBJ17f0: LOOK + vsq - ffff8800250368e0 9 212ms FSC: OBJ17f1: LOOK + vsq - ffff880025036aa8 9 212ms FSC: OBJ17f2: LOOK + +In the 'THR' column, executing items show the thread they're occupying and +queued threads indicate which queue they're on. 'PID' shows the process ID of +a slow-work thread that's executing something. 'FL' shows the work item flags. +'MARK' indicates how long since an item was queued or began executing. Lastly, +the 'DESC' column permits the owner of an item to give some information. + diff --git a/Documentation/sound/alsa/ALSA-Configuration.txt b/Documentation/sound/alsa/ALSA-Configuration.txt index 4252697a95d6..8923597bd2bd 100644 --- a/Documentation/sound/alsa/ALSA-Configuration.txt +++ b/Documentation/sound/alsa/ALSA-Configuration.txt @@ -60,6 +60,12 @@ Prior to version 0.9.0rc4 options had a 'snd_' prefix. This was removed. slots - Reserve the slot index for the given driver. This option takes multiple strings. See "Module Autoloading Support" section for details. + debug - Specifies the debug message level + (0 = disable debug prints, 1 = normal debug messages, + 2 = verbose debug messages) + This option appears only when CONFIG_SND_DEBUG=y. + This option can be dynamically changed via sysfs + /sys/modules/snd/parameters/debug file. Module snd-pcm-oss ------------------ @@ -513,6 +519,26 @@ Prior to version 0.9.0rc4 options had a 'snd_' prefix. This was removed. or input, but you may use this module for any application which requires a sound card (like RealPlayer). + pcm_devs - Number of PCM devices assigned to each card + (default = 1, up to 4) + pcm_substreams - Number of PCM substreams assigned to each PCM + (default = 8, up to 128) + hrtimer - Use hrtimer (=1, default) or system timer (=0) + fake_buffer - Fake buffer allocations (default = 1) + + When multiple PCM devices are created, snd-dummy gives different + behavior to each PCM device: + 0 = interleaved with mmap support + 1 = non-interleaved with mmap support + 2 = interleaved without mmap + 3 = non-interleaved without mmap + + As default, snd-dummy drivers doesn't allocate the real buffers + but either ignores read/write or mmap a single dummy page to all + buffer pages, in order to save the resouces. If your apps need + the read/ written buffer data to be consistent, pass fake_buffer=0 + option. + The power-management is supported. Module snd-echo3g @@ -768,6 +794,13 @@ Prior to version 0.9.0rc4 options had a 'snd_' prefix. This was removed. bdl_pos_adj - Specifies the DMA IRQ timing delay in samples. Passing -1 will make the driver to choose the appropriate value based on the controller chip. + patch - Specifies the early "patch" files to modify the HD-audio + setup before initializing the codecs. This option is + available only when CONFIG_SND_HDA_PATCH_LOADER=y is set. + See HD-Audio.txt for details. + beep_mode - Selects the beep registration mode (0=off, 1=on, 2= + dynamic registration via mute switch on/off); the default + value is set via CONFIG_SND_HDA_INPUT_BEEP_MODE kconfig. [Single (global) options] single_cmd - Use single immediate commands to communicate with @@ -1424,6 +1457,7 @@ Prior to version 0.9.0rc4 options had a 'snd_' prefix. This was removed. Module for internal PC-Speaker. + nopcm - Disable PC-Speaker PCM sound. Only beeps remain. nforce_wa - enable NForce chipset workaround. Expect bad sound. This module supports system beeps, some kind of PCM playback and @@ -1601,7 +1635,7 @@ Prior to version 0.9.0rc4 options had a 'snd_' prefix. This was removed. Module snd-sscape ----------------- - Module for ENSONIQ SoundScape PnP cards. + Module for ENSONIQ SoundScape cards. port - Port # (PnP setup) wss_port - WSS Port # (PnP setup) @@ -1609,10 +1643,11 @@ Prior to version 0.9.0rc4 options had a 'snd_' prefix. This was removed. mpu_irq - MPU-401 IRQ # (PnP setup) dma - DMA # (PnP setup) dma2 - 2nd DMA # (PnP setup, -1 to disable) + joystick - Enable gameport - 0 = disable (default), 1 = enable - This module supports multiple cards. ISA PnP must be enabled. - You need sscape_ctl tool in alsa-tools package for loading - the microcode. + This module supports multiple cards. + + The driver requires the firmware loader support on kernel. Module snd-sun-amd7930 (on sparc only) -------------------------------------- diff --git a/Documentation/sound/alsa/ControlNames.txt b/Documentation/sound/alsa/ControlNames.txt index 5b18298e9495..fea65bb6269e 100644 --- a/Documentation/sound/alsa/ControlNames.txt +++ b/Documentation/sound/alsa/ControlNames.txt @@ -18,8 +18,9 @@ SOURCE: Master Master Mono Hardware Master + Speaker (internal speaker) Headphone - PC Speaker + Beep (beep generator) Phone Phone Input Phone Output diff --git a/Documentation/sound/alsa/HD-Audio-Models.txt b/Documentation/sound/alsa/HD-Audio-Models.txt index 939a3dd58148..e72cee9e2a71 100644 --- a/Documentation/sound/alsa/HD-Audio-Models.txt +++ b/Documentation/sound/alsa/HD-Audio-Models.txt @@ -114,8 +114,8 @@ ALC662/663/272 samsung-nc10 Samsung NC10 mini notebook auto auto-config reading BIOS (default) -ALC882/885 -========== +ALC882/883/885/888/889 +====================== 3stack-dig 3-jack with SPDIF I/O 6stack-dig 6-jack digital with SPDIF I/O arima Arima W820Di1 @@ -126,13 +126,10 @@ ALC882/885 mb5 Macbook 5,1 mbp3 Macbook Pro rev3 imac24 iMac 24'' with jack detection + imac91 iMac 9,1 w2jc ASUS W2JC - auto auto-config reading BIOS (default) - -ALC883/888 -========== - 3stack-dig 3-jack with SPDIF I/O - 6stack-dig 6-jack digital with SPDIF I/O + 3stack-2ch-dig 3-jack with SPDIF I/O (ALC883) + alc883-6stack-dig 6-jack digital with SPDIF I/O (ALC883) 3stack-6ch 3-jack 6-channel 3stack-6ch-dig 3-jack 6-channel with SPDIF I/O 6stack-dig-demo 6-jack digital for Intel demo board @@ -140,6 +137,7 @@ ALC883/888 acer-aspire Acer Aspire 9810 acer-aspire-4930g Acer Aspire 4930G acer-aspire-6530g Acer Aspire 6530G + acer-aspire-7730g Acer Aspire 7730G acer-aspire-8930g Acer Aspire 8930G medion Medion Laptops medion-md2 Medion MD2 @@ -155,10 +153,13 @@ ALC883/888 3stack-hp HP machines with 3stack (Lucknow, Samba boards) 6stack-dell Dell machines with 6stack (Inspiron 530) mitac Mitac 8252D + clevo-m540r Clevo M540R (6ch + digital) clevo-m720 Clevo M720 laptop series fujitsu-pi2515 Fujitsu AMILO Pi2515 fujitsu-xa3530 Fujitsu AMILO XA3530 3stack-6ch-intel Intel DG33* boards + intel-alc889a Intel IbexPeak with ALC889A + intel-x58 Intel DX58 with ALC889 asus-p5q ASUS P5Q-EM boards mb31 MacBook 3,1 sony-vaio-tt Sony VAIO TT @@ -209,6 +210,7 @@ AD1884A / AD1883 / AD1984A / AD1984B laptop laptop with HP jack sensing mobile mobile devices with HP jack sensing thinkpad Lenovo Thinkpad X300 + touchsmart HP Touchsmart AD1884 ====== @@ -229,7 +231,7 @@ AD1984 ====== basic default configuration thinkpad Lenovo Thinkpad T61/X61 - dell Dell T3400 + dell_desktop Dell T3400 AD1986A ======= @@ -258,6 +260,7 @@ Conexant 5045 laptop-micsense Laptop with Mic sense (old model fujitsu) laptop-hpmicsense Laptop with HP and Mic senses benq Benq R55E + laptop-hp530 HP 530 laptop test for testing/debugging purpose, almost all controls can be adjusted. Appearing only when compiled with $CONFIG_SND_DEBUG=y @@ -278,9 +281,16 @@ Conexant 5051 hp-dv6736 HP dv6736 lenovo-x200 Lenovo X200 laptop +Conexant 5066 +============= + laptop Basic Laptop config (default) + dell-laptop Dell laptops + olpc-xo-1_5 OLPC XO 1.5 + STAC9200 ======== ref Reference board + oqo OQO Model 2 dell-d21 Dell (unknown) dell-d22 Dell (unknown) dell-d23 Dell (unknown) @@ -350,6 +360,7 @@ STAC9227/9228/9229/927x 5stack-no-fp D965 5stack without front panel dell-3stack Dell Dimension E520 dell-bios Fixes with Dell BIOS setup + volknob Fixes with volume-knob widget 0x24 auto BIOS setup (default) STAC92HD71B* @@ -368,20 +379,29 @@ STAC92HD73* =========== ref Reference board no-jd BIOS setup but without jack-detection + intel Intel DG45* mobos dell-m6-amic Dell desktops/laptops with analog mics dell-m6-dmic Dell desktops/laptops with digital mics dell-m6 Dell desktops/laptops with both type of mics dell-eq Dell desktops/laptops + alienware Alienware M17x auto BIOS setup (default) STAC92HD83* =========== ref Reference board - mic-ref Reference board with power managment for ports + mic-ref Reference board with power management for ports dell-s14 Dell laptop + hp HP laptops with (inverted) mute-LED auto BIOS setup (default) STAC9872 ======== vaio VAIO laptop without SPDIF auto BIOS setup (default) + +Cirrus Logic CS4206/4207 +======================== + mbp55 MacBook Pro 5,5 + imac27 IMac 27 Inch + auto BIOS setup (default) diff --git a/Documentation/sound/alsa/HD-Audio.txt b/Documentation/sound/alsa/HD-Audio.txt index 71ac995b1915..6325bec06a72 100644 --- a/Documentation/sound/alsa/HD-Audio.txt +++ b/Documentation/sound/alsa/HD-Audio.txt @@ -139,6 +139,10 @@ The driver checks PCI SSID and looks through the static configuration table until any matching entry is found. If you have a new machine, you may see a message like below: ------------------------------------------------------------------------ + hda_codec: ALC880: BIOS auto-probing. +------------------------------------------------------------------------ +Meanwhile, in the earlier versions, you would see a message like: +------------------------------------------------------------------------ hda_codec: Unknown model for ALC880, trying auto-probe from BIOS... ------------------------------------------------------------------------ Even if you see such a message, DON'T PANIC. Take a deep breath and @@ -403,6 +407,66 @@ re-configure based on that state, run like below: ------------------------------------------------------------------------ +Early Patching +~~~~~~~~~~~~~~ +When CONFIG_SND_HDA_PATCH_LOADER=y is set, you can pass a "patch" as a +firmware file for modifying the HD-audio setup before initializing the +codec. This can work basically like the reconfiguration via sysfs in +the above, but it does it before the first codec configuration. + +A patch file is a plain text file which looks like below: + +------------------------------------------------------------------------ + [codec] + 0x12345678 0xabcd1234 2 + + [model] + auto + + [pincfg] + 0x12 0x411111f0 + + [verb] + 0x20 0x500 0x03 + 0x20 0x400 0xff + + [hint] + hp_detect = yes +------------------------------------------------------------------------ + +The file needs to have a line `[codec]`. The next line should contain +three numbers indicating the codec vendor-id (0x12345678 in the +example), the codec subsystem-id (0xabcd1234) and the address (2) of +the codec. The rest patch entries are applied to this specified codec +until another codec entry is given. + +The `[model]` line allows to change the model name of the each codec. +In the example above, it will be changed to model=auto. +Note that this overrides the module option. + +After the `[pincfg]` line, the contents are parsed as the initial +default pin-configurations just like `user_pin_configs` sysfs above. +The values can be shown in user_pin_configs sysfs file, too. + +Similarly, the lines after `[verb]` are parsed as `init_verbs` +sysfs entries, and the lines after `[hint]` are parsed as `hints` +sysfs entries, respectively. + +The hd-audio driver reads the file via request_firmware(). Thus, +a patch file has to be located on the appropriate firmware path, +typically, /lib/firmware. For example, when you pass the option +`patch=hda-init.fw`, the file /lib/firmware/hda-init-fw must be +present. + +The patch module option is specific to each card instance, and you +need to give one file name for each instance, separated by commas. +For example, if you have two cards, one for an on-board analog and one +for an HDMI video board, you may pass patch option like below: +------------------------------------------------------------------------ + options snd-hda-intel patch=on-board-patch,hdmi-patch +------------------------------------------------------------------------ + + Power-Saving ~~~~~~~~~~~~ The power-saving is a kind of auto-suspend of the device. When the @@ -560,11 +624,13 @@ hda-verb. The program gives you an easy-to-use GUI stuff for showing the widget information and adjusting the amp values, as well as the proc-compatible output. -The hda-analyzer is a part of alsa.git repository in -alsa-project.org: +The hda-analyzer: - http://git.alsa-project.org/?p=alsa.git;a=tree;f=hda-analyzer +is a part of alsa.git repository in alsa-project.org: + +- git://git.alsa-project.org/alsa.git Codecgraph ~~~~~~~~~~ diff --git a/Documentation/sound/alsa/Procfile.txt b/Documentation/sound/alsa/Procfile.txt index 719a819f8cc2..07301de12cc4 100644 --- a/Documentation/sound/alsa/Procfile.txt +++ b/Documentation/sound/alsa/Procfile.txt @@ -95,7 +95,7 @@ card*/pcm*/xrun_debug It takes an integer value, can be changed by writing to this file, such as - # cat 5 > /proc/asound/card0/pcm0p/xrun_debug + # echo 5 > /proc/asound/card0/pcm0p/xrun_debug The value consists of the following bit flags: bit 0 = Enable XRUN/jiffies debug messages diff --git a/Documentation/spi/spi-summary b/Documentation/spi/spi-summary index 4a02d2508bc8..4884cb33845d 100644 --- a/Documentation/spi/spi-summary +++ b/Documentation/spi/spi-summary @@ -350,7 +350,7 @@ SPI protocol drivers somewhat resemble platform device drivers: .resume = CHIP_resume, }; -The driver core will autmatically attempt to bind this driver to any SPI +The driver core will automatically attempt to bind this driver to any SPI device whose board_info gave a modalias of "CHIP". Your probe() code might look like this unless you're creating a device which is managing a bus (appearing under /sys/class/spi_master). @@ -538,7 +538,7 @@ SPI MESSAGE QUEUE The bulk of the driver will be managing the I/O queue fed by transfer(). That queue could be purely conceptual. For example, a driver used only -for low-frequency sensor acess might be fine using synchronous PIO. +for low-frequency sensor access might be fine using synchronous PIO. But the queue will probably be very real, using message->queue, PIO, often DMA (especially if the root filesystem is in SPI flash), and diff --git a/Documentation/spi/spidev_test.c b/Documentation/spi/spidev_test.c index c1a5aad3c75a..10abd3773e49 100644 --- a/Documentation/spi/spidev_test.c +++ b/Documentation/spi/spidev_test.c @@ -69,7 +69,7 @@ static void transfer(int fd) puts(""); } -void print_usage(const char *prog) +static void print_usage(const char *prog) { printf("Usage: %s [-DsbdlHOLC3]\n", prog); puts(" -D --device device to use (default /dev/spidev1.1)\n" @@ -85,7 +85,7 @@ void print_usage(const char *prog) exit(1); } -void parse_opts(int argc, char *argv[]) +static void parse_opts(int argc, char *argv[]) { while (1) { static const struct option lopts[] = { diff --git a/Documentation/spinlocks.txt b/Documentation/spinlocks.txt index 619699dde593..178c831b907d 100644 --- a/Documentation/spinlocks.txt +++ b/Documentation/spinlocks.txt @@ -1,73 +1,8 @@ -SPIN_LOCK_UNLOCKED and RW_LOCK_UNLOCKED defeat lockdep state tracking and -are hence deprecated. +Lesson 1: Spin locks -Please use DEFINE_SPINLOCK()/DEFINE_RWLOCK() or -__SPIN_LOCK_UNLOCKED()/__RW_LOCK_UNLOCKED() as appropriate for static -initialization. - -Most of the time, you can simply turn: - - static spinlock_t xxx_lock = SPIN_LOCK_UNLOCKED; - -into: - - static DEFINE_SPINLOCK(xxx_lock); - -Static structure member variables go from: - - struct foo bar { - .lock = SPIN_LOCK_UNLOCKED; - }; - -to: - - struct foo bar { - .lock = __SPIN_LOCK_UNLOCKED(bar.lock); - }; - -Declaration of static rw_locks undergo a similar transformation. - -Dynamic initialization, when necessary, may be performed as -demonstrated below. - - spinlock_t xxx_lock; - rwlock_t xxx_rw_lock; - - static int __init xxx_init(void) - { - spin_lock_init(&xxx_lock); - rwlock_init(&xxx_rw_lock); - ... - } - - module_init(xxx_init); - -The following discussion is still valid, however, with the dynamic -initialization of spinlocks or with DEFINE_SPINLOCK, etc., used -instead of SPIN_LOCK_UNLOCKED. - ------------------------ - -On Fri, 2 Jan 1998, Doug Ledford wrote: -> -> I'm working on making the aic7xxx driver more SMP friendly (as well as -> importing the latest FreeBSD sequencer code to have 7895 support) and wanted -> to get some info from you. The goal here is to make the various routines -> SMP safe as well as UP safe during interrupts and other manipulating -> routines. So far, I've added a spin_lock variable to things like my queue -> structs. Now, from what I recall, there are some spin lock functions I can -> use to lock these spin locks from other use as opposed to a (nasty) -> save_flags(); cli(); stuff; restore_flags(); construct. Where do I find -> these routines and go about making use of them? Do they only lock on a -> per-processor basis or can they also lock say an interrupt routine from -> mucking with a queue if the queue routine was manipulating it when the -> interrupt occurred, or should I still use a cli(); based construct on that -> one? - -See <asm/spinlock.h>. The basic version is: - - spinlock_t xxx_lock = SPIN_LOCK_UNLOCKED; +The most basic primitive for locking is spinlock. +static DEFINE_SPINLOCK(xxx_lock); unsigned long flags; @@ -75,13 +10,11 @@ See <asm/spinlock.h>. The basic version is: ... critical section here .. spin_unlock_irqrestore(&xxx_lock, flags); -and the above is always safe. It will disable interrupts _locally_, but the +The above is always safe. It will disable interrupts _locally_, but the spinlock itself will guarantee the global lock, so it will guarantee that there is only one thread-of-control within the region(s) protected by that -lock. - -Note that it works well even under UP - the above sequence under UP -essentially is just the same as doing a +lock. This works well even under UP. The above sequence under UP +essentially is just the same as doing unsigned long flags; @@ -91,15 +24,13 @@ essentially is just the same as doing a so the code does _not_ need to worry about UP vs SMP issues: the spinlocks work correctly under both (and spinlocks are actually more efficient on -architectures that allow doing the "save_flags + cli" in one go because I -don't export that interface normally). +architectures that allow doing the "save_flags + cli" in one operation). + + NOTE! Implications of spin_locks for memory are further described in: -NOTE NOTE NOTE! The reason the spinlock is so much faster than a global -interrupt lock under SMP is exactly because it disables interrupts only on -the local CPU. The spin-lock is safe only when you _also_ use the lock -itself to do locking across CPU's, which implies that EVERYTHING that -touches a shared variable has to agree about the spinlock they want to -use. + Documentation/memory-barriers.txt + (5) LOCK operations. + (6) UNLOCK operations. The above is usually pretty simple (you usually need and want only one spinlock for most things - using more than one spinlock can make things a @@ -120,20 +51,24 @@ and another sequence that does then they are NOT mutually exclusive, and the critical regions can happen at the same time on two different CPU's. That's fine per se, but the critical regions had better be critical for different things (ie they -can't stomp on each other). +can't stomp on each other). The above is a problem mainly if you end up mixing code - for example the routines in ll_rw_block() tend to use cli/sti to protect the atomicity of their actions, and if a driver uses spinlocks instead then you should -think about issues like the above.. +think about issues like the above. This is really the only really hard part about spinlocks: once you start using spinlocks they tend to expand to areas you might not have noticed before, because you have to make sure the spinlocks correctly protect the shared data structures _everywhere_ they are used. The spinlocks are most -easily added to places that are completely independent of other code (ie -internal driver data structures that nobody else ever touches, for -example). +easily added to places that are completely independent of other code (for +example, internal driver data structures that nobody else ever touches). + + NOTE! The spin-lock is safe only when you _also_ use the lock itself + to do locking across CPU's, which implies that EVERYTHING that + touches a shared variable has to agree about the spinlock they want + to use. ---- @@ -141,13 +76,17 @@ Lesson 2: reader-writer spinlocks. If your data accesses have a very natural pattern where you usually tend to mostly read from the shared variables, the reader-writer locks -(rw_lock) versions of the spinlocks are often nicer. They allow multiple +(rw_lock) versions of the spinlocks are sometimes useful. They allow multiple readers to be in the same critical region at once, but if somebody wants -to change the variables it has to get an exclusive write lock. The -routines look the same as above: +to change the variables it has to get an exclusive write lock. - rwlock_t xxx_lock = RW_LOCK_UNLOCKED; + NOTE! reader-writer locks require more atomic memory operations than + simple spinlocks. Unless the reader critical section is long, you + are better off just using spinlocks. +The routines look the same as above: + + rwlock_t xxx_lock = RW_LOCK_UNLOCKED; unsigned long flags; @@ -159,18 +98,21 @@ routines look the same as above: .. read and write exclusive access to the info ... write_unlock_irqrestore(&xxx_lock, flags); -The above kind of lock is useful for complex data structures like linked -lists etc, especially when you know that most of the work is to just -traverse the list searching for entries without changing the list itself, -for example. Then you can use the read lock for that kind of list -traversal, which allows many concurrent readers. Anything that _changes_ -the list will have to get the write lock. +The above kind of lock may be useful for complex data structures like +linked lists, especially searching for entries without changing the list +itself. The read lock allows many concurrent readers. Anything that +_changes_ the list will have to get the write lock. + + NOTE! RCU is better for list traversal, but requires careful + attention to design detail (see Documentation/RCU/listRCU.txt). -Note: you cannot "upgrade" a read-lock to a write-lock, so if you at _any_ +Also, you cannot "upgrade" a read-lock to a write-lock, so if you at _any_ time need to do any changes (even if you don't do it every time), you have -to get the write-lock at the very beginning. I could fairly easily add a -primitive to create a "upgradeable" read-lock, but it hasn't been an issue -yet. Tell me if you'd want one. +to get the write-lock at the very beginning. + + NOTE! We are working hard to remove reader-writer spinlocks in most + cases, so please don't add a new one without consensus. (Instead, see + Documentation/RCU/rcu.txt for complete information.) ---- @@ -233,4 +175,46 @@ indeed), while write-locks need to protect themselves against interrupts. Linus +---- + +Reference information: + +For dynamic initialization, use spin_lock_init() or rwlock_init() as +appropriate: + + spinlock_t xxx_lock; + rwlock_t xxx_rw_lock; + + static int __init xxx_init(void) + { + spin_lock_init(&xxx_lock); + rwlock_init(&xxx_rw_lock); + ... + } + + module_init(xxx_init); + +For static initialization, use DEFINE_SPINLOCK() / DEFINE_RWLOCK() or +__SPIN_LOCK_UNLOCKED() / __RW_LOCK_UNLOCKED() as appropriate. + +SPIN_LOCK_UNLOCKED and RW_LOCK_UNLOCKED are deprecated. These interfere +with lockdep state tracking. + +Most of the time, you can simply turn: + static spinlock_t xxx_lock = SPIN_LOCK_UNLOCKED; +into: + static DEFINE_SPINLOCK(xxx_lock); + +Static structure member variables go from: + + struct foo bar { + .lock = SPIN_LOCK_UNLOCKED; + }; + +to: + struct foo bar { + .lock = __SPIN_LOCK_UNLOCKED(bar.lock); + }; + +Declaration of static rw_locks undergo a similar transformation. diff --git a/Documentation/stable_kernel_rules.txt b/Documentation/stable_kernel_rules.txt index a452227361b1..5effa5bd993b 100644 --- a/Documentation/stable_kernel_rules.txt +++ b/Documentation/stable_kernel_rules.txt @@ -26,13 +26,33 @@ Procedure for submitting patches to the -stable tree: - Send the patch, after verifying that it follows the above rules, to stable@kernel.org. + - To have the patch automatically included in the stable tree, add the + the tag + Cc: stable@kernel.org + in the sign-off area. Once the patch is merged it will be applied to + the stable tree without anything else needing to be done by the author + or subsystem maintainer. + - If the patch requires other patches as prerequisites which can be + cherry-picked than this can be specified in the following format in + the sign-off area: + + Cc: <stable@kernel.org> # .32.x: a1f84a3: sched: Check for idle + Cc: <stable@kernel.org> # .32.x: 1b9508f: sched: Rate-limit newidle + Cc: <stable@kernel.org> # .32.x: fd21073: sched: Fix affinity logic + Cc: <stable@kernel.org> # .32.x + Signed-off-by: Ingo Molnar <mingo@elte.hu> + + The tag sequence has the meaning of: + git cherry-pick a1f84a3 + git cherry-pick 1b9508f + git cherry-pick fd21073 + git cherry-pick <this commit> + - The sender will receive an ACK when the patch has been accepted into the queue, or a NAK if the patch is rejected. This response might take a few days, according to the developer's schedules. - If accepted, the patch will be added to the -stable queue, for review by other developers and by the relevant subsystem maintainer. - - If the stable@kernel.org address is added to a patch, when it goes into - Linus's tree it will automatically be emailed to the stable team. - Security patches should not be sent to this alias, but instead to the documented security@kernel.org address. diff --git a/Documentation/sysctl/ctl_unnumbered.txt b/Documentation/sysctl/ctl_unnumbered.txt deleted file mode 100644 index 23003a8ea3e7..000000000000 --- a/Documentation/sysctl/ctl_unnumbered.txt +++ /dev/null @@ -1,22 +0,0 @@ - -Except for a few extremely rare exceptions user space applications do not use -the binary sysctl interface. Instead everyone uses /proc/sys/... with -readable ascii names. - -Recently the kernel has started supporting setting the binary sysctl value to -CTL_UNNUMBERED so we no longer need to assign a binary sysctl path to allow -sysctls to show up in /proc/sys. - -Assigning binary sysctl numbers is an endless source of conflicts in sysctl.h, -breaking of the user space ABI (because of those conflicts), and maintenance -problems. A complete pass through all of the sysctl users revealed multiple -instances where the sysctl binary interface was broken and had gone undetected -for years. - -So please do not add new binary sysctl numbers. They are unneeded and -problematic. - -If you really need a new binary sysctl number please first merge your sysctl -into the kernel and then as a separate patch allocate a binary sysctl number. - -(ebiederm@xmission.com, June 2007) diff --git a/Documentation/sysctl/fs.txt b/Documentation/sysctl/fs.txt index 1458448436cc..62682500878a 100644 --- a/Documentation/sysctl/fs.txt +++ b/Documentation/sysctl/fs.txt @@ -96,13 +96,16 @@ handles that the Linux kernel will allocate. When you get lots of error messages about running out of file handles, you might want to increase this limit. -The three values in file-nr denote the number of allocated -file handles, the number of unused file handles and the maximum -number of file handles. When the allocated file handles come -close to the maximum, but the number of unused file handles is -significantly greater than 0, you've encountered a peak in your -usage of file handles and you don't need to increase the maximum. - +Historically, the three values in file-nr denoted the number of +allocated file handles, the number of allocated but unused file +handles, and the maximum number of file handles. Linux 2.6 always +reports 0 as the number of free file handles -- this is not an +error, it just means that the number of allocated file handles +exactly matches the number of used file handles. + +Attempts to allocate more file descriptors than file-max are +reported with printk, look for "VFS: file-max limit <number> +reached". ============================================================== nr_open: diff --git a/Documentation/sysctl/kernel.txt b/Documentation/sysctl/kernel.txt index 322a00bb99d9..3894eaa23486 100644 --- a/Documentation/sysctl/kernel.txt +++ b/Documentation/sysctl/kernel.txt @@ -19,8 +19,12 @@ Currently, these files might (depending on your configuration) show up in /proc/sys/kernel: - acpi_video_flags - acct +- bootloader_type [ X86 only ] +- bootloader_version [ X86 only ] +- callhome [ S390 only ] - auto_msgmni - core_pattern +- core_pipe_limit - core_uses_pid - ctrl-alt-del - dentry-state @@ -91,6 +95,50 @@ valid for 30 seconds. ============================================================== +bootloader_type: + +x86 bootloader identification + +This gives the bootloader type number as indicated by the bootloader, +shifted left by 4, and OR'd with the low four bits of the bootloader +version. The reason for this encoding is that this used to match the +type_of_loader field in the kernel header; the encoding is kept for +backwards compatibility. That is, if the full bootloader type number +is 0x15 and the full version number is 0x234, this file will contain +the value 340 = 0x154. + +See the type_of_loader and ext_loader_type fields in +Documentation/x86/boot.txt for additional information. + +============================================================== + +bootloader_version: + +x86 bootloader version + +The complete bootloader version number. In the example above, this +file will contain the value 564 = 0x234. + +See the type_of_loader and ext_loader_ver fields in +Documentation/x86/boot.txt for additional information. + +============================================================== + +callhome: + +Controls the kernel's callhome behavior in case of a kernel panic. + +The s390 hardware allows an operating system to send a notification +to a service organization (callhome) in case of an operating system panic. + +When the value in this file is 0 (which is the default behavior) +nothing happens in case of a kernel panic. If this value is set to "1" +the complete kernel oops message is send to the IBM customer service +organization in case the mainframe the Linux operating system is running +on has a service contract with IBM. + +============================================================== + core_pattern: core_pattern is used to specify a core dumpfile pattern name. @@ -119,6 +167,27 @@ core_pattern is used to specify a core dumpfile pattern name. ============================================================== +core_pipe_limit: + +This sysctl is only applicable when core_pattern is configured to pipe core +files to a user space helper (when the first character of core_pattern is a '|', +see above). When collecting cores via a pipe to an application, it is +occasionally useful for the collecting application to gather data about the +crashing process from its /proc/pid directory. In order to do this safely, the +kernel must wait for the collecting process to exit, so as not to remove the +crashing processes proc files prematurely. This in turn creates the possibility +that a misbehaving userspace collecting process can block the reaping of a +crashed process simply by never exiting. This sysctl defends against that. It +defines how many concurrent crashing processes may be piped to user space +applications in parallel. If this value is exceeded, then those crashing +processes above that value are noted via the kernel log and their cores are +skipped. 0 is a special value, indicating that unlimited processes may be +captured in parallel, but that no waiting will take place (i.e. the collecting +process is not guaranteed access to /proc/<crashing pid>/). This value defaults +to 0. + +============================================================== + core_uses_pid: The default coredump filename is "core". By setting @@ -297,31 +366,43 @@ send before ratelimiting kicks in. ============================================================== +printk_delay: + +Delay each printk message in printk_delay milliseconds + +Value from 0 - 10000 is allowed. + +============================================================== + randomize-va-space: This option can be used to select the type of process address space randomization that is used in the system, for architectures that support this feature. -0 - Turn the process address space randomization off by default. +0 - Turn the process address space randomization off. This is the + default for architectures that do not support this feature anyways, + and kernels that are booted with the "norandmaps" parameter. 1 - Make the addresses of mmap base, stack and VDSO page randomized. This, among other things, implies that shared libraries will be - loaded to random addresses. Also for PIE-linked binaries, the location - of code start is randomized. + loaded to random addresses. Also for PIE-linked binaries, the + location of code start is randomized. This is the default if the + CONFIG_COMPAT_BRK option is enabled. + +2 - Additionally enable heap randomization. This is the default if + CONFIG_COMPAT_BRK is disabled. - With heap randomization, the situation is a little bit more - complicated. - There a few legacy applications out there (such as some ancient + There are a few legacy applications out there (such as some ancient versions of libc.so.5 from 1996) that assume that brk area starts - just after the end of the code+bss. These applications break when - start of the brk area is randomized. There are however no known + just after the end of the code+bss. These applications break when + start of the brk area is randomized. There are however no known non-legacy applications that would be broken this way, so for most - systems it is safe to choose full randomization. However there is - a CONFIG_COMPAT_BRK option for systems with ancient and/or broken - binaries, that makes heap non-randomized, but keeps all other - parts of process address space randomized if randomize_va_space - sysctl is turned on. + systems it is safe to choose full randomization. + + Systems with ancient and/or broken binaries should be configured + with CONFIG_COMPAT_BRK enabled, which excludes the heap from process + address space randomization. ============================================================== diff --git a/Documentation/sysctl/vm.txt b/Documentation/sysctl/vm.txt index c4de6359d440..fc5790d36cd9 100644 --- a/Documentation/sysctl/vm.txt +++ b/Documentation/sysctl/vm.txt @@ -32,6 +32,8 @@ Currently, these files are in /proc/sys/vm: - legacy_va_layout - lowmem_reserve_ratio - max_map_count +- memory_failure_early_kill +- memory_failure_recovery - min_free_kbytes - min_slab_ratio - min_unmapped_ratio @@ -53,7 +55,6 @@ Currently, these files are in /proc/sys/vm: - vfs_cache_pressure - zone_reclaim_mode - ============================================================== block_dump @@ -275,6 +276,44 @@ e.g., up to one or two maps per allocation. The default value is 65536. +============================================================= + +memory_failure_early_kill: + +Control how to kill processes when uncorrected memory error (typically +a 2bit error in a memory module) is detected in the background by hardware +that cannot be handled by the kernel. In some cases (like the page +still having a valid copy on disk) the kernel will handle the failure +transparently without affecting any applications. But if there is +no other uptodate copy of the data it will kill to prevent any data +corruptions from propagating. + +1: Kill all processes that have the corrupted and not reloadable page mapped +as soon as the corruption is detected. Note this is not supported +for a few types of pages, like kernel internally allocated data or +the swap cache, but works for the majority of user pages. + +0: Only unmap the corrupted page from all processes and only kill a process +who tries to access it. + +The kill is done using a catchable SIGBUS with BUS_MCEERR_AO, so processes can +handle this if they want to. + +This is only active on architectures/platforms with advanced machine +check handling and depends on the hardware capabilities. + +Applications can override this setting individually with the PR_MCE_KILL prctl + +============================================================== + +memory_failure_recovery + +Enable memory failure recovery (when supported by the platform) + +1: Attempt recovery. + +0: Always panic on a memory failure. + ============================================================== min_free_kbytes: @@ -331,7 +370,7 @@ The default is 1 percent. mmap_min_addr This file indicates the amount of address space which a user process will -be restricted from mmaping. Since kernel null dereference bugs could +be restricted from mmapping. Since kernel null dereference bugs could accidentally operate based on the information in the first couple of pages of memory userspace processes should not be allowed to write to them. By default this value is set to 0 and no protections will be enforced by the @@ -585,7 +624,9 @@ caching of directory and inode objects. At the default value of vfs_cache_pressure=100 the kernel will attempt to reclaim dentries and inodes at a "fair" rate with respect to pagecache and swapcache reclaim. Decreasing vfs_cache_pressure causes the kernel to prefer -to retain dentry and inode caches. Increasing vfs_cache_pressure beyond 100 +to retain dentry and inode caches. When vfs_cache_pressure=0, the kernel will +never reclaim dentries and inodes due to memory pressure and this can easily +lead to out-of-memory conditions. Increasing vfs_cache_pressure beyond 100 causes the kernel to prefer to reclaim dentries and inodes. ============================================================== diff --git a/Documentation/thermal/sysfs-api.txt b/Documentation/thermal/sysfs-api.txt index 70d68ce8640a..cb3d15bc1aeb 100644 --- a/Documentation/thermal/sysfs-api.txt +++ b/Documentation/thermal/sysfs-api.txt @@ -1,5 +1,5 @@ Generic Thermal Sysfs driver How To -========================= +=================================== Written by Sujith Thomas <sujith.thomas@intel.com>, Zhang Rui <rui.zhang@intel.com> @@ -10,20 +10,20 @@ Copyright (c) 2008 Intel Corporation 0. Introduction -The generic thermal sysfs provides a set of interfaces for thermal zone devices (sensors) -and thermal cooling devices (fan, processor...) to register with the thermal management -solution and to be a part of it. +The generic thermal sysfs provides a set of interfaces for thermal zone +devices (sensors) and thermal cooling devices (fan, processor...) to register +with the thermal management solution and to be a part of it. -This how-to focuses on enabling new thermal zone and cooling devices to participate -in thermal management. -This solution is platform independent and any type of thermal zone devices and -cooling devices should be able to make use of the infrastructure. +This how-to focuses on enabling new thermal zone and cooling devices to +participate in thermal management. +This solution is platform independent and any type of thermal zone devices +and cooling devices should be able to make use of the infrastructure. -The main task of the thermal sysfs driver is to expose thermal zone attributes as well -as cooling device attributes to the user space. -An intelligent thermal management application can make decisions based on inputs -from thermal zone attributes (the current temperature and trip point temperature) -and throttle appropriate devices. +The main task of the thermal sysfs driver is to expose thermal zone attributes +as well as cooling device attributes to the user space. +An intelligent thermal management application can make decisions based on +inputs from thermal zone attributes (the current temperature and trip point +temperature) and throttle appropriate devices. [0-*] denotes any positive number starting from 0 [1-*] denotes any positive number starting from 1 @@ -31,77 +31,77 @@ and throttle appropriate devices. 1. thermal sysfs driver interface functions 1.1 thermal zone device interface -1.1.1 struct thermal_zone_device *thermal_zone_device_register(char *name, int trips, - void *devdata, struct thermal_zone_device_ops *ops) - - This interface function adds a new thermal zone device (sensor) to - /sys/class/thermal folder as thermal_zone[0-*]. - It tries to bind all the thermal cooling devices registered at the same time. - - name: the thermal zone name. - trips: the total number of trip points this thermal zone supports. - devdata: device private data - ops: thermal zone device call-backs. - .bind: bind the thermal zone device with a thermal cooling device. - .unbind: unbind the thermal zone device with a thermal cooling device. - .get_temp: get the current temperature of the thermal zone. - .get_mode: get the current mode (user/kernel) of the thermal zone. - "kernel" means thermal management is done in kernel. - "user" will prevent kernel thermal driver actions upon trip points - so that user applications can take charge of thermal management. - .set_mode: set the mode (user/kernel) of the thermal zone. - .get_trip_type: get the type of certain trip point. - .get_trip_temp: get the temperature above which the certain trip point - will be fired. +1.1.1 struct thermal_zone_device *thermal_zone_device_register(char *name, + int trips, void *devdata, struct thermal_zone_device_ops *ops) + + This interface function adds a new thermal zone device (sensor) to + /sys/class/thermal folder as thermal_zone[0-*]. It tries to bind all the + thermal cooling devices registered at the same time. + + name: the thermal zone name. + trips: the total number of trip points this thermal zone supports. + devdata: device private data + ops: thermal zone device call-backs. + .bind: bind the thermal zone device with a thermal cooling device. + .unbind: unbind the thermal zone device with a thermal cooling device. + .get_temp: get the current temperature of the thermal zone. + .get_mode: get the current mode (user/kernel) of the thermal zone. + - "kernel" means thermal management is done in kernel. + - "user" will prevent kernel thermal driver actions upon trip points + so that user applications can take charge of thermal management. + .set_mode: set the mode (user/kernel) of the thermal zone. + .get_trip_type: get the type of certain trip point. + .get_trip_temp: get the temperature above which the certain trip point + will be fired. 1.1.2 void thermal_zone_device_unregister(struct thermal_zone_device *tz) - This interface function removes the thermal zone device. - It deletes the corresponding entry form /sys/class/thermal folder and unbind all - the thermal cooling devices it uses. + This interface function removes the thermal zone device. + It deletes the corresponding entry form /sys/class/thermal folder and + unbind all the thermal cooling devices it uses. 1.2 thermal cooling device interface 1.2.1 struct thermal_cooling_device *thermal_cooling_device_register(char *name, - void *devdata, struct thermal_cooling_device_ops *) - - This interface function adds a new thermal cooling device (fan/processor/...) to - /sys/class/thermal/ folder as cooling_device[0-*]. - It tries to bind itself to all the thermal zone devices register at the same time. - name: the cooling device name. - devdata: device private data. - ops: thermal cooling devices call-backs. - .get_max_state: get the Maximum throttle state of the cooling device. - .get_cur_state: get the Current throttle state of the cooling device. - .set_cur_state: set the Current throttle state of the cooling device. + void *devdata, struct thermal_cooling_device_ops *) + + This interface function adds a new thermal cooling device (fan/processor/...) + to /sys/class/thermal/ folder as cooling_device[0-*]. It tries to bind itself + to all the thermal zone devices register at the same time. + name: the cooling device name. + devdata: device private data. + ops: thermal cooling devices call-backs. + .get_max_state: get the Maximum throttle state of the cooling device. + .get_cur_state: get the Current throttle state of the cooling device. + .set_cur_state: set the Current throttle state of the cooling device. 1.2.2 void thermal_cooling_device_unregister(struct thermal_cooling_device *cdev) - This interface function remove the thermal cooling device. - It deletes the corresponding entry form /sys/class/thermal folder and unbind - itself from all the thermal zone devices using it. + This interface function remove the thermal cooling device. + It deletes the corresponding entry form /sys/class/thermal folder and + unbind itself from all the thermal zone devices using it. 1.3 interface for binding a thermal zone device with a thermal cooling device 1.3.1 int thermal_zone_bind_cooling_device(struct thermal_zone_device *tz, - int trip, struct thermal_cooling_device *cdev); + int trip, struct thermal_cooling_device *cdev); - This interface function bind a thermal cooling device to the certain trip point - of a thermal zone device. - This function is usually called in the thermal zone device .bind callback. - tz: the thermal zone device - cdev: thermal cooling device - trip: indicates which trip point the cooling devices is associated with - in this thermal zone. + This interface function bind a thermal cooling device to the certain trip + point of a thermal zone device. + This function is usually called in the thermal zone device .bind callback. + tz: the thermal zone device + cdev: thermal cooling device + trip: indicates which trip point the cooling devices is associated with + in this thermal zone. 1.3.2 int thermal_zone_unbind_cooling_device(struct thermal_zone_device *tz, - int trip, struct thermal_cooling_device *cdev); + int trip, struct thermal_cooling_device *cdev); - This interface function unbind a thermal cooling device from the certain trip point - of a thermal zone device. - This function is usually called in the thermal zone device .unbind callback. - tz: the thermal zone device - cdev: thermal cooling device - trip: indicates which trip point the cooling devices is associated with - in this thermal zone. + This interface function unbind a thermal cooling device from the certain + trip point of a thermal zone device. This function is usually called in + the thermal zone device .unbind callback. + tz: the thermal zone device + cdev: thermal cooling device + trip: indicates which trip point the cooling devices is associated with + in this thermal zone. 2. sysfs attributes structure @@ -114,153 +114,167 @@ if hwmon is compiled in or built as a module. Thermal zone device sys I/F, created once it's registered: /sys/class/thermal/thermal_zone[0-*]: - |-----type: Type of the thermal zone - |-----temp: Current temperature - |-----mode: Working mode of the thermal zone - |-----trip_point_[0-*]_temp: Trip point temperature - |-----trip_point_[0-*]_type: Trip point type + |---type: Type of the thermal zone + |---temp: Current temperature + |---mode: Working mode of the thermal zone + |---trip_point_[0-*]_temp: Trip point temperature + |---trip_point_[0-*]_type: Trip point type Thermal cooling device sys I/F, created once it's registered: /sys/class/thermal/cooling_device[0-*]: - |-----type : Type of the cooling device(processor/fan/...) - |-----max_state: Maximum cooling state of the cooling device - |-----cur_state: Current cooling state of the cooling device + |---type: Type of the cooling device(processor/fan/...) + |---max_state: Maximum cooling state of the cooling device + |---cur_state: Current cooling state of the cooling device -These two dynamic attributes are created/removed in pairs. -They represent the relationship between a thermal zone and its associated cooling device. -They are created/removed for each -thermal_zone_bind_cooling_device/thermal_zone_unbind_cooling_device successful execution. +Then next two dynamic attributes are created/removed in pairs. They represent +the relationship between a thermal zone and its associated cooling device. +They are created/removed for each successful execution of +thermal_zone_bind_cooling_device/thermal_zone_unbind_cooling_device. -/sys/class/thermal/thermal_zone[0-*] - |-----cdev[0-*]: The [0-*]th cooling device in the current thermal zone - |-----cdev[0-*]_trip_point: Trip point that cdev[0-*] is associated with +/sys/class/thermal/thermal_zone[0-*]: + |---cdev[0-*]: [0-*]th cooling device in current thermal zone + |---cdev[0-*]_trip_point: Trip point that cdev[0-*] is associated with Besides the thermal zone device sysfs I/F and cooling device sysfs I/F, -the generic thermal driver also creates a hwmon sysfs I/F for each _type_ of -thermal zone device. E.g. the generic thermal driver registers one hwmon class device -and build the associated hwmon sysfs I/F for all the registered ACPI thermal zones. +the generic thermal driver also creates a hwmon sysfs I/F for each _type_ +of thermal zone device. E.g. the generic thermal driver registers one hwmon +class device and build the associated hwmon sysfs I/F for all the registered +ACPI thermal zones. + /sys/class/hwmon/hwmon[0-*]: - |-----name: The type of the thermal zone devices. - |-----temp[1-*]_input: The current temperature of thermal zone [1-*]. - |-----temp[1-*]_critical: The critical trip point of thermal zone [1-*]. + |---name: The type of the thermal zone devices + |---temp[1-*]_input: The current temperature of thermal zone [1-*] + |---temp[1-*]_critical: The critical trip point of thermal zone [1-*] + Please read Documentation/hwmon/sysfs-interface for additional information. *************************** * Thermal zone attributes * *************************** -type Strings which represent the thermal zone type. - This is given by thermal zone driver as part of registration. - Eg: "acpitz" indicates it's an ACPI thermal device. - In order to keep it consistent with hwmon sys attribute, - this should be a short, lowercase string, - not containing spaces nor dashes. - RO - Required - -temp Current temperature as reported by thermal zone (sensor) - Unit: millidegree Celsius - RO - Required - -mode One of the predefined values in [kernel, user] - This file gives information about the algorithm - that is currently managing the thermal zone. - It can be either default kernel based algorithm - or user space application. - RW - Optional - kernel = Thermal management in kernel thermal zone driver. - user = Preventing kernel thermal zone driver actions upon - trip points so that user application can take full - charge of the thermal management. - -trip_point_[0-*]_temp The temperature above which trip point will be fired - Unit: millidegree Celsius - RO - Optional - -trip_point_[0-*]_type Strings which indicate the type of the trip point - E.g. it can be one of critical, hot, passive, - active[0-*] for ACPI thermal zone. - RO - Optional - -cdev[0-*] Sysfs link to the thermal cooling device node where the sys I/F - for cooling device throttling control represents. - RO - Optional - -cdev[0-*]_trip_point The trip point with which cdev[0-*] is associated in this thermal zone - -1 means the cooling device is not associated with any trip point. - RO - Optional - -****************************** -* Cooling device attributes * -****************************** - -type String which represents the type of device - eg: For generic ACPI: this should be "Fan", - "Processor" or "LCD" - eg. For memory controller device on intel_menlow platform: - this should be "Memory controller" - RO - Required - -max_state The maximum permissible cooling state of this cooling device. - RO - Required - -cur_state The current cooling state of this cooling device. - the value can any integer numbers between 0 and max_state, - cur_state == 0 means no cooling - cur_state == max_state means the maximum cooling. - RW - Required +type + Strings which represent the thermal zone type. + This is given by thermal zone driver as part of registration. + E.g: "acpitz" indicates it's an ACPI thermal device. + In order to keep it consistent with hwmon sys attribute; this should + be a short, lowercase string, not containing spaces nor dashes. + RO, Required + +temp + Current temperature as reported by thermal zone (sensor). + Unit: millidegree Celsius + RO, Required + +mode + One of the predefined values in [kernel, user]. + This file gives information about the algorithm that is currently + managing the thermal zone. It can be either default kernel based + algorithm or user space application. + kernel = Thermal management in kernel thermal zone driver. + user = Preventing kernel thermal zone driver actions upon + trip points so that user application can take full + charge of the thermal management. + RW, Optional + +trip_point_[0-*]_temp + The temperature above which trip point will be fired. + Unit: millidegree Celsius + RO, Optional + +trip_point_[0-*]_type + Strings which indicate the type of the trip point. + E.g. it can be one of critical, hot, passive, active[0-*] for ACPI + thermal zone. + RO, Optional + +cdev[0-*] + Sysfs link to the thermal cooling device node where the sys I/F + for cooling device throttling control represents. + RO, Optional + +cdev[0-*]_trip_point + The trip point with which cdev[0-*] is associated in this thermal + zone; -1 means the cooling device is not associated with any trip + point. + RO, Optional + +passive + Attribute is only present for zones in which the passive cooling + policy is not supported by native thermal driver. Default is zero + and can be set to a temperature (in millidegrees) to enable a + passive trip point for the zone. Activation is done by polling with + an interval of 1 second. + Unit: millidegrees Celsius + Valid values: 0 (disabled) or greater than 1000 + RW, Optional + +***************************** +* Cooling device attributes * +***************************** + +type + String which represents the type of device, e.g: + - for generic ACPI: should be "Fan", "Processor" or "LCD" + - for memory controller device on intel_menlow platform: + should be "Memory controller". + RO, Required + +max_state + The maximum permissible cooling state of this cooling device. + RO, Required + +cur_state + The current cooling state of this cooling device. + The value can any integer numbers between 0 and max_state: + - cur_state == 0 means no cooling + - cur_state == max_state means the maximum cooling. + RW, Required 3. A simple implementation -ACPI thermal zone may support multiple trip points like critical/hot/passive/active. -If an ACPI thermal zone supports critical, passive, active[0] and active[1] at the same time, -it may register itself as a thermal_zone_device (thermal_zone1) with 4 trip points in all. -It has one processor and one fan, which are both registered as thermal_cooling_device. -If the processor is listed in _PSL method, and the fan is listed in _AL0 method, -the sys I/F structure will be built like this: +ACPI thermal zone may support multiple trip points like critical, hot, +passive, active. If an ACPI thermal zone supports critical, passive, +active[0] and active[1] at the same time, it may register itself as a +thermal_zone_device (thermal_zone1) with 4 trip points in all. +It has one processor and one fan, which are both registered as +thermal_cooling_device. + +If the processor is listed in _PSL method, and the fan is listed in _AL0 +method, the sys I/F structure will be built like this: /sys/class/thermal: |thermal_zone1: - |-----type: acpitz - |-----temp: 37000 - |-----mode: kernel - |-----trip_point_0_temp: 100000 - |-----trip_point_0_type: critical - |-----trip_point_1_temp: 80000 - |-----trip_point_1_type: passive - |-----trip_point_2_temp: 70000 - |-----trip_point_2_type: active0 - |-----trip_point_3_temp: 60000 - |-----trip_point_3_type: active1 - |-----cdev0: --->/sys/class/thermal/cooling_device0 - |-----cdev0_trip_point: 1 /* cdev0 can be used for passive */ - |-----cdev1: --->/sys/class/thermal/cooling_device3 - |-----cdev1_trip_point: 2 /* cdev1 can be used for active[0]*/ + |---type: acpitz + |---temp: 37000 + |---mode: kernel + |---trip_point_0_temp: 100000 + |---trip_point_0_type: critical + |---trip_point_1_temp: 80000 + |---trip_point_1_type: passive + |---trip_point_2_temp: 70000 + |---trip_point_2_type: active0 + |---trip_point_3_temp: 60000 + |---trip_point_3_type: active1 + |---cdev0: --->/sys/class/thermal/cooling_device0 + |---cdev0_trip_point: 1 /* cdev0 can be used for passive */ + |---cdev1: --->/sys/class/thermal/cooling_device3 + |---cdev1_trip_point: 2 /* cdev1 can be used for active[0]*/ |cooling_device0: - |-----type: Processor - |-----max_state: 8 - |-----cur_state: 0 + |---type: Processor + |---max_state: 8 + |---cur_state: 0 |cooling_device3: - |-----type: Fan - |-----max_state: 2 - |-----cur_state: 0 + |---type: Fan + |---max_state: 2 + |---cur_state: 0 /sys/class/hwmon: |hwmon0: - |-----name: acpitz - |-----temp1_input: 37000 - |-----temp1_crit: 100000 + |---name: acpitz + |---temp1_input: 37000 + |---temp1_crit: 100000 diff --git a/Documentation/timers/hpet.txt b/Documentation/timers/hpet.txt index 04763a325520..16d25e6b5a00 100644 --- a/Documentation/timers/hpet.txt +++ b/Documentation/timers/hpet.txt @@ -3,7 +3,7 @@ The High Precision Event Timer (HPET) hardware follows a specification by Intel and Microsoft which can be found at - http://www.intel.com/technology/architecture/hpetspec.htm + http://www.intel.com/hardwaredesign/hpetspec_1.pdf Each HPET has one fixed-rate counter (at 10+ MHz, hence "High Precision") and up to 32 comparators. Normally three or more comparators are provided, diff --git a/Documentation/trace/events-kmem.txt b/Documentation/trace/events-kmem.txt new file mode 100644 index 000000000000..aa82ee4a5a87 --- /dev/null +++ b/Documentation/trace/events-kmem.txt @@ -0,0 +1,107 @@ + Subsystem Trace Points: kmem + +The kmem tracing system captures events related to object and page allocation +within the kernel. Broadly speaking there are five major subheadings. + + o Slab allocation of small objects of unknown type (kmalloc) + o Slab allocation of small objects of known type + o Page allocation + o Per-CPU Allocator Activity + o External Fragmentation + +This document describes what each of the tracepoints is and why they +might be useful. + +1. Slab allocation of small objects of unknown type +=================================================== +kmalloc call_site=%lx ptr=%p bytes_req=%zu bytes_alloc=%zu gfp_flags=%s +kmalloc_node call_site=%lx ptr=%p bytes_req=%zu bytes_alloc=%zu gfp_flags=%s node=%d +kfree call_site=%lx ptr=%p + +Heavy activity for these events may indicate that a specific cache is +justified, particularly if kmalloc slab pages are getting significantly +internal fragmented as a result of the allocation pattern. By correlating +kmalloc with kfree, it may be possible to identify memory leaks and where +the allocation sites were. + + +2. Slab allocation of small objects of known type +================================================= +kmem_cache_alloc call_site=%lx ptr=%p bytes_req=%zu bytes_alloc=%zu gfp_flags=%s +kmem_cache_alloc_node call_site=%lx ptr=%p bytes_req=%zu bytes_alloc=%zu gfp_flags=%s node=%d +kmem_cache_free call_site=%lx ptr=%p + +These events are similar in usage to the kmalloc-related events except that +it is likely easier to pin the event down to a specific cache. At the time +of writing, no information is available on what slab is being allocated from, +but the call_site can usually be used to extrapolate that information. + +3. Page allocation +================== +mm_page_alloc page=%p pfn=%lu order=%d migratetype=%d gfp_flags=%s +mm_page_alloc_zone_locked page=%p pfn=%lu order=%u migratetype=%d cpu=%d percpu_refill=%d +mm_page_free_direct page=%p pfn=%lu order=%d +mm_pagevec_free page=%p pfn=%lu order=%d cold=%d + +These four events deal with page allocation and freeing. mm_page_alloc is +a simple indicator of page allocator activity. Pages may be allocated from +the per-CPU allocator (high performance) or the buddy allocator. + +If pages are allocated directly from the buddy allocator, the +mm_page_alloc_zone_locked event is triggered. This event is important as high +amounts of activity imply high activity on the zone->lock. Taking this lock +impairs performance by disabling interrupts, dirtying cache lines between +CPUs and serialising many CPUs. + +When a page is freed directly by the caller, the mm_page_free_direct event +is triggered. Significant amounts of activity here could indicate that the +callers should be batching their activities. + +When pages are freed using a pagevec, the mm_pagevec_free is +triggered. Broadly speaking, pages are taken off the LRU lock in bulk and +freed in batch with a pagevec. Significant amounts of activity here could +indicate that the system is under memory pressure and can also indicate +contention on the zone->lru_lock. + +4. Per-CPU Allocator Activity +============================= +mm_page_alloc_zone_locked page=%p pfn=%lu order=%u migratetype=%d cpu=%d percpu_refill=%d +mm_page_pcpu_drain page=%p pfn=%lu order=%d cpu=%d migratetype=%d + +In front of the page allocator is a per-cpu page allocator. It exists only +for order-0 pages, reduces contention on the zone->lock and reduces the +amount of writing on struct page. + +When a per-CPU list is empty or pages of the wrong type are allocated, +the zone->lock will be taken once and the per-CPU list refilled. The event +triggered is mm_page_alloc_zone_locked for each page allocated with the +event indicating whether it is for a percpu_refill or not. + +When the per-CPU list is too full, a number of pages are freed, each one +which triggers a mm_page_pcpu_drain event. + +The individual nature of the events is so that pages can be tracked +between allocation and freeing. A number of drain or refill pages that occur +consecutively imply the zone->lock being taken once. Large amounts of per-CPU +refills and drains could imply an imbalance between CPUs where too much work +is being concentrated in one place. It could also indicate that the per-CPU +lists should be a larger size. Finally, large amounts of refills on one CPU +and drains on another could be a factor in causing large amounts of cache +line bounces due to writes between CPUs and worth investigating if pages +can be allocated and freed on the same CPU through some algorithm change. + +5. External Fragmentation +========================= +mm_page_alloc_extfrag page=%p pfn=%lu alloc_order=%d fallback_order=%d pageblock_order=%d alloc_migratetype=%d fallback_migratetype=%d fragmenting=%d change_ownership=%d + +External fragmentation affects whether a high-order allocation will be +successful or not. For some types of hardware, this is important although +it is avoided where possible. If the system is using huge pages and needs +to be able to resize the pool over the lifetime of the system, this value +is important. + +Large numbers of this event implies that memory is fragmenting and +high-order allocations will start failing at some time in the future. One +means of reducing the occurrence of this event is to increase the size of +min_free_kbytes in increments of 3*pageblock_size*nr_online_nodes where +pageblock_size is usually the size of the default hugepage size. diff --git a/Documentation/trace/events.txt b/Documentation/trace/events.txt index 6e5f35ebb9c1..02ac6ed38b2d 100644 --- a/Documentation/trace/events.txt +++ b/Documentation/trace/events.txt @@ -22,12 +22,12 @@ tracing information should be printed. --------------------------------- The events which are available for tracing can be found in the file -/debug/tracing/available_events. +/sys/kernel/debug/tracing/available_events. To enable a particular event, such as 'sched_wakeup', simply echo it -to /debug/tracing/set_event. For example: +to /sys/kernel/debug/tracing/set_event. For example: - # echo sched_wakeup >> /debug/tracing/set_event + # echo sched_wakeup >> /sys/kernel/debug/tracing/set_event [ Note: '>>' is necessary, otherwise it will firstly disable all the events. ] @@ -35,15 +35,15 @@ to /debug/tracing/set_event. For example: To disable an event, echo the event name to the set_event file prefixed with an exclamation point: - # echo '!sched_wakeup' >> /debug/tracing/set_event + # echo '!sched_wakeup' >> /sys/kernel/debug/tracing/set_event To disable all events, echo an empty line to the set_event file: - # echo > /debug/tracing/set_event + # echo > /sys/kernel/debug/tracing/set_event To enable all events, echo '*:*' or '*:' to the set_event file: - # echo *:* > /debug/tracing/set_event + # echo *:* > /sys/kernel/debug/tracing/set_event The events are organized into subsystems, such as ext4, irq, sched, etc., and a full event name looks like this: <subsystem>:<event>. The @@ -52,29 +52,29 @@ file. All of the events in a subsystem can be specified via the syntax "<subsystem>:*"; for example, to enable all irq events, you can use the command: - # echo 'irq:*' > /debug/tracing/set_event + # echo 'irq:*' > /sys/kernel/debug/tracing/set_event 2.2 Via the 'enable' toggle --------------------------- -The events available are also listed in /debug/tracing/events/ hierarchy +The events available are also listed in /sys/kernel/debug/tracing/events/ hierarchy of directories. To enable event 'sched_wakeup': - # echo 1 > /debug/tracing/events/sched/sched_wakeup/enable + # echo 1 > /sys/kernel/debug/tracing/events/sched/sched_wakeup/enable To disable it: - # echo 0 > /debug/tracing/events/sched/sched_wakeup/enable + # echo 0 > /sys/kernel/debug/tracing/events/sched/sched_wakeup/enable To enable all events in sched subsystem: - # echo 1 > /debug/tracing/events/sched/enable + # echo 1 > /sys/kernel/debug/tracing/events/sched/enable -To eanble all events: +To enable all events: - # echo 1 > /debug/tracing/events/enable + # echo 1 > /sys/kernel/debug/tracing/events/enable When reading one of these enable files, there are four results: diff --git a/Documentation/trace/ftrace-design.txt b/Documentation/trace/ftrace-design.txt new file mode 100644 index 000000000000..6a5a579126b0 --- /dev/null +++ b/Documentation/trace/ftrace-design.txt @@ -0,0 +1,262 @@ + function tracer guts + ==================== + By Mike Frysinger + +Introduction +------------ + +Here we will cover the architecture pieces that the common function tracing +code relies on for proper functioning. Things are broken down into increasing +complexity so that you can start simple and at least get basic functionality. + +Note that this focuses on architecture implementation details only. If you +want more explanation of a feature in terms of common code, review the common +ftrace.txt file. + + +Prerequisites +------------- + +Ftrace relies on these features being implemented: + STACKTRACE_SUPPORT - implement save_stack_trace() + TRACE_IRQFLAGS_SUPPORT - implement include/asm/irqflags.h + + +HAVE_FUNCTION_TRACER +-------------------- + +You will need to implement the mcount and the ftrace_stub functions. + +The exact mcount symbol name will depend on your toolchain. Some call it +"mcount", "_mcount", or even "__mcount". You can probably figure it out by +running something like: + $ echo 'main(){}' | gcc -x c -S -o - - -pg | grep mcount + call mcount +We'll make the assumption below that the symbol is "mcount" just to keep things +nice and simple in the examples. + +Keep in mind that the ABI that is in effect inside of the mcount function is +*highly* architecture/toolchain specific. We cannot help you in this regard, +sorry. Dig up some old documentation and/or find someone more familiar than +you to bang ideas off of. Typically, register usage (argument/scratch/etc...) +is a major issue at this point, especially in relation to the location of the +mcount call (before/after function prologue). You might also want to look at +how glibc has implemented the mcount function for your architecture. It might +be (semi-)relevant. + +The mcount function should check the function pointer ftrace_trace_function +to see if it is set to ftrace_stub. If it is, there is nothing for you to do, +so return immediately. If it isn't, then call that function in the same way +the mcount function normally calls __mcount_internal -- the first argument is +the "frompc" while the second argument is the "selfpc" (adjusted to remove the +size of the mcount call that is embedded in the function). + +For example, if the function foo() calls bar(), when the bar() function calls +mcount(), the arguments mcount() will pass to the tracer are: + "frompc" - the address bar() will use to return to foo() + "selfpc" - the address bar() (with mcount() size adjustment) + +Also keep in mind that this mcount function will be called *a lot*, so +optimizing for the default case of no tracer will help the smooth running of +your system when tracing is disabled. So the start of the mcount function is +typically the bare minimum with checking things before returning. That also +means the code flow should usually be kept linear (i.e. no branching in the nop +case). This is of course an optimization and not a hard requirement. + +Here is some pseudo code that should help (these functions should actually be +implemented in assembly): + +void ftrace_stub(void) +{ + return; +} + +void mcount(void) +{ + /* save any bare state needed in order to do initial checking */ + + extern void (*ftrace_trace_function)(unsigned long, unsigned long); + if (ftrace_trace_function != ftrace_stub) + goto do_trace; + + /* restore any bare state */ + + return; + +do_trace: + + /* save all state needed by the ABI (see paragraph above) */ + + unsigned long frompc = ...; + unsigned long selfpc = <return address> - MCOUNT_INSN_SIZE; + ftrace_trace_function(frompc, selfpc); + + /* restore all state needed by the ABI */ +} + +Don't forget to export mcount for modules ! +extern void mcount(void); +EXPORT_SYMBOL(mcount); + + +HAVE_FUNCTION_TRACE_MCOUNT_TEST +------------------------------- + +This is an optional optimization for the normal case when tracing is turned off +in the system. If you do not enable this Kconfig option, the common ftrace +code will take care of doing the checking for you. + +To support this feature, you only need to check the function_trace_stop +variable in the mcount function. If it is non-zero, there is no tracing to be +done at all, so you can return. + +This additional pseudo code would simply be: +void mcount(void) +{ + /* save any bare state needed in order to do initial checking */ + ++ if (function_trace_stop) ++ return; + + extern void (*ftrace_trace_function)(unsigned long, unsigned long); + if (ftrace_trace_function != ftrace_stub) +... + + +HAVE_FUNCTION_GRAPH_TRACER +-------------------------- + +Deep breath ... time to do some real work. Here you will need to update the +mcount function to check ftrace graph function pointers, as well as implement +some functions to save (hijack) and restore the return address. + +The mcount function should check the function pointers ftrace_graph_return +(compare to ftrace_stub) and ftrace_graph_entry (compare to +ftrace_graph_entry_stub). If either of those is not set to the relevant stub +function, call the arch-specific function ftrace_graph_caller which in turn +calls the arch-specific function prepare_ftrace_return. Neither of these +function names is strictly required, but you should use them anyway to stay +consistent across the architecture ports -- easier to compare & contrast +things. + +The arguments to prepare_ftrace_return are slightly different than what are +passed to ftrace_trace_function. The second argument "selfpc" is the same, +but the first argument should be a pointer to the "frompc". Typically this is +located on the stack. This allows the function to hijack the return address +temporarily to have it point to the arch-specific function return_to_handler. +That function will simply call the common ftrace_return_to_handler function and +that will return the original return address with which you can return to the +original call site. + +Here is the updated mcount pseudo code: +void mcount(void) +{ +... + if (ftrace_trace_function != ftrace_stub) + goto do_trace; + ++#ifdef CONFIG_FUNCTION_GRAPH_TRACER ++ extern void (*ftrace_graph_return)(...); ++ extern void (*ftrace_graph_entry)(...); ++ if (ftrace_graph_return != ftrace_stub || ++ ftrace_graph_entry != ftrace_graph_entry_stub) ++ ftrace_graph_caller(); ++#endif + + /* restore any bare state */ +... + +Here is the pseudo code for the new ftrace_graph_caller assembly function: +#ifdef CONFIG_FUNCTION_GRAPH_TRACER +void ftrace_graph_caller(void) +{ + /* save all state needed by the ABI */ + + unsigned long *frompc = &...; + unsigned long selfpc = <return address> - MCOUNT_INSN_SIZE; + /* passing frame pointer up is optional -- see below */ + prepare_ftrace_return(frompc, selfpc, frame_pointer); + + /* restore all state needed by the ABI */ +} +#endif + +For information on how to implement prepare_ftrace_return(), simply look at the +x86 version (the frame pointer passing is optional; see the next section for +more information). The only architecture-specific piece in it is the setup of +the fault recovery table (the asm(...) code). The rest should be the same +across architectures. + +Here is the pseudo code for the new return_to_handler assembly function. Note +that the ABI that applies here is different from what applies to the mcount +code. Since you are returning from a function (after the epilogue), you might +be able to skimp on things saved/restored (usually just registers used to pass +return values). + +#ifdef CONFIG_FUNCTION_GRAPH_TRACER +void return_to_handler(void) +{ + /* save all state needed by the ABI (see paragraph above) */ + + void (*original_return_point)(void) = ftrace_return_to_handler(); + + /* restore all state needed by the ABI */ + + /* this is usually either a return or a jump */ + original_return_point(); +} +#endif + + +HAVE_FUNCTION_GRAPH_FP_TEST +--------------------------- + +An arch may pass in a unique value (frame pointer) to both the entering and +exiting of a function. On exit, the value is compared and if it does not +match, then it will panic the kernel. This is largely a sanity check for bad +code generation with gcc. If gcc for your port sanely updates the frame +pointer under different opitmization levels, then ignore this option. + +However, adding support for it isn't terribly difficult. In your assembly code +that calls prepare_ftrace_return(), pass the frame pointer as the 3rd argument. +Then in the C version of that function, do what the x86 port does and pass it +along to ftrace_push_return_trace() instead of a stub value of 0. + +Similarly, when you call ftrace_return_to_handler(), pass it the frame pointer. + + +HAVE_FTRACE_NMI_ENTER +--------------------- + +If you can't trace NMI functions, then skip this option. + +<details to be filled> + + +HAVE_SYSCALL_TRACEPOINTS +--------------------- + +You need very few things to get the syscalls tracing in an arch. + +- Have a NR_syscalls variable in <asm/unistd.h> that provides the number + of syscalls supported by the arch. +- Implement arch_syscall_addr() that resolves a syscall address from a + syscall number. +- Support the TIF_SYSCALL_TRACEPOINT thread flags +- Put the trace_sys_enter() and trace_sys_exit() tracepoints calls from ptrace + in the ptrace syscalls tracing path. +- Tag this arch as HAVE_SYSCALL_TRACEPOINTS. + + +HAVE_FTRACE_MCOUNT_RECORD +------------------------- + +See scripts/recordmcount.pl for more info. + +<details to be filled> + + +HAVE_DYNAMIC_FTRACE +--------------------- + +<details to be filled> diff --git a/Documentation/trace/ftrace.txt b/Documentation/trace/ftrace.txt index a4fcad7b423c..bab3040da548 100644 --- a/Documentation/trace/ftrace.txt +++ b/Documentation/trace/ftrace.txt @@ -26,6 +26,12 @@ disabled, and more (ftrace allows for tracer plugins, which means that the list of tracers can always grow). +Implementation Details +---------------------- + +See ftrace-design.txt for details for arch porters and such. + + The File System --------------- @@ -111,14 +117,9 @@ of ftrace. Here is a list of some of the key files: For example, the time interrupts are disabled. This time is saved in this file. The max trace will also be stored, and displayed by "trace". - A new max trace will only be recorded, if the + A new max trace will only be recorded if the latency is greater than the value in this - file (in microseconds). Note that the max latency - recorded by the wakeup and the wakeup_rt tracer - do not necessarily reflect the worst-case latency - of the system, but may be erroneously high in - case two or more processes share the maximum - priority of the system. + file. (in microseconds) buffer_size_kb: @@ -132,7 +133,7 @@ of ftrace. Here is a list of some of the key files: than requested, the rest of the page will be used, making the actual allocation bigger than requested. ( Note, the size may not be a multiple of the page size - due to buffer managment overhead. ) + due to buffer management overhead. ) This can only be updated when the current_tracer is set to "nop". @@ -1230,6 +1231,7 @@ something like this simple program: #include <sys/stat.h> #include <fcntl.h> #include <unistd.h> +#include <string.h> #define _STR(x) #x #define STR(x) _STR(x) @@ -1264,6 +1266,7 @@ const char *find_debugfs(void) return NULL; } + strcat(debugfs, "/tracing/"); debugfs_found = 1; return debugfs; @@ -1622,7 +1625,7 @@ If I am only interested in sys_nanosleep and hrtimer_interrupt: # echo sys_nanosleep hrtimer_interrupt \ > set_ftrace_filter - # echo ftrace > current_tracer + # echo function > current_tracer # echo 1 > tracing_enabled # usleep 1 # echo 0 > tracing_enabled diff --git a/Documentation/trace/histograms.txt b/Documentation/trace/histograms.txt index 2f179673710a..664505717219 100644 --- a/Documentation/trace/histograms.txt +++ b/Documentation/trace/histograms.txt @@ -24,43 +24,26 @@ histograms of potential sources of latency, the kernel stores the time stamp at the start of a critical section, determines the time elapsed when the end of the section is reached, and increments the frequency counter of that latency value - irrespective of whether any concurrently -running process is affected by this latency or not. +running process is affected by latency or not. - Configuration items (in the Kernel hacking/Tracers submenu) - CONFIG_INTERRUPT_OFF_HIST - CONFIG_PREEMPT_OFF_HIST + CONFIG_INTERRUPT_OFF_LATENCY + CONFIG_PREEMPT_OFF_LATENCY * Effective latencies -There are two types of effective latencies, wakeup latencies and missed -timer latencies - -* Wakeup latencies -Wakeup latencies may occur during wakeup of a process. To determine -wakeup latencies, the kernel stores the time stamp when a process is -scheduled to be woken up, and determines the duration of the wakeup time -shortly before control is passed over to this process. Note that the -apparent latency in user space may be considerably longer, since -i) interrupts may be disabled preventing the timer from waking up a process -in time + +Effective latencies are actually occuring during wakeup of a process. To +determine effective latencies, the kernel stores the time stamp when a +process is scheduled to be woken up, and determines the duration of the +wakeup time shortly before control is passed over to this process. Note +that the apparent latency in user space may be considerably longer, +since +i) interrupts may be disabled preventing the scheduler from initiating +the wakeup mechanism, and ii) the process may be interrupted after control is passed over to it but before user space execution takes place. -If a particular wakeup latency is highest so far, details of the task -that is suffering from this latency are stored as well (see below). -- Configuration item (in the Kernel hacking/Tracers submenu) - CONFIG_WAKEUP_LATENCY_HIST - -* Missed timer latencies - -Missed timer latencies occur when a timer interrupt is serviced later -than it should. This is mainly due to disabled interrupts. To determine -the missed timer latency, the expected and the real execution time of a -timer are compared. If the former precedes the latter, the difference is -entered into the missed timer offsets histogram. If the timer is -responsible to wakeup a sleeping process and the latency is highest so -far among previous wakeup timers, details of the related task are stored -as well (see below). - Configuration item (in the Kernel hacking/Tracers submenu) - CONFIG_MISSED_TIMER_OFFSETS_HIST + CONFIG_WAKEUP_LATENCY * Usage @@ -76,36 +59,30 @@ from shell command line level, or add nodev /sys sysfs defaults 0 0 nodev /sys/kernel/debug debugfs defaults 0 0 -to the file /etc/fstab in order to implicitly mount the debug file -system at every reboot. All latency histogram related files are +to the file /etc/fstab. All latency histogram related files are available in the directory /sys/kernel/debug/tracing/latency_hist. A particular histogram type is enabled by writing non-zero to the related variable in the /sys/kernel/debug/tracing/latency_hist/enable directory. -Select "preemptirqsoff" for histograms of potential sources of -latencies, "wakeup" for histograms of wakeup latencies and -"missed_timer_offsets" for histograms of missed timer offsets, -respectively. +Select "preemptirqsoff" for the histograms of potential sources of +latencies and "wakeup" for histograms of effective latencies. The +histogram data - one per CPU - are available in the files -The histogram data - one per CPU - are available in the files /sys/kernel/debug/tracing/latency_hist/preemptoff/CPUx /sys/kernel/debug/tracing/latency_hist/irqsoff/CPUx /sys/kernel/debug/tracing/latency_hist/preemptirqsoff/CPUx /sys/kernel/debug/tracing/latency_hist/wakeup/CPUx. -/sys/kernel/debug/tracing/latency_hist/wakeup/sharedprio/CPUx. -/sys/kernel/debug/tracing/latency_hist/missed_timer_offsets/CPUx. The histograms are reset by writing non-zero to the file "reset" in a particular latency directory. To reset all latency data, use -#!/bin/bash +#!/bin/sh -TRACINGDIR=/sys/kernel/debug/tracing -HISTDIR=$TRACINGDIR/latency_hist +HISTDIR=/sys/kernel/debug/tracing/latency_hist if test -d $HISTDIR then cd $HISTDIR - for i in `find . | grep /reset$` + for i in */reset do echo 1 >$i done @@ -115,19 +92,19 @@ fi * Data format Latency data are stored with a resolution of one microsecond. The -maximum latency is 10,240 microseconds. Every output line contains the -latency in microseconds in the first row and the number of samples in -the second row. To display only lines with a positive latency count, -use, for example, +maximum latency is 10,240 microseconds. The data are only valid, if the +overflow register is empty. Every output line contains the latency in +microseconds in the first row and the number of samples in the second +row. To display only lines with a positive latency count, use, for +example, grep -v " 0$" /sys/kernel/debug/tracing/latency_hist/preemptoff/CPU0 -#Minimum latency: 0 microseconds -#Average latency: 0 microseconds -#Maximum latency: 25 microseconds +#Minimum latency: 0 microseconds. +#Average latency: 0 microseconds. +#Maximum latency: 25 microseconds. #Total samples: 3104770694 -#There are 0 samples lower than 0 microseconds. -#There are 0 samples greater or equal than 10240 microseconds. +#There are 0 samples greater or equal than 10240 microseconds #usecs samples 0 2984486876 1 49843506 @@ -156,23 +133,6 @@ grep -v " 0$" /sys/kernel/debug/tracing/latency_hist/preemptoff/CPU0 25 1 -* Two types of wakeup latency histograms - -Two different algorithms are used to determine the wakeup latency of a -process. One of them only considers processes that exclusively use the -highest priority of the system, the other one records the wakeup latency -of a process even if it shares the highest system latency with other -processes. The former is used to determine the worst-case latency of a -system; if higher than expected, the hardware and or system software -(e.g. the Linux kernel) may need to be debugged and fixed. The latter -reflects the priority design of a given system; if higher than expected, -the system design may need to be re-evaluated - the hardware -manufacturer or the kernel developers must not be blamed for such -latencies. The exclusive-priority wakeup latency histograms are located -in the "wakeup" subdirectory, the shared-priority histograms are located -in the "wakeup/sharedprio" subdirectory. - - * Wakeup latency of a selected process To only collect wakeup latency data of a particular process, write the @@ -183,18 +143,14 @@ PID of the requested process to PIDs are not considered, if this variable is set to 0. -* Details of processes with the highest wakeup or missed timer -latency so far +* Details of the process with the highest wakeup latency so far -Selected data of processes that suffered from the highest wakeup or -missed timer latency that occurred on a particular CPU are available in -the files +Selected data of the process that suffered from the highest wakeup +latency that occurred in a particular CPU are available in the file -/sys/kernel/debug/tracing/latency_hist/wakeup/max_latency-CPUx -/sys/kernel/debug/tracing/latency_hist/wakeup/sharedprio/max_latency-CPUx -/sys/kernel/debug/tracing/latency_hist/missed_timer_offsets/max_latency-CPUx +/sys/kernel/debug/tracing/latency_hist/wakeup/max_latency-CPUx. The format of the data is <PID> <Priority> <Latency> <Command> -These data are also reset when the related histograms are reset. +These data are also reset when the wakeup histogram ist reset. diff --git a/Documentation/trace/kprobetrace.txt b/Documentation/trace/kprobetrace.txt new file mode 100644 index 000000000000..47aabeebbdf6 --- /dev/null +++ b/Documentation/trace/kprobetrace.txt @@ -0,0 +1,149 @@ + Kprobe-based Event Tracing + ========================== + + Documentation is written by Masami Hiramatsu + + +Overview +-------- +These events are similar to tracepoint based events. Instead of Tracepoint, +this is based on kprobes (kprobe and kretprobe). So it can probe wherever +kprobes can probe (this means, all functions body except for __kprobes +functions). Unlike the Tracepoint based event, this can be added and removed +dynamically, on the fly. + +To enable this feature, build your kernel with CONFIG_KPROBE_TRACING=y. + +Similar to the events tracer, this doesn't need to be activated via +current_tracer. Instead of that, add probe points via +/sys/kernel/debug/tracing/kprobe_events, and enable it via +/sys/kernel/debug/tracing/events/kprobes/<EVENT>/enabled. + + +Synopsis of kprobe_events +------------------------- + p[:[GRP/]EVENT] SYMBOL[+offs]|MEMADDR [FETCHARGS] : Set a probe + r[:[GRP/]EVENT] SYMBOL[+0] [FETCHARGS] : Set a return probe + + GRP : Group name. If omitted, use "kprobes" for it. + EVENT : Event name. If omitted, the event name is generated + based on SYMBOL+offs or MEMADDR. + SYMBOL[+offs] : Symbol+offset where the probe is inserted. + MEMADDR : Address where the probe is inserted. + + FETCHARGS : Arguments. Each probe can have up to 128 args. + %REG : Fetch register REG + @ADDR : Fetch memory at ADDR (ADDR should be in kernel) + @SYM[+|-offs] : Fetch memory at SYM +|- offs (SYM should be a data symbol) + $stackN : Fetch Nth entry of stack (N >= 0) + $stack : Fetch stack address. + $argN : Fetch function argument. (N >= 0)(*) + $retval : Fetch return value.(**) + +|-offs(FETCHARG) : Fetch memory at FETCHARG +|- offs address.(***) + NAME=FETCHARG: Set NAME as the argument name of FETCHARG. + + (*) aN may not correct on asmlinkaged functions and at the middle of + function body. + (**) only for return probe. + (***) this is useful for fetching a field of data structures. + + +Per-Probe Event Filtering +------------------------- + Per-probe event filtering feature allows you to set different filter on each +probe and gives you what arguments will be shown in trace buffer. If an event +name is specified right after 'p:' or 'r:' in kprobe_events, it adds an event +under tracing/events/kprobes/<EVENT>, at the directory you can see 'id', +'enabled', 'format' and 'filter'. + +enabled: + You can enable/disable the probe by writing 1 or 0 on it. + +format: + This shows the format of this probe event. + +filter: + You can write filtering rules of this event. + +id: + This shows the id of this probe event. + + +Event Profiling +--------------- + You can check the total number of probe hits and probe miss-hits via +/sys/kernel/debug/tracing/kprobe_profile. + The first column is event name, the second is the number of probe hits, +the third is the number of probe miss-hits. + + +Usage examples +-------------- +To add a probe as a new event, write a new definition to kprobe_events +as below. + + echo p:myprobe do_sys_open dfd=$arg0 filename=$arg1 flags=$arg2 mode=$arg3 > /sys/kernel/debug/tracing/kprobe_events + + This sets a kprobe on the top of do_sys_open() function with recording +1st to 4th arguments as "myprobe" event. As this example shows, users can +choose more familiar names for each arguments. + + echo r:myretprobe do_sys_open $retval >> /sys/kernel/debug/tracing/kprobe_events + + This sets a kretprobe on the return point of do_sys_open() function with +recording return value as "myretprobe" event. + You can see the format of these events via +/sys/kernel/debug/tracing/events/kprobes/<EVENT>/format. + + cat /sys/kernel/debug/tracing/events/kprobes/myprobe/format +name: myprobe +ID: 75 +format: + field:unsigned short common_type; offset:0; size:2; + field:unsigned char common_flags; offset:2; size:1; + field:unsigned char common_preempt_count; offset:3; size:1; + field:int common_pid; offset:4; size:4; + field:int common_tgid; offset:8; size:4; + + field: unsigned long ip; offset:16;tsize:8; + field: int nargs; offset:24;tsize:4; + field: unsigned long dfd; offset:32;tsize:8; + field: unsigned long filename; offset:40;tsize:8; + field: unsigned long flags; offset:48;tsize:8; + field: unsigned long mode; offset:56;tsize:8; + +print fmt: "(%lx) dfd=%lx filename=%lx flags=%lx mode=%lx", REC->ip, REC->dfd, REC->filename, REC->flags, REC->mode + + + You can see that the event has 4 arguments as in the expressions you specified. + + echo > /sys/kernel/debug/tracing/kprobe_events + + This clears all probe points. + + Right after definition, each event is disabled by default. For tracing these +events, you need to enable it. + + echo 1 > /sys/kernel/debug/tracing/events/kprobes/myprobe/enable + echo 1 > /sys/kernel/debug/tracing/events/kprobes/myretprobe/enable + + And you can see the traced information via /sys/kernel/debug/tracing/trace. + + cat /sys/kernel/debug/tracing/trace +# tracer: nop +# +# TASK-PID CPU# TIMESTAMP FUNCTION +# | | | | | + <...>-1447 [001] 1038282.286875: myprobe: (do_sys_open+0x0/0xd6) dfd=3 filename=7fffd1ec4440 flags=8000 mode=0 + <...>-1447 [001] 1038282.286878: myretprobe: (sys_openat+0xc/0xe <- do_sys_open) $retval=fffffffffffffffe + <...>-1447 [001] 1038282.286885: myprobe: (do_sys_open+0x0/0xd6) dfd=ffffff9c filename=40413c flags=8000 mode=1b6 + <...>-1447 [001] 1038282.286915: myretprobe: (sys_open+0x1b/0x1d <- do_sys_open) $retval=3 + <...>-1447 [001] 1038282.286969: myprobe: (do_sys_open+0x0/0xd6) dfd=ffffff9c filename=4041c6 flags=98800 mode=10 + <...>-1447 [001] 1038282.286976: myretprobe: (sys_open+0x1b/0x1d <- do_sys_open) $retval=3 + + + Each line shows when the kernel hits an event, and <- SYMBOL means kernel +returns from SYMBOL(e.g. "sys_open+0x1b/0x1d <- do_sys_open" means kernel +returns from do_sys_open to sys_open+0x1b). + + diff --git a/Documentation/trace/mmiotrace.txt b/Documentation/trace/mmiotrace.txt index 162effbfbdec..664e7386d89e 100644 --- a/Documentation/trace/mmiotrace.txt +++ b/Documentation/trace/mmiotrace.txt @@ -44,7 +44,8 @@ Check for lost events. Usage ----- -Make sure debugfs is mounted to /sys/kernel/debug. If not, (requires root privileges) +Make sure debugfs is mounted to /sys/kernel/debug. +If not (requires root privileges): $ mount -t debugfs debugfs /sys/kernel/debug Check that the driver you are about to trace is not loaded. @@ -91,7 +92,7 @@ $ dmesg > dmesg.txt $ tar zcf pciid-nick-mmiotrace.tar.gz mydump.txt lspci.txt dmesg.txt and then send the .tar.gz file. The trace compresses considerably. Replace "pciid" and "nick" with the PCI ID or model name of your piece of hardware -under investigation and your nick name. +under investigation and your nickname. How Mmiotrace Works @@ -100,7 +101,7 @@ How Mmiotrace Works Access to hardware IO-memory is gained by mapping addresses from PCI bus by calling one of the ioremap_*() functions. Mmiotrace is hooked into the __ioremap() function and gets called whenever a mapping is created. Mapping is -an event that is recorded into the trace log. Note, that ISA range mappings +an event that is recorded into the trace log. Note that ISA range mappings are not caught, since the mapping always exists and is returned directly. MMIO accesses are recorded via page faults. Just before __ioremap() returns, @@ -122,11 +123,11 @@ Trace Log Format ---------------- The raw log is text and easily filtered with e.g. grep and awk. One record is -one line in the log. A record starts with a keyword, followed by keyword -dependant arguments. Arguments are separated by a space, or continue until the +one line in the log. A record starts with a keyword, followed by keyword- +dependent arguments. Arguments are separated by a space, or continue until the end of line. The format for version 20070824 is as follows: -Explanation Keyword Space separated arguments +Explanation Keyword Space-separated arguments --------------------------------------------------------------------------- read event R width, timestamp, map id, physical, value, PC, PID @@ -136,7 +137,7 @@ iounmap event UNMAP timestamp, map id, PC, PID marker MARK timestamp, text version VERSION the string "20070824" info for reader LSPCI one line from lspci -v -PCI address map PCIDEV space separated /proc/bus/pci/devices data +PCI address map PCIDEV space-separated /proc/bus/pci/devices data unk. opcode UNKNOWN timestamp, map id, physical, data, PC, PID Timestamp is in seconds with decimals. Physical is a PCI bus address, virtual diff --git a/Documentation/trace/postprocess/trace-pagealloc-postprocess.pl b/Documentation/trace/postprocess/trace-pagealloc-postprocess.pl new file mode 100644 index 000000000000..7df50e8cf4d9 --- /dev/null +++ b/Documentation/trace/postprocess/trace-pagealloc-postprocess.pl @@ -0,0 +1,418 @@ +#!/usr/bin/perl +# This is a POC (proof of concept or piece of crap, take your pick) for reading the +# text representation of trace output related to page allocation. It makes an attempt +# to extract some high-level information on what is going on. The accuracy of the parser +# may vary considerably +# +# Example usage: trace-pagealloc-postprocess.pl < /sys/kernel/debug/tracing/trace_pipe +# other options +# --prepend-parent Report on the parent proc and PID +# --read-procstat If the trace lacks process info, get it from /proc +# --ignore-pid Aggregate processes of the same name together +# +# Copyright (c) IBM Corporation 2009 +# Author: Mel Gorman <mel@csn.ul.ie> +use strict; +use Getopt::Long; + +# Tracepoint events +use constant MM_PAGE_ALLOC => 1; +use constant MM_PAGE_FREE_DIRECT => 2; +use constant MM_PAGEVEC_FREE => 3; +use constant MM_PAGE_PCPU_DRAIN => 4; +use constant MM_PAGE_ALLOC_ZONE_LOCKED => 5; +use constant MM_PAGE_ALLOC_EXTFRAG => 6; +use constant EVENT_UNKNOWN => 7; + +# Constants used to track state +use constant STATE_PCPU_PAGES_DRAINED => 8; +use constant STATE_PCPU_PAGES_REFILLED => 9; + +# High-level events extrapolated from tracepoints +use constant HIGH_PCPU_DRAINS => 10; +use constant HIGH_PCPU_REFILLS => 11; +use constant HIGH_EXT_FRAGMENT => 12; +use constant HIGH_EXT_FRAGMENT_SEVERE => 13; +use constant HIGH_EXT_FRAGMENT_MODERATE => 14; +use constant HIGH_EXT_FRAGMENT_CHANGED => 15; + +my %perprocesspid; +my %perprocess; +my $opt_ignorepid; +my $opt_read_procstat; +my $opt_prepend_parent; + +# Catch sigint and exit on request +my $sigint_report = 0; +my $sigint_exit = 0; +my $sigint_pending = 0; +my $sigint_received = 0; +sub sigint_handler { + my $current_time = time; + if ($current_time - 2 > $sigint_received) { + print "SIGINT received, report pending. Hit ctrl-c again to exit\n"; + $sigint_report = 1; + } else { + if (!$sigint_exit) { + print "Second SIGINT received quickly, exiting\n"; + } + $sigint_exit++; + } + + if ($sigint_exit > 3) { + print "Many SIGINTs received, exiting now without report\n"; + exit; + } + + $sigint_received = $current_time; + $sigint_pending = 1; +} +$SIG{INT} = "sigint_handler"; + +# Parse command line options +GetOptions( + 'ignore-pid' => \$opt_ignorepid, + 'read-procstat' => \$opt_read_procstat, + 'prepend-parent' => \$opt_prepend_parent, +); + +# Defaults for dynamically discovered regex's +my $regex_fragdetails_default = 'page=([0-9a-f]*) pfn=([0-9]*) alloc_order=([-0-9]*) fallback_order=([-0-9]*) pageblock_order=([-0-9]*) alloc_migratetype=([-0-9]*) fallback_migratetype=([-0-9]*) fragmenting=([-0-9]) change_ownership=([-0-9])'; + +# Dyanically discovered regex +my $regex_fragdetails; + +# Static regex used. Specified like this for readability and for use with /o +# (process_pid) (cpus ) ( time ) (tpoint ) (details) +my $regex_traceevent = '\s*([a-zA-Z0-9-]*)\s*(\[[0-9]*\])\s*([0-9.]*):\s*([a-zA-Z_]*):\s*(.*)'; +my $regex_statname = '[-0-9]*\s\((.*)\).*'; +my $regex_statppid = '[-0-9]*\s\(.*\)\s[A-Za-z]\s([0-9]*).*'; + +sub generate_traceevent_regex { + my $event = shift; + my $default = shift; + my $regex; + + # Read the event format or use the default + if (!open (FORMAT, "/sys/kernel/debug/tracing/events/$event/format")) { + $regex = $default; + } else { + my $line; + while (!eof(FORMAT)) { + $line = <FORMAT>; + if ($line =~ /^print fmt:\s"(.*)",.*/) { + $regex = $1; + $regex =~ s/%p/\([0-9a-f]*\)/g; + $regex =~ s/%d/\([-0-9]*\)/g; + $regex =~ s/%lu/\([0-9]*\)/g; + } + } + } + + # Verify fields are in the right order + my $tuple; + foreach $tuple (split /\s/, $regex) { + my ($key, $value) = split(/=/, $tuple); + my $expected = shift; + if ($key ne $expected) { + print("WARNING: Format not as expected '$key' != '$expected'"); + $regex =~ s/$key=\((.*)\)/$key=$1/; + } + } + + if (defined shift) { + die("Fewer fields than expected in format"); + } + + return $regex; +} +$regex_fragdetails = generate_traceevent_regex("kmem/mm_page_alloc_extfrag", + $regex_fragdetails_default, + "page", "pfn", + "alloc_order", "fallback_order", "pageblock_order", + "alloc_migratetype", "fallback_migratetype", + "fragmenting", "change_ownership"); + +sub read_statline($) { + my $pid = $_[0]; + my $statline; + + if (open(STAT, "/proc/$pid/stat")) { + $statline = <STAT>; + close(STAT); + } + + if ($statline eq '') { + $statline = "-1 (UNKNOWN_PROCESS_NAME) R 0"; + } + + return $statline; +} + +sub guess_process_pid($$) { + my $pid = $_[0]; + my $statline = $_[1]; + + if ($pid == 0) { + return "swapper-0"; + } + + if ($statline !~ /$regex_statname/o) { + die("Failed to math stat line for process name :: $statline"); + } + return "$1-$pid"; +} + +sub parent_info($$) { + my $pid = $_[0]; + my $statline = $_[1]; + my $ppid; + + if ($pid == 0) { + return "NOPARENT-0"; + } + + if ($statline !~ /$regex_statppid/o) { + die("Failed to match stat line process ppid:: $statline"); + } + + # Read the ppid stat line + $ppid = $1; + return guess_process_pid($ppid, read_statline($ppid)); +} + +sub process_events { + my $traceevent; + my $process_pid; + my $cpus; + my $timestamp; + my $tracepoint; + my $details; + my $statline; + + # Read each line of the event log +EVENT_PROCESS: + while ($traceevent = <STDIN>) { + if ($traceevent =~ /$regex_traceevent/o) { + $process_pid = $1; + $tracepoint = $4; + + if ($opt_read_procstat || $opt_prepend_parent) { + $process_pid =~ /(.*)-([0-9]*)$/; + my $process = $1; + my $pid = $2; + + $statline = read_statline($pid); + + if ($opt_read_procstat && $process eq '') { + $process_pid = guess_process_pid($pid, $statline); + } + + if ($opt_prepend_parent) { + $process_pid = parent_info($pid, $statline) . " :: $process_pid"; + } + } + + # Unnecessary in this script. Uncomment if required + # $cpus = $2; + # $timestamp = $3; + } else { + next; + } + + # Perl Switch() sucks majorly + if ($tracepoint eq "mm_page_alloc") { + $perprocesspid{$process_pid}->{MM_PAGE_ALLOC}++; + } elsif ($tracepoint eq "mm_page_free_direct") { + $perprocesspid{$process_pid}->{MM_PAGE_FREE_DIRECT}++; + } elsif ($tracepoint eq "mm_pagevec_free") { + $perprocesspid{$process_pid}->{MM_PAGEVEC_FREE}++; + } elsif ($tracepoint eq "mm_page_pcpu_drain") { + $perprocesspid{$process_pid}->{MM_PAGE_PCPU_DRAIN}++; + $perprocesspid{$process_pid}->{STATE_PCPU_PAGES_DRAINED}++; + } elsif ($tracepoint eq "mm_page_alloc_zone_locked") { + $perprocesspid{$process_pid}->{MM_PAGE_ALLOC_ZONE_LOCKED}++; + $perprocesspid{$process_pid}->{STATE_PCPU_PAGES_REFILLED}++; + } elsif ($tracepoint eq "mm_page_alloc_extfrag") { + + # Extract the details of the event now + $details = $5; + + my ($page, $pfn); + my ($alloc_order, $fallback_order, $pageblock_order); + my ($alloc_migratetype, $fallback_migratetype); + my ($fragmenting, $change_ownership); + + if ($details !~ /$regex_fragdetails/o) { + print "WARNING: Failed to parse mm_page_alloc_extfrag as expected\n"; + next; + } + + $perprocesspid{$process_pid}->{MM_PAGE_ALLOC_EXTFRAG}++; + $page = $1; + $pfn = $2; + $alloc_order = $3; + $fallback_order = $4; + $pageblock_order = $5; + $alloc_migratetype = $6; + $fallback_migratetype = $7; + $fragmenting = $8; + $change_ownership = $9; + + if ($fragmenting) { + $perprocesspid{$process_pid}->{HIGH_EXT_FRAG}++; + if ($fallback_order <= 3) { + $perprocesspid{$process_pid}->{HIGH_EXT_FRAGMENT_SEVERE}++; + } else { + $perprocesspid{$process_pid}->{HIGH_EXT_FRAGMENT_MODERATE}++; + } + } + if ($change_ownership) { + $perprocesspid{$process_pid}->{HIGH_EXT_FRAGMENT_CHANGED}++; + } + } else { + $perprocesspid{$process_pid}->{EVENT_UNKNOWN}++; + } + + # Catch a full pcpu drain event + if ($perprocesspid{$process_pid}->{STATE_PCPU_PAGES_DRAINED} && + $tracepoint ne "mm_page_pcpu_drain") { + + $perprocesspid{$process_pid}->{HIGH_PCPU_DRAINS}++; + $perprocesspid{$process_pid}->{STATE_PCPU_PAGES_DRAINED} = 0; + } + + # Catch a full pcpu refill event + if ($perprocesspid{$process_pid}->{STATE_PCPU_PAGES_REFILLED} && + $tracepoint ne "mm_page_alloc_zone_locked") { + $perprocesspid{$process_pid}->{HIGH_PCPU_REFILLS}++; + $perprocesspid{$process_pid}->{STATE_PCPU_PAGES_REFILLED} = 0; + } + + if ($sigint_pending) { + last EVENT_PROCESS; + } + } +} + +sub dump_stats { + my $hashref = shift; + my %stats = %$hashref; + + # Dump per-process stats + my $process_pid; + my $max_strlen = 0; + + # Get the maximum process name + foreach $process_pid (keys %perprocesspid) { + my $len = length($process_pid); + if ($len > $max_strlen) { + $max_strlen = $len; + } + } + $max_strlen += 2; + + printf("\n"); + printf("%-" . $max_strlen . "s %8s %10s %8s %8s %8s %8s %8s %8s %8s %8s %8s %8s %8s\n", + "Process", "Pages", "Pages", "Pages", "Pages", "PCPU", "PCPU", "PCPU", "Fragment", "Fragment", "MigType", "Fragment", "Fragment", "Unknown"); + printf("%-" . $max_strlen . "s %8s %10s %8s %8s %8s %8s %8s %8s %8s %8s %8s %8s %8s\n", + "details", "allocd", "allocd", "freed", "freed", "pages", "drains", "refills", "Fallback", "Causing", "Changed", "Severe", "Moderate", ""); + + printf("%-" . $max_strlen . "s %8s %10s %8s %8s %8s %8s %8s %8s %8s %8s %8s %8s %8s\n", + "", "", "under lock", "direct", "pagevec", "drain", "", "", "", "", "", "", "", ""); + + foreach $process_pid (keys %stats) { + # Dump final aggregates + if ($stats{$process_pid}->{STATE_PCPU_PAGES_DRAINED}) { + $stats{$process_pid}->{HIGH_PCPU_DRAINS}++; + $stats{$process_pid}->{STATE_PCPU_PAGES_DRAINED} = 0; + } + if ($stats{$process_pid}->{STATE_PCPU_PAGES_REFILLED}) { + $stats{$process_pid}->{HIGH_PCPU_REFILLS}++; + $stats{$process_pid}->{STATE_PCPU_PAGES_REFILLED} = 0; + } + + printf("%-" . $max_strlen . "s %8d %10d %8d %8d %8d %8d %8d %8d %8d %8d %8d %8d %8d\n", + $process_pid, + $stats{$process_pid}->{MM_PAGE_ALLOC}, + $stats{$process_pid}->{MM_PAGE_ALLOC_ZONE_LOCKED}, + $stats{$process_pid}->{MM_PAGE_FREE_DIRECT}, + $stats{$process_pid}->{MM_PAGEVEC_FREE}, + $stats{$process_pid}->{MM_PAGE_PCPU_DRAIN}, + $stats{$process_pid}->{HIGH_PCPU_DRAINS}, + $stats{$process_pid}->{HIGH_PCPU_REFILLS}, + $stats{$process_pid}->{MM_PAGE_ALLOC_EXTFRAG}, + $stats{$process_pid}->{HIGH_EXT_FRAG}, + $stats{$process_pid}->{HIGH_EXT_FRAGMENT_CHANGED}, + $stats{$process_pid}->{HIGH_EXT_FRAGMENT_SEVERE}, + $stats{$process_pid}->{HIGH_EXT_FRAGMENT_MODERATE}, + $stats{$process_pid}->{EVENT_UNKNOWN}); + } +} + +sub aggregate_perprocesspid() { + my $process_pid; + my $process; + undef %perprocess; + + foreach $process_pid (keys %perprocesspid) { + $process = $process_pid; + $process =~ s/-([0-9])*$//; + if ($process eq '') { + $process = "NO_PROCESS_NAME"; + } + + $perprocess{$process}->{MM_PAGE_ALLOC} += $perprocesspid{$process_pid}->{MM_PAGE_ALLOC}; + $perprocess{$process}->{MM_PAGE_ALLOC_ZONE_LOCKED} += $perprocesspid{$process_pid}->{MM_PAGE_ALLOC_ZONE_LOCKED}; + $perprocess{$process}->{MM_PAGE_FREE_DIRECT} += $perprocesspid{$process_pid}->{MM_PAGE_FREE_DIRECT}; + $perprocess{$process}->{MM_PAGEVEC_FREE} += $perprocesspid{$process_pid}->{MM_PAGEVEC_FREE}; + $perprocess{$process}->{MM_PAGE_PCPU_DRAIN} += $perprocesspid{$process_pid}->{MM_PAGE_PCPU_DRAIN}; + $perprocess{$process}->{HIGH_PCPU_DRAINS} += $perprocesspid{$process_pid}->{HIGH_PCPU_DRAINS}; + $perprocess{$process}->{HIGH_PCPU_REFILLS} += $perprocesspid{$process_pid}->{HIGH_PCPU_REFILLS}; + $perprocess{$process}->{MM_PAGE_ALLOC_EXTFRAG} += $perprocesspid{$process_pid}->{MM_PAGE_ALLOC_EXTFRAG}; + $perprocess{$process}->{HIGH_EXT_FRAG} += $perprocesspid{$process_pid}->{HIGH_EXT_FRAG}; + $perprocess{$process}->{HIGH_EXT_FRAGMENT_CHANGED} += $perprocesspid{$process_pid}->{HIGH_EXT_FRAGMENT_CHANGED}; + $perprocess{$process}->{HIGH_EXT_FRAGMENT_SEVERE} += $perprocesspid{$process_pid}->{HIGH_EXT_FRAGMENT_SEVERE}; + $perprocess{$process}->{HIGH_EXT_FRAGMENT_MODERATE} += $perprocesspid{$process_pid}->{HIGH_EXT_FRAGMENT_MODERATE}; + $perprocess{$process}->{EVENT_UNKNOWN} += $perprocesspid{$process_pid}->{EVENT_UNKNOWN}; + } +} + +sub report() { + if (!$opt_ignorepid) { + dump_stats(\%perprocesspid); + } else { + aggregate_perprocesspid(); + dump_stats(\%perprocess); + } +} + +# Process events or signals until neither is available +sub signal_loop() { + my $sigint_processed; + do { + $sigint_processed = 0; + process_events(); + + # Handle pending signals if any + if ($sigint_pending) { + my $current_time = time; + + if ($sigint_exit) { + print "Received exit signal\n"; + $sigint_pending = 0; + } + if ($sigint_report) { + if ($current_time >= $sigint_received + 2) { + report(); + $sigint_report = 0; + $sigint_pending = 0; + $sigint_processed = 1; + } + } + } + } while ($sigint_pending || $sigint_processed); +} + +signal_loop(); +report(); diff --git a/Documentation/trace/power.txt b/Documentation/trace/power.txt deleted file mode 100644 index cd805e16dc27..000000000000 --- a/Documentation/trace/power.txt +++ /dev/null @@ -1,17 +0,0 @@ -The power tracer collects detailed information about C-state and P-state -transitions, instead of just looking at the high-level "average" -information. - -There is a helper script found in scrips/tracing/power.pl in the kernel -sources which can be used to parse this information and create a -Scalable Vector Graphics (SVG) picture from the trace data. - -To use this tracer: - - echo 0 > /sys/kernel/debug/tracing/tracing_enabled - echo power > /sys/kernel/debug/tracing/current_tracer - echo 1 > /sys/kernel/debug/tracing/tracing_enabled - sleep 1 - echo 0 > /sys/kernel/debug/tracing/tracing_enabled - cat /sys/kernel/debug/tracing/trace | \ - perl scripts/tracing/power.pl > out.sv diff --git a/Documentation/trace/ring-buffer-design.txt b/Documentation/trace/ring-buffer-design.txt index 5b1d23d604c5..d299ff31df57 100644 --- a/Documentation/trace/ring-buffer-design.txt +++ b/Documentation/trace/ring-buffer-design.txt @@ -33,9 +33,9 @@ head_page - a pointer to the page that the reader will use next tail_page - a pointer to the page that will be written to next -commit_page - a pointer to the page with the last finished non nested write. +commit_page - a pointer to the page with the last finished non-nested write. -cmpxchg - hardware assisted atomic transaction that performs the following: +cmpxchg - hardware-assisted atomic transaction that performs the following: A = B iff previous A == C @@ -52,15 +52,15 @@ The Generic Ring Buffer The ring buffer can be used in either an overwrite mode or in producer/consumer mode. -Producer/consumer mode is where the producer were to fill up the +Producer/consumer mode is where if the producer were to fill up the buffer before the consumer could free up anything, the producer will stop writing to the buffer. This will lose most recent events. -Overwrite mode is where the produce were to fill up the buffer +Overwrite mode is where if the producer were to fill up the buffer before the consumer could free up anything, the producer will overwrite the older data. This will lose the oldest events. -No two writers can write at the same time (on the same per cpu buffer), +No two writers can write at the same time (on the same per-cpu buffer), but a writer may interrupt another writer, but it must finish writing before the previous writer may continue. This is very important to the algorithm. The writers act like a "stack". The way interrupts works @@ -79,16 +79,16 @@ the interrupt doing a write as well. Readers can happen at any time. But no two readers may run at the same time, nor can a reader preempt/interrupt another reader. A reader -can not preempt/interrupt a writer, but it may read/consume from the +cannot preempt/interrupt a writer, but it may read/consume from the buffer at the same time as a writer is writing, but the reader must be on another processor to do so. A reader may read on its own processor and can be preempted by a writer. -A writer can preempt a reader, but a reader can not preempt a writer. +A writer can preempt a reader, but a reader cannot preempt a writer. But a reader can read the buffer at the same time (on another processor) as a writer. -The ring buffer is made up of a list of pages held together by a link list. +The ring buffer is made up of a list of pages held together by a linked list. At initialization a reader page is allocated for the reader that is not part of the ring buffer. @@ -102,7 +102,7 @@ the head page. The reader has its own page to use. At start up time, this page is allocated but is not attached to the list. When the reader wants -to read from the buffer, if its page is empty (like it is on start up) +to read from the buffer, if its page is empty (like it is on start-up), it will swap its page with the head_page. The old reader page will become part of the ring buffer and the head_page will be removed. The page after the inserted page (old reader_page) will become the @@ -206,7 +206,7 @@ The main pointers: commit page - the page that last finished a write. -The commit page only is updated by the outer most writer in the +The commit page only is updated by the outermost writer in the writer stack. A writer that preempts another writer will not move the commit page. @@ -281,7 +281,7 @@ with the previous write. The commit pointer points to the last write location that was committed without preempting another write. When a write that preempted another write is committed, it only becomes a pending commit -and will not be a full commit till all writes have been committed. +and will not be a full commit until all writes have been committed. The commit page points to the page that has the last full commit. The tail page points to the page with the last write (before @@ -292,7 +292,7 @@ be several pages ahead. If the tail page catches up to the commit page then no more writes may take place (regardless of the mode of the ring buffer: overwrite and produce/consumer). -The order of pages are: +The order of pages is: head page commit page @@ -311,7 +311,7 @@ Possible scenario: There is a special case that the head page is after either the commit page and possibly the tail page. That is when the commit (and tail) page has been swapped with the reader page. This is because the head page is always -part of the ring buffer, but the reader page is not. When ever there +part of the ring buffer, but the reader page is not. Whenever there has been less than a full page that has been committed inside the ring buffer, and a reader swaps out a page, it will be swapping out the commit page. @@ -338,7 +338,7 @@ and a reader swaps out a page, it will be swapping out the commit page. In this case, the head page will not move when the tail and commit move back into the ring buffer. -The reader can not swap a page into the ring buffer if the commit page +The reader cannot swap a page into the ring buffer if the commit page is still on that page. If the read meets the last commit (real commit not pending or reserved), then there is nothing more to read. The buffer is considered empty until another full commit finishes. @@ -395,7 +395,7 @@ The main idea behind the lockless algorithm is to combine the moving of the head_page pointer with the swapping of pages with the reader. State flags are placed inside the pointer to the page. To do this, each page must be aligned in memory by 4 bytes. This will allow the 2 -least significant bits of the address to be used as flags. Since +least significant bits of the address to be used as flags, since they will always be zero for the address. To get the address, simply mask out the flags. @@ -460,7 +460,7 @@ When the reader tries to swap the page with the ring buffer, it will also use cmpxchg. If the flag bit in the pointer to the head page does not have the HEADER flag set, the compare will fail and the reader will need to look for the new head page and try again. -Note, the flag UPDATE and HEADER are never set at the same time. +Note, the flags UPDATE and HEADER are never set at the same time. The reader swaps the reader page as follows: @@ -539,7 +539,7 @@ updated to the reader page. | +-----------------------------+ | +------------------------------------+ -Another important point. The page that the reader page points back to +Another important point: The page that the reader page points back to by its previous pointer (the one that now points to the new head page) never points back to the reader page. That is because the reader page is not part of the ring buffer. Traversing the ring buffer via the next pointers @@ -572,7 +572,7 @@ not be able to swap the head page from the buffer, nor will it be able to move the head page, until the writer is finished with the move. This eliminates any races that the reader can have on the writer. The reader -must spin, and this is why the reader can not preempt the writer. +must spin, and this is why the reader cannot preempt the writer. tail page | @@ -659,9 +659,9 @@ before pushing the head page. If it is, then it can be assumed that the tail page wrapped the buffer, and we must drop new writes. This is not a race condition, because the commit page can only be moved -by the outter most writer (the writer that was preempted). +by the outermost writer (the writer that was preempted). This means that the commit will not move while a writer is moving the -tail page. The reader can not swap the reader page if it is also being +tail page. The reader cannot swap the reader page if it is also being used as the commit page. The reader can simply check that the commit is off the reader page. Once the commit page leaves the reader page it will never go back on it unless a reader does another swap with the @@ -733,7 +733,7 @@ The write converts the head page pointer to UPDATE. --->| |<---| |<---| |<---| |<--- +---+ +---+ +---+ +---+ -But if a nested writer preempts here. It will see that the next +But if a nested writer preempts here, it will see that the next page is a head page, but it is also nested. It will detect that it is nested and will save that information. The detection is the fact that it sees the UPDATE flag instead of a HEADER or NORMAL @@ -761,7 +761,7 @@ to NORMAL. --->| |<---| |<---| |<---| |<--- +---+ +---+ +---+ +---+ -After the nested writer finishes, the outer most writer will convert +After the nested writer finishes, the outermost writer will convert the UPDATE pointer to NORMAL. @@ -812,7 +812,7 @@ head page. +---+ +---+ +---+ +---+ The nested writer moves the tail page forward. But does not set the old -update page to NORMAL because it is not the outer most writer. +update page to NORMAL because it is not the outermost writer. tail page | @@ -892,7 +892,7 @@ It will return to the first writer. --->| |<---| |<---| |<---| |<--- +---+ +---+ +---+ +---+ -The first writer can not know atomically test if the tail page moved +The first writer cannot know atomically if the tail page moved while it updates the HEAD page. It will then update the head page to what it thinks is the new head page. @@ -923,9 +923,9 @@ if the tail page is either where it use to be or on the next page: --->| |<---| |<---| |<---| |<--- +---+ +---+ +---+ +---+ -If tail page != A and tail page does not equal B, then it must reset the -pointer back to NORMAL. The fact that it only needs to worry about -nested writers, it only needs to check this after setting the HEAD page. +If tail page != A and tail page != B, then it must reset the pointer +back to NORMAL. The fact that it only needs to worry about nested +writers means that it only needs to check this after setting the HEAD page. (first writer) @@ -939,7 +939,7 @@ nested writers, it only needs to check this after setting the HEAD page. +---+ +---+ +---+ +---+ Now the writer can update the head page. This is also why the head page must -remain in UPDATE and only reset by the outer most writer. This prevents +remain in UPDATE and only reset by the outermost writer. This prevents the reader from seeing the incorrect head page. diff --git a/Documentation/trace/tracepoint-analysis.txt b/Documentation/trace/tracepoint-analysis.txt new file mode 100644 index 000000000000..87bee3c129ba --- /dev/null +++ b/Documentation/trace/tracepoint-analysis.txt @@ -0,0 +1,327 @@ + Notes on Analysing Behaviour Using Events and Tracepoints + + Documentation written by Mel Gorman + PCL information heavily based on email from Ingo Molnar + +1. Introduction +=============== + +Tracepoints (see Documentation/trace/tracepoints.txt) can be used without +creating custom kernel modules to register probe functions using the event +tracing infrastructure. + +Simplistically, tracepoints represent important events that can be +taken in conjunction with other tracepoints to build a "Big Picture" of +what is going on within the system. There are a large number of methods for +gathering and interpreting these events. Lacking any current Best Practises, +this document describes some of the methods that can be used. + +This document assumes that debugfs is mounted on /sys/kernel/debug and that +the appropriate tracing options have been configured into the kernel. It is +assumed that the PCL tool tools/perf has been installed and is in your path. + +2. Listing Available Events +=========================== + +2.1 Standard Utilities +---------------------- + +All possible events are visible from /sys/kernel/debug/tracing/events. Simply +calling + + $ find /sys/kernel/debug/tracing/events -type d + +will give a fair indication of the number of events available. + +2.2 PCL (Performance Counters for Linux) +------- + +Discovery and enumeration of all counters and events, including tracepoints, +are available with the perf tool. Getting a list of available events is a +simple case of: + + $ perf list 2>&1 | grep Tracepoint + ext4:ext4_free_inode [Tracepoint event] + ext4:ext4_request_inode [Tracepoint event] + ext4:ext4_allocate_inode [Tracepoint event] + ext4:ext4_write_begin [Tracepoint event] + ext4:ext4_ordered_write_end [Tracepoint event] + [ .... remaining output snipped .... ] + + +3. Enabling Events +================== + +3.1 System-Wide Event Enabling +------------------------------ + +See Documentation/trace/events.txt for a proper description on how events +can be enabled system-wide. A short example of enabling all events related +to page allocation would look something like: + + $ for i in `find /sys/kernel/debug/tracing/events -name "enable" | grep mm_`; do echo 1 > $i; done + +3.2 System-Wide Event Enabling with SystemTap +--------------------------------------------- + +In SystemTap, tracepoints are accessible using the kernel.trace() function +call. The following is an example that reports every 5 seconds what processes +were allocating the pages. + + global page_allocs + + probe kernel.trace("mm_page_alloc") { + page_allocs[execname()]++ + } + + function print_count() { + printf ("%-25s %-s\n", "#Pages Allocated", "Process Name") + foreach (proc in page_allocs-) + printf("%-25d %s\n", page_allocs[proc], proc) + printf ("\n") + delete page_allocs + } + + probe timer.s(5) { + print_count() + } + +3.3 System-Wide Event Enabling with PCL +--------------------------------------- + +By specifying the -a switch and analysing sleep, the system-wide events +for a duration of time can be examined. + + $ perf stat -a \ + -e kmem:mm_page_alloc -e kmem:mm_page_free_direct \ + -e kmem:mm_pagevec_free \ + sleep 10 + Performance counter stats for 'sleep 10': + + 9630 kmem:mm_page_alloc + 2143 kmem:mm_page_free_direct + 7424 kmem:mm_pagevec_free + + 10.002577764 seconds time elapsed + +Similarly, one could execute a shell and exit it as desired to get a report +at that point. + +3.4 Local Event Enabling +------------------------ + +Documentation/trace/ftrace.txt describes how to enable events on a per-thread +basis using set_ftrace_pid. + +3.5 Local Event Enablement with PCL +----------------------------------- + +Events can be activated and tracked for the duration of a process on a local +basis using PCL such as follows. + + $ perf stat -e kmem:mm_page_alloc -e kmem:mm_page_free_direct \ + -e kmem:mm_pagevec_free ./hackbench 10 + Time: 0.909 + + Performance counter stats for './hackbench 10': + + 17803 kmem:mm_page_alloc + 12398 kmem:mm_page_free_direct + 4827 kmem:mm_pagevec_free + + 0.973913387 seconds time elapsed + +4. Event Filtering +================== + +Documentation/trace/ftrace.txt covers in-depth how to filter events in +ftrace. Obviously using grep and awk of trace_pipe is an option as well +as any script reading trace_pipe. + +5. Analysing Event Variances with PCL +===================================== + +Any workload can exhibit variances between runs and it can be important +to know what the standard deviation is. By and large, this is left to the +performance analyst to do it by hand. In the event that the discrete event +occurrences are useful to the performance analyst, then perf can be used. + + $ perf stat --repeat 5 -e kmem:mm_page_alloc -e kmem:mm_page_free_direct + -e kmem:mm_pagevec_free ./hackbench 10 + Time: 0.890 + Time: 0.895 + Time: 0.915 + Time: 1.001 + Time: 0.899 + + Performance counter stats for './hackbench 10' (5 runs): + + 16630 kmem:mm_page_alloc ( +- 3.542% ) + 11486 kmem:mm_page_free_direct ( +- 4.771% ) + 4730 kmem:mm_pagevec_free ( +- 2.325% ) + + 0.982653002 seconds time elapsed ( +- 1.448% ) + +In the event that some higher-level event is required that depends on some +aggregation of discrete events, then a script would need to be developed. + +Using --repeat, it is also possible to view how events are fluctuating over +time on a system-wide basis using -a and sleep. + + $ perf stat -e kmem:mm_page_alloc -e kmem:mm_page_free_direct \ + -e kmem:mm_pagevec_free \ + -a --repeat 10 \ + sleep 1 + Performance counter stats for 'sleep 1' (10 runs): + + 1066 kmem:mm_page_alloc ( +- 26.148% ) + 182 kmem:mm_page_free_direct ( +- 5.464% ) + 890 kmem:mm_pagevec_free ( +- 30.079% ) + + 1.002251757 seconds time elapsed ( +- 0.005% ) + +6. Higher-Level Analysis with Helper Scripts +============================================ + +When events are enabled the events that are triggering can be read from +/sys/kernel/debug/tracing/trace_pipe in human-readable format although binary +options exist as well. By post-processing the output, further information can +be gathered on-line as appropriate. Examples of post-processing might include + + o Reading information from /proc for the PID that triggered the event + o Deriving a higher-level event from a series of lower-level events. + o Calculating latencies between two events + +Documentation/trace/postprocess/trace-pagealloc-postprocess.pl is an example +script that can read trace_pipe from STDIN or a copy of a trace. When used +on-line, it can be interrupted once to generate a report without exiting +and twice to exit. + +Simplistically, the script just reads STDIN and counts up events but it +also can do more such as + + o Derive high-level events from many low-level events. If a number of pages + are freed to the main allocator from the per-CPU lists, it recognises + that as one per-CPU drain even though there is no specific tracepoint + for that event + o It can aggregate based on PID or individual process number + o In the event memory is getting externally fragmented, it reports + on whether the fragmentation event was severe or moderate. + o When receiving an event about a PID, it can record who the parent was so + that if large numbers of events are coming from very short-lived + processes, the parent process responsible for creating all the helpers + can be identified + +7. Lower-Level Analysis with PCL +================================ + +There may also be a requirement to identify what functions within a program +were generating events within the kernel. To begin this sort of analysis, the +data must be recorded. At the time of writing, this required root: + + $ perf record -c 1 \ + -e kmem:mm_page_alloc -e kmem:mm_page_free_direct \ + -e kmem:mm_pagevec_free \ + ./hackbench 10 + Time: 0.894 + [ perf record: Captured and wrote 0.733 MB perf.data (~32010 samples) ] + +Note the use of '-c 1' to set the event period to sample. The default sample +period is quite high to minimise overhead but the information collected can be +very coarse as a result. + +This record outputted a file called perf.data which can be analysed using +perf report. + + $ perf report + # Samples: 30922 + # + # Overhead Command Shared Object + # ........ ......... ................................ + # + 87.27% hackbench [vdso] + 6.85% hackbench /lib/i686/cmov/libc-2.9.so + 2.62% hackbench /lib/ld-2.9.so + 1.52% perf [vdso] + 1.22% hackbench ./hackbench + 0.48% hackbench [kernel] + 0.02% perf /lib/i686/cmov/libc-2.9.so + 0.01% perf /usr/bin/perf + 0.01% perf /lib/ld-2.9.so + 0.00% hackbench /lib/i686/cmov/libpthread-2.9.so + # + # (For more details, try: perf report --sort comm,dso,symbol) + # + +According to this, the vast majority of events triggered on events +within the VDSO. With simple binaries, this will often be the case so let's +take a slightly different example. In the course of writing this, it was +noticed that X was generating an insane amount of page allocations so let's look +at it: + + $ perf record -c 1 -f \ + -e kmem:mm_page_alloc -e kmem:mm_page_free_direct \ + -e kmem:mm_pagevec_free \ + -p `pidof X` + +This was interrupted after a few seconds and + + $ perf report + # Samples: 27666 + # + # Overhead Command Shared Object + # ........ ....... ....................................... + # + 51.95% Xorg [vdso] + 47.95% Xorg /opt/gfx-test/lib/libpixman-1.so.0.13.1 + 0.09% Xorg /lib/i686/cmov/libc-2.9.so + 0.01% Xorg [kernel] + # + # (For more details, try: perf report --sort comm,dso,symbol) + # + +So, almost half of the events are occurring in a library. To get an idea which +symbol: + + $ perf report --sort comm,dso,symbol + # Samples: 27666 + # + # Overhead Command Shared Object Symbol + # ........ ....... ....................................... ...... + # + 51.95% Xorg [vdso] [.] 0x000000ffffe424 + 47.93% Xorg /opt/gfx-test/lib/libpixman-1.so.0.13.1 [.] pixmanFillsse2 + 0.09% Xorg /lib/i686/cmov/libc-2.9.so [.] _int_malloc + 0.01% Xorg /opt/gfx-test/lib/libpixman-1.so.0.13.1 [.] pixman_region32_copy_f + 0.01% Xorg [kernel] [k] read_hpet + 0.01% Xorg /opt/gfx-test/lib/libpixman-1.so.0.13.1 [.] get_fast_path + 0.00% Xorg [kernel] [k] ftrace_trace_userstack + +To see where within the function pixmanFillsse2 things are going wrong: + + $ perf annotate pixmanFillsse2 + [ ... ] + 0.00 : 34eeb: 0f 18 08 prefetcht0 (%eax) + : } + : + : extern __inline void __attribute__((__gnu_inline__, __always_inline__, _ + : _mm_store_si128 (__m128i *__P, __m128i __B) : { + : *__P = __B; + 12.40 : 34eee: 66 0f 7f 80 40 ff ff movdqa %xmm0,-0xc0(%eax) + 0.00 : 34ef5: ff + 12.40 : 34ef6: 66 0f 7f 80 50 ff ff movdqa %xmm0,-0xb0(%eax) + 0.00 : 34efd: ff + 12.39 : 34efe: 66 0f 7f 80 60 ff ff movdqa %xmm0,-0xa0(%eax) + 0.00 : 34f05: ff + 12.67 : 34f06: 66 0f 7f 80 70 ff ff movdqa %xmm0,-0x90(%eax) + 0.00 : 34f0d: ff + 12.58 : 34f0e: 66 0f 7f 40 80 movdqa %xmm0,-0x80(%eax) + 12.31 : 34f13: 66 0f 7f 40 90 movdqa %xmm0,-0x70(%eax) + 12.40 : 34f18: 66 0f 7f 40 a0 movdqa %xmm0,-0x60(%eax) + 12.31 : 34f1d: 66 0f 7f 40 b0 movdqa %xmm0,-0x50(%eax) + +At a glance, it looks like the time is being spent copying pixmaps to +the card. Further investigation would be needed to determine why pixmaps +are being copied around so much but a starting point would be to take an +ancient build of libpixmap out of the library path where it was totally +forgotten about from months ago! diff --git a/Documentation/usb/authorization.txt b/Documentation/usb/authorization.txt index 381b22ee7834..c069b6884c77 100644 --- a/Documentation/usb/authorization.txt +++ b/Documentation/usb/authorization.txt @@ -16,20 +16,20 @@ Usage: Authorize a device to connect: -$ echo 1 > /sys/usb/devices/DEVICE/authorized +$ echo 1 > /sys/bus/usb/devices/DEVICE/authorized Deauthorize a device: -$ echo 0 > /sys/usb/devices/DEVICE/authorized +$ echo 0 > /sys/bus/usb/devices/DEVICE/authorized Set new devices connected to hostX to be deauthorized by default (ie: lock down): -$ echo 0 > /sys/bus/devices/usbX/authorized_default +$ echo 0 > /sys/bus/usb/devices/usbX/authorized_default Remove the lock down: -$ echo 1 > /sys/bus/devices/usbX/authorized_default +$ echo 1 > /sys/bus/usb/devices/usbX/authorized_default By default, Wired USB devices are authorized by default to connect. Wireless USB hosts deauthorize by default all new connected @@ -47,7 +47,7 @@ USB port): boot up rc.local -> - for host in /sys/bus/devices/usb* + for host in /sys/bus/usb/devices/usb* do echo 0 > $host/authorized_default done diff --git a/Documentation/usb/power-management.txt b/Documentation/usb/power-management.txt index ad642615ad4c..3bf6818c8cf5 100644 --- a/Documentation/usb/power-management.txt +++ b/Documentation/usb/power-management.txt @@ -2,7 +2,7 @@ Alan Stern <stern@rowland.harvard.edu> - October 5, 2007 + November 10, 2009 @@ -71,12 +71,10 @@ being accessed through sysfs, then it definitely is idle. Forms of dynamic PM ------------------- -Dynamic suspends can occur in two ways: manual and automatic. -"Manual" means that the user has told the kernel to suspend a device, -whereas "automatic" means that the kernel has decided all by itself to -suspend a device. Automatic suspend is called "autosuspend" for -short. In general, a device won't be autosuspended unless it has been -idle for some minimum period of time, the so-called idle-delay time. +Dynamic suspends occur when the kernel decides to suspend an idle +device. This is called "autosuspend" for short. In general, a device +won't be autosuspended unless it has been idle for some minimum period +of time, the so-called idle-delay time. Of course, nothing the kernel does on its own initiative should prevent the computer or its devices from working properly. If a @@ -96,10 +94,11 @@ idle. We can categorize power management events in two broad classes: external and internal. External events are those triggered by some agent outside the USB stack: system suspend/resume (triggered by -userspace), manual dynamic suspend/resume (also triggered by -userspace), and remote wakeup (triggered by the device). Internal -events are those triggered within the USB stack: autosuspend and -autoresume. +userspace), manual dynamic resume (also triggered by userspace), and +remote wakeup (triggered by the device). Internal events are those +triggered within the USB stack: autosuspend and autoresume. Note that +all dynamic suspend events are internal; external agents are not +allowed to issue dynamic suspends. The user interface for dynamic PM @@ -123,9 +122,9 @@ relevant attribute files are: wakeup, level, and autosuspend. power/level - This file contains one of three words: "on", "auto", - or "suspend". You can write those words to the file - to change the device's setting. + This file contains one of two words: "on" or "auto". + You can write those words to the file to change the + device's setting. "on" means that the device should be resumed and autosuspend is not allowed. (Of course, system @@ -134,10 +133,10 @@ relevant attribute files are: wakeup, level, and autosuspend. "auto" is the normal state in which the kernel is allowed to autosuspend and autoresume the device. - "suspend" means that the device should remain - suspended, and autoresume is not allowed. (But remote - wakeup may still be allowed, since it is controlled - separately by the power/wakeup attribute.) + (In kernels up to 2.6.32, you could also specify + "suspend", meaning that the device should remain + suspended and autoresume was not allowed. This + setting is no longer supported.) power/autosuspend @@ -145,9 +144,9 @@ relevant attribute files are: wakeup, level, and autosuspend. number of seconds the device should remain idle before the kernel will autosuspend it (the idle-delay time). The default is 2. 0 means to autosuspend as soon as - the device becomes idle, and -1 means never to - autosuspend. You can write a number to the file to - change the autosuspend idle-delay time. + the device becomes idle, and negative values mean + never to autosuspend. You can write a number to the + file to change the autosuspend idle-delay time. Writing "-1" to power/autosuspend and writing "on" to power/level do essentially the same thing -- they both prevent the device from being @@ -313,13 +312,14 @@ three of the methods listed above. In addition, a driver indicates that it supports autosuspend by setting the .supports_autosuspend flag in its usb_driver structure. It is then responsible for informing the USB core whenever one of its interfaces becomes busy or idle. The -driver does so by calling these five functions: +driver does so by calling these six functions: int usb_autopm_get_interface(struct usb_interface *intf); void usb_autopm_put_interface(struct usb_interface *intf); - int usb_autopm_set_interface(struct usb_interface *intf); int usb_autopm_get_interface_async(struct usb_interface *intf); void usb_autopm_put_interface_async(struct usb_interface *intf); + void usb_autopm_get_interface_no_resume(struct usb_interface *intf); + void usb_autopm_put_interface_no_suspend(struct usb_interface *intf); The functions work by maintaining a counter in the usb_interface structure. When intf->pm_usage_count is > 0 then the interface is @@ -331,11 +331,13 @@ considered to be idle, and the kernel may autosuspend the device. associated with the device itself rather than any of its interfaces. This field is used only by the USB core.) -The driver owns intf->pm_usage_count; it can modify the value however -and whenever it likes. A nice aspect of the non-async usb_autopm_* -routines is that the changes they make are protected by the usb_device -structure's PM mutex (udev->pm_mutex); however drivers may change -pm_usage_count without holding the mutex. Drivers using the async +Drivers must not modify intf->pm_usage_count directly; its value +should be changed only be using the functions listed above. Drivers +are responsible for insuring that the overall change to pm_usage_count +during their lifetime balances out to 0 (it may be necessary for the +disconnect method to call usb_autopm_put_interface() one or more times +to fulfill this requirement). The first two routines use the PM mutex +in struct usb_device for mutual exclusion; drivers using the async routines are responsible for their own synchronization and mutual exclusion. @@ -347,11 +349,6 @@ exclusion. attempts an autosuspend if the new value is <= 0 and the device isn't suspended. - usb_autopm_set_interface() leaves pm_usage_count alone. - It attempts an autoresume if the value is > 0 and the device - is suspended, and it attempts an autosuspend if the value is - <= 0 and the device isn't suspended. - usb_autopm_get_interface_async() and usb_autopm_put_interface_async() do almost the same things as their non-async counterparts. The differences are: they do @@ -360,13 +357,11 @@ exclusion. such as an URB's completion handler, but when they return the device will not generally not yet be in the desired state. -There also are a couple of utility routines drivers can use: - - usb_autopm_enable() sets pm_usage_cnt to 0 and then calls - usb_autopm_set_interface(), which will attempt an autosuspend. - - usb_autopm_disable() sets pm_usage_cnt to 1 and then calls - usb_autopm_set_interface(), which will attempt an autoresume. + usb_autopm_get_interface_no_resume() and + usb_autopm_put_interface_no_suspend() merely increment or + decrement the pm_usage_count value; they do not attempt to + carry out an autoresume or an autosuspend. Hence they can be + called in an atomic context. The conventional usage pattern is that a driver calls usb_autopm_get_interface() in its open routine and @@ -381,9 +376,9 @@ the device hasn't been idle for long enough, a delayed workqueue routine is automatically set up to carry out the operation when the autosuspend idle-delay has expired. -Autoresume attempts also can fail. This will happen if power/level is -set to "suspend" or if the device doesn't manage to resume properly. -Unlike autosuspend, there's no delay for an autoresume. +Autoresume attempts also can fail, although failure would mean that +the device is no longer present or operating properly. Unlike +autosuspend, there's no delay for an autoresume. Other parts of the driver interface @@ -400,11 +395,11 @@ though, setting this flag won't cause the kernel to autoresume it. Normally a driver would set this flag in its probe method, at which time the device is guaranteed not to be autosuspended.) -The usb_autopm_* routines have to run in a sleepable process context; -they must not be called from an interrupt handler or while holding a -spinlock. In fact, the entire autosuspend mechanism is not well geared -toward interrupt-driven operation. However there is one thing a -driver can do in an interrupt handler: +The synchronous usb_autopm_* routines have to run in a sleepable +process context; they must not be called from an interrupt handler or +while holding a spinlock. In fact, the entire autosuspend mechanism +is not well geared toward interrupt-driven operation. However there +is one thing a driver can do in an interrupt handler: usb_mark_last_busy(struct usb_device *udev); @@ -423,15 +418,16 @@ an URB had completed too recently. External suspend calls should never be allowed to fail in this way, only autosuspend calls. The driver can tell them apart by checking -udev->auto_pm; this flag will be set to 1 for internal PM events -(autosuspend or autoresume) and 0 for external PM events. +the PM_EVENT_AUTO bit in the message.event argument to the suspend +method; this bit will be set for internal PM events (autosuspend) and +clear for external PM events. Many of the ingredients in the autosuspend framework are oriented towards interfaces: The usb_interface structure contains the pm_usage_cnt field, and the usb_autopm_* routines take an interface pointer as their argument. But somewhat confusingly, a few of the -pieces (usb_mark_last_busy() and udev->auto_pm) use the usb_device -structure instead. Drivers need to keep this straight; they can call +pieces (i.e., usb_mark_last_busy()) use the usb_device structure +instead. Drivers need to keep this straight; they can call interface_to_usbdev() to find the device structure for a given interface. @@ -530,13 +526,3 @@ succeed, it may still remain active and thus cause the system to resume as soon as the system suspend is complete. Or the remote wakeup may fail and get lost. Which outcome occurs depends on timing and on the hardware and firmware design. - -More interestingly, a device might undergo a manual resume or -autoresume during system suspend. With current kernels this shouldn't -happen, because manual resumes must be initiated by userspace and -autoresumes happen in response to I/O requests, but all user processes -and I/O should be quiescent during a system suspend -- thanks to the -freezer. However there are plans to do away with the freezer, which -would mean these things would become possible. If and when this comes -about, the USB core will carefully arrange matters so that either type -of resume will block until the entire system has resumed. diff --git a/Documentation/usb/usbmon.txt b/Documentation/usb/usbmon.txt index 6c3c625b7f30..66f92d1194c1 100644 --- a/Documentation/usb/usbmon.txt +++ b/Documentation/usb/usbmon.txt @@ -33,7 +33,7 @@ if usbmon is built into the kernel. Verify that bus sockets are present. -# ls /sys/kernel/debug/usbmon +# ls /sys/kernel/debug/usb/usbmon 0s 0u 1s 1t 1u 2s 2t 2u 3s 3t 3u 4s 4t 4u # @@ -58,11 +58,11 @@ Bus=03 means it's bus 3. 3. Start 'cat' -# cat /sys/kernel/debug/usbmon/3u > /tmp/1.mon.out +# cat /sys/kernel/debug/usb/usbmon/3u > /tmp/1.mon.out to listen on a single bus, otherwise, to listen on all buses, type: -# cat /sys/kernel/debug/usbmon/0u > /tmp/1.mon.out +# cat /sys/kernel/debug/usb/usbmon/0u > /tmp/1.mon.out This process will be reading until killed. Naturally, the output can be redirected to a desirable location. This is preferred, because it is going @@ -305,7 +305,7 @@ Before the call, hdr, data, and alloc should be filled. Upon return, the area pointed by hdr contains the next event structure, and the data buffer contains the data, if any. The event is removed from the kernel buffer. -The MON_IOCX_GET copies 48 bytes, MON_IOCX_GETX copies 64 bytes. +The MON_IOCX_GET copies 48 bytes to hdr area, MON_IOCX_GETX copies 64 bytes. MON_IOCX_MFETCH, defined as _IOWR(MON_IOC_MAGIC, 7, struct mon_mfetch_arg) diff --git a/Documentation/vgaarbiter.txt b/Documentation/vgaarbiter.txt new file mode 100644 index 000000000000..43a9b0694fdd --- /dev/null +++ b/Documentation/vgaarbiter.txt @@ -0,0 +1,194 @@ + +VGA Arbiter +=========== + +Graphic devices are accessed through ranges in I/O or memory space. While most +modern devices allow relocation of such ranges, some "Legacy" VGA devices +implemented on PCI will typically have the same "hard-decoded" addresses as +they did on ISA. For more details see "PCI Bus Binding to IEEE Std 1275-1994 +Standard for Boot (Initialization Configuration) Firmware Revision 2.1" +Section 7, Legacy Devices. + +The Resource Access Control (RAC) module inside the X server [0] existed for +the legacy VGA arbitration task (besides other bus management tasks) when more +than one legacy device co-exists on the same machine. But the problem happens +when these devices are trying to be accessed by different userspace clients +(e.g. two server in parallel). Their address assignments conflict. Moreover, +ideally, being an userspace application, it is not the role of the the X +server to control bus resources. Therefore an arbitration scheme outside of +the X server is needed to control the sharing of these resources. This +document introduces the operation of the VGA arbiter implemented for Linux +kernel. + +---------------------------------------------------------------------------- + +I. Details and Theory of Operation + I.1 vgaarb + I.2 libpciaccess + I.3 xf86VGAArbiter (X server implementation) +II. Credits +III.References + + +I. Details and Theory of Operation +================================== + +I.1 vgaarb +---------- + +The vgaarb is a module of the Linux Kernel. When it is initially loaded, it +scans all PCI devices and adds the VGA ones inside the arbitration. The +arbiter then enables/disables the decoding on different devices of the VGA +legacy instructions. Device which do not want/need to use the arbiter may +explicitly tell it by calling vga_set_legacy_decoding(). + +The kernel exports a char device interface (/dev/vga_arbiter) to the clients, +which has the following semantics: + + open : open user instance of the arbiter. By default, it's attached to + the default VGA device of the system. + + close : close user instance. Release locks made by the user + + read : return a string indicating the status of the target like: + + "<card_ID>,decodes=<io_state>,owns=<io_state>,locks=<io_state> (ic,mc)" + + An IO state string is of the form {io,mem,io+mem,none}, mc and + ic are respectively mem and io lock counts (for debugging/ + diagnostic only). "decodes" indicate what the card currently + decodes, "owns" indicates what is currently enabled on it, and + "locks" indicates what is locked by this card. If the card is + unplugged, we get "invalid" then for card_ID and an -ENODEV + error is returned for any command until a new card is targeted. + + + write : write a command to the arbiter. List of commands: + + target <card_ID> : switch target to card <card_ID> (see below) + lock <io_state> : acquires locks on target ("none" is an invalid io_state) + trylock <io_state> : non-blocking acquire locks on target (returns EBUSY if + unsuccessful) + unlock <io_state> : release locks on target + unlock all : release all locks on target held by this user (not + implemented yet) + decodes <io_state> : set the legacy decoding attributes for the card + + poll : event if something changes on any card (not just the + target) + + card_ID is of the form "PCI:domain:bus:dev.fn". It can be set to "default" + to go back to the system default card (TODO: not implemented yet). Currently, + only PCI is supported as a prefix, but the userland API may support other bus + types in the future, even if the current kernel implementation doesn't. + +Note about locks: + +The driver keeps track of which user has which locks on which card. It +supports stacking, like the kernel one. This complexifies the implementation +a bit, but makes the arbiter more tolerant to user space problems and able +to properly cleanup in all cases when a process dies. +Currently, a max of 16 cards can have locks simultaneously issued from +user space for a given user (file descriptor instance) of the arbiter. + +In the case of devices hot-{un,}plugged, there is a hook - pci_notify() - to +notify them being added/removed in the system and automatically added/removed +in the arbiter. + +There's also a in-kernel API of the arbiter in the case of DRM, vgacon and +others which may use the arbiter. + + +I.2 libpciaccess +---------------- + +To use the vga arbiter char device it was implemented an API inside the +libpciaccess library. One field was added to struct pci_device (each device +on the system): + + /* the type of resource decoded by the device */ + int vgaarb_rsrc; + +Besides it, in pci_system were added: + + int vgaarb_fd; + int vga_count; + struct pci_device *vga_target; + struct pci_device *vga_default_dev; + + +The vga_count is usually need to keep informed how many cards are being +arbitrated, so for instance if there's only one then it can totally escape the +scheme. + + +These functions below acquire VGA resources for the given card and mark those +resources as locked. If the resources requested are "normal" (and not legacy) +resources, the arbiter will first check whether the card is doing legacy +decoding for that type of resource. If yes, the lock is "converted" into a +legacy resource lock. The arbiter will first look for all VGA cards that +might conflict and disable their IOs and/or Memory access, including VGA +forwarding on P2P bridges if necessary, so that the requested resources can +be used. Then, the card is marked as locking these resources and the IO and/or +Memory access is enabled on the card (including VGA forwarding on parent +P2P bridges if any). In the case of vga_arb_lock(), the function will block +if some conflicting card is already locking one of the required resources (or +any resource on a different bus segment, since P2P bridges don't differentiate +VGA memory and IO afaik). If the card already owns the resources, the function +succeeds. vga_arb_trylock() will return (-EBUSY) instead of blocking. Nested +calls are supported (a per-resource counter is maintained). + + +Set the target device of this client. + int pci_device_vgaarb_set_target (struct pci_device *dev); + + +For instance, in x86 if two devices on the same bus want to lock different +resources, both will succeed (lock). If devices are in different buses and +trying to lock different resources, only the first who tried succeeds. + int pci_device_vgaarb_lock (void); + int pci_device_vgaarb_trylock (void); + +Unlock resources of device. + int pci_device_vgaarb_unlock (void); + +Indicates to the arbiter if the card decodes legacy VGA IOs, legacy VGA +Memory, both, or none. All cards default to both, the card driver (fbdev for +example) should tell the arbiter if it has disabled legacy decoding, so the +card can be left out of the arbitration process (and can be safe to take +interrupts at any time. + int pci_device_vgaarb_decodes (int new_vgaarb_rsrc); + +Connects to the arbiter device, allocates the struct + int pci_device_vgaarb_init (void); + +Close the connection + void pci_device_vgaarb_fini (void); + + +I.3 xf86VGAArbiter (X server implementation) +-------------------------------------------- + +(TODO) + +X server basically wraps all the functions that touch VGA registers somehow. + + +II. Credits +=========== + +Benjamin Herrenschmidt (IBM?) started this work when he discussed such design +with the Xorg community in 2005 [1, 2]. In the end of 2007, Paulo Zanoni and +Tiago Vignatti (both of C3SL/Federal University of Paran) proceeded his work +enhancing the kernel code to adapt as a kernel module and also did the +implementation of the user space side [3]. Now (2009) Tiago Vignatti and Dave +Airlie finally put this work in shape and queued to Jesse Barnes' PCI tree. + + +III. References +============== + +[0] http://cgit.freedesktop.org/xorg/xserver/commit/?id=4b42448a2388d40f257774fbffdccaea87bd0347 +[1] http://lists.freedesktop.org/archives/xorg/2005-March/006663.html +[2] http://lists.freedesktop.org/archives/xorg/2005-March/006745.html +[3] http://lists.freedesktop.org/archives/xorg/2007-October/029507.html diff --git a/Documentation/video4linux/CARDLIST.cx23885 b/Documentation/video4linux/CARDLIST.cx23885 index 450b8f8c389b..7539e8fa1ffd 100644 --- a/Documentation/video4linux/CARDLIST.cx23885 +++ b/Documentation/video4linux/CARDLIST.cx23885 @@ -21,3 +21,8 @@ 20 -> Hauppauge WinTV-HVR1255 [0070:2251] 21 -> Hauppauge WinTV-HVR1210 [0070:2291,0070:2295] 22 -> Mygica X8506 DMB-TH [14f1:8651] + 23 -> Magic-Pro ProHDTV Extreme 2 [14f1:8657] + 24 -> Hauppauge WinTV-HVR1850 [0070:8541] + 25 -> Compro VideoMate E800 [1858:e800] + 26 -> Hauppauge WinTV-HVR1290 [0070:8551] + 27 -> Mygica X8558 PRO DMB-TH [14f1:8578] diff --git a/Documentation/video4linux/CARDLIST.cx88 b/Documentation/video4linux/CARDLIST.cx88 index 0736518b2f88..7ec3c4e4b60f 100644 --- a/Documentation/video4linux/CARDLIST.cx88 +++ b/Documentation/video4linux/CARDLIST.cx88 @@ -80,3 +80,5 @@ 79 -> Terratec Cinergy HT PCI MKII [153b:1177] 80 -> Hauppauge WinTV-IR Only [0070:9290] 81 -> Leadtek WinFast DTV1800 Hybrid [107d:6654] + 82 -> WinFast DTV2000 H rev. J [107d:6f2b] + 83 -> Prof 7301 DVB-S/S2 [b034:3034] diff --git a/Documentation/video4linux/CARDLIST.em28xx b/Documentation/video4linux/CARDLIST.em28xx index e352d754875c..0c166ff003a0 100644 --- a/Documentation/video4linux/CARDLIST.em28xx +++ b/Documentation/video4linux/CARDLIST.em28xx @@ -1,5 +1,5 @@ 0 -> Unknown EM2800 video grabber (em2800) [eb1a:2800] - 1 -> Unknown EM2750/28xx video grabber (em2820/em2840) [eb1a:2710,eb1a:2820,eb1a:2821,eb1a:2860,eb1a:2861,eb1a:2870,eb1a:2881,eb1a:2883] + 1 -> Unknown EM2750/28xx video grabber (em2820/em2840) [eb1a:2710,eb1a:2820,eb1a:2821,eb1a:2860,eb1a:2861,eb1a:2862,eb1a:2870,eb1a:2881,eb1a:2883,eb1a:2868] 2 -> Terratec Cinergy 250 USB (em2820/em2840) [0ccd:0036] 3 -> Pinnacle PCTV USB 2 (em2820/em2840) [2304:0208] 4 -> Hauppauge WinTV USB 2 (em2820/em2840) [2040:4200,2040:4201] @@ -7,7 +7,7 @@ 6 -> Terratec Cinergy 200 USB (em2800) 7 -> Leadtek Winfast USB II (em2800) [0413:6023] 8 -> Kworld USB2800 (em2800) - 9 -> Pinnacle Dazzle DVC 90/100/101/107 / Kaiser Baas Video to DVD maker (em2820/em2840) [1b80:e302,2304:0207,2304:021a] + 9 -> Pinnacle Dazzle DVC 90/100/101/107 / Kaiser Baas Video to DVD maker (em2820/em2840) [1b80:e302,1b80:e304,2304:0207,2304:021a] 10 -> Hauppauge WinTV HVR 900 (em2880) [2040:6500] 11 -> Terratec Hybrid XS (em2880) [0ccd:0042] 12 -> Kworld PVR TV 2800 RF (em2820/em2840) @@ -33,7 +33,7 @@ 34 -> Terratec Cinergy A Hybrid XS (em2860) [0ccd:004f] 35 -> Typhoon DVD Maker (em2860) 36 -> NetGMBH Cam (em2860) - 37 -> Gadmei UTV330 (em2860) + 37 -> Gadmei UTV330 (em2860) [eb1a:50a6] 38 -> Yakumo MovieMixer (em2861) 39 -> KWorld PVRTV 300U (em2861) [eb1a:e300] 40 -> Plextor ConvertX PX-TV100U (em2861) [093b:a005] @@ -67,3 +67,6 @@ 69 -> KWorld ATSC 315U HDTV TV Box (em2882) [eb1a:a313] 70 -> Evga inDtube (em2882) 71 -> Silvercrest Webcam 1.3mpix (em2820/em2840) + 72 -> Gadmei UTV330+ (em2861) + 73 -> Reddo DVB-C USB TV Box (em2870) + 74 -> Actionmaster/LinXcel/Digitus VC211A (em2800) diff --git a/Documentation/video4linux/CARDLIST.saa7134 b/Documentation/video4linux/CARDLIST.saa7134 index c913e5614195..fce1e7eb0474 100644 --- a/Documentation/video4linux/CARDLIST.saa7134 +++ b/Documentation/video4linux/CARDLIST.saa7134 @@ -167,3 +167,10 @@ 166 -> Beholder BeholdTV 607 RDS [5ace:6073] 167 -> Beholder BeholdTV 609 RDS [5ace:6092] 168 -> Beholder BeholdTV 609 RDS [5ace:6093] +169 -> Compro VideoMate S350/S300 [185b:c900] +170 -> AverMedia AverTV Studio 505 [1461:a115] +171 -> Beholder BeholdTV X7 [5ace:7595] +172 -> RoverMedia TV Link Pro FM [19d1:0138] +173 -> Zolid Hybrid TV Tuner PCI [1131:2004] +174 -> Asus Europa Hybrid OEM [1043:4847] +175 -> Leadtek Winfast DTV1000S [107d:6655] diff --git a/Documentation/video4linux/CARDLIST.saa7164 b/Documentation/video4linux/CARDLIST.saa7164 new file mode 100644 index 000000000000..152bd7b781ca --- /dev/null +++ b/Documentation/video4linux/CARDLIST.saa7164 @@ -0,0 +1,9 @@ + 0 -> Unknown + 1 -> Generic Rev2 + 2 -> Generic Rev3 + 3 -> Hauppauge WinTV-HVR2250 [0070:8880,0070:8810] + 4 -> Hauppauge WinTV-HVR2200 [0070:8980] + 5 -> Hauppauge WinTV-HVR2200 [0070:8900] + 6 -> Hauppauge WinTV-HVR2200 [0070:8901] + 7 -> Hauppauge WinTV-HVR2250 [0070:8891,0070:8851] + 8 -> Hauppauge WinTV-HVR2250 [0070:88A1] diff --git a/Documentation/video4linux/CARDLIST.tuner b/Documentation/video4linux/CARDLIST.tuner index be67844074dd..e0d298fe8830 100644 --- a/Documentation/video4linux/CARDLIST.tuner +++ b/Documentation/video4linux/CARDLIST.tuner @@ -78,3 +78,6 @@ tuner=77 - TCL tuner MF02GIP-5N-E tuner=78 - Philips FMD1216MEX MK3 Hybrid Tuner tuner=79 - Philips PAL/SECAM multi (FM1216 MK5) tuner=80 - Philips FQ1216LME MK3 PAL/SECAM w/active loopthrough +tuner=81 - Partsnic (Daewoo) PTI-5NF05 +tuner=82 - Philips CU1216L +tuner=83 - NXP TDA18271 diff --git a/Documentation/video4linux/CQcam.txt b/Documentation/video4linux/CQcam.txt index 04986efb731c..d230878e473e 100644 --- a/Documentation/video4linux/CQcam.txt +++ b/Documentation/video4linux/CQcam.txt @@ -18,8 +18,8 @@ Table of Contents 1.0 Introduction - The file ../drivers/char/c-qcam.c is a device driver for the -Logitech (nee Connectix) parallel port interface color CCD camera. + The file ../../drivers/media/video/c-qcam.c is a device driver for +the Logitech (nee Connectix) parallel port interface color CCD camera. This is a fairly inexpensive device for capturing images. Logitech does not currently provide information for developers, but many people have engineered several solutions for non-Microsoft use of the Color diff --git a/Documentation/video4linux/gspca.txt b/Documentation/video4linux/gspca.txt index 573f95b58807..1800a62cf135 100644 --- a/Documentation/video4linux/gspca.txt +++ b/Documentation/video4linux/gspca.txt @@ -6,11 +6,13 @@ The modules are: xxxx vend:prod ---- -spca501 0000:0000 MystFromOri Unknow Camera +spca501 0000:0000 MystFromOri Unknown Camera +spca508 0130:0130 Clone Digital Webcam 11043 m5602 0402:5602 ALi Video Camera Controller spca501 040a:0002 Kodak DVC-325 spca500 040a:0300 Kodak EZ200 zc3xx 041e:041e Creative WebCam Live! +ov519 041e:4003 Video Blaster WebCam Go Plus spca500 041e:400a Creative PC-CAM 300 sunplus 041e:400b Creative PC-CAM 600 sunplus 041e:4012 PC-Cam350 @@ -37,6 +39,7 @@ ov519 041e:405f Creative Live! VISTA VF0330 ov519 041e:4060 Creative Live! VISTA VF0350 ov519 041e:4061 Creative Live! VISTA VF0400 ov519 041e:4064 Creative Live! VISTA VF0420 +ov519 041e:4067 Creative Live! Cam Video IM (VF0350) ov519 041e:4068 Creative Live! VISTA VF0470 spca561 0458:7004 Genius VideoCAM Express V2 sunplus 0458:7006 Genius Dsc 1.3 Smart @@ -68,12 +71,12 @@ zc3xx 046d:08a3 Logitech QC Chat zc3xx 046d:08a6 Logitech QCim zc3xx 046d:08a7 Logitech QuickCam Image zc3xx 046d:08a9 Logitech Notebook Deluxe -zc3xx 046d:08aa Labtec Webcam Notebook +zc3xx 046d:08aa Labtec Webcam Notebook zc3xx 046d:08ac Logitech QuickCam Cool zc3xx 046d:08ad Logitech QCCommunicate STX zc3xx 046d:08ae Logitech QuickCam for Notebooks zc3xx 046d:08af Logitech QuickCam Cool -zc3xx 046d:08b9 Logitech QC IM ??? +zc3xx 046d:08b9 Logitech QuickCam Express zc3xx 046d:08d7 Logitech QCam STX zc3xx 046d:08d9 Logitech QuickCam IM/Connect zc3xx 046d:08d8 Logitech Notebook Deluxe @@ -82,7 +85,7 @@ zc3xx 046d:08dd Logitech QuickCam for Notebooks spca500 046d:0900 Logitech Inc. ClickSmart 310 spca500 046d:0901 Logitech Inc. ClickSmart 510 sunplus 046d:0905 Logitech ClickSmart 820 -tv8532 046d:0920 QC Express +tv8532 046d:0920 Logitech QuickCam Express tv8532 046d:0921 Labtec Webcam spca561 046d:0928 Logitech QC Express Etch2 spca561 046d:0929 Labtec Webcam Elch2 @@ -91,7 +94,7 @@ spca561 046d:092b Labtec Webcam Plus spca561 046d:092c Logitech QC chat Elch2 spca561 046d:092d Logitech QC Elch2 spca561 046d:092e Logitech QC Elch2 -spca561 046d:092f Logitech QuickCam Express Plus +spca561 046d:092f Logitech QuickCam Express Plus sunplus 046d:0960 Logitech ClickSmart 420 sunplus 0471:0322 Philips DMVC1300K zc3xx 0471:0325 Philips SPC 200 NC @@ -140,6 +143,7 @@ spca500 04fc:7333 PalmPixDC85 sunplus 04fc:ffff Pure DigitalDakota spca501 0506:00df 3Com HomeConnect Lite sunplus 052b:1513 Megapix V4 +sunplus 052b:1803 MegaImage VI tv8532 0545:808b Veo Stingray tv8532 0545:8333 Veo Stingray sunplus 0546:3155 Polaroid PDC3070 @@ -165,13 +169,19 @@ sunplus 055f:c650 Mustek MDC5500Z zc3xx 055f:d003 Mustek WCam300A zc3xx 055f:d004 Mustek WCam300 AN conex 0572:0041 Creative Notebook cx11646 +ov519 05a9:0511 Video Blaster WebCam 3/WebCam Plus, D-Link USB Digital Video Camera +ov519 05a9:0518 Creative WebCam ov519 05a9:0519 OV519 Microphone ov519 05a9:0530 OmniVision +ov519 05a9:2800 OmniVision SuperCAM ov519 05a9:4519 Webcam Classic ov519 05a9:8519 OmniVision +ov519 05a9:a511 D-Link USB Digital Video Camera ov519 05a9:a518 D-Link DSB-C310 Webcam sunplus 05da:1018 Digital Dream Enigma 1.3 stk014 05e1:0893 Syntek DV4000 +gl860 05e3:0503 Genesys Logic PC Camera +gl860 05e3:f191 Genesys Logic PC Camera spca561 060b:a001 Maxell Compact Pc PM3 zc3xx 0698:2003 CTX M730V built in spca500 06bd:0404 Agfa CL20 @@ -182,8 +192,8 @@ ov534 06f8:3002 Hercules Blog Webcam ov534 06f8:3003 Hercules Dualpix HD Weblog sonixj 06f8:3004 Hercules Classic Silver sonixj 06f8:3008 Hercules Deluxe Optical Glass +pac7302 06f8:3009 Hercules Classic Link spca508 0733:0110 ViewQuest VQ110 -spca508 0130:0130 Clone Digital Webcam 11043 spca501 0733:0401 Intel Create and Share spca501 0733:0402 ViewQuest M318B spca505 0733:0430 Intel PC Camera Pro @@ -194,10 +204,12 @@ sunplus 0733:2221 Mercury Digital Pro 3.1p sunplus 0733:3261 Concord 3045 spca536a sunplus 0733:3281 Cyberpix S550V spca506 0734:043b 3DeMon USB Capture aka +ov519 0813:0002 Dual Mode USB Camera Plus spca500 084d:0003 D-Link DSC-350 spca500 08ca:0103 Aiptek PocketDV sunplus 08ca:0104 Aiptek PocketDVII 1.3 sunplus 08ca:0106 Aiptek Pocket DV3100+ +mr97310a 08ca:0110 Trust Spyc@m 100 mr97310a 08ca:0111 Aiptek PenCam VGA+ sunplus 08ca:2008 Aiptek Mini PenCam 2 M sunplus 08ca:2010 Aiptek PocketCam 3M @@ -218,7 +230,7 @@ pac207 093a:2460 Qtec Webcam 100 pac207 093a:2461 HP Webcam pac207 093a:2463 Philips SPC 220 NC pac207 093a:2464 Labtec Webcam 1200 -pac207 093a:2468 PAC207 +pac207 093a:2468 Webcam WB-1400T pac207 093a:2470 Genius GF112 pac207 093a:2471 Genius VideoCam ge111 pac207 093a:2472 Genius VideoCam ge110 @@ -226,17 +238,20 @@ pac207 093a:2474 Genius iLook 111 pac207 093a:2476 Genius e-Messenger 112 pac7311 093a:2600 PAC7311 Typhoon pac7311 093a:2601 Philips SPC 610 NC -pac7311 093a:2603 PAC7312 +pac7311 093a:2603 Philips SPC 500 NC pac7311 093a:2608 Trust WB-3300p pac7311 093a:260e Gigaware VGA PC Camera, Trust WB-3350p, SIGMA cam 2350 pac7311 093a:260f SnakeCam -pac7311 093a:2620 Apollo AC-905 -pac7311 093a:2621 PAC731x -pac7311 093a:2622 Genius Eye 312 -pac7311 093a:2624 PAC7302 -pac7311 093a:2626 Labtec 2200 -pac7311 093a:262a Webcam 300k -pac7311 093a:262c Philips SPC 230 NC +pac7302 093a:2620 Apollo AC-905 +pac7302 093a:2621 PAC731x +pac7302 093a:2622 Genius Eye 312 +pac7302 093a:2624 PAC7302 +pac7302 093a:2626 Labtec 2200 +pac7302 093a:2628 Genius iLook 300 +pac7302 093a:2629 Genious iSlim 300 +pac7302 093a:262a Webcam 300k +pac7302 093a:262c Philips SPC 230 NC +jeilinj 0979:0280 Sakar 57379 zc3xx 0ac8:0302 Z-star Vimicro zc0302 vc032x 0ac8:0321 Vimicro generic vc0321 vc032x 0ac8:0323 Vimicro Vc0323 @@ -244,11 +259,13 @@ vc032x 0ac8:0328 A4Tech PK-130MG zc3xx 0ac8:301b Z-Star zc301b zc3xx 0ac8:303b Vimicro 0x303b zc3xx 0ac8:305b Z-star Vimicro zc0305b -zc3xx 0ac8:307b Ldlc VC302+Ov7620 +zc3xx 0ac8:307b PC Camera (ZS0211) vc032x 0ac8:c001 Sony embedded vimicro vc032x 0ac8:c002 Sony embedded vimicro +vc032x 0ac8:c301 Samsung Q1 Ultra Premium spca508 0af9:0010 Hama USB Sightcam 100 spca508 0af9:0011 Hama USB Sightcam 100 +ov519 0b62:0059 iBOT2 Webcam sonixb 0c45:6001 Genius VideoCAM NB sonixb 0c45:6005 Microdia Sweex Mini Webcam sonixb 0c45:6007 Sonix sn9c101 + Tas5110D @@ -284,6 +301,7 @@ sonixj 0c45:613a Microdia Sonix PC Camera sonixj 0c45:613b Surfer SN-206 sonixj 0c45:613c Sonix Pccam168 sonixj 0c45:6143 Sonix Pccam168 +sonixj 0c45:6148 Digitus DA-70811/ZSMC USB PC Camera ZS211/Microdia sn9c20x 0c45:6240 PC Camera (SN9C201 + MT9M001) sn9c20x 0c45:6242 PC Camera (SN9C201 + MT9M111) sn9c20x 0c45:6248 PC Camera (SN9C201 + OV9655) @@ -307,8 +325,10 @@ sn9c20x 0c45:62b3 PC Camera (SN9C202 + OV9655) sn9c20x 0c45:62bb PC Camera (SN9C202 + OV7660) sn9c20x 0c45:62bc PC Camera (SN9C202 + HV7131R) sunplus 0d64:0303 Sunplus FashionCam DXG +ov519 0e96:c001 TRUST 380 USB2 SPACEC@M etoms 102c:6151 Qcam Sangha CIF etoms 102c:6251 Qcam xxxxxx VGA +ov519 1046:9967 W9967CF/W9968CF WebCam IC, Video Blaster WebCam Go zc3xx 10fd:0128 Typhoon Webshot II USB 300k 0x0128 spca561 10fd:7e50 FlyCam Usb 100 zc3xx 10fd:8050 Typhoon Webshot II USB 300k @@ -321,7 +341,12 @@ spca501 1776:501c Arowana 300K CMOS Camera t613 17a1:0128 TASCORP JPEG Webcam, NGS Cyclops vc032x 17ef:4802 Lenovo Vc0323+MI1310_SOC pac207 2001:f115 D-Link DSB-C120 +sq905c 2770:9050 sq905c +sq905c 2770:905c DualCamera +sq905 2770:9120 Argus Digital Camera DC1512 +sq905c 2770:913d sq905c spca500 2899:012c Toptro Industrial +ov519 8020:ef04 ov519 spca508 8086:0110 Intel Easy PC Camera spca500 8086:0630 Intel Pocket PC Camera spca506 99fa:8988 Grandtec V.cap diff --git a/Documentation/video4linux/sh_mobile_ceu_camera.txt b/Documentation/video4linux/sh_mobile_ceu_camera.txt new file mode 100644 index 000000000000..2ae16349a78d --- /dev/null +++ b/Documentation/video4linux/sh_mobile_ceu_camera.txt @@ -0,0 +1,157 @@ + Cropping and Scaling algorithm, used in the sh_mobile_ceu_camera driver + ======================================================================= + +Terminology +----------- + +sensor scales: horizontal and vertical scales, configured by the sensor driver +host scales: -"- host driver +combined scales: sensor_scale * host_scale + + +Generic scaling / cropping scheme +--------------------------------- + +-1-- +| +-2-- -\ +| --\ +| --\ ++-5-- -\ -- -3-- +| ---\ +| --- -4-- -\ +| -\ +| - -6-- +| +| - -6'- +| -/ +| --- -4'- -/ +| ---/ ++-5'- -/ +| -- -3'- +| --/ +| --/ +-2'- -/ +| +| +-1'- + +Produced by user requests: + +S_CROP(left / top = (5) - (1), width / height = (5') - (5)) +S_FMT(width / height = (6') - (6)) + +Here: + +(1) to (1') - whole max width or height +(1) to (2) - sensor cropped left or top +(2) to (2') - sensor cropped width or height +(3) to (3') - sensor scale +(3) to (4) - CEU cropped left or top +(4) to (4') - CEU cropped width or height +(5) to (5') - reverse sensor scale applied to CEU cropped width or height +(2) to (5) - reverse sensor scale applied to CEU cropped left or top +(6) to (6') - CEU scale - user window + + +S_FMT +----- + +Do not touch input rectangle - it is already optimal. + +1. Calculate current sensor scales: + + scale_s = ((3') - (3)) / ((2') - (2)) + +2. Calculate "effective" input crop (sensor subwindow) - CEU crop scaled back at +current sensor scales onto input window - this is user S_CROP: + + width_u = (5') - (5) = ((4') - (4)) * scale_s + +3. Calculate new combined scales from "effective" input window to requested user +window: + + scale_comb = width_u / ((6') - (6)) + +4. Calculate sensor output window by applying combined scales to real input +window: + + width_s_out = ((2') - (2)) / scale_comb + +5. Apply iterative sensor S_FMT for sensor output window. + + subdev->video_ops->s_fmt(.width = width_s_out) + +6. Retrieve sensor output window (g_fmt) + +7. Calculate new sensor scales: + + scale_s_new = ((3')_new - (3)_new) / ((2') - (2)) + +8. Calculate new CEU crop - apply sensor scales to previously calculated +"effective" crop: + + width_ceu = (4')_new - (4)_new = width_u / scale_s_new + left_ceu = (4)_new - (3)_new = ((5) - (2)) / scale_s_new + +9. Use CEU cropping to crop to the new window: + + ceu_crop(.width = width_ceu, .left = left_ceu) + +10. Use CEU scaling to scale to the requested user window: + + scale_ceu = width_ceu / width + + +S_CROP +------ + +If old scale applied to new crop is invalid produce nearest new scale possible + +1. Calculate current combined scales. + + scale_comb = (((4') - (4)) / ((6') - (6))) * (((2') - (2)) / ((3') - (3))) + +2. Apply iterative sensor S_CROP for new input window. + +3. If old combined scales applied to new crop produce an impossible user window, +adjust scales to produce nearest possible window. + + width_u_out = ((5') - (5)) / scale_comb + + if (width_u_out > max) + scale_comb = ((5') - (5)) / max; + else if (width_u_out < min) + scale_comb = ((5') - (5)) / min; + +4. Issue G_CROP to retrieve actual input window. + +5. Using actual input window and calculated combined scales calculate sensor +target output window. + + width_s_out = ((3') - (3)) = ((2') - (2)) / scale_comb + +6. Apply iterative S_FMT for new sensor target output window. + +7. Issue G_FMT to retrieve the actual sensor output window. + +8. Calculate sensor scales. + + scale_s = ((3') - (3)) / ((2') - (2)) + +9. Calculate sensor output subwindow to be cropped on CEU by applying sensor +scales to the requested window. + + width_ceu = ((5') - (5)) / scale_s + +10. Use CEU cropping for above calculated window. + +11. Calculate CEU scales from sensor scales from results of (10) and user window +from (3) + + scale_ceu = calc_scale(((5') - (5)), &width_u_out) + +12. Apply CEU scales. + +-- +Author: Guennadi Liakhovetski <g.liakhovetski@gmx.de> diff --git a/Documentation/video4linux/si4713.txt b/Documentation/video4linux/si4713.txt new file mode 100644 index 000000000000..2e7392a4fee1 --- /dev/null +++ b/Documentation/video4linux/si4713.txt @@ -0,0 +1,176 @@ +Driver for I2C radios for the Silicon Labs Si4713 FM Radio Transmitters + +Copyright (c) 2009 Nokia Corporation +Contact: Eduardo Valentin <eduardo.valentin@nokia.com> + + +Information about the Device +============================ +This chip is a Silicon Labs product. It is a I2C device, currently on 0x63 address. +Basically, it has transmission and signal noise level measurement features. + +The Si4713 integrates transmit functions for FM broadcast stereo transmission. +The chip also allows integrated receive power scanning to identify low signal +power FM channels. + +The chip is programmed using commands and responses. There are also several +properties which can change the behavior of this chip. + +Users must comply with local regulations on radio frequency (RF) transmission. + +Device driver description +========================= +There are two modules to handle this device. One is a I2C device driver +and the other is a platform driver. + +The I2C device driver exports a v4l2-subdev interface to the kernel. +All properties can also be accessed by v4l2 extended controls interface, by +using the v4l2-subdev calls (g_ext_ctrls, s_ext_ctrls). + +The platform device driver exports a v4l2 radio device interface to user land. +So, it uses the I2C device driver as a sub device in order to send the user +commands to the actual device. Basically it is a wrapper to the I2C device driver. + +Applications can use v4l2 radio API to specify frequency of operation, mute state, +etc. But mostly of its properties will be present in the extended controls. + +When the v4l2 mute property is set to 1 (true), the driver will turn the chip off. + +Properties description +====================== + +The properties can be accessed using v4l2 extended controls. +Here is an output from v4l2-ctl util: +/ # v4l2-ctl -d /dev/radio0 --all -L +Driver Info: + Driver name : radio-si4713 + Card type : Silicon Labs Si4713 Modulator + Bus info : + Driver version: 0 + Capabilities : 0x00080800 + RDS Output + Modulator +Audio output: 0 (FM Modulator Audio Out) +Frequency: 1408000 (88.000000 MHz) +Video Standard = 0x00000000 +Modulator: + Name : FM Modulator + Capabilities : 62.5 Hz stereo rds + Frequency range : 76.0 MHz - 108.0 MHz + Subchannel modulation: stereo+rds + +User Controls + + mute (bool) : default=1 value=0 + +FM Radio Modulator Controls + + rds_signal_deviation (int) : min=0 max=90000 step=10 default=200 value=200 flags=slider + rds_program_id (int) : min=0 max=65535 step=1 default=0 value=0 + rds_program_type (int) : min=0 max=31 step=1 default=0 value=0 + rds_ps_name (str) : min=0 max=96 step=8 value='si4713 ' + rds_radio_text (str) : min=0 max=384 step=32 value='' + audio_limiter_feature_enabled (bool) : default=1 value=1 + audio_limiter_release_time (int) : min=250 max=102390 step=50 default=5010 value=5010 flags=slider + audio_limiter_deviation (int) : min=0 max=90000 step=10 default=66250 value=66250 flags=slider +audio_compression_feature_enabl (bool) : default=1 value=1 + audio_compression_gain (int) : min=0 max=20 step=1 default=15 value=15 flags=slider + audio_compression_threshold (int) : min=-40 max=0 step=1 default=-40 value=-40 flags=slider + audio_compression_attack_time (int) : min=0 max=5000 step=500 default=0 value=0 flags=slider + audio_compression_release_time (int) : min=100000 max=1000000 step=100000 default=1000000 value=1000000 flags=slider + pilot_tone_feature_enabled (bool) : default=1 value=1 + pilot_tone_deviation (int) : min=0 max=90000 step=10 default=6750 value=6750 flags=slider + pilot_tone_frequency (int) : min=0 max=19000 step=1 default=19000 value=19000 flags=slider + pre_emphasis_settings (menu) : min=0 max=2 default=1 value=1 + tune_power_level (int) : min=0 max=120 step=1 default=88 value=88 flags=slider + tune_antenna_capacitor (int) : min=0 max=191 step=1 default=0 value=110 flags=slider +/ # + +Here is a summary of them: + +* Pilot is an audible tone sent by the device. + +pilot_frequency - Configures the frequency of the stereo pilot tone. +pilot_deviation - Configures pilot tone frequency deviation level. +pilot_enabled - Enables or disables the pilot tone feature. + +* The si4713 device is capable of applying audio compression to the transmitted signal. + +acomp_enabled - Enables or disables the audio dynamic range control feature. +acomp_gain - Sets the gain for audio dynamic range control. +acomp_threshold - Sets the threshold level for audio dynamic range control. +acomp_attack_time - Sets the attack time for audio dynamic range control. +acomp_release_time - Sets the release time for audio dynamic range control. + +* Limiter setups audio deviation limiter feature. Once a over deviation occurs, +it is possible to adjust the front-end gain of the audio input and always +prevent over deviation. + +limiter_enabled - Enables or disables the limiter feature. +limiter_deviation - Configures audio frequency deviation level. +limiter_release_time - Sets the limiter release time. + +* Tuning power + +power_level - Sets the output power level for signal transmission. +antenna_capacitor - This selects the value of antenna tuning capacitor manually +or automatically if set to zero. + +* RDS related + +rds_ps_name - Sets the RDS ps name field for transmission. +rds_radio_text - Sets the RDS radio text for transmission. +rds_pi - Sets the RDS PI field for transmission. +rds_pty - Sets the RDS PTY field for transmission. + +* Region related + +preemphasis - sets the preemphasis to be applied for transmission. + +RNL +=== + +This device also has an interface to measure received noise level. To do that, you should +ioctl the device node. Here is an code of example: + +int main (int argc, char *argv[]) +{ + struct si4713_rnl rnl; + int fd = open("/dev/radio0", O_RDWR); + int rval; + + if (argc < 2) + return -EINVAL; + + if (fd < 0) + return fd; + + sscanf(argv[1], "%d", &rnl.frequency); + + rval = ioctl(fd, SI4713_IOC_MEASURE_RNL, &rnl); + if (rval < 0) + return rval; + + printf("received noise level: %d\n", rnl.rnl); + + close(fd); +} + +The struct si4713_rnl and SI4713_IOC_MEASURE_RNL are defined under +include/media/si4713.h. + +Stereo/Mono and RDS subchannels +=============================== + +The device can also be configured using the available sub channels for +transmission. To do that use S/G_MODULATOR ioctl and configure txsubchans properly. +Refer to the V4L2 API specification for proper use of this ioctl. + +Testing +======= +Testing is usually done with v4l2-ctl utility for managing FM tuner cards. +The tool can be found in v4l-dvb repository under v4l2-apps/util directory. + +Example for setting rds ps name: +# v4l2-ctl -d /dev/radio0 --set-ctrl=rds_ps_name="Dummy" + diff --git a/Documentation/video4linux/soc-camera.txt b/Documentation/video4linux/soc-camera.txt index 178ef3c5e579..3f87c7da4ca2 100644 --- a/Documentation/video4linux/soc-camera.txt +++ b/Documentation/video4linux/soc-camera.txt @@ -116,5 +116,45 @@ functionality. struct soc_camera_device also links to an array of struct soc_camera_data_format, listing pixel formats, supported by the camera. +VIDIOC_S_CROP and VIDIOC_S_FMT behaviour +---------------------------------------- + +Above user ioctls modify image geometry as follows: + +VIDIOC_S_CROP: sets location and sizes of the sensor window. Unit is one sensor +pixel. Changing sensor window sizes preserves any scaling factors, therefore +user window sizes change as well. + +VIDIOC_S_FMT: sets user window. Should preserve previously set sensor window as +much as possible by modifying scaling factors. If the sensor window cannot be +preserved precisely, it may be changed too. + +In soc-camera there are two locations, where scaling and cropping can taks +place: in the camera driver and in the host driver. User ioctls are first passed +to the host driver, which then generally passes them down to the camera driver. +It is more efficient to perform scaling and cropping in the camera driver to +save camera bus bandwidth and maximise the framerate. However, if the camera +driver failed to set the required parameters with sufficient precision, the host +driver may decide to also use its own scaling and cropping to fulfill the user's +request. + +Camera drivers are interfaced to the soc-camera core and to host drivers over +the v4l2-subdev API, which is completely functional, it doesn't pass any data. +Therefore all camera drivers shall reply to .g_fmt() requests with their current +output geometry. This is necessary to correctly configure the camera bus. +.s_fmt() and .try_fmt() have to be implemented too. Sensor window and scaling +factors have to be maintained by camera drivers internally. According to the +V4L2 API all capture drivers must support the VIDIOC_CROPCAP ioctl, hence we +rely on camera drivers implementing .cropcap(). If the camera driver does not +support cropping, it may choose to not implement .s_crop(), but to enable +cropping support by the camera host driver at least the .g_crop method must be +implemented. + +User window geometry is kept in .user_width and .user_height fields in struct +soc_camera_device and used by the soc-camera core and host drivers. The core +updates these fields upon successful completion of a .s_fmt() call, but if these +fields change elsewhere, e.g., during .s_crop() processing, the host driver is +responsible for updating them. + -- Author: Guennadi Liakhovetski <g.liakhovetski@gmx.de> diff --git a/Documentation/video4linux/v4l2-framework.txt b/Documentation/video4linux/v4l2-framework.txt index ba4706afc5fb..74d677c8b036 100644 --- a/Documentation/video4linux/v4l2-framework.txt +++ b/Documentation/video4linux/v4l2-framework.txt @@ -370,19 +370,20 @@ from the remove() callback ensures that this is always done correctly. The bridge driver also has some helper functions it can use: struct v4l2_subdev *sd = v4l2_i2c_new_subdev(v4l2_dev, adapter, - "module_foo", "chipid", 0x36); + "module_foo", "chipid", 0x36, NULL); This loads the given module (can be NULL if no module needs to be loaded) and calls i2c_new_device() with the given i2c_adapter and chip/address arguments. If all goes well, then it registers the subdev with the v4l2_device. -You can also use v4l2_i2c_new_probed_subdev() which is very similar to -v4l2_i2c_new_subdev(), except that it has an array of possible I2C addresses -that it should probe. Internally it calls i2c_new_probed_device(). +You can also use the last argument of v4l2_i2c_new_subdev() to pass an array +of possible I2C addresses that it should probe. These probe addresses are +only used if the previous argument is 0. A non-zero argument means that you +know the exact i2c address so in that case no probing will take place. Both functions return NULL if something went wrong. -Note that the chipid you pass to v4l2_i2c_new_(probed_)subdev() is usually +Note that the chipid you pass to v4l2_i2c_new_subdev() is usually the same as the module name. It allows you to specify a chip variant, e.g. "saa7114" or "saa7115". In general though the i2c driver autodetects this. The use of chipid is something that needs to be looked at more closely at a @@ -410,11 +411,6 @@ the irq and platform_data arguments after the subdev was setup. The older v4l2_i2c_new_(probed_)subdev functions will call s_config as well, but with irq set to 0 and platform_data set to NULL. -Note that in the next kernel release the functions v4l2_i2c_new_subdev, -v4l2_i2c_new_probed_subdev and v4l2_i2c_new_probed_subdev_addr will all be -replaced by a single v4l2_i2c_new_subdev that is identical to -v4l2_i2c_new_subdev_cfg but without the irq and platform_data arguments. - struct video_device ------------------- @@ -490,31 +486,35 @@ VFL_TYPE_RADIO: radioX for radio tuners VFL_TYPE_VTX: vtxX for teletext devices (deprecated, don't use) The last argument gives you a certain amount of control over the device -kernel number used (i.e. the X in videoX). Normally you will pass -1 to -let the v4l2 framework pick the first free number. But if a driver creates -many devices, then it can be useful to have different video devices in -separate ranges. For example, video capture devices start at 0, video -output devices start at 16. - -So you can use the last argument to specify a minimum kernel number and -the v4l2 framework will try to pick the first free number that is equal +device node number used (i.e. the X in videoX). Normally you will pass -1 +to let the v4l2 framework pick the first free number. But sometimes users +want to select a specific node number. It is common that drivers allow +the user to select a specific device node number through a driver module +option. That number is then passed to this function and video_register_device +will attempt to select that device node number. If that number was already +in use, then the next free device node number will be selected and it +will send a warning to the kernel log. + +Another use-case is if a driver creates many devices. In that case it can +be useful to place different video devices in separate ranges. For example, +video capture devices start at 0, video output devices start at 16. +So you can use the last argument to specify a minimum device node number +and the v4l2 framework will try to pick the first free number that is equal or higher to what you passed. If that fails, then it will just pick the first free number. +Since in this case you do not care about a warning about not being able +to select the specified device node number, you can call the function +video_register_device_no_warn() instead. + Whenever a device node is created some attributes are also created for you. If you look in /sys/class/video4linux you see the devices. Go into e.g. video0 and you will see 'name' and 'index' attributes. The 'name' attribute -is the 'name' field of the video_device struct. The 'index' attribute is -a device node index that can be assigned by the driver, or that is calculated -for you. +is the 'name' field of the video_device struct. -If you call video_register_device(), then the index is just increased by -1 for each device node you register. The first video device node you register -always starts off with 0. - -Alternatively you can call video_register_device_index() which is identical -to video_register_device(), but with an extra index argument. Here you can -pass a specific index value (between 0 and 31) that should be used. +The 'index' attribute is the index of the device node: for each call to +video_register_device() the index is just increased by 1. The first video +device node you register always starts with index 0. Users can setup udev rules that utilize the index attribute to make fancy device names (e.g. 'mpegX' for MPEG video capture device nodes). @@ -523,9 +523,8 @@ After the device was successfully registered, then you can use these fields: - vfl_type: the device type passed to video_register_device. - minor: the assigned device minor number. -- num: the device kernel number (i.e. the X in videoX). -- index: the device index number (calculated or set explicitly using - video_register_device_index). +- num: the device node number (i.e. the X in videoX). +- index: the device index number. If the registration failed, then you need to call video_device_release() to free the allocated video_device struct, or free your own struct if the @@ -562,6 +561,8 @@ video_device helper functions There are a few useful helper functions: +- file/video_device private data + You can set/get driver private data in the video_device struct using: void *video_get_drvdata(struct video_device *vdev); @@ -576,8 +577,7 @@ struct video_device *video_devdata(struct file *file); returns the video_device belonging to the file struct. -The final helper function combines video_get_drvdata with -video_devdata: +The video_drvdata function combines video_get_drvdata with video_devdata: void *video_drvdata(struct file *file); @@ -585,6 +585,17 @@ You can go from a video_device struct to the v4l2_device struct using: struct v4l2_device *v4l2_dev = vdev->v4l2_dev; +- Device node name + +The video_device node kernel name can be retrieved using + +const char *video_device_node_name(struct video_device *vdev); + +The name is used as a hint by userspace tools such as udev. The function +should be used where possible instead of accessing the video_device::num and +video_device::minor fields. + + video buffer helper functions ----------------------------- diff --git a/Documentation/video4linux/v4lgrab.c b/Documentation/video4linux/v4lgrab.c index 05769cff1009..c8ded175796e 100644 --- a/Documentation/video4linux/v4lgrab.c +++ b/Documentation/video4linux/v4lgrab.c @@ -89,7 +89,7 @@ } \ } -int get_brightness_adj(unsigned char *image, long size, int *brightness) { +static int get_brightness_adj(unsigned char *image, long size, int *brightness) { long i, tot = 0; for (i=0;i<size*3;i++) tot += image[i]; diff --git a/Documentation/video4linux/zr364xx.txt b/Documentation/video4linux/zr364xx.txt index 7f3d1955d214..d98e4d302977 100644 --- a/Documentation/video4linux/zr364xx.txt +++ b/Documentation/video4linux/zr364xx.txt @@ -66,3 +66,4 @@ Vendor Product Distributor Model 0x0a17 0x004e Pentax Optio 50 0x041e 0x405d Creative DiVi CAM 516 0x08ca 0x2102 Aiptek DV T300 +0x06d6 0x003d Trust Powerc@m 910Z diff --git a/Documentation/vm/.gitignore b/Documentation/vm/.gitignore index 33e8a023df02..09b164a5700f 100644 --- a/Documentation/vm/.gitignore +++ b/Documentation/vm/.gitignore @@ -1 +1,2 @@ +page-types slabinfo diff --git a/Documentation/vm/00-INDEX b/Documentation/vm/00-INDEX index 2f77ced35df7..e57d6a9dd32b 100644 --- a/Documentation/vm/00-INDEX +++ b/Documentation/vm/00-INDEX @@ -6,6 +6,8 @@ balance - various information on memory balancing. hugetlbpage.txt - a brief summary of hugetlbpage support in the Linux kernel. +ksm.txt + - how to use the Kernel Samepage Merging feature. locking - info on how locking and synchronization is done in the Linux vm code. numa @@ -20,3 +22,5 @@ slabinfo.c - source code for a tool to get reports about slabs. slub.txt - a short users guide for SLUB. +map_hugetlb.c + - an example program that uses the MAP_HUGETLB mmap flag. diff --git a/Documentation/vm/hugetlbpage.txt b/Documentation/vm/hugetlbpage.txt index ea8714fcc3ad..bc31636973e3 100644 --- a/Documentation/vm/hugetlbpage.txt +++ b/Documentation/vm/hugetlbpage.txt @@ -11,23 +11,21 @@ This optimization is more critical now as bigger and bigger physical memories (several GBs) are more readily available. Users can use the huge page support in Linux kernel by either using the mmap -system call or standard SYSv shared memory system calls (shmget, shmat). +system call or standard SYSV shared memory system calls (shmget, shmat). First the Linux kernel needs to be built with the CONFIG_HUGETLBFS (present under "File systems") and CONFIG_HUGETLB_PAGE (selected automatically when CONFIG_HUGETLBFS is selected) configuration options. -The kernel built with hugepage support should show the number of configured -hugepages in the system by running the "cat /proc/meminfo" command. +The /proc/meminfo file provides information about the total number of +persistent hugetlb pages in the kernel's huge page pool. It also displays +information about the number of free, reserved and surplus huge pages and the +default huge page size. The huge page size is needed for generating the +proper alignment and size of the arguments to system calls that map huge page +regions. -/proc/meminfo also provides information about the total number of hugetlb -pages configured in the kernel. It also displays information about the -number of free hugetlb pages at any time. It also displays information about -the configured hugepage size - this is needed for generating the proper -alignment and size of the arguments to the above system calls. - -The output of "cat /proc/meminfo" will have lines like: +The output of "cat /proc/meminfo" will include lines like: ..... HugePages_Total: vvv @@ -37,88 +35,231 @@ HugePages_Surp: yyy Hugepagesize: zzz kB where: -HugePages_Total is the size of the pool of hugepages. -HugePages_Free is the number of hugepages in the pool that are not yet -allocated. -HugePages_Rsvd is short for "reserved," and is the number of hugepages -for which a commitment to allocate from the pool has been made, but no -allocation has yet been made. It's vaguely analogous to overcommit. -HugePages_Surp is short for "surplus," and is the number of hugepages in -the pool above the value in /proc/sys/vm/nr_hugepages. The maximum -number of surplus hugepages is controlled by -/proc/sys/vm/nr_overcommit_hugepages. +HugePages_Total is the size of the pool of huge pages. +HugePages_Free is the number of huge pages in the pool that are not yet + allocated. +HugePages_Rsvd is short for "reserved," and is the number of huge pages for + which a commitment to allocate from the pool has been made, + but no allocation has yet been made. Reserved huge pages + guarantee that an application will be able to allocate a + huge page from the pool of huge pages at fault time. +HugePages_Surp is short for "surplus," and is the number of huge pages in + the pool above the value in /proc/sys/vm/nr_hugepages. The + maximum number of surplus huge pages is controlled by + /proc/sys/vm/nr_overcommit_hugepages. /proc/filesystems should also show a filesystem of type "hugetlbfs" configured in the kernel. -/proc/sys/vm/nr_hugepages indicates the current number of configured hugetlb -pages in the kernel. Super user can dynamically request more (or free some -pre-configured) hugepages. -The allocation (or deallocation) of hugetlb pages is possible only if there are -enough physically contiguous free pages in system (freeing of hugepages is -possible only if there are enough hugetlb pages free that can be transferred -back to regular memory pool). - -Pages that are used as hugetlb pages are reserved inside the kernel and cannot -be used for other purposes. - -Once the kernel with Hugetlb page support is built and running, a user can -use either the mmap system call or shared memory system calls to start using -the huge pages. It is required that the system administrator preallocate -enough memory for huge page purposes. - -Use the following command to dynamically allocate/deallocate hugepages: +/proc/sys/vm/nr_hugepages indicates the current number of "persistent" huge +pages in the kernel's huge page pool. "Persistent" huge pages will be +returned to the huge page pool when freed by a task. A user with root +privileges can dynamically allocate more or free some persistent huge pages +by increasing or decreasing the value of 'nr_hugepages'. + +Pages that are used as huge pages are reserved inside the kernel and cannot +be used for other purposes. Huge pages cannot be swapped out under +memory pressure. + +Once a number of huge pages have been pre-allocated to the kernel huge page +pool, a user with appropriate privilege can use either the mmap system call +or shared memory system calls to use the huge pages. See the discussion of +Using Huge Pages, below. + +The administrator can allocate persistent huge pages on the kernel boot +command line by specifying the "hugepages=N" parameter, where 'N' = the +number of huge pages requested. This is the most reliable method of +allocating huge pages as memory has not yet become fragmented. + +Some platforms support multiple huge page sizes. To allocate huge pages +of a specific size, one must preceed the huge pages boot command parameters +with a huge page size selection parameter "hugepagesz=<size>". <size> must +be specified in bytes with optional scale suffix [kKmMgG]. The default huge +page size may be selected with the "default_hugepagesz=<size>" boot parameter. + +When multiple huge page sizes are supported, /proc/sys/vm/nr_hugepages +indicates the current number of pre-allocated huge pages of the default size. +Thus, one can use the following command to dynamically allocate/deallocate +default sized persistent huge pages: echo 20 > /proc/sys/vm/nr_hugepages -This command will try to configure 20 hugepages in the system. The success -or failure of allocation depends on the amount of physically contiguous -memory that is preset in system at this time. System administrators may want -to put this command in one of the local rc init files. This will enable the -kernel to request huge pages early in the boot process (when the possibility -of getting physical contiguous pages is still very high). In either -case, administrators will want to verify the number of hugepages actually -allocated by checking the sysctl or meminfo. - -/proc/sys/vm/nr_overcommit_hugepages indicates how large the pool of -hugepages can grow, if more hugepages than /proc/sys/vm/nr_hugepages are -requested by applications. echo'ing any non-zero value into this file -indicates that the hugetlb subsystem is allowed to try to obtain -hugepages from the buddy allocator, if the normal pool is exhausted. As -these surplus hugepages go out of use, they are freed back to the buddy -allocator. - -Caveat: Shrinking the pool via nr_hugepages such that it becomes less -than the number of hugepages in use will convert the balance to surplus -huge pages even if it would exceed the overcommit value. As long as -this condition holds, however, no more surplus huge pages will be -allowed on the system until one of the two sysctls are increased -sufficiently, or the surplus huge pages go out of use and are freed. - -With support for multiple hugepage pools at run-time available, much of -the hugepage userspace interface has been duplicated in sysfs. The above -information applies to the default hugepage size (which will be -controlled by the proc interfaces for backwards compatibility). The root -hugepage control directory is +This command will try to adjust the number of default sized huge pages in the +huge page pool to 20, allocating or freeing huge pages, as required. + +On a NUMA platform, the kernel will attempt to distribute the huge page pool +over all the set of allowed nodes specified by the NUMA memory policy of the +task that modifies nr_hugepages. The default for the allowed nodes--when the +task has default memory policy--is all on-line nodes with memory. Allowed +nodes with insufficient available, contiguous memory for a huge page will be +silently skipped when allocating persistent huge pages. See the discussion +below of the interaction of task memory policy, cpusets and per node attributes +with the allocation and freeing of persistent huge pages. + +The success or failure of huge page allocation depends on the amount of +physically contiguous memory that is present in system at the time of the +allocation attempt. If the kernel is unable to allocate huge pages from +some nodes in a NUMA system, it will attempt to make up the difference by +allocating extra pages on other nodes with sufficient available contiguous +memory, if any. + +System administrators may want to put this command in one of the local rc +init files. This will enable the kernel to allocate huge pages early in +the boot process when the possibility of getting physical contiguous pages +is still very high. Administrators can verify the number of huge pages +actually allocated by checking the sysctl or meminfo. To check the per node +distribution of huge pages in a NUMA system, use: + + cat /sys/devices/system/node/node*/meminfo | fgrep Huge + +/proc/sys/vm/nr_overcommit_hugepages specifies how large the pool of +huge pages can grow, if more huge pages than /proc/sys/vm/nr_hugepages are +requested by applications. Writing any non-zero value into this file +indicates that the hugetlb subsystem is allowed to try to obtain that +number of "surplus" huge pages from the kernel's normal page pool, when the +persistent huge page pool is exhausted. As these surplus huge pages become +unused, they are freed back to the kernel's normal page pool. + +When increasing the huge page pool size via nr_hugepages, any existing surplus +pages will first be promoted to persistent huge pages. Then, additional +huge pages will be allocated, if necessary and if possible, to fulfill +the new persistent huge page pool size. + +The administrator may shrink the pool of persistent huge pages for +the default huge page size by setting the nr_hugepages sysctl to a +smaller value. The kernel will attempt to balance the freeing of huge pages +across all nodes in the memory policy of the task modifying nr_hugepages. +Any free huge pages on the selected nodes will be freed back to the kernel's +normal page pool. + +Caveat: Shrinking the persistent huge page pool via nr_hugepages such that +it becomes less than the number of huge pages in use will convert the balance +of the in-use huge pages to surplus huge pages. This will occur even if +the number of surplus pages it would exceed the overcommit value. As long as +this condition holds--that is, until nr_hugepages+nr_overcommit_hugepages is +increased sufficiently, or the surplus huge pages go out of use and are freed-- +no more surplus huge pages will be allowed to be allocated. + +With support for multiple huge page pools at run-time available, much of +the huge page userspace interface in /proc/sys/vm has been duplicated in sysfs. +The /proc interfaces discussed above have been retained for backwards +compatibility. The root huge page control directory in sysfs is: /sys/kernel/mm/hugepages -For each hugepage size supported by the running kernel, a subdirectory -will exist, of the form +For each huge page size supported by the running kernel, a subdirectory +will exist, of the form: hugepages-${size}kB Inside each of these directories, the same set of files will exist: nr_hugepages + nr_hugepages_mempolicy nr_overcommit_hugepages free_hugepages resv_hugepages surplus_hugepages -which function as described above for the default hugepage-sized case. +which function as described above for the default huge page-sized case. + + +Interaction of Task Memory Policy with Huge Page Allocation/Freeing + +Whether huge pages are allocated and freed via the /proc interface or +the /sysfs interface using the nr_hugepages_mempolicy attribute, the NUMA +nodes from which huge pages are allocated or freed are controlled by the +NUMA memory policy of the task that modifies the nr_hugepages_mempolicy +sysctl or attribute. When the nr_hugepages attribute is used, mempolicy +is ignored. + +The recommended method to allocate or free huge pages to/from the kernel +huge page pool, using the nr_hugepages example above, is: + + numactl --interleave <node-list> echo 20 \ + >/proc/sys/vm/nr_hugepages_mempolicy + +or, more succinctly: + + numactl -m <node-list> echo 20 >/proc/sys/vm/nr_hugepages_mempolicy + +This will allocate or free abs(20 - nr_hugepages) to or from the nodes +specified in <node-list>, depending on whether number of persistent huge pages +is initially less than or greater than 20, respectively. No huge pages will be +allocated nor freed on any node not included in the specified <node-list>. + +When adjusting the persistent hugepage count via nr_hugepages_mempolicy, any +memory policy mode--bind, preferred, local or interleave--may be used. The +resulting effect on persistent huge page allocation is as follows: + +1) Regardless of mempolicy mode [see Documentation/vm/numa_memory_policy.txt], + persistent huge pages will be distributed across the node or nodes + specified in the mempolicy as if "interleave" had been specified. + However, if a node in the policy does not contain sufficient contiguous + memory for a huge page, the allocation will not "fallback" to the nearest + neighbor node with sufficient contiguous memory. To do this would cause + undesirable imbalance in the distribution of the huge page pool, or + possibly, allocation of persistent huge pages on nodes not allowed by + the task's memory policy. + +2) One or more nodes may be specified with the bind or interleave policy. + If more than one node is specified with the preferred policy, only the + lowest numeric id will be used. Local policy will select the node where + the task is running at the time the nodes_allowed mask is constructed. + For local policy to be deterministic, the task must be bound to a cpu or + cpus in a single node. Otherwise, the task could be migrated to some + other node at any time after launch and the resulting node will be + indeterminate. Thus, local policy is not very useful for this purpose. + Any of the other mempolicy modes may be used to specify a single node. + +3) The nodes allowed mask will be derived from any non-default task mempolicy, + whether this policy was set explicitly by the task itself or one of its + ancestors, such as numactl. This means that if the task is invoked from a + shell with non-default policy, that policy will be used. One can specify a + node list of "all" with numactl --interleave or --membind [-m] to achieve + interleaving over all nodes in the system or cpuset. + +4) Any task mempolicy specifed--e.g., using numactl--will be constrained by + the resource limits of any cpuset in which the task runs. Thus, there will + be no way for a task with non-default policy running in a cpuset with a + subset of the system nodes to allocate huge pages outside the cpuset + without first moving to a cpuset that contains all of the desired nodes. + +5) Boot-time huge page allocation attempts to distribute the requested number + of huge pages over all on-lines nodes with memory. + +Per Node Hugepages Attributes + +A subset of the contents of the root huge page control directory in sysfs, +described above, will be replicated under each the system device of each +NUMA node with memory in: + + /sys/devices/system/node/node[0-9]*/hugepages/ + +Under this directory, the subdirectory for each supported huge page size +contains the following attribute files: + + nr_hugepages + free_hugepages + surplus_hugepages + +The free_' and surplus_' attribute files are read-only. They return the number +of free and surplus [overcommitted] huge pages, respectively, on the parent +node. + +The nr_hugepages attribute returns the total number of huge pages on the +specified node. When this attribute is written, the number of persistent huge +pages on the parent node will be adjusted to the specified value, if sufficient +resources exist, regardless of the task's mempolicy or cpuset constraints. + +Note that the number of overcommit and reserve pages remain global quantities, +as we don't know until fault time, when the faulting task's mempolicy is +applied, from which node the huge page allocation will be attempted. + -If the user applications are going to request hugepages using mmap system +Using Huge Pages + +If the user applications are going to request huge pages using mmap system call, then it is required that system administrator mount a file system of type hugetlbfs: @@ -127,7 +268,7 @@ type hugetlbfs: none /mnt/huge This command mounts a (pseudo) filesystem of type hugetlbfs on the directory -/mnt/huge. Any files created on /mnt/huge uses hugepages. The uid and gid +/mnt/huge. Any files created on /mnt/huge uses huge pages. The uid and gid options sets the owner and group of the root of the file system. By default the uid and gid of the current process are taken. The mode option sets the mode of root of file system to value & 0777. This value is given in octal. @@ -146,26 +287,30 @@ Regular chown, chgrp, and chmod commands (with right permissions) could be used to change the file attributes on hugetlbfs. Also, it is important to note that no such mount command is required if the -applications are going to use only shmat/shmget system calls. Users who -wish to use hugetlb page via shared memory segment should be a member of -a supplementary group and system admin needs to configure that gid into -/proc/sys/vm/hugetlb_shm_group. It is possible for same or different -applications to use any combination of mmaps and shm* calls, though the -mount of filesystem will be required for using mmap calls. +applications are going to use only shmat/shmget system calls or mmap with +MAP_HUGETLB. Users who wish to use hugetlb page via shared memory segment +should be a member of a supplementary group and system admin needs to +configure that gid into /proc/sys/vm/hugetlb_shm_group. It is possible for +same or different applications to use any combination of mmaps and shm* +calls, though the mount of filesystem will be required for using mmap calls +without MAP_HUGETLB. For an example of how to use mmap with MAP_HUGETLB see +map_hugetlb.c. ******************************************************************* /* - * Example of using hugepage memory in a user application using Sys V shared + * Example of using huge page memory in a user application using Sys V shared * memory system calls. In this example the app is requesting 256MB of * memory that is backed by huge pages. The application uses the flag * SHM_HUGETLB in the shmget system call to inform the kernel that it is - * requesting hugepages. + * requesting huge pages. * * For the ia64 architecture, the Linux kernel reserves Region number 4 for - * hugepages. That means the addresses starting with 0x800000... will need - * to be specified. Specifying a fixed address is not required on ppc64, - * i386 or x86_64. + * huge pages. That means that if one requires a fixed address, a huge page + * aligned address starting with 0x800000... will be required. If a fixed + * address is not required, the kernel will select an address in the proper + * range. + * Other architectures, such as ppc64, i386 or x86_64 are not so constrained. * * Note: The default shared memory limit is quite low on many kernels, * you may need to increase it via: @@ -194,14 +339,8 @@ mount of filesystem will be required for using mmap calls. #define dprintf(x) printf(x) -/* Only ia64 requires this */ -#ifdef __ia64__ -#define ADDR (void *)(0x8000000000000000UL) -#define SHMAT_FLAGS (SHM_RND) -#else -#define ADDR (void *)(0x0UL) +#define ADDR (void *)(0x0UL) /* let kernel choose address */ #define SHMAT_FLAGS (0) -#endif int main(void) { @@ -252,17 +391,19 @@ int main(void) ******************************************************************* /* - * Example of using hugepage memory in a user application using the mmap + * Example of using huge page memory in a user application using the mmap * system call. Before running this application, make sure that the * administrator has mounted the hugetlbfs filesystem (on some directory * like /mnt) using the command mount -t hugetlbfs nodev /mnt. In this * example, the app is requesting memory of size 256MB that is backed by * huge pages. * - * For ia64 architecture, Linux kernel reserves Region number 4 for hugepages. - * That means the addresses starting with 0x800000... will need to be - * specified. Specifying a fixed address is not required on ppc64, i386 - * or x86_64. + * For the ia64 architecture, the Linux kernel reserves Region number 4 for + * huge pages. That means that if one requires a fixed address, a huge page + * aligned address starting with 0x800000... will be required. If a fixed + * address is not required, the kernel will select an address in the proper + * range. + * Other architectures, such as ppc64, i386 or x86_64 are not so constrained. */ #include <stdlib.h> #include <stdio.h> @@ -274,14 +415,8 @@ int main(void) #define LENGTH (256UL*1024*1024) #define PROTECTION (PROT_READ | PROT_WRITE) -/* Only ia64 requires this */ -#ifdef __ia64__ -#define ADDR (void *)(0x8000000000000000UL) -#define FLAGS (MAP_SHARED | MAP_FIXED) -#else -#define ADDR (void *)(0x0UL) +#define ADDR (void *)(0x0UL) /* let kernel choose address */ #define FLAGS (MAP_SHARED) -#endif void check_bytes(char *addr) { diff --git a/Documentation/vm/hwpoison.txt b/Documentation/vm/hwpoison.txt new file mode 100644 index 000000000000..12f9ba20ccb7 --- /dev/null +++ b/Documentation/vm/hwpoison.txt @@ -0,0 +1,182 @@ +What is hwpoison? + +Upcoming Intel CPUs have support for recovering from some memory errors +(``MCA recovery''). This requires the OS to declare a page "poisoned", +kill the processes associated with it and avoid using it in the future. + +This patchkit implements the necessary infrastructure in the VM. + +To quote the overview comment: + + * High level machine check handler. Handles pages reported by the + * hardware as being corrupted usually due to a 2bit ECC memory or cache + * failure. + * + * This focusses on pages detected as corrupted in the background. + * When the current CPU tries to consume corruption the currently + * running process can just be killed directly instead. This implies + * that if the error cannot be handled for some reason it's safe to + * just ignore it because no corruption has been consumed yet. Instead + * when that happens another machine check will happen. + * + * Handles page cache pages in various states. The tricky part + * here is that we can access any page asynchronous to other VM + * users, because memory failures could happen anytime and anywhere, + * possibly violating some of their assumptions. This is why this code + * has to be extremely careful. Generally it tries to use normal locking + * rules, as in get the standard locks, even if that means the + * error handling takes potentially a long time. + * + * Some of the operations here are somewhat inefficient and have non + * linear algorithmic complexity, because the data structures have not + * been optimized for this case. This is in particular the case + * for the mapping from a vma to a process. Since this case is expected + * to be rare we hope we can get away with this. + +The code consists of a the high level handler in mm/memory-failure.c, +a new page poison bit and various checks in the VM to handle poisoned +pages. + +The main target right now is KVM guests, but it works for all kinds +of applications. KVM support requires a recent qemu-kvm release. + +For the KVM use there was need for a new signal type so that +KVM can inject the machine check into the guest with the proper +address. This in theory allows other applications to handle +memory failures too. The expection is that near all applications +won't do that, but some very specialized ones might. + +--- + +There are two (actually three) modi memory failure recovery can be in: + +vm.memory_failure_recovery sysctl set to zero: + All memory failures cause a panic. Do not attempt recovery. + (on x86 this can be also affected by the tolerant level of the + MCE subsystem) + +early kill + (can be controlled globally and per process) + Send SIGBUS to the application as soon as the error is detected + This allows applications who can process memory errors in a gentle + way (e.g. drop affected object) + This is the mode used by KVM qemu. + +late kill + Send SIGBUS when the application runs into the corrupted page. + This is best for memory error unaware applications and default + Note some pages are always handled as late kill. + +--- + +User control: + +vm.memory_failure_recovery + See sysctl.txt + +vm.memory_failure_early_kill + Enable early kill mode globally + +PR_MCE_KILL + Set early/late kill mode/revert to system default + arg1: PR_MCE_KILL_CLEAR: Revert to system default + arg1: PR_MCE_KILL_SET: arg2 defines thread specific mode + PR_MCE_KILL_EARLY: Early kill + PR_MCE_KILL_LATE: Late kill + PR_MCE_KILL_DEFAULT: Use system global default +PR_MCE_KILL_GET + return current mode + + +--- + +Testing: + +madvise(MADV_HWPOISON, ....) + (as root) + Poison a page in the process for testing + + +hwpoison-inject module through debugfs + +/sys/debug/hwpoison/ + +corrupt-pfn + +Inject hwpoison fault at PFN echoed into this file. This does +some early filtering to avoid corrupted unintended pages in test suites. + +unpoison-pfn + +Software-unpoison page at PFN echoed into this file. This +way a page can be reused again. +This only works for Linux injected failures, not for real +memory failures. + +Note these injection interfaces are not stable and might change between +kernel versions + +corrupt-filter-dev-major +corrupt-filter-dev-minor + +Only handle memory failures to pages associated with the file system defined +by block device major/minor. -1U is the wildcard value. +This should be only used for testing with artificial injection. + +corrupt-filter-memcg + +Limit injection to pages owned by memgroup. Specified by inode number +of the memcg. + +Example: + mkdir /cgroup/hwpoison + + usemem -m 100 -s 1000 & + echo `jobs -p` > /cgroup/hwpoison/tasks + + memcg_ino=$(ls -id /cgroup/hwpoison | cut -f1 -d' ') + echo $memcg_ino > /debug/hwpoison/corrupt-filter-memcg + + page-types -p `pidof init` --hwpoison # shall do nothing + page-types -p `pidof usemem` --hwpoison # poison its pages + +corrupt-filter-flags-mask +corrupt-filter-flags-value + +When specified, only poison pages if ((page_flags & mask) == value). +This allows stress testing of many kinds of pages. The page_flags +are the same as in /proc/kpageflags. The flag bits are defined in +include/linux/kernel-page-flags.h and documented in +Documentation/vm/pagemap.txt + +Architecture specific MCE injector + +x86 has mce-inject, mce-test + +Some portable hwpoison test programs in mce-test, see blow. + +--- + +References: + +http://halobates.de/mce-lc09-2.pdf + Overview presentation from LinuxCon 09 + +git://git.kernel.org/pub/scm/utils/cpu/mce/mce-test.git + Test suite (hwpoison specific portable tests in tsrc) + +git://git.kernel.org/pub/scm/utils/cpu/mce/mce-inject.git + x86 specific injector + + +--- + +Limitations: + +- Not all page types are supported and never will. Most kernel internal +objects cannot be recovered, only LRU pages for now. +- Right now hugepage support is missing. + +--- +Andi Kleen, Oct 2009 + diff --git a/Documentation/vm/ksm.txt b/Documentation/vm/ksm.txt new file mode 100644 index 000000000000..b392e496f816 --- /dev/null +++ b/Documentation/vm/ksm.txt @@ -0,0 +1,82 @@ +How to use the Kernel Samepage Merging feature +---------------------------------------------- + +KSM is a memory-saving de-duplication feature, enabled by CONFIG_KSM=y, +added to the Linux kernel in 2.6.32. See mm/ksm.c for its implementation, +and http://lwn.net/Articles/306704/ and http://lwn.net/Articles/330589/ + +The KSM daemon ksmd periodically scans those areas of user memory which +have been registered with it, looking for pages of identical content which +can be replaced by a single write-protected page (which is automatically +copied if a process later wants to update its content). + +KSM was originally developed for use with KVM (where it was known as +Kernel Shared Memory), to fit more virtual machines into physical memory, +by sharing the data common between them. But it can be useful to any +application which generates many instances of the same data. + +KSM only merges anonymous (private) pages, never pagecache (file) pages. +KSM's merged pages were originally locked into kernel memory, but can now +be swapped out just like other user pages (but sharing is broken when they +are swapped back in: ksmd must rediscover their identity and merge again). + +KSM only operates on those areas of address space which an application +has advised to be likely candidates for merging, by using the madvise(2) +system call: int madvise(addr, length, MADV_MERGEABLE). + +The app may call int madvise(addr, length, MADV_UNMERGEABLE) to cancel +that advice and restore unshared pages: whereupon KSM unmerges whatever +it merged in that range. Note: this unmerging call may suddenly require +more memory than is available - possibly failing with EAGAIN, but more +probably arousing the Out-Of-Memory killer. + +If KSM is not configured into the running kernel, madvise MADV_MERGEABLE +and MADV_UNMERGEABLE simply fail with EINVAL. If the running kernel was +built with CONFIG_KSM=y, those calls will normally succeed: even if the +the KSM daemon is not currently running, MADV_MERGEABLE still registers +the range for whenever the KSM daemon is started; even if the range +cannot contain any pages which KSM could actually merge; even if +MADV_UNMERGEABLE is applied to a range which was never MADV_MERGEABLE. + +Like other madvise calls, they are intended for use on mapped areas of +the user address space: they will report ENOMEM if the specified range +includes unmapped gaps (though working on the intervening mapped areas), +and might fail with EAGAIN if not enough memory for internal structures. + +Applications should be considerate in their use of MADV_MERGEABLE, +restricting its use to areas likely to benefit. KSM's scans may use a lot +of processing power: some installations will disable KSM for that reason. + +The KSM daemon is controlled by sysfs files in /sys/kernel/mm/ksm/, +readable by all but writable only by root: + +pages_to_scan - how many present pages to scan before ksmd goes to sleep + e.g. "echo 100 > /sys/kernel/mm/ksm/pages_to_scan" + Default: 100 (chosen for demonstration purposes) + +sleep_millisecs - how many milliseconds ksmd should sleep before next scan + e.g. "echo 20 > /sys/kernel/mm/ksm/sleep_millisecs" + Default: 20 (chosen for demonstration purposes) + +run - set 0 to stop ksmd from running but keep merged pages, + set 1 to run ksmd e.g. "echo 1 > /sys/kernel/mm/ksm/run", + set 2 to stop ksmd and unmerge all pages currently merged, + but leave mergeable areas registered for next run + Default: 0 (must be changed to 1 to activate KSM, + except if CONFIG_SYSFS is disabled) + +The effectiveness of KSM and MADV_MERGEABLE is shown in /sys/kernel/mm/ksm/: + +pages_shared - how many shared pages are being used +pages_sharing - how many more sites are sharing them i.e. how much saved +pages_unshared - how many pages unique but repeatedly checked for merging +pages_volatile - how many pages changing too fast to be placed in a tree +full_scans - how many times all mergeable areas have been scanned + +A high ratio of pages_sharing to pages_shared indicates good sharing, but +a high ratio of pages_unshared to pages_sharing indicates wasted effort. +pages_volatile embraces several different kinds of activity, but a high +proportion there would also indicate poor use of madvise MADV_MERGEABLE. + +Izik Eidus, +Hugh Dickins, 17 Nov 2009 diff --git a/Documentation/vm/locking b/Documentation/vm/locking index f366fa956179..25fadb448760 100644 --- a/Documentation/vm/locking +++ b/Documentation/vm/locking @@ -80,7 +80,7 @@ Note: PTL can also be used to guarantee that no new clones using the mm start up ... this is a loose form of stability on mm_users. For example, it is used in copy_mm to protect against a racing tlb_gather_mmu single address space optimization, so that the zap_page_range (from -vmtruncate) does not lose sending ipi's to cloned threads that might +truncate) does not lose sending ipi's to cloned threads that might be spawned underneath it and go to user mode to drag in pte's into tlbs. swap_lock diff --git a/Documentation/vm/map_hugetlb.c b/Documentation/vm/map_hugetlb.c new file mode 100644 index 000000000000..e2bdae37f499 --- /dev/null +++ b/Documentation/vm/map_hugetlb.c @@ -0,0 +1,77 @@ +/* + * Example of using hugepage memory in a user application using the mmap + * system call with MAP_HUGETLB flag. Before running this program make + * sure the administrator has allocated enough default sized huge pages + * to cover the 256 MB allocation. + * + * For ia64 architecture, Linux kernel reserves Region number 4 for hugepages. + * That means the addresses starting with 0x800000... will need to be + * specified. Specifying a fixed address is not required on ppc64, i386 + * or x86_64. + */ +#include <stdlib.h> +#include <stdio.h> +#include <unistd.h> +#include <sys/mman.h> +#include <fcntl.h> + +#define LENGTH (256UL*1024*1024) +#define PROTECTION (PROT_READ | PROT_WRITE) + +#ifndef MAP_HUGETLB +#define MAP_HUGETLB 0x40 +#endif + +/* Only ia64 requires this */ +#ifdef __ia64__ +#define ADDR (void *)(0x8000000000000000UL) +#define FLAGS (MAP_PRIVATE | MAP_ANONYMOUS | MAP_HUGETLB | MAP_FIXED) +#else +#define ADDR (void *)(0x0UL) +#define FLAGS (MAP_PRIVATE | MAP_ANONYMOUS | MAP_HUGETLB) +#endif + +void check_bytes(char *addr) +{ + printf("First hex is %x\n", *((unsigned int *)addr)); +} + +void write_bytes(char *addr) +{ + unsigned long i; + + for (i = 0; i < LENGTH; i++) + *(addr + i) = (char)i; +} + +void read_bytes(char *addr) +{ + unsigned long i; + + check_bytes(addr); + for (i = 0; i < LENGTH; i++) + if (*(addr + i) != (char)i) { + printf("Mismatch at %lu\n", i); + break; + } +} + +int main(void) +{ + void *addr; + + addr = mmap(ADDR, LENGTH, PROTECTION, FLAGS, 0, 0); + if (addr == MAP_FAILED) { + perror("mmap"); + exit(1); + } + + printf("Returned address is %p\n", addr); + check_bytes(addr); + write_bytes(addr); + read_bytes(addr); + + munmap(addr, LENGTH); + + return 0; +} diff --git a/Documentation/vm/page-types.c b/Documentation/vm/page-types.c index 0833f44ba16b..66e9358e2144 100644 --- a/Documentation/vm/page-types.c +++ b/Documentation/vm/page-types.c @@ -1,10 +1,25 @@ /* * page-types: Tool for querying page flags * + * This program is free software; you can redistribute it and/or modify it + * under the terms of the GNU General Public License as published by the Free + * Software Foundation; version 2. + * + * This program is distributed in the hope that it will be useful, but WITHOUT + * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or + * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for + * more details. + * + * You should find a copy of v2 of the GNU General Public License somewhere on + * your Linux system; if not, write to the Free Software Foundation, Inc., 59 + * Temple Place, Suite 330, Boston, MA 02111-1307 USA. + * * Copyright (C) 2009 Intel corporation - * Copyright (C) 2009 Wu Fengguang <fengguang.wu@intel.com> + * + * Authors: Wu Fengguang <fengguang.wu@intel.com> */ +#define _LARGEFILE64_SOURCE #include <stdio.h> #include <stdlib.h> #include <unistd.h> @@ -13,12 +28,33 @@ #include <string.h> #include <getopt.h> #include <limits.h> +#include <assert.h> #include <sys/types.h> #include <sys/errno.h> #include <sys/fcntl.h> /* + * pagemap kernel ABI bits + */ + +#define PM_ENTRY_BYTES sizeof(uint64_t) +#define PM_STATUS_BITS 3 +#define PM_STATUS_OFFSET (64 - PM_STATUS_BITS) +#define PM_STATUS_MASK (((1LL << PM_STATUS_BITS) - 1) << PM_STATUS_OFFSET) +#define PM_STATUS(nr) (((nr) << PM_STATUS_OFFSET) & PM_STATUS_MASK) +#define PM_PSHIFT_BITS 6 +#define PM_PSHIFT_OFFSET (PM_STATUS_OFFSET - PM_PSHIFT_BITS) +#define PM_PSHIFT_MASK (((1LL << PM_PSHIFT_BITS) - 1) << PM_PSHIFT_OFFSET) +#define PM_PSHIFT(x) (((u64) (x) << PM_PSHIFT_OFFSET) & PM_PSHIFT_MASK) +#define PM_PFRAME_MASK ((1LL << PM_PSHIFT_OFFSET) - 1) +#define PM_PFRAME(x) ((x) & PM_PFRAME_MASK) + +#define PM_PRESENT PM_STATUS(4LL) +#define PM_SWAP PM_STATUS(2LL) + + +/* * kernel page flags */ @@ -47,7 +83,9 @@ #define KPF_COMPOUND_TAIL 16 #define KPF_HUGE 17 #define KPF_UNEVICTABLE 18 +#define KPF_HWPOISON 19 #define KPF_NOPAGE 20 +#define KPF_KSM 21 /* [32-] kernel hacking assistances */ #define KPF_RESERVED 32 @@ -73,7 +111,7 @@ #define BIT(name) (1ULL << KPF_##name) #define BITS_COMPOUND (BIT(COMPOUND_HEAD) | BIT(COMPOUND_TAIL)) -static char *page_flag_names[] = { +static const char *page_flag_names[] = { [KPF_LOCKED] = "L:locked", [KPF_ERROR] = "E:error", [KPF_REFERENCED] = "R:referenced", @@ -94,7 +132,9 @@ static char *page_flag_names[] = { [KPF_COMPOUND_TAIL] = "T:compound_tail", [KPF_HUGE] = "G:huge", [KPF_UNEVICTABLE] = "u:unevictable", + [KPF_HWPOISON] = "X:hwpoison", [KPF_NOPAGE] = "n:nopage", + [KPF_KSM] = "x:ksm", [KPF_RESERVED] = "r:reserved", [KPF_MLOCKED] = "m:mlocked", @@ -126,6 +166,11 @@ static int nr_addr_ranges; static unsigned long opt_offset[MAX_ADDR_RANGES]; static unsigned long opt_size[MAX_ADDR_RANGES]; +#define MAX_VMAS 10240 +static int nr_vmas; +static unsigned long pg_start[MAX_VMAS]; +static unsigned long pg_end[MAX_VMAS]; + #define MAX_BIT_FILTERS 64 static int nr_bit_filters; static uint64_t opt_mask[MAX_BIT_FILTERS]; @@ -133,9 +178,15 @@ static uint64_t opt_bits[MAX_BIT_FILTERS]; static int page_size; -#define PAGES_BATCH (64 << 10) /* 64k pages */ +static int pagemap_fd; static int kpageflags_fd; -static uint64_t kpageflags_buf[KPF_BYTES * PAGES_BATCH]; + +static int opt_hwpoison; +static int opt_unpoison; + +static const char hwpoison_debug_fs[] = "/debug/hwpoison"; +static int hwpoison_inject_fd; +static int hwpoison_forget_fd; #define HASH_SHIFT 13 #define HASH_SIZE (1 << HASH_SHIFT) @@ -158,12 +209,17 @@ static uint64_t page_flags[HASH_SIZE]; type __min2 = (y); \ __min1 < __min2 ? __min1 : __min2; }) -unsigned long pages2mb(unsigned long pages) +#define max_t(type, x, y) ({ \ + type __max1 = (x); \ + type __max2 = (y); \ + __max1 > __max2 ? __max1 : __max2; }) + +static unsigned long pages2mb(unsigned long pages) { return (pages * page_size) >> 20; } -void fatal(const char *x, ...) +static void fatal(const char *x, ...) { va_list ap; @@ -173,12 +229,80 @@ void fatal(const char *x, ...) exit(EXIT_FAILURE); } +static int checked_open(const char *pathname, int flags) +{ + int fd = open(pathname, flags); + + if (fd < 0) { + perror(pathname); + exit(EXIT_FAILURE); + } + + return fd; +} + +/* + * pagemap/kpageflags routines + */ + +static unsigned long do_u64_read(int fd, char *name, + uint64_t *buf, + unsigned long index, + unsigned long count) +{ + long bytes; + + if (index > ULONG_MAX / 8) + fatal("index overflow: %lu\n", index); + + if (lseek(fd, index * 8, SEEK_SET) < 0) { + perror(name); + exit(EXIT_FAILURE); + } + + bytes = read(fd, buf, count * 8); + if (bytes < 0) { + perror(name); + exit(EXIT_FAILURE); + } + if (bytes % 8) + fatal("partial read: %lu bytes\n", bytes); + + return bytes / 8; +} + +static unsigned long kpageflags_read(uint64_t *buf, + unsigned long index, + unsigned long pages) +{ + return do_u64_read(kpageflags_fd, PROC_KPAGEFLAGS, buf, index, pages); +} + +static unsigned long pagemap_read(uint64_t *buf, + unsigned long index, + unsigned long pages) +{ + return do_u64_read(pagemap_fd, "/proc/pid/pagemap", buf, index, pages); +} + +static unsigned long pagemap_pfn(uint64_t val) +{ + unsigned long pfn; + + if (val & PM_PRESENT) + pfn = PM_PFRAME(val); + else + pfn = 0; + + return pfn; +} + /* * page flag names */ -char *page_flag_name(uint64_t flags) +static char *page_flag_name(uint64_t flags) { static char buf[65]; int present; @@ -188,7 +312,7 @@ char *page_flag_name(uint64_t flags) present = (flags >> i) & 1; if (!page_flag_names[i]) { if (present) - fatal("unkown flag bit %d\n", i); + fatal("unknown flag bit %d\n", i); continue; } buf[j++] = present ? page_flag_names[i][0] : '_'; @@ -197,7 +321,7 @@ char *page_flag_name(uint64_t flags) return buf; } -char *page_flag_longname(uint64_t flags) +static char *page_flag_longname(uint64_t flags) { static char buf[1024]; int i, n; @@ -221,32 +345,42 @@ char *page_flag_longname(uint64_t flags) * page list and summary */ -void show_page_range(unsigned long offset, uint64_t flags) +static void show_page_range(unsigned long voffset, + unsigned long offset, uint64_t flags) { static uint64_t flags0; + static unsigned long voff; static unsigned long index; static unsigned long count; - if (flags == flags0 && offset == index + count) { + if (flags == flags0 && offset == index + count && + (!opt_pid || voffset == voff + count)) { count++; return; } - if (count) - printf("%lu\t%lu\t%s\n", + if (count) { + if (opt_pid) + printf("%lx\t", voff); + printf("%lx\t%lx\t%s\n", index, count, page_flag_name(flags0)); + } flags0 = flags; index = offset; + voff = voffset; count = 1; } -void show_page(unsigned long offset, uint64_t flags) +static void show_page(unsigned long voffset, + unsigned long offset, uint64_t flags) { - printf("%lu\t%s\n", offset, page_flag_name(flags)); + if (opt_pid) + printf("%lx\t", voffset); + printf("%lx\t%s\n", offset, page_flag_name(flags)); } -void show_summary(void) +static void show_summary(void) { int i; @@ -272,7 +406,7 @@ void show_summary(void) * page flag filters */ -int bit_mask_ok(uint64_t flags) +static int bit_mask_ok(uint64_t flags) { int i; @@ -289,7 +423,7 @@ int bit_mask_ok(uint64_t flags) return 1; } -uint64_t expand_overloaded_flags(uint64_t flags) +static uint64_t expand_overloaded_flags(uint64_t flags) { /* SLOB/SLUB overload several page flags */ if (flags & BIT(SLAB)) { @@ -308,7 +442,7 @@ uint64_t expand_overloaded_flags(uint64_t flags) return flags; } -uint64_t well_known_flags(uint64_t flags) +static uint64_t well_known_flags(uint64_t flags) { /* hide flags intended only for kernel hacker */ flags &= ~KPF_HACKERS_BITS; @@ -320,12 +454,68 @@ uint64_t well_known_flags(uint64_t flags) return flags; } +static uint64_t kpageflags_flags(uint64_t flags) +{ + flags = expand_overloaded_flags(flags); + + if (!opt_raw) + flags = well_known_flags(flags); + + return flags; +} + +/* + * page actions + */ + +static void prepare_hwpoison_fd(void) +{ + char buf[100]; + + if (opt_hwpoison && !hwpoison_inject_fd) { + sprintf(buf, "%s/corrupt-pfn", hwpoison_debug_fs); + hwpoison_inject_fd = checked_open(buf, O_WRONLY); + } + + if (opt_unpoison && !hwpoison_forget_fd) { + sprintf(buf, "%s/renew-pfn", hwpoison_debug_fs); + hwpoison_forget_fd = checked_open(buf, O_WRONLY); + } +} + +static int hwpoison_page(unsigned long offset) +{ + char buf[100]; + int len; + + len = sprintf(buf, "0x%lx\n", offset); + len = write(hwpoison_inject_fd, buf, len); + if (len < 0) { + perror("hwpoison inject"); + return len; + } + return 0; +} + +static int unpoison_page(unsigned long offset) +{ + char buf[100]; + int len; + + len = sprintf(buf, "0x%lx\n", offset); + len = write(hwpoison_forget_fd, buf, len); + if (len < 0) { + perror("hwpoison forget"); + return len; + } + return 0; +} /* * page frame walker */ -int hash_slot(uint64_t flags) +static int hash_slot(uint64_t flags) { int k = HASH_KEY(flags); int i; @@ -352,73 +542,124 @@ int hash_slot(uint64_t flags) exit(EXIT_FAILURE); } -void add_page(unsigned long offset, uint64_t flags) +static void add_page(unsigned long voffset, + unsigned long offset, uint64_t flags) { - flags = expand_overloaded_flags(flags); - - if (!opt_raw) - flags = well_known_flags(flags); + flags = kpageflags_flags(flags); if (!bit_mask_ok(flags)) return; + if (opt_hwpoison) + hwpoison_page(offset); + if (opt_unpoison) + unpoison_page(offset); + if (opt_list == 1) - show_page_range(offset, flags); + show_page_range(voffset, offset, flags); else if (opt_list == 2) - show_page(offset, flags); + show_page(voffset, offset, flags); nr_pages[hash_slot(flags)]++; total_pages++; } -void walk_pfn(unsigned long index, unsigned long count) +#define KPAGEFLAGS_BATCH (64 << 10) /* 64k pages */ +static void walk_pfn(unsigned long voffset, + unsigned long index, + unsigned long count) { + uint64_t buf[KPAGEFLAGS_BATCH]; unsigned long batch; - unsigned long n; + long pages; unsigned long i; - if (index > ULONG_MAX / KPF_BYTES) - fatal("index overflow: %lu\n", index); + while (count) { + batch = min_t(unsigned long, count, KPAGEFLAGS_BATCH); + pages = kpageflags_read(buf, index, batch); + if (pages == 0) + break; + + for (i = 0; i < pages; i++) + add_page(voffset + i, index + i, buf[i]); - lseek(kpageflags_fd, index * KPF_BYTES, SEEK_SET); + index += pages; + count -= pages; + } +} + +#define PAGEMAP_BATCH (64 << 10) +static void walk_vma(unsigned long index, unsigned long count) +{ + uint64_t buf[PAGEMAP_BATCH]; + unsigned long batch; + unsigned long pages; + unsigned long pfn; + unsigned long i; while (count) { - batch = min_t(unsigned long, count, PAGES_BATCH); - n = read(kpageflags_fd, kpageflags_buf, batch * KPF_BYTES); - if (n == 0) + batch = min_t(unsigned long, count, PAGEMAP_BATCH); + pages = pagemap_read(buf, index, batch); + if (pages == 0) break; - if (n < 0) { - perror(PROC_KPAGEFLAGS); - exit(EXIT_FAILURE); + + for (i = 0; i < pages; i++) { + pfn = pagemap_pfn(buf[i]); + if (pfn) + walk_pfn(index + i, pfn, 1); } - if (n % KPF_BYTES != 0) - fatal("partial read: %lu bytes\n", n); - n = n / KPF_BYTES; + index += pages; + count -= pages; + } +} + +static void walk_task(unsigned long index, unsigned long count) +{ + const unsigned long end = index + count; + unsigned long start; + int i = 0; + + while (index < end) { - for (i = 0; i < n; i++) - add_page(index + i, kpageflags_buf[i]); + while (pg_end[i] <= index) + if (++i >= nr_vmas) + return; + if (pg_start[i] >= end) + return; - index += batch; - count -= batch; + start = max_t(unsigned long, pg_start[i], index); + index = min_t(unsigned long, pg_end[i], end); + + assert(start < index); + walk_vma(start, index - start); } } -void walk_addr_ranges(void) +static void add_addr_range(unsigned long offset, unsigned long size) +{ + if (nr_addr_ranges >= MAX_ADDR_RANGES) + fatal("too many addr ranges\n"); + + opt_offset[nr_addr_ranges] = offset; + opt_size[nr_addr_ranges] = min_t(unsigned long, size, ULONG_MAX-offset); + nr_addr_ranges++; +} + +static void walk_addr_ranges(void) { int i; - kpageflags_fd = open(PROC_KPAGEFLAGS, O_RDONLY); - if (kpageflags_fd < 0) { - perror(PROC_KPAGEFLAGS); - exit(EXIT_FAILURE); - } + kpageflags_fd = checked_open(PROC_KPAGEFLAGS, O_RDONLY); if (!nr_addr_ranges) - walk_pfn(0, ULONG_MAX); + add_addr_range(0, ULONG_MAX); for (i = 0; i < nr_addr_ranges; i++) - walk_pfn(opt_offset[i], opt_size[i]); + if (!opt_pid) + walk_pfn(0, opt_offset[i], opt_size[i]); + else + walk_task(opt_offset[i], opt_size[i]); close(kpageflags_fd); } @@ -428,7 +669,7 @@ void walk_addr_ranges(void) * user interface */ -const char *page_flag_type(uint64_t flag) +static const char *page_flag_type(uint64_t flag) { if (flag & KPF_HACKERS_BITS) return "(r)"; @@ -437,34 +678,41 @@ const char *page_flag_type(uint64_t flag) return " "; } -void usage(void) +static void usage(void) { int i, j; printf( "page-types [options]\n" -" -r|--raw Raw mode, for kernel developers\n" -" -a|--addr addr-spec Walk a range of pages\n" -" -b|--bits bits-spec Walk pages with specified bits\n" +" -r|--raw Raw mode, for kernel developers\n" +" -d|--describe flags Describe flags\n" +" -a|--addr addr-spec Walk a range of pages\n" +" -b|--bits bits-spec Walk pages with specified bits\n" +" -p|--pid pid Walk process address space\n" #if 0 /* planned features */ -" -p|--pid pid Walk process address space\n" -" -f|--file filename Walk file address space\n" +" -f|--file filename Walk file address space\n" #endif -" -l|--list Show page details in ranges\n" -" -L|--list-each Show page details one by one\n" -" -N|--no-summary Don't show summay info\n" -" -h|--help Show this usage message\n" +" -l|--list Show page details in ranges\n" +" -L|--list-each Show page details one by one\n" +" -N|--no-summary Don't show summay info\n" +" -X|--hwpoison hwpoison pages\n" +" -x|--unpoison unpoison pages\n" +" -h|--help Show this usage message\n" +"flags:\n" +" 0x10 bitfield format, e.g.\n" +" anon bit-name, e.g.\n" +" 0x10,anon comma-separated list, e.g.\n" "addr-spec:\n" -" N one page at offset N (unit: pages)\n" -" N+M pages range from N to N+M-1\n" -" N,M pages range from N to M-1\n" -" N, pages range from N to end\n" -" ,M pages range from 0 to M\n" +" N one page at offset N (unit: pages)\n" +" N+M pages range from N to N+M-1\n" +" N,M pages range from N to M-1\n" +" N, pages range from N to end\n" +" ,M pages range from 0 to M-1\n" "bits-spec:\n" -" bit1,bit2 (flags & (bit1|bit2)) != 0\n" -" bit1,bit2=bit1 (flags & (bit1|bit2)) == bit1\n" -" bit1,~bit2 (flags & (bit1|bit2)) == bit1\n" -" =bit1,bit2 flags == (bit1|bit2)\n" +" bit1,bit2 (flags & (bit1|bit2)) != 0\n" +" bit1,bit2=bit1 (flags & (bit1|bit2)) == bit1\n" +" bit1,~bit2 (flags & (bit1|bit2)) == bit1\n" +" =bit1,bit2 flags == (bit1|bit2)\n" "bit-names:\n" ); @@ -482,7 +730,7 @@ void usage(void) "(r) raw mode bits (o) overloaded bits\n"); } -unsigned long long parse_number(const char *str) +static unsigned long long parse_number(const char *str) { unsigned long long n; @@ -494,26 +742,58 @@ unsigned long long parse_number(const char *str) return n; } -void parse_pid(const char *str) +static void parse_pid(const char *str) { + FILE *file; + char buf[5000]; + opt_pid = parse_number(str); -} -void parse_file(const char *name) -{ + sprintf(buf, "/proc/%d/pagemap", opt_pid); + pagemap_fd = checked_open(buf, O_RDONLY); + + sprintf(buf, "/proc/%d/maps", opt_pid); + file = fopen(buf, "r"); + if (!file) { + perror(buf); + exit(EXIT_FAILURE); + } + + while (fgets(buf, sizeof(buf), file) != NULL) { + unsigned long vm_start; + unsigned long vm_end; + unsigned long long pgoff; + int major, minor; + char r, w, x, s; + unsigned long ino; + int n; + + n = sscanf(buf, "%lx-%lx %c%c%c%c %llx %x:%x %lu", + &vm_start, + &vm_end, + &r, &w, &x, &s, + &pgoff, + &major, &minor, + &ino); + if (n < 10) { + fprintf(stderr, "unexpected line: %s\n", buf); + continue; + } + pg_start[nr_vmas] = vm_start / page_size; + pg_end[nr_vmas] = vm_end / page_size; + if (++nr_vmas >= MAX_VMAS) { + fprintf(stderr, "too many VMAs\n"); + break; + } + } + fclose(file); } -void add_addr_range(unsigned long offset, unsigned long size) +static void parse_file(const char *name) { - if (nr_addr_ranges >= MAX_ADDR_RANGES) - fatal("too much addr ranges\n"); - - opt_offset[nr_addr_ranges] = offset; - opt_size[nr_addr_ranges] = size; - nr_addr_ranges++; } -void parse_addr_range(const char *optarg) +static void parse_addr_range(const char *optarg) { unsigned long offset; unsigned long size; @@ -547,7 +827,7 @@ void parse_addr_range(const char *optarg) add_addr_range(offset, size); } -void add_bits_filter(uint64_t mask, uint64_t bits) +static void add_bits_filter(uint64_t mask, uint64_t bits) { if (nr_bit_filters >= MAX_BIT_FILTERS) fatal("too much bit filters\n"); @@ -557,7 +837,7 @@ void add_bits_filter(uint64_t mask, uint64_t bits) nr_bit_filters++; } -uint64_t parse_flag_name(const char *str, int len) +static uint64_t parse_flag_name(const char *str, int len) { int i; @@ -577,7 +857,7 @@ uint64_t parse_flag_name(const char *str, int len) return parse_number(str); } -uint64_t parse_flag_names(const char *str, int all) +static uint64_t parse_flag_names(const char *str, int all) { const char *p = str; uint64_t flags = 0; @@ -596,7 +876,7 @@ uint64_t parse_flag_names(const char *str, int all) return flags; } -void parse_bits_mask(const char *optarg) +static void parse_bits_mask(const char *optarg) { uint64_t mask; uint64_t bits; @@ -620,16 +900,28 @@ void parse_bits_mask(const char *optarg) add_bits_filter(mask, bits); } +static void describe_flags(const char *optarg) +{ + uint64_t flags = parse_flag_names(optarg, 0); + + printf("0x%016llx\t%s\t%s\n", + (unsigned long long)flags, + page_flag_name(flags), + page_flag_longname(flags)); +} -struct option opts[] = { +static const struct option opts[] = { { "raw" , 0, NULL, 'r' }, { "pid" , 1, NULL, 'p' }, { "file" , 1, NULL, 'f' }, { "addr" , 1, NULL, 'a' }, { "bits" , 1, NULL, 'b' }, + { "describe" , 1, NULL, 'd' }, { "list" , 0, NULL, 'l' }, { "list-each" , 0, NULL, 'L' }, { "no-summary", 0, NULL, 'N' }, + { "hwpoison" , 0, NULL, 'X' }, + { "unpoison" , 0, NULL, 'x' }, { "help" , 0, NULL, 'h' }, { NULL , 0, NULL, 0 } }; @@ -641,7 +933,7 @@ int main(int argc, char *argv[]) page_size = getpagesize(); while ((c = getopt_long(argc, argv, - "rp:f:a:b:lLNh", opts, NULL)) != -1) { + "rp:f:a:b:d:lLNXxh", opts, NULL)) != -1) { switch (c) { case 'r': opt_raw = 1; @@ -658,6 +950,9 @@ int main(int argc, char *argv[]) case 'b': parse_bits_mask(optarg); break; + case 'd': + describe_flags(optarg); + exit(0); case 'l': opt_list = 1; break; @@ -667,6 +962,14 @@ int main(int argc, char *argv[]) case 'N': opt_no_summary = 1; break; + case 'X': + opt_hwpoison = 1; + prepare_hwpoison_fd(); + break; + case 'x': + opt_unpoison = 1; + prepare_hwpoison_fd(); + break; case 'h': usage(); exit(0); @@ -676,15 +979,17 @@ int main(int argc, char *argv[]) } } + if (opt_list && opt_pid) + printf("voffset\t"); if (opt_list == 1) - printf("offset\tcount\tflags\n"); + printf("offset\tlen\tflags\n"); if (opt_list == 2) printf("offset\tflags\n"); walk_addr_ranges(); if (opt_list == 1) - show_page_range(0, 0); /* drain the buffer */ + show_page_range(0, 0, 0); /* drain the buffer */ if (opt_no_summary) return 0; diff --git a/Documentation/vm/pagemap.txt b/Documentation/vm/pagemap.txt index 600a304a828c..df09b9650a81 100644 --- a/Documentation/vm/pagemap.txt +++ b/Documentation/vm/pagemap.txt @@ -57,7 +57,9 @@ There are three components to pagemap: 16. COMPOUND_TAIL 16. HUGE 18. UNEVICTABLE + 19. HWPOISON 20. NOPAGE + 21. KSM Short descriptions to the page flags: @@ -86,9 +88,15 @@ Short descriptions to the page flags: 17. HUGE this is an integral part of a HugeTLB page +19. HWPOISON + hardware detected memory corruption on this page: don't touch the data! + 20. NOPAGE no page frame exists at the requested address +21. KSM + identical memory pages dynamically shared between one or more processes + [IO related page flags] 1. ERROR IO error occurred 3. UPTODATE page has up-to-date data diff --git a/Documentation/vm/slabinfo.c b/Documentation/vm/slabinfo.c index df3227605d59..92e729f4b676 100644 --- a/Documentation/vm/slabinfo.c +++ b/Documentation/vm/slabinfo.c @@ -87,7 +87,7 @@ int page_size; regex_t pattern; -void fatal(const char *x, ...) +static void fatal(const char *x, ...) { va_list ap; @@ -97,7 +97,7 @@ void fatal(const char *x, ...) exit(EXIT_FAILURE); } -void usage(void) +static void usage(void) { printf("slabinfo 5/7/2007. (c) 2007 sgi.\n\n" "slabinfo [-ahnpvtsz] [-d debugopts] [slab-regexp]\n" @@ -131,7 +131,7 @@ void usage(void) ); } -unsigned long read_obj(const char *name) +static unsigned long read_obj(const char *name) { FILE *f = fopen(name, "r"); @@ -151,7 +151,7 @@ unsigned long read_obj(const char *name) /* * Get the contents of an attribute */ -unsigned long get_obj(const char *name) +static unsigned long get_obj(const char *name) { if (!read_obj(name)) return 0; @@ -159,7 +159,7 @@ unsigned long get_obj(const char *name) return atol(buffer); } -unsigned long get_obj_and_str(const char *name, char **x) +static unsigned long get_obj_and_str(const char *name, char **x) { unsigned long result = 0; char *p; @@ -178,7 +178,7 @@ unsigned long get_obj_and_str(const char *name, char **x) return result; } -void set_obj(struct slabinfo *s, const char *name, int n) +static void set_obj(struct slabinfo *s, const char *name, int n) { char x[100]; FILE *f; @@ -192,7 +192,7 @@ void set_obj(struct slabinfo *s, const char *name, int n) fclose(f); } -unsigned long read_slab_obj(struct slabinfo *s, const char *name) +static unsigned long read_slab_obj(struct slabinfo *s, const char *name) { char x[100]; FILE *f; @@ -215,7 +215,7 @@ unsigned long read_slab_obj(struct slabinfo *s, const char *name) /* * Put a size string together */ -int store_size(char *buffer, unsigned long value) +static int store_size(char *buffer, unsigned long value) { unsigned long divisor = 1; char trailer = 0; @@ -247,7 +247,7 @@ int store_size(char *buffer, unsigned long value) return n; } -void decode_numa_list(int *numa, char *t) +static void decode_numa_list(int *numa, char *t) { int node; int nr; @@ -272,7 +272,7 @@ void decode_numa_list(int *numa, char *t) } } -void slab_validate(struct slabinfo *s) +static void slab_validate(struct slabinfo *s) { if (strcmp(s->name, "*") == 0) return; @@ -280,7 +280,7 @@ void slab_validate(struct slabinfo *s) set_obj(s, "validate", 1); } -void slab_shrink(struct slabinfo *s) +static void slab_shrink(struct slabinfo *s) { if (strcmp(s->name, "*") == 0) return; @@ -290,7 +290,7 @@ void slab_shrink(struct slabinfo *s) int line = 0; -void first_line(void) +static void first_line(void) { if (show_activity) printf("Name Objects Alloc Free %%Fast Fallb O\n"); @@ -302,7 +302,7 @@ void first_line(void) /* * Find the shortest alias of a slab */ -struct aliasinfo *find_one_alias(struct slabinfo *find) +static struct aliasinfo *find_one_alias(struct slabinfo *find) { struct aliasinfo *a; struct aliasinfo *best = NULL; @@ -318,18 +318,18 @@ struct aliasinfo *find_one_alias(struct slabinfo *find) return best; } -unsigned long slab_size(struct slabinfo *s) +static unsigned long slab_size(struct slabinfo *s) { return s->slabs * (page_size << s->order); } -unsigned long slab_activity(struct slabinfo *s) +static unsigned long slab_activity(struct slabinfo *s) { return s->alloc_fastpath + s->free_fastpath + s->alloc_slowpath + s->free_slowpath; } -void slab_numa(struct slabinfo *s, int mode) +static void slab_numa(struct slabinfo *s, int mode) { int node; @@ -374,7 +374,7 @@ void slab_numa(struct slabinfo *s, int mode) line++; } -void show_tracking(struct slabinfo *s) +static void show_tracking(struct slabinfo *s) { printf("\n%s: Kernel object allocation\n", s->name); printf("-----------------------------------------------------------------------\n"); @@ -392,7 +392,7 @@ void show_tracking(struct slabinfo *s) } -void ops(struct slabinfo *s) +static void ops(struct slabinfo *s) { if (strcmp(s->name, "*") == 0) return; @@ -405,14 +405,14 @@ void ops(struct slabinfo *s) printf("\n%s has no kmem_cache operations\n", s->name); } -const char *onoff(int x) +static const char *onoff(int x) { if (x) return "On "; return "Off"; } -void slab_stats(struct slabinfo *s) +static void slab_stats(struct slabinfo *s) { unsigned long total_alloc; unsigned long total_free; @@ -477,7 +477,7 @@ void slab_stats(struct slabinfo *s) s->deactivate_to_tail, (s->deactivate_to_tail * 100) / total); } -void report(struct slabinfo *s) +static void report(struct slabinfo *s) { if (strcmp(s->name, "*") == 0) return; @@ -518,7 +518,7 @@ void report(struct slabinfo *s) slab_stats(s); } -void slabcache(struct slabinfo *s) +static void slabcache(struct slabinfo *s) { char size_str[20]; char dist_str[40]; @@ -593,7 +593,7 @@ void slabcache(struct slabinfo *s) /* * Analyze debug options. Return false if something is amiss. */ -int debug_opt_scan(char *opt) +static int debug_opt_scan(char *opt) { if (!opt || !opt[0] || strcmp(opt, "-") == 0) return 1; @@ -642,7 +642,7 @@ int debug_opt_scan(char *opt) return 1; } -int slab_empty(struct slabinfo *s) +static int slab_empty(struct slabinfo *s) { if (s->objects > 0) return 0; @@ -657,7 +657,7 @@ int slab_empty(struct slabinfo *s) return 1; } -void slab_debug(struct slabinfo *s) +static void slab_debug(struct slabinfo *s) { if (strcmp(s->name, "*") == 0) return; @@ -717,7 +717,7 @@ void slab_debug(struct slabinfo *s) set_obj(s, "trace", 1); } -void totals(void) +static void totals(void) { struct slabinfo *s; @@ -976,7 +976,7 @@ void totals(void) b1, b2, b3); } -void sort_slabs(void) +static void sort_slabs(void) { struct slabinfo *s1,*s2; @@ -1005,7 +1005,7 @@ void sort_slabs(void) } } -void sort_aliases(void) +static void sort_aliases(void) { struct aliasinfo *a1,*a2; @@ -1030,7 +1030,7 @@ void sort_aliases(void) } } -void link_slabs(void) +static void link_slabs(void) { struct aliasinfo *a; struct slabinfo *s; @@ -1048,7 +1048,7 @@ void link_slabs(void) } } -void alias(void) +static void alias(void) { struct aliasinfo *a; char *active = NULL; @@ -1079,7 +1079,7 @@ void alias(void) } -void rename_slabs(void) +static void rename_slabs(void) { struct slabinfo *s; struct aliasinfo *a; @@ -1102,12 +1102,12 @@ void rename_slabs(void) } } -int slab_mismatch(char *slab) +static int slab_mismatch(char *slab) { return regexec(&pattern, slab, 0, NULL, 0); } -void read_slab_dir(void) +static void read_slab_dir(void) { DIR *dir; struct dirent *de; @@ -1209,7 +1209,7 @@ void read_slab_dir(void) fatal("Too many aliases\n"); } -void output_slabs(void) +static void output_slabs(void) { struct slabinfo *slab; diff --git a/Documentation/vm/slub.txt b/Documentation/vm/slub.txt index bb1f5c6e28b3..b37300edf27c 100644 --- a/Documentation/vm/slub.txt +++ b/Documentation/vm/slub.txt @@ -41,6 +41,8 @@ Possible debug options are P Poisoning (object and padding) U User tracking (free and alloc) T Trace (please only use on single slabs) + O Switch debugging off for caches that would have + caused higher minimum slab orders - Switch all debugging off (useful if the kernel is configured with CONFIG_SLUB_DEBUG_ON) @@ -59,6 +61,14 @@ to the dentry cache with slub_debug=F,dentry +Debugging options may require the minimum possible slab order to increase as +a result of storing the metadata (for example, caches with PAGE_SIZE object +sizes). This has a higher liklihood of resulting in slab allocation errors +in low memory situations or if there's high fragmentation of memory. To +switch off debugging for such caches by default, use + + slub_debug=O + In case you forgot to enable debugging on the kernel command line: It is possible to enable debugging manually when the kernel is up. Look at the contents of: @@ -235,7 +245,7 @@ been overwritten. Here a string of 8 characters was written into a slab that has the length of 8 characters. However, a 8 character string needs a terminating 0. That zero has overwritten the first byte of the Redzone field. After reporting the details of the issue encountered the FIX SLUB message -tell us that SLUB has restored the Redzone to its proper value and then +tells us that SLUB has restored the Redzone to its proper value and then system operations continue. Emergency operations: diff --git a/Documentation/w1/masters/ds2482 b/Documentation/w1/masters/ds2482 index 9210d6fa5024..299b91c7609f 100644 --- a/Documentation/w1/masters/ds2482 +++ b/Documentation/w1/masters/ds2482 @@ -24,8 +24,8 @@ General Remarks Valid addresses are 0x18, 0x19, 0x1a, and 0x1b. However, the device cannot be detected without writing to the i2c bus, so no -detection is done. -You should force the device address. +detection is done. You should instantiate the device explicitly. -$ modprobe ds2482 force=0,0x18 +$ modprobe ds2482 +$ echo ds2482 0x18 > /sys/bus/i2c/devices/i2c-0/new_device diff --git a/Documentation/watchdog/src/watchdog-test.c b/Documentation/watchdog/src/watchdog-test.c index 65f6c19cb865..a750532ffcf8 100644 --- a/Documentation/watchdog/src/watchdog-test.c +++ b/Documentation/watchdog/src/watchdog-test.c @@ -18,7 +18,7 @@ int fd; * the PC Watchdog card to reset its internal timer so it doesn't trigger * a computer reset. */ -void keep_alive(void) +static void keep_alive(void) { int dummy; diff --git a/Documentation/x86/boot.txt b/Documentation/x86/boot.txt index 8da3a795083f..30b43e1b2697 100644 --- a/Documentation/x86/boot.txt +++ b/Documentation/x86/boot.txt @@ -599,6 +599,7 @@ Protocol: 2.07+ 0x00000000 The default x86/PC environment 0x00000001 lguest 0x00000002 Xen + 0x00000003 Moorestown MID Field name: hardware_subarch_data Type: write (subarch-dependent) diff --git a/Documentation/x86/earlyprintk.txt b/Documentation/x86/earlyprintk.txt index 607b1a016064..f19802c0f485 100644 --- a/Documentation/x86/earlyprintk.txt +++ b/Documentation/x86/earlyprintk.txt @@ -7,7 +7,7 @@ and two USB cables, connected like this: [host/target] <-------> [USB debug key] <-------> [client/console] -1. There are three specific hardware requirements: +1. There are a number of specific hardware requirements: a.) Host/target system needs to have USB debug port capability. @@ -42,7 +42,35 @@ and two USB cables, connected like this: This is a small blue plastic connector with two USB connections, it draws power from its USB connections. - c.) Thirdly, you need a second client/console system with a regular USB port. + c.) You need a second client/console system with a high speed USB 2.0 + port. + + d.) The Netchip device must be plugged directly into the physical + debug port on the "host/target" system. You cannot use a USB hub in + between the physical debug port and the "host/target" system. + + The EHCI debug controller is bound to a specific physical USB + port and the Netchip device will only work as an early printk + device in this port. The EHCI host controllers are electrically + wired such that the EHCI debug controller is hooked up to the + first physical and there is no way to change this via software. + You can find the physical port through experimentation by trying + each physical port on the system and rebooting. Or you can try + and use lsusb or look at the kernel info messages emitted by the + usb stack when you plug a usb device into various ports on the + "host/target" system. + + Some hardware vendors do not expose the usb debug port with a + physical connector and if you find such a device send a complaint + to the hardware vendor, because there is no reason not to wire + this port into one of the physically accessible ports. + + e.) It is also important to note, that many versions of the Netchip + device require the "client/console" system to be plugged into the + right and side of the device (with the product logo facing up and + readable left to right). The reason being is that the 5 volt + power supply is taken from only one side of the device and it + must be the side that does not get rebooted. 2. Software requirements: @@ -56,6 +84,13 @@ and two USB cables, connected like this: (If you are using Grub, append it to the 'kernel' line in /etc/grub.conf) + On systems with more than one EHCI debug controller you must + specify the correct EHCI debug controller number. The ordering + comes from the PCI bus enumeration of the EHCI controllers. The + default with no number argument is "0" the first EHCI debug + controller. To use the second EHCI debug controller, you would + use the command line: "earlyprintk=dbgp1" + NOTE: normally earlyprintk console gets turned off once the regular console is alive - use "earlyprintk=dbgp,keep" to keep this channel open beyond early bootup. This can be useful for diff --git a/Documentation/x86/zero-page.txt b/Documentation/x86/zero-page.txt index 4f913857b8a2..feb37e177010 100644 --- a/Documentation/x86/zero-page.txt +++ b/Documentation/x86/zero-page.txt @@ -12,6 +12,7 @@ Offset Proto Name Meaning 000/040 ALL screen_info Text mode or frame buffer information (struct screen_info) 040/014 ALL apm_bios_info APM BIOS information (struct apm_bios_info) +058/008 ALL tboot_addr Physical address of tboot shared page 060/010 ALL ist_info Intel SpeedStep (IST) BIOS support information (struct ist_info) 080/010 ALL hd0_info hd0 disk parameter, OBSOLETE!! |
