iv/linux
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/sparc

Browse Source 
Merge sparc bug fixes that didn't make it into v3.9 into
sparc-next.

Signed-off-by: David S. Miller <davem@davemloft.net>
This commit is contained in:
David S. Miller 2013-05-04 18:34:13 -07:00
commit 048c9acca9
8536 changed files with 458399 additions and 277374 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

4
CREDITS
View File

@ -761,6 +761,10 @@ S: Northampton
S: NN1 3QT
S: United Kingdom
N: Massimo Dal Zotto
E: dz@debian.org
D: i8k Dell laptop SMM driver
N: Uwe Dannowski
E: Uwe.Dannowski@ira.uka.de
W: http://i30www.ira.uka.de/~dannowsk/

7
Documentation/ABI/testing/sysfs-bus-mei Normal file
View File

@ -0,0 +1,7 @@
What: /sys/bus/mei/devices/.../modalias
Date: March 2013
KernelVersion: 3.10
Contact: Samuel Ortiz <sameo@linux.intel.com>
linux-mei@linux.intel.com
Description: Stores the same MODALIAS value emitted by uevent
Format: mei:<mei device name>

6
Documentation/ABI/testing/sysfs-bus-usb
View File

@ -32,7 +32,7 @@ Date: January 2008
KernelVersion: 2.6.25
Contact: Sarah Sharp <sarah.a.sharp@intel.com>
Description:
If CONFIG_PM and CONFIG_USB_SUSPEND are enabled, then this file
If CONFIG_PM_RUNTIME is enabled then this file
is present. When read, it returns the total time (in msec)
that the USB device has been connected to the machine. This
file is read-only.
@ -45,7 +45,7 @@ Date: January 2008
KernelVersion: 2.6.25
Contact: Sarah Sharp <sarah.a.sharp@intel.com>
Description:
If CONFIG_PM and CONFIG_USB_SUSPEND are enabled, then this file
If CONFIG_PM_RUNTIME is enabled then this file
is present. When read, it returns the total time (in msec)
that the USB device has been active, i.e. not in a suspended
state. This file is read-only.
@ -187,7 +187,7 @@ What: /sys/bus/usb/devices/.../power/usb2_hardware_lpm
Date: September 2011
Contact: Andiry Xu <andiry.xu@amd.com>
Description:
If CONFIG_USB_SUSPEND is set and a USB 2.0 lpm-capable device
If CONFIG_PM_RUNTIME is set and a USB 2.0 lpm-capable device
is plugged in to a xHCI host which support link PM, it will
perform a LPM test; if the test is passed and host supports
USB2 hardware LPM (xHCI 1.0 feature), USB2 hardware LPM will

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

@ -67,6 +67,14 @@ Description:
Defines the penalty which will be applied to an
originator message's tq-field on every hop.
What: /sys/class/net/<mesh_iface>/mesh/network_coding
Date: Nov 2012
Contact: Martin Hundeboll <martin@hundeboll.net>
Description:
Controls whether Network Coding (using some magic
to send fewer wifi packets but still the same
content) is enabled or not.
What: /sys/class/net/<mesh_iface>/mesh/orig_interval
Date: May 2010
Contact: Marek Lindner <lindner_marek@yahoo.de>

44
Documentation/ABI/testing/sysfs-devices-lpss_ltr Normal file
View File

@ -0,0 +1,44 @@
What: /sys/devices/.../lpss_ltr/
Date: March 2013
Contact: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Description:
The /sys/devices/.../lpss_ltr/ directory is only present for
devices included into the Intel Lynxpoint Low Power Subsystem
(LPSS). If present, it contains attributes containing the LTR
mode and the values of LTR registers of the device.
What: /sys/devices/.../lpss_ltr/ltr_mode
Date: March 2013
Contact: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Description:
The /sys/devices/.../lpss_ltr/ltr_mode attribute contains an
integer number (0 or 1) indicating whether or not the devices'
LTR functionality is working in the software mode (1).
This attribute is read-only. If the device's runtime PM status
is not "active", attempts to read from this attribute cause
-EAGAIN to be returned.
What: /sys/devices/.../lpss_ltr/auto_ltr
Date: March 2013
Contact: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Description:
The /sys/devices/.../lpss_ltr/auto_ltr attribute contains the
current value of the device's AUTO_LTR register (raw)
represented as an 8-digit hexadecimal number.
This attribute is read-only. If the device's runtime PM status
is not "active", attempts to read from this attribute cause
-EAGAIN to be returned.
What: /sys/devices/.../lpss_ltr/sw_ltr
Date: March 2013
Contact: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Description:
The /sys/devices/.../lpss_ltr/auto_ltr attribute contains the
current value of the device's SW_LTR register (raw) represented
as an 8-digit hexadecimal number.
This attribute is read-only. If the device's runtime PM status
is not "active", attempts to read from this attribute cause
-EAGAIN to be returned.

13
Documentation/ABI/testing/sysfs-devices-power_resources_wakeup Normal file
View File

@ -0,0 +1,13 @@
What: /sys/devices/.../power_resources_wakeup/
Date: April 2013
Contact: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Description:
The /sys/devices/.../power_resources_wakeup/ directory is only
present for device objects representing ACPI device nodes that
require ACPI power resources for wakeup signaling.
If present, it contains symbolic links to device directories
representing ACPI power resources that need to be turned on for
the given device node to be able to signal wakeup. The names of
the links are the same as the names of the directories they
point to.

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

@ -173,3 +173,15 @@ Description: Processor frequency boosting control
Boosting allows the CPU and the firmware to run at a frequency
beyound it's nominal limit.
More details can be found in Documentation/cpu-freq/boost.txt
What: /sys/devices/system/cpu/cpu#/crash_notes
/sys/devices/system/cpu/cpu#/crash_notes_size
Date: April 2013
Contact: kexec@lists.infradead.org
Description: address and size of the percpu note.
crash_notes: the physical address of the memory that holds the
note of cpu#.
crash_notes_size: size of the note of cpu#.

12
Documentation/ABI/testing/sysfs-driver-hid-roccat-isku
View File

@ -101,7 +101,8 @@ Date: June 2011
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
Description: When written, this file lets one set the backlight intensity for
a specific profile. Profile number is included in written data.
The data has to be 10 bytes long.
The data has to be 10 bytes long for Isku, IskuFX needs 16 bytes
of data.
Before reading this file, control has to be written to select
which profile to read.
Users: http://roccat.sourceforge.net
@ -141,3 +142,12 @@ Description: When written, this file lets one trigger easyshift functionality
The data has to be 16 bytes long.
This file is writeonly.
Users: http://roccat.sourceforge.net
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/isku/roccatisku<minor>/talkfx
Date: February 2013
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
Description: When written, this file lets one trigger temporary color schemes
from the host.
The data has to be 16 bytes long.
This file is writeonly.
Users: http://roccat.sourceforge.net

105
Documentation/ABI/testing/sysfs-driver-hid-roccat-konepure Normal file
View File

@ -0,0 +1,105 @@
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/konepure/roccatkonepure<minor>/actual_profile
Date: December 2012
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
Description: The mouse can store 5 profiles which can be switched by the
press of a button. actual_profile holds number of actual profile.
This value is persistent, so its value determines the profile
that's active when the mouse is powered on next time.
When written, the mouse activates the set profile immediately.
The data has to be 3 bytes long.
The mouse will reject invalid data.
Users: http://roccat.sourceforge.net
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/konepure/roccatkonepure<minor>/control
Date: December 2012
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
Description: When written, this file lets one select which data from which
profile will be read next. The data has to be 3 bytes long.
This file is writeonly.
Users: http://roccat.sourceforge.net
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/konepure/roccatkonepure<minor>/info
Date: December 2012
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
Description: When read, this file returns general data like firmware version.
When written, the device can be reset.
The data is 6 bytes long.
Users: http://roccat.sourceforge.net
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/konepure/roccatkonepure<minor>/macro
Date: December 2012
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
Description: The mouse can store a macro with max 500 key/button strokes
internally.
When written, this file lets one set the sequence for a specific
button for a specific profile. Button and profile numbers are
included in written data. The data has to be 2082 bytes long.
This file is writeonly.
Users: http://roccat.sourceforge.net
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/konepure/roccatkonepure<minor>/profile_buttons
Date: December 2012
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
Description: The mouse can store 5 profiles which can be switched by the
press of a button. A profile is split in settings and buttons.
profile_buttons holds information about button layout.
When written, this file lets one write the respective profile
buttons back to the mouse. The data has to be 59 bytes long.
The mouse will reject invalid data.
Which profile to write is determined by the profile number
contained in the data.
Before reading this file, control has to be written to select
which profile to read.
Users: http://roccat.sourceforge.net
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/konepure/roccatkonepure<minor>/profile_settings
Date: December 2012
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
Description: The mouse can store 5 profiles which can be switched by the
press of a button. A profile is split in settings and buttons.
profile_settings holds information like resolution, sensitivity
and light effects.
When written, this file lets one write the respective profile
settings back to the mouse. The data has to be 31 bytes long.
The mouse will reject invalid data.
Which profile to write is determined by the profile number
contained in the data.
Before reading this file, control has to be written to select
which profile to read.
Users: http://roccat.sourceforge.net
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/konepure/roccatkonepure<minor>/sensor
Date: December 2012
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
Description: The mouse has a tracking- and a distance-control-unit. These
can be activated/deactivated and the lift-off distance can be
set. The data has to be 6 bytes long.
This file is writeonly.
Users: http://roccat.sourceforge.net
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/konepure/roccatkonepure<minor>/talk
Date: December 2012
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
Description: Used to active some easy* functions of the mouse from outside.
The data has to be 16 bytes long.
This file is writeonly.
Users: http://roccat.sourceforge.net
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/konepure/roccatkonepure<minor>/tcu
Date: December 2012
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
Description: When written a calibration process for the tracking control unit
can be initiated/cancelled. Also lets one read/write sensor
registers.
The data has to be 4 bytes long.
Users: http://roccat.sourceforge.net
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/konepure/roccatkonepure<minor>/tcu_image
Date: December 2012
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
Description: When read the mouse returns a 30x30 pixel image of the
sampled underground. This works only in the course of a
calibration process initiated with tcu.
The returned data is 1028 bytes in size.
This file is readonly.
Users: http://roccat.sourceforge.net

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

@ -18,6 +18,32 @@ Description:
yoffset: The number of pixels between the top of the screen
and the top edge of the image.
What: /sys/firmware/acpi/hotplug/
Date: February 2013
Contact: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Description:
There are separate hotplug profiles for different classes of
devices supported by ACPI, such as containers, memory modules,
processors, PCI root bridges etc. A hotplug profile for a given
class of devices is a collection of settings defining the way
that class of devices will be handled by the ACPI core hotplug
code. Those profiles are represented in sysfs as subdirectories
of /sys/firmware/acpi/hotplug/.
The following setting is available to user space for each
hotplug profile:
enabled: If set, the ACPI core will handle notifications of
hotplug events associated with the given class of
devices and will allow those devices to be ejected with
the help of the _EJ0 control method. Unsetting it
effectively disables hotplug for the correspoinding
class of devices.
The value of the above attribute is an integer number: 1 (set)
or 0 (unset). Attempts to write any other values to it will
cause -EINVAL to be returned.
What: /sys/firmware/acpi/interrupts/
Date: February 2008
Contact: Len Brown <lenb@kernel.org>

2
Documentation/DocBook/80211.tmpl
View File

@ -437,7 +437,7 @@
</section>
!Finclude/net/mac80211.h ieee80211_get_buffered_bc
!Finclude/net/mac80211.h ieee80211_beacon_get
!Finclude/net/mac80211.h ieee80211_sta_eosp_irqsafe
!Finclude/net/mac80211.h ieee80211_sta_eosp
!Finclude/net/mac80211.h ieee80211_frame_release_type
!Finclude/net/mac80211.h ieee80211_sta_ps_transition
!Finclude/net/mac80211.h ieee80211_sta_ps_transition_ni

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

@ -227,7 +227,7 @@ X!Isound/sound_firmware.c
<chapter id="uart16x50">
<title>16x50 UART Driver</title>
!Edrivers/tty/serial/serial_core.c
!Edrivers/tty/serial/8250/8250.c
!Edrivers/tty/serial/8250/8250_core.c
</chapter>
<chapter id="fbdev">

52
Documentation/DocBook/media/dvb/dvbproperty.xml
View File

@ -1,6 +1,6 @@
<section id="FE_GET_SET_PROPERTY">
<title><constant>FE_GET_PROPERTY/FE_SET_PROPERTY</constant></title>
<para>This section describes the DVB version 5 extention of the DVB-API, also
<para>This section describes the DVB version 5 extension of the DVB-API, also
called "S2API", as this API were added to provide support for DVB-S2. It was
designed to be able to replace the old frontend API. Yet, the DISEQC and
the capability ioctls weren't implemented yet via the new way.</para>
@ -903,14 +903,12 @@ enum fe_interleaving {
<constant>svalue</constant> is for signed values of the measure (dB measures)
and <constant>uvalue</constant> is for unsigned values (counters, relative scale)</para></listitem>
<listitem><para><constant>scale</constant> - Scale for the value. It can be:</para>
<section id = "fecap-scale-params">
<itemizedlist mark='bullet'>
<itemizedlist mark='bullet' id="fecap-scale-params">
<listitem><para><constant>FE_SCALE_NOT_AVAILABLE</constant> - The parameter is supported by the frontend, but it was not possible to collect it (could be a transitory or permanent condition)</para></listitem>
<listitem><para><constant>FE_SCALE_DECIBEL</constant> - parameter is a signed value, measured in 1/1000 dB</para></listitem>
<listitem><para><constant>FE_SCALE_RELATIVE</constant> - parameter is a unsigned value, where 0 means 0% and 65535 means 100%.</para></listitem>
<listitem><para><constant>FE_SCALE_COUNTER</constant> - parameter is a unsigned value that counts the occurrence of an event, like bit error, block error, or lapsed time.</para></listitem>
</itemizedlist>
</section>
</listitem>
</itemizedlist>
<section id="DTV-STAT-SIGNAL-STRENGTH">
@ -918,9 +916,9 @@ enum fe_interleaving {
<para>Indicates the signal strength level at the analog part of the tuner or of the demod.</para>
<para>Possible scales for this metric are:</para>
<itemizedlist mark='bullet'>
<listitem><constant>FE_SCALE_NOT_AVAILABLE</constant> - it failed to measure it, or the measurement was not complete yet.</listitem>
<listitem><constant>FE_SCALE_DECIBEL</constant> - signal strength is in 0.0001 dBm units, power measured in miliwatts. This value is generally negative.</listitem>
<listitem><constant>FE_SCALE_RELATIVE</constant> - The frontend provides a 0% to 100% measurement for power (actually, 0 to 65535).</listitem>
<listitem><para><constant>FE_SCALE_NOT_AVAILABLE</constant> - it failed to measure it, or the measurement was not complete yet.</para></listitem>
<listitem><para><constant>FE_SCALE_DECIBEL</constant> - signal strength is in 0.0001 dBm units, power measured in miliwatts. This value is generally negative.</para></listitem>
<listitem><para><constant>FE_SCALE_RELATIVE</constant> - The frontend provides a 0% to 100% measurement for power (actually, 0 to 65535).</para></listitem>
</itemizedlist>
</section>
<section id="DTV-STAT-CNR">
@ -928,9 +926,9 @@ enum fe_interleaving {
<para>Indicates the Signal to Noise ratio for the main carrier.</para>
<para>Possible scales for this metric are:</para>
<itemizedlist mark='bullet'>
<listitem><constant>FE_SCALE_NOT_AVAILABLE</constant> - it failed to measure it, or the measurement was not complete yet.</listitem>
<listitem><constant>FE_SCALE_DECIBEL</constant> - Signal/Noise ratio is in 0.0001 dB units.</listitem>
<listitem><constant>FE_SCALE_RELATIVE</constant> - The frontend provides a 0% to 100% measurement for Signal/Noise (actually, 0 to 65535).</listitem>
<listitem><para><constant>FE_SCALE_NOT_AVAILABLE</constant> - it failed to measure it, or the measurement was not complete yet.</para></listitem>
<listitem><para><constant>FE_SCALE_DECIBEL</constant> - Signal/Noise ratio is in 0.0001 dB units.</para></listitem>
<listitem><para><constant>FE_SCALE_RELATIVE</constant> - The frontend provides a 0% to 100% measurement for Signal/Noise (actually, 0 to 65535).</para></listitem>
</itemizedlist>
</section>
<section id="DTV-STAT-PRE-ERROR-BIT-COUNT">
@ -943,8 +941,8 @@ enum fe_interleaving {
The frontend may reset it when a channel/transponder is tuned.</para>
<para>Possible scales for this metric are:</para>
<itemizedlist mark='bullet'>
<listitem><constant>FE_SCALE_NOT_AVAILABLE</constant> - it failed to measure it, or the measurement was not complete yet.</listitem>
<listitem><constant>FE_SCALE_COUNTER</constant> - Number of error bits counted before the inner coding.</listitem>
<listitem><para><constant>FE_SCALE_NOT_AVAILABLE</constant> - it failed to measure it, or the measurement was not complete yet.</para></listitem>
<listitem><para><constant>FE_SCALE_COUNTER</constant> - Number of error bits counted before the inner coding.</para></listitem>
</itemizedlist>
</section>
<section id="DTV-STAT-PRE-TOTAL-BIT-COUNT">
@ -952,14 +950,14 @@ enum fe_interleaving {
<para>Measures the amount of bits received before the inner code block, during the same period as
<link linkend="DTV-STAT-PRE-ERROR-BIT-COUNT"><constant>DTV_STAT_PRE_ERROR_BIT_COUNT</constant></link> measurement was taken.</para>
<para>It should be noticed that this measurement can be smaller than the total amount of bits on the transport stream,
as the frontend may need to manually restart the measurement, loosing some data between each measurement interval.</para>
as the frontend may need to manually restart the measurement, losing some data between each measurement interval.</para>
<para>This measurement is monotonically increased, as the frontend gets more bit count measurements.
The frontend may reset it when a channel/transponder is tuned.</para>
<para>Possible scales for this metric are:</para>
<itemizedlist mark='bullet'>
<listitem><constant>FE_SCALE_NOT_AVAILABLE</constant> - it failed to measure it, or the measurement was not complete yet.</listitem>
<listitem><constant>FE_SCALE_COUNTER</constant> - Number of bits counted while measuring
<link linkend="DTV-STAT-PRE-ERROR-BIT-COUNT"><constant>DTV_STAT_PRE_ERROR_BIT_COUNT</constant></link>.</listitem>
<listitem><para><constant>FE_SCALE_NOT_AVAILABLE</constant> - it failed to measure it, or the measurement was not complete yet.</para></listitem>
<listitem><para><constant>FE_SCALE_COUNTER</constant> - Number of bits counted while measuring
<link linkend="DTV-STAT-PRE-ERROR-BIT-COUNT"><constant>DTV_STAT_PRE_ERROR_BIT_COUNT</constant></link>.</para></listitem>
</itemizedlist>
</section>
<section id="DTV-STAT-POST-ERROR-BIT-COUNT">
@ -972,8 +970,8 @@ enum fe_interleaving {
The frontend may reset it when a channel/transponder is tuned.</para>
<para>Possible scales for this metric are:</para>
<itemizedlist mark='bullet'>
<listitem><constant>FE_SCALE_NOT_AVAILABLE</constant> - it failed to measure it, or the measurement was not complete yet.</listitem>
<listitem><constant>FE_SCALE_COUNTER</constant> - Number of error bits counted after the inner coding.</listitem>
<listitem><para><constant>FE_SCALE_NOT_AVAILABLE</constant> - it failed to measure it, or the measurement was not complete yet.</para></listitem>
<listitem><para><constant>FE_SCALE_COUNTER</constant> - Number of error bits counted after the inner coding.</para></listitem>
</itemizedlist>
</section>
<section id="DTV-STAT-POST-TOTAL-BIT-COUNT">
@ -981,14 +979,14 @@ enum fe_interleaving {
<para>Measures the amount of bits received after the inner coding, during the same period as
<link linkend="DTV-STAT-POST-ERROR-BIT-COUNT"><constant>DTV_STAT_POST_ERROR_BIT_COUNT</constant></link> measurement was taken.</para>
<para>It should be noticed that this measurement can be smaller than the total amount of bits on the transport stream,
as the frontend may need to manually restart the measurement, loosing some data between each measurement interval.</para>
as the frontend may need to manually restart the measurement, losing some data between each measurement interval.</para>
<para>This measurement is monotonically increased, as the frontend gets more bit count measurements.
The frontend may reset it when a channel/transponder is tuned.</para>
<para>Possible scales for this metric are:</para>
<itemizedlist mark='bullet'>
<listitem><constant>FE_SCALE_NOT_AVAILABLE</constant> - it failed to measure it, or the measurement was not complete yet.</listitem>
<listitem><constant>FE_SCALE_COUNTER</constant> - Number of bits counted while measuring
<link linkend="DTV-STAT-POST-ERROR-BIT-COUNT"><constant>DTV_STAT_POST_ERROR_BIT_COUNT</constant></link>.</listitem>
<listitem><para><constant>FE_SCALE_NOT_AVAILABLE</constant> - it failed to measure it, or the measurement was not complete yet.</para></listitem>
<listitem><para><constant>FE_SCALE_COUNTER</constant> - Number of bits counted while measuring
<link linkend="DTV-STAT-POST-ERROR-BIT-COUNT"><constant>DTV_STAT_POST_ERROR_BIT_COUNT</constant></link>.</para></listitem>
</itemizedlist>
</section>
<section id="DTV-STAT-ERROR-BLOCK-COUNT">
@ -998,8 +996,8 @@ enum fe_interleaving {
The frontend may reset it when a channel/transponder is tuned.</para>
<para>Possible scales for this metric are:</para>
<itemizedlist mark='bullet'>
<listitem><constant>FE_SCALE_NOT_AVAILABLE</constant> - it failed to measure it, or the measurement was not complete yet.</listitem>
<listitem><constant>FE_SCALE_COUNTER</constant> - Number of error blocks counted after the outer coding.</listitem>
<listitem><para><constant>FE_SCALE_NOT_AVAILABLE</constant> - it failed to measure it, or the measurement was not complete yet.</para></listitem>
<listitem><para><constant>FE_SCALE_COUNTER</constant> - Number of error blocks counted after the outer coding.</para></listitem>
</itemizedlist>
</section>
<section id="DTV-STAT-TOTAL-BLOCK-COUNT">
@ -1011,9 +1009,9 @@ enum fe_interleaving {
by <link linkend="DTV-STAT-TOTAL-BLOCK-COUNT"><constant>DTV-STAT-TOTAL-BLOCK-COUNT</constant></link>.</para>
<para>Possible scales for this metric are:</para>
<itemizedlist mark='bullet'>
<listitem><constant>FE_SCALE_NOT_AVAILABLE</constant> - it failed to measure it, or the measurement was not complete yet.</listitem>
<listitem><constant>FE_SCALE_COUNTER</constant> - Number of blocks counted while measuring
<link linkend="DTV-STAT-ERROR-BLOCK-COUNT"><constant>DTV_STAT_ERROR_BLOCK_COUNT</constant></link>.</listitem>
<listitem><para><constant>FE_SCALE_NOT_AVAILABLE</constant> - it failed to measure it, or the measurement was not complete yet.</para></listitem>
<listitem><para><constant>FE_SCALE_COUNTER</constant> - Number of blocks counted while measuring
<link linkend="DTV-STAT-ERROR-BLOCK-COUNT"><constant>DTV_STAT_ERROR_BLOCK_COUNT</constant></link>.</para></listitem>
</itemizedlist>
</section>
</section>

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

@ -749,15 +749,6 @@ polarities, frontporch, backporch etc. The <filename>linux/v4l2-dv-timings.h</fi
header can be used to get the timings of the formats in the <xref linkend="cea861" /> and
<xref linkend="vesadmt" /> standards.
</para>
</listitem>
<listitem>
<para>DV Presets: Digital Video (DV) presets (<emphasis role="bold">deprecated</emphasis>).
These are IDs representing a
video timing at the input/output. Presets are pre-defined timings implemented
by the hardware according to video standards. A __u32 data type is used to represent
a preset unlike the bit mask that is used in &v4l2-std-id; allowing future extensions
to support as many different presets as needed. This API is deprecated in favor of the DV Timings
API.</para>
</listitem>
</itemizedlist>
<para>To enumerate and query the attributes of the DV timings supported by a device,
@ -766,11 +757,6 @@ API.</para>
&VIDIOC-S-DV-TIMINGS; ioctl and to get current DV timings they use the
&VIDIOC-G-DV-TIMINGS; ioctl. To detect the DV timings as seen by the video receiver applications
use the &VIDIOC-QUERY-DV-TIMINGS; ioctl.</para>
<para>To enumerate and query the attributes of DV presets supported by a device,
applications use the &VIDIOC-ENUM-DV-PRESETS; ioctl. To get the current DV preset,
applications use the &VIDIOC-G-DV-PRESET; ioctl and to set a preset they use the
&VIDIOC-S-DV-PRESET; ioctl. To detect the preset as seen by the video receiver applications
use the &VIDIOC-QUERY-DV-PRESET; ioctl.</para>
<para>Applications can make use of the <xref linkend="input-capabilities" /> and
<xref linkend="output-capabilities"/> flags to decide what ioctls are available to set the
video timings for the device.</para>

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

@ -2310,6 +2310,9 @@ more information.</para>
<listitem>
<para>Added FM Modulator (FM TX) Extended Control Class: <constant>V4L2_CTRL_CLASS_FM_TX</constant> and their Control IDs.</para>
</listitem>
<listitem>
<para>Added FM Receiver (FM RX) Extended Control Class: <constant>V4L2_CTRL_CLASS_FM_RX</constant> and their Control IDs.</para>
</listitem>
<listitem>
<para>Added Remote Controller chapter, describing the default Remote Controller mapping for media devices.</para>
</listitem>
@ -2493,6 +2496,23 @@ that used it. It was originally scheduled for removal in 2.6.35.
</orderedlist>
</section>
<section>
<title>V4L2 in Linux 3.10</title>
<orderedlist>
<listitem>
<para>Removed obsolete and unused DV_PRESET ioctls
VIDIOC_G_DV_PRESET, VIDIOC_S_DV_PRESET, VIDIOC_QUERY_DV_PRESET and
VIDIOC_ENUM_DV_PRESET. Remove the related v4l2_input/output capability
flags V4L2_IN_CAP_PRESETS and V4L2_OUT_CAP_PRESETS.
</para>
</listitem>
<listitem>
<para>Added new debugging ioctl &VIDIOC-DBG-G-CHIP-INFO;.
</para>
</listitem>
</orderedlist>
</section>
<section id="other">
<title>Relation of V4L2 to other Linux multimedia APIs</title>
@ -2625,8 +2645,8 @@ interfaces and should not be implemented in new drivers.</para>
<xref linkend="extended-controls" />.</para>
</listitem>
<listitem>
<para>&VIDIOC-G-DV-PRESET;, &VIDIOC-S-DV-PRESET;, &VIDIOC-ENUM-DV-PRESETS; and
&VIDIOC-QUERY-DV-PRESET; ioctls. Use the DV Timings API (<xref linkend="dv-timings" />).</para>
<para>VIDIOC_G_DV_PRESET, VIDIOC_S_DV_PRESET, VIDIOC_ENUM_DV_PRESETS and
VIDIOC_QUERY_DV_PRESET ioctls. Use the DV Timings API (<xref linkend="dv-timings" />).</para>
</listitem>
<listitem>
<para><constant>VIDIOC_SUBDEV_G_CROP</constant> and

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

@ -2299,6 +2299,12 @@ Possible values are:</entry>
</entrytbl>
</row>
<row><entry></entry></row>
<row>
<entry spanname="id"><constant>V4L2_CID_MPEG_VIDEO_REPEAT_SEQ_HEADER</constant>&nbsp;</entry>
<entry>boolean</entry>
</row><row><entry spanname="descr">Repeat the video sequence headers. Repeating these
headers makes random access to the video stream easier. Applicable to the MPEG1, 2 and 4 encoder.</entry>
</row>
<row>
<entry spanname="id"><constant>V4L2_CID_MPEG_VIDEO_DECODER_MPEG4_DEBLOCK_FILTER</constant>&nbsp;</entry>
<entry>boolean</entry>
@ -3136,6 +3142,13 @@ giving priority to the center of the metered area.</entry>
<entry><constant>V4L2_EXPOSURE_METERING_SPOT</constant>&nbsp;</entry>
<entry>Measure only very small area at the center of the frame.</entry>
</row>
<row>
<entry><constant>V4L2_EXPOSURE_METERING_MATRIX</constant>&nbsp;</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>
</row>
</tbody>
</entrytbl>
</row>
@ -3848,7 +3861,7 @@ in Hz. The range and step are driver-specific.</entry>
</row>
<row>
<entry spanname="id"><constant>V4L2_CID_TUNE_PREEMPHASIS</constant>&nbsp;</entry>
<entry>integer</entry>
<entry>enum v4l2_preemphasis</entry>
</row>
<row id="v4l2-preemphasis"><entry spanname="descr">Configures the pre-emphasis value for broadcasting.
A pre-emphasis filter is applied to the broadcast to accentuate the high audio frequencies.
@ -4687,4 +4700,76 @@ interface and may change in the future.</para>
</table>
</section>
<section id="fm-rx-controls">
<title>FM Receiver Control Reference</title>
<para>The FM Receiver (FM_RX) class includes controls for common features of
FM Reception capable devices.</para>
<table pgwide="1" frame="none" id="fm-rx-control-id">
<title>FM_RX Control IDs</title>
<tgroup cols="4">
<colspec colname="c1" colwidth="1*" />
<colspec colname="c2" colwidth="6*" />
<colspec colname="c3" colwidth="2*" />
<colspec colname="c4" colwidth="6*" />
<spanspec namest="c1" nameend="c2" spanname="id" />
<spanspec namest="c2" nameend="c4" spanname="descr" />
<thead>
<row>
<entry spanname="id" align="left">ID</entry>
<entry align="left">Type</entry>
</row><row rowsep="1"><entry spanname="descr" align="left">Description</entry>
</row>
</thead>
<tbody valign="top">
<row><entry></entry></row>
<row>
<entry spanname="id"><constant>V4L2_CID_FM_RX_CLASS</constant>&nbsp;</entry>
<entry>class</entry>
</row><row><entry spanname="descr">The FM_RX class
descriptor. Calling &VIDIOC-QUERYCTRL; for this control will return a
description of this control class.</entry>
</row>
<row>
<entry spanname="id"><constant>V4L2_CID_RDS_RECEPTION</constant>&nbsp;</entry>
<entry>boolean</entry>
</row><row><entry spanname="descr">Enables/disables RDS
reception by the radio tuner</entry>
</row>
<row>
<entry spanname="id"><constant>V4L2_CID_TUNE_DEEMPHASIS</constant>&nbsp;</entry>
<entry>enum v4l2_deemphasis</entry>
</row>
<row id="v4l2-deemphasis"><entry spanname="descr">Configures the de-emphasis value for reception.
A de-emphasis filter is applied to the broadcast to accentuate the high audio frequencies.
Depending on the region, a time constant of either 50 or 75 useconds is used. The enum&nbsp;v4l2_deemphasis
defines possible values for de-emphasis. Here they are:</entry>
</row><row>
<entrytbl spanname="descr" cols="2">
<tbody valign="top">
<row>
<entry><constant>V4L2_DEEMPHASIS_DISABLED</constant>&nbsp;</entry>
<entry>No de-emphasis is applied.</entry>
</row>
<row>
<entry><constant>V4L2_DEEMPHASIS_50_uS</constant>&nbsp;</entry>
<entry>A de-emphasis of 50 uS is used.</entry>
</row>
<row>
<entry><constant>V4L2_DEEMPHASIS_75_uS</constant>&nbsp;</entry>
<entry>A de-emphasis of 75 uS is used.</entry>
</row>
</tbody>
</entrytbl>
</row>
<row><entry></entry></row>
</tbody>
</tgroup>
</table>
</section>
</section>

6
Documentation/DocBook/media/v4l/io.xml
View File

@ -1145,6 +1145,12 @@ in which case caches have not been used.</entry>
same clock outside V4L2, use
<function>clock_gettime(2)</function> .</entry>
</row>
<row>
<entry><constant>V4L2_BUF_FLAG_TIMESTAMP_COPY</constant></entry>
<entry>0x4000</entry>
<entry>The CAPTURE buffer timestamp has been taken from the
corresponding OUTPUT buffer. This flag applies only to mem2mem devices.</entry>
</row>
</tbody>
</tgroup>
</table>

10
Documentation/DocBook/media/v4l/media-ioc-enum-entities.xml
View File

@ -272,6 +272,16 @@
<entry><constant>MEDIA_ENT_T_V4L2_SUBDEV_LENS</constant></entry>
<entry>Lens controller</entry>
</row>
<row>
<entry><constant>MEDIA_ENT_T_V4L2_SUBDEV_DECODER</constant></entry>
<entry>Video decoder, the basic function of the video decoder is to
accept analogue video from a wide variety of sources such as
broadcast, DVD players, cameras and video cassette recorders, in
either NTSC, PAL or HD format and still occasionally SECAM, separate
it into its component parts, luminance and chrominance, and output
it in some digital video standard, with appropriate embedded timing
signals.</entry>
</row>
</tbody>
</tgroup>
</table>

206
Documentation/DocBook/media/v4l/subdev-formats.xml
View File

@ -93,19 +93,35 @@
<table pgwide="0" frame="none" id="v4l2-mbus-pixelcode-rgb">
<title>RGB formats</title>
<tgroup cols="11">
<tgroup cols="27">
<colspec colname="id" align="left" />
<colspec colname="code" align="center"/>
<colspec colname="bit" />
<colspec colnum="4" colname="b07" align="center" />
<colspec colnum="5" colname="b06" align="center" />
<colspec colnum="6" colname="b05" align="center" />
<colspec colnum="7" colname="b04" align="center" />
<colspec colnum="8" colname="b03" align="center" />
<colspec colnum="9" colname="b02" align="center" />
<colspec colnum="10" colname="b01" align="center" />
<colspec colnum="11" colname="b00" align="center" />
<spanspec namest="b07" nameend="b00" spanname="b0" />
<colspec colnum="4" colname="b23" align="center" />
<colspec colnum="5" colname="b22" align="center" />
<colspec colnum="6" colname="b21" align="center" />
<colspec colnum="7" colname="b20" align="center" />
<colspec colnum="8" colname="b19" align="center" />
<colspec colnum="9" colname="b18" align="center" />
<colspec colnum="10" colname="b17" align="center" />
<colspec colnum="11" colname="b16" align="center" />
<colspec colnum="12" colname="b15" align="center" />
<colspec colnum="13" colname="b14" align="center" />
<colspec colnum="14" colname="b13" align="center" />
<colspec colnum="15" colname="b12" align="center" />
<colspec colnum="16" colname="b11" align="center" />
<colspec colnum="17" colname="b10" align="center" />
<colspec colnum="18" colname="b09" align="center" />
<colspec colnum="19" colname="b08" align="center" />
<colspec colnum="20" colname="b07" align="center" />
<colspec colnum="21" colname="b06" align="center" />
<colspec colnum="22" colname="b05" align="center" />
<colspec colnum="23" colname="b04" align="center" />
<colspec colnum="24" colname="b03" align="center" />
<colspec colnum="25" colname="b02" align="center" />
<colspec colnum="26" colname="b01" align="center" />
<colspec colnum="27" colname="b00" align="center" />
<spanspec namest="b23" nameend="b00" spanname="b0" />
<thead>
<row>
<entry>Identifier</entry>
@ -117,6 +133,22 @@
<entry></entry>
<entry></entry>
<entry>Bit</entry>
<entry>23</entry>
<entry>22</entry>
<entry>21</entry>
<entry>20</entry>
<entry>19</entry>
<entry>18</entry>
<entry>17</entry>
<entry>16</entry>
<entry>15</entry>
<entry>14</entry>
<entry>13</entry>
<entry>12</entry>
<entry>11</entry>
<entry>10</entry>
<entry>9</entry>
<entry>8</entry>
<entry>7</entry>
<entry>6</entry>
<entry>5</entry>
@ -132,6 +164,7 @@
<entry>V4L2_MBUS_FMT_RGB444_2X8_PADHI_BE</entry>
<entry>0x1001</entry>
<entry></entry>
&dash-ent-16;
<entry>0</entry>
<entry>0</entry>
<entry>0</entry>
@ -145,6 +178,7 @@
<entry></entry>
<entry></entry>
<entry></entry>
&dash-ent-16;
<entry>g<subscript>3</subscript></entry>
<entry>g<subscript>2</subscript></entry>
<entry>g<subscript>1</subscript></entry>
@ -158,6 +192,7 @@
<entry>V4L2_MBUS_FMT_RGB444_2X8_PADHI_LE</entry>
<entry>0x1002</entry>
<entry></entry>
&dash-ent-16;
<entry>g<subscript>3</subscript></entry>
<entry>g<subscript>2</subscript></entry>
<entry>g<subscript>1</subscript></entry>
@ -171,6 +206,7 @@
<entry></entry>
<entry></entry>
<entry></entry>
&dash-ent-16;
<entry>0</entry>
<entry>0</entry>
<entry>0</entry>
@ -184,6 +220,7 @@
<entry>V4L2_MBUS_FMT_RGB555_2X8_PADHI_BE</entry>
<entry>0x1003</entry>
<entry></entry>
&dash-ent-16;
<entry>0</entry>
<entry>r<subscript>4</subscript></entry>
<entry>r<subscript>3</subscript></entry>
@ -197,6 +234,7 @@
<entry></entry>
<entry></entry>
<entry></entry>
&dash-ent-16;
<entry>g<subscript>2</subscript></entry>
<entry>g<subscript>1</subscript></entry>
<entry>g<subscript>0</subscript></entry>
@ -210,6 +248,7 @@
<entry>V4L2_MBUS_FMT_RGB555_2X8_PADHI_LE</entry>
<entry>0x1004</entry>
<entry></entry>
&dash-ent-16;
<entry>g<subscript>2</subscript></entry>
<entry>g<subscript>1</subscript></entry>
<entry>g<subscript>0</subscript></entry>
@ -223,6 +262,7 @@
<entry></entry>
<entry></entry>
<entry></entry>
&dash-ent-16;
<entry>0</entry>
<entry>r<subscript>4</subscript></entry>
<entry>r<subscript>3</subscript></entry>
@ -236,6 +276,7 @@
<entry>V4L2_MBUS_FMT_BGR565_2X8_BE</entry>
<entry>0x1005</entry>
<entry></entry>
&dash-ent-16;
<entry>b<subscript>4</subscript></entry>
<entry>b<subscript>3</subscript></entry>
<entry>b<subscript>2</subscript></entry>
@ -249,6 +290,7 @@
<entry></entry>
<entry></entry>
<entry></entry>
&dash-ent-16;
<entry>g<subscript>2</subscript></entry>
<entry>g<subscript>1</subscript></entry>
<entry>g<subscript>0</subscript></entry>
@ -262,6 +304,7 @@
<entry>V4L2_MBUS_FMT_BGR565_2X8_LE</entry>
<entry>0x1006</entry>
<entry></entry>
&dash-ent-16;
<entry>g<subscript>2</subscript></entry>
<entry>g<subscript>1</subscript></entry>
<entry>g<subscript>0</subscript></entry>
@ -275,6 +318,7 @@
<entry></entry>
<entry></entry>
<entry></entry>
&dash-ent-16;
<entry>b<subscript>4</subscript></entry>
<entry>b<subscript>3</subscript></entry>
<entry>b<subscript>2</subscript></entry>
@ -288,6 +332,7 @@
<entry>V4L2_MBUS_FMT_RGB565_2X8_BE</entry>
<entry>0x1007</entry>
<entry></entry>
&dash-ent-16;
<entry>r<subscript>4</subscript></entry>
<entry>r<subscript>3</subscript></entry>
<entry>r<subscript>2</subscript></entry>
@ -301,6 +346,7 @@
<entry></entry>
<entry></entry>
<entry></entry>
&dash-ent-16;
<entry>g<subscript>2</subscript></entry>
<entry>g<subscript>1</subscript></entry>
<entry>g<subscript>0</subscript></entry>
@ -314,6 +360,7 @@
<entry>V4L2_MBUS_FMT_RGB565_2X8_LE</entry>
<entry>0x1008</entry>
<entry></entry>
&dash-ent-16;
<entry>g<subscript>2</subscript></entry>
<entry>g<subscript>1</subscript></entry>
<entry>g<subscript>0</subscript></entry>
@ -327,6 +374,7 @@
<entry></entry>
<entry></entry>
<entry></entry>
&dash-ent-16;
<entry>r<subscript>4</subscript></entry>
<entry>r<subscript>3</subscript></entry>
<entry>r<subscript>2</subscript></entry>
@ -336,6 +384,144 @@
<entry>g<subscript>4</subscript></entry>
<entry>g<subscript>3</subscript></entry>
</row>
<row id="V4L2-MBUS-FMT-RGB666-1X18">
<entry>V4L2_MBUS_FMT_RGB666_1X18</entry>
<entry>0x1009</entry>
<entry></entry>
<entry>-</entry>
<entry>-</entry>
<entry>-</entry>
<entry>-</entry>
<entry>-</entry>
<entry>-</entry>
<entry>r<subscript>5</subscript></entry>
<entry>r<subscript>4</subscript></entry>
<entry>r<subscript>3</subscript></entry>
<entry>r<subscript>2</subscript></entry>
<entry>r<subscript>1</subscript></entry>
<entry>r<subscript>0</subscript></entry>
<entry>g<subscript>5</subscript></entry>
<entry>g<subscript>4</subscript></entry>
<entry>g<subscript>3</subscript></entry>
<entry>g<subscript>2</subscript></entry>
<entry>g<subscript>1</subscript></entry>
<entry>g<subscript>0</subscript></entry>
<entry>b<subscript>5</subscript></entry>
<entry>b<subscript>4</subscript></entry>
<entry>b<subscript>3</subscript></entry>
<entry>b<subscript>2</subscript></entry>
<entry>b<subscript>1</subscript></entry>
<entry>b<subscript>0</subscript></entry>
</row>
<row id="V4L2-MBUS-FMT-RGB888-1X24">
<entry>V4L2_MBUS_FMT_RGB888_1X24</entry>
<entry>0x100a</entry>
<entry></entry>
<entry>r<subscript>7</subscript></entry>
<entry>r<subscript>6</subscript></entry>
<entry>r<subscript>5</subscript></entry>
<entry>r<subscript>4</subscript></entry>
<entry>r<subscript>3</subscript></entry>
<entry>r<subscript>2</subscript></entry>
<entry>r<subscript>1</subscript></entry>
<entry>r<subscript>0</subscript></entry>
<entry>g<subscript>7</subscript></entry>
<entry>g<subscript>6</subscript></entry>
<entry>g<subscript>5</subscript></entry>
<entry>g<subscript>4</subscript></entry>
<entry>g<subscript>3</subscript></entry>
<entry>g<subscript>2</subscript></entry>
<entry>g<subscript>1</subscript></entry>
<entry>g<subscript>0</subscript></entry>
<entry>b<subscript>7</subscript></entry>
<entry>b<subscript>6</subscript></entry>
<entry>b<subscript>5</subscript></entry>
<entry>b<subscript>4</subscript></entry>
<entry>b<subscript>3</subscript></entry>
<entry>b<subscript>2</subscript></entry>
<entry>b<subscript>1</subscript></entry>
<entry>b<subscript>0</subscript></entry>
</row>
<row id="V4L2-MBUS-FMT-RGB888-2X12-BE">
<entry>V4L2_MBUS_FMT_RGB888_2X12_BE</entry>
<entry>0x100b</entry>
<entry></entry>
&dash-ent-10;
<entry>-</entry>
<entry>-</entry>
<entry>r<subscript>7</subscript></entry>
<entry>r<subscript>6</subscript></entry>
<entry>r<subscript>5</subscript></entry>
<entry>r<subscript>4</subscript></entry>
<entry>r<subscript>3</subscript></entry>
<entry>r<subscript>2</subscript></entry>
<entry>r<subscript>1</subscript></entry>
<entry>r<subscript>0</subscript></entry>
<entry>g<subscript>7</subscript></entry>
<entry>g<subscript>6</subscript></entry>
<entry>g<subscript>5</subscript></entry>
<entry>g<subscript>4</subscript></entry>
</row>
<row>
<entry></entry>
<entry></entry>
<entry></entry>
&dash-ent-10;
<entry>-</entry>
<entry>-</entry>
<entry>g<subscript>3</subscript></entry>
<entry>g<subscript>2</subscript></entry>
<entry>g<subscript>1</subscript></entry>
<entry>g<subscript>0</subscript></entry>
<entry>b<subscript>7</subscript></entry>
<entry>b<subscript>6</subscript></entry>
<entry>b<subscript>5</subscript></entry>
<entry>b<subscript>4</subscript></entry>
<entry>b<subscript>3</subscript></entry>
<entry>b<subscript>2</subscript></entry>
<entry>b<subscript>1</subscript></entry>
<entry>b<subscript>0</subscript></entry>
</row>
<row id="V4L2-MBUS-FMT-RGB888-2X12-LE">
<entry>V4L2_MBUS_FMT_RGB888_2X12_LE</entry>
<entry>0x100c</entry>
<entry></entry>
&dash-ent-10;
<entry>-</entry>
<entry>-</entry>
<entry>g<subscript>3</subscript></entry>
<entry>g<subscript>2</subscript></entry>
<entry>g<subscript>1</subscript></entry>
<entry>g<subscript>0</subscript></entry>
<entry>b<subscript>7</subscript></entry>
<entry>b<subscript>6</subscript></entry>
<entry>b<subscript>5</subscript></entry>
<entry>b<subscript>4</subscript></entry>
<entry>b<subscript>3</subscript></entry>
<entry>b<subscript>2</subscript></entry>
<entry>b<subscript>1</subscript></entry>
<entry>b<subscript>0</subscript></entry>
</row>
<row>
<entry></entry>
<entry></entry>
<entry></entry>
&dash-ent-10;
<entry>-</entry>
<entry>-</entry>
<entry>r<subscript>7</subscript></entry>
<entry>r<subscript>6</subscript></entry>
<entry>r<subscript>5</subscript></entry>
<entry>r<subscript>4</subscript></entry>
<entry>r<subscript>3</subscript></entry>
<entry>r<subscript>2</subscript></entry>
<entry>r<subscript>1</subscript></entry>
<entry>r<subscript>0</subscript></entry>
<entry>g<subscript>7</subscript></entry>
<entry>g<subscript>6</subscript></entry>
<entry>g<subscript>5</subscript></entry>
<entry>g<subscript>4</subscript></entry>
</row>
</tbody>
</tgroup>
</table>

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

@ -124,6 +124,7 @@ Remote Controller chapter.</contrib>
<year>2010</year>
<year>2011</year>
<year>2012</year>
<year>2013</year>
<holder>Bill Dirks, Michael H. Schimek, Hans Verkuil, Martin
Rubli, Andy Walls, Muralidharan Karicheri, Mauro Carvalho Chehab,
Pawel Osciak</holder>
@ -139,13 +140,23 @@ 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.10</revnumber>
<date>2013-03-25</date>
<authorinitials>hv</authorinitials>
<revremark>Remove obsolete and unused DV_PRESET ioctls:
VIDIOC_G_DV_PRESET, VIDIOC_S_DV_PRESET, VIDIOC_QUERY_DV_PRESET and
VIDIOC_ENUM_DV_PRESET. Remove the related v4l2_input/output capability
flags V4L2_IN_CAP_PRESETS and V4L2_OUT_CAP_PRESETS. Added VIDIOC_DBG_G_CHIP_INFO.
</revremark>
</revision>
<revision>
<revnumber>3.9</revnumber>
<date>2012-12-03</date>
<authorinitials>sa, sn</authorinitials>
<revremark>Added timestamp types to v4l2_buffer.
Added <constant>V4L2_EVENT_CTRL_CH_RANGE</constant> control
event changes flag, see <xref linkend="changes-flags"/>.
Added V4L2_EVENT_CTRL_CH_RANGE control event changes flag.
</revremark>
</revision>
@ -537,6 +548,7 @@ and discussions on the V4L mailing list.</revremark>
&sub-create-bufs;
&sub-cropcap;
&sub-dbg-g-chip-ident;
&sub-dbg-g-chip-info;
&sub-dbg-g-register;
&sub-decoder-cmd;
&sub-dqevent;
@ -544,7 +556,6 @@ and discussions on the V4L mailing list.</revremark>
&sub-encoder-cmd;
&sub-enumaudio;
&sub-enumaudioout;
&sub-enum-dv-presets;
&sub-enum-dv-timings;
&sub-enum-fmt;
&sub-enum-framesizes;
@ -558,7 +569,6 @@ and discussions on the V4L mailing list.</revremark>
&sub-g-audioout;
&sub-g-crop;
&sub-g-ctrl;
&sub-g-dv-preset;
&sub-g-dv-timings;
&sub-g-enc-index;
&sub-g-ext-ctrls;
@ -582,7 +592,6 @@ and discussions on the V4L mailing list.</revremark>
&sub-querybuf;
&sub-querycap;
&sub-queryctrl;
&sub-query-dv-preset;
&sub-query-dv-timings;
&sub-querystd;
&sub-reqbufs;

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

@ -200,10 +200,10 @@ the values from <xref linkend="chip-ids" />.</entry>
&cs-def;
<tbody valign="top">
<row>
<entry><constant>V4L2_CHIP_MATCH_HOST</constant></entry>
<entry><constant>V4L2_CHIP_MATCH_BRIDGE</constant></entry>
<entry>0</entry>
<entry>Match the nth chip on the card, zero for the
host chip. Does not match &i2c; chips.</entry>
bridge chip. Does not match sub-devices.</entry>
</row>
<row>
<entry><constant>V4L2_CHIP_MATCH_I2C_DRIVER</constant></entry>
@ -220,6 +220,11 @@ the values from <xref linkend="chip-ids" />.</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>

223
Documentation/DocBook/media/v4l/vidioc-dbg-g-chip-info.xml Normal file
View File

@ -0,0 +1,223 @@
<refentry id="vidioc-dbg-g-chip-info">
<refmeta>
<refentrytitle>ioctl VIDIOC_DBG_G_CHIP_INFO</refentrytitle>
&manvol;
</refmeta>
<refnamediv>
<refname>VIDIOC_DBG_G_CHIP_INFO</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_info
*<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_INFO</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>Additionally the Linux kernel must be compiled with the
<constant>CONFIG_VIDEO_ADV_DEBUG</constant> option to enable this ioctl.</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-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>
<para>When <structfield>match.type</structfield> is
<constant>V4L2_CHIP_MATCH_BRIDGE</constant>,
<structfield>match.addr</structfield> selects the nth bridge '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_INFO</constant> fails with an &EINVAL;.
The number zero always selects the bridge chip itself, &eg; the chip
connected to the PCI or USB bus. Non-zero numbers identify specific
parts of the bridge chip such as an AC97 register block.</para>
<para>When <structfield>match.type</structfield> is
<constant>V4L2_CHIP_MATCH_SUBDEV</constant>,
<structfield>match.addr</structfield> selects the nth sub-device. This
allows you to enumerate over all sub-devices.</para>
<para>On success, the <structfield>name</structfield> field will
contain a chip name and the <structfield>flags</structfield> field will
contain <constant>V4L2_CHIP_FL_READABLE</constant> if the driver supports
reading registers from the device or <constant>V4L2_CHIP_FL_WRITABLE</constant>
if the driver supports writing registers to the device.</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="name-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="name-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-info">
<title>struct <structname>v4l2_dbg_chip_info</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="name-v4l2-dbg-match" />.</entry>
</row>
<row>
<entry>char</entry>
<entry><structfield>name[32]</structfield></entry>
<entry>The name of the chip.</entry>
</row>
<row>
<entry>__u32</entry>
<entry><structfield>flags</structfield></entry>
<entry>Set by the driver. If <constant>V4L2_CHIP_FL_READABLE</constant>
is set, then the driver supports reading registers from the device. If
<constant>V4L2_CHIP_FL_WRITABLE</constant> is set, then it supports writing registers.</entry>
</row>
<row>
<entry>__u32</entry>
<entry><structfield>reserved[8]</structfield></entry>
<entry>Reserved fields, both application and driver must set these to 0.</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="name-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. 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>
<entry>Match the nth sub-device.</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 or
no device could be matched.</para>
</listitem>
</varlistentry>
</variablelist>
</refsect1>
</refentry>

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

@ -87,7 +87,7 @@ written into the register.</para>
<para>To read a register applications must initialize the
<structfield>match.type</structfield>,
<structfield>match.chip</structfield> or <structfield>match.name</structfield> and
<structfield>match.addr</structfield> or <structfield>match.name</structfield> and
<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
@ -95,11 +95,11 @@ structure. On success the driver stores the register value in the
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
<constant>V4L2_CHIP_MATCH_BRIDGE</constant>,
<structfield>match.addr</structfield> selects the nth non-sub-device chip
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-IDENT; ioctl.</para>
present with the &VIDIOC-DBG-G-CHIP-INFO; ioctl.</para>
<para>When <structfield>match.type</structfield> is
<constant>V4L2_CHIP_MATCH_I2C_DRIVER</constant>,
@ -109,7 +109,7 @@ For instance
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-IDENT; ioctl you can find out which &i2c; chips are
&VIDIOC-DBG-G-CHIP-INFO; ioctl you can find out which &i2c; chips are
present.</para>
<para>When <structfield>match.type</structfield> is
@ -122,19 +122,23 @@ bus address.</para>
<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-IDENT;
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-IDENT;. Conversely it may support
<constant>VIDIOC_DBG_G_CHIP_IDENT</constant> but not these ioctls.</para>
&VIDIOC-DBG-G-CHIP-INFO;. Conversely it may support
<constant>VIDIOC_DBG_G_CHIP_INFO</constant> but not these ioctls.</para>
<para><constant>VIDIOC_DBG_G_REGISTER</constant> and
<constant>VIDIOC_DBG_S_REGISTER</constant> were introduced in Linux
@ -217,10 +221,10 @@ register.</entry>
&cs-def;
<tbody valign="top">
<row>
<entry><constant>V4L2_CHIP_MATCH_HOST</constant></entry>
<entry><constant>V4L2_CHIP_MATCH_BRIDGE</constant></entry>
<entry>0</entry>
<entry>Match the nth chip on the card, zero for the
host chip. Does not match &i2c; chips.</entry>
bridge chip. Does not match sub-devices.</entry>
</row>
<row>
<entry><constant>V4L2_CHIP_MATCH_I2C_DRIVER</constant></entry>
@ -237,6 +241,11 @@ register.</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.</entry>
</row>
</tbody>
</tgroup>
</table>

240
Documentation/DocBook/media/v4l/vidioc-enum-dv-presets.xml
View File

@ -1,240 +0,0 @@
<refentry id="vidioc-enum-dv-presets">
<refmeta>
<refentrytitle>ioctl VIDIOC_ENUM_DV_PRESETS</refentrytitle>
&manvol;
</refmeta>
<refnamediv>
<refname>VIDIOC_ENUM_DV_PRESETS</refname>
<refpurpose>Enumerate supported Digital Video presets</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_dv_enum_preset *<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_ENUM_DV_PRESETS</para>
</listitem>
</varlistentry>
<varlistentry>
<term><parameter>argp</parameter></term>
<listitem>
<para></para>
</listitem>
</varlistentry>
</variablelist>
</refsect1>
<refsect1>
<title>Description</title>
<para>This ioctl is <emphasis role="bold">deprecated</emphasis>.
New drivers and applications should use &VIDIOC-ENUM-DV-TIMINGS; instead.
</para>
<para>To query the attributes of a DV preset, applications initialize the
<structfield>index</structfield> field and zero the reserved array of &v4l2-dv-enum-preset;
and call the <constant>VIDIOC_ENUM_DV_PRESETS</constant> ioctl with a pointer to this
structure. Drivers fill the rest of the structure or return an
&EINVAL; when the index is out of bounds. To enumerate all DV Presets supported,
applications shall begin at index zero, incrementing by one until the
driver returns <errorcode>EINVAL</errorcode>. Drivers may enumerate a
different set of DV presets after switching the video input or
output.</para>
<table pgwide="1" frame="none" id="v4l2-dv-enum-preset">
<title>struct <structname>v4l2_dv_enum_presets</structname></title>
<tgroup cols="3">
&cs-str;
<tbody valign="top">
<row>
<entry>__u32</entry>
<entry><structfield>index</structfield></entry>
<entry>Number of the DV preset, set by the
application.</entry>
</row>
<row>
<entry>__u32</entry>
<entry><structfield>preset</structfield></entry>
<entry>This field identifies one of the DV preset values listed in <xref linkend="v4l2-dv-presets-vals"/>.</entry>
</row>
<row>
<entry>__u8</entry>
<entry><structfield>name</structfield>[24]</entry>
<entry>Name of the preset, a NUL-terminated ASCII string, for example: "720P-60", "1080I-60". This information is
intended for the user.</entry>
</row>
<row>
<entry>__u32</entry>
<entry><structfield>width</structfield></entry>
<entry>Width of the active video in pixels for the DV preset.</entry>
</row>
<row>
<entry>__u32</entry>
<entry><structfield>height</structfield></entry>
<entry>Height of the active video in lines for the DV preset.</entry>
</row>
<row>
<entry>__u32</entry>
<entry><structfield>reserved</structfield>[4]</entry>
<entry>Reserved for future extensions. Drivers must set the array to zero.</entry>
</row>
</tbody>
</tgroup>
</table>
<table pgwide="1" frame="none" id="v4l2-dv-presets-vals">
<title>struct <structname>DV Presets</structname></title>
<tgroup cols="3">
&cs-str;
<tbody valign="top">
<row>
<entry>Preset</entry>
<entry>Preset value</entry>
<entry>Description</entry>
</row>
<row>
<entry></entry>
<entry></entry>
<entry></entry>
</row>
<row>
<entry>V4L2_DV_INVALID</entry>
<entry>0</entry>
<entry>Invalid preset value.</entry>
</row>
<row>
<entry>V4L2_DV_480P59_94</entry>
<entry>1</entry>
<entry>720x480 progressive video at 59.94 fps as per BT.1362.</entry>
</row>
<row>
<entry>V4L2_DV_576P50</entry>
<entry>2</entry>
<entry>720x576 progressive video at 50 fps as per BT.1362.</entry>
</row>
<row>
<entry>V4L2_DV_720P24</entry>
<entry>3</entry>
<entry>1280x720 progressive video at 24 fps as per SMPTE 296M.</entry>
</row>
<row>
<entry>V4L2_DV_720P25</entry>
<entry>4</entry>
<entry>1280x720 progressive video at 25 fps as per SMPTE 296M.</entry>
</row>
<row>
<entry>V4L2_DV_720P30</entry>
<entry>5</entry>
<entry>1280x720 progressive video at 30 fps as per SMPTE 296M.</entry>
</row>
<row>
<entry>V4L2_DV_720P50</entry>
<entry>6</entry>
<entry>1280x720 progressive video at 50 fps as per SMPTE 296M.</entry>
</row>
<row>
<entry>V4L2_DV_720P59_94</entry>
<entry>7</entry>
<entry>1280x720 progressive video at 59.94 fps as per SMPTE 274M.</entry>
</row>
<row>
<entry>V4L2_DV_720P60</entry>
<entry>8</entry>
<entry>1280x720 progressive video at 60 fps as per SMPTE 274M/296M.</entry>
</row>
<row>
<entry>V4L2_DV_1080I29_97</entry>
<entry>9</entry>
<entry>1920x1080 interlaced video at 29.97 fps as per BT.1120/SMPTE 274M.</entry>
</row>
<row>
<entry>V4L2_DV_1080I30</entry>
<entry>10</entry>
<entry>1920x1080 interlaced video at 30 fps as per BT.1120/SMPTE 274M.</entry>
</row>
<row>
<entry>V4L2_DV_1080I25</entry>
<entry>11</entry>
<entry>1920x1080 interlaced video at 25 fps as per BT.1120.</entry>
</row>
<row>
<entry>V4L2_DV_1080I50</entry>
<entry>12</entry>
<entry>1920x1080 interlaced video at 50 fps as per SMPTE 296M.</entry>
</row>
<row>
<entry>V4L2_DV_1080I60</entry>
<entry>13</entry>
<entry>1920x1080 interlaced video at 60 fps as per SMPTE 296M.</entry>
</row>
<row>
<entry>V4L2_DV_1080P24</entry>
<entry>14</entry>
<entry>1920x1080 progressive video at 24 fps as per SMPTE 296M.</entry>
</row>
<row>
<entry>V4L2_DV_1080P25</entry>
<entry>15</entry>
<entry>1920x1080 progressive video at 25 fps as per SMPTE 296M.</entry>
</row>
<row>
<entry>V4L2_DV_1080P30</entry>
<entry>16</entry>
<entry>1920x1080 progressive video at 30 fps as per SMPTE 296M.</entry>
</row>
<row>
<entry>V4L2_DV_1080P50</entry>
<entry>17</entry>
<entry>1920x1080 progressive video at 50 fps as per BT.1120.</entry>
</row>
<row>
<entry>V4L2_DV_1080P60</entry>
<entry>18</entry>
<entry>1920x1080 progressive video at 60 fps as per BT.1120.</entry>
</row>
</tbody>
</tgroup>
</table>
</refsect1>
<refsect1>
&return-value;
<variablelist>
<varlistentry>
<term><errorcode>EINVAL</errorcode></term>
<listitem>
<para>The &v4l2-dv-enum-preset; <structfield>index</structfield>
is out of bounds.</para>
</listitem>
</varlistentry>
<varlistentry>
<term><errorcode>ENODATA</errorcode></term>
<listitem>
<para>Digital video presets are not supported for this input or output.</para>
</listitem>
</varlistentry>
</variablelist>
</refsect1>
</refentry>

5
Documentation/DocBook/media/v4l/vidioc-enuminput.xml
View File

@ -277,11 +277,6 @@ input/output interface to linux-media@vger.kernel.org on 19 Oct 2009.
<tgroup cols="3">
&cs-def;
<tbody valign="top">
<row>
<entry><constant>V4L2_IN_CAP_PRESETS</constant></entry>
<entry>0x00000001</entry>
<entry>This input supports setting DV presets by using VIDIOC_S_DV_PRESET.</entry>
</row>
<row>
<entry><constant>V4L2_IN_CAP_DV_TIMINGS</constant></entry>
<entry>0x00000002</entry>

5
Documentation/DocBook/media/v4l/vidioc-enumoutput.xml
View File

@ -162,11 +162,6 @@ input/output interface to linux-media@vger.kernel.org on 19 Oct 2009.
<tgroup cols="3">
&cs-def;
<tbody valign="top">
<row>
<entry><constant>V4L2_OUT_CAP_PRESETS</constant></entry>
<entry>0x00000001</entry>
<entry>This output supports setting DV presets by using VIDIOC_S_DV_PRESET.</entry>
</row>
<row>
<entry><constant>V4L2_OUT_CAP_DV_TIMINGS</constant></entry>
<entry>0x00000002</entry>

113
Documentation/DocBook/media/v4l/vidioc-g-dv-preset.xml
View File

@ -1,113 +0,0 @@
<refentry id="vidioc-g-dv-preset">
<refmeta>
<refentrytitle>ioctl VIDIOC_G_DV_PRESET, VIDIOC_S_DV_PRESET</refentrytitle>
&manvol;
</refmeta>
<refnamediv>
<refname>VIDIOC_G_DV_PRESET</refname>
<refname>VIDIOC_S_DV_PRESET</refname>
<refpurpose>Query or select the DV preset of the current input or output</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_dv_preset *<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_G_DV_PRESET, VIDIOC_S_DV_PRESET</para>
</listitem>
</varlistentry>
<varlistentry>
<term><parameter>argp</parameter></term>
<listitem>
<para></para>
</listitem>
</varlistentry>
</variablelist>
</refsect1>
<refsect1>
<title>Description</title>
<para>These ioctls are <emphasis role="bold">deprecated</emphasis>.
New drivers and applications should use &VIDIOC-G-DV-TIMINGS; and &VIDIOC-S-DV-TIMINGS;
instead.
</para>
<para>To query and select the current DV preset, applications
use the <constant>VIDIOC_G_DV_PRESET</constant> and <constant>VIDIOC_S_DV_PRESET</constant>
ioctls which take a pointer to a &v4l2-dv-preset; type as argument.
Applications must zero the reserved array in &v4l2-dv-preset;.
<constant>VIDIOC_G_DV_PRESET</constant> returns a dv preset in the field
<structfield>preset</structfield> of &v4l2-dv-preset;.</para>
<para><constant>VIDIOC_S_DV_PRESET</constant> accepts a pointer to a &v4l2-dv-preset;
that has the preset value to be set. Applications must zero the reserved array in &v4l2-dv-preset;.
If the preset is not supported, it returns an &EINVAL; </para>
</refsect1>
<refsect1>
&return-value;
<variablelist>
<varlistentry>
<term><errorcode>EINVAL</errorcode></term>
<listitem>
<para>This ioctl is not supported, or the
<constant>VIDIOC_S_DV_PRESET</constant>,<constant>VIDIOC_S_DV_PRESET</constant> parameter was unsuitable.</para>
</listitem>
</varlistentry>
<varlistentry>
<term><errorcode>ENODATA</errorcode></term>
<listitem>
<para>Digital video presets are not supported for this input or output.</para>
</listitem>
</varlistentry>
<varlistentry>
<term><errorcode>EBUSY</errorcode></term>
<listitem>
<para>The device is busy and therefore can not change the preset.</para>
</listitem>
</varlistentry>
</variablelist>
<table pgwide="1" frame="none" id="v4l2-dv-preset">
<title>struct <structname>v4l2_dv_preset</structname></title>
<tgroup cols="3">
&cs-str;
<tbody valign="top">
<row>
<entry>__u32</entry>
<entry><structfield>preset</structfield></entry>
<entry>Preset value to represent the digital video timings</entry>
</row>
<row>
<entry>__u32</entry>
<entry><structfield>reserved[4]</structfield></entry>
<entry>Reserved fields for future use</entry>
</row>
</tbody>
</tgroup>
</table>
</refsect1>
</refentry>

9
Documentation/DocBook/media/v4l/vidioc-g-ext-ctrls.xml
View File

@ -319,6 +319,15 @@ These controls are described in <xref
processing controls. These controls are described in <xref
linkend="image-process-controls" />.</entry>
</row>
<row>
<entry><constant>V4L2_CTRL_CLASS_FM_RX</constant></entry>
<entry>0xa10000</entry>
<entry>The class containing FM Receiver (FM RX) controls.
These controls are described in <xref
linkend="fm-rx-controls" />.</entry>
</row>
</tbody>
</tgroup>
</table>

78
Documentation/DocBook/media/v4l/vidioc-query-dv-preset.xml
View File

@ -1,78 +0,0 @@
<refentry id="vidioc-query-dv-preset">
<refmeta>
<refentrytitle>ioctl VIDIOC_QUERY_DV_PRESET</refentrytitle>
&manvol;
</refmeta>
<refnamediv>
<refname>VIDIOC_QUERY_DV_PRESET</refname>
<refpurpose>Sense the DV preset received by the current
input</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_dv_preset *<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_QUERY_DV_PRESET</para>
</listitem>
</varlistentry>
<varlistentry>
<term><parameter>argp</parameter></term>
<listitem>
<para></para>
</listitem>
</varlistentry>
</variablelist>
</refsect1>
<refsect1>
<title>Description</title>
<para>This ioctl is <emphasis role="bold">deprecated</emphasis>.
New drivers and applications should use &VIDIOC-QUERY-DV-TIMINGS; instead.
</para>
<para>The hardware may be able to detect the current DV preset
automatically, similar to sensing the video standard. To do so, applications
call <constant> VIDIOC_QUERY_DV_PRESET</constant> with a pointer to a
&v4l2-dv-preset; type. Once the hardware detects a preset, that preset is
returned in the preset field of &v4l2-dv-preset;. If the preset could not be
detected because there was no signal, or the signal was unreliable, or the
signal did not map to a supported preset, then the value V4L2_DV_INVALID is
returned.</para>
</refsect1>
<refsect1>
&return-value;
<variablelist>
<varlistentry>
<term><errorcode>ENODATA</errorcode></term>
<listitem>
<para>Digital video presets are not supported for this input or output.</para>
</listitem>
</varlistentry>
</variablelist>
</refsect1>
</refentry>

1
Documentation/DocBook/media_api.tmpl
View File

@ -23,6 +23,7 @@
<!-- LinuxTV v4l-dvb repository. -->
<!ENTITY v4l-dvb "<ulink url='http://linuxtv.org/repo/'>http://linuxtv.org/repo/</ulink>">
<!ENTITY dash-ent-10 "<entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry>">
<!ENTITY dash-ent-16 "<entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry>">
]>
<book id="media_api">

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

@ -6164,14 +6164,12 @@ struct _snd_pcm_runtime {
<para>
The macro takes an conditional expression to evaluate.
When <constant>CONFIG_SND_DEBUG</constant>, is set, the
expression is actually evaluated. If it's non-zero, it shows
the warning message such as
When <constant>CONFIG_SND_DEBUG</constant>, is set, if the
expression is non-zero, it shows the warning message such as
<computeroutput>BUG? (xxx)</computeroutput>
normally followed by stack trace. It returns the evaluated
value.
When no <constant>CONFIG_SND_DEBUG</constant> is set, this
macro always returns zero.
normally followed by stack trace.
In both cases it returns the evaluated value.
</para>
</section>

44
Documentation/EDID/1600x1200.S Normal file
View File

@ -0,0 +1,44 @@
/*
1600x1200.S: EDID data set for standard 1600x1200 60 Hz monitor
Copyright (C) 2013 Carsten Emde <C.Emde@osadl.org>
This program is free software; you can redistribute it and/or
modify it under the terms of the GNU General Public License
as published by the Free Software Foundation; either version 2
of the License, or (at your option) any later version.
This program is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
GNU General Public License for more details.
You should have received a copy of the GNU General Public License
along with this program; if not, write to the Free Software
Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA.
*/
/* EDID */
#define VERSION 1
#define REVISION 3
/* Display */
#define CLOCK 162000 /* kHz */
#define XPIX 1600
#define YPIX 1200
#define XY_RATIO XY_RATIO_4_3
#define XBLANK 560
#define YBLANK 50
#define XOFFSET 64
#define XPULSE 192
#define YOFFSET (63+1)
#define YPULSE (63+3)
#define DPI 72
#define VFREQ 60 /* Hz */
#define TIMING_NAME "Linux UXGA"
#define ESTABLISHED_TIMINGS_BITS 0x00 /* none */
#define HSYNC_POL 1
#define VSYNC_POL 1
#define CRC 0x9d
#include "edid.S"

12
Documentation/EDID/HOWTO.txt
View File

@ -18,12 +18,12 @@ CONFIG_DRM_LOAD_EDID_FIRMWARE was introduced. It allows to provide an
individually prepared or corrected EDID data set in the /lib/firmware
directory from where it is loaded via the firmware interface. The code
(see drivers/gpu/drm/drm_edid_load.c) contains built-in data sets for
commonly used screen resolutions (1024x768, 1280x1024, 1680x1050,
1920x1080) as binary blobs, but the kernel source tree does not contain
code to create these data. In order to elucidate the origin of the
built-in binary EDID blobs and to facilitate the creation of individual
data for a specific misbehaving monitor, commented sources and a
Makefile environment are given here.
commonly used screen resolutions (1024x768, 1280x1024, 1600x1200,
1680x1050, 1920x1080) as binary blobs, but the kernel source tree does
not contain code to create these data. In order to elucidate the origin
of the built-in binary EDID blobs and to facilitate the creation of
individual data for a specific misbehaving monitor, commented sources
and a Makefile environment are given here.
To create binary EDID and C source code files from the existing data
material, simply type "make".

26
Documentation/RCU/checklist.txt
View File

@ -217,9 +217,14 @@ over a rather long period of time, but improvements are always welcome!
whether the increased speed is worth it.
8. Although synchronize_rcu() is slower than is call_rcu(), it
usually results in simpler code. So, unless update performance
is critically important or the updaters cannot block,
synchronize_rcu() should be used in preference to call_rcu().
usually results in simpler code. So, unless update performance is
critically important, the updaters cannot block, or the latency of
synchronize_rcu() is visible from userspace, synchronize_rcu()
should be used in preference to call_rcu(). Furthermore,
kfree_rcu() usually results in even simpler code than does
synchronize_rcu() without synchronize_rcu()'s multi-millisecond
latency. So please take advantage of kfree_rcu()'s "fire and
forget" memory-freeing capabilities where it applies.
An especially important property of the synchronize_rcu()
primitive is that it automatically self-limits: if grace periods
@ -268,7 +273,8 @@ over a rather long period of time, but improvements are always welcome!
e. Periodically invoke synchronize_rcu(), permitting a limited
number of updates per grace period.
The same cautions apply to call_rcu_bh() and call_rcu_sched().
The same cautions apply to call_rcu_bh(), call_rcu_sched(),
call_srcu(), and kfree_rcu().
9. All RCU list-traversal primitives, which include
rcu_dereference(), list_for_each_entry_rcu(), and
@ -296,9 +302,9 @@ over a rather long period of time, but improvements are always welcome!
all currently executing rcu_read_lock()-protected RCU read-side
critical sections complete. It does -not- necessarily guarantee
that all currently running interrupts, NMIs, preempt_disable()
code, or idle loops will complete. Therefore, if you do not have
rcu_read_lock()-protected read-side critical sections, do -not-
use synchronize_rcu().
code, or idle loops will complete. Therefore, if your
read-side critical sections are protected by something other
than rcu_read_lock(), do -not- use synchronize_rcu().
Similarly, disabling preemption is not an acceptable substitute
for rcu_read_lock(). Code that attempts to use preemption
@ -401,9 +407,9 @@ over a rather long period of time, but improvements are always welcome!
read-side critical sections. It is the responsibility of the
RCU update-side primitives to deal with this.
17. Use CONFIG_PROVE_RCU, CONFIG_DEBUG_OBJECTS_RCU_HEAD, and
the __rcu sparse checks to validate your RCU code. These
can help find problems as follows:
17. Use CONFIG_PROVE_RCU, CONFIG_DEBUG_OBJECTS_RCU_HEAD, and the
__rcu sparse checks (enabled by CONFIG_SPARSE_RCU_POINTER) to
validate your RCU code. These can help find problems as follows:
CONFIG_PROVE_RCU: check that accesses to RCU-protected data
structures are carried out under the proper RCU

5
Documentation/RCU/lockdep.txt
View File

@ -64,6 +64,11 @@ checking of rcu_dereference() primitives:
but retain the compiler constraints that prevent duplicating
or coalescsing. This is useful when when testing the
value of the pointer itself, for example, against NULL.
rcu_access_index(idx):
Return the value of the index and omit all barriers, but
retain the compiler constraints that prevent duplicating
or coalescsing. This is useful when when testing the
value of the index itself, for example, against -1.
The rcu_dereference_check() check expression can be any boolean
expression, but would normally include a lockdep expression. However,

15
Documentation/RCU/rcubarrier.txt
View File

@ -79,7 +79,20 @@ complete. Pseudo-code using rcu_barrier() is as follows:
2. Execute rcu_barrier().
3. Allow the module to be unloaded.
The rcutorture module makes use of rcu_barrier in its exit function
There are also rcu_barrier_bh(), rcu_barrier_sched(), and srcu_barrier()
functions for the other flavors of RCU, and you of course must match
the flavor of rcu_barrier() with that of call_rcu(). If your module
uses multiple flavors of call_rcu(), then it must also use multiple
flavors of rcu_barrier() when unloading that module. For example, if
it uses call_rcu_bh(), call_srcu() on srcu_struct_1, and call_srcu() on
srcu_struct_2(), then the following three lines of code will be required
when unloading:
1 rcu_barrier_bh();
2 srcu_barrier(&srcu_struct_1);
3 srcu_barrier(&srcu_struct_2);
The rcutorture module makes use of rcu_barrier() in its exit function
as follows:
1 static void

33
Documentation/RCU/stallwarn.txt
View File

@ -92,14 +92,14 @@ If the CONFIG_RCU_CPU_STALL_INFO kernel configuration parameter is set,
more information is printed with the stall-warning message, for example:
INFO: rcu_preempt detected stall on CPU
0: (63959 ticks this GP) idle=241/3fffffffffffffff/0
0: (63959 ticks this GP) idle=241/3fffffffffffffff/0 softirq=82/543
(t=65000 jiffies)
In kernels with CONFIG_RCU_FAST_NO_HZ, even more information is
printed:
INFO: rcu_preempt detected stall on CPU
0: (64628 ticks this GP) idle=dd5/3fffffffffffffff/0 drain=0 . timer not pending
0: (64628 ticks this GP) idle=dd5/3fffffffffffffff/0 softirq=82/543 last_accelerate: a345/d342 nonlazy_posted: 25 .D
(t=65000 jiffies)
The "(64628 ticks this GP)" indicates that this CPU has taken more
@ -116,13 +116,28 @@ number between the two "/"s is the value of the nesting, which will
be a small positive number if in the idle loop and a very large positive
number (as shown above) otherwise.
For CONFIG_RCU_FAST_NO_HZ kernels, the "drain=0" indicates that the CPU is
not in the process of trying to force itself into dyntick-idle state, the
"." indicates that the CPU has not given up forcing RCU into dyntick-idle
mode (it would be "H" otherwise), and the "timer not pending" indicates
that the CPU has not recently forced RCU into dyntick-idle mode (it
would otherwise indicate the number of microseconds remaining in this
forced state).
The "softirq=" portion of the message tracks the number of RCU softirq
handlers that the stalled CPU has executed. The number before the "/"
is the number that had executed since boot at the time that this CPU
last noted the beginning of a grace period, which might be the current
(stalled) grace period, or it might be some earlier grace period (for
example, if the CPU might have been in dyntick-idle mode for an extended
time period. The number after the "/" is the number that have executed
since boot until the current time. If this latter number stays constant
across repeated stall-warning messages, it is possible that RCU's softirq
handlers are no longer able to execute on this CPU. This can happen if
the stalled CPU is spinning with interrupts are disabled, or, in -rt
kernels, if a high-priority process is starving RCU's softirq handler.
For CONFIG_RCU_FAST_NO_HZ kernels, the "last_accelerate:" prints the
low-order 16 bits (in hex) of the jiffies counter when this CPU last
invoked rcu_try_advance_all_cbs() from rcu_needs_cpu() or last invoked
rcu_accelerate_cbs() from rcu_prepare_for_idle(). The "nonlazy_posted:"
prints the number of non-lazy callbacks posted since the last call to
rcu_needs_cpu(). Finally, an "L" indicates that there are currently
no non-lazy callbacks ("." is printed otherwise, as shown above) and
"D" indicates that dyntick-idle processing is enabled ("." is printed
otherwise, for example, if disabled via the "nohz=" kernel boot parameter).
Multiple Warnings From One Stall

4
Documentation/RCU/whatisRCU.txt
View File

@ -265,9 +265,9 @@ rcu_dereference()
rcu_read_lock();
p = rcu_dereference(head.next);
rcu_read_unlock();
x = p->address;
x = p->address; /* BUG!!! */
rcu_read_lock();
y = p->data;
y = p->data; /* BUG!!! */
rcu_read_unlock();
Holding a reference from one RCU read-side critical section

9
Documentation/SubmittingPatches
View File

@ -420,7 +420,7 @@ person it names. This tag documents that potentially interested parties
have been included in the discussion
14) Using Reported-by:, Tested-by: and Reviewed-by:
14) Using Reported-by:, Tested-by:, Reviewed-by: and Suggested-by:
If this patch fixes a problem reported by somebody else, consider adding a
Reported-by: tag to credit the reporter for their contribution. Please
@ -468,6 +468,13 @@ done on the patch. Reviewed-by: tags, when supplied by reviewers known to
understand the subject area and to perform thorough reviews, will normally
increase the likelihood of your patch getting into the kernel.
A Suggested-by: tag indicates that the patch idea is suggested by the person
named and ensures credit to the person for the idea. Please note that this
tag should not be added without the reporter's permission, especially if the
idea was not posted in a public forum. That said, if we diligently credit our
idea reporters, they will, hopefully, be inspired to help us again in the
future.
15) The canonical patch format

498
Documentation/arm/cluster-pm-race-avoidance.txt Normal file
View File

@ -0,0 +1,498 @@
Cluster-wide Power-up/power-down race avoidance algorithm
=========================================================
This file documents the algorithm which is used to coordinate CPU and
cluster setup and teardown operations and to manage hardware coherency
controls safely.
The section "Rationale" explains what the algorithm is for and why it is
needed. "Basic model" explains general concepts using a simplified view
of the system. The other sections explain the actual details of the
algorithm in use.
Rationale
---------
In a system containing multiple CPUs, it is desirable to have the
ability to turn off individual CPUs when the system is idle, reducing
power consumption and thermal dissipation.
In a system containing multiple clusters of CPUs, it is also desirable
to have the ability to turn off entire clusters.
Turning entire clusters off and on is a risky business, because it
involves performing potentially destructive operations affecting a group
of independently running CPUs, while the OS continues to run. This
means that we need some coordination in order to ensure that critical
cluster-level operations are only performed when it is truly safe to do
so.
Simple locking may not be sufficient to solve this problem, because
mechanisms like Linux spinlocks may rely on coherency mechanisms which
are not immediately enabled when a cluster powers up. Since enabling or
disabling those mechanisms may itself be a non-atomic operation (such as
writing some hardware registers and invalidating large caches), other
methods of coordination are required in order to guarantee safe
power-down and power-up at the cluster level.
The mechanism presented in this document describes a coherent memory
based protocol for performing the needed coordination. It aims to be as
lightweight as possible, while providing the required safety properties.
Basic model
-----------
Each cluster and CPU is assigned a state, as follows:
DOWN
COMING_UP
UP
GOING_DOWN
+---------> UP ----------+
| v
COMING_UP GOING_DOWN
^ |
+--------- DOWN <--------+
DOWN: The CPU or cluster is not coherent, and is either powered off or
suspended, or is ready to be powered off or suspended.
COMING_UP: The CPU or cluster has committed to moving to the UP state.
It may be part way through the process of initialisation and
enabling coherency.
UP: The CPU or cluster is active and coherent at the hardware
level. A CPU in this state is not necessarily being used
actively by the kernel.
GOING_DOWN: The CPU or cluster has committed to moving to the DOWN
state. It may be part way through the process of teardown and
coherency exit.
Each CPU has one of these states assigned to it at any point in time.
The CPU states are described in the "CPU state" section, below.
Each cluster is also assigned a state, but it is necessary to split the
state value into two parts (the "cluster" state and "inbound" state) and
to introduce additional states in order to avoid races between different
CPUs in the cluster simultaneously modifying the state. The cluster-
level states are described in the "Cluster state" section.
To help distinguish the CPU states from cluster states in this
discussion, the state names are given a CPU_ prefix for the CPU states,
and a CLUSTER_ or INBOUND_ prefix for the cluster states.
CPU state
---------
In this algorithm, each individual core in a multi-core processor is
referred to as a "CPU". CPUs are assumed to be single-threaded:
therefore, a CPU can only be doing one thing at a single point in time.
This means that CPUs fit the basic model closely.
The algorithm defines the following states for each CPU in the system:
CPU_DOWN
CPU_COMING_UP
CPU_UP
CPU_GOING_DOWN
cluster setup and
CPU setup complete policy decision
+-----------> CPU_UP ------------+
| v
CPU_COMING_UP CPU_GOING_DOWN
^ |
+----------- CPU_DOWN <----------+
policy decision CPU teardown complete
or hardware event
The definitions of the four states correspond closely to the states of
the basic model.
Transitions between states occur as follows.
A trigger event (spontaneous) means that the CPU can transition to the
next state as a result of making local progress only, with no
requirement for any external event to happen.
CPU_DOWN:
A CPU reaches the CPU_DOWN state when it is ready for
power-down. On reaching this state, the CPU will typically
power itself down or suspend itself, via a WFI instruction or a
firmware call.
Next state: CPU_COMING_UP
Conditions: none
Trigger events:
a) an explicit hardware power-up operation, resulting
from a policy decision on another CPU;
b) a hardware event, such as an interrupt.
CPU_COMING_UP:
A CPU cannot start participating in hardware coherency until the
cluster is set up and coherent. If the cluster is not ready,
then the CPU will wait in the CPU_COMING_UP state until the
cluster has been set up.
Next state: CPU_UP
Conditions: The CPU's parent cluster must be in CLUSTER_UP.
Trigger events: Transition of the parent cluster to CLUSTER_UP.
Refer to the "Cluster state" section for a description of the
CLUSTER_UP state.
CPU_UP:
When a CPU reaches the CPU_UP state, it is safe for the CPU to
start participating in local coherency.
This is done by jumping to the kernel's CPU resume code.
Note that the definition of this state is slightly different
from the basic model definition: CPU_UP does not mean that the
CPU is coherent yet, but it does mean that it is safe to resume
the kernel. The kernel handles the rest of the resume
procedure, so the remaining steps are not visible as part of the
race avoidance algorithm.
The CPU remains in this state until an explicit policy decision
is made to shut down or suspend the CPU.
Next state: CPU_GOING_DOWN
Conditions: none
Trigger events: explicit policy decision
CPU_GOING_DOWN:
While in this state, the CPU exits coherency, including any
operations required to achieve this (such as cleaning data
caches).
Next state: CPU_DOWN
Conditions: local CPU teardown complete
Trigger events: (spontaneous)
Cluster state
-------------
A cluster is a group of connected CPUs with some common resources.
Because a cluster contains multiple CPUs, it can be doing multiple
things at the same time. This has some implications. In particular, a
CPU can start up while another CPU is tearing the cluster down.
In this discussion, the "outbound side" is the view of the cluster state
as seen by a CPU tearing the cluster down. The "inbound side" is the
view of the cluster state as seen by a CPU setting the CPU up.
In order to enable safe coordination in such situations, it is important
that a CPU which is setting up the cluster can advertise its state
independently of the CPU which is tearing down the cluster. For this
reason, the cluster state is split into two parts:
"cluster" state: The global state of the cluster; or the state
on the outbound side:
CLUSTER_DOWN
CLUSTER_UP
CLUSTER_GOING_DOWN
"inbound" state: The state of the cluster on the inbound side.
INBOUND_NOT_COMING_UP
INBOUND_COMING_UP
The different pairings of these states results in six possible
states for the cluster as a whole:
CLUSTER_UP
+==========> INBOUND_NOT_COMING_UP -------------+
# |
|
CLUSTER_UP <----+ |
INBOUND_COMING_UP | v
^ CLUSTER_GOING_DOWN CLUSTER_GOING_DOWN
# INBOUND_COMING_UP <=== INBOUND_NOT_COMING_UP
CLUSTER_DOWN | |
INBOUND_COMING_UP <----+ |
|
^ |
+=========== CLUSTER_DOWN <------------+
INBOUND_NOT_COMING_UP
Transitions -----> can only be made by the outbound CPU, and
only involve changes to the "cluster" state.
Transitions ===##> can only be made by the inbound CPU, and only
involve changes to the "inbound" state, except where there is no
further transition possible on the outbound side (i.e., the
outbound CPU has put the cluster into the CLUSTER_DOWN state).
The race avoidance algorithm does not provide a way to determine
which exact CPUs within the cluster play these roles. This must
be decided in advance by some other means. Refer to the section
"Last man and first man selection" for more explanation.
CLUSTER_DOWN/INBOUND_NOT_COMING_UP is the only state where the
cluster can actually be powered down.
The parallelism of the inbound and outbound CPUs is observed by
the existence of two different paths from CLUSTER_GOING_DOWN/
INBOUND_NOT_COMING_UP (corresponding to GOING_DOWN in the basic
model) to CLUSTER_DOWN/INBOUND_COMING_UP (corresponding to
COMING_UP in the basic model). The second path avoids cluster
teardown completely.
CLUSTER_UP/INBOUND_COMING_UP is equivalent to UP in the basic
model. The final transition to CLUSTER_UP/INBOUND_NOT_COMING_UP
is trivial and merely resets the state machine ready for the
next cycle.
Details of the allowable transitions follow.
The next state in each case is notated
<cluster state>/<inbound state> (<transitioner>)
where the <transitioner> is the side on which the transition
can occur; either the inbound or the outbound side.
CLUSTER_DOWN/INBOUND_NOT_COMING_UP:
Next state: CLUSTER_DOWN/INBOUND_COMING_UP (inbound)
Conditions: none
Trigger events:
a) an explicit hardware power-up operation, resulting
from a policy decision on another CPU;
b) a hardware event, such as an interrupt.
CLUSTER_DOWN/INBOUND_COMING_UP:
In this state, an inbound CPU sets up the cluster, including
enabling of hardware coherency at the cluster level and any
other operations (such as cache invalidation) which are required
in order to achieve this.
The purpose of this state is to do sufficient cluster-level
setup to enable other CPUs in the cluster to enter coherency
safely.
Next state: CLUSTER_UP/INBOUND_COMING_UP (inbound)
Conditions: cluster-level setup and hardware coherency complete
Trigger events: (spontaneous)
CLUSTER_UP/INBOUND_COMING_UP:
Cluster-level setup is complete and hardware coherency is
enabled for the cluster. Other CPUs in the cluster can safely
enter coherency.
This is a transient state, leading immediately to
CLUSTER_UP/INBOUND_NOT_COMING_UP. All other CPUs on the cluster
should consider treat these two states as equivalent.
Next state: CLUSTER_UP/INBOUND_NOT_COMING_UP (inbound)
Conditions: none
Trigger events: (spontaneous)
CLUSTER_UP/INBOUND_NOT_COMING_UP:
Cluster-level setup is complete and hardware coherency is
enabled for the cluster. Other CPUs in the cluster can safely
enter coherency.
The cluster will remain in this state until a policy decision is
made to power the cluster down.
Next state: CLUSTER_GOING_DOWN/INBOUND_NOT_COMING_UP (outbound)
Conditions: none
Trigger events: policy decision to power down the cluster
CLUSTER_GOING_DOWN/INBOUND_NOT_COMING_UP:
An outbound CPU is tearing the cluster down. The selected CPU
must wait in this state until all CPUs in the cluster are in the
CPU_DOWN state.
When all CPUs are in the CPU_DOWN state, the cluster can be torn
down, for example by cleaning data caches and exiting
cluster-level coherency.
To avoid wasteful unnecessary teardown operations, the outbound
should check the inbound cluster state for asynchronous
transitions to INBOUND_COMING_UP. Alternatively, individual
CPUs can be checked for entry into CPU_COMING_UP or CPU_UP.
Next states:
CLUSTER_DOWN/INBOUND_NOT_COMING_UP (outbound)
Conditions: cluster torn down and ready to power off
Trigger events: (spontaneous)
CLUSTER_GOING_DOWN/INBOUND_COMING_UP (inbound)
Conditions: none
Trigger events:
a) an explicit hardware power-up operation,
resulting from a policy decision on another
CPU;
b) a hardware event, such as an interrupt.
CLUSTER_GOING_DOWN/INBOUND_COMING_UP:
The cluster is (or was) being torn down, but another CPU has
come online in the meantime and is trying to set up the cluster
again.
If the outbound CPU observes this state, it has two choices:
a) back out of teardown, restoring the cluster to the
CLUSTER_UP state;
b) finish tearing the cluster down and put the cluster
in the CLUSTER_DOWN state; the inbound CPU will
set up the cluster again from there.
Choice (a) permits the removal of some latency by avoiding
unnecessary teardown and setup operations in situations where
the cluster is not really going to be powered down.
Next states:
CLUSTER_UP/INBOUND_COMING_UP (outbound)
Conditions: cluster-level setup and hardware
coherency complete
Trigger events: (spontaneous)
CLUSTER_DOWN/INBOUND_COMING_UP (outbound)
Conditions: cluster torn down and ready to power off
Trigger events: (spontaneous)
Last man and First man selection
--------------------------------
The CPU which performs cluster tear-down operations on the outbound side
is commonly referred to as the "last man".
The CPU which performs cluster setup on the inbound side is commonly
referred to as the "first man".
The race avoidance algorithm documented above does not provide a
mechanism to choose which CPUs should play these roles.
Last man:
When shutting down the cluster, all the CPUs involved are initially
executing Linux and hence coherent. Therefore, ordinary spinlocks can
be used to select a last man safely, before the CPUs become
non-coherent.
First man:
Because CPUs may power up asynchronously in response to external wake-up
events, a dynamic mechanism is needed to make sure that only one CPU
attempts to play the first man role and do the cluster-level
initialisation: any other CPUs must wait for this to complete before
proceeding.
Cluster-level initialisation may involve actions such as configuring
coherency controls in the bus fabric.
The current implementation in mcpm_head.S uses a separate mutual exclusion
mechanism to do this arbitration. This mechanism is documented in
detail in vlocks.txt.
Features and Limitations
------------------------
Implementation:
The current ARM-based implementation is split between
arch/arm/common/mcpm_head.S (low-level inbound CPU operations) and
arch/arm/common/mcpm_entry.c (everything else):
__mcpm_cpu_going_down() signals the transition of a CPU to the
CPU_GOING_DOWN state.
__mcpm_cpu_down() signals the transition of a CPU to the CPU_DOWN
state.
A CPU transitions to CPU_COMING_UP and then to CPU_UP via the
low-level power-up code in mcpm_head.S. This could
involve CPU-specific setup code, but in the current
implementation it does not.
__mcpm_outbound_enter_critical() and __mcpm_outbound_leave_critical()
handle transitions from CLUSTER_UP to CLUSTER_GOING_DOWN
and from there to CLUSTER_DOWN or back to CLUSTER_UP (in
the case of an aborted cluster power-down).
These functions are more complex than the __mcpm_cpu_*()
functions due to the extra inter-CPU coordination which
is needed for safe transitions at the cluster level.
A cluster transitions from CLUSTER_DOWN back to CLUSTER_UP via
the low-level power-up code in mcpm_head.S. This
typically involves platform-specific setup code,
provided by the platform-specific power_up_setup
function registered via mcpm_sync_init.
Deep topologies:
As currently described and implemented, the algorithm does not
support CPU topologies involving more than two levels (i.e.,
clusters of clusters are not supported). The algorithm could be
extended by replicating the cluster-level states for the
additional topological levels, and modifying the transition
rules for the intermediate (non-outermost) cluster levels.
Colophon
--------
Originally created and documented by Dave Martin for Linaro Limited, in
collaboration with Nicolas Pitre and Achin Gupta.
Copyright (C) 2012-2013 Linaro Limited
Distributed under the terms of Version 2 of the GNU General Public
License, as defined in linux/COPYING.

88
Documentation/arm/firmware.txt Normal file
View File

@ -0,0 +1,88 @@
Interface for registering and calling firmware-specific operations for ARM.
----
Written by Tomasz Figa <t.figa@samsung.com>
Some boards are running with secure firmware running in TrustZone secure
world, which changes the way some things have to be initialized. This makes
a need to provide an interface for such platforms to specify available firmware
operations and call them when needed.
Firmware operations can be specified using struct firmware_ops
struct firmware_ops {
/*
* Enters CPU idle mode
*/
int (*do_idle)(void);
/*
* Sets boot address of specified physical CPU
*/
int (*set_cpu_boot_addr)(int cpu, unsigned long boot_addr);
/*
* Boots specified physical CPU
*/
int (*cpu_boot)(int cpu);
/*
* Initializes L2 cache
*/
int (*l2x0_init)(void);
};
and then registered with register_firmware_ops function
void register_firmware_ops(const struct firmware_ops *ops)
the ops pointer must be non-NULL.
There is a default, empty set of operations provided, so there is no need to
set anything if platform does not require firmware operations.
To call a firmware operation, a helper macro is provided
#define call_firmware_op(op, ...) \
((firmware_ops->op) ? firmware_ops->op(__VA_ARGS__) : (-ENOSYS))
the macro checks if the operation is provided and calls it or otherwise returns
-ENOSYS to signal that given operation is not available (for example, to allow
fallback to legacy operation).
Example of registering firmware operations:
/* board file */
static int platformX_do_idle(void)
{
/* tell platformX firmware to enter idle */
return 0;
}
static int platformX_cpu_boot(int i)
{
/* tell platformX firmware to boot CPU i */
return 0;
}
static const struct firmware_ops platformX_firmware_ops = {
.do_idle = exynos_do_idle,
.cpu_boot = exynos_cpu_boot,
/* other operations not available on platformX */
};
/* init_early callback of machine descriptor */
static void __init board_init_early(void)
{
register_firmware_ops(&platformX_firmware_ops);
}
Example of using a firmware operation:
/* some platform code, e.g. SMP initialization */
__raw_writel(virt_to_phys(exynos4_secondary_startup),
CPU1_BOOT_REG);
/* Call Exynos specific smc call */
if (call_firmware_op(cpu_boot, cpu) == -ENOSYS)
cpu_boot_legacy(...); /* Try legacy way */
gic_raise_softirq(cpumask_of(cpu), 1);

56
Documentation/arm/sunxi/clocks.txt Normal file
View File

@ -0,0 +1,56 @@
Frequently asked questions about the sunxi clock system
=======================================================
This document contains useful bits of information that people tend to ask
about the sunxi clock system, as well as accompanying ASCII art when adequate.
Q: Why is the main 24MHz oscillator gatable? Wouldn't that break the
system?
A: The 24MHz oscillator allows gating to save power. Indeed, if gated
carelessly the system would stop functioning, but with the right
steps, one can gate it and keep the system running. Consider this
simplified suspend example:
While the system is operational, you would see something like
24MHz 32kHz
|
PLL1
\
\_ CPU Mux
|
[CPU]
When you are about to suspend, you switch the CPU Mux to the 32kHz
oscillator:
24Mhz 32kHz
| |
PLL1 |
/
CPU Mux _/
|
[CPU]
Finally you can gate the main oscillator
32kHz
|
|
/
CPU Mux _/
|
[CPU]
Q: Were can I learn more about the sunxi clocks?
A: The linux-sunxi wiki contains a page documenting the clock registers,
you can find it at
http://linux-sunxi.org/A10/CCM
The authoritative source for information at this time is the ccmu driver
released by Allwinner, you can find it at
https://github.com/linux-sunxi/linux-sunxi/tree/sunxi-3.0/arch/arm/mach-sun4i/clock/ccmu

211
Documentation/arm/vlocks.txt Normal file
View File

@ -0,0 +1,211 @@
vlocks for Bare-Metal Mutual Exclusion
======================================
Voting Locks, or "vlocks" provide a simple low-level mutual exclusion
mechanism, with reasonable but minimal requirements on the memory
system.
These are intended to be used to coordinate critical activity among CPUs
which are otherwise non-coherent, in situations where the hardware
provides no other mechanism to support this and ordinary spinlocks
cannot be used.
vlocks make use of the atomicity provided by the memory system for
writes to a single memory location. To arbitrate, every CPU "votes for
itself", by storing a unique number to a common memory location. The
final value seen in that memory location when all the votes have been
cast identifies the winner.
In order to make sure that the election produces an unambiguous result
in finite time, a CPU will only enter the election in the first place if
no winner has been chosen and the election does not appear to have
started yet.
Algorithm
---------
The easiest way to explain the vlocks algorithm is with some pseudo-code:
int currently_voting[NR_CPUS] = { 0, };
int last_vote = -1; /* no votes yet */
bool vlock_trylock(int this_cpu)
{
/* signal our desire to vote */
currently_voting[this_cpu] = 1;
if (last_vote != -1) {
/* someone already volunteered himself */
currently_voting[this_cpu] = 0;
return false; /* not ourself */
}
/* let's suggest ourself */
last_vote = this_cpu;
currently_voting[this_cpu] = 0;
/* then wait until everyone else is done voting */
for_each_cpu(i) {
while (currently_voting[i] != 0)
/* wait */;
}
/* result */
if (last_vote == this_cpu)
return true; /* we won */
return false;
}
bool vlock_unlock(void)
{
last_vote = -1;
}
The currently_voting[] array provides a way for the CPUs to determine
whether an election is in progress, and plays a role analogous to the
"entering" array in Lamport's bakery algorithm [1].
However, once the election has started, the underlying memory system
atomicity is used to pick the winner. This avoids the need for a static
priority rule to act as a tie-breaker, or any counters which could
overflow.
As long as the last_vote variable is globally visible to all CPUs, it
will contain only one value that won't change once every CPU has cleared
its currently_voting flag.
Features and limitations
------------------------
* vlocks are not intended to be fair. In the contended case, it is the
_last_ CPU which attempts to get the lock which will be most likely
to win.
vlocks are therefore best suited to situations where it is necessary
to pick a unique winner, but it does not matter which CPU actually
wins.
* Like other similar mechanisms, vlocks will not scale well to a large
number of CPUs.
vlocks can be cascaded in a voting hierarchy to permit better scaling
if necessary, as in the following hypothetical example for 4096 CPUs:
/* first level: local election */
my_town = towns[(this_cpu >> 4) & 0xf];
I_won = vlock_trylock(my_town, this_cpu & 0xf);
if (I_won) {
/* we won the town election, let's go for the state */
my_state = states[(this_cpu >> 8) & 0xf];
I_won = vlock_lock(my_state, this_cpu & 0xf));
if (I_won) {
/* and so on */
I_won = vlock_lock(the_whole_country, this_cpu & 0xf];
if (I_won) {
/* ... */
}
vlock_unlock(the_whole_country);
}
vlock_unlock(my_state);
}
vlock_unlock(my_town);
ARM implementation
------------------
The current ARM implementation [2] contains some optimisations beyond
the basic algorithm:
* By packing the members of the currently_voting array close together,
we can read the whole array in one transaction (providing the number
of CPUs potentially contending the lock is small enough). This
reduces the number of round-trips required to external memory.
In the ARM implementation, this means that we can use a single load
and comparison:
LDR Rt, [Rn]
CMP Rt, #0
...in place of code equivalent to:
LDRB Rt, [Rn]
CMP Rt, #0
LDRBEQ Rt, [Rn, #1]
CMPEQ Rt, #0
LDRBEQ Rt, [Rn, #2]
CMPEQ Rt, #0
LDRBEQ Rt, [Rn, #3]
CMPEQ Rt, #0
This cuts down on the fast-path latency, as well as potentially
reducing bus contention in contended cases.
The optimisation relies on the fact that the ARM memory system
guarantees coherency between overlapping memory accesses of
different sizes, similarly to many other architectures. Note that
we do not care which element of currently_voting appears in which
bits of Rt, so there is no need to worry about endianness in this
optimisation.
If there are too many CPUs to read the currently_voting array in
one transaction then multiple transations are still required. The
implementation uses a simple loop of word-sized loads for this
case. The number of transactions is still fewer than would be
required if bytes were loaded individually.
In principle, we could aggregate further by using LDRD or LDM, but
to keep the code simple this was not attempted in the initial
implementation.
* vlocks are currently only used to coordinate between CPUs which are
unable to enable their caches yet. This means that the
implementation removes many of the barriers which would be required
when executing the algorithm in cached memory.
packing of the currently_voting array does not work with cached
memory unless all CPUs contending the lock are cache-coherent, due
to cache writebacks from one CPU clobbering values written by other
CPUs. (Though if all the CPUs are cache-coherent, you should be
probably be using proper spinlocks instead anyway).
* The "no votes yet" value used for the last_vote variable is 0 (not
-1 as in the pseudocode). This allows statically-allocated vlocks
to be implicitly initialised to an unlocked state simply by putting
them in .bss.
An offset is added to each CPU's ID for the purpose of setting this
variable, so that no CPU uses the value 0 for its ID.
Colophon
--------
Originally created and documented by Dave Martin for Linaro Limited, for
use in ARM-based big.LITTLE platforms, with review and input gratefully
received from Nicolas Pitre and Achin Gupta. Thanks to Nicolas for
grabbing most of this text out of the relevant mail thread and writing
up the pseudocode.
Copyright (C) 2012-2013 Linaro Limited
Distributed under the terms of Version 2 of the GNU General Public
License, as defined in linux/COPYING.
References
----------
[1] Lamport, L. "A New Solution of Dijkstra's Concurrent Programming
Problem", Communications of the ACM 17, 8 (August 1974), 453-455.
http://en.wikipedia.org/wiki/Lamport%27s_bakery_algorithm
[2] linux/arch/arm/common/vlock.S, www.kernel.org.

7
Documentation/backlight/lp855x-driver.txt
View File

@ -32,14 +32,10 @@ Platform data for lp855x
For supporting platform specific data, the lp855x platform data can be used.
* name : Backlight driver name. If it is not defined, default name is set.
* mode : Brightness control mode. PWM or register based.
* device_control : Value of DEVICE CONTROL register.
* initial_brightness : Initial value of backlight brightness.
* period_ns : Platform specific PWM period value. unit is nano.
Only valid when brightness is pwm input mode.
* load_new_rom_data :
0 : use default configuration data
1 : update values of eeprom or eprom registers on loading driver
* size_program : Total size of lp855x_rom_data.
* rom_data : List of new eeprom/eprom registers.
@ -54,10 +50,8 @@ static struct lp855x_rom_data lp8552_eeprom_arr[] = {
static struct lp855x_platform_data lp8552_pdata = {
.name = "lcd-bl",
.mode = REGISTER_BASED,
.device_control = I2C_CONFIG(LP8552),
.initial_brightness = INITIAL_BRT,
.load_new_rom_data = 1,
.size_program = ARRAY_SIZE(lp8552_eeprom_arr),
.rom_data = lp8552_eeprom_arr,
};
@ -65,7 +59,6 @@ static struct lp855x_platform_data lp8552_pdata = {
example 2) lp8556 platform data : pwm input mode with default rom data
static struct lp855x_platform_data lp8556_pdata = {
.mode = PWM_BASED,
.device_control = PWM_CONFIG(LP8556),
.initial_brightness = INITIAL_BRT,
.period_ns = 1000000,

2
Documentation/cgroups/00-INDEX
View File

@ -18,6 +18,8 @@ memcg_test.txt
- Memory Resource Controller; implementation details.
memory.txt
- Memory Resource Controller; design, accounting, interface, testing.
net_cls.txt
- Network classifier cgroups details and usages.
net_prio.txt
- Network priority cgroups details and usages.
resource_counter.txt

3
Documentation/cgroups/cgroups.txt
View File

@ -442,7 +442,7 @@ You can attach the current shell task by echoing 0:
You can use the cgroup.procs file instead of the tasks file to move all
threads in a threadgroup at once. Echoing the PID of any task in a
threadgroup to cgroup.procs causes all tasks in that threadgroup to be
be attached to the cgroup. Writing 0 to cgroup.procs moves all tasks
attached to the cgroup. Writing 0 to cgroup.procs moves all tasks
in the writing task's threadgroup.
Note: Since every task is always a member of exactly one cgroup in each
@ -580,6 +580,7 @@ propagation along the hierarchy. See the comment on
cgroup_for_each_descendant_pre() for details.
void css_offline(struct cgroup *cgrp);
(cgroup_mutex held by caller)
This is the counterpart of css_online() and called iff css_online()
has succeeded on @cgrp. This signifies the beginning of the end of

70
Documentation/cgroups/devices.txt
View File

@ -13,9 +13,7 @@ either an integer or * for all. Access is a composition of r
The root device cgroup starts with rwm to 'all'. A child device
cgroup gets a copy of the parent. Administrators can then remove
devices from the whitelist or add new entries. A child cgroup can
never receive a device access which is denied by its parent. However
when a device access is removed from a parent it will not also be
removed from the child(ren).
never receive a device access which is denied by its parent.
2. User Interface
@ -50,3 +48,69 @@ task to a new cgroup. (Again we'll probably want to change that).
A cgroup may not be granted more permissions than the cgroup's
parent has.
4. Hierarchy
device cgroups maintain hierarchy by making sure a cgroup never has more
access permissions than its parent. Every time an entry is written to
a cgroup's devices.deny file, all its children will have that entry removed
from their whitelist and all the locally set whitelist entries will be
re-evaluated. In case one of the locally set whitelist entries would provide
more access than the cgroup's parent, it'll be removed from the whitelist.
Example:
A
/ \
B
group behavior exceptions
A allow "b 8:* rwm", "c 116:1 rw"
B deny "c 1:3 rwm", "c 116:2 rwm", "b 3:* rwm"
If a device is denied in group A:
# echo "c 116:* r" > A/devices.deny
it'll propagate down and after revalidating B's entries, the whitelist entry
"c 116:2 rwm" will be removed:
group whitelist entries denied devices
A all "b 8:* rwm", "c 116:* rw"
B "c 1:3 rwm", "b 3:* rwm" all the rest
In case parent's exceptions change and local exceptions are not allowed
anymore, they'll be deleted.
Notice that new whitelist entries will not be propagated:
A
/ \
B
group whitelist entries denied devices
A "c 1:3 rwm", "c 1:5 r" all the rest
B "c 1:3 rwm", "c 1:5 r" all the rest
when adding "c *:3 rwm":
# echo "c *:3 rwm" >A/devices.allow
the result:
group whitelist entries denied devices
A "c *:3 rwm", "c 1:5 r" all the rest
B "c 1:3 rwm", "c 1:5 r" all the rest
but now it'll be possible to add new entries to B:
# echo "c 2:3 rwm" >B/devices.allow
# echo "c 50:3 r" >B/devices.allow
or even
# echo "c *:3 rwm" >B/devices.allow
Allowing or denying all by writing 'a' to devices.allow or devices.deny will
not be possible once the device cgroups has children.
4.1 Hierarchy (internal implementation)
device cgroups is implemented internally using a behavior (ALLOW, DENY) and a
list of exceptions. The internal state is controlled using the same user
interface to preserve compatibility with the previous whitelist-only
implementation. Removal or addition of exceptions that will reduce the access
to devices will be propagated down the hierarchy.
For every propagated exception, the effective rules will be re-evaluated based
on current parent's access rules.

72
Documentation/cgroups/memory.txt
View File

@ -40,6 +40,7 @@ Features:
- soft limit
- moving (recharging) account at moving a task is selectable.
- usage threshold notifier
- memory pressure notifier
- oom-killer disable knob and oom-notifier
- Root cgroup has no limit controls.
@ -65,6 +66,7 @@ Brief summary of control files.
memory.stat # show various statistics
memory.use_hierarchy # set/show hierarchical account enabled
memory.force_empty # trigger forced move charge to parent
memory.pressure_level # set memory pressure notifications
memory.swappiness # set/show swappiness parameter of vmscan
(See sysctl's vm.swappiness)
memory.move_charge_at_immigrate # set/show controls of moving charges
@ -194,7 +196,7 @@ the cgroup that brought it in -- this will happen on memory pressure).
But see section 8.2: when moving a task to another cgroup, its pages may
be recharged to the new cgroup, if move_charge_at_immigrate has been chosen.
Exception: If CONFIG_CGROUP_CGROUP_MEMCG_SWAP is not used.
Exception: If CONFIG_MEMCG_SWAP is not used.
When you do swapoff and make swapped-out pages of shmem(tmpfs) to
be backed into memory in force, charges for pages are accounted against the
caller of swapoff rather than the users of shmem.
@ -762,7 +764,73 @@ At reading, current status of OOM is shown.
under_oom 0 or 1 (if 1, the memory cgroup is under OOM, tasks may
be stopped.)
11. TODO
11. Memory Pressure
The pressure level notifications can be used to monitor the memory
allocation cost; based on the pressure, applications can implement
different strategies of managing their memory resources. The pressure
levels are defined as following:
The "low" level means that the system is reclaiming memory for new
allocations. Monitoring this reclaiming activity might be useful for
maintaining cache level. Upon notification, the program (typically
"Activity Manager") might analyze vmstat and act in advance (i.e.
prematurely shutdown unimportant services).
The "medium" level means that the system is experiencing medium memory
pressure, the system might be making swap, paging out active file caches,
etc. Upon this event applications may decide to further analyze
vmstat/zoneinfo/memcg or internal memory usage statistics and free any
resources that can be easily reconstructed or re-read from a disk.
The "critical" level means that the system is actively thrashing, it is
about to out of memory (OOM) or even the in-kernel OOM killer is on its
way to trigger. Applications should do whatever they can to help the
system. It might be too late to consult with vmstat or any other
statistics, so it's advisable to take an immediate action.
The events are propagated upward until the event is handled, i.e. the
events are not pass-through. Here is what this means: for example you have
three cgroups: A->B->C. Now you set up an event listener on cgroups A, B
and C, and suppose group C experiences some pressure. In this situation,
only group C will receive the notification, i.e. groups A and B will not
receive it. This is done to avoid excessive "broadcasting" of messages,
which disturbs the system and which is especially bad if we are low on
memory or thrashing. So, organize the cgroups wisely, or propagate the
events manually (or, ask us to implement the pass-through events,
explaining why would you need them.)
The file memory.pressure_level is only used to setup an eventfd. To
register a notification, an application must:
- create an eventfd using eventfd(2);
- open memory.pressure_level;
- write string like "<event_fd> <fd of memory.pressure_level> <level>"
to cgroup.event_control.
Application will be notified through eventfd when memory pressure is at
the specific level (or higher). Read/write operations to
memory.pressure_level are no implemented.
Test:
Here is a small script example that makes a new cgroup, sets up a
memory limit, sets up a notification in the cgroup and then makes child
cgroup experience a critical pressure:
# cd /sys/fs/cgroup/memory/
# mkdir foo
# cd foo
# cgroup_event_listener memory.pressure_level low &
# echo 8000000 > memory.limit_in_bytes
# echo 8000000 > memory.memsw.limit_in_bytes
# echo $$ > tasks
# dd if=/dev/zero | read x
(Expect a bunch of notifications, and eventually, the oom-killer will
trigger.)
12. TODO
1. Add support for accounting huge pages (as a separate controller)
2. Make per-cgroup scanner reclaim not-shared pages first

34
Documentation/cgroups/net_cls.txt Normal file
View File

@ -0,0 +1,34 @@
Network classifier cgroup
-------------------------
The Network classifier cgroup provides an interface to
tag network packets with a class identifier (classid).
The Traffic Controller (tc) can be used to assign
different priorities to packets from different cgroups.
Creating a net_cls cgroups instance creates a net_cls.classid file.
This net_cls.classid value is initialized to 0.
You can write hexadecimal values to net_cls.classid; the format for these
values is 0xAAAABBBB; AAAA is the major handle number and BBBB
is the minor handle number.
Reading net_cls.classid yields a decimal result.
Example:
mkdir /sys/fs/cgroup/net_cls
mount -t cgroup -onet_cls net_cls /sys/fs/cgroup/net_cls
mkdir /sys/fs/cgroup/net_cls/0
echo 0x100001 > /sys/fs/cgroup/net_cls/0/net_cls.classid
- setting a 10:1 handle.
cat /sys/fs/cgroup/net_cls/0/net_cls.classid
1048577
configuring tc:
tc qdisc add dev eth0 root handle 10: htb
tc class add dev eth0 parent 10: classid 10:1 htb rate 40mbit
- creating traffic class 10:1
tc filter add dev eth0 parent 10: protocol ip prio 10 handle 1: cgroup

15
Documentation/clk.txt
View File

@ -174,9 +174,9 @@ int clk_foo_enable(struct clk_hw *hw)
};
Below is a matrix detailing which clk_ops are mandatory based upon the
hardware capbilities of that clock. A cell marked as "y" means
hardware capabilities of that clock. A cell marked as "y" means
mandatory, a cell marked as "n" implies that either including that
callback is invalid or otherwise uneccesary. Empty cells are either
callback is invalid or otherwise unnecessary. Empty cells are either
optional or must be evaluated on a case-by-case basis.
clock hardware characteristics
@ -231,3 +231,14 @@ To better enforce this policy, always follow this simple rule: any
statically initialized clock data MUST be defined in a separate file
from the logic that implements its ops. Basically separate the logic
from the data and all is well.
Part 6 - Disabling clock gating of unused clocks
Sometimes during development it can be useful to be able to bypass the
default disabling of unused clocks. For example, if drivers aren't enabling
clocks properly but rely on them being on from the bootloader, bypassing
the disabling means that the driver will remain functional while the issues
are sorted out.
To bypass this disabling, include "clk_ignore_unused" in the bootargs to the
kernel.

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

@ -108,8 +108,9 @@ policy->governor must contain the "default policy" for
cpufreq_driver.target is called with
these values.
For setting some of these values, the frequency table helpers might be
helpful. See the section 2 for more information on them.
For setting some of these values (cpuinfo.min[max]_freq, policy->min[max]), the
frequency table helpers might be helpful. See the section 2 for more information
on them.
SMP systems normally have same clock source for a group of cpus. For these the
.init() would be called only once for the first online cpu. Here the .init()
@ -184,10 +185,10 @@ the reference implementation in drivers/cpufreq/longrun.c
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_freq_table entries, with any value in
of an array of struct cpufreq_frequency_table entries, with any value in
"index" you want to use, and the corresponding frequency in
"frequency". At the end of the table, you need to add a
cpufreq_freq_table entry with frequency set to CPUFREQ_TABLE_END. And
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
CPUFREQ_ENTRY_INVALID. The entries don't need to be in ascending
order.

27
Documentation/cpu-freq/governors.txt
View File

@ -167,6 +167,27 @@ of load evaluation and helping the CPU stay at its top speed when truly
busy, rather than shifting back and forth in speed. This tunable has no
effect on behavior at lower speeds/lower CPU loads.
powersave_bias: this parameter takes a value between 0 to 1000. It
defines the percentage (times 10) value of the target frequency that
will be shaved off of the target. For example, when set to 100 -- 10%,
when ondemand governor would have targeted 1000 MHz, it will target
1000 MHz - (10% of 1000 MHz) = 900 MHz instead. This is set to 0
(disabled) by default.
When AMD frequency sensitivity powersave bias driver --
drivers/cpufreq/amd_freq_sensitivity.c is loaded, this parameter
defines the workload frequency sensitivity threshold in which a lower
frequency is chosen instead of ondemand governor's original target.
The frequency sensitivity is a hardware reported (on AMD Family 16h
Processors and above) value between 0 to 100% that tells software how
the performance of the workload running on a CPU will change when
frequency changes. A workload with sensitivity of 0% (memory/IO-bound)
will not perform any better on higher core frequency, whereas a
workload with sensitivity of 100% (CPU-bound) will perform better
higher the frequency. When the driver is loaded, this is set to 400
by default -- for CPUs running workloads with sensitivity value below
40%, a lower frequency is chosen. Unloading the driver or writing 0
will disable this feature.
2.5 Conservative
----------------
@ -191,6 +212,12 @@ governor but for the opposite direction. For example when set to its
default value of '20' it means that if the CPU usage needs to be below
20% between samples to have the frequency decreased.
sampling_down_factor: similar functionality as in "ondemand" governor.
But in "conservative", it controls the rate at which the kernel makes
a decision on when to decrease the frequency while running in any
speed. Load for frequency increase is still evaluated every
sampling rate.
3. The Governor Interface in the CPUfreq Core
=============================================

6
Documentation/cpuidle/driver.txt
View File

@ -15,11 +15,17 @@ has mechanisms in place to support actual entry-exit into CPU idle states.
cpuidle driver initializes the cpuidle_device structure for each CPU device
and registers with cpuidle using cpuidle_register_device.
If all the idle states are the same, the wrapper function cpuidle_register
could be used instead.
It can also support the dynamic changes (like battery <-> AC), by using
cpuidle_pause_and_lock, cpuidle_disable_device and cpuidle_enable_device,
cpuidle_resume_and_unlock.
Interfaces:
extern int cpuidle_register(struct cpuidle_driver *drv,
const struct cpumask *const coupled_cpus);
extern int cpuidle_unregister(struct cpuidle_driver *drv);
extern int cpuidle_register_driver(struct cpuidle_driver *drv);
extern void cpuidle_unregister_driver(struct cpuidle_driver *drv);
extern int cpuidle_register_device(struct cpuidle_device *dev);

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

@ -1,10 +1,13 @@
dm-raid
-------
=======
The device-mapper RAID (dm-raid) target provides a bridge from DM to MD.
It allows the MD RAID drivers to be accessed using a device-mapper
interface.
Mapping Table Interface
-----------------------
The target is named "raid" and it accepts the following parameters:
<raid_type> <#raid_params> <raid_params> \
@ -47,7 +50,7 @@ The target is named "raid" and it accepts the following parameters:
followed by optional parameters (in any order):
[sync|nosync] Force or prevent RAID initialization.
[rebuild <idx>] Rebuild drive number idx (first drive is 0).
[rebuild <idx>] Rebuild drive number 'idx' (first drive is 0).
[daemon_sleep <ms>]
Interval between runs of the bitmap daemon that
@ -56,9 +59,9 @@ The target is named "raid" and it accepts the following parameters:
[min_recovery_rate <kB/sec/disk>] Throttle RAID initialization
[max_recovery_rate <kB/sec/disk>] Throttle RAID initialization
[write_mostly <idx>] Drive index is write-mostly
[max_write_behind <sectors>] See '-write-behind=' (man mdadm)
[stripe_cache <sectors>] Stripe cache size (higher RAIDs only)
[write_mostly <idx>] Mark drive index 'idx' write-mostly.
[max_write_behind <sectors>] See '--write-behind=' (man mdadm)
[stripe_cache <sectors>] Stripe cache size (RAID 4/5/6 only)
[region_size <sectors>]
The region_size multiplied by the number of regions is the
logical size of the array. The bitmap records the device
@ -122,7 +125,7 @@ The target is named "raid" and it accepts the following parameters:
given for both the metadata and data drives for a given position.
Example tables
Example Tables
--------------
# RAID4 - 4 data drives, 1 parity (no metadata devices)
# No metadata devices specified to hold superblock/bitmap info
@ -141,26 +144,70 @@ Example tables
raid4 4 2048 sync min_recovery_rate 20 \
5 8:17 8:18 8:33 8:34 8:49 8:50 8:65 8:66 8:81 8:82
Status Output
-------------
'dmsetup table' displays the table used to construct the mapping.
The optional parameters are always printed in the order listed
above with "sync" or "nosync" always output ahead of the other
arguments, regardless of the order used when originally loading the table.
Arguments that can be repeated are ordered by value.
'dmsetup status' yields information on the state and health of the
array.
The output is as follows:
'dmsetup status' yields information on the state and health of the array.
The output is as follows (normally a single line, but expanded here for
clarity):
1: <s> <l> raid \
2: <raid_type> <#devices> <1 health char for each dev> <resync_ratio>
2: <raid_type> <#devices> <health_chars> \
3: <sync_ratio> <sync_action> <mismatch_cnt>
Line 1 is the standard output produced by device-mapper.
Line 2 is produced by the raid target, and best explained by example:
0 1960893648 raid raid4 5 AAAAA 2/490221568
Line 2 & 3 are produced by the raid target and are best explained by example:
0 1960893648 raid raid4 5 AAAAA 2/490221568 init 0
Here we can see the RAID type is raid4, there are 5 devices - all of
which are 'A'live, and the array is 2/490221568 complete with recovery.
Faulty or missing devices are marked 'D'. Devices that are out-of-sync
are marked 'a'.
which are 'A'live, and the array is 2/490221568 complete with its initial
recovery. Here is a fuller description of the individual fields:
<raid_type> Same as the <raid_type> used to create the array.
<health_chars> One char for each device, indicating: 'A' = alive and
in-sync, 'a' = alive but not in-sync, 'D' = dead/failed.
<sync_ratio> The ratio indicating how much of the array has undergone
the process described by 'sync_action'. If the
'sync_action' is "check" or "repair", then the process
of "resync" or "recover" can be considered complete.
<sync_action> One of the following possible states:
idle - No synchronization action is being performed.
frozen - The current action has been halted.
resync - Array is undergoing its initial synchronization
or is resynchronizing after an unclean shutdown
(possibly aided by a bitmap).
recover - A device in the array is being rebuilt or
replaced.
check - A user-initiated full check of the array is
being performed. All blocks are read and
checked for consistency. The number of
discrepancies found are recorded in
<mismatch_cnt>. No changes are made to the
array by this action.
repair - The same as "check", but discrepancies are
corrected.
reshape - The array is undergoing a reshape.
<mismatch_cnt> The number of discrepancies found between mirror copies
in RAID1/10 or wrong parity values found in RAID4/5/6.
This value is valid only after a "check" of the array
is performed. A healthy array has a 'mismatch_cnt' of 0.
Message Interface
-----------------
The dm-raid target will accept certain actions through the 'message' interface.
('man dmsetup' for more information on the message interface.) These actions
include:
"idle" - Halt the current sync action.
"frozen" - Freeze the current sync action.
"resync" - Initiate/continue a resync.
"recover"- Initiate/continue a recover process.
"check" - Initiate a check (i.e. a "scrub") of the array.
"repair" - Initiate a repair of the array.
"reshape"- Currently unsupported (-EINVAL).
Version History
---------------
@ -171,4 +218,7 @@ Version History
1.3.1 Allow device replacement/rebuild for RAID 10
1.3.2 Fix/improve redundancy checking for RAID10
1.4.0 Non-functional change. Removes arg from mapping function.
1.4.1 Add RAID10 "far" and "offset" algorithm support.
1.4.1 RAID10 fix redundancy validation checks (commit 55ebbb5).
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.

11
Documentation/devicetree/bindings/arm/altera/socfpga-clk-manager.txt Normal file
View File

@ -0,0 +1,11 @@
Altera SOCFPGA Clock Manager
Required properties:
- compatible : "altr,clk-mgr"
- reg : Should contain base address and length for Clock Manager
Example:
clkmgr@ffd04000 {
compatible = "altr,clk-mgr";
reg = <0xffd04000 0x1000>;
};

13
Documentation/devicetree/bindings/arm/atmel-adc.txt
View File

@ -14,9 +14,19 @@ Required properties:
- atmel,adc-status-register: Offset of the Interrupt Status Register
- atmel,adc-trigger-register: Offset of the Trigger Register
- atmel,adc-vref: Reference voltage in millivolts for the conversions
- atmel,adc-res: List of resolution in bits supported by the ADC. List size
must be two at least.
- atmel,adc-res-names: Contains one identifier string for each resolution
in atmel,adc-res property. "lowres" and "highres"
identifiers are required.
Optional properties:
- atmel,adc-use-external: Boolean to enable of external triggers
- atmel,adc-use-res: String corresponding to an identifier from
atmel,adc-res-names property. If not specified, the highest
resolution will be used.
- atmel,adc-sleep-mode: Boolean to enable sleep mode when no conversion
- atmel,adc-sample-hold-time: Sample and Hold Time in microseconds
Optional trigger Nodes:
- Required properties:
@ -40,6 +50,9 @@ adc0: adc@fffb0000 {
atmel,adc-trigger-register = <0x08>;
atmel,adc-use-external;
atmel,adc-vref = <3300>;
atmel,adc-res = <8 10>;
atmel,adc-res-names = "lowres", "highres";
atmel,adc-use-res = "lowres";
trigger@0 {
trigger-name = "external-rising";

19
Documentation/devicetree/bindings/arm/bcm/bcm,kona-timer.txt Normal file
View File

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

18
Documentation/devicetree/bindings/arm/msm/ssbi.txt Normal file
View File

@ -0,0 +1,18 @@
* Qualcomm SSBI
Some Qualcomm MSM devices contain a point-to-point serial bus used to
communicate with a limited range of devices (mostly power management
chips).
These require the following properties:
- compatible: "qcom,ssbi"
- qcom,controller-type
indicates the SSBI bus variant the controller should use to talk
with the slave device. This should be one of "ssbi", "ssbi2", or
"pmic-arbiter". The type chosen is determined by the attached
slave.
The slave device should be the single child node of the ssbi device
with a compatible field.

41
Documentation/devicetree/bindings/arm/msm/timer.txt
View File

@ -3,36 +3,35 @@
Properties:
- compatible : Should at least contain "qcom,msm-timer". More specific
properties such as "qcom,msm-gpt" and "qcom,msm-dgt" specify a general
purpose timer and a debug timer respectively.
properties specify which subsystem the timers are paired with.
- interrupts : Interrupt indicating a match event.
"qcom,kpss-timer" - krait subsystem
"qcom,scss-timer" - scorpion subsystem
- reg : Specifies the base address of the timer registers. The second region
specifies an optional register used to configure the clock divider.
- interrupts : Interrupts for the the debug timer, the first general purpose
timer, and optionally a second general purpose timer in that
order.
- clock-frequency : The frequency of the timer in Hz.
- reg : Specifies the base address of the timer registers.
- clock-frequency : The frequency of the debug timer and the general purpose
timer(s) in Hz in that order.
Optional:
- cpu-offset : per-cpu offset used when the timer is accessed without the
CPU remapping facilities. The offset is cpu-offset * cpu-nr.
CPU remapping facilities. The offset is
cpu-offset + (0x10000 * cpu-nr).
Example:
timer@200a004 {
compatible = "qcom,msm-gpt", "qcom,msm-timer";
interrupts = <1 2 0x301>;
reg = <0x0200a004 0x10>;
clock-frequency = <32768>;
cpu-offset = <0x40000>;
};
timer@200a024 {
compatible = "qcom,msm-dgt", "qcom,msm-timer";
interrupts = <1 3 0x301>;
reg = <0x0200a024 0x10>,
<0x0200a034 0x4>;
clock-frequency = <6750000>;
timer@200a000 {
compatible = "qcom,scss-timer", "qcom,msm-timer";
interrupts = <1 1 0x301>,
<1 2 0x301>,
<1 3 0x301>;
reg = <0x0200a000 0x100>;
clock-frequency = <19200000>,
<32768>;
cpu-offset = <0x40000>;
};

10
Documentation/devicetree/bindings/arm/samsung-boards.txt
View File

@ -6,3 +6,13 @@ Required root node properties:
- compatible = should be one or more of the following.
(a) "samsung,smdkv310" - for Samsung's SMDKV310 eval board.
(b) "samsung,exynos4210" - for boards based on Exynos4210 SoC.
Optional:
- firmware node, specifying presence and type of secure firmware:
- compatible: only "samsung,secure-firmware" is currently supported
- reg: address of non-secure SYSRAM used for communication with firmware
firmware@0203F000 {
compatible = "samsung,secure-firmware";
reg = <0x0203F000 0x1000>;
};

60
Documentation/devicetree/bindings/arm/samsung/exynos-adc.txt Normal file
View File

@ -0,0 +1,60 @@
Samsung Exynos Analog to Digital Converter bindings
The devicetree bindings are for the new ADC driver written for
Exynos4 and upward SoCs from Samsung.
New driver handles the following
1. Supports ADC IF found on EXYNOS4412/EXYNOS5250
and future SoCs from Samsung
2. Add ADC driver under iio/adc framework
3. Also adds the Documentation for device tree bindings
Required properties:
- compatible: Must be "samsung,exynos-adc-v1"
for exynos4412/5250 controllers.
Must be "samsung,exynos-adc-v2" for
future controllers.
- reg: Contains ADC register address range (base address and
length) and the address of the phy enable register.
- interrupts: Contains the interrupt information for the timer. The
format is being dependent on which interrupt controller
the Samsung device uses.
- #io-channel-cells = <1>; As ADC has multiple outputs
- clocks From common clock binding: handle to adc clock.
- clock-names From common clock binding: Shall be "adc".
- vdd-supply VDD input supply.
Note: child nodes can be added for auto probing from device tree.
Example: adding device info in dtsi file
adc: adc@12D10000 {
compatible = "samsung,exynos-adc-v1";
reg = <0x12D10000 0x100>, <0x10040718 0x4>;
interrupts = <0 106 0>;
#io-channel-cells = <1>;
io-channel-ranges;
clocks = <&clock 303>;
clock-names = "adc";
vdd-supply = <&buck5_reg>;
};
Example: Adding child nodes in dts file
adc@12D10000 {
/* NTC thermistor is a hwmon device */
ncp15wb473@0 {
compatible = "ntc,ncp15wb473";
pullup-uV = <1800000>;
pullup-ohm = <47000>;
pulldown-ohm = <0>;
io-channels = <&adc 4>;
};
};
Note: Does not apply to ADC driver under arch/arm/plat-samsung/
Note: The child node can be added under the adc node or separately.

67
Documentation/devicetree/bindings/arm/tegra/nvidia,tegra20-pmc.txt
View File

@ -1,19 +1,84 @@
NVIDIA Tegra Power Management Controller (PMC)
Properties:
The PMC block interacts with an external Power Management Unit. The PMC
mostly controls the entry and exit of the system from different sleep
modes. It provides power-gating controllers for SoC and CPU power-islands.
Required properties:
- name : Should be pmc
- compatible : Should contain "nvidia,tegra<chip>-pmc".
- reg : Offset and length of the register set for the device
- clocks : Must contain an entry for each entry in clock-names.
- clock-names : Must include the following entries:
"pclk" (The Tegra clock of that name),
"clk32k_in" (The 32KHz clock input to Tegra).
Optional properties:
- nvidia,invert-interrupt : If present, inverts the PMU interrupt signal.
The PMU is an external Power Management Unit, whose interrupt output
signal is fed into the PMC. This signal is optionally inverted, and then
fed into the ARM GIC. The PMC is not involved in the detection or
handling of this interrupt signal, merely its inversion.
- nvidia,suspend-mode : The suspend mode that the platform should use.
Valid values are 0, 1 and 2:
0 (LP0): CPU + Core voltage off and DRAM in self-refresh
1 (LP1): CPU voltage off and DRAM in self-refresh
2 (LP2): CPU voltage off
- nvidia,core-power-req-active-high : Boolean, core power request active-high
- nvidia,sys-clock-req-active-high : Boolean, system clock request active-high
- nvidia,combined-power-req : Boolean, combined power request for CPU & Core
- nvidia,cpu-pwr-good-en : Boolean, CPU power good signal (from PMIC to PMC)
is enabled.
Required properties when nvidia,suspend-mode is specified:
- nvidia,cpu-pwr-good-time : CPU power good time in uS.
- nvidia,cpu-pwr-off-time : CPU power off time in uS.
- nvidia,core-pwr-good-time : <Oscillator-stable-time Power-stable-time>
Core power good time in uS.
- nvidia,core-pwr-off-time : Core power off time in uS.
Required properties when nvidia,suspend-mode=<0>:
- nvidia,lp0-vec : <start length> Starting address and length of LP0 vector
The LP0 vector contains the warm boot code that is executed by AVP when
resuming from the LP0 state. The AVP (Audio-Video Processor) is an ARM7
processor and always being the first boot processor when chip is power on
or resume from deep sleep mode. When the system is resumed from the deep
sleep mode, the warm boot code will restore some PLLs, clocks and then
bring up CPU0 for resuming the system.
Example:
/ SoC dts including file
pmc@7000f400 {
compatible = "nvidia,tegra20-pmc";
reg = <0x7000e400 0x400>;
clocks = <&tegra_car 110>, <&clk32k_in>;
clock-names = "pclk", "clk32k_in";
nvidia,invert-interrupt;
nvidia,suspend-mode = <1>;
nvidia,cpu-pwr-good-time = <2000>;
nvidia,cpu-pwr-off-time = <100>;
nvidia,core-pwr-good-time = <3845 3845>;
nvidia,core-pwr-off-time = <458>;
nvidia,core-power-req-active-high;
nvidia,sys-clock-req-active-high;
nvidia,lp0-vec = <0xbdffd000 0x2000>;
};
/ Tegra board dts file
{
...
clocks {
compatible = "simple-bus";
#address-cells = <1>;
#size-cells = <0>;
clk32k_in: clock {
compatible = "fixed-clock";
reg=<0>;
#clock-cells = <0>;
clock-frequency = <32768>;
};
};
...
};

17
Documentation/devicetree/bindings/ata/imx-pata.txt Normal file
View File

@ -0,0 +1,17 @@
* Freescale i.MX PATA Controller
Required properties:
- compatible: "fsl,imx27-pata"
- reg: Address range of the PATA Controller
- interrupts: The interrupt of the PATA Controller
- clocks: the clocks for the PATA Controller
Example:
pata: pata@83fe0000 {
compatible = "fsl,imx51-pata", "fsl,imx27-pata";
reg = <0x83fe0000 0x4000>;
interrupts = <70>;
clocks = <&clks 161>;
status = "disabled";
};

91
Documentation/devicetree/bindings/bus/ti-gpmc.txt
View File

@ -35,36 +35,83 @@ Required properties:
Timing properties for child nodes. All are optional and default to 0.
- gpmc,sync-clk: Minimum clock period for synchronous mode, in picoseconds
- gpmc,sync-clk-ps: Minimum clock period for synchronous mode, in picoseconds
Chip-select signal timings corresponding to GPMC_CONFIG2:
- gpmc,cs-on: Assertion time
- gpmc,cs-rd-off: Read deassertion time
- gpmc,cs-wr-off: Write deassertion time
Chip-select signal timings (in nanoseconds) corresponding to GPMC_CONFIG2:
- gpmc,cs-on-ns: Assertion time
- gpmc,cs-rd-off-ns: Read deassertion time
- gpmc,cs-wr-off-ns: Write deassertion time
ADV signal timings corresponding to GPMC_CONFIG3:
- gpmc,adv-on: Assertion time
- gpmc,adv-rd-off: Read deassertion time
- gpmc,adv-wr-off: Write deassertion time
ADV signal timings (in nanoseconds) corresponding to GPMC_CONFIG3:
- gpmc,adv-on-ns: Assertion time
- gpmc,adv-rd-off-ns: Read deassertion time
- gpmc,adv-wr-off-ns: Write deassertion time
WE signals timings corresponding to GPMC_CONFIG4:
- gpmc,we-on: Assertion time
- gpmc,we-off: Deassertion time
WE signals timings (in nanoseconds) corresponding to GPMC_CONFIG4:
- gpmc,we-on-ns Assertion time
- gpmc,we-off-ns: Deassertion time
OE signals timings corresponding to GPMC_CONFIG4:
- gpmc,oe-on: Assertion time
- gpmc,oe-off: Deassertion time
OE signals timings (in nanoseconds) corresponding to GPMC_CONFIG4:
- gpmc,oe-on-ns: Assertion time
- gpmc,oe-off-ns: Deassertion time
Access time and cycle time timings corresponding to GPMC_CONFIG5:
- gpmc,page-burst-access: Multiple access word delay
- gpmc,access: Start-cycle to first data valid delay
- gpmc,rd-cycle: Total read cycle time
- gpmc,wr-cycle: Total write cycle time
Access time and cycle time timings (in nanoseconds) corresponding to
GPMC_CONFIG5:
- gpmc,page-burst-access-ns: Multiple access word delay
- gpmc,access-ns: Start-cycle to first data valid delay
- gpmc,rd-cycle-ns: Total read cycle time
- gpmc,wr-cycle-ns: Total write cycle time
- gpmc,bus-turnaround-ns: Turn-around time between successive accesses
- gpmc,cycle2cycle-delay-ns: Delay between chip-select pulses
- gpmc,clk-activation-ns: GPMC clock activation time
- gpmc,wait-monitoring-ns: Start of wait monitoring with regard to valid
data
Boolean timing parameters. If property is present parameter enabled and
disabled if omitted:
- gpmc,adv-extra-delay: ADV signal is delayed by half GPMC clock
- gpmc,cs-extra-delay: CS signal is delayed by half GPMC clock
- gpmc,cycle2cycle-diffcsen: Add "cycle2cycle-delay" between successive
accesses to a different CS
- gpmc,cycle2cycle-samecsen: Add "cycle2cycle-delay" between successive
accesses to the same CS
- gpmc,oe-extra-delay: OE signal is delayed by half GPMC clock
- gpmc,we-extra-delay: WE signal is delayed by half GPMC clock
- gpmc,time-para-granularity: Multiply all access times by 2
The following are only applicable to OMAP3+ and AM335x:
- gpmc,wr-access
- gpmc,wr-data-mux-bus
- gpmc,wr-access-ns: In synchronous write mode, for single or
burst accesses, defines the number of
GPMC_FCLK cycles from start access time
to the GPMC_CLK rising edge used by the
memory device for the first data capture.
- gpmc,wr-data-mux-bus-ns: In address-data multiplex mode, specifies
the time when the first data is driven on
the address-data bus.
GPMC chip-select settings properties for child nodes. All are optional.
- gpmc,burst-length Page/burst length. Must be 4, 8 or 16.
- gpmc,burst-wrap Enables wrap bursting
- gpmc,burst-read Enables read page/burst mode
- gpmc,burst-write Enables write page/burst mode
- gpmc,device-nand Device is NAND
- gpmc,device-width Total width of device(s) connected to a GPMC
chip-select in bytes. The GPMC supports 8-bit
and 16-bit devices and so this property must be
1 or 2.
- gpmc,mux-add-data Address and data multiplexing configuration.
Valid values are 1 for address-address-data
multiplexing mode and 2 for address-data
multiplexing mode.
- gpmc,sync-read Enables synchronous read. Defaults to asynchronous
is this is not set.
- gpmc,sync-write Enables synchronous writes. Defaults to asynchronous
is this is not set.
- gpmc,wait-pin Wait-pin used by client. Must be less than
"gpmc,num-waitpins".
- gpmc,wait-on-read Enables wait monitoring on reads.
- gpmc,wait-on-write Enables wait monitoring on writes.
Example for an AM33xx board:

18
Documentation/devicetree/bindings/clock/altr_socfpga.txt Normal file
View File

@ -0,0 +1,18 @@
Device Tree Clock bindings for Altera's SoCFPGA platform
This binding uses the common clock binding[1].
[1] Documentation/devicetree/bindings/clock/clock-bindings.txt
Required properties:
- compatible : shall be one of the following:
"altr,socfpga-pll-clock" - for a PLL clock
"altr,socfpga-perip-clock" - The peripheral clock divided from the
PLL clock.
- reg : shall be the control register offset from CLOCK_MANAGER's base for the clock.
- clocks : shall be the input parent clock phandle for the clock. This is
either an oscillator or a pll output.
- #clock-cells : from common clock binding, shall be set to 0.
Optional properties:
- fixed-divider : If clocks have a fixed divider value, use this property.

22
Documentation/devicetree/bindings/clock/axi-clkgen.txt Normal file
View File

@ -0,0 +1,22 @@
Binding for the axi-clkgen clock generator
This binding uses the common clock binding[1].
[1] Documentation/devicetree/bindings/clock/clock-bindings.txt
Required properties:
- compatible : shall be "adi,axi-clkgen".
- #clock-cells : from common clock binding; Should always be set to 0.
- reg : Address and length of the axi-clkgen register set.
- clocks : Phandle and clock specifier for the parent clock.
Optional properties:
- clock-output-names : From common clock binding.
Example:
clock@0xff000000 {
compatible = "adi,axi-clkgen";
#clock-cells = <0>;
reg = <0xff000000 0x1000>;
clocks = <&osc 1>;
};

288
Documentation/devicetree/bindings/clock/exynos4-clock.txt Normal file
View File

@ -0,0 +1,288 @@
* Samsung Exynos4 Clock Controller
The Exynos4 clock controller generates and supplies clock to various controllers
within the Exynos4 SoC. The clock binding described here is applicable to all
SoC's in the Exynos4 family.
Required Properties:
- comptible: should be one of the following.
- "samsung,exynos4210-clock" - controller compatible with Exynos4210 SoC.
- "samsung,exynos4412-clock" - controller compatible with Exynos4412 SoC.
- reg: physical base address of the controller and length of memory mapped
region.
- #clock-cells: should be 1.
The following is the list of clocks generated by the controller. Each clock is
assigned an identifier and client nodes use this identifier to specify the
clock which they consume. Some of the clocks are available only on a particular
Exynos4 SoC and this is specified where applicable.
[Core Clocks]
Clock ID SoC (if specific)
-----------------------------------------------
xxti 1
xusbxti 2
fin_pll 3
fout_apll 4
fout_mpll 5
fout_epll 6
fout_vpll 7
sclk_apll 8
sclk_mpll 9
sclk_epll 10
sclk_vpll 11
arm_clk 12
aclk200 13
aclk100 14
aclk160 15
aclk133 16
mout_mpll_user_t 17 Exynos4x12
mout_mpll_user_c 18 Exynos4x12
mout_core 19
mout_apll 20
[Clock Gate for Special Clocks]
Clock ID SoC (if specific)
-----------------------------------------------
sclk_fimc0 128
sclk_fimc1 129
sclk_fimc2 130
sclk_fimc3 131
sclk_cam0 132
sclk_cam1 133
sclk_csis0 134
sclk_csis1 135
sclk_hdmi 136
sclk_mixer 137
sclk_dac 138
sclk_pixel 139
sclk_fimd0 140
sclk_mdnie0 141 Exynos4412
sclk_mdnie_pwm0 12 142 Exynos4412
sclk_mipi0 143
sclk_audio0 144
sclk_mmc0 145
sclk_mmc1 146
sclk_mmc2 147
sclk_mmc3 148
sclk_mmc4 149
sclk_sata 150 Exynos4210
sclk_uart0 151
sclk_uart1 152
sclk_uart2 153
sclk_uart3 154
sclk_uart4 155
sclk_audio1 156
sclk_audio2 157
sclk_spdif 158
sclk_spi0 159
sclk_spi1 160
sclk_spi2 161
sclk_slimbus 162
sclk_fimd1 163 Exynos4210
sclk_mipi1 164 Exynos4210
sclk_pcm1 165
sclk_pcm2 166
sclk_i2s1 167
sclk_i2s2 168
sclk_mipihsi 169 Exynos4412
sclk_mfc 170
sclk_pcm0 171
sclk_g3d 172
sclk_pwm_isp 173 Exynos4x12
sclk_spi0_isp 174 Exynos4x12
sclk_spi1_isp 175 Exynos4x12
sclk_uart_isp 176 Exynos4x12
[Peripheral Clock Gates]
Clock ID SoC (if specific)
-----------------------------------------------
fimc0 256
fimc1 257
fimc2 258
fimc3 259
csis0 260
csis1 261
jpeg 262
smmu_fimc0 263
smmu_fimc1 264
smmu_fimc2 265
smmu_fimc3 266
smmu_jpeg 267
vp 268
mixer 269
tvenc 270 Exynos4210
hdmi 271
smmu_tv 272
mfc 273
smmu_mfcl 274
smmu_mfcr 275
g3d 276
g2d 277 Exynos4210
rotator 278 Exynos4210
mdma 279 Exynos4210
smmu_g2d 280 Exynos4210
smmu_rotator 281 Exynos4210
smmu_mdma 282 Exynos4210
fimd0 283
mie0 284
mdnie0 285 Exynos4412
dsim0 286
smmu_fimd0 287
fimd1 288 Exynos4210
mie1 289 Exynos4210
dsim1 290 Exynos4210
smmu_fimd1 291 Exynos4210
pdma0 292
pdma1 293
pcie_phy 294
sata_phy 295 Exynos4210
tsi 296
sdmmc0 297
sdmmc1 298
sdmmc2 299
sdmmc3 300
sdmmc4 301
sata 302 Exynos4210
sromc 303
usb_host 304
usb_device 305
pcie 306
onenand 307
nfcon 308
smmu_pcie 309
gps 310
smmu_gps 311
uart0 312
uart1 313
uart2 314
uart3 315
uart4 316
i2c0 317
i2c1 318
i2c2 319
i2c3 320
i2c4 321
i2c5 322
i2c6 323
i2c7 324
i2c_hdmi 325
tsadc 326
spi0 327
spi1 328
spi2 329
i2s1 330
i2s2 331
pcm0 332
i2s0 333
pcm1 334
pcm2 335
pwm 336
slimbus 337
spdif 338
ac97 339
modemif 340
chipid 341
sysreg 342
hdmi_cec 343
mct 344
wdt 345
rtc 346
keyif 347
audss 348
mipi_hsi 349 Exynos4210
mdma2 350 Exynos4210
pixelasyncm0 351
pixelasyncm1 352
fimc_lite0 353 Exynos4x12
fimc_lite1 354 Exynos4x12
ppmuispx 355 Exynos4x12
ppmuispmx 356 Exynos4x12
fimc_isp 357 Exynos4x12
fimc_drc 358 Exynos4x12
fimc_fd 359 Exynos4x12
mcuisp 360 Exynos4x12
gicisp 361 Exynos4x12
smmu_isp 362 Exynos4x12
smmu_drc 363 Exynos4x12
smmu_fd 364 Exynos4x12
smmu_lite0 365 Exynos4x12
smmu_lite1 366 Exynos4x12
mcuctl_isp 367 Exynos4x12
mpwm_isp 368 Exynos4x12
i2c0_isp 369 Exynos4x12
i2c1_isp 370 Exynos4x12
mtcadc_isp 371 Exynos4x12
pwm_isp 372 Exynos4x12
wdt_isp 373 Exynos4x12
uart_isp 374 Exynos4x12
asyncaxim 375 Exynos4x12
smmu_ispcx 376 Exynos4x12
spi0_isp 377 Exynos4x12
spi1_isp 378 Exynos4x12
pwm_isp_sclk 379 Exynos4x12
spi0_isp_sclk 380 Exynos4x12
spi1_isp_sclk 381 Exynos4x12
uart_isp_sclk 382 Exynos4x12
[Mux Clocks]
Clock ID SoC (if specific)
-----------------------------------------------
mout_fimc0 384
mout_fimc1 385
mout_fimc2 386
mout_fimc3 387
mout_cam0 388
mout_cam1 389
mout_csis0 390
mout_csis1 391
mout_g3d0 392
mout_g3d1 393
mout_g3d 394
aclk400_mcuisp 395 Exynos4x12
[Div Clocks]
Clock ID SoC (if specific)
-----------------------------------------------
div_isp0 450 Exynos4x12
div_isp1 451 Exynos4x12
div_mcuisp0 452 Exynos4x12
div_mcuisp1 453 Exynos4x12
div_aclk200 454 Exynos4x12
div_aclk400_mcuisp 455 Exynos4x12
Example 1: An example of a clock controller node is listed below.
clock: clock-controller@0x10030000 {
compatible = "samsung,exynos4210-clock";
reg = <0x10030000 0x20000>;
#clock-cells = <1>;
};
Example 2: UART controller node that consumes the clock generated by the clock
controller. Refer to the standard clock bindings for information
about 'clocks' and 'clock-names' property.
serial@13820000 {
compatible = "samsung,exynos4210-uart";
reg = <0x13820000 0x100>;
interrupts = <0 54 0>;
clocks = <&clock 314>, <&clock 153>;
clock-names = "uart", "clk_uart_baud0";
};

177
Documentation/devicetree/bindings/clock/exynos5250-clock.txt Normal file
View File

@ -0,0 +1,177 @@
* Samsung Exynos5250 Clock Controller
The Exynos5250 clock controller generates and supplies clock to various
controllers within the Exynos5250 SoC.
Required Properties:
- comptible: should be one of the following.
- "samsung,exynos5250-clock" - controller compatible with Exynos5250 SoC.
- reg: physical base address of the controller and length of memory mapped
region.
- #clock-cells: should be 1.
The following is the list of clocks generated by the controller. Each clock is
assigned an identifier and client nodes use this identifier to specify the
clock which they consume.
[Core Clocks]
Clock ID
----------------------------
fin_pll 1
[Clock Gate for Special Clocks]
Clock ID
----------------------------
sclk_cam_bayer 128
sclk_cam0 129
sclk_cam1 130
sclk_gscl_wa 131
sclk_gscl_wb 132
sclk_fimd1 133
sclk_mipi1 134
sclk_dp 135
sclk_hdmi 136
sclk_pixel 137
sclk_audio0 138
sclk_mmc0 139
sclk_mmc1 140
sclk_mmc2 141
sclk_mmc3 142
sclk_sata 143
sclk_usb3 144
sclk_jpeg 145
sclk_uart0 146
sclk_uart1 147
sclk_uart2 148
sclk_uart3 149
sclk_pwm 150
sclk_audio1 151
sclk_audio2 152
sclk_spdif 153
sclk_spi0 154
sclk_spi1 155
sclk_spi2 156
[Peripheral Clock Gates]
Clock ID
----------------------------
gscl0 256
gscl1 257
gscl2 258
gscl3 259
gscl_wa 260
gscl_wb 261
smmu_gscl0 262
smmu_gscl1 263
smmu_gscl2 264
smmu_gscl3 265
mfc 266
smmu_mfcl 267
smmu_mfcr 268
rotator 269
jpeg 270
mdma1 271
smmu_rotator 272
smmu_jpeg 273
smmu_mdma1 274
pdma0 275
pdma1 276
sata 277
usbotg 278
mipi_hsi 279
sdmmc0 280
sdmmc1 281
sdmmc2 282
sdmmc3 283
sromc 284
usb2 285
usb3 286
sata_phyctrl 287
sata_phyi2c 288
uart0 289
uart1 290
uart2 291
uart3 292
uart4 293
i2c0 294
i2c1 295
i2c2 296
i2c3 297
i2c4 298
i2c5 299
i2c6 300
i2c7 301
i2c_hdmi 302
adc 303
spi0 304
spi1 305
spi2 306
i2s1 307
i2s2 308
pcm1 309
pcm2 310
pwm 311
spdif 312
ac97 313
hsi2c0 314
hsi2c1 315
hs12c2 316
hs12c3 317
chipid 318
sysreg 319
pmu 320
cmu_top 321
cmu_core 322
cmu_mem 323
tzpc0 324
tzpc1 325
tzpc2 326
tzpc3 327
tzpc4 328
tzpc5 329
tzpc6 330
tzpc7 331
tzpc8 332
tzpc9 333
hdmi_cec 334
mct 335
wdt 336
rtc 337
tmu 338
fimd1 339
mie1 340
dsim0 341
dp 342
mixer 343
hdmi 345
Example 1: An example of a clock controller node is listed below.
clock: clock-controller@0x10010000 {
compatible = "samsung,exynos5250-clock";
reg = <0x10010000 0x30000>;
#clock-cells = <1>;
};
Example 2: UART controller node that consumes the clock generated by the clock
controller. Refer to the standard clock bindings for information
about 'clocks' and 'clock-names' property.
serial@13820000 {
compatible = "samsung,exynos4210-uart";
reg = <0x13820000 0x100>;
interrupts = <0 54 0>;
clocks = <&clock 314>, <&clock 153>;
clock-names = "uart", "clk_uart_baud0";
};

61
Documentation/devicetree/bindings/clock/exynos5440-clock.txt Normal file
View File

@ -0,0 +1,61 @@
* Samsung Exynos5440 Clock Controller
The Exynos5440 clock controller generates and supplies clock to various
controllers within the Exynos5440 SoC.
Required Properties:
- comptible: should be "samsung,exynos5440-clock".
- reg: physical base address of the controller and length of memory mapped
region.
- #clock-cells: should be 1.
The following is the list of clocks generated by the controller. Each clock is
assigned an identifier and client nodes use this identifier to specify the
clock which they consume.
[Core Clocks]
Clock ID
----------------------------
xtal 1
arm_clk 2
[Peripheral Clock Gates]
Clock ID
----------------------------
spi_baud 16
pb0_250 17
pr0_250 18
pr1_250 19
b_250 20
b_125 21
b_200 22
sata 23
usb 24
gmac0 25
cs250 26
pb0_250_o 27
pr0_250_o 28
pr1_250_o 29
b_250_o 30
b_125_o 31
b_200_o 32
sata_o 33
usb_o 34
gmac0_o 35
cs250_o 36
Example: An example of a clock controller node is listed below.
clock: clock-controller@0x10010000 {
compatible = "samsung,exynos5440-clock";
reg = <0x160000 0x10000>;
#clock-cells = <1>;
};

24
Documentation/devicetree/bindings/clock/fixed-factor-clock.txt Normal file
View File

@ -0,0 +1,24 @@
Binding for simple fixed factor rate clock sources.
This binding uses the common clock binding[1].
[1] Documentation/devicetree/bindings/clock/clock-bindings.txt
Required properties:
- compatible : shall be "fixed-factor-clock".
- #clock-cells : from common clock binding; shall be set to 0.
- clock-div: fixed divider.
- clock-mult: fixed multiplier.
- clocks: parent clock.
Optional properties:
- clock-output-names : From common clock binding.
Example:
clock {
compatible = "fixed-factor-clock";
clocks = <&parentclk>;
#clock-cells = <0>;
div = <2>;
mult = <1>;
};

117
Documentation/devicetree/bindings/clock/imx27-clock.txt Normal file
View File

@ -0,0 +1,117 @@
* Clock bindings for Freescale i.MX27
Required properties:
- compatible: Should be "fsl,imx27-ccm"
- reg: Address and length of the register set
- interrupts: Should contain CCM interrupt
- #clock-cells: Should be <1>
The clock consumer should specify the desired clock by having the clock
ID in its "clocks" phandle cell. The following is a full list of i.MX27
clocks and IDs.
Clock ID
-----------------------
dummy 0
ckih 1
ckil 2
mpll 3
spll 4
mpll_main2 5
ahb 6
ipg 7
nfc_div 8
per1_div 9
per2_div 10
per3_div 11
per4_div 12
vpu_sel 13
vpu_div 14
usb_div 15
cpu_sel 16
clko_sel 17
cpu_div 18
clko_div 19
ssi1_sel 20
ssi2_sel 21
ssi1_div 22
ssi2_div 23
clko_en 24
ssi2_ipg_gate 25
ssi1_ipg_gate 26
slcdc_ipg_gate 27
sdhc3_ipg_gate 28
sdhc2_ipg_gate 29
sdhc1_ipg_gate 30
scc_ipg_gate 31
sahara_ipg_gate 32
rtc_ipg_gate 33
pwm_ipg_gate 34
owire_ipg_gate 35
lcdc_ipg_gate 36
kpp_ipg_gate 37
iim_ipg_gate 38
i2c2_ipg_gate 39
i2c1_ipg_gate 40
gpt6_ipg_gate 41
gpt5_ipg_gate 42
gpt4_ipg_gate 43
gpt3_ipg_gate 44
gpt2_ipg_gate 45
gpt1_ipg_gate 46
gpio_ipg_gate 47
fec_ipg_gate 48
emma_ipg_gate 49
dma_ipg_gate 50
cspi3_ipg_gate 51
cspi2_ipg_gate 52
cspi1_ipg_gate 53
nfc_baud_gate 54
ssi2_baud_gate 55
ssi1_baud_gate 56
vpu_baud_gate 57
per4_gate 58
per3_gate 59
per2_gate 60
per1_gate 61
usb_ahb_gate 62
slcdc_ahb_gate 63
sahara_ahb_gate 64
lcdc_ahb_gate 65
vpu_ahb_gate 66
fec_ahb_gate 67
emma_ahb_gate 68
emi_ahb_gate 69
dma_ahb_gate 70
csi_ahb_gate 71
brom_ahb_gate 72
ata_ahb_gate 73
wdog_ipg_gate 74
usb_ipg_gate 75
uart6_ipg_gate 76
uart5_ipg_gate 77
uart4_ipg_gate 78
uart3_ipg_gate 79
uart2_ipg_gate 80
uart1_ipg_gate 81
ckih_div1p5 82
fpm 83
mpll_osc_sel 84
mpll_sel 85
Examples:
clks: ccm@10027000{
compatible = "fsl,imx27-ccm";
reg = <0x10027000 0x1000>;
#clock-cells = <1>;
};
uart1: serial@1000a000 {
compatible = "fsl,imx27-uart", "fsl,imx21-uart";
reg = <0x1000a000 0x1000>;
interrupts = <20>;
clocks = <&clks 81>, <&clks 61>;
clock-names = "ipg", "per";
status = "disabled";
};

303
Documentation/devicetree/bindings/clock/nvidia,tegra114-car.txt Normal file
View File

@ -0,0 +1,303 @@
NVIDIA Tegra114 Clock And Reset Controller
This binding uses the common clock binding:
Documentation/devicetree/bindings/clock/clock-bindings.txt
The CAR (Clock And Reset) Controller on Tegra is the HW module responsible
for muxing and gating Tegra's clocks, and setting their rates.
Required properties :
- compatible : Should be "nvidia,tegra114-car"
- reg : Should contain CAR registers location and length
- clocks : Should contain phandle and clock specifiers for two clocks:
the 32 KHz "32k_in", and the board-specific oscillator "osc".
- #clock-cells : Should be 1.
In clock consumers, this cell represents the clock ID exposed by the CAR.
The first 160 clocks are numbered to match the bits in the CAR's CLK_OUT_ENB
registers. These IDs often match those in the CAR's RST_DEVICES registers,
but not in all cases. Some bits in CLK_OUT_ENB affect multiple clocks. In
this case, those clocks are assigned IDs above 160 in order to highlight
this issue. Implementations that interpret these clock IDs as bit values
within the CLK_OUT_ENB or RST_DEVICES registers should be careful to
explicitly handle these special cases.
The balance of the clocks controlled by the CAR are assigned IDs of 160 and
above.
0 unassigned
1 unassigned
2 unassigned
3 unassigned
4 rtc
5 timer
6 uarta
7 unassigned (register bit affects uartb and vfir)
8 unassigned
9 sdmmc2
10 unassigned (register bit affects spdif_in and spdif_out)
11 i2s1
12 i2c1
13 ndflash
14 sdmmc1
15 sdmmc4
16 unassigned
17 pwm
18 i2s2
19 epp
20 unassigned (register bit affects vi and vi_sensor)
21 2d
22 usbd
23 isp
24 3d
25 unassigned
26 disp2
27 disp1
28 host1x
29 vcp
30 i2s0
31 unassigned
32 unassigned
33 unassigned
34 apbdma
35 unassigned
36 kbc
37 unassigned
38 unassigned
39 unassigned (register bit affects fuse and fuse_burn)
40 kfuse
41 sbc1
42 nor
43 unassigned
44 sbc2
45 unassigned
46 sbc3
47 i2c5
48 dsia
49 unassigned
50 mipi
51 hdmi
52 csi
53 unassigned
54 i2c2
55 uartc
56 mipi-cal
57 emc
58 usb2
59 usb3
60 msenc
61 vde
62 bsea
63 bsev
64 unassigned
65 uartd
66 unassigned
67 i2c3
68 sbc4
69 sdmmc3
70 unassigned
71 owr
72 afi
73 csite
74 unassigned
75 unassigned
76 la
77 trace
78 soc_therm
79 dtv
80 ndspeed
81 i2cslow
82 dsib
83 tsec
84 unassigned
85 unassigned
86 unassigned
87 unassigned
88 unassigned
89 xusb_host
90 unassigned
91 msenc
92 csus
93 unassigned
94 unassigned
95 unassigned (bit affects xusb_dev and xusb_dev_src)
96 unassigned
97 unassigned
98 unassigned
99 mselect
100 tsensor
101 i2s3
102 i2s4
103 i2c4
104 sbc5
105 sbc6
106 d_audio
107 apbif
108 dam0
109 dam1
110 dam2
111 hda2codec_2x
112 unassigned
113 audio0_2x
114 audio1_2x
115 audio2_2x
116 audio3_2x
117 audio4_2x
118 spdif_2x
119 actmon
120 extern1
121 extern2
122 extern3
123 unassigned
124 unassigned
125 hda
126 unassigned
127 se
128 hda2hdmi
129 unassigned
130 unassigned
131 unassigned
132 unassigned
133 unassigned
134 unassigned
135 unassigned
136 unassigned
137 unassigned
138 unassigned
139 unassigned
140 unassigned
141 unassigned
142 unassigned
143 unassigned (bit affects xusb_falcon_src, xusb_fs_src,
xusb_host_src and xusb_ss_src)
144 cilab
145 cilcd
146 cile
147 dsialp
148 dsiblp
149 unassigned
150 dds
151 unassigned
152 dp2
153 amx
154 adx
155 unassigned (bit affects dfll_ref and dfll_soc)
156 xusb_ss
192 uartb
193 vfir
194 spdif_in
195 spdif_out
196 vi
197 vi_sensor
198 fuse
199 fuse_burn
200 clk_32k
201 clk_m
202 clk_m_div2
203 clk_m_div4
204 pll_ref
205 pll_c
206 pll_c_out1
207 pll_c2
208 pll_c3
209 pll_m
210 pll_m_out1
211 pll_p
212 pll_p_out1
213 pll_p_out2
214 pll_p_out3
215 pll_p_out4
216 pll_a
217 pll_a_out0
218 pll_d
219 pll_d_out0
220 pll_d2
221 pll_d2_out0
222 pll_u
223 pll_u_480M
224 pll_u_60M
225 pll_u_48M
226 pll_u_12M
227 pll_x
228 pll_x_out0
229 pll_re_vco
230 pll_re_out
231 pll_e_out0
232 spdif_in_sync
233 i2s0_sync
234 i2s1_sync
235 i2s2_sync
236 i2s3_sync
237 i2s4_sync
238 vimclk_sync
239 audio0
240 audio1
241 audio2
242 audio3
243 audio4
244 spdif
245 clk_out_1
246 clk_out_2
247 clk_out_3
248 blink
252 xusb_host_src
253 xusb_falcon_src
254 xusb_fs_src
255 xusb_ss_src
256 xusb_dev_src
257 xusb_dev
258 xusb_hs_src
259 sclk
260 hclk
261 pclk
262 cclk_g
263 cclk_lp
264 dfll_ref
265 dfll_soc
Example SoC include file:
/ {
tegra_car: clock {
compatible = "nvidia,tegra114-car";
reg = <0x60006000 0x1000>;
#clock-cells = <1>;
};
usb@c5004000 {
clocks = <&tegra_car 58>; /* usb2 */
};
};
Example board file:
/ {
clocks {
compatible = "simple-bus";
#address-cells = <1>;
#size-cells = <0>;
osc: clock@0 {
compatible = "fixed-clock";
reg = <0>;
#clock-cells = <0>;
clock-frequency = <12000000>;
};
clk_32k: clock@1 {
compatible = "fixed-clock";
reg = <1>;
#clock-cells = <0>;
clock-frequency = <32768>;
};
};
&tegra_car {
clocks = <&clk_32k> <&osc>;
};
};

4
Documentation/devicetree/bindings/clock/nvidia,tegra20-car.txt
View File

@ -120,8 +120,8 @@ Required properties :
90 clk_d
91 unassigned
92 sus
93 cdev1
94 cdev2
93 cdev2
94 cdev1
95 unassigned
96 uart2

114
Documentation/devicetree/bindings/clock/silabs,si5351.txt Normal file
View File

@ -0,0 +1,114 @@
Binding for Silicon Labs Si5351a/b/c programmable i2c clock generator.
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
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].
==I2C device node==
Required properties:
- compatible: shall be one of "silabs,si5351{a,a-msop,b,c}".
- reg: i2c device address, shall be 0x60 or 0x61.
- #clock-cells: from common clock binding; shall be set to 1.
- clocks: from common clock binding; list of parent clock
handles, shall be xtal reference clock or xtal and clkin for
si5351c only.
- #address-cells: shall be set to 1.
- #size-cells: shall be set to 0.
Optional properties:
- silabs,pll-source: pair of (number, source) for each pll. Allows
to overwrite clock source of pll A (number=0) or B (number=1).
==Child nodes==
Each of the clock outputs can be overwritten individually by
using a child node to the I2C device node. If a child node for a clock
output is not set, the eeprom configuration is not overwritten.
Required child node properties:
- reg: number of clock output.
Optional child node properties:
- silabs,clock-source: source clock of the output divider stage N, shall be
0 = multisynth N
1 = multisynth 0 for output clocks 0-3, else multisynth4
2 = xtal
3 = clkin (si5351c only)
- silabs,drive-strength: output drive strength in mA, shall be one of {2,4,6,8}.
- silabs,multisynth-source: source pll A(0) or B(1) of corresponding multisynth
divider.
- silabs,pll-master: boolean, multisynth can change pll frequency.
==Example==
/* 25MHz reference crystal */
ref25: ref25M {
compatible = "fixed-clock";
#clock-cells = <0>;
clock-frequency = <25000000>;
};
i2c-master-node {
/* Si5351a msop10 i2c clock generator */
si5351a: clock-generator@60 {
compatible = "silabs,si5351a-msop";
reg = <0x60>;
#address-cells = <1>;
#size-cells = <0>;
#clock-cells = <1>;
/* connect xtal input to 25MHz reference */
clocks = <&ref25>;
/* connect xtal input as source of pll0 and pll1 */
silabs,pll-source = <0 0>, <1 0>;
/*
* overwrite clkout0 configuration with:
* - 8mA output drive strength
* - pll0 as clock source of multisynth0
* - multisynth0 as clock source of output divider
* - multisynth0 can change pll0
* - set initial clock frequency of 74.25MHz
*/
clkout0 {
reg = <0>;
silabs,drive-strength = <8>;
silabs,multisynth-source = <0>;
silabs,clock-source = <0>;
silabs,pll-master;
clock-frequency = <74250000>;
};
/*
* overwrite clkout1 configuration with:
* - 4mA output drive strength
* - pll1 as clock source of multisynth1
* - multisynth1 as clock source of output divider
* - multisynth1 can change pll1
*/
clkout1 {
reg = <1>;
silabs,drive-strength = <4>;
silabs,multisynth-source = <1>;
silabs,clock-source = <0>;
pll-master;
};
/*
* overwrite clkout2 configuration with:
* - xtal as clock source of output divider
*/
clkout2 {
reg = <2>;
silabs,clock-source = <2>;
};
};
};

151
Documentation/devicetree/bindings/clock/sunxi.txt Normal file
View File

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

65
Documentation/devicetree/bindings/cpufreq/arm_big_little_dt.txt Normal file
View File

@ -0,0 +1,65 @@
Generic ARM big LITTLE cpufreq driver's DT glue
-----------------------------------------------
This is DT specific glue layer for generic cpufreq driver for big LITTLE
systems.
Both required and optional properties listed below must be defined
under node /cpus/cpu@x. Where x is the first cpu inside a cluster.
FIXME: Cpus should boot in the order specified in DT and all cpus for a cluster
must be present contiguously. Generic DT driver will check only node 'x' for
cpu:x.
Required properties:
- operating-points: Refer to Documentation/devicetree/bindings/power/opp.txt
for details
Optional properties:
- clock-latency: Specify the possible maximum transition latency for clock,
in unit of nanoseconds.
Examples:
cpus {
#address-cells = <1>;
#size-cells = <0>;
cpu@0 {
compatible = "arm,cortex-a15";
reg = <0>;
next-level-cache = <&L2>;
operating-points = <
/* kHz uV */
792000 1100000
396000 950000
198000 850000
>;
clock-latency = <61036>; /* two CLK32 periods */
};
cpu@1 {
compatible = "arm,cortex-a15";
reg = <1>;
next-level-cache = <&L2>;
};
cpu@100 {
compatible = "arm,cortex-a7";
reg = <100>;
next-level-cache = <&L2>;
operating-points = <
/* kHz uV */
792000 950000
396000 750000
198000 450000
>;
clock-latency = <61036>; /* two CLK32 periods */
};
cpu@101 {
compatible = "arm,cortex-a7";
reg = <101>;
next-level-cache = <&L2>;
};
};

2
Documentation/devicetree/bindings/cpufreq/cpufreq-cpu0.txt
View File

@ -32,7 +32,7 @@ cpus {
396000 950000
198000 850000
>;
transition-latency = <61036>; /* two CLK32 periods */
clock-latency = <61036>; /* two CLK32 periods */
};
cpu@1 {

28
Documentation/devicetree/bindings/cpufreq/cpufreq-exynos5440.txt Normal file
View File

@ -0,0 +1,28 @@
Exynos5440 cpufreq driver
-------------------
Exynos5440 SoC cpufreq driver for CPU frequency scaling.
Required properties:
- interrupts: Interrupt to know the completion of cpu frequency change.
- operating-points: Table of frequencies and voltage CPU could be transitioned into,
in the decreasing order. Frequency should be in KHz units and voltage
should be in microvolts.
Optional properties:
- clock-latency: Clock monitor latency in microsecond.
All the required listed above must be defined under node cpufreq.
Example:
--------
cpufreq@160000 {
compatible = "samsung,exynos5440-cpufreq";
reg = <0x160000 0x1000>;
interrupts = <0 57 0>;
operating-points = <
1000000 975000
800000 925000>;
clock-latency = <100000>;
};

15
Documentation/devicetree/bindings/crypto/fsl-imx-sahara.txt Normal file
View File

@ -0,0 +1,15 @@
Freescale SAHARA Cryptographic Accelerator included in some i.MX chips.
Currently only i.MX27 is supported.
Required properties:
- compatible : Should be "fsl,<soc>-sahara"
- reg : Should contain SAHARA registers location and length
- interrupts : Should contain SAHARA interrupt number
Example:
sah@10025000 {
compatible = "fsl,imx27-sahara";
reg = < 0x10025000 0x800>;
interrupts = <75>;
};

22
Documentation/devicetree/bindings/drm/exynos/g2d.txt
View File

@ -1,22 +0,0 @@
Samsung 2D Graphic Accelerator using DRM frame work
Samsung FIMG2D is a graphics 2D accelerator which supports Bit Block Transfer.
We set the drawing-context registers for configuring rendering parameters and
then start rendering.
This driver is for SOCs which contain G2D IPs with version 4.1.
Required properties:
-compatible:
should be "samsung,exynos-g2d-41".
-reg:
physical base address of the controller and length
of memory mapped region.
-interrupts:
interrupt combiner values.
Example:
g2d {
compatible = "samsung,exynos-g2d-41";
reg = <0x10850000 0x1000>;
interrupts = <0 91 0>;
};

24
Documentation/devicetree/bindings/gpio/gpio-vt8500.txt
View File

@ -1,24 +0,0 @@
VIA/Wondermedia VT8500 GPIO Controller
-----------------------------------------------------
Required properties:
- compatible : "via,vt8500-gpio", "wm,wm8505-gpio"
or "wm,wm8650-gpio" depending on your SoC
- reg : Should contain 1 register range (address and length)
- #gpio-cells : should be <3>.
1) bank
2) pin number
3) flags - should be 0
Example:
gpio: gpio-controller@d8110000 {
compatible = "via,vt8500-gpio";
gpio-controller;
reg = <0xd8110000 0x10000>;
#gpio-cells = <3>;
};
vibrate {
gpios = <&gpio 0 1 0>; /* Bank 0, Pin 1, No flags */
};

6
Documentation/devicetree/bindings/gpio/gpio.txt
View File

@ -98,7 +98,7 @@ announce the pinrange to the pin ctrl subsystem. For example,
compatible = "fsl,qe-pario-bank-e", "fsl,qe-pario-bank";
reg = <0x1460 0x18>;
gpio-controller;
gpio-ranges = <&pinctrl1 20 10>, <&pinctrl2 50 20>;
gpio-ranges = <&pinctrl1 0 20 10>, <&pinctrl2 10 50 20>;
}
@ -107,8 +107,8 @@ where,
Next values specify the base pin and number of pins for the range
handled by 'qe_pio_e' gpio. In the given example from base pin 20 to
pin 29 under pinctrl1 and pin 50 to pin 69 under pinctrl2 is handled
by this gpio controller.
pin 29 under pinctrl1 with gpio offset 0 and pin 50 to pin 69 under
pinctrl2 with gpio offset 10 is handled by this gpio controller.
The pinctrl node must have "#gpio-range-cells" property to show number of
arguments to pass with phandle from gpio controllers node.

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

@ -1,7 +1,10 @@
* Marvell PXA GPIO controller
Required properties:
- compatible : Should be "mrvl,pxa-gpio" or "mrvl,mmp-gpio"
- compatible : Should be "intel,pxa25x-gpio", "intel,pxa26x-gpio",
"intel,pxa27x-gpio", "intel,pxa3xx-gpio",
"marvell,pxa93x-gpio", "marvell,mmp-gpio" or
"marvell,mmp2-gpio".
- reg : Address and length of the register set for the device
- interrupts : Should be the port interrupt shared by all gpio pins.
There're three gpio interrupts in arch-pxa, and they're gpio0,
@ -18,7 +21,7 @@ Required properties:
Example:
gpio: gpio@d4019000 {
compatible = "mrvl,mmp-gpio";
compatible = "marvell,mmp-gpio";
reg = <0xd4019000 0x1000>;
interrupts = <49>;
interrupt-name = "gpio_mux";

29
Documentation/devicetree/bindings/hwmon/ntc_thermistor.txt Normal file
View File

@ -0,0 +1,29 @@
NTC Thermistor hwmon sensors
-------------------------------
Requires node properties:
- "compatible" value : one of
"ntc,ncp15wb473"
"ntc,ncp18wb473"
"ntc,ncp21wb473"
"ntc,ncp03wb473"
"ntc,ncp15wl333"
- "pullup-uv" Pull up voltage in micro volts
- "pullup-ohm" Pull up resistor value in ohms
- "pulldown-ohm" Pull down resistor value in ohms
- "connected-positive" Always ON, If not specified.
Status change is possible.
- "io-channels" Channel node of ADC to be used for
conversion.
Read more about iio bindings at
Documentation/devicetree/bindings/iio/iio-bindings.txt
Example:
ncp15wb473@0 {
compatible = "ntc,ncp15wb473";
pullup-uv = <1800000>;
pullup-ohm = <47000>;
pulldown-ohm = <0>;
io-channels = <&adc 3>;
};

18
Documentation/devicetree/bindings/hwrng/timeriomem_rng.txt Normal file
View File

@ -0,0 +1,18 @@
HWRNG support for the timeriomem_rng driver
Required properties:
- compatible : "timeriomem_rng"
- reg : base address to sample from
- period : wait time in microseconds to use between samples
N.B. currently 'reg' must be four bytes wide and aligned
Example:
hwrng@44 {
#address-cells = <1>;
#size-cells = <1>;
compatible = "timeriomem_rng";
reg = <0x44 0x04>;
period = <1000000>;
};

80
Documentation/devicetree/bindings/i2c/i2c-arb-gpio-challenge.txt Normal file
View File

@ -0,0 +1,80 @@
GPIO-based I2C Arbitration Using a Challenge & Response Mechanism
=================================================================
This uses GPIO lines and a challenge & response mechanism to arbitrate who is
the master of an I2C bus in a multimaster situation.
In many cases using GPIOs to arbitrate is not needed and a design can use
the standard I2C multi-master rules. Using GPIOs is generally useful in
the case where there is a device on the bus that has errata and/or bugs
that makes standard multimaster mode not feasible.
Algorithm:
All masters on the bus have a 'bus claim' line which is an output that the
others can see. These are all active low with pull-ups enabled. We'll
describe these lines as:
- OUR_CLAIM: output from us signaling to other hosts that we want the bus
- THEIR_CLAIMS: output from others signaling that they want the bus
The basic algorithm is to assert your line when you want the bus, then make
sure that the other side doesn't want it also. A detailed explanation is best
done with an example.
Let's say we want to claim the bus. We:
1. Assert OUR_CLAIM.
2. Waits a little bit for the other sides to notice (slew time, say 10
microseconds).
3. Check THEIR_CLAIMS. If none are asserted then the we have the bus and we are
done.
4. Otherwise, wait for a few milliseconds and see if THEIR_CLAIMS are released.
5. If not, back off, release the claim and wait for a few more milliseconds.
6. Go back to 1 (until retry time has expired).
Required properties:
- compatible: i2c-arb-gpio-challenge
- our-claim-gpio: The GPIO that we use to claim the bus.
- their-claim-gpios: The GPIOs that the other sides use to claim the bus.
Note that some implementations may only support a single other master.
- Standard I2C mux properties. See mux.txt in this directory.
- Single I2C child bus node at reg 0. See mux.txt in this directory.
Optional properties:
- slew-delay-us: microseconds to wait for a GPIO to go high. Default is 10 us.
- wait-retry-us: we'll attempt another claim after this many microseconds.
Default is 3000 us.
- wait-free-us: we'll give up after this many microseconds. Default is 50000 us.
Example:
i2c@12CA0000 {
compatible = "acme,some-i2c-device";
#address-cells = <1>;
#size-cells = <0>;
};
i2c-arbitrator {
compatible = "i2c-arb-gpio-challenge";
#address-cells = <1>;
#size-cells = <0>;
i2c-parent = <&{/i2c@12CA0000}>;
our-claim-gpio = <&gpf0 3 1>;
their-claim-gpios = <&gpe0 4 1>;
slew-delay-us = <10>;
wait-retry-us = <3000>;
wait-free-us = <50000>;
i2c@0 {
reg = <0>;
#address-cells = <1>;
#size-cells = <0>;
i2c@52 {
// Normal I2C device
};
};
};

2
Documentation/devicetree/bindings/i2c/i2c-s3c2410.txt
View File

@ -26,7 +26,7 @@ Required for all cases except "samsung,s3c2440-hdmiphy-i2c":
- pinctrl-names: Should contain only one value - "default".
Optional properties:
- samsung,i2c-slave-addr: Slave address in multi-master enviroment. If not
- samsung,i2c-slave-addr: Slave address in multi-master environment. If not
specified, default value is 0.
- samsung,i2c-max-bus-freq: Desired frequency in Hz of the bus. If not
specified, the default value in Hz is 100000.

2
Documentation/devicetree/bindings/i2c/trivial-devices.txt
View File

@ -35,6 +35,8 @@ fsl,mc13892 MC13892: Power Management Integrated Circuit (PMIC) for i.MX35/51
fsl,mma8450 MMA8450Q: Xtrinsic Low-power, 3-axis Xtrinsic Accelerometer
fsl,mpr121 MPR121: Proximity Capacitive Touch Sensor Controller
fsl,sgtl5000 SGTL5000: Ultra Low-Power Audio Codec
infineon,slb9635tt Infineon SLB9635 (Soft-) I2C TPM (old protocol, max 100khz)
infineon,slb9645tt Infineon SLB9645 I2C TPM (new protocol, max 400khz)
maxim,ds1050 5 Bit Programmable, Pulse-Width Modulator
maxim,max1237 Low-Power, 4-/12-Channel, 2-Wire Serial, 12-Bit ADCs
maxim,max6625 9-Bit/12-Bit Temperature Sensors with I²C-Compatible Serial Interface

97
Documentation/devicetree/bindings/iio/iio-bindings.txt Normal file
View File

@ -0,0 +1,97 @@
This binding is derived from clock bindings, and based on suggestions
from Lars-Peter Clausen [1].
Sources of IIO channels can be represented by any node in the device
tree. Those nodes are designated as IIO providers. IIO consumer
nodes use a phandle and IIO specifier pair to connect IIO provider
outputs to IIO inputs. Similar to the gpio specifiers, an IIO
specifier is an array of one or more cells identifying the IIO
output on a device. The length of an IIO specifier is defined by the
value of a #io-channel-cells property in the IIO provider node.
[1] http://marc.info/?l=linux-iio&m=135902119507483&w=2
==IIO providers==
Required properties:
#io-channel-cells: Number of cells in an IIO specifier; Typically 0 for nodes
with a single IIO output and 1 for nodes with multiple
IIO outputs.
Example for a simple configuration with no trigger:
adc: voltage-sensor@35 {
compatible = "maxim,max1139";
reg = <0x35>;
#io-channel-cells = <1>;
};
Example for a configuration with trigger:
adc@35 {
compatible = "some-vendor,some-adc";
reg = <0x35>;
adc1: iio-device@0 {
#io-channel-cells = <1>;
/* other properties */
};
adc2: iio-device@1 {
#io-channel-cells = <1>;
/* other properties */
};
};
==IIO consumers==
Required properties:
io-channels: List of phandle and IIO specifier pairs, one pair
for each IIO input to the device. Note: if the
IIO provider specifies '0' for #io-channel-cells,
then only the phandle portion of the pair will appear.
Optional properties:
io-channel-names:
List of IIO input name strings sorted in the same
order as the io-channels property. Consumers drivers
will use io-channel-names to match IIO input names
with IIO specifiers.
io-channel-ranges:
Empty property indicating that child nodes can inherit named
IIO channels from this node. Useful for bus nodes to provide
and IIO channel to their children.
For example:
device {
io-channels = <&adc 1>, <&ref 0>;
io-channel-names = "vcc", "vdd";
};
This represents a device with two IIO inputs, named "vcc" and "vdd".
The vcc channel is connected to output 1 of the &adc device, and the
vdd channel is connected to output 0 of the &ref device.
==Example==
adc: max1139@35 {
compatible = "maxim,max1139";
reg = <0x35>;
#io-channel-cells = <1>;
};
...
iio_hwmon {
compatible = "iio-hwmon";
io-channels = <&adc 0>, <&adc 1>, <&adc 2>,
<&adc 3>, <&adc 4>, <&adc 5>,
<&adc 6>, <&adc 7>, <&adc 8>,
<&adc 9>;
};
some_consumer {
compatible = "some-consumer";
io-channels = <&adc 10>, <&adc 11>;
io-channel-names = "adc1", "adc2";
};

16
Documentation/devicetree/bindings/input/ps2keyb-mouse-apbps2.txt Normal file
View File

@ -0,0 +1,16 @@
Aeroflex Gaisler APBPS2 PS/2 Core, supporting Keyboard or Mouse.
The APBPS2 PS/2 core is available in the GRLIB VHDL IP core library.
Note: In the ordinary environment for the APBPS2 core, a LEON SPARC system,
these properties are built from information in the AMBA plug&play and from
bootloader settings.
Required properties:
- name : Should be "GAISLER_APBPS2" or "01_060"
- reg : Address and length of the register set for the device
- interrupts : Interrupt numbers for this device
For further information look in the documentation for the GLIB IP core library:
http://www.gaisler.com/products/grlib/grip.pdf

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

@ -0,0 +1,30 @@
* AUO in-cell touchscreen controller using Pixcir sensors
Required properties:
- compatible: must be "auo,auo_pixcir_ts"
- reg: I2C address of the chip
- interrupts: interrupt to which the chip is connected
- gpios: gpios the chip is connected to
first one is the interrupt gpio and second one the reset gpio
- x-size: horizontal resolution of touchscreen
- y-size: vertical resolution of touchscreen
Example:
i2c@00000000 {
/* ... */
auo_pixcir_ts@5c {
compatible = "auo,auo_pixcir_ts";
reg = <0x5c>;
interrupts = <2 0>;
gpios = <&gpf 2 0 2>, /* INT */
<&gpf 5 1 0>; /* RST */
x-size = <800>;
y-size = <600>;
};
/* ... */
};

24
Documentation/devicetree/bindings/input/touchscreen/sitronix-st1232.txt Normal file
View File

@ -0,0 +1,24 @@
* Sitronix st1232 touchscreen controller
Required properties:
- compatible: must be "sitronix,st1232"
- reg: I2C address of the chip
- interrupts: interrupt to which the chip is connected
Optional properties:
- gpios: a phandle to the reset GPIO
Example:
i2c@00000000 {
/* ... */
touchscreen@55 {
compatible = "sitronix,st1232";
reg = <0x55>;
interrupts = <2 0>;
gpios = <&gpio1 166 0>;
};
/* ... */
};

4
Documentation/devicetree/bindings/interrupt-controller/allwinner,sunxi-ic.txt → Documentation/devicetree/bindings/interrupt-controller/allwinner,sun4i-ic.txt
View File

@ -2,7 +2,7 @@ Allwinner Sunxi Interrupt Controller
Required properties:
- compatible : should be "allwinner,sunxi-ic"
- compatible : should be "allwinner,sun4i-ic"
- reg : Specifies base physical address and size of the registers.
- interrupt-controller : Identifies the node as an interrupt controller
- #interrupt-cells : Specifies the number of cells needed to encode an
@ -97,7 +97,7 @@ The interrupt sources are as follows:
Example:
intc: interrupt-controller {
compatible = "allwinner,sunxi-ic";
compatible = "allwinner,sun4i-ic";
reg = <0x01c20400 0x400>;
interrupt-controller;
#interrupt-cells = <2>;

53
Documentation/devicetree/bindings/interrupt-controller/samsung,s3c24xx-irq.txt Normal file
View File

@ -0,0 +1,53 @@
Samsung S3C24XX Interrupt Controllers
The S3C24XX SoCs contain a custom set of interrupt controllers providing a
varying number of interrupt sources. The set consists of a main- and sub-
controller and on newer SoCs even a second main controller.
Required properties:
- compatible: Compatible property value should be "samsung,s3c2410-irq"
for machines before s3c2416 and "samsung,s3c2416-irq" for s3c2416 and later.
- reg: Physical base address of the controller and length of memory mapped
region.
- interrupt-controller : Identifies the node as an interrupt controller
- #interrupt-cells : Specifies the number of cells needed to encode an
interrupt source. The value shall be 4 and interrupt descriptor shall
have the following format:
<ctrl_num parent_irq ctrl_irq type>
ctrl_num contains the controller to use:
- 0 ... main controller
- 1 ... sub controller
- 2 ... second main controller on s3c2416 and s3c2450
parent_irq contains the parent bit in the main controller and will be
ignored in main controllers
ctrl_irq contains the interrupt bit of the controller
type contains the trigger type to use
Example:
interrupt-controller@4a000000 {
compatible = "samsung,s3c2410-irq";
reg = <0x4a000000 0x100>;
interrupt-controller;
#interrupt-cells=<4>;
};
[...]
serial@50000000 {
compatible = "samsung,s3c2410-uart";
reg = <0x50000000 0x4000>;
interrupt-parent = <&subintc>;
interrupts = <1 28 0 4>, <1 28 1 4>;
};
rtc@57000000 {
compatible = "samsung,s3c2410-rtc";
reg = <0x57000000 0x100>;
interrupt-parent = <&intc>;
interrupts = <0 30 0 3>, <0 8 0 3>;
};

2
Documentation/devicetree/bindings/leds/tca6507.txt
View File

@ -1,4 +1,4 @@
LEDs conected to tca6507
LEDs connected to tca6507
Required properties:
- compatible : should be : "ti,tca6507".

3
Documentation/devicetree/bindings/marvell.txt
View File

@ -115,6 +115,9 @@ prefixed with the string "marvell,", for Marvell Technology Group Ltd.
- compatible : "marvell,mv64360-eth-block"
- reg : Offset and length of the register set for this block
Optional properties:
- clocks : Phandle to the clock control device and gate bit
Example Discovery Ethernet block node:
ethernet-block@2000 {
#address-cells = <1>;

30
Documentation/devicetree/bindings/media/coda.txt Normal file
View File

@ -0,0 +1,30 @@
Chips&Media Coda multi-standard codec IP
========================================
Coda codec IPs are present in i.MX SoCs in various versions,
called VPU (Video Processing Unit).
Required properties:
- compatible : should be "fsl,<chip>-src" for i.MX SoCs:
(a) "fsl,imx27-vpu" for CodaDx6 present in i.MX27
(b) "fsl,imx53-vpu" for CODA7541 present in i.MX53
(c) "fsl,imx6q-vpu" for CODA960 present in i.MX6q
- reg: should be register base and length as documented in the
SoC reference manual
- interrupts : Should contain the VPU interrupt. For CODA960,
a second interrupt is needed for the MJPEG unit.
- clocks : Should contain the ahb and per clocks, in the order
determined by the clock-names property.
- clock-names : Should be "ahb", "per"
- iram : phandle pointing to the SRAM device node
Example:
vpu: vpu@63ff4000 {
compatible = "fsl,imx53-vpu";
reg = <0x63ff4000 0x1000>;
interrupts = <9>;
clocks = <&clks 63>, <&clks 63>;
clock-names = "ahb", "per";
iram = <&ocram>;
};

14
Documentation/devicetree/bindings/media/exynos-fimc-lite.txt Normal file
View File

@ -0,0 +1,14 @@
Exynos4x12/Exynos5 SoC series camera host interface (FIMC-LITE)
Required properties:
- compatible : should be "samsung,exynos4212-fimc" for Exynos4212 and
Exynos4412 SoCs;
- reg : physical base address and size of the device memory mapped
registers;
- interrupts : should contain FIMC-LITE interrupt;
- clocks : FIMC LITE gate clock should be specified in this property.
- clock-names : should contain "flite" entry.
Each FIMC device should have an alias in the aliases node, in the form of
fimc-lite<n>, where <n> is an integer specifying the IP block instance.

49
Documentation/devicetree/bindings/media/exynos4-fimc-is.txt Normal file
View File

@ -0,0 +1,49 @@
Exynos4x12 SoC series Imaging Subsystem (FIMC-IS)
The FIMC-IS is a subsystem for processing image signal from an image sensor.
The Exynos4x12 SoC series FIMC-IS V1.5 comprises of a dedicated ARM Cortex-A5
processor, ISP, DRC and FD IP blocks and peripheral devices such as UART, I2C
and SPI bus controllers, PWM and ADC.
fimc-is node
------------
Required properties:
- compatible : should be "samsung,exynos4212-fimc-is" for Exynos4212 and
Exynos4412 SoCs;
- reg : physical base address and length of the registers set;
- interrupts : must contain two FIMC-IS interrupts, in order: ISP0, ISP1;
- clocks : list of clock specifiers, corresponding to entries in
clock-names property;
- clock-names : must contain "ppmuispx", "ppmuispx", "lite0", "lite1"
"mpll", "sysreg", "isp", "drc", "fd", "mcuisp", "uart",
"ispdiv0", "ispdiv1", "mcuispdiv0", "mcuispdiv1", "aclk200",
"div_aclk200", "aclk400mcuisp", "div_aclk400mcuisp" entries,
matching entries in the clocks property.
pmu subnode
-----------
Required properties:
- reg : must contain PMU physical base address and size of the register set.
The following are the FIMC-IS peripheral device nodes and can be specified
either standalone or as the fimc-is node child nodes.
i2c-isp (ISP I2C bus controller) nodes
------------------------------------------
Required properties:
- compatible : should be "samsung,exynos4212-i2c-isp" for Exynos4212 and
Exynos4412 SoCs;
- reg : physical base address and length of the registers set;
- clocks : must contain gate clock specifier for this controller;
- clock-names : must contain "i2c_isp" entry.
For the above nodes it is required to specify a pinctrl state named "default",
according to the pinctrl bindings defined in ../pinctrl/pinctrl-bindings.txt.
Device tree nodes of the image sensors' controlled directly by the FIMC-IS
firmware must be child nodes of their corresponding ISP I2C bus controller node.
The data link of these image sensors must be specified using the common video
interfaces bindings, defined in video-interfaces.txt.

21
Documentation/devicetree/bindings/media/s5p-mfc.txt
View File

@ -21,3 +21,24 @@ Required properties:
- samsung,mfc-l : Base address of the second memory bank used by MFC
for DMA contiguous memory allocation and its size.
Optional properties:
- samsung,power-domain : power-domain property defined with a phandle
to respective power domain.
Example:
SoC specific DT entry:
mfc: codec@13400000 {
compatible = "samsung,mfc-v5";
reg = <0x13400000 0x10000>;
interrupts = <0 94 0>;
samsung,power-domain = <&pd_mfc>;
};
Board specific DT entry:
codec@13400000 {
samsung,mfc-r = <0x43000000 0x800000>;
samsung,mfc-l = <0x51000000 0x800000>;
};

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