Fixes for 3.19
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAABCAAGBQJUoD2fAAoJEOa/DcumaUyE3XwQAKf2Jo0m0YyFYSNkN9tu1JAX jpqhI/wTXwpvQCIGt1pexLc21/mpPGlmXMvppf+Qc/NiM6OWT3b3lkTfoVTSNrRW k841CuBIjFe+03TF3L7L836eGiccjMtQIMDKG8D9ndK8ZV5gGRpJCtOp1oPfrwAQ uZmidH4NzyURH1v8CrfIFKksNwDAdb0KKCWC0xibpR5TrhPyJVo3Z60umjch7U8U 476/5JRU6w8IMzEfQU9/yamxEQGpCTxOsoqTvpsG5nqC45YFh8SCHdTi6v8E6jrY kvBh2AwgBsH5oi1VQ4JotsageMgA4h5k+jsMIfm1wqWgTWNtMuDU8mSHvRFN8nRY 6pi9G5KYLPZnGBNHUB+7g6MqPDBFHKh/xQw2lyWtGnVwbavXVE/gCeo3mhwmmyZR 2hhCiD1knExoHVueb+akDzNqnaTkjQjr1rXY4leq2PoLuLYlSDKor6PiAJ/tHq4r LhYCzVpTFmQuRC5alczrD0aHCb927IHpimKax2TuzGO/YiuefdgKo/StNAWwANYJ yGasVwRp5ew/sWhCgbykl+5wYnp3xoy+BMFzxyDiX4h4aeTzXfa4ii1QzEKmVbyh CyfVIlA30Lz4wf9zK7zUyV6kYu9d11Co5uctwulXSWsX/pKVYbmxuoHo9FSnZ36c KrFz6J6sYzF87FWXRh4H =5CnD -----END PGP SIGNATURE----- Merge tag 'mvebu-fixes-3.19' of git://git.infradead.org/linux-mvebu into fixes Pull "Fixes for 3.19" from Andrew Lunn: Jason is taking a back seat this cycle and i'm doing all the patch wrangling for mvebu. * tag 'mvebu-fixes-3.19' of git://git.infradead.org/linux-mvebu: ARM: mvebu: Fix pinctrl configuration for Armada 370 DB Also update to Linux 3.19-rc1, which this was based on. Signed-off-by: Arnd Bergmann <arnd@arndb.de>hifive-unleashed-5.1
Arnd Bergmann
commit
7ebdfaa52d
|
|
@ -96,3 +96,6 @@ x509.genkey
|
|||
|
||||
# Kconfig presets
|
||||
all.config
|
||||
|
||||
# Kdevelop4
|
||||
*.kdev4
|
||||
|
|
|
|||
4
.mailmap
4
.mailmap
|
|
@ -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>
|
||||
|
|
@ -102,6 +102,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>
|
||||
|
|
|
|||
13
CREDITS
13
CREDITS
|
|
@ -1197,6 +1197,13 @@ S: R. Tocantins, 89 - Cristo Rei
|
|||
S: 80050-430 - Curitiba - Paraná
|
||||
S: Brazil
|
||||
|
||||
N: Oded Gabbay
|
||||
E: oded.gabbay@gmail.com
|
||||
D: AMD KFD maintainer
|
||||
S: 12 Shraga Raphaeli
|
||||
S: Petah-Tikva, 4906418
|
||||
S: Israel
|
||||
|
||||
N: Kumar Gala
|
||||
E: galak@kernel.crashing.org
|
||||
D: Embedded PowerPC 6xx/7xx/74xx/82xx/83xx/85xx support
|
||||
|
|
@ -1727,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
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
|
|
|
|||
|
|
@ -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:
|
||||
|
|
@ -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
|
||||
|
|
@ -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
|
||||
|
|
@ -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).
|
||||
|
|
@ -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.
|
||||
|
|
@ -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.
|
||||
|
|
@ -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.
|
||||
|
|
@ -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.
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
|
|
@ -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
|
||||
--------
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
File diff suppressed because it is too large
Load Diff
|
|
@ -492,10 +492,10 @@ char *date;</synopsis>
|
|||
<sect2>
|
||||
<title>The Translation Table Manager (TTM)</title>
|
||||
<para>
|
||||
TTM design background and information belongs here.
|
||||
TTM design background and information belongs here.
|
||||
</para>
|
||||
<sect3>
|
||||
<title>TTM initialization</title>
|
||||
<title>TTM initialization</title>
|
||||
<warning><para>This section is outdated.</para></warning>
|
||||
<para>
|
||||
Drivers wishing to support TTM must fill out a drm_bo_driver
|
||||
|
|
@ -503,42 +503,42 @@ char *date;</synopsis>
|
|||
pointers for initializing the TTM, allocating and freeing memory,
|
||||
waiting for command completion and fence synchronization, and memory
|
||||
migration. See the radeon_ttm.c file for an example of usage.
|
||||
</para>
|
||||
<para>
|
||||
The ttm_global_reference structure is made up of several fields:
|
||||
</para>
|
||||
<programlisting>
|
||||
struct ttm_global_reference {
|
||||
enum ttm_global_types global_type;
|
||||
size_t size;
|
||||
void *object;
|
||||
int (*init) (struct ttm_global_reference *);
|
||||
void (*release) (struct ttm_global_reference *);
|
||||
};
|
||||
</programlisting>
|
||||
<para>
|
||||
There should be one global reference structure for your memory
|
||||
manager as a whole, and there will be others for each object
|
||||
created by the memory manager at runtime. Your global TTM should
|
||||
have a type of TTM_GLOBAL_TTM_MEM. The size field for the global
|
||||
object should be sizeof(struct ttm_mem_global), and the init and
|
||||
release hooks should point at your driver-specific init and
|
||||
release routines, which probably eventually call
|
||||
ttm_mem_global_init and ttm_mem_global_release, respectively.
|
||||
</para>
|
||||
<para>
|
||||
Once your global TTM accounting structure is set up and initialized
|
||||
by calling ttm_global_item_ref() on it,
|
||||
you need to create a buffer object TTM to
|
||||
provide a pool for buffer object allocation by clients and the
|
||||
kernel itself. The type of this object should be TTM_GLOBAL_TTM_BO,
|
||||
and its size should be sizeof(struct ttm_bo_global). Again,
|
||||
driver-specific init and release functions may be provided,
|
||||
likely eventually calling ttm_bo_global_init() and
|
||||
ttm_bo_global_release(), respectively. Also, like the previous
|
||||
object, ttm_global_item_ref() is used to create an initial reference
|
||||
count for the TTM, which will call your initialization function.
|
||||
</para>
|
||||
</para>
|
||||
<para>
|
||||
The ttm_global_reference structure is made up of several fields:
|
||||
</para>
|
||||
<programlisting>
|
||||
struct ttm_global_reference {
|
||||
enum ttm_global_types global_type;
|
||||
size_t size;
|
||||
void *object;
|
||||
int (*init) (struct ttm_global_reference *);
|
||||
void (*release) (struct ttm_global_reference *);
|
||||
};
|
||||
</programlisting>
|
||||
<para>
|
||||
There should be one global reference structure for your memory
|
||||
manager as a whole, and there will be others for each object
|
||||
created by the memory manager at runtime. Your global TTM should
|
||||
have a type of TTM_GLOBAL_TTM_MEM. The size field for the global
|
||||
object should be sizeof(struct ttm_mem_global), and the init and
|
||||
release hooks should point at your driver-specific init and
|
||||
release routines, which probably eventually call
|
||||
ttm_mem_global_init and ttm_mem_global_release, respectively.
|
||||
</para>
|
||||
<para>
|
||||
Once your global TTM accounting structure is set up and initialized
|
||||
by calling ttm_global_item_ref() on it,
|
||||
you need to create a buffer object TTM to
|
||||
provide a pool for buffer object allocation by clients and the
|
||||
kernel itself. The type of this object should be TTM_GLOBAL_TTM_BO,
|
||||
and its size should be sizeof(struct ttm_bo_global). Again,
|
||||
driver-specific init and release functions may be provided,
|
||||
likely eventually calling ttm_bo_global_init() and
|
||||
ttm_bo_global_release(), respectively. Also, like the previous
|
||||
object, ttm_global_item_ref() is used to create an initial reference
|
||||
count for the TTM, which will call your initialization function.
|
||||
</para>
|
||||
</sect3>
|
||||
</sect2>
|
||||
<sect2 id="drm-gem">
|
||||
|
|
@ -566,19 +566,19 @@ char *date;</synopsis>
|
|||
using driver-specific ioctls.
|
||||
</para>
|
||||
<para>
|
||||
On a fundamental level, GEM involves several operations:
|
||||
<itemizedlist>
|
||||
<listitem>Memory allocation and freeing</listitem>
|
||||
<listitem>Command execution</listitem>
|
||||
<listitem>Aperture management at command execution time</listitem>
|
||||
</itemizedlist>
|
||||
Buffer object allocation is relatively straightforward and largely
|
||||
On a fundamental level, GEM involves several operations:
|
||||
<itemizedlist>
|
||||
<listitem>Memory allocation and freeing</listitem>
|
||||
<listitem>Command execution</listitem>
|
||||
<listitem>Aperture management at command execution time</listitem>
|
||||
</itemizedlist>
|
||||
Buffer object allocation is relatively straightforward and largely
|
||||
provided by Linux's shmem layer, which provides memory to back each
|
||||
object.
|
||||
</para>
|
||||
<para>
|
||||
Device-specific operations, such as command execution, pinning, buffer
|
||||
read & write, mapping, and domain ownership transfers are left to
|
||||
read & write, mapping, and domain ownership transfers are left to
|
||||
driver-specific ioctls.
|
||||
</para>
|
||||
<sect3>
|
||||
|
|
@ -738,16 +738,16 @@ char *date;</synopsis>
|
|||
respectively. The conversion is handled by the DRM core without any
|
||||
driver-specific support.
|
||||
</para>
|
||||
<para>
|
||||
GEM also supports buffer sharing with dma-buf file descriptors through
|
||||
PRIME. GEM-based drivers must use the provided helpers functions to
|
||||
implement the exporting and importing correctly. See <xref linkend="drm-prime-support" />.
|
||||
Since sharing file descriptors is inherently more secure than the
|
||||
easily guessable and global GEM names it is the preferred buffer
|
||||
sharing mechanism. Sharing buffers through GEM names is only supported
|
||||
for legacy userspace. Furthermore PRIME also allows cross-device
|
||||
buffer sharing since it is based on dma-bufs.
|
||||
</para>
|
||||
<para>
|
||||
GEM also supports buffer sharing with dma-buf file descriptors through
|
||||
PRIME. GEM-based drivers must use the provided helpers functions to
|
||||
implement the exporting and importing correctly. See <xref linkend="drm-prime-support" />.
|
||||
Since sharing file descriptors is inherently more secure than the
|
||||
easily guessable and global GEM names it is the preferred buffer
|
||||
sharing mechanism. Sharing buffers through GEM names is only supported
|
||||
for legacy userspace. Furthermore PRIME also allows cross-device
|
||||
buffer sharing since it is based on dma-bufs.
|
||||
</para>
|
||||
</sect3>
|
||||
<sect3 id="drm-gem-objects-mapping">
|
||||
<title>GEM Objects Mapping</title>
|
||||
|
|
@ -852,7 +852,7 @@ char *date;</synopsis>
|
|||
<sect3>
|
||||
<title>Command Execution</title>
|
||||
<para>
|
||||
Perhaps the most important GEM function for GPU devices is providing a
|
||||
Perhaps the most important GEM function for GPU devices is providing a
|
||||
command execution interface to clients. Client programs construct
|
||||
command buffers containing references to previously allocated memory
|
||||
objects, and then submit them to GEM. At that point, GEM takes care to
|
||||
|
|
@ -874,95 +874,101 @@ char *date;</synopsis>
|
|||
<title>GEM Function Reference</title>
|
||||
!Edrivers/gpu/drm/drm_gem.c
|
||||
</sect3>
|
||||
</sect2>
|
||||
<sect2>
|
||||
<title>VMA Offset Manager</title>
|
||||
</sect2>
|
||||
<sect2>
|
||||
<title>VMA Offset Manager</title>
|
||||
!Pdrivers/gpu/drm/drm_vma_manager.c vma offset manager
|
||||
!Edrivers/gpu/drm/drm_vma_manager.c
|
||||
!Iinclude/drm/drm_vma_manager.h
|
||||
</sect2>
|
||||
<sect2 id="drm-prime-support">
|
||||
<title>PRIME Buffer Sharing</title>
|
||||
<para>
|
||||
PRIME is the cross device buffer sharing framework in drm, originally
|
||||
created for the OPTIMUS range of multi-gpu platforms. To userspace
|
||||
PRIME buffers are dma-buf based file descriptors.
|
||||
</para>
|
||||
<sect3>
|
||||
<title>Overview and Driver Interface</title>
|
||||
<para>
|
||||
Similar to GEM global names, PRIME file descriptors are
|
||||
also used to share buffer objects across processes. They offer
|
||||
additional security: as file descriptors must be explicitly sent over
|
||||
UNIX domain sockets to be shared between applications, they can't be
|
||||
guessed like the globally unique GEM names.
|
||||
</para>
|
||||
<para>
|
||||
Drivers that support the PRIME
|
||||
API must set the DRIVER_PRIME bit in the struct
|
||||
<structname>drm_driver</structname>
|
||||
<structfield>driver_features</structfield> field, and implement the
|
||||
<methodname>prime_handle_to_fd</methodname> and
|
||||
<methodname>prime_fd_to_handle</methodname> operations.
|
||||
</para>
|
||||
<para>
|
||||
<synopsis>int (*prime_handle_to_fd)(struct drm_device *dev,
|
||||
struct drm_file *file_priv, uint32_t handle,
|
||||
uint32_t flags, int *prime_fd);
|
||||
</sect2>
|
||||
<sect2 id="drm-prime-support">
|
||||
<title>PRIME Buffer Sharing</title>
|
||||
<para>
|
||||
PRIME is the cross device buffer sharing framework in drm, originally
|
||||
created for the OPTIMUS range of multi-gpu platforms. To userspace
|
||||
PRIME buffers are dma-buf based file descriptors.
|
||||
</para>
|
||||
<sect3>
|
||||
<title>Overview and Driver Interface</title>
|
||||
<para>
|
||||
Similar to GEM global names, PRIME file descriptors are
|
||||
also used to share buffer objects across processes. They offer
|
||||
additional security: as file descriptors must be explicitly sent over
|
||||
UNIX domain sockets to be shared between applications, they can't be
|
||||
guessed like the globally unique GEM names.
|
||||
</para>
|
||||
<para>
|
||||
Drivers that support the PRIME
|
||||
API must set the DRIVER_PRIME bit in the struct
|
||||
<structname>drm_driver</structname>
|
||||
<structfield>driver_features</structfield> field, and implement the
|
||||
<methodname>prime_handle_to_fd</methodname> and
|
||||
<methodname>prime_fd_to_handle</methodname> operations.
|
||||
</para>
|
||||
<para>
|
||||
<synopsis>int (*prime_handle_to_fd)(struct drm_device *dev,
|
||||
struct drm_file *file_priv, uint32_t handle,
|
||||
uint32_t flags, int *prime_fd);
|
||||
int (*prime_fd_to_handle)(struct drm_device *dev,
|
||||
struct drm_file *file_priv, int prime_fd,
|
||||
uint32_t *handle);</synopsis>
|
||||
Those two operations convert a handle to a PRIME file descriptor and
|
||||
vice versa. Drivers must use the kernel dma-buf buffer sharing framework
|
||||
to manage the PRIME file descriptors. Similar to the mode setting
|
||||
API PRIME is agnostic to the underlying buffer object manager, as
|
||||
long as handles are 32bit unsigned integers.
|
||||
</para>
|
||||
<para>
|
||||
While non-GEM drivers must implement the operations themselves, GEM
|
||||
drivers must use the <function>drm_gem_prime_handle_to_fd</function>
|
||||
and <function>drm_gem_prime_fd_to_handle</function> helper functions.
|
||||
Those helpers rely on the driver
|
||||
<methodname>gem_prime_export</methodname> and
|
||||
<methodname>gem_prime_import</methodname> operations to create a dma-buf
|
||||
instance from a GEM object (dma-buf exporter role) and to create a GEM
|
||||
object from a dma-buf instance (dma-buf importer role).
|
||||
</para>
|
||||
<para>
|
||||
<synopsis>struct dma_buf * (*gem_prime_export)(struct drm_device *dev,
|
||||
struct drm_gem_object *obj,
|
||||
int flags);
|
||||
struct drm_file *file_priv, int prime_fd,
|
||||
uint32_t *handle);</synopsis>
|
||||
Those two operations convert a handle to a PRIME file descriptor and
|
||||
vice versa. Drivers must use the kernel dma-buf buffer sharing framework
|
||||
to manage the PRIME file descriptors. Similar to the mode setting
|
||||
API PRIME is agnostic to the underlying buffer object manager, as
|
||||
long as handles are 32bit unsigned integers.
|
||||
</para>
|
||||
<para>
|
||||
While non-GEM drivers must implement the operations themselves, GEM
|
||||
drivers must use the <function>drm_gem_prime_handle_to_fd</function>
|
||||
and <function>drm_gem_prime_fd_to_handle</function> helper functions.
|
||||
Those helpers rely on the driver
|
||||
<methodname>gem_prime_export</methodname> and
|
||||
<methodname>gem_prime_import</methodname> operations to create a dma-buf
|
||||
instance from a GEM object (dma-buf exporter role) and to create a GEM
|
||||
object from a dma-buf instance (dma-buf importer role).
|
||||
</para>
|
||||
<para>
|
||||
<synopsis>struct dma_buf * (*gem_prime_export)(struct drm_device *dev,
|
||||
struct drm_gem_object *obj,
|
||||
int flags);
|
||||
struct drm_gem_object * (*gem_prime_import)(struct drm_device *dev,
|
||||
struct dma_buf *dma_buf);</synopsis>
|
||||
These two operations are mandatory for GEM drivers that support
|
||||
PRIME.
|
||||
</para>
|
||||
</sect3>
|
||||
<sect3>
|
||||
<title>PRIME Helper Functions</title>
|
||||
!Pdrivers/gpu/drm/drm_prime.c PRIME Helpers
|
||||
struct dma_buf *dma_buf);</synopsis>
|
||||
These two operations are mandatory for GEM drivers that support
|
||||
PRIME.
|
||||
</para>
|
||||
</sect3>
|
||||
</sect2>
|
||||
<sect2>
|
||||
<title>PRIME Function References</title>
|
||||
<sect3>
|
||||
<title>PRIME Helper Functions</title>
|
||||
!Pdrivers/gpu/drm/drm_prime.c PRIME Helpers
|
||||
</sect3>
|
||||
</sect2>
|
||||
<sect2>
|
||||
<title>PRIME Function References</title>
|
||||
!Edrivers/gpu/drm/drm_prime.c
|
||||
</sect2>
|
||||
<sect2>
|
||||
<title>DRM MM Range Allocator</title>
|
||||
<sect3>
|
||||
<title>Overview</title>
|
||||
</sect2>
|
||||
<sect2>
|
||||
<title>DRM MM Range Allocator</title>
|
||||
<sect3>
|
||||
<title>Overview</title>
|
||||
!Pdrivers/gpu/drm/drm_mm.c Overview
|
||||
</sect3>
|
||||
<sect3>
|
||||
<title>LRU Scan/Eviction Support</title>
|
||||
</sect3>
|
||||
<sect3>
|
||||
<title>LRU Scan/Eviction Support</title>
|
||||
!Pdrivers/gpu/drm/drm_mm.c lru scan roaster
|
||||
</sect3>
|
||||
</sect3>
|
||||
</sect2>
|
||||
<sect2>
|
||||
<title>DRM MM Range Allocator Function References</title>
|
||||
<sect2>
|
||||
<title>DRM MM Range Allocator Function References</title>
|
||||
!Edrivers/gpu/drm/drm_mm.c
|
||||
!Iinclude/drm/drm_mm.h
|
||||
</sect2>
|
||||
</sect2>
|
||||
<sect2>
|
||||
<title>CMA Helper Functions Reference</title>
|
||||
!Pdrivers/gpu/drm/drm_gem_cma_helper.c cma helpers
|
||||
!Edrivers/gpu/drm/drm_gem_cma_helper.c
|
||||
!Iinclude/drm/drm_gem_cma_helper.h
|
||||
</sect2>
|
||||
</sect1>
|
||||
|
||||
<!-- Internals: mode setting -->
|
||||
|
|
@ -994,6 +1000,10 @@ int max_width, max_height;</synopsis>
|
|||
<title>Display Modes Function Reference</title>
|
||||
!Iinclude/drm/drm_modes.h
|
||||
!Edrivers/gpu/drm/drm_modes.c
|
||||
</sect2>
|
||||
<sect2>
|
||||
<title>Atomic Mode Setting Function Reference</title>
|
||||
!Edrivers/gpu/drm/drm_atomic.c
|
||||
</sect2>
|
||||
<sect2>
|
||||
<title>Frame Buffer Creation</title>
|
||||
|
|
@ -1825,6 +1835,10 @@ void intel_crt_init(struct drm_device *dev)
|
|||
<sect2>
|
||||
<title>KMS API Functions</title>
|
||||
!Edrivers/gpu/drm/drm_crtc.c
|
||||
</sect2>
|
||||
<sect2>
|
||||
<title>KMS Data Structures</title>
|
||||
!Iinclude/drm/drm_crtc.h
|
||||
</sect2>
|
||||
<sect2>
|
||||
<title>KMS Locking</title>
|
||||
|
|
@ -1933,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>
|
||||
|
|
@ -2076,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.
|
||||
|
|
@ -2278,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
|
||||
|
|
@ -2315,9 +2343,27 @@ void intel_crt_init(struct drm_device *dev)
|
|||
</listitem>
|
||||
</itemizedlist>
|
||||
</sect2>
|
||||
<sect2>
|
||||
<title>Atomic Modeset Helper Functions Reference</title>
|
||||
<sect3>
|
||||
<title>Overview</title>
|
||||
!Pdrivers/gpu/drm/drm_atomic_helper.c overview
|
||||
</sect3>
|
||||
<sect3>
|
||||
<title>Implementing Asynchronous Atomic Commit</title>
|
||||
!Pdrivers/gpu/drm/drm_atomic_helper.c implementing async commit
|
||||
</sect3>
|
||||
<sect3>
|
||||
<title>Atomic State Reset and Initialization</title>
|
||||
!Pdrivers/gpu/drm/drm_atomic_helper.c atomic state reset and initialization
|
||||
</sect3>
|
||||
!Iinclude/drm/drm_atomic_helper.h
|
||||
!Edrivers/gpu/drm/drm_atomic_helper.c
|
||||
</sect2>
|
||||
<sect2>
|
||||
<title>Modeset Helper Functions Reference</title>
|
||||
!Edrivers/gpu/drm/drm_crtc_helper.c
|
||||
!Pdrivers/gpu/drm/drm_crtc_helper.c overview
|
||||
</sect2>
|
||||
<sect2>
|
||||
<title>Output Probing Helper Functions Reference</title>
|
||||
|
|
@ -2341,6 +2387,12 @@ void intel_crt_init(struct drm_device *dev)
|
|||
!Pdrivers/gpu/drm/drm_dp_mst_topology.c dp mst helper
|
||||
!Iinclude/drm/drm_dp_mst_helper.h
|
||||
!Edrivers/gpu/drm/drm_dp_mst_topology.c
|
||||
</sect2>
|
||||
<sect2>
|
||||
<title>MIPI DSI Helper Functions Reference</title>
|
||||
!Pdrivers/gpu/drm/drm_mipi_dsi.c dsi helpers
|
||||
!Iinclude/drm/drm_mipi_dsi.h
|
||||
!Edrivers/gpu/drm/drm_mipi_dsi.c
|
||||
</sect2>
|
||||
<sect2>
|
||||
<title>EDID Helper Functions Reference</title>
|
||||
|
|
@ -2371,7 +2423,12 @@ void intel_crt_init(struct drm_device *dev)
|
|||
</sect2>
|
||||
<sect2>
|
||||
<title id="drm-kms-planehelpers">Plane Helper Reference</title>
|
||||
!Edrivers/gpu/drm/drm_plane_helper.c Plane Helpers
|
||||
!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>
|
||||
|
||||
|
|
@ -2507,8 +2564,8 @@ void intel_crt_init(struct drm_device *dev)
|
|||
<td valign="top" >Description/Restrictions</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td rowspan="21" valign="top" >DRM</td>
|
||||
<td rowspan="2" 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>
|
||||
|
|
@ -2523,6 +2580,20 @@ void intel_crt_init(struct drm_device *dev)
|
|||
<td valign="top" >Contains DPMS operation mode value.</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td valign="top" >“PATH”</td>
|
||||
<td valign="top" >BLOB | IMMUTABLE</td>
|
||||
<td valign="top" >0</td>
|
||||
<td valign="top" >Connector</td>
|
||||
<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>
|
||||
|
|
@ -2638,6 +2709,21 @@ void intel_crt_init(struct drm_device *dev)
|
|||
<td valign="top" >TBD</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td rowspan="2" valign="top" >Virtual GPU</td>
|
||||
<td valign="top" >“suggested X”</td>
|
||||
<td valign="top" >RANGE</td>
|
||||
<td valign="top" >Min=0, Max=0xffffffff</td>
|
||||
<td valign="top" >Connector</td>
|
||||
<td valign="top" >property to suggest an X offset for a connector</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td valign="top" >“suggested Y”</td>
|
||||
<td valign="top" >RANGE</td>
|
||||
<td valign="top" >Min=0, Max=0xffffffff</td>
|
||||
<td valign="top" >Connector</td>
|
||||
<td valign="top" >property to suggest an Y offset for a connector</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td rowspan="3" valign="top" >Optional</td>
|
||||
<td valign="top" >“scaling mode”</td>
|
||||
<td valign="top" >ENUM</td>
|
||||
|
|
@ -3787,6 +3873,26 @@ int num_ioctls;</synopsis>
|
|||
blocks. This excludes a set of SoC platforms with an SGX rendering unit,
|
||||
those have basic support through the gma500 drm driver.
|
||||
</para>
|
||||
<sect1>
|
||||
<title>Core Driver Infrastructure</title>
|
||||
<para>
|
||||
This section covers core driver infrastructure used by both the display
|
||||
and the GEM parts of the driver.
|
||||
</para>
|
||||
<sect2>
|
||||
<title>Runtime Power Management</title>
|
||||
!Pdrivers/gpu/drm/i915/intel_runtime_pm.c runtime pm
|
||||
!Idrivers/gpu/drm/i915/intel_runtime_pm.c
|
||||
</sect2>
|
||||
<sect2>
|
||||
<title>Interrupt Handling</title>
|
||||
!Pdrivers/gpu/drm/i915/i915_irq.c interrupt handling
|
||||
!Fdrivers/gpu/drm/i915/i915_irq.c intel_irq_init intel_irq_init_hw intel_hpd_init
|
||||
!Fdrivers/gpu/drm/i915/i915_irq.c intel_irq_fini
|
||||
!Fdrivers/gpu/drm/i915/i915_irq.c intel_runtime_pm_disable_interrupts
|
||||
!Fdrivers/gpu/drm/i915/i915_irq.c intel_runtime_pm_enable_interrupts
|
||||
</sect2>
|
||||
</sect1>
|
||||
<sect1>
|
||||
<title>Display Hardware Handling</title>
|
||||
<para>
|
||||
|
|
@ -3803,6 +3909,18 @@ int num_ioctls;</synopsis>
|
|||
configuration change.
|
||||
</para>
|
||||
</sect2>
|
||||
<sect2>
|
||||
<title>Frontbuffer Tracking</title>
|
||||
!Pdrivers/gpu/drm/i915/intel_frontbuffer.c frontbuffer tracking
|
||||
!Idrivers/gpu/drm/i915/intel_frontbuffer.c
|
||||
!Fdrivers/gpu/drm/i915/intel_drv.h intel_frontbuffer_flip
|
||||
!Fdrivers/gpu/drm/i915/i915_gem.c i915_gem_track_fb
|
||||
</sect2>
|
||||
<sect2>
|
||||
<title>Display FIFO Underrun Reporting</title>
|
||||
!Pdrivers/gpu/drm/i915/intel_fifo_underrun.c fifo underrun handling
|
||||
!Idrivers/gpu/drm/i915/intel_fifo_underrun.c
|
||||
</sect2>
|
||||
<sect2>
|
||||
<title>Plane Configuration</title>
|
||||
<para>
|
||||
|
|
@ -3822,6 +3940,16 @@ int num_ioctls;</synopsis>
|
|||
probing, so those sections fully apply.
|
||||
</para>
|
||||
</sect2>
|
||||
<sect2>
|
||||
<title>High Definition Audio</title>
|
||||
!Pdrivers/gpu/drm/i915/intel_audio.c High Definition Audio over HDMI and Display Port
|
||||
!Idrivers/gpu/drm/i915/intel_audio.c
|
||||
</sect2>
|
||||
<sect2>
|
||||
<title>Panel Self Refresh PSR (PSR/SRD)</title>
|
||||
!Pdrivers/gpu/drm/i915/intel_psr.c Panel Self Refresh (PSR/SRD)
|
||||
!Idrivers/gpu/drm/i915/intel_psr.c
|
||||
</sect2>
|
||||
<sect2>
|
||||
<title>DPIO</title>
|
||||
!Pdrivers/gpu/drm/i915/i915_reg.h DPIO
|
||||
|
|
@ -3931,6 +4059,28 @@ int num_ioctls;</synopsis>
|
|||
!Idrivers/gpu/drm/i915/intel_lrc.c
|
||||
</sect2>
|
||||
</sect1>
|
||||
|
||||
<sect1>
|
||||
<title> Tracing </title>
|
||||
<para>
|
||||
This sections covers all things related to the tracepoints implemented in
|
||||
the i915 driver.
|
||||
</para>
|
||||
<sect2>
|
||||
<title> i915_ppgtt_create and i915_ppgtt_release </title>
|
||||
!Pdrivers/gpu/drm/i915/i915_trace.h i915_ppgtt_create and i915_ppgtt_release tracepoints
|
||||
</sect2>
|
||||
<sect2>
|
||||
<title> i915_context_create and i915_context_free </title>
|
||||
!Pdrivers/gpu/drm/i915/i915_trace.h i915_context_create and i915_context_free tracepoints
|
||||
</sect2>
|
||||
<sect2>
|
||||
<title> switch_mm </title>
|
||||
!Pdrivers/gpu/drm/i915/i915_trace.h switch_mm tracepoint
|
||||
</sect2>
|
||||
</sect1>
|
||||
|
||||
</chapter>
|
||||
!Cdrivers/gpu/drm/i915/i915_irq.c
|
||||
</part>
|
||||
</book>
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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© 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 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 Tech 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 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>
|
||||
|
|
|
|||
|
|
@ -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>
|
||||
|
||||
|
|
|
|||
|
|
@ -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>
|
||||
|
||||
|
|
|
|||
|
|
@ -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. 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>
|
||||
|
|
|
|||
File diff suppressed because it is too large
Load Diff
|
|
@ -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>
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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;
|
||||
|
|
|
|||
|
|
@ -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>
|
||||
|
|
|
|||
|
|
@ -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>
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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
|
||||
------------
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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; };
|
||||
|
|
|
|||
|
|
@ -942,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
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
||||
|
|
|
|||
|
|
@ -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 :)
|
||||
|
|
@ -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,
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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>
|
||||
|
|
@ -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>;
|
||||
};
|
||||
};
|
||||
};
|
||||
|
|
@ -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>;
|
||||
};
|
||||
};
|
||||
|
|
|
|||
|
|
@ -97,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>;
|
||||
};
|
||||
};
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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>;
|
||||
};
|
||||
|
|
@ -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,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>;
|
||||
}
|
||||
|
|
|
|||
|
|
@ -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>;
|
||||
};
|
||||
|
|
|
|||
|
|
@ -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>;
|
||||
};
|
||||
|
|
@ -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>;
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
|
|
@ -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>;
|
||||
};
|
||||
|
|
@ -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
|
||||
|
|
@ -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>.
|
||||
|
|
@ -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>.
|
||||
|
|
@ -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>.
|
||||
|
|
@ -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>;
|
||||
...
|
||||
};
|
||||
}
|
||||
};
|
||||
|
|
|
|||
|
|
@ -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";
|
||||
};
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -11,7 +11,7 @@ Please find an example below:
|
|||
|
||||
Clockgen block diagram
|
||||
-------------------------------------------------------------------
|
||||
| Flexgen stucture |
|
||||
| Flexgen structure |
|
||||
| --------------------------------------------- |
|
||||
| | ------- -------- -------- | |
|
||||
clk_sysin | | | | | | | | |
|
||||
|
|
|
|||
|
|
@ -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";
|
||||
|
|
|
|||
|
|
@ -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"
|
||||
|
|
|
|||
|
|
@ -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";
|
||||
};
|
||||
|
|
@ -48,6 +48,7 @@ The full ID of peripheral types can be found below.
|
|||
21 ESAI
|
||||
22 SSI Dual FIFO (needs firmware ver >= 2)
|
||||
23 Shared ASRC
|
||||
24 SAI
|
||||
|
||||
The third cell specifies the transfer priority as below.
|
||||
|
||||
|
|
|
|||
|
|
@ -1,7 +1,9 @@
|
|||
QCOM BAM DMA controller
|
||||
|
||||
Required properties:
|
||||
- compatible: must contain "qcom,bam-v1.4.0" for MSM8974
|
||||
- compatible: must be one of the following:
|
||||
* "qcom,bam-v1.4.0" for MSM8974, APQ8074 and APQ8084
|
||||
* "qcom,bam-v1.3.0" for APQ8064, IPQ8064 and MSM8960
|
||||
- reg: Address range for DMA registers
|
||||
- interrupts: Should contain the one interrupt shared by all channels
|
||||
- #dma-cells: must be <1>, the cell in the dmas property of the client device
|
||||
|
|
|
|||
|
|
@ -4,7 +4,7 @@ This driver follows the generic DMA bindings defined in dma.txt.
|
|||
|
||||
Required properties:
|
||||
|
||||
- compatible: Must be "allwinner,sun6i-a31-dma"
|
||||
- compatible: Must be "allwinner,sun6i-a31-dma" or "allwinner,sun8i-a23-dma"
|
||||
- reg: Should contain the registers base address and length
|
||||
- interrupts: Should contain a reference to the interrupt used by this device
|
||||
- clocks: Should contain a reference to the parent AHB clock
|
||||
|
|
|
|||
|
|
@ -0,0 +1,30 @@
|
|||
* 74XX MMIO GPIO driver
|
||||
|
||||
Required properties:
|
||||
- compatible: Should contain one of the following:
|
||||
"ti,741g125": for 741G125 (1-bit Input),
|
||||
"ti,741g174": for 741G74 (1-bit Output),
|
||||
"ti,742g125": for 742G125 (2-bit Input),
|
||||
"ti,7474" : for 7474 (2-bit Output),
|
||||
"ti,74125" : for 74125 (4-bit Input),
|
||||
"ti,74175" : for 74175 (4-bit Output),
|
||||
"ti,74365" : for 74365 (6-bit Input),
|
||||
"ti,74174" : for 74174 (6-bit Output),
|
||||
"ti,74244" : for 74244 (8-bit Input),
|
||||
"ti,74273" : for 74273 (8-bit Output),
|
||||
"ti,741624" : for 741624 (16-bit Input),
|
||||
"ti,7416374": for 7416374 (16-bit Output).
|
||||
- reg: Physical base address and length where IC resides.
|
||||
- gpio-controller: Marks the device node as a gpio controller.
|
||||
- #gpio-cells: Should be two. The first cell is the pin number and
|
||||
the second cell is used to specify the GPIO polarity:
|
||||
0 = Active High,
|
||||
1 = Active Low.
|
||||
|
||||
Example:
|
||||
ctrl: gpio@30008004 {
|
||||
compatible = "ti,74174";
|
||||
reg = <0x30008004 0x1>;
|
||||
gpio-controller;
|
||||
#gpio-cells = <2>;
|
||||
};
|
||||
|
|
@ -57,6 +57,8 @@ Optional device specific properties:
|
|||
occurred on. If it is not set, the interrupt are only generated for the
|
||||
bank they belong to.
|
||||
On devices with only one interrupt output this property is useless.
|
||||
- microchip,irq-active-high: Sets the INTPOL flag in the IOCON register. This
|
||||
configures the IRQ output polarity as active high.
|
||||
|
||||
Example I2C (with interrupt):
|
||||
gpiom1: gpio@20 {
|
||||
|
|
|
|||
|
|
@ -0,0 +1,55 @@
|
|||
* Freescale VF610 PORT/GPIO module
|
||||
|
||||
The Freescale PORT/GPIO modules are two adjacent modules providing GPIO
|
||||
functionality. Each pair serves 32 GPIOs. The VF610 has 5 instances of
|
||||
each, and each PORT module has its own interrupt.
|
||||
|
||||
Required properties for GPIO node:
|
||||
- compatible : Should be "fsl,<soc>-gpio", currently "fsl,vf610-gpio"
|
||||
- reg : The first reg tuple represents the PORT module, the second tuple
|
||||
the GPIO module.
|
||||
- interrupts : Should be the port interrupt shared by all 32 pins.
|
||||
- gpio-controller : Marks the device node as a gpio controller.
|
||||
- #gpio-cells : Should be two. The first cell is the pin number and
|
||||
the second cell is used to specify the gpio polarity:
|
||||
0 = active high
|
||||
1 = active low
|
||||
- interrupt-controller: Marks the device node as an interrupt controller.
|
||||
- #interrupt-cells : Should be 2. The first cell is the GPIO number.
|
||||
The second cell bits[3:0] is used to specify trigger type and level flags:
|
||||
1 = low-to-high edge triggered.
|
||||
2 = high-to-low edge triggered.
|
||||
4 = active high level-sensitive.
|
||||
8 = active low level-sensitive.
|
||||
|
||||
Note: Each GPIO port should have an alias correctly numbered in "aliases"
|
||||
node.
|
||||
|
||||
Examples:
|
||||
|
||||
aliases {
|
||||
gpio0 = &gpio1;
|
||||
gpio1 = &gpio2;
|
||||
};
|
||||
|
||||
gpio1: gpio@40049000 {
|
||||
compatible = "fsl,vf610-gpio";
|
||||
reg = <0x40049000 0x1000 0x400ff000 0x40>;
|
||||
interrupts = <0 107 IRQ_TYPE_LEVEL_HIGH>;
|
||||
gpio-controller;
|
||||
#gpio-cells = <2>;
|
||||
interrupt-controller;
|
||||
#interrupt-cells = <2>;
|
||||
gpio-ranges = <&iomuxc 0 0 32>;
|
||||
};
|
||||
|
||||
gpio2: gpio@4004a000 {
|
||||
compatible = "fsl,vf610-gpio";
|
||||
reg = <0x4004a000 0x1000 0x400ff040 0x40>;
|
||||
interrupts = <0 108 IRQ_TYPE_LEVEL_HIGH>;
|
||||
gpio-controller;
|
||||
#gpio-cells = <2>;
|
||||
interrupt-controller;
|
||||
#interrupt-cells = <2>;
|
||||
gpio-ranges = <&iomuxc 0 32 32>;
|
||||
};
|
||||
|
|
@ -13,13 +13,22 @@ properties, each containing a 'gpio-list':
|
|||
gpio-specifier : Array of #gpio-cells specifying specific gpio
|
||||
(controller specific)
|
||||
|
||||
GPIO properties should be named "[<name>-]gpios". The exact
|
||||
meaning of each gpios property must be documented in the device tree
|
||||
binding for each device.
|
||||
GPIO properties should be named "[<name>-]gpios", with <name> being the purpose
|
||||
of this GPIO for the device. While a non-existent <name> is considered valid
|
||||
for compatibility reasons (resolving to the "gpios" property), it is not allowed
|
||||
for new bindings.
|
||||
|
||||
For example, the following could be used to describe GPIO pins used
|
||||
as chip select lines; with chip selects 0, 1 and 3 populated, and chip
|
||||
select 2 left empty:
|
||||
GPIO properties can contain one or more GPIO phandles, but only in exceptional
|
||||
cases should they contain more than one. If your device uses several GPIOs with
|
||||
distinct functions, reference each of them under its own property, giving it a
|
||||
meaningful name. The only case where an array of GPIOs is accepted is when
|
||||
several GPIOs serve the same function (e.g. a parallel data line).
|
||||
|
||||
The exact purpose of each gpios property must be documented in the device tree
|
||||
binding of the device.
|
||||
|
||||
The following example could be used to describe GPIO pins used as device enable
|
||||
and bit-banged data signals:
|
||||
|
||||
gpio1: gpio1 {
|
||||
gpio-controller
|
||||
|
|
@ -30,10 +39,12 @@ select 2 left empty:
|
|||
#gpio-cells = <1>;
|
||||
};
|
||||
[...]
|
||||
chipsel-gpios = <&gpio1 12 0>,
|
||||
<&gpio1 13 0>,
|
||||
<0>, /* holes are permitted, means no GPIO 2 */
|
||||
<&gpio2 2>;
|
||||
|
||||
enable-gpios = <&gpio2 2>;
|
||||
data-gpios = <&gpio1 12 0>,
|
||||
<&gpio1 13 0>,
|
||||
<&gpio1 14 0>,
|
||||
<&gpio1 15 0>;
|
||||
|
||||
Note that gpio-specifier length is controller dependent. In the
|
||||
above example, &gpio1 uses 2 cells to specify a gpio, while &gpio2
|
||||
|
|
@ -42,16 +53,17 @@ only uses one.
|
|||
gpio-specifier may encode: bank, pin position inside the bank,
|
||||
whether pin is open-drain and whether pin is logically inverted.
|
||||
Exact meaning of each specifier cell is controller specific, and must
|
||||
be documented in the device tree binding for the device.
|
||||
be documented in the device tree binding for the device. Use the macros
|
||||
defined in include/dt-bindings/gpio/gpio.h whenever possible:
|
||||
|
||||
Example of a node using GPIOs:
|
||||
|
||||
node {
|
||||
gpios = <&qe_pio_e 18 0>;
|
||||
enable-gpios = <&qe_pio_e 18 GPIO_ACTIVE_HIGH>;
|
||||
};
|
||||
|
||||
In this example gpio-specifier is "18 0" and encodes GPIO pin number,
|
||||
and GPIO flags as accepted by the "qe_pio_e" gpio-controller.
|
||||
GPIO_ACTIVE_HIGH is 0, so in this example gpio-specifier is "18 0" and encodes
|
||||
GPIO pin number, and GPIO flags as accepted by the "qe_pio_e" gpio-controller.
|
||||
|
||||
1.1) GPIO specifier best practices
|
||||
----------------------------------
|
||||
|
|
|
|||
|
|
@ -7,4 +7,4 @@ Required properties:
|
|||
- bit 0 specifies polarity (0 for normal, 1 for inverted)
|
||||
- gpio-controller : Marks the device node as a GPIO controller.
|
||||
- interrupts : Interrupt mapping for GPIO IRQ.
|
||||
|
||||
- gpio-ranges : Interaction with the PINCTRL subsystem.
|
||||
|
|
|
|||
|
|
@ -6,7 +6,9 @@ Required Properties:
|
|||
- "renesas,gpio-r8a7778": for R8A7778 (R-Mobile M1) compatible GPIO controller.
|
||||
- "renesas,gpio-r8a7779": for R8A7779 (R-Car H1) compatible GPIO controller.
|
||||
- "renesas,gpio-r8a7790": for R8A7790 (R-Car H2) compatible GPIO controller.
|
||||
- "renesas,gpio-r8a7791": for R8A7791 (R-Car M2) compatible GPIO controller.
|
||||
- "renesas,gpio-r8a7791": for R8A7791 (R-Car M2-W) compatible GPIO controller.
|
||||
- "renesas,gpio-r8a7793": for R8A7793 (R-Car M2-N) compatible GPIO controller.
|
||||
- "renesas,gpio-r8a7794": for R8A7794 (R-Car E2) compatible GPIO controller.
|
||||
- "renesas,gpio-rcar": for generic R-Car GPIO controller.
|
||||
|
||||
- reg: Base address and length of each memory resource used by the GPIO
|
||||
|
|
|
|||
|
|
@ -191,6 +191,8 @@ of the following host1x client modules:
|
|||
- nvidia,hpd-gpio: specifies a GPIO used for hotplug detection
|
||||
- nvidia,edid: supplies a binary EDID blob
|
||||
- nvidia,panel: phandle of a display panel
|
||||
- nvidia,ganged-mode: contains a phandle to a second DSI controller to gang
|
||||
up with in order to support up to 8 data lanes
|
||||
|
||||
- sor: serial output resource
|
||||
|
||||
|
|
|
|||
|
|
@ -68,7 +68,7 @@ STMicroelectronics stih4xx platforms
|
|||
number of clocks may depend of the SoC type.
|
||||
- clock-names: names of the clocks listed in clocks property in the same
|
||||
order.
|
||||
- hdmi,hpd-gpio: gpio id to detect if an hdmi cable is plugged or not.
|
||||
- ddc: phandle of an I2C controller used for DDC EDID probing
|
||||
|
||||
sti-hda:
|
||||
Required properties:
|
||||
|
|
@ -83,6 +83,22 @@ sti-hda:
|
|||
- clock-names: names of the clocks listed in clocks property in the same
|
||||
order.
|
||||
|
||||
sti-hqvdp:
|
||||
must be a child of sti-display-subsystem
|
||||
Required properties:
|
||||
- compatible: "st,stih<chip>-hqvdp"
|
||||
- reg: Physical base address of the IP registers and length of memory mapped region.
|
||||
- clocks: from common clock binding: handle hardware IP needed clocks, the
|
||||
number of clocks may depend of the SoC type.
|
||||
See ../clocks/clock-bindings.txt for details.
|
||||
- clock-names: names of the clocks listed in clocks property in the same
|
||||
order.
|
||||
- resets: resets to be used by the device
|
||||
See ../reset/reset.txt for details.
|
||||
- reset-names: names of the resets listed in resets property in the same
|
||||
order.
|
||||
- st,vtg: phandle on vtg main device node.
|
||||
|
||||
Example:
|
||||
|
||||
/ {
|
||||
|
|
@ -173,7 +189,6 @@ Example:
|
|||
interrupt-names = "irq";
|
||||
clock-names = "pix", "tmds", "phy", "audio";
|
||||
clocks = <&clockgen_c_vcc CLK_S_PIX_HDMI>, <&clockgen_c_vcc CLK_S_TMDS_HDMI>, <&clockgen_c_vcc CLK_S_HDMI_REJECT_PLL>, <&clockgen_b1 CLK_S_PCM_0>;
|
||||
hdmi,hpd-gpio = <&PIO2 5>;
|
||||
};
|
||||
|
||||
sti-hda@fe85a000 {
|
||||
|
|
@ -184,6 +199,16 @@ Example:
|
|||
clocks = <&clockgen_c_vcc CLK_S_PIX_HD>, <&clockgen_c_vcc CLK_S_HDDAC>;
|
||||
};
|
||||
};
|
||||
|
||||
sti-hqvdp@9c000000 {
|
||||
compatible = "st,stih407-hqvdp";
|
||||
reg = <0x9C00000 0x100000>;
|
||||
clock-names = "hqvdp", "pix_main";
|
||||
clocks = <&clk_s_c0_flexgen CLK_MAIN_DISP>, <&clk_s_d2_flexgen CLK_PIX_MAIN_DISP>;
|
||||
reset-names = "hqvdp";
|
||||
resets = <&softreset STIH407_HDQVDP_SOFTRESET>;
|
||||
st,vtg = <&vtg_main>;
|
||||
};
|
||||
};
|
||||
...
|
||||
};
|
||||
|
|
|
|||
|
|
@ -0,0 +1,16 @@
|
|||
Atmel TRNG (True Random Number Generator) block
|
||||
|
||||
Required properties:
|
||||
- compatible : Should be "atmel,at91sam9g45-trng"
|
||||
- reg : Offset and length of the register set of this block
|
||||
- interrupts : the interrupt number for the TRNG block
|
||||
- clocks: should contain the TRNG clk source
|
||||
|
||||
Example:
|
||||
|
||||
trng@fffcc000 {
|
||||
compatible = "atmel,at91sam9g45-trng";
|
||||
reg = <0xfffcc000 0x4000>;
|
||||
interrupts = <6 IRQ_TYPE_LEVEL_HIGH 0>;
|
||||
clocks = <&trng_clk>;
|
||||
};
|
||||
|
|
@ -14,10 +14,10 @@ Optional properties :
|
|||
- i2c-sda-hold-time-ns : should contain the SDA hold time in nanoseconds.
|
||||
This option is only supported in hardware blocks version 1.11a or newer.
|
||||
|
||||
- i2c-scl-falling-time : should contain the SCL falling time in nanoseconds.
|
||||
- i2c-scl-falling-time-ns : should contain the SCL falling time in nanoseconds.
|
||||
This value which is by default 300ns is used to compute the tLOW period.
|
||||
|
||||
- i2c-sda-falling-time : should contain the SDA falling time in nanoseconds.
|
||||
- i2c-sda-falling-time-ns : should contain the SDA falling time in nanoseconds.
|
||||
This value which is by default 300ns is used to compute the tHIGH period.
|
||||
|
||||
Example :
|
||||
|
|
|
|||
|
|
@ -0,0 +1,26 @@
|
|||
IMG Serial Control Bus (SCB) I2C Controller
|
||||
|
||||
Required Properties:
|
||||
- compatible: "img,scb-i2c"
|
||||
- reg: Physical base address and length of controller registers
|
||||
- interrupts: Interrupt number used by the controller
|
||||
- clocks : Should contain a clock specifier for each entry in clock-names
|
||||
- clock-names : Should contain the following entries:
|
||||
"scb", for the SCB core clock.
|
||||
"sys", for the system clock.
|
||||
- clock-frequency: The I2C bus frequency in Hz
|
||||
- #address-cells: Should be <1>
|
||||
- #size-cells: Should be <0>
|
||||
|
||||
Example:
|
||||
|
||||
i2c@18100000 {
|
||||
compatible = "img,scb-i2c";
|
||||
reg = <0x18100000 0x200>;
|
||||
interrupts = <GIC_SHARED 2 IRQ_TYPE_LEVEL_HIGH>;
|
||||
clocks = <&i2c0_clk>, <&system_clk>;
|
||||
clock-names = "scb", "sys";
|
||||
clock-frequency = <400000>;
|
||||
#address-cells = <1>;
|
||||
#size-cells = <0>;
|
||||
};
|
||||
|
|
@ -11,6 +11,8 @@ Required properties:
|
|||
Optional properties:
|
||||
- clock-frequency : Constains desired I2C/HS-I2C bus clock frequency in Hz.
|
||||
The absence of the propoerty indicates the default frequency 100 kHz.
|
||||
- dmas: A list of two dma specifiers, one for each entry in dma-names.
|
||||
- dma-names: should contain "tx" and "rx".
|
||||
|
||||
Examples:
|
||||
|
||||
|
|
@ -26,3 +28,12 @@ i2c@70038000 { /* HS-I2C on i.MX51 */
|
|||
interrupts = <64>;
|
||||
clock-frequency = <400000>;
|
||||
};
|
||||
|
||||
i2c0: i2c@40066000 { /* i2c0 on vf610 */
|
||||
compatible = "fsl,vf610-i2c";
|
||||
reg = <0x40066000 0x1000>;
|
||||
interrupts =<0 71 0x04>;
|
||||
dmas = <&edma0 0 50>,
|
||||
<&edma0 0 51>;
|
||||
dma-names = "rx","tx";
|
||||
};
|
||||
|
|
|
|||
|
|
@ -0,0 +1,24 @@
|
|||
Amlogic Meson I2C controller
|
||||
|
||||
Required properties:
|
||||
- compatible: must be "amlogic,meson6-i2c"
|
||||
- reg: physical address and length of the device registers
|
||||
- interrupts: a single interrupt specifier
|
||||
- clocks: clock for the device
|
||||
- #address-cells: should be <1>
|
||||
- #size-cells: should be <0>
|
||||
|
||||
Optional properties:
|
||||
- clock-frequency: the desired I2C bus clock frequency in Hz; in
|
||||
absence of this property the default value is used (100 kHz).
|
||||
|
||||
Examples:
|
||||
|
||||
i2c@c8100500 {
|
||||
compatible = "amlogic,meson6-i2c";
|
||||
reg = <0xc8100500 0x20>;
|
||||
interrupts = <0 92 1>;
|
||||
clocks = <&clk81>;
|
||||
#address-cells = <1>;
|
||||
#size-cells = <0>;
|
||||
};
|
||||
|
|
@ -0,0 +1,37 @@
|
|||
Device-tree bindings for I2C OPAL driver
|
||||
----------------------------------------
|
||||
|
||||
Most of the device node and properties layout is specific to the firmware and
|
||||
used by the firmware itself for configuring the port. From the linux
|
||||
perspective, the properties of use are "ibm,port-name" and "ibm,opal-id".
|
||||
|
||||
Required properties:
|
||||
|
||||
- reg: Port-id within a given master
|
||||
- compatible: must be "ibm,opal-i2c"
|
||||
- ibm,opal-id: Refers to a specific bus and used to identify it when calling
|
||||
the relevant OPAL functions.
|
||||
- bus-frequency: Operating frequency of the i2c bus (in HZ). Informational for
|
||||
linux, used by the FW though.
|
||||
|
||||
Optional properties:
|
||||
- ibm,port-name: Firmware provides this name that uniquely identifies the i2c
|
||||
port.
|
||||
|
||||
The node contains a number of other properties that are used by the FW itself
|
||||
and depend on the specific hardware implementation. The example below depicts
|
||||
a P8 on-chip bus.
|
||||
|
||||
Example:
|
||||
|
||||
i2c-bus@0 {
|
||||
reg = <0x0>;
|
||||
bus-frequency = <0x61a80>;
|
||||
compatible = "ibm,power8-i2c-port", "ibm,opal-i2c";
|
||||
ibm,opal-id = <0x1>;
|
||||
ibm,port-name = "p8_00000000_e1p0";
|
||||
#address-cells = <0x1>;
|
||||
phandle = <0x10000006>;
|
||||
#size-cells = <0x0>;
|
||||
linux,phandle = <0x10000006>;
|
||||
};
|
||||
|
|
@ -2,6 +2,15 @@ Device tree configuration for Renesas IIC (sh_mobile) driver
|
|||
|
||||
Required properties:
|
||||
- compatible : "renesas,iic-<soctype>". "renesas,rmobile-iic" as fallback
|
||||
Examples with soctypes are:
|
||||
- "renesas,iic-r8a73a4" (R-Mobile APE6)
|
||||
- "renesas,iic-r8a7740" (R-Mobile A1)
|
||||
- "renesas,iic-r8a7790" (R-Car H2)
|
||||
- "renesas,iic-r8a7791" (R-Car M2-W)
|
||||
- "renesas,iic-r8a7792" (R-Car V2H)
|
||||
- "renesas,iic-r8a7793" (R-Car M2-N)
|
||||
- "renesas,iic-r8a7794" (R-Car E2)
|
||||
- "renesas,iic-sh73a0" (SH-Mobile AG5)
|
||||
- reg : address start and address range size of device
|
||||
- interrupts : interrupt of device
|
||||
- clocks : clock for device
|
||||
|
|
@ -10,6 +19,11 @@ Required properties:
|
|||
|
||||
Optional properties:
|
||||
- clock-frequency : frequency of bus clock in Hz. Default 100kHz if unset.
|
||||
- dmas : Must contain a list of two references to DMA
|
||||
specifiers, one for transmission, and one for
|
||||
reception.
|
||||
- dma-names : Must contain a list of two DMA names, "tx" and "rx".
|
||||
|
||||
|
||||
Pinctrl properties might be needed, too. See there.
|
||||
|
||||
|
|
|
|||
|
|
@ -17,6 +17,9 @@ adi,adt7473 +/-1C TDM Extended Temp Range I.C
|
|||
adi,adt7475 +/-1C TDM Extended Temp Range I.C
|
||||
adi,adt7476 +/-1C TDM Extended Temp Range I.C
|
||||
adi,adt7490 +/-1C TDM Extended Temp Range I.C
|
||||
adi,adxl345 Three-Axis Digital Accelerometer
|
||||
adi,adxl346 Three-Axis Digital Accelerometer
|
||||
adi,adxl34x Three-Axis Digital Accelerometer
|
||||
at,24c08 i2c serial eeprom (24cxx)
|
||||
atmel,24c00 i2c serial eeprom (24cxx)
|
||||
atmel,24c01 i2c serial eeprom (24cxx)
|
||||
|
|
@ -76,7 +79,12 @@ ovti,ov5642 OV5642: Color CMOS QSXGA (5-megapixel) Image Sensor with OmniBSI an
|
|||
pericom,pt7c4338 Real-time Clock Module
|
||||
plx,pex8648 48-Lane, 12-Port PCI Express Gen 2 (5.0 GT/s) Switch
|
||||
ramtron,24c64 i2c serial eeprom (24cxx)
|
||||
ricoh,r2025sd I2C bus SERIAL INTERFACE REAL-TIME CLOCK IC
|
||||
ricoh,r2221tl I2C bus SERIAL INTERFACE REAL-TIME CLOCK IC
|
||||
ricoh,rs5c372a I2C bus SERIAL INTERFACE REAL-TIME CLOCK IC
|
||||
ricoh,rs5c372b I2C bus SERIAL INTERFACE REAL-TIME CLOCK IC
|
||||
ricoh,rv5c386 I2C bus SERIAL INTERFACE REAL-TIME CLOCK IC
|
||||
ricoh,rv5c387a I2C bus SERIAL INTERFACE REAL-TIME CLOCK IC
|
||||
samsung,24ad0xd1 S524AD0XF1 (128K/256K-bit Serial EEPROM for Low Power)
|
||||
sii,s35390a 2-wire CMOS real-time clock
|
||||
st-micro,24c256 i2c serial eeprom (24cxx)
|
||||
|
|
|
|||
|
|
@ -0,0 +1,46 @@
|
|||
Qualcomm's SPMI PMIC current ADC
|
||||
|
||||
QPNP PMIC current ADC (IADC) provides interface to clients to read current.
|
||||
A 16 bit ADC is used for current measurements. IADC can measure the current
|
||||
through an external resistor (channel 1) or internal (built-in) resistor
|
||||
(channel 0). When using an external resistor it is to be described by
|
||||
qcom,external-resistor-micro-ohms property.
|
||||
|
||||
IADC node:
|
||||
|
||||
- compatible:
|
||||
Usage: required
|
||||
Value type: <string>
|
||||
Definition: Should contain "qcom,spmi-iadc".
|
||||
|
||||
- reg:
|
||||
Usage: required
|
||||
Value type: <prop-encoded-array>
|
||||
Definition: IADC base address and length in the SPMI PMIC register map
|
||||
|
||||
- interrupts:
|
||||
Usage: optional
|
||||
Value type: <prop-encoded-array>
|
||||
Definition: End of ADC conversion.
|
||||
|
||||
- qcom,external-resistor-micro-ohms:
|
||||
Usage: optional
|
||||
Value type: <u32>
|
||||
Definition: Sense resister value in micro Ohm.
|
||||
If not defined value of 10000 micro Ohms will be used.
|
||||
|
||||
Example:
|
||||
/* IADC node */
|
||||
pmic_iadc: iadc@3600 {
|
||||
compatible = "qcom,spmi-iadc";
|
||||
reg = <0x3600 0x100>;
|
||||
interrupts = <0x0 0x36 0x0 IRQ_TYPE_EDGE_RISING>;
|
||||
qcom,external-resistor-micro-ohms = <10000>;
|
||||
#io-channel-cells = <1>;
|
||||
};
|
||||
|
||||
/* IIO client node */
|
||||
bat {
|
||||
io-channels = <&pmic_iadc 0>;
|
||||
io-channel-names = "iadc";
|
||||
};
|
||||
Some files were not shown because too many files have changed in this diff Show More
Loading…
Reference in New Issue