renegade-project/linux-next
2
0
Fork 0
mirror of https://github.com/edk2-porting/linux-next.git synced 2024-12-02 10:23:55 +08:00
Code

Merge remote-tracking branch 'origin/next' into kvm-ppc-next

Browse Source 
Conflicts:
	mm/Kconfig

CMA DMA split and ZSWAP introduction were conflicting, fix up manually.
This commit is contained in:
Alexander Graf 2013-08-29 00:41:59 +02:00
commit bf550fc93d
5488 changed files with 302590 additions and 103607 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

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

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

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

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

58
Documentation/ABI/testing/sysfs-bus-acpi Normal file
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.

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

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

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 Normal file
View File

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

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

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

20
Documentation/ABI/testing/sysfs-devices-online Normal file
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.

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

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

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

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

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>

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

2
Documentation/DocBook/writing_usb_driver.tmpl
View File

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

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 Normal file
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 Normal file
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)

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

24
Documentation/devicetree/bindings/arm/global_timer.txt Normal file
View File

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

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

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

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

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

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:

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

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

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

@ -24,8 +24,11 @@ The three cells in order are:
1. A phandle pointing to the DMA controller.
2. The memory interface (16 most significant bits), the peripheral interface
(16 less significant bits).
3. The peripheral identifier for the hardware handshaking interface. The
identifier can be different for tx and rx.
3. Parameters for the at91 DMA configuration register which are device
dependant:
- bit 7-0: peripheral identifier for the hardware handshaking interface. The
identifier can be different for tx and rx.
- bit 11-8: FIFO configuration. 0 for half FIFO, 1 for ALAP, 1 for ASAP.
Example:

48
Documentation/devicetree/bindings/dma/fsl-imx-dma.txt Normal file
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 Normal file
View File

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

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

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

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

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

47
Documentation/devicetree/bindings/hwmon/g762.txt Normal file
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 Normal file
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 Normal file
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>;
};

91
Documentation/devicetree/bindings/input/ads7846.txt Normal file
View File

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

60
Documentation/devicetree/bindings/input/pxa27x-keypad.txt Normal file
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 Normal file
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 Normal file
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 Normal file
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 Normal file
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>;
};
};

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

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

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

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

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

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

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

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

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

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

18
Documentation/devicetree/bindings/media/sh_mobile_ceu.txt Normal file
View File

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

30
Documentation/devicetree/bindings/metag/meta.txt Normal file
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 Normal file
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,
>;
};

119
Documentation/devicetree/bindings/mfd/max8998.txt Normal file
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 Normal file
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 Normal file
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 Normal file
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 Normal file
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 Normal file
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 Normal file
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 Normal file
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 Normal file
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 Normal file
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 Normal file
View File

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

44
Documentation/devicetree/bindings/power_supply/lp8727_charger.txt Normal file
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 Normal file
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 Normal file
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 Normal file
View File

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

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

@ -1,6 +1,6 @@
* Maxim MAX8997 Voltage and Current Regulator
The Maxim MAX8997 is a multi-function device which includes volatage and
The Maxim MAX8997 is a multi-function device which includes voltage and
current regulators, rtc, charger controller and other sub-blocks. It is
interfaced to the host controller using a i2c interface. Each sub-block is
addressed by the host system using different i2c slave address. This document

72
Documentation/devicetree/bindings/regulator/palmas-pmic.txt Normal file
View File

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

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

@ -1,6 +1,6 @@
* Samsung S5M8767 Voltage and Current Regulator
The Samsung S5M8767 is a multi-function device which includes volatage and
The Samsung S5M8767 is a multi-function device which includes voltage and
current regulators, rtc, charger controller and other sub-blocks. It is
interfaced to the host controller using a i2c interface. Each sub-block is
addressed by the host system using different i2c slave address. This document
@ -103,13 +103,13 @@ Example:
s5m8767,pmic-buck-default-dvs-idx = <0>;
s5m8767,pmic-buck-dvs-gpios = <&gpx0 0 1 0 0>, /* DVS1 */
<&gpx0 1 1 0 0>, /* DVS2 */
<&gpx0 2 1 0 0>; /* DVS3 */
s5m8767,pmic-buck-dvs-gpios = <&gpx0 0 0>, /* DVS1 */
<&gpx0 1 0>, /* DVS2 */
<&gpx0 2 0>; /* DVS3 */
s5m8767,pmic-buck-ds-gpios = <&gpx2 3 1 0 0>, /* SET1 */
<&gpx2 4 1 0 0>, /* SET2 */
<&gpx2 5 1 0 0>; /* SET3 */
s5m8767,pmic-buck-ds-gpios = <&gpx2 3 0>, /* SET1 */
<&gpx2 4 0>, /* SET2 */
<&gpx2 5 0>; /* SET3 */
s5m8767,pmic-buck2-dvs-voltage = <1350000>, <1300000>,
<1250000>, <1200000>,

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