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

Merge branch 'linus' into timers/urgent 

Get upstream changes so we can apply fixes against them

Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
wifi-calibration
Thomas Gleixner 2013-07-12 12:34:42 +02:00
parent e399eb56a6 9903883f1d
commit f2006e2739
5380 changed files with 298178 additions and 96909 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

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

58
Documentation/ABI/testing/sysfs-bus-acpi 100644
View File

@ -0,0 +1,58 @@
What: /sys/bus/acpi/devices/.../path
Date: December 2006
Contact: Rafael J. Wysocki <rjw@rjwysocki.net>
Description:
This attribute indicates the full path of ACPI namespace
object associated with the device object. For example,
\_SB_.PCI0.
This file is not present for device objects representing
fixed ACPI hardware features (like power and sleep
buttons).
What: /sys/bus/acpi/devices/.../modalias
Date: July 2007
Contact: Rafael J. Wysocki <rjw@rjwysocki.net>
Description:
This attribute indicates the PNP IDs of the device object.
That is acpi:HHHHHHHH:[CCCCCCC:]. Where each HHHHHHHH or
CCCCCCCC contains device object's PNPID (_HID or _CID).
What: /sys/bus/acpi/devices/.../hid
Date: April 2005
Contact: Rafael J. Wysocki <rjw@rjwysocki.net>
Description:
This attribute indicates the hardware ID (_HID) of the
device object. For example, PNP0103.
This file is present for device objects having the _HID
control method.
What: /sys/bus/acpi/devices/.../description
Date: October 2012
Contact: Rafael J. Wysocki <rjw@rjwysocki.net>
Description:
This attribute contains the output of the device object's
_STR control method, if present.
What: /sys/bus/acpi/devices/.../adr
Date: October 2012
Contact: Rafael J. Wysocki <rjw@rjwysocki.net>
Description:
This attribute contains the output of the device object's
_ADR control method, which is present for ACPI device
objects representing devices having standard enumeration
algorithms, such as PCI.
What: /sys/bus/acpi/devices/.../uid
Date: October 2012
Contact: Rafael J. Wysocki <rjw@rjwysocki.net>
Description:
This attribute contains the output of the device object's
_UID control method, if present.
What: /sys/bus/acpi/devices/.../eject
Date: December 2006
Contact: Rafael J. Wysocki <rjw@rjwysocki.net>
Description:
Writing 1 to this attribute will trigger hot removal of
this device object. This file exists for every device
object that has _EJ0 method.

20
Documentation/ABI/testing/sysfs-class-devfreq
View File

@ -78,3 +78,23 @@ Contact: Nishanth Menon <nm@ti.com>
Description:
The /sys/class/devfreq/.../available_governors shows
currently available governors in the system.
What: /sys/class/devfreq/.../min_freq
Date: January 2013
Contact: MyungJoo Ham <myungjoo.ham@samsung.com>
Description:
The /sys/class/devfreq/.../min_freq shows and stores
the minimum frequency requested by users. It is 0 if
the user does not care. min_freq overrides the
frequency requested by governors.
What: /sys/class/devfreq/.../max_freq
Date: January 2013
Contact: MyungJoo Ham <myungjoo.ham@samsung.com>
Description:
The /sys/class/devfreq/.../max_freq shows and stores
the maximum frequency requested by users. It is 0 if
the user does not care. max_freq overrides the
frequency requested by governors and min_freq.
The max_freq overrides min_freq because max_freq may be
used to throttle devices to avoid overheating.

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

20
Documentation/ABI/testing/sysfs-devices-online 100644
View File

@ -0,0 +1,20 @@
What: /sys/devices/.../online
Date: April 2013
Contact: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Description:
The /sys/devices/.../online attribute is only present for
devices whose bus types provide .online() and .offline()
callbacks. The number read from it (0 or 1) reflects the value
of the device's 'offline' field. If that number is 1 and '0'
(or 'n', or 'N') is written to this file, the device bus type's
.offline() callback is executed for the device and (if
successful) its 'offline' field is updated accordingly. In
turn, if that number is 0 and '1' (or 'y', or 'Y') is written to
this file, the device bus type's .online() callback is executed
for the device and (if successful) its 'offline' field is
updated as appropriate.
After a successful execution of the bus type's .offline()
callback the device cannot be used for any purpose until either
it is removed (i.e. device_del() is called for it), or its bus
type's .online() is exeucted successfully.

2
Documentation/ABI/testing/sysfs-devices-sun
View File

@ -1,4 +1,4 @@
Whatt: /sys/devices/.../sun
What: /sys/devices/.../sun
Date: October 2012
Contact: Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>
Description:

15
Documentation/ABI/testing/sysfs-devices-system-cpu
View File

@ -144,6 +144,21 @@ Description: Discover and change clock speed of CPUs
to learn how to control the knobs.
What: /sys/devices/system/cpu/cpu#/cpufreq/freqdomain_cpus
Date: June 2013
Contact: cpufreq@vger.kernel.org
Description: Discover CPUs in the same CPU frequency coordination domain
freqdomain_cpus is the list of CPUs (online+offline) that share
the same clock/freq domain (possibly at the hardware level).
That information may be hidden from the cpufreq core and the
value of related_cpus may be different from freqdomain_cpus. This
attribute is useful for user space DVFS controllers to get better
power/performance results for platforms using acpi-cpufreq.
This file is only present if the acpi-cpufreq driver is in use.
What: /sys/devices/system/cpu/cpu*/cache/index3/cache_disable_{0,1}
Date: August 2008
KernelVersion: 2.6.27

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

@ -12,7 +12,7 @@ Description: Make it possible to set/get current led state. Reading from it
What: /sys/bus/hid/drivers/wiimote/<dev>/extension
Date: August 2011
KernelVersion: 3.2
Contact: David Herrmann <dh.herrmann@googlemail.com>
Contact: David Herrmann <dh.herrmann@gmail.com>
Description: This file contains the currently connected and initialized
extensions. It can be one of: none, motionp, nunchuck, classic,
motionp+nunchuck, motionp+classic
@ -20,3 +20,40 @@ Description: This file contains the currently connected and initialized
the official Nintendo Nunchuck extension and classic is the
Nintendo Classic Controller extension. The motionp extension can
be combined with the other two.
Starting with kernel-version 3.11 Motion Plus hotplugging is
supported and if detected, it's no longer reported as static
extension. You will get uevent notifications for the motion-plus
device then.
What: /sys/bus/hid/drivers/wiimote/<dev>/devtype
Date: May 2013
KernelVersion: 3.11
Contact: David Herrmann <dh.herrmann@gmail.com>
Description: While a device is initialized by the wiimote driver, we perform
a device detection and signal a "change" uevent after it is
done. This file shows the detected device type. "pending" means
that the detection is still ongoing, "unknown" means, that the
device couldn't be detected or loaded. "generic" means, that the
device couldn't be detected but supports basic Wii Remote
features and can be used.
Other strings for each device-type are available and may be
added if new device-specific detections are added.
Currently supported are:
gen10: First Wii Remote generation
gen20: Second Wii Remote Plus generation (builtin MP)
balanceboard: Wii Balance Board
What: /sys/bus/hid/drivers/wiimote/<dev>/bboard_calib
Date: May 2013
KernelVersion: 3.11
Contact: David Herrmann <dh.herrmann@gmail.com>
Description: This attribute is only provided if the device was detected as a
balance board. It provides a single line with 3 calibration
values for all 4 sensors. The values are separated by colons and
are each 2 bytes long (encoded as 4 digit hexadecimal value).
First, 0kg values for all 4 sensors are written, followed by the
17kg values for all 4 sensors and last the 34kg values for all 4
sensors.
Calibration data is already applied by the kernel to all input
values but may be used by user-space to perform other
transformations.

10
Documentation/ABI/testing/sysfs-firmware-acpi
View File

@ -44,6 +44,16 @@ Description:
or 0 (unset). Attempts to write any other values to it will
cause -EINVAL to be returned.
What: /sys/firmware/acpi/hotplug/force_remove
Date: May 2013
Contact: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Description:
The number in this file (0 or 1) determines whether (1) or not
(0) the ACPI subsystem will allow devices to be hot-removed even
if they cannot be put offline gracefully (from the kernel's
viewpoint). That number can be changed by writing a boolean
value to this file.
What: /sys/firmware/acpi/interrupts/
Date: February 2008
Contact: Len Brown <lenb@kernel.org>

3
Documentation/CodingStyle
View File

@ -389,7 +389,8 @@ Albeit deprecated by some people, the equivalent of the goto statement is
used frequently by compilers in form of the unconditional jump instruction.
The goto statement comes in handy when a function exits from multiple
locations and some common work such as cleanup has to be done.
locations and some common work such as cleanup has to be done. If there is no
cleanup needed then just return directly.
The rationale is:

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

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

@ -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>
@ -297,10 +299,10 @@ KAO -->
</sect1>
<sect1><title>Frame Buffer Fonts</title>
<para>
Refer to the file drivers/video/console/fonts.c for more information.
Refer to the file lib/fonts/fonts.c for more information.
</para>
<!-- FIXME: Removed for now since no structured comments in source
X!Idrivers/video/console/fonts.c
X!Ilib/fonts/fonts.c
-->
</sect1>
</chapter>

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 -->

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

@ -1955,12 +1955,17 @@ machines due to caching.
</sect1>
</chapter>
<chapter id="apiref">
<chapter id="apiref-mutex">
<title>Mutex API reference</title>
!Iinclude/linux/mutex.h
!Ekernel/mutex.c
</chapter>
<chapter id="apiref-futex">
<title>Futex API reference</title>
!Ikernel/futex.c
</chapter>
<chapter id="references">
<title>Further reading</title>

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>

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

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

4
Documentation/accounting/getdelays.c
View File

@ -272,7 +272,7 @@ int main(int argc, char *argv[])
char *logfile = NULL;
int loop = 0;
int containerset = 0;
char containerpath[1024];
char *containerpath = NULL;
int cfd = 0;
int forking = 0;
sigset_t sigset;
@ -299,7 +299,7 @@ int main(int argc, char *argv[])
break;
case 'C':
containerset = 1;
strncpy(containerpath, optarg, strlen(optarg) + 1);
containerpath = optarg;
break;
case 'w':
logfile = strdup(optarg);

395
Documentation/acpi/namespace.txt 100644
View File

@ -0,0 +1,395 @@
ACPI Device Tree - Representation of ACPI Namespace
Copyright (C) 2013, Intel Corporation
Author: Lv Zheng <lv.zheng@intel.com>
Abstract:
The Linux ACPI subsystem converts ACPI namespace objects into a Linux
device tree under the /sys/devices/LNXSYSTEM:00 and updates it upon
receiving ACPI hotplug notification events. For each device object in this
hierarchy there is a corresponding symbolic link in the
/sys/bus/acpi/devices.
This document illustrates the structure of the ACPI device tree.
Credit:
Thanks for the help from Zhang Rui <rui.zhang@intel.com> and Rafael J.
Wysocki <rafael.j.wysocki@intel.com>.
1. ACPI Definition Blocks
The ACPI firmware sets up RSDP (Root System Description Pointer) in the
system memory address space pointing to the XSDT (Extended System
Description Table). The XSDT always points to the FADT (Fixed ACPI
Description Table) using its first entry, the data within the FADT
includes various fixed-length entries that describe fixed ACPI features
of the hardware. The FADT contains a pointer to the DSDT
(Differentiated System Descripition Table). The XSDT also contains
entries pointing to possibly multiple SSDTs (Secondary System
Description Table).
The DSDT and SSDT data is organized in data structures called definition
blocks that contain definitions of various objects, including ACPI
control methods, encoded in AML (ACPI Machine Language). The data block
of the DSDT along with the contents of SSDTs represents a hierarchical
data structure called the ACPI namespace whose topology reflects the
structure of the underlying hardware platform.
The relationships between ACPI System Definition Tables described above
are illustrated in the following diagram.
+---------+ +-------+ +--------+ +------------------------+
| RSDP | +->| XSDT | +->| FADT | | +-------------------+ |
+---------+ | +-------+ | +--------+ +-|->| DSDT | |
| Pointer | | | Entry |-+ | ...... | | | +-------------------+ |
+---------+ | +-------+ | X_DSDT |--+ | | Definition Blocks | |
| Pointer |-+ | ..... | | ...... | | +-------------------+ |
+---------+ +-------+ +--------+ | +-------------------+ |
| Entry |------------------|->| SSDT | |
+- - - -+ | +-------------------| |
| Entry | - - - - - - - -+ | | Definition Blocks | |
+- - - -+ | | +-------------------+ |
| | +- - - - - - - - - -+ |
+-|->| SSDT | |
| +-------------------+ |
| | Definition Blocks | |
| +- - - - - - - - - -+ |
+------------------------+
|
OSPM Loading |
\|/
+----------------+
| ACPI Namespace |
+----------------+
Figure 1. ACPI Definition Blocks
NOTE: RSDP can also contain a pointer to the RSDT (Root System
Description Table). Platforms provide RSDT to enable
compatibility with ACPI 1.0 operating systems. The OS is expected
to use XSDT, if present.
2. Example ACPI Namespace
All definition blocks are loaded into a single namespace. The namespace
is a hierarchy of objects identified by names and paths.
The following naming conventions apply to object names in the ACPI
namespace:
1. All names are 32 bits long.
2. The first byte of a name must be one of 'A' - 'Z', '_'.
3. Each of the remaining bytes of a name must be one of 'A' - 'Z', '0'
- '9', '_'.
4. Names starting with '_' are reserved by the ACPI specification.
5. The '\' symbol represents the root of the namespace (i.e. names
prepended with '\' are relative to the namespace root).
6. The '^' symbol represents the parent of the current namespace node
(i.e. names prepended with '^' are relative to the parent of the
current namespace node).
The figure below shows an example ACPI namespace.
+------+
| \ | Root
+------+
|
| +------+
+-| _PR | Scope(_PR): the processor namespace
| +------+
| |
| | +------+
| +-| CPU0 | Processor(CPU0): the first processor
| +------+
|
| +------+
+-| _SB | Scope(_SB): the system bus namespace
| +------+
| |
| | +------+
| +-| LID0 | Device(LID0); the lid device
| | +------+
| | |
| | | +------+
| | +-| _HID | Name(_HID, "PNP0C0D"): the hardware ID
| | | +------+
| | |
| | | +------+
| | +-| _STA | Method(_STA): the status control method
| | +------+
| |
| | +------+
| +-| PCI0 | Device(PCI0); the PCI root bridge
| +------+
| |
| | +------+
| +-| _HID | Name(_HID, "PNP0A08"): the hardware ID
| | +------+
| |
| | +------+
| +-| _CID | Name(_CID, "PNP0A03"): the compatible ID
| | +------+
| |
| | +------+
| +-| RP03 | Scope(RP03): the PCI0 power scope
| | +------+
| | |
| | | +------+
| | +-| PXP3 | PowerResource(PXP3): the PCI0 power resource
| | +------+
| |
| | +------+
| +-| GFX0 | Device(GFX0): the graphics adapter
| +------+
| |
| | +------+
| +-| _ADR | Name(_ADR, 0x00020000): the PCI bus address
| | +------+
| |
| | +------+
| +-| DD01 | Device(DD01): the LCD output device
| +------+
| |
| | +------+
| +-| _BCL | Method(_BCL): the backlight control method
| +------+
|
| +------+
+-| _TZ | Scope(_TZ): the thermal zone namespace
| +------+
| |
| | +------+
| +-| FN00 | PowerResource(FN00): the FAN0 power resource
| | +------+
| |
| | +------+
| +-| FAN0 | Device(FAN0): the FAN0 cooling device
| | +------+
| | |
| | | +------+
| | +-| _HID | Name(_HID, "PNP0A0B"): the hardware ID
| | +------+
| |
| | +------+
| +-| TZ00 | ThermalZone(TZ00); the FAN thermal zone
| +------+
|
| +------+
+-| _GPE | Scope(_GPE): the GPE namespace
+------+
Figure 2. Example ACPI Namespace
3. Linux ACPI Device Objects
The Linux kernel's core ACPI subsystem creates struct acpi_device
objects for ACPI namespace objects representing devices, power resources
processors, thermal zones. Those objects are exported to user space via
sysfs as directories in the subtree under /sys/devices/LNXSYSTM:00. The
format of their names is <bus_id:instance>, where 'bus_id' refers to the
ACPI namespace representation of the given object and 'instance' is used
for distinguishing different object of the same 'bus_id' (it is
two-digit decimal representation of an unsigned integer).
The value of 'bus_id' depends on the type of the object whose name it is
part of as listed in the table below.
+---+-----------------+-------+----------+
| | Object/Feature | Table | bus_id |
+---+-----------------+-------+----------+
| N | Root | xSDT | LNXSYSTM |
+---+-----------------+-------+----------+
| N | Device | xSDT | _HID |
+---+-----------------+-------+----------+
| N | Processor | xSDT | LNXCPU |
+---+-----------------+-------+----------+
| N | ThermalZone | xSDT | LNXTHERM |
+---+-----------------+-------+----------+
| N | PowerResource | xSDT | LNXPOWER |
+---+-----------------+-------+----------+
| N | Other Devices | xSDT | device |
+---+-----------------+-------+----------+
| F | PWR_BUTTON | FADT | LNXPWRBN |
+---+-----------------+-------+----------+
| F | SLP_BUTTON | FADT | LNXSLPBN |
+---+-----------------+-------+----------+
| M | Video Extension | xSDT | LNXVIDEO |
+---+-----------------+-------+----------+
| M | ATA Controller | xSDT | LNXIOBAY |
+---+-----------------+-------+----------+
| M | Docking Station | xSDT | LNXDOCK |
+---+-----------------+-------+----------+
Table 1. ACPI Namespace Objects Mapping
The following rules apply when creating struct acpi_device objects on
the basis of the contents of ACPI System Description Tables (as
indicated by the letter in the first column and the notation in the
second column of the table above):
N:
The object's source is an ACPI namespace node (as indicated by the
named object's type in the second column). In that case the object's
directory in sysfs will contain the 'path' attribute whose value is
the full path to the node from the namespace root.
struct acpi_device objects are created for the ACPI namespace nodes
whose _STA control methods return PRESENT or FUNCTIONING. The power
resource nodes or nodes without _STA are assumed to be both PRESENT
and FUNCTIONING.
F:
The struct acpi_device object is created for a fixed hardware
feature (as indicated by the fixed feature flag's name in the second
column), so its sysfs directory will not contain the 'path'
attribute.
M:
The struct acpi_device object is created for an ACPI namespace node
with specific control methods (as indicated by the ACPI defined
device's type in the second column). The 'path' attribute containing
its namespace path will be present in its sysfs directory. For
example, if the _BCL method is present for an ACPI namespace node, a
struct acpi_device object with LNXVIDEO 'bus_id' will be created for
it.
The third column of the above table indicates which ACPI System
Description Tables contain information used for the creation of the
struct acpi_device objects represented by the given row (xSDT means DSDT
or SSDT).
The forth column of the above table indicates the 'bus_id' generation
rule of the struct acpi_device object:
_HID:
_HID in the last column of the table means that the object's bus_id
is derived from the _HID/_CID identification objects present under
the corresponding ACPI namespace node. The object's sysfs directory
will then contain the 'hid' and 'modalias' attributes that can be
used to retrieve the _HID and _CIDs of that object.
LNXxxxxx:
The 'modalias' attribute is also present for struct acpi_device
objects having bus_id of the "LNXxxxxx" form (pseudo devices), in
which cases it contains the bus_id string itself.
device:
'device' in the last column of the table indicates that the object's
bus_id cannot be determined from _HID/_CID of the corresponding
ACPI namespace node, although that object represents a device (for
example, it may be a PCI device with _ADR defined and without _HID
or _CID). In that case the string 'device' will be used as the
object's bus_id.
4. Linux ACPI Physical Device Glue
ACPI device (i.e. struct acpi_device) objects may be linked to other
objects in the Linux' device hierarchy that represent "physical" devices
(for example, devices on the PCI bus). If that happens, it means that
the ACPI device object is a "companion" of a device otherwise
represented in a different way and is used (1) to provide configuration
information on that device which cannot be obtained by other means and
(2) to do specific things to the device with the help of its ACPI
control methods. One ACPI device object may be linked this way to
multiple "physical" devices.
If an ACPI device object is linked to a "physical" device, its sysfs
directory contains the "physical_node" symbolic link to the sysfs
directory of the target device object. In turn, the target device's
sysfs directory will then contain the "firmware_node" symbolic link to
the sysfs directory of the companion ACPI device object.
The linking mechanism relies on device identification provided by the
ACPI namespace. For example, if there's an ACPI namespace object
representing a PCI device (i.e. a device object under an ACPI namespace
object representing a PCI bridge) whose _ADR returns 0x00020000 and the
bus number of the parent PCI bridge is 0, the sysfs directory
representing the struct acpi_device object created for that ACPI
namespace object will contain the 'physical_node' symbolic link to the
/sys/devices/pci0000:00/0000:00:02:0/ sysfs directory of the
corresponding PCI device.
The linking mechanism is generally bus-specific. The core of its
implementation is located in the drivers/acpi/glue.c file, but there are
complementary parts depending on the bus types in question located
elsewhere. For example, the PCI-specific part of it is located in
drivers/pci/pci-acpi.c.
5. Example Linux ACPI Device Tree
The sysfs hierarchy of struct acpi_device objects corresponding to the
example ACPI namespace illustrated in Figure 2 with the addition of
fixed PWR_BUTTON/SLP_BUTTON devices is shown below.
+--------------+---+-----------------+
| LNXSYSTEM:00 | \ | acpi:LNXSYSTEM: |
+--------------+---+-----------------+
|
| +-------------+-----+----------------+
+-| LNXPWRBN:00 | N/A | acpi:LNXPWRBN: |
| +-------------+-----+----------------+
|
| +-------------+-----+----------------+
+-| LNXSLPBN:00 | N/A | acpi:LNXSLPBN: |
| +-------------+-----+----------------+
|
| +-----------+------------+--------------+
+-| LNXCPU:00 | \_PR_.CPU0 | acpi:LNXCPU: |
| +-----------+------------+--------------+
|
| +-------------+-------+----------------+
+-| LNXSYBUS:00 | \_SB_ | acpi:LNXSYBUS: |
| +-------------+-------+----------------+
| |
| | +- - - - - - - +- - - - - - +- - - - - - - -+
| +-| * PNP0C0D:00 | \_SB_.LID0 | acpi:PNP0C0D: |
| | +- - - - - - - +- - - - - - +- - - - - - - -+
| |
| | +------------+------------+-----------------------+
| +-| PNP0A08:00 | \_SB_.PCI0 | acpi:PNP0A08:PNP0A03: |
| +------------+------------+-----------------------+
| |
| | +-----------+-----------------+-----+
| +-| device:00 | \_SB_.PCI0.RP03 | N/A |
| | +-----------+-----------------+-----+
| | |
| | | +-------------+----------------------+----------------+
| | +-| LNXPOWER:00 | \_SB_.PCI0.RP03.PXP3 | acpi:LNXPOWER: |
| | +-------------+----------------------+----------------+
| |
| | +-------------+-----------------+----------------+
| +-| LNXVIDEO:00 | \_SB_.PCI0.GFX0 | acpi:LNXVIDEO: |
| +-------------+-----------------+----------------+
| |
| | +-----------+-----------------+-----+
| +-| device:01 | \_SB_.PCI0.DD01 | N/A |
| +-----------+-----------------+-----+
|
| +-------------+-------+----------------+
+-| LNXSYBUS:01 | \_TZ_ | acpi:LNXSYBUS: |
+-------------+-------+----------------+
|
| +-------------+------------+----------------+
+-| LNXPOWER:0a | \_TZ_.FN00 | acpi:LNXPOWER: |
| +-------------+------------+----------------+
|
| +------------+------------+---------------+
+-| PNP0C0B:00 | \_TZ_.FAN0 | acpi:PNP0C0B: |
| +------------+------------+---------------+
|
| +-------------+------------+----------------+
+-| LNXTHERM:00 | \_TZ_.TZ00 | acpi:LNXTHERM: |
+-------------+------------+----------------+
Figure 3. Example Linux ACPI Device Tree
NOTE: Each node is represented as "object/path/modalias", where:
1. 'object' is the name of the object's directory in sysfs.
2. 'path' is the ACPI namespace path of the corresponding
ACPI namespace object, as returned by the object's 'path'
sysfs attribute.
3. 'modalias' is the value of the object's 'modalias' sysfs
attribute (as described earlier in this document).
NOTE: N/A indicates the device object does not have the 'path' or the
'modalias' attribute.
NOTE: The PNP0C0D device listed above is highlighted (marked by "*")
to indicate it will be created only when its _STA methods return
PRESENT or FUNCTIONING.

106
Documentation/acpi/video_extension.txt 100644
View File

@ -0,0 +1,106 @@
ACPI video extensions
~~~~~~~~~~~~~~~~~~~~~
This driver implement the ACPI Extensions For Display Adapters for
integrated graphics devices on motherboard, as specified in ACPI 2.0
Specification, Appendix B, allowing to perform some basic control like
defining the video POST device, retrieving EDID information or to
setup a video output, etc. Note that this is an ref. implementation
only. It may or may not work for your integrated video device.
The ACPI video driver does 3 things regarding backlight control:
1 Export a sysfs interface for user space to control backlight level
If the ACPI table has a video device, and acpi_backlight=vendor kernel
command line is not present, the driver will register a backlight device
and set the required backlight operation structure for it for the sysfs
interface control. For every registered class device, there will be a
directory named acpi_videoX under /sys/class/backlight.
The backlight sysfs interface has a standard definition here:
Documentation/ABI/stable/sysfs-class-backlight.
And what ACPI video driver does is:
actual_brightness: on read, control method _BQC will be evaluated to
get the brightness level the firmware thinks it is at;
bl_power: not implemented, will set the current brightness instead;
brightness: on write, control method _BCM will run to set the requested
brightness level;
max_brightness: Derived from the _BCL package(see below);
type: firmware
Note that ACPI video backlight driver will always use index for
brightness, actual_brightness and max_brightness. So if we have
the following _BCL package:
Method (_BCL, 0, NotSerialized)
{
Return (Package (0x0C)
{
0x64,
0x32,
0x0A,
0x14,
0x1E,
0x28,
0x32,
0x3C,
0x46,
0x50,
0x5A,
0x64
})
}
The first two levels are for when laptop are on AC or on battery and are
not used by Linux currently. The remaining 10 levels are supported levels
that we can choose from. The applicable index values are from 0 (that
corresponds to the 0x0A brightness value) to 9 (that corresponds to the
0x64 brightness value) inclusive. Each of those index values is regarded
as a "brightness level" indicator. Thus from the user space perspective
the range of available brightness levels is from 0 to 9 (max_brightness)
inclusive.
2 Notify user space about hotkey event
There are generally two cases for hotkey event reporting:
i) For some laptops, when user presses the hotkey, a scancode will be
generated and sent to user space through the input device created by
the keyboard driver as a key type input event, with proper remap, the
following key code will appear to user space:
EV_KEY, KEY_BRIGHTNESSUP
EV_KEY, KEY_BRIGHTNESSDOWN
etc.
For this case, ACPI video driver does not need to do anything(actually,
it doesn't even know this happened).
ii) For some laptops, the press of the hotkey will not generate the
scancode, instead, firmware will notify the video device ACPI node
about the event. The event value is defined in the ACPI spec. ACPI
video driver will generate an key type input event according to the
notify value it received and send the event to user space through the
input device it created:
event keycode
0x86 KEY_BRIGHTNESSUP
0x87 KEY_BRIGHTNESSDOWN
etc.
so this would lead to the same effect as case i) now.
Once user space tool receives this event, it can modify the backlight
level through the sysfs interface.
3 Change backlight level in the kernel
This works for machines covered by case ii) in Section 2. Once the driver
received a notification, it will set the backlight level accordingly. This does
not affect the sending of event to user space, they are always sent to user
space regardless of whether or not the video module controls the backlight level
directly. This behaviour can be controlled through the brightness_switch_enabled
module parameter as documented in kernel-parameters.txt. It is recommended to
disable this behaviour once a GUI environment starts up and wants to have full
control of the backlight level.

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)

7
Documentation/arm64/memory.txt
View File

@ -73,3 +73,10 @@ Translation table lookup with 64KB pages:
| | +--------------------------> [41:29] L2 index (only 38:29 used)
| +-------------------------------> [47:42] L1 index (not used)
+-------------------------------------------------> [63] TTBR0/1
When using KVM, the hypervisor maps kernel pages in EL2, at a fixed
offset from the kernel VA (top 24bits of the kernel VA set to zero):
Start End Size Use
-----------------------------------------------------------------------
0000004000000000 0000007fffffffff 256GB kernel objects mapped in HYP

10
Documentation/bcache.txt
View File

@ -181,7 +181,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.
@ -222,7 +222,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,7 +296,7 @@ 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:
@ -362,7 +362,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
@ -417,7 +417,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

13
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).
@ -834,10 +834,9 @@ Test:
12. TODO
1. Add support for accounting huge pages (as a separate controller)
2. Make per-cgroup scanner reclaim not-shared pages first
3. Teach controller to account for shared-pages
4. Start reclamation in the background when the limit is
1. Make per-cgroup scanner reclaim not-shared pages first
2. Teach controller to account for shared-pages
3. Start reclamation in the background when the limit is
not yet hit but the usage is getting closer
Summary

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
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

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

@ -186,7 +186,7 @@ As most cpufreq processors only allow for being set to a few specific
frequencies, a "frequency table" with some functions might assist in
some work of the processor driver. Such a "frequency table" consists
of an array of struct cpufreq_frequency_table entries, with any value in
"index" you want to use, and the corresponding frequency in
"driver_data" you want to use, and the corresponding frequency in
"frequency". At the end of the table, you need to add a
cpufreq_frequency_table entry with frequency set to CPUFREQ_TABLE_END. And
if you want to skip one entry in the table, set the frequency to
@ -214,10 +214,4 @@ int cpufreq_frequency_table_target(struct cpufreq_policy *policy,
is the corresponding frequency table helper for the ->target
stage. Just pass the values to this function, and the unsigned int
index returns the number of the frequency table entry which contains
the frequency the CPU shall be set to. PLEASE NOTE: This is not the
"index" which is in this cpufreq_table_entry.index, but instead
cpufreq_table[index]. So, the new frequency is
cpufreq_table[index].frequency, and the value you stored into the
frequency table "index" field is
cpufreq_table[index].index.
the frequency the CPU shall be set to.

6
Documentation/cpu-hotplug.txt
View File

@ -370,8 +370,10 @@ A: There is no clear spec defined way from ACPI that can give us that
CPUs in MADT as hotpluggable CPUS. In the case there are no disabled CPUS
we assume 1/2 the number of CPUs currently present can be hotplugged.
Caveat: Today's ACPI MADT can only provide 256 entries since the apicid field
in MADT is only 8 bits.
Caveat: ACPI MADT can only provide 256 entries in systems with only ACPI 2.0c
or earlier ACPI version supported, because the apicid field in MADT is only
8 bits. From ACPI 3.0, this limitation was removed since the apicid field
was extended to 32 bits with x2APIC introduced.
User Space Notification

1
Documentation/crypto/async-tx-api.txt
View File

@ -222,5 +222,4 @@ drivers/dma/: location for offload engine drivers
include/linux/async_tx.h: core header file for the async_tx api
crypto/async_tx/async_tx.c: async_tx interface to dmaengine and common code
crypto/async_tx/async_memcpy.c: copy offload
crypto/async_tx/async_memset.c: memory fill offload
crypto/async_tx/async_xor.c: xor and xor zero sum offload

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.

2
Documentation/device-mapper/dm-raid.txt
View File

@ -222,3 +222,5 @@ Version History
1.4.2 Add RAID10 "far" and "offset" algorithm support.
1.5.0 Add message interface to allow manipulation of the sync_action.
New status (STATUSTYPE_INFO) fields: sync_action and mismatch_cnt.
1.5.1 Add ability to restore transiently failed devices on resume.
1.5.2 'mismatch_cnt' is zero unless [last_]sync_action is "check".

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

3
Documentation/devices.txt
View File

@ -100,8 +100,7 @@ Your cooperation is appreciated.
10 = /dev/aio Asynchronous I/O notification interface
11 = /dev/kmsg Writes to this come out as printk's, reads
export the buffered printk records.
12 = /dev/oldmem Used by crashdump kernels to access
the memory of the kernel that crashed.
12 = /dev/oldmem OBSOLETE - replaced by /proc/vmcore
1 block RAM disk
0 = /dev/ram0 First RAM disk

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

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

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

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

@ -12,6 +12,11 @@ Optional properties:
- calxeda,port-phys: phandle-combophy and lane assignment, which maps each
SATA port to a combophy and a lane within that
combophy
- calxeda,sgpio-gpio: phandle-gpio bank, bit offset, and default on or off,
which indicates that the driver supports SGPIO
indicator lights using the indicated GPIOs
- calxeda,led-order : a u32 array that map port numbers to offsets within the
SGPIO bitstream.
- dma-coherent : Present if dma operations are coherent
Example:

24
Documentation/devicetree/bindings/clock/nspire-clock.txt 100644
View File

@ -0,0 +1,24 @@
TI-NSPIRE Clocks
Required properties:
- compatible: Valid compatible properties include:
"lsi,nspire-cx-ahb-divider" for the AHB divider in the CX model
"lsi,nspire-classic-ahb-divider" for the AHB divider in the older model
"lsi,nspire-cx-clock" for the base clock in the CX model
"lsi,nspire-classic-clock" for the base clock in the older model
- reg: Physical base address of the controller and length of memory mapped
region.
Optional:
- clocks: For the "nspire-*-ahb-divider" compatible clocks, this is the parent
clock where it divides the rate from.
Example:
ahb_clk {
#clock-cells = <0>;
compatible = "lsi,nspire-cx-clock";
reg = <0x900B0000 0x4>;
clocks = <&base_clk>;
};

74
Documentation/devicetree/bindings/clock/rockchip.txt 100644
View File

@ -0,0 +1,74 @@
Device Tree Clock bindings for arch-rockchip
This binding uses the common clock binding[1].
[1] Documentation/devicetree/bindings/clock/clock-bindings.txt
== Gate clocks ==
The gate registers form a continuos block which makes the dt node
structure a matter of taste, as either all gates can be put into
one gate clock spanning all registers or they can be divided into
the 10 individual gates containing 16 clocks each.
The code supports both approaches.
Required properties:
- compatible : "rockchip,rk2928-gate-clk"
- reg : shall be the control register address(es) for the clock.
- #clock-cells : from common clock binding; shall be set to 1
- clock-output-names : the corresponding gate names that the clock controls
- clocks : should contain the parent clock for each individual gate,
therefore the number of clocks elements should match the number of
clock-output-names
Example using multiple gate clocks:
clk_gates0: gate-clk@200000d0 {
compatible = "rockchip,rk2928-gate-clk";
reg = <0x200000d0 0x4>;
clocks = <&dummy>, <&dummy>,
<&dummy>, <&dummy>,
<&dummy>, <&dummy>,
<&dummy>, <&dummy>,
<&dummy>, <&dummy>,
<&dummy>, <&dummy>,
<&dummy>, <&dummy>,
<&dummy>, <&dummy>;
clock-output-names =
"gate_core_periph", "gate_cpu_gpll",
"gate_ddrphy", "gate_aclk_cpu",
"gate_hclk_cpu", "gate_pclk_cpu",
"gate_atclk_cpu", "gate_i2s0",
"gate_i2s0_frac", "gate_i2s1",
"gate_i2s1_frac", "gate_i2s2",
"gate_i2s2_frac", "gate_spdif",
"gate_spdif_frac", "gate_testclk";
#clock-cells = <1>;
};
clk_gates1: gate-clk@200000d4 {
compatible = "rockchip,rk2928-gate-clk";
reg = <0x200000d4 0x4>;
clocks = <&xin24m>, <&xin24m>,
<&xin24m>, <&dummy>,
<&dummy>, <&xin24m>,
<&xin24m>, <&dummy>,
<&xin24m>, <&dummy>,
<&xin24m>, <&dummy>,
<&xin24m>, <&dummy>,
<&xin24m>, <&dummy>;
clock-output-names =
"gate_timer0", "gate_timer1",
"gate_timer2", "gate_jtag",
"gate_aclk_lcdc1_src", "gate_otgphy0",
"gate_otgphy1", "gate_ddr_gpll",
"gate_uart0", "gate_frac_uart0",
"gate_uart1", "gate_frac_uart1",
"gate_uart2", "gate_frac_uart2",
"gate_uart3", "gate_frac_uart3";
#clock-cells = <1>;
};

7
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].
@ -44,6 +44,11 @@ Optional child node properties:
- silabs,multisynth-source: source pll A(0) or B(1) of corresponding multisynth
divider.
- silabs,pll-master: boolean, multisynth can change pll frequency.
- silabs,disable-state : clock output disable state, shall be
0 = clock output is driven LOW when disabled
1 = clock output is driven HIGH when disabled
2 = clock output is FLOATING (HIGH-Z) when disabled
3 = clock output is NEVER disabled
==Example==

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

@ -12,22 +12,30 @@ Required properties:
"allwinner,sun4i-axi-clk" - for the AXI clock
"allwinner,sun4i-axi-gates-clk" - for the AXI gates
"allwinner,sun4i-ahb-clk" - for the AHB clock
"allwinner,sun4i-ahb-gates-clk" - for the AHB gates
"allwinner,sun4i-ahb-gates-clk" - for the AHB gates on A10
"allwinner,sun5i-a13-ahb-gates-clk" - for the AHB gates on A13
"allwinner,sun4i-apb0-clk" - for the APB0 clock
"allwinner,sun4i-apb0-gates-clk" - for the APB0 gates
"allwinner,sun4i-apb0-gates-clk" - for the APB0 gates on A10
"allwinner,sun5i-a13-apb0-gates-clk" - for the APB0 gates on A13
"allwinner,sun4i-apb1-clk" - for the APB1 clock
"allwinner,sun4i-apb1-mux-clk" - for the APB1 clock muxing
"allwinner,sun4i-apb1-gates-clk" - for the APB1 gates
"allwinner,sun4i-apb1-gates-clk" - for the APB1 gates on A10
"allwinner,sun5i-a13-apb1-gates-clk" - for the APB1 gates on A13
Required properties for all clocks:
- reg : shall be the control register address for the clock.
- clocks : shall be the input parent clock(s) phandle for the clock
- #clock-cells : from common clock binding; shall be set to 0 except for
"allwinner,sun4i-*-gates-clk" where it shall be set to 1
"allwinner,*-gates-clk" where it shall be set to 1
Additionally, "allwinner,sun4i-*-gates-clk" clocks require:
Additionally, "allwinner,*-gates-clk" clocks require:
- clock-output-names : the corresponding gate names that the clock controls
Clock consumers should specify the desired clocks they use with a
"clocks" phandle cell. Consumers that are using a gated clock should
provide an additional ID in their clock property. The values of this
ID are documented in sunxi/<soc>-gates.txt.
For example:
osc24M: osc24M@01c20050 {
@ -50,102 +58,3 @@ cpu: cpu@01c20054 {
reg = <0x01c20054 0x4>;
clocks = <&osc32k>, <&osc24M>, <&pll1>;
};
Gate clock outputs
The "allwinner,sun4i-*-gates-clk" clocks provide several gatable outputs;
their corresponding offsets as present on sun4i are listed below. Note that
some of these gates are not present on sun5i.
* AXI gates ("allwinner,sun4i-axi-gates-clk")
DRAM 0
* AHB gates ("allwinner,sun4i-ahb-gates-clk")
USB0 0
EHCI0 1
OHCI0 2*
EHCI1 3
OHCI1 4*
SS 5
DMA 6
BIST 7
MMC0 8
MMC1 9
MMC2 10
MMC3 11
MS 12**
NAND 13
SDRAM 14
ACE 16
EMAC 17
TS 18
SPI0 20
SPI1 21
SPI2 22
SPI3 23
PATA 24
SATA 25**
GPS 26*
VE 32
TVD 33
TVE0 34
TVE1 35
LCD0 36
LCD1 37
CSI0 40
CSI1 41
HDMI 43
DE_BE0 44
DE_BE1 45
DE_FE0 46
DE_FE1 47
MP 50
MALI400 52
* APB0 gates ("allwinner,sun4i-apb0-gates-clk")
CODEC 0
SPDIF 1*
AC97 2
IIS 3
PIO 5
IR0 6
IR1 7
KEYPAD 10
* APB1 gates ("allwinner,sun4i-apb1-gates-clk")
I2C0 0
I2C1 1
I2C2 2
CAN 4
SCR 5
PS20 6
PS21 7
UART0 16
UART1 17
UART2 18
UART3 19
UART4 20
UART5 21
UART6 22
UART7 23
Notation:
[*]: The datasheet didn't mention these, but they are present on AW code
[**]: The datasheet had this marked as "NC" but they are used on AW code

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

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

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

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

2
Documentation/devicetree/bindings/clock/vt8500.txt
View File

@ -8,6 +8,8 @@ Required properties:
- compatible : shall be one of the following:
"via,vt8500-pll-clock" - for a VT8500/WM8505 PLL clock
"wm,wm8650-pll-clock" - for a WM8650 PLL clock
"wm,wm8750-pll-clock" - for a WM8750 PLL clock
"wm,wm8850-pll-clock" - for a WM8850 PLL clock
"via,vt8500-device-clock" - for a VT/WM device clock
Required properties for PLL clocks:

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 {

48
Documentation/devicetree/bindings/gpio/gpio-xilinx.txt 100644
View File

@ -0,0 +1,48 @@
Xilinx plb/axi GPIO controller
Dual channel GPIO controller with configurable number of pins
(from 1 to 32 per channel). Every pin can be configured as
input/output/tristate. Both channels share the same global IRQ but
local interrupts can be enabled on channel basis.
Required properties:
- compatible : Should be "xlnx,xps-gpio-1.00.a"
- reg : Address and length of the register set for the device
- #gpio-cells : Should be two. The first cell is the pin number and the
second cell is used to specify optional parameters (currently unused).
- gpio-controller : Marks the device node as a GPIO controller.
Optional properties:
- interrupts : Interrupt mapping for GPIO IRQ.
- interrupt-parent : Phandle for the interrupt controller that
services interrupts for this device.
- xlnx,all-inputs : if n-th bit is setup, GPIO-n is input
- xlnx,dout-default : if n-th bit is 1, GPIO-n default value is 1
- xlnx,gpio-width : gpio width
- xlnx,tri-default : if n-th bit is 1, GPIO-n is in tristate mode
- xlnx,is-dual : if 1, controller also uses the second channel
- xlnx,all-inputs-2 : as above but for the second channel
- xlnx,dout-default-2 : as above but the second channel
- xlnx,gpio2-width : as above but for the second channel
- xlnx,tri-default-2 : as above but for the second channel
Example:
gpio: gpio@40000000 {
#gpio-cells = <2>;
compatible = "xlnx,xps-gpio-1.00.a";
gpio-controller ;
interrupt-parent = <&microblaze_0_intc>;
interrupts = < 6 2 >;
reg = < 0x40000000 0x10000 >;
xlnx,all-inputs = <0x0>;
xlnx,all-inputs-2 = <0x0>;
xlnx,dout-default = <0x0>;
xlnx,dout-default-2 = <0x0>;
xlnx,gpio-width = <0x2>;
xlnx,gpio2-width = <0x2>;
xlnx,interrupt-present = <0x1>;
xlnx,is-dual = <0x1>;
xlnx,tri-default = <0xffffffff>;
xlnx,tri-default-2 = <0xffffffff>;
} ;

47
Documentation/devicetree/bindings/hwmon/g762.txt 100644
View File

@ -0,0 +1,47 @@
GMT G762/G763 PWM Fan controller
Required node properties:
- "compatible": must be either "gmt,g762" or "gmt,g763"
- "reg": I2C bus address of the device
- "clocks": a fixed clock providing input clock frequency
on CLK pin of the chip.
Optional properties:
- "fan_startv": fan startup voltage. Accepted values are 0, 1, 2 and 3.
The higher the more.
- "pwm_polarity": pwm polarity. Accepted values are 0 (positive duty)
and 1 (negative duty).
- "fan_gear_mode": fan gear mode. Supported values are 0, 1 and 2.
If an optional property is not set in .dts file, then current value is kept
unmodified (e.g. u-boot installed value).
Additional information on operational parameters for the device is available
in Documentation/hwmon/g762. A detailed datasheet for the device is available
at http://natisbad.org/NAS/refs/GMT_EDS-762_763-080710-0.2.pdf.
Example g762 node:
clocks {
#address-cells = <1>;
#size-cells = <0>;
g762_clk: fixedclk {
compatible = "fixed-clock";
#clock-cells = <0>;
clock-frequency = <8192>;
}
}
g762: g762@3e {
compatible = "gmt,g762";
reg = <0x3e>;
clocks = <&g762_clk>
fan_gear_mode = <0>; /* chip default */
fan_startv = <1>; /* chip default */
pwm_polarity = <0>; /* chip default */
};

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>;
};

22
Documentation/devicetree/bindings/i2c/ina2xx.txt 100644
View File

@ -0,0 +1,22 @@
ina2xx properties
Required properties:
- compatible: Must be one of the following:
- "ti,ina219" for ina219
- "ti,ina220" for ina220
- "ti,ina226" for ina226
- "ti,ina230" for ina230
- reg: I2C address
Optional properties:
- shunt-resistor
Shunt resistor value in micro-Ohm
Example:
ina220@44 {
compatible = "ti,ina220";
reg = <0x44>;
shunt-resistor = <1000>;
};

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>;
};

147
Documentation/devicetree/bindings/leds/leds-lp55xx.txt 100644
View File

@ -0,0 +1,147 @@
Binding for TI/National Semiconductor LP55xx Led Drivers
Required properties:
- compatible: "national,lp5521" or "national,lp5523" or "ti,lp5562"
- reg: I2C slave address
- clock-mode: Input clock mode, (0: automode, 1: internal, 2: external)
Each child has own specific current settings
- led-cur: Current setting at each led channel (mA x10, 0 if led is not connected)
- max-cur: Maximun current at each led channel.
Optional properties:
- label: Used for naming LEDs
Alternatively, each child can have specific channel name
- chan-name: Name of each channel name
example 1) LP5521
3 LED channels, external clock used. Channel names are 'lp5521_pri:channel0',
'lp5521_pri:channel1' and 'lp5521_pri:channel2'
lp5521@32 {
compatible = "national,lp5521";
reg = <0x32>;
label = "lp5521_pri";
clock-mode = /bits/ 8 <2>;
chan0 {
led-cur = /bits/ 8 <0x2f>;
max-cur = /bits/ 8 <0x5f>;
};
chan1 {
led-cur = /bits/ 8 <0x2f>;
max-cur = /bits/ 8 <0x5f>;
};
chan2 {
led-cur = /bits/ 8 <0x2f>;
max-cur = /bits/ 8 <0x5f>;
};
};
example 2) LP5523
9 LED channels with specific name. Internal clock used.
The I2C slave address is configurable with ASEL1 and ASEL0 pins.
Available addresses are 32/33/34/35h.
ASEL1 ASEL0 Address
-------------------------
GND GND 32h
GND VEN 33h
VEN GND 34h
VEN VEN 35h
lp5523@32 {
compatible = "national,lp5523";
reg = <0x32>;
clock-mode = /bits/ 8 <1>;
chan0 {
chan-name = "d1";
led-cur = /bits/ 8 <0x14>;
max-cur = /bits/ 8 <0x20>;
};
chan1 {
chan-name = "d2";
led-cur = /bits/ 8 <0x14>;
max-cur = /bits/ 8 <0x20>;
};
chan2 {
chan-name = "d3";
led-cur = /bits/ 8 <0x14>;
max-cur = /bits/ 8 <0x20>;
};
chan3 {
chan-name = "d4";
led-cur = /bits/ 8 <0x14>;
max-cur = /bits/ 8 <0x20>;
};
chan4 {
chan-name = "d5";
led-cur = /bits/ 8 <0x14>;
max-cur = /bits/ 8 <0x20>;
};
chan5 {
chan-name = "d6";
led-cur = /bits/ 8 <0x14>;
max-cur = /bits/ 8 <0x20>;
};
chan6 {
chan-name = "d7";
led-cur = /bits/ 8 <0x14>;
max-cur = /bits/ 8 <0x20>;
};
chan7 {
chan-name = "d8";
led-cur = /bits/ 8 <0x14>;
max-cur = /bits/ 8 <0x20>;
};
chan8 {
chan-name = "d9";
led-cur = /bits/ 8 <0x14>;
max-cur = /bits/ 8 <0x20>;
};
};
example 3) LP5562
4 channels are defined.
lp5562@30 {
compatible = "ti,lp5562";
reg = <0x30>;
clock-mode = /bits/8 <2>;
chan0 {
chan-name = "R";
led-cur = /bits/ 8 <0x20>;
max-cur = /bits/ 8 <0x60>;
};
chan1 {
chan-name = "G";
led-cur = /bits/ 8 <0x20>;
max-cur = /bits/ 8 <0x60>;
};
chan2 {
chan-name = "B";
led-cur = /bits/ 8 <0x20>;
max-cur = /bits/ 8 <0x60>;
};
chan3 {
chan-name = "W";
led-cur = /bits/ 8 <0x20>;
max-cur = /bits/ 8 <0x60>;
};
};

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";
};

62
Documentation/devicetree/bindings/mfd/arizona.txt 100644
View File

@ -0,0 +1,62 @@
Wolfson Arizona class audio SoCs
These devices are audio SoCs with extensive digital capabilites and a range
of analogue I/O.
Required properties:
- compatible : one of the following chip-specific strings:
"wlf,wm5102"
"wlf,wm5110"
- reg : I2C slave address when connected using I2C, chip select number when
using SPI.
- interrupts : The interrupt line the /IRQ signal for the device is
connected to.
- interrupt-controller : Arizona class devices contain interrupt controllers
and may provide interrupt services to other devices.
- interrupt-parent : The parent interrupt controller.
- #interrupt-cells: the number of cells to describe an IRQ, this should be 2.
The first cell is the IRQ number.
The second cell is the flags, encoded as the trigger masks from
Documentation/devicetree/bindings/interrupts.txt
- gpio-controller : Indicates this device is a GPIO controller.
- #gpio-cells : Must be 2. The first cell is the pin number and the
second cell is used to specify optional parameters (currently unused).
- AVDD1-supply, DBVDD1-supply, DBVDD2-supply, DBVDD3-supply, CPVDD-supply,
SPKVDDL-supply, SPKVDDR-supply : power supplies for the device, as covered
in Documentation/devicetree/bindings/regulator/regulator.txt
Optional properties:
- wlf,reset : GPIO specifier for the GPIO controlling /RESET
- wlf,ldoena : GPIO specifier for the GPIO controlling LDOENA
- wlf,gpio-defaults : A list of GPIO configuration register values. If
absent, no configuration of these registers is performed. If any
entry has a value that is out of range for a 16 bit register then
the chip default will be used. If present exactly five values must
be specified.
Example:
codec: wm5102@1a {
compatible = "wlf,wm5102";
reg = <0x1a>;
interrupts = <347>;
#interrupt-cells = <2>;
interrupt-parent = <&gic>;
gpio-controller;
#gpio-cells = <2>;
wlf,gpio-defaults = <
0x00000000, /* AIF1TXLRCLK */
0xffffffff,
0xffffffff,
0xffffffff,
0xffffffff,
>;
};

55
Documentation/devicetree/bindings/mfd/max77693.txt 100644
View File

@ -0,0 +1,55 @@
Maxim MAX77693 multi-function device
MAX77693 is a Multifunction device with the following submodules:
- PMIC,
- CHARGER,
- LED,
- MUIC,
- HAPTIC
It is interfaced to host controller using i2c.
This document describes the bindings for the mfd device.
Required properties:
- compatible : Must be "maxim,max77693".
- reg : Specifies the i2c slave address of PMIC block.
- interrupts : This i2c device has an IRQ line connected to the main SoC.
- interrupt-parent : The parent interrupt controller.
Optional properties:
- regulators : The regulators of max77693 have to be instantiated under subnod
named "regulators" using the following format.
regulators {
regualtor-compatible = ESAFEOUT1/ESAFEOUT2/CHARGER
standard regulator constratints[*].
};
[*] refer Documentation/devicetree/bindings/regulator/regulator.txt
Example:
max77693@66 {
compatible = "maxim,max77693";
reg = <0x66>;
interrupt-parent = <&gpx1>;
interrupts = <5 2>;
regulators {
esafeout@1 {
regulator-compatible = "ESAFEOUT1";
regulator-name = "ESAFEOUT1";
regulator-boot-on;
};
esafeout@2 {
regulator-compatible = "ESAFEOUT2";
regulator-name = "ESAFEOUT2";
};
charger@0 {
regulator-compatible = "CHARGER";
regulator-name = "CHARGER";
regulator-min-microamp = <60000>;
regulator-max-microamp = <2580000>;
regulator-boot-on;
};
};
};

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;
};

41
Documentation/devicetree/bindings/pinctrl/fsl,vf610-pinctrl.txt 100644
View File

@ -0,0 +1,41 @@
Freescale Vybrid VF610 IOMUX Controller
Please refer to fsl,imx-pinctrl.txt in this directory for common binding part
and usage.
Required properties:
- compatible: "fsl,vf610-iomuxc"
- fsl,pins: two integers array, represents a group of pins mux and config
setting. The format is fsl,pins = <PIN_FUNC_ID CONFIG>, PIN_FUNC_ID is
a pin working on a specific function, CONFIG is the pad setting value
such as pull-up, speed, ode for this pin. Please refer to Vybrid VF610
datasheet for the valid pad config settings.
CONFIG bits definition:
PAD_CTL_SPEED_LOW (1 << 12)
PAD_CTL_SPEED_MED (2 << 12)
PAD_CTL_SPEED_HIGH (3 << 12)
PAD_CTL_SRE_FAST (1 << 11)
PAD_CTL_SRE_SLOW (0 << 11)
PAD_CTL_ODE (1 << 10)
PAD_CTL_HYS (1 << 9)
PAD_CTL_DSE_DISABLE (0 << 6)
PAD_CTL_DSE_150ohm (1 << 6)
PAD_CTL_DSE_75ohm (2 << 6)
PAD_CTL_DSE_50ohm (3 << 6)
PAD_CTL_DSE_37ohm (4 << 6)
PAD_CTL_DSE_30ohm (5 << 6)
PAD_CTL_DSE_25ohm (6 << 6)
PAD_CTL_DSE_20ohm (7 << 6)
PAD_CTL_PUS_100K_DOWN (0 << 4)
PAD_CTL_PUS_47K_UP (1 << 4)
PAD_CTL_PUS_100K_UP (2 << 4)
PAD_CTL_PUS_22K_UP (3 << 4)
PAD_CTL_PKE (1 << 3)
PAD_CTL_PUE (1 << 2)
PAD_CTL_OBE_ENABLE (1 << 1)
PAD_CTL_IBE_ENABLE (1 << 0)
PAD_CTL_OBE_IBE_ENABLE (3 << 0)
Please refer to vf610-pinfunc.h in device tree source folder
for all available PIN_FUNC_ID for Vybrid VF610.

127
Documentation/devicetree/bindings/pinctrl/img,tz1090-pdc-pinctrl.txt 100644
View File

@ -0,0 +1,127 @@
ImgTec TZ1090 PDC pin controller
Required properties:
- compatible: "img,tz1090-pdc-pinctrl"
- reg: Should contain the register physical address and length of the
SOC_GPIO_CONTROL registers in the PDC register region.
Please refer to pinctrl-bindings.txt in this directory for details of the
common pinctrl bindings used by client devices, including the meaning of the
phrase "pin configuration node".
TZ1090-PDC's pin configuration nodes act as a container for an abitrary number
of subnodes. Each of these subnodes represents some desired configuration for a
pin, a group, or a list of pins or groups. This configuration can include the
mux function to select on those pin(s)/group(s), and various pin configuration
parameters, such as pull-up, drive strength, etc.
The name of each subnode is not important; all subnodes should be enumerated
and processed purely based on their content.
Each subnode only affects those parameters that are explicitly listed. In
other words, a subnode that lists a mux function but no pin configuration
parameters implies no information about any pin configuration parameters.
Similarly, a pin subnode that describes a pullup parameter implies no
information about e.g. the mux function. For this reason, even seemingly boolean
values are actually tristates in this binding: unspecified, off, or on.
Unspecified is represented as an absent property, and off/on are represented as
integer values 0 and 1.
Required subnode-properties:
- tz1090,pins : An array of strings. Each string contains the name of a pin or
group. Valid values for these names are listed below.
Optional subnode-properties:
- tz1090,function: A string containing the name of the function to mux to the
pin or group. Valid values for function names are listed below, including
which pingroups can be muxed to them.
- supported generic pinconfig properties (for further details see
Documentation/devicetree/bindings/pinctrl/pinctrl-bindings.txt):
- bias-disable
- bias-high-impedance
- bias-bus-hold
- bias-pull-up
- bias-pull-down
- input-schmitt-enable
- input-schmitt-disable
- drive-strength: Integer, control drive strength of pins in mA.
2: 2mA
4: 4mA
8: 8mA
12: 12mA
- low-power-enable: Flag, power-on-start weak pull-down for invalid power.
- low-power-disable: Flag, power-on-start weak pull-down disabled.
Note that many of these properties are only valid for certain specific pins
or groups. See the TZ1090 TRM for complete details regarding which groups
support which functionality. The Linux pinctrl driver may also be a useful
reference.
Valid values for pin and group names are:
pins:
These all support bias-high-impediance, bias-pull-up, bias-pull-down, and
bias-bus-hold (which can also be provided to any of the groups below to set
it for all gpio pins in that group).
gpio0, gpio1, sys_wake0, sys_wake1, sys_wake2, ir_data, ext_power.
mux groups:
These all support function.
gpio0
pins: gpio0.
function: ir_mod_stable_out.
gpio1
pins: gpio1.
function: ir_mod_power_out.
drive groups:
These support input-schmitt-enable, input-schmitt-disable,
drive-strength, low-power-enable, and low-power-disable.
pdc
pins: gpio0, gpio1, sys_wake0, sys_wake1, sys_wake2, ir_data,
ext_power.
Example:
pinctrl_pdc: pinctrl@02006500 {
#gpio-range-cells = <3>;
compatible = "img,tz1090-pdc-pinctrl";
reg = <0x02006500 0x100>;
};
Example board file extracts:
&pinctrl_pdc {
pinctrl-names = "default";
pinctrl-0 = <&syswake_default>;
syswake_default: syswakes {
syswake_cfg {
tz1090,pins = "sys_wake0",
"sys_wake1",
"sys_wake2";
pull-up;
};
};
irmod_default: irmod {
gpio0_cfg {
tz1090,pins = "gpio0";
tz1090,function = "ir_mod_stable_out";
};
gpio1_cfg {
tz1090,pins = "gpio1";
tz1090,function = "ir_mod_power_out";
};
};
};
ir: ir@02006200 {
pinctrl-names = "default";
pinctrl-0 = <&irmod_default>;
};

227
Documentation/devicetree/bindings/pinctrl/img,tz1090-pinctrl.txt 100644
View File

@ -0,0 +1,227 @@
ImgTec TZ1090 pin controller
Required properties:
- compatible: "img,tz1090-pinctrl"
- reg: Should contain the register physical address and length of the pad
configuration registers (CR_PADS_* and CR_IF_CTL0).
Please refer to pinctrl-bindings.txt in this directory for details of the
common pinctrl bindings used by client devices, including the meaning of the
phrase "pin configuration node".
TZ1090's pin configuration nodes act as a container for an abitrary number of
subnodes. Each of these subnodes represents some desired configuration for a
pin, a group, or a list of pins or groups. This configuration can include the
mux function to select on those pin(s)/group(s), and various pin configuration
parameters, such as pull-up, drive strength, etc.
The name of each subnode is not important; all subnodes should be enumerated
and processed purely based on their content.
Each subnode only affects those parameters that are explicitly listed. In
other words, a subnode that lists a mux function but no pin configuration
parameters implies no information about any pin configuration parameters.
Similarly, a pin subnode that describes a pullup parameter implies no
information about e.g. the mux function. For this reason, even seemingly boolean
values are actually tristates in this binding: unspecified, off, or on.
Unspecified is represented as an absent property, and off/on are represented as
integer values 0 and 1.
Required subnode-properties:
- tz1090,pins : An array of strings. Each string contains the name of a pin or
group. Valid values for these names are listed below.
Optional subnode-properties:
- tz1090,function: A string containing the name of the function to mux to the
pin or group. Valid values for function names are listed below, including
which pingroups can be muxed to them.
- supported generic pinconfig properties (for further details see
Documentation/devicetree/bindings/pinctrl/pinctrl-bindings.txt):
- bias-disable
- bias-high-impedance
- bias-bus-hold
- bias-pull-up
- bias-pull-down
- input-schmitt-enable
- input-schmitt-disable
- drive-strength: Integer, control drive strength of pins in mA.
2: 2mA
4: 4mA
8: 8mA
12: 12mA
Note that many of these properties are only valid for certain specific pins
or groups. See the TZ1090 TRM for complete details regarding which groups
support which functionality. The Linux pinctrl driver may also be a useful
reference.
Valid values for pin and group names are:
gpio pins:
These all support bias-high-impediance, bias-pull-up, bias-pull-down, and
bias-bus-hold (which can also be provided to any of the groups below to set
it for all pins in that group).
They also all support the some form of muxing. Any pins which are contained
in one of the mux groups (see below) can be muxed only to the functions
supported by the mux group. All other pins can be muxed to the "perip"
function which which enables them with their intended peripheral.
Different pins in the same mux group cannot be muxed to different functions,
however it is possible to mux only a subset of the pins in a mux group to a
particular function and leave the remaining pins unmuxed. This is useful if
the board connects certain pins in a group to other devices to be controlled
by GPIO, and you don't want the usual peripheral to have any control of the
pin.
ant_sel0, ant_sel1, gain0, gain1, gain2, gain3, gain4, gain5, gain6, gain7,
i2s_bclk_out, i2s_din, i2s_dout0, i2s_dout1, i2s_dout2, i2s_lrclk_out,
i2s_mclk, pa_on, pdm_a, pdm_b, pdm_c, pdm_d, pll_on, rx_hp, rx_on,
scb0_sclk, scb0_sdat, scb1_sclk, scb1_sdat, scb2_sclk, scb2_sdat, sdh_cd,
sdh_clk_in, sdh_wp, sdio_clk, sdio_cmd, sdio_d0, sdio_d1, sdio_d2, sdio_d3,
spi0_cs0, spi0_cs1, spi0_cs2, spi0_din, spi0_dout, spi0_mclk, spi1_cs0,
spi1_cs1, spi1_cs2, spi1_din, spi1_dout, spi1_mclk, tft_blank_ls, tft_blue0,
tft_blue1, tft_blue2, tft_blue3, tft_blue4, tft_blue5, tft_blue6, tft_blue7,
tft_green0, tft_green1, tft_green2, tft_green3, tft_green4, tft_green5,
tft_green6, tft_green7, tft_hsync_nr, tft_panelclk, tft_pwrsave, tft_red0,
tft_red1, tft_red2, tft_red3, tft_red4, tft_red5, tft_red6, tft_red7,
tft_vd12acb, tft_vdden_gd, tft_vsync_ns, tx_on, uart0_cts, uart0_rts,
uart0_rxd, uart0_txd, uart1_rxd, uart1_txd.
bias-high-impediance: supported.
bias-pull-up: supported.
bias-pull-down: supported.
bias-bus-hold: supported.
function: perip or those supported by pin's mux group.
other pins:
These other pins are part of various pin groups below, but can't be
controlled as GPIOs. They do however support bias-high-impediance,
bias-pull-up, bias-pull-down, and bias-bus-hold (which can also be provided
to any of the groups below to set it for all pins in that group).
clk_out0, clk_out1, tck, tdi, tdo, tms, trst.
bias-high-impediance: supported.
bias-pull-up: supported.
bias-pull-down: supported.
bias-bus-hold: supported.
mux groups:
These all support function, and some support drive configs.
afe
pins: tx_on, rx_on, pll_on, pa_on, rx_hp, ant_sel0,
ant_sel1, gain0, gain1, gain2, gain3, gain4,
gain5, gain6, gain7.
function: afe, ts_out_0.
input-schmitt-enable: supported.
input-schmitt-disable: supported.
drive-strength: supported.
pdm_d
pins: pdm_d.
function: pdm_dac, usb_vbus.
sdh
pins: sdh_cd, sdh_wp, sdh_clk_in.
function: sdh, sdio.
sdio
pins: sdio_clk, sdio_cmd, sdio_d0, sdio_d1, sdio_d2,
sdio_d3.
function: sdio, sdh.
spi1_cs2
pins: spi1_cs2.
function: spi1_cs2, usb_vbus.
tft
pins: tft_red0, tft_red1, tft_red2, tft_red3,
tft_red4, tft_red5, tft_red6, tft_red7,
tft_green0, tft_green1, tft_green2, tft_green3,
tft_green4, tft_green5, tft_green6, tft_green7,
tft_blue0, tft_blue1, tft_blue2, tft_blue3,
tft_blue4, tft_blue5, tft_blue6, tft_blue7,
tft_vdden_gd, tft_panelclk, tft_blank_ls,
tft_vsync_ns, tft_hsync_nr, tft_vd12acb,
tft_pwrsave.
function: tft, ext_dac, not_iqadc_stb, iqdac_stb, ts_out_1,
lcd_trace, phy_ringosc.
input-schmitt-enable: supported.
input-schmitt-disable: supported.
drive-strength: supported.
drive groups:
These all support input-schmitt-enable, input-schmitt-disable,
and drive-strength.
jtag
pins: tck, trst, tdi, tdo, tms.
scb1
pins: scb1_sdat, scb1_sclk.
scb2
pins: scb2_sdat, scb2_sclk.
spi0
pins: spi0_mclk, spi0_cs0, spi0_cs1, spi0_cs2, spi0_dout, spi0_din.
spi1
pins: spi1_mclk, spi1_cs0, spi1_cs1, spi1_cs2, spi1_dout, spi1_din.
uart
pins: uart0_txd, uart0_rxd, uart0_rts, uart0_cts,
uart1_txd, uart1_rxd.
drive_i2s
pins: clk_out1, i2s_din, i2s_dout0, i2s_dout1, i2s_dout2,
i2s_lrclk_out, i2s_bclk_out, i2s_mclk.
drive_pdm
pins: clk_out0, pdm_b, pdm_a.
drive_scb0
pins: scb0_sclk, scb0_sdat, pdm_d, pdm_c.
drive_sdio
pins: sdio_clk, sdio_cmd, sdio_d0, sdio_d1, sdio_d2, sdio_d3,
sdh_wp, sdh_cd, sdh_clk_in.
convenience groups:
These are just convenient groupings of pins and don't support any drive
configs.
uart0
pins: uart0_cts, uart0_rts, uart0_rxd, uart0_txd.
uart1
pins: uart1_rxd, uart1_txd.
scb0
pins: scb0_sclk, scb0_sdat.
i2s
pins: i2s_bclk_out, i2s_din, i2s_dout0, i2s_dout1, i2s_dout2,
i2s_lrclk_out, i2s_mclk.
Example:
pinctrl: pinctrl@02005800 {
#gpio-range-cells = <3>;
compatible = "img,tz1090-pinctrl";
reg = <0x02005800 0xe4>;
};
Example board file extract:
&pinctrl {
uart0_default: uart0 {
uart0_cfg {
tz1090,pins = "uart0_rxd",
"uart0_txd";
tz1090,function = "perip";
};
};
tft_default: tft {
tft_cfg {
tz1090,pins = "tft";
tz1090,function = "tft";
};
};
};
uart@02004b00 {
pinctrl-names = "default";
pinctrl-0 = <&uart0_default>;
};

49
Documentation/devicetree/bindings/pinctrl/marvell,dove-pinctrl.txt
View File

@ -10,29 +10,31 @@ Required properties:
Available mpp pins/groups and functions:
Note: brackets (x) are not part of the mpp name for marvell,function and given
only for more detailed description in this document.
Note: pmu* also allows for Power Management functions listed below
name pins functions
================================================================================
mpp0 0 gpio, pmu, uart2(rts), sdio0(cd), lcd0(pwm)
mpp1 1 gpio, pmu, uart2(cts), sdio0(wp), lcd1(pwm)
mpp0 0 gpio, pmu, uart2(rts), sdio0(cd), lcd0(pwm), pmu*
mpp1 1 gpio, pmu, uart2(cts), sdio0(wp), lcd1(pwm), pmu*
mpp2 2 gpio, pmu, uart2(txd), sdio0(buspwr), sata(prsnt),
uart1(rts)
uart1(rts), pmu*
mpp3 3 gpio, pmu, uart2(rxd), sdio0(ledctrl), sata(act),
uart1(cts), lcd-spi(cs1)
mpp4 4 gpio, pmu, uart3(rts), sdio1(cd), spi1(miso)
mpp5 5 gpio, pmu, uart3(cts), sdio1(wp), spi1(cs)
mpp6 6 gpio, pmu, uart3(txd), sdio1(buspwr), spi1(mosi)
mpp7 7 gpio, pmu, uart3(rxd), sdio1(ledctrl), spi1(sck)
mpp8 8 gpio, pmu, watchdog(rstout)
mpp9 9 gpio, pmu, pex1(clkreq)
mpp10 10 gpio, pmu, ssp(sclk)
uart1(cts), lcd-spi(cs1), pmu*
mpp4 4 gpio, pmu, uart3(rts), sdio1(cd), spi1(miso), pmu*
mpp5 5 gpio, pmu, uart3(cts), sdio1(wp), spi1(cs), pmu*
mpp6 6 gpio, pmu, uart3(txd), sdio1(buspwr), spi1(mosi), pmu*
mpp7 7 gpio, pmu, uart3(rxd), sdio1(ledctrl), spi1(sck), pmu*
mpp8 8 gpio, pmu, watchdog(rstout), pmu*
mpp9 9 gpio, pmu, pex1(clkreq), pmu*
mpp10 10 gpio, pmu, ssp(sclk), pmu*
mpp11 11 gpio, pmu, sata(prsnt), sata-1(act), sdio0(ledctrl),
sdio1(ledctrl), pex0(clkreq)
mpp12 12 gpio, pmu, uart2(rts), audio0(extclk), sdio1(cd), sata(act)
sdio1(ledctrl), pex0(clkreq), pmu*
mpp12 12 gpio, pmu, uart2(rts), audio0(extclk), sdio1(cd),
sata(act), pmu*
mpp13 13 gpio, pmu, uart2(cts), audio1(extclk), sdio1(wp),
ssp(extclk)
mpp14 14 gpio, pmu, uart2(txd), sdio1(buspwr), ssp(rxd)
mpp15 15 gpio, pmu, uart2(rxd), sdio1(ledctrl), ssp(sfrm)
ssp(extclk), pmu*
mpp14 14 gpio, pmu, uart2(txd), sdio1(buspwr), ssp(rxd), pmu*
mpp15 15 gpio, pmu, uart2(rxd), sdio1(ledctrl), ssp(sfrm), pmu*
mpp16 16 gpio, uart3(rts), sdio0(cd), ac97(sdi1), lcd-spi(cs1)
mpp17 17 gpio, uart3(cts), sdio0(wp), ac97(sdi2), twsi(sda),
ac97-1(sysclko)
@ -57,6 +59,21 @@ mpp_nand 64-71 gpo, nand
audio0 - i2s, ac97
twsi - none, opt1, opt2, opt3
Power Management functions (pmu*):
pmu-nc Pin not driven by any PM function
pmu-low Pin driven low (0)
pmu-high Pin driven high (1)
pmic(sdi) Pin is used for PMIC SDI
cpu-pwr-down Pin is used for CPU_PWRDWN
standby-pwr-down Pin is used for STBY_PWRDWN
core-pwr-good Pin is used for CORE_PWR_GOOD (Pins 0-7 only)
cpu-pwr-good Pin is used for CPU_PWR_GOOD (Pins 8-15 only)
bat-fault Pin is used for BATTERY_FAULT
ext0-wakeup Pin is used for EXT0_WU
ext1-wakeup Pin is used for EXT0_WU
ext2-wakeup Pin is used for EXT0_WU
pmu-blink Pin is used for blink function
Notes:
* group "mpp_audio1" allows the following functions and gpio pins:
- gpio : gpio on pins 52-57

48
Documentation/devicetree/bindings/pinctrl/pinctrl-bindings.txt
View File

@ -126,3 +126,51 @@ device; they may be grandchildren, for example. Whether this is legal, and
whether there is any interaction between the child and intermediate parent
nodes, is again defined entirely by the binding for the individual pin
controller device.
== Using generic pinconfig options ==
Generic pinconfig parameters can be used by defining a separate node containing
the applicable parameters (and optional values), like:
pcfg_pull_up: pcfg_pull_up {
bias-pull-up;
drive-strength = <20>;
};
This node should then be referenced in the appropriate pinctrl node as a phandle
and parsed in the driver using the pinconf_generic_parse_dt_config function.
Supported configuration parameters are:
bias-disable - disable any pin bias
bias-high-impedance - high impedance mode ("third-state", "floating")
bias-bus-hold - latch weakly
bias-pull-up - pull up the pin
bias-pull-down - pull down the pin
bias-pull-pin-default - use pin-default pull state
drive-push-pull - drive actively high and low
drive-open-drain - drive with open drain
drive-open-source - drive with open source
drive-strength - sink or source at most X mA
input-schmitt-enable - enable schmitt-trigger mode
input-schmitt-disable - disable schmitt-trigger mode
input-debounce - debounce mode with debound time X
low-power-enable - enable low power mode
low-power-disable - disable low power mode
output-low - set the pin to output mode with low level
output-high - set the pin to output mode with high level
Arguments for parameters:
- bias-pull-up, -down and -pin-default take as optional argument on hardware
supporting it the pull strength in Ohm. bias-disable will disable the pull.
- drive-strength takes as argument the target strength in mA.
- input-debounce takes the debounce time in usec as argument
or 0 to disable debouncing
All parameters not listed here, do not take an argument.
More in-depth documentation on these parameters can be found in
<include/linux/pinctrl/pinconfig-generic.h>

3
Documentation/devicetree/bindings/pinctrl/pinctrl-single.txt
View File

@ -18,7 +18,8 @@ Optional properties:
pin functions is ignored
- pinctrl-single,bit-per-mux : boolean to indicate that one register controls
more than one pin
more than one pin, for which "pinctrl-single,function-mask" property specifies
position mask of pin.
- pinctrl-single,drive-strength : array of value that are used to configure
drive strength in the pinmux register. They're value of drive strength

110
Documentation/devicetree/bindings/pinctrl/pinctrl-st.txt 100644
View File

@ -0,0 +1,110 @@
*ST pin controller.
Each multi-function pin is controlled, driven and routed through the
PIO multiplexing block. Each pin supports GPIO functionality (ALT0)
and multiple alternate functions(ALT1 - ALTx) that directly connect
the pin to different hardware blocks.
When a pin is in GPIO mode, Output Enable (OE), Open Drain(OD), and
Pull Up (PU) are driven by the related PIO block.
ST pinctrl driver controls PIO multiplexing block and also interacts with
gpio driver to configure a pin.
Required properties: (PIO multiplexing block)
- compatible : should be "st,<SOC>-<pio-block>-pinctrl"
like st,stih415-sbc-pinctrl, st,stih415-front-pinctrl and so on.
- gpio-controller : Indicates this device is a GPIO controller
- #gpio-cells : Should be one. The first cell is the pin number.
- st,retime-pin-mask : Should be mask to specify which pins can be retimed.
If the property is not present, it is assumed that all the pins in the
bank are capable of retiming. Retiming is mainly used to improve the
IO timing margins of external synchronous interfaces.
- st,bank-name : Should be a name string for this bank as
specified in datasheet.
- st,syscfg : Should be a phandle of the syscfg node.
Example:
pin-controller-sbc {
#address-cells = <1>;
#size-cells = <1>;
compatible = "st,stih415-sbc-pinctrl";
st,syscfg = <&syscfg_sbc>;
ranges = <0 0xfe610000 0x5000>;
PIO0: gpio@fe610000 {
gpio-controller;
#gpio-cells = <1>;
reg = <0 0x100>;
st,bank-name = "PIO0";
};
...
pin-functions nodes follow...
};
Contents of function subnode node:
----------------------
Required properties for pin configuration node:
- st,pins : Child node with list of pins with configuration.
Below is the format of how each pin conf should look like.
<bank offset mux mode rt_type rt_delay rt_clk>
Every PIO is represented with 4-7 parameters depending on retime configuration.
Each parameter is explained as below.
-bank : Should be bank phandle to which this PIO belongs.
-offset : Offset in the PIO bank.
-mux : Should be alternate function number associated this pin.
Use same numbers from datasheet.
-mode :pin configuration is selected from one of the below values.
IN
IN_PU
OUT
BIDIR
BIDIR_PU
-rt_type Retiming Configuration for the pin.
Possible retime configuration are:
------- -------------
value args
------- -------------
NICLK <delay> <clk>
ICLK_IO <delay> <clk>
BYPASS <delay>
DE_IO <delay> <clk>
SE_ICLK_IO <delay> <clk>
SE_NICLK_IO <delay> <clk>
- delay is retime delay in pico seconds as mentioned in data sheet.
- rt_clk :clk to be use for retime.
Possible values are:
CLK_A
CLK_B
CLK_C
CLK_D
Example of mmcclk pin which is a bi-direction pull pu with retime config
as non inverted clock retimed with CLK_B and delay of 0 pico seconds:
pin-controller {
...
mmc0 {
pinctrl_mmc: mmc {
st,pins {
mmcclk = <&PIO13 4 ALT4 BIDIR_PU NICLK 0 CLK_B>;
...
};
};
...
};
};
sdhci0:sdhci@fe810000{
...
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_mmc>;
};

153
Documentation/devicetree/bindings/pinctrl/renesas,pfc-pinctrl.txt 100644
View File

@ -0,0 +1,153 @@
* Renesas Pin Function Controller (GPIO and Pin Mux/Config)
The Pin Function Controller (PFC) is a Pin Mux/Config controller. On SH7372,
SH73A0, R8A73A4 and R8A7740 it also acts as a GPIO controller.
Pin Control
-----------
Required Properties:
- compatible: should be one of the following.
- "renesas,pfc-r8a73a4": for R8A73A4 (R-Mobile APE6) compatible pin-controller.
- "renesas,pfc-r8a7740": for R8A7740 (R-Mobile A1) compatible pin-controller.
- "renesas,pfc-r8a7778": for R8A7778 (R-Mobile M1) compatible pin-controller.
- "renesas,pfc-r8a7779": for R8A7779 (R-Car H1) compatible pin-controller.
- "renesas,pfc-r8a7790": for R8A7790 (R-Car H2) compatible pin-controller.
- "renesas,pfc-sh7372": for SH7372 (SH-Mobile AP4) compatible pin-controller.
- "renesas,pfc-sh73a0": for SH73A0 (SH-Mobile AG5) compatible pin-controller.
- reg: Base address and length of each memory resource used by the pin
controller hardware module.
Optional properties:
- #gpio-range-cells: Mandatory when the PFC doesn't handle GPIO, forbidden
otherwise. Should be 3.
The PFC node also acts as a container for pin configuration nodes. Please refer
to pinctrl-bindings.txt in this directory for the definition of the term "pin
configuration node" and for the common pinctrl bindings used by client devices.
Each pin configuration node represents a desired configuration for a pin, a
pin group, or a list of pins or pin groups. The configuration can include the
function to select on those pin(s) and pin configuration parameters (such as
pull-up and pull-down).
Pin configuration nodes contain pin configuration properties, either directly
or grouped in child subnodes. Both pin muxing and configuration parameters can
be grouped in that way and referenced as a single pin configuration node by
client devices.
A configuration node or subnode must reference at least one pin (through the
pins or pin groups properties) and contain at least a function or one
configuration parameter. When the function is present only pin groups can be
used to reference pins.
All pin configuration nodes and subnodes names are ignored. All of those nodes
are parsed through phandles and processed purely based on their content.
Pin Configuration Node Properties:
- renesas,pins : An array of strings, each string containing the name of a pin.
- renesas,groups : An array of strings, each string containing the name of a pin
group.
- renesas,function: A string containing the name of the function to mux to the
pin group(s) specified by the renesas,groups property
Valid values for pin, group and function names can be found in the group and
function arrays of the PFC data file corresponding to the SoC
(drivers/pinctrl/sh-pfc/pfc-*.c)
The pin configuration parameters use the generic pinconf bindings defined in
pinctrl-bindings.txt in this directory. The supported parameters are
bias-disable, bias-pull-up and bias-pull-down.
GPIO
----
On SH7372, SH73A0, R8A73A4 and R8A7740 the PFC node is also a GPIO controller
node.
Required Properties:
- gpio-controller: Marks the device node as a gpio controller.
- #gpio-cells: Should be 2. The first cell is the GPIO number and the second
cell specifies GPIO flags, as defined in <dt-bindings/gpio/gpio.h>. Only the
GPIO_ACTIVE_HIGH and GPIO_ACTIVE_LOW flags are supported.
The syntax of the gpio specifier used by client nodes should be the following
with values derived from the SoC user manual.
<[phandle of the gpio controller node]
[pin number within the gpio controller]
[flags]>
On other mach-shmobile platforms GPIO is handled by the gpio-rcar driver.
Please refer to Documentation/devicetree/bindings/gpio/renesas,gpio-rcar.txt
for documentation of the GPIO device tree bindings on those platforms.
Examples
--------
Example 1: SH73A0 (SH-Mobile AG5) pin controller node
pfc: pfc@e6050000 {
compatible = "renesas,pfc-sh73a0";
reg = <0xe6050000 0x8000>,
<0xe605801c 0x1c>;
gpio-controller;
#gpio-cells = <2>;
};
Example 2: A GPIO LED node that references a GPIO
#include <dt-bindings/gpio/gpio.h>
leds {
compatible = "gpio-leds";
led1 {
gpios = <&pfc 20 GPIO_ACTIVE_LOW>;
};
};
Example 3: KZM-A9-GT (SH-Mobile AG5) default pin state hog and pin control maps
for the MMCIF and SCIFA4 devices
&pfc {
pinctrl-0 = <&scifa4_pins>;
pinctrl-names = "default";
mmcif_pins: mmcif {
mux {
renesas,groups = "mmc0_data8_0", "mmc0_ctrl_0";
renesas,function = "mmc0";
};
cfg {
renesas,groups = "mmc0_data8_0";
renesas,pins = "PORT279";
bias-pull-up;
};
};
scifa4_pins: scifa4 {
renesas,groups = "scifa4_data", "scifa4_ctrl";
renesas,function = "scifa4";
};
};
Example 4: KZM-A9-GT (SH-Mobile AG5) default pin state for the MMCIF device
&mmcif {
pinctrl-0 = <&mmcif_pins>;
pinctrl-names = "default";
bus-width = <8>;
vmmc-supply = <&reg_1p8v>;
status = "okay";
};

97
Documentation/devicetree/bindings/pinctrl/rockchip,pinctrl.txt 100644
View File

@ -0,0 +1,97 @@
* Rockchip Pinmux Controller
The Rockchip Pinmux Controller, enables the IC
to share one PAD to several functional blocks. The sharing is done by
multiplexing the PAD input/output signals. For each PAD there are up to
4 muxing options with option 0 being the use as a GPIO.
Please refer to pinctrl-bindings.txt in this directory for details of the
common pinctrl bindings used by client devices, including the meaning of the
phrase "pin configuration node".
The Rockchip pin configuration node is a node of a group of pins which can be
used for a specific device or function. This node represents both mux and
config of the pins in that group. The 'pins' selects the function mode(also
named pin mode) this pin can work on and the 'config' configures various pad
settings such as pull-up, etc.
The pins are grouped into up to 5 individual pin banks which need to be
defined as gpio sub-nodes of the pinmux controller.
Required properties for iomux controller:
- compatible: one of "rockchip,rk2928-pinctrl", "rockchip,rk3066a-pinctrl"
"rockchip,rk3066b-pinctrl", "rockchip,rk3188-pinctrl"
Required properties for gpio sub nodes:
- compatible: "rockchip,gpio-bank"
- reg: register of the gpio bank (different than the iomux registerset)
- interrupts: base interrupt of the gpio bank in the interrupt controller
- clocks: clock that drives this bank
- gpio-controller: identifies the node as a gpio controller and pin bank.
- #gpio-cells: number of cells in GPIO specifier. Since the generic GPIO
binding is used, the amount of cells must be specified as 2. See generic
GPIO binding documentation for description of particular cells.
- interrupt-controller: identifies the controller node as interrupt-parent.
- #interrupt-cells: the value of this property should be 2 and the interrupt
cells should use the standard two-cell scheme described in
bindings/interrupt-controller/interrupts.txt
Required properties for pin configuration node:
- rockchip,pins: 3 integers array, represents a group of pins mux and config
setting. The format is rockchip,pins = <PIN_BANK PIN_BANK_IDX MUX &phandle>.
The MUX 0 means gpio and MUX 1 to 3 mean the specific device function.
The phandle of a node containing the generic pinconfig options
to use, as described in pinctrl-bindings.txt in this directory.
Examples:
#include <dt-bindings/pinctrl/rockchip.h>
...
pinctrl@20008000 {
compatible = "rockchip,rk3066a-pinctrl";
reg = <0x20008000 0x150>;
#address-cells = <1>;
#size-cells = <1>;
ranges;
gpio0: gpio0@20034000 {
compatible = "rockchip,gpio-bank";
reg = <0x20034000 0x100>;
interrupts = <GIC_SPI 54 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&clk_gates8 9>;
gpio-controller;
#gpio-cells = <2>;
interrupt-controller;
#interrupt-cells = <2>;
};
...
pcfg_pull_default: pcfg_pull_default {
bias-pull-pin-default
};
uart2 {
uart2_xfer: uart2-xfer {
rockchip,pins = <RK_GPIO1 8 1 &pcfg_pull_default>,
<RK_GPIO1 9 1 &pcfg_pull_default>;
};
};
};
uart2: serial@20064000 {
compatible = "snps,dw-apb-uart";
reg = <0x20064000 0x400>;
interrupts = <GIC_SPI 36 IRQ_TYPE_LEVEL_HIGH>;
reg-shift = <2>;
reg-io-width = <1>;
clocks = <&mux_uart2>;
status = "okay";
pinctrl-names = "default";
pinctrl-0 = <&uart2_xfer>;
};

352
Documentation/devicetree/bindings/pinctrl/ste,abx500.txt 100644
View File

@ -0,0 +1,352 @@
ST Ericsson abx500 pinmux controller
Required properties:
- compatible: "stericsson,ab8500-gpio", "stericsson,ab8540-gpio",
"stericsson,ab8505-gpio", "stericsson,ab9540-gpio",
Please refer to pinctrl-bindings.txt in this directory for details of the
common pinctrl bindings used by client devices, including the meaning of the
phrase "pin configuration node".
ST Ericsson's pin configuration nodes act as a container for an arbitrary number of
subnodes. Each of these subnodes represents some desired configuration for a
pin, a group, or a list of pins or groups. This configuration can include the
mux function to select on those pin(s)/group(s), and various pin configuration
parameters, such as input, output, pull up, pull down...
The name of each subnode is not important; all subnodes should be enumerated
and processed purely based on their content.
Required subnode-properties:
- ste,pins : An array of strings. Each string contains the name of a pin or
group.
Optional subnode-properties:
- ste,function: A string containing the name of the function to mux to the
pin or group.
- generic pin configuration option to use. Example :
default_cfg {
ste,pins = "GPIO1";
bias-disable;
};
- ste,config: Handle of pin configuration node containing the generic
pinconfig options to use, as described in pinctrl-bindings.txt in
this directory. Example :
pcfg_bias_disable: pcfg_bias_disable {
bias-disable;
};
default_cfg {
ste,pins = "GPIO1";
ste.config = <&pcfg_bias_disable>;
};
Example board file extract:
&pinctrl_abx500 {
pinctrl-names = "default";
pinctrl-0 = <&sysclkreq2_default_mode>, <&sysclkreq3_default_mode>, <&gpio3_default_mode>, <&sysclkreq6_default_mode>, <&pwmout1_default_mode>, <&pwmout2_default_mode>, <&pwmout3_default_mode>, <&adi1_default_mode>, <&dmic12_default_mode>, <&dmic34_default_mode>, <&dmic56_default_mode>, <&sysclkreq5_default_mode>, <&batremn_default_mode>, <&service_default_mode>, <&pwrctrl0_default_mode>, <&pwrctrl1_default_mode>, <&pwmextvibra1_default_mode>, <&pwmextvibra2_default_mode>, <&gpio51_default_mode>, <&gpio52_default_mode>, <&gpio53_default_mode>, <&gpio54_default_mode>, <&pdmclkdat_default_mode>;
sysclkreq2 {
sysclkreq2_default_mode: sysclkreq2_default {
default_mux {
ste,function = "sysclkreq";
ste,pins = "sysclkreq2_d_1";
};
default_cfg {
ste,pins = "GPIO1";
bias-disable;
};
};
};
sysclkreq3 {
sysclkreq3_default_mode: sysclkreq3_default {
default_mux {
ste,function = "sysclkreq";
ste,pins = "sysclkreq3_d_1";
};
default_cfg {
ste,pins = "GPIO2";
output-low;
};
};
};
gpio3 {
gpio3_default_mode: gpio3_default {
default_mux {
ste,function = "gpio";
ste,pins = "gpio3_a_1";
};
default_cfg {
ste,pins = "GPIO3";
output-low;
};
};
};
sysclkreq6 {
sysclkreq6_default_mode: sysclkreq6_default {
default_mux {
ste,function = "sysclkreq";
ste,pins = "sysclkreq6_d_1";
};
default_cfg {
ste,pins = "GPIO4";
bias-disable;
};
};
};
pwmout1 {
pwmout1_default_mode: pwmout1_default {
default_mux {
ste,function = "pwmout";
ste,pins = "pwmout1_d_1";
};
default_cfg {
ste,pins = "GPIO14";
output-low;
};
};
};
pwmout2 {
pwmout2_default_mode: pwmout2_default {
pwmout2_default_mux {
ste,function = "pwmout";
ste,pins = "pwmout2_d_1";
};
pwmout2_default_cfg {
ste,pins = "GPIO15";
output-low;
};
};
};
pwmout3 {
pwmout3_default_mode: pwmout3_default {
pwmout3_default_mux {
ste,function = "pwmout";
ste,pins = "pwmout3_d_1";
};
pwmout3_default_cfg {
ste,pins = "GPIO16";
output-low;
};
};
};
adi1 {
adi1_default_mode: adi1_default {
adi1_default_mux {
ste,function = "adi1";
ste,pins = "adi1_d_1";
};
adi1_default_cfg1 {
ste,pins = "GPIO17","GPIO19","GPIO20";
bias-disable;
};
adi1_default_cfg2 {
ste,pins = "GPIO18";
output-low;
};
};
};
dmic12 {
dmic12_default_mode: dmic12_default {
dmic12_default_mux {
ste,function = "dmic";
ste,pins = "dmic12_d_1";
};
dmic12_default_cfg1 {
ste,pins = "GPIO27";
output-low;
};
dmic12_default_cfg2 {
ste,pins = "GPIO28";
bias-disable;
};
};
};
dmic34 {
dmic34_default_mode: dmic34_default {
dmic34_default_mux {
ste,function = "dmic";
ste,pins = "dmic34_d_1";
};
dmic34_default_cfg1 {
ste,pins = "GPIO29";
output-low;
};
dmic34_default_cfg2 {
ste,pins = "GPIO30";
bias-disable;{
};
};
};
dmic56 {
dmic56_default_mode: dmic56_default {
dmic56_default_mux {
ste,function = "dmic";
ste,pins = "dmic56_d_1";
};
dmic56_default_cfg1 {
ste,pins = "GPIO31";
output-low;
};
dmic56_default_cfg2 {
ste,pins = "GPIO32";
bias-disable;
};
};
};
sysclkreq5 {
sysclkreq5_default_mode: sysclkreq5_default {
sysclkreq5_default_mux {
ste,function = "sysclkreq";
ste,pins = "sysclkreq5_d_1";
};
sysclkreq5_default_cfg {
ste,pins = "GPIO42";
output-low;
};
};
};
batremn {
batremn_default_mode: batremn_default {
batremn_default_mux {
ste,function = "batremn";
ste,pins = "batremn_d_1";
};
batremn_default_cfg {
ste,pins = "GPIO43";
bias-disable;
};
};
};
service {
service_default_mode: service_default {
service_default_mux {
ste,function = "service";
ste,pins = "service_d_1";
};
service_default_cfg {
ste,pins = "GPIO44";
bias-disable;
};
};
};
pwrctrl0 {
pwrctrl0_default_mux: pwrctrl0_mux {
pwrctrl0_default_mux {
ste,function = "pwrctrl";
ste,pins = "pwrctrl0_d_1";
};
};
pwrctrl0_default_mode: pwrctrl0_default {
pwrctrl0_default_cfg {
ste,pins = "GPIO45";
bias-disable;
};
};
};
pwrctrl1 {
pwrctrl1_default_mux: pwrctrl1_mux {
pwrctrl1_default_mux {
ste,function = "pwrctrl";
ste,pins = "pwrctrl1_d_1";
};
};
pwrctrl1_default_mode: pwrctrl1_default {
pwrctrl1_default_cfg {
ste,pins = "GPIO46";
bias-disable;
};
};
};
pwmextvibra1 {
pwmextvibra1_default_mode: pwmextvibra1_default {
pwmextvibra1_default_mux {
ste,function = "pwmextvibra";
ste,pins = "pwmextvibra1_d_1";
};
pwmextvibra1_default_cfg {
ste,pins = "GPIO47";
bias-disable;
};
};
};
pwmextvibra2 {
pwmextvibra2_default_mode: pwmextvibra2_default {
pwmextvibra2_default_mux {
ste,function = "pwmextvibra";
ste,pins = "pwmextvibra2_d_1";
};
pwmextvibra1_default_cfg {
ste,pins = "GPIO48";
bias-disable;
};
};
};
gpio51 {
gpio51_default_mode: gpio51_default {
gpio51_default_mux {
ste,function = "gpio";
ste,pins = "gpio51_a_1";
};
gpio51_default_cfg {
ste,pins = "GPIO51";
output-low;
};
};
};
gpio52 {
gpio52_default_mode: gpio52_default {
gpio52_default_mux {
ste,function = "gpio";
ste,pins = "gpio52_a_1";
};
gpio52_default_cfg {
ste,pins = "GPIO52";
bias-pull-down;
};
};
};
gpio53 {
gpio53_default_mode: gpio53_default {
gpio53_default_mux {
ste,function = "gpio";
ste,pins = "gpio53_a_1";
};
gpio53_default_cfg {
ste,pins = "GPIO53";
bias-pull-down;
};
};
};
gpio54 {
gpio54_default_mode: gpio54_default {
gpio54_default_mux {
ste,function = "gpio";
ste,pins = "gpio54_a_1";
};
gpio54_default_cfg {
ste,pins = "GPIO54";
output-low;
};
};
};
pdmclkdat {
pdmclkdat_default_mode: pdmclkdat_default {
pdmclkdat_default_mux {
ste,function = "pdm";
ste,pins = "pdmclkdat_d_1";
};
pdmclkdat_default_cfg {
ste,pins = "GPIO55", "GPIO56";
bias-disable;
};
};
};
};

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

309
Documentation/devicetree/bindings/powerpc/fsl/interlaken-lac.txt 100644
View File

@ -0,0 +1,309 @@
===============================================================================
Freescale Interlaken Look-Aside Controller Device Bindings
Copyright 2012 Freescale Semiconductor Inc.
CONTENTS
- Interlaken Look-Aside Controller (LAC) Node
- Example LAC Node
- Interlaken Look-Aside Controller (LAC) Software Portal Node
- Interlaken Look-Aside Controller (LAC) Software Portal Child Nodes
- Example LAC SWP Node with Child Nodes
==============================================================================
Interlaken Look-Aside Controller (LAC) Node
DESCRIPTION
The Interlaken is a narrow, high speed channelized chip-to-chip interface. To
facilitate interoperability between a data path device and a look-aside
co-processor, the Interlaken Look-Aside protocol is defined for short
transaction-related transfers. Although based on the Interlaken protocol,
Interlaken Look-Aside is not directly compatible with Interlaken and can be
considered a different operation mode.
The Interlaken LA controller connects internal platform to Interlaken serial
interface. It accepts LA command through software portals, which are system
memory mapped 4KB spaces. The LA commands are then translated into the
Interlaken control words and data words, which are sent on TX side to TCAM
through SerDes lanes.
There are two 4KiB spaces defined within the LAC global register memory map.
There is a full register set at 0x0000-0x0FFF (also known as the "hypervisor"
version), and a subset at 0x1000-0x1FFF. The former is a superset of the
latter, and includes certain registers that should not be accessible to
partitioned software. Separate nodes are used for each region, with a phandle
linking the hypervisor node to the normal operating node.
PROPERTIES
- compatible
Usage: required
Value type: <string>
Definition: Must include "fsl,interlaken-lac". This represents only
those LAC CCSR registers not protected in partitioned
software. The version of the device is determined by the LAC
IP Block Revision Register (IPBRR0) at offset 0x0BF8.
Table of correspondences between IPBRR0 values and example
chips:
Value Device
----------- -------
0x02000100 T4240
The Hypervisor node has a different compatible. It must include
"fsl,interlaken-lac-hv". This node represents the protected
LAC register space and is required except inside a partition
where access to the hypervisor node is to be denied.
- fsl,non-hv-node
Usage: required in "fsl,interlaken-lac-hv"
Value type: <phandle>
Definition: Points to the non-protected LAC CCSR mapped register space
node.
- reg
Usage: required
Value type: <prop-encoded-array>
Definition: A standard property. The first resource represents the
Interlaken LAC configuration registers.
- interrupts:
Usage: required in non-hv node only
Value type: <prop-encoded-array>
Definition: Interrupt mapping for Interlaken LAC error IRQ.
EXAMPLE
lac: lac@229000 {
compatible = "fsl,interlaken-lac"
reg = <0x229000 0x1000>;
interrupts = <16 2 1 18>;
};
lac-hv@228000 {
compatible = "fsl,interlaken-lac-hv"
reg = <0x228000 0x1000>;
fsl,non-hv-node = <&lac>;
};
===============================================================================
Interlaken Look-Aside Controller (LAC) Software Portal Container Node
DESCRIPTION
The Interlaken Look-Aside Controller (LAC) utilizes Software Portals to accept
Interlaken Look-Aside (ILA) commands. The Interlaken LAC software portal
memory map occupies 128KB of memory space. The software portal memory space is
intended to be cache-enabled. WIMG for each software space is required to be
0010 if stashing is enabled; otherwise, WIMG can be 0000 or 0010.
PROPERTIES
- #address-cells
Usage: required
Value type: <u32>
Definition: A standard property. Must have a value of 1.
- #size-cells
Usage: required
Value type: <u32>
Definition: A standard property. Must have a value of 1.
- compatible
Usage: required
Value type: <string>
Definition: Must include "fsl,interlaken-lac-portals"
- ranges
Usage: required
Value type: <prop-encoded-array>
Definition: A standard property. Specifies the address and length
of the LAC portal memory space.
===============================================================================
Interlaken Look-Aside Controller (LAC) Software Portals Child Nodes
DESCRIPTION
There are up to 24 available software portals with each software portal
requiring 4KB of consecutive memory within the software portal memory mapped
space.
PROPERTIES
- compatible
Usage: required
Value type: <string>
Definition: Must include "fsl,interlaken-lac-portal-vX.Y" where X is
the Major version (IP_MJ) found in the LAC IP Block Revision
Register (IPBRR0), at offset 0x0BF8, and Y is the Minor version
(IP_MN).
Table of correspondences between version values and example chips:
Value Device
------ -------
1.0 T4240
- reg
Usage: required
Value type: <prop-encoded-array>
Definition: A standard property. The first resource represents the
Interlaken LAC software portal registers.
- fsl,liodn
Value type: <u32>
Definition: The logical I/O device number (LIODN) for this device. The
LIODN is a number expressed by this device and used to perform
look-ups in the IOMMU (PAMU) address table when performing
DMAs. This property is automatically added by u-boot.
===============================================================================
EXAMPLE
lac-portals {
#address-cells = <0x1>;
#size-cells = <0x1>;
compatible = "fsl,interlaken-lac-portals";
ranges = <0x0 0xf 0xf4400000 0x20000>;
lportal0: lac-portal@0 {
compatible = "fsl,interlaken-lac-portal-v1.0";
fsl,liodn = <0x204>;
reg = <0x0 0x1000>;
};
lportal1: lac-portal@1000 {
compatible = "fsl,interlaken-lac-portal-v1.0";
fsl,liodn = <0x205>;
reg = <0x1000 0x1000>;
};
lportal2: lac-portal@2000 {
compatible = "fsl,interlaken-lac-portal-v1.0";
fsl,liodn = <0x206>;
reg = <0x2000 0x1000>;
};
lportal3: lac-portal@3000 {
compatible = "fsl,interlaken-lac-portal-v1.0";
fsl,liodn = <0x207>;
reg = <0x3000 0x1000>;
};
lportal4: lac-portal@4000 {
compatible = "fsl,interlaken-lac-portal-v1.0";
fsl,liodn = <0x208>;
reg = <0x4000 0x1000>;
};
lportal5: lac-portal@5000 {
compatible = "fsl,interlaken-lac-portal-v1.0";
fsl,liodn = <0x209>;
reg = <0x5000 0x1000>;
};
lportal6: lac-portal@6000 {
compatible = "fsl,interlaken-lac-portal-v1.0";
fsl,liodn = <0x20A>;
reg = <0x6000 0x1000>;
};
lportal7: lac-portal@7000 {
compatible = "fsl,interlaken-lac-portal-v1.0";
fsl,liodn = <0x20B>;
reg = <0x7000 0x1000>;
};
lportal8: lac-portal@8000 {
compatible = "fsl,interlaken-lac-portal-v1.0";
fsl,liodn = <0x20C>;
reg = <0x8000 0x1000>;
};
lportal9: lac-portal@9000 {
compatible = "fsl,interlaken-lac-portal-v1.0";
fsl,liodn = <0x20D>;
reg = <0x9000 0x1000>;
};
lportal10: lac-portal@A000 {
compatible = "fsl,interlaken-lac-portal-v1.0";
fsl,liodn = <0x20E>;
reg = <0xA000 0x1000>;
};
lportal11: lac-portal@B000 {
compatible = "fsl,interlaken-lac-portal-v1.0";
fsl,liodn = <0x20F>;
reg = <0xB000 0x1000>;
};
lportal12: lac-portal@C000 {
compatible = "fsl,interlaken-lac-portal-v1.0";
fsl,liodn = <0x210>;
reg = <0xC000 0x1000>;
};
lportal13: lac-portal@D000 {
compatible = "fsl,interlaken-lac-portal-v1.0";
fsl,liodn = <0x211>;
reg = <0xD000 0x1000>;
};
lportal14: lac-portal@E000 {
compatible = "fsl,interlaken-lac-portal-v1.0";
fsl,liodn = <0x212>;
reg = <0xE000 0x1000>;
};
lportal15: lac-portal@F000 {
compatible = "fsl,interlaken-lac-portal-v1.0";
fsl,liodn = <0x213>;
reg = <0xF000 0x1000>;
};
lportal16: lac-portal@10000 {
compatible = "fsl,interlaken-lac-portal-v1.0";
fsl,liodn = <0x214>;
reg = <0x10000 0x1000>;
};
lportal17: lac-portal@11000 {
compatible = "fsl,interlaken-lac-portal-v1.0";
fsl,liodn = <0x215>;
reg = <0x11000 0x1000>;
};
lportal8: lac-portal@1200 {
compatible = "fsl,interlaken-lac-portal-v1.0";
fsl,liodn = <0x216>;
reg = <0x12000 0x1000>;
};
lportal19: lac-portal@13000 {
compatible = "fsl,interlaken-lac-portal-v1.0";
fsl,liodn = <0x217>;
reg = <0x13000 0x1000>;
};
lportal20: lac-portal@14000 {
compatible = "fsl,interlaken-lac-portal-v1.0";
fsl,liodn = <0x218>;
reg = <0x14000 0x1000>;
};
lportal21: lac-portal@15000 {
compatible = "fsl,interlaken-lac-portal-v1.0";
fsl,liodn = <0x219>;
reg = <0x15000 0x1000>;
};
lportal22: lac-portal@16000 {
compatible = "fsl,interlaken-lac-portal-v1.0";
fsl,liodn = <0x21A>;
reg = <0x16000 0x1000>;
};
lportal23: lac-portal@17000 {
compatible = "fsl,interlaken-lac-portal-v1.0";
fsl,liodn = <0x21B>;
reg = <0x17000 0x1000>;
};
};

20
Documentation/devicetree/bindings/pps/pps-gpio.txt 100644
View File

@ -0,0 +1,20 @@
Device-Tree Bindings for a PPS Signal on GPIO
These properties describe a PPS (pulse-per-second) signal connected to
a GPIO pin.
Required properties:
- compatible: should be "pps-gpio"
- gpios: one PPS GPIO in the format described by ../gpio/gpio.txt
Optional properties:
- assert-falling-edge: when present, assert is indicated by a falling edge
(instead of by a rising edge)
Example:
pps {
compatible = "pps-gpio";
gpios = <&gpio2 6 0>;
assert-falling-edge;
};

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;
};

160
Documentation/devicetree/bindings/regulator/lp872x.txt 100644
View File

@ -0,0 +1,160 @@
Binding for TI/National Semiconductor LP872x Driver
Required properties:
- compatible: "ti,lp8720" or "ti,lp8725"
- reg: I2C slave address. 0x7d = LP8720, 0x7a = LP8725
Optional properties:
- ti,general-config: the value of LP872X_GENERAL_CFG register (u8)
(LP8720)
bit[2]: BUCK output voltage control by external DVS pin or register
1 = external pin, 0 = bit7 of register 08h
bit[1]: sleep control by external DVS pin or register
1 = external pin, 0 = bit6 of register 08h
bit[0]: time step unit(usec). 1 = 25, 0 = 50
(LP8725)
bit[7:6]: time step unit(usec). 00 = 32, 01 = 64, 10 = 128, 11 = 256
bit[4]: BUCK2 enable control. 1 = enable, 0 = disable
bit[3]: BUCK2 output voltage register address. 1 = 0Ah, 0 = 0Bh
bit[2]: BUCK1 output voltage control by external DVS pin or register
1 = register 08h, 0 = DVS
bit[1]: LDO sleep control. 1 = sleep mode, 0 = normal
bit[0]: BUCK1 enable control, 1 = enable, 0 = disable
For more details, please see the datasheet.
- ti,update-config: define it when LP872X_GENERAL_CFG register should be set
- ti,dvs-gpio: GPIO specifier for external DVS pin control of LP872x devices.
- ti,dvs-vsel: DVS selector. 0 = SEL_V1, 1 = SEL_V2.
- ti,dvs-state: initial DVS pin state. 0 = DVS_LOW, 1 = DVS_HIGH.
Sub nodes for regulator_init_data
LP8720 has maximum 6 nodes. (child name: ldo1 ~ 5 and buck)
LP8725 has maximum 9 nodes. (child name: ldo1 ~ 5, lilo1,2 and buck1,2)
For more details, please see the following binding document.
(Documentation/devicetree/bindings/regulator/regulator.txt)
Datasheet
- LP8720: http://www.ti.com/lit/ds/symlink/lp8720.pdf
- LP8725: http://www.ti.com/lit/ds/symlink/lp8725.pdf
Example 1) LP8720
lp8720@7d {
compatible = "ti,lp8720";
reg = <0x7d>;
/* external DVS pin used, timestep is 25usec */
ti,general-config = /bits/ 8 <0x03>;
ti,update-config;
/*
* The dvs-gpio depends on the processor environment.
* For example, following GPIO specifier means GPIO134 in OMAP4.
*/
ti,dvs-gpio = <&gpio5 6 0>;
ti,dvs-vsel = /bits/ 8 <1>; /* SEL_V2 */
ti,dvs-state = /bits/ 8 <1>; /* DVS_HIGH */
vaf: ldo1 {
regulator-min-microvolt = <1200000>;
regulator-max-microvolt = <3300000>;
};
vmmc: ldo2 {
regulator-min-microvolt = <1200000>;
regulator-max-microvolt = <3300000>;
};
vcam_io: ldo3 {
regulator-min-microvolt = <1200000>;
regulator-max-microvolt = <3300000>;
regulator-boot-on;
};
vcam_core: ldo4 {
regulator-min-microvolt = <800000>;
regulator-max-microvolt = <2850000>;
regulator-boot-on;
};
vcam: ldo5 {
regulator-min-microvolt = <1200000>;
regulator-max-microvolt = <3300000>;
};
vcc: buck {
regulator-name = "VBUCK";
regulator-min-microvolt = <800000>;
regulator-max-microvolt = <2300000>;
};
};
Example 2) LP8725
lp8725@7a {
compatible = "ti,lp8725";
reg = <0x7a>;
/* Enable BUCK1,2, no DVS, normal LDO mode, timestep is 256usec */
ti,general-config = /bits/ 8 <0xdd>;
ti,update-config;
vcam_io: ldo1 {
regulator-min-microvolt = <1200000>;
regulator-max-microvolt = <3300000>;
};
vcam_core: ldo2 {
regulator-min-microvolt = <1200000>;
regulator-max-microvolt = <3300000>;
};
vcam: ldo3 {
regulator-min-microvolt = <1200000>;
regulator-max-microvolt = <3300000>;
};
vcmmb_io: ldo4 {
regulator-min-microvolt = <1200000>;
regulator-max-microvolt = <3300000>;
regulator-boot-on;
};
vcmmb_core: ldo5 {
regulator-min-microvolt = <1200000>;
regulator-max-microvolt = <3300000>;
regulator-boot-on;
};
vaux1: lilo1 {
regulator-name = "VAUX1";
regulator-min-microvolt = <800000>;
regulator-max-microvolt = <3300000>;
};
vaux2: lilo2 {
regulator-name = "VAUX2";
regulator-min-microvolt = <800000>;
regulator-max-microvolt = <3300000>;
};
vcc1: buck1 {
regulator-name = "VBUCK1";
regulator-min-microvolt = <800000>;
regulator-max-microvolt = <3000000>;
regulator-min-microamp = <460000>;
regulator-max-microamp = <1370000>;
regulator-boot-on;
};
vcc2: buck2 {
regulator-name = "VBUCK2";
regulator-min-microvolt = <800000>;
regulator-max-microvolt = <3000000>;
regulator-min-microamp = <460000>;
regulator-max-microamp = <1370000>;
regulator-boot-on;
};
};

21
Documentation/devicetree/bindings/regulator/max8973-regulator.txt 100644
View File

@ -0,0 +1,21 @@
* Maxim MAX8973 Voltage Regulator
Required properties:
- compatible: must be "maxim,max8973"
- reg: the i2c slave address of the regulator. It should be 0x1b.
Any standard regulator properties can be used to configure the single max8973
DCDC.
Example:
max8973@1b {
compatible = "maxim,max8973";
reg = <0x1b>;
regulator-min-microvolt = <935000>;
regulator-max-microvolt = <1200000>;
regulator-boot-on;
regulator-always-on;
};

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