Merge tag 'v5.15-rc1' into `android-mainline`
Linux 5.15-rc1 Signed-off-by: Greg Kroah-Hartman <gregkh@google.com> Change-Id: Ib4933c598d27b18268860e7549966ef7724652fc
This commit is contained in:
Greg Kroah-Hartman
commit
e74ef7cf8f
|
|
@ -128,6 +128,8 @@ Date: Aug 28, 2020
|
|||
KernelVersion: 5.10.0
|
||||
Contact: dmaengine@vger.kernel.org
|
||||
Description: The last executed device administrative command's status/error.
|
||||
Also last configuration error overloaded.
|
||||
Writing to it will clear the status.
|
||||
|
||||
What: /sys/bus/dsa/devices/wq<m>.<n>/block_on_fault
|
||||
Date: Oct 27, 2020
|
||||
|
|
@ -211,6 +213,13 @@ Contact: dmaengine@vger.kernel.org
|
|||
Description: Indicate whether ATS disable is turned on for the workqueue.
|
||||
0 indicates ATS is on, and 1 indicates ATS is off for the workqueue.
|
||||
|
||||
What: /sys/bus/dsa/devices/wq<m>.<n>/occupancy
|
||||
Date May 25, 2021
|
||||
KernelVersion: 5.14.0
|
||||
Contact: dmaengine@vger.kernel.org
|
||||
Description: Show the current number of entries in this WQ if WQ Occupancy
|
||||
Support bit WQ capabilities is 1.
|
||||
|
||||
What: /sys/bus/dsa/devices/engine<m>.<n>/group_id
|
||||
Date: Oct 25, 2019
|
||||
KernelVersion: 5.6.0
|
||||
|
|
|
|||
|
|
@ -215,6 +215,17 @@ Description: Sets the skip reset on timeout option for the device. Value of
|
|||
"0" means device will be reset in case some CS has timed out,
|
||||
otherwise it will not be reset.
|
||||
|
||||
What: /sys/kernel/debug/habanalabs/hl<n>/state_dump
|
||||
Date: Oct 2021
|
||||
KernelVersion: 5.15
|
||||
Contact: ynudelman@habana.ai
|
||||
Description: Gets the state dump occurring on a CS timeout or failure.
|
||||
State dump is used for debug and is created each time in case of
|
||||
a problem in a CS execution, before reset.
|
||||
Reading from the node returns the newest state dump available.
|
||||
Writing an integer X discards X state dumps, so that the
|
||||
next read would return X+1-st newest state dump.
|
||||
|
||||
What: /sys/kernel/debug/habanalabs/hl<n>/stop_on_err
|
||||
Date: Mar 2020
|
||||
KernelVersion: 5.6
|
||||
|
|
@ -230,6 +241,14 @@ Description: Displays a list with information about the currently user
|
|||
pointers (user virtual addresses) that are pinned and mapped
|
||||
to DMA addresses
|
||||
|
||||
What: /sys/kernel/debug/habanalabs/hl<n>/userptr_lookup
|
||||
Date: Aug 2021
|
||||
KernelVersion: 5.15
|
||||
Contact: ogabbay@kernel.org
|
||||
Description: Allows to search for specific user pointers (user virtual
|
||||
addresses) that are pinned and mapped to DMA addresses, and see
|
||||
their resolution to the specific dma address.
|
||||
|
||||
What: /sys/kernel/debug/habanalabs/hl<n>/vm
|
||||
Date: Jan 2019
|
||||
KernelVersion: 5.1
|
||||
|
|
|
|||
|
|
@ -30,22 +30,21 @@ following ASL code can be used::
|
|||
{
|
||||
Device (STAC)
|
||||
{
|
||||
Name (_ADR, Zero)
|
||||
Name (_HID, "BMA222E")
|
||||
Name (RBUF, ResourceTemplate ()
|
||||
{
|
||||
I2cSerialBus (0x0018, ControllerInitiated, 0x00061A80,
|
||||
AddressingMode7Bit, "\\_SB.I2C6", 0x00,
|
||||
ResourceConsumer, ,)
|
||||
GpioInt (Edge, ActiveHigh, Exclusive, PullDown, 0x0000,
|
||||
"\\_SB.GPO2", 0x00, ResourceConsumer, , )
|
||||
{ // Pin list
|
||||
0
|
||||
}
|
||||
})
|
||||
|
||||
Method (_CRS, 0, Serialized)
|
||||
{
|
||||
Name (RBUF, ResourceTemplate ()
|
||||
{
|
||||
I2cSerialBus (0x0018, ControllerInitiated, 0x00061A80,
|
||||
AddressingMode7Bit, "\\_SB.I2C6", 0x00,
|
||||
ResourceConsumer, ,)
|
||||
GpioInt (Edge, ActiveHigh, Exclusive, PullDown, 0x0000,
|
||||
"\\_SB.GPO2", 0x00, ResourceConsumer, , )
|
||||
{ // Pin list
|
||||
0
|
||||
}
|
||||
})
|
||||
Return (RBUF)
|
||||
}
|
||||
}
|
||||
|
|
@ -75,7 +74,7 @@ This option allows loading of user defined SSDTs from initrd and it is useful
|
|||
when the system does not support EFI or when there is not enough EFI storage.
|
||||
|
||||
It works in a similar way with initrd based ACPI tables override/upgrade: SSDT
|
||||
aml code must be placed in the first, uncompressed, initrd under the
|
||||
AML code must be placed in the first, uncompressed, initrd under the
|
||||
"kernel/firmware/acpi" path. Multiple files can be used and this will translate
|
||||
in loading multiple tables. Only SSDT and OEM tables are allowed. See
|
||||
initrd_table_override.txt for more details.
|
||||
|
|
@ -103,12 +102,14 @@ This is the preferred method, when EFI is supported on the platform, because it
|
|||
allows a persistent, OS independent way of storing the user defined SSDTs. There
|
||||
is also work underway to implement EFI support for loading user defined SSDTs
|
||||
and using this method will make it easier to convert to the EFI loading
|
||||
mechanism when that will arrive.
|
||||
mechanism when that will arrive. To enable it, the
|
||||
CONFIG_EFI_CUSTOM_SSDT_OVERLAYS shoyld be chosen to y.
|
||||
|
||||
In order to load SSDTs from an EFI variable the efivar_ssdt kernel command line
|
||||
parameter can be used. The argument for the option is the variable name to
|
||||
use. If there are multiple variables with the same name but with different
|
||||
vendor GUIDs, all of them will be loaded.
|
||||
In order to load SSDTs from an EFI variable the ``"efivar_ssdt=..."`` kernel
|
||||
command line parameter can be used (the name has a limitation of 16 characters).
|
||||
The argument for the option is the variable name to use. If there are multiple
|
||||
variables with the same name but with different vendor GUIDs, all of them will
|
||||
be loaded.
|
||||
|
||||
In order to store the AML code in an EFI variable the efivarfs filesystem can be
|
||||
used. It is enabled and mounted by default in /sys/firmware/efi/efivars in all
|
||||
|
|
@ -127,7 +128,7 @@ variable with the content from a given file::
|
|||
|
||||
#!/bin/sh -e
|
||||
|
||||
while ! [ -z "$1" ]; do
|
||||
while [ -n "$1" ]; do
|
||||
case "$1" in
|
||||
"-f") filename="$2"; shift;;
|
||||
"-g") guid="$2"; shift;;
|
||||
|
|
@ -167,14 +168,14 @@ variable with the content from a given file::
|
|||
Loading ACPI SSDTs from configfs
|
||||
================================
|
||||
|
||||
This option allows loading of user defined SSDTs from userspace via the configfs
|
||||
This option allows loading of user defined SSDTs from user space via the configfs
|
||||
interface. The CONFIG_ACPI_CONFIGFS option must be select and configfs must be
|
||||
mounted. In the following examples, we assume that configfs has been mounted in
|
||||
/config.
|
||||
/sys/kernel/config.
|
||||
|
||||
New tables can be loading by creating new directories in /config/acpi/table/ and
|
||||
writing the SSDT aml code in the aml attribute::
|
||||
New tables can be loading by creating new directories in /sys/kernel/config/acpi/table
|
||||
and writing the SSDT AML code in the aml attribute::
|
||||
|
||||
cd /config/acpi/table
|
||||
cd /sys/kernel/config/acpi/table
|
||||
mkdir my_ssdt
|
||||
cat ~/ssdt.aml > my_ssdt/aml
|
||||
|
|
|
|||
|
|
@ -178,7 +178,7 @@ update the boot loader and the kernel image itself as long as the boot
|
|||
loader passes the correct initrd file size. If by any chance, the boot
|
||||
loader passes a longer size, the kernel fails to find the bootconfig data.
|
||||
|
||||
To do this operation, Linux kernel provides "bootconfig" command under
|
||||
To do this operation, Linux kernel provides ``bootconfig`` command under
|
||||
tools/bootconfig, which allows admin to apply or delete the config file
|
||||
to/from initrd image. You can build it by the following command::
|
||||
|
||||
|
|
@ -196,6 +196,43 @@ To remove the config from the image, you can use -d option as below::
|
|||
Then add "bootconfig" on the normal kernel command line to tell the
|
||||
kernel to look for the bootconfig at the end of the initrd file.
|
||||
|
||||
|
||||
Kernel parameters via Boot Config
|
||||
=================================
|
||||
|
||||
In addition to the kernel command line, the boot config can be used for
|
||||
passing the kernel parameters. All the key-value pairs under ``kernel``
|
||||
key will be passed to kernel cmdline directly. Moreover, the key-value
|
||||
pairs under ``init`` will be passed to init process via the cmdline.
|
||||
The parameters are concatinated with user-given kernel cmdline string
|
||||
as the following order, so that the command line parameter can override
|
||||
bootconfig parameters (this depends on how the subsystem handles parameters
|
||||
but in general, earlier parameter will be overwritten by later one.)::
|
||||
|
||||
[bootconfig params][cmdline params] -- [bootconfig init params][cmdline init params]
|
||||
|
||||
Here is an example of the bootconfig file for kernel/init parameters.::
|
||||
|
||||
kernel {
|
||||
root = 01234567-89ab-cdef-0123-456789abcd
|
||||
}
|
||||
init {
|
||||
splash
|
||||
}
|
||||
|
||||
This will be copied into the kernel cmdline string as the following::
|
||||
|
||||
root="01234567-89ab-cdef-0123-456789abcd" -- splash
|
||||
|
||||
If user gives some other command line like,::
|
||||
|
||||
ro bootconfig -- quiet
|
||||
|
||||
The final kernel cmdline will be the following::
|
||||
|
||||
root="01234567-89ab-cdef-0123-456789abcd" ro bootconfig -- splash quiet
|
||||
|
||||
|
||||
Config File Limitation
|
||||
======================
|
||||
|
||||
|
|
|
|||
|
|
@ -1762,6 +1762,11 @@
|
|||
support for the idxd driver. By default it is set to
|
||||
true (1).
|
||||
|
||||
idxd.tc_override= [HW]
|
||||
Format: <bool>
|
||||
Allow override of default traffic class configuration
|
||||
for the device. By default it is set to false (0).
|
||||
|
||||
ieee754= [MIPS] Select IEEE Std 754 conformance mode
|
||||
Format: { strict | legacy | 2008 | relaxed }
|
||||
Default: strict
|
||||
|
|
|
|||
|
|
@ -140,6 +140,7 @@ EBU Armada family
|
|||
- 88F6821 Armada 382
|
||||
- 88F6W21 Armada 383
|
||||
- 88F6820 Armada 385
|
||||
- 88F6825
|
||||
- 88F6828 Armada 388
|
||||
|
||||
- Product infos: https://web.archive.org/web/20181006144616/http://www.marvell.com/embedded-processors/armada-38x/
|
||||
|
|
|
|||
|
|
@ -54,7 +54,7 @@ layer or if we want to try to merge requests. In both cases, requests will be
|
|||
sent to the software queue.
|
||||
|
||||
Then, after the requests are processed by software queues, they will be placed
|
||||
at the hardware queue, a second stage queue were the hardware has direct access
|
||||
at the hardware queue, a second stage queue where the hardware has direct access
|
||||
to process those requests. However, if the hardware does not have enough
|
||||
resources to accept more requests, blk-mq will places requests on a temporary
|
||||
queue, to be sent in the future, when the hardware is able.
|
||||
|
|
|
|||
|
|
@ -463,8 +463,8 @@ latex_elements['preamble'] += '''
|
|||
\\newcommand{\\kerneldocEndTC}{}
|
||||
\\newcommand{\\kerneldocBeginKR}{}
|
||||
\\newcommand{\\kerneldocEndKR}{}
|
||||
\\newcommand{\\kerneldocBeginSC}{}
|
||||
\\newcommand{\\kerneldocEndKR}{}
|
||||
\\newcommand{\\kerneldocBeginJP}{}
|
||||
\\newcommand{\\kerneldocEndJP}{}
|
||||
}
|
||||
'''
|
||||
|
||||
|
|
|
|||
|
|
@ -2,12 +2,13 @@
|
|||
CPU hotplug in the Kernel
|
||||
=========================
|
||||
|
||||
:Date: December, 2016
|
||||
:Date: September, 2021
|
||||
:Author: Sebastian Andrzej Siewior <bigeasy@linutronix.de>,
|
||||
Rusty Russell <rusty@rustcorp.com.au>,
|
||||
Srivatsa Vaddagiri <vatsa@in.ibm.com>,
|
||||
Ashok Raj <ashok.raj@intel.com>,
|
||||
Joel Schopp <jschopp@austin.ibm.com>
|
||||
Rusty Russell <rusty@rustcorp.com.au>,
|
||||
Srivatsa Vaddagiri <vatsa@in.ibm.com>,
|
||||
Ashok Raj <ashok.raj@intel.com>,
|
||||
Joel Schopp <jschopp@austin.ibm.com>,
|
||||
Thomas Gleixner <tglx@linutronix.de>
|
||||
|
||||
Introduction
|
||||
============
|
||||
|
|
@ -158,100 +159,480 @@ at state ``CPUHP_OFFLINE``. This includes:
|
|||
* Once all services are migrated, kernel calls an arch specific routine
|
||||
``__cpu_disable()`` to perform arch specific cleanup.
|
||||
|
||||
Using the hotplug API
|
||||
---------------------
|
||||
|
||||
It is possible to receive notifications once a CPU is offline or onlined. This
|
||||
might be important to certain drivers which need to perform some kind of setup
|
||||
or clean up functions based on the number of available CPUs::
|
||||
The CPU hotplug API
|
||||
===================
|
||||
|
||||
#include <linux/cpuhotplug.h>
|
||||
CPU hotplug state machine
|
||||
-------------------------
|
||||
|
||||
ret = cpuhp_setup_state(CPUHP_AP_ONLINE_DYN, "X/Y:online",
|
||||
Y_online, Y_prepare_down);
|
||||
CPU hotplug uses a trivial state machine with a linear state space from
|
||||
CPUHP_OFFLINE to CPUHP_ONLINE. Each state has a startup and a teardown
|
||||
callback.
|
||||
|
||||
*X* is the subsystem and *Y* the particular driver. The *Y_online* callback
|
||||
will be invoked during registration on all online CPUs. If an error
|
||||
occurs during the online callback the *Y_prepare_down* callback will be
|
||||
invoked on all CPUs on which the online callback was previously invoked.
|
||||
After registration completed, the *Y_online* callback will be invoked
|
||||
once a CPU is brought online and *Y_prepare_down* will be invoked when a
|
||||
CPU is shutdown. All resources which were previously allocated in
|
||||
*Y_online* should be released in *Y_prepare_down*.
|
||||
The return value *ret* is negative if an error occurred during the
|
||||
registration process. Otherwise a positive value is returned which
|
||||
contains the allocated hotplug for dynamically allocated states
|
||||
(*CPUHP_AP_ONLINE_DYN*). It will return zero for predefined states.
|
||||
When a CPU is onlined, the startup callbacks are invoked sequentially until
|
||||
the state CPUHP_ONLINE is reached. They can also be invoked when the
|
||||
callbacks of a state are set up or an instance is added to a multi-instance
|
||||
state.
|
||||
|
||||
The callback can be remove by invoking ``cpuhp_remove_state()``. In case of a
|
||||
dynamically allocated state (*CPUHP_AP_ONLINE_DYN*) use the returned state.
|
||||
During the removal of a hotplug state the teardown callback will be invoked.
|
||||
When a CPU is offlined the teardown callbacks are invoked in the reverse
|
||||
order sequentially until the state CPUHP_OFFLINE is reached. They can also
|
||||
be invoked when the callbacks of a state are removed or an instance is
|
||||
removed from a multi-instance state.
|
||||
|
||||
Multiple instances
|
||||
~~~~~~~~~~~~~~~~~~
|
||||
If a usage site requires only a callback in one direction of the hotplug
|
||||
operations (CPU online or CPU offline) then the other not-required callback
|
||||
can be set to NULL when the state is set up.
|
||||
|
||||
If a driver has multiple instances and each instance needs to perform the
|
||||
callback independently then it is likely that a ''multi-state'' should be used.
|
||||
First a multi-state state needs to be registered::
|
||||
The state space is divided into three sections:
|
||||
|
||||
ret = cpuhp_setup_state_multi(CPUHP_AP_ONLINE_DYN, "X/Y:online,
|
||||
Y_online, Y_prepare_down);
|
||||
Y_hp_online = ret;
|
||||
* The PREPARE section
|
||||
|
||||
The ``cpuhp_setup_state_multi()`` behaves similar to ``cpuhp_setup_state()``
|
||||
except it prepares the callbacks for a multi state and does not invoke
|
||||
the callbacks. This is a one time setup.
|
||||
Once a new instance is allocated, you need to register this new instance::
|
||||
The PREPARE section covers the state space from CPUHP_OFFLINE to
|
||||
CPUHP_BRINGUP_CPU.
|
||||
|
||||
ret = cpuhp_state_add_instance(Y_hp_online, &d->node);
|
||||
The startup callbacks in this section are invoked before the CPU is
|
||||
started during a CPU online operation. The teardown callbacks are invoked
|
||||
after the CPU has become dysfunctional during a CPU offline operation.
|
||||
|
||||
This function will add this instance to your previously allocated
|
||||
*Y_hp_online* state and invoke the previously registered callback
|
||||
(*Y_online*) on all online CPUs. The *node* element is a ``struct
|
||||
hlist_node`` member of your per-instance data structure.
|
||||
The callbacks are invoked on a control CPU as they can't obviously run on
|
||||
the hotplugged CPU which is either not yet started or has become
|
||||
dysfunctional already.
|
||||
|
||||
On removal of the instance::
|
||||
The startup callbacks are used to setup resources which are required to
|
||||
bring a CPU successfully online. The teardown callbacks are used to free
|
||||
resources or to move pending work to an online CPU after the hotplugged
|
||||
CPU became dysfunctional.
|
||||
|
||||
cpuhp_state_remove_instance(Y_hp_online, &d->node)
|
||||
The startup callbacks are allowed to fail. If a callback fails, the CPU
|
||||
online operation is aborted and the CPU is brought down to the previous
|
||||
state (usually CPUHP_OFFLINE) again.
|
||||
|
||||
should be invoked which will invoke the teardown callback on all online
|
||||
CPUs.
|
||||
The teardown callbacks in this section are not allowed to fail.
|
||||
|
||||
Manual setup
|
||||
~~~~~~~~~~~~
|
||||
* The STARTING section
|
||||
|
||||
Usually it is handy to invoke setup and teardown callbacks on registration or
|
||||
removal of a state because usually the operation needs to performed once a CPU
|
||||
goes online (offline) and during initial setup (shutdown) of the driver. However
|
||||
each registration and removal function is also available with a ``_nocalls``
|
||||
suffix which does not invoke the provided callbacks if the invocation of the
|
||||
callbacks is not desired. During the manual setup (or teardown) the functions
|
||||
``cpus_read_lock()`` and ``cpus_read_unlock()`` should be used to inhibit CPU
|
||||
hotplug operations.
|
||||
The STARTING section covers the state space between CPUHP_BRINGUP_CPU + 1
|
||||
and CPUHP_AP_ONLINE.
|
||||
|
||||
The startup callbacks in this section are invoked on the hotplugged CPU
|
||||
with interrupts disabled during a CPU online operation in the early CPU
|
||||
setup code. The teardown callbacks are invoked with interrupts disabled
|
||||
on the hotplugged CPU during a CPU offline operation shortly before the
|
||||
CPU is completely shut down.
|
||||
|
||||
The ordering of the events
|
||||
--------------------------
|
||||
The callbacks in this section are not allowed to fail.
|
||||
|
||||
The hotplug states are defined in ``include/linux/cpuhotplug.h``:
|
||||
The callbacks are used for low level hardware initialization/shutdown and
|
||||
for core subsystems.
|
||||
|
||||
* The states *CPUHP_OFFLINE* … *CPUHP_AP_OFFLINE* are invoked before the
|
||||
CPU is up.
|
||||
* The states *CPUHP_AP_OFFLINE* … *CPUHP_AP_ONLINE* are invoked
|
||||
just the after the CPU has been brought up. The interrupts are off and
|
||||
the scheduler is not yet active on this CPU. Starting with *CPUHP_AP_OFFLINE*
|
||||
the callbacks are invoked on the target CPU.
|
||||
* The states between *CPUHP_AP_ONLINE_DYN* and *CPUHP_AP_ONLINE_DYN_END* are
|
||||
reserved for the dynamic allocation.
|
||||
* The states are invoked in the reverse order on CPU shutdown starting with
|
||||
*CPUHP_ONLINE* and stopping at *CPUHP_OFFLINE*. Here the callbacks are
|
||||
invoked on the CPU that will be shutdown until *CPUHP_AP_OFFLINE*.
|
||||
* The ONLINE section
|
||||
|
||||
The ONLINE section covers the state space between CPUHP_AP_ONLINE + 1 and
|
||||
CPUHP_ONLINE.
|
||||
|
||||
The startup callbacks in this section are invoked on the hotplugged CPU
|
||||
during a CPU online operation. The teardown callbacks are invoked on the
|
||||
hotplugged CPU during a CPU offline operation.
|
||||
|
||||
The callbacks are invoked in the context of the per CPU hotplug thread,
|
||||
which is pinned on the hotplugged CPU. The callbacks are invoked with
|
||||
interrupts and preemption enabled.
|
||||
|
||||
The callbacks are allowed to fail. When a callback fails the hotplug
|
||||
operation is aborted and the CPU is brought back to the previous state.
|
||||
|
||||
CPU online/offline operations
|
||||
-----------------------------
|
||||
|
||||
A successful online operation looks like this::
|
||||
|
||||
[CPUHP_OFFLINE]
|
||||
[CPUHP_OFFLINE + 1]->startup() -> success
|
||||
[CPUHP_OFFLINE + 2]->startup() -> success
|
||||
[CPUHP_OFFLINE + 3] -> skipped because startup == NULL
|
||||
...
|
||||
[CPUHP_BRINGUP_CPU]->startup() -> success
|
||||
=== End of PREPARE section
|
||||
[CPUHP_BRINGUP_CPU + 1]->startup() -> success
|
||||
...
|
||||
[CPUHP_AP_ONLINE]->startup() -> success
|
||||
=== End of STARTUP section
|
||||
[CPUHP_AP_ONLINE + 1]->startup() -> success
|
||||
...
|
||||
[CPUHP_ONLINE - 1]->startup() -> success
|
||||
[CPUHP_ONLINE]
|
||||
|
||||
A successful offline operation looks like this::
|
||||
|
||||
[CPUHP_ONLINE]
|
||||
[CPUHP_ONLINE - 1]->teardown() -> success
|
||||
...
|
||||
[CPUHP_AP_ONLINE + 1]->teardown() -> success
|
||||
=== Start of STARTUP section
|
||||
[CPUHP_AP_ONLINE]->teardown() -> success
|
||||
...
|
||||
[CPUHP_BRINGUP_ONLINE - 1]->teardown()
|
||||
...
|
||||
=== Start of PREPARE section
|
||||
[CPUHP_BRINGUP_CPU]->teardown()
|
||||
[CPUHP_OFFLINE + 3]->teardown()
|
||||
[CPUHP_OFFLINE + 2] -> skipped because teardown == NULL
|
||||
[CPUHP_OFFLINE + 1]->teardown()
|
||||
[CPUHP_OFFLINE]
|
||||
|
||||
A failed online operation looks like this::
|
||||
|
||||
[CPUHP_OFFLINE]
|
||||
[CPUHP_OFFLINE + 1]->startup() -> success
|
||||
[CPUHP_OFFLINE + 2]->startup() -> success
|
||||
[CPUHP_OFFLINE + 3] -> skipped because startup == NULL
|
||||
...
|
||||
[CPUHP_BRINGUP_CPU]->startup() -> success
|
||||
=== End of PREPARE section
|
||||
[CPUHP_BRINGUP_CPU + 1]->startup() -> success
|
||||
...
|
||||
[CPUHP_AP_ONLINE]->startup() -> success
|
||||
=== End of STARTUP section
|
||||
[CPUHP_AP_ONLINE + 1]->startup() -> success
|
||||
---
|
||||
[CPUHP_AP_ONLINE + N]->startup() -> fail
|
||||
[CPUHP_AP_ONLINE + (N - 1)]->teardown()
|
||||
...
|
||||
[CPUHP_AP_ONLINE + 1]->teardown()
|
||||
=== Start of STARTUP section
|
||||
[CPUHP_AP_ONLINE]->teardown()
|
||||
...
|
||||
[CPUHP_BRINGUP_ONLINE - 1]->teardown()
|
||||
...
|
||||
=== Start of PREPARE section
|
||||
[CPUHP_BRINGUP_CPU]->teardown()
|
||||
[CPUHP_OFFLINE + 3]->teardown()
|
||||
[CPUHP_OFFLINE + 2] -> skipped because teardown == NULL
|
||||
[CPUHP_OFFLINE + 1]->teardown()
|
||||
[CPUHP_OFFLINE]
|
||||
|
||||
A failed offline operation looks like this::
|
||||
|
||||
[CPUHP_ONLINE]
|
||||
[CPUHP_ONLINE - 1]->teardown() -> success
|
||||
...
|
||||
[CPUHP_ONLINE - N]->teardown() -> fail
|
||||
[CPUHP_ONLINE - (N - 1)]->startup()
|
||||
...
|
||||
[CPUHP_ONLINE - 1]->startup()
|
||||
[CPUHP_ONLINE]
|
||||
|
||||
Recursive failures cannot be handled sensibly. Look at the following
|
||||
example of a recursive fail due to a failed offline operation: ::
|
||||
|
||||
[CPUHP_ONLINE]
|
||||
[CPUHP_ONLINE - 1]->teardown() -> success
|
||||
...
|
||||
[CPUHP_ONLINE - N]->teardown() -> fail
|
||||
[CPUHP_ONLINE - (N - 1)]->startup() -> success
|
||||
[CPUHP_ONLINE - (N - 2)]->startup() -> fail
|
||||
|
||||
The CPU hotplug state machine stops right here and does not try to go back
|
||||
down again because that would likely result in an endless loop::
|
||||
|
||||
[CPUHP_ONLINE - (N - 1)]->teardown() -> success
|
||||
[CPUHP_ONLINE - N]->teardown() -> fail
|
||||
[CPUHP_ONLINE - (N - 1)]->startup() -> success
|
||||
[CPUHP_ONLINE - (N - 2)]->startup() -> fail
|
||||
[CPUHP_ONLINE - (N - 1)]->teardown() -> success
|
||||
[CPUHP_ONLINE - N]->teardown() -> fail
|
||||
|
||||
Lather, rinse and repeat. In this case the CPU left in state::
|
||||
|
||||
[CPUHP_ONLINE - (N - 1)]
|
||||
|
||||
which at least lets the system make progress and gives the user a chance to
|
||||
debug or even resolve the situation.
|
||||
|
||||
Allocating a state
|
||||
------------------
|
||||
|
||||
There are two ways to allocate a CPU hotplug state:
|
||||
|
||||
* Static allocation
|
||||
|
||||
Static allocation has to be used when the subsystem or driver has
|
||||
ordering requirements versus other CPU hotplug states. E.g. the PERF core
|
||||
startup callback has to be invoked before the PERF driver startup
|
||||
callbacks during a CPU online operation. During a CPU offline operation
|
||||
the driver teardown callbacks have to be invoked before the core teardown
|
||||
callback. The statically allocated states are described by constants in
|
||||
the cpuhp_state enum which can be found in include/linux/cpuhotplug.h.
|
||||
|
||||
Insert the state into the enum at the proper place so the ordering
|
||||
requirements are fulfilled. The state constant has to be used for state
|
||||
setup and removal.
|
||||
|
||||
Static allocation is also required when the state callbacks are not set
|
||||
up at runtime and are part of the initializer of the CPU hotplug state
|
||||
array in kernel/cpu.c.
|
||||
|
||||
* Dynamic allocation
|
||||
|
||||
When there are no ordering requirements for the state callbacks then
|
||||
dynamic allocation is the preferred method. The state number is allocated
|
||||
by the setup function and returned to the caller on success.
|
||||
|
||||
Only the PREPARE and ONLINE sections provide a dynamic allocation
|
||||
range. The STARTING section does not as most of the callbacks in that
|
||||
section have explicit ordering requirements.
|
||||
|
||||
Setup of a CPU hotplug state
|
||||
----------------------------
|
||||
|
||||
The core code provides the following functions to setup a state:
|
||||
|
||||
* cpuhp_setup_state(state, name, startup, teardown)
|
||||
* cpuhp_setup_state_nocalls(state, name, startup, teardown)
|
||||
* cpuhp_setup_state_cpuslocked(state, name, startup, teardown)
|
||||
* cpuhp_setup_state_nocalls_cpuslocked(state, name, startup, teardown)
|
||||
|
||||
For cases where a driver or a subsystem has multiple instances and the same
|
||||
CPU hotplug state callbacks need to be invoked for each instance, the CPU
|
||||
hotplug core provides multi-instance support. The advantage over driver
|
||||
specific instance lists is that the instance related functions are fully
|
||||
serialized against CPU hotplug operations and provide the automatic
|
||||
invocations of the state callbacks on add and removal. To set up such a
|
||||
multi-instance state the following function is available:
|
||||
|
||||
* cpuhp_setup_state_multi(state, name, startup, teardown)
|
||||
|
||||
The @state argument is either a statically allocated state or one of the
|
||||
constants for dynamically allocated states - CPUHP_PREPARE_DYN,
|
||||
CPUHP_ONLINE_DYN - depending on the state section (PREPARE, ONLINE) for
|
||||
which a dynamic state should be allocated.
|
||||
|
||||
The @name argument is used for sysfs output and for instrumentation. The
|
||||
naming convention is "subsys:mode" or "subsys/driver:mode",
|
||||
e.g. "perf:mode" or "perf/x86:mode". The common mode names are:
|
||||
|
||||
======== =======================================================
|
||||
prepare For states in the PREPARE section
|
||||
|
||||
dead For states in the PREPARE section which do not provide
|
||||
a startup callback
|
||||
|
||||
starting For states in the STARTING section
|
||||
|
||||
dying For states in the STARTING section which do not provide
|
||||
a startup callback
|
||||
|
||||
online For states in the ONLINE section
|
||||
|
||||
offline For states in the ONLINE section which do not provide
|
||||
a startup callback
|
||||
======== =======================================================
|
||||
|
||||
As the @name argument is only used for sysfs and instrumentation other mode
|
||||
descriptors can be used as well if they describe the nature of the state
|
||||
better than the common ones.
|
||||
|
||||
Examples for @name arguments: "perf/online", "perf/x86:prepare",
|
||||
"RCU/tree:dying", "sched/waitempty"
|
||||
|
||||
The @startup argument is a function pointer to the callback which should be
|
||||
invoked during a CPU online operation. If the usage site does not require a
|
||||
startup callback set the pointer to NULL.
|
||||
|
||||
The @teardown argument is a function pointer to the callback which should
|
||||
be invoked during a CPU offline operation. If the usage site does not
|
||||
require a teardown callback set the pointer to NULL.
|
||||
|
||||
The functions differ in the way how the installed callbacks are treated:
|
||||
|
||||
* cpuhp_setup_state_nocalls(), cpuhp_setup_state_nocalls_cpuslocked()
|
||||
and cpuhp_setup_state_multi() only install the callbacks
|
||||
|
||||
* cpuhp_setup_state() and cpuhp_setup_state_cpuslocked() install the
|
||||
callbacks and invoke the @startup callback (if not NULL) for all online
|
||||
CPUs which have currently a state greater than the newly installed
|
||||
state. Depending on the state section the callback is either invoked on
|
||||
the current CPU (PREPARE section) or on each online CPU (ONLINE
|
||||
section) in the context of the CPU's hotplug thread.
|
||||
|
||||
If a callback fails for CPU N then the teardown callback for CPU
|
||||
0 .. N-1 is invoked to rollback the operation. The state setup fails,
|
||||
the callbacks for the state are not installed and in case of dynamic
|
||||
allocation the allocated state is freed.
|
||||
|
||||
The state setup and the callback invocations are serialized against CPU
|
||||
hotplug operations. If the setup function has to be called from a CPU
|
||||
hotplug read locked region, then the _cpuslocked() variants have to be
|
||||
used. These functions cannot be used from within CPU hotplug callbacks.
|
||||
|
||||
The function return values:
|
||||
======== ===================================================================
|
||||
0 Statically allocated state was successfully set up
|
||||
|
||||
>0 Dynamically allocated state was successfully set up.
|
||||
|
||||
The returned number is the state number which was allocated. If
|
||||
the state callbacks have to be removed later, e.g. module
|
||||
removal, then this number has to be saved by the caller and used
|
||||
as @state argument for the state remove function. For
|
||||
multi-instance states the dynamically allocated state number is
|
||||
also required as @state argument for the instance add/remove
|
||||
operations.
|
||||
|
||||
<0 Operation failed
|
||||
======== ===================================================================
|
||||
|
||||
Removal of a CPU hotplug state
|
||||
------------------------------
|
||||
|
||||
To remove a previously set up state, the following functions are provided:
|
||||
|
||||
* cpuhp_remove_state(state)
|
||||
* cpuhp_remove_state_nocalls(state)
|
||||
* cpuhp_remove_state_nocalls_cpuslocked(state)
|
||||
* cpuhp_remove_multi_state(state)
|
||||
|
||||
The @state argument is either a statically allocated state or the state
|
||||
number which was allocated in the dynamic range by cpuhp_setup_state*(). If
|
||||
the state is in the dynamic range, then the state number is freed and
|
||||
available for dynamic allocation again.
|
||||
|
||||
The functions differ in the way how the installed callbacks are treated:
|
||||
|
||||
* cpuhp_remove_state_nocalls(), cpuhp_remove_state_nocalls_cpuslocked()
|
||||
and cpuhp_remove_multi_state() only remove the callbacks.
|
||||
|
||||
* cpuhp_remove_state() removes the callbacks and invokes the teardown
|
||||
callback (if not NULL) for all online CPUs which have currently a state
|
||||
greater than the removed state. Depending on the state section the
|
||||
callback is either invoked on the current CPU (PREPARE section) or on
|
||||
each online CPU (ONLINE section) in the context of the CPU's hotplug
|
||||
thread.
|
||||
|
||||
In order to complete the removal, the teardown callback should not fail.
|
||||
|
||||
The state removal and the callback invocations are serialized against CPU
|
||||
hotplug operations. If the remove function has to be called from a CPU
|
||||
hotplug read locked region, then the _cpuslocked() variants have to be
|
||||
used. These functions cannot be used from within CPU hotplug callbacks.
|
||||
|
||||
If a multi-instance state is removed then the caller has to remove all
|
||||
instances first.
|
||||
|
||||
Multi-Instance state instance management
|
||||
----------------------------------------
|
||||
|
||||
Once the multi-instance state is set up, instances can be added to the
|
||||
state:
|
||||
|
||||
* cpuhp_state_add_instance(state, node)
|
||||
* cpuhp_state_add_instance_nocalls(state, node)
|
||||
|
||||
The @state argument is either a statically allocated state or the state
|
||||
number which was allocated in the dynamic range by cpuhp_setup_state_multi().
|
||||
|
||||
The @node argument is a pointer to an hlist_node which is embedded in the
|
||||
instance's data structure. The pointer is handed to the multi-instance
|
||||
state callbacks and can be used by the callback to retrieve the instance
|
||||
via container_of().
|
||||
|
||||
The functions differ in the way how the installed callbacks are treated:
|
||||
|
||||
* cpuhp_state_add_instance_nocalls() and only adds the instance to the
|
||||
multi-instance state's node list.
|
||||
|
||||
* cpuhp_state_add_instance() adds the instance and invokes the startup
|
||||
callback (if not NULL) associated with @state for all online CPUs which
|
||||
have currently a state greater than @state. The callback is only
|
||||
invoked for the to be added instance. Depending on the state section
|
||||
the callback is either invoked on the current CPU (PREPARE section) or
|
||||
on each online CPU (ONLINE section) in the context of the CPU's hotplug
|
||||
thread.
|
||||
|
||||
If a callback fails for CPU N then the teardown callback for CPU
|
||||
0 .. N-1 is invoked to rollback the operation, the function fails and
|
||||
the instance is not added to the node list of the multi-instance state.
|
||||
|
||||
To remove an instance from the state's node list these functions are
|
||||
available:
|
||||
|
||||
* cpuhp_state_remove_instance(state, node)
|
||||
* cpuhp_state_remove_instance_nocalls(state, node)
|
||||
|
||||
The arguments are the same as for the the cpuhp_state_add_instance*()
|
||||
variants above.
|
||||
|
||||
The functions differ in the way how the installed callbacks are treated:
|
||||
|
||||
* cpuhp_state_remove_instance_nocalls() only removes the instance from the
|
||||
state's node list.
|
||||
|
||||
* cpuhp_state_remove_instance() removes the instance and invokes the
|
||||
teardown callback (if not NULL) associated with @state for all online
|
||||
CPUs which have currently a state greater than @state. The callback is
|
||||
only invoked for the to be removed instance. Depending on the state
|
||||
section the callback is either invoked on the current CPU (PREPARE
|
||||
section) or on each online CPU (ONLINE section) in the context of the
|
||||
CPU's hotplug thread.
|
||||
|
||||
In order to complete the removal, the teardown callback should not fail.
|
||||
|
||||
The node list add/remove operations and the callback invocations are
|
||||
serialized against CPU hotplug operations. These functions cannot be used
|
||||
from within CPU hotplug callbacks and CPU hotplug read locked regions.
|
||||
|
||||
Examples
|
||||
--------
|
||||
|
||||
Setup and teardown a statically allocated state in the STARTING section for
|
||||
notifications on online and offline operations::
|
||||
|
||||
ret = cpuhp_setup_state(CPUHP_SUBSYS_STARTING, "subsys:starting", subsys_cpu_starting, subsys_cpu_dying);
|
||||
if (ret < 0)
|
||||
return ret;
|
||||
....
|
||||
cpuhp_remove_state(CPUHP_SUBSYS_STARTING);
|
||||
|
||||
Setup and teardown a dynamically allocated state in the ONLINE section
|
||||
for notifications on offline operations::
|
||||
|
||||
state = cpuhp_setup_state(CPUHP_ONLINE_DYN, "subsys:offline", NULL, subsys_cpu_offline);
|
||||
if (state < 0)
|
||||
return state;
|
||||
....
|
||||
cpuhp_remove_state(state);
|
||||
|
||||
Setup and teardown a dynamically allocated state in the ONLINE section
|
||||
for notifications on online operations without invoking the callbacks::
|
||||
|
||||
state = cpuhp_setup_state_nocalls(CPUHP_ONLINE_DYN, "subsys:online", subsys_cpu_online, NULL);
|
||||
if (state < 0)
|
||||
return state;
|
||||
....
|
||||
cpuhp_remove_state_nocalls(state);
|
||||
|
||||
Setup, use and teardown a dynamically allocated multi-instance state in the
|
||||
ONLINE section for notifications on online and offline operation::
|
||||
|
||||
state = cpuhp_setup_state_multi(CPUHP_ONLINE_DYN, "subsys:online", subsys_cpu_online, subsys_cpu_offline);
|
||||
if (state < 0)
|
||||
return state;
|
||||
....
|
||||
ret = cpuhp_state_add_instance(state, &inst1->node);
|
||||
if (ret)
|
||||
return ret;
|
||||
....
|
||||
ret = cpuhp_state_add_instance(state, &inst2->node);
|
||||
if (ret)
|
||||
return ret;
|
||||
....
|
||||
cpuhp_remove_instance(state, &inst1->node);
|
||||
....
|
||||
cpuhp_remove_instance(state, &inst2->node);
|
||||
....
|
||||
remove_multi_state(state);
|
||||
|
||||
A dynamically allocated state via *CPUHP_AP_ONLINE_DYN* is often enough.
|
||||
However if an earlier invocation during the bring up or shutdown is required
|
||||
then an explicit state should be acquired. An explicit state might also be
|
||||
required if the hotplug event requires specific ordering in respect to
|
||||
another hotplug event.
|
||||
|
||||
Testing of hotplug states
|
||||
=========================
|
||||
|
|
|
|||
|
|
@ -315,6 +315,9 @@ Block Devices
|
|||
.. kernel-doc:: block/genhd.c
|
||||
:export:
|
||||
|
||||
.. kernel-doc:: block/bdev.c
|
||||
:export:
|
||||
|
||||
Char devices
|
||||
============
|
||||
|
||||
|
|
|
|||
|
|
@ -75,9 +75,6 @@ And optionally
|
|||
.resume - A pointer to a per-policy resume function which is called
|
||||
with interrupts disabled and _before_ the governor is started again.
|
||||
|
||||
.ready - A pointer to a per-policy ready function which is called after
|
||||
the policy is fully initialized.
|
||||
|
||||
.attr - A pointer to a NULL-terminated list of "struct freq_attr" which
|
||||
allow to export values to sysfs.
|
||||
|
||||
|
|
|
|||
|
|
@ -12,7 +12,10 @@ maintainers:
|
|||
description:
|
||||
The Hitachi HD44780 Character LCD Controller is commonly used on character
|
||||
LCDs that can display one or more lines of text. It exposes an M6800 bus
|
||||
interface, which can be used in either 4-bit or 8-bit mode.
|
||||
interface, which can be used in either 4-bit or 8-bit mode. By using a
|
||||
GPIO expander it is possible to use the driver with one of the popular I2C
|
||||
expander boards based on the PCF8574 available for these displays. For
|
||||
an example see below.
|
||||
|
||||
properties:
|
||||
compatible:
|
||||
|
|
@ -94,3 +97,29 @@ examples:
|
|||
display-height-chars = <2>;
|
||||
display-width-chars = <16>;
|
||||
};
|
||||
- |
|
||||
#include <dt-bindings/gpio/gpio.h>
|
||||
i2c {
|
||||
#address-cells = <1>;
|
||||
#size-cells = <0>;
|
||||
|
||||
pcf8574: pcf8574@27 {
|
||||
compatible = "nxp,pcf8574";
|
||||
reg = <0x27>;
|
||||
gpio-controller;
|
||||
#gpio-cells = <2>;
|
||||
};
|
||||
};
|
||||
hd44780 {
|
||||
compatible = "hit,hd44780";
|
||||
display-height-chars = <2>;
|
||||
display-width-chars = <16>;
|
||||
data-gpios = <&pcf8574 4 0>,
|
||||
<&pcf8574 5 0>,
|
||||
<&pcf8574 6 0>,
|
||||
<&pcf8574 7 0>;
|
||||
enable-gpios = <&pcf8574 2 0>;
|
||||
rs-gpios = <&pcf8574 0 0>;
|
||||
rw-gpios = <&pcf8574 1 0>;
|
||||
backlight-gpios = <&pcf8574 3 0>;
|
||||
};
|
||||
|
|
|
|||
|
|
@ -11,7 +11,7 @@ Required properties:
|
|||
- None
|
||||
|
||||
Optional properties:
|
||||
- operating-points: Refer to Documentation/devicetree/bindings/opp/opp.txt for
|
||||
- operating-points: Refer to Documentation/devicetree/bindings/opp/opp-v1.yaml for
|
||||
details. OPPs *must* be supplied either via DT, i.e. this property, or
|
||||
populated at runtime.
|
||||
- clock-latency: Specify the possible maximum transition latency for clock,
|
||||
|
|
|
|||
|
|
@ -0,0 +1,70 @@
|
|||
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
|
||||
%YAML 1.2
|
||||
---
|
||||
$id: http://devicetree.org/schemas/cpufreq/cpufreq-mediatek-hw.yaml#
|
||||
$schema: http://devicetree.org/meta-schemas/core.yaml#
|
||||
|
||||
title: MediaTek's CPUFREQ Bindings
|
||||
|
||||
maintainers:
|
||||
- Hector Yuan <hector.yuan@mediatek.com>
|
||||
|
||||
description:
|
||||
CPUFREQ HW is a hardware engine used by MediaTek SoCs to
|
||||
manage frequency in hardware. It is capable of controlling
|
||||
frequency for multiple clusters.
|
||||
|
||||
properties:
|
||||
compatible:
|
||||
const: mediatek,cpufreq-hw
|
||||
|
||||
reg:
|
||||
minItems: 1
|
||||
maxItems: 2
|
||||
description:
|
||||
Addresses and sizes for the memory of the HW bases in
|
||||
each frequency domain. Each entry corresponds to
|
||||
a register bank for each frequency domain present.
|
||||
|
||||
"#performance-domain-cells":
|
||||
description:
|
||||
Number of cells in a performance domain specifier.
|
||||
Set const to 1 here for nodes providing multiple
|
||||
performance domains.
|
||||
const: 1
|
||||
|
||||
required:
|
||||
- compatible
|
||||
- reg
|
||||
- "#performance-domain-cells"
|
||||
|
||||
additionalProperties: false
|
||||
|
||||
examples:
|
||||
- |
|
||||
cpus {
|
||||
#address-cells = <1>;
|
||||
#size-cells = <0>;
|
||||
|
||||
cpu0: cpu@0 {
|
||||
device_type = "cpu";
|
||||
compatible = "arm,cortex-a55";
|
||||
enable-method = "psci";
|
||||
performance-domains = <&performance 0>;
|
||||
reg = <0x000>;
|
||||
};
|
||||
};
|
||||
|
||||
/* ... */
|
||||
|
||||
soc {
|
||||
#address-cells = <2>;
|
||||
#size-cells = <2>;
|
||||
|
||||
performance: performance-controller@11bc00 {
|
||||
compatible = "mediatek,cpufreq-hw";
|
||||
reg = <0 0x0011bc10 0 0x120>, <0 0x0011bd30 0 0x120>;
|
||||
|
||||
#performance-domain-cells = <1>;
|
||||
};
|
||||
};
|
||||
|
|
@ -10,7 +10,7 @@ Required properties:
|
|||
transition and not stable yet.
|
||||
Please refer to Documentation/devicetree/bindings/clock/clock-bindings.txt for
|
||||
generic clock consumer properties.
|
||||
- operating-points-v2: Please refer to Documentation/devicetree/bindings/opp/opp.txt
|
||||
- operating-points-v2: Please refer to Documentation/devicetree/bindings/opp/opp-v2.yaml
|
||||
for detail.
|
||||
- proc-supply: Regulator for Vproc of CPU cluster.
|
||||
|
||||
|
|
|
|||
|
|
@ -6,8 +6,6 @@ from the SoC, then supplies the OPP framework with 'prop' and 'supported
|
|||
hardware' information respectively. The framework is then able to read
|
||||
the DT and operate in the usual way.
|
||||
|
||||
For more information about the expected DT format [See: ../opp/opp.txt].
|
||||
|
||||
Frequency Scaling only
|
||||
----------------------
|
||||
|
||||
|
|
@ -15,7 +13,7 @@ No vendor specific driver required for this.
|
|||
|
||||
Located in CPU's node:
|
||||
|
||||
- operating-points : [See: ../power/opp.txt]
|
||||
- operating-points : [See: ../power/opp-v1.yaml]
|
||||
|
||||
Example [safe]
|
||||
--------------
|
||||
|
|
@ -37,7 +35,7 @@ This requires the ST CPUFreq driver to supply 'process' and 'version' info.
|
|||
|
||||
Located in CPU's node:
|
||||
|
||||
- operating-points-v2 : [See ../power/opp.txt]
|
||||
- operating-points-v2 : [See ../power/opp-v2.yaml]
|
||||
|
||||
Example [unsafe]
|
||||
----------------
|
||||
|
|
|
|||
|
|
@ -4,7 +4,7 @@ Binding for NVIDIA Tegra20 CPUFreq
|
|||
Required properties:
|
||||
- clocks: Must contain an entry for the CPU clock.
|
||||
See ../clocks/clock-bindings.txt for details.
|
||||
- operating-points-v2: See ../bindings/opp/opp.txt for details.
|
||||
- operating-points-v2: See ../bindings/opp/opp-v2.yaml for details.
|
||||
- #cooling-cells: Should be 2. See ../thermal/thermal-cooling-devices.yaml for details.
|
||||
|
||||
For each opp entry in 'operating-points-v2' table:
|
||||
|
|
|
|||
|
|
@ -8,7 +8,7 @@ Required properties:
|
|||
- clocks: Phandles for clock specified in "clock-names" property
|
||||
- clock-names : The name of clock used by the DFI, must be
|
||||
"pclk_ddr_mon";
|
||||
- operating-points-v2: Refer to Documentation/devicetree/bindings/opp/opp.txt
|
||||
- operating-points-v2: Refer to Documentation/devicetree/bindings/opp/opp-v2.yaml
|
||||
for details.
|
||||
- center-supply: DMC supply node.
|
||||
- status: Marks the node enabled/disabled.
|
||||
|
|
|
|||
|
|
@ -14,10 +14,10 @@ allOf:
|
|||
|
||||
properties:
|
||||
compatible:
|
||||
oneOf:
|
||||
- const: qcom,dsi-phy-7nm
|
||||
- const: qcom,dsi-phy-7nm-8150
|
||||
- const: qcom,sc7280-dsi-phy-7nm
|
||||
enum:
|
||||
- qcom,dsi-phy-7nm
|
||||
- qcom,dsi-phy-7nm-8150
|
||||
- qcom,sc7280-dsi-phy-7nm
|
||||
|
||||
reg:
|
||||
items:
|
||||
|
|
|
|||
|
|
@ -24,13 +24,15 @@ properties:
|
|||
items:
|
||||
- description: Control and Status Register Slave Port
|
||||
- description: Descriptor Slave Port
|
||||
- description: Response Slave Port
|
||||
- description: Response Slave Port (Optional)
|
||||
minItems: 2
|
||||
|
||||
reg-names:
|
||||
items:
|
||||
- const: csr
|
||||
- const: desc
|
||||
- const: resp
|
||||
minItems: 2
|
||||
|
||||
interrupts:
|
||||
maxItems: 1
|
||||
|
|
|
|||
|
|
@ -0,0 +1,130 @@
|
|||
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
|
||||
%YAML 1.2
|
||||
---
|
||||
$id: http://devicetree.org/schemas/dma/renesas,rz-dmac.yaml#
|
||||
$schema: http://devicetree.org/meta-schemas/core.yaml#
|
||||
|
||||
title: Renesas RZ/G2L DMA Controller
|
||||
|
||||
maintainers:
|
||||
- Biju Das <biju.das.jz@bp.renesas.com>
|
||||
|
||||
allOf:
|
||||
- $ref: "dma-controller.yaml#"
|
||||
|
||||
properties:
|
||||
compatible:
|
||||
items:
|
||||
- enum:
|
||||
- renesas,r9a07g044-dmac # RZ/G2{L,LC}
|
||||
- const: renesas,rz-dmac
|
||||
|
||||
reg:
|
||||
items:
|
||||
- description: Control and channel register block
|
||||
- description: DMA extended resource selector block
|
||||
|
||||
interrupts:
|
||||
maxItems: 17
|
||||
|
||||
interrupt-names:
|
||||
items:
|
||||
- const: error
|
||||
- const: ch0
|
||||
- const: ch1
|
||||
- const: ch2
|
||||
- const: ch3
|
||||
- const: ch4
|
||||
- const: ch5
|
||||
- const: ch6
|
||||
- const: ch7
|
||||
- const: ch8
|
||||
- const: ch9
|
||||
- const: ch10
|
||||
- const: ch11
|
||||
- const: ch12
|
||||
- const: ch13
|
||||
- const: ch14
|
||||
- const: ch15
|
||||
|
||||
clocks:
|
||||
items:
|
||||
- description: DMA main clock
|
||||
- description: DMA register access clock
|
||||
|
||||
'#dma-cells':
|
||||
const: 1
|
||||
description:
|
||||
The cell specifies the encoded MID/RID values of the DMAC port
|
||||
connected to the DMA client and the slave channel configuration
|
||||
parameters.
|
||||
bits[0:9] - Specifies MID/RID value
|
||||
bit[10] - Specifies DMA request high enable (HIEN)
|
||||
bit[11] - Specifies DMA request detection type (LVL)
|
||||
bits[12:14] - Specifies DMAACK output mode (AM)
|
||||
bit[15] - Specifies Transfer Mode (TM)
|
||||
|
||||
dma-channels:
|
||||
const: 16
|
||||
|
||||
power-domains:
|
||||
maxItems: 1
|
||||
|
||||
resets:
|
||||
items:
|
||||
- description: Reset for DMA ARESETN reset terminal
|
||||
- description: Reset for DMA RST_ASYNC reset terminal
|
||||
|
||||
required:
|
||||
- compatible
|
||||
- reg
|
||||
- interrupts
|
||||
- interrupt-names
|
||||
- clocks
|
||||
- '#dma-cells'
|
||||
- dma-channels
|
||||
- power-domains
|
||||
- resets
|
||||
|
||||
additionalProperties: false
|
||||
|
||||
examples:
|
||||
- |
|
||||
#include <dt-bindings/interrupt-controller/arm-gic.h>
|
||||
#include <dt-bindings/clock/r9a07g044-cpg.h>
|
||||
|
||||
dmac: dma-controller@11820000 {
|
||||
compatible = "renesas,r9a07g044-dmac",
|
||||
"renesas,rz-dmac";
|
||||
reg = <0x11820000 0x10000>,
|
||||
<0x11830000 0x10000>;
|
||||
interrupts = <GIC_SPI 141 IRQ_TYPE_EDGE_RISING>,
|
||||
<GIC_SPI 125 IRQ_TYPE_EDGE_RISING>,
|
||||
<GIC_SPI 126 IRQ_TYPE_EDGE_RISING>,
|
||||
<GIC_SPI 127 IRQ_TYPE_EDGE_RISING>,
|
||||
<GIC_SPI 128 IRQ_TYPE_EDGE_RISING>,
|
||||
<GIC_SPI 129 IRQ_TYPE_EDGE_RISING>,
|
||||
<GIC_SPI 130 IRQ_TYPE_EDGE_RISING>,
|
||||
<GIC_SPI 131 IRQ_TYPE_EDGE_RISING>,
|
||||
<GIC_SPI 132 IRQ_TYPE_EDGE_RISING>,
|
||||
<GIC_SPI 133 IRQ_TYPE_EDGE_RISING>,
|
||||
<GIC_SPI 134 IRQ_TYPE_EDGE_RISING>,
|
||||
<GIC_SPI 135 IRQ_TYPE_EDGE_RISING>,
|
||||
<GIC_SPI 136 IRQ_TYPE_EDGE_RISING>,
|
||||
<GIC_SPI 137 IRQ_TYPE_EDGE_RISING>,
|
||||
<GIC_SPI 138 IRQ_TYPE_EDGE_RISING>,
|
||||
<GIC_SPI 139 IRQ_TYPE_EDGE_RISING>,
|
||||
<GIC_SPI 140 IRQ_TYPE_EDGE_RISING>;
|
||||
interrupt-names = "error",
|
||||
"ch0", "ch1", "ch2", "ch3",
|
||||
"ch4", "ch5", "ch6", "ch7",
|
||||
"ch8", "ch9", "ch10", "ch11",
|
||||
"ch12", "ch13", "ch14", "ch15";
|
||||
clocks = <&cpg CPG_MOD R9A07G044_DMAC_ACLK>,
|
||||
<&cpg CPG_MOD R9A07G044_DMAC_PCLK>;
|
||||
power-domains = <&cpg>;
|
||||
resets = <&cpg R9A07G044_DMAC_ARESETN>,
|
||||
<&cpg R9A07G044_DMAC_RST_ASYNC>;
|
||||
#dma-cells = <1>;
|
||||
dma-channels = <16>;
|
||||
};
|
||||
|
|
@ -40,6 +40,13 @@ description: |
|
|||
0x0: FIFO mode with threshold selectable with bit 0-1
|
||||
0x1: Direct mode: each DMA request immediately initiates a transfer
|
||||
from/to the memory, FIFO is bypassed.
|
||||
-bit 4: alternative DMA request/acknowledge protocol
|
||||
0x0: Use standard DMA ACK management, where ACK signal is maintained
|
||||
up to the removal of request and transfer completion
|
||||
0x1: Use alternative DMA ACK management, where ACK de-assertion does
|
||||
not wait for the de-assertion of the REQuest, ACK is only managed
|
||||
by transfer completion. This must only be used on channels
|
||||
managing transfers for STM32 USART/UART.
|
||||
|
||||
|
||||
maintainers:
|
||||
|
|
|
|||
|
|
@ -0,0 +1,59 @@
|
|||
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
|
||||
%YAML 1.2
|
||||
---
|
||||
$id: http://devicetree.org/schemas/gpio/gpio-virtio.yaml#
|
||||
$schema: http://devicetree.org/meta-schemas/core.yaml#
|
||||
|
||||
title: Virtio GPIO controller
|
||||
|
||||
maintainers:
|
||||
- Viresh Kumar <viresh.kumar@linaro.org>
|
||||
|
||||
allOf:
|
||||
- $ref: /schemas/virtio/virtio-device.yaml#
|
||||
|
||||
description:
|
||||
Virtio GPIO controller, see /schemas/virtio/virtio-device.yaml for more
|
||||
details.
|
||||
|
||||
properties:
|
||||
$nodename:
|
||||
const: gpio
|
||||
|
||||
compatible:
|
||||
const: virtio,device29
|
||||
|
||||
gpio-controller: true
|
||||
|
||||
"#gpio-cells":
|
||||
const: 2
|
||||
|
||||
interrupt-controller: true
|
||||
|
||||
"#interrupt-cells":
|
||||
const: 2
|
||||
|
||||
required:
|
||||
- compatible
|
||||
- gpio-controller
|
||||
- "#gpio-cells"
|
||||
|
||||
unevaluatedProperties: false
|
||||
|
||||
examples:
|
||||
- |
|
||||
virtio@3000 {
|
||||
compatible = "virtio,mmio";
|
||||
reg = <0x3000 0x100>;
|
||||
interrupts = <41>;
|
||||
|
||||
gpio {
|
||||
compatible = "virtio,device29";
|
||||
gpio-controller;
|
||||
#gpio-cells = <2>;
|
||||
interrupt-controller;
|
||||
#interrupt-cells = <2>;
|
||||
};
|
||||
};
|
||||
|
||||
...
|
||||
|
|
@ -137,7 +137,7 @@ examples:
|
|||
resets = <&reset 0>, <&reset 1>;
|
||||
};
|
||||
|
||||
gpu_opp_table: opp_table0 {
|
||||
gpu_opp_table: opp-table {
|
||||
compatible = "operating-points-v2";
|
||||
|
||||
opp-533000000 {
|
||||
|
|
|
|||
|
|
@ -160,7 +160,7 @@ examples:
|
|||
#cooling-cells = <2>;
|
||||
};
|
||||
|
||||
gpu_opp_table: opp_table0 {
|
||||
gpu_opp_table: opp-table {
|
||||
compatible = "operating-points-v2";
|
||||
|
||||
opp-533000000 {
|
||||
|
|
|
|||
|
|
@ -0,0 +1,51 @@
|
|||
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
|
||||
%YAML 1.2
|
||||
---
|
||||
$id: http://devicetree.org/schemas/i2c/i2c-virtio.yaml#
|
||||
$schema: http://devicetree.org/meta-schemas/core.yaml#
|
||||
|
||||
title: Virtio I2C Adapter
|
||||
|
||||
maintainers:
|
||||
- Viresh Kumar <viresh.kumar@linaro.org>
|
||||
|
||||
allOf:
|
||||
- $ref: /schemas/i2c/i2c-controller.yaml#
|
||||
- $ref: /schemas/virtio/virtio-device.yaml#
|
||||
|
||||
description:
|
||||
Virtio I2C device, see /schemas/virtio/virtio-device.yaml for more details.
|
||||
|
||||
properties:
|
||||
$nodename:
|
||||
const: i2c
|
||||
|
||||
compatible:
|
||||
const: virtio,device22
|
||||
|
||||
required:
|
||||
- compatible
|
||||
|
||||
unevaluatedProperties: false
|
||||
|
||||
examples:
|
||||
- |
|
||||
virtio@3000 {
|
||||
compatible = "virtio,mmio";
|
||||
reg = <0x3000 0x100>;
|
||||
interrupts = <41>;
|
||||
|
||||
i2c {
|
||||
compatible = "virtio,device22";
|
||||
|
||||
#address-cells = <1>;
|
||||
#size-cells = <0>;
|
||||
|
||||
light-sensor@20 {
|
||||
compatible = "dynaimage,al3320a";
|
||||
reg = <0x20>;
|
||||
};
|
||||
};
|
||||
};
|
||||
|
||||
...
|
||||
|
|
@ -29,6 +29,8 @@ properties:
|
|||
description:
|
||||
Regulator for the LRADC reference voltage
|
||||
|
||||
wakeup-source: true
|
||||
|
||||
patternProperties:
|
||||
"^button-[0-9]+$":
|
||||
type: object
|
||||
|
|
|
|||
|
|
@ -1,55 +0,0 @@
|
|||
Qualcomm PM8941 PMIC Power Key
|
||||
|
||||
PROPERTIES
|
||||
|
||||
- compatible:
|
||||
Usage: required
|
||||
Value type: <string>
|
||||
Definition: must be one of:
|
||||
"qcom,pm8941-pwrkey"
|
||||
"qcom,pm8941-resin"
|
||||
"qcom,pmk8350-pwrkey"
|
||||
"qcom,pmk8350-resin"
|
||||
|
||||
- reg:
|
||||
Usage: required
|
||||
Value type: <prop-encoded-array>
|
||||
Definition: base address of registers for block
|
||||
|
||||
- interrupts:
|
||||
Usage: required
|
||||
Value type: <prop-encoded-array>
|
||||
Definition: key change interrupt; The format of the specifier is
|
||||
defined by the binding document describing the node's
|
||||
interrupt parent.
|
||||
|
||||
- debounce:
|
||||
Usage: optional
|
||||
Value type: <u32>
|
||||
Definition: time in microseconds that key must be pressed or released
|
||||
for state change interrupt to trigger.
|
||||
|
||||
- bias-pull-up:
|
||||
Usage: optional
|
||||
Value type: <empty>
|
||||
Definition: presence of this property indicates that the KPDPWR_N pin
|
||||
should be configured for pull up.
|
||||
|
||||
- linux,code:
|
||||
Usage: optional
|
||||
Value type: <u32>
|
||||
Definition: The input key-code associated with the power key.
|
||||
Use the linux event codes defined in
|
||||
include/dt-bindings/input/linux-event-codes.h
|
||||
When property is omitted KEY_POWER is assumed.
|
||||
|
||||
EXAMPLE
|
||||
|
||||
pwrkey@800 {
|
||||
compatible = "qcom,pm8941-pwrkey";
|
||||
reg = <0x800>;
|
||||
interrupts = <0x0 0x8 0 IRQ_TYPE_EDGE_BOTH>;
|
||||
debounce = <15625>;
|
||||
bias-pull-up;
|
||||
linux,code = <KEY_POWER>;
|
||||
};
|
||||
|
|
@ -0,0 +1,51 @@
|
|||
# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
|
||||
%YAML 1.2
|
||||
---
|
||||
$id: http://devicetree.org/schemas/input/qcom,pm8941-pwrkey.yaml#
|
||||
$schema: http://devicetree.org/meta-schemas/core.yaml#
|
||||
|
||||
title: Qualcomm PM8941 PMIC Power Key
|
||||
|
||||
maintainers:
|
||||
- Courtney Cavin <courtney.cavin@sonymobile.com>
|
||||
- Vinod Koul <vkoul@kernel.org>
|
||||
|
||||
allOf:
|
||||
- $ref: input.yaml#
|
||||
|
||||
properties:
|
||||
compatible:
|
||||
enum:
|
||||
- qcom,pm8941-pwrkey
|
||||
- qcom,pm8941-resin
|
||||
- qcom,pmk8350-pwrkey
|
||||
- qcom,pmk8350-resin
|
||||
|
||||
interrupts:
|
||||
maxItems: 1
|
||||
|
||||
debounce:
|
||||
description: |
|
||||
Time in microseconds that key must be pressed or
|
||||
released for state change interrupt to trigger.
|
||||
$ref: /schemas/types.yaml#/definitions/uint32
|
||||
|
||||
bias-pull-up:
|
||||
description: |
|
||||
Presence of this property indicates that the KPDPWR_N
|
||||
pin should be configured for pull up.
|
||||
$ref: /schemas/types.yaml#/definitions/flag
|
||||
|
||||
linux,code:
|
||||
description: |
|
||||
The input key-code associated with the power key.
|
||||
Use the linux event codes defined in
|
||||
include/dt-bindings/input/linux-event-codes.h
|
||||
When property is omitted KEY_POWER is assumed.
|
||||
|
||||
required:
|
||||
- compatible
|
||||
- interrupts
|
||||
|
||||
unevaluatedProperties: false
|
||||
...
|
||||
|
|
@ -1,21 +0,0 @@
|
|||
* Regulator Haptic Device Tree Bindings
|
||||
|
||||
Required Properties:
|
||||
- compatible : Should be "regulator-haptic"
|
||||
- haptic-supply : Power supply to the haptic motor.
|
||||
[*] refer Documentation/devicetree/bindings/regulator/regulator.txt
|
||||
|
||||
- max-microvolt : The maximum voltage value supplied to the haptic motor.
|
||||
[The unit of the voltage is a micro]
|
||||
|
||||
- min-microvolt : The minimum voltage value supplied to the haptic motor.
|
||||
[The unit of the voltage is a micro]
|
||||
|
||||
Example:
|
||||
|
||||
haptics {
|
||||
compatible = "regulator-haptic";
|
||||
haptic-supply = <&motor_regulator>;
|
||||
max-microvolt = <2700000>;
|
||||
min-microvolt = <1100000>;
|
||||
};
|
||||
|
|
@ -0,0 +1,43 @@
|
|||
# SPDX-License-Identifier: GPL-2.0
|
||||
%YAML 1.2
|
||||
---
|
||||
$id: "http://devicetree.org/schemas/input/regulator-haptic.yaml#"
|
||||
$schema: "http://devicetree.org/meta-schemas/core.yaml#"
|
||||
|
||||
title: Regulator Haptic Device Tree Bindings
|
||||
|
||||
maintainers:
|
||||
- Jaewon Kim <jaewon02.kim@samsung.com>
|
||||
|
||||
properties:
|
||||
compatible:
|
||||
const: regulator-haptic
|
||||
|
||||
haptic-supply:
|
||||
description: >
|
||||
Power supply to the haptic motor
|
||||
|
||||
max-microvolt:
|
||||
description: >
|
||||
The maximum voltage value supplied to the haptic motor
|
||||
|
||||
min-microvolt:
|
||||
description: >
|
||||
The minimum voltage value supplied to the haptic motor
|
||||
|
||||
required:
|
||||
- compatible
|
||||
- haptic-supply
|
||||
- max-microvolt
|
||||
- min-microvolt
|
||||
|
||||
additionalProperties: false
|
||||
|
||||
examples:
|
||||
- |
|
||||
haptics {
|
||||
compatible = "regulator-haptic";
|
||||
haptic-supply = <&motor_regulator>;
|
||||
max-microvolt = <2700000>;
|
||||
min-microvolt = <1100000>;
|
||||
};
|
||||
|
|
@ -0,0 +1,62 @@
|
|||
# SPDX-License-Identifier: GPL-2.0
|
||||
%YAML 1.2
|
||||
---
|
||||
$id: http://devicetree.org/schemas/input/touchscreen/chipone,icn8318.yaml#
|
||||
$schema: http://devicetree.org/meta-schemas/core.yaml#
|
||||
|
||||
title: ChipOne ICN8318 Touchscreen Controller Device Tree Bindings
|
||||
|
||||
maintainers:
|
||||
- Dmitry Torokhov <dmitry.torokhov@gmail.com>
|
||||
|
||||
allOf:
|
||||
- $ref: touchscreen.yaml#
|
||||
|
||||
properties:
|
||||
compatible:
|
||||
const: chipone,icn8318
|
||||
|
||||
reg:
|
||||
maxItems: 1
|
||||
|
||||
interrupts:
|
||||
maxItems: 1
|
||||
|
||||
wake-gpios:
|
||||
maxItems: 1
|
||||
|
||||
unevaluatedProperties: false
|
||||
|
||||
required:
|
||||
- compatible
|
||||
- reg
|
||||
- interrupts
|
||||
- wake-gpios
|
||||
- touchscreen-size-x
|
||||
- touchscreen-size-y
|
||||
|
||||
examples:
|
||||
- |
|
||||
#include <dt-bindings/gpio/gpio.h>
|
||||
#include <dt-bindings/interrupt-controller/arm-gic.h>
|
||||
|
||||
i2c {
|
||||
#address-cells = <1>;
|
||||
#size-cells = <0>;
|
||||
|
||||
touchscreen@40 {
|
||||
compatible = "chipone,icn8318";
|
||||
reg = <0x40>;
|
||||
interrupt-parent = <&pio>;
|
||||
interrupts = <9 IRQ_TYPE_EDGE_FALLING>; /* EINT9 (PG9) */
|
||||
pinctrl-names = "default";
|
||||
pinctrl-0 = <&ts_wake_pin_p66>;
|
||||
wake-gpios = <&pio 1 3 GPIO_ACTIVE_HIGH>; /* PB3 */
|
||||
touchscreen-size-x = <800>;
|
||||
touchscreen-size-y = <480>;
|
||||
touchscreen-inverted-x;
|
||||
touchscreen-swapped-x-y;
|
||||
};
|
||||
};
|
||||
|
||||
...
|
||||
|
|
@ -1,44 +0,0 @@
|
|||
* ChipOne icn8318 I2C touchscreen controller
|
||||
|
||||
Required properties:
|
||||
- compatible : "chipone,icn8318"
|
||||
- reg : I2C slave address of the chip (0x40)
|
||||
- interrupts : interrupt specification for the icn8318 interrupt
|
||||
- wake-gpios : GPIO specification for the WAKE input
|
||||
- touchscreen-size-x : horizontal resolution of touchscreen (in pixels)
|
||||
- touchscreen-size-y : vertical resolution of touchscreen (in pixels)
|
||||
|
||||
Optional properties:
|
||||
- pinctrl-names : should be "default"
|
||||
- pinctrl-0: : a phandle pointing to the pin settings for the
|
||||
control gpios
|
||||
- touchscreen-fuzz-x : horizontal noise value of the absolute input
|
||||
device (in pixels)
|
||||
- touchscreen-fuzz-y : vertical noise value of the absolute input
|
||||
device (in pixels)
|
||||
- touchscreen-inverted-x : X axis is inverted (boolean)
|
||||
- touchscreen-inverted-y : Y axis is inverted (boolean)
|
||||
- touchscreen-swapped-x-y : X and Y axis are swapped (boolean)
|
||||
Swapping is done after inverting the axis
|
||||
|
||||
Example:
|
||||
|
||||
i2c@00000000 {
|
||||
/* ... */
|
||||
|
||||
chipone_icn8318@40 {
|
||||
compatible = "chipone,icn8318";
|
||||
reg = <0x40>;
|
||||
interrupt-parent = <&pio>;
|
||||
interrupts = <9 IRQ_TYPE_EDGE_FALLING>; /* EINT9 (PG9) */
|
||||
pinctrl-names = "default";
|
||||
pinctrl-0 = <&ts_wake_pin_p66>;
|
||||
wake-gpios = <&pio 1 3 GPIO_ACTIVE_HIGH>; /* PB3 */
|
||||
touchscreen-size-x = <800>;
|
||||
touchscreen-size-y = <480>;
|
||||
touchscreen-inverted-x;
|
||||
touchscreen-swapped-x-y;
|
||||
};
|
||||
|
||||
/* ... */
|
||||
};
|
||||
|
|
@ -0,0 +1,68 @@
|
|||
# SPDX-License-Identifier: GPL-2.0
|
||||
%YAML 1.2
|
||||
---
|
||||
$id: http://devicetree.org/schemas/input/touchscreen/pixcir,pixcir_ts.yaml#
|
||||
$schema: http://devicetree.org/meta-schemas/core.yaml#
|
||||
|
||||
title: Pixcir Touchscreen Controller Device Tree Bindings
|
||||
|
||||
maintainers:
|
||||
- Dmitry Torokhov <dmitry.torokhov@gmail.com>
|
||||
|
||||
allOf:
|
||||
- $ref: touchscreen.yaml#
|
||||
|
||||
properties:
|
||||
compatible:
|
||||
enum:
|
||||
- pixcir,pixcir_ts
|
||||
- pixcir,pixcir_tangoc
|
||||
|
||||
reg:
|
||||
maxItems: 1
|
||||
|
||||
interrupts:
|
||||
maxItems: 1
|
||||
|
||||
attb-gpio:
|
||||
maxItems: 1
|
||||
|
||||
reset-gpios:
|
||||
maxItems: 1
|
||||
|
||||
enable-gpios:
|
||||
maxItems: 1
|
||||
|
||||
wake-gpios:
|
||||
maxItems: 1
|
||||
|
||||
unevaluatedProperties: false
|
||||
|
||||
required:
|
||||
- compatible
|
||||
- reg
|
||||
- interrupts
|
||||
- attb-gpio
|
||||
- touchscreen-size-x
|
||||
- touchscreen-size-y
|
||||
|
||||
examples:
|
||||
- |
|
||||
#include <dt-bindings/gpio/gpio.h>
|
||||
#include <dt-bindings/interrupt-controller/arm-gic.h>
|
||||
|
||||
i2c {
|
||||
#address-cells = <1>;
|
||||
#size-cells = <0>;
|
||||
|
||||
touchscreen@5c {
|
||||
compatible = "pixcir,pixcir_ts";
|
||||
reg = <0x5c>;
|
||||
interrupts = <2 0>;
|
||||
attb-gpio = <&gpf 2 0 2>;
|
||||
touchscreen-size-x = <800>;
|
||||
touchscreen-size-y = <600>;
|
||||
};
|
||||
};
|
||||
|
||||
...
|
||||
|
|
@ -1,31 +0,0 @@
|
|||
* Pixcir I2C touchscreen controllers
|
||||
|
||||
Required properties:
|
||||
- compatible: must be "pixcir,pixcir_ts" or "pixcir,pixcir_tangoc"
|
||||
- reg: I2C address of the chip
|
||||
- interrupts: interrupt to which the chip is connected
|
||||
- attb-gpio: GPIO connected to the ATTB line of the chip
|
||||
- touchscreen-size-x: horizontal resolution of touchscreen (in pixels)
|
||||
- touchscreen-size-y: vertical resolution of touchscreen (in pixels)
|
||||
|
||||
Optional properties:
|
||||
- reset-gpios: GPIO connected to the RESET line of the chip
|
||||
- enable-gpios: GPIO connected to the ENABLE line of the chip
|
||||
- wake-gpios: GPIO connected to the WAKE line of the chip
|
||||
|
||||
Example:
|
||||
|
||||
i2c@00000000 {
|
||||
/* ... */
|
||||
|
||||
pixcir_ts@5c {
|
||||
compatible = "pixcir,pixcir_ts";
|
||||
reg = <0x5c>;
|
||||
interrupts = <2 0>;
|
||||
attb-gpio = <&gpf 2 0 2>;
|
||||
touchscreen-size-x = <800>;
|
||||
touchscreen-size-y = <600>;
|
||||
};
|
||||
|
||||
/* ... */
|
||||
};
|
||||
|
|
@ -0,0 +1,128 @@
|
|||
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
|
||||
%YAML 1.2
|
||||
---
|
||||
$id: http://devicetree.org/schemas/input/touchscreen/ti,tsc2005.yaml#
|
||||
$schema: http://devicetree.org/meta-schemas/core.yaml#
|
||||
|
||||
title: Texas Instruments TSC2004 and TSC2005 touchscreen controller bindings
|
||||
|
||||
maintainers:
|
||||
- Marek Vasut <marex@denx.de>
|
||||
- Michael Welling <mwelling@ieee.org>
|
||||
|
||||
properties:
|
||||
$nodename:
|
||||
pattern: "^touchscreen(@.*)?$"
|
||||
|
||||
compatible:
|
||||
enum:
|
||||
- ti,tsc2004
|
||||
- ti,tsc2005
|
||||
|
||||
reg:
|
||||
maxItems: 1
|
||||
description: |
|
||||
I2C address when used on the I2C bus, or the SPI chip select index
|
||||
when used on the SPI bus
|
||||
|
||||
interrupts:
|
||||
maxItems: 1
|
||||
|
||||
reset-gpios:
|
||||
maxItems: 1
|
||||
description: GPIO specifier for the controller reset line
|
||||
|
||||
spi-max-frequency:
|
||||
description: TSC2005 SPI bus clock frequency.
|
||||
maximum: 25000000
|
||||
|
||||
ti,x-plate-ohms:
|
||||
description: resistance of the touchscreen's X plates in ohm (defaults to 280)
|
||||
|
||||
ti,esd-recovery-timeout-ms:
|
||||
description: |
|
||||
if the touchscreen does not respond after the configured time
|
||||
(in milli seconds), the driver will reset it. This is disabled
|
||||
by default.
|
||||
|
||||
vio-supply:
|
||||
description: Regulator specifier
|
||||
|
||||
touchscreen-fuzz-pressure: true
|
||||
touchscreen-fuzz-x: true
|
||||
touchscreen-fuzz-y: true
|
||||
touchscreen-max-pressure: true
|
||||
touchscreen-size-x: true
|
||||
touchscreen-size-y: true
|
||||
|
||||
allOf:
|
||||
- $ref: touchscreen.yaml#
|
||||
- if:
|
||||
properties:
|
||||
compatible:
|
||||
contains:
|
||||
const: ti,tsc2004
|
||||
then:
|
||||
properties:
|
||||
spi-max-frequency: false
|
||||
|
||||
additionalProperties: false
|
||||
|
||||
required:
|
||||
- compatible
|
||||
- reg
|
||||
- interrupts
|
||||
|
||||
examples:
|
||||
- |
|
||||
#include <dt-bindings/interrupt-controller/irq.h>
|
||||
#include <dt-bindings/gpio/gpio.h>
|
||||
i2c {
|
||||
#address-cells = <1>;
|
||||
#size-cells = <0>;
|
||||
touchscreen@48 {
|
||||
compatible = "ti,tsc2004";
|
||||
reg = <0x48>;
|
||||
vio-supply = <&vio>;
|
||||
|
||||
reset-gpios = <&gpio4 8 GPIO_ACTIVE_HIGH>;
|
||||
interrupts-extended = <&gpio1 27 IRQ_TYPE_EDGE_RISING>;
|
||||
|
||||
touchscreen-fuzz-x = <4>;
|
||||
touchscreen-fuzz-y = <7>;
|
||||
touchscreen-fuzz-pressure = <2>;
|
||||
touchscreen-size-x = <4096>;
|
||||
touchscreen-size-y = <4096>;
|
||||
touchscreen-max-pressure = <2048>;
|
||||
|
||||
ti,x-plate-ohms = <280>;
|
||||
ti,esd-recovery-timeout-ms = <8000>;
|
||||
};
|
||||
};
|
||||
- |
|
||||
#include <dt-bindings/interrupt-controller/irq.h>
|
||||
#include <dt-bindings/gpio/gpio.h>
|
||||
spi {
|
||||
#address-cells = <1>;
|
||||
#size-cells = <0>;
|
||||
touchscreen@0 {
|
||||
compatible = "ti,tsc2005";
|
||||
spi-max-frequency = <6000000>;
|
||||
reg = <0>;
|
||||
|
||||
vio-supply = <&vio>;
|
||||
|
||||
reset-gpios = <&gpio4 8 GPIO_ACTIVE_HIGH>; /* 104 */
|
||||
interrupts-extended = <&gpio4 4 IRQ_TYPE_EDGE_RISING>; /* 100 */
|
||||
|
||||
touchscreen-fuzz-x = <4>;
|
||||
touchscreen-fuzz-y = <7>;
|
||||
touchscreen-fuzz-pressure = <2>;
|
||||
touchscreen-size-x = <4096>;
|
||||
touchscreen-size-y = <4096>;
|
||||
touchscreen-max-pressure = <2048>;
|
||||
|
||||
ti,x-plate-ohms = <280>;
|
||||
ti,esd-recovery-timeout-ms = <8000>;
|
||||
};
|
||||
};
|
||||
|
|
@ -1,64 +0,0 @@
|
|||
* Texas Instruments tsc2004 and tsc2005 touchscreen controllers
|
||||
|
||||
Required properties:
|
||||
- compatible : "ti,tsc2004" or "ti,tsc2005"
|
||||
- reg : Device address
|
||||
- interrupts : IRQ specifier
|
||||
- spi-max-frequency : Maximum SPI clocking speed of the device
|
||||
(for tsc2005)
|
||||
|
||||
Optional properties:
|
||||
- vio-supply : Regulator specifier
|
||||
- reset-gpios : GPIO specifier for the controller reset line
|
||||
- ti,x-plate-ohms : integer, resistance of the touchscreen's X plates
|
||||
in ohm (defaults to 280)
|
||||
- ti,esd-recovery-timeout-ms : integer, if the touchscreen does not respond after
|
||||
the configured time (in milli seconds), the driver
|
||||
will reset it. This is disabled by default.
|
||||
- properties defined in touchscreen.txt
|
||||
|
||||
Example:
|
||||
|
||||
&i2c3 {
|
||||
tsc2004@48 {
|
||||
compatible = "ti,tsc2004";
|
||||
reg = <0x48>;
|
||||
vio-supply = <&vio>;
|
||||
|
||||
reset-gpios = <&gpio4 8 GPIO_ACTIVE_HIGH>;
|
||||
interrupts-extended = <&gpio1 27 IRQ_TYPE_EDGE_RISING>;
|
||||
|
||||
touchscreen-fuzz-x = <4>;
|
||||
touchscreen-fuzz-y = <7>;
|
||||
touchscreen-fuzz-pressure = <2>;
|
||||
touchscreen-size-x = <4096>;
|
||||
touchscreen-size-y = <4096>;
|
||||
touchscreen-max-pressure = <2048>;
|
||||
|
||||
ti,x-plate-ohms = <280>;
|
||||
ti,esd-recovery-timeout-ms = <8000>;
|
||||
};
|
||||
}
|
||||
|
||||
&mcspi1 {
|
||||
tsc2005@0 {
|
||||
compatible = "ti,tsc2005";
|
||||
spi-max-frequency = <6000000>;
|
||||
reg = <0>;
|
||||
|
||||
vio-supply = <&vio>;
|
||||
|
||||
reset-gpios = <&gpio4 8 GPIO_ACTIVE_HIGH>; /* 104 */
|
||||
interrupts-extended = <&gpio4 4 IRQ_TYPE_EDGE_RISING>; /* 100 */
|
||||
|
||||
touchscreen-fuzz-x = <4>;
|
||||
touchscreen-fuzz-y = <7>;
|
||||
touchscreen-fuzz-pressure = <2>;
|
||||
touchscreen-size-x = <4096>;
|
||||
touchscreen-size-y = <4096>;
|
||||
touchscreen-max-pressure = <2048>;
|
||||
|
||||
ti,x-plate-ohms = <280>;
|
||||
ti,esd-recovery-timeout-ms = <8000>;
|
||||
};
|
||||
}
|
||||
|
|
@ -81,10 +81,10 @@ examples:
|
|||
noc_opp_table: opp-table {
|
||||
compatible = "operating-points-v2";
|
||||
|
||||
opp-133M {
|
||||
opp-133333333 {
|
||||
opp-hz = /bits/ 64 <133333333>;
|
||||
};
|
||||
opp-800M {
|
||||
opp-800000000 {
|
||||
opp-hz = /bits/ 64 <800000000>;
|
||||
};
|
||||
};
|
||||
|
|
|
|||
|
|
@ -18,6 +18,9 @@ description: |
|
|||
sun50i-cpufreq-nvmem driver reads the efuse value from the SoC to
|
||||
provide the OPP framework with required information.
|
||||
|
||||
allOf:
|
||||
- $ref: opp-v2-base.yaml#
|
||||
|
||||
properties:
|
||||
compatible:
|
||||
const: allwinner,sun50i-h6-operating-points
|
||||
|
|
@ -43,6 +46,7 @@ patternProperties:
|
|||
|
||||
properties:
|
||||
opp-hz: true
|
||||
clock-latency-ns: true
|
||||
|
||||
patternProperties:
|
||||
"opp-microvolt-.*": true
|
||||
|
|
|
|||
|
|
@ -0,0 +1,51 @@
|
|||
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
|
||||
%YAML 1.2
|
||||
---
|
||||
$id: http://devicetree.org/schemas/opp/opp-v1.yaml#
|
||||
$schema: http://devicetree.org/meta-schemas/core.yaml#
|
||||
|
||||
title: Generic OPP (Operating Performance Points) v1 Bindings
|
||||
|
||||
maintainers:
|
||||
- Viresh Kumar <viresh.kumar@linaro.org>
|
||||
|
||||
description: |+
|
||||
Devices work at voltage-current-frequency combinations and some implementations
|
||||
have the liberty of choosing these. These combinations are called Operating
|
||||
Performance Points aka OPPs. This document defines bindings for these OPPs
|
||||
applicable across wide range of devices. For illustration purpose, this document
|
||||
uses CPU as a device.
|
||||
|
||||
This binding only supports voltage-frequency pairs.
|
||||
|
||||
select: true
|
||||
|
||||
properties:
|
||||
operating-points:
|
||||
$ref: /schemas/types.yaml#/definitions/uint32-matrix
|
||||
items:
|
||||
items:
|
||||
- description: Frequency in kHz
|
||||
- description: Voltage for OPP in uV
|
||||
|
||||
|
||||
additionalProperties: true
|
||||
examples:
|
||||
- |
|
||||
cpus {
|
||||
#address-cells = <1>;
|
||||
#size-cells = <0>;
|
||||
|
||||
cpu@0 {
|
||||
compatible = "arm,cortex-a9";
|
||||
device_type = "cpu";
|
||||
reg = <0>;
|
||||
next-level-cache = <&L2>;
|
||||
operating-points =
|
||||
/* kHz uV */
|
||||
<792000 1100000>,
|
||||
<396000 950000>,
|
||||
<198000 850000>;
|
||||
};
|
||||
};
|
||||
...
|
||||
|
|
@ -0,0 +1,214 @@
|
|||
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
|
||||
%YAML 1.2
|
||||
---
|
||||
$id: http://devicetree.org/schemas/opp/opp-v2-base.yaml#
|
||||
$schema: http://devicetree.org/meta-schemas/core.yaml#
|
||||
|
||||
title: Generic OPP (Operating Performance Points) Common Binding
|
||||
|
||||
maintainers:
|
||||
- Viresh Kumar <viresh.kumar@linaro.org>
|
||||
|
||||
description: |
|
||||
Devices work at voltage-current-frequency combinations and some implementations
|
||||
have the liberty of choosing these. These combinations are called Operating
|
||||
Performance Points aka OPPs. This document defines bindings for these OPPs
|
||||
applicable across wide range of devices. For illustration purpose, this document
|
||||
uses CPU as a device.
|
||||
|
||||
This describes the OPPs belonging to a device.
|
||||
|
||||
select: false
|
||||
|
||||
properties:
|
||||
$nodename:
|
||||
pattern: '^opp-table(-[a-z0-9]+)?$'
|
||||
|
||||
opp-shared:
|
||||
description:
|
||||
Indicates that device nodes using this OPP Table Node's phandle switch
|
||||
their DVFS state together, i.e. they share clock/voltage/current lines.
|
||||
Missing property means devices have independent clock/voltage/current
|
||||
lines, but they share OPP tables.
|
||||
type: boolean
|
||||
|
||||
patternProperties:
|
||||
'^opp-?[0-9]+$':
|
||||
type: object
|
||||
description:
|
||||
One or more OPP nodes describing voltage-current-frequency combinations.
|
||||
Their name isn't significant but their phandle can be used to reference an
|
||||
OPP. These are mandatory except for the case where the OPP table is
|
||||
present only to indicate dependency between devices using the opp-shared
|
||||
property.
|
||||
|
||||
properties:
|
||||
opp-hz:
|
||||
description:
|
||||
Frequency in Hz, expressed as a 64-bit big-endian integer. This is a
|
||||
required property for all device nodes, unless another "required"
|
||||
property to uniquely identify the OPP nodes exists. Devices like power
|
||||
domains must have another (implementation dependent) property.
|
||||
|
||||
opp-microvolt:
|
||||
description: |
|
||||
Voltage for the OPP
|
||||
|
||||
A single regulator's voltage is specified with an array of size one or three.
|
||||
Single entry is for target voltage and three entries are for <target min max>
|
||||
voltages.
|
||||
|
||||
Entries for multiple regulators shall be provided in the same field separated
|
||||
by angular brackets <>. The OPP binding doesn't provide any provisions to
|
||||
relate the values to their power supplies or the order in which the supplies
|
||||
need to be configured and that is left for the implementation specific
|
||||
binding.
|
||||
|
||||
Entries for all regulators shall be of the same size, i.e. either all use a
|
||||
single value or triplets.
|
||||
minItems: 1
|
||||
maxItems: 8 # Should be enough regulators
|
||||
items:
|
||||
minItems: 1
|
||||
maxItems: 3
|
||||
|
||||
opp-microamp:
|
||||
description: |
|
||||
The maximum current drawn by the device in microamperes considering
|
||||
system specific parameters (such as transients, process, aging,
|
||||
maximum operating temperature range etc.) as necessary. This may be
|
||||
used to set the most efficient regulator operating mode.
|
||||
|
||||
Should only be set if opp-microvolt or opp-microvolt-<name> is set for
|
||||
the OPP.
|
||||
|
||||
Entries for multiple regulators shall be provided in the same field
|
||||
separated by angular brackets <>. If current values aren't required
|
||||
for a regulator, then it shall be filled with 0. If current values
|
||||
aren't required for any of the regulators, then this field is not
|
||||
required. The OPP binding doesn't provide any provisions to relate the
|
||||
values to their power supplies or the order in which the supplies need
|
||||
to be configured and that is left for the implementation specific
|
||||
binding.
|
||||
minItems: 1
|
||||
maxItems: 8 # Should be enough regulators
|
||||
|
||||
opp-level:
|
||||
description:
|
||||
A value representing the performance level of the device.
|
||||
$ref: /schemas/types.yaml#/definitions/uint32
|
||||
|
||||
opp-peak-kBps:
|
||||
description:
|
||||
Peak bandwidth in kilobytes per second, expressed as an array of
|
||||
32-bit big-endian integers. Each element of the array represents the
|
||||
peak bandwidth value of each interconnect path. The number of elements
|
||||
should match the number of interconnect paths.
|
||||
minItems: 1
|
||||
maxItems: 32 # Should be enough
|
||||
|
||||
opp-avg-kBps:
|
||||
description:
|
||||
Average bandwidth in kilobytes per second, expressed as an array
|
||||
of 32-bit big-endian integers. Each element of the array represents the
|
||||
average bandwidth value of each interconnect path. The number of elements
|
||||
should match the number of interconnect paths. This property is only
|
||||
meaningful in OPP tables where opp-peak-kBps is present.
|
||||
minItems: 1
|
||||
maxItems: 32 # Should be enough
|
||||
|
||||
clock-latency-ns:
|
||||
description:
|
||||
Specifies the maximum possible transition latency (in nanoseconds) for
|
||||
switching to this OPP from any other OPP.
|
||||
|
||||
turbo-mode:
|
||||
description:
|
||||
Marks the OPP to be used only for turbo modes. Turbo mode is available
|
||||
on some platforms, where the device can run over its operating
|
||||
frequency for a short duration of time limited by the device's power,
|
||||
current and thermal limits.
|
||||
type: boolean
|
||||
|
||||
opp-suspend:
|
||||
description:
|
||||
Marks the OPP to be used during device suspend. If multiple OPPs in
|
||||
the table have this, the OPP with highest opp-hz will be used.
|
||||
type: boolean
|
||||
|
||||
opp-supported-hw:
|
||||
description: |
|
||||
This property allows a platform to enable only a subset of the OPPs
|
||||
from the larger set present in the OPP table, based on the current
|
||||
version of the hardware (already known to the operating system).
|
||||
|
||||
Each block present in the array of blocks in this property, represents
|
||||
a sub-group of hardware versions supported by the OPP. i.e. <sub-group
|
||||
A>, <sub-group B>, etc. The OPP will be enabled if _any_ of these
|
||||
sub-groups match the hardware's version.
|
||||
|
||||
Each sub-group is a platform defined array representing the hierarchy
|
||||
of hardware versions supported by the platform. For a platform with
|
||||
three hierarchical levels of version (X.Y.Z), this field shall look
|
||||
like
|
||||
|
||||
opp-supported-hw = <X1 Y1 Z1>, <X2 Y2 Z2>, <X3 Y3 Z3>.
|
||||
|
||||
Each level (eg. X1) in version hierarchy is represented by a 32 bit
|
||||
value, one bit per version and so there can be maximum 32 versions per
|
||||
level. Logical AND (&) operation is performed for each level with the
|
||||
hardware's level version and a non-zero output for _all_ the levels in
|
||||
a sub-group means the OPP is supported by hardware. A value of
|
||||
0xFFFFFFFF for each level in the sub-group will enable the OPP for all
|
||||
versions for the hardware.
|
||||
$ref: /schemas/types.yaml#/definitions/uint32-matrix
|
||||
maxItems: 32
|
||||
items:
|
||||
minItems: 1
|
||||
maxItems: 4
|
||||
|
||||
required-opps:
|
||||
description:
|
||||
This contains phandle to an OPP node in another device's OPP table. It
|
||||
may contain an array of phandles, where each phandle points to an OPP
|
||||
of a different device. It should not contain multiple phandles to the
|
||||
OPP nodes in the same OPP table. This specifies the minimum required
|
||||
OPP of the device(s), whose OPP's phandle is present in this property,
|
||||
for the functioning of the current device at the current OPP (where
|
||||
this property is present).
|
||||
$ref: /schemas/types.yaml#/definitions/phandle-array
|
||||
|
||||
patternProperties:
|
||||
'^opp-microvolt-':
|
||||
description:
|
||||
Named opp-microvolt property. This is exactly similar to the above
|
||||
opp-microvolt property, but allows multiple voltage ranges to be
|
||||
provided for the same OPP. At runtime, the platform can pick a <name>
|
||||
and matching opp-microvolt-<name> property will be enabled for all
|
||||
OPPs. If the platform doesn't pick a specific <name> or the <name>
|
||||
doesn't match with any opp-microvolt-<name> properties, then
|
||||
opp-microvolt property shall be used, if present.
|
||||
$ref: /schemas/types.yaml#/definitions/uint32-matrix
|
||||
minItems: 1
|
||||
maxItems: 8 # Should be enough regulators
|
||||
items:
|
||||
minItems: 1
|
||||
maxItems: 3
|
||||
|
||||
'^opp-microamp-':
|
||||
description:
|
||||
Named opp-microamp property. Similar to opp-microvolt-<name> property,
|
||||
but for microamp instead.
|
||||
$ref: /schemas/types.yaml#/definitions/uint32-array
|
||||
minItems: 1
|
||||
maxItems: 8 # Should be enough regulators
|
||||
|
||||
dependencies:
|
||||
opp-avg-kBps: [ opp-peak-kBps ]
|
||||
|
||||
required:
|
||||
- compatible
|
||||
|
||||
additionalProperties: true
|
||||
|
||||
...
|
||||
|
|
@ -0,0 +1,475 @@
|
|||
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
|
||||
%YAML 1.2
|
||||
---
|
||||
$id: http://devicetree.org/schemas/opp/opp-v2.yaml#
|
||||
$schema: http://devicetree.org/meta-schemas/core.yaml#
|
||||
|
||||
title: Generic OPP (Operating Performance Points) Bindings
|
||||
|
||||
maintainers:
|
||||
- Viresh Kumar <viresh.kumar@linaro.org>
|
||||
|
||||
allOf:
|
||||
- $ref: opp-v2-base.yaml#
|
||||
|
||||
properties:
|
||||
compatible:
|
||||
const: operating-points-v2
|
||||
|
||||
unevaluatedProperties: false
|
||||
|
||||
examples:
|
||||
- |
|
||||
/*
|
||||
* Example 1: Single cluster Dual-core ARM cortex A9, switch DVFS states
|
||||
* together.
|
||||
*/
|
||||
cpus {
|
||||
#address-cells = <1>;
|
||||
#size-cells = <0>;
|
||||
|
||||
cpu@0 {
|
||||
compatible = "arm,cortex-a9";
|
||||
device_type = "cpu";
|
||||
reg = <0>;
|
||||
next-level-cache = <&L2>;
|
||||
clocks = <&clk_controller 0>;
|
||||
clock-names = "cpu";
|
||||
cpu-supply = <&cpu_supply0>;
|
||||
operating-points-v2 = <&cpu0_opp_table0>;
|
||||
};
|
||||
|
||||
cpu@1 {
|
||||
compatible = "arm,cortex-a9";
|
||||
device_type = "cpu";
|
||||
reg = <1>;
|
||||
next-level-cache = <&L2>;
|
||||
clocks = <&clk_controller 0>;
|
||||
clock-names = "cpu";
|
||||
cpu-supply = <&cpu_supply0>;
|
||||
operating-points-v2 = <&cpu0_opp_table0>;
|
||||
};
|
||||
};
|
||||
|
||||
cpu0_opp_table0: opp-table {
|
||||
compatible = "operating-points-v2";
|
||||
opp-shared;
|
||||
|
||||
opp-1000000000 {
|
||||
opp-hz = /bits/ 64 <1000000000>;
|
||||
opp-microvolt = <975000 970000 985000>;
|
||||
opp-microamp = <70000>;
|
||||
clock-latency-ns = <300000>;
|
||||
opp-suspend;
|
||||
};
|
||||
opp-1100000000 {
|
||||
opp-hz = /bits/ 64 <1100000000>;
|
||||
opp-microvolt = <1000000 980000 1010000>;
|
||||
opp-microamp = <80000>;
|
||||
clock-latency-ns = <310000>;
|
||||
};
|
||||
opp-1200000000 {
|
||||
opp-hz = /bits/ 64 <1200000000>;
|
||||
opp-microvolt = <1025000>;
|
||||
clock-latency-ns = <290000>;
|
||||
turbo-mode;
|
||||
};
|
||||
};
|
||||
|
||||
- |
|
||||
/*
|
||||
* Example 2: Single cluster, Quad-core Qualcom-krait, switches DVFS states
|
||||
* independently.
|
||||
*/
|
||||
cpus {
|
||||
#address-cells = <1>;
|
||||
#size-cells = <0>;
|
||||
|
||||
cpu@0 {
|
||||
compatible = "qcom,krait";
|
||||
device_type = "cpu";
|
||||
reg = <0>;
|
||||
next-level-cache = <&L2>;
|
||||
clocks = <&clk_controller 0>;
|
||||
clock-names = "cpu";
|
||||
cpu-supply = <&cpu_supply0>;
|
||||
operating-points-v2 = <&cpu_opp_table>;
|
||||
};
|
||||
|
||||
cpu@1 {
|
||||
compatible = "qcom,krait";
|
||||
device_type = "cpu";
|
||||
reg = <1>;
|
||||
next-level-cache = <&L2>;
|
||||
clocks = <&clk_controller 1>;
|
||||
clock-names = "cpu";
|
||||
cpu-supply = <&cpu_supply1>;
|
||||
operating-points-v2 = <&cpu_opp_table>;
|
||||
};
|
||||
|
||||
cpu@2 {
|
||||
compatible = "qcom,krait";
|
||||
device_type = "cpu";
|
||||
reg = <2>;
|
||||
next-level-cache = <&L2>;
|
||||
clocks = <&clk_controller 2>;
|
||||
clock-names = "cpu";
|
||||
cpu-supply = <&cpu_supply2>;
|
||||
operating-points-v2 = <&cpu_opp_table>;
|
||||
};
|
||||
|
||||
cpu@3 {
|
||||
compatible = "qcom,krait";
|
||||
device_type = "cpu";
|
||||
reg = <3>;
|
||||
next-level-cache = <&L2>;
|
||||
clocks = <&clk_controller 3>;
|
||||
clock-names = "cpu";
|
||||
cpu-supply = <&cpu_supply3>;
|
||||
operating-points-v2 = <&cpu_opp_table>;
|
||||
};
|
||||
};
|
||||
|
||||
cpu_opp_table: opp-table {
|
||||
compatible = "operating-points-v2";
|
||||
|
||||
/*
|
||||
* Missing opp-shared property means CPUs switch DVFS states
|
||||
* independently.
|
||||
*/
|
||||
|
||||
opp-1000000000 {
|
||||
opp-hz = /bits/ 64 <1000000000>;
|
||||
opp-microvolt = <975000 970000 985000>;
|
||||
opp-microamp = <70000>;
|
||||
clock-latency-ns = <300000>;
|
||||
opp-suspend;
|
||||
};
|
||||
opp-1100000000 {
|
||||
opp-hz = /bits/ 64 <1100000000>;
|
||||
opp-microvolt = <1000000 980000 1010000>;
|
||||
opp-microamp = <80000>;
|
||||
clock-latency-ns = <310000>;
|
||||
};
|
||||
opp-1200000000 {
|
||||
opp-hz = /bits/ 64 <1200000000>;
|
||||
opp-microvolt = <1025000>;
|
||||
opp-microamp = <90000>;
|
||||
lock-latency-ns = <290000>;
|
||||
turbo-mode;
|
||||
};
|
||||
};
|
||||
|
||||
- |
|
||||
/*
|
||||
* Example 3: Dual-cluster, Dual-core per cluster. CPUs within a cluster switch
|
||||
* DVFS state together.
|
||||
*/
|
||||
cpus {
|
||||
#address-cells = <1>;
|
||||
#size-cells = <0>;
|
||||
|
||||
cpu@0 {
|
||||
compatible = "arm,cortex-a7";
|
||||
device_type = "cpu";
|
||||
reg = <0>;
|
||||
next-level-cache = <&L2>;
|
||||
clocks = <&clk_controller 0>;
|
||||
clock-names = "cpu";
|
||||
cpu-supply = <&cpu_supply0>;
|
||||
operating-points-v2 = <&cluster0_opp>;
|
||||
};
|
||||
|
||||
cpu@1 {
|
||||
compatible = "arm,cortex-a7";
|
||||
device_type = "cpu";
|
||||
reg = <1>;
|
||||
next-level-cache = <&L2>;
|
||||
clocks = <&clk_controller 0>;
|
||||
clock-names = "cpu";
|
||||
cpu-supply = <&cpu_supply0>;
|
||||
operating-points-v2 = <&cluster0_opp>;
|
||||
};
|
||||
|
||||
cpu@100 {
|
||||
compatible = "arm,cortex-a15";
|
||||
device_type = "cpu";
|
||||
reg = <100>;
|
||||
next-level-cache = <&L2>;
|
||||
clocks = <&clk_controller 1>;
|
||||
clock-names = "cpu";
|
||||
cpu-supply = <&cpu_supply1>;
|
||||
operating-points-v2 = <&cluster1_opp>;
|
||||
};
|
||||
|
||||
cpu@101 {
|
||||
compatible = "arm,cortex-a15";
|
||||
device_type = "cpu";
|
||||
reg = <101>;
|
||||
next-level-cache = <&L2>;
|
||||
clocks = <&clk_controller 1>;
|
||||
clock-names = "cpu";
|
||||
cpu-supply = <&cpu_supply1>;
|
||||
operating-points-v2 = <&cluster1_opp>;
|
||||
};
|
||||
};
|
||||
|
||||
cluster0_opp: opp-table-0 {
|
||||
compatible = "operating-points-v2";
|
||||
opp-shared;
|
||||
|
||||
opp-1000000000 {
|
||||
opp-hz = /bits/ 64 <1000000000>;
|
||||
opp-microvolt = <975000 970000 985000>;
|
||||
opp-microamp = <70000>;
|
||||
clock-latency-ns = <300000>;
|
||||
opp-suspend;
|
||||
};
|
||||
opp-1100000000 {
|
||||
opp-hz = /bits/ 64 <1100000000>;
|
||||
opp-microvolt = <1000000 980000 1010000>;
|
||||
opp-microamp = <80000>;
|
||||
clock-latency-ns = <310000>;
|
||||
};
|
||||
opp-1200000000 {
|
||||
opp-hz = /bits/ 64 <1200000000>;
|
||||
opp-microvolt = <1025000>;
|
||||
opp-microamp = <90000>;
|
||||
clock-latency-ns = <290000>;
|
||||
turbo-mode;
|
||||
};
|
||||
};
|
||||
|
||||
cluster1_opp: opp-table-1 {
|
||||
compatible = "operating-points-v2";
|
||||
opp-shared;
|
||||
|
||||
opp-1300000000 {
|
||||
opp-hz = /bits/ 64 <1300000000>;
|
||||
opp-microvolt = <1050000 1045000 1055000>;
|
||||
opp-microamp = <95000>;
|
||||
clock-latency-ns = <400000>;
|
||||
opp-suspend;
|
||||
};
|
||||
opp-1400000000 {
|
||||
opp-hz = /bits/ 64 <1400000000>;
|
||||
opp-microvolt = <1075000>;
|
||||
opp-microamp = <100000>;
|
||||
clock-latency-ns = <400000>;
|
||||
};
|
||||
opp-1500000000 {
|
||||
opp-hz = /bits/ 64 <1500000000>;
|
||||
opp-microvolt = <1100000 1010000 1110000>;
|
||||
opp-microamp = <95000>;
|
||||
clock-latency-ns = <400000>;
|
||||
turbo-mode;
|
||||
};
|
||||
};
|
||||
|
||||
- |
|
||||
/* Example 4: Handling multiple regulators */
|
||||
cpus {
|
||||
#address-cells = <1>;
|
||||
#size-cells = <0>;
|
||||
|
||||
cpu@0 {
|
||||
compatible = "foo,cpu-type";
|
||||
device_type = "cpu";
|
||||
reg = <0>;
|
||||
|
||||
vcc0-supply = <&cpu_supply0>;
|
||||
vcc1-supply = <&cpu_supply1>;
|
||||
vcc2-supply = <&cpu_supply2>;
|
||||
operating-points-v2 = <&cpu0_opp_table4>;
|
||||
};
|
||||
};
|
||||
|
||||
cpu0_opp_table4: opp-table-0 {
|
||||
compatible = "operating-points-v2";
|
||||
opp-shared;
|
||||
|
||||
opp-1000000000 {
|
||||
opp-hz = /bits/ 64 <1000000000>;
|
||||
opp-microvolt = <970000>, /* Supply 0 */
|
||||
<960000>, /* Supply 1 */
|
||||
<960000>; /* Supply 2 */
|
||||
opp-microamp = <70000>, /* Supply 0 */
|
||||
<70000>, /* Supply 1 */
|
||||
<70000>; /* Supply 2 */
|
||||
clock-latency-ns = <300000>;
|
||||
};
|
||||
|
||||
/* OR */
|
||||
|
||||
opp-1000000001 {
|
||||
opp-hz = /bits/ 64 <1000000001>;
|
||||
opp-microvolt = <975000 970000 985000>, /* Supply 0 */
|
||||
<965000 960000 975000>, /* Supply 1 */
|
||||
<965000 960000 975000>; /* Supply 2 */
|
||||
opp-microamp = <70000>, /* Supply 0 */
|
||||
<70000>, /* Supply 1 */
|
||||
<70000>; /* Supply 2 */
|
||||
clock-latency-ns = <300000>;
|
||||
};
|
||||
|
||||
/* OR */
|
||||
|
||||
opp-1000000002 {
|
||||
opp-hz = /bits/ 64 <1000000002>;
|
||||
opp-microvolt = <975000 970000 985000>, /* Supply 0 */
|
||||
<965000 960000 975000>, /* Supply 1 */
|
||||
<965000 960000 975000>; /* Supply 2 */
|
||||
opp-microamp = <70000>, /* Supply 0 */
|
||||
<0>, /* Supply 1 doesn't need this */
|
||||
<70000>; /* Supply 2 */
|
||||
clock-latency-ns = <300000>;
|
||||
};
|
||||
};
|
||||
|
||||
- |
|
||||
/*
|
||||
* Example 5: opp-supported-hw
|
||||
* (example: three level hierarchy of versions: cuts, substrate and process)
|
||||
*/
|
||||
cpus {
|
||||
#address-cells = <1>;
|
||||
#size-cells = <0>;
|
||||
|
||||
cpu@0 {
|
||||
compatible = "arm,cortex-a7";
|
||||
device_type = "cpu";
|
||||
reg = <0>;
|
||||
cpu-supply = <&cpu_supply>;
|
||||
operating-points-v2 = <&cpu0_opp_table_slow>;
|
||||
};
|
||||
};
|
||||
|
||||
cpu0_opp_table_slow: opp-table {
|
||||
compatible = "operating-points-v2";
|
||||
opp-shared;
|
||||
|
||||
opp-600000000 {
|
||||
/*
|
||||
* Supports all substrate and process versions for 0xF
|
||||
* cuts, i.e. only first four cuts.
|
||||
*/
|
||||
opp-supported-hw = <0xF 0xFFFFFFFF 0xFFFFFFFF>;
|
||||
opp-hz = /bits/ 64 <600000000>;
|
||||
};
|
||||
|
||||
opp-800000000 {
|
||||
/*
|
||||
* Supports:
|
||||
* - cuts: only one, 6th cut (represented by 6th bit).
|
||||
* - substrate: supports 16 different substrate versions
|
||||
* - process: supports 9 different process versions
|
||||
*/
|
||||
opp-supported-hw = <0x20 0xff0000ff 0x0000f4f0>;
|
||||
opp-hz = /bits/ 64 <800000000>;
|
||||
};
|
||||
|
||||
opp-900000000 {
|
||||
/*
|
||||
* Supports:
|
||||
* - All cuts and substrate where process version is 0x2.
|
||||
* - All cuts and process where substrate version is 0x2.
|
||||
*/
|
||||
opp-supported-hw = <0xFFFFFFFF 0xFFFFFFFF 0x02>,
|
||||
<0xFFFFFFFF 0x01 0xFFFFFFFF>;
|
||||
opp-hz = /bits/ 64 <900000000>;
|
||||
};
|
||||
};
|
||||
|
||||
- |
|
||||
/*
|
||||
* Example 6: opp-microvolt-<name>, opp-microamp-<name>:
|
||||
* (example: device with two possible microvolt ranges: slow and fast)
|
||||
*/
|
||||
cpus {
|
||||
#address-cells = <1>;
|
||||
#size-cells = <0>;
|
||||
|
||||
cpu@0 {
|
||||
compatible = "arm,cortex-a7";
|
||||
device_type = "cpu";
|
||||
reg = <0>;
|
||||
operating-points-v2 = <&cpu0_opp_table6>;
|
||||
};
|
||||
};
|
||||
|
||||
cpu0_opp_table6: opp-table-0 {
|
||||
compatible = "operating-points-v2";
|
||||
opp-shared;
|
||||
|
||||
opp-1000000000 {
|
||||
opp-hz = /bits/ 64 <1000000000>;
|
||||
opp-microvolt-slow = <915000 900000 925000>;
|
||||
opp-microvolt-fast = <975000 970000 985000>;
|
||||
opp-microamp-slow = <70000>;
|
||||
opp-microamp-fast = <71000>;
|
||||
};
|
||||
|
||||
opp-1200000000 {
|
||||
opp-hz = /bits/ 64 <1200000000>;
|
||||
opp-microvolt-slow = <915000 900000 925000>, /* Supply vcc0 */
|
||||
<925000 910000 935000>; /* Supply vcc1 */
|
||||
opp-microvolt-fast = <975000 970000 985000>, /* Supply vcc0 */
|
||||
<965000 960000 975000>; /* Supply vcc1 */
|
||||
opp-microamp = <70000>; /* Will be used for both slow/fast */
|
||||
};
|
||||
};
|
||||
|
||||
- |
|
||||
/*
|
||||
* Example 7: Single cluster Quad-core ARM cortex A53, OPP points from firmware,
|
||||
* distinct clock controls but two sets of clock/voltage/current lines.
|
||||
*/
|
||||
cpus {
|
||||
#address-cells = <2>;
|
||||
#size-cells = <0>;
|
||||
|
||||
cpu@0 {
|
||||
compatible = "arm,cortex-a53";
|
||||
device_type = "cpu";
|
||||
reg = <0x0 0x100>;
|
||||
next-level-cache = <&A53_L2>;
|
||||
clocks = <&dvfs_controller 0>;
|
||||
operating-points-v2 = <&cpu_opp0_table>;
|
||||
};
|
||||
cpu@1 {
|
||||
compatible = "arm,cortex-a53";
|
||||
device_type = "cpu";
|
||||
reg = <0x0 0x101>;
|
||||
next-level-cache = <&A53_L2>;
|
||||
clocks = <&dvfs_controller 1>;
|
||||
operating-points-v2 = <&cpu_opp0_table>;
|
||||
};
|
||||
cpu@2 {
|
||||
compatible = "arm,cortex-a53";
|
||||
device_type = "cpu";
|
||||
reg = <0x0 0x102>;
|
||||
next-level-cache = <&A53_L2>;
|
||||
clocks = <&dvfs_controller 2>;
|
||||
operating-points-v2 = <&cpu_opp1_table>;
|
||||
};
|
||||
cpu@3 {
|
||||
compatible = "arm,cortex-a53";
|
||||
device_type = "cpu";
|
||||
reg = <0x0 0x103>;
|
||||
next-level-cache = <&A53_L2>;
|
||||
clocks = <&dvfs_controller 3>;
|
||||
operating-points-v2 = <&cpu_opp1_table>;
|
||||
};
|
||||
|
||||
};
|
||||
|
||||
cpu_opp0_table: opp-table-0 {
|
||||
compatible = "operating-points-v2";
|
||||
opp-shared;
|
||||
};
|
||||
|
||||
cpu_opp1_table: opp-table-1 {
|
||||
compatible = "operating-points-v2";
|
||||
opp-shared;
|
||||
};
|
||||
...
|
||||
|
|
@ -1,622 +0,0 @@
|
|||
Generic OPP (Operating Performance Points) Bindings
|
||||
----------------------------------------------------
|
||||
|
||||
Devices work at voltage-current-frequency combinations and some implementations
|
||||
have the liberty of choosing these. These combinations are called Operating
|
||||
Performance Points aka OPPs. This document defines bindings for these OPPs
|
||||
applicable across wide range of devices. For illustration purpose, this document
|
||||
uses CPU as a device.
|
||||
|
||||
This document contain multiple versions of OPP binding and only one of them
|
||||
should be used per device.
|
||||
|
||||
Binding 1: operating-points
|
||||
============================
|
||||
|
||||
This binding only supports voltage-frequency pairs.
|
||||
|
||||
Properties:
|
||||
- operating-points: An array of 2-tuples items, and each item consists
|
||||
of frequency and voltage like <freq-kHz vol-uV>.
|
||||
freq: clock frequency in kHz
|
||||
vol: voltage in microvolt
|
||||
|
||||
Examples:
|
||||
|
||||
cpu@0 {
|
||||
compatible = "arm,cortex-a9";
|
||||
reg = <0>;
|
||||
next-level-cache = <&L2>;
|
||||
operating-points = <
|
||||
/* kHz uV */
|
||||
792000 1100000
|
||||
396000 950000
|
||||
198000 850000
|
||||
>;
|
||||
};
|
||||
|
||||
|
||||
Binding 2: operating-points-v2
|
||||
============================
|
||||
|
||||
* Property: operating-points-v2
|
||||
|
||||
Devices supporting OPPs must set their "operating-points-v2" property with
|
||||
phandle to a OPP table in their DT node. The OPP core will use this phandle to
|
||||
find the operating points for the device.
|
||||
|
||||
This can contain more than one phandle for power domain providers that provide
|
||||
multiple power domains. That is, one phandle for each power domain. If only one
|
||||
phandle is available, then the same OPP table will be used for all power domains
|
||||
provided by the power domain provider.
|
||||
|
||||
If required, this can be extended for SoC vendor specific bindings. Such bindings
|
||||
should be documented as Documentation/devicetree/bindings/power/<vendor>-opp.txt
|
||||
and should have a compatible description like: "operating-points-v2-<vendor>".
|
||||
|
||||
* OPP Table Node
|
||||
|
||||
This describes the OPPs belonging to a device. This node can have following
|
||||
properties:
|
||||
|
||||
Required properties:
|
||||
- compatible: Allow OPPs to express their compatibility. It should be:
|
||||
"operating-points-v2".
|
||||
|
||||
- OPP nodes: One or more OPP nodes describing voltage-current-frequency
|
||||
combinations. Their name isn't significant but their phandle can be used to
|
||||
reference an OPP. These are mandatory except for the case where the OPP table
|
||||
is present only to indicate dependency between devices using the opp-shared
|
||||
property.
|
||||
|
||||
Optional properties:
|
||||
- opp-shared: Indicates that device nodes using this OPP Table Node's phandle
|
||||
switch their DVFS state together, i.e. they share clock/voltage/current lines.
|
||||
Missing property means devices have independent clock/voltage/current lines,
|
||||
but they share OPP tables.
|
||||
|
||||
- status: Marks the OPP table enabled/disabled.
|
||||
|
||||
|
||||
* OPP Node
|
||||
|
||||
This defines voltage-current-frequency combinations along with other related
|
||||
properties.
|
||||
|
||||
Required properties:
|
||||
- opp-hz: Frequency in Hz, expressed as a 64-bit big-endian integer. This is a
|
||||
required property for all device nodes, unless another "required" property to
|
||||
uniquely identify the OPP nodes exists. Devices like power domains must have
|
||||
another (implementation dependent) property.
|
||||
|
||||
- opp-peak-kBps: Peak bandwidth in kilobytes per second, expressed as an array
|
||||
of 32-bit big-endian integers. Each element of the array represents the
|
||||
peak bandwidth value of each interconnect path. The number of elements should
|
||||
match the number of interconnect paths.
|
||||
|
||||
Optional properties:
|
||||
- opp-microvolt: voltage in micro Volts.
|
||||
|
||||
A single regulator's voltage is specified with an array of size one or three.
|
||||
Single entry is for target voltage and three entries are for <target min max>
|
||||
voltages.
|
||||
|
||||
Entries for multiple regulators shall be provided in the same field separated
|
||||
by angular brackets <>. The OPP binding doesn't provide any provisions to
|
||||
relate the values to their power supplies or the order in which the supplies
|
||||
need to be configured and that is left for the implementation specific
|
||||
binding.
|
||||
|
||||
Entries for all regulators shall be of the same size, i.e. either all use a
|
||||
single value or triplets.
|
||||
|
||||
- opp-microvolt-<name>: Named opp-microvolt property. This is exactly similar to
|
||||
the above opp-microvolt property, but allows multiple voltage ranges to be
|
||||
provided for the same OPP. At runtime, the platform can pick a <name> and
|
||||
matching opp-microvolt-<name> property will be enabled for all OPPs. If the
|
||||
platform doesn't pick a specific <name> or the <name> doesn't match with any
|
||||
opp-microvolt-<name> properties, then opp-microvolt property shall be used, if
|
||||
present.
|
||||
|
||||
- opp-microamp: The maximum current drawn by the device in microamperes
|
||||
considering system specific parameters (such as transients, process, aging,
|
||||
maximum operating temperature range etc.) as necessary. This may be used to
|
||||
set the most efficient regulator operating mode.
|
||||
|
||||
Should only be set if opp-microvolt is set for the OPP.
|
||||
|
||||
Entries for multiple regulators shall be provided in the same field separated
|
||||
by angular brackets <>. If current values aren't required for a regulator,
|
||||
then it shall be filled with 0. If current values aren't required for any of
|
||||
the regulators, then this field is not required. The OPP binding doesn't
|
||||
provide any provisions to relate the values to their power supplies or the
|
||||
order in which the supplies need to be configured and that is left for the
|
||||
implementation specific binding.
|
||||
|
||||
- opp-microamp-<name>: Named opp-microamp property. Similar to
|
||||
opp-microvolt-<name> property, but for microamp instead.
|
||||
|
||||
- opp-level: A value representing the performance level of the device,
|
||||
expressed as a 32-bit integer.
|
||||
|
||||
- opp-avg-kBps: Average bandwidth in kilobytes per second, expressed as an array
|
||||
of 32-bit big-endian integers. Each element of the array represents the
|
||||
average bandwidth value of each interconnect path. The number of elements
|
||||
should match the number of interconnect paths. This property is only
|
||||
meaningful in OPP tables where opp-peak-kBps is present.
|
||||
|
||||
- clock-latency-ns: Specifies the maximum possible transition latency (in
|
||||
nanoseconds) for switching to this OPP from any other OPP.
|
||||
|
||||
- turbo-mode: Marks the OPP to be used only for turbo modes. Turbo mode is
|
||||
available on some platforms, where the device can run over its operating
|
||||
frequency for a short duration of time limited by the device's power, current
|
||||
and thermal limits.
|
||||
|
||||
- opp-suspend: Marks the OPP to be used during device suspend. If multiple OPPs
|
||||
in the table have this, the OPP with highest opp-hz will be used.
|
||||
|
||||
- opp-supported-hw: This property allows a platform to enable only a subset of
|
||||
the OPPs from the larger set present in the OPP table, based on the current
|
||||
version of the hardware (already known to the operating system).
|
||||
|
||||
Each block present in the array of blocks in this property, represents a
|
||||
sub-group of hardware versions supported by the OPP. i.e. <sub-group A>,
|
||||
<sub-group B>, etc. The OPP will be enabled if _any_ of these sub-groups match
|
||||
the hardware's version.
|
||||
|
||||
Each sub-group is a platform defined array representing the hierarchy of
|
||||
hardware versions supported by the platform. For a platform with three
|
||||
hierarchical levels of version (X.Y.Z), this field shall look like
|
||||
|
||||
opp-supported-hw = <X1 Y1 Z1>, <X2 Y2 Z2>, <X3 Y3 Z3>.
|
||||
|
||||
Each level (eg. X1) in version hierarchy is represented by a 32 bit value, one
|
||||
bit per version and so there can be maximum 32 versions per level. Logical AND
|
||||
(&) operation is performed for each level with the hardware's level version
|
||||
and a non-zero output for _all_ the levels in a sub-group means the OPP is
|
||||
supported by hardware. A value of 0xFFFFFFFF for each level in the sub-group
|
||||
will enable the OPP for all versions for the hardware.
|
||||
|
||||
- status: Marks the node enabled/disabled.
|
||||
|
||||
- required-opps: This contains phandle to an OPP node in another device's OPP
|
||||
table. It may contain an array of phandles, where each phandle points to an
|
||||
OPP of a different device. It should not contain multiple phandles to the OPP
|
||||
nodes in the same OPP table. This specifies the minimum required OPP of the
|
||||
device(s), whose OPP's phandle is present in this property, for the
|
||||
functioning of the current device at the current OPP (where this property is
|
||||
present).
|
||||
|
||||
Example 1: Single cluster Dual-core ARM cortex A9, switch DVFS states together.
|
||||
|
||||
/ {
|
||||
cpus {
|
||||
#address-cells = <1>;
|
||||
#size-cells = <0>;
|
||||
|
||||
cpu@0 {
|
||||
compatible = "arm,cortex-a9";
|
||||
reg = <0>;
|
||||
next-level-cache = <&L2>;
|
||||
clocks = <&clk_controller 0>;
|
||||
clock-names = "cpu";
|
||||
cpu-supply = <&cpu_supply0>;
|
||||
operating-points-v2 = <&cpu0_opp_table>;
|
||||
};
|
||||
|
||||
cpu@1 {
|
||||
compatible = "arm,cortex-a9";
|
||||
reg = <1>;
|
||||
next-level-cache = <&L2>;
|
||||
clocks = <&clk_controller 0>;
|
||||
clock-names = "cpu";
|
||||
cpu-supply = <&cpu_supply0>;
|
||||
operating-points-v2 = <&cpu0_opp_table>;
|
||||
};
|
||||
};
|
||||
|
||||
cpu0_opp_table: opp_table0 {
|
||||
compatible = "operating-points-v2";
|
||||
opp-shared;
|
||||
|
||||
opp-1000000000 {
|
||||
opp-hz = /bits/ 64 <1000000000>;
|
||||
opp-microvolt = <975000 970000 985000>;
|
||||
opp-microamp = <70000>;
|
||||
clock-latency-ns = <300000>;
|
||||
opp-suspend;
|
||||
};
|
||||
opp-1100000000 {
|
||||
opp-hz = /bits/ 64 <1100000000>;
|
||||
opp-microvolt = <1000000 980000 1010000>;
|
||||
opp-microamp = <80000>;
|
||||
clock-latency-ns = <310000>;
|
||||
};
|
||||
opp-1200000000 {
|
||||
opp-hz = /bits/ 64 <1200000000>;
|
||||
opp-microvolt = <1025000>;
|
||||
clock-latency-ns = <290000>;
|
||||
turbo-mode;
|
||||
};
|
||||
};
|
||||
};
|
||||
|
||||
Example 2: Single cluster, Quad-core Qualcom-krait, switches DVFS states
|
||||
independently.
|
||||
|
||||
/ {
|
||||
cpus {
|
||||
#address-cells = <1>;
|
||||
#size-cells = <0>;
|
||||
|
||||
cpu@0 {
|
||||
compatible = "qcom,krait";
|
||||
reg = <0>;
|
||||
next-level-cache = <&L2>;
|
||||
clocks = <&clk_controller 0>;
|
||||
clock-names = "cpu";
|
||||
cpu-supply = <&cpu_supply0>;
|
||||
operating-points-v2 = <&cpu_opp_table>;
|
||||
};
|
||||
|
||||
cpu@1 {
|
||||
compatible = "qcom,krait";
|
||||
reg = <1>;
|
||||
next-level-cache = <&L2>;
|
||||
clocks = <&clk_controller 1>;
|
||||
clock-names = "cpu";
|
||||
cpu-supply = <&cpu_supply1>;
|
||||
operating-points-v2 = <&cpu_opp_table>;
|
||||
};
|
||||
|
||||
cpu@2 {
|
||||
compatible = "qcom,krait";
|
||||
reg = <2>;
|
||||
next-level-cache = <&L2>;
|
||||
clocks = <&clk_controller 2>;
|
||||
clock-names = "cpu";
|
||||
cpu-supply = <&cpu_supply2>;
|
||||
operating-points-v2 = <&cpu_opp_table>;
|
||||
};
|
||||
|
||||
cpu@3 {
|
||||
compatible = "qcom,krait";
|
||||
reg = <3>;
|
||||
next-level-cache = <&L2>;
|
||||
clocks = <&clk_controller 3>;
|
||||
clock-names = "cpu";
|
||||
cpu-supply = <&cpu_supply3>;
|
||||
operating-points-v2 = <&cpu_opp_table>;
|
||||
};
|
||||
};
|
||||
|
||||
cpu_opp_table: opp_table {
|
||||
compatible = "operating-points-v2";
|
||||
|
||||
/*
|
||||
* Missing opp-shared property means CPUs switch DVFS states
|
||||
* independently.
|
||||
*/
|
||||
|
||||
opp-1000000000 {
|
||||
opp-hz = /bits/ 64 <1000000000>;
|
||||
opp-microvolt = <975000 970000 985000>;
|
||||
opp-microamp = <70000>;
|
||||
clock-latency-ns = <300000>;
|
||||
opp-suspend;
|
||||
};
|
||||
opp-1100000000 {
|
||||
opp-hz = /bits/ 64 <1100000000>;
|
||||
opp-microvolt = <1000000 980000 1010000>;
|
||||
opp-microamp = <80000>;
|
||||
clock-latency-ns = <310000>;
|
||||
};
|
||||
opp-1200000000 {
|
||||
opp-hz = /bits/ 64 <1200000000>;
|
||||
opp-microvolt = <1025000>;
|
||||
opp-microamp = <90000;
|
||||
lock-latency-ns = <290000>;
|
||||
turbo-mode;
|
||||
};
|
||||
};
|
||||
};
|
||||
|
||||
Example 3: Dual-cluster, Dual-core per cluster. CPUs within a cluster switch
|
||||
DVFS state together.
|
||||
|
||||
/ {
|
||||
cpus {
|
||||
#address-cells = <1>;
|
||||
#size-cells = <0>;
|
||||
|
||||
cpu@0 {
|
||||
compatible = "arm,cortex-a7";
|
||||
reg = <0>;
|
||||
next-level-cache = <&L2>;
|
||||
clocks = <&clk_controller 0>;
|
||||
clock-names = "cpu";
|
||||
cpu-supply = <&cpu_supply0>;
|
||||
operating-points-v2 = <&cluster0_opp>;
|
||||
};
|
||||
|
||||
cpu@1 {
|
||||
compatible = "arm,cortex-a7";
|
||||
reg = <1>;
|
||||
next-level-cache = <&L2>;
|
||||
clocks = <&clk_controller 0>;
|
||||
clock-names = "cpu";
|
||||
cpu-supply = <&cpu_supply0>;
|
||||
operating-points-v2 = <&cluster0_opp>;
|
||||
};
|
||||
|
||||
cpu@100 {
|
||||
compatible = "arm,cortex-a15";
|
||||
reg = <100>;
|
||||
next-level-cache = <&L2>;
|
||||
clocks = <&clk_controller 1>;
|
||||
clock-names = "cpu";
|
||||
cpu-supply = <&cpu_supply1>;
|
||||
operating-points-v2 = <&cluster1_opp>;
|
||||
};
|
||||
|
||||
cpu@101 {
|
||||
compatible = "arm,cortex-a15";
|
||||
reg = <101>;
|
||||
next-level-cache = <&L2>;
|
||||
clocks = <&clk_controller 1>;
|
||||
clock-names = "cpu";
|
||||
cpu-supply = <&cpu_supply1>;
|
||||
operating-points-v2 = <&cluster1_opp>;
|
||||
};
|
||||
};
|
||||
|
||||
cluster0_opp: opp_table0 {
|
||||
compatible = "operating-points-v2";
|
||||
opp-shared;
|
||||
|
||||
opp-1000000000 {
|
||||
opp-hz = /bits/ 64 <1000000000>;
|
||||
opp-microvolt = <975000 970000 985000>;
|
||||
opp-microamp = <70000>;
|
||||
clock-latency-ns = <300000>;
|
||||
opp-suspend;
|
||||
};
|
||||
opp-1100000000 {
|
||||
opp-hz = /bits/ 64 <1100000000>;
|
||||
opp-microvolt = <1000000 980000 1010000>;
|
||||
opp-microamp = <80000>;
|
||||
clock-latency-ns = <310000>;
|
||||
};
|
||||
opp-1200000000 {
|
||||
opp-hz = /bits/ 64 <1200000000>;
|
||||
opp-microvolt = <1025000>;
|
||||
opp-microamp = <90000>;
|
||||
clock-latency-ns = <290000>;
|
||||
turbo-mode;
|
||||
};
|
||||
};
|
||||
|
||||
cluster1_opp: opp_table1 {
|
||||
compatible = "operating-points-v2";
|
||||
opp-shared;
|
||||
|
||||
opp-1300000000 {
|
||||
opp-hz = /bits/ 64 <1300000000>;
|
||||
opp-microvolt = <1050000 1045000 1055000>;
|
||||
opp-microamp = <95000>;
|
||||
clock-latency-ns = <400000>;
|
||||
opp-suspend;
|
||||
};
|
||||
opp-1400000000 {
|
||||
opp-hz = /bits/ 64 <1400000000>;
|
||||
opp-microvolt = <1075000>;
|
||||
opp-microamp = <100000>;
|
||||
clock-latency-ns = <400000>;
|
||||
};
|
||||
opp-1500000000 {
|
||||
opp-hz = /bits/ 64 <1500000000>;
|
||||
opp-microvolt = <1100000 1010000 1110000>;
|
||||
opp-microamp = <95000>;
|
||||
clock-latency-ns = <400000>;
|
||||
turbo-mode;
|
||||
};
|
||||
};
|
||||
};
|
||||
|
||||
Example 4: Handling multiple regulators
|
||||
|
||||
/ {
|
||||
cpus {
|
||||
cpu@0 {
|
||||
compatible = "vendor,cpu-type";
|
||||
...
|
||||
|
||||
vcc0-supply = <&cpu_supply0>;
|
||||
vcc1-supply = <&cpu_supply1>;
|
||||
vcc2-supply = <&cpu_supply2>;
|
||||
operating-points-v2 = <&cpu0_opp_table>;
|
||||
};
|
||||
};
|
||||
|
||||
cpu0_opp_table: opp_table0 {
|
||||
compatible = "operating-points-v2";
|
||||
opp-shared;
|
||||
|
||||
opp-1000000000 {
|
||||
opp-hz = /bits/ 64 <1000000000>;
|
||||
opp-microvolt = <970000>, /* Supply 0 */
|
||||
<960000>, /* Supply 1 */
|
||||
<960000>; /* Supply 2 */
|
||||
opp-microamp = <70000>, /* Supply 0 */
|
||||
<70000>, /* Supply 1 */
|
||||
<70000>; /* Supply 2 */
|
||||
clock-latency-ns = <300000>;
|
||||
};
|
||||
|
||||
/* OR */
|
||||
|
||||
opp-1000000000 {
|
||||
opp-hz = /bits/ 64 <1000000000>;
|
||||
opp-microvolt = <975000 970000 985000>, /* Supply 0 */
|
||||
<965000 960000 975000>, /* Supply 1 */
|
||||
<965000 960000 975000>; /* Supply 2 */
|
||||
opp-microamp = <70000>, /* Supply 0 */
|
||||
<70000>, /* Supply 1 */
|
||||
<70000>; /* Supply 2 */
|
||||
clock-latency-ns = <300000>;
|
||||
};
|
||||
|
||||
/* OR */
|
||||
|
||||
opp-1000000000 {
|
||||
opp-hz = /bits/ 64 <1000000000>;
|
||||
opp-microvolt = <975000 970000 985000>, /* Supply 0 */
|
||||
<965000 960000 975000>, /* Supply 1 */
|
||||
<965000 960000 975000>; /* Supply 2 */
|
||||
opp-microamp = <70000>, /* Supply 0 */
|
||||
<0>, /* Supply 1 doesn't need this */
|
||||
<70000>; /* Supply 2 */
|
||||
clock-latency-ns = <300000>;
|
||||
};
|
||||
};
|
||||
};
|
||||
|
||||
Example 5: opp-supported-hw
|
||||
(example: three level hierarchy of versions: cuts, substrate and process)
|
||||
|
||||
/ {
|
||||
cpus {
|
||||
cpu@0 {
|
||||
compatible = "arm,cortex-a7";
|
||||
...
|
||||
|
||||
cpu-supply = <&cpu_supply>
|
||||
operating-points-v2 = <&cpu0_opp_table_slow>;
|
||||
};
|
||||
};
|
||||
|
||||
opp_table {
|
||||
compatible = "operating-points-v2";
|
||||
opp-shared;
|
||||
|
||||
opp-600000000 {
|
||||
/*
|
||||
* Supports all substrate and process versions for 0xF
|
||||
* cuts, i.e. only first four cuts.
|
||||
*/
|
||||
opp-supported-hw = <0xF 0xFFFFFFFF 0xFFFFFFFF>
|
||||
opp-hz = /bits/ 64 <600000000>;
|
||||
...
|
||||
};
|
||||
|
||||
opp-800000000 {
|
||||
/*
|
||||
* Supports:
|
||||
* - cuts: only one, 6th cut (represented by 6th bit).
|
||||
* - substrate: supports 16 different substrate versions
|
||||
* - process: supports 9 different process versions
|
||||
*/
|
||||
opp-supported-hw = <0x20 0xff0000ff 0x0000f4f0>
|
||||
opp-hz = /bits/ 64 <800000000>;
|
||||
...
|
||||
};
|
||||
|
||||
opp-900000000 {
|
||||
/*
|
||||
* Supports:
|
||||
* - All cuts and substrate where process version is 0x2.
|
||||
* - All cuts and process where substrate version is 0x2.
|
||||
*/
|
||||
opp-supported-hw = <0xFFFFFFFF 0xFFFFFFFF 0x02>, <0xFFFFFFFF 0x01 0xFFFFFFFF>
|
||||
opp-hz = /bits/ 64 <900000000>;
|
||||
...
|
||||
};
|
||||
};
|
||||
};
|
||||
|
||||
Example 6: opp-microvolt-<name>, opp-microamp-<name>:
|
||||
(example: device with two possible microvolt ranges: slow and fast)
|
||||
|
||||
/ {
|
||||
cpus {
|
||||
cpu@0 {
|
||||
compatible = "arm,cortex-a7";
|
||||
...
|
||||
|
||||
operating-points-v2 = <&cpu0_opp_table>;
|
||||
};
|
||||
};
|
||||
|
||||
cpu0_opp_table: opp_table0 {
|
||||
compatible = "operating-points-v2";
|
||||
opp-shared;
|
||||
|
||||
opp-1000000000 {
|
||||
opp-hz = /bits/ 64 <1000000000>;
|
||||
opp-microvolt-slow = <915000 900000 925000>;
|
||||
opp-microvolt-fast = <975000 970000 985000>;
|
||||
opp-microamp-slow = <70000>;
|
||||
opp-microamp-fast = <71000>;
|
||||
};
|
||||
|
||||
opp-1200000000 {
|
||||
opp-hz = /bits/ 64 <1200000000>;
|
||||
opp-microvolt-slow = <915000 900000 925000>, /* Supply vcc0 */
|
||||
<925000 910000 935000>; /* Supply vcc1 */
|
||||
opp-microvolt-fast = <975000 970000 985000>, /* Supply vcc0 */
|
||||
<965000 960000 975000>; /* Supply vcc1 */
|
||||
opp-microamp = <70000>; /* Will be used for both slow/fast */
|
||||
};
|
||||
};
|
||||
};
|
||||
|
||||
Example 7: Single cluster Quad-core ARM cortex A53, OPP points from firmware,
|
||||
distinct clock controls but two sets of clock/voltage/current lines.
|
||||
|
||||
/ {
|
||||
cpus {
|
||||
#address-cells = <2>;
|
||||
#size-cells = <0>;
|
||||
|
||||
cpu@0 {
|
||||
compatible = "arm,cortex-a53";
|
||||
reg = <0x0 0x100>;
|
||||
next-level-cache = <&A53_L2>;
|
||||
clocks = <&dvfs_controller 0>;
|
||||
operating-points-v2 = <&cpu_opp0_table>;
|
||||
};
|
||||
cpu@1 {
|
||||
compatible = "arm,cortex-a53";
|
||||
reg = <0x0 0x101>;
|
||||
next-level-cache = <&A53_L2>;
|
||||
clocks = <&dvfs_controller 1>;
|
||||
operating-points-v2 = <&cpu_opp0_table>;
|
||||
};
|
||||
cpu@2 {
|
||||
compatible = "arm,cortex-a53";
|
||||
reg = <0x0 0x102>;
|
||||
next-level-cache = <&A53_L2>;
|
||||
clocks = <&dvfs_controller 2>;
|
||||
operating-points-v2 = <&cpu_opp1_table>;
|
||||
};
|
||||
cpu@3 {
|
||||
compatible = "arm,cortex-a53";
|
||||
reg = <0x0 0x103>;
|
||||
next-level-cache = <&A53_L2>;
|
||||
clocks = <&dvfs_controller 3>;
|
||||
operating-points-v2 = <&cpu_opp1_table>;
|
||||
};
|
||||
|
||||
};
|
||||
|
||||
cpu_opp0_table: opp0_table {
|
||||
compatible = "operating-points-v2";
|
||||
opp-shared;
|
||||
};
|
||||
|
||||
cpu_opp1_table: opp1_table {
|
||||
compatible = "operating-points-v2";
|
||||
opp-shared;
|
||||
};
|
||||
};
|
||||
|
|
@ -1,7 +1,7 @@
|
|||
Qualcomm OPP bindings to describe OPP nodes
|
||||
|
||||
The bindings are based on top of the operating-points-v2 bindings
|
||||
described in Documentation/devicetree/bindings/opp/opp.txt
|
||||
described in Documentation/devicetree/bindings/opp/opp-v2-base.yaml
|
||||
Additional properties are described below.
|
||||
|
||||
* OPP Table Node
|
||||
|
|
|
|||
|
|
@ -13,7 +13,7 @@ regulators to the device that will undergo OPP transitions we can make use
|
|||
of the multi regulator binding that is part of the OPP core described here [1]
|
||||
to describe both regulators needed by the platform.
|
||||
|
||||
[1] Documentation/devicetree/bindings/opp/opp.txt
|
||||
[1] Documentation/devicetree/bindings/opp/opp-v2.yaml
|
||||
|
||||
Required Properties for Device Node:
|
||||
- vdd-supply: phandle to regulator controlling VDD supply
|
||||
|
|
|
|||
|
|
@ -46,7 +46,7 @@ properties:
|
|||
Phandles to the OPP tables of power domains provided by a power domain
|
||||
provider. If the provider provides a single power domain only or all
|
||||
the power domains provided by the provider have identical OPP tables,
|
||||
then this shall contain a single phandle. Refer to ../opp/opp.txt
|
||||
then this shall contain a single phandle. Refer to ../opp/opp-v2-base.yaml
|
||||
for more information.
|
||||
|
||||
"#power-domain-cells":
|
||||
|
|
|
|||
|
|
@ -1,49 +0,0 @@
|
|||
Qualcomm PON Device
|
||||
|
||||
The Power On device for Qualcomm PM8xxx is MFD supporting pwrkey
|
||||
and resin along with the Android reboot-mode.
|
||||
|
||||
This DT node has pwrkey and resin as sub nodes.
|
||||
|
||||
Required Properties:
|
||||
-compatible: Must be one of:
|
||||
"qcom,pm8916-pon"
|
||||
"qcom,pms405-pon"
|
||||
"qcom,pm8998-pon"
|
||||
|
||||
-reg: Specifies the physical address of the pon register
|
||||
|
||||
Optional subnode:
|
||||
-pwrkey: Specifies the subnode pwrkey and should follow the
|
||||
qcom,pm8941-pwrkey.txt description.
|
||||
-resin: Specifies the subnode resin and should follow the
|
||||
qcom,pm8xxx-pwrkey.txt description.
|
||||
|
||||
The rest of the properties should follow the generic reboot-mode description
|
||||
found in reboot-mode.txt
|
||||
|
||||
Example:
|
||||
|
||||
pon@800 {
|
||||
compatible = "qcom,pm8916-pon";
|
||||
|
||||
reg = <0x800>;
|
||||
mode-bootloader = <0x2>;
|
||||
mode-recovery = <0x1>;
|
||||
|
||||
pwrkey {
|
||||
compatible = "qcom,pm8941-pwrkey";
|
||||
interrupts = <0x0 0x8 0 IRQ_TYPE_EDGE_BOTH>;
|
||||
debounce = <15625>;
|
||||
bias-pull-up;
|
||||
linux,code = <KEY_POWER>;
|
||||
};
|
||||
|
||||
resin {
|
||||
compatible = "qcom,pm8941-resin";
|
||||
interrupts = <0x0 0x8 1 IRQ_TYPE_EDGE_BOTH>;
|
||||
debounce = <15625>;
|
||||
bias-pull-up;
|
||||
linux,code = <KEY_VOLUMEDOWN>;
|
||||
};
|
||||
};
|
||||
|
|
@ -0,0 +1,80 @@
|
|||
# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
|
||||
%YAML 1.2
|
||||
---
|
||||
$id: http://devicetree.org/schemas/power/reset/qcom,pon.yaml#
|
||||
$schema: http://devicetree.org/meta-schemas/core.yaml#
|
||||
|
||||
title: Qualcomm PON Device
|
||||
|
||||
maintainers:
|
||||
- Vinod Koul <vkoul@kernel.org>
|
||||
|
||||
description: |
|
||||
The Power On device for Qualcomm PM8xxx is MFD supporting pwrkey
|
||||
and resin along with the Android reboot-mode.
|
||||
|
||||
This DT node has pwrkey and resin as sub nodes.
|
||||
|
||||
allOf:
|
||||
- $ref: reboot-mode.yaml#
|
||||
|
||||
properties:
|
||||
compatible:
|
||||
enum:
|
||||
- qcom,pm8916-pon
|
||||
- qcom,pms405-pon
|
||||
- qcom,pm8998-pon
|
||||
|
||||
reg:
|
||||
maxItems: 1
|
||||
|
||||
pwrkey:
|
||||
type: object
|
||||
$ref: "../../input/qcom,pm8941-pwrkey.yaml#"
|
||||
|
||||
resin:
|
||||
type: object
|
||||
$ref: "../../input/qcom,pm8941-pwrkey.yaml#"
|
||||
|
||||
required:
|
||||
- compatible
|
||||
- reg
|
||||
|
||||
unevaluatedProperties: false
|
||||
|
||||
examples:
|
||||
- |
|
||||
#include <dt-bindings/interrupt-controller/irq.h>
|
||||
#include <dt-bindings/input/linux-event-codes.h>
|
||||
#include <dt-bindings/spmi/spmi.h>
|
||||
spmi_bus: spmi@c440000 {
|
||||
reg = <0x0c440000 0x1100>;
|
||||
#address-cells = <2>;
|
||||
#size-cells = <0>;
|
||||
pmk8350: pmic@0 {
|
||||
reg = <0x0 SPMI_USID>;
|
||||
#address-cells = <1>;
|
||||
#size-cells = <0>;
|
||||
pmk8350_pon: pon_hlos@1300 {
|
||||
reg = <0x1300>;
|
||||
compatible = "qcom,pm8998-pon";
|
||||
|
||||
pwrkey {
|
||||
compatible = "qcom,pm8941-pwrkey";
|
||||
interrupts = < 0x0 0x8 0 IRQ_TYPE_EDGE_BOTH >;
|
||||
debounce = <15625>;
|
||||
bias-pull-up;
|
||||
linux,code = <KEY_POWER>;
|
||||
};
|
||||
|
||||
resin {
|
||||
compatible = "qcom,pm8941-resin";
|
||||
interrupts = <0x0 0x8 1 IRQ_TYPE_EDGE_BOTH>;
|
||||
debounce = <15625>;
|
||||
bias-pull-up;
|
||||
linux,code = <KEY_VOLUMEDOWN>;
|
||||
};
|
||||
};
|
||||
};
|
||||
};
|
||||
...
|
||||
|
|
@ -36,7 +36,7 @@ patternProperties:
|
|||
"^mode-.*$":
|
||||
$ref: /schemas/types.yaml#/definitions/uint32
|
||||
|
||||
additionalProperties: false
|
||||
additionalProperties: true
|
||||
|
||||
examples:
|
||||
- |
|
||||
|
|
|
|||
|
|
@ -29,6 +29,7 @@ properties:
|
|||
- enum:
|
||||
- rockchip,px30-pwm
|
||||
- rockchip,rk3308-pwm
|
||||
- rockchip,rk3568-pwm
|
||||
- const: rockchip,rk3328-pwm
|
||||
|
||||
reg:
|
||||
|
|
|
|||
|
|
@ -32,6 +32,9 @@ properties:
|
|||
- dallas,ds3232
|
||||
# I2C-BUS INTERFACE REAL TIME CLOCK MODULE
|
||||
- epson,rx8010
|
||||
# I2C-BUS INTERFACE REAL TIME CLOCK MODULE
|
||||
- epson,rx8025
|
||||
- epson,rx8035
|
||||
# I2C-BUS INTERFACE REAL TIME CLOCK MODULE with Battery Backed RAM
|
||||
- epson,rx8571
|
||||
# I2C-BUS INTERFACE REAL TIME CLOCK MODULE
|
||||
|
|
|
|||
|
|
@ -21,6 +21,7 @@ properties:
|
|||
- fsl,imx8mn-rpmsg-audio
|
||||
- fsl,imx8mm-rpmsg-audio
|
||||
- fsl,imx8mp-rpmsg-audio
|
||||
- fsl,imx8ulp-rpmsg-audio
|
||||
|
||||
model:
|
||||
$ref: /schemas/types.yaml#/definitions/string
|
||||
|
|
|
|||
|
|
@ -130,36 +130,34 @@ additionalProperties: false
|
|||
|
||||
examples:
|
||||
- |
|
||||
#include <dt-bindings/clock/mt8195-clk.h>
|
||||
#include <dt-bindings/interrupt-controller/arm-gic.h>
|
||||
#include <dt-bindings/interrupt-controller/irq.h>
|
||||
#include <dt-bindings/power/mt8195-power.h>
|
||||
|
||||
afe: mt8195-afe-pcm@10890000 {
|
||||
compatible = "mediatek,mt8195-audio";
|
||||
reg = <0x10890000 0x10000>;
|
||||
interrupts = <GIC_SPI 822 IRQ_TYPE_LEVEL_HIGH 0>;
|
||||
mediatek,topckgen = <&topckgen>;
|
||||
power-domains = <&spm MT8195_POWER_DOMAIN_AUDIO>;
|
||||
power-domains = <&spm 7>; //MT8195_POWER_DOMAIN_AUDIO
|
||||
clocks = <&clk26m>,
|
||||
<&topckgen CLK_TOP_APLL1>,
|
||||
<&topckgen CLK_TOP_APLL2>,
|
||||
<&topckgen CLK_TOP_APLL12_DIV0>,
|
||||
<&topckgen CLK_TOP_APLL12_DIV1>,
|
||||
<&topckgen CLK_TOP_APLL12_DIV2>,
|
||||
<&topckgen CLK_TOP_APLL12_DIV3>,
|
||||
<&topckgen CLK_TOP_APLL12_DIV9>,
|
||||
<&topckgen CLK_TOP_A1SYS_HP_SEL>,
|
||||
<&topckgen CLK_TOP_AUD_INTBUS_SEL>,
|
||||
<&topckgen CLK_TOP_AUDIO_H_SEL>,
|
||||
<&topckgen CLK_TOP_AUDIO_LOCAL_BUS_SEL>,
|
||||
<&topckgen CLK_TOP_DPTX_M_SEL>,
|
||||
<&topckgen CLK_TOP_I2SO1_M_SEL>,
|
||||
<&topckgen CLK_TOP_I2SO2_M_SEL>,
|
||||
<&topckgen CLK_TOP_I2SI1_M_SEL>,
|
||||
<&topckgen CLK_TOP_I2SI2_M_SEL>,
|
||||
<&infracfg_ao CLK_INFRA_AO_AUDIO_26M_B>,
|
||||
<&scp_adsp CLK_SCP_ADSP_AUDIODSP>;
|
||||
<&topckgen 163>, //CLK_TOP_APLL1
|
||||
<&topckgen 166>, //CLK_TOP_APLL2
|
||||
<&topckgen 233>, //CLK_TOP_APLL12_DIV0
|
||||
<&topckgen 234>, //CLK_TOP_APLL12_DIV1
|
||||
<&topckgen 235>, //CLK_TOP_APLL12_DIV2
|
||||
<&topckgen 236>, //CLK_TOP_APLL12_DIV3
|
||||
<&topckgen 238>, //CLK_TOP_APLL12_DIV9
|
||||
<&topckgen 100>, //CLK_TOP_A1SYS_HP_SEL
|
||||
<&topckgen 33>, //CLK_TOP_AUD_INTBUS_SEL
|
||||
<&topckgen 34>, //CLK_TOP_AUDIO_H_SEL
|
||||
<&topckgen 107>, //CLK_TOP_AUDIO_LOCAL_BUS_SEL
|
||||
<&topckgen 98>, //CLK_TOP_DPTX_M_SEL
|
||||
<&topckgen 94>, //CLK_TOP_I2SO1_M_SEL
|
||||
<&topckgen 95>, //CLK_TOP_I2SO2_M_SEL
|
||||
<&topckgen 96>, //CLK_TOP_I2SI1_M_SEL
|
||||
<&topckgen 97>, //CLK_TOP_I2SI2_M_SEL
|
||||
<&infracfg_ao 50>, //CLK_INFRA_AO_AUDIO_26M_B
|
||||
<&scp_adsp 0>; //CLK_SCP_ADSP_AUDIODSP
|
||||
clock-names = "clk26m",
|
||||
"apll1_ck",
|
||||
"apll2_ck",
|
||||
|
|
|
|||
|
|
@ -84,9 +84,9 @@ unevaluatedProperties: false
|
|||
if:
|
||||
properties:
|
||||
compatible:
|
||||
oneOf:
|
||||
- const: ti,omap2-mcspi
|
||||
- const: ti,omap4-mcspi
|
||||
enum:
|
||||
- ti,omap2-mcspi
|
||||
- ti,omap4-mcspi
|
||||
|
||||
then:
|
||||
properties:
|
||||
|
|
|
|||
|
|
@ -27,13 +27,11 @@ properties:
|
|||
|
||||
xlnx,num-ss-bits:
|
||||
description: Number of chip selects used.
|
||||
$ref: /schemas/types.yaml#/definitions/uint32
|
||||
minimum: 1
|
||||
maximum: 32
|
||||
|
||||
xlnx,num-transfer-bits:
|
||||
description: Number of bits per transfer. This will be 8 if not specified.
|
||||
$ref: /schemas/types.yaml#/definitions/uint32
|
||||
enum: [8, 16, 32]
|
||||
default: 8
|
||||
|
||||
|
|
|
|||
|
|
@ -0,0 +1,82 @@
|
|||
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
|
||||
# Copyright 2021 Linaro Ltd.
|
||||
%YAML 1.2
|
||||
---
|
||||
$id: http://devicetree.org/schemas/thermal/qcom-lmh.yaml#
|
||||
$schema: http://devicetree.org/meta-schemas/core.yaml#
|
||||
|
||||
title: Qualcomm Limits Management Hardware(LMh)
|
||||
|
||||
maintainers:
|
||||
- Thara Gopinath <thara.gopinath@linaro.org>
|
||||
|
||||
description:
|
||||
Limits Management Hardware(LMh) is a hardware infrastructure on some
|
||||
Qualcomm SoCs that can enforce temperature and current limits as
|
||||
programmed by software for certain IPs like CPU.
|
||||
|
||||
properties:
|
||||
compatible:
|
||||
enum:
|
||||
- qcom,sdm845-lmh
|
||||
|
||||
reg:
|
||||
items:
|
||||
- description: core registers
|
||||
|
||||
interrupts:
|
||||
maxItems: 1
|
||||
|
||||
'#interrupt-cells':
|
||||
const: 1
|
||||
|
||||
interrupt-controller: true
|
||||
|
||||
cpus:
|
||||
description:
|
||||
phandle of the first cpu in the LMh cluster
|
||||
$ref: /schemas/types.yaml#/definitions/phandle
|
||||
|
||||
qcom,lmh-temp-arm-millicelsius:
|
||||
description:
|
||||
An integer expressing temperature threshold at which the LMh thermal
|
||||
FSM is engaged.
|
||||
|
||||
qcom,lmh-temp-low-millicelsius:
|
||||
description:
|
||||
An integer expressing temperature threshold at which the state machine
|
||||
will attempt to remove frequency throttling.
|
||||
|
||||
qcom,lmh-temp-high-millicelsius:
|
||||
description:
|
||||
An integer expressing temperature threshold at which the state machine
|
||||
will attempt to throttle the frequency.
|
||||
|
||||
required:
|
||||
- compatible
|
||||
- reg
|
||||
- interrupts
|
||||
- '#interrupt-cells'
|
||||
- interrupt-controller
|
||||
- cpus
|
||||
- qcom,lmh-temp-arm-millicelsius
|
||||
- qcom,lmh-temp-low-millicelsius
|
||||
- qcom,lmh-temp-high-millicelsius
|
||||
|
||||
additionalProperties: false
|
||||
|
||||
examples:
|
||||
- |
|
||||
#include <dt-bindings/interrupt-controller/arm-gic.h>
|
||||
|
||||
lmh@17d70800 {
|
||||
compatible = "qcom,sdm845-lmh";
|
||||
reg = <0x17d70800 0x400>;
|
||||
interrupts = <GIC_SPI 33 IRQ_TYPE_LEVEL_HIGH>;
|
||||
cpus = <&CPU4>;
|
||||
qcom,lmh-temp-arm-millicelsius = <65000>;
|
||||
qcom,lmh-temp-low-millicelsius = <94500>;
|
||||
qcom,lmh-temp-high-millicelsius = <95000>;
|
||||
interrupt-controller;
|
||||
#interrupt-cells = <1>;
|
||||
};
|
||||
|
|
@ -215,7 +215,7 @@ patternProperties:
|
|||
- polling-delay
|
||||
- polling-delay-passive
|
||||
- thermal-sensors
|
||||
- trips
|
||||
|
||||
additionalProperties: false
|
||||
|
||||
additionalProperties: false
|
||||
|
|
|
|||
|
|
@ -36,7 +36,8 @@ required:
|
|||
- reg
|
||||
- interrupts
|
||||
|
||||
additionalProperties: false
|
||||
additionalProperties:
|
||||
type: object
|
||||
|
||||
examples:
|
||||
- |
|
||||
|
|
|
|||
|
|
@ -0,0 +1,41 @@
|
|||
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
|
||||
%YAML 1.2
|
||||
---
|
||||
$id: http://devicetree.org/schemas/virtio/virtio-device.yaml#
|
||||
$schema: http://devicetree.org/meta-schemas/core.yaml#
|
||||
|
||||
title: Virtio device bindings
|
||||
|
||||
maintainers:
|
||||
- Viresh Kumar <viresh.kumar@linaro.org>
|
||||
|
||||
description:
|
||||
These bindings are applicable to virtio devices irrespective of the bus they
|
||||
are bound to, like mmio or pci.
|
||||
|
||||
# We need a select here so we don't match all nodes with 'virtio,mmio'
|
||||
properties:
|
||||
compatible:
|
||||
pattern: "^virtio,device[0-9a-f]{1,8}$"
|
||||
description: Virtio device nodes.
|
||||
"virtio,deviceID", where ID is the virtio device id. The textual
|
||||
representation of ID shall be in lower case hexadecimal with leading
|
||||
zeroes suppressed.
|
||||
|
||||
required:
|
||||
- compatible
|
||||
|
||||
additionalProperties: true
|
||||
|
||||
examples:
|
||||
- |
|
||||
virtio@3000 {
|
||||
compatible = "virtio,mmio";
|
||||
reg = <0x3000 0x100>;
|
||||
interrupts = <43>;
|
||||
|
||||
i2c {
|
||||
compatible = "virtio,device22";
|
||||
};
|
||||
};
|
||||
...
|
||||
|
|
@ -15,13 +15,13 @@ maintainers:
|
|||
|
||||
properties:
|
||||
compatible:
|
||||
oneOf:
|
||||
- const: maxim,max6369
|
||||
- const: maxim,max6370
|
||||
- const: maxim,max6371
|
||||
- const: maxim,max6372
|
||||
- const: maxim,max6373
|
||||
- const: maxim,max6374
|
||||
enum:
|
||||
- maxim,max6369
|
||||
- maxim,max6370
|
||||
- maxim,max6371
|
||||
- maxim,max6372
|
||||
- maxim,max6373
|
||||
- maxim,max6374
|
||||
|
||||
reg:
|
||||
description: This is a 1-byte memory-mapped address
|
||||
|
|
|
|||
|
|
@ -36,9 +36,15 @@ CXL Core
|
|||
.. kernel-doc:: drivers/cxl/cxl.h
|
||||
:internal:
|
||||
|
||||
.. kernel-doc:: drivers/cxl/core.c
|
||||
.. kernel-doc:: drivers/cxl/core/bus.c
|
||||
:doc: cxl core
|
||||
|
||||
.. kernel-doc:: drivers/cxl/core/pmem.c
|
||||
:doc: cxl pmem
|
||||
|
||||
.. kernel-doc:: drivers/cxl/core/regs.c
|
||||
:doc: cxl registers
|
||||
|
||||
External Interfaces
|
||||
===================
|
||||
|
||||
|
|
|
|||
|
|
@ -22,7 +22,7 @@
|
|||
| openrisc: | TODO |
|
||||
| parisc: | ok |
|
||||
| powerpc: | ok |
|
||||
| riscv: | TODO |
|
||||
| riscv: | ok |
|
||||
| s390: | ok |
|
||||
| sh: | TODO |
|
||||
| sparc: | TODO |
|
||||
|
|
|
|||
|
|
@ -1,7 +1,7 @@
|
|||
#
|
||||
# Feature name: huge-vmap
|
||||
# Kconfig: HAVE_ARCH_HUGE_VMAP
|
||||
# description: arch supports the ioremap_pud_enabled() and ioremap_pmd_enabled() VM APIs
|
||||
# description: arch supports the arch_vmap_pud_supported() and arch_vmap_pmd_supported() VM APIs
|
||||
#
|
||||
-----------------------
|
||||
| arch |status|
|
||||
|
|
|
|||
|
|
@ -71,9 +71,6 @@ Other Functions
|
|||
.. kernel-doc:: fs/fs-writeback.c
|
||||
:export:
|
||||
|
||||
.. kernel-doc:: fs/block_dev.c
|
||||
:export:
|
||||
|
||||
.. kernel-doc:: fs/anon_inodes.c
|
||||
:export:
|
||||
|
||||
|
|
|
|||
|
|
@ -37,7 +37,7 @@ TTM initialization
|
|||
This section is outdated.
|
||||
|
||||
Drivers wishing to support TTM must pass a filled :c:type:`ttm_bo_driver
|
||||
<ttm_bo_driver>` structure to ttm_bo_device_init, together with an
|
||||
<ttm_bo_driver>` structure to ttm_device_init, together with an
|
||||
initialized global reference to the memory manager. The ttm_bo_driver
|
||||
structure contains several fields with function pointers for
|
||||
initializing the TTM, allocating and freeing memory, waiting for command
|
||||
|
|
|
|||
|
|
@ -76,8 +76,8 @@ handler is never re-entered: if the same interrupt arrives, it is queued
|
|||
fast: frequently it simply acknowledges the interrupt, marks a 'software
|
||||
interrupt' for execution and exits.
|
||||
|
||||
You can tell you are in a hardware interrupt, because
|
||||
:c:func:`in_irq()` returns true.
|
||||
You can tell you are in a hardware interrupt, because in_hardirq() returns
|
||||
true.
|
||||
|
||||
.. warning::
|
||||
|
||||
|
|
|
|||
|
|
@ -94,16 +94,10 @@ primitives, but I'll pretend they don't exist.
|
|||
Locking in the Linux Kernel
|
||||
===========================
|
||||
|
||||
If I could give you one piece of advice: never sleep with anyone crazier
|
||||
than yourself. But if I had to give you advice on locking: **keep it
|
||||
simple**.
|
||||
If I could give you one piece of advice on locking: **keep it simple**.
|
||||
|
||||
Be reluctant to introduce new locks.
|
||||
|
||||
Strangely enough, this last one is the exact reverse of my advice when
|
||||
you **have** slept with someone crazier than yourself. And you should
|
||||
think about getting a big dog.
|
||||
|
||||
Two Main Types of Kernel Locks: Spinlocks and Mutexes
|
||||
-----------------------------------------------------
|
||||
|
||||
|
|
@ -1406,7 +1400,7 @@ bh
|
|||
half will be running at any time.
|
||||
|
||||
Hardware Interrupt / Hardware IRQ
|
||||
Hardware interrupt request. in_irq() returns true in a
|
||||
Hardware interrupt request. in_hardirq() returns true in a
|
||||
hardware interrupt handler.
|
||||
|
||||
Interrupt Context
|
||||
|
|
@ -1418,7 +1412,7 @@ SMP
|
|||
(``CONFIG_SMP=y``).
|
||||
|
||||
Software Interrupt / softirq
|
||||
Software interrupt handler. in_irq() returns false;
|
||||
Software interrupt handler. in_hardirq() returns false;
|
||||
in_softirq() returns true. Tasklets and softirqs both
|
||||
fall into the category of 'software interrupts'.
|
||||
|
||||
|
|
|
|||
|
|
@ -5,7 +5,7 @@ Futex Requeue PI
|
|||
Requeueing of tasks from a non-PI futex to a PI futex requires
|
||||
special handling in order to ensure the underlying rt_mutex is never
|
||||
left without an owner if it has waiters; doing so would break the PI
|
||||
boosting logic [see rt-mutex-desgin.txt] For the purposes of
|
||||
boosting logic [see rt-mutex-design.rst] For the purposes of
|
||||
brevity, this action will be referred to as "requeue_pi" throughout
|
||||
this document. Priority inheritance is abbreviated throughout as
|
||||
"PI".
|
||||
|
|
|
|||
|
|
@ -2,7 +2,7 @@
|
|||
Wound/Wait Deadlock-Proof Mutex Design
|
||||
======================================
|
||||
|
||||
Please read mutex-design.txt first, as it applies to wait/wound mutexes too.
|
||||
Please read mutex-design.rst first, as it applies to wait/wound mutexes too.
|
||||
|
||||
Motivation for WW-Mutexes
|
||||
-------------------------
|
||||
|
|
|
|||
|
|
@ -101,8 +101,7 @@ subsystems which use EM might rely on this flag to check if all EM devices use
|
|||
the same scale. If there are different scales, these subsystems might decide
|
||||
to: return warning/error, stop working or panic.
|
||||
See Section 3. for an example of driver implementing this
|
||||
callback, and kernel/power/energy_model.c for further documentation on this
|
||||
API.
|
||||
callback, or Section 2.4 for further documentation on this API
|
||||
|
||||
|
||||
2.3 Accessing performance domains
|
||||
|
|
@ -123,7 +122,17 @@ em_cpu_energy() API. The estimation is performed assuming that the schedutil
|
|||
CPUfreq governor is in use in case of CPU device. Currently this calculation is
|
||||
not provided for other type of devices.
|
||||
|
||||
More details about the above APIs can be found in include/linux/energy_model.h.
|
||||
More details about the above APIs can be found in ``<linux/energy_model.h>``
|
||||
or in Section 2.4
|
||||
|
||||
|
||||
2.4 Description details of this API
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
.. kernel-doc:: include/linux/energy_model.h
|
||||
:internal:
|
||||
|
||||
.. kernel-doc:: kernel/power/energy_model.c
|
||||
:export:
|
||||
|
||||
|
||||
3. Example driver
|
||||
|
|
|
|||
|
|
@ -389,7 +389,7 @@ The -mm patches are experimental patches released by Andrew Morton.
|
|||
|
||||
In the past, -mm tree were used to also test subsystem patches, but this
|
||||
function is now done via the
|
||||
`linux-next <https://www.kernel.org/doc/man-pages/linux-next.html>`
|
||||
`linux-next` (https://www.kernel.org/doc/man-pages/linux-next.html)
|
||||
tree. The Subsystem maintainers push their patches first to linux-next,
|
||||
and, during the merge window, sends them directly to Linus.
|
||||
|
||||
|
|
|
|||
|
|
@ -126,15 +126,17 @@ On-line docs
|
|||
describes how to write user-mode utilities for communicating with
|
||||
Card Services.
|
||||
|
||||
* Title: **Linux Kernel Module Programming Guide**
|
||||
* Title: **The Linux Kernel Module Programming Guide**
|
||||
|
||||
:Author: Ori Pomerantz.
|
||||
:URL: https://tldp.org/LDP/lkmpg/2.6/html/index.html
|
||||
:Date: 2001
|
||||
:Author: Peter Jay Salzman, Michael Burian, Ori Pomerantz, Bob Mottram,
|
||||
Jim Huang.
|
||||
:URL: https://sysprog21.github.io/lkmpg/
|
||||
:Date: 2021
|
||||
:Keywords: modules, GPL book, /proc, ioctls, system calls,
|
||||
interrupt handlers .
|
||||
:Description: Very nice 92 pages GPL book on the topic of modules
|
||||
programming. Lots of examples.
|
||||
:Description: A very nice GPL book on the topic of modules
|
||||
programming. Lots of examples. Currently the new version is being
|
||||
actively maintained at https://github.com/sysprog21/lkmpg.
|
||||
|
||||
* Title: **Global spinlock list and usage**
|
||||
|
||||
|
|
|
|||
|
|
@ -944,12 +944,11 @@ have on your keyring::
|
|||
uid [ unknown] Linus Torvalds <torvalds@kernel.org>
|
||||
sub rsa2048 2011-09-20 [E]
|
||||
|
||||
Next, open the `PGP pathfinder`_. In the "From" field, paste the key
|
||||
fingerprint of Linus Torvalds from the output above. In the "To" field,
|
||||
paste the key-id you found via ``gpg --search`` of the unknown key, and
|
||||
check the results:
|
||||
|
||||
- `Finding paths to Linus`_
|
||||
Next, find a trust path from Linus Torvalds to the key-id you found via ``gpg
|
||||
--search`` of the unknown key. For this, you can use several tools including
|
||||
https://github.com/mricon/wotmate,
|
||||
https://git.kernel.org/pub/scm/docs/kernel/pgpkeys.git/tree/graphs, and
|
||||
https://the.earth.li/~noodles/pathfind.html.
|
||||
|
||||
If you get a few decent trust paths, then it's a pretty good indication
|
||||
that it is a valid key. You can add it to your keyring from the
|
||||
|
|
@ -962,6 +961,3 @@ administrators of the PGP Pathfinder service to not be malicious (in
|
|||
fact, this goes against :ref:`devs_not_infra`). However, if you
|
||||
do not carefully maintain your own web of trust, then it is a marked
|
||||
improvement over blindly trusting keyservers.
|
||||
|
||||
.. _`PGP pathfinder`: https://pgp.cs.uu.nl/
|
||||
.. _`Finding paths to Linus`: https://pgp.cs.uu.nl/paths/79BE3E4300411886/to/C94035C21B4F2AEB.html
|
||||
|
|
|
|||
|
|
@ -90,7 +90,7 @@ i gestori d'interruzioni devono essere veloci: spesso si limitano
|
|||
esclusivamente a notificare la presa in carico dell'interruzione,
|
||||
programmare una 'interruzione software' per l'esecuzione e quindi terminare.
|
||||
|
||||
Potete dire d'essere in una interruzione hardware perché :c:func:`in_irq()`
|
||||
Potete dire d'essere in una interruzione hardware perché in_hardirq()
|
||||
ritorna vero.
|
||||
|
||||
.. warning::
|
||||
|
|
|
|||
|
|
@ -1459,11 +1459,11 @@ contesto utente
|
|||
che hardware.
|
||||
|
||||
interruzione hardware
|
||||
Richiesta di interruzione hardware. in_irq() ritorna vero in un
|
||||
Richiesta di interruzione hardware. in_hardirq() ritorna vero in un
|
||||
gestore d'interruzioni hardware.
|
||||
|
||||
interruzione software / softirq
|
||||
Gestore di interruzioni software: in_irq() ritorna falso;
|
||||
Gestore di interruzioni software: in_hardirq() ritorna falso;
|
||||
in_softirq() ritorna vero. I tasklet e le softirq sono entrambi
|
||||
considerati 'interruzioni software'.
|
||||
|
||||
|
|
|
|||
|
|
@ -80,7 +80,7 @@ cpu上对这个地址空间进行刷新。
|
|||
5) ``void update_mmu_cache(struct vm_area_struct *vma,
|
||||
unsigned long address, pte_t *ptep)``
|
||||
|
||||
在每个页面故障结束时，这个程序被调用，以告诉体系结构特定的代码，在
|
||||
在每个缺页异常结束时，这个程序被调用，以告诉体系结构特定的代码，在
|
||||
软件页表中，在地址空间“vma->vm_mm”的虚拟地址“地址”处，现在存在
|
||||
一个翻译。
|
||||
|
||||
|
|
|
|||
|
|
@ -1,11 +1,13 @@
|
|||
.. include:: ../disclaimer-zh_CN.rst
|
||||
|
||||
:Original: :doc:`../../../core-api/irq/index`
|
||||
:Translator: Yanteng Si <siyanteng@loongson.cn>
|
||||
:Original: Documentation/core-api/index.rst
|
||||
|
||||
:翻译:
|
||||
|
||||
司延腾 Yanteng Si <siyanteng@loongson.cn>
|
||||
|
||||
.. _cn_core-api_index.rst:
|
||||
|
||||
|
||||
===========
|
||||
核心API文档
|
||||
===========
|
||||
|
|
|
|||
|
|
@ -1,11 +1,13 @@
|
|||
.. include:: ../../disclaimer-zh_CN.rst
|
||||
|
||||
:Original: :doc:`../../../../core-api/irq/concepts`
|
||||
:Translator: Yanteng Si <siyanteng@loongson.cn>
|
||||
:Original: Documentation/core-api/irq/concepts.rst
|
||||
|
||||
:翻译:
|
||||
|
||||
司延腾 Yanteng Si <siyanteng@loongson.cn>
|
||||
|
||||
.. _cn_concepts.rst:
|
||||
|
||||
|
||||
===========
|
||||
什么是IRQ？
|
||||
===========
|
||||
|
|
|
|||
|
|
@ -1,7 +1,10 @@
|
|||
.. include:: ../../disclaimer-zh_CN.rst
|
||||
|
||||
:Original: :doc:`../../../../core-api/irq/index`
|
||||
:Translator: Yanteng Si <siyanteng@loongson.cn>
|
||||
:Original: Documentation/core-api/irq/index.rst
|
||||
|
||||
:翻译:
|
||||
|
||||
司延腾 Yanteng Si <siyanteng@loongson.cn>
|
||||
|
||||
.. _cn_irq_index.rst:
|
||||
|
||||
|
|
|
|||
|
|
@ -1,11 +1,13 @@
|
|||
.. include:: ../../disclaimer-zh_CN.rst
|
||||
|
||||
:Original: :doc:`../../../../core-api/irq/irq-affinity`
|
||||
:Translator: Yanteng Si <siyanteng@loongson.cn>
|
||||
:Original: Documentation/core-api/irq/irq-affinity
|
||||
|
||||
:翻译:
|
||||
|
||||
司延腾 Yanteng Si <siyanteng@loongson.cn>
|
||||
|
||||
.. _cn_irq-affinity.rst:
|
||||
|
||||
|
||||
==============
|
||||
SMP IRQ 亲和性
|
||||
==============
|
||||
|
|
|
|||
|
|
@ -1,11 +1,13 @@
|
|||
.. include:: ../../disclaimer-zh_CN.rst
|
||||
|
||||
:Original: :doc:`../../../../core-api/irq/irq-domain`
|
||||
:Translator: Yanteng Si <siyanteng@loongson.cn>
|
||||
:Original: Documentation/core-api/irq/irq-domain.rst
|
||||
|
||||
:翻译:
|
||||
|
||||
司延腾 Yanteng Si <siyanteng@loongson.cn>
|
||||
|
||||
.. _cn_irq-domain.rst:
|
||||
|
||||
|
||||
=======================
|
||||
irq_domain 中断号映射库
|
||||
=======================
|
||||
|
|
|
|||
|
|
@ -1,11 +1,13 @@
|
|||
.. include:: ../../disclaimer-zh_CN.rst
|
||||
|
||||
:Original: :doc:`../../../../core-api/irq/irqflags-tracing`
|
||||
:Translator: Yanteng Si <siyanteng@loongson.cn>
|
||||
:Original: Documentation/core-api/irq/irqflags-tracing.rst
|
||||
|
||||
:翻译:
|
||||
|
||||
司延腾 Yanteng Si <siyanteng@loongson.cn>
|
||||
|
||||
.. _cn_irqflags-tracing.rst:
|
||||
|
||||
|
||||
=================
|
||||
IRQ-flags状态追踪
|
||||
=================
|
||||
|
|
|
|||
|
|
@ -1,11 +1,13 @@
|
|||
.. include:: ../disclaimer-zh_CN.rst
|
||||
|
||||
:Original: Documentation/core-api/kernel-api.rst
|
||||
:Translator: Yanteng Si <siyanteng@loongson.cn>
|
||||
|
||||
:翻译:
|
||||
|
||||
司延腾 Yanteng Si <siyanteng@loongson.cn>
|
||||
|
||||
.. _cn_kernel-api.rst:
|
||||
|
||||
|
||||
============
|
||||
Linux内核API
|
||||
============
|
||||
|
|
|
|||
|
|
@ -1,7 +1,10 @@
|
|||
.. include:: ../disclaimer-zh_CN.rst
|
||||
|
||||
:Original: Documentation/core-api/kobject.rst
|
||||
:Translator: Yanteng Si <siyanteng@loongson.cn>
|
||||
|
||||
:翻译:
|
||||
|
||||
司延腾 Yanteng Si <siyanteng@loongson.cn>
|
||||
|
||||
.. _cn_core_api_kobject.rst:
|
||||
|
||||
|
|
|
|||
|
|
@ -1,11 +1,13 @@
|
|||
.. include:: ../disclaimer-zh_CN.rst
|
||||
|
||||
:Original: Documentation/core-api/local_ops.rst
|
||||
:Translator: Yanteng Si <siyanteng@loongson.cn>
|
||||
|
||||
:翻译:
|
||||
|
||||
司延腾 Yanteng Si <siyanteng@loongson.cn>
|
||||
|
||||
.. _cn_local_ops:
|
||||
|
||||
|
||||
========================
|
||||
本地原子操作的语义和行为
|
||||
========================
|
||||
|
|
|
|||
|
|
@ -3,7 +3,10 @@
|
|||
.. include:: ../disclaimer-zh_CN.rst
|
||||
|
||||
:Original: Documentation/core-api/padata.rst
|
||||
:Translator: Yanteng Si <siyanteng@loongson.cn>
|
||||
|
||||
:翻译:
|
||||
|
||||
司延腾 Yanteng Si <siyanteng@loongson.cn>
|
||||
|
||||
.. _cn_core_api_padata.rst:
|
||||
|
||||
|
|
|
|||
|
|
@ -2,11 +2,13 @@
|
|||
.. include:: ../disclaimer-zh_CN.rst
|
||||
|
||||
:Original: Documentation/core-api/printk-basics.rst
|
||||
:Translator: Yanteng Si <siyanteng@loongson.cn>
|
||||
|
||||
:翻译:
|
||||
|
||||
司延腾 Yanteng Si <siyanteng@loongson.cn>
|
||||
|
||||
.. _cn_printk-basics.rst:
|
||||
|
||||
|
||||
==================
|
||||
使用printk记录消息
|
||||
==================
|
||||
|
|
|
|||
|
|
@ -1,11 +1,13 @@
|
|||
.. include:: ../disclaimer-zh_CN.rst
|
||||
|
||||
:Original: Documentation/core-api/printk-formats.rst
|
||||
:Translator: Yanteng Si <siyanteng@loongson.cn>
|
||||
|
||||
:翻译:
|
||||
|
||||
司延腾 Yanteng Si <siyanteng@loongson.cn>
|
||||
|
||||
.. _cn_printk-formats.rst:
|
||||
|
||||
|
||||
==============================
|
||||
如何获得正确的printk格式占位符
|
||||
==============================
|
||||
|
|
|
|||
|
|
@ -1,11 +1,13 @@
|
|||
.. include:: ../disclaimer-zh_CN.rst
|
||||
|
||||
:Original: Documentation/core-api/refcount-vs-atomic.rst
|
||||
:Translator: Yanteng Si <siyanteng@loongson.cn>
|
||||
|
||||
:翻译:
|
||||
|
||||
司延腾 Yanteng Si <siyanteng@loongson.cn>
|
||||
|
||||
.. _cn_refcount-vs-atomic:
|
||||
|
||||
|
||||
=======================================
|
||||
与atomic_t相比，refcount_t的API是这样的
|
||||
=======================================
|
||||
|
|
|
|||
|
|
@ -1,11 +1,13 @@
|
|||
.. include:: ../disclaimer-zh_CN.rst
|
||||
|
||||
:Original: Documentation/core-api/symbol-namespaces.rst
|
||||
:Translator: Yanteng Si <siyanteng@loongson.cn>
|
||||
|
||||
:翻译:
|
||||
|
||||
司延腾 Yanteng Si <siyanteng@loongson.cn>
|
||||
|
||||
.. _cn_symbol-namespaces.rst:
|
||||
|
||||
|
||||
=================================
|
||||
符号命名空间（Symbol Namespaces）
|
||||
=================================
|
||||
|
|
|
|||
|
|
@ -2,11 +2,13 @@
|
|||
.. include:: ../disclaimer-zh_CN.rst
|
||||
|
||||
:Original: Documentation/core-api/workqueue.rst
|
||||
:Translator: Yanteng Si <siyanteng@loongson.cn>
|
||||
|
||||
:翻译:
|
||||
|
||||
司延腾 Yanteng Si <siyanteng@loongson.cn>
|
||||
|
||||
.. _cn_workqueue.rst:
|
||||
|
||||
|
||||
=========================
|
||||
并发管理的工作队列 (cmwq)
|
||||
=========================
|
||||
|
|
|
|||
|
|
@ -1,12 +1,14 @@
|
|||
.. SPDX-License-Identifier: GPL-2.0
|
||||
.. include:: ../disclaimer-zh_CN.rst
|
||||
|
||||
:Original: :doc:`../../../cpu-freq/core`
|
||||
:Translator: Yanteng Si <siyanteng@loongson.cn>
|
||||
:Original: Documentation/cpu-freq/core.rst
|
||||
|
||||
:翻译:
|
||||
|
||||
司延腾 Yanteng Si <siyanteng@loongson.cn>
|
||||
|
||||
.. _cn_core.rst:
|
||||
|
||||
|
||||
====================================
|
||||
CPUFreq核心和CPUFreq通知器的通用说明
|
||||
====================================
|
||||
|
|
|
|||
|
|
@ -2,12 +2,14 @@
|
|||
|
||||
.. include:: ../disclaimer-zh_CN.rst
|
||||
|
||||
:Original: :doc:`../../../cpu-freq/cpu-drivers`
|
||||
:Translator: Yanteng Si <siyanteng@loongson.cn>
|
||||
:Original: Documentation/cpu-freq/cpu-drivers.rst
|
||||
|
||||
:翻译:
|
||||
|
||||
司延腾 Yanteng Si <siyanteng@loongson.cn>
|
||||
|
||||
.. _cn_cpu-drivers.rst:
|
||||
|
||||
|
||||
=======================================
|
||||
如何实现一个新的CPUFreq处理器驱动程序？
|
||||
=======================================
|
||||
|
|
@ -80,8 +82,6 @@ CPUfreq核心层注册一个cpufreq_driver结构体。
|
|||
.resume - 一个指向per-policy恢复函数的指针，该函数在关中断且在调节器再一次开始前被
|
||||
调用。
|
||||
|
||||
.ready - 一个指向per-policy准备函数的指针，该函数在策略完全初始化之后被调用。
|
||||
|
||||
.attr - 一个指向NULL结尾的"struct freq_attr"列表的指针，该函数允许导出值到
|
||||
sysfs。
|
||||
|
||||
|
|
|
|||
|
|
@ -2,12 +2,14 @@
|
|||
|
||||
.. include:: ../disclaimer-zh_CN.rst
|
||||
|
||||
:Original: :doc:`../../../cpu-freq/cpufreq-stats`
|
||||
:Translator: Yanteng Si <siyanteng@loongson.cn>
|
||||
:Original: Documentation/cpu-freq/cpufreq-stats.rst
|
||||
|
||||
:翻译:
|
||||
|
||||
司延腾 Yanteng Si <siyanteng@loongson.cn>
|
||||
|
||||
.. _cn_cpufreq-stats.rst:
|
||||
|
||||
|
||||
==========================================
|
||||
sysfs CPUFreq Stats的一般说明
|
||||
==========================================
|
||||
|
|
|
|||
|
|
@ -2,12 +2,14 @@
|
|||
|
||||
.. include:: ../disclaimer-zh_CN.rst
|
||||
|
||||
:Original: :doc:`../../../cpu-freq/index`
|
||||
:Translator: Yanteng Si <siyanteng@loongson.cn>
|
||||
:Original: Documentation/cpu-freq/index.rst
|
||||
|
||||
:翻译:
|
||||
|
||||
司延腾 Yanteng Si <siyanteng@loongson.cn>
|
||||
|
||||
.. _cn_index.rst:
|
||||
|
||||
|
||||
=======================================================
|
||||
Linux CPUFreq - Linux(TM)内核中的CPU频率和电压升降代码
|
||||
=======================================================
|
||||
|
|
|
|||
|
|
@ -2,7 +2,7 @@
|
|||
|
||||
.. include:: ../disclaimer-zh_CN.rst
|
||||
|
||||
:Original: :doc:`../../../filesystems/debugfs`
|
||||
:Original: Documentation/filesystems/debugfs.rst
|
||||
|
||||
=======
|
||||
Debugfs
|
||||
|
|
|
|||
|
|
@ -1,11 +1,13 @@
|
|||
.. include:: ../disclaimer-zh_CN.rst
|
||||
|
||||
:Original: :doc:`../../../iio/ep93xx_adc`
|
||||
:Translator: Yanteng Si <siyanteng@loongson.cn>
|
||||
:Original: Documentation/iio/ep93xx_adc.rst
|
||||
|
||||
:翻译:
|
||||
|
||||
司延腾 Yanteng Si <siyanteng@loongson.cn>
|
||||
|
||||
.. _cn_iio_ep93xx_adc:
|
||||
|
||||
|
||||
==================================
|
||||
思睿逻辑 EP93xx 模拟数字转换器驱动
|
||||
==================================
|
||||
|
|
|
|||
|
|
@ -1,11 +1,13 @@
|
|||
.. include:: ../disclaimer-zh_CN.rst
|
||||
|
||||
:Original: :doc:`../../../iio/iio_configfs`
|
||||
:Translator: Yanteng Si <siyanteng@loongson.cn>
|
||||
:Original: Documentation/iio/iio_configfs.rst
|
||||
|
||||
:翻译:
|
||||
|
||||
司延腾 Yanteng Si <siyanteng@loongson.cn>
|
||||
|
||||
.. _cn_iio_configfs:
|
||||
|
||||
|
||||
=====================
|
||||
工业 IIO configfs支持
|
||||
=====================
|
||||
|
|
|
|||
|
|
@ -2,12 +2,14 @@
|
|||
|
||||
.. include:: ../disclaimer-zh_CN.rst
|
||||
|
||||
:Original: :doc:`../../../iio/index`
|
||||
:Translator: Yanteng Si <siyanteng@loongson.cn>
|
||||
:Original: Documentation/iio/index.rst
|
||||
|
||||
:翻译:
|
||||
|
||||
司延腾 Yanteng Si <siyanteng@loongson.cn>
|
||||
|
||||
.. _cn_iio_index:
|
||||
|
||||
|
||||
========
|
||||
工业 I/O
|
||||
========
|
||||
|
|
|
|||
|
|
@ -68,7 +68,7 @@
|
|||
它将被排队（或丢弃）。因为它会关闭中断，所以处理程序必须很快：通常它只是
|
||||
确认中断，标记一个“软件中断”以执行并退出。
|
||||
|
||||
您可以通过 :c:func:`in_irq()` 返回真来判断您处于硬件中断状态。
|
||||
您可以通过 in_hardirq() 返回真来判断您处于硬件中断状态。
|
||||
|
||||
.. warning::
|
||||
|
||||
|
|
|
|||
Some files were not shown because too many files have changed in this diff Show More
Loading…
Reference in New Issue