redonkable
/
remarkable-linux
1
0
Fork 0
Code Releases Activity

Merge branch 'jejb-fixes' into fixes

steinar/wifi_calib_4_9_kernel
James Bottomley 2016-07-06 07:25:55 -07:00
parent 5e7ff2ca7f 262e2bfd7d
commit ea1a25c334
5937 changed files with 295583 additions and 113221 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 100644
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 100644
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.

9
Documentation/ABI/testing/sysfs-platform-hidma 100644
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 100644
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>

40
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>

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/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>

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

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

@ -216,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>

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 ===-

2
Documentation/Makefile
View File

@ -1,3 +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 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 100644
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";

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

@ -151,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

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.

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 100644
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 100644
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>

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

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 100644
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 100644
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 100644
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 100644
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 100644
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 100644
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 100644
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>;
};

18
Documentation/devicetree/bindings/display/fsl,tcon.txt 100644
View File

@ -0,0 +1,18 @@
Device Tree bindings for Freescale TCON Driver
Required properties:
- compatible: Should be one of
* "fsl,vf610-tcon".
- reg: Address and length of the register set for tcon.
- clocks: From common clock binding: handle to tcon ipg clock.
- clock-names: From common clock binding: Shall be "ipg".
Examples:
timing-controller@4003d000 {
compatible = "fsl,vf610-tcon";
reg = <0x4003d000 0x1000>;
clocks = <&clks VF610_CLK_TCON0>;
clock-names = "ipg";
status = "okay";
};

72
Documentation/devicetree/bindings/display/hisilicon/dw-dsi.txt 100644
View File

@ -0,0 +1,72 @@
Device-Tree bindings for DesignWare DSI Host Controller v1.20a driver
A DSI Host Controller resides in the middle of display controller and external
HDMI converter or panel.
Required properties:
- compatible: value should be "hisilicon,hi6220-dsi".
- reg: physical base address and length of dsi controller's registers.
- clocks: contains APB clock phandle + clock-specifier pair.
- clock-names: should be "pclk".
- ports: contains DSI controller input and output sub port.
The input port connects to ADE output port with the reg value "0".
The output port with the reg value "1", it could connect to panel or
any other bridge endpoints.
See Documentation/devicetree/bindings/graph.txt for more device graph info.
A example of HiKey board hi6220 SoC and board specific DT entry:
Example:
SoC specific:
dsi: dsi@f4107800 {
compatible = "hisilicon,hi6220-dsi";
reg = <0x0 0xf4107800 0x0 0x100>;
clocks = <&media_ctrl HI6220_DSI_PCLK>;
clock-names = "pclk";
status = "disabled";
ports {
#address-cells = <1>;
#size-cells = <0>;
/* 0 for input port */
port@0 {
reg = <0>;
dsi_in: endpoint {
remote-endpoint = <&ade_out>;
};
};
};
};
Board specific:
&dsi {
status = "ok";
ports {
/* 1 for output port */
port@1 {
reg = <1>;
dsi_out0: endpoint@0 {
remote-endpoint = <&adv7533_in>;
};
};
};
};
&i2c2 {
...
adv7533: adv7533@39 {
...
port {
adv7533_in: endpoint {
remote-endpoint = <&dsi_out0>;
};
};
};
};

64
Documentation/devicetree/bindings/display/hisilicon/hisi-ade.txt 100644
View File

@ -0,0 +1,64 @@
Device-Tree bindings for hisilicon ADE display controller driver
ADE (Advanced Display Engine) is the display controller which grab image
data from memory, do composition, do post image processing, generate RGB
timing stream and transfer to DSI.
Required properties:
- compatible: value should be "hisilicon,hi6220-ade".
- reg: physical base address and length of the ADE controller's registers.
- hisilicon,noc-syscon: ADE NOC QoS syscon.
- resets: The ADE reset controller node.
- interrupt: the ldi vblank interrupt number used.
- clocks: a list of phandle + clock-specifier pairs, one for each entry
in clock-names.
- clock-names: should contain:
"clk_ade_core" for the ADE core clock.
"clk_codec_jpeg" for the media NOC QoS clock, which use the same clock with
jpeg codec.
"clk_ade_pix" for the ADE pixel clok.
- assigned-clocks: Should contain "clk_ade_core" and "clk_codec_jpeg" clocks'
phandle + clock-specifier pairs.
- assigned-clock-rates: clock rates, one for each entry in assigned-clocks.
The rate of "clk_ade_core" could be "360000000" or "180000000";
The rate of "clk_codec_jpeg" could be or less than "1440000000".
These rate values could be configured according to performance and power
consumption.
- port: the output port. This contains one endpoint subnode, with its
remote-endpoint set to the phandle of the connected DSI input endpoint.
See Documentation/devicetree/bindings/graph.txt for more device graph info.
Optional properties:
- dma-coherent: Present if dma operations are coherent.
A example of HiKey board hi6220 SoC specific DT entry:
Example:
ade: ade@f4100000 {
compatible = "hisilicon,hi6220-ade";
reg = <0x0 0xf4100000 0x0 0x7800>;
reg-names = "ade_base";
hisilicon,noc-syscon = <&medianoc_ade>;
resets = <&media_ctrl MEDIA_ADE>;
interrupts = <0 115 4>; /* ldi interrupt */
clocks = <&media_ctrl HI6220_ADE_CORE>,
<&media_ctrl HI6220_CODEC_JPEG>,
<&media_ctrl HI6220_ADE_PIX_SRC>;
/*clock name*/
clock-names = "clk_ade_core",
"clk_codec_jpeg",
"clk_ade_pix";
assigned-clocks = <&media_ctrl HI6220_ADE_CORE>,
<&media_ctrl HI6220_CODEC_JPEG>;
assigned-clock-rates = <360000000>, <288000000>;
dma-coherent;
port {
ade_out: endpoint {
remote-endpoint = <&dsi_in>;
};
};
};

1
Documentation/devicetree/bindings/display/imx/ldb.txt
View File

@ -62,6 +62,7 @@ Required properties:
display-timings are used instead.
Optional properties (required if display-timings are used):
- ddc-i2c-bus: phandle of an I2C controller used for DDC EDID probing
- display-timings : A node that describes the display timings as defined in
Documentation/devicetree/bindings/display/display-timing.txt.
- fsl,data-mapping : should be "spwg" or "jeida"

203
Documentation/devicetree/bindings/display/mediatek/mediatek,disp.txt 100644
View File

@ -0,0 +1,203 @@
Mediatek display subsystem
==========================
The Mediatek display subsystem consists of various DISP function blocks in the
MMSYS register space. The connections between them can be configured by output
and input selectors in the MMSYS_CONFIG register space. Pixel clock and start
of frame signal are distributed to the other function blocks by a DISP_MUTEX
function block.
All DISP device tree nodes must be siblings to the central MMSYS_CONFIG node.
For a description of the MMSYS_CONFIG binding, see
Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.txt.
DISP function blocks
====================
A display stream starts at a source function block that reads pixel data from
memory and ends with a sink function block that drives pixels on a display
interface, or writes pixels back to memory. All DISP function blocks have
their own register space, interrupt, and clock gate. The blocks that can
access memory additionally have to list the IOMMU and local arbiter they are
connected to.
For a description of the display interface sink function blocks, see
Documentation/devicetree/bindings/display/mediatek/mediatek,dsi.txt and
Documentation/devicetree/bindings/display/mediatek/mediatek,dpi.txt.
Required properties (all function blocks):
- compatible: "mediatek,<chip>-disp-<function>", one of
"mediatek,<chip>-disp-ovl" - overlay (4 layers, blending, csc)
"mediatek,<chip>-disp-rdma" - read DMA / line buffer
"mediatek,<chip>-disp-wdma" - write DMA
"mediatek,<chip>-disp-color" - color processor
"mediatek,<chip>-disp-aal" - adaptive ambient light controller
"mediatek,<chip>-disp-gamma" - gamma correction
"mediatek,<chip>-disp-merge" - merge streams from two RDMA sources
"mediatek,<chip>-disp-split" - split stream to two encoders
"mediatek,<chip>-disp-ufoe" - data compression engine
"mediatek,<chip>-dsi" - DSI controller, see mediatek,dsi.txt
"mediatek,<chip>-dpi" - DPI controller, see mediatek,dpi.txt
"mediatek,<chip>-disp-mutex" - display mutex
"mediatek,<chip>-disp-od" - overdrive
- reg: Physical base address and length of the function block register space
- interrupts: The interrupt signal from the function block (required, except for
merge and split function blocks).
- clocks: device clocks
See Documentation/devicetree/bindings/clock/clock-bindings.txt for details.
For most function blocks this is just a single clock input. Only the DSI and
DPI controller nodes have multiple clock inputs. These are documented in
mediatek,dsi.txt and mediatek,dpi.txt, respectively.
Required properties (DMA function blocks):
- compatible: Should be one of
"mediatek,<chip>-disp-ovl"
"mediatek,<chip>-disp-rdma"
"mediatek,<chip>-disp-wdma"
- larb: Should contain a phandle pointing to the local arbiter device as defined
in Documentation/devicetree/bindings/soc/mediatek/mediatek,smi-larb.txt
- iommus: Should point to the respective IOMMU block with master port as
argument, see Documentation/devicetree/bindings/iommu/mediatek,iommu.txt
for details.
Examples:
mmsys: clock-controller@14000000 {
compatible = "mediatek,mt8173-mmsys", "syscon";
reg = <0 0x14000000 0 0x1000>;
power-domains = <&scpsys MT8173_POWER_DOMAIN_MM>;
#clock-cells = <1>;
};
ovl0: ovl@1400c000 {
compatible = "mediatek,mt8173-disp-ovl";
reg = <0 0x1400c000 0 0x1000>;
interrupts = <GIC_SPI 180 IRQ_TYPE_LEVEL_LOW>;
power-domains = <&scpsys MT8173_POWER_DOMAIN_MM>;
clocks = <&mmsys CLK_MM_DISP_OVL0>;
iommus = <&iommu M4U_PORT_DISP_OVL0>;
mediatek,larb = <&larb0>;
};
ovl1: ovl@1400d000 {
compatible = "mediatek,mt8173-disp-ovl";
reg = <0 0x1400d000 0 0x1000>;
interrupts = <GIC_SPI 181 IRQ_TYPE_LEVEL_LOW>;
power-domains = <&scpsys MT8173_POWER_DOMAIN_MM>;
clocks = <&mmsys CLK_MM_DISP_OVL1>;
iommus = <&iommu M4U_PORT_DISP_OVL1>;
mediatek,larb = <&larb4>;
};
rdma0: rdma@1400e000 {
compatible = "mediatek,mt8173-disp-rdma";
reg = <0 0x1400e000 0 0x1000>;
interrupts = <GIC_SPI 182 IRQ_TYPE_LEVEL_LOW>;
power-domains = <&scpsys MT8173_POWER_DOMAIN_MM>;
clocks = <&mmsys CLK_MM_DISP_RDMA0>;
iommus = <&iommu M4U_PORT_DISP_RDMA0>;
mediatek,larb = <&larb0>;
};
rdma1: rdma@1400f000 {
compatible = "mediatek,mt8173-disp-rdma";
reg = <0 0x1400f000 0 0x1000>;
interrupts = <GIC_SPI 183 IRQ_TYPE_LEVEL_LOW>;
power-domains = <&scpsys MT8173_POWER_DOMAIN_MM>;
clocks = <&mmsys CLK_MM_DISP_RDMA1>;
iommus = <&iommu M4U_PORT_DISP_RDMA1>;
mediatek,larb = <&larb4>;
};
rdma2: rdma@14010000 {
compatible = "mediatek,mt8173-disp-rdma";
reg = <0 0x14010000 0 0x1000>;
interrupts = <GIC_SPI 184 IRQ_TYPE_LEVEL_LOW>;
power-domains = <&scpsys MT8173_POWER_DOMAIN_MM>;
clocks = <&mmsys CLK_MM_DISP_RDMA2>;
iommus = <&iommu M4U_PORT_DISP_RDMA2>;
mediatek,larb = <&larb4>;
};
wdma0: wdma@14011000 {
compatible = "mediatek,mt8173-disp-wdma";
reg = <0 0x14011000 0 0x1000>;
interrupts = <GIC_SPI 185 IRQ_TYPE_LEVEL_LOW>;
power-domains = <&scpsys MT8173_POWER_DOMAIN_MM>;
clocks = <&mmsys CLK_MM_DISP_WDMA0>;
iommus = <&iommu M4U_PORT_DISP_WDMA0>;
mediatek,larb = <&larb0>;
};
wdma1: wdma@14012000 {
compatible = "mediatek,mt8173-disp-wdma";
reg = <0 0x14012000 0 0x1000>;
interrupts = <GIC_SPI 186 IRQ_TYPE_LEVEL_LOW>;
power-domains = <&scpsys MT8173_POWER_DOMAIN_MM>;
clocks = <&mmsys CLK_MM_DISP_WDMA1>;
iommus = <&iommu M4U_PORT_DISP_WDMA1>;
mediatek,larb = <&larb4>;
};
color0: color@14013000 {
compatible = "mediatek,mt8173-disp-color";
reg = <0 0x14013000 0 0x1000>;
interrupts = <GIC_SPI 187 IRQ_TYPE_LEVEL_LOW>;
power-domains = <&scpsys MT8173_POWER_DOMAIN_MM>;
clocks = <&mmsys CLK_MM_DISP_COLOR0>;
};
color1: color@14014000 {
compatible = "mediatek,mt8173-disp-color";
reg = <0 0x14014000 0 0x1000>;
interrupts = <GIC_SPI 188 IRQ_TYPE_LEVEL_LOW>;
power-domains = <&scpsys MT8173_POWER_DOMAIN_MM>;
clocks = <&mmsys CLK_MM_DISP_COLOR1>;
};
aal@14015000 {
compatible = "mediatek,mt8173-disp-aal";
reg = <0 0x14015000 0 0x1000>;
interrupts = <GIC_SPI 189 IRQ_TYPE_LEVEL_LOW>;
power-domains = <&scpsys MT8173_POWER_DOMAIN_MM>;
clocks = <&mmsys CLK_MM_DISP_AAL>;
};
gamma@14016000 {
compatible = "mediatek,mt8173-disp-gamma";
reg = <0 0x14016000 0 0x1000>;
interrupts = <GIC_SPI 190 IRQ_TYPE_LEVEL_LOW>;
power-domains = <&scpsys MT8173_POWER_DOMAIN_MM>;
clocks = <&mmsys CLK_MM_DISP_GAMMA>;
};
ufoe@1401a000 {
compatible = "mediatek,mt8173-disp-ufoe";
reg = <0 0x1401a000 0 0x1000>;
interrupts = <GIC_SPI 191 IRQ_TYPE_LEVEL_LOW>;
power-domains = <&scpsys MT8173_POWER_DOMAIN_MM>;
clocks = <&mmsys CLK_MM_DISP_UFOE>;
};
dsi0: dsi@1401b000 {
/* See mediatek,dsi.txt for details */
};
dpi0: dpi@1401d000 {
/* See mediatek,dpi.txt for details */
};
mutex: mutex@14020000 {
compatible = "mediatek,mt8173-disp-mutex";
reg = <0 0x14020000 0 0x1000>;
interrupts = <GIC_SPI 169 IRQ_TYPE_LEVEL_LOW>;
power-domains = <&scpsys MT8173_POWER_DOMAIN_MM>;
clocks = <&mmsys CLK_MM_MUTEX_32K>;
};
od@14023000 {
compatible = "mediatek,mt8173-disp-od";
reg = <0 0x14023000 0 0x1000>;
power-domains = <&scpsys MT8173_POWER_DOMAIN_MM>;
clocks = <&mmsys CLK_MM_DISP_OD>;
};

35
Documentation/devicetree/bindings/display/mediatek/mediatek,dpi.txt 100644
View File

@ -0,0 +1,35 @@
Mediatek DPI Device
===================
The Mediatek DPI function block is a sink of the display subsystem and
provides 8-bit RGB/YUV444 or 8/10/10-bit YUV422 pixel data on a parallel
output bus.
Required properties:
- compatible: "mediatek,<chip>-dpi"
- reg: Physical base address and length of the controller's registers
- interrupts: The interrupt signal from the function block.
- clocks: device clocks
See Documentation/devicetree/bindings/clock/clock-bindings.txt for details.
- clock-names: must contain "pixel", "engine", and "pll"
- port: Output port node with endpoint definitions as described in
Documentation/devicetree/bindings/graph.txt. This port should be connected
to the input port of an attached HDMI or LVDS encoder chip.
Example:
dpi0: dpi@1401d000 {
compatible = "mediatek,mt8173-dpi";
reg = <0 0x1401d000 0 0x1000>;
interrupts = <GIC_SPI 194 IRQ_TYPE_LEVEL_LOW>;
clocks = <&mmsys CLK_MM_DPI_PIXEL>,
<&mmsys CLK_MM_DPI_ENGINE>,
<&apmixedsys CLK_APMIXED_TVDPLL>;
clock-names = "pixel", "engine", "pll";
port {
dpi0_out: endpoint {
remote-endpoint = <&hdmi0_in>;
};
};
};

60
Documentation/devicetree/bindings/display/mediatek/mediatek,dsi.txt 100644
View File

@ -0,0 +1,60 @@
Mediatek DSI Device
===================
The Mediatek DSI function block is a sink of the display subsystem and can
drive up to 4-lane MIPI DSI output. Two DSIs can be synchronized for dual-
channel output.
Required properties:
- compatible: "mediatek,<chip>-dsi"
- reg: Physical base address and length of the controller's registers
- interrupts: The interrupt signal from the function block.
- clocks: device clocks
See Documentation/devicetree/bindings/clock/clock-bindings.txt for details.
- clock-names: must contain "engine", "digital", and "hs"
- phys: phandle link to the MIPI D-PHY controller.
- phy-names: must contain "dphy"
- port: Output port node with endpoint definitions as described in
Documentation/devicetree/bindings/graph.txt. This port should be connected
to the input port of an attached DSI panel or DSI-to-eDP encoder chip.
MIPI TX Configuration Module
============================
The MIPI TX configuration module controls the MIPI D-PHY.
Required properties:
- compatible: "mediatek,<chip>-mipi-tx"
- reg: Physical base address and length of the controller's registers
- clocks: PLL reference clock
- clock-output-names: name of the output clock line to the DSI encoder
- #clock-cells: must be <0>;
- #phy-cells: must be <0>.
Example:
mipi_tx0: mipi-dphy@10215000 {
compatible = "mediatek,mt8173-mipi-tx";
reg = <0 0x10215000 0 0x1000>;
clocks = <&clk26m>;
clock-output-names = "mipi_tx0_pll";
#clock-cells = <0>;
#phy-cells = <0>;
};
dsi0: dsi@1401b000 {
compatible = "mediatek,mt8173-dsi";
reg = <0 0x1401b000 0 0x1000>;
interrupts = <GIC_SPI 192 IRQ_TYPE_LEVEL_LOW>;
clocks = <&mmsys MM_DSI0_ENGINE>, <&mmsys MM_DSI0_DIGITAL>,
<&mipi_tx0>;
clock-names = "engine", "digital", "hs";
phys = <&mipi_tx0>;
phy-names = "dphy";
port {
dsi0_out: endpoint {
remote-endpoint = <&panel_in>;
};
};
};

7
Documentation/devicetree/bindings/display/panel/innolux,at070tn92.txt 100644
View File

@ -0,0 +1,7 @@
Innolux AT070TN92 7.0" WQVGA TFT LCD panel
Required properties:
- compatible: should be "innolux,at070tn92"
This binding is compatible with the simple-panel binding, which is specified
in simple-panel.txt in this directory.

7
Documentation/devicetree/bindings/display/panel/olimex,lcd-olinuxino-43-ts.txt 100644
View File

@ -0,0 +1,7 @@
Olimex 4.3" TFT LCD panel
Required properties:
- compatible: should be "olimex,lcd-olinuxino-43-ts"
This binding is compatible with the simple-panel binding, which is specified
in simple-panel.txt in this directory.

7
Documentation/devicetree/bindings/display/panel/ontat,yx700wv03.txt 100644
View File

@ -0,0 +1,7 @@
On Tat Industrial Company 7" DPI TFT panel.
Required properties:
- compatible: should be "ontat,yx700wv03"
This binding is compatible with the simple-panel binding, which is specified
in simple-panel.txt in this directory.

8
Documentation/devicetree/bindings/display/panel/tpk,f07a-0102.txt 100644
View File

@ -0,0 +1,8 @@
TPK U.S.A. LLC Fusion 7" integrated projected capacitive touch display with,
800 x 480 (WVGA) LCD panel.
Required properties:
- compatible: should be "tpk,f07a-0102"
This binding is compatible with the simple-panel binding, which is specified
in simple-panel.txt in this directory.

8
Documentation/devicetree/bindings/display/panel/tpk,f10a-0102.txt 100644
View File

@ -0,0 +1,8 @@
TPK U.S.A. LLC Fusion 10.1" integrated projected capacitive touch display with,
1024 x 600 (WSVGA) LCD panel.
Required properties:
- compatible: should be "tpk,f10a-0102"
This binding is compatible with the simple-panel binding, which is specified
in simple-panel.txt in this directory.

92
Documentation/devicetree/bindings/display/rockchip/analogix_dp-rockchip.txt 100644
View File

@ -0,0 +1,92 @@
Rockchip RK3288 specific extensions to the Analogix Display Port
================================
Required properties:
- compatible: "rockchip,rk3288-edp";
- reg: physical base address of the controller and length
- clocks: from common clock binding: handle to dp clock.
of memory mapped region.
- clock-names: from common clock binding:
Required elements: "dp" "pclk"
- resets: Must contain an entry for each entry in reset-names.
See ../reset/reset.txt for details.
- pinctrl-names: Names corresponding to the chip hotplug pinctrl states.
- pinctrl-0: pin-control mode. should be <&edp_hpd>
- reset-names: Must include the name "dp"
- rockchip,grf: this soc should set GRF regs, so need get grf here.
- ports: there are 2 port nodes with endpoint definitions as defined in
Documentation/devicetree/bindings/media/video-interfaces.txt.
Port 0: contained 2 endpoints, connecting to the output of vop.
Port 1: contained 1 endpoint, connecting to the input of panel.
For the below properties, please refer to Analogix DP binding document:
* Documentation/devicetree/bindings/drm/bridge/analogix_dp.txt
- phys (required)
- phy-names (required)
- hpd-gpios (optional)
- force-hpd (optional)
-------------------------------------------------------------------------------
Example:
dp-controller: dp@ff970000 {
compatible = "rockchip,rk3288-dp";
reg = <0xff970000 0x4000>;
interrupts = <GIC_SPI 98 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&cru SCLK_EDP>, <&cru PCLK_EDP_CTRL>;
clock-names = "dp", "pclk";
phys = <&dp_phy>;
phy-names = "dp";
rockchip,grf = <&grf>;
resets = <&cru 111>;
reset-names = "dp";
pinctrl-names = "default";
pinctrl-0 = <&edp_hpd>;
status = "disabled";
ports {
#address-cells = <1>;
#size-cells = <0>;
edp_in: port@0 {
reg = <0>;
#address-cells = <1>;
#size-cells = <0>;
edp_in_vopb: endpoint@0 {
reg = <0>;
remote-endpoint = <&vopb_out_edp>;
};
edp_in_vopl: endpoint@1 {
reg = <1>;
remote-endpoint = <&vopl_out_edp>;
};
};
edp_out: port@1 {
reg = <1>;
#address-cells = <1>;
#size-cells = <0>;
edp_out_panel: endpoint {
reg = <0>;
remote-endpoint = <&panel_in_edp>
};
};
};
};
pinctrl {
edp {
edp_hpd: edp-hpd {
rockchip,pins = <7 11 RK_FUNC_2 &pcfg_pull_none>;
};
};
};

35
Documentation/devicetree/bindings/display/snps,arcpgu.txt 100644
View File

@ -0,0 +1,35 @@
ARC PGU
This is a display controller found on several development boards produced
by Synopsys. The ARC PGU is an RGB streamer that reads the data from a
framebuffer and sends it to a single digital encoder (usually HDMI).
Required properties:
- compatible: "snps,arcpgu"
- reg: Physical base address and length of the controller's registers.
- clocks: A list of phandle + clock-specifier pairs, one for each
entry in 'clock-names'.
- clock-names: A list of clock names. For ARC PGU it should contain:
- "pxlclk" for the clock feeding the output PLL of the controller.
Required sub-nodes:
- port: The PGU connection to an encoder chip.
Example:
/ {
...
pgu@XXXXXXXX {
compatible = "snps,arcpgu";
reg = <0xXXXXXXXX 0x400>;
clocks = <&clock_node>;
clock-names = "pxlclk";
port {
pgu_output: endpoint {
remote-endpoint = <&hdmi_enc_input>;
};
};
};
};

258
Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt 100644
View File

@ -0,0 +1,258 @@
Allwinner A10 Display Pipeline
==============================
The Allwinner A10 Display pipeline is composed of several components
that are going to be documented below:
TV Encoder
----------
The TV Encoder supports the composite and VGA output. It is one end of
the pipeline.
Required properties:
- compatible: value should be "allwinner,sun4i-a10-tv-encoder".
- reg: base address and size of memory-mapped region
- clocks: the clocks driving the TV encoder
- resets: phandle to the reset controller driving the encoder
- ports: A ports node with endpoint definitions as defined in
Documentation/devicetree/bindings/media/video-interfaces.txt. The
first port should be the input endpoint.
TCON
----
The TCON acts as a timing controller for RGB, LVDS and TV interfaces.
Required properties:
- compatible: value should be "allwinner,sun5i-a13-tcon".
- reg: base address and size of memory-mapped region
- interrupts: interrupt associated to this IP
- clocks: phandles to the clocks feeding the TCON. Three are needed:
- 'ahb': the interface clocks
- 'tcon-ch0': The clock driving the TCON channel 0
- 'tcon-ch1': The clock driving the TCON channel 1
- resets: phandles to the reset controllers driving the encoder
- "lcd": the reset line for the TCON channel 0
- clock-names: the clock names mentioned above
- reset-names: the reset names mentioned above
- clock-output-names: Name of the pixel clock created
- ports: A ports node with endpoint definitions as defined in
Documentation/devicetree/bindings/media/video-interfaces.txt. The
first port should be the input endpoint, the second one the output
The output should have two endpoints. The first is the block
connected to the TCON channel 0 (usually a panel or a bridge), the
second the block connected to the TCON channel 1 (usually the TV
encoder)
Display Engine Backend
----------------------
The display engine backend exposes layers and sprites to the
system.
Required properties:
- compatible: value must be one of:
* allwinner,sun5i-a13-display-backend
- reg: base address and size of the memory-mapped region.
- clocks: phandles to the clocks feeding the frontend and backend
* ahb: the backend interface clock
* mod: the backend module clock
* ram: the backend DRAM clock
- clock-names: the clock names mentioned above
- resets: phandles to the reset controllers driving the backend
- ports: A ports node with endpoint definitions as defined in
Documentation/devicetree/bindings/media/video-interfaces.txt. The
first port should be the input endpoints, the second one the output
Display Engine Frontend
-----------------------
The display engine frontend does formats conversion, scaling,
deinterlacing and color space conversion.
Required properties:
- compatible: value must be one of:
* allwinner,sun5i-a13-display-frontend
- reg: base address and size of the memory-mapped region.
- interrupts: interrupt associated to this IP
- clocks: phandles to the clocks feeding the frontend and backend
* ahb: the backend interface clock
* mod: the backend module clock
* ram: the backend DRAM clock
- clock-names: the clock names mentioned above
- resets: phandles to the reset controllers driving the backend
- ports: A ports node with endpoint definitions as defined in
Documentation/devicetree/bindings/media/video-interfaces.txt. The
first port should be the input endpoints, the second one the outputs
Display Engine Pipeline
-----------------------
The display engine pipeline (and its entry point, since it can be
either directly the backend or the frontend) is represented as an
extra node.
Required properties:
- compatible: value must be one of:
* allwinner,sun5i-a13-display-engine
- allwinner,pipelines: list of phandle to the display engine
frontends available.
Example:
panel: panel {
compatible = "olimex,lcd-olinuxino-43-ts";
#address-cells = <1>;
#size-cells = <0>;
port {
#address-cells = <1>;
#size-cells = <0>;
panel_input: endpoint {
remote-endpoint = <&tcon0_out_panel>;
};
};
};
tve0: tv-encoder@01c0a000 {
compatible = "allwinner,sun4i-a10-tv-encoder";
reg = <0x01c0a000 0x1000>;
clocks = <&ahb_gates 34>;
resets = <&tcon_ch0_clk 0>;
port {
#address-cells = <1>;
#size-cells = <0>;
tve0_in_tcon0: endpoint@0 {
reg = <0>;
remote-endpoint = <&tcon0_out_tve0>;
};
};
};
tcon0: lcd-controller@1c0c000 {
compatible = "allwinner,sun5i-a13-tcon";
reg = <0x01c0c000 0x1000>;
interrupts = <44>;
resets = <&tcon_ch0_clk 1>;
reset-names = "lcd";
clocks = <&ahb_gates 36>,
<&tcon_ch0_clk>,
<&tcon_ch1_clk>;
clock-names = "ahb",
"tcon-ch0",
"tcon-ch1";
clock-output-names = "tcon-pixel-clock";
ports {
#address-cells = <1>;
#size-cells = <0>;
tcon0_in: port@0 {
#address-cells = <1>;
#size-cells = <0>;
reg = <0>;
tcon0_in_be0: endpoint@0 {
reg = <0>;
remote-endpoint = <&be0_out_tcon0>;
};
};
tcon0_out: port@1 {
#address-cells = <1>;
#size-cells = <0>;
reg = <1>;
tcon0_out_panel: endpoint@0 {
reg = <0>;
remote-endpoint = <&panel_input>;
};
tcon0_out_tve0: endpoint@1 {
reg = <1>;
remote-endpoint = <&tve0_in_tcon0>;
};
};
};
};
fe0: display-frontend@1e00000 {
compatible = "allwinner,sun5i-a13-display-frontend";
reg = <0x01e00000 0x20000>;
interrupts = <47>;
clocks = <&ahb_gates 46>, <&de_fe_clk>,
<&dram_gates 25>;
clock-names = "ahb", "mod",
"ram";
resets = <&de_fe_clk>;
ports {
#address-cells = <1>;
#size-cells = <0>;
fe0_out: port@1 {
#address-cells = <1>;
#size-cells = <0>;
reg = <1>;
fe0_out_be0: endpoint {
remote-endpoint = <&be0_in_fe0>;
};
};
};
};
be0: display-backend@1e60000 {
compatible = "allwinner,sun5i-a13-display-backend";
reg = <0x01e60000 0x10000>;
clocks = <&ahb_gates 44>, <&de_be_clk>,
<&dram_gates 26>;
clock-names = "ahb", "mod",
"ram";
resets = <&de_be_clk>;
ports {
#address-cells = <1>;
#size-cells = <0>;
be0_in: port@0 {
#address-cells = <1>;
#size-cells = <0>;
reg = <0>;
be0_in_fe0: endpoint@0 {
reg = <0>;
remote-endpoint = <&fe0_out_be0>;
};
};
be0_out: port@1 {
#address-cells = <1>;
#size-cells = <0>;
reg = <1>;
be0_out_tcon0: endpoint@0 {
reg = <0>;
remote-endpoint = <&tcon0_in_be0>;
};
};
};
};
display-engine {
compatible = "allwinner,sun5i-a13-display-engine";
allwinner,pipelines = <&fe0>;
};

26
Documentation/devicetree/bindings/dma/brcm,bcm2835-dma.txt
View File

@ -12,6 +12,10 @@ Required properties:
- reg: Should contain DMA registers location and length.
- interrupts: Should contain the DMA interrupts associated
to the DMA channels in ascending order.
- interrupt-names: Should contain the names of the interrupt
in the form "dmaXX".
Use "dma-shared-all" for the common interrupt line
that is shared by all dma channels.
- #dma-cells: Must be <1>, the cell in the dmas property of the
client device represents the DREQ number.
- brcm,dma-channel-mask: Bit mask representing the channels
@ -34,13 +38,35 @@ dma: dma@7e007000 {
<1 24>,
<1 25>,
<1 26>,
/* dma channel 11-14 share one irq */
<1 27>,
<1 27>,
<1 27>,
<1 27>,
/* unused shared irq for all channels */
<1 28>;
interrupt-names = "dma0",
"dma1",
"dma2",
"dma3",
"dma4",
"dma5",
"dma6",
"dma7",
"dma8",
"dma9",
"dma10",
"dma11",
"dma12",
"dma13",
"dma14",
"dma-shared-all";
#dma-cells = <1>;
brcm,dma-channel-mask = <0x7f35>;
};
DMA clients connected to the BCM2835 DMA controller must use the format
described in the dma.txt file, using a two-cell specifier for each channel.

5
Documentation/devicetree/bindings/dma/mv-xor.txt
View File

@ -1,7 +1,10 @@
* Marvell XOR engines
Required properties:
- compatible: Should be "marvell,orion-xor" or "marvell,armada-380-xor"
- compatible: Should be one of the following:
- "marvell,orion-xor"
- "marvell,armada-380-xor"
- "marvell,armada-3700-xor".
- reg: Should contain registers location and length (two sets)
the first set is the low registers, the second set the high
registers for the XOR engine.

0
Documentation/devicetree/bindings/dma/tegra20-apbdma.txt → Documentation/devicetree/bindings/dma/nvidia,tegra20-apbdma.txt
View File

55
Documentation/devicetree/bindings/dma/nvidia,tegra210-adma.txt 100644
View File

@ -0,0 +1,55 @@
* NVIDIA Tegra Audio DMA (ADMA) controller
The Tegra Audio DMA controller that is used for transferring data
between system memory and the Audio Processing Engine (APE).
Required properties:
- compatible: Must be "nvidia,tegra210-adma".
- reg: Should contain DMA registers location and length. This should be
a single entry that includes all of the per-channel registers in one
contiguous bank.
- interrupt-parent: Phandle to the interrupt parent controller.
- interrupts: Should contain all of the per-channel DMA interrupts in
ascending order with respect to the DMA channel index.
- clocks: Must contain one entry for the ADMA module clock
(TEGRA210_CLK_D_AUDIO).
- clock-names: Must contain the name "d_audio" for the corresponding
'clocks' entry.
- #dma-cells : Must be 1. The first cell denotes the receive/transmit
request number and should be between 1 and the maximum number of
requests supported. This value corresponds to the RX/TX_REQUEST_SELECT
fields in the ADMA_CHn_CTRL register.
Example:
adma: dma@702e2000 {
compatible = "nvidia,tegra210-adma";
reg = <0x0 0x702e2000 0x0 0x2000>;
interrupt-parent = <&tegra_agic>;
interrupts = <GIC_SPI 24 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 25 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 26 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 27 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 28 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 29 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 30 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 31 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 32 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 33 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 34 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 35 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 36 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 37 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 38 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 39 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 40 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 41 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 42 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 43 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 44 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 45 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&tegra_car TEGRA210_CLK_D_AUDIO>;
clock-names = "d_audio";
#dma-cells = <1>;
};

2
Documentation/devicetree/bindings/dma/qcom_bam_dma.txt
View File

@ -13,6 +13,8 @@ Required properties:
- clock-names: must contain "bam_clk" entry
- qcom,ee : indicates the active Execution Environment identifier (0-7) used in
the secure world.
- qcom,controlled-remotely : optional, indicates that the bam is controlled by
remote proccessor i.e. execution environment.
Example:

11
Documentation/devicetree/bindings/dma/snps-dma.txt
View File

@ -13,6 +13,11 @@ Required properties:
- chan_priority: priority of channels. 0 (default): increase from chan 0->n, 1:
increase from chan n->0
- block_size: Maximum block size supported by the controller
- data-width: Maximum data width supported by hardware per AHB master
(in bytes, power of 2)
Deprecated properties:
- data_width: Maximum data width supported by hardware per AHB master
(0 - 8bits, 1 - 16bits, ..., 5 - 256bits)
@ -38,7 +43,7 @@ Example:
chan_allocation_order = <1>;
chan_priority = <1>;
block_size = <0xfff>;
data_width = <3 3>;
data-width = <8 8>;
};
DMA clients connected to the Designware DMA controller must use the format
@ -47,8 +52,8 @@ The four cells in order are:
1. A phandle pointing to the DMA controller
2. The DMA request line number
3. Source master for transfers on allocated channel
4. Destination master for transfers on allocated channel
3. Memory master for transfers on allocated channel
4. Peripheral master for transfers on allocated channel
Example:

2
Documentation/devicetree/bindings/dma/xilinx/xilinx_dma.txt
View File

@ -7,7 +7,7 @@ Required properties:
- compatible: Should be "xlnx,axi-dma-1.00.a"
- #dma-cells: Should be <1>, see "dmas" property below
- reg: Should contain DMA registers location and length.
- dma-channel child node: Should have atleast one channel and can have upto
- dma-channel child node: Should have at least one channel and can have up to
two channels per device. This node specifies the properties of each
DMA channel (see child node properties below).

36
Documentation/devicetree/bindings/dma/xilinx/xilinx_vdma.txt
View File

@ -3,18 +3,44 @@ It can be configured to have one channel or two channels. If configured
as two channels, one is to transmit to the video device and another is
to receive from the video device.
Xilinx AXI DMA engine, it does transfers between memory and AXI4 stream
target devices. It can be configured to have one channel or two channels.
If configured as two channels, one is to transmit to the device and another
is to receive from the device.
Xilinx AXI CDMA engine, it does transfers between memory-mapped source
address and a memory-mapped destination address.
Required properties:
- compatible: Should be "xlnx,axi-vdma-1.00.a"
- compatible: Should be "xlnx,axi-vdma-1.00.a" or "xlnx,axi-dma-1.00.a" or
"xlnx,axi-cdma-1.00.a""
- #dma-cells: Should be <1>, see "dmas" property below
- reg: Should contain VDMA registers location and length.
- xlnx,num-fstores: Should be the number of framebuffers as configured in h/w.
- xlnx,addrwidth: Should be the vdma addressing size in bits(ex: 32 bits).
- dma-ranges: Should be as the following <dma_addr cpu_addr max_len>.
- dma-channel child node: Should have at least one channel and can have up to
two channels per device. This node specifies the properties of each
DMA channel (see child node properties below).
- clocks: Input clock specifier. Refer to common clock bindings.
- clock-names: List of input clocks
For VDMA:
Required elements: "s_axi_lite_aclk"
Optional elements: "m_axi_mm2s_aclk" "m_axi_s2mm_aclk",
"m_axis_mm2s_aclk", "s_axis_s2mm_aclk"
For CDMA:
Required elements: "s_axi_lite_aclk", "m_axi_aclk"
FOR AXIDMA:
Required elements: "s_axi_lite_aclk"
Optional elements: "m_axi_mm2s_aclk", "m_axi_s2mm_aclk",
"m_axi_sg_aclk"
Required properties for VDMA:
- xlnx,num-fstores: Should be the number of framebuffers as configured in h/w.
Optional properties:
- xlnx,include-sg: Tells configured for Scatter-mode in
the hardware.
Optional properties for VDMA:
- xlnx,flush-fsync: Tells which channel to Flush on Frame sync.
It takes following values:
{1}, flush both channels
@ -31,6 +57,7 @@ Required child node properties:
Optional child node properties:
- xlnx,include-dre: Tells hardware is configured for Data
Realignment Engine.
Optional child node properties for VDMA:
- xlnx,genlock-mode: Tells Genlock synchronization is
enabled/disabled in hardware.
@ -41,8 +68,13 @@ axi_vdma_0: axivdma@40030000 {
compatible = "xlnx,axi-vdma-1.00.a";
#dma_cells = <1>;
reg = < 0x40030000 0x10000 >;
dma-ranges = <0x00000000 0x00000000 0x40000000>;
xlnx,num-fstores = <0x8>;
xlnx,flush-fsync = <0x1>;
xlnx,addrwidth = <0x20>;
clocks = <&clk 0>, <&clk 1>, <&clk 2>, <&clk 3>, <&clk 4>;
clock-names = "s_axi_lite_aclk", "m_axi_mm2s_aclk", "m_axi_s2mm_aclk",
"m_axis_mm2s_aclk", "s_axis_s2mm_aclk";
dma-channel@40030000 {
compatible = "xlnx,axi-vdma-mm2s-channel";
interrupts = < 0 54 4 >;

24
Documentation/devicetree/bindings/gpio/ibm,ppc4xx-gpio.txt 100644
View File

@ -0,0 +1,24 @@
* IBM/AMCC/APM GPIO Controller for PowerPC 4XX series and compatible SoCs
All GPIOs are pin-shared with other functions. DCRs control whether a
particular pin that has GPIO capabilities acts as a GPIO or is used for
another purpose. GPIO outputs are separately programmable to emulate
an open-drain driver.
Required properties:
- compatible: must be "ibm,ppc4xx-gpio"
- reg: address and length of the register set for the device
- #gpio-cells: must be set to 2. The first cell is the pin number
and the second cell is used to specify the gpio polarity:
0 = active high
1 = active low
- gpio-controller: marks the device node as a gpio controller.
Example:
GPIO0: gpio@ef600b00 {
compatible = "ibm,ppc4xx-gpio";
reg = <0xef600b00 0x00000048>;
#gpio-cells = <2>;
gpio-controller;
};

2
Documentation/devicetree/bindings/gpio/microchip,pic32-gpio.txt
View File

@ -33,7 +33,7 @@ gpio0: gpio0@1f860000 {
gpio-controller;
interrupt-controller;
#interrupt-cells = <2>;
clocks = <&PBCLK4>;
clocks = <&rootclk PB4CLK>;
microchip,gpio-bank = <0>;
gpio-ranges = <&pic32_pinctrl 0 0 16>;
};

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

@ -7,6 +7,7 @@ Required properties:
- "ti,ina220" for ina220
- "ti,ina226" for ina226
- "ti,ina230" for ina230
- "ti,ina231" for ina231
- reg: I2C address
Optional properties:

4
Documentation/devicetree/bindings/i2c/i2c-arb-gpio-challenge.txt
View File

@ -44,8 +44,8 @@ Required properties:
- our-claim-gpio: The GPIO that we use to claim the bus.
- their-claim-gpios: The GPIOs that the other sides use to claim the bus.
Note that some implementations may only support a single other master.
- Standard I2C mux properties. See mux.txt in this directory.
- Single I2C child bus node at reg 0. See mux.txt in this directory.
- Standard I2C mux properties. See i2c-mux.txt in this directory.
- Single I2C child bus node at reg 0. See i2c-mux.txt in this directory.
Optional properties:
- slew-delay-us: microseconds to wait for a GPIO to go high. Default is 10 us.

3
Documentation/devicetree/bindings/i2c/i2c-demux-pinctrl.txt
View File

@ -27,7 +27,8 @@ Required properties:
- i2c-bus-name: The name of this bus. Also needed as pinctrl-name for the I2C
parents.
Furthermore, I2C mux properties and child nodes. See mux.txt in this directory.
Furthermore, I2C mux properties and child nodes. See i2c-mux.txt in this
directory.
Example:

6
Documentation/devicetree/bindings/i2c/i2c-mux-gpio.txt
View File

@ -22,8 +22,8 @@ Required properties:
- i2c-parent: The phandle of the I2C bus that this multiplexer's master-side
port is connected to.
- mux-gpios: list of gpios used to control the muxer
* Standard I2C mux properties. See mux.txt in this directory.
* I2C child bus nodes. See mux.txt in this directory.
* Standard I2C mux properties. See i2c-mux.txt in this directory.
* I2C child bus nodes. See i2c-mux.txt in this directory.
Optional properties:
- idle-state: value to set the muxer to when idle. When no value is
@ -33,7 +33,7 @@ For each i2c child node, an I2C child bus will be created. They will
be numbered based on their order in the device tree.
Whenever an access is made to a device on a child bus, the value set
in the revelant node's reg property will be output using the list of
in the relevant node's reg property will be output using the list of
GPIOs, the first in the list holding the least-significant value.
If an idle state is defined, using the idle-state (optional) property,

4
Documentation/devicetree/bindings/i2c/i2c-mux-pinctrl.txt
View File

@ -28,9 +28,9 @@ Also required are:
* Standard pinctrl properties that specify the pin mux state for each child
bus. See ../pinctrl/pinctrl-bindings.txt.
* Standard I2C mux properties. See mux.txt in this directory.
* Standard I2C mux properties. See i2c-mux.txt in this directory.
* I2C child bus nodes. See mux.txt in this directory.
* I2C child bus nodes. See i2c-mux.txt in this directory.
For each named state defined in the pinctrl-names property, an I2C child bus
will be created. I2C child bus numbers are assigned based on the index into

6
Documentation/devicetree/bindings/i2c/i2c-mux-reg.txt
View File

@ -7,8 +7,8 @@ Required properties:
- compatible: i2c-mux-reg
- i2c-parent: The phandle of the I2C bus that this multiplexer's master-side
port is connected to.
* Standard I2C mux properties. See mux.txt in this directory.
* I2C child bus nodes. See mux.txt in this directory.
* Standard I2C mux properties. See i2c-mux.txt in this directory.
* I2C child bus nodes. See i2c-mux.txt in this directory.
Optional properties:
- reg: this pair of <offset size> specifies the register to control the mux.
@ -24,7 +24,7 @@ Optional properties:
given, it defaults to the last value used.
Whenever an access is made to a device on a child bus, the value set
in the revelant node's reg property will be output to the register.
in the relevant node's reg property will be output to the register.
If an idle state is defined, using the idle-state (optional) property,
whenever an access is not being made to a device on a child bus, the

6
Documentation/devicetree/bindings/i2c/i2c-octeon.txt
View File

@ -4,6 +4,12 @@
Compatibility with all cn3XXX, cn5XXX and cn6XXX SOCs.
or
compatible: "cavium,octeon-7890-twsi"
Compatibility with cn78XX SOCs.
- reg: The base address of the TWSI/I2C bus controller register bank.
- #address-cells: Must be <1>.

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