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

Merge branch 'master' into for-3.12/upstream 

Sync with Linus' tree to be able to apply fixup patch on top
of 9d9a04ee75 ("HID: apple: Add support for the 2013 Macbook Air")

Signed-off-by: Jiri Kosina <jkosina@suse.cz>
hifive-unleashed-5.1
Jiri Kosina 2013-09-04 10:49:39 +02:00
parent 6c2794a298 58c59bc997
commit efd15f5f4f
5117 changed files with 271426 additions and 184323 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

1
.gitignore vendored
View File

@ -29,6 +29,7 @@ modules.builtin
*.bz2
*.lzma
*.xz
*.lz4
*.lzo
*.patch
*.gcno

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

@ -54,6 +54,13 @@ Description: Interface for making ib_srp connect to a new target.
ib_srp. Specifying a value that exceeds cmd_sg_entries is
only safe with partial memory descriptor list support enabled
(allow_ext_sg=1).
* comp_vector, a number in the range 0..n-1 specifying the
MSI-X completion vector. Some HCA's allocate multiple (n)
MSI-X vectors per HCA port. If the IRQ affinity masks of
these interrupts have been configured such that each MSI-X
interrupt is handled by a different CPU then the comp_vector
parameter can be used to spread the SRP completion workload
over multiple CPU's.
What: /sys/class/infiniband_srp/srp-<hca>-<port_number>/ibdev
Date: January 2, 2006

10
Documentation/ABI/stable/sysfs-module
View File

@ -4,9 +4,13 @@ Description:
/sys/module/MODULENAME
The name of the module that is in the kernel. This
module name will show up either if the module is built
directly into the kernel, or if it is loaded as a
dynamic module.
module name will always show up if the module is loaded as a
dynamic module. If it is built directly into the kernel, it
will only show up if it has a version or at least one
parameter.
Note: The conditions of creation in the built-in case are not
by design and may be removed in the future.
/sys/module/MODULENAME/parameters
This directory contains individual files that are each

2
Documentation/ABI/testing/sysfs-bus-event_source-devices-events
View File

@ -29,7 +29,7 @@ Description: Generic performance monitoring events
What: /sys/devices/cpu/events/PM_1PLUS_PPC_CMPL
/sys/devices/cpu/events/PM_BRU_FIN
/sys/devices/cpu/events/PM_BRU_MPRED
/sys/devices/cpu/events/PM_BR_MPRED
/sys/devices/cpu/events/PM_CMPLU_STALL
/sys/devices/cpu/events/PM_CMPLU_STALL_BRU
/sys/devices/cpu/events/PM_CMPLU_STALL_DCACHE_MISS

79
Documentation/ABI/testing/sysfs-class-pwm 100644
View File

@ -0,0 +1,79 @@
What: /sys/class/pwm/
Date: May 2013
KernelVersion: 3.11
Contact: H Hartley Sweeten <hsweeten@visionengravers.com>
Description:
The pwm/ class sub-directory belongs to the Generic PWM
Framework and provides a sysfs interface for using PWM
channels.
What: /sys/class/pwm/pwmchipN/
Date: May 2013
KernelVersion: 3.11
Contact: H Hartley Sweeten <hsweeten@visionengravers.com>
Description:
A /sys/class/pwm/pwmchipN directory is created for each
probed PWM controller/chip where N is the base of the
PWM chip.
What: /sys/class/pwm/pwmchipN/npwm
Date: May 2013
KernelVersion: 3.11
Contact: H Hartley Sweeten <hsweeten@visionengravers.com>
Description:
The number of PWM channels supported by the PWM chip.
What: /sys/class/pwm/pwmchipN/export
Date: May 2013
KernelVersion: 3.11
Contact: H Hartley Sweeten <hsweeten@visionengravers.com>
Description:
Exports a PWM channel from the PWM chip for sysfs control.
Value is between 0 and /sys/class/pwm/pwmchipN/npwm - 1.
What: /sys/class/pwm/pwmchipN/unexport
Date: May 2013
KernelVersion: 3.11
Contact: H Hartley Sweeten <hsweeten@visionengravers.com>
Description:
Unexports a PWM channel.
What: /sys/class/pwm/pwmchipN/pwmX
Date: May 2013
KernelVersion: 3.11
Contact: H Hartley Sweeten <hsweeten@visionengravers.com>
Description:
A /sys/class/pwm/pwmchipN/pwmX directory is created for
each exported PWM channel where X is the exported PWM
channel number.
What: /sys/class/pwm/pwmchipN/pwmX/period
Date: May 2013
KernelVersion: 3.11
Contact: H Hartley Sweeten <hsweeten@visionengravers.com>
Description:
Sets the PWM signal period in nanoseconds.
What: /sys/class/pwm/pwmchipN/pwmX/duty_cycle
Date: May 2013
KernelVersion: 3.11
Contact: H Hartley Sweeten <hsweeten@visionengravers.com>
Description:
Sets the PWM signal duty cycle in nanoseconds.
What: /sys/class/pwm/pwmchipN/pwmX/polarity
Date: May 2013
KernelVersion: 3.11
Contact: H Hartley Sweeten <hsweeten@visionengravers.com>
Description:
Sets the output polarity of the PWM signal to "normal" or
"inversed".
What: /sys/class/pwm/pwmchipN/pwmX/enable
Date: May 2013
KernelVersion: 3.11
Contact: H Hartley Sweeten <hsweeten@visionengravers.com>
Description:
Enable/disable the PWM signal.
0 is disabled
1 is enabled

14
Documentation/ABI/testing/sysfs-devices-edac
View File

@ -77,7 +77,7 @@ Description: Read/Write attribute file that controls memory scrubbing.
What: /sys/devices/system/edac/mc/mc*/max_location
Date: April 2012
Contact: Mauro Carvalho Chehab <mchehab@redhat.com>
Contact: Mauro Carvalho Chehab <m.chehab@samsung.com>
linux-edac@vger.kernel.org
Description: This attribute file displays the information about the last
available memory slot in this memory controller. It is used by
@ -85,7 +85,7 @@ Description: This attribute file displays the information about the last
What: /sys/devices/system/edac/mc/mc*/(dimm|rank)*/size
Date: April 2012
Contact: Mauro Carvalho Chehab <mchehab@redhat.com>
Contact: Mauro Carvalho Chehab <m.chehab@samsung.com>
linux-edac@vger.kernel.org
Description: This attribute file will display the size of dimm or rank.
For dimm*/size, this is the size, in MB of the DIMM memory
@ -96,14 +96,14 @@ Description: This attribute file will display the size of dimm or rank.
What: /sys/devices/system/edac/mc/mc*/(dimm|rank)*/dimm_dev_type
Date: April 2012
Contact: Mauro Carvalho Chehab <mchehab@redhat.com>
Contact: Mauro Carvalho Chehab <m.chehab@samsung.com>
linux-edac@vger.kernel.org
Description: This attribute file will display what type of DRAM device is
being utilized on this DIMM (x1, x2, x4, x8, ...).
What: /sys/devices/system/edac/mc/mc*/(dimm|rank)*/dimm_edac_mode
Date: April 2012
Contact: Mauro Carvalho Chehab <mchehab@redhat.com>
Contact: Mauro Carvalho Chehab <m.chehab@samsung.com>
linux-edac@vger.kernel.org
Description: This attribute file will display what type of Error detection
and correction is being utilized. For example: S4ECD4ED would
@ -111,7 +111,7 @@ Description: This attribute file will display what type of Error detection
What: /sys/devices/system/edac/mc/mc*/(dimm|rank)*/dimm_label
Date: April 2012
Contact: Mauro Carvalho Chehab <mchehab@redhat.com>
Contact: Mauro Carvalho Chehab <m.chehab@samsung.com>
linux-edac@vger.kernel.org
Description: This control file allows this DIMM to have a label assigned
to it. With this label in the module, when errors occur
@ -126,14 +126,14 @@ Description: This control file allows this DIMM to have a label assigned
What: /sys/devices/system/edac/mc/mc*/(dimm|rank)*/dimm_location
Date: April 2012
Contact: Mauro Carvalho Chehab <mchehab@redhat.com>
Contact: Mauro Carvalho Chehab <m.chehab@samsung.com>
linux-edac@vger.kernel.org
Description: This attribute file will display the location (csrow/channel,
branch/channel/slot or channel/slot) of the dimm or rank.
What: /sys/devices/system/edac/mc/mc*/(dimm|rank)*/dimm_mem_type
Date: April 2012
Contact: Mauro Carvalho Chehab <mchehab@redhat.com>
Contact: Mauro Carvalho Chehab <m.chehab@samsung.com>
linux-edac@vger.kernel.org
Description: This attribute file will display what type of memory is
currently on this csrow. Normally, either buffered or

21
Documentation/ABI/testing/sysfs-driver-intel-rapid-start 100644
View File

@ -0,0 +1,21 @@
What: /sys/bus/acpi/intel-rapid-start/wakeup_events
Date: July 2, 2013
KernelVersion: 3.11
Contact: Matthew Garrett <mjg59@srcf.ucam.org>
Description: An integer representing a set of wakeup events as follows:
1: Wake to enter hibernation when the wakeup timer expires
2: Wake to enter hibernation when the battery reaches a
critical level
These values are ORed together. For example, a value of 3
indicates that the system will wake to enter hibernation when
either the wakeup timer expires or the battery reaches a
critical level.
What: /sys/bus/acpi/intel-rapid-start/wakeup_time
Date: July 2, 2013
KernelVersion: 3.11
Contact: Matthew Garrett <mjg59@srcf.ucam.org>
Description: An integer representing the length of time the system will
remain asleep before waking up to enter hibernation.
This value is in minutes.

17
Documentation/ABI/testing/sysfs-driver-xen-blkback 100644
View File

@ -0,0 +1,17 @@
What: /sys/module/xen_blkback/parameters/max_buffer_pages
Date: March 2013
KernelVersion: 3.11
Contact: Roger Pau Monné <roger.pau@citrix.com>
Description:
Maximum number of free pages to keep in each block
backend buffer.
What: /sys/module/xen_blkback/parameters/max_persistent_grants
Date: March 2013
KernelVersion: 3.11
Contact: Roger Pau Monné <roger.pau@citrix.com>
Description:
Maximum number of grants to map persistently in
blkback. If the frontend tries to use more than
max_persistent_grants, the LRU kicks in and starts
removing 5% of max_persistent_grants every 100ms.

10
Documentation/ABI/testing/sysfs-driver-xen-blkfront 100644
View File

@ -0,0 +1,10 @@
What: /sys/module/xen_blkfront/parameters/max
Date: June 2013
KernelVersion: 3.11
Contact: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Description:
Maximum number of segments that the frontend will negotiate
with the backend for indirect descriptors. The default value
is 32 - higher value means more potential throughput but more
memory usage. The backend picks the minimum of the frontend
and its default backend value.

13
Documentation/DocBook/80211.tmpl
View File

@ -127,14 +127,11 @@
!Finclude/net/cfg80211.h cfg80211_ibss_params
!Finclude/net/cfg80211.h cfg80211_connect_params
!Finclude/net/cfg80211.h cfg80211_pmksa
!Finclude/net/cfg80211.h cfg80211_send_rx_auth
!Finclude/net/cfg80211.h cfg80211_send_auth_timeout
!Finclude/net/cfg80211.h cfg80211_send_rx_assoc
!Finclude/net/cfg80211.h cfg80211_send_assoc_timeout
!Finclude/net/cfg80211.h cfg80211_send_deauth
!Finclude/net/cfg80211.h __cfg80211_send_deauth
!Finclude/net/cfg80211.h cfg80211_send_disassoc
!Finclude/net/cfg80211.h __cfg80211_send_disassoc
!Finclude/net/cfg80211.h cfg80211_rx_mlme_mgmt
!Finclude/net/cfg80211.h cfg80211_auth_timeout
!Finclude/net/cfg80211.h cfg80211_rx_assoc_resp
!Finclude/net/cfg80211.h cfg80211_assoc_timeout
!Finclude/net/cfg80211.h cfg80211_tx_mlme_mgmt
!Finclude/net/cfg80211.h cfg80211_ibss_joined
!Finclude/net/cfg80211.h cfg80211_connect_result
!Finclude/net/cfg80211.h cfg80211_roamed

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

@ -84,7 +84,7 @@ X!Iinclude/linux/kobject.h
<sect1><title>Kernel utility functions</title>
!Iinclude/linux/kernel.h
!Ekernel/printk.c
!Ekernel/printk/printk.c
!Ekernel/panic.c
!Ekernel/sys.c
!Ekernel/rcupdate.c
@ -126,6 +126,8 @@ X!Edrivers/base/interface.c
</sect1>
<sect1><title>Device Drivers DMA Management</title>
!Edrivers/base/dma-buf.c
!Edrivers/base/reservation.c
!Iinclude/linux/reservation.h
!Edrivers/base/dma-coherent.c
!Edrivers/base/dma-mapping.c
</sect1>

277
Documentation/DocBook/drm.tmpl
View File

@ -186,11 +186,12 @@
<varlistentry>
<term>DRIVER_HAVE_IRQ</term><term>DRIVER_IRQ_SHARED</term>
<listitem><para>
DRIVER_HAVE_IRQ indicates whether the driver has an IRQ handler. The
DRM core will automatically register an interrupt handler when the
flag is set. DRIVER_IRQ_SHARED indicates whether the device &amp;
handler support shared IRQs (note that this is required of PCI
drivers).
DRIVER_HAVE_IRQ indicates whether the driver has an IRQ handler
managed by the DRM Core. The core will support simple IRQ handler
installation when the flag is set. The installation process is
described in <xref linkend="drm-irq-registration"/>.</para>
<para>DRIVER_IRQ_SHARED indicates whether the device &amp; handler
support shared IRQs (note that this is required of PCI drivers).
</para></listitem>
</varlistentry>
<varlistentry>
@ -344,50 +345,71 @@ char *date;</synopsis>
The DRM core tries to facilitate IRQ handler registration and
unregistration by providing <function>drm_irq_install</function> and
<function>drm_irq_uninstall</function> functions. Those functions only
support a single interrupt per device.
</para>
<!--!Fdrivers/char/drm/drm_irq.c drm_irq_install-->
<para>
Both functions get the device IRQ by calling
<function>drm_dev_to_irq</function>. This inline function will call a
bus-specific operation to retrieve the IRQ number. For platform devices,
<function>platform_get_irq</function>(..., 0) is used to retrieve the
IRQ number.
</para>
<para>
<function>drm_irq_install</function> starts by calling the
<methodname>irq_preinstall</methodname> driver operation. The operation
is optional and must make sure that the interrupt will not get fired by
clearing all pending interrupt flags or disabling the interrupt.
</para>
<para>
The IRQ will then be requested by a call to
<function>request_irq</function>. If the DRIVER_IRQ_SHARED driver
feature flag is set, a shared (IRQF_SHARED) IRQ handler will be
requested.
</para>
<para>
The IRQ handler function must be provided as the mandatory irq_handler
driver operation. It will get passed directly to
<function>request_irq</function> and thus has the same prototype as all
IRQ handlers. It will get called with a pointer to the DRM device as the
second argument.
</para>
<para>
Finally the function calls the optional
<methodname>irq_postinstall</methodname> driver operation. The operation
usually enables interrupts (excluding the vblank interrupt, which is
enabled separately), but drivers may choose to enable/disable interrupts
at a different time.
</para>
<para>
<function>drm_irq_uninstall</function> is similarly used to uninstall an
IRQ handler. It starts by waking up all processes waiting on a vblank
interrupt to make sure they don't hang, and then calls the optional
<methodname>irq_uninstall</methodname> driver operation. The operation
must disable all hardware interrupts. Finally the function frees the IRQ
by calling <function>free_irq</function>.
support a single interrupt per device, devices that use more than one
IRQs need to be handled manually.
</para>
<sect4>
<title>Managed IRQ Registration</title>
<para>
Both the <function>drm_irq_install</function> and
<function>drm_irq_uninstall</function> functions get the device IRQ by
calling <function>drm_dev_to_irq</function>. This inline function will
call a bus-specific operation to retrieve the IRQ number. For platform
devices, <function>platform_get_irq</function>(..., 0) is used to
retrieve the IRQ number.
</para>
<para>
<function>drm_irq_install</function> starts by calling the
<methodname>irq_preinstall</methodname> driver operation. The operation
is optional and must make sure that the interrupt will not get fired by
clearing all pending interrupt flags or disabling the interrupt.
</para>
<para>
The IRQ will then be requested by a call to
<function>request_irq</function>. If the DRIVER_IRQ_SHARED driver
feature flag is set, a shared (IRQF_SHARED) IRQ handler will be
requested.
</para>
<para>
The IRQ handler function must be provided as the mandatory irq_handler
driver operation. It will get passed directly to
<function>request_irq</function> and thus has the same prototype as all
IRQ handlers. It will get called with a pointer to the DRM device as the
second argument.
</para>
<para>
Finally the function calls the optional
<methodname>irq_postinstall</methodname> driver operation. The operation
usually enables interrupts (excluding the vblank interrupt, which is
enabled separately), but drivers may choose to enable/disable interrupts
at a different time.
</para>
<para>
<function>drm_irq_uninstall</function> is similarly used to uninstall an
IRQ handler. It starts by waking up all processes waiting on a vblank
interrupt to make sure they don't hang, and then calls the optional
<methodname>irq_uninstall</methodname> driver operation. The operation
must disable all hardware interrupts. Finally the function frees the IRQ
by calling <function>free_irq</function>.
</para>
</sect4>
<sect4>
<title>Manual IRQ Registration</title>
<para>
Drivers that require multiple interrupt handlers can't use the managed
IRQ registration functions. In that case IRQs must be registered and
unregistered manually (usually with the <function>request_irq</function>
and <function>free_irq</function> functions, or their devm_* equivalent).
</para>
<para>
When manually registering IRQs, drivers must not set the DRIVER_HAVE_IRQ
driver feature flag, and must not provide the
<methodname>irq_handler</methodname> driver operation. They must set the
<structname>drm_device</structname> <structfield>irq_enabled</structfield>
field to 1 upon registration of the IRQs, and clear it to 0 after
unregistering the IRQs.
</para>
</sect4>
</sect3>
<sect3>
<title>Memory Manager Initialization</title>
@ -434,7 +456,7 @@ char *date;</synopsis>
The DRM core includes two memory managers, namely Translation Table Maps
(TTM) and Graphics Execution Manager (GEM). TTM was the first DRM memory
manager to be developed and tried to be a one-size-fits-them all
solution. It provides a single userspace API to accomodate the need of
solution. It provides a single userspace API to accommodate the need of
all hardware, supporting both Unified Memory Architecture (UMA) devices
and devices with dedicated video RAM (i.e. most discrete video cards).
This resulted in a large, complex piece of code that turned out to be
@ -701,7 +723,7 @@ char *date;</synopsis>
<para>
Similar to global names, GEM file descriptors are also used to share GEM
objects across processes. They offer additional security: as file
descriptors must be explictly sent over UNIX domain sockets to be shared
descriptors must be explicitly sent over UNIX domain sockets to be shared
between applications, they can't be guessed like the globally unique GEM
names.
</para>
@ -1154,7 +1176,7 @@ int max_width, max_height;</synopsis>
</para>
<para>
The <methodname>page_flip</methodname> operation schedules a page flip.
Once any pending rendering targetting the new frame buffer has
Once any pending rendering targeting the new frame buffer has
completed, the CRTC will be reprogrammed to display that frame buffer
after the next vertical refresh. The operation must return immediately
without waiting for rendering or page flip to complete and must block
@ -1213,6 +1235,15 @@ int max_width, max_height;</synopsis>
<sect4>
<title>Miscellaneous</title>
<itemizedlist>
<listitem>
<synopsis>void (*set_property)(struct drm_crtc *crtc,
struct drm_property *property, uint64_t value);</synopsis>
<para>
Set the value of the given CRTC property to
<parameter>value</parameter>. See <xref linkend="drm-kms-properties"/>
for more information about properties.
</para>
</listitem>
<listitem>
<synopsis>void (*gamma_set)(struct drm_crtc *crtc, u16 *r, u16 *g, u16 *b,
uint32_t start, uint32_t size);</synopsis>
@ -1363,6 +1394,15 @@ int max_width, max_height;</synopsis>
<xref linkend="drm-kms-init"/>.
</para>
</listitem>
<listitem>
<synopsis>void (*set_property)(struct drm_plane *plane,
struct drm_property *property, uint64_t value);</synopsis>
<para>
Set the value of the given plane property to
<parameter>value</parameter>. See <xref linkend="drm-kms-properties"/>
for more information about properties.
</para>
</listitem>
</itemizedlist>
</sect3>
</sect2>
@ -1571,6 +1611,15 @@ int max_width, max_height;</synopsis>
<sect4>
<title>Miscellaneous</title>
<itemizedlist>
<listitem>
<synopsis>void (*set_property)(struct drm_connector *connector,
struct drm_property *property, uint64_t value);</synopsis>
<para>
Set the value of the given connector property to
<parameter>value</parameter>. See <xref linkend="drm-kms-properties"/>
for more information about properties.
</para>
</listitem>
<listitem>
<synopsis>void (*destroy)(struct drm_connector *connector);</synopsis>
<para>
@ -1846,10 +1895,6 @@ void intel_crt_init(struct drm_device *dev)
<synopsis>bool (*mode_fixup)(struct drm_encoder *encoder,
const struct drm_display_mode *mode,
struct drm_display_mode *adjusted_mode);</synopsis>
<note><para>
FIXME: The mode argument be const, but the i915 driver modifies
mode-&gt;clock in <function>intel_dp_mode_fixup</function>.
</para></note>
<para>
Let encoders adjust the requested mode or reject it completely. This
operation returns true if the mode is accepted (possibly after being
@ -2161,6 +2206,128 @@ void intel_crt_init(struct drm_device *dev)
<title>EDID Helper Functions Reference</title>
!Edrivers/gpu/drm/drm_edid.c
</sect2>
<sect2>
<title>Rectangle Utilities Reference</title>
!Pinclude/drm/drm_rect.h rect utils
!Iinclude/drm/drm_rect.h
!Edrivers/gpu/drm/drm_rect.c
</sect2>
</sect1>
<!-- Internals: kms properties -->
<sect1 id="drm-kms-properties">
<title>KMS Properties</title>
<para>
Drivers may need to expose additional parameters to applications than
those described in the previous sections. KMS supports attaching
properties to CRTCs, connectors and planes and offers a userspace API to
list, get and set the property values.
</para>
<para>
Properties are identified by a name that uniquely defines the property
purpose, and store an associated value. For all property types except blob
properties the value is a 64-bit unsigned integer.
</para>
<para>
KMS differentiates between properties and property instances. Drivers
first create properties and then create and associate individual instances
of those properties to objects. A property can be instantiated multiple
times and associated with different objects. Values are stored in property
instances, and all other property information are stored in the propery
and shared between all instances of the property.
</para>
<para>
Every property is created with a type that influences how the KMS core
handles the property. Supported property types are
<variablelist>
<varlistentry>
<term>DRM_MODE_PROP_RANGE</term>
<listitem><para>Range properties report their minimum and maximum
admissible values. The KMS core verifies that values set by
application fit in that range.</para></listitem>
</varlistentry>
<varlistentry>
<term>DRM_MODE_PROP_ENUM</term>
<listitem><para>Enumerated properties take a numerical value that
ranges from 0 to the number of enumerated values defined by the
property minus one, and associate a free-formed string name to each
value. Applications can retrieve the list of defined value-name pairs
and use the numerical value to get and set property instance values.
</para></listitem>
</varlistentry>
<varlistentry>
<term>DRM_MODE_PROP_BITMASK</term>
<listitem><para>Bitmask properties are enumeration properties that
additionally restrict all enumerated values to the 0..63 range.
Bitmask property instance values combine one or more of the
enumerated bits defined by the property.</para></listitem>
</varlistentry>
<varlistentry>
<term>DRM_MODE_PROP_BLOB</term>
<listitem><para>Blob properties store a binary blob without any format
restriction. The binary blobs are created as KMS standalone objects,
and blob property instance values store the ID of their associated
blob object.</para>
<para>Blob properties are only used for the connector EDID property
and cannot be created by drivers.</para></listitem>
</varlistentry>
</variablelist>
</para>
<para>
To create a property drivers call one of the following functions depending
on the property type. All property creation functions take property flags
and name, as well as type-specific arguments.
<itemizedlist>
<listitem>
<synopsis>struct drm_property *drm_property_create_range(struct drm_device *dev, int flags,
const char *name,
uint64_t min, uint64_t max);</synopsis>
<para>Create a range property with the given minimum and maximum
values.</para>
</listitem>
<listitem>
<synopsis>struct drm_property *drm_property_create_enum(struct drm_device *dev, int flags,
const char *name,
const struct drm_prop_enum_list *props,
int num_values);</synopsis>
<para>Create an enumerated property. The <parameter>props</parameter>
argument points to an array of <parameter>num_values</parameter>
value-name pairs.</para>
</listitem>
<listitem>
<synopsis>struct drm_property *drm_property_create_bitmask(struct drm_device *dev,
int flags, const char *name,
const struct drm_prop_enum_list *props,
int num_values);</synopsis>
<para>Create a bitmask property. The <parameter>props</parameter>
argument points to an array of <parameter>num_values</parameter>
value-name pairs.</para>
</listitem>
</itemizedlist>
</para>
<para>
Properties can additionally be created as immutable, in which case they
will be read-only for applications but can be modified by the driver. To
create an immutable property drivers must set the DRM_MODE_PROP_IMMUTABLE
flag at property creation time.
</para>
<para>
When no array of value-name pairs is readily available at property
creation time for enumerated or range properties, drivers can create
the property using the <function>drm_property_create</function> function
and manually add enumeration value-name pairs by calling the
<function>drm_property_add_enum</function> function. Care must be taken to
properly specify the property type through the <parameter>flags</parameter>
argument.
</para>
<para>
After creating properties drivers can attach property instances to CRTC,
connector and plane objects by calling the
<function>drm_object_attach_property</function>. The function takes a
pointer to the target object, a pointer to the previously created property
and an initial instance value.
</para>
</sect1>
<!-- Internals: vertical blanking -->

2
Documentation/DocBook/media/dvb/frontend.xml
View File

@ -233,7 +233,7 @@ typedef enum fe_status {
<entry align="char">The frontend FEC inner coding (Viterbi, LDPC or other inner code) is stable</entry>
</row><row>
<entry align="char">FE_HAS_SYNC</entry>
<entry align="char">Syncronization bytes was found</entry>
<entry align="char">Synchronization bytes was found</entry>
</row><row>
<entry align="char">FE_HAS_LOCK</entry>
<entry align="char">The DVB were locked and everything is working</entry>

14
Documentation/DocBook/media/v4l/compat.xml
View File

@ -2254,7 +2254,7 @@ video encoding.</para>
<orderedlist>
<listitem>
<para>The <constant>VIDIOC_G_CHIP_IDENT</constant> ioctl was renamed
to <constant>VIDIOC_G_CHIP_IDENT_OLD</constant> and &VIDIOC-DBG-G-CHIP-IDENT;
to <constant>VIDIOC_G_CHIP_IDENT_OLD</constant> and <constant>VIDIOC_DBG_G_CHIP_IDENT</constant>
was introduced in its place. The old struct <structname>v4l2_chip_ident</structname>
was renamed to <structname id="v4l2-chip-ident-old">v4l2_chip_ident_old</structname>.</para>
</listitem>
@ -2513,6 +2513,16 @@ that used it. It was originally scheduled for removal in 2.6.35.
</orderedlist>
</section>
<section>
<title>V4L2 in Linux 3.11</title>
<orderedlist>
<listitem>
<para>Remove obsolete <constant>VIDIOC_DBG_G_CHIP_IDENT</constant> ioctl.
</para>
</listitem>
</orderedlist>
</section>
<section id="other">
<title>Relation of V4L2 to other Linux multimedia APIs</title>
@ -2596,7 +2606,7 @@ and may change in the future.</para>
ioctls.</para>
</listitem>
<listitem>
<para>&VIDIOC-DBG-G-CHIP-IDENT; ioctl.</para>
<para>&VIDIOC-DBG-G-CHIP-INFO; ioctl.</para>
</listitem>
<listitem>
<para>&VIDIOC-ENUM-DV-TIMINGS;, &VIDIOC-QUERY-DV-TIMINGS; and

2
Documentation/DocBook/media/v4l/controls.xml
View File

@ -3147,7 +3147,7 @@ giving priority to the center of the metered area.</entry>
<entry>A multi-zone metering. The light intensity is measured
in several points of the frame and the the results are combined. The
algorithm of the zones selection and their significance in calculating the
final value is device dependant.</entry>
final value is device dependent.</entry>
</row>
</tbody>
</entrytbl>

2
Documentation/DocBook/media/v4l/pixfmt-nv12mt.xml
View File

@ -24,7 +24,7 @@ into 64x32 macroblocks. The CbCr plane has the same width, in bytes, as the Y
plane (and the image), but is half as tall in pixels. The chroma plane is also
grouped into 64x32 macroblocks.</para>
<para>Width of the buffer has to be aligned to the multiple of 128, and
height alignment is 32. Every four adjactent buffers - two horizontally and two
height alignment is 32. Every four adjacent buffers - two horizontally and two
vertically are grouped together and are located in memory in Z or flipped Z
order. </para>
<para>Layout of macroblocks in memory is presented in the following

11
Documentation/DocBook/media/v4l/v4l2.xml
View File

@ -140,6 +140,14 @@ structs, ioctls) must be noted in more detail in the history chapter
(compat.xml), along with the possible impact on existing drivers and
applications. -->
<revision>
<revnumber>3.11</revnumber>
<date>2013-05-26</date>
<authorinitials>hv</authorinitials>
<revremark>Remove obsolete VIDIOC_DBG_G_CHIP_IDENT ioctl.
</revremark>
</revision>
<revision>
<revnumber>3.10</revnumber>
<date>2013-03-25</date>
@ -493,7 +501,7 @@ and discussions on the V4L mailing list.</revremark>
</partinfo>
<title>Video for Linux Two API Specification</title>
<subtitle>Revision 3.10</subtitle>
<subtitle>Revision 3.11</subtitle>
<chapter id="common">
&sub-common;
@ -547,7 +555,6 @@ and discussions on the V4L mailing list.</revremark>
<!-- All ioctls go here. -->
&sub-create-bufs;
&sub-cropcap;
&sub-dbg-g-chip-ident;
&sub-dbg-g-chip-info;
&sub-dbg-g-register;
&sub-decoder-cmd;

271
Documentation/DocBook/media/v4l/vidioc-dbg-g-chip-ident.xml
View File

@ -1,271 +0,0 @@
<refentry id="vidioc-dbg-g-chip-ident">
<refmeta>
<refentrytitle>ioctl VIDIOC_DBG_G_CHIP_IDENT</refentrytitle>
&manvol;
</refmeta>
<refnamediv>
<refname>VIDIOC_DBG_G_CHIP_IDENT</refname>
<refpurpose>Identify the chips on a TV card</refpurpose>
</refnamediv>
<refsynopsisdiv>
<funcsynopsis>
<funcprototype>
<funcdef>int <function>ioctl</function></funcdef>
<paramdef>int <parameter>fd</parameter></paramdef>
<paramdef>int <parameter>request</parameter></paramdef>
<paramdef>struct v4l2_dbg_chip_ident
*<parameter>argp</parameter></paramdef>
</funcprototype>
</funcsynopsis>
</refsynopsisdiv>
<refsect1>
<title>Arguments</title>
<variablelist>
<varlistentry>
<term><parameter>fd</parameter></term>
<listitem>
<para>&fd;</para>
</listitem>
</varlistentry>
<varlistentry>
<term><parameter>request</parameter></term>
<listitem>
<para>VIDIOC_DBG_G_CHIP_IDENT</para>
</listitem>
</varlistentry>
<varlistentry>
<term><parameter>argp</parameter></term>
<listitem>
<para></para>
</listitem>
</varlistentry>
</variablelist>
</refsect1>
<refsect1>
<title>Description</title>
<note>
<title>Experimental</title>
<para>This is an <link
linkend="experimental">experimental</link> interface and may change in
the future.</para>
</note>
<para>For driver debugging purposes this ioctl allows test
applications to query the driver about the chips present on the TV
card. Regular applications must not use it. When you found a chip
specific bug, please contact the linux-media mailing list (&v4l-ml;)
so it can be fixed.</para>
<para>To query the driver applications must initialize the
<structfield>match.type</structfield> and
<structfield>match.addr</structfield> or <structfield>match.name</structfield>
fields of a &v4l2-dbg-chip-ident;
and call <constant>VIDIOC_DBG_G_CHIP_IDENT</constant> with a pointer to
this structure. On success the driver stores information about the
selected chip in the <structfield>ident</structfield> and
<structfield>revision</structfield> fields. On failure the structure
remains unchanged.</para>
<para>When <structfield>match.type</structfield> is
<constant>V4L2_CHIP_MATCH_HOST</constant>,
<structfield>match.addr</structfield> selects the nth non-&i2c; chip
on the TV card. You can enumerate all chips by starting at zero and
incrementing <structfield>match.addr</structfield> by one until
<constant>VIDIOC_DBG_G_CHIP_IDENT</constant> fails with an &EINVAL;.
The number zero always selects the host chip, &eg; the chip connected
to the PCI or USB bus.</para>
<para>When <structfield>match.type</structfield> is
<constant>V4L2_CHIP_MATCH_I2C_DRIVER</constant>,
<structfield>match.name</structfield> contains the I2C driver name.
For instance
<constant>"saa7127"</constant> will match any chip
supported by the saa7127 driver, regardless of its &i2c; bus address.
When multiple chips supported by the same driver are present, the
ioctl will return <constant>V4L2_IDENT_AMBIGUOUS</constant> in the
<structfield>ident</structfield> field.</para>
<para>When <structfield>match.type</structfield> is
<constant>V4L2_CHIP_MATCH_I2C_ADDR</constant>,
<structfield>match.addr</structfield> selects a chip by its 7 bit
&i2c; bus address.</para>
<para>When <structfield>match.type</structfield> is
<constant>V4L2_CHIP_MATCH_AC97</constant>,
<structfield>match.addr</structfield> selects the nth AC97 chip
on the TV card. You can enumerate all chips by starting at zero and
incrementing <structfield>match.addr</structfield> by one until
<constant>VIDIOC_DBG_G_CHIP_IDENT</constant> fails with an &EINVAL;.</para>
<para>On success, the <structfield>ident</structfield> field will
contain a chip ID from the Linux
<filename>media/v4l2-chip-ident.h</filename> header file, and the
<structfield>revision</structfield> field will contain a driver
specific value, or zero if no particular revision is associated with
this chip.</para>
<para>When the driver could not identify the selected chip,
<structfield>ident</structfield> will contain
<constant>V4L2_IDENT_UNKNOWN</constant>. When no chip matched
the ioctl will succeed but the
<structfield>ident</structfield> field will contain
<constant>V4L2_IDENT_NONE</constant>. If multiple chips matched,
<structfield>ident</structfield> will contain
<constant>V4L2_IDENT_AMBIGUOUS</constant>. In all these cases the
<structfield>revision</structfield> field remains unchanged.</para>
<para>This ioctl is optional, not all drivers may support it. It
was introduced in Linux 2.6.21, but the API was changed to the
one described here in 2.6.29.</para>
<para>We recommended the <application>v4l2-dbg</application>
utility over calling this ioctl directly. It is available from the
LinuxTV v4l-dvb repository; see <ulink
url="http://linuxtv.org/repo/">http://linuxtv.org/repo/</ulink> for
access instructions.</para>
<!-- Note for convenience vidioc-dbg-g-register.sgml
contains a duplicate of this table. -->
<table pgwide="1" frame="none" id="ident-v4l2-dbg-match">
<title>struct <structname>v4l2_dbg_match</structname></title>
<tgroup cols="4">
&cs-ustr;
<tbody valign="top">
<row>
<entry>__u32</entry>
<entry><structfield>type</structfield></entry>
<entry>See <xref linkend="ident-chip-match-types" /> for a list of
possible types.</entry>
</row>
<row>
<entry>union</entry>
<entry>(anonymous)</entry>
</row>
<row>
<entry></entry>
<entry>__u32</entry>
<entry><structfield>addr</structfield></entry>
<entry>Match a chip by this number, interpreted according
to the <structfield>type</structfield> field.</entry>
</row>
<row>
<entry></entry>
<entry>char</entry>
<entry><structfield>name[32]</structfield></entry>
<entry>Match a chip by this name, interpreted according
to the <structfield>type</structfield> field.</entry>
</row>
</tbody>
</tgroup>
</table>
<table pgwide="1" frame="none" id="v4l2-dbg-chip-ident">
<title>struct <structname>v4l2_dbg_chip_ident</structname></title>
<tgroup cols="3">
&cs-str;
<tbody valign="top">
<row>
<entry>struct v4l2_dbg_match</entry>
<entry><structfield>match</structfield></entry>
<entry>How to match the chip, see <xref linkend="ident-v4l2-dbg-match" />.</entry>
</row>
<row>
<entry>__u32</entry>
<entry><structfield>ident</structfield></entry>
<entry>A chip identifier as defined in the Linux
<filename>media/v4l2-chip-ident.h</filename> header file, or one of
the values from <xref linkend="chip-ids" />.</entry>
</row>
<row>
<entry>__u32</entry>
<entry><structfield>revision</structfield></entry>
<entry>A chip revision, chip and driver specific.</entry>
</row>
</tbody>
</tgroup>
</table>
<!-- Note for convenience vidioc-dbg-g-register.sgml
contains a duplicate of this table. -->
<table pgwide="1" frame="none" id="ident-chip-match-types">
<title>Chip Match Types</title>
<tgroup cols="3">
&cs-def;
<tbody valign="top">
<row>
<entry><constant>V4L2_CHIP_MATCH_BRIDGE</constant></entry>
<entry>0</entry>
<entry>Match the nth chip on the card, zero for the
bridge chip. Does not match sub-devices.</entry>
</row>
<row>
<entry><constant>V4L2_CHIP_MATCH_I2C_DRIVER</constant></entry>
<entry>1</entry>
<entry>Match an &i2c; chip by its driver name.</entry>
</row>
<row>
<entry><constant>V4L2_CHIP_MATCH_I2C_ADDR</constant></entry>
<entry>2</entry>
<entry>Match a chip by its 7 bit &i2c; bus address.</entry>
</row>
<row>
<entry><constant>V4L2_CHIP_MATCH_AC97</constant></entry>
<entry>3</entry>
<entry>Match the nth anciliary AC97 chip.</entry>
</row>
<row>
<entry><constant>V4L2_CHIP_MATCH_SUBDEV</constant></entry>
<entry>4</entry>
<entry>Match the nth sub-device. Can't be used with this ioctl.</entry>
</row>
</tbody>
</tgroup>
</table>
<!-- This is an anonymous enum in media/v4l2-chip-ident.h. -->
<table pgwide="1" frame="none" id="chip-ids">
<title>Chip Identifiers</title>
<tgroup cols="3">
&cs-def;
<tbody valign="top">
<row>
<entry><constant>V4L2_IDENT_NONE</constant></entry>
<entry>0</entry>
<entry>No chip matched.</entry>
</row>
<row>
<entry><constant>V4L2_IDENT_AMBIGUOUS</constant></entry>
<entry>1</entry>
<entry>Multiple chips matched.</entry>
</row>
<row>
<entry><constant>V4L2_IDENT_UNKNOWN</constant></entry>
<entry>2</entry>
<entry>A chip is present at this address, but the driver
could not identify it.</entry>
</row>
</tbody>
</tgroup>
</table>
</refsect1>
<refsect1>
&return-value;
<variablelist>
<varlistentry>
<term><errorcode>EINVAL</errorcode></term>
<listitem>
<para>The <structfield>match_type</structfield> is invalid.</para>
</listitem>
</varlistentry>
</variablelist>
</refsect1>
</refentry>

20
Documentation/DocBook/media/v4l/vidioc-dbg-g-chip-info.xml
View File

@ -73,8 +73,7 @@ fields of a &v4l2-dbg-chip-info;
and call <constant>VIDIOC_DBG_G_CHIP_INFO</constant> with a pointer to
this structure. On success the driver stores information about the
selected chip in the <structfield>name</structfield> and
<structfield>flags</structfield> fields. On failure the structure
remains unchanged.</para>
<structfield>flags</structfield> fields.</para>
<para>When <structfield>match.type</structfield> is
<constant>V4L2_CHIP_MATCH_BRIDGE</constant>,
@ -132,7 +131,7 @@ to the <structfield>type</structfield> field.</entry>
<entry>char</entry>
<entry><structfield>name[32]</structfield></entry>
<entry>Match a chip by this name, interpreted according
to the <structfield>type</structfield> field.</entry>
to the <structfield>type</structfield> field. Currently unused.</entry>
</row>
</tbody>
</tgroup>
@ -182,21 +181,6 @@ is set, then the driver supports reading registers from the device. If
<entry>Match the nth chip on the card, zero for the
bridge chip. Does not match sub-devices.</entry>
</row>
<row>
<entry><constant>V4L2_CHIP_MATCH_I2C_DRIVER</constant></entry>
<entry>1</entry>
<entry>Match an &i2c; chip by its driver name. Can't be used with this ioctl.</entry>
</row>
<row>
<entry><constant>V4L2_CHIP_MATCH_I2C_ADDR</constant></entry>
<entry>2</entry>
<entry>Match a chip by its 7 bit &i2c; bus address. Can't be used with this ioctl.</entry>
</row>
<row>
<entry><constant>V4L2_CHIP_MATCH_AC97</constant></entry>
<entry>3</entry>
<entry>Match the nth anciliary AC97 chip. Can't be used with this ioctl.</entry>
</row>
<row>
<entry><constant>V4L2_CHIP_MATCH_SUBDEV</constant></entry>
<entry>4</entry>

64
Documentation/DocBook/media/v4l/vidioc-dbg-g-register.xml
View File

@ -76,7 +76,7 @@ compiled with the <constant>CONFIG_VIDEO_ADV_DEBUG</constant> option
to enable these ioctls.</para>
<para>To write a register applications must initialize all fields
of a &v4l2-dbg-register; and call
of a &v4l2-dbg-register; except for <structfield>size</structfield> and call
<constant>VIDIOC_DBG_S_REGISTER</constant> with a pointer to this
structure. The <structfield>match.type</structfield> and
<structfield>match.addr</structfield> or <structfield>match.name</structfield>
@ -91,8 +91,8 @@ written into the register.</para>
<structfield>reg</structfield> fields, and call
<constant>VIDIOC_DBG_G_REGISTER</constant> with a pointer to this
structure. On success the driver stores the register value in the
<structfield>val</structfield> field. On failure the structure remains
unchanged.</para>
<structfield>val</structfield> field and the size (in bytes) of the
value in <structfield>size</structfield>.</para>
<para>When <structfield>match.type</structfield> is
<constant>V4L2_CHIP_MATCH_BRIDGE</constant>,
@ -101,40 +101,10 @@ on the TV card. The number zero always selects the host chip, &eg; the
chip connected to the PCI or USB bus. You can find out which chips are
present with the &VIDIOC-DBG-G-CHIP-INFO; ioctl.</para>
<para>When <structfield>match.type</structfield> is
<constant>V4L2_CHIP_MATCH_I2C_DRIVER</constant>,
<structfield>match.name</structfield> contains the I2C driver name.
For instance
<constant>"saa7127"</constant> will match any chip
supported by the saa7127 driver, regardless of its &i2c; bus address.
When multiple chips supported by the same driver are present, the
effect of these ioctls is undefined. Again with the
&VIDIOC-DBG-G-CHIP-INFO; ioctl you can find out which &i2c; chips are
present.</para>
<para>When <structfield>match.type</structfield> is
<constant>V4L2_CHIP_MATCH_I2C_ADDR</constant>,
<structfield>match.addr</structfield> selects a chip by its 7 bit &i2c;
bus address.</para>
<para>When <structfield>match.type</structfield> is
<constant>V4L2_CHIP_MATCH_AC97</constant>,
<structfield>match.addr</structfield> selects the nth AC97 chip
on the TV card.</para>
<para>When <structfield>match.type</structfield> is
<constant>V4L2_CHIP_MATCH_SUBDEV</constant>,
<structfield>match.addr</structfield> selects the nth sub-device.</para>
<note>
<title>Success not guaranteed</title>
<para>Due to a flaw in the Linux &i2c; bus driver these ioctls may
return successfully without actually reading or writing a register. To
catch the most likely failure we recommend a &VIDIOC-DBG-G-CHIP-INFO;
call confirming the presence of the selected &i2c; chip.</para>
</note>
<para>These ioctls are optional, not all drivers may support them.
However when a driver supports these ioctls it must also support
&VIDIOC-DBG-G-CHIP-INFO;. Conversely it may support
@ -150,7 +120,7 @@ LinuxTV v4l-dvb repository; see <ulink
url="http://linuxtv.org/repo/">http://linuxtv.org/repo/</ulink> for
access instructions.</para>
<!-- Note for convenience vidioc-dbg-g-chip-ident.sgml
<!-- Note for convenience vidioc-dbg-g-chip-info.sgml
contains a duplicate of this table. -->
<table pgwide="1" frame="none" id="v4l2-dbg-match">
<title>struct <structname>v4l2_dbg_match</structname></title>
@ -160,7 +130,7 @@ access instructions.</para>
<row>
<entry>__u32</entry>
<entry><structfield>type</structfield></entry>
<entry>See <xref linkend="ident-chip-match-types" /> for a list of
<entry>See <xref linkend="chip-match-types" /> for a list of
possible types.</entry>
</row>
<row>
@ -179,7 +149,7 @@ to the <structfield>type</structfield> field.</entry>
<entry>char</entry>
<entry><structfield>name[32]</structfield></entry>
<entry>Match a chip by this name, interpreted according
to the <structfield>type</structfield> field.</entry>
to the <structfield>type</structfield> field. Currently unused.</entry>
</row>
</tbody>
</tgroup>
@ -198,6 +168,11 @@ to the <structfield>type</structfield> field.</entry>
<entry><structfield>match</structfield></entry>
<entry>How to match the chip, see <xref linkend="v4l2-dbg-match" />.</entry>
</row>
<row>
<entry>__u32</entry>
<entry><structfield>size</structfield></entry>
<entry>The register size in bytes.</entry>
</row>
<row>
<entry>__u64</entry>
<entry><structfield>reg</structfield></entry>
@ -213,7 +188,7 @@ register.</entry>
</tgroup>
</table>
<!-- Note for convenience vidioc-dbg-g-chip-ident.sgml
<!-- Note for convenience vidioc-dbg-g-chip-info.sgml
contains a duplicate of this table. -->
<table pgwide="1" frame="none" id="chip-match-types">
<title>Chip Match Types</title>
@ -226,21 +201,6 @@ register.</entry>
<entry>Match the nth chip on the card, zero for the
bridge chip. Does not match sub-devices.</entry>
</row>
<row>
<entry><constant>V4L2_CHIP_MATCH_I2C_DRIVER</constant></entry>
<entry>1</entry>
<entry>Match an &i2c; chip by its driver name.</entry>
</row>
<row>
<entry><constant>V4L2_CHIP_MATCH_I2C_ADDR</constant></entry>
<entry>2</entry>
<entry>Match a chip by its 7 bit &i2c; bus address.</entry>
</row>
<row>
<entry><constant>V4L2_CHIP_MATCH_AC97</constant></entry>
<entry>3</entry>
<entry>Match the nth anciliary AC97 chip.</entry>
</row>
<row>
<entry><constant>V4L2_CHIP_MATCH_SUBDEV</constant></entry>
<entry>4</entry>

3
Documentation/DocBook/media/v4l/vidioc-querystd.xml
View File

@ -54,7 +54,8 @@ standard automatically. To do so, applications call <constant>
VIDIOC_QUERYSTD</constant> with a pointer to a &v4l2-std-id; type. The
driver stores here a set of candidates, this can be a single flag or a
set of supported standards if for example the hardware can only
distinguish between 50 and 60 Hz systems. When detection is not
distinguish between 50 and 60 Hz systems. If no signal was detected,
then the driver will return V4L2_STD_UNKNOWN. When detection is not
possible or fails, the set must contain all standards supported by the
current video input or output.</para>

2
Documentation/DocBook/writing_usb_driver.tmpl
View File

@ -83,7 +83,7 @@
</para>
<para>
Because each different protocol causes a new driver to be created, I have
written a generic USB driver skeleton, modeled after the pci-skeleton.c
written a generic USB driver skeleton, modelled after the pci-skeleton.c
file in the kernel source tree upon which many PCI network drivers have
been based. This USB skeleton can be found at drivers/usb/usb-skeleton.c
in the kernel source tree. In this article I will walk through the basics

2
Documentation/arm/IXP4xx
View File

@ -36,7 +36,7 @@ Linux currently supports the following features on the IXP4xx chips:
- Timers (watchdog, OS)
The following components of the chips are not supported by Linux and
require the use of Intel's proprietary CSR softare:
require the use of Intel's proprietary CSR software:
- USB device interface
- Network interfaces (HSS, Utopia, NPEs, etc)

47
Documentation/bcache.txt
View File

@ -46,29 +46,33 @@ you format your backing devices and cache device at the same time, you won't
have to manually attach:
make-bcache -B /dev/sda /dev/sdb -C /dev/sdc
To make bcache devices known to the kernel, echo them to /sys/fs/bcache/register:
bcache-tools now ships udev rules, and bcache devices are known to the kernel
immediately. Without udev, you can manually register devices like this:
echo /dev/sdb > /sys/fs/bcache/register
echo /dev/sdc > /sys/fs/bcache/register
To register your bcache devices automatically, you could add something like
this to an init script:
Registering the backing device makes the bcache device show up in /dev; you can
now format it and use it as normal. But the first time using a new bcache
device, it'll be running in passthrough mode until you attach it to a cache.
See the section on attaching.
echo /dev/sd* > /sys/fs/bcache/register_quiet
The devices show up as:
It'll look for bcache superblocks and ignore everything that doesn't have one.
/dev/bcache<N>
Registering the backing device makes the bcache show up in /dev; you can now
format it and use it as normal. But the first time using a new bcache device,
it'll be running in passthrough mode until you attach it to a cache. See the
section on attaching.
As well as (with udev):
The devices show up at /dev/bcacheN, and can be controlled via sysfs from
/sys/block/bcacheN/bcache:
/dev/bcache/by-uuid/<uuid>
/dev/bcache/by-label/<label>
To get started:
mkfs.ext4 /dev/bcache0
mount /dev/bcache0 /mnt
You can control bcache devices through sysfs at /sys/block/bcache<N>/bcache .
Cache devices are managed as sets; multiple caches per set isn't supported yet
but will allow for mirroring of metadata and dirty data in the future. Your new
cache set shows up as /sys/fs/bcache/<UUID>
@ -80,11 +84,11 @@ must be attached to your cache set to enable caching. Attaching a backing
device to a cache set is done thusly, with the UUID of the cache set in
/sys/fs/bcache:
echo <UUID> > /sys/block/bcache0/bcache/attach
echo <CSET-UUID> > /sys/block/bcache0/bcache/attach
This only has to be done once. The next time you reboot, just reregister all
your bcache devices. If a backing device has data in a cache somewhere, the
/dev/bcache# device won't be created until the cache shows up - particularly
/dev/bcache<N> device won't be created until the cache shows up - particularly
important if you have writeback caching turned on.
If you're booting up and your cache device is gone and never coming back, you
@ -181,7 +185,7 @@ want for getting the best possible numbers when benchmarking.
In practice this isn't an issue because as soon as a write comes along it'll
cause the btree node to be split, and you need almost no write traffic for
this to not show up enough to be noticable (especially since bcache's btree
this to not show up enough to be noticeable (especially since bcache's btree
nodes are huge and index large regions of the device). But when you're
benchmarking, if you're trying to warm the cache by reading a bunch of data
and there's no other traffic - that can be a problem.
@ -191,6 +195,9 @@ want for getting the best possible numbers when benchmarking.
SYSFS - BACKING DEVICE:
Available at /sys/block/<bdev>/bcache, /sys/block/bcache*/bcache and
(if attached) /sys/fs/bcache/<cset-uuid>/bdev*
attach
Echo the UUID of a cache set to this file to enable caching.
@ -222,7 +229,7 @@ running
it's in passthrough mode or caching).
sequential_cutoff
A sequential IO will bypass the cache once it passes this threshhold; the
A sequential IO will bypass the cache once it passes this threshold; the
most recent 128 IOs are tracked so sequential IO can be detected even when
it isn't all done at once.
@ -296,10 +303,12 @@ cache_miss_collisions
since the synchronization for cache misses was rewritten)
cache_readaheads
Count of times readahead occured.
Count of times readahead occurred.
SYSFS - CACHE SET:
Available at /sys/fs/bcache/<cset-uuid>
average_key_size
Average data per key in the btree.
@ -362,7 +371,7 @@ unregister
SYSFS - CACHE SET INTERNAL:
This directory also exposes timings for a number of internal operations, with
separate files for average duration, average frequency, last occurence and max
separate files for average duration, average frequency, last occurrence and max
duration: garbage collection, btree read, btree node sorts and btree splits.
active_journal_entries
@ -390,6 +399,8 @@ trigger_gc
SYSFS - CACHE DEVICE:
Available at /sys/block/<cdev>/bcache
block_size
Minimum granularity of writes - should match hardware sector size.
@ -417,7 +428,7 @@ freelist_percent
space.
io_errors
Number of errors that have occured, decayed by io_error_halflife.
Number of errors that have occurred, decayed by io_error_halflife.
metadata_written
Sum of all non data writes (btree writes and all other metadata).

2
Documentation/block/queue-sysfs.txt
View File

@ -93,7 +93,7 @@ To avoid priority inversion through request starvation, a request
queue maintains a separate request pool per each cgroup when
CONFIG_BLK_CGROUP is enabled, and this parameter applies to each such
per-block-cgroup request pool. IOW, if there are N block cgroups,
each request queue may have upto N request pools, each independently
each request queue may have up to N request pools, each independently
regulated by nr_requests.
optimal_io_size (RO)

29
Documentation/cgroups/blkio-controller.txt
View File

@ -94,11 +94,13 @@ Throttling/Upper Limit policy
Hierarchical Cgroups
====================
- Currently only CFQ supports hierarchical groups. For throttling,
cgroup interface does allow creation of hierarchical cgroups and
internally it treats them as flat hierarchy.
If somebody created a hierarchy like as follows.
Both CFQ and throttling implement hierarchy support; however,
throttling's hierarchy support is enabled iff "sane_behavior" is
enabled from cgroup side, which currently is a development option and
not publicly available.
If somebody created a hierarchy like as follows.
root
/ \
@ -106,21 +108,20 @@ Hierarchical Cgroups
|
test3
CFQ will handle the hierarchy correctly but and throttling will
practically treat all groups at same level. For details on CFQ
hierarchy support, refer to Documentation/block/cfq-iosched.txt.
Throttling will treat the hierarchy as if it looks like the
following.
CFQ by default and throttling with "sane_behavior" will handle the
hierarchy correctly. For details on CFQ hierarchy support, refer to
Documentation/block/cfq-iosched.txt. For throttling, all limits apply
to the whole subtree while all statistics are local to the IOs
directly generated by tasks in that cgroup.
Throttling without "sane_behavior" enabled from cgroup side will
practically treat all groups at same level as if it looks like the
following.
pivot
/ / \ \
root test1 test2 test3
Nesting cgroups, while allowed, isn't officially supported and blkio
genereates warning when cgroups nest. Once throttling implements
hierarchy support, hierarchy will be supported and the warning will
be removed.
Various user visible config options
===================================
CONFIG_BLK_CGROUP

6
Documentation/cgroups/memory.txt
View File

@ -304,7 +304,7 @@ kernel memory, we prevent new processes from being created when the kernel
memory usage is too high.
* slab pages: pages allocated by the SLAB or SLUB allocator are tracked. A copy
of each kmem_cache is created everytime the cache is touched by the first time
of each kmem_cache is created every time the cache is touched by the first time
from inside the memcg. The creation is done lazily, so some objects can still be
skipped while the cache is being created. All objects in a slab page should
belong to the same memcg. This only fails to hold when a task is migrated to a
@ -490,10 +490,10 @@ 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
inactive_anon - # of bytes of anonymous memory and swap cache memory on
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
inactive LRU list.
LRU list.
inactive_file - # of bytes of file-backed memory on inactive LRU list.
active_file - # of bytes of file-backed memory on active LRU list.
unevictable - # of bytes of memory that cannot be reclaimed (mlocked etc).

2
Documentation/clk.txt
View File

@ -32,7 +32,7 @@ hardware-specific bits for the hypothetical "foo" hardware.
Tying the two halves of this interface together is struct clk_hw, which
is defined in struct clk_foo and pointed to within struct clk. This
allows easy for navigation between the two discrete halves of the common
allows for easy navigation between the two discrete halves of the common
clock interface.
Part 2 - common data structures and api

63
Documentation/coccinelle.txt
View File

@ -6,15 +6,17 @@ Copyright 2010 Gilles Muller <Gilles.Muller@lip6.fr>
Getting Coccinelle
~~~~~~~~~~~~~~~~~~~~
The semantic patches included in the kernel use the 'virtual rule'
feature which was introduced in Coccinelle version 0.1.11.
The semantic patches included in the kernel use features and options
which are provided by Coccinelle version 1.0.0-rc11 and above.
Using earlier versions will fail as the option names used by
the Coccinelle files and coccicheck have been updated.
Coccinelle (>=0.2.0) is available through the package manager
Coccinelle is available through the package manager
of many distributions, e.g. :
- Debian (>=squeeze)
- Fedora (>=13)
- Ubuntu (>=10.04 Lucid Lynx)
- Debian
- Fedora
- Ubuntu
- OpenSUSE
- Arch Linux
- NetBSD
@ -36,11 +38,6 @@ as a regular user, and install it with
sudo make install
The semantic patches in the kernel will work best with Coccinelle version
0.2.4 or later. Using earlier versions may incur some parse errors in the
semantic patch code, but any results that are obtained should still be
correct.
Using Coccinelle on the Linux kernel
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
@ -48,7 +45,7 @@ A Coccinelle-specific target is defined in the top level
Makefile. This target is named 'coccicheck' and calls the 'coccicheck'
front-end in the 'scripts' directory.
Four modes are defined: patch, report, context, and org. The mode to
Four basic modes are defined: patch, report, context, and org. The mode to
use is specified by setting the MODE variable with 'MODE=<mode>'.
'patch' proposes a fix, when possible.
@ -62,18 +59,24 @@ diff-like style.Lines of interest are indicated with '-'.
'org' generates a report in the Org mode format of Emacs.
Note that not all semantic patches implement all modes. For easy use
of Coccinelle, the default mode is "chain" which tries the previous
modes in the order above until one succeeds.
of Coccinelle, the default mode is "report".
To make a report for every semantic patch, run the following command:
Two other modes provide some common combinations of these modes.
make coccicheck MODE=report
'chain' tries the previous modes in the order above until one succeeds.
NB: The 'report' mode is the default one.
'rep+ctxt' runs successively the report mode and the context mode.
It should be used with the C option (described later)
which checks the code on a file basis.
To produce patches, run:
Examples:
To make a report for every semantic patch, run the following command:
make coccicheck MODE=patch
make coccicheck MODE=report
To produce patches, run:
make coccicheck MODE=patch
The coccicheck target applies every semantic patch available in the
@ -91,6 +94,11 @@ To enable verbose messages set the V= variable, for example:
make coccicheck MODE=report V=1
By default, coccicheck tries to run as parallel as possible. To change
the parallelism, set the J= variable. For example, to run across 4 CPUs:
make coccicheck MODE=report J=4
Using Coccinelle with a single semantic patch
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
@ -124,26 +132,33 @@ To check only newly edited code, use the value 2 for the C flag, i.e.
make C=2 CHECK="scripts/coccicheck"
In these modes, which works on a file basis, there is no information
about semantic patches displayed, and no commit message proposed.
This runs every semantic patch in scripts/coccinelle by default. The
COCCI variable may additionally be used to only apply a single
semantic patch as shown in the previous section.
The "chain" mode is the default. You can select another one with the
The "report" mode is the default. You can select another one with the
MODE variable explained above.
In this mode, there is no information about semantic patches
displayed, and no commit message proposed.
Additional flags
~~~~~~~~~~~~~~~~~~
Additional flags can be passed to spatch through the SPFLAGS
variable.
make SPFLAGS=--use_glimpse coccicheck
make SPFLAGS=--use-glimpse coccicheck
make SPFLAGS=--use-idutils coccicheck
See spatch --help to learn more about spatch options.
Note that the '--use-glimpse' and '--use-idutils' options
require external tools for indexing the code. None of them is
thus active by default. However, by indexing the code with
one of these tools, and according to the cocci file used,
spatch could proceed the entire code base more quickly.
Proposing new semantic patches
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

6
Documentation/cpu-hotplug.txt
View File

@ -267,8 +267,8 @@ Q: If i have some kernel code that needs to be aware of CPU arrival and
A: This is what you would need in your kernel code to receive notifications.
#include <linux/cpu.h>
static int __cpuinit foobar_cpu_callback(struct notifier_block *nfb,
unsigned long action, void *hcpu)
static int foobar_cpu_callback(struct notifier_block *nfb,
unsigned long action, void *hcpu)
{
unsigned int cpu = (unsigned long)hcpu;
@ -285,7 +285,7 @@ A: This is what you would need in your kernel code to receive notifications.
return NOTIFY_OK;
}
static struct notifier_block __cpuinitdata foobar_cpu_notifer =
static struct notifier_block foobar_cpu_notifer =
{
.notifier_call = foobar_cpu_callback,
};

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

@ -87,7 +87,7 @@ Migration throttling
Migrating data between the origin and cache device uses bandwidth.
The user can set a throttle to prevent more than a certain amount of
migration occuring at any one time. Currently we're not taking any
migration occurring at any one time. Currently we're not taking any
account of normal io traffic going to the devices. More work needs
doing here to avoid migrating during those peak io moments.

126
Documentation/device-mapper/switch.txt 100644
View File

@ -0,0 +1,126 @@
dm-switch
=========
The device-mapper switch target creates a device that supports an
arbitrary mapping of fixed-size regions of I/O across a fixed set of
paths. The path used for any specific region can be switched
dynamically by sending the target a message.
It maps I/O to underlying block devices efficiently when there is a large
number of fixed-sized address regions but there is no simple pattern
that would allow for a compact representation of the mapping such as
dm-stripe.
Background
----------
Dell EqualLogic and some other iSCSI storage arrays use a distributed
frameless architecture. In this architecture, the storage group
consists of a number of distinct storage arrays ("members") each having
independent controllers, disk storage and network adapters. When a LUN
is created it is spread across multiple members. The details of the
spreading are hidden from initiators connected to this storage system.
The storage group exposes a single target discovery portal, no matter
how many members are being used. When iSCSI sessions are created, each
session is connected to an eth port on a single member. Data to a LUN
can be sent on any iSCSI session, and if the blocks being accessed are
stored on another member the I/O will be forwarded as required. This
forwarding is invisible to the initiator. The storage layout is also
dynamic, and the blocks stored on disk may be moved from member to
member as needed to balance the load.
This architecture simplifies the management and configuration of both
the storage group and initiators. In a multipathing configuration, it
is possible to set up multiple iSCSI sessions to use multiple network
interfaces on both the host and target to take advantage of the
increased network bandwidth. An initiator could use a simple round
robin algorithm to send I/O across all paths and let the storage array
members forward it as necessary, but there is a performance advantage to
sending data directly to the correct member.
A device-mapper table already lets you map different regions of a
device onto different targets. However in this architecture the LUN is
spread with an address region size on the order of 10s of MBs, which
means the resulting table could have more than a million entries and
consume far too much memory.
Using this device-mapper switch target we can now build a two-layer
device hierarchy:
Upper Tier – Determine which array member the I/O should be sent to.
Lower Tier – Load balance amongst paths to a particular member.
The lower tier consists of a single dm multipath device for each member.
Each of these multipath devices contains the set of paths directly to
the array member in one priority group, and leverages existing path
selectors to load balance amongst these paths. We also build a
non-preferred priority group containing paths to other array members for
failover reasons.
The upper tier consists of a single dm-switch device. This device uses
a bitmap to look up the location of the I/O and choose the appropriate
lower tier device to route the I/O. By using a bitmap we are able to
use 4 bits for each address range in a 16 member group (which is very
large for us). This is a much denser representation than the dm table
b-tree can achieve.
Construction Parameters
=======================
<num_paths> <region_size> <num_optional_args> [<optional_args>...]
[<dev_path> <offset>]+
<num_paths>
The number of paths across which to distribute the I/O.
<region_size>
The number of 512-byte sectors in a region. Each region can be redirected
to any of the available paths.
<num_optional_args>
The number of optional arguments. Currently, no optional arguments
are supported and so this must be zero.
<dev_path>
The block device that represents a specific path to the device.
<offset>
The offset of the start of data on the specific <dev_path> (in units
of 512-byte sectors). This number is added to the sector number when
forwarding the request to the specific path. Typically it is zero.
Messages
========
set_region_mappings <index>:<path_nr> [<index>]:<path_nr> [<index>]:<path_nr>...
Modify the region table by specifying which regions are redirected to
which paths.
<index>
The region number (region size was specified in constructor parameters).
If index is omitted, the next region (previous index + 1) is used.
Expressed in hexadecimal (WITHOUT any prefix like 0x).
<path_nr>
The path number in the range 0 ... (<num_paths> - 1).
Expressed in hexadecimal (WITHOUT any prefix like 0x).
Status
======
No status line is reported.
Example
=======
Assume that you have volumes vg1/switch0 vg1/switch1 vg1/switch2 with
the same size.
Create a switch device with 64kB region size:
dmsetup create switch --table "0 `blockdev --getsize /dev/vg1/switch0`
switch 3 128 0 /dev/vg1/switch0 0 /dev/vg1/switch1 0 /dev/vg1/switch2 0"
Set mappings for the first 7 entries to point to devices switch0, switch1,
switch2, switch0, switch1, switch2, switch1:
dmsetup message switch 0 set_region_mappings 0:0 :1 :2 :0 :1 :2 :1

24
Documentation/devicetree/bindings/arm/global_timer.txt 100644
View File

@ -0,0 +1,24 @@
* ARM Global Timer
Cortex-A9 are often associated with a per-core Global timer.
** Timer node required properties:
- compatible : Should be "arm,cortex-a9-global-timer"
Driver supports versions r2p0 and above.
- interrupts : One interrupt to each core
- reg : Specify the base address and the size of the GT timer
register window.
- clocks : Should be phandle to a clock.
Example:
timer@2c000600 {
compatible = "arm,cortex-a9-global-timer";
reg = <0x2c000600 0x20>;
interrupts = <1 13 0xf01>;
clocks = <&arm_periph_clk>;
};

6
Documentation/devicetree/bindings/arm/samsung/interrupt-combiner.txt
View File

@ -5,7 +5,7 @@ can combine interrupt sources as a group and provide a single interrupt request
for the group. The interrupt request from each group are connected to a parent
interrupt controller, such as GIC in case of Exynos4210.
The interrupt combiner controller consists of multiple combiners. Upto eight
The interrupt combiner controller consists of multiple combiners. Up to eight
interrupt sources can be connected to a combiner. The combiner outputs one
combined interrupt for its eight interrupt sources. The combined interrupt
is usually connected to a parent interrupt controller.
@ -14,8 +14,8 @@ A single node in the device tree is used to describe the interrupt combiner
controller module (which includes multiple combiners). A combiner in the
interrupt controller module shares config/control registers with other
combiners. For example, a 32-bit interrupt enable/disable config register
can accommodate upto 4 interrupt combiners (with each combiner supporting
upto 8 interrupt sources).
can accommodate up to 4 interrupt combiners (with each combiner supporting
up to 8 interrupt sources).
Required properties:
- compatible: should be "samsung,exynos4210-combiner".

2
Documentation/devicetree/bindings/arm/spear/shirq.txt
View File

@ -14,7 +14,7 @@ A single node in the device tree is used to describe the shared
interrupt multiplexor (one node for all groups). A group in the
interrupt controller shares config/control registers with other groups.
For example, a 32-bit interrupt enable/disable config register can
accommodate upto 4 interrupt groups.
accommodate up to 4 interrupt groups.
Required properties:
- compatible: should be, either of

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

@ -98,6 +98,7 @@ clocks and IDs.
fpm 83
mpll_osc_sel 84
mpll_sel 85
spll_gate 86
Examples:

2
Documentation/devicetree/bindings/clock/silabs,si5351.txt
View File

@ -4,7 +4,7 @@ Reference
[1] Si5351A/B/C Data Sheet
http://www.silabs.com/Support%20Documents/TechnicalDocs/Si5351.pdf
The Si5351a/b/c are programmable i2c clock generators with upto 8 output
The Si5351a/b/c are programmable i2c clock generators with up to 8 output
clocks. Si5351a also has a reduced pin-count package (MSOP10) where only
3 output clocks are accessible. The internal structure of the clock
generators can be found in [1].

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

@ -24,8 +24,11 @@ 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. The peripheral identifier for the hardware handshaking interface. The
identifier can be different for tx and rx.
3. Parameters for the at91 DMA configuration register which are device
dependant:
- 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.
Example:

48
Documentation/devicetree/bindings/dma/fsl-imx-dma.txt 100644
View File

@ -0,0 +1,48 @@
* Freescale Direct Memory Access (DMA) Controller for i.MX
This document will only describe differences to the generic DMA Controller and
DMA request bindings as described in dma/dma.txt .
* DMA controller
Required properties:
- compatible : Should be "fsl,<chip>-dma". chip can be imx1, imx21 or imx27
- reg : Should contain DMA registers location and length
- interrupts : First item should be DMA interrupt, second one is optional and
should contain DMA Error interrupt
- #dma-cells : Has to be 1. imx-dma does not support anything else.
Optional properties:
- #dma-channels : Number of DMA channels supported. Should be 16.
- #dma-requests : Number of DMA requests supported.
Example:
dma: dma@10001000 {
compatible = "fsl,imx27-dma";
reg = <0x10001000 0x1000>;
interrupts = <32 33>;
#dma-cells = <1>;
#dma-channels = <16>;
};
* DMA client
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.
- dma-names: List of string identifiers for the DMA requests. For the correct
names, have a look at the specific client driver.
Example:
sdhci1: sdhci@10013000 {
...
dmas = <&dma 7>;
dma-names = "rx-tx";
...
};

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

@ -4,14 +4,70 @@ Required properties:
- compatible : Should be "fsl,<chip>-sdma"
- reg : Should contain SDMA registers location and length
- interrupts : Should contain SDMA interrupt
- #dma-cells : Must be <3>.
The first cell specifies the DMA request/event ID. See details below
about the second and third cell.
- fsl,sdma-ram-script-name : Should contain the full path of SDMA RAM
scripts firmware
The second cell of dma phandle specifies the peripheral type of DMA transfer.
The full ID of peripheral types can be found below.
ID transfer type
---------------------
0 MCU domain SSI
1 Shared SSI
2 MMC
3 SDHC
4 MCU domain UART
5 Shared UART
6 FIRI
7 MCU domain CSPI
8 Shared CSPI
9 SIM
10 ATA
11 CCM
12 External peripheral
13 Memory Stick Host Controller
14 Shared Memory Stick Host Controller
15 DSP
16 Memory
17 FIFO type Memory
18 SPDIF
19 IPU Memory
20 ASRC
21 ESAI
The third cell specifies the transfer priority as below.
ID transfer priority
-------------------------
0 High
1 Medium
2 Low
Examples:
sdma@83fb0000 {
compatible = "fsl,imx51-sdma", "fsl,imx35-sdma";
reg = <0x83fb0000 0x4000>;
interrupts = <6>;
#dma-cells = <3>;
fsl,sdma-ram-script-name = "sdma-imx51.bin";
};
DMA clients connected to the i.MX SDMA controller must use the format
described in the dma.txt file.
Examples:
ssi2: ssi@70014000 {
compatible = "fsl,imx51-ssi", "fsl,imx21-ssi";
reg = <0x70014000 0x4000>;
interrupts = <30>;
clocks = <&clks 49>;
dmas = <&sdma 24 1 0>,
<&sdma 25 1 0>;
dma-names = "rx", "tx";
fsl,fifo-depth = <15>;
};

75
Documentation/devicetree/bindings/dma/shdma.txt 100644
View File

@ -0,0 +1,75 @@
* SHDMA Device Tree bindings
Sh-/r-mobile and r-car systems often have multiple identical DMA controller
instances, capable of serving any of a common set of DMA slave devices, using
the same configuration. To describe this topology we require all compatible
SHDMA DT nodes to be placed under a DMA multiplexer node. All such compatible
DMAC instances have the same number of channels and use the same DMA
descriptors. Therefore respective DMA DT bindings can also all be placed in the
multiplexer node. Even if there is only one such DMAC instance on a system, it
still has to be placed under such a multiplexer node.
* DMA multiplexer
Required properties:
- compatible: should be "renesas,shdma-mux"
- #dma-cells: should be <1>, see "dmas" property below
Optional properties (currently unused):
- dma-channels: number of DMA channels
- dma-requests: number of DMA request signals
* DMA controller
Required properties:
- compatible: should be "renesas,shdma"
Example:
dmac: dma-mux0 {
compatible = "renesas,shdma-mux";
#dma-cells = <1>;
dma-channels = <6>;
dma-requests = <256>;
reg = <0 0>; /* Needed for AUXDATA */
#address-cells = <1>;
#size-cells = <1>;
ranges;
dma0: shdma@fe008020 {
compatible = "renesas,shdma";
reg = <0xfe008020 0x270>,
<0xfe009000 0xc>;
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>;
interrupt-names = "error",
"ch0", "ch1", "ch2", "ch3",
"ch4", "ch5";
};
dma1: shdma@fe018020 {
...
};
dma2: shdma@fe028020 {
...
};
};
* DMA client
Required properties:
- dmas: a list of <[DMA multiplexer phandle] [MID/RID value]> pairs,
where MID/RID values are fixed handles, specified in the SoC
manual
- dma-names: a list of DMA channel names, one per "dmas" entry
Example:
dmas = <&dmac 0xd1
&dmac 0xd2>;
dma-names = "tx", "rx";

8
Documentation/devicetree/bindings/drm/tilcdc/tilcdc.txt
View File

@ -10,6 +10,14 @@ Recommended properties:
services interrupts for this device.
- ti,hwmods: Name of the hwmod associated to the LCDC
Optional properties:
- max-bandwidth: The maximum pixels per second that the memory
interface / lcd controller combination can sustain
- max-width: The maximum horizontal pixel width supported by
the lcd controller.
- max-pixelclock: The maximum pixel clock that can be supported
by the lcd controller in KHz.
Example:
fb: fb@4830e000 {

25
Documentation/devicetree/bindings/gpio/men-a021-wdt.txt 100644
View File

@ -0,0 +1,25 @@
Bindings for MEN A21 Watchdog device connected to GPIO lines
Required properties:
- compatible: "men,a021-wdt"
- gpios: Specifies the pins that control the Watchdog, order:
1: Watchdog enable
2: Watchdog fast-mode
3: Watchdog trigger
4: Watchdog reset cause bit 0
5: Watchdog reset cause bit 1
6: Watchdog reset cause bit 2
Optional properties:
- None
Example:
watchdog {
compatible ="men,a021-wdt";
gpios = <&gpio3 9 1 /* WD_EN */
&gpio3 10 1 /* WD_FAST */
&gpio3 11 1 /* WD_TRIG */
&gpio3 6 1 /* RST_CAUSE[0] */
&gpio3 7 1 /* RST_CAUSE[1] */
&gpio3 8 1>; /* RST_CAUSE[2] */
};

15
Documentation/devicetree/bindings/i2c/i2c-designware.txt
View File

@ -10,6 +10,10 @@ Recommended properties :
- clock-frequency : desired I2C bus clock frequency in Hz.
Optional properties :
- i2c-sda-hold-time-ns : should contain the SDA hold time in nanoseconds.
This option is only supported in hardware blocks version 1.11a or newer.
Example :
i2c@f0000 {
@ -20,3 +24,14 @@ Example :
interrupts = <11>;
clock-frequency = <400000>;
};
i2c@1120000 {
#address-cells = <1>;
#size-cells = <0>;
compatible = "snps,designware-i2c";
reg = <0x1120000 0x1000>;
interrupt-parent = <&ictl>;
interrupts = <12 1>;
clock-frequency = <400000>;
i2c-sda-hold-time-ns = <300>;
};

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

@ -6,7 +6,11 @@ Required properties :
- reg : Offset and length of the register set for the device
- compatible : Should be "marvell,mv64xxx-i2c"
- interrupts : The interrupt number
- clock-frequency : Desired I2C bus clock frequency in Hz.
Optional properties :
- clock-frequency : Desired I2C bus clock frequency in Hz. If not set the
default frequency is 100kHz
Examples:

24
Documentation/devicetree/bindings/i2c/i2c-vt8500.txt 100644
View File

@ -0,0 +1,24 @@
* Wondermedia I2C Controller
Required properties :
- compatible : should be "wm,wm8505-i2c"
- reg : Offset and length of the register set for the device
- interrupts : <IRQ> where IRQ is the interrupt number
- clocks : phandle to the I2C clock source
Optional properties :
- clock-frequency : desired I2C bus clock frequency in Hz.
Valid values are 100000 and 400000.
Default to 100000 if not specified, or invalid value.
Example :
i2c_0: i2c@d8280000 {
compatible = "wm,wm8505-i2c";
reg = <0xd8280000 0x1000>;
interrupts = <19>;
clocks = <&clki2c0>;
clock-frequency = <400000>;
};

91
Documentation/devicetree/bindings/input/ads7846.txt 100644
View File

@ -0,0 +1,91 @@
Device tree bindings for TI's ADS7843, ADS7845, ADS7846, ADS7873, TSC2046
SPI driven touch screen controllers.
The node for this driver must be a child node of a SPI controller, hence
all mandatory properties described in
Documentation/devicetree/bindings/spi/spi-bus.txt
must be specified.
Additional required properties:
compatible Must be one of the following, depending on the
model:
"ti,tsc2046"
"ti,ads7843"
"ti,ads7845"
"ti,ads7846"
"ti,ads7873"
interrupt-parent
interrupts An interrupt node describing the IRQ line the chip's
!PENIRQ pin is connected to.
vcc-supply A regulator node for the supply voltage.
Optional properties:
ti,vref-delay-usecs vref supply delay in usecs, 0 for
external vref (u16).
ti,vref-mv The VREF voltage, in millivolts (u16).
ti,keep-vref-on set to keep vref on for differential
measurements as well
ti,swap-xy swap x and y axis
ti,settle-delay-usec Settling time of the analog signals;
a function of Vcc and the capacitance
on the X/Y drivers. If set to non-zero,
two samples are taken with settle_delay
us apart, and the second one is used.
~150 uSec with 0.01uF caps (u16).
ti,penirq-recheck-delay-usecs If set to non-zero, after samples are
taken this delay is applied and penirq
is rechecked, to help avoid false
events. This value is affected by the
material used to build the touch layer
(u16).
ti,x-plate-ohms Resistance of the X-plate,
in Ohms (u16).
ti,y-plate-ohms Resistance of the Y-plate,
in Ohms (u16).
ti,x-min Minimum value on the X axis (u16).
ti,y-min Minimum value on the Y axis (u16).
ti,x-max Maximum value on the X axis (u16).
ti,y-max Minimum value on the Y axis (u16).
ti,pressure-min Minimum reported pressure value
(threshold) - u16.
ti,pressure-max Maximum reported pressure value (u16).
ti,debounce-max Max number of additional readings per
sample (u16).
ti,debounce-tol Tolerance used for filtering (u16).
ti,debounce-rep Additional consecutive good readings
required after the first two (u16).
ti,pendown-gpio-debounce Platform specific debounce time for the
pendown-gpio (u32).
pendown-gpio GPIO handle describing the pin the !PENIRQ
line is connected to.
linux,wakeup use any event on touchscreen as wakeup event.
Example for a TSC2046 chip connected to an McSPI controller of an OMAP SoC::
spi_controller {
tsc2046@0 {
reg = <0>; /* CS0 */
compatible = "ti,tsc2046";
interrupt-parent = <&gpio1>;
interrupts = <8 0>; /* BOOT6 / GPIO 8 */
spi-max-frequency = <1000000>;
pendown-gpio = <&gpio1 8 0>;
vcc-supply = <&reg_vcc3>;
ti,x-min = /bits/ 16 <0>;
ti,x-max = /bits/ 16 <8000>;
ti,y-min = /bits/ 16 <0>;
ti,y-max = /bits/ 16 <4800>;
ti,x-plate-ohms = /bits/ 16 <40>;
ti,pressure-max = /bits/ 16 <255>;
linux,wakeup;
};
};

60
Documentation/devicetree/bindings/input/pxa27x-keypad.txt 100644
View File

@ -0,0 +1,60 @@
* Marvell PXA Keypad controller
Required Properties
- compatible : should be "marvell,pxa27x-keypad"
- reg : Address and length of the register set for the device
- interrupts : The interrupt for the keypad controller
- marvell,debounce-interval : How long time the key will be
recognized when it is pressed. It is a u32 value, and bit[31:16]
is debounce interval for direct key and bit[15:0] is debounce
interval for matrix key. The value is in binary number of 2ms
Optional Properties For Matrix Keyes
Please refer to matrix-keymap.txt
Optional Properties for Direct Keyes
- marvell,direct-key-count : How many direct keyes are used.
- marvell,direct-key-mask : The mask indicates which keyes
are used. If bit[X] of the mask is set, the direct key X
is used.
- marvell,direct-key-low-active : Direct key status register
tells the level of pins that connects to the direct keyes.
When this property is set, it means that when the pin level
is low, the key is pressed(active).
- marvell,direct-key-map : It is a u16 array. Each item indicates
the linux key-code for the direct key.
Optional Properties For Rotary
- marvell,rotary0 : It is a u32 value. Bit[31:16] is the
linux key-code for rotary up. Bit[15:0] is the linux key-code
for rotary down. It is for rotary 0.
- marvell,rotary1 : Same as marvell,rotary0. It is for rotary 1.
- marvell,rotary-rel-key : When rotary is used for relative axes
in the device, the value indicates the key-code for relative
axes measurement in the device. It is a u32 value. Bit[31:16]
is for rotary 1, and Bit[15:0] is for rotary 0.
Examples:
keypad: keypad@d4012000 {
keypad,num-rows = <3>;
keypad,num-columns = <5>;
linux,keymap = <0x0000000e /* KEY_BACKSPACE */
0x0001006b /* KEY_END */
0x00020061 /* KEY_RIGHTCTRL */
0x0003000b /* KEY_0 */
0x00040002 /* KEY_1 */
0x0100008b /* KEY_MENU */
0x01010066 /* KEY_HOME */
0x010200e7 /* KEY_SEND */
0x01030009 /* KEY_8 */
0x0104000a /* KEY_9 */
0x02000160 /* KEY_OK */
0x02010003 /* KEY_2 */
0x02020004 /* KEY_3 */
0x02030005 /* KEY_4 */
0x02040006>; /* KEY_5 */
marvell,rotary0 = <0x006c0067>; /* KEY_UP & KEY_DOWN */
marvell,direct-key-count = <1>;
marvell,direct-key-map = <0x001c>;
marvell,debounce-interval = <0x001e001e>;
};

24
Documentation/devicetree/bindings/input/samsung-keypad.txt
View File

@ -25,14 +25,6 @@ Required Board Specific Properties:
- samsung,keypad-num-columns: Number of column lines connected to the
keypad controller.
- row-gpios: List of gpios used as row lines. The gpio specifier for
this property depends on the gpio controller to which these row lines
are connected.
- col-gpios: List of gpios used as column lines. The gpio specifier for
this property depends on the gpio controller to which these column
lines are connected.
- Keys represented as child nodes: Each key connected to the keypad
controller is represented as a child node to the keypad controller
device node and should include the following properties.
@ -41,6 +33,9 @@ Required Board Specific Properties:
- linux,code: the key-code to be reported when the key is pressed
and released.
- pinctrl-0: Should specify pin control groups used for this controller.
- pinctrl-names: Should contain only one value - "default".
Optional Properties specific to linux:
- linux,keypad-no-autorepeat: do no enable autorepeat feature.
- linux,keypad-wakeup: use any event on keypad as wakeup event.
@ -56,17 +51,8 @@ Example:
linux,input-no-autorepeat;
linux,input-wakeup;
row-gpios = <&gpx2 0 3 3 0
&gpx2 1 3 3 0>;
col-gpios = <&gpx1 0 3 0 0
&gpx1 1 3 0 0
&gpx1 2 3 0 0
&gpx1 3 3 0 0
&gpx1 4 3 0 0
&gpx1 5 3 0 0
&gpx1 6 3 0 0
&gpx1 7 3 0 0>;
pinctrl-names = "default";
pinctrl-0 = <&keypad_rows &keypad_columns>;
key_1 {
keypad,row = <0>;

60
Documentation/devicetree/bindings/input/ti,nspire-keypad.txt 100644
View File

@ -0,0 +1,60 @@
TI-NSPIRE Keypad
Required properties:
- compatible: Compatible property value should be "ti,nspire-keypad".
- reg: Physical base address of the peripheral and length of memory mapped
region.
- interrupts: The interrupt number for the peripheral.
- scan-interval: How often to scan in us. Based on a APB speed of 33MHz, the
maximum and minimum delay time is ~2000us and ~500us respectively
- row-delay: How long to wait before scanning each row.
- clocks: The clock this peripheral is attached to.
- linux,keymap: The keymap to use
(see Documentation/devicetree/bindings/input/matrix-keymap.txt)
Optional properties:
- active-low: Specify that the keypad is active low (i.e. logical low signifies
a key press).
Example:
input {
compatible = "ti,nspire-keypad";
reg = <0x900E0000 0x1000>;
interrupts = <16>;
scan-interval = <1000>;
row-delay = <200>;
clocks = <&apb_pclk>;
linux,keymap = <
0x0000001c 0x0001001c 0x00040039
0x0005002c 0x00060015 0x0007000b
0x0008000f 0x0100002d 0x01010011
0x0102002f 0x01030004 0x01040016
0x01050014 0x0106001f 0x01070002
0x010a006a 0x02000013 0x02010010
0x02020019 0x02030007 0x02040018
0x02050031 0x02060032 0x02070005
0x02080028 0x0209006c 0x03000026
0x03010025 0x03020024 0x0303000a
0x03040017 0x03050023 0x03060022
0x03070008 0x03080035 0x03090069
0x04000021 0x04010012 0x04020020
0x0404002e 0x04050030 0x0406001e
0x0407000d 0x04080037 0x04090067
0x05010038 0x0502000c 0x0503001b
0x05040034 0x0505001a 0x05060006
0x05080027 0x0509000e 0x050a006f
0x0600002b 0x0602004e 0x06030068
0x06040003 0x0605006d 0x06060009
0x06070001 0x0609000f 0x0708002a
0x0709001d 0x070a0033 >;
};

44
Documentation/devicetree/bindings/input/touchscreen/ti-tsc-adc.txt 100644
View File

@ -0,0 +1,44 @@
* TI - TSC ADC (Touschscreen and analog digital converter)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Required properties:
- child "tsc"
ti,wires: Wires refer to application modes i.e. 4/5/8 wire touchscreen
support on the platform.
ti,x-plate-resistance: X plate resistance
ti,coordiante-readouts: The sequencer supports a total of 16
programmable steps each step is used to
read a single coordinate. A single
readout is enough but multiple reads can
increase the quality.
A value of 5 means, 5 reads for X, 5 for
Y and 2 for Z (always). This utilises 12
of the 16 software steps available. The
remaining 4 can be used by the ADC.
ti,wire-config: Different boards could have a different order for
connecting wires on touchscreen. We need to provide an
8 bit number where in the 1st four bits represent the
analog lines and the next 4 bits represent positive/
negative terminal on that input line. Notations to
represent the input lines and terminals resoectively
is as follows:
AIN0 = 0, AIN1 = 1 and so on till AIN7 = 7.
XP = 0, XN = 1, YP = 2, YN = 3.
- child "adc"
ti,adc-channels: List of analog inputs available for ADC.
AIN0 = 0, AIN1 = 1 and so on till AIN7 = 7.
Example:
tscadc: tscadc@44e0d000 {
compatible = "ti,am3359-tscadc";
tsc {
ti,wires = <4>;
ti,x-plate-resistance = <200>;
ti,coordiante-readouts = <5>;
ti,wire-config = <0x00 0x11 0x22 0x33>;
};
adc {
ti,adc-channels = <4 5 6 7>;
};
}

70
Documentation/devicetree/bindings/iommu/arm,smmu.txt 100644
View File

@ -0,0 +1,70 @@
* ARM System MMU Architecture Implementation
ARM SoCs may contain an implementation of the ARM System Memory
Management Unit Architecture, which can be used to provide 1 or 2 stages
of address translation to bus masters external to the CPU.
The SMMU may also raise interrupts in response to various fault
conditions.
** System MMU required properties:
- compatible : Should be one of:
"arm,smmu-v1"
"arm,smmu-v2"
"arm,mmu-400"
"arm,mmu-500"
depending on the particular implementation and/or the
version of the architecture implemented.
- reg : Base address and size of the SMMU.
- #global-interrupts : The number of global interrupts exposed by the
device.
- interrupts : Interrupt list, with the first #global-irqs entries
corresponding to the global interrupts and any
following entries corresponding to context interrupts,
specified in order of their indexing by the SMMU.
For SMMUv2 implementations, there must be exactly one
interrupt per context bank. In the case of a single,
combined interrupt, it must be listed multiple times.
- mmu-masters : A list of phandles to device nodes representing bus
masters for which the SMMU can provide a translation
and their corresponding StreamIDs (see example below).
Each device node linked from this list must have a
"#stream-id-cells" property, indicating the number of
StreamIDs associated with it.
** System MMU optional properties:
- smmu-parent : When multiple SMMUs are chained together, this
property can be used to provide a phandle to the
parent SMMU (that is the next SMMU on the path going
from the mmu-masters towards memory) node for this
SMMU.
Example:
smmu {
compatible = "arm,smmu-v1";
reg = <0xba5e0000 0x10000>;
#global-interrupts = <2>;
interrupts = <0 32 4>,
<0 33 4>,
<0 34 4>, /* This is the first context interrupt */
<0 35 4>,
<0 36 4>,
<0 37 4>;
/*
* Two DMA controllers, the first with two StreamIDs (0xd01d
* and 0xd01e) and the second with only one (0xd11c).
*/
mmu-masters = <&dma0 0xd01d 0xd01e>,
<&dma1 0xd11c>;
};

6
Documentation/devicetree/bindings/media/exynos-fimc-lite.txt
View File

@ -2,8 +2,10 @@ Exynos4x12/Exynos5 SoC series camera host interface (FIMC-LITE)
Required properties:
- compatible : should be "samsung,exynos4212-fimc-lite" for Exynos4212 and
Exynos4412 SoCs;
- compatible : should be one of:
"samsung,exynos4212-fimc-lite" for Exynos4212/4412 SoCs,
"samsung,exynos5250-fimc-lite" for Exynos5250 compatible
devices;
- reg : physical base address and size of the device memory mapped
registers;
- interrupts : should contain FIMC-LITE interrupt;

40
Documentation/devicetree/bindings/media/i2c/mt9p031.txt 100644
View File

@ -0,0 +1,40 @@
* Aptina 1/2.5-Inch 5Mp CMOS Digital Image Sensor
The Aptina MT9P031 is a 1/2.5-inch CMOS active pixel digital image sensor with
an active array size of 2592H x 1944V. It is programmable through a simple
two-wire serial interface.
Required Properties:
- compatible: value should be either one among the following
(a) "aptina,mt9p031" for mt9p031 sensor
(b) "aptina,mt9p031m" for mt9p031m sensor
- input-clock-frequency: Input clock frequency.
- pixel-clock-frequency: Pixel clock frequency.
Optional Properties:
- reset-gpios: Chip reset GPIO
For further reading on port node refer to
Documentation/devicetree/bindings/media/video-interfaces.txt.
Example:
i2c0@1c22000 {
...
...
mt9p031@5d {
compatible = "aptina,mt9p031";
reg = <0x5d>;
reset-gpios = <&gpio3 30 0>;
port {
mt9p031_1: endpoint {
input-clock-frequency = <6000000>;
pixel-clock-frequency = <96000000>;
};
};
};
...
};

44
Documentation/devicetree/bindings/media/i2c/tvp514x.txt 100644
View File

@ -0,0 +1,44 @@
* Texas Instruments TVP514x video decoder
The TVP5146/TVP5146m2/TVP5147/TVP5147m1 device is high quality, single-chip
digital video decoder that digitizes and decodes all popular baseband analog
video formats into digital video component. The tvp514x decoder supports analog-
to-digital (A/D) conversion of component RGB and YPbPr signals as well as A/D
conversion and decoding of NTSC, PAL and SECAM composite and S-video into
component YCbCr.
Required Properties :
- compatible : value should be either one among the following
(a) "ti,tvp5146" for tvp5146 decoder.
(b) "ti,tvp5146m2" for tvp5146m2 decoder.
(c) "ti,tvp5147" for tvp5147 decoder.
(d) "ti,tvp5147m1" for tvp5147m1 decoder.
- hsync-active: HSYNC Polarity configuration for endpoint.
- vsync-active: VSYNC Polarity configuration for endpoint.
- pclk-sample: Clock polarity of the endpoint.
For further reading on port node refer to Documentation/devicetree/bindings/
media/video-interfaces.txt.
Example:
i2c0@1c22000 {
...
...
tvp514x@5c {
compatible = "ti,tvp5146";
reg = <0x5c>;
port {
tvp514x_1: endpoint {
hsync-active = <1>;
vsync-active = <1>;
pclk-sample = <0>;
};
};
};
...
};

26
Documentation/devicetree/bindings/media/samsung-fimc.txt
View File

@ -127,22 +127,22 @@ Example:
};
};
};
};
/* MIPI CSI-2 bus IF sensor */
s5c73m3: sensor@0x1a {
compatible = "samsung,s5c73m3";
reg = <0x1a>;
vddio-supply = <...>;
/* MIPI CSI-2 bus IF sensor */
s5c73m3: sensor@0x1a {
compatible = "samsung,s5c73m3";
reg = <0x1a>;
vddio-supply = <...>;
clock-frequency = <24000000>;
clocks = <...>;
clock-names = "mclk";
clock-frequency = <24000000>;
clocks = <...>;
clock-names = "mclk";
port {
s5c73m3_1: endpoint {
data-lanes = <1 2 3 4>;
remote-endpoint = <&csis0_ep>;
port {
s5c73m3_1: endpoint {
data-lanes = <1 2 3 4>;
remote-endpoint = <&csis0_ep>;
};
};
};
};

4
Documentation/devicetree/bindings/media/samsung-mipi-csis.txt
View File

@ -5,8 +5,8 @@ Required properties:
- compatible : "samsung,s5pv210-csis" for S5PV210 (S5PC110),
"samsung,exynos4210-csis" for Exynos4210 (S5PC210),
"samsung,exynos4212-csis" for Exynos4212/Exynos4412
SoC series;
"samsung,exynos4212-csis" for Exynos4212/Exynos4412,
"samsung,exynos5250-csis" for Exynos5250;
- reg : offset and length of the register set for the device;
- interrupts : should contain MIPI CSIS interrupt; the format of the
interrupt specifier depends on the interrupt controller;

18
Documentation/devicetree/bindings/media/sh_mobile_ceu.txt 100644
View File

@ -0,0 +1,18 @@
Bindings, specific for the sh_mobile_ceu_camera.c driver:
- compatible: Should be "renesas,sh-mobile-ceu"
- reg: register base and size
- interrupts: the interrupt number
- interrupt-parent: the interrupt controller
- renesas,max-width: maximum image width, supported on this SoC
- renesas,max-height: maximum image height, supported on this SoC
Example:
ceu0: ceu@0xfe910000 {
compatible = "renesas,sh-mobile-ceu";
reg = <0xfe910000 0xa0>;
interrupt-parent = <&intcs>;
interrupts = <0x880>;
renesas,max-width = <8188>;
renesas,max-height = <8188>;
};

30
Documentation/devicetree/bindings/metag/meta.txt 100644
View File

@ -0,0 +1,30 @@
* Meta Processor Binding
This binding specifies what properties must be available in the device tree
representation of a Meta Processor Core, which is the root node in the tree.
Required properties:
- compatible: Specifies the compatibility list for the Meta processor.
The type shall be <string> and the value shall include "img,meta".
Optional properties:
- clocks: Clock consumer specifiers as described in
Documentation/devicetree/bindings/clock/clock-bindings.txt
- clock-names: Clock consumer names as described in
Documentation/devicetree/bindings/clock/clock-bindings.txt.
Clocks are identified by name. Valid clocks are:
- "core": The Meta core clock from which the Meta timers are derived.
* Examples
/ {
compatible = "toumaz,tz1090", "img,meta";
clocks = <&meta_core_clk>;
clock-names = "core";
};

119
Documentation/devicetree/bindings/mfd/max8998.txt 100644
View File

@ -0,0 +1,119 @@
* Maxim MAX8998, National/TI LP3974 multi-function device
The Maxim MAX8998 is a multi-function device which includes voltage/current
regulators, real time clock, battery charging controller and several
other sub-blocks. It is interfaced using an I2C interface. Each sub-block
is addressed by the host system using different i2c slave address.
PMIC sub-block
--------------
The PMIC sub-block contains a number of voltage and current regulators,
with controllable parameters and dynamic voltage scaling capability.
In addition, it includes a real time clock and battery charging controller
as well. It is accessible at I2C address 0x66.
Required properties:
- compatible: Should be one of the following:
- "maxim,max8998" for Maxim MAX8998
- "national,lp3974" or "ti,lp3974" for National/TI LP3974.
- 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 MAX8998 are routed to.
- interrupts: Interrupt specifiers for two interrupt sources.
- First interrupt specifier is for main interrupt.
- Second interrupt specifier is for power-on/-off interrupt.
- max8998,pmic-buck1-dvs-gpios: GPIO specifiers for two host gpios used
for buck 1 dvs. The format of the gpio specifier depends on the gpio
controller.
- max8998,pmic-buck2-dvs-gpio: GPIO specifier for host gpio used
for buck 2 dvs. The format of the gpio specifier depends on the gpio
controller.
- max8998,pmic-buck1-default-dvs-idx: Default voltage setting selected from
the possible 4 options selectable by the dvs gpios. The value of this
property should be 0, 1, 2 or 3. If not specified or out of range,
a default value of 0 is taken.
- max8998,pmic-buck2-default-dvs-idx: Default voltage setting selected from
the possible 2 options selectable by the dvs gpios. The value of this
property should be 0 or 1. If not specified or out of range, a default
value of 0 is taken.
- max8998,pmic-buck-voltage-lock: If present, disallows changing of
preprogrammed buck dvfs voltages.
Additional properties required if max8998,pmic-buck1-dvs-gpios is defined:
- max8998,pmic-buck1-dvs-voltage: An array of 4 voltage values in microvolts
for buck1 regulator that can be selected using dvs gpio.
Additional properties required if max8998,pmic-buck2-dvs-gpio is defined:
- max8998,pmic-buck2-dvs-voltage: An array of 2 voltage values in microvolts
for buck2 regulator that can be selected using dvs gpio.
Regulators: All the regulators of MAX8998 to be instantiated shall be
listed in a child node named 'regulators'. Each regulator is represented
by a child node of the 'regulators' node.
regulator-name {
/* standard regulator bindings here */
};
Following regulators of the MAX8998 PMIC block are supported. Note that
the 'n' in regulator name, as in LDOn or BUCKn, represents the LDO or BUCK
number as described in MAX8998 datasheet.
- LDOn
- valid values for n are 2 to 17
- Example: LDO2, LDO10, LDO17
- BUCKn
- valid values for n are 1 to 4.
- Example: BUCK1, BUCK2, BUCK3, BUCK4
- ENVICHG: Battery Charging Current Monitor Output. This is a fixed
voltage type regulator
- ESAFEOUT1: (ldo19)
- ESAFEOUT2: (ld020)
Standard regulator bindings are used inside regulator subnodes. Check
Documentation/devicetree/bindings/regulator/regulator.txt
for more details.
Example:
pmic@66 {
compatible = "maxim,max8998-pmic";
reg = <0x66>;
interrupt-parent = <&wakeup_eint>;
interrupts = <4 0>, <3 0>;
/* Buck 1 DVS settings */
max8998,pmic-buck1-default-dvs-idx = <0>;
max8998,pmic-buck1-dvs-gpios = <&gpx0 0 1 0 0>, /* SET1 */
<&gpx0 1 1 0 0>; /* SET2 */
max8998,pmic-buck1-dvs-voltage = <1350000>, <1300000>,
<1000000>, <950000>;
/* Buck 2 DVS settings */
max8998,pmic-buck2-default-dvs-idx = <0>;
max8998,pmic-buck2-dvs-gpio = <&gpx0 0 3 0 0>; /* SET3 */
max8998,pmic-buck2-dvs-voltage = <1350000>, <1300000>;
/* Regulators to instantiate */
regulators {
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_ARM_1.2V";
regulator-min-microvolt = <950000>;
regulator-max-microvolt = <1350000>;
regulator-always-on;
regulator-boot-on;
};
};
};

49
Documentation/devicetree/bindings/mfd/palmas.txt 100644
View File

@ -0,0 +1,49 @@
* palmas device tree bindings
The TI palmas family current members :-
twl6035 (palmas)
twl6037 (palmas)
tps65913 (palmas)
tps65914 (palmas)
Required properties:
- compatible : Should be from the list
ti,twl6035
ti,twl6036
ti,twl6037
ti,tps65913
ti,tps65914
ti,tps80036
and also the generic series names
ti,palmas
- interrupt-controller : palmas has its own internal IRQs
- #interrupt-cells : should be set to 2 for IRQ number and flags
The first cell is the IRQ number.
The second cell is the flags, encoded as the trigger masks from
Documentation/devicetree/bindings/interrupts.txt
- interrupt-parent : The parent interrupt controller.
Optional properties:
ti,mux-padX : set the pad register X (1-2) to the correct muxing for the
hardware, if not set will use muxing in OTP.
Example:
palmas {
compatible = "ti,twl6035", "ti,palmas";
reg = <0x48>
interrupt-parent = <&intc>;
interrupt-controller;
#interrupt-cells = <2>;
ti,mux-pad1 = <0>;
ti,mux-pad2 = <0>;
#address-cells = <1>;
#size-cells = <0>;
pmic {
compatible = "ti,twl6035-pmic", "ti,palmas-pmic";
....
};
}

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

@ -0,0 +1,28 @@
Texas Instruments TWL family (twl4030) reset and power management module
The power management module inside the TWL family provides several facilities
to control the power resources, including power scripts. For now, the
binding only supports the complete shutdown of the system after poweroff.
Required properties:
- compatible : must be "ti,twl4030-power"
Optional properties:
- ti,use_poweroff: With this flag, the chip will initiates an ACTIVE-to-OFF or
SLEEP-to-OFF transition when the system poweroffs.
Example:
&i2c1 {
clock-frequency = <2600000>;
twl: twl@48 {
reg = <0x48>;
interrupts = <7>; /* SYS_NIRQ cascaded to intc */
interrupt-parent = <&intc>;
twl_power: power {
compatible = "ti,twl4030-power";
ti,use_poweroff;
};
};
};

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

@ -28,6 +28,7 @@ Optional properties:
- cap-mmc-highspeed: MMC high-speed timing is supported
- cap-power-off-card: powering off the card is safe
- cap-sdio-irq: enable SDIO IRQ signalling on this interface
- full-pwr-cycle: full power cycle of the card is supported
*NOTE* on CD and WP polarity. To use common for all SD/MMC host controllers line
polarity properties, we have to fix the meaning of the "normal" and "inverted"

23
Documentation/devicetree/bindings/mmc/rockchip-dw-mshc.txt 100644
View File

@ -0,0 +1,23 @@
* Rockchip specific extensions to the Synopsis Designware Mobile
Storage Host Controller
The Synopsis designware mobile storage host controller is used to interface
a SoC with storage medium such as eMMC or SD/MMC cards. This file documents
differences between the core Synopsis dw mshc controller properties described
by synopsis-dw-mshc.txt and the properties used by the Rockchip specific
extensions to the Synopsis Designware Mobile Storage Host Controller.
Required Properties:
* compatible: should be
- "rockchip,rk2928-dw-mshc": for Rockchip RK2928 and following
Example:
rkdwmmc0@12200000 {
compatible = "rockchip,rk2928-dw-mshc";
reg = <0x12200000 0x1000>;
interrupts = <0 75 0>;
#address-cells = <1>;
#size-cells = <0>;
};

22
Documentation/devicetree/bindings/mmc/synopsis-dw-mshc.txt
View File

@ -39,6 +39,19 @@ Required Properties:
Optional properties:
* clocks: from common clock binding: handle to biu and ciu clocks for the
bus interface unit clock and the card interface unit clock.
* clock-names: from common clock binding: Shall be "biu" and "ciu".
If the biu clock is missing we'll simply skip enabling it. If the
ciu clock is missing we'll just assume that the clock is running at
clock-frequency. It is an error to omit both the ciu clock and the
clock-frequency.
* clock-frequency: should be the frequency (in Hz) of the ciu clock. If this
is specified and the ciu clock is specified then we'll try to set the ciu
clock to this at probe time.
* num-slots: specifies the number of slots supported by the controller.
The number of physical slots actually used could be equal or less than the
value specified by num-slots. If this property is not specified, the value
@ -51,10 +64,13 @@ Optional properties:
* card-detect-delay: Delay in milli-seconds before detecting card after card
insert event. The default value is 0.
* supports-highspeed: Enables support for high speed cards (upto 50MHz)
* supports-highspeed: Enables support for high speed cards (up to 50MHz)
* broken-cd: as documented in mmc core bindings.
* vmmc-supply: The phandle to the regulator to use for vmmc. If this is
specified we'll defer probe until we can find this regulator.
Aliases:
- All the MSHC controller nodes should be represented in the aliases node using
@ -67,6 +83,8 @@ board specific portions as listed below.
dwmmc0@12200000 {
compatible = "snps,dw-mshc";
clocks = <&clock 351>, <&clock 132>;
clock-names = "biu", "ciu";
reg = <0x12200000 0x1000>;
interrupts = <0 75 0>;
#address-cells = <1>;
@ -74,11 +92,13 @@ board specific portions as listed below.
};
dwmmc0@12200000 {
clock-frequency = <400000000>;
num-slots = <1>;
supports-highspeed;
broken-cd;
fifo-depth = <0x80>;
card-detect-delay = <200>;
vmmc-supply = <&buck8>;
slot@0 {
reg = <0>;

22
Documentation/devicetree/bindings/net/allwinner,sun4i-emac.txt 100644
View File

@ -0,0 +1,22 @@
* Allwinner EMAC ethernet controller
Required properties:
- compatible: should be "allwinner,sun4i-emac".
- reg: address and length of the register set for the device.
- interrupts: interrupt for the device
- phy: A phandle to a phy node defining the PHY address (as the reg
property, a single integer).
- clocks: A phandle to the reference clock for this device
Optional properties:
- (local-)mac-address: mac address to be used by this driver
Example:
emac: ethernet@01c0b000 {
compatible = "allwinner,sun4i-emac";
reg = <0x01c0b000 0x1000>;
interrupts = <55>;
clocks = <&ahb_gates 17>;
phy = <&phy0>;
};

26
Documentation/devicetree/bindings/net/allwinner,sun4i-mdio.txt 100644
View File

@ -0,0 +1,26 @@
* Allwinner A10 MDIO Ethernet Controller interface
Required properties:
- compatible: should be "allwinner,sun4i-mdio".
- reg: address and length of the register set for the device.
Optional properties:
- phy-supply: phandle to a regulator if the PHY needs one
Example at the SoC level:
mdio@01c0b080 {
compatible = "allwinner,sun4i-mdio";
reg = <0x01c0b080 0x14>;
#address-cells = <1>;
#size-cells = <0>;
};
And at the board level:
mdio@01c0b080 {
phy-supply = <&reg_emac_3v3>;
phy0: ethernet-phy@0 {
reg = <0>;
};
};

38
Documentation/devicetree/bindings/net/arc_emac.txt 100644
View File

@ -0,0 +1,38 @@
* Synopsys ARC EMAC 10/100 Ethernet driver (EMAC)
Required properties:
- compatible: Should be "snps,arc-emac"
- reg: Address and length of the register set for the device
- interrupts: Should contain the EMAC interrupts
- clock-frequency: CPU frequency. It is needed to calculate and set polling
period of EMAC.
- max-speed: Maximum supported data-rate in Mbit/s. In some HW configurations
bandwidth of external memory controller might be a limiting factor. That's why
it's required to specify which data-rate is supported on current SoC or FPGA.
For example if only 10 Mbit/s is supported (10BASE-T) set "10". If 100 Mbit/s is
supported (100BASE-TX) set "100".
- phy: PHY device attached to the EMAC via MDIO bus
Child nodes of the driver are the individual PHY devices connected to the
MDIO bus. They must have a "reg" property given the PHY address on the MDIO bus.
Optional properties:
- mac-address: 6 bytes, mac address
Examples:
ethernet@c0fc2000 {
compatible = "snps,arc-emac";
reg = <0xc0fc2000 0x3c>;
interrupts = <6>;
mac-address = [ 00 11 22 33 44 55 ];
clock-frequency = <80000000>;
max-speed = <100>;
phy = <&phy0>;
#address-cells = <1>;
#size-cells = <0>;
phy0: ethernet-phy@0 {
reg = <1>;
};
};

2
Documentation/devicetree/bindings/net/can/fsl-flexcan.txt
View File

@ -16,6 +16,8 @@ Optional properties:
- clock-frequency : The oscillator frequency driving the flexcan device
- xceiver-supply: Regulator that powers the CAN transceiver
Example:
can@1c000 {

6
Documentation/devicetree/bindings/net/cpsw.txt
View File

@ -28,6 +28,8 @@ Optional properties:
Slave Properties:
Required properties:
- phy_id : Specifies slave phy id
- phy-mode : The interface between the SoC and the PHY (a string
that of_get_phy_mode() can understand)
- mac-address : Specifies slave MAC address
Optional properties:
@ -58,11 +60,13 @@ Examples:
cpts_clock_shift = <29>;
cpsw_emac0: slave@0 {
phy_id = <&davinci_mdio>, <0>;
phy-mode = "rgmii-txid";
/* Filled in by U-Boot */
mac-address = [ 00 00 00 00 00 00 ];
};
cpsw_emac1: slave@1 {
phy_id = <&davinci_mdio>, <1>;
phy-mode = "rgmii-txid";
/* Filled in by U-Boot */
mac-address = [ 00 00 00 00 00 00 ];
};
@ -84,11 +88,13 @@ Examples:
cpts_clock_shift = <29>;
cpsw_emac0: slave@0 {
phy_id = <&davinci_mdio>, <0>;
phy-mode = "rgmii-txid";
/* Filled in by U-Boot */
mac-address = [ 00 00 00 00 00 00 ];
};
cpsw_emac1: slave@1 {
phy_id = <&davinci_mdio>, <1>;
phy-mode = "rgmii-txid";
/* Filled in by U-Boot */
mac-address = [ 00 00 00 00 00 00 ];
};

26
Documentation/devicetree/bindings/net/davicom-dm9000.txt 100644
View File

@ -0,0 +1,26 @@
Davicom DM9000 Fast Ethernet controller
Required properties:
- compatible = "davicom,dm9000";
- reg : physical addresses and sizes of registers, must contain 2 entries:
first entry : address register,
second entry : data register.
- interrupt-parent : interrupt controller to which the device is connected
- interrupts : interrupt specifier specific to interrupt controller
Optional properties:
- local-mac-address : A bytestring of 6 bytes specifying Ethernet MAC address
to use (from firmware or bootloader)
- davicom,no-eeprom : Configuration EEPROM is not available
- davicom,ext-phy : Use external PHY
Example:
ethernet@18000000 {
compatible = "davicom,dm9000";
reg = <0x18000000 0x2 0x18000004 0x2>;
interrupt-parent = <&gpn>;
interrupts = <7 4>;
local-mac-address = [00 00 de ad be ef];
davicom,no-eeprom;
};

85
Documentation/devicetree/bindings/net/marvell-orion-net.txt 100644
View File

@ -0,0 +1,85 @@
Marvell Orion/Discovery ethernet controller
=============================================
The Marvell Discovery ethernet controller can be found on Marvell Orion SoCs
(Kirkwood, Dove, Orion5x, and Discovery Innovation) and as part of Marvell
Discovery system controller chips (mv64[345]60).
The Discovery ethernet controller is described with two levels of nodes. The
first level describes the ethernet controller itself and the second level
describes up to 3 ethernet port nodes within that controller. The reason for
the multiple levels is that the port registers are interleaved within a single
set of controller registers. Each port node describes port-specific properties.
Note: The above separation is only true for Discovery system controllers.
For Orion SoCs we stick to the separation, although there each controller has
only one port associated. Multiple ports are implemented as multiple single-port
controllers. As Kirkwood has some issues with proper initialization after reset,
an extra compatible string is added for it.
* Ethernet controller node
Required controller properties:
- #address-cells: shall be 1.
- #size-cells: shall be 0.
- compatible: shall be one of "marvell,orion-eth", "marvell,kirkwood-eth".
- reg: address and length of the controller registers.
Optional controller properties:
- clocks: phandle reference to the controller clock.
- marvell,tx-checksum-limit: max tx packet size for hardware checksum.
* Ethernet port node
Required port properties:
- device_type: shall be "network".
- compatible: shall be one of "marvell,orion-eth-port",
"marvell,kirkwood-eth-port".
- reg: port number relative to ethernet controller, shall be 0, 1, or 2.
- interrupts: port interrupt.
- local-mac-address: 6 bytes MAC address.
Optional port properties:
- marvell,tx-queue-size: size of the transmit ring buffer.
- marvell,tx-sram-addr: address of transmit descriptor buffer located in SRAM.
- marvell,tx-sram-size: size of transmit descriptor buffer located in SRAM.
- marvell,rx-queue-size: size of the receive ring buffer.
- marvell,rx-sram-addr: address of receive descriptor buffer located in SRAM.
- marvell,rx-sram-size: size of receive descriptor buffer located in SRAM.
and
- phy-handle: phandle reference to ethernet PHY.
or
- speed: port speed if no PHY connected.
- duplex: port mode if no PHY connected.
* Node example:
mdio-bus {
...
ethphy: ethernet-phy@8 {
device_type = "ethernet-phy";
...
};
};
eth: ethernet-controller@72000 {
compatible = "marvell,orion-eth";
#address-cells = <1>;
#size-cells = <0>;
reg = <0x72000 0x2000>;
clocks = <&gate_clk 2>;
marvell,tx-checksum-limit = <1600>;
ethernet@0 {
device_type = "network";
compatible = "marvell,orion-eth-port";
reg = <0>;
interrupts = <29>;
phy-handle = <&ethphy>;
local-mac-address = [00 00 00 00 00 00];
};
};

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

@ -0,0 +1,9 @@
Micrel KS8851 Ethernet mac
Required properties:
- compatible = "micrel,ks8851-ml" of parallel interface
- reg : 2 physical address and size of registers for data and command
- interrupts : interrupt connection
Optional properties:
- local-mac-address : Ethernet mac address to use

10
Documentation/devicetree/bindings/net/stmmac.txt
View File

@ -12,6 +12,16 @@ Required properties:
property
- phy-mode: String, operation mode of the PHY interface.
Supported values are: "mii", "rmii", "gmii", "rgmii".
- snps,phy-addr phy address to connect to.
- snps,reset-gpio gpio number for phy reset.
- snps,reset-active-low boolean flag to indicate if phy reset is active low.
- snps,reset-delays-us is triplet of delays
The 1st cell is reset pre-delay in micro seconds.
The 2nd cell is reset pulse in micro seconds.
The 3rd cell is reset post-delay in micro seconds.
- snps,pbl Programmable Burst Length
- snps,fixed-burst Program the DMA to use the fixed burst mode
- snps,mixed-burst Program the DMA to use the mixed burst mode
Optional properties:
- mac-address: 6 bytes, mac address

20
Documentation/devicetree/bindings/net/via-velocity.txt 100644
View File

@ -0,0 +1,20 @@
* VIA Velocity 10/100/1000 Network Controller
Required properties:
- compatible : Should be "via,velocity-vt6110"
- reg : Address and length of the io space
- interrupts : Should contain the controller interrupt line
Optional properties:
- no-eeprom : PCI network cards use an external EEPROM to store data. Embedded
devices quite often set this data in uboot and do not provide an eeprom.
Specify this option if you have no external eeprom.
Examples:
eth0@d8004000 {
compatible = "via,velocity-vt6110";
reg = <0xd8004000 0x400>;
interrupts = <10>;
no-eeprom;
};

44
Documentation/devicetree/bindings/power_supply/lp8727_charger.txt 100644
View File

@ -0,0 +1,44 @@
Binding for TI/National Semiconductor LP8727 Charger
Required properties:
- compatible: "ti,lp8727"
- reg: I2C slave address 27h
Optional properties:
- interrupt-parent: interrupt controller node (see interrupt binding[0])
- interrupts: interrupt specifier (see interrupt binding[0])
- debounce-ms: interrupt debounce time. (u32)
AC and USB charging parameters
- charger-type: "ac" or "usb" (string)
- eoc-level: value of 'enum lp8727_eoc_level' (u8)
- charging-current: value of 'enum lp8727_ichg' (u8)
[0]: Documentation/devicetree/bindings/interrupt-controller/interrupts.txt
Example)
lp8727@27 {
compatible = "ti,lp8727";
reg = <0x27>;
/* GPIO 134 is used for LP8728 interrupt pin */
interrupt-parent = <&gpio5>; /* base = 128 */
interrupts = <6 0x2>; /* offset = 6, falling edge type */
debounce-ms = <300>;
/* AC charger: 5% EOC and 500mA charging current */
ac {
charger-type = "ac";
eoc-level = /bits/ 8 <0>;
charging-current = /bits/ 8 <4>;
};
/* USB charger: 10% EOC and 400mA charging current */
usb {
charger-type = "usb";
eoc-level = /bits/ 8 <1>;
charging-current = /bits/ 8 <2>;
};
};

2
Documentation/devicetree/bindings/powerpc/4xx/emac.txt
View File

@ -1,7 +1,7 @@
4xx/Axon EMAC ethernet nodes
The EMAC ethernet controller in IBM and AMCC 4xx chips, and also
the Axon bridge. To operate this needs to interact with a ths
the Axon bridge. To operate this needs to interact with a this
special McMAL DMA controller, and sometimes an RGMII or ZMII
interface. In addition to the nodes and properties described
below, the node for the OPB bus on which the EMAC sits must have a

27
Documentation/devicetree/bindings/pwm/nxp,pca9685-pwm.txt 100644
View File

@ -0,0 +1,27 @@
NXP PCA9685 16-channel 12-bit PWM LED controller
================================================
Required properties:
- compatible: "nxp,pca9685-pwm"
- #pwm-cells: should be 2. The first cell specifies the per-chip index
of the PWM to use and the second cell is the period in nanoseconds.
The index 16 is the ALLCALL channel, that sets all PWM channels at the same
time.
Optional properties:
- invert (bool): boolean to enable inverted logic
- open-drain (bool): boolean to configure outputs with open-drain structure;
if omitted use totem-pole structure
Example:
For LEDs that are directly connected to the PCA, the following setting is
applicable:
pca: pca@41 {
compatible = "nxp,pca9685-pwm";
#pwm-cells = <2>;
reg = <0x41>;
invert;
open-drain;
};

2
Documentation/devicetree/bindings/regulator/max8997-regulator.txt
View File

@ -1,6 +1,6 @@
* Maxim MAX8997 Voltage and Current Regulator
The Maxim MAX8997 is a multi-function device which includes volatage and
The Maxim MAX8997 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. This document

70
Documentation/devicetree/bindings/regulator/palmas-pmic.txt 100644
View File

@ -0,0 +1,70 @@
* palmas regulator IP block devicetree bindings
Required properties:
- compatible : Should be from the list
ti,twl6035-pmic
ti,twl6036-pmic
ti,twl6037-pmic
ti,tps65913-pmic
ti,tps65914-pmic
and also the generic series names
ti,palmas-pmic
- interrupt-parent : The parent interrupt controller which is palmas.
- interrupts : The interrupt number and the type which can be looked up here:
arch/arm/boot/dts/include/dt-bindings/interrupt-controller/irq.h
- interrupts-name: The names of the individual interrupts.
Optional properties:
- ti,ldo6-vibrator : ldo6 is in vibrator mode
Optional nodes:
- regulators : Must contain a sub-node per regulator from the list below.
Each sub-node should contain the constraints and initialization
information for that regulator. See regulator.txt for a
description of standard properties for these sub-nodes.
Additional custom properties are listed below.
For ti,palmas-pmic - smps12, smps123, smps3 depending on OTP,
smps45, smps457, smps7 depending on variant, smps6, smps[8-10],
ldo[1-9], ldoln, ldousb.
Optional sub-node properties:
ti,warm-reset - maintain voltage during warm reset(boolean)
ti,roof-floor - control voltage selection by pin(boolean)
ti,mode-sleep - mode to adopt in pmic sleep 0 - off, 1 - auto,
2 - eco, 3 - forced pwm
ti,smps-range - OTP has the wrong range set for the hardware so override
0 - low range, 1 - high range.
Example:
#include <dt-bindings/interrupt-controller/irq.h>
pmic {
compatible = "ti,twl6035-pmic", "ti,palmas-pmic";
interrupt-parent = <&palmas>;
interrupts = <14 IRQ_TYPE_NONE>;
interrupts-name = "short-irq";
ti,ldo6-vibrator;
regulators {
smps12_reg : smps12 {
regulator-name = "smps12";
regulator-min-microvolt = < 600000>;
regulator-max-microvolt = <1500000>;
regulator-always-on;
regulator-boot-on;
ti,warm-reset;
ti,roof-floor;
ti,mode-sleep = <0>;
ti,smps-range = <1>;
};
ldo1_reg: ldo1 {
regulator-name = "ldo1";
regulator-min-microvolt = <2800000>;
regulator-max-microvolt = <2800000>;
};
};
};

14
Documentation/devicetree/bindings/regulator/s5m8767-regulator.txt
View File

@ -1,6 +1,6 @@
* Samsung S5M8767 Voltage and Current Regulator
The Samsung S5M8767 is a multi-function device which includes volatage and
The Samsung S5M8767 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. This document
@ -103,13 +103,13 @@ Example:
s5m8767,pmic-buck-default-dvs-idx = <0>;
s5m8767,pmic-buck-dvs-gpios = <&gpx0 0 1 0 0>, /* DVS1 */
<&gpx0 1 1 0 0>, /* DVS2 */
<&gpx0 2 1 0 0>; /* DVS3 */
s5m8767,pmic-buck-dvs-gpios = <&gpx0 0 0>, /* DVS1 */
<&gpx0 1 0>, /* DVS2 */
<&gpx0 2 0>; /* DVS3 */
s5m8767,pmic-buck-ds-gpios = <&gpx2 3 1 0 0>, /* SET1 */
<&gpx2 4 1 0 0>, /* SET2 */
<&gpx2 5 1 0 0>; /* SET3 */
s5m8767,pmic-buck-ds-gpios = <&gpx2 3 0>, /* SET1 */
<&gpx2 4 0>, /* SET2 */
<&gpx2 5 0>; /* SET3 */
s5m8767,pmic-buck2-dvs-voltage = <1350000>, <1300000>,
<1250000>, <1200000>,

26
Documentation/devicetree/bindings/regulator/twl-regulator.txt
View File

@ -18,20 +18,20 @@ For twl6030 regulators/LDOs
- "ti,twl6030-vdd1" for VDD1 SMPS
- "ti,twl6030-vdd2" for VDD2 SMPS
- "ti,twl6030-vdd3" for VDD3 SMPS
For twl6025 regulators/LDOs
For twl6032 regulators/LDOs
- compatible:
- "ti,twl6025-ldo1" for LDO1 LDO
- "ti,twl6025-ldo2" for LDO2 LDO
- "ti,twl6025-ldo3" for LDO3 LDO
- "ti,twl6025-ldo4" for LDO4 LDO
- "ti,twl6025-ldo5" for LDO5 LDO
- "ti,twl6025-ldo6" for LDO6 LDO
- "ti,twl6025-ldo7" for LDO7 LDO
- "ti,twl6025-ldoln" for LDOLN LDO
- "ti,twl6025-ldousb" for LDOUSB LDO
- "ti,twl6025-smps3" for SMPS3 SMPS
- "ti,twl6025-smps4" for SMPS4 SMPS
- "ti,twl6025-vio" for VIO SMPS
- "ti,twl6032-ldo1" for LDO1 LDO
- "ti,twl6032-ldo2" for LDO2 LDO
- "ti,twl6032-ldo3" for LDO3 LDO
- "ti,twl6032-ldo4" for LDO4 LDO
- "ti,twl6032-ldo5" for LDO5 LDO
- "ti,twl6032-ldo6" for LDO6 LDO
- "ti,twl6032-ldo7" for LDO7 LDO
- "ti,twl6032-ldoln" for LDOLN LDO
- "ti,twl6032-ldousb" for LDOUSB LDO
- "ti,twl6032-smps3" for SMPS3 SMPS
- "ti,twl6032-smps4" for SMPS4 SMPS
- "ti,twl6032-vio" for VIO SMPS
For twl4030 regulators/LDOs
- compatible:
- "ti,twl4030-vaux1" for VAUX1 LDO

13
Documentation/devicetree/bindings/serio/olpc,ap-sp.txt 100644
View File

@ -0,0 +1,13 @@
OLPC AP-SP serio interface
Required properties:
- compatible : "olpc,ap-sp"
- reg : base address and length of SoC's WTM registers
- interrupts : SP-AP interrupt
Example:
ap-sp@d4290000 {
compatible = "olpc,ap-sp";
reg = <0xd4290000 0x1000>;
interrupts = <40>;
}

2
Documentation/devicetree/bindings/spi/brcm,bcm2835-spi.txt
View File

@ -2,7 +2,7 @@ Broadcom BCM2835 SPI0 controller
The BCM2835 contains two forms of SPI master controller, one known simply as
SPI0, and the other known as the "Universal SPI Master"; part of the
auxilliary block. This binding applies to the SPI0 controller.
auxiliary block. This binding applies to the SPI0 controller.
Required properties:
- compatible: Should be "brcm,bcm2835-spi".

21
drivers/staging/ti-soc-thermal/ti_soc_thermal.txt → Documentation/devicetree/bindings/thermal/ti_soc_thermal.txt
View File

@ -17,8 +17,9 @@ Required properties:
- interrupts : this entry should indicate which interrupt line
the talert signal is routed to;
Specific:
- ti,tshut-gpio : this entry should be used to inform which GPIO
line the tshut signal is routed to;
- gpios : this entry should be used to inform which GPIO
line the tshut signal is routed to. The informed GPIO will
be treated as an IRQ;
- regs : this entry must also be specified and it is specific
to each bandgap version, because the mapping may change from
soc to soc, apart of depending on available features.
@ -37,7 +38,7 @@ bandgap {
0x4a002378 0x18>;
compatible = "ti,omap4460-bandgap";
interrupts = <0 126 4>; /* talert */
ti,tshut-gpio = <86>;
gpios = <&gpio3 22 0>; /* tshut */
};
OMAP4470:
@ -47,7 +48,7 @@ bandgap {
0x4a002378 0x18>;
compatible = "ti,omap4470-bandgap";
interrupts = <0 126 4>; /* talert */
ti,tshut-gpio = <86>;
gpios = <&gpio3 22 0>; /* tshut */
};
OMAP5430:
@ -59,3 +60,15 @@ bandgap {
compatible = "ti,omap5430-bandgap";
interrupts = <0 126 4>; /* talert */
};
DRA752:
bandgap {
reg = <0x4a0021e0 0xc
0x4a00232c 0xc
0x4a002380 0x2c
0x4a0023C0 0x3c
0x4a002564 0x8
0x4a002574 0x50>;
compatible = "ti,dra752-bandgap";
interrupts = <0 126 4>; /* talert */
};

33
Documentation/devicetree/bindings/timer/lsi,zevio-timer.txt 100644
View File

@ -0,0 +1,33 @@
TI-NSPIRE timer
Required properties:
- compatible : should be "lsi,zevio-timer".
- reg : The physical base address and size of the timer (always first).
- clocks: phandle to the source clock.
Optional properties:
- interrupts : The interrupt number of the first timer.
- reg : The interrupt acknowledgement registers
(always after timer base address)
If any of the optional properties are not given, the timer is added as a
clock-source only.
Example:
timer {
compatible = "lsi,zevio-timer";
reg = <0x900D0000 0x1000>, <0x900A0020 0x8>;
interrupts = <19>;
clocks = <&timer_clk>;
};
Example (no clock-events):
timer {
compatible = "lsi,zevio-timer";
reg = <0x900D0000 0x1000>;
clocks = <&timer_clk>;
};

17
Documentation/devicetree/bindings/timer/marvell,orion-timer.txt 100644
View File

@ -0,0 +1,17 @@
Marvell Orion SoC timer
Required properties:
- compatible: shall be "marvell,orion-timer"
- reg: base address of the timer register starting with TIMERS CONTROL register
- interrupt-parent: phandle of the bridge interrupt controller
- interrupts: should contain the interrupts for Timer0 and Timer1
- clocks: phandle of timer reference clock (tclk)
Example:
timer: timer {
compatible = "marvell,orion-timer";
reg = <0x20300 0x20>;
interrupt-parent = <&bridge_intc>;
interrupts = <1>, <2>;
clocks = <&core_clk 0>;
};

2
Documentation/devicetree/bindings/timer/samsung,exynos4210-mct.txt
View File

@ -44,7 +44,7 @@ Example 1: In this example, the system uses only the first global timer
};
Example 2: In this example, the MCT global and local timer interrupts are
connected to two seperate interrupt controllers. Hence, an
connected to two separate interrupt controllers. Hence, an
interrupt-map is created to map the interrupts to the respective
interrupt controllers.

16
Documentation/devicetree/bindings/ufs/ufshcd-pltfrm.txt 100644
View File

@ -0,0 +1,16 @@
* Universal Flash Storage (UFS) Host Controller
UFSHC nodes are defined to describe on-chip UFS host controllers.
Each UFS controller instance should have its own node.
Required properties:
- compatible : compatible list, contains "jedec,ufs-1.1"
- interrupts : <interrupt mapping for UFS host controller IRQ>
- reg : <registers mapping>
Example:
ufshc@0xfc598000 {
compatible = "jedec,ufs-1.1";
reg = <0xfc598000 0x800>;
interrupts = <0 28 0>;
};

2
Documentation/devicetree/bindings/usb/am33xx-usb.txt
View File

@ -12,7 +12,7 @@ AM33XX MUSB GLUE
represents PERIPHERAL.
- port1-mode : Should be "1" to represent HOST. "3" signifies OTG and "2"
represents PERIPHERAL.
- power : Should be "250". This signifies the controller can supply upto
- power : Should be "250". This signifies the controller can supply up to
500mA when operating in host mode.
Example:

2
Documentation/devicetree/bindings/usb/omap-usb.txt
View File

@ -16,7 +16,7 @@ OMAP MUSB GLUE
specifying ULPI and UTMI respectively.
- mode : Should be "3" to represent OTG. "1" signifies HOST and "2"
represents PERIPHERAL.
- power : Should be "50". This signifies the controller can supply upto
- power : Should be "50". This signifies the controller can supply up to
100mA when operating in host mode.
- usb-phy : the phandle for the PHY device

2
Documentation/devicetree/bindings/usb/twlxxxx-usb.txt
View File

@ -8,7 +8,7 @@ TWL6030 USB COMPARATOR
usb interrupt number that raises VBUS interrupts when the controller has to
act as device
- usb-supply : phandle to the regulator device tree node. It should be vusb
if it is twl6030 or ldousb if it is twl6025 subclass.
if it is twl6030 or ldousb if it is twl6032 subclass.
twl6030-usb {
compatible = "ti,twl6030-usb";

4
Documentation/devicetree/bindings/vendor-prefixes.txt
View File

@ -18,6 +18,7 @@ chrp Common Hardware Reference Platform
cirrus Cirrus Logic, Inc.
cortina Cortina Systems, Inc.
dallas Maxim Integrated Products (formerly Dallas Semiconductor)
davicom DAVICOM Semiconductor, Inc.
denx Denx Software Engineering
emmicro EM Microelectronic
epson Seiko Epson Corp.
@ -25,6 +26,7 @@ est ESTeem Wireless Modems
fsl Freescale Semiconductor
GEFanuc GE Fanuc Intelligent Platforms Embedded Systems, Inc.
gef GE Fanuc Intelligent Platforms Embedded Systems, Inc.
hisilicon Hisilicon Limited.
hp Hewlett Packard
ibm International Business Machines (IBM)
idt Integrated Device Technologies, Inc.
@ -42,6 +44,7 @@ nxp NXP Semiconductors
onnn ON Semiconductor Corp.
picochip Picochip Ltd
powervr PowerVR (deprecated, use img)
qca Qualcomm Atheros, Inc.
qcom Qualcomm, Inc.
ralink Mediatek/Ralink Technology Corp.
ramtron Ramtron International
@ -58,6 +61,7 @@ snps Synopsys, Inc.
st STMicroelectronics
ste ST-Ericsson
stericsson ST-Ericsson
toumaz Toumaz
ti Texas Instruments
toshiba Toshiba Corporation
v3 V3 Semiconductor

1
Documentation/devicetree/bindings/video/display-timing.txt
View File

@ -34,6 +34,7 @@ optional properties:
- ignored = ignored
- interlaced (bool): boolean to enable interlaced mode
- doublescan (bool): boolean to enable doublescan mode
- doubleclk (bool): boolean to enable doubleclock mode
All the optional properties that are not bool follow the following logic:
<1>: high active

13
Documentation/devicetree/bindings/video/exynos_hdmi.txt
View File

@ -1,22 +1,23 @@
Device-Tree bindings for drm hdmi driver
Required properties:
- compatible: value should be "samsung,exynos5-hdmi".
- compatible: value should be one among the following:
1) "samsung,exynos5-hdmi" <DEPRECATED>
2) "samsung,exynos4210-hdmi"
3) "samsung,exynos4212-hdmi"
- reg: physical base address of the hdmi and length of memory mapped
region.
- interrupts: interrupt number to the cpu.
- hpd-gpio: following information about the hotplug gpio pin.
a) phandle of the gpio controller node.
b) pin number within the gpio controller.
c) pin function mode.
d) optional flags and pull up/down.
e) drive strength.
c) optional flags and pull up/down.
Example:
hdmi {
compatible = "samsung,exynos5-hdmi";
compatible = "samsung,exynos4212-hdmi";
reg = <0x14530000 0x100000>;
interrupts = <0 95 0>;
hpd-gpio = <&gpx3 7 0xf 1 3>;
hpd-gpio = <&gpx3 7 1>;
};

7
Documentation/devicetree/bindings/video/exynos_hdmiddc.txt
View File

@ -1,12 +1,15 @@
Device-Tree bindings for hdmiddc driver
Required properties:
- compatible: value should be "samsung,exynos5-hdmiddc".
- compatible: value should be one of the following
1) "samsung,exynos5-hdmiddc" <DEPRECATED>
2) "samsung,exynos4210-hdmiddc"
- reg: I2C address of the hdmiddc device.
Example:
hdmiddc {
compatible = "samsung,exynos5-hdmiddc";
compatible = "samsung,exynos4210-hdmiddc";
reg = <0x50>;
};

7
Documentation/devicetree/bindings/video/exynos_hdmiphy.txt
View File

@ -1,12 +1,15 @@
Device-Tree bindings for hdmiphy driver
Required properties:
- compatible: value should be "samsung,exynos5-hdmiphy".
- compatible: value should be one of the following:
1) "samsung,exynos5-hdmiphy" <DEPRECATED>
2) "samsung,exynos4210-hdmiphy".
3) "samsung,exynos4212-hdmiphy".
- reg: I2C address of the hdmiphy device.
Example:
hdmiphy {
compatible = "samsung,exynos5-hdmiphy";
compatible = "samsung,exynos4210-hdmiphy";
reg = <0x38>;
};

9
Documentation/devicetree/bindings/video/exynos_mixer.txt
View File

@ -1,7 +1,12 @@
Device-Tree bindings for mixer driver
Required properties:
- compatible: value should be "samsung,exynos5-mixer".
- compatible: value should be one of the following:
1) "samsung,exynos5-mixer" <DEPRECATED>
2) "samsung,exynos4210-mixer"
3) "samsung,exynos5250-mixer"
4) "samsung,exynos5420-mixer"
- reg: physical base address of the mixer and length of memory mapped
region.
- interrupts: interrupt number to the cpu.
@ -9,7 +14,7 @@ Required properties:
Example:
mixer {
compatible = "samsung,exynos5-mixer";
compatible = "samsung,exynos5250-mixer";
reg = <0x14450000 0x10000>;
interrupts = <0 94 0>;
};

51
Documentation/devicetree/bindings/video/fsl,imx-fb.txt 100644
View File

@ -0,0 +1,51 @@
Freescale imx21 Framebuffer
This framebuffer driver supports devices imx1, imx21, imx25, and imx27.
Required properties:
- compatible : "fsl,<chip>-fb", chip should be imx1 or imx21
- reg : Should contain 1 register ranges(address and length)
- interrupts : One interrupt of the fb dev
Required nodes:
- display: Phandle to a display node as described in
Documentation/devicetree/bindings/video/display-timing.txt
Additional, the display node has to define properties:
- bits-per-pixel: Bits per pixel
- fsl,pcr: LCDC PCR value
Optional properties:
- fsl,dmacr: DMA Control Register value. This is optional. By default, the
register is not modified as recommended by the datasheet.
- fsl,lscr1: LCDC Sharp Configuration Register value.
Example:
imxfb: fb@10021000 {
compatible = "fsl,imx21-fb";
interrupts = <61>;
reg = <0x10021000 0x1000>;
display = <&display0>;
};
...
display0: display0 {
model = "Primeview-PD050VL1";
native-mode = <&timing_disp0>;
bits-per-pixel = <16>;
fsl,pcr = <0xf0c88080>; /* non-standard but required */
display-timings {
timing_disp0: 640x480 {
hactive = <640>;
vactive = <480>;
hback-porch = <112>;
hfront-porch = <36>;
hsync-len = <32>;
vback-porch = <33>;
vfront-porch = <33>;
vsync-len = <2>;
clock-frequency = <25000000>;
};
};
};

10
Documentation/devicetree/bindings/video/ssd1307fb.txt
View File

@ -1,13 +1,17 @@
* Solomon SSD1307 Framebuffer Driver
Required properties:
- compatible: Should be "solomon,ssd1307fb-<bus>". The only supported bus for
now is i2c.
- compatible: Should be "solomon,<chip>fb-<bus>". The only supported bus for
now is i2c, and the supported chips are ssd1306 and ssd1307.
- reg: Should contain address of the controller on the I2C bus. Most likely
0x3c or 0x3d
- pwm: Should contain the pwm to use according to the OF device tree PWM
specification [0]
specification [0]. Only required for the ssd1307.
- reset-gpios: Should contain the GPIO used to reset the OLED display
- solomon,height: Height in pixel of the screen driven by the controller
- solomon,width: Width in pixel of the screen driven by the controller
- solomon,page-offset: Offset of pages (band of 8 pixels) that the screen is
mapped to.
Optional properties:
- reset-active-low: Is the reset gpio is active on physical low?

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