xiaomi-sm8450/android_kernel_xiaomi_sm8450
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Merge tag 'v4.2-rc3' into next

Browse Source 
Sync up with Linux 4.2-rc3 to bring in infrastructure (OF) pieces.
This commit is contained in:
Dmitry Torokhov
2015-07-20 10:08:17 -07:00
parent 6ccfe64c77 52721d9d33
commit c57d5621d2
16312 changed files with 1451643 additions and 462384 deletions
Download Patch File Download Diff File Expand all files Collapse all files

1
.gitignore vendored
View File

@@ -24,6 +24,7 @@
*.order
*.elf
*.bin
*.tar
*.gz
*.bz2
*.lzma

9
.mailmap
View File

@@ -84,6 +84,7 @@ Mayuresh Janorkar <mayur@ti.com>
Michael Buesch <m@bues.ch>
Michel Dänzer <michel@tungstengraphics.com>
Mitesh shah <mshah@teja.com>
Mohit Kumar <mohit.kumar@st.com> <mohit.kumar.dhaka@gmail.com>
Morten Welinder <terra@gnome.org>
Morten Welinder <welinder@anemone.rentec.com>
Morten Welinder <welinder@darter.rentec.com>
@@ -95,11 +96,14 @@ Patrick Mochel <mochel@digitalimplant.org>
Peter A Jonsson <pj@ludd.ltu.se>
Peter Oruba <peter@oruba.de>
Peter Oruba <peter.oruba@amd.com>
Pratyush Anand <pratyush.anand@gmail.com> <pratyush.anand@st.com>
Praveen BP <praveenbp@ti.com>
Rajesh Shah <rajesh.shah@intel.com>
Ralf Baechle <ralf@linux-mips.org>
Ralf Wildenhues <Ralf.Wildenhues@gmx.de>
Randy Dunlap <rdunlap@infradead.org> <rdunlap@xenotime.net>
Rémi Denis-Courmont <rdenis@simphalempin.com>
Ricardo Ribalda Delgado <ricardo.ribalda@gmail.com>
Rudolf Marek <R.Marek@sh.cvut.cz>
Rui Saraiva <rmps@joel.ist.utl.pt>
Sachin P Sant <ssant@in.ibm.com>
@@ -112,6 +116,7 @@ Shiraz Hashim <shiraz.linux.kernel@gmail.com> <shiraz.hashim@st.com>
Simon Kelley <simon@thekelleys.org.uk>
Stéphane Witzmann <stephane.witzmann@ubpmes.univ-bpclermont.fr>
Stephen Hemminger <shemminger@osdl.org>
Sudeep Holla <sudeep.holla@arm.com> Sudeep KarkadaNagesha <sudeep.karkadanagesha@arm.com>
Sumit Semwal <sumit.semwal@ti.com>
Tejun Heo <htejun@gmail.com>
Thomas Graf <tgraf@suug.ch>
@@ -121,7 +126,9 @@ Uwe Kleine-König <ukleinek@informatik.uni-freiburg.de>
Uwe Kleine-König <ukl@pengutronix.de>
Uwe Kleine-König <Uwe.Kleine-Koenig@digi.com>
Valdis Kletnieks <Valdis.Kletnieks@vt.edu>
Viresh Kumar <viresh.linux@gmail.com> <viresh.kumar@st.com>
Viresh Kumar <vireshk@kernel.org> <viresh.kumar@st.com>
Viresh Kumar <vireshk@kernel.org> <viresh.linux@gmail.com>
Viresh Kumar <vireshk@kernel.org> <viresh.kumar2@arm.com>
Takashi YOSHII <takashi.yoshii.zj@renesas.com>
Yusuke Goda <goda.yusuke@renesas.com>
Gustavo Padovan <gustavo@las.ic.unicamp.br>

41
CREDITS
View File

@@ -187,6 +187,10 @@ N: Krishna Balasubramanian
E: balasub@cis.ohio-state.edu
D: Wrote SYS V IPC (part of standard kernel since 0.99.10)
N: Chris Ball
E: chris@printf.net
D: Former maintainer of the MMC/SD/SDIO subsystem.
N: Dario Ballabio
E: ballabio_dario@emc.com
E: dario.ballabio@tiscalinet.it
@@ -504,6 +508,10 @@ E: paul@paulbristow.net
W: http://paulbristow.net/linux/idefloppy.html
D: Maintainer of IDE/ATAPI floppy driver
N: Stefano Brivio
E: stefano.brivio@polimi.it
D: Broadcom B43 driver
N: Dominik Brodowski
E: linux@brodo.de
W: http://www.brodo.de/
@@ -2041,6 +2049,10 @@ D: pirq addr, CS5535 alsa audio driver
S: Gurgaon, India
S: Kuala Lumpur, Malaysia
N: Mohit Kumar
D: ST Microelectronics SPEAr13xx PCI host bridge driver
D: Synopsys Designware PCI host bridge driver
N: Gabor Kuti
M: seasons@falcon.sch.bme.hu
M: seasons@makosteszta.sote.hu
@@ -2728,6 +2740,10 @@ S: C/ Mieses 20, 9-B
S: Valladolid 47009
S: Spain
N: Jens Osterkamp
E: jens@de.ibm.com
D: Maintainer of Spidernet network driver for Cell
N: Gadi Oxman
E: gadio@netvision.net.il
D: Original author and maintainer of IDE/ATAPI floppy/tape drivers
@@ -3004,6 +3020,19 @@ W: http://www.qsl.net/dl1bke/
D: Generic Z8530 driver, AX.25 DAMA slave implementation
D: Several AX.25 hacks
N: Ricardo Ribalda Delgado
E: ricardo.ribalda@gmail.com
W: http://ribalda.com
D: PLX USB338x driver
D: PCA9634 driver
D: Option GTM671WFS
D: Fintek F81216A
D: Various kernel hacks
S: Qtechnology A/S
S: Valby Langgade 142
S: 2500 Valby
S: Denmark
N: Francois-Rene Rideau
E: fare@tunes.org
W: http://www.tunes.org/~fare
@@ -3194,11 +3223,6 @@ N: Dipankar Sarma
E: dipankar@in.ibm.com
D: RCU
N: Yoshinori Sato
E: ysato@users.sourceforge.jp
D: uClinux for Renesas H8/300 (H8300)
D: http://uclinux-h8.sourceforge.jp/
N: Hannu Savolainen
E: hannu@opensound.com
D: Maintainer of the sound drivers until 2.1.x days.
@@ -3684,6 +3708,13 @@ N: Dirk Verworner
D: Co-author of German book ``Linux-Kernel-Programmierung''
D: Co-founder of Berlin Linux User Group
N: Andrew Victor
E: linux@maxim.org.za
W: http://maxim.org.za/at91_26.html
D: First maintainer of Atmel ARM-based SoC, aka AT91
D: Introduced support for at91rm9200, the first chip of AT91 family
S: South Africa
N: Riku Voipio
E: riku.voipio@iki.fi
D: Author of PCA9532 LED and Fintek f75375s hwmon driver

119
Documentation/ABI/obsolete/sysfs-block-zram Normal file
View File

@@ -0,0 +1,119 @@
What: /sys/block/zram<id>/num_reads
Date: August 2015
Contact: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
Description:
The num_reads file is read-only and specifies the number of
reads (failed or successful) done on this device.
Now accessible via zram<id>/stat node.
What: /sys/block/zram<id>/num_writes
Date: August 2015
Contact: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
Description:
The num_writes file is read-only and specifies the number of
writes (failed or successful) done on this device.
Now accessible via zram<id>/stat node.
What: /sys/block/zram<id>/invalid_io
Date: August 2015
Contact: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
Description:
The invalid_io file is read-only and specifies the number of
non-page-size-aligned I/O requests issued to this device.
Now accessible via zram<id>/io_stat node.
What: /sys/block/zram<id>/failed_reads
Date: August 2015
Contact: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
Description:
The failed_reads file is read-only and specifies the number of
failed reads happened on this device.
Now accessible via zram<id>/io_stat node.
What: /sys/block/zram<id>/failed_writes
Date: August 2015
Contact: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
Description:
The failed_writes file is read-only and specifies the number of
failed writes happened on this device.
Now accessible via zram<id>/io_stat node.
What: /sys/block/zram<id>/notify_free
Date: August 2015
Contact: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
Description:
The notify_free file is read-only. Depending on device usage
scenario it may account a) the number of pages freed because
of swap slot free notifications or b) the number of pages freed
because of REQ_DISCARD requests sent by bio. The former ones
are sent to a swap block device when a swap slot is freed, which
implies that this disk is being used as a swap disk. The latter
ones are sent by filesystem mounted with discard option,
whenever some data blocks are getting discarded.
Now accessible via zram<id>/io_stat node.
What: /sys/block/zram<id>/zero_pages
Date: August 2015
Contact: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
Description:
The zero_pages file is read-only and specifies number of zero
filled pages written to this disk. No memory is allocated for
such pages.
Now accessible via zram<id>/mm_stat node.
What: /sys/block/zram<id>/orig_data_size
Date: August 2015
Contact: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
Description:
The orig_data_size file is read-only and specifies uncompressed
size of data stored in this disk. This excludes zero-filled
pages (zero_pages) since no memory is allocated for them.
Unit: bytes
Now accessible via zram<id>/mm_stat node.
What: /sys/block/zram<id>/compr_data_size
Date: August 2015
Contact: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
Description:
The compr_data_size file is read-only and specifies compressed
size of data stored in this disk. So, compression ratio can be
calculated using orig_data_size and this statistic.
Unit: bytes
Now accessible via zram<id>/mm_stat node.
What: /sys/block/zram<id>/mem_used_total
Date: August 2015
Contact: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
Description:
The mem_used_total file is read-only and specifies the amount
of memory, including allocator fragmentation and metadata
overhead, allocated for this disk. So, allocator space
efficiency can be calculated using compr_data_size and this
statistic.
Unit: bytes
Now accessible via zram<id>/mm_stat node.
What: /sys/block/zram<id>/mem_used_max
Date: August 2015
Contact: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
Description:
The mem_used_max file is read/write and specifies the amount
of maximum memory zram have consumed to store compressed data.
For resetting the value, you should write "0". Otherwise,
you could see -EINVAL.
Unit: bytes
Downgraded to write-only node: so it's possible to set new
value only; its current value is stored in zram<id>/mm_stat
node.
What: /sys/block/zram<id>/mem_limit
Date: August 2015
Contact: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
Description:
The mem_limit file is read/write and specifies the maximum
amount of memory ZRAM can use to store the compressed data.
The limit could be changed in run time and "0" means disable
the limit. No limit is the initial state. Unit: bytes
Downgraded to write-only node: so it's possible to set new
value only; its current value is stored in zram<id>/mm_stat
node.

11
Documentation/ABI/stable/sysfs-bus-w1 Normal file
View File

@@ -0,0 +1,11 @@
What: /sys/bus/w1/devices/.../w1_master_timeout_us
Date: April 2015
Contact: Dmitry Khromov <dk@icelogic.net>
Description: Bus scanning interval, microseconds component.
Some of 1-Wire devices commonly associated with physical access
control systems are attached/generate presence for as short as
100 ms - hence the tens-to-hundreds milliseconds scan intervals
are required.
see Documentation/w1/w1.generic for detailed information.
Users: any user space application which wants to know bus scanning
interval

10
Documentation/ABI/stable/sysfs-devices Normal file
View File

@@ -0,0 +1,10 @@
# Note: This documents additional properties of any device beyond what
# is documented in Documentation/sysfs-rules.txt
What: /sys/devices/*/of_path
Date: February 2015
Contact: Device Tree mailing list <devicetree@vger.kernel.org>
Description:
Any device associated with a device-tree node will have
an of_path symlink pointing to the corresponding device
node in /sys/firmware/devicetree/

6
Documentation/ABI/stable/sysfs-driver-w1_ds28ea00 Normal file
View File

@@ -0,0 +1,6 @@
What: /sys/bus/w1/devices/.../w1_seq
Date: Apr 2015
Contact: Matt Campbell <mattrcampbell@gmail.com>
Description: Support for the DS28EA00 chain sequence function
see Documentation/w1/slaves/w1_therm for detailed information
Users: any user space application which wants to communicate with DS28EA00

2
Documentation/ABI/testing/configfs-spear-pcie-gadget
View File

@@ -1,7 +1,7 @@
What: /config/pcie-gadget
Date: Feb 2011
KernelVersion: 2.6.37
Contact: Pratyush Anand <pratyush.anand@st.com>
Contact: Pratyush Anand <pratyush.anand@gmail.com>
Description:
Interface is used to configure selected dual mode PCIe controller

9
Documentation/ABI/testing/configfs-usb-gadget-printer Normal file
View File

@@ -0,0 +1,9 @@
What: /config/usb-gadget/gadget/functions/printer.name
Date: Apr 2015
KernelVersion: 4.1
Description:
The attributes:
pnp_string - Data to be passed to the host in pnp string
q_len - Number of requests per endpoint

9
Documentation/ABI/testing/dev-kmsg
View File

@@ -98,4 +98,13 @@ Description: The /dev/kmsg character device node provides userspace access
logic is used internally when messages are printed to the
console, /proc/kmsg or the syslog() syscall.
By default, kernel tries to avoid fragments by concatenating
when it can and fragments are rare; however, when extended
console support is enabled, the in-kernel concatenation is
disabled and /dev/kmsg output will contain more fragments. If
the log consumer performs concatenation, the end result
should be the same. In the future, the in-kernel concatenation
may be removed entirely and /dev/kmsg users are recommended to
implement fragment handling.
Users: dmesg(1), userspace kernel log consumers

26
Documentation/ABI/testing/ima_policy
View File

@@ -20,17 +20,19 @@ Description:
action: measure | dont_measure | appraise | dont_appraise | audit
condition:= base | lsm [option]
base: [[func=] [mask=] [fsmagic=] [fsuuid=] [uid=]
[fowner]]
[euid=] [fowner=]]
lsm: [[subj_user=] [subj_role=] [subj_type=]
[obj_user=] [obj_role=] [obj_type=]]
option: [[appraise_type=]] [permit_directio]
base: func:= [BPRM_CHECK][MMAP_CHECK][FILE_CHECK][MODULE_CHECK]
[FIRMWARE_CHECK]
mask:= [MAY_READ] [MAY_WRITE] [MAY_APPEND] [MAY_EXEC]
mask:= [[^]MAY_READ] [[^]MAY_WRITE] [[^]MAY_APPEND]
[[^]MAY_EXEC]
fsmagic:= hex value
fsuuid:= file system UUID (e.g 8bcbe394-4f13-4144-be8e-5aa9ea2ce2f6)
uid:= decimal value
euid:= decimal value
fowner:=decimal value
lsm: are LSM specific
option: appraise_type:= [imasig]
@@ -49,11 +51,25 @@ Description:
dont_measure fsmagic=0x01021994
dont_appraise fsmagic=0x01021994
# RAMFS_MAGIC
dont_measure fsmagic=0x858458f6
dont_appraise fsmagic=0x858458f6
# DEVPTS_SUPER_MAGIC
dont_measure fsmagic=0x1cd1
dont_appraise fsmagic=0x1cd1
# BINFMTFS_MAGIC
dont_measure fsmagic=0x42494e4d
dont_appraise fsmagic=0x42494e4d
# SECURITYFS_MAGIC
dont_measure fsmagic=0x73636673
dont_appraise fsmagic=0x73636673
# SELINUX_MAGIC
dont_measure fsmagic=0xf97cff8c
dont_appraise fsmagic=0xf97cff8c
# CGROUP_SUPER_MAGIC
dont_measure fsmagic=0x27e0eb
dont_appraise fsmagic=0x27e0eb
# NSFS_MAGIC
dont_measure fsmagic=0x6e736673
dont_appraise fsmagic=0x6e736673
measure func=BPRM_CHECK
measure func=FILE_MMAP mask=MAY_EXEC
@@ -70,10 +86,6 @@ Description:
Examples of LSM specific definitions:
SELinux:
# SELINUX_MAGIC
dont_measure fsmagic=0xf97cff8c
dont_appraise fsmagic=0xf97cff8c
dont_measure obj_type=var_log_t
dont_appraise obj_type=var_log_t
dont_measure obj_type=auditd_log_t

11
Documentation/ABI/testing/sysfs-ata
View File

@@ -90,6 +90,17 @@ gscr
130: SATA_PMP_GSCR_SII_GPIO
Only valid if the device is a PM.
trim
Shows the DSM TRIM mode currently used by the device. Valid
values are:
unsupported: Drive does not support DSM TRIM
unqueued: Drive supports unqueued DSM TRIM only
queued: Drive supports queued DSM TRIM
forced_unqueued: Drive's queued DSM support is known to be
buggy and only unqueued TRIM commands
are sent
spdn_cnt
Number of time libata decided to lower the speed of link due to errors.

22
Documentation/ABI/testing/sysfs-block-dm
View File

@@ -23,3 +23,25 @@ Description: Device-mapper device suspend state.
Contains the value 1 while the device is suspended.
Otherwise it contains 0. Read-only attribute.
Users: util-linux, device-mapper udev rules
What: /sys/block/dm-<num>/dm/rq_based_seq_io_merge_deadline
Date: March 2015
KernelVersion: 4.1
Contact: dm-devel@redhat.com
Description: Allow control over how long a request that is a
reasonable merge candidate can be queued on the request
queue. The resolution of this deadline is in
microseconds (ranging from 1 to 100000 usecs).
Setting this attribute to 0 (the default) will disable
request-based DM's merge heuristic and associated extra
accounting. This attribute is not applicable to
bio-based DM devices so it will only ever report 0 for
them.
What: /sys/block/dm-<num>/dm/use_blk_mq
Date: March 2015
KernelVersion: 4.1
Contact: dm-devel@redhat.com
Description: Request-based Device-mapper blk-mq I/O path mode.
Contains the value 1 if the device is using blk-mq.
Otherwise it contains 0. Read-only attribute.

25
Documentation/ABI/testing/sysfs-block-zram
View File

@@ -141,3 +141,28 @@ Description:
amount of memory ZRAM can use to store the compressed data. The
limit could be changed in run time and "0" means disable the
limit. No limit is the initial state. Unit: bytes
What: /sys/block/zram<id>/compact
Date: August 2015
Contact: Minchan Kim <minchan@kernel.org>
Description:
The compact file is write-only and trigger compaction for
allocator zrm uses. The allocator moves some objects so that
it could free fragment space.
What: /sys/block/zram<id>/io_stat
Date: August 2015
Contact: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
Description:
The io_stat file is read-only and accumulates device's I/O
statistics not accounted by block layer. For example,
failed_reads, failed_writes, etc. File format is similar to
block layer statistics file format.
What: /sys/block/zram<id>/mm_stat
Date: August 2015
Contact: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
Description:
The mm_stat file is read-only and represents device's mm
statistics (orig_data_size, compr_data_size, etc.) in a format
similar to block layer statistics file format.

450
Documentation/ABI/testing/sysfs-bus-coresight-devices-etm4x Normal file
View File

@@ -0,0 +1,450 @@
What: /sys/bus/coresight/devices/<memory_map>.etm/enable_source
Date: April 2015
KernelVersion: 4.01
Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
Description: (RW) Enable/disable tracing on this specific trace entiry.
Enabling a source implies the source has been configured
properly and a sink has been identidifed for it. The path
of coresight components linking the source to the sink is
configured and managed automatically by the coresight framework.
What: /sys/bus/coresight/devices/<memory_map>.etm/cpu
Date: April 2015
KernelVersion: 4.01
Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
Description: (R) The CPU this tracing entity is associated with.
What: /sys/bus/coresight/devices/<memory_map>.etm/nr_pe_cmp
Date: April 2015
KernelVersion: 4.01
Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
Description: (R) Indicates the number of PE comparator inputs that are
available for tracing.
What: /sys/bus/coresight/devices/<memory_map>.etm/nr_addr_cmp
Date: April 2015
KernelVersion: 4.01
Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
Description: (R) Indicates the number of address comparator pairs that are
available for tracing.
What: /sys/bus/coresight/devices/<memory_map>.etm/nr_cntr
Date: April 2015
KernelVersion: 4.01
Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
Description: (R) Indicates the number of counters that are available for
tracing.
What: /sys/bus/coresight/devices/<memory_map>.etm/nr_ext_inp
Date: April 2015
KernelVersion: 4.01
Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
Description: (R) Indicates how many external inputs are implemented.
What: /sys/bus/coresight/devices/<memory_map>.etm/numcidc
Date: April 2015
KernelVersion: 4.01
Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
Description: (R) Indicates the number of Context ID comparators that are
available for tracing.
What: /sys/bus/coresight/devices/<memory_map>.etm/numvmidc
Date: April 2015
KernelVersion: 4.01
Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
Description: (R) Indicates the number of VMID comparators that are available
for tracing.
What: /sys/bus/coresight/devices/<memory_map>.etm/nrseqstate
Date: April 2015
KernelVersion: 4.01
Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
Description: (R) Indicates the number of sequencer states that are
implemented.
What: /sys/bus/coresight/devices/<memory_map>.etm/nr_resource
Date: April 2015
KernelVersion: 4.01
Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
Description: (R) Indicates the number of resource selection pairs that are
available for tracing.
What: /sys/bus/coresight/devices/<memory_map>.etm/nr_ss_cmp
Date: April 2015
KernelVersion: 4.01
Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
Description: (R) Indicates the number of single-shot comparator controls that
are available for tracing.
What: /sys/bus/coresight/devices/<memory_map>.etm/reset
Date: April 2015
KernelVersion: 4.01
Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
Description: (W) Cancels all configuration on a trace unit and set it back
to its boot configuration.
What: /sys/bus/coresight/devices/<memory_map>.etm/mode
Date: April 2015
KernelVersion: 4.01
Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
Description: (RW) Controls various modes supported by this ETM, for example
P0 instruction tracing, branch broadcast, cycle counting and
context ID tracing.
What: /sys/bus/coresight/devices/<memory_map>.etm/pe
Date: April 2015
KernelVersion: 4.01
Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
Description: (RW) Controls which PE to trace.
What: /sys/bus/coresight/devices/<memory_map>.etm/event
Date: April 2015
KernelVersion: 4.01
Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
Description: (RW) Controls the tracing of arbitrary events from bank 0 to 3.
What: /sys/bus/coresight/devices/<memory_map>.etm/event_instren
Date: April 2015
KernelVersion: 4.01
Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
Description: (RW) Controls the behavior of the events in bank 0 to 3.
What: /sys/bus/coresight/devices/<memory_map>.etm/event_ts
Date: April 2015
KernelVersion: 4.01
Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
Description: (RW) Controls the insertion of global timestamps in the trace
streams.
What: /sys/bus/coresight/devices/<memory_map>.etm/syncfreq
Date: April 2015
KernelVersion: 4.01
Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
Description: (RW) Controls how often trace synchronization requests occur.
What: /sys/bus/coresight/devices/<memory_map>.etm/cyc_threshold
Date: April 2015
KernelVersion: 4.01
Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
Description: (RW) Sets the threshold value for cycle counting.
What: /sys/bus/coresight/devices/<memory_map>.etm/bb_ctrl
Date: April 2015
KernelVersion: 4.01
Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
Description: (RW) Controls which regions in the memory map are enabled to
use branch broadcasting.
What: /sys/bus/coresight/devices/<memory_map>.etm/event_vinst
Date: April 2015
KernelVersion: 4.01
Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
Description: (RW) Controls instruction trace filtering.
What: /sys/bus/coresight/devices/<memory_map>.etm/s_exlevel_vinst
Date: April 2015
KernelVersion: 4.01
Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
Description: (RW) In Secure state, each bit controls whether instruction
tracing is enabled for the corresponding exception level.
What: /sys/bus/coresight/devices/<memory_map>.etm/ns_exlevel_vinst
Date: April 2015
KernelVersion: 4.01
Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
Description: (RW) In non-secure state, each bit controls whether instruction
tracing is enabled for the corresponding exception level.
What: /sys/bus/coresight/devices/<memory_map>.etm/addr_idx
Date: April 2015
KernelVersion: 4.01
Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
Description: (RW) Select which address comparator or pair (of comparators) to
work with.
What: /sys/bus/coresight/devices/<memory_map>.etm/addr_instdatatype
Date: April 2015
KernelVersion: 4.01
Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
Description: (RW) Controls what type of comparison the trace unit performs.
What: /sys/bus/coresight/devices/<memory_map>.etm/addr_single
Date: April 2015
KernelVersion: 4.01
Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
Description: (RW) Used to setup single address comparator values.
What: /sys/bus/coresight/devices/<memory_map>.etm/addr_range
Date: April 2015
KernelVersion: 4.01
Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
Description: (RW) Used to setup address range comparator values.
What: /sys/bus/coresight/devices/<memory_map>.etm/seq_idx
Date: April 2015
KernelVersion: 4.01
Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
Description: (RW) Select which sequensor.
What: /sys/bus/coresight/devices/<memory_map>.etm/seq_state
Date: April 2015
KernelVersion: 4.01
Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
Description: (RW) Use this to set, or read, the sequencer state.
What: /sys/bus/coresight/devices/<memory_map>.etm/seq_event
Date: April 2015
KernelVersion: 4.01
Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
Description: (RW) Moves the sequencer state to a specific state.
What: /sys/bus/coresight/devices/<memory_map>.etm/seq_reset_event
Date: April 2015
KernelVersion: 4.01
Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
Description: (RW) Moves the sequencer to state 0 when a programmed event
occurs.
What: /sys/bus/coresight/devices/<memory_map>.etm/cntr_idx
Date: April 2015
KernelVersion: 4.01
Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
Description: (RW) Select which counter unit to work with.
What: /sys/bus/coresight/devices/<memory_map>.etm/cntrldvr
Date: April 2015
KernelVersion: 4.01
Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
Description: (RW) This sets or returns the reload count value of the
specific counter.
What: /sys/bus/coresight/devices/<memory_map>.etm/cntr_val
Date: April 2015
KernelVersion: 4.01
Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
Description: (RW) This sets or returns the current count value of the
specific counter.
What: /sys/bus/coresight/devices/<memory_map>.etm/cntr_ctrl
Date: April 2015
KernelVersion: 4.01
Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
Description: (RW) Controls the operation of the selected counter.
What: /sys/bus/coresight/devices/<memory_map>.etm/res_idx
Date: April 2015
KernelVersion: 4.01
Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
Description: (RW) Select which resource selection unit to work with.
What: /sys/bus/coresight/devices/<memory_map>.etm/res_ctrl
Date: April 2015
KernelVersion: 4.01
Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
Description: (RW) Controls the selection of the resources in the trace unit.
What: /sys/bus/coresight/devices/<memory_map>.etm/ctxid_idx
Date: April 2015
KernelVersion: 4.01
Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
Description: (RW) Select which context ID comparator to work with.
What: /sys/bus/coresight/devices/<memory_map>.etm/ctxid_val
Date: April 2015
KernelVersion: 4.01
Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
Description: (RW) Get/Set the context ID comparator value to trigger on.
What: /sys/bus/coresight/devices/<memory_map>.etm/ctxid_masks
Date: April 2015
KernelVersion: 4.01
Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
Description: (RW) Mask for all 8 context ID comparator value
registers (if implemented).
What: /sys/bus/coresight/devices/<memory_map>.etm/vmid_idx
Date: April 2015
KernelVersion: 4.01
Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
Description: (RW) Select which virtual machine ID comparator to work with.
What: /sys/bus/coresight/devices/<memory_map>.etm/vmid_val
Date: April 2015
KernelVersion: 4.01
Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
Description: (RW) Get/Set the virtual machine ID comparator value to
trigger on.
What: /sys/bus/coresight/devices/<memory_map>.etm/vmid_masks
Date: April 2015
KernelVersion: 4.01
Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
Description: (RW) Mask for all 8 virtual machine ID comparator value
registers (if implemented).
What: /sys/bus/coresight/devices/<memory_map>.etm/mgmt/trcoslsr
Date: April 2015
KernelVersion: 4.01
Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
Description: (R) Print the content of the OS Lock Status Register (0x304).
The value it taken directly from the HW.
What: /sys/bus/coresight/devices/<memory_map>.etm/mgmt/trcpdcr
Date: April 2015
KernelVersion: 4.01
Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
Description: (R) Print the content of the Power Down Control Register
(0x310). The value is taken directly from the HW.
What: /sys/bus/coresight/devices/<memory_map>.etm/mgmt/trcpdsr
Date: April 2015
KernelVersion: 4.01
Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
Description: (R) Print the content of the Power Down Status Register
(0x314). The value is taken directly from the HW.
What: /sys/bus/coresight/devices/<memory_map>.etm/mgmt/trclsr
Date: April 2015
KernelVersion: 4.01
Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
Description: (R) Print the content of the SW Lock Status Register
(0xFB4). The value is taken directly from the HW.
What: /sys/bus/coresight/devices/<memory_map>.etm/mgmt/trcauthstatus
Date: April 2015
KernelVersion: 4.01
Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
Description: (R) Print the content of the Authentication Status Register
(0xFB8). The value is taken directly from the HW.
What: /sys/bus/coresight/devices/<memory_map>.etm/mgmt/trcdevid
Date: April 2015
KernelVersion: 4.01
Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
Description: (R) Print the content of the Device ID Register
(0xFC8). The value is taken directly from the HW.
What: /sys/bus/coresight/devices/<memory_map>.etm/mgmt/trcdevtype
Date: April 2015
KernelVersion: 4.01
Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
Description: (R) Print the content of the Device Type Register
(0xFCC). The value is taken directly from the HW.
What: /sys/bus/coresight/devices/<memory_map>.etm/mgmt/trcpidr0
Date: April 2015
KernelVersion: 4.01
Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
Description: (R) Print the content of the Peripheral ID0 Register
(0xFE0). The value is taken directly from the HW.
What: /sys/bus/coresight/devices/<memory_map>.etm/mgmt/trcpidr1
Date: April 2015
KernelVersion: 4.01
Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
Description: (R) Print the content of the Peripheral ID1 Register
(0xFE4). The value is taken directly from the HW.
What: /sys/bus/coresight/devices/<memory_map>.etm/mgmt/trcpidr2
Date: April 2015
KernelVersion: 4.01
Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
Description: (R) Print the content of the Peripheral ID2 Register
(0xFE8). The value is taken directly from the HW.
What: /sys/bus/coresight/devices/<memory_map>.etm/mgmt/trcpidr3
Date: April 2015
KernelVersion: 4.01
Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
Description: (R) Print the content of the Peripheral ID3 Register
(0xFEC). The value is taken directly from the HW.
What: /sys/bus/coresight/devices/<memory_map>.etm/trcidr/trcidr0
Date: April 2015
KernelVersion: 4.01
Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
Description: (R) Returns the tracing capabilities of the trace unit (0x1E0).
The value is taken directly from the HW.
What: /sys/bus/coresight/devices/<memory_map>.etm/trcidr/trcidr1
Date: April 2015
KernelVersion: 4.01
Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
Description: (R) Returns the tracing capabilities of the trace unit (0x1E4).
The value is taken directly from the HW.
What: /sys/bus/coresight/devices/<memory_map>.etm/trcidr/trcidr2
Date: April 2015
KernelVersion: 4.01
Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
Description: (R) Returns the maximum size of the data value, data address,
VMID, context ID and instuction address in the trace unit
(0x1E8). The value is taken directly from the HW.
What: /sys/bus/coresight/devices/<memory_map>.etm/trcidr/trcidr3
Date: April 2015
KernelVersion: 4.01
Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
Description: (R) Returns the value associated with various resources
available to the trace unit. See the Trace Macrocell
architecture specification for more details (0x1E8).
The value is taken directly from the HW.
What: /sys/bus/coresight/devices/<memory_map>.etm/trcidr/trcidr4
Date: April 2015
KernelVersion: 4.01
Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
Description: (R) Returns how many resources the trace unit supports (0x1F0).
The value is taken directly from the HW.
What: /sys/bus/coresight/devices/<memory_map>.etm/trcidr/trcidr5
Date: April 2015
KernelVersion: 4.01
Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
Description: (R) Returns how many resources the trace unit supports (0x1F4).
The value is taken directly from the HW.
What: /sys/bus/coresight/devices/<memory_map>.etm/trcidr/trcidr8
Date: April 2015
KernelVersion: 4.01
Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
Description: (R) Returns the maximum speculation depth of the instruction
trace stream. (0x180). The value is taken directly from the HW.
What: /sys/bus/coresight/devices/<memory_map>.etm/trcidr/trcidr9
Date: April 2015
KernelVersion: 4.01
Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
Description: (R) Returns the number of P0 right-hand keys that the trace unit
can use (0x184). The value is taken directly from the HW.
What: /sys/bus/coresight/devices/<memory_map>.etm/trcidr/trcidr10
Date: April 2015
KernelVersion: 4.01
Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
Description: (R) Returns the number of P1 right-hand keys that the trace unit
can use (0x188). The value is taken directly from the HW.
What: /sys/bus/coresight/devices/<memory_map>.etm/trcidr/trcidr11
Date: April 2015
KernelVersion: 4.01
Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
Description: (R) Returns the number of special P1 right-hand keys that the
trace unit can use (0x18C). The value is taken directly from
the HW.
What: /sys/bus/coresight/devices/<memory_map>.etm/trcidr/trcidr12
Date: April 2015
KernelVersion: 4.01
Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
Description: (R) Returns the number of conditional P1 right-hand keys that
the trace unit can use (0x190). The value is taken directly
from the HW.
What: /sys/bus/coresight/devices/<memory_map>.etm/trcidr/trcidr13
Date: April 2015
KernelVersion: 4.01
Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
Description: (R) Returns the number of special conditional P1 right-hand keys
that the trace unit can use (0x194). The value is taken
directly from the HW.

12
Documentation/ABI/testing/sysfs-bus-fcoe
View File

@@ -32,7 +32,7 @@ Description: 'FCoE Controller' instances on the fcoe bus.
Attributes:
fcf_dev_loss_tmo: Device loss timeout peroid (see below). Changing
fcf_dev_loss_tmo: Device loss timeout period (see below). Changing
this value will change the dev_loss_tmo for all
FCFs discovered by this controller.
@@ -61,7 +61,7 @@ Attributes:
lesb/err_block: Link Error Status Block (LESB) block error count.
lesb/fcs_error: Link Error Status Block (LESB) Fibre Channel
Serivces error count.
Services error count.
Notes: ctlr_X (global increment starting at 0)
@@ -85,7 +85,7 @@ Attributes:
fabric.
selected: 1 indicates that the switch has been selected for use;
0 indicates that the swich will not be used.
0 indicates that the switch will not be used.
fc_map: The Fibre Channel MAP
@@ -93,7 +93,7 @@ Attributes:
mac: The FCF's MAC address
fka_peroid: The FIP Keep-Alive peroid
fka_period: The FIP Keep-Alive period
fabric_state: The internal kernel state
"Unknown" - Initialization value
@@ -101,9 +101,9 @@ Attributes:
"Connected" - Host is connected to the FCF
"Deleted" - FCF is being removed from the system
dev_loss_tmo: The device loss timeout peroid for this FCF.
dev_loss_tmo: The device loss timeout period for this FCF.
Notes: A device loss infrastructre similar to the FC Transport's
Notes: A device loss infrastructure similar to the FC Transport's
is present in fcoe_sysfs. It is nice to have so that a
link flapping adapter doesn't continually advance the count
used to identify the discovered FCF. FCFs will exist in a

242
Documentation/ABI/testing/sysfs-bus-iio
View File

@@ -71,6 +71,8 @@ Description:
What: /sys/bus/iio/devices/iio:deviceX/in_voltageY_raw
What: /sys/bus/iio/devices/iio:deviceX/in_voltageY_supply_raw
What: /sys/bus/iio/devices/iio:deviceX/in_voltageY_i_raw
What: /sys/bus/iio/devices/iio:deviceX/in_voltageY_q_raw
KernelVersion: 2.6.35
Contact: linux-iio@vger.kernel.org
Description:
@@ -81,6 +83,11 @@ Description:
unique to allow association with event codes. Units after
application of scale and offset are millivolts.
Channels with 'i' and 'q' modifiers always exist in pairs and both
channels refer to the same signal. The 'i' channel contains the in-phase
component of the signal while the 'q' channel contains the quadrature
component.
What: /sys/bus/iio/devices/iio:deviceX/in_voltageY-voltageZ_raw
KernelVersion: 2.6.35
Contact: linux-iio@vger.kernel.org
@@ -246,13 +253,23 @@ What: /sys/bus/iio/devices/iio:deviceX/in_accel_y_offset
What: /sys/bus/iio/devices/iio:deviceX/in_accel_z_offset
What: /sys/bus/iio/devices/iio:deviceX/in_voltageY_offset
What: /sys/bus/iio/devices/iio:deviceX/in_voltage_offset
What: /sys/bus/iio/devices/iio:deviceX/in_voltageY_i_offset
What: /sys/bus/iio/devices/iio:deviceX/in_voltageY_q_offset
What: /sys/bus/iio/devices/iio:deviceX/in_voltage_q_offset
What: /sys/bus/iio/devices/iio:deviceX/in_voltage_i_offset
What: /sys/bus/iio/devices/iio:deviceX/in_currentY_offset
What: /sys/bus/iio/devices/iio:deviceX/in_current_offset
What: /sys/bus/iio/devices/iio:deviceX/in_currentY_i_offset
What: /sys/bus/iio/devices/iio:deviceX/in_currentY_q_offset
What: /sys/bus/iio/devices/iio:deviceX/in_current_q_offset
What: /sys/bus/iio/devices/iio:deviceX/in_current_i_offset
What: /sys/bus/iio/devices/iio:deviceX/in_tempY_offset
What: /sys/bus/iio/devices/iio:deviceX/in_temp_offset
What: /sys/bus/iio/devices/iio:deviceX/in_pressureY_offset
What: /sys/bus/iio/devices/iio:deviceX/in_pressure_offset
What: /sys/bus/iio/devices/iio:deviceX/in_humidityrelative_offset
What: /sys/bus/iio/devices/iio:deviceX/in_magn_offset
What: /sys/bus/iio/devices/iio:deviceX/in_rot_offset
KernelVersion: 2.6.35
Contact: linux-iio@vger.kernel.org
Description:
@@ -271,14 +288,22 @@ Description:
to the _raw output.
What: /sys/bus/iio/devices/iio:deviceX/in_voltageY_scale
What: /sys/bus/iio/devices/iio:deviceX/in_voltageY_i_scale
What: /sys/bus/iio/devices/iio:deviceX/in_voltageY_q_scale
What: /sys/bus/iio/devices/iio:deviceX/in_voltageY_supply_scale
What: /sys/bus/iio/devices/iio:deviceX/in_voltage_scale
What: /sys/bus/iio/devices/iio:deviceX/in_voltage_i_scale
What: /sys/bus/iio/devices/iio:deviceX/in_voltage_q_scale
What: /sys/bus/iio/devices/iio:deviceX/in_voltage-voltage_scale
What: /sys/bus/iio/devices/iio:deviceX/out_voltageY_scale
What: /sys/bus/iio/devices/iio:deviceX/out_altvoltageY_scale
What: /sys/bus/iio/devices/iio:deviceX/in_currentY_scale
What: /sys/bus/iio/devices/iio:deviceX/in_currentY_supply_scale
What: /sys/bus/iio/devices/iio:deviceX/in_current_scale
What: /sys/bus/iio/devices/iio:deviceX/in_currentY_i_scale
What: /sys/bus/iio/devices/iio:deviceX/in_currentY_q_scale
What: /sys/bus/iio/devices/iio:deviceX/in_current_i_scale
What: /sys/bus/iio/devices/iio:deviceX/in_current_q_scale
What: /sys/bus/iio/devices/iio:deviceX/in_accel_scale
What: /sys/bus/iio/devices/iio:deviceX/in_accel_peak_scale
What: /sys/bus/iio/devices/iio:deviceX/in_anglvel_scale
@@ -296,6 +321,7 @@ What: /sys/bus/iio/devices/iio:deviceX/in_pressureY_scale
What: /sys/bus/iio/devices/iio:deviceX/in_pressure_scale
What: /sys/bus/iio/devices/iio:deviceX/in_humidityrelative_scale
What: /sys/bus/iio/devices/iio:deviceX/in_velocity_sqrt(x^2+y^2+z^2)_scale
What: /sys/bus/iio/devices/iio:deviceX/in_illuminance_scale
KernelVersion: 2.6.35
Contact: linux-iio@vger.kernel.org
Description:
@@ -325,6 +351,10 @@ Description:
What /sys/bus/iio/devices/iio:deviceX/in_voltageY_calibscale
What /sys/bus/iio/devices/iio:deviceX/in_voltageY_supply_calibscale
What /sys/bus/iio/devices/iio:deviceX/in_voltageY_i_calibscale
What /sys/bus/iio/devices/iio:deviceX/in_voltageY_q_calibscale
What /sys/bus/iio/devices/iio:deviceX/in_voltage_i_calibscale
What /sys/bus/iio/devices/iio:deviceX/in_voltage_q_calibscale
What /sys/bus/iio/devices/iio:deviceX/in_voltage_calibscale
What /sys/bus/iio/devices/iio:deviceX/in_accel_x_calibscale
What /sys/bus/iio/devices/iio:deviceX/in_accel_y_calibscale
@@ -336,6 +366,7 @@ what /sys/bus/iio/devices/iio:deviceX/in_illuminance0_calibscale
what /sys/bus/iio/devices/iio:deviceX/in_proximity0_calibscale
What: /sys/bus/iio/devices/iio:deviceX/in_pressureY_calibscale
What: /sys/bus/iio/devices/iio:deviceX/in_pressure_calibscale
What: /sys/bus/iio/devices/iio:deviceX/in_illuminance_calibscale
KernelVersion: 2.6.35
Contact: linux-iio@vger.kernel.org
Description:
@@ -347,7 +378,7 @@ What: /sys/bus/iio/devices/iio:deviceX/in_activity_calibgender
What: /sys/bus/iio/devices/iio:deviceX/in_energy_calibgender
What: /sys/bus/iio/devices/iio:deviceX/in_distance_calibgender
What: /sys/bus/iio/devices/iio:deviceX/in_velocity_calibgender
KernelVersion: 3.20
KernelVersion: 4.0
Contact: linux-iio@vger.kernel.org
Description:
Gender of the user (e.g.: male, female) used by some pedometers
@@ -358,7 +389,7 @@ What: /sys/bus/iio/devices/iio:deviceX/in_activity_calibgender_available
What: /sys/bus/iio/devices/iio:deviceX/in_energy_calibgender_available
What: /sys/bus/iio/devices/iio:deviceX/in_distance_calibgender_available
What: /sys/bus/iio/devices/iio:deviceX/in_velocity_calibgender_available
KernelVersion: 3.20
KernelVersion: 4.0
Contact: linux-iio@vger.kernel.org
Description:
Lists all available gender values (e.g.: male, female).
@@ -375,7 +406,7 @@ Description:
type.
What: /sys/bus/iio/devices/iio:deviceX/in_energy_calibweight
KernelVersion: 3.20
KernelVersion: 4.0
Contact: linux-iio@vger.kernel.org
Description:
Weight of the user (in kg). It is needed by some pedometers
@@ -416,6 +447,16 @@ Description:
to the underlying data channel, then this parameter
gives the 3dB frequency of the filter in Hz.
What: /sys/.../in_accel_filter_high_pass_3db_frequency
What: /sys/.../in_anglvel_filter_high_pass_3db_frequency
What: /sys/.../in_magn_filter_high_pass_3db_frequency
KernelVersion: 4.2
Contact: linux-iio@vger.kernel.org
Description:
If a known or controllable high pass filter is applied
to the underlying data channel, then this parameter
gives the 3dB frequency of the filter in Hz.
What: /sys/bus/iio/devices/iio:deviceX/out_voltageY_raw
What: /sys/bus/iio/devices/iio:deviceX/out_altvoltageY_raw
KernelVersion: 2.6.37
@@ -612,6 +653,8 @@ Description:
a given event type is enabled a future point (and not those for
whatever event was previously enabled).
What: /sys/.../events/in_accel_thresh_rising_value
What: /sys/.../events/in_accel_thresh_falling_value
What: /sys/.../events/in_accel_x_raw_thresh_rising_value
What: /sys/.../events/in_accel_x_raw_thresh_falling_value
What: /sys/.../events/in_accel_y_raw_thresh_rising_value
@@ -661,6 +704,24 @@ Description:
value is in raw device units or in processed units (as _raw
and _input do on sysfs direct channel read attributes).
What: /sys/.../events/in_accel_scale
What: /sys/.../events/in_accel_peak_scale
What: /sys/.../events/in_anglvel_scale
What: /sys/.../events/in_magn_scale
What: /sys/.../events/in_rot_from_north_magnetic_scale
What: /sys/.../events/in_rot_from_north_true_scale
What: /sys/.../events/in_voltage_scale
What: /sys/.../events/in_voltage_supply_scale
What: /sys/.../events/in_temp_scale
What: /sys/.../events/in_illuminance_scale
What: /sys/.../events/in_proximity_scale
KernelVersion: 3.21
Contact: linux-iio@vger.kernel.org
Description:
Specifies the conversion factor from the standard units
to device specific units used to set the event trigger
threshold.
What: /sys/.../events/in_accel_x_thresh_rising_hysteresis
What: /sys/.../events/in_accel_x_thresh_falling_hysteresis
What: /sys/.../events/in_accel_x_thresh_either_hysteresis
@@ -776,7 +837,7 @@ Description:
What: /sys/.../events/in_accel_x_thresh_rising_period
What: /sys/.../events/in_accel_x_thresh_falling_period
hat: /sys/.../events/in_accel_x_roc_rising_period
What: /sys/.../events/in_accel_x_roc_rising_period
What: /sys/.../events/in_accel_x_roc_falling_period
What: /sys/.../events/in_accel_y_thresh_rising_period
What: /sys/.../events/in_accel_y_thresh_falling_period
@@ -856,6 +917,26 @@ Description:
met before an event is generated. If direction is not
specified then this period applies to both directions.
What: /sys/.../events/in_accel_thresh_rising_low_pass_filter_3db
What: /sys/.../events/in_anglvel_thresh_rising_low_pass_filter_3db
What: /sys/.../events/in_magn_thresh_rising_low_pass_filter_3db
KernelVersion: 4.2
Contact: linux-iio@vger.kernel.org
Description:
If a low pass filter can be applied to the event generation
this property gives its 3db frequency in Hz.
A value of zero disables the filter.
What: /sys/.../events/in_accel_thresh_rising_high_pass_filter_3db
What: /sys/.../events/in_anglvel_thresh_rising_high_pass_filter_3db
What: /sys/.../events/in_magn_thresh_rising_high_pass_filter_3db
KernelVersion: 4.2
Contact: linux-iio@vger.kernel.org
Description:
If a high pass filter can be applied to the event generation
this property gives its 3db frequency in Hz.
A value of zero disables the filter.
What: /sys/.../events/in_activity_still_thresh_rising_en
What: /sys/.../events/in_activity_still_thresh_falling_en
What: /sys/.../events/in_activity_walking_thresh_rising_en
@@ -923,7 +1004,7 @@ Description:
this type.
What: /sys/.../events/in_steps_change_en
KernelVersion: 3.20
KernelVersion: 4.0
Contact: linux-iio@vger.kernel.org
Description:
Event generated when channel passes a threshold on the absolute
@@ -932,7 +1013,7 @@ Description:
in_steps_change_value.
What: /sys/.../events/in_steps_change_value
KernelVersion: 3.20
KernelVersion: 4.0
Contact: linux-iio@vger.kernel.org
Description:
Specifies the value of change threshold that the
@@ -992,11 +1073,16 @@ What: /sys/.../iio:deviceX/scan_elements/in_timestamp_en
What: /sys/.../iio:deviceX/scan_elements/in_voltageY_supply_en
What: /sys/.../iio:deviceX/scan_elements/in_voltageY_en
What: /sys/.../iio:deviceX/scan_elements/in_voltageY-voltageZ_en
What: /sys/.../iio:deviceX/scan_elements/in_voltageY_i_en
What: /sys/.../iio:deviceX/scan_elements/in_voltageY_q_en
What: /sys/.../iio:deviceX/scan_elements/in_voltage_i_en
What: /sys/.../iio:deviceX/scan_elements/in_voltage_q_en
What: /sys/.../iio:deviceX/scan_elements/in_incli_x_en
What: /sys/.../iio:deviceX/scan_elements/in_incli_y_en
What: /sys/.../iio:deviceX/scan_elements/in_pressureY_en
What: /sys/.../iio:deviceX/scan_elements/in_pressure_en
What: /sys/.../iio:deviceX/scan_elements/in_rot_quaternion_en
What: /sys/.../iio:deviceX/scan_elements/in_proximity_en
KernelVersion: 2.6.37
Contact: linux-iio@vger.kernel.org
Description:
@@ -1009,10 +1095,15 @@ What: /sys/.../iio:deviceX/scan_elements/in_incli_type
What: /sys/.../iio:deviceX/scan_elements/in_voltageY_type
What: /sys/.../iio:deviceX/scan_elements/in_voltage_type
What: /sys/.../iio:deviceX/scan_elements/in_voltageY_supply_type
What: /sys/.../iio:deviceX/scan_elements/in_voltageY_i_type
What: /sys/.../iio:deviceX/scan_elements/in_voltageY_q_type
What: /sys/.../iio:deviceX/scan_elements/in_voltage_i_type
What: /sys/.../iio:deviceX/scan_elements/in_voltage_q_type
What: /sys/.../iio:deviceX/scan_elements/in_timestamp_type
What: /sys/.../iio:deviceX/scan_elements/in_pressureY_type
What: /sys/.../iio:deviceX/scan_elements/in_pressure_type
What: /sys/.../iio:deviceX/scan_elements/in_rot_quaternion_type
What: /sys/.../iio:deviceX/scan_elements/in_proximity_type
KernelVersion: 2.6.37
Contact: linux-iio@vger.kernel.org
Description:
@@ -1045,6 +1136,10 @@ Description:
What: /sys/.../iio:deviceX/scan_elements/in_voltageY_index
What: /sys/.../iio:deviceX/scan_elements/in_voltageY_supply_index
What: /sys/.../iio:deviceX/scan_elements/in_voltageY_i_index
What: /sys/.../iio:deviceX/scan_elements/in_voltageY_q_index
What: /sys/.../iio:deviceX/scan_elements/in_voltage_i_index
What: /sys/.../iio:deviceX/scan_elements/in_voltage_q_index
What: /sys/.../iio:deviceX/scan_elements/in_accel_x_index
What: /sys/.../iio:deviceX/scan_elements/in_accel_y_index
What: /sys/.../iio:deviceX/scan_elements/in_accel_z_index
@@ -1064,6 +1159,7 @@ What: /sys/.../iio:deviceX/scan_elements/in_timestamp_index
What: /sys/.../iio:deviceX/scan_elements/in_pressureY_index
What: /sys/.../iio:deviceX/scan_elements/in_pressure_index
What: /sys/.../iio:deviceX/scan_elements/in_rot_quaternion_index
What: /sys/.../iio:deviceX/scan_elements/in_proximity_index
KernelVersion: 2.6.37
Contact: linux-iio@vger.kernel.org
Description:
@@ -1104,7 +1200,7 @@ Description:
What: /sys/.../iio:deviceX/in_energy_input
What: /sys/.../iio:deviceX/in_energy_raw
KernelVersion: 3.20
KernelVersion: 4.0
Contact: linux-iio@vger.kernel.org
Description:
This attribute is used to read the energy value reported by the
@@ -1113,7 +1209,7 @@ Description:
What: /sys/.../iio:deviceX/in_distance_input
What: /sys/.../iio:deviceX/in_distance_raw
KernelVersion: 3.20
KernelVersion: 4.0
Contact: linux-iio@vger.kernel.org
Description:
This attribute is used to read the distance covered by the user
@@ -1138,14 +1234,16 @@ Description:
object is near the sensor, usually be observing
reflectivity of infrared or ultrasound emitted.
Often these sensors are unit less and as such conversion
to SI units is not possible. Where it is, the units should
be meters. If such a conversion is not possible, the reported
values should behave in the same way as a distance, i.e. lower
values indicate something is closer to the sensor.
to SI units is not possible. Higher proximity measurements
indicate closer objects, and vice versa.
What: /sys/.../iio:deviceX/in_illuminance_input
What: /sys/.../iio:deviceX/in_illuminance_raw
What: /sys/.../iio:deviceX/in_illuminanceY_input
What: /sys/.../iio:deviceX/in_illuminanceY_raw
What: /sys/.../iio:deviceX/in_illuminanceY_mean_raw
What: /sys/.../iio:deviceX/in_illuminance_ir_raw
What: /sys/.../iio:deviceX/in_illuminance_clear_raw
KernelVersion: 3.4
Contact: linux-iio@vger.kernel.org
Description:
@@ -1174,7 +1272,7 @@ Description:
seconds.
What: /sys/.../iio:deviceX/in_velocity_sqrt(x^2+y^2+z^2)_integration_time
KernelVersion: 3.20
KernelVersion: 4.0
Contact: linux-iio@vger.kernel.org
Description:
Number of seconds in which to compute speed.
@@ -1199,6 +1297,8 @@ Description:
or without compensation from tilt sensors.
What: /sys/bus/iio/devices/iio:deviceX/in_currentX_raw
What: /sys/bus/iio/devices/iio:deviceX/in_currentX_i_raw
What: /sys/bus/iio/devices/iio:deviceX/in_currentX_q_raw
KernelVersion: 3.18
Contact: linux-iio@vger.kernel.org
Description:
@@ -1207,6 +1307,11 @@ Description:
present, output should be considered as processed with the
unit in milliamps.
Channels with 'i' and 'q' modifiers always exist in pairs and both
channels refer to the same signal. The 'i' channel contains the in-phase
component of the signal while the 'q' channel contains the quadrature
component.
What: /sys/.../iio:deviceX/in_energy_en
What: /sys/.../iio:deviceX/in_distance_en
What: /sys/.../iio:deviceX/in_velocity_sqrt(x^2+y^2+z^2)_en
@@ -1236,7 +1341,7 @@ Description:
Units after application of scale are m/s.
What: /sys/.../iio:deviceX/in_steps_debounce_count
KernelVersion: 3.20
KernelVersion: 4.0
Contact: linux-iio@vger.kernel.org
Description:
Specifies the number of steps that must occur within
@@ -1244,8 +1349,115 @@ Description:
consumer is making steps.
What: /sys/.../iio:deviceX/in_steps_debounce_time
KernelVersion: 3.20
KernelVersion: 4.0
Contact: linux-iio@vger.kernel.org
Description:
Specifies number of seconds in which we compute the steps
that occur in order to decide if the consumer is making steps.
What: /sys/bus/iio/devices/iio:deviceX/buffer/watermark
KernelVersion: 4.2
Contact: linux-iio@vger.kernel.org
Description:
A single positive integer specifying the maximum number of scan
elements to wait for.
Poll will block until the watermark is reached.
Blocking read will wait until the minimum between the requested
read amount or the low water mark is available.
Non-blocking read will retrieve the available samples from the
buffer even if there are less samples then watermark level. This
allows the application to block on poll with a timeout and read
the available samples after the timeout expires and thus have a
maximum delay guarantee.
What: /sys/bus/iio/devices/iio:deviceX/buffer/hwfifo_enabled
KernelVersion: 4.2
Contact: linux-iio@vger.kernel.org
Description:
A read-only boolean value that indicates if the hardware fifo is
currently enabled or disabled. If the device does not have a
hardware fifo this entry is not present.
The hardware fifo is enabled when the buffer is enabled if the
current hardware fifo watermark level is set and other current
device settings allows it (e.g. if a trigger is set that samples
data differently that the hardware fifo does then hardware fifo
will not enabled).
If the hardware fifo is enabled and the level of the hardware
fifo reaches the hardware fifo watermark level the device will
flush its hardware fifo to the device buffer. Doing a non
blocking read on the device when no samples are present in the
device buffer will also force a flush.
When the hardware fifo is enabled there is no need to use a
trigger to use buffer mode since the watermark settings
guarantees that the hardware fifo is flushed to the device
buffer.
What: /sys/bus/iio/devices/iio:deviceX/buffer/hwfifo_watermark
KernelVersion: 4.2
Contact: linux-iio@vger.kernel.org
Description:
Read-only entry that contains a single integer specifying the
current watermark level for the hardware fifo. If the device
does not have a hardware fifo this entry is not present.
The watermark level for the hardware fifo is set by the driver
based on the value set by the user in buffer/watermark but
taking into account hardware limitations (e.g. most hardware
buffers are limited to 32-64 samples, some hardware buffers
watermarks are fixed or have minimum levels). A value of 0
means that the hardware watermark is unset.
What: /sys/bus/iio/devices/iio:deviceX/buffer/hwfifo_watermark_min
KernelVersion: 4.2
Contact: linux-iio@vger.kernel.org
Description:
A single positive integer specifying the minimum watermark level
for the hardware fifo of this device. If the device does not
have a hardware fifo this entry is not present.
If the user sets buffer/watermark to a value less than this one,
then the hardware watermark will remain unset.
What: /sys/bus/iio/devices/iio:deviceX/buffer/hwfifo_watermark_max
KernelVersion: 4.2
Contact: linux-iio@vger.kernel.org
Description:
A single positive integer specifying the maximum watermark level
for the hardware fifo of this device. If the device does not
have a hardware fifo this entry is not present.
If the user sets buffer/watermark to a value greater than this
one, then the hardware watermark will be capped at this value.
What: /sys/bus/iio/devices/iio:deviceX/buffer/hwfifo_watermark_available
KernelVersion: 4.2
Contact: linux-iio@vger.kernel.org
Description:
A list of positive integers specifying the available watermark
levels for the hardware fifo. This entry is optional and if it
is not present it means that all the values between
hwfifo_watermark_min and hwfifo_watermark_max are supported.
If the user sets buffer/watermark to a value greater than
hwfifo_watermak_min but not equal to any of the values in this
list, the driver will chose an appropriate value for the
hardware fifo watermark level.
What: /sys/bus/iio/devices/iio:deviceX/in_temp_calibemissivity
What: /sys/bus/iio/devices/iio:deviceX/in_tempX_calibemissivity
What: /sys/bus/iio/devices/iio:deviceX/in_temp_object_calibemissivity
What: /sys/bus/iio/devices/iio:deviceX/in_tempX_object_calibemissivity
KernelVersion: 4.1
Contact: linux-iio@vger.kernel.org
Description:
The emissivity ratio of the surface in the field of view of the
contactless temperature sensor. Emissivity varies from 0 to 1,
with 1 being the emissivity of a black body.
What: /sys/bus/iio/devices/iio:deviceX/in_magn_x_oversampling_ratio
What: /sys/bus/iio/devices/iio:deviceX/in_magn_y_oversampling_ratio
What: /sys/bus/iio/devices/iio:deviceX/in_magn_z_oversampling_ratio
KernelVersion: 4.2
Contact: linux-iio@vger.kernel.org
Description:
Hardware applied number of measurements for acquiring one
data point. The HW will do <type>[_name]_oversampling_ratio
measurements and return the average value as output data. Each
value resulted from <type>[_name]_oversampling_ratio measurements
is considered as one sample for <type>[_name]_sampling_frequency.

7
Documentation/ABI/testing/sysfs-bus-iio-vf610 Normal file
View File

@@ -0,0 +1,7 @@
What: /sys/bus/iio/devices/iio:deviceX/conversion_mode
KernelVersion: 4.2
Contact: linux-iio@vger.kernel.org
Description:
Specifies the hardware conversion mode used. The three
available modes are "normal", "high-speed" and "low-power",
where the last is the default mode.

16
Documentation/ABI/testing/sysfs-bus-mei
View File

@@ -4,4 +4,18 @@ KernelVersion: 3.10
Contact: Samuel Ortiz <sameo@linux.intel.com>
linux-mei@linux.intel.com
Description: Stores the same MODALIAS value emitted by uevent
Format: mei:<mei device name>
Format: mei:<mei device name>:<device uuid>:
What: /sys/bus/mei/devices/.../name
Date: May 2015
KernelVersion: 4.2
Contact: Tomas Winkler <tomas.winkler@intel.com>
Description: Stores mei client device name
Format: string
What: /sys/bus/mei/devices/.../uuid
Date: May 2015
KernelVersion: 4.2
Contact: Tomas Winkler <tomas.winkler@intel.com>
Description: Stores mei client device uuid
Format: xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx

8
Documentation/ABI/testing/sysfs-bus-pci-drivers-janz-cmodio Normal file
View File

@@ -0,0 +1,8 @@
What: /sys/bus/pci/drivers/janz-cmodio/.../modulbus_number
Date: May 2010
KernelVersion: 2.6.35
Contact: Ira W. Snyder <ira.snyder@gmail.com>
Description:
Value representing the HEX switch S2 of the janz carrier board CMOD-IO or CAN-PCI2
Read-only: value of the configuration switch (0..15)

12
Documentation/ABI/testing/sysfs-bus-usb-lvstest
View File

@@ -4,14 +4,14 @@ driver is bound with root hub device.
What: /sys/bus/usb/devices/.../get_dev_desc
Date: March 2014
Contact: Pratyush Anand <pratyush.anand@st.com>
Contact: Pratyush Anand <pratyush.anand@gmail.com>
Description:
Write to this node to issue "Get Device Descriptor"
for Link Layer Validation device. It is needed for TD.7.06.
What: /sys/bus/usb/devices/.../u1_timeout
Date: March 2014
Contact: Pratyush Anand <pratyush.anand@st.com>
Contact: Pratyush Anand <pratyush.anand@gmail.com>
Description:
Set "U1 timeout" for the downstream port where Link Layer
Validation device is connected. Timeout value must be between 0
@@ -19,7 +19,7 @@ Description:
What: /sys/bus/usb/devices/.../u2_timeout
Date: March 2014
Contact: Pratyush Anand <pratyush.anand@st.com>
Contact: Pratyush Anand <pratyush.anand@gmail.com>
Description:
Set "U2 timeout" for the downstream port where Link Layer
Validation device is connected. Timeout value must be between 0
@@ -27,21 +27,21 @@ Description:
What: /sys/bus/usb/devices/.../hot_reset
Date: March 2014
Contact: Pratyush Anand <pratyush.anand@st.com>
Contact: Pratyush Anand <pratyush.anand@gmail.com>
Description:
Write to this node to issue "Reset" for Link Layer Validation
device. It is needed for TD.7.29, TD.7.31, TD.7.34 and TD.7.35.
What: /sys/bus/usb/devices/.../u3_entry
Date: March 2014
Contact: Pratyush Anand <pratyush.anand@st.com>
Contact: Pratyush Anand <pratyush.anand@gmail.com>
Description:
Write to this node to issue "U3 entry" for Link Layer
Validation device. It is needed for TD.7.35 and TD.7.36.
What: /sys/bus/usb/devices/.../u3_exit
Date: March 2014
Contact: Pratyush Anand <pratyush.anand@st.com>
Contact: Pratyush Anand <pratyush.anand@gmail.com>
Description:
Write to this node to issue "U3 exit" for Link Layer
Validation device. It is needed for TD.7.36.

35
Documentation/ABI/testing/sysfs-class-cxl
View File

@@ -6,6 +6,17 @@ Example: The real path of the attribute /sys/class/cxl/afu0.0s/irqs_max is
Slave contexts (eg. /sys/class/cxl/afu0.0s):
What: /sys/class/cxl/<afu>/afu_err_buf
Date: September 2014
Contact: linuxppc-dev@lists.ozlabs.org
Description: read only
AFU Error Buffer contents. The contents of this file are
application specific and depends on the AFU being used.
Applications interacting with the AFU can use this attribute
to know about the current error condition and take appropriate
action like logging the event etc.
What: /sys/class/cxl/<afu>/irqs_max
Date: September 2014
Contact: linuxppc-dev@lists.ozlabs.org
@@ -15,6 +26,7 @@ Description: read/write
that hardware can support (eg. 2037). Write values will limit
userspace applications to that many userspace interrupts. Must
be >= irqs_min.
Users: https://github.com/ibm-capi/libcxl
What: /sys/class/cxl/<afu>/irqs_min
Date: September 2014
@@ -24,6 +36,7 @@ Description: read only
userspace must request on a CXL_START_WORK ioctl. Userspace may
omit the num_interrupts field in the START_WORK IOCTL to get
this minimum automatically.
Users: https://github.com/ibm-capi/libcxl
What: /sys/class/cxl/<afu>/mmio_size
Date: September 2014
@@ -31,6 +44,7 @@ Contact: linuxppc-dev@lists.ozlabs.org
Description: read only
Decimal value of the size of the MMIO space that may be mmaped
by userspace.
Users: https://github.com/ibm-capi/libcxl
What: /sys/class/cxl/<afu>/modes_supported
Date: September 2014
@@ -38,6 +52,7 @@ Contact: linuxppc-dev@lists.ozlabs.org
Description: read only
List of the modes this AFU supports. One per line.
Valid entries are: "dedicated_process" and "afu_directed"
Users: https://github.com/ibm-capi/libcxl
What: /sys/class/cxl/<afu>/mode
Date: September 2014
@@ -46,6 +61,7 @@ Description: read/write
The current mode the AFU is using. Will be one of the modes
given in modes_supported. Writing will change the mode
provided that no user contexts are attached.
Users: https://github.com/ibm-capi/libcxl
What: /sys/class/cxl/<afu>/prefault_mode
@@ -59,6 +75,7 @@ Description: read/write
descriptor as an effective address and
prefault what it points to.
all: all segments process calling START_WORK maps.
Users: https://github.com/ibm-capi/libcxl
What: /sys/class/cxl/<afu>/reset
Date: September 2014
@@ -66,12 +83,14 @@ Contact: linuxppc-dev@lists.ozlabs.org
Description: write only
Writing 1 here will reset the AFU provided there are not
contexts active on the AFU.
Users: https://github.com/ibm-capi/libcxl
What: /sys/class/cxl/<afu>/api_version
Date: September 2014
Contact: linuxppc-dev@lists.ozlabs.org
Description: read only
Decimal value of the current version of the kernel/user API.
Users: https://github.com/ibm-capi/libcxl
What: /sys/class/cxl/<afu>/api_version_compatible
Date: September 2014
@@ -79,6 +98,7 @@ Contact: linuxppc-dev@lists.ozlabs.org
Description: read only
Decimal value of the the lowest version of the userspace API
this this kernel supports.
Users: https://github.com/ibm-capi/libcxl
AFU configuration records (eg. /sys/class/cxl/afu0.0/cr0):
@@ -92,6 +112,7 @@ Contact: linuxppc-dev@lists.ozlabs.org
Description: read only
Hexadecimal value of the vendor ID found in this AFU
configuration record.
Users: https://github.com/ibm-capi/libcxl
What: /sys/class/cxl/<afu>/cr<config num>/device
Date: February 2015
@@ -99,13 +120,15 @@ Contact: linuxppc-dev@lists.ozlabs.org
Description: read only
Hexadecimal value of the device ID found in this AFU
configuration record.
Users: https://github.com/ibm-capi/libcxl
What: /sys/class/cxl/<afu>/cr<config num>/vendor
What: /sys/class/cxl/<afu>/cr<config num>/class
Date: February 2015
Contact: linuxppc-dev@lists.ozlabs.org
Description: read only
Hexadecimal value of the class code found in this AFU
configuration record.
Users: https://github.com/ibm-capi/libcxl
What: /sys/class/cxl/<afu>/cr<config num>/config
Date: February 2015
@@ -115,6 +138,7 @@ Description: read only
record. The format is expected to match the either the standard
or extended configuration space defined by the PCIe
specification.
Users: https://github.com/ibm-capi/libcxl
@@ -126,18 +150,21 @@ Contact: linuxppc-dev@lists.ozlabs.org
Description: read only
Decimal value of the size of the MMIO space that may be mmaped
by userspace. This includes all slave contexts space also.
Users: https://github.com/ibm-capi/libcxl
What: /sys/class/cxl/<afu>m/pp_mmio_len
Date: September 2014
Contact: linuxppc-dev@lists.ozlabs.org
Description: read only
Decimal value of the Per Process MMIO space length.
Users: https://github.com/ibm-capi/libcxl
What: /sys/class/cxl/<afu>m/pp_mmio_off
Date: September 2014
Contact: linuxppc-dev@lists.ozlabs.org
Description: read only
Decimal value of the Per Process MMIO space offset.
Users: https://github.com/ibm-capi/libcxl
Card info (eg. /sys/class/cxl/card0)
@@ -147,12 +174,14 @@ Date: September 2014
Contact: linuxppc-dev@lists.ozlabs.org
Description: read only
Identifies the CAIA Version the card implements.
Users: https://github.com/ibm-capi/libcxl
What: /sys/class/cxl/<card>/psl_revision
Date: September 2014
Contact: linuxppc-dev@lists.ozlabs.org
Description: read only
Identifies the revision level of the PSL.
Users: https://github.com/ibm-capi/libcxl
What: /sys/class/cxl/<card>/base_image
Date: September 2014
@@ -162,6 +191,7 @@ Description: read only
that support loadable PSLs. For FPGAs this field identifies
the image contained in the on-adapter flash which is loaded
during the initial program load.
Users: https://github.com/ibm-capi/libcxl
What: /sys/class/cxl/<card>/image_loaded
Date: September 2014
@@ -169,6 +199,7 @@ Contact: linuxppc-dev@lists.ozlabs.org
Description: read only
Will return "user" or "factory" depending on the image loaded
onto the card.
Users: https://github.com/ibm-capi/libcxl
What: /sys/class/cxl/<card>/load_image_on_perst
Date: December 2014
@@ -183,6 +214,7 @@ Description: read/write
user or factory image to be loaded.
Default is to reload on PERST whichever image the card has
loaded.
Users: https://github.com/ibm-capi/libcxl
What: /sys/class/cxl/<card>/reset
Date: October 2014
@@ -190,3 +222,4 @@ Contact: linuxppc-dev@lists.ozlabs.org
Description: write only
Writing 1 will issue a PERST to card which may cause the card
to reload the FPGA depending on load_image_on_perst.
Users: https://github.com/ibm-capi/libcxl

80
Documentation/ABI/testing/sysfs-class-led-flash Normal file
View File

@@ -0,0 +1,80 @@
What: /sys/class/leds/<led>/flash_brightness
Date: March 2015
KernelVersion: 4.0
Contact: Jacek Anaszewski <j.anaszewski@samsung.com>
Description: read/write
Set the brightness of this LED in the flash strobe mode, in
microamperes. The file is created only for the flash LED devices
that support setting flash brightness.
The value is between 0 and
/sys/class/leds/<led>/max_flash_brightness.
What: /sys/class/leds/<led>/max_flash_brightness
Date: March 2015
KernelVersion: 4.0
Contact: Jacek Anaszewski <j.anaszewski@samsung.com>
Description: read only
Maximum brightness level for this LED in the flash strobe mode,
in microamperes.
What: /sys/class/leds/<led>/flash_timeout
Date: March 2015
KernelVersion: 4.0
Contact: Jacek Anaszewski <j.anaszewski@samsung.com>
Description: read/write
Hardware timeout for flash, in microseconds. The flash strobe
is stopped after this period of time has passed from the start
of the strobe. The file is created only for the flash LED
devices that support setting flash timeout.
What: /sys/class/leds/<led>/max_flash_timeout
Date: March 2015
KernelVersion: 4.0
Contact: Jacek Anaszewski <j.anaszewski@samsung.com>
Description: read only
Maximum flash timeout for this LED, in microseconds.
What: /sys/class/leds/<led>/flash_strobe
Date: March 2015
KernelVersion: 4.0
Contact: Jacek Anaszewski <j.anaszewski@samsung.com>
Description: read/write
Flash strobe state. When written with 1 it triggers flash strobe
and when written with 0 it turns the flash off.
On read 1 means that flash is currently strobing and 0 means
that flash is off.
What: /sys/class/leds/<led>/flash_fault
Date: March 2015
KernelVersion: 4.0
Contact: Jacek Anaszewski <j.anaszewski@samsung.com>
Description: read only
Space separated list of flash faults that may have occurred.
Flash faults are re-read after strobing the flash. Possible
flash faults:
* led-over-voltage - flash controller voltage to the flash LED
has exceeded the limit specific to the flash controller
* flash-timeout-exceeded - the flash strobe was still on when
the timeout set by the user has expired; not all flash
controllers may set this in all such conditions
* controller-over-temperature - the flash controller has
overheated
* controller-short-circuit - the short circuit protection
of the flash controller has been triggered
* led-power-supply-over-current - current in the LED power
supply has exceeded the limit specific to the flash
controller
* indicator-led-fault - the flash controller has detected
a short or open circuit condition on the indicator LED
* led-under-voltage - flash controller voltage to the flash
LED has been below the minimum limit specific to
the flash
* controller-under-voltage - the input voltage of the flash
controller is below the limit under which strobing the
flash at full current will not be possible;
the condition persists until this flag is no longer set
* led-over-temperature - the temperature of the LED has exceeded
its allowed upper limit

10
Documentation/ABI/testing/sysfs-class-mtd
View File

@@ -222,3 +222,13 @@ Description:
The number of blocks that are marked as reserved, if any, in
this partition. These are typically used to store the in-flash
bad block table (BBT).
What: /sys/class/mtd/mtdX/offset
Date: March 2015
KernelVersion: 4.1
Contact: linux-mtd@lists.infradead.org
Description:
For a partition, the offset of that partition from the start
of the master device in bytes. This attribute is absent on
main devices, so it can be used to distinguish between
partitions and devices that aren't partitions.

27
Documentation/ABI/testing/sysfs-class-net
View File

@@ -39,6 +39,25 @@ Description:
Format is a string, e.g: 00:11:22:33:44:55 for an Ethernet MAC
address.
What: /sys/class/net/<bridge iface>/bridge/group_fwd_mask
Date: January 2012
KernelVersion: 3.2
Contact: netdev@vger.kernel.org
Description:
Bitmask to allow forwarding of link local frames with address
01-80-C2-00-00-0X on a bridge device. Only values that set bits
not matching BR_GROUPFWD_RESTRICTED in net/bridge/br_private.h
allowed.
Default value 0 does not forward any link local frames.
Restricted bits:
0: 01-80-C2-00-00-00 Bridge Group Address used for STP
1: 01-80-C2-00-00-01 (MAC Control) 802.3 used for MAC PAUSE
2: 01-80-C2-00-00-02 (Link Aggregation) 802.3ad
Any values not setting these bits can be used. Take special
care when forwarding control frames e.g. 802.1X-PAE or LLDP.
What: /sys/class/net/<iface>/broadcast
Date: April 2005
KernelVersion: 2.6.12
@@ -188,6 +207,14 @@ Description:
Indicates the interface unique physical port identifier within
the NIC, as a string.
What: /sys/class/net/<iface>/phys_port_name
Date: March 2015
KernelVersion: 4.0
Contact: netdev@vger.kernel.org
Description:
Indicates the interface physical port name within the NIC,
as a string.
What: /sys/class/net/<iface>/speed
Date: October 2009
KernelVersion: 2.6.33

19
Documentation/ABI/testing/sysfs-class-net-janz-ican3 Normal file
View File

@@ -0,0 +1,19 @@
What: /sys/class/net/<iface>/termination
Date: May 2010
KernelVersion: 2.6.35
Contact: Ira W. Snyder <ira.snyder@gmail.com>
Description:
Value representing the can bus termination
Default: 1 (termination active)
Reading: get actual termination state
Writing: set actual termination state (0=no termination, 1=termination active)
What: /sys/class/net/<iface>/fwinfo
Date: May 2015
KernelVersion: 3.19
Contact: Andreas Gröger <andreas24groeger@gmail.com>
Description:
Firmware stamp of ican3 module
Read-only: 32 byte string identification of the ICAN3 module
(known values: "JANZ-ICAN3 ICANOS 1.xx", "JANZ-ICAN3 CAL/CANopen 1.xx")

8
Documentation/ABI/testing/sysfs-class-net-queues
View File

@@ -24,6 +24,14 @@ Description:
Indicates the number of transmit timeout events seen by this
network interface transmit queue.
What: /sys/class/<iface>/queues/tx-<queue>/tx_maxrate
Date: March 2015
KernelVersion: 4.1
Contact: netdev@vger.kernel.org
Description:
A Mbps max-rate set for the queue, a value of zero means disabled,
default is disabled.
What: /sys/class/<iface>/queues/tx-<queue>/xps_cpus
Date: November 2010
KernelVersion: 2.6.38

109
Documentation/ABI/testing/sysfs-class-scsi_tape Normal file
View File

@@ -0,0 +1,109 @@
What: /sys/class/scsi_tape/*/stats/in_flight
Date: Apr 2015
KernelVersion: 4.2
Contact: Shane Seymour <shane.seymour@hp.com>
Description:
Show the number of I/Os currently in-flight between the st
module and the SCSI mid-layer.
Users:
What: /sys/class/scsi_tape/*/stats/io_ns
Date: Apr 2015
KernelVersion: 4.2
Contact: Shane Seymour <shane.seymour@hp.com>
Description:
Shows the total amount of time spent waiting for all I/O
to and from the tape drive to complete. This includes all
reads, writes, and other SCSI commands issued to the tape
drive. An example of other SCSI commands would be tape
movement such as a rewind when a rewind tape device is
closed. This item is measured in nanoseconds.
To determine the amount of time spent waiting for other I/O
to complete subtract read_ns and write_ns from this value.
Users:
What: /sys/class/scsi_tape/*/stats/other_cnt
Date: Apr 2015
KernelVersion: 4.2
Contact: Shane Seymour <shane.seymour@hp.com>
Description:
The number of I/O requests issued to the tape drive other
than SCSI read/write requests.
Users:
What: /sys/class/scsi_tape/*/stats/read_byte_cnt
Date: Apr 2015
KernelVersion: 4.2
Contact: Shane Seymour <shane.seymour@hp.com>
Description:
Shows the total number of bytes requested from the tape drive.
This value is presented in bytes because tape drives support
variable length block sizes.
Users:
What: /sys/class/scsi_tape/*/stats/read_cnt
Date: Apr 2015
KernelVersion: 4.2
Contact: Shane Seymour <shane.seymour@hp.com>
Description:
Shows the total number of read requests issued to the tape
drive.
Users:
What: /sys/class/scsi_tape/*/stats/read_ns
Date: Apr 2015
KernelVersion: 4.2
Contact: Shane Seymour <shane.seymour@hp.com>
Description:
Shows the total amount of time in nanoseconds waiting for
read I/O requests to complete.
Users:
What: /sys/class/scsi_tape/*/stats/write_byte_cnt
Date: Apr 2015
KernelVersion: 4.2
Contact: Shane Seymour <shane.seymour@hp.com>
Description:
Shows the total number of bytes written to the tape drive.
This value is presented in bytes because tape drives support
variable length block sizes.
Users:
What: /sys/class/scsi_tape/*/stats/write_cnt
Date: Apr 2015
KernelVersion: 4.2
Contact: Shane Seymour <shane.seymour@hp.com>
Description:
Shows the total number of write requests issued to the tape
drive.
Users:
What: /sys/class/scsi_tape/*/stats/write_ms
Date: Apr 2015
KernelVersion: 4.2
Contact: Shane Seymour <shane.seymour@hp.com>
Description:
Shows the total amount of time in nanoseconds waiting for
write I/O requests to complete.
Users:
What: /sys/class/scsi_tape/*/stats/resid_cnt
Date: Apr 2015
KernelVersion: 4.2
Contact: Shane Seymour <shane.seymour@hp.com>
Description:
Shows the number of times we found that a residual >0
was found when the SCSI midlayer indicated that there was
an error. For reads this may be a case of someone issuing
reads greater than the block size.
Users:

24
Documentation/ABI/testing/sysfs-class-zram Normal file
View File

@@ -0,0 +1,24 @@
What: /sys/class/zram-control/
Date: August 2015
KernelVersion: 4.2
Contact: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
Description:
The zram-control/ class sub-directory belongs to zram
device class
What: /sys/class/zram-control/hot_add
Date: August 2015
KernelVersion: 4.2
Contact: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
Description:
RO attribute. Read operation will cause zram to add a new
device and return its device id back to user (so one can
use /dev/zram<id>), or error code.
What: /sys/class/zram-control/hot_remove
Date: August 2015
KernelVersion: 4.2
Contact: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
Description:
WO attribute. Remove a specific /dev/zramX device, where X
is a device_id provided by user.

4
Documentation/ABI/testing/sysfs-devices-system-cpu
View File

@@ -162,7 +162,7 @@ Description: Discover CPUs in the same CPU frequency coordination domain
What: /sys/devices/system/cpu/cpu*/cache/index3/cache_disable_{0,1}
Date: August 2008
KernelVersion: 2.6.27
Contact: discuss@x86-64.org
Contact: Linux kernel mailing list <linux-kernel@vger.kernel.org>
Description: Disable L3 cache indices
These files exist in every CPU's cache/index3 directory. Each
@@ -243,7 +243,7 @@ Description: Parameters for the CPU cache attributes
coherency_line_size: the minimum amount of data in bytes that gets
transferred from memory to cache
level: the cache hierarcy in the multi-level cache configuration
level: the cache hierarchy in the multi-level cache configuration
number_of_sets: total number of sets in the cache, a set is a
collection of cache lines with the same cache index

10
Documentation/ABI/testing/sysfs-driver-hid
View File

@@ -8,3 +8,13 @@ Description: When read, this file returns the device's raw binary HID
report descriptor.
This file cannot be written.
Users: HIDAPI library (http://www.signal11.us/oss/hidapi)
What: For USB devices : /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/country
For BT devices : /sys/class/bluetooth/hci<addr>/<hid-bus>:<vendor-id>:<product-id>.<num>/country
Symlink : /sys/class/hidraw/hidraw<num>/device/country
Date: February 2015
KernelVersion: 3.19
Contact: Olivier Gay <ogay@logitech.com>
Description: When read, this file returns the hex integer value in ASCII
of the device's HID country code (e.g. 21 for US).
This file cannot be written.

49
Documentation/ABI/testing/sysfs-driver-hid-logitech-lg4ff
View File

@@ -1,7 +1,52 @@
What: /sys/module/hid_logitech/drivers/hid:logitech/<dev>/range.
What: /sys/bus/hid/drivers/logitech/<dev>/range
Date: July 2011
KernelVersion: 3.2
Contact: Michal Malý <madcatxster@gmail.com>
Contact: Michal Malý <madcatxster@devoid-pointer.net>
Description: Display minimum, maximum and current range of the steering
wheel. Writing a value within min and max boundaries sets the
range of the wheel.
What: /sys/bus/hid/drivers/logitech/<dev>/alternate_modes
Date: Feb 2015
KernelVersion: 4.1
Contact: Michal Malý <madcatxster@devoid-pointer.net>
Description: Displays a set of alternate modes supported by a wheel. Each
mode is listed as follows:
Tag: Mode Name
Currently active mode is marked with an asterisk. List also
contains an abstract item "native" which always denotes the
native mode of the wheel. Echoing the mode tag switches the
wheel into the corresponding mode. Depending on the exact model
of the wheel not all listed modes might always be selectable.
If a wheel cannot be switched into the desired mode, -EINVAL
is returned accompanied with an explanatory message in the
kernel log.
This entry is not created for devices that have only one mode.
Currently supported mode switches:
Driving Force Pro:
DF-EX --> DFP
G25:
DF-EX --> DFP --> G25
G27:
DF-EX <*> DFP <-> G25 <-> G27
DF-EX <*--------> G25 <-> G27
DF-EX <*----------------> G27
DFGT:
DF-EX <*> DFP <-> DFGT
DF-EX <*--------> DFGT
* hid_logitech module must be loaded with lg4ff_no_autoswitch=1
parameter set in order for the switch to DF-EX mode to work.
What: /sys/bus/hid/drivers/logitech/<dev>/real_id
Date: Feb 2015
KernelVersion: 4.1
Contact: Michal Malý <madcatxster@devoid-pointer.net>
Description: Displays the real model of the wheel regardless of any
alternate mode the wheel might be switched to.
It is a read-only value.
This entry is not created for devices that have only one mode.

93
Documentation/ABI/testing/sysfs-driver-toshiba_acpi
View File

@@ -8,9 +8,11 @@ Description: This file controls the keyboard backlight operation mode, valid
* 0x2 -> AUTO (also called TIMER)
* 0x8 -> ON
* 0x10 -> OFF
Note that the kernel 3.16 onwards this file accepts all listed
Note that from kernel 3.16 onwards this file accepts all listed
parameters, kernel 3.15 only accepts the first two (FN-Z and
AUTO).
Also note that toggling this value on type 1 devices, requires
a reboot for changes to take effect.
Users: KToshiba
What: /sys/devices/LNXSYSTM:00/LNXSYBUS:00/TOS{1900,620{0,7,8}}:00/kbd_backlight_timeout
@@ -67,15 +69,72 @@ Description: This file shows the current keyboard backlight type,
* 2 -> Type 2, supporting modes TIMER, ON and OFF
Users: KToshiba
What: /sys/devices/LNXSYSTM:00/LNXSYBUS:00/TOS{1900,620{0,7,8}}:00/usb_sleep_charge
Date: January 23, 2015
KernelVersion: 4.0
Contact: Azael Avalos <coproscefalo@gmail.com>
Description: This file controls the USB Sleep & Charge charging mode, which
can be:
* 0 -> Disabled (0x00)
* 1 -> Alternate (0x09)
* 2 -> Auto (0x21)
* 3 -> Typical (0x11)
Note that from kernel 4.1 onwards this file accepts all listed
values, kernel 4.0 only supports the first three.
Note that this feature only works when connected to power, if
you want to use it under battery, see the entry named
"sleep_functions_on_battery"
Users: KToshiba
What: /sys/devices/LNXSYSTM:00/LNXSYBUS:00/TOS{1900,620{0,7,8}}:00/sleep_functions_on_battery
Date: January 23, 2015
KernelVersion: 4.0
Contact: Azael Avalos <coproscefalo@gmail.com>
Description: This file controls the USB Sleep Functions under battery, and
set the level at which point they will be disabled, accepted
values can be:
* 0 -> Disabled
* 1-100 -> Battery level to disable sleep functions
Currently it prints two values, the first one indicates if the
feature is enabled or disabled, while the second one shows the
current battery level set.
Note that when the value is set to disabled, the sleep function
will only work when connected to power.
Users: KToshiba
What: /sys/devices/LNXSYSTM:00/LNXSYBUS:00/TOS{1900,620{0,7,8}}:00/usb_rapid_charge
Date: January 23, 2015
KernelVersion: 4.0
Contact: Azael Avalos <coproscefalo@gmail.com>
Description: This file controls the USB Rapid Charge state, which can be:
* 0 -> Disabled
* 1 -> Enabled
Note that toggling this value requires a reboot for changes to
take effect.
Users: KToshiba
What: /sys/devices/LNXSYSTM:00/LNXSYBUS:00/TOS{1900,620{0,7,8}}:00/usb_sleep_music
Date: January 23, 2015
KernelVersion: 4.0
Contact: Azael Avalos <coproscefalo@gmail.com>
Description: This file controls the Sleep & Music state, which values can be:
* 0 -> Disabled
* 1 -> Enabled
Note that this feature only works when connected to power, if
you want to use it under battery, see the entry named
"sleep_functions_on_battery"
Users: KToshiba
What: /sys/devices/LNXSYSTM:00/LNXSYBUS:00/TOS{1900,620{0,7,8}}:00/version
Date: February, 2015
KernelVersion: 3.20
Date: February 12, 2015
KernelVersion: 4.0
Contact: Azael Avalos <coproscefalo@gmail.com>
Description: This file shows the current version of the driver
Users: KToshiba
What: /sys/devices/LNXSYSTM:00/LNXSYBUS:00/TOS{1900,620{0,7,8}}:00/fan
Date: February, 2015
KernelVersion: 3.20
Date: February 12, 2015
KernelVersion: 4.0
Contact: Azael Avalos <coproscefalo@gmail.com>
Description: This file controls the state of the internal fan, valid
values are:
@@ -83,8 +142,8 @@ Description: This file controls the state of the internal fan, valid
* 1 -> ON
What: /sys/devices/LNXSYSTM:00/LNXSYBUS:00/TOS{1900,620{0,7,8}}:00/kbd_function_keys
Date: February, 2015
KernelVersion: 3.20
Date: February 12, 2015
KernelVersion: 4.0
Contact: Azael Avalos <coproscefalo@gmail.com>
Description: This file controls the Special Functions (hotkeys) operation
mode, valid values are:
@@ -94,21 +153,29 @@ Description: This file controls the Special Functions (hotkeys) operation
and the hotkeys are accessed via FN-F{1-12}.
In the "Special Functions" mode, the F{1-12} keys trigger the
hotkey and the F{1-12} keys are accessed via FN-F{1-12}.
Note that toggling this value requires a reboot for changes to
take effect.
Users: KToshiba
What: /sys/devices/LNXSYSTM:00/LNXSYBUS:00/TOS{1900,620{0,7,8}}:00/panel_power_on
Date: February, 2015
KernelVersion: 3.20
Date: February 12, 2015
KernelVersion: 4.0
Contact: Azael Avalos <coproscefalo@gmail.com>
Description: This file controls whether the laptop should turn ON whenever
the LID is opened, valid values are:
* 0 -> Disabled
* 1 -> Enabled
Note that toggling this value requires a reboot for changes to
take effect.
Users: KToshiba
What: /sys/devices/LNXSYSTM:00/LNXSYBUS:00/TOS{1900,620{0,7,8}}:00/usb_three
Date: February, 2015
KernelVersion: 3.20
Date: February 12, 2015
KernelVersion: 4.0
Contact: Azael Avalos <coproscefalo@gmail.com>
Description: This file controls whether the USB 3 functionality, valid
values are:
Description: This file controls the USB 3 functionality, valid values are:
* 0 -> Disabled (Acts as a regular USB 2)
* 1 -> Enabled (Full USB 3 functionality)
Note that toggling this value requires a reboot for changes to
take effect.
Users: KToshiba

20
Documentation/ABI/testing/sysfs-driver-toshiba_haps Normal file
View File

@@ -0,0 +1,20 @@
What: /sys/devices/LNXSYSTM:00/LNXSYBUS:00/TOS620A:00/protection_level
Date: August 16, 2014
KernelVersion: 3.17
Contact: Azael Avalos <coproscefalo@gmail.com>
Description: This file controls the built-in accelerometer protection level,
valid values are:
* 0 -> Disabled
* 1 -> Low
* 2 -> Medium
* 3 -> High
The default potection value is set to 2 (Medium).
Users: KToshiba
What: /sys/devices/LNXSYSTM:00/LNXSYBUS:00/TOS620A:00/reset_protection
Date: August 16, 2014
KernelVersion: 3.17
Contact: Azael Avalos <coproscefalo@gmail.com>
Description: This file turns off the built-in accelerometer for a few
seconds and then restore normal operation. Accepting 1 as the
only parameter.

110
Documentation/ABI/testing/sysfs-firmware-dmi
View File

@@ -1,110 +0,0 @@
What: /sys/firmware/dmi/
Date: February 2011
Contact: Mike Waychison <mikew@google.com>
Description:
Many machines' firmware (x86 and ia64) export DMI /
SMBIOS tables to the operating system. Getting at this
information is often valuable to userland, especially in
cases where there are OEM extensions used.
The kernel itself does not rely on the majority of the
information in these tables being correct. It equally
cannot ensure that the data as exported to userland is
without error either.
DMI is structured as a large table of entries, where
each entry has a common header indicating the type and
length of the entry, as well as a firmware-provided
'handle' that is supposed to be unique amongst all
entries.
Some entries are required by the specification, but many
others are optional. In general though, users should
never expect to find a specific entry type on their
system unless they know for certain what their firmware
is doing. Machine to machine experiences will vary.
Multiple entries of the same type are allowed. In order
to handle these duplicate entry types, each entry is
assigned by the operating system an 'instance', which is
derived from an entry type's ordinal position. That is
to say, if there are 'N' multiple entries with the same type
'T' in the DMI tables (adjacent or spread apart, it
doesn't matter), they will be represented in sysfs as
entries "T-0" through "T-(N-1)":
Example entry directories:
/sys/firmware/dmi/entries/17-0
/sys/firmware/dmi/entries/17-1
/sys/firmware/dmi/entries/17-2
/sys/firmware/dmi/entries/17-3
...
Instance numbers are used in lieu of the firmware
assigned entry handles as the kernel itself makes no
guarantees that handles as exported are unique, and
there are likely firmware images that get this wrong in
the wild.
Each DMI entry in sysfs has the common header values
exported as attributes:
handle : The 16bit 'handle' that is assigned to this
entry by the firmware. This handle may be
referred to by other entries.
length : The length of the entry, as presented in the
entry itself. Note that this is _not the
total count of bytes associated with the
entry_. This value represents the length of
the "formatted" portion of the entry. This
"formatted" region is sometimes followed by
the "unformatted" region composed of nul
terminated strings, with termination signalled
by a two nul characters in series.
raw : The raw bytes of the entry. This includes the
"formatted" portion of the entry, the
"unformatted" strings portion of the entry,
and the two terminating nul characters.
type : The type of the entry. This value is the same
as found in the directory name. It indicates
how the rest of the entry should be interpreted.
instance: The instance ordinal of the entry for the
given type. This value is the same as found
in the parent directory name.
position: The ordinal position (zero-based) of the entry
within the entirety of the DMI entry table.
=== Entry Specialization ===
Some entry types may have other information available in
sysfs. Not all types are specialized.
--- Type 15 - System Event Log ---
This entry allows the firmware to export a log of
events the system has taken. This information is
typically backed by nvram, but the implementation
details are abstracted by this table. This entry's data
is exported in the directory:
/sys/firmware/dmi/entries/15-0/system_event_log
and has the following attributes (documented in the
SMBIOS / DMI specification under "System Event Log (Type 15)":
area_length
header_start_offset
data_start_offset
access_method
status
change_token
access_method_address
header_format
per_log_type_descriptor_length
type_descriptors_supported_count
As well, the kernel exports the binary attribute:
raw_event_log : The raw binary bits of the event log
as described by the DMI entry.

110
Documentation/ABI/testing/sysfs-firmware-dmi-entries Normal file
View File

@@ -0,0 +1,110 @@
What: /sys/firmware/dmi/entries/
Date: February 2011
Contact: Mike Waychison <mikew@google.com>
Description:
Many machines' firmware (x86 and ia64) export DMI /
SMBIOS tables to the operating system. Getting at this
information is often valuable to userland, especially in
cases where there are OEM extensions used.
The kernel itself does not rely on the majority of the
information in these tables being correct. It equally
cannot ensure that the data as exported to userland is
without error either.
DMI is structured as a large table of entries, where
each entry has a common header indicating the type and
length of the entry, as well as a firmware-provided
'handle' that is supposed to be unique amongst all
entries.
Some entries are required by the specification, but many
others are optional. In general though, users should
never expect to find a specific entry type on their
system unless they know for certain what their firmware
is doing. Machine to machine experiences will vary.
Multiple entries of the same type are allowed. In order
to handle these duplicate entry types, each entry is
assigned by the operating system an 'instance', which is
derived from an entry type's ordinal position. That is
to say, if there are 'N' multiple entries with the same type
'T' in the DMI tables (adjacent or spread apart, it
doesn't matter), they will be represented in sysfs as
entries "T-0" through "T-(N-1)":
Example entry directories:
/sys/firmware/dmi/entries/17-0
/sys/firmware/dmi/entries/17-1
/sys/firmware/dmi/entries/17-2
/sys/firmware/dmi/entries/17-3
...
Instance numbers are used in lieu of the firmware
assigned entry handles as the kernel itself makes no
guarantees that handles as exported are unique, and
there are likely firmware images that get this wrong in
the wild.
Each DMI entry in sysfs has the common header values
exported as attributes:
handle : The 16bit 'handle' that is assigned to this
entry by the firmware. This handle may be
referred to by other entries.
length : The length of the entry, as presented in the
entry itself. Note that this is _not the
total count of bytes associated with the
entry_. This value represents the length of
the "formatted" portion of the entry. This
"formatted" region is sometimes followed by
the "unformatted" region composed of nul
terminated strings, with termination signalled
by a two nul characters in series.
raw : The raw bytes of the entry. This includes the
"formatted" portion of the entry, the
"unformatted" strings portion of the entry,
and the two terminating nul characters.
type : The type of the entry. This value is the same
as found in the directory name. It indicates
how the rest of the entry should be interpreted.
instance: The instance ordinal of the entry for the
given type. This value is the same as found
in the parent directory name.
position: The ordinal position (zero-based) of the entry
within the entirety of the DMI entry table.
=== Entry Specialization ===
Some entry types may have other information available in
sysfs. Not all types are specialized.
--- Type 15 - System Event Log ---
This entry allows the firmware to export a log of
events the system has taken. This information is
typically backed by nvram, but the implementation
details are abstracted by this table. This entry's data
is exported in the directory:
/sys/firmware/dmi/entries/15-0/system_event_log
and has the following attributes (documented in the
SMBIOS / DMI specification under "System Event Log (Type 15)":
area_length
header_start_offset
data_start_offset
access_method
status
change_token
access_method_address
header_format
per_log_type_descriptor_length
type_descriptors_supported_count
As well, the kernel exports the binary attribute:
raw_event_log : The raw binary bits of the event log
as described by the DMI entry.

22
Documentation/ABI/testing/sysfs-firmware-dmi-tables Normal file
View File

@@ -0,0 +1,22 @@
What: /sys/firmware/dmi/tables/
Date: April 2015
Contact: Ivan Khoronzhuk <ivan.khoronzhuk@globallogic.com>
Description:
The firmware provides DMI structures as a packed list of
data referenced by a SMBIOS table entry point. The SMBIOS
entry point contains general information, like SMBIOS
version, DMI table size, etc. The structure, content and
size of SMBIOS entry point is dependent on SMBIOS version.
The format of SMBIOS entry point and DMI structures
can be read in SMBIOS specification.
The dmi/tables provides raw SMBIOS entry point and DMI tables
through sysfs as an alternative to utilities reading them
from /dev/mem. The raw SMBIOS entry point and DMI table are
presented as binary attributes and are accessible via:
/sys/firmware/dmi/tables/smbios_entry_point
/sys/firmware/dmi/tables/DMI
The complete DMI information can be obtained using these two
tables.

10
Documentation/ABI/testing/sysfs-firmware-efi
View File

@@ -18,3 +18,13 @@ Contact: Dave Young <dyoung@redhat.com>
Description: It shows the physical address of config table entry in the EFI
system table.
Users: Kexec
What: /sys/firmware/efi/systab
Date: April 2005
Contact: linux-efi@vger.kernel.org
Description: Displays the physical addresses of all EFI Configuration
Tables found via the EFI System Table. The order in
which the tables are printed forms an ABI and newer
versions are always printed first, i.e. ACPI20 comes
before ACPI.
Users: dmidecode

81
Documentation/ABI/testing/sysfs-firmware-efi-esrt Normal file
View File

@@ -0,0 +1,81 @@
What: /sys/firmware/efi/esrt/
Date: February 2015
Contact: Peter Jones <pjones@redhat.com>
Description: Provides userland access to read the EFI System Resource Table
(ESRT), a catalog of firmware for which can be updated with
the UEFI UpdateCapsule mechanism described in section 7.5 of
the UEFI Standard.
Users: fwupdate - https://github.com/rhinstaller/fwupdate
What: /sys/firmware/efi/esrt/fw_resource_count
Date: February 2015
Contact: Peter Jones <pjones@redhat.com>
Description: The number of entries in the ESRT
What: /sys/firmware/efi/esrt/fw_resource_count_max
Date: February 2015
Contact: Peter Jones <pjones@redhat.com>
Description: The maximum number of entries that /could/ be registered
in the allocation the table is currently in. This is
really only useful to the system firmware itself.
What: /sys/firmware/efi/esrt/fw_resource_version
Date: February 2015
Contact: Peter Jones <pjones@redhat.com>
Description: The version of the ESRT structure provided by the firmware.
What: /sys/firmware/efi/esrt/entries/entry$N/
Date: February 2015
Contact: Peter Jones <pjones@redhat.com>
Description: Each ESRT entry is identified by a GUID, and each gets a
subdirectory under entries/ .
example: /sys/firmware/efi/esrt/entries/entry0/
What: /sys/firmware/efi/esrt/entries/entry$N/fw_type
Date: February 2015
Contact: Peter Jones <pjones@redhat.com>
Description: What kind of firmware entry this is:
0 - Unknown
1 - System Firmware
2 - Device Firmware
3 - UEFI Driver
What: /sys/firmware/efi/esrt/entries/entry$N/fw_class
Date: February 2015
Contact: Peter Jones <pjones@redhat.com>
Description: This is the entry's guid, and will match the directory name.
What: /sys/firmware/efi/esrt/entries/entry$N/fw_version
Date: February 2015
Contact: Peter Jones <pjones@redhat.com>
Description: The version of the firmware currently installed. This is a
32-bit unsigned integer.
What: /sys/firmware/efi/esrt/entries/entry$N/lowest_supported_fw_version
Date: February 2015
Contact: Peter Jones <pjones@redhat.com>
Description: The lowest version of the firmware that can be installed.
What: /sys/firmware/efi/esrt/entries/entry$N/capsule_flags
Date: February 2015
Contact: Peter Jones <pjones@redhat.com>
Description: Flags that must be passed to UpdateCapsule()
What: /sys/firmware/efi/esrt/entries/entry$N/last_attempt_version
Date: February 2015
Contact: Peter Jones <pjones@redhat.com>
Description: The last firmware version for which an update was attempted.
What: /sys/firmware/efi/esrt/entries/entry$N/last_attempt_status
Date: February 2015
Contact: Peter Jones <pjones@redhat.com>
Description: The result of the last firmware update attempt for the
firmware resource entry.
0 - Success
1 - Insufficient resources
2 - Incorrect version
3 - Invalid format
4 - Authentication error
5 - AC power event
6 - Battery power event

69
Documentation/ABI/testing/sysfs-platform-dell-laptop Normal file
View File

@@ -0,0 +1,69 @@
What: /sys/class/leds/dell::kbd_backlight/als_enabled
Date: December 2014
KernelVersion: 3.19
Contact: Gabriele Mazzotta <gabriele.mzt@gmail.com>,
Pali Rohár <pali.rohar@gmail.com>
Description:
This file allows to control the automatic keyboard
illumination mode on some systems that have an ambient
light sensor. Write 1 to this file to enable the auto
mode, 0 to disable it.
What: /sys/class/leds/dell::kbd_backlight/als_setting
Date: December 2014
KernelVersion: 3.19
Contact: Gabriele Mazzotta <gabriele.mzt@gmail.com>,
Pali Rohár <pali.rohar@gmail.com>
Description:
This file allows to specifiy the on/off threshold value,
as reported by the ambient light sensor.
What: /sys/class/leds/dell::kbd_backlight/start_triggers
Date: December 2014
KernelVersion: 3.19
Contact: Gabriele Mazzotta <gabriele.mzt@gmail.com>,
Pali Rohár <pali.rohar@gmail.com>
Description:
This file allows to control the input triggers that
turn on the keyboard backlight illumination that is
disabled because of inactivity.
Read the file to see the triggers available. The ones
enabled are preceded by '+', those disabled by '-'.
To enable a trigger, write its name preceded by '+' to
this file. To disable a trigger, write its name preceded
by '-' instead.
For example, to enable the keyboard as trigger run:
echo +keyboard > /sys/class/leds/dell::kbd_backlight/start_triggers
To disable it:
echo -keyboard > /sys/class/leds/dell::kbd_backlight/start_triggers
Note that not all the available triggers can be configured.
What: /sys/class/leds/dell::kbd_backlight/stop_timeout
Date: December 2014
KernelVersion: 3.19
Contact: Gabriele Mazzotta <gabriele.mzt@gmail.com>,
Pali Rohár <pali.rohar@gmail.com>
Description:
This file allows to specify the interval after which the
keyboard illumination is disabled because of inactivity.
The timeouts are expressed in seconds, minutes, hours and
days, for which the symbols are 's', 'm', 'h' and 'd'
respectively.
To configure the timeout, write to this file a value along
with any the above units. If no unit is specified, the value
is assumed to be expressed in seconds.
For example, to set the timeout to 10 minutes run:
echo 10m > /sys/class/leds/dell::kbd_backlight/stop_timeout
Note that when this file is read, the returned value might be
expressed in a different unit than the one used when the timeout
was set.
Also note that only some timeouts are supported and that
some systems might fall back to a specific timeout in case
an invalid timeout is written to this file.

8
Documentation/ABI/testing/sysfs-platform-twl4030-usb Normal file
View File

@@ -0,0 +1,8 @@
What: /sys/bus/platform/devices/*twl4030-usb/vbus
Description:
Read-only status reporting if VBUS (approx 5V)
is being supplied by the USB bus.
Possible values: "on", "off".
Changes are notified via select/poll.

158
Documentation/CodingStyle
View File

@@ -13,7 +13,7 @@ and NOT read it. Burn them, it's a great symbolic gesture.
Anyway, here goes:
Chapter 1: Indentation
Chapter 1: Indentation
Tabs are 8 characters, and thus indentations are also 8 characters.
There are heretic movements that try to make indentations 4 (or even 2!)
@@ -56,7 +56,6 @@ instead of "double-indenting" the "case" labels. E.g.:
break;
}
Don't put multiple statements on a single line unless you have
something to hide:
@@ -156,25 +155,25 @@ comments on.
Do not unnecessarily use braces where a single statement will do.
if (condition)
action();
if (condition)
action();
and
if (condition)
do_this();
else
do_that();
if (condition)
do_this();
else
do_that();
This does not apply if only one branch of a conditional statement is a single
statement; in the latter case use braces in both branches:
if (condition) {
do_this();
do_that();
} else {
otherwise();
}
if (condition) {
do_this();
do_that();
} else {
otherwise();
}
3.1: Spaces
@@ -186,8 +185,11 @@ although they are not required in the language, as in: "sizeof info" after
"struct fileinfo info;" is declared).
So use a space after these keywords:
if, switch, case, for, do, while
but not with sizeof, typeof, alignof, or __attribute__. E.g.,
s = sizeof(struct file);
Do not add spaces around (inside) parenthesized expressions. This example is
@@ -209,12 +211,15 @@ such as any of these:
= + - < > * / % | & ^ <= >= == != ? :
but no space after unary operators:
& * + - ~ ! sizeof typeof alignof __attribute__ defined
no space before the postfix increment & decrement unary operators:
++ --
no space after the prefix increment & decrement unary operators:
++ --
and no space around the '.' and "->" structure member operators.
@@ -268,13 +273,11 @@ See chapter 6 (Functions).
Chapter 5: Typedefs
Please don't use things like "vps_t".
It's a _mistake_ to use typedef for structures and pointers. When you see a
vps_t a;
in the source, what does it mean?
In contrast, if it says
struct virtual_container *a;
@@ -372,11 +375,11 @@ In source files, separate functions with one blank line. If the function is
exported, the EXPORT* macro for it should follow immediately after the closing
function brace line. E.g.:
int system_is_up(void)
{
return system_state == SYSTEM_RUNNING;
}
EXPORT_SYMBOL(system_is_up);
int system_is_up(void)
{
return system_state == SYSTEM_RUNNING;
}
EXPORT_SYMBOL(system_is_up);
In function prototypes, include parameter names with their data types.
Although this is not required by the C language, it is preferred in Linux
@@ -405,34 +408,34 @@ The rationale for using gotos is:
modifications are prevented
- saves the compiler work to optimize redundant code away ;)
int fun(int a)
{
int result = 0;
char *buffer;
int fun(int a)
{
int result = 0;
char *buffer;
buffer = kmalloc(SIZE, GFP_KERNEL);
if (!buffer)
return -ENOMEM;
buffer = kmalloc(SIZE, GFP_KERNEL);
if (!buffer)
return -ENOMEM;
if (condition1) {
while (loop1) {
...
if (condition1) {
while (loop1) {
...
}
result = 1;
goto out_buffer;
}
result = 1;
goto out_buffer;
...
out_buffer:
kfree(buffer);
return result;
}
...
out_buffer:
kfree(buffer);
return result;
}
A common type of bug to be aware of it "one err bugs" which look like this:
err:
kfree(foo->bar);
kfree(foo);
return ret;
err:
kfree(foo->bar);
kfree(foo);
return ret;
The bug in this code is that on some exit paths "foo" is NULL. Normally the
fix for this is to split it up into two error labels "err_bar:" and "err_foo:".
@@ -503,9 +506,9 @@ values. To do the latter, you can stick the following in your .emacs file:
(defun c-lineup-arglist-tabs-only (ignored)
"Line up argument lists by tabs, not spaces"
(let* ((anchor (c-langelem-pos c-syntactic-element))
(column (c-langelem-2nd-pos c-syntactic-element))
(offset (- (1+ column) anchor))
(steps (floor offset c-basic-offset)))
(column (c-langelem-2nd-pos c-syntactic-element))
(offset (- (1+ column) anchor))
(steps (floor offset c-basic-offset)))
(* (max steps 1)
c-basic-offset)))
@@ -612,7 +615,7 @@ have a reference count on it, you almost certainly have a bug.
Names of macros defining constants and labels in enums are capitalized.
#define CONSTANT 0x12345
#define CONSTANT 0x12345
Enums are preferred when defining several related constants.
@@ -623,28 +626,28 @@ Generally, inline functions are preferable to macros resembling functions.
Macros with multiple statements should be enclosed in a do - while block:
#define macrofun(a, b, c) \
do { \
if (a == 5) \
do_this(b, c); \
} while (0)
#define macrofun(a, b, c) \
do { \
if (a == 5) \
do_this(b, c); \
} while (0)
Things to avoid when using macros:
1) macros that affect control flow:
#define FOO(x) \
do { \
if (blah(x) < 0) \
return -EBUGGERED; \
} while(0)
#define FOO(x) \
do { \
if (blah(x) < 0) \
return -EBUGGERED; \
} while(0)
is a _very_ bad idea. It looks like a function call but exits the "calling"
function; don't break the internal parsers of those who will read the code.
2) macros that depend on having a local variable with a magic name:
#define FOO(val) bar(index, val)
#define FOO(val) bar(index, val)
might look like a good thing, but it's confusing as hell when one reads the
code and it's prone to breakage from seemingly innocent changes.
@@ -656,8 +659,21 @@ bite you if somebody e.g. turns FOO into an inline function.
must enclose the expression in parentheses. Beware of similar issues with
macros using parameters.
#define CONSTANT 0x4000
#define CONSTEXP (CONSTANT | 3)
#define CONSTANT 0x4000
#define CONSTEXP (CONSTANT | 3)
5) namespace collisions when defining local variables in macros resembling
functions:
#define FOO(x) \
({ \
typeof(x) ret; \
ret = calc_ret(x); \
(ret); \
})
ret is a common name for a local variable - __foo_ret is less likely
to collide with an existing variable.
The cpp manual deals with macros exhaustively. The gcc internals manual also
covers RTL which is used frequently with assembly language in the kernel.
@@ -796,11 +812,11 @@ you should use, rather than explicitly coding some variant of them yourself.
For example, if you need to calculate the length of an array, take advantage
of the macro
#define ARRAY_SIZE(x) (sizeof(x) / sizeof((x)[0]))
#define ARRAY_SIZE(x) (sizeof(x) / sizeof((x)[0]))
Similarly, if you need to calculate the size of some structure member, use
#define FIELD_SIZEOF(t, f) (sizeof(((t*)0)->f))
#define FIELD_SIZEOF(t, f) (sizeof(((t*)0)->f))
There are also min() and max() macros that do strict type checking if you
need them. Feel free to peruse that header file to see what else is already
@@ -813,19 +829,19 @@ Some editors can interpret configuration information embedded in source files,
indicated with special markers. For example, emacs interprets lines marked
like this:
-*- mode: c -*-
-*- mode: c -*-
Or like this:
/*
Local Variables:
compile-command: "gcc -DMAGIC_DEBUG_FLAG foo.c"
End:
*/
/*
Local Variables:
compile-command: "gcc -DMAGIC_DEBUG_FLAG foo.c"
End:
*/
Vim interprets markers that look like this:
/* vim:set sw=8 noet */
/* vim:set sw=8 noet */
Do not include any of these in source files. People have their own personal
editor configurations, and your source files should not override them. This
@@ -902,9 +918,9 @@ At the end of any non-trivial #if or #ifdef block (more than a few lines),
place a comment after the #endif on the same line, noting the conditional
expression used. For instance:
#ifdef CONFIG_SOMETHING
...
#endif /* CONFIG_SOMETHING */
#ifdef CONFIG_SOMETHING
...
#endif /* CONFIG_SOMETHING */
Appendix I: References

33
Documentation/DMA-API-HOWTO.txt
View File

@@ -25,13 +25,18 @@ physical addresses. These are the addresses in /proc/iomem. The physical
address is not directly useful to a driver; it must use ioremap() to map
the space and produce a virtual address.
I/O devices use a third kind of address: a "bus address" or "DMA address".
If a device has registers at an MMIO address, or if it performs DMA to read
or write system memory, the addresses used by the device are bus addresses.
In some systems, bus addresses are identical to CPU physical addresses, but
in general they are not. IOMMUs and host bridges can produce arbitrary
I/O devices use a third kind of address: a "bus address". If a device has
registers at an MMIO address, or if it performs DMA to read or write system
memory, the addresses used by the device are bus addresses. In some
systems, bus addresses are identical to CPU physical addresses, but in
general they are not. IOMMUs and host bridges can produce arbitrary
mappings between physical and bus addresses.
From a device's point of view, DMA uses the bus address space, but it may
be restricted to a subset of that space. For example, even if a system
supports 64-bit addresses for main memory and PCI BARs, it may use an IOMMU
so devices only need to use 32-bit DMA addresses.
Here's a picture and some examples:
CPU CPU Bus
@@ -72,11 +77,11 @@ can use virtual address X to access the buffer, but the device itself
cannot because DMA doesn't go through the CPU virtual memory system.
In some simple systems, the device can do DMA directly to physical address
Y. But in many others, there is IOMMU hardware that translates bus
Y. But in many others, there is IOMMU hardware that translates DMA
addresses to physical addresses, e.g., it translates Z to Y. This is part
of the reason for the DMA API: the driver can give a virtual address X to
an interface like dma_map_single(), which sets up any required IOMMU
mapping and returns the bus address Z. The driver then tells the device to
mapping and returns the DMA address Z. The driver then tells the device to
do DMA to Z, and the IOMMU maps it to the buffer at address Y in system
RAM.
@@ -98,7 +103,7 @@ First of all, you should make sure
#include <linux/dma-mapping.h>
is in your driver, which provides the definition of dma_addr_t. This type
can hold any valid DMA or bus address for the platform and should be used
can hold any valid DMA address for the platform and should be used
everywhere you hold a DMA address returned from the DMA mapping functions.
What memory is DMA'able?
@@ -240,7 +245,7 @@ the case would look like this:
if (!dma_set_mask_and_coherent(dev, DMA_BIT_MASK(64))) {
using_dac = 1;
consistent_using_dac = 1;
consistent_using_dac = 1;
} else if (!dma_set_mask_and_coherent(dev, DMA_BIT_MASK(32))) {
using_dac = 0;
consistent_using_dac = 0;
@@ -316,7 +321,7 @@ There are two types of DMA mappings:
Think of "consistent" as "synchronous" or "coherent".
The current default is to return consistent memory in the low 32
bits of the bus space. However, for future compatibility you should
bits of the DMA space. However, for future compatibility you should
set the consistent mask even if this default is fine for your
driver.
@@ -353,7 +358,7 @@ There are two types of DMA mappings:
transfer, unmapped right after it (unless you use dma_sync_* below)
and for which hardware can optimize for sequential accesses.
This of "streaming" as "asynchronous" or "outside the coherency
Think of "streaming" as "asynchronous" or "outside the coherency
domain".
Good examples of what to use streaming mappings for are:
@@ -403,7 +408,7 @@ dma_alloc_coherent() returns two values: the virtual address which you
can use to access it from the CPU and dma_handle which you pass to the
card.
The CPU virtual address and the DMA bus address are both
The CPU virtual address and the DMA address are both
guaranteed to be aligned to the smallest PAGE_SIZE order which
is greater than or equal to the requested size. This invariant
exists (for example) to guarantee that if you allocate a chunk
@@ -645,8 +650,8 @@ PLEASE NOTE: The 'nents' argument to the dma_unmap_sg call must be
dma_map_sg call.
Every dma_map_{single,sg}() call should have its dma_unmap_{single,sg}()
counterpart, because the bus address space is a shared resource and
you could render the machine unusable by consuming all bus addresses.
counterpart, because the DMA address space is a shared resource and
you could render the machine unusable by consuming all DMA addresses.
If you need to use the same streaming DMA region multiple times and touch
the data in between the DMA transfers, the buffer needs to be synced

30
Documentation/DMA-API.txt
View File

@@ -18,10 +18,10 @@ Part I - dma_ API
To get the dma_ API, you must #include <linux/dma-mapping.h>. This
provides dma_addr_t and the interfaces described below.
A dma_addr_t can hold any valid DMA or bus address for the platform. It
can be given to a device to use as a DMA source or target. A CPU cannot
reference a dma_addr_t directly because there may be translation between
its physical address space and the bus address space.
A dma_addr_t can hold any valid DMA address for the platform. It can be
given to a device to use as a DMA source or target. A CPU cannot reference
a dma_addr_t directly because there may be translation between its physical
address space and the DMA address space.
Part Ia - Using large DMA-coherent buffers
------------------------------------------
@@ -42,7 +42,7 @@ It returns a pointer to the allocated region (in the processor's virtual
address space) or NULL if the allocation failed.
It also returns a <dma_handle> which may be cast to an unsigned integer the
same width as the bus and given to the device as the bus address base of
same width as the bus and given to the device as the DMA address base of
the region.
Note: consistent memory can be expensive on some platforms, and the
@@ -193,7 +193,7 @@ dma_map_single(struct device *dev, void *cpu_addr, size_t size,
enum dma_data_direction direction)
Maps a piece of processor virtual memory so it can be accessed by the
device and returns the bus address of the memory.
device and returns the DMA address of the memory.
The direction for both APIs may be converted freely by casting.
However the dma_ API uses a strongly typed enumerator for its
@@ -212,20 +212,20 @@ contiguous piece of memory. For this reason, memory to be mapped by
this API should be obtained from sources which guarantee it to be
physically contiguous (like kmalloc).
Further, the bus address of the memory must be within the
Further, the DMA address of the memory must be within the
dma_mask of the device (the dma_mask is a bit mask of the
addressable region for the device, i.e., if the bus address of
the memory ANDed with the dma_mask is still equal to the bus
addressable region for the device, i.e., if the DMA address of
the memory ANDed with the dma_mask is still equal to the DMA
address, then the device can perform DMA to the memory). To
ensure that the memory allocated by kmalloc is within the dma_mask,
the driver may specify various platform-dependent flags to restrict
the bus address range of the allocation (e.g., on x86, GFP_DMA
guarantees to be within the first 16MB of available bus addresses,
the DMA address range of the allocation (e.g., on x86, GFP_DMA
guarantees to be within the first 16MB of available DMA addresses,
as required by ISA devices).
Note also that the above constraints on physical contiguity and
dma_mask may not apply if the platform has an IOMMU (a device which
maps an I/O bus address to a physical memory address). However, to be
maps an I/O DMA address to a physical memory address). However, to be
portable, device driver writers may *not* assume that such an IOMMU
exists.
@@ -296,7 +296,7 @@ reduce current DMA mapping usage or delay and try again later).
dma_map_sg(struct device *dev, struct scatterlist *sg,
int nents, enum dma_data_direction direction)
Returns: the number of bus address segments mapped (this may be shorter
Returns: the number of DMA address segments mapped (this may be shorter
than <nents> passed in if some elements of the scatter/gather list are
physically or virtually adjacent and an IOMMU maps them with a single
entry).
@@ -340,7 +340,7 @@ must be the same as those and passed in to the scatter/gather mapping
API.
Note: <nents> must be the number you passed in, *not* the number of
bus address entries returned.
DMA address entries returned.
void
dma_sync_single_for_cpu(struct device *dev, dma_addr_t dma_handle, size_t size,
@@ -507,7 +507,7 @@ it's asked for coherent memory for this device.
phys_addr is the CPU physical address to which the memory is currently
assigned (this will be ioremapped so the CPU can access the region).
device_addr is the bus address the device needs to be programmed
device_addr is the DMA address the device needs to be programmed
with to actually address this memory (this will be handed out as the
dma_addr_t in dma_alloc_coherent()).

913
Documentation/DocBook/crypto-API.tmpl
View File

@@ -119,7 +119,7 @@
<para>
Note: The terms "transformation" and cipher algorithm are used
interchangably.
interchangeably.
</para>
</sect1>
@@ -509,6 +509,270 @@
select it due to the used type and mask field.
</para>
</sect1>
<sect1><title>Internal Structure of Kernel Crypto API</title>
<para>
The kernel crypto API has an internal structure where a cipher
implementation may use many layers and indirections. This section
shall help to clarify how the kernel crypto API uses
various components to implement the complete cipher.
</para>
<para>
The following subsections explain the internal structure based
on existing cipher implementations. The first section addresses
the most complex scenario where all other scenarios form a logical
subset.
</para>
<sect2><title>Generic AEAD Cipher Structure</title>
<para>
The following ASCII art decomposes the kernel crypto API layers
when using the AEAD cipher with the automated IV generation. The
shown example is used by the IPSEC layer.
</para>
<para>
For other use cases of AEAD ciphers, the ASCII art applies as
well, but the caller may not use the AEAD cipher with a separate
IV generator. In this case, the caller must generate the IV.
</para>
<para>
The depicted example decomposes the AEAD cipher of GCM(AES) based
on the generic C implementations (gcm.c, aes-generic.c, ctr.c,
ghash-generic.c, seqiv.c). The generic implementation serves as an
example showing the complete logic of the kernel crypto API.
</para>
<para>
It is possible that some streamlined cipher implementations (like
AES-NI) provide implementations merging aspects which in the view
of the kernel crypto API cannot be decomposed into layers any more.
In case of the AES-NI implementation, the CTR mode, the GHASH
implementation and the AES cipher are all merged into one cipher
implementation registered with the kernel crypto API. In this case,
the concept described by the following ASCII art applies too. However,
the decomposition of GCM into the individual sub-components
by the kernel crypto API is not done any more.
</para>
<para>
Each block in the following ASCII art is an independent cipher
instance obtained from the kernel crypto API. Each block
is accessed by the caller or by other blocks using the API functions
defined by the kernel crypto API for the cipher implementation type.
</para>
<para>
The blocks below indicate the cipher type as well as the specific
logic implemented in the cipher.
</para>
<para>
The ASCII art picture also indicates the call structure, i.e. who
calls which component. The arrows point to the invoked block
where the caller uses the API applicable to the cipher type
specified for the block.
</para>
<programlisting>
<![CDATA[
kernel crypto API | IPSEC Layer
|
+-----------+ |
| | (1)
| aead | <----------------------------------- esp_output
| (seqniv) | ---+
+-----------+ |
| (2)
+-----------+ |
| | <--+ (2)
| aead | <----------------------------------- esp_input
| (gcm) | ------------+
+-----------+ |
| (3) | (5)
v v
+-----------+ +-----------+
| | | |
| ablkcipher| | ahash |
| (ctr) | ---+ | (ghash) |
+-----------+ | +-----------+
|
+-----------+ | (4)
| | <--+
| cipher |
| (aes) |
+-----------+
]]>
</programlisting>
<para>
The following call sequence is applicable when the IPSEC layer
triggers an encryption operation with the esp_output function. During
configuration, the administrator set up the use of rfc4106(gcm(aes)) as
the cipher for ESP. The following call sequence is now depicted in the
ASCII art above:
</para>
<orderedlist>
<listitem>
<para>
esp_output() invokes crypto_aead_encrypt() to trigger an encryption
operation of the AEAD cipher with IV generator.
</para>
<para>
In case of GCM, the SEQIV implementation is registered as GIVCIPHER
in crypto_rfc4106_alloc().
</para>
<para>
The SEQIV performs its operation to generate an IV where the core
function is seqiv_geniv().
</para>
</listitem>
<listitem>
<para>
Now, SEQIV uses the AEAD API function calls to invoke the associated
AEAD cipher. In our case, during the instantiation of SEQIV, the
cipher handle for GCM is provided to SEQIV. This means that SEQIV
invokes AEAD cipher operations with the GCM cipher handle.
</para>
<para>
During instantiation of the GCM handle, the CTR(AES) and GHASH
ciphers are instantiated. The cipher handles for CTR(AES) and GHASH
are retained for later use.
</para>
<para>
The GCM implementation is responsible to invoke the CTR mode AES and
the GHASH cipher in the right manner to implement the GCM
specification.
</para>
</listitem>
<listitem>
<para>
The GCM AEAD cipher type implementation now invokes the ABLKCIPHER API
with the instantiated CTR(AES) cipher handle.
</para>
<para>
During instantiation of the CTR(AES) cipher, the CIPHER type
implementation of AES is instantiated. The cipher handle for AES is
retained.
</para>
<para>
That means that the ABLKCIPHER implementation of CTR(AES) only
implements the CTR block chaining mode. After performing the block
chaining operation, the CIPHER implementation of AES is invoked.
</para>
</listitem>
<listitem>
<para>
The ABLKCIPHER of CTR(AES) now invokes the CIPHER API with the AES
cipher handle to encrypt one block.
</para>
</listitem>
<listitem>
<para>
The GCM AEAD implementation also invokes the GHASH cipher
implementation via the AHASH API.
</para>
</listitem>
</orderedlist>
<para>
When the IPSEC layer triggers the esp_input() function, the same call
sequence is followed with the only difference that the operation starts
with step (2).
</para>
</sect2>
<sect2><title>Generic Block Cipher Structure</title>
<para>
Generic block ciphers follow the same concept as depicted with the ASCII
art picture above.
</para>
<para>
For example, CBC(AES) is implemented with cbc.c, and aes-generic.c. The
ASCII art picture above applies as well with the difference that only
step (4) is used and the ABLKCIPHER block chaining mode is CBC.
</para>
</sect2>
<sect2><title>Generic Keyed Message Digest Structure</title>
<para>
Keyed message digest implementations again follow the same concept as
depicted in the ASCII art picture above.
</para>
<para>
For example, HMAC(SHA256) is implemented with hmac.c and
sha256_generic.c. The following ASCII art illustrates the
implementation:
</para>
<programlisting>
<![CDATA[
kernel crypto API | Caller
|
+-----------+ (1) |
| | <------------------ some_function
| ahash |
| (hmac) | ---+
+-----------+ |
| (2)
+-----------+ |
| | <--+
| shash |
| (sha256) |
+-----------+
]]>
</programlisting>
<para>
The following call sequence is applicable when a caller triggers
an HMAC operation:
</para>
<orderedlist>
<listitem>
<para>
The AHASH API functions are invoked by the caller. The HMAC
implementation performs its operation as needed.
</para>
<para>
During initialization of the HMAC cipher, the SHASH cipher type of
SHA256 is instantiated. The cipher handle for the SHA256 instance is
retained.
</para>
<para>
At one time, the HMAC implementation requires a SHA256 operation
where the SHA256 cipher handle is used.
</para>
</listitem>
<listitem>
<para>
The HMAC instance now invokes the SHASH API with the SHA256
cipher handle to calculate the message digest.
</para>
</listitem>
</orderedlist>
</sect2>
</sect1>
</chapter>
<chapter id="Development"><title>Developing Cipher Algorithms</title>
@@ -808,10 +1072,616 @@
</sect1>
</chapter>
<chapter id="User"><title>User Space Interface</title>
<sect1><title>Introduction</title>
<para>
The concepts of the kernel crypto API visible to kernel space is fully
applicable to the user space interface as well. Therefore, the kernel
crypto API high level discussion for the in-kernel use cases applies
here as well.
</para>
<para>
The major difference, however, is that user space can only act as a
consumer and never as a provider of a transformation or cipher algorithm.
</para>
<para>
The following covers the user space interface exported by the kernel
crypto API. A working example of this description is libkcapi that
can be obtained from [1]. That library can be used by user space
applications that require cryptographic services from the kernel.
</para>
<para>
Some details of the in-kernel kernel crypto API aspects do not
apply to user space, however. This includes the difference between
synchronous and asynchronous invocations. The user space API call
is fully synchronous.
</para>
<para>
[1] http://www.chronox.de/libkcapi.html
</para>
</sect1>
<sect1><title>User Space API General Remarks</title>
<para>
The kernel crypto API is accessible from user space. Currently,
the following ciphers are accessible:
</para>
<itemizedlist>
<listitem>
<para>Message digest including keyed message digest (HMAC, CMAC)</para>
</listitem>
<listitem>
<para>Symmetric ciphers</para>
</listitem>
<listitem>
<para>AEAD ciphers</para>
</listitem>
<listitem>
<para>Random Number Generators</para>
</listitem>
</itemizedlist>
<para>
The interface is provided via socket type using the type AF_ALG.
In addition, the setsockopt option type is SOL_ALG. In case the
user space header files do not export these flags yet, use the
following macros:
</para>
<programlisting>
#ifndef AF_ALG
#define AF_ALG 38
#endif
#ifndef SOL_ALG
#define SOL_ALG 279
#endif
</programlisting>
<para>
A cipher is accessed with the same name as done for the in-kernel
API calls. This includes the generic vs. unique naming schema for
ciphers as well as the enforcement of priorities for generic names.
</para>
<para>
To interact with the kernel crypto API, a socket must be
created by the user space application. User space invokes the cipher
operation with the send()/write() system call family. The result of the
cipher operation is obtained with the read()/recv() system call family.
</para>
<para>
The following API calls assume that the socket descriptor
is already opened by the user space application and discusses only
the kernel crypto API specific invocations.
</para>
<para>
To initialize the socket interface, the following sequence has to
be performed by the consumer:
</para>
<orderedlist>
<listitem>
<para>
Create a socket of type AF_ALG with the struct sockaddr_alg
parameter specified below for the different cipher types.
</para>
</listitem>
<listitem>
<para>
Invoke bind with the socket descriptor
</para>
</listitem>
<listitem>
<para>
Invoke accept with the socket descriptor. The accept system call
returns a new file descriptor that is to be used to interact with
the particular cipher instance. When invoking send/write or recv/read
system calls to send data to the kernel or obtain data from the
kernel, the file descriptor returned by accept must be used.
</para>
</listitem>
</orderedlist>
</sect1>
<sect1><title>In-place Cipher operation</title>
<para>
Just like the in-kernel operation of the kernel crypto API, the user
space interface allows the cipher operation in-place. That means that
the input buffer used for the send/write system call and the output
buffer used by the read/recv system call may be one and the same.
This is of particular interest for symmetric cipher operations where a
copying of the output data to its final destination can be avoided.
</para>
<para>
If a consumer on the other hand wants to maintain the plaintext and
the ciphertext in different memory locations, all a consumer needs
to do is to provide different memory pointers for the encryption and
decryption operation.
</para>
</sect1>
<sect1><title>Message Digest API</title>
<para>
The message digest type to be used for the cipher operation is
selected when invoking the bind syscall. bind requires the caller
to provide a filled struct sockaddr data structure. This data
structure must be filled as follows:
</para>
<programlisting>
struct sockaddr_alg sa = {
.salg_family = AF_ALG,
.salg_type = "hash", /* this selects the hash logic in the kernel */
.salg_name = "sha1" /* this is the cipher name */
};
</programlisting>
<para>
The salg_type value "hash" applies to message digests and keyed
message digests. Though, a keyed message digest is referenced by
the appropriate salg_name. Please see below for the setsockopt
interface that explains how the key can be set for a keyed message
digest.
</para>
<para>
Using the send() system call, the application provides the data that
should be processed with the message digest. The send system call
allows the following flags to be specified:
</para>
<itemizedlist>
<listitem>
<para>
MSG_MORE: If this flag is set, the send system call acts like a
message digest update function where the final hash is not
yet calculated. If the flag is not set, the send system call
calculates the final message digest immediately.
</para>
</listitem>
</itemizedlist>
<para>
With the recv() system call, the application can read the message
digest from the kernel crypto API. If the buffer is too small for the
message digest, the flag MSG_TRUNC is set by the kernel.
</para>
<para>
In order to set a message digest key, the calling application must use
the setsockopt() option of ALG_SET_KEY. If the key is not set the HMAC
operation is performed without the initial HMAC state change caused by
the key.
</para>
</sect1>
<sect1><title>Symmetric Cipher API</title>
<para>
The operation is very similar to the message digest discussion.
During initialization, the struct sockaddr data structure must be
filled as follows:
</para>
<programlisting>
struct sockaddr_alg sa = {
.salg_family = AF_ALG,
.salg_type = "skcipher", /* this selects the symmetric cipher */
.salg_name = "cbc(aes)" /* this is the cipher name */
};
</programlisting>
<para>
Before data can be sent to the kernel using the write/send system
call family, the consumer must set the key. The key setting is
described with the setsockopt invocation below.
</para>
<para>
Using the sendmsg() system call, the application provides the data that should be processed for encryption or decryption. In addition, the IV is
specified with the data structure provided by the sendmsg() system call.
</para>
<para>
The sendmsg system call parameter of struct msghdr is embedded into the
struct cmsghdr data structure. See recv(2) and cmsg(3) for more
information on how the cmsghdr data structure is used together with the
send/recv system call family. That cmsghdr data structure holds the
following information specified with a separate header instances:
</para>
<itemizedlist>
<listitem>
<para>
specification of the cipher operation type with one of these flags:
</para>
<itemizedlist>
<listitem>
<para>ALG_OP_ENCRYPT - encryption of data</para>
</listitem>
<listitem>
<para>ALG_OP_DECRYPT - decryption of data</para>
</listitem>
</itemizedlist>
</listitem>
<listitem>
<para>
specification of the IV information marked with the flag ALG_SET_IV
</para>
</listitem>
</itemizedlist>
<para>
The send system call family allows the following flag to be specified:
</para>
<itemizedlist>
<listitem>
<para>
MSG_MORE: If this flag is set, the send system call acts like a
cipher update function where more input data is expected
with a subsequent invocation of the send system call.
</para>
</listitem>
</itemizedlist>
<para>
Note: The kernel reports -EINVAL for any unexpected data. The caller
must make sure that all data matches the constraints given in
/proc/crypto for the selected cipher.
</para>
<para>
With the recv() system call, the application can read the result of
the cipher operation from the kernel crypto API. The output buffer
must be at least as large as to hold all blocks of the encrypted or
decrypted data. If the output data size is smaller, only as many
blocks are returned that fit into that output buffer size.
</para>
</sect1>
<sect1><title>AEAD Cipher API</title>
<para>
The operation is very similar to the symmetric cipher discussion.
During initialization, the struct sockaddr data structure must be
filled as follows:
</para>
<programlisting>
struct sockaddr_alg sa = {
.salg_family = AF_ALG,
.salg_type = "aead", /* this selects the symmetric cipher */
.salg_name = "gcm(aes)" /* this is the cipher name */
};
</programlisting>
<para>
Before data can be sent to the kernel using the write/send system
call family, the consumer must set the key. The key setting is
described with the setsockopt invocation below.
</para>
<para>
In addition, before data can be sent to the kernel using the
write/send system call family, the consumer must set the authentication
tag size. To set the authentication tag size, the caller must use the
setsockopt invocation described below.
</para>
<para>
Using the sendmsg() system call, the application provides the data that should be processed for encryption or decryption. In addition, the IV is
specified with the data structure provided by the sendmsg() system call.
</para>
<para>
The sendmsg system call parameter of struct msghdr is embedded into the
struct cmsghdr data structure. See recv(2) and cmsg(3) for more
information on how the cmsghdr data structure is used together with the
send/recv system call family. That cmsghdr data structure holds the
following information specified with a separate header instances:
</para>
<itemizedlist>
<listitem>
<para>
specification of the cipher operation type with one of these flags:
</para>
<itemizedlist>
<listitem>
<para>ALG_OP_ENCRYPT - encryption of data</para>
</listitem>
<listitem>
<para>ALG_OP_DECRYPT - decryption of data</para>
</listitem>
</itemizedlist>
</listitem>
<listitem>
<para>
specification of the IV information marked with the flag ALG_SET_IV
</para>
</listitem>
<listitem>
<para>
specification of the associated authentication data (AAD) with the
flag ALG_SET_AEAD_ASSOCLEN. The AAD is sent to the kernel together
with the plaintext / ciphertext. See below for the memory structure.
</para>
</listitem>
</itemizedlist>
<para>
The send system call family allows the following flag to be specified:
</para>
<itemizedlist>
<listitem>
<para>
MSG_MORE: If this flag is set, the send system call acts like a
cipher update function where more input data is expected
with a subsequent invocation of the send system call.
</para>
</listitem>
</itemizedlist>
<para>
Note: The kernel reports -EINVAL for any unexpected data. The caller
must make sure that all data matches the constraints given in
/proc/crypto for the selected cipher.
</para>
<para>
With the recv() system call, the application can read the result of
the cipher operation from the kernel crypto API. The output buffer
must be at least as large as defined with the memory structure below.
If the output data size is smaller, the cipher operation is not performed.
</para>
<para>
The authenticated decryption operation may indicate an integrity error.
Such breach in integrity is marked with the -EBADMSG error code.
</para>
<sect2><title>AEAD Memory Structure</title>
<para>
The AEAD cipher operates with the following information that
is communicated between user and kernel space as one data stream:
</para>
<itemizedlist>
<listitem>
<para>plaintext or ciphertext</para>
</listitem>
<listitem>
<para>associated authentication data (AAD)</para>
</listitem>
<listitem>
<para>authentication tag</para>
</listitem>
</itemizedlist>
<para>
The sizes of the AAD and the authentication tag are provided with
the sendmsg and setsockopt calls (see there). As the kernel knows
the size of the entire data stream, the kernel is now able to
calculate the right offsets of the data components in the data
stream.
</para>
<para>
The user space caller must arrange the aforementioned information
in the following order:
</para>
<itemizedlist>
<listitem>
<para>
AEAD encryption input: AAD || plaintext
</para>
</listitem>
<listitem>
<para>
AEAD decryption input: AAD || ciphertext || authentication tag
</para>
</listitem>
</itemizedlist>
<para>
The output buffer the user space caller provides must be at least as
large to hold the following data:
</para>
<itemizedlist>
<listitem>
<para>
AEAD encryption output: ciphertext || authentication tag
</para>
</listitem>
<listitem>
<para>
AEAD decryption output: plaintext
</para>
</listitem>
</itemizedlist>
</sect2>
</sect1>
<sect1><title>Random Number Generator API</title>
<para>
Again, the operation is very similar to the other APIs.
During initialization, the struct sockaddr data structure must be
filled as follows:
</para>
<programlisting>
struct sockaddr_alg sa = {
.salg_family = AF_ALG,
.salg_type = "rng", /* this selects the symmetric cipher */
.salg_name = "drbg_nopr_sha256" /* this is the cipher name */
};
</programlisting>
<para>
Depending on the RNG type, the RNG must be seeded. The seed is provided
using the setsockopt interface to set the key. For example, the
ansi_cprng requires a seed. The DRBGs do not require a seed, but
may be seeded.
</para>
<para>
Using the read()/recvmsg() system calls, random numbers can be obtained.
The kernel generates at most 128 bytes in one call. If user space
requires more data, multiple calls to read()/recvmsg() must be made.
</para>
<para>
WARNING: The user space caller may invoke the initially mentioned
accept system call multiple times. In this case, the returned file
descriptors have the same state.
</para>
</sect1>
<sect1><title>Zero-Copy Interface</title>
<para>
In addition to the send/write/read/recv system call family, the AF_ALG
interface can be accessed with the zero-copy interface of splice/vmsplice.
As the name indicates, the kernel tries to avoid a copy operation into
kernel space.
</para>
<para>
The zero-copy operation requires data to be aligned at the page boundary.
Non-aligned data can be used as well, but may require more operations of
the kernel which would defeat the speed gains obtained from the zero-copy
interface.
</para>
<para>
The system-interent limit for the size of one zero-copy operation is
16 pages. If more data is to be sent to AF_ALG, user space must slice
the input into segments with a maximum size of 16 pages.
</para>
<para>
Zero-copy can be used with the following code example (a complete working
example is provided with libkcapi):
</para>
<programlisting>
int pipes[2];
pipe(pipes);
/* input data in iov */
vmsplice(pipes[1], iov, iovlen, SPLICE_F_GIFT);
/* opfd is the file descriptor returned from accept() system call */
splice(pipes[0], NULL, opfd, NULL, ret, 0);
read(opfd, out, outlen);
</programlisting>
</sect1>
<sect1><title>Setsockopt Interface</title>
<para>
In addition to the read/recv and send/write system call handling
to send and retrieve data subject to the cipher operation, a consumer
also needs to set the additional information for the cipher operation.
This additional information is set using the setsockopt system call
that must be invoked with the file descriptor of the open cipher
(i.e. the file descriptor returned by the accept system call).
</para>
<para>
Each setsockopt invocation must use the level SOL_ALG.
</para>
<para>
The setsockopt interface allows setting the following data using
the mentioned optname:
</para>
<itemizedlist>
<listitem>
<para>
ALG_SET_KEY -- Setting the key. Key setting is applicable to:
</para>
<itemizedlist>
<listitem>
<para>the skcipher cipher type (symmetric ciphers)</para>
</listitem>
<listitem>
<para>the hash cipher type (keyed message digests)</para>
</listitem>
<listitem>
<para>the AEAD cipher type</para>
</listitem>
<listitem>
<para>the RNG cipher type to provide the seed</para>
</listitem>
</itemizedlist>
</listitem>
<listitem>
<para>
ALG_SET_AEAD_AUTHSIZE -- Setting the authentication tag size
for AEAD ciphers. For a encryption operation, the authentication
tag of the given size will be generated. For a decryption operation,
the provided ciphertext is assumed to contain an authentication tag
of the given size (see section about AEAD memory layout below).
</para>
</listitem>
</itemizedlist>
</sect1>
<sect1><title>User space API example</title>
<para>
Please see [1] for libkcapi which provides an easy-to-use wrapper
around the aforementioned Netlink kernel interface. [1] also contains
a test application that invokes all libkcapi API calls.
</para>
<para>
[1] http://www.chronox.de/libkcapi.html
</para>
</sect1>
</chapter>
<chapter id="API"><title>Programming Interface</title>
<para>
Please note that the kernel crypto API contains the AEAD givcrypt
API (crypto_aead_giv* and aead_givcrypt_* function calls in
include/crypto/aead.h). This API is obsolete and will be removed
in the future. To obtain the functionality of an AEAD cipher with
internal IV generation, use the IV generator as a regular cipher.
For example, rfc4106(gcm(aes)) is the AEAD cipher with external
IV generation and seqniv(rfc4106(gcm(aes))) implies that the kernel
crypto API generates the IV. Different IV generators are available.
</para>
<sect1><title>Block Cipher Context Data Structures</title>
!Pinclude/linux/crypto.h Block Cipher Context Data Structures
!Finclude/linux/crypto.h aead_request
!Finclude/crypto/aead.h aead_request
</sect1>
<sect1><title>Block Cipher Algorithm Definitions</title>
!Pinclude/linux/crypto.h Block Cipher Algorithm Definitions
@@ -820,7 +1690,7 @@
!Finclude/linux/crypto.h aead_alg
!Finclude/linux/crypto.h blkcipher_alg
!Finclude/linux/crypto.h cipher_alg
!Finclude/linux/crypto.h rng_alg
!Finclude/crypto/rng.h rng_alg
</sect1>
<sect1><title>Asynchronous Block Cipher API</title>
!Pinclude/linux/crypto.h Asynchronous Block Cipher API
@@ -844,26 +1714,27 @@
!Finclude/linux/crypto.h ablkcipher_request_set_crypt
</sect1>
<sect1><title>Authenticated Encryption With Associated Data (AEAD) Cipher API</title>
!Pinclude/linux/crypto.h Authenticated Encryption With Associated Data (AEAD) Cipher API
!Finclude/linux/crypto.h crypto_alloc_aead
!Finclude/linux/crypto.h crypto_free_aead
!Finclude/linux/crypto.h crypto_aead_ivsize
!Finclude/linux/crypto.h crypto_aead_authsize
!Finclude/linux/crypto.h crypto_aead_blocksize
!Finclude/linux/crypto.h crypto_aead_setkey
!Finclude/linux/crypto.h crypto_aead_setauthsize
!Finclude/linux/crypto.h crypto_aead_encrypt
!Finclude/linux/crypto.h crypto_aead_decrypt
!Pinclude/crypto/aead.h Authenticated Encryption With Associated Data (AEAD) Cipher API
!Finclude/crypto/aead.h crypto_alloc_aead
!Finclude/crypto/aead.h crypto_free_aead
!Finclude/crypto/aead.h crypto_aead_ivsize
!Finclude/crypto/aead.h crypto_aead_authsize
!Finclude/crypto/aead.h crypto_aead_blocksize
!Finclude/crypto/aead.h crypto_aead_setkey
!Finclude/crypto/aead.h crypto_aead_setauthsize
!Finclude/crypto/aead.h crypto_aead_encrypt
!Finclude/crypto/aead.h crypto_aead_decrypt
</sect1>
<sect1><title>Asynchronous AEAD Request Handle</title>
!Pinclude/linux/crypto.h Asynchronous AEAD Request Handle
!Finclude/linux/crypto.h crypto_aead_reqsize
!Finclude/linux/crypto.h aead_request_set_tfm
!Finclude/linux/crypto.h aead_request_alloc
!Finclude/linux/crypto.h aead_request_free
!Finclude/linux/crypto.h aead_request_set_callback
!Finclude/linux/crypto.h aead_request_set_crypt
!Finclude/linux/crypto.h aead_request_set_assoc
!Pinclude/crypto/aead.h Asynchronous AEAD Request Handle
!Finclude/crypto/aead.h crypto_aead_reqsize
!Finclude/crypto/aead.h aead_request_set_tfm
!Finclude/crypto/aead.h aead_request_alloc
!Finclude/crypto/aead.h aead_request_free
!Finclude/crypto/aead.h aead_request_set_callback
!Finclude/crypto/aead.h aead_request_set_crypt
!Finclude/crypto/aead.h aead_request_set_assoc
!Finclude/crypto/aead.h aead_request_set_ad
</sect1>
<sect1><title>Synchronous Block Cipher API</title>
!Pinclude/linux/crypto.h Synchronous Block Cipher API

97
Documentation/DocBook/drm.tmpl
View File

@@ -1293,7 +1293,7 @@ int max_width, max_height;</synopsis>
</para>
<para>
If a page flip can be successfully scheduled the driver must set the
<code>drm_crtc-&lt;fb</code> field to the new framebuffer pointed to
<code>drm_crtc-&gt;fb</code> field to the new framebuffer pointed to
by <code>fb</code>. This is important so that the reference counting
on framebuffers stays balanced.
</para>
@@ -2439,6 +2439,18 @@ void intel_crt_init(struct drm_device *dev)
<title>Tile group</title>
!Pdrivers/gpu/drm/drm_crtc.c Tile group
</sect2>
<sect2>
<title>Bridges</title>
<sect3>
<title>Overview</title>
!Pdrivers/gpu/drm/drm_bridge.c overview
</sect3>
<sect3>
<title>Default bridge callback sequence</title>
!Pdrivers/gpu/drm/drm_bridge.c bridge callbacks
</sect3>
!Edrivers/gpu/drm/drm_bridge.c
</sect2>
</sect1>
<!-- Internals: kms properties -->
@@ -2573,7 +2585,22 @@ void intel_crt_init(struct drm_device *dev)
<td valign="top" >Description/Restrictions</td>
</tr>
<tr>
<td rowspan="36" valign="top" >DRM</td>
<td rowspan="37" valign="top" >DRM</td>
<td valign="top" >Generic</td>
<td valign="top" >“rotation”</td>
<td valign="top" >BITMASK</td>
<td valign="top" >{ 0, "rotate-0" },
{ 1, "rotate-90" },
{ 2, "rotate-180" },
{ 3, "rotate-270" },
{ 4, "reflect-x" },
{ 5, "reflect-y" }</td>
<td valign="top" >CRTC, Plane</td>
<td valign="top" >rotate-(degrees) rotates the image by the specified amount in degrees
in counter clockwise direction. reflect-x and reflect-y reflects the
image along the specified axis prior to rotation</td>
</tr>
<tr>
<td rowspan="5" valign="top" >Connector</td>
<td valign="top" >“EDID”</td>
<td valign="top" >BLOB | IMMUTABLE</td>
@@ -2834,7 +2861,7 @@ void intel_crt_init(struct drm_device *dev)
<td valign="top" >TBD</td>
</tr>
<tr>
<td rowspan="21" valign="top" >i915</td>
<td rowspan="20" valign="top" >i915</td>
<td rowspan="2" valign="top" >Generic</td>
<td valign="top" >"Broadcast RGB"</td>
<td valign="top" >ENUM</td>
@@ -2850,14 +2877,6 @@ void intel_crt_init(struct drm_device *dev)
<td valign="top" >TBD</td>
</tr>
<tr>
<td rowspan="1" valign="top" >Plane</td>
<td valign="top" >“rotation”</td>
<td valign="top" >BITMASK</td>
<td valign="top" >{ 0, "rotate-0" }, { 2, "rotate-180" }</td>
<td valign="top" >Plane</td>
<td valign="top" >TBD</td>
</tr>
<tr>
<td rowspan="17" valign="top" >SDVO-TV</td>
<td valign="top" >“mode”</td>
<td valign="top" >ENUM</td>
@@ -3364,20 +3383,8 @@ void intel_crt_init(struct drm_device *dev)
<td valign="top" >TBD</td>
</tr>
<tr>
<td rowspan="2" valign="top" >omap</td>
<td rowspan="2" valign="top" >Generic</td>
<td valign="top" >“rotation”</td>
<td valign="top" >BITMASK</td>
<td valign="top" >{ 0, "rotate-0" },
{ 1, "rotate-90" },
{ 2, "rotate-180" },
{ 3, "rotate-270" },
{ 4, "reflect-x" },
{ 5, "reflect-y" }</td>
<td valign="top" >CRTC, Plane</td>
<td valign="top" >TBD</td>
</tr>
<tr>
<td valign="top" >omap</td>
<td valign="top" >Generic</td>
<td valign="top" >“zorder”</td>
<td valign="top" >RANGE</td>
<td valign="top" >Min=0, Max=3</td>
@@ -3979,6 +3986,11 @@ int num_ioctls;</synopsis>
!Fdrivers/gpu/drm/i915/i915_irq.c intel_runtime_pm_disable_interrupts
!Fdrivers/gpu/drm/i915/i915_irq.c intel_runtime_pm_enable_interrupts
</sect2>
<sect2>
<title>Intel GVT-g Guest Support(vGPU)</title>
!Pdrivers/gpu/drm/i915/i915_vgpu.c Intel GVT-g guest support
!Idrivers/gpu/drm/i915/i915_vgpu.c
</sect2>
</sect1>
<sect1>
<title>Display Hardware Handling</title>
@@ -4046,12 +4058,23 @@ int num_ioctls;</synopsis>
<title>Frame Buffer Compression (FBC)</title>
!Pdrivers/gpu/drm/i915/intel_fbc.c Frame Buffer Compression (FBC)
!Idrivers/gpu/drm/i915/intel_fbc.c
</sect2>
<sect2>
<title>Display Refresh Rate Switching (DRRS)</title>
!Pdrivers/gpu/drm/i915/intel_dp.c Display Refresh Rate Switching (DRRS)
!Fdrivers/gpu/drm/i915/intel_dp.c intel_dp_set_drrs_state
!Fdrivers/gpu/drm/i915/intel_dp.c intel_edp_drrs_enable
!Fdrivers/gpu/drm/i915/intel_dp.c intel_edp_drrs_disable
!Fdrivers/gpu/drm/i915/intel_dp.c intel_edp_drrs_invalidate
!Fdrivers/gpu/drm/i915/intel_dp.c intel_edp_drrs_flush
!Fdrivers/gpu/drm/i915/intel_dp.c intel_dp_drrs_init
</sect2>
<sect2>
<title>DPIO</title>
!Pdrivers/gpu/drm/i915/i915_reg.h DPIO
<table id="dpiox2">
<title>Dual channel PHY (VLV/CHV)</title>
<title>Dual channel PHY (VLV/CHV/BXT)</title>
<tgroup cols="8">
<colspec colname="c0" />
<colspec colname="c1" />
@@ -4102,7 +4125,7 @@ int num_ioctls;</synopsis>
</tgroup>
</table>
<table id="dpiox1">
<title>Single channel PHY (CHV)</title>
<title>Single channel PHY (CHV/BXT)</title>
<tgroup cols="4">
<colspec colname="c0" />
<colspec colname="c1" />
@@ -4137,6 +4160,12 @@ int num_ioctls;</synopsis>
</tgroup>
</table>
</sect2>
<sect2>
<title>CSR firmware support for DMC</title>
!Pdrivers/gpu/drm/i915/intel_csr.c csr support for dmc
!Idrivers/gpu/drm/i915/intel_csr.c
</sect2>
</sect1>
<sect1>
@@ -4168,7 +4197,7 @@ int num_ioctls;</synopsis>
<sect2>
<title>Buffer Object Eviction</title>
<para>
This section documents the interface function for evicting buffer
This section documents the interface functions for evicting buffer
objects to make space available in the virtual gpu address spaces.
Note that this is mostly orthogonal to shrinking buffer objects
caches, which has the goal to make main memory (shared with the gpu
@@ -4176,8 +4205,18 @@ int num_ioctls;</synopsis>
</para>
!Idrivers/gpu/drm/i915/i915_gem_evict.c
</sect2>
<sect2>
<title>Buffer Object Memory Shrinking</title>
<para>
This section documents the interface function for shrinking memory
usage of buffer object caches. Shrinking is used to make main memory
available. Note that this is mostly orthogonal to evicting buffer
objects, which has the goal to make space in gpu virtual address
spaces.
</para>
!Idrivers/gpu/drm/i915/i915_gem_shrinker.c
</sect2>
</sect1>
<sect1>
<title> Tracing </title>
<para>

2
Documentation/DocBook/kernel-hacking.tmpl
View File

@@ -954,6 +954,8 @@ printk(KERN_INFO "my ip: %pI4\n", &amp;ipaddress);
<function>MODULE_LICENSE()</function> that specifies a GPL
compatible license. It implies that the function is considered
an internal implementation issue, and not really an interface.
Some maintainers and developers may however
require EXPORT_SYMBOL_GPL() when adding any new APIs or functionality.
</para>
</sect1>
</chapter>

1
Documentation/DocBook/media/.gitignore vendored Normal file
View File

@@ -0,0 +1 @@
!*.svg

88
Documentation/DocBook/media/Makefile
View File

@@ -65,29 +65,31 @@ IOCTLS = \
$(shell perl -ne 'print "$$1 " if /\#define\s+([^\s]+)\s+_IO/' $(srctree)/include/uapi/linux/dvb/video.h) \
$(shell perl -ne 'print "$$1 " if /\#define\s+([^\s]+)\s+_IO/' $(srctree)/include/uapi/linux/media.h) \
$(shell perl -ne 'print "$$1 " if /\#define\s+([^\s]+)\s+_IO/' $(srctree)/include/uapi/linux/v4l2-subdev.h) \
VIDIOC_SUBDEV_G_FRAME_INTERVAL \
VIDIOC_SUBDEV_S_FRAME_INTERVAL \
VIDIOC_SUBDEV_ENUM_MBUS_CODE \
VIDIOC_SUBDEV_ENUM_FRAME_SIZE \
VIDIOC_SUBDEV_ENUM_FRAME_INTERVAL \
VIDIOC_SUBDEV_G_SELECTION \
VIDIOC_SUBDEV_S_SELECTION \
DEFINES = \
$(shell perl -ne 'print "$$1 " if /\#define\s+(DTV_[^\s]+)\s+/' $(srctree)/include/uapi/linux/dvb/frontend.h) \
TYPES = \
$(shell perl -ne 'print "$$1 " if /^typedef\s+[^\s]+\s+([^\s]+)\;/' $(srctree)/include/uapi/linux/videodev2.h) \
$(shell perl -ne 'print "$$1 " if /^}\s+([a-z0-9_]+_t)/' $(srctree)/include/uapi/linux/dvb/frontend.h)
$(shell perl -ne 'print "$$1 " if /^typedef\s+.*\s+(\S+)\;/' $(srctree)/include/uapi/linux/videodev2.h) \
$(shell perl -ne 'print "$$1 " if /^typedef\s+.*\s+(\S+)\;/' $(srctree)/include/uapi/linux/dvb/frontend.h)
ENUMS = \
$(shell perl -ne 'print "$$1 " if /^enum\s+([^\s]+)\s+/' $(srctree)/include/uapi/linux/videodev2.h) \
$(shell perl -ne 'print "$$1 " if /^enum\s+([^\s]+)\s+/' $(srctree)/include/uapi/linux/dvb/audio.h) \
$(shell perl -ne 'print "$$1 " if /^enum\s+([^\s]+)\s+/' $(srctree)/include/uapi/linux/dvb/ca.h) \
$(shell perl -ne 'print "$$1 " if /^enum\s+([^\s]+)\s+/' $(srctree)/include/uapi/linux/dvb/dmx.h) \
$(shell perl -ne 'print "$$1 " if /^enum\s+([^\s]+)\s+/' $(srctree)/include/uapi/linux/dvb/frontend.h) \
$(shell perl -ne 'print "$$1 " if /^enum\s+([^\s]+)\s+/' $(srctree)/include/uapi/linux/dvb/net.h) \
$(shell perl -ne 'print "$$1 " if /^enum\s+([^\s]+)\s+/' $(srctree)/include/uapi/linux/dvb/video.h) \
$(shell perl -ne 'print "$$1 " if /^enum\s+([^\s]+)\s+/' $(srctree)/include/uapi/linux/media.h) \
$(shell perl -ne 'print "$$1 " if /^enum\s+([^\s]+)\s+/' $(srctree)/include/uapi/linux/v4l2-mediabus.h) \
$(shell perl -ne 'print "$$1 " if /^enum\s+([^\s]+)\s+/' $(srctree)/include/uapi/linux/v4l2-subdev.h)
$(shell perl -ne 'print "$$1 " if /^enum\s+([^\s]+)\s+/' \
$(srctree)/include/uapi/linux/videodev2.h \
$(srctree)/include/uapi/linux/dvb/audio.h \
$(srctree)/include/uapi/linux/dvb/ca.h \
$(srctree)/include/uapi/linux/dvb/dmx.h \
$(srctree)/include/uapi/linux/dvb/frontend.h \
$(srctree)/include/uapi/linux/dvb/net.h \
$(srctree)/include/uapi/linux/dvb/video.h \
$(srctree)/include/uapi/linux/media.h \
$(srctree)/include/uapi/linux/v4l2-mediabus.h \
$(srctree)/include/uapi/linux/v4l2-subdev.h)
ENUM_DEFS = \
$(shell perl -e 'open IN,"cat @ARGV| cpp -fpreprocessed |"; while (<IN>) { if ($$enum) {print "$$1\n" if (/\s*([A-Z]\S+)\b/); } $$enum = 0 if ($$enum && /^\}/); $$enum = 1 if(/^\s*enum\s/); }; close IN;' \
$(srctree)/include/uapi/linux/dvb/dmx.h \
$(srctree)/include/uapi/linux/dvb/frontend.h)
STRUCTS = \
$(shell perl -ne 'print "$$1 " if /^struct\s+([^\s]+)\s+/' $(srctree)/include/uapi/linux/videodev2.h) \
@@ -95,7 +97,7 @@ STRUCTS = \
$(shell perl -ne 'print "$$1 " if (/^struct\s+([^\s]+)\s+/)' $(srctree)/include/uapi/linux/dvb/ca.h) \
$(shell perl -ne 'print "$$1 " if (/^struct\s+([^\s]+)\s+/)' $(srctree)/include/uapi/linux/dvb/dmx.h) \
$(shell perl -ne 'print "$$1 " if (!/dtv\_cmds\_h/ && /^struct\s+([^\s]+)\s+/)' $(srctree)/include/uapi/linux/dvb/frontend.h) \
$(shell perl -ne 'print "$$1 " if (/^struct\s+([A-Z][^\s]+)\s+/)' $(srctree)/include/uapi/linux/dvb/net.h) \
$(shell perl -ne 'print "$$1 " if (/^struct\s+([^\s]+)\s+/ && !/_old/)' $(srctree)/include/uapi/linux/dvb/net.h) \
$(shell perl -ne 'print "$$1 " if (/^struct\s+([^\s]+)\s+/)' $(srctree)/include/uapi/linux/dvb/video.h) \
$(shell perl -ne 'print "$$1 " if /^struct\s+([^\s]+)\s+/' $(srctree)/include/uapi/linux/media.h) \
$(shell perl -ne 'print "$$1 " if /^struct\s+([^\s]+)\s+/' $(srctree)/include/uapi/linux/v4l2-subdev.h) \
@@ -179,7 +181,6 @@ DOCUMENTED = \
-e "s/v4l2\-mpeg\-vbi\-ITV0/v4l2-mpeg-vbi-itv0-1/g"
DVB_DOCUMENTED = \
-e "s/\(linkend\=\"\)FE_SET_PROPERTY/\1FE_GET_PROPERTY/g" \
-e "s,\(struct\s\+\)\([a-z0-9_]\+\)\(\s\+{\),\1\<link linkend=\"\2\">\2\<\/link\>\3,g" \
-e "s,\(}\s\+\)\([a-z0-9_]\+_t\+\),\1\<link linkend=\"\2\">\2\<\/link\>,g" \
-e "s,\(define\s\+\)\(DTV_[A-Z0-9_]\+\)\(\s\+[0-9]\+\),\1\<link linkend=\"\2\">\2\<\/link\>\3,g" \
@@ -188,14 +189,17 @@ DVB_DOCUMENTED = \
-e "s,\(audio-mixer\|audio-karaoke\|audio-status\|ca-slot-info\|ca-descr-info\|ca-caps\|ca-msg\|ca-descr\|ca-pid\|dmx-filter\|dmx-caps\|video-system\|video-highlight\|video-spu\|video-spu-palette\|video-navi-pack\)-t,\1,g" \
-e "s,DTV-ISDBT-LAYER[A-C],DTV-ISDBT-LAYER,g" \
-e "s,\(define\s\+\)\([A-Z0-9_]\+\)\(\s\+_IO\),\1\<link linkend=\"\2\">\2\<\/link\>\3,g" \
-e "s,\(define\s\+\)\(DTV_[A-Z0-9_]\+\)\(\s\+\),\1\<link linkend=\"\2\">\2\<\/link\>\3,g" \
-e "s,<link\s\+linkend=\".*\">\(__.*_OLD\)<\/link>,\1,g" \
-e "s/\(linkend\=\"\)FE_SET_PROPERTY/\1FE_GET_PROPERTY/g" \
-e "s,<link\s\+linkend=\".*\">\(DTV_ISDBS_TS_ID_LEGACY\|DTV_MAX_COMMAND\|DTV_IOCTL_MAX_MSGS\)<\/link>,\1,g" \
#
# Media targets and dependencies
#
install_media_images = \
$(Q)-cp $(OBJIMGFILES) $(MEDIA_SRC_DIR)/v4l/*.svg $(MEDIA_OBJ_DIR)/media_api
$(Q)-cp $(OBJIMGFILES) $(MEDIA_SRC_DIR)/*.svg $(MEDIA_SRC_DIR)/v4l/*.svg $(MEDIA_OBJ_DIR)/media_api
$(MEDIA_OBJ_DIR)/%: $(MEDIA_SRC_DIR)/%.b64
$(Q)base64 -d $< >$@
@@ -243,9 +247,14 @@ $(MEDIA_OBJ_DIR)/dmx.h.xml: $(srctree)/include/uapi/linux/dvb/dmx.h $(MEDIA_OBJ_
@( \
echo "<programlisting>") > $@
@( \
for ident in $(ENUM_DEFS) ; do \
entity=`echo $$ident | tr _ -` ; \
r="$$r s/([^\w\-])$$ident([^\w\-])/\1\&$$entity\;\2/g;";\
done; \
expand --tabs=8 < $< | \
sed $(ESCAPE) $(DVB_DOCUMENTED) | \
sed 's/i\.e\./&ie;/') >> $@
sed 's/i\.e\./&ie;/' | \
perl -ne "$$r print $$_;") >> $@
@( \
echo "</programlisting>") >> $@
@@ -254,9 +263,14 @@ $(MEDIA_OBJ_DIR)/frontend.h.xml: $(srctree)/include/uapi/linux/dvb/frontend.h $(
@( \
echo "<programlisting>") > $@
@( \
for ident in $(ENUM_DEFS) ; do \
entity=`echo $$ident | tr _ -` ; \
r="$$r s/([^\w\-])$$ident([^\w\-])/\1\&$$entity\;\2/g;";\
done; \
expand --tabs=8 < $< | \
sed $(ESCAPE) $(DVB_DOCUMENTED) | \
sed 's/i\.e\./&ie;/') >> $@
sed 's/i\.e\./&ie;/' | \
perl -ne "$$r print $$_;") >> $@
@( \
echo "</programlisting>") >> $@
@@ -298,11 +312,22 @@ $(MEDIA_OBJ_DIR)/media-entities.tmpl: $(MEDIA_OBJ_DIR)/v4l2.xml
@( \
echo -e "\n<!-- Ioctls -->") >>$@
@( \
for ident in $(IOCTLS) ; do \
for ident in `echo $(IOCTLS) | sed -e "s,VIDIOC_RESERVED,,"`; do\
entity=`echo $$ident | tr _ -` ; \
id=`grep "<refname>$$ident" $(MEDIA_OBJ_DIR)/vidioc-*.xml $(MEDIA_OBJ_DIR)/media-ioc-*.xml | sed -r s,"^.*/(.*).xml.*","\1",` ; \
echo "<!ENTITY $$entity \"<link" \
id=`grep -e "<refname>$$ident" -e "<section id=\"$$ident\"" $$(find $(MEDIA_SRC_DIR) -name *.xml -type f)| sed -r s,"^.*/(.*).xml.*","\1",` ; \
if [ "$$id" != "" ]; then echo "<!ENTITY $$entity \"<link" \
"linkend='$$id'><constant>$$ident</constant></link>\">" \
>>$@ ; else \
echo "Warning: undocumented ioctl: $$ident. Please document it at the media DocBook!" >&2; \
fi; \
done)
@( \
echo -e "\n<!-- Defines -->") >>$@
@( \
for ident in $(DEFINES) ; do \
entity=`echo $$ident | tr _ -` ; \
echo "<!ENTITY $$entity \"<link" \
"linkend='$$entity'><constant>$$ident</constant></link>\">" \
>>$@ ; \
done)
@( \
@@ -322,6 +347,15 @@ $(MEDIA_OBJ_DIR)/media-entities.tmpl: $(MEDIA_OBJ_DIR)/v4l2.xml
"linkend='$$entity'>$$ident</link>\">" >>$@ ; \
done)
@( \
echo -e "\n<!-- Enum definitions -->") >>$@
@( \
for ident in $(ENUM_DEFS) ; do \
entity=`echo $$ident | tr _ -` ; \
echo "<!ENTITY $$entity \"<link" \
"linkend='$$entity'><constant>$$ident</constant></link>\">" \
>>$@ ; \
done)
@( \
echo -e "\n<!-- Structures -->") >>$@
@( \
for ident in $(STRUCTS) ; do \

6
Documentation/DocBook/media/dvb/audio.xml
View File

@@ -1,7 +1,7 @@
<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/audio.h</emphasis> in your
can be accessed through <constant>/dev/dvb/adapter?/audio?</constant>. Data types and and
ioctl definitions can be accessed by including <constant>linux/dvb/audio.h</constant> in your
application.
</para>
<para>Please note that some DVB cards don&#8217;t have their own MPEG decoder, which results in
@@ -32,7 +32,7 @@ typedef enum {
</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
is selected the stream comes from the application through the <constant>write()</constant> system
call.
</para>

4
Documentation/DocBook/media/dvb/ca.xml
View File

@@ -1,7 +1,7 @@
<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.
<constant>/dev/dvb/adapter?/ca?</constant>. Data types and and ioctl definitions can be accessed by
including <constant>linux/dvb/ca.h</constant> in your application.
</para>
<section id="ca_data_types">

61
Documentation/DocBook/media/dvb/demux.xml
View File

@@ -1,33 +1,50 @@
<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.
accessed through <constant>/dev/adapter?/demux?</constant>. Data types and and ioctl definitions can be
accessed by including <constant>linux/dvb/dmx.h</constant> 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, /&#x22C6; Streaming directly to decoder. &#x22C6;/
DMX_OUT_TAP, /&#x22C6; Output going to a memory buffer &#x22C6;/
/&#x22C6; (to be retrieved via the read command).&#x22C6;/
DMX_OUT_TS_TAP, /&#x22C6; Output multiplexed into a new TS &#x22C6;/
/&#x22C6; (to be retrieved by reading from the &#x22C6;/
/&#x22C6; logical DVR device). &#x22C6;/
DMX_OUT_TSDEMUX_TAP /&#x22C6; Like TS_TAP but retrieved from the DMX device &#x22C6;/
} 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>
<title>Output for the demux</title>
<table pgwide="1" frame="none" id="dmx-output">
<title>enum dmx_output</title>
<tgroup cols="2">
&cs-def;
<thead>
<row>
<entry>ID</entry>
<entry>Description</entry>
</row>
</thead>
<tbody valign="top">
<row>
<entry align="char" id="DMX-OUT-DECODER">DMX_OUT_DECODER</entry>
<entry>Streaming directly to decoder.</entry>
</row><row>
<entry align="char" id="DMX-OUT-TAP">DMX_OUT_TAP</entry>
<entry>Output going to a memory buffer (to be retrieved via the
read command). Delivers the stream output to the demux
device on which the ioctl is called.</entry>
</row><row>
<entry align="char" id="DMX-OUT-TS-TAP">DMX_OUT_TS_TAP</entry>
<entry>Output multiplexed into a new TS (to be retrieved by
reading from the logical DVR device). Routes output to the
logical DVR device <constant>/dev/dvb/adapter?/dvr?</constant>,
which delivers a TS multiplexed from all filters for which
<constant>DMX_OUT_TS_TAP</constant> was specified.</entry>
</row><row>
<entry align="char" id="DMX-OUT-TSDEMUX-TAP">DMX_OUT_TSDEMUX_TAP</entry>
<entry>Like &DMX-OUT-TS-TAP; but retrieved from the DMX
device.</entry>
</row>
</tbody>
</tgroup>
</table>
</section>
<section id="dmx-input-t">

34
Documentation/DocBook/media/dvb/dvbapi.xml
View File

@@ -28,12 +28,22 @@
<holder>Convergence GmbH</holder>
</copyright>
<copyright>
<year>2009-2014</year>
<year>2009-2015</year>
<holder>Mauro Carvalho Chehab</holder>
</copyright>
<revhistory>
<!-- Put document revisions here, newest first. -->
<revision>
<revnumber>2.1.0</revnumber>
<date>2015-05-29</date>
<authorinitials>mcc</authorinitials>
<revremark>
DocBook improvements and cleanups, in order to document the
system calls on a more standard way and provide more description
about the current DVB API.
</revremark>
</revision>
<revision>
<revnumber>2.0.4</revnumber>
<date>2011-05-06</date>
@@ -95,18 +105,26 @@ Added ISDB-T test originally written by Patrick Boettcher
<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">
<chapter id="net">
&sub-net;
</chapter>
<chapter id="legacy_dvb_apis">
<title>DVB Deprecated APIs</title>
<para>The APIs described here are kept only for historical reasons. There's
just one driver for a very legacy hardware that uses this API. No
modern drivers should use it. Instead, audio and video should be using
the V4L2 and ALSA APIs, and the pipelines should be set using the
Media Controller API</para>
<section id="dvb_video">
&sub-video;
</section>
<section id="dvb_audio">
&sub-audio;
</section>
</chapter>
<chapter id="dvb_kdapi">
&sub-kdapi;
</chapter>

1117
Documentation/DocBook/media/dvb/dvbproperty.xml
View File

File diff suppressed because it is too large Load Diff

6
Documentation/DocBook/media/dvb/examples.xml
View File

@@ -1,8 +1,10 @@
<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>NOTE: This section is out of date, and the code below won't even
compile. Please refer to the
<ulink url="http://linuxtv.org/docs/libdvbv5/index.html">libdvbv5</ulink>
for updated/recommended examples.
</para>
<section id="tuning">

78
Documentation/DocBook/media/dvb/fe-diseqc-recv-slave-reply.xml Normal file
View File

@@ -0,0 +1,78 @@
<refentry id="FE_DISEQC_RECV_SLAVE_REPLY">
<refmeta>
<refentrytitle>ioctl FE_DISEQC_RECV_SLAVE_REPLY</refentrytitle>
&manvol;
</refmeta>
<refnamediv>
<refname>FE_DISEQC_RECV_SLAVE_REPLY</refname>
<refpurpose>Receives reply from a DiSEqC 2.0 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 dvb_diseqc_slave_reply *<parameter>argp</parameter></paramdef>
</funcprototype>
</funcsynopsis>
</refsynopsisdiv>
<refsect1>
<title>Arguments</title>
<variablelist>
<varlistentry>
<term><parameter>fd</parameter></term>
<listitem>
<para>&fe_fd;</para>
</listitem>
</varlistentry>
<varlistentry>
<term><parameter>request</parameter></term>
<listitem>
<para>FE_DISEQC_RECV_SLAVE_REPLY</para>
</listitem>
</varlistentry>
<varlistentry>
<term><parameter>argp</parameter></term>
<listitem>
<para>pointer to &dvb-diseqc-slave-reply;</para>
</listitem>
</varlistentry>
</variablelist>
</refsect1>
<refsect1>
<title>Description</title>
<para>Receives reply from a DiSEqC 2.0 command.</para>
&return-value-dvb;
<table pgwide="1" frame="none" id="dvb-diseqc-slave-reply">
<title>struct <structname>dvb_diseqc_slave_reply</structname></title>
<tgroup cols="3">
&cs-str;
<tbody valign="top">
<row>
<entry>uint8_t</entry>
<entry>msg[4]</entry>
<entry>DiSEqC message (framing, data[3])</entry>
</row><row>
<entry>uint8_t</entry>
<entry>msg_len</entry>
<entry>Length of the DiSEqC message. Valid values are 0 to 4,
where 0 means no msg</entry>
</row><row>
<entry>int</entry>
<entry>timeout</entry>
<entry>Return from ioctl after timeout ms with errorcode when no
message was received</entry>
</row>
</tbody>
</tgroup>
</table>
</refsect1>
</refentry>

51
Documentation/DocBook/media/dvb/fe-diseqc-reset-overload.xml Normal file
View File

@@ -0,0 +1,51 @@
<refentry id="FE_DISEQC_RESET_OVERLOAD">
<refmeta>
<refentrytitle>ioctl FE_DISEQC_RESET_OVERLOAD</refentrytitle>
&manvol;
</refmeta>
<refnamediv>
<refname>FE_DISEQC_RESET_OVERLOAD</refname>
<refpurpose>Restores the power to the antenna subsystem, if it was powered
off due to power overload.</refpurpose>
</refnamediv>
<refsynopsisdiv>
<funcsynopsis>
<funcprototype>
<funcdef>int <function>ioctl</function></funcdef>
<paramdef>int <parameter>fd</parameter></paramdef>
<paramdef>int <parameter>request</parameter></paramdef>
<paramdef>NULL</paramdef>
</funcprototype>
</funcsynopsis>
</refsynopsisdiv>
<refsect1>
<title>Arguments</title>
<variablelist>
<varlistentry>
<term><parameter>fd</parameter></term>
<listitem>
<para>&fe_fd;</para>
</listitem>
</varlistentry>
<varlistentry>
<term><parameter>request</parameter></term>
<listitem>
<para>FE_DISEQC_RESET_OVERLOAD</para>
</listitem>
</varlistentry>
</variablelist>
</refsect1>
<refsect1>
<title>Description</title>
<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>
&return-value-dvb;
</refsect1>
</refentry>

89
Documentation/DocBook/media/dvb/fe-diseqc-send-burst.xml Normal file
View File

@@ -0,0 +1,89 @@
<refentry id="FE_DISEQC_SEND_BURST">
<refmeta>
<refentrytitle>ioctl FE_DISEQC_SEND_BURST</refentrytitle>
&manvol;
</refmeta>
<refnamediv>
<refname>FE_DISEQC_SEND_BURST</refname>
<refpurpose>Sends a 22KHz tone burst for 2x1 mini DiSEqC satellite selection.</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 fe_sec_mini_cmd *<parameter>tone</parameter></paramdef>
</funcprototype>
</funcsynopsis>
</refsynopsisdiv>
<refsect1>
<title>Arguments</title>
<variablelist>
<varlistentry>
<term><parameter>fd</parameter></term>
<listitem>
<para>&fe_fd;</para>
</listitem>
</varlistentry>
<varlistentry>
<term><parameter>request</parameter></term>
<listitem>
<para>FE_DISEQC_SEND_BURST</para>
</listitem>
</varlistentry>
<varlistentry>
<term><parameter>tone</parameter></term>
<listitem>
<para>pointer to &fe-sec-mini-cmd;</para>
</listitem>
</varlistentry>
</variablelist>
</refsect1>
<refsect1>
<title>Description</title>
<para>This ioctl is used to set the generation of a 22kHz tone burst for mini
DiSEqC satellite
selection for 2x1 switches.
This call requires read/write permissions.</para>
<para>It provides support for what's specified at
<ulink url="http://www.eutelsat.com/files/contributed/satellites/pdf/Diseqc/associated%20docs/simple_tone_burst_detec.pdf">Digital Satellite Equipment Control
(DiSEqC) - Simple "ToneBurst" Detection Circuit specification.</ulink>
</para>
&return-value-dvb;
</refsect1>
<refsect1 id="fe-sec-mini-cmd-t">
<title>enum fe_sec_mini_cmd</title>
<table pgwide="1" frame="none" id="fe-sec-mini-cmd">
<title>enum fe_sec_mini_cmd</title>
<tgroup cols="2">
&cs-def;
<thead>
<row>
<entry>ID</entry>
<entry>Description</entry>
</row>
</thead>
<tbody valign="top">
<row>
<entry align="char" id="SEC-MINI-A"><constant>SEC_MINI_A</constant></entry>
<entry align="char">Sends a mini-DiSEqC 22kHz '0' Tone Burst to
select satellite-A</entry>
</row><row>
<entry align="char" id="SEC-MINI-B"><constant>SEC_MINI_B</constant></entry>
<entry align="char">Sends a mini-DiSEqC 22kHz '1' Data Burst to
select satellite-B</entry>
</row>
</tbody>
</tgroup>
</table>
</refsect1>
</refentry>

72
Documentation/DocBook/media/dvb/fe-diseqc-send-master-cmd.xml Normal file
View File

@@ -0,0 +1,72 @@
<refentry id="FE_DISEQC_SEND_MASTER_CMD">
<refmeta>
<refentrytitle>ioctl FE_DISEQC_SEND_MASTER_CMD</refentrytitle>
&manvol;
</refmeta>
<refnamediv>
<refname>FE_DISEQC_SEND_MASTER_CMD</refname>
<refpurpose>Sends a DiSEqC 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 dvb_diseqc_master_cmd *<parameter>argp</parameter></paramdef>
</funcprototype>
</funcsynopsis>
</refsynopsisdiv>
<refsect1>
<title>Arguments</title>
<variablelist>
<varlistentry>
<term><parameter>fd</parameter></term>
<listitem>
<para>&fe_fd;</para>
</listitem>
</varlistentry>
<varlistentry>
<term><parameter>request</parameter></term>
<listitem>
<para>FE_DISEQC_SEND_MASTER_CMD</para>
</listitem>
</varlistentry>
<varlistentry>
<term><parameter>argp</parameter></term>
<listitem>
<para>pointer to &dvb-diseqc-master-cmd;</para>
</listitem>
</varlistentry>
</variablelist>
</refsect1>
<refsect1>
<title>Description</title>
<para>Sends a DiSEqC command to the antenna subsystem.</para>
&return-value-dvb;
<table pgwide="1" frame="none" id="dvb-diseqc-master-cmd">
<title>struct <structname>dvb_diseqc_master_cmd</structname></title>
<tgroup cols="3">
&cs-str;
<tbody valign="top">
<row>
<entry>uint8_t</entry>
<entry>msg[6]</entry>
<entry>DiSEqC message (framing, address, command, data[3])</entry>
</row><row>
<entry>uint8_t</entry>
<entry>msg_len</entry>
<entry>Length of the DiSEqC message. Valid values are 3 to 6</entry>
</row>
</tbody>
</tgroup>
</table>
</refsect1>
</refentry>

61
Documentation/DocBook/media/dvb/fe-enable-high-lnb-voltage.xml Normal file
View File

@@ -0,0 +1,61 @@
<refentry id="FE_ENABLE_HIGH_LNB_VOLTAGE">
<refmeta>
<refentrytitle>ioctl FE_ENABLE_HIGH_LNB_VOLTAGE</refentrytitle>
&manvol;
</refmeta>
<refnamediv>
<refname>FE_ENABLE_HIGH_LNB_VOLTAGE</refname>
<refpurpose>Select output DC level between normal LNBf voltages or higher
LNBf voltages.</refpurpose>
</refnamediv>
<refsynopsisdiv>
<funcsynopsis>
<funcprototype>
<funcdef>int <function>ioctl</function></funcdef>
<paramdef>int <parameter>fd</parameter></paramdef>
<paramdef>int <parameter>request</parameter></paramdef>
<paramdef>unsigned int <parameter>high</parameter></paramdef>
</funcprototype>
</funcsynopsis>
</refsynopsisdiv>
<refsect1>
<title>Arguments</title>
<variablelist>
<varlistentry>
<term><parameter>fd</parameter></term>
<listitem>
<para>&fe_fd;</para>
</listitem>
</varlistentry>
<varlistentry>
<term><parameter>request</parameter></term>
<listitem>
<para>FE_ENABLE_HIGH_LNB_VOLTAGE</para>
</listitem>
</varlistentry>
<varlistentry>
<term><parameter>high</parameter></term>
<listitem>
<para>Valid flags:</para>
<itemizedlist>
<listitem><para>0 - normal 13V and 18V.</para></listitem>
<listitem><para>&gt;0 - enables slightly higher voltages instead of
13/18V, in order to compensate for long antenna cables.</para></listitem>
</itemizedlist>
</listitem>
</varlistentry>
</variablelist>
</refsect1>
<refsect1>
<title>Description</title>
<para>Select output DC level between normal LNBf voltages or higher
LNBf voltages between 0 (normal) or a value grater than 0 for higher
voltages.</para>
&return-value-dvb;
</refsect1>
</refentry>

266
Documentation/DocBook/media/dvb/fe-get-info.xml Normal file
View File

@@ -0,0 +1,266 @@
<refentry id="FE_GET_INFO">
<refmeta>
<refentrytitle>ioctl FE_GET_INFO</refentrytitle>
&manvol;
</refmeta>
<refnamediv>
<refname>FE_GET_INFO</refname>
<refpurpose>Query DVB frontend capabilities and returns information about
the front-end. This call only requires read-only access to the device</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 dvb_frontend_info *<parameter>argp</parameter></paramdef>
</funcprototype>
</funcsynopsis>
</refsynopsisdiv>
<refsect1>
<title>Arguments</title>
<variablelist>
<varlistentry>
<term><parameter>fd</parameter></term>
<listitem>
<para>&fe_fd;</para>
</listitem>
</varlistentry>
<varlistentry>
<term><parameter>request</parameter></term>
<listitem>
<para>FE_GET_INFO</para>
</listitem>
</varlistentry>
<varlistentry>
<term><parameter>argp</parameter></term>
<listitem>
<para>pointer to struct &dvb-frontend-info;</para>
</listitem>
</varlistentry>
</variablelist>
</refsect1>
<refsect1>
<title>Description</title>
<para>All DVB frontend devices support the
<constant>FE_GET_INFO</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 dvb_frontend_info which is filled by the driver. When the
driver is not compatible with this specification the ioctl returns an error.
</para>
&return-value-dvb;
<table pgwide="1" frame="none" id="dvb-frontend-info">
<title>struct <structname>dvb_frontend_info</structname></title>
<tgroup cols="3">
&cs-str;
<tbody valign="top">
<row>
<entry>char</entry>
<entry>name[128]</entry>
<entry>Name of the frontend</entry>
</row><row>
<entry>fe_type_t</entry>
<entry>type</entry>
<entry><emphasis role="bold">DEPRECATED</emphasis>. DVBv3 type. Should not be used on modern programs, as a
frontend may have more than one type. So, the DVBv5 API should
be used instead to enumerate and select the frontend type.</entry>
</row><row>
<entry>uint32_t</entry>
<entry>frequency_min</entry>
<entry>Minimal frequency supported by the frontend</entry>
</row><row>
<entry>uint32_t</entry>
<entry>frequency_max</entry>
<entry>Maximal frequency supported by the frontend</entry>
</row><row>
<entry>uint32_t</entry>
<entry>frequency_stepsize</entry>
<entry>Frequency step - all frequencies are multiple of this value</entry>
</row><row>
<entry>uint32_t</entry>
<entry>frequency_tolerance</entry>
<entry>Tolerance of the frequency</entry>
</row><row>
<entry>uint32_t</entry>
<entry>symbol_rate_min</entry>
<entry>Minimal symbol rate (for Cable/Satellite systems), in bauds</entry>
</row><row>
<entry>uint32_t</entry>
<entry>symbol_rate_max</entry>
<entry>Maximal symbol rate (for Cable/Satellite systems), in bauds</entry>
</row><row>
<entry>uint32_t</entry>
<entry>symbol_rate_tolerance</entry>
<entry>Maximal symbol rate tolerance, in ppm</entry>
</row><row>
<entry>uint32_t</entry>
<entry>notifier_delay</entry>
<entry><emphasis role="bold">DEPRECATED</emphasis>. Not used by any driver.</entry>
</row><row>
<entry>&fe-caps;</entry>
<entry>caps</entry>
<entry>Capabilities supported by the frontend</entry>
</row>
</tbody>
</tgroup>
</table>
<para>NOTE: The frequencies are specified in Hz for Terrestrial and Cable
systems. They're specified in kHz for Satellite systems</para>
</refsect1>
<refsect1 id="fe-caps-t">
<title>frontend capabilities</title>
<para>Capabilities describe what a frontend can do. Some capabilities are
supported only on some specific frontend types.</para>
<table pgwide="1" frame="none" id="fe-caps">
<title>enum fe_caps</title>
<tgroup cols="2">
&cs-def;
<thead>
<row>
<entry>ID</entry>
<entry>Description</entry>
</row>
</thead>
<tbody valign="top">
<row>
<entry id="FE-IS-STUPID"><constant>FE_IS_STUPID</constant></entry>
<entry>There's something wrong at the frontend, and it can't
report its capabilities</entry>
</row>
<row>
<entry id="FE-CAN-INVERSION-AUTO"><constant>FE_CAN_INVERSION_AUTO</constant></entry>
<entry>The frontend is capable of auto-detecting inversion</entry>
</row>
<row>
<entry id="FE-CAN-FEC-1-2"><constant>FE_CAN_FEC_1_2</constant></entry>
<entry>The frontend supports FEC 1/2</entry>
</row>
<row>
<entry id="FE-CAN-FEC-2-3"><constant>FE_CAN_FEC_2_3</constant></entry>
<entry>The frontend supports FEC 2/3</entry>
</row>
<row>
<entry id="FE-CAN-FEC-3-4"><constant>FE_CAN_FEC_3_4</constant></entry>
<entry>The frontend supports FEC 3/4</entry>
</row>
<row>
<entry id="FE-CAN-FEC-4-5"><constant>FE_CAN_FEC_4_5</constant></entry>
<entry>The frontend supports FEC 4/5</entry>
</row>
<row>
<entry id="FE-CAN-FEC-5-6"><constant>FE_CAN_FEC_5_6</constant></entry>
<entry>The frontend supports FEC 5/6</entry>
</row>
<row>
<entry id="FE-CAN-FEC-6-7"><constant>FE_CAN_FEC_6_7</constant></entry>
<entry>The frontend supports FEC 6/7</entry>
</row>
<row>
<entry id="FE-CAN-FEC-7-8"><constant>FE_CAN_FEC_7_8</constant></entry>
<entry>The frontend supports FEC 7/8</entry>
</row>
<row>
<entry id="FE-CAN-FEC-8-9"><constant>FE_CAN_FEC_8_9</constant></entry>
<entry>The frontend supports FEC 8/9</entry>
</row>
<row>
<entry id="FE-CAN-FEC-AUTO"><constant>FE_CAN_FEC_AUTO</constant></entry>
<entry>The frontend can autodetect FEC.</entry>
</row>
<row>
<entry id="FE-CAN-QPSK"><constant>FE_CAN_QPSK</constant></entry>
<entry>The frontend supports QPSK modulation</entry>
</row>
<row>
<entry id="FE-CAN-QAM-16"><constant>FE_CAN_QAM_16</constant></entry>
<entry>The frontend supports 16-QAM modulation</entry>
</row>
<row>
<entry id="FE-CAN-QAM-32"><constant>FE_CAN_QAM_32</constant></entry>
<entry>The frontend supports 32-QAM modulation</entry>
</row>
<row>
<entry id="FE-CAN-QAM-64"><constant>FE_CAN_QAM_64</constant></entry>
<entry>The frontend supports 64-QAM modulation</entry>
</row>
<row>
<entry id="FE-CAN-QAM-128"><constant>FE_CAN_QAM_128</constant></entry>
<entry>The frontend supports 128-QAM modulation</entry>
</row>
<row>
<entry id="FE-CAN-QAM-256"><constant>FE_CAN_QAM_256</constant></entry>
<entry>The frontend supports 256-QAM modulation</entry>
</row>
<row>
<entry id="FE-CAN-QAM-AUTO"><constant>FE_CAN_QAM_AUTO</constant></entry>
<entry>The frontend can autodetect modulation</entry>
</row>
<row>
<entry id="FE-CAN-TRANSMISSION-MODE-AUTO"><constant>FE_CAN_TRANSMISSION_MODE_AUTO</constant></entry>
<entry>The frontend can autodetect the transmission mode</entry>
</row>
<row>
<entry id="FE-CAN-BANDWIDTH-AUTO"><constant>FE_CAN_BANDWIDTH_AUTO</constant></entry>
<entry>The frontend can autodetect the bandwidth</entry>
</row>
<row>
<entry id="FE-CAN-GUARD-INTERVAL-AUTO"><constant>FE_CAN_GUARD_INTERVAL_AUTO</constant></entry>
<entry>The frontend can autodetect the guard interval</entry>
</row>
<row>
<entry id="FE-CAN-HIERARCHY-AUTO"><constant>FE_CAN_HIERARCHY_AUTO</constant></entry>
<entry>The frontend can autodetect hierarch</entry>
</row>
<row>
<entry id="FE-CAN-8VSB"><constant>FE_CAN_8VSB</constant></entry>
<entry>The frontend supports 8-VSB modulation</entry>
</row>
<row>
<entry id="FE-CAN-16VSB"><constant>FE_CAN_16VSB</constant></entry>
<entry>The frontend supports 16-VSB modulation</entry>
</row>
<row>
<entry id="FE-HAS-EXTENDED-CAPS"><constant>FE_HAS_EXTENDED_CAPS</constant></entry>
<entry>Currently, unused</entry>
</row>
<row>
<entry id="FE-CAN-MULTISTREAM"><constant>FE_CAN_MULTISTREAM</constant></entry>
<entry>The frontend supports multistream filtering</entry>
</row>
<row>
<entry id="FE-CAN-TURBO-FEC"><constant>FE_CAN_TURBO_FEC</constant></entry>
<entry>The frontend supports turbo FEC modulation</entry>
</row>
<row>
<entry id="FE-CAN-2G-MODULATION"><constant>FE_CAN_2G_MODULATION</constant></entry>
<entry>The frontend supports "2nd generation modulation" (DVB-S2/T2)></entry>
</row>
<row>
<entry id="FE-NEEDS-BENDING"><constant>FE_NEEDS_BENDING</constant></entry>
<entry>Not supported anymore, don't use it</entry>
</row>
<row>
<entry id="FE-CAN-RECOVER"><constant>FE_CAN_RECOVER</constant></entry>
<entry>The frontend can recover from a cable unplug automatically</entry>
</row>
<row>
<entry id="FE-CAN-MUTE-TS"><constant>FE_CAN_MUTE_TS</constant></entry>
<entry>The frontend can stop spurious TS data output</entry>
</row>
</tbody>
</tgroup>
</table>
</refsect1>
</refentry>

81
Documentation/DocBook/media/dvb/fe-get-property.xml Normal file
View File

@@ -0,0 +1,81 @@
<refentry id="FE_GET_PROPERTY">
<refmeta>
<refentrytitle>ioctl FE_SET_PROPERTY, FE_GET_PROPERTY</refentrytitle>
&manvol;
</refmeta>
<refnamediv>
<refname>FE_SET_PROPERTY</refname>
<refname>FE_GET_PROPERTY</refname>
<refpurpose>FE_SET_PROPERTY sets one or more frontend properties.
FE_GET_PROPERTY returns one or more frontend properties.</refpurpose>
</refnamediv>
<refsynopsisdiv>
<funcsynopsis>
<funcprototype>
<funcdef>int <function>ioctl</function></funcdef>
<paramdef>int <parameter>fd</parameter></paramdef>
<paramdef>int <parameter>request</parameter></paramdef>
<paramdef>struct dtv_properties *<parameter>argp</parameter></paramdef>
</funcprototype>
</funcsynopsis>
</refsynopsisdiv>
<refsect1>
<title>Arguments</title>
<variablelist>
<varlistentry>
<term><parameter>fd</parameter></term>
<listitem>
<para>&fe_fd;</para>
</listitem>
</varlistentry>
<varlistentry>
<term><parameter>request</parameter></term>
<listitem>
<para>FE_SET_PROPERTY, FE_GET_PROPERTY</para>
</listitem>
</varlistentry>
<varlistentry>
<term><parameter>argp</parameter></term>
<listitem>
<para>pointer to &dtv-properties;</para>
</listitem>
</varlistentry>
</variablelist>
</refsect1>
<refsect1>
<title>Description</title>
<para>All DVB frontend devices support the
<constant>FE_SET_PROPERTY</constant> and <constant>FE_GET_PROPERTY</constant>
ioctls. The supported properties and statistics depends on the delivery system
and on the device:</para>
<itemizedlist>
<listitem>
<para><constant>FE_SET_PROPERTY:</constant></para>
<itemizedlist>
<listitem><para>This ioctl is used to set one or more
frontend properties.</para></listitem>
<listitem><para>This is the basic command to request the frontend to tune into some
frequency and to start decoding the digital TV signal.</para></listitem>
<listitem><para>This call requires read/write access to the device.</para></listitem>
<listitem><para>At return, the values are updated to reflect the
actual parameters used.</para></listitem>
</itemizedlist>
</listitem>
<listitem>
<para><constant>FE_GET_PROPERTY:</constant></para>
<itemizedlist>
<listitem><para>This ioctl is used to get properties and
statistics from the frontend.</para></listitem>
<listitem><para>No properties are changed, and statistics aren't reset.</para></listitem>
<listitem><para>This call only requires read-only access to the device.</para></listitem>
</itemizedlist>
</listitem>
</itemizedlist>
&return-value-dvb;
</refsect1>
</refentry>

107
Documentation/DocBook/media/dvb/fe-read-status.xml Normal file
View File

@@ -0,0 +1,107 @@
<refentry id="FE_READ_STATUS">
<refmeta>
<refentrytitle>ioctl FE_READ_STATUS</refentrytitle>
&manvol;
</refmeta>
<refnamediv>
<refname>FE_READ_STATUS</refname>
<refpurpose>Returns status information about the front-end. This call only
requires read-only access to the device</refpurpose>
</refnamediv>
<refsynopsisdiv>
<funcsynopsis>
<funcprototype>
<funcdef>int <function>ioctl</function></funcdef>
<paramdef>int <parameter>fd</parameter></paramdef>
<paramdef>int <parameter>request</parameter></paramdef>
<paramdef>unsigned int *<parameter>status</parameter></paramdef>
</funcprototype>
</funcsynopsis>
</refsynopsisdiv>
<refsect1>
<title>Arguments</title>
<variablelist>
<varlistentry>
<term><parameter>fd</parameter></term>
<listitem>
<para>&fe_fd;</para>
</listitem>
</varlistentry>
<varlistentry>
<term><parameter>request</parameter></term>
<listitem>
<para>FE_READ_STATUS</para>
</listitem>
</varlistentry>
<varlistentry>
<term><parameter>status</parameter></term>
<listitem>
<para>pointer to a bitmask integer filled with the values defined by
&fe-status;.</para>
</listitem>
</varlistentry>
</variablelist>
</refsect1>
<refsect1>
<title>Description</title>
<para>All DVB frontend devices support the
<constant>FE_READ_STATUS</constant> ioctl. It is used to check about the
locking status of the frontend after being tuned. The ioctl takes a
pointer to an integer where the status will be written.
</para>
<para>NOTE: the size of status is actually sizeof(enum fe_status), with varies
according with the architecture. This needs to be fixed in the future.</para>
&return-value-dvb;
</refsect1>
<refsect1 id="fe-status-t">
<title>int fe_status</title>
<para>The fe_status parameter is used to indicate the current state
and/or state changes of the frontend hardware. It is produced using
the &fe-status; values on a bitmask</para>
<table pgwide="1" frame="none" id="fe-status">
<title>enum fe_status</title>
<tgroup cols="2">
&cs-def;
<thead>
<row>
<entry>ID</entry>
<entry>Description</entry>
</row>
</thead>
<tbody valign="top">
<row>
<entry align="char" id="FE-HAS-SIGNAL"><constant>FE_HAS_SIGNAL</constant></entry>
<entry align="char">The frontend has found something above the noise level</entry>
</row><row>
<entry align="char" id="FE-HAS-CARRIER"><constant>FE_HAS_CARRIER</constant></entry>
<entry align="char">The frontend has found a DVB signal</entry>
</row><row>
<entry align="char" id="FE-HAS-VITERBI"><constant>FE_HAS_VITERBI</constant></entry>
<entry align="char">The frontend FEC inner coding (Viterbi, LDPC or other inner code) is stable</entry>
</row><row>
<entry align="char" id="FE-HAS-SYNC"><constant>FE_HAS_SYNC</constant></entry>
<entry align="char">Synchronization bytes was found</entry>
</row><row>
<entry align="char" id="FE-HAS-LOCK"><constant>FE_HAS_LOCK</constant></entry>
<entry align="char">The DVB were locked and everything is working</entry>
</row><row>
<entry align="char" id="FE-TIMEDOUT"><constant>FE_TIMEDOUT</constant></entry>
<entry align="char">no lock within the last about 2 seconds</entry>
</row><row>
<entry align="char" id="FE-REINIT"><constant>FE_REINIT</constant></entry>
<entry align="char">The frontend was reinitialized, application is
recommended to reset DiSEqC, tone and parameters</entry>
</row>
</tbody>
</tgroup>
</table>
</refsect1>
</refentry>

64
Documentation/DocBook/media/dvb/fe-set-frontend-tune-mode.xml Normal file
View File

@@ -0,0 +1,64 @@
<refentry id="FE_SET_FRONTEND_TUNE_MODE">
<refmeta>
<refentrytitle>ioctl FE_SET_FRONTEND_TUNE_MODE</refentrytitle>
&manvol;
</refmeta>
<refnamediv>
<refname>FE_SET_FRONTEND_TUNE_MODE</refname>
<refpurpose>Allow setting tuner mode flags to the frontend.</refpurpose>
</refnamediv>
<refsynopsisdiv>
<funcsynopsis>
<funcprototype>
<funcdef>int <function>ioctl</function></funcdef>
<paramdef>int <parameter>fd</parameter></paramdef>
<paramdef>int <parameter>request</parameter></paramdef>
<paramdef>unsigned int <parameter>flags</parameter></paramdef>
</funcprototype>
</funcsynopsis>
</refsynopsisdiv>
<refsect1>
<title>Arguments</title>
<variablelist>
<varlistentry>
<term><parameter>fd</parameter></term>
<listitem>
<para>&fe_fd;</para>
</listitem>
</varlistentry>
<varlistentry>
<term><parameter>request</parameter></term>
<listitem>
<para>FE_SET_FRONTEND_TUNE_MODE</para>
</listitem>
</varlistentry>
<varlistentry>
<term><parameter>flags</parameter></term>
<listitem>
<para>Valid flags:</para>
<itemizedlist>
<listitem><para>0 - normal tune mode</para></listitem>
<listitem><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></listitem>
</itemizedlist>
</listitem>
</varlistentry>
</variablelist>
</refsect1>
<refsect1>
<title>Description</title>
<para>Allow setting tuner mode flags to the frontend, between 0 (normal)
or FE_TUNE_MODE_ONESHOT mode</para>
&return-value-dvb;
</refsect1>
</refentry>

91
Documentation/DocBook/media/dvb/fe-set-tone.xml Normal file
View File

@@ -0,0 +1,91 @@
<refentry id="FE_SET_TONE">
<refmeta>
<refentrytitle>ioctl FE_SET_TONE</refentrytitle>
&manvol;
</refmeta>
<refnamediv>
<refname>FE_SET_TONE</refname>
<refpurpose>Sets/resets the generation of the continuous 22kHz tone.</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 fe_sec_tone_mode *<parameter>tone</parameter></paramdef>
</funcprototype>
</funcsynopsis>
</refsynopsisdiv>
<refsect1>
<title>Arguments</title>
<variablelist>
<varlistentry>
<term><parameter>fd</parameter></term>
<listitem>
<para>&fe_fd;</para>
</listitem>
</varlistentry>
<varlistentry>
<term><parameter>request</parameter></term>
<listitem>
<para>FE_SET_TONE</para>
</listitem>
</varlistentry>
<varlistentry>
<term><parameter>tone</parameter></term>
<listitem>
<para>pointer to &fe-sec-tone-mode;</para>
</listitem>
</varlistentry>
</variablelist>
</refsect1>
<refsect1>
<title>Description</title>
<para>This ioctl is used to set the generation of the continuous 22kHz tone.
This call requires read/write permissions.</para>
<para>Usually, satellite antenna subsystems require that the digital TV
device to send a 22kHz tone in order to select between high/low band on
some dual-band LNBf. It is also used to send signals to DiSEqC equipment,
but this is done using the DiSEqC ioctls.</para>
<para>NOTE: if more than one device is connected to the same antenna,
setting a tone may interfere on other devices, as they may lose
the capability of selecting the band. So, it is recommended that
applications would change to SEC_TONE_OFF when the device is not used.</para>
&return-value-dvb;
</refsect1>
<refsect1 id="fe-sec-tone-mode-t">
<title>enum fe_sec_tone_mode</title>
<table pgwide="1" frame="none" id="fe-sec-tone-mode">
<title>enum fe_sec_tone_mode</title>
<tgroup cols="2">
&cs-def;
<thead>
<row>
<entry>ID</entry>
<entry>Description</entry>
</row>
</thead>
<tbody valign="top">
<row>
<entry align="char" id="SEC-TONE-ON"><constant>SEC_TONE_ON</constant></entry>
<entry align="char">Sends a 22kHz tone burst to the antenna</entry>
</row><row>
<entry align="char" id="SEC-TONE-OFF"><constant>SEC_TONE_OFF</constant></entry>
<entry align="char">Don't send a 22kHz tone to the antenna
(except if the FE_DISEQC_* ioctls are called)</entry>
</row>
</tbody>
</tgroup>
</table>
</refsect1>
</refentry>

69
Documentation/DocBook/media/dvb/fe-set-voltage.xml Normal file
View File

@@ -0,0 +1,69 @@
<refentry id="FE_SET_VOLTAGE">
<refmeta>
<refentrytitle>ioctl FE_SET_VOLTAGE</refentrytitle>
&manvol;
</refmeta>
<refnamediv>
<refname>FE_SET_VOLTAGE</refname>
<refpurpose>Allow setting the DC level sent to the antenna subsystem.</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 fe_sec_voltage *<parameter>voltage</parameter></paramdef>
</funcprototype>
</funcsynopsis>
</refsynopsisdiv>
<refsect1>
<title>Arguments</title>
<variablelist>
<varlistentry>
<term><parameter>fd</parameter></term>
<listitem>
<para>&fe_fd;</para>
</listitem>
</varlistentry>
<varlistentry>
<term><parameter>request</parameter></term>
<listitem>
<para>FE_SET_VOLTAGE</para>
</listitem>
</varlistentry>
<varlistentry>
<term><parameter>voltage</parameter></term>
<listitem>
<para>pointer to &fe-sec-voltage;</para>
<para>Valid values are described at &fe-sec-voltage;.</para>
</listitem>
</varlistentry>
</variablelist>
</refsect1>
<refsect1>
<title>Description</title>
<para>This ioctl allows to set the DC voltage level sent through the antenna
cable to 13V, 18V or off.</para>
<para>Usually, a satellite antenna subsystems require that the digital TV
device to send a DC voltage to feed power to the LNBf. Depending on the
LNBf type, the polarization or the intermediate frequency (IF) of the LNBf
can controlled by the voltage level. Other devices (for example, the ones
that implement DISEqC and multipoint LNBf's don't need to control the
voltage level, provided that either 13V or 18V is sent to power up the
LNBf.</para>
<para>NOTE: if more than one device is connected to the same antenna,
setting a voltage level may interfere on other devices, as they may lose
the capability of setting polarization or IF. So, on those
cases, setting the voltage to SEC_VOLTAGE_OFF while the device is not is
used is recommended.</para>
&return-value-dvb;
</refsect1>
</refentry>

1727
Documentation/DocBook/media/dvb/frontend.xml
View File

File diff suppressed because it is too large Load Diff

654
Documentation/DocBook/media/dvb/frontend_legacy_api.xml Normal file
View File

@@ -0,0 +1,654 @@
<section id="frontend_legacy_types">
<title>Frontend Legacy Data Types</title>
<section id="fe-type-t">
<title>Frontend type</title>
<para>For historical reasons, frontend types are named by the type of modulation
used in transmission. The fontend types are given by fe_type_t type, defined as:</para>
<table pgwide="1" frame="none" id="fe-type">
<title>Frontend types</title>
<tgroup cols="3">
&cs-def;
<thead>
<row>
<entry>fe_type</entry>
<entry>Description</entry>
<entry><link linkend="DTV-DELIVERY-SYSTEM">DTV_DELIVERY_SYSTEM</link> equivalent type</entry>
</row>
</thead>
<tbody valign="top">
<row>
<entry id="FE-QPSK"><constant>FE_QPSK</constant></entry>
<entry>For DVB-S standard</entry>
<entry><constant>SYS_DVBS</constant></entry>
</row>
<row>
<entry id="FE-QAM"><constant>FE_QAM</constant></entry>
<entry>For DVB-C annex A standard</entry>
<entry><constant>SYS_DVBC_ANNEX_A</constant></entry>
</row>
<row>
<entry id="FE-OFDM"><constant>FE_OFDM</constant></entry>
<entry>For DVB-T standard</entry>
<entry><constant>SYS_DVBT</constant></entry>
</row>
<row>
<entry id="FE-ATSC"><constant>FE_ATSC</constant></entry>
<entry>For ATSC standard (terrestrial) or for DVB-C Annex B (cable) used in US.</entry>
<entry><constant>SYS_ATSC</constant> (terrestrial) or <constant>SYS_DVBC_ANNEX_B</constant> (cable)</entry>
</row>
</tbody></tgroup></table>
<para>Newer formats like DVB-S2, ISDB-T, ISDB-S and DVB-T2 are not described at the above, as they're
supported via the new <link linkend="FE_GET_PROPERTY">FE_GET_PROPERTY/FE_GET_SET_PROPERTY</link> ioctl's, using the <link linkend="DTV-DELIVERY-SYSTEM">DTV_DELIVERY_SYSTEM</link> parameter.
</para>
<para>In the old days, &dvb-frontend-info; used to contain
<constant>fe_type_t</constant> field to indicate the delivery systems,
filled with either FE_QPSK, FE_QAM, FE_OFDM or FE_ATSC. While this is
still filled to keep backward compatibility, the usage of this
field is deprecated, as it can report just one delivery system, but some
devices support multiple delivery systems. Please use
<link linkend="DTV-ENUM-DELSYS">DTV_ENUM_DELSYS</link> instead.
</para>
<para>On devices that support multiple delivery systems,
&dvb-frontend-info;::<constant>fe_type_t</constant> is filled with the
currently standard, as selected by the last call to
<link linkend="FE_GET_PROPERTY">FE_SET_PROPERTY</link>
using the &DTV-DELIVERY-SYSTEM; property.</para>
</section>
<section id="fe-bandwidth-t">
<title>Frontend bandwidth</title>
<table pgwide="1" frame="none" id="fe-bandwidth">
<title>enum fe_bandwidth</title>
<tgroup cols="2">
&cs-def;
<thead>
<row>
<entry>ID</entry>
<entry>Description</entry>
</row>
</thead>
<tbody valign="top">
<row>
<entry id="BANDWIDTH-AUTO"><constant>BANDWIDTH_AUTO</constant></entry>
<entry>Autodetect bandwidth (if supported)</entry>
</row><row>
<entry id="BANDWIDTH-1-712-MHZ"><constant>BANDWIDTH_1_712_MHZ</constant></entry>
<entry>1.712 MHz</entry>
</row><row>
<entry id="BANDWIDTH-5-MHZ"><constant>BANDWIDTH_5_MHZ</constant></entry>
<entry>5 MHz</entry>
</row><row>
<entry id="BANDWIDTH-6-MHZ"><constant>BANDWIDTH_6_MHZ</constant></entry>
<entry>6 MHz</entry>
</row><row>
<entry id="BANDWIDTH-7-MHZ"><constant>BANDWIDTH_7_MHZ</constant></entry>
<entry>7 MHz</entry>
</row><row>
<entry id="BANDWIDTH-8-MHZ"><constant>BANDWIDTH_8_MHZ</constant></entry>
<entry>8 MHz</entry>
</row><row>
<entry id="BANDWIDTH-10-MHZ"><constant>BANDWIDTH_10_MHZ</constant></entry>
<entry>10 MHz</entry>
</row>
</tbody>
</tgroup>
</table>
</section>
<section id="dvb-frontend-parameters">
<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.</para>
<para>The struct <constant>dvb_frontend_parameters</constant> uses an
union with specific per-system parameters. However, as newer delivery systems
required more data, the structure size weren't enough to fit, and just
extending its size would break the existing applications. So, those parameters
were replaced by the usage of <link linkend="FE_GET_PROPERTY">
<constant>FE_GET_PROPERTY/FE_SET_PROPERTY</constant></link> ioctl's. The
new API is flexible enough to add new parameters to existing delivery systems,
and to add newer delivery systems.</para>
<para>So, newer applications should use <link linkend="FE_GET_PROPERTY">
<constant>FE_GET_PROPERTY/FE_SET_PROPERTY</constant></link> instead, in
order to be able to support the newer System Delivery like DVB-S2, DVB-T2,
DVB-C2, ISDB, etc.</para>
<para>All kinds of parameters are combined as an union in the FrontendParameters structure:
<programlisting>
struct dvb_frontend_parameters {
uint32_t frequency; /&#x22C6; (absolute) frequency in Hz for QAM/OFDM &#x22C6;/
/&#x22C6; intermediate frequency in kHz for QPSK &#x22C6;/
&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;
};
</programlisting></para>
<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 <constant>frequency</constant> specifies the absolute frequency and is given in Hz.
</para>
<section id="dvb-qpsk-parameters">
<title>QPSK parameters</title>
<para>For satellite QPSK frontends you have to use the <constant>dvb_qpsk_parameters</constant> structure:</para>
<programlisting>
struct dvb_qpsk_parameters {
uint32_t symbol_rate; /&#x22C6; symbol rate in Symbols per second &#x22C6;/
&fe-code-rate-t; fec_inner; /&#x22C6; forward error correction (see above) &#x22C6;/
};
</programlisting>
</section>
<section id="dvb-qam-parameters">
<title>QAM parameters</title>
<para>for cable QAM frontend you use the <constant>dvb_qam_parameters</constant> structure:</para>
<programlisting>
struct dvb_qam_parameters {
uint32_t symbol_rate; /&#x22C6; symbol rate in Symbols per second &#x22C6;/
&fe-code-rate-t; fec_inner; /&#x22C6; forward error correction (see above) &#x22C6;/
&fe-modulation-t; modulation; /&#x22C6; modulation type (see above) &#x22C6;/
};
</programlisting>
</section>
<section id="dvb-vsb-parameters">
<title>VSB parameters</title>
<para>ATSC frontends are supported by the <constant>dvb_vsb_parameters</constant> structure:</para>
<programlisting>
struct dvb_vsb_parameters {
&fe-modulation-t; modulation; /&#x22C6; modulation type (see above) &#x22C6;/
};
</programlisting>
</section>
<section id="dvb-ofdm-parameters">
<title>OFDM parameters</title>
<para>DVB-T frontends are supported by the <constant>dvb_ofdm_parameters</constant> structure:</para>
<programlisting>
struct dvb_ofdm_parameters {
&fe-bandwidth-t; bandwidth;
&fe-code-rate-t; code_rate_HP; /&#x22C6; high priority stream code rate &#x22C6;/
&fe-code-rate-t; code_rate_LP; /&#x22C6; low priority stream code rate &#x22C6;/
&fe-modulation-t; constellation; /&#x22C6; modulation type (see above) &#x22C6;/
&fe-transmit-mode-t; transmission_mode;
&fe-guard-interval-t; guard_interval;
&fe-hierarchy-t; hierarchy_information;
};
</programlisting>
</section>
</section>
<section id="dvb-frontend-event">
<title>frontend events</title>
<programlisting>
struct dvb_frontend_event {
fe_status_t status;
struct dvb_frontend_parameters parameters;
};
</programlisting>
</section>
</section>
<section id="frontend_legacy_fcalls">
<title>Frontend Legacy Function Calls</title>
<para>Those functions are defined at DVB version 3. The support is kept in
the kernel due to compatibility issues only. Their usage is strongly
not recommended</para>
<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 &#x22C6;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>
&return-value-dvb;
</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>, uint16_t
&#x22C6;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>uint16_t *snr</para>
</entry><entry
align="char">
<para>The signal-to-noise ratio is stored into *snr.</para>
</entry>
</row></tbody></tgroup></informaltable>
&return-value-dvb;
</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>, uint16_t &#x22C6;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>uint16_t *strength</para>
</entry><entry
align="char">
<para>The signal strength value is stored into *strength.</para>
</entry>
</row></tbody></tgroup></informaltable>
&return-value-dvb;
</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 &#x22C6;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>
&return-value-dvb;
</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 &#x22C6;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>
&return-value-dvb;
<informaltable><tgroup cols="2"><tbody><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 &#x22C6;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>
&return-value-dvb;
<informaltable><tgroup cols="2"><tbody><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 &#x22C6;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>
&return-value-dvb;
<informaltable><tgroup cols="2"><tbody><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">
<para>Overflow in event queue - one or more events were lost.</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>
&return-value-dvb;
</section>
</section>

30
Documentation/DocBook/media/dvb/intro.xml
View File

@@ -129,41 +129,41 @@ 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
<para>All devices can be found in the <constant>/dev</constant>
tree under <constant>/dev/dvb</constant>. The individual devices
are called:</para>
<itemizedlist>
<listitem>
<para><emphasis role="tt">/dev/dvb/adapterN/audioM</emphasis>,</para>
<para><constant>/dev/dvb/adapterN/audioM</constant>,</para>
</listitem>
<listitem>
<para><emphasis role="tt">/dev/dvb/adapterN/videoM</emphasis>,</para>
<para><constant>/dev/dvb/adapterN/videoM</constant>,</para>
</listitem>
<listitem>
<para><emphasis role="tt">/dev/dvb/adapterN/frontendM</emphasis>,</para>
<para><constant>/dev/dvb/adapterN/frontendM</constant>,</para>
</listitem>
<listitem>
<para><emphasis role="tt">/dev/dvb/adapterN/netM</emphasis>,</para>
<para><constant>/dev/dvb/adapterN/netM</constant>,</para>
</listitem>
<listitem>
<para><emphasis role="tt">/dev/dvb/adapterN/demuxM</emphasis>,</para>
<para><constant>/dev/dvb/adapterN/demuxM</constant>,</para>
</listitem>
<listitem>
<para><emphasis role="tt">/dev/dvb/adapterN/dvrM</emphasis>,</para>
<para><constant>/dev/dvb/adapterN/dvrM</constant>,</para>
</listitem>
<listitem>
<para><emphasis role="tt">/dev/dvb/adapterN/caM</emphasis>,</para></listitem></itemizedlist>
<para><constant>/dev/dvb/adapterN/caM</constant>,</para></listitem></itemizedlist>
<para>where N enumerates the DVB PCI cards in a system starting
from&#x00A0;0, and M enumerates the devices of each type within each
adapter, starting from&#x00A0;0, too. We will omit the &#8220;<emphasis
role="tt">/dev/dvb/adapterN/</emphasis>&#8221; in the further dicussion
adapter, starting from&#x00A0;0, too. We will omit the &#8220;
<constant>/dev/dvb/adapterN/</constant>&#8221; in the further dicussion
of these devices. The naming scheme for the devices is the same wheter
devfs is used or not.</para>
@@ -202,10 +202,10 @@ a partial path like:</para>
</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 5.8</emphasis>.
additional include file
<constant>linux/dvb/version.h</constant> exists, which defines the
constant <constant>DVB_API_VERSION</constant>. This document
describes <constant>DVB_API_VERSION 5.10</constant>.
</para>
</section>

4
Documentation/DocBook/media/dvb/kdapi.xml
View File

@@ -1,8 +1,8 @@
<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-core</emphasis>.
DVB device driver writers. The header file for this API is named <constant>demux.h</constant> and located in
<constant>">drivers/media/dvb-core</constant>.
</para>
<para>Maintainer note: This section must be reviewed. It is probably out of date.
</para>

374
Documentation/DocBook/media/dvb/net.xml
View File

@@ -1,156 +1,238 @@
<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>The DVB net device controls the mapping of data packages that are
part of a transport stream to be mapped into a virtual network interface,
visible through the standard Linux network protocol stack.</para>
<para>Currently, two encapsulations are supported:</para>
<itemizedlist>
<listitem><para><ulink url="http://en.wikipedia.org/wiki/Multiprotocol_Encapsulation">
Multi Protocol Encapsulation (MPE)</ulink></para></listitem>
<listitem><para><ulink url="http://en.wikipedia.org/wiki/Unidirectional_Lightweight_Encapsulation">
Ultra Lightweight Encapsulation (ULE)</ulink></para></listitem>
</itemizedlist>
<section id="dvb-net-if">
<title>struct dvb_net_if</title>
<programlisting>
struct dvb_net_if {
__u16 pid;
__u16 if_num;
__u8 feedtype;
#define DVB_NET_FEEDTYPE_MPE 0 /&#x22C6; multi protocol encapsulation &#x22C6;/
#define DVB_NET_FEEDTYPE_ULE 1 /&#x22C6; ultra lightweight encapsulation &#x22C6;/
};
</programlisting>
</section>
<para>In order to create the Linux virtual network interfaces, an application
needs to tell to the Kernel what are the PIDs and the encapsulation types
that are present on the transport stream. This is done through
<constant>/dev/dvb/adapter?/net?</constant> device node.
The data will be available via virtual <constant>dvb?_?</constant>
network interfaces, and will be controled/routed via the standard
ip tools (like ip, route, netstat, ifconfig, etc).</para>
<para> Data types and and ioctl definitions are defined via
<constant>linux/dvb/net.h</constant> header.</para>
</section>
<section id="net_fcalls">
<title>DVB net Function Calls</title>
<para>To be written&#x2026;
</para>
<section id="NET_ADD_IF"
role="subsection"><title>NET_ADD_IF</title>
<para>DESCRIPTION
</para>
<informaltable><tgroup cols="1"><tbody><row><entry
align="char">
<para>This ioctl is undocumented. Documentation is welcome.</para>
</entry>
</row></tbody></tgroup></informaltable>
<para>SYNOPSIS
</para>
<informaltable><tgroup cols="1"><tbody><row><entry
align="char">
<para>int ioctl(fd, int request = NET_ADD_IF,
struct dvb_net_if *if);</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 NET_ADD_IF for this command.</para>
</entry>
</row><row><entry
align="char">
<para>struct dvb_net_if *if
</para>
</entry><entry
align="char">
<para>Undocumented.</para>
</entry>
</row></tbody></tgroup></informaltable>
&return-value-dvb;
</section>
<section id="NET_REMOVE_IF"
role="subsection"><title>NET_REMOVE_IF</title>
<para>DESCRIPTION
</para>
<informaltable><tgroup cols="1"><tbody><row><entry
align="char">
<para>This ioctl is undocumented. Documentation is welcome.</para>
</entry>
</row></tbody></tgroup></informaltable>
<para>SYNOPSIS
</para>
<informaltable><tgroup cols="1"><tbody><row><entry
align="char">
<para>int ioctl(fd, int request = NET_REMOVE_IF);
</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 NET_REMOVE_IF for this command.</para>
</entry>
</row></tbody></tgroup></informaltable>
&return-value-dvb;
</section>
<refentry id="NET_ADD_IF">
<refmeta>
<refentrytitle>ioctl NET_ADD_IF</refentrytitle>
&manvol;
</refmeta>
<refnamediv>
<refname>NET_ADD_IF</refname>
<refpurpose>Creates a new network interface for a given Packet ID.</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 dvb_net_if *<parameter>net_if</parameter></paramdef>
</funcprototype>
</funcsynopsis>
</refsynopsisdiv>
<refsect1>
<title>Arguments</title>
<variablelist>
<varlistentry>
<term><parameter>fd</parameter></term>
<listitem>
<para>&fe_fd;</para>
</listitem>
</varlistentry>
<varlistentry>
<term><parameter>request</parameter></term>
<listitem>
<para>FE_SET_TONE</para>
</listitem>
</varlistentry>
<varlistentry>
<term><parameter>net_if</parameter></term>
<listitem>
<para>pointer to &dvb-net-if;</para>
</listitem>
</varlistentry>
</variablelist>
</refsect1>
<refsect1>
<title>Description</title>
<para>The NET_ADD_IF ioctl system call selects the Packet ID (PID) that
contains a TCP/IP traffic, the type of encapsulation to be used (MPE or ULE)
and the interface number for the new interface to be created. When the
system call successfully returns, a new virtual network interface is created.</para>
<para>The &dvb-net-if;::ifnum field will be filled with the number of the
created interface.</para>
<section id="NET_GET_IF"
role="subsection"><title>NET_GET_IF</title>
<para>DESCRIPTION
</para>
<informaltable><tgroup cols="1"><tbody><row><entry
align="char">
<para>This ioctl is undocumented. Documentation is welcome.</para>
</entry>
</row></tbody></tgroup></informaltable>
<para>SYNOPSIS
</para>
<informaltable><tgroup cols="1"><tbody><row><entry
align="char">
<para>int ioctl(fd, int request = NET_GET_IF,
struct dvb_net_if *if);</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 NET_GET_IF for this command.</para>
</entry>
</row><row><entry
align="char">
<para>struct dvb_net_if *if
</para>
</entry><entry
align="char">
<para>Undocumented.</para>
</entry>
</row></tbody></tgroup></informaltable>
&return-value-dvb;
</section>
</refsect1>
<refsect1 id="dvb-net-if-t">
<title>struct <structname>dvb_net_if</structname> description</title>
<table pgwide="1" frame="none" id="dvb-net-if">
<title>struct <structname>dvb_net_if</structname></title>
<tgroup cols="2">
&cs-def;
<thead>
<row>
<entry>ID</entry>
<entry>Description</entry>
</row>
</thead>
<tbody valign="top">
<row>
<entry align="char">pid</entry>
<entry align="char">Packet ID (PID) of the MPEG-TS that contains
data</entry>
</row><row>
<entry align="char">ifnum</entry>
<entry align="char">number of the DVB interface.</entry>
</row><row>
<entry align="char">feedtype</entry>
<entry align="char">Encapsulation type of the feed. It can be:
<constant>DVB_NET_FEEDTYPE_MPE</constant> for MPE encoding
or
<constant>DVB_NET_FEEDTYPE_ULE</constant> for ULE encoding.
</entry>
</row>
</tbody>
</tgroup>
</table>
</refsect1>
</refentry>
<refentry id="NET_REMOVE_IF">
<refmeta>
<refentrytitle>ioctl NET_REMOVE_IF</refentrytitle>
&manvol;
</refmeta>
<refnamediv>
<refname>NET_REMOVE_IF</refname>
<refpurpose>Removes a network interface.</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>ifnum</parameter></paramdef>
</funcprototype>
</funcsynopsis>
</refsynopsisdiv>
<refsect1>
<title>Arguments</title>
<variablelist>
<varlistentry>
<term><parameter>fd</parameter></term>
<listitem>
<para>&fe_fd;</para>
</listitem>
</varlistentry>
<varlistentry>
<term><parameter>request</parameter></term>
<listitem>
<para>FE_SET_TONE</para>
</listitem>
</varlistentry>
<varlistentry>
<term><parameter>net_if</parameter></term>
<listitem>
<para>number of the interface to be removed</para>
</listitem>
</varlistentry>
</variablelist>
</refsect1>
<refsect1>
<title>Description</title>
<para>The NET_REMOVE_IF ioctl deletes an interface previously created
via &NET-ADD-IF;.</para>
&return-value-dvb;
</refsect1>
</refentry>
<refentry id="NET_GET_IF">
<refmeta>
<refentrytitle>ioctl NET_GET_IF</refentrytitle>
&manvol;
</refmeta>
<refnamediv>
<refname>NET_GET_IF</refname>
<refpurpose>Read the configuration data of an interface created via
&NET-ADD-IF;.</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 dvb_net_if *<parameter>net_if</parameter></paramdef>
</funcprototype>
</funcsynopsis>
</refsynopsisdiv>
<refsect1>
<title>Arguments</title>
<variablelist>
<varlistentry>
<term><parameter>fd</parameter></term>
<listitem>
<para>&fe_fd;</para>
</listitem>
</varlistentry>
<varlistentry>
<term><parameter>request</parameter></term>
<listitem>
<para>FE_SET_TONE</para>
</listitem>
</varlistentry>
<varlistentry>
<term><parameter>net_if</parameter></term>
<listitem>
<para>pointer to &dvb-net-if;</para>
</listitem>
</varlistentry>
</variablelist>
</refsect1>
<refsect1>
<title>Description</title>
<para>The NET_GET_IF ioctl uses the interface number given by the
&dvb-net-if;::ifnum field and fills the content of &dvb-net-if; with
the packet ID and encapsulation type used on such interface. If the
interface was not created yet with &NET-ADD-IF;, it will return -1 and
fill the <constant>errno</constant> with <constant>EINVAL</constant>
error code.</para>
&return-value-dvb;
</refsect1>
</refentry>
</section>

10
Documentation/DocBook/media/dvb/video.xml
View File

@@ -1,12 +1,12 @@
<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
can be accessed through <emphasis role="bold">/dev/dvb/adapter0/video0</emphasis>. Data types and and
ioctl definitions can be accessed by including <emphasis role="bold">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
associated video4linux device, e.g. <emphasis role="bold">/dev/video</emphasis>, which allows scaling and defining output
windows.
</para>
<para>Some DVB cards don&#8217;t have their own MPEG decoder, which results in the omission of
@@ -24,7 +24,7 @@ have been created to replace that functionality.</para>
<section id="video-format-t">
<title>video_format_t</title>
<para>The <emphasis role="tt">video_format_t</emphasis> data type defined by
<para>The <constant>video_format_t</constant> data type defined by
</para>
<programlisting>
typedef enum {
@@ -74,7 +74,7 @@ typedef enum {
</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
is selected the stream comes from the application through the <emphasis role="bold">write()</emphasis> system
call.
</para>
</section>

28
Documentation/DocBook/media/typical_media_device.svg Normal file
View File

File diff suppressed because one or more lines are too long
Side by Side

After

Width:  |  Height:  |  Size: 35 KiB

11
Documentation/DocBook/media/v4l/biblio.xml
View File

@@ -1,14 +1,13 @@
<bibliography>
<title>References</title>
<biblioentry id="eia608">
<abbrev>EIA&nbsp;608-B</abbrev>
<biblioentry id="cea608">
<abbrev>CEA&nbsp;608-E</abbrev>
<authorgroup>
<corpauthor>Electronic Industries Alliance (<ulink
url="http://www.eia.org">http://www.eia.org</ulink>)</corpauthor>
<corpauthor>Consumer Electronics Association (<ulink
url="http://www.ce.org">http://www.ce.org</ulink>)</corpauthor>
</authorgroup>
<title>EIA 608-B "Recommended Practice for Line 21 Data
Service"</title>
<title>CEA-608-E R-2014 "Line 21 Data Services"</title>
</biblioentry>
<biblioentry id="en300294">

2
Documentation/DocBook/media/v4l/compat.xml
View File

@@ -2491,7 +2491,7 @@ that used it. It was originally scheduled for removal in 2.6.35.
</listitem>
<listitem>
<para>Added <constant>V4L2_EVENT_CTRL_CH_RANGE</constant> control event
changes flag. See <xref linkend="changes-flags"/>.</para>
changes flag. See <xref linkend="ctrl-changes-flags"/>.</para>
</listitem>
</orderedlist>
</section>

4
Documentation/DocBook/media/v4l/controls.xml
View File

@@ -4863,7 +4863,7 @@ interface and may change in the future.</para>
</note>
<para>
The Image Source control class is intended for low-level control of
The Image Process control class is intended for low-level control of
image processing functions. Unlike
<constant>V4L2_CID_IMAGE_SOURCE_CLASS</constant>, the controls in
this class affect processing the image, and do not control capturing
@@ -4871,7 +4871,7 @@ interface and may change in the future.</para>
</para>
<table pgwide="1" frame="none" id="image-process-control-id">
<title>Image Source Control IDs</title>
<title>Image Process Control IDs</title>
<tgroup cols="4">
<colspec colname="c1" colwidth="1*" />

2
Documentation/DocBook/media/v4l/dev-sliced-vbi.xml
View File

@@ -254,7 +254,7 @@ ETS&nbsp;300&nbsp;231, lsb first transmitted.</entry>
<row>
<entry><constant>V4L2_SLICED_CAPTION_525</constant></entry>
<entry>0x1000</entry>
<entry><xref linkend="eia608" /></entry>
<entry><xref linkend="cea608" /></entry>
<entry>NTSC line 21, 284 (second field 21)</entry>
<entry>Two bytes in transmission order, including parity
bit, lsb first transmitted.</entry>

26
Documentation/DocBook/media/v4l/io.xml
View File

@@ -841,15 +841,15 @@ is the file descriptor associated with a DMABUF buffer.</entry>
<entry>__u32</entry>
<entry><structfield>reserved2</structfield></entry>
<entry></entry>
<entry>A place holder for future extensions. Applications
should set this to 0.</entry>
<entry>A place holder for future extensions. Drivers and applications
must set this to 0.</entry>
</row>
<row>
<entry>__u32</entry>
<entry><structfield>reserved</structfield></entry>
<entry></entry>
<entry>A place holder for future extensions. Applications
should set this to 0.</entry>
<entry>A place holder for future extensions. Drivers and applications
must set this to 0.</entry>
</row>
</tbody>
</tgroup>
@@ -930,8 +930,8 @@ should set this to 0.</entry>
<entry>__u32</entry>
<entry><structfield>reserved[11]</structfield></entry>
<entry></entry>
<entry>Reserved for future use. Should be zeroed by an
application.</entry>
<entry>Reserved for future use. Should be zeroed by drivers and
applications.</entry>
</row>
</tbody>
</tgroup>
@@ -1127,6 +1127,18 @@ passed on to a DMA-capable hardware unit for further processing or output.
Typically applications shall use this flag for output buffers if the data
in this buffer has not been created by the CPU but by some DMA-capable unit,
in which case caches have not been used.</entry>
</row>
<row>
<entry><constant>V4L2_BUF_FLAG_LAST</constant></entry>
<entry>0x00100000</entry>
<entry>Last buffer produced by the hardware. mem2mem codec drivers
set this flag on the capture queue for the last buffer when the
<link linkend="vidioc-querybuf">VIDIOC_QUERYBUF</link> or
<link linkend="vidioc-qbuf">VIDIOC_DQBUF</link> ioctl is called. Due to hardware
limitations, the last buffer may be empty. In this case the driver will set the
<structfield>bytesused</structfield> field to 0, regardless of the format. Any
Any subsequent call to the <link linkend="vidioc-qbuf">VIDIOC_DQBUF</link> ioctl
will not block anymore, but return an &EPIPE;.</entry>
</row>
<row>
<entry><constant>V4L2_BUF_FLAG_TIMESTAMP_MASK</constant></entry>
@@ -1155,7 +1167,7 @@ in which case caches have not been used.</entry>
<entry>The buffer timestamp has been taken from the
<constant>CLOCK_MONOTONIC</constant> clock. To access the
same clock outside V4L2, use
<function>clock_gettime(2)</function> .</entry>
<function>clock_gettime(2)</function>.</entry>
</row>
<row>
<entry><constant>V4L2_BUF_FLAG_TIMESTAMP_COPY</constant></entry>

2
Documentation/DocBook/media/v4l/media-func-open.xml
View File

@@ -44,7 +44,7 @@
<para>To open a media device applications call <function>open()</function>
with the desired device name. The function has no side effects; the device
configuration remain unchanged.</para>
<para>When the device is opened in read-only mode, attemps to modify its
<para>When the device is opened in read-only mode, attempts to modify its
configuration will result in an error, and <varname>errno</varname> will be
set to <errorcode>EBADF</errorcode>.</para>
</refsect1>

92
Documentation/DocBook/media/v4l/media-ioc-enum-entities.xml
View File

@@ -143,86 +143,28 @@
<row>
<entry></entry>
<entry>struct</entry>
<entry><structfield>v4l</structfield></entry>
<entry><structfield>dev</structfield></entry>
<entry></entry>
<entry>Valid for V4L sub-devices and nodes only.</entry>
<entry>Valid for (sub-)devices that create a single device node.</entry>
</row>
<row>
<entry></entry>
<entry></entry>
<entry>__u32</entry>
<entry><structfield>major</structfield></entry>
<entry>V4L device node major number. For V4L sub-devices with no
device node, set by the driver to 0.</entry>
<entry>Device node major number.</entry>
</row>
<row>
<entry></entry>
<entry></entry>
<entry>__u32</entry>
<entry><structfield>minor</structfield></entry>
<entry>V4L device node minor number. For V4L sub-devices with no
device node, set by the driver to 0.</entry>
</row>
<row>
<entry></entry>
<entry>struct</entry>
<entry><structfield>fb</structfield></entry>
<entry></entry>
<entry>Valid for frame buffer nodes only.</entry>
</row>
<row>
<entry></entry>
<entry></entry>
<entry>__u32</entry>
<entry><structfield>major</structfield></entry>
<entry>Frame buffer device node major number.</entry>
</row>
<row>
<entry></entry>
<entry></entry>
<entry>__u32</entry>
<entry><structfield>minor</structfield></entry>
<entry>Frame buffer device node minor number.</entry>
</row>
<row>
<entry></entry>
<entry>struct</entry>
<entry><structfield>alsa</structfield></entry>
<entry></entry>
<entry>Valid for ALSA devices only.</entry>
</row>
<row>
<entry></entry>
<entry></entry>
<entry>__u32</entry>
<entry><structfield>card</structfield></entry>
<entry>ALSA card number</entry>
</row>
<row>
<entry></entry>
<entry></entry>
<entry>__u32</entry>
<entry><structfield>device</structfield></entry>
<entry>ALSA device number</entry>
</row>
<row>
<entry></entry>
<entry></entry>
<entry>__u32</entry>
<entry><structfield>subdevice</structfield></entry>
<entry>ALSA sub-device number</entry>
</row>
<row>
<entry></entry>
<entry>int</entry>
<entry><structfield>dvb</structfield></entry>
<entry></entry>
<entry>DVB card number</entry>
<entry>Device node minor number.</entry>
</row>
<row>
<entry></entry>
<entry>__u8</entry>
<entry><structfield>raw</structfield>[180]</entry>
<entry><structfield>raw</structfield>[184]</entry>
<entry></entry>
<entry></entry>
</row>
@@ -253,8 +195,24 @@
<entry>ALSA card</entry>
</row>
<row>
<entry><constant>MEDIA_ENT_T_DEVNODE_DVB</constant></entry>
<entry>DVB card</entry>
<entry><constant>MEDIA_ENT_T_DEVNODE_DVB_FE</constant></entry>
<entry>DVB frontend devnode</entry>
</row>
<row>
<entry><constant>MEDIA_ENT_T_DEVNODE_DVB_DEMUX</constant></entry>
<entry>DVB demux devnode</entry>
</row>
<row>
<entry><constant>MEDIA_ENT_T_DEVNODE_DVB_DVR</constant></entry>
<entry>DVB DVR devnode</entry>
</row>
<row>
<entry><constant>MEDIA_ENT_T_DEVNODE_DVB_CA</constant></entry>
<entry>DVB CAM devnode</entry>
</row>
<row>
<entry><constant>MEDIA_ENT_T_DEVNODE_DVB_NET</constant></entry>
<entry>DVB network devnode</entry>
</row>
<row>
<entry><constant>MEDIA_ENT_T_V4L2_SUBDEV</constant></entry>
@@ -282,6 +240,10 @@
it in some digital video standard, with appropriate embedded timing
signals.</entry>
</row>
<row>
<entry><constant>MEDIA_ENT_T_V4L2_SUBDEV_TUNER</constant></entry>
<entry>TV and/or radio tuner</entry>
</row>
</tbody>
</tgroup>
</table>

79
Documentation/DocBook/media/v4l/pixfmt-packed-rgb.xml
View File

@@ -303,45 +303,6 @@ for a pixel lie next to each other in memory.</para>
<entry>b<subscript>1</subscript></entry>
<entry>b<subscript>0</subscript></entry>
</row>
<row id="V4L2-PIX-FMT-BGR666">
<entry><constant>V4L2_PIX_FMT_BGR666</constant></entry>
<entry>'BGRH'</entry>
<entry></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>g<subscript>5</subscript></entry>
<entry>g<subscript>4</subscript></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>r<subscript>5</subscript></entry>
<entry>r<subscript>4</subscript></entry>
<entry>r<subscript>3</subscript></entry>
<entry>r<subscript>2</subscript></entry>
<entry></entry>
<entry>r<subscript>1</subscript></entry>
<entry>r<subscript>0</subscript></entry>
<entry></entry>
<entry></entry>
<entry></entry>
<entry></entry>
<entry></entry>
<entry></entry>
<entry></entry>
<entry></entry>
<entry></entry>
<entry></entry>
<entry></entry>
<entry></entry>
<entry></entry>
<entry></entry>
</row>
<row id="V4L2-PIX-FMT-BGR24">
<entry><constant>V4L2_PIX_FMT_BGR24</constant></entry>
<entry>'BGR3'</entry>
@@ -404,6 +365,46 @@ for a pixel lie next to each other in memory.</para>
<entry>b<subscript>1</subscript></entry>
<entry>b<subscript>0</subscript></entry>
</row>
<row id="V4L2-PIX-FMT-BGR666">
<entry><constant>V4L2_PIX_FMT_BGR666</constant></entry>
<entry>'BGRH'</entry>
<entry></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>g<subscript>5</subscript></entry>
<entry>g<subscript>4</subscript></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>r<subscript>5</subscript></entry>
<entry>r<subscript>4</subscript></entry>
<entry>r<subscript>3</subscript></entry>
<entry>r<subscript>2</subscript></entry>
<entry></entry>
<entry>r<subscript>1</subscript></entry>
<entry>r<subscript>0</subscript></entry>
<entry>-</entry>
<entry>-</entry>
<entry>-</entry>
<entry>-</entry>
<entry>-</entry>
<entry>-</entry>
<entry></entry>
<entry>-</entry>
<entry>-</entry>
<entry>-</entry>
<entry>-</entry>
<entry>-</entry>
<entry>-</entry>
<entry>-</entry>
<entry>-</entry>
</row>
<row id="V4L2-PIX-FMT-ABGR32">
<entry><constant>V4L2_PIX_FMT_ABGR32</constant></entry>
<entry>'AR24'</entry>

16
Documentation/DocBook/media/v4l/pixfmt-sgrbg8.xml
View File

@@ -38,10 +38,10 @@ columns and rows.</para>
</row>
<row>
<entry>start&nbsp;+&nbsp;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>
<entry>B<subscript>10</subscript></entry>
<entry>G<subscript>11</subscript></entry>
<entry>B<subscript>12</subscript></entry>
<entry>G<subscript>13</subscript></entry>
</row>
<row>
<entry>start&nbsp;+&nbsp;8:</entry>
@@ -52,10 +52,10 @@ columns and rows.</para>
</row>
<row>
<entry>start&nbsp;+&nbsp;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>
<entry>B<subscript>30</subscript></entry>
<entry>G<subscript>31</subscript></entry>
<entry>B<subscript>32</subscript></entry>
<entry>G<subscript>33</subscript></entry>
</row>
</tbody>
</tgroup>

2
Documentation/DocBook/media/v4l/pixfmt-srggb10p.xml
View File

@@ -38,7 +38,7 @@
<title>Byte Order.</title>
<para>Each cell is one byte.
<informaltable frame="topbot" colsep="1" rowsep="1">
<tgroup cols="5" align="center" border="1">
<tgroup cols="5" align="center">
<colspec align="left" colwidth="2*" />
<tbody valign="top">
<row>

81
Documentation/DocBook/media/v4l/pixfmt-y16-be.xml Normal file
View File

@@ -0,0 +1,81 @@
<refentry id="V4L2-PIX-FMT-Y16-BE">
<refmeta>
<refentrytitle>V4L2_PIX_FMT_Y16_BE ('Y16 ' | (1 &lt;&lt; 31))</refentrytitle>
&manvol;
</refmeta>
<refnamediv>
<refname><constant>V4L2_PIX_FMT_Y16_BE</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 most significant byte is stored at lower memory addresses
(big-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_BE</constant> 4 &times; 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&nbsp;+&nbsp;0:</entry>
<entry>Y'<subscript>00high</subscript></entry>
<entry>Y'<subscript>00low</subscript></entry>
<entry>Y'<subscript>01high</subscript></entry>
<entry>Y'<subscript>01low</subscript></entry>
<entry>Y'<subscript>02high</subscript></entry>
<entry>Y'<subscript>02low</subscript></entry>
<entry>Y'<subscript>03high</subscript></entry>
<entry>Y'<subscript>03low</subscript></entry>
</row>
<row>
<entry>start&nbsp;+&nbsp;8:</entry>
<entry>Y'<subscript>10high</subscript></entry>
<entry>Y'<subscript>10low</subscript></entry>
<entry>Y'<subscript>11high</subscript></entry>
<entry>Y'<subscript>11low</subscript></entry>
<entry>Y'<subscript>12high</subscript></entry>
<entry>Y'<subscript>12low</subscript></entry>
<entry>Y'<subscript>13high</subscript></entry>
<entry>Y'<subscript>13low</subscript></entry>
</row>
<row>
<entry>start&nbsp;+&nbsp;16:</entry>
<entry>Y'<subscript>20high</subscript></entry>
<entry>Y'<subscript>20low</subscript></entry>
<entry>Y'<subscript>21high</subscript></entry>
<entry>Y'<subscript>21low</subscript></entry>
<entry>Y'<subscript>22high</subscript></entry>
<entry>Y'<subscript>22low</subscript></entry>
<entry>Y'<subscript>23high</subscript></entry>
<entry>Y'<subscript>23low</subscript></entry>
</row>
<row>
<entry>start&nbsp;+&nbsp;24:</entry>
<entry>Y'<subscript>30high</subscript></entry>
<entry>Y'<subscript>30low</subscript></entry>
<entry>Y'<subscript>31high</subscript></entry>
<entry>Y'<subscript>31low</subscript></entry>
<entry>Y'<subscript>32high</subscript></entry>
<entry>Y'<subscript>32low</subscript></entry>
<entry>Y'<subscript>33high</subscript></entry>
<entry>Y'<subscript>33low</subscript></entry>
</row>
</tbody>
</tgroup>
</informaltable>
</para>
</formalpara>
</example>
</refsect1>
</refentry>

4
Documentation/DocBook/media/v4l/pixfmt-yuv420m.xml
View File

@@ -29,12 +29,12 @@ and Cr planes have half as many pad bytes after their rows. In other
words, two Cx rows (including padding) is exactly as long as one Y row
(including padding).</para>
<para><constant>V4L2_PIX_FMT_NV12M</constant> is intended to be
<para><constant>V4L2_PIX_FMT_YUV420M</constant> is intended to be
used only in drivers and applications that support the multi-planar API,
described in <xref linkend="planar-apis"/>. </para>
<example>
<title><constant>V4L2_PIX_FMT_YVU420M</constant> 4 &times; 4
<title><constant>V4L2_PIX_FMT_YUV420M</constant> 4 &times; 4
pixel image</title>
<formalpara>

240
Documentation/DocBook/media/v4l/pixfmt.xml
View File

@@ -80,9 +80,9 @@ 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
<structfield>bytesperline</structfield> value applies to the first
plane and is divided by the same factor as the
<structfield>width</structfield> field for any smaller planes. For
<structfield>width</structfield> field for the other 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
@@ -155,6 +155,14 @@ see <xref linkend="colorspaces" />.</entry>
<entry>This information supplements the
<structfield>colorspace</structfield> and must be set by the driver for
capture streams and by the application for output streams,
see <xref linkend="colorspaces" />.</entry>
</row>
<row>
<entry>&v4l2-xfer-func;</entry>
<entry><structfield>xfer_func</structfield></entry>
<entry>This information supplements the
<structfield>colorspace</structfield> and must be set by the driver for
capture streams and by the application for output streams,
see <xref linkend="colorspaces" />.</entry>
</row>
</tbody>
@@ -182,16 +190,16 @@ see <xref linkend="colorspaces" />.</entry>
</entry>
</row>
<row>
<entry>__u16</entry>
<entry>__u32</entry>
<entry><structfield>bytesperline</structfield></entry>
<entry>Distance in bytes between the leftmost pixels in two adjacent
lines. See &v4l2-pix-format;.</entry>
</row>
<row>
<entry>__u16</entry>
<entry><structfield>reserved[7]</structfield></entry>
<entry>Reserved for future extensions. Should be zeroed by the
application.</entry>
<entry><structfield>reserved[6]</structfield></entry>
<entry>Reserved for future extensions. Should be zeroed by drivers and
applications.</entry>
</row>
</tbody>
</tgroup>
@@ -262,13 +270,21 @@ see <xref linkend="colorspaces" />.</entry>
<entry>This information supplements the
<structfield>colorspace</structfield> and must be set by the driver for
capture streams and by the application for output streams,
see <xref linkend="colorspaces" />.</entry>
</row>
<row>
<entry>&v4l2-xfer-func;</entry>
<entry><structfield>xfer_func</structfield></entry>
<entry>This information supplements the
<structfield>colorspace</structfield> and must be set by the driver for
capture streams and by the application for output streams,
see <xref linkend="colorspaces" />.</entry>
</row>
<row>
<entry>__u8</entry>
<entry><structfield>reserved[8]</structfield></entry>
<entry>Reserved for future extensions. Should be zeroed by the
application.</entry>
<entry><structfield>reserved[7]</structfield></entry>
<entry>Reserved for future extensions. Should be zeroed by drivers
and applications.</entry>
</row>
</tbody>
</tgroup>
@@ -476,15 +492,16 @@ is also very useful.</para>
<section>
<title>Defining Colorspaces in V4L2</title>
<para>In V4L2 colorspaces are defined by three values. The first is the colorspace
identifier (&v4l2-colorspace;) which defines the chromaticities, the transfer
<para>In V4L2 colorspaces are defined by four values. The first is the colorspace
identifier (&v4l2-colorspace;) which defines the chromaticities, the default transfer
function, the default Y'CbCr encoding and the default quantization method. The second
is the Y'CbCr encoding identifier (&v4l2-ycbcr-encoding;) to specify non-standard
Y'CbCr encodings and the third is the quantization identifier (&v4l2-quantization;)
to specify non-standard quantization methods. Most of the time only the colorspace
field of &v4l2-pix-format; or &v4l2-pix-format-mplane; needs to be filled in. Note
that the default R'G'B' quantization is always full range for all colorspaces,
so this won't be mentioned explicitly for each colorspace description.</para>
is the transfer function identifier (&v4l2-xfer-func;) to specify non-standard
transfer functions. The third is the Y'CbCr encoding identifier (&v4l2-ycbcr-encoding;)
to specify non-standard Y'CbCr encodings and the fourth is the quantization identifier
(&v4l2-quantization;) to specify non-standard quantization methods. Most of the time
only the colorspace field of &v4l2-pix-format; or &v4l2-pix-format-mplane; needs to
be filled in. Note that the default R'G'B' quantization is full range for all
colorspaces except for BT.2020 which uses limited range R'G'B' quantization.</para>
<table pgwide="1" frame="none" id="v4l2-colorspace">
<title>V4L2 Colorspaces</title>
@@ -497,6 +514,11 @@ so this won't be mentioned explicitly for each colorspace description.</para>
</row>
</thead>
<tbody valign="top">
<row>
<entry><constant>V4L2_COLORSPACE_DEFAULT</constant></entry>
<entry>The default colorspace. This can be used by applications to let the
driver fill in the colorspace.</entry>
</row>
<row>
<entry><constant>V4L2_COLORSPACE_SMPTE170M</constant></entry>
<entry>See <xref linkend="col-smpte-170m" />.</entry>
@@ -533,6 +555,52 @@ so this won't be mentioned explicitly for each colorspace description.</para>
<entry><constant>V4L2_COLORSPACE_JPEG</constant></entry>
<entry>See <xref linkend="col-jpeg" />.</entry>
</row>
<row>
<entry><constant>V4L2_COLORSPACE_RAW</constant></entry>
<entry>The raw colorspace. This is used for raw image capture where
the image is minimally processed and is using the internal colorspace
of the device. The software that processes an image using this
'colorspace' will have to know the internals of the capture device.</entry>
</row>
</tbody>
</tgroup>
</table>
<table pgwide="1" frame="none" id="v4l2-xfer-func">
<title>V4L2 Transfer Function</title>
<tgroup cols="2" align="left">
&cs-def;
<thead>
<row>
<entry>Identifier</entry>
<entry>Details</entry>
</row>
</thead>
<tbody valign="top">
<row>
<entry><constant>V4L2_XFER_FUNC_DEFAULT</constant></entry>
<entry>Use the default transfer function as defined by the colorspace.</entry>
</row>
<row>
<entry><constant>V4L2_XFER_FUNC_709</constant></entry>
<entry>Use the Rec. 709 transfer function.</entry>
</row>
<row>
<entry><constant>V4L2_XFER_FUNC_SRGB</constant></entry>
<entry>Use the sRGB transfer function.</entry>
</row>
<row>
<entry><constant>V4L2_XFER_FUNC_ADOBERGB</constant></entry>
<entry>Use the AdobeRGB transfer function.</entry>
</row>
<row>
<entry><constant>V4L2_XFER_FUNC_SMPTE240M</constant></entry>
<entry>Use the SMPTE 240M transfer function.</entry>
</row>
<row>
<entry><constant>V4L2_XFER_FUNC_NONE</constant></entry>
<entry>Do not use a transfer function (i.e. use linear RGB values).</entry>
</row>
</tbody>
</tgroup>
</table>
@@ -598,7 +666,8 @@ so this won't be mentioned explicitly for each colorspace description.</para>
<row>
<entry><constant>V4L2_QUANTIZATION_DEFAULT</constant></entry>
<entry>Use the default quantization encoding as defined by the colorspace.
This is always full range for R'G'B' and usually limited range for Y'CbCr.</entry>
This is always full range for R'G'B' (except for the BT.2020 colorspace) and usually
limited range for Y'CbCr.</entry>
</row>
<row>
<entry><constant>V4L2_QUANTIZATION_FULL_RANGE</constant></entry>
@@ -620,10 +689,11 @@ is mapped to [16&hellip;235]. Cb and Cr are mapped from [-0.5&hellip;0.5] to [16
<section>
<title>Detailed Colorspace Descriptions</title>
<section>
<title id="col-smpte-170m">Colorspace SMPTE 170M (<constant>V4L2_COLORSPACE_SMPTE170M</constant>)</title>
<section id="col-smpte-170m">
<title>Colorspace SMPTE 170M (<constant>V4L2_COLORSPACE_SMPTE170M</constant>)</title>
<para>The <xref linkend="smpte170m" /> standard defines the colorspace used by NTSC and PAL and by SDTV
in general. The default Y'CbCr encoding is <constant>V4L2_YCBCR_ENC_601</constant>.
in general. The default transfer function is <constant>V4L2_XFER_FUNC_709</constant>.
The default Y'CbCr encoding is <constant>V4L2_YCBCR_ENC_601</constant>.
The default Y'CbCr quantization is limited range. The chromaticities of the primary colors and
the white reference are:</para>
<table frame="none">
@@ -666,8 +736,7 @@ as the SMPTE C set, so this colorspace is sometimes called SMPTE C as well.</par
<variablelist>
<varlistentry>
<term>The transfer function defined for SMPTE 170M is the same as the
one defined in Rec. 709. Normally L is in the range [0&hellip;1], but for the extended
gamut xvYCC encoding values outside that range are allowed.</term>
one defined in Rec. 709.</term>
<listitem>
<para>L' = -1.099(-L)<superscript>0.45</superscript>&nbsp;+&nbsp;0.099&nbsp;for&nbsp;L&nbsp;&le;&nbsp;-0.018</para>
<para>L' = 4.5L&nbsp;for&nbsp;-0.018&nbsp;&lt;&nbsp;L&nbsp;&lt;&nbsp;0.018</para>
@@ -702,30 +771,12 @@ defined in the <xref linkend="itu601" /> standard and this colorspace is sometim
though BT.601 does not mention any color primaries.</para>
<para>The default quantization is limited range, but full range is possible although
rarely seen.</para>
<para>The <constant>V4L2_YCBCR_ENC_601</constant> encoding as described above is the
default for this colorspace, but it can be overridden with <constant>V4L2_YCBCR_ENC_709</constant>,
in which case the Rec. 709 Y'CbCr encoding is used.</para>
<variablelist>
<varlistentry>
<term>The xvYCC 601 encoding (<constant>V4L2_YCBCR_ENC_XV601</constant>, <xref linkend="xvycc" />) is similar
to the BT.601 encoding, but it allows for R', G' and B' values that are outside the range
[0&hellip;1]. The resulting Y', Cb and Cr values are scaled and offset:</term>
<listitem>
<para>Y'&nbsp;=&nbsp;(219&nbsp;/&nbsp;255)&nbsp;*&nbsp;(0.299R'&nbsp;+&nbsp;0.587G'&nbsp;+&nbsp;0.114B')&nbsp;+&nbsp;(16&nbsp;/&nbsp;255)</para>
<para>Cb&nbsp;=&nbsp;(224&nbsp;/&nbsp;255)&nbsp;*&nbsp;(-0.169R'&nbsp;-&nbsp;0.331G'&nbsp;+&nbsp;0.5B')</para>
<para>Cr&nbsp;=&nbsp;(224&nbsp;/&nbsp;255)&nbsp;*&nbsp;(0.5R'&nbsp;-&nbsp;0.419G'&nbsp;-&nbsp;0.081B')</para>
</listitem>
</varlistentry>
</variablelist>
<para>Y' is clamped to the range [0&hellip;1] and Cb and Cr are clamped
to the range [-0.5&hellip;0.5]. The non-standard xvYCC 709 encoding can also be used by selecting
<constant>V4L2_YCBCR_ENC_XV709</constant>. The xvYCC encodings always use full range
quantization.</para>
</section>
<section>
<title id="col-rec709">Colorspace Rec. 709 (<constant>V4L2_COLORSPACE_REC709</constant>)</title>
<para>The <xref linkend="itu709" /> standard defines the colorspace used by HDTV in general. The default
<section id="col-rec709">
<title>Colorspace Rec. 709 (<constant>V4L2_COLORSPACE_REC709</constant>)</title>
<para>The <xref linkend="itu709" /> standard defines the colorspace used by HDTV in general.
The default transfer function is <constant>V4L2_XFER_FUNC_709</constant>. The default
Y'CbCr encoding is <constant>V4L2_YCBCR_ENC_709</constant>. The default Y'CbCr quantization is
limited range. The chromaticities of the primary colors and the white reference are:</para>
<table frame="none">
@@ -803,29 +854,44 @@ rarely seen.</para>
<para>The <constant>V4L2_YCBCR_ENC_709</constant> encoding described above is the default
for this colorspace, but it can be overridden with <constant>V4L2_YCBCR_ENC_601</constant>, in which
case the BT.601 Y'CbCr encoding is used.</para>
<para>Two additional extended gamut Y'CbCr encodings are also possible with this colorspace:</para>
<variablelist>
<varlistentry>
<term>The xvYCC 709 encoding (<constant>V4L2_YCBCR_ENC_XV709</constant>, <xref linkend="xvycc" />)
is similar to the Rec. 709 encoding, but it allows for R', G' and B' values that are outside the range
[0&hellip;1]. The resulting Y', Cb and Cr values are scaled and offset:</term>
<listitem>
<para>Y'&nbsp;=&nbsp;(219&nbsp;/&nbsp;255)&nbsp;*&nbsp;(0.2126R'&nbsp;+&nbsp;0.7152G'&nbsp;+&nbsp;0.0722B')&nbsp;+&nbsp;(16&nbsp;/&nbsp;255)</para>
<para>Cb&nbsp;=&nbsp;(224&nbsp;/&nbsp;255)&nbsp;*&nbsp;(-0.1146R'&nbsp;-&nbsp;0.3854G'&nbsp;+&nbsp;0.5B')</para>
<para>Cr&nbsp;=&nbsp;(224&nbsp;/&nbsp;255)&nbsp;*&nbsp;(0.5R'&nbsp;-&nbsp;0.4542G'&nbsp;-&nbsp;0.0458B')</para>
<para>Y'&nbsp;=&nbsp;(219&nbsp;/&nbsp;256)&nbsp;*&nbsp;(0.2126R'&nbsp;+&nbsp;0.7152G'&nbsp;+&nbsp;0.0722B')&nbsp;+&nbsp;(16&nbsp;/&nbsp;256)</para>
<para>Cb&nbsp;=&nbsp;(224&nbsp;/&nbsp;256)&nbsp;*&nbsp;(-0.1146R'&nbsp;-&nbsp;0.3854G'&nbsp;+&nbsp;0.5B')</para>
<para>Cr&nbsp;=&nbsp;(224&nbsp;/&nbsp;256)&nbsp;*&nbsp;(0.5R'&nbsp;-&nbsp;0.4542G'&nbsp;-&nbsp;0.0458B')</para>
</listitem>
</varlistentry>
</variablelist>
<variablelist>
<varlistentry>
<term>The xvYCC 601 encoding (<constant>V4L2_YCBCR_ENC_XV601</constant>, <xref linkend="xvycc" />) is similar
to the BT.601 encoding, but it allows for R', G' and B' values that are outside the range
[0&hellip;1]. The resulting Y', Cb and Cr values are scaled and offset:</term>
<listitem>
<para>Y'&nbsp;=&nbsp;(219&nbsp;/&nbsp;256)&nbsp;*&nbsp;(0.299R'&nbsp;+&nbsp;0.587G'&nbsp;+&nbsp;0.114B')&nbsp;+&nbsp;(16&nbsp;/&nbsp;256)</para>
<para>Cb&nbsp;=&nbsp;(224&nbsp;/&nbsp;256)&nbsp;*&nbsp;(-0.169R'&nbsp;-&nbsp;0.331G'&nbsp;+&nbsp;0.5B')</para>
<para>Cr&nbsp;=&nbsp;(224&nbsp;/&nbsp;256)&nbsp;*&nbsp;(0.5R'&nbsp;-&nbsp;0.419G'&nbsp;-&nbsp;0.081B')</para>
</listitem>
</varlistentry>
</variablelist>
<para>Y' is clamped to the range [0&hellip;1] and Cb and Cr are clamped
to the range [-0.5&hellip;0.5]. The non-standard xvYCC 601 encoding can also be used by
selecting <constant>V4L2_YCBCR_ENC_XV601</constant>. The xvYCC encodings always use full
range quantization.</para>
to the range [-0.5&hellip;0.5]. The non-standard xvYCC 709 or xvYCC 601 encodings can be used by
selecting <constant>V4L2_YCBCR_ENC_XV709</constant> or <constant>V4L2_YCBCR_ENC_XV601</constant>.
The xvYCC encodings always use full range quantization.</para>
</section>
<section>
<title id="col-srgb">Colorspace sRGB (<constant>V4L2_COLORSPACE_SRGB</constant>)</title>
<para>The <xref linkend="srgb" /> standard defines the colorspace used by most webcams and computer graphics. The
default Y'CbCr encoding is <constant>V4L2_YCBCR_ENC_SYCC</constant>. The default Y'CbCr quantization
is full range. The chromaticities of the primary colors and the white reference are:</para>
<section id="col-srgb">
<title>Colorspace sRGB (<constant>V4L2_COLORSPACE_SRGB</constant>)</title>
<para>The <xref linkend="srgb" /> standard defines the colorspace used by most webcams
and computer graphics. The default transfer function is <constant>V4L2_XFER_FUNC_SRGB</constant>.
The default Y'CbCr encoding is <constant>V4L2_YCBCR_ENC_SYCC</constant>. The default Y'CbCr
quantization is full range. The chromaticities of the primary colors and the white
reference are:</para>
<table frame="none">
<title>sRGB Chromaticities</title>
<tgroup cols="3" align="left">
@@ -898,10 +964,11 @@ encoding, it is not. The <constant>V4L2_YCBCR_ENC_XV601</constant> scales and of
values before quantization, but this encoding does not do that.</para>
</section>
<section>
<title id="col-adobergb">Colorspace Adobe RGB (<constant>V4L2_COLORSPACE_ADOBERGB</constant>)</title>
<section id="col-adobergb">
<title>Colorspace Adobe RGB (<constant>V4L2_COLORSPACE_ADOBERGB</constant>)</title>
<para>The <xref linkend="adobergb" /> standard defines the colorspace used by computer graphics
that use the AdobeRGB colorspace. This is also known as the <xref linkend="oprgb" /> standard.
The default transfer function is <constant>V4L2_XFER_FUNC_ADOBERGB</constant>.
The default Y'CbCr encoding is <constant>V4L2_YCBCR_ENC_601</constant>. The default Y'CbCr
quantization is limited range. The chromaticities of the primary colors and the white reference
are:</para>
@@ -970,12 +1037,13 @@ clamped to the range [-0.5&hellip;0.5]. This transform is identical to one defin
SMPTE 170M/BT.601. The Y'CbCr quantization is limited range.</para>
</section>
<section>
<title id="col-bt2020">Colorspace BT.2020 (<constant>V4L2_COLORSPACE_BT2020</constant>)</title>
<section id="col-bt2020">
<title>Colorspace BT.2020 (<constant>V4L2_COLORSPACE_BT2020</constant>)</title>
<para>The <xref linkend="itu2020" /> standard defines the colorspace used by Ultra-high definition
television (UHDTV). The default Y'CbCr encoding is <constant>V4L2_YCBCR_ENC_BT2020</constant>.
The default Y'CbCr quantization is limited range. The chromaticities of the primary colors and
the white reference are:</para>
television (UHDTV). The default transfer function is <constant>V4L2_XFER_FUNC_709</constant>.
The default Y'CbCr encoding is <constant>V4L2_YCBCR_ENC_BT2020</constant>.
The default R'G'B' quantization is limited range (!), and so is the default Y'CbCr quantization.
The chromaticities of the primary colors and the white reference are:</para>
<table frame="none">
<title>BT.2020 Chromaticities</title>
<tgroup cols="3" align="left">
@@ -1032,7 +1100,7 @@ the white reference are:</para>
<term>The luminance (Y') and color difference (Cb and Cr) are obtained with the
following <constant>V4L2_YCBCR_ENC_BT2020</constant> encoding:</term>
<listitem>
<para>Y'&nbsp;=&nbsp;0.2627R'&nbsp;+&nbsp;0.6789G'&nbsp;+&nbsp;0.0593B'</para>
<para>Y'&nbsp;=&nbsp;0.2627R'&nbsp;+&nbsp;0.6780G'&nbsp;+&nbsp;0.0593B'</para>
<para>Cb&nbsp;=&nbsp;-0.1396R'&nbsp;-&nbsp;0.3604G'&nbsp;+&nbsp;0.5B'</para>
<para>Cr&nbsp;=&nbsp;0.5R'&nbsp;-&nbsp;0.4598G'&nbsp;-&nbsp;0.0402B'</para>
</listitem>
@@ -1046,7 +1114,7 @@ clamped to the range [-0.5&hellip;0.5]. The Y'CbCr quantization is limited range
<varlistentry>
<term>Luma:</term>
<listitem>
<para>Yc'&nbsp;=&nbsp;(0.2627R&nbsp;+&nbsp;0.6789G&nbsp;+&nbsp;0.0593B)'</para>
<para>Yc'&nbsp;=&nbsp;(0.2627R&nbsp;+&nbsp;0.6780G&nbsp;+&nbsp;0.0593B)'</para>
</listitem>
</varlistentry>
</variablelist>
@@ -1054,7 +1122,7 @@ clamped to the range [-0.5&hellip;0.5]. The Y'CbCr quantization is limited range
<varlistentry>
<term>B'&nbsp;-&nbsp;Yc'&nbsp;&le;&nbsp;0:</term>
<listitem>
<para>Cbc&nbsp;=&nbsp;(B'&nbsp;-&nbsp;Y')&nbsp;/&nbsp;1.9404</para>
<para>Cbc&nbsp;=&nbsp;(B'&nbsp;-&nbsp;Yc')&nbsp;/&nbsp;1.9404</para>
</listitem>
</varlistentry>
</variablelist>
@@ -1062,7 +1130,7 @@ clamped to the range [-0.5&hellip;0.5]. The Y'CbCr quantization is limited range
<varlistentry>
<term>B'&nbsp;-&nbsp;Yc'&nbsp;&gt;&nbsp;0:</term>
<listitem>
<para>Cbc&nbsp;=&nbsp;(B'&nbsp;-&nbsp;Y')&nbsp;/&nbsp;1.5816</para>
<para>Cbc&nbsp;=&nbsp;(B'&nbsp;-&nbsp;Yc')&nbsp;/&nbsp;1.5816</para>
</listitem>
</varlistentry>
</variablelist>
@@ -1086,10 +1154,12 @@ clamped to the range [-0.5&hellip;0.5]. The Y'CbCr quantization is limited range
clamped to the range [-0.5&hellip;0.5]. The Yc'CbcCrc quantization is limited range.</para>
</section>
<section>
<title id="col-smpte-240m">Colorspace SMPTE 240M (<constant>V4L2_COLORSPACE_SMPTE240M</constant>)</title>
<para>The <xref linkend="smpte240m" /> standard was an interim standard used during the early days of HDTV (1988-1998).
It has been superseded by Rec. 709. The default Y'CbCr encoding is <constant>V4L2_YCBCR_ENC_SMPTE240M</constant>.
<section id="col-smpte-240m">
<title>Colorspace SMPTE 240M (<constant>V4L2_COLORSPACE_SMPTE240M</constant>)</title>
<para>The <xref linkend="smpte240m" /> standard was an interim standard used during
the early days of HDTV (1988-1998). It has been superseded by Rec. 709.
The default transfer function is <constant>V4L2_XFER_FUNC_SMPTE240M</constant>.
The default Y'CbCr encoding is <constant>V4L2_YCBCR_ENC_SMPTE240M</constant>.
The default Y'CbCr quantization is limited range. The chromaticities of the primary colors and the
white reference are:</para>
<table frame="none">
@@ -1159,11 +1229,13 @@ following <constant>V4L2_YCBCR_ENC_SMPTE240M</constant> encoding:</term>
clamped to the range [-0.5&hellip;0.5]. The Y'CbCr quantization is limited range.</para>
</section>
<section>
<title id="col-sysm">Colorspace NTSC 1953 (<constant>V4L2_COLORSPACE_470_SYSTEM_M</constant>)</title>
<section id="col-sysm">
<title>Colorspace NTSC 1953 (<constant>V4L2_COLORSPACE_470_SYSTEM_M</constant>)</title>
<para>This standard defines the colorspace used by NTSC in 1953. In practice this
colorspace is obsolete and SMPTE 170M should be used instead. The default Y'CbCr encoding
is <constant>V4L2_YCBCR_ENC_601</constant>. The default Y'CbCr quantization is limited range.
colorspace is obsolete and SMPTE 170M should be used instead.
The default transfer function is <constant>V4L2_XFER_FUNC_709</constant>.
The default Y'CbCr encoding is <constant>V4L2_YCBCR_ENC_601</constant>.
The default Y'CbCr quantization is limited range.
The chromaticities of the primary colors and the white reference are:</para>
<table frame="none">
<title>NTSC 1953 Chromaticities</title>
@@ -1237,11 +1309,13 @@ clamped to the range [-0.5&hellip;0.5]. The Y'CbCr quantization is limited range
This transform is identical to one defined in SMPTE 170M/BT.601.</para>
</section>
<section>
<title id="col-sysbg">Colorspace EBU Tech. 3213 (<constant>V4L2_COLORSPACE_470_SYSTEM_BG</constant>)</title>
<section id="col-sysbg">
<title>Colorspace EBU Tech. 3213 (<constant>V4L2_COLORSPACE_470_SYSTEM_BG</constant>)</title>
<para>The <xref linkend="tech3213" /> standard defines the colorspace used by PAL/SECAM in 1975. In practice this
colorspace is obsolete and SMPTE 170M should be used instead. The default Y'CbCr encoding
is <constant>V4L2_YCBCR_ENC_601</constant>. The default Y'CbCr quantization is limited range.
colorspace is obsolete and SMPTE 170M should be used instead.
The default transfer function is <constant>V4L2_XFER_FUNC_709</constant>.
The default Y'CbCr encoding is <constant>V4L2_YCBCR_ENC_601</constant>.
The default Y'CbCr quantization is limited range.
The chromaticities of the primary colors and the white reference are:</para>
<table frame="none">
<title>EBU Tech. 3213 Chromaticities</title>
@@ -1311,10 +1385,11 @@ clamped to the range [-0.5&hellip;0.5]. The Y'CbCr quantization is limited range
This transform is identical to one defined in SMPTE 170M/BT.601.</para>
</section>
<section>
<title id="col-jpeg">Colorspace JPEG (<constant>V4L2_COLORSPACE_JPEG</constant>)</title>
<section id="col-jpeg">
<title>Colorspace JPEG (<constant>V4L2_COLORSPACE_JPEG</constant>)</title>
<para>This colorspace defines the colorspace used by most (Motion-)JPEG formats. The chromaticities
of the primary colors and the white reference are identical to sRGB. The Y'CbCr encoding is
of the primary colors and the white reference are identical to sRGB. The transfer
function use is <constant>V4L2_XFER_FUNC_SRGB</constant>. The Y'CbCr encoding is
<constant>V4L2_YCBCR_ENC_601</constant> with full range quantization where
Y' is scaled to [0&hellip;255] and Cb/Cr are scaled to [-128&hellip;128] and
then clipped to [-128&hellip;127].</para>
@@ -1435,6 +1510,7 @@ information.</para>
&sub-y12;
&sub-y10b;
&sub-y16;
&sub-y16-be;
&sub-uv8;
&sub-yuyv;
&sub-uyvy;

2
Documentation/DocBook/media/v4l/remote_controllers.xml
View File

@@ -284,7 +284,7 @@ different IR's. Due to that, V4L2 API now specifies a standard for mapping Media
</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>
<para>It should be noted 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>

1203
Documentation/DocBook/media/v4l/subdev-formats.xml
View File

File diff suppressed because it is too large Load Diff

9
Documentation/DocBook/media/v4l/v4l2.xml
View File

@@ -136,6 +136,7 @@ Remote Controller chapter.</contrib>
<year>2012</year>
<year>2013</year>
<year>2014</year>
<year>2015</year>
<holder>Bill Dirks, Michael H. Schimek, Hans Verkuil, Martin
Rubli, Andy Walls, Muralidharan Karicheri, Mauro Carvalho Chehab,
Pawel Osciak</holder>
@@ -151,6 +152,14 @@ structs, ioctls) must be noted in more detail in the history chapter
(compat.xml), along with the possible impact on existing drivers and
applications. -->
<revision>
<revnumber>3.21</revnumber>
<date>2015-02-13</date>
<authorinitials>mcc</authorinitials>
<revremark>Fix documentation for media controller device nodes and add support for DVB device nodes.
Add support for Tuner sub-device.
</revremark>
</revision>
<revision>
<revnumber>3.19</revnumber>
<date>2014-12-05</date>

3
Documentation/DocBook/media/v4l/vidioc-create-bufs.xml
View File

@@ -134,7 +134,8 @@ information.</para>
<row>
<entry>__u32</entry>
<entry><structfield>reserved</structfield>[8]</entry>
<entry>A place holder for future extensions.</entry>
<entry>A place holder for future extensions. Drivers and applications
must set the array to zero.</entry>
</row>
</tbody>
</tgroup>

9
Documentation/DocBook/media/v4l/vidioc-cropcap.xml
View File

@@ -59,6 +59,11 @@ constant except when switching the video standard. Remember this
switch can occur implicit when switching the video input or
output.</para>
<para>Do not use the multiplanar buffer types. Use <constant>V4L2_BUF_TYPE_VIDEO_CAPTURE</constant>
instead of <constant>V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE</constant>
and use <constant>V4L2_BUF_TYPE_VIDEO_OUTPUT</constant> instead of
<constant>V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE</constant>.</para>
<para>This ioctl must be implemented for video capture or output devices that
support cropping and/or scaling and/or have non-square pixels, and for overlay devices.</para>
@@ -73,9 +78,7 @@ support cropping and/or scaling and/or have non-square pixels, and for overlay d
<entry>Type of the data stream, set by the application.
Only these types are valid here:
<constant>V4L2_BUF_TYPE_VIDEO_CAPTURE</constant>,
<constant>V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE</constant>,
<constant>V4L2_BUF_TYPE_VIDEO_OUTPUT</constant>,
<constant>V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE</constant> and
<constant>V4L2_BUF_TYPE_VIDEO_OUTPUT</constant> and
<constant>V4L2_BUF_TYPE_VIDEO_OVERLAY</constant>. See <xref linkend="v4l2-buf-type" />.</entry>
</row>
<row>

12
Documentation/DocBook/media/v4l/vidioc-decoder-cmd.xml
View File

@@ -197,7 +197,17 @@ be muted when playing back at a non-standard speed.
this command does nothing. This command has two flags:
if <constant>V4L2_DEC_CMD_STOP_TO_BLACK</constant> is set, then the decoder will
set the picture to black after it stopped decoding. Otherwise the last image will
repeat. If <constant>V4L2_DEC_CMD_STOP_IMMEDIATELY</constant> is set, then the decoder
repeat. mem2mem decoders will stop producing new frames altogether. They will send
a <constant>V4L2_EVENT_EOS</constant> event when the last frame has been decoded
and all frames are ready to be dequeued and will set the
<constant>V4L2_BUF_FLAG_LAST</constant> buffer flag on the last buffer of the
capture queue to indicate there will be no new buffers produced to dequeue. This
buffer may be empty, indicated by the driver setting the
<structfield>bytesused</structfield> field to 0. Once the
<constant>V4L2_BUF_FLAG_LAST</constant> flag was set, the
<link linkend="vidioc-qbuf">VIDIOC_DQBUF</link> ioctl will not block anymore,
but return an &EPIPE;.
If <constant>V4L2_DEC_CMD_STOP_IMMEDIATELY</constant> is set, then the decoder
stops immediately (ignoring the <structfield>pts</structfield> value), otherwise it
will keep decoding until timestamp >= pts or until the last of the pending data from
its internal buffers was decoded.

126
Documentation/DocBook/media/v4l/vidioc-dqevent.xml
View File

@@ -64,7 +64,7 @@
<entry>__u32</entry>
<entry><structfield>type</structfield></entry>
<entry></entry>
<entry>Type of the event.</entry>
<entry>Type of the event, see <xref linkend="event-type" />.</entry>
</row>
<row>
<entry>union</entry>
@@ -133,7 +133,10 @@
<entry>struct timespec</entry>
<entry><structfield>timestamp</structfield></entry>
<entry></entry>
<entry>Event timestamp.</entry>
<entry>Event timestamp. The timestamp has been taken from the
<constant>CLOCK_MONOTONIC</constant> clock. To access the
same clock outside V4L2, use <function>clock_gettime(2)</function>.
</entry>
</row>
<row>
<entry>u32</entry>
@@ -154,6 +157,113 @@
</tgroup>
</table>
<table frame="none" pgwide="1" id="event-type">
<title>Event Types</title>
<tgroup cols="3">
&cs-def;
<tbody valign="top">
<row>
<entry><constant>V4L2_EVENT_ALL</constant></entry>
<entry>0</entry>
<entry>All events. V4L2_EVENT_ALL is valid only for
VIDIOC_UNSUBSCRIBE_EVENT for unsubscribing all events at once.
</entry>
</row>
<row>
<entry><constant>V4L2_EVENT_VSYNC</constant></entry>
<entry>1</entry>
<entry>This event is triggered on the vertical sync.
This event has a &v4l2-event-vsync; associated with it.
</entry>
</row>
<row>
<entry><constant>V4L2_EVENT_EOS</constant></entry>
<entry>2</entry>
<entry>This event is triggered when the end of a stream is reached.
This is typically used with MPEG decoders to report to the application
when the last of the MPEG stream has been decoded.
</entry>
</row>
<row>
<entry><constant>V4L2_EVENT_CTRL</constant></entry>
<entry>3</entry>
<entry><para>This event requires that the <structfield>id</structfield>
matches the control ID from which you want to receive events.
This event is triggered if the control's value changes, if a
button control is pressed or if the control's flags change.
This event has a &v4l2-event-ctrl; associated with it. This struct
contains much of the same information as &v4l2-queryctrl; and
&v4l2-control;.</para>
<para>If the event is generated due to a call to &VIDIOC-S-CTRL; or
&VIDIOC-S-EXT-CTRLS;, then the event will <emphasis>not</emphasis> be sent to
the file handle that called the ioctl function. This prevents
nasty feedback loops. If you <emphasis>do</emphasis> want to get the
event, then set the <constant>V4L2_EVENT_SUB_FL_ALLOW_FEEDBACK</constant>
flag.
</para>
<para>This event type will ensure that no information is lost when
more events are raised than there is room internally. In that
case the &v4l2-event-ctrl; of the second-oldest event is kept,
but the <structfield>changes</structfield> field of the
second-oldest event is ORed with the <structfield>changes</structfield>
field of the oldest event.</para>
</entry>
</row>
<row>
<entry><constant>V4L2_EVENT_FRAME_SYNC</constant></entry>
<entry>4</entry>
<entry>
<para>Triggered immediately when the reception of a
frame has begun. This event has a
&v4l2-event-frame-sync; associated with it.</para>
<para>If the hardware needs to be stopped in the case of a
buffer underrun it might not be able to generate this event.
In such cases the <structfield>frame_sequence</structfield>
field in &v4l2-event-frame-sync; will not be incremented. This
causes two consecutive frame sequence numbers to have n times
frame interval in between them.</para>
</entry>
</row>
<row>
<entry><constant>V4L2_EVENT_SOURCE_CHANGE</constant></entry>
<entry>5</entry>
<entry>
<para>This event is triggered when a source parameter change is
detected during runtime by the video device. It can be a
runtime resolution change triggered by a video decoder or the
format change happening on an input connector.
This event requires that the <structfield>id</structfield>
matches the input index (when used with a video device node)
or the pad index (when used with a subdevice node) from which
you want to receive events.</para>
<para>This event has a &v4l2-event-src-change; associated
with it. The <structfield>changes</structfield> bitfield denotes
what has changed for the subscribed pad. If multiple events
occurred before application could dequeue them, then the changes
will have the ORed value of all the events generated.</para>
</entry>
</row>
<row>
<entry><constant>V4L2_EVENT_MOTION_DET</constant></entry>
<entry>6</entry>
<entry>
<para>Triggered whenever the motion detection state for one or more of the regions
changes. This event has a &v4l2-event-motion-det; associated with it.</para>
</entry>
</row>
<row>
<entry><constant>V4L2_EVENT_PRIVATE_START</constant></entry>
<entry>0x08000000</entry>
<entry>Base event number for driver-private events.</entry>
</row>
</tbody>
</tgroup>
</table>
<table frame="none" pgwide="1" id="v4l2-event-vsync">
<title>struct <structname>v4l2_event_vsync</structname></title>
<tgroup cols="3">
@@ -177,7 +287,7 @@
<entry>__u32</entry>
<entry><structfield>changes</structfield></entry>
<entry></entry>
<entry>A bitmask that tells what has changed. See <xref linkend="changes-flags" />.</entry>
<entry>A bitmask that tells what has changed. See <xref linkend="ctrl-changes-flags" />.</entry>
</row>
<row>
<entry>__u32</entry>
@@ -309,8 +419,8 @@
</tgroup>
</table>
<table pgwide="1" frame="none" id="changes-flags">
<title>Changes</title>
<table pgwide="1" frame="none" id="ctrl-changes-flags">
<title>Control Changes</title>
<tgroup cols="3">
&cs-def;
<tbody valign="top">
@@ -318,9 +428,9 @@
<entry><constant>V4L2_EVENT_CTRL_CH_VALUE</constant></entry>
<entry>0x0001</entry>
<entry>This control event was triggered because the value of the control
changed. Special case: if a button control is pressed, then this
event is sent as well, even though there is not explicit value
associated with a button control.</entry>
changed. Special cases: Volatile controls do no generate this event;
If a control has the <constant>V4L2_CTRL_FLAG_EXECUTE_ON_WRITE</constant>
flag set, then this event is sent as well, regardless its value.</entry>
</row>
<row>
<entry><constant>V4L2_EVENT_CTRL_CH_FLAGS</constant></entry>

10
Documentation/DocBook/media/v4l/vidioc-encoder-cmd.xml
View File

@@ -129,7 +129,15 @@ this command.</entry>
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>
nothing. mem2mem encoders will send a <constant>V4L2_EVENT_EOS</constant> event
when the last frame has been decoded and all frames are ready to be dequeued and
will set the <constant>V4L2_BUF_FLAG_LAST</constant> buffer flag on the last
buffer of the capture queue to indicate there will be no new buffers produced to
dequeue. This buffer may be empty, indicated by the driver setting the
<structfield>bytesused</structfield> field to 0. Once the
<constant>V4L2_BUF_FLAG_LAST</constant> flag was set, the
<link linkend="vidioc-qbuf">VIDIOC_DQBUF</link> ioctl will not block anymore,
but return an &EPIPE;.</entry>
</row>
<row>
<entry><constant>V4L2_ENC_CMD_PAUSE</constant></entry>

3
Documentation/DocBook/media/v4l/vidioc-enum-frameintervals.xml
View File

@@ -217,7 +217,8 @@ enumerated.</entry>
<entry>__u32</entry>
<entry><structfield>reserved[2]</structfield></entry>
<entry></entry>
<entry>Reserved space for future use.</entry>
<entry>Reserved space for future use. Must be zeroed by drivers and
applications.</entry>
</row>
</tbody>
</tgroup>

3
Documentation/DocBook/media/v4l/vidioc-enum-framesizes.xml
View File

@@ -223,7 +223,8 @@ application should zero out all members except for the
<entry>__u32</entry>
<entry><structfield>reserved[2]</structfield></entry>
<entry></entry>
<entry>Reserved space for future use.</entry>
<entry>Reserved space for future use. Must be zeroed by drivers and
applications.</entry>
</row>
</tbody>
</tgroup>

3
Documentation/DocBook/media/v4l/vidioc-expbuf.xml
View File

@@ -184,7 +184,8 @@ of open() for more details.</entry>
<row>
<entry>__u32</entry>
<entry><structfield>reserved[11]</structfield></entry>
<entry>Reserved field for future use. Must be set to zero.</entry>
<entry>Reserved field for future use. Drivers and applications must
set the array to zero.</entry>
</row>
</tbody>
</tgroup>

5
Documentation/DocBook/media/v4l/vidioc-g-crop.xml
View File

@@ -70,6 +70,11 @@ structure or returns the &EINVAL; if cropping is not supported.</para>
<constant>VIDIOC_S_CROP</constant> ioctl with a pointer to this
structure.</para>
<para>Do not use the multiplanar buffer types. Use <constant>V4L2_BUF_TYPE_VIDEO_CAPTURE</constant>
instead of <constant>V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE</constant>
and use <constant>V4L2_BUF_TYPE_VIDEO_OUTPUT</constant> instead of
<constant>V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE</constant>.</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

22
Documentation/DocBook/media/v4l/vidioc-g-dv-timings.xml
View File

@@ -7,6 +7,8 @@
<refnamediv>
<refname>VIDIOC_G_DV_TIMINGS</refname>
<refname>VIDIOC_S_DV_TIMINGS</refname>
<refname>VIDIOC_SUBDEV_G_DV_TIMINGS</refname>
<refname>VIDIOC_SUBDEV_S_DV_TIMINGS</refname>
<refpurpose>Get or set DV timings for input or output</refpurpose>
</refnamediv>
@@ -34,7 +36,7 @@
<varlistentry>
<term><parameter>request</parameter></term>
<listitem>
<para>VIDIOC_G_DV_TIMINGS, VIDIOC_S_DV_TIMINGS</para>
<para>VIDIOC_G_DV_TIMINGS, VIDIOC_S_DV_TIMINGS, VIDIOC_SUBDEV_G_DV_TIMINGS, VIDIOC_SUBDEV_S_DV_TIMINGS</para>
</listitem>
</varlistentry>
<varlistentry>
@@ -318,10 +320,20 @@ can't generate such frequencies, then the flag will also be cleared.
</row>
<row>
<entry>V4L2_DV_FL_HALF_LINE</entry>
<entry>Specific to interlaced formats: if set, then field 1 (aka the odd field)
is really one half-line longer and field 2 (aka the even field) is really one half-line
shorter, so each field has exactly the same number of half-lines. Whether half-lines can be
detected or used depends on the hardware.
<entry>Specific to interlaced formats: if set, then the vertical frontporch
of field 1 (aka the odd field) is really one half-line longer and the vertical backporch
of field 2 (aka the even field) is really one half-line shorter, so each field has exactly
the same number of half-lines. Whether half-lines can be detected or used depends on
the hardware.
</entry>
</row>
<row>
<entry>V4L2_DV_FL_IS_CE_VIDEO</entry>
<entry>If set, then this is a Consumer Electronics (CE) video format.
Such formats differ from other formats (commonly called IT formats) in that if
R'G'B' encoding is used then by default the R'G'B' values use limited range
(i.e. 16-235) as opposed to full range (i.e. 0-255). All formats defined in CEA-861
except for the 640x480p59.94 format are CE formats.
</entry>
</row>
</tbody>

11
Documentation/DocBook/media/v4l/vidioc-g-edid.xml
View File

@@ -7,6 +7,8 @@
<refnamediv>
<refname>VIDIOC_G_EDID</refname>
<refname>VIDIOC_S_EDID</refname>
<refname>VIDIOC_SUBDEV_G_EDID</refname>
<refname>VIDIOC_SUBDEV_S_EDID</refname>
<refpurpose>Get or set the EDID of a video receiver/transmitter</refpurpose>
</refnamediv>
@@ -42,7 +44,7 @@
<varlistentry>
<term><parameter>request</parameter></term>
<listitem>
<para>VIDIOC_G_EDID, VIDIOC_S_EDID</para>
<para>VIDIOC_G_EDID, VIDIOC_S_EDID, VIDIOC_SUBDEV_G_EDID, VIDIOC_SUBDEV_S_EDID</para>
</listitem>
</varlistentry>
<varlistentry>
@@ -82,6 +84,13 @@
<para>If blocks have to be retrieved from the sink, then this call will block until they
have been read.</para>
<para>If <structfield>start_block</structfield> and <structfield>blocks</structfield> are
both set to 0 when <constant>VIDIOC_G_EDID</constant> is called, then the driver will
set <structfield>blocks</structfield> to the total number of available EDID blocks
and it will return 0 without copying any data. This is an easy way to discover how many
EDID blocks there are. Note that if there are no EDID blocks available at all, then
the driver will set <structfield>blocks</structfield> to 0 and it returns 0.</para>
<para>To set the EDID blocks of a receiver the application has to fill in the <structfield>pad</structfield>,
<structfield>blocks</structfield> and <structfield>edid</structfield> fields and set
<structfield>start_block</structfield> to 0. It is not possible to set part of an EDID,

Some files were not shown because too many files have changed in this diff Show More