xiaomi-sm8450/android_kernel_xiaomi_sm8450
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Merge branch 'master' into for-next

Browse Source 
Sync with Linus' tree to be able to apply fixes on top of newer things
in tree (efi-stub).

Signed-off-by: Jiri Kosina <jkosina@suse.cz>
This commit is contained in:
Jiri Kosina
2013-12-19 15:08:03 +01:00
parent b481c2cb35 319e2e3f63
commit e23c34bb41
11720 changed files with 574391 additions and 276332 deletions
Download Patch File Download Diff File Expand all files Collapse all files

20
CREDITS
View File

@@ -655,6 +655,11 @@ S: Stanford University
S: Stanford, California 94305
S: USA
N: Carlos Chinea
E: carlos.chinea@nokia.com
E: cch.devel@gmail.com
D: Author of HSI Subsystem
N: Randolph Chung
E: tausq@debian.org
D: Linux/PA-RISC hacker
@@ -2576,7 +2581,7 @@ S: Toronto, Ontario
S: Canada
N: Zwane Mwaikambo
E: zwane@arm.linux.org.uk
E: zwanem@gmail.com
D: Various driver hacking
D: Lowlevel x86 kernel hacking
D: General debugging
@@ -2808,8 +2813,7 @@ S: Ottawa, Ontario
S: Canada K2P 0X8
N: Mikael Pettersson
E: mikpe@it.uu.se
W: http://user.it.uu.se/~mikpe/linux/
E: mikpelinux@gmail.com
D: Miscellaneous fixes
N: Reed H. Petty
@@ -2896,6 +2900,11 @@ S: Framewood Road
S: Wexham SL3 6PJ
S: United Kingdom
N: Richard Purdie
E: rpurdie@rpsys.net
D: Backlight subsystem maintainer
S: United Kingdom
N: Daniel Quinlan
E: quinlan@pathname.com
W: http://www.pathname.com/~quinlan/
@@ -3153,6 +3162,11 @@ N: Dipankar Sarma
E: dipankar@in.ibm.com
D: RCU
N: Yoshinori Sato
E: ysato@users.sourceforge.jp
D: uClinux for Renesas H8/300 (H8300)
D: http://uclinux-h8.sourceforge.jp/
N: Hannu Savolainen
E: hannu@opensound.com
D: Maintainer of the sound drivers until 2.1.x days.

13
Documentation/ABI/README
View File

@@ -72,3 +72,16 @@ kernel tree without going through the obsolete state first.
It's up to the developer to place their interfaces in the category they
wish for it to start out in.
Notable bits of non-ABI, which should not under any circumstances be considered
stable:
- Kconfig. Userspace should not rely on the presence or absence of any
particular Kconfig symbol, in /proc/config.gz, in the copy of .config
commonly installed to /boot, or in any invocation of the kernel build
process.
- Kernel-internal symbols. Do not rely on the presence, absence, location, or
type of any kernel symbol, either in System.map files or the kernel binary
itself. See Documentation/stable_api_nonsense.txt.

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

@@ -37,8 +37,8 @@ Description:
that the USB device has been connected to the machine. This
file is read-only.
Users:
PowerTOP <power@bughost.org>
http://www.lesswatts.org/projects/powertop/
PowerTOP <powertop@lists.01.org>
https://01.org/powertop/
What: /sys/bus/usb/device/.../power/active_duration
Date: January 2008
@@ -57,8 +57,8 @@ Description:
will give an integer percentage. Note that this does not
account for counter wrap.
Users:
PowerTOP <power@bughost.org>
http://www.lesswatts.org/projects/powertop/
PowerTOP <powertop@lists.01.org>
https://01.org/powertop/
What: /sys/bus/usb/devices/<busnum>-<port[.port]>...:<config num>-<interface num>/supports_autosuspend
Date: January 2008

13
Documentation/ABI/stable/sysfs-driver-ib_srp
View File

@@ -61,6 +61,12 @@ Description: Interface for making ib_srp connect to a new target.
interrupt is handled by a different CPU then the comp_vector
parameter can be used to spread the SRP completion workload
over multiple CPU's.
* tl_retry_count, a number in the range 2..7 specifying the
IB RC retry count.
* queue_size, the maximum number of commands that the
initiator is allowed to queue per SCSI host. The default
value for this parameter is 62. The lowest supported value
is 2.
What: /sys/class/infiniband_srp/srp-<hca>-<port_number>/ibdev
Date: January 2, 2006
@@ -153,6 +159,13 @@ Contact: linux-rdma@vger.kernel.org
Description: InfiniBand service ID used for establishing communication with
the SRP target.
What: /sys/class/scsi_host/host<n>/sgid
Date: February 1, 2014
KernelVersion: 3.13
Contact: linux-rdma@vger.kernel.org
Description: InfiniBand GID of the source port used for communication with
the SRP target.
What: /sys/class/scsi_host/host<n>/zero_req_lim
Date: September 20, 2006
KernelVersion: 2.6.18

39
Documentation/ABI/stable/sysfs-transport-srp
View File

@@ -5,6 +5,24 @@ Contact: linux-scsi@vger.kernel.org, linux-rdma@vger.kernel.org
Description: Instructs an SRP initiator to disconnect from a target and to
remove all LUNs imported from that target.
What: /sys/class/srp_remote_ports/port-<h>:<n>/dev_loss_tmo
Date: February 1, 2014
KernelVersion: 3.13
Contact: linux-scsi@vger.kernel.org, linux-rdma@vger.kernel.org
Description: Number of seconds the SCSI layer will wait after a transport
layer error has been observed before removing a target port.
Zero means immediate removal. Setting this attribute to "off"
will disable the dev_loss timer.
What: /sys/class/srp_remote_ports/port-<h>:<n>/fast_io_fail_tmo
Date: February 1, 2014
KernelVersion: 3.13
Contact: linux-scsi@vger.kernel.org, linux-rdma@vger.kernel.org
Description: Number of seconds the SCSI layer will wait after a transport
layer error has been observed before failing I/O. Zero means
failing I/O immediately. Setting this attribute to "off" will
disable the fast_io_fail timer.
What: /sys/class/srp_remote_ports/port-<h>:<n>/port_id
Date: June 27, 2007
KernelVersion: 2.6.24
@@ -12,8 +30,29 @@ Contact: linux-scsi@vger.kernel.org
Description: 16-byte local SRP port identifier in hexadecimal format. An
example: 4c:49:4e:55:58:20:56:49:4f:00:00:00:00:00:00:00.
What: /sys/class/srp_remote_ports/port-<h>:<n>/reconnect_delay
Date: February 1, 2014
KernelVersion: 3.13
Contact: linux-scsi@vger.kernel.org, linux-rdma@vger.kernel.org
Description: Number of seconds the SCSI layer will wait after a reconnect
attempt failed before retrying. Setting this attribute to
"off" will disable time-based reconnecting.
What: /sys/class/srp_remote_ports/port-<h>:<n>/roles
Date: June 27, 2007
KernelVersion: 2.6.24
Contact: linux-scsi@vger.kernel.org
Description: Role of the remote port. Either "SRP Initiator" or "SRP Target".
What: /sys/class/srp_remote_ports/port-<h>:<n>/state
Date: February 1, 2014
KernelVersion: 3.13
Contact: linux-scsi@vger.kernel.org, linux-rdma@vger.kernel.org
Description: State of the transport layer used for communication with the
remote port. "running" if the transport layer is operational;
"blocked" if a transport layer error has been encountered but
the fast_io_fail_tmo timer has not yet fired; "fail-fast"
after the fast_io_fail_tmo timer has fired and before the
"dev_loss_tmo" timer has fired; "lost" after the
"dev_loss_tmo" timer has fired and before the port is finally
removed.

31
Documentation/ABI/testing/configfs-usb-gadget-mass-storage Normal file
View File

@@ -0,0 +1,31 @@
What: /config/usb-gadget/gadget/functions/mass_storage.name
Date: Oct 2013
KenelVersion: 3.13
Description:
The attributes:
stall - Set to permit function to halt bulk endpoints.
Disabled on some USB devices known not to work
correctly. You should set it to true.
num_buffers - Number of pipeline buffers. Valid numbers
are 2..4. Available only if
CONFIG_USB_GADGET_DEBUG_FILES is set.
What: /config/usb-gadget/gadget/functions/mass_storage.name/lun.name
Date: Oct 2013
KenelVersion: 3.13
Description:
The attributes:
file - The path to the backing file for the LUN.
Required if LUN is not marked as removable.
ro - Flag specifying access to the LUN shall be
read-only. This is implied if CD-ROM emulation
is enabled as well as when it was impossible
to open "filename" in R/W mode.
removable - Flag specifying that LUN shall be indicated as
being removable.
cdrom - Flag specifying that LUN shall be reported as
being a CD-ROM.
nofua - Flag specifying that FUA flag
in SCSI WRITE(10,12)

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

@@ -79,7 +79,7 @@ Description:
correspond to externally available input one of the named
versions may be used. The number must always be specified and
unique to allow association with event codes. Units after
application of scale and offset are microvolts.
application of scale and offset are millivolts.
What: /sys/bus/iio/devices/iio:deviceX/in_voltageY-voltageZ_raw
KernelVersion: 2.6.35
@@ -90,7 +90,7 @@ Description:
physically equivalent inputs when non differential readings are
separately available. In differential only parts, then all that
is required is a consistent labeling. Units after application
of scale and offset are microvolts.
of scale and offset are millivolts.
What: /sys/bus/iio/devices/iio:deviceX/in_capacitanceY_raw
KernelVersion: 3.2
@@ -537,6 +537,62 @@ Description:
value is in raw device units or in processed units (as _raw
and _input do on sysfs direct channel read attributes).
What: /sys/.../events/in_accel_x_thresh_rising_hysteresis
What: /sys/.../events/in_accel_x_thresh_falling_hysteresis
What: /sys/.../events/in_accel_x_thresh_either_hysteresis
What: /sys/.../events/in_accel_y_thresh_rising_hysteresis
What: /sys/.../events/in_accel_y_thresh_falling_hysteresis
What: /sys/.../events/in_accel_y_thresh_either_hysteresis
What: /sys/.../events/in_accel_z_thresh_rising_hysteresis
What: /sys/.../events/in_accel_z_thresh_falling_hysteresis
What: /sys/.../events/in_accel_z_thresh_either_hysteresis
What: /sys/.../events/in_anglvel_x_thresh_rising_hysteresis
What: /sys/.../events/in_anglvel_x_thresh_falling_hysteresis
What: /sys/.../events/in_anglvel_x_thresh_either_hysteresis
What: /sys/.../events/in_anglvel_y_thresh_rising_hysteresis
What: /sys/.../events/in_anglvel_y_thresh_falling_hysteresis
What: /sys/.../events/in_anglvel_y_thresh_either_hysteresis
What: /sys/.../events/in_anglvel_z_thresh_rising_hysteresis
What: /sys/.../events/in_anglvel_z_thresh_falling_hysteresis
What: /sys/.../events/in_anglvel_z_thresh_either_hysteresis
What: /sys/.../events/in_magn_x_thresh_rising_hysteresis
What: /sys/.../events/in_magn_x_thresh_falling_hysteresis
What: /sys/.../events/in_magn_x_thresh_either_hysteresis
What: /sys/.../events/in_magn_y_thresh_rising_hysteresis
What: /sys/.../events/in_magn_y_thresh_falling_hysteresis
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_voltageY_thresh_rising_hysteresis
What: /sys/.../events/in_voltageY_thresh_falling_hysteresis
What: /sys/.../events/in_voltageY_thresh_either_hysteresis
What: /sys/.../events/in_tempY_thresh_rising_hysteresis
What: /sys/.../events/in_tempY_thresh_falling_hysteresis
What: /sys/.../events/in_tempY_thresh_either_hysteresis
What: /sys/.../events/in_illuminance0_thresh_falling_hysteresis
what: /sys/.../events/in_illuminance0_thresh_rising_hysteresis
what: /sys/.../events/in_illuminance0_thresh_either_hysteresis
what: /sys/.../events/in_proximity0_thresh_falling_hysteresis
what: /sys/.../events/in_proximity0_thresh_rising_hysteresis
what: /sys/.../events/in_proximity0_thresh_either_hysteresis
KernelVersion: 3.13
Contact: linux-iio@vger.kernel.org
Description:
Specifies the hysteresis of threshold that the device is comparing
against for the events enabled by
<type>Y[_name]_thresh[_(rising|falling)]_hysteresis.
If separate attributes exist for the two directions, but
direction is not specified for this attribute, then a single
hysteresis value applies to both directions.
For falling events the hysteresis is added to the _value attribute for
this event to get the upper threshold for when the event goes back to
normal, for rising events the hysteresis is subtracted from the _value
attribute. E.g. if in_voltage0_raw_thresh_rising_value is set to 1200
and in_voltage0_raw_thresh_rising_hysteresis is set to 50. The event
will get activated once in_voltage0_raw goes above 1200 and will become
deactived again once the value falls below 1150.
What: /sys/.../events/in_accel_x_raw_roc_rising_value
What: /sys/.../events/in_accel_x_raw_roc_falling_value
What: /sys/.../events/in_accel_y_raw_roc_rising_value
@@ -811,3 +867,14 @@ Description:
Writing '1' stores the current device configuration into
on-chip EEPROM. After power-up or chip reset the device will
automatically load the saved configuration.
What: /sys/.../iio:deviceX/in_intensity_red_integration_time
What: /sys/.../iio:deviceX/in_intensity_green_integration_time
What: /sys/.../iio:deviceX/in_intensity_blue_integration_time
What: /sys/.../iio:deviceX/in_intensity_clear_integration_time
What: /sys/.../iio:deviceX/in_illuminance_integration_time
KernelVersion: 3.12
Contact: linux-iio@vger.kernel.org
Description:
This attribute is used to get/set the integration time in
seconds.

157
Documentation/ABI/testing/sysfs-class-mic.txt Normal file
View File

@@ -0,0 +1,157 @@
What: /sys/class/mic/
Date: October 2013
KernelVersion: 3.13
Contact: Sudeep Dutt <sudeep.dutt@intel.com>
Description:
The mic class directory belongs to Intel MIC devices and
provides information per MIC device. An Intel MIC device is a
PCIe form factor add-in Coprocessor card based on the Intel Many
Integrated Core (MIC) architecture that runs a Linux OS.
What: /sys/class/mic/mic(x)
Date: October 2013
KernelVersion: 3.13
Contact: Sudeep Dutt <sudeep.dutt@intel.com>
Description:
The directories /sys/class/mic/mic0, /sys/class/mic/mic1 etc.,
represent MIC devices (0,1,..etc). Each directory has
information specific to that MIC device.
What: /sys/class/mic/mic(x)/family
Date: October 2013
KernelVersion: 3.13
Contact: Sudeep Dutt <sudeep.dutt@intel.com>
Description:
Provides information about the Coprocessor family for an Intel
MIC device. For example - "x100"
What: /sys/class/mic/mic(x)/stepping
Date: October 2013
KernelVersion: 3.13
Contact: Sudeep Dutt <sudeep.dutt@intel.com>
Description:
Provides information about the silicon stepping for an Intel
MIC device. For example - "A0" or "B0"
What: /sys/class/mic/mic(x)/state
Date: October 2013
KernelVersion: 3.13
Contact: Sudeep Dutt <sudeep.dutt@intel.com>
Description:
When read, this entry provides the current state of an Intel
MIC device in the context of the card OS. Possible values that
will be read are:
"offline" - The MIC device is ready to boot the card OS. On
reading this entry after an OSPM resume, a "boot" has to be
written to this entry if the card was previously shutdown
during OSPM suspend.
"online" - The MIC device has initiated booting a card OS.
"shutting_down" - The card OS is shutting down.
"reset_failed" - The MIC device has failed to reset.
"suspending" - The MIC device is currently being prepared for
suspend. On reading this entry, a "suspend" has to be written
to the state sysfs entry to ensure the card is shutdown during
OSPM suspend.
"suspended" - The MIC device has been suspended.
When written, this sysfs entry triggers different state change
operations depending upon the current state of the card OS.
Acceptable values are:
"boot" - Boot the card OS image specified by the combination
of firmware, ramdisk, cmdline and bootmode
sysfs entries.
"reset" - Initiates device reset.
"shutdown" - Initiates card OS shutdown.
"suspend" - Initiates card OS shutdown and also marks the card
as suspended.
What: /sys/class/mic/mic(x)/shutdown_status
Date: October 2013
KernelVersion: 3.13
Contact: Sudeep Dutt <sudeep.dutt@intel.com>
Description:
An Intel MIC device runs a Linux OS during its operation. This
OS can shutdown because of various reasons. When read, this
entry provides the status on why the card OS was shutdown.
Possible values are:
"nop" - shutdown status is not applicable, when the card OS is
"online"
"crashed" - Shutdown because of a HW or SW crash.
"halted" - Shutdown because of a halt command.
"poweroff" - Shutdown because of a poweroff command.
"restart" - Shutdown because of a restart command.
What: /sys/class/mic/mic(x)/cmdline
Date: October 2013
KernelVersion: 3.13
Contact: Sudeep Dutt <sudeep.dutt@intel.com>
Description:
An Intel MIC device runs a Linux OS during its operation. Before
booting this card OS, it is possible to pass kernel command line
options to configure various features in it, similar to
self-bootable machines. When read, this entry provides
information about the current kernel command line options set to
boot the card OS. This entry can be written to change the
existing kernel command line options. Typically, the user would
want to read the current command line options, append new ones
or modify existing ones and then write the whole kernel command
line back to this entry.
What: /sys/class/mic/mic(x)/firmware
Date: October 2013
KernelVersion: 3.13
Contact: Sudeep Dutt <sudeep.dutt@intel.com>
Description:
When read, this sysfs entry provides the path name under
/lib/firmware/ where the firmware image to be booted on the
card can be found. The entry can be written to change the
firmware image location under /lib/firmware/.
What: /sys/class/mic/mic(x)/ramdisk
Date: October 2013
KernelVersion: 3.13
Contact: Sudeep Dutt <sudeep.dutt@intel.com>
Description:
When read, this sysfs entry provides the path name under
/lib/firmware/ where the ramdisk image to be used during card
OS boot can be found. The entry can be written to change
the ramdisk image location under /lib/firmware/.
What: /sys/class/mic/mic(x)/bootmode
Date: October 2013
KernelVersion: 3.13
Contact: Sudeep Dutt <sudeep.dutt@intel.com>
Description:
When read, this sysfs entry provides the current bootmode for
the card. This sysfs entry can be written with the following
valid strings:
a) linux - Boot a Linux image.
b) elf - Boot an elf image for flash updates.
What: /sys/class/mic/mic(x)/log_buf_addr
Date: October 2013
KernelVersion: 3.13
Contact: Sudeep Dutt <sudeep.dutt@intel.com>
Description:
An Intel MIC device runs a Linux OS during its operation. For
debugging purpose and early kernel boot messages, the user can
access the card OS log buffer via debugfs. When read, this entry
provides the kernel virtual address of the buffer where the card
OS log buffer can be read. This entry is written by the host
configuration daemon to set the log buffer address. The correct
log buffer address to be written can be found in the System.map
file of the card OS.
What: /sys/class/mic/mic(x)/log_buf_len
Date: October 2013
KernelVersion: 3.13
Contact: Sudeep Dutt <sudeep.dutt@intel.com>
Description:
An Intel MIC device runs a Linux OS during its operation. For
debugging purpose and early kernel boot messages, the user can
access the card OS log buffer via debugfs. When read, this entry
provides the kernel virtual address where the card OS log buffer
length can be read. This entry is written by host configuration
daemon to set the log buffer length address. The correct log
buffer length address to be written can be found in the
System.map file of the card OS.

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

@@ -104,7 +104,7 @@ Description:
One of the following ASCII strings, representing the device
type:
absent, ram, rom, nor, nand, dataflash, ubi, unknown
absent, ram, rom, nor, nand, mlc-nand, dataflash, ubi, unknown
What: /sys/class/mtd/mtdX/writesize
Date: April 2009
@@ -128,9 +128,8 @@ KernelVersion: 3.4
Contact: linux-mtd@lists.infradead.org
Description:
Maximum number of bit errors that the device is capable of
correcting within each region covering an ecc step. This will
always be a non-negative integer. Note that some devices will
have multiple ecc steps within each writesize region.
correcting within each region covering an ECC step (see
ecc_step_size). This will always be a non-negative integer.
In the case of devices lacking any ECC capability, it is 0.
@@ -173,3 +172,15 @@ Description:
This is generally applicable only to NAND flash devices with ECC
capability. It is ignored on devices lacking ECC capability;
i.e., devices for which ecc_strength is zero.
What: /sys/class/mtd/mtdX/ecc_step_size
Date: May 2013
KernelVersion: 3.10
Contact: linux-mtd@lists.infradead.org
Description:
The size of a single region covered by ECC, known as the ECC
step. Devices may have several equally sized ECC steps within
each writesize region.
It will always be a non-negative integer. In the case of
devices lacking any ECC capability, it is 0.

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

@@ -1,13 +1,13 @@
What: /sys/class/net/<iface>/batman-adv/iface_status
Date: May 2010
Contact: Marek Lindner <lindner_marek@yahoo.de>
Contact: Marek Lindner <mareklindner@neomailbox.ch>
Description:
Indicates the status of <iface> as it is seen by batman.
What: /sys/class/net/<iface>/batman-adv/mesh_iface
Date: May 2010
Contact: Marek Lindner <lindner_marek@yahoo.de>
Contact: Marek Lindner <mareklindner@neomailbox.ch>
Description:
The /sys/class/net/<iface>/batman-adv/mesh_iface file
displays the batman mesh interface this <iface>

34
Documentation/ABI/testing/sysfs-class-net-mesh
View File

@@ -1,22 +1,23 @@
What: /sys/class/net/<mesh_iface>/mesh/aggregated_ogms
Date: May 2010
Contact: Marek Lindner <lindner_marek@yahoo.de>
Contact: Marek Lindner <mareklindner@neomailbox.ch>
Description:
Indicates whether the batman protocol messages of the
mesh <mesh_iface> shall be aggregated or not.
What: /sys/class/net/<mesh_iface>/mesh/ap_isolation
What: /sys/class/net/<mesh_iface>/mesh/<vlan_subdir>/ap_isolation
Date: May 2011
Contact: Antonio Quartulli <ordex@autistici.org>
Contact: Antonio Quartulli <antonio@meshcoding.com>
Description:
Indicates whether the data traffic going from a
wireless client to another wireless client will be
silently dropped.
silently dropped. <vlan_subdir> is empty when referring
to the untagged lan.
What: /sys/class/net/<mesh_iface>/mesh/bonding
Date: June 2010
Contact: Simon Wunderlich <siwu@hrz.tu-chemnitz.de>
Contact: Simon Wunderlich <sw@simonwunderlich.de>
Description:
Indicates whether the data traffic going through the
mesh will be sent using multiple interfaces at the
@@ -24,7 +25,7 @@ Description:
What: /sys/class/net/<mesh_iface>/mesh/bridge_loop_avoidance
Date: November 2011
Contact: Simon Wunderlich <siwu@hrz.tu-chemnitz.de>
Contact: Simon Wunderlich <sw@simonwunderlich.de>
Description:
Indicates whether the bridge loop avoidance feature
is enabled. This feature detects and avoids loops
@@ -41,21 +42,21 @@ Description:
What: /sys/class/net/<mesh_iface>/mesh/gw_bandwidth
Date: October 2010
Contact: Marek Lindner <lindner_marek@yahoo.de>
Contact: Marek Lindner <mareklindner@neomailbox.ch>
Description:
Defines the bandwidth which is propagated by this
node if gw_mode was set to 'server'.
What: /sys/class/net/<mesh_iface>/mesh/gw_mode
Date: October 2010
Contact: Marek Lindner <lindner_marek@yahoo.de>
Contact: Marek Lindner <mareklindner@neomailbox.ch>
Description:
Defines the state of the gateway features. Can be
either 'off', 'client' or 'server'.
What: /sys/class/net/<mesh_iface>/mesh/gw_sel_class
Date: October 2010
Contact: Marek Lindner <lindner_marek@yahoo.de>
Contact: Marek Lindner <mareklindner@neomailbox.ch>
Description:
Defines the selection criteria this node will use
to choose a gateway if gw_mode was set to 'client'.
@@ -77,25 +78,14 @@ Description:
What: /sys/class/net/<mesh_iface>/mesh/orig_interval
Date: May 2010
Contact: Marek Lindner <lindner_marek@yahoo.de>
Contact: Marek Lindner <mareklindner@neomailbox.ch>
Description:
Defines the interval in milliseconds in which batman
sends its protocol messages.
What: /sys/class/net/<mesh_iface>/mesh/routing_algo
Date: Dec 2011
Contact: Marek Lindner <lindner_marek@yahoo.de>
Contact: Marek Lindner <mareklindner@neomailbox.ch>
Description:
Defines the routing procotol this mesh instance
uses to find the optimal paths through the mesh.
What: /sys/class/net/<mesh_iface>/mesh/vis_mode
Date: May 2010
Contact: Marek Lindner <lindner_marek@yahoo.de>
Description:
Each batman node only maintains information about its
own local neighborhood, therefore generating graphs
showing the topology of the entire mesh is not easily
feasible without having a central instance to collect
the local topologies from all nodes. This file allows
to activate the collecting (server) mode.

152
Documentation/ABI/testing/sysfs-class-powercap Normal file
View File

@@ -0,0 +1,152 @@
What: /sys/class/powercap/
Date: September 2013
KernelVersion: 3.13
Contact: linux-pm@vger.kernel.org
Description:
The powercap/ class sub directory belongs to the power cap
subsystem. Refer to
Documentation/power/powercap/powercap.txt for details.
What: /sys/class/powercap/<control type>
Date: September 2013
KernelVersion: 3.13
Contact: linux-pm@vger.kernel.org
Description:
A <control type> is a unique name under /sys/class/powercap.
Here <control type> determines how the power is going to be
controlled. A <control type> can contain multiple power zones.
What: /sys/class/powercap/<control type>/enabled
Date: September 2013
KernelVersion: 3.13
Contact: linux-pm@vger.kernel.org
Description:
This allows to enable/disable power capping for a "control type".
This status affects every power zone using this "control_type.
What: /sys/class/powercap/<control type>/<power zone>
Date: September 2013
KernelVersion: 3.13
Contact: linux-pm@vger.kernel.org
Description:
A power zone is a single or a collection of devices, which can
be independently monitored and controlled. A power zone sysfs
entry is qualified with the name of the <control type>.
E.g. intel-rapl:0:1:1.
What: /sys/class/powercap/<control type>/<power zone>/<child power zone>
Date: September 2013
KernelVersion: 3.13
Contact: linux-pm@vger.kernel.org
Description:
Power zones may be organized in a hierarchy in which child
power zones provide monitoring and control for a subset of
devices under the parent. For example, if there is a parent
power zone for a whole CPU package, each CPU core in it can
be a child power zone.
What: /sys/class/powercap/.../<power zone>/name
Date: September 2013
KernelVersion: 3.13
Contact: linux-pm@vger.kernel.org
Description:
Specifies the name of this power zone.
What: /sys/class/powercap/.../<power zone>/energy_uj
Date: September 2013
KernelVersion: 3.13
Contact: linux-pm@vger.kernel.org
Description:
Current energy counter in micro-joules. Write "0" to reset.
If the counter can not be reset, then this attribute is
read-only.
What: /sys/class/powercap/.../<power zone>/max_energy_range_uj
Date: September 2013
KernelVersion: 3.13
Contact: linux-pm@vger.kernel.org
Description:
Range of the above energy counter in micro-joules.
What: /sys/class/powercap/.../<power zone>/power_uw
Date: September 2013
KernelVersion: 3.13
Contact: linux-pm@vger.kernel.org
Description:
Current power in micro-watts.
What: /sys/class/powercap/.../<power zone>/max_power_range_uw
Date: September 2013
KernelVersion: 3.13
Contact: linux-pm@vger.kernel.org
Description:
Range of the above power value in micro-watts.
What: /sys/class/powercap/.../<power zone>/constraint_X_name
Date: September 2013
KernelVersion: 3.13
Contact: linux-pm@vger.kernel.org
Description:
Each power zone can define one or more constraints. Each
constraint can have an optional name. Here "X" can have values
from 0 to max integer.
What: /sys/class/powercap/.../<power zone>/constraint_X_power_limit_uw
Date: September 2013
KernelVersion: 3.13
Contact: linux-pm@vger.kernel.org
Description:
Power limit in micro-watts should be applicable for
the time window specified by "constraint_X_time_window_us".
Here "X" can have values from 0 to max integer.
What: /sys/class/powercap/.../<power zone>/constraint_X_time_window_us
Date: September 2013
KernelVersion: 3.13
Contact: linux-pm@vger.kernel.org
Description:
Time window in micro seconds. This is used along with
constraint_X_power_limit_uw to define a power constraint.
Here "X" can have values from 0 to max integer.
What: /sys/class/powercap/<control type>/.../constraint_X_max_power_uw
Date: September 2013
KernelVersion: 3.13
Contact: linux-pm@vger.kernel.org
Description:
Maximum allowed power in micro watts for this constraint.
Here "X" can have values from 0 to max integer.
What: /sys/class/powercap/<control type>/.../constraint_X_min_power_uw
Date: September 2013
KernelVersion: 3.13
Contact: linux-pm@vger.kernel.org
Description:
Minimum allowed power in micro watts for this constraint.
Here "X" can have values from 0 to max integer.
What: /sys/class/powercap/.../<power zone>/constraint_X_max_time_window_us
Date: September 2013
KernelVersion: 3.13
Contact: linux-pm@vger.kernel.org
Description:
Maximum allowed time window in micro seconds for this
constraint. Here "X" can have values from 0 to max integer.
What: /sys/class/powercap/.../<power zone>/constraint_X_min_time_window_us
Date: September 2013
KernelVersion: 3.13
Contact: linux-pm@vger.kernel.org
Description:
Minimum allowed time window in micro seconds for this
constraint. Here "X" can have values from 0 to max integer.
What: /sys/class/powercap/.../<power zone>/enabled
Date: September 2013
KernelVersion: 3.13
Contact: linux-pm@vger.kernel.org
Description
This allows to enable/disable power capping at power zone level.
This applies to current power zone and its children.

32
Documentation/ABI/testing/sysfs-devices-power
View File

@@ -1,6 +1,6 @@
What: /sys/devices/.../power/
Date: January 2009
Contact: Rafael J. Wysocki <rjw@sisk.pl>
Contact: Rafael J. Wysocki <rjw@rjwysocki.net>
Description:
The /sys/devices/.../power directory contains attributes
allowing the user space to check and modify some power
@@ -8,7 +8,7 @@ Description:
What: /sys/devices/.../power/wakeup
Date: January 2009
Contact: Rafael J. Wysocki <rjw@sisk.pl>
Contact: Rafael J. Wysocki <rjw@rjwysocki.net>
Description:
The /sys/devices/.../power/wakeup attribute allows the user
space to check if the device is enabled to wake up the system
@@ -34,7 +34,7 @@ Description:
What: /sys/devices/.../power/control
Date: January 2009
Contact: Rafael J. Wysocki <rjw@sisk.pl>
Contact: Rafael J. Wysocki <rjw@rjwysocki.net>
Description:
The /sys/devices/.../power/control attribute allows the user
space to control the run-time power management of the device.
@@ -53,7 +53,7 @@ Description:
What: /sys/devices/.../power/async
Date: January 2009
Contact: Rafael J. Wysocki <rjw@sisk.pl>
Contact: Rafael J. Wysocki <rjw@rjwysocki.net>
Description:
The /sys/devices/.../async attribute allows the user space to
enable or diasble the device's suspend and resume callbacks to
@@ -79,7 +79,7 @@ Description:
What: /sys/devices/.../power/wakeup_count
Date: September 2010
Contact: Rafael J. Wysocki <rjw@sisk.pl>
Contact: Rafael J. Wysocki <rjw@rjwysocki.net>
Description:
The /sys/devices/.../wakeup_count attribute contains the number
of signaled wakeup events associated with the device. This
@@ -88,7 +88,7 @@ Description:
What: /sys/devices/.../power/wakeup_active_count
Date: September 2010
Contact: Rafael J. Wysocki <rjw@sisk.pl>
Contact: Rafael J. Wysocki <rjw@rjwysocki.net>
Description:
The /sys/devices/.../wakeup_active_count attribute contains the
number of times the processing of wakeup events associated with
@@ -98,7 +98,7 @@ Description:
What: /sys/devices/.../power/wakeup_abort_count
Date: February 2012
Contact: Rafael J. Wysocki <rjw@sisk.pl>
Contact: Rafael J. Wysocki <rjw@rjwysocki.net>
Description:
The /sys/devices/.../wakeup_abort_count attribute contains the
number of times the processing of a wakeup event associated with
@@ -109,7 +109,7 @@ Description:
What: /sys/devices/.../power/wakeup_expire_count
Date: February 2012
Contact: Rafael J. Wysocki <rjw@sisk.pl>
Contact: Rafael J. Wysocki <rjw@rjwysocki.net>
Description:
The /sys/devices/.../wakeup_expire_count attribute contains the
number of times a wakeup event associated with the device has
@@ -119,7 +119,7 @@ Description:
What: /sys/devices/.../power/wakeup_active
Date: September 2010
Contact: Rafael J. Wysocki <rjw@sisk.pl>
Contact: Rafael J. Wysocki <rjw@rjwysocki.net>
Description:
The /sys/devices/.../wakeup_active attribute contains either 1,
or 0, depending on whether or not a wakeup event associated with
@@ -129,7 +129,7 @@ Description:
What: /sys/devices/.../power/wakeup_total_time_ms
Date: September 2010
Contact: Rafael J. Wysocki <rjw@sisk.pl>
Contact: Rafael J. Wysocki <rjw@rjwysocki.net>
Description:
The /sys/devices/.../wakeup_total_time_ms attribute contains
the total time of processing wakeup events associated with the
@@ -139,7 +139,7 @@ Description:
What: /sys/devices/.../power/wakeup_max_time_ms
Date: September 2010
Contact: Rafael J. Wysocki <rjw@sisk.pl>
Contact: Rafael J. Wysocki <rjw@rjwysocki.net>
Description:
The /sys/devices/.../wakeup_max_time_ms attribute contains
the maximum time of processing a single wakeup event associated
@@ -149,7 +149,7 @@ Description:
What: /sys/devices/.../power/wakeup_last_time_ms
Date: September 2010
Contact: Rafael J. Wysocki <rjw@sisk.pl>
Contact: Rafael J. Wysocki <rjw@rjwysocki.net>
Description:
The /sys/devices/.../wakeup_last_time_ms attribute contains
the value of the monotonic clock corresponding to the time of
@@ -160,7 +160,7 @@ Description:
What: /sys/devices/.../power/wakeup_prevent_sleep_time_ms
Date: February 2012
Contact: Rafael J. Wysocki <rjw@sisk.pl>
Contact: Rafael J. Wysocki <rjw@rjwysocki.net>
Description:
The /sys/devices/.../wakeup_prevent_sleep_time_ms attribute
contains the total time the device has been preventing
@@ -189,7 +189,7 @@ Description:
What: /sys/devices/.../power/pm_qos_latency_us
Date: March 2012
Contact: Rafael J. Wysocki <rjw@sisk.pl>
Contact: Rafael J. Wysocki <rjw@rjwysocki.net>
Description:
The /sys/devices/.../power/pm_qos_resume_latency_us attribute
contains the PM QoS resume latency limit for the given device,
@@ -207,7 +207,7 @@ Description:
What: /sys/devices/.../power/pm_qos_no_power_off
Date: September 2012
Contact: Rafael J. Wysocki <rjw@sisk.pl>
Contact: Rafael J. Wysocki <rjw@rjwysocki.net>
Description:
The /sys/devices/.../power/pm_qos_no_power_off attribute
is used for manipulating the PM QoS "no power off" flag. If
@@ -222,7 +222,7 @@ Description:
What: /sys/devices/.../power/pm_qos_remote_wakeup
Date: September 2012
Contact: Rafael J. Wysocki <rjw@sisk.pl>
Contact: Rafael J. Wysocki <rjw@rjwysocki.net>
Description:
The /sys/devices/.../power/pm_qos_remote_wakeup attribute
is used for manipulating the PM QoS "remote wakeup required"

178
Documentation/ABI/testing/sysfs-driver-hid-roccat-ryos Normal file
View File

@@ -0,0 +1,178 @@
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/ryos/roccatryos<minor>/control
Date: October 2013
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
Description: When written, this file lets one select which data from which
profile will be read next. The data has to be 3 bytes long.
This file is writeonly.
Users: http://roccat.sourceforge.net
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/ryos/roccatryos<minor>/profile
Date: October 2013
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
Description: The mouse can store 5 profiles which can be switched by the
press of a button. profile holds index of actual profile.
This value is persistent, so its value determines the profile
that's active when the device is powered on next time.
When written, the device activates the set profile immediately.
The data has to be 3 bytes long.
The device will reject invalid data.
Users: http://roccat.sourceforge.net
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/ryos/roccatryos<minor>/keys_primary
Date: October 2013
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
Description: When written, this file lets one set the default of all keys for
a specific profile. Profile index is included in written data.
The data has to be 125 bytes long.
Before reading this file, control has to be written to select
which profile to read.
Users: http://roccat.sourceforge.net
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/ryos/roccatryos<minor>/keys_function
Date: October 2013
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
Description: When written, this file lets one set the function of the
function keys for a specific profile. Profile index is included
in written data. The data has to be 95 bytes long.
Before reading this file, control has to be written to select
which profile to read.
Users: http://roccat.sourceforge.net
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/ryos/roccatryos<minor>/keys_macro
Date: October 2013
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
Description: When written, this file lets one set the function of the macro
keys for a specific profile. Profile index is included in
written data. The data has to be 35 bytes long.
Before reading this file, control has to be written to select
which profile to read.
Users: http://roccat.sourceforge.net
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/ryos/roccatryos<minor>/keys_thumbster
Date: October 2013
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
Description: When written, this file lets one set the function of the
thumbster keys for a specific profile. Profile index is included
in written data. The data has to be 23 bytes long.
Before reading this file, control has to be written to select
which profile to read.
Users: http://roccat.sourceforge.net
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/ryos/roccatryos<minor>/keys_extra
Date: October 2013
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
Description: When written, this file lets one set the function of the
capslock and function keys for a specific profile. Profile index
is included in written data. The data has to be 8 bytes long.
Before reading this file, control has to be written to select
which profile to read.
Users: http://roccat.sourceforge.net
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/ryos/roccatryos<minor>/keys_easyzone
Date: October 2013
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
Description: When written, this file lets one set the function of the
easyzone keys for a specific profile. Profile index is included
in written data. The data has to be 294 bytes long.
Before reading this file, control has to be written to select
which profile to read.
Users: http://roccat.sourceforge.net
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/ryos/roccatryos<minor>/key_mask
Date: October 2013
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
Description: When written, this file lets one deactivate certain keys like
windows and application keys, to prevent accidental presses.
Profile index for which this settings occur is included in
written data. The data has to be 6 bytes long.
Before reading this file, control has to be written to select
which profile to read.
Users: http://roccat.sourceforge.net
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/ryos/roccatryos<minor>/light
Date: October 2013
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
Description: When written, this file lets one set the backlight intensity for
a specific profile. Profile index is included in written data.
This attribute is only valid for the glow and pro variant.
The data has to be 16 bytes long.
Before reading this file, control has to be written to select
which profile to read.
Users: http://roccat.sourceforge.net
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/ryos/roccatryos<minor>/macro
Date: October 2013
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
Description: When written, this file lets one store macros with max 480
keystrokes for a specific button for a specific profile.
Button and profile indexes are included in written data.
The data has to be 2002 bytes long.
Before reading this file, control has to be written to select
which profile and key to read.
Users: http://roccat.sourceforge.net
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/ryos/roccatryos<minor>/info
Date: October 2013
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
Description: When read, this file returns general data like firmware version.
The data is 8 bytes long.
This file is readonly.
Users: http://roccat.sourceforge.net
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/ryos/roccatryos<minor>/reset
Date: October 2013
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
Description: When written, this file lets one reset the device.
The data has to be 3 bytes long.
This file is writeonly.
Users: http://roccat.sourceforge.net
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/ryos/roccatryos<minor>/talk
Date: October 2013
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
Description: When written, this file lets one trigger easyshift functionality
from the host.
The data has to be 16 bytes long.
This file is writeonly.
Users: http://roccat.sourceforge.net
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/ryos/roccatryos<minor>/light_control
Date: October 2013
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
Description: When written, this file lets one switch between stored and custom
light settings.
This attribute is only valid for the pro variant.
The data has to be 8 bytes long.
This file is writeonly.
Users: http://roccat.sourceforge.net
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/ryos/roccatryos<minor>/stored_lights
Date: October 2013
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
Description: When written, this file lets one set per-key lighting for different
layers.
This attribute is only valid for the pro variant.
The data has to be 1382 bytes long.
Before reading this file, control has to be written to select
which profile to read.
Users: http://roccat.sourceforge.net
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/ryos/roccatryos<minor>/custom_lights
Date: October 2013
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
Description: When written, this file lets one set the actual per-key lighting.
This attribute is only valid for the pro variant.
The data has to be 20 bytes long.
This file is writeonly.
Users: http://roccat.sourceforge.net
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/ryos/roccatryos<minor>/light_macro
Date: October 2013
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
Description: When written, this file lets one set a light macro that is looped
whenever the device gets in dimness mode.
This attribute is only valid for the pro variant.
The data has to be 2002 bytes long.
Before reading this file, control has to be written to select
which profile to read.
Users: http://roccat.sourceforge.net

18
Documentation/ABI/testing/sysfs-driver-hid-wiimote
View File

@@ -57,3 +57,21 @@ Description: This attribute is only provided if the device was detected as a
Calibration data is already applied by the kernel to all input
values but may be used by user-space to perform other
transformations.
What: /sys/bus/hid/drivers/wiimote/<dev>/pro_calib
Date: October 2013
KernelVersion: 3.13
Contact: David Herrmann <dh.herrmann@gmail.com>
Description: This attribute is only provided if the device was detected as a
pro-controller. It provides a single line with 4 calibration
values for all 4 analog sticks. Format is: "x1:y1 x2:y2". Data
is prefixed with a +/-. Each value is a signed 16bit number.
Data is encoded as decimal numbers and specifies the offsets of
the analog sticks of the pro-controller.
Calibration data is already applied by the kernel to all input
values but may be used by user-space to perform other
transformations.
Calibration data is detected by the kernel during device setup.
You can write "scan\n" into this file to re-trigger calibration.
You can also write data directly in the form "x1:y1 x2:y2" to
set the calibration values manually.

22
Documentation/ABI/testing/sysfs-driver-sunxi-sid Normal file
View File

@@ -0,0 +1,22 @@
What: /sys/devices/*/<our-device>/eeprom
Date: August 2013
Contact: Oliver Schinagl <oliver@schinagl.nl>
Description: read-only access to the SID (Security-ID) on current
A-series SoC's from Allwinner. Currently supports A10, A10s, A13
and A20 CPU's. The earlier A1x series of SoCs exports 16 bytes,
whereas the newer A20 SoC exposes 512 bytes split into sections.
Besides the 16 bytes of SID, there's also an SJTAG area,
HDMI-HDCP key and some custom keys. Below a quick overview, for
details see the user manual:
0x000 128 bit root-key (sun[457]i)
0x010 128 bit boot-key (sun7i)
0x020 64 bit security-jtag-key (sun7i)
0x028 16 bit key configuration (sun7i)
0x02b 16 bit custom-vendor-key (sun7i)
0x02c 320 bit low general key (sun7i)
0x040 32 bit read-control access (sun7i)
0x064 224 bit low general key (sun7i)
0x080 2304 bit HDCP-key (sun7i)
0x1a0 768 bit high general key (sun7i)
Users: any user space application which wants to read the SID on
Allwinner's A-series of CPU's.

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

@@ -1,6 +1,6 @@
What: /sys/power/
Date: August 2006
Contact: Rafael J. Wysocki <rjw@sisk.pl>
Contact: Rafael J. Wysocki <rjw@rjwysocki.net>
Description:
The /sys/power directory will contain files that will
provide a unified interface to the power management
@@ -8,7 +8,7 @@ Description:
What: /sys/power/state
Date: August 2006
Contact: Rafael J. Wysocki <rjw@sisk.pl>
Contact: Rafael J. Wysocki <rjw@rjwysocki.net>
Description:
The /sys/power/state file controls the system power state.
Reading from this file returns what states are supported,
@@ -22,7 +22,7 @@ Description:
What: /sys/power/disk
Date: September 2006
Contact: Rafael J. Wysocki <rjw@sisk.pl>
Contact: Rafael J. Wysocki <rjw@rjwysocki.net>
Description:
The /sys/power/disk file controls the operating mode of the
suspend-to-disk mechanism. Reading from this file returns
@@ -67,7 +67,7 @@ Description:
What: /sys/power/image_size
Date: August 2006
Contact: Rafael J. Wysocki <rjw@sisk.pl>
Contact: Rafael J. Wysocki <rjw@rjwysocki.net>
Description:
The /sys/power/image_size file controls the size of the image
created by the suspend-to-disk mechanism. It can be written a
@@ -84,7 +84,7 @@ Description:
What: /sys/power/pm_trace
Date: August 2006
Contact: Rafael J. Wysocki <rjw@sisk.pl>
Contact: Rafael J. Wysocki <rjw@rjwysocki.net>
Description:
The /sys/power/pm_trace file controls the code which saves the
last PM event point in the RTC across reboots, so that you can
@@ -133,7 +133,7 @@ Description:
What: /sys/power/pm_async
Date: January 2009
Contact: Rafael J. Wysocki <rjw@sisk.pl>
Contact: Rafael J. Wysocki <rjw@rjwysocki.net>
Description:
The /sys/power/pm_async file controls the switch allowing the
user space to enable or disable asynchronous suspend and resume
@@ -146,7 +146,7 @@ Description:
What: /sys/power/wakeup_count
Date: July 2010
Contact: Rafael J. Wysocki <rjw@sisk.pl>
Contact: Rafael J. Wysocki <rjw@rjwysocki.net>
Description:
The /sys/power/wakeup_count file allows user space to put the
system into a sleep state while taking into account the
@@ -161,7 +161,7 @@ Description:
What: /sys/power/reserved_size
Date: May 2011
Contact: Rafael J. Wysocki <rjw@sisk.pl>
Contact: Rafael J. Wysocki <rjw@rjwysocki.net>
Description:
The /sys/power/reserved_size file allows user space to control
the amount of memory reserved for allocations made by device
@@ -175,7 +175,7 @@ Description:
What: /sys/power/autosleep
Date: April 2012
Contact: Rafael J. Wysocki <rjw@sisk.pl>
Contact: Rafael J. Wysocki <rjw@rjwysocki.net>
Description:
The /sys/power/autosleep file can be written one of the strings
returned by reads from /sys/power/state. If that happens, a
@@ -192,7 +192,7 @@ Description:
What: /sys/power/wake_lock
Date: February 2012
Contact: Rafael J. Wysocki <rjw@sisk.pl>
Contact: Rafael J. Wysocki <rjw@rjwysocki.net>
Description:
The /sys/power/wake_lock file allows user space to create
wakeup source objects and activate them on demand (if one of
@@ -219,7 +219,7 @@ Description:
What: /sys/power/wake_unlock
Date: February 2012
Contact: Rafael J. Wysocki <rjw@sisk.pl>
Contact: Rafael J. Wysocki <rjw@rjwysocki.net>
Description:
The /sys/power/wake_unlock file allows user space to deactivate
wakeup sources created with the help of /sys/power/wake_lock.

11
Documentation/Changes
View File

@@ -196,13 +196,6 @@ chmod 0644 /dev/cpu/microcode
as root before you can use this. You'll probably also want to
get the user-space microcode_ctl utility to use with this.
Powertweak
----------
If you are running v0.1.17 or earlier, you should upgrade to
version v0.99.0 or higher. Running old versions may cause problems
with programs using shared memory.
udev
----
udev is a userspace application for populating /dev dynamically with
@@ -366,10 +359,6 @@ Intel P6 microcode
------------------
o <http://www.urbanmyth.org/microcode/>
Powertweak
----------
o <http://powertweak.sourceforge.net/>
udev
----
o <http://www.kernel.org/pub/linux/utils/kernel/hotplug/udev.html>

33
Documentation/DMA-API-HOWTO.txt
View File

@@ -101,12 +101,21 @@ style to do this even if your device holds the default setting,
because this shows that you did think about these issues wrt. your
device.
The query is performed via a call to dma_set_mask():
The query is performed via a call to dma_set_mask_and_coherent():
int dma_set_mask_and_coherent(struct device *dev, u64 mask);
which will query the mask for both streaming and coherent APIs together.
If you have some special requirements, then the following two separate
queries can be used instead:
The query for streaming mappings is performed via a call to
dma_set_mask():
int dma_set_mask(struct device *dev, u64 mask);
The query for consistent allocations is performed via a call to
dma_set_coherent_mask():
The query for consistent allocations is performed via a call
to dma_set_coherent_mask():
int dma_set_coherent_mask(struct device *dev, u64 mask);
@@ -137,7 +146,7 @@ exactly why.
The standard 32-bit addressing device would do something like this:
if (dma_set_mask(dev, DMA_BIT_MASK(32))) {
if (dma_set_mask_and_coherent(dev, DMA_BIT_MASK(32))) {
printk(KERN_WARNING
"mydev: No suitable DMA available.\n");
goto ignore_this_device;
@@ -171,22 +180,20 @@ the case would look like this:
int using_dac, consistent_using_dac;
if (!dma_set_mask(dev, DMA_BIT_MASK(64))) {
if (!dma_set_mask_and_coherent(dev, DMA_BIT_MASK(64))) {
using_dac = 1;
consistent_using_dac = 1;
dma_set_coherent_mask(dev, DMA_BIT_MASK(64));
} else if (!dma_set_mask(dev, DMA_BIT_MASK(32))) {
} else if (!dma_set_mask_and_coherent(dev, DMA_BIT_MASK(32))) {
using_dac = 0;
consistent_using_dac = 0;
dma_set_coherent_mask(dev, DMA_BIT_MASK(32));
} else {
printk(KERN_WARNING
"mydev: No suitable DMA available.\n");
goto ignore_this_device;
}
dma_set_coherent_mask() will always be able to set the same or a
smaller mask as dma_set_mask(). However for the rare case that a
The coherent coherent mask will always be able to set the same or a
smaller mask as the streaming mask. However for the rare case that a
device driver only uses consistent allocations, one would have to
check the return value from dma_set_coherent_mask().
@@ -199,9 +206,9 @@ address you might do something like:
goto ignore_this_device;
}
When dma_set_mask() is successful, and returns zero, the kernel saves
away this mask you have provided. The kernel will use this
information later when you make DMA mappings.
When dma_set_mask() or dma_set_mask_and_coherent() is successful, and
returns zero, the kernel saves away this mask you have provided. The
kernel will use this information later when you make DMA mappings.
There is a case which we are aware of at this time, which is worth
mentioning in this documentation. If your device supports multiple

8
Documentation/DMA-API.txt
View File

@@ -141,6 +141,14 @@ won't change the current mask settings. It is more intended as an
internal API for use by the platform than an external API for use by
driver writers.
int
dma_set_mask_and_coherent(struct device *dev, u64 mask)
Checks to see if the mask is possible and updates the device
streaming and coherent DMA mask parameters if it is.
Returns: 0 if successful and a negative error if not.
int
dma_set_mask(struct device *dev, u64 mask)

4
Documentation/DocBook/80211.tmpl
View File

@@ -152,8 +152,8 @@
!Finclude/net/cfg80211.h cfg80211_scan_request
!Finclude/net/cfg80211.h cfg80211_scan_done
!Finclude/net/cfg80211.h cfg80211_bss
!Finclude/net/cfg80211.h cfg80211_inform_bss_frame
!Finclude/net/cfg80211.h cfg80211_inform_bss
!Finclude/net/cfg80211.h cfg80211_inform_bss_width_frame
!Finclude/net/cfg80211.h cfg80211_inform_bss_width
!Finclude/net/cfg80211.h cfg80211_unlink_bss
!Finclude/net/cfg80211.h cfg80211_find_ie
!Finclude/net/cfg80211.h ieee80211_bss_get_ie

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

@@ -58,7 +58,7 @@
</sect1>
<sect1><title>Wait queues and Wake events</title>
!Iinclude/linux/wait.h
!Ekernel/wait.c
!Ekernel/sched/wait.c
</sect1>
<sect1><title>High-resolution timers</title>
!Iinclude/linux/ktime.h
@@ -87,7 +87,10 @@ X!Iinclude/linux/kobject.h
!Ekernel/printk/printk.c
!Ekernel/panic.c
!Ekernel/sys.c
!Ekernel/rcupdate.c
!Ekernel/rcu/srcu.c
!Ekernel/rcu/tree.c
!Ekernel/rcu/tree_plugin.h
!Ekernel/rcu/update.c
</sect1>
<sect1><title>Device Resource Management</title>

1
Documentation/DocBook/filesystems.tmpl
View File

@@ -91,7 +91,6 @@
<title>The Filesystem for Exporting Kernel Objects</title>
!Efs/sysfs/file.c
!Efs/sysfs/symlink.c
!Efs/sysfs/bin.c
</chapter>
<chapter id="debugfs">

64
Documentation/DocBook/genericirq.tmpl
View File

@@ -87,7 +87,7 @@
<chapter id="rationale">
<title>Rationale</title>
<para>
The original implementation of interrupt handling in Linux is using
The original implementation of interrupt handling in Linux uses
the __do_IRQ() super-handler, which is able to deal with every
type of interrupt logic.
</para>
@@ -111,19 +111,19 @@
</itemizedlist>
</para>
<para>
This split implementation of highlevel IRQ handlers allows us to
This split implementation of high-level IRQ handlers allows us to
optimize the flow of the interrupt handling for each specific
interrupt type. This reduces complexity in that particular codepath
interrupt type. This reduces complexity in that particular code path
and allows the optimized handling of a given type.
</para>
<para>
The original general IRQ implementation used hw_interrupt_type
structures and their ->ack(), ->end() [etc.] callbacks to
differentiate the flow control in the super-handler. This leads to
a mix of flow logic and lowlevel hardware logic, and it also leads
to unnecessary code duplication: for example in i386, there is a
ioapic_level_irq and a ioapic_edge_irq irq-type which share many
of the lowlevel details but have different flow handling.
a mix of flow logic and low-level hardware logic, and it also leads
to unnecessary code duplication: for example in i386, there is an
ioapic_level_irq and an ioapic_edge_irq IRQ-type which share many
of the low-level details but have different flow handling.
</para>
<para>
A more natural abstraction is the clean separation of the
@@ -132,23 +132,23 @@
<para>
Analysing a couple of architecture's IRQ subsystem implementations
reveals that most of them can use a generic set of 'irq flow'
methods and only need to add the chip level specific code.
methods and only need to add the chip-level specific code.
The separation is also valuable for (sub)architectures
which need specific quirks in the irq flow itself but not in the
chip-details - and thus provides a more transparent IRQ subsystem
which need specific quirks in the IRQ flow itself but not in the
chip details - and thus provides a more transparent IRQ subsystem
design.
</para>
<para>
Each interrupt descriptor is assigned its own highlevel flow
Each interrupt descriptor is assigned its own high-level flow
handler, which is normally one of the generic
implementations. (This highlevel flow handler implementation also
implementations. (This high-level flow handler implementation also
makes it simple to provide demultiplexing handlers which can be
found in embedded platforms on various architectures.)
</para>
<para>
The separation makes the generic interrupt handling layer more
flexible and extensible. For example, an (sub)architecture can
use a generic irq-flow implementation for 'level type' interrupts
use a generic IRQ-flow implementation for 'level type' interrupts
and add a (sub)architecture specific 'edge type' implementation.
</para>
<para>
@@ -172,9 +172,9 @@
<para>
There are three main levels of abstraction in the interrupt code:
<orderedlist>
<listitem><para>Highlevel driver API</para></listitem>
<listitem><para>Highlevel IRQ flow handlers</para></listitem>
<listitem><para>Chiplevel hardware encapsulation</para></listitem>
<listitem><para>High-level driver API</para></listitem>
<listitem><para>High-level IRQ flow handlers</para></listitem>
<listitem><para>Chip-level hardware encapsulation</para></listitem>
</orderedlist>
</para>
<sect1 id="Interrupt_control_flow">
@@ -189,16 +189,16 @@
which are assigned to this interrupt.
</para>
<para>
Whenever an interrupt triggers, the lowlevel arch code calls into
the generic interrupt code by calling desc->handle_irq().
This highlevel IRQ handling function only uses desc->irq_data.chip
Whenever an interrupt triggers, the low-level architecture code calls
into the generic interrupt code by calling desc->handle_irq().
This high-level IRQ handling function only uses desc->irq_data.chip
primitives referenced by the assigned chip descriptor structure.
</para>
</sect1>
<sect1 id="Highlevel_Driver_API">
<title>Highlevel Driver API</title>
<title>High-level Driver API</title>
<para>
The highlevel Driver API consists of following functions:
The high-level Driver API consists of following functions:
<itemizedlist>
<listitem><para>request_irq()</para></listitem>
<listitem><para>free_irq()</para></listitem>
@@ -216,7 +216,7 @@
</para>
</sect1>
<sect1 id="Highlevel_IRQ_flow_handlers">
<title>Highlevel IRQ flow handlers</title>
<title>High-level IRQ flow handlers</title>
<para>
The generic layer provides a set of pre-defined irq-flow methods:
<itemizedlist>
@@ -228,7 +228,7 @@
<listitem><para>handle_edge_eoi_irq</para></listitem>
<listitem><para>handle_bad_irq</para></listitem>
</itemizedlist>
The interrupt flow handlers (either predefined or architecture
The interrupt flow handlers (either pre-defined or architecture
specific) are assigned to specific interrupts by the architecture
either during bootup or during device initialization.
</para>
@@ -297,7 +297,7 @@ desc->irq_data.chip->irq_unmask();
<para>
handle_fasteoi_irq provides a generic implementation
for interrupts, which only need an EOI at the end of
the handler
the handler.
</para>
<para>
The following control flow is implemented (simplified excerpt):
@@ -394,7 +394,7 @@ if (desc->irq_data.chip->irq_eoi)
The generic functions are intended for 'clean' architectures and chips,
which have no platform-specific IRQ handling quirks. If an architecture
needs to implement quirks on the 'flow' level then it can do so by
overriding the highlevel irq-flow handler.
overriding the high-level irq-flow handler.
</para>
</sect2>
<sect2 id="Delayed_interrupt_disable">
@@ -419,9 +419,9 @@ if (desc->irq_data.chip->irq_eoi)
</sect2>
</sect1>
<sect1 id="Chiplevel_hardware_encapsulation">
<title>Chiplevel hardware encapsulation</title>
<title>Chip-level hardware encapsulation</title>
<para>
The chip level hardware descriptor structure irq_chip
The chip-level hardware descriptor structure irq_chip
contains all the direct chip relevant functions, which
can be utilized by the irq flow implementations.
<itemizedlist>
@@ -429,14 +429,14 @@ if (desc->irq_data.chip->irq_eoi)
<listitem><para>irq_mask_ack() - Optional, recommended for performance</para></listitem>
<listitem><para>irq_mask()</para></listitem>
<listitem><para>irq_unmask()</para></listitem>
<listitem><para>irq_eoi() - Optional, required for eoi flow handlers</para></listitem>
<listitem><para>irq_eoi() - Optional, required for EOI flow handlers</para></listitem>
<listitem><para>irq_retrigger() - Optional</para></listitem>
<listitem><para>irq_set_type() - Optional</para></listitem>
<listitem><para>irq_set_wake() - Optional</para></listitem>
</itemizedlist>
These primitives are strictly intended to mean what they say: ack means
ACK, masking means masking of an IRQ line, etc. It is up to the flow
handler(s) to use these basic units of lowlevel functionality.
handler(s) to use these basic units of low-level functionality.
</para>
</sect1>
</chapter>
@@ -445,7 +445,7 @@ if (desc->irq_data.chip->irq_eoi)
<title>__do_IRQ entry point</title>
<para>
The original implementation __do_IRQ() was an alternative entry
point for all types of interrupts. It not longer exists.
point for all types of interrupts. It no longer exists.
</para>
<para>
This handler turned out to be not suitable for all
@@ -468,11 +468,11 @@ if (desc->irq_data.chip->irq_eoi)
<chapter id="genericchip">
<title>Generic interrupt chip</title>
<para>
To avoid copies of identical implementations of irq chips the
To avoid copies of identical implementations of IRQ chips the
core provides a configurable generic interrupt chip
implementation. Developers should check carefuly whether the
generic chip fits their needs before implementing the same
functionality slightly different themself.
functionality slightly differently themselves.
</para>
!Ekernel/irq/generic-chip.c
</chapter>

2
Documentation/DocBook/kernel-locking.tmpl
View File

@@ -1958,7 +1958,7 @@ machines due to caching.
<chapter id="apiref-mutex">
<title>Mutex API reference</title>
!Iinclude/linux/mutex.h
!Ekernel/mutex.c
!Ekernel/locking/mutex.c
</chapter>
<chapter id="apiref-futex">

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

@@ -73,7 +73,8 @@ range from zero to the maximal number of valid planes for the currently active
format. For the single-planar API, applications must set <structfield> plane
</structfield> to zero. Additional flags may be posted in the <structfield>
flags </structfield> field. Refer to a manual for open() for details.
Currently only O_CLOEXEC is supported. All other fields must be set to zero.
Currently only O_CLOEXEC, O_RDONLY, O_WRONLY, and O_RDWR are supported. All
other fields must be set to zero.
In the case of multi-planar API, every plane is exported separately using
multiple <constant> VIDIOC_EXPBUF </constant> calls. </para>
@@ -170,8 +171,9 @@ multi-planar API. Otherwise this value must be set to zero. </entry>
<entry>__u32</entry>
<entry><structfield>flags</structfield></entry>
<entry>Flags for the newly created file, currently only <constant>
O_CLOEXEC </constant> is supported, refer to the manual of open() for more
details.</entry>
O_CLOEXEC </constant>, <constant>O_RDONLY</constant>, <constant>O_WRONLY
</constant>, and <constant>O_RDWR</constant> are supported, refer to the manual
of open() for more details.</entry>
</row>
<row>
<entry>__s32</entry>

4
Documentation/DocBook/mtdnand.tmpl
View File

@@ -1222,10 +1222,6 @@ in this page</entry>
#define NAND_BBT_VERSION 0x00000100
/* Create a bbt if none axists */
#define NAND_BBT_CREATE 0x00000200
/* Search good / bad pattern through all pages of a block */
#define NAND_BBT_SCANALLPAGES 0x00000400
/* Scan block empty during good / bad block scan */
#define NAND_BBT_SCANEMPTY 0x00000800
/* Write bbt if neccecary */
#define NAND_BBT_WRITE 0x00001000
/* Read and write back block contents when writing bbt */

8
Documentation/PCI/pci.txt
View File

@@ -525,8 +525,9 @@ corresponding register block for you.
6. Other interesting functions
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
pci_find_slot() Find pci_dev corresponding to given bus and
slot numbers.
pci_get_domain_bus_and_slot() Find pci_dev corresponding to given domain,
bus and slot and number. If the device is
found, its reference count is increased.
pci_set_power_state() Set PCI Power Management state (0=D0 ... 3=D3)
pci_find_capability() Find specified capability in device's capability
list.
@@ -582,7 +583,8 @@ having sane locking.
pci_find_device() Superseded by pci_get_device()
pci_find_subsys() Superseded by pci_get_subsys()
pci_find_slot() Superseded by pci_get_slot()
pci_find_slot() Superseded by pci_get_domain_bus_and_slot()
pci_get_slot() Superseded by pci_get_domain_bus_and_slot()
The alternative is the traditional PCI device driver that walks PCI

4
Documentation/RCU/checklist.txt
View File

@@ -202,8 +202,8 @@ over a rather long period of time, but improvements are always welcome!
updater uses call_rcu_sched() or synchronize_sched(), then
the corresponding readers must disable preemption, possibly
by calling rcu_read_lock_sched() and rcu_read_unlock_sched().
If the updater uses synchronize_srcu() or call_srcu(),
the the corresponding readers must use srcu_read_lock() and
If the updater uses synchronize_srcu() or call_srcu(), then
the corresponding readers must use srcu_read_lock() and
srcu_read_unlock(), and with the same srcu_struct. The rules for
the expedited primitives are the same as for their non-expedited
counterparts. Mixing things up will result in confusion and

22
Documentation/RCU/stallwarn.txt
View File

@@ -12,12 +12,12 @@ CONFIG_RCU_CPU_STALL_TIMEOUT
This kernel configuration parameter defines the period of time
that RCU will wait from the beginning of a grace period until it
issues an RCU CPU stall warning. This time period is normally
sixty seconds.
21 seconds.
This configuration parameter may be changed at runtime via the
/sys/module/rcutree/parameters/rcu_cpu_stall_timeout, however
this parameter is checked only at the beginning of a cycle.
So if you are 30 seconds into a 70-second stall, setting this
So if you are 10 seconds into a 40-second stall, setting this
sysfs parameter to (say) five will shorten the timeout for the
-next- stall, or the following warning for the current stall
(assuming the stall lasts long enough). It will not affect the
@@ -32,7 +32,7 @@ CONFIG_RCU_CPU_STALL_VERBOSE
also dump the stacks of any tasks that are blocking the current
RCU-preempt grace period.
RCU_CPU_STALL_INFO
CONFIG_RCU_CPU_STALL_INFO
This kernel configuration parameter causes the stall warning to
print out additional per-CPU diagnostic information, including
@@ -43,7 +43,8 @@ RCU_STALL_DELAY_DELTA
Although the lockdep facility is extremely useful, it does add
some overhead. Therefore, under CONFIG_PROVE_RCU, the
RCU_STALL_DELAY_DELTA macro allows five extra seconds before
giving an RCU CPU stall warning message.
giving an RCU CPU stall warning message. (This is a cpp
macro, not a kernel configuration parameter.)
RCU_STALL_RAT_DELAY
@@ -52,7 +53,8 @@ RCU_STALL_RAT_DELAY
However, if the offending CPU does not detect its own stall in
the number of jiffies specified by RCU_STALL_RAT_DELAY, then
some other CPU will complain. This delay is normally set to
two jiffies.
two jiffies. (This is a cpp macro, not a kernel configuration
parameter.)
When a CPU detects that it is stalling, it will print a message similar
to the following:
@@ -86,7 +88,12 @@ printing, there will be a spurious stall-warning message:
INFO: rcu_bh_state detected stalls on CPUs/tasks: { } (detected by 4, 2502 jiffies)
This is rare, but does happen from time to time in real life.
This is rare, but does happen from time to time in real life. It is also
possible for a zero-jiffy stall to be flagged in this case, depending
on how the stall warning and the grace-period initialization happen to
interact. Please note that it is not possible to entirely eliminate this
sort of false positive without resorting to things like stop_machine(),
which is overkill for this sort of problem.
If the CONFIG_RCU_CPU_STALL_INFO kernel configuration parameter is set,
more information is printed with the stall-warning message, for example:
@@ -216,4 +223,5 @@ that portion of the stack which remains the same from trace to trace.
If you can reliably trigger the stall, ftrace can be quite helpful.
RCU bugs can often be debugged with the help of CONFIG_RCU_TRACE
and with RCU's event tracing.
and with RCU's event tracing. For information on RCU's event tracing,
see include/trace/events/rcu.h.

2
Documentation/acpi/dsdt-override.txt
View File

@@ -4,4 +4,4 @@ CONFIG_ACPI_CUSTOM_DSDT builds the image into the kernel.
When to use this method is described in detail on the
Linux/ACPI home page:
http://www.lesswatts.org/projects/acpi/overridingDSDT.php
https://01.org/linux-acpi/documentation/overriding-dsdt

26
Documentation/acpi/enumeration.txt
View File

@@ -295,10 +295,6 @@ These GPIO numbers are controller relative and path "\\_SB.PCI0.GPI0"
specifies the path to the controller. In order to use these GPIOs in Linux
we need to translate them to the Linux GPIO numbers.
The driver can do this by including <linux/acpi_gpio.h> and then calling
acpi_get_gpio(path, gpio). This will return the Linux GPIO number or
negative errno if there was no translation found.
In a simple case of just getting the Linux GPIO number from device
resources one can use acpi_get_gpio_by_index() helper function. It takes
pointer to the device and index of the GpioIo/GpioInt descriptor in the
@@ -322,3 +318,25 @@ suitable to the gpiolib before passing them.
In case of GpioInt resource an additional call to gpio_to_irq() must be
done before calling request_irq().
Note that the above API is ACPI specific and not recommended for drivers
that need to support non-ACPI systems. The recommended way is to use
the descriptor based GPIO interfaces. The above example looks like this
when converted to the GPIO desc:
#include <linux/gpio/consumer.h>
...
struct gpio_desc *irq_desc, *power_desc;
irq_desc = gpiod_get_index(dev, NULL, 1);
if (IS_ERR(irq_desc))
/* handle error */
power_desc = gpiod_get_index(dev, NULL, 0);
if (IS_ERR(power_desc))
/* handle error */
/* Now we can use the GPIO descriptors */
See also Documentation/gpio.txt.

2
Documentation/aoe/udev.txt
View File

@@ -23,4 +23,4 @@ SUBSYSTEM=="aoe", KERNEL=="revalidate", NAME="etherd/%k", GROUP="disk", MODE="02
SUBSYSTEM=="aoe", KERNEL=="flush", NAME="etherd/%k", GROUP="disk", MODE="0220"
# aoe block devices
KERNEL=="etherd*", NAME="%k", GROUP="disk"
KERNEL=="etherd*", GROUP="disk"

1
Documentation/arm/Marvell/README
View File

@@ -88,6 +88,7 @@ EBU Armada family
MV78230
MV78260
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.

26
Documentation/arm/sunxi/README
View File

@@ -10,6 +10,10 @@ SunXi family
Linux kernel mach directory: arch/arm/mach-sunxi
Flavors:
* ARM926 based SoCs
- Allwinner F20 (sun3i)
+ Not Supported
* ARM Cortex-A8 based SoCs
- Allwinner A10 (sun4i)
+ Datasheet
@@ -25,4 +29,24 @@ SunXi family
+ Datasheet
http://dl.linux-sunxi.org/A13/A13%20Datasheet%20-%20v1.12%20%282012-03-29%29.pdf
+ User Manual
http://dl.linux-sunxi.org/A13/A13%20User%20Manual%20-%20v1.2%20%282013-08-08%29.pdf
http://dl.linux-sunxi.org/A13/A13%20User%20Manual%20-%20v1.2%20%282013-01-08%29.pdf
* Dual ARM Cortex-A7 based SoCs
- Allwinner A20 (sun7i)
+ User Manual
http://dl.linux-sunxi.org/A20/A20%20User%20Manual%202013-03-22.pdf
- Allwinner A23
+ Not Supported
* Quad ARM Cortex-A7 based SoCs
- Allwinner A31 (sun6i)
+ Datasheet
http://dl.linux-sunxi.org/A31/A31%20Datasheet%20-%20v1.00%20(2012-12-24).pdf
- Allwinner A31s (sun6i)
+ Not Supported
* Quad ARM Cortex-A15, Quad ARM Cortex-A7 based SoCs
- Allwinner A80
+ Not Supported

67
Documentation/arm64/booting.txt
View File

@@ -45,9 +45,9 @@ sees fit.)
Requirement: MANDATORY
The device tree blob (dtb) must be no bigger than 2 megabytes in size
and placed at a 2-megabyte boundary within the first 512 megabytes from
the start of the kernel image. This is to allow the kernel to map the
The device tree blob (dtb) must be placed on an 8-byte boundary within
the first 512 megabytes from the start of the kernel image and must not
cross a 2-megabyte boundary. This is to allow the kernel to map the
blob using a single section mapping in the initial page tables.
@@ -68,13 +68,23 @@ Image target is available instead.
Requirement: MANDATORY
The decompressed kernel image contains a 32-byte header as follows:
The decompressed kernel image contains a 64-byte header as follows:
u32 magic = 0x14000008; /* branch to stext, little-endian */
u32 res0 = 0; /* reserved */
u32 code0; /* Executable code */
u32 code1; /* Executable code */
u64 text_offset; /* Image load offset */
u64 res0 = 0; /* reserved */
u64 res1 = 0; /* reserved */
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 */
Header notes:
- code0/code1 are responsible for branching to stext.
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
@@ -105,9 +115,10 @@ Before jumping into the kernel, the following conditions must be met:
External caches (if present) must be configured and disabled.
- Architected timers
CNTFRQ must be programmed with the timer frequency.
If entering the kernel at EL1, CNTHCTL_EL2 must have EL1PCTEN (bit 0)
set where available.
CNTFRQ must be programmed with the timer frequency and CNTVOFF must
be programmed with a consistent value on all CPUs. If entering the
kernel at EL1, CNTHCTL_EL2 must have EL1PCTEN (bit 0) set where
available.
- Coherency
All CPUs to be booted by the kernel must be part of the same coherency
@@ -120,30 +131,46 @@ 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.
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.
The boot loader is expected to enter the kernel on each CPU in the
following manner:
- The primary CPU must jump directly to the first instruction of the
kernel image. The device tree blob passed by this CPU must contain
for each CPU node:
1. An 'enable-method' property. Currently, the only supported value
for this field is the string "spin-table".
2. A 'cpu-release-addr' property identifying a 64-bit,
zero-initialised memory location.
an 'enable-method' property for each cpu node. The supported
enable-methods are described below.
It is expected that the bootloader will generate these device tree
properties and insert them into the blob prior to kernel entry.
- Any secondary CPUs must spin outside of the kernel in a reserved area
of memory (communicated to the kernel by a /memreserve/ region in the
- CPUs with a "spin-table" enable-method must have a 'cpu-release-addr'
property in their cpu node. This property identifies a
naturally-aligned 64-bit zero-initalised memory location.
These CPUs should spin outside of the kernel in a reserved area of
memory (communicated to the kernel by a /memreserve/ region in the
device tree) polling their cpu-release-addr location, which must be
contained in the reserved region. A wfe instruction may be inserted
to reduce the overhead of the busy-loop and a sev will be issued by
the primary CPU. When a read of the location pointed to by the
cpu-release-addr returns a non-zero value, the CPU must jump directly
to this value.
cpu-release-addr returns a non-zero value, the CPU must jump to this
value. The value will be written as a single 64-bit little-endian
value, so CPUs must convert the read value to their native endianness
before jumping to it.
- CPUs with a "psci" enable method should remain outside of
the kernel (i.e. outside of the regions of memory described to the
kernel in the memory node, or in a reserved area of memory described
to the kernel by a /memreserve/ region in the device tree). The
kernel will issue CPU_ON calls as described in ARM document number ARM
DEN 0022A ("Power State Coordination Interface System Software on ARM
processors") to bring CPUs into the kernel.
The device tree should contain a 'psci' node, as described in
Documentation/devicetree/bindings/arm/psci.txt.
- Secondary CPU general-purpose register settings
x0 = 0 (reserved for future use)

29
Documentation/arm64/memory.txt
View File

@@ -21,7 +21,7 @@ The swapper_pgd_dir address is written to TTBR1 and never written to
TTBR0.
AArch64 Linux memory layout:
AArch64 Linux memory layout with 4KB pages:
Start End Size Use
-----------------------------------------------------------------------
@@ -39,13 +39,38 @@ ffffffbffbc00000 ffffffbffbdfffff 2MB earlyprintk device
ffffffbffbe00000 ffffffbffbe0ffff 64KB PCI I/O space
ffffffbbffff0000 ffffffbcffffffff ~2MB [guard]
ffffffbffbe10000 ffffffbcffffffff ~2MB [guard]
ffffffbffc000000 ffffffbfffffffff 64MB modules
ffffffc000000000 ffffffffffffffff 256GB kernel logical memory map
AArch64 Linux memory layout with 64KB pages:
Start End Size Use
-----------------------------------------------------------------------
0000000000000000 000003ffffffffff 4TB user
fffffc0000000000 fffffdfbfffeffff ~2TB vmalloc
fffffdfbffff0000 fffffdfbffffffff 64KB [guard page]
fffffdfc00000000 fffffdfdffffffff 8GB vmemmap
fffffdfe00000000 fffffdfffbbfffff ~8GB [guard, future vmmemap]
fffffdfffbc00000 fffffdfffbdfffff 2MB earlyprintk device
fffffdfffbe00000 fffffdfffbe0ffff 64KB PCI I/O space
fffffdfffbe10000 fffffdfffbffffff ~2MB [guard]
fffffdfffc000000 fffffdffffffffff 64MB modules
fffffe0000000000 ffffffffffffffff 2TB kernel logical memory map
Translation table lookup with 4KB pages:
+--------+--------+--------+--------+--------+--------+--------+--------+

34
Documentation/arm64/tagged-pointers.txt Normal file
View File

@@ -0,0 +1,34 @@
Tagged virtual addresses in AArch64 Linux
=========================================
Author: Will Deacon <will.deacon@arm.com>
Date : 12 June 2013
This document briefly describes the provision of tagged virtual
addresses in the AArch64 translation system and their potential uses
in AArch64 Linux.
The kernel configures the translation tables so that translations made
via TTBR0 (i.e. userspace mappings) have the top byte (bits 63:56) of
the virtual address ignored by the translation hardware. This frees up
this byte for application use, with the following caveats:
(1) The kernel requires that all user addresses passed to EL1
are tagged with tag 0x00. This means that any syscall
parameters containing user virtual addresses *must* have
their top byte cleared before trapping to the kernel.
(2) Non-zero tags are not preserved when delivering signals.
This means that signal handlers in applications making use
of tags cannot rely on the tag information for user virtual
addresses being maintained for fields inside siginfo_t.
One exception to this rule is for signals raised in response
to watchpoint debug exceptions, where the tag information
will be preserved.
(3) Special care should be taken when using tagged pointers,
since it is likely that C compilers will not hazard two
virtual addresses differing only in the upper byte.
The architecture prevents the use of a tagged PC, so the upper byte will
be set to a sign-extension of bit 55 on exception return.

574
Documentation/assoc_array.txt Normal file
View File

@@ -0,0 +1,574 @@
========================================
GENERIC ASSOCIATIVE ARRAY IMPLEMENTATION
========================================
Contents:
- Overview.
- The public API.
- Edit script.
- Operations table.
- Manipulation functions.
- Access functions.
- Index key form.
- Internal workings.
- Basic internal tree layout.
- Shortcuts.
- Splitting and collapsing nodes.
- Non-recursive iteration.
- Simultaneous alteration and iteration.
========
OVERVIEW
========
This associative array implementation is an object container with the following
properties:
(1) Objects are opaque pointers. The implementation does not care where they
point (if anywhere) or what they point to (if anything).
[!] NOTE: Pointers to objects _must_ be zero in the least significant bit.
(2) Objects do not need to contain linkage blocks for use by the array. This
permits an object to be located in multiple arrays simultaneously.
Rather, the array is made up of metadata blocks that point to objects.
(3) Objects require index keys to locate them within the array.
(4) Index keys must be unique. Inserting an object with the same key as one
already in the array will replace the old object.
(5) Index keys can be of any length and can be of different lengths.
(6) Index keys should encode the length early on, before any variation due to
length is seen.
(7) Index keys can include a hash to scatter objects throughout the array.
(8) The array can iterated over. The objects will not necessarily come out in
key order.
(9) The array can be iterated over whilst it is being modified, provided the
RCU readlock is being held by the iterator. Note, however, under these
circumstances, some objects may be seen more than once. If this is a
problem, the iterator should lock against modification. Objects will not
be missed, however, unless deleted.
(10) Objects in the array can be looked up by means of their index key.
(11) Objects can be looked up whilst the array is being modified, provided the
RCU readlock is being held by the thread doing the look up.
The implementation uses a tree of 16-pointer nodes internally that are indexed
on each level by nibbles from the index key in the same manner as in a radix
tree. To improve memory efficiency, shortcuts can be emplaced to skip over
what would otherwise be a series of single-occupancy nodes. Further, nodes
pack leaf object pointers into spare space in the node rather than making an
extra branch until as such time an object needs to be added to a full node.
==============
THE PUBLIC API
==============
The public API can be found in <linux/assoc_array.h>. The associative array is
rooted on the following structure:
struct assoc_array {
...
};
The code is selected by enabling CONFIG_ASSOCIATIVE_ARRAY.
EDIT SCRIPT
-----------
The insertion and deletion functions produce an 'edit script' that can later be
applied to effect the changes without risking ENOMEM. This retains the
preallocated metadata blocks that will be installed in the internal tree and
keeps track of the metadata blocks that will be removed from the tree when the
script is applied.
This is also used to keep track of dead blocks and dead objects after the
script has been applied so that they can be freed later. The freeing is done
after an RCU grace period has passed - thus allowing access functions to
proceed under the RCU read lock.
The script appears as outside of the API as a pointer of the type:
struct assoc_array_edit;
There are two functions for dealing with the script:
(1) Apply an edit script.
void assoc_array_apply_edit(struct assoc_array_edit *edit);
This will perform the edit functions, interpolating various write barriers
to permit accesses under the RCU read lock to continue. The edit script
will then be passed to call_rcu() to free it and any dead stuff it points
to.
(2) Cancel an edit script.
void assoc_array_cancel_edit(struct assoc_array_edit *edit);
This frees the edit script and all preallocated memory immediately. If
this was for insertion, the new object is _not_ released by this function,
but must rather be released by the caller.
These functions are guaranteed not to fail.
OPERATIONS TABLE
----------------
Various functions take a table of operations:
struct assoc_array_ops {
...
};
This points to a number of methods, all of which need to be provided:
(1) Get a chunk of index key from caller data:
unsigned long (*get_key_chunk)(const void *index_key, int level);
This should return a chunk of caller-supplied index key starting at the
*bit* position given by the level argument. The level argument will be a
multiple of ASSOC_ARRAY_KEY_CHUNK_SIZE and the function should return
ASSOC_ARRAY_KEY_CHUNK_SIZE bits. No error is possible.
(2) Get a chunk of an object's index key.
unsigned long (*get_object_key_chunk)(const void *object, int level);
As the previous function, but gets its data from an object in the array
rather than from a caller-supplied index key.
(3) See if this is the object we're looking for.
bool (*compare_object)(const void *object, const void *index_key);
Compare the object against an index key and return true if it matches and
false if it doesn't.
(4) Diff the index keys of two objects.
int (*diff_objects)(const void *object, const void *index_key);
Return the bit position at which the index key of the specified object
differs from the given index key or -1 if they are the same.
(5) Free an object.
void (*free_object)(void *object);
Free the specified object. Note that this may be called an RCU grace
period after assoc_array_apply_edit() was called, so synchronize_rcu() may
be necessary on module unloading.
MANIPULATION FUNCTIONS
----------------------
There are a number of functions for manipulating an associative array:
(1) Initialise an associative array.
void assoc_array_init(struct assoc_array *array);
This initialises the base structure for an associative array. It can't
fail.
(2) Insert/replace an object in an associative array.
struct assoc_array_edit *
assoc_array_insert(struct assoc_array *array,
const struct assoc_array_ops *ops,
const void *index_key,
void *object);
This inserts the given object into the array. Note that the least
significant bit of the pointer must be zero as it's used to type-mark
pointers internally.
If an object already exists for that key then it will be replaced with the
new object and the old one will be freed automatically.
The index_key argument should hold index key information and is
passed to the methods in the ops table when they are called.
This function makes no alteration to the array itself, but rather returns
an edit script that must be applied. -ENOMEM is returned in the case of
an out-of-memory error.
The caller should lock exclusively against other modifiers of the array.
(3) Delete an object from an associative array.
struct assoc_array_edit *
assoc_array_delete(struct assoc_array *array,
const struct assoc_array_ops *ops,
const void *index_key);
This deletes an object that matches the specified data from the array.
The index_key argument should hold index key information and is
passed to the methods in the ops table when they are called.
This function makes no alteration to the array itself, but rather returns
an edit script that must be applied. -ENOMEM is returned in the case of
an out-of-memory error. NULL will be returned if the specified object is
not found within the array.
The caller should lock exclusively against other modifiers of the array.
(4) Delete all objects from an associative array.
struct assoc_array_edit *
assoc_array_clear(struct assoc_array *array,
const struct assoc_array_ops *ops);
This deletes all the objects from an associative array and leaves it
completely empty.
This function makes no alteration to the array itself, but rather returns
an edit script that must be applied. -ENOMEM is returned in the case of
an out-of-memory error.
The caller should lock exclusively against other modifiers of the array.
(5) Destroy an associative array, deleting all objects.
void assoc_array_destroy(struct assoc_array *array,
const struct assoc_array_ops *ops);
This destroys the contents of the associative array and leaves it
completely empty. It is not permitted for another thread to be traversing
the array under the RCU read lock at the same time as this function is
destroying it as no RCU deferral is performed on memory release -
something that would require memory to be allocated.
The caller should lock exclusively against other modifiers and accessors
of the array.
(6) Garbage collect an associative array.
int assoc_array_gc(struct assoc_array *array,
const struct assoc_array_ops *ops,
bool (*iterator)(void *object, void *iterator_data),
void *iterator_data);
This iterates over the objects in an associative array and passes each one
to iterator(). If iterator() returns true, the object is kept. If it
returns false, the object will be freed. If the iterator() function
returns true, it must perform any appropriate refcount incrementing on the
object before returning.
The internal tree will be packed down if possible as part of the iteration
to reduce the number of nodes in it.
The iterator_data is passed directly to iterator() and is otherwise
ignored by the function.
The function will return 0 if successful and -ENOMEM if there wasn't
enough memory.
It is possible for other threads to iterate over or search the array under
the RCU read lock whilst this function is in progress. The caller should
lock exclusively against other modifiers of the array.
ACCESS FUNCTIONS
----------------
There are two functions for accessing an associative array:
(1) Iterate over all the objects in an associative array.
int assoc_array_iterate(const struct assoc_array *array,
int (*iterator)(const void *object,
void *iterator_data),
void *iterator_data);
This passes each object in the array to the iterator callback function.
iterator_data is private data for that function.
This may be used on an array at the same time as the array is being
modified, provided the RCU read lock is held. Under such circumstances,
it is possible for the iteration function to see some objects twice. If
this is a problem, then modification should be locked against. The
iteration algorithm should not, however, miss any objects.
The function will return 0 if no objects were in the array or else it will
return the result of the last iterator function called. Iteration stops
immediately if any call to the iteration function results in a non-zero
return.
(2) Find an object in an associative array.
void *assoc_array_find(const struct assoc_array *array,
const struct assoc_array_ops *ops,
const void *index_key);
This walks through the array's internal tree directly to the object
specified by the index key..
This may be used on an array at the same time as the array is being
modified, provided the RCU read lock is held.
The function will return the object if found (and set *_type to the object
type) or will return NULL if the object was not found.
INDEX KEY FORM
--------------
The index key can be of any form, but since the algorithms aren't told how long
the key is, it is strongly recommended that the index key includes its length
very early on before any variation due to the length would have an effect on
comparisons.
This will cause leaves with different length keys to scatter away from each
other - and those with the same length keys to cluster together.
It is also recommended that the index key begin with a hash of the rest of the
key to maximise scattering throughout keyspace.
The better the scattering, the wider and lower the internal tree will be.
Poor scattering isn't too much of a problem as there are shortcuts and nodes
can contain mixtures of leaves and metadata pointers.
The index key is read in chunks of machine word. Each chunk is subdivided into
one nibble (4 bits) per level, so on a 32-bit CPU this is good for 8 levels and
on a 64-bit CPU, 16 levels. Unless the scattering is really poor, it is
unlikely that more than one word of any particular index key will have to be
used.
=================
INTERNAL WORKINGS
=================
The associative array data structure has an internal tree. This tree is
constructed of two types of metadata blocks: nodes and shortcuts.
A node is an array of slots. Each slot can contain one of four things:
(*) A NULL pointer, indicating that the slot is empty.
(*) A pointer to an object (a leaf).
(*) A pointer to a node at the next level.
(*) A pointer to a shortcut.
BASIC INTERNAL TREE LAYOUT
--------------------------
Ignoring shortcuts for the moment, the nodes form a multilevel tree. The index
key space is strictly subdivided by the nodes in the tree and nodes occur on
fixed levels. For example:
Level: 0 1 2 3
=============== =============== =============== ===============
NODE D
NODE B NODE C +------>+---+
+------>+---+ +------>+---+ | | 0 |
NODE A | | 0 | | | 0 | | +---+
+---+ | +---+ | +---+ | : :
| 0 | | : : | : : | +---+
+---+ | +---+ | +---+ | | f |
| 1 |---+ | 3 |---+ | 7 |---+ +---+
+---+ +---+ +---+
: : : : | 8 |---+
+---+ +---+ +---+ | NODE E
| e |---+ | f | : : +------>+---+
+---+ | +---+ +---+ | 0 |
| f | | | f | +---+
+---+ | +---+ : :
| NODE F +---+
+------>+---+ | f |
| 0 | NODE G +---+
+---+ +------>+---+
: : | | 0 |
+---+ | +---+
| 6 |---+ : :
+---+ +---+
: : | f |
+---+ +---+
| f |
+---+
In the above example, there are 7 nodes (A-G), each with 16 slots (0-f).
Assuming no other meta data nodes in the tree, the key space is divided thusly:
KEY PREFIX NODE
========== ====
137* D
138* E
13[0-69-f]* C
1[0-24-f]* B
e6* G
e[0-57-f]* F
[02-df]* A
So, for instance, keys with the following example index keys will be found in
the appropriate nodes:
INDEX KEY PREFIX NODE
=============== ======= ====
13694892892489 13 C
13795289025897 137 D
13889dde88793 138 E
138bbb89003093 138 E
1394879524789 12 C
1458952489 1 B
9431809de993ba - A
b4542910809cd - A
e5284310def98 e F
e68428974237 e6 G
e7fffcbd443 e F
f3842239082 - A
To save memory, if a node can hold all the leaves in its portion of keyspace,
then the node will have all those leaves in it and will not have any metadata
pointers - even if some of those leaves would like to be in the same slot.
A node can contain a heterogeneous mix of leaves and metadata pointers.
Metadata pointers must be in the slots that match their subdivisions of key
space. The leaves can be in any slot not occupied by a metadata pointer. It
is guaranteed that none of the leaves in a node will match a slot occupied by a
metadata pointer. If the metadata pointer is there, any leaf whose key matches
the metadata key prefix must be in the subtree that the metadata pointer points
to.
In the above example list of index keys, node A will contain:
SLOT CONTENT INDEX KEY (PREFIX)
==== =============== ==================
1 PTR TO NODE B 1*
any LEAF 9431809de993ba
any LEAF b4542910809cd
e PTR TO NODE F e*
any LEAF f3842239082
and node B:
3 PTR TO NODE C 13*
any LEAF 1458952489
SHORTCUTS
---------
Shortcuts are metadata records that jump over a piece of keyspace. A shortcut
is a replacement for a series of single-occupancy nodes ascending through the
levels. Shortcuts exist to save memory and to speed up traversal.
It is possible for the root of the tree to be a shortcut - say, for example,
the tree contains at least 17 nodes all with key prefix '1111'. The insertion
algorithm will insert a shortcut to skip over the '1111' keyspace in a single
bound and get to the fourth level where these actually become different.
SPLITTING AND COLLAPSING NODES
------------------------------
Each node has a maximum capacity of 16 leaves and metadata pointers. If the
insertion algorithm finds that it is trying to insert a 17th object into a
node, that node will be split such that at least two leaves that have a common
key segment at that level end up in a separate node rooted on that slot for
that common key segment.
If the leaves in a full node and the leaf that is being inserted are
sufficiently similar, then a shortcut will be inserted into the tree.
When the number of objects in the subtree rooted at a node falls to 16 or
fewer, then the subtree will be collapsed down to a single node - and this will
ripple towards the root if possible.
NON-RECURSIVE ITERATION
-----------------------
Each node and shortcut contains a back pointer to its parent and the number of
slot in that parent that points to it. None-recursive iteration uses these to
proceed rootwards through the tree, going to the parent node, slot N + 1 to
make sure progress is made without the need for a stack.
The backpointers, however, make simultaneous alteration and iteration tricky.
SIMULTANEOUS ALTERATION AND ITERATION
-------------------------------------
There are a number of cases to consider:
(1) Simple insert/replace. This involves simply replacing a NULL or old
matching leaf pointer with the pointer to the new leaf after a barrier.
The metadata blocks don't change otherwise. An old leaf won't be freed
until after the RCU grace period.
(2) Simple delete. This involves just clearing an old matching leaf. The
metadata blocks don't change otherwise. The old leaf won't be freed until
after the RCU grace period.
(3) Insertion replacing part of a subtree that we haven't yet entered. This
may involve replacement of part of that subtree - but that won't affect
the iteration as we won't have reached the pointer to it yet and the
ancestry blocks are not replaced (the layout of those does not change).
(4) Insertion replacing nodes that we're actively processing. This isn't a
problem as we've passed the anchoring pointer and won't switch onto the
new layout until we follow the back pointers - at which point we've
already examined the leaves in the replaced node (we iterate over all the
leaves in a node before following any of its metadata pointers).
We might, however, re-see some leaves that have been split out into a new
branch that's in a slot further along than we were at.
(5) Insertion replacing nodes that we're processing a dependent branch of.
This won't affect us until we follow the back pointers. Similar to (4).
(6) Deletion collapsing a branch under us. This doesn't affect us because the
back pointers will get us back to the parent of the new node before we
could see the new node. The entire collapsed subtree is thrown away
unchanged - and will still be rooted on the same slot, so we shouldn't
process it a second time as we'll go back to slot + 1.
Note:
(*) Under some circumstances, we need to simultaneously change the parent
pointer and the parent slot pointer on a node (say, for example, we
inserted another node before it and moved it up a level). We cannot do
this without locking against a read - so we have to replace that node too.
However, when we're changing a shortcut into a node this isn't a problem
as shortcuts only have one slot and so the parent slot number isn't used
when traversing backwards over one. This means that it's okay to change
the slot number first - provided suitable barriers are used to make sure
the parent slot number is read after the back pointer.
Obsolete blocks and leaves are freed up after an RCU grace period has passed,
so as long as anyone doing walking or iteration holds the RCU read lock, the
old superstructure should not go away on them.

5
Documentation/backlight/lp855x-driver.txt
View File

@@ -4,7 +4,8 @@ Kernel driver lp855x
Backlight driver for LP855x ICs
Supported chips:
Texas Instruments LP8550, LP8551, LP8552, LP8553, LP8556 and LP8557
Texas Instruments LP8550, LP8551, LP8552, LP8553, LP8555, LP8556 and
LP8557
Author: Milo(Woogyom) Kim <milo.kim@ti.com>
@@ -24,7 +25,7 @@ Value : pwm based or register based
2) chip_id
The lp855x chip id.
Value : lp8550/lp8551/lp8552/lp8553/lp8556/lp8557
Value : lp8550/lp8551/lp8552/lp8553/lp8555/lp8556/lp8557
Platform data for lp855x
------------------------

2
Documentation/block/00-INDEX
View File

@@ -6,6 +6,8 @@ capability.txt
- Generic Block Device Capability (/sys/block/<device>/capability)
cfq-iosched.txt
- CFQ IO scheduler tunables
cmdline-partition.txt
- how to specify block device partitions on kernel command line
data-integrity.txt
- Block data integrity
deadline-iosched.txt

39
Documentation/block/cmdline-partition.txt Normal file
View File

@@ -0,0 +1,39 @@
Embedded device command line partition parsing
=====================================================================
Support for reading the block device partition table from the command line.
It is typically used for fixed block (eMMC) embedded devices.
It has no MBR, so saves storage space. Bootloader can be easily accessed
by absolute address of data on the block device.
Users can easily change the partition.
The format for the command line is just like mtdparts:
blkdevparts=<blkdev-def>[;<blkdev-def>]
<blkdev-def> := <blkdev-id>:<partdef>[,<partdef>]
<partdef> := <size>[@<offset>](part-name)
<blkdev-id>
block device disk name, embedded device used fixed block device,
it's disk name also fixed. such as: mmcblk0, mmcblk1, mmcblk0boot0.
<size>
partition size, in bytes, such as: 512, 1m, 1G.
<offset>
partition start address, in bytes.
(part-name)
partition name, kernel send uevent with "PARTNAME". application can create
a link to block device partition with the name "PARTNAME".
user space application can access partition by partition name.
Example:
eMMC disk name is "mmcblk0" and "mmcblk0boot0"
bootargs:
'blkdevparts=mmcblk0:1G(data0),1G(data1),-;mmcblk0boot0:1m(boot),-(kernel)'
dmesg:
mmcblk0: p1(data0) p2(data1) p3()
mmcblk0boot0: p1(boot) p2(kernel)

6
Documentation/blockdev/floppy.txt
View File

@@ -39,15 +39,15 @@ Module configuration options
============================
If you use the floppy driver as a module, use the following syntax:
modprobe floppy <options>
modprobe floppy floppy="<options>"
Example:
modprobe floppy omnibook messages
modprobe floppy floppy="omnibook messages"
If you need certain options enabled every time you load the floppy driver,
you can put:
options floppy omnibook messages
options floppy floppy="omnibook messages"
in a configuration file in /etc/modprobe.d/.

12
Documentation/cgroups/memory.txt
View File

@@ -490,6 +490,8 @@ pgpgin - # of charging events to the memory cgroup. The charging
pgpgout - # of uncharging events to the memory cgroup. The uncharging
event happens each time a page is unaccounted from the cgroup.
swap - # of bytes of swap usage
writeback - # of bytes of file/anon cache that are queued for syncing to
disk.
inactive_anon - # of bytes of anonymous and swap cache memory on inactive
LRU list.
active_anon - # of bytes of anonymous and swap cache memory on active
@@ -571,15 +573,19 @@ an memcg since the pages are allowed to be allocated from any physical
node. One of the use cases is evaluating application performance by
combining this information with the application's CPU allocation.
We export "total", "file", "anon" and "unevictable" pages per-node for
each memcg. The ouput format of memory.numa_stat is:
Each memcg's numa_stat file includes "total", "file", "anon" and "unevictable"
per-node page counts including "hierarchical_<counter>" which sums up all
hierarchical children's values in addition to the memcg's own value.
The ouput format of memory.numa_stat is:
total=<total pages> N0=<node 0 pages> N1=<node 1 pages> ...
file=<total file pages> N0=<node 0 pages> N1=<node 1 pages> ...
anon=<total anon pages> N0=<node 0 pages> N1=<node 1 pages> ...
unevictable=<total anon pages> N0=<node 0 pages> N1=<node 1 pages> ...
hierarchical_<counter>=<counter pages> N0=<node 0 pages> N1=<node 1 pages> ...
And we have total = file + anon + unevictable.
The "total" count is sum of file + anon + unevictable.
6. Hierarchy support

8
Documentation/clk.txt
View File

@@ -70,6 +70,10 @@ the operations defined in clk.h:
unsigned long parent_rate);
long (*round_rate)(struct clk_hw *hw, unsigned long,
unsigned long *);
long (*determine_rate)(struct clk_hw *hw,
unsigned long rate,
unsigned long *best_parent_rate,
struct clk **best_parent_clk);
int (*set_parent)(struct clk_hw *hw, u8 index);
u8 (*get_parent)(struct clk_hw *hw);
int (*set_rate)(struct clk_hw *hw, unsigned long);
@@ -191,7 +195,8 @@ optional or must be evaluated on a case-by-case basis.
.is_enabled | y | | | | |
| | | | | |
.recalc_rate | | y | | | |
.round_rate | | y | | | |
.round_rate | | y [1] | | | |
.determine_rate | | y [1] | | | |
.set_rate | | y | | | |
| | | | | |
.set_parent | | | n | y | n |
@@ -199,6 +204,7 @@ optional or must be evaluated on a case-by-case basis.
| | | | | |
.init | | | | | |
-----------------------------------------------------------
[1] either one of round_rate or determine_rate is required.
Finally, register your clock at run-time with a hardware-specific
registration function. This function simply populates struct clk_foo's

2
Documentation/connector/ucon.c
View File

@@ -71,7 +71,7 @@ static int netlink_send(int s, struct cn_msg *msg)
nlh->nlmsg_seq = seq++;
nlh->nlmsg_pid = getpid();
nlh->nlmsg_type = NLMSG_DONE;
nlh->nlmsg_len = NLMSG_LENGTH(size - sizeof(*nlh));
nlh->nlmsg_len = size;
nlh->nlmsg_flags = 0;
m = NLMSG_DATA(nlh);

27
Documentation/cpu-freq/cpu-drivers.txt
View File

@@ -23,8 +23,8 @@ Contents:
1.1 Initialization
1.2 Per-CPU Initialization
1.3 verify
1.4 target or setpolicy?
1.5 target
1.4 target/target_index or setpolicy?
1.5 target/target_index
1.6 setpolicy
2. Frequency Table Helpers
@@ -56,7 +56,8 @@ cpufreq_driver.init - A pointer to the per-CPU initialization
cpufreq_driver.verify - A pointer to a "verification" function.
cpufreq_driver.setpolicy _or_
cpufreq_driver.target - See below on the differences.
cpufreq_driver.target/
target_index - See below on the differences.
And optionally
@@ -66,7 +67,7 @@ cpufreq_driver.resume - A pointer to a per-CPU resume function
which is called with interrupts disabled
and _before_ the pre-suspend frequency
and/or policy is restored by a call to
->target or ->setpolicy.
->target/target_index or ->setpolicy.
cpufreq_driver.attr - A pointer to a NULL-terminated list of
"struct freq_attr" which allow to
@@ -103,8 +104,8 @@ policy->governor must contain the "default policy" for
this CPU. A few moments later,
cpufreq_driver.verify and either
cpufreq_driver.setpolicy or
cpufreq_driver.target is called with
these values.
cpufreq_driver.target/target_index is called
with these values.
For setting some of these values (cpuinfo.min[max]_freq, policy->min[max]), the
frequency table helpers might be helpful. See the section 2 for more information
@@ -133,20 +134,28 @@ range) is within policy->min and policy->max. If necessary, increase
policy->max first, and only if this is no solution, decrease policy->min.
1.4 target or setpolicy?
1.4 target/target_index or setpolicy?
----------------------------
Most cpufreq drivers or even most cpu frequency scaling algorithms
only allow the CPU to be set to one frequency. For these, you use the
->target call.
->target/target_index call.
Some cpufreq-capable processors switch the frequency between certain
limits on their own. These shall use the ->setpolicy call
1.4. target
1.4. target/target_index
-------------
The target_index call has two arguments: struct cpufreq_policy *policy,
and unsigned int index (into the exposed frequency table).
The CPUfreq driver must set the new frequency when called here. The
actual frequency must be determined by freq_table[index].frequency.
Deprecated:
----------
The target call has three arguments: struct cpufreq_policy *policy,
unsigned int target_frequency, unsigned int relation.

4
Documentation/cpu-freq/governors.txt
View File

@@ -40,7 +40,7 @@ Most cpufreq drivers (in fact, all except one, longrun) or even most
cpu frequency scaling algorithms only offer the CPU to be set to one
frequency. In order to offer dynamic frequency scaling, the cpufreq
core must be able to tell these drivers of a "target frequency". So
these specific drivers will be transformed to offer a "->target"
these specific drivers will be transformed to offer a "->target/target_index"
call instead of the existing "->setpolicy" call. For "longrun", all
stays the same, though.
@@ -71,7 +71,7 @@ CPU can be set to switch independently | CPU can only be set
/ the limits of policy->{min,max}
/ \
/ \
Using the ->setpolicy call, Using the ->target call,
Using the ->setpolicy call, Using the ->target/target_index call,
the limits and the the frequency closest
"policy" is set. to target_freq is set.
It is assured that it

2
Documentation/cpu-hotplug.txt
View File

@@ -5,7 +5,7 @@
Rusty Russell <rusty@rustcorp.com.au>
Srivatsa Vaddagiri <vatsa@in.ibm.com>
i386:
Zwane Mwaikambo <zwane@arm.linux.org.uk>
Zwane Mwaikambo <zwanem@gmail.com>
ppc64:
Nathan Lynch <nathanl@austin.ibm.com>
Joel Schopp <jschopp@austin.ibm.com>

1
Documentation/cpuidle/governor.txt
View File

@@ -25,5 +25,4 @@ kernel configuration and platform will be selected by cpuidle.
Interfaces:
extern int cpuidle_register_governor(struct cpuidle_governor *gov);
extern void cpuidle_unregister_governor(struct cpuidle_governor *gov);
struct cpuidle_governor

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

@@ -30,8 +30,10 @@ multiqueue
This policy is the default.
The multiqueue policy has two sets of 16 queues: one set for entries
waiting for the cache and another one for those in the cache.
The multiqueue policy has three sets of 16 queues: one set for entries
waiting for the cache and another two for those in the cache (a set for
clean entries and a set for dirty entries).
Cache entries in the queues are aged based on logical time. Entry into
the cache is based on variable thresholds and queue selection is based
on hit count on entry. The policy aims to take different cache miss

65
Documentation/device-mapper/cache.txt
View File

@@ -50,14 +50,16 @@ other parameters detailed later):
which are dirty, and extra hints for use by the policy object.
This information could be put on the cache device, but having it
separate allows the volume manager to configure it differently,
e.g. as a mirror for extra robustness.
e.g. as a mirror for extra robustness. This metadata device may only
be used by a single cache device.
Fixed block size
----------------
The origin is divided up into blocks of a fixed size. This block size
is configurable when you first create the cache. Typically we've been
using block sizes of 256k - 1024k.
using block sizes of 256KB - 1024KB. The block size must be between 64
(32KB) and 2097152 (1GB) and a multiple of 64 (32KB).
Having a fixed block size simplifies the target a lot. But it is
something of a compromise. For instance, a small part of a block may be
@@ -66,10 +68,11 @@ So large block sizes are bad because they waste cache space. And small
block sizes are bad because they increase the amount of metadata (both
in core and on disk).
Writeback/writethrough
----------------------
Cache operating modes
---------------------
The cache has two modes, writeback and writethrough.
The cache has three operating modes: writeback, writethrough and
passthrough.
If writeback, the default, is selected then a write to a block that is
cached will go only to the cache and the block will be marked dirty in
@@ -79,8 +82,31 @@ If writethrough is selected then a write to a cached block will not
complete until it has hit both the origin and cache devices. Clean
blocks should remain clean.
If passthrough is selected, useful when the cache contents are not known
to be coherent with the origin device, then all reads are served from
the origin device (all reads miss the cache) and all writes are
forwarded to the origin device; additionally, write hits cause cache
block invalidates. To enable passthrough mode the cache must be clean.
Passthrough mode allows a cache device to be activated without having to
worry about coherency. Coherency that exists is maintained, although
the cache will gradually cool as writes take place. If the coherency of
the cache can later be verified, or established through use of the
"invalidate_cblocks" message, the cache device can be transitioned to
writethrough or writeback mode while still warm. Otherwise, the cache
contents can be discarded prior to transitioning to the desired
operating mode.
A simple cleaner policy is provided, which will clean (write back) all
dirty blocks in a cache. Useful for decommissioning a cache.
dirty blocks in a cache. Useful for decommissioning a cache or when
shrinking a cache. Shrinking the cache's fast device requires all cache
blocks, in the area of the cache being removed, to be clean. If the
area being removed from the cache still contains dirty blocks the resize
will fail. Care must be taken to never reduce the volume used for the
cache's fast device until the cache is clean. This is of particular
importance if writeback mode is used. Writethrough and passthrough
modes already maintain a clean cache. Future support to partially clean
the cache, above a specified threshold, will allow for keeping the cache
warm and in writeback mode during resize.
Migration throttling
--------------------
@@ -159,7 +185,7 @@ Constructor
block size : cache unit size in sectors
#feature args : number of feature arguments passed
feature args : writethrough. (The default is writeback.)
feature args : writethrough or passthrough (The default is writeback.)
policy : the replacement policy to use
#policy args : an even number of arguments corresponding to
@@ -175,6 +201,13 @@ Optional feature arguments are:
back cache block contents later for performance reasons,
so they may differ from the corresponding origin blocks.
passthrough : a degraded mode useful for various cache coherency
situations (e.g., rolling back snapshots of
underlying storage). Reads and writes always go to
the origin. If a write goes to a cached origin
block, then the cache block is invalidated.
To enable passthrough mode the cache must be clean.
A policy called 'default' is always registered. This is an alias for
the policy we currently think is giving best all round performance.
@@ -229,12 +262,28 @@ The message format is:
E.g.
dmsetup message my_cache 0 sequential_threshold 1024
Invalidation is removing an entry from the cache without writing it
back. Cache blocks can be invalidated via the invalidate_cblocks
message, which takes an arbitrary number of cblock ranges. Each cblock
range's end value is "one past the end", meaning 5-10 expresses a range
of values from 5 to 9. Each cblock must be expressed as a decimal
value, in the future a variant message that takes cblock ranges
expressed in hexidecimal may be needed to better support efficient
invalidation of larger caches. The cache must be in passthrough mode
when invalidate_cblocks is used.
invalidate_cblocks [<cblock>|<cblock begin>-<cblock end>]*
E.g.
dmsetup message my_cache 0 invalidate_cblocks 2345 3456-4567 5678-6789
Examples
========
The test suite can be found here:
https://github.com/jthornber/thinp-test-suite
https://github.com/jthornber/device-mapper-test-suite
dmsetup create my_cache --table '0 41943040 cache /dev/mapper/metadata \
/dev/mapper/ssd /dev/mapper/origin 512 1 writeback default 0'

11
Documentation/device-mapper/dm-crypt.txt
View File

@@ -4,12 +4,15 @@ dm-crypt
Device-Mapper's "crypt" target provides transparent encryption of block devices
using the kernel crypto API.
For a more detailed description of supported parameters see:
http://code.google.com/p/cryptsetup/wiki/DMCrypt
Parameters: <cipher> <key> <iv_offset> <device path> \
<offset> [<#opt_params> <opt_params>]
<cipher>
Encryption cipher and an optional IV generation mode.
(In format cipher[:keycount]-chainmode-ivopts:ivmode).
(In format cipher[:keycount]-chainmode-ivmode[:ivopts]).
Examples:
des
aes-cbc-essiv:sha256
@@ -19,7 +22,11 @@ Parameters: <cipher> <key> <iv_offset> <device path> \
<key>
Key used for encryption. It is encoded as a hexadecimal number.
You can only use key sizes that are valid for the selected cipher.
You can only use key sizes that are valid for the selected cipher
in combination with the selected iv mode.
Note that for some iv modes the key string can contain additional
keys (for example IV seed) so the key contains more parts concatenated
into a single string.
<keycount>
Multi-key compatibility mode. You can define <keycount> keys and

186
Documentation/device-mapper/statistics.txt Normal file
View File

@@ -0,0 +1,186 @@
DM statistics
=============
Device Mapper supports the collection of I/O statistics on user-defined
regions of a DM device. If no regions are defined no statistics are
collected so there isn't any performance impact. Only bio-based DM
devices are currently supported.
Each user-defined region specifies a starting sector, length and step.
Individual statistics will be collected for each step-sized area within
the range specified.
The I/O statistics counters for each step-sized area of a region are
in the same format as /sys/block/*/stat or /proc/diskstats (see:
Documentation/iostats.txt). But two extra counters (12 and 13) are
provided: total time spent reading and writing in milliseconds. All
these counters may be accessed by sending the @stats_print message to
the appropriate DM device via dmsetup.
Each region has a corresponding unique identifier, which we call a
region_id, that is assigned when the region is created. The region_id
must be supplied when querying statistics about the region, deleting the
region, etc. Unique region_ids enable multiple userspace programs to
request and process statistics for the same DM device without stepping
on each other's data.
The creation of DM statistics will allocate memory via kmalloc or
fallback to using vmalloc space. At most, 1/4 of the overall system
memory may be allocated by DM statistics. The admin can see how much
memory is used by reading
/sys/module/dm_mod/parameters/stats_current_allocated_bytes
Messages
========
@stats_create <range> <step> [<program_id> [<aux_data>]]
Create a new region and return the region_id.
<range>
"-" - whole device
"<start_sector>+<length>" - a range of <length> 512-byte sectors
starting with <start_sector>.
<step>
"<area_size>" - the range is subdivided into areas each containing
<area_size> sectors.
"/<number_of_areas>" - the range is subdivided into the specified
number of areas.
<program_id>
An optional parameter. A name that uniquely identifies
the userspace owner of the range. This groups ranges together
so that userspace programs can identify the ranges they
created and ignore those created by others.
The kernel returns this string back in the output of
@stats_list message, but it doesn't use it for anything else.
<aux_data>
An optional parameter. A word that provides auxiliary data
that is useful to the client program that created the range.
The kernel returns this string back in the output of
@stats_list message, but it doesn't use this value for anything.
@stats_delete <region_id>
Delete the region with the specified id.
<region_id>
region_id returned from @stats_create
@stats_clear <region_id>
Clear all the counters except the in-flight i/o counters.
<region_id>
region_id returned from @stats_create
@stats_list [<program_id>]
List all regions registered with @stats_create.
<program_id>
An optional parameter.
If this parameter is specified, only matching regions
are returned.
If it is not specified, all regions are returned.
Output format:
<region_id>: <start_sector>+<length> <step> <program_id> <aux_data>
@stats_print <region_id> [<starting_line> <number_of_lines>]
Print counters for each step-sized area of a region.
<region_id>
region_id returned from @stats_create
<starting_line>
The index of the starting line in the output.
If omitted, all lines are returned.
<number_of_lines>
The number of lines to include in the output.
If omitted, all lines are returned.
Output format for each step-sized area of a region:
<start_sector>+<length> counters
The first 11 counters have the same meaning as
/sys/block/*/stat or /proc/diskstats.
Please refer to Documentation/iostats.txt for details.
1. the number of reads completed
2. the number of reads merged
3. the number of sectors read
4. the number of milliseconds spent reading
5. the number of writes completed
6. the number of writes merged
7. the number of sectors written
8. the number of milliseconds spent writing
9. the number of I/Os currently in progress
10. the number of milliseconds spent doing I/Os
11. the weighted number of milliseconds spent doing I/Os
Additional counters:
12. the total time spent reading in milliseconds
13. the total time spent writing in milliseconds
@stats_print_clear <region_id> [<starting_line> <number_of_lines>]
Atomically print and then clear all the counters except the
in-flight i/o counters. Useful when the client consuming the
statistics does not want to lose any statistics (those updated
between printing and clearing).
<region_id>
region_id returned from @stats_create
<starting_line>
The index of the starting line in the output.
If omitted, all lines are printed and then cleared.
<number_of_lines>
The number of lines to process.
If omitted, all lines are printed and then cleared.
@stats_set_aux <region_id> <aux_data>
Store auxiliary data aux_data for the specified region.
<region_id>
region_id returned from @stats_create
<aux_data>
The string that identifies data which is useful to the client
program that created the range. The kernel returns this
string back in the output of @stats_list message, but it
doesn't use this value for anything.
Examples
========
Subdivide the DM device 'vol' into 100 pieces and start collecting
statistics on them:
dmsetup message vol 0 @stats_create - /100
Set the auxillary data string to "foo bar baz" (the escape for each
space must also be escaped, otherwise the shell will consume them):
dmsetup message vol 0 @stats_set_aux 0 foo\\ bar\\ baz
List the statistics:
dmsetup message vol 0 @stats_list
Print the statistics:
dmsetup message vol 0 @stats_print 0
Delete the statistics:
dmsetup message vol 0 @stats_delete 0

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

@@ -99,13 +99,14 @@ Using an existing pool device
$data_block_size $low_water_mark"
$data_block_size gives the smallest unit of disk space that can be
allocated at a time expressed in units of 512-byte sectors. People
primarily interested in thin provisioning may want to use a value such
as 1024 (512KB). People doing lots of snapshotting may want a smaller value
such as 128 (64KB). If you are not zeroing newly-allocated data,
a larger $data_block_size in the region of 256000 (128MB) is suggested.
$data_block_size must be the same for the lifetime of the
metadata device.
allocated at a time expressed in units of 512-byte sectors.
$data_block_size must be between 128 (64KB) and 2097152 (1GB) and a
multiple of 128 (64KB). $data_block_size cannot be changed after the
thin-pool is created. People primarily interested in thin provisioning
may want to use a value such as 1024 (512KB). People doing lots of
snapshotting may want a smaller value such as 128 (64KB). If you are
not zeroing newly-allocated data, a larger $data_block_size in the
region of 256000 (128MB) is suggested.
$low_water_mark is expressed in blocks of size $data_block_size. If
free space on the data device drops below this level then a dm event

1
Documentation/devices.txt
View File

@@ -414,6 +414,7 @@ Your cooperation is appreciated.
200 = /dev/net/tun TAP/TUN network device
201 = /dev/button/gulpb Transmeta GULP-B buttons
202 = /dev/emd/ctl Enhanced Metadisk RAID (EMD) control
203 = /dev/cuse Cuse (character device in user-space)
204 = /dev/video/em8300 EM8300 DVD decoder control
205 = /dev/video/em8300_mv EM8300 DVD decoder video
206 = /dev/video/em8300_ma EM8300 DVD decoder audio

24
Documentation/devicetree/bindings/arc/pmu.txt Normal file
View File

@@ -0,0 +1,24 @@
* ARC Performance Monitor Unit
The ARC 700 can be configured with a pipeline performance monitor for counting
CPU and cache events like cache misses and hits.
Note that:
* ARC 700 refers to a family of ARC processor cores;
- There is only one type of PMU available for the whole family;
- The PMU may support different sets of events; supported events are probed
at boot time, as required by the reference manual.
* The ARC 700 PMU does not support interrupts; although HW events may be
counted, the HW events themselves cannot serve as a trigger for a sample.
Required properties:
- compatible : should contain
"snps,arc700-pmu"
Example:
pmu {
compatible = "snps,arc700-pmu";
};

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

@@ -9,9 +9,53 @@ Required properties (in root node):
FPGA type interrupt controllers, see the versatile-fpga-irq binding doc.
In the root node the Integrator/CP must have a /cpcon node pointing
to the CP control registers, and the Integrator/AP must have a
/syscon node pointing to the Integrator/AP system controller.
Required nodes:
- core-module: the root node to the Integrator platforms must have
a core-module with regs and the compatible string
"arm,core-module-integrator"
Required properties for the core module:
- regs: the location and size of the core module registers, one
range of 0x200 bytes.
- syscon: the root node of the Integrator platforms must have a
system controller node pointong to the control registers,
with the compatible string
"arm,integrator-ap-syscon"
"arm,integrator-cp-syscon"
respectively.
Required properties for the system controller:
- regs: the location and size of the system controller registers,
one range of 0x100 bytes.
Required properties for the AP system controller:
- interrupts: the AP syscon node must include the logical module
interrupts, stated in order of module instance <module 0>,
<module 1>, <module 2> ... for the CP system controller this
is not required not of any use.
/dts-v1/;
/include/ "integrator.dtsi"
/ {
model = "ARM Integrator/AP";
compatible = "arm,integrator-ap";
core-module@10000000 {
compatible = "arm,core-module-integrator";
reg = <0x10000000 0x200>;
};
syscon {
compatible = "arm,integrator-ap-syscon";
reg = <0x11000000 0x100>;
interrupt-parent = <&pic>;
/* These are the logic module IRQs */
interrupts = <9>, <10>, <11>, <12>;
};
};
ARM Versatile Application and Platform Baseboards

3
Documentation/devicetree/bindings/arm/armada-370-xp-mpic.txt
View File

@@ -4,6 +4,8 @@ Marvell Armada 370 and Armada XP Interrupt Controller
Required properties:
- compatible: Should be "marvell,mpic"
- interrupt-controller: Identifies the node as an interrupt controller.
- msi-controller: Identifies the node as an PCI Message Signaled
Interrupt controller.
- #interrupt-cells: The number of cells to define the interrupts. Should be 1.
The cell is the IRQ number
@@ -24,6 +26,7 @@ Example:
#address-cells = <1>;
#size-cells = <1>;
interrupt-controller;
msi-controller;
reg = <0xd0020a00 0x1d0>,
<0xd0021070 0x58>;
};

8
Documentation/devicetree/bindings/arm/atmel-adc.txt
View File

@@ -7,7 +7,6 @@ Required properties:
- interrupts: Should contain the IRQ line for the ADC
- atmel,adc-channels-used: Bitmask of the channels muxed and enable for this
device
- atmel,adc-num-channels: Number of channels available in the ADC
- atmel,adc-startup-time: Startup Time of the ADC in microseconds as
defined in the datasheet
- atmel,adc-vref: Reference voltage in millivolts for the conversions
@@ -24,6 +23,13 @@ Optional properties:
resolution will be used.
- atmel,adc-sleep-mode: Boolean to enable sleep mode when no conversion
- atmel,adc-sample-hold-time: Sample and Hold Time in microseconds
- atmel,adc-ts-wires: Number of touch screen wires. Should be 4 or 5. If this
value is set, then adc driver will enable touch screen
support.
NOTE: when adc touch screen enabled, the adc hardware trigger will be
disabled. Since touch screen will occupied the trigger register.
- atmel,adc-ts-pressure-threshold: a pressure threshold for touchscreen. It
make touch detect more precision.
Optional trigger Nodes:
- Required properties:

3
Documentation/devicetree/bindings/arm/bcm/bcm11351.txt
View File

@@ -6,4 +6,5 @@ bcm11351, bcm28145, bcm28155 SoCs) shall have the following properties:
Required root node property:
compatible = "bcm,bcm11351";
compatible = "brcm,bcm11351";
DEPRECATED: compatible = "bcm,bcm11351";

5
Documentation/devicetree/bindings/arm/bcm/bcm,kona-timer.txt → Documentation/devicetree/bindings/arm/bcm/kona-timer.txt
View File

@@ -4,14 +4,15 @@ This timer is used in the following Broadcom SoCs:
BCM11130, BCM11140, BCM11351, BCM28145, BCM28155
Required properties:
- compatible : "bcm,kona-timer"
- compatible : "brcm,kona-timer"
- DEPRECATED: compatible : "bcm,kona-timer"
- reg : Register range for the timer
- interrupts : interrupt for the timer
- clock-frequency: frequency that the clock operates
Example:
timer@35006000 {
compatible = "bcm,kona-timer";
compatible = "brcm,kona-timer";
reg = <0x35006000 0x1000>;
interrupts = <0x0 7 0x4>;
clock-frequency = <32768>;

15
Documentation/devicetree/bindings/arm/bcm/kona-wdt.txt Normal file
View File

@@ -0,0 +1,15 @@
Broadcom Kona Family Watchdog Timer
-----------------------------------
This watchdog timer is used in the following Broadcom SoCs:
BCM11130, BCM11140, BCM11351, BCM28145, BCM28155
Required properties:
- compatible = "brcm,bcm11351-wdt", "brcm,kona-wdt";
- reg: memory address & range
Example:
watchdog@35002f40 {
compatible = "brcm,bcm11351-wdt", "brcm,kona-wdt";
reg = <0x35002f40 0x6c>;
};

4
Documentation/devicetree/bindings/arm/calxeda/mem-ctrlr.txt
View File

@@ -1,7 +1,9 @@
Calxeda DDR memory controller
Properties:
- compatible : Should be "calxeda,hb-ddr-ctrl"
- compatible : Should be:
- "calxeda,hb-ddr-ctrl" for ECX-1000
- "calxeda,ecx-2000-ddr-ctrl" for ECX-2000
- reg : Address and size for DDR controller registers.
- interrupts : Interrupt for DDR controller.

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

@@ -36,14 +36,18 @@ specific to ARM.
- reg
Usage: required
Value type: <prop-encoded-array>
Value type: Integer cells. A register entry, expressed as a pair
of cells, containing base and size.
Definition: A standard property. Specifies base physical
address of CCI control registers common to all
interfaces.
- ranges:
Usage: required
Value type: <prop-encoded-array>
Value type: Integer cells. An array of range entries, expressed
as a tuple of cells, containing child address,
parent address and the size of the region in the
child address space.
Definition: A standard property. Follow rules in the ePAPR for
hierarchical bus addressing. CCI interfaces
addresses refer to the parent node addressing
@@ -74,11 +78,49 @@ specific to ARM.
- reg:
Usage: required
Value type: <prop-encoded-array>
Value type: Integer cells. A register entry, expressed
as a pair of cells, containing base and
size.
Definition: the base address and size of the
corresponding interface programming
registers.
- CCI PMU node
Parent node must be CCI interconnect node.
A CCI pmu node must contain the following properties:
- compatible
Usage: required
Value type: <string>
Definition: must be "arm,cci-400-pmu"
- reg:
Usage: required
Value type: Integer cells. A register entry, expressed
as a pair of cells, containing base and
size.
Definition: the base address and size of the
corresponding interface programming
registers.
- interrupts:
Usage: required
Value type: Integer cells. Array of interrupt specifier
entries, as defined in
../interrupt-controller/interrupts.txt.
Definition: list of counter overflow interrupts, one per
counter. The interrupts must be specified
starting with the cycle counter overflow
interrupt, followed by counter0 overflow
interrupt, counter1 overflow interrupt,...
,counterN overflow interrupt.
The CCI PMU has an interrupt signal for each
counter. The number of interrupts must be
equal to the number of counters.
* CCI interconnect bus masters
Description: masters in the device tree connected to a CCI port
@@ -144,7 +186,7 @@ Example:
#address-cells = <1>;
#size-cells = <1>;
reg = <0x0 0x2c090000 0 0x1000>;
ranges = <0x0 0x0 0x2c090000 0x6000>;
ranges = <0x0 0x0 0x2c090000 0x10000>;
cci_control0: slave-if@1000 {
compatible = "arm,cci-400-ctrl-if";
@@ -163,6 +205,16 @@ Example:
interface-type = "ace";
reg = <0x5000 0x1000>;
};
pmu@9000 {
compatible = "arm,cci-400-pmu";
reg = <0x9000 0x5000>;
interrupts = <0 101 4>,
<0 102 4>,
<0 103 4>,
<0 104 4>,
<0 105 4>;
};
};
This CCI node corresponds to a CCI component whose control registers sits

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

@@ -1,77 +1,384 @@
* ARM CPUs binding description
=================
ARM CPUs bindings
=================
The device tree allows to describe the layout of CPUs in a system through
the "cpus" node, which in turn contains a number of subnodes (ie "cpu")
defining properties for every cpu.
Bindings for CPU nodes follow the ePAPR standard, available from:
Bindings for CPU nodes follow the ePAPR v1.1 standard, available from:
http://devicetree.org
https://www.power.org/documentation/epapr-version-1-1/
For the ARM architecture every CPU node must contain the following properties:
with updates for 32-bit and 64-bit ARM systems provided in this document.
- device_type: must be "cpu"
- reg: property matching the CPU MPIDR[23:0] register bits
reg[31:24] bits must be set to 0
- compatible: should be one of:
"arm,arm1020"
"arm,arm1020e"
"arm,arm1022"
"arm,arm1026"
"arm,arm720"
"arm,arm740"
================================
Convention used in this document
================================
This document follows the conventions described in the ePAPR v1.1, with
the addition:
- square brackets define bitfields, eg reg[7:0] value of the bitfield in
the reg property contained in bits 7 down to 0
=====================================
cpus and cpu node bindings definition
=====================================
The ARM architecture, in accordance with the ePAPR, requires the cpus and cpu
nodes to be present and contain the properties described below.
- cpus node
Description: Container of cpu nodes
The node name must be "cpus".
A cpus node must define the following properties:
- #address-cells
Usage: required
Value type: <u32>
Definition depends on ARM architecture version and
configuration:
# On uniprocessor ARM architectures previous to v7
value must be 1, to enable a simple enumeration
scheme for processors that do not have a HW CPU
identification register.
# On 32-bit ARM 11 MPcore, ARM v7 or later systems
value must be 1, that corresponds to CPUID/MPIDR
registers sizes.
# On ARM v8 64-bit systems value should be set to 2,
that corresponds to the MPIDR_EL1 register size.
If MPIDR_EL1[63:32] value is equal to 0 on all CPUs
in the system, #address-cells can be set to 1, since
MPIDR_EL1[63:32] bits are not used for CPUs
identification.
- #size-cells
Usage: required
Value type: <u32>
Definition: must be set to 0
- cpu node
Description: Describes a CPU in an ARM based system
PROPERTIES
- device_type
Usage: required
Value type: <string>
Definition: must be "cpu"
- reg
Usage and definition depend on ARM architecture version and
configuration:
# On uniprocessor ARM architectures previous to v7
this property is required and must be set to 0.
# On ARM 11 MPcore based systems this property is
required and matches the CPUID[11:0] register bits.
Bits [11:0] in the reg cell must be set to
bits [11:0] in CPU ID register.
All other bits in the reg cell must be set to 0.
# On 32-bit ARM v7 or later systems this property is
required and matches the CPU MPIDR[23:0] register
bits.
Bits [23:0] in the reg cell must be set to
bits [23:0] in MPIDR.
All other bits in the reg cell must be set to 0.
# On ARM v8 64-bit systems this property is required
and matches the MPIDR_EL1 register affinity bits.
* If cpus node's #address-cells property is set to 2
The first reg cell bits [7:0] must be set to
bits [39:32] of MPIDR_EL1.
The second reg cell bits [23:0] must be set to
bits [23:0] of MPIDR_EL1.
* If cpus node's #address-cells property is set to 1
The reg cell bits [23:0] must be set to bits [23:0]
of MPIDR_EL1.
All other bits in the reg cells must be set to 0.
- compatible:
Usage: required
Value type: <string>
Definition: should be one of:
"arm,arm710t"
"arm,arm720t"
"arm,arm740t"
"arm,arm7ej-s"
"arm,arm7tdmi"
"arm,arm920"
"arm,arm922"
"arm,arm7tdmi-s"
"arm,arm9es"
"arm,arm9ej-s"
"arm,arm920t"
"arm,arm922t"
"arm,arm925"
"arm,arm926"
"arm,arm940"
"arm,arm946"
"arm,arm926e-s"
"arm,arm926ej-s"
"arm,arm940t"
"arm,arm946e-s"
"arm,arm966e-s"
"arm,arm968e-s"
"arm,arm9tdmi"
"arm,arm1020e"
"arm,arm1020t"
"arm,arm1022e"
"arm,arm1026ej-s"
"arm,arm1136j-s"
"arm,arm1136jf-s"
"arm,arm1156t2-s"
"arm,arm1156t2f-s"
"arm,arm1176jzf"
"arm,arm1176jz-s"
"arm,arm1176jzf-s"
"arm,arm11mpcore"
"arm,cortex-a5"
"arm,cortex-a7"
"arm,cortex-a8"
"arm,cortex-a9"
"arm,cortex-a15"
"arm,arm1136"
"arm,arm1156"
"arm,arm1176"
"arm,arm11mpcore"
"arm,cortex-a53"
"arm,cortex-a57"
"arm,cortex-m0"
"arm,cortex-m0+"
"arm,cortex-m1"
"arm,cortex-m3"
"arm,cortex-m4"
"arm,cortex-r4"
"arm,cortex-r5"
"arm,cortex-r7"
"faraday,fa526"
"intel,sa110"
"intel,sa1100"
"marvell,feroceon"
"marvell,mohawk"
"marvell,xsc3"
"marvell,xscale"
"marvell,pj4a"
"marvell,pj4b"
"marvell,sheeva-v5"
"qcom,krait"
"qcom,scorpion"
- enable-method
Value type: <stringlist>
Usage and definition depend on ARM architecture version.
# On ARM v8 64-bit this property is required and must
be one of:
"spin-table"
"psci"
# On ARM 32-bit systems this property is optional.
Example:
- cpu-release-addr
Usage: required for systems that have an "enable-method"
property value of "spin-table".
Value type: <prop-encoded-array>
Definition:
# On ARM v8 64-bit systems must be a two cell
property identifying a 64-bit zero-initialised
memory location.
Example 1 (dual-cluster big.LITTLE system 32-bit):
cpus {
#size-cells = <0>;
#address-cells = <1>;
CPU0: cpu@0 {
cpu@0 {
device_type = "cpu";
compatible = "arm,cortex-a15";
reg = <0x0>;
};
CPU1: cpu@1 {
cpu@1 {
device_type = "cpu";
compatible = "arm,cortex-a15";
reg = <0x1>;
};
CPU2: cpu@100 {
cpu@100 {
device_type = "cpu";
compatible = "arm,cortex-a7";
reg = <0x100>;
};
CPU3: cpu@101 {
cpu@101 {
device_type = "cpu";
compatible = "arm,cortex-a7";
reg = <0x101>;
};
};
Example 2 (Cortex-A8 uniprocessor 32-bit system):
cpus {
#size-cells = <0>;
#address-cells = <1>;
cpu@0 {
device_type = "cpu";
compatible = "arm,cortex-a8";
reg = <0x0>;
};
};
Example 3 (ARM 926EJ-S uniprocessor 32-bit system):
cpus {
#size-cells = <0>;
#address-cells = <1>;
cpu@0 {
device_type = "cpu";
compatible = "arm,arm926ej-s";
reg = <0x0>;
};
};
Example 4 (ARM Cortex-A57 64-bit system):
cpus {
#size-cells = <0>;
#address-cells = <2>;
cpu@0 {
device_type = "cpu";
compatible = "arm,cortex-a57";
reg = <0x0 0x0>;
enable-method = "spin-table";
cpu-release-addr = <0 0x20000000>;
};
cpu@1 {
device_type = "cpu";
compatible = "arm,cortex-a57";
reg = <0x0 0x1>;
enable-method = "spin-table";
cpu-release-addr = <0 0x20000000>;
};
cpu@100 {
device_type = "cpu";
compatible = "arm,cortex-a57";
reg = <0x0 0x100>;
enable-method = "spin-table";
cpu-release-addr = <0 0x20000000>;
};
cpu@101 {
device_type = "cpu";
compatible = "arm,cortex-a57";
reg = <0x0 0x101>;
enable-method = "spin-table";
cpu-release-addr = <0 0x20000000>;
};
cpu@10000 {
device_type = "cpu";
compatible = "arm,cortex-a57";
reg = <0x0 0x10000>;
enable-method = "spin-table";
cpu-release-addr = <0 0x20000000>;
};
cpu@10001 {
device_type = "cpu";
compatible = "arm,cortex-a57";
reg = <0x0 0x10001>;
enable-method = "spin-table";
cpu-release-addr = <0 0x20000000>;
};
cpu@10100 {
device_type = "cpu";
compatible = "arm,cortex-a57";
reg = <0x0 0x10100>;
enable-method = "spin-table";
cpu-release-addr = <0 0x20000000>;
};
cpu@10101 {
device_type = "cpu";
compatible = "arm,cortex-a57";
reg = <0x0 0x10101>;
enable-method = "spin-table";
cpu-release-addr = <0 0x20000000>;
};
cpu@100000000 {
device_type = "cpu";
compatible = "arm,cortex-a57";
reg = <0x1 0x0>;
enable-method = "spin-table";
cpu-release-addr = <0 0x20000000>;
};
cpu@100000001 {
device_type = "cpu";
compatible = "arm,cortex-a57";
reg = <0x1 0x1>;
enable-method = "spin-table";
cpu-release-addr = <0 0x20000000>;
};
cpu@100000100 {
device_type = "cpu";
compatible = "arm,cortex-a57";
reg = <0x1 0x100>;
enable-method = "spin-table";
cpu-release-addr = <0 0x20000000>;
};
cpu@100000101 {
device_type = "cpu";
compatible = "arm,cortex-a57";
reg = <0x1 0x101>;
enable-method = "spin-table";
cpu-release-addr = <0 0x20000000>;
};
cpu@100010000 {
device_type = "cpu";
compatible = "arm,cortex-a57";
reg = <0x1 0x10000>;
enable-method = "spin-table";
cpu-release-addr = <0 0x20000000>;
};
cpu@100010001 {
device_type = "cpu";
compatible = "arm,cortex-a57";
reg = <0x1 0x10001>;
enable-method = "spin-table";
cpu-release-addr = <0 0x20000000>;
};
cpu@100010100 {
device_type = "cpu";
compatible = "arm,cortex-a57";
reg = <0x1 0x10100>;
enable-method = "spin-table";
cpu-release-addr = <0 0x20000000>;
};
cpu@100010101 {
device_type = "cpu";
compatible = "arm,cortex-a57";
reg = <0x1 0x10101>;
enable-method = "spin-table";
cpu-release-addr = <0 0x20000000>;
};
};

8
Documentation/devicetree/bindings/arm/omap/mpu.txt
View File

@@ -7,10 +7,18 @@ The MPU contain CPUs, GIC, L2 cache and a local PRCM.
Required properties:
- compatible : Should be "ti,omap3-mpu" for OMAP3
Should be "ti,omap4-mpu" for OMAP4
Should be "ti,omap5-mpu" for OMAP5
- ti,hwmods: "mpu"
Examples:
- For an OMAP5 SMP system:
mpu {
compatible = "ti,omap5-mpu";
ti,hwmods = "mpu"
};
- For an OMAP4 SMP system:
mpu {

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

@@ -21,7 +21,8 @@ Required properties:
Optional properties:
- ti,no_idle_on_suspend: When present, it prevents the PM to idle the module
during suspend.
- ti,no-reset-on-init: When present, the module should not be reset at init
- ti,no-idle-on-init: When present, the module should not be idled at init
Example:
@@ -59,3 +60,6 @@ Boards:
- AM43x EPOS EVM
compatible = "ti,am43x-epos-evm", "ti,am4372", "ti,am43"
- DRA7 EVM: Software Developement Board for DRA7XX
compatible = "ti,dra7-evm", "ti,dra7"

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

@@ -7,6 +7,7 @@ representation in the device tree should be done as under:-
Required properties:
- compatible : should be one of
"arm,armv8-pmuv3"
"arm,cortex-a15-pmu"
"arm,cortex-a9-pmu"
"arm,cortex-a8-pmu"

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

@@ -49,7 +49,7 @@ adc@12D10000 {
/* NTC thermistor is a hwmon device */
ncp15wb473@0 {
compatible = "ntc,ncp15wb473";
pullup-uV = <1800000>;
pullup-uv = <1800000>;
pullup-ohm = <47000>;
pulldown-ohm = <0>;
io-channels = <&adc 4>;

474
Documentation/devicetree/bindings/arm/topology.txt Normal file
View File

@@ -0,0 +1,474 @@
===========================================
ARM topology binding description
===========================================
===========================================
1 - Introduction
===========================================
In an ARM system, the hierarchy of CPUs is defined through three entities that
are used to describe the layout of physical CPUs in the system:
- cluster
- core
- thread
The cpu nodes (bindings defined in [1]) represent the devices that
correspond to physical CPUs and are to be mapped to the hierarchy levels.
The bottom hierarchy level sits at core or thread level depending on whether
symmetric multi-threading (SMT) is supported or not.
For instance in a system where CPUs support SMT, "cpu" nodes represent all
threads existing in the system and map to the hierarchy level "thread" above.
In systems where SMT is not supported "cpu" nodes represent all cores present
in the system and map to the hierarchy level "core" above.
ARM topology bindings allow one to associate cpu nodes with hierarchical groups
corresponding to the system hierarchy; syntactically they are defined as device
tree nodes.
The remainder of this document provides the topology bindings for ARM, based
on the ePAPR standard, available from:
http://www.power.org/documentation/epapr-version-1-1/
If not stated otherwise, whenever a reference to a cpu node phandle is made its
value must point to a cpu node compliant with the cpu node bindings as
documented in [1].
A topology description containing phandles to cpu nodes that are not compliant
with bindings standardized in [1] is therefore considered invalid.
===========================================
2 - cpu-map node
===========================================
The ARM CPU topology is defined within the cpu-map node, which is a direct
child of the cpus node and provides a container where the actual topology
nodes are listed.
- cpu-map node
Usage: Optional - On ARM SMP systems provide CPUs topology to the OS.
ARM uniprocessor systems do not require a topology
description and therefore should not define a
cpu-map node.
Description: The cpu-map node is just a container node where its
subnodes describe the CPU topology.
Node name must be "cpu-map".
The cpu-map node's parent node must be the cpus node.
The cpu-map node's child nodes can be:
- one or more cluster nodes
Any other configuration is considered invalid.
The cpu-map node can only contain three types of child nodes:
- cluster node
- core node
- thread node
whose bindings are described in paragraph 3.
The nodes describing the CPU topology (cluster/core/thread) can only be
defined within the cpu-map node.
Any other configuration is consider invalid and therefore must be ignored.
===========================================
2.1 - cpu-map child nodes naming convention
===========================================
cpu-map child nodes must follow a naming convention where the node name
must be "clusterN", "coreN", "threadN" depending on the node type (ie
cluster/core/thread) (where N = {0, 1, ...} is the node number; nodes which
are siblings within a single common parent node must be given a unique and
sequential N value, starting from 0).
cpu-map child nodes which do not share a common parent node can have the same
name (ie same number N as other cpu-map child nodes at different device tree
levels) since name uniqueness will be guaranteed by the device tree hierarchy.
===========================================
3 - cluster/core/thread node bindings
===========================================
Bindings for cluster/cpu/thread nodes are defined as follows:
- cluster node
Description: must be declared within a cpu-map node, one node
per cluster. A system can contain several layers of
clustering and cluster nodes can be contained in parent
cluster nodes.
The cluster node name must be "clusterN" as described in 2.1 above.
A cluster node can not be a leaf node.
A cluster node's child nodes must be:
- one or more cluster nodes; or
- one or more core nodes
Any other configuration is considered invalid.
- core node
Description: must be declared in a cluster node, one node per core in
the cluster. If the system does not support SMT, core
nodes are leaf nodes, otherwise they become containers of
thread nodes.
The core node name must be "coreN" as described in 2.1 above.
A core node must be a leaf node if SMT is not supported.
Properties for core nodes that are leaf nodes:
- cpu
Usage: required
Value type: <phandle>
Definition: a phandle to the cpu node that corresponds to the
core node.
If a core node is not a leaf node (CPUs supporting SMT) a core node's
child nodes can be:
- one or more thread nodes
Any other configuration is considered invalid.
- thread node
Description: must be declared in a core node, one node per thread
in the core if the system supports SMT. Thread nodes are
always leaf nodes in the device tree.
The thread node name must be "threadN" as described in 2.1 above.
A thread node must be a leaf node.
A thread node must contain the following property:
- cpu
Usage: required
Value type: <phandle>
Definition: a phandle to the cpu node that corresponds to
the thread node.
===========================================
4 - Example dts
===========================================
Example 1 (ARM 64-bit, 16-cpu system, two clusters of clusters):
cpus {
#size-cells = <0>;
#address-cells = <2>;
cpu-map {
cluster0 {
cluster0 {
core0 {
thread0 {
cpu = <&CPU0>;
};
thread1 {
cpu = <&CPU1>;
};
};
core1 {
thread0 {
cpu = <&CPU2>;
};
thread1 {
cpu = <&CPU3>;
};
};
};
cluster1 {
core0 {
thread0 {
cpu = <&CPU4>;
};
thread1 {
cpu = <&CPU5>;
};
};
core1 {
thread0 {
cpu = <&CPU6>;
};
thread1 {
cpu = <&CPU7>;
};
};
};
};
cluster1 {
cluster0 {
core0 {
thread0 {
cpu = <&CPU8>;
};
thread1 {
cpu = <&CPU9>;
};
};
core1 {
thread0 {
cpu = <&CPU10>;
};
thread1 {
cpu = <&CPU11>;
};
};
};
cluster1 {
core0 {
thread0 {
cpu = <&CPU12>;
};
thread1 {
cpu = <&CPU13>;
};
};
core1 {
thread0 {
cpu = <&CPU14>;
};
thread1 {
cpu = <&CPU15>;
};
};
};
};
};
CPU0: cpu@0 {
device_type = "cpu";
compatible = "arm,cortex-a57";
reg = <0x0 0x0>;
enable-method = "spin-table";
cpu-release-addr = <0 0x20000000>;
};
CPU1: cpu@1 {
device_type = "cpu";
compatible = "arm,cortex-a57";
reg = <0x0 0x1>;
enable-method = "spin-table";
cpu-release-addr = <0 0x20000000>;
};
CPU2: cpu@100 {
device_type = "cpu";
compatible = "arm,cortex-a57";
reg = <0x0 0x100>;
enable-method = "spin-table";
cpu-release-addr = <0 0x20000000>;
};
CPU3: cpu@101 {
device_type = "cpu";
compatible = "arm,cortex-a57";
reg = <0x0 0x101>;
enable-method = "spin-table";
cpu-release-addr = <0 0x20000000>;
};
CPU4: cpu@10000 {
device_type = "cpu";
compatible = "arm,cortex-a57";
reg = <0x0 0x10000>;
enable-method = "spin-table";
cpu-release-addr = <0 0x20000000>;
};
CPU5: cpu@10001 {
device_type = "cpu";
compatible = "arm,cortex-a57";
reg = <0x0 0x10001>;
enable-method = "spin-table";
cpu-release-addr = <0 0x20000000>;
};
CPU6: cpu@10100 {
device_type = "cpu";
compatible = "arm,cortex-a57";
reg = <0x0 0x10100>;
enable-method = "spin-table";
cpu-release-addr = <0 0x20000000>;
};
CPU7: cpu@10101 {
device_type = "cpu";
compatible = "arm,cortex-a57";
reg = <0x0 0x10101>;
enable-method = "spin-table";
cpu-release-addr = <0 0x20000000>;
};
CPU8: cpu@100000000 {
device_type = "cpu";
compatible = "arm,cortex-a57";
reg = <0x1 0x0>;
enable-method = "spin-table";
cpu-release-addr = <0 0x20000000>;
};
CPU9: cpu@100000001 {
device_type = "cpu";
compatible = "arm,cortex-a57";
reg = <0x1 0x1>;
enable-method = "spin-table";
cpu-release-addr = <0 0x20000000>;
};
CPU10: cpu@100000100 {
device_type = "cpu";
compatible = "arm,cortex-a57";
reg = <0x1 0x100>;
enable-method = "spin-table";
cpu-release-addr = <0 0x20000000>;
};
CPU11: cpu@100000101 {
device_type = "cpu";
compatible = "arm,cortex-a57";
reg = <0x1 0x101>;
enable-method = "spin-table";
cpu-release-addr = <0 0x20000000>;
};
CPU12: cpu@100010000 {
device_type = "cpu";
compatible = "arm,cortex-a57";
reg = <0x1 0x10000>;
enable-method = "spin-table";
cpu-release-addr = <0 0x20000000>;
};
CPU13: cpu@100010001 {
device_type = "cpu";
compatible = "arm,cortex-a57";
reg = <0x1 0x10001>;
enable-method = "spin-table";
cpu-release-addr = <0 0x20000000>;
};
CPU14: cpu@100010100 {
device_type = "cpu";
compatible = "arm,cortex-a57";
reg = <0x1 0x10100>;
enable-method = "spin-table";
cpu-release-addr = <0 0x20000000>;
};
CPU15: cpu@100010101 {
device_type = "cpu";
compatible = "arm,cortex-a57";
reg = <0x1 0x10101>;
enable-method = "spin-table";
cpu-release-addr = <0 0x20000000>;
};
};
Example 2 (ARM 32-bit, dual-cluster, 8-cpu system, no SMT):
cpus {
#size-cells = <0>;
#address-cells = <1>;
cpu-map {
cluster0 {
core0 {
cpu = <&CPU0>;
};
core1 {
cpu = <&CPU1>;
};
core2 {
cpu = <&CPU2>;
};
core3 {
cpu = <&CPU3>;
};
};
cluster1 {
core0 {
cpu = <&CPU4>;
};
core1 {
cpu = <&CPU5>;
};
core2 {
cpu = <&CPU6>;
};
core3 {
cpu = <&CPU7>;
};
};
};
CPU0: cpu@0 {
device_type = "cpu";
compatible = "arm,cortex-a15";
reg = <0x0>;
};
CPU1: cpu@1 {
device_type = "cpu";
compatible = "arm,cortex-a15";
reg = <0x1>;
};
CPU2: cpu@2 {
device_type = "cpu";
compatible = "arm,cortex-a15";
reg = <0x2>;
};
CPU3: cpu@3 {
device_type = "cpu";
compatible = "arm,cortex-a15";
reg = <0x3>;
};
CPU4: cpu@100 {
device_type = "cpu";
compatible = "arm,cortex-a7";
reg = <0x100>;
};
CPU5: cpu@101 {
device_type = "cpu";
compatible = "arm,cortex-a7";
reg = <0x101>;
};
CPU6: cpu@102 {
device_type = "cpu";
compatible = "arm,cortex-a7";
reg = <0x102>;
};
CPU7: cpu@103 {
device_type = "cpu";
compatible = "arm,cortex-a7";
reg = <0x103>;
};
};
===============================================================================
[1] ARM Linux kernel documentation
Documentation/devicetree/bindings/arm/cpus.txt

33
Documentation/devicetree/bindings/arm/vexpress-scc.txt Normal file
View File

@@ -0,0 +1,33 @@
ARM Versatile Express Serial Configuration Controller
-----------------------------------------------------
Test chips for ARM Versatile Express platform implement SCC (Serial
Configuration Controller) interface, used to set initial conditions
for the test chip.
In some cases its registers are also mapped in normal address space
and can be used to obtain runtime information about the chip internals
(like silicon temperature sensors) and as interface to other subsystems
like platform configuration control and power management.
Required properties:
- compatible value: "arm,vexpress-scc,<model>", "arm,vexpress-scc";
where <model> is the full tile model name (as used
in the tile's Technical Reference Manual),
eg. for Coretile Express A15x2 A7x3 (V2P-CA15_A7):
compatible = "arm,vexpress-scc,v2p-ca15_a7", "arm,vexpress-scc";
Optional properties:
- reg: when the SCC is memory mapped, physical address and size of the
registers window
- interrupts: when the SCC can generate a system-level interrupt
Example:
scc@7fff0000 {
compatible = "arm,vexpress-scc,v2p-ca15_a7", "arm,vexpress-scc";
reg = <0 0x7fff0000 0 0x1000>;
interrupts = <0 95 4>;
};

12
Documentation/devicetree/bindings/arm/vic.txt
View File

@@ -18,6 +18,15 @@ Required properties:
Optional properties:
- interrupts : Interrupt source for parent controllers if the VIC is nested.
- valid-mask : A one cell big bit mask of valid interrupt sources. Each bit
represents single interrupt source, starting from source 0 at LSb and ending
at source 31 at MSb. A bit that is set means that the source is wired and
clear means otherwise. If unspecified, defaults to all valid.
- valid-wakeup-mask : A one cell big bit mask of interrupt sources that can be
configured as wake up source for the system. Order of bits is the same as for
valid-mask property. A set bit means that this interrupt source can be
configured as a wake up source for the system. If unspecied, defaults to all
interrupt sources configurable as wake up sources.
Example:
@@ -26,4 +35,7 @@ Example:
interrupt-controller;
#interrupt-cells = <1>;
reg = <0x60000 0x1000>;
valid-mask = <0xffffff7f>;
valid-wakeup-mask = <0x0000ff7f>;
};

17
Documentation/devicetree/bindings/bus/imx-weim.txt
View File

@@ -8,7 +8,7 @@ The actual devices are instantiated from the child nodes of a WEIM node.
Required properties:
- compatible: Should be set to "fsl,imx6q-weim"
- compatible: Should be set to "fsl,<soc>-weim"
- reg: A resource specifier for the register space
(see the example below)
- clocks: the clock, see the example below.
@@ -21,11 +21,18 @@ Required properties:
Timing property for child nodes. It is mandatory, not optional.
- fsl,weim-cs-timing: The timing array, contains 6 timing values for the
- fsl,weim-cs-timing: The timing array, contains timing values for the
child node. We can get the CS index from the child
node's "reg" property. This property contains the values
for the registers EIM_CSnGCR1, EIM_CSnGCR2, EIM_CSnRCR1,
EIM_CSnRCR2, EIM_CSnWCR1, EIM_CSnWCR2 in this order.
node's "reg" property. The number of registers depends
on the selected chip.
For i.MX1, i.MX21 ("fsl,imx1-weim") there are two
registers: CSxU, CSxL.
For i.MX25, i.MX27, i.MX31 and i.MX35 ("fsl,imx27-weim")
there are three registers: CSCRxU, CSCRxL, CSCRxA.
For i.MX50, i.MX53 ("fsl,imx50-weim"),
i.MX51 ("fsl,imx51-weim") and i.MX6Q ("fsl,imx6q-weim")
there are six registers: CSxGCR1, CSxGCR2, CSxRCR1,
CSxRCR2, CSxWCR1, CSxWCR2.
Example for an imx6q-sabreauto board, the NOR flash connected to the WEIM:

276
Documentation/devicetree/bindings/bus/mvebu-mbus.txt Normal file
View File

@@ -0,0 +1,276 @@
* Marvell MBus
Required properties:
- compatible: Should be set to one of the following:
marvell,armada370-mbus
marvell,armadaxp-mbus
marvell,armada370-mbus
marvell,armadaxp-mbus
marvell,kirkwood-mbus
marvell,dove-mbus
marvell,orion5x-88f5281-mbus
marvell,orion5x-88f5182-mbus
marvell,orion5x-88f5181-mbus
marvell,orion5x-88f6183-mbus
marvell,mv78xx0-mbus
- address-cells: Must be '2'. The first cell for the MBus ID encoding,
the second cell for the address offset within the window.
- size-cells: Must be '1'.
- ranges: Must be set up to provide a proper translation for each child.
See the examples below.
- controller: Contains a single phandle referring to the MBus controller
node. This allows to specify the node that contains the
registers that control the MBus, which is typically contained
within the internal register window (see below).
Optional properties:
- pcie-mem-aperture: This optional property contains the aperture for
the memory region of the PCIe driver.
If it's defined, it must encode the base address and
size for the address decoding windows allocated for
the PCIe memory region.
- pcie-io-aperture: Just as explained for the above property, this
optional property contains the aperture for the
I/O region of the PCIe driver.
* Marvell MBus controller
Required properties:
- compatible: Should be set to "marvell,mbus-controller".
- reg: Device's register space.
Two entries are expected (see the examples below):
the first one controls the devices decoding window and
the second one controls the SDRAM decoding window.
Example:
soc {
compatible = "marvell,armada370-mbus", "simple-bus";
#address-cells = <2>;
#size-cells = <1>;
controller = <&mbusc>;
pcie-mem-aperture = <0xe0000000 0x8000000>;
pcie-io-aperture = <0xe8000000 0x100000>;
internal-regs {
compatible = "simple-bus";
mbusc: mbus-controller@20000 {
compatible = "marvell,mbus-controller";
reg = <0x20000 0x100>, <0x20180 0x20>;
};
/* more children ...*/
};
};
** MBus address decoding window specification
The MBus children address space is comprised of two cells: the first one for
the window ID and the second one for the offset within the window.
In order to allow to describe valid and non-valid window entries, the
following encoding is used:
0xSIAA0000 0x00oooooo
Where:
S = 0x0 for a MBus valid window
S = 0xf for a non-valid window (see below)
If S = 0x0, then:
I = 4-bit window target ID
AA = windpw attribute
If S = 0xf, then:
I = don't care
AA = 1 for internal register
Following the above encoding, for each ranges entry for a MBus valid window
(S = 0x0), an address decoding window is allocated. On the other side,
entries for translation that do not correspond to valid windows (S = 0xf)
are skipped.
soc {
compatible = "marvell,armada370-mbus", "simple-bus";
#address-cells = <2>;
#size-cells = <1>;
controller = <&mbusc>;
ranges = <0xf0010000 0 0 0xd0000000 0x100000
0x01e00000 0 0 0xfff00000 0x100000>;
bootrom {
compatible = "marvell,bootrom";
reg = <0x01e00000 0 0x100000>;
};
/* other children */
...
internal-regs {
compatible = "simple-bus";
ranges = <0 0xf0010000 0 0x100000>;
mbusc: mbus-controller@20000 {
compatible = "marvell,mbus-controller";
reg = <0x20000 0x100>, <0x20180 0x20>;
};
/* more children ...*/
};
};
In the shown example, the translation entry in the 'ranges' property is what
makes the MBus driver create a static decoding window for the corresponding
given child device. Note that the binding does not require child nodes to be
present. Of course, child nodes are needed to probe the devices.
Since each window is identified by its target ID and attribute ID there's
a special macro that can be use to simplify the translation entries:
#define MBUS_ID(target,attributes) (((target) << 24) | ((attributes) << 16))
Using this macro, the above example would be:
soc {
compatible = "marvell,armada370-mbus", "simple-bus";
#address-cells = <2>;
#size-cells = <1>;
controller = <&mbusc>;
ranges = < MBUS_ID(0xf0, 0x01) 0 0 0xd0000000 0x100000
MBUS_ID(0x01, 0xe0) 0 0 0xfff00000 0x100000>;
bootrom {
compatible = "marvell,bootrom";
reg = <MBUS_ID(0x01, 0xe0) 0 0x100000>;
};
/* other children */
...
internal-regs {
compatible = "simple-bus";
#address-cells = <1>;
#size-cells = <1>;
ranges = <0 MBUS_ID(0xf0, 0x01) 0 0x100000>;
mbusc: mbus-controller@20000 {
compatible = "marvell,mbus-controller";
reg = <0x20000 0x100>, <0x20180 0x20>;
};
/* other children */
...
};
};
** About the window base address
Remember the MBus controller allows a great deal of flexibility for choosing
the decoding window base address. When planning the device tree layout it's
possible to choose any address as the base address, provided of course there's
a region large enough available, and with the required alignment.
Yet in other words: there's nothing preventing us from setting a base address
of 0xf0000000, or 0xd0000000 for the NOR device shown above, if such region is
unused.
** Window allocation policy
The mbus-node ranges property defines a set of mbus windows that are expected
to be set by the operating system and that are guaranteed to be free of overlaps
with one another or with the system memory ranges.
Each entry in the property refers to exactly one window. If the operating system
choses to use a different set of mbus windows, it must ensure that any address
translations performed from downstream devices are adapted accordingly.
The operating system may insert additional mbus windows that do not conflict
with the ones listed in the ranges, e.g. for mapping PCIe devices.
As a special case, the internal register window must be set up by the boot
loader at the address listed in the ranges property, since access to that region
is needed to set up the other windows.
** Example
See the example below, where a more complete device tree is shown:
soc {
compatible = "marvell,armadaxp-mbus", "simple-bus";
controller = <&mbusc>;
ranges = <MBUS_ID(0xf0, 0x01) 0 0 0xd0000000 0x100000 /* internal-regs */
MBUS_ID(0x01, 0x1d) 0 0 0xfff00000 0x100000
MBUS_ID(0x01, 0x2f) 0 0 0xf0000000 0x8000000>;
bootrom {
compatible = "marvell,bootrom";
reg = <MBUS_ID(0x01, 0x1d) 0 0x100000>;
};
devbus-bootcs {
status = "okay";
ranges = <0 MBUS_ID(0x01, 0x2f) 0 0x8000000>;
/* NOR */
nor {
compatible = "cfi-flash";
reg = <0 0x8000000>;
bank-width = <2>;
};
};
pcie-controller {
compatible = "marvell,armada-xp-pcie";
status = "okay";
device_type = "pci";
#address-cells = <3>;
#size-cells = <2>;
ranges =
<0x82000000 0 0x40000 MBUS_ID(0xf0, 0x01) 0x40000 0 0x00002000 /* Port 0.0 registers */
0x82000000 0 0x42000 MBUS_ID(0xf0, 0x01) 0x42000 0 0x00002000 /* Port 2.0 registers */
0x82000000 0 0x44000 MBUS_ID(0xf0, 0x01) 0x44000 0 0x00002000 /* Port 0.1 registers */
0x82000000 0 0x48000 MBUS_ID(0xf0, 0x01) 0x48000 0 0x00002000 /* Port 0.2 registers */
0x82000000 0 0x4c000 MBUS_ID(0xf0, 0x01) 0x4c000 0 0x00002000 /* Port 0.3 registers */
0x82000800 0 0xe0000000 MBUS_ID(0x04, 0xe8) 0xe0000000 0 0x08000000 /* Port 0.0 MEM */
0x81000800 0 0 MBUS_ID(0x04, 0xe0) 0xe8000000 0 0x00100000 /* Port 0.0 IO */>;
pcie@1,0 {
/* Port 0, Lane 0 */
status = "okay";
};
};
internal-regs {
compatible = "simple-bus";
#address-cells = <1>;
#size-cells = <1>;
ranges = <0 MBUS_ID(0xf0, 0x01) 0 0x100000>;
mbusc: mbus-controller@20000 {
reg = <0x20000 0x100>, <0x20180 0x20>;
};
interrupt-controller@20000 {
reg = <0x20a00 0x2d0>, <0x21070 0x58>;
};
};
};

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

@@ -0,0 +1,11 @@
* Clock bindings for Energy Micro efm32 Giant Gecko's Clock Management Unit
Required properties:
- compatible: Should be "efm32gg,cmu"
- reg: Base address and length of the register set
- interrupts: Interrupt used by the CMU
- #clock-cells: Should be <1>
The clock consumer should specify the desired clock by having the clock ID in
its "clocks" phandle cell. The header efm32-clk.h contains a list of available
IDs.

3
Documentation/devicetree/bindings/clock/exynos4-clock.txt
View File

@@ -6,7 +6,7 @@ SoC's in the Exynos4 family.
Required Properties:
- comptible: should be one of the following.
- compatible: should be one of the following.
- "samsung,exynos4210-clock" - controller compatible with Exynos4210 SoC.
- "samsung,exynos4412-clock" - controller compatible with Exynos4412 SoC.
@@ -236,6 +236,7 @@ Exynos4 SoC and this is specified where applicable.
spi0_isp_sclk 380 Exynos4x12
spi1_isp_sclk 381 Exynos4x12
uart_isp_sclk 382 Exynos4x12
tmu_apbif 383
[Mux Clocks]

16
Documentation/devicetree/bindings/clock/exynos5250-clock.txt
View File

@@ -5,7 +5,7 @@ controllers within the Exynos5250 SoC.
Required Properties:
- comptible: should be one of the following.
- compatible: should be one of the following.
- "samsung,exynos5250-clock" - controller compatible with Exynos5250 SoC.
- reg: physical base address of the controller and length of memory mapped
@@ -59,6 +59,9 @@ clock which they consume.
sclk_spi0 154
sclk_spi1 155
sclk_spi2 156
div_i2s1 157
div_i2s2 158
sclk_hdmiphy 159
[Peripheral Clock Gates]
@@ -154,7 +157,16 @@ clock which they consume.
dsim0 341
dp 342
mixer 343
hdmi 345
hdmi 344
g2d 345
[Clock Muxes]
Clock ID
----------------------------
mout_hdmi 1024
Example 1: An example of a clock controller node is listed below.

14
Documentation/devicetree/bindings/clock/exynos5420-clock.txt
View File

@@ -5,7 +5,7 @@ controllers within the Exynos5420 SoC.
Required Properties:
- comptible: should be one of the following.
- compatible: should be one of the following.
- "samsung,exynos5420-clock" - controller compatible with Exynos5420 SoC.
- reg: physical base address of the controller and length of memory mapped
@@ -59,6 +59,7 @@ clock which they consume.
sclk_pwm 155
sclk_gscl_wa 156
sclk_gscl_wb 157
sclk_hdmiphy 158
[Peripheral Clock Gates]
@@ -179,6 +180,17 @@ clock which they consume.
fimc_lite3 495
aclk_g3d 500
g3d 501
smmu_mixer 502
Mux ID
----------------------------
mout_hdmi 640
Divider ID
----------------------------
dout_pixel 768
Example 1: An example of a clock controller node is listed below.

2
Documentation/devicetree/bindings/clock/exynos5440-clock.txt
View File

@@ -5,7 +5,7 @@ controllers within the Exynos5440 SoC.
Required Properties:
- comptible: should be "samsung,exynos5440-clock".
- compatible: should be "samsung,exynos5440-clock".
- reg: physical base address of the controller and length of memory mapped
region.

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

@@ -197,6 +197,7 @@ clocks and IDs.
spdif0_gate 183
spdif1_gate 184
spdif_ipg_gate 185
ocram 186
Examples (for mx53):

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

@@ -209,6 +209,17 @@ clocks and IDs.
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
Examples:

29
Documentation/devicetree/bindings/clock/keystone-gate.txt Normal file
View File

@@ -0,0 +1,29 @@
Status: Unstable - ABI compatibility may be broken in the future
Binding for Keystone gate control driver which uses PSC controller IP.
This binding uses the common clock binding[1].
[1] Documentation/devicetree/bindings/clock/clock-bindings.txt
Required properties:
- compatible : shall be "ti,keystone,psc-clock".
- #clock-cells : from common clock binding; shall be set to 0.
- clocks : parent clock phandle
- reg : psc control and domain address address space
- reg-names : psc control and domain registers
- domain-id : psc domain id needed to check the transition state register
Optional properties:
- clock-output-names : From common clock binding to override the
default output clock name
Example:
clkusb: clkusb {
#clock-cells = <0>;
compatible = "ti,keystone,psc-clock";
clocks = <&chipclk16>;
clock-output-names = "usb";
reg = <0x02350008 0xb00>, <0x02350000 0x400>;
reg-names = "control", "domain";
domain-id = <0>;
};

84
Documentation/devicetree/bindings/clock/keystone-pll.txt Normal file
View File

@@ -0,0 +1,84 @@
Status: Unstable - ABI compatibility may be broken in the future
Binding for keystone PLLs. The main PLL IP typically has a multiplier,
a divider and a post divider. The additional PLL IPs like ARMPLL, DDRPLL
and PAPLL are controlled by the memory mapped register where as the Main
PLL is controlled by a PLL controller registers along with memory mapped
registers.
This binding uses the common clock binding[1].
[1] Documentation/devicetree/bindings/clock/clock-bindings.txt
Required properties:
- #clock-cells : from common clock binding; shall be set to 0.
- compatible : shall be "ti,keystone,main-pll-clock" or "ti,keystone,pll-clock"
- clocks : parent clock phandle
- reg - pll control0 and pll multipler registers
- reg-names : control and multiplier. The multiplier is applicable only for
main pll clock
- fixed-postdiv : fixed post divider value
Example:
mainpllclk: mainpllclk@2310110 {
#clock-cells = <0>;
compatible = "ti,keystone,main-pll-clock";
clocks = <&refclkmain>;
reg = <0x02620350 4>, <0x02310110 4>;
reg-names = "control", "multiplier";
fixed-postdiv = <2>;
};
papllclk: papllclk@2620358 {
#clock-cells = <0>;
compatible = "ti,keystone,pll-clock";
clocks = <&refclkmain>;
clock-output-names = "pa-pll-clk";
reg = <0x02620358 4>;
reg-names = "control";
fixed-postdiv = <6>;
};
Required properties:
- #clock-cells : from common clock binding; shall be set to 0.
- compatible : shall be "ti,keystone,pll-mux-clock"
- clocks : link phandles of parent clocks
- reg - pll mux register
- bit-shift : number of bits to shift the bit-mask
- bit-mask : arbitrary bitmask for programming the mux
Optional properties:
- clock-output-names : From common clock binding.
Example:
mainmuxclk: mainmuxclk@2310108 {
#clock-cells = <0>;
compatible = "ti,keystone,pll-mux-clock";
clocks = <&mainpllclk>, <&refclkmain>;
reg = <0x02310108 4>;
bit-shift = <23>;
bit-mask = <1>;
clock-output-names = "mainmuxclk";
};
Required properties:
- #clock-cells : from common clock binding; shall be set to 0.
- compatible : shall be "ti,keystone,pll-divider-clock"
- clocks : parent clock phandle
- reg - pll mux register
- bit-shift : number of bits to shift the bit-mask
- bit-mask : arbitrary bitmask for programming the divider
Optional properties:
- clock-output-names : From common clock binding.
Example:
gemtraceclk: gemtraceclk@2310120 {
#clock-cells = <0>;
compatible = "ti,keystone,pll-divider-clock";
clocks = <&mainmuxclk>;
reg = <0x02310120 4>;
bit-shift = <0>;
bit-mask = <8>;
clock-output-names = "gemtraceclk";
};

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

@@ -0,0 +1,19 @@
* Core Divider Clock bindings for Marvell MVEBU SoCs
The following is a list of provided IDs and clock names on Armada 370/XP:
0 = nand (NAND clock)
Required properties:
- compatible : must be "marvell,armada-370-corediv-clock"
- reg : must be the register address of Core Divider control register
- #clock-cells : from common clock binding; shall be set to 1
- clocks : must be set to the parent's phandle
Example:
corediv_clk: corediv-clocks@18740 {
compatible = "marvell,armada-370-corediv-clock";
reg = <0x18740 0xc>;
#clock-cells = <1>;
clocks = <&pll>;
};

14
Documentation/devicetree/bindings/clock/mvebu-gated-clock.txt
View File

@@ -1,10 +1,10 @@
* Gated Clock bindings for Marvell Orion SoCs
* Gated Clock bindings for Marvell EBU SoCs
Marvell Dove and Kirkwood allow some peripheral clocks to be gated to save
some power. The clock consumer should specify the desired clock by having
the clock ID in its "clocks" phandle cell. The clock ID is directly mapped to
the corresponding clock gating control bit in HW to ease manual clock lookup
in datasheet.
Marvell Armada 370/XP, Dove and Kirkwood allow some peripheral clocks to be
gated to save some power. The clock consumer should specify the desired clock
by having the clock ID in its "clocks" phandle cell. The clock ID is directly
mapped to the corresponding clock gating control bit in HW to ease manual clock
lookup in datasheet.
The following is a list of provided IDs for Armada 370:
ID Clock Peripheral
@@ -94,6 +94,8 @@ ID Clock Peripheral
Required properties:
- compatible : shall be one of the following:
"marvell,armada-370-gating-clock" - for Armada 370 SoC clock gating
"marvell,armada-xp-gating-clock" - for Armada XP SoC clock gating
"marvell,dove-gating-clock" - for Dove SoC clock gating
"marvell,kirkwood-gating-clock" - for Kirkwood SoC clock gating
- reg : shall be the register address of the Clock Gating Control register

77
Documentation/devicetree/bindings/clock/samsung,s3c64xx-clock.txt Normal file
View File

@@ -0,0 +1,77 @@
* Samsung S3C64xx Clock Controller
The S3C64xx clock controller generates and supplies clock to various controllers
within the SoC. The clock binding described here is applicable to all SoCs in
the S3C64xx family.
Required Properties:
- compatible: should be one of the following.
- "samsung,s3c6400-clock" - controller compatible with S3C6400 SoC.
- "samsung,s3c6410-clock" - controller compatible with S3C6410 SoC.
- reg: physical base address of the controller and length of memory mapped
region.
- #clock-cells: should be 1.
Each clock is assigned an identifier and client nodes can use this identifier
to specify the clock which they consume. Some of the clocks are available only
on a particular S3C64xx SoC and this is specified where applicable.
All available clocks are defined as preprocessor macros in
dt-bindings/clock/samsung,s3c64xx-clock.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:
- "fin_pll" - PLL input clock (xtal/extclk) - required,
- "xusbxti" - USB xtal - required,
- "iiscdclk0" - I2S0 codec clock - optional,
- "iiscdclk1" - I2S1 codec clock - optional,
- "iiscdclk2" - I2S2 codec clock - optional,
- "pcmcdclk0" - PCM0 codec clock - optional,
- "pcmcdclk1" - PCM1 codec clock - optional, only S3C6410.
Example: Clock controller node:
clock: clock-controller@7e00f000 {
compatible = "samsung,s3c6410-clock";
reg = <0x7e00f000 0x1000>;
#clock-cells = <1>;
};
Example: Required external clocks:
fin_pll: clock-fin-pll {
compatible = "fixed-clock";
clock-output-names = "fin_pll";
clock-frequency = <12000000>;
#clock-cells = <0>;
};
xusbxti: clock-xusbxti {
compatible = "fixed-clock";
clock-output-names = "xusbxti";
clock-frequency = <48000000>;
#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@7f005000 {
compatible = "samsung,s3c6400-uart";
reg = <0x7f005000 0x100>;
interrupt-parent = <&vic1>;
interrupts = <5>;
clock-names = "uart", "clk_uart_baud2",
"clk_uart_baud3";
clocks = <&clock PCLK_UART0>, <&clocks PCLK_UART0>,
<&clock SCLK_UART>;
status = "disabled";
};

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

@@ -8,19 +8,31 @@ Required properties:
- compatible : shall be one of the following:
"allwinner,sun4i-osc-clk" - for a gatable oscillator
"allwinner,sun4i-pll1-clk" - for the main PLL clock
"allwinner,sun6i-a31-pll1-clk" - for the main PLL clock on A31
"allwinner,sun4i-cpu-clk" - for the CPU multiplexer clock
"allwinner,sun4i-axi-clk" - for the AXI clock
"allwinner,sun4i-axi-gates-clk" - for the AXI gates
"allwinner,sun4i-ahb-clk" - for the AHB clock
"allwinner,sun4i-ahb-gates-clk" - for the AHB gates on A10
"allwinner,sun5i-a13-ahb-gates-clk" - for the AHB gates on A13
"allwinner,sun5i-a10s-ahb-gates-clk" - for the AHB gates on A10s
"allwinner,sun7i-a20-ahb-gates-clk" - for the AHB gates on A20
"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,sun4i-apb0-clk" - for the APB0 clock
"allwinner,sun4i-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,sun7i-a20-apb0-gates-clk" - for the APB0 gates on A20
"allwinner,sun4i-apb1-clk" - for the APB1 clock
"allwinner,sun4i-apb1-mux-clk" - for the APB1 clock muxing
"allwinner,sun4i-apb1-gates-clk" - for the APB1 gates on A10
"allwinner,sun5i-a13-apb1-gates-clk" - for the APB1 gates on A13
"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,sun6i-a31-apb2-div-clk" - for the APB2 gates on A31
"allwinner,sun6i-a31-apb2-gates-clk" - for the APB2 gates on A31
Required properties for all clocks:
- reg : shall be the control register address for the clock.
@@ -33,8 +45,8 @@ Additionally, "allwinner,*-gates-clk" clocks require:
Clock consumers should specify the desired clocks they use with a
"clocks" phandle cell. Consumers that are using a gated clock should
provide an additional ID in their clock property. The values of this
ID are documented in sunxi/<soc>-gates.txt.
provide an additional ID in their clock property. This ID is the
offset of the bit controlling this particular gate in the register.
For example:

93
Documentation/devicetree/bindings/clock/sunxi/sun4i-a10-gates.txt
View File

@@ -1,93 +0,0 @@
Gate clock outputs
------------------
* AXI gates ("allwinner,sun4i-axi-gates-clk")
DRAM 0
* AHB gates ("allwinner,sun4i-ahb-gates-clk")
USB0 0
EHCI0 1
OHCI0 2*
EHCI1 3
OHCI1 4*
SS 5
DMA 6
BIST 7
MMC0 8
MMC1 9
MMC2 10
MMC3 11
MS 12**
NAND 13
SDRAM 14
ACE 16
EMAC 17
TS 18
SPI0 20
SPI1 21
SPI2 22
SPI3 23
PATA 24
SATA 25**
GPS 26*
VE 32
TVD 33
TVE0 34
TVE1 35
LCD0 36
LCD1 37
CSI0 40
CSI1 41
HDMI 43
DE_BE0 44
DE_BE1 45
DE_FE1 46
DE_FE1 47
MP 50
MALI400 52
* APB0 gates ("allwinner,sun4i-apb0-gates-clk")
CODEC 0
SPDIF 1*
AC97 2
IIS 3
PIO 5
IR0 6
IR1 7
KEYPAD 10
* APB1 gates ("allwinner,sun4i-apb1-gates-clk")
I2C0 0
I2C1 1
I2C2 2
CAN 4
SCR 5
PS20 6
PS21 7
UART0 16
UART1 17
UART2 18
UART3 19
UART4 20
UART5 21
UART6 22
UART7 23
Notation:
[*]: The datasheet didn't mention these, but they are present on AW code
[**]: The datasheet had this marked as "NC" but they are used on AW code

58
Documentation/devicetree/bindings/clock/sunxi/sun5i-a13-gates.txt
View File

@@ -1,58 +0,0 @@
Gate clock outputs
------------------
* AXI gates ("allwinner,sun4i-axi-gates-clk")
DRAM 0
* AHB gates ("allwinner,sun5i-a13-ahb-gates-clk")
USBOTG 0
EHCI 1
OHCI 2
SS 5
DMA 6
BIST 7
MMC0 8
MMC1 9
MMC2 10
NAND 13
SDRAM 14
SPI0 20
SPI1 21
SPI2 22
STIMER 28
VE 32
LCD 36
CSI 40
DE_BE 44
DE_FE 46
IEP 51
MALI400 52
* APB0 gates ("allwinner,sun5i-a13-apb0-gates-clk")
CODEC 0
PIO 5
IR 6
* APB1 gates ("allwinner,sun5i-a13-apb1-gates-clk")
I2C0 0
I2C1 1
I2C2 2
UART1 17
UART3 19

111
Documentation/devicetree/bindings/clock/xgene.txt Normal file
View File

@@ -0,0 +1,111 @@
Device Tree Clock bindings for APM X-Gene
This binding uses the common clock binding[1].
[1] Documentation/devicetree/bindings/clock/clock-bindings.txt
Required properties:
- compatible : shall be one of the following:
"apm,xgene-socpll-clock" - for a X-Gene SoC PLL clock
"apm,xgene-pcppll-clock" - for a X-Gene PCP PLL clock
"apm,xgene-device-clock" - for a X-Gene device clock
Required properties for SoC or PCP PLL clocks:
- reg : shall be the physical PLL register address for the pll clock.
- clocks : shall be the input parent clock phandle for the clock. This should
be the reference clock.
- #clock-cells : shall be set to 1.
- clock-output-names : shall be the name of the PLL referenced by derive
clock.
Optional properties for PLL clocks:
- clock-names : shall be the name of the PLL. If missing, use the device name.
Required properties for device clocks:
- reg : shall be a list of address and length pairs describing the CSR
reset and/or the divider. Either may be omitted, but at least
one must be present.
- reg-names : shall be a string list describing the reg resource. This
may include "csr-reg" and/or "div-reg". If this property
is not present, the reg property is assumed to describe
only "csr-reg".
- clocks : shall be the input parent clock phandle for the clock.
- #clock-cells : shall be set to 1.
- clock-output-names : shall be the name of the device referenced.
Optional properties for device clocks:
- clock-names : shall be the name of the device clock. If missing, use the
device name.
- csr-offset : Offset to the CSR reset register from the reset address base.
Default is 0.
- csr-mask : CSR reset mask bit. Default is 0xF.
- enable-offset : Offset to the enable register from the reset address base.
Default is 0x8.
- enable-mask : CSR enable mask bit. Default is 0xF.
- divider-offset : Offset to the divider CSR register from the divider base.
Default is 0x0.
- divider-width : Width of the divider register. Default is 0.
- divider-shift : Bit shift of the divider register. Default is 0.
For example:
pcppll: pcppll@17000100 {
compatible = "apm,xgene-pcppll-clock";
#clock-cells = <1>;
clocks = <&refclk 0>;
clock-names = "pcppll";
reg = <0x0 0x17000100 0x0 0x1000>;
clock-output-names = "pcppll";
type = <0>;
};
socpll: socpll@17000120 {
compatible = "apm,xgene-socpll-clock";
#clock-cells = <1>;
clocks = <&refclk 0>;
clock-names = "socpll";
reg = <0x0 0x17000120 0x0 0x1000>;
clock-output-names = "socpll";
type = <1>;
};
qmlclk: qmlclk {
compatible = "apm,xgene-device-clock";
#clock-cells = <1>;
clocks = <&socplldiv2 0>;
clock-names = "qmlclk";
reg = <0x0 0x1703C000 0x0 0x1000>;
reg-name = "csr-reg";
clock-output-names = "qmlclk";
};
ethclk: ethclk {
compatible = "apm,xgene-device-clock";
#clock-cells = <1>;
clocks = <&socplldiv2 0>;
clock-names = "ethclk";
reg = <0x0 0x17000000 0x0 0x1000>;
reg-names = "div-reg";
divider-offset = <0x238>;
divider-width = <0x9>;
divider-shift = <0x0>;
clock-output-names = "ethclk";
};
apbclk: apbclk {
compatible = "apm,xgene-device-clock";
#clock-cells = <1>;
clocks = <&ahbclk 0>;
clock-names = "apbclk";
reg = <0x0 0x1F2AC000 0x0 0x1000
0x0 0x1F2AC000 0x0 0x1000>;
reg-names = "csr-reg", "div-reg";
csr-offset = <0x0>;
csr-mask = <0x200>;
enable-offset = <0x8>;
enable-mask = <0x200>;
divider-offset = <0x10>;
divider-width = <0x2>;
divider-shift = <0x0>;
flags = <0x8>;
clock-output-names = "apbclk";
};

157
Documentation/devicetree/bindings/crypto/fsl-sec6.txt Normal file
View File

@@ -0,0 +1,157 @@
SEC 6 is as Freescale's Cryptographic Accelerator and Assurance Module (CAAM).
Currently Freescale powerpc chip C29X is embeded with SEC 6.
SEC 6 device tree binding include:
-SEC 6 Node
-Job Ring Node
-Full Example
=====================================================================
SEC 6 Node
Description
Node defines the base address of the SEC 6 block.
This block specifies the address range of all global
configuration registers for the SEC 6 block.
For example, In C293, we could see three SEC 6 node.
PROPERTIES
- compatible
Usage: required
Value type: <string>
Definition: Must include "fsl,sec-v6.0".
- fsl,sec-era
Usage: optional
Value type: <u32>
Definition: A standard property. Define the 'ERA' of the SEC
device.
- #address-cells
Usage: required
Value type: <u32>
Definition: A standard property. Defines the number of cells
for representing physical addresses in child nodes.
- #size-cells
Usage: required
Value type: <u32>
Definition: A standard property. Defines the number of cells
for representing the size of physical addresses in
child nodes.
- reg
Usage: required
Value type: <prop-encoded-array>
Definition: A standard property. Specifies the physical
address and length of the SEC 6 configuration registers.
- ranges
Usage: required
Value type: <prop-encoded-array>
Definition: A standard property. Specifies the physical address
range of the SEC 6.0 register space (-SNVS not included). A
triplet that includes the child address, parent address, &
length.
Note: All other standard properties (see the ePAPR) are allowed
but are optional.
EXAMPLE
crypto@a0000 {
compatible = "fsl,sec-v6.0";
fsl,sec-era = <6>;
#address-cells = <1>;
#size-cells = <1>;
reg = <0xa0000 0x20000>;
ranges = <0 0xa0000 0x20000>;
};
=====================================================================
Job Ring (JR) Node
Child of the crypto node defines data processing interface to SEC 6
across the peripheral bus for purposes of processing
cryptographic descriptors. The specified address
range can be made visible to one (or more) cores.
The interrupt defined for this node is controlled within
the address range of this node.
- compatible
Usage: required
Value type: <string>
Definition: Must include "fsl,sec-v6.0-job-ring".
- reg
Usage: required
Value type: <prop-encoded-array>
Definition: Specifies a two JR parameters: an offset from
the parent physical address and the length the JR registers.
- interrupts
Usage: required
Value type: <prop_encoded-array>
Definition: Specifies the interrupts generated by this
device. The value of the interrupts property
consists of one interrupt specifier. The format
of the specifier is defined by the binding document
describing the node's interrupt parent.
EXAMPLE
jr@1000 {
compatible = "fsl,sec-v6.0-job-ring";
reg = <0x1000 0x1000>;
interrupts = <49 2 0 0>;
};
===================================================================
Full Example
Since some chips may contain more than one SEC, the dtsi contains
only the node contents, not the node itself. A chip using the SEC
should include the dtsi inside each SEC node. Example:
In qoriq-sec6.0.dtsi:
compatible = "fsl,sec-v6.0";
fsl,sec-era = <6>;
#address-cells = <1>;
#size-cells = <1>;
jr@1000 {
compatible = "fsl,sec-v6.0-job-ring",
"fsl,sec-v5.2-job-ring",
"fsl,sec-v5.0-job-ring",
"fsl,sec-v4.4-job-ring",
"fsl,sec-v4.0-job-ring";
reg = <0x1000 0x1000>;
};
jr@2000 {
compatible = "fsl,sec-v6.0-job-ring",
"fsl,sec-v5.2-job-ring",
"fsl,sec-v5.0-job-ring",
"fsl,sec-v4.4-job-ring",
"fsl,sec-v4.0-job-ring";
reg = <0x2000 0x1000>;
};
In the C293 device tree, we add the include of public property:
crypto@a0000 {
/include/ "qoriq-sec6.0.dtsi"
}
crypto@a0000 {
reg = <0xa0000 0x20000>;
ranges = <0 0xa0000 0x20000>;
jr@1000 {
interrupts = <49 2 0 0>;
};
jr@2000 {
interrupts = <50 2 0 0>;
};
};

31
Documentation/devicetree/bindings/crypto/omap-aes.txt Normal file
View File

@@ -0,0 +1,31 @@
OMAP SoC AES crypto Module
Required properties:
- compatible : Should contain entries for this and backward compatible
AES versions:
- "ti,omap2-aes" for OMAP2.
- "ti,omap3-aes" for OMAP3.
- "ti,omap4-aes" for OMAP4 and AM33XX.
Note that the OMAP2 and 3 versions are compatible (OMAP3 supports
more algorithms) but they are incompatible with OMAP4.
- ti,hwmods: Name of the hwmod associated with the AES module
- reg : Offset and length of the register set for the module
- interrupts : the interrupt-specifier for the AES module.
Optional properties:
- dmas: DMA specifiers for tx and rx dma. See the DMA client binding,
Documentation/devicetree/bindings/dma/dma.txt
- dma-names: DMA request names should include "tx" and "rx" if present.
Example:
/* AM335x */
aes: aes@53500000 {
compatible = "ti,omap4-aes";
ti,hwmods = "aes";
reg = <0x53500000 0xa0>;
interrupts = <102>;
dmas = <&edma 6>,
<&edma 5>;
dma-names = "tx", "rx";
};

30
Documentation/devicetree/bindings/crypto/omap-des.txt Normal file
View File

@@ -0,0 +1,30 @@
OMAP SoC DES crypto Module
Required properties:
- compatible : Should contain "ti,omap4-des"
- ti,hwmods: Name of the hwmod associated with the DES module
- reg : Offset and length of the register set for the module
- interrupts : the interrupt-specifier for the DES module
- clocks : A phandle to the functional clock node of the DES module
corresponding to each entry in clock-names
- clock-names : Name of the functional clock, should be "fck"
Optional properties:
- dmas: DMA specifiers for tx and rx dma. See the DMA client binding,
Documentation/devicetree/bindings/dma/dma.txt
Each entry corresponds to an entry in dma-names
- dma-names: DMA request names should include "tx" and "rx" if present
Example:
/* DRA7xx SoC */
des: des@480a5000 {
compatible = "ti,omap4-des";
ti,hwmods = "des";
reg = <0x480a5000 0xa0>;
interrupts = <GIC_SPI 82 IRQ_TYPE_LEVEL_HIGH>;
dmas = <&sdma 117>, <&sdma 116>;
dma-names = "tx", "rx";
clocks = <&l3_iclk_div>;
clock-names = "fck";
};

28
Documentation/devicetree/bindings/crypto/omap-sham.txt Normal file
View File

@@ -0,0 +1,28 @@
OMAP SoC SHA crypto Module
Required properties:
- compatible : Should contain entries for this and backward compatible
SHAM versions:
- "ti,omap2-sham" for OMAP2 & OMAP3.
- "ti,omap4-sham" for OMAP4 and AM33XX.
- "ti,omap5-sham" for OMAP5, DRA7 and AM43XX.
- ti,hwmods: Name of the hwmod associated with the SHAM module
- reg : Offset and length of the register set for the module
- interrupts : the interrupt-specifier for the SHAM module.
Optional properties:
- dmas: DMA specifiers for the rx dma. See the DMA client binding,
Documentation/devicetree/bindings/dma/dma.txt
- dma-names: DMA request name. Should be "rx" if a dma is present.
Example:
/* AM335x */
sham: sham@53100000 {
compatible = "ti,omap4-sham";
ti,hwmods = "sham";
reg = <0x53100000 0x200>;
interrupts = <109>;
dmas = <&edma 36>;
dma-names = "rx";
};

2
Documentation/devicetree/bindings/dma/atmel-dma.txt
View File

@@ -28,7 +28,7 @@ The three cells in order are:
dependent:
- bit 7-0: peripheral identifier for the hardware handshaking interface. The
identifier can be different for tx and rx.
- bit 11-8: FIFO configuration. 0 for half FIFO, 1 for ALAP, 1 for ASAP.
- bit 11-8: FIFO configuration. 0 for half FIFO, 1 for ALAP, 2 for ASAP.
Example:

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

@@ -1,7 +1,12 @@
* Freescale Smart Direct Memory Access (SDMA) Controller for i.MX
Required properties:
- compatible : Should be "fsl,<chip>-sdma"
- compatible : Should be "fsl,imx31-sdma", "fsl,imx31-to1-sdma",
"fsl,imx31-to2-sdma", "fsl,imx35-sdma", "fsl,imx35-to1-sdma",
"fsl,imx35-to2-sdma", "fsl,imx51-sdma", "fsl,imx53-sdma" or
"fsl,imx6q-sdma". The -to variants should be preferred since they
allow to determnine the correct ROM script addresses needed for
the driver to work without additional firmware.
- reg : Should contain SDMA registers location and length
- interrupts : Should contain SDMA interrupt
- #dma-cells : Must be <3>.

46
Documentation/devicetree/bindings/dma/k3dma.txt Normal file
View File

@@ -0,0 +1,46 @@
* Hisilicon K3 DMA controller
See dma.txt first
Required properties:
- compatible: Should be "hisilicon,k3-dma-1.0"
- reg: Should contain DMA registers location and length.
- interrupts: Should contain one interrupt shared by all channel
- #dma-cells: see dma.txt, should be 1, para number
- dma-channels: physical channels supported
- dma-requests: virtual channels supported, each virtual channel
have specific request line
- clocks: clock required
Example:
Controller:
dma0: dma@fcd02000 {
compatible = "hisilicon,k3-dma-1.0";
reg = <0xfcd02000 0x1000>;
#dma-cells = <1>;
dma-channels = <16>;
dma-requests = <27>;
interrupts = <0 12 4>;
clocks = <&pclk>;
status = "disable";
};
Client:
Use specific request line passing from dmax
For example, i2c0 read channel request line is 18, while write channel use 19
i2c0: i2c@fcb08000 {
compatible = "snps,designware-i2c";
dmas = <&dma0 18 /* read channel */
&dma0 19>; /* write channel */
dma-names = "rx", "tx";
};
i2c1: i2c@fcb09000 {
compatible = "snps,designware-i2c";
dmas = <&dma0 20 /* read channel */
&dma0 21>; /* write channel */
dma-names = "rx", "tx";
};

61
Documentation/devicetree/bindings/dma/shdma.txt
View File

@@ -22,42 +22,51 @@ Optional properties (currently unused):
* DMA controller
Required properties:
- compatible: should be "renesas,shdma"
- compatible: should be of the form "renesas,shdma-<soc>", where <soc> should
be replaced with the desired SoC model, e.g.
"renesas,shdma-r8a73a4" for the system DMAC on r8a73a4 SoC
Example:
dmac: dma-mux0 {
dmac: dma-multiplexer@0 {
compatible = "renesas,shdma-mux";
#dma-cells = <1>;
dma-channels = <6>;
dma-channels = <20>;
dma-requests = <256>;
reg = <0 0>; /* Needed for AUXDATA */
#address-cells = <1>;
#size-cells = <1>;
#address-cells = <2>;
#size-cells = <2>;
ranges;
dma0: shdma@fe008020 {
compatible = "renesas,shdma";
reg = <0xfe008020 0x270>,
<0xfe009000 0xc>;
dma0: dma-controller@e6700020 {
compatible = "renesas,shdma-r8a73a4";
reg = <0 0xe6700020 0 0x89e0>;
interrupt-parent = <&gic>;
interrupts = <0 34 4
0 28 4
0 29 4
0 30 4
0 31 4
0 32 4
0 33 4>;
interrupts = <0 220 4
0 200 4
0 201 4
0 202 4
0 203 4
0 204 4
0 205 4
0 206 4
0 207 4
0 208 4
0 209 4
0 210 4
0 211 4
0 212 4
0 213 4
0 214 4
0 215 4
0 216 4
0 217 4
0 218 4
0 219 4>;
interrupt-names = "error",
"ch0", "ch1", "ch2", "ch3",
"ch4", "ch5";
};
dma1: shdma@fe018020 {
...
};
dma2: shdma@fe028020 {
...
"ch4", "ch5", "ch6", "ch7",
"ch8", "ch9", "ch10", "ch11",
"ch12", "ch13", "ch14", "ch15",
"ch16", "ch17", "ch18", "ch19";
};
};

64
Documentation/devicetree/bindings/gpio/8xxx_gpio.txt
View File

@@ -5,16 +5,42 @@ This is for the non-QE/CPM/GUTs GPIO controllers as found on
Every GPIO controller node must have #gpio-cells property defined,
this information will be used to translate gpio-specifiers.
See bindings/gpio/gpio.txt for details of how to specify GPIO
information for devices.
The GPIO module usually is connected to the SoC's internal interrupt
controller, see bindings/interrupt-controller/interrupts.txt (the
interrupt client nodes section) for details how to specify this GPIO
module's interrupt.
The GPIO module may serve as another interrupt controller (cascaded to
the SoC's internal interrupt controller). See the interrupt controller
nodes section in bindings/interrupt-controller/interrupts.txt for
details.
Required properties:
- compatible : "fsl,<CHIP>-gpio" followed by "fsl,mpc8349-gpio" for
83xx, "fsl,mpc8572-gpio" for 85xx and "fsl,mpc8610-gpio" for 86xx.
- #gpio-cells : Should be two. The first cell is the pin number and the
second cell is used to specify optional parameters (currently unused).
- interrupts : Interrupt mapping for GPIO IRQ.
- interrupt-parent : Phandle for the interrupt controller that
- compatible: "fsl,<chip>-gpio" followed by "fsl,mpc8349-gpio"
for 83xx, "fsl,mpc8572-gpio" for 85xx, or
"fsl,mpc8610-gpio" for 86xx.
- #gpio-cells: Should be two. The first cell is the pin number
and the second cell is used to specify optional
parameters (currently unused).
- interrupt-parent: Phandle for the interrupt controller that
services interrupts for this device.
- gpio-controller : Marks the port as GPIO controller.
- interrupts: Interrupt mapping for GPIO IRQ.
- gpio-controller: Marks the port as GPIO controller.
Optional properties:
- interrupt-controller: Empty boolean property which marks the GPIO
module as an IRQ controller.
- #interrupt-cells: Should be two. Defines the number of integer
cells required to specify an interrupt within
this interrupt controller. The first cell
defines the pin number, the second cell
defines additional flags (trigger type,
trigger polarity). Note that the available
set of trigger conditions supported by the
GPIO module depends on the actual SoC.
Example of gpio-controller nodes for a MPC8347 SoC:
@@ -22,39 +48,27 @@ Example of gpio-controller nodes for a MPC8347 SoC:
#gpio-cells = <2>;
compatible = "fsl,mpc8347-gpio", "fsl,mpc8349-gpio";
reg = <0xc00 0x100>;
interrupts = <74 0x8>;
interrupt-parent = <&ipic>;
interrupts = <74 0x8>;
gpio-controller;
interrupt-controller;
#interrupt-cells = <2>;
};
gpio2: gpio-controller@d00 {
#gpio-cells = <2>;
compatible = "fsl,mpc8347-gpio", "fsl,mpc8349-gpio";
reg = <0xd00 0x100>;
interrupts = <75 0x8>;
interrupt-parent = <&ipic>;
interrupts = <75 0x8>;
gpio-controller;
};
See booting-without-of.txt for details of how to specify GPIO
information for devices.
To use GPIO pins as interrupt sources for peripherals, specify the
GPIO controller as the interrupt parent and define GPIO number +
trigger mode using the interrupts property, which is defined like
this:
interrupts = <number trigger>, where:
- number: GPIO pin (0..31)
- trigger: trigger mode:
2 = trigger on falling edge
3 = trigger on both edges
Example of device using this is:
Example of a peripheral using the GPIO module as an IRQ controller:
funkyfpga@0 {
compatible = "funky-fpga";
...
interrupts = <4 3>;
interrupt-parent = <&gpio1>;
interrupts = <4 3>;
};

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