OpenE2K
/
linux
6
0
Fork 0
Code Issues Pull Requests Releases Wiki Activity

Linux 3.16-rc5 

-----BEGIN PGP SIGNATURE-----
 Version: GnuPG v1
 
 iQEcBAABAgAGBQJTwvRvAAoJEHm+PkMAQRiG8CoIAJucWkj+MJFFoDXjR9hfI8U7
 /WeQLJP0GpWGMXd2KznX9epCuw5rsuaPAxCy1HFDNOa7OtNYacWrsIhByxOIDLwL
 YjDB9+fpMMPFWsr+LPJa8Ombh/TveCS77w6Pt5VMZFwvIKujiNK/C3MdxjReH5Gr
 iTGm8x7nEs2D6L2+5sQVlhXot/97phxIlBSP6wPXEiaztNZ9/JZi905Xpgq+WU16
 ZOA8MlJj1TQD4xcWyUcsQ5REwIOdQ6xxPF00wv/12RFela+Puy4JLAilnV6Mc12U
 fwYOZKbUNBS8rjfDDdyX3sljV1L5iFFqKkW3WFdnv/z8ZaZSo5NupWuavDnifKw=
 =6Q8o
 -----END PGP SIGNATURE-----

Merge tag 'v3.16-rc5' into timers/core

Reason: Bring in upstream modifications, so the pending changes which
depend on them can be queued.
This commit is contained in:
Thomas Gleixner 2014-07-16 21:57:38 +02:00
parent be11e6d860 1795cd9b3a
commit afdb094380
4678 changed files with 184249 additions and 90401 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

4
.gitignore vendored
View File

@ -22,7 +22,6 @@
*.lst
*.symtypes
*.order
modules.builtin
*.elf
*.bin
*.gz
@ -33,6 +32,8 @@ modules.builtin
*.lzo
*.patch
*.gcno
modules.builtin
Module.symvers
#
# Top-level generic files
@ -44,7 +45,6 @@ modules.builtin
/vmlinuz
/System.map
/Module.markers
/Module.symvers
#
# Debian directory (make deb-pkg)

4
CREDITS
View File

@ -9,6 +9,10 @@
Linus
----------
M: Matt Mackal
E: mpm@selenic.com
D: SLOB slab allocator
N: Matti Aarnio
E: mea@nic.funet.fi
D: Alpha systems hacking, IPv6 and other network related stuff

25
Documentation/ABI/stable/sysfs-devices-system-cpu Normal file
View File

@ -0,0 +1,25 @@
What: /sys/devices/system/cpu/dscr_default
Date: 13-May-2014
KernelVersion: v3.15.0
Contact:
Description: Writes are equivalent to writing to
/sys/devices/system/cpu/cpuN/dscr on all CPUs.
Reads return the last written value or 0.
This value is not a global default: it is a way to set
all per-CPU defaults at the same time.
Values: 64 bit unsigned integer (bit field)
What: /sys/devices/system/cpu/cpu[0-9]+/dscr
Date: 13-May-2014
KernelVersion: v3.15.0
Contact:
Description: Default value for the Data Stream Control Register (DSCR) on
a CPU.
This default value is used when the kernel is executing and
for any process that has not set the DSCR itself.
If a process ever sets the DSCR (via direct access to the
SPR) that value will be persisted for that process and used
on any CPU where it executes (overriding the value described
here).
If set by a process it will be inherited by child processes.
Values: 64 bit unsigned integer (bit field)

2
Documentation/ABI/testing/ima_policy
View File

@ -23,7 +23,7 @@ Description:
[fowner]]
lsm: [[subj_user=] [subj_role=] [subj_type=]
[obj_user=] [obj_role=] [obj_type=]]
option: [[appraise_type=]]
option: [[appraise_type=]] [permit_directio]
base: func:= [BPRM_CHECK][MMAP_CHECK][FILE_CHECK][MODULE_CHECK]
mask:= [MAY_READ] [MAY_WRITE] [MAY_APPEND] [MAY_EXEC]

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

@ -169,6 +169,14 @@ Description:
"unknown", "notpresent", "down", "lowerlayerdown", "testing",
"dormant", "up".
What: /sys/class/net/<iface>/phys_port_id
Date: July 2013
KernelVersion: 3.12
Contact: netdev@vger.kernel.org
Description:
Indicates the interface unique physical port identifier within
the NIC, as a string.
What: /sys/class/net/<iface>/speed
Date: October 2009
KernelVersion: 2.6.33

149
Documentation/ABI/testing/sysfs-class-net-cdc_ncm Normal file
View File

@ -0,0 +1,149 @@
What: /sys/class/net/<iface>/cdc_ncm/min_tx_pkt
Date: May 2014
KernelVersion: 3.16
Contact: Bjørn Mork <bjorn@mork.no>
Description:
The driver will pad NCM Transfer Blocks (NTBs) longer
than this to tx_max, allowing the device to receive
tx_max sized frames with no terminating short
packet. NTBs shorter than this limit are transmitted
as-is, without any padding, and are terminated with a
short USB packet.
Padding to tx_max allows the driver to transmit NTBs
back-to-back without any interleaving short USB
packets. This reduces the number of short packet
interrupts in the device, and represents a tradeoff
between USB bus bandwidth and device DMA optimization.
Set to 0 to pad all frames. Set greater than tx_max to
disable all padding.
What: /sys/class/net/<iface>/cdc_ncm/rx_max
Date: May 2014
KernelVersion: 3.16
Contact: Bjørn Mork <bjorn@mork.no>
Description:
The maximum NTB size for RX. Cannot exceed the
maximum value supported by the device. Must allow at
least one max sized datagram plus headers.
The actual limits are device dependent. See
dwNtbInMaxSize.
Note: Some devices will silently ignore changes to
this value, resulting in oversized NTBs and
corresponding framing errors.
What: /sys/class/net/<iface>/cdc_ncm/tx_max
Date: May 2014
KernelVersion: 3.16
Contact: Bjørn Mork <bjorn@mork.no>
Description:
The maximum NTB size for TX. Cannot exceed the
maximum value supported by the device. Must allow at
least one max sized datagram plus headers.
The actual limits are device dependent. See
dwNtbOutMaxSize.
What: /sys/class/net/<iface>/cdc_ncm/tx_timer_usecs
Date: May 2014
KernelVersion: 3.16
Contact: Bjørn Mork <bjorn@mork.no>
Description:
Datagram aggregation timeout in µs. The driver will
wait up to 3 times this timeout for more datagrams to
aggregate before transmitting an NTB frame.
Valid range: 5 to 4000000
Set to 0 to disable aggregation.
The following read-only attributes all represent fields of the
structure defined in section 6.2.1 "GetNtbParameters" of "Universal
Serial Bus Communications Class Subclass Specifications for Network
Control Model Devices" (CDC NCM), Revision 1.0 (Errata 1), November
24, 2010 from USB Implementers Forum, Inc. The descriptions are
quoted from table 6-3 of CDC NCM: "NTB Parameter Structure".
What: /sys/class/net/<iface>/cdc_ncm/bmNtbFormatsSupported
Date: May 2014
KernelVersion: 3.16
Contact: Bjørn Mork <bjorn@mork.no>
Description:
Bit 0: 16-bit NTB supported (set to 1)
Bit 1: 32-bit NTB supported
Bits 2 – 15: reserved (reset to zero; must be ignored by host)
What: /sys/class/net/<iface>/cdc_ncm/dwNtbInMaxSize
Date: May 2014
KernelVersion: 3.16
Contact: Bjørn Mork <bjorn@mork.no>
Description:
IN NTB Maximum Size in bytes
What: /sys/class/net/<iface>/cdc_ncm/wNdpInDivisor
Date: May 2014
KernelVersion: 3.16
Contact: Bjørn Mork <bjorn@mork.no>
Description:
Divisor used for IN NTB Datagram payload alignment
What: /sys/class/net/<iface>/cdc_ncm/wNdpInPayloadRemainder
Date: May 2014
KernelVersion: 3.16
Contact: Bjørn Mork <bjorn@mork.no>
Description:
Remainder used to align input datagram payload within
the NTB: (Payload Offset) mod (wNdpInDivisor) =
wNdpInPayloadRemainder
What: /sys/class/net/<iface>/cdc_ncm/wNdpInAlignment
Date: May 2014
KernelVersion: 3.16
Contact: Bjørn Mork <bjorn@mork.no>
Description:
NDP alignment modulus for NTBs on the IN pipe. Shall
be a power of 2, and shall be at least 4.
What: /sys/class/net/<iface>/cdc_ncm/dwNtbOutMaxSize
Date: May 2014
KernelVersion: 3.16
Contact: Bjørn Mork <bjorn@mork.no>
Description:
OUT NTB Maximum Size
What: /sys/class/net/<iface>/cdc_ncm/wNdpOutDivisor
Date: May 2014
KernelVersion: 3.16
Contact: Bjørn Mork <bjorn@mork.no>
Description:
OUT NTB Datagram alignment modulus
What: /sys/class/net/<iface>/cdc_ncm/wNdpOutPayloadRemainder
Date: May 2014
KernelVersion: 3.16
Contact: Bjørn Mork <bjorn@mork.no>
Description:
Remainder used to align output datagram payload
offsets within the NTB: Padding, shall be transmitted
as zero by function, and ignored by host. (Payload
Offset) mod (wNdpOutDivisor) = wNdpOutPayloadRemainder
What: /sys/class/net/<iface>/cdc_ncm/wNdpOutAlignment
Date: May 2014
KernelVersion: 3.16
Contact: Bjørn Mork <bjorn@mork.no>
Description:
NDP alignment modulus for use in NTBs on the OUT
pipe. Shall be a power of 2, and shall be at least 4.
What: /sys/class/net/<iface>/cdc_ncm/wNtbOutMaxDatagrams
Date: May 2014
KernelVersion: 3.16
Contact: Bjørn Mork <bjorn@mork.no>
Description:
Maximum number of datagrams that the host may pack
into a single OUT NTB. Zero means that the device
imposes no limit.

79
Documentation/ABI/testing/sysfs-class-net-queues Normal file
View File

@ -0,0 +1,79 @@
What: /sys/class/<iface>/queues/rx-<queue>/rps_cpus
Date: March 2010
KernelVersion: 2.6.35
Contact: netdev@vger.kernel.org
Description:
Mask of the CPU(s) currently enabled to participate into the
Receive Packet Steering packet processing flow for this
network device queue. Possible values depend on the number
of available CPU(s) in the system.
What: /sys/class/<iface>/queues/rx-<queue>/rps_flow_cnt
Date: April 2010
KernelVersion: 2.6.35
Contact: netdev@vger.kernel.org
Description:
Number of Receive Packet Steering flows being currently
processed by this particular network device receive queue.
What: /sys/class/<iface>/queues/tx-<queue>/tx_timeout
Date: November 2011
KernelVersion: 3.3
Contact: netdev@vger.kernel.org
Description:
Indicates the number of transmit timeout events seen by this
network interface transmit queue.
What: /sys/class/<iface>/queues/tx-<queue>/xps_cpus
Date: November 2010
KernelVersion: 2.6.38
Contact: netdev@vger.kernel.org
Description:
Mask of the CPU(s) currently enabled to participate into the
Transmit Packet Steering packet processing flow for this
network device transmit queue. Possible vaules depend on the
number of available CPU(s) in the system.
What: /sys/class/<iface>/queues/tx-<queue>/byte_queue_limits/hold_time
Date: November 2011
KernelVersion: 3.3
Contact: netdev@vger.kernel.org
Description:
Indicates the hold time in milliseconds to measure the slack
of this particular network device transmit queue.
Default value is 1000.
What: /sys/class/<iface>/queues/tx-<queue>/byte_queue_limits/inflight
Date: November 2011
KernelVersion: 3.3
Contact: netdev@vger.kernel.org
Description:
Indicates the number of bytes (objects) in flight on this
network device transmit queue.
What: /sys/class/<iface>/queues/tx-<queue>/byte_queue_limits/limit
Date: November 2011
KernelVersion: 3.3
Contact: netdev@vger.kernel.org
Description:
Indicates the current limit of bytes allowed to be queued
on this network device transmit queue. This value is clamped
to be within the bounds defined by limit_max and limit_min.
What: /sys/class/<iface>/queues/tx-<queue>/byte_queue_limits/limit_max
Date: November 2011
KernelVersion: 3.3
Contact: netdev@vger.kernel.org
Description:
Indicates the absolute maximum limit of bytes allowed to be
queued on this network device transmit queue. See
include/linux/dynamic_queue_limits.h for the default value.
What: /sys/class/<iface>/queues/tx-<queue>/byte_queue_limits/limit_min
Date: November 2011
KernelVersion: 3.3
Contact: netdev@vger.kernel.org
Description:
Indicates the absolute minimum limit of bytes allowed to be
queued on this network device transmit queue. Default value is
0.

201
Documentation/ABI/testing/sysfs-class-net-statistics Normal file
View File

@ -0,0 +1,201 @@
What: /sys/class/<iface>/statistics/collisions
Date: April 2005
KernelVersion: 2.6.12
Contact: netdev@vger.kernel.org
Description:
Indicates the number of collisions seen by this network device.
This value might not be relevant with all MAC layers.
What: /sys/class/<iface>/statistics/multicast
Date: April 2005
KernelVersion: 2.6.12
Contact: netdev@vger.kernel.org
Description:
Indicates the number of multicast packets received by this
network device.
What: /sys/class/<iface>/statistics/rx_bytes
Date: April 2005
KernelVersion: 2.6.12
Contact: netdev@vger.kernel.org
Description:
Indicates the number of bytes received by this network device.
See the network driver for the exact meaning of when this
value is incremented.
What: /sys/class/<iface>/statistics/rx_compressed
Date: April 2005
KernelVersion: 2.6.12
Contact: netdev@vger.kernel.org
Description:
Indicates the number of compressed packets received by this
network device. This value might only be relevant for interfaces
that support packet compression (e.g: PPP).
What: /sys/class/<iface>/statistics/rx_crc_errors
Date: April 2005
KernelVersion: 2.6.12
Contact: netdev@vger.kernel.org
Description:
Indicates the number of packets received with a CRC (FCS) error
by this network device. Note that the specific meaning might
depend on the MAC layer used by the interface.
What: /sys/class/<iface>/statistics/rx_dropped
Date: April 2005
KernelVersion: 2.6.12
Contact: netdev@vger.kernel.org
Description:
Indicates the number of packets received by the network device
but dropped, that are not forwarded to the upper layers for
packet processing. See the network driver for the exact
meaning of this value.
What: /sys/class/<iface>/statistics/rx_fifo_errors
Date: April 2005
KernelVersion: 2.6.12
Contact: netdev@vger.kernel.org
Description:
Indicates the number of receive FIFO errors seen by this
network device. See the network driver for the exact
meaning of this value.
What: /sys/class/<iface>/statistics/rx_frame_errors
Date: April 2005
KernelVersion: 2.6.12
Contact: netdev@vger.kernel.org
Description:
Indicates the number of received frames with error, such as
alignment errors. Note that the specific meaning depends on
on the MAC layer protocol used. See the network driver for
the exact meaning of this value.
What: /sys/class/<iface>/statistics/rx_length_errors
Date: April 2005
KernelVersion: 2.6.12
Contact: netdev@vger.kernel.org
Description:
Indicates the number of received error packet with a length
error, oversized or undersized. See the network driver for the
exact meaning of this value.
What: /sys/class/<iface>/statistics/rx_missed_errors
Date: April 2005
KernelVersion: 2.6.12
Contact: netdev@vger.kernel.org
Description:
Indicates the number of received packets that have been missed
due to lack of capacity in the receive side. See the network
driver for the exact meaning of this value.
What: /sys/class/<iface>/statistics/rx_over_errors
Date: April 2005
KernelVersion: 2.6.12
Contact: netdev@vger.kernel.org
Description:
Indicates the number of received packets that are oversized
compared to what the network device is configured to accept
(e.g: larger than MTU). See the network driver for the exact
meaning of this value.
What: /sys/class/<iface>/statistics/rx_packets
Date: April 2005
KernelVersion: 2.6.12
Contact: netdev@vger.kernel.org
Description:
Indicates the total number of good packets received by this
network device.
What: /sys/class/<iface>/statistics/tx_aborted_errors
Date: April 2005
KernelVersion: 2.6.12
Contact: netdev@vger.kernel.org
Description:
Indicates the number of packets that have been aborted
during transmission by a network device (e.g: because of
a medium collision). See the network driver for the exact
meaning of this value.
What: /sys/class/<iface>/statistics/tx_bytes
Date: April 2005
KernelVersion: 2.6.12
Contact: netdev@vger.kernel.org
Description:
Indicates the number of bytes transmitted by a network
device. See the network driver for the exact meaning of this
value, in particular whether this accounts for all successfully
transmitted packets or all packets that have been queued for
transmission.
What: /sys/class/<iface>/statistics/tx_carrier_errors
Date: April 2005
KernelVersion: 2.6.12
Contact: netdev@vger.kernel.org
Description:
Indicates the number of packets that could not be transmitted
because of carrier errors (e.g: physical link down). See the
network driver for the exact meaning of this value.
What: /sys/class/<iface>/statistics/tx_compressed
Date: April 2005
KernelVersion: 2.6.12
Contact: netdev@vger.kernel.org
Description:
Indicates the number of transmitted compressed packets. Note
this might only be relevant for devices that support
compression (e.g: PPP).
What: /sys/class/<iface>/statistics/tx_dropped
Date: April 2005
KernelVersion: 2.6.12
Contact: netdev@vger.kernel.org
Description:
Indicates the number of packets dropped during transmission.
See the driver for the exact reasons as to why the packets were
dropped.
What: /sys/class/<iface>/statistics/tx_errors
Date: April 2005
KernelVersion: 2.6.12
Contact: netdev@vger.kernel.org
Description:
Indicates the number of packets in error during transmission by
a network device. See the driver for the exact reasons as to
why the packets were dropped.
What: /sys/class/<iface>/statistics/tx_fifo_errors
Date: April 2005
KernelVersion: 2.6.12
Contact: netdev@vger.kernel.org
Description:
Indicates the number of packets having caused a transmit
FIFO error. See the driver for the exact reasons as to why the
packets were dropped.
What: /sys/class/<iface>/statistics/tx_heartbeat_errors
Date: April 2005
KernelVersion: 2.6.12
Contact: netdev@vger.kernel.org
Description:
Indicates the number of packets transmitted that have been
reported as heartbeat errors. See the driver for the exact
reasons as to why the packets were dropped.
What: /sys/class/<iface>/statistics/tx_packets
Date: April 2005
KernelVersion: 2.6.12
Contact: netdev@vger.kernel.org
Description:
Indicates the number of packets transmitted by a network
device. See the driver for whether this reports the number of all
attempted or successful transmissions.
What: /sys/class/<iface>/statistics/tx_window_errors
Date: April 2005
KernelVersion: 2.6.12
Contact: netdev@vger.kernel.org
Description:
Indicates the number of packets not successfully transmitted
due to a window collision. The specific meaning depends on the
MAC layer used. On Ethernet this is usually used to report
late collisions errors.

9
Documentation/Changes
View File

@ -280,12 +280,9 @@ that is possible.
mcelog
------
In Linux 2.6.31+ the i386 kernel needs to run the mcelog utility
as a regular cronjob similar to the x86-64 kernel to process and log
machine check events when CONFIG_X86_NEW_MCE is enabled. Machine check
events are errors reported by the CPU. Processing them is strongly encouraged.
All x86-64 kernels since 2.6.4 require the mcelog utility to
process machine checks.
On x86 kernels the mcelog utility is needed to process and log machine check
events when CONFIG_X86_MCE is enabled. Machine check events are errors reported
by the CPU. Processing them is strongly encouraged.
Getting updated software
========================

1
Documentation/DocBook/80211.tmpl
View File

@ -100,6 +100,7 @@
!Finclude/net/cfg80211.h wdev_priv
!Finclude/net/cfg80211.h ieee80211_iface_limit
!Finclude/net/cfg80211.h ieee80211_iface_combination
!Finclude/net/cfg80211.h cfg80211_check_combinations
</chapter>
<chapter>
<title>Actions and configuration</title>

1027
Documentation/DocBook/drm.tmpl
View File

File diff suppressed because it is too large Load Diff

2
Documentation/DocBook/gadget.tmpl
View File

@ -708,7 +708,7 @@ hardware level details could be very different.
<para>Systems need specialized hardware support to implement OTG,
notably including a special <emphasis>Mini-AB</emphasis> jack
and associated transciever to support <emphasis>Dual-Role</emphasis>
and associated transceiver to support <emphasis>Dual-Role</emphasis>
operation:
they can act either as a host, using the standard
Linux-USB host side driver stack,

4
Documentation/DocBook/genericirq.tmpl
View File

@ -182,7 +182,7 @@
<para>
Each interrupt is described by an interrupt descriptor structure
irq_desc. The interrupt is referenced by an 'unsigned int' numeric
value which selects the corresponding interrupt decription structure
value which selects the corresponding interrupt description structure
in the descriptor structures array.
The descriptor structure contains status information and pointers
to the interrupt flow method and the interrupt chip structure
@ -470,7 +470,7 @@ if (desc->irq_data.chip->irq_eoi)
<para>
To avoid copies of identical implementations of IRQ chips the
core provides a configurable generic interrupt chip
implementation. Developers should check carefuly whether the
implementation. Developers should check carefully whether the
generic chip fits their needs before implementing the same
functionality slightly differently themselves.
</para>

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

@ -1760,7 +1760,7 @@ as it would be on UP.
</para>
<para>
There is a furthur optimization possible here: remember our original
There is a further optimization possible here: remember our original
cache code, where there were no reference counts and the caller simply
held the lock whenever using the object? This is still possible: if
you hold the lock, no one can delete the object, so you don't need to

6
Documentation/DocBook/libata.tmpl
View File

@ -677,7 +677,7 @@ and other resources, etc.
<listitem>
<para>
ATA_QCFLAG_ACTIVE is clared from qc->flags.
ATA_QCFLAG_ACTIVE is cleared from qc->flags.
</para>
</listitem>
@ -708,7 +708,7 @@ and other resources, etc.
<listitem>
<para>
qc->waiting is claread &amp; completed (in that order).
qc->waiting is cleared &amp; completed (in that order).
</para>
</listitem>
@ -1163,7 +1163,7 @@ and other resources, etc.
<para>
Once sense data is acquired, this type of errors can be
handled similary to other SCSI errors. Note that sense data
handled similarly to other SCSI errors. Note that sense data
may indicate ATA bus error (e.g. Sense Key 04h HARDWARE ERROR
&amp;&amp; ASC/ASCQ 47h/00h SCSI PARITY ERROR). In such
cases, the error should be considered as an ATA bus error and

4
Documentation/DocBook/media/Makefile
View File

@ -202,8 +202,8 @@ $(MEDIA_OBJ_DIR)/%: $(MEDIA_SRC_DIR)/%.b64
$(MEDIA_OBJ_DIR)/v4l2.xml: $(OBJIMGFILES)
@$($(quiet)gen_xml)
@(ln -sf $(MEDIA_SRC_DIR)/v4l/*xml $(MEDIA_OBJ_DIR)/)
@(ln -sf $(MEDIA_SRC_DIR)/dvb/*xml $(MEDIA_OBJ_DIR)/)
@(ln -sf `cd $(MEDIA_SRC_DIR) && /bin/pwd`/v4l/*xml $(MEDIA_OBJ_DIR)/)
@(ln -sf `cd $(MEDIA_SRC_DIR) && /bin/pwd`/dvb/*xml $(MEDIA_OBJ_DIR)/)
$(MEDIA_OBJ_DIR)/videodev2.h.xml: $(srctree)/include/uapi/linux/videodev2.h $(MEDIA_OBJ_DIR)/v4l2.xml
@$($(quiet)gen_xml)

2
Documentation/DocBook/media_api.tmpl
View File

@ -68,7 +68,7 @@
several digital tv standards. While it is called as DVB API,
in fact it covers several different video standards including
DVB-T, DVB-S, DVB-C and ATSC. The API is currently being updated
to documment support also for DVB-S2, ISDB-T and ISDB-S.</para>
to document support also for DVB-S2, ISDB-T and ISDB-S.</para>
<para>The third part covers the Remote Controller API.</para>
<para>The fourth part covers the Media Controller API.</para>
<para>For additional information and for the latest development code,

30
Documentation/DocBook/mtdnand.tmpl
View File

@ -91,7 +91,7 @@
<listitem><para>
[MTD Interface]</para><para>
These functions provide the interface to the MTD kernel API.
They are not replacable and provide functionality
They are not replaceable and provide functionality
which is complete hardware independent.
</para></listitem>
<listitem><para>
@ -100,14 +100,14 @@
</para></listitem>
<listitem><para>
[GENERIC]</para><para>
Generic functions are not replacable and provide functionality
Generic functions are not replaceable and provide functionality
which is complete hardware independent.
</para></listitem>
<listitem><para>
[DEFAULT]</para><para>
Default functions provide hardware related functionality which is suitable
for most of the implementations. These functions can be replaced by the
board driver if neccecary. Those functions are called via pointers in the
board driver if necessary. Those functions are called via pointers in the
NAND chip description structure. The board driver can set the functions which
should be replaced by board dependent functions before calling nand_scan().
If the function pointer is NULL on entry to nand_scan() then the pointer
@ -264,7 +264,7 @@ static void board_hwcontrol(struct mtd_info *mtd, int cmd)
is set up nand_scan() is called. This function tries to
detect and identify then chip. If a chip is found all the
internal data fields are initialized accordingly.
The structure(s) have to be zeroed out first and then filled with the neccecary
The structure(s) have to be zeroed out first and then filled with the necessary
information about the device.
</para>
<programlisting>
@ -327,7 +327,7 @@ module_init(board_init);
<sect1 id="Exit_function">
<title>Exit function</title>
<para>
The exit function is only neccecary if the driver is
The exit function is only necessary if the driver is
compiled as a module. It releases all resources which
are held by the chip driver and unregisters the partitions
in the MTD layer.
@ -494,7 +494,7 @@ static void board_select_chip (struct mtd_info *mtd, int chip)
in this case. See rts_from4.c and diskonchip.c for
implementation reference. In those cases we must also
use bad block tables on FLASH, because the ECC layout is
interferring with the bad block marker positions.
interfering with the bad block marker positions.
See bad block table support for details.
</para>
</sect2>
@ -542,7 +542,7 @@ static void board_select_chip (struct mtd_info *mtd, int chip)
<para>
nand_scan() calls the function nand_default_bbt().
nand_default_bbt() selects appropriate default
bad block table desriptors depending on the chip information
bad block table descriptors depending on the chip information
which was retrieved by nand_scan().
</para>
<para>
@ -554,7 +554,7 @@ static void board_select_chip (struct mtd_info *mtd, int chip)
<sect2 id="Flash_based_tables">
<title>Flash based tables</title>
<para>
It may be desired or neccecary to keep a bad block table in FLASH.
It may be desired or necessary to keep a bad block table in FLASH.
For AG-AND chips this is mandatory, as they have no factory marked
bad blocks. They have factory marked good blocks. The marker pattern
is erased when the block is erased to be reused. So in case of
@ -565,10 +565,10 @@ static void board_select_chip (struct mtd_info *mtd, int chip)
of the blocks.
</para>
<para>
The blocks in which the tables are stored are procteted against
The blocks in which the tables are stored are protected against
accidental access by marking them bad in the memory bad block
table. The bad block table management functions are allowed
to circumvernt this protection.
to circumvent this protection.
</para>
<para>
The simplest way to activate the FLASH based bad block table support
@ -592,7 +592,7 @@ static void board_select_chip (struct mtd_info *mtd, int chip)
User defined tables are created by filling out a
nand_bbt_descr structure and storing the pointer in the
nand_chip structure member bbt_td before calling nand_scan().
If a mirror table is neccecary a second structure must be
If a mirror table is necessary a second structure must be
created and a pointer to this structure must be stored
in bbt_md inside the nand_chip structure. If the bbt_md
member is set to NULL then only the main table is used
@ -666,7 +666,7 @@ static void board_select_chip (struct mtd_info *mtd, int chip)
<para>
For automatic placement some blocks must be reserved for
bad block table storage. The number of reserved blocks is defined
in the maxblocks member of the babd block table description structure.
in the maxblocks member of the bad block table description structure.
Reserving 4 blocks for mirrored tables should be a reasonable number.
This also limits the number of blocks which are scanned for the bad
block table ident pattern.
@ -1068,11 +1068,11 @@ in this page</entry>
<chapter id="filesystems">
<title>Filesystem support</title>
<para>
The NAND driver provides all neccecary functions for a
The NAND driver provides all necessary functions for a
filesystem via the MTD interface.
</para>
<para>
Filesystems must be aware of the NAND pecularities and
Filesystems must be aware of the NAND peculiarities and
restrictions. One major restrictions of NAND Flash is, that you cannot
write as often as you want to a page. The consecutive writes to a page,
before erasing it again, are restricted to 1-3 writes, depending on the
@ -1222,7 +1222,7 @@ in this page</entry>
#define NAND_BBT_VERSION 0x00000100
/* Create a bbt if none axists */
#define NAND_BBT_CREATE 0x00000200
/* Write bbt if neccecary */
/* Write bbt if necessary */
#define NAND_BBT_WRITE 0x00001000
/* Read and write back block contents when writing bbt */
#define NAND_BBT_SAVECONTENT 0x00002000

2
Documentation/DocBook/regulator.tmpl
View File

@ -155,7 +155,7 @@
release regulators. Functions are
provided to <link linkend='API-regulator-enable'>enable</link>
and <link linkend='API-regulator-disable'>disable</link> the
reguator and to get and set the runtime parameters of the
regulator and to get and set the runtime parameters of the
regulator.
</para>
<para>

4
Documentation/DocBook/uio-howto.tmpl
View File

@ -766,10 +766,10 @@ framework to set up sysfs files for this region. Simply leave it alone.
<para>
The dynamic memory regions will be allocated when the UIO device file,
<varname>/dev/uioX</varname> is opened.
Simiar to static memory resources, the memory region information for
Similar to static memory resources, the memory region information for
dynamic regions is then visible via sysfs at
<varname>/sys/class/uio/uioX/maps/mapY/*</varname>.
The dynmaic memory regions will be freed when the UIO device file is
The dynamic memory regions will be freed when the UIO device file is
closed. When no processes are holding the device file open, the address
returned to userspace is ~0.
</para>

2
Documentation/DocBook/usb.tmpl
View File

@ -153,7 +153,7 @@
<listitem><para>The Linux USB API supports synchronous calls for
control and bulk messages.
It also supports asynchnous calls for all kinds of data transfer,
It also supports asynchronous calls for all kinds of data transfer,
using request structures called "URBs" (USB Request Blocks).
</para></listitem>

2
Documentation/DocBook/writing-an-alsa-driver.tmpl
View File

@ -5696,7 +5696,7 @@ struct _snd_pcm_runtime {
suspending the PCM operations via
<function>snd_pcm_suspend_all()</function> or
<function>snd_pcm_suspend()</function>. It means that the PCM
streams are already stoppped when the register snapshot is
streams are already stopped when the register snapshot is
taken. But, remember that you don't have to restart the PCM
stream in the resume callback. It'll be restarted via
trigger call with <constant>SNDRV_PCM_TRIGGER_RESUME</constant>

2
Documentation/EDID/1024x768.S
View File

@ -36,7 +36,7 @@
#define DPI 72
#define VFREQ 60 /* Hz */
#define TIMING_NAME "Linux XGA"
#define ESTABLISHED_TIMINGS_BITS 0x08 /* Bit 3 -> 1024x768 @60 Hz */
#define ESTABLISHED_TIMING2_BITS 0x08 /* Bit 3 -> 1024x768 @60 Hz */
#define HSYNC_POL 0
#define VSYNC_POL 0
#define CRC 0x55

2
Documentation/EDID/1280x1024.S
View File

@ -36,7 +36,7 @@
#define DPI 72
#define VFREQ 60 /* Hz */
#define TIMING_NAME "Linux SXGA"
#define ESTABLISHED_TIMINGS_BITS 0x00 /* none */
/* No ESTABLISHED_TIMINGx_BITS */
#define HSYNC_POL 1
#define VSYNC_POL 1
#define CRC 0xa0

2
Documentation/EDID/1600x1200.S
View File

@ -36,7 +36,7 @@
#define DPI 72
#define VFREQ 60 /* Hz */
#define TIMING_NAME "Linux UXGA"
#define ESTABLISHED_TIMINGS_BITS 0x00 /* none */
/* No ESTABLISHED_TIMINGx_BITS */
#define HSYNC_POL 1
#define VSYNC_POL 1
#define CRC 0x9d

2
Documentation/EDID/1680x1050.S
View File

@ -36,7 +36,7 @@
#define DPI 96
#define VFREQ 60 /* Hz */
#define TIMING_NAME "Linux WSXGA"
#define ESTABLISHED_TIMINGS_BITS 0x00 /* none */
/* No ESTABLISHED_TIMINGx_BITS */
#define HSYNC_POL 1
#define VSYNC_POL 1
#define CRC 0x26

2
Documentation/EDID/1920x1080.S
View File

@ -36,7 +36,7 @@
#define DPI 96
#define VFREQ 60 /* Hz */
#define TIMING_NAME "Linux FHD"
#define ESTABLISHED_TIMINGS_BITS 0x00 /* none */
/* No ESTABLISHED_TIMINGx_BITS */
#define HSYNC_POL 1
#define VSYNC_POL 1
#define CRC 0x05

41
Documentation/EDID/800x600.S Normal file
View File

@ -0,0 +1,41 @@
/*
800x600.S: EDID data set for standard 800x600 60 Hz monitor
Copyright (C) 2011 Carsten Emde <C.Emde@osadl.org>
Copyright (C) 2014 Linaro Limited
This program is free software; you can redistribute it and/or
modify it under the terms of the GNU General Public License
as published by the Free Software Foundation; either version 2
of the License, or (at your option) any later version.
This program is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
GNU General Public License for more details.
*/
/* EDID */
#define VERSION 1
#define REVISION 3
/* Display */
#define CLOCK 40000 /* kHz */
#define XPIX 800
#define YPIX 600
#define XY_RATIO XY_RATIO_4_3
#define XBLANK 256
#define YBLANK 28
#define XOFFSET 40
#define XPULSE 128
#define YOFFSET (63+1)
#define YPULSE (63+4)
#define DPI 72
#define VFREQ 60 /* Hz */
#define TIMING_NAME "Linux SVGA"
#define ESTABLISHED_TIMING1_BITS 0x01 /* Bit 0: 800x600 @ 60Hz */
#define HSYNC_POL 1
#define VSYNC_POL 1
#define CRC 0xc2
#include "edid.S"

2
Documentation/EDID/HOWTO.txt
View File

@ -18,7 +18,7 @@ CONFIG_DRM_LOAD_EDID_FIRMWARE was introduced. It allows to provide an
individually prepared or corrected EDID data set in the /lib/firmware
directory from where it is loaded via the firmware interface. The code
(see drivers/gpu/drm/drm_edid_load.c) contains built-in data sets for
commonly used screen resolutions (1024x768, 1280x1024, 1600x1200,
commonly used screen resolutions (800x600, 1024x768, 1280x1024, 1600x1200,
1680x1050, 1920x1080) as binary blobs, but the kernel source tree does
not contain code to create these data. In order to elucidate the origin
of the built-in binary EDID blobs and to facilitate the creation of

17
Documentation/EDID/edid.S
View File

@ -33,6 +33,17 @@
#define XY_RATIO_5_4 0b10
#define XY_RATIO_16_9 0b11
/* Provide defaults for the timing bits */
#ifndef ESTABLISHED_TIMING1_BITS
#define ESTABLISHED_TIMING1_BITS 0x00
#endif
#ifndef ESTABLISHED_TIMING2_BITS
#define ESTABLISHED_TIMING2_BITS 0x00
#endif
#ifndef ESTABLISHED_TIMING3_BITS
#define ESTABLISHED_TIMING3_BITS 0x00
#endif
#define mfgname2id(v1,v2,v3) \
((((v1-'@')&0x1f)<<10)+(((v2-'@')&0x1f)<<5)+((v3-'@')&0x1f))
#define swap16(v1) ((v1>>8)+((v1&0xff)<<8))
@ -139,7 +150,7 @@ white_x_y_msb: .byte 0x50,0x54
Bit 2 640x480 @ 75 Hz
Bit 1 800x600 @ 56 Hz
Bit 0 800x600 @ 60 Hz */
estbl_timing1: .byte 0x00
estbl_timing1: .byte ESTABLISHED_TIMING1_BITS
/* Bit 7 800x600 @ 72 Hz
Bit 6 800x600 @ 75 Hz
@ -149,11 +160,11 @@ estbl_timing1: .byte 0x00
Bit 2 1024x768 @ 72 Hz
Bit 1 1024x768 @ 75 Hz
Bit 0 1280x1024 @ 75 Hz */
estbl_timing2: .byte ESTABLISHED_TIMINGS_BITS
estbl_timing2: .byte ESTABLISHED_TIMING2_BITS
/* Bit 7 1152x870 @ 75 Hz (Apple Macintosh II)
Bits 6-0 Other manufacturer-specific display mod */
estbl_timing3: .byte 0x00
estbl_timing3: .byte ESTABLISHED_TIMING3_BITS
/* Standard timing */
/* X resolution, less 31, divided by 8 (256-2288 pixels) */

1
Documentation/accounting/getdelays.c
View File

@ -314,6 +314,7 @@ int main(int argc, char *argv[])
break;
case 'm':
strncpy(cpumask, optarg, sizeof(cpumask));
cpumask[sizeof(cpumask) - 1] = '\0';
maskset = 1;
printf("cpumask %s maskset %d\n", cpumask, maskset);
break;

6
Documentation/cgroups/memory.txt
View File

@ -458,15 +458,11 @@ About use_hierarchy, see Section 6.
5.1 force_empty
memory.force_empty interface is provided to make cgroup's memory usage empty.
You can use this interface only when the cgroup has no tasks.
When writing anything to this
# echo 0 > memory.force_empty
Almost all pages tracked by this memory cgroup will be unmapped and freed.
Some pages cannot be freed because they are locked or in-use. Such pages are
moved to parent (if use_hierarchy==1) or root (if use_hierarchy==0) and this
cgroup will be empty.
the cgroup will be reclaimed and as many pages reclaimed as possible.
The typical use case for this interface is before calling rmdir().
Because rmdir() moves all pages to parent, some out-of-use page caches can be

359
Documentation/cgroups/unified-hierarchy.txt Normal file
View File

@ -0,0 +1,359 @@
Cgroup unified hierarchy
April, 2014 Tejun Heo <tj@kernel.org>
This document describes the changes made by unified hierarchy and
their rationales. It will eventually be merged into the main cgroup
documentation.
CONTENTS
1. Background
2. Basic Operation
2-1. Mounting
2-2. cgroup.subtree_control
2-3. cgroup.controllers
3. Structural Constraints
3-1. Top-down
3-2. No internal tasks
4. Other Changes
4-1. [Un]populated Notification
4-2. Other Core Changes
4-3. Per-Controller Changes
4-3-1. blkio
4-3-2. cpuset
4-3-3. memory
5. Planned Changes
5-1. CAP for resource control
1. Background
cgroup allows an arbitrary number of hierarchies and each hierarchy
can host any number of controllers. While this seems to provide a
high level of flexibility, it isn't quite useful in practice.
For example, as there is only one instance of each controller, utility
type controllers such as freezer which can be useful in all
hierarchies can only be used in one. The issue is exacerbated by the
fact that controllers can't be moved around once hierarchies are
populated. Another issue is that all controllers bound to a hierarchy
are forced to have exactly the same view of the hierarchy. It isn't
possible to vary the granularity depending on the specific controller.
In practice, these issues heavily limit which controllers can be put
on the same hierarchy and most configurations resort to putting each
controller on its own hierarchy. Only closely related ones, such as
the cpu and cpuacct controllers, make sense to put on the same
hierarchy. This often means that userland ends up managing multiple
similar hierarchies repeating the same steps on each hierarchy
whenever a hierarchy management operation is necessary.
Unfortunately, support for multiple hierarchies comes at a steep cost.
Internal implementation in cgroup core proper is dazzlingly
complicated but more importantly the support for multiple hierarchies
restricts how cgroup is used in general and what controllers can do.
There's no limit on how many hierarchies there may be, which means
that a task's cgroup membership can't be described in finite length.
The key may contain any varying number of entries and is unlimited in
length, which makes it highly awkward to handle and leads to addition
of controllers which exist only to identify membership, which in turn
exacerbates the original problem.
Also, as a controller can't have any expectation regarding what shape
of hierarchies other controllers would be on, each controller has to
assume that all other controllers are operating on completely
orthogonal hierarchies. This makes it impossible, or at least very
cumbersome, for controllers to cooperate with each other.
In most use cases, putting controllers on hierarchies which are
completely orthogonal to each other isn't necessary. What usually is
called for is the ability to have differing levels of granularity
depending on the specific controller. In other words, hierarchy may
be collapsed from leaf towards root when viewed from specific
controllers. For example, a given configuration might not care about
how memory is distributed beyond a certain level while still wanting
to control how CPU cycles are distributed.
Unified hierarchy is the next version of cgroup interface. It aims to
address the aforementioned issues by having more structure while
retaining enough flexibility for most use cases. Various other
general and controller-specific interface issues are also addressed in
the process.
2. Basic Operation
2-1. Mounting
Currently, unified hierarchy can be mounted with the following mount
command. Note that this is still under development and scheduled to
change soon.
mount -t cgroup -o __DEVEL__sane_behavior cgroup $MOUNT_POINT
All controllers which are not bound to other hierarchies are
automatically bound to unified hierarchy and show up at the root of
it. Controllers which are enabled only in the root of unified
hierarchy can be bound to other hierarchies at any time. This allows
mixing unified hierarchy with the traditional multiple hierarchies in
a fully backward compatible way.
2-2. cgroup.subtree_control
All cgroups on unified hierarchy have a "cgroup.subtree_control" file
which governs which controllers are enabled on the children of the
cgroup. Let's assume a hierarchy like the following.
root - A - B - C
\ D
root's "cgroup.subtree_control" file determines which controllers are
enabled on A. A's on B. B's on C and D. This coincides with the
fact that controllers on the immediate sub-level are used to
distribute the resources of the parent. In fact, it's natural to
assume that resource control knobs of a child belong to its parent.
Enabling a controller in a "cgroup.subtree_control" file declares that
distribution of the respective resources of the cgroup will be
controlled. Note that this means that controller enable states are
shared among siblings.
When read, the file contains a space-separated list of currently
enabled controllers. A write to the file should contain a
space-separated list of controllers with '+' or '-' prefixed (without
the quotes). Controllers prefixed with '+' are enabled and '-'
disabled. If a controller is listed multiple times, the last entry
wins. The specific operations are executed atomically - either all
succeed or fail.
2-3. cgroup.controllers
Read-only "cgroup.controllers" file contains a space-separated list of
controllers which can be enabled in the cgroup's
"cgroup.subtree_control" file.
In the root cgroup, this lists controllers which are not bound to
other hierarchies and the content changes as controllers are bound to
and unbound from other hierarchies.
In non-root cgroups, the content of this file equals that of the
parent's "cgroup.subtree_control" file as only controllers enabled
from the parent can be used in its children.
3. Structural Constraints
3-1. Top-down
As it doesn't make sense to nest control of an uncontrolled resource,
all non-root "cgroup.subtree_control" files can only contain
controllers which are enabled in the parent's "cgroup.subtree_control"
file. A controller can be enabled only if the parent has the
controller enabled and a controller can't be disabled if one or more
children have it enabled.
3-2. No internal tasks
One long-standing issue that cgroup faces is the competition between
tasks belonging to the parent cgroup and its children cgroups. This
is inherently nasty as two different types of entities compete and
there is no agreed-upon obvious way to handle it. Different
controllers are doing different things.
The cpu controller considers tasks and cgroups as equivalents and maps
nice levels to cgroup weights. This works for some cases but falls
flat when children should be allocated specific ratios of CPU cycles
and the number of internal tasks fluctuates - the ratios constantly
change as the number of competing entities fluctuates. There also are
other issues. The mapping from nice level to weight isn't obvious or
universal, and there are various other knobs which simply aren't
available for tasks.
The blkio controller implicitly creates a hidden leaf node for each
cgroup to host the tasks. The hidden leaf has its own copies of all
the knobs with "leaf_" prefixed. While this allows equivalent control
over internal tasks, it's with serious drawbacks. It always adds an
extra layer of nesting which may not be necessary, makes the interface
messy and significantly complicates the implementation.
The memory controller currently doesn't have a way to control what
happens between internal tasks and child cgroups and the behavior is
not clearly defined. There have been attempts to add ad-hoc behaviors
and knobs to tailor the behavior to specific workloads. Continuing
this direction will lead to problems which will be extremely difficult
to resolve in the long term.
Multiple controllers struggle with internal tasks and came up with
different ways to deal with it; unfortunately, all the approaches in
use now are severely flawed and, furthermore, the widely different
behaviors make cgroup as whole highly inconsistent.
It is clear that this is something which needs to be addressed from
cgroup core proper in a uniform way so that controllers don't need to
worry about it and cgroup as a whole shows a consistent and logical
behavior. To achieve that, unified hierarchy enforces the following
structural constraint:
Except for the root, only cgroups which don't contain any task may
have controllers enabled in their "cgroup.subtree_control" files.
Combined with other properties, this guarantees that, when a
controller is looking at the part of the hierarchy which has it
enabled, tasks are always only on the leaves. This rules out
situations where child cgroups compete against internal tasks of the
parent.
There are two things to note. Firstly, the root cgroup is exempt from
the restriction. Root contains tasks and anonymous resource
consumption which can't be associated with any other cgroup and
requires special treatment from most controllers. How resource
consumption in the root cgroup is governed is up to each controller.
Secondly, the restriction doesn't take effect if there is no enabled
controller in the cgroup's "cgroup.subtree_control" file. This is
important as otherwise it wouldn't be possible to create children of a
populated cgroup. To control resource distribution of a cgroup, the
cgroup must create children and transfer all its tasks to the children
before enabling controllers in its "cgroup.subtree_control" file.
4. Other Changes
4-1. [Un]populated Notification
cgroup users often need a way to determine when a cgroup's
subhierarchy becomes empty so that it can be cleaned up. cgroup
currently provides release_agent for it; unfortunately, this mechanism
is riddled with issues.
- It delivers events by forking and execing a userland binary
specified as the release_agent. This is a long deprecated method of
notification delivery. It's extremely heavy, slow and cumbersome to
integrate with larger infrastructure.
- There is single monitoring point at the root. There's no way to
delegate management of a subtree.
- The event isn't recursive. It triggers when a cgroup doesn't have
any tasks or child cgroups. Events for internal nodes trigger only
after all children are removed. This again makes it impossible to
delegate management of a subtree.
- Events are filtered from the kernel side. A "notify_on_release"
file is used to subscribe to or suppress release events. This is
unnecessarily complicated and probably done this way because event
delivery itself was expensive.
Unified hierarchy implements an interface file "cgroup.populated"
which can be used to monitor whether the cgroup's subhierarchy has
tasks in it or not. Its value is 0 if there is no task in the cgroup
and its descendants; otherwise, 1. poll and [id]notify events are
triggered when the value changes.
This is significantly lighter and simpler and trivially allows
delegating management of subhierarchy - subhierarchy monitoring can
block further propagation simply by putting itself or another process
in the subhierarchy and monitor events that it's interested in from
there without interfering with monitoring higher in the tree.
In unified hierarchy, the release_agent mechanism is no longer
supported and the interface files "release_agent" and
"notify_on_release" do not exist.
4-2. Other Core Changes
- None of the mount options is allowed.
- remount is disallowed.
- rename(2) is disallowed.
- The "tasks" file is removed. Everything should at process
granularity. Use the "cgroup.procs" file instead.
- The "cgroup.procs" file is not sorted. pids will be unique unless
they got recycled in-between reads.
- The "cgroup.clone_children" file is removed.
4-3. Per-Controller Changes
4-3-1. blkio
- blk-throttle becomes properly hierarchical.
4-3-2. cpuset
- Tasks are kept in empty cpusets after hotplug and take on the masks
of the nearest non-empty ancestor, instead of being moved to it.
- A task can be moved into an empty cpuset, and again it takes on the
masks of the nearest non-empty ancestor.
4-3-3. memory
- use_hierarchy is on by default and the cgroup file for the flag is
not created.
5. Planned Changes
5-1. CAP for resource control
Unified hierarchy will require one of the capabilities(7), which is
yet to be decided, for all resource control related knobs. Process
organization operations - creation of sub-cgroups and migration of
processes in sub-hierarchies may be delegated by changing the
ownership and/or permissions on the cgroup directory and
"cgroup.procs" interface file; however, all operations which affect
resource control - writes to a "cgroup.subtree_control" file or any
controller-specific knobs - will require an explicit CAP privilege.
This, in part, is to prevent the cgroup interface from being
inadvertently promoted to programmable API used by non-privileged
binaries. cgroup exposes various aspects of the system in ways which
aren't properly abstracted for direct consumption by regular programs.
This is an administration interface much closer to sysctl knobs than
system calls. Even the basic access model, being filesystem path
based, isn't suitable for direct consumption. There's no way to
access "my cgroup" in a race-free way or make multiple operations
atomic against migration to another cgroup.
Another aspect is that, for better or for worse, the cgroup interface
goes through far less scrutiny than regular interfaces for
unprivileged userland. The upside is that cgroup is able to expose
useful features which may not be suitable for general consumption in a
reasonable time frame. It provides a relatively short path between
internal details and userland-visible interface. Of course, this
shortcut comes with high risk. We go through what we go through for
general kernel APIs for good reasons. It may end up leaking internal
details in a way which can exert significant pain by locking the
kernel into a contract that can't be maintained in a reasonable
manner.
Also, due to the specific nature, cgroup and its controllers don't
tend to attract attention from a wide scope of developers. cgroup's
short history is already fraught with severely mis-designed
interfaces, unnecessary commitments to and exposing of internal
details, broken and dangerous implementations of various features.
Keeping cgroup as an administration interface is both advantageous for
its role and imperative given its nature. Some of the cgroup features
may make sense for unprivileged access. If deemed justified, those
must be further abstracted and implemented as a different interface,
be it a system call or process-private filesystem, and survive through
the scrutiny that any interface for general consumption is required to
go through.
Requiring CAP is not a complete solution but should serve as a
significant deterrent against spraying cgroup usages in non-privileged
programs.

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

@ -26,6 +26,7 @@ Contents:
1.4 target/target_index or setpolicy?
1.5 target/target_index
1.6 setpolicy
1.7 get_intermediate and target_intermediate
2. Frequency Table Helpers
@ -79,6 +80,10 @@ cpufreq_driver.attr - A pointer to a NULL-terminated list of
"struct freq_attr" which allow to
export values to sysfs.
cpufreq_driver.get_intermediate
and target_intermediate Used to switch to stable frequency while
changing CPU frequency.
1.2 Per-CPU Initialization
--------------------------
@ -151,7 +156,7 @@ Some cpufreq-capable processors switch the frequency between certain
limits on their own. These shall use the ->setpolicy call
1.4. target/target_index
1.5. target/target_index
-------------
The target_index call has two arguments: struct cpufreq_policy *policy,
@ -160,6 +165,9 @@ 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.
It should always restore to earlier frequency (i.e. policy->restore_freq) in
case of errors, even if we switched to intermediate frequency earlier.
Deprecated:
----------
The target call has three arguments: struct cpufreq_policy *policy,
@ -179,7 +187,7 @@ Here again the frequency table helper might assist you - see section 2
for details.
1.5 setpolicy
1.6 setpolicy
---------------
The setpolicy call only takes a struct cpufreq_policy *policy as
@ -190,6 +198,23 @@ setting when policy->policy is CPUFREQ_POLICY_PERFORMANCE, and a
powersaving-oriented setting when CPUFREQ_POLICY_POWERSAVE. Also check
the reference implementation in drivers/cpufreq/longrun.c
1.7 get_intermediate and target_intermediate
--------------------------------------------
Only for drivers with target_index() and CPUFREQ_ASYNC_NOTIFICATION unset.
get_intermediate should return a stable intermediate frequency platform wants to
switch to, and target_intermediate() should set CPU to to that frequency, before
jumping to the frequency corresponding to 'index'. Core will take care of
sending notifications and driver doesn't have to handle them in
target_intermediate() or target_index().
Drivers can return '0' from get_intermediate() in case they don't wish to switch
to intermediate frequency for some target frequency. In that case core will
directly call ->target_index().
NOTE: ->target_index() should restore to policy->restore_freq in case of
failures as core would send notifications for that.
2. Frequency Table Helpers

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

@ -15,10 +15,13 @@ New sysfs files for controlling P state selection have been added to
/sys/devices/system/cpu/intel_pstate/
max_perf_pct: limits the maximum P state that will be requested by
the driver stated as a percentage of the available performance.
the driver stated as a percentage of the available performance. The
available (P states) performance may be reduced by the no_turbo
setting described below.
min_perf_pct: limits the minimum P state that will be requested by
the driver stated as a percentage of the available performance.
the driver stated as a percentage of the max (non-turbo)
performance level.
no_turbo: limits the driver to selecting P states below the turbo
frequency range.

14
Documentation/devicetree/bindings/arm/armada-38x.txt
View File

@ -6,5 +6,15 @@ following property:
Required root node property:
- compatible: must contain either "marvell,armada380" or
"marvell,armada385" depending on the variant of the SoC being used.
- compatible: must contain "marvell,armada380"
In addition, boards using the Marvell Armada 385 SoC shall have the
following property before the previous one:
Required root node property:
compatible: must contain "marvell,armada385"
Example:
compatible = "marvell,a385-rd", "marvell,armada385", "marvell,armada380";

20
Documentation/devicetree/bindings/arm/exynos/power_domain.txt
View File

@ -9,6 +9,18 @@ Required Properties:
- reg: physical base address of the controller and length of memory mapped
region.
Optional Properties:
- clocks: List of clock handles. The parent clocks of the input clocks to the
devices in this power domain are set to oscclk before power gating
and restored back after powering on a domain. This is required for
all domains which are powered on and off and not required for unused
domains.
- clock-names: The following clocks can be specified:
- oscclk: Oscillator clock.
- pclkN, clkN: Pairs of parent of input clock and input clock to the
devices in this power domain. Maximum of 4 pairs (N = 0 to 3)
are supported currently.
Node of a device using power domains must have a samsung,power-domain property
defined with a phandle to respective power domain.
@ -19,6 +31,14 @@ Example:
reg = <0x10023C00 0x10>;
};
mfc_pd: power-domain@10044060 {
compatible = "samsung,exynos4210-pd";
reg = <0x10044060 0x20>;
clocks = <&clock CLK_FIN_PLL>, <&clock CLK_MOUT_SW_ACLK333>,
<&clock CLK_MOUT_USER_ACLK333>;
clock-names = "oscclk", "pclk0", "clk0";
};
Example of the node using power domain:
node {

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

@ -40,6 +40,9 @@ Optional properties:
- arm,filter-ranges : <start length> Starting address and length of window to
filter. Addresses in the filter window are directed to the M1 port. Other
addresses will go to the M0 port.
- arm,io-coherent : indicates that the system is operating in an hardware
I/O coherent mode. Valid only when the arm,pl310-cache compatible
string is used.
- interrupts : 1 combined interrupt.
- cache-id-part: cache id part number to be used if it is not present
on hardware

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

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

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

@ -4,10 +4,16 @@ SATA nodes are defined to describe on-chip Serial ATA controllers.
Each SATA controller should have its own node.
Required properties:
- compatible : compatible list, one of "snps,spear-ahci",
"snps,exynos5440-ahci", "ibm,476gtr-ahci",
"allwinner,sun4i-a10-ahci", "fsl,imx53-ahci"
"fsl,imx6q-ahci" or "snps,dwc-ahci"
- compatible : compatible string, one of:
- "allwinner,sun4i-a10-ahci"
- "fsl,imx53-ahci"
- "fsl,imx6q-ahci"
- "hisilicon,hisi-ahci"
- "ibm,476gtr-ahci"
- "marvell,armada-380-ahci"
- "snps,dwc-ahci"
- "snps,exynos5440-ahci"
- "snps,spear-ahci"
- interrupts : <interrupt mapping for SATA IRQ>
- reg : <registers mapping>

10
Documentation/devicetree/bindings/clock/corenet-clock.txt → Documentation/devicetree/bindings/clock/qoriq-clock.txt
View File

@ -7,6 +7,14 @@ which can then be passed to a variety of internal logic, including
cores and peripheral IP blocks.
Please refer to the Reference Manual for details.
All references to "1.0" and "2.0" refer to the QorIQ chassis version to
which the chip complies.
Chassis Version Example Chips
--------------- -------------
1.0 p4080, p5020, p5040
2.0 t4240, b4860, t1040
1. Clock Block Binding
Required properties:
@ -85,7 +93,7 @@ Example for clock block and clock provider:
#clock-cells = <0>;
compatible = "fsl,qoriq-sysclk-1.0";
clock-output-names = "sysclk";
}
};
pll0: pll0@800 {
#clock-cells = <1>;

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

@ -20,12 +20,15 @@ Required properties:
"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-ar100-clk" - for the AR100 on A31
"allwinner,sun6i-a31-ahb1-mux-clk" - for the AHB1 multiplexer on A31
"allwinner,sun6i-a31-ahb1-gates-clk" - for the AHB1 gates on A31
"allwinner,sun4i-a10-apb0-clk" - for the APB0 clock
"allwinner,sun6i-a31-apb0-clk" - for the APB0 clock on A31
"allwinner,sun4i-a10-apb0-gates-clk" - for the APB0 gates on A10
"allwinner,sun5i-a13-apb0-gates-clk" - for the APB0 gates on A13
"allwinner,sun5i-a10s-apb0-gates-clk" - for the APB0 gates on A10s
"allwinner,sun6i-a31-apb0-gates-clk" - for the APB0 gates on A31
"allwinner,sun7i-a20-apb0-gates-clk" - for the APB0 gates on A20
"allwinner,sun4i-a10-apb1-clk" - for the APB1 clock
"allwinner,sun4i-a10-apb1-mux-clk" - for the APB1 clock muxing
@ -41,6 +44,7 @@ Required properties:
"allwinner,sun7i-a20-gmac-clk" - for the GMAC clock module on A20/A31
"allwinner,sun4i-a10-usb-clk" - for usb gates + resets on A10 / A20
"allwinner,sun5i-a13-usb-clk" - for usb gates + resets on A13
"allwinner,sun6i-a31-usb-clk" - for usb gates + resets on A31
Required properties for all clocks:
- reg : shall be the control register address for the clock.

24
Documentation/devicetree/bindings/clock/ti/apll.txt
View File

@ -14,18 +14,32 @@ a subtype of a DPLL [2], although a simplified one at that.
[2] Documentation/devicetree/bindings/clock/ti/dpll.txt
Required properties:
- compatible : shall be "ti,dra7-apll-clock"
- compatible : shall be "ti,dra7-apll-clock" or "ti,omap2-apll-clock"
- #clock-cells : from common clock binding; shall be set to 0.
- clocks : link phandles of parent clocks (clk-ref and clk-bypass)
- reg : address and length of the register set for controlling the APLL.
It contains the information of registers in the following order:
"control" - contains the control register base address
"idlest" - contains the idlest register base address
"control" - contains the control register offset
"idlest" - contains the idlest register offset
"autoidle" - contains the autoidle register offset (OMAP2 only)
- ti,clock-frequency : static clock frequency for the clock (OMAP2 only)
- ti,idlest-shift : bit-shift for the idlest field (OMAP2 only)
- ti,bit-shift : bit-shift for enable and autoidle fields (OMAP2 only)
Examples:
apll_pcie_ck: apll_pcie_ck@4a008200 {
apll_pcie_ck: apll_pcie_ck {
#clock-cells = <0>;
clocks = <&apll_pcie_in_clk_mux>, <&dpll_pcie_ref_ck>;
reg = <0x4a00821c 0x4>, <0x4a008220 0x4>;
reg = <0x021c>, <0x0220>;
compatible = "ti,dra7-apll-clock";
};
apll96_ck: apll96_ck {
#clock-cells = <0>;
compatible = "ti,omap2-apll-clock";
clocks = <&sys_ck>;
ti,bit-shift = <2>;
ti,idlest-shift = <8>;
ti,clock-frequency = <96000000>;
reg = <0x0500>, <0x0530>, <0x0520>;
};

10
Documentation/devicetree/bindings/clock/ti/dpll.txt
View File

@ -24,12 +24,14 @@ Required properties:
"ti,omap4-dpll-core-clock",
"ti,omap4-dpll-m4xen-clock",
"ti,omap4-dpll-j-type-clock",
"ti,omap5-mpu-dpll-clock",
"ti,am3-dpll-no-gate-clock",
"ti,am3-dpll-j-type-clock",
"ti,am3-dpll-no-gate-j-type-clock",
"ti,am3-dpll-clock",
"ti,am3-dpll-core-clock",
"ti,am3-dpll-x2-clock",
"ti,omap2-dpll-core-clock",
- #clock-cells : from common clock binding; shall be set to 0.
- clocks : link phandles of parent clocks, first entry lists reference clock
@ -41,6 +43,7 @@ Required properties:
"mult-div1" - contains the multiplier / divider register base address
"autoidle" - contains the autoidle register base address (optional)
ti,am3-* dpll types do not have autoidle register
ti,omap2-* dpll type does not support idlest / autoidle registers
Optional properties:
- DPLL mode setting - defining any one or more of the following overrides
@ -73,3 +76,10 @@ Examples:
clocks = <&sys_clkin_ck>, <&sys_clkin_ck>;
reg = <0x90>, <0x5c>, <0x68>;
};
dpll_ck: dpll_ck {
#clock-cells = <0>;
compatible = "ti,omap2-dpll-core-clock";
clocks = <&sys_ck>, <&sys_ck>;
reg = <0x0500>, <0x0540>;
};

96
Documentation/devicetree/bindings/clock/ti/dra7-atl.txt Normal file
View File

@ -0,0 +1,96 @@
Device Tree Clock bindings for ATL (Audio Tracking Logic) of DRA7 SoC.
The ATL IP is used to generate clock to be used to synchronize baseband and
audio codec. A single ATL IP provides four ATL clock instances sharing the same
functional clock but can be configured to provide different clocks.
ATL can maintain a clock averages to some desired frequency based on the bws/aws
signals - can compensate the drift between the two ws signal.
In order to provide the support for ATL and it's output clocks (which can be used
internally within the SoC or external components) two sets of bindings is needed:
Clock tree binding:
This binding uses the common clock binding[1].
To be able to integrate the ATL clocks with DT clock tree.
Provides ccf level representation of the ATL clocks to be used by drivers.
Since the clock instances are part of a single IP this binding is used as a node
for the DT clock tree, the IP driver is needed to handle the actual configuration
of the IP.
[1] Documentation/devicetree/bindings/clock/clock-bindings.txt
Required properties:
- compatible : shall be "ti,dra7-atl-clock"
- #clock-cells : from common clock binding; shall be set to 0.
- clocks : link phandles to functional clock of ATL
Binding for the IP driver:
This binding is used to configure the IP driver which is going to handle the
configuration of the IP for the ATL clock instances.
Required properties:
- compatible : shall be "ti,dra7-atl"
- reg : base address for the ATL IP
- ti,provided-clocks : List of phandles to the clocks associated with the ATL
- clocks : link phandles to functional clock of ATL
- clock-names : Shall be set to "fck"
- ti,hwmods : Shall be set to "atl"
Optional properties:
Configuration of ATL instances:
- atl{0/1/2/3} {
- bws : Baseband word select signal selection
- aws : Audio word select signal selection
};
For valid word select signals, see the dt-bindings/clk/ti-dra7-atl.h include
file.
Examples:
/* clock bindings for atl provided clocks */
atl_clkin0_ck: atl_clkin0_ck {
#clock-cells = <0>;
compatible = "ti,dra7-atl-clock";
clocks = <&atl_gfclk_mux>;
};
atl_clkin1_ck: atl_clkin1_ck {
#clock-cells = <0>;
compatible = "ti,dra7-atl-clock";
clocks = <&atl_gfclk_mux>;
};
atl_clkin2_ck: atl_clkin2_ck {
#clock-cells = <0>;
compatible = "ti,dra7-atl-clock";
clocks = <&atl_gfclk_mux>;
};
atl_clkin3_ck: atl_clkin3_ck {
#clock-cells = <0>;
compatible = "ti,dra7-atl-clock";
clocks = <&atl_gfclk_mux>;
};
/* binding for the IP */
atl: atl@4843c000 {
compatible = "ti,dra7-atl";
reg = <0x4843c000 0x3ff>;
ti,hwmods = "atl";
ti,provided-clocks = <&atl_clkin0_ck>, <&atl_clkin1_ck>,
<&atl_clkin2_ck>, <&atl_clkin3_ck>;
clocks = <&atl_gfclk_mux>;
clock-names = "fck";
status = "disabled";
};
#include <dt-bindings/clk/ti-dra7-atl.h>
&atl {
status = "okay";
atl2 {
bws = <DRA7_ATL_WS_MCASP2_FSX>;
aws = <DRA7_ATL_WS_MCASP3_FSX>;
};
};

29
Documentation/devicetree/bindings/clock/ti/gate.txt
View File

@ -25,6 +25,11 @@ Required properties:
to map clockdomains properly
"ti,hsdiv-gate-clock" - gate clock with OMAP36xx specific hardware handling,
required for a hardware errata
"ti,composite-gate-clock" - composite gate clock, to be part of composite
clock
"ti,composite-no-wait-gate-clock" - composite gate clock that does not wait
for clock to be active before returning
from clk_enable()
- #clock-cells : from common clock binding; shall be set to 0
- clocks : link to phandle of parent clock
- reg : offset for register controlling adjustable gate, not needed for
@ -41,7 +46,7 @@ Examples:
#clock-cells = <0>;
compatible = "ti,gate-clock";
clocks = <&core_96m_fck>;
reg = <0x48004a00 0x4>;
reg = <0x0a00>;
ti,bit-shift = <25>;
};
@ -57,7 +62,7 @@ Examples:
#clock-cells = <0>;
compatible = "ti,dss-gate-clock";
clocks = <&dpll4_m4x2_ck>;
reg = <0x48004e00 0x4>;
reg = <0x0e00>;
ti,bit-shift = <0>;
};
@ -65,7 +70,7 @@ Examples:
#clock-cells = <0>;
compatible = "ti,am35xx-gate-clock";
clocks = <&ipss_ick>;
reg = <0x4800259c 0x4>;
reg = <0x059c>;
ti,bit-shift = <1>;
};
@ -80,6 +85,22 @@ Examples:
compatible = "ti,hsdiv-gate-clock";
clocks = <&dpll4_m2x2_mul_ck>;
ti,bit-shift = <0x1b>;
reg = <0x48004d00 0x4>;
reg = <0x0d00>;
ti,set-bit-to-disable;
};
vlynq_gate_fck: vlynq_gate_fck {
#clock-cells = <0>;
compatible = "ti,composite-gate-clock";
clocks = <&core_ck>;
ti,bit-shift = <3>;
reg = <0x0200>;
};
sys_clkout2_src_gate: sys_clkout2_src_gate {
#clock-cells = <0>;
compatible = "ti,composite-no-wait-gate-clock";
clocks = <&core_ck>;
ti,bit-shift = <15>;
reg = <0x0070>;
};

2
Documentation/devicetree/bindings/clock/ti/interface.txt
View File

@ -21,6 +21,8 @@ Required properties:
"ti,omap3-dss-interface-clock" - interface clock with DSS specific HW handling
"ti,omap3-ssi-interface-clock" - interface clock with SSI specific HW handling
"ti,am35xx-interface-clock" - interface clock with AM35xx specific HW handling
"ti,omap2430-interface-clock" - interface clock with OMAP2430 specific HW
handling
- #clock-cells : from common clock binding; shall be set to 0
- clocks : link to phandle of parent clock
- reg : base address for the control register

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

@ -1,17 +1,20 @@
* MARVELL MMP DMA controller
Marvell Peripheral DMA Controller
Used platfroms: pxa688, pxa910, pxa3xx, etc
Used platforms: pxa688, pxa910, pxa3xx, etc
Required properties:
- compatible: Should be "marvell,pdma-1.0"
- reg: Should contain DMA registers location and length.
- interrupts: Either contain all of the per-channel DMA interrupts
or one irq for pdma device
- #dma-channels: Number of DMA channels supported by the controller.
Optional properties:
- #dma-channels: Number of DMA channels supported by the controller (defaults
to 32 when not specified)
"marvell,pdma-1.0"
Used platfroms: pxa25x, pxa27x, pxa3xx, pxa93x, pxa168, pxa910, pxa688.
Used platforms: pxa25x, pxa27x, pxa3xx, pxa93x, pxa168, pxa910, pxa688.
Examples:
@ -45,7 +48,7 @@ pdma: dma-controller@d4000000 {
Marvell Two Channel DMA Controller used specifically for audio
Used platfroms: pxa688, pxa910
Used platforms: pxa688, pxa910
Required properties:
- compatible: Should be "marvell,adma-1.0" or "marvell,pxa910-squ"

75
Documentation/devicetree/bindings/dma/xilinx/xilinx_vdma.txt Normal file
View File

@ -0,0 +1,75 @@
Xilinx AXI VDMA engine, it does transfers between memory and video devices.
It can be configured to have one channel or two channels. If configured
as two channels, one is to transmit to the video device and another is
to receive from the video device.
Required properties:
- compatible: Should be "xlnx,axi-vdma-1.00.a"
- #dma-cells: Should be <1>, see "dmas" property below
- reg: Should contain VDMA registers location and length.
- xlnx,num-fstores: Should be the number of framebuffers as configured in h/w.
- dma-channel child node: Should have at least one channel and can have up to
two channels per device. This node specifies the properties of each
DMA channel (see child node properties below).
Optional properties:
- xlnx,include-sg: Tells configured for Scatter-mode in
the hardware.
- xlnx,flush-fsync: Tells which channel to Flush on Frame sync.
It takes following values:
{1}, flush both channels
{2}, flush mm2s channel
{3}, flush s2mm channel
Required child node properties:
- compatible: It should be either "xlnx,axi-vdma-mm2s-channel" or
"xlnx,axi-vdma-s2mm-channel".
- interrupts: Should contain per channel VDMA interrupts.
- xlnx,data-width: Should contain the stream data width, take values
{32,64...1024}.
Optional child node properties:
- xlnx,include-dre: Tells hardware is configured for Data
Realignment Engine.
- xlnx,genlock-mode: Tells Genlock synchronization is
enabled/disabled in hardware.
Example:
++++++++
axi_vdma_0: axivdma@40030000 {
compatible = "xlnx,axi-vdma-1.00.a";
#dma_cells = <1>;
reg = < 0x40030000 0x10000 >;
xlnx,num-fstores = <0x8>;
xlnx,flush-fsync = <0x1>;
dma-channel@40030000 {
compatible = "xlnx,axi-vdma-mm2s-channel";
interrupts = < 0 54 4 >;
xlnx,datawidth = <0x40>;
} ;
dma-channel@40030030 {
compatible = "xlnx,axi-vdma-s2mm-channel";
interrupts = < 0 53 4 >;
xlnx,datawidth = <0x40>;
} ;
} ;
* DMA client
Required properties:
- dmas: a list of <[Video DMA device phandle] [Channel ID]> pairs,
where Channel ID is '0' for write/tx and '1' for read/rx
channel.
- dma-names: a list of DMA channel names, one per "dmas" entry
Example:
++++++++
vdmatest_0: vdmatest@0 {
compatible ="xlnx,axi-vdma-test-1.00.a";
dmas = <&axi_vdma_0 0
&axi_vdma_0 1>;
dma-names = "vdma0", "vdma1";
} ;

2
Documentation/devicetree/bindings/gpu/nvidia,tegra20-host1x.txt
View File

@ -136,6 +136,7 @@ of the following host1x client modules:
- compatible: "nvidia,tegra<chip>-hdmi"
- reg: Physical base address and length of the controller's registers.
- interrupts: The interrupt outputs from the controller.
- hdmi-supply: supply for the +5V HDMI connector pin
- vdd-supply: regulator for supply voltage
- pll-supply: regulator for PLL
- clocks: Must contain an entry for each entry in clock-names.
@ -180,6 +181,7 @@ of the following host1x client modules:
See ../reset/reset.txt for details.
- reset-names: Must include the following entries:
- dsi
- avdd-dsi-supply: phandle of a supply that powers the DSI controller
- nvidia,mipi-calibrate: Should contain a phandle and a specifier specifying
which pads are used by this DSI output and need to be calibrated. See also
../mipi/nvidia,tegra114-mipi.txt.

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

@ -3,11 +3,19 @@ NTC Thermistor hwmon sensors
Requires node properties:
- "compatible" value : one of
"ntc,ncp15wb473"
"ntc,ncp18wb473"
"ntc,ncp21wb473"
"ntc,ncp03wb473"
"ntc,ncp15wl333"
"murata,ncp15wb473"
"murata,ncp18wb473"
"murata,ncp21wb473"
"murata,ncp03wb473"
"murata,ncp15wl333"
/* Usage of vendor name "ntc" is deprecated */
<DEPRECATED> "ntc,ncp15wb473"
<DEPRECATED> "ntc,ncp18wb473"
<DEPRECATED> "ntc,ncp21wb473"
<DEPRECATED> "ntc,ncp03wb473"
<DEPRECATED> "ntc,ncp15wl333"
- "pullup-uv" Pull up voltage in micro volts
- "pullup-ohm" Pull up resistor value in ohms
- "pulldown-ohm" Pull down resistor value in ohms
@ -21,7 +29,7 @@ Read more about iio bindings at
Example:
ncp15wb473@0 {
compatible = "ntc,ncp15wb473";
compatible = "murata,ncp15wb473";
pullup-uv = <1800000>;
pullup-ohm = <47000>;
pulldown-ohm = <0>;

42
Documentation/devicetree/bindings/i2c/i2c-rk3x.txt Normal file
View File

@ -0,0 +1,42 @@
* Rockchip RK3xxx I2C controller
This driver interfaces with the native I2C controller present in Rockchip
RK3xxx SoCs.
Required properties :
- reg : Offset and length of the register set for the device
- compatible : should be "rockchip,rk3066-i2c", "rockchip,rk3188-i2c" or
"rockchip,rk3288-i2c".
- interrupts : interrupt number
- clocks : parent clock
Required on RK3066, RK3188 :
- rockchip,grf : the phandle of the syscon node for the general register
file (GRF)
- on those SoCs an alias with the correct I2C bus ID (bit offset in the GRF)
is also required.
Optional properties :
- clock-frequency : SCL frequency to use (in Hz). If omitted, 100kHz is used.
Example:
aliases {
i2c0 = &i2c0;
}
i2c0: i2c@2002d000 {
compatible = "rockchip,rk3188-i2c";
reg = <0x2002d000 0x1000>;
interrupts = <GIC_SPI 40 IRQ_TYPE_LEVEL_HIGH>;
#address-cells = <1>;
#size-cells = <0>;
rockchip,grf = <&grf>;
clock-names = "i2c";
clocks = <&cru PCLK_I2C0>;
};

41
Documentation/devicetree/bindings/i2c/i2c-sunxi-p2wi.txt Normal file
View File

@ -0,0 +1,41 @@
* Allwinner P2WI (Push/Pull 2 Wire Interface) controller
Required properties :
- reg : Offset and length of the register set for the device.
- compatible : Should one of the following:
- "allwinner,sun6i-a31-p2wi"
- interrupts : The interrupt line connected to the P2WI peripheral.
- clocks : The gate clk connected to the P2WI peripheral.
- resets : The reset line connected to the P2WI peripheral.
Optional properties :
- clock-frequency : Desired P2WI bus clock frequency in Hz. If not set the
default frequency is 100kHz
A P2WI may contain one child node encoding a P2WI slave device.
Slave device properties:
Required properties:
- reg : the I2C slave address used during the initialization
process to switch from I2C to P2WI mode
Example:
p2wi@01f03400 {
compatible = "allwinner,sun6i-a31-p2wi";
reg = <0x01f03400 0x400>;
interrupts = <0 39 4>;
clocks = <&apb0_gates 3>;
clock-frequency = <6000000>;
resets = <&apb0_rst 3>;
axp221: pmic@68 {
compatible = "x-powers,axp221";
reg = <0x68>;
/* ... */
};
};

0
Documentation/devicetree/bindings/gpio/gpio_keys.txt → Documentation/devicetree/bindings/input/gpio-keys.txt
View File

60
Documentation/devicetree/bindings/input/st-keyscan.txt Normal file
View File

@ -0,0 +1,60 @@
* ST Keyscan controller Device Tree bindings
The ST keyscan controller Device Tree binding is based on the
matrix-keymap.
Required properties:
- compatible: "st,sti-keyscan"
- reg: Register base address and size of st-keyscan controller.
- interrupts: Interrupt number for the st-keyscan controller.
- clocks: Must contain one entry, for the module clock.
See ../clocks/clock-bindings.txt for details.
- pinctrl: Should specify pin control groups used for this controller.
See ../pinctrl/pinctrl-bindings.txt for details.
- linux,keymap: The keymap for keys as described in the binding document
devicetree/bindings/input/matrix-keymap.txt.
- keypad,num-rows: Number of row lines connected to the keypad controller.
- keypad,num-columns: Number of column lines connected to the keypad
controller.
Optional property:
- st,debounce_us: Debouncing interval time in microseconds
Example:
keyscan: keyscan@fe4b0000 {
compatible = "st,sti-keyscan";
reg = <0xfe4b0000 0x2000>;
interrupts = <GIC_SPI 212 IRQ_TYPE_NONE>;
clocks = <&CLK_SYSIN>;
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_keyscan>;
keypad,num-rows = <4>;
keypad,num-columns = <4>;
st,debounce_us = <5000>;
linux,keymap = < MATRIX_KEY(0x00, 0x00, KEY_F13)
MATRIX_KEY(0x00, 0x01, KEY_F9)
MATRIX_KEY(0x00, 0x02, KEY_F5)
MATRIX_KEY(0x00, 0x03, KEY_F1)
MATRIX_KEY(0x01, 0x00, KEY_F14)
MATRIX_KEY(0x01, 0x01, KEY_F10)
MATRIX_KEY(0x01, 0x02, KEY_F6)
MATRIX_KEY(0x01, 0x03, KEY_F2)
MATRIX_KEY(0x02, 0x00, KEY_F15)
MATRIX_KEY(0x02, 0x01, KEY_F11)
MATRIX_KEY(0x02, 0x02, KEY_F7)
MATRIX_KEY(0x02, 0x03, KEY_F3)
MATRIX_KEY(0x03, 0x00, KEY_F16)
MATRIX_KEY(0x03, 0x01, KEY_F12)
MATRIX_KEY(0x03, 0x02, KEY_F8)
MATRIX_KEY(0x03, 0x03, KEY_F4) >;
};

20
Documentation/devicetree/bindings/input/touchscreen/sun4i.txt Normal file
View File

@ -0,0 +1,20 @@
sun4i resistive touchscreen controller
--------------------------------------
Required properties:
- compatible: "allwinner,sun4i-a10-ts"
- reg: mmio address range of the chip
- interrupts: interrupt to which the chip is connected
Optional properties:
- allwinner,ts-attached: boolean indicating that an actual touchscreen is
attached to the controller
Example:
rtp: rtp@01c25000 {
compatible = "allwinner,sun4i-a10-ts";
reg = <0x01c25000 0x100>;
interrupts = <29>;
allwinner,ts-attached;
};

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

@ -0,0 +1,27 @@
General Touchscreen Properties:
Optional properties for Touchscreens:
- touchscreen-size-x : horizontal resolution of touchscreen
(in pixels)
- touchscreen-size-y : vertical resolution of touchscreen
(in pixels)
- touchscreen-max-pressure : maximum reported pressure (arbitrary range
dependent on the controller)
- touchscreen-fuzz-x : horizontal noise value of the absolute input
device (in pixels)
- touchscreen-fuzz-y : vertical noise value of the absolute input
device (in pixels)
- touchscreen-fuzz-pressure : pressure noise value of the absolute input
device (arbitrary range dependent on the
controller)
- touchscreen-inverted-x : X axis is inverted (boolean)
- touchscreen-inverted-y : Y axis is inverted (boolean)
Deprecated properties for Touchscreens:
- x-size : deprecated name for touchscreen-size-x
- y-size : deprecated name for touchscreen-size-y
- moving-threshold : deprecated name for a combination of
touchscreen-fuzz-x and touchscreen-fuzz-y
- contact-threshold : deprecated name for touchscreen-fuzz-pressure
- x-invert : deprecated name for touchscreen-inverted-x
- y-invert : deprecated name for touchscreen-inverted-y

42
Documentation/devicetree/bindings/input/touchscreen/tsc2005.txt Normal file
View File

@ -0,0 +1,42 @@
* Texas Instruments tsc2005 touchscreen controller
Required properties:
- compatible : "ti,tsc2005"
- reg : SPI device address
- spi-max-frequency : Maximal SPI speed
- interrupts : IRQ specifier
- reset-gpios : GPIO specifier
- vio-supply : Regulator specifier
Optional properties:
- ti,x-plate-ohms : integer, resistance of the touchscreen's X plates
in ohm (defaults to 280)
- ti,esd-recovery-timeout-ms : integer, if the touchscreen does not respond after
the configured time (in milli seconds), the driver
will reset it. This is disabled by default.
- properties defined in touchscreen.txt
Example:
&mcspi1 {
tsc2005@0 {
compatible = "ti,tsc2005";
spi-max-frequency = <6000000>;
reg = <0>;
vio-supply = <&vio>;
reset-gpios = <&gpio4 8 GPIO_ACTIVE_HIGH>; /* 104 */
interrupts-extended = <&gpio4 4 IRQ_TYPE_EDGE_RISING>; /* 100 */
touchscreen-fuzz-x = <4>;
touchscreen-fuzz-y = <7>;
touchscreen-fuzz-pressure = <2>;
touchscreen-max-x = <4096>;
touchscreen-max-y = <4096>;
touchscreen-max-pressure = <2048>;
ti,x-plate-ohms = <280>;
ti,esd-recovery-timeout-ms = <8000>;
};
}

8
Documentation/devicetree/bindings/leds/leds-lp55xx.txt
View File

@ -1,7 +1,13 @@
Binding for TI/National Semiconductor LP55xx Led Drivers
Required properties:
- compatible: "national,lp5521" or "national,lp5523" or "ti,lp5562" or "ti,lp8501"
- compatible: one of
national,lp5521
national,lp5523
ti,lp55231
ti,lp5562
ti,lp8501
- reg: I2C slave address
- clock-mode: Input clock mode, (0: automode, 1: internal, 2: external)

2
Documentation/devicetree/bindings/leds/leds-pwm.txt
View File

@ -13,6 +13,8 @@ LED sub-node properties:
For the pwms and pwm-names property please refer to:
Documentation/devicetree/bindings/pwm/pwm.txt
- max-brightness : Maximum brightness possible for the LED
- active-low : (optional) For PWMs where the LED is wired to supply
rather than ground.
- label : (optional)
see Documentation/devicetree/bindings/leds/common.txt
- linux,default-trigger : (optional)

25
Documentation/devicetree/bindings/mfd/bfticu.txt Normal file
View File

@ -0,0 +1,25 @@
KEYMILE bfticu Chassis Management FPGA
The bfticu is a multifunction device that manages the whole chassis.
Its main functionality is to collect IRQs from the whole chassis and signals
them to a single controller.
Required properties:
- compatible: "keymile,bfticu"
- interrupt-controller: the bfticu FPGA is an interrupt controller
- interrupts: the main IRQ line to signal the collected IRQs
- #interrupt-cells : is 2 and their usage is compliant to the 2 cells variant
of Documentation/devicetree/bindings/interrupt-controller/interrupts.txt
- interrupt-parent: the parent IRQ ctrl the main IRQ is connected to
- reg: access on the parent local bus (chip select, offset in chip select, size)
Example:
chassis-mgmt@3,0 {
compatible = "keymile,bfticu";
interrupt-controller;
#interrupt-cells = <2>;
reg = <3 0 0x100>;
interrupt-parent = <&mpic>;
interrupts = <6 1 0 0>;
};

17
Documentation/devicetree/bindings/mfd/qriox.txt Normal file
View File

@ -0,0 +1,17 @@
KEYMILE qrio Board Control CPLD
The qrio is a multifunction device that controls the KEYMILE boards based on
the kmp204x design.
It is consists of a reset controller, watchdog timer, LEDs, and 2 IRQ capable
GPIO blocks.
Required properties:
- compatible: "keymile,qriox"
- reg: access on the parent local bus (chip select, offset in chip select, size)
Example:
board-control@1,0 {
compatible = "keymile,qriox";
reg = <1 0 0x80>;
};

17
Documentation/devicetree/bindings/mfd/twl4030-power.txt
View File

@ -5,7 +5,22 @@ to control the power resources, including power scripts. For now, the
binding only supports the complete shutdown of the system after poweroff.
Required properties:
- compatible : must be "ti,twl4030-power"
- compatible : must be one of the following
"ti,twl4030-power"
"ti,twl4030-power-reset"
"ti,twl4030-power-idle"
"ti,twl4030-power-idle-osc-off"
The use of ti,twl4030-power-reset is recommended at least on
3530 that needs a special configuration for warm reset to work.
When using ti,twl4030-power-idle, the TI recommended configuration
for idle modes is loaded to the tlw4030 PMIC.
When using ti,twl4030-power-idle-osc-off, the TI recommended
configuration is used with the external oscillator being shut
down during off-idle. Note that this does not work on all boards
depending on how the external oscillator is wired.
Optional properties:
- ti,use_poweroff: With this flag, the chip will initiates an ACTIVE-to-OFF or

2
Documentation/devicetree/bindings/mmc/mmc.txt
View File

@ -38,6 +38,8 @@ Optional properties:
- mmc-highspeed-ddr-1_2v: eMMC high-speed DDR mode(1.2V I/O) is supported
- mmc-hs200-1_8v: eMMC HS200 mode(1.8V I/O) is supported
- mmc-hs200-1_2v: eMMC HS200 mode(1.2V I/O) is supported
- mmc-hs400-1_8v: eMMC HS400 mode(1.8V I/O) is supported
- mmc-hs400-1_2v: eMMC HS400 mode(1.2V I/O) is supported
*NOTE* on CD and WP polarity. To use common for all SD/MMC host controllers line
polarity properties, we have to fix the meaning of the "normal" and "inverted"

30
Documentation/devicetree/bindings/mmc/moxa,moxart-mmc.txt Normal file
View File

@ -0,0 +1,30 @@
MOXA ART MMC Host Controller Interface
Inherits from mmc binding[1].
[1] Documentation/devicetree/bindings/mmc/mmc.txt
Required properties:
- compatible : Must be "moxa,moxart-mmc" or "faraday,ftsdc010"
- reg : Should contain registers location and length
- interrupts : Should contain the interrupt number
- clocks : Should contain phandle for the clock feeding the MMC controller
Optional properties:
- dmas : Should contain two DMA channels, line request number must be 5 for
both channels
- dma-names : Must be "tx", "rx"
Example:
mmc: mmc@98e00000 {
compatible = "moxa,moxart-mmc";
reg = <0x98e00000 0x5C>;
interrupts = <5 0>;
clocks = <&clk_apb>;
dmas = <&dma 5>,
<&dma 5>;
dma-names = "tx", "rx";
};

5
Documentation/devicetree/bindings/mmc/synopsys-dw-mshc.txt
View File

@ -69,10 +69,6 @@ Optional properties:
* supports-highspeed: Enables support for high speed cards (up to 50MHz)
* caps2-mmc-hs200-1_8v: Supports mmc HS200 SDR 1.8V mode
* caps2-mmc-hs200-1_2v: Supports mmc HS200 SDR 1.2V mode
* broken-cd: as documented in mmc core bindings.
* vmmc-supply: The phandle to the regulator to use for vmmc. If this is
@ -103,7 +99,6 @@ board specific portions as listed below.
clock-freq-min-max = <400000 200000000>;
num-slots = <1>;
supports-highspeed;
caps2-mmc-hs200-1_8v;
broken-cd;
fifo-depth = <0x80>;
card-detect-delay = <200>;

33
Documentation/devicetree/bindings/mmc/usdhi6rol0.txt Normal file
View File

@ -0,0 +1,33 @@
* Renesas usdhi6rol0 SD/SDIO host controller
Required properties:
- compatible: must be
"renesas,usdhi6rol0"
- interrupts: 3 interrupts, named "card detect", "data" and "SDIO" must be
specified
- clocks: a clock binding for the IMCLK input
Optional properties:
- vmmc-supply: a phandle of a regulator, supplying Vcc to the card
- vqmmc-supply: a phandle of a regulator, supplying VccQ to the card
Additionally any standard mmc bindings from mmc.txt can be used.
Example:
sd0: sd@ab000000 {
compatible = "renesas,usdhi6rol0";
reg = <0xab000000 0x200>;
interrupts = <0 23 0x4
0 24 0x4
0 25 0x4>;
interrupt-names = "card detect", "data", "SDIO";
bus-width = <4>;
max-frequency = <50000000>;
cap-power-off-card;
clocks = <&imclk>;
vmmc-supply = <&vcc_sd0>;
vqmmc-supply = <&vccq_sd0>;
};

35
Documentation/devicetree/bindings/mtd/fsl-quadspi.txt Normal file
View File

@ -0,0 +1,35 @@
* Freescale Quad Serial Peripheral Interface(QuadSPI)
Required properties:
- compatible : Should be "fsl,vf610-qspi"
- reg : the first contains the register location and length,
the second contains the memory mapping address and length
- reg-names: Should contain the reg names "QuadSPI" and "QuadSPI-memory"
- interrupts : Should contain the interrupt for the device
- clocks : The clocks needed by the QuadSPI controller
- clock-names : the name of the clocks
Optional properties:
- fsl,qspi-has-second-chip: The controller has two buses, bus A and bus B.
Each bus can be connected with two NOR flashes.
Most of the time, each bus only has one NOR flash
connected, this is the default case.
But if there are two NOR flashes connected to the
bus, you should enable this property.
(Please check the board's schematic.)
Example:
qspi0: quadspi@40044000 {
compatible = "fsl,vf610-qspi";
reg = <0x40044000 0x1000>, <0x20000000 0x10000000>;
reg-names = "QuadSPI", "QuadSPI-memory";
interrupts = <0 24 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&clks VF610_CLK_QSPI0_EN>,
<&clks VF610_CLK_QSPI0>;
clock-names = "qspi_en", "qspi";
flash0: s25fl128s@0 {
....
};
};

45
Documentation/devicetree/bindings/mtd/gpmc-nand.txt
View File

@ -28,6 +28,8 @@ Optional properties:
"ham1" 1-bit Hamming ecc code
"bch4" 4-bit BCH ecc code
"bch8" 8-bit BCH ecc code
"bch16" 16-bit BCH ECC code
Refer below "How to select correct ECC scheme for your device ?"
- ti,nand-xfer-type: A string setting the data transfer type. One of:
@ -90,3 +92,46 @@ Example for an AM33xx board:
};
};
How to select correct ECC scheme for your device ?
--------------------------------------------------
Higher ECC scheme usually means better protection against bit-flips and
increased system lifetime. However, selection of ECC scheme is dependent
on various other factors also like;
(1) support of built in hardware engines.
Some legacy OMAP SoC do not have ELM harware engine, so those SoC cannot
support ecc-schemes with hardware error-correction (BCHx_HW). However
such SoC can use ecc-schemes with software library for error-correction
(BCHx_HW_DETECTION_SW). The error correction capability with software
library remains equivalent to their hardware counter-part, but there is
slight CPU penalty when too many bit-flips are detected during reads.
(2) Device parameters like OOBSIZE.
Other factor which governs the selection of ecc-scheme is oob-size.
Higher ECC schemes require more OOB/Spare area to store ECC syndrome,
so the device should have enough free bytes available its OOB/Spare
area to accomodate ECC for entire page. In general following expression
helps in determining if given device can accomodate ECC syndrome:
"2 + (PAGESIZE / 512) * ECC_BYTES" >= OOBSIZE"
where
OOBSIZE number of bytes in OOB/spare area
PAGESIZE number of bytes in main-area of device page
ECC_BYTES number of ECC bytes generated to protect
512 bytes of data, which is:
'3' for HAM1_xx ecc schemes
'7' for BCH4_xx ecc schemes
'14' for BCH8_xx ecc schemes
'26' for BCH16_xx ecc schemes
Example(a): For a device with PAGESIZE = 2048 and OOBSIZE = 64 and
trying to use BCH16 (ECC_BYTES=26) ecc-scheme.
Number of ECC bytes per page = (2 + (2048 / 512) * 26) = 106 B
which is greater than capacity of NAND device (OOBSIZE=64)
Hence, BCH16 cannot be supported on given device. But it can
probably use lower ecc-schemes like BCH8.
Example(b): For a device with PAGESIZE = 2048 and OOBSIZE = 128 and
trying to use BCH16 (ECC_BYTES=26) ecc-scheme.
Number of ECC bytes per page = (2 + (2048 / 512) * 26) = 106 B
which can be accomodate in the OOB/Spare area of this device
(OOBSIZE=128). So this device can use BCH16 ecc-scheme.

4
Documentation/devicetree/bindings/mtd/m25p80.txt
View File

@ -5,8 +5,8 @@ Required properties:
representing partitions.
- compatible : Should be the manufacturer and the name of the chip. Bear in mind
the DT binding is not Linux-only, but in case of Linux, see the
"m25p_ids" table in drivers/mtd/devices/m25p80.c for the list of
supported chips.
"spi_nor_ids" table in drivers/mtd/spi-nor/spi-nor.c for the list
of supported chips.
- reg : Chip-Select number
- spi-max-frequency : Maximum frequency of the SPI bus the chip can operate at

8
Documentation/devicetree/bindings/mtd/pxa3xx-nand.txt
View File

@ -17,6 +17,14 @@ Optional properties:
- num-cs: Number of chipselect lines to usw
- nand-on-flash-bbt: boolean to enable on flash bbt option if
not present false
- nand-ecc-strength: number of bits to correct per ECC step
- nand-ecc-step-size: number of data bytes covered by a single ECC step
The following ECC strength and step size are currently supported:
- nand-ecc-strength = <1>, nand-ecc-step-size = <512>
- nand-ecc-strength = <4>, nand-ecc-step-size = <512>
- nand-ecc-strength = <8>, nand-ecc-step-size = <512>
Example:

17
Documentation/devicetree/bindings/net/amd-xgbe-phy.txt Normal file
View File

@ -0,0 +1,17 @@
* AMD 10GbE PHY driver (amd-xgbe-phy)
Required properties:
- compatible: Should be "amd,xgbe-phy-seattle-v1a" and
"ethernet-phy-ieee802.3-c45"
- reg: Address and length of the register sets for the device
- SerDes Rx/Tx registers
- SerDes integration registers (1/2)
- SerDes integration registers (2/2)
Example:
xgbe_phy@e1240800 {
compatible = "amd,xgbe-phy-seattle-v1a", "ethernet-phy-ieee802.3-c45";
reg = <0 0xe1240800 0 0x00400>,
<0 0xe1250000 0 0x00060>,
<0 0xe1250080 0 0x00004>;
};

34
Documentation/devicetree/bindings/net/amd-xgbe.txt Normal file
View File

@ -0,0 +1,34 @@
* AMD 10GbE driver (amd-xgbe)
Required properties:
- compatible: Should be "amd,xgbe-seattle-v1a"
- reg: Address and length of the register sets for the device
- MAC registers
- PCS registers
- interrupt-parent: Should be the phandle for the interrupt controller
that services interrupts for this device
- interrupts: Should contain the amd-xgbe interrupt
- clocks: Should be the DMA clock for the amd-xgbe device (used for
calculating the correct Rx interrupt watchdog timer value on a DMA
channel for coalescing)
- clock-names: Should be the name of the DMA clock, "dma_clk"
- phy-handle: See ethernet.txt file in the same directory
- phy-mode: See ethernet.txt file in the same directory
Optional properties:
- mac-address: mac address to be assigned to the device. Can be overridden
by UEFI.
Example:
xgbe@e0700000 {
compatible = "amd,xgbe-seattle-v1a";
reg = <0 0xe0700000 0 0x80000>,
<0 0xe0780000 0 0x80000>;
interrupt-parent = <&gic>;
interrupts = <0 325 4>;
clocks = <&xgbe_clk>;
clock-names = "dma_clk";
phy-handle = <&phy>;
phy-mode = "xgmii";
mac-address = [ 02 a1 a2 a3 a4 a5 ];
};

2
Documentation/devicetree/bindings/net/broadcom-bcmgenet.txt
View File

@ -24,7 +24,7 @@ Optional properties:
- fixed-link: When the GENET interface is connected to a MoCA hardware block or
when operating in a RGMII to RGMII type of connection, or when the MDIO bus is
voluntarily disabled, this property should be used to describe the "fixed link".
See Documentation/devicetree/bindings/net/fsl-tsec-phy.txt for information on
See Documentation/devicetree/bindings/net/fixed-link.txt for information on
the property specifics
Required child nodes:

29
Documentation/devicetree/bindings/net/broadcom-systemport.txt Normal file
View File

@ -0,0 +1,29 @@
* Broadcom BCM7xxx Ethernet Systemport Controller (SYSTEMPORT)
Required properties:
- compatible: should be one of "brcm,systemport-v1.00" or "brcm,systemport"
- reg: address and length of the register set for the device.
- interrupts: interrupts for the device, first cell must be for the the rx
interrupts, and the second cell should be for the transmit queues
- local-mac-address: Ethernet MAC address (48 bits) of this adapter
- phy-mode: Should be a string describing the PHY interface to the
Ethernet switch/PHY, see Documentation/devicetree/bindings/net/ethernet.txt
- fixed-link: see Documentation/devicetree/bindings/net/fixed-link.txt for
the property specific details
Optional properties:
- systemport,num-tier2-arb: number of tier 2 arbiters, an integer
- systemport,num-tier1-arb: number of tier 1 arbiters, an integer
- systemport,num-txq: number of HW transmit queues, an integer
- systemport,num-rxq: number of HW receive queues, an integer
Example:
ethernet@f04a0000 {
compatible = "brcm,systemport-v1.00";
reg = <0xf04a0000 0x4650>;
local-mac-address = [ 00 11 22 33 44 55 ];
fixed-link = <0 1 1000 0 0>;
phy-mode = "gmii";
interrupts = <0x0 0x16 0x0>,
<0x0 0x17 0x0>;
};

44
Documentation/devicetree/bindings/net/can/xilinx_can.txt Normal file
View File

@ -0,0 +1,44 @@
Xilinx Axi CAN/Zynq CANPS controller Device Tree Bindings
---------------------------------------------------------
Required properties:
- compatible : Should be "xlnx,zynq-can-1.0" for Zynq CAN
controllers and "xlnx,axi-can-1.00.a" for Axi CAN
controllers.
- reg : Physical base address and size of the Axi CAN/Zynq
CANPS registers map.
- interrupts : Property with a value describing the interrupt
number.
- interrupt-parent : Must be core interrupt controller
- clock-names : List of input clock names - "can_clk", "pclk"
(For CANPS), "can_clk" , "s_axi_aclk"(For AXI CAN)
(See clock bindings for details).
- clocks : Clock phandles (see clock bindings for details).
- tx-fifo-depth : Can Tx fifo depth.
- rx-fifo-depth : Can Rx fifo depth.
Example:
For Zynq CANPS Dts file:
zynq_can_0: can@e0008000 {
compatible = "xlnx,zynq-can-1.0";
clocks = <&clkc 19>, <&clkc 36>;
clock-names = "can_clk", "pclk";
reg = <0xe0008000 0x1000>;
interrupts = <0 28 4>;
interrupt-parent = <&intc>;
tx-fifo-depth = <0x40>;
rx-fifo-depth = <0x40>;
};
For Axi CAN Dts file:
axi_can_0: axi-can@40000000 {
compatible = "xlnx,axi-can-1.00.a";
clocks = <&clkc 0>, <&clkc 1>;
clock-names = "can_clk","s_axi_aclk" ;
reg = <0x40000000 0x10000>;
interrupt-parent = <&intc>;
interrupts = <0 59 1>;
tx-fifo-depth = <0x40>;
rx-fifo-depth = <0x40>;
};

4
Documentation/devicetree/bindings/net/cpsw-phy-sel.txt
View File

@ -2,7 +2,9 @@ TI CPSW Phy mode Selection Device Tree Bindings
-----------------------------------------------
Required properties:
- compatible : Should be "ti,am3352-cpsw-phy-sel"
- compatible : Should be "ti,am3352-cpsw-phy-sel" for am335x platform and
"ti,dra7xx-cpsw-phy-sel" for dra7xx platform
"ti,am43xx-cpsw-phy-sel" for am43xx platform
- reg : physical base address and size of the cpsw
registers map
- reg-names : names of the register map given in "reg" node

42
Documentation/devicetree/bindings/net/fixed-link.txt Normal file
View File

@ -0,0 +1,42 @@
Fixed link Device Tree binding
------------------------------
Some Ethernet MACs have a "fixed link", and are not connected to a
normal MDIO-managed PHY device. For those situations, a Device Tree
binding allows to describe a "fixed link".
Such a fixed link situation is described by creating a 'fixed-link'
sub-node of the Ethernet MAC device node, with the following
properties:
* 'speed' (integer, mandatory), to indicate the link speed. Accepted
values are 10, 100 and 1000
* 'full-duplex' (boolean, optional), to indicate that full duplex is
used. When absent, half duplex is assumed.
* 'pause' (boolean, optional), to indicate that pause should be
enabled.
* 'asym-pause' (boolean, optional), to indicate that asym_pause should
be enabled.
Old, deprecated 'fixed-link' binding:
* A 'fixed-link' property in the Ethernet MAC node, with 5 cells, of the
form <a b c d e> with the following accepted values:
- a: emulated PHY ID, choose any but but unique to the all specified
fixed-links, from 0 to 31
- b: duplex configuration: 0 for half duplex, 1 for full duplex
- c: link speed in Mbits/sec, accepted values are: 10, 100 and 1000
- d: pause configuration: 0 for no pause, 1 for pause
- e: asymmetric pause configuration: 0 for no asymmetric pause, 1 for
asymmetric pause
Example:
ethernet@0 {
...
fixed-link {
speed = <1000>;
full-duplex;
};
...
};

5
Documentation/devicetree/bindings/net/fsl-tsec-phy.txt
View File

@ -42,10 +42,7 @@ Properties:
interrupt. For TSEC and eTSEC devices, the first interrupt is
transmit, the second is receive, and the third is error.
- phy-handle : See ethernet.txt file in the same directory.
- fixed-link : <a b c d e> where a is emulated phy id - choose any,
but unique to the all specified fixed-links, b is duplex - 0 half,
1 full, c is link speed - d#10/d#100/d#1000, d is pause - 0 no
pause, 1 pause, e is asym_pause - 0 no asym_pause, 1 asym_pause.
- fixed-link : See fixed-link.txt in the same directory.
- phy-connection-type : See ethernet.txt file in the same directory.
This property is only really needed if the connection is of type
"rgmii-id", as all other connection types are detected by hardware.

36
Documentation/devicetree/bindings/net/hisilicon-hix5hd2-gmac.txt Normal file
View File

@ -0,0 +1,36 @@
Hisilicon hix5hd2 gmac controller
Required properties:
- compatible: should be "hisilicon,hix5hd2-gmac".
- reg: specifies base physical address(s) and size of the device registers.
The first region is the MAC register base and size.
The second region is external interface control register.
- interrupts: should contain the MAC interrupt.
- #address-cells: must be <1>.
- #size-cells: must be <0>.
- phy-mode: see ethernet.txt [1].
- phy-handle: see ethernet.txt [1].
- mac-address: see ethernet.txt [1].
- clocks: clock phandle and specifier pair.
- PHY subnode: inherits from phy binding [2]
[1] Documentation/devicetree/bindings/net/ethernet.txt
[2] Documentation/devicetree/bindings/net/phy.txt
Example:
gmac0: ethernet@f9840000 {
compatible = "hisilicon,hix5hd2-gmac";
reg = <0xf9840000 0x1000>,<0xf984300c 0x4>;
interrupts = <0 71 4>;
#address-cells = <1>;
#size-cells = <0>;
phy-mode = "mii";
phy-handle = <&phy2>;
mac-address = [00 00 00 00 00 00];
clocks = <&clock HIX5HD2_MAC0_CLK>;
phy2: ethernet-phy@2 {
reg = <2>;
};
};

23
Documentation/devicetree/bindings/net/ieee802154/at86rf230.txt Normal file
View File

@ -0,0 +1,23 @@
* AT86RF230 IEEE 802.15.4 *
Required properties:
- compatible: should be "atmel,at86rf230", "atmel,at86rf231",
"atmel,at86rf233" or "atmel,at86rf212"
- spi-max-frequency: maximal bus speed, should be set to 7500000 depends
sync or async operation mode
- reg: the chipselect index
- interrupts: the interrupt generated by the device
Optional properties:
- reset-gpio: GPIO spec for the rstn pin
- sleep-gpio: GPIO spec for the slp_tr pin
Example:
at86rf231@0 {
compatible = "atmel,at86rf231";
spi-max-frequency = <7500000>;
reg = <0>;
interrupts = <19 1>;
interrupt-parent = <&gpio3>;
};

15
Documentation/devicetree/bindings/net/micrel-ks8851.txt
View File

@ -1,9 +1,18 @@
Micrel KS8851 Ethernet mac
Micrel KS8851 Ethernet mac (MLL)
Required properties:
- compatible = "micrel,ks8851-ml" of parallel interface
- compatible = "micrel,ks8851-mll" of parallel interface
- reg : 2 physical address and size of registers for data and command
- interrupts : interrupt connection
Micrel KS8851 Ethernet mac (SPI)
Required properties:
- compatible = "micrel,ks8851" or the deprecated "ks8851"
- reg : chip select number
- interrupts : interrupt connection
Optional properties:
- vdd-supply: supply for Ethernet mac
- vdd-supply: analog 3.3V supply for Ethernet mac
- vdd-io-supply: digital 1.8V IO supply for Ethernet mac
- reset-gpios: reset_n input pin

49
Documentation/devicetree/bindings/net/micrel-ksz9021.txt
View File

@ -1,49 +0,0 @@
Micrel KSZ9021 Gigabit Ethernet PHY
Some boards require special tuning values, particularly when it comes to
clock delays. You can specify clock delay values by adding
micrel-specific properties to an Ethernet OF device node.
All skew control options are specified in picoseconds. The minimum
value is 0, and the maximum value is 3000.
Optional properties:
- rxc-skew-ps : Skew control of RXC pad
- rxdv-skew-ps : Skew control of RX CTL pad
- txc-skew-ps : Skew control of TXC pad
- txen-skew-ps : Skew control of TX_CTL pad
- rxd0-skew-ps : Skew control of RX data 0 pad
- rxd1-skew-ps : Skew control of RX data 1 pad
- rxd2-skew-ps : Skew control of RX data 2 pad
- rxd3-skew-ps : Skew control of RX data 3 pad
- txd0-skew-ps : Skew control of TX data 0 pad
- txd1-skew-ps : Skew control of TX data 1 pad
- txd2-skew-ps : Skew control of TX data 2 pad
- txd3-skew-ps : Skew control of TX data 3 pad
Examples:
/* Attach to an Ethernet device with autodetected PHY */
&enet {
rxc-skew-ps = <3000>;
rxdv-skew-ps = <0>;
txc-skew-ps = <3000>;
txen-skew-ps = <0>;
status = "okay";
};
/* Attach to an explicitly-specified PHY */
mdio {
phy0: ethernet-phy@0 {
rxc-skew-ps = <3000>;
rxdv-skew-ps = <0>;
txc-skew-ps = <3000>;
txen-skew-ps = <0>;
reg = <0>;
};
};
ethernet@70000 {
status = "okay";
phy = <&phy0>;
phy-mode = "rgmii-id";
};

83
Documentation/devicetree/bindings/net/micrel-ksz90x1.txt Normal file
View File

@ -0,0 +1,83 @@
Micrel KSZ9021/KSZ9031 Gigabit Ethernet PHY
Some boards require special tuning values, particularly when it comes to
clock delays. You can specify clock delay values by adding
micrel-specific properties to an Ethernet OF device node.
Note that these settings are applied after any phy-specific fixup from
phy_fixup_list (see phy_init_hw() from drivers/net/phy/phy_device.c),
and therefore may overwrite them.
KSZ9021:
All skew control options are specified in picoseconds. The minimum
value is 0, the maximum value is 3000, and it is incremented by 200ps
steps.
Optional properties:
- rxc-skew-ps : Skew control of RXC pad
- rxdv-skew-ps : Skew control of RX CTL pad
- txc-skew-ps : Skew control of TXC pad
- txen-skew-ps : Skew control of TX CTL pad
- rxd0-skew-ps : Skew control of RX data 0 pad
- rxd1-skew-ps : Skew control of RX data 1 pad
- rxd2-skew-ps : Skew control of RX data 2 pad
- rxd3-skew-ps : Skew control of RX data 3 pad
- txd0-skew-ps : Skew control of TX data 0 pad
- txd1-skew-ps : Skew control of TX data 1 pad
- txd2-skew-ps : Skew control of TX data 2 pad
- txd3-skew-ps : Skew control of TX data 3 pad
KSZ9031:
All skew control options are specified in picoseconds. The minimum
value is 0, and the maximum is property-dependent. The increment
step is 60ps.
Optional properties:
Maximum value of 1860:
- rxc-skew-ps : Skew control of RX clock pad
- txc-skew-ps : Skew control of TX clock pad
Maximum value of 900:
- rxdv-skew-ps : Skew control of RX CTL pad
- txen-skew-ps : Skew control of TX CTL pad
- rxd0-skew-ps : Skew control of RX data 0 pad
- rxd1-skew-ps : Skew control of RX data 1 pad
- rxd2-skew-ps : Skew control of RX data 2 pad
- rxd3-skew-ps : Skew control of RX data 3 pad
- txd0-skew-ps : Skew control of TX data 0 pad
- txd1-skew-ps : Skew control of TX data 1 pad
- txd2-skew-ps : Skew control of TX data 2 pad
- txd3-skew-ps : Skew control of TX data 3 pad
Examples:
/* Attach to an Ethernet device with autodetected PHY */
&enet {
rxc-skew-ps = <3000>;
rxdv-skew-ps = <0>;
txc-skew-ps = <3000>;
txen-skew-ps = <0>;
status = "okay";
};
/* Attach to an explicitly-specified PHY */
mdio {
phy0: ethernet-phy@0 {
rxc-skew-ps = <3000>;
rxdv-skew-ps = <0>;
txc-skew-ps = <3000>;
txen-skew-ps = <0>;
reg = <0>;
};
};
ethernet@70000 {
status = "okay";
phy = <&phy0>;
phy-mode = "rgmii-id";
};

35
Documentation/devicetree/bindings/net/nfc/pn544.txt Normal file
View File

@ -0,0 +1,35 @@
* NXP Semiconductors PN544 NFC Controller
Required properties:
- compatible: Should be "nxp,pn544-i2c".
- clock-frequency: I²C work frequency.
- reg: address on the bus
- interrupt-parent: phandle for the interrupt gpio controller
- interrupts: GPIO interrupt to which the chip is connected
- enable-gpios: Output GPIO pin used for enabling/disabling the PN544
- firmware-gpios: Output GPIO pin used to enter firmware download mode
Optional SoC Specific Properties:
- pinctrl-names: Contains only one value - "default".
- pintctrl-0: Specifies the pin control groups used for this controller.
Example (for ARM-based BeagleBone with PN544 on I2C2):
&i2c2 {
status = "okay";
pn544: pn544@28 {
compatible = "nxp,pn544-i2c";
reg = <0x28>;
clock-frequency = <400000>;
interrupt-parent = <&gpio1>;
interrupts = <17 GPIO_ACTIVE_HIGH>;
enable-gpios = <&gpio3 21 GPIO_ACTIVE_HIGH>;
firmware-gpios = <&gpio3 19 GPIO_ACTIVE_HIGH>;
};
};

33
Documentation/devicetree/bindings/net/nfc/st21nfca.txt Normal file
View File

@ -0,0 +1,33 @@
* STMicroelectronics SAS. ST21NFCA NFC Controller
Required properties:
- compatible: Should be "st,st21nfca_i2c".
- clock-frequency: I²C work frequency.
- reg: address on the bus
- interrupt-parent: phandle for the interrupt gpio controller
- interrupts: GPIO interrupt to which the chip is connected
- enable-gpios: Output GPIO pin used for enabling/disabling the ST21NFCA
Optional SoC Specific Properties:
- pinctrl-names: Contains only one value - "default".
- pintctrl-0: Specifies the pin control groups used for this controller.
Example (for ARM-based BeagleBoard xM with ST21NFCA on I2C2):
&i2c2 {
status = "okay";
st21nfca: st21nfca@1 {
compatible = "st,st21nfca_i2c";
reg = <0x01>;
clock-frequency = <400000>;
interrupt-parent = <&gpio5>;
interrupts = <2 IRQ_TYPE_LEVEL_LOW>;
enable-gpios = <&gpio5 29 GPIO_ACTIVE_HIGH>;
};
};

2
Documentation/devicetree/bindings/net/nfc/trf7970a.txt
View File

@ -12,6 +12,7 @@ Required properties:
Optional SoC Specific Properties:
- pinctrl-names: Contains only one value - "default".
- pintctrl-0: Specifies the pin control groups used for this controller.
- autosuspend-delay: Specify autosuspend delay in milliseconds.
Example (for ARM-based BeagleBone with TRF7970A on SPI1):
@ -29,6 +30,7 @@ Example (for ARM-based BeagleBone with TRF7970A on SPI1):
ti,enable-gpios = <&gpio2 2 GPIO_ACTIVE_LOW>,
<&gpio2 5 GPIO_ACTIVE_LOW>;
vin-supply = <&ldo3_reg>;
autosuspend-delay = <30000>;
status = "okay";
};
};

17
Documentation/devicetree/bindings/net/via-rhine.txt Normal file
View File

@ -0,0 +1,17 @@
* VIA Rhine 10/100 Network Controller
Required properties:
- compatible : Should be "via,vt8500-rhine" for integrated
Rhine controllers found in VIA VT8500, WonderMedia WM8950
and similar. These are listed as 1106:3106 rev. 0x84 on the
virtual PCI bus under vendor-provided kernels
- reg : Address and length of the io space
- interrupts : Should contain the controller interrupt line
Examples:
ethernet@d8004000 {
compatible = "via,vt8500-rhine";
reg = <0xd8004000 0x100>;
interrupts = <10>;
};

7
Documentation/devicetree/bindings/panel/auo,b133xtn01.txt Normal file
View File

@ -0,0 +1,7 @@
AU Optronics Corporation 13.3" WXGA (1366x768) TFT LCD panel
Required properties:
- compatible: should be "auo,b133xtn01"
This binding is compatible with the simple-panel binding, which is specified
in simple-panel.txt in this directory.

7
Documentation/devicetree/bindings/panel/edt,et057090dhu.txt Normal file
View File

@ -0,0 +1,7 @@
Emerging Display Technology Corp. 5.7" VGA TFT LCD panel
Required properties:
- compatible: should be "edt,et057090dhu"
This binding is compatible with the simple-panel binding, which is specified
in simple-panel.txt in this directory.

10
Documentation/devicetree/bindings/panel/edt,et070080dh6.txt Normal file
View File

@ -0,0 +1,10 @@
Emerging Display Technology Corp. ET070080DH6 7.0" WVGA TFT LCD panel
Required properties:
- compatible: should be "edt,et070080dh6"
This panel is the same as ETM0700G0DH6 except for the touchscreen.
ET070080DH6 is the model with resistive touch.
This binding is compatible with the simple-panel binding, which is specified
in simple-panel.txt in this directory.

10
Documentation/devicetree/bindings/panel/edt,etm0700g0dh6.txt Normal file
View File

@ -0,0 +1,10 @@
Emerging Display Technology Corp. ETM0700G0DH6 7.0" WVGA TFT LCD panel
Required properties:
- compatible: should be "edt,etm0700g0dh6"
This panel is the same as ET070080DH6 except for the touchscreen.
ETM0700G0DH6 is the model with capacitive multitouch.
This binding is compatible with the simple-panel binding, which is specified
in simple-panel.txt in this directory.

74
Documentation/devicetree/bindings/pci/designware-pcie.txt
View File

@ -1,15 +1,7 @@
* Synopsys Designware PCIe interface
Required properties:
- compatible: should contain "snps,dw-pcie" to identify the
core, plus an identifier for the specific instance, such
as "samsung,exynos5440-pcie" or "fsl,imx6q-pcie".
- reg: base addresses and lengths of the pcie controller,
the phy controller, additional register for the phy controller.
- interrupts: interrupt values for level interrupt,
pulse interrupt, special interrupt.
- clocks: from common clock binding: handle to pci clock.
- clock-names: from common clock binding: should be "pcie" and "pcie_bus".
- compatible: should contain "snps,dw-pcie" to identify the core.
- #address-cells: set to <3>
- #size-cells: set to <2>
- device_type: set to "pci"
@ -19,65 +11,11 @@ Required properties:
to define the mapping of the PCIe interface to interrupt
numbers.
- num-lanes: number of lanes to use
- clocks: Must contain an entry for each entry in clock-names.
See ../clocks/clock-bindings.txt for details.
- clock-names: Must include the following entries:
- "pcie"
- "pcie_bus"
Optional properties:
- reset-gpio: gpio pin number of power good signal
Optional properties for fsl,imx6q-pcie
- power-on-gpio: gpio pin number of power-enable signal
- wake-up-gpio: gpio pin number of incoming wakeup signal
- disable-gpio: gpio pin number of outgoing rfkill/endpoint disable signal
Example:
SoC specific DT Entry:
pcie@290000 {
compatible = "samsung,exynos5440-pcie", "snps,dw-pcie";
reg = <0x290000 0x1000
0x270000 0x1000
0x271000 0x40>;
interrupts = <0 20 0>, <0 21 0>, <0 22 0>;
clocks = <&clock 28>, <&clock 27>;
clock-names = "pcie", "pcie_bus";
#address-cells = <3>;
#size-cells = <2>;
device_type = "pci";
ranges = <0x00000800 0 0x40000000 0x40000000 0 0x00001000 /* configuration space */
0x81000000 0 0 0x40001000 0 0x00010000 /* downstream I/O */
0x82000000 0 0x40011000 0x40011000 0 0x1ffef000>; /* non-prefetchable memory */
#interrupt-cells = <1>;
interrupt-map-mask = <0 0 0 0>;
interrupt-map = <0x0 0 &gic 53>;
num-lanes = <4>;
};
pcie@2a0000 {
compatible = "samsung,exynos5440-pcie", "snps,dw-pcie";
reg = <0x2a0000 0x1000
0x272000 0x1000
0x271040 0x40>;
interrupts = <0 23 0>, <0 24 0>, <0 25 0>;
clocks = <&clock 29>, <&clock 27>;
clock-names = "pcie", "pcie_bus";
#address-cells = <3>;
#size-cells = <2>;
device_type = "pci";
ranges = <0x00000800 0 0x60000000 0x60000000 0 0x00001000 /* configuration space */
0x81000000 0 0 0x60001000 0 0x00010000 /* downstream I/O */
0x82000000 0 0x60011000 0x60011000 0 0x1ffef000>; /* non-prefetchable memory */
#interrupt-cells = <1>;
interrupt-map-mask = <0 0 0 0>;
interrupt-map = <0x0 0 &gic 56>;
num-lanes = <4>;
};
Board specific DT Entry:
pcie@290000 {
reset-gpio = <&pin_ctrl 5 0>;
};
pcie@2a0000 {
reset-gpio = <&pin_ctrl 22 0>;
};

38
Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.txt Normal file
View File

@ -0,0 +1,38 @@
* Freescale i.MX6 PCIe interface
This PCIe host controller is based on the Synopsis Designware PCIe IP
and thus inherits all the common properties defined in designware-pcie.txt.
Required properties:
- compatible: "fsl,imx6q-pcie"
- reg: base addresse and length of the pcie controller
- interrupts: A list of interrupt outputs of the controller. Must contain an
entry for each entry in the interrupt-names property.
- interrupt-names: Must include the following entries:
- "msi": The interrupt that is asserted when an MSI is received
- clock-names: Must include the following additional entries:
- "pcie_phy"
Example:
pcie@0x01000000 {
compatible = "fsl,imx6q-pcie", "snps,dw-pcie";
reg = <0x01ffc000 0x4000>;
#address-cells = <3>;
#size-cells = <2>;
device_type = "pci";
ranges = <0x00000800 0 0x01f00000 0x01f00000 0 0x00080000
0x81000000 0 0 0x01f80000 0 0x00010000
0x82000000 0 0x01000000 0x01000000 0 0x00f00000>;
num-lanes = <1>;
interrupts = <GIC_SPI 120 IRQ_TYPE_LEVEL_HIGH>;
interrupt-names = "msi";
#interrupt-cells = <1>;
interrupt-map-mask = <0 0 0 0x7>;
interrupt-map = <0 0 0 1 &intc GIC_SPI 123 IRQ_TYPE_LEVEL_HIGH>,
<0 0 0 2 &intc GIC_SPI 122 IRQ_TYPE_LEVEL_HIGH>,
<0 0 0 3 &intc GIC_SPI 121 IRQ_TYPE_LEVEL_HIGH>,
<0 0 0 4 &intc GIC_SPI 120 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&clks 144>, <&clks 206>, <&clks 189>;
clock-names = "pcie", "pcie_bus", "pcie_phy";
};

65
Documentation/devicetree/bindings/pci/samsung,exynos5440-pcie.txt Normal file
View File

@ -0,0 +1,65 @@
* Samsung Exynos 5440 PCIe interface
This PCIe host controller is based on the Synopsis Designware PCIe IP
and thus inherits all the common properties defined in designware-pcie.txt.
Required properties:
- compatible: "samsung,exynos5440-pcie"
- reg: base addresses and lengths of the pcie controller,
the phy controller, additional register for the phy controller.
- interrupts: A list of interrupt outputs for level interrupt,
pulse interrupt, special interrupt.
Example:
SoC specific DT Entry:
pcie@290000 {
compatible = "samsung,exynos5440-pcie", "snps,dw-pcie";
reg = <0x290000 0x1000
0x270000 0x1000
0x271000 0x40>;
interrupts = <0 20 0>, <0 21 0>, <0 22 0>;
clocks = <&clock 28>, <&clock 27>;
clock-names = "pcie", "pcie_bus";
#address-cells = <3>;
#size-cells = <2>;
device_type = "pci";
ranges = <0x00000800 0 0x40000000 0x40000000 0 0x00001000 /* configuration space */
0x81000000 0 0 0x40001000 0 0x00010000 /* downstream I/O */
0x82000000 0 0x40011000 0x40011000 0 0x1ffef000>; /* non-prefetchable memory */
#interrupt-cells = <1>;
interrupt-map-mask = <0 0 0 0>;
interrupt-map = <0 0 0 0 &gic GIC_SPI 21 IRQ_TYPE_LEVEL_HIGH>;
num-lanes = <4>;
};
pcie@2a0000 {
compatible = "samsung,exynos5440-pcie", "snps,dw-pcie";
reg = <0x2a0000 0x1000
0x272000 0x1000
0x271040 0x40>;
interrupts = <0 23 0>, <0 24 0>, <0 25 0>;
clocks = <&clock 29>, <&clock 27>;
clock-names = "pcie", "pcie_bus";
#address-cells = <3>;
#size-cells = <2>;
device_type = "pci";
ranges = <0x00000800 0 0x60000000 0x60000000 0 0x00001000 /* configuration space */
0x81000000 0 0 0x60001000 0 0x00010000 /* downstream I/O */
0x82000000 0 0x60011000 0x60011000 0 0x1ffef000>; /* non-prefetchable memory */
#interrupt-cells = <1>;
interrupt-map-mask = <0 0 0 0>;
interrupt-map = <0 0 0 0 &gic GIC_SPI 24 IRQ_TYPE_LEVEL_HIGH>;
num-lanes = <4>;
};
Board specific DT Entry:
pcie@290000 {
reset-gpio = <&pin_ctrl 5 0>;
};
pcie@2a0000 {
reset-gpio = <&pin_ctrl 22 0>;
};

54
Documentation/devicetree/bindings/powerpc/4xx/akebono.txt Normal file
View File

@ -0,0 +1,54 @@
IBM Akebono board device tree
=============================
The IBM Akebono board is a development board for the PPC476GTR SoC.
0) The root node
Required properties:
- model : "ibm,akebono".
- compatible : "ibm,akebono" , "ibm,476gtr".
1.a) The Secure Digital Host Controller Interface (SDHCI) node
Represent the Secure Digital Host Controller Interfaces.
Required properties:
- compatible : should be "ibm,476gtr-sdhci","generic-sdhci".
- reg : should contain the SDHCI registers location and length.
- interrupt-parent : a phandle for the interrupt controller.
- interrupts : should contain the SDHCI interrupt.
1.b) The Advanced Host Controller Interface (AHCI) SATA node
Represents the advanced host controller SATA interface.
Required properties:
- compatible : should be "ibm,476gtr-ahci".
- reg : should contain the AHCI registers location and length.
- interrupt-parent : a phandle for the interrupt controller.
- interrupts : should contain the AHCI interrupt.
1.c) The FPGA node
The Akebono board stores some board information such as the revision
number in an FPGA which is represented by this node.
Required properties:
- compatible : should be "ibm,akebono-fpga".
- reg : should contain the FPGA registers location and length.
1.d) The AVR node
The Akebono board has an Atmel AVR microprocessor attached to the I2C
bus as a power controller for the board.
Required properties:
- compatible : should be "ibm,akebono-avr".
- reg : should contain the I2C bus address for the AVR.

19
Documentation/devicetree/bindings/powerpc/4xx/hsta.txt Normal file
View File

@ -0,0 +1,19 @@
ppc476gtr High Speed Serial Assist (HSTA) node
==============================================
The 476gtr SoC contains a high speed serial assist module attached
between the plb4 and plb6 system buses to provide high speed data
transfer between memory and system peripherals as well as support for
PCI message signalled interrupts.
Currently only the MSI support is used by Linux using the following
device tree entries:
Require properties:
- compatible : "ibm,476gtr-hsta-msi", "ibm,hsta-msi"
- reg : register mapping for the HSTA MSI space
- interrupt-parent : parent controller for mapping interrupts
- interrupts : ordered interrupt mapping for each MSI in the register
space. The first interrupt should be associated with a
register offset of 0x00, the second to 0x10, etc.

17
Documentation/devicetree/bindings/powerpc/fsl/board.txt
View File

@ -67,3 +67,20 @@ Example:
gpio-controller;
};
};
* Freescale on-board FPGA connected on I2C bus
Some Freescale boards like BSC9132QDS have on board FPGA connected on
the i2c bus.
Required properties:
- compatible: Should be a board-specific string followed by a string
indicating the type of FPGA. Example:
"fsl,<board>-fpga", "fsl,fpga-qixis-i2c"
- reg: Should contain the address of the FPGA
Example:
fpga: fpga@66 {
compatible = "fsl,bsc9132qds-fpga", "fsl,fpga-qixis-i2c";
reg = <0x66>;
};

46
Documentation/devicetree/bindings/powerpc/fsl/ccf.txt Normal file
View File

@ -0,0 +1,46 @@
Freescale CoreNet Coherency Fabric(CCF) Device Tree Binding
DESCRIPTION
The CoreNet coherency fabric is a fabric-oriented, connectivity infrastructure
that enables the implementation of coherent, multicore systems.
Required properties:
- compatible: <string list>
fsl,corenet1-cf - CoreNet coherency fabric version 1.
Example chips: T4240, B4860
fsl,corenet2-cf - CoreNet coherency fabric version 2.
Example chips: P5040, P5020, P4080, P3041, P2041
fsl,corenet-cf - Used to represent the common registers
between CCF version 1 and CCF version 2. This compatible
is retained for compatibility reasons, as it was already
used for both CCF version 1 chips and CCF version 2
chips. It should be specified after either
"fsl,corenet1-cf" or "fsl,corenet2-cf".
- reg: <prop-encoded-array>
A standard property. Represents the CCF registers.
- interrupts: <prop-encoded-array>
Interrupt mapping for CCF error interrupt.
- fsl,ccf-num-csdids: <u32>
Specifies the number of Coherency Subdomain ID Port Mapping
Registers that are supported by the CCF.
- fsl,ccf-num-snoopids: <u32>
Specifies the number of Snoop ID Port Mapping Registers that
are supported by CCF.
Example:
corenet-cf@18000 {
compatible = "fsl,corenet2-cf", "fsl,corenet-cf";
reg = <0x18000 0x1000>;
interrupts = <16 2 1 31>;
fsl,ccf-num-csdids = <32>;
fsl,ccf-num-snoopids = <32>;
};

11
Documentation/devicetree/bindings/powerpc/fsl/cpus.txt
View File

@ -20,3 +20,14 @@ PROPERTIES
a property named fsl,eref-[CAT], where [CAT] is the abbreviated category
name with all uppercase letters converted to lowercase, indicates that
the category is supported by the implementation.
- fsl,portid-mapping
Usage: optional
Value type: <u32>
Definition: The Coherency Subdomain ID Port Mapping Registers and
Snoop ID Port Mapping registers, which are part of the CoreNet
Coherency fabric (CCF), provide a CoreNet Coherency Subdomain
ID/CoreNet Snoop ID to cpu mapping functions. Certain bits from
these registers should be set if the coresponding CPU should be
snooped. This property defines a bitmask which selects the bit
that should be set if this cpu should be snooped.

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