Merge branch 'master' into for-4.20/upstream-fixes
Pull in a merge commit that brought in 3b692c55e5 ("HID: asus: only
support backlight when it's not driven by WMI") so that fixup could be
applied on top of it.
hifive-unleashed-5.1
Jiri Kosina
commit
0c72442095
|
|
@ -323,7 +323,6 @@ ForEachMacros:
|
|||
- 'protocol_for_each_card'
|
||||
- 'protocol_for_each_dev'
|
||||
- 'queue_for_each_hw_ctx'
|
||||
- 'radix_tree_for_each_contig'
|
||||
- 'radix_tree_for_each_slot'
|
||||
- 'radix_tree_for_each_tagged'
|
||||
- 'rbtree_postorder_for_each_entry_safe'
|
||||
|
|
|
|||
12
.mailmap
12
.mailmap
|
|
@ -119,6 +119,13 @@ Mark Brown <broonie@sirena.org.uk>
|
|||
Mark Yao <markyao0591@gmail.com> <mark.yao@rock-chips.com>
|
||||
Martin Kepplinger <martink@posteo.de> <martin.kepplinger@theobroma-systems.com>
|
||||
Martin Kepplinger <martink@posteo.de> <martin.kepplinger@ginzinger.com>
|
||||
Matthew Wilcox <willy@infradead.org> <matthew.r.wilcox@intel.com>
|
||||
Matthew Wilcox <willy@infradead.org> <matthew@wil.cx>
|
||||
Matthew Wilcox <willy@infradead.org> <mawilcox@linuxonhyperv.com>
|
||||
Matthew Wilcox <willy@infradead.org> <mawilcox@microsoft.com>
|
||||
Matthew Wilcox <willy@infradead.org> <willy@debian.org>
|
||||
Matthew Wilcox <willy@infradead.org> <willy@linux.intel.com>
|
||||
Matthew Wilcox <willy@infradead.org> <willy@parisc-linux.org>
|
||||
Matthieu CASTET <castet.matthieu@free.fr>
|
||||
Mauro Carvalho Chehab <mchehab@kernel.org> <mchehab@brturbo.com.br>
|
||||
Mauro Carvalho Chehab <mchehab@kernel.org> <maurochehab@gmail.com>
|
||||
|
|
@ -153,6 +160,11 @@ Peter Oruba <peter.oruba@amd.com>
|
|||
Pratyush Anand <pratyush.anand@gmail.com> <pratyush.anand@st.com>
|
||||
Praveen BP <praveenbp@ti.com>
|
||||
Qais Yousef <qsyousef@gmail.com> <qais.yousef@imgtec.com>
|
||||
Oleksij Rempel <linux@rempel-privat.de> <bug-track@fisher-privat.net>
|
||||
Oleksij Rempel <linux@rempel-privat.de> <external.Oleksij.Rempel@de.bosch.com>
|
||||
Oleksij Rempel <linux@rempel-privat.de> <fixed-term.Oleksij.Rempel@de.bosch.com>
|
||||
Oleksij Rempel <linux@rempel-privat.de> <o.rempel@pengutronix.de>
|
||||
Oleksij Rempel <linux@rempel-privat.de> <ore@pengutronix.de>
|
||||
Rajesh Shah <rajesh.shah@intel.com>
|
||||
Ralf Baechle <ralf@linux-mips.org>
|
||||
Ralf Wildenhues <Ralf.Wildenhues@gmx.de>
|
||||
|
|
|
|||
|
|
@ -25,38 +25,3 @@ Description:
|
|||
4.2.2.
|
||||
|
||||
The files are read only.
|
||||
|
||||
|
||||
What: /sys/bus/usb/drivers/usbtmc/*/TermChar
|
||||
Date: August 2008
|
||||
Contact: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
||||
Description:
|
||||
This file is the TermChar value to be sent to the USB TMC
|
||||
device as described by the document, "Universal Serial Bus Test
|
||||
and Measurement Class Specification
|
||||
(USBTMC) Revision 1.0" as published by the USB-IF.
|
||||
|
||||
Note that the TermCharEnabled file determines if this value is
|
||||
sent to the device or not.
|
||||
|
||||
|
||||
What: /sys/bus/usb/drivers/usbtmc/*/TermCharEnabled
|
||||
Date: August 2008
|
||||
Contact: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
||||
Description:
|
||||
This file determines if the TermChar is to be sent to the
|
||||
device on every transaction or not. For more details about
|
||||
this, please see the document, "Universal Serial Bus Test and
|
||||
Measurement Class Specification (USBTMC) Revision 1.0" as
|
||||
published by the USB-IF.
|
||||
|
||||
|
||||
What: /sys/bus/usb/drivers/usbtmc/*/auto_abort
|
||||
Date: August 2008
|
||||
Contact: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
||||
Description:
|
||||
This file determines if the transaction of the USB TMC
|
||||
device is to be automatically aborted if there is any error.
|
||||
For more details about this, please see the document,
|
||||
"Universal Serial Bus Test and Measurement Class Specification
|
||||
(USBTMC) Revision 1.0" as published by the USB-IF.
|
||||
|
|
|
|||
|
|
@ -0,0 +1,41 @@
|
|||
What: /config/stp-policy/<device>:p_sys-t.<policy>/<node>/uuid
|
||||
Date: June 2018
|
||||
KernelVersion: 4.19
|
||||
Description:
|
||||
UUID source identifier string, RW.
|
||||
Default value is randomly generated at the mkdir <node> time.
|
||||
Data coming from trace sources that use this <node> will be
|
||||
tagged with this UUID in the MIPI SyS-T packet stream, to
|
||||
allow the decoder to discern between different sources
|
||||
within the same master/channel range, and identify the
|
||||
higher level decoders that may be needed for each source.
|
||||
|
||||
What: /config/stp-policy/<device>:p_sys-t.<policy>/<node>/do_len
|
||||
Date: June 2018
|
||||
KernelVersion: 4.19
|
||||
Description:
|
||||
Include payload length in the MIPI SyS-T header, boolean.
|
||||
If enabled, the SyS-T protocol encoder will include payload
|
||||
length in each packet's metadata. This is normally redundant
|
||||
if the underlying transport protocol supports marking message
|
||||
boundaries (which STP does), so this is off by default.
|
||||
|
||||
What: /config/stp-policy/<device>:p_sys-t.<policy>/<node>/ts_interval
|
||||
Date: June 2018
|
||||
KernelVersion: 4.19
|
||||
Description:
|
||||
Time interval in milliseconds. Include a timestamp in the
|
||||
MIPI SyS-T packet metadata, if this many milliseconds have
|
||||
passed since the previous packet from this source. Zero is
|
||||
the default and stands for "never send the timestamp".
|
||||
|
||||
What: /config/stp-policy/<device>:p_sys-t.<policy>/<node>/clocksync_interval
|
||||
Date: June 2018
|
||||
KernelVersion: 4.19
|
||||
Description:
|
||||
Time interval in milliseconds. Send a CLOCKSYNC packet if
|
||||
this many milliseconds have passed since the previous
|
||||
CLOCKSYNC packet from this source. Zero is the default and
|
||||
stands for "never send the CLOCKSYNC". It makes sense to
|
||||
use this option with sources that generate constant and/or
|
||||
periodic data, like stm_heartbeat.
|
||||
|
|
@ -12,6 +12,10 @@ Date: Dec 2014
|
|||
KernelVersion: 4.0
|
||||
Description: Control descriptors
|
||||
|
||||
All attributes read only:
|
||||
bInterfaceNumber - USB interface number for this
|
||||
streaming interface
|
||||
|
||||
What: /config/usb-gadget/gadget/functions/uvc.name/control/class
|
||||
Date: Dec 2014
|
||||
KernelVersion: 4.0
|
||||
|
|
@ -109,6 +113,10 @@ Date: Dec 2014
|
|||
KernelVersion: 4.0
|
||||
Description: Streaming descriptors
|
||||
|
||||
All attributes read only:
|
||||
bInterfaceNumber - USB interface number for this
|
||||
streaming interface
|
||||
|
||||
What: /config/usb-gadget/gadget/functions/uvc.name/streaming/class
|
||||
Date: Dec 2014
|
||||
KernelVersion: 4.0
|
||||
|
|
@ -160,6 +168,10 @@ Description: Specific MJPEG format descriptors
|
|||
|
||||
All attributes read only,
|
||||
except bmaControls and bDefaultFrameIndex:
|
||||
bFormatIndex - unique id for this format descriptor;
|
||||
only defined after parent header is
|
||||
linked into the streaming class;
|
||||
read-only
|
||||
bmaControls - this format's data for bmaControls in
|
||||
the streaming header
|
||||
bmInterfaceFlags - specifies interlace information,
|
||||
|
|
@ -177,6 +189,10 @@ Date: Dec 2014
|
|||
KernelVersion: 4.0
|
||||
Description: Specific MJPEG frame descriptors
|
||||
|
||||
bFrameIndex - unique id for this framedescriptor;
|
||||
only defined after parent format is
|
||||
linked into the streaming header;
|
||||
read-only
|
||||
dwFrameInterval - indicates how frame interval can be
|
||||
programmed; a number of values
|
||||
separated by newline can be specified
|
||||
|
|
@ -204,6 +220,10 @@ Date: Dec 2014
|
|||
KernelVersion: 4.0
|
||||
Description: Specific uncompressed format descriptors
|
||||
|
||||
bFormatIndex - unique id for this format descriptor;
|
||||
only defined after parent header is
|
||||
linked into the streaming class;
|
||||
read-only
|
||||
bmaControls - this format's data for bmaControls in
|
||||
the streaming header
|
||||
bmInterfaceFlags - specifies interlace information,
|
||||
|
|
@ -224,6 +244,10 @@ Date: Dec 2014
|
|||
KernelVersion: 4.0
|
||||
Description: Specific uncompressed frame descriptors
|
||||
|
||||
bFrameIndex - unique id for this framedescriptor;
|
||||
only defined after parent format is
|
||||
linked into the streaming header;
|
||||
read-only
|
||||
dwFrameInterval - indicates how frame interval can be
|
||||
programmed; a number of values
|
||||
separated by newline can be specified
|
||||
|
|
|
|||
|
|
@ -199,7 +199,7 @@ Description:
|
|||
|
||||
What: /sys/bus/iio/devices/iio:deviceX/in_positionrelative_x_raw
|
||||
What: /sys/bus/iio/devices/iio:deviceX/in_positionrelative_y_raw
|
||||
KernelVersion: 4.18
|
||||
KernelVersion: 4.19
|
||||
Contact: linux-iio@vger.kernel.org
|
||||
Description:
|
||||
Relative position in direction x or y on a pad (may be
|
||||
|
|
|
|||
|
|
@ -323,3 +323,27 @@ Description:
|
|||
|
||||
This is similar to /sys/bus/pci/drivers_autoprobe, but
|
||||
affects only the VFs associated with a specific PF.
|
||||
|
||||
What: /sys/bus/pci/devices/.../p2pmem/size
|
||||
Date: November 2017
|
||||
Contact: Logan Gunthorpe <logang@deltatee.com>
|
||||
Description:
|
||||
If the device has any Peer-to-Peer memory registered, this
|
||||
file contains the total amount of memory that the device
|
||||
provides (in decimal).
|
||||
|
||||
What: /sys/bus/pci/devices/.../p2pmem/available
|
||||
Date: November 2017
|
||||
Contact: Logan Gunthorpe <logang@deltatee.com>
|
||||
Description:
|
||||
If the device has any Peer-to-Peer memory registered, this
|
||||
file contains the amount of memory that has not been
|
||||
allocated (in decimal).
|
||||
|
||||
What: /sys/bus/pci/devices/.../p2pmem/published
|
||||
Date: November 2017
|
||||
Contact: Logan Gunthorpe <logang@deltatee.com>
|
||||
Description:
|
||||
If the device has any Peer-to-Peer memory registered, this
|
||||
file contains a '1' if the memory has been published for
|
||||
use outside the driver that owns the device.
|
||||
|
|
|
|||
|
|
@ -189,6 +189,16 @@ Description:
|
|||
The file will read "hotplug", "wired" and "not used" if the
|
||||
information is available, and "unknown" otherwise.
|
||||
|
||||
What: /sys/bus/usb/devices/.../(hub interface)/portX/location
|
||||
Date: October 2018
|
||||
Contact: Bjørn Mork <bjorn@mork.no>
|
||||
Description:
|
||||
Some platforms provide usb port physical location through
|
||||
firmware. This is used by the kernel to pair up logical ports
|
||||
mapping to the same physical connector. The attribute exposes the
|
||||
raw location value as a hex integer.
|
||||
|
||||
|
||||
What: /sys/bus/usb/devices/.../(hub interface)/portX/quirks
|
||||
Date: May 2018
|
||||
Contact: Nicolas Boichat <drinkcat@chromium.org>
|
||||
|
|
@ -219,7 +229,14 @@ Description:
|
|||
ports and report them to the kernel. This attribute is to expose
|
||||
the number of over-current situation occurred on a specific port
|
||||
to user space. This file will contain an unsigned 32 bit value
|
||||
which wraps to 0 after its maximum is reached.
|
||||
which wraps to 0 after its maximum is reached. This file supports
|
||||
poll() for monitoring changes to this value in user space.
|
||||
|
||||
Any time this value changes the corresponding hub device will send a
|
||||
udev event with the following attributes:
|
||||
|
||||
OVER_CURRENT_PORT=/sys/bus/usb/devices/.../(hub interface)/portX
|
||||
OVER_CURRENT_COUNT=[current value of this sysfs attribute]
|
||||
|
||||
What: /sys/bus/usb/devices/.../(hub interface)/portX/usb3_lpm_permit
|
||||
Date: November 2015
|
||||
|
|
|
|||
|
|
@ -0,0 +1,21 @@
|
|||
What: /sys/bus/vmbus/devices/.../driver_override
|
||||
Date: August 2019
|
||||
Contact: Stephen Hemminger <sthemmin@microsoft.com>
|
||||
Description:
|
||||
This file allows the driver for a device to be specified which
|
||||
will override standard static and dynamic ID matching. When
|
||||
specified, only a driver with a name matching the value written
|
||||
to driver_override will have an opportunity to bind to the
|
||||
device. The override is specified by writing a string to the
|
||||
driver_override file (echo uio_hv_generic > driver_override) and
|
||||
may be cleared with an empty string (echo > driver_override).
|
||||
This returns the device to standard matching rules binding.
|
||||
Writing to driver_override does not automatically unbind the
|
||||
device from its current driver or make any attempt to
|
||||
automatically load the specified driver. If no driver with a
|
||||
matching name is currently loaded in the kernel, the device
|
||||
will not bind to any driver. This also allows devices to
|
||||
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.
|
||||
|
||||
|
|
@ -91,6 +91,24 @@ Description:
|
|||
stacked (e.g: VLAN interfaces) but still have the same MAC
|
||||
address as their parent device.
|
||||
|
||||
What: /sys/class/net/<iface>/dev_port
|
||||
Date: February 2014
|
||||
KernelVersion: 3.15
|
||||
Contact: netdev@vger.kernel.org
|
||||
Description:
|
||||
Indicates the port number of this network device, formatted
|
||||
as a decimal value. Some NICs have multiple independent ports
|
||||
on the same PCI bus, device and function. This attribute allows
|
||||
userspace to distinguish the respective interfaces.
|
||||
|
||||
Note: some device drivers started to use 'dev_id' for this
|
||||
purpose since long before 3.15 and have not adopted the new
|
||||
attribute ever since. To query the port number, some tools look
|
||||
exclusively at 'dev_port', while others only consult 'dev_id'.
|
||||
If a network device has multiple client adapter ports as
|
||||
described in the previous paragraph and does not set this
|
||||
attribute to its port number, it's a kernel bug.
|
||||
|
||||
What: /sys/class/net/<iface>/dormant
|
||||
Date: March 2006
|
||||
KernelVersion: 2.6.17
|
||||
|
|
|
|||
|
|
@ -0,0 +1,35 @@
|
|||
What: /sys/devices/platform/lg-laptop/reader_mode
|
||||
Date: October 2018
|
||||
KernelVersion: 4.20
|
||||
Contact: "Matan Ziv-Av <matan@svgalib.org>
|
||||
Description:
|
||||
Control reader mode. 1 means on, 0 means off.
|
||||
|
||||
What: /sys/devices/platform/lg-laptop/fn_lock
|
||||
Date: October 2018
|
||||
KernelVersion: 4.20
|
||||
Contact: "Matan Ziv-Av <matan@svgalib.org>
|
||||
Description:
|
||||
Control FN lock mode. 1 means on, 0 means off.
|
||||
|
||||
What: /sys/devices/platform/lg-laptop/battery_care_limit
|
||||
Date: October 2018
|
||||
KernelVersion: 4.20
|
||||
Contact: "Matan Ziv-Av <matan@svgalib.org>
|
||||
Description:
|
||||
Maximal battery charge level. Accepted values are 80 or 100.
|
||||
|
||||
What: /sys/devices/platform/lg-laptop/fan_mode
|
||||
Date: October 2018
|
||||
KernelVersion: 4.20
|
||||
Contact: "Matan Ziv-Av <matan@svgalib.org>
|
||||
Description:
|
||||
Control fan mode. 1 for performance mode, 0 for silent mode.
|
||||
|
||||
What: /sys/devices/platform/lg-laptop/usb_charge
|
||||
Date: October 2018
|
||||
KernelVersion: 4.20
|
||||
Contact: "Matan Ziv-Av <matan@svgalib.org>
|
||||
Description:
|
||||
Control USB port charging when device is turned off.
|
||||
1 means on, 0 means off.
|
||||
|
|
@ -99,17 +99,20 @@ Note that the devices listed here correspond to the value populated in 1.4 above
|
|||
2.2 Using Endpoint Test function Device
|
||||
|
||||
pcitest.sh added in tools/pci/ can be used to run all the default PCI endpoint
|
||||
tests. Before pcitest.sh can be used pcitest.c should be compiled using the
|
||||
following commands.
|
||||
tests. To compile this tool the following commands should be used:
|
||||
|
||||
cd <kernel-dir>
|
||||
make headers_install ARCH=arm
|
||||
arm-linux-gnueabihf-gcc -Iusr/include tools/pci/pcitest.c -o pcitest
|
||||
cp pcitest <rootfs>/usr/sbin/
|
||||
cp tools/pci/pcitest.sh <rootfs>
|
||||
# cd <kernel-dir>
|
||||
# make -C tools/pci
|
||||
|
||||
or if you desire to compile and install in your system:
|
||||
|
||||
# cd <kernel-dir>
|
||||
# make -C tools/pci install
|
||||
|
||||
The tool and script will be located in <rootfs>/usr/bin/
|
||||
|
||||
2.2.1 pcitest.sh Output
|
||||
# ./pcitest.sh
|
||||
# pcitest.sh
|
||||
BAR tests
|
||||
|
||||
BAR0: OKAY
|
||||
|
|
|
|||
|
|
@ -110,7 +110,7 @@ The actual steps taken by a platform to recover from a PCI error
|
|||
event will be platform-dependent, but will follow the general
|
||||
sequence described below.
|
||||
|
||||
STEP 0: Error Event: ERR_NONFATAL
|
||||
STEP 0: Error Event
|
||||
-------------------
|
||||
A PCI bus error is detected by the PCI hardware. On powerpc, the slot
|
||||
is isolated, in that all I/O is blocked: all reads return 0xffffffff,
|
||||
|
|
@ -228,7 +228,13 @@ proceeds to either STEP3 (Link Reset) or to STEP 5 (Resume Operations).
|
|||
If any driver returned PCI_ERS_RESULT_NEED_RESET, then the platform
|
||||
proceeds to STEP 4 (Slot Reset)
|
||||
|
||||
STEP 3: Slot Reset
|
||||
STEP 3: Link Reset
|
||||
------------------
|
||||
The platform resets the link. This is a PCI-Express specific step
|
||||
and is done whenever a fatal error has been detected that can be
|
||||
"solved" by resetting the link.
|
||||
|
||||
STEP 4: Slot Reset
|
||||
------------------
|
||||
|
||||
In response to a return value of PCI_ERS_RESULT_NEED_RESET, the
|
||||
|
|
@ -314,7 +320,7 @@ Failure).
|
|||
>>> However, it probably should.
|
||||
|
||||
|
||||
STEP 4: Resume Operations
|
||||
STEP 5: Resume Operations
|
||||
-------------------------
|
||||
The platform will call the resume() callback on all affected device
|
||||
drivers if all drivers on the segment have returned
|
||||
|
|
@ -326,7 +332,7 @@ a result code.
|
|||
At this point, if a new error happens, the platform will restart
|
||||
a new error recovery sequence.
|
||||
|
||||
STEP 5: Permanent Failure
|
||||
STEP 6: Permanent Failure
|
||||
-------------------------
|
||||
A "permanent failure" has occurred, and the platform cannot recover
|
||||
the device. The platform will call error_detected() with a
|
||||
|
|
@ -349,27 +355,6 @@ errors. See the discussion in powerpc/eeh-pci-error-recovery.txt
|
|||
for additional detail on real-life experience of the causes of
|
||||
software errors.
|
||||
|
||||
STEP 0: Error Event: ERR_FATAL
|
||||
-------------------
|
||||
PCI bus error is detected by the PCI hardware. On powerpc, the slot is
|
||||
isolated, in that all I/O is blocked: all reads return 0xffffffff, all
|
||||
writes are ignored.
|
||||
|
||||
STEP 1: Remove devices
|
||||
--------------------
|
||||
Platform removes the devices depending on the error agent, it could be
|
||||
this port for all subordinates or upstream component (likely downstream
|
||||
port)
|
||||
|
||||
STEP 2: Reset link
|
||||
--------------------
|
||||
The platform resets the link. This is a PCI-Express specific step and is
|
||||
done whenever a fatal error has been detected that can be "solved" by
|
||||
resetting the link.
|
||||
|
||||
STEP 3: Re-enumerate the devices
|
||||
--------------------
|
||||
Initiates the re-enumeration.
|
||||
|
||||
Conclusion; General Remarks
|
||||
---------------------------
|
||||
|
|
|
|||
|
|
@ -0,0 +1,73 @@
|
|||
================================
|
||||
PSI - Pressure Stall Information
|
||||
================================
|
||||
|
||||
:Date: April, 2018
|
||||
:Author: Johannes Weiner <hannes@cmpxchg.org>
|
||||
|
||||
When CPU, memory or IO devices are contended, workloads experience
|
||||
latency spikes, throughput losses, and run the risk of OOM kills.
|
||||
|
||||
Without an accurate measure of such contention, users are forced to
|
||||
either play it safe and under-utilize their hardware resources, or
|
||||
roll the dice and frequently suffer the disruptions resulting from
|
||||
excessive overcommit.
|
||||
|
||||
The psi feature identifies and quantifies the disruptions caused by
|
||||
such resource crunches and the time impact it has on complex workloads
|
||||
or even entire systems.
|
||||
|
||||
Having an accurate measure of productivity losses caused by resource
|
||||
scarcity aids users in sizing workloads to hardware--or provisioning
|
||||
hardware according to workload demand.
|
||||
|
||||
As psi aggregates this information in realtime, systems can be managed
|
||||
dynamically using techniques such as load shedding, migrating jobs to
|
||||
other systems or data centers, or strategically pausing or killing low
|
||||
priority or restartable batch jobs.
|
||||
|
||||
This allows maximizing hardware utilization without sacrificing
|
||||
workload health or risking major disruptions such as OOM kills.
|
||||
|
||||
Pressure interface
|
||||
==================
|
||||
|
||||
Pressure information for each resource is exported through the
|
||||
respective file in /proc/pressure/ -- cpu, memory, and io.
|
||||
|
||||
The format for CPU is as such:
|
||||
|
||||
some avg10=0.00 avg60=0.00 avg300=0.00 total=0
|
||||
|
||||
and for memory and IO:
|
||||
|
||||
some avg10=0.00 avg60=0.00 avg300=0.00 total=0
|
||||
full avg10=0.00 avg60=0.00 avg300=0.00 total=0
|
||||
|
||||
The "some" line indicates the share of time in which at least some
|
||||
tasks are stalled on a given resource.
|
||||
|
||||
The "full" line indicates the share of time in which all non-idle
|
||||
tasks are stalled on a given resource simultaneously. In this state
|
||||
actual CPU cycles are going to waste, and a workload that spends
|
||||
extended time in this state is considered to be thrashing. This has
|
||||
severe impact on performance, and it's useful to distinguish this
|
||||
situation from a state where some tasks are stalled but the CPU is
|
||||
still doing productive work. As such, time spent in this subset of the
|
||||
stall state is tracked separately and exported in the "full" averages.
|
||||
|
||||
The ratios are tracked as recent trends over ten, sixty, and three
|
||||
hundred second windows, which gives insight into short term events as
|
||||
well as medium and long term trends. The total absolute stall time is
|
||||
tracked and exported as well, to allow detection of latency spikes
|
||||
which wouldn't necessarily make a dent in the time averages, or to
|
||||
average trends over custom time frames.
|
||||
|
||||
Cgroup2 interface
|
||||
=================
|
||||
|
||||
In a system with a CONFIG_CGROUP=y kernel and the cgroup2 filesystem
|
||||
mounted, pressure stall information is also tracked for tasks grouped
|
||||
into cgroups. Each subdirectory in the cgroupfs mountpoint contains
|
||||
cpu.pressure, memory.pressure, and io.pressure files; the format is
|
||||
the same as the /proc/pressure/ files.
|
||||
|
|
@ -966,6 +966,12 @@ All time durations are in microseconds.
|
|||
$PERIOD duration. "max" for $MAX indicates no limit. If only
|
||||
one number is written, $MAX is updated.
|
||||
|
||||
cpu.pressure
|
||||
A read-only nested-key file which exists on non-root cgroups.
|
||||
|
||||
Shows pressure stall information for CPU. See
|
||||
Documentation/accounting/psi.txt for details.
|
||||
|
||||
|
||||
Memory
|
||||
------
|
||||
|
|
@ -1127,6 +1133,10 @@ PAGE_SIZE multiple when read back.
|
|||
disk readahead. For now OOM in memory cgroup kills
|
||||
tasks iff shortage has happened inside page fault.
|
||||
|
||||
This event is not raised if the OOM killer is not
|
||||
considered as an option, e.g. for failed high-order
|
||||
allocations.
|
||||
|
||||
oom_kill
|
||||
The number of processes belonging to this cgroup
|
||||
killed by any kind of OOM killer.
|
||||
|
|
@ -1271,6 +1281,12 @@ PAGE_SIZE multiple when read back.
|
|||
higher than the limit for an extended period of time. This
|
||||
reduces the impact on the workload and memory management.
|
||||
|
||||
memory.pressure
|
||||
A read-only nested-key file which exists on non-root cgroups.
|
||||
|
||||
Shows pressure stall information for memory. See
|
||||
Documentation/accounting/psi.txt for details.
|
||||
|
||||
|
||||
Usage Guidelines
|
||||
~~~~~~~~~~~~~~~~
|
||||
|
|
@ -1408,6 +1424,12 @@ IO Interface Files
|
|||
|
||||
8:16 rbps=2097152 wbps=max riops=max wiops=max
|
||||
|
||||
io.pressure
|
||||
A read-only nested-key file which exists on non-root cgroups.
|
||||
|
||||
Shows pressure stall information for IO. See
|
||||
Documentation/accounting/psi.txt for details.
|
||||
|
||||
|
||||
Writeback
|
||||
~~~~~~~~~
|
||||
|
|
|
|||
|
|
@ -1759,6 +1759,18 @@
|
|||
nobypass [PPC/POWERNV]
|
||||
Disable IOMMU bypass, using IOMMU for PCI devices.
|
||||
|
||||
iommu.strict= [ARM64] Configure TLB invalidation behaviour
|
||||
Format: { "0" | "1" }
|
||||
0 - Lazy mode.
|
||||
Request that DMA unmap operations use deferred
|
||||
invalidation of hardware TLBs, for increased
|
||||
throughput at the cost of reduced device isolation.
|
||||
Will fall back to strict mode if not supported by
|
||||
the relevant IOMMU driver.
|
||||
1 - Strict mode (default).
|
||||
DMA unmap operations invalidate IOMMU hardware TLBs
|
||||
synchronously.
|
||||
|
||||
iommu.passthrough=
|
||||
[ARM64] Configure DMA to bypass the IOMMU by default.
|
||||
Format: { "0" | "1" }
|
||||
|
|
@ -2416,7 +2428,7 @@
|
|||
seconds. Use this parameter to check at some
|
||||
other rate. 0 disables periodic checking.
|
||||
|
||||
memtest= [KNL,X86,ARM] Enable memtest
|
||||
memtest= [KNL,X86,ARM,PPC] Enable memtest
|
||||
Format: <integer>
|
||||
default : 0 <disable>
|
||||
Specifies the number of memtest passes to be
|
||||
|
|
@ -4623,7 +4635,8 @@
|
|||
|
||||
usbcore.old_scheme_first=
|
||||
[USB] Start with the old device initialization
|
||||
scheme (default 0 = off).
|
||||
scheme, applies only to low and full-speed devices
|
||||
(default 0 = off).
|
||||
|
||||
usbcore.usbfs_memory_mb=
|
||||
[USB] Memory limit (in MB) for buffers allocated by
|
||||
|
|
@ -4838,6 +4851,18 @@
|
|||
This is actually a boot loader parameter; the value is
|
||||
passed to the kernel using a special protocol.
|
||||
|
||||
vm_debug[=options] [KNL] Available with CONFIG_DEBUG_VM=y.
|
||||
May slow down system boot speed, especially when
|
||||
enabled on systems with a large amount of memory.
|
||||
All options are enabled by default, and this
|
||||
interface is meant to allow for selectively
|
||||
enabling or disabling specific virtual memory
|
||||
debugging features.
|
||||
|
||||
Available options are:
|
||||
P Enable page structure init time poisoning
|
||||
- Disable all of the above options
|
||||
|
||||
vmalloc=nn[KMG] [KNL,BOOT] Forces the vmalloc area to have an exact
|
||||
size of <nn>. This can be used to increase the
|
||||
minimum size (128MB on x86). It can also be used to
|
||||
|
|
|
|||
|
|
@ -5,7 +5,7 @@ Memory Hotplug
|
|||
==============
|
||||
|
||||
:Created: Jul 28 2007
|
||||
:Updated: Add description of notifier of memory hotplug: Oct 11 2007
|
||||
:Updated: Add some details about locking internals: Aug 20 2018
|
||||
|
||||
This document is about memory hotplug including how-to-use and current status.
|
||||
Because Memory Hotplug is still under development, contents of this text will
|
||||
|
|
@ -392,6 +392,46 @@ Need more implementation yet....
|
|||
- Notification completion of remove works by OS to firmware.
|
||||
- Guard from remove if not yet.
|
||||
|
||||
|
||||
Locking Internals
|
||||
=================
|
||||
|
||||
When adding/removing memory that uses memory block devices (i.e. ordinary RAM),
|
||||
the device_hotplug_lock should be held to:
|
||||
|
||||
- synchronize against online/offline requests (e.g. via sysfs). This way, memory
|
||||
block devices can only be accessed (.online/.state attributes) by user
|
||||
space once memory has been fully added. And when removing memory, we
|
||||
know nobody is in critical sections.
|
||||
- synchronize against CPU hotplug and similar (e.g. relevant for ACPI and PPC)
|
||||
|
||||
Especially, there is a possible lock inversion that is avoided using
|
||||
device_hotplug_lock when adding memory and user space tries to online that
|
||||
memory faster than expected:
|
||||
|
||||
- device_online() will first take the device_lock(), followed by
|
||||
mem_hotplug_lock
|
||||
- add_memory_resource() will first take the mem_hotplug_lock, followed by
|
||||
the device_lock() (while creating the devices, during bus_add_device()).
|
||||
|
||||
As the device is visible to user space before taking the device_lock(), this
|
||||
can result in a lock inversion.
|
||||
|
||||
onlining/offlining of memory should be done via device_online()/
|
||||
device_offline() - to make sure it is properly synchronized to actions
|
||||
via sysfs. Holding device_hotplug_lock is advised (to e.g. protect online_type)
|
||||
|
||||
When adding/removing/onlining/offlining memory or adding/removing
|
||||
heterogeneous/device memory, we should always hold the mem_hotplug_lock in
|
||||
write mode to serialise memory hotplug (e.g. access to global/zone
|
||||
variables).
|
||||
|
||||
In addition, mem_hotplug_lock (in contrast to device_hotplug_lock) in read
|
||||
mode allows for a quite efficient get_online_mems/put_online_mems
|
||||
implementation, so code accessing memory can protect from that memory
|
||||
vanishing.
|
||||
|
||||
|
||||
Future Work
|
||||
===========
|
||||
|
||||
|
|
|
|||
|
|
@ -26,23 +26,34 @@ information is helpful. Any exploit code is very helpful and will not
|
|||
be released without consent from the reporter unless it has already been
|
||||
made public.
|
||||
|
||||
Disclosure
|
||||
----------
|
||||
Disclosure and embargoed information
|
||||
------------------------------------
|
||||
|
||||
The goal of the Linux kernel security team is to work with the bug
|
||||
submitter to understand and fix the bug. We prefer to publish the fix as
|
||||
soon as possible, but try to avoid public discussion of the bug itself
|
||||
and leave that to others.
|
||||
The security list is not a disclosure channel. For that, see Coordination
|
||||
below.
|
||||
|
||||
Publishing the fix may be delayed when the bug or the fix is not yet
|
||||
fully understood, the solution is not well-tested or for vendor
|
||||
coordination. However, we expect these delays to be short, measurable in
|
||||
days, not weeks or months. A release date is negotiated by the security
|
||||
team working with the bug submitter as well as vendors. However, the
|
||||
kernel security team holds the final say when setting a timeframe. The
|
||||
timeframe varies from immediate (esp. if it's already publicly known bug)
|
||||
to a few weeks. As a basic default policy, we expect report date to
|
||||
release date to be on the order of 7 days.
|
||||
Once a robust fix has been developed, our preference is to release the
|
||||
fix in a timely fashion, treating it no differently than any of the other
|
||||
thousands of changes and fixes the Linux kernel project releases every
|
||||
month.
|
||||
|
||||
However, at the request of the reporter, we will postpone releasing the
|
||||
fix for up to 5 business days after the date of the report or after the
|
||||
embargo has lifted; whichever comes first. The only exception to that
|
||||
rule is if the bug is publicly known, in which case the preference is to
|
||||
release the fix as soon as it's available.
|
||||
|
||||
Whilst embargoed information may be shared with trusted individuals in
|
||||
order to develop a fix, such information will not be published alongside
|
||||
the fix or on any other disclosure channel without the permission of the
|
||||
reporter. This includes but is not limited to the original bug report
|
||||
and followup discussions (if any), exploits, CVE information or the
|
||||
identity of the reporter.
|
||||
|
||||
In other words our only interest is in getting bugs fixed. All other
|
||||
information submitted to the security list and any followup discussions
|
||||
of the report are treated confidentially even after the embargo has been
|
||||
lifted, in perpetuity.
|
||||
|
||||
Coordination
|
||||
------------
|
||||
|
|
@ -68,7 +79,7 @@ may delay the bug handling. If a reporter wishes to have a CVE identifier
|
|||
assigned ahead of public disclosure, they will need to contact the private
|
||||
linux-distros list, described above. When such a CVE identifier is known
|
||||
before a patch is provided, it is desirable to mention it in the commit
|
||||
message, though.
|
||||
message if the reporter agrees.
|
||||
|
||||
Non-disclosure agreements
|
||||
-------------------------
|
||||
|
|
|
|||
|
|
@ -26,6 +26,7 @@ Offset Value Purpose
|
|||
0x20 0xfcba0d10 (Magic cookie) AFTR
|
||||
0x24 exynos_cpu_resume_ns AFTR
|
||||
0x28 + 4*cpu 0x8 (Magic cookie, Exynos3250) AFTR
|
||||
0x28 0x0 or last value during resume (Exynos542x) System suspend
|
||||
|
||||
|
||||
2. Secure mode
|
||||
|
|
|
|||
|
|
@ -27,7 +27,7 @@ cgroup.
|
|||
Currently user space applications can easily take away all the rdma verb
|
||||
specific resources such as AH, CQ, QP, MR etc. Due to which other applications
|
||||
in other cgroup or kernel space ULPs may not even get chance to allocate any
|
||||
rdma resources. This can leads to service unavailability.
|
||||
rdma resources. This can lead to service unavailability.
|
||||
|
||||
Therefore RDMA controller is needed through which resource consumption
|
||||
of processes can be limited. Through this controller different rdma
|
||||
|
|
|
|||
|
|
@ -5,54 +5,23 @@ Boot time memory management
|
|||
Early system initialization cannot use "normal" memory management
|
||||
simply because it is not set up yet. But there is still need to
|
||||
allocate memory for various data structures, for instance for the
|
||||
physical page allocator. To address this, a specialized allocator
|
||||
called the :ref:`Boot Memory Allocator <bootmem>`, or bootmem, was
|
||||
introduced. Several years later PowerPC developers added a "Logical
|
||||
Memory Blocks" allocator, which was later adopted by other
|
||||
architectures and renamed to :ref:`memblock <memblock>`. There is also
|
||||
a compatibility layer called `nobootmem` that translates bootmem
|
||||
allocation interfaces to memblock calls.
|
||||
physical page allocator.
|
||||
|
||||
The selection of the early allocator is done using
|
||||
``CONFIG_NO_BOOTMEM`` and ``CONFIG_HAVE_MEMBLOCK`` kernel
|
||||
configuration options. These options are enabled or disabled
|
||||
statically by the architectures' Kconfig files.
|
||||
|
||||
* Architectures that rely only on bootmem select
|
||||
``CONFIG_NO_BOOTMEM=n && CONFIG_HAVE_MEMBLOCK=n``.
|
||||
* The users of memblock with the nobootmem compatibility layer set
|
||||
``CONFIG_NO_BOOTMEM=y && CONFIG_HAVE_MEMBLOCK=y``.
|
||||
* And for those that use both memblock and bootmem the configuration
|
||||
includes ``CONFIG_NO_BOOTMEM=n && CONFIG_HAVE_MEMBLOCK=y``.
|
||||
|
||||
Whichever allocator is used, it is the responsibility of the
|
||||
architecture specific initialization to set it up in
|
||||
:c:func:`setup_arch` and tear it down in :c:func:`mem_init` functions.
|
||||
A specialized allocator called ``memblock`` performs the
|
||||
boot time memory management. The architecture specific initialization
|
||||
must set it up in :c:func:`setup_arch` and tear it down in
|
||||
:c:func:`mem_init` functions.
|
||||
|
||||
Once the early memory management is available it offers a variety of
|
||||
functions and macros for memory allocations. The allocation request
|
||||
may be directed to the first (and probably the only) node or to a
|
||||
particular node in a NUMA system. There are API variants that panic
|
||||
when an allocation fails and those that don't. And more recent and
|
||||
advanced memblock even allows controlling its own behaviour.
|
||||
when an allocation fails and those that don't.
|
||||
|
||||
.. _bootmem:
|
||||
Memblock also offers a variety of APIs that control its own behaviour.
|
||||
|
||||
Bootmem
|
||||
=======
|
||||
|
||||
(mostly stolen from Mel Gorman's "Understanding the Linux Virtual
|
||||
Memory Manager" `book`_)
|
||||
|
||||
.. _book: https://www.kernel.org/doc/gorman/
|
||||
|
||||
.. kernel-doc:: mm/bootmem.c
|
||||
:doc: bootmem overview
|
||||
|
||||
.. _memblock:
|
||||
|
||||
Memblock
|
||||
========
|
||||
Memblock Overview
|
||||
=================
|
||||
|
||||
.. kernel-doc:: mm/memblock.c
|
||||
:doc: memblock overview
|
||||
|
|
@ -61,26 +30,6 @@ Memblock
|
|||
Functions and structures
|
||||
========================
|
||||
|
||||
Common API
|
||||
----------
|
||||
|
||||
The functions that are described in this section are available
|
||||
regardless of what early memory manager is enabled.
|
||||
|
||||
.. kernel-doc:: mm/nobootmem.c
|
||||
|
||||
Bootmem specific API
|
||||
--------------------
|
||||
|
||||
These interfaces available only with bootmem, i.e when ``CONFIG_NO_BOOTMEM=n``
|
||||
|
||||
.. kernel-doc:: include/linux/bootmem.h
|
||||
.. kernel-doc:: mm/bootmem.c
|
||||
:functions:
|
||||
|
||||
Memblock specific API
|
||||
---------------------
|
||||
|
||||
Here is the description of memblock data structures, functions and
|
||||
macros. Some of them are actually internal, but since they are
|
||||
documented it would be silly to omit them. Besides, reading the
|
||||
|
|
|
|||
|
|
@ -21,6 +21,7 @@ Core utilities
|
|||
local_ops
|
||||
workqueue
|
||||
genericirq
|
||||
xarray
|
||||
flexible-arrays
|
||||
librs
|
||||
genalloc
|
||||
|
|
|
|||
|
|
@ -420,9 +420,8 @@ struct clk
|
|||
%pC pll1
|
||||
%pCn pll1
|
||||
|
||||
For printing struct clk structures. %pC and %pCn print the name
|
||||
(Common Clock Framework) or address (legacy clock framework) of the
|
||||
structure.
|
||||
For printing struct clk structures. %pC and %pCn print the name of the clock
|
||||
(Common Clock Framework) or a unique 32-bit ID (legacy clock framework).
|
||||
|
||||
Passed by reference.
|
||||
|
||||
|
|
|
|||
|
|
@ -0,0 +1,435 @@
|
|||
.. SPDX-License-Identifier: GPL-2.0+
|
||||
|
||||
======
|
||||
XArray
|
||||
======
|
||||
|
||||
:Author: Matthew Wilcox
|
||||
|
||||
Overview
|
||||
========
|
||||
|
||||
The XArray is an abstract data type which behaves like a very large array
|
||||
of pointers. It meets many of the same needs as a hash or a conventional
|
||||
resizable array. Unlike a hash, it allows you to sensibly go to the
|
||||
next or previous entry in a cache-efficient manner. In contrast to a
|
||||
resizable array, there is no need to copy data or change MMU mappings in
|
||||
order to grow the array. It is more memory-efficient, parallelisable
|
||||
and cache friendly than a doubly-linked list. It takes advantage of
|
||||
RCU to perform lookups without locking.
|
||||
|
||||
The XArray implementation is efficient when the indices used are densely
|
||||
clustered; hashing the object and using the hash as the index will not
|
||||
perform well. The XArray is optimised for small indices, but still has
|
||||
good performance with large indices. If your index can be larger than
|
||||
``ULONG_MAX`` then the XArray is not the data type for you. The most
|
||||
important user of the XArray is the page cache.
|
||||
|
||||
Each non-``NULL`` entry in the array has three bits associated with
|
||||
it called marks. Each mark may be set or cleared independently of
|
||||
the others. You can iterate over entries which are marked.
|
||||
|
||||
Normal pointers may be stored in the XArray directly. They must be 4-byte
|
||||
aligned, which is true for any pointer returned from :c:func:`kmalloc` and
|
||||
:c:func:`alloc_page`. It isn't true for arbitrary user-space pointers,
|
||||
nor for function pointers. You can store pointers to statically allocated
|
||||
objects, as long as those objects have an alignment of at least 4.
|
||||
|
||||
You can also store integers between 0 and ``LONG_MAX`` in the XArray.
|
||||
You must first convert it into an entry using :c:func:`xa_mk_value`.
|
||||
When you retrieve an entry from the XArray, you can check whether it is
|
||||
a value entry by calling :c:func:`xa_is_value`, and convert it back to
|
||||
an integer by calling :c:func:`xa_to_value`.
|
||||
|
||||
Some users want to store tagged pointers instead of using the marks
|
||||
described above. They can call :c:func:`xa_tag_pointer` to create an
|
||||
entry with a tag, :c:func:`xa_untag_pointer` to turn a tagged entry
|
||||
back into an untagged pointer and :c:func:`xa_pointer_tag` to retrieve
|
||||
the tag of an entry. Tagged pointers use the same bits that are used
|
||||
to distinguish value entries from normal pointers, so each user must
|
||||
decide whether they want to store value entries or tagged pointers in
|
||||
any particular XArray.
|
||||
|
||||
The XArray does not support storing :c:func:`IS_ERR` pointers as some
|
||||
conflict with value entries or internal entries.
|
||||
|
||||
An unusual feature of the XArray is the ability to create entries which
|
||||
occupy a range of indices. Once stored to, looking up any index in
|
||||
the range will return the same entry as looking up any other index in
|
||||
the range. Setting a mark on one index will set it on all of them.
|
||||
Storing to any index will store to all of them. Multi-index entries can
|
||||
be explicitly split into smaller entries, or storing ``NULL`` into any
|
||||
entry will cause the XArray to forget about the range.
|
||||
|
||||
Normal API
|
||||
==========
|
||||
|
||||
Start by initialising an XArray, either with :c:func:`DEFINE_XARRAY`
|
||||
for statically allocated XArrays or :c:func:`xa_init` for dynamically
|
||||
allocated ones. A freshly-initialised XArray contains a ``NULL``
|
||||
pointer at every index.
|
||||
|
||||
You can then set entries using :c:func:`xa_store` and get entries
|
||||
using :c:func:`xa_load`. xa_store will overwrite any entry with the
|
||||
new entry and return the previous entry stored at that index. You can
|
||||
use :c:func:`xa_erase` instead of calling :c:func:`xa_store` with a
|
||||
``NULL`` entry. There is no difference between an entry that has never
|
||||
been stored to and one that has most recently had ``NULL`` stored to it.
|
||||
|
||||
You can conditionally replace an entry at an index by using
|
||||
:c:func:`xa_cmpxchg`. Like :c:func:`cmpxchg`, it will only succeed if
|
||||
the entry at that index has the 'old' value. It also returns the entry
|
||||
which was at that index; if it returns the same entry which was passed as
|
||||
'old', then :c:func:`xa_cmpxchg` succeeded.
|
||||
|
||||
If you want to only store a new entry to an index if the current entry
|
||||
at that index is ``NULL``, you can use :c:func:`xa_insert` which
|
||||
returns ``-EEXIST`` if the entry is not empty.
|
||||
|
||||
You can enquire whether a mark is set on an entry by using
|
||||
:c:func:`xa_get_mark`. If the entry is not ``NULL``, you can set a mark
|
||||
on it by using :c:func:`xa_set_mark` and remove the mark from an entry by
|
||||
calling :c:func:`xa_clear_mark`. You can ask whether any entry in the
|
||||
XArray has a particular mark set by calling :c:func:`xa_marked`.
|
||||
|
||||
You can copy entries out of the XArray into a plain array by calling
|
||||
:c:func:`xa_extract`. Or you can iterate over the present entries in
|
||||
the XArray by calling :c:func:`xa_for_each`. You may prefer to use
|
||||
:c:func:`xa_find` or :c:func:`xa_find_after` to move to the next present
|
||||
entry in the XArray.
|
||||
|
||||
Calling :c:func:`xa_store_range` stores the same entry in a range
|
||||
of indices. If you do this, some of the other operations will behave
|
||||
in a slightly odd way. For example, marking the entry at one index
|
||||
may result in the entry being marked at some, but not all of the other
|
||||
indices. Storing into one index may result in the entry retrieved by
|
||||
some, but not all of the other indices changing.
|
||||
|
||||
Finally, you can remove all entries from an XArray by calling
|
||||
:c:func:`xa_destroy`. If the XArray entries are pointers, you may wish
|
||||
to free the entries first. You can do this by iterating over all present
|
||||
entries in the XArray using the :c:func:`xa_for_each` iterator.
|
||||
|
||||
ID assignment
|
||||
-------------
|
||||
|
||||
You can call :c:func:`xa_alloc` to store the entry at any unused index
|
||||
in the XArray. If you need to modify the array from interrupt context,
|
||||
you can use :c:func:`xa_alloc_bh` or :c:func:`xa_alloc_irq` to disable
|
||||
interrupts while allocating the ID. Unlike :c:func:`xa_store`, allocating
|
||||
a ``NULL`` pointer does not delete an entry. Instead it reserves an
|
||||
entry like :c:func:`xa_reserve` and you can release it using either
|
||||
:c:func:`xa_erase` or :c:func:`xa_release`. To use ID assignment, the
|
||||
XArray must be defined with :c:func:`DEFINE_XARRAY_ALLOC`, or initialised
|
||||
by passing ``XA_FLAGS_ALLOC`` to :c:func:`xa_init_flags`,
|
||||
|
||||
Memory allocation
|
||||
-----------------
|
||||
|
||||
The :c:func:`xa_store`, :c:func:`xa_cmpxchg`, :c:func:`xa_alloc`,
|
||||
:c:func:`xa_reserve` and :c:func:`xa_insert` functions take a gfp_t
|
||||
parameter in case the XArray needs to allocate memory to store this entry.
|
||||
If the entry is being deleted, no memory allocation needs to be performed,
|
||||
and the GFP flags specified will be ignored.
|
||||
|
||||
It is possible for no memory to be allocatable, particularly if you pass
|
||||
a restrictive set of GFP flags. In that case, the functions return a
|
||||
special value which can be turned into an errno using :c:func:`xa_err`.
|
||||
If you don't need to know exactly which error occurred, using
|
||||
:c:func:`xa_is_err` is slightly more efficient.
|
||||
|
||||
Locking
|
||||
-------
|
||||
|
||||
When using the Normal API, you do not have to worry about locking.
|
||||
The XArray uses RCU and an internal spinlock to synchronise access:
|
||||
|
||||
No lock needed:
|
||||
* :c:func:`xa_empty`
|
||||
* :c:func:`xa_marked`
|
||||
|
||||
Takes RCU read lock:
|
||||
* :c:func:`xa_load`
|
||||
* :c:func:`xa_for_each`
|
||||
* :c:func:`xa_find`
|
||||
* :c:func:`xa_find_after`
|
||||
* :c:func:`xa_extract`
|
||||
* :c:func:`xa_get_mark`
|
||||
|
||||
Takes xa_lock internally:
|
||||
* :c:func:`xa_store`
|
||||
* :c:func:`xa_insert`
|
||||
* :c:func:`xa_erase`
|
||||
* :c:func:`xa_erase_bh`
|
||||
* :c:func:`xa_erase_irq`
|
||||
* :c:func:`xa_cmpxchg`
|
||||
* :c:func:`xa_store_range`
|
||||
* :c:func:`xa_alloc`
|
||||
* :c:func:`xa_alloc_bh`
|
||||
* :c:func:`xa_alloc_irq`
|
||||
* :c:func:`xa_destroy`
|
||||
* :c:func:`xa_set_mark`
|
||||
* :c:func:`xa_clear_mark`
|
||||
|
||||
Assumes xa_lock held on entry:
|
||||
* :c:func:`__xa_store`
|
||||
* :c:func:`__xa_insert`
|
||||
* :c:func:`__xa_erase`
|
||||
* :c:func:`__xa_cmpxchg`
|
||||
* :c:func:`__xa_alloc`
|
||||
* :c:func:`__xa_set_mark`
|
||||
* :c:func:`__xa_clear_mark`
|
||||
|
||||
If you want to take advantage of the lock to protect the data structures
|
||||
that you are storing in the XArray, you can call :c:func:`xa_lock`
|
||||
before calling :c:func:`xa_load`, then take a reference count on the
|
||||
object you have found before calling :c:func:`xa_unlock`. This will
|
||||
prevent stores from removing the object from the array between looking
|
||||
up the object and incrementing the refcount. You can also use RCU to
|
||||
avoid dereferencing freed memory, but an explanation of that is beyond
|
||||
the scope of this document.
|
||||
|
||||
The XArray does not disable interrupts or softirqs while modifying
|
||||
the array. It is safe to read the XArray from interrupt or softirq
|
||||
context as the RCU lock provides enough protection.
|
||||
|
||||
If, for example, you want to store entries in the XArray in process
|
||||
context and then erase them in softirq context, you can do that this way::
|
||||
|
||||
void foo_init(struct foo *foo)
|
||||
{
|
||||
xa_init_flags(&foo->array, XA_FLAGS_LOCK_BH);
|
||||
}
|
||||
|
||||
int foo_store(struct foo *foo, unsigned long index, void *entry)
|
||||
{
|
||||
int err;
|
||||
|
||||
xa_lock_bh(&foo->array);
|
||||
err = xa_err(__xa_store(&foo->array, index, entry, GFP_KERNEL));
|
||||
if (!err)
|
||||
foo->count++;
|
||||
xa_unlock_bh(&foo->array);
|
||||
return err;
|
||||
}
|
||||
|
||||
/* foo_erase() is only called from softirq context */
|
||||
void foo_erase(struct foo *foo, unsigned long index)
|
||||
{
|
||||
xa_lock(&foo->array);
|
||||
__xa_erase(&foo->array, index);
|
||||
foo->count--;
|
||||
xa_unlock(&foo->array);
|
||||
}
|
||||
|
||||
If you are going to modify the XArray from interrupt or softirq context,
|
||||
you need to initialise the array using :c:func:`xa_init_flags`, passing
|
||||
``XA_FLAGS_LOCK_IRQ`` or ``XA_FLAGS_LOCK_BH``.
|
||||
|
||||
The above example also shows a common pattern of wanting to extend the
|
||||
coverage of the xa_lock on the store side to protect some statistics
|
||||
associated with the array.
|
||||
|
||||
Sharing the XArray with interrupt context is also possible, either
|
||||
using :c:func:`xa_lock_irqsave` in both the interrupt handler and process
|
||||
context, or :c:func:`xa_lock_irq` in process context and :c:func:`xa_lock`
|
||||
in the interrupt handler. Some of the more common patterns have helper
|
||||
functions such as :c:func:`xa_erase_bh` and :c:func:`xa_erase_irq`.
|
||||
|
||||
Sometimes you need to protect access to the XArray with a mutex because
|
||||
that lock sits above another mutex in the locking hierarchy. That does
|
||||
not entitle you to use functions like :c:func:`__xa_erase` without taking
|
||||
the xa_lock; the xa_lock is used for lockdep validation and will be used
|
||||
for other purposes in the future.
|
||||
|
||||
The :c:func:`__xa_set_mark` and :c:func:`__xa_clear_mark` functions are also
|
||||
available for situations where you look up an entry and want to atomically
|
||||
set or clear a mark. It may be more efficient to use the advanced API
|
||||
in this case, as it will save you from walking the tree twice.
|
||||
|
||||
Advanced API
|
||||
============
|
||||
|
||||
The advanced API offers more flexibility and better performance at the
|
||||
cost of an interface which can be harder to use and has fewer safeguards.
|
||||
No locking is done for you by the advanced API, and you are required
|
||||
to use the xa_lock while modifying the array. You can choose whether
|
||||
to use the xa_lock or the RCU lock while doing read-only operations on
|
||||
the array. You can mix advanced and normal operations on the same array;
|
||||
indeed the normal API is implemented in terms of the advanced API. The
|
||||
advanced API is only available to modules with a GPL-compatible license.
|
||||
|
||||
The advanced API is based around the xa_state. This is an opaque data
|
||||
structure which you declare on the stack using the :c:func:`XA_STATE`
|
||||
macro. This macro initialises the xa_state ready to start walking
|
||||
around the XArray. It is used as a cursor to maintain the position
|
||||
in the XArray and let you compose various operations together without
|
||||
having to restart from the top every time.
|
||||
|
||||
The xa_state is also used to store errors. You can call
|
||||
:c:func:`xas_error` to retrieve the error. All operations check whether
|
||||
the xa_state is in an error state before proceeding, so there's no need
|
||||
for you to check for an error after each call; you can make multiple
|
||||
calls in succession and only check at a convenient point. The only
|
||||
errors currently generated by the XArray code itself are ``ENOMEM`` and
|
||||
``EINVAL``, but it supports arbitrary errors in case you want to call
|
||||
:c:func:`xas_set_err` yourself.
|
||||
|
||||
If the xa_state is holding an ``ENOMEM`` error, calling :c:func:`xas_nomem`
|
||||
will attempt to allocate more memory using the specified gfp flags and
|
||||
cache it in the xa_state for the next attempt. The idea is that you take
|
||||
the xa_lock, attempt the operation and drop the lock. The operation
|
||||
attempts to allocate memory while holding the lock, but it is more
|
||||
likely to fail. Once you have dropped the lock, :c:func:`xas_nomem`
|
||||
can try harder to allocate more memory. It will return ``true`` if it
|
||||
is worth retrying the operation (i.e. that there was a memory error *and*
|
||||
more memory was allocated). If it has previously allocated memory, and
|
||||
that memory wasn't used, and there is no error (or some error that isn't
|
||||
``ENOMEM``), then it will free the memory previously allocated.
|
||||
|
||||
Internal Entries
|
||||
----------------
|
||||
|
||||
The XArray reserves some entries for its own purposes. These are never
|
||||
exposed through the normal API, but when using the advanced API, it's
|
||||
possible to see them. Usually the best way to handle them is to pass them
|
||||
to :c:func:`xas_retry`, and retry the operation if it returns ``true``.
|
||||
|
||||
.. flat-table::
|
||||
:widths: 1 1 6
|
||||
|
||||
* - Name
|
||||
- Test
|
||||
- Usage
|
||||
|
||||
* - Node
|
||||
- :c:func:`xa_is_node`
|
||||
- An XArray node. May be visible when using a multi-index xa_state.
|
||||
|
||||
* - Sibling
|
||||
- :c:func:`xa_is_sibling`
|
||||
- A non-canonical entry for a multi-index entry. The value indicates
|
||||
which slot in this node has the canonical entry.
|
||||
|
||||
* - Retry
|
||||
- :c:func:`xa_is_retry`
|
||||
- This entry is currently being modified by a thread which has the
|
||||
xa_lock. The node containing this entry may be freed at the end
|
||||
of this RCU period. You should restart the lookup from the head
|
||||
of the array.
|
||||
|
||||
* - Zero
|
||||
- :c:func:`xa_is_zero`
|
||||
- Zero entries appear as ``NULL`` through the Normal API, but occupy
|
||||
an entry in the XArray which can be used to reserve the index for
|
||||
future use.
|
||||
|
||||
Other internal entries may be added in the future. As far as possible, they
|
||||
will be handled by :c:func:`xas_retry`.
|
||||
|
||||
Additional functionality
|
||||
------------------------
|
||||
|
||||
The :c:func:`xas_create_range` function allocates all the necessary memory
|
||||
to store every entry in a range. It will set ENOMEM in the xa_state if
|
||||
it cannot allocate memory.
|
||||
|
||||
You can use :c:func:`xas_init_marks` to reset the marks on an entry
|
||||
to their default state. This is usually all marks clear, unless the
|
||||
XArray is marked with ``XA_FLAGS_TRACK_FREE``, in which case mark 0 is set
|
||||
and all other marks are clear. Replacing one entry with another using
|
||||
:c:func:`xas_store` will not reset the marks on that entry; if you want
|
||||
the marks reset, you should do that explicitly.
|
||||
|
||||
The :c:func:`xas_load` will walk the xa_state as close to the entry
|
||||
as it can. If you know the xa_state has already been walked to the
|
||||
entry and need to check that the entry hasn't changed, you can use
|
||||
:c:func:`xas_reload` to save a function call.
|
||||
|
||||
If you need to move to a different index in the XArray, call
|
||||
:c:func:`xas_set`. This resets the cursor to the top of the tree, which
|
||||
will generally make the next operation walk the cursor to the desired
|
||||
spot in the tree. If you want to move to the next or previous index,
|
||||
call :c:func:`xas_next` or :c:func:`xas_prev`. Setting the index does
|
||||
not walk the cursor around the array so does not require a lock to be
|
||||
held, while moving to the next or previous index does.
|
||||
|
||||
You can search for the next present entry using :c:func:`xas_find`. This
|
||||
is the equivalent of both :c:func:`xa_find` and :c:func:`xa_find_after`;
|
||||
if the cursor has been walked to an entry, then it will find the next
|
||||
entry after the one currently referenced. If not, it will return the
|
||||
entry at the index of the xa_state. Using :c:func:`xas_next_entry` to
|
||||
move to the next present entry instead of :c:func:`xas_find` will save
|
||||
a function call in the majority of cases at the expense of emitting more
|
||||
inline code.
|
||||
|
||||
The :c:func:`xas_find_marked` function is similar. If the xa_state has
|
||||
not been walked, it will return the entry at the index of the xa_state,
|
||||
if it is marked. Otherwise, it will return the first marked entry after
|
||||
the entry referenced by the xa_state. The :c:func:`xas_next_marked`
|
||||
function is the equivalent of :c:func:`xas_next_entry`.
|
||||
|
||||
When iterating over a range of the XArray using :c:func:`xas_for_each`
|
||||
or :c:func:`xas_for_each_marked`, it may be necessary to temporarily stop
|
||||
the iteration. The :c:func:`xas_pause` function exists for this purpose.
|
||||
After you have done the necessary work and wish to resume, the xa_state
|
||||
is in an appropriate state to continue the iteration after the entry
|
||||
you last processed. If you have interrupts disabled while iterating,
|
||||
then it is good manners to pause the iteration and reenable interrupts
|
||||
every ``XA_CHECK_SCHED`` entries.
|
||||
|
||||
The :c:func:`xas_get_mark`, :c:func:`xas_set_mark` and
|
||||
:c:func:`xas_clear_mark` functions require the xa_state cursor to have
|
||||
been moved to the appropriate location in the xarray; they will do
|
||||
nothing if you have called :c:func:`xas_pause` or :c:func:`xas_set`
|
||||
immediately before.
|
||||
|
||||
You can call :c:func:`xas_set_update` to have a callback function
|
||||
called each time the XArray updates a node. This is used by the page
|
||||
cache workingset code to maintain its list of nodes which contain only
|
||||
shadow entries.
|
||||
|
||||
Multi-Index Entries
|
||||
-------------------
|
||||
|
||||
The XArray has the ability to tie multiple indices together so that
|
||||
operations on one index affect all indices. For example, storing into
|
||||
any index will change the value of the entry retrieved from any index.
|
||||
Setting or clearing a mark on any index will set or clear the mark
|
||||
on every index that is tied together. The current implementation
|
||||
only allows tying ranges which are aligned powers of two together;
|
||||
eg indices 64-127 may be tied together, but 2-6 may not be. This may
|
||||
save substantial quantities of memory; for example tying 512 entries
|
||||
together will save over 4kB.
|
||||
|
||||
You can create a multi-index entry by using :c:func:`XA_STATE_ORDER`
|
||||
or :c:func:`xas_set_order` followed by a call to :c:func:`xas_store`.
|
||||
Calling :c:func:`xas_load` with a multi-index xa_state will walk the
|
||||
xa_state to the right location in the tree, but the return value is not
|
||||
meaningful, potentially being an internal entry or ``NULL`` even when there
|
||||
is an entry stored within the range. Calling :c:func:`xas_find_conflict`
|
||||
will return the first entry within the range or ``NULL`` if there are no
|
||||
entries in the range. The :c:func:`xas_for_each_conflict` iterator will
|
||||
iterate over every entry which overlaps the specified range.
|
||||
|
||||
If :c:func:`xas_load` encounters a multi-index entry, the xa_index
|
||||
in the xa_state will not be changed. When iterating over an XArray
|
||||
or calling :c:func:`xas_find`, if the initial index is in the middle
|
||||
of a multi-index entry, it will not be altered. Subsequent calls
|
||||
or iterations will move the index to the first index in the range.
|
||||
Each entry will only be returned once, no matter how many indices it
|
||||
occupies.
|
||||
|
||||
Using :c:func:`xas_next` or :c:func:`xas_prev` with a multi-index xa_state
|
||||
is not supported. Using either of these functions on a multi-index entry
|
||||
will reveal sibling entries; these should be skipped over by the caller.
|
||||
|
||||
Storing ``NULL`` into any index of a multi-index entry will set the entry
|
||||
at every index to ``NULL`` and dissolve the tie. Splitting a multi-index
|
||||
entry into entries occupying smaller ranges is not yet supported.
|
||||
|
||||
Functions and structures
|
||||
========================
|
||||
|
||||
.. kernel-doc:: include/linux/xarray.h
|
||||
.. kernel-doc:: lib/xarray.c
|
||||
|
|
@ -14,75 +14,3 @@ compatible: must contain "al,alpine"
|
|||
|
||||
...
|
||||
}
|
||||
|
||||
* CPU node:
|
||||
|
||||
The Alpine platform includes cortex-a15 cores.
|
||||
enable-method: must be "al,alpine-smp" to allow smp [1]
|
||||
|
||||
Example:
|
||||
|
||||
cpus {
|
||||
#address-cells = <1>;
|
||||
#size-cells = <0>;
|
||||
enable-method = "al,alpine-smp";
|
||||
|
||||
cpu@0 {
|
||||
compatible = "arm,cortex-a15";
|
||||
device_type = "cpu";
|
||||
reg = <0>;
|
||||
};
|
||||
|
||||
cpu@1 {
|
||||
compatible = "arm,cortex-a15";
|
||||
device_type = "cpu";
|
||||
reg = <1>;
|
||||
};
|
||||
|
||||
cpu@2 {
|
||||
compatible = "arm,cortex-a15";
|
||||
device_type = "cpu";
|
||||
reg = <2>;
|
||||
};
|
||||
|
||||
cpu@3 {
|
||||
compatible = "arm,cortex-a15";
|
||||
device_type = "cpu";
|
||||
reg = <3>;
|
||||
};
|
||||
};
|
||||
|
||||
|
||||
* Alpine CPU resume registers
|
||||
|
||||
The CPU resume register are used to define required resume address after
|
||||
reset.
|
||||
|
||||
Properties:
|
||||
- compatible : Should contain "al,alpine-cpu-resume".
|
||||
- reg : Offset and length of the register set for the device
|
||||
|
||||
Example:
|
||||
|
||||
cpu_resume {
|
||||
compatible = "al,alpine-cpu-resume";
|
||||
reg = <0xfbff5ed0 0x30>;
|
||||
};
|
||||
|
||||
* Alpine System-Fabric Service Registers
|
||||
|
||||
The System-Fabric Service Registers allow various operation on CPU and
|
||||
system fabric, like powering CPUs off.
|
||||
|
||||
Properties:
|
||||
- compatible : Should contain "al,alpine-sysfabric-service" and "syscon".
|
||||
- reg : Offset and length of the register set for the device
|
||||
|
||||
Example:
|
||||
|
||||
nb_service {
|
||||
compatible = "al,alpine-sysfabric-service", "syscon";
|
||||
reg = <0xfb070000 0x10000>;
|
||||
};
|
||||
|
||||
[1] arm/cpu-enable-method/al,alpine-smp
|
||||
|
|
|
|||
|
|
@ -57,12 +57,17 @@ Boards with the Amlogic Meson AXG A113D SoC shall have the following properties:
|
|||
Required root node property:
|
||||
compatible: "amlogic,a113d", "amlogic,meson-axg";
|
||||
|
||||
Boards with the Amlogic Meson G12A S905D2 SoC shall have the following properties:
|
||||
Required root node property:
|
||||
compatible: "amlogic,g12a";
|
||||
|
||||
Board compatible values (alphabetically, grouped by SoC):
|
||||
|
||||
- "geniatech,atv1200" (Meson6)
|
||||
|
||||
- "minix,neo-x8" (Meson8)
|
||||
|
||||
- "endless,ec100" (Meson8b)
|
||||
- "hardkernel,odroid-c1" (Meson8b)
|
||||
- "tronfy,mxq" (Meson8b)
|
||||
|
||||
|
|
@ -101,6 +106,8 @@ Board compatible values (alphabetically, grouped by SoC):
|
|||
|
||||
- "amlogic,s400" (Meson axg a113d)
|
||||
|
||||
- "amlogic,u200" (Meson g12a s905d2)
|
||||
|
||||
Amlogic Meson Firmware registers Interface
|
||||
------------------------------------------
|
||||
|
||||
|
|
|
|||
|
|
@ -70,173 +70,3 @@ compatible: must be one of:
|
|||
- "atmel,samv71q19"
|
||||
- "atmel,samv71q20"
|
||||
- "atmel,samv71q21"
|
||||
|
||||
Chipid required properties:
|
||||
- compatible: Should be "atmel,sama5d2-chipid"
|
||||
- reg : Should contain registers location and length
|
||||
|
||||
PIT Timer required properties:
|
||||
- compatible: Should be "atmel,at91sam9260-pit"
|
||||
- reg: Should contain registers location and length
|
||||
- interrupts: Should contain interrupt for the PIT which is the IRQ line
|
||||
shared across all System Controller members.
|
||||
|
||||
System Timer (ST) required properties:
|
||||
- compatible: Should be "atmel,at91rm9200-st", "syscon", "simple-mfd"
|
||||
- reg: Should contain registers location and length
|
||||
- interrupts: Should contain interrupt for the ST which is the IRQ line
|
||||
shared across all System Controller members.
|
||||
- clocks: phandle to input clock.
|
||||
Its subnodes can be:
|
||||
- watchdog: compatible should be "atmel,at91rm9200-wdt"
|
||||
|
||||
RSTC Reset Controller required properties:
|
||||
- compatible: Should be "atmel,<chip>-rstc".
|
||||
<chip> can be "at91sam9260" or "at91sam9g45" or "sama5d3"
|
||||
- reg: Should contain registers location and length
|
||||
- clocks: phandle to input clock.
|
||||
|
||||
Example:
|
||||
|
||||
rstc@fffffd00 {
|
||||
compatible = "atmel,at91sam9260-rstc";
|
||||
reg = <0xfffffd00 0x10>;
|
||||
clocks = <&clk32k>;
|
||||
};
|
||||
|
||||
RAMC SDRAM/DDR Controller required properties:
|
||||
- compatible: Should be "atmel,at91rm9200-sdramc", "syscon"
|
||||
"atmel,at91sam9260-sdramc",
|
||||
"atmel,at91sam9g45-ddramc",
|
||||
"atmel,sama5d3-ddramc",
|
||||
- reg: Should contain registers location and length
|
||||
|
||||
Examples:
|
||||
|
||||
ramc0: ramc@ffffe800 {
|
||||
compatible = "atmel,at91sam9g45-ddramc";
|
||||
reg = <0xffffe800 0x200>;
|
||||
};
|
||||
|
||||
SHDWC Shutdown Controller
|
||||
|
||||
required properties:
|
||||
- compatible: Should be "atmel,<chip>-shdwc".
|
||||
<chip> can be "at91sam9260", "at91sam9rl" or "at91sam9x5".
|
||||
- reg: Should contain registers location and length
|
||||
- clocks: phandle to input clock.
|
||||
|
||||
optional properties:
|
||||
- atmel,wakeup-mode: String, operation mode of the wakeup mode.
|
||||
Supported values are: "none", "high", "low", "any".
|
||||
- atmel,wakeup-counter: Counter on Wake-up 0 (between 0x0 and 0xf).
|
||||
|
||||
optional at91sam9260 properties:
|
||||
- atmel,wakeup-rtt-timer: boolean to enable Real-time Timer Wake-up.
|
||||
|
||||
optional at91sam9rl properties:
|
||||
- atmel,wakeup-rtc-timer: boolean to enable Real-time Clock Wake-up.
|
||||
- atmel,wakeup-rtt-timer: boolean to enable Real-time Timer Wake-up.
|
||||
|
||||
optional at91sam9x5 properties:
|
||||
- atmel,wakeup-rtc-timer: boolean to enable Real-time Clock Wake-up.
|
||||
|
||||
Example:
|
||||
|
||||
shdwc@fffffd10 {
|
||||
compatible = "atmel,at91sam9260-shdwc";
|
||||
reg = <0xfffffd10 0x10>;
|
||||
clocks = <&clk32k>;
|
||||
};
|
||||
|
||||
SHDWC SAMA5D2-Compatible Shutdown Controller
|
||||
|
||||
1) shdwc node
|
||||
|
||||
required properties:
|
||||
- compatible: should be "atmel,sama5d2-shdwc".
|
||||
- reg: should contain registers location and length
|
||||
- clocks: phandle to input clock.
|
||||
- #address-cells: should be one. The cell is the wake-up input index.
|
||||
- #size-cells: should be zero.
|
||||
|
||||
optional properties:
|
||||
|
||||
- debounce-delay-us: minimum wake-up inputs debouncer period in
|
||||
microseconds. It's usually a board-related property.
|
||||
- atmel,wakeup-rtc-timer: boolean to enable Real-Time Clock wake-up.
|
||||
|
||||
The node contains child nodes for each wake-up input that the platform uses.
|
||||
|
||||
2) input nodes
|
||||
|
||||
Wake-up input nodes are usually described in the "board" part of the Device
|
||||
Tree. Note also that input 0 is linked to the wake-up pin and is frequently
|
||||
used.
|
||||
|
||||
Required properties:
|
||||
- reg: should contain the wake-up input index [0 - 15].
|
||||
|
||||
Optional properties:
|
||||
- atmel,wakeup-active-high: boolean, the corresponding wake-up input described
|
||||
by the child, forces the wake-up of the core power supply on a high level.
|
||||
The default is to be active low.
|
||||
|
||||
Example:
|
||||
|
||||
On the SoC side:
|
||||
shdwc@f8048010 {
|
||||
compatible = "atmel,sama5d2-shdwc";
|
||||
reg = <0xf8048010 0x10>;
|
||||
clocks = <&clk32k>;
|
||||
#address-cells = <1>;
|
||||
#size-cells = <0>;
|
||||
atmel,wakeup-rtc-timer;
|
||||
};
|
||||
|
||||
On the board side:
|
||||
shdwc@f8048010 {
|
||||
debounce-delay-us = <976>;
|
||||
|
||||
input@0 {
|
||||
reg = <0>;
|
||||
};
|
||||
|
||||
input@1 {
|
||||
reg = <1>;
|
||||
atmel,wakeup-active-high;
|
||||
};
|
||||
};
|
||||
|
||||
Special Function Registers (SFR)
|
||||
|
||||
Special Function Registers (SFR) manage specific aspects of the integrated
|
||||
memory, bridge implementations, processor and other functionality not controlled
|
||||
elsewhere.
|
||||
|
||||
required properties:
|
||||
- compatible: Should be "atmel,<chip>-sfr", "syscon" or
|
||||
"atmel,<chip>-sfrbu", "syscon"
|
||||
<chip> can be "sama5d3", "sama5d4" or "sama5d2".
|
||||
- reg: Should contain registers location and length
|
||||
|
||||
sfr@f0038000 {
|
||||
compatible = "atmel,sama5d3-sfr", "syscon";
|
||||
reg = <0xf0038000 0x60>;
|
||||
};
|
||||
|
||||
Security Module (SECUMOD)
|
||||
|
||||
The Security Module macrocell provides all necessary secure functions to avoid
|
||||
voltage, temperature, frequency and mechanical attacks on the chip. It also
|
||||
embeds secure memories that can be scrambled
|
||||
|
||||
required properties:
|
||||
- compatible: Should be "atmel,<chip>-secumod", "syscon".
|
||||
<chip> can be "sama5d2".
|
||||
- reg: Should contain registers location and length
|
||||
|
||||
secumod@fc040000 {
|
||||
compatible = "atmel,sama5d2-secumod", "syscon";
|
||||
reg = <0xfc040000 0x100>;
|
||||
};
|
||||
|
|
|
|||
|
|
@ -0,0 +1,171 @@
|
|||
Atmel system registers
|
||||
|
||||
Chipid required properties:
|
||||
- compatible: Should be "atmel,sama5d2-chipid"
|
||||
- reg : Should contain registers location and length
|
||||
|
||||
PIT Timer required properties:
|
||||
- compatible: Should be "atmel,at91sam9260-pit"
|
||||
- reg: Should contain registers location and length
|
||||
- interrupts: Should contain interrupt for the PIT which is the IRQ line
|
||||
shared across all System Controller members.
|
||||
|
||||
System Timer (ST) required properties:
|
||||
- compatible: Should be "atmel,at91rm9200-st", "syscon", "simple-mfd"
|
||||
- reg: Should contain registers location and length
|
||||
- interrupts: Should contain interrupt for the ST which is the IRQ line
|
||||
shared across all System Controller members.
|
||||
- clocks: phandle to input clock.
|
||||
Its subnodes can be:
|
||||
- watchdog: compatible should be "atmel,at91rm9200-wdt"
|
||||
|
||||
RSTC Reset Controller required properties:
|
||||
- compatible: Should be "atmel,<chip>-rstc".
|
||||
<chip> can be "at91sam9260" or "at91sam9g45" or "sama5d3"
|
||||
- reg: Should contain registers location and length
|
||||
- clocks: phandle to input clock.
|
||||
|
||||
Example:
|
||||
|
||||
rstc@fffffd00 {
|
||||
compatible = "atmel,at91sam9260-rstc";
|
||||
reg = <0xfffffd00 0x10>;
|
||||
clocks = <&clk32k>;
|
||||
};
|
||||
|
||||
RAMC SDRAM/DDR Controller required properties:
|
||||
- compatible: Should be "atmel,at91rm9200-sdramc", "syscon"
|
||||
"atmel,at91sam9260-sdramc",
|
||||
"atmel,at91sam9g45-ddramc",
|
||||
"atmel,sama5d3-ddramc",
|
||||
- reg: Should contain registers location and length
|
||||
|
||||
Examples:
|
||||
|
||||
ramc0: ramc@ffffe800 {
|
||||
compatible = "atmel,at91sam9g45-ddramc";
|
||||
reg = <0xffffe800 0x200>;
|
||||
};
|
||||
|
||||
SHDWC Shutdown Controller
|
||||
|
||||
required properties:
|
||||
- compatible: Should be "atmel,<chip>-shdwc".
|
||||
<chip> can be "at91sam9260", "at91sam9rl" or "at91sam9x5".
|
||||
- reg: Should contain registers location and length
|
||||
- clocks: phandle to input clock.
|
||||
|
||||
optional properties:
|
||||
- atmel,wakeup-mode: String, operation mode of the wakeup mode.
|
||||
Supported values are: "none", "high", "low", "any".
|
||||
- atmel,wakeup-counter: Counter on Wake-up 0 (between 0x0 and 0xf).
|
||||
|
||||
optional at91sam9260 properties:
|
||||
- atmel,wakeup-rtt-timer: boolean to enable Real-time Timer Wake-up.
|
||||
|
||||
optional at91sam9rl properties:
|
||||
- atmel,wakeup-rtc-timer: boolean to enable Real-time Clock Wake-up.
|
||||
- atmel,wakeup-rtt-timer: boolean to enable Real-time Timer Wake-up.
|
||||
|
||||
optional at91sam9x5 properties:
|
||||
- atmel,wakeup-rtc-timer: boolean to enable Real-time Clock Wake-up.
|
||||
|
||||
Example:
|
||||
|
||||
shdwc@fffffd10 {
|
||||
compatible = "atmel,at91sam9260-shdwc";
|
||||
reg = <0xfffffd10 0x10>;
|
||||
clocks = <&clk32k>;
|
||||
};
|
||||
|
||||
SHDWC SAMA5D2-Compatible Shutdown Controller
|
||||
|
||||
1) shdwc node
|
||||
|
||||
required properties:
|
||||
- compatible: should be "atmel,sama5d2-shdwc".
|
||||
- reg: should contain registers location and length
|
||||
- clocks: phandle to input clock.
|
||||
- #address-cells: should be one. The cell is the wake-up input index.
|
||||
- #size-cells: should be zero.
|
||||
|
||||
optional properties:
|
||||
|
||||
- debounce-delay-us: minimum wake-up inputs debouncer period in
|
||||
microseconds. It's usually a board-related property.
|
||||
- atmel,wakeup-rtc-timer: boolean to enable Real-Time Clock wake-up.
|
||||
|
||||
The node contains child nodes for each wake-up input that the platform uses.
|
||||
|
||||
2) input nodes
|
||||
|
||||
Wake-up input nodes are usually described in the "board" part of the Device
|
||||
Tree. Note also that input 0 is linked to the wake-up pin and is frequently
|
||||
used.
|
||||
|
||||
Required properties:
|
||||
- reg: should contain the wake-up input index [0 - 15].
|
||||
|
||||
Optional properties:
|
||||
- atmel,wakeup-active-high: boolean, the corresponding wake-up input described
|
||||
by the child, forces the wake-up of the core power supply on a high level.
|
||||
The default is to be active low.
|
||||
|
||||
Example:
|
||||
|
||||
On the SoC side:
|
||||
shdwc@f8048010 {
|
||||
compatible = "atmel,sama5d2-shdwc";
|
||||
reg = <0xf8048010 0x10>;
|
||||
clocks = <&clk32k>;
|
||||
#address-cells = <1>;
|
||||
#size-cells = <0>;
|
||||
atmel,wakeup-rtc-timer;
|
||||
};
|
||||
|
||||
On the board side:
|
||||
shdwc@f8048010 {
|
||||
debounce-delay-us = <976>;
|
||||
|
||||
input@0 {
|
||||
reg = <0>;
|
||||
};
|
||||
|
||||
input@1 {
|
||||
reg = <1>;
|
||||
atmel,wakeup-active-high;
|
||||
};
|
||||
};
|
||||
|
||||
Special Function Registers (SFR)
|
||||
|
||||
Special Function Registers (SFR) manage specific aspects of the integrated
|
||||
memory, bridge implementations, processor and other functionality not controlled
|
||||
elsewhere.
|
||||
|
||||
required properties:
|
||||
- compatible: Should be "atmel,<chip>-sfr", "syscon" or
|
||||
"atmel,<chip>-sfrbu", "syscon"
|
||||
<chip> can be "sama5d3", "sama5d4" or "sama5d2".
|
||||
- reg: Should contain registers location and length
|
||||
|
||||
sfr@f0038000 {
|
||||
compatible = "atmel,sama5d3-sfr", "syscon";
|
||||
reg = <0xf0038000 0x60>;
|
||||
};
|
||||
|
||||
Security Module (SECUMOD)
|
||||
|
||||
The Security Module macrocell provides all necessary secure functions to avoid
|
||||
voltage, temperature, frequency and mechanical attacks on the chip. It also
|
||||
embeds secure memories that can be scrambled
|
||||
|
||||
required properties:
|
||||
- compatible: Should be "atmel,<chip>-secumod", "syscon".
|
||||
<chip> can be "sama5d2".
|
||||
- reg: Should contain registers location and length
|
||||
|
||||
secumod@fc040000 {
|
||||
compatible = "atmel,sama5d2-secumod", "syscon";
|
||||
reg = <0xfc040000 0x100>;
|
||||
};
|
||||
|
|
@ -42,6 +42,14 @@ Raspberry Pi Compute Module
|
|||
Required root node properties:
|
||||
compatible = "raspberrypi,compute-module", "brcm,bcm2835";
|
||||
|
||||
Raspberry Pi Compute Module 3
|
||||
Required root node properties:
|
||||
compatible = "raspberrypi,3-compute-module", "brcm,bcm2837";
|
||||
|
||||
Raspberry Pi Compute Module 3 Lite
|
||||
Required root node properties:
|
||||
compatible = "raspberrypi,3-compute-module-lite", "brcm,bcm2837";
|
||||
|
||||
Raspberry Pi Zero
|
||||
Required root node properties:
|
||||
compatible = "raspberrypi,model-zero", "brcm,bcm2835";
|
||||
|
|
|
|||
|
|
@ -54,9 +54,7 @@ its hardware characteristcs.
|
|||
clocks the core of that coresight component. The latter clock
|
||||
is optional.
|
||||
|
||||
* port or ports: The representation of the component's port
|
||||
layout using the generic DT graph presentation found in
|
||||
"bindings/graph.txt".
|
||||
* port or ports: see "Graph bindings for Coresight" below.
|
||||
|
||||
* Additional required properties for System Trace Macrocells (STM):
|
||||
* reg: along with the physical base address and length of the register
|
||||
|
|
@ -73,7 +71,7 @@ its hardware characteristcs.
|
|||
AMBA markee):
|
||||
- "arm,coresight-replicator"
|
||||
|
||||
* port or ports: same as above.
|
||||
* port or ports: see "Graph bindings for Coresight" below.
|
||||
|
||||
* Optional properties for ETM/PTMs:
|
||||
|
||||
|
|
@ -96,6 +94,20 @@ its hardware characteristcs.
|
|||
* interrupts : Exactly one SPI may be listed for reporting the address
|
||||
error
|
||||
|
||||
Graph bindings for Coresight
|
||||
-------------------------------
|
||||
|
||||
Coresight components are interconnected to create a data path for the flow of
|
||||
trace data generated from the "sources" to their collection points "sink".
|
||||
Each coresight component must describe the "input" and "output" connections.
|
||||
The connections must be described via generic DT graph bindings as described
|
||||
by the "bindings/graph.txt", where each "port" along with an "endpoint"
|
||||
component represents a hardware port and the connection.
|
||||
|
||||
* All output ports must be listed inside a child node named "out-ports"
|
||||
* All input ports must be listed inside a child node named "in-ports".
|
||||
* Port address must match the hardware port number.
|
||||
|
||||
Example:
|
||||
|
||||
1. Sinks
|
||||
|
|
@ -105,10 +117,11 @@ Example:
|
|||
|
||||
clocks = <&oscclk6a>;
|
||||
clock-names = "apb_pclk";
|
||||
port {
|
||||
etb_in_port: endpoint@0 {
|
||||
slave-mode;
|
||||
remote-endpoint = <&replicator_out_port0>;
|
||||
in-ports {
|
||||
port {
|
||||
etb_in_port: endpoint@0 {
|
||||
remote-endpoint = <&replicator_out_port0>;
|
||||
};
|
||||
};
|
||||
};
|
||||
};
|
||||
|
|
@ -119,10 +132,11 @@ Example:
|
|||
|
||||
clocks = <&oscclk6a>;
|
||||
clock-names = "apb_pclk";
|
||||
port {
|
||||
tpiu_in_port: endpoint@0 {
|
||||
slave-mode;
|
||||
remote-endpoint = <&replicator_out_port1>;
|
||||
in-ports {
|
||||
port {
|
||||
tpiu_in_port: endpoint@0 {
|
||||
remote-endpoint = <&replicator_out_port1>;
|
||||
};
|
||||
};
|
||||
};
|
||||
};
|
||||
|
|
@ -133,22 +147,16 @@ Example:
|
|||
|
||||
clocks = <&oscclk6a>;
|
||||
clock-names = "apb_pclk";
|
||||
ports {
|
||||
#address-cells = <1>;
|
||||
#size-cells = <0>;
|
||||
|
||||
/* input port */
|
||||
port@0 {
|
||||
reg = <0>;
|
||||
in-ports {
|
||||
port {
|
||||
etr_in_port: endpoint {
|
||||
slave-mode;
|
||||
remote-endpoint = <&replicator2_out_port0>;
|
||||
};
|
||||
};
|
||||
};
|
||||
|
||||
/* CATU link represented by output port */
|
||||
port@1 {
|
||||
reg = <1>;
|
||||
out-ports {
|
||||
port {
|
||||
etr_out_port: endpoint {
|
||||
remote-endpoint = <&catu_in_port>;
|
||||
};
|
||||
|
|
@ -163,7 +171,7 @@ Example:
|
|||
*/
|
||||
compatible = "arm,coresight-replicator";
|
||||
|
||||
ports {
|
||||
out-ports {
|
||||
#address-cells = <1>;
|
||||
#size-cells = <0>;
|
||||
|
||||
|
|
@ -181,12 +189,11 @@ Example:
|
|||
remote-endpoint = <&tpiu_in_port>;
|
||||
};
|
||||
};
|
||||
};
|
||||
|
||||
/* replicator input port */
|
||||
port@2 {
|
||||
reg = <0>;
|
||||
in-ports {
|
||||
port {
|
||||
replicator_in_port0: endpoint {
|
||||
slave-mode;
|
||||
remote-endpoint = <&funnel_out_port0>;
|
||||
};
|
||||
};
|
||||
|
|
@ -199,40 +206,36 @@ Example:
|
|||
|
||||
clocks = <&oscclk6a>;
|
||||
clock-names = "apb_pclk";
|
||||
ports {
|
||||
#address-cells = <1>;
|
||||
#size-cells = <0>;
|
||||
|
||||
/* funnel output port */
|
||||
port@0 {
|
||||
reg = <0>;
|
||||
out-ports {
|
||||
port {
|
||||
funnel_out_port0: endpoint {
|
||||
remote-endpoint =
|
||||
<&replicator_in_port0>;
|
||||
};
|
||||
};
|
||||
};
|
||||
|
||||
/* funnel input ports */
|
||||
port@1 {
|
||||
in-ports {
|
||||
#address-cells = <1>;
|
||||
#size-cells = <0>;
|
||||
|
||||
port@0 {
|
||||
reg = <0>;
|
||||
funnel_in_port0: endpoint {
|
||||
slave-mode;
|
||||
remote-endpoint = <&ptm0_out_port>;
|
||||
};
|
||||
};
|
||||
|
||||
port@2 {
|
||||
port@1 {
|
||||
reg = <1>;
|
||||
funnel_in_port1: endpoint {
|
||||
slave-mode;
|
||||
remote-endpoint = <&ptm1_out_port>;
|
||||
};
|
||||
};
|
||||
|
||||
port@3 {
|
||||
port@2 {
|
||||
reg = <2>;
|
||||
funnel_in_port2: endpoint {
|
||||
slave-mode;
|
||||
remote-endpoint = <&etm0_out_port>;
|
||||
};
|
||||
};
|
||||
|
|
@ -248,9 +251,11 @@ Example:
|
|||
cpu = <&cpu0>;
|
||||
clocks = <&oscclk6a>;
|
||||
clock-names = "apb_pclk";
|
||||
port {
|
||||
ptm0_out_port: endpoint {
|
||||
remote-endpoint = <&funnel_in_port0>;
|
||||
out-ports {
|
||||
port {
|
||||
ptm0_out_port: endpoint {
|
||||
remote-endpoint = <&funnel_in_port0>;
|
||||
};
|
||||
};
|
||||
};
|
||||
};
|
||||
|
|
@ -262,9 +267,11 @@ Example:
|
|||
cpu = <&cpu1>;
|
||||
clocks = <&oscclk6a>;
|
||||
clock-names = "apb_pclk";
|
||||
port {
|
||||
ptm1_out_port: endpoint {
|
||||
remote-endpoint = <&funnel_in_port1>;
|
||||
out-ports {
|
||||
port {
|
||||
ptm1_out_port: endpoint {
|
||||
remote-endpoint = <&funnel_in_port1>;
|
||||
};
|
||||
};
|
||||
};
|
||||
};
|
||||
|
|
@ -278,9 +285,11 @@ Example:
|
|||
|
||||
clocks = <&soc_smc50mhz>;
|
||||
clock-names = "apb_pclk";
|
||||
port {
|
||||
stm_out_port: endpoint {
|
||||
remote-endpoint = <&main_funnel_in_port2>;
|
||||
out-ports {
|
||||
port {
|
||||
stm_out_port: endpoint {
|
||||
remote-endpoint = <&main_funnel_in_port2>;
|
||||
};
|
||||
};
|
||||
};
|
||||
};
|
||||
|
|
@ -295,10 +304,11 @@ Example:
|
|||
clock-names = "apb_pclk";
|
||||
|
||||
interrupts = <GIC_SPI 4 IRQ_TYPE_LEVEL_HIGH>;
|
||||
port {
|
||||
catu_in_port: endpoint {
|
||||
slave-mode;
|
||||
remote-endpoint = <&etr_out_port>;
|
||||
in-ports {
|
||||
port {
|
||||
catu_in_port: endpoint {
|
||||
remote-endpoint = <&etr_out_port>;
|
||||
};
|
||||
};
|
||||
};
|
||||
};
|
||||
|
|
|
|||
|
|
@ -14,7 +14,28 @@ Related properties: (none)
|
|||
|
||||
Note:
|
||||
This enable method requires valid nodes compatible with
|
||||
"al,alpine-cpu-resume" and "al,alpine-nb-service"[1].
|
||||
"al,alpine-cpu-resume" and "al,alpine-nb-service".
|
||||
|
||||
|
||||
* Alpine CPU resume registers
|
||||
|
||||
The CPU resume register are used to define required resume address after
|
||||
reset.
|
||||
|
||||
Properties:
|
||||
- compatible : Should contain "al,alpine-cpu-resume".
|
||||
- reg : Offset and length of the register set for the device
|
||||
|
||||
|
||||
* Alpine System-Fabric Service Registers
|
||||
|
||||
The System-Fabric Service Registers allow various operation on CPU and
|
||||
system fabric, like powering CPUs off.
|
||||
|
||||
Properties:
|
||||
- compatible : Should contain "al,alpine-sysfabric-service" and "syscon".
|
||||
- reg : Offset and length of the register set for the device
|
||||
|
||||
|
||||
Example:
|
||||
|
||||
|
|
@ -48,5 +69,12 @@ cpus {
|
|||
};
|
||||
};
|
||||
|
||||
--
|
||||
[1] arm/al,alpine.txt
|
||||
cpu_resume {
|
||||
compatible = "al,alpine-cpu-resume";
|
||||
reg = <0xfbff5ed0 0x30>;
|
||||
};
|
||||
|
||||
nb_service {
|
||||
compatible = "al,alpine-sysfabric-service", "syscon";
|
||||
reg = <0xfb070000 0x10000>;
|
||||
};
|
||||
|
|
|
|||
|
|
@ -276,7 +276,7 @@ described below.
|
|||
Usage: optional
|
||||
Value type: <prop-encoded-array>
|
||||
Definition: A u32 value that represents the running time dynamic
|
||||
power coefficient in units of mW/MHz/uV^2. The
|
||||
power coefficient in units of uW/MHz/V^2. The
|
||||
coefficient can either be calculated from power
|
||||
measurements or derived by analysis.
|
||||
|
||||
|
|
@ -287,7 +287,7 @@ described below.
|
|||
|
||||
Pdyn = dynamic-power-coefficient * V^2 * f
|
||||
|
||||
where voltage is in uV, frequency is in MHz.
|
||||
where voltage is in V, frequency is in MHz.
|
||||
|
||||
Example 1 (dual-cluster big.LITTLE system 32-bit):
|
||||
|
||||
|
|
|
|||
|
|
@ -0,0 +1,19 @@
|
|||
Freescale DCFG
|
||||
|
||||
DCFG is the device configuration unit, that provides general purpose
|
||||
configuration and status for the device. Such as setting the secondary
|
||||
core start address and release the secondary core from holdoff and startup.
|
||||
|
||||
Required properties:
|
||||
- compatible: Should contain a chip-specific compatible string,
|
||||
Chip-specific strings are of the form "fsl,<chip>-dcfg",
|
||||
The following <chip>s are known to be supported:
|
||||
ls1012a, ls1021a, ls1043a, ls1046a, ls2080a.
|
||||
|
||||
- reg : should contain base address and length of DCFG memory-mapped registers
|
||||
|
||||
Example:
|
||||
dcfg: dcfg@1ee0000 {
|
||||
compatible = "fsl,ls1021a-dcfg";
|
||||
reg = <0x0 0x1ee0000 0x0 0x10000>;
|
||||
};
|
||||
|
|
@ -0,0 +1,19 @@
|
|||
Freescale SCFG
|
||||
|
||||
SCFG is the supplemental configuration unit, that provides SoC specific
|
||||
configuration and status registers for the chip. Such as getting PEX port
|
||||
status.
|
||||
|
||||
Required properties:
|
||||
- compatible: Should contain a chip-specific compatible string,
|
||||
Chip-specific strings are of the form "fsl,<chip>-scfg",
|
||||
The following <chip>s are known to be supported:
|
||||
ls1012a, ls1021a, ls1043a, ls1046a, ls2080a.
|
||||
|
||||
- reg: should contain base address and length of SCFG memory-mapped registers
|
||||
|
||||
Example:
|
||||
scfg: scfg@1570000 {
|
||||
compatible = "fsl,ls1021a-scfg";
|
||||
reg = <0x0 0x1570000 0x0 0x10000>;
|
||||
};
|
||||
|
|
@ -0,0 +1,183 @@
|
|||
NXP i.MX System Controller Firmware (SCFW)
|
||||
--------------------------------------------------------------------
|
||||
|
||||
The System Controller Firmware (SCFW) is a low-level system function
|
||||
which runs on a dedicated Cortex-M core to provide power, clock, and
|
||||
resource management. It exists on some i.MX8 processors. e.g. i.MX8QM
|
||||
(QM, QP), and i.MX8QX (QXP, DX).
|
||||
|
||||
The AP communicates with the SC using a multi-ported MU module found
|
||||
in the LSIO subsystem. The current definition of this MU module provides
|
||||
5 remote AP connections to the SC to support up to 5 execution environments
|
||||
(TZ, HV, standard Linux, etc.). The SC side of this MU module interfaces
|
||||
with the LSIO DSC IP bus. The SC firmware will communicate with this MU
|
||||
using the MSI bus.
|
||||
|
||||
System Controller Device Node:
|
||||
============================================================
|
||||
|
||||
The scu node with the following properties shall be under the /firmware/ node.
|
||||
|
||||
Required properties:
|
||||
-------------------
|
||||
- compatible: should be "fsl,imx-scu".
|
||||
- mbox-names: should include "tx0", "tx1", "tx2", "tx3",
|
||||
"rx0", "rx1", "rx2", "rx3".
|
||||
- mboxes: List of phandle of 4 MU channels for tx and 4 MU channels
|
||||
for rx. All 8 MU channels must be in the same MU instance.
|
||||
Cross instances are not allowed. The MU instance can only
|
||||
be one of LSIO MU0~M4 for imx8qxp and imx8qm. Users need
|
||||
to make sure use the one which is not conflict with other
|
||||
execution environments. e.g. ATF.
|
||||
Note:
|
||||
Channel 0 must be "tx0" or "rx0".
|
||||
Channel 1 must be "tx1" or "rx1".
|
||||
Channel 2 must be "tx2" or "rx2".
|
||||
Channel 3 must be "tx3" or "rx3".
|
||||
e.g.
|
||||
mboxes = <&lsio_mu1 0 0
|
||||
&lsio_mu1 0 1
|
||||
&lsio_mu1 0 2
|
||||
&lsio_mu1 0 3
|
||||
&lsio_mu1 1 0
|
||||
&lsio_mu1 1 1
|
||||
&lsio_mu1 1 2
|
||||
&lsio_mu1 1 3>;
|
||||
See Documentation/devicetree/bindings/mailbox/fsl,mu.txt
|
||||
for detailed mailbox binding.
|
||||
|
||||
i.MX SCU Client Device Node:
|
||||
============================================================
|
||||
|
||||
Client nodes are maintained as children of the relevant IMX-SCU device node.
|
||||
|
||||
Power domain bindings based on SCU Message Protocol
|
||||
------------------------------------------------------------
|
||||
|
||||
This binding for the SCU power domain providers uses the generic power
|
||||
domain binding[2].
|
||||
|
||||
Required properties:
|
||||
- compatible: Should be "fsl,scu-pd".
|
||||
- #address-cells: Should be 1.
|
||||
- #size-cells: Should be 0.
|
||||
|
||||
Required properties for power domain sub nodes:
|
||||
- #power-domain-cells: Must be 0.
|
||||
|
||||
Optional Properties:
|
||||
- reg: Resource ID of this power domain.
|
||||
No exist means uncontrollable by user.
|
||||
See detailed Resource ID list from:
|
||||
include/dt-bindings/power/imx-rsrc.h
|
||||
- power-domains: phandle pointing to the parent power domain.
|
||||
|
||||
Clock bindings based on SCU Message Protocol
|
||||
------------------------------------------------------------
|
||||
|
||||
This binding uses the common clock binding[1].
|
||||
|
||||
Required properties:
|
||||
- compatible: Should be "fsl,imx8qxp-clock".
|
||||
- #clock-cells: Should be 1. Contains the Clock ID value.
|
||||
- clocks: List of clock specifiers, must contain an entry for
|
||||
each required entry in clock-names
|
||||
- clock-names: Should include entries "xtal_32KHz", "xtal_24MHz"
|
||||
|
||||
The clock consumer should specify the desired clock by having the clock
|
||||
ID in its "clocks" phandle cell.
|
||||
|
||||
See the full list of clock IDs from:
|
||||
include/dt-bindings/clock/imx8qxp-clock.h
|
||||
|
||||
Pinctrl bindings based on SCU Message Protocol
|
||||
------------------------------------------------------------
|
||||
|
||||
This binding uses the i.MX common pinctrl binding[3].
|
||||
|
||||
Required properties:
|
||||
- compatible: Should be "fsl,imx8qxp-iomuxc".
|
||||
|
||||
Required properties for Pinctrl sub nodes:
|
||||
- fsl,pins: Each entry consists of 3 integers which represents
|
||||
the mux and config setting for one pin. The first 2
|
||||
integers <pin_id mux_mode> are specified using a
|
||||
PIN_FUNC_ID macro, which can be found in
|
||||
<dt-bindings/pinctrl/pads-imx8qxp.h>.
|
||||
The last integer CONFIG is the pad setting value like
|
||||
pull-up on this pin.
|
||||
|
||||
Please refer to i.MX8QXP Reference Manual for detailed
|
||||
CONFIG settings.
|
||||
|
||||
[1] Documentation/devicetree/bindings/clock/clock-bindings.txt
|
||||
[2] Documentation/devicetree/bindings/power/power_domain.txt
|
||||
[3] Documentation/devicetree/bindings/pinctrl/fsl,imx-pinctrl.txt
|
||||
|
||||
Example (imx8qxp):
|
||||
-------------
|
||||
lsio_mu1: mailbox@5d1c0000 {
|
||||
...
|
||||
#mbox-cells = <2>;
|
||||
};
|
||||
|
||||
firmware {
|
||||
scu {
|
||||
compatible = "fsl,imx-scu";
|
||||
mbox-names = "tx0", "tx1", "tx2", "tx3",
|
||||
"rx0", "rx1", "rx2", "rx3";
|
||||
mboxes = <&lsio_mu1 0 0
|
||||
&lsio_mu1 0 1
|
||||
&lsio_mu1 0 2
|
||||
&lsio_mu1 0 3
|
||||
&lsio_mu1 1 0
|
||||
&lsio_mu1 1 1
|
||||
&lsio_mu1 1 2
|
||||
&lsio_mu1 1 3>;
|
||||
|
||||
clk: clk {
|
||||
compatible = "fsl,imx8qxp-clk";
|
||||
#clock-cells = <1>;
|
||||
};
|
||||
|
||||
iomuxc {
|
||||
compatible = "fsl,imx8qxp-iomuxc";
|
||||
|
||||
pinctrl_lpuart0: lpuart0grp {
|
||||
fsl,pins = <
|
||||
SC_P_UART0_RX_ADMA_UART0_RX 0x06000020
|
||||
SC_P_UART0_TX_ADMA_UART0_TX 0x06000020
|
||||
>;
|
||||
};
|
||||
...
|
||||
};
|
||||
|
||||
imx8qx-pm {
|
||||
compatible = "fsl,scu-pd";
|
||||
#address-cells = <1>;
|
||||
#size-cells = <0>;
|
||||
|
||||
pd_dma: dma-power-domain {
|
||||
#power-domain-cells = <0>;
|
||||
|
||||
pd_dma_lpuart0: dma-lpuart0@57 {
|
||||
reg = <SC_R_UART_0>;
|
||||
#power-domain-cells = <0>;
|
||||
power-domains = <&pd_dma>;
|
||||
};
|
||||
...
|
||||
};
|
||||
...
|
||||
};
|
||||
};
|
||||
};
|
||||
|
||||
serial@5a060000 {
|
||||
...
|
||||
pinctrl-names = "default";
|
||||
pinctrl-0 = <&pinctrl_lpuart0>;
|
||||
clocks = <&clk IMX8QXP_UART0_CLK>,
|
||||
<&clk IMX8QXP_UART0_IPG_CLK>;
|
||||
clock-names = "per", "ipg";
|
||||
power-domains = <&pd_dma_lpuart0>;
|
||||
};
|
||||
|
|
@ -57,6 +57,50 @@ i.MX6SLL EVK board
|
|||
Required root node properties:
|
||||
- compatible = "fsl,imx6sll-evk", "fsl,imx6sll";
|
||||
|
||||
i.MX6 Quad Plus SABRE Smart Device Board
|
||||
Required root node properties:
|
||||
- compatible = "fsl,imx6qp-sabresd", "fsl,imx6qp";
|
||||
|
||||
i.MX6 Quad Plus SABRE Automotive Board
|
||||
Required root node properties:
|
||||
- compatible = "fsl,imx6qp-sabreauto", "fsl,imx6qp";
|
||||
|
||||
i.MX6 DualLite SABRE Smart Device Board
|
||||
Required root node properties:
|
||||
- compatible = "fsl,imx6dl-sabresd", "fsl,imx6dl";
|
||||
|
||||
i.MX6 DualLite/Solo SABRE Automotive Board
|
||||
Required root node properties:
|
||||
- compatible = "fsl,imx6dl-sabreauto", "fsl,imx6dl";
|
||||
|
||||
i.MX6 SoloLite EVK Board
|
||||
Required root node properties:
|
||||
- compatible = "fsl,imx6sl-evk", "fsl,imx6sl";
|
||||
|
||||
i.MX6 UltraLite 14x14 EVK Board
|
||||
Required root node properties:
|
||||
- compatible = "fsl,imx6ul-14x14-evk", "fsl,imx6ul";
|
||||
|
||||
i.MX6 UltraLiteLite 14x14 EVK Board
|
||||
Required root node properties:
|
||||
- compatible = "fsl,imx6ull-14x14-evk", "fsl,imx6ull";
|
||||
|
||||
i.MX6 ULZ 14x14 EVK Board
|
||||
Required root node properties:
|
||||
- compatible = "fsl,imx6ulz-14x14-evk", "fsl,imx6ull", "fsl,imx6ulz";
|
||||
|
||||
i.MX6 SoloX SDB Board
|
||||
Required root node properties:
|
||||
- compatible = "fsl,imx6sx-sdb", "fsl,imx6sx";
|
||||
|
||||
i.MX6 SoloX Sabre Auto Board
|
||||
Required root node properties:
|
||||
- compatible = "fsl,imx6sx-sabreauto", "fsl,imx6sx";
|
||||
|
||||
i.MX7 SabreSD Board
|
||||
Required root node properties:
|
||||
- compatible = "fsl,imx7d-sdb", "fsl,imx7d";
|
||||
|
||||
Generic i.MX boards
|
||||
-------------------
|
||||
|
||||
|
|
@ -101,45 +145,6 @@ Freescale LS1021A Platform Device Tree Bindings
|
|||
Required root node compatible properties:
|
||||
- compatible = "fsl,ls1021a";
|
||||
|
||||
Freescale SoC-specific Device Tree Bindings
|
||||
-------------------------------------------
|
||||
|
||||
Freescale SCFG
|
||||
SCFG is the supplemental configuration unit, that provides SoC specific
|
||||
configuration and status registers for the chip. Such as getting PEX port
|
||||
status.
|
||||
Required properties:
|
||||
- compatible: Should contain a chip-specific compatible string,
|
||||
Chip-specific strings are of the form "fsl,<chip>-scfg",
|
||||
The following <chip>s are known to be supported:
|
||||
ls1012a, ls1021a, ls1043a, ls1046a, ls2080a.
|
||||
|
||||
- reg: should contain base address and length of SCFG memory-mapped registers
|
||||
|
||||
Example:
|
||||
scfg: scfg@1570000 {
|
||||
compatible = "fsl,ls1021a-scfg";
|
||||
reg = <0x0 0x1570000 0x0 0x10000>;
|
||||
};
|
||||
|
||||
Freescale DCFG
|
||||
DCFG is the device configuration unit, that provides general purpose
|
||||
configuration and status for the device. Such as setting the secondary
|
||||
core start address and release the secondary core from holdoff and startup.
|
||||
Required properties:
|
||||
- compatible: Should contain a chip-specific compatible string,
|
||||
Chip-specific strings are of the form "fsl,<chip>-dcfg",
|
||||
The following <chip>s are known to be supported:
|
||||
ls1012a, ls1021a, ls1043a, ls1046a, ls2080a.
|
||||
|
||||
- reg : should contain base address and length of DCFG memory-mapped registers
|
||||
|
||||
Example:
|
||||
dcfg: dcfg@1ee0000 {
|
||||
compatible = "fsl,ls1021a-dcfg";
|
||||
reg = <0x0 0x1ee0000 0x0 0x10000>;
|
||||
};
|
||||
|
||||
Freescale ARMv8 based Layerscape SoC family Device Tree Bindings
|
||||
----------------------------------------------------------------
|
||||
|
||||
|
|
|
|||
|
|
@ -8,6 +8,14 @@ HiKey960 Board
|
|||
Required root node properties:
|
||||
- compatible = "hisilicon,hi3660-hikey960", "hisilicon,hi3660";
|
||||
|
||||
Hi3670 SoC
|
||||
Required root node properties:
|
||||
- compatible = "hisilicon,hi3670";
|
||||
|
||||
HiKey970 Board
|
||||
Required root node properties:
|
||||
- compatible = "hisilicon,hi3670-hikey970", "hisilicon,hi3670";
|
||||
|
||||
Hi3798cv200 SoC
|
||||
Required root node properties:
|
||||
- compatible = "hisilicon,hi3798cv200";
|
||||
|
|
|
|||
|
|
@ -45,11 +45,15 @@ Optional Properties:
|
|||
debug_messages - Map the Debug message region
|
||||
- reg: register space corresponding to the debug_messages
|
||||
- ti,system-reboot-controller: If system reboot can be triggered by SoC reboot
|
||||
- ti,host-id: Integer value corresponding to the host ID assigned by Firmware
|
||||
for identification of host processing entities such as virtual
|
||||
machines
|
||||
|
||||
Example (K2G):
|
||||
-------------
|
||||
pmmc: pmmc {
|
||||
compatible = "ti,k2g-sci";
|
||||
ti,host-id = <2>;
|
||||
mbox-names = "rx", "tx";
|
||||
mboxes= <&msgmgr &msgmgr_proxy_pmmc_rx>,
|
||||
<&msgmgr &msgmgr_proxy_pmmc_tx>;
|
||||
|
|
|
|||
|
|
@ -10,6 +10,7 @@ Required Properties:
|
|||
- "mediatek,mt2712-apmixedsys", "syscon"
|
||||
- "mediatek,mt6797-apmixedsys"
|
||||
- "mediatek,mt7622-apmixedsys"
|
||||
- "mediatek,mt7623-apmixedsys", "mediatek,mt2701-apmixedsys"
|
||||
- "mediatek,mt8135-apmixedsys"
|
||||
- "mediatek,mt8173-apmixedsys"
|
||||
- #clock-cells: Must be 1
|
||||
|
|
|
|||
|
|
@ -8,6 +8,7 @@ Required Properties:
|
|||
- compatible: Should be one of:
|
||||
- "mediatek,mt2701-audsys", "syscon"
|
||||
- "mediatek,mt7622-audsys", "syscon"
|
||||
- "mediatek,mt7623-audsys", "mediatek,mt2701-audsys", "syscon"
|
||||
- #clock-cells: Must be 1
|
||||
|
||||
The AUDSYS controller uses the common clk binding from
|
||||
|
|
|
|||
|
|
@ -8,6 +8,7 @@ Required Properties:
|
|||
- compatible: Should be:
|
||||
- "mediatek,mt2701-bdpsys", "syscon"
|
||||
- "mediatek,mt2712-bdpsys", "syscon"
|
||||
- "mediatek,mt7623-bdpsys", "mediatek,mt2701-bdpsys", "syscon"
|
||||
- #clock-cells: Must be 1
|
||||
|
||||
The bdpsys controller uses the common clk binding from
|
||||
|
|
|
|||
|
|
@ -8,6 +8,7 @@ Required Properties:
|
|||
- compatible: Should be:
|
||||
- "mediatek,mt2701-ethsys", "syscon"
|
||||
- "mediatek,mt7622-ethsys", "syscon"
|
||||
- "mediatek,mt7623-ethsys", "mediatek,mt2701-ethsys", "syscon"
|
||||
- #clock-cells: Must be 1
|
||||
- #reset-cells: Must be 1
|
||||
|
||||
|
|
|
|||
|
|
@ -9,6 +9,7 @@ Required Properties:
|
|||
- compatible: Should be:
|
||||
- "mediatek,mt2701-hifsys", "syscon"
|
||||
- "mediatek,mt7622-hifsys", "syscon"
|
||||
- "mediatek,mt7623-hifsys", "mediatek,mt2701-hifsys", "syscon"
|
||||
- #clock-cells: Must be 1
|
||||
|
||||
The hifsys controller uses the common clk binding from
|
||||
|
|
|
|||
|
|
@ -9,6 +9,7 @@ Required Properties:
|
|||
- "mediatek,mt2701-imgsys", "syscon"
|
||||
- "mediatek,mt2712-imgsys", "syscon"
|
||||
- "mediatek,mt6797-imgsys", "syscon"
|
||||
- "mediatek,mt7623-imgsys", "mediatek,mt2701-imgsys", "syscon"
|
||||
- "mediatek,mt8173-imgsys", "syscon"
|
||||
- #clock-cells: Must be 1
|
||||
|
||||
|
|
|
|||
|
|
@ -11,6 +11,7 @@ Required Properties:
|
|||
- "mediatek,mt2712-infracfg", "syscon"
|
||||
- "mediatek,mt6797-infracfg", "syscon"
|
||||
- "mediatek,mt7622-infracfg", "syscon"
|
||||
- "mediatek,mt7623-infracfg", "mediatek,mt2701-infracfg", "syscon"
|
||||
- "mediatek,mt8135-infracfg", "syscon"
|
||||
- "mediatek,mt8173-infracfg", "syscon"
|
||||
- #clock-cells: Must be 1
|
||||
|
|
|
|||
|
|
@ -9,6 +9,7 @@ Required Properties:
|
|||
- "mediatek,mt2701-mmsys", "syscon"
|
||||
- "mediatek,mt2712-mmsys", "syscon"
|
||||
- "mediatek,mt6797-mmsys", "syscon"
|
||||
- "mediatek,mt7623-mmsys", "mediatek,mt2701-mmsys", "syscon"
|
||||
- "mediatek,mt8173-mmsys", "syscon"
|
||||
- #clock-cells: Must be 1
|
||||
|
||||
|
|
|
|||
|
|
@ -10,6 +10,7 @@ Required Properties:
|
|||
- "mediatek,mt2701-pericfg", "syscon"
|
||||
- "mediatek,mt2712-pericfg", "syscon"
|
||||
- "mediatek,mt7622-pericfg", "syscon"
|
||||
- "mediatek,mt7623-pericfg", "mediatek,mt2701-pericfg", "syscon"
|
||||
- "mediatek,mt8135-pericfg", "syscon"
|
||||
- "mediatek,mt8173-pericfg", "syscon"
|
||||
- #clock-cells: Must be 1
|
||||
|
|
|
|||
|
|
@ -10,6 +10,7 @@ Required Properties:
|
|||
- "mediatek,mt2712-topckgen", "syscon"
|
||||
- "mediatek,mt6797-topckgen"
|
||||
- "mediatek,mt7622-topckgen"
|
||||
- "mediatek,mt7623-topckgen", "mediatek,mt2701-topckgen"
|
||||
- "mediatek,mt8135-topckgen"
|
||||
- "mediatek,mt8173-topckgen"
|
||||
- #clock-cells: Must be 1
|
||||
|
|
|
|||
|
|
@ -9,6 +9,7 @@ Required Properties:
|
|||
- "mediatek,mt2701-vdecsys", "syscon"
|
||||
- "mediatek,mt2712-vdecsys", "syscon"
|
||||
- "mediatek,mt6797-vdecsys", "syscon"
|
||||
- "mediatek,mt7623-vdecsys", "mediatek,mt2701-vdecsys", "syscon"
|
||||
- "mediatek,mt8173-vdecsys", "syscon"
|
||||
- #clock-cells: Must be 1
|
||||
|
||||
|
|
|
|||
|
|
@ -21,10 +21,29 @@ PROPERTIES
|
|||
the register region. An optional second element specifies
|
||||
the base address and size of the alias register region.
|
||||
|
||||
- clocks:
|
||||
Usage: required
|
||||
Value type: <prop-encoded-array>
|
||||
Definition: reference to the pll parents.
|
||||
|
||||
- clock-names:
|
||||
Usage: required
|
||||
Value type: <stringlist>
|
||||
Definition: must be "pll8_vote", "pxo".
|
||||
|
||||
- clock-output-names:
|
||||
Usage: optional
|
||||
Value type: <string>
|
||||
Definition: Name of the output clock. Typically acpuX_aux where X is a
|
||||
CPU number starting at 0.
|
||||
|
||||
Example:
|
||||
|
||||
clock-controller@2088000 {
|
||||
compatible = "qcom,kpss-acc-v2";
|
||||
reg = <0x02088000 0x1000>,
|
||||
<0x02008000 0x1000>;
|
||||
clocks = <&gcc PLL8_VOTE>, <&gcc PXO_SRC>;
|
||||
clock-names = "pll8_vote", "pxo";
|
||||
clock-output-names = "acpu0_aux";
|
||||
};
|
||||
|
|
|
|||
|
|
@ -0,0 +1,44 @@
|
|||
Krait Processor Sub-system (KPSS) Global Clock Controller (GCC)
|
||||
|
||||
PROPERTIES
|
||||
|
||||
- compatible:
|
||||
Usage: required
|
||||
Value type: <string>
|
||||
Definition: should be one of the following. The generic compatible
|
||||
"qcom,kpss-gcc" should also be included.
|
||||
"qcom,kpss-gcc-ipq8064", "qcom,kpss-gcc"
|
||||
"qcom,kpss-gcc-apq8064", "qcom,kpss-gcc"
|
||||
"qcom,kpss-gcc-msm8974", "qcom,kpss-gcc"
|
||||
"qcom,kpss-gcc-msm8960", "qcom,kpss-gcc"
|
||||
|
||||
- reg:
|
||||
Usage: required
|
||||
Value type: <prop-encoded-array>
|
||||
Definition: base address and size of the register region
|
||||
|
||||
- clocks:
|
||||
Usage: required
|
||||
Value type: <prop-encoded-array>
|
||||
Definition: reference to the pll parents.
|
||||
|
||||
- clock-names:
|
||||
Usage: required
|
||||
Value type: <stringlist>
|
||||
Definition: must be "pll8_vote", "pxo".
|
||||
|
||||
- clock-output-names:
|
||||
Usage: required
|
||||
Value type: <string>
|
||||
Definition: Name of the output clock. Typically acpu_l2_aux indicating
|
||||
an L2 cache auxiliary clock.
|
||||
|
||||
Example:
|
||||
|
||||
l2cc: clock-controller@2011000 {
|
||||
compatible = "qcom,kpss-gcc-ipq8064", "qcom,kpss-gcc";
|
||||
reg = <0x2011000 0x1000>;
|
||||
clocks = <&gcc PLL8_VOTE>, <&gcc PXO_SRC>;
|
||||
clock-names = "pll8_vote", "pxo";
|
||||
clock-output-names = "acpu_l2_aux";
|
||||
};
|
||||
|
|
@ -16,11 +16,26 @@ Properties:
|
|||
- reg:
|
||||
Usage: required
|
||||
Value Type: <prop-encoded-array>
|
||||
Definition: Start address and the the size of the register region.
|
||||
Definition: The first element specifies the llcc base start address and
|
||||
the size of the register region. The second element specifies
|
||||
the llcc broadcast base address and size of the register region.
|
||||
|
||||
- reg-names:
|
||||
Usage: required
|
||||
Value Type: <stringlist>
|
||||
Definition: Register region names. Must be "llcc_base", "llcc_broadcast_base".
|
||||
|
||||
- interrupts:
|
||||
Usage: required
|
||||
Definition: The interrupt is associated with the llcc edac device.
|
||||
It's used for llcc cache single and double bit error detection
|
||||
and reporting.
|
||||
|
||||
Example:
|
||||
|
||||
cache-controller@1100000 {
|
||||
compatible = "qcom,sdm845-llcc";
|
||||
reg = <0x1100000 0x250000>;
|
||||
reg = <0x1100000 0x200000>, <0x1300000 0x50000> ;
|
||||
reg-names = "llcc_base", "llcc_broadcast_base";
|
||||
interrupts = <GIC_SPI 582 IRQ_TYPE_LEVEL_HIGH>;
|
||||
};
|
||||
|
|
|
|||
|
|
@ -5,6 +5,10 @@ Rockchip platforms device tree bindings
|
|||
Required root node properties:
|
||||
- compatible = "vamrs,ficus", "rockchip,rk3399";
|
||||
|
||||
- 96boards RK3399 Rock960 (ROCK960 Consumer Edition)
|
||||
Required root node properties:
|
||||
- compatible = "vamrs,rock960", "rockchip,rk3399";
|
||||
|
||||
- Amarula Vyasa RK3288 board
|
||||
Required root node properties:
|
||||
- compatible = "amarula,vyasa-rk3288", "rockchip,rk3288";
|
||||
|
|
@ -13,6 +17,10 @@ Rockchip platforms device tree bindings
|
|||
Required root node properties:
|
||||
- compatible = "asus,rk3288-tinker", "rockchip,rk3288";
|
||||
|
||||
- Asus Tinker board S
|
||||
Required root node properties:
|
||||
- compatible = "asus,rk3288-tinker-s", "rockchip,rk3288";
|
||||
|
||||
- Kylin RK3036 board:
|
||||
Required root node properties:
|
||||
- compatible = "rockchip,kylin-rk3036", "rockchip,rk3036";
|
||||
|
|
@ -59,6 +67,10 @@ Rockchip platforms device tree bindings
|
|||
Required root node properties:
|
||||
- compatible = "firefly,roc-rk3328-cc", "rockchip,rk3328";
|
||||
|
||||
- Firefly ROC-RK3399-PC board:
|
||||
Required root node properties:
|
||||
- compatible = "firefly,roc-rk3399-pc", "rockchip,rk3399";
|
||||
|
||||
- ChipSPARK PopMetal-RK3288 board:
|
||||
Required root node properties:
|
||||
- compatible = "chipspark,popmetal-rk3288", "rockchip,rk3288";
|
||||
|
|
@ -160,6 +172,10 @@ Rockchip platforms device tree bindings
|
|||
Required root node properties:
|
||||
- compatible = "pine64,rock64", "rockchip,rk3328";
|
||||
|
||||
- Pine64 RockPro64 board:
|
||||
Required root node properties:
|
||||
- compatible = "pine64,rockpro64", "rockchip,rk3399";
|
||||
|
||||
- Rockchip PX3 Evaluation board:
|
||||
Required root node properties:
|
||||
- compatible = "rockchip,px3-evb", "rockchip,px3", "rockchip,rk3188";
|
||||
|
|
@ -168,6 +184,10 @@ Rockchip platforms device tree bindings
|
|||
Required root node properties:
|
||||
- compatible = "rockchip,px5-evb", "rockchip,px5", "rockchip,rk3368";
|
||||
|
||||
- Rockchip PX30 Evaluation board:
|
||||
Required root node properties:
|
||||
- compatible = "rockchip,px30-evb", "rockchip,px30";
|
||||
|
||||
- Rockchip RV1108 Evaluation board
|
||||
Required root node properties:
|
||||
- compatible = "rockchip,rv1108-evb", "rockchip,rv1108";
|
||||
|
|
|
|||
|
|
@ -22,7 +22,7 @@ References:
|
|||
|
||||
Example:
|
||||
|
||||
scu@a04100000 {
|
||||
scu@a0410000 {
|
||||
compatible = "arm,cortex-a9-scu";
|
||||
reg = <0xa0410000 0x100>;
|
||||
};
|
||||
|
|
|
|||
|
|
@ -32,7 +32,8 @@ describe the view of Secure world using the standard bindings. These
|
|||
secure- bindings only need to be used where both the Secure and Normal
|
||||
world views need to be described in a single device tree.
|
||||
|
||||
Valid Secure world properties:
|
||||
Valid Secure world properties
|
||||
-----------------------------
|
||||
|
||||
- secure-status : specifies whether the device is present and usable
|
||||
in the secure world. The combination of this with "status" allows
|
||||
|
|
@ -51,3 +52,19 @@ Valid Secure world properties:
|
|||
status = "disabled"; secure-status = "okay"; /* S-only */
|
||||
status = "disabled"; /* disabled in both */
|
||||
status = "disabled"; secure-status = "disabled"; /* disabled in both */
|
||||
|
||||
The secure-chosen node
|
||||
----------------------
|
||||
|
||||
Similar to the /chosen node which serves as a place for passing data
|
||||
between firmware and the operating system, the /secure-chosen node may
|
||||
be used to pass data to the Secure OS. Only the properties defined
|
||||
below may appear in the /secure-chosen node.
|
||||
|
||||
- stdout-path : specifies the device to be used by the Secure OS for
|
||||
its console output. The syntax is the same as for /chosen/stdout-path.
|
||||
If the /secure-chosen node exists but the stdout-path property is not
|
||||
present, the Secure OS should not perform any console output. If
|
||||
/secure-chosen does not exist, the Secure OS should use the value of
|
||||
/chosen/stdout-path instead (that is, use the same device as the
|
||||
Normal world OS).
|
||||
|
|
|
|||
|
|
@ -7,6 +7,8 @@ SoCs:
|
|||
compatible = "renesas,emev2"
|
||||
- RZ/A1H (R7S72100)
|
||||
compatible = "renesas,r7s72100"
|
||||
- RZ/A2 (R7S9210)
|
||||
compatible = "renesas,r7s9210"
|
||||
- SH-Mobile AG5 (R8A73A00/SH73A0)
|
||||
compatible = "renesas,sh73a0"
|
||||
- R-Mobile APE6 (R8A73A40)
|
||||
|
|
@ -23,6 +25,10 @@ SoCs:
|
|||
compatible = "renesas,r8a7745"
|
||||
- RZ/G1C (R8A77470)
|
||||
compatible = "renesas,r8a77470"
|
||||
- RZ/G2M (R8A774A1)
|
||||
compatible = "renesas,r8a774a1"
|
||||
- RZ/G2E (RA8774C0)
|
||||
compatible = "renesas,r8a774c0"
|
||||
- R-Car M1A (R8A77781)
|
||||
compatible = "renesas,r8a7778"
|
||||
- R-Car H1 (R8A77790)
|
||||
|
|
@ -107,6 +113,8 @@ Boards:
|
|||
compatible = "renesas,lager", "renesas,r8a7790"
|
||||
- M3ULCB (R-Car Starter Kit Pro, RTP0RC7796SKBX0010SA09 (M3 ES1.0))
|
||||
compatible = "renesas,m3ulcb", "renesas,r8a7796"
|
||||
- M3NULCB (R-Car Starter Kit Pro, RTP0RC77965SKBX010SA00 (M3-N ES1.1))
|
||||
compatible = "renesas,m3nulcb", "renesas,r8a77965"
|
||||
- Marzen (R0P7779A00010S)
|
||||
compatible = "renesas,marzen", "renesas,r8a7779"
|
||||
- Porter (M2-LCDP)
|
||||
|
|
@ -143,12 +151,12 @@ Boards:
|
|||
compatible = "renesas,wheat", "renesas,r8a7792"
|
||||
|
||||
|
||||
Most Renesas ARM SoCs have a Product Register that allows to retrieve SoC
|
||||
product and revision information. If present, a device node for this register
|
||||
should be added.
|
||||
Most Renesas ARM SoCs have a Product Register or Boundary Scan ID Register that
|
||||
allows to retrieve SoC product and revision information. If present, a device
|
||||
node for this register should be added.
|
||||
|
||||
Required properties:
|
||||
- compatible: Must be "renesas,prr".
|
||||
- compatible: Must be "renesas,prr" or "renesas,bsid"
|
||||
- reg: Base address and length of the register block.
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -1,4 +1,9 @@
|
|||
Marvell Berlin SoC Family Device Tree Bindings
|
||||
Synaptics SoC Device Tree Bindings
|
||||
|
||||
According to https://www.synaptics.com/company/news/conexant-marvell
|
||||
Synaptics has acquired the Multimedia Solutions Business of Marvell, so
|
||||
berlin SoCs are now Synaptics' SoCs now.
|
||||
|
||||
---------------------------------------------------------------
|
||||
|
||||
Work in progress statement:
|
||||
|
|
@ -13,6 +18,10 @@ stable binding/ABI.
|
|||
|
||||
---------------------------------------------------------------
|
||||
|
||||
Boards with the Synaptics AS370 SoC shall have the following properties:
|
||||
Required root node property:
|
||||
compatible: "syna,as370"
|
||||
|
||||
Boards with a SoC of the Marvell Berlin family, e.g. Armada 1500
|
||||
shall have the following properties:
|
||||
|
||||
|
|
@ -47,12 +47,17 @@ board-specific compatible values:
|
|||
nvidia,ventana
|
||||
toradex,apalis_t30
|
||||
toradex,apalis_t30-eval
|
||||
toradex,apalis_t30-v1.1
|
||||
toradex,apalis_t30-v1.1-eval
|
||||
toradex,apalis-tk1
|
||||
toradex,apalis-tk1-eval
|
||||
toradex,colibri_t20-512
|
||||
toradex,apalis-tk1-v1.2
|
||||
toradex,apalis-tk1-v1.2-eval
|
||||
toradex,colibri_t20
|
||||
toradex,colibri_t20-eval-v3
|
||||
toradex,colibri_t20-iris
|
||||
toradex,colibri_t30
|
||||
toradex,colibri_t30-eval-v3
|
||||
toradex,iris
|
||||
|
||||
Trusted Foundations
|
||||
-------------------------------------------
|
||||
|
|
|
|||
|
|
@ -34,3 +34,96 @@ Board DTS:
|
|||
pmc@c360000 {
|
||||
nvidia,invert-interrupt;
|
||||
};
|
||||
|
||||
== Pad Control ==
|
||||
|
||||
On Tegra SoCs a pad is a set of pins which are configured as a group.
|
||||
The pin grouping is a fixed attribute of the hardware. The PMC can be
|
||||
used to set pad power state and signaling voltage. A pad can be either
|
||||
in active or power down mode. The support for power state and signaling
|
||||
voltage configuration varies depending on the pad in question. 3.3 V and
|
||||
1.8 V signaling voltages are supported on pins where software
|
||||
controllable signaling voltage switching is available.
|
||||
|
||||
Pad configurations are described with pin configuration nodes which
|
||||
are placed under the pmc node and they are referred to by the pinctrl
|
||||
client properties. For more information see
|
||||
Documentation/devicetree/bindings/pinctrl/pinctrl-bindings.txt.
|
||||
|
||||
The following pads are present on Tegra186:
|
||||
csia csib dsi mipi-bias
|
||||
pex-clk-bias pex-clk3 pex-clk2 pex-clk1
|
||||
usb0 usb1 usb2 usb-bias
|
||||
uart audio hsic dbg
|
||||
hdmi-dp0 hdmi-dp1 pex-cntrl sdmmc2-hv
|
||||
sdmmc4 cam dsib dsic
|
||||
dsid csic csid csie
|
||||
dsif spi ufs dmic-hv
|
||||
edp sdmmc1-hv sdmmc3-hv conn
|
||||
audio-hv ao-hv
|
||||
|
||||
Required pin configuration properties:
|
||||
- pins: A list of strings, each of which contains the name of a pad
|
||||
to be configured.
|
||||
|
||||
Optional pin configuration properties:
|
||||
- low-power-enable: Configure the pad into power down mode
|
||||
- low-power-disable: Configure the pad into active mode
|
||||
- power-source: Must contain either TEGRA_IO_PAD_VOLTAGE_1V8 or
|
||||
TEGRA_IO_PAD_VOLTAGE_3V3 to select between signaling voltages.
|
||||
The values are defined in
|
||||
include/dt-bindings/pinctrl/pinctrl-tegra-io-pad.h.
|
||||
|
||||
Note: The power state can be configured on all of the above pads except
|
||||
for ao-hv. Following pads have software configurable signaling
|
||||
voltages: sdmmc2-hv, dmic-hv, sdmmc1-hv, sdmmc3-hv, audio-hv,
|
||||
ao-hv.
|
||||
|
||||
Pad configuration state example:
|
||||
pmc: pmc@7000e400 {
|
||||
compatible = "nvidia,tegra186-pmc";
|
||||
reg = <0 0x0c360000 0 0x10000>,
|
||||
<0 0x0c370000 0 0x10000>,
|
||||
<0 0x0c380000 0 0x10000>,
|
||||
<0 0x0c390000 0 0x10000>;
|
||||
reg-names = "pmc", "wake", "aotag", "scratch";
|
||||
|
||||
...
|
||||
|
||||
sdmmc1_3v3: sdmmc1-3v3 {
|
||||
pins = "sdmmc1-hv";
|
||||
power-source = <TEGRA_IO_PAD_VOLTAGE_3V3>;
|
||||
};
|
||||
|
||||
sdmmc1_1v8: sdmmc1-1v8 {
|
||||
pins = "sdmmc1-hv";
|
||||
power-source = <TEGRA_IO_PAD_VOLTAGE_1V8>;
|
||||
};
|
||||
|
||||
hdmi_off: hdmi-off {
|
||||
pins = "hdmi";
|
||||
low-power-enable;
|
||||
}
|
||||
|
||||
hdmi_on: hdmi-on {
|
||||
pins = "hdmi";
|
||||
low-power-disable;
|
||||
}
|
||||
};
|
||||
|
||||
Pinctrl client example:
|
||||
sdmmc1: sdhci@3400000 {
|
||||
...
|
||||
pinctrl-names = "sdmmc-3v3", "sdmmc-1v8";
|
||||
pinctrl-0 = <&sdmmc1_3v3>;
|
||||
pinctrl-1 = <&sdmmc1_1v8>;
|
||||
};
|
||||
|
||||
...
|
||||
|
||||
sor0: sor@15540000 {
|
||||
...
|
||||
pinctrl-0 = <&hdmi_off>;
|
||||
pinctrl-1 = <&hdmi_on>;
|
||||
pinctrl-names = "hdmi-on", "hdmi-off";
|
||||
};
|
||||
|
|
|
|||
|
|
@ -195,3 +195,106 @@ Example:
|
|||
power-domains = <&pd_audio>;
|
||||
...
|
||||
};
|
||||
|
||||
== Pad Control ==
|
||||
|
||||
On Tegra SoCs a pad is a set of pins which are configured as a group.
|
||||
The pin grouping is a fixed attribute of the hardware. The PMC can be
|
||||
used to set pad power state and signaling voltage. A pad can be either
|
||||
in active or power down mode. The support for power state and signaling
|
||||
voltage configuration varies depending on the pad in question. 3.3 V and
|
||||
1.8 V signaling voltages are supported on pins where software
|
||||
controllable signaling voltage switching is available.
|
||||
|
||||
The pad configuration state nodes are placed under the pmc node and they
|
||||
are referred to by the pinctrl client properties. For more information
|
||||
see Documentation/devicetree/bindings/pinctrl/pinctrl-bindings.txt.
|
||||
The pad name should be used as the value of the pins property in pin
|
||||
configuration nodes.
|
||||
|
||||
The following pads are present on Tegra124 and Tegra132:
|
||||
audio bb cam comp
|
||||
csia csb cse dsi
|
||||
dsib dsic dsid hdmi
|
||||
hsic hv lvds mipi-bias
|
||||
nand pex-bias pex-clk1 pex-clk2
|
||||
pex-cntrl sdmmc1 sdmmc3 sdmmc4
|
||||
sys_ddc uart usb0 usb1
|
||||
usb2 usb_bias
|
||||
|
||||
The following pads are present on Tegra210:
|
||||
audio audio-hv cam csia
|
||||
csib csic csid csie
|
||||
csif dbg debug-nonao dmic
|
||||
dp dsi dsib dsic
|
||||
dsid emmc emmc2 gpio
|
||||
hdmi hsic lvds mipi-bias
|
||||
pex-bias pex-clk1 pex-clk2 pex-cntrl
|
||||
sdmmc1 sdmmc3 spi spi-hv
|
||||
uart usb0 usb1 usb2
|
||||
usb3 usb-bias
|
||||
|
||||
Required pin configuration properties:
|
||||
- pins: Must contain name of the pad(s) to be configured.
|
||||
|
||||
Optional pin configuration properties:
|
||||
- low-power-enable: Configure the pad into power down mode
|
||||
- low-power-disable: Configure the pad into active mode
|
||||
- power-source: Must contain either TEGRA_IO_PAD_VOLTAGE_1V8
|
||||
or TEGRA_IO_PAD_VOLTAGE_3V3 to select between signaling voltages.
|
||||
The values are defined in
|
||||
include/dt-bindings/pinctrl/pinctrl-tegra-io-pad.h.
|
||||
|
||||
Note: The power state can be configured on all of the Tegra124 and
|
||||
Tegra132 pads. None of the Tegra124 or Tegra132 pads support
|
||||
signaling voltage switching.
|
||||
|
||||
Note: All of the listed Tegra210 pads except pex-cntrl support power
|
||||
state configuration. Signaling voltage switching is supported on
|
||||
following Tegra210 pads: audio, audio-hv, cam, dbg, dmic, gpio,
|
||||
pex-cntrl, sdmmc1, sdmmc3, spi, spi-hv, and uart.
|
||||
|
||||
Pad configuration state example:
|
||||
pmc: pmc@7000e400 {
|
||||
compatible = "nvidia,tegra210-pmc";
|
||||
reg = <0x0 0x7000e400 0x0 0x400>;
|
||||
clocks = <&tegra_car TEGRA210_CLK_PCLK>, <&clk32k_in>;
|
||||
clock-names = "pclk", "clk32k_in";
|
||||
|
||||
...
|
||||
|
||||
sdmmc1_3v3: sdmmc1-3v3 {
|
||||
pins = "sdmmc1";
|
||||
power-source = <TEGRA_IO_PAD_VOLTAGE_3V3>;
|
||||
};
|
||||
|
||||
sdmmc1_1v8: sdmmc1-1v8 {
|
||||
pins = "sdmmc1";
|
||||
power-source = <TEGRA_IO_PAD_VOLTAGE_1V8>;
|
||||
};
|
||||
|
||||
hdmi_off: hdmi-off {
|
||||
pins = "hdmi";
|
||||
low-power-enable;
|
||||
}
|
||||
|
||||
hdmi_on: hdmi-on {
|
||||
pins = "hdmi";
|
||||
low-power-disable;
|
||||
}
|
||||
};
|
||||
|
||||
Pinctrl client example:
|
||||
sdmmc1: sdhci@700b0000 {
|
||||
...
|
||||
pinctrl-names = "sdmmc-3v3", "sdmmc-1v8";
|
||||
pinctrl-0 = <&sdmmc1_3v3>;
|
||||
pinctrl-1 = <&sdmmc1_1v8>;
|
||||
};
|
||||
...
|
||||
sor@54540000 {
|
||||
...
|
||||
pinctrl-0 = <&hdmi_off>;
|
||||
pinctrl-1 = <&hdmi_on>;
|
||||
pinctrl-names = "hdmi-on", "hdmi-off";
|
||||
};
|
||||
|
|
|
|||
|
|
@ -60,7 +60,7 @@ Example:
|
|||
<0xa0410100 0x100>;
|
||||
};
|
||||
|
||||
scu@a04100000 {
|
||||
scu@a0410000 {
|
||||
compatible = "arm,cortex-a9-scu";
|
||||
reg = <0xa0410000 0x100>;
|
||||
};
|
||||
|
|
|
|||
|
|
@ -0,0 +1,30 @@
|
|||
ZTE sysctrl Registers
|
||||
|
||||
Registers for 'zte,zx296702' SoC:
|
||||
|
||||
System management required properties:
|
||||
- compatible = "zte,sysctrl"
|
||||
|
||||
Low power management required properties:
|
||||
- compatible = "zte,zx296702-pcu"
|
||||
|
||||
Bus matrix required properties:
|
||||
- compatible = "zte,zx-bus-matrix"
|
||||
|
||||
|
||||
Registers for 'zte,zx296718' SoC:
|
||||
|
||||
System management required properties:
|
||||
- compatible = "zte,zx296718-aon-sysctrl"
|
||||
- compatible = "zte,zx296718-sysctrl"
|
||||
|
||||
Example:
|
||||
aon_sysctrl: aon-sysctrl@116000 {
|
||||
compatible = "zte,zx296718-aon-sysctrl", "syscon";
|
||||
reg = <0x116000 0x1000>;
|
||||
};
|
||||
|
||||
sysctrl: sysctrl@1463000 {
|
||||
compatible = "zte,zx296718-sysctrl", "syscon";
|
||||
reg = <0x1463000 0x1000>;
|
||||
};
|
||||
|
|
@ -1,20 +1,10 @@
|
|||
ZTE platforms device tree bindings
|
||||
---------------------------------------
|
||||
|
||||
---------------------------------------
|
||||
- ZX296702 board:
|
||||
Required root node properties:
|
||||
- compatible = "zte,zx296702-ad1", "zte,zx296702"
|
||||
|
||||
System management required properties:
|
||||
- compatible = "zte,sysctrl"
|
||||
|
||||
Low power management required properties:
|
||||
- compatible = "zte,zx296702-pcu"
|
||||
|
||||
Bus matrix required properties:
|
||||
- compatible = "zte,zx-bus-matrix"
|
||||
|
||||
|
||||
---------------------------------------
|
||||
- ZX296718 SoC:
|
||||
Required root node properties:
|
||||
|
|
@ -22,18 +12,3 @@ Bus matrix required properties:
|
|||
|
||||
ZX296718 EVB board:
|
||||
- "zte,zx296718-evb"
|
||||
|
||||
System management required properties:
|
||||
- compatible = "zte,zx296718-aon-sysctrl"
|
||||
- compatible = "zte,zx296718-sysctrl"
|
||||
|
||||
Example:
|
||||
aon_sysctrl: aon-sysctrl@116000 {
|
||||
compatible = "zte,zx296718-aon-sysctrl", "syscon";
|
||||
reg = <0x116000 0x1000>;
|
||||
};
|
||||
|
||||
sysctrl: sysctrl@1463000 {
|
||||
compatible = "zte,zx296718-sysctrl", "syscon";
|
||||
reg = <0x1463000 0x1000>;
|
||||
};
|
||||
|
|
|
|||
|
|
@ -13,6 +13,7 @@ Required Properties:
|
|||
region.
|
||||
- clocks: Reference to the parent clocks ("hosc", "losc")
|
||||
- #clock-cells: should be 1.
|
||||
- #reset-cells: should be 1.
|
||||
|
||||
Each clock is assigned an identifier, and client nodes can use this identifier
|
||||
to specify the clock which they consume.
|
||||
|
|
@ -36,6 +37,7 @@ Example: Clock Management Unit node:
|
|||
reg = <0x0 0xe0160000 0x0 0x1000>;
|
||||
clocks = <&hosc>, <&losc>;
|
||||
#clock-cells = <1>;
|
||||
#reset-cells = <1>;
|
||||
};
|
||||
|
||||
Example: UART controller node that consumes clock generated by the clock
|
||||
|
|
|
|||
|
|
@ -4,6 +4,8 @@ This binding uses the common clock binding[1].
|
|||
|
||||
[1] Documentation/devicetree/bindings/clock/clock-bindings.txt
|
||||
|
||||
Slow Clock controller:
|
||||
|
||||
Required properties:
|
||||
- compatible : shall be one of the following:
|
||||
"atmel,at91sam9x5-sckc" or
|
||||
|
|
@ -16,84 +18,6 @@ Required properties:
|
|||
|
||||
"atmel,at91sam9x5-clk-slow-rc-osc":
|
||||
at91 internal slow RC oscillator
|
||||
|
||||
"atmel,<chip>-pmc":
|
||||
at91 PMC (Power Management Controller)
|
||||
All at91 specific clocks (clocks defined below) must be child
|
||||
node of the PMC node.
|
||||
<chip> can be: at91rm9200, at91sam9260, at91sam9261,
|
||||
at91sam9263, at91sam9g45, at91sam9n12, at91sam9rl, at91sam9x5,
|
||||
sama5d2, sama5d3 or sama5d4.
|
||||
|
||||
"atmel,at91sam9x5-clk-slow" (under sckc node)
|
||||
or
|
||||
"atmel,at91sam9260-clk-slow" (under pmc node):
|
||||
at91 slow clk
|
||||
|
||||
"atmel,at91rm9200-clk-main-osc"
|
||||
"atmel,at91sam9x5-clk-main-rc-osc"
|
||||
at91 main clk sources
|
||||
|
||||
"atmel,at91sam9x5-clk-main"
|
||||
"atmel,at91rm9200-clk-main":
|
||||
at91 main clock
|
||||
|
||||
"atmel,at91rm9200-clk-master" or
|
||||
"atmel,at91sam9x5-clk-master":
|
||||
at91 master clock
|
||||
|
||||
"atmel,at91sam9x5-clk-peripheral" or
|
||||
"atmel,at91rm9200-clk-peripheral":
|
||||
at91 peripheral clocks
|
||||
|
||||
"atmel,at91rm9200-clk-pll" or
|
||||
"atmel,at91sam9g45-clk-pll" or
|
||||
"atmel,at91sam9g20-clk-pllb" or
|
||||
"atmel,sama5d3-clk-pll":
|
||||
at91 pll clocks
|
||||
|
||||
"atmel,at91sam9x5-clk-plldiv":
|
||||
at91 plla divisor
|
||||
|
||||
"atmel,at91rm9200-clk-programmable" or
|
||||
"atmel,at91sam9g45-clk-programmable" or
|
||||
"atmel,at91sam9x5-clk-programmable":
|
||||
at91 programmable clocks
|
||||
|
||||
"atmel,at91sam9x5-clk-smd":
|
||||
at91 SMD (Soft Modem) clock
|
||||
|
||||
"atmel,at91rm9200-clk-system":
|
||||
at91 system clocks
|
||||
|
||||
"atmel,at91rm9200-clk-usb" or
|
||||
"atmel,at91sam9x5-clk-usb" or
|
||||
"atmel,at91sam9n12-clk-usb":
|
||||
at91 usb clock
|
||||
|
||||
"atmel,at91sam9x5-clk-utmi":
|
||||
at91 utmi clock
|
||||
|
||||
"atmel,sama5d4-clk-h32mx":
|
||||
at91 h32mx clock
|
||||
|
||||
"atmel,sama5d2-clk-generated":
|
||||
at91 generated clock
|
||||
|
||||
"atmel,sama5d2-clk-audio-pll-frac":
|
||||
at91 audio fractional pll
|
||||
|
||||
"atmel,sama5d2-clk-audio-pll-pad":
|
||||
at91 audio pll CLK_AUDIO output pin
|
||||
|
||||
"atmel,sama5d2-clk-audio-pll-pmc"
|
||||
at91 audio pll output on AUDIOPLLCLK that feeds the PMC
|
||||
and can be used by peripheral clock or generic clock
|
||||
|
||||
"atmel,sama5d2-clk-i2s-mux" (under pmc node):
|
||||
at91 I2S clock source selection
|
||||
|
||||
Required properties for SCKC node:
|
||||
- reg : defines the IO memory reserved for the SCKC.
|
||||
- #size-cells : shall be 0 (reg is used to encode clk id).
|
||||
- #address-cells : shall be 1 (reg is used to encode clk id).
|
||||
|
|
@ -109,428 +33,30 @@ For example:
|
|||
/* put at91 slow clocks here */
|
||||
};
|
||||
|
||||
Power Management Controller (PMC):
|
||||
|
||||
Required properties for internal slow RC oscillator:
|
||||
- #clock-cells : from common clock binding; shall be set to 0.
|
||||
- clock-frequency : define the internal RC oscillator frequency.
|
||||
|
||||
Optional properties:
|
||||
- clock-accuracy : define the internal RC oscillator accuracy.
|
||||
|
||||
For example:
|
||||
slow_rc_osc: slow_rc_osc {
|
||||
compatible = "atmel,at91sam9x5-clk-slow-rc-osc";
|
||||
clock-frequency = <32768>;
|
||||
clock-accuracy = <50000000>;
|
||||
};
|
||||
|
||||
Required properties for slow oscillator:
|
||||
- #clock-cells : from common clock binding; shall be set to 0.
|
||||
- clocks : shall encode the main osc source clk sources (see atmel datasheet).
|
||||
Required properties:
|
||||
- compatible : shall be "atmel,<chip>-pmc", "syscon":
|
||||
<chip> can be: at91rm9200, at91sam9260, at91sam9261,
|
||||
at91sam9263, at91sam9g45, at91sam9n12, at91sam9rl, at91sam9g15,
|
||||
at91sam9g25, at91sam9g35, at91sam9x25, at91sam9x35, at91sam9x5,
|
||||
sama5d2, sama5d3 or sama5d4.
|
||||
- #clock-cells : from common clock binding; shall be set to 2. The first entry
|
||||
is the type of the clock (core, system, peripheral or generated) and the
|
||||
second entry its index as provided by the datasheet
|
||||
- clocks : Must contain an entry for each entry in clock-names.
|
||||
- clock-names: Must include the following entries: "slow_clk", "main_xtal"
|
||||
|
||||
Optional properties:
|
||||
- atmel,osc-bypass : boolean property. Set this when a clock signal is directly
|
||||
provided on XIN.
|
||||
|
||||
For example:
|
||||
slow_osc: slow_osc {
|
||||
compatible = "atmel,at91rm9200-clk-slow-osc";
|
||||
#clock-cells = <0>;
|
||||
clocks = <&slow_xtal>;
|
||||
};
|
||||
|
||||
Required properties for slow clock:
|
||||
- #clock-cells : from common clock binding; shall be set to 0.
|
||||
- clocks : shall encode the slow clk sources (see atmel datasheet).
|
||||
|
||||
For example:
|
||||
clk32k: slck {
|
||||
compatible = "atmel,at91sam9x5-clk-slow";
|
||||
#clock-cells = <0>;
|
||||
clocks = <&slow_rc_osc &slow_osc>;
|
||||
};
|
||||
|
||||
Required properties for PMC node:
|
||||
- reg : defines the IO memory reserved for the PMC.
|
||||
- #size-cells : shall be 0 (reg is used to encode clk id).
|
||||
- #address-cells : shall be 1 (reg is used to encode clk id).
|
||||
- interrupts : shall be set to PMC interrupt line.
|
||||
- interrupt-controller : tell that the PMC is an interrupt controller.
|
||||
- #interrupt-cells : must be set to 1. The first cell encodes the interrupt id,
|
||||
and reflect the bit position in the PMC_ER/DR/SR registers.
|
||||
You can use the dt macros defined in dt-bindings/clock/at91.h.
|
||||
0 (AT91_PMC_MOSCS) -> main oscillator ready
|
||||
1 (AT91_PMC_LOCKA) -> PLL A ready
|
||||
2 (AT91_PMC_LOCKB) -> PLL B ready
|
||||
3 (AT91_PMC_MCKRDY) -> master clock ready
|
||||
6 (AT91_PMC_LOCKU) -> UTMI PLL clock ready
|
||||
8 .. 15 (AT91_PMC_PCKRDY(id)) -> programmable clock ready
|
||||
16 (AT91_PMC_MOSCSELS) -> main oscillator selected
|
||||
17 (AT91_PMC_MOSCRCS) -> RC main oscillator stabilized
|
||||
18 (AT91_PMC_CFDEV) -> clock failure detected
|
||||
|
||||
For example:
|
||||
pmc: pmc@fffffc00 {
|
||||
compatible = "atmel,sama5d3-pmc";
|
||||
interrupts = <1 4 7>;
|
||||
interrupt-controller;
|
||||
#interrupt-cells = <2>;
|
||||
#size-cells = <0>;
|
||||
#address-cells = <1>;
|
||||
|
||||
/* put at91 clocks here */
|
||||
};
|
||||
|
||||
Required properties for main clock internal RC oscillator:
|
||||
- interrupts : shall be set to "<0>".
|
||||
- clock-frequency : define the internal RC oscillator frequency.
|
||||
|
||||
Optional properties:
|
||||
- clock-accuracy : define the internal RC oscillator accuracy.
|
||||
|
||||
For example:
|
||||
main_rc_osc: main_rc_osc {
|
||||
compatible = "atmel,at91sam9x5-clk-main-rc-osc";
|
||||
interrupt-parent = <&pmc>;
|
||||
interrupts = <0>;
|
||||
clock-frequency = <12000000>;
|
||||
clock-accuracy = <50000000>;
|
||||
};
|
||||
|
||||
Required properties for main clock oscillator:
|
||||
- interrupts : shall be set to "<0>".
|
||||
- #clock-cells : from common clock binding; shall be set to 0.
|
||||
- clocks : shall encode the main osc source clk sources (see atmel datasheet).
|
||||
|
||||
Optional properties:
|
||||
- atmel,osc-bypass : boolean property. Specified if a clock signal is provided
|
||||
on XIN.
|
||||
|
||||
clock signal is directly provided on XIN pin.
|
||||
|
||||
For example:
|
||||
main_osc: main_osc {
|
||||
compatible = "atmel,at91rm9200-clk-main-osc";
|
||||
interrupt-parent = <&pmc>;
|
||||
interrupts = <0>;
|
||||
#clock-cells = <0>;
|
||||
clocks = <&main_xtal>;
|
||||
};
|
||||
|
||||
Required properties for main clock:
|
||||
- interrupts : shall be set to "<0>".
|
||||
- #clock-cells : from common clock binding; shall be set to 0.
|
||||
- clocks : shall encode the main clk sources (see atmel datasheet).
|
||||
|
||||
For example:
|
||||
main: mainck {
|
||||
compatible = "atmel,at91sam9x5-clk-main";
|
||||
interrupt-parent = <&pmc>;
|
||||
interrupts = <0>;
|
||||
#clock-cells = <0>;
|
||||
clocks = <&main_rc_osc &main_osc>;
|
||||
};
|
||||
|
||||
Required properties for master clock:
|
||||
- interrupts : shall be set to "<3>".
|
||||
- #clock-cells : from common clock binding; shall be set to 0.
|
||||
- clocks : shall be the master clock sources (see atmel datasheet) phandles.
|
||||
e.g. "<&ck32k>, <&main>, <&plla>, <&pllb>".
|
||||
- atmel,clk-output-range : minimum and maximum clock frequency (two u32
|
||||
fields).
|
||||
e.g. output = <0 133000000>; <=> 0 to 133MHz.
|
||||
- atmel,clk-divisors : master clock divisors table (four u32 fields).
|
||||
0 <=> reserved value.
|
||||
e.g. divisors = <1 2 4 6>;
|
||||
- atmel,master-clk-have-div3-pres : some SoC use the reserved value 7 in the
|
||||
PRES field as CLOCK_DIV3 (e.g sam9x5).
|
||||
|
||||
For example:
|
||||
mck: mck {
|
||||
compatible = "atmel,at91rm9200-clk-master";
|
||||
interrupt-parent = <&pmc>;
|
||||
interrupts = <3>;
|
||||
#clock-cells = <0>;
|
||||
atmel,clk-output-range = <0 133000000>;
|
||||
atmel,clk-divisors = <1 2 4 0>;
|
||||
};
|
||||
|
||||
Required properties for peripheral clocks:
|
||||
- #size-cells : shall be 0 (reg is used to encode clk id).
|
||||
- #address-cells : shall be 1 (reg is used to encode clk id).
|
||||
- clocks : shall be the master clock phandle.
|
||||
e.g. clocks = <&mck>;
|
||||
- name: device tree node describing a specific peripheral clock.
|
||||
* #clock-cells : from common clock binding; shall be set to 0.
|
||||
* reg: peripheral id. See Atmel's datasheets to get a full
|
||||
list of peripheral ids.
|
||||
* atmel,clk-output-range : minimum and maximum clock frequency
|
||||
(two u32 fields). Only valid on at91sam9x5-clk-peripheral
|
||||
compatible IPs.
|
||||
|
||||
For example:
|
||||
periph: periphck {
|
||||
compatible = "atmel,at91sam9x5-clk-peripheral";
|
||||
#size-cells = <0>;
|
||||
#address-cells = <1>;
|
||||
clocks = <&mck>;
|
||||
|
||||
ssc0_clk {
|
||||
#clock-cells = <0>;
|
||||
reg = <2>;
|
||||
atmel,clk-output-range = <0 133000000>;
|
||||
};
|
||||
|
||||
usart0_clk {
|
||||
#clock-cells = <0>;
|
||||
reg = <3>;
|
||||
atmel,clk-output-range = <0 66000000>;
|
||||
};
|
||||
};
|
||||
|
||||
|
||||
Required properties for pll clocks:
|
||||
- interrupts : shall be set to "<1>".
|
||||
- #clock-cells : from common clock binding; shall be set to 0.
|
||||
- clocks : shall be the main clock phandle.
|
||||
- reg : pll id.
|
||||
0 -> PLL A
|
||||
1 -> PLL B
|
||||
- atmel,clk-input-range : minimum and maximum source clock frequency (two u32
|
||||
fields).
|
||||
e.g. input = <1 32000000>; <=> 1 to 32MHz.
|
||||
- #atmel,pll-clk-output-range-cells : number of cells reserved for pll output
|
||||
range description. Sould be set to 2, 3
|
||||
or 4.
|
||||
* 1st and 2nd cells represent the frequency range (min-max).
|
||||
* 3rd cell is optional and represents the OUT field value for the given
|
||||
range.
|
||||
* 4th cell is optional and represents the ICPLL field (PLLICPR
|
||||
register)
|
||||
- atmel,pll-clk-output-ranges : pll output frequency ranges + optional parameter
|
||||
depending on #atmel,pll-output-range-cells
|
||||
property value.
|
||||
|
||||
For example:
|
||||
plla: pllack {
|
||||
compatible = "atmel,at91sam9g45-clk-pll";
|
||||
interrupt-parent = <&pmc>;
|
||||
interrupts = <1>;
|
||||
#clock-cells = <0>;
|
||||
clocks = <&main>;
|
||||
reg = <0>;
|
||||
atmel,clk-input-range = <2000000 32000000>;
|
||||
#atmel,pll-clk-output-range-cells = <4>;
|
||||
atmel,pll-clk-output-ranges = <74500000 800000000 0 0
|
||||
69500000 750000000 1 0
|
||||
64500000 700000000 2 0
|
||||
59500000 650000000 3 0
|
||||
54500000 600000000 0 1
|
||||
49500000 550000000 1 1
|
||||
44500000 500000000 2 1
|
||||
40000000 450000000 3 1>;
|
||||
};
|
||||
|
||||
Required properties for plldiv clocks (plldiv = pll / 2):
|
||||
- #clock-cells : from common clock binding; shall be set to 0.
|
||||
- clocks : shall be the plla clock phandle.
|
||||
|
||||
The pll divisor is equal to 2 and cannot be changed.
|
||||
|
||||
For example:
|
||||
plladiv: plladivck {
|
||||
compatible = "atmel,at91sam9x5-clk-plldiv";
|
||||
#clock-cells = <0>;
|
||||
clocks = <&plla>;
|
||||
};
|
||||
|
||||
Required properties for programmable clocks:
|
||||
- #size-cells : shall be 0 (reg is used to encode clk id).
|
||||
- #address-cells : shall be 1 (reg is used to encode clk id).
|
||||
- clocks : shall be the programmable clock source phandles.
|
||||
e.g. clocks = <&clk32k>, <&main>, <&plla>, <&pllb>;
|
||||
- name: device tree node describing a specific prog clock.
|
||||
* #clock-cells : from common clock binding; shall be set to 0.
|
||||
* reg : programmable clock id (register offset from PCKx
|
||||
register).
|
||||
* interrupts : shall be set to "<(8 + id)>".
|
||||
|
||||
For example:
|
||||
prog: progck {
|
||||
compatible = "atmel,at91sam9g45-clk-programmable";
|
||||
#size-cells = <0>;
|
||||
#address-cells = <1>;
|
||||
interrupt-parent = <&pmc>;
|
||||
clocks = <&clk32k>, <&main>, <&plladiv>, <&utmi>, <&mck>;
|
||||
|
||||
prog0 {
|
||||
#clock-cells = <0>;
|
||||
reg = <0>;
|
||||
interrupts = <8>;
|
||||
};
|
||||
|
||||
prog1 {
|
||||
#clock-cells = <0>;
|
||||
reg = <1>;
|
||||
interrupts = <9>;
|
||||
};
|
||||
};
|
||||
|
||||
|
||||
Required properties for smd clock:
|
||||
- #clock-cells : from common clock binding; shall be set to 0.
|
||||
- clocks : shall be the smd clock source phandles.
|
||||
e.g. clocks = <&plladiv>, <&utmi>;
|
||||
|
||||
For example:
|
||||
smd: smdck {
|
||||
compatible = "atmel,at91sam9x5-clk-smd";
|
||||
#clock-cells = <0>;
|
||||
clocks = <&plladiv>, <&utmi>;
|
||||
};
|
||||
|
||||
Required properties for system clocks:
|
||||
- #size-cells : shall be 0 (reg is used to encode clk id).
|
||||
- #address-cells : shall be 1 (reg is used to encode clk id).
|
||||
- name: device tree node describing a specific system clock.
|
||||
* #clock-cells : from common clock binding; shall be set to 0.
|
||||
* reg: system clock id (bit position in SCER/SCDR/SCSR registers).
|
||||
See Atmel's datasheet to get a full list of system clock ids.
|
||||
|
||||
For example:
|
||||
system: systemck {
|
||||
compatible = "atmel,at91rm9200-clk-system";
|
||||
#address-cells = <1>;
|
||||
#size-cells = <0>;
|
||||
|
||||
ddrck {
|
||||
#clock-cells = <0>;
|
||||
reg = <2>;
|
||||
clocks = <&mck>;
|
||||
};
|
||||
|
||||
uhpck {
|
||||
#clock-cells = <0>;
|
||||
reg = <6>;
|
||||
clocks = <&usb>;
|
||||
};
|
||||
|
||||
udpck {
|
||||
#clock-cells = <0>;
|
||||
reg = <7>;
|
||||
clocks = <&usb>;
|
||||
};
|
||||
};
|
||||
|
||||
|
||||
Required properties for usb clock:
|
||||
- #clock-cells : from common clock binding; shall be set to 0.
|
||||
- clocks : shall be the smd clock source phandles.
|
||||
e.g. clocks = <&pllb>;
|
||||
- atmel,clk-divisors (only available for "atmel,at91rm9200-clk-usb"):
|
||||
usb clock divisor table.
|
||||
e.g. divisors = <1 2 4 0>;
|
||||
|
||||
For example:
|
||||
usb: usbck {
|
||||
compatible = "atmel,at91sam9x5-clk-usb";
|
||||
#clock-cells = <0>;
|
||||
clocks = <&plladiv>, <&utmi>;
|
||||
};
|
||||
|
||||
usb: usbck {
|
||||
compatible = "atmel,at91rm9200-clk-usb";
|
||||
#clock-cells = <0>;
|
||||
clocks = <&pllb>;
|
||||
atmel,clk-divisors = <1 2 4 0>;
|
||||
};
|
||||
|
||||
|
||||
Required properties for utmi clock:
|
||||
- interrupts : shall be set to "<AT91_PMC_LOCKU IRQ_TYPE_LEVEL_HIGH>".
|
||||
- #clock-cells : from common clock binding; shall be set to 0.
|
||||
- clocks : shall be the main clock source phandle.
|
||||
|
||||
For example:
|
||||
utmi: utmick {
|
||||
compatible = "atmel,at91sam9x5-clk-utmi";
|
||||
interrupt-parent = <&pmc>;
|
||||
interrupts = <AT91_PMC_LOCKU IRQ_TYPE_LEVEL_HIGH>;
|
||||
#clock-cells = <0>;
|
||||
clocks = <&main>;
|
||||
};
|
||||
|
||||
Required properties for 32 bits bus Matrix clock (h32mx clock):
|
||||
- #clock-cells : from common clock binding; shall be set to 0.
|
||||
- clocks : shall be the master clock source phandle.
|
||||
|
||||
For example:
|
||||
h32ck: h32mxck {
|
||||
#clock-cells = <0>;
|
||||
compatible = "atmel,sama5d4-clk-h32mx";
|
||||
clocks = <&mck>;
|
||||
};
|
||||
|
||||
Required properties for generated clocks:
|
||||
- #size-cells : shall be 0 (reg is used to encode clk id).
|
||||
- #address-cells : shall be 1 (reg is used to encode clk id).
|
||||
- clocks : shall be the generated clock source phandles.
|
||||
e.g. clocks = <&clk32k>, <&main>, <&plladiv>, <&utmi>, <&mck>, <&audio_pll_pmc>;
|
||||
- name: device tree node describing a specific generated clock.
|
||||
* #clock-cells : from common clock binding; shall be set to 0.
|
||||
* reg: peripheral id. See Atmel's datasheets to get a full
|
||||
list of peripheral ids.
|
||||
* atmel,clk-output-range : minimum and maximum clock frequency
|
||||
(two u32 fields).
|
||||
|
||||
For example:
|
||||
gck {
|
||||
compatible = "atmel,sama5d2-clk-generated";
|
||||
#address-cells = <1>;
|
||||
#size-cells = <0>;
|
||||
clocks = <&clk32k>, <&main>, <&plladiv>, <&utmi>, <&mck>, <&audio_pll_pmc>;
|
||||
|
||||
tcb0_gclk: tcb0_gclk {
|
||||
#clock-cells = <0>;
|
||||
reg = <35>;
|
||||
atmel,clk-output-range = <0 83000000>;
|
||||
};
|
||||
|
||||
pwm_gclk: pwm_gclk {
|
||||
#clock-cells = <0>;
|
||||
reg = <38>;
|
||||
atmel,clk-output-range = <0 83000000>;
|
||||
};
|
||||
};
|
||||
|
||||
Required properties for I2S mux clocks:
|
||||
- #size-cells : shall be 0 (reg is used to encode I2S bus id).
|
||||
- #address-cells : shall be 1 (reg is used to encode I2S bus id).
|
||||
- name: device tree node describing a specific mux clock.
|
||||
* #clock-cells : from common clock binding; shall be set to 0.
|
||||
* clocks : shall be the mux clock parent phandles; shall be 2 phandles:
|
||||
peripheral and generated clock; the first phandle shall belong to the
|
||||
peripheral clock and the second one shall belong to the generated
|
||||
clock; "clock-indices" property can be user to specify
|
||||
the correct order.
|
||||
* reg: I2S bus id of the corresponding mux clock.
|
||||
e.g. reg = <0>; for i2s0, reg = <1>; for i2s1
|
||||
|
||||
For example:
|
||||
i2s_clkmux {
|
||||
compatible = "atmel,sama5d2-clk-i2s-mux";
|
||||
#address-cells = <1>;
|
||||
#size-cells = <0>;
|
||||
|
||||
i2s0muxck: i2s0_muxclk {
|
||||
clocks = <&i2s0_clk>, <&i2s0_gclk>;
|
||||
#clock-cells = <0>;
|
||||
reg = <0>;
|
||||
};
|
||||
|
||||
i2s1muxck: i2s1_muxclk {
|
||||
clocks = <&i2s1_clk>, <&i2s1_gclk>;
|
||||
#clock-cells = <0>;
|
||||
reg = <1>;
|
||||
};
|
||||
pmc: pmc@f0018000 {
|
||||
compatible = "atmel,sama5d4-pmc", "syscon";
|
||||
reg = <0xf0018000 0x120>;
|
||||
interrupts = <1 IRQ_TYPE_LEVEL_HIGH 7>;
|
||||
#clock-cells = <2>;
|
||||
clocks = <&clk32k>, <&main_xtal>;
|
||||
clock-names = "slow_clk", "main_xtal";
|
||||
};
|
||||
|
|
|
|||
|
|
@ -0,0 +1,43 @@
|
|||
* Hisilicon Hi3670 Clock Controller
|
||||
|
||||
The Hi3670 clock controller generates and supplies clock to various
|
||||
controllers within the Hi3670 SoC.
|
||||
|
||||
Required Properties:
|
||||
|
||||
- compatible: the compatible should be one of the following strings to
|
||||
indicate the clock controller functionality.
|
||||
|
||||
- "hisilicon,hi3670-crgctrl"
|
||||
- "hisilicon,hi3670-pctrl"
|
||||
- "hisilicon,hi3670-pmuctrl"
|
||||
- "hisilicon,hi3670-sctrl"
|
||||
- "hisilicon,hi3670-iomcu"
|
||||
- "hisilicon,hi3670-media1-crg"
|
||||
- "hisilicon,hi3670-media2-crg"
|
||||
|
||||
- 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 use this identifier
|
||||
to specify the clock which they consume.
|
||||
|
||||
All these identifier could be found in <dt-bindings/clock/hi3670-clock.h>.
|
||||
|
||||
Examples:
|
||||
crg_ctrl: clock-controller@fff35000 {
|
||||
compatible = "hisilicon,hi3670-crgctrl", "syscon";
|
||||
reg = <0x0 0xfff35000 0x0 0x1000>;
|
||||
#clock-cells = <1>;
|
||||
};
|
||||
|
||||
uart0: serial@fdf02000 {
|
||||
compatible = "arm,pl011", "arm,primecell";
|
||||
reg = <0x0 0xfdf02000 0x0 0x1000>;
|
||||
interrupts = <GIC_SPI 74 IRQ_TYPE_LEVEL_HIGH>;
|
||||
clocks = <&crg_ctrl HI3670_CLK_GATE_UART0>,
|
||||
<&crg_ctrl HI3670_PCLK>;
|
||||
clock-names = "uartclk", "apb_pclk";
|
||||
};
|
||||
|
|
@ -6,6 +6,14 @@ Required properties:
|
|||
- interrupts: Should contain CCM interrupt
|
||||
- #clock-cells: Should be <1>
|
||||
|
||||
Optional properties:
|
||||
- fsl,pmic-stby-poweroff: Configure CCM to assert PMIC_STBY_REQ signal
|
||||
on power off.
|
||||
Use this property if the SoC should be powered off by external power
|
||||
management IC (PMIC) triggered via PMIC_STBY_REQ signal.
|
||||
Boards that are designed to initiate poweroff on PMIC_ON_REQ signal should
|
||||
be using "syscon-poweroff" driver instead.
|
||||
|
||||
The clock consumer should specify the desired clock by having the clock
|
||||
ID in its "clocks" phandle cell. See include/dt-bindings/clock/imx6qdl-clock.h
|
||||
for the full list of i.MX6 Quad and DualLite clock IDs.
|
||||
|
|
|
|||
|
|
@ -6,8 +6,11 @@ to provide many different clock signals derived from only 2 external source
|
|||
clocks.
|
||||
|
||||
Required properties:
|
||||
- compatible : Should be "ingenic,<soctype>-cgu".
|
||||
For example "ingenic,jz4740-cgu" or "ingenic,jz4780-cgu".
|
||||
- compatible : Should be one of:
|
||||
* ingenic,jz4740-cgu
|
||||
* ingenic,jz4725b-cgu
|
||||
* ingenic,jz4770-cgu
|
||||
* ingenic,jz4780-cgu
|
||||
- reg : The address & length of the CGU registers.
|
||||
- clocks : List of phandle & clock specifiers for clocks external to the CGU.
|
||||
Two such external clocks should be specified - first the external crystal
|
||||
|
|
|
|||
|
|
@ -0,0 +1,18 @@
|
|||
Qualcomm Camera Clock & Reset Controller Binding
|
||||
------------------------------------------------
|
||||
|
||||
Required properties :
|
||||
- compatible : shall contain "qcom,sdm845-camcc".
|
||||
- reg : shall contain base register location and length.
|
||||
- #clock-cells : from common clock binding, shall contain 1.
|
||||
- #reset-cells : from common reset binding, shall contain 1.
|
||||
- #power-domain-cells : from generic power domain binding, shall contain 1.
|
||||
|
||||
Example:
|
||||
camcc: clock-controller@ad00000 {
|
||||
compatible = "qcom,sdm845-camcc";
|
||||
reg = <0xad00000 0x10000>;
|
||||
#clock-cells = <1>;
|
||||
#reset-cells = <1>;
|
||||
#power-domain-cells = <1>;
|
||||
};
|
||||
|
|
@ -19,6 +19,9 @@ Required properties :
|
|||
"qcom,gcc-msm8996"
|
||||
"qcom,gcc-msm8998"
|
||||
"qcom,gcc-mdm9615"
|
||||
"qcom,gcc-qcs404"
|
||||
"qcom,gcc-sdm630"
|
||||
"qcom,gcc-sdm660"
|
||||
"qcom,gcc-sdm845"
|
||||
|
||||
- reg : shall contain base register location and length
|
||||
|
|
|
|||
|
|
@ -0,0 +1,60 @@
|
|||
High-Frequency PLL (HFPLL)
|
||||
|
||||
PROPERTIES
|
||||
|
||||
- compatible:
|
||||
Usage: required
|
||||
Value type: <string>:
|
||||
shall contain only one of the following. The generic
|
||||
compatible "qcom,hfpll" should be also included.
|
||||
|
||||
"qcom,hfpll-ipq8064", "qcom,hfpll"
|
||||
"qcom,hfpll-apq8064", "qcom,hfpll"
|
||||
"qcom,hfpll-msm8974", "qcom,hfpll"
|
||||
"qcom,hfpll-msm8960", "qcom,hfpll"
|
||||
|
||||
- reg:
|
||||
Usage: required
|
||||
Value type: <prop-encoded-array>
|
||||
Definition: address and size of HPLL registers. An optional second
|
||||
element specifies the address and size of the alias
|
||||
register region.
|
||||
|
||||
- clocks:
|
||||
Usage: required
|
||||
Value type: <prop-encoded-array>
|
||||
Definition: reference to the xo clock.
|
||||
|
||||
- clock-names:
|
||||
Usage: required
|
||||
Value type: <stringlist>
|
||||
Definition: must be "xo".
|
||||
|
||||
- clock-output-names:
|
||||
Usage: required
|
||||
Value type: <string>
|
||||
Definition: Name of the PLL. Typically hfpllX where X is a CPU number
|
||||
starting at 0. Otherwise hfpll_Y where Y is more specific
|
||||
such as "l2".
|
||||
|
||||
Example:
|
||||
|
||||
1) An HFPLL for the L2 cache.
|
||||
|
||||
clock-controller@f9016000 {
|
||||
compatible = "qcom,hfpll-ipq8064", "qcom,hfpll";
|
||||
reg = <0xf9016000 0x30>;
|
||||
clocks = <&xo_board>;
|
||||
clock-names = "xo";
|
||||
clock-output-names = "hfpll_l2";
|
||||
};
|
||||
|
||||
2) An HFPLL for CPU0. This HFPLL has the alias register region.
|
||||
|
||||
clock-controller@f908a000 {
|
||||
compatible = "qcom,hfpll-ipq8064", "qcom,hfpll";
|
||||
reg = <0xf908a000 0x30>, <0xf900a000 0x30>;
|
||||
clocks = <&xo_board>;
|
||||
clock-names = "xo";
|
||||
clock-output-names = "hfpll0";
|
||||
};
|
||||
|
|
@ -0,0 +1,34 @@
|
|||
Krait Clock Controller
|
||||
|
||||
PROPERTIES
|
||||
|
||||
- compatible:
|
||||
Usage: required
|
||||
Value type: <string>
|
||||
Definition: must be one of:
|
||||
"qcom,krait-cc-v1"
|
||||
"qcom,krait-cc-v2"
|
||||
|
||||
- #clock-cells:
|
||||
Usage: required
|
||||
Value type: <u32>
|
||||
Definition: must be 1
|
||||
|
||||
- clocks:
|
||||
Usage: required
|
||||
Value type: <prop-encoded-array>
|
||||
Definition: reference to the clock parents of hfpll, secondary muxes.
|
||||
|
||||
- clock-names:
|
||||
Usage: required
|
||||
Value type: <stringlist>
|
||||
Definition: must be "hfpll0", "hfpll1", "acpu0_aux", "acpu1_aux", "qsb".
|
||||
|
||||
Example:
|
||||
|
||||
kraitcc: clock-controller {
|
||||
compatible = "qcom,krait-cc-v1";
|
||||
clocks = <&hfpll0>, <&hfpll1>, <&acpu0_aux>, <&acpu1_aux>, <qsb>;
|
||||
clock-names = "hfpll0", "hfpll1", "acpu0_aux", "acpu1_aux", "qsb";
|
||||
#clock-cells = <1>;
|
||||
};
|
||||
|
|
@ -13,9 +13,13 @@ They provide the following functionalities:
|
|||
|
||||
Required Properties:
|
||||
- compatible: Must be one of:
|
||||
- "renesas,r7s9210-cpg-mssr" for the r7s9210 SoC (RZ/A2)
|
||||
- "renesas,r8a7743-cpg-mssr" for the r8a7743 SoC (RZ/G1M)
|
||||
- "renesas,r8a7744-cpg-mssr" for the r8a7744 SoC (RZ/G1N)
|
||||
- "renesas,r8a7745-cpg-mssr" for the r8a7745 SoC (RZ/G1E)
|
||||
- "renesas,r8a77470-cpg-mssr" for the r8a77470 SoC (RZ/G1C)
|
||||
- "renesas,r8a774a1-cpg-mssr" for the r8a774a1 SoC (RZ/G2M)
|
||||
- "renesas,r8a774c0-cpg-mssr" for the r8a774c0 SoC (RZ/G2E)
|
||||
- "renesas,r8a7790-cpg-mssr" for the r8a7790 SoC (R-Car H2)
|
||||
- "renesas,r8a7791-cpg-mssr" for the r8a7791 SoC (R-Car M2-W)
|
||||
- "renesas,r8a7792-cpg-mssr" for the r8a7792 SoC (R-Car V2H)
|
||||
|
|
@ -35,12 +39,13 @@ Required Properties:
|
|||
- clocks: References to external parent clocks, one entry for each entry in
|
||||
clock-names
|
||||
- clock-names: List of external parent clock names. Valid names are:
|
||||
- "extal" (r8a7743, r8a7745, r8a77470, r8a7790, r8a7791, r8a7792,
|
||||
r8a7793, r8a7794, r8a7795, r8a7796, r8a77965, r8a77970,
|
||||
r8a77980, r8a77990, r8a77995)
|
||||
- "extalr" (r8a7795, r8a7796, r8a77965, r8a77970, r8a77980)
|
||||
- "usb_extal" (r8a7743, r8a7745, r8a77470, r8a7790, r8a7791, r8a7793,
|
||||
r8a7794)
|
||||
- "extal" (r7s9210, r8a7743, r8a7744, r8a7745, r8a77470, r8a774a1,
|
||||
r8a774c0, r8a7790, r8a7791, r8a7792, r8a7793, r8a7794,
|
||||
r8a7795, r8a7796, r8a77965, r8a77970, r8a77980, r8a77990,
|
||||
r8a77995)
|
||||
- "extalr" (r8a774a1, r8a7795, r8a7796, r8a77965, r8a77970, r8a77980)
|
||||
- "usb_extal" (r8a7743, r8a7744, r8a7745, r8a77470, r8a7790, r8a7791,
|
||||
r8a7793, r8a7794)
|
||||
|
||||
- #clock-cells: Must be 2
|
||||
- For CPG core clocks, the two clock specifier cells must be "CPG_CORE"
|
||||
|
|
|
|||
|
|
@ -29,15 +29,15 @@ Required properties for usb-c-connector with power delivery support:
|
|||
in "Universal Serial Bus Power Delivery Specification" chapter 6.4.1.2
|
||||
Source_Capabilities Message, the order of each entry(PDO) should follow
|
||||
the PD spec chapter 6.4.1. Required for power source and power dual role.
|
||||
User can specify the source PDO array via PDO_FIXED/BATT/VAR() defined in
|
||||
dt-bindings/usb/pd.h.
|
||||
User can specify the source PDO array via PDO_FIXED/BATT/VAR/PPS_APDO()
|
||||
defined in dt-bindings/usb/pd.h.
|
||||
- sink-pdos: An array of u32 with each entry providing supported power
|
||||
sink data object(PDO), the detailed bit definitions of PDO can be found
|
||||
in "Universal Serial Bus Power Delivery Specification" chapter 6.4.1.3
|
||||
Sink Capabilities Message, the order of each entry(PDO) should follow
|
||||
the PD spec chapter 6.4.1. Required for power sink and power dual role.
|
||||
User can specify the sink PDO array via PDO_FIXED/BATT/VAR() defined in
|
||||
dt-bindings/usb/pd.h.
|
||||
User can specify the sink PDO array via PDO_FIXED/BATT/VAR/PPS_APDO() defined
|
||||
in dt-bindings/usb/pd.h.
|
||||
- op-sink-microwatt: Sink required operating power in microwatt, if source
|
||||
can't offer the power, Capability Mismatch is set. Required for power
|
||||
sink and power dual role.
|
||||
|
|
|
|||
|
|
@ -24,7 +24,7 @@ Optional properties:
|
|||
|
||||
Example:
|
||||
|
||||
p1_sec_a: crypto@400,d2000000 {
|
||||
p1_sec_a: crypto@400d2000000 {
|
||||
compatible = "hisilicon,hip07-sec";
|
||||
reg = <0x400 0xd0000000 0x0 0x10000
|
||||
0x400 0xd2000000 0x0 0x10000
|
||||
|
|
|
|||
|
|
@ -0,0 +1,73 @@
|
|||
==================
|
||||
C-SKY CPU Bindings
|
||||
==================
|
||||
|
||||
The device tree allows to describe the layout of CPUs in a system through
|
||||
the "cpus" node, which in turn contains a number of subnodes (ie "cpu")
|
||||
defining properties for every cpu.
|
||||
|
||||
Only SMP system need to care about the cpus node and single processor
|
||||
needn't define cpus node at all.
|
||||
|
||||
=====================================
|
||||
cpus and cpu node bindings definition
|
||||
=====================================
|
||||
|
||||
- cpus node
|
||||
|
||||
Description: Container of cpu nodes
|
||||
|
||||
The node name must be "cpus".
|
||||
|
||||
A cpus node must define the following properties:
|
||||
|
||||
- #address-cells
|
||||
Usage: required
|
||||
Value type: <u32>
|
||||
Definition: must be set to 1
|
||||
- #size-cells
|
||||
Usage: required
|
||||
Value type: <u32>
|
||||
Definition: must be set to 0
|
||||
|
||||
- cpu node
|
||||
|
||||
Description: Describes one of SMP cores
|
||||
|
||||
PROPERTIES
|
||||
|
||||
- device_type
|
||||
Usage: required
|
||||
Value type: <string>
|
||||
Definition: must be "cpu"
|
||||
- reg
|
||||
Usage: required
|
||||
Value type: <u32>
|
||||
Definition: CPU index
|
||||
- compatible:
|
||||
Usage: required
|
||||
Value type: <string>
|
||||
Definition: must contain "csky", eg:
|
||||
"csky,610"
|
||||
"csky,807"
|
||||
"csky,810"
|
||||
"csky,860"
|
||||
|
||||
Example:
|
||||
--------
|
||||
|
||||
cpus {
|
||||
#address-cells = <1>;
|
||||
#size-cells = <0>;
|
||||
cpu@0 {
|
||||
device_type = "cpu";
|
||||
reg = <0>;
|
||||
status = "ok";
|
||||
};
|
||||
|
||||
cpu@1 {
|
||||
device_type = "cpu";
|
||||
reg = <1>;
|
||||
status = "ok";
|
||||
};
|
||||
};
|
||||
|
|
@ -15,6 +15,13 @@ Required children nodes:
|
|||
to external devices using the OF graph reprensentation (see ../graph.txt).
|
||||
At least one port node is required.
|
||||
|
||||
Optional properties in grandchild nodes:
|
||||
Any endpoint grandchild node may specify a desired video interface
|
||||
according to ../../media/video-interfaces.txt, specifically
|
||||
- bus-width: recognized values are <12>, <16>, <18> and <24>, and
|
||||
override any output mode selection heuristic, forcing "rgb444",
|
||||
"rgb565", "rgb666" and "rgb888" respectively.
|
||||
|
||||
Example:
|
||||
|
||||
hlcdc: hlcdc@f0030000 {
|
||||
|
|
@ -50,3 +57,19 @@ Example:
|
|||
#pwm-cells = <3>;
|
||||
};
|
||||
};
|
||||
|
||||
Example 2: With a video interface override to force rgb565; as above
|
||||
but with these changes/additions:
|
||||
|
||||
&hlcdc {
|
||||
hlcdc-display-controller {
|
||||
pinctrl-names = "default";
|
||||
pinctrl-0 = <&pinctrl_lcd_base &pinctrl_lcd_rgb565>;
|
||||
|
||||
port@0 {
|
||||
hlcdc_panel_output: endpoint@0 {
|
||||
bus-width = <16>;
|
||||
};
|
||||
};
|
||||
};
|
||||
};
|
||||
|
|
|
|||
|
|
@ -22,7 +22,13 @@ among others.
|
|||
|
||||
Required properties:
|
||||
|
||||
- compatible: Must be "lvds-encoder"
|
||||
- compatible: Must be one or more of the following
|
||||
- "ti,ds90c185" for the TI DS90C185 FPD-Link Serializer
|
||||
- "lvds-encoder" for a generic LVDS encoder device
|
||||
|
||||
When compatible with the generic version, nodes must list the
|
||||
device-specific version corresponding to the device first
|
||||
followed by the generic version.
|
||||
|
||||
Required nodes:
|
||||
|
||||
|
|
|
|||
|
|
@ -14,10 +14,22 @@ Required properties:
|
|||
- "renesas,r8a7795-lvds" for R8A7795 (R-Car H3) compatible LVDS encoders
|
||||
- "renesas,r8a7796-lvds" for R8A7796 (R-Car M3-W) compatible LVDS encoders
|
||||
- "renesas,r8a77970-lvds" for R8A77970 (R-Car V3M) compatible LVDS encoders
|
||||
- "renesas,r8a77980-lvds" for R8A77980 (R-Car V3H) compatible LVDS encoders
|
||||
- "renesas,r8a77990-lvds" for R8A77990 (R-Car E3) compatible LVDS encoders
|
||||
- "renesas,r8a77995-lvds" for R8A77995 (R-Car D3) compatible LVDS encoders
|
||||
|
||||
- reg: Base address and length for the memory-mapped registers
|
||||
- clocks: A phandle + clock-specifier pair for the functional clock
|
||||
- clocks: A list of phandles + clock-specifier pairs, one for each entry in
|
||||
the clock-names property.
|
||||
- clock-names: Name of the clocks. This property is model-dependent.
|
||||
- The functional clock, which mandatory for all models, shall be listed
|
||||
first, and shall be named "fck".
|
||||
- On R8A77990 and R8A77995, the LVDS encoder can use the EXTAL or
|
||||
DU_DOTCLKINx clocks. Those clocks are optional. When supplied they must be
|
||||
named "extal" and "dclkin.x" respectively, with "x" being the DU_DOTCLKIN
|
||||
numerical index.
|
||||
- When the clocks property only contains the functional clock, the
|
||||
clock-names property may be omitted.
|
||||
- resets: A phandle + reset specifier for the module reset
|
||||
|
||||
Required nodes:
|
||||
|
|
|
|||
|
|
@ -0,0 +1,87 @@
|
|||
SN65DSI86 DSI to eDP bridge chip
|
||||
--------------------------------
|
||||
|
||||
This is the binding for Texas Instruments SN65DSI86 bridge.
|
||||
http://www.ti.com/general/docs/lit/getliterature.tsp?genericPartNumber=sn65dsi86&fileType=pdf
|
||||
|
||||
Required properties:
|
||||
- compatible: Must be "ti,sn65dsi86"
|
||||
- reg: i2c address of the chip, 0x2d as per datasheet
|
||||
- enable-gpios: gpio specification for bridge_en pin (active high)
|
||||
|
||||
- vccio-supply: A 1.8V supply that powers up the digital IOs.
|
||||
- vpll-supply: A 1.8V supply that powers up the displayport PLL.
|
||||
- vcca-supply: A 1.2V supply that powers up the analog circuits.
|
||||
- vcc-supply: A 1.2V supply that powers up the digital core.
|
||||
|
||||
Optional properties:
|
||||
- interrupts-extended: Specifier for the SN65DSI86 interrupt line.
|
||||
|
||||
- gpio-controller: Marks the device has a GPIO controller.
|
||||
- #gpio-cells : Should be two. The first cell is the pin number and
|
||||
the second cell is used to specify flags.
|
||||
See ../../gpio/gpio.txt for more information.
|
||||
- #pwm-cells : Should be one. See ../../pwm/pwm.txt for description of
|
||||
the cell formats.
|
||||
|
||||
- clock-names: should be "refclk"
|
||||
- clocks: Specification for input reference clock. The reference
|
||||
clock rate must be 12 MHz, 19.2 MHz, 26 MHz, 27 MHz or 38.4 MHz.
|
||||
|
||||
- data-lanes: See ../../media/video-interface.txt
|
||||
- lane-polarities: See ../../media/video-interface.txt
|
||||
|
||||
- suspend-gpios: specification for GPIO1 pin on bridge (active low)
|
||||
|
||||
Required nodes:
|
||||
This device has two video ports. Their connections are modelled using the
|
||||
OF graph bindings specified in Documentation/devicetree/bindings/graph.txt.
|
||||
|
||||
- Video port 0 for DSI input
|
||||
- Video port 1 for eDP output
|
||||
|
||||
Example
|
||||
-------
|
||||
|
||||
edp-bridge@2d {
|
||||
compatible = "ti,sn65dsi86";
|
||||
#address-cells = <1>;
|
||||
#size-cells = <0>;
|
||||
reg = <0x2d>;
|
||||
|
||||
enable-gpios = <&msmgpio 33 GPIO_ACTIVE_HIGH>;
|
||||
suspend-gpios = <&msmgpio 34 GPIO_ACTIVE_LOW>;
|
||||
|
||||
interrupts-extended = <&gpio3 4 IRQ_TYPE_EDGE_FALLING>;
|
||||
|
||||
vccio-supply = <&pm8916_l17>;
|
||||
vcca-supply = <&pm8916_l6>;
|
||||
vpll-supply = <&pm8916_l17>;
|
||||
vcc-supply = <&pm8916_l6>;
|
||||
|
||||
clock-names = "refclk";
|
||||
clocks = <&input_refclk>;
|
||||
|
||||
ports {
|
||||
#address-cells = <1>;
|
||||
#size-cells = <0>;
|
||||
|
||||
port@0 {
|
||||
reg = <0>;
|
||||
|
||||
edp_bridge_in: endpoint {
|
||||
remote-endpoint = <&dsi_out>;
|
||||
};
|
||||
};
|
||||
|
||||
port@1 {
|
||||
reg = <1>;
|
||||
|
||||
edp_bridge_out: endpoint {
|
||||
data-lanes = <2 1 3 0>;
|
||||
lane-polarities = <0 1 0 1>;
|
||||
remote-endpoint = <&edp_panel_in>;
|
||||
};
|
||||
};
|
||||
};
|
||||
}
|
||||
|
|
@ -0,0 +1,35 @@
|
|||
TC358764 MIPI-DSI to LVDS panel bridge
|
||||
|
||||
Required properties:
|
||||
- compatible: "toshiba,tc358764"
|
||||
- reg: the virtual channel number of a DSI peripheral
|
||||
- vddc-supply: core voltage supply, 1.2V
|
||||
- vddio-supply: I/O voltage supply, 1.8V or 3.3V
|
||||
- vddlvds-supply: LVDS1/2 voltage supply, 3.3V
|
||||
- reset-gpios: a GPIO spec for the reset pin
|
||||
|
||||
The device node can contain following 'port' child nodes,
|
||||
according to the OF graph bindings defined in [1]:
|
||||
0: DSI Input, not required, if the bridge is DSI controlled
|
||||
1: LVDS Output, mandatory
|
||||
|
||||
[1]: Documentation/devicetree/bindings/media/video-interfaces.txt
|
||||
|
||||
Example:
|
||||
|
||||
bridge@0 {
|
||||
reg = <0>;
|
||||
compatible = "toshiba,tc358764";
|
||||
vddc-supply = <&vcc_1v2_reg>;
|
||||
vddio-supply = <&vcc_1v8_reg>;
|
||||
vddlvds-supply = <&vcc_3v3_reg>;
|
||||
reset-gpios = <&gpd1 6 GPIO_ACTIVE_LOW>;
|
||||
#address-cells = <1>;
|
||||
#size-cells = <0>;
|
||||
port@1 {
|
||||
reg = <1>;
|
||||
lvds_ep: endpoint {
|
||||
remote-endpoint = <&panel_ep>;
|
||||
};
|
||||
};
|
||||
};
|
||||
|
|
@ -21,6 +21,9 @@ Required properties:
|
|||
- samsung,pll-clock-frequency: specifies frequency of the oscillator clock
|
||||
- #address-cells, #size-cells: should be set respectively to <1> and <0>
|
||||
according to DSI host bindings (see MIPI DSI bindings [1])
|
||||
- samsung,burst-clock-frequency: specifies DSI frequency in high-speed burst
|
||||
mode
|
||||
- samsung,esc-clock-frequency: specifies DSI frequency in escape mode
|
||||
|
||||
Optional properties:
|
||||
- power-domains: a phandle to DSIM power domain node
|
||||
|
|
@ -29,25 +32,9 @@ Child nodes:
|
|||
Should contain DSI peripheral nodes (see MIPI DSI bindings [1]).
|
||||
|
||||
Video interfaces:
|
||||
Device node can contain video interface port nodes according to [2].
|
||||
The following are properties specific to those nodes:
|
||||
|
||||
port node inbound:
|
||||
- reg: (required) must be 0.
|
||||
port node outbound:
|
||||
- reg: (required) must be 1.
|
||||
|
||||
endpoint node connected from mic node (reg = 0):
|
||||
- remote-endpoint: specifies the endpoint in mic node. This node is required
|
||||
for Exynos5433 mipi dsi. So mic can access to panel node
|
||||
throughout this dsi node.
|
||||
endpoint node connected to panel node (reg = 1):
|
||||
- remote-endpoint: specifies the endpoint in panel node. This node is
|
||||
required in all kinds of exynos mipi dsi to represent
|
||||
the connection between mipi dsi and panel.
|
||||
- samsung,burst-clock-frequency: specifies DSI frequency in high-speed burst
|
||||
mode
|
||||
- samsung,esc-clock-frequency: specifies DSI frequency in escape mode
|
||||
Device node can contain following video interface port nodes according to [2]:
|
||||
0: RGB input,
|
||||
1: DSI output
|
||||
|
||||
[1]: Documentation/devicetree/bindings/display/mipi-dsi-bus.txt
|
||||
[2]: Documentation/devicetree/bindings/media/video-interfaces.txt
|
||||
|
|
|
|||
|
|
@ -16,7 +16,7 @@ The following assumes that only a single peripheral is connected to a DSI
|
|||
host. Experience shows that this is true for the large majority of setups.
|
||||
|
||||
DSI host
|
||||
--------
|
||||
========
|
||||
|
||||
In addition to the standard properties and those defined by the parent bus of
|
||||
a DSI host, the following properties apply to a node representing a DSI host.
|
||||
|
|
@ -29,12 +29,24 @@ Required properties:
|
|||
- #size-cells: Should be 0. There are cases where it makes sense to use a
|
||||
different value here. See below.
|
||||
|
||||
DSI peripheral
|
||||
--------------
|
||||
Optional properties:
|
||||
- clock-master: boolean. Should be enabled if the host is being used in
|
||||
conjunction with another DSI host to drive the same peripheral. Hardware
|
||||
supporting such a configuration generally requires the data on both the busses
|
||||
to be driven by the same clock. Only the DSI host instance controlling this
|
||||
clock should contain this property.
|
||||
|
||||
Peripherals are represented as child nodes of the DSI host's node. Properties
|
||||
described here apply to all DSI peripherals, but individual bindings may want
|
||||
to define additional, device-specific properties.
|
||||
DSI peripheral
|
||||
==============
|
||||
|
||||
Peripherals with DSI as control bus, or no control bus
|
||||
------------------------------------------------------
|
||||
|
||||
Peripherals with the DSI bus as the primary control bus, or peripherals with
|
||||
no control bus but use the DSI bus to transmit pixel data are represented
|
||||
as child nodes of the DSI host's node. Properties described here apply to all
|
||||
DSI peripherals, but individual bindings may want to define additional,
|
||||
device-specific properties.
|
||||
|
||||
Required properties:
|
||||
- reg: The virtual channel number of a DSI peripheral. Must be in the range
|
||||
|
|
@ -49,9 +61,37 @@ case two alternative representations can be chosen:
|
|||
property is the number of the first virtual channel and the second cell is
|
||||
the number of consecutive virtual channels.
|
||||
|
||||
Example
|
||||
-------
|
||||
Peripherals with a different control bus
|
||||
----------------------------------------
|
||||
|
||||
There are peripherals that have I2C/SPI (or some other non-DSI bus) as the
|
||||
primary control bus, but are also connected to a DSI bus (mostly for the data
|
||||
path). Connections between such peripherals and a DSI host can be represented
|
||||
using the graph bindings [1], [2].
|
||||
|
||||
Peripherals that support dual channel DSI
|
||||
-----------------------------------------
|
||||
|
||||
Peripherals with higher bandwidth requirements can be connected to 2 DSI
|
||||
busses. Each DSI bus/channel drives some portion of the pixel data (generally
|
||||
left/right half of each line of the display, or even/odd lines of the display).
|
||||
The graph bindings should be used to represent the multiple DSI busses that are
|
||||
connected to this peripheral. Each DSI host's output endpoint can be linked to
|
||||
an input endpoint of the DSI peripheral.
|
||||
|
||||
[1] Documentation/devicetree/bindings/graph.txt
|
||||
[2] Documentation/devicetree/bindings/media/video-interfaces.txt
|
||||
|
||||
Examples
|
||||
========
|
||||
- (1), (2) and (3) are examples of a DSI host and peripheral on the DSI bus
|
||||
with different virtual channel configurations.
|
||||
- (4) is an example of a peripheral on a I2C control bus connected to a
|
||||
DSI host using of-graph bindings.
|
||||
- (5) is an example of 2 DSI hosts driving a dual-channel DSI peripheral,
|
||||
which uses I2C as its primary control bus.
|
||||
|
||||
1)
|
||||
dsi-host {
|
||||
...
|
||||
|
||||
|
|
@ -67,6 +107,7 @@ Example
|
|||
...
|
||||
};
|
||||
|
||||
2)
|
||||
dsi-host {
|
||||
...
|
||||
|
||||
|
|
@ -82,6 +123,7 @@ Example
|
|||
...
|
||||
};
|
||||
|
||||
3)
|
||||
dsi-host {
|
||||
...
|
||||
|
||||
|
|
@ -96,3 +138,98 @@ Example
|
|||
|
||||
...
|
||||
};
|
||||
|
||||
4)
|
||||
i2c-host {
|
||||
...
|
||||
|
||||
dsi-bridge@35 {
|
||||
compatible = "...";
|
||||
reg = <0x35>;
|
||||
|
||||
ports {
|
||||
...
|
||||
|
||||
port {
|
||||
bridge_mipi_in: endpoint {
|
||||
remote-endpoint = <&host_mipi_out>;
|
||||
};
|
||||
};
|
||||
};
|
||||
};
|
||||
};
|
||||
|
||||
dsi-host {
|
||||
...
|
||||
|
||||
ports {
|
||||
...
|
||||
|
||||
port {
|
||||
host_mipi_out: endpoint {
|
||||
remote-endpoint = <&bridge_mipi_in>;
|
||||
};
|
||||
};
|
||||
};
|
||||
};
|
||||
|
||||
5)
|
||||
i2c-host {
|
||||
dsi-bridge@35 {
|
||||
compatible = "...";
|
||||
reg = <0x35>;
|
||||
|
||||
ports {
|
||||
#address-cells = <1>;
|
||||
#size-cells = <0>;
|
||||
|
||||
port@0 {
|
||||
reg = <0>;
|
||||
dsi0_in: endpoint {
|
||||
remote-endpoint = <&dsi0_out>;
|
||||
};
|
||||
};
|
||||
|
||||
port@1 {
|
||||
reg = <1>;
|
||||
dsi1_in: endpoint {
|
||||
remote-endpoint = <&dsi1_out>;
|
||||
};
|
||||
};
|
||||
};
|
||||
};
|
||||
};
|
||||
|
||||
dsi0-host {
|
||||
...
|
||||
|
||||
/*
|
||||
* this DSI instance drives the clock for both the host
|
||||
* controllers
|
||||
*/
|
||||
clock-master;
|
||||
|
||||
ports {
|
||||
...
|
||||
|
||||
port {
|
||||
dsi0_out: endpoint {
|
||||
remote-endpoint = <&dsi0_in>;
|
||||
};
|
||||
};
|
||||
};
|
||||
};
|
||||
|
||||
dsi1-host {
|
||||
...
|
||||
|
||||
ports {
|
||||
...
|
||||
|
||||
port {
|
||||
dsi1_out: endpoint {
|
||||
remote-endpoint = <&dsi1_in>;
|
||||
};
|
||||
};
|
||||
};
|
||||
};
|
||||
|
|
|
|||
|
|
@ -15,6 +15,8 @@ Required Properties:
|
|||
- "renesas,du-r8a7796" for R8A7796 (R-Car M3-W) compatible DU
|
||||
- "renesas,du-r8a77965" for R8A77965 (R-Car M3-N) compatible DU
|
||||
- "renesas,du-r8a77970" for R8A77970 (R-Car V3M) compatible DU
|
||||
- "renesas,du-r8a77980" for R8A77980 (R-Car V3H) compatible DU
|
||||
- "renesas,du-r8a77990" for R8A77990 (R-Car E3) compatible DU
|
||||
- "renesas,du-r8a77995" for R8A77995 (R-Car D3) compatible DU
|
||||
|
||||
- reg: the memory-mapped I/O registers base address and length
|
||||
|
|
@ -61,6 +63,8 @@ corresponding to each DU output.
|
|||
R8A7796 (R-Car M3-W) DPAD 0 HDMI 0 LVDS 0 -
|
||||
R8A77965 (R-Car M3-N) DPAD 0 HDMI 0 LVDS 0 -
|
||||
R8A77970 (R-Car V3M) DPAD 0 LVDS 0 - -
|
||||
R8A77980 (R-Car V3H) DPAD 0 LVDS 0 - -
|
||||
R8A77990 (R-Car E3) DPAD 0 LVDS 0 LVDS 1 -
|
||||
R8A77995 (R-Car D3) DPAD 0 LVDS 0 LVDS 1 -
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -8,6 +8,9 @@ Required properties:
|
|||
- compatible: value should be one of the following
|
||||
"rockchip,rk3036-vop";
|
||||
"rockchip,rk3126-vop";
|
||||
"rockchip,px30-vop-lit";
|
||||
"rockchip,px30-vop-big";
|
||||
"rockchip,rk3188-vop";
|
||||
"rockchip,rk3288-vop";
|
||||
"rockchip,rk3368-vop";
|
||||
"rockchip,rk3366-vop";
|
||||
|
|
|
|||
|
|
@ -78,6 +78,7 @@ Required properties:
|
|||
|
||||
- compatible: value must be one of:
|
||||
* "allwinner,sun8i-a83t-dw-hdmi"
|
||||
* "allwinner,sun50i-a64-dw-hdmi", "allwinner,sun8i-a83t-dw-hdmi"
|
||||
- reg: base address and size of memory-mapped region
|
||||
- reg-io-width: See dw_hdmi.txt. Shall be 1.
|
||||
- interrupts: HDMI interrupt number
|
||||
|
|
@ -96,6 +97,9 @@ Required properties:
|
|||
first port should be the input endpoint. The second should be the
|
||||
output, usually to an HDMI connector.
|
||||
|
||||
Optional properties:
|
||||
- hvcc-supply: the VCC power supply of the controller
|
||||
|
||||
DWC HDMI PHY
|
||||
------------
|
||||
|
||||
|
|
@ -103,6 +107,7 @@ Required properties:
|
|||
- compatible: value must be one of:
|
||||
* allwinner,sun8i-a83t-hdmi-phy
|
||||
* allwinner,sun8i-h3-hdmi-phy
|
||||
* allwinner,sun8i-r40-hdmi-phy
|
||||
* allwinner,sun50i-a64-hdmi-phy
|
||||
- reg: base address and size of memory-mapped region
|
||||
- clocks: phandles to the clocks feeding the HDMI PHY
|
||||
|
|
@ -112,9 +117,9 @@ Required properties:
|
|||
- resets: phandle to the reset controller driving the PHY
|
||||
- reset-names: must be "phy"
|
||||
|
||||
H3 and A64 HDMI PHY require additional clocks:
|
||||
H3, A64 and R40 HDMI PHY require additional clocks:
|
||||
- pll-0: parent of phy clock
|
||||
- pll-1: second possible phy clock parent (A64 only)
|
||||
- pll-1: second possible phy clock parent (A64/R40 only)
|
||||
|
||||
TV Encoder
|
||||
----------
|
||||
|
|
@ -151,6 +156,8 @@ Required properties:
|
|||
* allwinner,sun8i-v3s-tcon
|
||||
* allwinner,sun9i-a80-tcon-lcd
|
||||
* allwinner,sun9i-a80-tcon-tv
|
||||
* "allwinner,sun50i-a64-tcon-lcd", "allwinner,sun8i-a83t-tcon-lcd"
|
||||
* "allwinner,sun50i-a64-tcon-tv", "allwinner,sun8i-a83t-tcon-tv"
|
||||
- reg: base address and size of memory-mapped region
|
||||
- interrupts: interrupt associated to this IP
|
||||
- clocks: phandles to the clocks feeding the TCON.
|
||||
|
|
@ -369,7 +376,11 @@ Required properties:
|
|||
* allwinner,sun8i-a83t-de2-mixer-0
|
||||
* allwinner,sun8i-a83t-de2-mixer-1
|
||||
* allwinner,sun8i-h3-de2-mixer-0
|
||||
* allwinner,sun8i-r40-de2-mixer-0
|
||||
* allwinner,sun8i-r40-de2-mixer-1
|
||||
* allwinner,sun8i-v3s-de2-mixer
|
||||
* allwinner,sun50i-a64-de2-mixer-0
|
||||
* allwinner,sun50i-a64-de2-mixer-1
|
||||
- reg: base address and size of the memory-mapped region.
|
||||
- clocks: phandles to the clocks feeding the mixer
|
||||
* bus: the mixer interface clock
|
||||
|
|
@ -403,6 +414,7 @@ Required properties:
|
|||
* allwinner,sun8i-r40-display-engine
|
||||
* allwinner,sun8i-v3s-display-engine
|
||||
* allwinner,sun9i-a80-display-engine
|
||||
* allwinner,sun50i-a64-display-engine
|
||||
|
||||
- allwinner,pipelines: list of phandle to the display engine
|
||||
frontends (DE 1.0) or mixers (DE 2.0) available.
|
||||
|
|
|
|||
|
|
@ -2,8 +2,13 @@
|
|||
|
||||
Required properties:
|
||||
|
||||
- compatible: Should be "ingenic,jz4780-dma"
|
||||
- reg: Should contain the DMA controller registers location and length.
|
||||
- compatible: Should be one of:
|
||||
* ingenic,jz4740-dma
|
||||
* ingenic,jz4725b-dma
|
||||
* ingenic,jz4770-dma
|
||||
* ingenic,jz4780-dma
|
||||
- reg: Should contain the DMA channel registers location and length, followed
|
||||
by the DMA controller registers location and length.
|
||||
- interrupts: Should contain the interrupt specifier of the DMA controller.
|
||||
- clocks: Should contain a clock specifier for the JZ4780 PDMA clock.
|
||||
- #dma-cells: Must be <2>. Number of integer cells in the dmas property of
|
||||
|
|
@ -19,9 +24,10 @@ Optional properties:
|
|||
|
||||
Example:
|
||||
|
||||
dma: dma@13420000 {
|
||||
dma: dma-controller@13420000 {
|
||||
compatible = "ingenic,jz4780-dma";
|
||||
reg = <0x13420000 0x10000>;
|
||||
reg = <0x13420000 0x400
|
||||
0x13421000 0x40>;
|
||||
|
||||
interrupt-parent = <&intc>;
|
||||
interrupts = <10>;
|
||||
|
|
|
|||
|
|
@ -17,6 +17,7 @@ Required Properties:
|
|||
- compatible: "renesas,dmac-<soctype>", "renesas,rcar-dmac" as fallback.
|
||||
Examples with soctypes are:
|
||||
- "renesas,dmac-r8a7743" (RZ/G1M)
|
||||
- "renesas,dmac-r8a7744" (RZ/G1N)
|
||||
- "renesas,dmac-r8a7745" (RZ/G1E)
|
||||
- "renesas,dmac-r8a77470" (RZ/G1C)
|
||||
- "renesas,dmac-r8a7790" (R-Car H2)
|
||||
|
|
|
|||
|
|
@ -4,6 +4,7 @@ Required Properties:
|
|||
-compatible: "renesas,<soctype>-usb-dmac", "renesas,usb-dmac" as fallback.
|
||||
Examples with soctypes are:
|
||||
- "renesas,r8a7743-usb-dmac" (RZ/G1M)
|
||||
- "renesas,r8a7744-usb-dmac" (RZ/G1N)
|
||||
- "renesas,r8a7745-usb-dmac" (RZ/G1E)
|
||||
- "renesas,r8a7790-usb-dmac" (R-Car H2)
|
||||
- "renesas,r8a7791-usb-dmac" (R-Car M2-W)
|
||||
|
|
|
|||
|
|
@ -7,16 +7,23 @@ assorted actions.
|
|||
|
||||
Required properties:
|
||||
- compatible: must contain one of the following:
|
||||
* "qcom,scm-apq8064" for APQ8064 platforms
|
||||
* "qcom,scm-msm8660" for MSM8660 platforms
|
||||
* "qcom,scm-msm8690" for MSM8690 platforms
|
||||
* "qcom,scm-msm8996" for MSM8996 platforms
|
||||
* "qcom,scm-ipq4019" for IPQ4019 platforms
|
||||
* "qcom,scm" for later processors (MSM8916, APQ8084, MSM8974, etc)
|
||||
- clocks: One to three clocks may be required based on compatible.
|
||||
* No clock required for "qcom,scm-msm8996", "qcom,scm-ipq4019"
|
||||
* Only core clock required for "qcom,scm-apq8064", "qcom,scm-msm8660", and "qcom,scm-msm8960"
|
||||
* Core, iface, and bus clocks required for "qcom,scm"
|
||||
* "qcom,scm-apq8064"
|
||||
* "qcom,scm-apq8084"
|
||||
* "qcom,scm-msm8660"
|
||||
* "qcom,scm-msm8916"
|
||||
* "qcom,scm-msm8960"
|
||||
* "qcom,scm-msm8974"
|
||||
* "qcom,scm-msm8996"
|
||||
* "qcom,scm-msm8998"
|
||||
* "qcom,scm-ipq4019"
|
||||
* "qcom,scm-sdm845"
|
||||
and:
|
||||
* "qcom,scm"
|
||||
- clocks: Specifies clocks needed by the SCM interface, if any:
|
||||
* core clock required for "qcom,scm-apq8064", "qcom,scm-msm8660" and
|
||||
"qcom,scm-msm8960"
|
||||
* core, iface and bus clocks required for "qcom,scm-apq8084",
|
||||
"qcom,scm-msm8916" and "qcom,scm-msm8974"
|
||||
- clock-names: Must contain "core" for the core clock, "iface" for the interface
|
||||
clock and "bus" for the bus clock per the requirements of the compatible.
|
||||
- qcom,dload-mode: phandle to the TCSR hardware block and offset of the
|
||||
|
|
@ -26,8 +33,10 @@ Example for MSM8916:
|
|||
|
||||
firmware {
|
||||
scm {
|
||||
compatible = "qcom,scm";
|
||||
clocks = <&gcc GCC_CRYPTO_CLK> , <&gcc GCC_CRYPTO_AXI_CLK>, <&gcc GCC_CRYPTO_AHB_CLK>;
|
||||
compatible = "qcom,msm8916", "qcom,scm";
|
||||
clocks = <&gcc GCC_CRYPTO_CLK> ,
|
||||
<&gcc GCC_CRYPTO_AXI_CLK>,
|
||||
<&gcc GCC_CRYPTO_AHB_CLK>;
|
||||
clock-names = "core", "bus", "iface";
|
||||
};
|
||||
};
|
||||
|
|
|
|||
|
|
@ -0,0 +1,82 @@
|
|||
-----------------------------------------------------------------
|
||||
Device Tree Bindings for the Xilinx Zynq MPSoC Firmware Interface
|
||||
-----------------------------------------------------------------
|
||||
|
||||
The zynqmp-firmware node describes the interface to platform firmware.
|
||||
ZynqMP has an interface to communicate with secure firmware. Firmware
|
||||
driver provides an interface to firmware APIs. Interface APIs can be
|
||||
used by any driver to communicate to PMUFW(Platform Management Unit).
|
||||
These requests include clock management, pin control, device control,
|
||||
power management service, FPGA service and other platform management
|
||||
services.
|
||||
|
||||
Required properties:
|
||||
- compatible: Must contain: "xlnx,zynqmp-firmware"
|
||||
- method: The method of calling the PM-API firmware layer.
|
||||
Permitted values are:
|
||||
- "smc" : SMC #0, following the SMCCC
|
||||
- "hvc" : HVC #0, following the SMCCC
|
||||
|
||||
--------------------------------------------------------------------------
|
||||
Device Tree Clock bindings for the Zynq Ultrascale+ MPSoC controlled using
|
||||
Zynq MPSoC firmware interface
|
||||
--------------------------------------------------------------------------
|
||||
The clock controller is a h/w block of Zynq Ultrascale+ MPSoC clock
|
||||
tree. It reads required input clock frequencies from the devicetree and acts
|
||||
as clock provider for all clock consumers of PS clocks.
|
||||
|
||||
See clock_bindings.txt for more information on the generic clock bindings.
|
||||
|
||||
Required properties:
|
||||
- #clock-cells: Must be 1
|
||||
- compatible: Must contain: "xlnx,zynqmp-clk"
|
||||
- clocks: List of clock specifiers which are external input
|
||||
clocks to the given clock controller. Please refer
|
||||
the next section to find the input clocks for a
|
||||
given controller.
|
||||
- clock-names: List of clock names which are exteral input clocks
|
||||
to the given clock controller. Please refer to the
|
||||
clock bindings for more details.
|
||||
|
||||
Input clocks for zynqmp Ultrascale+ clock controller:
|
||||
|
||||
The Zynq UltraScale+ MPSoC has one primary and four alternative reference clock
|
||||
inputs. These required clock inputs are:
|
||||
- pss_ref_clk (PS reference clock)
|
||||
- video_clk (reference clock for video system )
|
||||
- pss_alt_ref_clk (alternative PS reference clock)
|
||||
- aux_ref_clk
|
||||
- gt_crx_ref_clk (transceiver reference clock)
|
||||
|
||||
The following strings are optional parameters to the 'clock-names' property in
|
||||
order to provide an optional (E)MIO clock source:
|
||||
- swdt0_ext_clk
|
||||
- swdt1_ext_clk
|
||||
- gem0_emio_clk
|
||||
- gem1_emio_clk
|
||||
- gem2_emio_clk
|
||||
- gem3_emio_clk
|
||||
- mio_clk_XX # with XX = 00..77
|
||||
- mio_clk_50_or_51 #for the mux clock to gem tsu from 50 or 51
|
||||
|
||||
|
||||
Output clocks are registered based on clock information received
|
||||
from firmware. Output clocks indexes are mentioned in
|
||||
include/dt-bindings/clock/xlnx,zynqmp-clk.h.
|
||||
|
||||
-------
|
||||
Example
|
||||
-------
|
||||
|
||||
firmware {
|
||||
zynqmp_firmware: zynqmp-firmware {
|
||||
compatible = "xlnx,zynqmp-firmware";
|
||||
method = "smc";
|
||||
zynqmp_clk: clock-controller {
|
||||
#clock-cells = <1>;
|
||||
compatible = "xlnx,zynqmp-clk";
|
||||
clocks = <&pss_ref_clk>, <&video_clk>, <&pss_alt_ref_clk>, <&aux_ref_clk>, <>_crx_ref_clk>;
|
||||
clock-names = "pss_ref_clk", "video_clk", "pss_alt_ref_clk","aux_ref_clk", "gt_crx_ref_clk";
|
||||
};
|
||||
};
|
||||
};
|
||||
|
|
@ -415,7 +415,7 @@ DT Overlay contains:
|
|||
firmware-name = "base.rbf";
|
||||
|
||||
fpga-bridge@4400 {
|
||||
compatible = "altr,freeze-bridge";
|
||||
compatible = "altr,freeze-bridge-controller";
|
||||
reg = <0x4400 0x10>;
|
||||
|
||||
fpga_region1: fpga-region1 {
|
||||
|
|
@ -427,7 +427,7 @@ DT Overlay contains:
|
|||
};
|
||||
|
||||
fpga-bridge@4420 {
|
||||
compatible = "altr,freeze-bridge";
|
||||
compatible = "altr,freeze-bridge-controller";
|
||||
reg = <0x4420 0x10>;
|
||||
|
||||
fpga_region2: fpga-region2 {
|
||||
|
|
|
|||
|
|
@ -3,6 +3,7 @@
|
|||
Required properties :
|
||||
|
||||
- compatible : should be "snps,designware-i2c"
|
||||
or "mscc,ocelot-i2c" with "snps,designware-i2c" for fallback
|
||||
- reg : Offset and length of the register set for the device
|
||||
- interrupts : <IRQ> where IRQ is the interrupt number.
|
||||
|
||||
|
|
@ -11,8 +12,12 @@ Recommended properties :
|
|||
- clock-frequency : desired I2C bus clock frequency in Hz.
|
||||
|
||||
Optional properties :
|
||||
- reg : for "mscc,ocelot-i2c", a second register set to configure the SDA hold
|
||||
time, named ICPU_CFG:TWI_DELAY in the datasheet.
|
||||
|
||||
- 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.
|
||||
This option is only supported in hardware blocks version 1.11a or newer and
|
||||
on Microsemi SoCs ("mscc,ocelot-i2c" compatible).
|
||||
|
||||
- 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.
|
||||
|
|
|
|||
|
|
@ -3,7 +3,9 @@ I2C for R-Car platforms
|
|||
Required properties:
|
||||
- compatible:
|
||||
"renesas,i2c-r8a7743" if the device is a part of a R8A7743 SoC.
|
||||
"renesas,i2c-r8a7744" if the device is a part of a R8A7744 SoC.
|
||||
"renesas,i2c-r8a7745" if the device is a part of a R8A7745 SoC.
|
||||
"renesas,i2c-r8a77470" if the device is a part of a R8A77470 SoC.
|
||||
"renesas,i2c-r8a774a1" if the device is a part of a R8A774A1 SoC.
|
||||
"renesas,i2c-r8a7778" if the device is a part of a R8A7778 SoC.
|
||||
"renesas,i2c-r8a7779" if the device is a part of a R8A7779 SoC.
|
||||
|
|
|
|||
|
|
@ -5,6 +5,7 @@ Required properties:
|
|||
- "renesas,iic-r8a73a4" (R-Mobile APE6)
|
||||
- "renesas,iic-r8a7740" (R-Mobile A1)
|
||||
- "renesas,iic-r8a7743" (RZ/G1M)
|
||||
- "renesas,iic-r8a7744" (RZ/G1N)
|
||||
- "renesas,iic-r8a7745" (RZ/G1E)
|
||||
- "renesas,iic-r8a774a1" (RZ/G2M)
|
||||
- "renesas,iic-r8a7790" (R-Car H2)
|
||||
|
|
|
|||
|
|
@ -84,7 +84,7 @@ Binding may contain optional "interrupts" property, describing interrupts
|
|||
used by the device. I2C core will assign "irq" interrupt (or the very first
|
||||
interrupt if not using interrupt names) as primary interrupt for the slave.
|
||||
|
||||
Alternatively, devices supporting SMbus Host Notify, and connected to
|
||||
Alternatively, devices supporting SMBus Host Notify, and connected to
|
||||
adapters that support this feature, may use "host-notify" property. I2C
|
||||
core will create a virtual interrupt for Host Notify and assign it as
|
||||
primary interrupt for the slave.
|
||||
|
|
|
|||
|
|
@ -0,0 +1,33 @@
|
|||
Analog Devices ADXL372 3-Axis, +/-(200g) Digital Accelerometer
|
||||
|
||||
http://www.analog.com/media/en/technical-documentation/data-sheets/adxl372.pdf
|
||||
|
||||
Required properties:
|
||||
- compatible : should be "adi,adxl372"
|
||||
- reg: the I2C address or SPI chip select number for the device
|
||||
|
||||
Required properties for SPI bus usage:
|
||||
- spi-max-frequency: Max SPI frequency to use
|
||||
|
||||
Optional properties:
|
||||
- interrupts: interrupt mapping for IRQ as documented in
|
||||
Documentation/devicetree/bindings/interrupt-controller/interrupts.txt
|
||||
|
||||
Example for a I2C device node:
|
||||
|
||||
accelerometer@53 {
|
||||
compatible = "adi,adxl372";
|
||||
reg = <0x53>;
|
||||
interrupt-parent = <&gpio>;
|
||||
interrupts = <25 IRQ_TYPE_EDGE_FALLING>;
|
||||
};
|
||||
|
||||
Example for a SPI device node:
|
||||
|
||||
accelerometer@0 {
|
||||
compatible = "adi,adxl372";
|
||||
reg = <0>;
|
||||
spi-max-frequency = <1000000>;
|
||||
interrupt-parent = <&gpio>;
|
||||
interrupts = <25 IRQ_TYPE_EDGE_FALLING>;
|
||||
};
|
||||
|
|
@ -0,0 +1,30 @@
|
|||
* Microchip MCP3911 Dual channel analog front end (ADC)
|
||||
|
||||
Required properties:
|
||||
- compatible: Should be "microchip,mcp3911"
|
||||
- reg: SPI chip select number for the device
|
||||
|
||||
Recommended properties:
|
||||
- spi-max-frequency: Definition as per
|
||||
Documentation/devicetree/bindings/spi/spi-bus.txt.
|
||||
Max frequency for this chip is 20MHz.
|
||||
|
||||
Optional properties:
|
||||
- clocks: Phandle and clock identifier for sampling clock
|
||||
- interrupt-parent: Phandle to the parent interrupt controller
|
||||
- interrupts: IRQ line for the ADC
|
||||
- microchip,device-addr: Device address when multiple MCP3911 chips are present on the
|
||||
same SPI bus. Valid values are 0-3. Defaults to 0.
|
||||
- vref-supply: Phandle to the external reference voltage supply.
|
||||
|
||||
Example:
|
||||
adc@0 {
|
||||
compatible = "microchip,mcp3911";
|
||||
reg = <0>;
|
||||
interrupt-parent = <&gpio5>;
|
||||
interrupts = <15 IRQ_TYPE_EDGE_RISING>;
|
||||
spi-max-frequency = <20000000>;
|
||||
microchip,device-addr = <0>;
|
||||
vref-supply = <&vref_reg>;
|
||||
clocks = <&xtal>;
|
||||
};
|
||||
|
|
@ -1,7 +1,9 @@
|
|||
Qualcomm's SPMI PMIC voltage ADC
|
||||
Qualcomm's SPMI PMIC ADC
|
||||
|
||||
SPMI PMIC voltage ADC (VADC) provides interface to clients to read
|
||||
voltage. The VADC is a 15-bit sigma-delta ADC.
|
||||
- SPMI PMIC voltage ADC (VADC) provides interface to clients to read
|
||||
voltage. The VADC is a 15-bit sigma-delta ADC.
|
||||
- SPMI PMIC5 voltage ADC (ADC) provides interface to clients to read
|
||||
voltage. The VADC is a 16-bit sigma-delta ADC.
|
||||
|
||||
VADC node:
|
||||
|
||||
|
|
@ -9,11 +11,13 @@ VADC node:
|
|||
Usage: required
|
||||
Value type: <string>
|
||||
Definition: Should contain "qcom,spmi-vadc".
|
||||
Should contain "qcom,spmi-adc5" for PMIC5 ADC driver.
|
||||
Should contain "qcom,spmi-adc-rev2" for PMIC rev2 ADC driver.
|
||||
|
||||
- reg:
|
||||
Usage: required
|
||||
Value type: <prop-encoded-array>
|
||||
Definition: VADC base address and length in the SPMI PMIC register map.
|
||||
Definition: VADC base address in the SPMI PMIC register map.
|
||||
|
||||
- #address-cells:
|
||||
Usage: required
|
||||
|
|
@ -45,13 +49,26 @@ Channel node properties:
|
|||
Definition: ADC channel number.
|
||||
See include/dt-bindings/iio/qcom,spmi-vadc.h
|
||||
|
||||
- label:
|
||||
Usage: required for "qcom,spmi-adc5" and "qcom,spmi-adc-rev2"
|
||||
Value type: <empty>
|
||||
Definition: ADC input of the platform as seen in the schematics.
|
||||
For thermistor inputs connected to generic AMUX or GPIO inputs
|
||||
these can vary across platform for the same pins. Hence select
|
||||
the platform schematics name for this channel.
|
||||
|
||||
- qcom,decimation:
|
||||
Usage: optional
|
||||
Value type: <u32>
|
||||
Definition: This parameter is used to decrease ADC sampling rate.
|
||||
Quicker measurements can be made by reducing decimation ratio.
|
||||
Valid values are 512, 1024, 2048, 4096.
|
||||
If property is not found, default value of 512 will be used.
|
||||
- For compatible property "qcom,spmi-vadc", valid values are
|
||||
512, 1024, 2048, 4096. If property is not found, default value
|
||||
of 512 will be used.
|
||||
- For compatible property "qcom,spmi-adc5", valid values are 250, 420
|
||||
and 840. If property is not found, default value of 840 is used.
|
||||
- For compatible property "qcom,spmi-adc-rev2", valid values are 256,
|
||||
512 and 1024. If property is not present, default value is 1024.
|
||||
|
||||
- qcom,pre-scaling:
|
||||
Usage: optional
|
||||
|
|
@ -66,21 +83,38 @@ Channel node properties:
|
|||
- qcom,ratiometric:
|
||||
Usage: optional
|
||||
Value type: <empty>
|
||||
Definition: Channel calibration type. If this property is specified
|
||||
VADC will use the VDD reference (1.8V) and GND for channel
|
||||
calibration. If property is not found, channel will be
|
||||
calibrated with 0.625V and 1.25V reference channels, also
|
||||
known as absolute calibration.
|
||||
Definition: Channel calibration type.
|
||||
- For compatible property "qcom,spmi-vadc", if this property is
|
||||
specified VADC will use the VDD reference (1.8V) and GND for
|
||||
channel calibration. If property is not found, channel will be
|
||||
calibrated with 0.625V and 1.25V reference channels, also
|
||||
known as absolute calibration.
|
||||
- For compatible property "qcom,spmi-adc5" and "qcom,spmi-adc-rev2",
|
||||
if this property is specified VADC will use the VDD reference
|
||||
(1.875V) and GND for channel calibration. If property is not found,
|
||||
channel will be calibrated with 0V and 1.25V reference channels,
|
||||
also known as absolute calibration.
|
||||
|
||||
- qcom,hw-settle-time:
|
||||
Usage: optional
|
||||
Value type: <u32>
|
||||
Definition: Time between AMUX getting configured and the ADC starting
|
||||
conversion. Delay = 100us * (value) for value < 11, and
|
||||
2ms * (value - 10) otherwise.
|
||||
Valid values are: 0, 100, 200, 300, 400, 500, 600, 700, 800,
|
||||
900 us and 1, 2, 4, 6, 8, 10 ms
|
||||
If property is not found, channel will use 0us.
|
||||
conversion. The 'hw_settle_time' is an index used from valid values
|
||||
and programmed in hardware to achieve the hardware settling delay.
|
||||
- For compatible property "qcom,spmi-vadc" and "qcom,spmi-adc-rev2",
|
||||
Delay = 100us * (hw_settle_time) for hw_settle_time < 11,
|
||||
and 2ms * (hw_settle_time - 10) otherwise.
|
||||
Valid values are: 0, 100, 200, 300, 400, 500, 600, 700, 800,
|
||||
900 us and 1, 2, 4, 6, 8, 10 ms.
|
||||
If property is not found, channel will use 0us.
|
||||
- For compatible property "qcom,spmi-adc5", delay = 15us for
|
||||
value 0, 100us * (value) for values < 11,
|
||||
and 2ms * (value - 10) otherwise.
|
||||
Valid values are: 15, 100, 200, 300, 400, 500, 600, 700, 800,
|
||||
900 us and 1, 2, 4, 6, 8, 10 ms
|
||||
Certain controller digital versions have valid values of
|
||||
15, 100, 200, 300, 400, 500, 600, 700, 1, 2, 4, 8, 16, 32, 64, 128 ms
|
||||
If property is not found, channel will use 15us.
|
||||
|
||||
- qcom,avg-samples:
|
||||
Usage: optional
|
||||
|
|
@ -89,13 +123,18 @@ Channel node properties:
|
|||
Averaging provides the option to obtain a single measurement
|
||||
from the ADC that is an average of multiple samples. The value
|
||||
selected is 2^(value).
|
||||
Valid values are: 1, 2, 4, 8, 16, 32, 64, 128, 256, 512
|
||||
If property is not found, 1 sample will be used.
|
||||
- For compatible property "qcom,spmi-vadc", valid values
|
||||
are: 1, 2, 4, 8, 16, 32, 64, 128, 256, 512
|
||||
If property is not found, 1 sample will be used.
|
||||
- For compatible property "qcom,spmi-adc5" and "qcom,spmi-adc-rev2",
|
||||
valid values are: 1, 2, 4, 8, 16
|
||||
If property is not found, 1 sample will be used.
|
||||
|
||||
NOTE:
|
||||
|
||||
Following channels, also known as reference point channels, are used for
|
||||
result calibration and their channel configuration nodes should be defined:
|
||||
For compatible property "qcom,spmi-vadc" following channels, also known as
|
||||
reference point channels, are used for result calibration and their channel
|
||||
configuration nodes should be defined:
|
||||
VADC_REF_625MV and/or VADC_SPARE1(based on PMIC version) VADC_REF_1250MV,
|
||||
VADC_GND_REF and VADC_VDD_VADC.
|
||||
|
||||
|
|
@ -104,7 +143,7 @@ Example:
|
|||
/* VADC node */
|
||||
pmic_vadc: vadc@3100 {
|
||||
compatible = "qcom,spmi-vadc";
|
||||
reg = <0x3100 0x100>;
|
||||
reg = <0x3100>;
|
||||
interrupts = <0x0 0x31 0x0 IRQ_TYPE_EDGE_RISING>;
|
||||
#address-cells = <1>;
|
||||
#size-cells = <0>;
|
||||
|
|
|
|||
|
|
@ -12,6 +12,8 @@ Required properties:
|
|||
- interrupts: The interrupt number for the ADC device.
|
||||
- #io-channel-cells: Number of cells in an IIO specifier.
|
||||
- hwlocks: Reference to a phandle of a hwlock provider node.
|
||||
- nvmem-cells: A phandle to the calibration cells provided by eFuse device.
|
||||
- nvmem-cell-names: Should be "big_scale_calib", "small_scale_calib".
|
||||
|
||||
Example:
|
||||
|
||||
|
|
@ -32,5 +34,7 @@ Example:
|
|||
interrupts = <0 IRQ_TYPE_LEVEL_HIGH>;
|
||||
#io-channel-cells = <1>;
|
||||
hwlocks = <&hwlock 4>;
|
||||
nvmem-cells = <&adc_big_scale>, <&adc_small_scale>;
|
||||
nvmem-cell-names = "big_scale_calib", "small_scale_calib";
|
||||
};
|
||||
};
|
||||
|
|
|
|||
Some files were not shown because too many files have changed in this diff Show More
Loading…
Reference in New Issue