AuxXxilium/linux_dsm_epyc7002
1
0
Fork 0
mirror of https://github.com/AuxXxilium/linux_dsm_epyc7002.git synced 2024-11-24 09:30:52 +07:00
Code Issues Actions Packages Projects Releases Wiki Activity

KVM: s390: Fix for 5.7 and maintainer update

Browse Source 
- Silence false positive lockdep warning
 - add Claudio as reviewer
 -----BEGIN PGP SIGNATURE-----
 Version: GnuPG v2.0.22 (GNU/Linux)
 
 iQIcBAABAgAGBQJenY6AAAoJEBF7vIC1phx8bykQAK+QZyD+H/zGNuqeUVn0sh8e
 yKUVMR+kuE+l57q77nt2AYVxqpCD9xSKRR+SOSLzhVH/HJf625nm+Ny/WOWMebwJ
 EA/KK+v15T5rga8gFza+4cPg4v/pHwjHhSbjTb1JWg+8cJR1BTj6OxRuTtWr5+25
 GF4RhkJOit/VhNbCo1aIgs7/7F1pPALstdPAUsHYe1PeULdRMVqSVluXT2KTPhpi
 /kzDw8sKKcYgv/eaVdcNoHv+VX1AWIRDAKEttCywyocfbu0ESwadmR7C0qlm1446
 HqowP6F0xCF0Whi/65aN4ZOv7wjO/qrV08DZ7JLA3/oKlXtZ1ieyiE2q/P1frSo1
 gvmuHiH5/UI6t6a/BSCpJwqcilxKYArqAAYBKoGiJhTbsJStqw0wl41klWTKXlTq
 VrCvjoUxQ9JMjFCQ1GXOU+ODNyX2IwZYptJ5vF24HYzBJwUBe3HPG9/BA8YcodzG
 qGQ5IKv0Q1IFTwOqnt557H0MjcBtNIEx54aLJrPy3wldsiNSj39Ft0cuvnbR+Q4F
 QhKk88dHtd7NW1IirfgYmLGe0rB1ANKM7wUGEdM5w2y5Eg8wCs8/P4KeGh0YyFI9
 xPqZDfwof6KkDjOGFXr/CeD/thi+km0/FpePb7cL5Ow4a+JmrCvqQiXrf0TbnFpv
 t5ZlHnGzoSHsEaRgmJ+X
 =d46L
 -----END PGP SIGNATURE-----

Merge tag 'kvm-s390-master-5.7-2' of git://git.kernel.org/pub/scm/linux/kernel/git/kvms390/linux into kvm-master

KVM: s390: Fix for 5.7 and maintainer update

- Silence false positive lockdep warning
- add Claudio as reviewer
This commit is contained in:
Paolo Bonzini 2020-04-21 09:37:13 -04:00
commit 3bda03865f
4691 changed files with 184496 additions and 69619 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

1
.gitignore vendored
View File

@ -1,3 +1,4 @@
# SPDX-License-Identifier: GPL-2.0-only
#
# NOTE! Don't add files that are generated in specific
# subdirectories here. Add them in the ".gitignore" file

2
.mailmap
View File

@ -210,6 +210,7 @@ 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>
Pali Rohár <pali@kernel.org> <pali.rohar@gmail.com>
Paolo 'Blaisorblade' Giarrusso <blaisorblade@yahoo.it>
Patrick Mochel <mochel@digitalimplant.org>
Paul Burton <paulburton@kernel.org> <paul.burton@imgtec.com>
@ -248,6 +249,7 @@ Sakari Ailus <sakari.ailus@linux.intel.com> <sakari.ailus@iki.fi>
Sean Nyekjaer <sean@geanix.com> <sean.nyekjaer@prevas.dk>
Sebastian Reichel <sre@kernel.org> <sre@debian.org>
Sebastian Reichel <sre@kernel.org> <sebastian.reichel@collabora.co.uk>
Sedat Dilek <sedat.dilek@gmail.com> <sedat.dilek@credativ.de>
Shiraz Hashim <shiraz.linux.kernel@gmail.com> <shiraz.hashim@st.com>
Shuah Khan <shuah@kernel.org> <shuahkhan@gmail.com>
Shuah Khan <shuah@kernel.org> <shuah.khan@hp.com>

1
Documentation/.gitignore vendored
View File

@ -1,2 +1,3 @@
# SPDX-License-Identifier: GPL-2.0-only
output
*.pyc

9
Documentation/ABI/obsolete/sysfs-kernel-fadump_enabled Normal file
View File

@ -0,0 +1,9 @@
This ABI is renamed and moved to a new location /sys/kernel/fadump/enabled.
What: /sys/kernel/fadump_enabled
Date: Feb 2012
Contact: linuxppc-dev@lists.ozlabs.org
Description: read only
Primarily used to identify whether the FADump is enabled in
the kernel or not.
User: Kdump service

10
Documentation/ABI/obsolete/sysfs-kernel-fadump_registered Normal file
View File

@ -0,0 +1,10 @@
This ABI is renamed and moved to a new location /sys/kernel/fadump/registered.¬
What: /sys/kernel/fadump_registered
Date: Feb 2012
Contact: linuxppc-dev@lists.ozlabs.org
Description: read/write
Helps to control the dump collect feature from userspace.
Setting 1 to this file enables the system to collect the
dump and 0 to disable it.
User: Kdump service

10
Documentation/ABI/obsolete/sysfs-kernel-fadump_release_mem Normal file
View File

@ -0,0 +1,10 @@
This ABI is renamed and moved to a new location /sys/kernel/fadump/release_mem.¬
What: /sys/kernel/fadump_release_mem
Date: Feb 2012
Contact: linuxppc-dev@lists.ozlabs.org
Description: write only
This is a special sysfs file and only available when
the system is booted to capture the vmcore using FADump.
It is used to release the memory reserved by FADump to
save the crash dump.

9
Documentation/ABI/removed/sysfs-kernel-fadump_release_opalcore Normal file
View File

@ -0,0 +1,9 @@
This ABI is moved to /sys/firmware/opal/mpipl/release_core.
What: /sys/kernel/fadump_release_opalcore
Date: Sep 2019
Contact: linuxppc-dev@lists.ozlabs.org
Description: write only
The sysfs file is available when the system is booted to
collect the dump on OPAL based machine. It used to release
the memory used to collect the opalcore.

14
Documentation/ABI/testing/debugfs-driver-habanalabs
View File

@ -43,6 +43,20 @@ Description: Allows the root user to read or write directly through the
If the IOMMU is disabled, it also allows the root user to read
or write from the host a device VA of a host mapped memory
What: /sys/kernel/debug/habanalabs/hl<n>/data64
Date: Jan 2020
KernelVersion: 5.6
Contact: oded.gabbay@gmail.com
Description: Allows the root user to read or write 64 bit data directly
through the device's PCI bar. Writing to this file generates a
write transaction while reading from the file generates a read
transaction. This custom interface is needed (instead of using
the generic Linux user-space PCI mapping) because the DDR bar
is very small compared to the DDR memory and only the driver can
move the bar before and after the transaction.
If the IOMMU is disabled, it also allows the root user to read
or write from the host a device VA of a host mapped memory
What: /sys/kernel/debug/habanalabs/hl<n>/device
Date: Jan 2019
KernelVersion: 5.1

241
Documentation/ABI/testing/sysfs-bus-coresight-devices-cti Normal file
View File

@ -0,0 +1,241 @@
What: /sys/bus/coresight/devices/<cti-name>/enable
Date: March 2020
KernelVersion 5.7
Contact: Mike Leach or Mathieu Poirier
Description: (RW) Enable/Disable the CTI hardware.
What: /sys/bus/coresight/devices/<cti-name>/powered
Date: March 2020
KernelVersion 5.7
Contact: Mike Leach or Mathieu Poirier
Description: (R) Indicate if the CTI hardware is powered.
What: /sys/bus/coresight/devices/<cti-name>/ctmid
Date: March 2020
KernelVersion 5.7
Contact: Mike Leach or Mathieu Poirier
Description: (R) Display the associated CTM ID
What: /sys/bus/coresight/devices/<cti-name>/nr_trigger_cons
Date: March 2020
KernelVersion 5.7
Contact: Mike Leach or Mathieu Poirier
Description: (R) Number of devices connected to triggers on this CTI
What: /sys/bus/coresight/devices/<cti-name>/triggers<N>/name
Date: March 2020
KernelVersion 5.7
Contact: Mike Leach or Mathieu Poirier
Description: (R) Name of connected device <N>
What: /sys/bus/coresight/devices/<cti-name>/triggers<N>/in_signals
Date: March 2020
KernelVersion 5.7
Contact: Mike Leach or Mathieu Poirier
Description: (R) Input trigger signals from connected device <N>
What: /sys/bus/coresight/devices/<cti-name>/triggers<N>/in_types
Date: March 2020
KernelVersion 5.7
Contact: Mike Leach or Mathieu Poirier
Description: (R) Functional types for the input trigger signals
from connected device <N>
What: /sys/bus/coresight/devices/<cti-name>/triggers<N>/out_signals
Date: March 2020
KernelVersion 5.7
Contact: Mike Leach or Mathieu Poirier
Description: (R) Output trigger signals to connected device <N>
What: /sys/bus/coresight/devices/<cti-name>/triggers<N>/out_types
Date: March 2020
KernelVersion 5.7
Contact: Mike Leach or Mathieu Poirier
Description: (R) Functional types for the output trigger signals
to connected device <N>
What: /sys/bus/coresight/devices/<cti-name>/regs/inout_sel
Date: March 2020
KernelVersion 5.7
Contact: Mike Leach or Mathieu Poirier
Description: (RW) Select the index for inen and outen registers.
What: /sys/bus/coresight/devices/<cti-name>/regs/inen
Date: March 2020
KernelVersion 5.7
Contact: Mike Leach or Mathieu Poirier
Description: (RW) Read or write the CTIINEN register selected by inout_sel.
What: /sys/bus/coresight/devices/<cti-name>/regs/outen
Date: March 2020
KernelVersion 5.7
Contact: Mike Leach or Mathieu Poirier
Description: (RW) Read or write the CTIOUTEN register selected by inout_sel.
What: /sys/bus/coresight/devices/<cti-name>/regs/gate
Date: March 2020
KernelVersion 5.7
Contact: Mike Leach or Mathieu Poirier
Description: (RW) Read or write CTIGATE register.
What: /sys/bus/coresight/devices/<cti-name>/regs/asicctl
Date: March 2020
KernelVersion 5.7
Contact: Mike Leach or Mathieu Poirier
Description: (RW) Read or write ASICCTL register.
What: /sys/bus/coresight/devices/<cti-name>/regs/intack
Date: March 2020
KernelVersion 5.7
Contact: Mike Leach or Mathieu Poirier
Description: (W) Write the INTACK register.
What: /sys/bus/coresight/devices/<cti-name>/regs/appset
Date: March 2020
KernelVersion 5.7
Contact: Mike Leach or Mathieu Poirier
Description: (RW) Set CTIAPPSET register to activate channel. Read back to
determine current value of register.
What: /sys/bus/coresight/devices/<cti-name>/regs/appclear
Date: March 2020
KernelVersion 5.7
Contact: Mike Leach or Mathieu Poirier
Description: (W) Write APPCLEAR register to deactivate channel.
What: /sys/bus/coresight/devices/<cti-name>/regs/apppulse
Date: March 2020
KernelVersion 5.7
Contact: Mike Leach or Mathieu Poirier
Description: (W) Write APPPULSE to pulse a channel active for one clock
cycle.
What: /sys/bus/coresight/devices/<cti-name>/regs/chinstatus
Date: March 2020
KernelVersion 5.7
Contact: Mike Leach or Mathieu Poirier
Description: (R) Read current status of channel inputs.
What: /sys/bus/coresight/devices/<cti-name>/regs/choutstatus
Date: March 2020
KernelVersion 5.7
Contact: Mike Leach or Mathieu Poirier
Description: (R) read current status of channel outputs.
What: /sys/bus/coresight/devices/<cti-name>/regs/triginstatus
Date: March 2020
KernelVersion 5.7
Contact: Mike Leach or Mathieu Poirier
Description: (R) read current status of input trigger signals
What: /sys/bus/coresight/devices/<cti-name>/regs/trigoutstatus
Date: March 2020
KernelVersion 5.7
Contact: Mike Leach or Mathieu Poirier
Description: (R) read current status of output trigger signals.
What: /sys/bus/coresight/devices/<cti-name>/channels/trigin_attach
Date: March 2020
KernelVersion 5.7
Contact: Mike Leach or Mathieu Poirier
Description: (W) Attach a CTI input trigger to a CTM channel.
What: /sys/bus/coresight/devices/<cti-name>/channels/trigin_detach
Date: March 2020
KernelVersion 5.7
Contact: Mike Leach or Mathieu Poirier
Description: (W) Detach a CTI input trigger from a CTM channel.
What: /sys/bus/coresight/devices/<cti-name>/channels/trigout_attach
Date: March 2020
KernelVersion 5.7
Contact: Mike Leach or Mathieu Poirier
Description: (W) Attach a CTI output trigger to a CTM channel.
What: /sys/bus/coresight/devices/<cti-name>/channels/trigout_detach
Date: March 2020
KernelVersion 5.7
Contact: Mike Leach or Mathieu Poirier
Description: (W) Detach a CTI output trigger from a CTM channel.
What: /sys/bus/coresight/devices/<cti-name>/channels/chan_gate_enable
Date: March 2020
KernelVersion 5.7
Contact: Mike Leach or Mathieu Poirier
Description: (RW) Enable CTIGATE for single channel (W) or list enabled
channels through the gate (R).
What: /sys/bus/coresight/devices/<cti-name>/channels/chan_gate_disable
Date: March 2020
KernelVersion 5.7
Contact: Mike Leach or Mathieu Poirier
Description: (W) Disable CTIGATE for single channel.
What: /sys/bus/coresight/devices/<cti-name>/channels/chan_set
Date: March 2020
KernelVersion 5.7
Contact: Mike Leach or Mathieu Poirier
Description: (W) Activate a single channel.
What: /sys/bus/coresight/devices/<cti-name>/channels/chan_clear
Date: March 2020
KernelVersion 5.7
Contact: Mike Leach or Mathieu Poirier
Description: (W) Deactivate a single channel.
What: /sys/bus/coresight/devices/<cti-name>/channels/chan_pulse
Date: March 2020
KernelVersion 5.7
Contact: Mike Leach or Mathieu Poirier
Description: (W) Pulse a single channel - activate for a single clock cycle.
What: /sys/bus/coresight/devices/<cti-name>/channels/trigout_filtered
Date: March 2020
KernelVersion 5.7
Contact: Mike Leach or Mathieu Poirier
Description: (R) List of output triggers filtered across all connections.
What: /sys/bus/coresight/devices/<cti-name>/channels/trig_filter_enable
Date: March 2020
KernelVersion 5.7
Contact: Mike Leach or Mathieu Poirier
Description: (RW) Enable or disable trigger output signal filtering.
What: /sys/bus/coresight/devices/<cti-name>/channels/chan_inuse
Date: March 2020
KernelVersion 5.7
Contact: Mike Leach or Mathieu Poirier
Description: (R) show channels with at least one attached trigger signal.
What: /sys/bus/coresight/devices/<cti-name>/channels/chan_free
Date: March 2020
KernelVersion 5.7
Contact: Mike Leach or Mathieu Poirier
Description: (R) show channels with no attached trigger signals.
What: /sys/bus/coresight/devices/<cti-name>/channels/chan_xtrigs_sel
Date: March 2020
KernelVersion 5.7
Contact: Mike Leach or Mathieu Poirier
Description: (RW) Write channel number to select a channel to view, read to
see selected channel number.
What: /sys/bus/coresight/devices/<cti-name>/channels/chan_xtrigs_in
Date: March 2020
KernelVersion 5.7
Contact: Mike Leach or Mathieu Poirier
Description: (R) Read to see input triggers connected to selected view
channel.
What: /sys/bus/coresight/devices/<cti-name>/channels/chan_xtrigs_out
Date: March 2020
KernelVersion 5.7
Contact: Mike Leach or Mathieu Poirier
Description: (R) Read to see output triggers connected to selected view
channel.
What: /sys/bus/coresight/devices/<cti-name>/channels/chan_xtrigs_reset
Date: March 2020
KernelVersion 5.7
Contact: Mike Leach or Mathieu Poirier
Description: (W) Clear all channel / trigger programming.

8
Documentation/ABI/testing/sysfs-bus-intel_th-devices-msc
View File

@ -40,3 +40,11 @@ Description: (RW) Trigger window switch for the MSC's buffer, in
triggering a window switch for the buffer. Returns an error in any
other operating mode or attempts to write something other than "1".
What: /sys/bus/intel_th/devices/<intel_th_id>-msc<msc-id>/stop_on_full
Date: March 2020
KernelVersion: 5.7
Contact: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Description: (RW) Configure whether trace stops when the last available window
becomes full (1/y/Y) or wraps around and continues until the next
window becomes available again (0/n/N).

16
Documentation/ABI/testing/sysfs-driver-jz4780-efuse Normal file
View File

@ -0,0 +1,16 @@
What: /sys/devices/*/<our-device>/nvmem
Date: December 2017
Contact: PrasannaKumar Muralidharan <prasannatsmkumar@gmail.com>
Description: read-only access to the efuse on the Ingenic JZ4780 SoC
The SoC has a one time programmable 8K efuse that is
split into segments. The driver supports read only.
The segments are
0x000 64 bit Random Number
0x008 128 bit Ingenic Chip ID
0x018 128 bit Customer ID
0x028 3520 bit Reserved
0x1E0 8 bit Protect Segment
0x1E1 2296 bit HDMI Key
0x300 2048 bit Security boot key
Users: any user space application which wants to read the Chip
and Customer ID

21
Documentation/ABI/testing/sysfs-firmware-opal-sensor-groups Normal file
View File

@ -0,0 +1,21 @@
What: /sys/firmware/opal/sensor_groups
Date: August 2017
Contact: Linux for PowerPC mailing list <linuxppc-dev@ozlabs.org>
Description: Sensor groups directory for POWER9 powernv servers
Each folder in this directory contains a sensor group
which are classified based on type of the sensor
like power, temperature, frequency, current, etc. They
can also indicate the group of sensors belonging to
different owners like CSM, Profiler, Job-Scheduler
What: /sys/firmware/opal/sensor_groups/<sensor_group_name>/clear
Date: August 2017
Contact: Linux for PowerPC mailing list <linuxppc-dev@ozlabs.org>
Description: Sysfs file to clear the min-max of all the sensors
belonging to the group.
Writing 1 to this file will clear the minimum and
maximum values of all the sensors in the group.
In POWER9, the min-max of a sensor is the historical minimum
and maximum value of the sensor cached by OCC.

5
Documentation/ABI/testing/sysfs-fs-f2fs
View File

@ -318,3 +318,8 @@ Date: September 2019
Contact: "Hridya Valsaraju" <hridya@google.com>
Description: Average number of valid blocks.
Available when CONFIG_F2FS_STAT_FS=y.
What: /sys/fs/f2fs/<disk>/mounted_time_sec
Date: February 2020
Contact: "Jaegeuk Kim" <jaegeuk@kernel.org>
Description: Show the mounted time in secs of this partition.

40
Documentation/ABI/testing/sysfs-kernel-fadump Normal file
View File

@ -0,0 +1,40 @@
What: /sys/kernel/fadump/*
Date: Dec 2019
Contact: linuxppc-dev@lists.ozlabs.org
Description:
The /sys/kernel/fadump/* is a collection of FADump sysfs
file provide information about the configuration status
of Firmware Assisted Dump (FADump).
What: /sys/kernel/fadump/enabled
Date: Dec 2019
Contact: linuxppc-dev@lists.ozlabs.org
Description: read only
Primarily used to identify whether the FADump is enabled in
the kernel or not.
User: Kdump service
What: /sys/kernel/fadump/registered
Date: Dec 2019
Contact: linuxppc-dev@lists.ozlabs.org
Description: read/write
Helps to control the dump collect feature from userspace.
Setting 1 to this file enables the system to collect the
dump and 0 to disable it.
User: Kdump service
What: /sys/kernel/fadump/release_mem
Date: Dec 2019
Contact: linuxppc-dev@lists.ozlabs.org
Description: write only
This is a special sysfs file and only available when
the system is booted to capture the vmcore using FADump.
It is used to release the memory reserved by FADump to
save the crash dump.
What: /sys/kernel/fadump/mem_reserved
Date: Dec 2019
Contact: linuxppc-dev@lists.ozlabs.org
Description: read only
Provide information about the amount of memory reserved by
FADump to save the crash dump in bytes.

8
Documentation/ABI/testing/sysfs-platform-dell-laptop
View File

@ -2,7 +2,7 @@ What: /sys/class/leds/dell::kbd_backlight/als_enabled
Date: December 2014
KernelVersion: 3.19
Contact: Gabriele Mazzotta <gabriele.mzt@gmail.com>,
Pali Rohár <pali.rohar@gmail.com>
Pali Rohár <pali@kernel.org>
Description:
This file allows to control the automatic keyboard
illumination mode on some systems that have an ambient
@ -13,7 +13,7 @@ What: /sys/class/leds/dell::kbd_backlight/als_setting
Date: December 2014
KernelVersion: 3.19
Contact: Gabriele Mazzotta <gabriele.mzt@gmail.com>,
Pali Rohár <pali.rohar@gmail.com>
Pali Rohár <pali@kernel.org>
Description:
This file allows to specifiy the on/off threshold value,
as reported by the ambient light sensor.
@ -22,7 +22,7 @@ What: /sys/class/leds/dell::kbd_backlight/start_triggers
Date: December 2014
KernelVersion: 3.19
Contact: Gabriele Mazzotta <gabriele.mzt@gmail.com>,
Pali Rohár <pali.rohar@gmail.com>
Pali Rohár <pali@kernel.org>
Description:
This file allows to control the input triggers that
turn on the keyboard backlight illumination that is
@ -45,7 +45,7 @@ What: /sys/class/leds/dell::kbd_backlight/stop_timeout
Date: December 2014
KernelVersion: 3.19
Contact: Gabriele Mazzotta <gabriele.mzt@gmail.com>,
Pali Rohár <pali.rohar@gmail.com>
Pali Rohár <pali@kernel.org>
Description:
This file allows to specify the interval after which the
keyboard illumination is disabled because of inactivity.

155
Documentation/PCI/boot-interrupts.rst Normal file
View File

@ -0,0 +1,155 @@
.. SPDX-License-Identifier: GPL-2.0
===============
Boot Interrupts
===============
:Author: - Sean V Kelley <sean.v.kelley@linux.intel.com>
Overview
========
On PCI Express, interrupts are represented with either MSI or inbound
interrupt messages (Assert_INTx/Deassert_INTx). The integrated IO-APIC in a
given Core IO converts the legacy interrupt messages from PCI Express to
MSI interrupts. If the IO-APIC is disabled (via the mask bits in the
IO-APIC table entries), the messages are routed to the legacy PCH. This
in-band interrupt mechanism was traditionally necessary for systems that
did not support the IO-APIC and for boot. Intel in the past has used the
term "boot interrupts" to describe this mechanism. Further, the PCI Express
protocol describes this in-band legacy wire-interrupt INTx mechanism for
I/O devices to signal PCI-style level interrupts. The subsequent paragraphs
describe problems with the Core IO handling of INTx message routing to the
PCH and mitigation within BIOS and the OS.
Issue
=====
When in-band legacy INTx messages are forwarded to the PCH, they in turn
trigger a new interrupt for which the OS likely lacks a handler. When an
interrupt goes unhandled over time, they are tracked by the Linux kernel as
Spurious Interrupts. The IRQ will be disabled by the Linux kernel after it
reaches a specific count with the error "nobody cared". This disabled IRQ
now prevents valid usage by an existing interrupt which may happen to share
the IRQ line.
irq 19: nobody cared (try booting with the "irqpoll" option)
CPU: 0 PID: 2988 Comm: irq/34-nipalk Tainted: 4.14.87-rt49-02410-g4a640ec-dirty #1
Hardware name: National Instruments NI PXIe-8880/NI PXIe-8880, BIOS 2.1.5f1 01/09/2020
Call Trace:
<IRQ>
? dump_stack+0x46/0x5e
? __report_bad_irq+0x2e/0xb0
? note_interrupt+0x242/0x290
? nNIKAL100_memoryRead16+0x8/0x10 [nikal]
? handle_irq_event_percpu+0x55/0x70
? handle_irq_event+0x4f/0x80
? handle_fasteoi_irq+0x81/0x180
? handle_irq+0x1c/0x30
? do_IRQ+0x41/0xd0
? common_interrupt+0x84/0x84
</IRQ>
handlers:
irq_default_primary_handler threaded usb_hcd_irq
Disabling IRQ #19
Conditions
==========
The use of threaded interrupts is the most likely condition to trigger
this problem today. Threaded interrupts may not be reenabled after the IRQ
handler wakes. These "one shot" conditions mean that the threaded interrupt
needs to keep the interrupt line masked until the threaded handler has run.
Especially when dealing with high data rate interrupts, the thread needs to
run to completion; otherwise some handlers will end up in stack overflows
since the interrupt of the issuing device is still active.
Affected Chipsets
=================
The legacy interrupt forwarding mechanism exists today in a number of
devices including but not limited to chipsets from AMD/ATI, Broadcom, and
Intel. Changes made through the mitigations below have been applied to
drivers/pci/quirks.c
Starting with ICX there are no longer any IO-APICs in the Core IO's
devices. IO-APIC is only in the PCH. Devices connected to the Core IO's
PCIe Root Ports will use native MSI/MSI-X mechanisms.
Mitigations
===========
The mitigations take the form of PCI quirks. The preference has been to
first identify and make use of a means to disable the routing to the PCH.
In such a case a quirk to disable boot interrupt generation can be
added.[1]
Intel® 6300ESB I/O Controller Hub
Alternate Base Address Register:
BIE: Boot Interrupt Enable
0 = Boot interrupt is enabled.
1 = Boot interrupt is disabled.
Intel® Sandy Bridge through Sky Lake based Xeon servers:
Coherent Interface Protocol Interrupt Control
dis_intx_route2pch/dis_intx_route2ich/dis_intx_route2dmi2:
When this bit is set. Local INTx messages received from the
Intel® Quick Data DMA/PCI Express ports are not routed to legacy
PCH - they are either converted into MSI via the integrated IO-APIC
(if the IO-APIC mask bit is clear in the appropriate entries)
or cause no further action (when mask bit is set)
In the absence of a way to directly disable the routing, another approach
has been to make use of PCI Interrupt pin to INTx routing tables for
purposes of redirecting the interrupt handler to the rerouted interrupt
line by default. Therefore, on chipsets where this INTx routing cannot be
disabled, the Linux kernel will reroute the valid interrupt to its legacy
interrupt. This redirection of the handler will prevent the occurrence of
the spurious interrupt detection which would ordinarily disable the IRQ
line due to excessive unhandled counts.[2]
The config option X86_REROUTE_FOR_BROKEN_BOOT_IRQS exists to enable (or
disable) the redirection of the interrupt handler to the PCH interrupt
line. The option can be overridden by either pci=ioapicreroute or
pci=noioapicreroute.[3]
More Documentation
==================
There is an overview of the legacy interrupt handling in several datasheets
(6300ESB and 6700PXH below). While largely the same, it provides insight
into the evolution of its handling with chipsets.
Example of disabling of the boot interrupt
------------------------------------------
Intel® 6300ESB I/O Controller Hub (Document # 300641-004US)
5.7.3 Boot Interrupt
https://www.intel.com/content/dam/doc/datasheet/6300esb-io-controller-hub-datasheet.pdf
Intel® Xeon® Processor E5-1600/2400/2600/4600 v3 Product Families
Datasheet - Volume 2: Registers (Document # 330784-003)
6.6.41 cipintrc Coherent Interface Protocol Interrupt Control
https://www.intel.com/content/dam/www/public/us/en/documents/datasheets/xeon-e5-v3-datasheet-vol-2.pdf
Example of handler rerouting
----------------------------
Intel® 6700PXH 64-bit PCI Hub (Document # 302628)
2.15.2 PCI Express Legacy INTx Support and Boot Interrupt
https://www.intel.com/content/dam/doc/datasheet/6700pxh-64-bit-pci-hub-datasheet.pdf
If you have any legacy PCI interrupt questions that aren't answered, email me.
Cheers,
Sean V Kelley
sean.v.kelley@linux.intel.com
[1] https://lore.kernel.org/r/12131949181903-git-send-email-sassmann@suse.de/
[2] https://lore.kernel.org/r/12131949182094-git-send-email-sassmann@suse.de/
[3] https://lore.kernel.org/r/487C8EA7.6020205@suse.de/

1
Documentation/PCI/index.rst
View File

@ -16,3 +16,4 @@ Linux PCI Bus Subsystem
pci-error-recovery
pcieaer-howto
endpoint/index
boot-interrupts

23
Documentation/PCI/pcieaer-howto.rst
View File

@ -156,12 +156,6 @@ default reset_link function, but different upstream ports might
have different specifications to reset pci express link, so all
upstream ports should provide their own reset_link functions.
In struct pcie_port_service_driver, a new pointer, reset_link, is
added.
::
pci_ers_result_t (*reset_link) (struct pci_dev *dev);
Section 3.2.2.2 provides more detailed info on when to call
reset_link.
@ -212,15 +206,10 @@ error_detected(dev, pci_channel_io_frozen) to all drivers within
a hierarchy in question. Then, performing link reset at upstream is
necessary. As different kinds of devices might use different approaches
to reset link, AER port service driver is required to provide the
function to reset link. Firstly, kernel looks for if the upstream
component has an aer driver. If it has, kernel uses the reset_link
callback of the aer driver. If the upstream component has no aer driver
and the port is downstream port, we will perform a hot reset as the
default by setting the Secondary Bus Reset bit of the Bridge Control
register associated with the downstream port. As for upstream ports,
they should provide their own aer service drivers with reset_link
function. If error_detected returns PCI_ERS_RESULT_CAN_RECOVER and
reset_link returns PCI_ERS_RESULT_RECOVERED, the error handling goes
function to reset link via callback parameter of pcie_do_recovery()
function. If reset_link is not NULL, recovery function will use it
to reset the link. If error_detected returns PCI_ERS_RESULT_CAN_RECOVER
and reset_link returns PCI_ERS_RESULT_RECOVERED, the error handling goes
to mmio_enabled.
helper functions
@ -243,9 +232,9 @@ messages to root port when an error is detected.
::
int pci_cleanup_aer_uncorrect_error_status(struct pci_dev *dev);`
int pci_aer_clear_nonfatal_status(struct pci_dev *dev);`
pci_cleanup_aer_uncorrect_error_status cleanups the uncorrectable
pci_aer_clear_nonfatal_status clears non-fatal errors in the uncorrectable
error status register.
Frequent Asked Questions

6
Documentation/admin-guide/binderfs.rst
View File

@ -33,6 +33,12 @@ max
a per-instance limit. If ``max=<count>`` is set then only ``<count>`` number
of binder devices can be allocated in this binderfs instance.
stats
Using ``stats=global`` enables global binder statistics.
``stats=global`` is only available for a binderfs instance mounted in the
initial user namespace. An attempt to use the option to mount a binderfs
instance in another user namespace will return a permission error.
Allocating binder Devices
-------------------------

11
Documentation/admin-guide/cgroup-v1/cpusets.rst
View File

@ -223,6 +223,17 @@ cpu_online_mask using a CPU hotplug notifier, and the mems file
automatically tracks the value of node_states[N_MEMORY]--i.e.,
nodes with memory--using the cpuset_track_online_nodes() hook.
The cpuset.effective_cpus and cpuset.effective_mems files are
normally read-only copies of cpuset.cpus and cpuset.mems files
respectively. If the cpuset cgroup filesystem is mounted with the
special "cpuset_v2_mode" option, the behavior of these files will become
similar to the corresponding files in cpuset v2. In other words, hotplug
events will not change cpuset.cpus and cpuset.mems. Those events will
only affect cpuset.effective_cpus and cpuset.effective_mems which show
the actual cpus and memory nodes that are currently used by this cpuset.
See Documentation/admin-guide/cgroup-v2.rst for more information about
cpuset v2 behavior.
1.4 What are exclusive cpusets ?
--------------------------------

3
Documentation/admin-guide/dynamic-debug-howto.rst
View File

@ -54,6 +54,9 @@ If you make a mistake with the syntax, the write will fail thus::
<debugfs>/dynamic_debug/control
-bash: echo: write error: Invalid argument
Note, for systems without 'debugfs' enabled, the control file can be
found in ``/proc/dynamic_debug/control``.
Viewing Dynamic Debug Behaviour
===============================

40
Documentation/admin-guide/kernel-parameters.txt
View File

@ -22,11 +22,13 @@
default: 0
acpi_backlight= [HW,ACPI]
acpi_backlight=vendor
acpi_backlight=video
If set to vendor, prefer vendor specific driver
{ vendor | video | native | none }
If set to vendor, prefer vendor-specific driver
(e.g. thinkpad_acpi, sony_acpi, etc.) instead
of the ACPI video.ko driver.
If set to video, use the ACPI video.ko driver.
If set to native, use the device's native backlight mode.
If set to none, disable the ACPI backlight interface.
acpi_force_32bit_fadt_addr
force FADT to use 32 bit addresses rather than the
@ -683,7 +685,7 @@
coredump_filter=
[KNL] Change the default value for
/proc/<pid>/coredump_filter.
See also Documentation/filesystems/proc.txt.
See also Documentation/filesystems/proc.rst.
coresight_cpu_debug.enable
[ARM,ARM64]
@ -960,7 +962,7 @@
edid/1680x1050.bin, or edid/1920x1080.bin is given
and no file with the same name exists. Details and
instructions how to build your own EDID data are
available in Documentation/driver-api/edid.rst. An EDID
available in Documentation/admin-guide/edid.rst. An EDID
data set will only be used for a particular connector,
if its name and a colon are prepended to the EDID
name. Each connector may use a unique EDID data
@ -990,10 +992,6 @@
Documentation/admin-guide/dynamic-debug-howto.rst
for details.
nompx [X86] Disables Intel Memory Protection Extensions.
See Documentation/x86/intel_mpx.rst for more
information about the feature.
nopku [X86] Disable Memory Protection Keys CPU feature found
in some Intel CPUs.
@ -1473,6 +1471,14 @@
hpet_mmap= [X86, HPET_MMAP] Allow userspace to mmap HPET
registers. Default set by CONFIG_HPET_MMAP_DEFAULT.
hugetlb_cma= [HW] The size of a cma area used for allocation
of gigantic hugepages.
Format: nn[KMGTPE]
Reserve a cma area of given size and allocate gigantic
hugepages using the cma allocator. If enabled, the
boot-time allocation of gigantic hugepages is skipped.
hugepages= [HW,X86-32,IA-64] HugeTLB pages to allocate at boot.
hugepagesz= [HW,IA-64,PPC,X86-64] The size of the HugeTLB pages.
On x86-64 and powerpc, this option can be specified
@ -2571,13 +2577,22 @@
For details see: Documentation/admin-guide/hw-vuln/mds.rst
mem=nn[KMG] [KNL,BOOT] Force usage of a specific amount of memory
Amount of memory to be used when the kernel is not able
to see the whole system memory or for test.
Amount of memory to be used in cases as follows:
1 for test;
2 when the kernel is not able to see the whole system memory;
3 memory that lies after 'mem=' boundary is excluded from
the hypervisor, then assigned to KVM guests.
[X86] Work as limiting max address. Use together
with memmap= to avoid physical address space collisions.
Without memmap= PCI devices could be placed at addresses
belonging to unused RAM.
Note that this only takes effects during boot time since
in above case 3, memory may need be hot added after boot
if system memory of hypervisor is not sufficient.
mem=nopentium [BUGS=X86-32] Disable usage of 4MB pages for kernel
memory.
@ -3720,6 +3735,9 @@
Override pmtimer IOPort with a hex value.
e.g. pmtmr=0x508
pm_debug_messages [SUSPEND,KNL]
Enable suspend/resume debug messages during boot up.
pnp.debug=1 [PNP]
Enable PNP debug messages (depends on the
CONFIG_PNP_DEBUG_MESSAGES option). Change at run-time

14
Documentation/admin-guide/mm/transhuge.rst
View File

@ -310,6 +310,11 @@ thp_fault_fallback
is incremented if a page fault fails to allocate
a huge page and instead falls back to using small pages.
thp_fault_fallback_charge
is incremented if a page fault fails to charge a huge page and
instead falls back to using small pages even though the
allocation was successful.
thp_collapse_alloc_failed
is incremented if khugepaged found a range
of pages that should be collapsed into one huge page but failed
@ -319,6 +324,15 @@ thp_file_alloc
is incremented every time a file huge page is successfully
allocated.
thp_file_fallback
is incremented if a file huge page is attempted to be allocated
but fails and instead falls back to using small pages.
thp_file_fallback_charge
is incremented if a file huge page cannot be charged and instead
falls back to using small pages even though the allocation was
successful.
thp_file_mapped
is incremented every time a file huge page is mapped into
user address space.

51
Documentation/admin-guide/mm/userfaultfd.rst
View File

@ -108,6 +108,57 @@ UFFDIO_COPY. They're atomic as in guaranteeing that nothing can see an
half copied page since it'll keep userfaulting until the copy has
finished.
Notes:
- If you requested UFFDIO_REGISTER_MODE_MISSING when registering then
you must provide some kind of page in your thread after reading from
the uffd. You must provide either UFFDIO_COPY or UFFDIO_ZEROPAGE.
The normal behavior of the OS automatically providing a zero page on
an annonymous mmaping is not in place.
- None of the page-delivering ioctls default to the range that you
registered with. You must fill in all fields for the appropriate
ioctl struct including the range.
- You get the address of the access that triggered the missing page
event out of a struct uffd_msg that you read in the thread from the
uffd. You can supply as many pages as you want with UFFDIO_COPY or
UFFDIO_ZEROPAGE. Keep in mind that unless you used DONTWAKE then
the first of any of those IOCTLs wakes up the faulting thread.
- Be sure to test for all errors including (pollfd[0].revents &
POLLERR). This can happen, e.g. when ranges supplied were
incorrect.
Write Protect Notifications
---------------------------
This is equivalent to (but faster than) using mprotect and a SIGSEGV
signal handler.
Firstly you need to register a range with UFFDIO_REGISTER_MODE_WP.
Instead of using mprotect(2) you use ioctl(uffd, UFFDIO_WRITEPROTECT,
struct *uffdio_writeprotect) while mode = UFFDIO_WRITEPROTECT_MODE_WP
in the struct passed in. The range does not default to and does not
have to be identical to the range you registered with. You can write
protect as many ranges as you like (inside the registered range).
Then, in the thread reading from uffd the struct will have
msg.arg.pagefault.flags & UFFD_PAGEFAULT_FLAG_WP set. Now you send
ioctl(uffd, UFFDIO_WRITEPROTECT, struct *uffdio_writeprotect) again
while pagefault.mode does not have UFFDIO_WRITEPROTECT_MODE_WP set.
This wakes up the thread which will continue to run with writes. This
allows you to do the bookkeeping about the write in the uffd reading
thread before the ioctl.
If you registered with both UFFDIO_REGISTER_MODE_MISSING and
UFFDIO_REGISTER_MODE_WP then you need to think about the sequence in
which you supply a page and undo write protect. Note that there is a
difference between writes into a WP area and into a !WP area. The
former will have UFFD_PAGEFAULT_FLAG_WP set, the latter
UFFD_PAGEFAULT_FLAG_WRITE. The latter did not fail on protection but
you still need to supply a page when UFFDIO_REGISTER_MODE_MISSING was
used.
QEMU/KVM
========

270
Documentation/admin-guide/pm/suspend-flows.rst Normal file
View File

@ -0,0 +1,270 @@
.. SPDX-License-Identifier: GPL-2.0
.. include:: <isonum.txt>
=========================
System Suspend Code Flows
=========================
:Copyright: |copy| 2020 Intel Corporation
:Author: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
At least one global system-wide transition needs to be carried out for the
system to get from the working state into one of the supported
:doc:`sleep states <sleep-states>`. Hibernation requires more than one
transition to occur for this purpose, but the other sleep states, commonly
referred to as *system-wide suspend* (or simply *system suspend*) states, need
only one.
For those sleep states, the transition from the working state of the system into
the target sleep state is referred to as *system suspend* too (in the majority
of cases, whether this means a transition or a sleep state of the system should
be clear from the context) and the transition back from the sleep state into the
working state is referred to as *system resume*.
The kernel code flows associated with the suspend and resume transitions for
different sleep states of the system are quite similar, but there are some
significant differences between the :ref:`suspend-to-idle <s2idle>` code flows
and the code flows related to the :ref:`suspend-to-RAM <s2ram>` and
:ref:`standby <standby>` sleep states.
The :ref:`suspend-to-RAM <s2ram>` and :ref:`standby <standby>` sleep states
cannot be implemented without platform support and the difference between them
boils down to the platform-specific actions carried out by the suspend and
resume hooks that need to be provided by the platform driver to make them
available. Apart from that, the suspend and resume code flows for these sleep
states are mostly identical, so they both together will be referred to as
*platform-dependent suspend* states in what follows.
.. _s2idle_suspend:
Suspend-to-idle Suspend Code Flow
=================================
The following steps are taken in order to transition the system from the working
state to the :ref:`suspend-to-idle <s2idle>` sleep state:
1. Invoking system-wide suspend notifiers.
Kernel subsystems can register callbacks to be invoked when the suspend
transition is about to occur and when the resume transition has finished.
That allows them to prepare for the change of the system state and to clean
up after getting back to the working state.
2. Freezing tasks.
Tasks are frozen primarily in order to avoid unchecked hardware accesses
from user space through MMIO regions or I/O registers exposed directly to
it and to prevent user space from entering the kernel while the next step
of the transition is in progress (which might have been problematic for
various reasons).
All user space tasks are intercepted as though they were sent a signal and
put into uninterruptible sleep until the end of the subsequent system resume
transition.
The kernel threads that choose to be frozen during system suspend for
specific reasons are frozen subsequently, but they are not intercepted.
Instead, they are expected to periodically check whether or not they need
to be frozen and to put themselves into uninterruptible sleep if so. [Note,
however, that kernel threads can use locking and other concurrency controls
available in kernel space to synchronize themselves with system suspend and
resume, which can be much more precise than the freezing, so the latter is
not a recommended option for kernel threads.]
3. Suspending devices and reconfiguring IRQs.
Devices are suspended in four phases called *prepare*, *suspend*,
*late suspend* and *noirq suspend* (see :ref:`driverapi_pm_devices` for more
information on what exactly happens in each phase).
Every device is visited in each phase, but typically it is not physically
accessed in more than two of them.
The runtime PM API is disabled for every device during the *late* suspend
phase and high-level ("action") interrupt handlers are prevented from being
invoked before the *noirq* suspend phase.
Interrupts are still handled after that, but they are only acknowledged to
interrupt controllers without performing any device-specific actions that
would be triggered in the working state of the system (those actions are
deferred till the subsequent system resume transition as described
`below <s2idle_resume_>`_).
IRQs associated with system wakeup devices are "armed" so that the resume
transition of the system is started when one of them signals an event.
4. Freezing the scheduler tick and suspending timekeeping.
When all devices have been suspended, CPUs enter the idle loop and are put
into the deepest available idle state. While doing that, each of them
"freezes" its own scheduler tick so that the timer events associated with
the tick do not occur until the CPU is woken up by another interrupt source.
The last CPU to enter the idle state also stops the timekeeping which
(among other things) prevents high resolution timers from triggering going
forward until the first CPU that is woken up restarts the timekeeping.
That allows the CPUs to stay in the deep idle state relatively long in one
go.
From this point on, the CPUs can only be woken up by non-timer hardware
interrupts. If that happens, they go back to the idle state unless the
interrupt that woke up one of them comes from an IRQ that has been armed for
system wakeup, in which case the system resume transition is started.
.. _s2idle_resume:
Suspend-to-idle Resume Code Flow
================================
The following steps are taken in order to transition the system from the
:ref:`suspend-to-idle <s2idle>` sleep state into the working state:
1. Resuming timekeeping and unfreezing the scheduler tick.
When one of the CPUs is woken up (by a non-timer hardware interrupt), it
leaves the idle state entered in the last step of the preceding suspend
transition, restarts the timekeeping (unless it has been restarted already
by another CPU that woke up earlier) and the scheduler tick on that CPU is
unfrozen.
If the interrupt that has woken up the CPU was armed for system wakeup,
the system resume transition begins.
2. Resuming devices and restoring the working-state configuration of IRQs.
Devices are resumed in four phases called *noirq resume*, *early resume*,
*resume* and *complete* (see :ref:`driverapi_pm_devices` for more
information on what exactly happens in each phase).
Every device is visited in each phase, but typically it is not physically
accessed in more than two of them.
The working-state configuration of IRQs is restored after the *noirq* resume
phase and the runtime PM API is re-enabled for every device whose driver
supports it during the *early* resume phase.
3. Thawing tasks.
Tasks frozen in step 2 of the preceding `suspend <s2idle_suspend_>`_
transition are "thawed", which means that they are woken up from the
uninterruptible sleep that they went into at that time and user space tasks
are allowed to exit the kernel.
4. Invoking system-wide resume notifiers.
This is analogous to step 1 of the `suspend <s2idle_suspend_>`_ transition
and the same set of callbacks is invoked at this point, but a different
"notification type" parameter value is passed to them.
Platform-dependent Suspend Code Flow
====================================
The following steps are taken in order to transition the system from the working
state to platform-dependent suspend state:
1. Invoking system-wide suspend notifiers.
This step is the same as step 1 of the suspend-to-idle suspend transition
described `above <s2idle_suspend_>`_.
2. Freezing tasks.
This step is the same as step 2 of the suspend-to-idle suspend transition
described `above <s2idle_suspend_>`_.
3. Suspending devices and reconfiguring IRQs.
This step is analogous to step 3 of the suspend-to-idle suspend transition
described `above <s2idle_suspend_>`_, but the arming of IRQs for system
wakeup generally does not have any effect on the platform.
There are platforms that can go into a very deep low-power state internally
when all CPUs in them are in sufficiently deep idle states and all I/O
devices have been put into low-power states. On those platforms,
suspend-to-idle can reduce system power very effectively.
On the other platforms, however, low-level components (like interrupt
controllers) need to be turned off in a platform-specific way (implemented
in the hooks provided by the platform driver) to achieve comparable power
reduction.
That usually prevents in-band hardware interrupts from waking up the system,
which must be done in a special platform-dependent way. Then, the
configuration of system wakeup sources usually starts when system wakeup
devices are suspended and is finalized by the platform suspend hooks later
on.
4. Disabling non-boot CPUs.
On some platforms the suspend hooks mentioned above must run in a one-CPU
configuration of the system (in particular, the hardware cannot be accessed
by any code running in parallel with the platform suspend hooks that may,
and often do, trap into the platform firmware in order to finalize the
suspend transition).
For this reason, the CPU offline/online (CPU hotplug) framework is used
to take all of the CPUs in the system, except for one (the boot CPU),
offline (typically, the CPUs that have been taken offline go into deep idle
states).
This means that all tasks are migrated away from those CPUs and all IRQs are
rerouted to the only CPU that remains online.
5. Suspending core system components.
This prepares the core system components for (possibly) losing power going
forward and suspends the timekeeping.
6. Platform-specific power removal.
This is expected to remove power from all of the system components except
for the memory controller and RAM (in order to preserve the contents of the
latter) and some devices designated for system wakeup.
In many cases control is passed to the platform firmware which is expected
to finalize the suspend transition as needed.
Platform-dependent Resume Code Flow
===================================
The following steps are taken in order to transition the system from a
platform-dependent suspend state into the working state:
1. Platform-specific system wakeup.
The platform is woken up by a signal from one of the designated system
wakeup devices (which need not be an in-band hardware interrupt) and
control is passed back to the kernel (the working configuration of the
platform may need to be restored by the platform firmware before the
kernel gets control again).
2. Resuming core system components.
The suspend-time configuration of the core system components is restored and
the timekeeping is resumed.
3. Re-enabling non-boot CPUs.
The CPUs disabled in step 4 of the preceding suspend transition are taken
back online and their suspend-time configuration is restored.
4. Resuming devices and restoring the working-state configuration of IRQs.
This step is the same as step 2 of the suspend-to-idle suspend transition
described `above <s2idle_resume_>`_.
5. Thawing tasks.
This step is the same as step 3 of the suspend-to-idle suspend transition
described `above <s2idle_resume_>`_.
6. Invoking system-wide resume notifiers.
This step is the same as step 4 of the suspend-to-idle suspend transition
described `above <s2idle_resume_>`_.

1
Documentation/admin-guide/pm/system-wide.rst
View File

@ -8,3 +8,4 @@ System-Wide Power Management
:maxdepth: 2
sleep-states
suspend-flows

26
Documentation/admin-guide/sysctl/kernel.rst
View File

@ -390,9 +390,17 @@ When ``kptr_restrict`` is set to 2, kernel pointers printed using
modprobe
========
This gives the full path of the modprobe command which the kernel will
use to load modules. This can be used to debug module loading
requests::
The full path to the usermode helper for autoloading kernel modules,
by default "/sbin/modprobe". This binary is executed when the kernel
requests a module. For example, if userspace passes an unknown
filesystem type to mount(), then the kernel will automatically request
the corresponding filesystem module by executing this usermode helper.
This usermode helper should insert the needed module into the kernel.
This sysctl only affects module autoloading. It has no effect on the
ability to explicitly insert modules.
This sysctl can be used to debug module loading requests::
echo '#! /bin/sh' > /tmp/modprobe
echo 'echo "$@" >> /tmp/modprobe.log' >> /tmp/modprobe
@ -400,10 +408,15 @@ requests::
chmod a+x /tmp/modprobe
echo /tmp/modprobe > /proc/sys/kernel/modprobe
This only applies when the *kernel* is requesting that the module be
loaded; it won't have any effect if the module is being loaded
explicitly using ``modprobe`` from userspace.
Alternatively, if this sysctl is set to the empty string, then module
autoloading is completely disabled. The kernel will not try to
execute a usermode helper at all, nor will it call the
kernel_module_request LSM hook.
If CONFIG_STATIC_USERMODEHELPER=y is set in the kernel configuration,
then the configured static usermode helper overrides this sysctl,
except that the empty string is still accepted to completely disable
module autoloading as described above.
modules_disabled
================
@ -446,7 +459,6 @@ Notes:
successful IPC object allocation. If an IPC object allocation syscall
fails, it is undefined if the value remains unmodified or is reset to -1.
nmi_watchdog
============

6
Documentation/admin-guide/sysctl/user.rst
View File

@ -65,6 +65,12 @@ max_pid_namespaces
The maximum number of pid namespaces that any user in the current
user namespace may create.
max_time_namespaces
===================
The maximum number of time namespaces that any user in the current
user namespace may create.
max_user_namespaces
===================

20
Documentation/admin-guide/sysrq.rst
View File

@ -48,9 +48,10 @@ always allowed (by a user with admin privileges).
How do I use the magic SysRq key?
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
On x86 - You press the key combo :kbd:`ALT-SysRq-<command key>`.
On x86
You press the key combo :kbd:`ALT-SysRq-<command key>`.
.. note::
.. note::
Some
keyboards may not have a key labeled 'SysRq'. The 'SysRq' key is
also known as the 'Print Screen' key. Also some keyboards cannot
@ -58,14 +59,15 @@ On x86 - You press the key combo :kbd:`ALT-SysRq-<command key>`.
have better luck with press :kbd:`Alt`, press :kbd:`SysRq`,
release :kbd:`SysRq`, press :kbd:`<command key>`, release everything.
On SPARC - You press :kbd:`ALT-STOP-<command key>`, I believe.
On SPARC
You press :kbd:`ALT-STOP-<command key>`, I believe.
On the serial console (PC style standard serial ports only)
You send a ``BREAK``, then within 5 seconds a command key. Sending
``BREAK`` twice is interpreted as a normal BREAK.
On PowerPC
Press :kbd:`ALT - Print Screen` (or :kbd:`F13`) - :kbd:`<command key>`,
Press :kbd:`ALT - Print Screen` (or :kbd:`F13`) - :kbd:`<command key>`.
:kbd:`Print Screen` (or :kbd:`F13`) - :kbd:`<command key>` may suffice.
On other
@ -73,7 +75,7 @@ On other
let me know so I can add them to this section.
On all
write a character to /proc/sysrq-trigger. e.g.::
Write a character to /proc/sysrq-trigger. e.g.::
echo t > /proc/sysrq-trigger
@ -282,7 +284,7 @@ Just ask them on the linux-kernel mailing list:
Credits
~~~~~~~
Written by Mydraal <vulpyne@vulpyne.net>
Updated by Adam Sulmicki <adam@cfar.umd.edu>
Updated by Jeremy M. Dolan <jmd@turbogeek.org> 2001/01/28 10:15:59
Added to by Crutcher Dunnavant <crutcher+kernel@datastacks.com>
- Written by Mydraal <vulpyne@vulpyne.net>
- Updated by Adam Sulmicki <adam@cfar.umd.edu>
- Updated by Jeremy M. Dolan <jmd@turbogeek.org> 2001/01/28 10:15:59
- Added to by Crutcher Dunnavant <crutcher+kernel@datastacks.com>

6
Documentation/core-api/timekeeping.rst
View File

@ -154,9 +154,9 @@ architectures. These are the recommended replacements:
Use ktime_get() or ktime_get_ts64() instead.
.. c:function:: struct timeval do_gettimeofday( void )
struct timespec getnstimeofday( void )
struct timespec64 getnstimeofday64( void )
.. c:function:: void do_gettimeofday( struct timeval * )
void getnstimeofday( struct timespec * )
void getnstimeofday64( struct timespec64 * )
void ktime_get_real_ts( struct timespec * )
ktime_get_real_ts64() is a direct replacement, but consider using

1
Documentation/devicetree/bindings/.gitignore vendored
View File

@ -1,2 +1,3 @@
# SPDX-License-Identifier: GPL-2.0-only
*.example.dts
processed-schema*.yaml

2
Documentation/devicetree/bindings/arm/altera/socfpga-clk-manager.yaml
View File

@ -21,6 +21,8 @@ properties:
required:
- compatible
additionalProperties: false
examples:
- |
clkmgr@ffd04000 {

2
Documentation/devicetree/bindings/arm/amlogic/amlogic,meson-gx-ao-secure.yaml
View File

@ -43,6 +43,8 @@ required:
- compatible
- reg
additionalProperties: false
examples:
- |
ao-secure@140 {

86
Documentation/devicetree/bindings/arm/arm,integrator.yaml Normal file
View File

@ -0,0 +1,86 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/arm/arm,integrator.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: ARM Integrator Boards Device Tree Bindings
maintainers:
- Linus Walleij <linus.walleij@linaro.org>
description: |+
These were the first ARM platforms officially supported by ARM Ltd.
They are ARMv4, ARMv5 and ARMv6-capable using different core tiles,
so the system is modular and can host a variety of CPU tiles called
"core tiles" and referred to in the device tree as "core modules".
properties:
$nodename:
const: '/'
compatible:
oneOf:
- description: ARM Integrator Application Platform, this board has a PCI
host and several PCI slots, as well as a number of slots for logical
expansion modules, it is referred to as an "ASIC Development
Motherboard" and is extended with custom FPGA and is intended for
rapid prototyping. See ARM DUI 0098B. This board can physically come
pre-packaged in a PC Tower form factor called Integrator/PP1 or a
special metal fixture called Integrator/PP2, see ARM DUI 0169A.
items:
- const: arm,integrator-ap
- description: ARM Integrator Compact Platform (HBI-0086), this board has
a compact form factor and mainly consists of the bare minimum
peripherals to make use of the core module. See ARM DUI 0159B.
items:
- const: arm,integrator-cp
- description: ARM Integrator Standard Development Board (SDB) Platform,
this board is a PCI-based board conforming to the Microsoft SDB
(HARP) specification. See ARM DUI 0099A.
items:
- const: arm,integrator-sp
core-module@10000000:
type: object
description: the root node in the Integrator platforms must contain
a core module child node. They are always at physical address
0x10000000 in all the Integrator variants.
properties:
compatible:
items:
- const: arm,core-module-integrator
- const: syscon
- const: simple-mfd
reg:
maxItems: 1
required:
- compatible
- reg
patternProperties:
"^syscon@[0-9a-f]+$":
description: All Integrator boards must provide a system controller as a
node in the root of the device tree.
type: object
properties:
compatible:
items:
- enum:
- arm,integrator-ap-syscon
- arm,integrator-cp-syscon
- arm,integrator-sp-syscon
- const: syscon
reg:
maxItems: 1
required:
- compatible
- reg
required:
- compatible
- core-module@10000000
...

123
Documentation/devicetree/bindings/arm/arm,realview.yaml Normal file
View File

@ -0,0 +1,123 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/arm/arm,realview.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: ARM RealView Boards Device Tree Bindings
maintainers:
- Linus Walleij <linus.walleij@linaro.org>
description: |+
The ARM RealView series of reference designs were built to explore the ARM
11, Cortex A-8 and Cortex A-9 CPUs. This included new features compared to
the earlier CPUs such as TrustZone and multicore (MPCore).
properties:
$nodename:
const: '/'
compatible:
oneOf:
- description: ARM RealView Emulation Baseboard (HBI-0140) was created
as a generic platform to test different FPGA designs, and has
pluggable CPU modules, see ARM DUI 0303E.
items:
- const: arm,realview-eb
- description: ARM RealView Platform Baseboard for ARM1176JZF-S
(HBI-0147) was created as a development board to test ARM TrustZone,
CoreSight and Intelligent Energy Management (IEM) see ARM DUI 0425F.
items:
- const: arm,realview-pb1176
- description: ARM RealView Platform Baseboard for ARM 11 MPCore
(HBI-0159, HBI-0175 and HBI-0176) was created to showcase
multiprocessing with ARM11 using MPCore using symmetric
multiprocessing (SMP). See ARM DUI 0351E.
items:
- const: arm,realview-pb11mp
- description: ARM RealView Platform Baseboard for Cortex-A8 (HBI-0178,
HBI-0176 and HBI-0175) was the first reference platform for the
Cortex CPU family, including a Cortex-A8 test chip.
items:
- const: arm,realview-pba8
- description: ARM RealView Platform Baseboard Explore for Cortex-A9
(HBI-0182 and HBI-0183) was the reference platform for the Cortex-A9
CPU.
items:
- const: arm,realview-pbx
soc:
description: All RealView boards must provide a soc node in the root of the
device tree, representing the System-on-Chip since these test chips are
rather complex.
type: object
properties:
compatible:
oneOf:
- items:
- const: arm,realview-eb-soc
- const: simple-bus
- items:
- const: arm,realview-pb1176-soc
- const: simple-bus
- items:
- const: arm,realview-pb11mp-soc
- const: simple-bus
- items:
- const: arm,realview-pba8-soc
- const: simple-bus
- items:
- const: arm,realview-pbx-soc
- const: simple-bus
patternProperties:
"^.*syscon@[0-9a-f]+$":
type: object
description: All RealView boards must provide a syscon system controller
node inside the soc node.
properties:
compatible:
oneOf:
- items:
- const: arm,realview-eb11mp-revb-syscon
- const: arm,realview-eb-syscon
- const: syscon
- const: simple-mfd
- items:
- const: arm,realview-eb11mp-revc-syscon
- const: arm,realview-eb-syscon
- const: syscon
- const: simple-mfd
- items:
- const: arm,realview-eb-syscon
- const: syscon
- const: simple-mfd
- items:
- const: arm,realview-pb1176-syscon
- const: syscon
- const: simple-mfd
- items:
- const: arm,realview-pb11mp-syscon
- const: syscon
- const: simple-mfd
- items:
- const: arm,realview-pba8-syscon
- const: syscon
- const: simple-mfd
- items:
- const: arm,realview-pbx-syscon
- const: syscon
- const: simple-mfd
required:
- compatible
- reg
required:
- compatible
required:
- compatible
- soc
...

71
Documentation/devicetree/bindings/arm/arm,versatile.yaml Normal file
View File

@ -0,0 +1,71 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/arm/arm,versatile.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: ARM Versatile Boards Device Tree Bindings
maintainers:
- Linus Walleij <linus.walleij@linaro.org>
description: |+
The ARM Versatile boards are two variants of ARM926EJ-S evaluation boards
with various pluggable interface boards, in essence the Versatile PB version
is a superset of the Versatile AB version.
properties:
$nodename:
const: '/'
compatible:
oneOf:
- description: The ARM Versatile Application Baseboard (HBI-0118) is an
evaluation board specifically for the ARM926EJ-S. It can be connected
to an IB1 interface board for a touchscreen-type use case or an IB2
for a candybar phone-type use case. See ARM DUI 0225D.
items:
- const: arm,versatile-ab
- description: The ARM Versatile Platform Baseboard (HBI-0117) is an
extension of the Versatile Application Baseboard that includes a
PCI host controller. Like the sibling board, it is done specifically
for ARM926EJ-S. See ARM DUI 0224B.
items:
- const: arm,versatile-pb
core-module@10000000:
type: object
description: the root node in the Versatile platforms must contain
a core module child node. They are always at physical address
0x10000000 in all the Versatile variants.
properties:
compatible:
items:
- const: arm,core-module-versatile
- const: syscon
- const: simple-mfd
reg:
maxItems: 1
required:
- compatible
- reg
patternProperties:
"^syscon@[0-9a-f]+$":
type: object
description: When fitted with the IB2 Interface Board, the Versatile
AB will present an optional system controller node which controls the
extra peripherals on the interface board.
properties:
compatible:
contains:
const: arm,versatile-ib2-syscon
required:
- compatible
- reg
required:
- compatible
- core-module@10000000
...

223
Documentation/devicetree/bindings/arm/arm,vexpress-juno.yaml Normal file
View File

@ -0,0 +1,223 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/arm/arm,vexpress-juno.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: ARM Versatile Express and Juno Boards Device Tree Bindings
maintainers:
- Sudeep Holla <sudeep.holla@arm.com>
- Linus Walleij <linus.walleij@linaro.org>
description: |+
ARM's Versatile Express platform were built as reference designs for exploring
multicore Cortex-A class systems. The Versatile Express family contains both
32 bit (Aarch32) and 64 bit (Aarch64) systems.
The board consist of a motherboard and one or more daughterboards (tiles). The
motherboard provides a set of peripherals. Processor and RAM "live" on the
tiles.
The motherboard and each core tile should be described by a separate Device
Tree source file, with the tile's description including the motherboard file
using an include directive. As the motherboard can be initialized in one of
two different configurations ("memory maps"), care must be taken to include
the correct one.
When a new generation of boards were introduced under the name "Juno", these
shared to many common characteristics with the Versatile Express that the
"arm,vexpress" compatible was retained in the root node, and these are
included in this binding schema as well.
The root node indicates the CPU SoC on the core tile, and this
is a daughterboard to the main motherboard. The name used in the compatible
string shall match the name given in the core tile's technical reference
manual, followed by "arm,vexpress" as an additional compatible value. If
further subvariants are released of the core tile, even more fine-granular
compatible strings with up to three compatible strings are used.
properties:
$nodename:
const: '/'
compatible:
oneOf:
- description: CoreTile Express A9x4 (V2P-CA9) has 4 Cortex A9 CPU cores
in MPCore configuration in a test chip on the core tile. See ARM
DUI 0448I. This was the first Versatile Express platform.
items:
- const: arm,vexpress,v2p-ca9
- const: arm,vexpress
- description: CoreTile Express A5x2 (V2P-CA5s) has 2 Cortex A5 CPU cores
in a test chip on the core tile. It is intended to evaluate NEON, FPU
and Jazelle support in the Cortex A5 family. See ARM DUI 0541C.
items:
- const: arm,vexpress,v2p-ca5s
- const: arm,vexpress
- description: Coretile Express A15x2 (V2P-CA15) has 2 Cortex A15 CPU
cores in a MPCore configuration in a test chip on the core tile. See
ARM DUI 0604F.
items:
- const: arm,vexpress,v2p-ca15
- const: arm,vexpress
- description: CoreTile Express A15x4 (V2P-CA15, HBI-0237A) has 4 Cortex
A15 CPU cores in a test chip on the core tile. This is the first test
chip called "TC1".
items:
- const: arm,vexpress,v2p-ca15,tc1
- const: arm,vexpress,v2p-ca15
- const: arm,vexpress
- description: Coretile Express A15x2 A7x3 (V2P-CA15_A7) has 2 Cortex A15
CPU cores and 3 Cortex A7 cores in a big.LITTLE MPCore configuration
in a test chip on the core tile. See ARM DDI 0503I.
items:
- const: arm,vexpress,v2p-ca15_a7
- const: arm,vexpress
- description: LogicTile Express 20MG (V2F-1XV7) has 2 Cortex A53 CPU
cores in a test chip on the core tile. See ARM DDI 0498D.
items:
- const: arm,vexpress,v2f-1xv7,ca53x2
- const: arm,vexpress,v2f-1xv7
- const: arm,vexpress
- description: Arm Versatile Express Juno "r0" (the first Juno board,
V2M-Juno) was introduced as a vehicle for evaluating big.LITTLE on
AArch64 CPU cores. It has 2 Cortex A57 CPU cores and 4 Cortex A53
cores in a big.LITTLE configuration. It also features the MALI T624
GPU. See ARM document 100113_0000_07_en.
items:
- const: arm,juno
- const: arm,vexpress
- description: Arm Versatile Express Juno r1 Development Platform
(V2M-Juno r1) was introduced mainly aimed at development of PCIe
based systems. Juno r1 also has support for AXI masters placed on
the TLX connectors to join the coherency domain. Otherwise it is the
same configuration as Juno r0. See ARM document 100122_0100_06_en.
items:
- const: arm,juno-r1
- const: arm,juno
- const: arm,vexpress
- description: Arm Versatile Express Juno r2 Development Platform
(V2M-Juno r2). It has the same feature set as Juno r0 and r1. See
ARM document 100114_0200_04_en.
items:
- const: arm,juno-r2
- const: arm,juno
- const: arm,vexpress
- description: Arm AEMv8a Versatile Express Real-Time System Model
(VE RTSM) is a programmers view of the Versatile Express with Arm
v8A hardware. See ARM DUI 0575D.
items:
- const: arm,rtsm_ve,aemv8a
- const: arm,vexpress
- description: Arm FVP (Fixed Virtual Platform) base model revision C
See ARM Document 100964_1190_00_en.
items:
- const: arm,fvp-base-revc
- const: arm,vexpress
- description: Arm Foundation model for Aarch64
items:
- const: arm,foundation-aarch64
- const: arm,vexpress
arm,hbi:
$ref: '/schemas/types.yaml#/definitions/uint32'
description: This indicates the ARM HBI (Hardware Board ID), this is
ARM's unique board model ID, visible on the PCB's silkscreen.
arm,vexpress,site:
description: As Versatile Express can be configured in number of physically
different setups, the device tree should describe platform topology.
For this reason the root node and main motherboard node must define this
property, describing the physical location of the children nodes.
0 means motherboard site, while 1 and 2 are daughterboard sites, and
0xf means "sisterboard" which is the site containing the main CPU tile.
allOf:
- $ref: '/schemas/types.yaml#/definitions/uint32'
- minimum: 0
maximum: 15
arm,vexpress,position:
description: When daughterboards are stacked on one site, their position
in the stack be be described this attribute.
allOf:
- $ref: '/schemas/types.yaml#/definitions/uint32'
- minimum: 0
maximum: 3
arm,vexpress,dcc:
description: When describing tiles consisting of more than one DCC, its
number can be specified with this attribute.
allOf:
- $ref: '/schemas/types.yaml#/definitions/uint32'
- minimum: 0
maximum: 3
patternProperties:
"^bus@[0-9a-f]+$":
description: Static Memory Bus (SMB) node, if this exists it describes
the connection between the motherboard and any tiles. Sometimes the
compatible is placed directly under this node, sometimes it is placed
in a subnode named "motherboard". Sometimes the compatible includes
"arm,vexpress,v2?-p1" sometimes (on software models) is is just
"simple-bus". If the compatible is placed in the "motherboard" node,
it is stricter and always has two compatibles.
type: object
allOf:
- $ref: '/schemas/simple-bus.yaml'
properties:
compatible:
oneOf:
- items:
- enum:
- arm,vexpress,v2m-p1
- arm,vexpress,v2p-p1
- const: simple-bus
- const: simple-bus
motherboard:
type: object
description: The motherboard description provides a single "motherboard"
node using 2 address cells corresponding to the Static Memory Bus
used between the motherboard and the tile. The first cell defines the
Chip Select (CS) line number, the second cell address offset within
the CS. All interrupt lines between the motherboard and the tile
are active high and are described using single cell.
properties:
"#address-cells":
const: 2
"#size-cells":
const: 1
compatible:
items:
- enum:
- arm,vexpress,v2m-p1
- arm,vexpress,v2p-p1
- const: simple-bus
arm,v2m-memory-map:
description: This describes the memory map type.
allOf:
- $ref: '/schemas/types.yaml#/definitions/string'
- enum:
- rs1
- rs2
required:
- compatible
required:
- compatible
allOf:
- if:
properties:
compatible:
contains:
enum:
- arm,vexpress,v2p-ca9
- arm,vexpress,v2p-ca5s
- arm,vexpress,v2p-ca15
- arm,vexpress,v2p-ca15_a7
- arm,vexpress,v2f-1xv7,ca53x2
then:
required:
- arm,hbi
...

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

@ -1,237 +0,0 @@
ARM Integrator/AP (Application Platform) and Integrator/CP (Compact Platform)
-----------------------------------------------------------------------------
ARM's oldest Linux-supported platform with connectors for different core
tiles of ARMv4, ARMv5 and ARMv6 type.
Required properties (in root node):
compatible = "arm,integrator-ap"; /* Application Platform */
compatible = "arm,integrator-cp"; /* Compact Platform */
FPGA type interrupt controllers, see the versatile-fpga-irq binding doc.
Required nodes:
- core-module: the root node to the Integrator platforms must have
a core-module with regs and the compatible string
"arm,core-module-integrator"
- external-bus-interface: the root node to the Integrator platforms
must have an external bus interface with regs and the
compatible-string "arm,external-bus-interface"
Required properties for the core module:
- regs: the location and size of the core module registers, one
range of 0x200 bytes.
- syscon: the root node of the Integrator platforms must have a
system controller node pointing to the control registers,
with the compatible string
"arm,integrator-ap-syscon"
"arm,integrator-cp-syscon"
respectively.
Required properties for the system controller:
- regs: the location and size of the system controller registers,
one range of 0x100 bytes.
Required properties for the AP system controller:
- interrupts: the AP syscon node must include the logical module
interrupts, stated in order of module instance <module 0>,
<module 1>, <module 2> ... for the CP system controller this
is not required not of any use.
/dts-v1/;
/include/ "integrator.dtsi"
/ {
model = "ARM Integrator/AP";
compatible = "arm,integrator-ap";
core-module@10000000 {
compatible = "arm,core-module-integrator";
reg = <0x10000000 0x200>;
};
ebi@12000000 {
compatible = "arm,external-bus-interface";
reg = <0x12000000 0x100>;
};
syscon {
compatible = "arm,integrator-ap-syscon";
reg = <0x11000000 0x100>;
interrupt-parent = <&pic>;
/* These are the logic module IRQs */
interrupts = <9>, <10>, <11>, <12>;
};
};
ARM Versatile Application and Platform Baseboards
-------------------------------------------------
ARM's development hardware platform with connectors for customizable
core tiles. The hardware configuration of the Versatile boards is
highly customizable.
Required properties (in root node):
compatible = "arm,versatile-ab"; /* Application baseboard */
compatible = "arm,versatile-pb"; /* Platform baseboard */
Interrupt controllers:
- VIC required properties:
compatible = "arm,versatile-vic";
interrupt-controller;
#interrupt-cells = <1>;
- SIC required properties:
compatible = "arm,versatile-sic";
interrupt-controller;
#interrupt-cells = <1>;
Required nodes:
- core-module: the root node to the Versatile platforms must have
a core-module with regs and the compatible strings
"arm,core-module-versatile", "syscon"
Optional nodes:
- arm,versatile-ib2-syscon : if the Versatile has an IB2 interface
board mounted, this has a separate system controller that is
defined in this node.
Required properties:
compatible = "arm,versatile-ib2-syscon", "syscon"
ARM RealView Boards
-------------------
The RealView boards cover tailored evaluation boards that are used to explore
the ARM11 and Cortex A-8 and Cortex A-9 processors.
Required properties (in root node):
/* RealView Emulation Baseboard */
compatible = "arm,realview-eb";
/* RealView Platform Baseboard for ARM1176JZF-S */
compatible = "arm,realview-pb1176";
/* RealView Platform Baseboard for ARM11 MPCore */
compatible = "arm,realview-pb11mp";
/* RealView Platform Baseboard for Cortex A-8 */
compatible = "arm,realview-pba8";
/* RealView Platform Baseboard Explore for Cortex A-9 */
compatible = "arm,realview-pbx";
Required nodes:
- soc: some node of the RealView platforms must be the SoC
node that contain the SoC-specific devices, with the compatible
string set to one of these tuples:
"arm,realview-eb-soc", "simple-bus"
"arm,realview-pb1176-soc", "simple-bus"
"arm,realview-pb11mp-soc", "simple-bus"
"arm,realview-pba8-soc", "simple-bus"
"arm,realview-pbx-soc", "simple-bus"
- syscon: some subnode of the RealView SoC node must be a
system controller node pointing to the control registers,
with the compatible string set to one of these:
"arm,realview-eb11mp-revb-syscon", "arm,realview-eb-syscon", "syscon"
"arm,realview-eb11mp-revc-syscon", "arm,realview-eb-syscon", "syscon"
"arm,realview-eb-syscon", "syscon"
"arm,realview-pb1176-syscon", "syscon"
"arm,realview-pb11mp-syscon", "syscon"
"arm,realview-pba8-syscon", "syscon"
"arm,realview-pbx-syscon", "syscon"
Required properties for the system controller:
- regs: the location and size of the system controller registers,
one range of 0x1000 bytes.
Example:
/dts-v1/;
#include <dt-bindings/interrupt-controller/irq.h>
/ {
model = "ARM RealView PB1176 with device tree";
compatible = "arm,realview-pb1176";
#address-cells = <1>;
#size-cells = <1>;
soc {
#address-cells = <1>;
#size-cells = <1>;
compatible = "arm,realview-pb1176-soc", "simple-bus";
ranges;
syscon: syscon@10000000 {
compatible = "arm,realview-syscon", "syscon";
reg = <0x10000000 0x1000>;
};
};
};
ARM Versatile Express Boards
-----------------------------
For details on the device tree bindings for ARM Versatile Express boards
please consult the vexpress.txt file in the same directory as this file.
ARM Juno Boards
----------------
The Juno boards are targeting development for AArch64 systems. The first
iteration, Juno r0, is a vehicle for evaluating big.LITTLE on AArch64,
with the second iteration, Juno r1, mainly aimed at development of PCIe
based systems. Juno r1 also has support for AXI masters placed on the TLX
connectors to join the coherency domain.
Juno boards are described in a similar way to ARM Versatile Express boards,
with the motherboard part of the hardware being described in a separate file
to highlight the fact that is part of the support infrastructure for the SoC.
Juno device tree bindings also share the Versatile Express bindings as
described under the RS1 memory mapping.
Required properties (in root node):
compatible = "arm,juno"; /* For Juno r0 board */
compatible = "arm,juno-r1"; /* For Juno r1 board */
compatible = "arm,juno-r2"; /* For Juno r2 board */
Required nodes:
The description for the board must include:
- a "psci" node describing the boot method used for the secondary CPUs.
A detailed description of the bindings used for "psci" nodes is present
in the psci.yaml file.
- a "cpus" node describing the available cores and their associated
"enable-method"s. For more details see cpus.yaml file.
Example:
/dts-v1/;
/ {
model = "ARM Juno development board (r0)";
compatible = "arm,juno", "arm,vexpress";
interrupt-parent = <&gic>;
#address-cells = <2>;
#size-cells = <2>;
cpus {
#address-cells = <2>;
#size-cells = <0>;
A57_0: cpu@0 {
compatible = "arm,cortex-a57";
reg = <0x0 0x0>;
device_type = "cpu";
enable-method = "psci";
};
.....
A53_0: cpu@100 {
compatible = "arm,cortex-a53";
reg = <0x0 0x100>;
device_type = "cpu";
enable-method = "psci";
};
.....
};
};

36
Documentation/devicetree/bindings/arm/bcm/brcm,bcm11351-cpu-method.txt
View File

@ -1,36 +0,0 @@
Broadcom Kona Family CPU Enable Method
--------------------------------------
This binding defines the enable method used for starting secondary
CPUs in the following Broadcom SoCs:
BCM11130, BCM11140, BCM11351, BCM28145, BCM28155, BCM21664
The enable method is specified by defining the following required
properties in the "cpu" device tree node:
- enable-method = "brcm,bcm11351-cpu-method";
- secondary-boot-reg = <...>;
The secondary-boot-reg property is a u32 value that specifies the
physical address of the register used to request the ROM holding pen
code release a secondary CPU. The value written to the register is
formed by encoding the target CPU id into the low bits of the
physical start address it should jump to.
Example:
cpus {
#address-cells = <1>;
#size-cells = <0>;
cpu0: cpu@0 {
device_type = "cpu";
compatible = "arm,cortex-a9";
reg = <0>;
};
cpu1: cpu@1 {
device_type = "cpu";
compatible = "arm,cortex-a9";
reg = <1>;
enable-method = "brcm,bcm11351-cpu-method";
secondary-boot-reg = <0x3500417c>;
};
};

10
Documentation/devicetree/bindings/arm/bcm/brcm,bcm11351.txt
View File

@ -1,10 +0,0 @@
Broadcom BCM11351 device tree bindings
-------------------------------------------
Boards with the bcm281xx SoC family (which includes bcm11130, bcm11140,
bcm11351, bcm28145, bcm28155 SoCs) shall have the following properties:
Required root node property:
compatible = "brcm,bcm11351";
DEPRECATED: compatible = "bcm,bcm11351";

21
Documentation/devicetree/bindings/arm/bcm/brcm,bcm11351.yaml Normal file
View File

@ -0,0 +1,21 @@
# SPDX-License-Identifier: GPL-2.0
%YAML 1.2
---
$id: http://devicetree.org/schemas/arm/bcm/brcm,bcm11351.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Broadcom BCM11351 device tree bindings
maintainers:
- Florian Fainelli <f.fainelli@gmail.com>
properties:
$nodename:
const: '/'
compatible:
items:
- enum:
- brcm,bcm28155-ap
- const: brcm,bcm11351
...

15
Documentation/devicetree/bindings/arm/bcm/brcm,bcm21664.txt
View File

@ -1,15 +0,0 @@
Broadcom BCM21664 device tree bindings
--------------------------------------
This document describes the device tree bindings for boards with the BCM21664
SoC.
Required root node property:
- compatible: brcm,bcm21664
Example:
/ {
model = "BCM21664 SoC";
compatible = "brcm,bcm21664";
[...]
}

21
Documentation/devicetree/bindings/arm/bcm/brcm,bcm21664.yaml Normal file
View File

@ -0,0 +1,21 @@
# SPDX-License-Identifier: GPL-2.0
%YAML 1.2
---
$id: http://devicetree.org/schemas/arm/bcm/brcm,bcm21664.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Broadcom BCM21664 device tree bindings
maintainers:
- Florian Fainelli <f.fainelli@gmail.com>
properties:
$nodename:
const: '/'
compatible:
items:
- enum:
- brcm,bcm21664-garnet
- const: brcm,bcm21664
...

36
Documentation/devicetree/bindings/arm/bcm/brcm,bcm23550-cpu-method.txt
View File

@ -1,36 +0,0 @@
Broadcom Kona Family CPU Enable Method
--------------------------------------
This binding defines the enable method used for starting secondary
CPUs in the following Broadcom SoCs:
BCM23550
The enable method is specified by defining the following required
properties in the "cpu" device tree node:
- enable-method = "brcm,bcm23550";
- secondary-boot-reg = <...>;
The secondary-boot-reg property is a u32 value that specifies the
physical address of the register used to request the ROM holding pen
code release a secondary CPU. The value written to the register is
formed by encoding the target CPU id into the low bits of the
physical start address it should jump to.
Example:
cpus {
#address-cells = <1>;
#size-cells = <0>;
cpu0: cpu@0 {
device_type = "cpu";
compatible = "arm,cortex-a9";
reg = <0>;
};
cpu1: cpu@1 {
device_type = "cpu";
compatible = "arm,cortex-a9";
reg = <1>;
enable-method = "brcm,bcm23550";
secondary-boot-reg = <0x3500417c>;
};
};

15
Documentation/devicetree/bindings/arm/bcm/brcm,bcm23550.txt
View File

@ -1,15 +0,0 @@
Broadcom BCM23550 device tree bindings
--------------------------------------
This document describes the device tree bindings for boards with the BCM23550
SoC.
Required root node property:
- compatible: brcm,bcm23550
Example:
/ {
model = "BCM23550 SoC";
compatible = "brcm,bcm23550";
[...]
}

21
Documentation/devicetree/bindings/arm/bcm/brcm,bcm23550.yaml Normal file
View File

@ -0,0 +1,21 @@
# SPDX-License-Identifier: GPL-2.0
%YAML 1.2
---
$id: http://devicetree.org/schemas/arm/bcm/brcm,bcm23550.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Broadcom BCM23550 device tree bindings
maintainers:
- Florian Fainelli <f.fainelli@gmail.com>
properties:
$nodename:
const: '/'
compatible:
items:
- enum:
- brcm,bcm23550-sparrow
- const: brcm,bcm23550
...

15
Documentation/devicetree/bindings/arm/bcm/brcm,bcm4708.txt
View File

@ -1,15 +0,0 @@
Broadcom BCM4708 device tree bindings
-------------------------------------------
Boards with the BCM4708 SoC shall have the following properties:
Required root node property:
bcm4708
compatible = "brcm,bcm4708";
bcm4709
compatible = "brcm,bcm4709";
bcm53012
compatible = "brcm,bcm53012";

88
Documentation/devicetree/bindings/arm/bcm/brcm,bcm4708.yaml Normal file
View File

@ -0,0 +1,88 @@
# SPDX-License-Identifier: GPL-2.0
%YAML 1.2
---
$id: http://devicetree.org/schemas/arm/bcm/brcm,bcm4708.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Broadcom BCM4708 device tree bindings
description:
Broadcom BCM4708/47081/4709/47094/53012 Wi-Fi/network SoCs based
on the iProc architecture (Northstar).
maintainers:
- Florian Fainelli <f.fainelli@gmail.com>
- Hauke Mehrtens <hauke@hauke-m.de>
- Rafal Milecki <zajec5@gmail.com>
properties:
$nodename:
const: '/'
compatible:
oneOf:
- description: BCM4708 based boards
items:
- enum:
- asus,rt-ac56u
- asus,rt-ac68u
- buffalo,wzr-1750dhp
- linksys,ea6300-v1
- linksys,ea6500-v2
- luxul,xap-1510v1
- luxul,xwc-1000
- netgear,r6250v1
- netgear,r6300v2
- smartrg,sr400ac
- brcm,bcm94708
- const: brcm,bcm4708
- description: BCM47081 based boards
items:
- enum:
- asus,rt-n18u
- buffalo,wzr-600dhp2
- buffalo,wzr-900dhp
- luxul,xap-1410v1
- luxul,xwr-1200v1
- tplink,archer-c5-v2
- const: brcm,bcm47081
- const: brcm,bcm4708
- description: BCM4709 based boards
items:
- enum:
- asus,rt-ac87u
- buffalo,wxr-1900dhp
- linksys,ea9200
- netgear,r7000
- netgear,r8000
- tplink,archer-c9-v1
- brcm,bcm94709
- const: brcm,bcm4709
- const: brcm,bcm4708
- description: BCM47094 based boards
items:
- enum:
- dlink,dir-885l
- linksys,panamera
- luxul,abr-4500-v1
- luxul,xap-1610-v1
- luxul,xbr-4500-v1
- luxul,xwc-2000-v1
- luxul,xwr-3100v1
- luxul,xwr-3150-v1
- netgear,r8500
- phicomm,k3
- const: brcm,bcm47094
- const: brcm,bcm4708
- description: BCM53012 based boards
items:
- enum:
- brcm,bcm953012er
- brcm,bcm953012hr
- brcm,bcm953012k
- const: brcm,brcm53012
- const: brcm,bcm4708
...

31
Documentation/devicetree/bindings/arm/bcm/brcm,cygnus.txt
View File

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

29
Documentation/devicetree/bindings/arm/bcm/brcm,cygnus.yaml Normal file
View File

@ -0,0 +1,29 @@
# SPDX-License-Identifier: GPL-2.0
%YAML 1.2
---
$id: http://devicetree.org/schemas/arm/bcm/brcm,cygnus.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Broadcom Cygnus device tree bindings
maintainers:
- Ray Jui <rjui@broadcom.com>
- Scott Branden <sbranden@broadcom.com>
properties:
$nodename:
const: '/'
compatible:
items:
- enum:
- brcm,bcm11300
- brcm,bcm11320
- brcm,bcm11350
- brcm,bcm11360
- brcm,bcm58300
- brcm,bcm58302
- brcm,bcm58303
- brcm,bcm58305
- const: brcm,cygnus
...

14
Documentation/devicetree/bindings/arm/bcm/brcm,hr2.txt
View File

@ -1,14 +0,0 @@
Broadcom Hurricane 2 device tree bindings
---------------------------------------
Broadcom Hurricane 2 family of SoCs are used for switching control. These SoCs
are based on Broadcom's iProc SoC architecture and feature a single core Cortex
A9 ARM CPUs, DDR2/DDR3 memory, PCIe GEN-2, USB 2.0 and USB 3.0, serial and NAND
flash and a PCIe attached integrated switching engine.
Boards with Hurricane SoCs shall have the following properties:
Required root node property:
BCM53342
compatible = "brcm,bcm53342", "brcm,hr2";

28
Documentation/devicetree/bindings/arm/bcm/brcm,hr2.yaml Normal file
View File

@ -0,0 +1,28 @@
# SPDX-License-Identifier: GPL-2.0
%YAML 1.2
---
$id: http://devicetree.org/schemas/arm/bcm/brcm,hr2.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Broadcom Hurricane 2 device tree bindings
description:
Broadcom Hurricane 2 family of SoCs are used for switching control. These SoCs
are based on Broadcom's iProc SoC architecture and feature a single core Cortex
A9 ARM CPUs, DDR2/DDR3 memory, PCIe GEN-2, USB 2.0 and USB 3.0, serial and NAND
flash and a PCIe attached integrated switching engine.
maintainers:
- Florian Fainelli <f.fainelli@gmail.com>
properties:
$nodename:
const: '/'
compatible:
items:
- enum:
- ubnt,unifi-switch8
- const: brcm,bcm53342
- const: brcm,hr2
...

9
Documentation/devicetree/bindings/arm/bcm/brcm,ns2.txt
View File

@ -1,9 +0,0 @@
Broadcom North Star 2 (NS2) device tree bindings
------------------------------------------------
Boards with NS2 shall have the following properties:
Required root node property:
NS2 SVK board
compatible = "brcm,ns2-svk", "brcm,ns2";

23
Documentation/devicetree/bindings/arm/bcm/brcm,ns2.yaml Normal file
View File

@ -0,0 +1,23 @@
# SPDX-License-Identifier: GPL-2.0
%YAML 1.2
---
$id: http://devicetree.org/schemas/arm/bcm/brcm,ns2.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Broadcom North Star 2 (NS2) device tree bindings
maintainers:
- Ray Jui <rjui@broadcom.com>
- Scott Branden <sbranden@broadcom.com>
properties:
$nodename:
const: '/'
compatible:
items:
- enum:
- brcm,ns2-svk
- brcm,ns2-xmc
- const: brcm,ns2
...

39
Documentation/devicetree/bindings/arm/bcm/brcm,nsp-cpu-method.txt
View File

@ -1,39 +0,0 @@
Broadcom Northstar Plus SoC CPU Enable Method
---------------------------------------------
This binding defines the enable method used for starting secondary
CPU in the following Broadcom SoCs:
BCM58522, BCM58525, BCM58535, BCM58622, BCM58623, BCM58625, BCM88312
The enable method is specified by defining the following required
properties in the corresponding secondary "cpu" device tree node:
- enable-method = "brcm,bcm-nsp-smp";
- secondary-boot-reg = <...>;
The secondary-boot-reg property is a u32 value that specifies the
physical address of the register which should hold the common
entry point for a secondary CPU. This entry is cpu node specific
and should be added per cpu. E.g., in case of NSP (BCM58625) which
is a dual core CPU SoC, this entry should be added to cpu1 node.
Example:
cpus {
#address-cells = <1>;
#size-cells = <0>;
cpu0: cpu@0 {
device_type = "cpu";
compatible = "arm,cortex-a9";
next-level-cache = <&L2>;
reg = <0>;
};
cpu1: cpu@1 {
device_type = "cpu";
compatible = "arm,cortex-a9";
next-level-cache = <&L2>;
enable-method = "brcm,bcm-nsp-smp";
secondary-boot-reg = <0xffff042c>;
reg = <1>;
};
};

34
Documentation/devicetree/bindings/arm/bcm/brcm,nsp.txt
View File

@ -1,34 +0,0 @@
Broadcom Northstar Plus device tree bindings
--------------------------------------------
Broadcom Northstar Plus family of SoCs are used for switching control
and management applications as well as residential router/gateway
applications. The SoC features dual core Cortex A9 ARM CPUs, integrating
several peripheral interfaces including multiple Gigabit Ethernet PHYs,
DDR3 memory, PCIE Gen-2, USB 2.0 and USB 3.0, serial and NAND flash,
SATA and several other IO controllers.
Boards with Northstar Plus SoCs shall have the following properties:
Required root node property:
BCM58522
compatible = "brcm,bcm58522", "brcm,nsp";
BCM58525
compatible = "brcm,bcm58525", "brcm,nsp";
BCM58535
compatible = "brcm,bcm58535", "brcm,nsp";
BCM58622
compatible = "brcm,bcm58622", "brcm,nsp";
BCM58623
compatible = "brcm,bcm58623", "brcm,nsp";
BCM58625
compatible = "brcm,bcm58625", "brcm,nsp";
BCM88312
compatible = "brcm,bcm88312", "brcm,nsp";

36
Documentation/devicetree/bindings/arm/bcm/brcm,nsp.yaml Normal file
View File

@ -0,0 +1,36 @@
# SPDX-License-Identifier: GPL-2.0
%YAML 1.2
---
$id: http://devicetree.org/schemas/arm/bcm/brcm,nsp.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Broadcom Northstar Plus device tree bindings
description:
Broadcom Northstar Plus family of SoCs are used for switching control
and management applications as well as residential router/gateway
applications. The SoC features dual core Cortex A9 ARM CPUs, integrating
several peripheral interfaces including multiple Gigabit Ethernet PHYs,
DDR3 memory, PCIE Gen-2, USB 2.0 and USB 3.0, serial and NAND flash,
SATA and several other IO controllers.
maintainers:
- Ray Jui <rjui@broadcom.com>
- Scott Branden <sbranden@broadcom.com>
properties:
$nodename:
const: '/'
compatible:
items:
- enum:
- brcm,bcm58522
- brcm,bcm58525
- brcm,bcm58535
- brcm,bcm58622
- brcm,bcm58623
- brcm,bcm58625
- brcm,bcm88312
- const: brcm,nsp
...

12
Documentation/devicetree/bindings/arm/bcm/brcm,stingray.txt
View File

@ -1,12 +0,0 @@
Broadcom Stingray device tree bindings
------------------------------------------------
Boards with Stingray shall have the following properties:
Required root node property:
Stingray Combo SVK board
compatible = "brcm,bcm958742k", "brcm,stingray";
Stingray SST100 board
compatible = "brcm,bcm958742t", "brcm,stingray";

24
Documentation/devicetree/bindings/arm/bcm/brcm,stingray.yaml Normal file
View File

@ -0,0 +1,24 @@
# SPDX-License-Identifier: GPL-2.0
%YAML 1.2
---
$id: http://devicetree.org/schemas/arm/bcm/brcm,stingray.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Broadcom Stingray device tree bindings
maintainers:
- Ray Jui <rjui@broadcom.com>
- Scott Branden <sbranden@broadcom.com>
properties:
$nodename:
const: '/'
compatible:
items:
- enum:
- brcm,bcm958742k
- brcm,bcm958742t
- brcm,bcm958802a802x
- const: brcm,stingray
...

10
Documentation/devicetree/bindings/arm/bcm/brcm,vulcan-soc.txt
View File

@ -1,10 +0,0 @@
Broadcom Vulcan device tree bindings
------------------------------------
Boards with Broadcom Vulcan shall have the following root property:
Broadcom Vulcan Evaluation Board:
compatible = "brcm,vulcan-eval", "brcm,vulcan-soc";
Generic Vulcan board:
compatible = "brcm,vulcan-soc";

22
Documentation/devicetree/bindings/arm/bcm/brcm,vulcan-soc.yaml Normal file
View File

@ -0,0 +1,22 @@
# SPDX-License-Identifier: GPL-2.0
%YAML 1.2
---
$id: http://devicetree.org/schemas/arm/bcm/brcm,vulcan-soc.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Broadcom Vulcan device tree bindings
maintainers:
- Robert Richter <rrichter@marvell.com>
properties:
$nodename:
const: '/'
compatible:
items:
- enum:
- brcm,vulcan-eval
- cavium,thunderx2-cn9900
- const: brcm,vulcan-soc
...

336
Documentation/devicetree/bindings/arm/coresight-cti.yaml Normal file
View File

@ -0,0 +1,336 @@
# SPDX-License-Identifier: GPL-2.0-only or BSD-2-Clause
# Copyright 2019 Linaro Ltd.
%YAML 1.2
---
$id: http://devicetree.org/schemas/arm/coresight-cti.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: ARM Coresight Cross Trigger Interface (CTI) device.
description: |
The CoreSight Embedded Cross Trigger (ECT) consists of CTI devices connected
to one or more CoreSight components and/or a CPU, with CTIs interconnected in
a star topology via the Cross Trigger Matrix (CTM), which is not programmable.
The ECT components are not part of the trace generation data path and are thus
not part of the CoreSight graph described in the general CoreSight bindings
file coresight.txt.
The CTI component properties define the connections between the individual
CTI and the components it is directly connected to, consisting of input and
output hardware trigger signals. CTIs can have a maximum number of input and
output hardware trigger signals (8 each for v1 CTI, 32 each for v2 CTI). The
number is defined at design time, the maximum of each defined in the DEVID
register.
CTIs are interconnected in a star topology via the CTM, using a number of
programmable channels, usually 4, but again implementation defined and
described in the DEVID register. The star topology is not required to be
described in the bindings as the actual connections are software
programmable.
In general the connections between CTI and components via the trigger signals
are implementation defined, except when the CTI is connected to an ARM v8
architecture core and optional ETM.
In this case the ARM v8 architecture defines the required signal connections
between CTI and the CPU core and ETM if present. In the case of a v8
architecturally connected CTI an additional compatible string is used to
indicate this feature (arm,coresight-cti-v8-arch).
When CTI trigger connection information is unavailable then a minimal driver
binding can be declared with no explicit trigger signals. This will result
the driver detecting the maximum available triggers and channels from the
DEVID register and make them all available for use as a single default
connection. Any user / client application will require additional information
on the connections between the CTI and other components for correct operation.
This information might be found by enabling the Integration Test registers in
the driver (set CONFIG_CORESIGHT_CTI_INTEGRATION_TEST in Kernel
configuration). These registers may be used to explore the trigger connections
between CTI and other CoreSight components.
Certain triggers between CoreSight devices and the CTI have specific types
and usages. These can be defined along with the signal indexes with the
constants defined in <dt-bindings/arm/coresight-cti-dt.h>
For example a CTI connected to a core will usually have a DBGREQ signal. This
is defined in the binding as type PE_EDBGREQ. These types will appear in an
optional array alongside the signal indexes. Omitting types will default all
signals to GEN_IO.
Note that some hardware trigger signals can be connected to non-CoreSight
components (e.g. UART etc) depending on hardware implementation.
maintainers:
- Mike Leach <mike.leach@linaro.org>
allOf:
- $ref: /schemas/arm/primecell.yaml#
# Need a custom select here or 'arm,primecell' will match on lots of nodes
select:
properties:
compatible:
contains:
enum:
- arm,coresight-cti
required:
- compatible
properties:
$nodename:
pattern: "^cti(@[0-9a-f]+)$"
compatible:
oneOf:
- items:
- const: arm,coresight-cti
- const: arm,primecell
- items:
- const: arm,coresight-cti-v8-arch
- const: arm,coresight-cti
- const: arm,primecell
reg:
maxItems: 1
cpu:
$ref: /schemas/types.yaml#/definitions/phandle
description:
Handle to cpu this device is associated with. This must appear in the
base cti node if compatible string arm,coresight-cti-v8-arch is used,
or may appear in a trig-conns child node when appropriate.
arm,cti-ctm-id:
$ref: /schemas/types.yaml#/definitions/uint32
description:
Defines the CTM this CTI is connected to, in large systems with multiple
separate CTI/CTM nets. Typically multi-socket systems where the CTM is
propagated between sockets.
arm,cs-dev-assoc:
$ref: /schemas/types.yaml#/definitions/phandle
description:
defines a phandle reference to an associated CoreSight trace device.
When the associated trace device is enabled, then the respective CTI
will be enabled. Use in a trig-conns node, or in CTI base node when
compatible string arm,coresight-cti-v8-arch used. If the associated
device has not been registered then the node name will be stored as
the connection name for later resolution. If the associated device is
not a CoreSight device or not registered then the node name will remain
the connection name and automatic enabling will not occur.
# size cells and address cells required if trig-conns node present.
"#size-cells":
const: 0
"#address-cells":
const: 1
patternProperties:
'^trig-conns@([0-9]+)$':
type: object
description:
A trigger connections child node which describes the trigger signals
between this CTI and another hardware device. This device may be a CPU,
CoreSight device, any other hardware device or simple external IO lines.
The connection may have both input and output triggers, or only one or the
other.
properties:
reg:
maxItems: 1
arm,trig-in-sigs:
allOf:
- $ref: /schemas/types.yaml#/definitions/uint32-array
minItems: 1
maxItems: 32
description:
List of CTI trigger in signal numbers in use by a trig-conns node.
arm,trig-in-types:
allOf:
- $ref: /schemas/types.yaml#/definitions/uint32-array
minItems: 1
maxItems: 32
description:
List of constants representing the types for the CTI trigger in
signals. Types in this array match to the corresponding signal in the
arm,trig-in-sigs array. If the -types array is smaller, or omitted
completely, then the types will default to GEN_IO.
arm,trig-out-sigs:
allOf:
- $ref: /schemas/types.yaml#/definitions/uint32-array
minItems: 1
maxItems: 32
description:
List of CTI trigger out signal numbers in use by a trig-conns node.
arm,trig-out-types:
allOf:
- $ref: /schemas/types.yaml#/definitions/uint32-array
minItems: 1
maxItems: 32
description:
List of constants representing the types for the CTI trigger out
signals. Types in this array match to the corresponding signal
in the arm,trig-out-sigs array. If the "-types" array is smaller,
or omitted completely, then the types will default to GEN_IO.
arm,trig-filters:
allOf:
- $ref: /schemas/types.yaml#/definitions/uint32-array
minItems: 1
maxItems: 32
description:
List of CTI trigger out signals that will be blocked from becoming
active, unless filtering is disabled on the driver.
arm,trig-conn-name:
allOf:
- $ref: /schemas/types.yaml#/definitions/string
description:
Defines a connection name that will be displayed, if the cpu or
arm,cs-dev-assoc properties are not being used in this connection.
Principle use for CTI that are connected to non-CoreSight devices, or
external IO.
anyOf:
- required:
- arm,trig-in-sigs
- required:
- arm,trig-out-sigs
oneOf:
- required:
- arm,trig-conn-name
- required:
- cpu
- required:
- arm,cs-dev-assoc
required:
- reg
required:
- compatible
- reg
- clocks
- clock-names
if:
properties:
compatible:
contains:
const: arm,coresight-cti-v8-arch
then:
required:
- cpu
examples:
# minimum CTI definition. DEVID register used to set number of triggers.
- |
cti@20020000 {
compatible = "arm,coresight-cti", "arm,primecell";
reg = <0x20020000 0x1000>;
clocks = <&soc_smc50mhz>;
clock-names = "apb_pclk";
};
# v8 architecturally defined CTI - CPU + ETM connections generated by the
# driver according to the v8 architecture specification.
- |
cti@859000 {
compatible = "arm,coresight-cti-v8-arch", "arm,coresight-cti",
"arm,primecell";
reg = <0x859000 0x1000>;
clocks = <&soc_smc50mhz>;
clock-names = "apb_pclk";
cpu = <&CPU1>;
arm,cs-dev-assoc = <&etm1>;
};
# Implementation defined CTI - CPU + ETM connections explicitly defined..
# Shows use of type constants from dt-bindings/arm/coresight-cti-dt.h
# #size-cells and #address-cells are required if trig-conns@ nodes present.
- |
#include <dt-bindings/arm/coresight-cti-dt.h>
cti@858000 {
compatible = "arm,coresight-cti", "arm,primecell";
reg = <0x858000 0x1000>;
clocks = <&soc_smc50mhz>;
clock-names = "apb_pclk";
arm,cti-ctm-id = <1>;
#address-cells = <1>;
#size-cells = <0>;
trig-conns@0 {
reg = <0>;
arm,trig-in-sigs = <4 5 6 7>;
arm,trig-in-types = <ETM_EXTOUT
ETM_EXTOUT
ETM_EXTOUT
ETM_EXTOUT>;
arm,trig-out-sigs = <4 5 6 7>;
arm,trig-out-types = <ETM_EXTIN
ETM_EXTIN
ETM_EXTIN
ETM_EXTIN>;
arm,cs-dev-assoc = <&etm0>;
};
trig-conns@1 {
reg = <1>;
cpu = <&CPU0>;
arm,trig-in-sigs = <0 1>;
arm,trig-in-types = <PE_DBGTRIGGER
PE_PMUIRQ>;
arm,trig-out-sigs=<0 1 2 >;
arm,trig-out-types = <PE_EDBGREQ
PE_DBGRESTART
PE_CTIIRQ>;
arm,trig-filters = <0>;
};
};
# Implementation defined CTI - non CoreSight component connections.
- |
cti@20110000 {
compatible = "arm,coresight-cti", "arm,primecell";
reg = <0 0x20110000 0 0x1000>;
clocks = <&soc_smc50mhz>;
clock-names = "apb_pclk";
#address-cells = <1>;
#size-cells = <0>;
trig-conns@0 {
reg = <0>;
arm,trig-in-sigs=<0>;
arm,trig-in-types=<GEN_INTREQ>;
arm,trig-out-sigs=<0>;
arm,trig-out-types=<GEN_HALTREQ>;
arm,trig-conn-name = "sys_profiler";
};
trig-conns@1 {
reg = <1>;
arm,trig-out-sigs=<2 3>;
arm,trig-out-types=<GEN_HALTREQ GEN_RESTARTREQ>;
arm,trig-conn-name = "watchdog";
};
trig-conns@2 {
reg = <2>;
arm,trig-in-sigs=<1 6>;
arm,trig-in-types=<GEN_HALTREQ GEN_RESTARTREQ>;
arm,trig-conn-name = "g_counter";
};
};
...

7
Documentation/devicetree/bindings/arm/coresight.txt
View File

@ -45,6 +45,10 @@ its hardware characteristcs.
- Coresight Address Translation Unit (CATU)
"arm,coresight-catu", "arm,primecell";
- Coresight Cross Trigger Interface (CTI):
"arm,coresight-cti", "arm,primecell";
See coresight-cti.yaml for full CTI definitions.
* reg: physical base address and length of the register
set(s) of the component.
@ -72,6 +76,9 @@ its hardware characteristcs.
* reg-names: the only acceptable values are "stm-base" and
"stm-stimulus-base", each corresponding to the areas defined in "reg".
* Required properties for Coresight Cross Trigger Interface (CTI)
See coresight-cti.yaml for full CTI definitions.
* Required properties for devices that don't show up on the AMBA bus, such as
non-configurable replicators and non-configurable funnels:

46
Documentation/devicetree/bindings/arm/cpus.yaml
View File

@ -123,11 +123,18 @@ properties:
- arm,cortex-a12
- arm,cortex-a15
- arm,cortex-a17
- arm,cortex-a32
- arm,cortex-a34
- arm,cortex-a35
- arm,cortex-a53
- arm,cortex-a55
- arm,cortex-a57
- arm,cortex-a65
- arm,cortex-a72
- arm,cortex-a73
- arm,cortex-a75
- arm,cortex-a76
- arm,cortex-a77
- arm,cortex-m0
- arm,cortex-m0+
- arm,cortex-m1
@ -136,6 +143,8 @@ properties:
- arm,cortex-r4
- arm,cortex-r5
- arm,cortex-r7
- arm,neoverse-e1
- arm,neoverse-n1
- brcm,brahma-b15
- brcm,brahma-b53
- brcm,vulcan
@ -155,6 +164,8 @@ properties:
- nvidia,tegra194-carmel
- qcom,krait
- qcom,kryo
- qcom,kryo260
- qcom,kryo280
- qcom,kryo385
- qcom,kryo485
- qcom,scorpion
@ -201,6 +212,8 @@ properties:
- rockchip,rk3066-smp
- socionext,milbeaut-m10v-smp
- ste,dbx500-smp
- ti,am3352
- ti,am4372
cpu-release-addr:
$ref: '/schemas/types.yaml#/definitions/uint64'
@ -287,6 +300,39 @@ properties:
While optional, it is the preferred way to get access to
the cpu-core power-domains.
secondary-boot-reg:
$ref: '/schemas/types.yaml#/definitions/uint32'
description: |
Required for systems that have an "enable-method" property value of
"brcm,bcm11351-cpu-method", "brcm,bcm23550" or "brcm,bcm-nsp-smp".
This includes the following SoCs: |
BCM11130, BCM11140, BCM11351, BCM28145, BCM28155, BCM21664, BCM23550
BCM58522, BCM58525, BCM58535, BCM58622, BCM58623, BCM58625, BCM88312
The secondary-boot-reg property is a u32 value that specifies the
physical address of the register used to request the ROM holding pen
code release a secondary CPU. The value written to the register is
formed by encoding the target CPU id into the low bits of the
physical start address it should jump to.
if:
# If the enable-method property contains one of those values
properties:
enable-method:
contains:
enum:
- brcm,bcm11351-cpu-method
- brcm,bcm23550
- brcm,bcm-nsp-smp
# and if enable-method is present
required:
- enable-method
then:
required:
- secondary-boot-reg
required:
- device_type
- reg

18
Documentation/devicetree/bindings/arm/freescale/fsl,scu.txt
View File

@ -164,7 +164,18 @@ Required properties:
- compatible: should be:
"fsl,imx8qxp-sc-key"
followed by "fsl,imx-sc-key";
- linux,keycodes: See Documentation/devicetree/bindings/input/keys.txt
- linux,keycodes: See Documentation/devicetree/bindings/input/input.yaml
Thermal bindings based on SCU Message Protocol
------------------------------------------------------------
Required properties:
- compatible: Should be :
"fsl,imx8qxp-sc-thermal"
followed by "fsl,imx-sc-thermal";
- #thermal-sensor-cells: See Documentation/devicetree/bindings/thermal/thermal.txt
for a description.
Example (imx8qxp):
-------------
@ -238,6 +249,11 @@ firmware {
compatible = "fsl,imx8qxp-sc-wdt", "fsl,imx-sc-wdt";
timeout-sec = <60>;
};
tsens: thermal-sensor {
compatible = "fsl,imx8qxp-sc-thermal", "fsl,imx-sc-thermal";
#thermal-sensor-cells = <1>;
};
};
};

69
Documentation/devicetree/bindings/arm/fsl.yaml
View File

@ -119,6 +119,10 @@ properties:
- fsl,imx6q-sabreauto
- fsl,imx6q-sabrelite
- fsl,imx6q-sabresd
- technexion,imx6q-pico-dwarf # TechNexion i.MX6Q Pico-Dwarf
- technexion,imx6q-pico-hobbit # TechNexion i.MX6Q Pico-Hobbit
- technexion,imx6q-pico-nymph # TechNexion i.MX6Q Pico-Nymph
- technexion,imx6q-pico-pi # TechNexion i.MX6Q Pico-Pi
- technologic,imx6q-ts4900
- technologic,imx6q-ts7970
- toradex,apalis_imx6q # Apalis iMX6 Module
@ -166,6 +170,10 @@ properties:
- emtrion,emcon-mx6-avari # emCON-MX6S or emCON-MX6DL SoM on Avari Base
- fsl,imx6dl-sabreauto # i.MX6 DualLite/Solo SABRE Automotive Board
- fsl,imx6dl-sabresd # i.MX6 DualLite SABRE Smart Device Board
- technexion,imx6dl-pico-dwarf # TechNexion i.MX6DL Pico-Dwarf
- technexion,imx6dl-pico-hobbit # TechNexion i.MX6DL Pico-Hobbit
- technexion,imx6dl-pico-nymph # TechNexion i.MX6DL Pico-Nymph
- technexion,imx6dl-pico-pi # TechNexion i.MX6DL Pico-Pi
- technologic,imx6dl-ts4900
- technologic,imx6dl-ts7970
- toradex,colibri_imx6dl # Colibri iMX6 Module
@ -225,6 +233,9 @@ properties:
- fsl,imx6ul-14x14-evk # i.MX6 UltraLite 14x14 EVK Board
- kontron,imx6ul-n6310-som # Kontron N6310 SOM
- kontron,imx6ul-n6311-som # Kontron N6311 SOM
- technexion,imx6ul-pico-dwarf # TechNexion i.MX6UL Pico-Dwarf
- technexion,imx6ul-pico-hobbit # TechNexion i.MX6UL Pico-Hobbit
- technexion,imx6ul-pico-pi # TechNexion i.MX6UL Pico-Pi
- const: fsl,imx6ul
- description: Kontron N6310 S Board
@ -274,6 +285,7 @@ properties:
items:
- enum:
- toradex,colibri-imx7s # Colibri iMX7 Solo Module
- toradex,colibri-imx7s-aster # Colibri iMX7 Solo Module on Aster Carrier Board
- toradex,colibri-imx7s-eval-v3 # Colibri iMX7 Solo Module on Colibri Evaluation Board V3
- tq,imx7s-mba7 # i.MX7S TQ MBa7 with TQMa7S SoM
- const: fsl,imx7s
@ -284,8 +296,14 @@ properties:
- fsl,imx7d-sdb # i.MX7 SabreSD Board
- fsl,imx7d-sdb-reva # i.MX7 SabreSD Rev-A Board
- novtech,imx7d-meerkat96 # i.MX7 Meerkat96 Board
- technexion,imx7d-pico-dwarf # TechNexion i.MX7D Pico-Dwarf
- technexion,imx7d-pico-hobbit # TechNexion i.MX7D Pico-Hobbit
- technexion,imx7d-pico-nymph # TechNexion i.MX7D Pico-Nymph
- technexion,imx7d-pico-pi # TechNexion i.MX7D Pico-Pi
- toradex,colibri-imx7d # Colibri iMX7 Dual Module
- toradex,colibri-imx7d-aster # Colibri iMX7 Dual Module on Aster Carrier Board
- toradex,colibri-imx7d-emmc # Colibri iMX7 Dual 1GB (eMMC) Module
- toradex,colibri-imx7d-emmc-aster # Colibri iMX7 Dual 1GB (eMMC) Module on Aster Carrier Board
- toradex,colibri-imx7d-emmc-eval-v3 # Colibri iMX7 Dual 1GB (eMMC) Module on Colibri Evaluation Board V3
- toradex,colibri-imx7d-eval-v3 # Colibri iMX7 Dual Module on Colibri Evaluation Board V3
- tq,imx7d-mba7 # i.MX7D TQ MBa7 with TQMa7D SoM
@ -324,6 +342,12 @@ properties:
- fsl,imx8mn-evk # i.MX8MN LPDDR4 EVK Board
- const: fsl,imx8mn
- description: i.MX8MP based Boards
items:
- enum:
- fsl,imx8mp-evk # i.MX8MP EVK Board
- const: fsl,imx8mp
- description: i.MX8MQ based Boards
items:
- enum:
@ -395,6 +419,51 @@ properties:
- fsl,ls1021a-twr
- const: fsl,ls1021a
- description: LS1028A based Boards
items:
- enum:
- fsl,ls1028a-qds
- fsl,ls1028a-rdb
- const: fsl,ls1028a
- description: Kontron KBox A-230-LS
items:
- const: kontron,kbox-a-230-ls
- const: kontron,sl28-var4
- const: kontron,sl28
- const: fsl,ls1028a
- description:
Kontron SMARC-sAL28 board on the SMARC Eval Carrier 2.0
items:
- enum:
- kontron,sl28-var2-ads2
- kontron,sl28-var3-ads2
- kontron,sl28-var4-ads2
- enum:
- kontron,sl28-var2
- kontron,sl28-var3
- kontron,sl28-var4
- const: kontron,sl28
- const: fsl,ls1028a
- description:
Kontron SMARC-sAL28 board (on a generic/undefined carrier)
items:
- enum:
- kontron,sl28-var2
- kontron,sl28-var3
- kontron,sl28-var4
- const: kontron,sl28
- const: fsl,ls1028a
- description:
Kontron SMARC-sAL28 board (base). This is used in the base device
tree which is compatible with the overlays provided by the
vendor.
items:
- const: kontron,sl28
- const: fsl,ls1028a
- description: LS1043A based Boards
items:
- enum:

7
Documentation/devicetree/bindings/arm/l2c2x0.yaml
View File

@ -29,7 +29,8 @@ allOf:
properties:
compatible:
enum:
oneOf:
- enum:
- arm,pl310-cache
- arm,l220-cache
- arm,l210-cache
@ -47,9 +48,11 @@ properties:
# Marvell Controller designed to be
# compatible with the ARM one with outer cache mode.
- marvell,aurora-outer-cache
- items:
# Marvell Tauros3 cache controller, compatible
# with arm,pl310-cache controller.
- marvell,tauros3-cache
- const: marvell,tauros3-cache
- const: arm,pl310-cache
cache-level:
const: 2

5
Documentation/devicetree/bindings/arm/mrvl/mrvl.yaml
View File

@ -28,8 +28,11 @@ properties:
items:
- enum:
- mrvl,mmp2-brownstone
- olpc,xo-1.75
- const: mrvl,mmp2
- description: MMP3 based boards
items:
- const: mrvl,mmp3
- enum:
- dell,wyse-ariel
- const: marvell,mmp3
...

2
Documentation/devicetree/bindings/arm/msm/qcom,llcc.yaml
View File

@ -43,6 +43,8 @@ required:
- reg-names
- interrupts
additionalProperties: false
examples:
- |
#include <dt-bindings/interrupt-controller/arm-gic.h>

41
Documentation/devicetree/bindings/arm/pmu.yaml
View File

@ -20,27 +20,36 @@ properties:
items:
- enum:
- apm,potenza-pmu
- arm,armv8-pmuv3
- arm,cortex-a73-pmu
- arm,cortex-a72-pmu
- arm,cortex-a57-pmu
- arm,cortex-a53-pmu
- arm,cortex-a35-pmu
- arm,cortex-a17-pmu
- arm,cortex-a15-pmu
- arm,cortex-a12-pmu
- arm,cortex-a9-pmu
- arm,cortex-a8-pmu
- arm,cortex-a7-pmu
- arm,cortex-a5-pmu
- arm,arm11mpcore-pmu
- arm,arm1176-pmu
- arm,armv8-pmuv3 # Only for s/w models
- arm,arm1136-pmu
- arm,arm1176-pmu
- arm,arm11mpcore-pmu
- arm,cortex-a5-pmu
- arm,cortex-a7-pmu
- arm,cortex-a8-pmu
- arm,cortex-a9-pmu
- arm,cortex-a12-pmu
- arm,cortex-a15-pmu
- arm,cortex-a17-pmu
- arm,cortex-a32-pmu
- arm,cortex-a34-pmu
- arm,cortex-a35-pmu
- arm,cortex-a53-pmu
- arm,cortex-a55-pmu
- arm,cortex-a57-pmu
- arm,cortex-a65-pmu
- arm,cortex-a72-pmu
- arm,cortex-a73-pmu
- arm,cortex-a75-pmu
- arm,cortex-a76-pmu
- arm,cortex-a77-pmu
- arm,neoverse-e1-pmu
- arm,neoverse-n1-pmu
- brcm,vulcan-pmu
- cavium,thunder-pmu
- qcom,krait-pmu
- qcom,scorpion-pmu
- qcom,scorpion-mp-pmu
- qcom,krait-pmu
interrupts:
# Don't know how many CPUs, so no constraints to specify

5
Documentation/devicetree/bindings/arm/psci.yaml
View File

@ -32,6 +32,9 @@ description: |+
http://infocenter.arm.com/help/topic/com.arm.doc.den0022c/DEN0022C_Power_State_Coordination_Interface.pdf
properties:
$nodename:
const: psci
compatible:
oneOf:
- description:
@ -141,6 +144,8 @@ allOf:
- cpu_off
- cpu_on
additionalProperties: false
examples:
- |+

8
Documentation/devicetree/bindings/arm/qcom.yaml
View File

@ -28,6 +28,7 @@ description: |
apq8074
apq8084
apq8096
ipq6018
ipq8074
mdm9615
msm8916
@ -41,6 +42,7 @@ description: |
The 'board' element must be one of the following strings:
cdp
cp01-c1
dragonboard
hk01
idp
@ -150,4 +152,10 @@ properties:
- enum:
- qcom,sc7180-idp
- const: qcom,sc7180
- items:
- enum:
- qcom,ipq6018-cp01-c1
- const: qcom,ipq6018
...

2
Documentation/devicetree/bindings/arm/renesas,prr.yaml
View File

@ -27,6 +27,8 @@ required:
- compatible
- reg
additionalProperties: false
examples:
- |
prr: chipid@ff000044 {

1
Documentation/devicetree/bindings/arm/renesas.yaml
View File

@ -208,6 +208,7 @@ properties:
- description: R-Car M3-W+ (R8A77961)
items:
- enum:
- renesas,m3ulcb # M3ULCB (R-Car Starter Kit Pro, RTP8J77961ASKB0SK0SA05A (M3 ES3.0))
- renesas,salvator-xs # Salvator-XS (Salvator-X 2nd version, RTP0RC7796SIPB0012SA5A)
- const: renesas,r8a77961

12
Documentation/devicetree/bindings/arm/rockchip.yaml
View File

@ -402,6 +402,11 @@ properties:
- const: phytec,rk3288-phycore-som
- const: rockchip,rk3288
- description: Pine64 PinebookPro
items:
- const: pine64,pinebook-pro
- const: rockchip,rk3399
- description: Pine64 Rock64
items:
- const: pine64,rock64
@ -443,7 +448,7 @@ properties:
- description: Rockchip Kylin
items:
- const: rockchip,kylin-rk3036
- const: rockchip,rk3036-kylin
- const: rockchip,rk3036
- description: Rockchip PX3 Evaluation board
@ -468,6 +473,11 @@ properties:
- const: rockchip,r88
- const: rockchip,rk3368
- description: Rockchip RK3036 Evaluation board
items:
- const: rockchip,rk3036-evb
- const: rockchip,rk3036
- description: Rockchip RK3228 Evaluation board
items:
- const: rockchip,rk3228-evb

2
Documentation/devicetree/bindings/arm/samsung/exynos-chipid.yaml
View File

@ -30,6 +30,8 @@ required:
- compatible
- reg
additionalProperties: false
examples:
- |
chipid@10000000 {

2
Documentation/devicetree/bindings/arm/samsung/pmu.yaml
View File

@ -89,6 +89,8 @@ required:
- clock-names
- clocks
additionalProperties: false
examples:
- |
#include <dt-bindings/clock/exynos5250.h>

2
Documentation/devicetree/bindings/arm/samsung/samsung-secure-firmware.yaml
View File

@ -23,6 +23,8 @@ required:
- compatible
- reg
additionalProperties: false
examples:
- |
firmware@203f000 {

60
Documentation/devicetree/bindings/arm/socionext/cache-uniphier.txt
View File

@ -1,60 +0,0 @@
UniPhier outer cache controller
UniPhier SoCs are integrated with a full-custom outer cache controller system.
All of them have a level 2 cache controller, and some have a level 3 cache
controller as well.
Required properties:
- compatible: should be "socionext,uniphier-system-cache"
- reg: offsets and lengths of the register sets for the device. It should
contain 3 regions: control register, revision register, operation register,
in this order.
- cache-unified: specifies the cache is a unified cache.
- cache-size: specifies the size in bytes of the cache
- cache-sets: specifies the number of associativity sets of the cache
- cache-line-size: specifies the line size in bytes
- cache-level: specifies the level in the cache hierarchy. The value should
be 2 for L2 cache, 3 for L3 cache, etc.
Optional properties:
- next-level-cache: phandle to the next level cache if present. The next level
cache should be also compatible with "socionext,uniphier-system-cache".
The L2 cache must exist to use the L3 cache; the cache hierarchy must be
indicated correctly with "next-level-cache" properties.
Example 1 (system with L2):
l2: l2-cache@500c0000 {
compatible = "socionext,uniphier-system-cache";
reg = <0x500c0000 0x2000>, <0x503c0100 0x4>,
<0x506c0000 0x400>;
cache-unified;
cache-size = <0x80000>;
cache-sets = <256>;
cache-line-size = <128>;
cache-level = <2>;
};
Example 2 (system with L2 and L3):
l2: l2-cache@500c0000 {
compatible = "socionext,uniphier-system-cache";
reg = <0x500c0000 0x2000>, <0x503c0100 0x8>,
<0x506c0000 0x400>;
cache-unified;
cache-size = <0x200000>;
cache-sets = <512>;
cache-line-size = <128>;
cache-level = <2>;
next-level-cache = <&l3>;
};
l3: l3-cache@500c8000 {
compatible = "socionext,uniphier-system-cache";
reg = <0x500c8000 0x2000>, <0x503c8100 0x8>,
<0x506c8000 0x400>;
cache-unified;
cache-size = <0x400000>;
cache-sets = <512>;
cache-line-size = <256>;
cache-level = <3>;
};

102
Documentation/devicetree/bindings/arm/socionext/socionext,uniphier-system-cache.yaml Normal file
View File

@ -0,0 +1,102 @@
# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
%YAML 1.2
---
$id: http://devicetree.org/schemas/arm/socionext/socionext,uniphier-system-cache.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: UniPhier outer cache controller
description: |
UniPhier ARM 32-bit SoCs are integrated with a full-custom outer cache
controller system. All of them have a level 2 cache controller, and some
have a level 3 cache controller as well.
maintainers:
- Masahiro Yamada <yamada.masahiro@socionext.com>
properties:
compatible:
const: socionext,uniphier-system-cache
reg:
description: |
should contain 3 regions: control register, revision register,
operation register, in this order.
minItems: 3
maxItems: 3
interrupts:
description: |
Interrupts can be used to notify the completion of cache operations.
The number of interrupts should match to the number of CPU cores.
The specified interrupts correspond to CPU0, CPU1, ... in this order.
minItems: 1
maxItems: 4
cache-unified: true
cache-size: true
cache-sets: true
cache-line-size: true
cache-level:
minimum: 2
maximum: 3
next-level-cache: true
allOf:
- $ref: /schemas/cache-controller.yaml#
additionalProperties: false
required:
- compatible
- reg
- interrupts
- cache-unified
- cache-size
- cache-sets
- cache-line-size
- cache-level
examples:
- |
// System with L2.
cache-controller@500c0000 {
compatible = "socionext,uniphier-system-cache";
reg = <0x500c0000 0x2000>, <0x503c0100 0x4>, <0x506c0000 0x400>;
interrupts = <0 174 4>, <0 175 4>, <0 190 4>, <0 191 4>;
cache-unified;
cache-size = <0x140000>;
cache-sets = <512>;
cache-line-size = <128>;
cache-level = <2>;
};
- |
// System with L2 and L3.
// L2 should specify the next level cache by 'next-level-cache'.
l2: cache-controller@500c0000 {
compatible = "socionext,uniphier-system-cache";
reg = <0x500c0000 0x2000>, <0x503c0100 0x8>, <0x506c0000 0x400>;
interrupts = <0 190 4>, <0 191 4>;
cache-unified;
cache-size = <0x200000>;
cache-sets = <512>;
cache-line-size = <128>;
cache-level = <2>;
next-level-cache = <&l3>;
};
l3: cache-controller@500c8000 {
compatible = "socionext,uniphier-system-cache";
reg = <0x500c8000 0x2000>, <0x503c8100 0x8>, <0x506c8000 0x400>;
interrupts = <0 174 4>, <0 175 4>;
cache-unified;
cache-size = <0x200000>;
cache-sets = <512>;
cache-line-size = <256>;
cache-level = <3>;
};

47
Documentation/devicetree/bindings/arm/socionext/uniphier.txt
View File

@ -1,47 +0,0 @@
Socionext UniPhier SoC family
-----------------------------
Required properties in the root node:
- compatible: should contain board and SoC compatible strings
SoC and board compatible strings:
(sorted chronologically)
- LD4 SoC: "socionext,uniphier-ld4"
- Reference Board: "socionext,uniphier-ld4-ref"
- Pro4 SoC: "socionext,uniphier-pro4"
- Reference Board: "socionext,uniphier-pro4-ref"
- Ace Board: "socionext,uniphier-pro4-ace"
- Sanji Board: "socionext,uniphier-pro4-sanji"
- sLD8 SoC: "socionext,uniphier-sld8"
- Reference Board: "socionext,uniphier-sld8-ref"
- PXs2 SoC: "socionext,uniphier-pxs2"
- Gentil Board: "socionext,uniphier-pxs2-gentil"
- Vodka Board: "socionext,uniphier-pxs2-vodka"
- LD6b SoC: "socionext,uniphier-ld6b"
- Reference Board: "socionext,uniphier-ld6b-ref"
- LD11 SoC: "socionext,uniphier-ld11"
- Reference Board: "socionext,uniphier-ld11-ref"
- Global Board: "socionext,uniphier-ld11-global"
- LD20 SoC: "socionext,uniphier-ld20"
- Reference Board: "socionext,uniphier-ld20-ref"
- Global Board: "socionext,uniphier-ld20-global"
- PXs3 SoC: "socionext,uniphier-pxs3"
- Reference Board: "socionext,uniphier-pxs3-ref"
Example:
/dts-v1/;
/ {
compatible = "socionext,uniphier-ld20-ref", "socionext,uniphier-ld20";
...
};

61
Documentation/devicetree/bindings/arm/socionext/uniphier.yaml Normal file
View File

@ -0,0 +1,61 @@
# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
%YAML 1.2
---
$id: http://devicetree.org/schemas/arm/socionext/uniphier.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Socionext UniPhier platform device tree bindings
maintainers:
- Masahiro Yamada <yamada.masahiro@socionext.com>
properties:
$nodename:
const: /
compatible:
oneOf:
- description: LD4 SoC boards
items:
- enum:
- socionext,uniphier-ld4-ref
- const: socionext,uniphier-ld4
- description: Pro4 SoC boards
items:
- enum:
- socionext,uniphier-pro4-ace
- socionext,uniphier-pro4-ref
- socionext,uniphier-pro4-sanji
- const: socionext,uniphier-pro4
- description: sLD8 SoC boards
items:
- enum:
- socionext,uniphier-sld8-ref
- const: socionext,uniphier-sld8
- description: PXs2 SoC boards
items:
- enum:
- socionext,uniphier-pxs2-gentil
- socionext,uniphier-pxs2-vodka
- const: socionext,uniphier-pxs2
- description: LD6b SoC boards
items:
- enum:
- socionext,uniphier-ld6b-ref
- const: socionext,uniphier-ld6b
- description: LD11 SoC boards
items:
- enum:
- socionext,uniphier-ld11-global
- socionext,uniphier-ld11-ref
- const: socionext,uniphier-ld11
- description: LD20 SoC boards
items:
- enum:
- socionext,uniphier-ld20-global
- socionext,uniphier-ld20-ref
- const: socionext,uniphier-ld20
- description: PXs3 SoC boards
items:
- enum:
- socionext,uniphier-pxs3-ref
- const: socionext,uniphier-pxs3

2
Documentation/devicetree/bindings/arm/stm32/st,stm32-syscon.yaml
View File

@ -29,6 +29,8 @@ required:
- reg
- clocks
additionalProperties: false
examples:
- |
#include <dt-bindings/clock/stm32mp1-clks.h>

26
Documentation/devicetree/bindings/arm/sunxi.yaml
View File

@ -394,6 +394,12 @@ properties:
- const: linksprite,pcduino3-nano
- const: allwinner,sun7i-a20
- description: Linutronix Testbox v2
items:
- const: linutronix,testbox-v2
- const: lamobo,lamobo-r1
- const: allwinner,sun7i-a20
- description: HAOYU Electronics Marsboard A10
items:
- const: haoyu,a10-marsboard
@ -636,6 +642,21 @@ properties:
- const: pine64,pinebook
- const: allwinner,sun50i-a64
- description: Pine64 PinePhone Developer Batch (1.0)
items:
- const: pine64,pinephone-1.0
- const: allwinner,sun50i-a64
- description: Pine64 PinePhone Braveheart (1.1)
items:
- const: pine64,pinephone-1.1
- const: allwinner,sun50i-a64
- description: Pine64 PineTab
items:
- const: pine64,pinetab
- const: allwinner,sun50i-a64
- description: Pine64 SoPine Baseboard
items:
- const: pine64,sopine-baseboard
@ -647,6 +668,11 @@ properties:
- const: pineriver,mini-xplus
- const: allwinner,sun4i-a10
- description: PocketBook Touch Lux 3
items:
- const: pocketbook,touch-lux-3
- const: allwinner,sun5i-a13
- description: Point of View Protab2-IPS9
items:
- const: pov,protab2-ips9

7
Documentation/devicetree/bindings/arm/sunxi/allwinner,sun4i-a10-mbus.yaml
View File

@ -30,6 +30,7 @@ properties:
enum:
- allwinner,sun5i-a13-mbus
- allwinner,sun8i-h3-mbus
- allwinner,sun50i-a64-mbus
reg:
maxItems: 1
@ -41,6 +42,10 @@ properties:
description:
See section 2.3.9 of the DeviceTree Specification.
'#address-cells': true
'#size-cells': true
required:
- "#interconnect-cells"
- compatible
@ -58,6 +63,8 @@ examples:
compatible = "allwinner,sun5i-a13-mbus";
reg = <0x01c01000 0x1000>;
clocks = <&ccu CLK_MBUS>;
#address-cells = <1>;
#size-cells = <1>;
dma-ranges = <0x00000000 0x40000000 0x20000000>;
#interconnect-cells = <1>;
};

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

@ -1,300 +0,0 @@
NVIDIA Tegra Power Management Controller (PMC)
== Power Management Controller Node ==
The PMC block interacts with an external Power Management Unit. The PMC
mostly controls the entry and exit of the system from different sleep
modes. It provides power-gating controllers for SoC and CPU power-islands.
Required properties:
- name : Should be pmc
- compatible : Should contain one of the following:
For Tegra20 must contain "nvidia,tegra20-pmc".
For Tegra30 must contain "nvidia,tegra30-pmc".
For Tegra114 must contain "nvidia,tegra114-pmc"
For Tegra124 must contain "nvidia,tegra124-pmc"
For Tegra132 must contain "nvidia,tegra124-pmc"
For Tegra210 must contain "nvidia,tegra210-pmc"
- reg : Offset and length of the register set for the device
- clocks : Must contain an entry for each entry in clock-names.
See ../clocks/clock-bindings.txt for details.
- clock-names : Must include the following entries:
"pclk" (The Tegra clock of that name),
"clk32k_in" (The 32KHz clock input to Tegra).
Optional properties:
- nvidia,invert-interrupt : If present, inverts the PMU interrupt signal.
The PMU is an external Power Management Unit, whose interrupt output
signal is fed into the PMC. This signal is optionally inverted, and then
fed into the ARM GIC. The PMC is not involved in the detection or
handling of this interrupt signal, merely its inversion.
- nvidia,suspend-mode : The suspend mode that the platform should use.
Valid values are 0, 1 and 2:
0 (LP0): CPU + Core voltage off and DRAM in self-refresh
1 (LP1): CPU voltage off and DRAM in self-refresh
2 (LP2): CPU voltage off
- nvidia,core-power-req-active-high : Boolean, core power request active-high
- nvidia,sys-clock-req-active-high : Boolean, system clock request active-high
- nvidia,combined-power-req : Boolean, combined power request for CPU & Core
- nvidia,cpu-pwr-good-en : Boolean, CPU power good signal (from PMIC to PMC)
is enabled.
Required properties when nvidia,suspend-mode is specified:
- nvidia,cpu-pwr-good-time : CPU power good time in uS.
- nvidia,cpu-pwr-off-time : CPU power off time in uS.
- nvidia,core-pwr-good-time : <Oscillator-stable-time Power-stable-time>
Core power good time in uS.
- nvidia,core-pwr-off-time : Core power off time in uS.
Required properties when nvidia,suspend-mode=<0>:
- nvidia,lp0-vec : <start length> Starting address and length of LP0 vector
The LP0 vector contains the warm boot code that is executed by AVP when
resuming from the LP0 state. The AVP (Audio-Video Processor) is an ARM7
processor and always being the first boot processor when chip is power on
or resume from deep sleep mode. When the system is resumed from the deep
sleep mode, the warm boot code will restore some PLLs, clocks and then
bring up CPU0 for resuming the system.
Hardware-triggered thermal reset:
On Tegra30, Tegra114 and Tegra124, if the 'i2c-thermtrip' subnode exists,
hardware-triggered thermal reset will be enabled.
Required properties for hardware-triggered thermal reset (inside 'i2c-thermtrip'):
- nvidia,i2c-controller-id : ID of I2C controller to send poweroff command to. Valid values are
described in section 9.2.148 "APBDEV_PMC_SCRATCH53_0" of the
Tegra K1 Technical Reference Manual.
- nvidia,bus-addr : Bus address of the PMU on the I2C bus
- nvidia,reg-addr : I2C register address to write poweroff command to
- nvidia,reg-data : Poweroff command to write to PMU
Optional properties for hardware-triggered thermal reset (inside 'i2c-thermtrip'):
- nvidia,pinmux-id : Pinmux used by the hardware when issuing poweroff command.
Defaults to 0. Valid values are described in section 12.5.2
"Pinmux Support" of the Tegra4 Technical Reference Manual.
Optional nodes:
- powergates : This node contains a hierarchy of power domain nodes, which
should match the powergates on the Tegra SoC. See "Powergate
Nodes" below.
Example:
/ SoC dts including file
pmc@7000f400 {
compatible = "nvidia,tegra20-pmc";
reg = <0x7000e400 0x400>;
clocks = <&tegra_car 110>, <&clk32k_in>;
clock-names = "pclk", "clk32k_in";
nvidia,invert-interrupt;
nvidia,suspend-mode = <1>;
nvidia,cpu-pwr-good-time = <2000>;
nvidia,cpu-pwr-off-time = <100>;
nvidia,core-pwr-good-time = <3845 3845>;
nvidia,core-pwr-off-time = <458>;
nvidia,core-power-req-active-high;
nvidia,sys-clock-req-active-high;
nvidia,lp0-vec = <0xbdffd000 0x2000>;
};
/ Tegra board dts file
{
...
pmc@7000f400 {
i2c-thermtrip {
nvidia,i2c-controller-id = <4>;
nvidia,bus-addr = <0x40>;
nvidia,reg-addr = <0x36>;
nvidia,reg-data = <0x2>;
};
};
...
clocks {
compatible = "simple-bus";
#address-cells = <1>;
#size-cells = <0>;
clk32k_in: clock {
compatible = "fixed-clock";
reg=<0>;
#clock-cells = <0>;
clock-frequency = <32768>;
};
};
...
};
== Powergate Nodes ==
Each of the powergate nodes represents a power-domain on the Tegra SoC
that can be power-gated by the Tegra PMC. The name of the powergate node
should be one of the below. Note that not every powergate is applicable
to all Tegra devices and the following list shows which powergates are
applicable to which devices. Please refer to the Tegra TRM for more
details on the various powergates.
Name Description Devices Applicable
3d 3D Graphics Tegra20/114/124/210
3d0 3D Graphics 0 Tegra30
3d1 3D Graphics 1 Tegra30
aud Audio Tegra210
dfd Debug Tegra210
dis Display A Tegra114/124/210
disb Display B Tegra114/124/210
heg 2D Graphics Tegra30/114/124/210
iram Internal RAM Tegra124/210
mpe MPEG Encode All
nvdec NVIDIA Video Decode Engine Tegra210
nvjpg NVIDIA JPEG Engine Tegra210
pcie PCIE Tegra20/30/124/210
sata SATA Tegra30/124/210
sor Display interfaces Tegra124/210
ve2 Video Encode Engine 2 Tegra210
venc Video Encode Engine All
vdec Video Decode Engine Tegra20/30/114/124
vic Video Imaging Compositor Tegra124/210
xusba USB Partition A Tegra114/124/210
xusbb USB Partition B Tegra114/124/210
xusbc USB Partition C Tegra114/124/210
Required properties:
- clocks: Must contain an entry for each clock required by the PMC for
controlling a power-gate. See ../clocks/clock-bindings.txt for details.
- resets: Must contain an entry for each reset required by the PMC for
controlling a power-gate. See ../reset/reset.txt for details.
- #power-domain-cells: Must be 0.
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";
powergates {
pd_audio: aud {
clocks = <&tegra_car TEGRA210_CLK_APE>,
<&tegra_car TEGRA210_CLK_APB2APE>;
resets = <&tegra_car 198>;
#power-domain-cells = <0>;
};
};
};
== Powergate Clients ==
Hardware blocks belonging to a power domain should contain a "power-domains"
property that is a phandle pointing to the corresponding powergate node.
Example:
adma: adma@702e2000 {
...
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";
};

354
Documentation/devicetree/bindings/arm/tegra/nvidia,tegra20-pmc.yaml Normal file
View File

@ -0,0 +1,354 @@
# SPDX-License-Identifier: GPL-2.0
%YAML 1.2
---
$id: http://devicetree.org/schemas/arm/tegra/nvidia,tegra20-pmc.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Tegra Power Management Controller (PMC)
maintainers:
- Thierry Reding <thierry.reding@gmail.com>
- Jonathan Hunter <jonathanh@nvidia.com>
properties:
compatible:
enum:
- nvidia,tegra20-pmc
- nvidia,tegra20-pmc
- nvidia,tegra30-pmc
- nvidia,tegra114-pmc
- nvidia,tegra124-pmc
- nvidia,tegra210-pmc
reg:
maxItems: 1
description:
Offset and length of the register set for the device.
clock-names:
items:
- const: pclk
- const: clk32k_in
description:
Must includes entries pclk and clk32k_in.
pclk is the Tegra clock of that name and clk32k_in is 32KHz clock
input to Tegra.
clocks:
maxItems: 2
description:
Must contain an entry for each entry in clock-names.
See ../clocks/clocks-bindings.txt for details.
'#clock-cells':
const: 1
description:
Tegra PMC has clk_out_1, clk_out_2, and clk_out_3.
PMC also has blink control which allows 32Khz clock output to
Tegra blink pad.
Consumer of PMC clock should specify the desired clock by having
the clock ID in its "clocks" phandle cell with pmc clock provider.
See include/dt-bindings/soc/tegra-pmc.h for the list of Tegra PMC
clock IDs.
'#interrupt-cells':
const: 2
description:
Specifies number of cells needed to encode an interrupt source.
The value must be 2.
interrupt-controller: true
nvidia,invert-interrupt:
$ref: /schemas/types.yaml#/definitions/flag
description: Inverts the PMU interrupt signal.
The PMU is an external Power Management Unit, whose interrupt output
signal is fed into the PMC. This signal is optionally inverted, and
then fed into the ARM GIC. The PMC is not involved in the detection
or handling of this interrupt signal, merely its inversion.
nvidia,core-power-req-active-high:
$ref: /schemas/types.yaml#/definitions/flag
description: Core power request active-high.
nvidia,sys-clock-req-active-high:
$ref: /schemas/types.yaml#/definitions/flag
description: System clock request active-high.
nvidia,combined-power-req:
$ref: /schemas/types.yaml#/definitions/flag
description: combined power request for CPU and Core.
nvidia,cpu-pwr-good-en:
$ref: /schemas/types.yaml#/definitions/flag
description:
CPU power good signal from external PMIC to PMC is enabled.
nvidia,suspend-mode:
allOf:
- $ref: /schemas/types.yaml#/definitions/uint32
- enum: [0, 1, 2]
description:
The suspend mode that the platform should use.
Mode 0 is for LP0, CPU + Core voltage off and DRAM in self-refresh
Mode 1 is for LP1, CPU voltage off and DRAM in self-refresh
Mode 2 is for LP2, CPU voltage off
nvidia,cpu-pwr-good-time:
$ref: /schemas/types.yaml#/definitions/uint32
description: CPU power good time in uSec.
nvidia,cpu-pwr-off-time:
$ref: /schemas/types.yaml#/definitions/uint32
description: CPU power off time in uSec.
nvidia,core-pwr-good-time:
$ref: /schemas/types.yaml#/definitions/uint32-array
description:
<Oscillator-stable-time Power-stable-time>
Core power good time in uSec.
nvidia,core-pwr-off-time:
$ref: /schemas/types.yaml#/definitions/uint32
description: Core power off time in uSec.
nvidia,lp0-vec:
$ref: /schemas/types.yaml#/definitions/uint32-array
description:
<start length> Starting address and length of LP0 vector.
The LP0 vector contains the warm boot code that is executed
by AVP when resuming from the LP0 state.
The AVP (Audio-Video Processor) is an ARM7 processor and
always being the first boot processor when chip is power on
or resume from deep sleep mode. When the system is resumed
from the deep sleep mode, the warm boot code will restore
some PLLs, clocks and then brings up CPU0 for resuming the
system.
i2c-thermtrip:
type: object
description:
On Tegra30, Tegra114 and Tegra124 if i2c-thermtrip subnode exists,
hardware-triggered thermal reset will be enabled.
properties:
nvidia,i2c-controller-id:
$ref: /schemas/types.yaml#/definitions/uint32
description:
ID of I2C controller to send poweroff command to PMU.
Valid values are described in section 9.2.148
"APBDEV_PMC_SCRATCH53_0" of the Tegra K1 Technical Reference
Manual.
nvidia,bus-addr:
$ref: /schemas/types.yaml#/definitions/uint32
description: Bus address of the PMU on the I2C bus.
nvidia,reg-addr:
$ref: /schemas/types.yaml#/definitions/uint32
description: PMU I2C register address to issue poweroff command.
nvidia,reg-data:
$ref: /schemas/types.yaml#/definitions/uint32
description: Poweroff command to write to PMU.
nvidia,pinmux-id:
$ref: /schemas/types.yaml#/definitions/uint32
description:
Pinmux used by the hardware when issuing Poweroff command.
Defaults to 0. Valid values are described in section 12.5.2
"Pinmux Support" of the Tegra4 Technical Reference Manual.
required:
- nvidia,i2c-controller-id
- nvidia,bus-addr
- nvidia,reg-addr
- nvidia,reg-data
additionalProperties: false
powergates:
type: object
description: |
This node contains a hierarchy of power domain nodes, which should
match the powergates on the Tegra SoC. Each powergate node
represents a power-domain on the Tegra SoC that can be power-gated
by the Tegra PMC.
Hardware blocks belonging to a power domain should contain
"power-domains" property that is a phandle pointing to corresponding
powergate node.
The name of the powergate node should be one of the below. Note that
not every powergate is applicable to all Tegra devices and the following
list shows which powergates are applicable to which devices.
Please refer to Tegra TRM for mode details on the powergate nodes to
use for each power-gate block inside Tegra.
Name Description Devices Applicable
3d 3D Graphics Tegra20/114/124/210
3d0 3D Graphics 0 Tegra30
3d1 3D Graphics 1 Tegra30
aud Audio Tegra210
dfd Debug Tegra210
dis Display A Tegra114/124/210
disb Display B Tegra114/124/210
heg 2D Graphics Tegra30/114/124/210
iram Internal RAM Tegra124/210
mpe MPEG Encode All
nvdec NVIDIA Video Decode Engine Tegra210
nvjpg NVIDIA JPEG Engine Tegra210
pcie PCIE Tegra20/30/124/210
sata SATA Tegra30/124/210
sor Display interfaces Tegra124/210
ve2 Video Encode Engine 2 Tegra210
venc Video Encode Engine All
vdec Video Decode Engine Tegra20/30/114/124
vic Video Imaging Compositor Tegra124/210
xusba USB Partition A Tegra114/124/210
xusbb USB Partition B Tegra114/124/210
xusbc USB Partition C Tegra114/124/210
patternProperties:
"^[a-z0-9]+$":
type: object
patternProperties:
clocks:
minItems: 1
maxItems: 8
description:
Must contain an entry for each clock required by the PMC
for controlling a power-gate.
See ../clocks/clock-bindings.txt document for more details.
resets:
minItems: 1
maxItems: 8
description:
Must contain an entry for each reset required by the PMC
for controlling a power-gate.
See ../reset/reset.txt for more details.
'#power-domain-cells':
const: 0
description: Must be 0.
required:
- clocks
- resets
- '#power-domain-cells'
additionalProperties: false
patternProperties:
"^[a-f0-9]+-[a-f0-9]+$":
type: object
description:
This is a Pad configuration node. 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.3V and 1.8V 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.
properties:
pins:
$ref: /schemas/types.yaml#/definitions/string
description: Must contain name of the pad(s) to be configured.
low-power-enable:
$ref: /schemas/types.yaml#/definitions/flag
description: Configure the pad into power down mode.
low-power-disable:
$ref: /schemas/types.yaml#/definitions/flag
description: Configure the pad into active mode.
power-source:
$ref: /schemas/types.yaml#/definitions/uint32
description:
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.
Power state can be configured on all Tegra124 and Tegra132
pads. None of the Tegra124 or Tegra132 pads support signaling
voltage switching.
All of the listed Tegra210 pads except pex-cntrl support power
state configuration. Signaling voltage switching is supported
on below Tegra210 pads.
audio, audio-hv, cam, dbg, dmic, gpio, pex-cntrl, sdmmc1,
sdmmc3, spi, spi-hv, and uart.
required:
- pins
additionalProperties: false
required:
- compatible
- reg
- clock-names
- clocks
- '#clock-cells'
dependencies:
"nvidia,suspend-mode": ["nvidia,core-pwr-off-time", "nvidia,cpu-pwr-off-time"]
"nvidia,core-pwr-off-time": ["nvidia,core-pwr-good-time"]
"nvidia,cpu-pwr-off-time": ["nvidia,cpu-pwr-good-time"]
examples:
- |
#include <dt-bindings/clock/tegra210-car.h>
#include <dt-bindings/pinctrl/pinctrl-tegra-io-pad.h>
#include <dt-bindings/soc/tegra-pmc.h>
tegra_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";
#clock-cells = <1>;
nvidia,invert-interrupt;
nvidia,suspend-mode = <0>;
nvidia,cpu-pwr-good-time = <0>;
nvidia,cpu-pwr-off-time = <0>;
nvidia,core-pwr-good-time = <4587 3876>;
nvidia,core-pwr-off-time = <39065>;
nvidia,core-power-req-active-high;
nvidia,sys-clock-req-active-high;
powergates {
pd_audio: aud {
clocks = <&tegra_car TEGRA210_CLK_APE>,
<&tegra_car TEGRA210_CLK_APB2APE>;
resets = <&tegra_car 198>;
#power-domain-cells = <0>;
};
pd_xusbss: xusba {
clocks = <&tegra_car TEGRA210_CLK_XUSB_SS>;
resets = <&tegra_car TEGRA210_CLK_XUSB_SS>;
#power-domain-cells = <0>;
};
};
};

229
Documentation/devicetree/bindings/arm/vexpress.txt
View File

@ -1,229 +0,0 @@
ARM Versatile Express boards family
-----------------------------------
ARM's Versatile Express platform consists of a motherboard and one
or more daughterboards (tiles). The motherboard provides a set of
peripherals. Processor and RAM "live" on the tiles.
The motherboard and each core tile should be described by a separate
Device Tree source file, with the tile's description including
the motherboard file using a /include/ directive. As the motherboard
can be initialized in one of two different configurations ("memory
maps"), care must be taken to include the correct one.
Root node
---------
Required properties in the root node:
- compatible value:
compatible = "arm,vexpress,<model>", "arm,vexpress";
where <model> is the full tile model name (as used in the tile's
Technical Reference Manual), eg.:
- for Coretile Express A5x2 (V2P-CA5s):
compatible = "arm,vexpress,v2p-ca5s", "arm,vexpress";
- for Coretile Express A9x4 (V2P-CA9):
compatible = "arm,vexpress,v2p-ca9", "arm,vexpress";
If a tile comes in several variants or can be used in more then one
configuration, the compatible value should be:
compatible = "arm,vexpress,<model>,<variant>", \
"arm,vexpress,<model>", "arm,vexpress";
eg:
- Coretile Express A15x2 (V2P-CA15) with Tech Chip 1:
compatible = "arm,vexpress,v2p-ca15,tc1", \
"arm,vexpress,v2p-ca15", "arm,vexpress";
- LogicTile Express 13MG (V2F-2XV6) running Cortex-A7 (3 cores) SMM:
compatible = "arm,vexpress,v2f-2xv6,ca7x3", \
"arm,vexpress,v2f-2xv6", "arm,vexpress";
Optional properties in the root node:
- tile model name (use name from the tile's Technical Reference
Manual, eg. "V2P-CA5s")
model = "<model>";
- tile's HBI number (unique ARM's board model ID, visible on the
PCB's silkscreen) in hexadecimal transcription:
arm,hbi = <0xhbi>
eg:
- for Coretile Express A5x2 (V2P-CA5s) HBI-0191:
arm,hbi = <0x191>;
- Coretile Express A9x4 (V2P-CA9) HBI-0225:
arm,hbi = <0x225>;
CPU nodes
---------
Top-level standard "cpus" node is required. It must contain a node
with device_type = "cpu" property for every available core, eg.:
cpus {
#address-cells = <1>;
#size-cells = <0>;
cpu@0 {
device_type = "cpu";
compatible = "arm,cortex-a5";
reg = <0>;
};
};
Configuration infrastructure
----------------------------
The platform has an elaborated configuration system, consisting of
microcontrollers residing on the mother- and daughterboards known
as Motherboard/Daughterboard Configuration Controller (MCC and DCC).
The controllers are responsible for the platform initialization
(reset generation, flash programming, FPGA bitfiles loading etc.)
but also control clock generators, voltage regulators, gather
environmental data like temperature, power consumption etc. Even
the video output switch (FPGA) is controlled that way.
The controllers are not mapped into normal memory address space
and must be accessed through bridges - other devices capable
of generating transactions on the configuration bus.
The nodes describing configuration controllers must define
the following properties:
- compatible value:
compatible = "arm,vexpress,config-bus";
- bridge phandle:
arm,vexpress,config-bridge = <phandle>;
and children describing available functions.
Platform topology
-----------------
As Versatile Express can be configured in number of physically
different setups, the device tree should describe platform topology.
Root node and main motherboard node must define the following
property, describing physical location of the children nodes:
- site number:
arm,vexpress,site = <number>;
where 0 means motherboard, 1 or 2 are daugtherboard sites,
0xf means "master" site (site containing main CPU tile)
- when daughterboards are stacked on one site, their position
in the stack be be described with:
arm,vexpress,position = <number>;
- when describing tiles consisting more than one DCC, its number
can be described with:
arm,vexpress,dcc = <number>;
Any of the numbers above defaults to zero if not defined in
the node or any of its parent.
Motherboard
-----------
The motherboard description file provides a single "motherboard" node
using 2 address cells corresponding to the Static Memory Bus used
between the motherboard and the tile. The first cell defines the Chip
Select (CS) line number, the second cell address offset within the CS.
All interrupt lines between the motherboard and the tile are active
high and are described using single cell.
Optional properties of the "motherboard" node:
- motherboard's memory map variant:
arm,v2m-memory-map = "<name>";
where name is one of:
- "rs1" - for RS1 map (i.a. peripherals on CS3); this map is also
referred to as "ARM Cortex-A Series memory map":
arm,v2m-memory-map = "rs1";
When this property is missing, the motherboard is using the original
memory map (also known as the "Legacy memory map", primarily used
with the original CoreTile Express A9x4) with peripherals on CS7.
Motherboard .dtsi files provide a set of labelled peripherals that
can be used to obtain required phandle in the tile's "aliases" node:
- UARTs, note that the numbers correspond to the physical connectors
on the motherboard's back panel:
v2m_serial0, v2m_serial1, v2m_serial2 and v2m_serial3
- I2C controllers:
v2m_i2c_dvi and v2m_i2c_pcie
- SP804 timers:
v2m_timer01 and v2m_timer23
The tile description should define a "smb" node, describing the
Static Memory Bus between the tile and motherboard. It must define
the following properties:
- "simple-bus" compatible value (to ensure creation of the children)
compatible = "simple-bus";
- mapping of the SMB CS/offset addresses into main address space:
#address-cells = <2>;
#size-cells = <1>;
ranges = <...>;
- interrupts mapping:
#interrupt-cells = <1>;
interrupt-map-mask = <0 0 63>;
interrupt-map = <...>;
Example of a VE tile description (simplified)
---------------------------------------------
/dts-v1/;
/ {
model = "V2P-CA5s";
arm,hbi = <0x225>;
arm,vexpress,site = <0xf>;
compatible = "arm,vexpress-v2p-ca5s", "arm,vexpress";
interrupt-parent = <&gic>;
#address-cells = <1>;
#size-cells = <1>;
chosen { };
aliases {
serial0 = &v2m_serial0;
};
cpus {
#address-cells = <1>;
#size-cells = <0>;
cpu@0 {
device_type = "cpu";
compatible = "arm,cortex-a5";
reg = <0>;
};
};
gic: interrupt-controller@2c001000 {
compatible = "arm,cortex-a9-gic";
#interrupt-cells = <3>;
#address-cells = <0>;
interrupt-controller;
reg = <0x2c001000 0x1000>,
<0x2c000100 0x100>;
};
dcc {
compatible = "arm,vexpress,config-bus";
arm,vexpress,config-bridge = <&v2m_sysreg>;
osc@0 {
compatible = "arm,vexpress-osc";
};
};
smb {
compatible = "simple-bus";
#address-cells = <2>;
#size-cells = <1>;
/* CS0 is visible at 0x08000000 */
ranges = <0 0 0x08000000 0x04000000>;
#interrupt-cells = <1>;
interrupt-map-mask = <0 0 63>;
/* Active high IRQ 0 is connected to GIC's SPI0 */
interrupt-map = <0 0 0 &gic 0 0 4>;
/include/ "vexpress-v2m-rs1.dtsi"
};
};

71
Documentation/devicetree/bindings/ata/renesas,rcar-sata.yaml Normal file
View File

@ -0,0 +1,71 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: "http://devicetree.org/schemas/ata/renesas,rcar-sata.yaml#"
$schema: "http://devicetree.org/meta-schemas/core.yaml#"
title: Renesas R-Car Serial-ATA Interface
maintainers:
- Geert Uytterhoeven <geert+renesas@glider.be>
properties:
compatible:
oneOf:
- items:
- enum:
- renesas,sata-r8a7779 # R-Car H1
- items:
- enum:
- renesas,sata-r8a7790-es1 # R-Car H2 ES1
- renesas,sata-r8a7790 # R-Car H2 other than ES1
- renesas,sata-r8a7791 # R-Car M2-W
- renesas,sata-r8a7793 # R-Car M2-N
- const: renesas,rcar-gen2-sata # generic R-Car Gen2
- items:
- enum:
- renesas,sata-r8a774b1 # RZ/G2N
- renesas,sata-r8a7795 # R-Car H3
- renesas,sata-r8a77965 # R-Car M3-N
- const: renesas,rcar-gen3-sata # generic R-Car Gen3 or RZ/G2
reg:
maxItems: 1
interrupts:
maxItems: 1
clocks:
maxItems: 1
iommus:
maxItems: 1
power-domains:
maxItems: 1
resets:
maxItems: 1
required:
- compatible
- reg
- interrupts
- clocks
additionalProperties: false
examples:
- |
#include <dt-bindings/clock/r8a7791-cpg-mssr.h>
#include <dt-bindings/interrupt-controller/arm-gic.h>
#include <dt-bindings/power/r8a7791-sysc.h>
sata@ee300000 {
compatible = "renesas,sata-r8a7791", "renesas,rcar-gen2-sata";
reg = <0xee300000 0x200000>;
interrupts = <GIC_SPI 105 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&cpg CPG_MOD 815>;
power-domains = <&sysc R8A7791_PD_ALWAYS_ON>;
resets = <&cpg 815>;
};

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

@ -1,36 +0,0 @@
* Renesas R-Car SATA
Required properties:
- compatible : should contain one or more of the following:
- "renesas,sata-r8a774b1" for RZ/G2N
- "renesas,sata-r8a7779" for R-Car H1
- "renesas,sata-r8a7790-es1" for R-Car H2 ES1
- "renesas,sata-r8a7790" for R-Car H2 other than ES1
- "renesas,sata-r8a7791" for R-Car M2-W
- "renesas,sata-r8a7793" for R-Car M2-N
- "renesas,sata-r8a7795" for R-Car H3
- "renesas,sata-r8a77965" for R-Car M3-N
- "renesas,rcar-gen2-sata" for a generic R-Car Gen2
compatible device
- "renesas,rcar-gen3-sata" for a generic R-Car Gen3 or
RZ/G2 compatible device
- "renesas,rcar-sata" is deprecated
When compatible with the generic version nodes
must list the SoC-specific version corresponding
to the platform first followed by the generic
version.
- reg : address and length of the SATA registers;
- interrupts : must consist of one interrupt specifier.
- clocks : must contain a reference to the functional clock.
Example:
sata0: sata@ee300000 {
compatible = "renesas,sata-r8a7791", "renesas,rcar-gen2-sata";
reg = <0 0xee300000 0 0x2000>;
interrupt-parent = <&gic>;
interrupts = <0 105 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&mstp8_clks R8A7791_CLK_SATA0>;
};

96
Documentation/devicetree/bindings/bus/socionext,uniphier-system-bus.yaml Normal file
View File

@ -0,0 +1,96 @@
# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
%YAML 1.2
---
$id: http://devicetree.org/schemas/bus/socionext,uniphier-system-bus.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: UniPhier System Bus
description: |
The UniPhier System Bus is an external bus that connects on-board devices to
the UniPhier SoC. It is a simple (semi-)parallel bus with address, data, and
some control signals. It supports up to 8 banks (chip selects).
Before any access to the bus, the bus controller must be configured; the bus
controller registers provide the control for the translation from the offset
within each bank to the CPU-viewed address. The needed setup includes the
base address, the size of each bank. Optionally, some timing parameters can
be optimized for faster bus access.
maintainers:
- Masahiro Yamada <yamada.masahiro@socionext.com>
properties:
compatible:
const: socionext,uniphier-system-bus
reg:
maxItems: 1
"#address-cells":
description: |
The first cell is the bank number (chip select).
The second cell is the address offset within the bank.
const: 2
"#size-cells":
const: 1
ranges:
description: |
Provide address translation from the System Bus to the parent bus.
Note:
The address region(s) that can be assigned for the System Bus is
implementation defined. Some SoCs can use 0x00000000-0x0fffffff and
0x40000000-0x4fffffff, while other SoCs only 0x40000000-0x4fffffff.
There might be additional limitations depending on SoCs and the boot mode.
The address translation is arbitrary as long as the banks are assigned in
the supported address space with the required alignment and they do not
overlap one another.
For example, it is possible to map:
bank 0 to 0x42000000-0x43ffffff, bank 5 to 0x46000000-0x46ffffff
It is also possible to map:
bank 0 to 0x48000000-0x49ffffff, bank 5 to 0x44000000-0x44ffffff
There is no reason to stick to a particular translation mapping, but the
"ranges" property should provide a "reasonable" default that is known to
work. The software should initialize the bus controller according to it.
required:
- compatible
- reg
- "#address-cells"
- "#size-cells"
- ranges
examples:
- |
// In this example,
// - the Ethernet device is connected at the offset 0x01f00000 of CS1 and
// mapped to 0x43f00000 of the parent bus.
// - the UART device is connected at the offset 0x00200000 of CS5 and
// mapped to 0x46200000 of the parent bus.
system-bus@58c00000 {
compatible = "socionext,uniphier-system-bus";
reg = <0x58c00000 0x400>;
#address-cells = <2>;
#size-cells = <1>;
ranges = <1 0x00000000 0x42000000 0x02000000>,
<5 0x00000000 0x46000000 0x01000000>;
ethernet@1,01f00000 {
compatible = "smsc,lan9115";
reg = <1 0x01f00000 0x1000>;
interrupts = <0 48 4>;
phy-mode = "mii";
};
uart@5,00200000 {
compatible = "ns16550a";
reg = <5 0x00200000 0x20>;
interrupts = <0 49 4>;
clock-frequency = <12288000>;
};
};

1
Documentation/devicetree/bindings/bus/ti-sysc.txt
View File

@ -38,6 +38,7 @@ Required standard properties:
"ti,sysc-dra7-mcasp"
"ti,sysc-usb-host-fs"
"ti,sysc-dra7-mcan"
"ti,sysc-pruss"
- reg shall have register areas implemented for the interconnect
target module in question such as revision, sysc and syss

66
Documentation/devicetree/bindings/bus/uniphier-system-bus.txt
View File

@ -1,66 +0,0 @@
UniPhier System Bus
The UniPhier System Bus is an external bus that connects on-board devices to
the UniPhier SoC. It is a simple (semi-)parallel bus with address, data, and
some control signals. It supports up to 8 banks (chip selects).
Before any access to the bus, the bus controller must be configured; the bus
controller registers provide the control for the translation from the offset
within each bank to the CPU-viewed address. The needed setup includes the base
address, the size of each bank. Optionally, some timing parameters can be
optimized for faster bus access.
Required properties:
- compatible: should be "socionext,uniphier-system-bus".
- reg: offset and length of the register set for the bus controller device.
- #address-cells: should be 2. The first cell is the bank number (chip select).
The second cell is the address offset within the bank.
- #size-cells: should be 1.
- ranges: should provide a proper address translation from the System Bus to
the parent bus.
Note:
The address region(s) that can be assigned for the System Bus is implementation
defined. Some SoCs can use 0x00000000-0x0fffffff and 0x40000000-0x4fffffff,
while other SoCs can only use 0x40000000-0x4fffffff. There might be additional
limitations depending on SoCs and the boot mode. The address translation is
arbitrary as long as the banks are assigned in the supported address space with
the required alignment and they do not overlap one another.
For example, it is possible to map:
bank 0 to 0x42000000-0x43ffffff, bank 5 to 0x46000000-0x46ffffff
It is also possible to map:
bank 0 to 0x48000000-0x49ffffff, bank 5 to 0x44000000-0x44ffffff
There is no reason to stick to a particular translation mapping, but the
"ranges" property should provide a "reasonable" default that is known to work.
The software should initialize the bus controller according to it.
Example:
system-bus {
compatible = "socionext,uniphier-system-bus";
reg = <0x58c00000 0x400>;
#address-cells = <2>;
#size-cells = <1>;
ranges = <1 0x00000000 0x42000000 0x02000000
5 0x00000000 0x46000000 0x01000000>;
ethernet@1,01f00000 {
compatible = "smsc,lan9115";
reg = <1 0x01f00000 0x1000>;
interrupts = <0 48 4>
phy-mode = "mii";
};
uart@5,00200000 {
compatible = "ns16550a";
reg = <5 0x00200000 0x20>;
interrupts = <0 49 4>
clock-frequency = <12288000>;
};
};
In this example,
- the Ethernet device is connected at the offset 0x01f00000 of CS1 and
mapped to 0x43f00000 of the parent bus.
- the UART device is connected at the offset 0x00200000 of CS5 and
mapped to 0x46200000 of the parent bus.

54
Documentation/devicetree/bindings/chrome/google,cros-ec-typec.yaml Normal file
View File

@ -0,0 +1,54 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/chrome/google,cros-ec-typec.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Google Chrome OS EC(Embedded Controller) Type C port driver.
maintainers:
- Benson Leung <bleung@chromium.org>
- Prashant Malani <pmalani@chromium.org>
description:
Chrome OS devices have an Embedded Controller(EC) which has access to
Type C port state. This node is intended to allow the host to read and
control the Type C ports. The node for this device should be under a
cros-ec node like google,cros-ec-spi.
properties:
compatible:
const: google,cros-ec-typec
connector:
$ref: /schemas/connector/usb-connector.yaml#
required:
- compatible
examples:
- |+
spi0 {
#address-cells = <1>;
#size-cells = <0>;
cros_ec: ec@0 {
compatible = "google,cros-ec-spi";
reg = <0>;
typec {
compatible = "google,cros-ec-typec";
#address-cells = <1>;
#size-cells = <0>;
connector@0 {
compatible = "usb-c-connector";
reg = <0>;
power-role = "dual";
data-role = "dual";
try-power-role = "source";
};
};
};
};

103
Documentation/devicetree/bindings/clock/arm,syscon-icst.yaml Normal file
View File

@ -0,0 +1,103 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/clock/arm,syscon-icst.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: ARM System Controller ICST Clocks
maintainers:
- Linus Walleij <linusw@kernel.org>
description: |
The ICS525 and ICS307 oscillators are produced by Integrated
Devices Technology (IDT). ARM integrated these oscillators deeply into their
reference designs by adding special control registers that manage such
oscillators to their system controllers.
The various ARM system controllers contain logic to serialize and initialize
an ICST clock request after a write to the 32 bit register at an offset
into the system controller. Furthermore, to even be able to alter one of
these frequencies, the system controller must first be unlocked by
writing a special token to another offset in the system controller.
Some ARM hardware contain special versions of the serial interface that only
connects the low 8 bits of the VDW (missing one bit), hard-wires RDW to
different values and sometimes also hard-wires the output divider. They
therefore have special compatible strings as per this table (the OD value is
the value on the pins, not the resulting output divider).
In the core modules and logic tiles, the ICST is a configurable clock fed
from a 24 MHz clock on the motherboard (usually the main crystal) used for
generating e.g. video clocks. It is located on the core module and there is
only one of these. This clock node must be a subnode of the core module.
Hardware variant RDW OD VDW
Integrator/AP 22 1 Bit 8 0, rest variable
integratorap-cm
Integrator/AP 46 3 Bit 8 0, rest variable
integratorap-sys
Integrator/AP 22 or 1 17 or (33 or 25 MHz)
integratorap-pci 14 1 14
Integrator/CP 22 variable Bit 8 0, rest variable
integratorcp-cm-core
Integrator/CP 22 variable Bit 8 0, rest variable
integratorcp-cm-mem
The ICST oscillator must be provided inside a system controller node.
properties:
"#clock-cells":
const: 0
compatible:
enum:
- arm,syscon-icst525
- arm,syscon-icst307
- arm,syscon-icst525-integratorap-cm
- arm,syscon-icst525-integratorap-sys
- arm,syscon-icst525-integratorap-pci
- arm,syscon-icst525-integratorcp-cm-core
- arm,syscon-icst525-integratorcp-cm-mem
- arm,integrator-cm-auxosc
- arm,versatile-cm-auxosc
- arm,impd-vco1
- arm,impd-vco2
clocks:
description: Parent clock for the ICST VCO
maxItems: 1
clock-output-names:
maxItems: 1
lock-offset:
$ref: '/schemas/types.yaml#/definitions/uint32'
description: Offset to the unlocking register for the oscillator
vco-offset:
$ref: '/schemas/types.yaml#/definitions/uint32'
description: Offset to the VCO register for the oscillator
required:
- "#clock-cells"
- compatible
- clocks
examples:
- |
vco1: clock {
compatible = "arm,impd1-vco1";
#clock-cells = <0>;
lock-offset = <0x08>;
vco-offset = <0x00>;
clocks = <&sysclk>;
clock-output-names = "IM-PD1-VCO1";
};
...

34
Documentation/devicetree/bindings/clock/arm-integrator.txt
View File

@ -1,34 +0,0 @@
Clock bindings for ARM Integrator and Versatile Core Module clocks
Auxiliary Oscillator Clock
This is a configurable clock fed from a 24 MHz chrystal,
used for generating e.g. video clocks. It is located on the
core module and there is only one of these.
This clock node *must* be a subnode of the core module, since
it obtains the base address for it's address range from its
parent node.
Required properties:
- compatible: must be "arm,integrator-cm-auxosc" or "arm,versatile-cm-auxosc"
- #clock-cells: must be <0>
Optional properties:
- clocks: parent clock(s)
Example:
core-module@10000000 {
xtal24mhz: xtal24mhz@24M {
#clock-cells = <0>;
compatible = "fixed-clock";
clock-frequency = <24000000>;
};
auxosc: cm_aux_osc@25M {
#clock-cells = <0>;
compatible = "arm,integrator-cm-auxosc";
clocks = <&xtal24mhz>;
};
};

70
Documentation/devicetree/bindings/clock/arm-syscon-icst.txt
View File

@ -1,70 +0,0 @@
ARM System Controller ICST clocks
The ICS525 and ICS307 oscillators are produced by Integrated Devices
Technology (IDT). ARM integrated these oscillators deeply into their
reference designs by adding special control registers that manage such
oscillators to their system controllers.
The various ARM system controllers contain logic to serialize and initialize
an ICST clock request after a write to the 32 bit register at an offset
into the system controller. Furthermore, to even be able to alter one of
these frequencies, the system controller must first be unlocked by
writing a special token to another offset in the system controller.
Some ARM hardware contain special versions of the serial interface that only
connects the low 8 bits of the VDW (missing one bit), hardwires RDW to
different values and sometimes also hardwire the output divider. They
therefore have special compatible strings as per this table (the OD value is
the value on the pins, not the resulting output divider):
Hardware variant: RDW OD VDW
Integrator/AP 22 1 Bit 8 0, rest variable
integratorap-cm
Integrator/AP 46 3 Bit 8 0, rest variable
integratorap-sys
Integrator/AP 22 or 1 17 or (33 or 25 MHz)
integratorap-pci 14 1 14
Integrator/CP 22 variable Bit 8 0, rest variable
integratorcp-cm-core
Integrator/CP 22 variable Bit 8 0, rest variable
integratorcp-cm-mem
The ICST oscillator must be provided inside a system controller node.
Required properties:
- compatible: must be one of
"arm,syscon-icst525"
"arm,syscon-icst307"
"arm,syscon-icst525-integratorap-cm"
"arm,syscon-icst525-integratorap-sys"
"arm,syscon-icst525-integratorap-pci"
"arm,syscon-icst525-integratorcp-cm-core"
"arm,syscon-icst525-integratorcp-cm-mem"
- lock-offset: the offset address into the system controller where the
unlocking register is located
- vco-offset: the offset address into the system controller where the
ICST control register is located (even 32 bit address)
- #clock-cells: must be <0>
- clocks: parent clock, since the ICST needs a parent clock to derive its
frequency from, this attribute is compulsory.
Example:
syscon: syscon@10000000 {
compatible = "syscon";
reg = <0x10000000 0x1000>;
oscclk0: osc0@c {
compatible = "arm,syscon-icst307";
#clock-cells = <0>;
lock-offset = <0x20>;
vco-offset = <0x0c>;
clocks = <&xtal24mhz>;
};
(...)
};

2
Documentation/devicetree/bindings/clock/clock-bindings.txt
View File

@ -94,7 +94,7 @@ clock is connected to output 0 of the &ref.
/* external oscillator */
osc: oscillator {
compatible = "fixed-clock";
#clock-cells = <1>;
#clock-cells = <0>;
clock-frequency = <32678>;
clock-output-names = "osc";
};

5
Documentation/devicetree/bindings/clock/fsl,plldig.yaml
View File

@ -21,6 +21,9 @@ properties:
reg:
maxItems: 1
clocks:
maxItems: 1
'#clock-cells':
const: 0
@ -41,6 +44,8 @@ required:
- clocks
- '#clock-cells'
additionalProperties: false
examples:
# Display PIXEL Clock node:
- |

29
Documentation/devicetree/bindings/clock/imx8mm-clock.txt
View File

@ -1,29 +0,0 @@
* Clock bindings for NXP i.MX8M Mini
Required properties:
- compatible: Should be "fsl,imx8mm-ccm"
- reg: Address and length of the register set
- #clock-cells: Should be <1>
- clocks: list of clock specifiers, must contain an entry for each required
entry in clock-names
- clock-names: should include the following entries:
- "osc_32k"
- "osc_24m"
- "clk_ext1"
- "clk_ext2"
- "clk_ext3"
- "clk_ext4"
clk: clock-controller@30380000 {
compatible = "fsl,imx8mm-ccm";
reg = <0x0 0x30380000 0x0 0x10000>;
#clock-cells = <1>;
clocks = <&osc_32k>, <&osc_24m>, <&clk_ext1>, <&clk_ext2>,
<&clk_ext3>, <&clk_ext4>;
clock-names = "osc_32k", "osc_24m", "clk_ext1", "clk_ext2",
"clk_ext3", "clk_ext4";
};
The clock consumer should specify the desired clock by having the clock
ID in its "clocks" phandle cell. See include/dt-bindings/clock/imx8mm-clock.h
for the full list of i.MX8M Mini clock IDs.

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