hollalinux
/
linux-sg2042
mirror of https://github.com/sophgo/linux-riscv.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

Merge branches 'for-4.8/alps', 'for-4.8/apple', 'for-4.8/i2c-hid', 'for-4.8/uhid-offload-hid-device-add' and 'for-4.8/upstream' into for-linus

This commit is contained in:
Jiri Kosina 2016-07-28 10:48:15 +02:00
parent 819d64e51d b5d9427549 d9f448e3d7 67f8ecc550 ddfe8483e9
commit e82a82c19f
7080 changed files with 356709 additions and 133874 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

6
.mailmap
View File

@ -21,6 +21,7 @@ Andrey Ryabinin <ryabinin.a.a@gmail.com> <a.ryabinin@samsung.com>
Andrew Morton <akpm@linux-foundation.org>
Andrew Vasquez <andrew.vasquez@qlogic.com>
Andy Adamson <andros@citi.umich.edu>
Antoine Tenart <antoine.tenart@free-electrons.com>
Antonio Ospite <ao2@ao2.it> <ao2@amarulasolutions.com>
Archit Taneja <archit@ti.com>
Arnaud Patard <arnaud.patard@rtp-net.org>
@ -30,6 +31,9 @@ Axel Lin <axel.lin@gmail.com>
Ben Gardner <bgardner@wabtec.com>
Ben M Cahill <ben.m.cahill@intel.com>
Björn Steinbrink <B.Steinbrink@gmx.de>
Boris Brezillon <boris.brezillon@free-electrons.com>
Boris Brezillon <boris.brezillon@free-electrons.com> <b.brezillon.dev@gmail.com>
Boris Brezillon <boris.brezillon@free-electrons.com> <b.brezillon@overkiz.com>
Brian Avery <b.avery@hp.com>
Brian King <brking@us.ibm.com>
Christoph Hellwig <hch@lst.de>
@ -89,6 +93,7 @@ Leonid I Ananiev <leonid.i.ananiev@intel.com>
Linas Vepstas <linas@austin.ibm.com>
Mark Brown <broonie@sirena.org.uk>
Matthieu CASTET <castet.matthieu@free.fr>
Mauro Carvalho Chehab <mchehab@kernel.org> <maurochehab@gmail.com> <mchehab@infradead.org> <mchehab@redhat.com> <m.chehab@samsung.com> <mchehab@osg.samsung.com> <mchehab@s-opensource.com>
Mayuresh Janorkar <mayur@ti.com>
Michael Buesch <m@bues.ch>
Michel Dänzer <michel@tungstengraphics.com>
@ -122,6 +127,7 @@ Santosh Shilimkar <santosh.shilimkar@oracle.org>
Sascha Hauer <s.hauer@pengutronix.de>
S.Çağlar Onur <caglar@pardus.org.tr>
Shiraz Hashim <shiraz.linux.kernel@gmail.com> <shiraz.hashim@st.com>
Shuah Khan <shuah@kernel.org> <shuahkhan@gmail.com> <shuah.khan@hp.com> <shuahkh@osg.samsung.com> <shuah.kh@samsung.com>
Simon Kelley <simon@thekelleys.org.uk>
Stéphane Witzmann <stephane.witzmann@ubpmes.univ-bpclermont.fr>
Stephen Hemminger <shemminger@osdl.org>

2
CREDITS
View File

@ -649,6 +649,7 @@ D: Configure, Menuconfig, xconfig
N: Mauro Carvalho Chehab
E: m.chehab@samsung.org
E: mchehab@osg.samsung.com
E: mchehab@infradead.org
D: Media subsystem (V4L/DVB) drivers and core
D: EDAC drivers and EDAC 3.0 core rework
@ -768,6 +769,7 @@ D: Z85230 driver
D: Former security contact point (please use vendor-sec@lst.de)
D: ex 2.2 maintainer
D: 2.1.x modular sound
D: Assigned major/minor numbers maintainer at lanana.org
S: c/o Red Hat UK Ltd
S: Alexandra House
S: Alexandra Terrace

11
Documentation/ABI/obsolete/sysfs-driver-hid-roccat-savu
View File

@ -3,9 +3,10 @@ Date: Mai 2012
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
Description: The mouse can store 5 profiles which can be switched by the
press of a button. A profile is split into general settings and
button settings. buttons holds informations about button layout.
When written, this file lets one write the respective profile
buttons to the mouse. The data has to be 47 bytes long.
button settings. The buttons variable holds information about
button layout. When written, this file lets one write the
respective profile buttons to the mouse. The data has to be
47 bytes long.
The mouse will reject invalid data.
Which profile to write is determined by the profile number
contained in the data.
@ -26,8 +27,8 @@ Date: Mai 2012
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
Description: The mouse can store 5 profiles which can be switched by the
press of a button. A profile is split into general settings and
button settings. profile holds informations like resolution, sensitivity
and light effects.
button settings. A profile holds information like resolution,
sensitivity and light effects.
When written, this file lets one write the respective profile
settings back to the mouse. The data has to be 43 bytes long.
The mouse will reject invalid data.

9
Documentation/ABI/stable/sysfs-class-ubi
View File

@ -107,6 +107,15 @@ Contact: Artem Bityutskiy <dedekind@infradead.org>
Description:
Number of physical eraseblocks reserved for bad block handling.
What: /sys/class/ubi/ubiX/ro_mode
Date: April 2016
KernelVersion: 4.7
Contact: linux-mtd@lists.infradead.org
Description:
Contains ASCII "1\n" if the read-only flag is set on this
device, and "0\n" if it is cleared. UBI devices mark themselves
as read-only when they detect an unrecoverable error.
What: /sys/class/ubi/ubiX/total_eraseblocks
Date: July 2006
KernelVersion: 2.6.22

58
Documentation/ABI/testing/configfs-usb-gadget-uvc
View File

@ -1,6 +1,6 @@
What: /config/usb-gadget/gadget/functions/uvc.name
Date: Dec 2014
KernelVersion: 3.20
KernelVersion: 4.0
Description: UVC function directory
streaming_maxburst - 0..15 (ss only)
@ -9,37 +9,37 @@ Description: UVC function directory
What: /config/usb-gadget/gadget/functions/uvc.name/control
Date: Dec 2014
KernelVersion: 3.20
KernelVersion: 4.0
Description: Control descriptors
What: /config/usb-gadget/gadget/functions/uvc.name/control/class
Date: Dec 2014
KernelVersion: 3.20
KernelVersion: 4.0
Description: Class descriptors
What: /config/usb-gadget/gadget/functions/uvc.name/control/class/ss
Date: Dec 2014
KernelVersion: 3.20
KernelVersion: 4.0
Description: Super speed control class descriptors
What: /config/usb-gadget/gadget/functions/uvc.name/control/class/fs
Date: Dec 2014
KernelVersion: 3.20
KernelVersion: 4.0
Description: Full speed control class descriptors
What: /config/usb-gadget/gadget/functions/uvc.name/control/terminal
Date: Dec 2014
KernelVersion: 3.20
KernelVersion: 4.0
Description: Terminal descriptors
What: /config/usb-gadget/gadget/functions/uvc.name/control/terminal/output
Date: Dec 2014
KernelVersion: 3.20
KernelVersion: 4.0
Description: Output terminal descriptors
What: /config/usb-gadget/gadget/functions/uvc.name/control/terminal/output/default
Date: Dec 2014
KernelVersion: 3.20
KernelVersion: 4.0
Description: Default output terminal descriptors
All attributes read only:
@ -53,12 +53,12 @@ Description: Default output terminal descriptors
What: /config/usb-gadget/gadget/functions/uvc.name/control/terminal/camera
Date: Dec 2014
KernelVersion: 3.20
KernelVersion: 4.0
Description: Camera terminal descriptors
What: /config/usb-gadget/gadget/functions/uvc.name/control/terminal/camera/default
Date: Dec 2014
KernelVersion: 3.20
KernelVersion: 4.0
Description: Default camera terminal descriptors
All attributes read only:
@ -75,12 +75,12 @@ Description: Default camera terminal descriptors
What: /config/usb-gadget/gadget/functions/uvc.name/control/processing
Date: Dec 2014
KernelVersion: 3.20
KernelVersion: 4.0
Description: Processing unit descriptors
What: /config/usb-gadget/gadget/functions/uvc.name/control/processing/default
Date: Dec 2014
KernelVersion: 3.20
KernelVersion: 4.0
Description: Default processing unit descriptors
All attributes read only:
@ -94,49 +94,49 @@ Description: Default processing unit descriptors
What: /config/usb-gadget/gadget/functions/uvc.name/control/header
Date: Dec 2014
KernelVersion: 3.20
KernelVersion: 4.0
Description: Control header descriptors
What: /config/usb-gadget/gadget/functions/uvc.name/control/header/name
Date: Dec 2014
KernelVersion: 3.20
KernelVersion: 4.0
Description: Specific control header descriptors
dwClockFrequency
bcdUVC
What: /config/usb-gadget/gadget/functions/uvc.name/streaming
Date: Dec 2014
KernelVersion: 3.20
KernelVersion: 4.0
Description: Streaming descriptors
What: /config/usb-gadget/gadget/functions/uvc.name/streaming/class
Date: Dec 2014
KernelVersion: 3.20
KernelVersion: 4.0
Description: Streaming class descriptors
What: /config/usb-gadget/gadget/functions/uvc.name/streaming/class/ss
Date: Dec 2014
KernelVersion: 3.20
KernelVersion: 4.0
Description: Super speed streaming class descriptors
What: /config/usb-gadget/gadget/functions/uvc.name/streaming/class/hs
Date: Dec 2014
KernelVersion: 3.20
KernelVersion: 4.0
Description: High speed streaming class descriptors
What: /config/usb-gadget/gadget/functions/uvc.name/streaming/class/fs
Date: Dec 2014
KernelVersion: 3.20
KernelVersion: 4.0
Description: Full speed streaming class descriptors
What: /config/usb-gadget/gadget/functions/uvc.name/streaming/color_matching
Date: Dec 2014
KernelVersion: 3.20
KernelVersion: 4.0
Description: Color matching descriptors
What: /config/usb-gadget/gadget/functions/uvc.name/streaming/color_matching/default
Date: Dec 2014
KernelVersion: 3.20
KernelVersion: 4.0
Description: Default color matching descriptors
All attributes read only:
@ -150,12 +150,12 @@ Description: Default color matching descriptors
What: /config/usb-gadget/gadget/functions/uvc.name/streaming/mjpeg
Date: Dec 2014
KernelVersion: 3.20
KernelVersion: 4.0
Description: MJPEG format descriptors
What: /config/usb-gadget/gadget/functions/uvc.name/streaming/mjpeg/name
Date: Dec 2014
KernelVersion: 3.20
KernelVersion: 4.0
Description: Specific MJPEG format descriptors
All attributes read only,
@ -174,7 +174,7 @@ Description: Specific MJPEG format descriptors
What: /config/usb-gadget/gadget/functions/uvc.name/streaming/mjpeg/name/name
Date: Dec 2014
KernelVersion: 3.20
KernelVersion: 4.0
Description: Specific MJPEG frame descriptors
dwFrameInterval - indicates how frame interval can be
@ -196,12 +196,12 @@ Description: Specific MJPEG frame descriptors
What: /config/usb-gadget/gadget/functions/uvc.name/streaming/uncompressed
Date: Dec 2014
KernelVersion: 3.20
KernelVersion: 4.0
Description: Uncompressed format descriptors
What: /config/usb-gadget/gadget/functions/uvc.name/streaming/uncompressed/name
Date: Dec 2014
KernelVersion: 3.20
KernelVersion: 4.0
Description: Specific uncompressed format descriptors
bmaControls - this format's data for bmaControls in
@ -221,7 +221,7 @@ Description: Specific uncompressed format descriptors
What: /config/usb-gadget/gadget/functions/uvc.name/streaming/uncompressed/name/name
Date: Dec 2014
KernelVersion: 3.20
KernelVersion: 4.0
Description: Specific uncompressed frame descriptors
dwFrameInterval - indicates how frame interval can be
@ -243,12 +243,12 @@ Description: Specific uncompressed frame descriptors
What: /config/usb-gadget/gadget/functions/uvc.name/streaming/header
Date: Dec 2014
KernelVersion: 3.20
KernelVersion: 4.0
Description: Streaming header descriptors
What: /config/usb-gadget/gadget/functions/uvc.name/streaming/header/name
Date: Dec 2014
KernelVersion: 3.20
KernelVersion: 4.0
Description: Specific streaming header descriptors
All attributes read only:

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

@ -166,3 +166,12 @@ Description:
The mm_stat file is read-only and represents device's mm
statistics (orig_data_size, compr_data_size, etc.) in a format
similar to block layer statistics file format.
What: /sys/block/zram<id>/debug_stat
Date: July 2016
Contact: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
Description:
The debug_stat file is read-only and represents various
device's debugging info useful for kernel developers. Its
format is not documented intentionally and may change
anytime without any notice.

69
Documentation/ABI/testing/sysfs-bus-coresight-devices-etb10
View File

@ -6,13 +6,6 @@ Description: (RW) Add/remove a sink from a trace path. There can be multiple
source for a single sink.
ex: echo 1 > /sys/bus/coresight/devices/20010000.etb/enable_sink
What: /sys/bus/coresight/devices/<memory_map>.etb/status
Date: November 2014
KernelVersion: 3.19
Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
Description: (R) List various control and status registers. The specific
layout and content is driver specific.
What: /sys/bus/coresight/devices/<memory_map>.etb/trigger_cntr
Date: November 2014
KernelVersion: 3.19
@ -22,3 +15,65 @@ Description: (RW) Disables write access to the Trace RAM by stopping the
following the trigger event. The number of 32-bit words written
into the Trace RAM following the trigger event is equal to the
value stored in this register+1 (from ARM ETB-TRM).
What: /sys/bus/coresight/devices/<memory_map>.etb/mgmt/rdp
Date: March 2016
KernelVersion: 4.7
Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
Description: (R) Defines the depth, in words, of the trace RAM in powers of
2. The value is read directly from HW register RDP, 0x004.
What: /sys/bus/coresight/devices/<memory_map>.etb/mgmt/sts
Date: March 2016
KernelVersion: 4.7
Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
Description: (R) Shows the value held by the ETB status register. The value
is read directly from HW register STS, 0x00C.
What: /sys/bus/coresight/devices/<memory_map>.etb/mgmt/rrp
Date: March 2016
KernelVersion: 4.7
Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
Description: (R) Shows the value held by the ETB RAM Read Pointer register
that is used to read entries from the Trace RAM over the APB
interface. The value is read directly from HW register RRP,
0x014.
What: /sys/bus/coresight/devices/<memory_map>.etb/mgmt/rwp
Date: March 2016
KernelVersion: 4.7
Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
Description: (R) Shows the value held by the ETB RAM Write Pointer register
that is used to sets the write pointer to write entries from
the CoreSight bus into the Trace RAM. The value is read directly
from HW register RWP, 0x018.
What: /sys/bus/coresight/devices/<memory_map>.etb/mgmt/trg
Date: March 2016
KernelVersion: 4.7
Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
Description: (R) Similar to "trigger_cntr" above except that this value is
read directly from HW register TRG, 0x01C.
What: /sys/bus/coresight/devices/<memory_map>.etb/mgmt/ctl
Date: March 2016
KernelVersion: 4.7
Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
Description: (R) Shows the value held by the ETB Control register. The value
is read directly from HW register CTL, 0x020.
What: /sys/bus/coresight/devices/<memory_map>.etb/mgmt/ffsr
Date: March 2016
KernelVersion: 4.7
Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
Description: (R) Shows the value held by the ETB Formatter and Flush Status
register. The value is read directly from HW register FFSR,
0x300.
What: /sys/bus/coresight/devices/<memory_map>.etb/mgmt/ffcr
Date: March 2016
KernelVersion: 4.7
Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
Description: (R) Shows the value held by the ETB Formatter and Flush Control
register. The value is read directly from HW register FFCR,
0x304.

13
Documentation/ABI/testing/sysfs-bus-coresight-devices-etm4x
View File

@ -359,6 +359,19 @@ Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
Description: (R) Print the content of the Peripheral ID3 Register
(0xFEC). The value is taken directly from the HW.
What: /sys/bus/coresight/devices/<memory_map>.etm/mgmt/trcconfig
Date: February 2016
KernelVersion: 4.07
Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
Description: (R) Print the content of the trace configuration register
(0x010) as currently set by SW.
What: /sys/bus/coresight/devices/<memory_map>.etm/mgmt/trctraceid
Date: February 2016
KernelVersion: 4.07
Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
Description: (R) Print the content of the trace ID register (0x040).
What: /sys/bus/coresight/devices/<memory_map>.etm/trcidr/trcidr0
Date: April 2015
KernelVersion: 4.01

53
Documentation/ABI/testing/sysfs-bus-coresight-devices-stm Normal file
View File

@ -0,0 +1,53 @@
What: /sys/bus/coresight/devices/<memory_map>.stm/enable_source
Date: April 2016
KernelVersion: 4.7
Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
Description: (RW) Enable/disable tracing on this specific trace macrocell.
Enabling the trace macrocell implies it has been configured
properly and a sink has been identified for it. The path
of coresight components linking the source to the sink is
configured and managed automatically by the coresight framework.
What: /sys/bus/coresight/devices/<memory_map>.stm/hwevent_enable
Date: April 2016
KernelVersion: 4.7
Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
Description: (RW) Provides access to the HW event enable register, used in
conjunction with HW event bank select register.
What: /sys/bus/coresight/devices/<memory_map>.stm/hwevent_select
Date: April 2016
KernelVersion: 4.7
Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
Description: (RW) Gives access to the HW event block select register
(STMHEBSR) in order to configure up to 256 channels. Used in
conjunction with "hwevent_enable" register as described above.
What: /sys/bus/coresight/devices/<memory_map>.stm/port_enable
Date: April 2016
KernelVersion: 4.7
Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
Description: (RW) Provides access to the stimulus port enable register
(STMSPER). Used in conjunction with "port_select" described
below.
What: /sys/bus/coresight/devices/<memory_map>.stm/port_select
Date: April 2016
KernelVersion: 4.7
Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
Description: (RW) Used to determine which bank of stimulus port bit in
register STMSPER (see above) apply to.
What: /sys/bus/coresight/devices/<memory_map>.stm/status
Date: April 2016
KernelVersion: 4.7
Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
Description: (R) List various control and status registers. The specific
layout and content is driver specific.
What: /sys/bus/coresight/devices/<memory_map>.stm/traceid
Date: April 2016
KernelVersion: 4.7
Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
Description: (RW) Holds the trace ID that will appear in the trace stream
coming from this trace entity.

77
Documentation/ABI/testing/sysfs-bus-coresight-devices-tmc
View File

@ -6,3 +6,80 @@ Description: (RW) Disables write access to the Trace RAM by stopping the
formatter after a defined number of words have been stored
following the trigger event. Additional interface for this
driver are expected to be added as it matures.
What: /sys/bus/coresight/devices/<memory_map>.tmc/mgmt/rsz
Date: March 2016
KernelVersion: 4.7
Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
Description: (R) Defines the size, in 32-bit words, of the local RAM buffer.
The value is read directly from HW register RSZ, 0x004.
What: /sys/bus/coresight/devices/<memory_map>.tmc/mgmt/sts
Date: March 2016
KernelVersion: 4.7
Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
Description: (R) Shows the value held by the TMC status register. The value
is read directly from HW register STS, 0x00C.
What: /sys/bus/coresight/devices/<memory_map>.tmc/mgmt/rrp
Date: March 2016
KernelVersion: 4.7
Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
Description: (R) Shows the value held by the TMC RAM Read Pointer register
that is used to read entries from the Trace RAM over the APB
interface. The value is read directly from HW register RRP,
0x014.
What: /sys/bus/coresight/devices/<memory_map>.tmc/mgmt/rwp
Date: March 2016
KernelVersion: 4.7
Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
Description: (R) Shows the value held by the TMC RAM Write Pointer register
that is used to sets the write pointer to write entries from
the CoreSight bus into the Trace RAM. The value is read directly
from HW register RWP, 0x018.
What: /sys/bus/coresight/devices/<memory_map>.tmc/mgmt/trg
Date: March 2016
KernelVersion: 4.7
Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
Description: (R) Similar to "trigger_cntr" above except that this value is
read directly from HW register TRG, 0x01C.
What: /sys/bus/coresight/devices/<memory_map>.tmc/mgmt/ctl
Date: March 2016
KernelVersion: 4.7
Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
Description: (R) Shows the value held by the TMC Control register. The value
is read directly from HW register CTL, 0x020.
What: /sys/bus/coresight/devices/<memory_map>.tmc/mgmt/ffsr
Date: March 2016
KernelVersion: 4.7
Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
Description: (R) Shows the value held by the TMC Formatter and Flush Status
register. The value is read directly from HW register FFSR,
0x300.
What: /sys/bus/coresight/devices/<memory_map>.tmc/mgmt/ffcr
Date: March 2016
KernelVersion: 4.7
Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
Description: (R) Shows the value held by the TMC Formatter and Flush Control
register. The value is read directly from HW register FFCR,
0x304.
What: /sys/bus/coresight/devices/<memory_map>.tmc/mgmt/mode
Date: March 2016
KernelVersion: 4.7
Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
Description: (R) Shows the value held by the TMC Mode register, which
indicate the mode the device has been configured to enact. The
The value is read directly from the MODE register, 0x028.
What: /sys/bus/coresight/devices/<memory_map>.tmc/mgmt/devid
Date: March 2016
KernelVersion: 4.7
Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
Description: (R) Indicates the capabilities of the Coresight TMC.
The value is read directly from the DEVID register, 0xFC8,

2
Documentation/ABI/testing/sysfs-bus-event_source-devices-hv_24x7
View File

@ -4,7 +4,7 @@ Contact: Linux on PowerPC Developer List <linuxppc-dev@lists.ozlabs.org>
Description:
Provides access to the binary "24x7 catalog" provided by the
hypervisor on POWER7 and 8 systems. This catalog lists events
avaliable from the powerpc "hv_24x7" pmu. Its format is
available from the powerpc "hv_24x7" pmu. Its format is
documented here:
https://raw.githubusercontent.com/jmesmon/catalog-24x7/master/hv-24x7-catalog.h

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

@ -1233,7 +1233,7 @@ KernelVersion: 3.4
Contact: linux-iio@vger.kernel.org
Description:
Proximity measurement indicating that some
object is near the sensor, usually be observing
object is near the sensor, usually by observing
reflectivity of infrared or ultrasound emitted.
Often these sensors are unit less and as such conversion
to SI units is not possible. Higher proximity measurements
@ -1255,12 +1255,23 @@ Description:
What: /sys/.../iio:deviceX/in_intensityY_raw
What: /sys/.../iio:deviceX/in_intensityY_ir_raw
What: /sys/.../iio:deviceX/in_intensityY_both_raw
What: /sys/.../iio:deviceX/in_intensityY_uv_raw
KernelVersion: 3.4
Contact: linux-iio@vger.kernel.org
Description:
Unit-less light intensity. Modifiers both and ir indicate
that measurements contains visible and infrared light
components or just infrared light, respectively.
components or just infrared light, respectively. Modifier uv indicates
that measurements contain ultraviolet light components.
What: /sys/.../iio:deviceX/in_uvindex_input
KernelVersion: 4.6
Contact: linux-iio@vger.kernel.org
Description:
UV light intensity index measuring the human skin's response to
different wavelength of sunlight weighted according to the
standardised CIE Erythemal Action Spectrum. UV index values range
from 0 (low) to >=11 (extreme).
What: /sys/.../iio:deviceX/in_intensity_red_integration_time
What: /sys/.../iio:deviceX/in_intensity_green_integration_time
@ -1501,3 +1512,56 @@ 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.
What: /sys/bus/iio/devices/iio:deviceX/mount_matrix
What: /sys/bus/iio/devices/iio:deviceX/in_mount_matrix
What: /sys/bus/iio/devices/iio:deviceX/out_mount_matrix
What: /sys/bus/iio/devices/iio:deviceX/in_anglvel_mount_matrix
What: /sys/bus/iio/devices/iio:deviceX/in_accel_mount_matrix
KernelVersion: 4.6
Contact: linux-iio@vger.kernel.org
Description:
Mounting matrix for IIO sensors. This is a rotation matrix which
informs userspace about sensor chip's placement relative to the
main hardware it is mounted on.
Main hardware placement is defined according to the local
reference frame related to the physical quantity the sensor
measures.
Given that the rotation matrix is defined in a board specific
way (platform data and / or device-tree), the main hardware
reference frame definition is left to the implementor's choice
(see below for a magnetometer example).
Applications should apply this rotation matrix to samples so
that when main hardware reference frame is aligned onto local
reference frame, then sensor chip reference frame is also
perfectly aligned with it.
Matrix is a 3x3 unitary matrix and typically looks like
[0, 1, 0; 1, 0, 0; 0, 0, -1]. Identity matrix
[1, 0, 0; 0, 1, 0; 0, 0, 1] means sensor chip and main hardware
are perfectly aligned with each other.
For example, a mounting matrix for a magnetometer sensor informs
userspace about sensor chip's ORIENTATION relative to the main
hardware.
More specifically, main hardware orientation is defined with
respect to the LOCAL EARTH GEOMAGNETIC REFERENCE FRAME where :
* Y is in the ground plane and positive towards magnetic North ;
* X is in the ground plane, perpendicular to the North axis and
positive towards the East ;
* Z is perpendicular to the ground plane and positive upwards.
An implementor might consider that for a hand-held device, a
'natural' orientation would be 'front facing camera at the top'.
The main hardware reference frame could then be described as :
* Y is in the plane of the screen and is positive towards the
top of the screen ;
* X is in the plane of the screen, perpendicular to Y axis, and
positive towards the right hand side of the screen ;
* Z is perpendicular to the screen plane and positive out of the
screen.
Another example for a quadrotor UAV might be :
* Y is in the plane of the propellers and positive towards the
front-view camera;
* X is in the plane of the propellers, perpendicular to Y axis,
and positive towards the starboard side of the UAV ;
* Z is perpendicular to propellers plane and positive upwards.

2
Documentation/ABI/testing/sysfs-bus-iio-proximity-as3935
View File

@ -1,4 +1,4 @@
What /sys/bus/iio/devices/iio:deviceX/in_proximity_raw
What /sys/bus/iio/devices/iio:deviceX/in_proximity_input
Date: March 2014
KernelVersion: 3.15
Contact: Matt Ranostay <mranostay@gmail.com>

29
Documentation/ABI/testing/sysfs-bus-mcb Normal file
View File

@ -0,0 +1,29 @@
What: /sys/bus/mcb/devices/mcb:X
Date: March 2016
KernelVersion: 4.7
Contact: Johannes Thumshirn <jth@kernel.org>
Description: Hardware chip or device hosting the MEN chameleon bus
What: /sys/bus/mcb/devices/mcb:X/revision
Date: March 2016
KernelVersion: 4.7
Contact: Johannes Thumshirn <jth@kernel.org>
Description: The FPGA's revision number
What: /sys/bus/mcb/devices/mcb:X/minor
Date: March 2016
KernelVersion: 4.7
Contact: Johannes Thumshirn <jth@kernel.org>
Description: The FPGA's minor number
What: /sys/bus/mcb/devices/mcb:X/model
Date: March 2016
KernelVersion: 4.7
Contact: Johannes Thumshirn <jth@kernel.org>
Description: The FPGA's model number
What: /sys/bus/mcb/devices/mcb:X/name
Date: March 2016
KernelVersion: 4.7
Contact: Johannes Thumshirn <jth@kernel.org>
Description: The FPGA's name

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

@ -233,3 +233,11 @@ Description: read/write
0 = don't trust, the image may be different (default)
1 = trust that the image will not change.
Users: https://github.com/ibm-capi/libcxl
What: /sys/class/cxl/<card>/psl_timebase_synced
Date: March 2016
Contact: linuxppc-dev@lists.ozlabs.org
Description: read only
Returns 1 if the psl timebase register is synchronized
with the core timebase register, 0 otherwise.
Users: https://github.com/ibm-capi/libcxl

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

@ -12,3 +12,13 @@ KernelVersion: 4.3
Contact: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Description:
Shows the number of channels per master on this STM device.
What: /sys/class/stm/<stm>/hw_override
Date: March 2016
KernelVersion: 4.7
Contact: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Description:
Reads as 0 if master numbers in the STP stream produced by
this stm device will match the master numbers assigned by
the software or 1 if the stm hardware overrides software
assigned masters.

2
Documentation/ABI/testing/sysfs-driver-hid-picolcd
View File

@ -39,5 +39,5 @@ Description: Make it possible to adjust defio refresh rate.
Note: As device can barely do 2 complete refreshes a second
it only makes sense to adjust this value if only one or two
tiles get changed and it's not appropriate to expect the application
to flush it's tiny changes explicitely at higher than default rate.
to flush its tiny changes explicitly at higher than default rate.

2
Documentation/ABI/testing/sysfs-firmware-acpi
View File

@ -169,7 +169,7 @@ Description:
to enable/disable/clear ACPI interrupts in user space, which can be
used to debug some ACPI interrupt storm issues.
Note that only writting to VALID GPE/Fixed Event is allowed,
Note that only writing to VALID GPE/Fixed Event is allowed,
i.e. user can only change the status of runtime GPE and
Fixed Event with event handler installed.

10
Documentation/ABI/testing/sysfs-ibft
View File

@ -21,3 +21,13 @@ Contact: Konrad Rzeszutek <ketuzsezr@darnok.org>
Description: The /sys/firmware/ibft/ethernetX directory will contain
files that expose the iSCSI Boot Firmware Table NIC data.
Usually this contains the IP address, MAC, and gateway of the NIC.
What: /sys/firmware/ibft/acpi_header
Date: March 2016
Contact: David Bond <dbond@suse.com>
Description: The /sys/firmware/ibft/acpi_header directory will contain files
that expose the SIGNATURE, OEM_ID, and OEM_TABLE_ID fields of the
acpi table header of the iBFT structure. This will allow for
identification of the creator of the table which is useful in
determining quirks associated with some adapters when used in
hardware vs software iscsi initiator mode.

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

@ -0,0 +1,9 @@
What: /sys/devices/platform/hidma-*/chid
/sys/devices/platform/QCOM8061:*/chid
Date: Dec 2015
KernelVersion: 4.4
Contact: "Sinan Kaya <okaya@cudeaurora.org>"
Description:
Contains the ID of the channel within the HIDMA instance.
It is used to associate a given HIDMA channel with the
priority and weight calls in the management interface.

35
Documentation/ABI/testing/sysfs-platform-usbip-vudc Normal file
View File

@ -0,0 +1,35 @@
What: /sys/devices/platform/usbip-vudc.%d/dev_desc
Date: April 2016
KernelVersion: 4.6
Contact: Krzysztof Opasiak <k.opasiak@samsung.com>
Description:
This file allows to read device descriptor of
gadget driver which is currently bound to this
controller. It is possible to read this file
only if gadget driver is bound, otherwise error
is returned.
What: /sys/devices/platform/usbip-vudc.%d/usbip_status
Date: April 2016
KernelVersion: 4.6
Contact: Krzysztof Opasiak <k.opasiak@samsung.com>
Description:
Current status of the device.
Allowed values:
1 - Device is available and can be exported
2 - Device is currently exported
3 - Fatal error occurred during communication
with peer
What: /sys/devices/platform/usbip-vudc.%d/usbip_sockfd
Date: April 2016
KernelVersion: 4.6
Contact: Krzysztof Opasiak <k.opasiak@samsung.com>
Description:
This file allows to export usb device to
connection peer. It is done by writing to this
file socket fd (as a string for example "8")
associated with a connection to remote peer who
would like to use this device. It is possible to
close the connection by writing -1 instead of
socked fd.

26
Documentation/DocBook/debugobjects.tmpl
View File

@ -316,8 +316,8 @@
</itemizedlist>
</para>
<para>
The function returns 1 when the fixup was successful,
otherwise 0. The return value is used to update the
The function returns true when the fixup was successful,
otherwise false. The return value is used to update the
statistics.
</para>
<para>
@ -341,8 +341,8 @@
</itemizedlist>
</para>
<para>
The function returns 1 when the fixup was successful,
otherwise 0. The return value is used to update the
The function returns true when the fixup was successful,
otherwise false. The return value is used to update the
statistics.
</para>
<para>
@ -359,7 +359,8 @@
statically initialized object or not. In case it is it calls
debug_object_init() and debug_object_activate() to make the
object known to the tracker and marked active. In this case
the function should return 0 because this is not a real fixup.
the function should return false because this is not a real
fixup.
</para>
</sect1>
@ -376,8 +377,8 @@
</itemizedlist>
</para>
<para>
The function returns 1 when the fixup was successful,
otherwise 0. The return value is used to update the
The function returns true when the fixup was successful,
otherwise false. The return value is used to update the
statistics.
</para>
</sect1>
@ -397,8 +398,8 @@
</itemizedlist>
</para>
<para>
The function returns 1 when the fixup was successful,
otherwise 0. The return value is used to update the
The function returns true when the fixup was successful,
otherwise false. The return value is used to update the
statistics.
</para>
</sect1>
@ -414,8 +415,8 @@
debug bucket.
</para>
<para>
The function returns 1 when the fixup was successful,
otherwise 0. The return value is used to update the
The function returns true when the fixup was successful,
otherwise false. The return value is used to update the
statistics.
</para>
<para>
@ -427,7 +428,8 @@
case. The fixup function should check if this is a legitimate
case of a statically initialized object or not. In this case only
debug_object_init() should be called to make the object known to
the tracker. Then the function should return 0 because this is not
the tracker. Then the function should return false because this
is not
a real fixup.
</para>
</sect1>

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

@ -128,14 +128,44 @@ X!Edrivers/base/interface.c
!Edrivers/base/platform.c
!Edrivers/base/bus.c
</sect1>
<sect1><title>Device Drivers DMA Management</title>
<sect1>
<title>Buffer Sharing and Synchronization</title>
<para>
The dma-buf subsystem provides the framework for sharing buffers
for hardware (DMA) access across multiple device drivers and
subsystems, and for synchronizing asynchronous hardware access.
</para>
<para>
This is used, for example, by drm "prime" multi-GPU support, but
is of course not limited to GPU use cases.
</para>
<para>
The three main components of this are: (1) dma-buf, representing
a sg_table and exposed to userspace as a file descriptor to allow
passing between devices, (2) fence, which provides a mechanism
to signal when one device as finished access, and (3) reservation,
which manages the shared or exclusive fence(s) associated with
the buffer.
</para>
<sect2><title>dma-buf</title>
!Edrivers/dma-buf/dma-buf.c
!Edrivers/dma-buf/fence.c
!Edrivers/dma-buf/seqno-fence.c
!Iinclude/linux/fence.h
!Iinclude/linux/seqno-fence.h
!Iinclude/linux/dma-buf.h
</sect2>
<sect2><title>reservation</title>
!Pdrivers/dma-buf/reservation.c Reservation Object Overview
!Edrivers/dma-buf/reservation.c
!Iinclude/linux/reservation.h
</sect2>
<sect2><title>fence</title>
!Edrivers/dma-buf/fence.c
!Iinclude/linux/fence.h
!Edrivers/dma-buf/seqno-fence.c
!Iinclude/linux/seqno-fence.h
!Edrivers/dma-buf/sync_file.c
!Iinclude/linux/sync_file.h
</sect2>
</sect1>
<sect1><title>Device Drivers DMA Management</title>
!Edrivers/base/dma-coherent.c
!Edrivers/base/dma-mapping.c
</sect1>
@ -233,6 +263,7 @@ X!Isound/sound_firmware.c
!Iinclude/media/v4l2-mediabus.h
!Iinclude/media/v4l2-mem2mem.h
!Iinclude/media/v4l2-of.h
!Iinclude/media/v4l2-rect.h
!Iinclude/media/v4l2-subdev.h
!Iinclude/media/videobuf2-core.h
!Iinclude/media/videobuf2-v4l2.h

53
Documentation/DocBook/gpu.tmpl
View File

@ -1615,12 +1615,23 @@ void intel_crt_init(struct drm_device *dev)
!Pdrivers/gpu/drm/drm_fb_helper.c fbdev helpers
!Edrivers/gpu/drm/drm_fb_helper.c
!Iinclude/drm/drm_fb_helper.h
</sect2>
<sect2>
<title>Framebuffer CMA Helper Functions Reference</title>
!Pdrivers/gpu/drm/drm_fb_cma_helper.c framebuffer cma helper functions
!Edrivers/gpu/drm/drm_fb_cma_helper.c
</sect2>
<sect2>
<title>Display Port Helper Functions Reference</title>
!Pdrivers/gpu/drm/drm_dp_helper.c dp helpers
!Iinclude/drm/drm_dp_helper.h
!Edrivers/gpu/drm/drm_dp_helper.c
</sect2>
<sect2>
<title>Display Port Dual Mode Adaptor Helper Functions Reference</title>
!Pdrivers/gpu/drm/drm_dp_dual_mode_helper.c dp dual mode helpers
!Iinclude/drm/drm_dp_dual_mode_helper.h
!Edrivers/gpu/drm/drm_dp_dual_mode_helper.c
</sect2>
<sect2>
<title>Display Port MST Helper Functions Reference</title>
@ -1671,17 +1682,23 @@ void intel_crt_init(struct drm_device *dev)
!Pdrivers/gpu/drm/drm_crtc.c Tile group
</sect2>
<sect2>
<title>Bridges</title>
<title>Bridges</title>
<sect3>
<title>Overview</title>
<title>Overview</title>
!Pdrivers/gpu/drm/drm_bridge.c overview
</sect3>
<sect3>
<title>Default bridge callback sequence</title>
<title>Default bridge callback sequence</title>
!Pdrivers/gpu/drm/drm_bridge.c bridge callbacks
</sect3>
!Edrivers/gpu/drm/drm_bridge.c
</sect2>
<sect2>
<title>Panel Helper Reference</title>
!Iinclude/drm/drm_panel.h
!Edrivers/gpu/drm/drm_panel.c
!Pdrivers/gpu/drm/drm_panel.c drm panel
</sect2>
</sect1>
<!-- Internals: kms properties -->
@ -1817,7 +1834,7 @@ void intel_crt_init(struct drm_device *dev)
</tr>
<tr>
<td rowspan="42" valign="top" >DRM</td>
<td valign="top" >Generic</td>
<td rowspan="2" valign="top" >Generic</td>
<td valign="top" >“rotation”</td>
<td valign="top" >BITMASK</td>
<td valign="top" >{ 0, "rotate-0" },
@ -1832,6 +1849,13 @@ void intel_crt_init(struct drm_device *dev)
image along the specified axis prior to rotation</td>
</tr>
<tr>
<td valign="top" >“scaling mode”</td>
<td valign="top" >ENUM</td>
<td valign="top" >{ "None", "Full", "Center", "Full aspect" }</td>
<td valign="top" >Connector</td>
<td valign="top" >Supported by: amdgpu, gma500, i915, nouveau and radeon.</td>
</tr>
<tr>
<td rowspan="5" valign="top" >Connector</td>
<td valign="top" >“EDID”</td>
<td valign="top" >BLOB | IMMUTABLE</td>
@ -2068,21 +2092,12 @@ void intel_crt_init(struct drm_device *dev)
<td valign="top" >property to suggest an Y offset for a connector</td>
</tr>
<tr>
<td rowspan="8" valign="top" >Optional</td>
<td valign="top" >“scaling mode”</td>
<td valign="top" >ENUM</td>
<td valign="top" >{ "None", "Full", "Center", "Full aspect" }</td>
<td valign="top" >Connector</td>
<td valign="top" >TBD</td>
</tr>
<tr>
<td rowspan="7" valign="top" >Optional</td>
<td valign="top" >"aspect ratio"</td>
<td valign="top" >ENUM</td>
<td valign="top" >{ "None", "4:3", "16:9" }</td>
<td valign="top" >Connector</td>
<td valign="top" >DRM property to set aspect ratio from user space app.
This enum is made generic to allow addition of custom aspect
ratios.</td>
<td valign="top" >TDB</td>
</tr>
<tr>
<td valign="top" >“dirty”</td>
@ -2153,7 +2168,11 @@ void intel_crt_init(struct drm_device *dev)
<td valign="top" >ENUM</td>
<td valign="top" >{ "Automatic", "Full", "Limited 16:235" }</td>
<td valign="top" >Connector</td>
<td valign="top" >TBD</td>
<td valign="top" >When this property is set to Limited 16:235
and CTM is set, the hardware will be programmed with the
result of the multiplication of CTM by the limited range
matrix to ensure the pixels normaly in the range 0..1.0 are
remapped to the range 16/255..235/255.</td>
</tr>
<tr>
<td valign="top" >“audio”</td>
@ -3334,7 +3353,7 @@ int num_ioctls;</synopsis>
<title>Video BIOS Table (VBT)</title>
!Pdrivers/gpu/drm/i915/intel_bios.c Video BIOS Table (VBT)
!Idrivers/gpu/drm/i915/intel_bios.c
!Idrivers/gpu/drm/i915/intel_bios.h
!Idrivers/gpu/drm/i915/intel_vbt_defs.h
</sect2>
</sect1>

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

@ -15,7 +15,7 @@
that are present on the transport stream. This is done through
<constant>/dev/dvb/adapter?/net?</constant> device node.
The data will be available via virtual <constant>dvb?_?</constant>
network interfaces, and will be controled/routed via the standard
network interfaces, and will be controlled/routed via the standard
ip tools (like ip, route, netstat, ifconfig, etc).</para>
<para> Data types and and ioctl definitions are defined via
<constant>linux/dvb/net.h</constant> header.</para>

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

@ -2685,10 +2685,6 @@ hardware may support both.</para>
and may change in the future.</para>
<itemizedlist>
<listitem>
<para>Video Output Overlay (OSD) Interface, <xref
linkend="osd" />.</para>
</listitem>
<listitem>
<para>&VIDIOC-DBG-G-REGISTER; and &VIDIOC-DBG-S-REGISTER;
ioctls.</para>
@ -2696,40 +2692,6 @@ ioctls.</para>
<listitem>
<para>&VIDIOC-DBG-G-CHIP-INFO; ioctl.</para>
</listitem>
<listitem>
<para>&VIDIOC-ENUM-DV-TIMINGS;, &VIDIOC-QUERY-DV-TIMINGS; and
&VIDIOC-DV-TIMINGS-CAP; ioctls.</para>
</listitem>
<listitem>
<para>Flash API. <xref linkend="flash-controls" /></para>
</listitem>
<listitem>
<para>&VIDIOC-CREATE-BUFS; and &VIDIOC-PREPARE-BUF; ioctls.</para>
</listitem>
<listitem>
<para>Selection API. <xref linkend="selection-api" /></para>
</listitem>
<listitem>
<para>Sub-device selection API: &VIDIOC-SUBDEV-G-SELECTION;
and &VIDIOC-SUBDEV-S-SELECTION; ioctls.</para>
</listitem>
<listitem>
<para>Support for frequency band enumeration: &VIDIOC-ENUM-FREQ-BANDS; ioctl.</para>
</listitem>
<listitem>
<para>Vendor and device specific media bus pixel formats.
<xref linkend="v4l2-mbus-vendor-spec-fmts" />.</para>
</listitem>
<listitem>
<para>Importing DMABUF file descriptors as a new IO method described
in <xref linkend="dmabuf" />.</para>
</listitem>
<listitem>
<para>Exporting DMABUF files using &VIDIOC-EXPBUF; ioctl.</para>
</listitem>
<listitem>
<para>Software Defined Radio (SDR) Interface, <xref linkend="sdr" />.</para>
</listitem>
</itemizedlist>
</section>

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

@ -2841,7 +2841,7 @@ for a GOP and keep it below or equal the set bitrate target. Otherwise the rate
overall average bitrate for the stream and keeps it below or equal to the set bitrate. In the first case
the average bitrate for the whole stream will be smaller then the set bitrate. This is caused because the
average is calculated for smaller number of frames, on the other hand enabling this setting will ensure that
the stream will meet tight bandwidth contraints. Applicable to encoders.
the stream will meet tight bandwidth constraints. Applicable to encoders.
</entry>
</row>
<row><entry></entry></row>
@ -4272,13 +4272,6 @@ manually or automatically if set to zero. Unit, range and step are driver-specif
<section id="flash-controls">
<title>Flash Control Reference</title>
<note>
<title>Experimental</title>
<para>This is an <link linkend="experimental">experimental</link>
interface and may change in the future.</para>
</note>
<para>
The V4L2 flash controls are intended to provide generic access
to flash controller devices. Flash controller devices are
@ -4743,14 +4736,6 @@ interface and may change in the future.</para>
<section id="image-source-controls">
<title>Image Source Control Reference</title>
<note>
<title>Experimental</title>
<para>This is an <link
linkend="experimental">experimental</link> interface and may
change in the future.</para>
</note>
<para>
The Image Source control class is intended for low-level
control of image source devices such as image sensors. The
@ -4862,14 +4847,6 @@ interface and may change in the future.</para>
<section id="image-process-controls">
<title>Image Process Control Reference</title>
<note>
<title>Experimental</title>
<para>This is an <link
linkend="experimental">experimental</link> interface and may
change in the future.</para>
</note>
<para>
The Image Process control class is intended for low-level control of
image processing functions. Unlike
@ -4955,14 +4932,6 @@ interface and may change in the future.</para>
<section id="dv-controls">
<title>Digital Video Control Reference</title>
<note>
<title>Experimental</title>
<para>This is an <link
linkend="experimental">experimental</link> interface and may
change in the future.</para>
</note>
<para>
The Digital Video control class is intended to control receivers
and transmitters for <ulink url="http://en.wikipedia.org/wiki/Vga">VGA</ulink>,

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

@ -85,7 +85,7 @@ initialize all fields of the &v4l2-vbi-format;
results of <constant>VIDIOC_G_FMT</constant>, and call the
&VIDIOC-S-FMT; ioctl with a pointer to this structure. Drivers return
an &EINVAL; only when the given parameters are ambiguous, otherwise
they modify the parameters according to the hardware capabilites and
they modify the parameters according to the hardware capabilities and
return the actual parameters. When the driver allocates resources at
this point, it may return an &EBUSY; to indicate the returned
parameters are valid but the required resources are currently not

6
Documentation/DocBook/media/v4l/dev-sdr.xml
View File

@ -1,11 +1,5 @@
<title>Software Defined Radio Interface (SDR)</title>
<note>
<title>Experimental</title>
<para>This is an <link linkend="experimental"> experimental </link>
interface and may change in the future.</para>
</note>
<para>
SDR is an abbreviation of Software Defined Radio, the radio device
which uses application software for modulation or demodulation. This interface

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

@ -1,11 +1,5 @@
<title>Sub-device Interface</title>
<note>
<title>Experimental</title>
<para>This is an <link linkend="experimental">experimental</link>
interface and may change in the future.</para>
</note>
<para>The complex nature of V4L2 devices, where hardware is often made of
several integrated circuits that need to interact with each other in a
controlled way, leads to complex V4L2 drivers. The drivers usually reflect

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

@ -475,12 +475,6 @@ rest should be evident.</para>
<section id="dmabuf">
<title>Streaming I/O (DMA buffer importing)</title>
<note>
<title>Experimental</title>
<para>This is an <link linkend="experimental">experimental</link>
interface and may change in the future.</para>
</note>
<para>The DMABUF framework provides a generic method for sharing buffers
between multiple devices. Device drivers that support DMABUF can export a DMA
buffer to userspace as a file descriptor (known as the exporter role), import a

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

@ -1,13 +1,6 @@
<section id="selection-api">
<title>Experimental API for cropping, composing and scaling</title>
<note>
<title>Experimental</title>
<para>This is an <link linkend="experimental">experimental</link>
interface and may change in the future.</para>
</note>
<title>API for cropping, composing and scaling</title>
<section>
<title>Introduction</title>

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

@ -4002,12 +4002,6 @@ see <xref linkend="colorspaces" />.</entry>
<section id="v4l2-mbus-vendor-spec-fmts">
<title>Vendor and Device Specific Formats</title>
<note>
<title>Experimental</title>
<para>This is an <link linkend="experimental">experimental</link>
interface and may change in the future.</para>
</note>
<para>This section lists complex data formats that are either vendor or
device specific.
</para>

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

@ -49,12 +49,6 @@
<refsect1>
<title>Description</title>
<note>
<title>Experimental</title>
<para>This is an <link linkend="experimental"> experimental </link>
interface and may change in the future.</para>
</note>
<para>This ioctl is used to create buffers for <link linkend="mmap">memory
mapped</link> or <link linkend="userp">user pointer</link> or <link
linkend="dmabuf">DMA buffer</link> I/O. It can be used as an alternative or in

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

@ -49,14 +49,9 @@
<refsect1>
<title>Description</title>
<note>
<title>Experimental</title>
<para>This is an <link linkend="experimental"> experimental </link>
interface and may change in the future.</para>
</note>
<para>To query the capabilities of the DV receiver/transmitter applications
can call the <constant>VIDIOC_DV_TIMINGS_CAP</constant> ioctl on a video node
<para>To query the capabilities of the DV receiver/transmitter applications initialize the
<structfield>pad</structfield> field to 0, zero the reserved array of &v4l2-dv-timings-cap;
and call the <constant>VIDIOC_DV_TIMINGS_CAP</constant> ioctl on a video node
and the driver will fill in the structure. Note that drivers may return
different values after switching the video input or output.</para>
@ -65,8 +60,8 @@ queried by calling the <constant>VIDIOC_SUBDEV_DV_TIMINGS_CAP</constant> ioctl
directly on a subdevice node. The capabilities are specific to inputs (for DV
receivers) or outputs (for DV transmitters), applications must specify the
desired pad number in the &v4l2-dv-timings-cap; <structfield>pad</structfield>
field. Attempts to query capabilities on a pad that doesn't support them will
return an &EINVAL;.</para>
field and zero the <structfield>reserved</structfield> array. Attempts to query
capabilities on a pad that doesn't support them will return an &EINVAL;.</para>
<table pgwide="1" frame="none" id="v4l2-bt-timings-cap">
<title>struct <structname>v4l2_bt_timings_cap</structname></title>
@ -145,7 +140,8 @@ return an &EINVAL;.</para>
<row>
<entry>__u32</entry>
<entry><structfield>reserved</structfield>[2]</entry>
<entry>Reserved for future extensions. Drivers must set the array to zero.</entry>
<entry>Reserved for future extensions. Drivers and applications must
set the array to zero.</entry>
</row>
<row>
<entry>union</entry>

11
Documentation/DocBook/media/v4l/vidioc-enum-dv-timings.xml
View File

@ -49,20 +49,15 @@
<refsect1>
<title>Description</title>
<note>
<title>Experimental</title>
<para>This is an <link linkend="experimental"> experimental </link>
interface and may change in the future.</para>
</note>
<para>While some DV receivers or transmitters support a wide range of timings, others
support only a limited number of timings. With this ioctl applications can enumerate a list
of known supported timings. Call &VIDIOC-DV-TIMINGS-CAP; to check if it also supports other
standards or even custom timings that are not in this list.</para>
<para>To query the available timings, applications initialize the
<structfield>index</structfield> field and zero the reserved array of &v4l2-enum-dv-timings;
and call the <constant>VIDIOC_ENUM_DV_TIMINGS</constant> ioctl on a video node with a
<structfield>index</structfield> field, set the <structfield>pad</structfield> field to 0,
zero the reserved array of &v4l2-enum-dv-timings; and call the
<constant>VIDIOC_ENUM_DV_TIMINGS</constant> ioctl on a video node with a
pointer to this structure. Drivers fill the rest of the structure or return an
&EINVAL; when the index is out of bounds. To enumerate all supported DV timings,
applications shall begin at index zero, incrementing by one until the

6
Documentation/DocBook/media/v4l/vidioc-enum-freq-bands.xml
View File

@ -49,12 +49,6 @@
<refsect1>
<title>Description</title>
<note>
<title>Experimental</title>
<para>This is an <link linkend="experimental"> experimental </link>
interface and may change in the future.</para>
</note>
<para>Enumerates the frequency bands that a tuner or modulator supports.
To do this applications initialize the <structfield>tuner</structfield>,
<structfield>type</structfield> and <structfield>index</structfield> fields,

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

@ -49,12 +49,6 @@
<refsect1>
<title>Description</title>
<note>
<title>Experimental</title>
<para>This is an <link linkend="experimental"> experimental </link>
interface and may change in the future.</para>
</note>
<para>This ioctl is an extension to the <link linkend="mmap">memory
mapping</link> I/O method, therefore it is available only for
<constant>V4L2_MEMORY_MMAP</constant> buffers. It can be used to export a

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

@ -1,6 +1,6 @@
<refentry id="vidioc-g-edid">
<refmeta>
<refentrytitle>ioctl VIDIOC_G_EDID, VIDIOC_S_EDID</refentrytitle>
<refentrytitle>ioctl VIDIOC_G_EDID, VIDIOC_S_EDID, VIDIOC_SUBDEV_G_EDID, VIDIOC_SUBDEV_S_EDID</refentrytitle>
&manvol;
</refmeta>
@ -71,7 +71,8 @@
<para>To get the EDID data the application has to fill in the <structfield>pad</structfield>,
<structfield>start_block</structfield>, <structfield>blocks</structfield> and <structfield>edid</structfield>
fields and call <constant>VIDIOC_G_EDID</constant>. The current EDID from block
fields, zero the <structfield>reserved</structfield> array and call
<constant>VIDIOC_G_EDID</constant>. The current EDID from block
<structfield>start_block</structfield> and of size <structfield>blocks</structfield>
will be placed in the memory <structfield>edid</structfield> points to. The <structfield>edid</structfield>
pointer must point to memory at least <structfield>blocks</structfield>&nbsp;*&nbsp;128 bytes
@ -92,8 +93,9 @@
the driver will set <structfield>blocks</structfield> to 0 and it returns 0.</para>
<para>To set the EDID blocks of a receiver the application has to fill in the <structfield>pad</structfield>,
<structfield>blocks</structfield> and <structfield>edid</structfield> fields and set
<structfield>start_block</structfield> to 0. It is not possible to set part of an EDID,
<structfield>blocks</structfield> and <structfield>edid</structfield> fields, set
<structfield>start_block</structfield> to 0 and zero the <structfield>reserved</structfield> array.
It is not possible to set part of an EDID,
it is always all or nothing. Setting the EDID data is only valid for receivers as it makes
no sense for a transmitter.</para>

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

@ -50,12 +50,6 @@
<refsect1>
<title>Description</title>
<note>
<title>Experimental</title>
<para>This is an <link linkend="experimental"> experimental </link>
interface and may change in the future.</para>
</note>
<para>The ioctls are used to query and configure selection rectangles.</para>
<para>To query the cropping (composing) rectangle set &v4l2-selection;
@ -222,7 +216,7 @@ or the <structfield>flags</structfield> argument is not valid.</para>
<term><errorcode>ERANGE</errorcode></term>
<listitem>
<para>It is not possible to adjust &v4l2-rect; <structfield>
r</structfield> rectangle to satisfy all contraints given in the
r</structfield> rectangle to satisfy all constraints given in the
<structfield>flags</structfield> argument.</para>
</listitem>
</varlistentry>

6
Documentation/DocBook/media/v4l/vidioc-prepare-buf.xml
View File

@ -48,12 +48,6 @@
<refsect1>
<title>Description</title>
<note>
<title>Experimental</title>
<para>This is an <link linkend="experimental"> experimental </link>
interface and may change in the future.</para>
</note>
<para>Applications can optionally call the
<constant>VIDIOC_PREPARE_BUF</constant> ioctl to pass ownership of the buffer
to the driver before actually enqueuing it, using the

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

@ -50,12 +50,6 @@ input</refpurpose>
<refsect1>
<title>Description</title>
<note>
<title>Experimental</title>
<para>This is an <link linkend="experimental"> experimental </link>
interface and may change in the future.</para>
</note>
<para>The hardware may be able to detect the current DV timings
automatically, similar to sensing the video standard. To do so, applications
call <constant>VIDIOC_QUERY_DV_TIMINGS</constant> with a pointer to a

8
Documentation/DocBook/media/v4l/vidioc-streamon.xml
View File

@ -123,6 +123,14 @@ synchronize with other events.</para>
</para>
</listitem>
</varlistentry>
<varlistentry>
<term><errorcode>ENOLINK</errorcode></term>
<listitem>
<para>The driver implements Media Controller interface and
the pipeline link configuration is invalid.
</para>
</listitem>
</varlistentry>
</variablelist>
</refsect1>
</refentry>

6
Documentation/DocBook/media/v4l/vidioc-subdev-enum-frame-interval.xml
View File

@ -49,12 +49,6 @@
<refsect1>
<title>Description</title>
<note>
<title>Experimental</title>
<para>This is an <link linkend="experimental">experimental</link>
interface and may change in the future.</para>
</note>
<para>This ioctl lets applications enumerate available frame intervals on a
given sub-device pad. Frame intervals only makes sense for sub-devices that
can control the frame period on their own. This includes, for instance,

6
Documentation/DocBook/media/v4l/vidioc-subdev-enum-frame-size.xml
View File

@ -49,12 +49,6 @@
<refsect1>
<title>Description</title>
<note>
<title>Experimental</title>
<para>This is an <link linkend="experimental">experimental</link>
interface and may change in the future.</para>
</note>
<para>This ioctl allows applications to enumerate all frame sizes
supported by a sub-device on the given pad for the given media bus format.
Supported formats can be retrieved with the &VIDIOC-SUBDEV-ENUM-MBUS-CODE;

6
Documentation/DocBook/media/v4l/vidioc-subdev-enum-mbus-code.xml
View File

@ -49,12 +49,6 @@
<refsect1>
<title>Description</title>
<note>
<title>Experimental</title>
<para>This is an <link linkend="experimental">experimental</link>
interface and may change in the future.</para>
</note>
<para>To enumerate media bus formats available at a given sub-device pad
applications initialize the <structfield>pad</structfield>, <structfield>which</structfield>
and <structfield>index</structfield> fields of &v4l2-subdev-mbus-code-enum; and

6
Documentation/DocBook/media/v4l/vidioc-subdev-g-fmt.xml
View File

@ -50,12 +50,6 @@
<refsect1>
<title>Description</title>
<note>
<title>Experimental</title>
<para>This is an <link linkend="experimental">experimental</link>
interface and may change in the future.</para>
</note>
<para>These ioctls are used to negotiate the frame format at specific
subdev pads in the image pipeline.</para>

6
Documentation/DocBook/media/v4l/vidioc-subdev-g-frame-interval.xml
View File

@ -50,12 +50,6 @@
<refsect1>
<title>Description</title>
<note>
<title>Experimental</title>
<para>This is an <link linkend="experimental">experimental</link>
interface and may change in the future.</para>
</note>
<para>These ioctls are used to get and set the frame interval at specific
subdev pads in the image pipeline. The frame interval only makes sense for
sub-devices that can control the frame period on their own. This includes,

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

@ -49,12 +49,6 @@
<refsect1>
<title>Description</title>
<note>
<title>Experimental</title>
<para>This is an <link linkend="experimental">experimental</link>
interface and may change in the future.</para>
</note>
<para>The selections are used to configure various image
processing functionality performed by the subdevs which affect the
image size. This currently includes cropping, scaling and

12
Documentation/IRQ-domain.txt
View File

@ -70,6 +70,7 @@ of the reverse map types are described below:
==== Linear ====
irq_domain_add_linear()
irq_domain_create_linear()
The linear reverse map maintains a fixed size table indexed by the
hwirq number. When a hwirq is mapped, an irq_desc is allocated for
@ -81,10 +82,16 @@ map are fixed time lookup for IRQ numbers, and irq_descs are only
allocated for in-use IRQs. The disadvantage is that the table must be
as large as the largest possible hwirq number.
irq_domain_add_linear() and irq_domain_create_linear() are functionally
equivalent, except for the first argument is different - the former
accepts an Open Firmware specific 'struct device_node', while the latter
accepts a more general abstraction 'struct fwnode_handle'.
The majority of drivers should use the linear map.
==== Tree ====
irq_domain_add_tree()
irq_domain_create_tree()
The irq_domain maintains a radix tree map from hwirq numbers to Linux
IRQs. When an hwirq is mapped, an irq_desc is allocated and the
@ -95,6 +102,11 @@ since it doesn't need to allocate a table as large as the largest
hwirq number. The disadvantage is that hwirq to IRQ number lookup is
dependent on how many entries are in the table.
irq_domain_add_tree() and irq_domain_create_tree() are functionally
equivalent, except for the first argument is different - the former
accepts an Open Firmware specific 'struct device_node', while the latter
accepts a more general abstraction 'struct fwnode_handle'.
Very few drivers should need this mapping.
==== No Map ===-

5
Documentation/Makefile
View File

@ -1,4 +1,3 @@
subdir-y := accounting auxdisplay blackfin connector \
subdir-y := accounting auxdisplay blackfin \
filesystems filesystems ia64 laptops mic misc-devices \
networking pcmcia prctl ptp timers vDSO video4linux \
watchdog
networking pcmcia prctl ptp timers vDSO watchdog

6
Documentation/RCU/RTFP.txt
View File

@ -176,13 +176,13 @@ a history of how Linux changed RCU more than RCU changed Linux
which Mathieu Desnoyers is now maintaining [MathieuDesnoyers2009URCU]
[MathieuDesnoyersPhD]. TINY_RCU [PaulEMcKenney2009BloatWatchRCU] made
its appearance, as did expedited RCU [PaulEMcKenney2009expeditedRCU].
The problem of resizeable RCU-protected hash tables may now be on a path
The problem of resizable RCU-protected hash tables may now be on a path
to a solution [JoshTriplett2009RPHash]. A few academic researchers are now
using RCU to solve their parallel problems [HariKannan2009DynamicAnalysisRCU].
2010 produced a simpler preemptible-RCU implementation
based on TREE_RCU [PaulEMcKenney2010SimpleOptRCU], lockdep-RCU
[PaulEMcKenney2010LockdepRCU], another resizeable RCU-protected hash
[PaulEMcKenney2010LockdepRCU], another resizable RCU-protected hash
table [HerbertXu2010RCUResizeHash] (this one consuming more memory,
but allowing arbitrary changes in hash function, as required for DoS
avoidance in the networking code), realization of the 2009 RCU-protected
@ -193,7 +193,7 @@ the RCU API [PaulEMcKenney2010RCUAPI].
[LinusTorvalds2011Linux2:6:38:rc1:NPigginVFS], an RCU-protected red-black
tree using software transactional memory to protect concurrent updates
(strange, but true!) [PhilHoward2011RCUTMRBTree], yet another variant of
RCU-protected resizeable hash tables [Triplett:2011:RPHash], the 3.0 RCU
RCU-protected resizable hash tables [Triplett:2011:RPHash], the 3.0 RCU
trainwreck [PaulEMcKenney2011RCU3.0trainwreck], and Neil Brown's "Meet the
Lockers" LWN article [NeilBrown2011MeetTheLockers]. Some academic
work looked at debugging uses of RCU [Seyster:2011:RFA:2075416.2075425].

2
Documentation/adding-syscalls.txt
View File

@ -136,7 +136,7 @@ an fxyzzy(3) operation for free:
- xyzzyat(fd, "", ..., AT_EMPTY_PATH) is equivalent to fxyzzy(fd, ...)
(For more details on the rationale of the *at() calls, see the openat(2) man
page; for an example of AT_EMPTY_PATH, see the statat(2) man page.)
page; for an example of AT_EMPTY_PATH, see the fstatat(2) man page.)
If your new xyzzy(2) system call involves a parameter describing an offset
within a file, make its type loff_t so that 64-bit offsets can be supported

2
Documentation/arm/SA1100/Assabet
View File

@ -214,7 +214,7 @@ RedBoot scripting
-----------------
All the commands above aren't so useful if they have to be typed in every
time the Assabet is rebooted. Therefore it's possible to automatize the boot
time the Assabet is rebooted. Therefore it's possible to automate the boot
process using RedBoot's scripting capability.
For example, I use this to boot Linux with both the kernel and the ramdisk

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

@ -53,7 +53,10 @@ stable kernels.
| ARM | Cortex-A57 | #832075 | ARM64_ERRATUM_832075 |
| ARM | Cortex-A57 | #852523 | N/A |
| ARM | Cortex-A57 | #834220 | ARM64_ERRATUM_834220 |
| ARM | MMU-500 | #841119,#826419 | N/A |
| | | | |
| Cavium | ThunderX ITS | #22375, #24313 | CAVIUM_ERRATUM_22375 |
| Cavium | ThunderX ITS | #23144 | CAVIUM_ERRATUM_23144 |
| Cavium | ThunderX GICv3 | #23154 | CAVIUM_ERRATUM_23154 |
| Cavium | ThunderX Core | #27456 | CAVIUM_ERRATUM_27456 |
| Cavium | ThunderX SMMUv2 | #27704 | N/A |

4
Documentation/block/00-INDEX
View File

@ -2,6 +2,8 @@
- This file
biodoc.txt
- Notes on the Generic Block Layer Rewrite in Linux 2.5
biovecs.txt
- Immutable biovecs and biovec iterators
capability.txt
- Generic Block Device Capability (/sys/block/<device>/capability)
cfq-iosched.txt
@ -14,6 +16,8 @@ deadline-iosched.txt
- Deadline IO scheduler tunables
ioprio.txt
- Block io priorities (in CFQ scheduler)
pr.txt
- Block layer support for Persistent Reservations
null_blk.txt
- Null block for block-layer benchmarking.
queue-sysfs.txt

26
Documentation/blockdev/zram.txt
View File

@ -59,27 +59,16 @@ num_devices parameter is optional and tells zram how many devices should be
pre-created. Default: 1.
2) Set max number of compression streams
Compression backend may use up to max_comp_streams compression streams,
thus allowing up to max_comp_streams concurrent compression operations.
By default, compression backend uses single compression stream.
Regardless the value passed to this attribute, ZRAM will always
allocate multiple compression streams - one per online CPUs - thus
allowing several concurrent compression operations. The number of
allocated compression streams goes down when some of the CPUs
become offline. There is no single-compression-stream mode anymore,
unless you are running a UP system or has only 1 CPU online.
Examples:
#show max compression streams number
To find out how many streams are currently available:
cat /sys/block/zram0/max_comp_streams
#set max compression streams number to 3
echo 3 > /sys/block/zram0/max_comp_streams
Note:
In order to enable compression backend's multi stream support max_comp_streams
must be initially set to desired concurrency level before ZRAM device
initialisation. Once the device initialised as a single stream compression
backend (max_comp_streams equals to 1), you will see error if you try to change
the value of max_comp_streams because single stream compression backend
implemented as a special case by lock overhead issue and does not support
dynamic max_comp_streams. Only multi stream backend supports dynamic
max_comp_streams adjustment.
3) Select compression algorithm
Using comp_algorithm device attribute one can see available and
currently selected (shown in square brackets) compression algorithms,
@ -183,6 +172,7 @@ mem_limit RW the maximum amount of memory ZRAM can use to store
pages_compacted RO the number of pages freed during compaction
(available only via zram<id>/mm_stat node)
compact WO trigger memory compaction
debug_stat RO this file is used for zram debugging purposes
WARNING
=======

14
Documentation/cgroup-v1/memory.txt
View File

@ -280,17 +280,9 @@ the amount of kernel memory used by the system. Kernel memory is fundamentally
different than user memory, since it can't be swapped out, which makes it
possible to DoS the system by consuming too much of this precious resource.
Kernel memory won't be accounted at all until limit on a group is set. This
allows for existing setups to continue working without disruption. The limit
cannot be set if the cgroup have children, or if there are already tasks in the
cgroup. Attempting to set the limit under those conditions will return -EBUSY.
When use_hierarchy == 1 and a group is accounted, its children will
automatically be accounted regardless of their limit value.
After a group is first limited, it will be kept being accounted until it
is removed. The memory limitation itself, can of course be removed by writing
-1 to memory.kmem.limit_in_bytes. In this case, kmem will be accounted, but not
limited.
Kernel memory accounting is enabled for all memory cgroups by default. But
it can be disabled system-wide by passing cgroup.memory=nokmem to the kernel
at boot time. In this case, kernel memory will not be accounted at all.
Kernel memory limits are not imposed for the root cgroup. Usage for the root
cgroup may or may not be accounted. The memory used is accumulated into

8
Documentation/connector/connector.txt
View File

@ -186,3 +186,11 @@ only cn_test.c test module used it.
Some work in netlink area is still being done, so things can be changed in
2.6.15 timeframe, if it will happen, documentation will be updated for that
kernel.
/*****************************************/
Code samples
/*****************************************/
Sample code for a connector test module and user space can be found
in samples/connector/. To build this code, enable CONFIG_CONNECTOR
and CONFIG_SAMPLES.

84
Documentation/devices.txt
View File

@ -1,20 +1,17 @@
LINUX ALLOCATED DEVICES (2.6+ version)
Maintained by Alan Cox <device@lanana.org>
Last revised: 6th April 2009
LINUX ALLOCATED DEVICES (4.x+ version)
This list is the Linux Device List, the official registry of allocated
device numbers and /dev directory nodes for the Linux operating
system.
The latest version of this list is available from
http://www.lanana.org/docs/device-list/ or
ftp://ftp.kernel.org/pub/linux/docs/device-list/. This version may be
newer than the one distributed with the Linux kernel.
The LaTeX version of this document is no longer maintained.
The LaTeX version of this document is no longer maintained, nor is
the document that used to reside at lanana.org. This version in the
mainline Linux kernel is the master document. Updates shall be sent
as patches to the kernel maintainers (see the SubmittingPatches document).
Specifically explore the sections titled "CHAR and MISC DRIVERS", and
"BLOCK LAYER" in the MAINTAINERS file to find the right maintainers
to involve for character and block devices.
This document is included by reference into the Filesystem Hierarchy
Standard (FHS). The FHS is available from http://www.pathname.com/fhs/.
@ -23,60 +20,33 @@ Allocations marked (68k/Amiga) apply to Linux/68k on the Amiga
platform only. Allocations marked (68k/Atari) apply to Linux/68k on
the Atari platform only.
The symbol {2.6} means the allocation is obsolete and scheduled for
removal once kernel version 2.6 (or equivalent) is released. Some of these
allocations have already been removed.
This document is in the public domain. The author requests, however,
This document is in the public domain. The authors requests, however,
that semantically altered versions are not distributed without
permission of the author, assuming the author can be contacted without
permission of the authors, assuming the authors can be contacted without
an unreasonable effort.
In particular, please don't sent patches for this list to Linus, at
least not without contacting me first.
I do not have any information about these devices beyond what appears
on this list. Any such information requests will be deleted without
reply.
**** DEVICE DRIVERS AUTHORS PLEASE READ THIS ****
Linux now has extensive support for dynamic allocation of device numbering
and can use sysfs and udev (systemd) to handle the naming needs. There are
still some exceptions in the serial and boot device area. Before asking
for a device number make sure you actually need one.
To have a major number allocated, or a minor number in situations
where that applies (e.g. busmice), please contact me with the
appropriate device information. Also, if you have additional
information regarding any of the devices listed below, or if I have
made a mistake, I would greatly appreciate a note.
where that applies (e.g. busmice), please submit a patch and send to
the authors as indicated above.
I do, however, make a few requests about the nature of your report.
This is necessary for me to be able to keep this list up to date and
correct in a timely manner. First of all, *please* send it to the
correct address... <device@lanana.org>. I receive hundreds of email
messages a day, so mail sent to other addresses may very well get lost
in the avalanche. Please put in a descriptive subject, so I can find
your mail again should I need to. Too many people send me email
saying just "device number request" in the subject.
Second, please include a description of the device *in the same format
as this list*. The reason for this is that it is the only way I have
found to ensure I have all the requisite information to publish your
Keep the description of the device *in the same format
as this list*. The reason for this is that it is the only way we have
found to ensure we have all the requisite information to publish your
device and avoid conflicts.
Third, please don't assume that the distributed version of the list is
up to date. Due to the number of registrations I have to maintain it
in "batch mode", so there is likely additional registrations that
haven't been listed yet.
Fourth, remember that Linux now has extensive support for dynamic allocation
of device numbering and can use sysfs and udev to handle the naming needs.
There are still some exceptions in the serial and boot device area. Before
asking for a device number make sure you actually need one.
Finally, sometimes I have to play "namespace police." Please don't be
offended. I often get submissions for /dev names that would be bound
to cause conflicts down the road. I am trying to avoid getting in a
Finally, sometimes we have to play "namespace police." Please don't be
offended. We often get submissions for /dev names that would be bound
to cause conflicts down the road. We are trying to avoid getting in a
situation where we would have to suffer an incompatible forward
change. Therefore, please consult with me *before* you make your
change. Therefore, please consult with us *before* you make your
device names and numbers in any way public, at least to the point
where it would be at all difficult to get them changed.
@ -3099,9 +3069,9 @@ Your cooperation is appreciated.
129 = /dev/ipath_sma Device used by Subnet Management Agent
130 = /dev/ipath_diag Device used by diagnostics programs
234-239 UNASSIGNED
240-254 char LOCAL/EXPERIMENTAL USE
234-254 char RESERVED FOR DYNAMIC ASSIGNMENT
Character devices that request a dynamic allocation of major number will
take numbers starting from 254 and downward.
240-254 block LOCAL/EXPERIMENTAL USE
Allocated for local/experimental use. For devices not

7
Documentation/devicetree/bindings/arc/eznps.txt Normal file
View File

@ -0,0 +1,7 @@
EZchip NPS Network Processor Platforms Device Tree Bindings
---------------------------------------------------------------------------
Appliance main board with NPS400 ASIC.
Required root node properties:
- compatible = "ezchip,arc-nps";

3
Documentation/devicetree/bindings/arm/amlogic.txt
View File

@ -25,3 +25,6 @@ Board compatible values:
- "tronsmart,vega-s95-pro", "tronsmart,vega-s95" (Meson gxbb)
- "tronsmart,vega-s95-meta", "tronsmart,vega-s95" (Meson gxbb)
- "tronsmart,vega-s95-telos", "tronsmart,vega-s95" (Meson gxbb)
- "hardkernel,odroid-c2" (Meson gxbb)
- "amlogic,p200" (Meson gxbb)
- "amlogic,p201" (Meson gxbb)

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

@ -93,6 +93,14 @@ Required nodes:
a core-module with regs and the compatible strings
"arm,core-module-versatile", "syscon"
Optional nodes:
- arm,versatile-ib2-syscon : if the Versatile has an IB2 interface
board mounted, this has a separate system controller that is
defined in this node.
Required properties:
compatible = "arm,versatile-ib2-syscon", "syscon"
ARM RealView Boards
-------------------
The RealView boards cover tailored evaluation boards that are used to explore

65
Documentation/devicetree/bindings/arm/atmel-at91.txt
View File

@ -41,6 +41,10 @@ compatible: must be one of:
- "atmel,sama5d43"
- "atmel,sama5d44"
Chipid required properties:
- compatible: Should be "atmel,sama5d2-chipid"
- reg : Should contain registers location and length
PIT Timer required properties:
- compatible: Should be "atmel,at91sam9260-pit"
- reg: Should contain registers location and length
@ -147,6 +151,65 @@ Example:
clocks = <&clk32k>;
};
SHDWC SAMA5D2-Compatible Shutdown Controller
1) shdwc node
required properties:
- compatible: should be "atmel,sama5d2-shdwc".
- reg: should contain registers location and length
- clocks: phandle to input clock.
- #address-cells: should be one. The cell is the wake-up input index.
- #size-cells: should be zero.
optional properties:
- debounce-delay-us: minimum wake-up inputs debouncer period in
microseconds. It's usually a board-related property.
- atmel,wakeup-rtc-timer: boolean to enable Real-Time Clock wake-up.
The node contains child nodes for each wake-up input that the platform uses.
2) input nodes
Wake-up input nodes are usually described in the "board" part of the Device
Tree. Note also that input 0 is linked to the wake-up pin and is frequently
used.
Required properties:
- reg: should contain the wake-up input index [0 - 15].
Optional properties:
- atmel,wakeup-active-high: boolean, the corresponding wake-up input described
by the child, forces the wake-up of the core power supply on a high level.
The default is to be active low.
Example:
On the SoC side:
shdwc@f8048010 {
compatible = "atmel,sama5d2-shdwc";
reg = <0xf8048010 0x10>;
clocks = <&clk32k>;
#address-cells = <1>;
#size-cells = <0>;
atmel,wakeup-rtc-timer;
};
On the board side:
shdwc@f8048010 {
debounce-delay-us = <976>;
input@0 {
reg = <0>;
};
input@1 {
reg = <1>;
atmel,wakeup-active-high;
};
};
Special Function Registers (SFR)
Special Function Registers (SFR) manage specific aspects of the integrated
@ -155,7 +218,7 @@ elsewhere.
required properties:
- compatible: Should be "atmel,<chip>-sfr", "syscon".
<chip> can be "sama5d3" or "sama5d4".
<chip> can be "sama5d3", "sama5d4" or "sama5d2".
- reg: Should contain registers location and length
sfr@f0038000 {

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

@ -100,7 +100,7 @@ specific to ARM.
"arm,cci-400-pmu,r0"
"arm,cci-400-pmu,r1"
"arm,cci-400-pmu" - DEPRECATED, permitted only where OS has
secure acces to CCI registers
secure access to CCI registers
"arm,cci-500-pmu,r0"
"arm,cci-550-pmu,r0"
- reg:

28
Documentation/devicetree/bindings/arm/coresight.txt
View File

@ -19,6 +19,7 @@ its hardware characteristcs.
- "arm,coresight-etm3x", "arm,primecell";
- "arm,coresight-etm4x", "arm,primecell";
- "qcom,coresight-replicator1x", "arm,primecell";
- "arm,coresight-stm", "arm,primecell"; [1]
* reg: physical base address and length of the register
set(s) of the component.
@ -36,6 +37,14 @@ its hardware characteristcs.
layout using the generic DT graph presentation found in
"bindings/graph.txt".
* Additional required properties for System Trace Macrocells (STM):
* reg: along with the physical base address and length of the register
set as described above, another entry is required to describe the
mapping of the extended stimulus port area.
* reg-names: the only acceptable values are "stm-base" and
"stm-stimulus-base", each corresponding to the areas defined in "reg".
* Required properties for devices that don't show up on the AMBA bus, such as
non-configurable replicators:
@ -202,3 +211,22 @@ Example:
};
};
};
4. STM
stm@20100000 {
compatible = "arm,coresight-stm", "arm,primecell";
reg = <0 0x20100000 0 0x1000>,
<0 0x28000000 0 0x180000>;
reg-names = "stm-base", "stm-stimulus-base";
clocks = <&soc_smc50mhz>;
clock-names = "apb_pclk";
port {
stm_out_port: endpoint {
remote-endpoint = <&main_funnel_in_port2>;
};
};
};
[1]. There is currently two version of STM: STM32 and STM500. Both
have the same HW interface and as such don't need an explicit binding name.

4
Documentation/devicetree/bindings/arm/fsl.txt
View File

@ -135,6 +135,10 @@ LS1043A ARMv8 based RDB Board
Required root node properties:
- compatible = "fsl,ls1043a-rdb", "fsl,ls1043a";
LS1043A ARMv8 based QDS Board
Required root node properties:
- compatible = "fsl,ls1043a-qds", "fsl,ls1043a";
LS2080A ARMv8 based Simulator model
Required root node properties:
- compatible = "fsl,ls2080a-simu", "fsl,ls2080a";

24
Documentation/devicetree/bindings/arm/hisilicon/hisilicon.txt
View File

@ -1,29 +1,33 @@
Hisilicon Platforms Device Tree Bindings
----------------------------------------------------
Hi6220 SoC
Required root node properties:
- compatible = "hisilicon,hi6220";
Hi4511 Board
Required root node properties:
- compatible = "hisilicon,hi3620-hi4511";
HiP04 D01 Board
Hi6220 SoC
Required root node properties:
- compatible = "hisilicon,hip04-d01";
HiP01 ca9x2 Board
Required root node properties:
- compatible = "hisilicon,hip01-ca9x2";
- compatible = "hisilicon,hi6220";
HiKey Board
Required root node properties:
- compatible = "hisilicon,hi6220-hikey", "hisilicon,hi6220";
HiP01 ca9x2 Board
Required root node properties:
- compatible = "hisilicon,hip01-ca9x2";
HiP04 D01 Board
Required root node properties:
- compatible = "hisilicon,hip04-d01";
HiP05 D02 Board
Required root node properties:
- compatible = "hisilicon,hip05-d02";
HiP06 D03 Board
Required root node properties:
- compatible = "hisilicon,hip06-d03";
Hisilicon system controller
Required properties:

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

@ -84,6 +84,12 @@ Optional properties:
- prefetch-instr : Instruction prefetch. Value: <0> (forcibly disable),
<1> (forcibly enable), property absent (retain settings set by
firmware)
- arm,dynamic-clock-gating : L2 dynamic clock gating. Value: <0> (forcibly
disable), <1> (forcibly enable), property absent (OS specific behavior,
preferrably retain firmware settings)
- arm,standby-mode: L2 standby mode enable. Value <0> (forcibly disable),
<1> (forcibly enable), property absent (OS specific behavior,
preferrably retain firmware settings)
Example:

35
Documentation/devicetree/bindings/arm/marvell/ap806-system-controller.txt Normal file
View File

@ -0,0 +1,35 @@
Marvell Armada AP806 System Controller
======================================
The AP806 is one of the two core HW blocks of the Marvell Armada 7K/8K
SoCs. It contains a system controller, which provides a number
registers giving access to numerous features: clocks, pin-muxing and
many other SoC configuration items. This DT binding allows to describe
this system controller.
The Device Tree node representing the AP806 system controller provides
a number of clocks:
- 0: clock of CPU cluster 0
- 1: clock of CPU cluster 1
- 2: fixed PLL at 1200 Mhz
- 3: MSS clock, derived from the fixed PLL
Required properties:
- compatible: must be:
"marvell,ap806-system-controller", "syscon"
- reg: register area of the AP806 system controller
- #clock-cells: must be set to 1
- clock-output-names: must be defined to:
"ap-cpu-cluster-0", "ap-cpu-cluster-1", "ap-fixed", "ap-mss"
Example:
syscon: system-controller@6f4000 {
compatible = "marvell,ap806-system-controller", "syscon";
#clock-cells = <1>;
clock-output-names = "ap-cpu-cluster-0", "ap-cpu-cluster-1",
"ap-fixed", "ap-mss";
reg = <0x6f4000 0x1000>;
};

83
Documentation/devicetree/bindings/arm/marvell/cp110-system-controller0.txt Normal file
View File

@ -0,0 +1,83 @@
Marvell Armada CP110 System Controller 0
========================================
The CP110 is one of the two core HW blocks of the Marvell Armada 7K/8K
SoCs. It contains two sets of system control registers, System
Controller 0 and System Controller 1. This Device Tree binding allows
to describe the first system controller, which provides registers to
configure various aspects of the SoC.
The Device Tree node representing this System Controller 0 provides a
number of clocks:
- a set of core clocks
- a set of gatable clocks
Those clocks can be referenced by other Device Tree nodes using two
cells:
- The first cell must be 0 or 1. 0 for the core clocks and 1 for the
gatable clocks.
- The second cell identifies the particular core clock or gatable
clocks.
The following clocks are available:
- Core clocks
- 0 0 APLL
- 0 1 PPv2 core
- 0 2 EIP
- 0 3 Core
- 0 4 NAND core
- Gatable clocks
- 1 0 Audio
- 1 1 Comm Unit
- 1 2 NAND
- 1 3 PPv2
- 1 4 SDIO
- 1 5 MG Domain
- 1 6 MG Core
- 1 7 XOR1
- 1 8 XOR0
- 1 9 GOP DP
- 1 11 PCIe x1 0
- 1 12 PCIe x1 1
- 1 13 PCIe x4
- 1 14 PCIe / XOR
- 1 15 SATA
- 1 16 SATA USB
- 1 17 Main
- 1 18 SD/MMC
- 1 21 Slow IO (SPI, NOR, BootROM, I2C, UART)
- 1 22 USB3H0
- 1 23 USB3H1
- 1 24 USB3 Device
- 1 25 EIP150
- 1 26 EIP197
Required properties:
- compatible: must be:
"marvell,cp110-system-controller0", "syscon";
- reg: register area of the CP110 system controller 0
- #clock-cells: must be set to 2
- core-clock-output-names must be set to:
"cpm-apll", "cpm-ppv2-core", "cpm-eip", "cpm-core", "cpm-nand-core"
- gate-clock-output-names must be set to:
"cpm-audio", "cpm-communit", "cpm-nand", "cpm-ppv2", "cpm-sdio",
"cpm-mg-domain", "cpm-mg-core", "cpm-xor1", "cpm-xor0", "cpm-gop-dp", "none",
"cpm-pcie_x10", "cpm-pcie_x11", "cpm-pcie_x4", "cpm-pcie-xor", "cpm-sata",
"cpm-sata-usb", "cpm-main", "cpm-sd-mmc", "none", "none", "cpm-slow-io",
"cpm-usb3h0", "cpm-usb3h1", "cpm-usb3dev", "cpm-eip150", "cpm-eip197";
Example:
cpm_syscon0: system-controller@440000 {
compatible = "marvell,cp110-system-controller0", "syscon";
reg = <0x440000 0x1000>;
#clock-cells = <2>;
core-clock-output-names = "cpm-apll", "cpm-ppv2-core", "cpm-eip", "cpm-core", "cpm-nand-core";
gate-clock-output-names = "cpm-audio", "cpm-communit", "cpm-nand", "cpm-ppv2", "cpm-sdio",
"cpm-mg-domain", "cpm-mg-core", "cpm-xor1", "cpm-xor0", "cpm-gop-dp", "none",
"cpm-pcie_x10", "cpm-pcie_x11", "cpm-pcie_x4", "cpm-pcie-xor", "cpm-sata",
"cpm-sata-usb", "cpm-main", "cpm-sd-mmc", "none", "none", "cpm-slow-io",
"cpm-usb3h0", "cpm-usb3h1", "cpm-usb3dev", "cpm-eip150", "cpm-eip197";
};

3
Documentation/devicetree/bindings/arm/omap/crossbar.txt
View File

@ -42,7 +42,8 @@ Examples:
Consumer:
========
See Documentation/devicetree/bindings/interrupt-controller/interrupts.txt and
Documentation/devicetree/bindings/arm/gic.txt for further details.
Documentation/devicetree/bindings/interrupt-controller/arm,gic.txt for
further details.
An interrupt consumer on an SoC using crossbar will use:
interrupts = <GIC_SPI request_number interrupt_level>

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

@ -133,6 +133,9 @@ Boards:
- AM335X Bone : Low cost community board
compatible = "ti,am335x-bone", "ti,am33xx", "ti,omap3"
- AM3359 ICEv2 : Low cost Industrial Communication Engine EVM.
compatible = "ti,am3359-icev2", "ti,am33xx", "ti,omap3"
- AM335X OrionLXm : Substation Automation Platform
compatible = "novatech,am335x-lxm", "ti,am33xx"
@ -169,6 +172,9 @@ Boards:
- AM57XX SBC-AM57x
compatible = "compulab,sbc-am57x", "compulab,cl-som-am57x", "ti,am5728", "ti,dra742", "ti,dra74", "ti,dra7"
- AM5728 IDK
compatible = "ti,am5728-idk", "ti,am5728", "ti,dra742", "ti,dra74", "ti,dra7"
- DRA742 EVM: Software Development Board for DRA742
compatible = "ti,dra7-evm", "ti,dra742", "ti,dra74", "ti,dra7"

9
Documentation/devicetree/bindings/arm/oxnas.txt Normal file
View File

@ -0,0 +1,9 @@
Oxford Semiconductor OXNAS SoCs Family device tree bindings
-------------------------------------------
Boards with the OX810SE SoC shall have the following properties:
Required root node property:
compatible: "oxsemi,ox810se"
Board compatible values:
- "wd,mbwe" (OX810SE)

14
Documentation/devicetree/bindings/arm/rockchip.txt
View File

@ -39,6 +39,10 @@ Rockchip platforms device tree bindings
Required root node properties:
- compatible = "netxeon,r89", "rockchip,rk3288";
- GeekBuying GeekBox:
Required root node properties:
- compatible = "geekbuying,geekbox", "rockchip,rk3368";
- Google Brain (dev-board):
Required root node properties:
- compatible = "google,veyron-brain-rev0", "google,veyron-brain",
@ -87,6 +91,10 @@ Rockchip platforms device tree bindings
"google,veyron-speedy-rev3", "google,veyron-speedy-rev2",
"google,veyron-speedy", "google,veyron", "rockchip,rk3288";
- mqmaker MiQi:
Required root node properties:
- compatible = "mqmaker,miqi", "rockchip,rk3288";
- Rockchip RK3368 evb:
Required root node properties:
- compatible = "rockchip,rk3368-evb-act8846", "rockchip,rk3368";
@ -97,4 +105,8 @@ Rockchip platforms device tree bindings
- Rockchip RK3228 Evaluation board:
Required root node properties:
- compatible = "rockchip,rk3228-evb", "rockchip,rk3228";
- compatible = "rockchip,rk3228-evb", "rockchip,rk3228";
- Rockchip RK3399 evb:
Required root node properties:
- compatible = "rockchip,rk3399-evb", "rockchip,rk3399";

2
Documentation/devicetree/bindings/arm/samsung/samsung-boards.txt
View File

@ -2,6 +2,8 @@
Required root node properties:
- compatible = should be one or more of the following.
- "samsung,artik5" - for Exynos3250-based Samsung ARTIK5 module.
- "samsung,artik5-eval" - for Exynos3250-based Samsung ARTIK5 eval board.
- "samsung,monk" - for Exynos3250-based Samsung Simband board.
- "samsung,rinato" - for Exynos3250-based Samsung Gear2 board.
- "samsung,smdkv310" - for Exynos4210-based Samsung SMDKV310 eval board.

2
Documentation/devicetree/bindings/arm/spear-misc.txt
View File

@ -6,4 +6,4 @@ few properties of different peripheral controllers.
misc node required properties:
- compatible Should be "st,spear1340-misc", "syscon".
- reg: Address range of misc space upto 8K
- reg: Address range of misc space up to 8K

92
Documentation/devicetree/bindings/arm/tegra/nvidia,tegra20-pmc.txt
View File

@ -1,16 +1,20 @@
NVIDIA Tegra Power Management Controller (PMC)
== Power Management Controller Node ==
The PMC block interacts with an external Power Management Unit. The PMC
mostly controls the entry and exit of the system from different sleep
modes. It provides power-gating controllers for SoC and CPU power-islands.
Required properties:
- name : Should be pmc
- compatible : For Tegra20, must contain "nvidia,tegra20-pmc". For Tegra30,
must contain "nvidia,tegra30-pmc". For Tegra114, must contain
"nvidia,tegra114-pmc". For Tegra124, must contain "nvidia,tegra124-pmc".
Otherwise, must contain "nvidia,<chip>-pmc", plus at least one of the
above, where <chip> is tegra132.
- compatible : Should contain one of the following:
For Tegra20 must contain "nvidia,tegra20-pmc".
For Tegra30 must contain "nvidia,tegra30-pmc".
For Tegra114 must contain "nvidia,tegra114-pmc"
For Tegra124 must contain "nvidia,tegra124-pmc"
For Tegra132 must contain "nvidia,tegra124-pmc"
For Tegra210 must contain "nvidia,tegra210-pmc"
- reg : Offset and length of the register set for the device
- clocks : Must contain an entry for each entry in clock-names.
See ../clocks/clock-bindings.txt for details.
@ -68,6 +72,11 @@ Optional properties for hardware-triggered thermal reset (inside 'i2c-thermtrip'
Defaults to 0. Valid values are described in section 12.5.2
"Pinmux Support" of the Tegra4 Technical Reference Manual.
Optional nodes:
- powergates : This node contains a hierarchy of power domain nodes, which
should match the powergates on the Tegra SoC. See "Powergate
Nodes" below.
Example:
/ SoC dts including file
@ -113,3 +122,76 @@ pmc@7000f400 {
};
...
};
== Powergate Nodes ==
Each of the powergate nodes represents a power-domain on the Tegra SoC
that can be power-gated by the Tegra PMC. The name of the powergate node
should be one of the below. Note that not every powergate is applicable
to all Tegra devices and the following list shows which powergates are
applicable to which devices. Please refer to the Tegra TRM for more
details on the various powergates.
Name Description Devices Applicable
3d 3D Graphics Tegra20/114/124/210
3d0 3D Graphics 0 Tegra30
3d1 3D Graphics 1 Tegra30
aud Audio Tegra210
dfd Debug Tegra210
dis Display A Tegra114/124/210
disb Display B Tegra114/124/210
heg 2D Graphics Tegra30/114/124/210
iram Internal RAM Tegra124/210
mpe MPEG Encode All
nvdec NVIDIA Video Decode Engine Tegra210
nvjpg NVIDIA JPEG Engine Tegra210
pcie PCIE Tegra20/30/124/210
sata SATA Tegra30/124/210
sor Display interfaces Tegra124/210
ve2 Video Encode Engine 2 Tegra210
venc Video Encode Engine All
vdec Video Decode Engine Tegra20/30/114/124
vic Video Imaging Compositor Tegra124/210
xusba USB Partition A Tegra114/124/210
xusbb USB Partition B Tegra114/124/210
xusbc USB Partition C Tegra114/124/210
Required properties:
- clocks: Must contain an entry for each clock required by the PMC for
controlling a power-gate. See ../clocks/clock-bindings.txt for details.
- resets: Must contain an entry for each reset required by the PMC for
controlling a power-gate. See ../reset/reset.txt for details.
- #power-domain-cells: Must be 0.
Example:
pmc: pmc@7000e400 {
compatible = "nvidia,tegra210-pmc";
reg = <0x0 0x7000e400 0x0 0x400>;
clocks = <&tegra_car TEGRA210_CLK_PCLK>, <&clk32k_in>;
clock-names = "pclk", "clk32k_in";
powergates {
pd_audio: aud {
clocks = <&tegra_car TEGRA210_CLK_APE>,
<&tegra_car TEGRA210_CLK_APB2APE>;
resets = <&tegra_car 198>;
#power-domain-cells = <0>;
};
};
};
== Powergate Clients ==
Hardware blocks belonging to a power domain should contain a "power-domains"
property that is a phandle pointing to the corresponding powergate node.
Example:
adma: adma@702e2000 {
...
power-domains = <&pd_audio>;
...
};

2
Documentation/devicetree/bindings/arm/ux500/boards.txt
View File

@ -23,7 +23,7 @@ scu:
see binding for arm/scu.txt
interrupt-controller:
see binding for arm/gic.txt
see binding for interrupt-controller/arm,gic.txt
timer:
see binding for arm/twd.txt

0
Documentation/devicetree/bindings/ata/tegra-sata.txt → Documentation/devicetree/bindings/ata/nvidia,tegra124-ahci.txt
View File

41
Documentation/devicetree/bindings/clock/artpec6.txt Normal file
View File

@ -0,0 +1,41 @@
* Clock bindings for Axis ARTPEC-6 chip
The bindings are based on the clock provider binding in
Documentation/devicetree/bindings/clock/clock-bindings.txt
External clocks:
----------------
There are two external inputs to the main clock controller which should be
provided using the common clock bindings.
- "sys_refclk": External 50 Mhz oscillator (required)
- "i2s_refclk": Alternate audio reference clock (optional).
Main clock controller
---------------------
Required properties:
- #clock-cells: Should be <1>
See dt-bindings/clock/axis,artpec6-clkctrl.h for the list of valid identifiers.
- compatible: Should be "axis,artpec6-clkctrl"
- reg: Must contain the base address and length of the system controller
- clocks: Must contain a phandle entry for each clock in clock-names
- clock-names: Must include the external oscillator ("sys_refclk"). Optional
ones are the audio reference clock ("i2s_refclk") and the audio fractional
dividers ("frac_clk0" and "frac_clk1").
Examples:
ext_clk: ext_clk {
#clock-cells = <0>;
compatible = "fixed-clock";
clock-frequency = <50000000>;
};
clkctrl: clkctrl@f8000000 {
#clock-cells = <1>;
compatible = "axis,artpec6-clkctrl";
reg = <0xf8000000 0x48>;
clocks = <&ext_clk>;
clock-names = "sys_refclk";
};

25
Documentation/devicetree/bindings/clock/axs10x-i2s-pll-clock.txt Normal file
View File

@ -0,0 +1,25 @@
Binding for the AXS10X I2S PLL clock
This binding uses the common clock binding[1].
[1] Documentation/devicetree/bindings/clock/clock-bindings.txt
Required properties:
- compatible: shall be "snps,axs10x-i2s-pll-clock"
- reg : address and length of the I2S PLL register set.
- clocks: shall be the input parent clock phandle for the PLL.
- #clock-cells: from common clock binding; Should always be set to 0.
Example:
pll_clock: pll_clock {
compatible = "fixed-clock";
clock-frequency = <27000000>;
#clock-cells = <0>;
};
i2s_clock@100a0 {
compatible = "snps,axs10x-i2s-pll-clock";
reg = <0x100a0 0x10>;
clocks = <&pll_clock>;
#clock-cells = <0>;
};

46
Documentation/devicetree/bindings/clock/hi3519-crg.txt Normal file
View File

@ -0,0 +1,46 @@
* Hisilicon Hi3519 Clock and Reset Generator(CRG)
The Hi3519 CRG module provides clock and reset signals to various
controllers within the SoC.
This binding uses the following bindings:
Documentation/devicetree/bindings/clock/clock-bindings.txt
Documentation/devicetree/bindings/reset/reset.txt
Required Properties:
- compatible: should be one of the following.
- "hisilicon,hi3519-crg" - controller compatible with Hi3519 SoC.
- reg: physical base address of the controller and length of memory mapped
region.
- #clock-cells: should be 1.
Each clock is assigned an identifier and client nodes use this identifier
to specify the clock which they consume.
All these identifier could be found in <dt-bindings/clock/hi3519-clock.h>.
- #reset-cells: should be 2.
A reset signal can be controlled by writing a bit register in the CRG module.
The reset specifier consists of two cells. The first cell represents the
register offset relative to the base address. The second cell represents the
bit index in the register.
Example: CRG nodes
CRG: clock-reset-controller@12010000 {
compatible = "hisilicon,hi3519-crg";
reg = <0x12010000 0x10000>;
#clock-cells = <1>;
#reset-cells = <2>;
};
Example: consumer nodes
i2c0: i2c@12110000 {
compatible = "hisilicon,hi3519-i2c";
reg = <0x12110000 0x1000>;
clocks = <&CRG HI3519_I2C0_RST>;
resets = <&CRG 0xe4 0>;
};

1
Documentation/devicetree/bindings/clock/imx35-clock.txt
View File

@ -94,6 +94,7 @@ clocks and IDs.
csi_sel 79
iim_gate 80
gpu2d_gate 81
ckli_gate 82
Examples:

39
Documentation/devicetree/bindings/clock/microchip,pic32.txt Normal file
View File

@ -0,0 +1,39 @@
Microchip PIC32 Clock Controller Binding
----------------------------------------
Microchip clock controller is consists of few oscillators, PLL, multiplexer
and few divider modules.
This binding uses common clock bindings.
[1] Documentation/devicetree/bindings/clock/clock-bindings.txt
Required properties:
- compatible: shall be "microchip,pic32mzda-clk".
- reg: shall contain base address and length of clock registers.
- #clock-cells: shall be 1.
Optional properties:
- microchip,pic32mzda-sosc: shall be added only if platform has
secondary oscillator connected.
Example:
rootclk: clock-controller@1f801200 {
compatible = "microchip,pic32mzda-clk";
reg = <0x1f801200 0x200>;
#clock-cells = <1>;
/* optional */
microchip,pic32mzda-sosc;
};
The clock consumer shall specify the desired clock-output of the clock
controller (as defined in [2]) by specifying output-id in its "clock"
phandle cell.
[2] include/dt-bindings/clock/microchip,pic32-clock.h
For example for UART2:
uart2: serial@2 {
compatible = "microchip,pic32mzda-uart";
reg = <>;
interrupts = <>;
clocks = <&rootclk PB2CLK>;
};

2
Documentation/devicetree/bindings/clock/nvidia,tegra124-dfll.txt
View File

@ -50,7 +50,7 @@ Required properties for I2C mode:
Example:
clock@0,70110000 {
clock@70110000 {
compatible = "nvidia,tegra124-dfll";
reg = <0 0x70110000 0 0x100>, /* DFLL control */
<0 0x70110000 0 0x100>, /* I2C output control */

35
Documentation/devicetree/bindings/clock/oxnas,stdclk.txt Normal file
View File

@ -0,0 +1,35 @@
Oxford Semiconductor OXNAS SoC Family Standard Clocks
================================================
Please also refer to clock-bindings.txt in this directory for common clock
bindings usage.
Required properties:
- compatible: Should be "oxsemi,ox810se-stdclk"
- #clock-cells: 1, see below
Parent node should have the following properties :
- compatible: Should be "oxsemi,ox810se-sys-ctrl", "syscon", "simple-mfd"
For OX810SE, the clock indices are :
- 0: LEON
- 1: DMA_SGDMA
- 2: CIPHER
- 3: SATA
- 4: AUDIO
- 5: USBMPH
- 6: ETHA
- 7: PCIA
- 8: NAND
example:
sys: sys-ctrl@000000 {
compatible = "oxsemi,ox810se-sys-ctrl", "syscon", "simple-mfd";
reg = <0x000000 0x100000>;
stdclk: stdclk {
compatible = "oxsemi,ox810se-stdclk";
#clock-cells = <1>;
};
};

2
Documentation/devicetree/bindings/clock/rockchip,rk3188-cru.txt
View File

@ -16,7 +16,7 @@ Required Properties:
Optional Properties:
- rockchip,grf: phandle to the syscon managing the "general register files"
If missing pll rates are not changable, due to the missing pll lock status.
If missing pll rates are not changeable, due to the missing pll lock status.
Each clock is assigned an identifier and client nodes can use this identifier
to specify the clock which they consume. All available clocks are defined as

2
Documentation/devicetree/bindings/clock/rockchip,rk3288-cru.txt
View File

@ -15,7 +15,7 @@ Required Properties:
Optional Properties:
- rockchip,grf: phandle to the syscon managing the "general register files"
If missing pll rates are not changable, due to the missing pll lock status.
If missing pll rates are not changeable, due to the missing pll lock status.
Each clock is assigned an identifier and client nodes can use this identifier
to specify the clock which they consume. All available clocks are defined as

62
Documentation/devicetree/bindings/clock/rockchip,rk3399-cru.txt Normal file
View File

@ -0,0 +1,62 @@
* Rockchip RK3399 Clock and Reset Unit
The RK3399 clock controller generates and supplies clock to various
controllers within the SoC and also implements a reset controller for SoC
peripherals.
Required Properties:
- compatible: PMU for CRU should be "rockchip,rk3399-pmucru"
- compatible: CRU should be "rockchip,rk3399-cru"
- reg: physical base address of the controller and length of memory mapped
region.
- #clock-cells: should be 1.
- #reset-cells: should be 1.
Each clock is assigned an identifier and client nodes can use this identifier
to specify the clock which they consume. All available clocks are defined as
preprocessor macros in the dt-bindings/clock/rk3399-cru.h headers and can be
used in device tree sources. Similar macros exist for the reset sources in
these files.
External clocks:
There are several clocks that are generated outside the SoC. It is expected
that they are defined using standard clock bindings with following
clock-output-names:
- "xin24m" - crystal input - required,
- "xin32k" - rtc clock - optional,
- "clkin_gmac" - external GMAC clock - optional,
- "clkin_i2s" - external I2S clock - optional,
- "pclkin_cif" - external ISP clock - optional,
- "clk_usbphy0_480m" - output clock of the pll in the usbphy0
- "clk_usbphy1_480m" - output clock of the pll in the usbphy1
Example: Clock controller node:
pmucru: pmu-clock-controller@ff750000 {
compatible = "rockchip,rk3399-pmucru";
reg = <0x0 0xff750000 0x0 0x1000>;
#clock-cells = <1>;
#reset-cells = <1>;
};
cru: clock-controller@ff760000 {
compatible = "rockchip,rk3399-cru";
reg = <0x0 0xff760000 0x0 0x1000>;
#clock-cells = <1>;
#reset-cells = <1>;
};
Example: UART controller node that consumes the clock generated by the clock
controller:
uart0: serial@ff1a0000 {
compatible = "rockchip,rk3399-uart", "snps,dw-apb-uart";
reg = <0x0 0xff180000 0x0 0x100>;
clocks = <&cru SCLK_UART0>, <&cru PCLK_UART0>;
clock-names = "baudclk", "apb_pclk";
interrupts = <GIC_SPI 99 IRQ_TYPE_LEVEL_HIGH>;
reg-shift = <2>;
reg-io-width = <4>;
};

2
Documentation/devicetree/bindings/clock/st/st,clkgen.txt
View File

@ -40,7 +40,7 @@ address is common of all subnode.
};
This binding uses the common clock binding[1].
Each subnode should use the binding discribe in [2]..[7]
Each subnode should use the binding described in [2]..[7]
[1] Documentation/devicetree/bindings/clock/clock-bindings.txt
[2] Documentation/devicetree/bindings/clock/st,clkgen-divmux.txt

6
Documentation/devicetree/bindings/clock/sunxi.txt
View File

@ -10,6 +10,7 @@ Required properties:
"allwinner,sun4i-a10-pll1-clk" - for the main PLL clock and PLL4
"allwinner,sun6i-a31-pll1-clk" - for the main PLL clock on A31
"allwinner,sun8i-a23-pll1-clk" - for the main PLL clock on A23
"allwinner,sun4i-a10-pll3-clk" - for the video PLL clock on A10
"allwinner,sun9i-a80-pll4-clk" - for the peripheral PLLs on A80
"allwinner,sun4i-a10-pll5-clk" - for the PLL5 clock
"allwinner,sun4i-a10-pll6-clk" - for the PLL6 clock
@ -63,7 +64,9 @@ Required properties:
"allwinner,sun8i-a83t-bus-gates-clk" - for the bus gates on A83T
"allwinner,sun8i-h3-bus-gates-clk" - for the bus gates on H3
"allwinner,sun9i-a80-apbs-gates-clk" - for the APBS gates on A80
"allwinner,sun4i-a10-display-clk" - for the display clocks on the A10
"allwinner,sun4i-a10-dram-gates-clk" - for the DRAM gates on A10
"allwinner,sun5i-a13-dram-gates-clk" - for the DRAM gates on A13
"allwinner,sun5i-a13-mbus-clk" - for the MBUS clock on A13
"allwinner,sun4i-a10-mmc-clk" - for the MMC clock
"allwinner,sun9i-a80-mmc-clk" - for mmc module clocks on A80
@ -73,6 +76,8 @@ Required properties:
"allwinner,sun8i-a23-mbus-clk" - for the MBUS clock on A23
"allwinner,sun7i-a20-out-clk" - for the external output clocks
"allwinner,sun7i-a20-gmac-clk" - for the GMAC clock module on A20/A31
"allwinner,sun4i-a10-tcon-ch0-clk" - for the TCON channel 0 clock on the A10
"allwinner,sun4i-a10-tcon-ch1-clk" - for the TCON channel 1 clock on the A10
"allwinner,sun4i-a10-usb-clk" - for usb gates + resets on A10 / A20
"allwinner,sun5i-a13-usb-clk" - for usb gates + resets on A13
"allwinner,sun6i-a31-usb-clk" - for usb gates + resets on A31
@ -81,6 +86,7 @@ Required properties:
"allwinner,sun9i-a80-usb-mod-clk" - for usb gates + resets on A80
"allwinner,sun9i-a80-usb-phy-clk" - for usb phy gates + resets on A80
"allwinner,sun4i-a10-ve-clk" - for the Video Engine clock
"allwinner,sun6i-a31-display-clk" - for the display clocks
Required properties for all clocks:
- reg : shall be the control register address for the clock.

0
Documentation/devicetree/bindings/cpufreq/tegra124-cpufreq.txt → Documentation/devicetree/bindings/cpufreq/nvidia,tegra124-cpufreq.txt
View File

36
Documentation/devicetree/bindings/display/brcm,bcm-vc4.txt
View File

@ -35,12 +35,22 @@ Optional properties for HDMI:
as an interrupt/status bit in the HDMI controller
itself). See bindings/pinctrl/brcm,bcm2835-gpio.txt
Required properties for DPI:
- compatible: Should be "brcm,bcm2835-dpi"
- reg: Physical base address and length of the registers
- clocks: a) core: The core clock the unit runs on
b) pixel: The pixel clock that feeds the pixelvalve
- port: Port node with a single endpoint connecting to the panel
device, as defined in [1]
Required properties for V3D:
- compatible: Should be "brcm,bcm2835-v3d"
- reg: Physical base address and length of the V3D's registers
- interrupts: The interrupt number
See bindings/interrupt-controller/brcm,bcm2835-armctrl-ic.txt
[1] Documentation/devicetree/bindings/media/video-interfaces.txt
Example:
pixelvalve@7e807000 {
compatible = "brcm,bcm2835-pixelvalve2";
@ -66,6 +76,22 @@ hdmi: hdmi@7e902000 {
clock-names = "pixel", "hdmi";
};
dpi: dpi@7e208000 {
compatible = "brcm,bcm2835-dpi";
reg = <0x7e208000 0x8c>;
clocks = <&clocks BCM2835_CLOCK_VPU>,
<&clocks BCM2835_CLOCK_DPI>;
clock-names = "core", "pixel";
#address-cells = <1>;
#size-cells = <0>;
port {
dpi_out: endpoint@0 {
remote-endpoint = <&panel_in>;
};
};
};
v3d: v3d@7ec00000 {
compatible = "brcm,bcm2835-v3d";
reg = <0x7ec00000 0x1000>;
@ -75,3 +101,13 @@ v3d: v3d@7ec00000 {
vc4: gpu {
compatible = "brcm,bcm2835-vc4";
};
panel: panel {
compatible = "ontat,yx700wv03", "simple-panel";
port {
panel_in: endpoint {
remote-endpoint = <&dpi_out>;
};
};
};

52
Documentation/devicetree/bindings/display/bridge/analogix_dp.txt Normal file
View File

@ -0,0 +1,52 @@
Analogix Display Port bridge bindings
Required properties for dp-controller:
-compatible:
platform specific such as:
* "samsung,exynos5-dp"
* "rockchip,rk3288-dp"
-reg:
physical base address of the controller and length
of memory mapped region.
-interrupts:
interrupt combiner values.
-clocks:
from common clock binding: handle to dp clock.
-clock-names:
from common clock binding: Shall be "dp".
-interrupt-parent:
phandle to Interrupt combiner node.
-phys:
from general PHY binding: the phandle for the PHY device.
-phy-names:
from general PHY binding: Should be "dp".
Optional properties for dp-controller:
-force-hpd:
Indicate driver need force hpd when hpd detect failed, this
is used for some eDP screen which don't have hpd signal.
-hpd-gpios:
Hotplug detect GPIO.
Indicates which GPIO should be used for hotplug detection
-port@[X]: SoC specific port nodes with endpoint definitions as defined
in Documentation/devicetree/bindings/media/video-interfaces.txt,
please refer to the SoC specific binding document:
* Documentation/devicetree/bindings/display/exynos/exynos_dp.txt
* Documentation/devicetree/bindings/video/analogix_dp-rockchip.txt
[1]: Documentation/devicetree/bindings/media/video-interfaces.txt
-------------------------------------------------------------------------------
Example:
dp-controller {
compatible = "samsung,exynos5-dp";
reg = <0x145b0000 0x10000>;
interrupts = <10 3>;
interrupt-parent = <&combiner>;
clocks = <&clock 342>;
clock-names = "dp";
phys = <&dp_phy>;
phy-names = "dp";
};

5
Documentation/devicetree/bindings/display/exynos/exynos5433-decon.txt
View File

@ -5,7 +5,8 @@ Exynos series of SoCs which transfers the image data from a video memory
buffer to an external LCD interface.
Required properties:
- compatible: value should be "samsung,exynos5433-decon";
- compatible: value should be one of:
"samsung,exynos5433-decon", "samsung,exynos5433-decon-tv";
- reg: physical base address and length of the DECON registers set.
- interrupts: should contain a list of all DECON IP block interrupts in the
order: VSYNC, LCD_SYSTEM. The interrupt specifier format
@ -16,7 +17,7 @@ Required properties:
- clocks: must include clock specifiers corresponding to entries in the
clock-names property.
- clock-names: list of clock names sorted in the same order as the clocks
property. Must contain "aclk_decon", "aclk_smmu_decon0x",
property. Must contain "pclk", "aclk_decon", "aclk_smmu_decon0x",
"aclk_xiu_decon0x", "pclk_smmu_decon0x", clk_decon_vclk",
"sclk_decon_eclk"
- ports: contains a port which is connected to mic node. address-cells and

89
Documentation/devicetree/bindings/display/exynos/exynos_dp.txt
View File

@ -1,20 +1,3 @@
Device-Tree bindings for Samsung Exynos Embedded DisplayPort Transmitter(eDP)
DisplayPort is industry standard to accommodate the growing board adoption
of digital display technology within the PC and CE industries.
It consolidates the internal and external connection methods to reduce device
complexity and cost. It also supports necessary features for important cross
industry applications and provides performance scalability to enable the next
generation of displays that feature higher color depths, refresh rates, and
display resolutions.
eDP (embedded display port) device is compliant with Embedded DisplayPort
standard as follows,
- DisplayPort standard 1.1a for Exynos5250 and Exynos5260.
- DisplayPort standard 1.3 for Exynos5422s and Exynos5800.
eDP resides between FIMD and panel or FIMD and bridge such as LVDS.
The Exynos display port interface should be configured based on
the type of panel connected to it.
@ -48,26 +31,6 @@ Required properties for dp-controller:
from general PHY binding: the phandle for the PHY device.
-phy-names:
from general PHY binding: Should be "dp".
-samsung,color-space:
input video data format.
COLOR_RGB = 0, COLOR_YCBCR422 = 1, COLOR_YCBCR444 = 2
-samsung,dynamic-range:
dynamic range for input video data.
VESA = 0, CEA = 1
-samsung,ycbcr-coeff:
YCbCr co-efficients for input video.
COLOR_YCBCR601 = 0, COLOR_YCBCR709 = 1
-samsung,color-depth:
number of bits per colour component.
COLOR_6 = 0, COLOR_8 = 1, COLOR_10 = 2, COLOR_12 = 3
-samsung,link-rate:
link rate supported by the panel.
LINK_RATE_1_62GBPS = 0x6, LINK_RATE_2_70GBPS = 0x0A
-samsung,lane-count:
number of lanes supported by the panel.
LANE_COUNT1 = 1, LANE_COUNT2 = 2, LANE_COUNT4 = 4
- display-timings: timings for the connected panel as described by
Documentation/devicetree/bindings/display/display-timing.txt
Optional properties for dp-controller:
-interlaced:
@ -83,17 +46,31 @@ Optional properties for dp-controller:
Hotplug detect GPIO.
Indicates which GPIO should be used for hotplug
detection
Video interfaces:
Device node can contain video interface port nodes according to [1].
The following are properties specific to those nodes:
-video interfaces: Device node can contain video interface port
nodes according to [1].
- display-timings: timings for the connected panel as described by
Documentation/devicetree/bindings/display/panel/display-timing.txt
endpoint node connected to bridge or panel node:
- remote-endpoint: specifies the endpoint in panel or bridge node.
This node is required in all kinds of exynos dp
to represent the connection between dp and bridge
or dp and panel.
For the below properties, please refer to Analogix DP binding document:
* Documentation/devicetree/bindings/display/bridge/analogix_dp.txt
-phys (required)
-phy-names (required)
-hpd-gpios (optional)
force-hpd (optional)
[1]: Documentation/devicetree/bindings/media/video-interfaces.txt
Deprecated properties for DisplayPort:
-interlaced: deprecated prop that can parsed from drm_display_mode.
-vsync-active-high: deprecated prop that can parsed from drm_display_mode.
-hsync-active-high: deprecated prop that can parsed from drm_display_mode.
-samsung,ycbcr-coeff: deprecated prop that can parsed from drm_display_mode.
-samsung,dynamic-range: deprecated prop that can parsed from drm_display_mode.
-samsung,color-space: deprecated prop that can parsed from drm_display_info.
-samsung,color-depth: deprecated prop that can parsed from drm_display_info.
-samsung,link-rate: deprecated prop that can reading from monitor by dpcd method.
-samsung,lane-count: deprecated prop that can reading from monitor by dpcd method.
-samsung,hpd-gpio: deprecated name for hpd-gpios.
-------------------------------------------------------------------------------
Example:
@ -112,13 +89,6 @@ SOC specific portion:
Board Specific portion:
dp-controller {
samsung,color-space = <0>;
samsung,dynamic-range = <0>;
samsung,ycbcr-coeff = <0>;
samsung,color-depth = <1>;
samsung,link-rate = <0x0a>;
samsung,lane-count = <4>;
display-timings {
native-mode = <&lcd_timing>;
lcd_timing: 1366x768 {
@ -135,18 +105,9 @@ Board Specific portion:
};
ports {
port {
port@0 {
dp_out: endpoint {
remote-endpoint = <&dp_in>;
};
};
};
panel {
...
port {
dp_in: endpoint {
remote-endpoint = <&dp_out>;
remote-endpoint = <&bridge_in>;
};
};
};

2
Documentation/devicetree/bindings/display/exynos/exynos_dsim.txt
View File

@ -41,7 +41,7 @@ Video interfaces:
endpoint node connected from mic node (reg = 0):
- remote-endpoint: specifies the endpoint in mic node. This node is required
for Exynos5433 mipi dsi. So mic can access to panel node
thoughout this dsi node.
throughout this dsi node.
endpoint node connected to panel node (reg = 1):
- remote-endpoint: specifies the endpoint in panel node. This node is
required in all kinds of exynos mipi dsi to represent

27
Documentation/devicetree/bindings/display/exynos/exynos_hdmi.txt
View File

@ -5,6 +5,7 @@ Required properties:
1) "samsung,exynos4210-hdmi"
2) "samsung,exynos4212-hdmi"
3) "samsung,exynos5420-hdmi"
4) "samsung,exynos5433-hdmi"
- reg: physical base address of the hdmi and length of memory mapped
region.
- interrupts: interrupt number to the cpu.
@ -12,6 +13,11 @@ Required properties:
a) phandle of the gpio controller node.
b) pin number within the gpio controller.
c) optional flags and pull up/down.
- ddc: phandle to the hdmi ddc node
- phy: phandle to the hdmi phy node
- samsung,syscon-phandle: phandle for system controller node for PMU.
Required properties for Exynos 4210, 4212, 5420 and 5433:
- clocks: list of clock IDs from SoC clock driver.
a) hdmi: Gate of HDMI IP bus clock.
b) sclk_hdmi: Gate of HDMI special clock.
@ -25,9 +31,24 @@ Required properties:
sclk_pixel.
- clock-names: aliases as per driver requirements for above clock IDs:
"hdmi", "sclk_hdmi", "sclk_pixel", "sclk_hdmiphy" and "mout_hdmi".
- ddc: phandle to the hdmi ddc node
- phy: phandle to the hdmi phy node
- samsung,syscon-phandle: phandle for system controller node for PMU.
Required properties for Exynos 5433:
- clocks: list of clock specifiers according to common clock bindings.
a) hdmi_pclk: Gate of HDMI IP APB bus.
b) hdmi_i_pclk: Gate of HDMI-PHY IP APB bus.
d) i_tmds_clk: Gate of HDMI TMDS clock.
e) i_pixel_clk: Gate of HDMI pixel clock.
f) i_spdif_clk: Gate of HDMI SPDIF clock.
g) oscclk: Oscillator clock, used as parent of following *_user clocks
in case HDMI-PHY is not operational.
h) tmds_clko: TMDS clock generated by HDMI-PHY.
i) tmds_clko_user: MUX used to switch between oscclk and tmds_clko,
respectively if HDMI-PHY is off and operational.
j) pixel_clko: Pixel clock generated by HDMI-PHY.
k) pixel_clko_user: MUX used to switch between oscclk and pixel_clko,
respectively if HDMI-PHY is off and operational.
- clock-names: aliases for above clock specfiers.
- samsung,sysreg: handle to syscon used to control the system registers.
Example:

15
Documentation/devicetree/bindings/display/fsl,dcu.txt
View File

@ -6,17 +6,24 @@ Required properties:
* "fsl,vf610-dcu".
- reg: Address and length of the register set for dcu.
- clocks: From common clock binding: handle to dcu clock.
- clock-names: From common clock binding: Shall be "dcu".
- clocks: Handle to "dcu" and "pix" clock (in the order below)
This can be the same clock (e.g. LS1021a)
See ../clocks/clock-bindings.txt for details.
- clock-names: Should be "dcu" and "pix"
See ../clocks/clock-bindings.txt for details.
- big-endian Boolean property, LS1021A DCU registers are big-endian.
- fsl,panel: The phandle to panel node.
Optional properties:
- fsl,tcon: The phandle to the timing controller node.
Examples:
dcu: dcu@2ce0000 {
compatible = "fsl,ls1021a-dcu";
reg = <0x0 0x2ce0000 0x0 0x10000>;
clocks = <&platform_clk 0>;
clock-names = "dcu";
clocks = <&platform_clk 0>, <&platform_clk 0>;
clock-names = "dcu", "pix";
big-endian;
fsl,panel = <&panel>;
fsl,tcon = <&tcon>;
};

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