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

Merge tag 'topic/i915-hda-componentized-2015-01-12' into drm-intel-next-queued

Browse Source 
Conflicts:
	drivers/gpu/drm/i915/intel_runtime_pm.c

Separate branch so that Takashi can also pull just this refactoring
into sound-next.

Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
This commit is contained in:
Daniel Vetter
2015-01-12 23:07:46 +01:00
parent 7226572d8e fcf3aac5fc
commit 0a87a2db48
10043 changed files with 412931 additions and 312093 deletions
Download Patch File Download Diff File Expand all files Collapse all files

3
.gitignore vendored
View File

@@ -96,3 +96,6 @@ x509.genkey
# Kconfig presets
all.config
# Kdevelop4
*.kdev4

5
.mailmap
View File

@@ -17,7 +17,7 @@ Aleksey Gorelov <aleksey_gorelov@phoenix.com>
Al Viro <viro@ftp.linux.org.uk>
Al Viro <viro@zenIV.linux.org.uk>
Andreas Herrmann <aherrman@de.ibm.com>
Andrew Morton <akpm@osdl.org>
Andrew Morton <akpm@linux-foundation.org>
Andrew Vasquez <andrew.vasquez@qlogic.com>
Andy Adamson <andros@citi.umich.edu>
Archit Taneja <archit@ti.com>
@@ -51,6 +51,7 @@ Greg Kroah-Hartman <gregkh@suse.de>
Greg Kroah-Hartman <greg@kroah.com>
Henk Vergonet <Henk.Vergonet@gmail.com>
Henrik Kretzschmar <henne@nachtwindheim.de>
Henrik Rydberg <rydberg@bitmath.org>
Herbert Xu <herbert@gondor.apana.org.au>
Jacob Shin <Jacob.Shin@amd.com>
James Bottomley <jejb@mulgrave.(none)>
@@ -102,6 +103,8 @@ Rudolf Marek <R.Marek@sh.cvut.cz>
Rui Saraiva <rmps@joel.ist.utl.pt>
Sachin P Sant <ssant@in.ibm.com>
Sam Ravnborg <sam@mars.ravnborg.org>
Santosh Shilimkar <ssantosh@kernel.org>
Santosh Shilimkar <santosh.shilimkar@oracle.org>
Sascha Hauer <s.hauer@pengutronix.de>
S.Çağlar Onur <caglar@pardus.org.tr>
Shiraz Hashim <shiraz.linux.kernel@gmail.com> <shiraz.hashim@st.com>

6
CREDITS
View File

@@ -1734,14 +1734,14 @@ S: Chapel Hill, North Carolina 27514-4818
S: USA
N: Dave Jones
E: davej@redhat.com
E: davej@codemonkey.org.uk
W: http://www.codemonkey.org.uk
D: Assorted VIA x86 support.
D: 2.5 AGPGART overhaul.
D: CPUFREQ maintenance.
D: Fedora kernel maintenance.
D: Fedora kernel maintenance (2003-2014).
D: 'Trinity' and similar fuzz testing work.
D: Misc/Other.
S: 314 Littleton Rd, Westford, MA 01886, USA
N: Martin Josfsson
E: gandalf@wlug.westbo.se

14
Documentation/ABI/stable/sysfs-bus-usb
View File

@@ -32,10 +32,9 @@ Date: January 2008
KernelVersion: 2.6.25
Contact: Sarah Sharp <sarah.a.sharp@intel.com>
Description:
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.
If CONFIG_PM 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.
Users:
PowerTOP <powertop@lists.01.org>
https://01.org/powertop/
@@ -45,10 +44,9 @@ Date: January 2008
KernelVersion: 2.6.25
Contact: Sarah Sharp <sarah.a.sharp@intel.com>
Description:
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.
If CONFIG_PM 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.
Tools can use this file and the connected_duration file to
compute the percentage of time that a device has been active.

93
Documentation/ABI/stable/sysfs-class-udc Normal file
View File

@@ -0,0 +1,93 @@
What: /sys/class/udc/<udc>/a_alt_hnp_support
Date: June 2011
KernelVersion: 3.1
Contact: Felipe Balbi <balbi@kernel.org>
Description:
Indicates if an OTG A-Host supports HNP at an alternate port.
Users:
What: /sys/class/udc/<udc>/a_hnp_support
Date: June 2011
KernelVersion: 3.1
Contact: Felipe Balbi <balbi@kernel.org>
Description:
Indicates if an OTG A-Host supports HNP at this port.
Users:
What: /sys/class/udc/<udc>/b_hnp_enable
Date: June 2011
KernelVersion: 3.1
Contact: Felipe Balbi <balbi@kernel.org>
Description:
Indicates if an OTG A-Host enabled HNP support.
Users:
What: /sys/class/udc/<udc>/current_speed
Date: June 2011
KernelVersion: 3.1
Contact: Felipe Balbi <balbi@kernel.org>
Description:
Indicates the current negotiated speed at this port.
Users:
What: /sys/class/udc/<udc>/is_a_peripheral
Date: June 2011
KernelVersion: 3.1
Contact: Felipe Balbi <balbi@kernel.org>
Description:
Indicates that this port is the default Host on an OTG session
but HNP was used to switch roles.
Users:
What: /sys/class/udc/<udc>/is_otg
Date: June 2011
KernelVersion: 3.1
Contact: Felipe Balbi <balbi@kernel.org>
Description:
Indicates that this port support OTG.
Users:
What: /sys/class/udc/<udc>/maximum_speed
Date: June 2011
KernelVersion: 3.1
Contact: Felipe Balbi <balbi@kernel.org>
Description:
Indicates the maximum USB speed supported by this port.
Users:
What: /sys/class/udc/<udc>/maximum_speed
Date: June 2011
KernelVersion: 3.1
Contact: Felipe Balbi <balbi@kernel.org>
Description:
Indicates the maximum USB speed supported by this port.
Users:
What: /sys/class/udc/<udc>/soft_connect
Date: June 2011
KernelVersion: 3.1
Contact: Felipe Balbi <balbi@kernel.org>
Description:
Allows users to disconnect data pullup resistors thus causing a
logical disconnection from the USB Host.
Users:
What: /sys/class/udc/<udc>/srp
Date: June 2011
KernelVersion: 3.1
Contact: Felipe Balbi <balbi@kernel.org>
Description:
Allows users to manually start Session Request Protocol.
Users:
What: /sys/class/udc/<udc>/state
Date: June 2011
KernelVersion: 3.1
Contact: Felipe Balbi <balbi@kernel.org>
Description:
Indicates current state of the USB Device Controller. Valid
states are: 'not-attached', 'attached', 'powered',
'reconnecting', 'unauthenticated', 'default', 'addressed',
'configured', and 'suspended'; however not all USB Device
Controllers support reporting all states.
Users:

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

@@ -55,12 +55,12 @@ Description: Interface for making ib_srp connect to a new target.
only safe with partial memory descriptor list support enabled
(allow_ext_sg=1).
* comp_vector, a number in the range 0..n-1 specifying the
MSI-X completion vector. Some HCA's allocate multiple (n)
MSI-X vectors per HCA port. If the IRQ affinity masks of
these interrupts have been configured such that each MSI-X
interrupt is handled by a different CPU then the comp_vector
parameter can be used to spread the SRP completion workload
over multiple CPU's.
MSI-X completion vector of the first RDMA channel. Some
HCA's allocate multiple (n) MSI-X vectors per HCA port. If
the IRQ affinity masks of these interrupts have been
configured such that each MSI-X interrupt is handled by a
different CPU then the comp_vector parameter can be used to
spread the SRP completion workload over multiple CPU's.
* tl_retry_count, a number in the range 2..7 specifying the
IB RC retry count.
* queue_size, the maximum number of commands that the
@@ -88,6 +88,13 @@ Description: Whether ib_srp is allowed to include a partial memory
descriptor list in an SRP_CMD when communicating with an SRP
target.
What: /sys/class/scsi_host/host<n>/ch_count
Date: April 1, 2015
KernelVersion: 3.19
Contact: linux-rdma@vger.kernel.org
Description: Number of RDMA channels used for communication with the SRP
target.
What: /sys/class/scsi_host/host<n>/cmd_sg_entries
Date: May 19, 2011
KernelVersion: 2.6.39
@@ -95,6 +102,12 @@ Contact: linux-rdma@vger.kernel.org
Description: Maximum number of data buffer descriptors that may be sent to
the target in a single SRP_CMD request.
What: /sys/class/scsi_host/host<n>/comp_vector
Date: September 2, 2013
KernelVersion: 3.11
Contact: linux-rdma@vger.kernel.org
Description: Completion vector used for the first RDMA channel.
What: /sys/class/scsi_host/host<n>/dgid
Date: June 17, 2006
KernelVersion: 2.6.17

11
Documentation/ABI/testing/configfs-usb-gadget-hid Normal file
View File

@@ -0,0 +1,11 @@
What: /config/usb-gadget/gadget/functions/hid.name
Date: Nov 2014
KernelVersion: 3.19
Description:
The attributes:
protocol - HID protocol to use
report_desc - blob corresponding to HID report descriptors
except the data passed through /dev/hidg<N>
report_length - HID report length
subclass - HID device subclass to use

12
Documentation/ABI/testing/configfs-usb-gadget-midi Normal file
View File

@@ -0,0 +1,12 @@
What: /config/usb-gadget/gadget/functions/midi.name
Date: Nov 2014
KernelVersion: 3.19
Description:
The attributes:
index - index value for the USB MIDI adapter
id - ID string for the USB MIDI adapter
buflen - MIDI buffer length
qlen - USB read request queue length
in_ports - number of MIDI input ports
out_ports - number of MIDI output ports

24
Documentation/ABI/testing/sysfs-bus-coresight-devices-etb10 Normal file
View File

@@ -0,0 +1,24 @@
What: /sys/bus/coresight/devices/<memory_map>.etb/enable_sink
Date: November 2014
KernelVersion: 3.19
Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
Description: (RW) Add/remove a sink from a trace path. There can be multiple
source for a single sink.
ex: echo 1 > /sys/bus/coresight/devices/20010000.etb/enable_sink
What: /sys/bus/coresight/devices/<memory_map>.etb/status
Date: November 2014
KernelVersion: 3.19
Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
Description: (R) List various control and status registers. The specific
layout and content is driver specific.
What: /sys/bus/coresight/devices/<memory_map>.etb/trigger_cntr
Date: November 2014
KernelVersion: 3.19
Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
Description: (RW) Disables write access to the Trace RAM by stopping the
formatter after a defined number of words have been stored
following the trigger event. The number of 32-bit words written
into the Trace RAM following the trigger event is equal to the
value stored in this register+1 (from ARM ETB-TRM).

253
Documentation/ABI/testing/sysfs-bus-coresight-devices-etm3x Normal file
View File

@@ -0,0 +1,253 @@
What: /sys/bus/coresight/devices/<memory_map>.[etm|ptm]/enable_source
Date: November 2014
KernelVersion: 3.19
Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
Description: (RW) Enable/disable tracing on this specific trace entiry.
Enabling a source implies the source has been configured
properly and a sink has been identidifed for it. The path
of coresight components linking the source to the sink is
configured and managed automatically by the coresight framework.
What: /sys/bus/coresight/devices/<memory_map>.[etm|ptm]/status
Date: November 2014
KernelVersion: 3.19
Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
Description: (R) List various control and status registers. The specific
layout and content is driver specific.
What: /sys/bus/coresight/devices/<memory_map>.[etm|ptm]/addr_idx
Date: November 2014
KernelVersion: 3.19
Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
Description: Select which address comparator or pair (of comparators) to
work with.
What: /sys/bus/coresight/devices/<memory_map>.[etm|ptm]/addr_acctype
Date: November 2014
KernelVersion: 3.19
Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
Description: (RW) Used in conjunction with @addr_idx. Specifies
characteristics about the address comparator being configure,
for example the access type, the kind of instruction to trace,
processor contect ID to trigger on, etc. Individual fields in
the access type register may vary on the version of the trace
entity.
What: /sys/bus/coresight/devices/<memory_map>.[etm|ptm]/addr_range
Date: November 2014
KernelVersion: 3.19
Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
Description: (RW) Used in conjunction with @addr_idx. Specifies the range of
addresses to trigger on. Inclusion or exclusion is specificed
in the corresponding access type register.
What: /sys/bus/coresight/devices/<memory_map>.[etm|ptm]/addr_single
Date: November 2014
KernelVersion: 3.19
Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
Description: (RW) Used in conjunction with @addr_idx. Specifies the single
address to trigger on, highly influenced by the configuration
options of the corresponding access type register.
What: /sys/bus/coresight/devices/<memory_map>.[etm|ptm]/addr_start
Date: November 2014
KernelVersion: 3.19
Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
Description: (RW) Used in conjunction with @addr_idx. Specifies the single
address to start tracing on, highly influenced by the
configuration options of the corresponding access type register.
What: /sys/bus/coresight/devices/<memory_map>.[etm|ptm]/addr_stop
Date: November 2014
KernelVersion: 3.19
Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
Description: (RW) Used in conjunction with @addr_idx. Specifies the single
address to stop tracing on, highly influenced by the
configuration options of the corresponding access type register.
What: /sys/bus/coresight/devices/<memory_map>.[etm|ptm]/cntr_idx
Date: November 2014
KernelVersion: 3.19
Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
Description: (RW) Specifies the counter to work on.
What: /sys/bus/coresight/devices/<memory_map>.[etm|ptm]/cntr_event
Date: November 2014
KernelVersion: 3.19
Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
Description: (RW) Used in conjunction with cntr_idx, give access to the
counter event register.
What: /sys/bus/coresight/devices/<memory_map>.[etm|ptm]/cntr_val
Date: November 2014
KernelVersion: 3.19
Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
Description: (RW) Used in conjunction with cntr_idx, give access to the
counter value register.
What: /sys/bus/coresight/devices/<memory_map>.[etm|ptm]/cntr_rld_val
Date: November 2014
KernelVersion: 3.19
Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
Description: (RW) Used in conjunction with cntr_idx, give access to the
counter reload value register.
What: /sys/bus/coresight/devices/<memory_map>.[etm|ptm]/cntr_rld_event
Date: November 2014
KernelVersion: 3.19
Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
Description: (RW) Used in conjunction with cntr_idx, give access to the
counter reload event register.
What: /sys/bus/coresight/devices/<memory_map>.[etm|ptm]/ctxid_idx
Date: November 2014
KernelVersion: 3.19
Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
Description: (RW) Specifies the index of the context ID register to be
selected.
What: /sys/bus/coresight/devices/<memory_map>.[etm|ptm]/ctxid_mask
Date: November 2014
KernelVersion: 3.19
Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
Description: (RW) Mask to apply to all the context ID comparator.
What: /sys/bus/coresight/devices/<memory_map>.[etm|ptm]/ctxid_val
Date: November 2014
KernelVersion: 3.19
Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
Description: (RW) Used with the ctxid_idx, specify with context ID to trigger
on.
What: /sys/bus/coresight/devices/<memory_map>.[etm|ptm]/enable_event
Date: November 2014
KernelVersion: 3.19
Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
Description: (RW) Defines which event triggers a trace.
What: /sys/bus/coresight/devices/<memory_map>.[etm|ptm]/etmsr
Date: November 2014
KernelVersion: 3.19
Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
Description: (RW) Gives access to the ETM status register, which holds
programming information and status on certains events.
What: /sys/bus/coresight/devices/<memory_map>.[etm|ptm]/fifofull_level
Date: November 2014
KernelVersion: 3.19
Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
Description: (RW) Number of byte left in the fifo before considering it full.
Depending on the tracer's version, can also hold threshold for
data suppression.
What: /sys/bus/coresight/devices/<memory_map>.[etm|ptm]/mode
Date: November 2014
KernelVersion: 3.19
Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
Description: (RW) Interface with the driver's 'mode' field, controlling
various aspect of the trace entity such as time stamping,
context ID size and cycle accurate tracing. Driver specific
and bound to change depending on the driver.
What: /sys/bus/coresight/devices/<memory_map>.[etm|ptm]/nr_addr_cmp
Date: November 2014
KernelVersion: 3.19
Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
Description: (R) Provides the number of address comparators pairs accessible
on a trace unit, as specified by bit 3:0 of register ETMCCR.
What: /sys/bus/coresight/devices/<memory_map>.[etm|ptm]/nr_cntr
Date: November 2014
KernelVersion: 3.19
Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
Description: (R) Provides the number of counters accessible on a trace unit,
as specified by bit 15:13 of register ETMCCR.
What: /sys/bus/coresight/devices/<memory_map>.[etm|ptm]/nr_ctxid_cmp
Date: November 2014
KernelVersion: 3.19
Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
Description: (R) Provides the number of context ID comparator available on a
trace unit, as specified by bit 25:24 of register ETMCCR.
What: /sys/bus/coresight/devices/<memory_map>.[etm|ptm]/reset
Date: November 2014
KernelVersion: 3.19
Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
Description: (W) Cancels all configuration on a trace unit and set it back
to its boot configuration.
What: /sys/bus/coresight/devices/<memory_map>.[etm|ptm]/seq_12_event
Date: November 2014
KernelVersion: 3.19
Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
Description: (RW) Defines the event that causes the sequencer to transition
from state 1 to state 2.
What: /sys/bus/coresight/devices/<memory_map>.[etm|ptm]/seq_13_event
Date: November 2014
KernelVersion: 3.19
Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
Description: (RW) Defines the event that causes the sequencer to transition
from state 1 to state 3.
What: /sys/bus/coresight/devices/<memory_map>.[etm|ptm]/seq_21_event
Date: November 2014
KernelVersion: 3.19
Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
Description: (RW) Defines the event that causes the sequencer to transition
from state 2 to state 1.
What: /sys/bus/coresight/devices/<memory_map>.[etm|ptm]/seq_23_event
Date: November 2014
KernelVersion: 3.19
Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
Description: (RW) Defines the event that causes the sequencer to transition
from state 2 to state 3.
What: /sys/bus/coresight/devices/<memory_map>.[etm|ptm]/seq_31_event
Date: November 2014
KernelVersion: 3.19
Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
Description: (RW) Defines the event that causes the sequencer to transition
from state 3 to state 1.
What: /sys/bus/coresight/devices/<memory_map>.[etm|ptm]/seq_32_event
Date: November 2014
KernelVersion: 3.19
Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
Description: (RW) Defines the event that causes the sequencer to transition
from state 3 to state 2.
What: /sys/bus/coresight/devices/<memory_map>.[etm|ptm]/curr_seq_state
Date: November 2014
KernelVersion: 3.19
Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
Description: (R) Holds the current state of the sequencer.
What: /sys/bus/coresight/devices/<memory_map>.[etm|ptm]/sync_freq
Date: November 2014
KernelVersion: 3.19
Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
Description: (RW) Holds the trace synchronization frequency value - must be
programmed with the various implementation behavior in mind.
What: /sys/bus/coresight/devices/<memory_map>.[etm|ptm]/timestamp_event
Date: November 2014
KernelVersion: 3.19
Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
Description: (RW) Defines an event that requests the insertion of a timestamp
into the trace stream.
What: /sys/bus/coresight/devices/<memory_map>.[etm|ptm]/traceid
Date: November 2014
KernelVersion: 3.19
Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
Description: (RW) Holds the trace ID that will appear in the trace stream
coming from this trace entity.
What: /sys/bus/coresight/devices/<memory_map>.[etm|ptm]/trigger_event
Date: November 2014
KernelVersion: 3.19
Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
Description: (RW) Define the event that controls the trigger.

12
Documentation/ABI/testing/sysfs-bus-coresight-devices-funnel Normal file
View File

@@ -0,0 +1,12 @@
What: /sys/bus/coresight/devices/<memory_map>.funnel/funnel_ctrl
Date: November 2014
KernelVersion: 3.19
Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
Description: (RW) Enables the slave ports and defines the hold time of the
slave ports.
What: /sys/bus/coresight/devices/<memory_map>.funnel/priority
Date: November 2014
KernelVersion: 3.19
Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
Description: (RW) Defines input port priority order.

8
Documentation/ABI/testing/sysfs-bus-coresight-devices-tmc Normal file
View File

@@ -0,0 +1,8 @@
What: /sys/bus/coresight/devices/<memory_map>.tmc/trigger_cntr
Date: November 2014
KernelVersion: 3.19
Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
Description: (RW) Disables write access to the Trace RAM by stopping the
formatter after a defined number of words have been stored
following the trigger event. Additional interface for this
driver are expected to be added as it matures.

23
Documentation/ABI/testing/sysfs-bus-iio
View File

@@ -200,6 +200,13 @@ Description:
Raw pressure measurement from channel Y. Units after
application of scale and offset are kilopascal.
What: /sys/bus/iio/devices/iio:deviceX/in_pressureY_input
What: /sys/bus/iio/devices/iio:deviceX/in_pressure_input
KernelVersion: 3.8
Contact: linux-iio@vger.kernel.org
Description:
Scaled pressure measurement from channel Y, in kilopascal.
What: /sys/bus/iio/devices/iio:deviceX/in_humidityrelative_raw
KernelVersion: 3.14
Contact: linux-iio@vger.kernel.org
@@ -231,6 +238,7 @@ What: /sys/bus/iio/devices/iio:deviceX/in_tempY_offset
What: /sys/bus/iio/devices/iio:deviceX/in_temp_offset
What: /sys/bus/iio/devices/iio:deviceX/in_pressureY_offset
What: /sys/bus/iio/devices/iio:deviceX/in_pressure_offset
What: /sys/bus/iio/devices/iio:deviceX/in_humidityrelative_offset
KernelVersion: 2.6.35
Contact: linux-iio@vger.kernel.org
Description:
@@ -251,6 +259,7 @@ Description:
What: /sys/bus/iio/devices/iio:deviceX/in_voltageY_scale
What: /sys/bus/iio/devices/iio:deviceX/in_voltageY_supply_scale
What: /sys/bus/iio/devices/iio:deviceX/in_voltage_scale
What: /sys/bus/iio/devices/iio:deviceX/in_voltage-voltage_scale
What: /sys/bus/iio/devices/iio:deviceX/out_voltageY_scale
What: /sys/bus/iio/devices/iio:deviceX/out_altvoltageY_scale
What: /sys/bus/iio/devices/iio:deviceX/in_accel_scale
@@ -266,6 +275,7 @@ What: /sys/bus/iio/devices/iio:deviceX/in_rot_from_north_magnetic_tilt_comp_sca
What: /sys/bus/iio/devices/iio:deviceX/in_rot_from_north_true_tilt_comp_scale
What: /sys/bus/iio/devices/iio:deviceX/in_pressureY_scale
What: /sys/bus/iio/devices/iio:deviceX/in_pressure_scale
What: /sys/bus/iio/devices/iio:deviceX/in_humidityrelative_scale
KernelVersion: 2.6.35
Contact: linux-iio@vger.kernel.org
Description:
@@ -328,6 +338,10 @@ Description:
are listed in this attribute.
What /sys/bus/iio/devices/iio:deviceX/out_voltageY_hardwaregain
What: /sys/bus/iio/devices/iio:deviceX/in_intensity_red_hardwaregain
What: /sys/bus/iio/devices/iio:deviceX/in_intensity_green_hardwaregain
What: /sys/bus/iio/devices/iio:deviceX/in_intensity_blue_hardwaregain
What: /sys/bus/iio/devices/iio:deviceX/in_intensity_clear_hardwaregain
KernelVersion: 2.6.35
Contact: linux-iio@vger.kernel.org
Description:
@@ -1028,3 +1042,12 @@ Contact: linux-iio@vger.kernel.org
Description:
Raw value of rotation from true/magnetic north measured with
or without compensation from tilt sensors.
What: /sys/bus/iio/devices/iio:deviceX/in_currentX_raw
KernelVersion: 3.18
Contact: linux-iio@vger.kernel.org
Description:
Raw current measurement from channel X. Units are in milliamps
after application of scale and offset. If no offset or scale is
present, output should be considered as processed with the
unit in milliamps.

13
Documentation/ABI/testing/sysfs-bus-pci
View File

@@ -281,3 +281,16 @@ Description:
opt-out of driver binding using a driver_override name such as
"none". Only a single driver may be specified in the override,
there is no support for parsing delimiters.
What: /sys/bus/pci/devices/.../numa_node
Date: Oct 2014
Contact: Prarit Bhargava <prarit@redhat.com>
Description:
This file contains the NUMA node to which the PCI device is
attached, or -1 if the node is unknown. The initial value
comes from an ACPI _PXM method or a similar firmware
source. If that is missing or incorrect, this file can be
written to override the node. In that case, please report
a firmware bug to the system vendor. Writing to this file
taints the kernel with TAINT_FIRMWARE_WORKAROUND, which
reduces the supportability of your system.

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

@@ -104,16 +104,15 @@ What: /sys/bus/usb/devices/.../power/usb2_hardware_lpm
Date: September 2011
Contact: Andiry Xu <andiry.xu@amd.com>
Description:
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
be enabled for the device and the USB device directory will
contain a file named power/usb2_hardware_lpm. The file holds
a string value (enable or disable) indicating whether or not
USB2 hardware LPM is enabled for the device. Developer can
write y/Y/1 or n/N/0 to the file to enable/disable the
feature.
If CONFIG_PM 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 be enabled for the
device and the USB device directory will contain a file named
power/usb2_hardware_lpm. The file holds a string value (enable
or disable) indicating whether or not USB2 hardware LPM is
enabled for the device. Developer can write y/Y/1 or n/N/0 to
the file to enable/disable the feature.
What: /sys/bus/usb/devices/.../removable
Date: February 2012

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

@@ -216,3 +216,11 @@ Contact: netdev@vger.kernel.org
Description:
Indicates the interface protocol type as a decimal value. See
include/uapi/linux/if_arp.h for all possible values.
What: /sys/class/net/<iface>/phys_switch_id
Date: November 2014
KernelVersion: 3.19
Contact: netdev@vger.kernel.org
Description:
Indicates the unique physical switch identifier of a switch this
port belongs to, as a string.

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

@@ -224,3 +224,50 @@ Description: Parameters for the Intel P-state driver
frequency range.
More details can be found in Documentation/cpu-freq/intel-pstate.txt
What: /sys/devices/system/cpu/cpu*/cache/index*/<set_of_attributes_mentioned_below>
Date: July 2014(documented, existed before August 2008)
Contact: Sudeep Holla <sudeep.holla@arm.com>
Linux kernel mailing list <linux-kernel@vger.kernel.org>
Description: Parameters for the CPU cache attributes
allocation_policy:
- WriteAllocate: allocate a memory location to a cache line
on a cache miss because of a write
- ReadAllocate: allocate a memory location to a cache line
on a cache miss because of a read
- ReadWriteAllocate: both writeallocate and readallocate
attributes: LEGACY used only on IA64 and is same as write_policy
coherency_line_size: the minimum amount of data in bytes that gets
transferred from memory to cache
level: the cache hierarcy in the multi-level cache configuration
number_of_sets: total number of sets in the cache, a set is a
collection of cache lines with the same cache index
physical_line_partition: number of physical cache line per cache tag
shared_cpu_list: the list of logical cpus sharing the cache
shared_cpu_map: logical cpu mask containing the list of cpus sharing
the cache
size: the total cache size in kB
type:
- Instruction: cache that only holds instructions
- Data: cache that only caches data
- Unified: cache that holds both data and instructions
ways_of_associativity: degree of freedom in placing a particular block
of memory in the cache
write_policy:
- WriteThrough: data is written to both the cache line
and to the block in the lower-level memory
- WriteBack: data is written only to the cache line and
the modified cache line is written to main
memory only when it is replaced

60
Documentation/ABI/testing/sysfs-platform-dell-laptop Normal file
View File

@@ -0,0 +1,60 @@
What: /sys/class/leds/dell::kbd_backlight/als_setting
Date: December 2014
KernelVersion: 3.19
Contact: Gabriele Mazzotta <gabriele.mzt@gmail.com>,
Pali Rohár <pali.rohar@gmail.com>
Description:
This file allows to control the automatic keyboard
illumination mode on some systems that have an ambient
light sensor. Write 1 to this file to enable the auto
mode, 0 to disable it.
What: /sys/class/leds/dell::kbd_backlight/start_triggers
Date: December 2014
KernelVersion: 3.19
Contact: Gabriele Mazzotta <gabriele.mzt@gmail.com>,
Pali Rohár <pali.rohar@gmail.com>
Description:
This file allows to control the input triggers that
turn on the keyboard backlight illumination that is
disabled because of inactivity.
Read the file to see the triggers available. The ones
enabled are preceded by '+', those disabled by '-'.
To enable a trigger, write its name preceded by '+' to
this file. To disable a trigger, write its name preceded
by '-' instead.
For example, to enable the keyboard as trigger run:
echo +keyboard > /sys/class/leds/dell::kbd_backlight/start_triggers
To disable it:
echo -keyboard > /sys/class/leds/dell::kbd_backlight/start_triggers
Note that not all the available triggers can be configured.
What: /sys/class/leds/dell::kbd_backlight/stop_timeout
Date: December 2014
KernelVersion: 3.19
Contact: Gabriele Mazzotta <gabriele.mzt@gmail.com>,
Pali Rohár <pali.rohar@gmail.com>
Description:
This file allows to specify the interval after which the
keyboard illumination is disabled because of inactivity.
The timeouts are expressed in seconds, minutes, hours and
days, for which the symbols are 's', 'm', 'h' and 'd'
respectively.
To configure the timeout, write to this file a value along
with any the above units. If no unit is specified, the value
is assumed to be expressed in seconds.
For example, to set the timeout to 10 minutes run:
echo 10m > /sys/class/leds/dell::kbd_backlight/stop_timeout
Note that when this file is read, the returned value might be
expressed in a different unit than the one used when the timeout
was set.
Also note that only some timeouts are supported and that
some systems might fall back to a specific timeout in case
an invalid timeout is written to this file.

2
Documentation/Changes
View File

@@ -383,7 +383,7 @@ o <http://www.iptables.org/downloads.html>
Ip-route2
---------
o <ftp://ftp.tux.org/pub/net/ip-routing/iproute2-2.2.4-now-ss991023.tar.gz>
o <https://www.kernel.org/pub/linux/utils/net/iproute2/>
OProfile
--------

70
Documentation/CodingStyle
View File

@@ -392,7 +392,12 @@ The goto statement comes in handy when a function exits from multiple
locations and some common work such as cleanup has to be done. If there is no
cleanup needed then just return directly.
The rationale is:
Choose label names which say what the goto does or why the goto exists. An
example of a good name could be "out_buffer:" if the goto frees "buffer". Avoid
using GW-BASIC names like "err1:" and "err2:". Also don't name them after the
goto location like "err_kmalloc_failed:"
The rationale for using gotos is:
- unconditional statements are easier to understand and follow
- nesting is reduced
@@ -403,9 +408,10 @@ The rationale is:
int fun(int a)
{
int result = 0;
char *buffer = kmalloc(SIZE);
char *buffer;
if (buffer == NULL)
buffer = kmalloc(SIZE, GFP_KERNEL);
if (!buffer)
return -ENOMEM;
if (condition1) {
@@ -413,14 +419,25 @@ int fun(int a)
...
}
result = 1;
goto out;
goto out_buffer;
}
...
out:
out_buffer:
kfree(buffer);
return result;
}
A common type of bug to be aware of it "one err bugs" which look like this:
err:
kfree(foo->bar);
kfree(foo);
return ret;
The bug in this code is that on some exit paths "foo" is NULL. Normally the
fix for this is to split it up into two error labels "err_bar:" and "err_foo:".
Chapter 8: Commenting
Comments are good, but there is also a danger of over-commenting. NEVER
@@ -845,6 +862,49 @@ next instruction in the assembly output:
: /* outputs */ : /* inputs */ : /* clobbers */);
Chapter 20: Conditional Compilation
Wherever possible, don't use preprocessor conditionals (#if, #ifdef) in .c
files; doing so makes code harder to read and logic harder to follow. Instead,
use such conditionals in a header file defining functions for use in those .c
files, providing no-op stub versions in the #else case, and then call those
functions unconditionally from .c files. The compiler will avoid generating
any code for the stub calls, producing identical results, but the logic will
remain easy to follow.
Prefer to compile out entire functions, rather than portions of functions or
portions of expressions. Rather than putting an ifdef in an expression, factor
out part or all of the expression into a separate helper function and apply the
conditional to that function.
If you have a function or variable which may potentially go unused in a
particular configuration, and the compiler would warn about its definition
going unused, mark the definition as __maybe_unused rather than wrapping it in
a preprocessor conditional. (However, if a function or variable *always* goes
unused, delete it.)
Within code, where possible, use the IS_ENABLED macro to convert a Kconfig
symbol into a C boolean expression, and use it in a normal C conditional:
if (IS_ENABLED(CONFIG_SOMETHING)) {
...
}
The compiler will constant-fold the conditional away, and include or exclude
the block of code just as with an #ifdef, so this will not add any runtime
overhead. However, this approach still allows the C compiler to see the code
inside the block, and check it for correctness (syntax, types, symbol
references, etc). Thus, you still have to use an #ifdef if the code inside the
block references symbols that will not exist if the condition is not met.
At the end of any non-trivial #if or #ifdef block (more than a few lines),
place a comment after the #endif on the same line, noting the conditional
expression used. For instance:
#ifdef CONFIG_SOMETHING
...
#endif /* CONFIG_SOMETHING */
Appendix I: References

2
Documentation/DocBook/Makefile
View File

@@ -15,7 +15,7 @@ DOCBOOKS := z8530book.xml device-drivers.xml \
80211.xml debugobjects.xml sh.xml regulator.xml \
alsa-driver-api.xml writing-an-alsa-driver.xml \
tracepoint.xml drm.xml media_api.xml w1.xml \
writing_musb_glue_layer.xml
writing_musb_glue_layer.xml crypto-API.xml
include Documentation/DocBook/media/Makefile

31
Documentation/DocBook/alsa-driver-api.tmpl
View File

@@ -57,6 +57,7 @@
!Esound/core/pcm.c
!Esound/core/pcm_lib.c
!Esound/core/pcm_native.c
!Iinclude/sound/pcm.h
</sect1>
<sect1><title>PCM Format Helpers</title>
!Esound/core/pcm_misc.c
@@ -64,6 +65,10 @@
<sect1><title>PCM Memory Management</title>
!Esound/core/pcm_memory.c
</sect1>
<sect1><title>PCM DMA Engine API</title>
!Esound/core/pcm_dmaengine.c
!Iinclude/sound/dmaengine_pcm.h
</sect1>
</chapter>
<chapter><title>Control/Mixer API</title>
<sect1><title>General Control Interface</title>
@@ -91,12 +96,38 @@
!Esound/core/info.c
</sect1>
</chapter>
<chapter><title>Compress Offload</title>
<sect1><title>Compress Offload API</title>
!Esound/core/compress_offload.c
!Iinclude/uapi/sound/compress_offload.h
!Iinclude/uapi/sound/compress_params.h
!Iinclude/sound/compress_driver.h
</sect1>
</chapter>
<chapter><title>ASoC</title>
<sect1><title>ASoC Core API</title>
!Iinclude/sound/soc.h
!Esound/soc/soc-core.c
!Esound/soc/soc-cache.c
!Esound/soc/soc-devres.c
!Esound/soc/soc-io.c
!Esound/soc/soc-pcm.c
</sect1>
<sect1><title>ASoC DAPM API</title>
!Esound/soc/soc-dapm.c
</sect1>
<sect1><title>ASoC DMA Engine API</title>
!Esound/soc/soc-generic-dmaengine-pcm.c
</sect1>
</chapter>
<chapter><title>Miscellaneous Functions</title>
<sect1><title>Hardware-Dependent Devices API</title>
!Esound/core/hwdep.c
</sect1>
<sect1><title>Jack Abstraction Layer API</title>
!Iinclude/sound/jack.h
!Esound/core/jack.c
!Esound/soc/soc-jack.c
</sect1>
<sect1><title>ISA DMA Helpers</title>
!Esound/core/isadma.c

1253
Documentation/DocBook/crypto-API.tmpl Normal file
View File

File diff suppressed because it is too large Load Diff

39
Documentation/DocBook/drm.tmpl
View File

@@ -1947,10 +1947,16 @@ void intel_crt_init(struct drm_device *dev)
and then retrieves a list of modes by calling the connector
<methodname>get_modes</methodname> helper operation.
</para>
<para>
If the helper operation returns no mode, and if the connector status
is connector_status_connected, standard VESA DMT modes up to
1024x768 are automatically added to the modes list by a call to
<function>drm_add_modes_noedid</function>.
</para>
<para>
The function filters out modes larger than
The function then filters out modes larger than
<parameter>max_width</parameter> and <parameter>max_height</parameter>
if specified. It then calls the optional connector
if specified. It finally calls the optional connector
<methodname>mode_valid</methodname> helper operation for each mode in
the probed list to check whether the mode is valid for the connector.
</para>
@@ -2090,11 +2096,19 @@ void intel_crt_init(struct drm_device *dev)
<synopsis>int (*get_modes)(struct drm_connector *connector);</synopsis>
<para>
Fill the connector's <structfield>probed_modes</structfield> list
by parsing EDID data with <function>drm_add_edid_modes</function> or
calling <function>drm_mode_probed_add</function> directly for every
by parsing EDID data with <function>drm_add_edid_modes</function>,
adding standard VESA DMT modes with <function>drm_add_modes_noedid</function>,
or calling <function>drm_mode_probed_add</function> directly for every
supported mode and return the number of modes it has detected. This
operation is mandatory.
</para>
<para>
Note that the caller function will automatically add standard VESA
DMT modes up to 1024x768 if the <methodname>get_modes</methodname>
helper operation returns no mode and if the connector status is
connector_status_connected. There is no need to call
<function>drm_add_edid_modes</function> manually in that case.
</para>
<para>
When adding modes manually the driver creates each mode with a call to
<function>drm_mode_create</function> and must fill the following fields.
@@ -2292,7 +2306,7 @@ void intel_crt_init(struct drm_device *dev)
<function>drm_helper_probe_single_connector_modes</function>.
</para>
<para>
When parsing EDID data, <function>drm_add_edid_modes</function> fill the
When parsing EDID data, <function>drm_add_edid_modes</function> fills the
connector <structfield>display_info</structfield>
<structfield>width_mm</structfield> and
<structfield>height_mm</structfield> fields. When creating modes
@@ -2412,6 +2426,10 @@ void intel_crt_init(struct drm_device *dev)
!Edrivers/gpu/drm/drm_plane_helper.c
!Pdrivers/gpu/drm/drm_plane_helper.c overview
</sect2>
<sect2>
<title>Tile group</title>
!Pdrivers/gpu/drm/drm_crtc.c Tile group
</sect2>
</sect1>
<!-- Internals: kms properties -->
@@ -2546,8 +2564,8 @@ void intel_crt_init(struct drm_device *dev)
<td valign="top" >Description/Restrictions</td>
</tr>
<tr>
<td rowspan="23" valign="top" >DRM</td>
<td rowspan="3" valign="top" >Generic</td>
<td rowspan="25" valign="top" >DRM</td>
<td rowspan="4" valign="top" >Generic</td>
<td valign="top" >“EDID”</td>
<td valign="top" >BLOB | IMMUTABLE</td>
<td valign="top" >0</td>
@@ -2569,6 +2587,13 @@ void intel_crt_init(struct drm_device *dev)
<td valign="top" >Contains topology path to a connector.</td>
</tr>
<tr>
<td valign="top" >“TILE”</td>
<td valign="top" >BLOB | IMMUTABLE</td>
<td valign="top" >0</td>
<td valign="top" >Connector</td>
<td valign="top" >Contains tiling information for a connector.</td>
</tr>
<tr>
<td rowspan="1" valign="top" >Plane</td>
<td valign="top" >“type”</td>
<td valign="top" >ENUM | IMMUTABLE</td>

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

@@ -120,8 +120,8 @@ struct dtv_properties {
</para>
<informaltable><tgroup cols="1"><tbody><row><entry
align="char">
<para>This ioctl call sets one or more frontend properties. This call only
requires read-only access to the device.</para>
<para>This ioctl call sets one or more frontend properties. This call
requires read/write access to the device.</para>
</entry>
</row></tbody></tgroup></informaltable>
<para>SYNOPSIS

85
Documentation/DocBook/media/v4l/biblio.xml
View File

@@ -178,6 +178,75 @@ Signal - NTSC for Studio Applications"</title>
1125-Line High-Definition Production"</title>
</biblioentry>
<biblioentry id="srgb">
<abbrev>sRGB</abbrev>
<authorgroup>
<corpauthor>International Electrotechnical Commission
(<ulink url="http://www.iec.ch">http://www.iec.ch</ulink>)</corpauthor>
</authorgroup>
<title>IEC 61966-2-1 ed1.0 "Multimedia systems and equipment - Colour measurement
and management - Part 2-1: Colour management - Default RGB colour space - sRGB"</title>
</biblioentry>
<biblioentry id="sycc">
<abbrev>sYCC</abbrev>
<authorgroup>
<corpauthor>International Electrotechnical Commission
(<ulink url="http://www.iec.ch">http://www.iec.ch</ulink>)</corpauthor>
</authorgroup>
<title>IEC 61966-2-1-am1 ed1.0 "Amendment 1 - Multimedia systems and equipment - Colour measurement
and management - Part 2-1: Colour management - Default RGB colour space - sRGB"</title>
</biblioentry>
<biblioentry id="xvycc">
<abbrev>xvYCC</abbrev>
<authorgroup>
<corpauthor>International Electrotechnical Commission
(<ulink url="http://www.iec.ch">http://www.iec.ch</ulink>)</corpauthor>
</authorgroup>
<title>IEC 61966-2-4 ed1.0 "Multimedia systems and equipment - Colour measurement
and management - Part 2-4: Colour management - Extended-gamut YCC colour space for video
applications - xvYCC"</title>
</biblioentry>
<biblioentry id="adobergb">
<abbrev>AdobeRGB</abbrev>
<authorgroup>
<corpauthor>Adobe Systems Incorporated (<ulink url="http://www.adobe.com">http://www.adobe.com</ulink>)</corpauthor>
</authorgroup>
<title>Adobe&copy; RGB (1998) Color Image Encoding Version 2005-05</title>
</biblioentry>
<biblioentry id="oprgb">
<abbrev>opRGB</abbrev>
<authorgroup>
<corpauthor>International Electrotechnical Commission
(<ulink url="http://www.iec.ch">http://www.iec.ch</ulink>)</corpauthor>
</authorgroup>
<title>IEC 61966-2-5 "Multimedia systems and equipment - Colour measurement
and management - Part 2-5: Colour management - Optional RGB colour space - opRGB"</title>
</biblioentry>
<biblioentry id="itu2020">
<abbrev>ITU&nbsp;BT.2020</abbrev>
<authorgroup>
<corpauthor>International Telecommunication Union (<ulink
url="http://www.itu.ch">http://www.itu.ch</ulink>)</corpauthor>
</authorgroup>
<title>ITU-R Recommendation BT.2020 (08/2012) "Parameter values for ultra-high
definition television systems for production and international programme exchange"
</title>
</biblioentry>
<biblioentry id="tech3213">
<abbrev>EBU&nbsp;Tech&nbsp;3213</abbrev>
<authorgroup>
<corpauthor>European Broadcast Union (<ulink
url="http://www.ebu.ch">http://www.ebu.ch</ulink>)</corpauthor>
</authorgroup>
<title>E.B.U. Standard for Chromaticity Tolerances for Studio Monitors"</title>
</biblioentry>
<biblioentry id="iec62106">
<abbrev>IEC&nbsp;62106</abbrev>
<authorgroup>
@@ -266,4 +335,20 @@ in the frequency range from 87,5 to 108,0 MHz</title>
<subtitle>Version 1, Revision 2</subtitle>
</biblioentry>
<biblioentry id="poynton">
<abbrev>poynton</abbrev>
<authorgroup>
<corpauthor>Charles Poynton</corpauthor>
</authorgroup>
<title>Digital Video and HDTV, Algorithms and Interfaces</title>
</biblioentry>
<biblioentry id="colimg">
<abbrev>colimg</abbrev>
<authorgroup>
<corpauthor>Erik Reinhard et al.</corpauthor>
</authorgroup>
<title>Color Imaging: Fundamentals and Applications</title>
</biblioentry>
</bibliography>

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

@@ -2579,6 +2579,18 @@ fields changed from _s32 to _u32.
</orderedlist>
</section>
<section>
<title>V4L2 in Linux 3.19</title>
<orderedlist>
<listitem>
<para>Rewrote Colorspace chapter, added new &v4l2-ycbcr-encoding;
and &v4l2-quantization; fields to &v4l2-pix-format;, &v4l2-pix-format-mplane;
and &v4l2-mbus-framefmt;.
</para>
</listitem>
</orderedlist>
</section>
<section id="other">
<title>Relation of V4L2 to other Linux multimedia APIs</title>

109
Documentation/DocBook/media/v4l/dev-subdev.xml
View File

@@ -195,53 +195,59 @@
<title>Sample Pipeline Configuration</title>
<tgroup cols="3">
<colspec colname="what"/>
<colspec colname="sensor-0" />
<colspec colname="frontend-0" />
<colspec colname="frontend-1" />
<colspec colname="scaler-0" />
<colspec colname="scaler-1" />
<colspec colname="sensor-0 format" />
<colspec colname="frontend-0 format" />
<colspec colname="frontend-1 format" />
<colspec colname="scaler-0 format" />
<colspec colname="scaler-0 compose" />
<colspec colname="scaler-1 format" />
<thead>
<row>
<entry></entry>
<entry>Sensor/0</entry>
<entry>Frontend/0</entry>
<entry>Frontend/1</entry>
<entry>Scaler/0</entry>
<entry>Scaler/1</entry>
<entry>Sensor/0 format</entry>
<entry>Frontend/0 format</entry>
<entry>Frontend/1 format</entry>
<entry>Scaler/0 format</entry>
<entry>Scaler/0 compose selection rectangle</entry>
<entry>Scaler/1 format</entry>
</row>
</thead>
<tbody valign="top">
<row>
<entry>Initial state</entry>
<entry>2048x1536</entry>
<entry>-</entry>
<entry>-</entry>
<entry>-</entry>
<entry>-</entry>
<entry>2048x1536/SGRBG8_1X8</entry>
<entry>(default)</entry>
<entry>(default)</entry>
<entry>(default)</entry>
<entry>(default)</entry>
<entry>(default)</entry>
</row>
<row>
<entry>Configure frontend input</entry>
<entry>2048x1536</entry>
<entry><emphasis>2048x1536</emphasis></entry>
<entry><emphasis>2046x1534</emphasis></entry>
<entry>-</entry>
<entry>-</entry>
<entry>Configure frontend sink format</entry>
<entry>2048x1536/SGRBG8_1X8</entry>
<entry><emphasis>2048x1536/SGRBG8_1X8</emphasis></entry>
<entry><emphasis>2046x1534/SGRBG8_1X8</emphasis></entry>
<entry>(default)</entry>
<entry>(default)</entry>
<entry>(default)</entry>
</row>
<row>
<entry>Configure scaler input</entry>
<entry>2048x1536</entry>
<entry>2048x1536</entry>
<entry>2046x1534</entry>
<entry><emphasis>2046x1534</emphasis></entry>
<entry><emphasis>2046x1534</emphasis></entry>
<entry>Configure scaler sink format</entry>
<entry>2048x1536/SGRBG8_1X8</entry>
<entry>2048x1536/SGRBG8_1X8</entry>
<entry>2046x1534/SGRBG8_1X8</entry>
<entry><emphasis>2046x1534/SGRBG8_1X8</emphasis></entry>
<entry><emphasis>0,0/2046x1534</emphasis></entry>
<entry><emphasis>2046x1534/SGRBG8_1X8</emphasis></entry>
</row>
<row>
<entry>Configure scaler output</entry>
<entry>2048x1536</entry>
<entry>2048x1536</entry>
<entry>2046x1534</entry>
<entry>2046x1534</entry>
<entry><emphasis>1280x960</emphasis></entry>
<entry>Configure scaler sink compose selection</entry>
<entry>2048x1536/SGRBG8_1X8</entry>
<entry>2048x1536/SGRBG8_1X8</entry>
<entry>2046x1534/SGRBG8_1X8</entry>
<entry>2046x1534/SGRBG8_1X8</entry>
<entry><emphasis>0,0/1280x960</emphasis></entry>
<entry><emphasis>1280x960/SGRBG8_1X8</emphasis></entry>
</row>
</tbody>
</tgroup>
@@ -249,19 +255,30 @@
<para>
<orderedlist>
<listitem><para>Initial state. The sensor output is set to its native 3MP
resolution. Resolutions on the host frontend and scaler input and output
pads are undefined.</para></listitem>
<listitem><para>The application configures the frontend input pad resolution to
2048x1536. The driver propagates the format to the frontend output pad.
Note that the propagated output format can be different, as in this case,
than the input format, as the hardware might need to crop pixels (for
instance when converting a Bayer filter pattern to RGB or YUV).</para></listitem>
<listitem><para>The application configures the scaler input pad resolution to
2046x1534 to match the frontend output resolution. The driver propagates
the format to the scaler output pad.</para></listitem>
<listitem><para>The application configures the scaler output pad resolution to
1280x960.</para></listitem>
<listitem><para>Initial state. The sensor source pad format is
set to its native 3MP size and V4L2_MBUS_FMT_SGRBG8_1X8
media bus code. Formats on the host frontend and scaler sink
and source pads have the default values, as well as the
compose rectangle on the scaler's sink pad.</para></listitem>
<listitem><para>The application configures the frontend sink
pad format's size to 2048x1536 and its media bus code to
V4L2_MBUS_FMT_SGRBG_1X8. The driver propagates the format to
the frontend source pad.</para></listitem>
<listitem><para>The application configures the scaler sink pad
format's size to 2046x1534 and the media bus code to
V4L2_MBUS_FMT_SGRBG_1X8 to match the frontend source size and
media bus code. The media bus code on the sink pad is set to
V4L2_MBUS_FMT_SGRBG_1X8. The driver propagates the size to the
compose selection rectangle on the scaler's sink pad, and the
format to the scaler source pad.</para></listitem>
<listitem><para>The application configures the size of the compose
selection rectangle of the scaler's sink pad 1280x960. The driver
propagates the size to the scaler's source pad
format.</para></listitem>
</orderedlist>
</para>

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

@@ -1422,7 +1422,10 @@ one of the <constant>V4L2_FIELD_NONE</constant>,
<constant>V4L2_FIELD_BOTTOM</constant>, or
<constant>V4L2_FIELD_INTERLACED</constant> formats is acceptable.
Drivers choose depending on hardware capabilities or e.&nbsp;g. the
requested image size, and return the actual field order. &v4l2-buffer;
requested image size, and return the actual field order. Drivers must
never return <constant>V4L2_FIELD_ANY</constant>. If multiple
field orders are possible the driver must choose one of the possible
field orders during &VIDIOC-S-FMT; or &VIDIOC-TRY-FMT;. &v4l2-buffer;
<structfield>field</structfield> can never be
<constant>V4L2_FIELD_ANY</constant>.</entry>
</row>

1296
Documentation/DocBook/media/v4l/pixfmt.xml
View File

File diff suppressed because it is too large Load Diff

16
Documentation/DocBook/media/v4l/selections-common.xml
View File

@@ -62,6 +62,22 @@
<entry>Yes</entry>
<entry>Yes</entry>
</row>
<row>
<entry><constant>V4L2_SEL_TGT_NATIVE_SIZE</constant></entry>
<entry>0x0003</entry>
<entry>The native size of the device, e.g. a sensor's
pixel array. <structfield>left</structfield> and
<structfield>top</structfield> fields are zero for this
target. Setting the native size will generally only make
sense for memory to memory devices where the software can
create a canvas of a given size in which for example a
video frame can be composed. In that case
V4L2_SEL_TGT_NATIVE_SIZE can be used to configure the size
of that canvas.
</entry>
<entry>Yes</entry>
<entry>Yes</entry>
</row>
<row>
<entry><constant>V4L2_SEL_TGT_COMPOSE</constant></entry>
<entry>0x0100</entry>

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

@@ -33,9 +33,25 @@
<entry>Image colorspace, from &v4l2-colorspace;. See
<xref linkend="colorspaces" /> for details.</entry>
</row>
<row>
<entry>&v4l2-ycbcr-encoding;</entry>
<entry><structfield>ycbcr_enc</structfield></entry>
<entry>This information supplements the
<structfield>colorspace</structfield> and must be set by the driver for
capture streams and by the application for output streams,
see <xref linkend="colorspaces" />.</entry>
</row>
<row>
<entry>&v4l2-quantization;</entry>
<entry><structfield>quantization</structfield></entry>
<entry>This information supplements the
<structfield>colorspace</structfield> and must be set by the driver for
capture streams and by the application for output streams,
see <xref linkend="colorspaces" />.</entry>
</row>
<row>
<entry>__u32</entry>
<entry><structfield>reserved</structfield>[7]</entry>
<entry><structfield>reserved</structfield>[6]</entry>
<entry>Reserved for future extensions. Applications and drivers must
set the array to zero.</entry>
</row>
@@ -86,7 +102,7 @@
green and 5-bit blue values padded on the high bit, transferred as 2 8-bit
samples per pixel with the most significant bits (padding, red and half of
the green value) transferred first will be named
<constant>V4L2_MBUS_FMT_RGB555_2X8_PADHI_BE</constant>.
<constant>MEDIA_BUS_FMT_RGB555_2X8_PADHI_BE</constant>.
</para>
<para>The following tables list existing packed RGB formats.</para>
@@ -176,8 +192,8 @@
</row>
</thead>
<tbody valign="top">
<row id="V4L2-MBUS-FMT-RGB444-2X8-PADHI-BE">
<entry>V4L2_MBUS_FMT_RGB444_2X8_PADHI_BE</entry>
<row id="MEDIA-BUS-FMT-RGB444-2X8-PADHI-BE">
<entry>MEDIA_BUS_FMT_RGB444_2X8_PADHI_BE</entry>
<entry>0x1001</entry>
<entry></entry>
&dash-ent-24;
@@ -204,8 +220,8 @@
<entry>b<subscript>1</subscript></entry>
<entry>b<subscript>0</subscript></entry>
</row>
<row id="V4L2-MBUS-FMT-RGB444-2X8-PADHI-LE">
<entry>V4L2_MBUS_FMT_RGB444_2X8_PADHI_LE</entry>
<row id="MEDIA-BUS-FMT-RGB444-2X8-PADHI-LE">
<entry>MEDIA_BUS_FMT_RGB444_2X8_PADHI_LE</entry>
<entry>0x1002</entry>
<entry></entry>
&dash-ent-24;
@@ -232,8 +248,8 @@
<entry>r<subscript>1</subscript></entry>
<entry>r<subscript>0</subscript></entry>
</row>
<row id="V4L2-MBUS-FMT-RGB555-2X8-PADHI-BE">
<entry>V4L2_MBUS_FMT_RGB555_2X8_PADHI_BE</entry>
<row id="MEDIA-BUS-FMT-RGB555-2X8-PADHI-BE">
<entry>MEDIA_BUS_FMT_RGB555_2X8_PADHI_BE</entry>
<entry>0x1003</entry>
<entry></entry>
&dash-ent-24;
@@ -260,8 +276,8 @@
<entry>b<subscript>1</subscript></entry>
<entry>b<subscript>0</subscript></entry>
</row>
<row id="V4L2-MBUS-FMT-RGB555-2X8-PADHI-LE">
<entry>V4L2_MBUS_FMT_RGB555_2X8_PADHI_LE</entry>
<row id="MEDIA-BUS-FMT-RGB555-2X8-PADHI-LE">
<entry>MEDIA_BUS_FMT_RGB555_2X8_PADHI_LE</entry>
<entry>0x1004</entry>
<entry></entry>
&dash-ent-24;
@@ -288,8 +304,8 @@
<entry>g<subscript>4</subscript></entry>
<entry>g<subscript>3</subscript></entry>
</row>
<row id="V4L2-MBUS-FMT-BGR565-2X8-BE">
<entry>V4L2_MBUS_FMT_BGR565_2X8_BE</entry>
<row id="MEDIA-BUS-FMT-BGR565-2X8-BE">
<entry>MEDIA_BUS_FMT_BGR565_2X8_BE</entry>
<entry>0x1005</entry>
<entry></entry>
&dash-ent-24;
@@ -316,8 +332,8 @@
<entry>r<subscript>1</subscript></entry>
<entry>r<subscript>0</subscript></entry>
</row>
<row id="V4L2-MBUS-FMT-BGR565-2X8-LE">
<entry>V4L2_MBUS_FMT_BGR565_2X8_LE</entry>
<row id="MEDIA-BUS-FMT-BGR565-2X8-LE">
<entry>MEDIA_BUS_FMT_BGR565_2X8_LE</entry>
<entry>0x1006</entry>
<entry></entry>
&dash-ent-24;
@@ -344,8 +360,8 @@
<entry>g<subscript>4</subscript></entry>
<entry>g<subscript>3</subscript></entry>
</row>
<row id="V4L2-MBUS-FMT-RGB565-2X8-BE">
<entry>V4L2_MBUS_FMT_RGB565_2X8_BE</entry>
<row id="MEDIA-BUS-FMT-RGB565-2X8-BE">
<entry>MEDIA_BUS_FMT_RGB565_2X8_BE</entry>
<entry>0x1007</entry>
<entry></entry>
&dash-ent-24;
@@ -372,8 +388,8 @@
<entry>b<subscript>1</subscript></entry>
<entry>b<subscript>0</subscript></entry>
</row>
<row id="V4L2-MBUS-FMT-RGB565-2X8-LE">
<entry>V4L2_MBUS_FMT_RGB565_2X8_LE</entry>
<row id="MEDIA-BUS-FMT-RGB565-2X8-LE">
<entry>MEDIA_BUS_FMT_RGB565_2X8_LE</entry>
<entry>0x1008</entry>
<entry></entry>
&dash-ent-24;
@@ -400,8 +416,8 @@
<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>
<row id="MEDIA-BUS-FMT-RGB666-1X18">
<entry>MEDIA_BUS_FMT_RGB666_1X18</entry>
<entry>0x1009</entry>
<entry></entry>
&dash-ent-14;
@@ -424,8 +440,8 @@
<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>
<row id="MEDIA-BUS-FMT-RGB888-1X24">
<entry>MEDIA_BUS_FMT_RGB888_1X24</entry>
<entry>0x100a</entry>
<entry></entry>
&dash-ent-8;
@@ -454,8 +470,8 @@
<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>
<row id="MEDIA-BUS-FMT-RGB888-2X12-BE">
<entry>MEDIA_BUS_FMT_RGB888_2X12_BE</entry>
<entry>0x100b</entry>
<entry></entry>
&dash-ent-20;
@@ -490,8 +506,8 @@
<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>
<row id="MEDIA-BUS-FMT-RGB888-2X12-LE">
<entry>MEDIA_BUS_FMT_RGB888_2X12_LE</entry>
<entry>0x100c</entry>
<entry></entry>
&dash-ent-20;
@@ -526,8 +542,8 @@
<entry>g<subscript>5</subscript></entry>
<entry>g<subscript>4</subscript></entry>
</row>
<row id="V4L2-MBUS-FMT-ARGB888-1X32">
<entry>V4L2_MBUS_FMT_ARGB888_1X32</entry>
<row id="MEDIA-BUS-FMT-ARGB888-1X32">
<entry>MEDIA_BUS_FMT_ARGB888_1X32</entry>
<entry>0x100d</entry>
<entry></entry>
<entry>a<subscript>7</subscript></entry>
@@ -600,7 +616,7 @@
<para>For instance, a format with uncompressed 10-bit Bayer components
arranged in a red, green, green, blue pattern transferred as 2 8-bit
samples per pixel with the least significant bits transferred first will
be named <constant>V4L2_MBUS_FMT_SRGGB10_2X8_PADHI_LE</constant>.
be named <constant>MEDIA_BUS_FMT_SRGGB10_2X8_PADHI_LE</constant>.
</para>
<figure id="bayer-patterns">
@@ -663,8 +679,8 @@
</row>
</thead>
<tbody valign="top">
<row id="V4L2-MBUS-FMT-SBGGR8-1X8">
<entry>V4L2_MBUS_FMT_SBGGR8_1X8</entry>
<row id="MEDIA-BUS-FMT-SBGGR8-1X8">
<entry>MEDIA_BUS_FMT_SBGGR8_1X8</entry>
<entry>0x3001</entry>
<entry></entry>
<entry>-</entry>
@@ -680,8 +696,8 @@
<entry>b<subscript>1</subscript></entry>
<entry>b<subscript>0</subscript></entry>
</row>
<row id="V4L2-MBUS-FMT-SGBRG8-1X8">
<entry>V4L2_MBUS_FMT_SGBRG8_1X8</entry>
<row id="MEDIA-BUS-FMT-SGBRG8-1X8">
<entry>MEDIA_BUS_FMT_SGBRG8_1X8</entry>
<entry>0x3013</entry>
<entry></entry>
<entry>-</entry>
@@ -697,8 +713,8 @@
<entry>g<subscript>1</subscript></entry>
<entry>g<subscript>0</subscript></entry>
</row>
<row id="V4L2-MBUS-FMT-SGRBG8-1X8">
<entry>V4L2_MBUS_FMT_SGRBG8_1X8</entry>
<row id="MEDIA-BUS-FMT-SGRBG8-1X8">
<entry>MEDIA_BUS_FMT_SGRBG8_1X8</entry>
<entry>0x3002</entry>
<entry></entry>
<entry>-</entry>
@@ -714,8 +730,8 @@
<entry>g<subscript>1</subscript></entry>
<entry>g<subscript>0</subscript></entry>
</row>
<row id="V4L2-MBUS-FMT-SRGGB8-1X8">
<entry>V4L2_MBUS_FMT_SRGGB8_1X8</entry>
<row id="MEDIA-BUS-FMT-SRGGB8-1X8">
<entry>MEDIA_BUS_FMT_SRGGB8_1X8</entry>
<entry>0x3014</entry>
<entry></entry>
<entry>-</entry>
@@ -731,8 +747,8 @@
<entry>r<subscript>1</subscript></entry>
<entry>r<subscript>0</subscript></entry>
</row>
<row id="V4L2-MBUS-FMT-SBGGR10-ALAW8-1X8">
<entry>V4L2_MBUS_FMT_SBGGR10_ALAW8_1X8</entry>
<row id="MEDIA-BUS-FMT-SBGGR10-ALAW8-1X8">
<entry>MEDIA_BUS_FMT_SBGGR10_ALAW8_1X8</entry>
<entry>0x3015</entry>
<entry></entry>
<entry>-</entry>
@@ -748,8 +764,8 @@
<entry>b<subscript>1</subscript></entry>
<entry>b<subscript>0</subscript></entry>
</row>
<row id="V4L2-MBUS-FMT-SGBRG10-ALAW8-1X8">
<entry>V4L2_MBUS_FMT_SGBRG10_ALAW8_1X8</entry>
<row id="MEDIA-BUS-FMT-SGBRG10-ALAW8-1X8">
<entry>MEDIA_BUS_FMT_SGBRG10_ALAW8_1X8</entry>
<entry>0x3016</entry>
<entry></entry>
<entry>-</entry>
@@ -765,8 +781,8 @@
<entry>g<subscript>1</subscript></entry>
<entry>g<subscript>0</subscript></entry>
</row>
<row id="V4L2-MBUS-FMT-SGRBG10-ALAW8-1X8">
<entry>V4L2_MBUS_FMT_SGRBG10_ALAW8_1X8</entry>
<row id="MEDIA-BUS-FMT-SGRBG10-ALAW8-1X8">
<entry>MEDIA_BUS_FMT_SGRBG10_ALAW8_1X8</entry>
<entry>0x3017</entry>
<entry></entry>
<entry>-</entry>
@@ -782,8 +798,8 @@
<entry>g<subscript>1</subscript></entry>
<entry>g<subscript>0</subscript></entry>
</row>
<row id="V4L2-MBUS-FMT-SRGGB10-ALAW8-1X8">
<entry>V4L2_MBUS_FMT_SRGGB10_ALAW8_1X8</entry>
<row id="MEDIA-BUS-FMT-SRGGB10-ALAW8-1X8">
<entry>MEDIA_BUS_FMT_SRGGB10_ALAW8_1X8</entry>
<entry>0x3018</entry>
<entry></entry>
<entry>-</entry>
@@ -799,8 +815,8 @@
<entry>r<subscript>1</subscript></entry>
<entry>r<subscript>0</subscript></entry>
</row>
<row id="V4L2-MBUS-FMT-SBGGR10-DPCM8-1X8">
<entry>V4L2_MBUS_FMT_SBGGR10_DPCM8_1X8</entry>
<row id="MEDIA-BUS-FMT-SBGGR10-DPCM8-1X8">
<entry>MEDIA_BUS_FMT_SBGGR10_DPCM8_1X8</entry>
<entry>0x300b</entry>
<entry></entry>
<entry>-</entry>
@@ -816,8 +832,8 @@
<entry>b<subscript>1</subscript></entry>
<entry>b<subscript>0</subscript></entry>
</row>
<row id="V4L2-MBUS-FMT-SGBRG10-DPCM8-1X8">
<entry>V4L2_MBUS_FMT_SGBRG10_DPCM8_1X8</entry>
<row id="MEDIA-BUS-FMT-SGBRG10-DPCM8-1X8">
<entry>MEDIA_BUS_FMT_SGBRG10_DPCM8_1X8</entry>
<entry>0x300c</entry>
<entry></entry>
<entry>-</entry>
@@ -833,8 +849,8 @@
<entry>g<subscript>1</subscript></entry>
<entry>g<subscript>0</subscript></entry>
</row>
<row id="V4L2-MBUS-FMT-SGRBG10-DPCM8-1X8">
<entry>V4L2_MBUS_FMT_SGRBG10_DPCM8_1X8</entry>
<row id="MEDIA-BUS-FMT-SGRBG10-DPCM8-1X8">
<entry>MEDIA_BUS_FMT_SGRBG10_DPCM8_1X8</entry>
<entry>0x3009</entry>
<entry></entry>
<entry>-</entry>
@@ -850,8 +866,8 @@
<entry>g<subscript>1</subscript></entry>
<entry>g<subscript>0</subscript></entry>
</row>
<row id="V4L2-MBUS-FMT-SRGGB10-DPCM8-1X8">
<entry>V4L2_MBUS_FMT_SRGGB10_DPCM8_1X8</entry>
<row id="MEDIA-BUS-FMT-SRGGB10-DPCM8-1X8">
<entry>MEDIA_BUS_FMT_SRGGB10_DPCM8_1X8</entry>
<entry>0x300d</entry>
<entry></entry>
<entry>-</entry>
@@ -867,8 +883,8 @@
<entry>r<subscript>1</subscript></entry>
<entry>r<subscript>0</subscript></entry>
</row>
<row id="V4L2-MBUS-FMT-SBGGR10-2X8-PADHI-BE">
<entry>V4L2_MBUS_FMT_SBGGR10_2X8_PADHI_BE</entry>
<row id="MEDIA-BUS-FMT-SBGGR10-2X8-PADHI-BE">
<entry>MEDIA_BUS_FMT_SBGGR10_2X8_PADHI_BE</entry>
<entry>0x3003</entry>
<entry></entry>
<entry>-</entry>
@@ -901,8 +917,8 @@
<entry>b<subscript>1</subscript></entry>
<entry>b<subscript>0</subscript></entry>
</row>
<row id="V4L2-MBUS-FMT-SBGGR10-2X8-PADHI-LE">
<entry>V4L2_MBUS_FMT_SBGGR10_2X8_PADHI_LE</entry>
<row id="MEDIA-BUS-FMT-SBGGR10-2X8-PADHI-LE">
<entry>MEDIA_BUS_FMT_SBGGR10_2X8_PADHI_LE</entry>
<entry>0x3004</entry>
<entry></entry>
<entry>-</entry>
@@ -935,8 +951,8 @@
<entry>b<subscript>9</subscript></entry>
<entry>b<subscript>8</subscript></entry>
</row>
<row id="V4L2-MBUS-FMT-SBGGR10-2X8-PADLO-BE">
<entry>V4L2_MBUS_FMT_SBGGR10_2X8_PADLO_BE</entry>
<row id="MEDIA-BUS-FMT-SBGGR10-2X8-PADLO-BE">
<entry>MEDIA_BUS_FMT_SBGGR10_2X8_PADLO_BE</entry>
<entry>0x3005</entry>
<entry></entry>
<entry>-</entry>
@@ -969,8 +985,8 @@
<entry>0</entry>
<entry>0</entry>
</row>
<row id="V4L2-MBUS-FMT-SBGGR10-2X8-PADLO-LE">
<entry>V4L2_MBUS_FMT_SBGGR10_2X8_PADLO_LE</entry>
<row id="MEDIA-BUS-FMT-SBGGR10-2X8-PADLO-LE">
<entry>MEDIA_BUS_FMT_SBGGR10_2X8_PADLO_LE</entry>
<entry>0x3006</entry>
<entry></entry>
<entry>-</entry>
@@ -1003,8 +1019,8 @@
<entry>b<subscript>3</subscript></entry>
<entry>b<subscript>2</subscript></entry>
</row>
<row id="V4L2-MBUS-FMT-SBGGR10-1X10">
<entry>V4L2_MBUS_FMT_SBGGR10_1X10</entry>
<row id="MEDIA-BUS-FMT-SBGGR10-1X10">
<entry>MEDIA_BUS_FMT_SBGGR10_1X10</entry>
<entry>0x3007</entry>
<entry></entry>
<entry>-</entry>
@@ -1020,8 +1036,8 @@
<entry>b<subscript>1</subscript></entry>
<entry>b<subscript>0</subscript></entry>
</row>
<row id="V4L2-MBUS-FMT-SGBRG10-1X10">
<entry>V4L2_MBUS_FMT_SGBRG10_1X10</entry>
<row id="MEDIA-BUS-FMT-SGBRG10-1X10">
<entry>MEDIA_BUS_FMT_SGBRG10_1X10</entry>
<entry>0x300e</entry>
<entry></entry>
<entry>-</entry>
@@ -1037,8 +1053,8 @@
<entry>g<subscript>1</subscript></entry>
<entry>g<subscript>0</subscript></entry>
</row>
<row id="V4L2-MBUS-FMT-SGRBG10-1X10">
<entry>V4L2_MBUS_FMT_SGRBG10_1X10</entry>
<row id="MEDIA-BUS-FMT-SGRBG10-1X10">
<entry>MEDIA_BUS_FMT_SGRBG10_1X10</entry>
<entry>0x300a</entry>
<entry></entry>
<entry>-</entry>
@@ -1054,8 +1070,8 @@
<entry>g<subscript>1</subscript></entry>
<entry>g<subscript>0</subscript></entry>
</row>
<row id="V4L2-MBUS-FMT-SRGGB10-1X10">
<entry>V4L2_MBUS_FMT_SRGGB10_1X10</entry>
<row id="MEDIA-BUS-FMT-SRGGB10-1X10">
<entry>MEDIA_BUS_FMT_SRGGB10_1X10</entry>
<entry>0x300f</entry>
<entry></entry>
<entry>-</entry>
@@ -1071,8 +1087,8 @@
<entry>r<subscript>1</subscript></entry>
<entry>r<subscript>0</subscript></entry>
</row>
<row id="V4L2-MBUS-FMT-SBGGR12-1X12">
<entry>V4L2_MBUS_FMT_SBGGR12_1X12</entry>
<row id="MEDIA-BUS-FMT-SBGGR12-1X12">
<entry>MEDIA_BUS_FMT_SBGGR12_1X12</entry>
<entry>0x3008</entry>
<entry></entry>
<entry>b<subscript>11</subscript></entry>
@@ -1088,8 +1104,8 @@
<entry>b<subscript>1</subscript></entry>
<entry>b<subscript>0</subscript></entry>
</row>
<row id="V4L2-MBUS-FMT-SGBRG12-1X12">
<entry>V4L2_MBUS_FMT_SGBRG12_1X12</entry>
<row id="MEDIA-BUS-FMT-SGBRG12-1X12">
<entry>MEDIA_BUS_FMT_SGBRG12_1X12</entry>
<entry>0x3010</entry>
<entry></entry>
<entry>g<subscript>11</subscript></entry>
@@ -1105,8 +1121,8 @@
<entry>g<subscript>1</subscript></entry>
<entry>g<subscript>0</subscript></entry>
</row>
<row id="V4L2-MBUS-FMT-SGRBG12-1X12">
<entry>V4L2_MBUS_FMT_SGRBG12_1X12</entry>
<row id="MEDIA-BUS-FMT-SGRBG12-1X12">
<entry>MEDIA_BUS_FMT_SGRBG12_1X12</entry>
<entry>0x3011</entry>
<entry></entry>
<entry>g<subscript>11</subscript></entry>
@@ -1122,8 +1138,8 @@
<entry>g<subscript>1</subscript></entry>
<entry>g<subscript>0</subscript></entry>
</row>
<row id="V4L2-MBUS-FMT-SRGGB12-1X12">
<entry>V4L2_MBUS_FMT_SRGGB12_1X12</entry>
<row id="MEDIA-BUS-FMT-SRGGB12-1X12">
<entry>MEDIA_BUS_FMT_SRGGB12_1X12</entry>
<entry>0x3012</entry>
<entry></entry>
<entry>r<subscript>11</subscript></entry>
@@ -1175,7 +1191,7 @@
<para>For instance, a format where pixels are encoded as 8-bit YUV values
downsampled to 4:2:2 and transferred as 2 8-bit bus samples per pixel in the
U, Y, V, Y order will be named <constant>V4L2_MBUS_FMT_UYVY8_2X8</constant>.
U, Y, V, Y order will be named <constant>MEDIA_BUS_FMT_UYVY8_2X8</constant>.
</para>
<para><xref linkend="v4l2-mbus-pixelcode-yuv8"/> lists existing packed YUV
@@ -1280,8 +1296,8 @@
</row>
</thead>
<tbody valign="top">
<row id="V4L2-MBUS-FMT-Y8-1X8">
<entry>V4L2_MBUS_FMT_Y8_1X8</entry>
<row id="MEDIA-BUS-FMT-Y8-1X8">
<entry>MEDIA_BUS_FMT_Y8_1X8</entry>
<entry>0x2001</entry>
<entry></entry>
&dash-ent-24;
@@ -1294,8 +1310,8 @@
<entry>y<subscript>1</subscript></entry>
<entry>y<subscript>0</subscript></entry>
</row>
<row id="V4L2-MBUS-FMT-UV8-1X8">
<entry>V4L2_MBUS_FMT_UV8_1X8</entry>
<row id="MEDIA-BUS-FMT-UV8-1X8">
<entry>MEDIA_BUS_FMT_UV8_1X8</entry>
<entry>0x2015</entry>
<entry></entry>
&dash-ent-24;
@@ -1322,8 +1338,8 @@
<entry>v<subscript>1</subscript></entry>
<entry>v<subscript>0</subscript></entry>
</row>
<row id="V4L2-MBUS-FMT-UYVY8-1_5X8">
<entry>V4L2_MBUS_FMT_UYVY8_1_5X8</entry>
<row id="MEDIA-BUS-FMT-UYVY8-1_5X8">
<entry>MEDIA_BUS_FMT_UYVY8_1_5X8</entry>
<entry>0x2002</entry>
<entry></entry>
&dash-ent-24;
@@ -1406,8 +1422,8 @@
<entry>y<subscript>1</subscript></entry>
<entry>y<subscript>0</subscript></entry>
</row>
<row id="V4L2-MBUS-FMT-VYUY8-1_5X8">
<entry>V4L2_MBUS_FMT_VYUY8_1_5X8</entry>
<row id="MEDIA-BUS-FMT-VYUY8-1_5X8">
<entry>MEDIA_BUS_FMT_VYUY8_1_5X8</entry>
<entry>0x2003</entry>
<entry></entry>
&dash-ent-24;
@@ -1490,8 +1506,8 @@
<entry>y<subscript>1</subscript></entry>
<entry>y<subscript>0</subscript></entry>
</row>
<row id="V4L2-MBUS-FMT-YUYV8-1_5X8">
<entry>V4L2_MBUS_FMT_YUYV8_1_5X8</entry>
<row id="MEDIA-BUS-FMT-YUYV8-1_5X8">
<entry>MEDIA_BUS_FMT_YUYV8_1_5X8</entry>
<entry>0x2004</entry>
<entry></entry>
&dash-ent-24;
@@ -1574,8 +1590,8 @@
<entry>v<subscript>1</subscript></entry>
<entry>v<subscript>0</subscript></entry>
</row>
<row id="V4L2-MBUS-FMT-YVYU8-1_5X8">
<entry>V4L2_MBUS_FMT_YVYU8_1_5X8</entry>
<row id="MEDIA-BUS-FMT-YVYU8-1_5X8">
<entry>MEDIA_BUS_FMT_YVYU8_1_5X8</entry>
<entry>0x2005</entry>
<entry></entry>
&dash-ent-24;
@@ -1658,8 +1674,8 @@
<entry>u<subscript>1</subscript></entry>
<entry>u<subscript>0</subscript></entry>
</row>
<row id="V4L2-MBUS-FMT-UYVY8-2X8">
<entry>V4L2_MBUS_FMT_UYVY8_2X8</entry>
<row id="MEDIA-BUS-FMT-UYVY8-2X8">
<entry>MEDIA_BUS_FMT_UYVY8_2X8</entry>
<entry>0x2006</entry>
<entry></entry>
&dash-ent-24;
@@ -1714,8 +1730,8 @@
<entry>y<subscript>1</subscript></entry>
<entry>y<subscript>0</subscript></entry>
</row>
<row id="V4L2-MBUS-FMT-VYUY8-2X8">
<entry>V4L2_MBUS_FMT_VYUY8_2X8</entry>
<row id="MEDIA-BUS-FMT-VYUY8-2X8">
<entry>MEDIA_BUS_FMT_VYUY8_2X8</entry>
<entry>0x2007</entry>
<entry></entry>
&dash-ent-24;
@@ -1770,8 +1786,8 @@
<entry>y<subscript>1</subscript></entry>
<entry>y<subscript>0</subscript></entry>
</row>
<row id="V4L2-MBUS-FMT-YUYV8-2X8">
<entry>V4L2_MBUS_FMT_YUYV8_2X8</entry>
<row id="MEDIA-BUS-FMT-YUYV8-2X8">
<entry>MEDIA_BUS_FMT_YUYV8_2X8</entry>
<entry>0x2008</entry>
<entry></entry>
&dash-ent-24;
@@ -1826,8 +1842,8 @@
<entry>v<subscript>1</subscript></entry>
<entry>v<subscript>0</subscript></entry>
</row>
<row id="V4L2-MBUS-FMT-YVYU8-2X8">
<entry>V4L2_MBUS_FMT_YVYU8_2X8</entry>
<row id="MEDIA-BUS-FMT-YVYU8-2X8">
<entry>MEDIA_BUS_FMT_YVYU8_2X8</entry>
<entry>0x2009</entry>
<entry></entry>
&dash-ent-24;
@@ -1882,8 +1898,8 @@
<entry>u<subscript>1</subscript></entry>
<entry>u<subscript>0</subscript></entry>
</row>
<row id="V4L2-MBUS-FMT-Y10-1X10">
<entry>V4L2_MBUS_FMT_Y10_1X10</entry>
<row id="MEDIA-BUS-FMT-Y10-1X10">
<entry>MEDIA_BUS_FMT_Y10_1X10</entry>
<entry>0x200a</entry>
<entry></entry>
&dash-ent-22;
@@ -1898,8 +1914,8 @@
<entry>y<subscript>1</subscript></entry>
<entry>y<subscript>0</subscript></entry>
</row>
<row id="V4L2-MBUS-FMT-UYVY10-2X10">
<entry>V4L2_MBUS_FMT_UYVY10_2X10</entry>
<row id="MEDIA-BUS-FMT-UYVY10-2X10">
<entry>MEDIA_BUS_FMT_UYVY10_2X10</entry>
<entry>0x2018</entry>
<entry></entry>
&dash-ent-22;
@@ -1962,8 +1978,8 @@
<entry>y<subscript>1</subscript></entry>
<entry>y<subscript>0</subscript></entry>
</row>
<row id="V4L2-MBUS-FMT-VYUY10-2X10">
<entry>V4L2_MBUS_FMT_VYUY10_2X10</entry>
<row id="MEDIA-BUS-FMT-VYUY10-2X10">
<entry>MEDIA_BUS_FMT_VYUY10_2X10</entry>
<entry>0x2019</entry>
<entry></entry>
&dash-ent-22;
@@ -2026,8 +2042,8 @@
<entry>y<subscript>1</subscript></entry>
<entry>y<subscript>0</subscript></entry>
</row>
<row id="V4L2-MBUS-FMT-YUYV10-2X10">
<entry>V4L2_MBUS_FMT_YUYV10_2X10</entry>
<row id="MEDIA-BUS-FMT-YUYV10-2X10">
<entry>MEDIA_BUS_FMT_YUYV10_2X10</entry>
<entry>0x200b</entry>
<entry></entry>
&dash-ent-22;
@@ -2090,8 +2106,8 @@
<entry>v<subscript>1</subscript></entry>
<entry>v<subscript>0</subscript></entry>
</row>
<row id="V4L2-MBUS-FMT-YVYU10-2X10">
<entry>V4L2_MBUS_FMT_YVYU10_2X10</entry>
<row id="MEDIA-BUS-FMT-YVYU10-2X10">
<entry>MEDIA_BUS_FMT_YVYU10_2X10</entry>
<entry>0x200c</entry>
<entry></entry>
&dash-ent-22;
@@ -2154,8 +2170,8 @@
<entry>u<subscript>1</subscript></entry>
<entry>u<subscript>0</subscript></entry>
</row>
<row id="V4L2-MBUS-FMT-Y12-1X12">
<entry>V4L2_MBUS_FMT_Y12_1X12</entry>
<row id="MEDIA-BUS-FMT-Y12-1X12">
<entry>MEDIA_BUS_FMT_Y12_1X12</entry>
<entry>0x2013</entry>
<entry></entry>
&dash-ent-20;
@@ -2172,8 +2188,8 @@
<entry>y<subscript>1</subscript></entry>
<entry>y<subscript>0</subscript></entry>
</row>
<row id="V4L2-MBUS-FMT-UYVY8-1X16">
<entry>V4L2_MBUS_FMT_UYVY8_1X16</entry>
<row id="MEDIA-BUS-FMT-UYVY8-1X16">
<entry>MEDIA_BUS_FMT_UYVY8_1X16</entry>
<entry>0x200f</entry>
<entry></entry>
&dash-ent-16;
@@ -2216,8 +2232,8 @@
<entry>y<subscript>1</subscript></entry>
<entry>y<subscript>0</subscript></entry>
</row>
<row id="V4L2-MBUS-FMT-VYUY8-1X16">
<entry>V4L2_MBUS_FMT_VYUY8_1X16</entry>
<row id="MEDIA-BUS-FMT-VYUY8-1X16">
<entry>MEDIA_BUS_FMT_VYUY8_1X16</entry>
<entry>0x2010</entry>
<entry></entry>
&dash-ent-16;
@@ -2260,8 +2276,8 @@
<entry>y<subscript>1</subscript></entry>
<entry>y<subscript>0</subscript></entry>
</row>
<row id="V4L2-MBUS-FMT-YUYV8-1X16">
<entry>V4L2_MBUS_FMT_YUYV8_1X16</entry>
<row id="MEDIA-BUS-FMT-YUYV8-1X16">
<entry>MEDIA_BUS_FMT_YUYV8_1X16</entry>
<entry>0x2011</entry>
<entry></entry>
&dash-ent-16;
@@ -2304,8 +2320,8 @@
<entry>v<subscript>1</subscript></entry>
<entry>v<subscript>0</subscript></entry>
</row>
<row id="V4L2-MBUS-FMT-YVYU8-1X16">
<entry>V4L2_MBUS_FMT_YVYU8_1X16</entry>
<row id="MEDIA-BUS-FMT-YVYU8-1X16">
<entry>MEDIA_BUS_FMT_YVYU8_1X16</entry>
<entry>0x2012</entry>
<entry></entry>
&dash-ent-16;
@@ -2348,8 +2364,8 @@
<entry>u<subscript>1</subscript></entry>
<entry>u<subscript>0</subscript></entry>
</row>
<row id="V4L2-MBUS-FMT-YDYUYDYV8-1X16">
<entry>V4L2_MBUS_FMT_YDYUYDYV8_1X16</entry>
<row id="MEDIA-BUS-FMT-YDYUYDYV8-1X16">
<entry>MEDIA_BUS_FMT_YDYUYDYV8_1X16</entry>
<entry>0x2014</entry>
<entry></entry>
&dash-ent-16;
@@ -2436,8 +2452,8 @@
<entry>v<subscript>1</subscript></entry>
<entry>v<subscript>0</subscript></entry>
</row>
<row id="V4L2-MBUS-FMT-UYVY10-1X20">
<entry>V4L2_MBUS_FMT_UYVY10_1X20</entry>
<row id="MEDIA-BUS-FMT-UYVY10-1X20">
<entry>MEDIA_BUS_FMT_UYVY10_1X20</entry>
<entry>0x201a</entry>
<entry></entry>
&dash-ent-12;
@@ -2488,8 +2504,8 @@
<entry>y<subscript>1</subscript></entry>
<entry>y<subscript>0</subscript></entry>
</row>
<row id="V4L2-MBUS-FMT-VYUY10-1X20">
<entry>V4L2_MBUS_FMT_VYUY10_1X20</entry>
<row id="MEDIA-BUS-FMT-VYUY10-1X20">
<entry>MEDIA_BUS_FMT_VYUY10_1X20</entry>
<entry>0x201b</entry>
<entry></entry>
&dash-ent-12;
@@ -2540,8 +2556,8 @@
<entry>y<subscript>1</subscript></entry>
<entry>y<subscript>0</subscript></entry>
</row>
<row id="V4L2-MBUS-FMT-YUYV10-1X20">
<entry>V4L2_MBUS_FMT_YUYV10_1X20</entry>
<row id="MEDIA-BUS-FMT-YUYV10-1X20">
<entry>MEDIA_BUS_FMT_YUYV10_1X20</entry>
<entry>0x200d</entry>
<entry></entry>
&dash-ent-12;
@@ -2592,8 +2608,8 @@
<entry>v<subscript>1</subscript></entry>
<entry>v<subscript>0</subscript></entry>
</row>
<row id="V4L2-MBUS-FMT-YVYU10-1X20">
<entry>V4L2_MBUS_FMT_YVYU10_1X20</entry>
<row id="MEDIA-BUS-FMT-YVYU10-1X20">
<entry>MEDIA_BUS_FMT_YVYU10_1X20</entry>
<entry>0x200e</entry>
<entry></entry>
&dash-ent-12;
@@ -2644,8 +2660,8 @@
<entry>u<subscript>1</subscript></entry>
<entry>u<subscript>0</subscript></entry>
</row>
<row id="V4L2-MBUS-FMT-YUV10-1X30">
<entry>V4L2_MBUS_FMT_YUV10_1X30</entry>
<row id="MEDIA-BUS-FMT-YUV10-1X30">
<entry>MEDIA_BUS_FMT_YUV10_1X30</entry>
<entry>0x2016</entry>
<entry></entry>
<entry>-</entry>
@@ -2681,8 +2697,8 @@
<entry>v<subscript>1</subscript></entry>
<entry>v<subscript>0</subscript></entry>
</row>
<row id="V4L2-MBUS-FMT-AYUV8-1X32">
<entry>V4L2_MBUS_FMT_AYUV8_1X32</entry>
<row id="MEDIA-BUS-FMT-AYUV8-1X32">
<entry>MEDIA_BUS_FMT_AYUV8_1X32</entry>
<entry>0x2017</entry>
<entry></entry>
<entry>a<subscript>7</subscript></entry>
@@ -2718,8 +2734,8 @@
<entry>v<subscript>1</subscript></entry>
<entry>v<subscript>0</subscript></entry>
</row>
<row id="V4L2-MBUS-FMT-UYVY12-2X12">
<entry>V4L2_MBUS_FMT_UYVY12_2X12</entry>
<row id="MEDIA-BUS-FMT-UYVY12-2X12">
<entry>MEDIA_BUS_FMT_UYVY12_2X12</entry>
<entry>0x201c</entry>
<entry></entry>
&dash-ent-20;
@@ -2790,8 +2806,8 @@
<entry>y<subscript>1</subscript></entry>
<entry>y<subscript>0</subscript></entry>
</row>
<row id="V4L2-MBUS-FMT-VYUY12-2X12">
<entry>V4L2_MBUS_FMT_VYUY12_2X12</entry>
<row id="MEDIA-BUS-FMT-VYUY12-2X12">
<entry>MEDIA_BUS_FMT_VYUY12_2X12</entry>
<entry>0x201d</entry>
<entry></entry>
&dash-ent-20;
@@ -2862,8 +2878,8 @@
<entry>y<subscript>1</subscript></entry>
<entry>y<subscript>0</subscript></entry>
</row>
<row id="V4L2-MBUS-FMT-YUYV12-2X12">
<entry>V4L2_MBUS_FMT_YUYV12_2X12</entry>
<row id="MEDIA-BUS-FMT-YUYV12-2X12">
<entry>MEDIA_BUS_FMT_YUYV12_2X12</entry>
<entry>0x201e</entry>
<entry></entry>
&dash-ent-20;
@@ -2934,8 +2950,8 @@
<entry>v<subscript>1</subscript></entry>
<entry>v<subscript>0</subscript></entry>
</row>
<row id="V4L2-MBUS-FMT-YVYU12-2X12">
<entry>V4L2_MBUS_FMT_YVYU12_2X12</entry>
<row id="MEDIA-BUS-FMT-YVYU12-2X12">
<entry>MEDIA_BUS_FMT_YVYU12_2X12</entry>
<entry>0x201f</entry>
<entry></entry>
&dash-ent-20;
@@ -3006,8 +3022,8 @@
<entry>u<subscript>1</subscript></entry>
<entry>u<subscript>0</subscript></entry>
</row>
<row id="V4L2-MBUS-FMT-UYVY12-1X24">
<entry>V4L2_MBUS_FMT_UYVY12_1X24</entry>
<row id="MEDIA-BUS-FMT-UYVY12-1X24">
<entry>MEDIA_BUS_FMT_UYVY12_1X24</entry>
<entry>0x2020</entry>
<entry></entry>
&dash-ent-8;
@@ -3066,8 +3082,8 @@
<entry>y<subscript>1</subscript></entry>
<entry>y<subscript>0</subscript></entry>
</row>
<row id="V4L2-MBUS-FMT-VYUY12-1X24">
<entry>V4L2_MBUS_FMT_VYUY12_1X24</entry>
<row id="MEDIA-BUS-FMT-VYUY12-1X24">
<entry>MEDIA_BUS_FMT_VYUY12_1X24</entry>
<entry>0x2021</entry>
<entry></entry>
&dash-ent-8;
@@ -3126,8 +3142,8 @@
<entry>y<subscript>1</subscript></entry>
<entry>y<subscript>0</subscript></entry>
</row>
<row id="V4L2-MBUS-FMT-YUYV12-1X24">
<entry>V4L2_MBUS_FMT_YUYV12_1X24</entry>
<row id="MEDIA-BUS-FMT-YUYV12-1X24">
<entry>MEDIA_BUS_FMT_YUYV12_1X24</entry>
<entry>0x2022</entry>
<entry></entry>
&dash-ent-8;
@@ -3186,8 +3202,8 @@
<entry>v<subscript>1</subscript></entry>
<entry>v<subscript>0</subscript></entry>
</row>
<row id="V4L2-MBUS-FMT-YVYU12-1X24">
<entry>V4L2_MBUS_FMT_YVYU12_1X24</entry>
<row id="MEDIA-BUS-FMT-YVYU12-1X24">
<entry>MEDIA_BUS_FMT_YVYU12_1X24</entry>
<entry>0x2023</entry>
<entry></entry>
&dash-ent-8;
@@ -3366,8 +3382,8 @@
</row>
</thead>
<tbody valign="top">
<row id="V4L2-MBUS-FMT-AHSV8888-1X32">
<entry>V4L2_MBUS_FMT_AHSV8888_1X32</entry>
<row id="MEDIA-BUS-FMT-AHSV8888-1X32">
<entry>MEDIA_BUS_FMT_AHSV8888_1X32</entry>
<entry>0x6001</entry>
<entry></entry>
<entry>a<subscript>7</subscript></entry>
@@ -3422,7 +3438,7 @@
</para>
<para>For instance, for a JPEG baseline process and an 8-bit bus width
the format will be named <constant>V4L2_MBUS_FMT_JPEG_1X8</constant>.
the format will be named <constant>MEDIA_BUS_FMT_JPEG_1X8</constant>.
</para>
<para>The following table lists existing JPEG compressed formats.</para>
@@ -3441,8 +3457,8 @@
</row>
</thead>
<tbody valign="top">
<row id="V4L2-MBUS-FMT-JPEG-1X8">
<entry>V4L2_MBUS_FMT_JPEG_1X8</entry>
<row id="MEDIA-BUS-FMT-JPEG-1X8">
<entry>MEDIA_BUS_FMT_JPEG_1X8</entry>
<entry>0x4001</entry>
<entry>Besides of its usage for the parallel bus this format is
recommended for transmission of JPEG data over MIPI CSI bus
@@ -3484,8 +3500,8 @@ interface and may change in the future.</para>
</row>
</thead>
<tbody valign="top">
<row id="V4L2-MBUS-FMT-S5C-UYVY-JPEG-1X8">
<entry>V4L2_MBUS_FMT_S5C_UYVY_JPEG_1X8</entry>
<row id="MEDIA-BUS-FMT-S5C-UYVY-JPEG-1X8">
<entry>MEDIA_BUS_FMT_S5C_UYVY_JPEG_1X8</entry>
<entry>0x5001</entry>
<entry>
Interleaved raw UYVY and JPEG image format with embedded

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

@@ -151,6 +151,15 @@ 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.19</revnumber>
<date>2014-12-05</date>
<authorinitials>hv</authorinitials>
<revremark>Rewrote Colorspace chapter, added new &v4l2-ycbcr-encoding; and &v4l2-quantization; fields
to &v4l2-pix-format;, &v4l2-pix-format-mplane; and &v4l2-mbus-framefmt;.
</revremark>
</revision>
<revision>
<revnumber>3.17</revnumber>
<date>2014-08-04</date>
@@ -539,7 +548,7 @@ and discussions on the V4L mailing list.</revremark>
</partinfo>
<title>Video for Linux Two API Specification</title>
<subtitle>Revision 3.17</subtitle>
<subtitle>Revision 3.19</subtitle>
<chapter id="common">
&sub-common;

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

@@ -287,6 +287,14 @@ input/output interface to linux-media@vger.kernel.org on 19 Oct 2009.
<entry>0x00000004</entry>
<entry>This input supports setting the TV standard by using VIDIOC_S_STD.</entry>
</row>
<row>
<entry><constant>V4L2_IN_CAP_NATIVE_SIZE</constant></entry>
<entry>0x00000008</entry>
<entry>This input supports setting the native size using
the <constant>V4L2_SEL_TGT_NATIVE_SIZE</constant>
selection target, see <xref
linkend="v4l2-selections-common"/>.</entry>
</row>
</tbody>
</tgroup>
</table>

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

@@ -172,6 +172,14 @@ input/output interface to linux-media@vger.kernel.org on 19 Oct 2009.
<entry>0x00000004</entry>
<entry>This output supports setting the TV standard by using VIDIOC_S_STD.</entry>
</row>
<row>
<entry><constant>V4L2_OUT_CAP_NATIVE_SIZE</constant></entry>
<entry>0x00000008</entry>
<entry>This output supports setting the native size using
the <constant>V4L2_SEL_TGT_NATIVE_SIZE</constant>
selection target, see <xref
linkend="v4l2-selections-common"/>.</entry>
</row>
</tbody>
</tgroup>
</table>

2
Documentation/DocBook/uio-howto.tmpl
View File

@@ -540,7 +540,7 @@ appears in sysfs.
</para></listitem>
<listitem><para>
<varname>unsigned long size</varname>: Fill in the size of the
<varname>resource_size_t size</varname>: Fill in the size of the
memory block that <varname>addr</varname> points to. If <varname>size</varname>
is zero, the mapping is considered unused. Note that you
<emphasis>must</emphasis> initialize <varname>size</varname> with zero for

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

@@ -3657,6 +3657,29 @@ struct _snd_pcm_runtime {
</informalexample>
</para>
<para>
The above callback can be simplified with a helper function,
<function>snd_ctl_enum_info</function>. The final code
looks like below.
(You can pass ARRAY_SIZE(texts) instead of 4 in the third
argument; it's a matter of taste.)
<informalexample>
<programlisting>
<![CDATA[
static int snd_myctl_enum_info(struct snd_kcontrol *kcontrol,
struct snd_ctl_elem_info *uinfo)
{
static char *texts[4] = {
"First", "Second", "Third", "Fourth"
};
return snd_ctl_enum_info(uinfo, 1, 4, texts);
}
]]>
</programlisting>
</informalexample>
</para>
<para>
Some common info callbacks are available for your convenience:
<function>snd_ctl_boolean_mono_info()</function> and

74
Documentation/IPMI.txt
View File

@@ -42,7 +42,13 @@ The driver interface depends on your hardware. If your system
properly provides the SMBIOS info for IPMI, the driver will detect it
and just work. If you have a board with a standard interface (These
will generally be either "KCS", "SMIC", or "BT", consult your hardware
manual), choose the 'IPMI SI handler' option.
manual), choose the 'IPMI SI handler' option. A driver also exists
for direct I2C access to the IPMI management controller. Some boards
support this, but it is unknown if it will work on every board. For
this, choose 'IPMI SMBus handler', but be ready to try to do some
figuring to see if it will work on your system if the SMBIOS/APCI
information is wrong or not present. It is fairly safe to have both
these enabled and let the drivers auto-detect what is present.
You should generally enable ACPI on your system, as systems with IPMI
can have ACPI tables describing them.
@@ -52,7 +58,8 @@ their job correctly, the IPMI controller should be automatically
detected (via ACPI or SMBIOS tables) and should just work. Sadly,
many boards do not have this information. The driver attempts
standard defaults, but they may not work. If you fall into this
situation, you need to read the section below named 'The SI Driver'.
situation, you need to read the section below named 'The SI Driver' or
"The SMBus Driver" on how to hand-configure your system.
IPMI defines a standard watchdog timer. You can enable this with the
'IPMI Watchdog Timer' config option. If you compile the driver into
@@ -97,7 +104,12 @@ driver, each open file for this device ties in to the message handler
as an IPMI user.
ipmi_si - A driver for various system interfaces. This supports KCS,
SMIC, and BT interfaces.
SMIC, and BT interfaces. Unless you have an SMBus interface or your
own custom interface, you probably need to use this.
ipmi_ssif - A driver for accessing BMCs on the SMBus. It uses the
I2C kernel driver's SMBus interfaces to send and receive IPMI messages
over the SMBus.
ipmi_watchdog - IPMI requires systems to have a very capable watchdog
timer. This driver implements the standard Linux watchdog timer
@@ -476,6 +488,62 @@ for specifying an interface. Note that when removing an interface,
only the first three parameters (si type, address type, and address)
are used for the comparison. Any options are ignored for removing.
The SMBus Driver (SSIF)
-----------------------
The SMBus driver allows up to 4 SMBus devices to be configured in the
system. By default, the driver will only register with something it
finds in DMI or ACPI tables. You can change this
at module load time (for a module) with:
modprobe ipmi_ssif.o
addr=<i2caddr1>[,<i2caddr2>[,...]]
adapter=<adapter1>[,<adapter2>[...]]
dbg=<flags1>,<flags2>...
slave_addrs=<addr1>,<addr2>,...
[dbg_probe=1]
The addresses are normal I2C addresses. The adapter is the string
name of the adapter, as shown in /sys/class/i2c-adapter/i2c-<n>/name.
It is *NOT* i2c-<n> itself.
The debug flags are bit flags for each BMC found, they are:
IPMI messages: 1, driver state: 2, timing: 4, I2C probe: 8
Setting dbg_probe to 1 will enable debugging of the probing and
detection process for BMCs on the SMBusses.
The slave_addrs specifies the IPMI address of the local BMC. This is
usually 0x20 and the driver defaults to that, but in case it's not, it
can be specified when the driver starts up.
Discovering the IPMI compliant BMC on the SMBus can cause devices on
the I2C bus to fail. The SMBus driver writes a "Get Device ID" IPMI
message as a block write to the I2C bus and waits for a response.
This action can be detrimental to some I2C devices. It is highly
recommended that the known I2C address be given to the SMBus driver in
the smb_addr parameter unless you have DMI or ACPI data to tell the
driver what to use.
When compiled into the kernel, the addresses can be specified on the
kernel command line as:
ipmb_ssif.addr=<i2caddr1>[,<i2caddr2>[...]]
ipmi_ssif.adapter=<adapter1>[,<adapter2>[...]]
ipmi_ssif.dbg=<flags1>[,<flags2>[...]]
ipmi_ssif.dbg_probe=1
ipmi_ssif.slave_addrs=<addr1>[,<addr2>[...]]
These are the same options as on the module command line.
The I2C driver does not support non-blocking access or polling, so
this driver cannod to IPMI panic events, extend the watchdog at panic
time, or other panic-related IPMI functions without special kernel
patches and driver modifications. You can get those at the openipmi
web page.
The driver supports a hot add and remove of interfaces through the I2C
sysfs interface.
Other Pieces
------------

71
Documentation/IRQ-domain.txt
View File

@@ -151,3 +151,74 @@ used and no descriptor gets allocated it is very important to make sure
that the driver using the simple domain call irq_create_mapping()
before any irq_find_mapping() since the latter will actually work
for the static IRQ assignment case.
==== Hierarchy IRQ domain ====
On some architectures, there may be multiple interrupt controllers
involved in delivering an interrupt from the device to the target CPU.
Let's look at a typical interrupt delivering path on x86 platforms:
Device --> IOAPIC -> Interrupt remapping Controller -> Local APIC -> CPU
There are three interrupt controllers involved:
1) IOAPIC controller
2) Interrupt remapping controller
3) Local APIC controller
To support such a hardware topology and make software architecture match
hardware architecture, an irq_domain data structure is built for each
interrupt controller and those irq_domains are organized into hierarchy.
When building irq_domain hierarchy, the irq_domain near to the device is
child and the irq_domain near to CPU is parent. So a hierarchy structure
as below will be built for the example above.
CPU Vector irq_domain (root irq_domain to manage CPU vectors)
^
|
Interrupt Remapping irq_domain (manage irq_remapping entries)
^
|
IOAPIC irq_domain (manage IOAPIC delivery entries/pins)
There are four major interfaces to use hierarchy irq_domain:
1) irq_domain_alloc_irqs(): allocate IRQ descriptors and interrupt
controller related resources to deliver these interrupts.
2) irq_domain_free_irqs(): free IRQ descriptors and interrupt controller
related resources associated with these interrupts.
3) irq_domain_activate_irq(): activate interrupt controller hardware to
deliver the interrupt.
3) irq_domain_deactivate_irq(): deactivate interrupt controller hardware
to stop delivering the interrupt.
Following changes are needed to support hierarchy irq_domain.
1) a new field 'parent' is added to struct irq_domain; it's used to
maintain irq_domain hierarchy information.
2) a new field 'parent_data' is added to struct irq_data; it's used to
build hierarchy irq_data to match hierarchy irq_domains. The irq_data
is used to store irq_domain pointer and hardware irq number.
3) new callbacks are added to struct irq_domain_ops to support hierarchy
irq_domain operations.
With support of hierarchy irq_domain and hierarchy irq_data ready, an
irq_domain structure is built for each interrupt controller, and an
irq_data structure is allocated for each irq_domain associated with an
IRQ. Now we could go one step further to support stacked(hierarchy)
irq_chip. That is, an irq_chip is associated with each irq_data along
the hierarchy. A child irq_chip may implement a required action by
itself or by cooperating with its parent irq_chip.
With stacked irq_chip, interrupt controller driver only needs to deal
with the hardware managed by itself and may ask for services from its
parent irq_chip when needed. So we could achieve a much cleaner
software architecture.
For an interrupt controller driver to support hierarchy irq_domain, it
needs to:
1) Implement irq_domain_ops.alloc and irq_domain_ops.free
2) Optionally implement irq_domain_ops.activate and
irq_domain_ops.deactivate.
3) Optionally implement an irq_chip to manage the interrupt controller
hardware.
4) No need to implement irq_domain_ops.map and irq_domain_ops.unmap,
they are unused with hierarchy irq_domain.
Hierarchy irq_domain may also be used to support other architectures,
such as ARM, ARM64 etc.

4
Documentation/RCU/rcu.txt
View File

@@ -36,7 +36,7 @@ o How can the updater tell when a grace period has completed
executed in user mode, or executed in the idle loop, we can
safely free up that item.
Preemptible variants of RCU (CONFIG_TREE_PREEMPT_RCU) get the
Preemptible variants of RCU (CONFIG_PREEMPT_RCU) get the
same effect, but require that the readers manipulate CPU-local
counters. These counters allow limited types of blocking within
RCU read-side critical sections. SRCU also uses CPU-local
@@ -81,7 +81,7 @@ o I hear that RCU is patented? What is with that?
o I hear that RCU needs work in order to support realtime kernels?
This work is largely completed. Realtime-friendly RCU can be
enabled via the CONFIG_TREE_PREEMPT_RCU kernel configuration
enabled via the CONFIG_PREEMPT_RCU kernel configuration
parameter. However, work is in progress for enabling priority
boosting of preempted RCU read-side critical sections. This is
needed if you have CPU-bound realtime threads.

14
Documentation/RCU/stallwarn.txt
View File

@@ -26,12 +26,6 @@ CONFIG_RCU_CPU_STALL_TIMEOUT
Stall-warning messages may be enabled and disabled completely via
/sys/module/rcupdate/parameters/rcu_cpu_stall_suppress.
CONFIG_RCU_CPU_STALL_VERBOSE
This kernel configuration parameter causes the stall warning to
also dump the stacks of any tasks that are blocking the current
RCU-preempt grace period.
CONFIG_RCU_CPU_STALL_INFO
This kernel configuration parameter causes the stall warning to
@@ -77,7 +71,7 @@ This message indicates that CPU 5 detected that it was causing a stall,
and that the stall was affecting RCU-sched. This message will normally be
followed by a stack dump of the offending CPU. On TREE_RCU kernel builds,
RCU and RCU-sched are implemented by the same underlying mechanism,
while on TREE_PREEMPT_RCU kernel builds, RCU is instead implemented
while on PREEMPT_RCU kernel builds, RCU is instead implemented
by rcu_preempt_state.
On the other hand, if the offending CPU fails to print out a stall-warning
@@ -89,7 +83,7 @@ INFO: rcu_bh_state detected stalls on CPUs/tasks: { 3 5 } (detected by 2, 2502 j
This message indicates that CPU 2 detected that CPUs 3 and 5 were both
causing stalls, and that the stall was affecting RCU-bh. This message
will normally be followed by stack dumps for each CPU. Please note that
TREE_PREEMPT_RCU builds can be stalled by tasks as well as by CPUs,
PREEMPT_RCU builds can be stalled by tasks as well as by CPUs,
and that the tasks will be indicated by PID, for example, "P3421".
It is even possible for a rcu_preempt_state stall to be caused by both
CPUs -and- tasks, in which case the offending CPUs and tasks will all
@@ -205,10 +199,10 @@ o A CPU-bound real-time task in a CONFIG_PREEMPT kernel, which might
o A CPU-bound real-time task in a CONFIG_PREEMPT_RT kernel that
is running at a higher priority than the RCU softirq threads.
This will prevent RCU callbacks from ever being invoked,
and in a CONFIG_TREE_PREEMPT_RCU kernel will further prevent
and in a CONFIG_PREEMPT_RCU kernel will further prevent
RCU grace periods from ever completing. Either way, the
system will eventually run out of memory and hang. In the
CONFIG_TREE_PREEMPT_RCU case, you might see stall-warning
CONFIG_PREEMPT_RCU case, you might see stall-warning
messages.
o A hardware or software issue shuts off the scheduler-clock

4
Documentation/RCU/trace.txt
View File

@@ -8,7 +8,7 @@ The following sections describe the debugfs files and formats, first
for rcutree and next for rcutiny.
CONFIG_TREE_RCU and CONFIG_TREE_PREEMPT_RCU debugfs Files and Formats
CONFIG_TREE_RCU and CONFIG_PREEMPT_RCU debugfs Files and Formats
These implementations of RCU provide several debugfs directories under the
top-level directory "rcu":
@@ -18,7 +18,7 @@ rcu/rcu_preempt
rcu/rcu_sched
Each directory contains files for the corresponding flavor of RCU.
Note that rcu/rcu_preempt is only present for CONFIG_TREE_PREEMPT_RCU.
Note that rcu/rcu_preempt is only present for CONFIG_PREEMPT_RCU.
For CONFIG_TREE_RCU, the RCU flavor maps onto the RCU-sched flavor,
so that activity for both appears in rcu/rcu_sched.

2
Documentation/RCU/whatisRCU.txt
View File

@@ -137,7 +137,7 @@ rcu_read_lock()
Used by a reader to inform the reclaimer that the reader is
entering an RCU read-side critical section. It is illegal
to block while in an RCU read-side critical section, though
kernels built with CONFIG_TREE_PREEMPT_RCU can preempt RCU
kernels built with CONFIG_PREEMPT_RCU can preempt RCU
read-side critical sections. Any RCU-protected data structure
accessed during an RCU read-side critical section is guaranteed to
remain unreclaimed for the full duration of that critical section.

96
Documentation/acpi/gpio-properties.txt Normal file
View File

@@ -0,0 +1,96 @@
_DSD Device Properties Related to GPIO
--------------------------------------
With the release of ACPI 5.1 and the _DSD configuration objecte names
can finally be given to GPIOs (and other things as well) returned by
_CRS. Previously, we were only able to use an integer index to find
the corresponding GPIO, which is pretty error prone (it depends on
the _CRS output ordering, for example).
With _DSD we can now query GPIOs using a name instead of an integer
index, like the ASL example below shows:
// Bluetooth device with reset and shutdown GPIOs
Device (BTH)
{
Name (_HID, ...)
Name (_CRS, ResourceTemplate ()
{
GpioIo (Exclusive, PullUp, 0, 0, IoRestrictionInputOnly,
"\\_SB.GPO0", 0, ResourceConsumer) {15}
GpioIo (Exclusive, PullUp, 0, 0, IoRestrictionInputOnly,
"\\_SB.GPO0", 0, ResourceConsumer) {27, 31}
})
Name (_DSD, Package ()
{
ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
Package ()
{
Package () {"reset-gpio", Package() {^BTH, 1, 1, 0 }},
Package () {"shutdown-gpio", Package() {^BTH, 0, 0, 0 }},
}
})
}
The format of the supported GPIO property is:
Package () { "name", Package () { ref, index, pin, active_low }}
ref - The device that has _CRS containing GpioIo()/GpioInt() resources,
typically this is the device itself (BTH in our case).
index - Index of the GpioIo()/GpioInt() resource in _CRS starting from zero.
pin - Pin in the GpioIo()/GpioInt() resource. Typically this is zero.
active_low - If 1 the GPIO is marked as active_low.
Since ACPI GpioIo() resource does not have a field saying whether it is
active low or high, the "active_low" argument can be used here. Setting
it to 1 marks the GPIO as active low.
In our Bluetooth example the "reset-gpio" refers to the second GpioIo()
resource, second pin in that resource with the GPIO number of 31.
ACPI GPIO Mappings Provided by Drivers
--------------------------------------
There are systems in which the ACPI tables do not contain _DSD but provide _CRS
with GpioIo()/GpioInt() resources and device drivers still need to work with
them.
In those cases ACPI device identification objects, _HID, _CID, _CLS, _SUB, _HRV,
available to the driver can be used to identify the device and that is supposed
to be sufficient to determine the meaning and purpose of all of the GPIO lines
listed by the GpioIo()/GpioInt() resources returned by _CRS. In other words,
the driver is supposed to know what to use the GpioIo()/GpioInt() resources for
once it has identified the device. Having done that, it can simply assign names
to the GPIO lines it is going to use and provide the GPIO subsystem with a
mapping between those names and the ACPI GPIO resources corresponding to them.
To do that, the driver needs to define a mapping table as a NULL-terminated
array of struct acpi_gpio_mapping objects that each contain a name, a pointer
to an array of line data (struct acpi_gpio_params) objects and the size of that
array. Each struct acpi_gpio_params object consists of three fields,
crs_entry_index, line_index, active_low, representing the index of the target
GpioIo()/GpioInt() resource in _CRS starting from zero, the index of the target
line in that resource starting from zero, and the active-low flag for that line,
respectively, in analogy with the _DSD GPIO property format specified above.
For the example Bluetooth device discussed previously the data structures in
question would look like this:
static const struct acpi_gpio_params reset_gpio = { 1, 1, false };
static const struct acpi_gpio_params shutdown_gpio = { 0, 0, false };
static const struct acpi_gpio_mapping bluetooth_acpi_gpios[] = {
{ "reset-gpio", &reset_gpio, 1 },
{ "shutdown-gpio", &shutdown_gpio, 1 },
{ },
};
Next, the mapping table needs to be passed as the second argument to
acpi_dev_add_driver_gpios() that will register it with the ACPI device object
pointed to by its first argument. That should be done in the driver's .probe()
routine. On removal, the driver should unregister its GPIO mapping table by
calling acpi_dev_remove_driver_gpios() on the ACPI device object where that
table was previously registered.

28
Documentation/arm/firmware.txt
View File

@@ -7,32 +7,14 @@ 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
Firmware operations can be specified by filling in a struct firmware_ops
with appropriate callbacks and then registering it with register_firmware_ops()
function.
void register_firmware_ops(const struct firmware_ops *ops)
the ops pointer must be non-NULL.
The ops pointer must be non-NULL. More information about struct firmware_ops
and its members can be found in arch/arm/include/asm/firmware.h header.
There is a default, empty set of operations provided, so there is no need to
set anything if platform does not require firmware operations.

2
Documentation/arm/memory.txt
View File

@@ -41,7 +41,7 @@ fffe8000 fffeffff DTCM mapping area for platforms with
fffe0000 fffe7fff ITCM mapping area for platforms with
ITCM mounted inside the CPU.
ffc00000 ffdfffff Fixmap mapping region. Addresses provided
ffc00000 ffefffff Fixmap mapping region. Addresses provided
by fix_to_virt() will be located here.
fee00000 feffffff Mapping of PCI I/O space. This is a static

16
Documentation/arm/sunxi/README
View File

@@ -37,16 +37,26 @@ SunXi family
http://dl.linux-sunxi.org/A20/A20%20User%20Manual%202013-03-22.pdf
- Allwinner A23
+ Not Supported
+ Datasheet
http://dl.linux-sunxi.org/A23/A23%20Datasheet%20V1.0%2020130830.pdf
+ User Manual
http://dl.linux-sunxi.org/A23/A23%20User%20Manual%20V1.0%2020130830.pdf
* Quad ARM Cortex-A7 based SoCs
- Allwinner A31 (sun6i)
+ Datasheet
http://dl.linux-sunxi.org/A31/A31%20Datasheet%20-%20v1.00%20(2012-12-24).pdf
http://dl.linux-sunxi.org/A31/A3x_release_document/A31/IC/A31%20datasheet%20V1.3%2020131106.pdf
+ User Manual
http://dl.linux-sunxi.org/A31/A3x_release_document/A31/IC/A31%20user%20manual%20V1.1%2020130630.pdf
- Allwinner A31s (sun6i)
+ Not Supported
+ Datasheet
http://dl.linux-sunxi.org/A31/A3x_release_document/A31s/IC/A31s%20datasheet%20V1.3%2020131106.pdf
+ User Manual
http://dl.linux-sunxi.org/A31/A3x_release_document/A31s/IC/A31s%20User%20Manual%20%20V1.0%2020130322.pdf
* Quad ARM Cortex-A15, Quad ARM Cortex-A7 based SoCs
- Allwinner A80
+ Not Supported
+ Datasheet
http://dl.linux-sunxi.org/A80/A80_Datasheet_Revision_1.0_0404.pdf

45
Documentation/arm64/legacy_instructions.txt Normal file
View File

@@ -0,0 +1,45 @@
The arm64 port of the Linux kernel provides infrastructure to support
emulation of instructions which have been deprecated, or obsoleted in
the architecture. The infrastructure code uses undefined instruction
hooks to support emulation. Where available it also allows turning on
the instruction execution in hardware.
The emulation mode can be controlled by writing to sysctl nodes
(/proc/sys/abi). The following explains the different execution
behaviours and the corresponding values of the sysctl nodes -
* Undef
Value: 0
Generates undefined instruction abort. Default for instructions that
have been obsoleted in the architecture, e.g., SWP
* Emulate
Value: 1
Uses software emulation. To aid migration of software, in this mode
usage of emulated instruction is traced as well as rate limited
warnings are issued. This is the default for deprecated
instructions, .e.g., CP15 barriers
* Hardware Execution
Value: 2
Although marked as deprecated, some implementations may support the
enabling/disabling of hardware support for the execution of these
instructions. Using hardware execution generally provides better
performance, but at the loss of ability to gather runtime statistics
about the use of the deprecated instructions.
The default mode depends on the status of the instruction in the
architecture. Deprecated instructions should default to emulation
while obsolete instructions must be undefined by default.
Supported legacy instructions
-----------------------------
* SWP{B}
Node: /proc/sys/abi/swp
Status: Obsolete
Default: Undef (0)
* CP15 Barriers
Node: /proc/sys/abi/cp15_barrier
Status: Deprecated
Default: Emulate (1)

12
Documentation/atomic_ops.txt
View File

@@ -7,12 +7,13 @@
maintainers on how to implement atomic counter, bitops, and spinlock
interfaces properly.
The atomic_t type should be defined as a signed integer.
Also, it should be made opaque such that any kind of cast to a normal
C integer type will fail. Something like the following should
suffice:
The atomic_t type should be defined as a signed integer and
the atomic_long_t type as a signed long integer. Also, they should
be made opaque such that any kind of cast to a normal C integer type
will fail. Something like the following should suffice:
typedef struct { int counter; } atomic_t;
typedef struct { long counter; } atomic_long_t;
Historically, counter has been declared volatile. This is now discouraged.
See Documentation/volatile-considered-harmful.txt for the complete rationale.
@@ -37,6 +38,9 @@ initializer is used before runtime. If the initializer is used at runtime, a
proper implicit or explicit read memory barrier is needed before reading the
value with atomic_read from another thread.
As with all of the atomic_ interfaces, replace the leading "atomic_"
with "atomic_long_" to operate on atomic_long_t.
The second interface can be used at runtime, as in:
struct foo { atomic_t counter; };

10
Documentation/block/biodoc.txt
View File

@@ -827,10 +827,6 @@ but in the event of any barrier requests in the tag queue we need to ensure
that requests are restarted in the order they were queue. This may happen
if the driver needs to use blk_queue_invalidate_tags().
Tagging also defines a new request flag, REQ_QUEUED. This is set whenever
a request is currently tagged. You should not use this flag directly,
blk_rq_tagged(rq) is the portable way to do so.
3.3 I/O Submission
The routine submit_bio() is used to submit a single io. Higher level i/o
@@ -946,7 +942,11 @@ elevator_allow_merge_fn called whenever the block layer determines
request safely. The io scheduler may still
want to stop a merge at this point if it
results in some sort of conflict internally,
this hook allows it to do that.
this hook allows it to do that. Note however
that two *requests* can still be merged at later
time. Currently the io scheduler has no way to
prevent that. It can only learn about the fact
from elevator_merge_req_fn callback.
elevator_dispatch_fn* fills the dispatch queue with ready requests.
I/O schedulers are free to postpone requests by

4
Documentation/cgroups/cgroups.txt
View File

@@ -312,10 +312,10 @@ the "cpuset" cgroup subsystem, the steps are something like:
2) mkdir /sys/fs/cgroup/cpuset
3) mount -t cgroup -ocpuset cpuset /sys/fs/cgroup/cpuset
4) Create the new cgroup by doing mkdir's and write's (or echo's) in
the /sys/fs/cgroup virtual file system.
the /sys/fs/cgroup/cpuset virtual file system.
5) Start a task that will be the "founding father" of the new job.
6) Attach that task to the new cgroup by writing its PID to the
/sys/fs/cgroup/cpuset/tasks file for that cgroup.
/sys/fs/cgroup/cpuset tasks file for that cgroup.
7) fork, exec or clone the job tasks from this founding father task.
For example, the following sequence of commands will setup a cgroup

6
Documentation/cgroups/cpusets.txt
View File

@@ -445,7 +445,7 @@ across partially overlapping sets of CPUs would risk unstable dynamics
that would be beyond our understanding. So if each of two partially
overlapping cpusets enables the flag 'cpuset.sched_load_balance', then we
form a single sched domain that is a superset of both. We won't move
a task to a CPU outside it cpuset, but the scheduler load balancing
a task to a CPU outside its cpuset, but the scheduler load balancing
code might waste some compute cycles considering that possibility.
This mismatch is why there is not a simple one-to-one relation
@@ -552,8 +552,8 @@ otherwise initial value -1 that indicates the cpuset has no request.
1 : search siblings (hyperthreads in a core).
2 : search cores in a package.
3 : search cpus in a node [= system wide on non-NUMA system]
( 4 : search nodes in a chunk of node [on NUMA system] )
( 5 : search system wide [on NUMA system] )
4 : search nodes in a chunk of node [on NUMA system]
5 : search system wide [on NUMA system]
The system default is architecture dependent. The system default
can be changed using the relax_domain_level= boot parameter.

2
Documentation/cgroups/hugetlb.txt
View File

@@ -29,7 +29,7 @@ Brief summary of control files
hugetlb.<hugepagesize>.limit_in_bytes # set/show limit of "hugepagesize" hugetlb usage
hugetlb.<hugepagesize>.max_usage_in_bytes # show max "hugepagesize" hugetlb usage recorded
hugetlb.<hugepagesize>.usage_in_bytes # show current res_counter usage for "hugepagesize" hugetlb
hugetlb.<hugepagesize>.usage_in_bytes # show current usage for "hugepagesize" hugetlb
hugetlb.<hugepagesize>.failcnt # show the number of allocation failure due to HugeTLB limit
For a system supporting two hugepage size (16M and 16G) the control

34
Documentation/cgroups/memory.txt
View File

@@ -1,5 +1,10 @@
Memory Resource Controller
NOTE: This document is hopelessly outdated and it asks for a complete
rewrite. It still contains a useful information so we are keeping it
here but make sure to check the current code if you need a deeper
understanding.
NOTE: The Memory Resource Controller has generically been referred to as the
memory controller in this document. Do not confuse memory controller
used here with the memory controller that is used in hardware.
@@ -52,9 +57,9 @@ Brief summary of control files.
tasks # attach a task(thread) and show list of threads
cgroup.procs # show list of processes
cgroup.event_control # an interface for event_fd()
memory.usage_in_bytes # show current res_counter usage for memory
memory.usage_in_bytes # show current usage for memory
(See 5.5 for details)
memory.memsw.usage_in_bytes # show current res_counter usage for memory+Swap
memory.memsw.usage_in_bytes # show current usage for memory+Swap
(See 5.5 for details)
memory.limit_in_bytes # set/show limit of memory usage
memory.memsw.limit_in_bytes # set/show limit of memory+Swap usage
@@ -116,16 +121,16 @@ The memory controller is the first controller developed.
2.1. Design
The core of the design is a counter called the res_counter. The res_counter
tracks the current memory usage and limit of the group of processes associated
with the controller. Each cgroup has a memory controller specific data
structure (mem_cgroup) associated with it.
The core of the design is a counter called the page_counter. The
page_counter tracks the current memory usage and limit of the group of
processes associated with the controller. Each cgroup has a memory controller
specific data structure (mem_cgroup) associated with it.
2.2. Accounting
+--------------------+
| mem_cgroup |
| (res_counter) |
| mem_cgroup |
| (page_counter) |
+--------------------+
/ ^ \
/ | \
@@ -321,7 +326,7 @@ per cgroup, instead of globally.
* tcp memory pressure: sockets memory pressure for the tcp protocol.
2.7.3 Common use cases
2.7.2 Common use cases
Because the "kmem" counter is fed to the main user counter, kernel memory can
never be limited completely independently of user memory. Say "U" is the user
@@ -349,20 +354,19 @@ set:
3. User Interface
0. Configuration
3.0. Configuration
a. Enable CONFIG_CGROUPS
b. Enable CONFIG_RESOURCE_COUNTERS
c. Enable CONFIG_MEMCG
d. Enable CONFIG_MEMCG_SWAP (to use swap extension)
b. Enable CONFIG_MEMCG
c. Enable CONFIG_MEMCG_SWAP (to use swap extension)
d. Enable CONFIG_MEMCG_KMEM (to use kmem extension)
1. Prepare the cgroups (see cgroups.txt, Why are cgroups needed?)
3.1. Prepare the cgroups (see cgroups.txt, Why are cgroups needed?)
# mount -t tmpfs none /sys/fs/cgroup
# mkdir /sys/fs/cgroup/memory
# mount -t cgroup none /sys/fs/cgroup/memory -o memory
2. Make the new group and move bash into it
3.2. Make the new group and move bash into it
# mkdir /sys/fs/cgroup/memory/0
# echo $$ > /sys/fs/cgroup/memory/0/tasks

197
Documentation/cgroups/resource_counter.txt
View File

@@ -1,197 +0,0 @@
The Resource Counter
The resource counter, declared at include/linux/res_counter.h,
is supposed to facilitate the resource management by controllers
by providing common stuff for accounting.
This "stuff" includes the res_counter structure and routines
to work with it.
1. Crucial parts of the res_counter structure
a. unsigned long long usage
The usage value shows the amount of a resource that is consumed
by a group at a given time. The units of measurement should be
determined by the controller that uses this counter. E.g. it can
be bytes, items or any other unit the controller operates on.
b. unsigned long long max_usage
The maximal value of the usage over time.
This value is useful when gathering statistical information about
the particular group, as it shows the actual resource requirements
for a particular group, not just some usage snapshot.
c. unsigned long long limit
The maximal allowed amount of resource to consume by the group. In
case the group requests for more resources, so that the usage value
would exceed the limit, the resource allocation is rejected (see
the next section).
d. unsigned long long failcnt
The failcnt stands for "failures counter". This is the number of
resource allocation attempts that failed.
c. spinlock_t lock
Protects changes of the above values.
2. Basic accounting routines
a. void res_counter_init(struct res_counter *rc,
struct res_counter *rc_parent)
Initializes the resource counter. As usual, should be the first
routine called for a new counter.
The struct res_counter *parent can be used to define a hierarchical
child -> parent relationship directly in the res_counter structure,
NULL can be used to define no relationship.
c. int res_counter_charge(struct res_counter *rc, unsigned long val,
struct res_counter **limit_fail_at)
When a resource is about to be allocated it has to be accounted
with the appropriate resource counter (controller should determine
which one to use on its own). This operation is called "charging".
This is not very important which operation - resource allocation
or charging - is performed first, but
* if the allocation is performed first, this may create a
temporary resource over-usage by the time resource counter is
charged;
* if the charging is performed first, then it should be uncharged
on error path (if the one is called).
If the charging fails and a hierarchical dependency exists, the
limit_fail_at parameter is set to the particular res_counter element
where the charging failed.
d. u64 res_counter_uncharge(struct res_counter *rc, unsigned long val)
When a resource is released (freed) it should be de-accounted
from the resource counter it was accounted to. This is called
"uncharging". The return value of this function indicate the amount
of charges still present in the counter.
The _locked routines imply that the res_counter->lock is taken.
e. u64 res_counter_uncharge_until
(struct res_counter *rc, struct res_counter *top,
unsigned long val)
Almost same as res_counter_uncharge() but propagation of uncharge
stops when rc == top. This is useful when kill a res_counter in
child cgroup.
2.1 Other accounting routines
There are more routines that may help you with common needs, like
checking whether the limit is reached or resetting the max_usage
value. They are all declared in include/linux/res_counter.h.
3. Analyzing the resource counter registrations
a. If the failcnt value constantly grows, this means that the counter's
limit is too tight. Either the group is misbehaving and consumes too
many resources, or the configuration is not suitable for the group
and the limit should be increased.
b. The max_usage value can be used to quickly tune the group. One may
set the limits to maximal values and either load the container with
a common pattern or leave one for a while. After this the max_usage
value shows the amount of memory the container would require during
its common activity.
Setting the limit a bit above this value gives a pretty good
configuration that works in most of the cases.
c. If the max_usage is much less than the limit, but the failcnt value
is growing, then the group tries to allocate a big chunk of resource
at once.
d. If the max_usage is much less than the limit, but the failcnt value
is 0, then this group is given too high limit, that it does not
require. It is better to lower the limit a bit leaving more resource
for other groups.
4. Communication with the control groups subsystem (cgroups)
All the resource controllers that are using cgroups and resource counters
should provide files (in the cgroup filesystem) to work with the resource
counter fields. They are recommended to adhere to the following rules:
a. File names
Field name File name
---------------------------------------------------
usage usage_in_<unit_of_measurement>
max_usage max_usage_in_<unit_of_measurement>
limit limit_in_<unit_of_measurement>
failcnt failcnt
lock no file :)
b. Reading from file should show the corresponding field value in the
appropriate format.
c. Writing to file
Field Expected behavior
----------------------------------
usage prohibited
max_usage reset to usage
limit set the limit
failcnt reset to zero
5. Usage example
a. Declare a task group (take a look at cgroups subsystem for this) and
fold a res_counter into it
struct my_group {
struct res_counter res;
<other fields>
}
b. Put hooks in resource allocation/release paths
int alloc_something(...)
{
if (res_counter_charge(res_counter_ptr, amount) < 0)
return -ENOMEM;
<allocate the resource and return to the caller>
}
void release_something(...)
{
res_counter_uncharge(res_counter_ptr, amount);
<release the resource>
}
In order to keep the usage value self-consistent, both the
"res_counter_ptr" and the "amount" in release_something() should be
the same as they were in the alloc_something() when the releasing
resource was allocated.
c. Provide the way to read res_counter values and set them (the cgroups
still can help with it).
c. Compile and run :)

2
Documentation/clk.txt
View File

@@ -74,7 +74,7 @@ the operations defined in clk.h:
long (*determine_rate)(struct clk_hw *hw,
unsigned long rate,
unsigned long *best_parent_rate,
struct clk **best_parent_clk);
struct clk_hw **best_parent_clk);
int (*set_parent)(struct clk_hw *hw, u8 index);
u8 (*get_parent)(struct clk_hw *hw);
int (*set_rate)(struct clk_hw *hw,

33
Documentation/cpu-freq/intel-pstate.txt
View File

@@ -1,17 +1,28 @@
Intel P-state driver
--------------------
This driver implements a scaling driver with an internal governor for
Intel Core processors. The driver follows the same model as the
Transmeta scaling driver (longrun.c) and implements the setpolicy()
instead of target(). Scaling drivers that implement setpolicy() are
assumed to implement internal governors by the cpufreq core. All the
logic for selecting the current P state is contained within the
driver; no external governor is used by the cpufreq core.
This driver provides an interface to control the P state selection for
SandyBridge+ Intel processors. The driver can operate two different
modes based on the processor model legacy and Hardware P state (HWP)
mode.
Intel SandyBridge+ processors are supported.
In legacy mode the driver implements a scaling driver with an internal
governor for Intel Core processors. The driver follows the same model
as the Transmeta scaling driver (longrun.c) and implements the
setpolicy() instead of target(). Scaling drivers that implement
setpolicy() are assumed to implement internal governors by the cpufreq
core. All the logic for selecting the current P state is contained
within the driver; no external governor is used by the cpufreq core.
New sysfs files for controlling P state selection have been added to
In HWP mode P state selection is implemented in the processor
itself. The driver provides the interfaces between the cpufreq core and
the processor to control P state selection based on user preferences
and reporting frequency to the cpufreq core. In this mode the
internal governor code is disabled.
In addtion to the interfaces provided by the cpufreq core for
controlling frequency the driver provides sysfs files for
controlling P state selection. These files have been added to
/sys/devices/system/cpu/intel_pstate/
max_perf_pct: limits the maximum P state that will be requested by
@@ -33,7 +44,9 @@ frequency is fiction for Intel Core processors. Even if the scaling
driver selects a single P state the actual frequency the processor
will run at is selected by the processor itself.
New debugfs files have also been added to /sys/kernel/debug/pstate_snb/
For legacy mode debugfs files have also been added to allow tuning of
the internal governor algorythm. These files are located at
/sys/kernel/debug/pstate_snb/ These files are NOT present in HWP mode.
deadband
d_gain_pct

205
Documentation/crypto/crypto-API-userspace.txt Normal file
View File

@@ -0,0 +1,205 @@
Introduction
============
The concepts of the kernel crypto API visible to kernel space is fully
applicable to the user space interface as well. Therefore, the kernel crypto API
high level discussion for the in-kernel use cases applies here as well.
The major difference, however, is that user space can only act as a consumer
and never as a provider of a transformation or cipher algorithm.
The following covers the user space interface exported by the kernel crypto
API. A working example of this description is libkcapi that can be obtained from
[1]. That library can be used by user space applications that require
cryptographic services from the kernel.
Some details of the in-kernel kernel crypto API aspects do not
apply to user space, however. This includes the difference between synchronous
and asynchronous invocations. The user space API call is fully synchronous.
In addition, only a subset of all cipher types are available as documented
below.
User space API general remarks
==============================
The kernel crypto API is accessible from user space. Currently, the following
ciphers are accessible:
* Message digest including keyed message digest (HMAC, CMAC)
* Symmetric ciphers
Note, AEAD ciphers are currently not supported via the symmetric cipher
interface.
The interface is provided via Netlink using the type AF_ALG. In addition, the
setsockopt option type is SOL_ALG. In case the user space header files do not
export these flags yet, use the following macros:
#ifndef AF_ALG
#define AF_ALG 38
#endif
#ifndef SOL_ALG
#define SOL_ALG 279
#endif
A cipher is accessed with the same name as done for the in-kernel API calls.
This includes the generic vs. unique naming schema for ciphers as well as the
enforcement of priorities for generic names.
To interact with the kernel crypto API, a Netlink socket must be created by
the user space application. User space invokes the cipher operation with the
send/write system call family. The result of the cipher operation is obtained
with the read/recv system call family.
The following API calls assume that the Netlink socket descriptor is already
opened by the user space application and discusses only the kernel crypto API
specific invocations.
To initialize a Netlink interface, the following sequence has to be performed
by the consumer:
1. Create a socket of type AF_ALG with the struct sockaddr_alg parameter
specified below for the different cipher types.
2. Invoke bind with the socket descriptor
3. Invoke accept with the socket descriptor. The accept system call
returns a new file descriptor that is to be used to interact with
the particular cipher instance. When invoking send/write or recv/read
system calls to send data to the kernel or obtain data from the
kernel, the file descriptor returned by accept must be used.
In-place cipher operation
=========================
Just like the in-kernel operation of the kernel crypto API, the user space
interface allows the cipher operation in-place. That means that the input buffer
used for the send/write system call and the output buffer used by the read/recv
system call may be one and the same. This is of particular interest for
symmetric cipher operations where a copying of the output data to its final
destination can be avoided.
If a consumer on the other hand wants to maintain the plaintext and the
ciphertext in different memory locations, all a consumer needs to do is to
provide different memory pointers for the encryption and decryption operation.
Message digest API
==================
The message digest type to be used for the cipher operation is selected when
invoking the bind syscall. bind requires the caller to provide a filled
struct sockaddr data structure. This data structure must be filled as follows:
struct sockaddr_alg sa = {
.salg_family = AF_ALG,
.salg_type = "hash", /* this selects the hash logic in the kernel */
.salg_name = "sha1" /* this is the cipher name */
};
The salg_type value "hash" applies to message digests and keyed message digests.
Though, a keyed message digest is referenced by the appropriate salg_name.
Please see below for the setsockopt interface that explains how the key can be
set for a keyed message digest.
Using the send() system call, the application provides the data that should be
processed with the message digest. The send system call allows the following
flags to be specified:
* MSG_MORE: If this flag is set, the send system call acts like a
message digest update function where the final hash is not
yet calculated. If the flag is not set, the send system call
calculates the final message digest immediately.
With the recv() system call, the application can read the message digest from
the kernel crypto API. If the buffer is too small for the message digest, the
flag MSG_TRUNC is set by the kernel.
In order to set a message digest key, the calling application must use the
setsockopt() option of ALG_SET_KEY. If the key is not set the HMAC operation is
performed without the initial HMAC state change caused by the key.
Symmetric cipher API
====================
The operation is very similar to the message digest discussion. During
initialization, the struct sockaddr data structure must be filled as follows:
struct sockaddr_alg sa = {
.salg_family = AF_ALG,
.salg_type = "skcipher", /* this selects the symmetric cipher */
.salg_name = "cbc(aes)" /* this is the cipher name */
};
Before data can be sent to the kernel using the write/send system call family,
the consumer must set the key. The key setting is described with the setsockopt
invocation below.
Using the sendmsg() system call, the application provides the data that should
be processed for encryption or decryption. In addition, the IV is specified
with the data structure provided by the sendmsg() system call.
The sendmsg system call parameter of struct msghdr is embedded into the
struct cmsghdr data structure. See recv(2) and cmsg(3) for more information
on how the cmsghdr data structure is used together with the send/recv system
call family. That cmsghdr data structure holds the following information
specified with a separate header instances:
* specification of the cipher operation type with one of these flags:
ALG_OP_ENCRYPT - encryption of data
ALG_OP_DECRYPT - decryption of data
* specification of the IV information marked with the flag ALG_SET_IV
The send system call family allows the following flag to be specified:
* MSG_MORE: If this flag is set, the send system call acts like a
cipher update function where more input data is expected
with a subsequent invocation of the send system call.
Note: The kernel reports -EINVAL for any unexpected data. The caller must
make sure that all data matches the constraints given in /proc/crypto for the
selected cipher.
With the recv() system call, the application can read the result of the
cipher operation from the kernel crypto API. The output buffer must be at least
as large as to hold all blocks of the encrypted or decrypted data. If the output
data size is smaller, only as many blocks are returned that fit into that
output buffer size.
Setsockopt interface
====================
In addition to the read/recv and send/write system call handling to send and
retrieve data subject to the cipher operation, a consumer also needs to set
the additional information for the cipher operation. This additional information
is set using the setsockopt system call that must be invoked with the file
descriptor of the open cipher (i.e. the file descriptor returned by the
accept system call).
Each setsockopt invocation must use the level SOL_ALG.
The setsockopt interface allows setting the following data using the mentioned
optname:
* ALG_SET_KEY -- Setting the key. Key setting is applicable to:
- the skcipher cipher type (symmetric ciphers)
- the hash cipher type (keyed message digests)
User space API example
======================
Please see [1] for libkcapi which provides an easy-to-use wrapper around the
aforementioned Netlink kernel interface. [1] also contains a test application
that invokes all libkcapi API calls.
[1] http://www.chronox.de/libkcapi.html
Author
======
Stephan Mueller <smueller@chronox.de>

22
Documentation/device-mapper/cache-policies.txt
View File

@@ -47,20 +47,26 @@ Message and constructor argument pairs are:
'discard_promote_adjustment <value>'
The sequential threshold indicates the number of contiguous I/Os
required before a stream is treated as sequential. The random threshold
required before a stream is treated as sequential. Once a stream is
considered sequential it will bypass the cache. The random threshold
is the number of intervening non-contiguous I/Os that must be seen
before the stream is treated as random again.
The sequential and random thresholds default to 512 and 4 respectively.
Large, sequential ios are probably better left on the origin device
since spindles tend to have good bandwidth. The io_tracker counts
contiguous I/Os to try to spot when the io is in one of these sequential
modes.
Large, sequential I/Os are probably better left on the origin device
since spindles tend to have good sequential I/O bandwidth. The
io_tracker counts contiguous I/Os to try to spot when the I/O is in one
of these sequential modes. But there are use-cases for wanting to
promote sequential blocks to the cache (e.g. fast application startup).
If sequential threshold is set to 0 the sequential I/O detection is
disabled and sequential I/O will no longer implicitly bypass the cache.
Setting the random threshold to 0 does _not_ disable the random I/O
stream detection.
Internally the mq policy maintains a promotion threshold variable. If
the hit count of a block not in the cache goes above this threshold it
gets promoted to the cache. The read, write and discard promote adjustment
Internally the mq policy determines a promotion threshold. If the hit
count of a block not in the cache goes above this threshold it gets
promoted to the cache. The read, write and discard promote adjustment
tunables allow you to tweak the promotion threshold by adding a small
value based on the io type. They default to 4, 8 and 1 respectively.
If you're trying to quickly warm a new cache device you may wish to

8
Documentation/devicetree/bindings/arm/amlogic.txt
View File

@@ -2,7 +2,9 @@ Amlogic MesonX device tree bindings
-------------------------------------------
Boards with the Amlogic Meson6 SoC shall have the following properties:
Required root node property:
compatible: "amlogic,meson6"
Required root node property:
compatible = "amlogic,meson6";
Boards with the Amlogic Meson8 SoC shall have the following properties:
Required root node property:
compatible: "amlogic,meson8";

8
Documentation/devicetree/bindings/arm/arch_timer.txt
View File

@@ -22,6 +22,14 @@ to deliver its interrupts via SPIs.
- always-on : a boolean property. If present, the timer is powered through an
always-on power domain, therefore it never loses context.
** Optional properties:
- arm,cpu-registers-not-fw-configured : Firmware does not initialize
any of the generic timer CPU registers, which contain their
architecturally-defined reset values. Only supported for 32-bit
systems which follow the ARMv7 architected reset values.
Example:
timer {

65
Documentation/devicetree/bindings/arm/arm-boards
View File

@@ -92,3 +92,68 @@ Required nodes:
- core-module: the root node to the Versatile platforms must have
a core-module with regs and the compatible strings
"arm,core-module-versatile", "syscon"
ARM RealView Boards
-------------------
The RealView boards cover tailored evaluation boards that are used to explore
the ARM11 and Cortex A-8 and Cortex A-9 processors.
Required properties (in root node):
/* RealView Emulation Baseboard */
compatible = "arm,realview-eb";
/* RealView Platform Baseboard for ARM1176JZF-S */
compatible = "arm,realview-pb1176";
/* RealView Platform Baseboard for ARM11 MPCore */
compatible = "arm,realview-pb11mp";
/* RealView Platform Baseboard for Cortex A-8 */
compatible = "arm,realview-pba8";
/* RealView Platform Baseboard Explore for Cortex A-9 */
compatible = "arm,realview-pbx";
Required nodes:
- soc: some node of the RealView platforms must be the SoC
node that contain the SoC-specific devices, withe the compatible
string set to one of these tuples:
"arm,realview-eb-soc", "simple-bus"
"arm,realview-pb1176-soc", "simple-bus"
"arm,realview-pb11mp-soc", "simple-bus"
"arm,realview-pba8-soc", "simple-bus"
"arm,realview-pbx-soc", "simple-bus"
- syscon: some subnode of the RealView SoC node must be a
system controller node pointing to the control registers,
with the compatible string set to one of these tuples:
"arm,realview-eb-syscon", "syscon"
"arm,realview-pb1176-syscon", "syscon"
"arm,realview-pb11mp-syscon", "syscon"
"arm,realview-pba8-syscon", "syscon"
"arm,realview-pbx-syscon", "syscon"
Required properties for the system controller:
- regs: the location and size of the system controller registers,
one range of 0x1000 bytes.
Example:
/dts-v1/;
#include <dt-bindings/interrupt-controller/irq.h>
#include "skeleton.dtsi"
/ {
model = "ARM RealView PB1176 with device tree";
compatible = "arm,realview-pb1176";
soc {
#address-cells = <1>;
#size-cells = <1>;
compatible = "arm,realview-pb1176-soc", "simple-bus";
ranges;
syscon: syscon@10000000 {
compatible = "arm,realview-syscon", "syscon";
reg = <0x10000000 0x1000>;
};
};
};

31
Documentation/devicetree/bindings/arm/bcm/cygnus.txt Normal file
View File

@@ -0,0 +1,31 @@
Broadcom Cygnus device tree bindings
------------------------------------
Boards with Cygnus SoCs shall have the following properties:
Required root node property:
BCM11300
compatible = "brcm,bcm11300", "brcm,cygnus";
BCM11320
compatible = "brcm,bcm11320", "brcm,cygnus";
BCM11350
compatible = "brcm,bcm11350", "brcm,cygnus";
BCM11360
compatible = "brcm,bcm11360", "brcm,cygnus";
BCM58300
compatible = "brcm,bcm58300", "brcm,cygnus";
BCM58302
compatible = "brcm,bcm58302", "brcm,cygnus";
BCM58303
compatible = "brcm,bcm58303", "brcm,cygnus";
BCM58305
compatible = "brcm,bcm58305", "brcm,cygnus";

204
Documentation/devicetree/bindings/arm/coresight.txt Normal file
View File

@@ -0,0 +1,204 @@
* CoreSight Components:
CoreSight components are compliant with the ARM CoreSight architecture
specification and can be connected in various topologies to suit a particular
SoCs tracing needs. These trace components can generally be classified as
sinks, links and sources. Trace data produced by one or more sources flows
through the intermediate links connecting the source to the currently selected
sink. Each CoreSight component device should use these properties to describe
its hardware characteristcs.
* Required properties for all components *except* non-configurable replicators:
* compatible: These have to be supplemented with "arm,primecell" as
drivers are using the AMBA bus interface. Possible values include:
- "arm,coresight-etb10", "arm,primecell";
- "arm,coresight-tpiu", "arm,primecell";
- "arm,coresight-tmc", "arm,primecell";
- "arm,coresight-funnel", "arm,primecell";
- "arm,coresight-etm3x", "arm,primecell";
* reg: physical base address and length of the register
set(s) of the component.
* clocks: the clock associated to this component.
* clock-names: the name of the clock as referenced by the code.
Since we are using the AMBA framework, the name should be
"apb_pclk".
* port or ports: The representation of the component's port
layout using the generic DT graph presentation found in
"bindings/graph.txt".
* Required properties for devices that don't show up on the AMBA bus, such as
non-configurable replicators:
* compatible: Currently supported value is (note the absence of the
AMBA markee):
- "arm,coresight-replicator"
* id: a unique number that will identify this replicator.
* port or ports: same as above.
* Optional properties for ETM/PTMs:
* arm,cp14: must be present if the system accesses ETM/PTM management
registers via co-processor 14.
* cpu: the cpu phandle this ETM/PTM is affined to. When omitted the
source is considered to belong to CPU0.
* Optional property for TMC:
* arm,buffer-size: size of contiguous buffer space for TMC ETR
(embedded trace router)
Example:
1. Sinks
etb@20010000 {
compatible = "arm,coresight-etb10", "arm,primecell";
reg = <0 0x20010000 0 0x1000>;
coresight-default-sink;
clocks = <&oscclk6a>;
clock-names = "apb_pclk";
port {
etb_in_port: endpoint@0 {
slave-mode;
remote-endpoint = <&replicator_out_port0>;
};
};
};
tpiu@20030000 {
compatible = "arm,coresight-tpiu", "arm,primecell";
reg = <0 0x20030000 0 0x1000>;
clocks = <&oscclk6a>;
clock-names = "apb_pclk";
port {
tpiu_in_port: endpoint@0 {
slave-mode;
remote-endpoint = <&replicator_out_port1>;
};
};
};
2. Links
replicator {
/* non-configurable replicators don't show up on the
* AMBA bus. As such no need to add "arm,primecell".
*/
compatible = "arm,coresight-replicator";
/* this will show up in debugfs as "0.replicator" */
id = <0>;
ports {
#address-cells = <1>;
#size-cells = <0>;
/* replicator output ports */
port@0 {
reg = <0>;
replicator_out_port0: endpoint {
remote-endpoint = <&etb_in_port>;
};
};
port@1 {
reg = <1>;
replicator_out_port1: endpoint {
remote-endpoint = <&tpiu_in_port>;
};
};
/* replicator input port */
port@2 {
reg = <0>;
replicator_in_port0: endpoint {
slave-mode;
remote-endpoint = <&funnel_out_port0>;
};
};
};
};
funnel@20040000 {
compatible = "arm,coresight-funnel", "arm,primecell";
reg = <0 0x20040000 0 0x1000>;
clocks = <&oscclk6a>;
clock-names = "apb_pclk";
ports {
#address-cells = <1>;
#size-cells = <0>;
/* funnel output port */
port@0 {
reg = <0>;
funnel_out_port0: endpoint {
remote-endpoint =
<&replicator_in_port0>;
};
};
/* funnel input ports */
port@1 {
reg = <0>;
funnel_in_port0: endpoint {
slave-mode;
remote-endpoint = <&ptm0_out_port>;
};
};
port@2 {
reg = <1>;
funnel_in_port1: endpoint {
slave-mode;
remote-endpoint = <&ptm1_out_port>;
};
};
port@3 {
reg = <2>;
funnel_in_port2: endpoint {
slave-mode;
remote-endpoint = <&etm0_out_port>;
};
};
};
};
3. Sources
ptm@2201c000 {
compatible = "arm,coresight-etm3x", "arm,primecell";
reg = <0 0x2201c000 0 0x1000>;
cpu = <&cpu0>;
clocks = <&oscclk6a>;
clock-names = "apb_pclk";
port {
ptm0_out_port: endpoint {
remote-endpoint = <&funnel_in_port0>;
};
};
};
ptm@2201d000 {
compatible = "arm,coresight-etm3x", "arm,primecell";
reg = <0 0x2201d000 0 0x1000>;
cpu = <&cpu1>;
clocks = <&oscclk6a>;
clock-names = "apb_pclk";
port {
ptm1_out_port: endpoint {
remote-endpoint = <&funnel_in_port1>;
};
};
};

9
Documentation/devicetree/bindings/arm/cpus.txt
View File

@@ -227,6 +227,15 @@ nodes to be present and contain the properties described below.
# List of phandles to idle state nodes supported
by this cpu [3].
- rockchip,pmu
Usage: optional for systems that have an "enable-method"
property value of "rockchip,rk3066-smp"
While optional, it is the preferred way to get access to
the cpu-core power-domains.
Value type: <phandle>
Definition: Specifies the syscon node controlling the cpu core
power domains.
Example 1 (dual-cluster big.LITTLE system 32-bit):
cpus {

38
Documentation/devicetree/bindings/arm/fsl.txt
View File

@@ -74,3 +74,41 @@ Required root node properties:
i.MX6q generic board
Required root node properties:
- compatible = "fsl,imx6q";
Freescale LS1021A Platform Device Tree Bindings
------------------------------------------------
Required root node compatible properties:
- compatible = "fsl,ls1021a";
Freescale LS1021A SoC-specific Device Tree Bindings
-------------------------------------------
Freescale SCFG
SCFG is the supplemental configuration unit, that provides SoC specific
configuration and status registers for the chip. Such as getting PEX port
status.
Required properties:
- compatible: should be "fsl,ls1021a-scfg"
- reg: should contain base address and length of SCFG memory-mapped registers
Example:
scfg: scfg@1570000 {
compatible = "fsl,ls1021a-scfg";
reg = <0x0 0x1570000 0x0 0x10000>;
};
Freescale DCFG
DCFG is the device configuration unit, that provides general purpose
configuration and status for the device. Such as setting the secondary
core start address and release the secondary core from holdoff and startup.
Required properties:
- compatible: should be "fsl,ls1021a-dcfg"
- reg : should contain base address and length of DCFG memory-mapped registers
Example:
dcfg: dcfg@1ee0000 {
compatible = "fsl,ls1021a-dcfg";
reg = <0x0 0x1ee0000 0x0 0x10000>;
};

39
Documentation/devicetree/bindings/arm/gic-v3.txt
View File

@@ -49,11 +49,29 @@ Optional
occupied by the redistributors. Required if more than one such
region is present.
Sub-nodes:
GICv3 has one or more Interrupt Translation Services (ITS) that are
used to route Message Signalled Interrupts (MSI) to the CPUs.
These nodes must have the following properties:
- compatible : Should at least contain "arm,gic-v3-its".
- msi-controller : Boolean property. Identifies the node as an MSI controller
- reg: Specifies the base physical address and size of the ITS
registers.
The main GIC node must contain the appropriate #address-cells,
#size-cells and ranges properties for the reg property of all ITS
nodes.
Examples:
gic: interrupt-controller@2cf00000 {
compatible = "arm,gic-v3";
#interrupt-cells = <3>;
#address-cells = <2>;
#size-cells = <2>;
ranges;
interrupt-controller;
reg = <0x0 0x2f000000 0 0x10000>, // GICD
<0x0 0x2f100000 0 0x200000>, // GICR
@@ -61,11 +79,20 @@ Examples:
<0x0 0x2c010000 0 0x2000>, // GICH
<0x0 0x2c020000 0 0x2000>; // GICV
interrupts = <1 9 4>;
gic-its@2c200000 {
compatible = "arm,gic-v3-its";
msi-controller;
reg = <0x0 0x2c200000 0 0x200000>;
};
};
gic: interrupt-controller@2c010000 {
compatible = "arm,gic-v3";
#interrupt-cells = <3>;
#address-cells = <2>;
#size-cells = <2>;
ranges;
interrupt-controller;
redistributor-stride = <0x0 0x40000>; // 256kB stride
#redistributor-regions = <2>;
@@ -76,4 +103,16 @@ Examples:
<0x0 0x2c060000 0 0x2000>, // GICH
<0x0 0x2c080000 0 0x2000>; // GICV
interrupts = <1 9 4>;
gic-its@2c200000 {
compatible = "arm,gic-v3-its";
msi-controller;
reg = <0x0 0x2c200000 0 0x200000>;
};
gic-its@2c400000 {
compatible = "arm,gic-v3-its";
msi-controller;
reg = <0x0 0x2c400000 0 0x200000>;
};
};

54
Documentation/devicetree/bindings/arm/gic.txt
View File

@@ -17,6 +17,7 @@ Main node required properties:
"arm,cortex-a7-gic"
"arm,arm11mp-gic"
"brcm,brahma-b15-gic"
"arm,arm1176jzf-devchip-gic"
- interrupt-controller : Identifies the node as an interrupt controller
- #interrupt-cells : Specifies the number of cells needed to encode an
interrupt source. The type shall be a <u32> and the value shall be 3.
@@ -96,3 +97,56 @@ Example:
<0x2c006000 0x2000>;
interrupts = <1 9 0xf04>;
};
* GICv2m extension for MSI/MSI-x support (Optional)
Certain revisions of GIC-400 supports MSI/MSI-x via V2M register frame(s).
This is enabled by specifying v2m sub-node(s).
Required properties:
- compatible : The value here should contain "arm,gic-v2m-frame".
- msi-controller : Identifies the node as an MSI controller.
- reg : GICv2m MSI interface register base and size
Optional properties:
- arm,msi-base-spi : When the MSI_TYPER register contains an incorrect
value, this property should contain the SPI base of
the MSI frame, overriding the HW value.
- arm,msi-num-spis : When the MSI_TYPER register contains an incorrect
value, this property should contain the number of
SPIs assigned to the frame, overriding the HW value.
Example:
interrupt-controller@e1101000 {
compatible = "arm,gic-400";
#interrupt-cells = <3>;
#address-cells = <2>;
#size-cells = <2>;
interrupt-controller;
interrupts = <1 8 0xf04>;
ranges = <0 0 0 0xe1100000 0 0x100000>;
reg = <0x0 0xe1110000 0 0x01000>,
<0x0 0xe112f000 0 0x02000>,
<0x0 0xe1140000 0 0x10000>,
<0x0 0xe1160000 0 0x10000>;
v2m0: v2m@0x8000 {
compatible = "arm,gic-v2m-frame";
msi-controller;
reg = <0x0 0x80000 0 0x1000>;
};
....
v2mN: v2m@0x9000 {
compatible = "arm,gic-v2m-frame";
msi-controller;
reg = <0x0 0x90000 0 0x1000>;
};
};

20
Documentation/devicetree/bindings/arm/idle-states.txt
View File

@@ -317,6 +317,26 @@ follows:
In such systems entry-latency-us + exit-latency-us
will exceed wakeup-latency-us by this duration.
- status:
Usage: Optional
Value type: <string>
Definition: A standard device tree property [5] that indicates
the operational status of an idle-state.
If present, it shall be:
"okay": to indicate that the idle state is
operational.
"disabled": to indicate that the idle state has
been disabled in firmware so it is not
operational.
If the property is not present the idle-state must
be considered operational.
- idle-state-name:
Usage: Optional
Value type: <string>
Definition: A string used as a descriptive name for the idle
state.
In addition to the properties listed above, a state node may require
additional properties specifics to the entry-method defined in the
idle-states node, please refer to the entry-method bindings

10
Documentation/devicetree/bindings/arm/marvell,berlin.txt
View File

@@ -106,11 +106,21 @@ Required subnode-properties:
- groups: a list of strings describing the group names.
- function: a string describing the function used to mux the groups.
* Reset controller binding
A reset controller is part of the chip control registers set. The chip control
node also provides the reset. The register set is not at the same offset between
Berlin SoCs.
Required property:
- #reset-cells: must be set to 2
Example:
chip: chip-control@ea0000 {
compatible = "marvell,berlin2-chip-ctrl";
#clock-cells = <1>;
#reset-cells = <2>;
reg = <0xea0000 0x400>;
clocks = <&refclk>, <&externaldev 0>;
clock-names = "refclk", "video_ext0";

19
Documentation/devicetree/bindings/arm/mediatek.txt
View File

@@ -1,10 +1,14 @@
Mediatek MT6589 Platforms Device Tree Bindings
MediaTek mt65xx & mt81xx Platforms Device Tree Bindings
Boards with a SoC of the Mediatek MT6589 shall have the following property:
Boards with a MediaTek mt65xx/mt81xx SoC shall have the following property:
Required root node property:
compatible: must contain "mediatek,mt6589"
compatible: Must contain one of
"mediatek,mt6589"
"mediatek,mt6592"
"mediatek,mt8127"
"mediatek,mt8135"
Supported boards:
@@ -12,3 +16,12 @@ Supported boards:
- bq Aquaris5 smart phone:
Required root node properties:
- compatible = "mundoreader,bq-aquaris5", "mediatek,mt6589";
- Evaluation board for MT6592:
Required root node properties:
- compatible = "mediatek,mt6592-evb", "mediatek,mt6592";
- MTK mt8127 tablet moose EVB:
Required root node properties:
- compatible = "mediatek,mt8127-moose", "mediatek,mt8127";
- MTK mt8135 tablet EVB:
Required root node properties:
- compatible = "mediatek,mt8135-evbp1", "mediatek,mt8135";

28
Documentation/devicetree/bindings/arm/mediatek/mediatek,sysirq.txt Normal file
View File

@@ -0,0 +1,28 @@
Mediatek 65xx/81xx sysirq
Mediatek SOCs sysirq support controllable irq inverter for each GIC SPI
interrupt.
Required properties:
- compatible: should be one of:
"mediatek,mt8135-sysirq"
"mediatek,mt8127-sysirq"
"mediatek,mt6589-sysirq"
"mediatek,mt6582-sysirq"
"mediatek,mt6577-sysirq"
- interrupt-controller : Identifies the node as an interrupt controller
- #interrupt-cells : Use the same format as specified by GIC in
Documentation/devicetree/bindings/arm/gic.txt
- interrupt-parent: phandle of irq parent for sysirq. The parent must
use the same interrupt-cells format as GIC.
- reg: Physical base address of the intpol registers and length of memory
mapped region.
Example:
sysirq: interrupt-controller@10200100 {
compatible = "mediatek,mt6589-sysirq", "mediatek,mt6577-sysirq";
interrupt-controller;
#interrupt-cells = <3>;
interrupt-parent = <&gic>;
reg = <0 0x10200100 0 0x1c>;
};

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

@@ -132,6 +132,9 @@ Boards:
- AM335X Bone : Low cost community board
compatible = "ti,am335x-bone", "ti,am33xx", "ti,omap3"
- AM335X OrionLXm : Substation Automation Platform
compatible = "novatech,am335x-lxm", "ti,am33xx"
- OMAP5 EVM : Evaluation Module
compatible = "ti,omap5-evm", "ti,omap5"

4
Documentation/devicetree/bindings/arm/rockchip.txt
View File

@@ -1,6 +1,10 @@
Rockchip platforms device tree bindings
---------------------------------------
- MarsBoard RK3066 board:
Required root node properties:
- compatible = "haoyu,marsboard-rk3066", "rockchip,rk3066a";
- bq Curie 2 tablet:
Required root node properties:
- compatible = "mundoreader,bq-curie2", "rockchip,rk3066a";

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

@@ -1,11 +1,20 @@
* Samsung's Exynos4210 based SMDKV310 evaluation board
SMDKV310 evaluation board is based on Samsung's Exynos4210 SoC.
* Samsung's Exynos SoC based boards
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.
- "samsung,monk" - for Exynos3250-based Samsung Simband board.
- "samsung,rinato" - for Exynos3250-based Samsung Gear2 board.
- "samsung,smdkv310" - for Exynos4210-based Samsung SMDKV310 eval board.
- "samsung,trats" - for Exynos4210-based Tizen Reference board.
- "samsung,universal_c210" - for Exynos4210-based Samsung board.
- "samsung,smdk4412", - for Exynos4412-based Samsung SMDK4412 eval board.
- "samsung,trats2" - for Exynos4412-based Tizen Reference board.
- "samsung,smdk5250" - for Exynos5250-based Samsung SMDK5250 eval board.
- "samsung,xyref5260" - for Exynos5260-based Samsung board.
- "samsung,smdk5410" - for Exynos5410-based Samsung SMDK5410 eval board.
- "samsung,smdk5420" - for Exynos5420-based Samsung SMDK5420 eval board.
- "samsung,sd5v1" - for Exynos5440-based Samsung board.
- "samsung,ssdk5440" - for Exynos5440-based Samsung board.
Optional:
- firmware node, specifying presence and type of secure firmware:

11
Documentation/devicetree/bindings/arm/samsung/exynos-adc.txt
View File

@@ -16,6 +16,8 @@ Required properties:
future controllers.
Must be "samsung,exynos3250-adc" for
controllers compatible with ADC of Exynos3250.
Must be "samsung,exynos7-adc" for
the ADC in Exynos7 and compatibles
Must be "samsung,s3c2410-adc" for
the ADC in s3c2410 and compatibles
Must be "samsung,s3c2416-adc" for
@@ -43,13 +45,16 @@ Required properties:
compatible ADC block)
- vdd-supply VDD input supply.
- samsung,syscon-phandle Contains the PMU system controller node
(To access the ADC_PHY register on Exynos5250/5420/5800/3250)
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>;
reg = <0x12D10000 0x100>;
interrupts = <0 106 0>;
#io-channel-cells = <1>;
io-channel-ranges;
@@ -58,13 +63,14 @@ adc: adc@12D10000 {
clock-names = "adc";
vdd-supply = <&buck5_reg>;
samsung,syscon-phandle = <&pmu_system_controller>;
};
Example: adding device info in dtsi file for Exynos3250 with additional sclk
adc: adc@126C0000 {
compatible = "samsung,exynos3250-adc", "samsung,exynos-adc-v2;
reg = <0x126C0000 0x100>, <0x10020718 0x4>;
reg = <0x126C0000 0x100>;
interrupts = <0 137 0>;
#io-channel-cells = <1>;
io-channel-ranges;
@@ -73,6 +79,7 @@ adc: adc@126C0000 {
clock-names = "adc", "sclk";
vdd-supply = <&buck5_reg>;
samsung,syscon-phandle = <&pmu_system_controller>;
};
Example: Adding child nodes in dts file

6
Documentation/devicetree/bindings/arm/ste-nomadik.txt
View File

@@ -10,6 +10,12 @@ Required root node property: src
Boards with the Nomadik SoC include:
Nomadik NHK-15 board manufactured by ST Microelectronics:
Required root node property:
compatible="st,nomadik-nhk-15";
S8815 "MiniKit" manufactured by Calao Systems:
Required root node property:

12
Documentation/devicetree/bindings/arm/sunxi.txt Normal file
View File

@@ -0,0 +1,12 @@
Allwinner sunXi Platforms Device Tree Bindings
Each device tree must specify which Allwinner SoC it uses,
using one of the following compatible strings:
allwinner,sun4i-a10
allwinner,sun5i-a10s
allwinner,sun5i-a13
allwinner,sun6i-a31
allwinner,sun7i-a20
allwinner,sun8i-a23
allwinner,sun9i-a80

35
Documentation/devicetree/bindings/arm/ux500/power_domain.txt Normal file
View File

@@ -0,0 +1,35 @@
* ST-Ericsson UX500 PM Domains
UX500 supports multiple PM domains which are used to gate power to one or
more peripherals on the SOC.
The implementation of PM domains for UX500 are based upon the generic PM domain
and use the corresponding DT bindings.
==PM domain providers==
Required properties:
- compatible: Must be "stericsson,ux500-pm-domains".
- #power-domain-cells : Number of cells in a power domain specifier, must be 1.
Example:
pm_domains: pm_domains0 {
compatible = "stericsson,ux500-pm-domains";
#power-domain-cells = <1>;
};
==PM domain consumers==
Required properties:
- power-domains: A phandle and PM domain specifier. Below are the list of
valid specifiers:
Index Specifier
----- ---------
0 DOMAIN_VAPE
Example:
sdi0_per1@80126000 {
compatible = "arm,pl18x", "arm,primecell";
power-domains = <&pm_domains DOMAIN_VAPE>
};

6
Documentation/devicetree/bindings/ata/marvell.txt
View File

@@ -6,11 +6,17 @@ Required Properties:
- interrupts : Interrupt controller is using
- nr-ports : Number of SATA ports in use.
Optional Properties:
- phys : List of phandles to sata phys
- phy-names : Should be "0", "1", etc, one number per phandle
Example:
sata@80000 {
compatible = "marvell,orion-sata";
reg = <0x80000 0x5000>;
interrupts = <21>;
phys = <&sata_phy0>, <&sata_phy1>;
phy-names = "0", "1";
nr-ports = <2>;
}

11
Documentation/devicetree/bindings/ata/sata_rcar.txt
View File

@@ -3,18 +3,21 @@
Required properties:
- compatible : should contain one of the following:
- "renesas,sata-r8a7779" for R-Car H1
("renesas,rcar-sata" is deprecated)
- "renesas,sata-r8a7790-es1" for R-Car H2 ES1
- "renesas,sata-r8a7790" for R-Car H2 other than ES1
- "renesas,sata-r8a7791" for R-Car M2-W
- "renesas,sata-r8a7793" for R-Car M2-N
- reg : address and length of the SATA registers;
- interrupts : must consist of one interrupt specifier.
- clocks : must contain a reference to the functional clock.
Example:
sata: sata@fc600000 {
compatible = "renesas,sata-r8a7779";
reg = <0xfc600000 0x2000>;
sata0: sata@ee300000 {
compatible = "renesas,sata-r8a7791";
reg = <0 0xee300000 0 0x2000>;
interrupt-parent = <&gic>;
interrupts = <0 100 IRQ_TYPE_LEVEL_HIGH>;
interrupts = <0 105 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&mstp8_clks R8A7791_CLK_SATA0>;
};

29
Documentation/devicetree/bindings/btmrvl.txt Normal file
View File

@@ -0,0 +1,29 @@
btmrvl
------
Required properties:
- compatible : must be "btmrvl,cfgdata"
Optional properties:
- btmrvl,cal-data : Calibration data downloaded to the device during
initialization. This is an array of 28 values(u8).
- btmrvl,gpio-gap : gpio and gap (in msecs) combination to be
configured.
Example:
GPIO pin 13 is configured as a wakeup source and GAP is set to 100 msecs
in below example.
btmrvl {
compatible = "btmrvl,cfgdata";
btmrvl,cal-data = /bits/ 8 <
0x37 0x01 0x1c 0x00 0xff 0xff 0xff 0xff 0x01 0x7f 0x04 0x02
0x00 0x00 0xba 0xce 0xc0 0xc6 0x2d 0x00 0x00 0x00 0x00 0x00
0x00 0x00 0xf0 0x00>;
btmrvl,gpio-gap = <0x0d64>;
};

21
Documentation/devicetree/bindings/bus/bcma.txt
View File

@@ -8,6 +8,11 @@ Required properties:
The cores on the AXI bus are automatically detected by bcma with the
memory ranges they are using and they get registered afterwards.
Automatic detection of the IRQ number is not working on
BCM47xx/BCM53xx ARM SoCs. To assign IRQ numbers to the cores, provide
them manually through device tree. Use an interrupt-map to specify the
IRQ used by the devices on the bus. The first address is just an index,
because we do not have any special register.
The top-level axi bus may contain children representing attached cores
(devices). This is needed since some hardware details can't be auto
@@ -22,6 +27,22 @@ Example:
ranges = <0x00000000 0x18000000 0x00100000>;
#address-cells = <1>;
#size-cells = <1>;
#interrupt-cells = <1>;
interrupt-map-mask = <0x000fffff 0xffff>;
interrupt-map =
/* Ethernet Controller 0 */
<0x00024000 0 &gic GIC_SPI 147 IRQ_TYPE_LEVEL_HIGH>,
/* Ethernet Controller 1 */
<0x00025000 0 &gic GIC_SPI 148 IRQ_TYPE_LEVEL_HIGH>;
/* PCIe Controller 0 */
<0x00012000 0 &gic GIC_SPI 126 IRQ_TYPE_LEVEL_HIGH>,
<0x00012000 1 &gic GIC_SPI 127 IRQ_TYPE_LEVEL_HIGH>,
<0x00012000 2 &gic GIC_SPI 128 IRQ_TYPE_LEVEL_HIGH>,
<0x00012000 3 &gic GIC_SPI 129 IRQ_TYPE_LEVEL_HIGH>,
<0x00012000 4 &gic GIC_SPI 130 IRQ_TYPE_LEVEL_HIGH>,
<0x00012000 5 &gic GIC_SPI 131 IRQ_TYPE_LEVEL_HIGH>;
chipcommon {
reg = <0x00000000 0x1000>;

6
Documentation/devicetree/bindings/bus/brcm,gisb-arb.txt
View File

@@ -2,7 +2,11 @@ Broadcom GISB bus Arbiter controller
Required properties:
- compatible: should be "brcm,gisb-arb"
- compatible:
"brcm,gisb-arb" or "brcm,bcm7445-gisb-arb" for 28nm chips
"brcm,bcm7435-gisb-arb" for newer 40nm chips
"brcm,bcm7400-gisb-arb" for older 40nm chips and all 65nm chips
"brcm,bcm7038-gisb-arb" for 130nm chips
- reg: specifies the base physical address and size of the registers
- interrupt-parent: specifies the phandle to the parent interrupt controller
this arbiter gets interrupt line from

17
Documentation/devicetree/bindings/bus/mvebu-mbus.txt
View File

@@ -48,9 +48,12 @@ Required properties:
- compatible: Should be set to "marvell,mbus-controller".
- reg: Device's register space.
Two entries are expected (see the examples below):
the first one controls the devices decoding window and
the second one controls the SDRAM decoding window.
Two or three entries are expected (see the examples below):
the first one controls the devices decoding window,
the second one controls the SDRAM decoding window and
the third controls the MBus bridge (only with the
marvell,armada370-mbus and marvell,armadaxp-mbus
compatible strings)
Example:
@@ -67,7 +70,7 @@ Example:
mbusc: mbus-controller@20000 {
compatible = "marvell,mbus-controller";
reg = <0x20000 0x100>, <0x20180 0x20>;
reg = <0x20000 0x100>, <0x20180 0x20>, <0x20250 0x8>;
};
/* more children ...*/
@@ -126,7 +129,7 @@ are skipped.
mbusc: mbus-controller@20000 {
compatible = "marvell,mbus-controller";
reg = <0x20000 0x100>, <0x20180 0x20>;
reg = <0x20000 0x100>, <0x20180 0x20>, <0x20250 0x8>;
};
/* more children ...*/
@@ -170,7 +173,7 @@ Using this macro, the above example would be:
mbusc: mbus-controller@20000 {
compatible = "marvell,mbus-controller";
reg = <0x20000 0x100>, <0x20180 0x20>;
reg = <0x20000 0x100>, <0x20180 0x20>, <0x20250 0x8>;
};
/* other children */
@@ -266,7 +269,7 @@ See the example below, where a more complete device tree is shown:
ranges = <0 MBUS_ID(0xf0, 0x01) 0 0x100000>;
mbusc: mbus-controller@20000 {
reg = <0x20000 0x100>, <0x20180 0x20>;
reg = <0x20000 0x100>, <0x20180 0x20>, <0x20250 0x8>;
};
interrupt-controller@20000 {

46
Documentation/devicetree/bindings/chosen.txt Normal file
View File

@@ -0,0 +1,46 @@
The chosen node
---------------
The chosen node does not represent a real device, but serves as a place
for passing data between firmware and the operating system, like boot
arguments. Data in the chosen node does not represent the hardware.
stdout-path property
--------------------
Device trees may specify the device to be used for boot console output
with a stdout-path property under /chosen, as described in ePAPR, e.g.
/ {
chosen {
stdout-path = "/serial@f00:115200";
};
serial@f00 {
compatible = "vendor,some-uart";
reg = <0xf00 0x10>;
};
};
If the character ":" is present in the value, this terminates the path.
The meaning of any characters following the ":" is device-specific, and
must be specified in the relevant binding documentation.
For UART devices, the preferred binding is a string in the form:
<baud>{<parity>{<bits>{<flow>}}}
where
baud - baud rate in decimal
parity - 'n' (none), 'o', (odd) or 'e' (even)
bits - number of data bits
flow - 'r' (rts)
For example: 115200n8r
Implementation note: Linux will look for the property "linux,stdout-path" or
on PowerPC "stdout" if "stdout-path" is not found. However, the
"linux,stdout-path" and "stdout" properties are deprecated. New platforms
should only use the "stdout-path" property.

34
Documentation/devicetree/bindings/clock/bcm-cygnus-clock.txt Normal file
View File

@@ -0,0 +1,34 @@
Broadcom Cygnus Clocks
This binding uses the common clock binding:
Documentation/devicetree/bindings/clock/clock-bindings.txt
Currently various "fixed" clocks are declared for peripheral drivers that use
the common clock framework to reference their core clocks. Proper support of
these clocks will be added later
Device tree example:
clocks {
#address-cells = <1>;
#size-cells = <1>;
ranges;
osc: oscillator {
compatible = "fixed-clock";
#clock-cells = <1>;
clock-frequency = <25000000>;
};
apb_clk: apb_clk {
compatible = "fixed-clock";
#clock-cells = <0>;
clock-frequency = <1000000000>;
};
periph_clk: periph_clk {
compatible = "fixed-clock";
#clock-cells = <0>;
clock-frequency = <500000000>;
};
};

38
Documentation/devicetree/bindings/clock/exynos4415-clock.txt Normal file
View File

@@ -0,0 +1,38 @@
* Samsung Exynos4415 Clock Controller
The Exynos4415 clock controller generates and supplies clock to various
consumer devices within the Exynos4415 SoC.
Required properties:
- compatible: should be one of the following:
- "samsung,exynos4415-cmu" - for the main system clocks controller
(CMU_LEFTBUS, CMU_RIGHTBUS, CMU_TOP, CMU_CPU clock domains).
- "samsung,exynos4415-cmu-dmc" - for the Exynos4415 SoC DRAM Memory
Controller (DMC) domain clock controller.
- reg: physical base address of the controller and length of memory mapped
region.
- #clock-cells: should be 1.
Each clock is assigned an identifier and client nodes can use this identifier
to specify the clock which they consume.
All available clocks are defined as preprocessor macros in
dt-bindings/clock/exynos4415.h header and can be used in device
tree sources.
Example 1: An example of a clock controller node is listed below.
cmu: clock-controller@10030000 {
compatible = "samsung,exynos4415-cmu";
reg = <0x10030000 0x18000>;
#clock-cells = <1>;
};
cmu-dmc: clock-controller@105C0000 {
compatible = "samsung,exynos4415-cmu-dmc";
reg = <0x105C0000 0x3000>;
#clock-cells = <1>;
};

93
Documentation/devicetree/bindings/clock/exynos7-clock.txt Normal file
View File

@@ -0,0 +1,93 @@
* Samsung Exynos7 Clock Controller
Exynos7 clock controller has various blocks which are instantiated
independently from the device-tree. These clock controllers
generate and supply clocks to various hardware blocks within
the SoC.
Each clock is assigned an identifier and client nodes can use
this identifier to specify the clock which they consume. All
available clocks are defined as preprocessor macros in
dt-bindings/clock/exynos7-clk.h header and can be used in
device tree sources.
External clocks:
There are several clocks that are generated outside the SoC. It
is expected that they are defined using standard clock bindings
with following clock-output-names:
- "fin_pll" - PLL input clock from XXTI
Required Properties for Clock Controller:
- compatible: clock controllers will use one of the following
compatible strings to indicate the clock controller
functionality.
- "samsung,exynos7-clock-topc"
- "samsung,exynos7-clock-top0"
- "samsung,exynos7-clock-top1"
- "samsung,exynos7-clock-ccore"
- "samsung,exynos7-clock-peric0"
- "samsung,exynos7-clock-peric1"
- "samsung,exynos7-clock-peris"
- "samsung,exynos7-clock-fsys0"
- "samsung,exynos7-clock-fsys1"
- reg: physical base address of the controller and the length of
memory mapped region.
- #clock-cells: should be 1.
- clocks: list of clock identifiers which are fed as the input to
the given clock controller. Please refer the next section to
find the input clocks for a given controller.
- clock-names: list of names of clocks which are fed as the input
to the given clock controller.
Input clocks for top0 clock controller:
- fin_pll
- dout_sclk_bus0_pll
- dout_sclk_bus1_pll
- dout_sclk_cc_pll
- dout_sclk_mfc_pll
Input clocks for top1 clock controller:
- fin_pll
- dout_sclk_bus0_pll
- dout_sclk_bus1_pll
- dout_sclk_cc_pll
- dout_sclk_mfc_pll
Input clocks for ccore clock controller:
- fin_pll
- dout_aclk_ccore_133
Input clocks for peric0 clock controller:
- fin_pll
- dout_aclk_peric0_66
- sclk_uart0
Input clocks for peric1 clock controller:
- fin_pll
- dout_aclk_peric1_66
- sclk_uart1
- sclk_uart2
- sclk_uart3
Input clocks for peris clock controller:
- fin_pll
- dout_aclk_peris_66
Input clocks for fsys0 clock controller:
- fin_pll
- dout_aclk_fsys0_200
- dout_sclk_mmc2
Input clocks for fsys1 clock controller:
- fin_pll
- dout_aclk_fsys1_200
- dout_sclk_mmc0
- dout_sclk_mmc1

21
Documentation/devicetree/bindings/clock/marvell,mmp2.txt Normal file
View File

@@ -0,0 +1,21 @@
* Marvell MMP2 Clock Controller
The MMP2 clock subsystem generates and supplies clock to various
controllers within the MMP2 SoC.
Required Properties:
- compatible: should be one of the following.
- "marvell,mmp2-clock" - controller compatible with MMP2 SoC.
- reg: physical base address of the clock subsystem and length of memory mapped
region. There are 3 places in SOC has clock control logic:
"mpmu", "apmu", "apbc". So three reg spaces need to be defined.
- #clock-cells: should be 1.
- #reset-cells: should be 1.
Each clock is assigned an identifier and client nodes use this identifier
to specify the clock which they consume.
All these identifier could be found in <dt-bindings/clock/marvell-mmp2.h>.

21
Documentation/devicetree/bindings/clock/marvell,pxa168.txt Normal file
View File

@@ -0,0 +1,21 @@
* Marvell PXA168 Clock Controller
The PXA168 clock subsystem generates and supplies clock to various
controllers within the PXA168 SoC.
Required Properties:
- compatible: should be one of the following.
- "marvell,pxa168-clock" - controller compatible with PXA168 SoC.
- reg: physical base address of the clock subsystem and length of memory mapped
region. There are 3 places in SOC has clock control logic:
"mpmu", "apmu", "apbc". So three reg spaces need to be defined.
- #clock-cells: should be 1.
- #reset-cells: should be 1.
Each clock is assigned an identifier and client nodes use this identifier
to specify the clock which they consume.
All these identifier could be found in <dt-bindings/clock/marvell,pxa168.h>.

21
Documentation/devicetree/bindings/clock/marvell,pxa910.txt Normal file
View File

@@ -0,0 +1,21 @@
* Marvell PXA910 Clock Controller
The PXA910 clock subsystem generates and supplies clock to various
controllers within the PXA910 SoC.
Required Properties:
- compatible: should be one of the following.
- "marvell,pxa910-clock" - controller compatible with PXA910 SoC.
- reg: physical base address of the clock subsystem and length of memory mapped
region. There are 4 places in SOC has clock control logic:
"mpmu", "apmu", "apbc", "apbcp". So four reg spaces need to be defined.
- #clock-cells: should be 1.
- #reset-cells: should be 1.
Each clock is assigned an identifier and client nodes use this identifier
to specify the clock which they consume.
All these identifier could be found in <dt-bindings/clock/marvell-pxa910.h>.

14
Documentation/devicetree/bindings/clock/qoriq-clock.txt
View File

@@ -62,6 +62,8 @@ Required properties:
It takes parent's clock-frequency as its clock.
* "fsl,qoriq-sysclk-2.0": for input system clock (v2.0).
It takes parent's clock-frequency as its clock.
* "fsl,qoriq-platform-pll-1.0" for the platform PLL clock (v1.0)
* "fsl,qoriq-platform-pll-2.0" for the platform PLL clock (v2.0)
- #clock-cells: From common clock binding. The number of cells in a
clock-specifier. Should be <0> for "fsl,qoriq-sysclk-[1,2].0"
clocks, or <1> for "fsl,qoriq-core-pll-[1,2].0" clocks.
@@ -128,8 +130,16 @@ Example for clock block and clock provider:
clock-names = "pll0", "pll0-div2", "pll1", "pll1-div2";
clock-output-names = "cmux1";
};
platform-pll: platform-pll@c00 {
#clock-cells = <1>;
reg = <0xc00 0x4>;
compatible = "fsl,qoriq-platform-pll-1.0";
clocks = <&sysclk>;
clock-output-names = "platform-pll", "platform-pll-div2";
};
};
}
};
Example for clock consumer:
@@ -139,4 +149,4 @@ Example for clock consumer:
clocks = <&mux0>;
...
};
}
};

18
Documentation/devicetree/bindings/clock/renesas,cpg-div6-clocks.txt
View File

@@ -7,11 +7,16 @@ to 64.
Required Properties:
- compatible: Must be one of the following
- "renesas,r8a73a4-div6-clock" for R8A73A4 (R-Mobile APE6) DIV6 clocks
- "renesas,r8a7740-div6-clock" for R8A7740 (R-Mobile A1) DIV6 clocks
- "renesas,r8a7790-div6-clock" for R8A7790 (R-Car H2) DIV6 clocks
- "renesas,r8a7791-div6-clock" for R8A7791 (R-Car M2) DIV6 clocks
- "renesas,sh73a0-div6-clock" for SH73A0 (SH-Mobile AG5) DIV6 clocks
- "renesas,cpg-div6-clock" for generic DIV6 clocks
- reg: Base address and length of the memory resource used by the DIV6 clock
- clocks: Reference to the parent clock
- clocks: Reference to the parent clock(s); either one, four, or eight
clocks must be specified. For clocks with multiple parents, invalid
settings must be specified as "<0>".
- #clock-cells: Must be 0
- clock-output-names: The name of the clock as a free-form string
@@ -19,10 +24,11 @@ Required Properties:
Example
-------
sd2_clk: sd2_clk@e6150078 {
compatible = "renesas,r8a7790-div6-clock", "renesas,cpg-div6-clock";
reg = <0 0xe6150078 0 4>;
clocks = <&pll1_div2_clk>;
sdhi2_clk: sdhi2_clk@e615007c {
compatible = "renesas,r8a73a4-div6-clock", "renesas,cpg-div6-clock";
reg = <0 0xe615007c 0 4>;
clocks = <&pll1_div2_clk>, <&cpg_clocks R8A73A4_CLK_PLL2S>,
<0>, <&extal2_clk>;
#clock-cells = <0>;
clock-output-names = "sd2";
clock-output-names = "sdhi2ck";
};

8
Documentation/devicetree/bindings/clock/renesas,cpg-mstp-clocks.txt
View File

@@ -26,11 +26,11 @@ Required Properties:
must appear in the same order as the output clocks.
- #clock-cells: Must be 1
- clock-output-names: The name of the clocks as free-form strings
- renesas,clock-indices: Indices of the gate clocks into the group (0 to 31)
- clock-indices: Indices of the gate clocks into the group (0 to 31)
The clocks, clock-output-names and renesas,clock-indices properties contain one
entry per gate clock. The MSTP groups are sparsely populated. Unimplemented
gate clocks must not be declared.
The clocks, clock-output-names and clock-indices properties contain one entry
per gate clock. The MSTP groups are sparsely populated. Unimplemented gate
clocks must not be declared.
Example

2
Documentation/devicetree/bindings/clock/st/st,flexgen.txt
View File

@@ -11,7 +11,7 @@ Please find an example below:
Clockgen block diagram
-------------------------------------------------------------------
| Flexgen stucture |
| Flexgen structure |
| --------------------------------------------- |
| | ------- -------- -------- | |
clk_sysin | | | | | | | | |

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

@@ -10,14 +10,17 @@ Required properties:
"allwinner,sun4i-a10-pll1-clk" - for the main PLL clock and PLL4
"allwinner,sun6i-a31-pll1-clk" - for the main PLL clock on A31
"allwinner,sun8i-a23-pll1-clk" - for the main PLL clock on A23
"allwinner,sun9i-a80-pll4-clk" - for the peripheral PLLs on A80
"allwinner,sun4i-a10-pll5-clk" - for the PLL5 clock
"allwinner,sun4i-a10-pll6-clk" - for the PLL6 clock
"allwinner,sun6i-a31-pll6-clk" - for the PLL6 clock on A31
"allwinner,sun9i-a80-gt-clk" - for the GT bus clock on A80
"allwinner,sun4i-a10-cpu-clk" - for the CPU multiplexer clock
"allwinner,sun4i-a10-axi-clk" - for the AXI clock
"allwinner,sun8i-a23-axi-clk" - for the AXI clock on A23
"allwinner,sun4i-a10-axi-gates-clk" - for the AXI gates
"allwinner,sun4i-a10-ahb-clk" - for the AHB clock
"allwinner,sun9i-a80-ahb-clk" - for the AHB bus clocks on A80
"allwinner,sun4i-a10-ahb-gates-clk" - for the AHB gates on A10
"allwinner,sun5i-a13-ahb-gates-clk" - for the AHB gates on A13
"allwinner,sun5i-a10s-ahb-gates-clk" - for the AHB gates on A10s
@@ -26,24 +29,29 @@ Required properties:
"allwinner,sun6i-a31-ahb1-mux-clk" - for the AHB1 multiplexer on A31
"allwinner,sun6i-a31-ahb1-gates-clk" - for the AHB1 gates on A31
"allwinner,sun8i-a23-ahb1-gates-clk" - for the AHB1 gates on A23
"allwinner,sun9i-a80-ahb0-gates-clk" - for the AHB0 gates on A80
"allwinner,sun9i-a80-ahb1-gates-clk" - for the AHB1 gates on A80
"allwinner,sun9i-a80-ahb2-gates-clk" - for the AHB2 gates on A80
"allwinner,sun4i-a10-apb0-clk" - for the APB0 clock
"allwinner,sun6i-a31-apb0-clk" - for the APB0 clock on A31
"allwinner,sun8i-a23-apb0-clk" - for the APB0 clock on A23
"allwinner,sun9i-a80-apb0-clk" - for the APB0 bus clock on A80
"allwinner,sun4i-a10-apb0-gates-clk" - for the APB0 gates on A10
"allwinner,sun5i-a13-apb0-gates-clk" - for the APB0 gates on A13
"allwinner,sun5i-a10s-apb0-gates-clk" - for the APB0 gates on A10s
"allwinner,sun6i-a31-apb0-gates-clk" - for the APB0 gates on A31
"allwinner,sun7i-a20-apb0-gates-clk" - for the APB0 gates on A20
"allwinner,sun8i-a23-apb0-gates-clk" - for the APB0 gates on A23
"allwinner,sun9i-a80-apb0-gates-clk" - for the APB0 gates on A80
"allwinner,sun4i-a10-apb1-clk" - for the APB1 clock
"allwinner,sun4i-a10-apb1-mux-clk" - for the APB1 clock muxing
"allwinner,sun9i-a80-apb1-clk" - for the APB1 bus clock on A80
"allwinner,sun4i-a10-apb1-gates-clk" - for the APB1 gates on A10
"allwinner,sun5i-a13-apb1-gates-clk" - for the APB1 gates on A13
"allwinner,sun5i-a10s-apb1-gates-clk" - for the APB1 gates on A10s
"allwinner,sun6i-a31-apb1-gates-clk" - for the APB1 gates on A31
"allwinner,sun7i-a20-apb1-gates-clk" - for the APB1 gates on A20
"allwinner,sun8i-a23-apb1-gates-clk" - for the APB1 gates on A23
"allwinner,sun6i-a31-apb2-div-clk" - for the APB2 gates on A31
"allwinner,sun9i-a80-apb1-gates-clk" - for the APB1 gates on A80
"allwinner,sun6i-a31-apb2-gates-clk" - for the APB2 gates on A31
"allwinner,sun8i-a23-apb2-gates-clk" - for the APB2 gates on A23
"allwinner,sun5i-a13-mbus-clk" - for the MBUS clock on A13
@@ -63,8 +71,9 @@ Required properties for all clocks:
multiplexed clocks, the list order must match the hardware
programming order.
- #clock-cells : from common clock binding; shall be set to 0 except for
"allwinner,*-gates-clk", "allwinner,sun4i-pll5-clk" and
"allwinner,sun4i-pll6-clk" where it shall be set to 1
the following compatibles where it shall be set to 1:
"allwinner,*-gates-clk", "allwinner,sun4i-pll5-clk",
"allwinner,sun4i-pll6-clk", "allwinner,sun6i-a31-pll6-clk"
- clock-output-names : shall be the corresponding names of the outputs.
If the clock module only has one output, the name shall be the
module name.
@@ -79,6 +88,12 @@ Clock consumers should specify the desired clocks they use with a
"clocks" phandle cell. Consumers that are using a gated clock should
provide an additional ID in their clock property. This ID is the
offset of the bit controlling this particular gate in the register.
For the other clocks with "#clock-cells" = 1, the additional ID shall
refer to the index of the output.
For "allwinner,sun6i-a31-pll6-clk", there are 2 outputs. The first output
is the normal PLL6 output, or "pll6". The second output is rate doubled
PLL6, or "pll6x2".
For example:
@@ -106,6 +121,14 @@ pll5: clk@01c20020 {
clock-output-names = "pll5_ddr", "pll5_other";
};
pll6: clk@01c20028 {
#clock-cells = <1>;
compatible = "allwinner,sun6i-a31-pll6-clk";
reg = <0x01c20028 0x4>;
clocks = <&osc24M>;
clock-output-names = "pll6", "pll6x2";
};
cpu: cpu@01c20054 {
#clock-cells = <0>;
compatible = "allwinner,sun4i-a10-cpu-clk";

15
Documentation/devicetree/bindings/clock/vf610-clock.txt
View File

@@ -5,6 +5,19 @@ Required properties:
- reg: Address and length of the register set
- #clock-cells: Should be <1>
Optional properties:
- clocks: list of clock identifiers which are external input clocks to the
given clock controller. Please refer the next section to find
the input clocks for a given controller.
- clock-names: list of names of clocks which are exteral input clocks to the
given clock controller.
Input clocks for top clock controller:
- sxosc (external crystal oscillator 32KHz, recommended)
- fxosc (external crystal oscillator 24MHz, recommended)
- audio_ext
- enet_ext
The clock consumer should specify the desired clock by having the clock
ID in its "clocks" phandle cell. See include/dt-bindings/clock/vf610-clock.h
for the full list of VF610 clock IDs.
@@ -15,6 +28,8 @@ clks: ccm@4006b000 {
compatible = "fsl,vf610-ccm";
reg = <0x4006b000 0x1000>;
#clock-cells = <1>;
clocks = <&sxosc>, <&fxosc>;
clock-names = "sxosc", "fxosc";
};
uart1: serial@40028000 {

2
Documentation/devicetree/bindings/crypto/fsl-imx-sahara.txt
View File

@@ -1,5 +1,5 @@
Freescale SAHARA Cryptographic Accelerator included in some i.MX chips.
Currently only i.MX27 is supported.
Currently only i.MX27 and i.MX53 are supported.
Required properties:
- compatible : Should be "fsl,<soc>-sahara"

54
Documentation/devicetree/bindings/dma/atmel-xdma.txt Normal file
View File

@@ -0,0 +1,54 @@
* Atmel Extensible Direct Memory Access Controller (XDMAC)
* XDMA Controller
Required properties:
- compatible: Should be "atmel,<chip>-dma".
<chip> compatible description:
- sama5d4: first SoC adding the XDMAC
- reg: Should contain DMA registers location and length.
- interrupts: Should contain DMA interrupt.
- #dma-cells: Must be <1>, used to represent the number of integer cells in
the dmas property of client devices.
- The 1st cell specifies the channel configuration register:
- bit 13: SIF, source interface identifier, used to get the memory
interface identifier,
- bit 14: DIF, destination interface identifier, used to get the peripheral
interface identifier,
- bit 30-24: PERID, peripheral identifier.
Example:
dma1: dma-controller@f0004000 {
compatible = "atmel,sama5d4-dma";
reg = <0xf0004000 0x200>;
interrupts = <50 4 0>;
#dma-cells = <1>;
};
* DMA clients
DMA clients connected to the Atmel XDMA controller must use the format
described in the dma.txt file, using a one-cell specifier for each channel.
The two cells in order are:
1. A phandle pointing to the DMA controller.
2. Channel configuration register. Configurable fields are:
- bit 13: SIF, source interface identifier, used to get the memory
interface identifier,
- bit 14: DIF, destination interface identifier, used to get the peripheral
interface identifier,
- bit 30-24: PERID, peripheral identifier.
Example:
i2c2: i2c@f8024000 {
compatible = "atmel,at91sam9x5-i2c";
reg = <0xf8024000 0x4000>;
interrupts = <34 4 6>;
dmas = <&dma1
(AT91_XDMAC_DT_MEM_IF(0) | AT91_XDMAC_DT_PER_IF(1)
| AT91_XDMAC_DT_PERID(6))>,
<&dma1
(AT91_XDMAC_DT_MEM_IF(0) | AT91_XDMAC_DT_PER_IF(1)
| AT91_XDMAC_DT_PERID(7))>;
dma-names = "tx", "rx";
};

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