leandrof/linux
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

Merge git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux

Browse Source
This commit is contained in:
David S. Miller 2016-03-19 21:05:24 -04:00
commit c78a85a843
6598 changed files with 361458 additions and 216040 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

1
CREDITS
View File

@ -3054,6 +3054,7 @@ D: PLX USB338x driver
D: PCA9634 driver
D: Option GTM671WFS
D: Fintek F81216A
D: AD5761 iio driver
D: Various kernel hacks
S: Qtechnology A/S
S: Valby Langgade 142

29
Documentation/ABI/obsolete/sysfs-class-rfkill
View File

@ -1,29 +0,0 @@
rfkill - radio frequency (RF) connector kill switch support
For details to this subsystem look at Documentation/rfkill.txt.
What: /sys/class/rfkill/rfkill[0-9]+/state
Date: 09-Jul-2007
KernelVersion v2.6.22
Contact: linux-wireless@vger.kernel.org
Description: Current state of the transmitter.
This file is deprecated and scheduled to be removed in 2014,
because its not possible to express the 'soft and hard block'
state of the rfkill driver.
Values: A numeric value.
0: RFKILL_STATE_SOFT_BLOCKED
transmitter is turned off by software
1: RFKILL_STATE_UNBLOCKED
transmitter is (potentially) active
2: RFKILL_STATE_HARD_BLOCKED
transmitter is forced off by something outside of
the driver's control.
What: /sys/class/rfkill/rfkill[0-9]+/claim
Date: 09-Jul-2007
KernelVersion v2.6.22
Contact: linux-wireless@vger.kernel.org
Description: This file is deprecated because there no longer is a way to
claim just control over a single rfkill instance.
This file is scheduled to be removed in 2012.
Values: 0: Kernel handles events

30
Documentation/ABI/obsolete/sysfs-gpio Normal file
View File

@ -0,0 +1,30 @@
What: /sys/class/gpio/
Date: July 2008
KernelVersion: 2.6.27
Contact: Linus Walleij <linusw@kernel.org>
Description:
As a Kconfig option, individual GPIO signals may be accessed from
userspace. GPIOs are only made available to userspace by an explicit
"export" operation. If a given GPIO is not claimed for use by
kernel code, it may be exported by userspace (and unexported later).
Kernel code may export it for complete or partial access.
GPIOs are identified as they are inside the kernel, using integers in
the range 0..INT_MAX. See Documentation/gpio.txt for more information.
/sys/class/gpio
/export ... asks the kernel to export a GPIO to userspace
/unexport ... to return a GPIO to the kernel
/gpioN ... for each exported GPIO #N OR
/<LINE-NAME> ... for a properly named GPIO line
/value ... always readable, writes fail for input GPIOs
/direction ... r/w as: in, out (default low); write: high, low
/edge ... r/w as: none, falling, rising, both
/gpiochipN ... for each gpiochip; #N is its first GPIO
/base ... (r/o) same as N
/label ... (r/o) descriptive, not necessarily unique
/ngpio ... (r/o) number of GPIOs; numbered N to N + (ngpio - 1)
This ABI is deprecated and will be removed after 2020. It is
replaced with the GPIO character device.

13
Documentation/ABI/removed/sysfs-class-rfkill Normal file
View File

@ -0,0 +1,13 @@
rfkill - radio frequency (RF) connector kill switch support
For details to this subsystem look at Documentation/rfkill.txt.
What: /sys/class/rfkill/rfkill[0-9]+/claim
Date: 09-Jul-2007
KernelVersion v2.6.22
Contact: linux-wireless@vger.kernel.org
Description: This file was deprecated because there no longer was a way to
claim just control over a single rfkill instance.
This file was scheduled to be removed in 2012, and was removed
in 2016.
Values: 0: Kernel handles events

14
Documentation/ABI/stable/sysfs-bus-vmbus
View File

@ -27,3 +27,17 @@ Description: The mapping of which primary/sub channels are bound to which
Virtual Processors.
Format: <channel's child_relid:the bound cpu's number>
Users: tools/hv/lsvmbus
What: /sys/bus/vmbus/devices/vmbus_*/device
Date: Dec. 2015
KernelVersion: 4.5
Contact: K. Y. Srinivasan <kys@microsoft.com>
Description: The 16 bit device ID of the device
Users: tools/hv/lsvmbus and user level RDMA libraries
What: /sys/bus/vmbus/devices/vmbus_*/vendor
Date: Dec. 2015
KernelVersion: 4.5
Contact: K. Y. Srinivasan <kys@microsoft.com>
Description: The 16 bit vendor ID of the device
Users: tools/hv/lsvmbus and user level RDMA libraries

27
Documentation/ABI/stable/sysfs-class-rfkill
View File

@ -2,9 +2,8 @@ rfkill - radio frequency (RF) connector kill switch support
For details to this subsystem look at Documentation/rfkill.txt.
For the deprecated /sys/class/rfkill/*/state and
/sys/class/rfkill/*/claim knobs of this interface look in
Documentation/ABI/obsolete/sysfs-class-rfkill.
For the deprecated /sys/class/rfkill/*/claim knobs of this interface look in
Documentation/ABI/removed/sysfs-class-rfkill.
What: /sys/class/rfkill
Date: 09-Jul-2007
@ -42,6 +41,28 @@ Values: A numeric value.
1: true
What: /sys/class/rfkill/rfkill[0-9]+/state
Date: 09-Jul-2007
KernelVersion v2.6.22
Contact: linux-wireless@vger.kernel.org
Description: Current state of the transmitter.
This file was scheduled to be removed in 2014, but due to its
large number of users it will be sticking around for a bit
longer. Despite it being marked as stabe, the newer "hard" and
"soft" interfaces should be preffered, since it is not possible
to express the 'soft and hard block' state of the rfkill driver
through this interface. There will likely be another attempt to
remove it in the future.
Values: A numeric value.
0: RFKILL_STATE_SOFT_BLOCKED
transmitter is turned off by software
1: RFKILL_STATE_UNBLOCKED
transmitter is (potentially) active
2: RFKILL_STATE_HARD_BLOCKED
transmitter is forced off by something outside of
the driver's control.
What: /sys/class/rfkill/rfkill[0-9]+/hard
Date: 12-March-2010
KernelVersion v2.6.34

26
Documentation/ABI/testing/gpio-cdev Normal file
View File

@ -0,0 +1,26 @@
What: /dev/gpiochip[0-9]+
Date: November 2015
KernelVersion: 4.4
Contact: linux-gpio@vger.kernel.org
Description:
The character device files /dev/gpiochip* are the interface
between GPIO chips and userspace.
The ioctl(2)-based ABI is defined and documented in
[include/uapi]<linux/gpio.h>.
The following file operations are supported:
open(2)
Currently the only useful flags are O_RDWR.
ioctl(2)
Initiate various actions.
See the inline documentation in [include/uapi]<linux/gpio.h>
for descriptions of all ioctls.
close(2)
Stops and free up the I/O contexts that was associated
with the file descriptor.
Users: TBD

1
Documentation/ABI/testing/ima_policy
View File

@ -27,6 +27,7 @@ Description:
base: func:= [BPRM_CHECK][MMAP_CHECK][FILE_CHECK][MODULE_CHECK]
[FIRMWARE_CHECK]
[KEXEC_KERNEL_CHECK] [KEXEC_INITRAMFS_CHECK]
mask:= [[^]MAY_READ] [[^]MAY_WRITE] [[^]MAY_APPEND]
[[^]MAY_EXEC]
fsmagic:= hex value

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

@ -496,8 +496,11 @@ Description:
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,
90kohm_to_gnd: connected to ground via a 90kOhm resistor,
100kohm_to_gnd: connected to ground via an 100kOhm resistor,
125kohm_to_gnd: connected to ground via an 125kOhm resistor,
500kohm_to_gnd: connected to ground via a 500kOhm resistor,
640kohm_to_gnd: connected to ground via a 640kOhm 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
@ -1491,3 +1494,10 @@ Description:
This ABI is especially applicable for humidity sensors
to heatup the device and get rid of any condensation
in some humidity environment
What: /sys/bus/iio/devices/iio:deviceX/in_ph_raw
KernelVersion: 4.5
Contact: linux-iio@vger.kernel.org
Description:
Raw (unscaled no offset etc.) pH reading of a substance as a negative
base-10 logarithm of hydrodium ions in a litre of water.

54
Documentation/ABI/testing/sysfs-bus-iio-health-afe440x Normal file
View File

@ -0,0 +1,54 @@
What: /sys/bus/iio/devices/iio:deviceX/tia_resistanceY
/sys/bus/iio/devices/iio:deviceX/tia_capacitanceY
Date: December 2015
KernelVersion:
Contact: Andrew F. Davis <afd@ti.com>
Description:
Get and set the resistance and the capacitance settings for the
Transimpedance Amplifier. Y is 1 for Rf1 and Cf1, Y is 2 for
Rf2 and Cf2 values.
What: /sys/bus/iio/devices/iio:deviceX/tia_separate_en
Date: December 2015
KernelVersion:
Contact: Andrew F. Davis <afd@ti.com>
Description:
Enable or disable separate settings for the TransImpedance
Amplifier above, when disabled both values are set by the
first channel.
What: /sys/bus/iio/devices/iio:deviceX/in_intensity_ledY_raw
/sys/bus/iio/devices/iio:deviceX/in_intensity_ledY_ambient_raw
Date: December 2015
KernelVersion:
Contact: Andrew F. Davis <afd@ti.com>
Description:
Get measured values from the ADC for these stages. Y is the
specific LED number. The values are expressed in 24-bit twos
complement.
What: /sys/bus/iio/devices/iio:deviceX/in_intensity_ledY-ledY_ambient_raw
Date: December 2015
KernelVersion:
Contact: Andrew F. Davis <afd@ti.com>
Description:
Get differential values from the ADC for these stages. Y is the
specific LED number. The values are expressed in 24-bit twos
complement for the specified LEDs.
What: /sys/bus/iio/devices/iio:deviceX/out_current_ledY_offset
/sys/bus/iio/devices/iio:deviceX/out_current_ledY_ambient_offset
Date: December 2015
KernelVersion:
Contact: Andrew F. Davis <afd@ti.com>
Description:
Get and set the offset cancellation DAC setting for these
stages. The values are expressed in 5-bit sign-magnitude.
What: /sys/bus/iio/devices/iio:deviceX/out_current_ledY_raw
Date: December 2015
KernelVersion:
Contact: Andrew F. Davis <afd@ti.com>
Description:
Get and set the LED current for the specified LED. Y is the
specific LED number.

15
Documentation/ABI/testing/sysfs-bus-iio-magnetometer-hmc5843 Normal file
View File

@ -0,0 +1,15 @@
What: /sys/bus/iio/devices/iio:deviceX/meas_conf
What: /sys/bus/iio/devices/iio:deviceX/meas_conf_available
KernelVersion: 4.5
Contact: linux-iio@vger.kernel.org
Description:
Current configuration and available configurations
for the bias current.
normal - Normal measurement configurations (default)
positivebias - Positive bias configuration
negativebias - Negative bias configuration
disabled - Only available on HMC5983. Disables magnetic
sensor and enables temperature sensor.
Note: The effect of this configuration may vary
according to the device. For exact documentation
check the device's datasheet.

9
Documentation/ABI/testing/sysfs-bus-iio-vf610
View File

@ -5,3 +5,12 @@ Description:
Specifies the hardware conversion mode used. The three
available modes are "normal", "high-speed" and "low-power",
where the last is the default mode.
What: /sys/bus/iio/devices/iio:deviceX/out_conversion_mode
KernelVersion: 4.6
Contact: linux-iio@vger.kernel.org
Description:
Specifies the hardware conversion mode used within DAC.
The two available modes are "high-power" and "low-power",
where "low-power" mode is the default mode.

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

@ -159,7 +159,7 @@ Description: read only
Decimal value of the Per Process MMIO space length.
Users: https://github.com/ibm-capi/libcxl
What: /sys/class/cxl/<afu>m/pp_mmio_off
What: /sys/class/cxl/<afu>m/pp_mmio_off (not in a guest)
Date: September 2014
Contact: linuxppc-dev@lists.ozlabs.org
Description: read only
@ -183,7 +183,7 @@ Description: read only
Identifies the revision level of the PSL.
Users: https://github.com/ibm-capi/libcxl
What: /sys/class/cxl/<card>/base_image
What: /sys/class/cxl/<card>/base_image (not in a guest)
Date: September 2014
Contact: linuxppc-dev@lists.ozlabs.org
Description: read only
@ -193,7 +193,7 @@ Description: read only
during the initial program load.
Users: https://github.com/ibm-capi/libcxl
What: /sys/class/cxl/<card>/image_loaded
What: /sys/class/cxl/<card>/image_loaded (not in a guest)
Date: September 2014
Contact: linuxppc-dev@lists.ozlabs.org
Description: read only
@ -201,7 +201,7 @@ Description: read only
onto the card.
Users: https://github.com/ibm-capi/libcxl
What: /sys/class/cxl/<card>/load_image_on_perst
What: /sys/class/cxl/<card>/load_image_on_perst (not in a guest)
Date: December 2014
Contact: linuxppc-dev@lists.ozlabs.org
Description: read/write
@ -224,7 +224,7 @@ Description: write only
to reload the FPGA depending on load_image_on_perst.
Users: https://github.com/ibm-capi/libcxl
What: /sys/class/cxl/<card>/perst_reloads_same_image
What: /sys/class/cxl/<card>/perst_reloads_same_image (not in a guest)
Date: July 2015
Contact: linuxppc-dev@lists.ozlabs.org
Description: read/write

17
Documentation/ABI/testing/sysfs-class-net-batman-adv
View File

@ -1,4 +1,20 @@
What: /sys/class/net/<iface>/batman-adv/throughput_override
Date: Feb 2014
Contact: Antonio Quartulli <antonio@meshcoding.com>
description:
Defines the throughput value to be used by B.A.T.M.A.N. V
when estimating the link throughput using this interface.
If the value is set to 0 then batman-adv will try to
estimate the throughput by itself.
What: /sys/class/net/<iface>/batman-adv/elp_interval
Date: Feb 2014
Contact: Linus Lüssing <linus.luessing@web.de>
Description:
Defines the interval in milliseconds in which batman
sends its probing packets for link quality measurements.
What: /sys/class/net/<iface>/batman-adv/iface_status
Date: May 2010
Contact: Marek Lindner <mareklindner@neomailbox.ch>
@ -12,4 +28,3 @@ Description:
The /sys/class/net/<iface>/batman-adv/mesh_iface file
displays the batman mesh interface this <iface>
currently is associated with.

15
Documentation/ABI/testing/sysfs-class-rc-nuvoton Normal file
View File

@ -0,0 +1,15 @@
What: /sys/class/rc/rcN/wakeup_data
Date: Mar 2016
KernelVersion: 4.6
Contact: Mauro Carvalho Chehab <m.chehab@samsung.com>
Description:
Reading this file returns the stored CIR wakeup sequence.
It starts with a pulse, followed by a space, pulse etc.
All values are in microseconds.
The same format can be used to store a wakeup sequence
in the Nuvoton chip by writing to this file.
Note: Some systems reset the stored wakeup sequence to a
factory default on each boot. On such systems store the
wakeup sequence in a file and set it on boot using e.g.
a udev rule.

100
Documentation/ABI/testing/sysfs-firmware-qemu_fw_cfg Normal file
View File

@ -0,0 +1,100 @@
What: /sys/firmware/qemu_fw_cfg/
Date: August 2015
Contact: Gabriel Somlo <somlo@cmu.edu>
Description:
Several different architectures supported by QEMU (x86, arm,
sun4*, ppc/mac) are provisioned with a firmware configuration
(fw_cfg) device, originally intended as a way for the host to
provide configuration data to the guest firmware. Starting
with QEMU v2.4, arbitrary fw_cfg file entries may be specified
by the user on the command line, which makes fw_cfg additionally
useful as an out-of-band, asynchronous mechanism for providing
configuration data to the guest userspace.
The authoritative guest-side hardware interface documentation
to the fw_cfg device can be found in "docs/specs/fw_cfg.txt"
in the QEMU source tree.
=== SysFS fw_cfg Interface ===
The fw_cfg sysfs interface described in this document is only
intended to display discoverable blobs (i.e., those registered
with the file directory), as there is no way to determine the
presence or size of "legacy" blobs (with selector keys between
0x0002 and 0x0018) programmatically.
All fw_cfg information is shown under:
/sys/firmware/qemu_fw_cfg/
The only legacy blob displayed is the fw_cfg device revision:
/sys/firmware/qemu_fw_cfg/rev
--- Discoverable fw_cfg blobs by selector key ---
All discoverable blobs listed in the fw_cfg file directory are
displayed as entries named after their unique selector key
value, e.g.:
/sys/firmware/qemu_fw_cfg/by_key/32
/sys/firmware/qemu_fw_cfg/by_key/33
/sys/firmware/qemu_fw_cfg/by_key/34
...
Each such fw_cfg sysfs entry has the following values exported
as attributes:
name : The 56-byte nul-terminated ASCII string used as the
blob's 'file name' in the fw_cfg directory.
size : The length of the blob, as given in the fw_cfg
directory.
key : The value of the blob's selector key as given in the
fw_cfg directory. This value is the same as used in
the parent directory name.
raw : The raw bytes of the blob, obtained by selecting the
entry via the control register, and reading a number
of bytes equal to the blob size from the data
register.
--- Listing fw_cfg blobs by file name ---
While the fw_cfg device does not impose any specific naming
convention on the blobs registered in the file directory,
QEMU developers have traditionally used path name semantics
to give each blob a descriptive name. For example:
"bootorder"
"genroms/kvmvapic.bin"
"etc/e820"
"etc/boot-fail-wait"
"etc/system-states"
"etc/table-loader"
"etc/acpi/rsdp"
"etc/acpi/tables"
"etc/smbios/smbios-tables"
"etc/smbios/smbios-anchor"
...
In addition to the listing by unique selector key described
above, the fw_cfg sysfs driver also attempts to build a tree
of directories matching the path name components of fw_cfg
blob names, ending in symlinks to the by_key entry for each
"basename", as illustrated below (assume current directory is
/sys/firmware):
qemu_fw_cfg/by_name/bootorder -> ../by_key/38
qemu_fw_cfg/by_name/etc/e820 -> ../../by_key/35
qemu_fw_cfg/by_name/etc/acpi/rsdp -> ../../../by_key/41
...
Construction of the directory tree and symlinks is done on a
"best-effort" basis, as there is no guarantee that components
of fw_cfg blob names are always "well behaved". I.e., there is
the possibility that a symlink (basename) will conflict with
a dirname component of another fw_cfg blob, in which case the
creation of the offending /sys/firmware/qemu_fw_cfg/by_name
entry will be skipped.
The authoritative list of entries will continue to be found
under the /sys/firmware/qemu_fw_cfg/by_key directory.

28
Documentation/ABI/testing/sysfs-gpio
View File

@ -1,28 +0,0 @@
What: /sys/class/gpio/
Date: July 2008
KernelVersion: 2.6.27
Contact: David Brownell <dbrownell@users.sourceforge.net>
Description:
As a Kconfig option, individual GPIO signals may be accessed from
userspace. GPIOs are only made available to userspace by an explicit
"export" operation. If a given GPIO is not claimed for use by
kernel code, it may be exported by userspace (and unexported later).
Kernel code may export it for complete or partial access.
GPIOs are identified as they are inside the kernel, using integers in
the range 0..INT_MAX. See Documentation/gpio.txt for more information.
/sys/class/gpio
/export ... asks the kernel to export a GPIO to userspace
/unexport ... to return a GPIO to the kernel
/gpioN ... for each exported GPIO #N OR
/<LINE-NAME> ... for a properly named GPIO line
/value ... always readable, writes fail for input GPIOs
/direction ... r/w as: in, out (default low); write: high, low
/edge ... r/w as: none, falling, rising, both
/gpiochipN ... for each gpiochip; #N is its first GPIO
/base ... (r/o) same as N
/label ... (r/o) descriptive, not necessarily unique
/ngpio ... (r/o) number of GPIOs; numbered N to N + (ngpio - 1)

97
Documentation/ABI/testing/sysfs-platform-hidma-mgmt Normal file
View File

@ -0,0 +1,97 @@
What: /sys/devices/platform/hidma-mgmt*/chanops/chan*/priority
/sys/devices/platform/QCOM8060:*/chanops/chan*/priority
Date: Nov 2015
KernelVersion: 4.4
Contact: "Sinan Kaya <okaya@cudeaurora.org>"
Description:
Contains either 0 or 1 and indicates if the DMA channel is a
low priority (0) or high priority (1) channel.
What: /sys/devices/platform/hidma-mgmt*/chanops/chan*/weight
/sys/devices/platform/QCOM8060:*/chanops/chan*/weight
Date: Nov 2015
KernelVersion: 4.4
Contact: "Sinan Kaya <okaya@cudeaurora.org>"
Description:
Contains 0..15 and indicates the weight of the channel among
equal priority channels during round robin scheduling.
What: /sys/devices/platform/hidma-mgmt*/chreset_timeout_cycles
/sys/devices/platform/QCOM8060:*/chreset_timeout_cycles
Date: Nov 2015
KernelVersion: 4.4
Contact: "Sinan Kaya <okaya@cudeaurora.org>"
Description:
Contains the platform specific cycle value to wait after a
reset command is issued. If the value is chosen too short,
then the HW will issue a reset failure interrupt. The value
is platform specific and should not be changed without
consultance.
What: /sys/devices/platform/hidma-mgmt*/dma_channels
/sys/devices/platform/QCOM8060:*/dma_channels
Date: Nov 2015
KernelVersion: 4.4
Contact: "Sinan Kaya <okaya@cudeaurora.org>"
Description:
Contains the number of dma channels supported by one instance
of HIDMA hardware. The value may change from chip to chip.
What: /sys/devices/platform/hidma-mgmt*/hw_version_major
/sys/devices/platform/QCOM8060:*/hw_version_major
Date: Nov 2015
KernelVersion: 4.4
Contact: "Sinan Kaya <okaya@cudeaurora.org>"
Description:
Version number major for the hardware.
What: /sys/devices/platform/hidma-mgmt*/hw_version_minor
/sys/devices/platform/QCOM8060:*/hw_version_minor
Date: Nov 2015
KernelVersion: 4.4
Contact: "Sinan Kaya <okaya@cudeaurora.org>"
Description:
Version number minor for the hardware.
What: /sys/devices/platform/hidma-mgmt*/max_rd_xactions
/sys/devices/platform/QCOM8060:*/max_rd_xactions
Date: Nov 2015
KernelVersion: 4.4
Contact: "Sinan Kaya <okaya@cudeaurora.org>"
Description:
Contains a value between 0 and 31. Maximum number of
read transactions that can be issued back to back.
Choosing a higher number gives better performance but
can also cause performance reduction to other peripherals
sharing the same bus.
What: /sys/devices/platform/hidma-mgmt*/max_read_request
/sys/devices/platform/QCOM8060:*/max_read_request
Date: Nov 2015
KernelVersion: 4.4
Contact: "Sinan Kaya <okaya@cudeaurora.org>"
Description:
Size of each read request. The value needs to be a power
of two and can be between 128 and 1024.
What: /sys/devices/platform/hidma-mgmt*/max_wr_xactions
/sys/devices/platform/QCOM8060:*/max_wr_xactions
Date: Nov 2015
KernelVersion: 4.4
Contact: "Sinan Kaya <okaya@cudeaurora.org>"
Description:
Contains a value between 0 and 31. Maximum number of
write transactions that can be issued back to back.
Choosing a higher number gives better performance but
can also cause performance reduction to other peripherals
sharing the same bus.
What: /sys/devices/platform/hidma-mgmt*/max_write_request
/sys/devices/platform/QCOM8060:*/max_write_request
Date: Nov 2015
KernelVersion: 4.4
Contact: "Sinan Kaya <okaya@cudeaurora.org>"
Description:
Size of each write request. The value needs to be a power
of two and can be between 128 and 1024.

2
Documentation/CodingStyle
View File

@ -640,7 +640,7 @@ Things to avoid when using macros:
do { \
if (blah(x) < 0) \
return -EBUGGERED; \
} while(0)
} while (0)
is a _very_ bad idea. It looks like a function call but exits the "calling"
function; don't break the internal parsers of those who will read the code.

26
Documentation/DMA-attributes.txt
View File

@ -100,3 +100,29 @@ allocated by dma_alloc_attrs() function from individual pages if it can
be mapped as contiguous chunk into device dma address space. By
specifying this attribute the allocated buffer is forced to be contiguous
also in physical memory.
DMA_ATTR_ALLOC_SINGLE_PAGES
---------------------------
This is a hint to the DMA-mapping subsystem that it's probably not worth
the time to try to allocate memory to in a way that gives better TLB
efficiency (AKA it's not worth trying to build the mapping out of larger
pages). You might want to specify this if:
- You know that the accesses to this memory won't thrash the TLB.
You might know that the accesses are likely to be sequential or
that they aren't sequential but it's unlikely you'll ping-pong
between many addresses that are likely to be in different physical
pages.
- You know that the penalty of TLB misses while accessing the
memory will be small enough to be inconsequential. If you are
doing a heavy operation like decryption or decompression this
might be the case.
- You know that the DMA mapping is fairly transitory. If you expect
the mapping to have a short lifetime then it may be worth it to
optimize allocation (avoid coming up with large pages) instead of
getting the slight performance win of larger pages.
Setting this hint doesn't guarantee that you won't get huge pages, but it
means that we won't try quite as hard to get them.
NOTE: At the moment DMA_ATTR_ALLOC_SINGLE_PAGES is only implemented on ARM,
though ARM64 patches will likely be posted soon.

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

@ -348,10 +348,7 @@
<para>type:
<itemizedlist>
<listitem>
<para>blkcipher for synchronous block ciphers</para>
</listitem>
<listitem>
<para>ablkcipher for asynchronous block ciphers</para>
<para>skcipher for symmetric key ciphers</para>
</listitem>
<listitem>
<para>cipher for single block ciphers that may be used with
@ -484,6 +481,9 @@
<listitem>
<para>CRYPTO_ALG_TYPE_RNG Random Number Generation</para>
</listitem>
<listitem>
<para>CRYPTO_ALG_TYPE_AKCIPHER Asymmetric cipher</para>
</listitem>
<listitem>
<para>CRYPTO_ALG_TYPE_PCOMPRESS Enhanced version of
CRYPTO_ALG_TYPE_COMPRESS allowing for segmented compression /
@ -597,7 +597,7 @@ kernel crypto API | IPSEC Layer
v v
+-----------+ +-----------+
| | | |
| ablkcipher| | ahash |
| skcipher | | ahash |
| (ctr) | ---+ | (ghash) |
+-----------+ | +-----------+
|
@ -658,7 +658,7 @@ kernel crypto API | IPSEC Layer
<listitem>
<para>
The GCM AEAD cipher type implementation now invokes the ABLKCIPHER API
The GCM AEAD cipher type implementation now invokes the SKCIPHER API
with the instantiated CTR(AES) cipher handle.
</para>
@ -669,7 +669,7 @@ kernel crypto API | IPSEC Layer
</para>
<para>
That means that the ABLKCIPHER implementation of CTR(AES) only
That means that the SKCIPHER implementation of CTR(AES) only
implements the CTR block chaining mode. After performing the block
chaining operation, the CIPHER implementation of AES is invoked.
</para>
@ -677,7 +677,7 @@ kernel crypto API | IPSEC Layer
<listitem>
<para>
The ABLKCIPHER of CTR(AES) now invokes the CIPHER API with the AES
The SKCIPHER of CTR(AES) now invokes the CIPHER API with the AES
cipher handle to encrypt one block.
</para>
</listitem>
@ -706,7 +706,7 @@ kernel crypto API | IPSEC Layer
<para>
For example, CBC(AES) is implemented with cbc.c, and aes-generic.c. The
ASCII art picture above applies as well with the difference that only
step (4) is used and the ABLKCIPHER block chaining mode is CBC.
step (4) is used and the SKCIPHER block chaining mode is CBC.
</para>
</sect2>
@ -904,15 +904,14 @@ kernel crypto API | Caller
</sect2>
</sect1>
<sect1><title>Multi-Block Ciphers [BLKCIPHER] [ABLKCIPHER]</title>
<sect1><title>Multi-Block Ciphers</title>
<para>
Example of transformations: cbc(aes), ecb(arc4), ...
</para>
<para>
This section describes the multi-block cipher transformation
implementations for both synchronous [BLKCIPHER] and
asynchronous [ABLKCIPHER] case. The multi-block ciphers are
implementations. The multi-block ciphers are
used for transformations which operate on scatterlists of
data supplied to the transformation functions. They output
the result into a scatterlist of data as well.
@ -921,16 +920,15 @@ kernel crypto API | Caller
<sect2><title>Registration Specifics</title>
<para>
The registration of [BLKCIPHER] or [ABLKCIPHER] algorithms
The registration of multi-block cipher algorithms
is one of the most standard procedures throughout the crypto API.
</para>
<para>
Note, if a cipher implementation requires a proper alignment
of data, the caller should use the functions of
crypto_blkcipher_alignmask() or crypto_ablkcipher_alignmask()
respectively to identify a memory alignment mask. The kernel
crypto API is able to process requests that are unaligned.
crypto_skcipher_alignmask() to identify a memory alignment mask.
The kernel crypto API is able to process requests that are unaligned.
This implies, however, additional overhead as the kernel
crypto API needs to perform the realignment of the data which
may imply moving of data.
@ -945,14 +943,13 @@ kernel crypto API | Caller
<para>
Please refer to the single block cipher description for schematics
of the block cipher usage. The usage patterns are exactly the same
for [ABLKCIPHER] and [BLKCIPHER] as they are for plain [CIPHER].
of the block cipher usage.
</para>
</sect2>
<sect2><title>Specifics Of Asynchronous Multi-Block Cipher</title>
<para>
There are a couple of specifics to the [ABLKCIPHER] interface.
There are a couple of specifics to the asynchronous interface.
</para>
<para>
@ -1692,7 +1689,28 @@ read(opfd, out, outlen);
!Finclude/linux/crypto.h cipher_alg
!Finclude/crypto/rng.h rng_alg
</sect1>
<sect1><title>Asynchronous Block Cipher API</title>
<sect1><title>Symmetric Key Cipher API</title>
!Pinclude/crypto/skcipher.h Symmetric Key Cipher API
!Finclude/crypto/skcipher.h crypto_alloc_skcipher
!Finclude/crypto/skcipher.h crypto_free_skcipher
!Finclude/crypto/skcipher.h crypto_has_skcipher
!Finclude/crypto/skcipher.h crypto_skcipher_ivsize
!Finclude/crypto/skcipher.h crypto_skcipher_blocksize
!Finclude/crypto/skcipher.h crypto_skcipher_setkey
!Finclude/crypto/skcipher.h crypto_skcipher_reqtfm
!Finclude/crypto/skcipher.h crypto_skcipher_encrypt
!Finclude/crypto/skcipher.h crypto_skcipher_decrypt
</sect1>
<sect1><title>Symmetric Key Cipher Request Handle</title>
!Pinclude/crypto/skcipher.h Symmetric Key Cipher Request Handle
!Finclude/crypto/skcipher.h crypto_skcipher_reqsize
!Finclude/crypto/skcipher.h skcipher_request_set_tfm
!Finclude/crypto/skcipher.h skcipher_request_alloc
!Finclude/crypto/skcipher.h skcipher_request_free
!Finclude/crypto/skcipher.h skcipher_request_set_callback
!Finclude/crypto/skcipher.h skcipher_request_set_crypt
</sect1>
<sect1><title>Asynchronous Block Cipher API - Deprecated</title>
!Pinclude/linux/crypto.h Asynchronous Block Cipher API
!Finclude/linux/crypto.h crypto_alloc_ablkcipher
!Finclude/linux/crypto.h crypto_free_ablkcipher
@ -1704,7 +1722,7 @@ read(opfd, out, outlen);
!Finclude/linux/crypto.h crypto_ablkcipher_encrypt
!Finclude/linux/crypto.h crypto_ablkcipher_decrypt
</sect1>
<sect1><title>Asynchronous Cipher Request Handle</title>
<sect1><title>Asynchronous Cipher Request Handle - Deprecated</title>
!Pinclude/linux/crypto.h Asynchronous Cipher Request Handle
!Finclude/linux/crypto.h crypto_ablkcipher_reqsize
!Finclude/linux/crypto.h ablkcipher_request_set_tfm
@ -1733,10 +1751,9 @@ read(opfd, out, outlen);
!Finclude/crypto/aead.h aead_request_free
!Finclude/crypto/aead.h aead_request_set_callback
!Finclude/crypto/aead.h aead_request_set_crypt
!Finclude/crypto/aead.h aead_request_set_assoc
!Finclude/crypto/aead.h aead_request_set_ad
</sect1>
<sect1><title>Synchronous Block Cipher API</title>
<sect1><title>Synchronous Block Cipher API - Deprecated</title>
!Pinclude/linux/crypto.h Synchronous Block Cipher API
!Finclude/linux/crypto.h crypto_alloc_blkcipher
!Finclude/linux/crypto.h crypto_free_blkcipher
@ -1761,19 +1778,6 @@ read(opfd, out, outlen);
!Finclude/linux/crypto.h crypto_cipher_setkey
!Finclude/linux/crypto.h crypto_cipher_encrypt_one
!Finclude/linux/crypto.h crypto_cipher_decrypt_one
</sect1>
<sect1><title>Synchronous Message Digest API</title>
!Pinclude/linux/crypto.h Synchronous Message Digest API
!Finclude/linux/crypto.h crypto_alloc_hash
!Finclude/linux/crypto.h crypto_free_hash
!Finclude/linux/crypto.h crypto_has_hash
!Finclude/linux/crypto.h crypto_hash_blocksize
!Finclude/linux/crypto.h crypto_hash_digestsize
!Finclude/linux/crypto.h crypto_hash_init
!Finclude/linux/crypto.h crypto_hash_update
!Finclude/linux/crypto.h crypto_hash_final
!Finclude/linux/crypto.h crypto_hash_digest
!Finclude/linux/crypto.h crypto_hash_setkey
</sect1>
<sect1><title>Message Digest Algorithm Definitions</title>
!Pinclude/crypto/hash.h Message Digest Algorithm Definitions
@ -1825,15 +1829,36 @@ read(opfd, out, outlen);
!Finclude/crypto/rng.h crypto_alloc_rng
!Finclude/crypto/rng.h crypto_rng_alg
!Finclude/crypto/rng.h crypto_free_rng
!Finclude/crypto/rng.h crypto_rng_generate
!Finclude/crypto/rng.h crypto_rng_get_bytes
!Finclude/crypto/rng.h crypto_rng_reset
!Finclude/crypto/rng.h crypto_rng_seedsize
!Cinclude/crypto/rng.h
</sect1>
<sect1><title>Asymmetric Cipher API</title>
!Pinclude/crypto/akcipher.h Generic Public Key API
!Finclude/crypto/akcipher.h akcipher_alg
!Finclude/crypto/akcipher.h akcipher_request
!Finclude/crypto/akcipher.h crypto_alloc_akcipher
!Finclude/crypto/akcipher.h crypto_free_akcipher
!Finclude/crypto/akcipher.h crypto_akcipher_set_pub_key
!Finclude/crypto/akcipher.h crypto_akcipher_set_priv_key
</sect1>
<sect1><title>Asymmetric Cipher Request Handle</title>
!Finclude/crypto/akcipher.h akcipher_request_alloc
!Finclude/crypto/akcipher.h akcipher_request_free
!Finclude/crypto/akcipher.h akcipher_request_set_callback
!Finclude/crypto/akcipher.h akcipher_request_set_crypt
!Finclude/crypto/akcipher.h crypto_akcipher_maxsize
!Finclude/crypto/akcipher.h crypto_akcipher_encrypt
!Finclude/crypto/akcipher.h crypto_akcipher_decrypt
!Finclude/crypto/akcipher.h crypto_akcipher_sign
!Finclude/crypto/akcipher.h crypto_akcipher_verify
</sect1>
</chapter>
<chapter id="Code"><title>Code Examples</title>
<sect1><title>Code Example For Asynchronous Block Cipher Operation</title>
<sect1><title>Code Example For Symmetric Key Cipher Operation</title>
<programlisting>
struct tcrypt_result {
@ -1842,15 +1867,15 @@ struct tcrypt_result {
};
/* tie all data structures together */
struct ablkcipher_def {
struct skcipher_def {
struct scatterlist sg;
struct crypto_ablkcipher *tfm;
struct ablkcipher_request *req;
struct crypto_skcipher *tfm;
struct skcipher_request *req;
struct tcrypt_result result;
};
/* Callback function */
static void test_ablkcipher_cb(struct crypto_async_request *req, int error)
static void test_skcipher_cb(struct crypto_async_request *req, int error)
{
struct tcrypt_result *result = req-&gt;data;
@ -1862,15 +1887,15 @@ static void test_ablkcipher_cb(struct crypto_async_request *req, int error)
}
/* Perform cipher operation */
static unsigned int test_ablkcipher_encdec(struct ablkcipher_def *ablk,
int enc)
static unsigned int test_skcipher_encdec(struct skcipher_def *sk,
int enc)
{
int rc = 0;
if (enc)
rc = crypto_ablkcipher_encrypt(ablk-&gt;req);
rc = crypto_skcipher_encrypt(sk-&gt;req);
else
rc = crypto_ablkcipher_decrypt(ablk-&gt;req);
rc = crypto_skcipher_decrypt(sk-&gt;req);
switch (rc) {
case 0:
@ -1878,52 +1903,52 @@ static unsigned int test_ablkcipher_encdec(struct ablkcipher_def *ablk,
case -EINPROGRESS:
case -EBUSY:
rc = wait_for_completion_interruptible(
&amp;ablk-&gt;result.completion);
if (!rc &amp;&amp; !ablk-&gt;result.err) {
reinit_completion(&amp;ablk-&gt;result.completion);
&amp;sk-&gt;result.completion);
if (!rc &amp;&amp; !sk-&gt;result.err) {
reinit_completion(&amp;sk-&gt;result.completion);
break;
}
default:
pr_info("ablkcipher encrypt returned with %d result %d\n",
rc, ablk-&gt;result.err);
pr_info("skcipher encrypt returned with %d result %d\n",
rc, sk-&gt;result.err);
break;
}
init_completion(&amp;ablk-&gt;result.completion);
init_completion(&amp;sk-&gt;result.completion);
return rc;
}
/* Initialize and trigger cipher operation */
static int test_ablkcipher(void)
static int test_skcipher(void)
{
struct ablkcipher_def ablk;
struct crypto_ablkcipher *ablkcipher = NULL;
struct ablkcipher_request *req = NULL;
struct skcipher_def sk;
struct crypto_skcipher *skcipher = NULL;
struct skcipher_request *req = NULL;
char *scratchpad = NULL;
char *ivdata = NULL;
unsigned char key[32];
int ret = -EFAULT;
ablkcipher = crypto_alloc_ablkcipher("cbc-aes-aesni", 0, 0);
if (IS_ERR(ablkcipher)) {
pr_info("could not allocate ablkcipher handle\n");
return PTR_ERR(ablkcipher);
skcipher = crypto_alloc_skcipher("cbc-aes-aesni", 0, 0);
if (IS_ERR(skcipher)) {
pr_info("could not allocate skcipher handle\n");
return PTR_ERR(skcipher);
}
req = ablkcipher_request_alloc(ablkcipher, GFP_KERNEL);
req = skcipher_request_alloc(skcipher, GFP_KERNEL);
if (IS_ERR(req)) {
pr_info("could not allocate request queue\n");
ret = PTR_ERR(req);
goto out;
}
ablkcipher_request_set_callback(req, CRYPTO_TFM_REQ_MAY_BACKLOG,
test_ablkcipher_cb,
&amp;ablk.result);
skcipher_request_set_callback(req, CRYPTO_TFM_REQ_MAY_BACKLOG,
test_skcipher_cb,
&amp;sk.result);
/* AES 256 with random key */
get_random_bytes(&amp;key, 32);
if (crypto_ablkcipher_setkey(ablkcipher, key, 32)) {
if (crypto_skcipher_setkey(skcipher, key, 32)) {
pr_info("key could not be set\n");
ret = -EAGAIN;
goto out;
@ -1945,26 +1970,26 @@ static int test_ablkcipher(void)
}
get_random_bytes(scratchpad, 16);
ablk.tfm = ablkcipher;
ablk.req = req;
sk.tfm = skcipher;
sk.req = req;
/* We encrypt one block */
sg_init_one(&amp;ablk.sg, scratchpad, 16);
ablkcipher_request_set_crypt(req, &amp;ablk.sg, &amp;ablk.sg, 16, ivdata);
init_completion(&amp;ablk.result.completion);
sg_init_one(&amp;sk.sg, scratchpad, 16);
skcipher_request_set_crypt(req, &amp;sk.sg, &amp;sk.sg, 16, ivdata);
init_completion(&amp;sk.result.completion);
/* encrypt data */
ret = test_ablkcipher_encdec(&amp;ablk, 1);
ret = test_skcipher_encdec(&amp;sk, 1);
if (ret)
goto out;
pr_info("Encryption triggered successfully\n");
out:
if (ablkcipher)
crypto_free_ablkcipher(ablkcipher);
if (skcipher)
crypto_free_skcipher(skcipher);
if (req)
ablkcipher_request_free(req);
skcipher_request_free(req);
if (ivdata)
kfree(ivdata);
if (scratchpad)
@ -1974,77 +1999,6 @@ out:
</programlisting>
</sect1>
<sect1><title>Code Example For Synchronous Block Cipher Operation</title>
<programlisting>
static int test_blkcipher(void)
{
struct crypto_blkcipher *blkcipher = NULL;
char *cipher = "cbc(aes)";
// AES 128
charkey =
"\x12\x34\x56\x78\x90\xab\xcd\xef\x12\x34\x56\x78\x90\xab\xcd\xef";
chariv =
"\x12\x34\x56\x78\x90\xab\xcd\xef\x12\x34\x56\x78\x90\xab\xcd\xef";
unsigned int ivsize = 0;
char *scratchpad = NULL; // holds plaintext and ciphertext
struct scatterlist sg;
struct blkcipher_desc desc;
int ret = -EFAULT;
blkcipher = crypto_alloc_blkcipher(cipher, 0, 0);
if (IS_ERR(blkcipher)) {
printk("could not allocate blkcipher handle for %s\n", cipher);
return -PTR_ERR(blkcipher);
}
if (crypto_blkcipher_setkey(blkcipher, key, strlen(key))) {
printk("key could not be set\n");
ret = -EAGAIN;
goto out;
}
ivsize = crypto_blkcipher_ivsize(blkcipher);
if (ivsize) {
if (ivsize != strlen(iv))
printk("IV length differs from expected length\n");
crypto_blkcipher_set_iv(blkcipher, iv, ivsize);
}
scratchpad = kmalloc(crypto_blkcipher_blocksize(blkcipher), GFP_KERNEL);
if (!scratchpad) {
printk("could not allocate scratchpad for %s\n", cipher);
goto out;
}
/* get some random data that we want to encrypt */
get_random_bytes(scratchpad, crypto_blkcipher_blocksize(blkcipher));
desc.flags = 0;
desc.tfm = blkcipher;
sg_init_one(&amp;sg, scratchpad, crypto_blkcipher_blocksize(blkcipher));
/* encrypt data in place */
crypto_blkcipher_encrypt(&amp;desc, &amp;sg, &amp;sg,
crypto_blkcipher_blocksize(blkcipher));
/* decrypt data in place
* crypto_blkcipher_decrypt(&amp;desc, &amp;sg, &amp;sg,
*/ crypto_blkcipher_blocksize(blkcipher));
printk("Cipher operation completed\n");
return 0;
out:
if (blkcipher)
crypto_free_blkcipher(blkcipher);
if (scratchpad)
kzfree(scratchpad);
return ret;
}
</programlisting>
</sect1>
<sect1><title>Code Example For Use of Operational State Memory With SHASH</title>
<programlisting>

3
Documentation/DocBook/device-drivers.tmpl
View File

@ -229,6 +229,7 @@ X!Isound/sound_firmware.c
!Iinclude/media/v4l2-dv-timings.h
!Iinclude/media/v4l2-event.h
!Iinclude/media/v4l2-flash-led-class.h
!Iinclude/media/v4l2-mc.h
!Iinclude/media/v4l2-mediabus.h
!Iinclude/media/v4l2-mem2mem.h
!Iinclude/media/v4l2-of.h
@ -368,7 +369,7 @@ X!Ilib/fonts/fonts.c
!Iinclude/linux/input-polldev.h
!Edrivers/input/input-polldev.c
</sect1>
<sect1><title>Matrix keyboars/keypads</title>
<sect1><title>Matrix keyboards/keypads</title>
!Iinclude/linux/input/matrix_keypad.h
</sect1>
<sect1><title>Sparse keymap support</title>

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

@ -2329,6 +2329,14 @@ to search and match for the present Macroblock (MB) in the reference picture. Th
vertical search range for motion estimation module in video encoder.</entry>
</row>
<row><entry></entry></row>
<row id="v4l2-mpeg-video-force-key-frame">
<entry spanname="id"><constant>V4L2_CID_MPEG_VIDEO_FORCE_KEY_FRAME</constant>&nbsp;</entry>
<entry>button</entry>
</row><row><entry spanname="descr">Force a key frame for the next queued buffer. Applicable to encoders.
This is a general, codec-agnostic keyframe control.</entry>
</row>
<row><entry></entry></row>
<row>
<entry spanname="id"><constant>V4L2_CID_MPEG_VIDEO_H264_CPB_SIZE</constant>&nbsp;</entry>
@ -5069,6 +5077,46 @@ interface and may change in the future.</para>
This control is applicable to VGA, DVI-A/D, HDMI and DisplayPort connectors.
</entry>
</row>
<row>
<entry spanname="id"><constant>V4L2_CID_DV_TX_IT_CONTENT_TYPE</constant></entry>
<entry id="v4l2-dv-content-type">enum v4l2_dv_it_content_type</entry>
</row>
<row><entry spanname="descr">Configures the IT Content Type
of the transmitted video. This information is sent over HDMI and DisplayPort connectors
as part of the AVI InfoFrame. The term 'IT Content' is used for content that originates
from a computer as opposed to content from a TV broadcast or an analog source. The
enum&nbsp;v4l2_dv_it_content_type defines the possible content types:</entry>
</row>
<row>
<entrytbl spanname="descr" cols="2">
<tbody valign="top">
<row>
<entry><constant>V4L2_DV_IT_CONTENT_TYPE_GRAPHICS</constant>&nbsp;</entry>
<entry>Graphics content. Pixel data should be passed unfiltered and without
analog reconstruction.</entry>
</row>
<row>
<entry><constant>V4L2_DV_IT_CONTENT_TYPE_PHOTO</constant>&nbsp;</entry>
<entry>Photo content. The content is derived from digital still pictures.
The content should be passed through with minimal scaling and picture
enhancements.</entry>
</row>
<row>
<entry><constant>V4L2_DV_IT_CONTENT_TYPE_CINEMA</constant>&nbsp;</entry>
<entry>Cinema content.</entry>
</row>
<row>
<entry><constant>V4L2_DV_IT_CONTENT_TYPE_GAME</constant>&nbsp;</entry>
<entry>Game content. Audio and video latency should be minimized.</entry>
</row>
<row>
<entry><constant>V4L2_DV_IT_CONTENT_TYPE_NO_ITC</constant>&nbsp;</entry>
<entry>No IT Content information is available and the ITC bit in the AVI
InfoFrame is set to 0.</entry>
</row>
</tbody>
</entrytbl>
</row>
<row>
<entry spanname="id"><constant>V4L2_CID_DV_RX_POWER_PRESENT</constant></entry>
<entry>bitmask</entry>
@ -5098,6 +5146,16 @@ interface and may change in the future.</para>
This control is applicable to VGA, DVI-A/D, HDMI and DisplayPort connectors.
</entry>
</row>
<row>
<entry spanname="id"><constant>V4L2_CID_DV_RX_IT_CONTENT_TYPE</constant></entry>
<entry>enum v4l2_dv_it_content_type</entry>
</row>
<row><entry spanname="descr">Reads the IT Content Type
of the received video. This information is sent over HDMI and DisplayPort connectors
as part of the AVI InfoFrame. The term 'IT Content' is used for content that originates
from a computer as opposed to content from a TV broadcast or an analog source. See
<constant>V4L2_CID_DV_TX_IT_CONTENT_TYPE</constant> for the available content types.</entry>
</row>
<row><entry></entry></row>
</tbody>
</tgroup>

3
Documentation/DocBook/media/v4l/media-ioc-g-topology.xml
View File

@ -48,9 +48,6 @@
<refsect1>
<title>Description</title>
<para><emphasis role="bold">NOTE:</emphasis> This new ioctl is programmed to be added on Kernel 4.6. Its definition/arguments may change until its final version.</para>
<para>The typical usage of this ioctl is to call it twice.
On the first call, the structure defined at &media-v2-topology; should
be zeroed. At return, if no errors happen, this ioctl will return the

81
Documentation/DocBook/media/v4l/media-types.xml
View File

@ -80,7 +80,46 @@
</row>
<row>
<entry><constant>MEDIA_ENT_F_TUNER</constant></entry>
<entry>Digital TV, analog TV, radio and/or software radio tuner.</entry>
<entry>Digital TV, analog TV, radio and/or software radio tuner,
with consists on a PLL tuning stage that converts radio
frequency (RF) signal into an Intermediate Frequency (IF).
Modern tuners have internally IF-PLL decoders for audio
and video, but older models have those stages implemented
on separate entities.
</entry>
</row>
<row>
<entry><constant>MEDIA_ENT_F_IF_VID_DECODER</constant></entry>
<entry>IF-PLL video decoder. It receives the IF from a PLL
and decodes the analog TV video signal. This is commonly
found on some very old analog tuners, like Philips MK3
designs. They all contain a tda9887 (or some software
compatible similar chip, like tda9885). Those devices
use a different I2C address than the tuner PLL.
</entry>
</row>
<row>
<entry><constant>MEDIA_ENT_F_IF_AUD_DECODER</constant></entry>
<entry>IF-PLL sound decoder. It receives the IF from a PLL
and decodes the analog TV audio signal. This is commonly
found on some very old analog hardware, like Micronas
msp3400, Philips tda9840, tda985x, etc. Those devices
use a different I2C address than the tuner PLL and
should be controlled together with the IF-PLL video
decoder.
</entry>
</row>
<row>
<entry><constant>MEDIA_ENT_F_AUDIO_CAPTURE</constant></entry>
<entry>Audio Capture Function Entity.</entry>
</row>
<row>
<entry><constant>MEDIA_ENT_F_AUDIO_PLAYBACK</constant></entry>
<entry>Audio Playback Function Entity.</entry>
</row>
<row>
<entry><constant>MEDIA_ENT_F_AUDIO_MIXER</constant></entry>
<entry>Audio Mixer Function Entity.</entry>
</row>
</tbody>
</tgroup>
@ -162,6 +201,46 @@
<entry>Device node interface for Software Defined Radio (V4L)</entry>
<entry>typically, /dev/swradio?</entry>
</row>
<row>
<entry><constant>MEDIA_INTF_T_ALSA_PCM_CAPTURE</constant></entry>
<entry>Device node interface for ALSA PCM Capture</entry>
<entry>typically, /dev/snd/pcmC?D?c</entry>
</row>
<row>
<entry><constant>MEDIA_INTF_T_ALSA_PCM_PLAYBACK</constant></entry>
<entry>Device node interface for ALSA PCM Playback</entry>
<entry>typically, /dev/snd/pcmC?D?p</entry>
</row>
<row>
<entry><constant>MEDIA_INTF_T_ALSA_CONTROL</constant></entry>
<entry>Device node interface for ALSA Control</entry>
<entry>typically, /dev/snd/controlC?</entry>
</row>
<row>
<entry><constant>MEDIA_INTF_T_ALSA_COMPRESS</constant></entry>
<entry>Device node interface for ALSA Compress</entry>
<entry>typically, /dev/snd/compr?</entry>
</row>
<row>
<entry><constant>MEDIA_INTF_T_ALSA_RAWMIDI</constant></entry>
<entry>Device node interface for ALSA Raw MIDI</entry>
<entry>typically, /dev/snd/midi?</entry>
</row>
<row>
<entry><constant>MEDIA_INTF_T_ALSA_HWDEP</constant></entry>
<entry>Device node interface for ALSA Hardware Dependent</entry>
<entry>typically, /dev/snd/hwC?D?</entry>
</row>
<row>
<entry><constant>MEDIA_INTF_T_ALSA_SEQUENCER</constant></entry>
<entry>Device node interface for ALSA Sequencer</entry>
<entry>typically, /dev/snd/seq</entry>
</row>
<row>
<entry><constant>MEDIA_INTF_T_ALSA_TIMER</constant></entry>
<entry>Device node interface for ALSA Timer</entry>
<entry>typically, /dev/snd/timer</entry>
</row>
</tbody>
</tgroup>
</table>

49
Documentation/DocBook/media/v4l/pixfmt-y12i.xml Normal file
View File

@ -0,0 +1,49 @@
<refentry id="V4L2-PIX-FMT-Y12I">
<refmeta>
<refentrytitle>V4L2_PIX_FMT_Y12I ('Y12I')</refentrytitle>
&manvol;
</refmeta>
<refnamediv>
<refname><constant>V4L2_PIX_FMT_Y12I</constant></refname>
<refpurpose>Interleaved grey-scale image, e.g. from a stereo-pair</refpurpose>
</refnamediv>
<refsect1>
<title>Description</title>
<para>This is a grey-scale image with a depth of 12 bits per pixel, but with
pixels from 2 sources interleaved and bit-packed. Each pixel is stored in a
24-bit word in the little-endian order. On a little-endian machine these pixels
can be deinterlaced using</para>
<para>
<programlisting>
__u8 *buf;
left0 = 0xfff &amp; *(__u16 *)buf;
right0 = *(__u16 *)(buf + 1) >> 4;
</programlisting>
</para>
<example>
<title><constant>V4L2_PIX_FMT_Y12I</constant> 2 pixel data stream taking 3 bytes</title>
<formalpara>
<title>Bit-packed representation</title>
<para>pixels cross the byte boundary and have a ratio of 3 bytes for each
interleaved pixel.
<informaltable frame="all">
<tgroup cols="3" align="center">
<colspec align="left" colwidth="2*" />
<tbody valign="top">
<row>
<entry>Y'<subscript>0left[7:0]</subscript></entry>
<entry>Y'<subscript>0right[3:0]</subscript>Y'<subscript>0left[11:8]</subscript></entry>
<entry>Y'<subscript>0right[11:4]</subscript></entry>
</row>
</tbody>
</tgroup>
</informaltable>
</para>
</formalpara>
</example>
</refsect1>
</refentry>

80
Documentation/DocBook/media/v4l/pixfmt-y8i.xml Normal file
View File

@ -0,0 +1,80 @@
<refentry id="V4L2-PIX-FMT-Y8I">
<refmeta>
<refentrytitle>V4L2_PIX_FMT_Y8I ('Y8I ')</refentrytitle>
&manvol;
</refmeta>
<refnamediv>
<refname><constant>V4L2_PIX_FMT_Y8I</constant></refname>
<refpurpose>Interleaved grey-scale image, e.g. from a stereo-pair</refpurpose>
</refnamediv>
<refsect1>
<title>Description</title>
<para>This is a grey-scale image with a depth of 8 bits per pixel, but with
pixels from 2 sources interleaved. Each pixel is stored in a 16-bit word. E.g.
the R200 RealSense camera stores pixel from the left sensor in lower and from
the right sensor in the higher 8 bits.</para>
<example>
<title><constant>V4L2_PIX_FMT_Y8I</constant> 4 &times; 4
pixel image</title>
<formalpara>
<title>Byte Order.</title>
<para>Each cell is one byte.
<informaltable frame="none">
<tgroup cols="9" align="center">
<colspec align="left" colwidth="2*" />
<tbody valign="top">
<row>
<entry>start&nbsp;+&nbsp;0:</entry>
<entry>Y'<subscript>00left</subscript></entry>
<entry>Y'<subscript>00right</subscript></entry>
<entry>Y'<subscript>01left</subscript></entry>
<entry>Y'<subscript>01right</subscript></entry>
<entry>Y'<subscript>02left</subscript></entry>
<entry>Y'<subscript>02right</subscript></entry>
<entry>Y'<subscript>03left</subscript></entry>
<entry>Y'<subscript>03right</subscript></entry>
</row>
<row>
<entry>start&nbsp;+&nbsp;8:</entry>
<entry>Y'<subscript>10left</subscript></entry>
<entry>Y'<subscript>10right</subscript></entry>
<entry>Y'<subscript>11left</subscript></entry>
<entry>Y'<subscript>11right</subscript></entry>
<entry>Y'<subscript>12left</subscript></entry>
<entry>Y'<subscript>12right</subscript></entry>
<entry>Y'<subscript>13left</subscript></entry>
<entry>Y'<subscript>13right</subscript></entry>
</row>
<row>
<entry>start&nbsp;+&nbsp;16:</entry>
<entry>Y'<subscript>20left</subscript></entry>
<entry>Y'<subscript>20right</subscript></entry>
<entry>Y'<subscript>21left</subscript></entry>
<entry>Y'<subscript>21right</subscript></entry>
<entry>Y'<subscript>22left</subscript></entry>
<entry>Y'<subscript>22right</subscript></entry>
<entry>Y'<subscript>23left</subscript></entry>
<entry>Y'<subscript>23right</subscript></entry>
</row>
<row>
<entry>start&nbsp;+&nbsp;24:</entry>
<entry>Y'<subscript>30left</subscript></entry>
<entry>Y'<subscript>30right</subscript></entry>
<entry>Y'<subscript>31left</subscript></entry>
<entry>Y'<subscript>31right</subscript></entry>
<entry>Y'<subscript>32left</subscript></entry>
<entry>Y'<subscript>32right</subscript></entry>
<entry>Y'<subscript>33left</subscript></entry>
<entry>Y'<subscript>33right</subscript></entry>
</row>
</tbody>
</tgroup>
</informaltable>
</para>
</formalpara>
</example>
</refsect1>
</refentry>

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

@ -1,35 +1,43 @@
<refentry id="V4L2-PIX-FMT-YUV420M">
<refentry>
<refmeta>
<refentrytitle>V4L2_PIX_FMT_YUV420M ('YM12')</refentrytitle>
<refentrytitle>V4L2_PIX_FMT_YUV420M ('YM12'), V4L2_PIX_FMT_YVU420M ('YM21')</refentrytitle>
&manvol;
</refmeta>
<refnamediv>
<refname> <constant>V4L2_PIX_FMT_YUV420M</constant></refname>
<refpurpose>Variation of <constant>V4L2_PIX_FMT_YUV420</constant>
with planes non contiguous in memory. </refpurpose>
<refname id="V4L2-PIX-FMT-YUV420M"><constant>V4L2_PIX_FMT_YUV420M</constant></refname>
<refname id="V4L2-PIX-FMT-YVU420M"><constant>V4L2_PIX_FMT_YVU420M</constant></refname>
<refpurpose>Variation of <constant>V4L2_PIX_FMT_YUV420</constant> and
<constant>V4L2_PIX_FMT_YVU420</constant> with planes non contiguous
in memory.</refpurpose>
</refnamediv>
<refsect1>
<title>Description</title>
<para>This is a multi-planar format, as opposed to a packed format.
The three components are separated into three sub- images or planes.
The three components are separated into three sub-images or planes.</para>
The Y plane is first. The Y plane has one byte per pixel. The Cb data
<para>The Y plane is first. The Y plane has one byte per pixel.
For <constant>V4L2_PIX_FMT_YUV420M</constant> the Cb data
constitutes the second plane which is half the width and half
the height of the Y plane (and of the image). Each Cb belongs to four
pixels, a two-by-two square of the image. For example,
Cb<subscript>0</subscript> belongs to Y'<subscript>00</subscript>,
Y'<subscript>01</subscript>, Y'<subscript>10</subscript>, and
Y'<subscript>11</subscript>. The Cr data, just like the Cb plane, is
in the third plane. </para>
in the third plane.</para>
<para><constant>V4L2_PIX_FMT_YVU420M</constant> is the same except
the Cr data is stored in the second plane and the Cb data in the third plane.
</para>
<para>If the Y plane has pad bytes after each row, then the Cb
and Cr planes have half as many pad bytes after their rows. In other
words, two Cx rows (including padding) is exactly as long as one Y row
(including padding).</para>
<para><constant>V4L2_PIX_FMT_YUV420M</constant> is intended to be
<para><constant>V4L2_PIX_FMT_YUV420M</constant> and
<constant>V4L2_PIX_FMT_YVU420M</constant> are intended to be
used only in drivers and applications that support the multi-planar API,
described in <xref linkend="planar-apis"/>. </para>

166
Documentation/DocBook/media/v4l/pixfmt-yuv422m.xml Normal file
View File

@ -0,0 +1,166 @@
<refentry>
<refmeta>
<refentrytitle>V4L2_PIX_FMT_YUV422M ('YM16'), V4L2_PIX_FMT_YVU422M ('YM61')</refentrytitle>
&manvol;
</refmeta>
<refnamediv>
<refname id="V4L2-PIX-FMT-YUV422M"><constant>V4L2_PIX_FMT_YUV422M</constant></refname>
<refname id="V4L2-PIX-FMT-YVU422M"><constant>V4L2_PIX_FMT_YVU422M</constant></refname>
<refpurpose>Planar formats with &frac12; horizontal resolution, also
known as YUV and YVU 4:2:2</refpurpose>
</refnamediv>
<refsect1>
<title>Description</title>
<para>This is a multi-planar format, as opposed to a packed format.
The three components are separated into three sub-images or planes.</para>
<para>The Y plane is first. The Y plane has one byte per pixel.
For <constant>V4L2_PIX_FMT_YUV422M</constant> the Cb data
constitutes the second plane which is half the width of the Y plane (and of the
image). Each Cb belongs to two pixels. For example,
Cb<subscript>0</subscript> belongs to Y'<subscript>00</subscript>,
Y'<subscript>01</subscript>. The Cr data, just like the Cb plane, is
in the third plane. </para>
<para><constant>V4L2_PIX_FMT_YVU422M</constant> is the same except
the Cr data is stored in the second plane and the Cb data in the third plane.
</para>
<para>If the Y plane has pad bytes after each row, then the Cb
and Cr planes have half as many pad bytes after their rows. In other
words, two Cx rows (including padding) is exactly as long as one Y row
(including padding).</para>
<para><constant>V4L2_PIX_FMT_YUV422M</constant> and
<constant>V4L2_PIX_FMT_YVU422M</constant> are intended to be
used only in drivers and applications that support the multi-planar API,
described in <xref linkend="planar-apis"/>. </para>
<example>
<title><constant>V4L2_PIX_FMT_YUV422M</constant> 4 &times; 4
pixel image</title>
<formalpara>
<title>Byte Order.</title>
<para>Each cell is one byte.
<informaltable frame="none">
<tgroup cols="5" align="center">
<colspec align="left" colwidth="2*" />
<tbody valign="top">
<row>
<entry>start0&nbsp;+&nbsp;0:</entry>
<entry>Y'<subscript>00</subscript></entry>
<entry>Y'<subscript>01</subscript></entry>
<entry>Y'<subscript>02</subscript></entry>
<entry>Y'<subscript>03</subscript></entry>
</row>
<row>
<entry>start0&nbsp;+&nbsp;4:</entry>
<entry>Y'<subscript>10</subscript></entry>
<entry>Y'<subscript>11</subscript></entry>
<entry>Y'<subscript>12</subscript></entry>
<entry>Y'<subscript>13</subscript></entry>
</row>
<row>
<entry>start0&nbsp;+&nbsp;8:</entry>
<entry>Y'<subscript>20</subscript></entry>
<entry>Y'<subscript>21</subscript></entry>
<entry>Y'<subscript>22</subscript></entry>
<entry>Y'<subscript>23</subscript></entry>
</row>
<row>
<entry>start0&nbsp;+&nbsp;12:</entry>
<entry>Y'<subscript>30</subscript></entry>
<entry>Y'<subscript>31</subscript></entry>
<entry>Y'<subscript>32</subscript></entry>
<entry>Y'<subscript>33</subscript></entry>
</row>
<row><entry></entry></row>
<row>
<entry>start1&nbsp;+&nbsp;0:</entry>
<entry>Cb<subscript>00</subscript></entry>
<entry>Cb<subscript>01</subscript></entry>
</row>
<row>
<entry>start1&nbsp;+&nbsp;2:</entry>
<entry>Cb<subscript>10</subscript></entry>
<entry>Cb<subscript>11</subscript></entry>
</row>
<row>
<entry>start1&nbsp;+&nbsp;4:</entry>
<entry>Cb<subscript>20</subscript></entry>
<entry>Cb<subscript>21</subscript></entry>
</row>
<row>
<entry>start1&nbsp;+&nbsp;6:</entry>
<entry>Cb<subscript>30</subscript></entry>
<entry>Cb<subscript>31</subscript></entry>
</row>
<row><entry></entry></row>
<row>
<entry>start2&nbsp;+&nbsp;0:</entry>
<entry>Cr<subscript>00</subscript></entry>
<entry>Cr<subscript>01</subscript></entry>
</row>
<row>
<entry>start2&nbsp;+&nbsp;2:</entry>
<entry>Cr<subscript>10</subscript></entry>
<entry>Cr<subscript>11</subscript></entry>
</row>
<row>
<entry>start2&nbsp;+&nbsp;4:</entry>
<entry>Cr<subscript>20</subscript></entry>
<entry>Cr<subscript>21</subscript></entry>
</row>
<row>
<entry>start2&nbsp;+&nbsp;6:</entry>
<entry>Cr<subscript>30</subscript></entry>
<entry>Cr<subscript>31</subscript></entry>
</row>
</tbody>
</tgroup>
</informaltable>
</para>
</formalpara>
<formalpara>
<title>Color Sample Location.</title>
<para>
<informaltable frame="none">
<tgroup cols="7" align="center">
<tbody valign="top">
<row>
<entry></entry>
<entry>0</entry><entry></entry><entry>1</entry><entry></entry>
<entry>2</entry><entry></entry><entry>3</entry>
</row>
<row>
<entry>0</entry>
<entry>Y</entry><entry>C</entry><entry>Y</entry><entry></entry>
<entry>Y</entry><entry>C</entry><entry>Y</entry>
</row>
<row>
<entry>1</entry>
<entry>Y</entry><entry>C</entry><entry>Y</entry><entry></entry>
<entry>Y</entry><entry>C</entry><entry>Y</entry>
</row>
<row>
<entry>2</entry>
<entry>Y</entry><entry>C</entry><entry>Y</entry><entry></entry>
<entry>Y</entry><entry>C</entry><entry>Y</entry>
</row>
<row>
<entry>3</entry>
<entry>Y</entry><entry>C</entry><entry>Y</entry><entry></entry>
<entry>Y</entry><entry>C</entry><entry>Y</entry>
</row>
</tbody>
</tgroup>
</informaltable>
</para>
</formalpara>
</example>
</refsect1>
</refentry>

177
Documentation/DocBook/media/v4l/pixfmt-yuv444m.xml Normal file
View File

@ -0,0 +1,177 @@
<refentry>
<refmeta>
<refentrytitle>V4L2_PIX_FMT_YUV444M ('YM24'), V4L2_PIX_FMT_YVU444M ('YM42')</refentrytitle>
&manvol;
</refmeta>
<refnamediv>
<refname id="V4L2-PIX-FMT-YUV444M"><constant>V4L2_PIX_FMT_YUV444M</constant></refname>
<refname id="V4L2-PIX-FMT-YVU444M"><constant>V4L2_PIX_FMT_YVU444M</constant></refname>
<refpurpose>Planar formats with full horizontal resolution, also
known as YUV and YVU 4:4:4</refpurpose>
</refnamediv>
<refsect1>
<title>Description</title>
<para>This is a multi-planar format, as opposed to a packed format.
The three components are separated into three sub-images or planes.</para>
<para>The Y plane is first. The Y plane has one byte per pixel.
For <constant>V4L2_PIX_FMT_YUV444M</constant> the Cb data
constitutes the second plane which is the same width and height as the Y plane
(and as the image). The Cr data, just like the Cb plane, is in the third plane.
</para>
<para><constant>V4L2_PIX_FMT_YVU444M</constant> is the same except
the Cr data is stored in the second plane and the Cb data in the third plane.
</para>
<para>If the Y plane has pad bytes after each row, then the Cb
and Cr planes have the same number of pad bytes after their rows.</para>
<para><constant>V4L2_PIX_FMT_YUV444M</constant> and
<constant>V4L2_PIX_FMT_YUV444M</constant> are intended to be
used only in drivers and applications that support the multi-planar API,
described in <xref linkend="planar-apis"/>. </para>
<example>
<title><constant>V4L2_PIX_FMT_YUV444M</constant> 4 &times; 4
pixel image</title>
<formalpara>
<title>Byte Order.</title>
<para>Each cell is one byte.
<informaltable frame="none">
<tgroup cols="5" align="center">
<colspec align="left" colwidth="2*" />
<tbody valign="top">
<row>
<entry>start0&nbsp;+&nbsp;0:</entry>
<entry>Y'<subscript>00</subscript></entry>
<entry>Y'<subscript>01</subscript></entry>
<entry>Y'<subscript>02</subscript></entry>
<entry>Y'<subscript>03</subscript></entry>
</row>
<row>
<entry>start0&nbsp;+&nbsp;4:</entry>
<entry>Y'<subscript>10</subscript></entry>
<entry>Y'<subscript>11</subscript></entry>
<entry>Y'<subscript>12</subscript></entry>
<entry>Y'<subscript>13</subscript></entry>
</row>
<row>
<entry>start0&nbsp;+&nbsp;8:</entry>
<entry>Y'<subscript>20</subscript></entry>
<entry>Y'<subscript>21</subscript></entry>
<entry>Y'<subscript>22</subscript></entry>
<entry>Y'<subscript>23</subscript></entry>
</row>
<row>
<entry>start0&nbsp;+&nbsp;12:</entry>
<entry>Y'<subscript>30</subscript></entry>
<entry>Y'<subscript>31</subscript></entry>
<entry>Y'<subscript>32</subscript></entry>
<entry>Y'<subscript>33</subscript></entry>
</row>
<row><entry></entry></row>
<row>
<entry>start1&nbsp;+&nbsp;0:</entry>
<entry>Cb<subscript>00</subscript></entry>
<entry>Cb<subscript>01</subscript></entry>
<entry>Cb<subscript>02</subscript></entry>
<entry>Cb<subscript>03</subscript></entry>
</row>
<row>
<entry>start1&nbsp;+&nbsp;4:</entry>
<entry>Cb<subscript>10</subscript></entry>
<entry>Cb<subscript>11</subscript></entry>
<entry>Cb<subscript>12</subscript></entry>
<entry>Cb<subscript>13</subscript></entry>
</row>
<row>
<entry>start1&nbsp;+&nbsp;8:</entry>
<entry>Cb<subscript>20</subscript></entry>
<entry>Cb<subscript>21</subscript></entry>
<entry>Cb<subscript>22</subscript></entry>
<entry>Cb<subscript>23</subscript></entry>
</row>
<row>
<entry>start1&nbsp;+&nbsp;12:</entry>
<entry>Cb<subscript>20</subscript></entry>
<entry>Cb<subscript>21</subscript></entry>
<entry>Cb<subscript>32</subscript></entry>
<entry>Cb<subscript>33</subscript></entry>
</row>
<row><entry></entry></row>
<row>
<entry>start2&nbsp;+&nbsp;0:</entry>
<entry>Cr<subscript>00</subscript></entry>
<entry>Cr<subscript>01</subscript></entry>
<entry>Cr<subscript>02</subscript></entry>
<entry>Cr<subscript>03</subscript></entry>
</row>
<row>
<entry>start2&nbsp;+&nbsp;4:</entry>
<entry>Cr<subscript>10</subscript></entry>
<entry>Cr<subscript>11</subscript></entry>
<entry>Cr<subscript>12</subscript></entry>
<entry>Cr<subscript>13</subscript></entry>
</row>
<row>
<entry>start2&nbsp;+&nbsp;8:</entry>
<entry>Cr<subscript>20</subscript></entry>
<entry>Cr<subscript>21</subscript></entry>
<entry>Cr<subscript>22</subscript></entry>
<entry>Cr<subscript>23</subscript></entry>
</row>
<row>
<entry>start2&nbsp;+&nbsp;12:</entry>
<entry>Cr<subscript>30</subscript></entry>
<entry>Cr<subscript>31</subscript></entry>
<entry>Cr<subscript>32</subscript></entry>
<entry>Cr<subscript>33</subscript></entry>
</row>
</tbody>
</tgroup>
</informaltable>
</para>
</formalpara>
<formalpara>
<title>Color Sample Location.</title>
<para>
<informaltable frame="none">
<tgroup cols="7" align="center">
<tbody valign="top">
<row>
<entry></entry>
<entry>0</entry><entry></entry><entry>1</entry><entry></entry>
<entry>2</entry><entry></entry><entry>3</entry>
</row>
<row>
<entry>0</entry>
<entry>YC</entry><entry></entry><entry>YC</entry><entry></entry>
<entry>YC</entry><entry></entry><entry>YC</entry>
</row>
<row>
<entry>1</entry>
<entry>YC</entry><entry></entry><entry>YC</entry><entry></entry>
<entry>YC</entry><entry></entry><entry>YC</entry>
</row>
<row>
<entry>2</entry>
<entry>YC</entry><entry></entry><entry>YC</entry><entry></entry>
<entry>YC</entry><entry></entry><entry>YC</entry>
</row>
<row>
<entry>3</entry>
<entry>YC</entry><entry></entry><entry>YC</entry><entry></entry>
<entry>YC</entry><entry></entry><entry>YC</entry>
</row>
</tbody>
</tgroup>
</informaltable>
</para>
</formalpara>
</example>
</refsect1>
</refentry>

154
Documentation/DocBook/media/v4l/pixfmt-yvu420m.xml
View File

@ -1,154 +0,0 @@
<refentry id="V4L2-PIX-FMT-YVU420M">
<refmeta>
<refentrytitle>V4L2_PIX_FMT_YVU420M ('YM21')</refentrytitle>
&manvol;
</refmeta>
<refnamediv>
<refname> <constant>V4L2_PIX_FMT_YVU420M</constant></refname>
<refpurpose>Variation of <constant>V4L2_PIX_FMT_YVU420</constant>
with planes non contiguous in memory. </refpurpose>
</refnamediv>
<refsect1>
<title>Description</title>
<para>This is a multi-planar format, as opposed to a packed format.
The three components are separated into three sub-images or planes.
The Y plane is first. The Y plane has one byte per pixel. The Cr data
constitutes the second plane which is half the width and half
the height of the Y plane (and of the image). Each Cr belongs to four
pixels, a two-by-two square of the image. For example,
Cr<subscript>0</subscript> belongs to Y'<subscript>00</subscript>,
Y'<subscript>01</subscript>, Y'<subscript>10</subscript>, and
Y'<subscript>11</subscript>. The Cb data, just like the Cr plane, constitutes
the third plane. </para>
<para>If the Y plane has pad bytes after each row, then the Cr
and Cb planes have half as many pad bytes after their rows. In other
words, two Cx rows (including padding) is exactly as long as one Y row
(including padding).</para>
<para><constant>V4L2_PIX_FMT_YVU420M</constant> is intended to be
used only in drivers and applications that support the multi-planar API,
described in <xref linkend="planar-apis"/>. </para>
<example>
<title><constant>V4L2_PIX_FMT_YVU420M</constant> 4 &times; 4
pixel image</title>
<formalpara>
<title>Byte Order.</title>
<para>Each cell is one byte.
<informaltable frame="none">
<tgroup cols="5" align="center">
<colspec align="left" colwidth="2*" />
<tbody valign="top">
<row>
<entry>start0&nbsp;+&nbsp;0:</entry>
<entry>Y'<subscript>00</subscript></entry>
<entry>Y'<subscript>01</subscript></entry>
<entry>Y'<subscript>02</subscript></entry>
<entry>Y'<subscript>03</subscript></entry>
</row>
<row>
<entry>start0&nbsp;+&nbsp;4:</entry>
<entry>Y'<subscript>10</subscript></entry>
<entry>Y'<subscript>11</subscript></entry>
<entry>Y'<subscript>12</subscript></entry>
<entry>Y'<subscript>13</subscript></entry>
</row>
<row>
<entry>start0&nbsp;+&nbsp;8:</entry>
<entry>Y'<subscript>20</subscript></entry>
<entry>Y'<subscript>21</subscript></entry>
<entry>Y'<subscript>22</subscript></entry>
<entry>Y'<subscript>23</subscript></entry>
</row>
<row>
<entry>start0&nbsp;+&nbsp;12:</entry>
<entry>Y'<subscript>30</subscript></entry>
<entry>Y'<subscript>31</subscript></entry>
<entry>Y'<subscript>32</subscript></entry>
<entry>Y'<subscript>33</subscript></entry>
</row>
<row><entry></entry></row>
<row>
<entry>start1&nbsp;+&nbsp;0:</entry>
<entry>Cr<subscript>00</subscript></entry>
<entry>Cr<subscript>01</subscript></entry>
</row>
<row>
<entry>start1&nbsp;+&nbsp;2:</entry>
<entry>Cr<subscript>10</subscript></entry>
<entry>Cr<subscript>11</subscript></entry>
</row>
<row><entry></entry></row>
<row>
<entry>start2&nbsp;+&nbsp;0:</entry>
<entry>Cb<subscript>00</subscript></entry>
<entry>Cb<subscript>01</subscript></entry>
</row>
<row>
<entry>start2&nbsp;+&nbsp;2:</entry>
<entry>Cb<subscript>10</subscript></entry>
<entry>Cb<subscript>11</subscript></entry>
</row>
</tbody>
</tgroup>
</informaltable>
</para>
</formalpara>
<formalpara>
<title>Color Sample Location.</title>
<para>
<informaltable frame="none">
<tgroup cols="7" align="center">
<tbody valign="top">
<row>
<entry></entry>
<entry>0</entry><entry></entry><entry>1</entry><entry></entry>
<entry>2</entry><entry></entry><entry>3</entry>
</row>
<row>
<entry>0</entry>
<entry>Y</entry><entry></entry><entry>Y</entry><entry></entry>
<entry>Y</entry><entry></entry><entry>Y</entry>
</row>
<row>
<entry></entry>
<entry></entry><entry>C</entry><entry></entry><entry></entry>
<entry></entry><entry>C</entry><entry></entry>
</row>
<row>
<entry>1</entry>
<entry>Y</entry><entry></entry><entry>Y</entry><entry></entry>
<entry>Y</entry><entry></entry><entry>Y</entry>
</row>
<row>
<entry></entry>
</row>
<row>
<entry>2</entry>
<entry>Y</entry><entry></entry><entry>Y</entry><entry></entry>
<entry>Y</entry><entry></entry><entry>Y</entry>
</row>
<row>
<entry></entry>
<entry></entry><entry>C</entry><entry></entry><entry></entry>
<entry></entry><entry>C</entry><entry></entry>
</row>
<row>
<entry>3</entry>
<entry>Y</entry><entry></entry><entry>Y</entry><entry></entry>
<entry>Y</entry><entry></entry><entry>Y</entry>
</row>
</tbody>
</tgroup>
</informaltable>
</para>
</formalpara>
</example>
</refsect1>
</refentry>

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

@ -0,0 +1,81 @@
<refentry id="V4L2-PIX-FMT-Z16">
<refmeta>
<refentrytitle>V4L2_PIX_FMT_Z16 ('Z16 ')</refentrytitle>
&manvol;
</refmeta>
<refnamediv>
<refname><constant>V4L2_PIX_FMT_Z16</constant></refname>
<refpurpose>Interleaved grey-scale image, e.g. from a stereo-pair</refpurpose>
</refnamediv>
<refsect1>
<title>Description</title>
<para>This is a 16-bit format, representing depth data. Each pixel is a
distance to the respective point in the image coordinates. Distance unit can
vary and has to be negotiated with the device separately. Each pixel is stored
in a 16-bit word in the little endian byte order.
</para>
<example>
<title><constant>V4L2_PIX_FMT_Z16</constant> 4 &times; 4
pixel image</title>
<formalpara>
<title>Byte Order.</title>
<para>Each cell is one byte.
<informaltable frame="none">
<tgroup cols="9" align="center">
<colspec align="left" colwidth="2*" />
<tbody valign="top">
<row>
<entry>start&nbsp;+&nbsp;0:</entry>
<entry>Z<subscript>00low</subscript></entry>
<entry>Z<subscript>00high</subscript></entry>
<entry>Z<subscript>01low</subscript></entry>
<entry>Z<subscript>01high</subscript></entry>
<entry>Z<subscript>02low</subscript></entry>
<entry>Z<subscript>02high</subscript></entry>
<entry>Z<subscript>03low</subscript></entry>
<entry>Z<subscript>03high</subscript></entry>
</row>
<row>
<entry>start&nbsp;+&nbsp;8:</entry>
<entry>Z<subscript>10low</subscript></entry>
<entry>Z<subscript>10high</subscript></entry>
<entry>Z<subscript>11low</subscript></entry>
<entry>Z<subscript>11high</subscript></entry>
<entry>Z<subscript>12low</subscript></entry>
<entry>Z<subscript>12high</subscript></entry>
<entry>Z<subscript>13low</subscript></entry>
<entry>Z<subscript>13high</subscript></entry>
</row>
<row>
<entry>start&nbsp;+&nbsp;16:</entry>
<entry>Z<subscript>20low</subscript></entry>
<entry>Z<subscript>20high</subscript></entry>
<entry>Z<subscript>21low</subscript></entry>
<entry>Z<subscript>21high</subscript></entry>
<entry>Z<subscript>22low</subscript></entry>
<entry>Z<subscript>22high</subscript></entry>
<entry>Z<subscript>23low</subscript></entry>
<entry>Z<subscript>23high</subscript></entry>
</row>
<row>
<entry>start&nbsp;+&nbsp;24:</entry>
<entry>Z<subscript>30low</subscript></entry>
<entry>Z<subscript>30high</subscript></entry>
<entry>Z<subscript>31low</subscript></entry>
<entry>Z<subscript>31high</subscript></entry>
<entry>Z<subscript>32low</subscript></entry>
<entry>Z<subscript>32high</subscript></entry>
<entry>Z<subscript>33low</subscript></entry>
<entry>Z<subscript>33high</subscript></entry>
</row>
</tbody>
</tgroup>
</informaltable>
</para>
</formalpara>
</example>
</refsect1>
</refentry>

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

@ -1620,6 +1620,8 @@ information.</para>
&sub-y10b;
&sub-y16;
&sub-y16-be;
&sub-y8i;
&sub-y12i;
&sub-uv8;
&sub-yuyv;
&sub-uyvy;
@ -1628,7 +1630,8 @@ information.</para>
&sub-y41p;
&sub-yuv420;
&sub-yuv420m;
&sub-yvu420m;
&sub-yuv422m;
&sub-yuv444m;
&sub-yuv410;
&sub-yuv422p;
&sub-yuv411p;
@ -1641,6 +1644,14 @@ information.</para>
&sub-m420;
</section>
<section id="depth-formats">
<title>Depth Formats</title>
<para>Depth data provides distance to points, mapped onto the image plane
</para>
&sub-z16;
</section>
<section>
<title>Compressed Formats</title>

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

@ -60,9 +60,19 @@ input</refpurpose>
automatically, similar to sensing the video standard. To do so, applications
call <constant>VIDIOC_QUERY_DV_TIMINGS</constant> with a pointer to a
&v4l2-dv-timings;. Once the hardware detects the timings, it will fill in the
timings structure.
timings structure.</para>
If the timings could not be detected because there was no signal, then
<para>Please note that drivers shall <emphasis>not</emphasis> switch timings automatically
if new timings are detected. Instead, drivers should send the
<constant>V4L2_EVENT_SOURCE_CHANGE</constant> event (if they support this) and expect
that userspace will take action by calling <constant>VIDIOC_QUERY_DV_TIMINGS</constant>.
The reason is that new timings usually mean different buffer sizes as well, and you
cannot change buffer sizes on the fly. In general, applications that receive the
Source Change event will have to call <constant>VIDIOC_QUERY_DV_TIMINGS</constant>,
and if the detected timings are valid they will have to stop streaming, set the new
timings, allocate new buffers and start streaming again.</para>
<para>If the timings could not be detected because there was no signal, then
<errorcode>ENOLINK</errorcode> is returned. If a signal was detected, but
it was unstable and the receiver could not lock to the signal, then
<errorcode>ENOLCK</errorcode> is returned. If the receiver could lock to the signal,

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

@ -59,6 +59,16 @@ then the driver will return V4L2_STD_UNKNOWN. When detection is not
possible or fails, the set must contain all standards supported by the
current video input or output.</para>
<para>Please note that drivers shall <emphasis>not</emphasis> switch the video standard
automatically if a new video standard is detected. Instead, drivers should send the
<constant>V4L2_EVENT_SOURCE_CHANGE</constant> event (if they support this) and expect
that userspace will take action by calling <constant>VIDIOC_QUERYSTD</constant>.
The reason is that a new video standard can mean different buffer sizes as well, and you
cannot change buffer sizes on the fly. In general, applications that receive the
Source Change event will have to call <constant>VIDIOC_QUERYSTD</constant>,
and if the detected video standard is valid they will have to stop streaming, set the new
standard, allocate new buffers and start streaming again.</para>
</refsect1>
<refsect1>

12
Documentation/DocBook/usb.tmpl
View File

@ -732,6 +732,18 @@ usbdev_ioctl (int fd, int ifno, unsigned request, void *param)
or SET_INTERFACE.
</para></warning></listitem></varlistentry>
<varlistentry><term>USBDEVFS_DROP_PRIVILEGES</term>
<listitem><para>This is used to relinquish the ability
to do certain operations which are considered to be
privileged on a usbfs file descriptor.
This includes claiming arbitrary interfaces, resetting
a device on which there are currently claimed interfaces
from other users, and issuing USBDEVFS_IOCTL calls.
The ioctl parameter is a 32 bit mask of interfaces
the user is allowed to claim on this file descriptor.
You may issue this ioctl more than one time to narrow
said mask.
</para></listitem></varlistentry>
</variablelist>
</sect2>

15
Documentation/HOWTO
View File

@ -68,7 +68,7 @@ For common questions and answers about the GPL, please see:
Documentation
------------
-------------
The Linux kernel source tree has a large range of documents that are
invaluable for learning how to interact with the kernel community. When
@ -187,7 +187,7 @@ apply a patch.
If you do not know where you want to start, but you want to look for
some task to start doing to join into the kernel development community,
go to the Linux Kernel Janitor's project:
http://kernelnewbies.org/KernelJanitors
http://kernelnewbies.org/KernelJanitors
It is a great place to start. It describes a list of relatively simple
problems that need to be cleaned up and fixed within the Linux kernel
source tree. Working with the developers in charge of this project, you
@ -250,11 +250,6 @@ process is as follows:
release a new -rc kernel every week.
- Process continues until the kernel is considered "ready", the
process should last around 6 weeks.
- Known regressions in each release are periodically posted to the
linux-kernel mailing list. The goal is to reduce the length of
that list to zero before declaring the kernel to be "ready," but, in
the real world, a small number of regressions often remain at
release time.
It is worth mentioning what Andrew Morton wrote on the linux-kernel
mailing list about kernel releases:
@ -263,7 +258,7 @@ mailing list about kernel releases:
preconceived timeline."
4.x.y -stable kernel tree
---------------------------
-------------------------
Kernels with 3-part versions are -stable kernels. They contain
relatively small and critical fixes for security problems or significant
regressions discovered in a given 4.x kernel.
@ -286,7 +281,7 @@ documents what kinds of changes are acceptable for the -stable tree, and
how the release process works.
4.x -git patches
------------------
----------------
These are daily snapshots of Linus' kernel tree which are managed in a
git repository (hence the name.) These patches are usually released
daily and represent the current state of Linus' tree. They are more
@ -318,7 +313,7 @@ accepted, or rejected. Most of these patchwork sites are listed at
http://patchwork.kernel.org/.
4.x -next kernel tree for integration tests
---------------------------------------------
-------------------------------------------
Before updates from subsystem trees are merged into the mainline 4.x
tree, they need to be integration-tested. For this purpose, a special
testing repository exists into which virtually all subsystem trees are

2
Documentation/SubmittingPatches
View File

@ -722,7 +722,7 @@ references.
--------------------------------
It can be helpful to manually add In-Reply-To: headers to a patch
(e.g., when using "git send email") to associate the patch with
(e.g., when using "git send-email") to associate the patch with
previous relevant discussion, e.g. to link a bug fix to the email with
the bug report. However, for a multi-patch series, it is generally
best to avoid using In-Reply-To: to link to older versions of the

2
Documentation/arm/Samsung/clksrc-change-registers.awk
View File

@ -41,7 +41,7 @@ function find_length(f)
else if (f ~ /0xf/)
return 4
printf "unknown legnth " f "\n" > "/dev/stderr"
printf "unknown length " f "\n" > "/dev/stderr"
exit
}

20
Documentation/arm64/booting.txt
View File

@ -109,7 +109,13 @@ Header notes:
1 - 4K
2 - 16K
3 - 64K
Bits 3-63: Reserved.
Bit 3: Kernel physical placement
0 - 2MB aligned base should be as close as possible
to the base of DRAM, since memory below it is not
accessible via the linear mapping
1 - 2MB aligned base may be anywhere in physical
memory
Bits 4-63: Reserved.
- When image_size is zero, a bootloader should attempt to keep as much
memory as possible free for use by the kernel immediately after the
@ -117,14 +123,14 @@ Header notes:
depending on selected features, and is effectively unbound.
The Image must be placed text_offset bytes from a 2MB aligned base
address near the start of usable system RAM and called there. Memory
below that base address is currently unusable by Linux, and therefore it
is strongly recommended that this location is the start of system RAM.
The region between the 2 MB aligned base address and the start of the
image has no special significance to the kernel, and may be used for
other purposes.
address anywhere in usable system RAM and called there. The region
between the 2 MB aligned base address and the start of the image has no
special significance to the kernel, and may be used for other purposes.
At least image_size bytes from the start of the image must be free for
use by the kernel.
NOTE: versions prior to v4.6 cannot make use of memory below the
physical offset of the Image so it is recommended that the Image be
placed as close as possible to the start of system RAM.
Any memory described to the kernel (even that below the start of the
image) which is not marked as reserved from the kernel (e.g., with a

1
Documentation/arm64/silicon-errata.txt
View File

@ -56,3 +56,4 @@ stable kernels.
| | | | |
| Cavium | ThunderX ITS | #22375, #24313 | CAVIUM_ERRATUM_22375 |
| Cavium | ThunderX GICv3 | #23154 | CAVIUM_ERRATUM_23154 |
| Cavium | ThunderX Core | #27456 | CAVIUM_ERRATUM_27456 |

93
Documentation/blockdev/cpqarray.txt
View File

@ -1,93 +0,0 @@
This driver is for Compaq's SMART2 Intelligent Disk Array Controllers.
Supported Cards:
----------------
This driver is known to work with the following cards:
* SMART (EISA)
* SMART-2/E (EISA)
* SMART-2/P
* SMART-2DH
* SMART-2SL
* SMART-221
* SMART-3100ES
* SMART-3200
* Integrated Smart Array Controller
* SA 4200
* SA 4250ES
* SA 431
* RAID LC2 Controller
It should also work with some really old Disk array adapters, but I am
unable to test against these cards:
* IDA
* IDA-2
* IAES
EISA Controllers:
-----------------
If you want to use an EISA controller you'll have to supply some
modprobe/lilo parameters. If the driver is compiled into the kernel, must
give it the controller's IO port address at boot time (it is not
necessary to specify the IRQ). For example, if you had two SMART-2/E
controllers, in EISA slots 1 and 2 you'd give it a boot argument like
this:
smart2=0x1000,0x2000
If you were loading the driver as a module, you'd give load it like this:
modprobe cpqarray eisa=0x1000,0x2000
You can use EISA and PCI adapters at the same time.
Device Naming:
--------------
You need some entries in /dev for the ida device. MAKEDEV in the /dev
directory can make device nodes for you automatically. The device setup is
as follows:
Major numbers:
72 ida0
73 ida1
74 ida2
75 ida3
76 ida4
77 ida5
78 ida6
79 ida7
Minor numbers:
b7 b6 b5 b4 b3 b2 b1 b0
|----+----| |----+----|
| |
| +-------- Partition ID (0=wholedev, 1-15 partition)
|
+-------------------- Logical Volume number
The device naming scheme is:
/dev/ida/c0d0 Controller 0, disk 0, whole device
/dev/ida/c0d0p1 Controller 0, disk 0, partition 1
/dev/ida/c0d0p2 Controller 0, disk 0, partition 2
/dev/ida/c0d0p3 Controller 0, disk 0, partition 3
/dev/ida/c1d1 Controller 1, disk 1, whole device
/dev/ida/c1d1p1 Controller 1, disk 1, partition 1
/dev/ida/c1d1p2 Controller 1, disk 1, partition 2
/dev/ida/c1d1p3 Controller 1, disk 1, partition 3
Changelog:
==========
10-28-2004 : General cleanup, syntax fixes for in-kernel driver version.
James Nelson <james4765@gmail.com>
1999 : Original Document

2
Documentation/cgroup-v1/00-INDEX
View File

@ -24,5 +24,3 @@ net_prio.txt
- Network priority cgroups details and usages.
pids.txt
- Process number cgroups details and usages.
unified-hierarchy.txt
- Description the new/next cgroup interface.

2
Documentation/cgroup-v1/cgroups.txt
View File

@ -8,7 +8,7 @@ Original copyright statements from cpusets.txt:
Portions Copyright (C) 2004 BULL SA.
Portions Copyright (c) 2004-2006 Silicon Graphics, Inc.
Modified by Paul Jackson <pj@sgi.com>
Modified by Christoph Lameter <clameter@sgi.com>
Modified by Christoph Lameter <cl@linux.com>
CONTENTS:
=========

2
Documentation/cgroup-v1/cpusets.txt
View File

@ -6,7 +6,7 @@ Written by Simon.Derr@bull.net
Portions Copyright (c) 2004-2006 Silicon Graphics, Inc.
Modified by Paul Jackson <pj@sgi.com>
Modified by Christoph Lameter <clameter@sgi.com>
Modified by Christoph Lameter <cl@linux.com>
Modified by Paul Menage <menage@google.com>
Modified by Hidetoshi Seto <seto.hidetoshi@jp.fujitsu.com>

33
Documentation/cgroup-v2.txt
View File

@ -132,6 +132,12 @@ strongly discouraged for production use. It is recommended to decide
the hierarchies and controller associations before starting using the
controllers after system boot.
During transition to v2, system management software might still
automount the v1 cgroup filesystem and so hijack all controllers
during boot, before manual intervention is possible. To make testing
and experimenting easier, the kernel parameter cgroup_no_v1= allows
disabling controllers in v1 and make them always available in v2.
2-2. Organizing Processes
@ -843,6 +849,15 @@ PAGE_SIZE multiple when read back.
Amount of memory used to cache filesystem data,
including tmpfs and shared memory.
kernel_stack
Amount of memory allocated to kernel stacks.
slab
Amount of memory used for storing in-kernel data
structures.
sock
Amount of memory used in network transmission buffers
@ -871,6 +886,16 @@ PAGE_SIZE multiple when read back.
on the internal memory management lists used by the
page reclaim algorithm
slab_reclaimable
Part of "slab" that might be reclaimed, such as
dentries and inodes.
slab_unreclaimable
Part of "slab" that cannot be reclaimed on memory
pressure.
pgfault
Total number of page faults incurred
@ -896,7 +921,7 @@ PAGE_SIZE multiple when read back.
limit, anonymous meomry of the cgroup will not be swapped out.
5-2-2. General Usage
5-2-2. Usage Guidelines
"memory.high" is the main mechanism to control memory usage.
Over-committing on high limit (sum of high limits > available memory)
@ -1368,6 +1393,12 @@ system than killing the group. Otherwise, memory.max is there to
limit this type of spillover and ultimately contain buggy or even
malicious applications.
Setting the original memory.limit_in_bytes below the current usage was
subject to a race condition, where concurrent charges could cause the
limit setting to fail. memory.max on the other hand will first set the
limit to prevent new charges, and then reclaim and OOM kill until the
new limit is met - or the task writing to memory.max is killed.
The combined memory+swap accounting and limiting is replaced by real
control over swap space.

2
Documentation/cpu-freq/intel-pstate.txt
View File

@ -25,7 +25,7 @@ callback, so cpufreq core can't request a transition to a specific frequency.
The driver provides minimum and maximum frequency limits and callbacks to set a
policy. The policy in cpufreq sysfs is referred to as the "scaling governor".
The cpufreq core can request the driver to operate in any of the two policies:
"performance: and "powersave". The driver decides which frequency to use based
"performance" and "powersave". The driver decides which frequency to use based
on the above policy selection considering minimum and maximum frequency limits.
The Intel P-State driver falls under the latter category, which implements the

23
Documentation/crypto/api-intro.txt
View File

@ -49,28 +49,33 @@ under development.
Here's an example of how to use the API:
#include <linux/crypto.h>
#include <crypto/ahash.h>
#include <linux/err.h>
#include <linux/scatterlist.h>
struct scatterlist sg[2];
char result[128];
struct crypto_hash *tfm;
struct hash_desc desc;
struct crypto_ahash *tfm;
struct ahash_request *req;
tfm = crypto_alloc_hash("md5", 0, CRYPTO_ALG_ASYNC);
tfm = crypto_alloc_ahash("md5", 0, CRYPTO_ALG_ASYNC);
if (IS_ERR(tfm))
fail();
/* ... set up the scatterlists ... */
desc.tfm = tfm;
desc.flags = 0;
if (crypto_hash_digest(&desc, sg, 2, result))
req = ahash_request_alloc(tfm, GFP_ATOMIC);
if (!req)
fail();
ahash_request_set_callback(req, 0, NULL, NULL);
ahash_request_set_crypt(req, sg, result, 2);
crypto_free_hash(tfm);
if (crypto_ahash_digest(req))
fail();
ahash_request_free(req);
crypto_free_ahash(tfm);
Many real examples are available in the regression test module (tcrypt.c).

39
Documentation/device-mapper/cache-policies.txt
View File

@ -28,51 +28,16 @@ Overview of supplied cache replacement policies
multiqueue (mq)
---------------
This policy has been deprecated in favor of the smq policy (see below).
This policy is now an alias for smq (see below).
The multiqueue policy has three sets of 16 queues: one set for entries
waiting for the cache and another two for those in the cache (a set for
clean entries and a set for dirty entries).
The following tunables are accepted, but have no effect:
Cache entries in the queues are aged based on logical time. Entry into
the cache is based on variable thresholds and queue selection is based
on hit count on entry. The policy aims to take different cache miss
costs into account and to adjust to varying load patterns automatically.
Message and constructor argument pairs are:
'sequential_threshold <#nr_sequential_ios>'
'random_threshold <#nr_random_ios>'
'read_promote_adjustment <value>'
'write_promote_adjustment <value>'
'discard_promote_adjustment <value>'
The sequential threshold indicates the number of contiguous I/Os
required before a stream is treated as sequential. Once a stream is
considered sequential it will bypass the cache. The random threshold
is the number of intervening non-contiguous I/Os that must be seen
before the stream is treated as random again.
The sequential and random thresholds default to 512 and 4 respectively.
Large, sequential I/Os are probably better left on the origin device
since spindles tend to have good sequential I/O bandwidth. The
io_tracker counts contiguous I/Os to try to spot when the I/O is in one
of these sequential modes. But there are use-cases for wanting to
promote sequential blocks to the cache (e.g. fast application startup).
If sequential threshold is set to 0 the sequential I/O detection is
disabled and sequential I/O will no longer implicitly bypass the cache.
Setting the random threshold to 0 does _not_ disable the random I/O
stream detection.
Internally the mq policy determines a promotion threshold. If the hit
count of a block not in the cache goes above this threshold it gets
promoted to the cache. The read, write and discard promote adjustment
tunables allow you to tweak the promotion threshold by adding a small
value based on the io type. They default to 4, 8 and 1 respectively.
If you're trying to quickly warm a new cache device you may wish to
reduce these to encourage promotion. Remember to switch them back to
their defaults after the cache fills though.
Stochastic multiqueue (smq)
---------------------------

49
Documentation/devicetree/bindings/arm/altera/socfpga-eccmgr.txt Normal file
View File

@ -0,0 +1,49 @@
Altera SoCFPGA ECC Manager
This driver uses the EDAC framework to implement the SOCFPGA ECC Manager.
The ECC Manager counts and corrects single bit errors and counts/handles
double bit errors which are uncorrectable.
Required Properties:
- compatible : Should be "altr,socfpga-ecc-manager"
- #address-cells: must be 1
- #size-cells: must be 1
- ranges : standard definition, should translate from local addresses
Subcomponents:
L2 Cache ECC
Required Properties:
- compatible : Should be "altr,socfpga-l2-ecc"
- reg : Address and size for ECC error interrupt clear registers.
- interrupts : Should be single bit error interrupt, then double bit error
interrupt. Note the rising edge type.
On Chip RAM ECC
Required Properties:
- compatible : Should be "altr,socfpga-ocram-ecc"
- reg : Address and size for ECC error interrupt clear registers.
- iram : phandle to On-Chip RAM definition.
- interrupts : Should be single bit error interrupt, then double bit error
interrupt. Note the rising edge type.
Example:
eccmgr: eccmgr@ffd08140 {
compatible = "altr,socfpga-ecc-manager";
#address-cells = <1>;
#size-cells = <1>;
ranges;
l2-ecc@ffd08140 {
compatible = "altr,socfpga-l2-ecc";
reg = <0xffd08140 0x4>;
interrupts = <0 36 1>, <0 37 1>;
};
ocram-ecc@ffd08144 {
compatible = "altr,socfpga-ocram-ecc";
reg = <0xffd08144 0x4>;
iram = <&ocram>;
interrupts = <0 178 1>, <0 179 1>;
};
};

4
Documentation/devicetree/bindings/arm/arm-boards
View File

@ -123,7 +123,9 @@ Required nodes:
- syscon: some subnode of the RealView SoC node must be a
system controller node pointing to the control registers,
with the compatible string set to one of these tuples:
with the compatible string set to one of these:
"arm,realview-eb11mp-revb-syscon", "arm,realview-eb-syscon", "syscon"
"arm,realview-eb11mp-revc-syscon", "arm,realview-eb-syscon", "syscon"
"arm,realview-eb-syscon", "syscon"
"arm,realview-pb1176-syscon", "syscon"
"arm,realview-pb11mp-syscon", "syscon"

2
Documentation/devicetree/bindings/arm/cpus.txt
View File

@ -250,7 +250,7 @@ nodes to be present and contain the properties described below.
Usage: optional
Value type: <prop-encoded-array>
Definition: A u32 value that represents the running time dynamic
power coefficient in units of mW/MHz/uVolt^2. The
power coefficient in units of mW/MHz/uV^2. The
coefficient can either be calculated from power
measurements or derived by analysis.

38
Documentation/devicetree/bindings/arm/fw-cfg.txt
View File

@ -11,43 +11,9 @@ QEMU exposes the control and data register to ARM guests as memory mapped
registers; their location is communicated to the guest's UEFI firmware in the
DTB that QEMU places at the bottom of the guest's DRAM.
The guest writes a selector value (a key) to the selector register, and then
can read the corresponding data (produced by QEMU) via the data register. If
the selected entry is writable, the guest can rewrite it through the data
register.
The authoritative guest-side hardware interface documentation to the fw_cfg
device can be found in "docs/specs/fw_cfg.txt" in the QEMU source tree.
The selector register takes keys in big endian byte order.
The data register allows accesses with 8, 16, 32 and 64-bit width (only at
offset 0 of the register). Accesses larger than a byte are interpreted as
arrays, bundled together only for better performance. The bytes constituting
such a word, in increasing address order, correspond to the bytes that would
have been transferred by byte-wide accesses in chronological order.
The interface allows guest firmware to download various parameters and blobs
that affect how the firmware works and what tables it installs for the guest
OS. For example, boot order of devices, ACPI tables, SMBIOS tables, kernel and
initrd images for direct kernel booting, virtual machine UUID, SMP information,
virtual NUMA topology, and so on.
The authoritative registry of the valid selector values and their meanings is
the QEMU source code; the structure of the data blobs corresponding to the
individual key values is also defined in the QEMU source code.
The presence of the registers can be verified by selecting the "signature" blob
with key 0x0000, and reading four bytes from the data register. The returned
signature is "QEMU".
The outermost protocol (involving the write / read sequences of the control and
data registers) is expected to be versioned, and/or described by feature bits.
The interface revision / feature bitmap can be retrieved with key 0x0001. The
blob to be read from the data register has size 4, and it is to be interpreted
as a uint32_t value in little endian byte order. The current value
(corresponding to the above outer protocol) is zero.
The guest kernel is not expected to use these registers (although it is
certainly allowed to); the device tree bindings are documented here because
this is where device tree bindings reside in general.
Required properties:

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

@ -23,6 +23,7 @@ Optional properties:
during suspend.
- ti,no-reset-on-init: When present, the module should not be reset at init
- ti,no-idle-on-init: When present, the module should not be idled at init
- ti,no-idle: When present, the module is never allowed to idle.
Example:

1
Documentation/devicetree/bindings/ata/ahci-platform.txt
View File

@ -11,6 +11,7 @@ Required properties:
- compatible : compatible string, one of:
- "allwinner,sun4i-a10-ahci"
- "hisilicon,hisi-ahci"
- "cavium,octeon-7130-ahci"
- "ibm,476gtr-ahci"
- "marvell,armada-380-ahci"
- "snps,dwc-ahci"

1
Documentation/devicetree/bindings/dma/arm-pl330.txt
View File

@ -15,6 +15,7 @@ Optional properties:
cells in the dmas property of client device.
- dma-channels: contains the total number of DMA channels supported by the DMAC
- dma-requests: contains the total number of DMA requests supported by the DMAC
- arm,pl330-broken-no-flushp: quirk for avoiding to execute DMAFLUSHP
Example:

89
Documentation/devicetree/bindings/dma/qcom_hidma_mgmt.txt Normal file
View File

@ -0,0 +1,89 @@
Qualcomm Technologies HIDMA Management interface
Qualcomm Technologies HIDMA is a high speed DMA device. It only supports
memcpy and memset capabilities. It has been designed for virtualized
environments.
Each HIDMA HW instance consists of multiple DMA channels. These channels
share the same bandwidth. The bandwidth utilization can be parititioned
among channels based on the priority and weight assignments.
There are only two priority levels and 15 weigh assignments possible.
Other parameters here determine how much of the system bus this HIDMA
instance can use like maximum read/write request and and number of bytes to
read/write in a single burst.
Main node required properties:
- compatible: "qcom,hidma-mgmt-1.0";
- reg: Address range for DMA device
- dma-channels: Number of channels supported by this DMA controller.
- max-write-burst-bytes: Maximum write burst in bytes that HIDMA can
occupy the bus for in a single transaction. A memcpy requested is
fragmented to multiples of this amount. This parameter is used while
writing into destination memory. Setting this value incorrectly can
starve other peripherals in the system.
- max-read-burst-bytes: Maximum read burst in bytes that HIDMA can
occupy the bus for in a single transaction. A memcpy request is
fragmented to multiples of this amount. This parameter is used while
reading the source memory. Setting this value incorrectly can starve
other peripherals in the system.
- max-write-transactions: This value is how many times a write burst is
applied back to back while writing to the destination before yielding
the bus.
- max-read-transactions: This value is how many times a read burst is
applied back to back while reading the source before yielding the bus.
- channel-reset-timeout-cycles: Channel reset timeout in cycles for this SOC.
Once a reset is applied to the HW, HW starts a timer for reset operation
to confirm. If reset is not completed within this time, HW reports reset
failure.
Sub-nodes:
HIDMA has one or more DMA channels that are used to move data from one
memory location to another.
When the OS is not in control of the management interface (i.e. it's a guest),
the channel nodes appear on their own, not under a management node.
Required properties:
- compatible: must contain "qcom,hidma-1.0"
- reg: Addresses for the transfer and event channel
- interrupts: Should contain the event interrupt
- desc-count: Number of asynchronous requests this channel can handle
- iommus: required a iommu node
Example:
Hypervisor OS configuration:
hidma-mgmt@f9984000 = {
compatible = "qcom,hidma-mgmt-1.0";
reg = <0xf9984000 0x15000>;
dma-channels = <6>;
max-write-burst-bytes = <1024>;
max-read-burst-bytes = <1024>;
max-write-transactions = <31>;
max-read-transactions = <31>;
channel-reset-timeout-cycles = <0x500>;
hidma_24: dma-controller@0x5c050000 {
compatible = "qcom,hidma-1.0";
reg = <0 0x5c050000 0x0 0x1000>,
<0 0x5c0b0000 0x0 0x1000>;
interrupts = <0 389 0>;
desc-count = <10>;
iommus = <&system_mmu>;
};
};
Guest OS configuration:
hidma_24: dma-controller@0x5c050000 {
compatible = "qcom,hidma-1.0";
reg = <0 0x5c050000 0x0 0x1000>,
<0 0x5c0b0000 0x0 0x1000>;
interrupts = <0 389 0>;
desc-count = <10>;
iommus = <&system_mmu>;
};

10
Documentation/devicetree/bindings/edac/apm-xgene-edac.txt
View File

@ -16,6 +16,10 @@ Required properties:
- regmap-mcba : Regmap of the MCB-A (memory bridge) resource.
- regmap-mcbb : Regmap of the MCB-B (memory bridge) resource.
- regmap-efuse : Regmap of the PMD efuse resource.
- regmap-rb : Regmap of the register bus resource. This property
is optional only for compatibility. If the RB
error conditions are not cleared, it will
continuously generate interrupt.
- reg : First resource shall be the CPU bus (PCP) resource.
- interrupts : Interrupt-specifier for MCU, PMD, L3, or SoC error
IRQ(s).
@ -64,6 +68,11 @@ Example:
reg = <0x0 0x1054a000 0x0 0x20>;
};
rb: rb@7e000000 {
compatible = "apm,xgene-rb", "syscon";
reg = <0x0 0x7e000000 0x0 0x10>;
};
edac@78800000 {
compatible = "apm,xgene-edac";
#address-cells = <2>;
@ -73,6 +82,7 @@ Example:
regmap-mcba = <&mcba>;
regmap-mcbb = <&mcbb>;
regmap-efuse = <&efuse>;
regmap-rb = <&rb>;
reg = <0x0 0x78800000 0x0 0x100>;
interrupts = <0x0 0x20 0x4>,
<0x0 0x21 0x4>,

17
Documentation/devicetree/bindings/goldfish/audio.txt Normal file
View File

@ -0,0 +1,17 @@
Android Goldfish Audio
Android goldfish audio device generated by android emulator.
Required properties:
- compatible : should contain "google,goldfish-audio" to match emulator
- reg : <registers mapping>
- interrupts : <interrupt mapping>
Example:
goldfish_audio@9030000 {
compatible = "google,goldfish-audio";
reg = <0x9030000 0x100>;
interrupts = <0x4>;
};

17
Documentation/devicetree/bindings/goldfish/battery.txt Normal file
View File

@ -0,0 +1,17 @@
Android Goldfish Battery
Android goldfish battery device generated by android emulator.
Required properties:
- compatible : should contain "google,goldfish-battery" to match emulator
- reg : <registers mapping>
- interrupts : <interrupt mapping>
Example:
goldfish_battery@9020000 {
compatible = "google,goldfish-battery";
reg = <0x9020000 0x1000>;
interrupts = <0x3>;
};

17
Documentation/devicetree/bindings/goldfish/events.txt Normal file
View File

@ -0,0 +1,17 @@
Android Goldfish Events Keypad
Android goldfish events keypad device generated by android emulator.
Required properties:
- compatible : should contain "google,goldfish-events-keypad" to match emulator
- reg : <registers mapping>
- interrupts : <interrupt mapping>
Example:
goldfish-events@9040000 {
compatible = "google,goldfish-events-keypad";
reg = <0x9040000 0x1000>;
interrupts = <0x5>;
};

17
Documentation/devicetree/bindings/goldfish/pipe.txt Normal file
View File

@ -0,0 +1,17 @@
Android Goldfish QEMU Pipe
Andorid pipe virtual device generated by android emulator.
Required properties:
- compatible : should contain "google,android-pipe" to match emulator
- reg : <registers mapping>
- interrupts : <interrupt mapping>
Example:
android_pipe@a010000 {
compatible = "google,android-pipe";
reg = <ff018000 0x2000>;
interrupts = <0x12>;
};

17
Documentation/devicetree/bindings/goldfish/tty.txt Normal file
View File

@ -0,0 +1,17 @@
Android Goldfish TTY
Android goldfish tty device generated by android emulator.
Required properties:
- compatible : should contain "google,goldfish-tty" to match emulator
- reg : <registers mapping>
- interrupts : <interrupt mapping>
Example:
goldfish_tty@1f004000 {
compatible = "google,goldfish-tty";
reg = <0x1f004000 0x1000>;
interrupts = <0xc>;
};

4
Documentation/devicetree/bindings/gpio/gpio-altera.txt
View File

@ -12,7 +12,7 @@ Required properties:
- #interrupt-cells : Should be 1. The interrupt type is fixed in the hardware.
- The first cell is the GPIO offset number within the GPIO controller.
- interrupts: Specify the interrupt.
- altr,interrupt-trigger: Specifies the interrupt trigger type the GPIO
- altr,interrupt-type: Specifies the interrupt trigger type the GPIO
hardware is synthesized. This field is required if the Altera GPIO controller
used has IRQ enabled as the interrupt type is not software controlled,
but hardware synthesized. Required if GPIO is used as an interrupt
@ -35,7 +35,7 @@ gpio_altr: gpio@0xff200000 {
reg = <0xff200000 0x10>;
interrupts = <0 45 4>;
altr,ngpio = <32>;
altr,interrupt-trigger = <IRQ_TYPE_EDGE_RISING>;
altr,interrupt-type = <IRQ_TYPE_EDGE_RISING>;
#gpio-cells = <2>;
gpio-controller;
#interrupt-cells = <1>;

4
Documentation/devicetree/bindings/gpio/gpio-mcp23s08.txt
View File

@ -10,6 +10,7 @@ Required properties:
- "microchip,mcp23s08" for 8 GPIO SPI version
- "microchip,mcp23s17" for 16 GPIO SPI version
- "microchip,mcp23s18" for 16 GPIO SPI version
- "microchip,mcp23008" for 8 GPIO I2C version or
- "microchip,mcp23017" for 16 GPIO I2C version of the chip
NOTE: Do not use the old mcp prefix any more. It is deprecated and will be
@ -43,9 +44,6 @@ Optional properties:
- first cell is the pin number
- second cell is used to specify flags.
- interrupt-controller: Marks the device node as a interrupt controller.
NOTE: The interrupt functionality is only supported for i2c versions of the
chips. The spi chips can also do the interrupts, but this is not supported by
the linux driver yet.
Optional device specific properties:
- microchip,irq-mirror: Sets the mirror flag in the IOCON register. Devices

34
Documentation/devicetree/bindings/gpio/gpio-pisosr.txt Normal file
View File

@ -0,0 +1,34 @@
Generic Parallel-in/Serial-out Shift Register GPIO Driver
This binding describes generic parallel-in/serial-out shift register
devices that can be used for GPI (General Purpose Input). This includes
SN74165 serial-out shift registers and the SN65HVS88x series of
industrial serializers.
Required properties:
- compatible : Should be "pisosr-gpio".
- gpio-controller : Marks the device node as a GPIO controller.
- #gpio-cells : Should be two. For consumer use see gpio.txt.
Optional properties:
- ngpios : Number of used GPIO lines (0..n-1), default is 8.
- load-gpios : GPIO pin specifier attached to load enable, this
pin is pulsed before reading from the device to
load input pin values into the the device.
For other required and optional properties of SPI slave
nodes please refer to ../spi/spi-bus.txt.
Example:
gpio@0 {
compatible = "ti,sn65hvs882", "pisosr-gpio";
gpio-controller;
#gpio-cells = <2>;
load-gpios = <&gpio2 23 GPIO_ACTIVE_LOW>;
reg = <0>;
spi-max-frequency = <1000000>;
spi-cpol;
};

20
Documentation/devicetree/bindings/gpio/gpio-ts4800.txt Normal file
View File

@ -0,0 +1,20 @@
* TS-4800 FPGA's GPIO controller bindings
Required properties:
- compatible: Must be "technologic,ts4800-gpio".
- #gpio-cells: Should be two. The first cell is the pin number.
- reg: Physical base address of the controller and length
of memory mapped region.
Optional property:
- ngpios: See "gpio.txt"
Example:
gpio1: gpio {
compatible = "technologic,ts4800-gpio";
reg = <0x10020 0x6>;
ngpios = <8>;
gpio-controller;
#gpio-cells = <2>;
};

47
Documentation/devicetree/bindings/gpio/gpio-xgene-sb.txt
View File

@ -1,10 +1,20 @@
APM X-Gene Standby GPIO controller bindings
This is a gpio controller in the standby domain.
There are 20 GPIO pins from 0..21. There is no GPIO_DS14 or GPIO_DS15,
only GPIO_DS8..GPIO_DS13 support interrupts. The IRQ mapping
is currently 1-to-1 on interrupts 0x28 thru 0x2d.
This is a gpio controller in the standby domain. It also supports interrupt in
some particular pins which are sourced to its parent interrupt controller
as diagram below:
+-----------------+
| X-Gene standby |
| GPIO controller +------ GPIO_0
+------------+ | | ...
| Parent IRQ | EXT_INT_0 | +------ GPIO_8/EXT_INT_0
| controller | (SPI40) | | ...
| (GICv2) +--------------+ +------ GPIO_[N+8]/EXT_INT_N
| | ... | |
| | EXT_INT_N | +------ GPIO_[N+9]
| | (SPI[40 + N])| | ...
| +--------------+ +------ GPIO_MAX
+------------+ +-----------------+
Required properties:
- compatible: "apm,xgene-gpio-sb" for the X-Gene Standby GPIO controller
@ -15,10 +25,18 @@ Required properties:
0 = active high
1 = active low
- gpio-controller: Marks the device node as a GPIO controller.
- interrupts: Shall contain exactly 6 interrupts.
- interrupts: The EXT_INT_0 parent interrupt resource must be listed first.
- interrupt-parent: Phandle of the parent interrupt controller.
- interrupt-cells: Should be two.
- first cell is 0-N coresponding for EXT_INT_0 to EXT_INT_N.
- second cell is used to specify flags.
- interrupt-controller: Marks the device node as an interrupt controller.
- apm,nr-gpios: Optional, specify number of gpios pin.
- apm,nr-irqs: Optional, specify number of interrupt pins.
- apm,irq-start: Optional, specify lowest gpio pin support interrupt.
Example:
sbgpio: sbgpio@17001000 {
sbgpio: gpio@17001000{
compatible = "apm,xgene-gpio-sb";
reg = <0x0 0x17001000 0x0 0x400>;
#gpio-cells = <2>;
@ -29,4 +47,19 @@ Example:
<0x0 0x2b 0x1>,
<0x0 0x2c 0x1>,
<0x0 0x2d 0x1>;
interrupt-parent = <&gic>;
#interrupt-cells = <2>;
interrupt-controller;
apm,nr-gpios = <22>;
apm,nr-irqs = <6>;
apm,irq-start = <8>;
};
testuser {
compatible = "example,testuser";
/* Use the GPIO_13/EXT_INT_5 line as an active high triggered
* level interrupt
*/
interrupts = <5 4>;
interrupt-parent = <&sbgpio>;
};

49
Documentation/devicetree/bindings/gpio/microchip,pic32-gpio.txt Normal file
View File

@ -0,0 +1,49 @@
* Microchip PIC32 GPIO devices (PIO).
Required properties:
- compatible: "microchip,pic32mzda-gpio"
- reg: Base address and length for the device.
- interrupts: The port interrupt shared by all pins.
- gpio-controller: Marks the port as GPIO controller.
- #gpio-cells: Two. The first cell is the pin number and
the second cell is used to specify the gpio polarity as defined in
defined in <dt-bindings/gpio/gpio.h>:
0 = GPIO_ACTIVE_HIGH
1 = GPIO_ACTIVE_LOW
2 = GPIO_OPEN_DRAIN
- interrupt-controller: Marks the device node as an interrupt controller.
- #interrupt-cells: Two. The first cell is the GPIO number and second cell
is used to specify the trigger type as defined in
<dt-bindings/interrupt-controller/irq.h>:
IRQ_TYPE_EDGE_RISING
IRQ_TYPE_EDGE_FALLING
IRQ_TYPE_EDGE_BOTH
- clocks: Clock specifier (see clock bindings for details).
- microchip,gpio-bank: Specifies which bank a controller owns.
- gpio-ranges: Interaction with the PINCTRL subsystem.
Example:
/* PORTA */
gpio0: gpio0@1f860000 {
compatible = "microchip,pic32mzda-gpio";
reg = <0x1f860000 0x100>;
interrupts = <118 IRQ_TYPE_LEVEL_HIGH>;
#gpio-cells = <2>;
gpio-controller;
interrupt-controller;
#interrupt-cells = <2>;
clocks = <&PBCLK4>;
microchip,gpio-bank = <0>;
gpio-ranges = <&pic32_pinctrl 0 0 16>;
};
keys {
...
button@sw1 {
label = "ESC";
linux,code = <1>;
gpios = <&gpio0 12 0>;
};
};

12
Documentation/devicetree/bindings/hsi/nokia-modem.txt
View File

@ -7,6 +7,8 @@ properties are needed by the Nokia modem HSI client:
Required properties:
- compatible: Should be one of
"nokia,n900-modem"
"nokia,n950-modem"
"nokia,n9-modem"
- hsi-channel-names: Should contain the following strings
"mcsaab-control"
"speech-control"
@ -15,11 +17,11 @@ Required properties:
- gpios: Should provide a GPIO handler for each GPIO listed in
gpio-names
- gpio-names: Should contain the following strings
"cmt_apeslpx"
"cmt_rst_rq"
"cmt_en"
"cmt_rst"
"cmt_bsi"
"cmt_apeslpx" (for n900, n950, n9)
"cmt_rst_rq" (for n900, n950, n9)
"cmt_en" (for n900, n950, n9)
"cmt_rst" (for n900)
"cmt_bsi" (for n900)
- interrupts: Should be IRQ handle for modem's reset indication
Example:

20
Documentation/devicetree/bindings/hwmon/nsa320-mcu.txt Normal file
View File

@ -0,0 +1,20 @@
Bindings for the fan / temperature monitor microcontroller used on
the Zyxel NSA 320 and several subsequent models.
Required properties:
- compatible : "zyxel,nsa320-mcu"
- data-gpios : The GPIO pin connected to the data line on the MCU
- clk-gpios : The GPIO pin connected to the clock line on the MCU
- act-gpios : The GPIO pin connected to the active line on the MCU
Example:
hwmon {
compatible = "zyxel,nsa320-mcu";
pinctrl-0 = <&pmx_mcu_data &pmx_mcu_clk &pmx_mcu_act>;
pinctrl-names = "default";
data-gpios = <&gpio0 14 GPIO_ACTIVE_HIGH>;
clk-gpios = <&gpio0 16 GPIO_ACTIVE_HIGH>;
act-gpios = <&gpio0 17 GPIO_ACTIVE_LOW>;
};

1
Documentation/devicetree/bindings/hwmon/ntc_thermistor.txt
View File

@ -10,6 +10,7 @@ Requires node properties:
"murata,ncp03wb473"
"murata,ncp15wl333"
"murata,ncp03wf104"
"murata,ncp15xh103"
/* Usage of vendor name "ntc" is deprecated */
<DEPRECATED> "ntc,ncp15wb473"

4
Documentation/devicetree/bindings/iio/accel/mma8452.txt
View File

@ -1,8 +1,10 @@
Freescale MMA8452Q, MMA8453Q, MMA8652FC or MMA8653FC triaxial accelerometer
Freescale MMA8451Q, MMA8452Q, MMA8453Q, MMA8652FC or MMA8653FC
triaxial accelerometer
Required properties:
- compatible: should contain one of
* "fsl,mma8451"
* "fsl,mma8452"
* "fsl,mma8453"
* "fsl,mma8652"

28
Documentation/devicetree/bindings/iio/adc/at91-sama5d2_adc.txt Normal file
View File

@ -0,0 +1,28 @@
* AT91 SAMA5D2 Analog to Digital Converter (ADC)
Required properties:
- compatible: Should be "atmel,sama5d2-adc".
- reg: Should contain ADC registers location and length.
- interrupts: Should contain the IRQ line for the ADC.
- clocks: phandle to device clock.
- clock-names: Must be "adc_clk".
- vref-supply: Supply used as reference for conversions.
- vddana-supply: Supply for the adc device.
- atmel,min-sample-rate-hz: Minimum sampling rate, it depends on SoC.
- atmel,max-sample-rate-hz: Maximum sampling rate, it depends on SoC.
- atmel,startup-time-ms: Startup time expressed in ms, it depends on SoC.
Example:
adc: adc@fc030000 {
compatible = "atmel,sama5d2-adc";
reg = <0xfc030000 0x100>;
interrupts = <40 IRQ_TYPE_LEVEL_HIGH 7>;
clocks = <&adc_clk>;
clock-names = "adc_clk";
atmel,min-sample-rate-hz = <200000>;
atmel,max-sample-rate-hz = <20000000>;
atmel,startup-time-ms = <4>;
vddana-supply = <&vdd_3v3_lp_reg>;
vref-supply = <&vdd_3v3_lp_reg>;
}

58
Documentation/devicetree/bindings/iio/adc/fsl,imx25-gcq.txt Normal file
View File

@ -0,0 +1,58 @@
Freescale i.MX25 ADC GCQ device
This is a generic conversion queue device that can convert any of the
analog inputs using the ADC unit of the i.MX25.
Required properties:
- compatible: Should be "fsl,imx25-gcq".
- reg: Should be the register range of the module.
- interrupts: Should be the interrupt number of the module.
Typically this is <1>.
- interrupt-parent: phandle to the tsadc module of the i.MX25.
- #address-cells: Should be <1> (setting for the subnodes)
- #size-cells: Should be <0> (setting for the subnodes)
Optional properties:
- vref-ext-supply: The regulator supplying the ADC reference voltage.
Required when at least one subnode uses the this reference.
- vref-xp-supply: The regulator supplying the ADC reference voltage on pin XP.
Required when at least one subnode uses this reference.
- vref-yp-supply: The regulator supplying the ADC reference voltage on pin YP.
Required when at least one subnode uses this reference.
Sub-nodes:
Optionally you can define subnodes which define the reference voltage
for the analog inputs.
Required properties for subnodes:
- reg: Should be the number of the analog input.
0: xp
1: yp
2: xn
3: yn
4: wiper
5: inaux0
6: inaux1
7: inaux2
Optional properties for subnodes:
- fsl,adc-refp: specifies the positive reference input as defined in
<dt-bindings/iio/adc/fsl-imx25-gcq.h>
- fsl,adc-refn: specifies the negative reference input as defined in
<dt-bindings/iio/adc/fsl-imx25-gcq.h>
Example:
adc: adc@50030800 {
compatible = "fsl,imx25-gcq";
reg = <0x50030800 0x60>;
interrupt-parent = <&tscadc>;
interrupts = <1>;
#address-cells = <1>;
#size-cells = <0>;
inaux@5 {
reg = <5>;
fsl,adc-refp = <MX25_ADC_REFP_INT>;
fsl,adc-refn = <MX25_ADC_REFN_NGND>;
};
};

1
Documentation/devicetree/bindings/iio/adc/mcp3422.txt
View File

@ -6,6 +6,7 @@ Required properties:
"microchip,mcp3422" or
"microchip,mcp3423" or
"microchip,mcp3424" or
"microchip,mcp3425" or
"microchip,mcp3426" or
"microchip,mcp3427" or
"microchip,mcp3428"

19
Documentation/devicetree/bindings/iio/adc/ti-adc0832.txt Normal file
View File

@ -0,0 +1,19 @@
* Texas Instruments' ADC0831/ADC0832/ADC0832/ADC0838
Required properties:
- compatible: Should be one of
* "ti,adc0831"
* "ti,adc0832"
* "ti,adc0834"
* "ti,adc0838"
- reg: spi chip select number for the device
- vref-supply: The regulator supply for ADC reference voltage
- spi-max-frequency: Max SPI frequency to use (< 400000)
Example:
adc@0 {
compatible = "ti,adc0832";
reg = <0>;
vref-supply = <&vdd_supply>;
spi-max-frequency = <200000>;
};

22
Documentation/devicetree/bindings/iio/chemical/atlas,ph-sm.txt Normal file
View File

@ -0,0 +1,22 @@
* Atlas Scientific pH-SM OEM sensor
http://www.atlas-scientific.com/_files/_datasheets/_oem/pH_oem_datasheet.pdf
Required properties:
- compatible: must be "atlas,ph-sm"
- reg: the I2C address of the sensor
- interrupt-parent: should be the phandle for the interrupt controller
- interrupts: the sole interrupt generated by the device
Refer to interrupt-controller/interrupts.txt for generic interrupt client
node bindings.
Example:
atlas@65 {
compatible = "atlas,ph-sm";
reg = <0x65>;
interrupt-parent = <&gpio1>;
interrupts = <16 2>;
};

20
Documentation/devicetree/bindings/iio/dac/vf610-dac.txt Normal file
View File

@ -0,0 +1,20 @@
Freescale vf610 Digital to Analog Converter bindings
The devicetree bindings are for the new DAC driver written for
vf610 SoCs from Freescale.
Required properties:
- compatible: Should contain "fsl,vf610-dac"
- reg: Offset and length of the register set for the device
- interrupts: Should contain the interrupt for the device
- clocks: The clock is needed by the DAC controller
- clock-names: Must contain "dac" matching entry in the clocks property.
Example:
dac0: dac@400cc000 {
compatible = "fsl,vf610-dac";
reg = <0x400cc000 0x1000>;
interrupts = <55 IRQ_TYPE_LEVEL_HIGH>;
clock-names = "dac";
clocks = <&clks VF610_CLK_DAC0>;
};

34
Documentation/devicetree/bindings/iio/health/afe4403.txt Normal file
View File

@ -0,0 +1,34 @@
Texas Instruments AFE4403 Heart rate and Pulse Oximeter
Required properties:
- compatible : Should be "ti,afe4403".
- reg : SPI chip select address of device.
- tx-supply : Regulator supply to transmitting LEDs.
- interrupt-parent : Phandle to he parent interrupt controller.
- interrupts : The interrupt line the device ADC_RDY pin is
connected to. For details refer to,
../../interrupt-controller/interrupts.txt.
Optional properties:
- reset-gpios : GPIO used to reset the device.
For details refer to, ../../gpio/gpio.txt.
For other required and optional properties of SPI slave nodes
please refer to ../../spi/spi-bus.txt.
Example:
&spi0 {
heart_mon@0 {
compatible = "ti,afe4403";
reg = <0>;
spi-max-frequency = <10000000>;
tx-supply = <&vbat>;
interrupt-parent = <&gpio1>;
interrupts = <28 IRQ_TYPE_EDGE_RISING>;
reset-gpios = <&gpio1 16 GPIO_ACTIVE_LOW>;
};
};

30
Documentation/devicetree/bindings/iio/health/afe4404.txt Normal file
View File

@ -0,0 +1,30 @@
Texas Instruments AFE4404 Heart rate and Pulse Oximeter
Required properties:
- compatible : Should be "ti,afe4404".
- reg : I2C address of the device.
- tx-supply : Regulator supply to transmitting LEDs.
- interrupt-parent : Phandle to he parent interrupt controller.
- interrupts : The interrupt line the device ADC_RDY pin is
connected to. For details refer to,
../interrupt-controller/interrupts.txt.
Optional properties:
- reset-gpios : GPIO used to reset the device.
For details refer to, ../gpio/gpio.txt.
Example:
&i2c2 {
heart_mon@58 {
compatible = "ti,afe4404";
reg = <0x58>;
tx-supply = <&vbat>;
interrupt-parent = <&gpio1>;
interrupts = <28 IRQ_TYPE_EDGE_RISING>;
reset-gpios = <&gpio1 16 GPIO_ACTIVE_LOW>;
};
};

8
Documentation/devicetree/bindings/iio/health/max30100.txt
View File

@ -11,11 +11,19 @@ Required properties:
Refer to interrupt-controller/interrupts.txt for generic
interrupt client node bindings.
Optional properties:
- maxim,led-current-microamp: configuration for LED current in microamperes
while the engine is running. First indexed value is the configuration for
the RED LED, and second value is for the IR LED.
Refer to the datasheet for the allowed current values.
Example:
max30100@057 {
compatible = "maxim,max30100";
reg = <57>;
maxim,led-current-microamp = <24000 50000>;
interrupt-parent = <&gpio1>;
interrupts = <16 2>;
};

2
Documentation/devicetree/bindings/iio/iio-bindings.txt
View File

@ -82,7 +82,7 @@ vdd channel is connected to output 0 of the &ref device.
...
iio_hwmon {
iio-hwmon {
compatible = "iio-hwmon";
io-channels = <&adc 0>, <&adc 1>, <&adc 2>,
<&adc 3>, <&adc 4>, <&adc 5>,

26
Documentation/devicetree/bindings/iio/light/opt3001.txt Normal file
View File

@ -0,0 +1,26 @@
* Texas Instruments OPT3001 Ambient Light Sensor
The driver supports interrupt-driven and interrupt-less operation, depending
on whether an interrupt property has been populated into the DT. Note that
the optional generation of IIO events on rising/falling light threshold changes
requires the use of interrupts. Without interrupts, only the simple reading
of the current light value is supported through the IIO API.
http://www.ti.com/product/opt3001
Required properties:
- compatible: should be "ti,opt3001"
- reg: the I2C address of the sensor
Optional properties:
- interrupt-parent: should be the phandle for the interrupt controller
- interrupts: interrupt mapping for GPIO IRQ (configure for falling edge)
Example:
opt3001@44 {
compatible = "ti,opt3001";
reg = <0x44>;
interrupt-parent = <&gpio1>;
interrupts = <28 IRQ_TYPE_EDGE_FALLING>;
};

2
Documentation/devicetree/bindings/input/ads7846.txt
View File

@ -29,6 +29,8 @@ Optional properties:
ti,vref-delay-usecs vref supply delay in usecs, 0 for
external vref (u16).
ti,vref-mv The VREF voltage, in millivolts (u16).
Set to 0 to use internal refernce
(ADS7846).
ti,keep-vref-on set to keep vref on for differential
measurements as well
ti,swap-xy swap x and y axis

56
Documentation/devicetree/bindings/input/rmi4/rmi_2d_sensor.txt Normal file
View File

@ -0,0 +1,56 @@
Synaptics RMI4 2D Sensor Device Binding
The Synaptics RMI4 core is able to support RMI4 devices using different
transports and different functions. This file describes the device tree
bindings for devices which contain 2D sensors using Function 11 or
Function 12. Complete documentation for transports and other functions
can be found in:
Documentation/devicetree/bindings/input/rmi4.
RMI4 Function 11 and Function 12 are for 2D touch position sensing.
Additional documentation for F11 can be found at:
http://www.synaptics.com/sites/default/files/511-000136-01-Rev-E-RMI4-Interfacing-Guide.pdf
Optional Touch Properties:
Description in Documentation/devicetree/bindings/input/touch
- touchscreen-inverted-x
- touchscreen-inverted-y
- touchscreen-swapped-x-y
- touchscreen-x-mm
- touchscreen-y-mm
Optional Properties:
- syna,clip-x-low: Sets a minimum value for X.
- syna,clip-y-low: Sets a minimum value for Y.
- syna,clip-x-high: Sets a maximum value for X.
- syna,clip-y-high: Sets a maximum value for Y.
- syna,offset-x: Add an offset to X.
- syna,offset-y: Add an offset to Y.
- syna,delta-x-threshold: Set the minimum distance on the X axis required
to generate an interrupt in reduced reporting
mode.
- syna,delta-y-threshold: Set the minimum distance on the Y axis required
to generate an interrupt in reduced reporting
mode.
- syna,sensor-type: Set the sensor type. 1 for touchscreen 2 for touchpad.
- syna,disable-report-mask: Mask for disabling posiiton reporting. Used to
disable reporing absolute position data.
- syna,rezero-wait-ms: Time in miliseconds to wait after issuing a rezero
command.
Example of a RMI4 I2C device with F11:
Example:
&i2c1 {
rmi4-i2c-dev@2c {
compatible = "syna,rmi4-i2c";
...
rmi4-f11@11 {
reg = <0x11>;
touchscreen-inverted-y;
syna,sensor-type = <2>;
};
};
};

39
Documentation/devicetree/bindings/input/rmi4/rmi_f01.txt Normal file
View File

@ -0,0 +1,39 @@
Synaptics RMI4 F01 Device Binding
The Synaptics RMI4 core is able to support RMI4 devices using different
transports and different functions. This file describes the device tree
bindings for devices which contain Function 1. Complete documentation
for transports and other functions can be found in:
Documentation/devicetree/bindings/input/rmi4.
Additional documentation for F01 can be found at:
http://www.synaptics.com/sites/default/files/511-000136-01-Rev-E-RMI4-Interfacing-Guide.pdf
Optional Properties:
- syna,nosleep-mode: If set the device will run at full power without sleeping.
nosleep has 3 modes, 0 will not change the default
setting, 1 will disable nosleep (allow sleeping),
and 2 will enable nosleep (disabling sleep).
- syna,wakeup-threshold: Defines the amplitude of the disturbance to the
background capacitance that will cause the
device to wake from dozing.
- syna,doze-holdoff-ms: The delay to wait after the last finger lift and the
first doze cycle.
- syna,doze-interval-ms: The time period that the device sleeps between finger
activity.
Example of a RMI4 I2C device with F01:
Example:
&i2c1 {
rmi4-i2c-dev@2c {
compatible = "syna,rmi4-i2c";
...
rmi4-f01@1 {
reg = <0x1>;
syna,nosleep-mode = <1>;
};
};
};

53
Documentation/devicetree/bindings/input/rmi4/rmi_i2c.txt Normal file
View File

@ -0,0 +1,53 @@
Synaptics RMI4 I2C Device Binding
The Synaptics RMI4 core is able to support RMI4 devices using different
transports and different functions. This file describes the device tree
bindings for devices using the I2C transport driver. Complete documentation
for other transports and functions can be found in
Documentation/devicetree/bindings/input/rmi4.
Required Properties:
- compatible: syna,rmi4-i2c
- reg: I2C address
- #address-cells: Set to 1 to indicate that the function child nodes
consist of only on uint32 value.
- #size-cells: Set to 0 to indicate that the function child nodes do not
have a size property.
Optional Properties:
- interrupts: interrupt which the rmi device is connected to.
- interrupt-parent: The interrupt controller.
See Documentation/devicetree/bindings/interrupt-controller/interrupts.txt
- syna,reset-delay-ms: The number of milliseconds to wait after resetting the
device.
Function Parameters:
Parameters specific to RMI functions are contained in child nodes of the rmi device
node. Documentation for the parameters of each function can be found in:
Documentation/devicetree/bindings/input/rmi4/rmi_f*.txt.
Example:
&i2c1 {
rmi4-i2c-dev@2c {
compatible = "syna,rmi4-i2c";
reg = <0x2c>;
#address-cells = <1>;
#size-cells = <0>;
interrupt-parent = <&gpio>;
interrupts = <4 2>;
rmi4-f01@1 {
reg = <0x1>;
syna,nosleep-mode = <1>;
};
rmi4-f11@11 {
reg = <0x11>;
touchscreen-inverted-y;
syna,sensor-type = <2>;
};
};
};

57
Documentation/devicetree/bindings/input/rmi4/rmi_spi.txt Normal file
View File

@ -0,0 +1,57 @@
Synaptics RMI4 SPI Device Binding
The Synaptics RMI4 core is able to support RMI4 devices using different
transports and different functions. This file describes the device tree
bindings for devices using the SPI transport driver. Complete documentation
for other transports and functions can be found in
Documentation/devicetree/bindings/input/rmi4.
Required Properties:
- compatible: syna,rmi4-spi
- reg: Chip select address for the device
- #address-cells: Set to 1 to indicate that the function child nodes
consist of only on uint32 value.
- #size-cells: Set to 0 to indicate that the function child nodes do not
have a size property.
Optional Properties:
- interrupts: interrupt which the rmi device is connected to.
- interrupt-parent: The interrupt controller.
See Documentation/devicetree/bindings/interrupt-controller/interrupts.txt
- spi-rx-delay-us: microsecond delay after a read transfer.
- spi-tx-delay-us: microsecond delay after a write transfer.
Function Parameters:
Parameters specific to RMI functions are contained in child nodes of the rmi device
node. Documentation for the parameters of each function can be found in:
Documentation/devicetree/bindings/input/rmi4/rmi_f*.txt.
Example:
spi@7000d800 {
rmi4-spi-dev@0 {
compatible = "syna,rmi4-spi";
reg = <0x0>;
#address-cells = <1>;
#size-cells = <0>;
spi-max-frequency = <4000000>;
spi-cpha;
spi-cpol;
interrupt-parent = <&gpio>;
interrupts = <TEGRA_GPIO(K, 2) 0x2>;
spi-rx-delay-us = <30>;
rmi4-f01@1 {
reg = <0x1>;
syna,nosleep-mode = <1>;
};
rmi4-f11@11 {
reg = <0x11>;
touchscreen-inverted-y;
syna,sensor-type = <2>;
};
};
};

2
Documentation/devicetree/bindings/input/rotary-encoder.txt
View File

@ -1,7 +1,7 @@
Rotary encoder DT bindings
Required properties:
- gpios: a spec for two GPIOs to be used
- gpios: a spec for at least two GPIOs to be used, most significant first
Optional properties:
- linux,axis: the input subsystem axis to map to this rotary encoder.

53
Documentation/devicetree/bindings/input/touchscreen/ad7879.txt Normal file
View File

@ -0,0 +1,53 @@
* Analog Devices AD7879(-1)/AD7889(-1) touchscreen interface (SPI/I2C)
Required properties:
- compatible : for SPI slave, use "adi,ad7879"
for I2C slave, use "adi,ad7879-1"
- reg : SPI chipselect/I2C slave address
See spi-bus.txt for more SPI slave properties
- interrupt-parent : the phandle for the interrupt controller
- interrupts : touch controller interrupt
- touchscreen-max-pressure : maximum reported pressure
- adi,resistance-plate-x : total resistance of X-plate (for pressure
calculation)
Optional properties:
- touchscreen-swapped-x-y : X and Y axis are swapped (boolean)
- adi,first-conversion-delay : 0-12: In 128us steps (starting with 128us)
13 : 2.560ms
14 : 3.584ms
15 : 4.096ms
This property has to be a '/bits/ 8' value
- adi,acquisition-time : 0: 2us
1: 4us
2: 8us
3: 16us
This property has to be a '/bits/ 8' value
- adi,median-filter-size : 0: disabled
1: 4 measurements
2: 8 measurements
3: 16 measurements
This property has to be a '/bits/ 8' value
- adi,averaging : 0: 2 middle values (1 if median disabled)
1: 4 middle values
2: 8 middle values
3: 16 values
This property has to be a '/bits/ 8' value
- adi,conversion-interval: : 0 : convert one time only
1-255: 515us + val * 35us (up to 9.440ms)
This property has to be a '/bits/ 8' value
Example:
ad7879@2c {
compatible = "adi,ad7879-1";
reg = <0x2c>;
interrupt-parent = <&gpio1>;
interrupts = <13 IRQ_TYPE_EDGE_FALLING>;
touchscreen-max-pressure = <4096>;
adi,resistance-plate-x = <120>;
adi,first-conversion-delay = /bits/ 8 <3>;
adi,acquisition-time = /bits/ 8 <1>;
adi,median-filter-size = /bits/ 8 <2>;
adi,averaging = /bits/ 8 <1>;
adi,conversion-interval = /bits/ 8 <255>;
};

95
Documentation/devicetree/bindings/input/touchscreen/cyttsp.txt Normal file
View File

@ -0,0 +1,95 @@
* Cypress cyttsp touchscreen controller
Required properties:
- compatible : must be "cypress,cyttsp-i2c" or "cypress,cyttsp-spi"
- reg : Device I2C address or SPI chip select number
- spi-max-frequency : Maximum SPI clocking speed of the device (for cyttsp-spi)
- interrupt-parent : the phandle for the gpio controller
(see interrupt binding[0]).
- interrupts : (gpio) interrupt to which the chip is connected
(see interrupt binding[0]).
- bootloader-key : the 8-byte bootloader key that is required to switch
the chip from bootloader mode (default mode) to
application mode.
This property has to be specified as an array of 8
'/bits/ 8' values.
Optional properties:
- reset-gpios : the reset gpio the chip is connected to
(see GPIO binding[1] for more details).
- touchscreen-size-x : horizontal resolution of touchscreen (in pixels)
- touchscreen-size-y : vertical resolution of touchscreen (in pixels)
- touchscreen-fuzz-x : horizontal noise value of the absolute input device
(in pixels)
- touchscreen-fuzz-y : vertical noise value of the absolute input device
(in pixels)
- active-distance : the distance in pixels beyond which a touch must move
before movement is detected and reported by the device.
Valid values: 0-15.
- active-interval-ms : the minimum period in ms between consecutive
scanning/processing cycles when the chip is in active mode.
Valid values: 0-255.
- lowpower-interval-ms : the minimum period in ms between consecutive
scanning/processing cycles when the chip is in low-power mode.
Valid values: 0-2550
- touch-timeout-ms : minimum time in ms spent in the active power state while no
touches are detected before entering low-power mode.
Valid values: 0-2550
- use-handshake : enable register-based handshake (boolean). This should
only be used if the chip is configured to use 'blocking
communication with timeout' (in this case the device
generates an interrupt at the end of every
scanning/processing cycle).
[0]: Documentation/devicetree/bindings/interrupt-controller/interrupts.txt
[1]: Documentation/devicetree/bindings/gpio/gpio.txt
Example:
&i2c1 {
/* ... */
cyttsp@a {
compatible = "cypress,cyttsp-i2c";
reg = <0xa>;
interrupt-parent = <&gpio0>;
interrupts = <28 0>;
reset-gpios = <&gpio3 4 GPIO_ACTIVE_LOW>;
touchscreen-size-x = <800>;
touchscreen-size-y = <480>;
touchscreen-fuzz-x = <4>;
touchscreen-fuzz-y = <7>;
bootloader-key = /bits/ 8 <0x01 0x02 0x03 0x04 0x05 0x06 0x07 0x08>;
active-distance = <8>;
active-interval-ms = <0>;
lowpower-interval-ms = <200>;
touch-timeout-ms = <100>;
};
/* ... */
};
&mcspi1 {
/* ... */
cyttsp@0 {
compatible = "cypress,cyttsp-spi";
spi-max-frequency = <6000000>;
reg = <0>;
interrupt-parent = <&gpio0>;
interrupts = <28 0>;
reset-gpios = <&gpio3 4 GPIO_ACTIVE_LOW>;
touchscreen-size-x = <800>;
touchscreen-size-y = <480>;
touchscreen-fuzz-x = <4>;
touchscreen-fuzz-y = <7>;
bootloader-key = /bits/ 8 <0x01 0x02 0x03 0x04 0x05 0x06 0x07 0x08>;
active-distance = <8>;
active-interval-ms = <0>;
lowpower-interval-ms = <200>;
touch-timeout-ms = <100>;
};
/* ... */
};

35
Documentation/devicetree/bindings/input/touchscreen/fsl-mx25-tcq.txt Normal file
View File

@ -0,0 +1,35 @@
Freescale mx25 TS conversion queue module
mx25 touchscreen conversion queue module which controls the ADC unit of the
mx25 for attached touchscreens.
Required properties:
- compatible: Should be "fsl,imx25-tcq".
- reg: Memory range of the device.
- interrupts: Should be the interrupt number associated with this module within
the tscadc unit (<0>).
- interrupt-parent: Should be a phandle to the tscadc unit.
- fsl,wires: Should be '<4>' or '<5>'
Optional properties:
- fsl,pen-debounce-ns: Pen debounce time in nanoseconds.
- fsl,pen-threshold: Pen-down threshold for the touchscreen. This is a value
between 1 and 4096. It is the ratio between the internal reference voltage
and the measured voltage after the plate was precharged. Resistence between
plates and therefore the voltage decreases with pressure so that a smaller
value is equivalent to a higher pressure.
- fsl,settling-time-ns: Settling time in nanoseconds. The settling time is before
the actual touch detection to wait for an even charge distribution in the
plate.
This device includes two conversion queues which can be added as subnodes.
The first queue is for the touchscreen, the second for general purpose ADC.
Example:
tsc: tcq@50030400 {
compatible = "fsl,imx25-tcq";
reg = <0x50030400 0x60>;
interrupt-parent = <&tscadc>;
interrupts = <0>;
fsl,wires = <4>;
};

2
Documentation/devicetree/bindings/input/touchscreen/touchscreen.txt
View File

@ -18,6 +18,8 @@ Optional properties for Touchscreens:
- touchscreen-inverted-y : Y axis is inverted (boolean)
- touchscreen-swapped-x-y : X and Y axis are swapped (boolean)
Swapping is done after inverting the axis
- touchscreen-x-mm : horizontal length in mm of the touchscreen
- touchscreen-y-mm : vertical length in mm of the touchscreen
Deprecated properties for Touchscreens:
- x-size : deprecated name for touchscreen-size-x

26
Documentation/devicetree/bindings/interrupt-controller/al,alpine-msix.txt Normal file
View File

@ -0,0 +1,26 @@
Alpine MSIX controller
See arm,gic-v3.txt for SPI and MSI definitions.
Required properties:
- compatible: should be "al,alpine-msix"
- reg: physical base address and size of the registers
- interrupt-parent: specifies the parent interrupt controller.
- interrupt-controller: identifies the node as an interrupt controller
- msi-controller: identifies the node as an PCI Message Signaled Interrupt
controller
- al,msi-base-spi: SPI base of the MSI frame
- al,msi-num-spis: number of SPIs assigned to the MSI frame, relative to SPI0
Example:
msix: msix {
compatible = "al,alpine-msix";
reg = <0x0 0xfbe00000 0x0 0x100000>;
interrupt-parent = <&gic>;
interrupt-controller;
msi-controller;
al,msi-base-spi = <160>;
al,msi-num-spis = <160>;
};

1
Documentation/devicetree/bindings/interrupt-controller/arm,gic.txt
View File

@ -16,6 +16,7 @@ Main node required properties:
"arm,cortex-a15-gic"
"arm,cortex-a7-gic"
"arm,cortex-a9-gic"
"arm,eb11mp-gic"
"arm,gic-400"
"arm,pl390"
"arm,tc11mp-gic"

44
Documentation/devicetree/bindings/interrupt-controller/marvell,odmi-controller.txt Normal file
View File

@ -0,0 +1,44 @@
* Marvell ODMI for MSI support
Some Marvell SoCs have an On-Die Message Interrupt (ODMI) controller
which can be used by on-board peripheral for MSI interrupts.
Required properties:
- compatible : The value here should contain:
"marvell,ap806-odmi-controller", "marvell,odmi-controller".
- interrupt,controller : Identifies the node as an interrupt controller.
- msi-controller : Identifies the node as an MSI controller.
- marvell,odmi-frames : Number of ODMI frames available. Each frame
provides a number of events.
- reg : List of register definitions, one for each
ODMI frame.
- marvell,spi-base : List of GIC base SPI interrupts, one for each
ODMI frame. Those SPI interrupts are 0-based,
i.e marvell,spi-base = <128> will use SPI #96.
See Documentation/devicetree/bindings/interrupt-controller/arm,gic.txt
for details about the GIC Device Tree binding.
- interrupt-parent : Reference to the parent interrupt controller.
Example:
odmi: odmi@300000 {
compatible = "marvell,ap806-odm-controller",
"marvell,odmi-controller";
interrupt-controller;
msi-controller;
marvell,odmi-frames = <4>;
reg = <0x300000 0x4000>,
<0x304000 0x4000>,
<0x308000 0x4000>,
<0x30C000 0x4000>;
marvell,spi-base = <128>, <136>, <144>, <152>;
};

7
Documentation/devicetree/bindings/interrupt-controller/mips-gic.txt
View File

@ -23,6 +23,12 @@ Optional properties:
- mti,reserved-cpu-vectors : Specifies the list of CPU interrupt vectors
to which the GIC may not route interrupts. Valid values are 2 - 7.
This property is ignored if the CPU is started in EIC mode.
- mti,reserved-ipi-vectors : Specifies the range of GIC interrupts that are
reserved for IPIs.
It accepts 2 values, the 1st is the starting interrupt and the 2nd is the size
of the reserved range.
If not specified, the driver will allocate the last 2 * number of VPEs in the
system.
Required properties for timer sub-node:
- compatible : Should be "mti,gic-timer".
@ -44,6 +50,7 @@ Example:
#interrupt-cells = <3>;
mti,reserved-cpu-vectors = <7>;
mti,reserved-ipi-vectors = <40 8>;
timer {
compatible = "mti,gic-timer";

49
Documentation/devicetree/bindings/interrupt-controller/sigma,smp8642-intc.txt Normal file
View File

@ -0,0 +1,49 @@
Sigma Designs SMP86xx/SMP87xx secondary interrupt controller
Required properties:
- compatible: should be "sigma,smp8642-intc"
- reg: physical address of MMIO region
- ranges: address space mapping of child nodes
- interrupt-parent: phandle of parent interrupt controller
- interrupt-controller: boolean
- #address-cells: should be <1>
- #size-cells: should be <1>
One child node per control block with properties:
- reg: address of registers for this control block
- interrupt-controller: boolean
- #interrupt-cells: should be <2>, interrupt index and flags per interrupts.txt
- interrupts: interrupt spec of primary interrupt controller
Example:
interrupt-controller@6e000 {
compatible = "sigma,smp8642-intc";
reg = <0x6e000 0x400>;
ranges = <0x0 0x6e000 0x400>;
interrupt-parent = <&gic>;
interrupt-controller;
#address-cells = <1>;
#size-cells = <1>;
irq0: interrupt-controller@0 {
reg = <0x000 0x100>;
interrupt-controller;
#interrupt-cells = <2>;
interrupts = <GIC_SPI 2 IRQ_TYPE_LEVEL_HIGH>;
};
irq1: interrupt-controller@100 {
reg = <0x100 0x100>;
interrupt-controller;
#interrupt-cells = <2>;
interrupts = <GIC_SPI 3 IRQ_TYPE_LEVEL_HIGH>;
};
irq2: interrupt-controller@300 {
reg = <0x300 0x100>;
interrupt-controller;
#interrupt-cells = <2>;
interrupts = <GIC_SPI 4 IRQ_TYPE_LEVEL_HIGH>;
};
};

52
Documentation/devicetree/bindings/leds/leds-is31fl32xx.txt Normal file
View File

@ -0,0 +1,52 @@
Binding for ISSI IS31FL32xx and Si-En SN32xx LED Drivers
The IS31FL32xx/SN32xx family of LED drivers are I2C devices with multiple
constant-current channels, each with independent 256-level PWM control.
Each LED is represented as a sub-node of the device.
Required properties:
- compatible: one of
issi,is31fl3236
issi,is31fl3235
issi,is31fl3218
issi,is31fl3216
si-en,sn3218
si-en,sn3216
- reg: I2C slave address
- address-cells : must be 1
- size-cells : must be 0
LED sub-node properties:
- reg : LED channel number (1..N)
- label : (optional)
see Documentation/devicetree/bindings/leds/common.txt
- linux,default-trigger : (optional)
see Documentation/devicetree/bindings/leds/common.txt
Example:
is31fl3236: led-controller@3c {
compatible = "issi,is31fl3236";
reg = <0x3c>;
#address-cells = <1>;
#size-cells = <0>;
led@1 {
reg = <1>;
label = "EB:blue:usr0";
};
led@2 {
reg = <2>;
label = "EB:blue:usr1";
};
...
led@36 {
reg = <36>;
label = "EB:blue:usr35";
};
};
For more product information please see the links below:
http://www.issi.com/US/product-analog-fxled-driver.shtml
http://www.si-en.com/product.asp?parentid=890

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