Snap for 8970845 from 935365e899 to android-mainline-keystone-qcom-release

Change-Id: I05f733a5fa1a9b01332de174218759f969e4ac7b
This commit is contained in:
Android Build Coastguard Worker 2022-08-20 00:00:19 +00:00
commit ea7c365a43
3124 changed files with 116625 additions and 54261 deletions

View File

@ -260,6 +260,15 @@ Description:
for discards, and don't read this file.
What: /sys/block/<disk>/queue/dma_alignment
Date: May 2022
Contact: linux-block@vger.kernel.org
Description:
Reports the alignment that user space addresses must have to be
used for raw block device access with O_DIRECT and other driver
specific passthrough mechanisms.
What: /sys/block/<disk>/queue/fua
Date: May 2018
Contact: linux-block@vger.kernel.org

View File

@ -938,3 +938,12 @@ Description:
- 1: enable
RW
What: /sys/class/hwmon/hwmonX/device/pec
Description:
PEC support on I2C devices
- 0, off, n: disable
- 1, on, y: enable
RW

View File

@ -493,12 +493,13 @@ What: /sys/devices/system/cpu/cpuX/regs/
/sys/devices/system/cpu/cpuX/regs/identification/
/sys/devices/system/cpu/cpuX/regs/identification/midr_el1
/sys/devices/system/cpu/cpuX/regs/identification/revidr_el1
/sys/devices/system/cpu/cpuX/regs/identification/smidr_el1
Date: June 2016
Contact: Linux ARM Kernel Mailing list <linux-arm-kernel@lists.infradead.org>
Description: AArch64 CPU registers
'identification' directory exposes the CPU ID registers for
identifying model and revision of the CPU.
identifying model and revision of the CPU and SMCU.
What: /sys/devices/system/cpu/aarch32_el0
Date: May 2021

View File

@ -0,0 +1,49 @@
What: /sys/bus/pci/devices/<BDF>/qat/state
Date: June 2022
KernelVersion: 5.20
Contact: qat-linux@intel.com
Description: (RW) Reports the current state of the QAT device. Write to
the file to start or stop the device.
The values are:
* up: the device is up and running
* down: the device is down
It is possible to transition the device from up to down only
if the device is up and vice versa.
This attribute is only available for qat_4xxx devices.
What: /sys/bus/pci/devices/<BDF>/qat/cfg_services
Date: June 2022
KernelVersion: 5.20
Contact: qat-linux@intel.com
Description: (RW) Reports the current configuration of the QAT device.
Write to the file to change the configured services.
The values are:
* sym;asym: the device is configured for running crypto
services
* dc: the device is configured for running compression services
It is possible to set the configuration only if the device
is in the `down` state (see /sys/bus/pci/devices/<BDF>/qat/state)
The following example shows how to change the configuration of
a device configured for running crypto services in order to
run data compression::
# cat /sys/bus/pci/devices/<BDF>/qat/state
up
# cat /sys/bus/pci/devices/<BDF>/qat/cfg_services
sym;asym
# echo down > /sys/bus/pci/devices/<BDF>/qat/state
# echo dc > /sys/bus/pci/devices/<BDF>/qat/cfg_services
# echo up > /sys/bus/pci/devices/<BDF>/qat/state
# cat /sys/bus/pci/devices/<BDF>/qat/cfg_services
dc
This attribute is only available for qat_4xxx devices.

View File

@ -12,8 +12,9 @@ Description:
configuration data to the guest userspace.
The authoritative guest-side hardware interface documentation
to the fw_cfg device can be found in "docs/specs/fw_cfg.txt"
in the QEMU source tree.
to the fw_cfg device can be found in "docs/specs/fw_cfg.rst"
in the QEMU source tree, or online at:
https://qemu-project.gitlab.io/qemu/specs/fw_cfg.html
**SysFS fw_cfg Interface**

View File

@ -1,23 +1,22 @@
config WARN_MISSING_DOCUMENTS
bool "Warn if there's a missing documentation file"
depends on COMPILE_TEST
help
It is not uncommon that a document gets renamed.
This option makes the Kernel to check for missing dependencies,
warning when something is missing. Works only if the Kernel
is built from a git tree.
It is not uncommon that a document gets renamed.
This option makes the Kernel to check for missing dependencies,
warning when something is missing. Works only if the Kernel
is built from a git tree.
If unsure, select 'N'.
If unsure, select 'N'.
config WARN_ABI_ERRORS
bool "Warn if there are errors at ABI files"
depends on COMPILE_TEST
help
The files under Documentation/ABI should follow what's
described at Documentation/ABI/README. Yet, as they're manually
written, it would be possible that some of those files would
have errors that would break them for being parsed by
scripts/get_abi.pl. Add a check to verify them.
The files under Documentation/ABI should follow what's
described at Documentation/ABI/README. Yet, as they're manually
written, it would be possible that some of those files would
have errors that would break them for being parsed by
scripts/get_abi.pl. Add a check to verify them.
If unsure, select 'N'.
If unsure, select 'N'.

View File

@ -125,14 +125,14 @@ Following piece of code illustrates the usage of the SR-IOV API.
...
}
static int dev_suspend(struct pci_dev *dev, pm_message_t state)
static int dev_suspend(struct device *dev)
{
...
return 0;
}
static int dev_resume(struct pci_dev *dev)
static int dev_resume(struct device *dev)
{
...
@ -165,8 +165,7 @@ Following piece of code illustrates the usage of the SR-IOV API.
.id_table = dev_id_table,
.probe = dev_probe,
.remove = dev_remove,
.suspend = dev_suspend,
.resume = dev_resume,
.driver.pm = &dev_pm_ops,
.shutdown = dev_shutdown,
.sriov_configure = dev_sriov_configure,
};

View File

@ -125,7 +125,7 @@ implementation of that functionality. To support the historical interface of
mmap() through files in /proc/bus/pci, platforms may also set HAVE_PCI_MMAP.
Alternatively, platforms which set HAVE_PCI_MMAP may provide their own
implementation of pci_mmap_page_range() instead of defining
implementation of pci_mmap_resource_range() instead of defining
ARCH_GENERIC_PCI_MMAP_RESOURCE.
Platforms which support write-combining maps of PCI resources must define

View File

@ -1844,10 +1844,10 @@ that meets this requirement.
Furthermore, NMI handlers can be interrupted by what appear to RCU to be
normal interrupts. One way that this can happen is for code that
directly invokes rcu_irq_enter() and rcu_irq_exit() to be called
directly invokes ct_irq_enter() and ct_irq_exit() to be called
from an NMI handler. This astonishing fact of life prompted the current
code structure, which has rcu_irq_enter() invoking
rcu_nmi_enter() and rcu_irq_exit() invoking rcu_nmi_exit().
code structure, which has ct_irq_enter() invoking
ct_nmi_enter() and ct_irq_exit() invoking ct_nmi_exit().
And yes, I also learned of this requirement the hard way.
Loadable Modules
@ -2195,7 +2195,7 @@ scheduling-clock interrupt be enabled when RCU needs it to be:
sections, and RCU believes this CPU to be idle, no problem. This
sort of thing is used by some architectures for light-weight
exception handlers, which can then avoid the overhead of
rcu_irq_enter() and rcu_irq_exit() at exception entry and
ct_irq_enter() and ct_irq_exit() at exception entry and
exit, respectively. Some go further and avoid the entireties of
irq_enter() and irq_exit().
Just make very sure you are running some of your tests with
@ -2226,7 +2226,7 @@ scheduling-clock interrupt be enabled when RCU needs it to be:
+-----------------------------------------------------------------------+
| **Answer**: |
+-----------------------------------------------------------------------+
| One approach is to do ``rcu_irq_exit();rcu_irq_enter();`` every so |
| One approach is to do ``ct_irq_exit();ct_irq_enter();`` every so |
| often. But given that long-running interrupt handlers can cause other |
| problems, not least for response time, shouldn't you work to keep |
| your interrupt handler's runtime within reasonable bounds? |

View File

@ -97,12 +97,12 @@ warnings:
which will include additional debugging information.
- A low-level kernel issue that either fails to invoke one of the
variants of rcu_user_enter(), rcu_user_exit(), rcu_idle_enter(),
rcu_idle_exit(), rcu_irq_enter(), or rcu_irq_exit() on the one
variants of rcu_eqs_enter(true), rcu_eqs_exit(true), ct_idle_enter(),
ct_idle_exit(), ct_irq_enter(), or ct_irq_exit() on the one
hand, or that invokes one of them too many times on the other.
Historically, the most frequent issue has been an omission
of either irq_enter() or irq_exit(), which in turn invoke
rcu_irq_enter() or rcu_irq_exit(), respectively. Building your
ct_irq_enter() or ct_irq_exit(), respectively. Building your
kernel with CONFIG_RCU_EQS_DEBUG=y can help track down these types
of issues, which sometimes arise in architecture-specific code.

View File

@ -97,7 +97,7 @@ Under below explanation, we assume CONFIG_MEM_RES_CTRL_SWAP=y.
=============
Page Cache is charged at
- add_to_page_cache_locked().
- filemap_add_folio().
The logic is very clear. (About migration, see below)

View File

@ -184,6 +184,14 @@ cgroup v2 currently supports the following mount options.
ignored on non-init namespace mounts. Please refer to the
Delegation section for details.
favordynmods
Reduce the latencies of dynamic cgroup modifications such as
task migrations and controller on/offs at the cost of making
hot path operations such as forks and exits more expensive.
The static usage pattern of creating a cgroup, enabling
controllers, and then seeding it with CLONE_INTO_CGROUP is
not affected by this option.
memory_localevents
Only populate memory.events with data for the current cgroup,
and not any subtrees. This is legacy behaviour, the default

View File

@ -20,6 +20,7 @@ Constructor parameters:
size)
5. the number of optional parameters (the parameters with an argument
count as two)
start_sector n (default: 0)
offset from the start of cache device in 512-byte sectors
high_watermark n (default: 50)
@ -74,20 +75,21 @@ Constructor parameters:
the origin volume in the last n milliseconds
Status:
1. error indicator - 0 if there was no error, otherwise error number
2. the number of blocks
3. the number of free blocks
4. the number of blocks under writeback
5. the number of read requests
6. the number of read requests that hit the cache
7. the number of write requests
8. the number of write requests that hit uncommitted block
9. the number of write requests that hit committed block
10. the number of write requests that bypass the cache
11. the number of write requests that are allocated in the cache
5. the number of read blocks
6. the number of read blocks that hit the cache
7. the number of write blocks
8. the number of write blocks that hit uncommitted block
9. the number of write blocks that hit committed block
10. the number of write blocks that bypass the cache
11. the number of write blocks that are allocated in the cache
12. the number of write requests that are blocked on the freelist
13. the number of flush requests
14. the number of discard requests
14. the number of discarded blocks
Messages:
flush

View File

@ -7,10 +7,9 @@ This list is the Linux Device List, the official registry of allocated
device numbers and ``/dev`` directory nodes for the Linux operating
system.
The LaTeX version of this document is no longer maintained, nor is
the document that used to reside at lanana.org. This version in the
mainline Linux kernel is the master document. Updates shall be sent
as patches to the kernel maintainers (see the
The version of this document at lanana.org is no longer maintained. This
version in the mainline Linux kernel is the master document. Updates
shall be sent as patches to the kernel maintainers (see the
:ref:`Documentation/process/submitting-patches.rst <submittingpatches>` document).
Specifically explore the sections titled "CHAR and MISC DRIVERS", and
"BLOCK LAYER" in the MAINTAINERS file to find the right maintainers

View File

@ -7,10 +7,10 @@ as a PE/COFF image, thereby convincing EFI firmware loaders to load
it as an EFI executable. The code that modifies the bzImage header,
along with the EFI-specific entry point that the firmware loader
jumps to are collectively known as the "EFI boot stub", and live in
arch/x86/boot/header.S and arch/x86/boot/compressed/eboot.c,
arch/x86/boot/header.S and drivers/firmware/efi/libstub/x86-stub.c,
respectively. For ARM the EFI stub is implemented in
arch/arm/boot/compressed/efi-header.S and
arch/arm/boot/compressed/efi-stub.c. EFI stub code that is shared
drivers/firmware/efi/libstub/arm32-stub.c. EFI stub code that is shared
between architectures is in drivers/firmware/efi/libstub.
For arm64, there is no compressed kernel support, so the Image itself

View File

@ -400,6 +400,12 @@
arm64.nomte [ARM64] Unconditionally disable Memory Tagging Extension
support
arm64.nosve [ARM64] Unconditionally disable Scalable Vector
Extension support
arm64.nosme [ARM64] Unconditionally disable Scalable Matrix
Extension support
ataflop= [HW,M68k]
atarimouse= [HW,MOUSE] Atari Mouse
@ -550,7 +556,7 @@
nosocket -- Disable socket memory accounting.
nokmem -- Disable kernel memory accounting.
checkreqprot [SELINUX] Set initial checkreqprot flag value.
checkreqprot= [SELINUX] Set initial checkreqprot flag value.
Format: { "0" | "1" }
See security/selinux/Kconfig help text.
0 -- check protection applied by kernel (includes
@ -1439,7 +1445,7 @@
(in particular on some ATI chipsets).
The kernel tries to set a reasonable default.
enforcing [SELINUX] Set initial enforcing status.
enforcing= [SELINUX] Set initial enforcing status.
Format: {"0" | "1"}
See security/selinux/Kconfig help text.
0 -- permissive (log only, no denials).
@ -3111,7 +3117,7 @@
mem_encrypt=on: Activate SME
mem_encrypt=off: Do not activate SME
Refer to Documentation/virt/kvm/amd-memory-encryption.rst
Refer to Documentation/virt/kvm/x86/amd-memory-encryption.rst
for details on when memory encryption can be activated.
mem_sleep_default= [SUSPEND] Default system suspend mode:
@ -3169,7 +3175,7 @@
improves system performance, but it may also
expose users to several CPU vulnerabilities.
Equivalent to: nopti [X86,PPC]
kpti=0 [ARM64]
if nokaslr then kpti=0 [ARM64]
nospectre_v1 [X86,PPC]
nobp=0 [S390]
nospectre_v2 [X86,PPC,S390,ARM64]
@ -3669,6 +3675,9 @@
just as if they had also been called out in the
rcu_nocbs= boot parameter.
Note that this argument takes precedence over
the CONFIG_RCU_NOCB_CPU_DEFAULT_ALL option.
noiotrap [SH] Disables trapped I/O port accesses.
noirqdebug [X86-32] Disables the code which attempts to detect and
@ -3743,11 +3752,6 @@
noreplace-smp [X86-32,SMP] Don't replace SMP instructions
with UP alternatives
nordrand [X86] Disable kernel use of the RDRAND and
RDSEED instructions even if they are supported
by the processor. RDRAND and RDSEED are still
available to user space applications.
noresume [SWSUSP] Disables resume and restores original swap
space.
@ -4567,6 +4571,9 @@
no-callback mode from boot but the mode may be
toggled at runtime via cpusets.
Note that this argument takes precedence over
the CONFIG_RCU_NOCB_CPU_DEFAULT_ALL option.
rcu_nocb_poll [KNL]
Rather than requiring that offloaded CPUs
(specified by rcu_nocbs= above) explicitly
@ -4676,6 +4683,34 @@
When RCU_NOCB_CPU is set, also adjust the
priority of NOCB callback kthreads.
rcutree.rcu_divisor= [KNL]
Set the shift-right count to use to compute
the callback-invocation batch limit bl from
the number of callbacks queued on this CPU.
The result will be bounded below by the value of
the rcutree.blimit kernel parameter. Every bl
callbacks, the softirq handler will exit in
order to allow the CPU to do other work.
Please note that this callback-invocation batch
limit applies only to non-offloaded callback
invocation. Offloaded callbacks are instead
invoked in the context of an rcuoc kthread, which
scheduler will preempt as it does any other task.
rcutree.nocb_nobypass_lim_per_jiffy= [KNL]
On callback-offloaded (rcu_nocbs) CPUs,
RCU reduces the lock contention that would
otherwise be caused by callback floods through
use of the ->nocb_bypass list. However, in the
common non-flooded case, RCU queues directly to
the main ->cblist in order to avoid the extra
overhead of the ->nocb_bypass list and its lock.
But if there are too many callbacks queued during
a single jiffy, RCU pre-queues the callbacks into
the ->nocb_bypass queue. The definition of "too
many" is supplied by this kernel boot parameter.
rcutree.rcu_nocb_gp_stride= [KNL]
Set the number of NOCB callback kthreads in
each group, which defaults to the square root

View File

@ -0,0 +1,136 @@
======================================
HNS3 Performance Monitoring Unit (PMU)
======================================
HNS3(HiSilicon network system 3) Performance Monitoring Unit (PMU) is an
End Point device to collect performance statistics of HiSilicon SoC NIC.
On Hip09, each SICL(Super I/O cluster) has one PMU device.
HNS3 PMU supports collection of performance statistics such as bandwidth,
latency, packet rate and interrupt rate.
Each HNS3 PMU supports 8 hardware events.
HNS3 PMU driver
===============
The HNS3 PMU driver registers a perf PMU with the name of its sicl id.::
/sys/devices/hns3_pmu_sicl_<sicl_id>
PMU driver provides description of available events, filter modes, format,
identifier and cpumask in sysfs.
The "events" directory describes the event code of all supported events
shown in perf list.
The "filtermode" directory describes the supported filter modes of each
event.
The "format" directory describes all formats of the config (events) and
config1 (filter options) fields of the perf_event_attr structure.
The "identifier" file shows version of PMU hardware device.
The "bdf_min" and "bdf_max" files show the supported bdf range of each
pmu device.
The "hw_clk_freq" file shows the hardware clock frequency of each pmu
device.
Example usage of checking event code and subevent code::
$# cat /sys/devices/hns3_pmu_sicl_0/events/dly_tx_normal_to_mac_time
config=0x00204
$# cat /sys/devices/hns3_pmu_sicl_0/events/dly_tx_normal_to_mac_packet_num
config=0x10204
Each performance statistic has a pair of events to get two values to
calculate real performance data in userspace.
The bits 0~15 of config (here 0x0204) are the true hardware event code. If
two events have same value of bits 0~15 of config, that means they are
event pair. And the bit 16 of config indicates getting counter 0 or
counter 1 of hardware event.
After getting two values of event pair in usersapce, the formula of
computation to calculate real performance data is:::
counter 0 / counter 1
Example usage of checking supported filter mode::
$# cat /sys/devices/hns3_pmu_sicl_0/filtermode/bw_ssu_rpu_byte_num
filter mode supported: global/port/port-tc/func/func-queue/
Example usage of perf::
$# perf list
hns3_pmu_sicl_0/bw_ssu_rpu_byte_num/ [kernel PMU event]
hns3_pmu_sicl_0/bw_ssu_rpu_time/ [kernel PMU event]
------------------------------------------
$# perf stat -g -e hns3_pmu_sicl_0/bw_ssu_rpu_byte_num,global=1/ -e hns3_pmu_sicl_0/bw_ssu_rpu_time,global=1/ -I 1000
or
$# perf stat -g -e hns3_pmu_sicl_0/config=0x00002,global=1/ -e hns3_pmu_sicl_0/config=0x10002,global=1/ -I 1000
Filter modes
--------------
1. global mode
PMU collect performance statistics for all HNS3 PCIe functions of IO DIE.
Set the "global" filter option to 1 will enable this mode.
Example usage of perf::
$# perf stat -a -e hns3_pmu_sicl_0/config=0x1020F,global=1/ -I 1000
2. port mode
PMU collect performance statistic of one whole physical port. The port id
is same as mac id. The "tc" filter option must be set to 0xF in this mode,
here tc stands for traffic class.
Example usage of perf::
$# perf stat -a -e hns3_pmu_sicl_0/config=0x1020F,port=0,tc=0xF/ -I 1000
3. port-tc mode
PMU collect performance statistic of one tc of physical port. The port id
is same as mac id. The "tc" filter option must be set to 0 ~ 7 in this
mode.
Example usage of perf::
$# perf stat -a -e hns3_pmu_sicl_0/config=0x1020F,port=0,tc=0/ -I 1000
4. func mode
PMU collect performance statistic of one PF/VF. The function id is BDF of
PF/VF, its conversion formula::
func = (bus << 8) + (device << 3) + (function)
for example:
BDF func
35:00.0 0x3500
35:00.1 0x3501
35:01.0 0x3508
In this mode, the "queue" filter option must be set to 0xFFFF.
Example usage of perf::
$# perf stat -a -e hns3_pmu_sicl_0/config=0x1020F,bdf=0x3500,queue=0xFFFF/ -I 1000
5. func-queue mode
PMU collect performance statistic of one queue of PF/VF. The function id
is BDF of PF/VF, the "queue" filter option must be set to the exact queue
id of function.
Example usage of perf::
$# perf stat -a -e hns3_pmu_sicl_0/config=0x1020F,bdf=0x3500,queue=0/ -I 1000
6. func-intr mode
PMU collect performance statistic of one interrupt of PF/VF. The function
id is BDF of PF/VF, the "intr" filter option must be set to the exact
interrupt id of function.
Example usage of perf::
$# perf stat -a -e hns3_pmu_sicl_0/config=0x00301,bdf=0x3500,intr=0/ -I 1000

View File

@ -9,6 +9,7 @@ Performance monitor support
hisi-pmu
hisi-pcie-pmu
hns3-pmu
imx-ddr
qcom_l2_pmu
qcom_l3_pmu

View File

@ -612,8 +612,8 @@ the ``menu`` governor to be used on the systems that use the ``ladder`` governor
by default this way, for example.
The other kernel command line parameters controlling CPU idle time management
described below are only relevant for the *x86* architecture and some of
them affect Intel processors only.
described below are only relevant for the *x86* architecture and references
to ``intel_idle`` affect Intel processors only.
The *x86* architecture support code recognizes three kernel command line
options related to CPU idle time management: ``idle=poll``, ``idle=halt``,
@ -635,10 +635,13 @@ idle, so it very well may hurt single-thread computations performance as well as
energy-efficiency. Thus using it for performance reasons may not be a good idea
at all.]
The ``idle=nomwait`` option disables the ``intel_idle`` driver and causes
``acpi_idle`` to be used (as long as all of the information needed by it is
there in the system's ACPI tables), but it is not allowed to use the
``MWAIT`` instruction of the CPUs to ask the hardware to enter idle states.
The ``idle=nomwait`` option prevents the use of ``MWAIT`` instruction of
the CPU to enter idle states. When this option is used, the ``acpi_idle``
driver will use the ``HLT`` instruction instead of ``MWAIT``. On systems
running Intel processors, this option disables the ``intel_idle`` driver
and forces the use of the ``acpi_idle`` driver instead. Note that in either
case, ``acpi_idle`` driver will function only if all the information needed
by it is in the system's ACPI tables.
In addition to the architecture-level kernel command line options affecting CPU
idle time management, there are parameters affecting individual ``CPUIdle``

View File

@ -38,8 +38,8 @@ acct
If BSD-style process accounting is enabled these values control
its behaviour. If free space on filesystem where the log lives
goes below ``lowwater``% accounting suspends. If free space gets
above ``highwater``% accounting resumes. ``frequency`` determines
goes below ``lowwater``\ % accounting suspends. If free space gets
above ``highwater``\ % accounting resumes. ``frequency`` determines
how often do we check the amount of free space (value is in
seconds). Default:

View File

@ -100,6 +100,7 @@ Bit Log Number Reason that got the kernel tainted
15 _/K 32768 kernel has been live patched
16 _/X 65536 auxiliary taint, defined for and used by distros
17 _/T 131072 kernel was built with the struct randomization plugin
18 _/N 262144 an in-kernel test has been run
=== === ====== ========================================================
Note: The character ``_`` is representing a blank in this table to make reading

View File

@ -0,0 +1,69 @@
.. SPDX-License-Identifier: GPL-2.0
======================================
Chromebook Boot Flow
======================================
Most recent Chromebooks that use device tree are using the opensource
depthcharge_ bootloader. Depthcharge_ expects the OS to be packaged as a `FIT
Image`_ which contains an OS image as well as a collection of device trees. It
is up to depthcharge_ to pick the right device tree from the `FIT Image`_ and
provide it to the OS.
The scheme that depthcharge_ uses to pick the device tree takes into account
three variables:
- Board name, specified at depthcharge_ compile time. This is $(BOARD) below.
- Board revision number, determined at runtime (perhaps by reading GPIO
strappings, perhaps via some other method). This is $(REV) below.
- SKU number, read from GPIO strappings at boot time. This is $(SKU) below.
For recent Chromebooks, depthcharge_ creates a match list that looks like this:
- google,$(BOARD)-rev$(REV)-sku$(SKU)
- google,$(BOARD)-rev$(REV)
- google,$(BOARD)-sku$(SKU)
- google,$(BOARD)
Note that some older Chromebooks use a slightly different list that may
not include SKU matching or may prioritize SKU/rev differently.
Note that for some boards there may be extra board-specific logic to inject
extra compatibles into the list, but this is uncommon.
Depthcharge_ will look through all device trees in the `FIT Image`_ trying to
find one that matches the most specific compatible. It will then look
through all device trees in the `FIT Image`_ trying to find the one that
matches the *second most* specific compatible, etc.
When searching for a device tree, depthcharge_ doesn't care where the
compatible string falls within a device tree's root compatible string array.
As an example, if we're on board "lazor", rev 4, SKU 0 and we have two device
trees:
- "google,lazor-rev5-sku0", "google,lazor-rev4-sku0", "qcom,sc7180"
- "google,lazor", "qcom,sc7180"
Then depthcharge_ will pick the first device tree even though
"google,lazor-rev4-sku0" was the second compatible listed in that device tree.
This is because it is a more specific compatible than "google,lazor".
It should be noted that depthcharge_ does not have any smarts to try to
match board or SKU revisions that are "close by". That is to say that
if depthcharge_ knows it's on "rev4" of a board but there is no "rev4"
device tree then depthcharge_ *won't* look for a "rev3" device tree.
In general when any significant changes are made to a board the board
revision number is increased even if none of those changes need to
be reflected in the device tree. Thus it's fairly common to see device
trees with multiple revisions.
It should be noted that, taking into account the above system that
depthcharge_ has, the most flexibility is achieved if the device tree
supporting the newest revision(s) of a board omits the "-rev{REV}"
compatible strings. When this is done then if you get a new board
revision and try to run old software on it then we'll at pick the
newest device tree we know about.
.. _depthcharge: https://source.chromium.org/chromiumos/chromiumos/codesearch/+/main:src/platform/depthcharge/
.. _`FIT Image`: https://doc.coreboot.org/lib/payloads/fit.html

View File

@ -31,6 +31,8 @@ SoC-specific documents
.. toctree::
:maxdepth: 1
google/chromebook-boot-flow
ixp4xx
marvell

View File

@ -171,96 +171,73 @@ HWCAP_PACG
Documentation/arm64/pointer-authentication.rst.
HWCAP2_DCPODP
Functionality implied by ID_AA64ISAR1_EL1.DPB == 0b0010.
HWCAP2_SVE2
Functionality implied by ID_AA64ZFR0_EL1.SVEVer == 0b0001.
HWCAP2_SVEAES
Functionality implied by ID_AA64ZFR0_EL1.AES == 0b0001.
HWCAP2_SVEPMULL
Functionality implied by ID_AA64ZFR0_EL1.AES == 0b0010.
HWCAP2_SVEBITPERM
Functionality implied by ID_AA64ZFR0_EL1.BitPerm == 0b0001.
HWCAP2_SVESHA3
Functionality implied by ID_AA64ZFR0_EL1.SHA3 == 0b0001.
HWCAP2_SVESM4
Functionality implied by ID_AA64ZFR0_EL1.SM4 == 0b0001.
HWCAP2_FLAGM2
Functionality implied by ID_AA64ISAR0_EL1.TS == 0b0010.
HWCAP2_FRINT
Functionality implied by ID_AA64ISAR1_EL1.FRINTTS == 0b0001.
HWCAP2_SVEI8MM
Functionality implied by ID_AA64ZFR0_EL1.I8MM == 0b0001.
HWCAP2_SVEF32MM
Functionality implied by ID_AA64ZFR0_EL1.F32MM == 0b0001.
HWCAP2_SVEF64MM
Functionality implied by ID_AA64ZFR0_EL1.F64MM == 0b0001.
HWCAP2_SVEBF16
Functionality implied by ID_AA64ZFR0_EL1.BF16 == 0b0001.
HWCAP2_I8MM
Functionality implied by ID_AA64ISAR1_EL1.I8MM == 0b0001.
HWCAP2_BF16
Functionality implied by ID_AA64ISAR1_EL1.BF16 == 0b0001.
HWCAP2_DGH
Functionality implied by ID_AA64ISAR1_EL1.DGH == 0b0001.
HWCAP2_RNG
Functionality implied by ID_AA64ISAR0_EL1.RNDR == 0b0001.
HWCAP2_BTI
Functionality implied by ID_AA64PFR0_EL1.BT == 0b0001.
HWCAP2_MTE
Functionality implied by ID_AA64PFR1_EL1.MTE == 0b0010, as described
by Documentation/arm64/memory-tagging-extension.rst.
HWCAP2_ECV
Functionality implied by ID_AA64MMFR0_EL1.ECV == 0b0001.
HWCAP2_AFP
Functionality implied by ID_AA64MFR1_EL1.AFP == 0b0001.
HWCAP2_RPRES
Functionality implied by ID_AA64ISAR2_EL1.RPRES == 0b0001.
HWCAP2_MTE3
Functionality implied by ID_AA64PFR1_EL1.MTE == 0b0011, as described
by Documentation/arm64/memory-tagging-extension.rst.
@ -301,6 +278,10 @@ HWCAP2_WFXT
Functionality implied by ID_AA64ISAR2_EL1.WFXT == 0b0010.
HWCAP2_EBF16
Functionality implied by ID_AA64ISAR1_EL1.BF16 == 0b0010.
4. Unused AT_HWCAP bits
-----------------------

View File

@ -33,9 +33,8 @@ AArch64 Linux memory layout with 4KB pages + 4 levels (48-bit)::
0000000000000000 0000ffffffffffff 256TB user
ffff000000000000 ffff7fffffffffff 128TB kernel logical memory map
[ffff600000000000 ffff7fffffffffff] 32TB [kasan shadow region]
ffff800000000000 ffff800007ffffff 128MB bpf jit region
ffff800008000000 ffff80000fffffff 128MB modules
ffff800010000000 fffffbffefffffff 124TB vmalloc
ffff800000000000 ffff800007ffffff 128MB modules
ffff800008000000 fffffbffefffffff 124TB vmalloc
fffffbfff0000000 fffffbfffdffffff 224MB fixed mappings (top down)
fffffbfffe000000 fffffbfffe7fffff 8MB [guard region]
fffffbfffe800000 fffffbffff7fffff 16MB PCI I/O space
@ -51,9 +50,8 @@ AArch64 Linux memory layout with 64KB pages + 3 levels (52-bit with HW support):
0000000000000000 000fffffffffffff 4PB user
fff0000000000000 ffff7fffffffffff ~4PB kernel logical memory map
[fffd800000000000 ffff7fffffffffff] 512TB [kasan shadow region]
ffff800000000000 ffff800007ffffff 128MB bpf jit region
ffff800008000000 ffff80000fffffff 128MB modules
ffff800010000000 fffffbffefffffff 124TB vmalloc
ffff800000000000 ffff800007ffffff 128MB modules
ffff800008000000 fffffbffefffffff 124TB vmalloc
fffffbfff0000000 fffffbfffdffffff 224MB fixed mappings (top down)
fffffbfffe000000 fffffbfffe7fffff 8MB [guard region]
fffffbfffe800000 fffffbffff7fffff 16MB PCI I/O space

View File

@ -82,10 +82,14 @@ stable kernels.
+----------------+-----------------+-----------------+-----------------------------+
| ARM | Cortex-A57 | #1319537 | ARM64_ERRATUM_1319367 |
+----------------+-----------------+-----------------+-----------------------------+
| ARM | Cortex-A57 | #1742098 | ARM64_ERRATUM_1742098 |
+----------------+-----------------+-----------------+-----------------------------+
| ARM | Cortex-A72 | #853709 | N/A |
+----------------+-----------------+-----------------+-----------------------------+
| ARM | Cortex-A72 | #1319367 | ARM64_ERRATUM_1319367 |
+----------------+-----------------+-----------------+-----------------------------+
| ARM | Cortex-A72 | #1655431 | ARM64_ERRATUM_1742098 |
+----------------+-----------------+-----------------+-----------------------------+
| ARM | Cortex-A73 | #858921 | ARM64_ERRATUM_858921 |
+----------------+-----------------+-----------------+-----------------------------+
| ARM | Cortex-A76 | #1188873,1418040| ARM64_ERRATUM_1418040 |
@ -102,6 +106,8 @@ stable kernels.
+----------------+-----------------+-----------------+-----------------------------+
| ARM | Cortex-A510 | #2077057 | ARM64_ERRATUM_2077057 |
+----------------+-----------------+-----------------+-----------------------------+
| ARM | Cortex-A510 | #2441009 | ARM64_ERRATUM_2441009 |
+----------------+-----------------+-----------------+-----------------------------+
| ARM | Cortex-A710 | #2119858 | ARM64_ERRATUM_2119858 |
+----------------+-----------------+-----------------+-----------------------------+
| ARM | Cortex-A710 | #2054223 | ARM64_ERRATUM_2054223 |

View File

@ -17,6 +17,9 @@ solution to the problem to avoid everybody inventing their own. The IDR
provides the ability to map an ID to a pointer, while the IDA provides
only ID allocation, and as a result is much more memory-efficient.
The IDR interface is deprecated; please use the :doc:`XArray <xarray>`
instead.
IDR usage
=========

View File

@ -4,31 +4,29 @@
Memory Protection Keys
======================
Memory Protection Keys for Userspace (PKU aka PKEYs) is a feature
which is found on Intel's Skylake (and later) "Scalable Processor"
Server CPUs. It will be available in future non-server Intel parts
and future AMD processors.
Memory Protection Keys provide a mechanism for enforcing page-based
protections, but without requiring modification of the page tables when an
application changes protection domains.
For anyone wishing to test or use this feature, it is available in
Amazon's EC2 C5 instances and is known to work there using an Ubuntu
17.04 image.
Pkeys Userspace (PKU) is a feature which can be found on:
* Intel server CPUs, Skylake and later
* Intel client CPUs, Tiger Lake (11th Gen Core) and later
* Future AMD CPUs
Memory Protection Keys provides a mechanism for enforcing page-based
protections, but without requiring modification of the page tables
when an application changes protection domains. It works by
dedicating 4 previously ignored bits in each page table entry to a
"protection key", giving 16 possible keys.
Pkeys work by dedicating 4 previously Reserved bits in each page table entry to
a "protection key", giving 16 possible keys.
There is also a new user-accessible register (PKRU) with two separate
bits (Access Disable and Write Disable) for each key. Being a CPU
register, PKRU is inherently thread-local, potentially giving each
Protections for each key are defined with a per-CPU user-accessible register
(PKRU). Each of these is a 32-bit register storing two bits (Access Disable
and Write Disable) for each of 16 keys.
Being a CPU register, PKRU is inherently thread-local, potentially giving each
thread a different set of protections from every other thread.
There are two new instructions (RDPKRU/WRPKRU) for reading and writing
to the new register. The feature is only available in 64-bit mode,
even though there is theoretically space in the PAE PTEs. These
permissions are enforced on data access only and have no effect on
instruction fetches.
There are two instructions (RDPKRU/WRPKRU) for reading and writing to the
register. The feature is only available in 64-bit mode, even though there is
theoretically space in the PAE PTEs. These permissions are enforced on data
access only and have no effect on instruction fetches.
Syscalls
========

View File

@ -66,7 +66,7 @@ The wiki documentation always refers to the linux-next version of the script.
For Semantic Patch Language(SmPL) grammar documentation refer to:
http://coccinelle.lip6.fr/documentation.php
https://coccinelle.gitlabpages.inria.fr/website/docs/main_grammar.html
Using Coccinelle on the Linux kernel
------------------------------------

View File

@ -208,6 +208,14 @@ In general, the rules for selftests are
Contributing new tests (details)
================================
* In your Makefile, use facilities from lib.mk by including it instead of
reinventing the wheel. Specify flags and binaries generation flags on
need basis before including lib.mk. ::
CFLAGS = $(KHDR_INCLUDES)
TEST_GEN_PROGS := close_range_test
include ../lib.mk
* Use TEST_GEN_XXX if such binaries or files are generated during
compiling.
@ -230,13 +238,30 @@ Contributing new tests (details)
* First use the headers inside the kernel source and/or git repo, and then the
system headers. Headers for the kernel release as opposed to headers
installed by the distro on the system should be the primary focus to be able
to find regressions.
to find regressions. Use KHDR_INCLUDES in Makefile to include headers from
the kernel source.
* If a test needs specific kernel config options enabled, add a config file in
the test directory to enable them.
e.g: tools/testing/selftests/android/config
* Create a .gitignore file inside test directory and add all generated objects
in it.
* Add new test name in TARGETS in selftests/Makefile::
TARGETS += android
* All changes should pass::
kselftest-{all,install,clean,gen_tar}
kselftest-{all,install,clean,gen_tar} O=abo_path
kselftest-{all,install,clean,gen_tar} O=rel_path
make -C tools/testing/selftests {all,install,clean,gen_tar}
make -C tools/testing/selftests {all,install,clean,gen_tar} O=abs_path
make -C tools/testing/selftests {all,install,clean,gen_tar} O=rel_path
Test Module
===========
@ -250,6 +275,14 @@ assist writing kernel modules that are for use with kselftest:
- ``tools/testing/selftests/kselftest_module.h``
- ``tools/testing/selftests/kselftest/module.sh``
Note that test modules should taint the kernel with TAINT_TEST. This will
happen automatically for modules which are in the ``tools/testing/``
directory, or for modules which use the ``kselftest_module.h`` header above.
Otherwise, you'll need to add ``MODULE_INFO(test, "Y")`` to your module
source. selftests which do not load modules typically should not taint the
kernel, but in cases where a non-test module is loaded, TEST_TAINT can be
applied from userspace by writing to ``/proc/sys/kernel/tainted``.
How to use
----------
@ -308,6 +341,7 @@ A bare bones test module might look like this:
KSTM_MODULE_LOADERS(test_foo);
MODULE_AUTHOR("John Developer <jd@fooman.org>");
MODULE_LICENSE("GPL");
MODULE_INFO(test, "Y");
Example test script
-------------------

View File

@ -192,6 +192,21 @@ via UML. To run tests on qemu, by default it requires two flags:
if we have downloaded the microblaze toolchain from the 0-day
website to a directory in our home directory called toolchains.
This means that for most architectures, running under qemu is as simple as:
.. code-block:: bash
./tools/testing/kunit/kunit.py run --arch=x86_64
When cross-compiling, we'll likely need to specify a different toolchain, for
example:
.. code-block:: bash
./tools/testing/kunit/kunit.py run \
--arch=s390 \
--cross_compile=s390x-linux-gnu-
If we want to run KUnit tests on an architecture not supported by
the ``--arch`` flag, or want to run KUnit tests on qemu using a
non-default configuration; then we can write our own``QemuConfig``.
@ -214,14 +229,11 @@ as
--jobs=12 \
--qemu_config=./tools/testing/kunit/qemu_configs/x86_64.py
To run existing KUnit tests on non-UML architectures, see:
Documentation/dev-tools/kunit/non_uml.rst.
Command-Line Arguments
======================
kunit_tool has a number of other command-line arguments which can
be useful for our test environment. Below the most commonly used
be useful for our test environment. Below are the most commonly used
command line arguments:
- ``--help``: Lists all available options. To list common options,
@ -245,3 +257,64 @@ command line arguments:
added or modified. Instead, enable all tests
which have satisfied dependencies by adding
``CONFIG_KUNIT_ALL_TESTS=y`` to your ``.kunitconfig``.
- ``--kunitconfig``: Specifies the path or the directory of the ``.kunitconfig``
file. For example:
- ``lib/kunit/.kunitconfig`` can be the path of the file.
- ``lib/kunit`` can be the directory in which the file is located.
This file is used to build and run with a predefined set of tests
and their dependencies. For example, to run tests for a given subsystem.
- ``--kconfig_add``: Specifies additional configuration options to be
appended to the ``.kunitconfig`` file. For example:
.. code-block::
./tools/testing/kunit/kunit.py run --kconfig_add CONFIG_KASAN=y
- ``--arch``: Runs tests on the specified architecture. The architecture
argument is same as the Kbuild ARCH environment variable.
For example, i386, x86_64, arm, um, etc. Non-UML architectures run on qemu.
Default is `um`.
- ``--cross_compile``: Specifies the Kbuild toolchain. It passes the
same argument as passed to the ``CROSS_COMPILE`` variable used by
Kbuild. This will be the prefix for the toolchain
binaries such as GCC. For example:
- ``sparc64-linux-gnu-`` if we have the sparc toolchain installed on
our system.
- ``$HOME/toolchains/microblaze/gcc-9.2.0-nolibc/microblaze-linux/bin/microblaze-linux``
if we have downloaded the microblaze toolchain from the 0-day
website to a specified path in our home directory called toolchains.
- ``--qemu_config``: Specifies the path to a file containing a
custom qemu architecture definition. This should be a python file
containing a `QemuArchParams` object.
- ``--qemu_args``: Specifies additional qemu arguments, for example, ``-smp 8``.
- ``--jobs``: Specifies the number of jobs (commands) to run simultaneously.
By default, this is set to the number of cores on your system.
- ``--timeout``: Specifies the maximum number of seconds allowed for all tests to run.
This does not include the time taken to build the tests.
- ``--kernel_args``: Specifies additional kernel command-line arguments. May be repeated.
- ``--run_isolated``: If set, boots the kernel for each individual suite/test.
This is useful for debugging a non-hermetic test, one that
might pass/fail based on what ran before it.
- ``--raw_output``: If set, generates unformatted output from kernel. Possible options are:
- ``all``: To view the full kernel output, use ``--raw_output=all``.
- ``kunit``: This is the default option and filters to KUnit output. Use ``--raw_output`` or ``--raw_output=kunit``.
- ``--json``: If set, stores the test results in a JSON format and prints to `stdout` or
saves to a file if a filename is specified.

View File

@ -15,7 +15,7 @@ It can be handy to create a bash function like:
.. code-block:: bash
function run_kunit() {
( cd "$(git rev-parse --show-toplevel)" && ./tools/testing/kunit/kunit.py run $@ )
( cd "$(git rev-parse --show-toplevel)" && ./tools/testing/kunit/kunit.py run "$@" )
}
.. note::
@ -123,8 +123,7 @@ Putting it together into a copy-pastable sequence of commands:
.. code-block:: bash
# Append coverage options to the current config
$ echo -e "CONFIG_DEBUG_KERNEL=y\nCONFIG_DEBUG_INFO=y\nCONFIG_DEBUG_INFO_DWARF_TOOLCHAIN_DEFAULT=y\nCONFIG_GCOV=y" >> .kunit/.kunitconfig
$ ./tools/testing/kunit/kunit.py run
$ ./tools/testing/kunit/kunit.py run --kunitconfig=.kunit/ --kunitconfig=tools/testing/kunit/configs/coverage_uml.config
# Extract the coverage information from the build dir (.kunit/)
$ lcov -t "my_kunit_tests" -o coverage.info -c -d .kunit/

View File

@ -505,7 +505,7 @@ By reusing the same ``cases`` array from above, we can write the test as a
const char *str;
const char *sha1;
};
struct sha1_test_case cases[] = {
const struct sha1_test_case cases[] = {
{
.str = "hello world",
.sha1 = "2aae6c35c94fcfb415dbe95f408b9ce91ee846ed",

View File

@ -25,7 +25,14 @@ properties:
items:
- enum:
- altr,socfpga-arria10-socdk
- enclustra,mercury-aa1
- const: altr,socfpga-arria10
- const: altr,socfpga
- description: Mercury+ AA1 boards
items:
- enum:
- google,chameleon-v3
- const: enclustra,mercury-aa1
- const: altr,socfpga-arria10
- const: altr,socfpga
@ -47,6 +54,7 @@ properties:
items:
- enum:
- altr,socfpga-stratix10-socdk
- altr,socfpga-stratix10-swvp
- const: altr,socfpga-stratix10
- description: SoCFPGA VT

View File

@ -0,0 +1,87 @@
# SPDX-License-Identifier: GPL-2.0-only or BSD-2-Clause
%YAML 1.2
---
$id: http://devicetree.org/schemas/arm/aspeed/aspeed.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Aspeed SoC based boards
maintainers:
- Joel Stanley <joel@jms.id.au>
properties:
$nodename:
const: '/'
compatible:
oneOf:
- description: AST2400 based boards
items:
- enum:
- facebook,galaxy100-bmc
- facebook,wedge100-bmc
- facebook,wedge40-bmc
- microsoft,olympus-bmc
- quanta,q71l-bmc
- tyan,palmetto-bmc
- yadro,vesnin-bmc
- const: aspeed,ast2400
- description: AST2500 based boards
items:
- enum:
- amd,ethanolx-bmc
- ampere,mtjade-bmc
- aspeed,ast2500-evb
- asrock,e3c246d4i-bmc
- asrock,romed8hm3-bmc
- bytedance,g220a-bmc
- facebook,cmm-bmc
- facebook,minipack-bmc
- facebook,tiogapass-bmc
- facebook,yamp-bmc
- facebook,yosemitev2-bmc
- facebook,wedge400-bmc
- hxt,stardragon4800-rep2-bmc
- ibm,mihawk-bmc
- ibm,mowgli-bmc
- ibm,romulus-bmc
- ibm,swift-bmc
- ibm,witherspoon-bmc
- ingrasys,zaius-bmc
- inspur,fp5280g2-bmc
- inspur,nf5280m6-bmc
- inspur,on5263m5-bmc
- intel,s2600wf-bmc
- inventec,lanyang-bmc
- lenovo,hr630-bmc
- lenovo,hr855xg2-bmc
- portwell,neptune-bmc
- qcom,centriq2400-rep-bmc
- supermicro,x11spi-bmc
- tyan,s7106-bmc
- tyan,s8036-bmc
- yadro,nicole-bmc
- yadro,vegman-n110-bmc
- yadro,vegman-rx20-bmc
- yadro,vegman-sx20-bmc
- const: aspeed,ast2500
- description: AST2600 based boards
items:
- enum:
- aspeed,ast2600-evb
- aspeed,ast2600-evb-a1
- facebook,bletchley-bmc
- facebook,cloudripper-bmc
- facebook,elbert-bmc
- facebook,fuji-bmc
- ibm,everest-bmc
- ibm,rainier-bmc
- ibm,tacoma-bmc
- inventec,transformer-bmc
- jabil,rbp-bmc
- nuvia,dc-scm-bmc
- quanta,s6q-bmc
- const: aspeed,ast2600
additionalProperties: true

View File

@ -163,9 +163,11 @@ properties:
- const: microchip,sama7g5
- const: microchip,sama7
- description: Microchip LAN9662 PCB8291 Evaluation Board.
- description: Microchip LAN9662 Evaluation Boards.
items:
- const: microchip,lan9662-pcb8291
- enum:
- microchip,lan9662-pcb8291
- microchip,lan9662-pcb8309
- const: microchip,lan9662
- const: microchip,lan966

View File

@ -87,6 +87,13 @@ properties:
- const: brcm,bcm53012
- const: brcm,bcm4708
- description: BCM53015 based boards
items:
- enum:
- meraki,mr26
- const: brcm,bcm53015
- const: brcm,bcm4708
- description: BCM53016 based boards
items:
- enum:

View File

@ -28,6 +28,99 @@ properties:
- const: brcm,bcm47622
- const: brcm,bcmbca
- description: BCM4912 based boards
items:
- enum:
- asus,gt-ax6000
- brcm,bcm94912
- const: brcm,bcm4912
- const: brcm,bcmbca
- description: BCM63138 based boards
items:
- enum:
- brcm,bcm963138
- brcm,BCM963138DVT
- const: brcm,bcm63138
- const: brcm,bcmbca
- description: BCM63146 based boards
items:
- enum:
- brcm,bcm963146
- const: brcm,bcm63146
- const: brcm,bcmbca
- description: BCM63148 based boards
items:
- enum:
- brcm,bcm963148
- const: brcm,bcm63148
- const: brcm,bcmbca
- description: BCM63158 based boards
items:
- enum:
- brcm,bcm963158
- const: brcm,bcm63158
- const: brcm,bcmbca
- description: BCM63178 based boards
items:
- enum:
- brcm,bcm963178
- const: brcm,bcm63178
- const: brcm,bcmbca
- description: BCM6756 based boards
items:
- enum:
- brcm,bcm96756
- const: brcm,bcm6756
- const: brcm,bcmbca
- description: BCM6813 based boards
items:
- enum:
- brcm,bcm96813
- const: brcm,bcm6813
- const: brcm,bcmbca
- description: BCM6846 based boards
items:
- enum:
- brcm,bcm96846
- const: brcm,bcm6846
- const: brcm,bcmbca
- description: BCM6855 based boards
items:
- enum:
- brcm,bcm96855
- const: brcm,bcm6855
- const: brcm,bcmbca
- description: BCM6856 based boards
items:
- enum:
- brcm,bcm96856
- const: brcm,bcm6856
- const: brcm,bcmbca
- description: BCM6858 based boards
items:
- enum:
- brcm,bcm96858
- const: brcm,bcm6858
- const: brcm,bcmbca
- description: BCM6878 based boards
items:
- enum:
- brcm,bcm96878
- const: brcm,bcm6878
- const: brcm,bcmbca
additionalProperties: true
...

View File

@ -221,6 +221,7 @@ properties:
- qcom,kpss-acc-v1
- qcom,kpss-acc-v2
- qcom,msm8226-smp
- qcom,msm8909-smp
# Only valid on ARM 32-bit, see above for ARM v8 64-bit
- qcom,msm8916-smp
- renesas,apmu

View File

@ -1,271 +0,0 @@
NXP i.MX System Controller Firmware (SCFW)
--------------------------------------------------------------------
The System Controller Firmware (SCFW) is a low-level system function
which runs on a dedicated Cortex-M core to provide power, clock, and
resource management. It exists on some i.MX8 processors. e.g. i.MX8QM
(QM, QP), and i.MX8QX (QXP, DX).
The AP communicates with the SC using a multi-ported MU module found
in the LSIO subsystem. The current definition of this MU module provides
5 remote AP connections to the SC to support up to 5 execution environments
(TZ, HV, standard Linux, etc.). The SC side of this MU module interfaces
with the LSIO DSC IP bus. The SC firmware will communicate with this MU
using the MSI bus.
System Controller Device Node:
============================================================
The scu node with the following properties shall be under the /firmware/ node.
Required properties:
-------------------
- compatible: should be "fsl,imx-scu".
- mbox-names: should include "tx0", "tx1", "tx2", "tx3",
"rx0", "rx1", "rx2", "rx3";
include "gip3" if want to support general MU interrupt.
- mboxes: List of phandle of 4 MU channels for tx, 4 MU channels for
rx, and 1 optional MU channel for general interrupt.
All MU channels must be in the same MU instance.
Cross instances are not allowed. The MU instance can only
be one of LSIO MU0~M4 for imx8qxp and imx8qm. Users need
to make sure use the one which is not conflict with other
execution environments. e.g. ATF.
Note:
Channel 0 must be "tx0" or "rx0".
Channel 1 must be "tx1" or "rx1".
Channel 2 must be "tx2" or "rx2".
Channel 3 must be "tx3" or "rx3".
General interrupt rx channel must be "gip3".
e.g.
mboxes = <&lsio_mu1 0 0
&lsio_mu1 0 1
&lsio_mu1 0 2
&lsio_mu1 0 3
&lsio_mu1 1 0
&lsio_mu1 1 1
&lsio_mu1 1 2
&lsio_mu1 1 3
&lsio_mu1 3 3>;
See Documentation/devicetree/bindings/mailbox/fsl,mu.yaml
for detailed mailbox binding.
Note: Each mu which supports general interrupt should have an alias correctly
numbered in "aliases" node.
e.g.
aliases {
mu1 = &lsio_mu1;
};
i.MX SCU Client Device Node:
============================================================
Client nodes are maintained as children of the relevant IMX-SCU device node.
Power domain bindings based on SCU Message Protocol
------------------------------------------------------------
This binding for the SCU power domain providers uses the generic power
domain binding[2].
Required properties:
- compatible: Should be one of:
"fsl,imx8qm-scu-pd",
"fsl,imx8qxp-scu-pd"
followed by "fsl,scu-pd"
- #power-domain-cells: Must be 1. Contains the Resource ID used by
SCU commands.
See detailed Resource ID list from:
include/dt-bindings/firmware/imx/rsrc.h
Clock bindings based on SCU Message Protocol
------------------------------------------------------------
This binding uses the common clock binding[1].
Required properties:
- compatible: Should be one of:
"fsl,imx8dxl-clk"
"fsl,imx8qm-clk"
"fsl,imx8qxp-clk"
followed by "fsl,scu-clk"
- #clock-cells: Should be 2.
Contains the Resource and Clock ID value.
- clocks: List of clock specifiers, must contain an entry for
each required entry in clock-names
- clock-names: Should include entries "xtal_32KHz", "xtal_24MHz"
The clock consumer should specify the desired clock by having the clock
ID in its "clocks" phandle cell.
See the full list of clock IDs from:
include/dt-bindings/clock/imx8qxp-clock.h
Pinctrl bindings based on SCU Message Protocol
------------------------------------------------------------
This binding uses the i.MX common pinctrl binding[3].
Required properties:
- compatible: Should be one of:
"fsl,imx8qm-iomuxc",
"fsl,imx8qxp-iomuxc",
"fsl,imx8dxl-iomuxc".
Required properties for Pinctrl sub nodes:
- fsl,pins: Each entry consists of 3 integers which represents
the mux and config setting for one pin. The first 2
integers <pin_id mux_mode> are specified using a
PIN_FUNC_ID macro, which can be found in
<dt-bindings/pinctrl/pads-imx8qm.h>,
<dt-bindings/pinctrl/pads-imx8qxp.h>,
<dt-bindings/pinctrl/pads-imx8dxl.h>.
The last integer CONFIG is the pad setting value like
pull-up on this pin.
Please refer to i.MX8QXP Reference Manual for detailed
CONFIG settings.
[1] Documentation/devicetree/bindings/clock/clock-bindings.txt
[2] Documentation/devicetree/bindings/power/power-domain.yaml
[3] Documentation/devicetree/bindings/pinctrl/fsl,imx-pinctrl.txt
RTC bindings based on SCU Message Protocol
------------------------------------------------------------
Required properties:
- compatible: should be "fsl,imx8qxp-sc-rtc";
OCOTP bindings based on SCU Message Protocol
------------------------------------------------------------
Required properties:
- compatible: Should be one of:
"fsl,imx8qm-scu-ocotp",
"fsl,imx8qxp-scu-ocotp".
- #address-cells: Must be 1. Contains byte index
- #size-cells: Must be 1. Contains byte length
Optional Child nodes:
- Data cells of ocotp:
Detailed bindings are described in bindings/nvmem/nvmem.txt
Watchdog bindings based on SCU Message Protocol
------------------------------------------------------------
Required properties:
- compatible: should be:
"fsl,imx8qxp-sc-wdt"
followed by "fsl,imx-sc-wdt";
Optional properties:
- timeout-sec: contains the watchdog timeout in seconds.
SCU key bindings based on SCU Message Protocol
------------------------------------------------------------
Required properties:
- compatible: should be:
"fsl,imx8qxp-sc-key"
followed by "fsl,imx-sc-key";
- 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-sensor.yaml
for a description.
Example (imx8qxp):
-------------
aliases {
mu1 = &lsio_mu1;
};
lsio_mu1: mailbox@5d1c0000 {
...
#mbox-cells = <2>;
};
firmware {
scu {
compatible = "fsl,imx-scu";
mbox-names = "tx0", "tx1", "tx2", "tx3",
"rx0", "rx1", "rx2", "rx3",
"gip3";
mboxes = <&lsio_mu1 0 0
&lsio_mu1 0 1
&lsio_mu1 0 2
&lsio_mu1 0 3
&lsio_mu1 1 0
&lsio_mu1 1 1
&lsio_mu1 1 2
&lsio_mu1 1 3
&lsio_mu1 3 3>;
clk: clk {
compatible = "fsl,imx8qxp-clk", "fsl,scu-clk";
#clock-cells = <2>;
};
iomuxc {
compatible = "fsl,imx8qxp-iomuxc";
pinctrl_lpuart0: lpuart0grp {
fsl,pins = <
SC_P_UART0_RX_ADMA_UART0_RX 0x06000020
SC_P_UART0_TX_ADMA_UART0_TX 0x06000020
>;
};
...
};
ocotp: imx8qx-ocotp {
compatible = "fsl,imx8qxp-scu-ocotp";
#address-cells = <1>;
#size-cells = <1>;
fec_mac0: mac@2c4 {
reg = <0x2c4 8>;
};
};
pd: imx8qx-pd {
compatible = "fsl,imx8qxp-scu-pd", "fsl,scu-pd";
#power-domain-cells = <1>;
};
rtc: rtc {
compatible = "fsl,imx8qxp-sc-rtc";
};
scu_key: scu-key {
compatible = "fsl,imx8qxp-sc-key", "fsl,imx-sc-key";
linux,keycodes = <KEY_POWER>;
};
watchdog {
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>;
};
};
};
serial@5a060000 {
...
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_lpuart0>;
clocks = <&uart0_clk IMX_SC_R_UART_0 IMX_SC_PM_CLK_PER>;
clock-names = "ipg";
power-domains = <&pd IMX_SC_R_UART_0>;
};

View File

@ -321,6 +321,7 @@ properties:
- enum:
- toradex,apalis_imx6q-ixora # Apalis iMX6Q/D Module on Ixora Carrier Board
- toradex,apalis_imx6q-ixora-v1.1 # Apalis iMX6Q/D Module on Ixora V1.1 Carrier Board
- toradex,apalis_imx6q-ixora-v1.2 # Apalis iMX6Q/D Module on Ixora V1.2 Carrier Board
- toradex,apalis_imx6q-eval # Apalis iMX6Q/D Module on Apalis Evaluation Board
- const: toradex,apalis_imx6q
- const: fsl,imx6q
@ -670,30 +671,30 @@ properties:
- description: i.MX6ULL Boards with Toradex Colibri iMX6ULL Modules
items:
- enum:
- toradex,colibri-imx6ull-aster # Colibri iMX6ULL Module on Aster Carrier Board
- toradex,colibri-imx6ull-eval # Colibri iMX6ULL Module on Colibri Evaluation Board V3
- toradex,colibri-imx6ull-iris # Colibri iMX6ULL Module on Iris Carrier Board
- toradex,colibri-imx6ull-iris-v2 # Colibri iMX6ULL Module on Iris V2 Carrier Board
- toradex,colibri-imx6ull-aster # Aster Carrier Board
- toradex,colibri-imx6ull-eval # Colibri Evaluation Board V3
- toradex,colibri-imx6ull-iris # Iris Carrier Board
- toradex,colibri-imx6ull-iris-v2 # Iris V2 Carrier Board
- const: toradex,colibri-imx6ull # Colibri iMX6ULL Module
- const: fsl,imx6ull
- description: i.MX6ULL Boards with Toradex Colibri iMX6ULL 1GB (eMMC) Module
items:
- enum:
- toradex,colibri-imx6ull-emmc-aster # Colibri iMX6ULL 1G (eMMC) on Aster Carrier Board
- toradex,colibri-imx6ull-emmc-eval # Colibri iMX6ULL 1G (eMMC) on Colibri Evaluation B. V3
- toradex,colibri-imx6ull-emmc-iris # Colibri iMX6ULL 1G (eMMC) on Iris Carrier Board
- toradex,colibri-imx6ull-emmc-iris-v2 # Colibri iMX6ULL 1G (eMMC) on Iris V2 Carrier Board
- toradex,colibri-imx6ull-emmc-aster # Aster Carrier Board
- toradex,colibri-imx6ull-emmc-eval # Colibri Evaluation B. V3
- toradex,colibri-imx6ull-emmc-iris # Iris Carrier Board
- toradex,colibri-imx6ull-emmc-iris-v2 # Iris V2 Carrier Board
- const: toradex,colibri-imx6ull-emmc # Colibri iMX6ULL 1GB (eMMC) Module
- const: fsl,imx6ull
- description: i.MX6ULL Boards with Toradex Colibri iMX6ULL Wi-Fi / BT Modules
items:
- enum:
- toradex,colibri-imx6ull-wifi-eval # Colibri iMX6ULL Wi-Fi / BT M. on Colibri Eval. B. V3
- toradex,colibri-imx6ull-wifi-aster # Colibri iMX6ULL Wi-Fi / BT M. on Aster Carrier Board
- toradex,colibri-imx6ull-wifi-iris # Colibri iMX6ULL Wi-Fi / BT M. on Iris Carrier Board
- toradex,colibri-imx6ull-wifi-iris-v2 # Colibri iMX6ULL Wi-Fi / BT M. on Iris V2 Carrier Board
- toradex,colibri-imx6ull-wifi-eval # Colibri Eval. B. V3
- toradex,colibri-imx6ull-wifi-aster # Aster Carrier Board
- toradex,colibri-imx6ull-wifi-iris # Iris Carrier Board
- toradex,colibri-imx6ull-wifi-iris-v2 # Iris V2 Carrier Board
- const: toradex,colibri-imx6ull-wifi # Colibri iMX6ULL Wi-Fi / BT Module
- const: fsl,imx6ull
@ -738,6 +739,8 @@ properties:
- enum:
- toradex,colibri-imx7s-aster # Module on Aster Carrier Board
- toradex,colibri-imx7s-eval-v3 # Module on Colibri Evaluation Board V3
- toradex,colibri-imx7s-iris # Module on Iris Carrier Board
- toradex,colibri-imx7s-iris-v2 # Module on Iris Carrier Board V2
- const: toradex,colibri-imx7s
- const: fsl,imx7s
@ -789,8 +792,10 @@ properties:
- description: i.MX7D Boards with Toradex Colibri i.MX7D Module
items:
- enum:
- toradex,colibri-imx7d-aster # Colibri iMX7D Module on Aster Carrier Board
- toradex,colibri-imx7d-eval-v3 # Colibri iMX7D Module on Colibri Evaluation Board V3
- toradex,colibri-imx7d-aster # Aster Carrier Board
- toradex,colibri-imx7d-eval-v3 # Colibri Evaluation Board V3
- toradex,colibri-imx7d-iris # Iris Carrier Board
- toradex,colibri-imx7d-iris-v2 # Iris Carrier Board V2
- const: toradex,colibri-imx7d
- const: fsl,imx7d
@ -799,6 +804,8 @@ properties:
- enum:
- toradex,colibri-imx7d-emmc-aster # Module on Aster Carrier Board
- toradex,colibri-imx7d-emmc-eval-v3 # Module on Colibri Evaluation Board V3
- toradex,colibri-imx7d-emmc-iris # Module on Iris Carrier Board
- toradex,colibri-imx7d-emmc-iris-v2 # Module on Iris Carrier Board V2
- const: toradex,colibri-imx7d-emmc
- const: fsl,imx7d
@ -865,6 +872,12 @@ properties:
- const: toradex,verdin-imx8mm # Verdin iMX8M Mini Module
- const: fsl,imx8mm
- description: PHYTEC phyCORE-i.MX8MM SoM based boards
items:
- const: phytec,imx8mm-phyboard-polis-rdk # phyBOARD-Polis RDK
- const: phytec,imx8mm-phycore-som # phyCORE-i.MX8MM SoM
- const: fsl,imx8mm
- description: Variscite VAR-SOM-MX8MM based boards
items:
- const: variscite,var-som-mx8mm-symphony
@ -914,6 +927,8 @@ properties:
- description: i.MX8MP based Boards
items:
- enum:
- dh,imx8mp-dhcom-som # i.MX8MP DHCOM SoM
- dh,imx8mp-dhcom-pdk2 # i.MX8MP DHCOM SoM on PDK2 board
- fsl,imx8mp-evk # i.MX8MP EVK Board
- gateworks,imx8mp-gw74xx # i.MX8MP Gateworks Board
- toradex,verdin-imx8mp # Verdin iMX8M Plus Modules
@ -952,6 +967,18 @@ properties:
- const: toradex,verdin-imx8mp # Verdin iMX8M Plus Module
- const: fsl,imx8mp
- description:
TQMa8MPxL is a series of LGA SOM featuring NXP i.MX8MP system-on-chip
variants. It is designed to be soldered on different carrier boards.
All CPU variants use the same device tree hence only one compatible
is needed. MBa8MPxL mainboard can be used as starterkit or in a boxed
version as an industrial computing device.
items:
- enum:
- tq,imx8mp-tqma8mpql-mba8mpxl # TQ-Systems GmbH i.MX8MP TQMa8MPQL SOM on MBa8MPxL
- const: tq,imx8mp-tqma8mpql # TQ-Systems GmbH i.MX8MP TQMa8MPQL SOM
- const: fsl,imx8mp
- description: i.MX8MQ based Boards
items:
- enum:
@ -1020,6 +1047,12 @@ properties:
- fsl,imx8ulp-evk # i.MX8ULP EVK Board
- const: fsl,imx8ulp
- description: i.MX93 based Boards
items:
- enum:
- fsl,imx93-11x11-evk # i.MX93 11x11 EVK Board
- const: fsl,imx93
- description:
Freescale Vybrid Platform Device Tree Bindings

View File

@ -0,0 +1,32 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/arm/marvell/marvell,ac5.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Marvell Alleycat5/5X Platforms
maintainers:
- Chris Packham <chris.packham@alliedtelesis.co.nz>
properties:
$nodename:
const: '/'
compatible:
oneOf:
- description: Alleycat5 (98DX25xx) Reference Design
items:
- enum:
- marvell,rd-ac5
- const: marvell,ac5
- description: Alleycat5X (98DX35xx) Reference Design
items:
- enum:
- marvell,rd-ac5x
- const: marvell,ac5x
- const: marvell,ac5
additionalProperties: true
...

View File

@ -131,6 +131,36 @@ properties:
- enum:
- mediatek,mt8183-evb
- const: mediatek,mt8183
- description: Google Hayato
items:
- const: google,hayato-rev1
- const: google,hayato
- const: mediatek,mt8192
- description: Google Spherion (Acer Chromebook 514)
items:
- const: google,spherion-rev3
- const: google,spherion-rev2
- const: google,spherion-rev1
- const: google,spherion-rev0
- const: google,spherion
- const: mediatek,mt8192
- description: Acer Tomato (Acer Chromebook Spin 513 CP513-2H)
items:
- enum:
- google,tomato-rev2
- google,tomato-rev1
- const: google,tomato
- const: mediatek,mt8195
- description: Acer Tomato rev3 - 4 (Acer Chromebook Spin 513 CP513-2H)
items:
- const: google,tomato-rev4
- const: google,tomato-rev3
- const: google,tomato
- const: mediatek,mt8195
- items:
- enum:
- mediatek,mt8186-evb
- const: mediatek,mt8186
- items:
- enum:
- mediatek,mt8192-evb

View File

@ -26,6 +26,7 @@ properties:
- mediatek,mt8135-pericfg
- mediatek,mt8173-pericfg
- mediatek,mt8183-pericfg
- mediatek,mt8186-pericfg
- mediatek,mt8195-pericfg
- mediatek,mt8516-pericfg
- const: syscon

View File

@ -8,6 +8,7 @@ title: NPCM Platforms Device Tree Bindings
maintainers:
- Jonathan Neuschäfer <j.neuschaefer@gmx.net>
- Tomer Maimon <tmaimon77@gmail.com>
properties:
$nodename:
@ -26,4 +27,10 @@ properties:
- nuvoton,npcm750-evb # NPCM750 evaluation board
- const: nuvoton,npcm750
- description: NPCM845 based boards
items:
- enum:
- nuvoton,npcm845-evb # NPCM845 evaluation board
- const: nuvoton,npcm845
additionalProperties: true

View File

@ -8,6 +8,7 @@ title: Global Control Registers block in Nuvoton SoCs
maintainers:
- Jonathan Neuschäfer <j.neuschaefer@gmx.net>
- Tomer Maimon <tmaimon77@gmail.com>
description:
The Global Control Registers (GCR) are a block of registers in Nuvoton SoCs
@ -20,6 +21,7 @@ properties:
- enum:
- nuvoton,wpcm450-gcr
- nuvoton,npcm750-gcr
- nuvoton,npcm845-gcr
- const: syscon
- const: simple-mfd

View File

@ -7,7 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml#
title: QCOM device tree bindings
maintainers:
- Stephen Boyd <sboyd@codeaurora.org>
- Bjorn Andersson <bjorn.andersson@linaro.org>
description: |
Some qcom based bootloaders identify the dtb blob based on a set of
@ -38,18 +38,24 @@ description: |
msm8992
msm8994
msm8996
msm8998
qcs404
sa8155p
sa8540p
sc7180
sc7280
sc8180x
sc8280xp
sda660
sdm630
sdm632
sdm636
sdm660
sdm845
sdx55
sdx65
sm6125
sm6350
sm7225
sm8150
sm8250
@ -90,6 +96,11 @@ description: |
A dragonboard board v0.1 of subtype 1 with an apq8074 SoC version 2, made in
foundry 2.
There are many devices in the list below that run the standard ChromeOS
bootloader setup and use the open source depthcharge bootloader to boot the
OS. These devices do not use the scheme described above. For details, see:
https://docs.kernel.org/arm/google/chromebook-boot-flow.html
properties:
$nodename:
const: "/"
@ -153,28 +164,50 @@ properties:
- const: qcom,msm8974
- items:
- enum:
- alcatel,idol347
- const: qcom,msm8916-mtp/1
- const: qcom,msm8916-mtp
- const: qcom,msm8916-mtp/1
- const: qcom,msm8916
- items:
- enum:
- longcheer,l8150
- alcatel,idol347
- asus,z00l
- huawei,g7
- longcheer,l8910
- samsung,a3u-eur
- samsung,a5u-eur
- samsung,j5
- samsung,serranove
- wingtech,wt88047
- const: qcom,msm8916
- items:
- const: longcheer,l8150
- const: qcom,msm8916-v1-qrd/9-v1
- const: qcom,msm8916
- items:
- enum:
- lg,bullhead
- microsoft,talkman
- xiaomi,libra
- const: qcom,msm8992
- items:
- enum:
- sony,karin_windy
- const: qcom,apq8094
- items:
- enum:
- huawei,angler
- microsoft,cityman
- sony,ivy-row
- sony,karin-row
- sony,satsuki-row
- sony,sumire-row
- sony,suzuran-row
- qcom,msm8994
- const: qcom,apq8094
- const: qcom,msm8994
- items:
- enum:
@ -190,9 +223,24 @@ properties:
- sony,kagura-row
- sony,keyaki-row
- xiaomi,gemini
- xiaomi,natrium
- xiaomi,scorpio
- const: qcom,msm8996
- items:
- enum:
- asus,novago-tp370ql
- fxtec,pro1
- hp,envy-x2
- lenovo,miix-630
- oneplus,cheeseburger
- oneplus,dumpling
- qcom,msm8998-mtp
- sony,xperia-lilac
- sony,xperia-maple
- sony,xperia-poplar
- const: qcom,msm8998
- items:
- enum:
- qcom,ipq4019-ap-dk01.1-c1
@ -214,19 +262,317 @@ properties:
- qcom,ipq8074-hk10-c2
- const: qcom,ipq8074
- items:
- description: Qualcomm Technologies, Inc. SC7180 IDP
items:
- enum:
- qcom,sc7180-idp
- const: qcom,sc7180
- items:
- enum:
- qcom,sc7280-crd
- qcom,sc7280-idp
- qcom,sc7280-idp2
- google,hoglin
- google,piglin
- google,senor
- description: HP Chromebook x2 11c (rev1 - 2)
items:
- const: google,coachz-rev1
- const: google,coachz-rev2
- const: qcom,sc7180
- description: HP Chromebook x2 11c (newest rev)
items:
- const: google,coachz
- const: qcom,sc7180
- description: HP Chromebook x2 11c with LTE (rev1 - 2)
items:
- const: google,coachz-rev1-sku0
- const: google,coachz-rev2-sku0
- const: qcom,sc7180
- description: HP Chromebook x2 11c with LTE (newest rev)
items:
- const: google,coachz-sku0
- const: qcom,sc7180
- description: Lenovo Chromebook Duet 5 13 (rev2)
items:
- const: google,homestar-rev2
- const: google,homestar-rev23
- const: qcom,sc7180
- description: Lenovo Chromebook Duet 5 13 (rev3)
items:
- const: google,homestar-rev3
- const: qcom,sc7180
- description: Lenovo Chromebook Duet 5 13 (newest rev)
items:
- const: google,homestar
- const: qcom,sc7180
- description: Google Kingoftown (rev0)
items:
- const: google,kingoftown-rev0
- const: qcom,sc7180
- description: Google Kingoftown (newest rev)
items:
- const: google,kingoftown
- const: qcom,sc7180
- description: Acer Chromebook Spin 513 (rev0)
items:
- const: google,lazor-rev0
- const: qcom,sc7180
- description: Acer Chromebook Spin 513 (rev1 - 2)
items:
- const: google,lazor-rev1
- const: google,lazor-rev2
- const: qcom,sc7180
- description: Acer Chromebook Spin 513 (rev3 - 8)
items:
- const: google,lazor-rev3
- const: google,lazor-rev4
- const: google,lazor-rev5
- const: google,lazor-rev6
- const: google,lazor-rev7
- const: google,lazor-rev8
- const: qcom,sc7180
- description: Acer Chromebook Spin 513 (newest rev)
items:
- const: google,lazor
- const: qcom,sc7180
- description: Acer Chromebook Spin 513 with KB Backlight (rev1 - 2)
items:
- const: google,lazor-rev1-sku2
- const: google,lazor-rev2-sku2
- const: qcom,sc7180
- description: Acer Chromebook Spin 513 with KB Backlight (rev3 - 8)
items:
- const: google,lazor-rev3-sku2
- const: google,lazor-rev4-sku2
- const: google,lazor-rev5-sku2
- const: google,lazor-rev6-sku2
- const: google,lazor-rev7-sku2
- const: google,lazor-rev8-sku2
- const: qcom,sc7180
- description: Acer Chromebook Spin 513 with KB Backlight (newest rev)
items:
- const: google,lazor-sku2
- const: qcom,sc7180
- description: Acer Chromebook Spin 513 with LTE (rev1 - 2)
items:
- const: google,lazor-rev1-sku0
- const: google,lazor-rev2-sku0
- const: qcom,sc7180
- description: Acer Chromebook Spin 513 with LTE (rev3 - 8)
items:
- const: google,lazor-rev3-sku0
- const: google,lazor-rev4-sku0
- const: google,lazor-rev5-sku0
- const: google,lazor-rev6-sku0
- const: google,lazor-rev7-sku0
- const: google,lazor-rev8-sku0
- const: qcom,sc7180
- description: Acer Chromebook Spin 513 with LTE (newest rev)
items:
- const: google,lazor-sku0
- const: qcom,sc7180
- description: Acer Chromebook 511 (rev4 - rev8)
items:
- const: google,lazor-rev4-sku4
- const: google,lazor-rev5-sku4
- const: google,lazor-rev6-sku4
- const: google,lazor-rev7-sku4
- const: google,lazor-rev8-sku4
- const: qcom,sc7180
- description: Acer Chromebook 511 (newest rev)
items:
- const: google,lazor-sku4
- const: qcom,sc7180
- description: Acer Chromebook 511 without Touchscreen (rev4)
items:
- const: google,lazor-rev4-sku5
- const: qcom,sc7180
- description: Acer Chromebook 511 without Touchscreen (rev5 - rev8)
items:
- const: google,lazor-rev5-sku5
- const: google,lazor-rev5-sku6
- const: google,lazor-rev6-sku6
- const: google,lazor-rev7-sku6
- const: google,lazor-rev8-sku6
- const: qcom,sc7180
- description: Acer Chromebook 511 without Touchscreen (newest rev)
items:
- const: google,lazor-sku6
- const: qcom,sc7180
- description: Google Mrbland with AUO panel (rev0)
items:
- const: google,mrbland-rev0-sku0
- const: qcom,sc7180
- description: Google Mrbland with AUO panel (newest rev)
items:
- const: google,mrbland-sku1536
- const: qcom,sc7180
- description: Google Mrbland with BOE panel (rev0)
items:
- const: google,mrbland-rev0-sku16
- const: qcom,sc7180
- description: Google Mrbland with BOE panel (newest rev)
items:
- const: google,mrbland-sku1024
- const: google,mrbland-sku768
- const: qcom,sc7180
- description: Google Pazquel with Parade (newest rev)
items:
- const: google,pazquel-sku5
- const: qcom,sc7180
- description: Google Pazquel with TI (newest rev)
items:
- const: google,pazquel-sku1
- const: qcom,sc7180
- description: Google Pazquel with LTE and Parade (newest rev)
items:
- const: google,pazquel-sku4
- const: qcom,sc7180
- description: Google Pazquel with LTE and TI (newest rev)
items:
- const: google,pazquel-sku0
- const: google,pazquel-sku2
- const: qcom,sc7180
- description: Sharp Dynabook Chromebook C1 (rev1)
items:
- const: google,pompom-rev1
- const: qcom,sc7180
- description: Sharp Dynabook Chromebook C1 (rev2)
items:
- const: google,pompom-rev2
- const: qcom,sc7180
- description: Sharp Dynabook Chromebook C1 (newest rev)
items:
- const: google,pompom
- const: qcom,sc7180
- description: Sharp Dynabook Chromebook C1 with LTE (rev1)
items:
- const: google,pompom-rev1-sku0
- const: qcom,sc7180
- description: Sharp Dynabook Chromebook C1 with LTE (rev2)
items:
- const: google,pompom-rev2-sku0
- const: qcom,sc7180
- description: Sharp Dynabook Chromebook C1 with LTE (newest rev)
items:
- const: google,pompom-sku0
- const: qcom,sc7180
- description: Google Quackingstick (newest rev)
items:
- const: google,quackingstick-sku1537
- const: qcom,sc7180
- description: Google Quackingstick with LTE (newest rev)
items:
- const: google,quackingstick-sku1536
- const: qcom,sc7180
- description: Google Trogdor (newest rev)
items:
- const: google,trogdor
- const: qcom,sc7180
- description: Google Trogdor with LTE (newest rev)
items:
- const: google,trogdor-sku0
- const: qcom,sc7180
- description: Lenovo IdeaPad Chromebook Duet 3 with BOE panel (rev0)
items:
- const: google,wormdingler-rev0-sku16
- const: qcom,sc7180
- description: Lenovo IdeaPad Chromebook Duet 3 with BOE panel (newest rev)
items:
- const: google,wormdingler-sku1024
- const: qcom,sc7180
- description: Lenovo IdeaPad Chromebook Duet 3 with BOE panel and rt5682s (newest rev)
items:
- const: google,wormdingler-sku1025
- const: qcom,sc7180
- description: Lenovo IdeaPad Chromebook Duet 3 with INX panel (rev0)
items:
- const: google,wormdingler-rev0-sku0
- const: qcom,sc7180
- description: Lenovo IdeaPad Chromebook Duet 3 with INX panel (newest rev)
items:
- const: google,wormdingler-sku0
- const: qcom,sc7180
- description: Lenovo IdeaPad Chromebook Duet 3 with INX panel and rt5682s (newest rev)
items:
- const: google,wormdingler-sku1
- const: qcom,sc7180
- description: Qualcomm Technologies, Inc. sc7280 CRD platform (rev3 - 4)
items:
- const: qcom,sc7280-crd
- const: google,hoglin-rev3
- const: google,hoglin-rev4
- const: google,piglin-rev3
- const: google,piglin-rev4
- const: qcom,sc7280
- description: Qualcomm Technologies, Inc. sc7280 CRD platform (newest rev)
items:
- const: google,hoglin
- const: qcom,sc7280
- description: Qualcomm Technologies, Inc. sc7280 IDP SKU1 platform
items:
- const: qcom,sc7280-idp
- const: google,senor
- const: qcom,sc7280
- description: Qualcomm Technologies, Inc. sc7280 IDP SKU2 platform
items:
- const: qcom,sc7280-idp2
- const: google,piglin
- const: qcom,sc7280
- description: Google Herobrine (newest rev)
items:
- const: google,herobrine
- const: qcom,sc7280
- description: Google Villager (newest rev)
items:
- const: google,villager
- const: qcom,sc7280
- items:
@ -238,14 +584,34 @@ properties:
- items:
- enum:
- lenovo,thinkpad-x13s
- qcom,sc8280xp-crd
- qcom,sc8280xp-qrd
- const: qcom,sc8280xp
- items:
- enum:
- sony,discovery-row
- sony,kirin-row
- sony,pioneer-row
- sony,voyager-row
- const: qcom,sdm630
- items:
- enum:
- inforce,ifc6560
- const: qcom,sda660
- items:
- enum:
- fairphone,fp3
- const: qcom,sdm632
- items:
- enum:
- sony,mermaid-row
- const: qcom,sdm636
- items:
- enum:
- xiaomi,lavender
@ -269,6 +635,13 @@ properties:
- qcom,ipq6018-cp01-c1
- const: qcom,ipq6018
- items:
- enum:
- qcom,qcs404-evb-1000
- qcom,qcs404-evb-4000
- const: qcom,qcs404-evb
- const: qcom,qcs404
- items:
- enum:
- qcom,sa8155p-adp
@ -279,6 +652,34 @@ properties:
- qcom,sa8295p-adp
- const: qcom,sa8540p
- items:
- enum:
- lenovo,yoga-c630
- lg,judyln
- lg,judyp
- oneplus,enchilada
- oneplus,fajita
- qcom,sdm845-mtp
- shift,axolotl
- samsung,w737
- sony,akari-row
- sony,akatsuki-row
- sony,apollo-row
- thundercomm,db845c
- xiaomi,beryllium
- xiaomi,polaris
- const: qcom,sdm845
- items:
- enum:
- sony,pdx201
- const: qcom,sm6125
- items:
- enum:
- sony,pdx213
- const: qcom,sm6350
- items:
- enum:
- fairphone,fp4
@ -286,19 +687,29 @@ properties:
- items:
- enum:
- microsoft,surface-duo
- qcom,sm8150-hdk
- qcom,sm8150-mtp
- sony,bahamut-generic
- sony,griffin-generic
- const: qcom,sm8150
- items:
- enum:
- qcom,qrb5165-rb5
- qcom,sm8250-hdk
- qcom,sm8250-mtp
- sony,pdx203-generic
- sony,pdx206-generic
- const: qcom,sm8250
- items:
- enum:
- microsoft,surface-duo2
- qcom,sm8350-hdk
- qcom,sm8350-mtp
- sony,pdx214-generic
- sony,pdx215-generic
- const: qcom,sm8350
- items:

View File

@ -554,6 +554,11 @@ properties:
- const: vamrs,rk3399pro-vmarc-som
- const: rockchip,rk3399pro
- description: Radxa ROCK Pi S
items:
- const: radxa,rockpis
- const: rockchip,rk3308
- description: Radxa Rock2 Square
items:
- const: radxa,rock2-square

View File

@ -0,0 +1,40 @@
# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
%YAML 1.2
---
$id: http://devicetree.org/schemas/arm/samsung/samsung-soc.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Samsung S3C, S5P and Exynos SoC compatibles naming convention
maintainers:
- Krzysztof Kozlowski <krzk@kernel.org>
description: |
Guidelines for new compatibles for SoC blocks/components.
When adding new compatibles in new bindings, use the format::
samsung,SoC-IP
For example::
samsung,exynos5433-cmu-isp
select:
properties:
compatible:
pattern: "^samsung,.*(s3c|s5pv|exynos)[0-9a-z]+.*$"
required:
- compatible
properties:
compatible:
oneOf:
- description: Preferred naming style for compatibles of SoC components
pattern: "^samsung,(s3c|s5pv|exynos|exynosautov)[0-9]+-.*$"
# Legacy compatibles with wild-cards - list cannot grow with new bindings:
- enum:
- samsung,exynos4x12-pinctrl
- samsung,exynos4x12-usb2-phy
- samsung,s3c64xx-pinctrl
- samsung,s3c64xx-wakeup-eint
additionalProperties: true

View File

@ -59,12 +59,18 @@ properties:
- prt,prtt1s # Protonic PRTT1S
- const: st,stm32mp151
- description: DH STM32MP153 SoM based Boards
- description: DH STM32MP153 DHCOM SoM based Boards
items:
- const: dh,stm32mp153c-dhcom-drc02
- const: dh,stm32mp153c-dhcom-som
- const: st,stm32mp153
- description: DH STM32MP153 DHCOR SoM based Boards
items:
- const: dh,stm32mp153c-dhcor-drc-compact
- const: dh,stm32mp153c-dhcor-som
- const: st,stm32mp153
- items:
- enum:
- shiratech,stm32mp157a-iot-box # IoT Box

View File

@ -0,0 +1,29 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
# Copyright (C) Sunplus Co., Ltd. 2021
%YAML 1.2
---
$id: http://devicetree.org/schemas/arm/sunplus,sp7021.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Sunplus SP7021 Boards
maintainers:
- qinjian <qinjian@cqplus1.com>
description: |
ARM platforms using Sunplus SP7021, an ARM Cortex A7 (4-cores) based SoC.
Wiki: https://sunplus-tibbo.atlassian.net/wiki/spaces/doc/overview
properties:
$nodename:
const: '/'
compatible:
items:
- enum:
- sunplus,sp7021-achip
- sunplus,sp7021-demo-v3
- const: sunplus,sp7021
additionalProperties: true
...

View File

@ -863,6 +863,11 @@ properties:
- const: yones-toptech,bs1078-v2
- const: allwinner,sun6i-a31s
- description: X96 Mate TV box
items:
- const: hechuang,x96-mate
- const: allwinner,sun50i-h616
- description: Xunlong OrangePi
items:
- const: xunlong,orangepi
@ -963,4 +968,9 @@ properties:
- const: xunlong,orangepi-zero-plus2-h3
- const: allwinner,sun8i-h3
- description: Xunlong OrangePi Zero 2
items:
- const: xunlong,orangepi-zero2
- const: allwinner,sun50i-h616
additionalProperties: true

View File

@ -29,10 +29,20 @@ properties:
compatible:
enum:
- allwinner,sun5i-a13-mbus
- allwinner,sun8i-a33-mbus
- allwinner,sun8i-a50-mbus
- allwinner,sun8i-a83t-mbus
- allwinner,sun8i-h3-mbus
- allwinner,sun8i-r40-mbus
- allwinner,sun8i-v3s-mbus
- allwinner,sun8i-v536-mbus
- allwinner,sun20i-d1-mbus
- allwinner,sun50i-a64-mbus
- allwinner,sun50i-a100-mbus
- allwinner,sun50i-h5-mbus
- allwinner,sun50i-h6-mbus
- allwinner,sun50i-h616-mbus
- allwinner,sun50i-r329-mbus
reg:
minItems: 1
@ -81,13 +91,13 @@ required:
- dma-ranges
if:
properties:
compatible:
contains:
enum:
- allwinner,sun8i-h3-mbus
- allwinner,sun50i-a64-mbus
- allwinner,sun50i-h5-mbus
not:
properties:
compatible:
contains:
enum:
- allwinner,sun5i-a13-mbus
- allwinner,sun8i-r40-mbus
then:
properties:

View File

@ -40,7 +40,6 @@ required:
- compatible
- reg
- nvidia,bpmp
- status
examples:
- |

View File

@ -0,0 +1,40 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: "http://devicetree.org/schemas/arm/tegra/nvidia,tegra194-axi2apb.yaml#"
$schema: "http://devicetree.org/meta-schemas/core.yaml#"
title: NVIDIA Tegra194 AXI2APB bridge
maintainers:
- Sumit Gupta <sumitg@nvidia.com>
properties:
$nodename:
pattern: "^axi2apb@([0-9a-f]+)$"
compatible:
enum:
- nvidia,tegra194-axi2apb
reg:
maxItems: 6
description: Physical base address and length of registers for all bridges
additionalProperties: false
required:
- compatible
- reg
examples:
- |
axi2apb: axi2apb@2390000 {
compatible = "nvidia,tegra194-axi2apb";
reg = <0x02390000 0x1000>,
<0x023a0000 0x1000>,
<0x023b0000 0x1000>,
<0x023c0000 0x1000>,
<0x023d0000 0x1000>,
<0x023e0000 0x1000>;
};

View File

@ -0,0 +1,97 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: "http://devicetree.org/schemas/arm/tegra/nvidia,tegra194-cbb.yaml#"
$schema: "http://devicetree.org/meta-schemas/core.yaml#"
title: NVIDIA Tegra194 CBB 1.0 bindings
maintainers:
- Sumit Gupta <sumitg@nvidia.com>
description: |+
The Control Backbone (CBB) is comprised of the physical path from an
initiator to a target's register configuration space. CBB 1.0 has
multiple hierarchical sub-NOCs (Network-on-Chip) and connects various
initiators and targets using different bridges like AXIP2P, AXI2APB.
This driver handles errors due to illegal register accesses reported
by the NOCs inside the CBB. NOCs reporting errors are cluster NOCs
"AON-NOC, SCE-NOC, RCE-NOC, BPMP-NOC, CV-NOC" and "CBB Central NOC"
which is the main NOC.
By default, the access issuing initiator is informed about the error
using SError or Data Abort exception unless the ERD (Error Response
Disable) is enabled/set for that initiator. If the ERD is enabled, then
SError or Data Abort is masked and the error is reported with interrupt.
- For CCPLEX (CPU Complex) initiator, the driver sets ERD bit. So, the
errors due to illegal accesses from CCPLEX are reported by interrupts.
If ERD is not set, then error is reported by SError.
- For other initiators, the ERD is disabled. So, the access issuing
initiator is informed about the illegal access by Data Abort exception.
In addition, an interrupt is also generated to CCPLEX. These initiators
include all engines using Cortex-R5 (which is ARMv7 CPU cluster) and
engines like TSEC (Security co-processor), NVDEC (NVIDIA Video Decoder
engine) etc which can initiate transactions.
The driver prints relevant debug information like Error Code, Error
Description, Master, Address, AXI ID, Cache, Protection, Security Group
etc on receiving error notification.
properties:
$nodename:
pattern: "^[a-z]+-noc@[0-9a-f]+$"
compatible:
enum:
- nvidia,tegra194-cbb-noc
- nvidia,tegra194-aon-noc
- nvidia,tegra194-bpmp-noc
- nvidia,tegra194-rce-noc
- nvidia,tegra194-sce-noc
reg:
maxItems: 1
interrupts:
description:
CCPLEX receives secure or nonsecure interrupt depending on error type.
A secure interrupt is received for SEC(firewall) & SLV errors and a
non-secure interrupt is received for TMO & DEC errors.
items:
- description: non-secure interrupt
- description: secure interrupt
nvidia,axi2apb:
$ref: '/schemas/types.yaml#/definitions/phandle'
description:
Specifies the node having all axi2apb bridges which need to be checked
for any error logged in their status register.
nvidia,apbmisc:
$ref: '/schemas/types.yaml#/definitions/phandle'
description:
Specifies the apbmisc node which need to be used for reading the ERD
register.
additionalProperties: false
required:
- compatible
- reg
- interrupts
- nvidia,apbmisc
examples:
- |
#include <dt-bindings/interrupt-controller/arm-gic.h>
cbb-noc@2300000 {
compatible = "nvidia,tegra194-cbb-noc";
reg = <0x02300000 0x1000>;
interrupts = <GIC_SPI 230 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 231 IRQ_TYPE_LEVEL_HIGH>;
nvidia,axi2apb = <&axi2apb>;
nvidia,apbmisc = <&apbmisc>;
};

View File

@ -0,0 +1,74 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: "http://devicetree.org/schemas/arm/tegra/nvidia,tegra234-cbb.yaml#"
$schema: "http://devicetree.org/meta-schemas/core.yaml#"
title: NVIDIA Tegra CBB 2.0 bindings
maintainers:
- Sumit Gupta <sumitg@nvidia.com>
description: |+
The Control Backbone (CBB) is comprised of the physical path from an
initiator to a target's register configuration space. CBB 2.0 consists
of multiple sub-blocks connected to each other to create a topology.
The Tegra234 SoC has different fabrics based on CBB 2.0 architecture
which include cluster fabrics BPMP, AON, PSC, SCE, RCE, DCE, FSI and
"CBB central fabric".
In CBB 2.0, each initiator which can issue transactions connects to a
Root Master Node (MN) before it connects to any other element of the
fabric. Each Root MN contains a Error Monitor (EM) which detects and
logs error. Interrupts from various EM blocks are collated by Error
Notifier (EN) which is per fabric and presents a single interrupt from
fabric to the SoC interrupt controller.
The driver handles errors from CBB due to illegal register accesses
and prints debug information about failed transaction on receiving
the interrupt from EN. Debug information includes Error Code, Error
Description, MasterID, Fabric, SlaveID, Address, Cache, Protection,
Security Group etc on receiving error notification.
If the Error Response Disable (ERD) is set/enabled for an initiator,
then SError or Data abort exception error response is masked and an
interrupt is used for reporting errors due to illegal accesses from
that initiator. The value returned on read failures is '0xFFFFFFFF'
for compatibility with PCIE.
properties:
$nodename:
pattern: "^[a-z]+-fabric@[0-9a-f]+$"
compatible:
enum:
- nvidia,tegra234-aon-fabric
- nvidia,tegra234-bpmp-fabric
- nvidia,tegra234-cbb-fabric
- nvidia,tegra234-dce-fabric
- nvidia,tegra234-rce-fabric
- nvidia,tegra234-sce-fabric
reg:
maxItems: 1
interrupts:
items:
- description: secure interrupt from error notifier
additionalProperties: false
required:
- compatible
- reg
- interrupts
examples:
- |
#include <dt-bindings/interrupt-controller/arm-gic.h>
cbb-fabric@1300000 {
compatible = "nvidia,tegra234-cbb-fabric";
reg = <0x13a00000 0x400000>;
interrupts = <GIC_SPI 231 IRQ_TYPE_LEVEL_HIGH>;
};

View File

@ -28,6 +28,9 @@ properties:
- items:
- const: allwinner,sun8i-r40-de2-clk
- const: allwinner,sun8i-h3-de2-clk
- items:
- const: allwinner,sun20i-d1-de2-clk
- const: allwinner,sun50i-h5-de2-clk
reg:
maxItems: 1

View File

@ -0,0 +1,43 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/clock/fsl,scu-clk.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: i.MX SCU Client Device Node - Clock bindings based on SCU Message Protocol
maintainers:
- Abel Vesa <abel.vesa@nxp.com>
description: i.MX SCU Client Device Node
Client nodes are maintained as children of the relevant IMX-SCU device node.
This binding uses the common clock binding.
(Documentation/devicetree/bindings/clock/clock-bindings.txt)
The clock consumer should specify the desired clock by having the clock
ID in its "clocks" phandle cell. See the full list of clock IDs from
include/dt-bindings/clock/imx8qxp-clock.h
properties:
compatible:
items:
- enum:
- fsl,imx8dxl-clk
- fsl,imx8qm-clk
- fsl,imx8qxp-clk
- const: fsl,scu-clk
'#clock-cells':
const: 2
required:
- compatible
- '#clock-cells'
additionalProperties: false
examples:
- |
clock-controller {
compatible = "fsl,imx8qxp-clk", "fsl,scu-clk";
#clock-cells = <2>;
};

View File

@ -0,0 +1,49 @@
# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
%YAML 1.2
---
$id: http://devicetree.org/schemas/clock/nuvoton,npcm845-clk.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Nuvoton NPCM8XX Clock Controller Binding
maintainers:
- Tomer Maimon <tmaimon77@gmail.com>
description: |
Nuvoton Arbel BMC NPCM8XX contains an integrated clock controller, which
generates and supplies clocks to all modules within the BMC.
properties:
compatible:
enum:
- nuvoton,npcm845-clk
reg:
maxItems: 1
'#clock-cells':
const: 1
description:
See include/dt-bindings/clock/nuvoton,npcm8xx-clock.h for the full
list of NPCM8XX clock IDs.
required:
- compatible
- reg
- '#clock-cells'
additionalProperties: false
examples:
- |
ahb {
#address-cells = <2>;
#size-cells = <2>;
clock-controller@f0801000 {
compatible = "nuvoton,npcm845-clk";
reg = <0x0 0xf0801000 0x0 0x1000>;
#clock-cells = <1>;
};
};
...

View File

@ -4,18 +4,19 @@
$id: http://devicetree.org/schemas/clock/qcom,dispcc-sm8x50.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Qualcomm Display Clock & Reset Controller Binding for SM8150/SM8250
title: Qualcomm Display Clock & Reset Controller Binding for SM8150/SM8250/SM8350
maintainers:
- Jonathan Marek <jonathan@marek.ca>
description: |
Qualcomm display clock control module which supports the clocks, resets and
power domains on SM8150 and SM8250.
power domains on SM8150/SM8250/SM8350.
See also:
dt-bindings/clock/qcom,dispcc-sm8150.h
dt-bindings/clock/qcom,dispcc-sm8250.h
dt-bindings/clock/qcom,dispcc-sm8350.h
properties:
compatible:
@ -23,6 +24,7 @@ properties:
- qcom,sc8180x-dispcc
- qcom,sm8150-dispcc
- qcom,sm8250-dispcc
- qcom,sm8350-dispcc
clocks:
items:

View File

@ -0,0 +1,72 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/clock/qcom,gpucc-sm8350.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Qualcomm Graphics Clock & Reset Controller Binding
maintainers:
- Robert Foss <robert.foss@linaro.org>
description: |
Qualcomm graphics clock control module which supports the clocks, resets and
power domains on Qualcomm SoCs.
See also:
dt-bindings/clock/qcom,gpucc-sm8350.h
properties:
compatible:
enum:
- qcom,sm8350-gpucc
clocks:
items:
- description: Board XO source
- description: GPLL0 main branch source
- description: GPLL0 div branch source
'#clock-cells':
const: 1
'#reset-cells':
const: 1
'#power-domain-cells':
const: 1
reg:
maxItems: 1
required:
- compatible
- reg
- clocks
- '#clock-cells'
- '#reset-cells'
- '#power-domain-cells'
additionalProperties: false
examples:
- |
#include <dt-bindings/clock/qcom,gcc-sm8350.h>
#include <dt-bindings/clock/qcom,rpmh.h>
soc {
#address-cells = <2>;
#size-cells = <2>;
clock-controller@3d90000 {
compatible = "qcom,sm8350-gpucc";
reg = <0 0x03d90000 0 0x9000>;
clocks = <&rpmhcc RPMH_CXO_CLK>,
<&gcc GCC_GPU_GPLL0_CLK_SRC>,
<&gcc GCC_GPU_GPLL0_DIV_CLK_SRC>;
#clock-cells = <1>;
#reset-cells = <1>;
#power-domain-cells = <1>;
};
};
...

View File

@ -0,0 +1,80 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/clock/qcom,sm8450-camcc.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Qualcomm Camera Clock & Reset Controller Binding for SM8450
maintainers:
- Vladimir Zapolskiy <vladimir.zapolskiy@linaro.org>
description: |
Qualcomm camera clock control module which supports the clocks, resets and
power domains on SM8450.
See also include/dt-bindings/clock/qcom,sm8450-camcc.h
properties:
compatible:
const: qcom,sm8450-camcc
clocks:
items:
- description: Camera AHB clock from GCC
- description: Board XO source
- description: Board active XO source
- description: Sleep clock source
power-domains:
maxItems: 1
description:
A phandle and PM domain specifier for the MMCX power domain.
required-opps:
description:
A phandle to an OPP node describing required MMCX performance point.
'#clock-cells':
const: 1
'#reset-cells':
const: 1
'#power-domain-cells':
const: 1
reg:
maxItems: 1
required:
- compatible
- reg
- clocks
- power-domains
- required-opps
- '#clock-cells'
- '#reset-cells'
- '#power-domain-cells'
additionalProperties: false
examples:
- |
#include <dt-bindings/clock/qcom,gcc-sm8450.h>
#include <dt-bindings/clock/qcom,rpmh.h>
#include <dt-bindings/power/qcom-rpmpd.h>
clock-controller@ade0000 {
compatible = "qcom,sm8450-camcc";
reg = <0xade0000 0x20000>;
clocks = <&gcc GCC_CAMERA_AHB_CLK>,
<&rpmhcc RPMH_CXO_CLK>,
<&rpmhcc RPMH_CXO_CLK_A>,
<&sleep_clk>;
power-domains = <&rpmhpd SM8450_MMCX>;
required-opps = <&rpmhpd_opp_low_svs>;
#clock-cells = <1>;
#reset-cells = <1>;
#power-domain-cells = <1>;
};
...

View File

@ -33,6 +33,7 @@ properties:
enum:
- samsung,exynos7885-cmu-top
- samsung,exynos7885-cmu-core
- samsung,exynos7885-cmu-fsys
- samsung,exynos7885-cmu-peri
clocks:
@ -88,6 +89,32 @@ allOf:
- const: dout_core_cci
- const: dout_core_g3d
- if:
properties:
compatible:
contains:
const: samsung,exynos7885-cmu-fsys
then:
properties:
clocks:
items:
- description: External reference clock (26 MHz)
- description: CMU_FSYS bus clock (from CMU_TOP)
- description: MMC_CARD clock (from CMU_TOP)
- description: MMC_EMBD clock (from CMU_TOP)
- description: MMC_SDIO clock (from CMU_TOP)
- description: USB30DRD clock (from CMU_TOP)
clock-names:
items:
- const: oscclk
- const: dout_fsys_bus
- const: dout_fsys_mmc_card
- const: dout_fsys_mmc_embd
- const: dout_fsys_mmc_sdio
- const: dout_fsys_usb30drd
- if:
properties:
compatible:

View File

@ -78,6 +78,7 @@ if:
contains:
enum:
- st,stm32mp1-rcc-secure
- st,stm32mp13-rcc
then:
properties:
clocks:

View File

@ -0,0 +1,52 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
# Copyright (C) Sunplus Co., Ltd. 2021
%YAML 1.2
---
$id: http://devicetree.org/schemas/clock/sunplus,sp7021-clkc.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Sunplus SP7021 SoC Clock Controller
maintainers:
- Qin Jian <qinjian@cqplus1.com>
properties:
compatible:
const: sunplus,sp7021-clkc
reg:
maxItems: 3
clocks:
maxItems: 1
"#clock-cells":
const: 1
required:
- compatible
- reg
- clocks
- "#clock-cells"
additionalProperties: false
examples:
- |
extclk: osc0 {
compatible = "fixed-clock";
#clock-cells = <0>;
clock-frequency = <27000000>;
clock-output-names = "extclk";
};
clkc: clock-controller@9c000004 {
compatible = "sunplus,sp7021-clkc";
reg = <0x9c000004 0x28>,
<0x9c000200 0x44>,
<0x9c000268 0x08>;
clocks = <&extclk>;
#clock-cells = <1>;
};
...

View File

@ -63,8 +63,8 @@ additionalProperties: true
examples:
- |
/ {
model = "Qualcomm Technologies, Inc. QCS404";
compatible = "qcom,qcs404";
model = "Qualcomm Technologies, Inc. QCS404 EVB 1000";
compatible = "qcom,qcs404-evb-1000", "qcom,qcs404-evb", "qcom,qcs404";
#address-cells = <2>;
#size-cells = <2>;

View File

@ -1,488 +0,0 @@
* Generic Exynos Bus frequency device
The Samsung Exynos SoC has many buses for data transfer between DRAM
and sub-blocks in SoC. Most Exynos SoCs share the common architecture
for buses. Generally, each bus of Exynos SoC includes a source clock
and a power line, which are able to change the clock frequency
of the bus in runtime. To monitor the usage of each bus in runtime,
the driver uses the PPMU (Platform Performance Monitoring Unit), which
is able to measure the current load of sub-blocks.
The Exynos SoC includes the various sub-blocks which have the each AXI bus.
The each AXI bus has the owned source clock but, has not the only owned
power line. The power line might be shared among one more sub-blocks.
So, we can divide into two type of device as the role of each sub-block.
There are two type of bus devices as following:
- parent bus device
- passive bus device
Basically, parent and passive bus device share the same power line.
The parent bus device can only change the voltage of shared power line
and the rest bus devices (passive bus device) depend on the decision of
the parent bus device. If there are three blocks which share the VDD_xxx
power line, Only one block should be parent device and then the rest blocks
should depend on the parent device as passive device.
VDD_xxx |--- A block (parent)
|--- B block (passive)
|--- C block (passive)
There are a little different composition among Exynos SoC because each Exynos
SoC has different sub-blocks. Therefore, such difference should be specified
in devicetree file instead of each device driver. In result, this driver
is able to support the bus frequency for all Exynos SoCs.
Required properties for all bus devices:
- compatible: Should be "samsung,exynos-bus".
- clock-names : the name of clock used by the bus, "bus".
- clocks : phandles for clock specified in "clock-names" property.
- operating-points-v2: the OPP table including frequency/voltage information
to support DVFS (Dynamic Voltage/Frequency Scaling) feature.
Required properties only for parent bus device:
- vdd-supply: the regulator to provide the buses with the voltage.
- devfreq-events: the devfreq-event device to monitor the current utilization
of buses.
Required properties only for passive bus device:
- devfreq: the parent bus device.
Optional properties only for parent bus device:
- exynos,saturation-ratio: the percentage value which is used to calibrate
the performance count against total cycle count.
Optional properties for the interconnect functionality (QoS frequency
constraints):
- #interconnect-cells: should be 0.
- interconnects: as documented in ../interconnect.txt, describes a path at the
higher level interconnects used by this interconnect provider.
If this interconnect provider is directly linked to a top level interconnect
provider the property contains only one phandle. The provider extends
the interconnect graph by linking its node to a node registered by provider
pointed to by first phandle in the 'interconnects' property.
- samsung,data-clock-ratio: ratio of the data throughput in B/s to minimum data
clock frequency in Hz, default value is 8 when this property is missing.
Detailed correlation between sub-blocks and power line according to Exynos SoC:
- In case of Exynos3250, there are two power line as following:
VDD_MIF |--- DMC
VDD_INT |--- LEFTBUS (parent device)
|--- PERIL
|--- MFC
|--- G3D
|--- RIGHTBUS
|--- PERIR
|--- FSYS
|--- LCD0
|--- PERIR
|--- ISP
|--- CAM
- In case of Exynos4210, there is one power line as following:
VDD_INT |--- DMC (parent device)
|--- LEFTBUS
|--- PERIL
|--- MFC(L)
|--- G3D
|--- TV
|--- LCD0
|--- RIGHTBUS
|--- PERIR
|--- MFC(R)
|--- CAM
|--- FSYS
|--- GPS
|--- LCD0
|--- LCD1
- In case of Exynos4x12, there are two power line as following:
VDD_MIF |--- DMC
VDD_INT |--- LEFTBUS (parent device)
|--- PERIL
|--- MFC(L)
|--- G3D
|--- TV
|--- IMAGE
|--- RIGHTBUS
|--- PERIR
|--- MFC(R)
|--- CAM
|--- FSYS
|--- GPS
|--- LCD0
|--- ISP
- In case of Exynos5422, there are two power line as following:
VDD_MIF |--- DREX 0 (parent device, DRAM EXpress controller)
|--- DREX 1
VDD_INT |--- NoC_Core (parent device)
|--- G2D
|--- G3D
|--- DISP1
|--- NoC_WCORE
|--- GSCL
|--- MSCL
|--- ISP
|--- MFC
|--- GEN
|--- PERIS
|--- PERIC
|--- FSYS
|--- FSYS2
- In case of Exynos5433, there is VDD_INT power line as following:
VDD_INT |--- G2D (parent device)
|--- MSCL
|--- GSCL
|--- JPEG
|--- MFC
|--- HEVC
|--- BUS0
|--- BUS1
|--- BUS2
|--- PERIS (Fixed clock rate)
|--- PERIC (Fixed clock rate)
|--- FSYS (Fixed clock rate)
Example 1:
Show the AXI buses of Exynos3250 SoC. Exynos3250 divides the buses to
power line (regulator). The MIF (Memory Interface) AXI bus is used to
transfer data between DRAM and CPU and uses the VDD_MIF regulator.
- MIF (Memory Interface) block
: VDD_MIF |--- DMC (Dynamic Memory Controller)
- INT (Internal) block
: VDD_INT |--- LEFTBUS (parent device)
|--- PERIL
|--- MFC
|--- G3D
|--- RIGHTBUS
|--- FSYS
|--- LCD0
|--- PERIR
|--- ISP
|--- CAM
- MIF bus's frequency/voltage table
-----------------------
|Lv| Freq | Voltage |
-----------------------
|L1| 50000 |800000 |
|L2| 100000 |800000 |
|L3| 134000 |800000 |
|L4| 200000 |825000 |
|L5| 400000 |875000 |
-----------------------
- INT bus's frequency/voltage table
----------------------------------------------------------
|Block|LEFTBUS|RIGHTBUS|MCUISP |ISP |PERIL ||VDD_INT |
| name| |LCD0 | | | || |
| | |FSYS | | | || |
| | |MFC | | | || |
----------------------------------------------------------
|Mode |*parent|passive |passive|passive|passive|| |
----------------------------------------------------------
|Lv |Frequency ||Voltage |
----------------------------------------------------------
|L1 |50000 |50000 |50000 |50000 |50000 ||900000 |
|L2 |80000 |80000 |80000 |80000 |80000 ||900000 |
|L3 |100000 |100000 |100000 |100000 |100000 ||1000000 |
|L4 |134000 |134000 |200000 |200000 | ||1000000 |
|L5 |200000 |200000 |400000 |300000 | ||1000000 |
----------------------------------------------------------
Example 2:
The bus of DMC (Dynamic Memory Controller) block in exynos3250.dtsi
is listed below:
bus_dmc: bus_dmc {
compatible = "samsung,exynos-bus";
clocks = <&cmu_dmc CLK_DIV_DMC>;
clock-names = "bus";
operating-points-v2 = <&bus_dmc_opp_table>;
status = "disabled";
};
bus_dmc_opp_table: opp_table1 {
compatible = "operating-points-v2";
opp-shared;
opp-50000000 {
opp-hz = /bits/ 64 <50000000>;
opp-microvolt = <800000>;
};
opp-100000000 {
opp-hz = /bits/ 64 <100000000>;
opp-microvolt = <800000>;
};
opp-134000000 {
opp-hz = /bits/ 64 <134000000>;
opp-microvolt = <800000>;
};
opp-200000000 {
opp-hz = /bits/ 64 <200000000>;
opp-microvolt = <825000>;
};
opp-400000000 {
opp-hz = /bits/ 64 <400000000>;
opp-microvolt = <875000>;
};
};
bus_leftbus: bus_leftbus {
compatible = "samsung,exynos-bus";
clocks = <&cmu CLK_DIV_GDL>;
clock-names = "bus";
operating-points-v2 = <&bus_leftbus_opp_table>;
status = "disabled";
};
bus_rightbus: bus_rightbus {
compatible = "samsung,exynos-bus";
clocks = <&cmu CLK_DIV_GDR>;
clock-names = "bus";
operating-points-v2 = <&bus_leftbus_opp_table>;
status = "disabled";
};
bus_lcd0: bus_lcd0 {
compatible = "samsung,exynos-bus";
clocks = <&cmu CLK_DIV_ACLK_160>;
clock-names = "bus";
operating-points-v2 = <&bus_leftbus_opp_table>;
status = "disabled";
};
bus_fsys: bus_fsys {
compatible = "samsung,exynos-bus";
clocks = <&cmu CLK_DIV_ACLK_200>;
clock-names = "bus";
operating-points-v2 = <&bus_leftbus_opp_table>;
status = "disabled";
};
bus_mcuisp: bus_mcuisp {
compatible = "samsung,exynos-bus";
clocks = <&cmu CLK_DIV_ACLK_400_MCUISP>;
clock-names = "bus";
operating-points-v2 = <&bus_mcuisp_opp_table>;
status = "disabled";
};
bus_isp: bus_isp {
compatible = "samsung,exynos-bus";
clocks = <&cmu CLK_DIV_ACLK_266>;
clock-names = "bus";
operating-points-v2 = <&bus_isp_opp_table>;
status = "disabled";
};
bus_peril: bus_peril {
compatible = "samsung,exynos-bus";
clocks = <&cmu CLK_DIV_ACLK_100>;
clock-names = "bus";
operating-points-v2 = <&bus_peril_opp_table>;
status = "disabled";
};
bus_mfc: bus_mfc {
compatible = "samsung,exynos-bus";
clocks = <&cmu CLK_SCLK_MFC>;
clock-names = "bus";
operating-points-v2 = <&bus_leftbus_opp_table>;
status = "disabled";
};
bus_leftbus_opp_table: opp_table1 {
compatible = "operating-points-v2";
opp-shared;
opp-50000000 {
opp-hz = /bits/ 64 <50000000>;
opp-microvolt = <900000>;
};
opp-80000000 {
opp-hz = /bits/ 64 <80000000>;
opp-microvolt = <900000>;
};
opp-100000000 {
opp-hz = /bits/ 64 <100000000>;
opp-microvolt = <1000000>;
};
opp-134000000 {
opp-hz = /bits/ 64 <134000000>;
opp-microvolt = <1000000>;
};
opp-200000000 {
opp-hz = /bits/ 64 <200000000>;
opp-microvolt = <1000000>;
};
};
bus_mcuisp_opp_table: opp_table2 {
compatible = "operating-points-v2";
opp-shared;
opp-50000000 {
opp-hz = /bits/ 64 <50000000>;
};
opp-80000000 {
opp-hz = /bits/ 64 <80000000>;
};
opp-100000000 {
opp-hz = /bits/ 64 <100000000>;
};
opp-200000000 {
opp-hz = /bits/ 64 <200000000>;
};
opp-400000000 {
opp-hz = /bits/ 64 <400000000>;
};
};
bus_isp_opp_table: opp_table3 {
compatible = "operating-points-v2";
opp-shared;
opp-50000000 {
opp-hz = /bits/ 64 <50000000>;
};
opp-80000000 {
opp-hz = /bits/ 64 <80000000>;
};
opp-100000000 {
opp-hz = /bits/ 64 <100000000>;
};
opp-200000000 {
opp-hz = /bits/ 64 <200000000>;
};
opp-300000000 {
opp-hz = /bits/ 64 <300000000>;
};
};
bus_peril_opp_table: opp_table4 {
compatible = "operating-points-v2";
opp-shared;
opp-50000000 {
opp-hz = /bits/ 64 <50000000>;
};
opp-80000000 {
opp-hz = /bits/ 64 <80000000>;
};
opp-100000000 {
opp-hz = /bits/ 64 <100000000>;
};
};
Usage case to handle the frequency and voltage of bus on runtime
in exynos3250-rinato.dts is listed below:
&bus_dmc {
devfreq-events = <&ppmu_dmc0_3>, <&ppmu_dmc1_3>;
vdd-supply = <&buck1_reg>; /* VDD_MIF */
status = "okay";
};
&bus_leftbus {
devfreq-events = <&ppmu_leftbus_3>, <&ppmu_rightbus_3>;
vdd-supply = <&buck3_reg>;
status = "okay";
};
&bus_rightbus {
devfreq = <&bus_leftbus>;
status = "okay";
};
&bus_lcd0 {
devfreq = <&bus_leftbus>;
status = "okay";
};
&bus_fsys {
devfreq = <&bus_leftbus>;
status = "okay";
};
&bus_mcuisp {
devfreq = <&bus_leftbus>;
status = "okay";
};
&bus_isp {
devfreq = <&bus_leftbus>;
status = "okay";
};
&bus_peril {
devfreq = <&bus_leftbus>;
status = "okay";
};
&bus_mfc {
devfreq = <&bus_leftbus>;
status = "okay";
};
Example 3:
An interconnect path "bus_display -- bus_leftbus -- bus_dmc" on
Exynos4412 SoC with video mixer as an interconnect consumer device.
soc {
bus_dmc: bus_dmc {
compatible = "samsung,exynos-bus";
clocks = <&clock CLK_DIV_DMC>;
clock-names = "bus";
operating-points-v2 = <&bus_dmc_opp_table>;
samsung,data-clock-ratio = <4>;
#interconnect-cells = <0>;
};
bus_leftbus: bus_leftbus {
compatible = "samsung,exynos-bus";
clocks = <&clock CLK_DIV_GDL>;
clock-names = "bus";
operating-points-v2 = <&bus_leftbus_opp_table>;
#interconnect-cells = <0>;
interconnects = <&bus_dmc>;
};
bus_display: bus_display {
compatible = "samsung,exynos-bus";
clocks = <&clock CLK_ACLK160>;
clock-names = "bus";
operating-points-v2 = <&bus_display_opp_table>;
#interconnect-cells = <0>;
interconnects = <&bus_leftbus &bus_dmc>;
};
bus_dmc_opp_table: opp_table1 {
compatible = "operating-points-v2";
/* ... */
}
bus_leftbus_opp_table: opp_table3 {
compatible = "operating-points-v2";
/* ... */
};
bus_display_opp_table: opp_table4 {
compatible = "operating-points-v2";
/* .. */
};
&mixer {
compatible = "samsung,exynos4212-mixer";
interconnects = <&bus_display &bus_dmc>;
/* ... */
};
};

View File

@ -21,6 +21,9 @@ properties:
enable-gpios: true
port: true
spi-cpha: true
spi-cpol: true
required:
- compatible
- enable-gpios

View File

@ -42,6 +42,9 @@ properties:
panel-height-mm:
description: physical panel height [mm]
spi-cpha: true
spi-cpol: true
required:
- compatible
- reg

View File

@ -23,6 +23,9 @@ properties:
backlight: true
port: true
spi-cpha: true
spi-cpol: true
required:
- compatible
- reg

View File

@ -28,6 +28,9 @@ properties:
backlight: true
port: true
spi-cpha: true
spi-cpol: true
required:
- compatible
- port

View File

@ -183,6 +183,12 @@ properties:
required:
- reg
protocol@18:
type: object
properties:
reg:
const: 0x18
additionalProperties: false
patternProperties:
@ -323,6 +329,10 @@ examples:
};
};
};
scmi_powercap: protocol@18 {
reg = <0x18>;
};
};
};

View File

@ -0,0 +1,210 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/firmware/fsl,scu.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: NXP i.MX System Controller Firmware (SCFW)
maintainers:
- Dong Aisheng <aisheng.dong@nxp.com>
description:
The System Controller Firmware (SCFW) is a low-level system function
which runs on a dedicated Cortex-M core to provide power, clock, and
resource management. It exists on some i.MX8 processors. e.g. i.MX8QM
(QM, QP), and i.MX8QX (QXP, DX).
The AP communicates with the SC using a multi-ported MU module found
in the LSIO subsystem. The current definition of this MU module provides
5 remote AP connections to the SC to support up to 5 execution environments
(TZ, HV, standard Linux, etc.). The SC side of this MU module interfaces
with the LSIO DSC IP bus. The SC firmware will communicate with this MU
using the MSI bus.
properties:
compatible:
const: fsl,imx-scu
clock-controller:
description:
Clock controller node that provides the clocks controlled by the SCU
$ref: /schemas/clock/fsl,scu-clk.yaml
ocotp:
description:
OCOTP controller node provided by the SCU
$ref: /schemas/nvmem/fsl,scu-ocotp.yaml
keys:
description:
Keys provided by the SCU
$ref: /schemas/input/fsl,scu-key.yaml
mboxes:
description:
A list of phandles of TX MU channels followed by a list of phandles of
RX MU channels. The list may include at the end one more optional MU
channel for general interrupt. The number of expected tx and rx
channels is 1 TX and 1 RX channels if MU instance is "fsl,imx8-mu-scu"
compatible, 4 TX and 4 RX channels otherwise. All MU channels must be
within the same MU instance. Cross instances are not allowed. The MU
instance can only be one of LSIO MU0~M4 for imx8qxp and imx8qm. Users
need to ensure that one is used that does not conflict with other
execution environments such as ATF.
oneOf:
- items:
- description: TX0 MU channel
- description: RX0 MU channel
- items:
- description: TX0 MU channel
- description: RX0 MU channel
- description: optional MU channel for general interrupt
- items:
- description: TX0 MU channel
- description: TX1 MU channel
- description: TX2 MU channel
- description: TX3 MU channel
- description: RX0 MU channel
- description: RX1 MU channel
- description: RX2 MU channel
- description: RX3 MU channel
- items:
- description: TX0 MU channel
- description: TX1 MU channel
- description: TX2 MU channel
- description: TX3 MU channel
- description: RX0 MU channel
- description: RX1 MU channel
- description: RX2 MU channel
- description: RX3 MU channel
- description: optional MU channel for general interrupt
mbox-names:
oneOf:
- items:
- const: tx0
- const: rx0
- items:
- const: tx0
- const: rx0
- const: gip3
- items:
- const: tx0
- const: tx1
- const: tx2
- const: tx3
- const: rx0
- const: rx1
- const: rx2
- const: rx3
- items:
- const: tx0
- const: tx1
- const: tx2
- const: tx3
- const: rx0
- const: rx1
- const: rx2
- const: rx3
- const: gip3
pinctrl:
description:
Pin controller provided by the SCU
$ref: /schemas/pinctrl/fsl,scu-pinctrl.yaml
power-controller:
description:
Power domains controller node that provides the power domains
controlled by the SCU
$ref: /schemas/power/fsl,scu-pd.yaml
rtc:
description:
RTC controller provided by the SCU
$ref: /schemas/rtc/fsl,scu-rtc.yaml
thermal-sensor:
description:
Thermal sensor provided by the SCU
$ref: /schemas/thermal/fsl,scu-thermal.yaml
watchdog:
description:
Watchdog controller provided by the SCU
$ref: /schemas/watchdog/fsl,scu-wdt.yaml
required:
- compatible
- mbox-names
- mboxes
additionalProperties: false
examples:
- |
#include <dt-bindings/firmware/imx/rsrc.h>
#include <dt-bindings/input/input.h>
#include <dt-bindings/pinctrl/pads-imx8qxp.h>
firmware {
system-controller {
compatible = "fsl,imx-scu";
mbox-names = "tx0", "tx1", "tx2", "tx3",
"rx0", "rx1", "rx2", "rx3",
"gip3";
mboxes = <&lsio_mu1 0 0 &lsio_mu1 0 1 &lsio_mu1 0 2 &lsio_mu1 0 3
&lsio_mu1 1 0 &lsio_mu1 1 1 &lsio_mu1 1 2 &lsio_mu1 1 3
&lsio_mu1 3 3>;
clock-controller {
compatible = "fsl,imx8qxp-clk", "fsl,scu-clk";
#clock-cells = <2>;
};
pinctrl {
compatible = "fsl,imx8qxp-iomuxc";
pinctrl_lpuart0: lpuart0grp {
fsl,pins = <
IMX8QXP_UART0_RX_ADMA_UART0_RX 0x06000020
IMX8QXP_UART0_TX_ADMA_UART0_TX 0x06000020
>;
};
};
ocotp {
compatible = "fsl,imx8qxp-scu-ocotp";
#address-cells = <1>;
#size-cells = <1>;
fec_mac0: mac@2c4 {
reg = <0x2c4 6>;
};
};
power-controller {
compatible = "fsl,imx8qxp-scu-pd", "fsl,scu-pd";
#power-domain-cells = <1>;
};
rtc {
compatible = "fsl,imx8qxp-sc-rtc";
};
keys {
compatible = "fsl,imx8qxp-sc-key", "fsl,imx-sc-key";
linux,keycodes = <KEY_POWER>;
};
watchdog {
compatible = "fsl,imx8qxp-sc-wdt", "fsl,imx-sc-wdt";
timeout-sec = <60>;
};
thermal-sensor {
compatible = "fsl,imx8qxp-sc-thermal", "fsl,imx-sc-thermal";
#thermal-sensor-cells = <1>;
};
};
};

View File

@ -23,10 +23,13 @@ Required properties:
* "qcom,scm-msm8994"
* "qcom,scm-msm8996"
* "qcom,scm-msm8998"
* "qcom,scm-qcs404"
* "qcom,scm-sc7180"
* "qcom,scm-sc7280"
* "qcom,scm-sm6125"
* "qcom,scm-sdm845"
* "qcom,scm-sdx55"
* "qcom,scm-sdx65"
* "qcom,scm-sm6350"
* "qcom,scm-sm8150"
* "qcom,scm-sm8250"
@ -43,6 +46,7 @@ Required properties:
clock and "bus" for the bus clock per the requirements of the compatible.
- qcom,dload-mode: phandle to the TCSR hardware block and offset of the
download mode control register (optional)
- interconnects: Specifies the bandwidth requirements of the SCM interface (optional)
Example for MSM8916:

View File

@ -11,7 +11,11 @@ maintainers:
properties:
compatible:
const: xlnx,zynq-gpio-1.0
enum:
- xlnx,zynq-gpio-1.0
- xlnx,zynqmp-gpio-1.0
- xlnx,versal-gpio-1.0
- xlnx,pmc-gpio-1.0
reg:
maxItems: 1
@ -24,6 +28,11 @@ properties:
gpio-controller: true
gpio-line-names:
description: strings describing the names of each gpio line
minItems: 58
maxItems: 174
interrupt-controller: true
"#interrupt-cells":
@ -32,6 +41,54 @@ properties:
clocks:
maxItems: 1
power-domains:
maxItems: 1
allOf:
- if:
properties:
compatible:
enum:
- xlnx,zynqmp-gpio-1.0
then:
properties:
gpio-line-names:
minItems: 174
maxItems: 174
- if:
properties:
compatible:
enum:
- xlnx,zynq-gpio-1.0
then:
properties:
gpio-line-names:
minItems: 118
maxItems: 118
- if:
properties:
compatible:
enum:
- xlnx,versal-gpio-1.0
then:
properties:
gpio-line-names:
minItems: 58
maxItems: 58
- if:
properties:
compatible:
enum:
- xlnx,pmc-gpio-1.0
then:
properties:
gpio-line-names:
minItems: 116
maxItems: 116
required:
- compatible
- reg

View File

@ -1,7 +1,7 @@
# SPDX-License-Identifier: GPL-2.0
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/arm/renesas,prr.yaml#
$id: http://devicetree.org/schemas/hwinfo/renesas,prr.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Renesas Product Register

View File

@ -16,6 +16,7 @@ properties:
- adi,adm1032
- adi,adt7461
- adi,adt7461a
- adi,adt7481
- dallas,max6646
- dallas,max6647
- dallas,max6649
@ -50,6 +51,12 @@ properties:
"#thermal-sensor-cells":
const: 1
'#address-cells':
const: 1
'#size-cells':
const: 0
vcc-supply:
description: phandle to the regulator that provides the +VCC supply
@ -61,6 +68,29 @@ required:
- compatible
- reg
patternProperties:
"^channel@([0-2])$":
type: object
description: Represents channels of the device and their specific configuration.
properties:
reg:
description: The channel number. 0 is local channel, 1-2 are remote channels.
items:
minimum: 0
maximum: 2
label:
description: A descriptive name for this channel, like "ambient" or "psu".
temperature-offset-millicelsius:
description: Temperature offset to be added to or subtracted from remote temperature measurements.
required:
- reg
additionalProperties: false
allOf:
- if:
not:
@ -70,12 +100,84 @@ allOf:
enum:
- adi,adt7461
- adi,adt7461a
- adi,adt7481
- ti,tmp451
- ti,tmp461
then:
properties:
ti,extended-range-enable: false
- if:
properties:
compatible:
contains:
enum:
- dallas,max6646
- dallas,max6647
- dallas,max6649
- dallas,max6657
- dallas,max6658
- dallas,max6659
- dallas,max6695
- dallas,max6696
then:
patternProperties:
"^channel@([0-2])$":
properties:
temperature-offset-millicelsius: false
- if:
properties:
compatible:
contains:
enum:
- adi,adt7461
- adi,adt7461a
- adi,adt7481
- onnn,nct1008
then:
patternProperties:
"^channel@([0-2])$":
properties:
temperature-offset-millicelsius:
maximum: 127750
- if:
properties:
compatible:
contains:
enum:
- adi,adm1032
- dallas,max6680
- dallas,max6681
- gmt,g781
- national,lm86
- national,lm89
- national,lm90
- national,lm99
- nxp,sa56004
- winbond,w83l771
then:
patternProperties:
"^channel@([0-2])$":
properties:
temperature-offset-millicelsius:
maximum: 127875
- if:
properties:
compatible:
contains:
enum:
- ti,tmp451
- ti,tmp461
then:
patternProperties:
"^channel@([0-2])$":
properties:
temperature-offset-millicelsius:
maximum: 127937
additionalProperties: false
examples:
@ -94,3 +196,32 @@ examples:
#thermal-sensor-cells = <1>;
};
};
- |
i2c {
#address-cells = <1>;
#size-cells = <0>;
sensor@4c {
compatible = "adi,adt7481";
reg = <0x4c>;
#address-cells = <1>;
#size-cells = <0>;
channel@0 {
reg = <0x0>;
label = "local";
};
channel@1 {
reg = <0x1>;
label = "front";
temperature-offset-millicelsius = <4000>;
};
channel@2 {
reg = <0x2>;
label = "back";
temperature-offset-millicelsius = <750>;
};
};
};

View File

@ -21,10 +21,18 @@ properties:
- enum:
- allwinner,sun8i-a23-i2c
- allwinner,sun8i-a83t-i2c
- allwinner,sun8i-v536-i2c
- allwinner,sun50i-a64-i2c
- allwinner,sun50i-a100-i2c
- allwinner,sun50i-h6-i2c
- const: allwinner,sun6i-a31-i2c
- description: Allwinner SoCs with offload support
items:
- enum:
- allwinner,sun20i-d1-i2c
- allwinner,sun50i-a100-i2c
- allwinner,sun50i-h616-i2c
- allwinner,sun50i-r329-i2c
- const: allwinner,sun8i-v536-i2c
- const: allwinner,sun6i-a31-i2c
- const: marvell,mv64xxx-i2c
- const: marvell,mv78230-i2c

View File

@ -2,7 +2,7 @@
This module is part of the DA9061/DA9062/DA9063. For more details about entire
DA9062 and DA9061 chips see Documentation/devicetree/bindings/mfd/da9062.txt
For DA9063 see Documentation/devicetree/bindings/mfd/da9063.txt
For DA9063 see Documentation/devicetree/bindings/mfd/dlg,da9063.yaml
This module provides the KEY_POWER event.

View File

@ -0,0 +1,40 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/input/fsl,scu-key.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: i.MX SCU Client Device Node - SCU key bindings based on SCU Message Protocol
maintainers:
- Dong Aisheng <aisheng.dong@nxp.com>
description: i.MX SCU Client Device Node
Client nodes are maintained as children of the relevant IMX-SCU device node.
allOf:
- $ref: input.yaml#
properties:
compatible:
items:
- const: fsl,imx8qxp-sc-key
- const: fsl,imx-sc-key
linux,keycodes:
maxItems: 1
required:
- compatible
- linux,keycodes
additionalProperties: false
examples:
- |
#include <dt-bindings/input/input.h>
keys {
compatible = "fsl,imx8qxp-sc-key", "fsl,imx-sc-key";
linux,keycodes = <KEY_POWER>;
};

View File

@ -0,0 +1,141 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/interconnect/mediatek,cci.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: MediaTek Cache Coherent Interconnect (CCI) frequency and voltage scaling
maintainers:
- Jia-Wei Chang <jia-wei.chang@mediatek.com>
- Johnson Wang <johnson.wang@mediatek.com>
description: |
MediaTek Cache Coherent Interconnect (CCI) is a hardware engine used by
MT8183 and MT8186 SoCs to scale the frequency and adjust the voltage in
hardware. It can also optimize the voltage to reduce the power consumption.
properties:
compatible:
enum:
- mediatek,mt8183-cci
- mediatek,mt8186-cci
clocks:
items:
- description:
The multiplexer for clock input of the bus.
- description:
A parent of "bus" clock which is used as an intermediate clock source
when the original clock source (PLL) is under transition and not
stable yet.
clock-names:
items:
- const: cci
- const: intermediate
operating-points-v2: true
opp-table: true
proc-supply:
description:
Phandle of the regulator for CCI that provides the supply voltage.
sram-supply:
description:
Phandle of the regulator for sram of CCI that provides the supply
voltage. When it is present, the implementation needs to do
"voltage tracking" to step by step scale up/down Vproc and Vsram to fit
SoC specific needs. When absent, the voltage scaling flow is handled by
hardware, hence no software "voltage tracking" is needed.
required:
- compatible
- clocks
- clock-names
- operating-points-v2
- proc-supply
additionalProperties: false
examples:
- |
#include <dt-bindings/clock/mt8183-clk.h>
cci: cci {
compatible = "mediatek,mt8183-cci";
clocks = <&mcucfg CLK_MCU_BUS_SEL>,
<&topckgen CLK_TOP_ARMPLL_DIV_PLL1>;
clock-names = "cci", "intermediate";
operating-points-v2 = <&cci_opp>;
proc-supply = <&mt6358_vproc12_reg>;
};
cci_opp: opp-table-cci {
compatible = "operating-points-v2";
opp-shared;
opp2_00: opp-273000000 {
opp-hz = /bits/ 64 <273000000>;
opp-microvolt = <650000>;
};
opp2_01: opp-338000000 {
opp-hz = /bits/ 64 <338000000>;
opp-microvolt = <687500>;
};
opp2_02: opp-403000000 {
opp-hz = /bits/ 64 <403000000>;
opp-microvolt = <718750>;
};
opp2_03: opp-463000000 {
opp-hz = /bits/ 64 <463000000>;
opp-microvolt = <756250>;
};
opp2_04: opp-546000000 {
opp-hz = /bits/ 64 <546000000>;
opp-microvolt = <800000>;
};
opp2_05: opp-624000000 {
opp-hz = /bits/ 64 <624000000>;
opp-microvolt = <818750>;
};
opp2_06: opp-689000000 {
opp-hz = /bits/ 64 <689000000>;
opp-microvolt = <850000>;
};
opp2_07: opp-767000000 {
opp-hz = /bits/ 64 <767000000>;
opp-microvolt = <868750>;
};
opp2_08: opp-845000000 {
opp-hz = /bits/ 64 <845000000>;
opp-microvolt = <893750>;
};
opp2_09: opp-871000000 {
opp-hz = /bits/ 64 <871000000>;
opp-microvolt = <906250>;
};
opp2_10: opp-923000000 {
opp-hz = /bits/ 64 <923000000>;
opp-microvolt = <931250>;
};
opp2_11: opp-962000000 {
opp-hz = /bits/ 64 <962000000>;
opp-microvolt = <943750>;
};
opp2_12: opp-1027000000 {
opp-hz = /bits/ 64 <1027000000>;
opp-microvolt = <975000>;
};
opp2_13: opp-1092000000 {
opp-hz = /bits/ 64 <1092000000>;
opp-microvolt = <1000000>;
};
opp2_14: opp-1144000000 {
opp-hz = /bits/ 64 <1144000000>;
opp-microvolt = <1025000>;
};
opp2_15: opp-1196000000 {
opp-hz = /bits/ 64 <1196000000>;
opp-microvolt = <1050000>;
};
};

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/interconnect/qcom,msm8998-bwmon.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Qualcomm Interconnect Bandwidth Monitor
maintainers:
- Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
description: |
Bandwidth Monitor measures current throughput on buses between various NoC
fabrics and provides information when it crosses configured thresholds.
Certain SoCs might have more than one Bandwidth Monitors, for example on SDM845::
- Measuring the bandwidth between CPUs and Last Level Cache Controller -
called just BWMON,
- Measuring the bandwidth between Last Level Cache Controller and memory
(DDR) - called LLCC BWMON.
properties:
compatible:
oneOf:
- items:
- enum:
- qcom,sdm845-bwmon
- const: qcom,msm8998-bwmon
- const: qcom,msm8998-bwmon # BWMON v4
interconnects:
maxItems: 1
interrupts:
maxItems: 1
operating-points-v2: true
opp-table: true
reg:
# BWMON v4 (currently described) and BWMON v5 use one register address
# space. BWMON v2 uses two register spaces - not yet described.
maxItems: 1
required:
- compatible
- interconnects
- interrupts
- operating-points-v2
- opp-table
- reg
additionalProperties: false
examples:
- |
#include <dt-bindings/interconnect/qcom,sdm845.h>
#include <dt-bindings/interrupt-controller/arm-gic.h>
pmu@1436400 {
compatible = "qcom,sdm845-bwmon", "qcom,msm8998-bwmon";
reg = <0x01436400 0x600>;
interrupts = <GIC_SPI 581 IRQ_TYPE_LEVEL_HIGH>;
interconnects = <&gladiator_noc MASTER_APPSS_PROC 3 &mem_noc SLAVE_LLCC 3>;
operating-points-v2 = <&cpu_bwmon_opp_table>;
cpu_bwmon_opp_table: opp-table {
compatible = "operating-points-v2";
opp-0 {
opp-peak-kBps = <4800000>;
};
opp-1 {
opp-peak-kBps = <9216000>;
};
opp-2 {
opp-peak-kBps = <15052800>;
};
opp-3 {
opp-peak-kBps = <20889600>;
};
opp-4 {
opp-peak-kBps = <25497600>;
};
};
};

View File

@ -0,0 +1,290 @@
# SPDX-License-Identifier: GPL-2.0
%YAML 1.2
---
$id: http://devicetree.org/schemas/interconnect/samsung,exynos-bus.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Samsung Exynos SoC Bus and Interconnect
maintainers:
- Chanwoo Choi <cw00.choi@samsung.com>
- Krzysztof Kozlowski <krzk@kernel.org>
description: |
The Samsung Exynos SoC has many buses for data transfer between DRAM and
sub-blocks in SoC. Most Exynos SoCs share the common architecture for buses.
Generally, each bus of Exynos SoC includes a source clock and a power line,
which are able to change the clock frequency of the bus in runtime. To
monitor the usage of each bus in runtime, the driver uses the PPMU (Platform
Performance Monitoring Unit), which is able to measure the current load of
sub-blocks.
The Exynos SoC includes the various sub-blocks which have the each AXI bus.
The each AXI bus has the owned source clock but, has not the only owned power
line. The power line might be shared among one more sub-blocks. So, we can
divide into two type of device as the role of each sub-block. There are two
type of bus devices as following::
- parent bus device
- passive bus device
Basically, parent and passive bus device share the same power line. The
parent bus device can only change the voltage of shared power line and the
rest bus devices (passive bus device) depend on the decision of the parent
bus device. If there are three blocks which share the VDD_xxx power line,
Only one block should be parent device and then the rest blocks should depend
on the parent device as passive device.
VDD_xxx |--- A block (parent)
|--- B block (passive)
|--- C block (passive)
There are a little different composition among Exynos SoC because each Exynos
SoC has different sub-blocks. Therefore, such difference should be specified
in devicetree file instead of each device driver. In result, this driver is
able to support the bus frequency for all Exynos SoCs.
Detailed correlation between sub-blocks and power line according
to Exynos SoC::
- In case of Exynos3250, there are two power line as following::
VDD_MIF |--- DMC (Dynamic Memory Controller)
VDD_INT |--- LEFTBUS (parent device)
|--- PERIL
|--- MFC
|--- G3D
|--- RIGHTBUS
|--- PERIR
|--- FSYS
|--- LCD0
|--- PERIR
|--- ISP
|--- CAM
- MIF bus's frequency/voltage table
-----------------------
|Lv| Freq | Voltage |
-----------------------
|L1| 50000 |800000 |
|L2| 100000 |800000 |
|L3| 134000 |800000 |
|L4| 200000 |825000 |
|L5| 400000 |875000 |
-----------------------
- INT bus's frequency/voltage table
----------------------------------------------------------
|Block|LEFTBUS|RIGHTBUS|MCUISP |ISP |PERIL ||VDD_INT |
| name| |LCD0 | | | || |
| | |FSYS | | | || |
| | |MFC | | | || |
----------------------------------------------------------
|Mode |*parent|passive |passive|passive|passive|| |
----------------------------------------------------------
|Lv |Frequency ||Voltage |
----------------------------------------------------------
|L1 |50000 |50000 |50000 |50000 |50000 ||900000 |
|L2 |80000 |80000 |80000 |80000 |80000 ||900000 |
|L3 |100000 |100000 |100000 |100000 |100000 ||1000000 |
|L4 |134000 |134000 |200000 |200000 | ||1000000 |
|L5 |200000 |200000 |400000 |300000 | ||1000000 |
----------------------------------------------------------
- In case of Exynos4210, there is one power line as following::
VDD_INT |--- DMC (parent device, Dynamic Memory Controller)
|--- LEFTBUS
|--- PERIL
|--- MFC(L)
|--- G3D
|--- TV
|--- LCD0
|--- RIGHTBUS
|--- PERIR
|--- MFC(R)
|--- CAM
|--- FSYS
|--- GPS
|--- LCD0
|--- LCD1
- In case of Exynos4x12, there are two power line as following::
VDD_MIF |--- DMC (Dynamic Memory Controller)
VDD_INT |--- LEFTBUS (parent device)
|--- PERIL
|--- MFC(L)
|--- G3D
|--- TV
|--- IMAGE
|--- RIGHTBUS
|--- PERIR
|--- MFC(R)
|--- CAM
|--- FSYS
|--- GPS
|--- LCD0
|--- ISP
- In case of Exynos5422, there are two power line as following::
VDD_MIF |--- DREX 0 (parent device, DRAM EXpress controller)
|--- DREX 1
VDD_INT |--- NoC_Core (parent device)
|--- G2D
|--- G3D
|--- DISP1
|--- NoC_WCORE
|--- GSCL
|--- MSCL
|--- ISP
|--- MFC
|--- GEN
|--- PERIS
|--- PERIC
|--- FSYS
|--- FSYS2
- In case of Exynos5433, there is VDD_INT power line as following::
VDD_INT |--- G2D (parent device)
|--- MSCL
|--- GSCL
|--- JPEG
|--- MFC
|--- HEVC
|--- BUS0
|--- BUS1
|--- BUS2
|--- PERIS (Fixed clock rate)
|--- PERIC (Fixed clock rate)
|--- FSYS (Fixed clock rate)
properties:
compatible:
enum:
- samsung,exynos-bus
clocks:
maxItems: 1
clock-names:
items:
- const: bus
devfreq:
$ref: /schemas/types.yaml#/definitions/phandle
description:
Parent bus device. Valid and required only for the passive bus devices.
devfreq-events:
$ref: /schemas/types.yaml#/definitions/phandle-array
minItems: 1
maxItems: 4
description:
Devfreq-event device to monitor the current utilization of buses. Valid
and required only for the parent bus devices.
exynos,saturation-ratio:
$ref: /schemas/types.yaml#/definitions/uint32
description:
Percentage value which is used to calibrate the performance count against
total cycle count. Valid only for the parent bus devices.
'#interconnect-cells':
const: 0
interconnects:
minItems: 1
maxItems: 2
operating-points-v2: true
samsung,data-clock-ratio:
$ref: /schemas/types.yaml#/definitions/uint32
default: 8
description:
Ratio of the data throughput in B/s to minimum data clock frequency in
Hz.
vdd-supply:
description:
Main bus power rail. Valid and required only for the parent bus devices.
required:
- compatible
- clocks
- clock-names
- operating-points-v2
additionalProperties: false
examples:
- |
#include <dt-bindings/clock/exynos3250.h>
bus-dmc {
compatible = "samsung,exynos-bus";
clocks = <&cmu_dmc CLK_DIV_DMC>;
clock-names = "bus";
operating-points-v2 = <&bus_dmc_opp_table>;
devfreq-events = <&ppmu_dmc0_3>, <&ppmu_dmc1_3>;
vdd-supply = <&buck1_reg>;
};
ppmu_dmc0: ppmu@106a0000 {
compatible = "samsung,exynos-ppmu";
reg = <0x106a0000 0x2000>;
events {
ppmu_dmc0_3: ppmu-event3-dmc0 {
event-name = "ppmu-event3-dmc0";
};
};
};
bus_leftbus: bus-leftbus {
compatible = "samsung,exynos-bus";
clocks = <&cmu CLK_DIV_GDL>;
clock-names = "bus";
operating-points-v2 = <&bus_leftbus_opp_table>;
devfreq-events = <&ppmu_leftbus_3>, <&ppmu_rightbus_3>;
vdd-supply = <&buck3_reg>;
};
bus-rightbus {
compatible = "samsung,exynos-bus";
clocks = <&cmu CLK_DIV_GDR>;
clock-names = "bus";
operating-points-v2 = <&bus_leftbus_opp_table>;
devfreq = <&bus_leftbus>;
};
- |
dmc: bus-dmc {
compatible = "samsung,exynos-bus";
clocks = <&clock CLK_DIV_DMC>;
clock-names = "bus";
operating-points-v2 = <&bus_dmc_opp_table>;
samsung,data-clock-ratio = <4>;
#interconnect-cells = <0>;
devfreq-events = <&ppmu_dmc0_3>, <&ppmu_dmc1_3>;
vdd-supply = <&buck1_reg>;
};
leftbus: bus-leftbus {
compatible = "samsung,exynos-bus";
clocks = <&clock CLK_DIV_GDL>;
clock-names = "bus";
operating-points-v2 = <&bus_leftbus_opp_table>;
interconnects = <&dmc>;
#interconnect-cells = <0>;
devfreq-events = <&ppmu_leftbus_3>, <&ppmu_rightbus_3>;
vdd-supply = <&buck3_reg>;
};
display: bus-display {
compatible = "samsung,exynos-bus";
clocks = <&clock CLK_DIV_ACLK_266>;
clock-names = "bus";
operating-points-v2 = <&bus_display_opp_table>;
interconnects = <&leftbus &dmc>;
#interconnect-cells = <0>;
devfreq = <&leftbus>;
};

View File

@ -0,0 +1,134 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/interrupt-controller/renesas,rzg2l-irqc.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Renesas RZ/G2L (and alike SoC's) Interrupt Controller (IA55)
maintainers:
- Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
- Geert Uytterhoeven <geert+renesas@glider.be>
description: |
IA55 performs various interrupt controls including synchronization for the external
interrupts of NMI, IRQ, and GPIOINT and the interrupts of the built-in peripheral
interrupts output by each IP. And it notifies the interrupt to the GIC
- IRQ sense select for 8 external interrupts, mapped to 8 GIC SPI interrupts
- GPIO pins used as external interrupt input pins, mapped to 32 GIC SPI interrupts
- NMI edge select (NMI is not treated as NMI exception and supports fall edge and
stand-up edge detection interrupts)
allOf:
- $ref: /schemas/interrupt-controller.yaml#
properties:
compatible:
items:
- enum:
- renesas,r9a07g044-irqc # RZ/G2{L,LC}
- renesas,r9a07g054-irqc # RZ/V2L
- const: renesas,rzg2l-irqc
'#interrupt-cells':
description: The first cell should contain external interrupt number (IRQ0-7) and the
second cell is used to specify the flag.
const: 2
'#address-cells':
const: 0
interrupt-controller: true
reg:
maxItems: 1
interrupts:
maxItems: 41
clocks:
maxItems: 2
clock-names:
items:
- const: clk
- const: pclk
power-domains:
maxItems: 1
resets:
maxItems: 1
required:
- compatible
- '#interrupt-cells'
- '#address-cells'
- interrupt-controller
- reg
- interrupts
- clocks
- clock-names
- power-domains
- resets
unevaluatedProperties: false
examples:
- |
#include <dt-bindings/interrupt-controller/arm-gic.h>
#include <dt-bindings/clock/r9a07g044-cpg.h>
irqc: interrupt-controller@110a0000 {
compatible = "renesas,r9a07g044-irqc", "renesas,rzg2l-irqc";
reg = <0x110a0000 0x10000>;
#interrupt-cells = <2>;
#address-cells = <0>;
interrupt-controller;
interrupts = <GIC_SPI 0 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 1 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 2 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 3 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 4 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 5 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 6 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 7 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 8 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 444 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 445 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 446 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 447 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 448 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 449 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 450 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 451 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 452 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 453 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 454 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 455 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 456 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 457 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 458 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 459 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 460 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 461 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 462 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 463 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 464 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 465 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 466 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 467 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 468 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 469 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 470 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 471 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 472 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 473 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 474 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 475 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&cpg CPG_MOD R9A07G044_IA55_CLK>,
<&cpg CPG_MOD R9A07G044_IA55_PCLK>;
clock-names = "clk", "pclk";
power-domains = <&cpg>;
resets = <&cpg R9A07G044_IA55_RESETN>;
};

View File

@ -26,9 +26,14 @@ description:
with priority below this threshold will not cause the PLIC to raise its
interrupt line leading to the context.
While the PLIC supports both edge-triggered and level-triggered interrupts,
interrupt handlers are oblivious to this distinction and therefore it is not
specified in the PLIC device-tree binding.
The PLIC supports both edge-triggered and level-triggered interrupts. For
edge-triggered interrupts, the RISC-V PLIC spec allows two responses to edges
seen while an interrupt handler is active; the PLIC may either queue them or
ignore them. In the first case, handlers are oblivious to the trigger type, so
it is not included in the interrupt specifier. In the second case, software
needs to know the trigger type, so it can reorder the interrupt flow to avoid
missing interrupts. This special handling is needed by at least the Renesas
RZ/Five SoC (AX45MP AndesCore with a NCEPLIC100) and the T-HEAD C900 PLIC.
While the RISC-V ISA doesn't specify a memory layout for the PLIC, the
"sifive,plic-1.0.0" device is a concrete implementation of the PLIC that
@ -47,6 +52,10 @@ maintainers:
properties:
compatible:
oneOf:
- items:
- enum:
- renesas,r9a07g043-plic
- const: andestech,nceplic100
- items:
- enum:
- sifive,fu540-c000-plic
@ -64,8 +73,7 @@ properties:
'#address-cells':
const: 0
'#interrupt-cells':
const: 1
'#interrupt-cells': true
interrupt-controller: true
@ -82,6 +90,12 @@ properties:
description:
Specifies how many external interrupts are supported by this controller.
clocks: true
power-domains: true
resets: true
required:
- compatible
- '#address-cells'
@ -91,6 +105,47 @@ required:
- interrupts-extended
- riscv,ndev
allOf:
- if:
properties:
compatible:
contains:
enum:
- andestech,nceplic100
- thead,c900-plic
then:
properties:
'#interrupt-cells':
const: 2
else:
properties:
'#interrupt-cells':
const: 1
- if:
properties:
compatible:
contains:
const: renesas,r9a07g043-plic
then:
properties:
clocks:
maxItems: 1
power-domains:
maxItems: 1
resets:
maxItems: 1
required:
- clocks
- power-domains
- resets
additionalProperties: false
examples:

View File

@ -0,0 +1,62 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
# Copyright (C) Sunplus Co., Ltd. 2021
%YAML 1.2
---
$id: http://devicetree.org/schemas/interrupt-controller/sunplus,sp7021-intc.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Sunplus SP7021 SoC Interrupt Controller
maintainers:
- Qin Jian <qinjian@cqplus1.com>
properties:
compatible:
items:
- const: sunplus,sp7021-intc
reg:
maxItems: 2
description:
Specifies base physical address(s) and size of the controller regs.
The 1st region include type/polarity/priority/mask regs.
The 2nd region include clear/masked_ext0/masked_ext1/group regs.
interrupt-controller: true
"#interrupt-cells":
const: 2
description:
The first cell is the IRQ number, the second cell is the trigger
type as defined in interrupt.txt in this directory.
interrupts:
maxItems: 2
description:
EXT_INT0 & EXT_INT1, 2 interrupts references to primary interrupt
controller.
required:
- compatible
- reg
- interrupt-controller
- "#interrupt-cells"
- interrupts
additionalProperties: false
examples:
- |
#include <dt-bindings/interrupt-controller/arm-gic.h>
intc: interrupt-controller@9c000780 {
compatible = "sunplus,sp7021-intc";
reg = <0x9c000780 0x80>, <0x9c000a80 0x80>;
interrupt-controller;
#interrupt-cells = <2>;
interrupt-parent = <&gic>;
interrupts = <GIC_SPI 5 IRQ_TYPE_LEVEL_HIGH>, /* EXT_INT0 */
<GIC_SPI 6 IRQ_TYPE_LEVEL_HIGH>; /* EXT_INT1 */
};
...

View File

@ -32,6 +32,7 @@ properties:
- mediatek,mt2701-smi-common
- mediatek,mt2712-smi-common
- mediatek,mt6779-smi-common
- mediatek,mt6795-smi-common
- mediatek,mt8167-smi-common
- mediatek,mt8173-smi-common
- mediatek,mt8183-smi-common

View File

@ -20,6 +20,7 @@ properties:
- mediatek,mt2701-smi-larb
- mediatek,mt2712-smi-larb
- mediatek,mt6779-smi-larb
- mediatek,mt6795-smi-larb
- mediatek,mt8167-smi-larb
- mediatek,mt8173-smi-larb
- mediatek,mt8183-smi-larb

View File

@ -22,6 +22,7 @@ properties:
- enum:
- allwinner,sun20i-d1-emac
- allwinner,sun50i-h6-emac
- allwinner,sun50i-h616-emac0
- const: allwinner,sun50i-a64-emac
reg:

View File

@ -0,0 +1,171 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/net/pcs/renesas,rzn1-miic.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Renesas RZ/N1 MII converter
maintainers:
- Clément Léger <clement.leger@bootlin.com>
description: |
This MII converter is present on the Renesas RZ/N1 SoC family. It is
responsible to do MII passthrough or convert it to RMII/RGMII.
properties:
'#address-cells':
const: 1
'#size-cells':
const: 0
compatible:
items:
- enum:
- renesas,r9a06g032-miic
- const: renesas,rzn1-miic
reg:
maxItems: 1
clocks:
items:
- description: MII reference clock
- description: RGMII reference clock
- description: RMII reference clock
- description: AHB clock used for the MII converter register interface
clock-names:
items:
- const: mii_ref
- const: rgmii_ref
- const: rmii_ref
- const: hclk
renesas,miic-switch-portin:
description: MII Switch PORTIN configuration. This value should use one of
the values defined in dt-bindings/net/pcs-rzn1-miic.h.
$ref: /schemas/types.yaml#/definitions/uint32
enum: [1, 2]
power-domains:
maxItems: 1
patternProperties:
"^mii-conv@[0-5]$":
type: object
description: MII converter port
properties:
reg:
description: MII Converter port number.
enum: [1, 2, 3, 4, 5]
renesas,miic-input:
description: Converter input port configuration. This value should use
one of the values defined in dt-bindings/net/pcs-rzn1-miic.h.
$ref: /schemas/types.yaml#/definitions/uint32
required:
- reg
- renesas,miic-input
additionalProperties: false
allOf:
- if:
properties:
reg:
const: 1
then:
properties:
renesas,miic-input:
const: 0
- if:
properties:
reg:
const: 2
then:
properties:
renesas,miic-input:
enum: [1, 11]
- if:
properties:
reg:
const: 3
then:
properties:
renesas,miic-input:
enum: [7, 10]
- if:
properties:
reg:
const: 4
then:
properties:
renesas,miic-input:
enum: [4, 6, 9, 13]
- if:
properties:
reg:
const: 5
then:
properties:
renesas,miic-input:
enum: [3, 5, 8, 12]
required:
- '#address-cells'
- '#size-cells'
- compatible
- reg
- clocks
- clock-names
- power-domains
additionalProperties: false
examples:
- |
#include <dt-bindings/net/pcs-rzn1-miic.h>
#include <dt-bindings/clock/r9a06g032-sysctrl.h>
eth-miic@44030000 {
#address-cells = <1>;
#size-cells = <0>;
compatible = "renesas,r9a06g032-miic", "renesas,rzn1-miic";
reg = <0x44030000 0x10000>;
clocks = <&sysctrl R9A06G032_CLK_MII_REF>,
<&sysctrl R9A06G032_CLK_RGMII_REF>,
<&sysctrl R9A06G032_CLK_RMII_REF>,
<&sysctrl R9A06G032_HCLK_SWITCH_RG>;
clock-names = "mii_ref", "rgmii_ref", "rmii_ref", "hclk";
renesas,miic-switch-portin = <MIIC_GMAC2_PORT>;
power-domains = <&sysctrl>;
mii_conv1: mii-conv@1 {
renesas,miic-input = <MIIC_GMAC1_PORT>;
reg = <1>;
};
mii_conv2: mii-conv@2 {
renesas,miic-input = <MIIC_SWITCH_PORTD>;
reg = <2>;
};
mii_conv3: mii-conv@3 {
renesas,miic-input = <MIIC_SWITCH_PORTC>;
reg = <3>;
};
mii_conv4: mii-conv@4 {
renesas,miic-input = <MIIC_SWITCH_PORTB>;
reg = <4>;
};
mii_conv5: mii-conv@5 {
renesas,miic-input = <MIIC_SWITCH_PORTA>;
reg = <5>;
};
};

View File

@ -0,0 +1,56 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/nvmem/fsl,scu-ocotp.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: i.MX SCU Client Device Node - OCOTP bindings based on SCU Message Protocol
maintainers:
- Dong Aisheng <aisheng.dong@nxp.com>
description: i.MX SCU Client Device Node
Client nodes are maintained as children of the relevant IMX-SCU device node.
allOf:
- $ref: nvmem.yaml#
properties:
compatible:
enum:
- fsl,imx8qm-scu-ocotp
- fsl,imx8qxp-scu-ocotp
patternProperties:
'^mac@[0-9a-f]*$':
type: object
description:
MAC address.
properties:
reg:
description:
Byte offset within OCOTP where the MAC address is stored
maxItems: 1
required:
- reg
additionalProperties: false
required:
- compatible
unevaluatedProperties: false
examples:
- |
ocotp {
compatible = "fsl,imx8qxp-scu-ocotp";
#address-cells = <1>;
#size-cells = <1>;
fec_mac0: mac@2c4 {
reg = <0x2c4 6>;
};
};

View File

@ -7,6 +7,7 @@ Required properties:
"mediatek,mt7622-pcie"
"mediatek,mt7623-pcie"
"mediatek,mt7629-pcie"
"airoha,en7523-pcie"
- device_type: Must be "pci"
- reg: Base addresses and lengths of the root ports.
- reg-names: Names of the above areas to use during resource lookup.

View File

@ -0,0 +1,319 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/pci/nvidia,tegra194-pcie-ep.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: NVIDIA Tegra194 (and later) PCIe Endpoint controller (Synopsys DesignWare Core based)
maintainers:
- Thierry Reding <thierry.reding@gmail.com>
- Jon Hunter <jonathanh@nvidia.com>
- Vidya Sagar <vidyas@nvidia.com>
description: |
This PCIe controller is based on the Synopsys DesignWare PCIe IP and thus
inherits all the common properties defined in snps,dw-pcie-ep.yaml. Some
of the controller instances are dual mode; they can work either in Root
Port mode or Endpoint mode but one at a time.
On Tegra194, controllers C0, C4 and C5 support Endpoint mode.
On Tegra234, controllers C5, C6, C7 and C10 support Endpoint mode.
Note: On Tegra194's P2972-0000 platform, only C5 controller can be enabled to
operate in the Endpoint mode because of the way the platform is designed.
properties:
compatible:
enum:
- nvidia,tegra194-pcie-ep
- nvidia,tegra234-pcie-ep
reg:
items:
- description: controller's application logic registers
- description: iATU and DMA registers. This is where the iATU (internal
Address Translation Unit) registers of the PCIe core are made
available for software access.
- description: aperture where the Root Port's own configuration
registers are available.
- description: aperture used to map the remote Root Complex address space
reg-names:
items:
- const: appl
- const: atu_dma
- const: dbi
- const: addr_space
interrupts:
items:
- description: controller interrupt
interrupt-names:
items:
- const: intr
clocks:
items:
- description: module clock
clock-names:
items:
- const: core
resets:
items:
- description: APB bus interface reset
- description: module reset
reset-names:
items:
- const: apb
- const: core
reset-gpios:
description: Must contain a phandle to a GPIO controller followed by GPIO
that is being used as PERST input signal. Please refer to pci.txt.
phys:
minItems: 1
maxItems: 8
phy-names:
minItems: 1
items:
- const: p2u-0
- const: p2u-1
- const: p2u-2
- const: p2u-3
- const: p2u-4
- const: p2u-5
- const: p2u-6
- const: p2u-7
power-domains:
maxItems: 1
description: |
A phandle to the node that controls power to the respective PCIe
controller and a specifier name for the PCIe controller.
Tegra194 specifiers are defined in "include/dt-bindings/power/tegra194-powergate.h"
Tegra234 specifiers are defined in "include/dt-bindings/power/tegra234-powergate.h"
interconnects:
items:
- description: memory read client
- description: memory write client
interconnect-names:
items:
- const: dma-mem # read
- const: write
dma-coherent: true
nvidia,bpmp:
$ref: /schemas/types.yaml#/definitions/phandle-array
description: |
Must contain a pair of phandles to BPMP controller node followed by
controller ID. Following are the controller IDs for each controller:
Tegra194
0: C0
1: C1
2: C2
3: C3
4: C4
5: C5
Tegra234
0 : C0
1 : C1
2 : C2
3 : C3
4 : C4
5 : C5
6 : C6
7 : C7
8 : C8
9 : C9
10: C10
items:
- items:
- description: phandle to BPMP controller node
- description: PCIe controller ID
maximum: 10
nvidia,aspm-cmrt-us:
description: Common Mode Restore Time for proper operation of ASPM to be
specified in microseconds
nvidia,aspm-pwr-on-t-us:
description: Power On time for proper operation of ASPM to be specified in
microseconds
nvidia,aspm-l0s-entrance-latency-us:
description: ASPM L0s entrance latency to be specified in microseconds
vddio-pex-ctl-supply:
description: A phandle to the regulator supply for PCIe side band signals
nvidia,refclk-select-gpios:
maxItems: 1
description: GPIO used to enable REFCLK to controller from the host
nvidia,enable-ext-refclk:
description: |
This boolean property needs to be present if the controller is configured
to receive Reference Clock from the host.
NOTE: This is applicable only for Tegra234.
$ref: /schemas/types.yaml#/definitions/flag
nvidia,enable-srns:
description: |
This boolean property needs to be present if the controller is
configured to operate in SRNS (Separate Reference Clocks with No
Spread-Spectrum Clocking). NOTE: This is applicable only for
Tegra234.
$ref: /schemas/types.yaml#/definitions/flag
allOf:
- $ref: /schemas/pci/snps,dw-pcie-ep.yaml#
unevaluatedProperties: false
required:
- interrupts
- interrupt-names
- clocks
- clock-names
- resets
- reset-names
- power-domains
- reset-gpios
- vddio-pex-ctl-supply
- num-lanes
- phys
- phy-names
- nvidia,bpmp
examples:
- |
#include <dt-bindings/clock/tegra194-clock.h>
#include <dt-bindings/gpio/tegra194-gpio.h>
#include <dt-bindings/interrupt-controller/arm-gic.h>
#include <dt-bindings/power/tegra194-powergate.h>
#include <dt-bindings/reset/tegra194-reset.h>
bus@0 {
#address-cells = <2>;
#size-cells = <2>;
ranges = <0x0 0x0 0x0 0x8 0x0>;
pcie-ep@141a0000 {
compatible = "nvidia,tegra194-pcie-ep";
reg = <0x00 0x141a0000 0x0 0x00020000>, /* appl registers (128K) */
<0x00 0x3a040000 0x0 0x00040000>, /* iATU_DMA reg space (256K) */
<0x00 0x3a080000 0x0 0x00040000>, /* DBI reg space (256K) */
<0x1c 0x00000000 0x4 0x00000000>; /* Address Space (16G) */
reg-names = "appl", "atu_dma", "dbi", "addr_space";
interrupts = <GIC_SPI 53 IRQ_TYPE_LEVEL_HIGH>; /* controller interrupt */
interrupt-names = "intr";
clocks = <&bpmp TEGRA194_CLK_PEX1_CORE_5>;
clock-names = "core";
resets = <&bpmp TEGRA194_RESET_PEX1_CORE_5_APB>,
<&bpmp TEGRA194_RESET_PEX1_CORE_5>;
reset-names = "apb", "core";
power-domains = <&bpmp TEGRA194_POWER_DOMAIN_PCIEX8A>;
pinctrl-names = "default";
pinctrl-0 = <&clkreq_c5_bi_dir_state>;
nvidia,bpmp = <&bpmp 5>;
nvidia,aspm-cmrt-us = <60>;
nvidia,aspm-pwr-on-t-us = <20>;
nvidia,aspm-l0s-entrance-latency-us = <3>;
vddio-pex-ctl-supply = <&vdd_1v8ao>;
reset-gpios = <&gpio TEGRA194_MAIN_GPIO(GG, 1) GPIO_ACTIVE_LOW>;
nvidia,refclk-select-gpios = <&gpio_aon TEGRA194_AON_GPIO(AA, 5)
GPIO_ACTIVE_HIGH>;
num-lanes = <8>;
phys = <&p2u_nvhs_0>, <&p2u_nvhs_1>, <&p2u_nvhs_2>,
<&p2u_nvhs_3>, <&p2u_nvhs_4>, <&p2u_nvhs_5>,
<&p2u_nvhs_6>, <&p2u_nvhs_7>;
phy-names = "p2u-0", "p2u-1", "p2u-2", "p2u-3", "p2u-4",
"p2u-5", "p2u-6", "p2u-7";
};
};
- |
#include <dt-bindings/clock/tegra234-clock.h>
#include <dt-bindings/gpio/tegra234-gpio.h>
#include <dt-bindings/interrupt-controller/arm-gic.h>
#include <dt-bindings/power/tegra234-powergate.h>
#include <dt-bindings/reset/tegra234-reset.h>
bus@0 {
#address-cells = <2>;
#size-cells = <2>;
ranges = <0x0 0x0 0x0 0x8 0x0>;
pcie-ep@141a0000 {
compatible = "nvidia,tegra234-pcie-ep";
power-domains = <&bpmp TEGRA234_POWER_DOMAIN_PCIEX8A>;
reg = <0x00 0x141a0000 0x0 0x00020000>, /* appl registers (128K) */
<0x00 0x3a040000 0x0 0x00040000>, /* iATU_DMA reg space (256K) */
<0x00 0x3a080000 0x0 0x00040000>, /* DBI reg space (256K) */
<0x27 0x40000000 0x4 0x00000000>; /* Address Space (16G) */
reg-names = "appl", "atu_dma", "dbi", "addr_space";
interrupts = <GIC_SPI 53 IRQ_TYPE_LEVEL_HIGH>; /* controller interrupt */
interrupt-names = "intr";
clocks = <&bpmp TEGRA234_CLK_PEX1_C5_CORE>;
clock-names = "core";
resets = <&bpmp TEGRA234_RESET_PEX1_CORE_5_APB>,
<&bpmp TEGRA234_RESET_PEX1_CORE_5>;
reset-names = "apb", "core";
nvidia,bpmp = <&bpmp 5>;
nvidia,enable-ext-refclk;
nvidia,aspm-cmrt-us = <60>;
nvidia,aspm-pwr-on-t-us = <20>;
nvidia,aspm-l0s-entrance-latency-us = <3>;
vddio-pex-ctl-supply = <&p3701_vdd_1v8_ls>;
reset-gpios = <&gpio TEGRA234_MAIN_GPIO(AF, 1) GPIO_ACTIVE_LOW>;
nvidia,refclk-select-gpios = <&gpio_aon
TEGRA234_AON_GPIO(AA, 4)
GPIO_ACTIVE_HIGH>;
num-lanes = <8>;
phys = <&p2u_nvhs_0>, <&p2u_nvhs_1>, <&p2u_nvhs_2>,
<&p2u_nvhs_3>, <&p2u_nvhs_4>, <&p2u_nvhs_5>,
<&p2u_nvhs_6>, <&p2u_nvhs_7>;
phy-names = "p2u-0", "p2u-1", "p2u-2", "p2u-3", "p2u-4",
"p2u-5", "p2u-6", "p2u-7";
};
};

View File

@ -1,245 +0,0 @@
NVIDIA Tegra PCIe controller (Synopsys DesignWare Core based)
This PCIe controller is based on the Synopsis Designware PCIe IP
and thus inherits all the common properties defined in snps,dw-pcie.yaml and
snps,dw-pcie-ep.yaml.
Some of the controller instances are dual mode where in they can work either
in root port mode or endpoint mode but one at a time.
Required properties:
- power-domains: A phandle to the node that controls power to the respective
PCIe controller and a specifier name for the PCIe controller. Following are
the specifiers for the different PCIe controllers
TEGRA194_POWER_DOMAIN_PCIEX8B: C0
TEGRA194_POWER_DOMAIN_PCIEX1A: C1
TEGRA194_POWER_DOMAIN_PCIEX1A: C2
TEGRA194_POWER_DOMAIN_PCIEX1A: C3
TEGRA194_POWER_DOMAIN_PCIEX4A: C4
TEGRA194_POWER_DOMAIN_PCIEX8A: C5
these specifiers are defined in
"include/dt-bindings/power/tegra194-powergate.h" file.
- reg: A list of physical base address and length pairs for each set of
controller registers. Must contain an entry for each entry in the reg-names
property.
- reg-names: Must include the following entries:
"appl": Controller's application logic registers
"config": As per the definition in snps,dw-pcie.yaml
"atu_dma": iATU and DMA registers. This is where the iATU (internal Address
Translation Unit) registers of the PCIe core are made available
for SW access.
"dbi": The aperture where root port's own configuration registers are
available
- interrupts: A list of interrupt outputs of the controller. Must contain an
entry for each entry in the interrupt-names property.
- interrupt-names: Must include the following entries:
"intr": The Tegra interrupt that is asserted for controller interrupts
- 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:
- core
- resets: Must contain an entry for each entry in reset-names.
See ../reset/reset.txt for details.
- reset-names: Must include the following entries:
- apb
- core
- phys: Must contain a phandle to P2U PHY for each entry in phy-names.
- phy-names: Must include an entry for each active lane.
"p2u-N": where N ranges from 0 to one less than the total number of lanes
- nvidia,bpmp: Must contain a pair of phandle to BPMP controller node followed
by controller-id. Following are the controller ids for each controller.
0: C0
1: C1
2: C2
3: C3
4: C4
5: C5
- vddio-pex-ctl-supply: Regulator supply for PCIe side band signals
RC mode:
- compatible: Tegra19x must contain "nvidia,tegra194-pcie"
- device_type: Must be "pci" for RC mode
- interrupt-names: Must include the following entries:
"msi": The Tegra interrupt that is asserted when an MSI is received
- bus-range: Range of bus numbers associated with this controller
- #address-cells: Address representation for root ports (must be 3)
- cell 0 specifies the bus and device numbers of the root port:
[23:16]: bus number
[15:11]: device number
- cell 1 denotes the upper 32 address bits and should be 0
- cell 2 contains the lower 32 address bits and is used to translate to the
CPU address space
- #size-cells: Size representation for root ports (must be 2)
- ranges: Describes the translation of addresses for root ports and standard
PCI regions. The entries must be 7 cells each, where the first three cells
correspond to the address as described for the #address-cells property
above, the fourth and fifth cells are for the physical CPU address to
translate to and the sixth and seventh cells are as described for the
#size-cells property above.
- Entries setup the mapping for the standard I/O, memory and
prefetchable PCI regions. The first cell determines the type of region
that is setup:
- 0x81000000: I/O memory region
- 0x82000000: non-prefetchable memory region
- 0xc2000000: prefetchable memory region
Please refer to the standard PCI bus binding document for a more detailed
explanation.
- #interrupt-cells: Size representation for interrupts (must be 1)
- interrupt-map-mask and interrupt-map: Standard PCI IRQ mapping properties
Please refer to the standard PCI bus binding document for a more detailed
explanation.
EP mode:
In Tegra194, Only controllers C0, C4 & C5 support EP mode.
- compatible: Tegra19x must contain "nvidia,tegra194-pcie-ep"
- reg-names: Must include the following entries:
"addr_space": Used to map remote RC address space
- reset-gpios: Must contain a phandle to a GPIO controller followed by
GPIO that is being used as PERST input signal. Please refer to pci.txt
document.
Optional properties:
- pinctrl-names: A list of pinctrl state names.
It is mandatory for C5 controller and optional for other controllers.
- "default": Configures PCIe I/O for proper operation.
- pinctrl-0: phandle for the 'default' state of pin configuration.
It is mandatory for C5 controller and optional for other controllers.
- supports-clkreq: Refer to Documentation/devicetree/bindings/pci/pci.txt
- nvidia,update-fc-fixup: This is a boolean property and needs to be present to
improve performance when a platform is designed in such a way that it
satisfies at least one of the following conditions thereby enabling root
port to exchange optimum number of FC (Flow Control) credits with
downstream devices
1. If C0/C4/C5 run at x1/x2 link widths (irrespective of speed and MPS)
2. If C0/C1/C2/C3/C4/C5 operate at their respective max link widths and
a) speed is Gen-2 and MPS is 256B
b) speed is >= Gen-3 with any MPS
- nvidia,aspm-cmrt-us: Common Mode Restore Time for proper operation of ASPM
to be specified in microseconds
- nvidia,aspm-pwr-on-t-us: Power On time for proper operation of ASPM to be
specified in microseconds
- nvidia,aspm-l0s-entrance-latency-us: ASPM L0s entrance latency to be
specified in microseconds
RC mode:
- vpcie3v3-supply: A phandle to the regulator node that supplies 3.3V to the slot
if the platform has one such slot. (Ex:- x16 slot owned by C5 controller
in p2972-0000 platform).
- vpcie12v-supply: A phandle to the regulator node that supplies 12V to the slot
if the platform has one such slot. (Ex:- x16 slot owned by C5 controller
in p2972-0000 platform).
EP mode:
- nvidia,refclk-select-gpios: Must contain a phandle to a GPIO controller
followed by GPIO that is being used to enable REFCLK to controller from host
NOTE:- On Tegra194's P2972-0000 platform, only C5 controller can be enabled to
operate in the endpoint mode because of the way the platform is designed.
Examples:
=========
Tegra194 RC mode:
-----------------
pcie@14180000 {
compatible = "nvidia,tegra194-pcie";
power-domains = <&bpmp TEGRA194_POWER_DOMAIN_PCIEX8B>;
reg = <0x00 0x14180000 0x0 0x00020000 /* appl registers (128K) */
0x00 0x38000000 0x0 0x00040000 /* configuration space (256K) */
0x00 0x38040000 0x0 0x00040000>; /* iATU_DMA reg space (256K) */
reg-names = "appl", "config", "atu_dma";
#address-cells = <3>;
#size-cells = <2>;
device_type = "pci";
num-lanes = <8>;
linux,pci-domain = <0>;
pinctrl-names = "default";
pinctrl-0 = <&pex_rst_c5_out_state>, <&clkreq_c5_bi_dir_state>;
clocks = <&bpmp TEGRA194_CLK_PEX0_CORE_0>;
clock-names = "core";
resets = <&bpmp TEGRA194_RESET_PEX0_CORE_0_APB>,
<&bpmp TEGRA194_RESET_PEX0_CORE_0>;
reset-names = "apb", "core";
interrupts = <GIC_SPI 72 IRQ_TYPE_LEVEL_HIGH>, /* controller interrupt */
<GIC_SPI 73 IRQ_TYPE_LEVEL_HIGH>; /* MSI interrupt */
interrupt-names = "intr", "msi";
#interrupt-cells = <1>;
interrupt-map-mask = <0 0 0 0>;
interrupt-map = <0 0 0 0 &gic GIC_SPI 72 IRQ_TYPE_LEVEL_HIGH>;
nvidia,bpmp = <&bpmp 0>;
supports-clkreq;
nvidia,aspm-cmrt-us = <60>;
nvidia,aspm-pwr-on-t-us = <20>;
nvidia,aspm-l0s-entrance-latency-us = <3>;
bus-range = <0x0 0xff>;
ranges = <0x81000000 0x0 0x38100000 0x0 0x38100000 0x0 0x00100000 /* downstream I/O (1MB) */
0x82000000 0x0 0x38200000 0x0 0x38200000 0x0 0x01E00000 /* non-prefetchable memory (30MB) */
0xc2000000 0x18 0x00000000 0x18 0x00000000 0x4 0x00000000>; /* prefetchable memory (16GB) */
vddio-pex-ctl-supply = <&vdd_1v8ao>;
vpcie3v3-supply = <&vdd_3v3_pcie>;
vpcie12v-supply = <&vdd_12v_pcie>;
phys = <&p2u_hsio_2>, <&p2u_hsio_3>, <&p2u_hsio_4>,
<&p2u_hsio_5>;
phy-names = "p2u-0", "p2u-1", "p2u-2", "p2u-3";
};
Tegra194 EP mode:
-----------------
pcie-ep@141a0000 {
compatible = "nvidia,tegra194-pcie-ep", "snps,dw-pcie-ep";
power-domains = <&bpmp TEGRA194_POWER_DOMAIN_PCIEX8A>;
reg = <0x00 0x141a0000 0x0 0x00020000 /* appl registers (128K) */
0x00 0x3a040000 0x0 0x00040000 /* iATU_DMA reg space (256K) */
0x00 0x3a080000 0x0 0x00040000 /* DBI reg space (256K) */
0x1c 0x00000000 0x4 0x00000000>; /* Address Space (16G) */
reg-names = "appl", "atu_dma", "dbi", "addr_space";
num-lanes = <8>;
num-ib-windows = <2>;
num-ob-windows = <8>;
pinctrl-names = "default";
pinctrl-0 = <&clkreq_c5_bi_dir_state>;
clocks = <&bpmp TEGRA194_CLK_PEX1_CORE_5>;
clock-names = "core";
resets = <&bpmp TEGRA194_RESET_PEX1_CORE_5_APB>,
<&bpmp TEGRA194_RESET_PEX1_CORE_5>;
reset-names = "apb", "core";
interrupts = <GIC_SPI 53 IRQ_TYPE_LEVEL_HIGH>; /* controller interrupt */
interrupt-names = "intr";
nvidia,bpmp = <&bpmp 5>;
nvidia,aspm-cmrt-us = <60>;
nvidia,aspm-pwr-on-t-us = <20>;
nvidia,aspm-l0s-entrance-latency-us = <3>;
vddio-pex-ctl-supply = <&vdd_1v8ao>;
reset-gpios = <&gpio TEGRA194_MAIN_GPIO(GG, 1) GPIO_ACTIVE_LOW>;
nvidia,refclk-select-gpios = <&gpio_aon TEGRA194_AON_GPIO(AA, 5)
GPIO_ACTIVE_HIGH>;
phys = <&p2u_nvhs_0>, <&p2u_nvhs_1>, <&p2u_nvhs_2>,
<&p2u_nvhs_3>, <&p2u_nvhs_4>, <&p2u_nvhs_5>,
<&p2u_nvhs_6>, <&p2u_nvhs_7>;
phy-names = "p2u-0", "p2u-1", "p2u-2", "p2u-3", "p2u-4",
"p2u-5", "p2u-6", "p2u-7";
};

View File

@ -0,0 +1,350 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/pci/nvidia,tegra194-pcie.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: NVIDIA Tegra194 (and later) PCIe controller (Synopsys DesignWare Core based)
maintainers:
- Thierry Reding <thierry.reding@gmail.com>
- Jon Hunter <jonathanh@nvidia.com>
- Vidya Sagar <vidyas@nvidia.com>
description: |
This PCIe controller is based on the Synopsys DesignWare PCIe IP and thus
inherits all the common properties defined in snps,dw-pcie.yaml. Some of
the controller instances are dual mode where in they can work either in
Root Port mode or Endpoint mode but one at a time.
See nvidia,tegra194-pcie-ep.yaml for details on the Endpoint mode device
tree bindings.
properties:
compatible:
enum:
- nvidia,tegra194-pcie
- nvidia,tegra234-pcie
reg:
items:
- description: controller's application logic registers
- description: configuration registers
- description: iATU and DMA registers. This is where the iATU (internal
Address Translation Unit) registers of the PCIe core are made
available for software access.
- description: aperture where the Root Port's own configuration
registers are available.
reg-names:
items:
- const: appl
- const: config
- const: atu_dma
- const: dbi
interrupts:
items:
- description: controller interrupt
- description: MSI interrupt
interrupt-names:
items:
- const: intr
- const: msi
clocks:
items:
- description: module clock
clock-names:
items:
- const: core
resets:
items:
- description: APB bus interface reset
- description: module reset
reset-names:
items:
- const: apb
- const: core
phys:
minItems: 1
maxItems: 8
phy-names:
minItems: 1
items:
- const: p2u-0
- const: p2u-1
- const: p2u-2
- const: p2u-3
- const: p2u-4
- const: p2u-5
- const: p2u-6
- const: p2u-7
power-domains:
maxItems: 1
description: |
A phandle to the node that controls power to the respective PCIe
controller and a specifier name for the PCIe controller.
Tegra194 specifiers defined in "include/dt-bindings/power/tegra194-powergate.h"
Tegra234 specifiers defined in "include/dt-bindings/power/tegra234-powergate.h"
interconnects:
items:
- description: memory read client
- description: memory write client
interconnect-names:
items:
- const: dma-mem # read
- const: write
dma-coherent: true
nvidia,bpmp:
$ref: /schemas/types.yaml#/definitions/phandle-array
description: |
Must contain a pair of phandles to BPMP controller node followed by
controller ID. Following are the controller IDs for each controller:
Tegra194
0: C0
1: C1
2: C2
3: C3
4: C4
5: C5
Tegra234
0 : C0
1 : C1
2 : C2
3 : C3
4 : C4
5 : C5
6 : C6
7 : C7
8 : C8
9 : C9
10: C10
items:
- items:
- description: phandle to BPMP controller node
- description: PCIe controller ID
maximum: 10
nvidia,update-fc-fixup:
description: |
This is a boolean property and needs to be present to improve performance
when a platform is designed in such a way that it satisfies at least one
of the following conditions thereby enabling Root Port to exchange
optimum number of FC (Flow Control) credits with downstream devices:
NOTE: This is applicable only for Tegra194.
1. If C0/C4/C5 run at x1/x2 link widths (irrespective of speed and MPS)
2. If C0/C1/C2/C3/C4/C5 operate at their respective max link widths and
a) speed is Gen-2 and MPS is 256B
b) speed is >= Gen-3 with any MPS
$ref: /schemas/types.yaml#/definitions/flag
nvidia,aspm-cmrt-us:
description: Common Mode Restore Time for proper operation of ASPM to be
specified in microseconds
nvidia,aspm-pwr-on-t-us:
description: Power On time for proper operation of ASPM to be specified in
microseconds
nvidia,aspm-l0s-entrance-latency-us:
description: ASPM L0s entrance latency to be specified in microseconds
vddio-pex-ctl-supply:
description: A phandle to the regulator supply for PCIe side band signals.
vpcie3v3-supply:
description: A phandle to the regulator node that supplies 3.3V to the slot
if the platform has one such slot, e.g., x16 slot owned by C5 controller
in p2972-0000 platform.
vpcie12v-supply:
description: A phandle to the regulator node that supplies 12V to the slot
if the platform has one such slot, e.g., x16 slot owned by C5 controller
in p2972-0000 platform.
nvidia,enable-srns:
description: |
This boolean property needs to be present if the controller is
configured to operate in SRNS (Separate Reference Clocks with No
Spread-Spectrum Clocking). NOTE: This is applicable only for
Tegra234.
$ref: /schemas/types.yaml#/definitions/flag
nvidia,enable-ext-refclk:
description: |
This boolean property needs to be present if the controller is
configured to use the reference clocking coming in from an external
clock source instead of using the internal clock source.
$ref: /schemas/types.yaml#/definitions/flag
allOf:
- $ref: /schemas/pci/snps,dw-pcie.yaml#
unevaluatedProperties: false
required:
- interrupts
- interrupt-names
- interrupt-map
- interrupt-map-mask
- clocks
- clock-names
- resets
- reset-names
- power-domains
- vddio-pex-ctl-supply
- num-lanes
- phys
- phy-names
- nvidia,bpmp
examples:
- |
#include <dt-bindings/clock/tegra194-clock.h>
#include <dt-bindings/interrupt-controller/arm-gic.h>
#include <dt-bindings/power/tegra194-powergate.h>
#include <dt-bindings/reset/tegra194-reset.h>
bus@0 {
#address-cells = <2>;
#size-cells = <2>;
ranges = <0x0 0x0 0x0 0x8 0x0>;
pcie@14180000 {
compatible = "nvidia,tegra194-pcie";
power-domains = <&bpmp TEGRA194_POWER_DOMAIN_PCIEX8B>;
reg = <0x0 0x14180000 0x0 0x00020000>, /* appl registers (128K) */
<0x0 0x38000000 0x0 0x00040000>, /* configuration space (256K) */
<0x0 0x38040000 0x0 0x00040000>, /* iATU_DMA reg space (256K) */
<0x0 0x38080000 0x0 0x00040000>; /* DBI reg space (256K) */
reg-names = "appl", "config", "atu_dma", "dbi";
#address-cells = <3>;
#size-cells = <2>;
device_type = "pci";
num-lanes = <8>;
linux,pci-domain = <0>;
pinctrl-names = "default";
pinctrl-0 = <&pex_rst_c5_out_state>, <&clkreq_c5_bi_dir_state>;
clocks = <&bpmp TEGRA194_CLK_PEX0_CORE_0>;
clock-names = "core";
resets = <&bpmp TEGRA194_RESET_PEX0_CORE_0_APB>,
<&bpmp TEGRA194_RESET_PEX0_CORE_0>;
reset-names = "apb", "core";
interrupts = <GIC_SPI 72 IRQ_TYPE_LEVEL_HIGH>, /* controller interrupt */
<GIC_SPI 73 IRQ_TYPE_LEVEL_HIGH>; /* MSI interrupt */
interrupt-names = "intr", "msi";
#interrupt-cells = <1>;
interrupt-map-mask = <0 0 0 0>;
interrupt-map = <0 0 0 0 &gic GIC_SPI 72 IRQ_TYPE_LEVEL_HIGH>;
nvidia,bpmp = <&bpmp 0>;
supports-clkreq;
nvidia,aspm-cmrt-us = <60>;
nvidia,aspm-pwr-on-t-us = <20>;
nvidia,aspm-l0s-entrance-latency-us = <3>;
bus-range = <0x0 0xff>;
ranges = <0x81000000 0x0 0x38100000 0x0 0x38100000 0x0 0x00100000>, /* downstream I/O */
<0x82000000 0x0 0x38200000 0x0 0x38200000 0x0 0x01e00000>, /* non-prefetch memory */
<0xc2000000 0x18 0x00000000 0x18 0x00000000 0x4 0x00000000>; /* prefetchable memory */
vddio-pex-ctl-supply = <&vdd_1v8ao>;
vpcie3v3-supply = <&vdd_3v3_pcie>;
vpcie12v-supply = <&vdd_12v_pcie>;
phys = <&p2u_hsio_2>, <&p2u_hsio_3>, <&p2u_hsio_4>,
<&p2u_hsio_5>;
phy-names = "p2u-0", "p2u-1", "p2u-2", "p2u-3";
};
};
- |
#include <dt-bindings/clock/tegra234-clock.h>
#include <dt-bindings/interrupt-controller/arm-gic.h>
#include <dt-bindings/power/tegra234-powergate.h>
#include <dt-bindings/reset/tegra234-reset.h>
bus@0 {
#address-cells = <2>;
#size-cells = <2>;
ranges = <0x0 0x0 0x0 0x8 0x0>;
pcie@14160000 {
compatible = "nvidia,tegra234-pcie";
power-domains = <&bpmp TEGRA234_POWER_DOMAIN_PCIEX4BB>;
reg = <0x00 0x14160000 0x0 0x00020000>, /* appl registers (128K) */
<0x00 0x36000000 0x0 0x00040000>, /* configuration space (256K) */
<0x00 0x36040000 0x0 0x00040000>, /* iATU_DMA reg space (256K) */
<0x00 0x36080000 0x0 0x00040000>; /* DBI reg space (256K) */
reg-names = "appl", "config", "atu_dma", "dbi";
#address-cells = <3>;
#size-cells = <2>;
device_type = "pci";
num-lanes = <4>;
num-viewport = <8>;
linux,pci-domain = <4>;
clocks = <&bpmp TEGRA234_CLK_PEX0_C4_CORE>;
clock-names = "core";
resets = <&bpmp TEGRA234_RESET_PEX0_CORE_4_APB>,
<&bpmp TEGRA234_RESET_PEX0_CORE_4>;
reset-names = "apb", "core";
interrupts = <GIC_SPI 51 IRQ_TYPE_LEVEL_HIGH>, /* controller interrupt */
<GIC_SPI 52 IRQ_TYPE_LEVEL_HIGH>; /* MSI interrupt */
interrupt-names = "intr", "msi";
#interrupt-cells = <1>;
interrupt-map-mask = <0 0 0 0>;
interrupt-map = <0 0 0 0 &gic GIC_SPI 51 IRQ_TYPE_LEVEL_HIGH>;
nvidia,bpmp = <&bpmp 4>;
nvidia,aspm-cmrt-us = <60>;
nvidia,aspm-pwr-on-t-us = <20>;
nvidia,aspm-l0s-entrance-latency-us = <3>;
bus-range = <0x0 0xff>;
ranges = <0x43000000 0x21 0x40000000 0x21 0x40000000 0x2 0xe8000000>, /* prefetchable */
<0x02000000 0x0 0x40000000 0x24 0x28000000 0x0 0x08000000>, /* non-prefetchable */
<0x01000000 0x0 0x36100000 0x00 0x36100000 0x0 0x00100000>; /* downstream I/O */
vddio-pex-ctl-supply = <&p3701_vdd_AO_1v8>;
phys = <&p2u_hsio_4>, <&p2u_hsio_5>, <&p2u_hsio_6>,
<&p2u_hsio_7>;
phy-names = "p2u-0", "p2u-1", "p2u-2", "p2u-3";
};
};

View File

@ -1,84 +0,0 @@
Renesas AHB to PCI bridge
-------------------------
This is the bridge used internally to connect the USB controllers to the
AHB. There is one bridge instance per USB port connected to the internal
OHCI and EHCI controllers.
Required properties:
- compatible: "renesas,pci-r8a7742" for the R8A7742 SoC;
"renesas,pci-r8a7743" for the R8A7743 SoC;
"renesas,pci-r8a7744" for the R8A7744 SoC;
"renesas,pci-r8a7745" for the R8A7745 SoC;
"renesas,pci-r8a7790" for the R8A7790 SoC;
"renesas,pci-r8a7791" for the R8A7791 SoC;
"renesas,pci-r8a7793" for the R8A7793 SoC;
"renesas,pci-r8a7794" for the R8A7794 SoC;
"renesas,pci-rcar-gen2" for a generic R-Car Gen2 or
RZ/G1 compatible device.
When compatible with the generic version, nodes must list the
SoC-specific version corresponding to the platform first
followed by the generic version.
- reg: A list of physical regions to access the device: the first is
the operational registers for the OHCI/EHCI controllers and the
second is for the bridge configuration and control registers.
- interrupts: interrupt for the device.
- clocks: The reference to the device clock.
- bus-range: The PCI bus number range; as this is a single bus, the range
should be specified as the same value twice.
- #address-cells: must be 3.
- #size-cells: must be 2.
- #interrupt-cells: must be 1.
- interrupt-map: standard property used to define the mapping of the PCI
interrupts to the GIC interrupts.
- interrupt-map-mask: standard property that helps to define the interrupt
mapping.
Optional properties:
- dma-ranges: a single range for the inbound memory region. If not supplied,
defaults to 1GiB at 0x40000000. Note there are hardware restrictions on the
allowed combinations of address and size.
Example SoC configuration:
pci0: pci@ee090000 {
compatible = "renesas,pci-r8a7790", "renesas,pci-rcar-gen2";
clocks = <&mstp7_clks R8A7790_CLK_EHCI>;
reg = <0x0 0xee090000 0x0 0xc00>,
<0x0 0xee080000 0x0 0x1100>;
interrupts = <0 108 IRQ_TYPE_LEVEL_HIGH>;
status = "disabled";
bus-range = <0 0>;
#address-cells = <3>;
#size-cells = <2>;
#interrupt-cells = <1>;
dma-ranges = <0x42000000 0 0x40000000 0 0x40000000 0 0x40000000>;
interrupt-map-mask = <0xff00 0 0 0x7>;
interrupt-map = <0x0000 0 0 1 &gic 0 108 IRQ_TYPE_LEVEL_HIGH
0x0800 0 0 1 &gic 0 108 IRQ_TYPE_LEVEL_HIGH
0x1000 0 0 2 &gic 0 108 IRQ_TYPE_LEVEL_HIGH>;
usb@1,0 {
reg = <0x800 0 0 0 0>;
phys = <&usb0 0>;
phy-names = "usb";
};
usb@2,0 {
reg = <0x1000 0 0 0 0>;
phys = <&usb0 0>;
phy-names = "usb";
};
};
Example board setup:
&pci0 {
status = "okay";
pinctrl-0 = <&usb0_pins>;
pinctrl-names = "default";
};

View File

@ -11,7 +11,7 @@ maintainers:
- Stanimir Varbanov <svarbanov@mm-sol.com>
description: |
Qualcomm PCIe root complex controller is bansed on the Synopsys DesignWare
Qualcomm PCIe root complex controller is based on the Synopsys DesignWare
PCIe IP.
properties:
@ -43,11 +43,12 @@ properties:
maxItems: 5
interrupts:
maxItems: 1
minItems: 1
maxItems: 8
interrupt-names:
items:
- const: msi
minItems: 1
maxItems: 8
# Common definitions for clocks, clock-names and reset.
# Platform constraints are described later.
@ -614,7 +615,7 @@ allOf:
- if:
not:
properties:
compatibles:
compatible:
contains:
enum:
- qcom,pcie-msm8996
@ -623,6 +624,50 @@ allOf:
- resets
- reset-names
# Newer chipsets support either 1 or 8 MSI vectors
# On older chipsets it's always 1 MSI vector
- if:
properties:
compatible:
contains:
enum:
- qcom,pcie-msm8996
- qcom,pcie-sc7280
- qcom,pcie-sc8180x
- qcom,pcie-sdm845
- qcom,pcie-sm8150
- qcom,pcie-sm8250
- qcom,pcie-sm8450-pcie0
- qcom,pcie-sm8450-pcie1
then:
oneOf:
- properties:
interrupts:
maxItems: 1
interrupt-names:
items:
- const: msi
- properties:
interrupts:
minItems: 8
interrupt-names:
items:
- const: msi0
- const: msi1
- const: msi2
- const: msi3
- const: msi4
- const: msi5
- const: msi6
- const: msi7
else:
properties:
interrupts:
maxItems: 1
interrupt-names:
items:
- const: msi
unevaluatedProperties: false
examples:

View File

@ -0,0 +1,186 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/pci/renesas,pci-rcar-gen2.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Renesas AHB to PCI bridge
maintainers:
- Marek Vasut <marek.vasut+renesas@gmail.com>
- Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
description: |
This is the bridge used internally to connect the USB controllers to the
AHB. There is one bridge instance per USB port connected to the internal
OHCI and EHCI controllers.
properties:
compatible:
oneOf:
- items:
- enum:
- renesas,pci-r8a7742 # RZ/G1H
- renesas,pci-r8a7743 # RZ/G1M
- renesas,pci-r8a7744 # RZ/G1N
- renesas,pci-r8a7745 # RZ/G1E
- renesas,pci-r8a7790 # R-Car H2
- renesas,pci-r8a7791 # R-Car M2-W
- renesas,pci-r8a7793 # R-Car M2-N
- renesas,pci-r8a7794 # R-Car E2
- const: renesas,pci-rcar-gen2 # R-Car Gen2 and RZ/G1
- items:
- enum:
- renesas,pci-r9a06g032 # RZ/N1D
- const: renesas,pci-rzn1 # RZ/N1
reg:
items:
- description: Operational registers for the OHCI/EHCI controllers.
- description: Bridge configuration and control registers.
interrupts:
maxItems: 1
clocks: true
clock-names: true
resets:
maxItems: 1
power-domains:
maxItems: 1
bus-range:
description: |
The PCI bus number range; as this is a single bus, the range
should be specified as the same value twice.
dma-ranges:
description: |
A single range for the inbound memory region. If not supplied,
defaults to 1GiB at 0x40000000. Note there are hardware restrictions on
the allowed combinations of address and size.
maxItems: 1
patternProperties:
'usb@[0-1],0':
type: object
description:
This a USB controller PCI device
properties:
reg:
description:
Identify the correct bus, device and function number in the
form <bdf 0 0 0 0>.
items:
minItems: 5
maxItems: 5
phys:
description:
Reference to the USB phy
maxItems: 1
phy-names:
maxItems: 1
required:
- reg
- phys
- phy-names
unevaluatedProperties: false
required:
- compatible
- reg
- interrupts
- interrupt-map
- interrupt-map-mask
- clocks
- power-domains
- bus-range
- "#address-cells"
- "#size-cells"
- "#interrupt-cells"
allOf:
- $ref: /schemas/pci/pci-bus.yaml#
- if:
properties:
compatible:
contains:
enum:
- renesas,pci-rzn1
then:
properties:
clocks:
items:
- description: Internal bus clock (AHB) for HOST
- description: Internal bus clock (AHB) Power Management
- description: PCI clock for USB subsystem
clock-names:
items:
- const: hclkh
- const: hclkpm
- const: pciclk
required:
- clock-names
else:
properties:
clocks:
items:
- description: Device clock
clock-names:
items:
- const: pclk
required:
- resets
unevaluatedProperties: false
examples:
- |
#include <dt-bindings/interrupt-controller/arm-gic.h>
#include <dt-bindings/clock/r8a7790-cpg-mssr.h>
#include <dt-bindings/power/r8a7790-sysc.h>
pci@ee090000 {
compatible = "renesas,pci-r8a7790", "renesas,pci-rcar-gen2";
device_type = "pci";
reg = <0xee090000 0xc00>,
<0xee080000 0x1100>;
clocks = <&cpg CPG_MOD 703>;
power-domains = <&sysc R8A7790_PD_ALWAYS_ON>;
resets = <&cpg 703>;
interrupts = <GIC_SPI 108 IRQ_TYPE_LEVEL_HIGH>;
bus-range = <0 0>;
#address-cells = <3>;
#size-cells = <2>;
#interrupt-cells = <1>;
ranges = <0x02000000 0 0xee080000 0xee080000 0 0x00010000>;
dma-ranges = <0x42000000 0 0x40000000 0x40000000 0 0x40000000>;
interrupt-map-mask = <0xf800 0 0 0x7>;
interrupt-map = <0x0000 0 0 1 &gic GIC_SPI 108 IRQ_TYPE_LEVEL_HIGH>,
<0x0800 0 0 1 &gic GIC_SPI 108 IRQ_TYPE_LEVEL_HIGH>,
<0x1000 0 0 2 &gic GIC_SPI 108 IRQ_TYPE_LEVEL_HIGH>;
usb@1,0 {
reg = <0x800 0 0 0 0>;
phys = <&usb0 0>;
phy-names = "usb";
};
usb@2,0 {
reg = <0x1000 0 0 0 0>;
phys = <&usb0 0>;
phy-names = "usb";
};
};

View File

@ -34,8 +34,8 @@ properties:
minItems: 2
maxItems: 5
items:
enum: [ dbi, dbi2, config, atu, app, elbi, mgmt, ctrl, parf, cfg, link,
ulreg, smu, mpu, apb, phy ]
enum: [ dbi, dbi2, config, atu, atu_dma, app, appl, elbi, mgmt, ctrl,
parf, cfg, link, ulreg, smu, mpu, apb, phy ]
num-lanes:
description: |

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