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

Merge branch 'sched/urgent' into sched/core

Browse source 
Merge in the latest fixes before applying a dependent patch.

Signed-off-by: Ingo Molnar <mingo@kernel.org>
This commit is contained in:
Ingo Molnar 2013-09-20 12:00:42 +02:00
parent c61037e905 7e3115ef51
commit 40a0c68ca9
5664 changed files with 331694 additions and 149493 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

12
CREDITS
View file

@ -637,14 +637,13 @@ S: 14509 NE 39th Street #1096
S: Bellevue, Washington 98007
S: USA
N: Christopher L. Cheney
E: ccheney@debian.org
E: ccheney@cheney.cx
W: http://www.cheney.cx
N: Chris Cheney
E: chris.cheney@gmail.com
E: ccheney@redhat.com
P: 1024D/8E384AF2 2D31 1927 87D7 1F24 9FF9 1BC5 D106 5AB3 8E38 4AF2
D: Vista Imaging usb webcam driver
S: 314 Prince of Wales
S: Conroe, TX 77304
S: 2308 Therrell Way
S: McKinney, TX 75070
S: USA
N: Stuart Cheshire
@ -1120,6 +1119,7 @@ D: author of userfs filesystem
D: Improved mmap and munmap handling
D: General mm minor tidyups
D: autofs v4 maintainer
D: Xen subsystem
S: 987 Alabama St
S: San Francisco
S: CA, 94110

2
Documentation/00-INDEX
View file

@ -40,7 +40,7 @@ IPMI.txt
IRQ-affinity.txt
- how to select which CPU(s) handle which interrupt events on SMP.
IRQ-domain.txt
- info on inerrupt numbering and setting up IRQ domains.
- info on interrupt numbering and setting up IRQ domains.
IRQ.txt
- description of what an IRQ is.
Intel-IOMMU.txt

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

@ -5,20 +5,21 @@ Description:
The disksize file is read-write and specifies the disk size
which represents the limit on the *uncompressed* worth of data
that can be stored in this disk.
Unit: bytes
What: /sys/block/zram<id>/initstate
Date: August 2010
Contact: Nitin Gupta <ngupta@vflare.org>
Description:
The disksize file is read-only and shows the initialization
The initstate file is read-only and shows the initialization
state of the device.
What: /sys/block/zram<id>/reset
Date: August 2010
Contact: Nitin Gupta <ngupta@vflare.org>
Description:
The disksize file is write-only and allows resetting the
device. The reset operation frees all the memory assocaited
The reset file is write-only and allows resetting the
device. The reset operation frees all the memory associated
with this device.
What: /sys/block/zram<id>/num_reads
@ -48,7 +49,7 @@ Contact: Nitin Gupta <ngupta@vflare.org>
Description:
The notify_free file is read-only and specifies the number of
swap slot free notifications received by this device. These
notifications are send to a swap block device when a swap slot
notifications are sent to a swap block device when a swap slot
is freed. This statistic is applicable only when this disk is
being used as a swap disk.

17
Documentation/ABI/testing/sysfs-class-mtd
View file

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

26
Documentation/ABI/testing/sysfs-fs-f2fs Normal file
View file

@ -0,0 +1,26 @@
What: /sys/fs/f2fs/<disk>/gc_max_sleep_time
Date: July 2013
Contact: "Namjae Jeon" <namjae.jeon@samsung.com>
Description:
Controls the maximun sleep time for gc_thread. Time
is in milliseconds.
What: /sys/fs/f2fs/<disk>/gc_min_sleep_time
Date: July 2013
Contact: "Namjae Jeon" <namjae.jeon@samsung.com>
Description:
Controls the minimum sleep time for gc_thread. Time
is in milliseconds.
What: /sys/fs/f2fs/<disk>/gc_no_gc_sleep_time
Date: July 2013
Contact: "Namjae Jeon" <namjae.jeon@samsung.com>
Description:
Controls the default sleep time for gc_thread. Time
is in milliseconds.
What: /sys/fs/f2fs/<disk>/gc_idle
Date: July 2013
Contact: "Namjae Jeon" <namjae.jeon@samsung.com>
Description:
Controls the victim selection policy for garbage collection.

1
Documentation/DocBook/80211.tmpl
View file

@ -325,6 +325,7 @@
<title>functions/definitions</title>
!Finclude/net/mac80211.h ieee80211_rx_status
!Finclude/net/mac80211.h mac80211_rx_flags
!Finclude/net/mac80211.h mac80211_tx_info_flags
!Finclude/net/mac80211.h mac80211_tx_control_flags
!Finclude/net/mac80211.h mac80211_rate_control_flags
!Finclude/net/mac80211.h ieee80211_tx_rate

138
Documentation/DocBook/drm.tmpl
View file

@ -155,13 +155,6 @@
will become a fatal error.
</para></listitem>
</varlistentry>
<varlistentry>
<term>DRIVER_USE_MTRR</term>
<listitem><para>
Driver uses MTRR interface for mapping memory, the DRM core will
manage MTRR resources. Deprecated.
</para></listitem>
</varlistentry>
<varlistentry>
<term>DRIVER_PCI_DMA</term>
<listitem><para>
@ -194,28 +187,6 @@
support shared IRQs (note that this is required of PCI drivers).
</para></listitem>
</varlistentry>
<varlistentry>
<term>DRIVER_IRQ_VBL</term>
<listitem><para>Unused. Deprecated.</para></listitem>
</varlistentry>
<varlistentry>
<term>DRIVER_DMA_QUEUE</term>
<listitem><para>
Should be set if the driver queues DMA requests and completes them
asynchronously. Deprecated.
</para></listitem>
</varlistentry>
<varlistentry>
<term>DRIVER_FB_DMA</term>
<listitem><para>
Driver supports DMA to/from the framebuffer, mapping of frambuffer
DMA buffers to userspace will be supported. Deprecated.
</para></listitem>
</varlistentry>
<varlistentry>
<term>DRIVER_IRQ_VBL2</term>
<listitem><para>Unused. Deprecated.</para></listitem>
</varlistentry>
<varlistentry>
<term>DRIVER_GEM</term>
<listitem><para>
@ -234,6 +205,12 @@
Driver implements DRM PRIME buffer sharing.
</para></listitem>
</varlistentry>
<varlistentry>
<term>DRIVER_RENDER</term>
<listitem><para>
Driver supports dedicated render nodes.
</para></listitem>
</varlistentry>
</variablelist>
</sect3>
<sect3>
@ -2212,6 +2189,18 @@ void intel_crt_init(struct drm_device *dev)
!Iinclude/drm/drm_rect.h
!Edrivers/gpu/drm/drm_rect.c
</sect2>
<sect2>
<title>Flip-work Helper Reference</title>
!Pinclude/drm/drm_flip_work.h flip utils
!Iinclude/drm/drm_flip_work.h
!Edrivers/gpu/drm/drm_flip_work.c
</sect2>
<sect2>
<title>VMA Offset Manager</title>
!Pdrivers/gpu/drm/drm_vma_manager.c vma offset manager
!Edrivers/gpu/drm/drm_vma_manager.c
!Iinclude/drm/drm_vma_manager.h
</sect2>
</sect1>
<!-- Internals: kms properties -->
@ -2422,18 +2411,18 @@ void (*postclose) (struct drm_device *, struct drm_file *);</synopsis>
</abstract>
<para>
The <methodname>firstopen</methodname> method is called by the DRM core
when an application opens a device that has no other opened file handle.
Similarly the <methodname>lastclose</methodname> method is called when
the last application holding a file handle opened on the device closes
it. Both methods are mostly used for UMS (User Mode Setting) drivers to
acquire and release device resources which should be done in the
<methodname>load</methodname> and <methodname>unload</methodname>
methods for KMS drivers.
for legacy UMS (User Mode Setting) drivers only when an application
opens a device that has no other opened file handle. UMS drivers can
implement it to acquire device resources. KMS drivers can't use the
method and must acquire resources in the <methodname>load</methodname>
method instead.
</para>
<para>
Note that the <methodname>lastclose</methodname> method is also called
at module unload time or, for hot-pluggable devices, when the device is
unplugged. The <methodname>firstopen</methodname> and
Similarly the <methodname>lastclose</methodname> method is called when
the last application holding a file handle opened on the device closes
it, for both UMS and KMS drivers. Additionally, the method is also
called at module unload time or, for hot-pluggable devices, when the
device is unplugged. The <methodname>firstopen</methodname> and
<methodname>lastclose</methodname> calls can thus be unbalanced.
</para>
<para>
@ -2462,7 +2451,12 @@ void (*postclose) (struct drm_device *, struct drm_file *);</synopsis>
<para>
The <methodname>lastclose</methodname> method should restore CRTC and
plane properties to default value, so that a subsequent open of the
device will not inherit state from the previous user.
device will not inherit state from the previous user. It can also be
used to execute delayed power switching state changes, e.g. in
conjunction with the vga-switcheroo infrastructure. Beyond that KMS
drivers should not do any further cleanup. Only legacy UMS drivers might
need to clean up device state so that the vga console or an independent
fbdev driver could take over.
</para>
</sect2>
<sect2>
@ -2498,7 +2492,6 @@ void (*postclose) (struct drm_device *, struct drm_file *);</synopsis>
<programlisting>
.poll = drm_poll,
.read = drm_read,
.fasync = drm_fasync,
.llseek = no_llseek,
</programlisting>
</para>
@ -2657,6 +2650,69 @@ int (*resume) (struct drm_device *);</synopsis>
info, since man pages should cover the rest.
</para>
<!-- External: render nodes -->
<sect1>
<title>Render nodes</title>
<para>
DRM core provides multiple character-devices for user-space to use.
Depending on which device is opened, user-space can perform a different
set of operations (mainly ioctls). The primary node is always created
and called <term>card&lt;num&gt;</term>. Additionally, a currently
unused control node, called <term>controlD&lt;num&gt;</term> is also
created. The primary node provides all legacy operations and
historically was the only interface used by userspace. With KMS, the
control node was introduced. However, the planned KMS control interface
has never been written and so the control node stays unused to date.
</para>
<para>
With the increased use of offscreen renderers and GPGPU applications,
clients no longer require running compositors or graphics servers to
make use of a GPU. But the DRM API required unprivileged clients to
authenticate to a DRM-Master prior to getting GPU access. To avoid this
step and to grant clients GPU access without authenticating, render
nodes were introduced. Render nodes solely serve render clients, that
is, no modesetting or privileged ioctls can be issued on render nodes.
Only non-global rendering commands are allowed. If a driver supports
render nodes, it must advertise it via the <term>DRIVER_RENDER</term>
DRM driver capability. If not supported, the primary node must be used
for render clients together with the legacy drmAuth authentication
procedure.
</para>
<para>
If a driver advertises render node support, DRM core will create a
separate render node called <term>renderD&lt;num&gt;</term>. There will
be one render node per device. No ioctls except PRIME-related ioctls
will be allowed on this node. Especially <term>GEM_OPEN</term> will be
explicitly prohibited. Render nodes are designed to avoid the
buffer-leaks, which occur if clients guess the flink names or mmap
offsets on the legacy interface. Additionally to this basic interface,
drivers must mark their driver-dependent render-only ioctls as
<term>DRM_RENDER_ALLOW</term> so render clients can use them. Driver
authors must be careful not to allow any privileged ioctls on render
nodes.
</para>
<para>
With render nodes, user-space can now control access to the render node
via basic file-system access-modes. A running graphics server which
authenticates clients on the privileged primary/legacy node is no longer
required. Instead, a client can open the render node and is immediately
granted GPU access. Communication between clients (or servers) is done
via PRIME. FLINK from render node to legacy node is not supported. New
clients must not use the insecure FLINK interface.
</para>
<para>
Besides dropping all modeset/global ioctls, render nodes also drop the
DRM-Master concept. There is no reason to associate render clients with
a DRM-Master as they are independent of any graphics server. Besides,
they must work without any running master, anyway.
Drivers must be able to run without a master object if they support
render nodes. If, on the other hand, a driver requires shared state
between clients which is visible to user-space and accessible beyond
open-file boundaries, they cannot support render nodes.
</para>
</sect1>
<!-- External: vblank handling -->
<sect1>

168
Documentation/DocBook/media/v4l/controls.xml
View file

@ -722,17 +722,22 @@ for more details.</para>
</section>
<section id="mpeg-controls">
<title>MPEG Control Reference</title>
<title>Codec Control Reference</title>
<para>Below all controls within the MPEG control class are
<para>Below all controls within the Codec control class are
described. First the generic controls, then controls specific for
certain hardware.</para>
<para>Note: These controls are applicable to all codecs and
not just MPEG. The defines are prefixed with V4L2_CID_MPEG/V4L2_MPEG
as the controls were originally made for MPEG codecs and later
extended to cover all encoding formats.</para>
<section>
<title>Generic MPEG Controls</title>
<title>Generic Codec Controls</title>
<table pgwide="1" frame="none" id="mpeg-control-id">
<title>MPEG Control IDs</title>
<title>Codec Control IDs</title>
<tgroup cols="4">
<colspec colname="c1" colwidth="1*" />
<colspec colname="c2" colwidth="6*" />
@ -752,7 +757,7 @@ certain hardware.</para>
<row>
<entry spanname="id"><constant>V4L2_CID_MPEG_CLASS</constant>&nbsp;</entry>
<entry>class</entry>
</row><row><entry spanname="descr">The MPEG class
</row><row><entry spanname="descr">The Codec class
descriptor. Calling &VIDIOC-QUERYCTRL; for this control will return a
description of this control class. This description can be used as the
caption of a Tab page in a GUI, for example.</entry>
@ -3009,6 +3014,159 @@ in by the application. 0 = do not insert, 1 = insert packets.</entry>
</tgroup>
</table>
</section>
<section>
<title>VPX Control Reference</title>
<para>The VPX controls include controls for encoding parameters
of VPx video codec.</para>
<table pgwide="1" frame="none" id="vpx-control-id">
<title>VPX Control IDs</title>
<tgroup cols="4">
<colspec colname="c1" colwidth="1*" />
<colspec colname="c2" colwidth="6*" />
<colspec colname="c3" colwidth="2*" />
<colspec colname="c4" colwidth="6*" />
<spanspec namest="c1" nameend="c2" spanname="id" />
<spanspec namest="c2" nameend="c4" spanname="descr" />
<thead>
<row>
<entry spanname="id" align="left">ID</entry>
<entry align="left">Type</entry>
</row><row rowsep="1"><entry spanname="descr" align="left">Description</entry>
</row>
</thead>
<tbody valign="top">
<row><entry></entry></row>
<row><entry></entry></row>
<row id="v4l2-vpx-num-partitions">
<entry spanname="id"><constant>V4L2_CID_MPEG_VIDEO_VPX_NUM_PARTITIONS</constant></entry>
<entry>enum v4l2_vp8_num_partitions</entry>
</row>
<row><entry spanname="descr">The number of token partitions to use in VP8 encoder.
Possible values are:</entry>
</row>
<row>
<entrytbl spanname="descr" cols="2">
<tbody valign="top">
<row>
<entry><constant>V4L2_CID_MPEG_VIDEO_VPX_1_PARTITION</constant></entry>
<entry>1 coefficient partition</entry>
</row>
<row>
<entry><constant>V4L2_CID_MPEG_VIDEO_VPX_2_PARTITIONS</constant></entry>
<entry>2 coefficient partitions</entry>
</row>
<row>
<entry><constant>V4L2_CID_MPEG_VIDEO_VPX_4_PARTITIONS</constant></entry>
<entry>4 coefficient partitions</entry>
</row>
<row>
<entry><constant>V4L2_CID_MPEG_VIDEO_VPX_8_PARTITIONS</constant></entry>
<entry>8 coefficient partitions</entry>
</row>
</tbody>
</entrytbl>
</row>
<row><entry></entry></row>
<row>
<entry spanname="id"><constant>V4L2_CID_MPEG_VIDEO_VPX_IMD_DISABLE_4X4</constant></entry>
<entry>boolean</entry>
</row>
<row><entry spanname="descr">Setting this prevents intra 4x4 mode in the intra mode decision.</entry>
</row>
<row><entry></entry></row>
<row id="v4l2-vpx-num-ref-frames">
<entry spanname="id"><constant>V4L2_CID_MPEG_VIDEO_VPX_NUM_REF_FRAMES</constant></entry>
<entry>enum v4l2_vp8_num_ref_frames</entry>
</row>
<row><entry spanname="descr">The number of reference pictures for encoding P frames.
Possible values are:</entry>
</row>
<row>
<entrytbl spanname="descr" cols="2">
<tbody valign="top">
<row>
<entry><constant>V4L2_CID_MPEG_VIDEO_VPX_1_REF_FRAME</constant></entry>
<entry>Last encoded frame will be searched</entry>
</row>
<row>
<entry><constant>V4L2_CID_MPEG_VIDEO_VPX_2_REF_FRAME</constant></entry>
<entry>Two frames will be searched among the last encoded frame, the golden frame
and the alternate reference (altref) frame. The encoder implementation will decide which two are chosen.</entry>
</row>
<row>
<entry><constant>V4L2_CID_MPEG_VIDEO_VPX_3_REF_FRAME</constant></entry>
<entry>The last encoded frame, the golden frame and the altref frame will be searched.</entry>
</row>
</tbody>
</entrytbl>
</row>
<row><entry></entry></row>
<row>
<entry spanname="id"><constant>V4L2_CID_MPEG_VIDEO_VPX_FILTER_LEVEL</constant></entry>
<entry>integer</entry>
</row>
<row><entry spanname="descr">Indicates the loop filter level. The adjustment of the loop
filter level is done via a delta value against a baseline loop filter value.</entry>
</row>
<row><entry></entry></row>
<row>
<entry spanname="id"><constant>V4L2_CID_MPEG_VIDEO_VPX_FILTER_SHARPNESS</constant></entry>
<entry>integer</entry>
</row>
<row><entry spanname="descr">This parameter affects the loop filter. Anything above
zero weakens the deblocking effect on the loop filter.</entry>
</row>
<row><entry></entry></row>
<row>
<entry spanname="id"><constant>V4L2_CID_MPEG_VIDEO_VPX_GOLDEN_FRAME_REF_PERIOD</constant></entry>
<entry>integer</entry>
</row>
<row><entry spanname="descr">Sets the refresh period for the golden frame. The period is defined
in number of frames. For a value of 'n', every nth frame starting from the first key frame will be taken as a golden frame.
For eg. for encoding sequence of 0, 1, 2, 3, 4, 5, 6, 7 where the golden frame refresh period is set as 4, the frames
0, 4, 8 etc will be taken as the golden frames as frame 0 is always a key frame.</entry>
</row>
<row><entry></entry></row>
<row id="v4l2-vpx-golden-frame-sel">
<entry spanname="id"><constant>V4L2_CID_MPEG_VIDEO_VPX_GOLDEN_FRAME_SEL</constant></entry>
<entry>enum v4l2_vp8_golden_frame_sel</entry>
</row>
<row><entry spanname="descr">Selects the golden frame for encoding.
Possible values are:</entry>
</row>
<row>
<entrytbl spanname="descr" cols="2">
<tbody valign="top">
<row>
<entry><constant>V4L2_CID_MPEG_VIDEO_VPX_GOLDEN_FRAME_USE_PREV</constant></entry>
<entry>Use the (n-2)th frame as a golden frame, current frame index being 'n'.</entry>
</row>
<row>
<entry><constant>V4L2_CID_MPEG_VIDEO_VPX_GOLDEN_FRAME_USE_REF_PERIOD</constant></entry>
<entry>Use the previous specific frame indicated by
V4L2_CID_MPEG_VIDEO_VPX_GOLDEN_FRAME_REF_PERIOD as a golden frame.</entry>
</row>
</tbody>
</entrytbl>
</row>
<row><entry></entry></row>
</tbody>
</tgroup>
</table>
</section>
</section>
<section id="camera-controls">

4
Documentation/DocBook/media/v4l/lirc_device_interface.xml
View file

@ -46,7 +46,9 @@ describing an IR signal are read from the chardev.</para>
values. Pulses and spaces are only marked implicitly by their position. The
data must start and end with a pulse, therefore, the data must always include
an uneven number of samples. The write function must block until the data has
been transmitted by the hardware.</para>
been transmitted by the hardware. If more data is provided than the hardware
can send, the driver returns EINVAL.</para>
</section>
<section id="lirc_ioctl">

171
Documentation/DocBook/media/v4l/pixfmt-nv16m.xml Normal file
View file

@ -0,0 +1,171 @@
<refentry>
<refmeta>
<refentrytitle>V4L2_PIX_FMT_NV16M ('NM16'), V4L2_PIX_FMT_NV61M ('NM61')</refentrytitle>
&manvol;
</refmeta>
<refnamediv>
<refname id="V4L2-PIX-FMT-NV16M"><constant>V4L2_PIX_FMT_NV16M</constant></refname>
<refname id="V4L2-PIX-FMT-NV61M"><constant>V4L2_PIX_FMT_NV61M</constant></refname>
<refpurpose>Variation of <constant>V4L2_PIX_FMT_NV16</constant> and <constant>V4L2_PIX_FMT_NV61</constant> with planes
non contiguous in memory. </refpurpose>
</refnamediv>
<refsect1>
<title>Description</title>
<para>This is a multi-planar, two-plane version of the YUV 4:2:0 format.
The three components are separated into two sub-images or planes.
<constant>V4L2_PIX_FMT_NV16M</constant> differs from <constant>V4L2_PIX_FMT_NV16
</constant> in that the two planes are non-contiguous in memory, i.e. the chroma
plane does not necessarily immediately follows the luma plane.
The luminance data occupies the first plane. The Y plane has one byte per pixel.
In the second plane there is chrominance data with alternating chroma samples.
The CbCr plane is the same width and height, in bytes, as the Y plane.
Each CbCr pair belongs to four pixels. For example,
Cb<subscript>0</subscript>/Cr<subscript>0</subscript> belongs to
Y'<subscript>00</subscript>, Y'<subscript>01</subscript>,
Y'<subscript>10</subscript>, Y'<subscript>11</subscript>.
<constant>V4L2_PIX_FMT_NV61M</constant> is the same as <constant>V4L2_PIX_FMT_NV16M</constant>
except the Cb and Cr bytes are swapped, the CrCb plane starts with a Cr byte.</para>
<para><constant>V4L2_PIX_FMT_NV16M</constant> and
<constant>V4L2_PIX_FMT_NV61M</constant> are intended to be used only in drivers
and applications that support the multi-planar API, described in
<xref linkend="planar-apis"/>. </para>
<example>
<title><constant>V4L2_PIX_FMT_NV16M</constant> 4 &times; 4 pixel image</title>
<formalpara>
<title>Byte Order.</title>
<para>Each cell is one byte.
<informaltable frame="none">
<tgroup cols="5" align="center">
<colspec align="left" colwidth="2*" />
<tbody valign="top">
<row>
<entry>start0&nbsp;+&nbsp;0:</entry>
<entry>Y'<subscript>00</subscript></entry>
<entry>Y'<subscript>01</subscript></entry>
<entry>Y'<subscript>02</subscript></entry>
<entry>Y'<subscript>03</subscript></entry>
</row>
<row>
<entry>start0&nbsp;+&nbsp;4:</entry>
<entry>Y'<subscript>10</subscript></entry>
<entry>Y'<subscript>11</subscript></entry>
<entry>Y'<subscript>12</subscript></entry>
<entry>Y'<subscript>13</subscript></entry>
</row>
<row>
<entry>start0&nbsp;+&nbsp;8:</entry>
<entry>Y'<subscript>20</subscript></entry>
<entry>Y'<subscript>21</subscript></entry>
<entry>Y'<subscript>22</subscript></entry>
<entry>Y'<subscript>23</subscript></entry>
</row>
<row>
<entry>start0&nbsp;+&nbsp;12:</entry>
<entry>Y'<subscript>30</subscript></entry>
<entry>Y'<subscript>31</subscript></entry>
<entry>Y'<subscript>32</subscript></entry>
<entry>Y'<subscript>33</subscript></entry>
</row>
<row>
<entry></entry>
</row>
<row>
<entry>start1&nbsp;+&nbsp;0:</entry>
<entry>Cb<subscript>00</subscript></entry>
<entry>Cr<subscript>00</subscript></entry>
<entry>Cb<subscript>02</subscript></entry>
<entry>Cr<subscript>02</subscript></entry>
</row>
<row>
<entry>start1&nbsp;+&nbsp;4:</entry>
<entry>Cb<subscript>10</subscript></entry>
<entry>Cr<subscript>10</subscript></entry>
<entry>Cb<subscript>12</subscript></entry>
<entry>Cr<subscript>12</subscript></entry>
</row>
<row>
<entry>start1&nbsp;+&nbsp;8:</entry>
<entry>Cb<subscript>20</subscript></entry>
<entry>Cr<subscript>20</subscript></entry>
<entry>Cb<subscript>22</subscript></entry>
<entry>Cr<subscript>22</subscript></entry>
</row>
<row>
<entry>start1&nbsp;+&nbsp;12:</entry>
<entry>Cb<subscript>30</subscript></entry>
<entry>Cr<subscript>30</subscript></entry>
<entry>Cb<subscript>32</subscript></entry>
<entry>Cr<subscript>32</subscript></entry>
</row>
</tbody>
</tgroup>
</informaltable>
</para>
</formalpara>
<formalpara>
<title>Color Sample Location.</title>
<para>
<informaltable frame="none">
<tgroup cols="7" align="center">
<tbody valign="top">
<row>
<entry></entry>
<entry>0</entry><entry></entry><entry>1</entry><entry></entry>
<entry>2</entry><entry></entry><entry>3</entry>
</row>
<row>
<entry>0</entry>
<entry>Y</entry><entry></entry><entry>Y</entry><entry></entry>
<entry>Y</entry><entry></entry><entry>Y</entry>
</row>
<row>
<entry></entry>
<entry></entry><entry>C</entry><entry></entry><entry></entry>
<entry></entry><entry>C</entry><entry></entry>
</row>
<row>
<entry>1</entry>
<entry>Y</entry><entry></entry><entry>Y</entry><entry></entry>
<entry>Y</entry><entry></entry><entry>Y</entry>
</row>
<row>
<entry></entry>
<entry></entry><entry>C</entry><entry></entry><entry></entry>
<entry></entry><entry>C</entry><entry></entry>
</row>
<row>
<entry></entry>
</row>
<row>
<entry>2</entry>
<entry>Y</entry><entry></entry><entry>Y</entry><entry></entry>
<entry>Y</entry><entry></entry><entry>Y</entry>
</row>
<row>
<entry></entry>
<entry></entry><entry>C</entry><entry></entry><entry></entry>
<entry></entry><entry>C</entry><entry></entry>
</row>
<row>
<entry>3</entry>
<entry>Y</entry><entry></entry><entry>Y</entry><entry></entry>
<entry>Y</entry><entry></entry><entry>Y</entry>
</row>
<row>
<entry></entry>
<entry></entry><entry>C</entry><entry></entry><entry></entry>
<entry></entry><entry>C</entry><entry></entry>
</row>
</tbody>
</tgroup>
</informaltable>
</para>
</formalpara>
</example>
</refsect1>
</refentry>

7
Documentation/DocBook/media/v4l/pixfmt.xml
View file

@ -391,9 +391,9 @@ clamp (double x)
else return r;
}
y1 = (255 / 219.0) * (Y1 - 16);
pb = (255 / 224.0) * (Cb - 128);
pr = (255 / 224.0) * (Cr - 128);
y1 = (Y1 - 16) / 219.0;
pb = (Cb - 128) / 224.0;
pr = (Cr - 128) / 224.0;
r = 1.0 * y1 + 0 * pb + 1.402 * pr;
g = 1.0 * y1 - 0.344 * pb - 0.714 * pr;
@ -718,6 +718,7 @@ information.</para>
&sub-nv12m;
&sub-nv12mt;
&sub-nv16;
&sub-nv16m;
&sub-nv24;
&sub-m420;
</section>

611
Documentation/DocBook/media/v4l/subdev-formats.xml
View file

File diff suppressed because it is too large Load diff

41
Documentation/DocBook/media/v4l/vidioc-create-bufs.xml
View file

@ -62,18 +62,29 @@ addition to the <constant>VIDIOC_REQBUFS</constant> ioctl, when a tighter
control over buffers is required. This ioctl can be called multiple times to
create buffers of different sizes.</para>
<para>To allocate device buffers applications initialize relevant fields of
the <structname>v4l2_create_buffers</structname> structure. They set the
<structfield>type</structfield> field in the
&v4l2-format; structure, embedded in this
structure, to the respective stream or buffer type.
<structfield>count</structfield> must be set to the number of required buffers.
<structfield>memory</structfield> specifies the required I/O method. The
<structfield>format</structfield> field shall typically be filled in using
either the <constant>VIDIOC_TRY_FMT</constant> or
<constant>VIDIOC_G_FMT</constant> ioctl(). Additionally, applications can adjust
<structfield>sizeimage</structfield> fields to fit their specific needs. The
<structfield>reserved</structfield> array must be zeroed.</para>
<para>To allocate the device buffers applications must initialize the
relevant fields of the <structname>v4l2_create_buffers</structname> structure.
The <structfield>count</structfield> field must be set to the number of
requested buffers, the <structfield>memory</structfield> field specifies the
requested I/O method and the <structfield>reserved</structfield> array must be
zeroed.</para>
<para>The <structfield>format</structfield> field specifies the image format
that the buffers must be able to handle. The application has to fill in this
&v4l2-format;. Usually this will be done using the
<constant>VIDIOC_TRY_FMT</constant> or <constant>VIDIOC_G_FMT</constant> ioctl()
to ensure that the requested format is supported by the driver. Unsupported
formats will result in an error.</para>
<para>The buffers created by this ioctl will have as minimum size the size
defined by the <structfield>format.pix.sizeimage</structfield> field. If the
<structfield>format.pix.sizeimage</structfield> field is less than the minimum
required for the given format, then <structfield>sizeimage</structfield> will be
increased by the driver to that minimum to allocate the buffers. If it is
larger, then the value will be used as-is. The same applies to the
<structfield>sizeimage</structfield> field of the
<structname>v4l2_plane_pix_format</structname> structure in the case of
multiplanar formats.</para>
<para>When the ioctl is called with a pointer to this structure the driver
will attempt to allocate up to the requested number of buffers and store the
@ -144,9 +155,9 @@ mapped</link> I/O.</para>
<varlistentry>
<term><errorcode>EINVAL</errorcode></term>
<listitem>
<para>The buffer type (<structfield>type</structfield> field) or the
requested I/O method (<structfield>memory</structfield>) is not
supported.</para>
<para>The buffer type (<structfield>format.type</structfield> field),
requested I/O method (<structfield>memory</structfield>) or format
(<structfield>format</structfield> field) is not valid.</para>
</listitem>
</varlistentry>
</variablelist>

6
Documentation/DocBook/media/v4l/vidioc-g-dv-timings.xml
View file

@ -156,19 +156,19 @@ bit 0 (V4L2_DV_VSYNC_POS_POL) is for vertical sync polarity and bit 1 (V4L2_DV_H
<entry>__u32</entry>
<entry><structfield>il_vfrontporch</structfield></entry>
<entry>Vertical front porch in lines for the even field (aka field 2) of
interlaced field formats.</entry>
interlaced field formats. Must be 0 for progressive formats.</entry>
</row>
<row>
<entry>__u32</entry>
<entry><structfield>il_vsync</structfield></entry>
<entry>Vertical sync length in lines for the even field (aka field 2) of
interlaced field formats.</entry>
interlaced field formats. Must be 0 for progressive formats.</entry>
</row>
<row>
<entry>__u32</entry>
<entry><structfield>il_vbackporch</structfield></entry>
<entry>Vertical back porch in lines for the even field (aka field 2) of
interlaced field formats.</entry>
interlaced field formats. Must be 0 for progressive formats.</entry>
</row>
<row>
<entry>__u32</entry>

4
Documentation/DocBook/media/v4l/vidioc-g-jpegcomp.xml
View file

@ -92,8 +92,8 @@ to add them.</para>
<entry>int</entry>
<entry><structfield>quality</structfield></entry>
<entry>Deprecated. If <link linkend="jpeg-quality-control"><constant>
V4L2_CID_JPEG_IMAGE_QUALITY</constant></link> control is exposed by
a driver applications should use it instead and ignore this field.
V4L2_CID_JPEG_COMPRESSION_QUALITY</constant></link> control is exposed
by a driver applications should use it instead and ignore this field.
</entry>
</row>
<row>

4
Documentation/DocBook/media/v4l/vidioc-g-parm.xml
View file

@ -132,7 +132,7 @@ devices.</para>
<row>
<entry>&v4l2-fract;</entry>
<entry><structfield>timeperframe</structfield></entry>
<entry><para>This is is the desired period between
<entry><para>This is the desired period between
successive frames captured by the driver, in seconds. The
field is intended to skip frames on the driver side, saving I/O
bandwidth.</para><para>Applications store here the desired frame
@ -193,7 +193,7 @@ applications must set the array to zero.</entry>
<row>
<entry>&v4l2-fract;</entry>
<entry><structfield>timeperframe</structfield></entry>
<entry>This is is the desired period between
<entry>This is the desired period between
successive frames output by the driver, in seconds.</entry>
</row>
<row>

6
Documentation/DocBook/media_api.tmpl
View file

@ -22,8 +22,14 @@
<!-- LinuxTV v4l-dvb repository. -->
<!ENTITY v4l-dvb "<ulink url='http://linuxtv.org/repo/'>http://linuxtv.org/repo/</ulink>">
<!ENTITY dash-ent-8 "<entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry>">
<!ENTITY dash-ent-10 "<entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry>">
<!ENTITY dash-ent-12 "<entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry>">
<!ENTITY dash-ent-14 "<entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry>">
<!ENTITY dash-ent-16 "<entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry>">
<!ENTITY dash-ent-20 "<entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry>">
<!ENTITY dash-ent-22 "<entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry>">
<!ENTITY dash-ent-24 "<entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry>">
]>
<book id="media_api">

2
Documentation/DocBook/mtdnand.tmpl
View file

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

4
Documentation/IRQ-affinity.txt
View file

@ -57,8 +57,8 @@ i.e counters for the CPU0-3 did not change.
Here is an example of limiting that same irq (44) to cpus 1024 to 1031:
[root@moon 44]# echo 1024-1031 > smp_affinity
[root@moon 44]# cat smp_affinity
[root@moon 44]# echo 1024-1031 > smp_affinity_list
[root@moon 44]# cat smp_affinity_list
1024-1031
Note that to do this with a bitmask would require 32 bitmasks of zero

10
Documentation/SubmittingPatches
View file

@ -109,6 +109,16 @@ probably didn't even receive earlier versions of the patch.
If the patch fixes a logged bug entry, refer to that bug entry by
number and URL.
If you want to refer to a specific commit, don't just refer to the
SHA-1 ID of the commit. Please also include the oneline summary of
the commit, to make it easier for reviewers to know what it is about.
Example:
Commit e21d2170f36602ae2708 ("video: remove unnecessary
platform_set_drvdata()") removed the unnecessary
platform_set_drvdata(), but left the variable "dev" unused,
delete it.
3) Separate your changes.

18
Documentation/acpi/enumeration.txt
View file

@ -207,7 +207,7 @@ passing those. One idea is to return this in _DSM method like:
Return (Local0)
}
Then the at25 SPI driver can get this configation by calling _DSM on its
Then the at25 SPI driver can get this configuration by calling _DSM on its
ACPI handle like:
struct acpi_buffer output = { ACPI_ALLOCATE_BUFFER, NULL };
@ -228,19 +228,9 @@ ACPI handle like:
I2C serial bus support
~~~~~~~~~~~~~~~~~~~~~~
The slaves behind I2C bus controller only need to add the ACPI IDs like
with the platform and SPI drivers. However the I2C bus controller driver
needs to call acpi_i2c_register_devices() after it has added the adapter.
An I2C bus (controller) driver does:
...
ret = i2c_add_numbered_adapter(adapter);
if (ret)
/* handle error */
of_i2c_register_devices(adapter);
/* Enumerate the slave devices behind this bus via ACPI */
acpi_i2c_register_devices(adapter);
with the platform and SPI drivers. The I2C core automatically enumerates
any slave devices behind the controller device once the adapter is
registered.
Below is an example of how to add ACPI support to the existing mpu3050
input driver:

2
Documentation/aoe/udev.txt
View file

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

42
Documentation/arm/Booting
View file

@ -18,7 +18,8 @@ following:
2. Initialise one serial port.
3. Detect the machine type.
4. Setup the kernel tagged list.
5. Call the kernel image.
5. Load initramfs.
6. Call the kernel image.
1. Setup and initialise RAM
@ -120,12 +121,27 @@ tagged list.
The boot loader must pass at a minimum the size and location of the
system memory, and the root filesystem location. The dtb must be
placed in a region of memory where the kernel decompressor will not
overwrite it. The recommended placement is in the first 16KiB of RAM
with the caveat that it may not be located at physical address 0 since
the kernel interprets a value of 0 in r2 to mean neither a tagged list
nor a dtb were passed.
overwrite it, whilst remaining within the region which will be covered
by the kernel's low-memory mapping.
5. Calling the kernel image
A safe location is just above the 128MiB boundary from start of RAM.
5. Load initramfs.
------------------
Existing boot loaders: OPTIONAL
New boot loaders: OPTIONAL
If an initramfs is in use then, as with the dtb, it must be placed in
a region of memory where the kernel decompressor will not overwrite it
while also with the region which will be covered by the kernel's
low-memory mapping.
A safe location is just above the device tree blob which itself will
be loaded just above the 128MiB boundary from the start of RAM as
recommended above.
6. Calling the kernel image
---------------------------
Existing boot loaders: MANDATORY
@ -136,11 +152,17 @@ is stored in flash, and is linked correctly to be run from flash,
then it is legal for the boot loader to call the zImage in flash
directly.
The zImage may also be placed in system RAM (at any location) and
called there. Note that the kernel uses 16K of RAM below the image
to store page tables. The recommended placement is 32KiB into RAM.
The zImage may also be placed in system RAM and called there. The
kernel should be placed in the first 128MiB of RAM. It is recommended
that it is loaded above 32MiB in order to avoid the need to relocate
prior to decompression, which will make the boot process slightly
faster.
In either case, the following conditions must be met:
When booting a raw (non-zImage) kernel the constraints are tighter.
In this case the kernel must be loaded at an offset into system equal
to TEXT_OFFSET - PAGE_OFFSET.
In any case, the following conditions must be met:
- Quiesce all DMA capable devices so that memory does not get
corrupted by bogus network packets or disk data. This will save

2
Documentation/arm/OMAP/omap_pm
View file

@ -78,7 +78,7 @@ to NULL. Drivers should use the following idiom:
The most common usage of these functions will probably be to specify
the maximum time from when an interrupt occurs, to when the device
becomes accessible. To accomplish this, driver writers should use the
set_max_mpu_wakeup_lat() function to to constrain the MPU wakeup
set_max_mpu_wakeup_lat() function to constrain the MPU wakeup
latency, and the set_max_dev_wakeup_lat() function to constrain the
device wakeup latency (from clk_enable() to accessibility). For
example,

121
Documentation/arm/kernel_mode_neon.txt Normal file
View file

@ -0,0 +1,121 @@
Kernel mode NEON
================
TL;DR summary
-------------
* Use only NEON instructions, or VFP instructions that don't rely on support
code
* Isolate your NEON code in a separate compilation unit, and compile it with
'-mfpu=neon -mfloat-abi=softfp'
* Put kernel_neon_begin() and kernel_neon_end() calls around the calls into your
NEON code
* Don't sleep in your NEON code, and be aware that it will be executed with
preemption disabled
Introduction
------------
It is possible to use NEON instructions (and in some cases, VFP instructions) in
code that runs in kernel mode. However, for performance reasons, the NEON/VFP
register file is not preserved and restored at every context switch or taken
exception like the normal register file is, so some manual intervention is
required. Furthermore, special care is required for code that may sleep [i.e.,
may call schedule()], as NEON or VFP instructions will be executed in a
non-preemptible section for reasons outlined below.
Lazy preserve and restore
-------------------------
The NEON/VFP register file is managed using lazy preserve (on UP systems) and
lazy restore (on both SMP and UP systems). This means that the register file is
kept 'live', and is only preserved and restored when multiple tasks are
contending for the NEON/VFP unit (or, in the SMP case, when a task migrates to
another core). Lazy restore is implemented by disabling the NEON/VFP unit after
every context switch, resulting in a trap when subsequently a NEON/VFP
instruction is issued, allowing the kernel to step in and perform the restore if
necessary.
Any use of the NEON/VFP unit in kernel mode should not interfere with this, so
it is required to do an 'eager' preserve of the NEON/VFP register file, and
enable the NEON/VFP unit explicitly so no exceptions are generated on first
subsequent use. This is handled by the function kernel_neon_begin(), which
should be called before any kernel mode NEON or VFP instructions are issued.
Likewise, the NEON/VFP unit should be disabled again after use to make sure user
mode will hit the lazy restore trap upon next use. This is handled by the
function kernel_neon_end().
Interruptions in kernel mode
----------------------------
For reasons of performance and simplicity, it was decided that there shall be no
preserve/restore mechanism for the kernel mode NEON/VFP register contents. This
implies that interruptions of a kernel mode NEON section can only be allowed if
they are guaranteed not to touch the NEON/VFP registers. For this reason, the
following rules and restrictions apply in the kernel:
* NEON/VFP code is not allowed in interrupt context;
* NEON/VFP code is not allowed to sleep;
* NEON/VFP code is executed with preemption disabled.
If latency is a concern, it is possible to put back to back calls to
kernel_neon_end() and kernel_neon_begin() in places in your code where none of
the NEON registers are live. (Additional calls to kernel_neon_begin() should be
reasonably cheap if no context switch occurred in the meantime)
VFP and support code
--------------------
Earlier versions of VFP (prior to version 3) rely on software support for things
like IEEE-754 compliant underflow handling etc. When the VFP unit needs such
software assistance, it signals the kernel by raising an undefined instruction
exception. The kernel responds by inspecting the VFP control registers and the
current instruction and arguments, and emulates the instruction in software.
Such software assistance is currently not implemented for VFP instructions
executed in kernel mode. If such a condition is encountered, the kernel will
fail and generate an OOPS.
Separating NEON code from ordinary code
---------------------------------------
The compiler is not aware of the special significance of kernel_neon_begin() and
kernel_neon_end(), i.e., that it is only allowed to issue NEON/VFP instructions
between calls to these respective functions. Furthermore, GCC may generate NEON
instructions of its own at -O3 level if -mfpu=neon is selected, and even if the
kernel is currently compiled at -O2, future changes may result in NEON/VFP
instructions appearing in unexpected places if no special care is taken.
Therefore, the recommended and only supported way of using NEON/VFP in the
kernel is by adhering to the following rules:
* isolate the NEON code in a separate compilation unit and compile it with
'-mfpu=neon -mfloat-abi=softfp';
* issue the calls to kernel_neon_begin(), kernel_neon_end() as well as the calls
into the unit containing the NEON code from a compilation unit which is *not*
built with the GCC flag '-mfpu=neon' set.
As the kernel is compiled with '-msoft-float', the above will guarantee that
both NEON and VFP instructions will only ever appear in designated compilation
units at any optimization level.
NEON assembler
--------------
NEON assembler is supported with no additional caveats as long as the rules
above are followed.
NEON code generated by GCC
--------------------------
The GCC option -ftree-vectorize (implied by -O3) tries to exploit implicit
parallelism, and generates NEON code from ordinary C source code. This is fully
supported as long as the rules above are followed.
NEON intrinsics
---------------
NEON intrinsics are also supported. However, as code using NEON intrinsics
relies on the GCC header <arm_neon.h>, (which #includes <stdint.h>), you should
observe the following in addition to the rules above:
* Compile the unit containing the NEON intrinsics with '-ffreestanding' so GCC
uses its builtin version of <stdint.h> (this is a C99 header which the kernel
does not supply);
* Include <arm_neon.h> last, or at least after <linux/types.h>

22
Documentation/arm64/booting.txt
View file

@ -45,9 +45,9 @@ sees fit.)
Requirement: MANDATORY
The device tree blob (dtb) must be no bigger than 2 megabytes in size
and placed at a 2-megabyte boundary within the first 512 megabytes from
the start of the kernel image. This is to allow the kernel to map the
The device tree blob (dtb) must be placed on an 8-byte boundary within
the first 512 megabytes from the start of the kernel image and must not
cross a 2-megabyte boundary. This is to allow the kernel to map the
blob using a single section mapping in the initial page tables.
@ -68,13 +68,23 @@ Image target is available instead.
Requirement: MANDATORY
The decompressed kernel image contains a 32-byte header as follows:
The decompressed kernel image contains a 64-byte header as follows:
u32 magic = 0x14000008; /* branch to stext, little-endian */
u32 res0 = 0; /* reserved */
u32 code0; /* Executable code */
u32 code1; /* Executable code */
u64 text_offset; /* Image load offset */
u64 res0 = 0; /* reserved */
u64 res1 = 0; /* reserved */
u64 res2 = 0; /* reserved */
u64 res3 = 0; /* reserved */
u64 res4 = 0; /* reserved */
u32 magic = 0x644d5241; /* Magic number, little endian, "ARM\x64" */
u32 res5 = 0; /* reserved */
Header notes:
- code0/code1 are responsible for branching to stext.
The image must be placed at the specified offset (currently 0x80000)
from the start of the system RAM and called there. The start of the

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

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

2
Documentation/block/cfq-iosched.txt
View file

@ -69,7 +69,7 @@ one, this value should be decreased relative to fifo_expire_async.
group_idle
-----------
This parameter forces idling at the CFQ group level instead of CFQ
queue level. This was introduced after after a bottleneck was observed
queue level. This was introduced after a bottleneck was observed
in higher end storage due to idle on sequential queue and allow dispatch
from a single queue. The idea with this parameter is that it can be run with
slice_idle=0 and group_idle=8, so that idling does not happen on individual

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

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

6
Documentation/cachetlb.txt
View file

@ -57,7 +57,7 @@ changes occur:
interface must make sure that any previous page table
modifications for the address space 'vma->vm_mm' in the range
'start' to 'end-1' will be visible to the cpu. That is, after
running, here will be no entries in the TLB for 'mm' for
running, there will be no entries in the TLB for 'mm' for
virtual addresses in the range 'start' to 'end-1'.
The "vma" is the backing store being used for the region.
@ -375,8 +375,8 @@ maps this page at its virtual address.
void flush_icache_page(struct vm_area_struct *vma, struct page *page)
All the functionality of flush_icache_page can be implemented in
flush_dcache_page and update_mmu_cache. In 2.7 the hope is to
remove this interface completely.
flush_dcache_page and update_mmu_cache. In the future, the hope
is to remove this interface completely.
The final category of APIs is for I/O to deliberately aliased address
ranges inside the kernel. Such aliases are set up by use of the

2
Documentation/cgroups/memory.txt
View file

@ -490,6 +490,8 @@ pgpgin - # of charging events to the memory cgroup. The charging
pgpgout - # of uncharging events to the memory cgroup. The uncharging
event happens each time a page is unaccounted from the cgroup.
swap - # of bytes of swap usage
writeback - # of bytes of file/anon cache that are queued for syncing to
disk.
inactive_anon - # of bytes of anonymous and swap cache memory on inactive
LRU list.
active_anon - # of bytes of anonymous and swap cache memory on active

46
Documentation/clk.txt
View file

@ -70,6 +70,10 @@ the operations defined in clk.h:
unsigned long parent_rate);
long (*round_rate)(struct clk_hw *hw, unsigned long,
unsigned long *);
long (*determine_rate)(struct clk_hw *hw,
unsigned long rate,
unsigned long *best_parent_rate,
struct clk **best_parent_clk);
int (*set_parent)(struct clk_hw *hw, u8 index);
u8 (*get_parent)(struct clk_hw *hw);
int (*set_rate)(struct clk_hw *hw, unsigned long);
@ -179,26 +183,28 @@ mandatory, a cell marked as "n" implies that either including that
callback is invalid or otherwise unnecessary. Empty cells are either
optional or must be evaluated on a case-by-case basis.
clock hardware characteristics
-----------------------------------------------------------
| gate | change rate | single parent | multiplexer | root |
|------|-------------|---------------|-------------|------|
.prepare | | | | | |
.unprepare | | | | | |
| | | | | |
.enable | y | | | | |
.disable | y | | | | |
.is_enabled | y | | | | |
| | | | | |
.recalc_rate | | y | | | |
.round_rate | | y | | | |
.set_rate | | y | | | |
| | | | | |
.set_parent | | | n | y | n |
.get_parent | | | n | y | n |
| | | | | |
.init | | | | | |
-----------------------------------------------------------
clock hardware characteristics
-----------------------------------------------------------
| gate | change rate | single parent | multiplexer | root |
|------|-------------|---------------|-------------|------|
.prepare | | | | | |
.unprepare | | | | | |
| | | | | |
.enable | y | | | | |
.disable | y | | | | |
.is_enabled | y | | | | |
| | | | | |
.recalc_rate | | y | | | |
.round_rate | | y [1] | | | |
.determine_rate | | y [1] | | | |
.set_rate | | y | | | |
| | | | | |
.set_parent | | | n | y | n |
.get_parent | | | n | y | n |
| | | | | |
.init | | | | | |
-----------------------------------------------------------
[1] either one of round_rate or determine_rate is required.
Finally, register your clock at run-time with a hardware-specific
registration function. This function simply populates struct clk_foo's

2
Documentation/cputopology.txt
View file

@ -22,7 +22,7 @@ to /proc/cpuinfo.
4) /sys/devices/system/cpu/cpuX/topology/thread_siblings:
internel kernel map of cpuX's hardware threads within the same
internal kernel map of cpuX's hardware threads within the same
core as cpuX
5) /sys/devices/system/cpu/cpuX/topology/core_siblings:

4
Documentation/development-process/2.Process
View file

@ -276,7 +276,7 @@ mainline get there via -mm.
The current -mm patch is available in the "mmotm" (-mm of the moment)
directory at:
http://userweb.kernel.org/~akpm/mmotm/
http://www.ozlabs.org/~akpm/mmotm/
Use of the MMOTM tree is likely to be a frustrating experience, though;
there is a definite chance that it will not even compile.
@ -287,7 +287,7 @@ the mainline is expected to look like after the next merge window closes.
Linux-next trees are announced on the linux-kernel and linux-next mailing
lists when they are assembled; they can be downloaded from:
http://www.kernel.org/pub/linux/kernel/people/sfr/linux-next/
http://www.kernel.org/pub/linux/kernel/next/
Some information about linux-next has been gathered at:

6
Documentation/device-mapper/cache.txt
View file

@ -50,14 +50,16 @@ other parameters detailed later):
which are dirty, and extra hints for use by the policy object.
This information could be put on the cache device, but having it
separate allows the volume manager to configure it differently,
e.g. as a mirror for extra robustness.
e.g. as a mirror for extra robustness. This metadata device may only
be used by a single cache device.
Fixed block size
----------------
The origin is divided up into blocks of a fixed size. This block size
is configurable when you first create the cache. Typically we've been
using block sizes of 256k - 1024k.
using block sizes of 256KB - 1024KB. The block size must be between 64
(32KB) and 2097152 (1GB) and a multiple of 64 (32KB).
Having a fixed block size simplifies the target a lot. But it is
something of a compromise. For instance, a small part of a block may be

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

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

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

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

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

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

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

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

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

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

4
Documentation/devicetree/bindings/arm/l2cc.txt
View file

@ -16,9 +16,11 @@ Required properties:
performs the same operation).
"marvell,"aurora-outer-cache: Marvell Controller designed to be
compatible with the ARM one with outer cache mode.
"bcm,bcm11351-a2-pl310-cache": For Broadcom bcm11351 chipset where an
"brcm,bcm11351-a2-pl310-cache": For Broadcom bcm11351 chipset where an
offset needs to be added to the address before passing down to the L2
cache controller
"bcm,bcm11351-a2-pl310-cache": DEPRECATED by
"brcm,bcm11351-a2-pl310-cache"
- cache-unified : Specifies the cache is a unified cache.
- cache-level : Should be set to 2 for a level 2 cache.
- reg : Physical base address and size of cache controller's memory mapped

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

@ -59,3 +59,6 @@ Boards:
- AM43x EPOS EVM
compatible = "ti,am43x-epos-evm", "ti,am4372", "ti,am43"
- DRA7 EVM: Software Developement Board for DRA7XX
compatible = "ti,dra7-evm", "ti,dra7"

2
Documentation/devicetree/bindings/arm/ste-u300.txt
View file

@ -22,7 +22,7 @@ This contains the board-specific information.
- compatible: must be "stericsson,s365".
- vana15-supply: the regulator supplying the 1.5V to drive the
board.
- syscon: a pointer to the syscon node so we can acccess the
- syscon: a pointer to the syscon node so we can access the
syscon registers to set the board as self-powered.
Example:

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

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

4
Documentation/devicetree/bindings/arm/vexpress-sysreg.txt
View file

@ -32,8 +32,8 @@ numbers - see motherboard's TRM for more details.
The node describing a config device must refer to the sysreg node via
"arm,vexpress,config-bridge" phandle (can be also defined in the node's
parent) and relies on the board topology properties - see main vexpress
node documentation for more details. It must must also define the
following property:
node documentation for more details. It must also define the following
property:
- arm,vexpress-sysreg,func : must contain two cells:
- first cell defines function number (eg. 1 for clock generator,
2 for voltage regulators etc.)

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

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

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

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

2
Documentation/devicetree/bindings/c6x/dscr.txt
View file

@ -5,7 +5,7 @@ TI C6X SoCs contain a region of miscellaneous registers which provide various
function for SoC control or status. Details vary considerably among from SoC
to SoC with no two being alike.
In general, the Device State Configuraion Registers (DSCR) will provide one or
In general, the Device State Configuration Registers (DSCR) will provide one or
more configuration registers often protected by a lock register where one or
more key values must be written to a lock register in order to unlock the
configuration register for writes. These configuration register may be used to

2
Documentation/devicetree/bindings/clock/clk-exynos-audss.txt
View file

@ -2,7 +2,7 @@
The Samsung Audio Subsystem clock controller generates and supplies clocks
to Audio Subsystem block available in the S5PV210 and Exynos SoCs. The clock
binding described here is applicable to all SoC's in Exynos family.
binding described here is applicable to all SoCs in Exynos family.
Required Properties:

1
Documentation/devicetree/bindings/clock/exynos4-clock.txt
View file

@ -236,6 +236,7 @@ Exynos4 SoC and this is specified where applicable.
spi0_isp_sclk 380 Exynos4x12
spi1_isp_sclk 381 Exynos4x12
uart_isp_sclk 382 Exynos4x12
tmu_apbif 383
[Mux Clocks]

14
Documentation/devicetree/bindings/clock/exynos5250-clock.txt
View file

@ -59,6 +59,9 @@ clock which they consume.
sclk_spi0 154
sclk_spi1 155
sclk_spi2 156
div_i2s1 157
div_i2s2 158
sclk_hdmiphy 159
[Peripheral Clock Gates]
@ -154,7 +157,16 @@ clock which they consume.
dsim0 341
dp 342
mixer 343
hdmi 345
hdmi 344
g2d 345
[Clock Muxes]
Clock ID
----------------------------
mout_hdmi 1024
Example 1: An example of a clock controller node is listed below.

12
Documentation/devicetree/bindings/clock/exynos5420-clock.txt
View file

@ -59,6 +59,7 @@ clock which they consume.
sclk_pwm 155
sclk_gscl_wa 156
sclk_gscl_wb 157
sclk_hdmiphy 158
[Peripheral Clock Gates]
@ -179,6 +180,17 @@ clock which they consume.
fimc_lite3 495
aclk_g3d 500
g3d 501
smmu_mixer 502
Mux ID
----------------------------
mout_hdmi 640
Divider ID
----------------------------
dout_pixel 768
Example 1: An example of a clock controller node is listed below.

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

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

6
Documentation/devicetree/bindings/clock/imx6q-clock.txt
View file

@ -209,6 +209,12 @@ clocks and IDs.
pll5_post_div 194
pll5_video_div 195
eim_slow 196
spdif 197
cko2_sel 198
cko2_podf 199
cko2 200
cko 201
vdoa 202
Examples:

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

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

2
Documentation/devicetree/bindings/clock/st,nomadik.txt
View file

@ -17,7 +17,7 @@ Optional properties for the SRC node:
- disable-mxtal: if present this will disable the MXTALO,
i.e. the driver output for the main (~19.2 MHz) chrystal,
if the board has its own circuitry for providing this
osciallator
oscillator
PLL nodes: these nodes represent the two PLLs on the system,

12
Documentation/devicetree/bindings/clock/sunxi.txt
View file

@ -8,19 +8,31 @@ Required properties:
- compatible : shall be one of the following:
"allwinner,sun4i-osc-clk" - for a gatable oscillator
"allwinner,sun4i-pll1-clk" - for the main PLL clock
"allwinner,sun6i-a31-pll1-clk" - for the main PLL clock on A31
"allwinner,sun4i-cpu-clk" - for the CPU multiplexer clock
"allwinner,sun4i-axi-clk" - for the AXI clock
"allwinner,sun4i-axi-gates-clk" - for the AXI gates
"allwinner,sun4i-ahb-clk" - for the AHB clock
"allwinner,sun4i-ahb-gates-clk" - for the AHB gates on A10
"allwinner,sun5i-a13-ahb-gates-clk" - for the AHB gates on A13
"allwinner,sun5i-a10s-ahb-gates-clk" - for the AHB gates on A10s
"allwinner,sun7i-a20-ahb-gates-clk" - for the AHB gates on A20
"allwinner,sun6i-a31-ahb1-mux-clk" - for the AHB1 multiplexer on A31
"allwinner,sun6i-a31-ahb1-gates-clk" - for the AHB1 gates on A31
"allwinner,sun4i-apb0-clk" - for the APB0 clock
"allwinner,sun4i-apb0-gates-clk" - for the APB0 gates on A10
"allwinner,sun5i-a13-apb0-gates-clk" - for the APB0 gates on A13
"allwinner,sun5i-a10s-apb0-gates-clk" - for the APB0 gates on A10s
"allwinner,sun7i-a20-apb0-gates-clk" - for the APB0 gates on A20
"allwinner,sun4i-apb1-clk" - for the APB1 clock
"allwinner,sun4i-apb1-mux-clk" - for the APB1 clock muxing
"allwinner,sun4i-apb1-gates-clk" - for the APB1 gates on A10
"allwinner,sun5i-a13-apb1-gates-clk" - for the APB1 gates on A13
"allwinner,sun5i-a10s-apb1-gates-clk" - for the APB1 gates on A10s
"allwinner,sun6i-a31-apb1-gates-clk" - for the APB1 gates on A31
"allwinner,sun7i-a20-apb1-gates-clk" - for the APB1 gates on A20
"allwinner,sun6i-a31-apb2-div-clk" - for the APB2 gates on A31
"allwinner,sun6i-a31-apb2-gates-clk" - for the APB2 gates on A31
Required properties for all clocks:
- reg : shall be the control register address for the clock.

75
Documentation/devicetree/bindings/clock/sunxi/sun5i-a10s-gates.txt Normal file
View file

@ -0,0 +1,75 @@
Gate clock outputs
------------------
* AXI gates ("allwinner,sun4i-axi-gates-clk")
DRAM 0
* AHB gates ("allwinner,sun5i-a10s-ahb-gates-clk")
USB0 0
EHCI0 1
OHCI0 2
SS 5
DMA 6
BIST 7
MMC0 8
MMC1 9
MMC2 10
NAND 13
SDRAM 14
EMAC 17
TS 18
SPI0 20
SPI1 21
SPI2 22
GPS 26
HSTIMER 28
VE 32
TVE 34
LCD 36
CSI 40
HDMI 43
DE_BE 44
DE_FE 46
IEP 51
MALI400 52
* APB0 gates ("allwinner,sun5i-a10s-apb0-gates-clk")
CODEC 0
IIS 3
PIO 5
IR 6
KEYPAD 10
* APB1 gates ("allwinner,sun5i-a10s-apb1-gates-clk")
I2C0 0
I2C1 1
I2C2 2
UART0 16
UART1 17
UART2 18
UART3 19
Notation:
[*]: The datasheet didn't mention these, but they are present on AW code
[**]: The datasheet had this marked as "NC" but they are used on AW code

83
Documentation/devicetree/bindings/clock/sunxi/sun6i-a31-gates.txt Normal file
View file

@ -0,0 +1,83 @@
Gate clock outputs
------------------
* AHB1 gates ("allwinner,sun6i-a31-ahb1-gates-clk")
MIPI DSI 1
SS 5
DMA 6
MMC0 8
MMC1 9
MMC2 10
MMC3 11
NAND1 12
NAND0 13
SDRAM 14
GMAC 17
TS 18
HSTIMER 19
SPI0 20
SPI1 21
SPI2 22
SPI3 23
USB_OTG 24
EHCI0 26
EHCI1 27
OHCI0 29
OHCI1 30
OHCI2 31
VE 32
LCD0 36
LCD1 37
CSI 40
HDMI 43
DE_BE0 44
DE_BE1 45
DE_FE1 46
DE_FE1 47
MP 50
GPU 52
DEU0 55
DEU1 56
DRC0 57
DRC1 58
* APB1 gates ("allwinner,sun6i-a31-apb1-gates-clk")
CODEC 0
DIGITAL MIC 4
PIO 5
DAUDIO0 12
DAUDIO1 13
* APB2 gates ("allwinner,sun6i-a31-apb2-gates-clk")
I2C0 0
I2C1 1
I2C2 2
I2C3 3
UART0 16
UART1 17
UART2 18
UART3 19
UART4 20
UART5 21
Notation:
[*]: The datasheet didn't mention these, but they are present on AW code
[**]: The datasheet had this marked as "NC" but they are used on AW code

98
Documentation/devicetree/bindings/clock/sunxi/sun7i-a20-gates.txt Normal file
View file

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

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

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

4
Documentation/devicetree/bindings/dma/atmel-dma.txt
View file

@ -18,14 +18,14 @@ dma0: dma@ffffec00 {
DMA clients connected to the Atmel DMA controller must use the format
described in the dma.txt file, using a three-cell specifier for each channel:
a phandle plus two interger cells.
a phandle plus two integer cells.
The three cells in order are:
1. A phandle pointing to the DMA controller.
2. The memory interface (16 most significant bits), the peripheral interface
(16 less significant bits).
3. Parameters for the at91 DMA configuration register which are device
dependant:
dependent:
- bit 7-0: peripheral identifier for the hardware handshaking interface. The
identifier can be different for tx and rx.
- bit 11-8: FIFO configuration. 0 for half FIFO, 1 for ALAP, 1 for ASAP.

2
Documentation/devicetree/bindings/dma/fsl-imx-dma.txt
View file

@ -34,7 +34,7 @@ Clients have to specify the DMA requests with phandles in a list.
Required properties:
- dmas: List of one or more DMA request specifiers. One DMA request specifier
consists of a phandle to the DMA controller followed by the integer
specifiying the request line.
specifying the request line.
- dma-names: List of string identifiers for the DMA requests. For the correct
names, have a look at the specific client driver.

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

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

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

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

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

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

4
Documentation/devicetree/bindings/dma/ste-dma40.txt
View file

@ -37,14 +37,14 @@ Each dmas request consists of 4 cells:
1. A phandle pointing to the DMA controller
2. Device Type
3. The DMA request line number (only when 'use fixed channel' is set)
4. A 32bit mask specifying; mode, direction and endianess [NB: This list will grow]
4. A 32bit mask specifying; mode, direction and endianness [NB: This list will grow]
0x00000001: Mode:
Logical channel when unset
Physical channel when set
0x00000002: Direction:
Memory to Device when unset
Device to Memory when set
0x00000004: Endianess:
0x00000004: Endianness:
Little endian when unset
Big endian when set
0x00000008: Use fixed channel:

26
Documentation/devicetree/bindings/gpio/gpio-mcp23s08.txt
View file

@ -3,10 +3,17 @@ Microchip MCP2308/MCP23S08/MCP23017/MCP23S17 driver for
Required properties:
- compatible : Should be
- "mcp,mcp23s08" for 8 GPIO SPI version
- "mcp,mcp23s17" for 16 GPIO SPI version
- "mcp,mcp23008" for 8 GPIO I2C version or
- "mcp,mcp23017" for 16 GPIO I2C version of the chip
- "mcp,mcp23s08" (DEPRECATED) for 8 GPIO SPI version
- "mcp,mcp23s17" (DEPRECATED) for 16 GPIO SPI version
- "mcp,mcp23008" (DEPRECATED) for 8 GPIO I2C version or
- "mcp,mcp23017" (DEPRECATED) for 16 GPIO I2C version of the chip
- "microchip,mcp23s08" for 8 GPIO SPI version
- "microchip,mcp23s17" for 16 GPIO SPI version
- "microchip,mcp23008" for 8 GPIO I2C version or
- "microchip,mcp23017" for 16 GPIO I2C version of the chip
NOTE: Do not use the old mcp prefix any more. It is deprecated and will be
removed.
- #gpio-cells : Should be two.
- first cell is the pin number
- second cell is used to specify flags. Flags are currently unused.
@ -15,10 +22,11 @@ Required properties:
SPI uses this to specify the chipselect line which the chip is
connected to. The driver and the SPI variant of the chip support
multiple chips on the same chipselect. Have a look at
mcp,spi-present-mask below.
microchip,spi-present-mask below.
Required device specific properties (only for SPI chips):
- mcp,spi-present-mask : This is a present flag, that makes only sense for SPI
- mcp,spi-present-mask (DEPRECATED)
- microchip,spi-present-mask : This is a present flag, that makes only sense for SPI
chips - as the name suggests. Multiple SPI chips can share the same
SPI chipselect. Set a bit in bit0-7 in this mask to 1 if there is a
chip connected with the corresponding spi address set. For example if
@ -26,11 +34,13 @@ Required device specific properties (only for SPI chips):
which is 0x08. mcp23s08 chip variant only supports bits 0-3. It is not
possible to mix mcp23s08 and mcp23s17 on the same chipselect. Set at
least one bit to 1 for SPI chips.
NOTE: Do not use the old mcp prefix any more. It is deprecated and will be
removed.
- spi-max-frequency = The maximum frequency this chip is able to handle
Example I2C:
gpiom1: gpio@20 {
compatible = "mcp,mcp23017";
compatible = "microchip,mcp23017";
gpio-controller;
#gpio-cells = <2>;
reg = <0x20>;
@ -38,7 +48,7 @@ gpiom1: gpio@20 {
Example SPI:
gpiom1: gpio@0 {
compatible = "mcp,mcp23s17";
compatible = "microchip,mcp23s17";
gpio-controller;
#gpio-cells = <2>;
spi-present-mask = <0x01>;

27
Documentation/devicetree/bindings/gpio/gpio-palmas.txt Normal file
View file

@ -0,0 +1,27 @@
Palmas GPIO controller bindings
Required properties:
- compatible:
- "ti,palams-gpio" for palma series of the GPIO controller
- "ti,tps80036-gpio" for Palma series device TPS80036.
- "ti,tps65913-gpio" for palma series device TPS65913.
- "ti,tps65914-gpio" for palma series device TPS65914.
- #gpio-cells : Should be two.
- first cell is the gpio pin number
- second cell is used to specify the gpio polarity:
0 = active high
1 = active low
- gpio-controller : Marks the device node as a GPIO controller.
Note: This gpio node will be sub node of palmas node.
Example:
palmas: tps65913@58 {
:::::::::::
palmas_gpio: palmas_gpio {
compatible = "ti,palmas-gpio";
gpio-controller;
#gpio-cells = <2>;
};
:::::::::::
};

45
Documentation/devicetree/bindings/gpio/gpio-tz1090-pdc.txt Normal file
View file

@ -0,0 +1,45 @@
ImgTec TZ1090 PDC GPIO Controller
Required properties:
- compatible: Compatible property value should be "img,tz1090-pdc-gpio".
- reg: Physical base address of the controller and length of memory mapped
region. This starts at and cover the SOC_GPIO_CONTROL registers.
- gpio-controller: Specifies that the node is a gpio controller.
- #gpio-cells: Should be 2. The syntax of the gpio specifier used by client
nodes should have the following values.
<[phandle of the gpio controller node]
[PDC gpio number]
[gpio flags]>
Values for gpio specifier:
- GPIO number: a value in the range 0 to 6.
- GPIO flags: bit field of flags, as defined in <dt-bindings/gpio/gpio.h>.
Only the following flags are supported:
GPIO_ACTIVE_HIGH
GPIO_ACTIVE_LOW
Optional properties:
- gpio-ranges: Mapping to pin controller pins (as described in
Documentation/devicetree/bindings/gpio/gpio.txt)
- interrupts: Individual syswake interrupts (other GPIOs cannot interrupt)
Example:
pdc_gpios: gpio-controller@02006500 {
gpio-controller;
#gpio-cells = <2>;
compatible = "img,tz1090-pdc-gpio";
reg = <0x02006500 0x100>;
interrupt-parent = <&pdc>;
interrupts = <8 IRQ_TYPE_NONE>, /* Syswake 0 */
<9 IRQ_TYPE_NONE>, /* Syswake 1 */
<10 IRQ_TYPE_NONE>; /* Syswake 2 */
gpio-ranges = <&pdc_pinctrl 0 0 7>;
};

88
Documentation/devicetree/bindings/gpio/gpio-tz1090.txt Normal file
View file

@ -0,0 +1,88 @@
ImgTec TZ1090 GPIO Controller
Required properties:
- compatible: Compatible property value should be "img,tz1090-gpio".
- reg: Physical base address of the controller and length of memory mapped
region.
- #address-cells: Should be 1 (for bank subnodes)
- #size-cells: Should be 0 (for bank subnodes)
- Each bank of GPIOs should have a subnode to represent it.
Bank subnode required properties:
- reg: Index of bank in the range 0 to 2.
- gpio-controller: Specifies that the node is a gpio controller.
- #gpio-cells: Should be 2. The syntax of the gpio specifier used by client
nodes should have the following values.
<[phandle of the gpio controller node]
[gpio number within the gpio bank]
[gpio flags]>
Values for gpio specifier:
- GPIO number: a value in the range 0 to 29.
- GPIO flags: bit field of flags, as defined in <dt-bindings/gpio/gpio.h>.
Only the following flags are supported:
GPIO_ACTIVE_HIGH
GPIO_ACTIVE_LOW
Bank subnode optional properties:
- gpio-ranges: Mapping to pin controller pins (as described in
Documentation/devicetree/bindings/gpio/gpio.txt)
- interrupts: Interrupt for the entire bank
- interrupt-controller: Specifies that the node is an interrupt controller
- #interrupt-cells: Should be 2. The syntax of the interrupt specifier used by
client nodes should have the following values.
<[phandle of the interurupt controller]
[gpio number within the gpio bank]
[irq flags]>
Values for irq specifier:
- GPIO number: a value in the range 0 to 29
- IRQ flags: value to describe edge and level triggering, as defined in
<dt-bindings/interrupt-controller/irq.h>. Only the following flags are
supported:
IRQ_TYPE_EDGE_RISING
IRQ_TYPE_EDGE_FALLING
IRQ_TYPE_EDGE_BOTH
IRQ_TYPE_LEVEL_HIGH
IRQ_TYPE_LEVEL_LOW
Example:
gpios: gpio-controller@02005800 {
#address-cells = <1>;
#size-cells = <0>;
compatible = "img,tz1090-gpio";
reg = <0x02005800 0x90>;
/* bank 0 with an interrupt */
gpios0: bank@0 {
#gpio-cells = <2>;
#interrupt-cells = <2>;
reg = <0>;
interrupts = <13 IRQ_TYPE_LEVEL_HIGH>;
gpio-controller;
gpio-ranges = <&pinctrl 0 0 30>;
interrupt-controller;
};
/* bank 2 without interrupt */
gpios2: bank@2 {
#gpio-cells = <2>;
reg = <2>;
gpio-controller;
gpio-ranges = <&pinctrl 0 60 30>;
};
};

55
Documentation/devicetree/bindings/gpio/gpio.txt
View file

@ -75,23 +75,36 @@ Example of two SOC GPIO banks defined as gpio-controller nodes:
gpio-controller;
};
2.1) gpio-controller and pinctrl subsystem
------------------------------------------
2.1) gpio- and pin-controller interaction
-----------------------------------------
gpio-controller on a SOC might be tightly coupled with the pinctrl
subsystem, in the sense that the pins can be used by other functions
together with optional gpio feature.
Some or all of the GPIOs provided by a GPIO controller may be routed to pins
on the package via a pin controller. This allows muxing those pins between
GPIO and other functions.
While the pin allocation is totally managed by the pin ctrl subsystem,
gpio (under gpiolib) is still maintained by gpio drivers. It may happen
that different pin ranges in a SoC is managed by different gpio drivers.
It is useful to represent which GPIOs correspond to which pins on which pin
controllers. The gpio-ranges property described below represents this, and
contains information structures as follows:
This makes it logical to let gpio drivers announce their pin ranges to
the pin ctrl subsystem and call 'pinctrl_request_gpio' in order to
request the corresponding pin before any gpio usage.
gpio-range-list ::= <single-gpio-range> [gpio-range-list]
single-gpio-range ::=
<pinctrl-phandle> <gpio-base> <pinctrl-base> <count>
gpio-phandle : phandle to pin controller node.
gpio-base : Base GPIO ID in the GPIO controller
pinctrl-base : Base pinctrl pin ID in the pin controller
count : The number of GPIOs/pins in this range
For this, the gpio controller can use a pinctrl phandle and pins to
announce the pinrange to the pin ctrl subsystem. For example,
The "pin controller node" mentioned above must conform to the bindings
described in ../pinctrl/pinctrl-bindings.txt.
Previous versions of this binding required all pin controller nodes that
were referenced by any gpio-ranges property to contain a property named
#gpio-range-cells with value <3>. This requirement is now deprecated.
However, that property may still exist in older device trees for
compatibility reasons, and would still be required even in new device
trees that need to be compatible with older software.
Example:
qe_pio_e: gpio-controller@1460 {
#gpio-cells = <2>;
@ -99,16 +112,8 @@ announce the pinrange to the pin ctrl subsystem. For example,
reg = <0x1460 0x18>;
gpio-controller;
gpio-ranges = <&pinctrl1 0 20 10>, <&pinctrl2 10 50 20>;
};
}
where,
&pinctrl1 and &pinctrl2 is the phandle to the pinctrl DT node.
Next values specify the base pin and number of pins for the range
handled by 'qe_pio_e' gpio. In the given example from base pin 20 to
pin 29 under pinctrl1 with gpio offset 0 and pin 50 to pin 69 under
pinctrl2 with gpio offset 10 is handled by this gpio controller.
The pinctrl node must have "#gpio-range-cells" property to show number of
arguments to pass with phandle from gpio controllers node.
Here, a single GPIO controller has GPIOs 0..9 routed to pin controller
pinctrl1's pins 20..29, and GPIOs 10..19 routed to pin controller pinctrl2's
pins 50..59.

7
Documentation/devicetree/bindings/gpio/mrvl-gpio.txt
View file

@ -10,8 +10,9 @@ Required properties:
There're three gpio interrupts in arch-pxa, and they're gpio0,
gpio1 and gpio_mux. There're only one gpio interrupt in arch-mmp,
gpio_mux.
- interrupt-name : Should be the name of irq resource. Each interrupt
binds its interrupt-name.
- interrupt-names : Should be the names of irq resources. Each interrupt
uses its own interrupt name, so there should be as many interrupt names
as referenced interrups.
- interrupt-controller : Identifies the node as an interrupt controller.
- #interrupt-cells: Specifies the number of cells needed to encode an
interrupt source.
@ -24,7 +25,7 @@ Example:
compatible = "marvell,mmp-gpio";
reg = <0xd4019000 0x1000>;
interrupts = <49>;
interrupt-name = "gpio_mux";
interrupt-names = "gpio_mux";
gpio-controller;
#gpio-cells = <1>;
interrupt-controller;

8
Documentation/devicetree/bindings/gpio/renesas,gpio-rcar.txt
View file

@ -23,6 +23,10 @@ Required Properties:
Please refer to gpio.txt in this directory for details of gpio-ranges property
and the common GPIO bindings used by client devices.
The GPIO controller also acts as an interrupt controller. It uses the default
two cells specifier as described in Documentation/devicetree/bindings/
interrupt-controller/interrupts.txt.
Example: R8A7779 (R-Car H1) GPIO controller nodes
gpio0: gpio@ffc40000 {
@ -33,6 +37,8 @@ Example: R8A7779 (R-Car H1) GPIO controller nodes
#gpio-cells = <2>;
gpio-controller;
gpio-ranges = <&pfc 0 0 32>;
interrupt-controller;
#interrupt-cells = <2>;
};
...
gpio6: gpio@ffc46000 {
@ -43,4 +49,6 @@ Example: R8A7779 (R-Car H1) GPIO controller nodes
#gpio-cells = <2>;
gpio-controller;
gpio-ranges = <&pfc 0 192 9>;
interrupt-controller;
#interrupt-cells = <2>;
};

7
Documentation/devicetree/bindings/gpu/samsung-g2d.txt
View file

@ -11,8 +11,11 @@ Required properties:
- interrupts : G2D interrupt number to the CPU.
- clocks : from common clock binding: handle to G2D clocks.
- clock-names : from common clock binding: must contain "sclk_fimg2d" and
"fimg2d", corresponding to entries in the clocks property.
- clock-names : names of clocks listed in clocks property, in the same
order, depending on SoC type:
- for S5PV210 and Exynos4 based SoCs: "fimg2d" and
"sclk_fimg2d"
- for Exynos5250 SoC: "fimg2d".
Example:
g2d@12800000 {

27
Documentation/devicetree/bindings/gpu/samsung-rotator.txt Normal file
View file

@ -0,0 +1,27 @@
* Samsung Image Rotator
Required properties:
- compatible : value should be one of the following:
(a) "samsung,exynos4210-rotator" for Rotator IP in Exynos4210
(b) "samsung,exynos4212-rotator" for Rotator IP in Exynos4212/4412
(c) "samsung,exynos5250-rotator" for Rotator IP in Exynos5250
- reg : Physical base address of the IP registers and length of memory
mapped region.
- interrupts : Interrupt specifier for rotator interrupt, according to format
specific to interrupt parent.
- clocks : Clock specifier for rotator clock, according to generic clock
bindings. (See Documentation/devicetree/bindings/clock/exynos*.txt)
- clock-names : Names of clocks. For exynos rotator, it should be "rotator".
Example:
rotator@12810000 {
compatible = "samsung,exynos4210-rotator";
reg = <0x12810000 0x1000>;
interrupts = <0 83 0>;
clocks = <&clock 278>;
clock-names = "rotator";
};

28
Documentation/devicetree/bindings/hid/hid-over-i2c.txt Normal file
View file

@ -0,0 +1,28 @@
* HID over I2C Device-Tree bindings
HID over I2C provides support for various Human Interface Devices over the
I2C bus. These devices can be for example touchpads, keyboards, touch screens
or sensors.
The specification has been written by Microsoft and is currently available here:
http://msdn.microsoft.com/en-us/library/windows/hardware/hh852380.aspx
If this binding is used, the kernel module i2c-hid will handle the communication
with the device and the generic hid core layer will handle the protocol.
Required properties:
- compatible: must be "hid-over-i2c"
- reg: i2c slave address
- hid-descr-addr: HID descriptor address
- interrupt-parent: the phandle for the interrupt controller
- interrupts: interrupt line
Example:
i2c-hid-dev@2c {
compatible = "hid-over-i2c";
reg = <0x2c>;
hid-descr-addr = <0x0020>;
interrupt-parent = <&gpx3>;
interrupts = <3 2>;
};

5
Documentation/devicetree/bindings/i2c/i2c-imx.txt
View file

@ -1,7 +1,10 @@
* Freescale Inter IC (I2C) and High Speed Inter IC (HS-I2C) for i.MX
Required properties:
- compatible : Should be "fsl,<chip>-i2c"
- compatible :
- "fsl,imx1-i2c" for I2C compatible with the one integrated on i.MX1 SoC
- "fsl,imx21-i2c" for I2C compatible with the one integrated on i.MX21 SoC
- "fsl,vf610-i2c" for I2C compatible with the one integrated on Vybrid vf610 SoC
- reg : Should contain I2C/HS-I2C registers location and length
- interrupts : Should contain I2C/HS-I2C interrupt

10
Documentation/devicetree/bindings/i2c/i2c-mv64xxx.txt
View file

@ -5,6 +5,7 @@ Required properties :
- reg : Offset and length of the register set for the device
- compatible : Should be "marvell,mv64xxx-i2c" or "allwinner,sun4i-i2c"
or "marvell,mv78230-i2c"
- interrupts : The interrupt number
Optional properties :
@ -20,3 +21,12 @@ Examples:
interrupts = <29>;
clock-frequency = <100000>;
};
For the Armada XP:
i2c@11000 {
compatible = "marvell,mv78230-i2c", "marvell,mv64xxx-i2c";
reg = <0x11000 0x100>;
interrupts = <29>;
clock-frequency = <100000>;
};

33
Documentation/devicetree/bindings/input/input-reset.txt Normal file
View file

@ -0,0 +1,33 @@
Input: sysrq reset sequence
A simple binding to represent a set of keys as described in
include/uapi/linux/input.h. This is to communicate a sequence of keys to the
sysrq driver. Upon holding the keys for a specified amount of time (if
specified) the system is sync'ed and reset.
Key sequences are global to the system but all the keys in a set must be coming
from the same input device.
The /chosen node should contain a 'linux,sysrq-reset-seq' child node to define
a set of keys.
Required property:
sysrq-reset-seq: array of Linux keycodes, one keycode per cell.
Optional property:
timeout-ms: duration keys must be pressed together in milliseconds before
generating a sysrq. If omitted the system is rebooted immediately when a valid
sequence has been recognized.
Example:
chosen {
linux,sysrq-reset-seq {
keyset = <0x03
0x04
0x0a>;
timeout-ms = <3000>;
};
};
Would represent KEY_2, KEY_3 and KEY_9.

2
Documentation/devicetree/bindings/input/touchscreen/egalax-ts.txt
View file

@ -6,7 +6,7 @@ Required properties:
- interrupt-parent: the phandle for the interrupt controller
- interrupts: touch controller interrupt
- wakeup-gpios: the gpio pin to be used for waking up the controller
as well as uased as irq pin
and also used as irq pin
Example:

72
Documentation/devicetree/bindings/leds/leds-lp55xx.txt
View file

@ -1,7 +1,7 @@
Binding for TI/National Semiconductor LP55xx Led Drivers
Required properties:
- compatible: "national,lp5521" or "national,lp5523" or "ti,lp5562"
- compatible: "national,lp5521" or "national,lp5523" or "ti,lp5562" or "ti,lp8501"
- reg: I2C slave address
- clock-mode: Input clock mode, (0: automode, 1: internal, 2: external)
@ -11,6 +11,11 @@ Each child has own specific current settings
Optional properties:
- label: Used for naming LEDs
- pwr-sel: LP8501 specific property. Power selection for output channels.
0: D1~9 are connected to VDD
1: D1~6 with VDD, D7~9 with VOUT
2: D1~6 with VOUT, D7~9 with VDD
3: D1~9 are connected to VOUT
Alternatively, each child can have specific channel name
- chan-name: Name of each channel name
@ -145,3 +150,68 @@ lp5562@30 {
max-cur = /bits/ 8 <0x60>;
};
};
example 4) LP8501
9 channels are defined. The 'pwr-sel' is LP8501 specific property.
Others are same as LP5523.
lp8501@32 {
compatible = "ti,lp8501";
reg = <0x32>;
clock-mode = /bits/ 8 <2>;
pwr-sel = /bits/ 8 <3>; /* D1~9 connected to VOUT */
chan0 {
chan-name = "d1";
led-cur = /bits/ 8 <0x14>;
max-cur = /bits/ 8 <0x20>;
};
chan1 {
chan-name = "d2";
led-cur = /bits/ 8 <0x14>;
max-cur = /bits/ 8 <0x20>;
};
chan2 {
chan-name = "d3";
led-cur = /bits/ 8 <0x14>;
max-cur = /bits/ 8 <0x20>;
};
chan3 {
chan-name = "d4";
led-cur = /bits/ 8 <0x14>;
max-cur = /bits/ 8 <0x20>;
};
chan4 {
chan-name = "d5";
led-cur = /bits/ 8 <0x14>;
max-cur = /bits/ 8 <0x20>;
};
chan5 {
chan-name = "d6";
led-cur = /bits/ 8 <0x14>;
max-cur = /bits/ 8 <0x20>;
};
chan6 {
chan-name = "d7";
led-cur = /bits/ 8 <0x14>;
max-cur = /bits/ 8 <0x20>;
};
chan7 {
chan-name = "d8";
led-cur = /bits/ 8 <0x14>;
max-cur = /bits/ 8 <0x20>;
};
chan8 {
chan-name = "d9";
led-cur = /bits/ 8 <0x14>;
max-cur = /bits/ 8 <0x20>;
};
};

47
Documentation/devicetree/bindings/leds/pca963x.txt Normal file
View file

@ -0,0 +1,47 @@
LEDs connected to pca9632, pca9633 or pca9634
Required properties:
- compatible : should be : "nxp,pca9632", "nxp,pca9633" or "nxp,pca9634"
Optional properties:
- nxp,totem-pole : use totem pole (push-pull) instead of default open-drain
- nxp,hw-blink : use hardware blinking instead of software blinking
Each led is represented as a sub-node of the nxp,pca963x device.
LED sub-node properties:
- label : (optional) see Documentation/devicetree/bindings/leds/common.txt
- reg : number of LED line (could be from 0 to 3 in pca9632 or pca9633
or 0 to 7 in pca9634)
- linux,default-trigger : (optional)
see Documentation/devicetree/bindings/leds/common.txt
Examples:
pca9632: pca9632 {
compatible = "nxp,pca9632";
#address-cells = <1>;
#size-cells = <0>;
reg = <0x62>;
red@0 {
label = "red";
reg = <0>;
linux,default-trigger = "none";
};
green@1 {
label = "green";
reg = <1>;
linux,default-trigger = "none";
};
blue@2 {
label = "blue";
reg = <2>;
linux,default-trigger = "none";
};
unused@3 {
label = "unused";
reg = <3>;
linux,default-trigger = "none";
};
};

48
Documentation/devicetree/bindings/media/i2c/adv7343.txt Normal file
View file

@ -0,0 +1,48 @@
* Analog Devices adv7343 video encoder
The ADV7343 are high speed, digital-to-analog video encoders in a 64-lead LQFP
package. Six high speed, 3.3 V, 11-bit video DACs provide support for composite
(CVBS), S-Video (Y-C), and component (YPrPb/RGB) analog outputs in standard
definition (SD), enhanced definition (ED), or high definition (HD) video
formats.
Required Properties :
- compatible: Must be "adi,adv7343"
Optional Properties :
- adi,power-mode-sleep-mode: on enable the current consumption is reduced to
micro ampere level. All DACs and the internal PLL
circuit are disabled.
- adi,power-mode-pll-ctrl: PLL and oversampling control. This control allows
internal PLL 1 circuit to be powered down and the
oversampling to be switched off.
- ad,adv7343-power-mode-dac: array configuring the power on/off DAC's 1..6,
0 = OFF and 1 = ON, Default value when this
property is not specified is <0 0 0 0 0 0>.
- ad,adv7343-sd-config-dac-out: array configure SD DAC Output's 1 and 2, 0 = OFF
and 1 = ON, Default value when this property is
not specified is <0 0>.
Example:
i2c0@1c22000 {
...
...
adv7343@2a {
compatible = "adi,adv7343";
reg = <0x2a>;
port {
adv7343_1: endpoint {
adi,power-mode-sleep-mode;
adi,power-mode-pll-ctrl;
/* Use DAC1..3, DAC6 */
adi,dac-enable = <1 1 1 0 0 1>;
/* Use SD DAC output 1 */
adi,sd-dac-enable = <1 0>;
};
};
};
...
};

19
Documentation/devicetree/bindings/media/i2c/ths8200.txt Normal file
View file

@ -0,0 +1,19 @@
* Texas Instruments THS8200 video encoder
The ths8200 device is a digital to analog converter used in DVD players, video
recorders, set-top boxes.
Required Properties :
- compatible : value must be "ti,ths8200"
Example:
i2c0@1c22000 {
...
...
ths8200@5c {
compatible = "ti,ths8200";
reg = <0x5c>;
};
...
};

53
Documentation/devicetree/bindings/media/i2c/tvp7002.txt Normal file
View file

@ -0,0 +1,53 @@
* Texas Instruments TV7002 video decoder
The TVP7002 device supports digitizing of video and graphics signal in RGB and
YPbPr color space.
Required Properties :
- compatible : Must be "ti,tvp7002"
Optional Properties:
- hsync-active: HSYNC Polarity configuration for the bus. Default value when
this property is not specified is <0>.
- vsync-active: VSYNC Polarity configuration for the bus. Default value when
this property is not specified is <0>.
- pclk-sample: Clock polarity of the bus. Default value when this property is
not specified is <0>.
- sync-on-green-active: Active state of Sync-on-green signal property of the
endpoint.
0 = Normal Operation (Active Low, Default)
1 = Inverted operation
- field-even-active: Active-high Field ID output polarity control of the bus.
Under normal operation, the field ID output is set to logic 1 for an odd field
(field 1) and set to logic 0 for an even field (field 0).
0 = Normal Operation (Active Low, Default)
1 = FID output polarity inverted
For further reading of port node refer Documentation/devicetree/bindings/media/
video-interfaces.txt.
Example:
i2c0@1c22000 {
...
...
tvp7002@5c {
compatible = "ti,tvp7002";
reg = <0x5c>;
port {
tvp7002_1: endpoint {
hsync-active = <1>;
vsync-active = <1>;
pclk-sample = <0>;
sync-on-green-active = <1>;
field-even-active = <0>;
};
};
};
...
};

11
Documentation/devicetree/bindings/media/s5p-mfc.txt
View file

@ -10,14 +10,15 @@ Required properties:
- compatible : value should be either one among the following
(a) "samsung,mfc-v5" for MFC v5 present in Exynos4 SoCs
(b) "samsung,mfc-v6" for MFC v6 present in Exynos5 SoCs
(b) "samsung,mfc-v7" for MFC v7 present in Exynos5420 SoC
- reg : Physical base address of the IP registers and length of memory
mapped region.
- interrupts : MFC interrupt number to the CPU.
- clocks : from common clock binding: handle to mfc clocks.
- clock-names : from common clock binding: must contain "sclk_mfc" and "mfc",
corresponding to entries in the clocks property.
- clocks : from common clock binding: handle to mfc clock.
- clock-names : from common clock binding: must contain "mfc",
corresponding to entry in the clocks property.
- samsung,mfc-r : Base address of the first memory bank used by MFC
for DMA contiguous memory allocation and its size.
@ -37,8 +38,8 @@ mfc: codec@13400000 {
reg = <0x13400000 0x10000>;
interrupts = <0 94 0>;
samsung,power-domain = <&pd_mfc>;
clocks = <&clock 170>, <&clock 273>;
clock-names = "sclk_mfc", "mfc";
clocks = <&clock 273>;
clock-names = "mfc";
};
Board specific DT entry:

2
Documentation/devicetree/bindings/media/video-interfaces.txt
View file

@ -88,6 +88,8 @@ Optional endpoint properties
- field-even-active: field signal level during the even field data transmission.
- pclk-sample: sample data on rising (1) or falling (0) edge of the pixel clock
signal.
- sync-on-green-active: active state of Sync-on-green (SoG) signal, 0/1 for
LOW/HIGH respectively.
- data-lanes: an array of physical data lane indexes. Position of an entry
determines the logical lane number, while the value of an entry indicates
physical lane, e.g. for 2-lane MIPI CSI-2 bus we could have

168
Documentation/devicetree/bindings/memory.txt Normal file
View file

@ -0,0 +1,168 @@
*** Memory binding ***
The /memory node provides basic information about the address and size
of the physical memory. This node is usually filled or updated by the
bootloader, depending on the actual memory configuration of the given
hardware.
The memory layout is described by the following node:
/ {
#address-cells = <(n)>;
#size-cells = <(m)>;
memory {
device_type = "memory";
reg = <(baseaddr1) (size1)
(baseaddr2) (size2)
...
(baseaddrN) (sizeN)>;
};
...
};
A memory node follows the typical device tree rules for "reg" property:
n: number of cells used to store base address value
m: number of cells used to store size value
baseaddrX: defines a base address of the defined memory bank
sizeX: the size of the defined memory bank
More than one memory bank can be defined.
*** Reserved memory regions ***
In /memory/reserved-memory node one can create child nodes describing
particular reserved (excluded from normal use) memory regions. Such
memory regions are usually designed for the special usage by various
device drivers. A good example are contiguous memory allocations or
memory sharing with other operating system on the same hardware board.
Those special memory regions might depend on the board configuration and
devices used on the target system.
Parameters for each memory region can be encoded into the device tree
with the following convention:
[(label):] (name) {
compatible = "linux,contiguous-memory-region", "reserved-memory-region";
reg = <(address) (size)>;
(linux,default-contiguous-region);
};
compatible: one or more of:
- "linux,contiguous-memory-region" - enables binding of this
region to Contiguous Memory Allocator (special region for
contiguous memory allocations, shared with movable system
memory, Linux kernel-specific).
- "reserved-memory-region" - compatibility is defined, given
region is assigned for exclusive usage for by the respective
devices.
reg: standard property defining the base address and size of
the memory region
linux,default-contiguous-region: property indicating that the region
is the default region for all contiguous memory
allocations, Linux specific (optional)
It is optional to specify the base address, so if one wants to use
autoconfiguration of the base address, '0' can be specified as a base
address in the 'reg' property.
The /memory/reserved-memory node must contain the same #address-cells
and #size-cells value as the root node.
*** Device node's properties ***
Once regions in the /memory/reserved-memory node have been defined, they
may be referenced by other device nodes. Bindings that wish to reference
memory regions should explicitly document their use of the following
property:
memory-region = <&phandle_to_defined_region>;
This property indicates that the device driver should use the memory
region pointed by the given phandle.
*** Example ***
This example defines a memory consisting of 4 memory banks. 3 contiguous
regions are defined for Linux kernel, one default of all device drivers
(named contig_mem, placed at 0x72000000, 64MiB), one dedicated to the
framebuffer device (labelled display_mem, placed at 0x78000000, 8MiB)
and one for multimedia processing (labelled multimedia_mem, placed at
0x77000000, 64MiB). 'display_mem' region is then assigned to fb@12300000
device for DMA memory allocations (Linux kernel drivers will use CMA is
available or dma-exclusive usage otherwise). 'multimedia_mem' is
assigned to scaler@12500000 and codec@12600000 devices for contiguous
memory allocations when CMA driver is enabled.
The reason for creating a separate region for framebuffer device is to
match the framebuffer base address to the one configured by bootloader,
so once Linux kernel drivers starts no glitches on the displayed boot
logo appears. Scaller and codec drivers should share the memory
allocations.
/ {
#address-cells = <1>;
#size-cells = <1>;
/* ... */
memory {
reg = <0x40000000 0x10000000
0x50000000 0x10000000
0x60000000 0x10000000
0x70000000 0x10000000>;
reserved-memory {
#address-cells = <1>;
#size-cells = <1>;
/*
* global autoconfigured region for contiguous allocations
* (used only with Contiguous Memory Allocator)
*/
contig_region@0 {
compatible = "linux,contiguous-memory-region";
reg = <0x0 0x4000000>;
linux,default-contiguous-region;
};
/*
* special region for framebuffer
*/
display_region: region@78000000 {
compatible = "linux,contiguous-memory-region", "reserved-memory-region";
reg = <0x78000000 0x800000>;
};
/*
* special region for multimedia processing devices
*/
multimedia_region: region@77000000 {
compatible = "linux,contiguous-memory-region";
reg = <0x77000000 0x4000000>;
};
};
};
/* ... */
fb0: fb@12300000 {
status = "okay";
memory-region = <&display_region>;
};
scaler: scaler@12500000 {
status = "okay";
memory-region = <&multimedia_region>;
};
codec: codec@12600000 {
status = "okay";
memory-region = <&multimedia_region>;
};
};

105
Documentation/devicetree/bindings/metag/pdc-intc.txt Normal file
View file

@ -0,0 +1,105 @@
* ImgTec Powerdown Controller (PDC) Interrupt Controller Binding
This binding specifies what properties must be available in the device tree
representation of a PDC IRQ controller. This has a number of input interrupt
lines which can wake the system, and are passed on through output interrupt
lines.
Required properties:
- compatible: Specifies the compatibility list for the interrupt controller.
The type shall be <string> and the value shall include "img,pdc-intc".
- reg: Specifies the base PDC physical address(s) and size(s) of the
addressable register space. The type shall be <prop-encoded-array>.
- interrupt-controller: The presence of this property identifies the node
as an interrupt controller. No property value shall be defined.
- #interrupt-cells: Specifies the number of cells needed to encode an
interrupt source. The type shall be a <u32> and the value shall be 2.
- num-perips: Number of waking peripherals.
- num-syswakes: Number of SysWake inputs.
- interrupts: List of interrupt specifiers. The first specifier shall be the
shared SysWake interrupt, and remaining specifies shall be PDC peripheral
interrupts in order.
* Interrupt Specifier Definition
Interrupt specifiers consists of 2 cells encoded as follows:
- <1st-cell>: The interrupt-number that identifies the interrupt source.
0-7: Peripheral interrupts
8-15: SysWake interrupts
- <2nd-cell>: The level-sense information, encoded using the Linux interrupt
flags as follows (only 4 valid for peripheral interrupts):
0 = none (decided by software)
1 = low-to-high edge triggered
2 = high-to-low edge triggered
3 = both edge triggered
4 = active-high level-sensitive (required for perip irqs)
8 = active-low level-sensitive
* Examples
Example 1:
/*
* TZ1090 PDC block
*/
pdc: pdc@0x02006000 {
// This is an interrupt controller node.
interrupt-controller;
// Three cells to encode interrupt sources.
#interrupt-cells = <2>;
// Offset address of 0x02006000 and size of 0x1000.
reg = <0x02006000 0x1000>;
// Compatible with Meta hardware trigger block.
compatible = "img,pdc-intc";
// Three peripherals are connected.
num-perips = <3>;
// Four SysWakes are connected.
num-syswakes = <4>;
interrupts = <18 4 /* level */>, /* Syswakes */
<30 4 /* level */>, /* Peripheral 0 (RTC) */
<29 4 /* level */>, /* Peripheral 1 (IR) */
<31 4 /* level */>; /* Peripheral 2 (WDT) */
};
Example 2:
/*
* An SoC peripheral that is wired through the PDC.
*/
rtc0 {
// The interrupt controller that this device is wired to.
interrupt-parent = <&pdc>;
// Interrupt source Peripheral 0
interrupts = <0 /* Peripheral 0 (RTC) */
4> /* IRQ_TYPE_LEVEL_HIGH */
};
Example 3:
/*
* An interrupt generating device that is wired to a SysWake pin.
*/
touchscreen0 {
// The interrupt controller that this device is wired to.
interrupt-parent = <&pdc>;
// Interrupt source SysWake 0 that is active-low level-sensitive
interrupts = <8 /* SysWake0 */
8 /* IRQ_TYPE_LEVEL_LOW */>;
};

2
Documentation/devicetree/bindings/mfd/cros-ec.txt
View file

@ -4,7 +4,7 @@ Google's ChromeOS EC is a Cortex-M device which talks to the AP and
implements various function such as keyboard and battery charging.
The EC can be connect through various means (I2C, SPI, LPC) and the
compatible string used depends on the inteface. Each connection method has
compatible string used depends on the interface. Each connection method has
its own driver which connects to the top level interface-agnostic EC driver.
Other Linux driver (such as cros-ec-keyb for the matrix keyboard) connect to
the top-level driver.

2
Documentation/devicetree/bindings/mfd/palmas.txt
View file

@ -5,6 +5,7 @@ twl6035 (palmas)
twl6037 (palmas)
tps65913 (palmas)
tps65914 (palmas)
tps659038
Required properties:
- compatible : Should be from the list
@ -14,6 +15,7 @@ Required properties:
ti,tps65913
ti,tps65914
ti,tps80036
ti,tps659038
and also the generic series names
ti,palmas
- interrupt-controller : palmas has its own internal IRQs

109
Documentation/devicetree/bindings/mfd/s2mps11.txt Normal file
View file

@ -0,0 +1,109 @@
* Samsung S2MPS11 Voltage and Current Regulator
The Samsung S2MP211 is a multi-function device which includes voltage and
current regulators, RTC, charger controller and other sub-blocks. It is
interfaced to the host controller using a I2C interface. Each sub-block is
addressed by the host system using different I2C slave address.
Required properties:
- compatible: Should be "samsung,s2mps11-pmic".
- reg: Specifies the I2C slave address of the pmic block. It should be 0x66.
Optional properties:
- interrupt-parent: Specifies the phandle of the interrupt controller to which
the interrupts from s2mps11 are delivered to.
- interrupts: Interrupt specifiers for interrupt sources.
Optional nodes:
- clocks: s2mps11 provides three(AP/CP/BT) buffered 32.768 KHz outputs, so to
register these as clocks with common clock framework instantiate a sub-node
named "clocks". It uses the common clock binding documented in :
[Documentation/devicetree/bindings/clock/clock-bindings.txt]
- #clock-cells: should be 1.
- The following is the list of clocks generated by the controller. Each clock
is assigned an identifier and client nodes use this identifier to specify
the clock which they consume.
Clock ID
----------------------
32KhzAP 0
32KhzCP 1
32KhzBT 2
- regulators: The regulators of s2mps11 that have to be instantiated should be
included in a sub-node named 'regulators'. Regulator nodes included in this
sub-node should be of the format as listed below.
regulator_name {
[standard regulator constraints....];
};
regulator-ramp-delay for BUCKs = [6250/12500/25000(default)/50000] uV/us
BUCK[2/3/4/6] supports disabling ramp delay on hardware, so explictly
regulator-ramp-delay = <0> can be used for them to disable ramp delay.
In absence of regulator-ramp-delay property, default ramp delay will be used.
NOTE: Some BUCKs share the ramp rate setting i.e. same ramp value will be set
for a particular group of BUCKs. So provide same regulator-ramp-delay<value>.
Grouping of BUCKs sharing ramp rate setting is as follow : BUCK[1, 6],
BUCK[3, 4], and BUCK[7, 8, 10]
The regulator constraints inside the regulator nodes use the standard regulator
bindings which are documented elsewhere.
The following are the names of the regulators that the s2mps11 pmic block
supports. Note: The 'n' in LDOn and BUCKn represents the LDO or BUCK number
as per the datasheet of s2mps11.
- LDOn
- valid values for n are 1 to 28
- Example: LDO0, LD01, LDO28
- BUCKn
- valid values for n are 1 to 9.
- Example: BUCK1, BUCK2, BUCK9
Example:
s2mps11_pmic@66 {
compatible = "samsung,s2mps11-pmic";
reg = <0x66>;
s2m_osc: clocks{
#clock-cells = 1;
clock-output-names = "xx", "yy", "zz";
};
regulators {
ldo1_reg: LDO1 {
regulator-name = "VDD_ABB_3.3V";
regulator-min-microvolt = <3300000>;
regulator-max-microvolt = <3300000>;
};
ldo2_reg: LDO2 {
regulator-name = "VDD_ALIVE_1.1V";
regulator-min-microvolt = <1100000>;
regulator-max-microvolt = <1100000>;
regulator-always-on;
};
buck1_reg: BUCK1 {
regulator-name = "vdd_mif";
regulator-min-microvolt = <950000>;
regulator-max-microvolt = <1350000>;
regulator-always-on;
regulator-boot-on;
};
buck2_reg: BUCK2 {
regulator-name = "vdd_arm";
regulator-min-microvolt = <950000>;
regulator-max-microvolt = <1350000>;
regulator-always-on;
regulator-boot-on;
regulator-ramp-delay = <50000>;
};
};
};

23
Documentation/devicetree/bindings/misc/atmel-ssc.txt
View file

@ -7,9 +7,30 @@ Required properties:
- reg: Should contain SSC registers location and length
- interrupts: Should contain SSC interrupt
Example:
Required properties for devices compatible with "atmel,at91sam9g45-ssc":
- dmas: DMA specifier, consisting of a phandle to DMA controller node,
the memory interface and SSC DMA channel ID (for tx and rx).
See Documentation/devicetree/bindings/dma/atmel-dma.txt for details.
- dma-names: Must be "tx", "rx".
Examples:
- PDC transfer:
ssc0: ssc@fffbc000 {
compatible = "atmel,at91rm9200-ssc";
reg = <0xfffbc000 0x4000>;
interrupts = <14 4 5>;
};
- DMA transfer:
ssc0: ssc@f0010000 {
compatible = "atmel,at91sam9g45-ssc";
reg = <0xf0010000 0x4000>;
interrupts = <28 4 5>;
dmas = <&dma0 1 13>,
<&dma0 1 14>;
dma-names = "tx", "rx";
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_ssc0_tx &pinctrl_ssc0_rx>;
status = "disabled";
};

5
Documentation/devicetree/bindings/misc/smc.txt
View file

@ -4,11 +4,12 @@ This binding defines the location of the bounce buffer
used for non-secure to secure communications.
Required properties:
- compatible : "bcm,kona-smc"
- compatible : "brcm,kona-smc"
- DEPRECATED: compatible : "bcm,kona-smc"
- reg : Location and size of bounce buffer
Example:
smc@0x3404c000 {
compatible = "bcm,bcm11351-smc", "bcm,kona-smc";
compatible = "brcm,bcm11351-smc", "brcm,kona-smc";
reg = <0x3404c000 0x400>; //1 KiB in SRAM
};

4
Documentation/devicetree/bindings/mmc/fsl-esdhc.txt
View file

@ -19,6 +19,9 @@ Optional properties:
"bus-width = <1>" property.
- sdhci,auto-cmd12: specifies that a controller can only handle auto
CMD12.
- voltage-ranges : two cells are required, first cell specifies minimum
slot voltage (mV), second cell specifies maximum slot voltage (mV).
Several ranges could be specified.
Example:
@ -29,4 +32,5 @@ sdhci@2e000 {
interrupt-parent = <&ipic>;
/* Filled in by U-Boot */
clock-frequency = <0>;
voltage-ranges = <3300 3300>;
};

5
Documentation/devicetree/bindings/mmc/bcm,kona-sdhci.txt → Documentation/devicetree/bindings/mmc/kona-sdhci.txt
View file

@ -4,12 +4,13 @@ This file documents differences between the core properties in mmc.txt
and the properties present in the bcm281xx SDHCI
Required properties:
- compatible : Should be "bcm,kona-sdhci"
- compatible : Should be "brcm,kona-sdhci"
- DEPRECATED: compatible : Should be "bcm,kona-sdhci"
Example:
sdio2: sdio@0x3f1a0000 {
compatible = "bcm,kona-sdhci";
compatible = "brcm,kona-sdhci";
reg = <0x3f1a0000 0x10000>;
interrupts = <0x0 74 0x4>;
};

28
Documentation/devicetree/bindings/mtd/atmel-nand.txt
View file

@ -15,6 +15,7 @@ Required properties:
optional gpio and may be set to 0 if not present.
Optional properties:
- atmel,nand-has-dma : boolean to support dma transfer for nand read/write.
- nand-ecc-mode : String, operation mode of the NAND ecc mode, soft by default.
Supported values are: "none", "soft", "hw", "hw_syndrome", "hw_oob_first",
"soft_bch".
@ -29,6 +30,14 @@ Optional properties:
sector size 1024.
- nand-bus-width : 8 or 16 bus width if not present 8
- nand-on-flash-bbt: boolean to enable on flash bbt option if not present false
- Nand Flash Controller(NFC) is a slave driver under Atmel nand flash
- Required properties:
- compatible : "atmel,sama5d3-nfc".
- reg : should specify the address and size used for NFC command registers,
NFC registers and NFC Sram. NFC Sram address and size can be absent
if don't want to use it.
- Optional properties:
- atmel,write-by-sram: boolean to enable NFC write by sram.
Examples:
nand0: nand@40000000,0 {
@ -77,3 +86,22 @@ nand0: nand@40000000 {
...
};
};
/* for NFC supported chips */
nand0: nand@40000000 {
compatible = "atmel,at91rm9200-nand";
#address-cells = <1>;
#size-cells = <1>;
ranges;
...
nfc@70000000 {
compatible = "atmel,sama5d3-nfc";
#address-cells = <1>;
#size-cells = <1>;
reg = <
0x70000000 0x10000000 /* NFC Command Registers */
0xffffc000 0x00000070 /* NFC HSMC regs */
0x00200000 0x00100000 /* NFC SRAM banks */
>;
};
};

25
Documentation/devicetree/bindings/mtd/fsmc-nand.txt
View file

@ -1,4 +1,5 @@
* FSMC NAND
ST Microelectronics Flexible Static Memory Controller (FSMC)
NAND Interface
Required properties:
- compatible : "st,spear600-fsmc-nand", "stericsson,fsmc-nand"
@ -9,6 +10,26 @@ Optional properties:
- bank-width : Width (in bytes) of the device. If not present, the width
defaults to 1 byte
- nand-skip-bbtscan: Indicates the the BBT scanning should be skipped
- timings: array of 6 bytes for NAND timings. The meanings of these bytes
are:
byte 0 TCLR : CLE to RE delay in number of AHB clock cycles, only 4 bits
are valid. Zero means one clockcycle, 15 means 16 clock
cycles.
byte 1 TAR : ALE to RE delay, 4 bits are valid. Same format as TCLR.
byte 2 THIZ : number of HCLK clock cycles during which the data bus is
kept in Hi-Z (tristate) after the start of a write access.
Only valid for write transactions. Zero means zero cycles,
255 means 255 cycles.
byte 3 THOLD : number of HCLK clock cycles to hold the address (and data
when writing) after the command deassertation. Zero means
one cycle, 255 means 256 cycles.
byte 4 TWAIT : number of HCLK clock cycles to assert the command to the
NAND flash in response to SMWAITn. Zero means 1 cycle,
255 means 256 cycles.
byte 5 TSET : number of HCLK clock cycles to assert the address before the
command is asserted. Zero means one cycle, 255 means 256
cycles.
- bank: default NAND bank to use (0-3 are valid, 0 is the default).
Example:
@ -24,6 +45,8 @@ Example:
bank-width = <1>;
nand-skip-bbtscan;
timings = /bits/ 8 <0 0 0 2 3 0>;
bank = <1>;
partition@0 {
...

1
Documentation/devicetree/bindings/mtd/partition.txt
View file

@ -4,6 +4,7 @@ Partitions can be represented by sub-nodes of an mtd device. This can be used
on platforms which have strong conventions about which portions of a flash are
used for what purposes, but which don't use an on-flash partition table such
as RedBoot.
NOTE: if the sub-node has a compatible string, then it is not a partition.
#address-cells & #size-cells must both be present in the mtd device. There are
two valid values for both:

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