joel16/android_kernel_sony_msm8994_rework
1
0
Fork 0
mirror of https://github.com/joel16/android_kernel_sony_msm8994_rework.git synced 2024-11-30 23:30:48 +00:00
Code Issues Actions Packages Projects Releases Wiki Activity

ASoC: Additional updates for 3.6

Browse Source 
A batch more bugfixes, all driver-specific and fairly small and
 unremarkable in a global context.  The biggest batch are for the newly
 added Arizona drivers.
 -----BEGIN PGP SIGNATURE-----
 Version: GnuPG v1.4.12 (GNU/Linux)
 
 iQIcBAABAgAGBQJQLsRjAAoJEFJkBDiqVpZ4HI0QALREeI4Hq7xGxOEPsY9QV+Eh
 0zs+Q2KnlGKlm87cm3PfsIpI+atf8WGVAO5/nTk7TPewvPbkvJp8p6zgzaMwvq1r
 5TqTdwTOwg0UuoiFakmET6x7mHmYvks0U1uAm5VwPzdNbahvHLArCsRgufXtNsEz
 4M9FmLL/+e9r/n3EKXMoNYab4krvmyVft5QCUxFkHgfcbfv95KIn9So54T5H/jG9
 fzhmKjMMGUja7Q7nLtpr6OHkJLZd1iPTu8xdjsQB7htNW7P8KPaseVt0oAUXNkXS
 K0WhTjqtQbDtm9KfrifY0vpdWNLbTi1R+vnm6FwQiDN0fZ1Tm18992veNZfaOAUE
 QWlGzt5Av2sCGwNXA55SF0cLo1lbxD1kwGN9o45zztGw0wW5qjkH9VF92XkpqISh
 zdE+bQoQk7I9UBtwql/YtY17QLn3KUBoDlHDaOQqrmQYXW69J8RnnjUMskoO/2Tu
 LTMPWLPnudVXIcfW+C/j1GSBN0l0q3FHGBYVfoCWwXShwjIr3Fzg8hhtHwL056/J
 YhEykqucR4iDJaOpjSxKiiKWjFfMQBkzipuTL6p/vqQJ3fPTp9LjQTABUnzsGqYQ
 mIx9W3BqZ1q/LiZYPYEExiIChdlE3g6+aFZfukk0sQQ0/dpipC/0qXRWMb8Kks6W
 18HFsHL5jX5s5e8qG5ac
 =X06H
 -----END PGP SIGNATURE-----

Merge tag 'asoc-3.6' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound into for-linus

ASoC: Additional updates for 3.6

A batch more bugfixes, all driver-specific and fairly small and
unremarkable in a global context.  The biggest batch are for the newly
added Arizona drivers.
This commit is contained in:
Takashi Iwai 2012-08-20 21:26:04 +02:00
commit f0b433e9f3
7553 changed files with 445490 additions and 194799 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

5
Documentation/ABI/obsolete/proc-sys-vm-nr_pdflush_threads Normal file
View File

@ -0,0 +1,5 @@
What: /proc/sys/vm/nr_pdflush_threads
Date: June 2012
Contact: Wanpeng Li <liwp@linux.vnet.ibm.com>
Description: Since pdflush is replaced by per-BDI flusher, the interface of old pdflush
exported in /proc/sys/vm/ should be removed.

11
Documentation/ABI/stable/sysfs-bus-firewire
View File

@ -39,6 +39,17 @@ Users: udev rules to set ownership and access permissions or ACLs of
/dev/fw[0-9]+ character device files
What: /sys/bus/firewire/devices/fw[0-9]+/is_local
Date: July 2012
KernelVersion: 3.6
Contact: linux1394-devel@lists.sourceforge.net
Description:
IEEE 1394 node device attribute.
Read-only and immutable.
Values: 1: The sysfs entry represents a local node (a controller card).
0: The sysfs entry represents a remote node.
What: /sys/bus/firewire/devices/fw[0-9]+[.][0-9]+/
Date: May 2007
KernelVersion: 2.6.22

15
Documentation/ABI/stable/sysfs-driver-w1_ds28e04 Normal file
View File

@ -0,0 +1,15 @@
What: /sys/bus/w1/devices/.../pio
Date: May 2012
Contact: Markus Franke <franm@hrz.tu-chemnitz.de>
Description: read/write the contents of the two PIO's of the DS28E04-100
see Documentation/w1/slaves/w1_ds28e04 for detailed information
Users: any user space application which wants to communicate with DS28E04-100
What: /sys/bus/w1/devices/.../eeprom
Date: May 2012
Contact: Markus Franke <franm@hrz.tu-chemnitz.de>
Description: read/write the contents of the EEPROM memory of the DS28E04-100
see Documentation/w1/slaves/w1_ds28e04 for detailed information
Users: any user space application which wants to communicate with DS28E04-100

2
Documentation/ABI/stable/vdso
View File

@ -24,4 +24,4 @@ though.
(As of this writing, this ABI documentation as been confirmed for x86_64.
The maintainers of the other vDSO-using architectures should confirm
that it is correct for their architecture.)
that it is correct for their architecture.)

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

@ -58,16 +58,18 @@ Description: The /dev/kmsg character device node provides userspace access
The output format consists of a prefix carrying the syslog
prefix including priority and facility, the 64 bit message
sequence number and the monotonic timestamp in microseconds.
The values are separated by a ','. Future extensions might
add more comma separated values before the terminating ';'.
Unknown values should be gracefully ignored.
sequence number and the monotonic timestamp in microseconds,
and a flag field. All fields are separated by a ','.
Future extensions might add more comma separated values before
the terminating ';'. Unknown fields and values should be
gracefully ignored.
The human readable text string starts directly after the ';'
and is terminated by a '\n'. Untrusted values derived from
hardware or other facilities are printed, therefore
all non-printable characters in the log message are escaped
by "\x00" C-style hex encoding.
all non-printable characters and '\' itself in the log message
are escaped by "\x00" C-style hex encoding.
A line starting with ' ', is a continuation line, adding
key/value pairs to the log message, which provide the machine
@ -75,11 +77,11 @@ Description: The /dev/kmsg character device node provides userspace access
userspace.
Example:
7,160,424069;pci_root PNP0A03:00: host bridge window [io 0x0000-0x0cf7] (ignored)
7,160,424069,-;pci_root PNP0A03:00: host bridge window [io 0x0000-0x0cf7] (ignored)
SUBSYSTEM=acpi
DEVICE=+acpi:PNP0A03:00
6,339,5140900;NET: Registered protocol family 10
30,340,5690716;udevd[80]: starting version 181
6,339,5140900,-;NET: Registered protocol family 10
30,340,5690716,-;udevd[80]: starting version 181
The DEVICE= key uniquely identifies devices the following way:
b12:8 - block dev_t
@ -87,4 +89,13 @@ Description: The /dev/kmsg character device node provides userspace access
n8 - netdev ifindex
+sound:card0 - subsystem:devname
The flags field carries '-' by default. A 'c' indicates a
fragment of a line. All following fragments are flagged with
'+'. Note, that these hints about continuation lines are not
neccessarily correct, and the stream could be interleaved with
unrelated messages, but merging the lines in the output
usually produces better human readable results. A similar
logic is used internally when messages are printed to the
console, /proc/kmsg or the syslog() syscall.
Users: dmesg(1), userspace kernel log consumers

21
Documentation/ABI/testing/sysfs-block-rssd
View File

@ -1,26 +1,5 @@
What: /sys/block/rssd*/registers
Date: March 2012
KernelVersion: 3.3
Contact: Asai Thambi S P <asamymuthupa@micron.com>
Description: This is a read-only file. Dumps below driver information and
hardware registers.
- S ACTive
- Command Issue
- Completed
- PORT IRQ STAT
- HOST IRQ STAT
- Allocated
- Commands in Q
What: /sys/block/rssd*/status
Date: April 2012
KernelVersion: 3.4
Contact: Asai Thambi S P <asamymuthupa@micron.com>
Description: This is a read-only file. Indicates the status of the device.
What: /sys/block/rssd*/flags
Date: May 2012
KernelVersion: 3.5
Contact: Asai Thambi S P <asamymuthupa@micron.com>
Description: This is a read-only file. Dumps the flags in port and driver
data structure

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

@ -96,4 +96,4 @@ Description:
overhead, allocated for this disk. So, allocator space
efficiency can be calculated using compr_data_size and this
statistic.
Unit: bytes
Unit: bytes

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

@ -40,9 +40,9 @@ Contact: linux-iio@vger.kernel.org
Description:
Some devices have internal clocks. This parameter sets the
resulting sampling frequency. In many devices this
parameter has an effect on input filters etc rather than
parameter has an effect on input filters etc. rather than
simply controlling when the input is sampled. As this
effects datardy triggers, hardware buffers and the sysfs
effects data ready triggers, hardware buffers and the sysfs
direct access interfaces, it may be found in any of the
relevant directories. If it effects all of the above
then it is to be found in the base device directory.
@ -74,7 +74,7 @@ What: /sys/bus/iio/devices/iio:deviceX/in_voltageY_supply_raw
KernelVersion: 2.6.35
Contact: linux-iio@vger.kernel.org
Description:
Raw (unscaled no bias removal etc) voltage measurement from
Raw (unscaled no bias removal etc.) voltage measurement from
channel Y. In special cases where the channel does not
correspond to externally available input one of the named
versions may be used. The number must always be specified and
@ -118,11 +118,11 @@ What: /sys/bus/iio/devices/iio:deviceX/in_temp_z_raw
KernelVersion: 2.6.35
Contact: linux-iio@vger.kernel.org
Description:
Raw (unscaled no bias removal etc) temperature measurement.
Raw (unscaled no bias removal etc.) temperature measurement.
If an axis is specified it generally means that the temperature
sensor is associated with one part of a compound device (e.g.
a gyroscope axis). Units after application of scale and offset
are milli degrees Celsuis.
are milli degrees Celsius.
What: /sys/bus/iio/devices/iio:deviceX/in_tempX_input
KernelVersion: 2.6.38
@ -148,10 +148,9 @@ KernelVersion: 2.6.35
Contact: linux-iio@vger.kernel.org
Description:
Angular velocity about axis x, y or z (may be arbitrarily
assigned) Data converted by application of offset then scale to
radians per second. Has all the equivalent parameters as
per voltageY. Units after application of scale and offset are
radians per second.
assigned). Has all the equivalent parameters as per voltageY.
Units after application of scale and offset are radians per
second.
What: /sys/bus/iio/devices/iio:deviceX/in_incli_x_raw
What: /sys/bus/iio/devices/iio:deviceX/in_incli_y_raw
@ -161,7 +160,7 @@ Contact: linux-iio@vger.kernel.org
Description:
Inclination raw reading about axis x, y or z (may be
arbitrarily assigned). Data converted by application of offset
and scale to Degrees.
and scale to degrees.
What: /sys/bus/iio/devices/iio:deviceX/in_magn_x_raw
What: /sys/bus/iio/devices/iio:deviceX/in_magn_y_raw
@ -203,7 +202,7 @@ Contact: linux-iio@vger.kernel.org
Description:
If known for a device, offset to be added to <type>[Y]_raw prior
to scaling by <type>[Y]_scale in order to obtain value in the
<type> units as specified in <type>[y]_raw documentation.
<type> units as specified in <type>[Y]_raw documentation.
Not present if the offset is always 0 or unknown. If Y or
axis <x|y|z> is not present, then the offset applies to all
in channels of <type>.
@ -249,7 +248,7 @@ What: /sys/bus/iio/devices/iio:deviceX/in_proximity0_calibbias
KernelVersion: 2.6.35
Contact: linux-iio@vger.kernel.org
Description:
Hardware applied calibration offset. (assumed to fix production
Hardware applied calibration offset (assumed to fix production
inaccuracies).
What /sys/bus/iio/devices/iio:deviceX/in_voltageY_calibscale
@ -266,7 +265,7 @@ what /sys/bus/iio/devices/iio:deviceX/in_proximity0_calibscale
KernelVersion: 2.6.35
Contact: linux-iio@vger.kernel.org
Description:
Hardware applied calibration scale factor. (assumed to fix
Hardware applied calibration scale factor (assumed to fix
production inaccuracies). If shared across all channels,
<type>_calibscale is used.
@ -276,10 +275,10 @@ What: /sys/.../iio:deviceX/in_voltage-voltage_scale_available
What: /sys/.../iio:deviceX/out_voltageX_scale_available
What: /sys/.../iio:deviceX/out_altvoltageX_scale_available
What: /sys/.../iio:deviceX/in_capacitance_scale_available
KernelVersion: 2.635
KernelVersion: 2.6.35
Contact: linux-iio@vger.kernel.org
Description:
If a discrete set of scale values are available, they
If a discrete set of scale values is available, they
are listed in this attribute.
What /sys/bus/iio/devices/iio:deviceX/out_voltageY_hardwaregain
@ -330,9 +329,11 @@ Contact: linux-iio@vger.kernel.org
Description:
Specifies the output powerdown mode.
DAC output stage is disconnected from the amplifier and
1kohm_to_gnd: connected to ground via an 1kOhm resistor
100kohm_to_gnd: connected to ground via an 100kOhm resistor
three_state: left floating
1kohm_to_gnd: connected to ground via an 1kOhm resistor,
6kohm_to_gnd: connected to ground via a 6kOhm resistor,
20kohm_to_gnd: connected to ground via a 20kOhm resistor,
100kohm_to_gnd: connected to ground via an 100kOhm resistor,
three_state: left floating.
For a list of available output power down options read
outX_powerdown_mode_available. If Y is not present the
mode is shared across all outputs.
@ -355,9 +356,10 @@ KernelVersion: 2.6.38
Contact: linux-iio@vger.kernel.org
Description:
Writing 1 causes output Y to enter the power down mode specified
by the corresponding outY_powerdown_mode. Clearing returns to
normal operation. Y may be suppressed if all outputs are
controlled together.
by the corresponding outY_powerdown_mode. DAC output stage is
disconnected from the amplifier. Clearing returns to normal
operation. Y may be suppressed if all outputs are controlled
together.
What: /sys/bus/iio/devices/iio:deviceX/out_altvoltageY_frequency
KernelVersion: 3.4.0
@ -421,12 +423,12 @@ Description:
different values, but the device can only enable both thresholds
or neither.
Note the driver will assume the last p events requested are
to be enabled where p is however many it supports (which may
vary depending on the exact set requested. So if you want to be
to be enabled where p is how many it supports (which may vary
depending on the exact set requested. So if you want to be
sure you have set what you think you have, check the contents of
these attributes after everything is configured. Drivers may
have to buffer any parameters so that they are consistent when
a given event type is enabled a future point (and not those for
a given event type is enabled at a future point (and not those for
whatever event was previously enabled).
What: /sys/.../iio:deviceX/events/in_accel_x_roc_rising_en
@ -702,7 +704,7 @@ What: /sys/.../buffer/scan_elements/in_anglvel_type
What: /sys/.../buffer/scan_elements/in_magn_type
What: /sys/.../buffer/scan_elements/in_incli_type
What: /sys/.../buffer/scan_elements/in_voltageY_type
What: /sys/.../buffer/scan_elements/in_voltage-in_type
What: /sys/.../buffer/scan_elements/in_voltage_type
What: /sys/.../buffer/scan_elements/in_voltageY_supply_type
What: /sys/.../buffer/scan_elements/in_timestamp_type
KernelVersion: 2.6.37
@ -723,7 +725,7 @@ Description:
the buffer output value appropriately. The storagebits value
also specifies the data alignment. So s48/64>>2 will be a
signed 48 bit integer stored in a 64 bit location aligned to
a a64 bit boundary. To obtain the clean value, shift right 2
a 64 bit boundary. To obtain the clean value, shift right 2
and apply a mask to zero the top 16 bits of the result.
For other storage combinations this attribute will be extended
appropriately.

37
Documentation/ABI/testing/sysfs-bus-iio-frequency-ad9523 Normal file
View File

@ -0,0 +1,37 @@
What: /sys/bus/iio/devices/iio:deviceX/pll2_feedback_clk_present
What: /sys/bus/iio/devices/iio:deviceX/pll2_reference_clk_present
What: /sys/bus/iio/devices/iio:deviceX/pll1_reference_clk_a_present
What: /sys/bus/iio/devices/iio:deviceX/pll1_reference_clk_b_present
What: /sys/bus/iio/devices/iio:deviceX/pll1_reference_clk_test_present
What: /sys/bus/iio/devices/iio:deviceX/vcxo_clk_present
KernelVersion: 3.4.0
Contact: linux-iio@vger.kernel.org
Description:
Reading returns either '1' or '0'.
'1' means that the clock in question is present.
'0' means that the clock is missing.
What: /sys/bus/iio/devices/iio:deviceX/pllY_locked
KernelVersion: 3.4.0
Contact: linux-iio@vger.kernel.org
Description:
Reading returns either '1' or '0'. '1' means that the
pllY is locked.
What: /sys/bus/iio/devices/iio:deviceX/store_eeprom
KernelVersion: 3.4.0
Contact: linux-iio@vger.kernel.org
Description:
Writing '1' stores the current device configuration into
on-chip EEPROM. After power-up or chip reset the device will
automatically load the saved configuration.
What: /sys/bus/iio/devices/iio:deviceX/sync_dividers
KernelVersion: 3.4.0
Contact: linux-iio@vger.kernel.org
Description:
Writing '1' triggers the clock distribution synchronization
functionality. All dividers are reset and the channels start
with their predefined phase offsets (out_altvoltageY_phase).
Writing this file has the effect as driving the external
/SYNC pin low.

21
Documentation/ABI/testing/sysfs-bus-iio-frequency-adf4350 Normal file
View File

@ -0,0 +1,21 @@
What: /sys/bus/iio/devices/iio:deviceX/out_altvoltageY_frequency_resolution
KernelVersion: 3.4.0
Contact: linux-iio@vger.kernel.org
Description:
Stores channel Y frequency resolution/channel spacing in Hz.
The value given directly influences the MODULUS used by
the fractional-N PLL. It is assumed that the algorithm
that is used to compute the various dividers, is able to
generate proper values for multiples of channel spacing.
What: /sys/bus/iio/devices/iio:deviceX/out_altvoltageY_refin_frequency
KernelVersion: 3.4.0
Contact: linux-iio@vger.kernel.org
Description:
Sets channel Y REFin frequency in Hz. In some clock chained
applications, the reference frequency used by the PLL may
change during runtime. This attribute allows the user to
adjust the reference frequency accordingly.
The value written has no effect until out_altvoltageY_frequency
is updated. Consider to use out_altvoltageY_powerdown to power
down the PLL and it's RFOut buffers during REFin changes.

61
Documentation/ABI/testing/sysfs-bus-iio-light-lm3533-als Normal file
View File

@ -0,0 +1,61 @@
What: /sys/.../events/in_illuminance0_thresh_either_en
Date: April 2012
KernelVersion: 3.5
Contact: Johan Hovold <jhovold@gmail.com>
Description:
Event generated when channel passes one of the four thresholds
in each direction (rising|falling) and a zone change occurs.
The corresponding light zone can be read from
in_illuminance0_zone.
What: /sys/.../events/in_illuminance0_threshY_hysteresis
Date: May 2012
KernelVersion: 3.5
Contact: Johan Hovold <jhovold@gmail.com>
Description:
Get the hysteresis for thresholds Y, that is,
threshY_hysteresis = threshY_raising - threshY_falling
What: /sys/.../events/illuminance_threshY_falling_value
What: /sys/.../events/illuminance_threshY_raising_value
Date: April 2012
KernelVersion: 3.5
Contact: Johan Hovold <jhovold@gmail.com>
Description:
Specifies the value of threshold that the device is comparing
against for the events enabled by
in_illuminance0_thresh_either_en (0..255), where Y in 0..3.
Note that threshY_falling must be less than or equal to
threshY_raising.
These thresholds correspond to the eight zone-boundary
registers (boundaryY_{low,high}) and define the five light
zones.
What: /sys/bus/iio/devices/iio:deviceX/in_illuminance0_zone
Date: April 2012
KernelVersion: 3.5
Contact: Johan Hovold <jhovold@gmail.com>
Description:
Get the current light zone (0..4) as defined by the
in_illuminance0_threshY_{falling,rising} thresholds.
What: /sys/bus/iio/devices/iio:deviceX/out_currentY_raw
Date: May 2012
KernelVersion: 3.5
Contact: Johan Hovold <jhovold@gmail.com>
Description:
Get output current for channel Y (0..255), that is,
out_currentY_currentZ_raw, where Z is the current zone.
What: /sys/bus/iio/devices/iio:deviceX/out_currentY_currentZ_raw
Date: May 2012
KernelVersion: 3.5
Contact: Johan Hovold <jhovold@gmail.com>
Description:
Set the output current for channel out_currentY when in zone
Z (0..255), where Y in 0..2 and Z in 0..4.
These values correspond to the ALS-mapper target registers for
ALS-mapper Y + 1.

10
Documentation/ABI/testing/sysfs-bus-rbd
View File

@ -35,8 +35,14 @@ name
pool
The pool where this rbd image resides. The pool-name pair is unique
per rados system.
The name of the storage pool where this rbd image resides.
An rbd image name is unique within its pool.
pool_id
The unique identifier for the rbd image's pool. This is
a permanent attribute of the pool. A pool's id will never
change.
size

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

@ -208,3 +208,15 @@ Description:
such as ACPI. This file will read either "removable" or
"fixed" if the information is available, and "unknown"
otherwise.
What: /sys/bus/usb/devices/.../ltm_capable
Date: July 2012
Contact: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Description:
USB 3.0 devices may optionally support Latency Tolerance
Messaging (LTM). They indicate their support by setting a bit
in the bmAttributes field of their SuperSpeed BOS descriptors.
If that bit is set for the device, ltm_capable will read "yes".
If the device doesn't support LTM, the file will read "no".
The file will be present for all speeds of USB devices, and will
always read "no" for USB 1.1 and USB 2.0 devices.

2
Documentation/ABI/testing/sysfs-bus-usb-devices-usbsevseg
View File

@ -40,4 +40,4 @@ Description: Controls the decimal places on the device.
the value of 10 ** n. Assume this field has
the value k and has 1 or more decimal places set,
to set the mth place (where m is not already set),
change this fields value to k + 10 ** m.
change this fields value to k + 10 ** m.

2
Documentation/ABI/testing/sysfs-class-backlight-driver-adp8870
View File

@ -53,4 +53,4 @@ Description:
Documentation/ABI/stable/sysfs-class-backlight.
It can be enabled by writing the value stored in
/sys/class/backlight/<backlight>/max_brightness to
/sys/class/backlight/<backlight>/brightness.
/sys/class/backlight/<backlight>/brightness.

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

@ -142,13 +142,14 @@ KernelVersion: 3.4
Contact: linux-mtd@lists.infradead.org
Description:
This allows the user to examine and adjust the criteria by which
mtd returns -EUCLEAN from mtd_read(). If the maximum number of
bit errors that were corrected on any single region comprising
an ecc step (as reported by the driver) equals or exceeds this
value, -EUCLEAN is returned. Otherwise, absent an error, 0 is
returned. Higher layers (e.g., UBI) use this return code as an
indication that an erase block may be degrading and should be
scrutinized as a candidate for being marked as bad.
mtd returns -EUCLEAN from mtd_read() and mtd_read_oob(). If the
maximum number of bit errors that were corrected on any single
region comprising an ecc step (as reported by the driver) equals
or exceeds this value, -EUCLEAN is returned. Otherwise, absent
an error, 0 is returned. Higher layers (e.g., UBI) use this
return code as an indication that an erase block may be
degrading and should be scrutinized as a candidate for being
marked as bad.
The initial value may be specified by the flash device driver.
If not, then the default value is ecc_strength.
@ -167,7 +168,7 @@ Description:
block degradation, but high enough to avoid the consequences of
a persistent return value of -EUCLEAN on devices where sticky
bitflips occur. Note that if bitflip_threshold exceeds
ecc_strength, -EUCLEAN is never returned by mtd_read().
ecc_strength, -EUCLEAN is never returned by the read operations.
Conversely, if bitflip_threshold is zero, -EUCLEAN is always
returned, absent a hard error.

140
Documentation/ABI/testing/sysfs-devices-edac Normal file
View File

@ -0,0 +1,140 @@
What: /sys/devices/system/edac/mc/mc*/reset_counters
Date: January 2006
Contact: linux-edac@vger.kernel.org
Description: This write-only control file will zero all the statistical
counters for UE and CE errors on the given memory controller.
Zeroing the counters will also reset the timer indicating how
long since the last counter were reset. This is useful for
computing errors/time. Since the counters are always reset
at driver initialization time, no module/kernel parameter
is available.
What: /sys/devices/system/edac/mc/mc*/seconds_since_reset
Date: January 2006
Contact: linux-edac@vger.kernel.org
Description: This attribute file displays how many seconds have elapsed
since the last counter reset. This can be used with the error
counters to measure error rates.
What: /sys/devices/system/edac/mc/mc*/mc_name
Date: January 2006
Contact: linux-edac@vger.kernel.org
Description: This attribute file displays the type of memory controller
that is being utilized.
What: /sys/devices/system/edac/mc/mc*/size_mb
Date: January 2006
Contact: linux-edac@vger.kernel.org
Description: This attribute file displays, in count of megabytes, of memory
that this memory controller manages.
What: /sys/devices/system/edac/mc/mc*/ue_count
Date: January 2006
Contact: linux-edac@vger.kernel.org
Description: This attribute file displays the total count of uncorrectable
errors that have occurred on this memory controller. If
panic_on_ue is set, this counter will not have a chance to
increment, since EDAC will panic the system
What: /sys/devices/system/edac/mc/mc*/ue_noinfo_count
Date: January 2006
Contact: linux-edac@vger.kernel.org
Description: This attribute file displays the number of UEs that have
occurred on this memory controller with no information as to
which DIMM slot is having errors.
What: /sys/devices/system/edac/mc/mc*/ce_count
Date: January 2006
Contact: linux-edac@vger.kernel.org
Description: This attribute file displays the total count of correctable
errors that have occurred on this memory controller. This
count is very important to examine. CEs provide early
indications that a DIMM is beginning to fail. This count
field should be monitored for non-zero values and report
such information to the system administrator.
What: /sys/devices/system/edac/mc/mc*/ce_noinfo_count
Date: January 2006
Contact: linux-edac@vger.kernel.org
Description: This attribute file displays the number of CEs that
have occurred on this memory controller wherewith no
information as to which DIMM slot is having errors. Memory is
handicapped, but operational, yet no information is available
to indicate which slot the failing memory is in. This count
field should be also be monitored for non-zero values.
What: /sys/devices/system/edac/mc/mc*/sdram_scrub_rate
Date: February 2007
Contact: linux-edac@vger.kernel.org
Description: Read/Write attribute file that controls memory scrubbing.
The scrubbing rate used by the memory controller is set by
writing a minimum bandwidth in bytes/sec to the attribute file.
The rate will be translated to an internal value that gives at
least the specified rate.
Reading the file will return the actual scrubbing rate employed.
If configuration fails or memory scrubbing is not implemented,
the value of the attribute file will be -1.
What: /sys/devices/system/edac/mc/mc*/max_location
Date: April 2012
Contact: Mauro Carvalho Chehab <mchehab@redhat.com>
linux-edac@vger.kernel.org
Description: This attribute file displays the information about the last
available memory slot in this memory controller. It is used by
userspace tools in order to display the memory filling layout.
What: /sys/devices/system/edac/mc/mc*/(dimm|rank)*/size
Date: April 2012
Contact: Mauro Carvalho Chehab <mchehab@redhat.com>
linux-edac@vger.kernel.org
Description: This attribute file will display the size of dimm or rank.
For dimm*/size, this is the size, in MB of the DIMM memory
stick. For rank*/size, this is the size, in MB for one rank
of the DIMM memory stick. On single rank memories (1R), this
is also the total size of the dimm. On dual rank (2R) memories,
this is half the size of the total DIMM memories.
What: /sys/devices/system/edac/mc/mc*/(dimm|rank)*/dimm_dev_type
Date: April 2012
Contact: Mauro Carvalho Chehab <mchehab@redhat.com>
linux-edac@vger.kernel.org
Description: This attribute file will display what type of DRAM device is
being utilized on this DIMM (x1, x2, x4, x8, ...).
What: /sys/devices/system/edac/mc/mc*/(dimm|rank)*/dimm_edac_mode
Date: April 2012
Contact: Mauro Carvalho Chehab <mchehab@redhat.com>
linux-edac@vger.kernel.org
Description: This attribute file will display what type of Error detection
and correction is being utilized. For example: S4ECD4ED would
mean a Chipkill with x4 DRAM.
What: /sys/devices/system/edac/mc/mc*/(dimm|rank)*/dimm_label
Date: April 2012
Contact: Mauro Carvalho Chehab <mchehab@redhat.com>
linux-edac@vger.kernel.org
Description: This control file allows this DIMM to have a label assigned
to it. With this label in the module, when errors occur
the output can provide the DIMM label in the system log.
This becomes vital for panic events to isolate the
cause of the UE event.
DIMM Labels must be assigned after booting, with information
that correctly identifies the physical slot with its
silk screen label. This information is currently very
motherboard specific and determination of this information
must occur in userland at this time.
What: /sys/devices/system/edac/mc/mc*/(dimm|rank)*/dimm_location
Date: April 2012
Contact: Mauro Carvalho Chehab <mchehab@redhat.com>
linux-edac@vger.kernel.org
Description: This attribute file will display the location (csrow/channel,
branch/channel/slot or channel/slot) of the dimm or rank.
What: /sys/devices/system/edac/mc/mc*/(dimm|rank)*/dimm_mem_type
Date: April 2012
Contact: Mauro Carvalho Chehab <mchehab@redhat.com>
linux-edac@vger.kernel.org
Description: This attribute file will display what type of memory is
currently on this csrow. Normally, either buffered or
unbuffered memory (for example, Unbuffered-DDR3).

44
Documentation/ABI/testing/sysfs-devices-platform-sh_mobile_lcdc_fb Normal file
View File

@ -0,0 +1,44 @@
What: /sys/devices/platform/sh_mobile_lcdc_fb.[0-3]/graphics/fb[0-9]/ovl_alpha
Date: May 2012
Contact: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Description:
This file is only available on fb[0-9] devices corresponding
to overlay planes.
Stores the alpha blending value for the overlay. Values range
from 0 (transparent) to 255 (opaque). The value is ignored if
the mode is not set to Alpha Blending.
What: /sys/devices/platform/sh_mobile_lcdc_fb.[0-3]/graphics/fb[0-9]/ovl_mode
Date: May 2012
Contact: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Description:
This file is only available on fb[0-9] devices corresponding
to overlay planes.
Selects the composition mode for the overlay. Possible values
are
0 - Alpha Blending
1 - ROP3
What: /sys/devices/platform/sh_mobile_lcdc_fb.[0-3]/graphics/fb[0-9]/ovl_position
Date: May 2012
Contact: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Description:
This file is only available on fb[0-9] devices corresponding
to overlay planes.
Stores the x,y overlay position on the display in pixels. The
position format is `[0-9]+,[0-9]+'.
What: /sys/devices/platform/sh_mobile_lcdc_fb.[0-3]/graphics/fb[0-9]/ovl_rop3
Date: May 2012
Contact: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Description:
This file is only available on fb[0-9] devices corresponding
to overlay planes.
Stores the raster operation (ROP3) for the overlay. Values
range from 0 to 255. The value is ignored if the mode is not
set to ROP3.

20
Documentation/ABI/testing/sysfs-devices-system-xen_cpu Normal file
View File

@ -0,0 +1,20 @@
What: /sys/devices/system/xen_cpu/
Date: May 2012
Contact: Liu, Jinsong <jinsong.liu@intel.com>
Description:
A collection of global/individual Xen physical cpu attributes
Individual physical cpu attributes are contained in
subdirectories named by the Xen's logical cpu number, e.g.:
/sys/devices/system/xen_cpu/xen_cpu#/
What: /sys/devices/system/xen_cpu/xen_cpu#/online
Date: May 2012
Contact: Liu, Jinsong <jinsong.liu@intel.com>
Description:
Interface to online/offline Xen physical cpus
When running under Xen platform, it provide user interface
to online/offline physical cpus, except cpu0 due to several
logic restrictions and assumptions.

38
Documentation/ABI/testing/sysfs-driver-hid-lenovo-tpkbd Normal file
View File

@ -0,0 +1,38 @@
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/press_to_select
Date: July 2011
Contact: linux-input@vger.kernel.org
Description: This controls if mouse clicks should be generated if the trackpoint is quickly pressed. How fast this press has to be
is being controlled by press_speed.
Values are 0 or 1.
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/dragging
Date: July 2011
Contact: linux-input@vger.kernel.org
Description: If this setting is enabled, it is possible to do dragging by pressing the trackpoint. This requires press_to_select to be enabled.
Values are 0 or 1.
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/release_to_select
Date: July 2011
Contact: linux-input@vger.kernel.org
Description: For details regarding this setting please refer to http://www.pc.ibm.com/ww/healthycomputing/trkpntb.html
Values are 0 or 1.
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/select_right
Date: July 2011
Contact: linux-input@vger.kernel.org
Description: This setting controls if the mouse click events generated by pressing the trackpoint (if press_to_select is enabled) generate
a left or right mouse button click.
Values are 0 or 1.
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/sensitivity
Date: July 2011
Contact: linux-input@vger.kernel.org
Description: This file contains the trackpoint sensitivity.
Values are decimal integers from 1 (lowest sensitivity) to 255 (highest sensitivity).
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/press_speed
Date: July 2011
Contact: linux-input@vger.kernel.org
Description: This setting controls how fast the trackpoint needs to be pressed to generate a mouse click if press_to_select is enabled.
Values are decimal integers from 1 (slowest) to 255 (fastest).

77
Documentation/ABI/testing/sysfs-driver-hid-roccat-savu Normal file
View File

@ -0,0 +1,77 @@
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/savu/roccatsavu<minor>/buttons
Date: Mai 2012
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
Description: The mouse can store 5 profiles which can be switched by the
press of a button. A profile is split into general settings and
button settings. buttons holds informations about button layout.
When written, this file lets one write the respective profile
buttons to the mouse. The data has to be 47 bytes long.
The mouse will reject invalid data.
Which profile to write is determined by the profile number
contained in the data.
Before reading this file, control has to be written to select
which profile to read.
Users: http://roccat.sourceforge.net
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/savu/roccatsavu<minor>/control
Date: Mai 2012
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
Description: When written, this file lets one select which data from which
profile will be read next. The data has to be 3 bytes long.
This file is writeonly.
Users: http://roccat.sourceforge.net
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/savu/roccatsavu<minor>/general
Date: Mai 2012
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
Description: The mouse can store 5 profiles which can be switched by the
press of a button. A profile is split into general settings and
button settings. profile holds informations like resolution, sensitivity
and light effects.
When written, this file lets one write the respective profile
settings back to the mouse. The data has to be 43 bytes long.
The mouse will reject invalid data.
Which profile to write is determined by the profile number
contained in the data.
This file is writeonly.
Users: http://roccat.sourceforge.net
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/savu/roccatsavu<minor>/info
Date: Mai 2012
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
Description: When read, this file returns general data like firmware version.
The data is 8 bytes long.
This file is readonly.
Users: http://roccat.sourceforge.net
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/savu/roccatsavu<minor>/macro
Date: Mai 2012
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
Description: When written, this file lets one store macros with max 500
keystrokes for a specific button for a specific profile.
Button and profile numbers are included in written data.
The data has to be 2083 bytes long.
Before reading this file, control has to be written to select
which profile and key to read.
Users: http://roccat.sourceforge.net
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/savu/roccatsavu<minor>/profile
Date: Mai 2012
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
Description: The mouse can store 5 profiles which can be switched by the
press of a button. profile holds number of actual profile.
This value is persistent, so its value determines the profile
that's active when the mouse is powered on next time.
When written, the mouse activates the set profile immediately.
The data has to be 3 bytes long.
The mouse will reject invalid data.
Users: http://roccat.sourceforge.net
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/savu/roccatsavu<minor>/sensor
Date: July 2012
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
Description: The mouse has a Avago ADNS-3090 sensor.
This file allows reading and writing of the mouse sensors registers.
The data has to be 4 bytes long.
Users: http://roccat.sourceforge.net

14
Documentation/ABI/testing/sysfs-kernel-iommu_groups Normal file
View File

@ -0,0 +1,14 @@
What: /sys/kernel/iommu_groups/
Date: May 2012
KernelVersion: v3.5
Contact: Alex Williamson <alex.williamson@redhat.com>
Description: /sys/kernel/iommu_groups/ contains a number of sub-
directories, each representing an IOMMU group. The
name of the sub-directory matches the iommu_group_id()
for the group, which is an integer value. Within each
subdirectory is another directory named "devices" with
links to the sysfs devices contained in this group.
The group directory also optionally contains a "name"
file if the IOMMU driver has chosen to register a more
common name for the group.
Users:

7
Documentation/ABI/testing/sysfs-platform-asus-wmi
View File

@ -29,3 +29,10 @@ KernelVersion: 2.6.39
Contact: "Corentin Chary" <corentincj@iksaif.net>
Description:
Control the card touchpad. 1 means on, 0 means off.
What: /sys/devices/platform/<platform>/lid_resume
Date: May 2012
KernelVersion: 3.5
Contact: "AceLan Kao" <acelan.kao@canonical.com>
Description:
Resume on lid open. 1 means on, 0 means off.

13
Documentation/ABI/testing/sysfs-power
View File

@ -231,3 +231,16 @@ Description:
Reads from this file return a string consisting of the names of
wakeup sources created with the help of /sys/power/wake_lock
that are inactive at the moment, separated with spaces.
What: /sys/power/pm_print_times
Date: May 2012
Contact: Sameer Nanda <snanda@chromium.org>
Description:
The /sys/power/pm_print_times file allows user space to
control whether the time taken by devices to suspend and
resume is printed. These prints are useful for hunting down
devices that take too long to suspend or resume.
Writing a "1" enables this printing while writing a "0"
disables it. The default value is "0". Reading from this file
will display the current value.

42
Documentation/DMA-attributes.txt
View File

@ -49,3 +49,45 @@ DMA_ATTR_NON_CONSISTENT lets the platform to choose to return either
consistent or non-consistent memory as it sees fit. By using this API,
you are guaranteeing to the platform that you have all the correct and
necessary sync points for this memory in the driver.
DMA_ATTR_NO_KERNEL_MAPPING
--------------------------
DMA_ATTR_NO_KERNEL_MAPPING lets the platform to avoid creating a kernel
virtual mapping for the allocated buffer. On some architectures creating
such mapping is non-trivial task and consumes very limited resources
(like kernel virtual address space or dma consistent address space).
Buffers allocated with this attribute can be only passed to user space
by calling dma_mmap_attrs(). By using this API, you are guaranteeing
that you won't dereference the pointer returned by dma_alloc_attr(). You
can threat it as a cookie that must be passed to dma_mmap_attrs() and
dma_free_attrs(). Make sure that both of these also get this attribute
set on each call.
Since it is optional for platforms to implement
DMA_ATTR_NO_KERNEL_MAPPING, those that do not will simply ignore the
attribute and exhibit default behavior.
DMA_ATTR_SKIP_CPU_SYNC
----------------------
By default dma_map_{single,page,sg} functions family transfer a given
buffer from CPU domain to device domain. Some advanced use cases might
require sharing a buffer between more than one device. This requires
having a mapping created separately for each device and is usually
performed by calling dma_map_{single,page,sg} function more than once
for the given buffer with device pointer to each device taking part in
the buffer sharing. The first call transfers a buffer from 'CPU' domain
to 'device' domain, what synchronizes CPU caches for the given region
(usually it means that the cache has been flushed or invalidated
depending on the dma direction). However, next calls to
dma_map_{single,page,sg}() for other devices will perform exactly the
same sychronization operation on the CPU cache. CPU cache sychronization
might be a time consuming operation, especially if the buffers are
large, so it is highly recommended to avoid it if possible.
DMA_ATTR_SKIP_CPU_SYNC allows platform code to skip synchronization of
the CPU cache for the given buffer assuming that it has been already
transferred to 'device' domain. This attribute can be also used for
dma_unmap_{single,page,sg} functions family to force buffer to stay in
device domain after releasing a mapping for it. Use this attribute with
care!

1
Documentation/DocBook/80211.tmpl
View File

@ -404,7 +404,6 @@
!Finclude/net/mac80211.h ieee80211_get_tkip_p1k
!Finclude/net/mac80211.h ieee80211_get_tkip_p1k_iv
!Finclude/net/mac80211.h ieee80211_get_tkip_p2k
!Finclude/net/mac80211.h ieee80211_key_removed
</chapter>
<chapter id="powersave">

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

@ -194,7 +194,7 @@ in the frequency range from 87,5 to 108,0 MHz</title>
<corpauthor>National Radio Systems Committee
(<ulink url="http://www.nrscstandards.org">http://www.nrscstandards.org</ulink>)</corpauthor>
</authorgroup>
<title>NTSC-4: United States RBDS Standard</title>
<title>NRSC-4: United States RBDS Standard</title>
</biblioentry>
<biblioentry id="iso12232">

17
Documentation/DocBook/media/v4l/common.xml
View File

@ -464,14 +464,14 @@ The <structfield>type</structfield> field of the respective
<structfield>tuner</structfield> field contains the index number of
the tuner.</para>
<para>Radio devices have exactly one tuner with index zero, no
<para>Radio input devices have exactly one tuner with index zero, no
video inputs.</para>
<para>To query and change tuner properties applications use the
&VIDIOC-G-TUNER; and &VIDIOC-S-TUNER; ioctl, respectively. The
&v4l2-tuner; returned by <constant>VIDIOC_G_TUNER</constant> also
contains signal status information applicable when the tuner of the
current video input, or a radio tuner is queried. Note that
current video or radio input is queried. Note that
<constant>VIDIOC_S_TUNER</constant> does not switch the current tuner,
when there is more than one at all. The tuner is solely determined by
the current video input. Drivers must support both ioctls and set the
@ -491,8 +491,17 @@ the modulator. The <structfield>type</structfield> field of the
respective &v4l2-output; returned by the &VIDIOC-ENUMOUTPUT; ioctl is
set to <constant>V4L2_OUTPUT_TYPE_MODULATOR</constant> and its
<structfield>modulator</structfield> field contains the index number
of the modulator. This specification does not define radio output
devices.</para>
of the modulator.</para>
<para>Radio output devices have exactly one modulator with index
zero, no video outputs.</para>
<para>A video or radio device cannot support both a tuner and a
modulator. Two separate device nodes will have to be used for such
hardware, one that supports the tuner functionality and one that supports
the modulator functionality. The reason is a limitation with the
&VIDIOC-S-FREQUENCY; ioctl where you cannot specify whether the frequency
is for a tuner or a modulator.</para>
<para>To query and change modulator properties applications use
the &VIDIOC-G-MODULATOR; and &VIDIOC-S-MODULATOR; ioctl. Note that

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

@ -2377,10 +2377,11 @@ that used it. It was originally scheduled for removal in 2.6.35.
<para>V4L2_CTRL_FLAG_VOLATILE was added to signal volatile controls to userspace.</para>
</listitem>
<listitem>
<para>Add selection API for extended control over cropping and
composing. Does not affect the compatibility of current drivers and
applications. See <link linkend="selection-api"> selection API </link> for
details.</para>
<para>Add selection API for extended control over cropping
and composing. Does not affect the compatibility of current
drivers and applications. See <link
linkend="selection-api"> selection API </link> for
details.</para>
</listitem>
</orderedlist>
</section>
@ -2458,6 +2459,36 @@ details.</para>
</orderedlist>
</section>
<section>
<title>V4L2 in Linux 3.6</title>
<orderedlist>
<listitem>
<para>Replaced <structfield>input</structfield> in
<structname>v4l2_buffer</structname> by
<structfield>reserved2</structfield> and removed
<constant>V4L2_BUF_FLAG_INPUT</constant>.</para>
</listitem>
</orderedlist>
</section>
<section>
<title>V4L2 in Linux 3.6</title>
<orderedlist>
<listitem>
<para>Added V4L2_CAP_VIDEO_M2M and V4L2_CAP_VIDEO_M2M_MPLANE capabilities.</para>
</listitem>
</orderedlist>
</section>
<section>
<title>V4L2 in Linux 3.6</title>
<orderedlist>
<listitem>
<para>Added support for frequency band enumerations: &VIDIOC-ENUM-FREQ-BANDS;.</para>
</listitem>
</orderedlist>
</section>
<section id="other">
<title>Relation of V4L2 to other Linux multimedia APIs</title>
@ -2587,6 +2618,9 @@ ioctls.</para>
<para><link linkend="v4l2-auto-focus-area"><constant>
V4L2_CID_AUTO_FOCUS_AREA</constant></link> control.</para>
</listitem>
<listitem>
<para>Support for frequency band enumeration: &VIDIOC-ENUM-FREQ-BANDS; ioctl.</para>
</listitem>
</itemizedlist>
</section>

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

@ -372,6 +372,11 @@ minimum value disables backlight compensation.</entry>
Cr component, bits [15:8] as Cb component and bits [31:16] must be zero.
</entry>
</row>
<row>
<entry><constant>V4L2_CID_AUTOBRIGHTNESS</constant></entry>
<entry>boolean</entry>
<entry>Enable Automatic Brightness.</entry>
</row>
<row>
<entry><constant>V4L2_CID_ROTATE</constant></entry>
<entry>integer</entry>
@ -3988,7 +3993,7 @@ interface and may change in the future.</para>
from RGB to Y'CbCr color space.
</entry>
</row>
<row id = "v4l2-jpeg-chroma-subsampling">
<row>
<entrytbl spanname="descr" cols="2">
<tbody valign="top">
<row>

36
Documentation/DocBook/media/v4l/dev-subdev.xml
View File

@ -276,7 +276,7 @@
</para>
</section>
<section>
<section id="v4l2-subdev-selections">
<title>Selections: cropping, scaling and composition</title>
<para>Many sub-devices support cropping frames on their input or output
@ -290,8 +290,8 @@
size. Both the coordinates and sizes are expressed in pixels.</para>
<para>As for pad formats, drivers store try and active
rectangles for the selection targets of ACTUAL type <xref
linkend="v4l2-subdev-selection-targets">.</xref></para>
rectangles for the selection targets <xref
linkend="v4l2-selections-common" />.</para>
<para>On sink pads, cropping is applied relative to the
current pad format. The pad format represents the image size as
@ -308,7 +308,7 @@
<para>Scaling support is optional. When supported by a subdev,
the crop rectangle on the subdev's sink pad is scaled to the
size configured using the &VIDIOC-SUBDEV-S-SELECTION; IOCTL
using <constant>V4L2_SUBDEV_SEL_COMPOSE_ACTUAL</constant>
using <constant>V4L2_SEL_TGT_COMPOSE</constant>
selection target on the same pad. If the subdev supports scaling
but not composing, the top and left values are not used and must
always be set to zero.</para>
@ -323,32 +323,32 @@
<para>The drivers should always use the closest possible
rectangle the user requests on all selection targets, unless
specifically told otherwise.
<constant>V4L2_SUBDEV_SEL_FLAG_SIZE_GE</constant> and
<constant>V4L2_SUBDEV_SEL_FLAG_SIZE_LE</constant> flags may be
<constant>V4L2_SEL_FLAG_GE</constant> and
<constant>V4L2_SEL_FLAG_LE</constant> flags may be
used to round the image size either up or down. <xref
linkend="v4l2-subdev-selection-flags"></xref></para>
linkend="v4l2-selection-flags" /></para>
</section>
<section>
<title>Types of selection targets</title>
<section>
<title>ACTUAL targets</title>
<title>Actual targets</title>
<para>ACTUAL targets reflect the actual hardware configuration
at any point of time. There is a BOUNDS target
corresponding to every ACTUAL.</para>
<para>Actual targets (without a postfix) reflect the actual
hardware configuration at any point of time. There is a BOUNDS
target corresponding to every actual target.</para>
</section>
<section>
<title>BOUNDS targets</title>
<para>BOUNDS targets is the smallest rectangle that contains
all valid ACTUAL rectangles. It may not be possible to set the
ACTUAL rectangle as large as the BOUNDS rectangle, however.
This may be because e.g. a sensor's pixel array is not
rectangular but cross-shaped or round. The maximum size may
also be smaller than the BOUNDS rectangle.</para>
<para>BOUNDS targets is the smallest rectangle that contains all
valid actual rectangles. It may not be possible to set the actual
rectangle as large as the BOUNDS rectangle, however. This may be
because e.g. a sensor's pixel array is not rectangular but
cross-shaped or round. The maximum size may also be smaller than the
BOUNDS rectangle.</para>
</section>
</section>
@ -362,7 +362,7 @@
performed by the user: the changes made will be propagated to
any subsequent stages. If this behaviour is not desired, the
user must set
<constant>V4L2_SUBDEV_SEL_FLAG_KEEP_CONFIG</constant> flag. This
<constant>V4L2_SEL_FLAG_KEEP_CONFIG</constant> flag. This
flag causes no propagation of the changes are allowed in any
circumstances. This may also cause the accessed rectangle to be
adjusted by the driver, depending on the properties of the

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

@ -683,14 +683,12 @@ memory, set by the application. See <xref linkend="userp" /> for details.
</row>
<row>
<entry>__u32</entry>
<entry><structfield>input</structfield></entry>
<entry><structfield>reserved2</structfield></entry>
<entry></entry>
<entry>Some video capture drivers support rapid and
synchronous video input changes, a function useful for example in
video surveillance applications. For this purpose applications set the
<constant>V4L2_BUF_FLAG_INPUT</constant> flag, and this field to the
number of a video input as in &v4l2-input; field
<structfield>index</structfield>.</entry>
<entry>A place holder for future extensions and custom
(driver defined) buffer types
<constant>V4L2_BUF_TYPE_PRIVATE</constant> and higher. Applications
should set this to 0.</entry>
</row>
<row>
<entry>__u32</entry>
@ -921,13 +919,6 @@ previous key frame.</entry>
<entry>The <structfield>timecode</structfield> field is valid.
Drivers set or clear this flag when the <constant>VIDIOC_DQBUF</constant>
ioctl is called.</entry>
</row>
<row>
<entry><constant>V4L2_BUF_FLAG_INPUT</constant></entry>
<entry>0x0200</entry>
<entry>The <structfield>input</structfield> field is valid.
Applications set or clear this flag before calling the
<constant>VIDIOC_QBUF</constant> ioctl.</entry>
</row>
<row>
<entry><constant>V4L2_BUF_FLAG_PREPARED</constant></entry>

34
Documentation/DocBook/media/v4l/selection-api.xml
View File

@ -53,11 +53,11 @@ cropping and composing rectangles have the same size.</para>
</mediaobject>
</figure>
For complete list of the available selection targets see table <xref
linkend="v4l2-sel-target"/>
</section>
See <xref linkend="v4l2-selection-targets" /> for more
information.
<section>
<title>Configuration</title>
@ -74,7 +74,7 @@ cropping/composing rectangles may have to be aligned, and both the source and
the sink may have arbitrary upper and lower size limits. Therefore, as usual,
drivers are expected to adjust the requested parameters and return the actual
values selected. An application can control the rounding behaviour using <link
linkend="v4l2-sel-flags"> constraint flags </link>.</para>
linkend="v4l2-selection-flags"> constraint flags </link>.</para>
<section>
@ -91,7 +91,7 @@ top/left corner at position <constant> (0,0) </constant>. The rectangle's
coordinates are expressed in pixels.</para>
<para>The top left corner, width and height of the source rectangle, that is
the area actually sampled, is given by the <constant> V4L2_SEL_TGT_CROP_ACTIVE
the area actually sampled, is given by the <constant> V4L2_SEL_TGT_CROP
</constant> target. It uses the same coordinate system as <constant>
V4L2_SEL_TGT_CROP_BOUNDS </constant>. The active cropping area must lie
completely inside the capture boundaries. The driver may further adjust the
@ -111,13 +111,13 @@ height are equal to the image size set by <constant> VIDIOC_S_FMT </constant>.
</para>
<para>The part of a buffer into which the image is inserted by the hardware is
controlled by the <constant> V4L2_SEL_TGT_COMPOSE_ACTIVE </constant> target.
controlled by the <constant> V4L2_SEL_TGT_COMPOSE </constant> target.
The rectangle's coordinates are also expressed in the same coordinate system as
the bounds rectangle. The composing rectangle must lie completely inside bounds
rectangle. The driver must adjust the composing rectangle to fit to the
bounding limits. Moreover, the driver can perform other adjustments according
to hardware limitations. The application can control rounding behaviour using
<link linkend="v4l2-sel-flags"> constraint flags </link>.</para>
<link linkend="v4l2-selection-flags"> constraint flags </link>.</para>
<para>For capture devices the default composing rectangle is queried using
<constant> V4L2_SEL_TGT_COMPOSE_DEFAULT </constant>. It is usually equal to the
@ -125,7 +125,7 @@ bounding rectangle.</para>
<para>The part of a buffer that is modified by the hardware is given by
<constant> V4L2_SEL_TGT_COMPOSE_PADDED </constant>. It contains all pixels
defined using <constant> V4L2_SEL_TGT_COMPOSE_ACTIVE </constant> plus all
defined using <constant> V4L2_SEL_TGT_COMPOSE </constant> plus all
padding data modified by hardware during insertion process. All pixels outside
this rectangle <emphasis>must not</emphasis> be changed by the hardware. The
content of pixels that lie inside the padded area but outside active area is
@ -153,7 +153,7 @@ specified using <constant> VIDIOC_S_FMT </constant> ioctl.</para>
<para>The top left corner, width and height of the source rectangle, that is
the area from which image date are processed by the hardware, is given by the
<constant> V4L2_SEL_TGT_CROP_ACTIVE </constant>. Its coordinates are expressed
<constant> V4L2_SEL_TGT_CROP </constant>. Its coordinates are expressed
in in the same coordinate system as the bounds rectangle. The active cropping
area must lie completely inside the crop boundaries and the driver may further
adjust the requested size and/or position according to hardware
@ -165,7 +165,7 @@ bounding rectangle.</para>
<para>The part of a video signal or graphics display where the image is
inserted by the hardware is controlled by <constant>
V4L2_SEL_TGT_COMPOSE_ACTIVE </constant> target. The rectangle's coordinates
V4L2_SEL_TGT_COMPOSE </constant> target. The rectangle's coordinates
are expressed in pixels. The composing rectangle must lie completely inside the
bounds rectangle. The driver must adjust the area to fit to the bounding
limits. Moreover, the driver can perform other adjustments according to
@ -184,7 +184,7 @@ such a padded area is driver-dependent feature not covered by this document.
Driver developers are encouraged to keep padded rectangle equal to active one.
The padded target is accessed by the <constant> V4L2_SEL_TGT_COMPOSE_PADDED
</constant> identifier. It must contain all pixels from the <constant>
V4L2_SEL_TGT_COMPOSE_ACTIVE </constant> target.</para>
V4L2_SEL_TGT_COMPOSE </constant> target.</para>
</section>
@ -193,8 +193,8 @@ V4L2_SEL_TGT_COMPOSE_ACTIVE </constant> target.</para>
<title>Scaling control</title>
<para>An application can detect if scaling is performed by comparing the width
and the height of rectangles obtained using <constant> V4L2_SEL_TGT_CROP_ACTIVE
</constant> and <constant> V4L2_SEL_TGT_COMPOSE_ACTIVE </constant> targets. If
and the height of rectangles obtained using <constant> V4L2_SEL_TGT_CROP
</constant> and <constant> V4L2_SEL_TGT_COMPOSE </constant> targets. If
these are not equal then the scaling is applied. The application can compute
the scaling ratios using these values.</para>
@ -252,7 +252,7 @@ area)</para>
ret = ioctl(fd, &VIDIOC-G-SELECTION;, &amp;sel);
if (ret)
exit(-1);
sel.target = V4L2_SEL_TGT_CROP_ACTIVE;
sel.target = V4L2_SEL_TGT_CROP;
ret = ioctl(fd, &VIDIOC-S-SELECTION;, &amp;sel);
if (ret)
exit(-1);
@ -281,7 +281,7 @@ area)</para>
r.left = sel.r.width / 4;
r.top = sel.r.height / 4;
sel.r = r;
sel.target = V4L2_SEL_TGT_COMPOSE_ACTIVE;
sel.target = V4L2_SEL_TGT_COMPOSE;
sel.flags = V4L2_SEL_FLAG_LE;
ret = ioctl(fd, &VIDIOC-S-SELECTION;, &amp;sel);
if (ret)
@ -298,11 +298,11 @@ V4L2_BUF_TYPE_VIDEO_OUTPUT </constant> for other devices</para>
&v4l2-selection; compose = {
.type = V4L2_BUF_TYPE_VIDEO_OUTPUT,
.target = V4L2_SEL_TGT_COMPOSE_ACTIVE,
.target = V4L2_SEL_TGT_COMPOSE,
};
&v4l2-selection; crop = {
.type = V4L2_BUF_TYPE_VIDEO_OUTPUT,
.target = V4L2_SEL_TGT_CROP_ACTIVE,
.target = V4L2_SEL_TGT_CROP,
};
double hscale, vscale;

164
Documentation/DocBook/media/v4l/selections-common.xml Normal file
View File

@ -0,0 +1,164 @@
<section id="v4l2-selections-common">
<title>Common selection definitions</title>
<para>While the <link linkend="selection-api">V4L2 selection
API</link> and <link linkend="v4l2-subdev-selections">V4L2 subdev
selection APIs</link> are very similar, there's one fundamental
difference between the two. On sub-device API, the selection
rectangle refers to the media bus format, and is bound to a
sub-device's pad. On the V4L2 interface the selection rectangles
refer to the in-memory pixel format.</para>
<para>This section defines the common definitions of the
selection interfaces on the two APIs.</para>
<section id="v4l2-selection-targets">
<title>Selection targets</title>
<para>The precise meaning of the selection targets may be
dependent on which of the two interfaces they are used.</para>
<table pgwide="1" frame="none" id="v4l2-selection-targets-table">
<title>Selection target definitions</title>
<tgroup cols="5">
<colspec colname="c1" />
<colspec colname="c2" />
<colspec colname="c3" />
<colspec colname="c4" />
<colspec colname="c5" />
&cs-def;
<thead>
<row rowsep="1">
<entry align="left">Target name</entry>
<entry align="left">id</entry>
<entry align="left">Definition</entry>
<entry align="left">Valid for V4L2</entry>
<entry align="left">Valid for V4L2 subdev</entry>
</row>
</thead>
<tbody valign="top">
<row>
<entry><constant>V4L2_SEL_TGT_CROP</constant></entry>
<entry>0x0000</entry>
<entry>Crop rectangle. Defines the cropped area.</entry>
<entry>Yes</entry>
<entry>Yes</entry>
</row>
<row>
<entry><constant>V4L2_SEL_TGT_CROP_DEFAULT</constant></entry>
<entry>0x0001</entry>
<entry>Suggested cropping rectangle that covers the "whole picture".</entry>
<entry>Yes</entry>
<entry>No</entry>
</row>
<row>
<entry><constant>V4L2_SEL_TGT_CROP_BOUNDS</constant></entry>
<entry>0x0002</entry>
<entry>Bounds of the crop rectangle. All valid crop
rectangles fit inside the crop bounds rectangle.
</entry>
<entry>Yes</entry>
<entry>Yes</entry>
</row>
<row>
<entry><constant>V4L2_SEL_TGT_COMPOSE</constant></entry>
<entry>0x0100</entry>
<entry>Compose rectangle. Used to configure scaling
and composition.</entry>
<entry>Yes</entry>
<entry>Yes</entry>
</row>
<row>
<entry><constant>V4L2_SEL_TGT_COMPOSE_DEFAULT</constant></entry>
<entry>0x0101</entry>
<entry>Suggested composition rectangle that covers the "whole picture".</entry>
<entry>Yes</entry>
<entry>No</entry>
</row>
<row>
<entry><constant>V4L2_SEL_TGT_COMPOSE_BOUNDS</constant></entry>
<entry>0x0102</entry>
<entry>Bounds of the compose rectangle. All valid compose
rectangles fit inside the compose bounds rectangle.</entry>
<entry>Yes</entry>
<entry>Yes</entry>
</row>
<row>
<entry><constant>V4L2_SEL_TGT_COMPOSE_PADDED</constant></entry>
<entry>0x0103</entry>
<entry>The active area and all padding pixels that are inserted or
modified by hardware.</entry>
<entry>Yes</entry>
<entry>No</entry>
</row>
</tbody>
</tgroup>
</table>
</section>
<section id="v4l2-selection-flags">
<title>Selection flags</title>
<table pgwide="1" frame="none" id="v4l2-selection-flags-table">
<title>Selection flag definitions</title>
<tgroup cols="5">
<colspec colname="c1" />
<colspec colname="c2" />
<colspec colname="c3" />
<colspec colname="c4" />
<colspec colname="c5" />
&cs-def;
<thead>
<row rowsep="1">
<entry align="left">Flag name</entry>
<entry align="left">id</entry>
<entry align="left">Definition</entry>
<entry align="left">Valid for V4L2</entry>
<entry align="left">Valid for V4L2 subdev</entry>
</row>
</thead>
<tbody valign="top">
<row>
<entry><constant>V4L2_SEL_FLAG_GE</constant></entry>
<entry>(1 &lt;&lt; 0)</entry>
<entry>Suggest the driver it should choose greater or
equal rectangle (in size) than was requested. Albeit the
driver may choose a lesser size, it will only do so due to
hardware limitations. Without this flag (and
<constant>V4L2_SEL_FLAG_LE</constant>) the
behaviour is to choose the closest possible
rectangle.</entry>
<entry>Yes</entry>
<entry>Yes</entry>
</row>
<row>
<entry><constant>V4L2_SEL_FLAG_LE</constant></entry>
<entry>(1 &lt;&lt; 1)</entry>
<entry>Suggest the driver it
should choose lesser or equal rectangle (in size) than was
requested. Albeit the driver may choose a greater size, it
will only do so due to hardware limitations.</entry>
<entry>Yes</entry>
<entry>Yes</entry>
</row>
<row>
<entry><constant>V4L2_SEL_FLAG_KEEP_CONFIG</constant></entry>
<entry>(1 &lt;&lt; 2)</entry>
<entry>The configuration must not be propagated to any
further processing steps. If this flag is not given, the
configuration is propagated inside the subdevice to all
further processing steps.</entry>
<entry>No</entry>
<entry>Yes</entry>
</row>
</tbody>
</tgroup>
</table>
</section>
</section>

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

@ -140,6 +140,11 @@ structs, ioctls) must be noted in more detail in the history chapter
applications. -->
<revision>
<revnumber>3.6</revnumber>
<date>2012-07-02</date>
<authorinitials>hv</authorinitials>
<revremark>Added VIDIOC_ENUM_FREQ_BANDS.
</revremark>
<revnumber>3.5</revnumber>
<date>2012-05-07</date>
<authorinitials>sa, sn</authorinitials>
@ -534,6 +539,7 @@ and discussions on the V4L mailing list.</revremark>
&sub-enum-fmt;
&sub-enum-framesizes;
&sub-enum-frameintervals;
&sub-enum-freq-bands;
&sub-enuminput;
&sub-enumoutput;
&sub-enumstd;
@ -589,6 +595,11 @@ and discussions on the V4L mailing list.</revremark>
&sub-write;
</appendix>
<appendix>
<title>Common definitions for V4L2 and V4L2 subdev interfaces</title>
&sub-selections-common;
</appendix>
<appendix id="videodev">
<title>Video For Linux Two Header File</title>
&sub-videodev2-h;

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

@ -64,7 +64,7 @@ different sizes.</para>
<para>To allocate device buffers applications initialize relevant fields of
the <structname>v4l2_create_buffers</structname> structure. They set the
<structfield>type</structfield> field in the
<structname>v4l2_format</structname> structure, embedded in this
&v4l2-format; structure, embedded in this
structure, to the respective stream or buffer type.
<structfield>count</structfield> must be set to the number of required buffers.
<structfield>memory</structfield> specifies the required I/O method. The
@ -97,7 +97,13 @@ information.</para>
<row>
<entry>__u32</entry>
<entry><structfield>count</structfield></entry>
<entry>The number of buffers requested or granted.</entry>
<entry>The number of buffers requested or granted. If count == 0, then
<constant>VIDIOC_CREATE_BUFS</constant> will set <structfield>index</structfield>
to the current number of created buffers, and it will check the validity of
<structfield>memory</structfield> and <structfield>format.type</structfield>.
If those are invalid -1 is returned and errno is set to &EINVAL;,
otherwise <constant>VIDIOC_CREATE_BUFS</constant> returns 0. It will
never set errno to &EBUSY; in this particular case.</entry>
</row>
<row>
<entry>__u32</entry>
@ -108,7 +114,7 @@ information.</para>
/></entry>
</row>
<row>
<entry>struct&nbsp;v4l2_format</entry>
<entry>&v4l2-format;</entry>
<entry><structfield>format</structfield></entry>
<entry>Filled in by the application, preserved by the driver.</entry>
</row>

14
Documentation/DocBook/media/v4l/vidioc-dv-timings-cap.xml
View File

@ -54,15 +54,9 @@
interface and may change in the future.</para>
</note>
<para>To query the available timings, applications initialize the
<structfield>index</structfield> field and zero the reserved array of &v4l2-dv-timings-cap;
and call the <constant>VIDIOC_DV_TIMINGS_CAP</constant> ioctl with a pointer to this
structure. Drivers fill the rest of the structure or return an
&EINVAL; when the index is out of bounds. To enumerate all supported DV timings,
applications shall begin at index zero, incrementing by one until the
driver returns <errorcode>EINVAL</errorcode>. Note that drivers may enumerate a
different set of DV timings after switching the video input or
output.</para>
<para>To query the capabilities of the DV receiver/transmitter applications can call
this ioctl and the driver will fill in the structure. Note that drivers may return
different values after switching the video input or output.</para>
<table pgwide="1" frame="none" id="v4l2-bt-timings-cap">
<title>struct <structname>v4l2_bt_timings_cap</structname></title>
@ -115,7 +109,7 @@ output.</para>
<row>
<entry>__u32</entry>
<entry><structfield>reserved</structfield>[16]</entry>
<entry></entry>
<entry>Reserved for future extensions. Drivers must set the array to zero.</entry>
</row>
</tbody>
</tgroup>

179
Documentation/DocBook/media/v4l/vidioc-enum-freq-bands.xml Normal file
View File

@ -0,0 +1,179 @@
<refentry id="vidioc-enum-freq-bands">
<refmeta>
<refentrytitle>ioctl VIDIOC_ENUM_FREQ_BANDS</refentrytitle>
&manvol;
</refmeta>
<refnamediv>
<refname>VIDIOC_ENUM_FREQ_BANDS</refname>
<refpurpose>Enumerate supported frequency bands</refpurpose>
</refnamediv>
<refsynopsisdiv>
<funcsynopsis>
<funcprototype>
<funcdef>int <function>ioctl</function></funcdef>
<paramdef>int <parameter>fd</parameter></paramdef>
<paramdef>int <parameter>request</parameter></paramdef>
<paramdef>struct v4l2_frequency_band
*<parameter>argp</parameter></paramdef>
</funcprototype>
</funcsynopsis>
</refsynopsisdiv>
<refsect1>
<title>Arguments</title>
<variablelist>
<varlistentry>
<term><parameter>fd</parameter></term>
<listitem>
<para>&fd;</para>
</listitem>
</varlistentry>
<varlistentry>
<term><parameter>request</parameter></term>
<listitem>
<para>VIDIOC_ENUM_FREQ_BANDS</para>
</listitem>
</varlistentry>
<varlistentry>
<term><parameter>argp</parameter></term>
<listitem>
<para></para>
</listitem>
</varlistentry>
</variablelist>
</refsect1>
<refsect1>
<title>Description</title>
<note>
<title>Experimental</title>
<para>This is an <link linkend="experimental"> experimental </link>
interface and may change in the future.</para>
</note>
<para>Enumerates the frequency bands that a tuner or modulator supports.
To do this applications initialize the <structfield>tuner</structfield>,
<structfield>type</structfield> and <structfield>index</structfield> fields,
and zero out the <structfield>reserved</structfield> array of a &v4l2-frequency-band; and
call the <constant>VIDIOC_ENUM_FREQ_BANDS</constant> ioctl with a pointer
to this structure.</para>
<para>This ioctl is supported if the <constant>V4L2_TUNER_CAP_FREQ_BANDS</constant> capability
of the corresponding tuner/modulator is set.</para>
<table pgwide="1" frame="none" id="v4l2-frequency-band">
<title>struct <structname>v4l2_frequency_band</structname></title>
<tgroup cols="3">
&cs-str;
<tbody valign="top">
<row>
<entry>__u32</entry>
<entry><structfield>tuner</structfield></entry>
<entry>The tuner or modulator index number. This is the
same value as in the &v4l2-input; <structfield>tuner</structfield>
field and the &v4l2-tuner; <structfield>index</structfield> field, or
the &v4l2-output; <structfield>modulator</structfield> field and the
&v4l2-modulator; <structfield>index</structfield> field.</entry>
</row>
<row>
<entry>__u32</entry>
<entry><structfield>type</structfield></entry>
<entry>The tuner type. This is the same value as in the
&v4l2-tuner; <structfield>type</structfield> field. The type must be set
to <constant>V4L2_TUNER_RADIO</constant> for <filename>/dev/radioX</filename>
device nodes, and to <constant>V4L2_TUNER_ANALOG_TV</constant>
for all others. Set this field to <constant>V4L2_TUNER_RADIO</constant> for
modulators (currently only radio modulators are supported).
See <xref linkend="v4l2-tuner-type" /></entry>
</row>
<row>
<entry>__u32</entry>
<entry><structfield>index</structfield></entry>
<entry>Identifies the frequency band, set by the application.</entry>
</row>
<row>
<entry>__u32</entry>
<entry><structfield>capability</structfield></entry>
<entry spanname="hspan">The tuner/modulator capability flags for
this frequency band, see <xref linkend="tuner-capability" />. The <constant>V4L2_TUNER_CAP_LOW</constant>
capability must be the same for all frequency bands of the selected tuner/modulator.
So either all bands have that capability set, or none of them have that capability.</entry>
</row>
<row>
<entry>__u32</entry>
<entry><structfield>rangelow</structfield></entry>
<entry spanname="hspan">The lowest tunable frequency in
units of 62.5 kHz, or if the <structfield>capability</structfield>
flag <constant>V4L2_TUNER_CAP_LOW</constant> is set, in units of 62.5
Hz, for this frequency band.</entry>
</row>
<row>
<entry>__u32</entry>
<entry><structfield>rangehigh</structfield></entry>
<entry spanname="hspan">The highest tunable frequency in
units of 62.5 kHz, or if the <structfield>capability</structfield>
flag <constant>V4L2_TUNER_CAP_LOW</constant> is set, in units of 62.5
Hz, for this frequency band.</entry>
</row>
<row>
<entry>__u32</entry>
<entry><structfield>modulation</structfield></entry>
<entry spanname="hspan">The supported modulation systems of this frequency band.
See <xref linkend="band-modulation" />. Note that currently only one
modulation system per frequency band is supported. More work will need to
be done if multiple modulation systems are possible. Contact the
linux-media mailing list (&v4l-ml;) if you need that functionality.</entry>
</row>
<row>
<entry>__u32</entry>
<entry><structfield>reserved</structfield>[9]</entry>
<entry>Reserved for future extensions. Applications and drivers
must set the array to zero.</entry>
</row>
</tbody>
</tgroup>
</table>
<table pgwide="1" frame="none" id="band-modulation">
<title>Band Modulation Systems</title>
<tgroup cols="3">
&cs-def;
<tbody valign="top">
<row>
<entry><constant>V4L2_BAND_MODULATION_VSB</constant></entry>
<entry>0x02</entry>
<entry>Vestigial Sideband modulation, used for analog TV.</entry>
</row>
<row>
<entry><constant>V4L2_BAND_MODULATION_FM</constant></entry>
<entry>0x04</entry>
<entry>Frequency Modulation, commonly used for analog radio.</entry>
</row>
<row>
<entry><constant>V4L2_BAND_MODULATION_AM</constant></entry>
<entry>0x08</entry>
<entry>Amplitude Modulation, commonly used for analog radio.</entry>
</row>
</tbody>
</tgroup>
</table>
</refsect1>
<refsect1>
&return-value;
<variablelist>
<varlistentry>
<term><errorcode>EINVAL</errorcode></term>
<listitem>
<para>The <structfield>tuner</structfield> or <structfield>index</structfield>
is out of bounds or the <structfield>type</structfield> field is wrong.</para>
</listitem>
</varlistentry>
</variablelist>
</refsect1>
</refentry>

7
Documentation/DocBook/media/v4l/vidioc-g-ext-ctrls.xml
View File

@ -284,13 +284,6 @@ These controls are described in <xref
processing controls. These controls are described in <xref
linkend="image-process-controls" />.</entry>
</row>
<row>
<entry><constant>V4L2_CTRL_CLASS_JPEG</constant></entry>
<entry>0x9d0000</entry>
<entry>The class containing JPEG compression controls.
These controls are described in <xref
linkend="jpeg-controls" />.</entry>
</row>
</tbody>
</tgroup>
</table>

13
Documentation/DocBook/media/v4l/vidioc-g-frequency.xml
View File

@ -98,11 +98,12 @@ the &v4l2-output; <structfield>modulator</structfield> field and the
<entry>__u32</entry>
<entry><structfield>type</structfield></entry>
<entry>The tuner type. This is the same value as in the
&v4l2-tuner; <structfield>type</structfield> field. See The type must be set
&v4l2-tuner; <structfield>type</structfield> field. The type must be set
to <constant>V4L2_TUNER_RADIO</constant> for <filename>/dev/radioX</filename>
device nodes, and to <constant>V4L2_TUNER_ANALOG_TV</constant>
for all others. The field is not applicable to modulators, &ie; ignored
by drivers. See <xref linkend="v4l2-tuner-type" /></entry>
for all others. Set this field to <constant>V4L2_TUNER_RADIO</constant> for
modulators (currently only radio modulators are supported).
See <xref linkend="v4l2-tuner-type" /></entry>
</row>
<row>
<entry>__u32</entry>
@ -135,6 +136,12 @@ bounds or the value in the <structfield>type</structfield> field is
wrong.</para>
</listitem>
</varlistentry>
<varlistentry>
<term><errorcode>EBUSY</errorcode></term>
<listitem>
<para>A hardware seek is in progress.</para>
</listitem>
</varlistentry>
</variablelist>
</refsect1>
</refentry>

86
Documentation/DocBook/media/v4l/vidioc-g-selection.xml
View File

@ -65,9 +65,9 @@ Do not use multiplanar buffers. Use <constant> V4L2_BUF_TYPE_VIDEO_CAPTURE
</constant>. Use <constant> V4L2_BUF_TYPE_VIDEO_OUTPUT </constant> instead of
<constant> V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE </constant>. The next step is
setting the value of &v4l2-selection; <structfield>target</structfield> field
to <constant> V4L2_SEL_TGT_CROP_ACTIVE </constant> (<constant>
V4L2_SEL_TGT_COMPOSE_ACTIVE </constant>). Please refer to table <xref
linkend="v4l2-sel-target" /> or <xref linkend="selection-api" /> for additional
to <constant> V4L2_SEL_TGT_CROP </constant> (<constant>
V4L2_SEL_TGT_COMPOSE </constant>). Please refer to table <xref
linkend="v4l2-selections-common" /> or <xref linkend="selection-api" /> for additional
targets. The <structfield>flags</structfield> and <structfield>reserved
</structfield> fields of &v4l2-selection; are ignored and they must be filled
with zeros. The driver fills the rest of the structure or
@ -86,9 +86,9 @@ use multiplanar buffers. Use <constant> V4L2_BUF_TYPE_VIDEO_CAPTURE
</constant>. Use <constant> V4L2_BUF_TYPE_VIDEO_OUTPUT </constant> instead of
<constant> V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE </constant>. The next step is
setting the value of &v4l2-selection; <structfield>target</structfield> to
<constant>V4L2_SEL_TGT_CROP_ACTIVE</constant> (<constant>
V4L2_SEL_TGT_COMPOSE_ACTIVE </constant>). Please refer to table <xref
linkend="v4l2-sel-target" /> or <xref linkend="selection-api" /> for additional
<constant>V4L2_SEL_TGT_CROP</constant> (<constant>
V4L2_SEL_TGT_COMPOSE </constant>). Please refer to table <xref
linkend="v4l2-selections-common" /> or <xref linkend="selection-api" /> for additional
targets. The &v4l2-rect; <structfield>r</structfield> rectangle need to be
set to the desired active area. Field &v4l2-selection; <structfield> reserved
</structfield> is ignored and must be filled with zeros. The driver may adjust
@ -154,74 +154,8 @@ exist no rectangle </emphasis> that satisfies the constraints.</para>
</refsect1>
<refsect1>
<table frame="none" pgwide="1" id="v4l2-sel-target">
<title>Selection targets.</title>
<tgroup cols="3">
&cs-def;
<tbody valign="top">
<row>
<entry><constant>V4L2_SEL_TGT_CROP_ACTIVE</constant></entry>
<entry>0x0000</entry>
<entry>The area that is currently cropped by hardware.</entry>
</row>
<row>
<entry><constant>V4L2_SEL_TGT_CROP_DEFAULT</constant></entry>
<entry>0x0001</entry>
<entry>Suggested cropping rectangle that covers the "whole picture".</entry>
</row>
<row>
<entry><constant>V4L2_SEL_TGT_CROP_BOUNDS</constant></entry>
<entry>0x0002</entry>
<entry>Limits for the cropping rectangle.</entry>
</row>
<row>
<entry><constant>V4L2_SEL_TGT_COMPOSE_ACTIVE</constant></entry>
<entry>0x0100</entry>
<entry>The area to which data is composed by hardware.</entry>
</row>
<row>
<entry><constant>V4L2_SEL_TGT_COMPOSE_DEFAULT</constant></entry>
<entry>0x0101</entry>
<entry>Suggested composing rectangle that covers the "whole picture".</entry>
</row>
<row>
<entry><constant>V4L2_SEL_TGT_COMPOSE_BOUNDS</constant></entry>
<entry>0x0102</entry>
<entry>Limits for the composing rectangle.</entry>
</row>
<row>
<entry><constant>V4L2_SEL_TGT_COMPOSE_PADDED</constant></entry>
<entry>0x0103</entry>
<entry>The active area and all padding pixels that are inserted or modified by hardware.</entry>
</row>
</tbody>
</tgroup>
</table>
</refsect1>
<refsect1>
<table frame="none" pgwide="1" id="v4l2-sel-flags">
<title>Selection constraint flags</title>
<tgroup cols="3">
&cs-def;
<tbody valign="top">
<row>
<entry><constant>V4L2_SEL_FLAG_GE</constant></entry>
<entry>0x00000001</entry>
<entry>Indicates that the adjusted rectangle must contain the original
&v4l2-selection; <structfield>r</structfield> rectangle.</entry>
</row>
<row>
<entry><constant>V4L2_SEL_FLAG_LE</constant></entry>
<entry>0x00000002</entry>
<entry>Indicates that the adjusted rectangle must be inside the original
&v4l2-rect; <structfield>r</structfield> rectangle.</entry>
</row>
</tbody>
</tgroup>
</table>
</refsect1>
<para>Selection targets and flags are documented in <xref
linkend="v4l2-selections-common"/>.</para>
<section>
<figure id="sel-const-adjust">
@ -252,14 +186,14 @@ exist no rectangle </emphasis> that satisfies the constraints.</para>
<row>
<entry>__u32</entry>
<entry><structfield>target</structfield></entry>
<entry>Used to select between <link linkend="v4l2-sel-target"> cropping
<entry>Used to select between <link linkend="v4l2-selections-common"> cropping
and composing rectangles</link>.</entry>
</row>
<row>
<entry>__u32</entry>
<entry><structfield>flags</structfield></entry>
<entry>Flags controlling the selection rectangle adjustments, refer to
<link linkend="v4l2-sel-flags">selection flags</link>.</entry>
<link linkend="v4l2-selection-flags">selection flags</link>.</entry>
</row>
<row>
<entry>&v4l2-rect;</entry>

38
Documentation/DocBook/media/v4l/vidioc-g-tuner.xml
View File

@ -119,10 +119,14 @@ field is not quite clear.--></para></entry>
<xref linkend="tuner-capability" />. Audio flags indicate the ability
to decode audio subprograms. They will <emphasis>not</emphasis>
change, for example with the current video standard.</para><para>When
the structure refers to a radio tuner only the
<constant>V4L2_TUNER_CAP_LOW</constant>,
<constant>V4L2_TUNER_CAP_STEREO</constant> and
<constant>V4L2_TUNER_CAP_RDS</constant> flags can be set.</para></entry>
the structure refers to a radio tuner the
<constant>V4L2_TUNER_CAP_LANG1</constant>,
<constant>V4L2_TUNER_CAP_LANG2</constant> and
<constant>V4L2_TUNER_CAP_NORM</constant> flags can't be used.</para>
<para>If multiple frequency bands are supported, then
<structfield>capability</structfield> is the union of all
<structfield>capability></structfield> fields of each &v4l2-frequency-band;.
</para></entry>
</row>
<row>
<entry>__u32</entry>
@ -130,7 +134,9 @@ the structure refers to a radio tuner only the
<entry spanname="hspan">The lowest tunable frequency in
units of 62.5 kHz, or if the <structfield>capability</structfield>
flag <constant>V4L2_TUNER_CAP_LOW</constant> is set, in units of 62.5
Hz.</entry>
Hz. If multiple frequency bands are supported, then
<structfield>rangelow</structfield> is the lowest frequency
of all the frequency bands.</entry>
</row>
<row>
<entry>__u32</entry>
@ -138,7 +144,9 @@ Hz.</entry>
<entry spanname="hspan">The highest tunable frequency in
units of 62.5 kHz, or if the <structfield>capability</structfield>
flag <constant>V4L2_TUNER_CAP_LOW</constant> is set, in units of 62.5
Hz.</entry>
Hz. If multiple frequency bands are supported, then
<structfield>rangehigh</structfield> is the highest frequency
of all the frequency bands.</entry>
</row>
<row>
<entry>__u32</entry>
@ -275,6 +283,18 @@ can or must be switched. (B/G PAL tuners for example are typically not
see the description of ioctl &VIDIOC-ENUMINPUT; for details. Only
<constant>V4L2_TUNER_ANALOG_TV</constant> tuners can have this capability.</entry>
</row>
<row>
<entry><constant>V4L2_TUNER_CAP_HWSEEK_BOUNDED</constant></entry>
<entry>0x0004</entry>
<entry>If set, then this tuner supports the hardware seek functionality
where the seek stops when it reaches the end of the frequency range.</entry>
</row>
<row>
<entry><constant>V4L2_TUNER_CAP_HWSEEK_WRAP</constant></entry>
<entry>0x0008</entry>
<entry>If set, then this tuner supports the hardware seek functionality
where the seek wraps around when it reaches the end of the frequency range.</entry>
</row>
<row>
<entry><constant>V4L2_TUNER_CAP_STEREO</constant></entry>
<entry>0x0010</entry>
@ -328,6 +348,12 @@ radio tuners.</entry>
<entry>0x0200</entry>
<entry>The RDS data is parsed by the hardware and set via controls.</entry>
</row>
<row>
<entry><constant>V4L2_TUNER_CAP_FREQ_BANDS</constant></entry>
<entry>0x0400</entry>
<entry>The &VIDIOC-ENUM-FREQ-BANDS; ioctl can be used to enumerate
the available frequency bands.</entry>
</row>
</tbody>
</tgroup>
</table>

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

@ -71,12 +71,9 @@ initialize the <structfield>bytesused</structfield>,
<structfield>field</structfield> and
<structfield>timestamp</structfield> fields, see <xref
linkend="buffer" /> for details.
Applications must also set <structfield>flags</structfield> to 0. If a driver
supports capturing from specific video inputs and you want to specify a video
input, then <structfield>flags</structfield> should be set to
<constant>V4L2_BUF_FLAG_INPUT</constant> and the field
<structfield>input</structfield> must be initialized to the desired input.
The <structfield>reserved</structfield> field must be set to 0. When using
Applications must also set <structfield>flags</structfield> to 0.
The <structfield>reserved2</structfield> and
<structfield>reserved</structfield> fields must be set to 0. When using
the <link linkend="planar-apis">multi-planar API</link>, the
<structfield>m.planes</structfield> field must contain a userspace pointer
to a filled-in array of &v4l2-plane; and the <structfield>length</structfield>

13
Documentation/DocBook/media/v4l/vidioc-querycap.xml
View File

@ -191,6 +191,19 @@ linkend="output">Video Output</link> interface.</entry>
<link linkend="planar-apis">multi-planar API</link> through the
<link linkend="output">Video Output</link> interface.</entry>
</row>
<row>
<entry><constant>V4L2_CAP_VIDEO_M2M</constant></entry>
<entry>0x00004000</entry>
<entry>The device supports the single-planar API through the
Video Memory-To-Memory interface.</entry>
</row>
<row>
<entry><constant>V4L2_CAP_VIDEO_M2M_MPLANE</constant></entry>
<entry>0x00008000</entry>
<entry>The device supports the
<link linkend="planar-apis">multi-planar API</link> through the
Video Memory-To-Memory interface.</entry>
</row>
<row>
<entry><constant>V4L2_CAP_VIDEO_OVERLAY</constant></entry>
<entry>0x00000004</entry>

68
Documentation/DocBook/media/v4l/vidioc-s-hw-freq-seek.xml
View File

@ -52,11 +52,26 @@
<para>Start a hardware frequency seek from the current frequency.
To do this applications initialize the <structfield>tuner</structfield>,
<structfield>type</structfield>, <structfield>seek_upward</structfield>,
<structfield>spacing</structfield> and
<structfield>wrap_around</structfield> fields, and zero out the
<structfield>reserved</structfield> array of a &v4l2-hw-freq-seek; and
call the <constant>VIDIOC_S_HW_FREQ_SEEK</constant> ioctl with a pointer
to this structure.</para>
<structfield>wrap_around</structfield>, <structfield>spacing</structfield>,
<structfield>rangelow</structfield> and <structfield>rangehigh</structfield>
fields, and zero out the <structfield>reserved</structfield> array of a
&v4l2-hw-freq-seek; and call the <constant>VIDIOC_S_HW_FREQ_SEEK</constant>
ioctl with a pointer to this structure.</para>
<para>The <structfield>rangelow</structfield> and
<structfield>rangehigh</structfield> fields can be set to a non-zero value to
tell the driver to search a specific band. If the &v4l2-tuner;
<structfield>capability</structfield> field has the
<constant>V4L2_TUNER_CAP_HWSEEK_PROG_LIM</constant> flag set, these values
must fall within one of the bands returned by &VIDIOC-ENUM-FREQ-BANDS;. If
the <constant>V4L2_TUNER_CAP_HWSEEK_PROG_LIM</constant> flag is not set,
then these values must exactly match those of one of the bands returned by
&VIDIOC-ENUM-FREQ-BANDS;. If the current frequency of the tuner does not fall
within the selected band it will be clamped to fit in the band before the
seek is started.</para>
<para>If an error is returned, then the original frequency will
be restored.</para>
<para>This ioctl is supported if the <constant>V4L2_CAP_HW_FREQ_SEEK</constant> capability is set.</para>
@ -87,7 +102,10 @@ field and the &v4l2-tuner; <structfield>index</structfield> field.</entry>
<row>
<entry>__u32</entry>
<entry><structfield>wrap_around</structfield></entry>
<entry>If non-zero, wrap around when at the end of the frequency range, else stop seeking.</entry>
<entry>If non-zero, wrap around when at the end of the frequency range, else stop seeking.
The &v4l2-tuner; <structfield>capability</structfield> field will tell you what the
hardware supports.
</entry>
</row>
<row>
<entry>__u32</entry>
@ -96,7 +114,27 @@ field and the &v4l2-tuner; <structfield>index</structfield> field.</entry>
</row>
<row>
<entry>__u32</entry>
<entry><structfield>reserved</structfield>[7]</entry>
<entry><structfield>rangelow</structfield></entry>
<entry>If non-zero, the lowest tunable frequency of the band to
search in units of 62.5 kHz, or if the &v4l2-tuner;
<structfield>capability</structfield> field has the
<constant>V4L2_TUNER_CAP_LOW</constant> flag set, in units of 62.5 Hz.
If <structfield>rangelow</structfield> is zero a reasonable default value
is used.</entry>
</row>
<row>
<entry>__u32</entry>
<entry><structfield>rangehigh</structfield></entry>
<entry>If non-zero, the highest tunable frequency of the band to
search in units of 62.5 kHz, or if the &v4l2-tuner;
<structfield>capability</structfield> field has the
<constant>V4L2_TUNER_CAP_LOW</constant> flag set, in units of 62.5 Hz.
If <structfield>rangehigh</structfield> is zero a reasonable default value
is used.</entry>
</row>
<row>
<entry>__u32</entry>
<entry><structfield>reserved</structfield>[5]</entry>
<entry>Reserved for future extensions. Applications
must set the array to zero.</entry>
</row>
@ -113,14 +151,22 @@ field and the &v4l2-tuner; <structfield>index</structfield> field.</entry>
<term><errorcode>EINVAL</errorcode></term>
<listitem>
<para>The <structfield>tuner</structfield> index is out of
bounds, the wrap_around value is not supported or the value in the <structfield>type</structfield> field is
wrong.</para>
bounds, the <structfield>wrap_around</structfield> value is not supported or
one of the values in the <structfield>type</structfield>,
<structfield>rangelow</structfield> or <structfield>rangehigh</structfield>
fields is wrong.</para>
</listitem>
</varlistentry>
<varlistentry>
<term><errorcode>EAGAIN</errorcode></term>
<term><errorcode>ENODATA</errorcode></term>
<listitem>
<para>The ioctl timed-out. Try again.</para>
<para>The hardware seek found no channels.</para>
</listitem>
</varlistentry>
<varlistentry>
<term><errorcode>EBUSY</errorcode></term>
<listitem>
<para>Another hardware seek is already in progress.</para>
</listitem>
</varlistentry>
</variablelist>

79
Documentation/DocBook/media/v4l/vidioc-subdev-g-selection.xml
View File

@ -72,10 +72,10 @@
<section>
<title>Types of selection targets</title>
<para>There are two types of selection targets: actual and bounds.
The ACTUAL targets are the targets which configure the hardware.
The BOUNDS target will return a rectangle that contain all
possible ACTUAL rectangles.</para>
<para>There are two types of selection targets: actual and bounds. The
actual targets are the targets which configure the hardware. The BOUNDS
target will return a rectangle that contain all possible actual
rectangles.</para>
</section>
<section>
@ -87,71 +87,8 @@
<constant>EINVAL</constant>.</para>
</section>
<table pgwide="1" frame="none" id="v4l2-subdev-selection-targets">
<title>V4L2 subdev selection targets</title>
<tgroup cols="3">
&cs-def;
<tbody valign="top">
<row>
<entry><constant>V4L2_SUBDEV_SEL_TGT_CROP_ACTUAL</constant></entry>
<entry>0x0000</entry>
<entry>Actual crop. Defines the cropping
performed by the processing step.</entry>
</row>
<row>
<entry><constant>V4L2_SUBDEV_SEL_TGT_CROP_BOUNDS</constant></entry>
<entry>0x0002</entry>
<entry>Bounds of the crop rectangle.</entry>
</row>
<row>
<entry><constant>V4L2_SUBDEV_SEL_TGT_COMPOSE_ACTUAL</constant></entry>
<entry>0x0100</entry>
<entry>Actual compose rectangle. Used to configure scaling
on sink pads and composition on source pads.</entry>
</row>
<row>
<entry><constant>V4L2_SUBDEV_SEL_TGT_COMPOSE_BOUNDS</constant></entry>
<entry>0x0102</entry>
<entry>Bounds of the compose rectangle.</entry>
</row>
</tbody>
</tgroup>
</table>
<table pgwide="1" frame="none" id="v4l2-subdev-selection-flags">
<title>V4L2 subdev selection flags</title>
<tgroup cols="3">
&cs-def;
<tbody valign="top">
<row>
<entry><constant>V4L2_SUBDEV_SEL_FLAG_SIZE_GE</constant></entry>
<entry>(1 &lt;&lt; 0)</entry> <entry>Suggest the driver it
should choose greater or equal rectangle (in size) than
was requested. Albeit the driver may choose a lesser size,
it will only do so due to hardware limitations. Without
this flag (and
<constant>V4L2_SUBDEV_SEL_FLAG_SIZE_LE</constant>) the
behaviour is to choose the closest possible
rectangle.</entry>
</row>
<row>
<entry><constant>V4L2_SUBDEV_SEL_FLAG_SIZE_LE</constant></entry>
<entry>(1 &lt;&lt; 1)</entry> <entry>Suggest the driver it
should choose lesser or equal rectangle (in size) than was
requested. Albeit the driver may choose a greater size, it
will only do so due to hardware limitations.</entry>
</row>
<row>
<entry><constant>V4L2_SUBDEV_SEL_FLAG_KEEP_CONFIG</constant></entry>
<entry>(1 &lt;&lt; 2)</entry>
<entry>The configuration should not be propagated to any
further processing steps. If this flag is not given, the
configuration is propagated inside the subdevice to all
further processing steps.</entry>
</row>
</tbody>
</tgroup>
</table>
<para>Selection targets and flags are documented in <xref
linkend="v4l2-selections-common"/>.</para>
<table pgwide="1" frame="none" id="v4l2-subdev-selection">
<title>struct <structname>v4l2_subdev_selection</structname></title>
@ -173,13 +110,13 @@
<entry>__u32</entry>
<entry><structfield>target</structfield></entry>
<entry>Target selection rectangle. See
<xref linkend="v4l2-subdev-selection-targets">.</xref>.</entry>
<xref linkend="v4l2-selections-common" />.</entry>
</row>
<row>
<entry>__u32</entry>
<entry><structfield>flags</structfield></entry>
<entry>Flags. See
<xref linkend="v4l2-subdev-selection-flags">.</xref></entry>
<xref linkend="v4l2-selection-flags" />.</entry>
</row>
<row>
<entry>&v4l2-rect;</entry>

5
Documentation/IRQ-domain.txt
View File

@ -93,6 +93,7 @@ Linux IRQ number into the hardware.
Most drivers cannot use this mapping.
==== Legacy ====
irq_domain_add_simple()
irq_domain_add_legacy()
irq_domain_add_legacy_isa()
@ -115,3 +116,7 @@ The legacy map should only be used if fixed IRQ mappings must be
supported. For example, ISA controllers would use the legacy map for
mapping Linux IRQs 0-15 so that existing ISA drivers get the correct IRQ
numbers.
Most users of legacy mappings should use irq_domain_add_simple() which
will use a legacy domain only if an IRQ range is supplied by the
system and will otherwise use a linear domain mapping.

2
Documentation/ManagementStyle
View File

@ -178,7 +178,7 @@ sadly that you are one too, and that while we can all bask in the secure
knowledge that we're better than the average person (let's face it,
nobody ever believes that they're average or below-average), we should
also admit that we're not the sharpest knife around, and there will be
other people that are less of an idiot that you are.
other people that are less of an idiot than you are.
Some people react badly to smart people. Others take advantage of them.

39
Documentation/RCU/checklist.txt
View File

@ -162,9 +162,9 @@ over a rather long period of time, but improvements are always welcome!
when publicizing a pointer to a structure that can
be traversed by an RCU read-side critical section.
5. If call_rcu(), or a related primitive such as call_rcu_bh() or
call_rcu_sched(), is used, the callback function must be
written to be called from softirq context. In particular,
5. If call_rcu(), or a related primitive such as call_rcu_bh(),
call_rcu_sched(), or call_srcu() is used, the callback function
must be written to be called from softirq context. In particular,
it cannot block.
6. Since synchronize_rcu() can block, it cannot be called from
@ -202,11 +202,12 @@ over a rather long period of time, but improvements are always welcome!
updater uses call_rcu_sched() or synchronize_sched(), then
the corresponding readers must disable preemption, possibly
by calling rcu_read_lock_sched() and rcu_read_unlock_sched().
If the updater uses synchronize_srcu(), the the corresponding
readers must use srcu_read_lock() and srcu_read_unlock(),
and with the same srcu_struct. The rules for the expedited
primitives are the same as for their non-expedited counterparts.
Mixing things up will result in confusion and broken kernels.
If the updater uses synchronize_srcu() or call_srcu(),
the the corresponding readers must use srcu_read_lock() and
srcu_read_unlock(), and with the same srcu_struct. The rules for
the expedited primitives are the same as for their non-expedited
counterparts. Mixing things up will result in confusion and
broken kernels.
One exception to this rule: rcu_read_lock() and rcu_read_unlock()
may be substituted for rcu_read_lock_bh() and rcu_read_unlock_bh()
@ -333,14 +334,14 @@ over a rather long period of time, but improvements are always welcome!
victim CPU from ever going offline.)
14. SRCU (srcu_read_lock(), srcu_read_unlock(), srcu_dereference(),
synchronize_srcu(), and synchronize_srcu_expedited()) may only
be invoked from process context. Unlike other forms of RCU, it
-is- permissible to block in an SRCU read-side critical section
(demarked by srcu_read_lock() and srcu_read_unlock()), hence the
"SRCU": "sleepable RCU". Please note that if you don't need
to sleep in read-side critical sections, you should be using
RCU rather than SRCU, because RCU is almost always faster and
easier to use than is SRCU.
synchronize_srcu(), synchronize_srcu_expedited(), and call_srcu())
may only be invoked from process context. Unlike other forms of
RCU, it -is- permissible to block in an SRCU read-side critical
section (demarked by srcu_read_lock() and srcu_read_unlock()),
hence the "SRCU": "sleepable RCU". Please note that if you
don't need to sleep in read-side critical sections, you should be
using RCU rather than SRCU, because RCU is almost always faster
and easier to use than is SRCU.
If you need to enter your read-side critical section in a
hardirq or exception handler, and then exit that same read-side
@ -353,8 +354,8 @@ over a rather long period of time, but improvements are always welcome!
cleanup_srcu_struct(). These are passed a "struct srcu_struct"
that defines the scope of a given SRCU domain. Once initialized,
the srcu_struct is passed to srcu_read_lock(), srcu_read_unlock()
synchronize_srcu(), and synchronize_srcu_expedited(). A given
synchronize_srcu() waits only for SRCU read-side critical
synchronize_srcu(), synchronize_srcu_expedited(), and call_srcu().
A given synchronize_srcu() waits only for SRCU read-side critical
sections governed by srcu_read_lock() and srcu_read_unlock()
calls that have been passed the same srcu_struct. This property
is what makes sleeping read-side critical sections tolerable --
@ -374,7 +375,7 @@ over a rather long period of time, but improvements are always welcome!
requiring SRCU's read-side deadlock immunity or low read-side
realtime latency.
Note that, rcu_assign_pointer() relates to SRCU just as they do
Note that, rcu_assign_pointer() relates to SRCU just as it does
to other forms of RCU.
15. The whole point of call_rcu(), synchronize_rcu(), and friends

15
Documentation/RCU/rcubarrier.txt
View File

@ -79,8 +79,6 @@ complete. Pseudo-code using rcu_barrier() is as follows:
2. Execute rcu_barrier().
3. Allow the module to be unloaded.
Quick Quiz #1: Why is there no srcu_barrier()?
The rcutorture module makes use of rcu_barrier in its exit function
as follows:
@ -162,7 +160,7 @@ for any pre-existing callbacks to complete.
Then lines 55-62 print status and do operation-specific cleanup, and
then return, permitting the module-unload operation to be completed.
Quick Quiz #2: Is there any other situation where rcu_barrier() might
Quick Quiz #1: Is there any other situation where rcu_barrier() might
be required?
Your module might have additional complications. For example, if your
@ -242,7 +240,7 @@ reaches zero, as follows:
4 complete(&rcu_barrier_completion);
5 }
Quick Quiz #3: What happens if CPU 0's rcu_barrier_func() executes
Quick Quiz #2: What happens if CPU 0's rcu_barrier_func() executes
immediately (thus incrementing rcu_barrier_cpu_count to the
value one), but the other CPU's rcu_barrier_func() invocations
are delayed for a full grace period? Couldn't this result in
@ -259,12 +257,7 @@ so that your module may be safely unloaded.
Answers to Quick Quizzes
Quick Quiz #1: Why is there no srcu_barrier()?
Answer: Since there is no call_srcu(), there can be no outstanding SRCU
callbacks. Therefore, there is no need to wait for them.
Quick Quiz #2: Is there any other situation where rcu_barrier() might
Quick Quiz #1: Is there any other situation where rcu_barrier() might
be required?
Answer: Interestingly enough, rcu_barrier() was not originally
@ -278,7 +271,7 @@ Answer: Interestingly enough, rcu_barrier() was not originally
implementing rcutorture, and found that rcu_barrier() solves
this problem as well.
Quick Quiz #3: What happens if CPU 0's rcu_barrier_func() executes
Quick Quiz #2: What happens if CPU 0's rcu_barrier_func() executes
immediately (thus incrementing rcu_barrier_cpu_count to the
value one), but the other CPU's rcu_barrier_func() invocations
are delayed for a full grace period? Couldn't this result in

9
Documentation/RCU/torture.txt
View File

@ -174,11 +174,20 @@ torture_type The type of RCU to test, with string values as follows:
and synchronize_rcu_bh_expedited().
"srcu": srcu_read_lock(), srcu_read_unlock() and
call_srcu().
"srcu_sync": srcu_read_lock(), srcu_read_unlock() and
synchronize_srcu().
"srcu_expedited": srcu_read_lock(), srcu_read_unlock() and
synchronize_srcu_expedited().
"srcu_raw": srcu_read_lock_raw(), srcu_read_unlock_raw(),
and call_srcu().
"srcu_raw_sync": srcu_read_lock_raw(), srcu_read_unlock_raw(),
and synchronize_srcu().
"sched": preempt_disable(), preempt_enable(), and
call_rcu_sched().

6
Documentation/RCU/whatisRCU.txt
View File

@ -833,9 +833,9 @@ sched: Critical sections Grace period Barrier
SRCU: Critical sections Grace period Barrier
srcu_read_lock synchronize_srcu N/A
srcu_read_unlock synchronize_srcu_expedited
srcu_read_lock_raw
srcu_read_lock synchronize_srcu srcu_barrier
srcu_read_unlock call_srcu
srcu_read_lock_raw synchronize_srcu_expedited
srcu_read_unlock_raw
srcu_dereference

2
Documentation/arm/Samsung-S3C24XX/H1940.txt
View File

@ -37,4 +37,4 @@ Maintainers
Thanks to the many others who have also provided support.
(c) 2005 Ben Dooks
(c) 2005 Ben Dooks

2
Documentation/arm/Samsung-S3C24XX/SMDK2440.txt
View File

@ -53,4 +53,4 @@ Maintainers
and to Simtec Electronics for allowing me time to work on this.
(c) 2004 Ben Dooks
(c) 2004 Ben Dooks

7
Documentation/block/queue-sysfs.txt
View File

@ -38,6 +38,13 @@ read or write requests. Note that the total allocated number may be twice
this amount, since it applies only to reads or writes (not the accumulated
sum).
To avoid priority inversion through request starvation, a request
queue maintains a separate request pool per each cgroup when
CONFIG_BLK_CGROUP is enabled, and this parameter applies to each such
per-block-cgroup request pool. IOW, if there are N block cgroups,
each request queue may have upto N request pools, each independently
regulated by nr_requests.
read_ahead_kb (RW)
------------------
Maximum number of kilobytes to read-ahead for filesystems on this block

27
Documentation/cgroups/cgroups.txt
View File

@ -370,15 +370,12 @@ To mount a cgroup hierarchy with just the cpuset and memory
subsystems, type:
# mount -t cgroup -o cpuset,memory hier1 /sys/fs/cgroup/rg1
To change the set of subsystems bound to a mounted hierarchy, just
remount with different options:
# mount -o remount,cpuset,blkio hier1 /sys/fs/cgroup/rg1
Now memory is removed from the hierarchy and blkio is added.
Note this will add blkio to the hierarchy but won't remove memory or
cpuset, because the new options are appended to the old ones:
# mount -o remount,blkio /sys/fs/cgroup/rg1
While remounting cgroups is currently supported, it is not recommend
to use it. Remounting allows changing bound subsystems and
release_agent. Rebinding is hardly useful as it only works when the
hierarchy is empty and release_agent itself should be replaced with
conventional fsnotify. The support for remounting will be removed in
the future.
To Specify a hierarchy's release_agent:
# mount -t cgroup -o cpuset,release_agent="/sbin/cpuset_release_agent" \
@ -637,16 +634,6 @@ void exit(struct task_struct *task)
Called during task exit.
int populate(struct cgroup *cgrp)
(cgroup_mutex held by caller)
Called after creation of a cgroup to allow a subsystem to populate
the cgroup directory with file entries. The subsystem should make
calls to cgroup_add_file() with objects of type cftype (see
include/linux/cgroup.h for details). Note that although this
method can return an error code, the error code is currently not
always handled well.
void post_clone(struct cgroup *cgrp)
(cgroup_mutex held by caller)
@ -656,7 +643,7 @@ example in cpusets, no task may attach before 'cpus' and 'mems' are set
up.
void bind(struct cgroup *root)
(cgroup_mutex and ss->hierarchy_mutex held by caller)
(cgroup_mutex held by caller)
Called when a cgroup subsystem is rebound to a different hierarchy
and root cgroup. Currently this will only involve movement between

45
Documentation/cgroups/hugetlb.txt Normal file
View File

@ -0,0 +1,45 @@
HugeTLB Controller
-------------------
The HugeTLB controller allows to limit the HugeTLB usage per control group and
enforces the controller limit during page fault. Since HugeTLB doesn't
support page reclaim, enforcing the limit at page fault time implies that,
the application will get SIGBUS signal if it tries to access HugeTLB pages
beyond its limit. This requires the application to know beforehand how much
HugeTLB pages it would require for its use.
HugeTLB controller can be created by first mounting the cgroup filesystem.
# mount -t cgroup -o hugetlb none /sys/fs/cgroup
With the above step, the initial or the parent HugeTLB group becomes
visible at /sys/fs/cgroup. At bootup, this group includes all the tasks in
the system. /sys/fs/cgroup/tasks lists the tasks in this cgroup.
New groups can be created under the parent group /sys/fs/cgroup.
# cd /sys/fs/cgroup
# mkdir g1
# echo $$ > g1/tasks
The above steps create a new group g1 and move the current shell
process (bash) into it.
Brief summary of control files
hugetlb.<hugepagesize>.limit_in_bytes # set/show limit of "hugepagesize" hugetlb usage
hugetlb.<hugepagesize>.max_usage_in_bytes # show max "hugepagesize" hugetlb usage recorded
hugetlb.<hugepagesize>.usage_in_bytes # show current res_counter usage for "hugepagesize" hugetlb
hugetlb.<hugepagesize>.failcnt # show the number of allocation failure due to HugeTLB limit
For a system supporting two hugepage size (16M and 16G) the control
files include:
hugetlb.16GB.limit_in_bytes
hugetlb.16GB.max_usage_in_bytes
hugetlb.16GB.usage_in_bytes
hugetlb.16GB.failcnt
hugetlb.16MB.limit_in_bytes
hugetlb.16MB.max_usage_in_bytes
hugetlb.16MB.usage_in_bytes
hugetlb.16MB.failcnt

12
Documentation/cgroups/memory.txt
View File

@ -73,6 +73,8 @@ Brief summary of control files.
memory.kmem.tcp.limit_in_bytes # set/show hard limit for tcp buf memory
memory.kmem.tcp.usage_in_bytes # show current tcp buf memory allocation
memory.kmem.tcp.failcnt # show the number of tcp buf memory usage hits limits
memory.kmem.tcp.max_usage_in_bytes # show max tcp buf memory usage recorded
1. History
@ -187,12 +189,12 @@ the cgroup that brought it in -- this will happen on memory pressure).
But see section 8.2: when moving a task to another cgroup, its pages may
be recharged to the new cgroup, if move_charge_at_immigrate has been chosen.
Exception: If CONFIG_CGROUP_CGROUP_MEM_RES_CTLR_SWAP is not used.
Exception: If CONFIG_CGROUP_CGROUP_MEMCG_SWAP is not used.
When you do swapoff and make swapped-out pages of shmem(tmpfs) to
be backed into memory in force, charges for pages are accounted against the
caller of swapoff rather than the users of shmem.
2.4 Swap Extension (CONFIG_CGROUP_MEM_RES_CTLR_SWAP)
2.4 Swap Extension (CONFIG_MEMCG_SWAP)
Swap Extension allows you to record charge for swap. A swapped-in page is
charged back to original page allocator if possible.
@ -259,7 +261,7 @@ When oom event notifier is registered, event will be delivered.
per-zone-per-cgroup LRU (cgroup's private LRU) is just guarded by
zone->lru_lock, it has no lock of its own.
2.7 Kernel Memory Extension (CONFIG_CGROUP_MEM_RES_CTLR_KMEM)
2.7 Kernel Memory Extension (CONFIG_MEMCG_KMEM)
With the Kernel memory extension, the Memory Controller is able to limit
the amount of kernel memory used by the system. Kernel memory is fundamentally
@ -286,8 +288,8 @@ per cgroup, instead of globally.
a. Enable CONFIG_CGROUPS
b. Enable CONFIG_RESOURCE_COUNTERS
c. Enable CONFIG_CGROUP_MEM_RES_CTLR
d. Enable CONFIG_CGROUP_MEM_RES_CTLR_SWAP (to use swap extension)
c. Enable CONFIG_MEMCG
d. Enable CONFIG_MEMCG_SWAP (to use swap extension)
1. Prepare the cgroups (see cgroups.txt, Why are cgroups needed?)
# mount -t tmpfs none /sys/fs/cgroup

13
Documentation/connector/cn_test.c
View File

@ -69,9 +69,13 @@ static int cn_test_want_notify(void)
return -ENOMEM;
}
nlh = NLMSG_PUT(skb, 0, 0x123, NLMSG_DONE, size - sizeof(*nlh));
nlh = nlmsg_put(skb, 0, 0x123, NLMSG_DONE, size - sizeof(*nlh), 0);
if (!nlh) {
kfree_skb(skb);
return -EMSGSIZE;
}
msg = (struct cn_msg *)NLMSG_DATA(nlh);
msg = nlmsg_data(nlh);
memset(msg, 0, size0);
@ -117,11 +121,6 @@ static int cn_test_want_notify(void)
pr_info("request was sent: group=0x%x\n", ctl->group);
return 0;
nlmsg_failure:
pr_err("failed to send %u.%u\n", msg->seq, msg->ack);
kfree_skb(skb);
return -EINVAL;
}
#endif

26
Documentation/device-mapper/dm-raid.txt
View File

@ -27,6 +27,10 @@ The target is named "raid" and it accepts the following parameters:
- rotating parity N (right-to-left) with data restart
raid6_nc RAID6 N continue
- rotating parity N (right-to-left) with data continuation
raid10 Various RAID10 inspired algorithms chosen by additional params
- RAID10: Striped Mirrors (aka 'Striping on top of mirrors')
- RAID1E: Integrated Adjacent Stripe Mirroring
- and other similar RAID10 variants
Reference: Chapter 4 of
http://www.snia.org/sites/default/files/SNIA_DDF_Technical_Position_v2.0.pdf
@ -59,6 +63,28 @@ The target is named "raid" and it accepts the following parameters:
logical size of the array. The bitmap records the device
synchronisation state for each region.
[raid10_copies <# copies>]
[raid10_format near]
These two options are used to alter the default layout of
a RAID10 configuration. The number of copies is can be
specified, but the default is 2. There are other variations
to how the copies are laid down - the default and only current
option is "near". Near copies are what most people think of
with respect to mirroring. If these options are left
unspecified, or 'raid10_copies 2' and/or 'raid10_format near'
are given, then the layouts for 2, 3 and 4 devices are:
2 drives 3 drives 4 drives
-------- ---------- --------------
A1 A1 A1 A1 A2 A1 A1 A2 A2
A2 A2 A2 A3 A3 A3 A3 A4 A4
A3 A3 A4 A4 A5 A5 A5 A6 A6
A4 A4 A5 A6 A6 A7 A7 A8 A8
.. .. .. .. .. .. .. .. ..
The 2-device layout is equivalent 2-way RAID1. The 4-device
layout is what a traditional RAID10 would look like. The
3-device layout is what might be called a 'RAID1E - Integrated
Adjacent Stripe Mirroring'.
<#raid_devs>: The number of devices composing the array.
Each device consists of two entries. The first is the device
containing the metadata (if any); the second is the one containing the

7
Documentation/device-mapper/striped.txt
View File

@ -9,15 +9,14 @@ devices in parallel.
Parameters: <num devs> <chunk size> [<dev path> <offset>]+
<num devs>: Number of underlying devices.
<chunk size>: Size of each chunk of data. Must be a power-of-2 and at
least as large as the system's PAGE_SIZE.
<chunk size>: Size of each chunk of data. Must be at least as
large as the system's PAGE_SIZE.
<dev path>: Full pathname to the underlying block-device, or a
"major:minor" device-number.
<offset>: Starting sector within the device.
One or more underlying devices can be specified. The striped device size must
be a multiple of the chunk size and a multiple of the number of underlying
devices.
be a multiple of the chunk size multiplied by the number of underlying devices.
Example scripts

24
Documentation/device-mapper/thin-provisioning.txt
View File

@ -231,6 +231,9 @@ i) Constructor
no_discard_passdown: Don't pass discards down to the underlying
data device, but just remove the mapping.
read_only: Don't allow any changes to be made to the pool
metadata.
Data block size must be between 64KB (128 sectors) and 1GB
(2097152 sectors) inclusive.
@ -239,7 +242,7 @@ ii) Status
<transaction id> <used metadata blocks>/<total metadata blocks>
<used data blocks>/<total data blocks> <held metadata root>
[no_]discard_passdown ro|rw
transaction id:
A 64-bit number used by userspace to help synchronise with metadata
@ -257,6 +260,21 @@ ii) Status
held root. This feature is not yet implemented so '-' is
always returned.
discard_passdown|no_discard_passdown
Whether or not discards are actually being passed down to the
underlying device. When this is enabled when loading the table,
it can get disabled if the underlying device doesn't support it.
ro|rw
If the pool encounters certain types of device failures it will
drop into a read-only metadata mode in which no changes to
the pool metadata (like allocating new blocks) are permitted.
In serious cases where even a read-only mode is deemed unsafe
no further I/O will be permitted and the status will just
contain the string 'Fail'. The userspace recovery tools
should then be used.
iii) Messages
create_thin <dev id>
@ -329,3 +347,7 @@ regain some space then send the 'trim' message to the pool.
ii) Status
<nr mapped sectors> <highest mapped sector>
If the pool has encountered device errors and failed, the status
will just contain the string 'Fail'. The userspace recovery
tools should then be used.

129
Documentation/device-mapper/verity.txt
View File

@ -7,39 +7,39 @@ This target is read-only.
Construction Parameters
=======================
<version> <dev> <hash_dev> <hash_start>
<version> <dev> <hash_dev>
<data_block_size> <hash_block_size>
<num_data_blocks> <hash_start_block>
<algorithm> <digest> <salt>
<version>
This is the version number of the on-disk format.
This is the type of the on-disk hash format.
0 is the original format used in the Chromium OS.
The salt is appended when hashing, digests are stored continuously and
the rest of the block is padded with zeros.
The salt is appended when hashing, digests are stored continuously and
the rest of the block is padded with zeros.
1 is the current format that should be used for new devices.
The salt is prepended when hashing and each digest is
padded with zeros to the power of two.
The salt is prepended when hashing and each digest is
padded with zeros to the power of two.
<dev>
This is the device containing the data the integrity of which needs to be
This is the device containing data, the integrity of which needs to be
checked. It may be specified as a path, like /dev/sdaX, or a device number,
<major>:<minor>.
<hash_dev>
This is the device that that supplies the hash tree data. It may be
This is the device that supplies the hash tree data. It may be
specified similarly to the device path and may be the same device. If the
same device is used, the hash_start should be outside of the dm-verity
configured device size.
same device is used, the hash_start should be outside the configured
dm-verity device.
<data_block_size>
The block size on a data device. Each block corresponds to one digest on
the hash device.
The block size on a data device in bytes.
Each block corresponds to one digest on the hash device.
<hash_block_size>
The size of a hash block.
The size of a hash block in bytes.
<num_data_blocks>
The number of data blocks on the data device. Additional blocks are
@ -65,7 +65,7 @@ Construction Parameters
Theory of operation
===================
dm-verity is meant to be setup as part of a verified boot path. This
dm-verity is meant to be set up as part of a verified boot path. This
may be anything ranging from a boot using tboot or trustedgrub to just
booting from a known-good device (like a USB drive or CD).
@ -73,20 +73,20 @@ When a dm-verity device is configured, it is expected that the caller
has been authenticated in some way (cryptographic signatures, etc).
After instantiation, all hashes will be verified on-demand during
disk access. If they cannot be verified up to the root node of the
tree, the root hash, then the I/O will fail. This should identify
tree, the root hash, then the I/O will fail. This should detect
tampering with any data on the device and the hash data.
Cryptographic hashes are used to assert the integrity of the device on a
per-block basis. This allows for a lightweight hash computation on first read
into the page cache. Block hashes are stored linearly-aligned to the nearest
block the size of a page.
per-block basis. This allows for a lightweight hash computation on first read
into the page cache. Block hashes are stored linearly, aligned to the nearest
block size.
Hash Tree
---------
Each node in the tree is a cryptographic hash. If it is a leaf node, the hash
is of some block data on disk. If it is an intermediary node, then the hash is
of a number of child nodes.
of some data block on disk is calculated. If it is an intermediary node,
the hash of a number of child nodes is calculated.
Each entry in the tree is a collection of neighboring nodes that fit in one
block. The number is determined based on block_size and the size of the
@ -110,63 +110,23 @@ alg = sha256, num_blocks = 32768, block_size = 4096
On-disk format
==============
Below is the recommended on-disk format. The verity kernel code does not
read the on-disk header. It only reads the hash blocks which directly
follow the header. It is expected that a user-space tool will verify the
integrity of the verity_header and then call dmsetup with the correct
parameters. Alternatively, the header can be omitted and the dmsetup
parameters can be passed via the kernel command-line in a rooted chain
of trust where the command-line is verified.
The verity kernel code does not read the verity metadata on-disk header.
It only reads the hash blocks which directly follow the header.
It is expected that a user-space tool will verify the integrity of the
verity header.
The on-disk format is especially useful in cases where the hash blocks
are on a separate partition. The magic number allows easy identification
of the partition contents. Alternatively, the hash blocks can be stored
in the same partition as the data to be verified. In such a configuration
the filesystem on the partition would be sized a little smaller than
the full-partition, leaving room for the hash blocks.
struct superblock {
uint8_t signature[8]
"verity\0\0";
uint8_t version;
1 - current format
uint8_t data_block_bits;
log2(data block size)
uint8_t hash_block_bits;
log2(hash block size)
uint8_t pad1[1];
zero padding
uint16_t salt_size;
big-endian salt size
uint8_t pad2[2];
zero padding
uint32_t data_blocks_hi;
big-endian high 32 bits of the 64-bit number of data blocks
uint32_t data_blocks_lo;
big-endian low 32 bits of the 64-bit number of data blocks
uint8_t algorithm[16];
cryptographic algorithm
uint8_t salt[384];
salt (the salt size is specified above)
uint8_t pad3[88];
zero padding to 512-byte boundary
}
Alternatively, the header can be omitted and the dmsetup parameters can
be passed via the kernel command-line in a rooted chain of trust where
the command-line is verified.
Directly following the header (and with sector number padded to the next hash
block boundary) are the hash blocks which are stored a depth at a time
(starting from the root), sorted in order of increasing index.
The full specification of kernel parameters and on-disk metadata format
is available at the cryptsetup project's wiki page
http://code.google.com/p/cryptsetup/wiki/DMVerity
Status
======
V (for Valid) is returned if every check performed so far was valid.
@ -174,21 +134,22 @@ If any check failed, C (for Corruption) is returned.
Example
=======
Setup a device:
dmsetup create vroot --table \
"0 2097152 "\
"verity 1 /dev/sda1 /dev/sda2 4096 4096 2097152 1 "\
Set up a device:
# dmsetup create vroot --readonly --table \
"0 2097152 verity 1 /dev/sda1 /dev/sda2 4096 4096 262144 1 sha256 "\
"4392712ba01368efdf14b05c76f9e4df0d53664630b5d48632ed17a137f39076 "\
"1234000000000000000000000000000000000000000000000000000000000000"
A command line tool veritysetup is available to compute or verify
the hash tree or activate the kernel driver. This is available from
the LVM2 upstream repository and may be supplied as a package called
device-mapper-verity-tools:
git://sources.redhat.com/git/lvm2
http://sourceware.org/git/?p=lvm2.git
http://sourceware.org/cgi-bin/cvsweb.cgi/LVM2/verity?cvsroot=lvm2
the hash tree or activate the kernel device. This is available from
the cryptsetup upstream repository http://code.google.com/p/cryptsetup/
(as a libcryptsetup extension).
veritysetup -a vroot /dev/sda1 /dev/sda2 \
4392712ba01368efdf14b05c76f9e4df0d53664630b5d48632ed17a137f39076
Create hash on the device:
# veritysetup format /dev/sda1 /dev/sda2
...
Root hash: 4392712ba01368efdf14b05c76f9e4df0d53664630b5d48632ed17a137f39076
Activate the device:
# veritysetup create vroot /dev/sda1 /dev/sda2 \
4392712ba01368efdf14b05c76f9e4df0d53664630b5d48632ed17a137f39076

2
Documentation/devices.txt
View File

@ -2416,6 +2416,8 @@ Your cooperation is appreciated.
1 = /dev/raw/raw1 First raw I/O device
2 = /dev/raw/raw2 Second raw I/O device
...
max minor number of raw device is set by kernel config
MAX_RAW_DEVS or raw module parameter 'max_raw_devs'
163 char

23
Documentation/devicetree/bindings/arm/armada-370-xp-mpic.txt Normal file
View File

@ -0,0 +1,23 @@
Marvell Armada 370 and Armada XP Interrupt Controller
-----------------------------------------------------
Required properties:
- compatible: Should be "marvell,mpic"
- interrupt-controller: Identifies the node as an interrupt controller.
- #interrupt-cells: The number of cells to define the interrupts. Should be 1.
The cell is the IRQ number
- reg: Should contain PMIC registers location and length. First pair
for the main interrupt registers, second pair for the per-CPU
interrupt registers
Example:
mpic: interrupt-controller@d0020000 {
compatible = "marvell,mpic";
#interrupt-cells = <1>;
#address-cells = <1>;
#size-cells = <1>;
interrupt-controller;
reg = <0xd0020000 0x1000>,
<0xd0021000 0x1000>;
};

11
Documentation/devicetree/bindings/arm/armada-370-xp-timer.txt Normal file
View File

@ -0,0 +1,11 @@
Marvell Armada 370 and Armada XP Global Timers
----------------------------------------------
Required properties:
- compatible: Should be "marvell,armada-370-xp-timer"
- interrupts: Should contain the list of Global Timer interrupts
- reg: Should contain the base address of the Global Timer registers
Optional properties:
- marvell,timer-25Mhz: Tells whether the Global timer supports the 25
Mhz fixed mode (available on Armada XP and not on Armada 370)

24
Documentation/devicetree/bindings/arm/armada-370-xp.txt Normal file
View File

@ -0,0 +1,24 @@
Marvell Armada 370 and Armada XP Platforms Device Tree Bindings
---------------------------------------------------------------
Boards with a SoC of the Marvell Armada 370 and Armada XP families
shall have the following property:
Required root node property:
compatible: must contain "marvell,armada-370-xp"
In addition, boards using the Marvell Armada 370 SoC shall have the
following property:
Required root node property:
compatible: must contain "marvell,armada370"
In addition, boards using the Marvell Armada XP SoC shall have the
following property:
Required root node property:
compatible: must contain "marvell,armadaxp"

9
Documentation/devicetree/bindings/arm/atmel-aic.txt
View File

@ -4,7 +4,7 @@ Required properties:
- compatible: Should be "atmel,<chip>-aic"
- interrupt-controller: Identifies the node as an interrupt controller.
- interrupt-parent: For single AIC system, it is an empty property.
- #interrupt-cells: The number of cells to define the interrupts. It sould be 2.
- #interrupt-cells: The number of cells to define the interrupts. It sould be 3.
The first cell is the IRQ number (aka "Peripheral IDentifier" on datasheet).
The second cell is used to specify flags:
bits[3:0] trigger type and level flags:
@ -14,7 +14,10 @@ Required properties:
8 = active low level-sensitive.
Valid combinations are 1, 2, 3, 4, 8.
Default flag for internal sources should be set to 4 (active high).
The third cell is used to specify the irq priority from 0 (lowest) to 7
(highest).
- reg: Should contain AIC registers location and length
- atmel,external-irqs: u32 array of external irqs.
Examples:
/*
@ -24,7 +27,7 @@ Examples:
compatible = "atmel,at91rm9200-aic";
interrupt-controller;
interrupt-parent;
#interrupt-cells = <2>;
#interrupt-cells = <3>;
reg = <0xfffff000 0x200>;
};
@ -34,5 +37,5 @@ Examples:
dma: dma-controller@ffffec00 {
compatible = "atmel,at91sam9g45-dma";
reg = <0xffffec00 0x200>;
interrupts = <21 4>;
interrupts = <21 4 5>;
};

15
Documentation/devicetree/bindings/arm/calxeda/l2ecc.txt Normal file
View File

@ -0,0 +1,15 @@
Calxeda Highbank L2 cache ECC
Properties:
- compatible : Should be "calxeda,hb-sregs-l2-ecc"
- reg : Address and size for ECC error interrupt clear registers.
- interrupts : Should be single bit error interrupt, then double bit error
interrupt.
Example:
sregs@fff3c200 {
compatible = "calxeda,hb-sregs-l2-ecc";
reg = <0xfff3c200 0x100>;
interrupts = <0 71 4 0 72 4>;
};

14
Documentation/devicetree/bindings/arm/calxeda/mem-ctrlr.txt Normal file
View File

@ -0,0 +1,14 @@
Calxeda DDR memory controller
Properties:
- compatible : Should be "calxeda,hb-ddr-ctrl"
- reg : Address and size for DDR controller registers.
- interrupts : Interrupt for DDR controller.
Example:
memory-controller@fff00000 {
compatible = "calxeda,hb-ddr-ctrl";
reg = <0xfff00000 0x1000>;
interrupts = <0 91 4>;
};

27
Documentation/devicetree/bindings/arm/davinci/cp-intc.txt Normal file
View File

@ -0,0 +1,27 @@
* TI Common Platform Interrupt Controller
Common Platform Interrupt Controller (cp_intc) is used on
OMAP-L1x SoCs and can support several configurable number
of interrupts.
Main node required properties:
- compatible : should be:
"ti,cp-intc"
- interrupt-controller : Identifies the node as an interrupt controller
- #interrupt-cells : Specifies the number of cells needed to encode an
interrupt source. The type shall be a <u32> and the value shall be 1.
The cell contains the interrupt number in the range [0-128].
- ti,intc-size: Number of interrupts handled by the interrupt controller.
- reg: physical base address and size of the intc registers map.
Example:
intc: interrupt-controller@1 {
compatible = "ti,cp-intc";
interrupt-controller;
#interrupt-cells = <1>;
ti,intc-size = <101>;
reg = <0xfffee000 0x2000>;
};

20
Documentation/devicetree/bindings/arm/mrvl/intc.txt
View File

@ -38,3 +38,23 @@ Example:
reg-names = "mux status", "mux mask";
mrvl,intc-nr-irqs = <2>;
};
* Marvell Orion Interrupt controller
Required properties
- compatible : Should be "marvell,orion-intc".
- #interrupt-cells: Specifies the number of cells needed to encode an
interrupt source. Supported value is <1>.
- interrupt-controller : Declare this node to be an interrupt controller.
- reg : Interrupt mask address. A list of 4 byte ranges, one per controller.
One entry in the list represents 32 interrupts.
Example:
intc: interrupt-controller {
compatible = "marvell,orion-intc", "marvell,intc";
interrupt-controller;
#interrupt-cells = <1>;
reg = <0xfed20204 0x04>,
<0xfed20214 0x04>;
};

17
Documentation/devicetree/bindings/arm/mvebu-system-controller.txt Normal file
View File

@ -0,0 +1,17 @@
MVEBU System Controller
-----------------------
MVEBU (Marvell SOCs: Armada 370/XP, Dove, mv78xx0, Kirkwood, Orion5x)
Required properties:
- compatible: one of:
- "marvell,orion-system-controller"
- "marvell,armada-370-xp-system-controller"
- reg: Should contain system controller registers location and length.
Example:
system-controller@d0018200 {
compatible = "marvell,armada-370-xp-system-controller";
reg = <0xd0018200 0x500>;
};

6
Documentation/devicetree/bindings/arm/olimex.txt Normal file
View File

@ -0,0 +1,6 @@
Olimex i.MX Platforms Device Tree Bindings
------------------------------------------
i.MX23 Olinuxino Low Cost Board
Required root node properties:
- compatible = "olimex,imx23-olinuxino", "fsl,imx23";

6
Documentation/devicetree/bindings/arm/omap/omap.txt
View File

@ -47,3 +47,9 @@ Boards:
- AM335X EVM : Software Developement Board for AM335x
compatible = "ti,am335x-evm", "ti,am33xx", "ti,omap3"
- AM335X Bone : Low cost community board
compatible = "ti,am335x-bone", "ti,am33xx", "ti,omap3"
- OMAP5 EVM : Evaluation Module
compatible = "ti,omap5-evm", "ti,omap5"

6
Documentation/devicetree/bindings/arm/primecell.txt
View File

@ -13,11 +13,17 @@ Required properties:
Optional properties:
- arm,primecell-periphid : Value to override the h/w value with
- clocks : From common clock binding. First clock is phandle to clock for apb
pclk. Additional clocks are optional and specific to those peripherals.
- clock-names : From common clock binding. Shall be "apb_pclk" for first clock.
Example:
serial@fff36000 {
compatible = "arm,pl011", "arm,primecell";
arm,primecell-periphid = <0x00341011>;
clocks = <&pclk>;
clock-names = "apb_pclk";
};

2
Documentation/devicetree/bindings/arm/tegra/emc.txt → Documentation/devicetree/bindings/arm/tegra/nvidia,tegra20-emc.txt
View File

@ -15,7 +15,7 @@ Child device nodes describe the memory settings for different configurations and
Example:
emc@7000f400 {
memory-controller@7000f400 {
#address-cells = < 1 >;
#size-cells = < 0 >;
compatible = "nvidia,tegra20-emc";

2
Documentation/devicetree/bindings/arm/tegra/nvidia,tegra20-mc.txt
View File

@ -8,7 +8,7 @@ Required properties:
- interrupts : Should contain MC General interrupt.
Example:
mc {
memory-controller@0x7000f000 {
compatible = "nvidia,tegra20-mc";
reg = <0x7000f000 0x024
0x7000f03c 0x3c4>;

2
Documentation/devicetree/bindings/arm/tegra/nvidia,tegra30-mc.txt
View File

@ -8,7 +8,7 @@ Required properties:
- interrupts : Should contain MC General interrupt.
Example:
mc {
memory-controller {
compatible = "nvidia,tegra30-mc";
reg = <0x7000f000 0x010
0x7000f03c 0x1b4

30
Documentation/devicetree/bindings/ata/cavium-compact-flash.txt Normal file
View File

@ -0,0 +1,30 @@
* Compact Flash
The Cavium Compact Flash device is connected to the Octeon Boot Bus,
and is thus a child of the Boot Bus device. It can read and write
industry standard compact flash devices.
Properties:
- compatible: "cavium,ebt3000-compact-flash";
Compatibility with many Cavium evaluation boards.
- reg: The base address of the the CF chip select banks. Depending on
the device configuration, there may be one or two banks.
- cavium,bus-width: The width of the connection to the CF devices. Valid
values are 8 and 16.
- cavium,true-ide: Optional, if present the CF connection is in True IDE mode.
- cavium,dma-engine-handle: Optional, a phandle for the DMA Engine connected
to this device.
Example:
compact-flash@5,0 {
compatible = "cavium,ebt3000-compact-flash";
reg = <5 0 0x10000>, <6 0 0x10000>;
cavium,bus-width = <16>;
cavium,true-ide;
cavium,dma-engine-handle = <&dma0>;
};

16
Documentation/devicetree/bindings/ata/marvell.txt Normal file
View File

@ -0,0 +1,16 @@
* Marvell Orion SATA
Required Properties:
- compatibility : "marvell,orion-sata"
- reg : Address range of controller
- interrupts : Interrupt controller is using
- nr-ports : Number of SATA ports in use.
Example:
sata@80000 {
compatible = "marvell,orion-sata";
reg = <0x80000 0x5000>;
interrupts = <21>;
nr-ports = <2>;
}

17
Documentation/devicetree/bindings/clock/calxeda.txt Normal file
View File

@ -0,0 +1,17 @@
Device Tree Clock bindings for Calxeda highbank platform
This binding uses the common clock binding[1].
[1] Documentation/devicetree/bindings/clock/clock-bindings.txt
Required properties:
- compatible : shall be one of the following:
"calxeda,hb-pll-clock" - for a PLL clock
"calxeda,hb-a9periph-clock" - The A9 peripheral clock divided from the
A9 clock.
"calxeda,hb-a9bus-clock" - The A9 bus clock divided from the A9 clock.
"calxeda,hb-emmc-clock" - Divided clock for MMC/SD controller.
- reg : shall be the control register offset from SYSREGs base for the clock.
- clocks : shall be the input parent clock phandle for the clock. This is
either an oscillator or a pll output.
- #clock-cells : from common clock binding; shall be set to 0.

117
Documentation/devicetree/bindings/clock/clock-bindings.txt Normal file
View File

@ -0,0 +1,117 @@
This binding is a work-in-progress, and are based on some experimental
work by benh[1].
Sources of clock signal can be represented by any node in the device
tree. Those nodes are designated as clock providers. Clock consumer
nodes use a phandle and clock specifier pair to connect clock provider
outputs to clock inputs. Similar to the gpio specifiers, a clock
specifier is an array of one more more cells identifying the clock
output on a device. The length of a clock specifier is defined by the
value of a #clock-cells property in the clock provider node.
[1] http://patchwork.ozlabs.org/patch/31551/
==Clock providers==
Required properties:
#clock-cells: Number of cells in a clock specifier; Typically 0 for nodes
with a single clock output and 1 for nodes with multiple
clock outputs.
Optional properties:
clock-output-names: Recommended to be a list of strings of clock output signal
names indexed by the first cell in the clock specifier.
However, the meaning of clock-output-names is domain
specific to the clock provider, and is only provided to
encourage using the same meaning for the majority of clock
providers. This format may not work for clock providers
using a complex clock specifier format. In those cases it
is recommended to omit this property and create a binding
specific names property.
Clock consumer nodes must never directly reference
the provider's clock-output-names property.
For example:
oscillator {
#clock-cells = <1>;
clock-output-names = "ckil", "ckih";
};
- this node defines a device with two clock outputs, the first named
"ckil" and the second named "ckih". Consumer nodes always reference
clocks by index. The names should reflect the clock output signal
names for the device.
==Clock consumers==
Required properties:
clocks: List of phandle and clock specifier pairs, one pair
for each clock input to the device. Note: if the
clock provider specifies '0' for #clock-cells, then
only the phandle portion of the pair will appear.
Optional properties:
clock-names: List of clock input name strings sorted in the same
order as the clocks property. Consumers drivers
will use clock-names to match clock input names
with clocks specifiers.
clock-ranges: Empty property indicating that child nodes can inherit named
clocks from this node. Useful for bus nodes to provide a
clock to their children.
For example:
device {
clocks = <&osc 1>, <&ref 0>;
clock-names = "baud", "register";
};
This represents a device with two clock inputs, named "baud" and "register".
The baud clock is connected to output 1 of the &osc device, and the register
clock is connected to output 0 of the &ref.
==Example==
/* external oscillator */
osc: oscillator {
compatible = "fixed-clock";
#clock-cells = <1>;
clock-frequency = <32678>;
clock-output-names = "osc";
};
/* phase-locked-loop device, generates a higher frequency clock
* from the external oscillator reference */
pll: pll@4c000 {
compatible = "vendor,some-pll-interface"
#clock-cells = <1>;
clocks = <&osc 0>;
clock-names = "ref";
reg = <0x4c000 0x1000>;
clock-output-names = "pll", "pll-switched";
};
/* UART, using the low frequency oscillator for the baud clock,
* and the high frequency switched PLL output for register
* clocking */
uart@a000 {
compatible = "fsl,imx-uart";
reg = <0xa000 0x1000>;
interrupts = <33>;
clocks = <&osc 0>, <&pll 1>;
clock-names = "baud", "register";
};
This DT fragment defines three devices: an external oscillator to provide a
low-frequency reference clock, a PLL device to generate a higher frequency
clock signal, and a UART.
* The oscillator is fixed-frequency, and provides one clock output, named "osc".
* The PLL is both a clock provider and a clock consumer. It uses the clock
signal generated by the external oscillator, and provides two output signals
("pll" and "pll-switched").
* The UART has its baud clock connected the external oscillator and its
register clock connected to the PLL clock (the "pll-switched" signal)

21
Documentation/devicetree/bindings/clock/fixed-clock.txt Normal file
View File

@ -0,0 +1,21 @@
Binding for simple fixed-rate clock sources.
This binding uses the common clock binding[1].
[1] Documentation/devicetree/bindings/clock/clock-bindings.txt
Required properties:
- compatible : shall be "fixed-clock".
- #clock-cells : from common clock binding; shall be set to 0.
- clock-frequency : frequency of clock in Hz. Should be a single cell.
Optional properties:
- gpios : From common gpio binding; gpio connection to clock enable pin.
- clock-output-names : From common clock binding.
Example:
clock {
compatible = "fixed-clock";
#clock-cells = <0>;
clock-frequency = <1000000000>;
};

19
Documentation/devicetree/bindings/fb/mxsfb.txt Normal file
View File

@ -0,0 +1,19 @@
* Freescale MXS LCD Interface (LCDIF)
Required properties:
- compatible: Should be "fsl,<chip>-lcdif". Supported chips include
imx23 and imx28.
- reg: Address and length of the register set for lcdif
- interrupts: Should contain lcdif interrupts
Optional properties:
- panel-enable-gpios : Should specify the gpio for panel enable
Examples:
lcdif@80030000 {
compatible = "fsl,imx28-lcdif";
reg = <0x80030000 2000>;
interrupts = <38 86>;
panel-enable-gpios = <&gpio3 30 0>;
};

49
Documentation/devicetree/bindings/gpio/cavium-octeon-gpio.txt Normal file
View File

@ -0,0 +1,49 @@
* General Purpose Input Output (GPIO) bus.
Properties:
- compatible: "cavium,octeon-3860-gpio"
Compatibility with all cn3XXX, cn5XXX and cn6XXX SOCs.
- reg: The base address of the GPIO unit's register bank.
- gpio-controller: This is a GPIO controller.
- #gpio-cells: Must be <2>. The first cell is the GPIO pin.
- interrupt-controller: The GPIO controller is also an interrupt
controller, many of its pins may be configured as an interrupt
source.
- #interrupt-cells: Must be <2>. The first cell is the GPIO pin
connected to the interrupt source. The second cell is the interrupt
triggering protocol and may have one of four values:
1 - edge triggered on the rising edge.
2 - edge triggered on the falling edge
4 - level triggered active high.
8 - level triggered active low.
- interrupts: Interrupt routing for each pin.
Example:
gpio-controller@1070000000800 {
#gpio-cells = <2>;
compatible = "cavium,octeon-3860-gpio";
reg = <0x10700 0x00000800 0x0 0x100>;
gpio-controller;
/* Interrupts are specified by two parts:
* 1) GPIO pin number (0..15)
* 2) Triggering (1 - edge rising
* 2 - edge falling
* 4 - level active high
* 8 - level active low)
*/
interrupt-controller;
#interrupt-cells = <2>;
/* The GPIO pin connect to 16 consecutive CUI bits */
interrupts = <0 16>, <0 17>, <0 18>, <0 19>,
<0 20>, <0 21>, <0 22>, <0 23>,
<0 24>, <0 25>, <0 26>, <0 27>,
<0 28>, <0 29>, <0 30>, <0 31>;
};

16
Documentation/devicetree/bindings/gpio/fsl-imx-gpio.txt
View File

@ -8,15 +8,25 @@ Required properties:
by low 16 pins and the second one is for high 16 pins.
- gpio-controller : Marks the device node as a gpio controller.
- #gpio-cells : Should be two. The first cell is the pin number and
the second cell is used to specify optional parameters (currently
unused).
the second cell is used to specify the gpio polarity:
0 = active high
1 = active low
- interrupt-controller: Marks the device node as an interrupt controller.
- #interrupt-cells : Should be 2. The first cell is the GPIO number.
The second cell bits[3:0] is used to specify trigger type and level flags:
1 = low-to-high edge triggered.
2 = high-to-low edge triggered.
4 = active high level-sensitive.
8 = active low level-sensitive.
Example:
gpio0: gpio@73f84000 {
compatible = "fsl,imx51-gpio", "fsl,imx31-gpio";
compatible = "fsl,imx51-gpio", "fsl,imx35-gpio";
reg = <0x73f84000 0x4000>;
interrupts = <50 51>;
gpio-controller;
#gpio-cells = <2>;
interrupt-controller;
#interrupt-cells = <2>;
};

5
Documentation/devicetree/bindings/gpio/gpio-mxs.txt
View File

@ -13,8 +13,9 @@ Required properties for GPIO node:
- interrupts : Should be the port interrupt shared by all 32 pins.
- gpio-controller : Marks the device node as a gpio controller.
- #gpio-cells : Should be two. The first cell is the pin number and
the second cell is used to specify optional parameters (currently
unused).
the second cell is used to specify the gpio polarity:
0 = active high
1 = active low
- interrupt-controller: Marks the device node as an interrupt controller.
- #interrupt-cells : Should be 2. The first cell is the GPIO number.
The second cell bits[3:0] is used to specify trigger type and level flags:

2
Documentation/devicetree/bindings/gpio/gpio-nmk.txt
View File

@ -26,6 +26,6 @@ Example:
#gpio-cells = <2>;
gpio-controller;
interrupt-controller;
supports-sleepmode;
st,supports-sleepmode;
gpio-bank = <1>;
};

9
Documentation/devicetree/bindings/gpio/gpio-samsung.txt
View File

@ -11,14 +11,15 @@ Required properties:
<[phandle of the gpio controller node]
[pin number within the gpio controller]
[mux function]
[pull up/down]
[flags and pull up/down]
[drive strength]>
Values for gpio specifier:
- Pin number: is a value between 0 to 7.
- Pull Up/Down: 0 - Pull Up/Down Disabled.
1 - Pull Down Enabled.
3 - Pull Up Enabled.
- Flags and Pull Up/Down: 0 - Pull Up/Down Disabled.
1 - Pull Down Enabled.
3 - Pull Up Enabled.
Bit 16 (0x00010000) - Input is active low.
- Drive Strength: 0 - 1x,
1 - 3x,
2 - 2x,

2
Documentation/devicetree/bindings/gpio/led.txt
View File

@ -55,4 +55,4 @@ run-control {
gpios = <&mpc8572 7 0>;
default-state = "on";
};
}
};

23
Documentation/devicetree/bindings/gpio/mrvl-gpio.txt
View File

@ -27,3 +27,26 @@ Example:
interrupt-controller;
#interrupt-cells = <1>;
};
* Marvell Orion GPIO Controller
Required properties:
- compatible : Should be "marvell,orion-gpio"
- reg : Address and length of the register set for controller.
- gpio-controller : So we know this is a gpio controller.
- ngpio : How many gpios this controller has.
- interrupts : Up to 4 Interrupts for the controller.
Optional properties:
- mask-offset : For SMP Orions, offset for Nth CPU
Example:
gpio0: gpio@10100 {
compatible = "marvell,orion-gpio";
#gpio-cells = <2>;
gpio-controller;
reg = <0x10100 0x40>;
ngpio = <32>;
interrupts = <35>, <36>, <37>, <38>;
};

0
Documentation/devicetree/bindings/gpio/gpio_nvidia.txt → Documentation/devicetree/bindings/gpio/nvidia,tegra20-gpio.txt
View File

34
Documentation/devicetree/bindings/i2c/cavium-i2c.txt Normal file
View File

@ -0,0 +1,34 @@
* Two Wire Serial Interface (TWSI) / I2C
- compatible: "cavium,octeon-3860-twsi"
Compatibility with all cn3XXX, cn5XXX and cn6XXX SOCs.
- reg: The base address of the TWSI/I2C bus controller register bank.
- #address-cells: Must be <1>.
- #size-cells: Must be <0>. I2C addresses have no size component.
- interrupts: A single interrupt specifier.
- clock-frequency: The I2C bus clock rate in Hz.
Example:
twsi0: i2c@1180000001000 {
#address-cells = <1>;
#size-cells = <0>;
compatible = "cavium,octeon-3860-twsi";
reg = <0x11800 0x00001000 0x0 0x200>;
interrupts = <0 45>;
clock-frequency = <100000>;
rtc@68 {
compatible = "dallas,ds1337";
reg = <0x68>;
};
tmp@4c {
compatible = "ti,tmp421";
reg = <0x4c>;
};
};

0
Documentation/devicetree/bindings/gpio/gpio_i2c.txt → Documentation/devicetree/bindings/i2c/gpio-i2c.txt
View File

3
Documentation/devicetree/bindings/i2c/i2c-mxs.txt
View File

@ -4,6 +4,8 @@ Required properties:
- compatible: Should be "fsl,<chip>-i2c"
- reg: Should contain registers location and length
- interrupts: Should contain ERROR and DMA interrupts
- clock-frequency: Desired I2C bus clock frequency in Hz.
Only 100000Hz and 400000Hz modes are supported.
Examples:
@ -13,4 +15,5 @@ i2c0: i2c@80058000 {
compatible = "fsl,imx28-i2c";
reg = <0x80058000 2000>;
interrupts = <111 68>;
clock-frequency = <100000>;
};

33
Documentation/devicetree/bindings/i2c/i2c-ocores.txt Normal file
View File

@ -0,0 +1,33 @@
Device tree configuration for i2c-ocores
Required properties:
- compatible : "opencores,i2c-ocores"
- reg : bus address start and address range size of device
- interrupts : interrupt number
- clock-frequency : frequency of bus clock in Hz
- #address-cells : should be <1>
- #size-cells : should be <0>
Optional properties:
- reg-shift : device register offsets are shifted by this value
- reg-io-width : io register width in bytes (1, 2 or 4)
- regstep : deprecated, use reg-shift above
Example:
i2c0: ocores@a0000000 {
#address-cells = <1>;
#size-cells = <0>;
compatible = "opencores,i2c-ocores";
reg = <0xa0000000 0x8>;
interrupts = <10>;
clock-frequency = <20000000>;
reg-shift = <0>; /* 8 bit registers */
reg-io-width = <1>; /* 8 bit read/write */
dummy@60 {
compatible = "dummy";
reg = <0x60>;
};
};

19
Documentation/devicetree/bindings/i2c/mrvl-i2c.txt
View File

@ -1,4 +1,4 @@
* I2C
* Marvell MMP I2C controller
Required properties :
@ -32,3 +32,20 @@ Examples:
interrupts = <58>;
};
* Marvell MV64XXX I2C controller
Required properties :
- reg : Offset and length of the register set for the device
- compatible : Should be "marvell,mv64xxx-i2c"
- interrupts : The interrupt number
- clock-frequency : Desired I2C bus clock frequency in Hz.
Examples:
i2c@11000 {
compatible = "marvell,mv64xxx-i2c";
reg = <0x11000 0x20>;
interrupts = <29>;
clock-frequency = <100000>;
};

1
Documentation/devicetree/bindings/input/fsl-mma8450.txt
View File

@ -2,6 +2,7 @@
Required properties:
- compatible : "fsl,mma8450".
- reg: the I2C address of MMA8450
Example:

28
Documentation/devicetree/bindings/input/lpc32xx-key.txt Normal file
View File

@ -0,0 +1,28 @@
NXP LPC32xx Key Scan Interface
Required Properties:
- compatible: Should be "nxp,lpc3220-key"
- reg: Physical base address of the controller and length of memory mapped
region.
- interrupts: The interrupt number to the cpu.
- keypad,num-rows: Number of rows and columns, e.g. 1: 1x1, 6: 6x6
- keypad,num-columns: Must be equal to keypad,num-rows since LPC32xx only
supports square matrices
- nxp,debounce-delay-ms: Debounce delay in ms
- nxp,scan-delay-ms: Repeated scan period in ms
- linux,keymap: the key-code to be reported when the key is pressed
and released, see also
Documentation/devicetree/bindings/input/matrix-keymap.txt
Example:
key@40050000 {
compatible = "nxp,lpc3220-key";
reg = <0x40050000 0x1000>;
interrupts = <54 0>;
keypad,num-rows = <1>;
keypad,num-columns = <1>;
nxp,debounce-delay-ms = <3>;
nxp,scan-delay-ms = <34>;
linux,keymap = <0x00000002>;
};

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