mirrors/linux
2
0
Fork 0
mirror of https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git synced 2026-05-07 16:17:41 -04:00
Code Issues Packages Projects Releases Wiki Activity

Merge tag 'v3.17-rc1' into patchwork

Browse Source 
Linux 3.17-rc1
This commit is contained in:
Mauro Carvalho Chehab
2014-08-21 15:23:58 -05:00
parent 0f3bf3dc1c 7d1311b93e
commit 2871f352c6
9308 changed files with 414660 additions and 434522 deletions
Download Patch File Download Diff File Expand all files Collapse all files

1
.gitignore vendored
View File

@@ -34,6 +34,7 @@
*.gcno
modules.builtin
Module.symvers
*.dwo
#
# Top-level generic files

5
.mailmap
View File

@@ -62,6 +62,11 @@ Jeff Garzik <jgarzik@pretzel.yyz.us>
Jens Axboe <axboe@suse.de>
Jens Osterkamp <Jens.Osterkamp@de.ibm.com>
John Stultz <johnstul@us.ibm.com>
<josh@joshtriplett.org> <josh@freedesktop.org>
<josh@joshtriplett.org> <josh@kernel.org>
<josh@joshtriplett.org> <josht@linux.vnet.ibm.com>
<josh@joshtriplett.org> <josht@us.ibm.com>
<josh@joshtriplett.org> <josht@vnet.ibm.com>
Juha Yrjola <at solidboot.com>
Juha Yrjola <juha.yrjola@nokia.com>
Juha Yrjola <juha.yrjola@solidboot.com>

14
CREDITS
View File

@@ -1381,6 +1381,9 @@ S: 17 rue Danton
S: F - 94270 Le Kremlin-Bicêtre
S: France
N: Jack Hammer
D: IBM ServeRAID RAID (ips) driver maintenance
N: Greg Hankins
E: gregh@cc.gatech.edu
D: fixed keyboard driver to separate LED and locking status
@@ -1691,6 +1694,10 @@ S: Reading
S: RG6 2NU
S: United Kingdom
N: Dave Jeffery
E: dhjeffery@gmail.com
D: SCSI hacks and IBM ServeRAID RAID driver maintenance
N: Jakub Jelinek
E: jakub@redhat.com
W: http://sunsite.mff.cuni.cz/~jj
@@ -3511,10 +3518,11 @@ S: MacGregor A.C.T 2615
S: Australia
N: Josh Triplett
E: josh@freedesktop.org
P: 1024D/D0FE7AFB B24A 65C9 1D71 2AC2 DE87 CA26 189B 9946 D0FE 7AFB
D: rcutorture maintainer
E: josh@joshtriplett.org
P: 4096R/8AFF873D 758E 5042 E397 4BA3 3A9C 1E67 0ED9 A3DF 8AFF 873D
D: RCU and rcutorture
D: lock annotations, finding and fixing lock bugs
D: kernel tinification
N: Winfried Trümper
E: winni@xpilot.org

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

@@ -3,13 +3,13 @@ Date: May 2007
KernelVersion: 2.6.23
Contact: Alan Stern <stern@rowland.harvard.edu>
Description:
If CONFIG_USB_PERSIST is set, then each USB device directory
will contain a file named power/persist. The file holds a
boolean value (0 or 1) indicating whether or not the
"USB-Persist" facility is enabled for the device. Since the
facility is inherently dangerous, it is disabled by default
for all devices except hubs. For more information, see
Documentation/usb/persist.txt.
USB device directories can contain a file named power/persist.
The file holds a boolean value (0 or 1) indicating whether or
not the "USB-Persist" facility is enabled for the device. For
hubs this facility is always enabled and their device
directories will not contain this file.
For more information, see Documentation/usb/persist.txt.
What: /sys/bus/usb/devices/.../power/autosuspend
Date: March 2007

4
Documentation/ABI/testing/ima_policy
View File

@@ -26,6 +26,7 @@ Description:
option: [[appraise_type=]] [permit_directio]
base: func:= [BPRM_CHECK][MMAP_CHECK][FILE_CHECK][MODULE_CHECK]
[FIRMWARE_CHECK]
mask:= [MAY_READ] [MAY_WRITE] [MAY_APPEND] [MAY_EXEC]
fsmagic:= hex value
fsuuid:= file system UUID (e.g 8bcbe394-4f13-4144-be8e-5aa9ea2ce2f6)
@@ -57,7 +58,8 @@ Description:
measure func=BPRM_CHECK
measure func=FILE_MMAP mask=MAY_EXEC
measure func=FILE_CHECK mask=MAY_READ uid=0
measure func=MODULE_CHECK uid=0
measure func=MODULE_CHECK
measure func=FIRMWARE_CHECK
appraise fowner=0
The default policy measures all executables in bprm_check,

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

@@ -260,6 +260,10 @@ What: /sys/bus/iio/devices/iio:deviceX/in_magn_scale
What: /sys/bus/iio/devices/iio:deviceX/in_magn_x_scale
What: /sys/bus/iio/devices/iio:deviceX/in_magn_y_scale
What: /sys/bus/iio/devices/iio:deviceX/in_magn_z_scale
What: /sys/bus/iio/devices/iio:deviceX/in_rot_from_north_magnetic_scale
What: /sys/bus/iio/devices/iio:deviceX/in_rot_from_north_true_scale
What: /sys/bus/iio/devices/iio:deviceX/in_rot_from_north_magnetic_tilt_comp_scale
What: /sys/bus/iio/devices/iio:deviceX/in_rot_from_north_true_tilt_comp_scale
What: /sys/bus/iio/devices/iio:deviceX/in_pressureY_scale
What: /sys/bus/iio/devices/iio:deviceX/in_pressure_scale
KernelVersion: 2.6.35
@@ -447,6 +451,14 @@ What: /sys/.../iio:deviceX/events/in_magn_y_thresh_rising_en
What: /sys/.../iio:deviceX/events/in_magn_y_thresh_falling_en
What: /sys/.../iio:deviceX/events/in_magn_z_thresh_rising_en
What: /sys/.../iio:deviceX/events/in_magn_z_thresh_falling_en
What: /sys/.../iio:deviceX/events/in_rot_from_north_magnetic_thresh_rising_en
What: /sys/.../iio:deviceX/events/in_rot_from_north_magnetic_thresh_falling_en
What: /sys/.../iio:deviceX/events/in_rot_from_north_true_thresh_rising_en
What: /sys/.../iio:deviceX/events/in_rot_from_north_true_thresh_falling_en
What: /sys/.../iio:deviceX/events/in_rot_from_north_magnetic_tilt_comp_thresh_rising_en
What: /sys/.../iio:deviceX/events/in_rot_from_north_magnetic_tilt_comp_thresh_falling_en
What: /sys/.../iio:deviceX/events/in_rot_from_north_true_tilt_comp_thresh_rising_en
What: /sys/.../iio:deviceX/events/in_rot_from_north_true_tilt_comp_thresh_falling_en
What: /sys/.../iio:deviceX/events/in_voltageY_supply_thresh_rising_en
What: /sys/.../iio:deviceX/events/in_voltageY_supply_thresh_falling_en
What: /sys/.../iio:deviceX/events/in_voltageY_thresh_rising_en
@@ -492,6 +504,14 @@ What: /sys/.../iio:deviceX/events/in_magn_y_roc_rising_en
What: /sys/.../iio:deviceX/events/in_magn_y_roc_falling_en
What: /sys/.../iio:deviceX/events/in_magn_z_roc_rising_en
What: /sys/.../iio:deviceX/events/in_magn_z_roc_falling_en
What: /sys/.../iio:deviceX/events/in_rot_from_north_magnetic_roc_rising_en
What: /sys/.../iio:deviceX/events/in_rot_from_north_magnetic_roc_falling_en
What: /sys/.../iio:deviceX/events/in_rot_from_north_true_roc_rising_en
What: /sys/.../iio:deviceX/events/in_rot_from_north_true_roc_falling_en
What: /sys/.../iio:deviceX/events/in_rot_from_north_magnetic_tilt_comp_roc_rising_en
What: /sys/.../iio:deviceX/events/in_rot_from_north_magnetic_tilt_comp_roc_falling_en
What: /sys/.../iio:deviceX/events/in_rot_from_north_true_tilt_comp_roc_rising_en
What: /sys/.../iio:deviceX/events/in_rot_from_north_true_tilt_comp_roc_falling_en
What: /sys/.../iio:deviceX/events/in_voltageY_supply_roc_rising_en
What: /sys/.../iio:deviceX/events/in_voltageY_supply_roc_falling_en
What: /sys/.../iio:deviceX/events/in_voltageY_roc_rising_en
@@ -538,6 +558,14 @@ What: /sys/.../events/in_magn_y_raw_thresh_rising_value
What: /sys/.../events/in_magn_y_raw_thresh_falling_value
What: /sys/.../events/in_magn_z_raw_thresh_rising_value
What: /sys/.../events/in_magn_z_raw_thresh_falling_value
What: /sys/.../events/in_rot_from_north_magnetic_raw_thresh_rising_value
What: /sys/.../events/in_rot_from_north_magnetic_raw_thresh_falling_value
What: /sys/.../events/in_rot_from_north_true_raw_thresh_rising_value
What: /sys/.../events/in_rot_from_north_true_raw_thresh_falling_value
What: /sys/.../events/in_rot_from_north_magnetic_tilt_comp_raw_thresh_rising_value
What: /sys/.../events/in_rot_from_north_magnetic_tilt_comp_raw_thresh_falling_value
What: /sys/.../events/in_rot_from_north_true_tilt_comp_raw_thresh_rising_value
What: /sys/.../events/in_rot_from_north_true_tilt_comp_raw_thresh_falling_value
What: /sys/.../events/in_voltageY_supply_raw_thresh_rising_value
What: /sys/.../events/in_voltageY_supply_raw_thresh_falling_value
What: /sys/.../events/in_voltageY_raw_thresh_rising_value
@@ -588,6 +616,18 @@ What: /sys/.../events/in_magn_y_thresh_either_hysteresis
What: /sys/.../events/in_magn_z_thresh_rising_hysteresis
What: /sys/.../events/in_magn_z_thresh_falling_hysteresis
What: /sys/.../events/in_magn_z_thresh_either_hysteresis
What: /sys/.../events/in_rot_from_north_magnetic_thresh_rising_hysteresis
What: /sys/.../events/in_rot_from_north_magnetic_thresh_falling_hysteresis
What: /sys/.../events/in_rot_from_north_magnetic_thresh_either_hysteresis
What: /sys/.../events/in_rot_from_north_true_thresh_rising_hysteresis
What: /sys/.../events/in_rot_from_north_true_thresh_falling_hysteresis
What: /sys/.../events/in_rot_from_north_true_thresh_either_hysteresis
What: /sys/.../events/in_rot_from_north_magnetic_tilt_comp_thresh_rising_hysteresis
What: /sys/.../events/in_rot_from_north_magnetic_tilt_comp_thresh_falling_hysteresis
What: /sys/.../events/in_rot_from_north_magnetic_tilt_comp_thresh_either_hysteresis
What: /sys/.../events/in_rot_from_north_true_tilt_comp_thresh_rising_hysteresis
What: /sys/.../events/in_rot_from_north_true_tilt_comp_thresh_falling_hysteresis
What: /sys/.../events/in_rot_from_north_true_tilt_comp_thresh_either_hysteresis
What: /sys/.../events/in_voltageY_thresh_rising_hysteresis
What: /sys/.../events/in_voltageY_thresh_falling_hysteresis
What: /sys/.../events/in_voltageY_thresh_either_hysteresis
@@ -635,6 +675,14 @@ What: /sys/.../events/in_magn_y_raw_roc_rising_value
What: /sys/.../events/in_magn_y_raw_roc_falling_value
What: /sys/.../events/in_magn_z_raw_roc_rising_value
What: /sys/.../events/in_magn_z_raw_roc_falling_value
What: /sys/.../events/in_rot_from_north_magnetic_raw_roc_rising_value
What: /sys/.../events/in_rot_from_north_magnetic_raw_roc_falling_value
What: /sys/.../events/in_rot_from_north_true_raw_roc_rising_value
What: /sys/.../events/in_rot_from_north_true_raw_roc_falling_value
What: /sys/.../events/in_rot_from_north_magnetic_tilt_comp_raw_roc_rising_value
What: /sys/.../events/in_rot_from_north_magnetic_tilt_comp_raw_roc_falling_value
What: /sys/.../events/in_rot_from_north_true_tilt_comp_raw_roc_rising_value
What: /sys/.../events/in_rot_from_north_true_tilt_comp_raw_roc_falling_value
What: /sys/.../events/in_voltageY_supply_raw_roc_rising_value
What: /sys/.../events/in_voltageY_supply_raw_roc_falling_value
What: /sys/.../events/in_voltageY_raw_roc_rising_value
@@ -690,6 +738,22 @@ What: /sys/.../events/in_magn_z_thresh_rising_period
What: /sys/.../events/in_magn_z_thresh_falling_period
What: /sys/.../events/in_magn_z_roc_rising_period
What: /sys/.../events/in_magn_z_roc_falling_period
What: /sys/.../events/in_rot_from_north_magnetic_thresh_rising_period
What: /sys/.../events/in_rot_from_north_magnetic_thresh_falling_period
What: /sys/.../events/in_rot_from_north_magnetic_roc_rising_period
What: /sys/.../events/in_rot_from_north_magnetic_roc_falling_period
What: /sys/.../events/in_rot_from_north_true_thresh_rising_period
What: /sys/.../events/in_rot_from_north_true_thresh_falling_period
What: /sys/.../events/in_rot_from_north_true_roc_rising_period
What: /sys/.../events/in_rot_from_north_true_roc_falling_period
What: /sys/.../events/in_rot_from_north_magnetic_tilt_comp_thresh_rising_period
What: /sys/.../events/in_rot_from_north_magnetic_tilt_comp_thresh_falling_period
What: /sys/.../events/in_rot_from_north_magnetic_tilt_comp_roc_rising_period
What: /sys/.../events/in_rot_from_north_magnetic_tilt_comp_roc_falling_period
What: /sys/.../events/in_rot_from_north_true_tilt_comp_thresh_rising_period
What: /sys/.../events/in_rot_from_north_true_tilt_comp_thresh_falling_period
What: /sys/.../events/in_rot_from_north_true_tilt_comp_roc_rising_period
What: /sys/.../events/in_rot_from_north_true_tilt_comp_roc_falling_period
What: /sys/.../events/in_voltageY_supply_thresh_rising_period
What: /sys/.../events/in_voltageY_supply_thresh_falling_period
What: /sys/.../events/in_voltageY_supply_roc_rising_period
@@ -787,6 +851,10 @@ What: /sys/.../iio:deviceX/scan_elements/in_anglvel_z_en
What: /sys/.../iio:deviceX/scan_elements/in_magn_x_en
What: /sys/.../iio:deviceX/scan_elements/in_magn_y_en
What: /sys/.../iio:deviceX/scan_elements/in_magn_z_en
What: /sys/.../iio:deviceX/scan_elements/in_rot_from_north_magnetic_en
What: /sys/.../iio:deviceX/scan_elements/in_rot_from_north_true_en
What: /sys/.../iio:deviceX/scan_elements/in_rot_from_north_magnetic_tilt_comp_en
What: /sys/.../iio:deviceX/scan_elements/in_rot_from_north_true_tilt_comp_en
What: /sys/.../iio:deviceX/scan_elements/in_timestamp_en
What: /sys/.../iio:deviceX/scan_elements/in_voltageY_supply_en
What: /sys/.../iio:deviceX/scan_elements/in_voltageY_en
@@ -853,6 +921,10 @@ What: /sys/.../iio:deviceX/scan_elements/in_anglvel_z_index
What: /sys/.../iio:deviceX/scan_elements/in_magn_x_index
What: /sys/.../iio:deviceX/scan_elements/in_magn_y_index
What: /sys/.../iio:deviceX/scan_elements/in_magn_z_index
What: /sys/.../iio:deviceX/scan_elements/in_rot_from_north_magnetic_index
What: /sys/.../iio:deviceX/scan_elements/in_rot_from_north_true_index
What: /sys/.../iio:deviceX/scan_elements/in_rot_from_north_magnetic_tilt_comp_index
What: /sys/.../iio:deviceX/scan_elements/in_rot_from_north_true_tilt_comp_index
What: /sys/.../iio:deviceX/scan_elements/in_incli_x_index
What: /sys/.../iio:deviceX/scan_elements/in_incli_y_index
What: /sys/.../iio:deviceX/scan_elements/in_timestamp_index
@@ -895,6 +967,19 @@ Description:
on-chip EEPROM. After power-up or chip reset the device will
automatically load the saved configuration.
What: /sys/.../iio:deviceX/in_proximity_raw
What: /sys/.../iio:deviceX/in_proximity_input
What: /sys/.../iio:deviceX/in_proximityY_raw
KernelVersion: 3.4
Contact: linux-iio@vger.kernel.org
Description:
Proximity measurement indicating that some
object is near the sensor, usually be observing
reflectivity of infrared or ultrasound emitted.
Often these sensors are unit less and as such conversion
to SI units is not possible. Where it is, the units should
be meters.
What: /sys/.../iio:deviceX/in_illuminanceY_input
What: /sys/.../iio:deviceX/in_illuminanceY_raw
What: /sys/.../iio:deviceX/in_illuminanceY_mean_raw
@@ -933,3 +1018,13 @@ Description:
x y z w. Here x, y, and z component represents the axis about
which a rotation will occur and w component represents the
amount of rotation.
What: /sys/bus/iio/devices/iio:deviceX/in_rot_from_north_magnetic_tilt_comp_raw
What: /sys/bus/iio/devices/iio:deviceX/in_rot_from_north_true_tilt_comp_raw
What: /sys/bus/iio/devices/iio:deviceX/in_rot_from_north_magnetic_raw
What: /sys/bus/iio/devices/iio:deviceX/in_rot_from_north_true_raw
KernelVersion: 3.15
Contact: linux-iio@vger.kernel.org
Description:
Raw value of rotation from true/magnetic north measured with
or without compensation from tilt sensors.

0
drivers/staging/iio/Documentation/sysfs-bus-iio-trigger-sysfs → Documentation/ABI/testing/sysfs-bus-iio-trigger-sysfs
View File

20
Documentation/ABI/testing/sysfs-bus-platform Normal file
View File

@@ -0,0 +1,20 @@
What: /sys/bus/platform/devices/.../driver_override
Date: April 2014
Contact: Kim Phillips <kim.phillips@freescale.com>
Description:
This file allows the driver for a device to be specified which
will override standard OF, ACPI, ID table, and name matching.
When specified, only a driver with a name matching the value
written to driver_override will have an opportunity to bind
to the device. The override is specified by writing a string
to the driver_override file (echo vfio-platform > \
driver_override) and may be cleared with an empty string
(echo > driver_override). This returns the device to standard
matching rules binding. Writing to driver_override does not
automatically unbind the device from its current driver or make
any attempt to automatically load the specified driver. If no
driver with a matching name is currently loaded in the kernel,
the device will not bind to any driver. This also allows
devices to opt-out of driver binding using a driver_override
name such as "none". Only a single driver may be specified in
the override, there is no support for parsing delimiters.

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

@@ -94,5 +94,5 @@ current_snap
parent
Information identifying the pool, image, and snapshot id for
the parent image in a layered rbd image (format 2 only).
Information identifying the chain of parent images in a layered rbd
image. Entries are separated by empty lines.

47
Documentation/ABI/testing/sysfs-bus-usb-lvstest Normal file
View File

@@ -0,0 +1,47 @@
Link Layer Validation Device is a standard device for testing of Super
Speed Link Layer tests. These nodes are available in sysfs only when lvs
driver is bound with root hub device.
What: /sys/bus/usb/devices/.../get_dev_desc
Date: March 2014
Contact: Pratyush Anand <pratyush.anand@st.com>
Description:
Write to this node to issue "Get Device Descriptor"
for Link Layer Validation device. It is needed for TD.7.06.
What: /sys/bus/usb/devices/.../u1_timeout
Date: March 2014
Contact: Pratyush Anand <pratyush.anand@st.com>
Description:
Set "U1 timeout" for the downstream port where Link Layer
Validation device is connected. Timeout value must be between 0
and 127. It is needed for TD.7.18, TD.7.19, TD.7.20 and TD.7.21.
What: /sys/bus/usb/devices/.../u2_timeout
Date: March 2014
Contact: Pratyush Anand <pratyush.anand@st.com>
Description:
Set "U2 timeout" for the downstream port where Link Layer
Validation device is connected. Timeout value must be between 0
and 127. It is needed for TD.7.18, TD.7.19, TD.7.20 and TD.7.21.
What: /sys/bus/usb/devices/.../hot_reset
Date: March 2014
Contact: Pratyush Anand <pratyush.anand@st.com>
Description:
Write to this node to issue "Reset" for Link Layer Validation
device. It is needed for TD.7.29, TD.7.31, TD.7.34 and TD.7.35.
What: /sys/bus/usb/devices/.../u3_entry
Date: March 2014
Contact: Pratyush Anand <pratyush.anand@st.com>
Description:
Write to this node to issue "U3 entry" for Link Layer
Validation device. It is needed for TD.7.35 and TD.7.36.
What: /sys/bus/usb/devices/.../u3_exit
Date: March 2014
Contact: Pratyush Anand <pratyush.anand@st.com>
Description:
Write to this node to issue "U3 exit" for Link Layer
Validation device. It is needed for TD.7.36.

17
Documentation/ABI/testing/sysfs-class-iommu Normal file
View File

@@ -0,0 +1,17 @@
What: /sys/class/iommu/<iommu>/devices/
Date: June 2014
KernelVersion: 3.17
Contact: Alex Williamson <alex.williamson@redhat.com>
Description:
IOMMU drivers are able to link devices managed by a
given IOMMU here to allow association of IOMMU to
device.
What: /sys/devices/.../iommu
Date: June 2014
KernelVersion: 3.17
Contact: Alex Williamson <alex.williamson@redhat.com>
Description:
IOMMU drivers are able to link the IOMMU for a
given device here to allow association of device to
IOMMU.

14
Documentation/ABI/testing/sysfs-class-iommu-amd-iommu Normal file
View File

@@ -0,0 +1,14 @@
What: /sys/class/iommu/<iommu>/amd-iommu/cap
Date: June 2014
KernelVersion: 3.17
Contact: Alex Williamson <alex.williamson@redhat.com>
Description:
IOMMU capability header as documented in the AMD IOMMU
specification. Format: %x
What: /sys/class/iommu/<iommu>/amd-iommu/features
Date: June 2014
KernelVersion: 3.17
Contact: Alex Williamson <alex.williamson@redhat.com>
Description:
Extended features of the IOMMU. Format: %llx

32
Documentation/ABI/testing/sysfs-class-iommu-intel-iommu Normal file
View File

@@ -0,0 +1,32 @@
What: /sys/class/iommu/<iommu>/intel-iommu/address
Date: June 2014
KernelVersion: 3.17
Contact: Alex Williamson <alex.williamson@redhat.com>
Description:
Physical address of the VT-d DRHD for this IOMMU.
Format: %llx. This allows association of a sysfs
intel-iommu with a DMAR DRHD table entry.
What: /sys/class/iommu/<iommu>/intel-iommu/cap
Date: June 2014
KernelVersion: 3.17
Contact: Alex Williamson <alex.williamson@redhat.com>
Description:
The cached hardware capability register value
of this DRHD unit. Format: %llx.
What: /sys/class/iommu/<iommu>/intel-iommu/ecap
Date: June 2014
KernelVersion: 3.17
Contact: Alex Williamson <alex.williamson@redhat.com>
Description:
The cached hardware extended capability register
value of this DRHD unit. Format: %llx.
What: /sys/class/iommu/<iommu>/intel-iommu/version
Date: June 2014
KernelVersion: 3.17
Contact: Alex Williamson <alex.williamson@redhat.com>
Description:
The architecture version as reported from the
VT-d VER_REG. Format: %d:%d, major:minor

16
Documentation/ABI/testing/sysfs-class-leds-gt683r Normal file
View File

@@ -0,0 +1,16 @@
What: /sys/class/leds/<led>/gt683r/mode
Date: Jun 2014
KernelVersion: 3.17
Contact: Janne Kanniainen <janne.kanniainen@gmail.com>
Description:
Set the mode of LEDs. You should notice that changing the mode
of one LED will update the mode of its two sibling devices as
well.
0 - normal
1 - audio
2 - breathing
Normal: LEDs are fully on when enabled
Audio: LEDs brightness depends on sound level
Breathing: LEDs brightness varies at human breathing rate

16
Documentation/ABI/testing/sysfs-class-mei Normal file
View File

@@ -0,0 +1,16 @@
What: /sys/class/mei/
Date: May 2014
KernelVersion: 3.17
Contact: Tomas Winkler <tomas.winkler@intel.com>
Description:
The mei/ class sub-directory belongs to mei device class
What: /sys/class/mei/meiN/
Date: May 2014
KernelVersion: 3.17
Contact: Tomas Winkler <tomas.winkler@intel.com>
Description:
The /sys/class/mei/meiN directory is created for
each probed mei device

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

@@ -184,3 +184,41 @@ Description:
It will always be a non-negative integer. In the case of
devices lacking any ECC capability, it is 0.
What: /sys/class/mtd/mtdX/ecc_failures
Date: June 2014
KernelVersion: 3.17
Contact: linux-mtd@lists.infradead.org
Description:
The number of failures reported by this device's ECC. Typically,
these failures are associated with failed read operations.
It will always be a non-negative integer. In the case of
devices lacking any ECC capability, it is 0.
What: /sys/class/mtd/mtdX/corrected_bits
Date: June 2014
KernelVersion: 3.17
Contact: linux-mtd@lists.infradead.org
Description:
The number of bits that have been corrected by means of the
device's ECC.
It will always be a non-negative integer. In the case of
devices lacking any ECC capability, it is 0.
What: /sys/class/mtd/mtdX/bad_blocks
Date: June 2014
KernelVersion: 3.17
Contact: linux-mtd@lists.infradead.org
Description:
The number of blocks marked as bad, if any, in this partition.
What: /sys/class/mtd/mtdX/bbt_blocks
Date: June 2014
KernelVersion: 3.17
Contact: linux-mtd@lists.infradead.org
Description:
The number of blocks that are marked as reserved, if any, in
this partition. These are typically used to store the in-flash
bad block table (BBT).

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

@@ -1,3 +1,14 @@
What: /sys/class/net/<iface>/name_assign_type
Date: July 2014
KernelVersion: 3.17
Contact: netdev@vger.kernel.org
Description:
Indicates the name assignment type. Possible values are:
1: enumerated by the kernel, possibly in an unpredictable way
2: predictably named by the kernel
3: named by userspace
4: renamed
What: /sys/class/net/<iface>/addr_assign_type
Date: July 2010
KernelVersion: 3.2

9
Documentation/ABI/testing/sysfs-driver-genwqe
View File

@@ -25,6 +25,15 @@ Date: Oct 2013
Contact: haver@linux.vnet.ibm.com
Description: Interface to set the next bitstream to be used.
What: /sys/class/genwqe/genwqe<n>_card/reload_bitstream
Date: May 2014
Contact: klebers@linux.vnet.ibm.com
Description: Interface to trigger a PCIe card reset to reload the bitstream.
sudo sh -c 'echo 1 > \
/sys/class/genwqe/genwqe0_card/reload_bitstream'
If successfully, the card will come back with the bitstream set
on 'next_bitstream'.
What: /sys/class/genwqe/genwqe<n>_card/tempsens
Date: Oct 2013
Contact: haver@linux.vnet.ibm.com

12
Documentation/ABI/testing/sysfs-driver-hid-lenovo-tpkbd → Documentation/ABI/testing/sysfs-driver-hid-lenovo
View File

@@ -4,18 +4,21 @@ Contact: linux-input@vger.kernel.org
Description: This controls if mouse clicks should be generated if the trackpoint is quickly pressed. How fast this press has to be
is being controlled by press_speed.
Values are 0 or 1.
Applies to Thinkpad USB Keyboard with TrackPoint.
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/dragging
Date: July 2011
Contact: linux-input@vger.kernel.org
Description: If this setting is enabled, it is possible to do dragging by pressing the trackpoint. This requires press_to_select to be enabled.
Values are 0 or 1.
Applies to Thinkpad USB Keyboard with TrackPoint.
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/release_to_select
Date: July 2011
Contact: linux-input@vger.kernel.org
Description: For details regarding this setting please refer to http://www.pc.ibm.com/ww/healthycomputing/trkpntb.html
Values are 0 or 1.
Applies to Thinkpad USB Keyboard with TrackPoint.
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/select_right
Date: July 2011
@@ -23,16 +26,25 @@ Contact: linux-input@vger.kernel.org
Description: This setting controls if the mouse click events generated by pressing the trackpoint (if press_to_select is enabled) generate
a left or right mouse button click.
Values are 0 or 1.
Applies to Thinkpad USB Keyboard with TrackPoint.
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/sensitivity
Date: July 2011
Contact: linux-input@vger.kernel.org
Description: This file contains the trackpoint sensitivity.
Values are decimal integers from 1 (lowest sensitivity) to 255 (highest sensitivity).
Applies to Thinkpad USB Keyboard with TrackPoint.
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/press_speed
Date: July 2011
Contact: linux-input@vger.kernel.org
Description: This setting controls how fast the trackpoint needs to be pressed to generate a mouse click if press_to_select is enabled.
Values are decimal integers from 1 (slowest) to 255 (fastest).
Applies to Thinkpad USB Keyboard with TrackPoint.
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/fn_lock
Date: July 2014
Contact: linux-input@vger.kernel.org
Description: This setting controls whether Fn Lock is enabled on the keyboard (i.e. if F1 is Mute or F1)
Values are 0 or 1
Applies to ThinkPad Compact (USB|Bluetooth) Keyboard with TrackPoint.

13
Documentation/ABI/testing/sysfs-driver-pciback Normal file
View File

@@ -0,0 +1,13 @@
What: /sys/bus/pci/drivers/pciback/quirks
Date: Oct 2011
KernelVersion: 3.1
Contact: xen-devel@lists.xenproject.org
Description:
If the permissive attribute is set, then writing a string in
the format of DDDD:BB:DD.F-REG:SIZE:MASK will allow the guest
to write and read from the PCI device. That is Domain:Bus:
Device.Function-Register:Size:Mask (Domain is optional).
For example:
#echo 00:19.0-E0:2:FF > /sys/bus/pci/drivers/pciback/quirks
will allow the guest to read and write to the configuration
register 0x0E.

11
Documentation/ABI/testing/sysfs-driver-tegra-fuse Normal file
View File

@@ -0,0 +1,11 @@
What: /sys/devices/*/<our-device>/fuse
Date: February 2014
Contact: Peter De Schrijver <pdeschrijver@nvidia.com>
Description: read-only access to the efuses on Tegra20, Tegra30, Tegra114
and Tegra124 SoC's from NVIDIA. The efuses contain write once
data programmed at the factory. The data is layed out in 32bit
words in LSB first format. Each bit represents a single value
as decoded from the fuse registers. Bits order/assignment
exactly matches the HW registers, including any unused bits.
Users: any user space application which wants to read the efuses on
Tegra SoC's

70
Documentation/ABI/testing/sysfs-driver-wacom
View File

@@ -1,48 +1,27 @@
WWhat: /sys/class/hidraw/hidraw*/device/oled*_img
Date: June 2012
Contact: linux-bluetooth@vger.kernel.org
Description:
The /sys/class/hidraw/hidraw*/device/oled*_img files control
OLED mocro displays on Intuos4 Wireless tablet. Accepted image
has to contain 256 bytes (64x32 px 1 bit colour). The format
is the same as PBM image 62x32px without header (64 bits per
horizontal line, 32 lines). An example of setting OLED No. 0:
dd bs=256 count=1 if=img_file of=[path to oled0_img]/oled0_img
The attribute is read only and no local copy of the image is
stored.
What: /sys/class/hidraw/hidraw*/device/speed
What: /sys/bus/hid/devices/<bus>:<vid>:<pid>.<n>/speed
Date: April 2010
Kernel Version: 2.6.35
Contact: linux-bluetooth@vger.kernel.org
Description:
The /sys/class/hidraw/hidraw*/device/speed file controls
reporting speed of Wacom bluetooth tablet. Reading from
this file returns 1 if tablet reports in high speed mode
The /sys/bus/hid/devices/<bus>:<vid>:<pid>.<n>/speed file
controls reporting speed of Wacom bluetooth tablet. Reading
from this file returns 1 if tablet reports in high speed mode
or 0 otherwise. Writing to this file one of these values
switches reporting speed.
What: /sys/class/leds/0005\:056A\:00BD.0001\:selector\:*/
Date: May 2012
Kernel Version: 3.5
Contact: linux-bluetooth@vger.kernel.org
Description:
LED selector for Intuos4 WL. There are 4 leds, but only one LED
can be lit at a time. Max brightness is 127.
What: /sys/bus/usb/devices/<busnum>-<devnum>:<cfg>.<intf>/wacom_led/led
Date: August 2011
What: /sys/bus/hid/devices/<bus>:<vid>:<pid>.<n>/wacom_led/led
Date: August 2014
Contact: linux-input@vger.kernel.org
Description:
Attribute group for control of the status LEDs and the OLEDs.
This attribute group is only available for Intuos 4 M, L,
and XL (with LEDs and OLEDs), Intuos 5 (LEDs only), and Cintiq
21UX2 and Cintiq 24HD (LEDs only). Therefore its presence
implicitly signifies the presence of said LEDs and OLEDs on the
tablet device.
and XL (with LEDs and OLEDs), Intuos 4 WL, Intuos 5 (LEDs only),
Intuos Pro (LEDs only) and Cintiq 21UX2 and Cintiq 24HD
(LEDs only). Therefore its presence implicitly signifies the
presence of said LEDs and OLEDs on the tablet device.
What: /sys/bus/usb/devices/<busnum>-<devnum>:<cfg>.<intf>/wacom_led/status0_luminance
Date: August 2011
What: /sys/bus/hid/devices/<bus>:<vid>:<pid>.<n>/wacom_led/status0_luminance
Date: August 2014
Contact: linux-input@vger.kernel.org
Description:
Writing to this file sets the status LED luminance (1..127)
@@ -50,16 +29,16 @@ Description:
button is pressed on the stylus. This luminance level is
normally lower than the level when a button is pressed.
What: /sys/bus/usb/devices/<busnum>-<devnum>:<cfg>.<intf>/wacom_led/status1_luminance
Date: August 2011
What: /sys/bus/hid/devices/<bus>:<vid>:<pid>.<n>/wacom_led/status1_luminance
Date: August 2014
Contact: linux-input@vger.kernel.org
Description:
Writing to this file sets the status LED luminance (1..127)
when the stylus touches the tablet surface, or any button is
pressed on the stylus.
What: /sys/bus/usb/devices/<busnum>-<devnum>:<cfg>.<intf>/wacom_led/status_led0_select
Date: August 2011
What: /sys/bus/hid/devices/<bus>:<vid>:<pid>.<n>/wacom_led/status_led0_select
Date: August 2014
Contact: linux-input@vger.kernel.org
Description:
Writing to this file sets which one of the four (for Intuos 4
@@ -67,23 +46,23 @@ Description:
24HD) status LEDs is active (0..3). The other three LEDs on the
same side are always inactive.
What: /sys/bus/usb/devices/<busnum>-<devnum>:<cfg>.<intf>/wacom_led/status_led1_select
Date: September 2011
What: /sys/bus/hid/devices/<bus>:<vid>:<pid>.<n>/wacom_led/status_led1_select
Date: August 2014
Contact: linux-input@vger.kernel.org
Description:
Writing to this file sets which one of the left four (for Cintiq 21UX2
and Cintiq 24HD) status LEDs is active (0..3). The other three LEDs on
the left are always inactive.
What: /sys/bus/usb/devices/<busnum>-<devnum>:<cfg>.<intf>/wacom_led/buttons_luminance
Date: August 2011
What: /sys/bus/hid/devices/<bus>:<vid>:<pid>.<n>/wacom_led/buttons_luminance
Date: August 2014
Contact: linux-input@vger.kernel.org
Description:
Writing to this file sets the overall luminance level (0..15)
of all eight button OLED displays.
What: /sys/bus/usb/devices/<busnum>-<devnum>:<cfg>.<intf>/wacom_led/button<n>_rawimg
Date: August 2011
What: /sys/bus/hid/devices/<bus>:<vid>:<pid>.<n>/wacom_led/button<n>_rawimg
Date: August 2014
Contact: linux-input@vger.kernel.org
Description:
When writing a 1024 byte raw image in Wacom Intuos 4
@@ -93,3 +72,8 @@ Description:
byte chunk encodes the image data for two consecutive lines on
the display. The low nibble of each byte contains the first
line, and the high nibble contains the second line.
When the Wacom Intuos 4 is connected over Bluetooth, the
image has to contain 256 bytes (64x32 px 1 bit colour).
The format is also scrambled, like in the USB mode, and it can
be summarized by converting 76543210 into GECA6420.
HGFEDCBA HFDB7531

269
Documentation/ABI/testing/sysfs-fs-nilfs2 Normal file
View File

@@ -0,0 +1,269 @@
What: /sys/fs/nilfs2/features/revision
Date: April 2014
Contact: "Vyacheslav Dubeyko" <slava@dubeyko.com>
Description:
Show current revision of NILFS file system driver.
This value informs about file system revision that
driver is ready to support.
What: /sys/fs/nilfs2/features/README
Date: April 2014
Contact: "Vyacheslav Dubeyko" <slava@dubeyko.com>
Description:
Describe attributes of /sys/fs/nilfs2/features group.
What: /sys/fs/nilfs2/<device>/revision
Date: April 2014
Contact: "Vyacheslav Dubeyko" <slava@dubeyko.com>
Description:
Show NILFS file system revision on volume.
This value informs about metadata structures'
revision on mounted volume.
What: /sys/fs/nilfs2/<device>/blocksize
Date: April 2014
Contact: "Vyacheslav Dubeyko" <slava@dubeyko.com>
Description:
Show volume's block size in bytes.
What: /sys/fs/nilfs2/<device>/device_size
Date: April 2014
Contact: "Vyacheslav Dubeyko" <slava@dubeyko.com>
Description:
Show volume size in bytes.
What: /sys/fs/nilfs2/<device>/free_blocks
Date: April 2014
Contact: "Vyacheslav Dubeyko" <slava@dubeyko.com>
Description:
Show count of free blocks on volume.
What: /sys/fs/nilfs2/<device>/uuid
Date: April 2014
Contact: "Vyacheslav Dubeyko" <slava@dubeyko.com>
Description:
Show volume's UUID (Universally Unique Identifier).
What: /sys/fs/nilfs2/<device>/volume_name
Date: April 2014
Contact: "Vyacheslav Dubeyko" <slava@dubeyko.com>
Description:
Show volume's label.
What: /sys/fs/nilfs2/<device>/README
Date: April 2014
Contact: "Vyacheslav Dubeyko" <slava@dubeyko.com>
Description:
Describe attributes of /sys/fs/nilfs2/<device> group.
What: /sys/fs/nilfs2/<device>/superblock/sb_write_time
Date: April 2014
Contact: "Vyacheslav Dubeyko" <slava@dubeyko.com>
Description:
Show last write time of super block in human-readable
format.
What: /sys/fs/nilfs2/<device>/superblock/sb_write_time_secs
Date: April 2014
Contact: "Vyacheslav Dubeyko" <slava@dubeyko.com>
Description:
Show last write time of super block in seconds.
What: /sys/fs/nilfs2/<device>/superblock/sb_write_count
Date: April 2014
Contact: "Vyacheslav Dubeyko" <slava@dubeyko.com>
Description:
Show current write count of super block.
What: /sys/fs/nilfs2/<device>/superblock/sb_update_frequency
Date: April 2014
Contact: "Vyacheslav Dubeyko" <slava@dubeyko.com>
Description:
Show/Set interval of periodical update of superblock
(in seconds).
What: /sys/fs/nilfs2/<device>/superblock/README
Date: April 2014
Contact: "Vyacheslav Dubeyko" <slava@dubeyko.com>
Description:
Describe attributes of /sys/fs/nilfs2/<device>/superblock
group.
What: /sys/fs/nilfs2/<device>/segctor/last_pseg_block
Date: April 2014
Contact: "Vyacheslav Dubeyko" <slava@dubeyko.com>
Description:
Show start block number of the latest segment.
What: /sys/fs/nilfs2/<device>/segctor/last_seg_sequence
Date: April 2014
Contact: "Vyacheslav Dubeyko" <slava@dubeyko.com>
Description:
Show sequence value of the latest segment.
What: /sys/fs/nilfs2/<device>/segctor/last_seg_checkpoint
Date: April 2014
Contact: "Vyacheslav Dubeyko" <slava@dubeyko.com>
Description:
Show checkpoint number of the latest segment.
What: /sys/fs/nilfs2/<device>/segctor/current_seg_sequence
Date: April 2014
Contact: "Vyacheslav Dubeyko" <slava@dubeyko.com>
Description:
Show segment sequence counter.
What: /sys/fs/nilfs2/<device>/segctor/current_last_full_seg
Date: April 2014
Contact: "Vyacheslav Dubeyko" <slava@dubeyko.com>
Description:
Show index number of the latest full segment.
What: /sys/fs/nilfs2/<device>/segctor/next_full_seg
Date: April 2014
Contact: "Vyacheslav Dubeyko" <slava@dubeyko.com>
Description:
Show index number of the full segment index
to be used next.
What: /sys/fs/nilfs2/<device>/segctor/next_pseg_offset
Date: April 2014
Contact: "Vyacheslav Dubeyko" <slava@dubeyko.com>
Description:
Show offset of next partial segment in the current
full segment.
What: /sys/fs/nilfs2/<device>/segctor/next_checkpoint
Date: April 2014
Contact: "Vyacheslav Dubeyko" <slava@dubeyko.com>
Description:
Show next checkpoint number.
What: /sys/fs/nilfs2/<device>/segctor/last_seg_write_time
Date: April 2014
Contact: "Vyacheslav Dubeyko" <slava@dubeyko.com>
Description:
Show write time of the last segment in
human-readable format.
What: /sys/fs/nilfs2/<device>/segctor/last_seg_write_time_secs
Date: April 2014
Contact: "Vyacheslav Dubeyko" <slava@dubeyko.com>
Description:
Show write time of the last segment in seconds.
What: /sys/fs/nilfs2/<device>/segctor/last_nongc_write_time
Date: April 2014
Contact: "Vyacheslav Dubeyko" <slava@dubeyko.com>
Description:
Show write time of the last segment not for cleaner
operation in human-readable format.
What: /sys/fs/nilfs2/<device>/segctor/last_nongc_write_time_secs
Date: April 2014
Contact: "Vyacheslav Dubeyko" <slava@dubeyko.com>
Description:
Show write time of the last segment not for cleaner
operation in seconds.
What: /sys/fs/nilfs2/<device>/segctor/dirty_data_blocks_count
Date: April 2014
Contact: "Vyacheslav Dubeyko" <slava@dubeyko.com>
Description:
Show number of dirty data blocks.
What: /sys/fs/nilfs2/<device>/segctor/README
Date: April 2014
Contact: "Vyacheslav Dubeyko" <slava@dubeyko.com>
Description:
Describe attributes of /sys/fs/nilfs2/<device>/segctor
group.
What: /sys/fs/nilfs2/<device>/segments/segments_number
Date: April 2014
Contact: "Vyacheslav Dubeyko" <slava@dubeyko.com>
Description:
Show number of segments on a volume.
What: /sys/fs/nilfs2/<device>/segments/blocks_per_segment
Date: April 2014
Contact: "Vyacheslav Dubeyko" <slava@dubeyko.com>
Description:
Show number of blocks in segment.
What: /sys/fs/nilfs2/<device>/segments/clean_segments
Date: April 2014
Contact: "Vyacheslav Dubeyko" <slava@dubeyko.com>
Description:
Show count of clean segments.
What: /sys/fs/nilfs2/<device>/segments/dirty_segments
Date: April 2014
Contact: "Vyacheslav Dubeyko" <slava@dubeyko.com>
Description:
Show count of dirty segments.
What: /sys/fs/nilfs2/<device>/segments/README
Date: April 2014
Contact: "Vyacheslav Dubeyko" <slava@dubeyko.com>
Description:
Describe attributes of /sys/fs/nilfs2/<device>/segments
group.
What: /sys/fs/nilfs2/<device>/checkpoints/checkpoints_number
Date: April 2014
Contact: "Vyacheslav Dubeyko" <slava@dubeyko.com>
Description:
Show number of checkpoints on volume.
What: /sys/fs/nilfs2/<device>/checkpoints/snapshots_number
Date: April 2014
Contact: "Vyacheslav Dubeyko" <slava@dubeyko.com>
Description:
Show number of snapshots on volume.
What: /sys/fs/nilfs2/<device>/checkpoints/last_seg_checkpoint
Date: April 2014
Contact: "Vyacheslav Dubeyko" <slava@dubeyko.com>
Description:
Show checkpoint number of the latest segment.
What: /sys/fs/nilfs2/<device>/checkpoints/next_checkpoint
Date: April 2014
Contact: "Vyacheslav Dubeyko" <slava@dubeyko.com>
Description:
Show next checkpoint number.
What: /sys/fs/nilfs2/<device>/checkpoints/README
Date: April 2014
Contact: "Vyacheslav Dubeyko" <slava@dubeyko.com>
Description:
Describe attributes of /sys/fs/nilfs2/<device>/checkpoints
group.
What: /sys/fs/nilfs2/<device>/mounted_snapshots/README
Date: April 2014
Contact: "Vyacheslav Dubeyko" <slava@dubeyko.com>
Description:
Describe content of /sys/fs/nilfs2/<device>/mounted_snapshots
group.
What: /sys/fs/nilfs2/<device>/mounted_snapshots/<id>/inodes_count
Date: April 2014
Contact: "Vyacheslav Dubeyko" <slava@dubeyko.com>
Description:
Show number of inodes for snapshot.
What: /sys/fs/nilfs2/<device>/mounted_snapshots/<id>/blocks_count
Date: April 2014
Contact: "Vyacheslav Dubeyko" <slava@dubeyko.com>
Description:
Show number of blocks for snapshot.
What: /sys/fs/nilfs2/<device>/mounted_snapshots/<id>/README
Date: April 2014
Contact: "Vyacheslav Dubeyko" <slava@dubeyko.com>
Description:
Describe attributes of /sys/fs/nilfs2/<device>/mounted_snapshots/<id>
group.

39
Documentation/ABI/testing/sysfs-fs-xfs Normal file
View File

@@ -0,0 +1,39 @@
What: /sys/fs/xfs/<disk>/log/log_head_lsn
Date: July 2014
KernelVersion: 3.17
Contact: xfs@oss.sgi.com
Description:
The log sequence number (LSN) of the current head of the
log. The LSN is exported in "cycle:basic block" format.
Users: xfstests
What: /sys/fs/xfs/<disk>/log/log_tail_lsn
Date: July 2014
KernelVersion: 3.17
Contact: xfs@oss.sgi.com
Description:
The log sequence number (LSN) of the current tail of the
log. The LSN is exported in "cycle:basic block" format.
What: /sys/fs/xfs/<disk>/log/reserve_grant_head
Date: July 2014
KernelVersion: 3.17
Contact: xfs@oss.sgi.com
Description:
The current state of the log reserve grant head. It
represents the total log reservation of all currently
outstanding transactions. The grant head is exported in
"cycle:bytes" format.
Users: xfstests
What: /sys/fs/xfs/<disk>/log/write_grant_head
Date: July 2014
KernelVersion: 3.17
Contact: xfs@oss.sgi.com
Description:
The current state of the log write grant head. It
represents the total log reservation of all currently
oustanding transactions, including regrants due to
rolling transactions. The grant head is exported in
"cycle:bytes" format.
Users: xfstests

7
Documentation/ABI/testing/sysfs-platform-ts5500
View File

@@ -30,6 +30,13 @@ Description:
the corresponding bit is set. For instance, 0x0e means jumpers
2, 3 and 4 are set.
What: /sys/devices/platform/ts5500/name
Date: July 2014
KernelVersion: 3.16
Contact: "Savoir-faire Linux Inc." <kernel@savoirfairelinux.com>
Description:
Model name of the TS board, e.g. "TS-5500".
What: /sys/devices/platform/ts5500/rs485
Date: January 2013
KernelVersion: 3.7

16
Documentation/ABI/testing/sysfs-tty
View File

@@ -138,3 +138,19 @@ Description:
These sysfs values expose the TIOCGSERIAL interface via
sysfs rather than via ioctls.
What: /sys/class/tty/ttyS0/rx_trig_bytes
Date: May 2014
Contact: Yoshihiro YUNOMAE <yoshihiro.yunomae.ez@hitachi.com>
Description:
Shows current RX interrupt trigger bytes or sets the
user specified value to change it for the FIFO buffer.
Users can show or set this value regardless of opening the
serial device file or not.
The RX trigger can be set one of four kinds of values for UART
serials. When users input a meaning less value to this I/F,
the RX trigger is changed to the nearest lower value for the
device specification. For example, when user sets 7bytes on
16550A, which has 1/4/8/14 bytes trigger, the RX trigger is
automatically changed to 4 bytes.

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

@@ -54,7 +54,7 @@
!Ikernel/sched/cpupri.c
!Ikernel/sched/fair.c
!Iinclude/linux/completion.h
!Ekernel/timer.c
!Ekernel/time/timer.c
</sect1>
<sect1><title>Wait queues and Wake events</title>
!Iinclude/linux/wait.h
@@ -63,7 +63,7 @@
<sect1><title>High-resolution timers</title>
!Iinclude/linux/ktime.h
!Iinclude/linux/hrtimer.h
!Ekernel/hrtimer.c
!Ekernel/time/hrtimer.c
</sect1>
<sect1><title>Workqueues and Kevents</title>
!Ekernel/workqueue.c
@@ -128,8 +128,12 @@ X!Edrivers/base/interface.c
!Edrivers/base/bus.c
</sect1>
<sect1><title>Device Drivers DMA Management</title>
!Edrivers/base/dma-buf.c
!Edrivers/base/reservation.c
!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
!Edrivers/dma-buf/reservation.c
!Iinclude/linux/reservation.h
!Edrivers/base/dma-coherent.c
!Edrivers/base/dma-mapping.c

91
Documentation/DocBook/drm.tmpl
View File

@@ -315,7 +315,7 @@ char *date;</synopsis>
<function>drm_dev_unregister()</function> followed by a call to
<function>drm_dev_unref()</function>.
</para>
!Edrivers/gpu/drm/drm_stub.c
!Edrivers/gpu/drm/drm_drv.c
</sect2>
<sect2>
<title>Driver Load</title>
@@ -1610,7 +1610,7 @@ int max_width, max_height;</synopsis>
The connector is then registered with a call to
<function>drm_connector_init</function> with a pointer to the connector
functions and a connector type, and exposed through sysfs with a call to
<function>drm_sysfs_connector_add</function>.
<function>drm_connector_register</function>.
</para>
<para>
Supported connector types are
@@ -1768,7 +1768,7 @@ int max_width, max_height;</synopsis>
(<function>drm_encoder_cleanup</function>) and connectors
(<function>drm_connector_cleanup</function>). Furthermore, connectors
that have been added to sysfs must be removed by a call to
<function>drm_sysfs_connector_remove</function> before calling
<function>drm_connector_unregister</function> before calling
<function>drm_connector_cleanup</function>.
</para>
<para>
@@ -1813,7 +1813,7 @@ void intel_crt_init(struct drm_device *dev)
drm_encoder_helper_add(&intel_output->enc, &intel_crt_helper_funcs);
drm_connector_helper_add(connector, &intel_crt_connector_helper_funcs);
drm_sysfs_connector_add(connector);
drm_connector_register(connector);
}]]></programlisting>
<para>
In the example above (taken from the i915 driver), a CRTC, connector and
@@ -2336,6 +2336,12 @@ void intel_crt_init(struct drm_device *dev)
!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 MST Helper Functions Reference</title>
!Pdrivers/gpu/drm/drm_dp_mst_topology.c dp mst helper
!Iinclude/drm/drm_dp_mst_helper.h
!Edrivers/gpu/drm/drm_dp_mst_topology.c
</sect2>
<sect2>
<title>EDID Helper Functions Reference</title>
@@ -2502,7 +2508,7 @@ void intel_crt_init(struct drm_device *dev)
<td valign="top" >Description/Restrictions</td>
</tr>
<tr>
<td rowspan="20" valign="top" >DRM</td>
<td rowspan="21" valign="top" >DRM</td>
<td rowspan="2" valign="top" >Generic</td>
<td valign="top" >“EDID”</td>
<td valign="top" >BLOB | IMMUTABLE</td>
@@ -2633,7 +2639,7 @@ void intel_crt_init(struct drm_device *dev)
<td valign="top" >TBD</td>
</tr>
<tr>
<td rowspan="2" valign="top" >Optional</td>
<td rowspan="3" valign="top" >Optional</td>
<td valign="top" >“scaling mode”</td>
<td valign="top" >ENUM</td>
<td valign="top" >{ "None", "Full", "Center", "Full aspect" }</td>
@@ -2641,6 +2647,15 @@ void intel_crt_init(struct drm_device *dev)
<td valign="top" >TBD</td>
</tr>
<tr>
<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>
</tr>
<tr>
<td valign="top" >“dirty”</td>
<td valign="top" >ENUM | IMMUTABLE</td>
<td valign="top" >{ "Off", "On", "Annotate" }</td>
@@ -2649,7 +2664,7 @@ void intel_crt_init(struct drm_device *dev)
</tr>
<tr>
<td rowspan="21" valign="top" >i915</td>
<td rowspan="3" valign="top" >Generic</td>
<td rowspan="2" valign="top" >Generic</td>
<td valign="top" >"Broadcast RGB"</td>
<td valign="top" >ENUM</td>
<td valign="top" >{ "Automatic", "Full", "Limited 16:235" }</td>
@@ -2664,10 +2679,11 @@ void intel_crt_init(struct drm_device *dev)
<td valign="top" >TBD</td>
</tr>
<tr>
<td valign="top" >Standard name as in DRM</td>
<td valign="top" >Standard type as in DRM</td>
<td valign="top" >Standard value as in DRM</td>
<td valign="top" >Standard Object as in DRM</td>
<td rowspan="1" valign="top" >Plane</td>
<td valign="top" >“rotation”</td>
<td valign="top" >BITMASK</td>
<td valign="top" >{ 0, "rotate-0" }, { 2, "rotate-180" }</td>
<td valign="top" >Plane</td>
<td valign="top" >TBD</td>
</tr>
<tr>
@@ -2799,8 +2815,8 @@ void intel_crt_init(struct drm_device *dev)
<td valign="top" >TBD</td>
</tr>
<tr>
<td rowspan="3" valign="top" >CDV gma-500</td>
<td rowspan="3" valign="top" >Generic</td>
<td rowspan="2" valign="top" >CDV gma-500</td>
<td rowspan="2" valign="top" >Generic</td>
<td valign="top" >"Broadcast RGB"</td>
<td valign="top" >ENUM</td>
<td valign="top" >{ “Full”, “Limited 16:235” }</td>
@@ -2815,15 +2831,8 @@ void intel_crt_init(struct drm_device *dev)
<td valign="top" >TBD</td>
</tr>
<tr>
<td valign="top" >Standard name as in DRM</td>
<td valign="top" >Standard type as in DRM</td>
<td valign="top" >Standard value as in DRM</td>
<td valign="top" >Standard Object as in DRM</td>
<td valign="top" >TBD</td>
</tr>
<tr>
<td rowspan="20" valign="top" >Poulsbo</td>
<td rowspan="2" valign="top" >Generic</td>
<td rowspan="19" valign="top" >Poulsbo</td>
<td rowspan="1" valign="top" >Generic</td>
<td valign="top" >“backlight”</td>
<td valign="top" >RANGE</td>
<td valign="top" >Min=0, Max=100</td>
@@ -2831,13 +2840,6 @@ void intel_crt_init(struct drm_device *dev)
<td valign="top" >TBD</td>
</tr>
<tr>
<td valign="top" >Standard name as in DRM</td>
<td valign="top" >Standard type as in DRM</td>
<td valign="top" >Standard value as in DRM</td>
<td valign="top" >Standard Object as in DRM</td>
<td valign="top" >TBD</td>
</tr>
<tr>
<td rowspan="17" valign="top" >SDVO-TV</td>
<td valign="top" >“mode”</td>
<td valign="top" >ENUM</td>
@@ -3064,7 +3066,7 @@ void intel_crt_init(struct drm_device *dev)
<td valign="top" >TBD</td>
</tr>
<tr>
<td rowspan="3" valign="top" >i2c/ch7006_drv</td>
<td rowspan="2" valign="top" >i2c/ch7006_drv</td>
<td valign="top" >Generic</td>
<td valign="top" >“scale”</td>
<td valign="top" >RANGE</td>
@@ -3073,14 +3075,7 @@ void intel_crt_init(struct drm_device *dev)
<td valign="top" >TBD</td>
</tr>
<tr>
<td rowspan="2" valign="top" >TV</td>
<td valign="top" >Standard names as in DRM</td>
<td valign="top" >Standard types as in DRM</td>
<td valign="top" >Standard Values as in DRM</td>
<td valign="top" >Standard object as in DRM</td>
<td valign="top" >TBD</td>
</tr>
<tr>
<td rowspan="1" valign="top" >TV</td>
<td valign="top" >“mode”</td>
<td valign="top" >ENUM</td>
<td valign="top" >{ "PAL", "PAL-M","PAL-N"}, ”PAL-Nc"
@@ -3089,7 +3084,7 @@ void intel_crt_init(struct drm_device *dev)
<td valign="top" >TBD</td>
</tr>
<tr>
<td rowspan="16" valign="top" >nouveau</td>
<td rowspan="15" valign="top" >nouveau</td>
<td rowspan="6" valign="top" >NV10 Overlay</td>
<td valign="top" >"colorkey"</td>
<td valign="top" >RANGE</td>
@@ -3198,14 +3193,6 @@ void intel_crt_init(struct drm_device *dev)
<td valign="top" >TBD</td>
</tr>
<tr>
<td valign="top" >Generic</td>
<td valign="top" >Standard name as in DRM</td>
<td valign="top" >Standard type as in DRM</td>
<td valign="top" >Standard value as in DRM</td>
<td valign="top" >Standard Object as in DRM</td>
<td valign="top" >TBD</td>
</tr>
<tr>
<td rowspan="2" valign="top" >omap</td>
<td rowspan="2" valign="top" >Generic</td>
<td valign="top" >“rotation”</td>
@@ -3236,7 +3223,7 @@ void intel_crt_init(struct drm_device *dev)
<td valign="top" >TBD</td>
</tr>
<tr>
<td rowspan="10" valign="top" >radeon</td>
<td rowspan="9" valign="top" >radeon</td>
<td valign="top" >DVI-I</td>
<td valign="top" >“coherent”</td>
<td valign="top" >RANGE</td>
@@ -3308,14 +3295,6 @@ void intel_crt_init(struct drm_device *dev)
<td valign="top" >TBD</td>
</tr>
<tr>
<td valign="top" >Generic</td>
<td valign="top" >Standard name as in DRM</td>
<td valign="top" >Standard type as in DRM</td>
<td valign="top" >Standard value as in DRM</td>
<td valign="top" >Standard Object as in DRM</td>
<td valign="top" >TBD</td>
</tr>
<tr>
<td rowspan="3" valign="top" >rcar-du</td>
<td rowspan="3" valign="top" >Generic</td>
<td valign="top" >"alpha"</td>

10
Documentation/DocBook/gadget.tmpl
View File

@@ -556,11 +556,11 @@ been converted to this framework.
Near-term plans include converting all of them, except for "gadgetfs".
</para>
!Edrivers/usb/gadget/f_acm.c
!Edrivers/usb/gadget/f_ecm.c
!Edrivers/usb/gadget/f_subset.c
!Edrivers/usb/gadget/f_obex.c
!Edrivers/usb/gadget/f_serial.c
!Edrivers/usb/gadget/function/f_acm.c
!Edrivers/usb/gadget/function/f_ecm.c
!Edrivers/usb/gadget/function/f_subset.c
!Edrivers/usb/gadget/function/f_obex.c
!Edrivers/usb/gadget/function/f_serial.c
</sect1>

2
Documentation/PCI/MSI-HOWTO.txt
View File

@@ -576,7 +576,7 @@ Some devices are known to have faulty MSI implementations. Usually this
is handled in the individual device driver, but occasionally it's necessary
to handle this with a quirk. Some drivers have an option to disable use
of MSI. While this is a convenient workaround for the driver author,
it is not good practise, and should not be emulated.
it is not good practice, and should not be emulated.
5.4. Finding why MSIs are disabled on a device

4
Documentation/RCU/RTFP.txt
View File

@@ -2451,8 +2451,8 @@ lot of {Linux} into your technology!!!"
,month="February"
,year="2010"
,note="Available:
\url{http://kerneltrap.com/mailarchive/linux-netdev/2010/2/26/6270589}
[Viewed March 20, 2011]"
\url{http://thread.gmane.org/gmane.linux.network/153338}
[Viewed June 9, 2014]"
,annotation={
Use a pair of list_head structures to support RCU-protected
resizable hash tables.

9
Documentation/RCU/rcuref.txt
View File

@@ -1,5 +1,14 @@
Reference-count design for elements of lists/arrays protected by RCU.
Please note that the percpu-ref feature is likely your first
stop if you need to combine reference counts and RCU. Please see
include/linux/percpu-refcount.h for more information. However, in
those unusual cases where percpu-ref would consume too much memory,
please read on.
------------------------------------------------------------------------
Reference counting on elements of lists which are protected by traditional
reader/writer spinlocks or semaphores are straightforward:

2
Documentation/RCU/whatisRCU.txt
View File

@@ -818,7 +818,7 @@ RCU pointer/list update:
list_add_tail_rcu
list_del_rcu
list_replace_rcu
hlist_add_after_rcu
hlist_add_behind_rcu
hlist_add_before_rcu
hlist_add_head_rcu
hlist_del_rcu

4
Documentation/SubmittingDrivers
View File

@@ -146,10 +146,6 @@ LWN.net:
Porting drivers from prior kernels to 2.6:
http://lwn.net/Articles/driver-porting/
KernelTrap:
Occasional Linux kernel articles and developer interviews
http://kerneltrap.org/
KernelNewbies:
Documentation and assistance for new kernel programmers
http://kernelnewbies.org/

40
Documentation/SubmittingPatches
View File

@@ -84,18 +84,42 @@ is another popular alternative.
2) Describe your changes.
Describe the technical detail of the change(s) your patch includes.
Describe your problem. Whether your patch is a one-line bug fix or
5000 lines of a new feature, there must be an underlying problem that
motivated you to do this work. Convince the reviewer that there is a
problem worth fixing and that it makes sense for them to read past the
first paragraph.
Be as specific as possible. The WORST descriptions possible include
things like "update driver X", "bug fix for driver X", or "this patch
includes updates for subsystem X. Please apply."
Describe user-visible impact. Straight up crashes and lockups are
pretty convincing, but not all bugs are that blatant. Even if the
problem was spotted during code review, describe the impact you think
it can have on users. Keep in mind that the majority of Linux
installations run kernels from secondary stable trees or
vendor/product-specific trees that cherry-pick only specific patches
from upstream, so include anything that could help route your change
downstream: provoking circumstances, excerpts from dmesg, crash
descriptions, performance regressions, latency spikes, lockups, etc.
Quantify optimizations and trade-offs. If you claim improvements in
performance, memory consumption, stack footprint, or binary size,
include numbers that back them up. But also describe non-obvious
costs. Optimizations usually aren't free but trade-offs between CPU,
memory, and readability; or, when it comes to heuristics, between
different workloads. Describe the expected downsides of your
optimization so that the reviewer can weigh costs against benefits.
Once the problem is established, describe what you are actually doing
about it in technical detail. It's important to describe the change
in plain English for the reviewer to verify that the code is behaving
as you intend it to.
The maintainer will thank you if you write your patch description in a
form which can be easily pulled into Linux's source code management
system, git, as a "commit log". See #15, below.
If your description starts to get long, that's a sign that you probably
need to split up your patch. See #3, next.
Solve only one problem per patch. If your description starts to get
long, that's a sign that you probably need to split up your patch.
See #3, next.
When you submit or resubmit a patch or patch series, include the
complete patch description and justification for it. Don't just
@@ -396,13 +420,13 @@ you are responsible for last-minute changes. Example :
[lucky@maintainer.example.org: struct foo moved from foo.c to foo.h]
Signed-off-by: Lucky K Maintainer <lucky@maintainer.example.org>
This practise is particularly helpful if you maintain a stable branch and
This practice is particularly helpful if you maintain a stable branch and
want at the same time to credit the author, track changes, merge the fix,
and protect the submitter from complaints. Note that under no circumstances
can you change the author's identity (the From header), as it is the one
which appears in the changelog.
Special note to back-porters: It seems to be a common and useful practise
Special note to back-porters: It seems to be a common and useful practice
to insert an indication of the origin of a patch at the top of the commit
message (just after the subject line) to facilitate tracking. For instance,
here's what we see in 2.6-stable :

52
Documentation/arm/CCN.txt Normal file
View File

@@ -0,0 +1,52 @@
ARM Cache Coherent Network
==========================
CCN-504 is a ring-bus interconnect consisting of 11 crosspoints
(XPs), with each crosspoint supporting up to two device ports,
so nodes (devices) 0 and 1 are connected to crosspoint 0,
nodes 2 and 3 to crosspoint 1 etc.
PMU (perf) driver
-----------------
The CCN driver registers a perf PMU driver, which provides
description of available events and configuration options
in sysfs, see /sys/bus/event_source/devices/ccn*.
The "format" directory describes format of the config, config1
and config2 fields of the perf_event_attr structure. The "events"
directory provides configuration templates for all documented
events, that can be used with perf tool. For example "xp_valid_flit"
is an equivalent of "type=0x8,event=0x4". Other parameters must be
explicitly specified. For events originating from device, "node"
defines its index. All crosspoint events require "xp" (index),
"port" (device port number) and "vc" (virtual channel ID) and
"dir" (direction). Watchpoints (special "event" value 0xfe) also
require comparator values ("cmp_l" and "cmp_h") and "mask", being
index of the comparator mask.
Masks are defined separately from the event description
(due to limited number of the config values) in the "cmp_mask"
directory, with first 8 configurable by user and additional
4 hardcoded for the most frequent use cases.
Cycle counter is described by a "type" value 0xff and does
not require any other settings.
Example of perf tool use:
/ # perf list | grep ccn
ccn/cycles/ [Kernel PMU event]
<...>
ccn/xp_valid_flit/ [Kernel PMU event]
<...>
/ # perf stat -C 0 -e ccn/cycles/,ccn/xp_valid_flit,xp=1,port=0,vc=1,dir=1/ \
sleep 1
The driver does not support sampling, therefore "perf record" will
not work. Also notice that only single cpu is being selected
("-C 0") - this is because perf framework does not support
"non-CPU related" counters (yet?) so system-wide session ("-a")
would try (and in most cases fail) to set up the same event
per each CPU.

23
Documentation/arm/Marvell/README
View File

@@ -53,8 +53,8 @@ Kirkwood family
Functional Spec: http://www.marvell.com/embedded-processors/kirkwood/assets/FS_88F6180_9x_6281_OpenSource.pdf
Homepage: http://www.marvell.com/embedded-processors/kirkwood/
Core: Feroceon ARMv5 compatible
Linux kernel mach directory: arch/arm/mach-kirkwood
Linux kernel plat directory: arch/arm/plat-orion
Linux kernel mach directory: arch/arm/mach-mvebu
Linux kernel plat directory: none
Discovery family
----------------
@@ -83,7 +83,9 @@ EBU Armada family
88F6710
88F6707
88F6W11
Product Brief: http://www.marvell.com/embedded-processors/armada-300/assets/Marvell_ARMADA_370_SoC.pdf
Product Brief: http://www.marvell.com/embedded-processors/armada-300/assets/Marvell_ARMADA_370_SoC.pdf
Hardware Spec: http://www.marvell.com/embedded-processors/armada-300/assets/ARMADA370-datasheet.pdf
Functional Spec: http://www.marvell.com/embedded-processors/armada-300/assets/ARMADA370-FunctionalSpec-datasheet.pdf
Armada 375 Flavors:
88F6720
@@ -100,8 +102,7 @@ EBU Armada family
MV78460
NOTE: not to be confused with the non-SMP 78xx0 SoCs
Product Brief: http://www.marvell.com/embedded-processors/armada-xp/assets/Marvell-ArmadaXP-SoC-product%20brief.pdf
No public datasheet available.
Functional Spec: http://www.marvell.com/embedded-processors/armada-xp/assets/ARMADA-XP-Functional-SpecDatasheet.pdf
Core: Sheeva ARMv7 compatible
@@ -135,7 +136,9 @@ Dove family (application processor)
Functional Spec : http://www.marvell.com/application-processors/armada-500/assets/Armada-510-Functional-Spec.pdf
Homepage: http://www.marvell.com/application-processors/armada-500/
Core: ARMv7 compatible
Directory: arch/arm/mach-dove
Directory: arch/arm/mach-mvebu (DT enabled platforms)
arch/arm/mach-dove (non-DT enabled platforms)
PXA 2xx/3xx/93x/95x family
--------------------------
@@ -253,10 +256,10 @@ Berlin family (Digital Entertainment)
Long-term plans
---------------
* Unify the mach-dove/, mach-mv78xx0/, mach-orion5x/ and
mach-kirkwood/ into the mach-mvebu/ to support all SoCs from the
Marvell EBU (Engineering Business Unit) in a single mach-<foo>
directory. The plat-orion/ would therefore disappear.
* Unify the mach-dove/, mach-mv78xx0/, mach-orion5x/ into the
mach-mvebu/ to support all SoCs from the Marvell EBU (Engineering
Business Unit) in a single mach-<foo> directory. The plat-orion/
would therefore disappear.
* Unify the mach-mmp/ and mach-pxa/ into the same mach-pxa
directory. The plat-pxa/ would therefore disappear.

11
Documentation/arm/Samsung/Overview.txt
View File

@@ -13,8 +13,6 @@ Introduction
- S3C24XX: See Documentation/arm/Samsung-S3C24XX/Overview.txt for full list
- S3C64XX: S3C6400 and S3C6410
- S5P6440
- S5PC100
- S5PC110 / S5PV210
@@ -34,8 +32,6 @@ Configuration
A number of configurations are supplied, as there is no current way of
unifying all the SoCs into one kernel.
s5p6440_defconfig - S5P6440 specific default configuration
s5pc100_defconfig - S5PC100 specific default configuration
s5pc110_defconfig - S5PC110 specific default configuration
s5pv210_defconfig - S5PV210 specific default configuration
@@ -67,13 +63,6 @@ Layout changes
where to simplify the include and dependency issues involved with having
so many different platform directories.
It was decided to remove plat-s5pc1xx as some of the support was already
in plat-s5p or plat-samsung, with the S5PC110 support added with S5PV210
the only user was the S5PC100. The S5PC100 specific items where moved to
arch/arm/mach-s5pc100.
Port Contributors
-----------------

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

@@ -68,7 +68,6 @@ BEGIN {
while (getline line < ARGV[1] > 0) {
if (line ~ /\#define.*_MASK/ &&
!(line ~ /S5PC100_EPLL_MASK/) &&
!(line ~ /USB_SIG_MASK/)) {
splitdefine(line, fields)
name = fields[0]

51
Documentation/arm64/booting.txt
View File

@@ -72,27 +72,54 @@ The decompressed kernel image contains a 64-byte header as follows:
u32 code0; /* Executable code */
u32 code1; /* Executable code */
u64 text_offset; /* Image load offset */
u64 res0 = 0; /* reserved */
u64 res1 = 0; /* reserved */
u64 text_offset; /* Image load offset, little endian */
u64 image_size; /* Effective Image size, little endian */
u64 flags; /* kernel flags, little endian */
u64 res2 = 0; /* reserved */
u64 res3 = 0; /* reserved */
u64 res4 = 0; /* reserved */
u32 magic = 0x644d5241; /* Magic number, little endian, "ARM\x64" */
u32 res5 = 0; /* reserved */
u32 res5; /* reserved (used for PE COFF offset) */
Header notes:
- As of v3.17, all fields are little endian unless stated otherwise.
- code0/code1 are responsible for branching to stext.
- when booting through EFI, code0/code1 are initially skipped.
res5 is an offset to the PE header and the PE header has the EFI
entry point (efi_stub_entry). When the stub has done its work, it
entry point (efi_stub_entry). When the stub has done its work, it
jumps to code0 to resume the normal boot process.
The image must be placed at the specified offset (currently 0x80000)
from the start of the system RAM and called there. The start of the
system RAM must be aligned to 2MB.
- Prior to v3.17, the endianness of text_offset was not specified. In
these cases image_size is zero and text_offset is 0x80000 in the
endianness of the kernel. Where image_size is non-zero image_size is
little-endian and must be respected. Where image_size is zero,
text_offset can be assumed to be 0x80000.
- The flags field (introduced in v3.17) is a little-endian 64-bit field
composed as follows:
Bit 0: Kernel endianness. 1 if BE, 0 if LE.
Bits 1-63: Reserved.
- When image_size is zero, a bootloader should attempt to keep as much
memory as possible free for use by the kernel immediately after the
end of the kernel image. The amount of space required will vary
depending on selected features, and is effectively unbound.
The Image must be placed text_offset bytes from a 2MB aligned base
address near the start of usable system RAM and called there. Memory
below that base address is currently unusable by Linux, and therefore it
is strongly recommended that this location is the start of system RAM.
At least image_size bytes from the start of the image must be free for
use by the kernel.
Any memory described to the kernel (even that below the 2MB aligned base
address) which is not marked as reserved from the kernel e.g. with a
memreserve region in the device tree) will be considered as available to
the kernel.
Before jumping into the kernel, the following conditions must be met:
@@ -141,6 +168,14 @@ Before jumping into the kernel, the following conditions must be met:
the kernel image will be entered must be initialised by software at a
higher exception level to prevent execution in an UNKNOWN state.
For systems with a GICv3 interrupt controller:
- If EL3 is present:
ICC_SRE_EL3.Enable (bit 3) must be initialiased to 0b1.
ICC_SRE_EL3.SRE (bit 0) must be initialised to 0b1.
- If the kernel is entered at EL1:
ICC.SRE_EL2.Enable (bit 3) must be initialised to 0b1
ICC_SRE_EL2.SRE (bit 0) must be initialised to 0b1.
The requirements described above for CPU mode, caches, MMUs, architected
timers, coherency and system registers apply to all CPUs. All CPUs must
enter the kernel in the same exception level.

75
Documentation/arm64/memory.txt
View File

@@ -2,18 +2,18 @@
==============================
Author: Catalin Marinas <catalin.marinas@arm.com>
Date : 20 February 2012
This document describes the virtual memory layout used by the AArch64
Linux kernel. The architecture allows up to 4 levels of translation
tables with a 4KB page size and up to 3 levels with a 64KB page size.
AArch64 Linux uses 3 levels of translation tables with the 4KB page
configuration, allowing 39-bit (512GB) virtual addresses for both user
and kernel. With 64KB pages, only 2 levels of translation tables are
used but the memory layout is the same.
AArch64 Linux uses either 3 levels or 4 levels of translation tables
with the 4KB page configuration, allowing 39-bit (512GB) or 48-bit
(256TB) virtual addresses, respectively, for both user and kernel. With
64KB pages, only 2 levels of translation tables, allowing 42-bit (4TB)
virtual address, are used but the memory layout is the same.
User addresses have bits 63:39 set to 0 while the kernel addresses have
User addresses have bits 63:48 set to 0 while the kernel addresses have
the same bits set to 1. TTBRx selection is given by bit 63 of the
virtual address. The swapper_pg_dir contains only kernel (global)
mappings while the user pgd contains only user (non-global) mappings.
@@ -21,58 +21,40 @@ The swapper_pgd_dir address is written to TTBR1 and never written to
TTBR0.
AArch64 Linux memory layout with 4KB pages:
AArch64 Linux memory layout with 4KB pages + 3 levels:
Start End Size Use
-----------------------------------------------------------------------
0000000000000000 0000007fffffffff 512GB user
ffffff8000000000 ffffffbbfffeffff ~240GB vmalloc
ffffffbbffff0000 ffffffbbffffffff 64KB [guard page]
ffffffbc00000000 ffffffbdffffffff 8GB vmemmap
ffffffbe00000000 ffffffbffbbfffff ~8GB [guard, future vmmemap]
ffffffbffa000000 ffffffbffaffffff 16MB PCI I/O space
ffffffbffb000000 ffffffbffbbfffff 12MB [guard]
ffffffbffbc00000 ffffffbffbdfffff 2MB fixed mappings
ffffffbffbe00000 ffffffbffbffffff 2MB [guard]
ffffffbffc000000 ffffffbfffffffff 64MB modules
ffffffc000000000 ffffffffffffffff 256GB kernel logical memory map
ffffff8000000000 ffffffffffffffff 512GB kernel
AArch64 Linux memory layout with 64KB pages:
AArch64 Linux memory layout with 4KB pages + 4 levels:
Start End Size Use
-----------------------------------------------------------------------
0000000000000000 0000ffffffffffff 256TB user
ffff000000000000 ffffffffffffffff 256TB kernel
AArch64 Linux memory layout with 64KB pages + 2 levels:
Start End Size Use
-----------------------------------------------------------------------
0000000000000000 000003ffffffffff 4TB user
fffffc0000000000 ffffffffffffffff 4TB kernel
fffffc0000000000 fffffdfbfffeffff ~2TB vmalloc
fffffdfbffff0000 fffffdfbffffffff 64KB [guard page]
AArch64 Linux memory layout with 64KB pages + 3 levels:
fffffdfc00000000 fffffdfdffffffff 8GB vmemmap
Start End Size Use
-----------------------------------------------------------------------
0000000000000000 0000ffffffffffff 256TB user
ffff000000000000 ffffffffffffffff 256TB kernel
fffffdfe00000000 fffffdfffbbfffff ~8GB [guard, future vmmemap]
fffffdfffa000000 fffffdfffaffffff 16MB PCI I/O space
fffffdfffb000000 fffffdfffbbfffff 12MB [guard]
fffffdfffbc00000 fffffdfffbdfffff 2MB fixed mappings
fffffdfffbe00000 fffffdfffbffffff 2MB [guard]
fffffdfffc000000 fffffdffffffffff 64MB modules
fffffe0000000000 ffffffffffffffff 2TB kernel logical memory map
For details of the virtual kernel memory layout please see the kernel
booting log.
Translation table lookup with 4KB pages:
@@ -86,7 +68,7 @@ Translation table lookup with 4KB pages:
| | | | +-> [20:12] L3 index
| | | +-----------> [29:21] L2 index
| | +---------------------> [38:30] L1 index
| +-------------------------------> [47:39] L0 index (not used)
| +-------------------------------> [47:39] L0 index
+-------------------------------------------------> [63] TTBR0/1
@@ -99,10 +81,11 @@ Translation table lookup with 64KB pages:
| | | | v
| | | | [15:0] in-page offset
| | | +----------> [28:16] L3 index
| | +--------------------------> [41:29] L2 index (only 38:29 used)
| +-------------------------------> [47:42] L1 index (not used)
| | +--------------------------> [41:29] L2 index
| +-------------------------------> [47:42] L1 index
+-------------------------------------------------> [63] TTBR0/1
When using KVM, the hypervisor maps kernel pages in EL2, at a fixed
offset from the kernel VA (top 24bits of the kernel VA set to zero):

14
Documentation/cgroups/cgroups.txt
View File

@@ -599,6 +599,20 @@ fork. If this method returns 0 (success) then this should remain valid
while the caller holds cgroup_mutex and it is ensured that either
attach() or cancel_attach() will be called in future.
void css_reset(struct cgroup_subsys_state *css)
(cgroup_mutex held by caller)
An optional operation which should restore @css's configuration to the
initial state. This is currently only used on the unified hierarchy
when a subsystem is disabled on a cgroup through
"cgroup.subtree_control" but should remain enabled because other
subsystems depend on it. cgroup core makes such a css invisible by
removing the associated interface files and invokes this callback so
that the hidden subsystem can return to the initial neutral state.
This prevents unexpected resource control from a hidden css and
ensures that the configuration is in the initial state when it is made
visible again later.
void cancel_attach(struct cgroup *cgrp, struct cgroup_taskset *tset)
(cgroup_mutex held by caller)

158
Documentation/cgroups/memcg_test.txt
View File

@@ -24,64 +24,27 @@ Please note that implementation details can be changed.
a page/swp_entry may be charged (usage += PAGE_SIZE) at
mem_cgroup_charge_anon()
Called at new page fault and Copy-On-Write.
mem_cgroup_try_charge_swapin()
Called at do_swap_page() (page fault on swap entry) and swapoff.
Followed by charge-commit-cancel protocol. (With swap accounting)
At commit, a charge recorded in swap_cgroup is removed.
mem_cgroup_charge_file()
Called at add_to_page_cache()
mem_cgroup_cache_charge_swapin()
Called at shmem's swapin.
mem_cgroup_prepare_migration()
Called before migration. "extra" charge is done and followed by
charge-commit-cancel protocol.
At commit, charge against oldpage or newpage will be committed.
mem_cgroup_try_charge()
2. Uncharge
a page/swp_entry may be uncharged (usage -= PAGE_SIZE) by
mem_cgroup_uncharge_page()
Called when an anonymous page is fully unmapped. I.e., mapcount goes
to 0. If the page is SwapCache, uncharge is delayed until
mem_cgroup_uncharge_swapcache().
mem_cgroup_uncharge_cache_page()
Called when a page-cache is deleted from radix-tree. If the page is
SwapCache, uncharge is delayed until mem_cgroup_uncharge_swapcache().
mem_cgroup_uncharge_swapcache()
Called when SwapCache is removed from radix-tree. The charge itself
is moved to swap_cgroup. (If mem+swap controller is disabled, no
charge to swap occurs.)
mem_cgroup_uncharge()
Called when a page's refcount goes down to 0.
mem_cgroup_uncharge_swap()
Called when swp_entry's refcnt goes down to 0. A charge against swap
disappears.
mem_cgroup_end_migration(old, new)
At success of migration old is uncharged (if necessary), a charge
to new page is committed. At failure, charge to old page is committed.
3. charge-commit-cancel
In some case, we can't know this "charge" is valid or not at charging
(because of races).
To handle such case, there are charge-commit-cancel functions.
mem_cgroup_try_charge_XXX
mem_cgroup_commit_charge_XXX
mem_cgroup_cancel_charge_XXX
these are used in swap-in and migration.
Memcg pages are charged in two steps:
mem_cgroup_try_charge()
mem_cgroup_commit_charge() or mem_cgroup_cancel_charge()
At try_charge(), there are no flags to say "this page is charged".
at this point, usage += PAGE_SIZE.
At commit(), the function checks the page should be charged or not
and set flags or avoid charging.(usage -= PAGE_SIZE)
At commit(), the page is associated with the memcg.
At cancel(), simply usage -= PAGE_SIZE.
@@ -91,18 +54,6 @@ Under below explanation, we assume CONFIG_MEM_RES_CTRL_SWAP=y.
Anonymous page is newly allocated at
- page fault into MAP_ANONYMOUS mapping.
- Copy-On-Write.
It is charged right after it's allocated before doing any page table
related operations. Of course, it's uncharged when another page is used
for the fault address.
At freeing anonymous page (by exit() or munmap()), zap_pte() is called
and pages for ptes are freed one by one.(see mm/memory.c). Uncharges
are done at page_remove_rmap() when page_mapcount() goes down to 0.
Another page freeing is by page-reclaim (vmscan.c) and anonymous
pages are swapped out. In this case, the page is marked as
PageSwapCache(). uncharge() routine doesn't uncharge the page marked
as SwapCache(). It's delayed until __delete_from_swap_cache().
4.1 Swap-in.
At swap-in, the page is taken from swap-cache. There are 2 cases.
@@ -111,41 +62,6 @@ Under below explanation, we assume CONFIG_MEM_RES_CTRL_SWAP=y.
(b) If the SwapCache has been mapped by processes, it has been
charged already.
This swap-in is one of the most complicated work. In do_swap_page(),
following events occur when pte is unchanged.
(1) the page (SwapCache) is looked up.
(2) lock_page()
(3) try_charge_swapin()
(4) reuse_swap_page() (may call delete_swap_cache())
(5) commit_charge_swapin()
(6) swap_free().
Considering following situation for example.
(A) The page has not been charged before (2) and reuse_swap_page()
doesn't call delete_from_swap_cache().
(B) The page has not been charged before (2) and reuse_swap_page()
calls delete_from_swap_cache().
(C) The page has been charged before (2) and reuse_swap_page() doesn't
call delete_from_swap_cache().
(D) The page has been charged before (2) and reuse_swap_page() calls
delete_from_swap_cache().
memory.usage/memsw.usage changes to this page/swp_entry will be
Case (A) (B) (C) (D)
Event
Before (2) 0/ 1 0/ 1 1/ 1 1/ 1
===========================================
(3) +1/+1 +1/+1 +1/+1 +1/+1
(4) - 0/ 0 - -1/ 0
(5) 0/-1 0/ 0 -1/-1 0/ 0
(6) - 0/-1 - 0/-1
===========================================
Result 1/ 1 1/ 1 1/ 1 1/ 1
In any cases, charges to this page should be 1/ 1.
4.2 Swap-out.
At swap-out, typical state transition is below.
@@ -158,28 +74,20 @@ Under below explanation, we assume CONFIG_MEM_RES_CTRL_SWAP=y.
swp_entry's refcnt -= 1.
At (b), the page is marked as SwapCache and not uncharged.
At (d), the page is removed from SwapCache and a charge in page_cgroup
is moved to swap_cgroup.
Finally, at task exit,
(e) zap_pte() is called and swp_entry's refcnt -=1 -> 0.
Here, a charge in swap_cgroup disappears.
5. Page Cache
Page Cache is charged at
- add_to_page_cache_locked().
uncharged at
- __remove_from_page_cache().
The logic is very clear. (About migration, see below)
Note: __remove_from_page_cache() is called by remove_from_page_cache()
and __remove_mapping().
6. Shmem(tmpfs) Page Cache
Memcg's charge/uncharge have special handlers of shmem. The best way
to understand shmem's page state transition is to read mm/shmem.c.
The best way to understand shmem's page state transition is to read
mm/shmem.c.
But brief explanation of the behavior of memcg around shmem will be
helpful to understand the logic.
@@ -192,56 +100,10 @@ Under below explanation, we assume CONFIG_MEM_RES_CTRL_SWAP=y.
It's charged when...
- A new page is added to shmem's radix-tree.
- A swp page is read. (move a charge from swap_cgroup to page_cgroup)
It's uncharged when
- A page is removed from radix-tree and not SwapCache.
- When SwapCache is removed, a charge is moved to swap_cgroup.
- When swp_entry's refcnt goes down to 0, a charge in swap_cgroup
disappears.
7. Page Migration
One of the most complicated functions is page-migration-handler.
Memcg has 2 routines. Assume that we are migrating a page's contents
from OLDPAGE to NEWPAGE.
Usual migration logic is..
(a) remove the page from LRU.
(b) allocate NEWPAGE (migration target)
(c) lock by lock_page().
(d) unmap all mappings.
(e-1) If necessary, replace entry in radix-tree.
(e-2) move contents of a page.
(f) map all mappings again.
(g) pushback the page to LRU.
(-) OLDPAGE will be freed.
Before (g), memcg should complete all necessary charge/uncharge to
NEWPAGE/OLDPAGE.
The point is....
- If OLDPAGE is anonymous, all charges will be dropped at (d) because
try_to_unmap() drops all mapcount and the page will not be
SwapCache.
- If OLDPAGE is SwapCache, charges will be kept at (g) because
__delete_from_swap_cache() isn't called at (e-1)
- If OLDPAGE is page-cache, charges will be kept at (g) because
remove_from_swap_cache() isn't called at (e-1)
memcg provides following hooks.
- mem_cgroup_prepare_migration(OLDPAGE)
Called after (b) to account a charge (usage += PAGE_SIZE) against
memcg which OLDPAGE belongs to.
- mem_cgroup_end_migration(OLDPAGE, NEWPAGE)
Called after (f) before (g).
If OLDPAGE is used, commit OLDPAGE again. If OLDPAGE is already
charged, a charge by prepare_migration() is automatically canceled.
If NEWPAGE is used, commit NEWPAGE and uncharge OLDPAGE.
But zap_pte() (by exit or munmap) can be called while migration,
we have to check if OLDPAGE/NEWPAGE is a valid page after commit().
mem_cgroup_migrate()
8. LRU
Each memcg has its own private LRU. Now, its handling is under global

35
Documentation/cgroups/unified-hierarchy.txt
View File

@@ -94,12 +94,35 @@ change soon.
mount -t cgroup -o __DEVEL__sane_behavior cgroup $MOUNT_POINT
All controllers which are not bound to other hierarchies are
automatically bound to unified hierarchy and show up at the root of
it. Controllers which are enabled only in the root of unified
hierarchy can be bound to other hierarchies at any time. This allows
mixing unified hierarchy with the traditional multiple hierarchies in
a fully backward compatible way.
All controllers which support the unified hierarchy and are not bound
to other hierarchies are automatically bound to unified hierarchy and
show up at the root of it. Controllers which are enabled only in the
root of unified hierarchy can be bound to other hierarchies. This
allows mixing unified hierarchy with the traditional multiple
hierarchies in a fully backward compatible way.
For development purposes, the following boot parameter makes all
controllers to appear on the unified hierarchy whether supported or
not.
cgroup__DEVEL__legacy_files_on_dfl
A controller can be moved across hierarchies only after the controller
is no longer referenced in its current hierarchy. Because per-cgroup
controller states are destroyed asynchronously and controllers may
have lingering references, a controller may not show up immediately on
the unified hierarchy after the final umount of the previous
hierarchy. Similarly, a controller should be fully disabled to be
moved out of the unified hierarchy and it may take some time for the
disabled controller to become available for other hierarchies;
furthermore, due to dependencies among controllers, other controllers
may need to be disabled too.
While useful for development and manual configurations, dynamically
moving controllers between the unified and other hierarchies is
strongly discouraged for production use. It is recommended to decide
the hierarchies and controller associations before starting using the
controllers.
2-2. cgroup.subtree_control

12
Documentation/device-mapper/switch.txt
View File

@@ -106,6 +106,11 @@ which paths.
The path number in the range 0 ... (<num_paths> - 1).
Expressed in hexadecimal (WITHOUT any prefix like 0x).
R<n>,<m>
This parameter allows repetitive patterns to be loaded quickly. <n> and <m>
are hexadecimal numbers. The last <n> mappings are repeated in the next <m>
slots.
Status
======
@@ -124,3 +129,10 @@ Create a switch device with 64kB region size:
Set mappings for the first 7 entries to point to devices switch0, switch1,
switch2, switch0, switch1, switch2, switch1:
dmsetup message switch 0 set_region_mappings 0:0 :1 :2 :0 :1 :2 :1
Set repetitive mapping. This command:
dmsetup message switch 0 set_region_mappings 1000:1 :2 R2,10
is equivalent to:
dmsetup message switch 0 set_region_mappings 1000:1 :2 :1 :2 :1 :2 :1 :2 \
:1 :2 :1 :2 :1 :2 :1 :2 :1 :2

7
Documentation/devicetree/bindings/arm/adapteva.txt Normal file
View File

@@ -0,0 +1,7 @@
Adapteva Platforms Device Tree Bindings
---------------------------------------
Parallella board
Required root node properties:
- compatible = "adapteva,parallella";

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

@@ -86,3 +86,9 @@ Interrupt controllers:
compatible = "arm,versatile-sic";
interrupt-controller;
#interrupt-cells = <1>;
Required nodes:
- core-module: the root node to the Versatile platforms must have
a core-module with regs and the compatible strings
"arm,core-module-versatile", "syscon"

14
Documentation/devicetree/bindings/arm/armada-380-mpcore-soc-ctrl.txt Normal file
View File

@@ -0,0 +1,14 @@
Marvell Armada 38x CA9 MPcore SoC Controller
============================================
Required properties:
- compatible: Should be "marvell,armada-380-mpcore-soc-ctrl".
- reg: should be the register base and length as documented in the
datasheet for the CA9 MPcore SoC Control registers
mpcore-soc-ctrl@20d20 {
compatible = "marvell,armada-380-mpcore-soc-ctrl";
reg = <0x20d20 0x6c>;
};

5
Documentation/devicetree/bindings/arm/atmel-pmc.txt
View File

@@ -1,7 +1,10 @@
* Power Management Controller (PMC)
Required properties:
- compatible: Should be "atmel,at91rm9200-pmc"
- compatible: Should be "atmel,<chip>-pmc".
<chip> can be: at91rm9200, at91sam9260, at91sam9g45, at91sam9n12,
at91sam9x5, sama5d3
- reg: Should contain PMC registers location and length
Examples:

36
Documentation/devicetree/bindings/arm/bcm/brcm,bcm11351-cpu-method Normal file
View File

@@ -0,0 +1,36 @@
Broadcom Kona Family CPU Enable Method
--------------------------------------
This binding defines the enable method used for starting secondary
CPUs in the following Broadcom SoCs:
BCM11130, BCM11140, BCM11351, BCM28145, BCM28155, BCM21664
The enable method is specified by defining the following required
properties in the "cpus" device tree node:
- enable-method = "brcm,bcm11351-cpu-method";
- secondary-boot-reg = <...>;
The secondary-boot-reg property is a u32 value that specifies the
physical address of the register used to request the ROM holding pen
code release a secondary CPU. The value written to the register is
formed by encoding the target CPU id into the low bits of the
physical start address it should jump to.
Example:
cpus {
#address-cells = <1>;
#size-cells = <0>;
enable-method = "brcm,bcm11351-cpu-method";
secondary-boot-reg = <0x3500417c>;
cpu0: cpu@0 {
device_type = "cpu";
compatible = "arm,cortex-a9";
reg = <0>;
};
cpu1: cpu@1 {
device_type = "cpu";
compatible = "arm,cortex-a9";
reg = <1>;
};
};

95
Documentation/devicetree/bindings/arm/brcm-brcmstb.txt Normal file
View File

@@ -0,0 +1,95 @@
ARM Broadcom STB platforms Device Tree Bindings
-----------------------------------------------
Boards with Broadcom Brahma15 ARM-based BCMxxxx (generally BCM7xxx variants)
SoC shall have the following DT organization:
Required root node properties:
- compatible: "brcm,bcm<chip_id>", "brcm,brcmstb"
example:
/ {
#address-cells = <2>;
#size-cells = <2>;
model = "Broadcom STB (bcm7445)";
compatible = "brcm,bcm7445", "brcm,brcmstb";
Further, syscon nodes that map platform-specific registers used for general
system control is required:
- compatible: "brcm,bcm<chip_id>-sun-top-ctrl", "syscon"
- compatible: "brcm,bcm<chip_id>-hif-cpubiuctrl", "syscon"
- compatible: "brcm,bcm<chip_id>-hif-continuation", "syscon"
example:
rdb {
#address-cells = <1>;
#size-cells = <1>;
compatible = "simple-bus";
ranges = <0 0x00 0xf0000000 0x1000000>;
sun_top_ctrl: syscon@404000 {
compatible = "brcm,bcm7445-sun-top-ctrl", "syscon";
reg = <0x404000 0x51c>;
};
hif_cpubiuctrl: syscon@3e2400 {
compatible = "brcm,bcm7445-hif-cpubiuctrl", "syscon";
reg = <0x3e2400 0x5b4>;
};
hif_continuation: syscon@452000 {
compatible = "brcm,bcm7445-hif-continuation", "syscon";
reg = <0x452000 0x100>;
};
};
Lastly, nodes that allow for support of SMP initialization and reboot are
required:
smpboot
-------
Required properties:
- compatible
The string "brcm,brcmstb-smpboot".
- syscon-cpu
A phandle / integer array property which lets the BSP know the location
of certain CPU power-on registers.
The layout of the property is as follows:
o a phandle to the "hif_cpubiuctrl" syscon node
o offset to the base CPU power zone register
o offset to the base CPU reset register
- syscon-cont
A phandle pointing to the syscon node which describes the CPU boot
continuation registers.
o a phandle to the "hif_continuation" syscon node
example:
smpboot {
compatible = "brcm,brcmstb-smpboot";
syscon-cpu = <&hif_cpubiuctrl 0x88 0x178>;
syscon-cont = <&hif_continuation>;
};
reboot
-------
Required properties
- compatible
The string property "brcm,brcmstb-reboot".
- syscon
A phandle / integer array that points to the syscon node which describes
the general system reset registers.
o a phandle to "sun_top_ctrl"
o offset to the "reset source enable" register
o offset to the "software master reset" register
example:
reboot {
compatible = "brcm,brcmstb-reboot";
syscon = <&sun_top_ctrl 0x304 0x308>;
};

21
Documentation/devicetree/bindings/arm/ccn.txt Normal file
View File

@@ -0,0 +1,21 @@
* ARM CCN (Cache Coherent Network)
Required properties:
- compatible: (standard compatible string) should be one of:
"arm,ccn-504"
"arm,ccn-508"
- reg: (standard registers property) physical address and size
(16MB) of the configuration registers block
- interrupts: (standard interrupt property) single interrupt
generated by the control block
Example:
ccn@0x2000000000 {
compatible = "arm,ccn-504";
reg = <0x20 0x00000000 0 0x1000000>;
interrupts = <0 181 4>;
};

41
Documentation/devicetree/bindings/arm/cpu-enable-method/marvell,berlin-smp Normal file
View File

@@ -0,0 +1,41 @@
========================================================
Secondary CPU enable-method "marvell,berlin-smp" binding
========================================================
This document describes the "marvell,berlin-smp" method for enabling secondary
CPUs. To apply to all CPUs, a single "marvell,berlin-smp" enable method should
be defined in the "cpus" node.
Enable method name: "marvell,berlin-smp"
Compatible machines: "marvell,berlin2" and "marvell,berlin2q"
Compatible CPUs: "marvell,pj4b" and "arm,cortex-a9"
Related properties: (none)
Note:
This enable method needs valid nodes compatible with "arm,cortex-a9-scu" and
"marvell,berlin-cpu-ctrl"[1].
Example:
cpus {
#address-cells = <1>;
#size-cells = <0>;
enable-method = "marvell,berlin-smp";
cpu@0 {
compatible = "marvell,pj4b";
device_type = "cpu";
next-level-cache = <&l2>;
reg = <0>;
};
cpu@1 {
compatible = "marvell,pj4b";
device_type = "cpu";
next-level-cache = <&l2>;
reg = <1>;
};
};
--
[1] arm/marvell,berlin.txt

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

@@ -152,7 +152,9 @@ nodes to be present and contain the properties described below.
"arm,cortex-a7"
"arm,cortex-a8"
"arm,cortex-a9"
"arm,cortex-a12"
"arm,cortex-a15"
"arm,cortex-a17"
"arm,cortex-a53"
"arm,cortex-a57"
"arm,cortex-m0"
@@ -163,6 +165,7 @@ nodes to be present and contain the properties described below.
"arm,cortex-r4"
"arm,cortex-r5"
"arm,cortex-r7"
"brcm,brahma-b15"
"faraday,fa526"
"intel,sa110"
"intel,sa1100"
@@ -184,6 +187,7 @@ nodes to be present and contain the properties described below.
can be one of:
"allwinner,sun6i-a31"
"arm,psci"
"brcm,brahma-b15"
"marvell,armada-375-smp"
"marvell,armada-380-smp"
"marvell,armada-xp-smp"

79
Documentation/devicetree/bindings/arm/gic-v3.txt Normal file
View File

@@ -0,0 +1,79 @@
* ARM Generic Interrupt Controller, version 3
AArch64 SMP cores are often associated with a GICv3, providing Private
Peripheral Interrupts (PPI), Shared Peripheral Interrupts (SPI),
Software Generated Interrupts (SGI), and Locality-specific Peripheral
Interrupts (LPI).
Main node required properties:
- compatible : should at least contain "arm,gic-v3".
- interrupt-controller : Identifies the node as an interrupt controller
- #interrupt-cells : Specifies the number of cells needed to encode an
interrupt source. Must be a single cell with a value of at least 3.
The 1st cell is the interrupt type; 0 for SPI interrupts, 1 for PPI
interrupts. Other values are reserved for future use.
The 2nd cell contains the interrupt number for the interrupt type.
SPI interrupts are in the range [0-987]. PPI interrupts are in the
range [0-15].
The 3rd cell is the flags, encoded as follows:
bits[3:0] trigger type and level flags.
1 = edge triggered
4 = level triggered
Cells 4 and beyond are reserved for future use. When the 1st cell
has a value of 0 or 1, cells 4 and beyond act as padding, and may be
ignored. It is recommended that padding cells have a value of 0.
- reg : Specifies base physical address(s) and size of the GIC
registers, in the following order:
- GIC Distributor interface (GICD)
- GIC Redistributors (GICR), one range per redistributor region
- GIC CPU interface (GICC)
- GIC Hypervisor interface (GICH)
- GIC Virtual CPU interface (GICV)
GICC, GICH and GICV are optional.
- interrupts : Interrupt source of the VGIC maintenance interrupt.
Optional
- redistributor-stride : If using padding pages, specifies the stride
of consecutive redistributors. Must be a multiple of 64kB.
- #redistributor-regions: The number of independent contiguous regions
occupied by the redistributors. Required if more than one such
region is present.
Examples:
gic: interrupt-controller@2cf00000 {
compatible = "arm,gic-v3";
#interrupt-cells = <3>;
interrupt-controller;
reg = <0x0 0x2f000000 0 0x10000>, // GICD
<0x0 0x2f100000 0 0x200000>, // GICR
<0x0 0x2c000000 0 0x2000>, // GICC
<0x0 0x2c010000 0 0x2000>, // GICH
<0x0 0x2c020000 0 0x2000>; // GICV
interrupts = <1 9 4>;
};
gic: interrupt-controller@2c010000 {
compatible = "arm,gic-v3";
#interrupt-cells = <3>;
interrupt-controller;
redistributor-stride = <0x0 0x40000>; // 256kB stride
#redistributor-regions = <2>;
reg = <0x0 0x2c010000 0 0x10000>, // GICD
<0x0 0x2d000000 0 0x800000>, // GICR 1: CPUs 0-31
<0x0 0x2e000000 0 0x800000>; // GICR 2: CPUs 32-63
<0x0 0x2c040000 0 0x2000>, // GICC
<0x0 0x2c060000 0 0x2000>, // GICH
<0x0 0x2c080000 0 0x2000>; // GICV
interrupts = <1 9 4>;
};

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

@@ -16,6 +16,7 @@ Main node required properties:
"arm,cortex-a9-gic"
"arm,cortex-a7-gic"
"arm,arm11mp-gic"
"brcm,brahma-b15-gic"
- interrupt-controller : Identifies the node as an interrupt controller
- #interrupt-cells : Specifies the number of cells needed to encode an
interrupt source. The type shall be a <u32> and the value shall be 3.

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

@@ -31,6 +31,17 @@ Example:
reboot-offset = <0x4>;
};
-----------------------------------------------------------------------
Hisilicon CPU controller
Required properties:
- compatible : "hisilicon,cpuctrl"
- reg : Register address and size
The clock registers and power registers of secondary cores are defined
in CPU controller, especially in HIX5HD2 SoC.
-----------------------------------------------------------------------
PCTRL: Peripheral misc control register
Required Properties:

16
Documentation/devicetree/bindings/arm/marvell,berlin.txt
View File

@@ -24,6 +24,22 @@ SoC and board used. Currently known SoC compatibles are:
...
}
* Marvell Berlin CPU control bindings
CPU control register allows various operations on CPUs, like resetting them
independently.
Required properties:
- compatible: should be "marvell,berlin-cpu-ctrl"
- reg: address and length of the register set
Example:
cpu-ctrl@f7dd0000 {
compatible = "marvell,berlin-cpu-ctrl";
reg = <0xf7dd0000 0x10000>;
};
* Marvell Berlin2 chip control binding
Marvell Berlin SoCs have a chip control register set providing several

8
Documentation/devicetree/bindings/arm/mediatek.txt Normal file
View File

@@ -0,0 +1,8 @@
Mediatek MT6589 Platforms Device Tree Bindings
Boards with a SoC of the Mediatek MT6589 shall have the following property:
Required root node property:
compatible: must contain "mediatek,mt6589"

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

@@ -10,6 +10,7 @@ Required properties:
- compatible : Should be "ti,irq-crossbar"
- reg: Base address and the size of the crossbar registers.
- ti,max-irqs: Total number of irqs available at the interrupt controller.
- ti,max-crossbar-sources: Maximum number of crossbar sources that can be routed.
- ti,reg-size: Size of a individual register in bytes. Every individual
register is assumed to be of same size. Valid sizes are 1, 2, 4.
- ti,irqs-reserved: List of the reserved irq lines that are not muxed using
@@ -17,11 +18,46 @@ Required properties:
so crossbar bar driver should not consider them as free
lines.
Optional properties:
- ti,irqs-skip: This is similar to "ti,irqs-reserved", but these are for
SOC-specific hard-wiring of those irqs which unexpectedly bypasses the
crossbar. These irqs have a crossbar register, but still cannot be used.
- ti,irqs-safe-map: integer which maps to a safe configuration to use
when the interrupt controller irq is unused (when not provided, default is 0)
Examples:
crossbar_mpu: @4a020000 {
compatible = "ti,irq-crossbar";
reg = <0x4a002a48 0x130>;
ti,max-irqs = <160>;
ti,max-crossbar-sources = <400>;
ti,reg-size = <2>;
ti,irqs-reserved = <0 1 2 3 5 6 131 132 139 140>;
ti,irqs-skip = <10 133 139 140>;
};
Consumer:
========
See Documentation/devicetree/bindings/interrupt-controller/interrupts.txt and
Documentation/devicetree/bindings/arm/gic.txt for further details.
An interrupt consumer on an SoC using crossbar will use:
interrupts = <GIC_SPI request_number interrupt_level>
When the request number is between 0 to that described by
"ti,max-crossbar-sources", it is assumed to be a crossbar mapping. If the
request_number is greater than "ti,max-crossbar-sources", then it is mapped as a
quirky hardware mapping direct to GIC.
Example:
device_x@0x4a023000 {
/* Crossbar 8 used */
interrupts = <GIC_SPI 8 IRQ_TYPE_LEVEL_HIGH>;
...
};
device_y@0x4a033000 {
/* Direct mapped GIC SPI 1 used */
interrupts = <GIC_SPI DIRECT_IRQ(1) IRQ_TYPE_LEVEL_HIGH>;
...
};

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

@@ -129,6 +129,9 @@ Boards:
- AM437x GP EVM
compatible = "ti,am437x-gp-evm", "ti,am4372", "ti,am43"
- AM437x SK EVM: AM437x StarterKit Evaluation Module
compatible = "ti,am437x-sk-evm", "ti,am4372", "ti,am43"
- DRA742 EVM: Software Development Board for DRA742
compatible = "ti,dra7-evm", "ti,dra742", "ti,dra74", "ti,dra7"

65
Documentation/devicetree/bindings/arm/omap/prcm.txt Normal file
View File

@@ -0,0 +1,65 @@
OMAP PRCM bindings
Power Reset and Clock Manager lists the device clocks and clockdomains under
a DT hierarchy. Each TI SoC can have multiple PRCM entities listed for it,
each describing one module and the clock hierarchy under it. see [1] for
documentation about the individual clock/clockdomain nodes.
[1] Documentation/devicetree/bindings/clock/ti/*
Required properties:
- compatible: Must be one of:
"ti,am3-prcm"
"ti,am3-scrm"
"ti,am4-prcm"
"ti,am4-scrm"
"ti,omap2-prcm"
"ti,omap2-scrm"
"ti,omap3-prm"
"ti,omap3-cm"
"ti,omap3-scrm"
"ti,omap4-cm1"
"ti,omap4-prm"
"ti,omap4-cm2"
"ti,omap4-scrm"
"ti,omap5-prm"
"ti,omap5-cm-core-aon"
"ti,omap5-scrm"
"ti,omap5-cm-core"
"ti,dra7-prm"
"ti,dra7-cm-core-aon"
"ti,dra7-cm-core"
- reg: Contains PRCM module register address range
(base address and length)
- clocks: clocks for this module
- clockdomains: clockdomains for this module
Example:
cm: cm@48004000 {
compatible = "ti,omap3-cm";
reg = <0x48004000 0x4000>;
cm_clocks: clocks {
#address-cells = <1>;
#size-cells = <0>;
};
cm_clockdomains: clockdomains {
};
}
&cm_clocks {
omap2_32k_fck: omap_32k_fck {
#clock-cells = <0>;
compatible = "fixed-clock";
clock-frequency = <32768>;
};
};
&cm_clockdomains {
core_l3_clkdm: core_l3_clkdm {
compatible = "ti,clockdomain";
clocks = <&sdrc_ick>;
};
};

25
Documentation/devicetree/bindings/arm/samsung/exynos-adc.txt
View File

@@ -14,14 +14,21 @@ Required properties:
for exynos4412/5250 controllers.
Must be "samsung,exynos-adc-v2" for
future controllers.
Must be "samsung,exynos3250-adc" for
controllers compatible with ADC of Exynos3250.
- reg: Contains ADC register address range (base address and
length) and the address of the phy enable register.
- interrupts: Contains the interrupt information for the timer. The
format is being dependent on which interrupt controller
the Samsung device uses.
- #io-channel-cells = <1>; As ADC has multiple outputs
- clocks From common clock binding: handle to adc clock.
- clock-names From common clock binding: Shall be "adc".
- clocks From common clock bindings: handles to clocks specified
in "clock-names" property, in the same order.
- clock-names From common clock bindings: list of clock input names
used by ADC block:
- "adc" : ADC bus clock
- "sclk" : ADC special clock (only for Exynos3250 and
compatible ADC block)
- vdd-supply VDD input supply.
Note: child nodes can be added for auto probing from device tree.
@@ -41,6 +48,20 @@ adc: adc@12D10000 {
vdd-supply = <&buck5_reg>;
};
Example: adding device info in dtsi file for Exynos3250 with additional sclk
adc: adc@126C0000 {
compatible = "samsung,exynos3250-adc", "samsung,exynos-adc-v2;
reg = <0x126C0000 0x100>, <0x10020718 0x4>;
interrupts = <0 137 0>;
#io-channel-cells = <1>;
io-channel-ranges;
clocks = <&cmu CLK_TSADC>, <&cmu CLK_SCLK_TSADC>;
clock-names = "adc", "sclk";
vdd-supply = <&buck5_reg>;
};
Example: Adding child nodes in dts file

32
Documentation/devicetree/bindings/arm/samsung/pmu.txt
View File

@@ -7,13 +7,45 @@ Properties:
- "samsung,exynos4212-pmu" - for Exynos4212 SoC,
- "samsung,exynos4412-pmu" - for Exynos4412 SoC,
- "samsung,exynos5250-pmu" - for Exynos5250 SoC,
- "samsung,exynos5260-pmu" - for Exynos5260 SoC.
- "samsung,exynos5410-pmu" - for Exynos5410 SoC,
- "samsung,exynos5420-pmu" - for Exynos5420 SoC.
second value must be always "syscon".
- reg : offset and length of the register set.
- #clock-cells : must be <1>, since PMU requires once cell as clock specifier.
The single specifier cell is used as index to list of clocks
provided by PMU, which is currently:
0 : SoC clock output (CLKOUT pin)
- clock-names : list of clock names for particular CLKOUT mux inputs in
following format:
"clkoutN", where N is a decimal number corresponding to
CLKOUT mux control bits value for given input, e.g.
"clkout0", "clkout7", "clkout15".
- clocks : list of phandles and specifiers to all input clocks listed in
clock-names property.
Example :
pmu_system_controller: system-controller@10040000 {
compatible = "samsung,exynos5250-pmu", "syscon";
reg = <0x10040000 0x5000>;
#clock-cells = <1>;
clock-names = "clkout0", "clkout1", "clkout2", "clkout3",
"clkout4", "clkout8", "clkout9";
clocks = <&clock CLK_OUT_DMC>, <&clock CLK_OUT_TOP>,
<&clock CLK_OUT_LEFTBUS>, <&clock CLK_OUT_RIGHTBUS>,
<&clock CLK_OUT_CPU>, <&clock CLK_XXTI>,
<&clock CLK_XUSBXTI>;
};
Example of clock consumer :
usb3503: usb3503@08 {
/* ... */
clock-names = "refclk";
clocks = <&pmu_system_controller 0>;
/* ... */
};

9
Documentation/devicetree/bindings/arm/spear-misc.txt Normal file
View File

@@ -0,0 +1,9 @@
SPEAr Misc configuration
===========================
SPEAr SOCs have some miscellaneous registers which are used to configure
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

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

@@ -30,6 +30,8 @@ board-specific compatible values:
nvidia,seaboard
nvidia,ventana
nvidia,whistler
toradex,apalis_t30
toradex,apalis_t30-eval
toradex,colibri_t20-512
toradex,iris

8
Documentation/devicetree/bindings/arm/xilinx.txt
View File

@@ -1,7 +1,7 @@
Xilinx Zynq EP107 Emulation Platform board
Xilinx Zynq Platforms Device Tree Bindings
This board is an emulation platform for the Zynq product which is
based on an ARM Cortex A9 processor.
Boards with Zynq-7000 SOC based on an ARM Cortex A9 processor
shall have the following properties.
Required root node properties:
- compatible = "xlnx,zynq-ep107";
- compatible = "xlnx,zynq-7000";

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

@@ -3,28 +3,43 @@
SATA nodes are defined to describe on-chip Serial ATA controllers.
Each SATA controller should have its own node.
It is possible, but not required, to represent each port as a sub-node.
It allows to enable each port independently when dealing with multiple
PHYs.
Required properties:
- compatible : compatible string, one of:
- "allwinner,sun4i-a10-ahci"
- "fsl,imx53-ahci"
- "fsl,imx6q-ahci"
- "hisilicon,hisi-ahci"
- "ibm,476gtr-ahci"
- "marvell,armada-380-ahci"
- "snps,dwc-ahci"
- "snps,exynos5440-ahci"
- "snps,spear-ahci"
- "generic-ahci"
- interrupts : <interrupt mapping for SATA IRQ>
- reg : <registers mapping>
Please note that when using "generic-ahci" you must also specify a SoC specific
compatible:
compatible = "manufacturer,soc-model-ahci", "generic-ahci";
Optional properties:
- dma-coherent : Present if dma operations are coherent
- clocks : a list of phandle + clock specifier pairs
- target-supply : regulator for SATA target power
- phys : reference to the SATA PHY node
- phy-names : must be "sata-phy"
Required properties when using sub-nodes:
- #address-cells : number of cells to encode an address
- #size-cells : number of cells representing the size of an address
Sub-nodes required properties:
- reg : the port number
- phys : reference to the SATA PHY node
"fsl,imx53-ahci", "fsl,imx6q-ahci" required properties:
- clocks : must contain the sata, sata_ref and ahb clocks
- clock-names : must contain "ahb" for the ahb clock
Examples:
sata@ffe08000 {
@@ -40,3 +55,23 @@ Examples:
clocks = <&pll6 0>, <&ahb_gates 25>;
target-supply = <&reg_ahci_5v>;
};
With sub-nodes:
sata@f7e90000 {
compatible = "marvell,berlin2q-achi", "generic-ahci";
reg = <0xe90000 0x1000>;
interrupts = <GIC_SPI 7 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&chip CLKID_SATA>;
#address-cells = <1>;
#size-cells = <0>;
sata0: sata-port@0 {
reg = <0>;
phys = <&sata_phy 0>;
};
sata1: sata-port@1 {
reg = <1>;
phys = <&sata_phy 1>;
};
};

31
Documentation/devicetree/bindings/ata/ahci-st.txt Normal file
View File

@@ -0,0 +1,31 @@
STMicroelectronics STi SATA controller
This binding describes a SATA device.
Required properties:
- compatible : Must be "st,sti-ahci"
- reg : Physical base addresses and length of register sets
- interrupts : Interrupt associated with the SATA device
- interrupt-names : Associated name must be; "hostc"
- resets : The power-down and soft-reset lines of SATA IP
- reset-names : Associated names must be; "pwr-dwn" and "sw-rst"
- clocks : The phandle for the clock
- clock-names : Associated name must be; "ahci_clk"
- phys : The phandle for the PHY device
- phy-names : Associated name must be; "ahci_phy"
Example:
sata0: sata@fe380000 {
compatible = "st,sti-ahci";
reg = <0xfe380000 0x1000>;
interrupts = <GIC_SPI 157 IRQ_TYPE_NONE>;
interrupt-names = "hostc";
phys = <&miphy365x_phy MIPHY_PORT_0 MIPHY_TYPE_SATA>;
phy-names = "ahci_phy";
resets = <&powerdown STIH416_SATA0_POWERDOWN>,
<&softreset STIH416_SATA0_SOFTRESET>;
reset-names = "pwr-dwn", "sw-rst";
clocks = <&clk_s_a0_ls CLK_ICN_REG>;
clock-names = "ahci_clk";
};

36
Documentation/devicetree/bindings/ata/imx-sata.txt Normal file
View File

@@ -0,0 +1,36 @@
* Freescale i.MX AHCI SATA Controller
The Freescale i.MX SATA controller mostly conforms to the AHCI interface
with some special extensions at integration level.
Required properties:
- compatible : should be one of the following:
- "fsl,imx53-ahci" for i.MX53 SATA controller
- "fsl,imx6q-ahci" for i.MX6Q SATA controller
- interrupts : interrupt mapping for SATA IRQ
- reg : registers mapping
- clocks : list of clock specifiers, must contain an entry for each
required entry in clock-names
- clock-names : should include "sata", "sata_ref" and "ahb" entries
Optional properties:
- fsl,transmit-level-mV : transmit voltage level, in millivolts.
- fsl,transmit-boost-mdB : transmit boost level, in milli-decibels
- fsl,transmit-atten-16ths : transmit attenuation, in 16ths
- fsl,receive-eq-mdB : receive equalisation, in milli-decibels
Please refer to the technical documentation or the driver source code
for the list of legal values for these options.
- fsl,no-spread-spectrum : disable spread-spectrum clocking on the SATA
link.
Examples:
sata@02200000 {
compatible = "fsl,imx6q-ahci";
reg = <0x02200000 0x4000>;
interrupts = <0 39 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&clks IMX6QDL_CLK_SATA>,
<&clks IMX6QDL_CLK_SATA_REF_100M>,
<&clks IMX6QDL_CLK_AHB>;
clock-names = "sata", "sata_ref", "ahb";
};

30
Documentation/devicetree/bindings/ata/tegra-sata.txt Normal file
View File

@@ -0,0 +1,30 @@
Tegra124 SoC SATA AHCI controller
Required properties :
- compatible : "nvidia,tegra124-ahci".
- reg : Should contain 2 entries:
- AHCI register set (SATA BAR5)
- SATA register set
- interrupts : Defines the interrupt used by SATA
- clocks : Must contain an entry for each entry in clock-names.
See ../clocks/clock-bindings.txt for details.
- clock-names : Must include the following entries:
- sata
- sata-oob
- cml1
- pll_e
- resets : Must contain an entry for each entry in reset-names.
See ../reset/reset.txt for details.
- reset-names : Must include the following entries:
- sata
- sata-oob
- sata-cold
- phys : Must contain an entry for each entry in phy-names.
See ../phy/phy-bindings.txt for details.
- phy-names : Must include the following entries:
- sata-phy : XUSB PADCTL SATA PHY
- hvdd-supply : Defines the SATA HVDD regulator
- vddio-supply : Defines the SATA VDDIO regulator
- avdd-supply : Defines the SATA AVDD regulator
- target-5v-supply : Defines the SATA 5V power regulator
- target-12v-supply : Defines the SATA 12V power regulator

4
Documentation/devicetree/bindings/clock/arm-integrator.txt
View File

@@ -1,4 +1,4 @@
Clock bindings for ARM Integrator Core Module clocks
Clock bindings for ARM Integrator and Versatile Core Module clocks
Auxilary Oscillator Clock
@@ -12,7 +12,7 @@ parent node.
Required properties:
- compatible: must be "arm,integrator-cm-auxosc"
- compatible: must be "arm,integrator-cm-auxosc" or "arm,versatile-cm-auxosc"
- #clock-cells: must be <0>
Optional properties:

35
Documentation/devicetree/bindings/clock/clk-palmas-clk32kg-clocks.txt Normal file
View File

@@ -0,0 +1,35 @@
* Palmas 32KHz clocks *
Palmas device has two clock output pins for 32KHz, KG and KG_AUDIO.
This binding uses the common clock binding ./clock-bindings.txt.
Required properties:
- compatible : "ti,palmas-clk32kg" for clk32kg clock
"ti,palmas-clk32kgaudio" for clk32kgaudio clock
- #clock-cells : shall be set to 0.
Optional property:
- ti,external-sleep-control: The external enable input pins controlled the
enable/disable of clocks. The external enable input pins ENABLE1,
ENABLE2 and NSLEEP. The valid values for the external pins are:
PALMAS_EXT_CONTROL_PIN_ENABLE1 for ENABLE1 pin
PALMAS_EXT_CONTROL_PIN_ENABLE2 for ENABLE2 pin
PALMAS_EXT_CONTROL_PIN_NSLEEP for NSLEEP pin
Option 0 or missing this property means the clock is enabled/disabled
via register access and these pins do not have any control.
The macros of external control pins for DTS is defined at
dt-bindings/mfd/palmas.h
Example:
#include <dt-bindings/mfd/palmas.h>
...
palmas: tps65913@58 {
...
clk32kg: palmas_clk32k@0 {
compatible = "ti,palmas-clk32kg";
#clock-cells = <0>;
ti,external-sleep-control = <PALMAS_EXT_CONTROL_PIN_NSLEEP>;
};
...
};

53
Documentation/devicetree/bindings/clock/clk-s5pv210-audss.txt Normal file
View File

@@ -0,0 +1,53 @@
* Samsung Audio Subsystem Clock Controller
The Samsung Audio Subsystem clock controller generates and supplies clocks
to Audio Subsystem block available in the S5PV210 and compatible SoCs.
Required Properties:
- compatible: should be "samsung,s5pv210-audss-clock".
- reg: physical base address and length of the controller's register set.
- #clock-cells: should be 1.
- clocks:
- hclk: AHB bus clock of the Audio Subsystem.
- xxti: Optional fixed rate PLL reference clock, parent of mout_audss. If
not specified (i.e. xusbxti is used for PLL reference), it is fixed to
a clock named "xxti".
- fout_epll: Input PLL to the AudioSS block, parent of mout_audss.
- iiscdclk0: Optional external i2s clock, parent of mout_i2s. If not
specified, it is fixed to a clock named "iiscdclk0".
- sclk_audio0: Audio bus clock, parent of mout_i2s.
- clock-names: Aliases for the above clocks. They should be "hclk",
"xxti", "fout_epll", "iiscdclk0", and "sclk_audio0" respectively.
All available clocks are defined as preprocessor macros in
dt-bindings/clock/s5pv210-audss-clk.h header and can be used in device
tree sources.
Example: Clock controller node.
clk_audss: clock-controller@c0900000 {
compatible = "samsung,s5pv210-audss-clock";
reg = <0xc0900000 0x1000>;
#clock-cells = <1>;
clock-names = "hclk", "xxti",
"fout_epll", "sclk_audio0";
clocks = <&clocks DOUT_HCLKP>, <&xxti>,
<&clocks FOUT_EPLL>, <&clocks SCLK_AUDIO0>;
};
Example: I2S controller node that consumes the clock generated by the clock
controller. Refer to the standard clock bindings for information
about 'clocks' and 'clock-names' property.
i2s0: i2s@03830000 {
/* ... */
clock-names = "iis", "i2s_opclk0",
"i2s_opclk1";
clocks = <&clk_audss CLK_I2S>, <&clk_audss CLK_I2S>,
<&clk_audss CLK_DOUT_AUD_BUS>;
/* ... */
};

36
Documentation/devicetree/bindings/clock/clock-bindings.txt
View File

@@ -131,3 +131,39 @@ clock signal, and a UART.
("pll" and "pll-switched").
* The UART has its baud clock connected the external oscillator and its
register clock connected to the PLL clock (the "pll-switched" signal)
==Assigned clock parents and rates==
Some platforms may require initial configuration of default parent clocks
and clock frequencies. Such a configuration can be specified in a device tree
node through assigned-clocks, assigned-clock-parents and assigned-clock-rates
properties. The assigned-clock-parents property should contain a list of parent
clocks in form of phandle and clock specifier pairs, the assigned-clock-parents
property the list of assigned clock frequency values - corresponding to clocks
listed in the assigned-clocks property.
To skip setting parent or rate of a clock its corresponding entry should be
set to 0, or can be omitted if it is not followed by any non-zero entry.
uart@a000 {
compatible = "fsl,imx-uart";
reg = <0xa000 0x1000>;
...
clocks = <&osc 0>, <&pll 1>;
clock-names = "baud", "register";
assigned-clocks = <&clkcon 0>, <&pll 2>;
assigned-clock-parents = <&pll 2>;
assigned-clock-rates = <0>, <460800>;
};
In this example the <&pll 2> clock is set as parent of clock <&clkcon 0> and
the <&pll 2> clock is assigned a frequency value of 460800 Hz.
Configuring a clock's parent and rate through the device node that consumes
the clock can be done only for clocks that have a single user. Specifying
conflicting parent or rate configuration in multiple consumer nodes for
a shared clock is forbidden.
Configuration of common clocks, which affect multiple consumer devices can
be similarly specified in the clock provider node.

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

@@ -0,0 +1,19 @@
* Clock bindings for the Cirrus Logic CLPS711X CPUs
Required properties:
- compatible : Shall contain "cirrus,clps711x-clk".
- reg : Address of the internal register set.
- startup-frequency: Factory set CPU startup frequency in HZ.
- #clock-cells : Should be <1>.
The clock consumer should specify the desired clock by having the clock
ID in its "clocks" phandle cell. See include/dt-bindings/clock/clps711x-clock.h
for the full list of CLPS711X clock IDs.
Example:
clks: clks@80000000 {
#clock-cells = <1>;
compatible = "cirrus,ep7312-clk", "cirrus,clps711x-clk";
reg = <0x80000000 0xc000>;
startup-frequency = <73728000>;
};

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

@@ -0,0 +1,26 @@
* Clock bindings for Freescale i.MX1 CPUs
Required properties:
- compatible: Should be "fsl,imx1-ccm".
- reg: Address and length of the register set.
- #clock-cells: Should be <1>.
The clock consumer should specify the desired clock by having the clock
ID in its "clocks" phandle cell. See include/dt-bindings/clock/imx1-clock.h
for the full list of i.MX1 clock IDs.
Examples:
clks: ccm@0021b000 {
#clock-cells = <1>;
compatible = "fsl,imx1-ccm";
reg = <0x0021b000 0x1000>;
};
pwm: pwm@00208000 {
#pwm-cells = <2>;
compatible = "fsl,imx1-pwm";
reg = <0x00208000 0x1000>;
interrupts = <34>;
clocks = <&clks IMX1_CLK_DUMMY>, <&clks IMX1_CLK_PER1>;
clock-names = "ipg", "per";
};

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

@@ -0,0 +1,28 @@
* Clock bindings for Freescale i.MX21
Required properties:
- compatible : Should be "fsl,imx21-ccm".
- reg : Address and length of the register set.
- interrupts : Should contain CCM interrupt.
- #clock-cells: Should be <1>.
The clock consumer should specify the desired clock by having the clock
ID in its "clocks" phandle cell. See include/dt-bindings/clock/imx21-clock.h
for the full list of i.MX21 clock IDs.
Examples:
clks: ccm@10027000{
compatible = "fsl,imx21-ccm";
reg = <0x10027000 0x800>;
#clock-cells = <1>;
};
uart1: serial@1000a000 {
compatible = "fsl,imx21-uart";
reg = <0x1000a000 0x1000>;
interrupts = <20>;
clocks = <&clks IMX21_CLK_UART1_IPG_GATE>,
<&clks IMX21_CLK_PER1>;
clock-names = "ipg", "per";
status = "disabled";
};

127
Documentation/devicetree/bindings/clock/imx27-clock.txt
View File

@@ -7,117 +7,22 @@ Required properties:
- #clock-cells: Should be <1>
The clock consumer should specify the desired clock by having the clock
ID in its "clocks" phandle cell. The following is a full list of i.MX27
clocks and IDs.
Clock ID
-----------------------
dummy 0
ckih 1
ckil 2
mpll 3
spll 4
mpll_main2 5
ahb 6
ipg 7
nfc_div 8
per1_div 9
per2_div 10
per3_div 11
per4_div 12
vpu_sel 13
vpu_div 14
usb_div 15
cpu_sel 16
clko_sel 17
cpu_div 18
clko_div 19
ssi1_sel 20
ssi2_sel 21
ssi1_div 22
ssi2_div 23
clko_en 24
ssi2_ipg_gate 25
ssi1_ipg_gate 26
slcdc_ipg_gate 27
sdhc3_ipg_gate 28
sdhc2_ipg_gate 29
sdhc1_ipg_gate 30
scc_ipg_gate 31
sahara_ipg_gate 32
rtc_ipg_gate 33
pwm_ipg_gate 34
owire_ipg_gate 35
lcdc_ipg_gate 36
kpp_ipg_gate 37
iim_ipg_gate 38
i2c2_ipg_gate 39
i2c1_ipg_gate 40
gpt6_ipg_gate 41
gpt5_ipg_gate 42
gpt4_ipg_gate 43
gpt3_ipg_gate 44
gpt2_ipg_gate 45
gpt1_ipg_gate 46
gpio_ipg_gate 47
fec_ipg_gate 48
emma_ipg_gate 49
dma_ipg_gate 50
cspi3_ipg_gate 51
cspi2_ipg_gate 52
cspi1_ipg_gate 53
nfc_baud_gate 54
ssi2_baud_gate 55
ssi1_baud_gate 56
vpu_baud_gate 57
per4_gate 58
per3_gate 59
per2_gate 60
per1_gate 61
usb_ahb_gate 62
slcdc_ahb_gate 63
sahara_ahb_gate 64
lcdc_ahb_gate 65
vpu_ahb_gate 66
fec_ahb_gate 67
emma_ahb_gate 68
emi_ahb_gate 69
dma_ahb_gate 70
csi_ahb_gate 71
brom_ahb_gate 72
ata_ahb_gate 73
wdog_ipg_gate 74
usb_ipg_gate 75
uart6_ipg_gate 76
uart5_ipg_gate 77
uart4_ipg_gate 78
uart3_ipg_gate 79
uart2_ipg_gate 80
uart1_ipg_gate 81
ckih_div1p5 82
fpm 83
mpll_osc_sel 84
mpll_sel 85
spll_gate 86
mshc_div 87
rtic_ipg_gate 88
mshc_ipg_gate 89
rtic_ahb_gate 90
mshc_baud_gate 91
ID in its "clocks" phandle cell. See include/dt-bindings/clock/imx27-clock.h
for the full list of i.MX27 clock IDs.
Examples:
clks: ccm@10027000{
compatible = "fsl,imx27-ccm";
reg = <0x10027000 0x1000>;
#clock-cells = <1>;
};
clks: ccm@10027000{
compatible = "fsl,imx27-ccm";
reg = <0x10027000 0x1000>;
#clock-cells = <1>;
};
uart1: serial@1000a000 {
compatible = "fsl,imx27-uart", "fsl,imx21-uart";
reg = <0x1000a000 0x1000>;
interrupts = <20>;
clocks = <&clks 81>, <&clks 61>;
clock-names = "ipg", "per";
status = "disabled";
};
uart1: serial@1000a000 {
compatible = "fsl,imx27-uart", "fsl,imx21-uart";
reg = <0x1000a000 0x1000>;
interrupts = <20>;
clocks = <&clks IMX27_CLK_UART1_IPG_GATE>,
<&clks IMX27_CLK_PER1_GATE>;
clock-names = "ipg", "per";
status = "disabled";
};

220
Documentation/devicetree/bindings/clock/imx6q-clock.txt
View File

@@ -7,223 +7,13 @@ Required properties:
- #clock-cells: Should be <1>
The clock consumer should specify the desired clock by having the clock
ID in its "clocks" phandle cell. The following is a full list of i.MX6Q
clocks and IDs.
Clock ID
---------------------------
dummy 0
ckil 1
ckih 2
osc 3
pll2_pfd0_352m 4
pll2_pfd1_594m 5
pll2_pfd2_396m 6
pll3_pfd0_720m 7
pll3_pfd1_540m 8
pll3_pfd2_508m 9
pll3_pfd3_454m 10
pll2_198m 11
pll3_120m 12
pll3_80m 13
pll3_60m 14
twd 15
step 16
pll1_sw 17
periph_pre 18
periph2_pre 19
periph_clk2_sel 20
periph2_clk2_sel 21
axi_sel 22
esai_sel 23
asrc_sel 24
spdif_sel 25
gpu2d_axi 26
gpu3d_axi 27
gpu2d_core_sel 28
gpu3d_core_sel 29
gpu3d_shader_sel 30
ipu1_sel 31
ipu2_sel 32
ldb_di0_sel 33
ldb_di1_sel 34
ipu1_di0_pre_sel 35
ipu1_di1_pre_sel 36
ipu2_di0_pre_sel 37
ipu2_di1_pre_sel 38
ipu1_di0_sel 39
ipu1_di1_sel 40
ipu2_di0_sel 41
ipu2_di1_sel 42
hsi_tx_sel 43
pcie_axi_sel 44
ssi1_sel 45
ssi2_sel 46
ssi3_sel 47
usdhc1_sel 48
usdhc2_sel 49
usdhc3_sel 50
usdhc4_sel 51
enfc_sel 52
emi_sel 53
emi_slow_sel 54
vdo_axi_sel 55
vpu_axi_sel 56
cko1_sel 57
periph 58
periph2 59
periph_clk2 60
periph2_clk2 61
ipg 62
ipg_per 63
esai_pred 64
esai_podf 65
asrc_pred 66
asrc_podf 67
spdif_pred 68
spdif_podf 69
can_root 70
ecspi_root 71
gpu2d_core_podf 72
gpu3d_core_podf 73
gpu3d_shader 74
ipu1_podf 75
ipu2_podf 76
ldb_di0_podf 77
ldb_di1_podf 78
ipu1_di0_pre 79
ipu1_di1_pre 80
ipu2_di0_pre 81
ipu2_di1_pre 82
hsi_tx_podf 83
ssi1_pred 84
ssi1_podf 85
ssi2_pred 86
ssi2_podf 87
ssi3_pred 88
ssi3_podf 89
uart_serial_podf 90
usdhc1_podf 91
usdhc2_podf 92
usdhc3_podf 93
usdhc4_podf 94
enfc_pred 95
enfc_podf 96
emi_podf 97
emi_slow_podf 98
vpu_axi_podf 99
cko1_podf 100
axi 101
mmdc_ch0_axi_podf 102
mmdc_ch1_axi_podf 103
arm 104
ahb 105
apbh_dma 106
asrc 107
can1_ipg 108
can1_serial 109
can2_ipg 110
can2_serial 111
ecspi1 112
ecspi2 113
ecspi3 114
ecspi4 115
ecspi5 116
enet 117
esai 118
gpt_ipg 119
gpt_ipg_per 120
gpu2d_core 121
gpu3d_core 122
hdmi_iahb 123
hdmi_isfr 124
i2c1 125
i2c2 126
i2c3 127
iim 128
enfc 129
ipu1 130
ipu1_di0 131
ipu1_di1 132
ipu2 133
ipu2_di0 134
ldb_di0 135
ldb_di1 136
ipu2_di1 137
hsi_tx 138
mlb 139
mmdc_ch0_axi 140
mmdc_ch1_axi 141
ocram 142
openvg_axi 143
pcie_axi 144
pwm1 145
pwm2 146
pwm3 147
pwm4 148
per1_bch 149
gpmi_bch_apb 150
gpmi_bch 151
gpmi_io 152
gpmi_apb 153
sata 154
sdma 155
spba 156
ssi1 157
ssi2 158
ssi3 159
uart_ipg 160
uart_serial 161
usboh3 162
usdhc1 163
usdhc2 164
usdhc3 165
usdhc4 166
vdo_axi 167
vpu_axi 168
cko1 169
pll1_sys 170
pll2_bus 171
pll3_usb_otg 172
pll4_audio 173
pll5_video 174
pll8_mlb 175
pll7_usb_host 176
pll6_enet 177
ssi1_ipg 178
ssi2_ipg 179
ssi3_ipg 180
rom 181
usbphy1 182
usbphy2 183
ldb_di0_div_3_5 184
ldb_di1_div_3_5 185
sata_ref 186
sata_ref_100m 187
pcie_ref 188
pcie_ref_125m 189
enet_ref 190
usbphy1_gate 191
usbphy2_gate 192
pll4_post_div 193
pll5_post_div 194
pll5_video_div 195
eim_slow 196
spdif 197
cko2_sel 198
cko2_podf 199
cko2 200
cko 201
vdoa 202
pll4_audio_div 203
lvds1_sel 204
lvds2_sel 205
lvds1_gate 206
lvds2_gate 207
esai_ahb 208
ID in its "clocks" phandle cell. See include/dt-bindings/clock/imx6qdl-clock.h
for the full list of i.MX6 Quad and DualLite clock IDs.
Examples:
#include <dt-bindings/clock/imx6qdl-clock.h>
clks: ccm@020c4000 {
compatible = "fsl,imx6q-ccm";
reg = <0x020c4000 0x4000>;
@@ -235,7 +25,7 @@ uart1: serial@02020000 {
compatible = "fsl,imx6q-uart", "fsl,imx21-uart";
reg = <0x02020000 0x4000>;
interrupts = <0 26 0x04>;
clocks = <&clks 160>, <&clks 161>;
clocks = <&clks IMX6QDL_CLK_UART_IPG>, <&clks IMX6QDL_CLK_UART_SERIAL>;
clock-names = "ipg", "per";
status = "disabled";
};

5
Documentation/devicetree/bindings/clock/mvebu-cpu-clock.txt
View File

@@ -3,14 +3,15 @@ Device Tree Clock bindings for cpu clock of Marvell EBU platforms
Required properties:
- compatible : shall be one of the following:
"marvell,armada-xp-cpu-clock" - cpu clocks for Armada XP
- reg : Address and length of the clock complex register set
- reg : Address and length of the clock complex register set, followed
by address and length of the PMU DFS registers
- #clock-cells : should be set to 1.
- clocks : shall be the input parent clock phandle for the clock.
cpuclk: clock-complex@d0018700 {
#clock-cells = <1>;
compatible = "marvell,armada-xp-cpu-clock";
reg = <0xd0018700 0xA0>;
reg = <0xd0018700 0xA0>, <0x1c054 0x10>;
clocks = <&coreclk 1>;
}

2
Documentation/devicetree/bindings/clock/qcom,gcc.txt
View File

@@ -5,6 +5,8 @@ Required properties :
- compatible : shall contain only one of the following:
"qcom,gcc-apq8064"
"qcom,gcc-apq8084"
"qcom,gcc-ipq8064"
"qcom,gcc-msm8660"
"qcom,gcc-msm8960"
"qcom,gcc-msm8974"

2
Documentation/devicetree/bindings/clock/qcom,mmcc.txt
View File

@@ -4,6 +4,8 @@ Qualcomm Multimedia Clock & Reset Controller Binding
Required properties :
- compatible : shall contain only one of the following:
"qcom,mmcc-apq8064"
"qcom,mmcc-apq8084"
"qcom,mmcc-msm8660"
"qcom,mmcc-msm8960"
"qcom,mmcc-msm8974"

61
Documentation/devicetree/bindings/clock/rockchip,rk3188-cru.txt Normal file
View File

@@ -0,0 +1,61 @@
* Rockchip RK3188/RK3066 Clock and Reset Unit
The RK3188/RK3066 clock controller generates and supplies clock to various
controllers within the SoC and also implements a reset controller for SoC
peripherals.
Required Properties:
- compatible: should be "rockchip,rk3188-cru", "rockchip,rk3188a-cru" or
"rockchip,rk3066a-cru"
- reg: physical base address of the controller and length of memory mapped
region.
- #clock-cells: should be 1.
- #reset-cells: should be 1.
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.
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/rk3188-cru.h and
dt-bindings/clock/rk3066-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,
- "xin27m" - 27mhz crystal input on rk3066 - optional,
- "ext_hsadc" - external HSADC clock - optional,
- "ext_cif0" - external camera clock - optional,
- "ext_rmii" - external RMII clock - optional,
- "ext_jtag" - externalJTAG clock - optional
Example: Clock controller node:
cru: cru@20000000 {
compatible = "rockchip,rk3188-cru";
reg = <0x20000000 0x1000>;
rockchip,grf = <&grf>;
#clock-cells = <1>;
#reset-cells = <1>;
};
Example: UART controller node that consumes the clock generated by the clock
controller:
uart0: serial@10124000 {
compatible = "snps,dw-apb-uart";
reg = <0x10124000 0x400>;
interrupts = <GIC_SPI 34 IRQ_TYPE_LEVEL_HIGH>;
reg-shift = <2>;
reg-io-width = <1>;
clocks = <&cru SCLK_UART0>;
};

61
Documentation/devicetree/bindings/clock/rockchip,rk3288-cru.txt Normal file
View File

@@ -0,0 +1,61 @@
* Rockchip RK3288 Clock and Reset Unit
The RK3288 clock controller generates and supplies clock to various
controllers within the SoC and also implements a reset controller for SoC
peripherals.
Required Properties:
- compatible: should be "rockchip,rk3288-cru"
- reg: physical base address of the controller and length of memory mapped
region.
- #clock-cells: should be 1.
- #reset-cells: should be 1.
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.
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/rk3288-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,
- "ext_i2s" - external I2S clock - optional,
- "ext_hsadc" - external HSADC clock - optional,
- "ext_edp_24m" - external display port clock - optional,
- "ext_vip" - external VIP clock - optional,
- "ext_isp" - external ISP clock - optional,
- "ext_jtag" - external JTAG clock - optional
Example: Clock controller node:
cru: cru@20000000 {
compatible = "rockchip,rk3188-cru";
reg = <0x20000000 0x1000>;
rockchip,grf = <&grf>;
#clock-cells = <1>;
#reset-cells = <1>;
};
Example: UART controller node that consumes the clock generated by the clock
controller:
uart0: serial@10124000 {
compatible = "snps,dw-apb-uart";
reg = <0x10124000 0x400>;
interrupts = <GIC_SPI 34 IRQ_TYPE_LEVEL_HIGH>;
reg-shift = <2>;
reg-io-width = <1>;
clocks = <&cru SCLK_UART0>;
};

3
Documentation/devicetree/bindings/clock/rockchip.txt
View File

@@ -6,6 +6,9 @@ This binding uses the common clock binding[1].
== Gate clocks ==
These bindings are deprecated!
Please use the soc specific CRU bindings instead.
The gate registers form a continuos block which makes the dt node
structure a matter of taste, as either all gates can be put into
one gate clock spanning all registers or they can be divided into

78
Documentation/devicetree/bindings/clock/samsung,s5pv210-clock.txt Normal file
View File

@@ -0,0 +1,78 @@
* Samsung S5P6442/S5PC110/S5PV210 Clock Controller
Samsung S5P6442, S5PC110 and S5PV210 SoCs contain integrated clock
controller, which generates and supplies clock to various controllers
within the SoC.
Required Properties:
- compatible: should be one of following:
- "samsung,s5pv210-clock" : for clock controller of Samsung
S5PC110/S5PV210 SoCs,
- "samsung,s5p6442-clock" : for clock controller of Samsung
S5P6442 SoC.
- reg: physical base address of the controller and length of memory mapped
region.
- #clock-cells: should be 1.
All available clocks are defined as preprocessor macros in
dt-bindings/clock/s5pv210.h header and can be used in device tree sources.
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:
- "xxti": external crystal oscillator connected to XXTI and XXTO pins of
the SoC,
- "xusbxti": external crystal oscillator connected to XUSBXTI and XUSBXTO
pins of the SoC,
A subset of above clocks available on given board shall be specified in
board device tree, including the system base clock, as selected by XOM[0]
pin of the SoC. Refer to generic fixed rate clock bindings
documentation[1] for more information how to specify these clocks.
[1] Documentation/devicetree/bindings/clock/fixed-clock.txt
Example: Clock controller node:
clock: clock-controller@7e00f000 {
compatible = "samsung,s5pv210-clock";
reg = <0x7e00f000 0x1000>;
#clock-cells = <1>;
};
Example: Required external clocks:
xxti: clock-xxti {
compatible = "fixed-clock";
clock-output-names = "xxti";
clock-frequency = <24000000>;
#clock-cells = <0>;
};
xusbxti: clock-xusbxti {
compatible = "fixed-clock";
clock-output-names = "xusbxti";
clock-frequency = <24000000>;
#clock-cells = <0>;
};
Example: UART controller node that consumes the clock generated by the clock
controller (refer to the standard clock bindings for information about
"clocks" and "clock-names" properties):
uart0: serial@e2900000 {
compatible = "samsung,s5pv210-uart";
reg = <0xe2900000 0x400>;
interrupt-parent = <&vic1>;
interrupts = <10>;
clock-names = "uart", "clk_uart_baud0",
"clk_uart_baud1";
clocks = <&clocks UART0>, <&clocks UART0>,
<&clocks SCLK_UART0>;
status = "disabled";
};

26
Documentation/devicetree/bindings/clock/st/st,clkgen-divmux.txt
View File

@@ -24,26 +24,26 @@ Required properties:
Example:
clockgenA@fd345000 {
clockgen-a@fd345000 {
reg = <0xfd345000 0xb50>;
CLK_M_A1_DIV1: CLK_M_A1_DIV1 {
clk_m_a1_div1: clk-m-a1-div1 {
#clock-cells = <1>;
compatible = "st,clkgena-divmux-c32-odf1",
"st,clkgena-divmux";
clocks = <&CLK_M_A1_OSC_PREDIV>,
<&CLK_M_A1_PLL0 1>, /* PLL0 PHI1 */
<&CLK_M_A1_PLL1 1>; /* PLL1 PHI1 */
clocks = <&clk_m_a1_osc_prediv>,
<&clk_m_a1_pll0 1>, /* PLL0 PHI1 */
<&clk_m_a1_pll1 1>; /* PLL1 PHI1 */
clock-output-names = "CLK_M_RX_ICN_TS",
"CLK_M_RX_ICN_VDP_0",
"", /* Unused */
"CLK_M_PRV_T1_BUS",
"CLK_M_ICN_REG_12",
"CLK_M_ICN_REG_10",
"", /* Unused */
"CLK_M_ICN_ST231";
clock-output-names = "clk-m-rx-icn-ts",
"clk-m-rx-icn-vdp-0",
"", /* unused */
"clk-m-prv-t1-bus",
"clk-m-icn-reg-12",
"clk-m-icn-reg-10",
"", /* unused */
"clk-m-icn-st231";
};
};

6
Documentation/devicetree/bindings/clock/st/st,clkgen-mux.txt
View File

@@ -17,7 +17,7 @@ Required properties:
"st,stih416-clkgenf-vcc-sd", "st,clkgen-mux"
"st,stih415-clkgen-a9-mux", "st,clkgen-mux"
"st,stih416-clkgen-a9-mux", "st,clkgen-mux"
"st,stih407-clkgen-a9-mux", "st,clkgen-mux"
- #clock-cells : from common clock binding; shall be set to 0.
@@ -27,10 +27,10 @@ Required properties:
Example:
CLK_M_HVA: CLK_M_HVA {
clk_m_hva: clk-m-hva@fd690868 {
#clock-cells = <0>;
compatible = "st,stih416-clkgenf-vcc-hva", "st,clkgen-mux";
reg = <0xfd690868 4>;
clocks = <&CLOCKGEN_F 1>, <&CLK_M_A1_DIV0 3>;
clocks = <&clockgen_f 1>, <&clk_m_a1_div0 3>;
};

17
Documentation/devicetree/bindings/clock/st/st,clkgen-pll.txt
View File

@@ -19,11 +19,14 @@ Required properties:
"st,stih415-plls-c32-ddr", "st,clkgen-plls-c32"
"st,stih416-plls-c32-a9", "st,clkgen-plls-c32"
"st,stih416-plls-c32-ddr", "st,clkgen-plls-c32"
"st,stih407-plls-c32-a0", "st,clkgen-plls-c32"
"st,stih407-plls-c32-a9", "st,clkgen-plls-c32"
"st,stih407-plls-c32-c0_0", "st,clkgen-plls-c32"
"st,stih407-plls-c32-c0_1", "st,clkgen-plls-c32"
"st,stih415-gpu-pll-c32", "st,clkgengpu-pll-c32"
"st,stih416-gpu-pll-c32", "st,clkgengpu-pll-c32"
- #clock-cells : From common clock binding; shall be set to 1.
- clocks : From common clock binding
@@ -32,17 +35,17 @@ Required properties:
Example:
clockgenA@fee62000 {
clockgen-a@fee62000 {
reg = <0xfee62000 0xb48>;
CLK_S_A0_PLL: CLK_S_A0_PLL {
clk_s_a0_pll: clk-s-a0-pll {
#clock-cells = <1>;
compatible = "st,clkgena-plls-c65";
clocks = <&CLK_SYSIN>;
clocks = <&clk_sysin>;
clock-output-names = "CLK_S_A0_PLL0_HS",
"CLK_S_A0_PLL0_LS",
"CLK_S_A0_PLL1";
clock-output-names = "clk-s-a0-pll0-hs",
"clk-s-a0-pll0-ls",
"clk-s-a0-pll1";
};
};

8
Documentation/devicetree/bindings/clock/st/st,clkgen-prediv.txt
View File

@@ -20,17 +20,17 @@ Required properties:
Example:
clockgenA@fd345000 {
clockgen-a@fd345000 {
reg = <0xfd345000 0xb50>;
CLK_M_A2_OSC_PREDIV: CLK_M_A2_OSC_PREDIV {
clk_m_a2_osc_prediv: clk-m-a2-osc-prediv {
#clock-cells = <0>;
compatible = "st,clkgena-prediv-c32",
"st,clkgena-prediv";
clocks = <&CLK_SYSIN>;
clocks = <&clk_sysin>;
clock-output-names = "CLK_M_A2_OSC_PREDIV";
clock-output-names = "clk-m-a2-osc-prediv";
};
};

32
Documentation/devicetree/bindings/clock/st/st,clkgen-vcc.txt
View File

@@ -32,22 +32,30 @@ Required properties:
Example:
CLOCKGEN_C_VCC: CLOCKGEN_C_VCC {
clockgen_c_vcc: clockgen-c-vcc@0xfe8308ac {
#clock-cells = <1>;
compatible = "st,stih416-clkgenc", "st,clkgen-vcc";
reg = <0xfe8308ac 12>;
clocks = <&CLK_S_VCC_HD>, <&CLOCKGEN_C 1>,
<&CLK_S_TMDS_FROMPHY>, <&CLOCKGEN_C 2>;
clocks = <&clk_s_vcc_hd>,
<&clockgen_c 1>,
<&clk_s_tmds_fromphy>,
<&clockgen_c 2>;
clock-output-names =
"CLK_S_PIX_HDMI", "CLK_S_PIX_DVO",
"CLK_S_OUT_DVO", "CLK_S_PIX_HD",
"CLK_S_HDDAC", "CLK_S_DENC",
"CLK_S_SDDAC", "CLK_S_PIX_MAIN",
"CLK_S_PIX_AUX", "CLK_S_STFE_FRC_0",
"CLK_S_REF_MCRU", "CLK_S_SLAVE_MCRU",
"CLK_S_TMDS_HDMI", "CLK_S_HDMI_REJECT_PLL",
"CLK_S_THSENS";
clock-output-names = "clk-s-pix-hdmi",
"clk-s-pix-dvo",
"clk-s-out-dvo",
"clk-s-pix-hd",
"clk-s-hddac",
"clk-s-denc",
"clk-s-sddac",
"clk-s-pix-main",
"clk-s-pix-aux",
"clk-s-stfe-frc-0",
"clk-s-ref-mcru",
"clk-s-slave-mcru",
"clk-s-tmds-hdmi",
"clk-s-hdmi-reject-pll",
"clk-s-thsens";
};

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

@@ -24,60 +24,77 @@ address is common of all subnode.
quadfs_node {
...
};
mux_node {
...
};
vcc_node {
...
};
flexgen_node {
...
};
...
};
This binding uses the common clock binding[1].
Each subnode should use the binding discribe in [2]..[4]
Each subnode should use the binding discribe in [2]..[7]
[1] Documentation/devicetree/bindings/clock/clock-bindings.txt
[2] Documentation/devicetree/bindings/clock/st,quadfs.txt
[3] Documentation/devicetree/bindings/clock/st,quadfs.txt
[4] Documentation/devicetree/bindings/clock/st,quadfs.txt
[2] Documentation/devicetree/bindings/clock/st,clkgen-divmux.txt
[3] Documentation/devicetree/bindings/clock/st,clkgen-mux.txt
[4] Documentation/devicetree/bindings/clock/st,clkgen-pll.txt
[5] Documentation/devicetree/bindings/clock/st,clkgen-prediv.txt
[6] Documentation/devicetree/bindings/clock/st,vcc.txt
[7] Documentation/devicetree/bindings/clock/st,quadfs.txt
[8] Documentation/devicetree/bindings/clock/st,flexgen.txt
Required properties:
- reg : A Base address and length of the register set.
Example:
clockgenA@fee62000 {
clockgen-a@fee62000 {
reg = <0xfee62000 0xb48>;
CLK_S_A0_PLL: CLK_S_A0_PLL {
clk_s_a0_pll: clk-s-a0-pll {
#clock-cells = <1>;
compatible = "st,clkgena-plls-c65";
clocks = <&CLK_SYSIN>;
clocks = <&clk-sysin>;
clock-output-names = "CLK_S_A0_PLL0_HS",
"CLK_S_A0_PLL0_LS",
"CLK_S_A0_PLL1";
clock-output-names = "clk-s-a0-pll0-hs",
"clk-s-a0-pll0-ls",
"clk-s-a0-pll1";
};
CLK_S_A0_OSC_PREDIV: CLK_S_A0_OSC_PREDIV {
clk_s_a0_osc_prediv: clk-s-a0-osc-prediv {
#clock-cells = <0>;
compatible = "st,clkgena-prediv-c65",
"st,clkgena-prediv";
clocks = <&CLK_SYSIN>;
clocks = <&clk_sysin>;
clock-output-names = "CLK_S_A0_OSC_PREDIV";
clock-output-names = "clk-s-a0-osc-prediv";
};
CLK_S_A0_HS: CLK_S_A0_HS {
clk_s_a0_hs: clk-s-a0-hs {
#clock-cells = <1>;
compatible = "st,clkgena-divmux-c65-hs",
"st,clkgena-divmux";
clocks = <&CLK_S_A0_OSC_PREDIV>,
<&CLK_S_A0_PLL 0>, /* PLL0 HS */
<&CLK_S_A0_PLL 2>; /* PLL1 */
clocks = <&clk-s_a0_osc_prediv>,
<&clk-s_a0_pll 0>, /* pll0 hs */
<&clk-s_a0_pll 2>; /* pll1 */
clock-output-names = "CLK_S_FDMA_0",
"CLK_S_FDMA_1",
""; /* CLK_S_JIT_SENSE */
/* Fourth output unused */
clock-output-names = "clk-s-fdma-0",
"clk-s-fdma-1",
""; /* clk-s-jit-sense */
/* fourth output unused */
};
};

119
Documentation/devicetree/bindings/clock/st/st,flexgen.txt Normal file
View File

@@ -0,0 +1,119 @@
Binding for a type of flexgen structure found on certain
STMicroelectronics consumer electronics SoC devices
This structure includes:
- a clock cross bar (represented by a mux element)
- a pre and final dividers (represented by a divider and gate elements)
Flexgen structure is a part of Clockgen[1].
Please find an example below:
Clockgen block diagram
-------------------------------------------------------------------
| Flexgen stucture |
| --------------------------------------------- |
| | ------- -------- -------- | |
clk_sysin | | | | | | | | |
---|-----------------|-->| | | | | | | |
| | | | | | | | | | |
| | ------- | | | |Pre | |Final | | |
| | |PLL0 | | | | |Dividers| |Dividers| | |
| |->| | | | | | x32 | | x32 | | |
| | | odf_0|----|-->| | | | | | | |
| | | | | | | | | | | | |
| | | | | | | | | | | | |
| | | | | | | | | | | | |
| | | | | | | | | | | | |
| | ------- | | | | | | | | |
| | | | | | | | | | |
| | ------- | | Clock | | | | | | |
| | |PLL1 | | | | | | | | | |
| |->| | | | Cross | | | | | | |
| | | odf_0|----|-->| | | | | | CLK_DIV[31:0]
| | | | | | Bar |====>| |====>| |===|=========>
| | | | | | | | | | | | |
| | | | | | | | | | | | |
| | | | | | | | | | | | |
| | ------- | | | | | | | | |
| | | | | | | | | | |
| | ------- | | | | | | | | |
| | |QUADFS | | | | | | | | | |
| |->| ch0|----|-->| | | | | | | |
| | | | | | | | | | | |
| | ch1|----|-->| | | | | | | |
| | | | | | | | | | | |
| | ch2|----|-->| | | DIV | | DIV | | |
| | | | | | | 1 to | | 1 to | | |
| | ch3|----|-->| | | 1024 | | 64 | | |
| ------- | | | | | | | | |
| | ------- -------- -------- | |
| -------------------------------------------- |
| |
-------------------------------------------------------------------
This binding uses the common clock binding[2].
[1] Documentation/devicetree/bindings/clock/st/st,clkgen.txt
[2] Documentation/devicetree/bindings/clock/clock-bindings.txt
Required properties:
- compatible : shall be:
"st,flexgen"
- #clock-cells : from common clock binding; shall be set to 1 (multiple clock
outputs).
- clocks : must be set to the parent's phandle. it's could be output clocks of
a quadsfs or/and a pll or/and clk_sysin (up to 7 clocks)
- clock-output-names : List of strings used to name the clock outputs.
Example:
clk_s_c0_flexgen: clk-s-c0-flexgen {
#clock-cells = <1>;
compatible = "st,flexgen";
clocks = <&clk_s_c0_pll0 0>,
<&clk_s_c0_pll1 0>,
<&clk_s_c0_quadfs 0>,
<&clk_s_c0_quadfs 1>,
<&clk_s_c0_quadfs 2>,
<&clk_s_c0_quadfs 3>,
<&clk_sysin>;
clock-output-names = "clk-icn-gpu",
"clk-fdma",
"clk-nand",
"clk-hva",
"clk-proc-stfe",
"clk-proc-tp",
"clk-rx-icn-dmu",
"clk-rx-icn-hva",
"clk-icn-cpu",
"clk-tx-icn-dmu",
"clk-mmc-0",
"clk-mmc-1",
"clk-jpegdec",
"clk-ext2fa9",
"clk-ic-bdisp-0",
"clk-ic-bdisp-1",
"clk-pp-dmu",
"clk-vid-dmu",
"clk-dss-lpc",
"clk-st231-aud-0",
"clk-st231-gp-1",
"clk-st231-dmu",
"clk-icn-lmi",
"clk-tx-icn-disp-1",
"clk-icn-sbc",
"clk-stfe-frc2",
"clk-eth-phy",
"clk-eth-ref-phyclk",
"clk-flash-promip",
"clk-main-disp",
"clk-aux-disp",
"clk-compo-dvp";
};

15
Documentation/devicetree/bindings/clock/st/st,quadfs.txt
View File

@@ -15,6 +15,9 @@ Required properties:
"st,stih416-quadfs432", "st,quadfs"
"st,stih416-quadfs660-E", "st,quadfs"
"st,stih416-quadfs660-F", "st,quadfs"
"st,stih407-quadfs660-C", "st,quadfs"
"st,stih407-quadfs660-D", "st,quadfs"
- #clock-cells : from common clock binding; shall be set to 1.
@@ -32,14 +35,14 @@ Required properties:
Example:
CLOCKGEN_E: CLOCKGEN_E {
clockgen_e: clockgen-e@fd3208bc {
#clock-cells = <1>;
compatible = "st,stih416-quadfs660-E", "st,quadfs";
reg = <0xfd3208bc 0xB0>;
clocks = <&CLK_SYSIN>;
clock-output-names = "CLK_M_PIX_MDTP_0",
"CLK_M_PIX_MDTP_1",
"CLK_M_PIX_MDTP_2",
"CLK_M_MPELPC";
clocks = <&clk_sysin>;
clock-output-names = "clk-m-pix-mdtp-0",
"clk-m-pix-mdtp-1",
"clk-m-pix-mdtp-2",
"clk-m-mpelpc";
};

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

@@ -9,11 +9,13 @@ Required properties:
"allwinner,sun4i-a10-osc-clk" - for a gatable oscillator
"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-pll5-clk" - for the PLL5 clock
"allwinner,sun4i-a10-pll6-clk" - for the PLL6 clock
"allwinner,sun6i-a31-pll6-clk" - for the PLL6 clock on A31
"allwinner,sun4i-a10-cpu-clk" - for the CPU multiplexer clock
"allwinner,sun4i-a10-axi-clk" - for the AXI clock
"allwinner,sun8i-a23-axi-clk" - for the AXI clock on A23
"allwinner,sun4i-a10-axi-gates-clk" - for the AXI gates
"allwinner,sun4i-a10-ahb-clk" - for the AHB clock
"allwinner,sun4i-a10-ahb-gates-clk" - for the AHB gates on A10
@@ -23,13 +25,16 @@ Required properties:
"allwinner,sun6i-a31-ar100-clk" - for the AR100 on A31
"allwinner,sun6i-a31-ahb1-mux-clk" - for the AHB1 multiplexer on A31
"allwinner,sun6i-a31-ahb1-gates-clk" - for the AHB1 gates on A31
"allwinner,sun8i-a23-ahb1-gates-clk" - for the AHB1 gates on A23
"allwinner,sun4i-a10-apb0-clk" - for the APB0 clock
"allwinner,sun6i-a31-apb0-clk" - for the APB0 clock on A31
"allwinner,sun8i-a23-apb0-clk" - for the APB0 clock on A23
"allwinner,sun4i-a10-apb0-gates-clk" - for the APB0 gates on A10
"allwinner,sun5i-a13-apb0-gates-clk" - for the APB0 gates on A13
"allwinner,sun5i-a10s-apb0-gates-clk" - for the APB0 gates on A10s
"allwinner,sun6i-a31-apb0-gates-clk" - for the APB0 gates on A31
"allwinner,sun7i-a20-apb0-gates-clk" - for the APB0 gates on A20
"allwinner,sun8i-a23-apb0-gates-clk" - for the APB0 gates on A23
"allwinner,sun4i-a10-apb1-clk" - for the APB1 clock
"allwinner,sun4i-a10-apb1-mux-clk" - for the APB1 clock muxing
"allwinner,sun4i-a10-apb1-gates-clk" - for the APB1 gates on A10
@@ -37,8 +42,10 @@ Required properties:
"allwinner,sun5i-a10s-apb1-gates-clk" - for the APB1 gates on A10s
"allwinner,sun6i-a31-apb1-gates-clk" - for the APB1 gates on A31
"allwinner,sun7i-a20-apb1-gates-clk" - for the APB1 gates on A20
"allwinner,sun8i-a23-apb1-gates-clk" - for the APB1 gates on A23
"allwinner,sun6i-a31-apb2-div-clk" - for the APB2 gates on A31
"allwinner,sun6i-a31-apb2-gates-clk" - for the APB2 gates on A31
"allwinner,sun8i-a23-apb2-gates-clk" - for the APB2 gates on A23
"allwinner,sun4i-a10-mod0-clk" - for the module 0 family of clocks
"allwinner,sun7i-a20-out-clk" - for the external output clocks
"allwinner,sun7i-a20-gmac-clk" - for the GMAC clock module on A20/A31

19
Documentation/devicetree/bindings/crypto/amd-ccp.txt Normal file
View File

@@ -0,0 +1,19 @@
* AMD Cryptographic Coprocessor driver (ccp)
Required properties:
- compatible: Should be "amd,ccp-seattle-v1a"
- reg: Address and length of the register set for the device
- interrupt-parent: Should be the phandle for the interrupt controller
that services interrupts for this device
- interrupts: Should contain the CCP interrupt
Optional properties:
- dma-coherent: Present if dma operations are coherent
Example:
ccp@e0100000 {
compatible = "amd,ccp-seattle-v1a";
reg = <0 0xe0100000 0 0x10000>;
interrupt-parent = <&gic>;
interrupts = <0 3 4>;
};

25
Documentation/devicetree/bindings/crypto/qcom-qce.txt Normal file
View File

@@ -0,0 +1,25 @@
Qualcomm crypto engine driver
Required properties:
- compatible : should be "qcom,crypto-v5.1"
- reg : specifies base physical address and size of the registers map
- clocks : phandle to clock-controller plus clock-specifier pair
- clock-names : "iface" clocks register interface
"bus" clocks data transfer interface
"core" clocks rest of the crypto block
- dmas : DMA specifiers for tx and rx dma channels. For more see
Documentation/devicetree/bindings/dma/dma.txt
- dma-names : DMA request names should be "rx" and "tx"
Example:
crypto@fd45a000 {
compatible = "qcom,crypto-v5.1";
reg = <0xfd45a000 0x6000>;
clocks = <&gcc GCC_CE2_AHB_CLK>,
<&gcc GCC_CE2_AXI_CLK>,
<&gcc GCC_CE2_CLK>;
clock-names = "iface", "bus", "core";
dmas = <&cryptobam 2>, <&cryptobam 3>;
dma-names = "rx", "tx";
};

1
Documentation/devicetree/bindings/dma/fsl-imx-sdma.txt
View File

@@ -47,6 +47,7 @@ The full ID of peripheral types can be found below.
20 ASRC
21 ESAI
22 SSI Dual FIFO (needs firmware ver >= 2)
23 Shared ASRC
The third cell specifies the transfer priority as below.

29
Documentation/devicetree/bindings/dma/mpc512x-dma.txt Normal file
View File

@@ -0,0 +1,29 @@
* Freescale MPC512x and MPC8308 DMA Controller
The DMA controller in Freescale MPC512x and MPC8308 SoCs can move
blocks of memory contents between memory and peripherals or
from memory to memory.
Refer to "Generic DMA Controller and DMA request bindings" in
the dma/dma.txt file for a more detailed description of binding.
Required properties:
- compatible: should be "fsl,mpc5121-dma" or "fsl,mpc8308-dma";
- reg: should contain the DMA controller registers location and length;
- interrupt for the DMA controller: syntax of interrupt client node
is described in interrupt-controller/interrupts.txt file.
- #dma-cells: the length of the DMA specifier, must be <1>.
Each channel of this DMA controller has a peripheral request line,
the assignment is fixed in hardware. This one cell
in dmas property of a client device represents the channel number.
Example:
dma0: dma@14000 {
compatible = "fsl,mpc5121-dma";
reg = <0x14000 0x1800>;
interrupts = <65 0x8>;
#dma-cells = <1>;
};
DMA clients must use the format described in dma/dma.txt file.

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