shinys000114/linux
1
0
Fork 0
mirror of https://github.com/hardkernel/linux.git synced 2026-06-06 10:58:48 +09:00
Code Issues Packages Projects Releases Wiki Activity

Merge 458ef2a25e Merge tag 'x86-timers-2020-03-30' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip into android-mainline

Browse Source 
In a quest to make the huge -rc1 merge easier to handle and bisect,
merge the first chunk of 5.7-rc1 patches into android-mainline.

Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: Ib54436e9515660a4c0c25c49c21bfb399eb57921
This commit is contained in:
Greg Kroah-Hartman
2020-03-31 14:01:10 +02:00
parent 9b3cb5c972 458ef2a25e
commit 5826bb3260
2274 changed files with 84500 additions and 75511 deletions
Download Patch File Download Diff File Expand all files Collapse all files

1
.mailmap
View File

@@ -244,6 +244,7 @@ Santosh Shilimkar <ssantosh@kernel.org>
Santosh Shilimkar <santosh.shilimkar@oracle.org>
Sascha Hauer <s.hauer@pengutronix.de>
S.Çağlar Onur <caglar@pardus.org.tr>
Sakari Ailus <sakari.ailus@linux.intel.com> <sakari.ailus@iki.fi>
Sean Nyekjaer <sean@geanix.com> <sean.nyekjaer@prevas.dk>
Sebastian Reichel <sre@kernel.org> <sre@debian.org>
Sebastian Reichel <sre@kernel.org> <sebastian.reichel@collabora.co.uk>

2
Documentation/ABI/testing/sysfs-kernel-uids → Documentation/ABI/removed/sysfs-kernel-uids
View File

@@ -1,5 +1,5 @@
What: /sys/kernel/uids/<uid>/cpu_shares
Date: December 2007
Date: December 2007, finally removed in kernel v2.6.34-rc1
Contact: Dhaval Giani <dhaval@linux.vnet.ibm.com>
Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>
Description:

8
drivers/staging/most/Documentation/ABI/configfs-most.txt → Documentation/ABI/testing/configfs-most
View File

@@ -194,11 +194,3 @@ Description:
destroy_link write '1' to this attribute to destroy an
active link
What: /sys/kernel/config/rdma_cm/<hca>/ports/<port-num>/default_roce_tos
Date: March 8, 2019
KernelVersion: 5.2
Description: RDMA-CM QPs from HCA <hca> at port <port-num>
will be created with this TOS as default.
This can be overridden by using the rdma_set_option API.
The possible RoCE TOS values are 0-255.

25
Documentation/ABI/testing/sysfs-bus-counter-104-quad-8
View File

@@ -1,3 +1,28 @@
What: /sys/bus/counter/devices/counterX/signalY/cable_fault
KernelVersion: 5.7
Contact: linux-iio@vger.kernel.org
Description:
Read-only attribute that indicates whether a differential
encoder cable fault (not connected or loose wires) is detected
for the respective channel of Signal Y. Valid attribute values
are boolean. Detection must first be enabled via the
corresponding cable_fault_enable attribute.
What: /sys/bus/counter/devices/counterX/signalY/cable_fault_enable
KernelVersion: 5.7
Contact: linux-iio@vger.kernel.org
Description:
Whether detection of differential encoder cable faults for the
respective channel of Signal Y is enabled. Valid attribute
values are boolean.
What: /sys/bus/counter/devices/counterX/signalY/filter_clock_prescaler
KernelVersion: 5.7
Contact: linux-iio@vger.kernel.org
Description:
Filter clock factor for input Signal Y. This prescaler value
affects the inputs of both quadrature pair signals.
What: /sys/bus/counter/devices/counterX/signalY/index_polarity
KernelVersion: 5.2
Contact: linux-iio@vger.kernel.org

24
Documentation/ABI/testing/sysfs-bus-iio-adc-ad7192
View File

@@ -2,17 +2,22 @@ What: /sys/bus/iio/devices/iio:deviceX/ac_excitation_en
KernelVersion:
Contact: linux-iio@vger.kernel.org
Description:
Reading gives the state of AC excitation.
Writing '1' enables AC excitation.
This attribute, if available, is used to enable the AC
excitation mode found on some converters. In ac excitation mode,
the polarity of the excitation voltage is reversed on
alternate cycles, to eliminate DC errors.
What: /sys/bus/iio/devices/iio:deviceX/bridge_switch_en
KernelVersion:
Contact: linux-iio@vger.kernel.org
Description:
This bridge switch is used to disconnect it when there is a
need to minimize the system current consumption.
Reading gives the state of the bridge switch.
Writing '1' enables the bridge switch.
This attribute, if available, is used to close or open the
bridge power down switch found on some converters.
In bridge applications, such as strain gauges and load cells,
the bridge itself consumes the majority of the current in the
system. To minimize the current consumption of the system,
the bridge can be disconnected (when it is not being used
using the bridge_switch_en attribute.
What: /sys/bus/iio/devices/iio:deviceX/in_voltagex_sys_calibration
KernelVersion:
@@ -21,6 +26,13 @@ Description:
Initiates the system calibration procedure. This is done on a
single channel at a time. Write '1' to start the calibration.
What: /sys/bus/iio/devices/iio:deviceX/in_voltage2-voltage2_shorted_raw
KernelVersion:
Contact: linux-iio@vger.kernel.org
Description:
Measure voltage from AIN2 pin connected to AIN(+)
and AIN(-) shorted.
What: /sys/bus/iio/devices/iio:deviceX/in_voltagex_sys_calibration_mode_available
KernelVersion:
Contact: linux-iio@vger.kernel.org

24
drivers/staging/most/Documentation/ABI/sysfs-bus-most.txt → Documentation/ABI/testing/sysfs-bus-most
View File

@@ -5,7 +5,7 @@ Contact: Christian Gromm <christian.gromm@microchip.com>
Description:
Provides information about the interface type and the physical
location of the device. Hardware attached via USB, for instance,
might return <usb_device 1-1.1:1.0>
might return <1-1.1:1.0>
Users:
What: /sys/bus/most/devices/.../interface
@@ -278,25 +278,7 @@ Description:
Indicates whether current channel ran out of buffers.
Users:
What: /sys/bus/most/drivers/mostcore/add_link
Date: March 2017
KernelVersion: 4.15
Contact: Christian Gromm <christian.gromm@microchip.com>
Description:
This is used to link a channel to a component of the
mostcore. A link created by writing to this file is
referred to as pipe.
Users:
What: /sys/bus/most/drivers/mostcore/remove_link
Date: March 2017
KernelVersion: 4.15
Contact: Christian Gromm <christian.gromm@microchip.com>
Description:
This is used to unlink a channel from a component.
Users:
What: /sys/bus/most/drivers/mostcore/components
What: /sys/bus/most/drivers/most_core/components
Date: March 2017
KernelVersion: 4.15
Contact: Christian Gromm <christian.gromm@microchip.com>
@@ -304,7 +286,7 @@ Description:
This is used to retrieve a list of registered components.
Users:
What: /sys/bus/most/drivers/mostcore/links
What: /sys/bus/most/drivers/most_core/links
Date: March 2017
KernelVersion: 4.15
Contact: Christian Gromm <christian.gromm@microchip.com>

23
Documentation/ABI/testing/sysfs-class-typec
View File

@@ -20,13 +20,13 @@ Date: April 2017
Contact: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Description:
The supported power roles. This attribute can be used to request
power role swap on the port when the port supports USB Power
Delivery. Swapping is supported as synchronous operation, so
write(2) to the attribute will not return until the operation
has finished. The attribute is notified about role changes so
that poll(2) on the attribute wakes up. Change on the role will
also generate uevent KOBJ_CHANGE. The current role is show in
brackets, for example "[source] sink" when in source mode.
power role swap on the port. Swapping is supported as
synchronous operation, so write(2) to the attribute will not
return until the operation has finished. The attribute is
notified about role changes so that poll(2) on the attribute
wakes up. Change on the role will also generate uevent
KOBJ_CHANGE. The current role is show in brackets, for example
"[source] sink" when in source mode.
Valid values: source, sink
@@ -108,6 +108,15 @@ Contact: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Description:
Revision number of the supported USB Type-C specification.
What: /sys/class/typec/<port>/orientation
Date: February 2020
Contact: Badhri Jagan Sridharan <badhri@google.com>
Description:
Indicates the active orientation of the Type-C connector.
Valid values:
- "normal": CC1 orientation
- "reverse": CC2 orientation
- "unknown": Orientation cannot be determined.
USB Type-C partner devices (eg. /sys/class/typec/port0-partner/)

2
Documentation/Makefile
View File

@@ -13,7 +13,7 @@ endif
SPHINXBUILD = sphinx-build
SPHINXOPTS =
SPHINXDIRS = .
_SPHINXDIRS = $(patsubst $(srctree)/Documentation/%/index.rst,%,$(wildcard $(srctree)/Documentation/*/index.rst))
_SPHINXDIRS = $(sort $(patsubst $(srctree)/Documentation/%/index.rst,%,$(wildcard $(srctree)/Documentation/*/index.rst)))
SPHINX_CONF = conf.py
PAPER =
BUILDDIR = $(obj)/output

2
Documentation/PCI/pci.rst
View File

@@ -239,7 +239,7 @@ from the PCI device config space. Use the values in the pci_dev structure
as the PCI "bus address" might have been remapped to a "host physical"
address by the arch/chip-set specific kernel support.
See Documentation/io-mapping.txt for how to access device registers
See Documentation/driver-api/io-mapping.rst for how to access device registers
or device memory.
The device driver needs to call pci_request_region() to verify

8
Documentation/RCU/Design/Memory-Ordering/Tree-RCU-Memory-Ordering.rst
View File

@@ -4,7 +4,7 @@ A Tour Through TREE_RCU's Grace-Period Memory Ordering
August 8, 2017
This article was contributed by Paul E.&nbsp;McKenney
This article was contributed by Paul E. McKenney
Introduction
============
@@ -48,7 +48,7 @@ Tree RCU Grace Period Memory Ordering Building Blocks
The workhorse for RCU's grace-period memory ordering is the
critical section for the ``rcu_node`` structure's
``-&gt;lock``. These critical sections use helper functions for lock
``->lock``. These critical sections use helper functions for lock
acquisition, including ``raw_spin_lock_rcu_node()``,
``raw_spin_lock_irq_rcu_node()``, and ``raw_spin_lock_irqsave_rcu_node()``.
Their lock-release counterparts are ``raw_spin_unlock_rcu_node()``,
@@ -102,9 +102,9 @@ lock-acquisition and lock-release functions::
23 r3 = READ_ONCE(x);
24 }
25
26 WARN_ON(r1 == 0 &amp;&amp; r2 == 0 &amp;&amp; r3 == 0);
26 WARN_ON(r1 == 0 && r2 == 0 && r3 == 0);
The ``WARN_ON()`` is evaluated at &ldquo;the end of time&rdquo;,
The ``WARN_ON()`` is evaluated at "the end of time",
after all changes have propagated throughout the system.
Without the ``smp_mb__after_unlock_lock()`` provided by the
acquisition functions, this ``WARN_ON()`` could trigger, for example

281
Documentation/RCU/listRCU.rst
View File

@@ -4,12 +4,61 @@ Using RCU to Protect Read-Mostly Linked Lists
=============================================
One of the best applications of RCU is to protect read-mostly linked lists
("struct list_head" in list.h). One big advantage of this approach
(``struct list_head`` in list.h). One big advantage of this approach
is that all of the required memory barriers are included for you in
the list macros. This document describes several applications of RCU,
with the best fits first.
Example 1: Read-Side Action Taken Outside of Lock, No In-Place Updates
Example 1: Read-mostly list: Deferred Destruction
-------------------------------------------------
A widely used usecase for RCU lists in the kernel is lockless iteration over
all processes in the system. ``task_struct::tasks`` represents the list node that
links all the processes. The list can be traversed in parallel to any list
additions or removals.
The traversal of the list is done using ``for_each_process()`` which is defined
by the 2 macros::
#define next_task(p) \
list_entry_rcu((p)->tasks.next, struct task_struct, tasks)
#define for_each_process(p) \
for (p = &init_task ; (p = next_task(p)) != &init_task ; )
The code traversing the list of all processes typically looks like::
rcu_read_lock();
for_each_process(p) {
/* Do something with p */
}
rcu_read_unlock();
The simplified code for removing a process from a task list is::
void release_task(struct task_struct *p)
{
write_lock(&tasklist_lock);
list_del_rcu(&p->tasks);
write_unlock(&tasklist_lock);
call_rcu(&p->rcu, delayed_put_task_struct);
}
When a process exits, ``release_task()`` calls ``list_del_rcu(&p->tasks)`` under
``tasklist_lock`` writer lock protection, to remove the task from the list of
all tasks. The ``tasklist_lock`` prevents concurrent list additions/removals
from corrupting the list. Readers using ``for_each_process()`` are not protected
with the ``tasklist_lock``. To prevent readers from noticing changes in the list
pointers, the ``task_struct`` object is freed only after one or more grace
periods elapse (with the help of call_rcu()). This deferring of destruction
ensures that any readers traversing the list will see valid ``p->tasks.next``
pointers and deletion/freeing can happen in parallel with traversal of the list.
This pattern is also called an **existence lock**, since RCU pins the object in
memory until all existing readers finish.
Example 2: Read-Side Action Taken Outside of Lock: No In-Place Updates
----------------------------------------------------------------------
The best applications are cases where, if reader-writer locking were
@@ -26,7 +75,7 @@ added or deleted, rather than being modified in place.
A straightforward example of this use of RCU may be found in the
system-call auditing support. For example, a reader-writer locked
implementation of audit_filter_task() might be as follows::
implementation of ``audit_filter_task()`` might be as follows::
static enum audit_state audit_filter_task(struct task_struct *tsk)
{
@@ -34,7 +83,7 @@ implementation of audit_filter_task() might be as follows::
enum audit_state state;
read_lock(&auditsc_lock);
/* Note: audit_netlink_sem held by caller. */
/* Note: audit_filter_mutex held by caller. */
list_for_each_entry(e, &audit_tsklist, list) {
if (audit_filter_rules(tsk, &e->rule, NULL, &state)) {
read_unlock(&auditsc_lock);
@@ -58,7 +107,7 @@ This means that RCU can be easily applied to the read side, as follows::
enum audit_state state;
rcu_read_lock();
/* Note: audit_netlink_sem held by caller. */
/* Note: audit_filter_mutex held by caller. */
list_for_each_entry_rcu(e, &audit_tsklist, list) {
if (audit_filter_rules(tsk, &e->rule, NULL, &state)) {
rcu_read_unlock();
@@ -69,18 +118,18 @@ This means that RCU can be easily applied to the read side, as follows::
return AUDIT_BUILD_CONTEXT;
}
The read_lock() and read_unlock() calls have become rcu_read_lock()
The ``read_lock()`` and ``read_unlock()`` calls have become rcu_read_lock()
and rcu_read_unlock(), respectively, and the list_for_each_entry() has
become list_for_each_entry_rcu(). The _rcu() list-traversal primitives
become list_for_each_entry_rcu(). The **_rcu()** list-traversal primitives
insert the read-side memory barriers that are required on DEC Alpha CPUs.
The changes to the update side are also straightforward. A reader-writer
lock might be used as follows for deletion and insertion::
The changes to the update side are also straightforward. A reader-writer lock
might be used as follows for deletion and insertion::
static inline int audit_del_rule(struct audit_rule *rule,
struct list_head *list)
{
struct audit_entry *e;
struct audit_entry *e;
write_lock(&auditsc_lock);
list_for_each_entry(e, list, list) {
@@ -113,9 +162,9 @@ Following are the RCU equivalents for these two functions::
static inline int audit_del_rule(struct audit_rule *rule,
struct list_head *list)
{
struct audit_entry *e;
struct audit_entry *e;
/* Do not use the _rcu iterator here, since this is the only
/* No need to use the _rcu iterator here, since this is the only
* deletion routine. */
list_for_each_entry(e, list, list) {
if (!audit_compare_rule(rule, &e->rule)) {
@@ -139,45 +188,45 @@ Following are the RCU equivalents for these two functions::
return 0;
}
Normally, the write_lock() and write_unlock() would be replaced by
a spin_lock() and a spin_unlock(), but in this case, all callers hold
audit_netlink_sem, so no additional locking is required. The auditsc_lock
can therefore be eliminated, since use of RCU eliminates the need for
writers to exclude readers. Normally, the write_lock() calls would
be converted into spin_lock() calls.
Normally, the ``write_lock()`` and ``write_unlock()`` would be replaced by a
spin_lock() and a spin_unlock(). But in this case, all callers hold
``audit_filter_mutex``, so no additional locking is required. The
``auditsc_lock`` can therefore be eliminated, since use of RCU eliminates the
need for writers to exclude readers.
The list_del(), list_add(), and list_add_tail() primitives have been
replaced by list_del_rcu(), list_add_rcu(), and list_add_tail_rcu().
The _rcu() list-manipulation primitives add memory barriers that are
needed on weakly ordered CPUs (most of them!). The list_del_rcu()
primitive omits the pointer poisoning debug-assist code that would
otherwise cause concurrent readers to fail spectacularly.
The **_rcu()** list-manipulation primitives add memory barriers that are needed on
weakly ordered CPUs (most of them!). The list_del_rcu() primitive omits the
pointer poisoning debug-assist code that would otherwise cause concurrent
readers to fail spectacularly.
So, when readers can tolerate stale data and when entries are either added
or deleted, without in-place modification, it is very easy to use RCU!
So, when readers can tolerate stale data and when entries are either added or
deleted, without in-place modification, it is very easy to use RCU!
Example 2: Handling In-Place Updates
Example 3: Handling In-Place Updates
------------------------------------
The system-call auditing code does not update auditing rules in place.
However, if it did, reader-writer-locked code to do so might look as
follows (presumably, the field_count is only permitted to decrease,
otherwise, the added fields would need to be filled in)::
The system-call auditing code does not update auditing rules in place. However,
if it did, the reader-writer-locked code to do so might look as follows
(assuming only ``field_count`` is updated, otherwise, the added fields would
need to be filled in)::
static inline int audit_upd_rule(struct audit_rule *rule,
struct list_head *list,
__u32 newaction,
__u32 newfield_count)
{
struct audit_entry *e;
struct audit_newentry *ne;
struct audit_entry *e;
struct audit_entry *ne;
write_lock(&auditsc_lock);
/* Note: audit_netlink_sem held by caller. */
/* Note: audit_filter_mutex held by caller. */
list_for_each_entry(e, list, list) {
if (!audit_compare_rule(rule, &e->rule)) {
e->rule.action = newaction;
e->rule.file_count = newfield_count;
e->rule.field_count = newfield_count;
write_unlock(&auditsc_lock);
return 0;
}
@@ -188,16 +237,16 @@ otherwise, the added fields would need to be filled in)::
The RCU version creates a copy, updates the copy, then replaces the old
entry with the newly updated entry. This sequence of actions, allowing
concurrent reads while doing a copy to perform an update, is what gives
RCU ("read-copy update") its name. The RCU code is as follows::
concurrent reads while making a copy to perform an update, is what gives
RCU (*read-copy update*) its name. The RCU code is as follows::
static inline int audit_upd_rule(struct audit_rule *rule,
struct list_head *list,
__u32 newaction,
__u32 newfield_count)
{
struct audit_entry *e;
struct audit_newentry *ne;
struct audit_entry *e;
struct audit_entry *ne;
list_for_each_entry(e, list, list) {
if (!audit_compare_rule(rule, &e->rule)) {
@@ -206,7 +255,7 @@ RCU ("read-copy update") its name. The RCU code is as follows::
return -ENOMEM;
audit_copy_rule(&ne->rule, &e->rule);
ne->rule.action = newaction;
ne->rule.file_count = newfield_count;
ne->rule.field_count = newfield_count;
list_replace_rcu(&e->list, &ne->list);
call_rcu(&e->rcu, audit_free_rule);
return 0;
@@ -215,34 +264,45 @@ RCU ("read-copy update") its name. The RCU code is as follows::
return -EFAULT; /* No matching rule */
}
Again, this assumes that the caller holds audit_netlink_sem. Normally,
the reader-writer lock would become a spinlock in this sort of code.
Again, this assumes that the caller holds ``audit_filter_mutex``. Normally, the
writer lock would become a spinlock in this sort of code.
Example 3: Eliminating Stale Data
Another use of this pattern can be found in the openswitch driver's *connection
tracking table* code in ``ct_limit_set()``. The table holds connection tracking
entries and has a limit on the maximum entries. There is one such table
per-zone and hence one *limit* per zone. The zones are mapped to their limits
through a hashtable using an RCU-managed hlist for the hash chains. When a new
limit is set, a new limit object is allocated and ``ct_limit_set()`` is called
to replace the old limit object with the new one using list_replace_rcu().
The old limit object is then freed after a grace period using kfree_rcu().
Example 4: Eliminating Stale Data
---------------------------------
The auditing examples above tolerate stale data, as do most algorithms
The auditing example above tolerates stale data, as do most algorithms
that are tracking external state. Because there is a delay from the
time the external state changes before Linux becomes aware of the change,
additional RCU-induced staleness is normally not a problem.
additional RCU-induced staleness is generally not a problem.
However, there are many examples where stale data cannot be tolerated.
One example in the Linux kernel is the System V IPC (see the ipc_lock()
function in ipc/util.c). This code checks a "deleted" flag under a
per-entry spinlock, and, if the "deleted" flag is set, pretends that the
One example in the Linux kernel is the System V IPC (see the shm_lock()
function in ipc/shm.c). This code checks a *deleted* flag under a
per-entry spinlock, and, if the *deleted* flag is set, pretends that the
entry does not exist. For this to be helpful, the search function must
return holding the per-entry spinlock, as ipc_lock() does in fact do.
return holding the per-entry spinlock, as shm_lock() does in fact do.
.. _quick_quiz:
Quick Quiz:
Why does the search function need to return holding the per-entry lock for
this deleted-flag technique to be helpful?
For the deleted-flag technique to be helpful, why is it necessary
to hold the per-entry lock while returning from the search function?
:ref:`Answer to Quick Quiz <answer_quick_quiz_list>`
:ref:`Answer to Quick Quiz <quick_quiz_answer>`
If the system-call audit module were to ever need to reject stale data,
one way to accomplish this would be to add a "deleted" flag and a "lock"
spinlock to the audit_entry structure, and modify audit_filter_task()
as follows::
If the system-call audit module were to ever need to reject stale data, one way
to accomplish this would be to add a ``deleted`` flag and a ``lock`` spinlock to the
audit_entry structure, and modify ``audit_filter_task()`` as follows::
static enum audit_state audit_filter_task(struct task_struct *tsk)
{
@@ -267,20 +327,20 @@ as follows::
}
Note that this example assumes that entries are only added and deleted.
Additional mechanism is required to deal correctly with the
update-in-place performed by audit_upd_rule(). For one thing,
audit_upd_rule() would need additional memory barriers to ensure
that the list_add_rcu() was really executed before the list_del_rcu().
Additional mechanism is required to deal correctly with the update-in-place
performed by ``audit_upd_rule()``. For one thing, ``audit_upd_rule()`` would
need additional memory barriers to ensure that the list_add_rcu() was really
executed before the list_del_rcu().
The audit_del_rule() function would need to set the "deleted"
flag under the spinlock as follows::
The ``audit_del_rule()`` function would need to set the ``deleted`` flag under the
spinlock as follows::
static inline int audit_del_rule(struct audit_rule *rule,
struct list_head *list)
{
struct audit_entry *e;
struct audit_entry *e;
/* Do not need to use the _rcu iterator here, since this
/* No need to use the _rcu iterator here, since this
* is the only deletion routine. */
list_for_each_entry(e, list, list) {
if (!audit_compare_rule(rule, &e->rule)) {
@@ -295,6 +355,91 @@ flag under the spinlock as follows::
return -EFAULT; /* No matching rule */
}
This too assumes that the caller holds ``audit_filter_mutex``.
Example 5: Skipping Stale Objects
---------------------------------
For some usecases, reader performance can be improved by skipping stale objects
during read-side list traversal if the object in concern is pending destruction
after one or more grace periods. One such example can be found in the timerfd
subsystem. When a ``CLOCK_REALTIME`` clock is reprogrammed - for example due to
setting of the system time, then all programmed timerfds that depend on this
clock get triggered and processes waiting on them to expire are woken up in
advance of their scheduled expiry. To facilitate this, all such timers are added
to an RCU-managed ``cancel_list`` when they are setup in
``timerfd_setup_cancel()``::
static void timerfd_setup_cancel(struct timerfd_ctx *ctx, int flags)
{
spin_lock(&ctx->cancel_lock);
if ((ctx->clockid == CLOCK_REALTIME &&
(flags & TFD_TIMER_ABSTIME) && (flags & TFD_TIMER_CANCEL_ON_SET)) {
if (!ctx->might_cancel) {
ctx->might_cancel = true;
spin_lock(&cancel_lock);
list_add_rcu(&ctx->clist, &cancel_list);
spin_unlock(&cancel_lock);
}
}
spin_unlock(&ctx->cancel_lock);
}
When a timerfd is freed (fd is closed), then the ``might_cancel`` flag of the
timerfd object is cleared, the object removed from the ``cancel_list`` and
destroyed::
int timerfd_release(struct inode *inode, struct file *file)
{
struct timerfd_ctx *ctx = file->private_data;
spin_lock(&ctx->cancel_lock);
if (ctx->might_cancel) {
ctx->might_cancel = false;
spin_lock(&cancel_lock);
list_del_rcu(&ctx->clist);
spin_unlock(&cancel_lock);
}
spin_unlock(&ctx->cancel_lock);
hrtimer_cancel(&ctx->t.tmr);
kfree_rcu(ctx, rcu);
return 0;
}
If the ``CLOCK_REALTIME`` clock is set, for example by a time server, the
hrtimer framework calls ``timerfd_clock_was_set()`` which walks the
``cancel_list`` and wakes up processes waiting on the timerfd. While iterating
the ``cancel_list``, the ``might_cancel`` flag is consulted to skip stale
objects::
void timerfd_clock_was_set(void)
{
struct timerfd_ctx *ctx;
unsigned long flags;
rcu_read_lock();
list_for_each_entry_rcu(ctx, &cancel_list, clist) {
if (!ctx->might_cancel)
continue;
spin_lock_irqsave(&ctx->wqh.lock, flags);
if (ctx->moffs != ktime_mono_to_real(0)) {
ctx->moffs = KTIME_MAX;
ctx->ticks++;
wake_up_locked_poll(&ctx->wqh, EPOLLIN);
}
spin_unlock_irqrestore(&ctx->wqh.lock, flags);
}
rcu_read_unlock();
}
The key point here is, because RCU-traversal of the ``cancel_list`` happens
while objects are being added and removed to the list, sometimes the traversal
can step on an object that has been removed from the list. In this example, it
is seen that it is better to skip such objects using a flag.
Summary
-------
@@ -303,19 +448,21 @@ the most amenable to use of RCU. The simplest case is where entries are
either added or deleted from the data structure (or atomically modified
in place), but non-atomic in-place modifications can be handled by making
a copy, updating the copy, then replacing the original with the copy.
If stale data cannot be tolerated, then a "deleted" flag may be used
If stale data cannot be tolerated, then a *deleted* flag may be used
in conjunction with a per-entry spinlock in order to allow the search
function to reject newly deleted data.
.. _answer_quick_quiz_list:
.. _quick_quiz_answer:
Answer to Quick Quiz:
Why does the search function need to return holding the per-entry
lock for this deleted-flag technique to be helpful?
For the deleted-flag technique to be helpful, why is it necessary
to hold the per-entry lock while returning from the search function?
If the search function drops the per-entry lock before returning,
then the caller will be processing stale data in any case. If it
is really OK to be processing stale data, then you don't need a
"deleted" flag. If processing stale data really is a problem,
*deleted* flag. If processing stale data really is a problem,
then you need to hold the per-entry lock across all of the code
that uses the value that was returned.
:ref:`Back to Quick Quiz <quick_quiz>`

18
Documentation/RCU/rcu.rst
View File

@@ -11,8 +11,8 @@ must be long enough that any readers accessing the item being deleted have
since dropped their references. For example, an RCU-protected deletion
from a linked list would first remove the item from the list, wait for
a grace period to elapse, then free the element. See the
Documentation/RCU/listRCU.rst file for more information on using RCU with
linked lists.
:ref:`Documentation/RCU/listRCU.rst <list_rcu_doc>` for more information on
using RCU with linked lists.
Frequently Asked Questions
--------------------------
@@ -50,7 +50,7 @@ Frequently Asked Questions
- If I am running on a uniprocessor kernel, which can only do one
thing at a time, why should I wait for a grace period?
See the Documentation/RCU/UP.rst file for more information.
See :ref:`Documentation/RCU/UP.rst <up_doc>` for more information.
- How can I see where RCU is currently used in the Linux kernel?
@@ -68,18 +68,18 @@ Frequently Asked Questions
- Why the name "RCU"?
"RCU" stands for "read-copy update". The file Documentation/RCU/listRCU.rst
has more information on where this name came from, search for
"read-copy update" to find it.
"RCU" stands for "read-copy update".
:ref:`Documentation/RCU/listRCU.rst <list_rcu_doc>` has more information on where
this name came from, search for "read-copy update" to find it.
- I hear that RCU is patented? What is with that?
Yes, it is. There are several known patents related to RCU,
search for the string "Patent" in RTFP.txt to find them.
search for the string "Patent" in Documentation/RCU/RTFP.txt to find them.
Of these, one was allowed to lapse by the assignee, and the
others have been contributed to the Linux kernel under GPL.
There are now also LGPL implementations of user-level RCU
available (http://liburcu.org/).
available (https://liburcu.org/).
- I hear that RCU needs work in order to support realtime kernels?
@@ -88,5 +88,5 @@ Frequently Asked Questions
- Where can I find more information on RCU?
See the RTFP.txt file in this directory.
See the Documentation/RCU/RTFP.txt file.
Or point your browser at (http://www.rdrop.com/users/paulmck/RCU/).

147
Documentation/RCU/torture.txt
View File

@@ -124,9 +124,14 @@ using a dynamically allocated srcu_struct (hence "srcud-" rather than
debugging. The final "T" entry contains the totals of the counters.
USAGE
USAGE ON SPECIFIC KERNEL BUILDS
The following script may be used to torture RCU:
It is sometimes desirable to torture RCU on a specific kernel build,
for example, when preparing to put that kernel build into production.
In that case, the kernel should be built with CONFIG_RCU_TORTURE_TEST=m
so that the test can be started using modprobe and terminated using rmmod.
For example, the following script may be used to torture RCU:
#!/bin/sh
@@ -142,8 +147,136 @@ checked for such errors. The "rmmod" command forces a "SUCCESS",
two are self-explanatory, while the last indicates that while there
were no RCU failures, CPU-hotplug problems were detected.
However, the tools/testing/selftests/rcutorture/bin/kvm.sh script
provides better automation, including automatic failure analysis.
It assumes a qemu/kvm-enabled platform, and runs guest OSes out of initrd.
See tools/testing/selftests/rcutorture/doc/initrd.txt for instructions
on setting up such an initrd.
USAGE ON MAINLINE KERNELS
When using rcutorture to test changes to RCU itself, it is often
necessary to build a number of kernels in order to test that change
across a broad range of combinations of the relevant Kconfig options
and of the relevant kernel boot parameters. In this situation, use
of modprobe and rmmod can be quite time-consuming and error-prone.
Therefore, the tools/testing/selftests/rcutorture/bin/kvm.sh
script is available for mainline testing for x86, arm64, and
powerpc. By default, it will run the series of tests specified by
tools/testing/selftests/rcutorture/configs/rcu/CFLIST, with each test
running for 30 minutes within a guest OS using a minimal userspace
supplied by an automatically generated initrd. After the tests are
complete, the resulting build products and console output are analyzed
for errors and the results of the runs are summarized.
On larger systems, rcutorture testing can be accelerated by passing the
--cpus argument to kvm.sh. For example, on a 64-CPU system, "--cpus 43"
would use up to 43 CPUs to run tests concurrently, which as of v5.4 would
complete all the scenarios in two batches, reducing the time to complete
from about eight hours to about one hour (not counting the time to build
the sixteen kernels). The "--dryrun sched" argument will not run tests,
but rather tell you how the tests would be scheduled into batches. This
can be useful when working out how many CPUs to specify in the --cpus
argument.
Not all changes require that all scenarios be run. For example, a change
to Tree SRCU might run only the SRCU-N and SRCU-P scenarios using the
--configs argument to kvm.sh as follows: "--configs 'SRCU-N SRCU-P'".
Large systems can run multiple copies of of the full set of scenarios,
for example, a system with 448 hardware threads can run five instances
of the full set concurrently. To make this happen:
kvm.sh --cpus 448 --configs '5*CFLIST'
Alternatively, such a system can run 56 concurrent instances of a single
eight-CPU scenario:
kvm.sh --cpus 448 --configs '56*TREE04'
Or 28 concurrent instances of each of two eight-CPU scenarios:
kvm.sh --cpus 448 --configs '28*TREE03 28*TREE04'
Of course, each concurrent instance will use memory, which can be
limited using the --memory argument, which defaults to 512M. Small
values for memory may require disabling the callback-flooding tests
using the --bootargs parameter discussed below.
Sometimes additional debugging is useful, and in such cases the --kconfig
parameter to kvm.sh may be used, for example, "--kconfig 'CONFIG_KASAN=y'".
Kernel boot arguments can also be supplied, for example, to control
rcutorture's module parameters. For example, to test a change to RCU's
CPU stall-warning code, use "--bootargs 'rcutorture.stall_cpu=30'".
This will of course result in the scripting reporting a failure, namely
the resuling RCU CPU stall warning. As noted above, reducing memory may
require disabling rcutorture's callback-flooding tests:
kvm.sh --cpus 448 --configs '56*TREE04' --memory 128M \
--bootargs 'rcutorture.fwd_progress=0'
Sometimes all that is needed is a full set of kernel builds. This is
what the --buildonly argument does.
Finally, the --trust-make argument allows each kernel build to reuse what
it can from the previous kernel build.
There are additional more arcane arguments that are documented in the
source code of the kvm.sh script.
If a run contains failures, the number of buildtime and runtime failures
is listed at the end of the kvm.sh output, which you really should redirect
to a file. The build products and console output of each run is kept in
tools/testing/selftests/rcutorture/res in timestamped directories. A
given directory can be supplied to kvm-find-errors.sh in order to have
it cycle you through summaries of errors and full error logs. For example:
tools/testing/selftests/rcutorture/bin/kvm-find-errors.sh \
tools/testing/selftests/rcutorture/res/2020.01.20-15.54.23
However, it is often more convenient to access the files directly.
Files pertaining to all scenarios in a run reside in the top-level
directory (2020.01.20-15.54.23 in the example above), while per-scenario
files reside in a subdirectory named after the scenario (for example,
"TREE04"). If a given scenario ran more than once (as in "--configs
'56*TREE04'" above), the directories corresponding to the second and
subsequent runs of that scenario include a sequence number, for example,
"TREE04.2", "TREE04.3", and so on.
The most frequently used file in the top-level directory is testid.txt.
If the test ran in a git repository, then this file contains the commit
that was tested and any uncommitted changes in diff format.
The most frequently used files in each per-scenario-run directory are:
.config: This file contains the Kconfig options.
Make.out: This contains build output for a specific scenario.
console.log: This contains the console output for a specific scenario.
This file may be examined once the kernel has booted, but
it might not exist if the build failed.
vmlinux: This contains the kernel, which can be useful with tools like
objdump and gdb.
A number of additional files are available, but are less frequently used.
Many are intended for debugging of rcutorture itself or of its scripting.
As of v5.4, a successful run with the default set of scenarios produces
the following summary at the end of the run on a 12-CPU system:
SRCU-N ------- 804233 GPs (148.932/s) [srcu: g10008272 f0x0 ]
SRCU-P ------- 202320 GPs (37.4667/s) [srcud: g1809476 f0x0 ]
SRCU-t ------- 1122086 GPs (207.794/s) [srcu: g0 f0x0 ]
SRCU-u ------- 1111285 GPs (205.794/s) [srcud: g1 f0x0 ]
TASKS01 ------- 19666 GPs (3.64185/s) [tasks: g0 f0x0 ]
TASKS02 ------- 20541 GPs (3.80389/s) [tasks: g0 f0x0 ]
TASKS03 ------- 19416 GPs (3.59556/s) [tasks: g0 f0x0 ]
TINY01 ------- 836134 GPs (154.84/s) [rcu: g0 f0x0 ] n_max_cbs: 34198
TINY02 ------- 850371 GPs (157.476/s) [rcu: g0 f0x0 ] n_max_cbs: 2631
TREE01 ------- 162625 GPs (30.1157/s) [rcu: g1124169 f0x0 ]
TREE02 ------- 333003 GPs (61.6672/s) [rcu: g2647753 f0x0 ] n_max_cbs: 35844
TREE03 ------- 306623 GPs (56.782/s) [rcu: g2975325 f0x0 ] n_max_cbs: 1496497
CPU count limited from 16 to 12
TREE04 ------- 246149 GPs (45.5831/s) [rcu: g1695737 f0x0 ] n_max_cbs: 434961
TREE05 ------- 314603 GPs (58.2598/s) [rcu: g2257741 f0x2 ] n_max_cbs: 193997
TREE07 ------- 167347 GPs (30.9902/s) [rcu: g1079021 f0x0 ] n_max_cbs: 478732
CPU count limited from 16 to 12
TREE09 ------- 752238 GPs (139.303/s) [rcu: g13075057 f0x0 ] n_max_cbs: 99011

2
Documentation/accounting/psi.rst
View File

@@ -1,3 +1,5 @@
.. _psi:
================================
PSI - Pressure Stall Information
================================

4
Documentation/admin-guide/binfmt-misc.rst
View File

@@ -1,5 +1,5 @@
Kernel Support for miscellaneous (your favourite) Binary Formats v1.1
=====================================================================
Kernel Support for miscellaneous Binary Formats (binfmt_misc)
=============================================================
This Kernel feature allows you to invoke almost (for restrictions see below)
every program by simply typing its name in the shell.

2
Documentation/admin-guide/blockdev/zram.rst
View File

@@ -251,8 +251,6 @@ line of text and contains the following stats separated by whitespace:
================ =============================================================
orig_data_size uncompressed size of data stored in this disk.
This excludes same-element-filled pages (same_pages) since
no memory is allocated for them.
Unit: bytes
compr_data_size compressed size of data stored in this disk
mem_used_total the amount of memory allocated for this disk. This

2
Documentation/admin-guide/bootconfig.rst
View File

@@ -23,7 +23,7 @@ of dot-connected-words, and key and value are connected by ``=``. The value
has to be terminated by semi-colon (``;``) or newline (``\n``).
For array value, array entries are separated by comma (``,``). ::
KEY[.WORD[...]] = VALUE[, VALUE2[...]][;]
KEY[.WORD[...]] = VALUE[, VALUE2[...]][;]
Unlike the kernel command line syntax, spaces are OK around the comma and ``=``.

2
Documentation/admin-guide/cgroup-v1/index.rst
View File

@@ -1,3 +1,5 @@
.. _cgroup-v1:
========================
Control Groups version 1
========================

28
Documentation/admin-guide/cgroup-v2.rst
View File

@@ -9,7 +9,7 @@ This is the authoritative documentation on the design, interface and
conventions of cgroup v2. It describes all userland-visible aspects
of cgroup including core and specific controller behaviors. All
future changes must be reflected in this document. Documentation for
v1 is available under Documentation/admin-guide/cgroup-v1/.
v1 is available under :ref:`Documentation/admin-guide/cgroup-v1/index.rst <cgroup-v1>`.
.. CONTENTS
@@ -1023,7 +1023,7 @@ All time durations are in microseconds.
A read-only nested-key file which exists on non-root cgroups.
Shows pressure stall information for CPU. See
Documentation/accounting/psi.rst for details.
:ref:`Documentation/accounting/psi.rst <psi>` for details.
cpu.uclamp.min
A read-write single value file which exists on non-root cgroups.
@@ -1103,7 +1103,7 @@ PAGE_SIZE multiple when read back.
proportionally to the overage, reducing reclaim pressure for
smaller overages.
Effective min boundary is limited by memory.min values of
Effective min boundary is limited by memory.min values of
all ancestor cgroups. If there is memory.min overcommitment
(child cgroup or cgroups are requiring more protected memory
than parent will allow), then each child cgroup will get
@@ -1313,53 +1313,41 @@ PAGE_SIZE multiple when read back.
Number of major page faults incurred
workingset_refault
Number of refaults of previously evicted pages
workingset_activate
Number of refaulted pages that were immediately activated
workingset_nodereclaim
Number of times a shadow node has been reclaimed
pgrefill
Amount of scanned pages (in an active LRU list)
pgscan
Amount of scanned pages (in an inactive LRU list)
pgsteal
Amount of reclaimed pages
pgactivate
Amount of pages moved to the active LRU list
pgdeactivate
Amount of pages moved to the inactive LRU list
pglazyfree
Amount of pages postponed to be freed under memory pressure
pglazyfreed
Amount of reclaimed lazyfree pages
thp_fault_alloc
Number of transparent hugepages which were allocated to satisfy
a page fault, including COW faults. This counter is not present
when CONFIG_TRANSPARENT_HUGEPAGE is not set.
thp_collapse_alloc
Number of transparent hugepages which were allocated to allow
collapsing an existing range of pages. This counter is not
present when CONFIG_TRANSPARENT_HUGEPAGE is not set.
@@ -1403,7 +1391,7 @@ PAGE_SIZE multiple when read back.
A read-only nested-key file which exists on non-root cgroups.
Shows pressure stall information for memory. See
Documentation/accounting/psi.rst for details.
:ref:`Documentation/accounting/psi.rst <psi>` for details.
Usage Guidelines
@@ -1478,7 +1466,7 @@ IO Interface Files
dios Number of discard IOs
====== =====================
An example read output follows:
An example read output follows::
8:16 rbytes=1459200 wbytes=314773504 rios=192 wios=353 dbytes=0 dios=0
8:0 rbytes=90430464 wbytes=299008000 rios=8950 wios=1252 dbytes=50331648 dios=3021
@@ -1643,7 +1631,7 @@ IO Interface Files
A read-only nested-key file which exists on non-root cgroups.
Shows pressure stall information for IO. See
Documentation/accounting/psi.rst for details.
:ref:`Documentation/accounting/psi.rst <psi>` for details.
Writeback
@@ -1853,7 +1841,7 @@ Cpuset Interface Files
from the requested CPUs.
The CPU numbers are comma-separated numbers or ranges.
For example:
For example::
# cat cpuset.cpus
0-4,6,8-10
@@ -1892,7 +1880,7 @@ Cpuset Interface Files
from the requested memory nodes.
The memory node numbers are comma-separated numbers or ranges.
For example:
For example::
# cat cpuset.mems
0-1,3

4
Documentation/driver-api/edid.rst → Documentation/admin-guide/edid.rst
View File

@@ -11,11 +11,13 @@ Today, with the advent of Kernel Mode Setting, a graphics board is
either correctly working because all components follow the standards -
or the computer is unusable, because the screen remains dark after
booting or it displays the wrong area. Cases when this happens are:
- The graphics board does not recognize the monitor.
- The graphics board is unable to detect any EDID data.
- The graphics board incorrectly forwards EDID data to the driver.
- The monitor sends no or bogus EDID data.
- A KVM sends its own EDID data instead of querying the connected monitor.
Adding the kernel parameter "nomodeset" helps in most cases, but causes
restrictions later on.
@@ -32,7 +34,7 @@ individual data for a specific misbehaving monitor, commented sources
and a Makefile environment are given here.
To create binary EDID and C source code files from the existing data
material, simply type "make".
material, simply type "make" in tools/edid/.
If you want to create your own EDID file, copy the file 1024x768.S,
replace the settings with your own data and add a new target to the

2
Documentation/admin-guide/hw-vuln/tsx_async_abort.rst
View File

@@ -136,8 +136,6 @@ enables the mitigation by default.
The mitigation can be controlled at boot time via a kernel command line option.
See :ref:`taa_mitigation_control_command_line`.
.. _virt_mechanism:
Virtualization mitigation
^^^^^^^^^^^^^^^^^^^^^^^^^

1
Documentation/admin-guide/index.rst
View File

@@ -75,6 +75,7 @@ configure specific aspects of kernel behavior to your liking.
cputopology
dell_rbu
device-mapper/index
edid
efi-stub
ext4
nfs/index

5
Documentation/admin-guide/iostats.rst
View File

@@ -100,7 +100,7 @@ Field 10 -- # of milliseconds spent doing I/Os (unsigned int)
Since 5.0 this field counts jiffies when at least one request was
started or completed. If request runs more than 2 jiffies then some
I/O time will not be accounted unless there are other requests.
I/O time might be not accounted in case of concurrent requests.
Field 11 -- weighted # of milliseconds spent doing I/Os (unsigned int)
This field is incremented at each I/O start, I/O completion, I/O
@@ -143,6 +143,9 @@ are summed (possibly overflowing the unsigned long variable they are
summed to) and the result given to the user. There is no convenient
user interface for accessing the per-CPU counters themselves.
Since 4.19 request times are measured with nanoseconds precision and
truncated to milliseconds before showing in this interface.
Disks vs Partitions
-------------------

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

@@ -450,6 +450,9 @@
bert_disable [ACPI]
Disable BERT OS support on buggy BIOSes.
bgrt_disable [ACPI][X86]
Disable BGRT to avoid flickering OEM logo.
bttv.card= [HW,V4L] bttv (bt848 + bt878 based grabber cards)
bttv.radio= Most important insmod options are available as
kernel args too.
@@ -1099,6 +1102,12 @@
A valid base address must be provided, and the serial
port must already be setup and configured.
ec_imx21,<addr>
ec_imx6q,<addr>
Start an early, polled-mode, output-only console on the
Freescale i.MX UART at the specified address. The UART
must already be setup and configured.
ar3700_uart,<addr>
Start an early, polled-mode console on the
Armada 3700 serial port at the specified
@@ -1354,6 +1363,24 @@
can be changed at run time by the max_graph_depth file
in the tracefs tracing directory. default: 0 (no limit)
fw_devlink= [KNL] Create device links between consumer and supplier
devices by scanning the firmware to infer the
consumer/supplier relationships. This feature is
especially useful when drivers are loaded as modules as
it ensures proper ordering of tasks like device probing
(suppliers first, then consumers), supplier boot state
clean up (only after all consumers have probed),
suspend/resume & runtime PM (consumers first, then
suppliers).
Format: { off | permissive | on | rpm }
off -- Don't create device links from firmware info.
permissive -- Create device links from firmware info
but use it only for ordering boot state clean
up (sync_state() calls).
on -- Create device links from firmware info and use it
to enforce probe and suspend/resume ordering.
rpm -- Like "on", but also use to order runtime PM.
gamecon.map[2|3]=
[HW,JOY] Multisystem joystick and NES/SNES/PSX pad
support via parallel port (up to 5 devices per port)
@@ -1779,7 +1806,7 @@
provided by tboot because it makes the system
vulnerable to DMA attacks.
nobounce [Default off]
Disable bounce buffer for unstrusted devices such as
Disable bounce buffer for untrusted devices such as
the Thunderbolt devices. This will treat the untrusted
devices as the trusted ones, hence might expose security
risks of DMA attacks.
@@ -1883,7 +1910,7 @@
No delay
ip= [IP_PNP]
See Documentation/filesystems/nfs/nfsroot.txt.
See Documentation/admin-guide/nfs/nfsroot.rst.
ipcmni_extend [KNL] Extend the maximum number of unique System V
IPC identifiers from 32,768 to 16,777,216.
@@ -2795,7 +2822,7 @@
<name>,<region-number>[,<base>,<size>,<buswidth>,<altbuswidth>]
mtdparts= [MTD]
See drivers/mtd/cmdlinepart.c.
See drivers/mtd/parsers/cmdlinepart.c
multitce=off [PPC] This parameter disables the use of the pSeries
firmware feature for updating multiple TCE entries
@@ -2853,13 +2880,13 @@
Default value is 0.
nfsaddrs= [NFS] Deprecated. Use ip= instead.
See Documentation/filesystems/nfs/nfsroot.txt.
See Documentation/admin-guide/nfs/nfsroot.rst.
nfsroot= [NFS] nfs root filesystem for disk-less boxes.
See Documentation/filesystems/nfs/nfsroot.txt.
See Documentation/admin-guide/nfs/nfsroot.rst.
nfsrootdebug [NFS] enable nfsroot debugging messages.
See Documentation/filesystems/nfs/nfsroot.txt.
See Documentation/admin-guide/nfs/nfsroot.rst.
nfs.callback_nr_threads=
[NFSv4] set the total number of threads that the
@@ -3285,12 +3312,6 @@
This can be set from sysctl after boot.
See Documentation/admin-guide/sysctl/vm.rst for details.
of_devlink [OF, KNL] Create device links between consumer and
supplier devices by scanning the devictree to infer the
consumer/supplier relationships. A consumer device
will not be probed until all the supplier devices have
probed successfully.
ohci1394_dma=early [HW] enable debugging via the ohci1394 driver.
See Documentation/debugging-via-ohci1394.txt for more
info.
@@ -3984,6 +4005,15 @@
Set threshold of queued RCU callbacks below which
batch limiting is re-enabled.
rcutree.qovld= [KNL]
Set threshold of queued RCU callbacks beyond which
RCU's force-quiescent-state scan will aggressively
enlist help from cond_resched() and sched IPIs to
help CPUs more quickly reach quiescent states.
Set to less than zero to make this be set based
on rcutree.qhimark at boot time and to zero to
disable more aggressive help enlistment.
rcutree.rcu_idle_gp_delay= [KNL]
Set wakeup interval for idle CPUs that have
RCU callbacks (RCU_FAST_NO_HZ=y).
@@ -4199,6 +4229,12 @@
rcupdate.rcu_cpu_stall_suppress= [KNL]
Suppress RCU CPU stall warning messages.
rcupdate.rcu_cpu_stall_suppress_at_boot= [KNL]
Suppress RCU CPU stall warning messages and
rcutorture writer stall warnings that occur
during early boot, that is, during the time
before the init task is spawned.
rcupdate.rcu_cpu_stall_timeout= [KNL]
Set timeout for RCU CPU stall warning messages.
@@ -4392,6 +4428,22 @@
incurs a small amount of overhead in the scheduler
but is useful for debugging and performance tuning.
sched_thermal_decay_shift=
[KNL, SMP] Set a decay shift for scheduler thermal
pressure signal. Thermal pressure signal follows the
default decay period of other scheduler pelt
signals(usually 32 ms but configurable). Setting
sched_thermal_decay_shift will left shift the decay
period for the thermal pressure signal by the shift
value.
i.e. with the default pelt decay period of 32 ms
sched_thermal_decay_shift thermal pressure decay pr
1 64 ms
2 128 ms
and so on.
Format: integer between 0 and 10
Default is 0.
skew_tick= [KNL] Offset the periodic timer tick per cpu to mitigate
xtime_lock contention on larger systems, and/or RCU lock
contention on all systems with CONFIG_MAXSMP set.
@@ -4514,10 +4566,10 @@
Format: <integer>
A nonzero value instructs the soft-lockup detector
to panic the machine when a soft-lockup occurs. This
is also controlled by CONFIG_BOOTPARAM_SOFTLOCKUP_PANIC
which is the respective build-time switch to that
functionality.
to panic the machine when a soft-lockup occurs. It is
also controlled by the kernel.softlockup_panic sysctl
and CONFIG_BOOTPARAM_SOFTLOCKUP_PANIC, which is the
respective build-time switch to that functionality.
softlockup_all_cpu_backtrace=
[KNL] Should the soft-lockup detector generate
@@ -4659,6 +4711,28 @@
spia_pedr=
spia_peddr=
split_lock_detect=
[X86] Enable split lock detection
When enabled (and if hardware support is present), atomic
instructions that access data across cache line
boundaries will result in an alignment check exception.
off - not enabled
warn - the kernel will emit rate limited warnings
about applications triggering the #AC
exception. This mode is the default on CPUs
that supports split lock detection.
fatal - the kernel will send SIGBUS to applications
that trigger the #AC exception.
If an #AC exception is hit in the kernel or in
firmware (i.e. not while executing in user mode)
the kernel will oops in either "warn" or "fatal"
mode.
srcutree.counter_wrap_check [KNL]
Specifies how frequently to check for
grace-period sequence counter wrap for the
@@ -4871,6 +4945,10 @@
topology updates sent by the hypervisor to this
LPAR.
torture.disable_onoff_at_boot= [KNL]
Prevent the CPU-hotplug component of torturing
until after init has spawned.
tp720= [HW,PS2]
tpm_suspend_pcr=[HW,TPM]

2
Documentation/admin-guide/kernel-per-CPU-kthreads.rst
View File

@@ -234,7 +234,7 @@ To reduce its OS jitter, do any of the following:
Such a workqueue can be confined to a given subset of the
CPUs using the ``/sys/devices/virtual/workqueue/*/cpumask`` sysfs
files. The set of WQ_SYSFS workqueues can be displayed using
"ls sys/devices/virtual/workqueue". That said, the workqueues
"ls /sys/devices/virtual/workqueue". That said, the workqueues
maintainer would like to caution people against indiscriminately
sprinkling WQ_SYSFS across all the workqueues. The reason for
caution is that it is easy to add WQ_SYSFS, but because sysfs is

3
Documentation/admin-guide/perf/imx-ddr.rst
View File

@@ -43,7 +43,8 @@ value 1 for supported.
AXI_ID and AXI_MASKING are mapped on DPCR1 register in performance counter.
When non-masked bits are matching corresponding AXI_ID bits then counter is
incremented. Perf counter is incremented if
incremented. Perf counter is incremented if::
AxID && AXI_MASKING == AXI_ID && AXI_MASKING
This filter doesn't support filter different AXI ID for axid-read and axid-write

274
Documentation/admin-guide/pm/cpufreq_drivers.rst Normal file
View File

@@ -0,0 +1,274 @@
.. SPDX-License-Identifier: GPL-2.0
=======================================================
Legacy Documentation of CPU Performance Scaling Drivers
=======================================================
Included below are historic documents describing assorted
:doc:`CPU performance scaling <cpufreq>` drivers. They are reproduced verbatim,
with the original white space formatting and indentation preserved, except for
the added leading space character in every line of text.
AMD PowerNow! Drivers
=====================
::
PowerNow! and Cool'n'Quiet are AMD names for frequency
management capabilities in AMD processors. As the hardware
implementation changes in new generations of the processors,
there is a different cpu-freq driver for each generation.
Note that the driver's will not load on the "wrong" hardware,
so it is safe to try each driver in turn when in doubt as to
which is the correct driver.
Note that the functionality to change frequency (and voltage)
is not available in all processors. The drivers will refuse
to load on processors without this capability. The capability
is detected with the cpuid instruction.
The drivers use BIOS supplied tables to obtain frequency and
voltage information appropriate for a particular platform.
Frequency transitions will be unavailable if the BIOS does
not supply these tables.
6th Generation: powernow-k6
7th Generation: powernow-k7: Athlon, Duron, Geode.
8th Generation: powernow-k8: Athlon, Athlon 64, Opteron, Sempron.
Documentation on this functionality in 8th generation processors
is available in the "BIOS and Kernel Developer's Guide", publication
26094, in chapter 9, available for download from www.amd.com.
BIOS supplied data, for powernow-k7 and for powernow-k8, may be
from either the PSB table or from ACPI objects. The ACPI support
is only available if the kernel config sets CONFIG_ACPI_PROCESSOR.
The powernow-k8 driver will attempt to use ACPI if so configured,
and fall back to PST if that fails.
The powernow-k7 driver will try to use the PSB support first, and
fall back to ACPI if the PSB support fails. A module parameter,
acpi_force, is provided to force ACPI support to be used instead
of PSB support.
``cpufreq-nforce2``
===================
::
The cpufreq-nforce2 driver changes the FSB on nVidia nForce2 platforms.
This works better than on other platforms, because the FSB of the CPU
can be controlled independently from the PCI/AGP clock.
The module has two options:
fid: multiplier * 10 (for example 8.5 = 85)
min_fsb: minimum FSB
If not set, fid is calculated from the current CPU speed and the FSB.
min_fsb defaults to FSB at boot time - 50 MHz.
IMPORTANT: The available range is limited downwards!
Also the minimum available FSB can differ, for systems
booting with 200 MHz, 150 should always work.
``pcc-cpufreq``
===============
::
/*
* pcc-cpufreq.txt - PCC interface documentation
*
* Copyright (C) 2009 Red Hat, Matthew Garrett <mjg@redhat.com>
* Copyright (C) 2009 Hewlett-Packard Development Company, L.P.
* Nagananda Chumbalkar <nagananda.chumbalkar@hp.com>
*/
Processor Clocking Control Driver
---------------------------------
Contents:
---------
1. Introduction
1.1 PCC interface
1.1.1 Get Average Frequency
1.1.2 Set Desired Frequency
1.2 Platforms affected
2. Driver and /sys details
2.1 scaling_available_frequencies
2.2 cpuinfo_transition_latency
2.3 cpuinfo_cur_freq
2.4 related_cpus
3. Caveats
1. Introduction:
----------------
Processor Clocking Control (PCC) is an interface between the platform
firmware and OSPM. It is a mechanism for coordinating processor
performance (ie: frequency) between the platform firmware and the OS.
The PCC driver (pcc-cpufreq) allows OSPM to take advantage of the PCC
interface.
OS utilizes the PCC interface to inform platform firmware what frequency the
OS wants for a logical processor. The platform firmware attempts to achieve
the requested frequency. If the request for the target frequency could not be
satisfied by platform firmware, then it usually means that power budget
conditions are in place, and "power capping" is taking place.
1.1 PCC interface:
------------------
The complete PCC specification is available here:
https://acpica.org/sites/acpica/files/Processor-Clocking-Control-v1p0.pdf
PCC relies on a shared memory region that provides a channel for communication
between the OS and platform firmware. PCC also implements a "doorbell" that
is used by the OS to inform the platform firmware that a command has been
sent.
The ACPI PCCH() method is used to discover the location of the PCC shared
memory region. The shared memory region header contains the "command" and
"status" interface. PCCH() also contains details on how to access the platform
doorbell.
The following commands are supported by the PCC interface:
* Get Average Frequency
* Set Desired Frequency
The ACPI PCCP() method is implemented for each logical processor and is
used to discover the offsets for the input and output buffers in the shared
memory region.
When PCC mode is enabled, the platform will not expose processor performance
or throttle states (_PSS, _TSS and related ACPI objects) to OSPM. Therefore,
the native P-state driver (such as acpi-cpufreq for Intel, powernow-k8 for
AMD) will not load.
However, OSPM remains in control of policy. The governor (eg: "ondemand")
computes the required performance for each processor based on server workload.
The PCC driver fills in the command interface, and the input buffer and
communicates the request to the platform firmware. The platform firmware is
responsible for delivering the requested performance.
Each PCC command is "global" in scope and can affect all the logical CPUs in
the system. Therefore, PCC is capable of performing "group" updates. With PCC
the OS is capable of getting/setting the frequency of all the logical CPUs in
the system with a single call to the BIOS.
1.1.1 Get Average Frequency:
----------------------------
This command is used by the OSPM to query the running frequency of the
processor since the last time this command was completed. The output buffer
indicates the average unhalted frequency of the logical processor expressed as
a percentage of the nominal (ie: maximum) CPU frequency. The output buffer
also signifies if the CPU frequency is limited by a power budget condition.
1.1.2 Set Desired Frequency:
----------------------------
This command is used by the OSPM to communicate to the platform firmware the
desired frequency for a logical processor. The output buffer is currently
ignored by OSPM. The next invocation of "Get Average Frequency" will inform
OSPM if the desired frequency was achieved or not.
1.2 Platforms affected:
-----------------------
The PCC driver will load on any system where the platform firmware:
* supports the PCC interface, and the associated PCCH() and PCCP() methods
* assumes responsibility for managing the hardware clocking controls in order
to deliver the requested processor performance
Currently, certain HP ProLiant platforms implement the PCC interface. On those
platforms PCC is the "default" choice.
However, it is possible to disable this interface via a BIOS setting. In
such an instance, as is also the case on platforms where the PCC interface
is not implemented, the PCC driver will fail to load silently.
2. Driver and /sys details:
---------------------------
When the driver loads, it merely prints the lowest and the highest CPU
frequencies supported by the platform firmware.
The PCC driver loads with a message such as:
pcc-cpufreq: (v1.00.00) driver loaded with frequency limits: 1600 MHz, 2933
MHz
This means that the OPSM can request the CPU to run at any frequency in
between the limits (1600 MHz, and 2933 MHz) specified in the message.
Internally, there is no need for the driver to convert the "target" frequency
to a corresponding P-state.
The VERSION number for the driver will be of the format v.xy.ab.
eg: 1.00.02
----- --
| |
| -- this will increase with bug fixes/enhancements to the driver
|-- this is the version of the PCC specification the driver adheres to
The following is a brief discussion on some of the fields exported via the
/sys filesystem and how their values are affected by the PCC driver:
2.1 scaling_available_frequencies:
----------------------------------
scaling_available_frequencies is not created in /sys. No intermediate
frequencies need to be listed because the BIOS will try to achieve any
frequency, within limits, requested by the governor. A frequency does not have
to be strictly associated with a P-state.
2.2 cpuinfo_transition_latency:
-------------------------------
The cpuinfo_transition_latency field is 0. The PCC specification does
not include a field to expose this value currently.
2.3 cpuinfo_cur_freq:
---------------------
A) Often cpuinfo_cur_freq will show a value different than what is declared
in the scaling_available_frequencies or scaling_cur_freq, or scaling_max_freq.
This is due to "turbo boost" available on recent Intel processors. If certain
conditions are met the BIOS can achieve a slightly higher speed than requested
by OSPM. An example:
scaling_cur_freq : 2933000
cpuinfo_cur_freq : 3196000
B) There is a round-off error associated with the cpuinfo_cur_freq value.
Since the driver obtains the current frequency as a "percentage" (%) of the
nominal frequency from the BIOS, sometimes, the values displayed by
scaling_cur_freq and cpuinfo_cur_freq may not match. An example:
scaling_cur_freq : 1600000
cpuinfo_cur_freq : 1583000
In this example, the nominal frequency is 2933 MHz. The driver obtains the
current frequency, cpuinfo_cur_freq, as 54% of the nominal frequency:
54% of 2933 MHz = 1583 MHz
Nominal frequency is the maximum frequency of the processor, and it usually
corresponds to the frequency of the P0 P-state.
2.4 related_cpus:
-----------------
The related_cpus field is identical to affected_cpus.
affected_cpus : 4
related_cpus : 4
Currently, the PCC driver does not evaluate _PSD. The platforms that support
PCC do not implement SW_ALL. So OSPM doesn't need to perform any coordination
to ensure that the same frequency is requested of all dependent CPUs.
3. Caveats:
-----------
The "cpufreq_stats" module in its present form cannot be loaded and
expected to work with the PCC driver. Since the "cpufreq_stats" module
provides information wrt each P-state, it is not applicable to the PCC driver.

73
Documentation/admin-guide/pm/cpuidle.rst
View File

@@ -583,20 +583,17 @@ Power Management Quality of Service for CPUs
The power management quality of service (PM QoS) framework in the Linux kernel
allows kernel code and user space processes to set constraints on various
energy-efficiency features of the kernel to prevent performance from dropping
below a required level. The PM QoS constraints can be set globally, in
predefined categories referred to as PM QoS classes, or against individual
devices.
below a required level.
CPU idle time management can be affected by PM QoS in two ways, through the
global constraint in the ``PM_QOS_CPU_DMA_LATENCY`` class and through the
resume latency constraints for individual CPUs. Kernel code (e.g. device
drivers) can set both of them with the help of special internal interfaces
provided by the PM QoS framework. User space can modify the former by opening
the :file:`cpu_dma_latency` special device file under :file:`/dev/` and writing
a binary value (interpreted as a signed 32-bit integer) to it. In turn, the
resume latency constraint for a CPU can be modified by user space by writing a
string (representing a signed 32-bit integer) to the
:file:`power/pm_qos_resume_latency_us` file under
global CPU latency limit and through the resume latency constraints for
individual CPUs. Kernel code (e.g. device drivers) can set both of them with
the help of special internal interfaces provided by the PM QoS framework. User
space can modify the former by opening the :file:`cpu_dma_latency` special
device file under :file:`/dev/` and writing a binary value (interpreted as a
signed 32-bit integer) to it. In turn, the resume latency constraint for a CPU
can be modified from user space by writing a string (representing a signed
32-bit integer) to the :file:`power/pm_qos_resume_latency_us` file under
:file:`/sys/devices/system/cpu/cpu<N>/` in ``sysfs``, where the CPU number
``<N>`` is allocated at the system initialization time. Negative values
will be rejected in both cases and, also in both cases, the written integer
@@ -605,32 +602,34 @@ number will be interpreted as a requested PM QoS constraint in microseconds.
The requested value is not automatically applied as a new constraint, however,
as it may be less restrictive (greater in this particular case) than another
constraint previously requested by someone else. For this reason, the PM QoS
framework maintains a list of requests that have been made so far in each
global class and for each device, aggregates them and applies the effective
(minimum in this particular case) value as the new constraint.
framework maintains a list of requests that have been made so far for the
global CPU latency limit and for each individual CPU, aggregates them and
applies the effective (minimum in this particular case) value as the new
constraint.
In fact, opening the :file:`cpu_dma_latency` special device file causes a new
PM QoS request to be created and added to the priority list of requests in the
``PM_QOS_CPU_DMA_LATENCY`` class and the file descriptor coming from the
"open" operation represents that request. If that file descriptor is then
used for writing, the number written to it will be associated with the PM QoS
request represented by it as a new requested constraint value. Next, the
priority list mechanism will be used to determine the new effective value of
the entire list of requests and that effective value will be set as a new
constraint. Thus setting a new requested constraint value will only change the
real constraint if the effective "list" value is affected by it. In particular,
for the ``PM_QOS_CPU_DMA_LATENCY`` class it only affects the real constraint if
it is the minimum of the requested constraints in the list. The process holding
a file descriptor obtained by opening the :file:`cpu_dma_latency` special device
file controls the PM QoS request associated with that file descriptor, but it
controls this particular PM QoS request only.
PM QoS request to be created and added to a global priority list of CPU latency
limit requests and the file descriptor coming from the "open" operation
represents that request. If that file descriptor is then used for writing, the
number written to it will be associated with the PM QoS request represented by
it as a new requested limit value. Next, the priority list mechanism will be
used to determine the new effective value of the entire list of requests and
that effective value will be set as a new CPU latency limit. Thus requesting a
new limit value will only change the real limit if the effective "list" value is
affected by it, which is the case if it is the minimum of the requested values
in the list.
The process holding a file descriptor obtained by opening the
:file:`cpu_dma_latency` special device file controls the PM QoS request
associated with that file descriptor, but it controls this particular PM QoS
request only.
Closing the :file:`cpu_dma_latency` special device file or, more precisely, the
file descriptor obtained while opening it, causes the PM QoS request associated
with that file descriptor to be removed from the ``PM_QOS_CPU_DMA_LATENCY``
class priority list and destroyed. If that happens, the priority list mechanism
will be used, again, to determine the new effective value for the whole list
and that value will become the new real constraint.
with that file descriptor to be removed from the global priority list of CPU
latency limit requests and destroyed. If that happens, the priority list
mechanism will be used again, to determine the new effective value for the whole
list and that value will become the new limit.
In turn, for each CPU there is one resume latency PM QoS request associated with
the :file:`power/pm_qos_resume_latency_us` file under
@@ -647,10 +646,10 @@ CPU in question every time the list of requests is updated this way or another
(there may be other requests coming from kernel code in that list).
CPU idle time governors are expected to regard the minimum of the global
effective ``PM_QOS_CPU_DMA_LATENCY`` class constraint and the effective
resume latency constraint for the given CPU as the upper limit for the exit
latency of the idle states they can select for that CPU. They should never
select any idle states with exit latency beyond that limit.
(effective) CPU latency limit and the effective resume latency constraint for
the given CPU as the upper limit for the exit latency of the idle states that
they are allowed to select for that CPU. They should never select any idle
states with exit latency beyond that limit.
Idle States Control Via Kernel Command Line

4
Documentation/admin-guide/pm/intel_pstate.rst
View File

@@ -734,10 +734,10 @@ References
==========
.. [1] Kristen Accardi, *Balancing Power and Performance in the Linux Kernel*,
http://events.linuxfoundation.org/sites/events/files/slides/LinuxConEurope_2015.pdf
https://events.static.linuxfound.org/sites/events/files/slides/LinuxConEurope_2015.pdf
.. [2] *Intel® 64 and IA-32 Architectures Software Developer’s Manual Volume 3: System Programming Guide*,
http://www.intel.com/content/www/us/en/architecture-and-technology/64-ia-32-architectures-software-developer-system-programming-manual-325384.html
https://www.intel.com/content/www/us/en/architecture-and-technology/64-ia-32-architectures-software-developer-system-programming-manual-325384.html
.. [3] *Advanced Configuration and Power Interface Specification*,
https://uefi.org/sites/default/files/resources/ACPI_6_3_final_Jan30.pdf

1
Documentation/admin-guide/pm/working-state.rst
View File

@@ -11,4 +11,5 @@ Working-State Power Management
intel_idle
cpufreq
intel_pstate
cpufreq_drivers
intel_epb

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

File diff suppressed because it is too large Load Diff

6
Documentation/arm/tcm.rst
View File

@@ -4,18 +4,18 @@ ARM TCM (Tightly-Coupled Memory) handling in Linux
Written by Linus Walleij <linus.walleij@stericsson.com>
Some ARM SoC:s have a so-called TCM (Tightly-Coupled Memory).
Some ARM SoCs have a so-called TCM (Tightly-Coupled Memory).
This is usually just a few (4-64) KiB of RAM inside the ARM
processor.
Due to being embedded inside the CPU The TCM has a
Due to being embedded inside the CPU, the TCM has a
Harvard-architecture, so there is an ITCM (instruction TCM)
and a DTCM (data TCM). The DTCM can not contain any
instructions, but the ITCM can actually contain data.
The size of DTCM or ITCM is minimum 4KiB so the typical
minimum configuration is 4KiB ITCM and 4KiB DTCM.
ARM CPU:s have special registers to read out status, physical
ARM CPUs have special registers to read out status, physical
location and size of TCM memories. arch/arm/include/asm/cputype.h
defines a CPUID_TCM register that you can read out from the
system control coprocessor. Documentation from ARM can be found

16
Documentation/block/capability.rst
View File

@@ -2,17 +2,9 @@
Generic Block Device Capability
===============================
This file documents the sysfs file block/<disk>/capability
This file documents the sysfs file ``block/<disk>/capability``.
capability is a hex word indicating which capabilities a specific disk
supports. For more information on bits not listed here, see
include/linux/genhd.h
``capability`` is a bitfield, printed in hexadecimal, indicating which
capabilities a specific block device supports:
GENHD_FL_MEDIA_CHANGE_NOTIFY
----------------------------
Value: 4
When this bit is set, the disk supports Asynchronous Notification
of media change events. These events will be broadcast to user
space via kernel uevent.
.. kernel-doc:: include/linux/genhd.h

6
Documentation/conf.py
View File

@@ -38,7 +38,11 @@ needs_sphinx = '1.3'
# ones.
extensions = ['kerneldoc', 'rstFlatTable', 'kernel_include', 'cdomain',
'kfigure', 'sphinx.ext.ifconfig', 'automarkup',
'maintainers_include']
'maintainers_include', 'sphinx.ext.autosectionlabel' ]
# Ensure that autosectionlabel will produce unique names
autosectionlabel_prefix_document = True
autosectionlabel_maxdepth = 2
# The name of the math extension changed on Sphinx 1.4
if (major == 1 and minor > 3) or (major > 1):

96
Documentation/core-api/index.rst
View File

@@ -8,41 +8,81 @@ This is the beginning of a manual for core kernel APIs. The conversion
Core utilities
==============
This section has general and "core core" documentation. The first is a
massive grab-bag of kerneldoc info left over from the docbook days; it
should really be broken up someday when somebody finds the energy to do
it.
.. toctree::
:maxdepth: 1
kernel-api
assoc_array
atomic_ops
cachetlb
refcount-vs-atomic
cpu_hotplug
idr
local_ops
workqueue
genericirq
xarray
librs
genalloc
errseq
packing
printk-formats
symbol-namespaces
Data structures and low-level utilities
=======================================
Library functionality that is used throughout the kernel.
.. toctree::
:maxdepth: 1
kobject
assoc_array
xarray
idr
circular-buffers
generic-radix-tree
packing
timekeeping
errseq
Concurrency primitives
======================
How Linux keeps everything from happening at the same time. See
:doc:`/locking/index` for more related documentation.
.. toctree::
:maxdepth: 1
atomic_ops
refcount-vs-atomic
local_ops
padata
../RCU/index
Low-level hardware management
=============================
Cache management, managing CPU hotplug, etc.
.. toctree::
:maxdepth: 1
cachetlb
cpu_hotplug
memory-hotplug
genericirq
protection-keys
Memory management
=================
How to allocate and use memory in the kernel. Note that there is a lot
more memory-management documentation in :doc:`/vm/index`.
.. toctree::
:maxdepth: 1
memory-allocation
mm-api
genalloc
pin_user_pages
gfp_mask-from-fs-io
timekeeping
boot-time-mm
memory-hotplug
protection-keys
../RCU/index
gcc-plugins
symbol-namespaces
padata
ioctl
gfp_mask-from-fs-io
Interfaces for kernel debugging
===============================
@@ -53,6 +93,16 @@ Interfaces for kernel debugging
debug-objects
tracepoint
Everything else
===============
Documents that don't fit elsewhere or which have yet to be categorized.
.. toctree::
:maxdepth: 1
librs
.. only:: subproject and html
Indices

78
Documentation/kobject.txt → Documentation/core-api/kobject.rst
View File

@@ -25,7 +25,7 @@ some terms we will be working with.
usually embedded within some other structure which contains the stuff
the code is really interested in.
No structure should EVER have more than one kobject embedded within it.
No structure should **EVER** have more than one kobject embedded within it.
If it does, the reference counting for the object is sure to be messed
up and incorrect, and your code will be buggy. So do not do this.
@@ -55,7 +55,7 @@ a larger, domain-specific object. To this end, kobjects will be found
embedded in other structures. If you are used to thinking of things in
object-oriented terms, kobjects can be seen as a top-level, abstract class
from which other classes are derived. A kobject implements a set of
capabilities which are not particularly useful by themselves, but which are
capabilities which are not particularly useful by themselves, but are
nice to have in other objects. The C language does not allow for the
direct expression of inheritance, so other techniques - such as structure
embedding - must be used.
@@ -65,12 +65,12 @@ this is analogous as to how "list_head" structs are rarely useful on
their own, but are invariably found embedded in the larger objects of
interest.)
So, for example, the UIO code in drivers/uio/uio.c has a structure that
So, for example, the UIO code in ``drivers/uio/uio.c`` has a structure that
defines the memory region associated with a uio device::
struct uio_map {
struct kobject kobj;
struct uio_mem *mem;
struct kobject kobj;
struct uio_mem *mem;
};
If you have a struct uio_map structure, finding its embedded kobject is
@@ -78,30 +78,30 @@ just a matter of using the kobj member. Code that works with kobjects will
often have the opposite problem, however: given a struct kobject pointer,
what is the pointer to the containing structure? You must avoid tricks
(such as assuming that the kobject is at the beginning of the structure)
and, instead, use the container_of() macro, found in <linux/kernel.h>::
and, instead, use the container_of() macro, found in ``<linux/kernel.h>``::
container_of(pointer, type, member)
where:
* "pointer" is the pointer to the embedded kobject,
* "type" is the type of the containing structure, and
* "member" is the name of the structure field to which "pointer" points.
* ``pointer`` is the pointer to the embedded kobject,
* ``type`` is the type of the containing structure, and
* ``member`` is the name of the structure field to which ``pointer`` points.
The return value from container_of() is a pointer to the corresponding
container type. So, for example, a pointer "kp" to a struct kobject
embedded *within* a struct uio_map could be converted to a pointer to the
*containing* uio_map structure with::
container type. So, for example, a pointer ``kp`` to a struct kobject
embedded **within** a struct uio_map could be converted to a pointer to the
**containing** uio_map structure with::
struct uio_map *u_map = container_of(kp, struct uio_map, kobj);
For convenience, programmers often define a simple macro for "back-casting"
For convenience, programmers often define a simple macro for **back-casting**
kobject pointers to the containing type. Exactly this happens in the
earlier drivers/uio/uio.c, as you can see here::
earlier ``drivers/uio/uio.c``, as you can see here::
struct uio_map {
struct kobject kobj;
struct uio_mem *mem;
struct kobject kobj;
struct uio_mem *mem;
};
#define to_map(map) container_of(map, struct uio_map, kobj)
@@ -125,7 +125,7 @@ must have an associated kobj_type. After calling kobject_init(), to
register the kobject with sysfs, the function kobject_add() must be called::
int kobject_add(struct kobject *kobj, struct kobject *parent,
const char *fmt, ...);
const char *fmt, ...);
This sets up the parent of the kobject and the name for the kobject
properly. If the kobject is to be associated with a specific kset,
@@ -172,13 +172,13 @@ call to kobject_uevent()::
int kobject_uevent(struct kobject *kobj, enum kobject_action action);
Use the KOBJ_ADD action for when the kobject is first added to the kernel.
Use the **KOBJ_ADD** action for when the kobject is first added to the kernel.
This should be done only after any attributes or children of the kobject
have been initialized properly, as userspace will instantly start to look
for them when this call happens.
When the kobject is removed from the kernel (details on how to do that are
below), the uevent for KOBJ_REMOVE will be automatically created by the
below), the uevent for **KOBJ_REMOVE** will be automatically created by the
kobject core, so the caller does not have to worry about doing that by
hand.
@@ -238,7 +238,7 @@ Both types of attributes used here, with a kobject that has been created
with the kobject_create_and_add(), can be of type kobj_attribute, so no
special custom attribute is needed to be created.
See the example module, samples/kobject/kobject-example.c for an
See the example module, ``samples/kobject/kobject-example.c`` for an
implementation of a simple kobject and attributes.
@@ -270,10 +270,10 @@ such a method has a form like::
void my_object_release(struct kobject *kobj)
{
struct my_object *mine = container_of(kobj, struct my_object, kobj);
struct my_object *mine = container_of(kobj, struct my_object, kobj);
/* Perform any additional cleanup on this object, then... */
kfree(mine);
/* Perform any additional cleanup on this object, then... */
kfree(mine);
}
One important point cannot be overstated: every kobject must have a
@@ -297,11 +297,11 @@ instead, it is associated with the ktype. So let us introduce struct
kobj_type::
struct kobj_type {
void (*release)(struct kobject *kobj);
const struct sysfs_ops *sysfs_ops;
struct attribute **default_attrs;
const struct kobj_ns_type_operations *(*child_ns_type)(struct kobject *kobj);
const void *(*namespace)(struct kobject *kobj);
void (*release)(struct kobject *kobj);
const struct sysfs_ops *sysfs_ops;
struct attribute **default_attrs;
const struct kobj_ns_type_operations *(*child_ns_type)(struct kobject *kobj);
const void *(*namespace)(struct kobject *kobj);
};
This structure is used to describe a particular type of kobject (or, more
@@ -352,8 +352,8 @@ created and never declared statically or on the stack. To create a new
kset use::
struct kset *kset_create_and_add(const char *name,
struct kset_uevent_ops *u,
struct kobject *parent);
struct kset_uevent_ops *u,
struct kobject *parent);
When you are finished with the kset, call::
@@ -365,16 +365,16 @@ Because other references to the kset may still exist, the release may happen
after kset_unregister() returns.
An example of using a kset can be seen in the
samples/kobject/kset-example.c file in the kernel tree.
``samples/kobject/kset-example.c`` file in the kernel tree.
If a kset wishes to control the uevent operations of the kobjects
associated with it, it can use the struct kset_uevent_ops to handle it::
struct kset_uevent_ops {
int (*filter)(struct kset *kset, struct kobject *kobj);
const char *(*name)(struct kset *kset, struct kobject *kobj);
int (*uevent)(struct kset *kset, struct kobject *kobj,
struct kobj_uevent_env *env);
int (*filter)(struct kset *kset, struct kobject *kobj);
const char *(*name)(struct kset *kset, struct kobject *kobj);
int (*uevent)(struct kset *kset, struct kobject *kobj,
struct kobj_uevent_env *env);
};
@@ -408,8 +408,8 @@ Kobject removal
After a kobject has been registered with the kobject core successfully, it
must be cleaned up when the code is finished with it. To do that, call
kobject_put(). By doing this, the kobject core will automatically clean up
all of the memory allocated by this kobject. If a KOBJ_ADD uevent has been
sent for the object, a corresponding KOBJ_REMOVE uevent will be sent, and
all of the memory allocated by this kobject. If a ``KOBJ_ADD`` uevent has been
sent for the object, a corresponding ``KOBJ_REMOVE`` uevent will be sent, and
any other sysfs housekeeping will be handled for the caller properly.
If you need to do a two-stage delete of the kobject (say you are not
@@ -430,5 +430,5 @@ Example code to copy from
=========================
For a more complete example of using ksets and kobjects properly, see the
example programs samples/kobject/{kobject-example.c,kset-example.c},
which will be built as loadable modules if you select CONFIG_SAMPLE_KOBJECT.
example programs ``samples/kobject/{kobject-example.c,kset-example.c}``,
which will be built as loadable modules if you select ``CONFIG_SAMPLE_KOBJECT``.

38
Documentation/cpu-freq/amd-powernow.txt
View File

@@ -1,38 +0,0 @@
PowerNow! and Cool'n'Quiet are AMD names for frequency
management capabilities in AMD processors. As the hardware
implementation changes in new generations of the processors,
there is a different cpu-freq driver for each generation.
Note that the driver's will not load on the "wrong" hardware,
so it is safe to try each driver in turn when in doubt as to
which is the correct driver.
Note that the functionality to change frequency (and voltage)
is not available in all processors. The drivers will refuse
to load on processors without this capability. The capability
is detected with the cpuid instruction.
The drivers use BIOS supplied tables to obtain frequency and
voltage information appropriate for a particular platform.
Frequency transitions will be unavailable if the BIOS does
not supply these tables.
6th Generation: powernow-k6
7th Generation: powernow-k7: Athlon, Duron, Geode.
8th Generation: powernow-k8: Athlon, Athlon 64, Opteron, Sempron.
Documentation on this functionality in 8th generation processors
is available in the "BIOS and Kernel Developer's Guide", publication
26094, in chapter 9, available for download from www.amd.com.
BIOS supplied data, for powernow-k7 and for powernow-k8, may be
from either the PSB table or from ACPI objects. The ACPI support
is only available if the kernel config sets CONFIG_ACPI_PROCESSOR.
The powernow-k8 driver will attempt to use ACPI if so configured,
and fall back to PST if that fails.
The powernow-k7 driver will try to use the PSB support first, and
fall back to ACPI if the PSB support fails. A module parameter,
acpi_force, is provided to force ACPI support to be used instead
of PSB support.

65
Documentation/cpu-freq/core.txt → Documentation/cpu-freq/core.rst
View File

@@ -1,31 +1,23 @@
CPU frequency and voltage scaling code in the Linux(TM) kernel
.. SPDX-License-Identifier: GPL-2.0
=============================================================
General description of the CPUFreq core and CPUFreq notifiers
=============================================================
L i n u x C P U F r e q
Authors:
- Dominik Brodowski <linux@brodo.de>
- David Kimdon <dwhedon@debian.org>
- Rafael J. Wysocki <rafael.j.wysocki@intel.com>
- Viresh Kumar <viresh.kumar@linaro.org>
C P U F r e q C o r e
.. Contents:
Dominik Brodowski <linux@brodo.de>
David Kimdon <dwhedon@debian.org>
Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Viresh Kumar <viresh.kumar@linaro.org>
Clock scaling allows you to change the clock speed of the CPUs on the
fly. This is a nice method to save battery power, because the lower
the clock speed, the less power the CPU consumes.
Contents:
---------
1. CPUFreq core and interfaces
2. CPUFreq notifiers
3. CPUFreq Table Generation with Operating Performance Point (OPP)
1. CPUFreq core and interfaces
2. CPUFreq notifiers
3. CPUFreq Table Generation with Operating Performance Point (OPP)
1. General Information
=======================
======================
The CPUFreq core code is located in drivers/cpufreq/cpufreq.c. This
cpufreq code offers a standardized interface for the CPUFreq
@@ -63,7 +55,7 @@ The phase is specified in the second argument to the notifier. The phase is
CPUFREQ_CREATE_POLICY when the policy is first created and it is
CPUFREQ_REMOVE_POLICY when the policy is removed.
The third argument, a void *pointer, points to a struct cpufreq_policy
The third argument, a ``void *pointer``, points to a struct cpufreq_policy
consisting of several values, including min, max (the lower and upper
frequencies (in kHz) of the new policy).
@@ -80,10 +72,13 @@ CPUFREQ_POSTCHANGE.
The third argument is a struct cpufreq_freqs with the following
values:
cpu - number of the affected CPU
old - old frequency
new - new frequency
flags - flags of the cpufreq driver
===== ===========================
cpu number of the affected CPU
old old frequency
new new frequency
flags flags of the cpufreq driver
===== ===========================
3. CPUFreq Table Generation with Operating Performance Point (OPP)
==================================================================
@@ -94,9 +89,12 @@ dev_pm_opp_init_cpufreq_table -
the OPP layer's internal information about the available frequencies
into a format readily providable to cpufreq.
WARNING: Do not use this function in interrupt context.
.. Warning::
Do not use this function in interrupt context.
Example::
Example:
soc_pm_init()
{
/* Do things */
@@ -106,7 +104,10 @@ dev_pm_opp_init_cpufreq_table -
/* Do other things */
}
NOTE: This function is available only if CONFIG_CPU_FREQ is enabled in
addition to CONFIG_PM_OPP.
.. note::
dev_pm_opp_free_cpufreq_table - Free up the table allocated by dev_pm_opp_init_cpufreq_table
This function is available only if CONFIG_CPU_FREQ is enabled in
addition to CONFIG_PM_OPP.
dev_pm_opp_free_cpufreq_table
Free up the table allocated by dev_pm_opp_init_cpufreq_table

133
Documentation/cpu-freq/cpu-drivers.txt → Documentation/cpu-freq/cpu-drivers.rst
View File

@@ -1,35 +1,27 @@
CPU frequency and voltage scaling code in the Linux(TM) kernel
.. SPDX-License-Identifier: GPL-2.0
===============================================
How to Implement a new CPUFreq Processor Driver
===============================================
Authors:
L i n u x C P U F r e q
- Dominik Brodowski <linux@brodo.de>
- Rafael J. Wysocki <rafael.j.wysocki@intel.com>
- Viresh Kumar <viresh.kumar@linaro.org>
C P U D r i v e r s
.. Contents
- information for developers -
Dominik Brodowski <linux@brodo.de>
Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Viresh Kumar <viresh.kumar@linaro.org>
Clock scaling allows you to change the clock speed of the CPUs on the
fly. This is a nice method to save battery power, because the lower
the clock speed, the less power the CPU consumes.
Contents:
---------
1. What To Do?
1.1 Initialization
1.2 Per-CPU Initialization
1.3 verify
1.4 target/target_index or setpolicy?
1.5 target/target_index
1.6 setpolicy
1.7 get_intermediate and target_intermediate
2. Frequency Table Helpers
1. What To Do?
1.1 Initialization
1.2 Per-CPU Initialization
1.3 verify
1.4 target/target_index or setpolicy?
1.5 target/target_index
1.6 setpolicy
1.7 get_intermediate and target_intermediate
2. Frequency Table Helpers
@@ -49,7 +41,7 @@ function check whether this kernel runs on the right CPU and the right
chipset. If so, register a struct cpufreq_driver with the CPUfreq core
using cpufreq_register_driver()
What shall this struct cpufreq_driver contain?
What shall this struct cpufreq_driver contain?
.name - The name of this driver.
@@ -108,37 +100,42 @@ Whenever a new CPU is registered with the device model, or after the
cpufreq driver registers itself, the per-policy initialization function
cpufreq_driver.init is called if no cpufreq policy existed for the CPU.
Note that the .init() and .exit() routines are called only once for the
policy and not for each CPU managed by the policy. It takes a struct
cpufreq_policy *policy as argument. What to do now?
policy and not for each CPU managed by the policy. It takes a ``struct
cpufreq_policy *policy`` as argument. What to do now?
If necessary, activate the CPUfreq support on your CPU.
Then, the driver must fill in the following values:
policy->cpuinfo.min_freq _and_
policy->cpuinfo.max_freq - the minimum and maximum frequency
(in kHz) which is supported by
this CPU
policy->cpuinfo.transition_latency the time it takes on this CPU to
switch between two frequencies in
nanoseconds (if appropriate, else
specify CPUFREQ_ETERNAL)
policy->cur The current operating frequency of
this CPU (if appropriate)
policy->min,
policy->max,
policy->policy and, if necessary,
policy->governor must contain the "default policy" for
this CPU. A few moments later,
cpufreq_driver.verify and either
cpufreq_driver.setpolicy or
cpufreq_driver.target/target_index is called
with these values.
policy->cpus Update this with the masks of the
(online + offline) CPUs that do DVFS
along with this CPU (i.e. that share
clock/voltage rails with it).
+-----------------------------------+--------------------------------------+
|policy->cpuinfo.min_freq _and_ | |
|policy->cpuinfo.max_freq | the minimum and maximum frequency |
| | (in kHz) which is supported by |
| | this CPU |
+-----------------------------------+--------------------------------------+
|policy->cpuinfo.transition_latency | the time it takes on this CPU to |
| | switch between two frequencies in |
| | nanoseconds (if appropriate, else |
| | specify CPUFREQ_ETERNAL) |
+-----------------------------------+--------------------------------------+
|policy->cur | The current operating frequency of |
| | this CPU (if appropriate) |
+-----------------------------------+--------------------------------------+
|policy->min, | |
|policy->max, | |
|policy->policy and, if necessary, | |
|policy->governor | must contain the "default policy" for|
| | this CPU. A few moments later, |
| | cpufreq_driver.verify and either |
| | cpufreq_driver.setpolicy or |
| | cpufreq_driver.target/target_index is|
| | called with these values. |
+-----------------------------------+--------------------------------------+
|policy->cpus | Update this with the masks of the |
| | (online + offline) CPUs that do DVFS |
| | along with this CPU (i.e. that share|
| | clock/voltage rails with it). |
+-----------------------------------+--------------------------------------+
For setting some of these values (cpuinfo.min[max]_freq, policy->min[max]), the
frequency table helpers might be helpful. See the section 2 for more information
@@ -151,8 +148,8 @@ on them.
When the user decides a new policy (consisting of
"policy,governor,min,max") shall be set, this policy must be validated
so that incompatible values can be corrected. For verifying these
values cpufreq_verify_within_limits(struct cpufreq_policy *policy,
unsigned int min_freq, unsigned int max_freq) function might be helpful.
values cpufreq_verify_within_limits(``struct cpufreq_policy *policy``,
``unsigned int min_freq``, ``unsigned int max_freq``) function might be helpful.
See section 2 for details on frequency table helpers.
You need to make sure that at least one valid frequency (or operating
@@ -163,7 +160,7 @@ policy->max first, and only if this is no solution, decrease policy->min.
1.4 target or target_index or setpolicy or fast_switch?
-------------------------------------------------------
Most cpufreq drivers or even most cpu frequency scaling algorithms
Most cpufreq drivers or even most cpu frequency scaling algorithms
only allow the CPU frequency to be set to predefined fixed values. For
these, you use the ->target(), ->target_index() or ->fast_switch()
callbacks.
@@ -175,8 +172,8 @@ limits on their own. These shall use the ->setpolicy() callback.
1.5. target/target_index
------------------------
The target_index call has two arguments: struct cpufreq_policy *policy,
and unsigned int index (into the exposed frequency table).
The target_index call has two arguments: ``struct cpufreq_policy *policy``,
and ``unsigned int`` index (into the exposed frequency table).
The CPUfreq driver must set the new frequency when called here. The
actual frequency must be determined by freq_table[index].frequency.
@@ -184,9 +181,9 @@ actual frequency must be determined by freq_table[index].frequency.
It should always restore to earlier frequency (i.e. policy->restore_freq) in
case of errors, even if we switched to intermediate frequency earlier.
Deprecated:
Deprecated
----------
The target call has three arguments: struct cpufreq_policy *policy,
The target call has three arguments: ``struct cpufreq_policy *policy``,
unsigned int target_frequency, unsigned int relation.
The CPUfreq driver must set the new frequency when called here. The
@@ -210,14 +207,14 @@ Not all drivers are expected to implement it, as sleeping from within
this callback isn't allowed. This callback must be highly optimized to
do switching as fast as possible.
This function has two arguments: struct cpufreq_policy *policy and
unsigned int target_frequency.
This function has two arguments: ``struct cpufreq_policy *policy`` and
``unsigned int target_frequency``.
1.7 setpolicy
-------------
The setpolicy call only takes a struct cpufreq_policy *policy as
The setpolicy call only takes a ``struct cpufreq_policy *policy`` as
argument. You need to set the lower limit of the in-processor or
in-chipset dynamic frequency switching to policy->min, the upper limit
to policy->max, and -if supported- select a performance-oriented
@@ -278,10 +275,10 @@ table.
cpufreq_for_each_valid_entry(pos, table) - iterates over all entries,
excluding CPUFREQ_ENTRY_INVALID frequencies.
Use arguments "pos" - a cpufreq_frequency_table * as a loop cursor and
"table" - the cpufreq_frequency_table * you want to iterate over.
Use arguments "pos" - a ``cpufreq_frequency_table *`` as a loop cursor and
"table" - the ``cpufreq_frequency_table *`` you want to iterate over.
For example:
For example::
struct cpufreq_frequency_table *pos, *driver_freq_table;

19
Documentation/cpu-freq/cpufreq-nforce2.txt
View File

@@ -1,19 +0,0 @@
The cpufreq-nforce2 driver changes the FSB on nVidia nForce2 platforms.
This works better than on other platforms, because the FSB of the CPU
can be controlled independently from the PCI/AGP clock.
The module has two options:
fid: multiplier * 10 (for example 8.5 = 85)
min_fsb: minimum FSB
If not set, fid is calculated from the current CPU speed and the FSB.
min_fsb defaults to FSB at boot time - 50 MHz.
IMPORTANT: The available range is limited downwards!
Also the minimum available FSB can differ, for systems
booting with 200 MHz, 150 should always work.

119
Documentation/cpu-freq/cpufreq-stats.txt → Documentation/cpu-freq/cpufreq-stats.rst
View File

@@ -1,21 +1,23 @@
.. SPDX-License-Identifier: GPL-2.0
CPU frequency and voltage scaling statistics in the Linux(TM) kernel
==========================================
General Description of sysfs CPUFreq Stats
==========================================
information for users
L i n u x c p u f r e q - s t a t s d r i v e r
Author: Venkatesh Pallipadi <venkatesh.pallipadi@intel.com>
- information for users -
.. Contents
Venkatesh Pallipadi <venkatesh.pallipadi@intel.com>
Contents
1. Introduction
2. Statistics Provided (with example)
3. Configuring cpufreq-stats
1. Introduction
2. Statistics Provided (with example)
3. Configuring cpufreq-stats
1. Introduction
===============
cpufreq-stats is a driver that provides CPU frequency statistics for each CPU.
These statistics are provided in /sysfs as a bunch of read_only interfaces. This
@@ -28,8 +30,10 @@ that may be running on your CPU. So, it will work with any cpufreq_driver.
2. Statistics Provided (with example)
=====================================
cpufreq stats provides following statistics (explained in detail below).
- time_in_state
- total_trans
- trans_table
@@ -39,53 +43,57 @@ All the statistics will be from the time the stats driver has been inserted
statistic is done. Obviously, stats driver will not have any information
about the frequency transitions before the stats driver insertion.
--------------------------------------------------------------------------------
<mysystem>:/sys/devices/system/cpu/cpu0/cpufreq/stats # ls -l
total 0
drwxr-xr-x 2 root root 0 May 14 16:06 .
drwxr-xr-x 3 root root 0 May 14 15:58 ..
--w------- 1 root root 4096 May 14 16:06 reset
-r--r--r-- 1 root root 4096 May 14 16:06 time_in_state
-r--r--r-- 1 root root 4096 May 14 16:06 total_trans
-r--r--r-- 1 root root 4096 May 14 16:06 trans_table
--------------------------------------------------------------------------------
::
<mysystem>:/sys/devices/system/cpu/cpu0/cpufreq/stats # ls -l
total 0
drwxr-xr-x 2 root root 0 May 14 16:06 .
drwxr-xr-x 3 root root 0 May 14 15:58 ..
--w------- 1 root root 4096 May 14 16:06 reset
-r--r--r-- 1 root root 4096 May 14 16:06 time_in_state
-r--r--r-- 1 root root 4096 May 14 16:06 total_trans
-r--r--r-- 1 root root 4096 May 14 16:06 trans_table
- **reset**
- reset
Write-only attribute that can be used to reset the stat counters. This can be
useful for evaluating system behaviour under different governors without the
need for a reboot.
- time_in_state
- **time_in_state**
This gives the amount of time spent in each of the frequencies supported by
this CPU. The cat output will have "<frequency> <time>" pair in each line, which
will mean this CPU spent <time> usertime units of time at <frequency>. Output
will have one line for each of the supported frequencies. usertime units here
will have one line for each of the supported frequencies. usertime units here
is 10mS (similar to other time exported in /proc).
--------------------------------------------------------------------------------
<mysystem>:/sys/devices/system/cpu/cpu0/cpufreq/stats # cat time_in_state
3600000 2089
3400000 136
3200000 34
3000000 67
2800000 172488
--------------------------------------------------------------------------------
::
<mysystem>:/sys/devices/system/cpu/cpu0/cpufreq/stats # cat time_in_state
3600000 2089
3400000 136
3200000 34
3000000 67
2800000 172488
- total_trans
This gives the total number of frequency transitions on this CPU. The cat
- **total_trans**
This gives the total number of frequency transitions on this CPU. The cat
output will have a single count which is the total number of frequency
transitions.
--------------------------------------------------------------------------------
<mysystem>:/sys/devices/system/cpu/cpu0/cpufreq/stats # cat total_trans
20
--------------------------------------------------------------------------------
::
<mysystem>:/sys/devices/system/cpu/cpu0/cpufreq/stats # cat total_trans
20
- **trans_table**
- trans_table
This will give a fine grained information about all the CPU frequency
transitions. The cat output here is a two dimensional matrix, where an entry
<i,j> (row i, column j) represents the count of number of transitions from
<i,j> (row i, column j) represents the count of number of transitions from
Freq_i to Freq_j. Freq_i rows and Freq_j columns follow the sorting order in
which the driver has provided the frequency table initially to the cpufreq core
and so can be sorted (ascending or descending) or unsorted. The output here
@@ -95,26 +103,27 @@ readability.
If the transition table is bigger than PAGE_SIZE, reading this will
return an -EFBIG error.
--------------------------------------------------------------------------------
<mysystem>:/sys/devices/system/cpu/cpu0/cpufreq/stats # cat trans_table
From : To
: 3600000 3400000 3200000 3000000 2800000
3600000: 0 5 0 0 0
3400000: 4 0 2 0 0
3200000: 0 1 0 2 0
3000000: 0 0 1 0 3
2800000: 0 0 0 2 0
--------------------------------------------------------------------------------
::
<mysystem>:/sys/devices/system/cpu/cpu0/cpufreq/stats # cat trans_table
From : To
: 3600000 3400000 3200000 3000000 2800000
3600000: 0 5 0 0 0
3400000: 4 0 2 0 0
3200000: 0 1 0 2 0
3000000: 0 0 1 0 3
2800000: 0 0 0 2 0
3. Configuring cpufreq-stats
============================
To configure cpufreq-stats in your kernel
Config Main Menu
Power management options (ACPI, APM) --->
CPU Frequency scaling --->
[*] CPU Frequency scaling
[*] CPU frequency translation statistics
To configure cpufreq-stats in your kernel::
Config Main Menu
Power management options (ACPI, APM) --->
CPU Frequency scaling --->
[*] CPU Frequency scaling
[*] CPU frequency translation statistics
"CPU Frequency scaling" (CONFIG_CPU_FREQ) should be enabled to configure

39
Documentation/cpu-freq/index.rst Normal file
View File

@@ -0,0 +1,39 @@
.. SPDX-License-Identifier: GPL-2.0
==============================================================================
Linux CPUFreq - CPU frequency and voltage scaling code in the Linux(TM) kernel
==============================================================================
Author: Dominik Brodowski <linux@brodo.de>
Clock scaling allows you to change the clock speed of the CPUs on the
fly. This is a nice method to save battery power, because the lower
the clock speed, the less power the CPU consumes.
.. toctree::
:maxdepth: 1
core
cpu-drivers
cpufreq-stats
Mailing List
------------
There is a CPU frequency changing CVS commit and general list where
you can report bugs, problems or submit patches. To post a message,
send an email to linux-pm@vger.kernel.org.
Links
-----
the FTP archives:
* ftp://ftp.linux.org.uk/pub/linux/cpufreq/
how to access the CVS repository:
* http://cvs.arm.linux.org.uk/
the CPUFreq Mailing list:
* http://vger.kernel.org/vger-lists.html#linux-pm
Clock and voltage scaling for the SA-1100:
* http://www.lartmaker.nl/projects/scaling

56
Documentation/cpu-freq/index.txt
View File

@@ -1,56 +0,0 @@
CPU frequency and voltage scaling code in the Linux(TM) kernel
L i n u x C P U F r e q
Dominik Brodowski <linux@brodo.de>
Clock scaling allows you to change the clock speed of the CPUs on the
fly. This is a nice method to save battery power, because the lower
the clock speed, the less power the CPU consumes.
Documents in this directory:
----------------------------
amd-powernow.txt - AMD powernow driver specific file.
core.txt - General description of the CPUFreq core and
of CPUFreq notifiers.
cpu-drivers.txt - How to implement a new cpufreq processor driver.
cpufreq-nforce2.txt - nVidia nForce2 platform specific file.
cpufreq-stats.txt - General description of sysfs cpufreq stats.
index.txt - File index, Mailing list and Links (this document)
pcc-cpufreq.txt - PCC cpufreq driver specific file.
Mailing List
------------
There is a CPU frequency changing CVS commit and general list where
you can report bugs, problems or submit patches. To post a message,
send an email to linux-pm@vger.kernel.org.
Links
-----
the FTP archives:
* ftp://ftp.linux.org.uk/pub/linux/cpufreq/
how to access the CVS repository:
* http://cvs.arm.linux.org.uk/
the CPUFreq Mailing list:
* http://vger.kernel.org/vger-lists.html#linux-pm
Clock and voltage scaling for the SA-1100:
* http://www.lartmaker.nl/projects/scaling

207
Documentation/cpu-freq/pcc-cpufreq.txt
View File

@@ -1,207 +0,0 @@
/*
* pcc-cpufreq.txt - PCC interface documentation
*
* Copyright (C) 2009 Red Hat, Matthew Garrett <mjg@redhat.com>
* Copyright (C) 2009 Hewlett-Packard Development Company, L.P.
* Nagananda Chumbalkar <nagananda.chumbalkar@hp.com>
*
* ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
*
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License as published by
* the Free Software Foundation; version 2 of the License.
*
* This program is distributed in the hope that it will be useful, but
* WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE, GOOD TITLE or NON
* INFRINGEMENT. See the GNU General Public License for more details.
*
* You should have received a copy of the GNU General Public License along
* with this program; if not, write to the Free Software Foundation, Inc.,
* 675 Mass Ave, Cambridge, MA 02139, USA.
*
* ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
*/
Processor Clocking Control Driver
---------------------------------
Contents:
---------
1. Introduction
1.1 PCC interface
1.1.1 Get Average Frequency
1.1.2 Set Desired Frequency
1.2 Platforms affected
2. Driver and /sys details
2.1 scaling_available_frequencies
2.2 cpuinfo_transition_latency
2.3 cpuinfo_cur_freq
2.4 related_cpus
3. Caveats
1. Introduction:
----------------
Processor Clocking Control (PCC) is an interface between the platform
firmware and OSPM. It is a mechanism for coordinating processor
performance (ie: frequency) between the platform firmware and the OS.
The PCC driver (pcc-cpufreq) allows OSPM to take advantage of the PCC
interface.
OS utilizes the PCC interface to inform platform firmware what frequency the
OS wants for a logical processor. The platform firmware attempts to achieve
the requested frequency. If the request for the target frequency could not be
satisfied by platform firmware, then it usually means that power budget
conditions are in place, and "power capping" is taking place.
1.1 PCC interface:
------------------
The complete PCC specification is available here:
http://www.acpica.org/download/Processor-Clocking-Control-v1p0.pdf
PCC relies on a shared memory region that provides a channel for communication
between the OS and platform firmware. PCC also implements a "doorbell" that
is used by the OS to inform the platform firmware that a command has been
sent.
The ACPI PCCH() method is used to discover the location of the PCC shared
memory region. The shared memory region header contains the "command" and
"status" interface. PCCH() also contains details on how to access the platform
doorbell.
The following commands are supported by the PCC interface:
* Get Average Frequency
* Set Desired Frequency
The ACPI PCCP() method is implemented for each logical processor and is
used to discover the offsets for the input and output buffers in the shared
memory region.
When PCC mode is enabled, the platform will not expose processor performance
or throttle states (_PSS, _TSS and related ACPI objects) to OSPM. Therefore,
the native P-state driver (such as acpi-cpufreq for Intel, powernow-k8 for
AMD) will not load.
However, OSPM remains in control of policy. The governor (eg: "ondemand")
computes the required performance for each processor based on server workload.
The PCC driver fills in the command interface, and the input buffer and
communicates the request to the platform firmware. The platform firmware is
responsible for delivering the requested performance.
Each PCC command is "global" in scope and can affect all the logical CPUs in
the system. Therefore, PCC is capable of performing "group" updates. With PCC
the OS is capable of getting/setting the frequency of all the logical CPUs in
the system with a single call to the BIOS.
1.1.1 Get Average Frequency:
----------------------------
This command is used by the OSPM to query the running frequency of the
processor since the last time this command was completed. The output buffer
indicates the average unhalted frequency of the logical processor expressed as
a percentage of the nominal (ie: maximum) CPU frequency. The output buffer
also signifies if the CPU frequency is limited by a power budget condition.
1.1.2 Set Desired Frequency:
----------------------------
This command is used by the OSPM to communicate to the platform firmware the
desired frequency for a logical processor. The output buffer is currently
ignored by OSPM. The next invocation of "Get Average Frequency" will inform
OSPM if the desired frequency was achieved or not.
1.2 Platforms affected:
-----------------------
The PCC driver will load on any system where the platform firmware:
* supports the PCC interface, and the associated PCCH() and PCCP() methods
* assumes responsibility for managing the hardware clocking controls in order
to deliver the requested processor performance
Currently, certain HP ProLiant platforms implement the PCC interface. On those
platforms PCC is the "default" choice.
However, it is possible to disable this interface via a BIOS setting. In
such an instance, as is also the case on platforms where the PCC interface
is not implemented, the PCC driver will fail to load silently.
2. Driver and /sys details:
---------------------------
When the driver loads, it merely prints the lowest and the highest CPU
frequencies supported by the platform firmware.
The PCC driver loads with a message such as:
pcc-cpufreq: (v1.00.00) driver loaded with frequency limits: 1600 MHz, 2933
MHz
This means that the OPSM can request the CPU to run at any frequency in
between the limits (1600 MHz, and 2933 MHz) specified in the message.
Internally, there is no need for the driver to convert the "target" frequency
to a corresponding P-state.
The VERSION number for the driver will be of the format v.xy.ab.
eg: 1.00.02
----- --
| |
| -- this will increase with bug fixes/enhancements to the driver
|-- this is the version of the PCC specification the driver adheres to
The following is a brief discussion on some of the fields exported via the
/sys filesystem and how their values are affected by the PCC driver:
2.1 scaling_available_frequencies:
----------------------------------
scaling_available_frequencies is not created in /sys. No intermediate
frequencies need to be listed because the BIOS will try to achieve any
frequency, within limits, requested by the governor. A frequency does not have
to be strictly associated with a P-state.
2.2 cpuinfo_transition_latency:
-------------------------------
The cpuinfo_transition_latency field is 0. The PCC specification does
not include a field to expose this value currently.
2.3 cpuinfo_cur_freq:
---------------------
A) Often cpuinfo_cur_freq will show a value different than what is declared
in the scaling_available_frequencies or scaling_cur_freq, or scaling_max_freq.
This is due to "turbo boost" available on recent Intel processors. If certain
conditions are met the BIOS can achieve a slightly higher speed than requested
by OSPM. An example:
scaling_cur_freq : 2933000
cpuinfo_cur_freq : 3196000
B) There is a round-off error associated with the cpuinfo_cur_freq value.
Since the driver obtains the current frequency as a "percentage" (%) of the
nominal frequency from the BIOS, sometimes, the values displayed by
scaling_cur_freq and cpuinfo_cur_freq may not match. An example:
scaling_cur_freq : 1600000
cpuinfo_cur_freq : 1583000
In this example, the nominal frequency is 2933 MHz. The driver obtains the
current frequency, cpuinfo_cur_freq, as 54% of the nominal frequency:
54% of 2933 MHz = 1583 MHz
Nominal frequency is the maximum frequency of the processor, and it usually
corresponds to the frequency of the P0 P-state.
2.4 related_cpus:
-----------------
The related_cpus field is identical to affected_cpus.
affected_cpus : 4
related_cpus : 4
Currently, the PCC driver does not evaluate _PSD. The platforms that support
PCC do not implement SW_ALL. So OSPM doesn't need to perform any coordination
to ensure that the same frequency is requested of all dependent CPUs.
3. Caveats:
-----------
The "cpufreq_stats" module in its present form cannot be loaded and
expected to work with the PCC driver. Since the "cpufreq_stats" module
provides information wrt each P-state, it is not applicable to the PCC driver.

22
Documentation/debugging-modules.txt
View File

@@ -1,22 +0,0 @@
Debugging Modules after 2.6.3
-----------------------------
In almost all distributions, the kernel asks for modules which don't
exist, such as "net-pf-10" or whatever. Changing "modprobe -q" to
"succeed" in this case is hacky and breaks some setups, and also we
want to know if it failed for the fallback code for old aliases in
fs/char_dev.c, for example.
In the past a debugging message which would fill people's logs was
emitted. This debugging message has been removed. The correct way
of debugging module problems is something like this:
echo '#! /bin/sh' > /tmp/modprobe
echo 'echo "$@" >> /tmp/modprobe.log' >> /tmp/modprobe
echo 'exec /sbin/modprobe "$@"' >> /tmp/modprobe
chmod a+x /tmp/modprobe
echo /tmp/modprobe > /proc/sys/kernel/modprobe
Note that the above applies only when the *kernel* is requesting
that the module be loaded -- it won't have any effect if that module
is being loaded explicitly using "modprobe" from userspace.

2
Documentation/dev-tools/gcov.rst
View File

@@ -203,7 +203,7 @@ Cause
may not correctly copy files from sysfs.
Solution
Use ``cat``' to read ``.gcda`` files and ``cp -d`` to copy links.
Use ``cat`` to read ``.gcda`` files and ``cp -d`` to copy links.
Alternatively use the mechanism shown in Appendix B.

3
Documentation/dev-tools/kmemleak.rst
View File

@@ -8,7 +8,8 @@ with the difference that the orphan objects are not freed but only
reported via /sys/kernel/debug/kmemleak. A similar method is used by the
Valgrind tool (``memcheck --leak-check``) to detect the memory leaks in
user-space applications.
Kmemleak is supported on x86, arm, powerpc, sparc, sh, microblaze, ppc, mips, s390 and tile.
Kmemleak is supported on x86, arm, arm64, powerpc, sparc, sh, microblaze, mips,
s390, nds32, arc and xtensa.
Usage
-----

6
Documentation/devicetree/bindings/display/connector/analog-tv-connector.txt
View File

@@ -6,16 +6,22 @@ Required properties:
Optional properties:
- label: a symbolic name for the connector
- sdtv-standards: limit the supported TV standards on a connector to the given
ones. If not specified all TV standards are allowed.
Possible TV standards are defined in
include/dt-bindings/display/sdtv-standards.h.
Required nodes:
- Video port for TV input
Example
-------
#include <dt-bindings/display/sdtv-standards.h>
tv: connector {
compatible = "composite-video-connector";
label = "tv";
sdtv-standards = <(SDTV_STD_PAL | SDTV_STD_NTSC)>;
port {
tv_connector_in: endpoint {

59
Documentation/devicetree/bindings/edac/dmc-520.yaml Normal file
View File

@@ -0,0 +1,59 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/edac/dmc-520.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: ARM DMC-520 EDAC bindings
maintainers:
- Lei Wang <lewan@microsoft.com>
description: |+
DMC-520 node is defined to describe DRAM error detection and correction.
https://static.docs.arm.com/100000/0200/corelink_dmc520_trm_100000_0200_01_en.pdf
properties:
compatible:
items:
- const: brcm,dmc-520
- const: arm,dmc-520
reg:
maxItems: 1
interrupts:
minItems: 1
maxItems: 10
interrupt-names:
minItems: 1
maxItems: 10
items:
enum:
- ram_ecc_errc
- ram_ecc_errd
- dram_ecc_errc
- dram_ecc_errd
- failed_access
- failed_prog
- link_err
- temperature_event
- arch_fsm
- phy_request
required:
- compatible
- reg
- interrupts
- interrupt-names
examples:
- |
dmc0: dmc@200000 {
compatible = "brcm,dmc-520", "arm,dmc-520";
reg = <0x200000 0x80000>;
interrupts = <0x0 0x349 0x4>, <0x0 0x34B 0x4>;
interrupt-names = "dram_ecc_errc", "dram_ecc_errd";
};

36
Documentation/devicetree/bindings/fsi/ibm,fsi2spi.yaml Normal file
View File

@@ -0,0 +1,36 @@
# SPDX-License-Identifier: (GPL-2.0-or-later)
%YAML 1.2
---
$id: http://devicetree.org/schemas/fsi/ibm,fsi2spi.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: IBM FSI-attached SPI controllers
maintainers:
- Eddie James <eajames@linux.ibm.com>
description: |
This binding describes an FSI CFAM engine called the FSI2SPI. Therefore this
node will always be a child of an FSI CFAM node; see fsi.txt for details on
FSI slave and CFAM nodes. This FSI2SPI engine provides access to a number of
SPI controllers.
properties:
compatible:
enum:
- ibm,fsi2spi
reg:
items:
- description: FSI slave address
required:
- compatible
- reg
examples:
- |
fsi2spi@1c00 {
compatible = "ibm,fsi2spi";
reg = <0x1c00 0x400>;
};

62
Documentation/devicetree/bindings/hwmon/adi,axi-fan-control.yaml Normal file
View File

@@ -0,0 +1,62 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
# Copyright 2019 Analog Devices Inc.
%YAML 1.2
---
$id: http://devicetree.org/schemas/bindings/hwmon/adi,axi-fan-control.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Analog Devices AXI FAN Control Device Tree Bindings
maintainers:
- Nuno Sá <nuno.sa@analog.com>
description: |+
Bindings for the Analog Devices AXI FAN Control driver. Spefications of the
core can be found in:
https://wiki.analog.com/resources/fpga/docs/axi_fan_control
properties:
compatible:
enum:
- adi,axi-fan-control-1.00.a
reg:
maxItems: 1
clocks:
maxItems: 1
interrupts:
maxItems: 1
pulses-per-revolution:
description:
Value specifying the number of pulses per revolution of the controlled
FAN.
allOf:
- $ref: /schemas/types.yaml#/definitions/uint32
enum: [1, 2, 4]
required:
- compatible
- reg
- clocks
- interrupts
- pulses-per-revolution
examples:
- |
fpga_axi: fpga-axi@0 {
#address-cells = <0x2>;
#size-cells = <0x1>;
axi_fan_control: axi-fan-control@80000000 {
compatible = "adi,axi-fan-control-1.00.a";
reg = <0x0 0x80000000 0x10000>;
clocks = <&clk 71>;
interrupts = <0 110 0>;
pulses-per-revolution = <2>;
};
};
...

84
Documentation/devicetree/bindings/hwmon/adt7475.yaml Normal file
View File

@@ -0,0 +1,84 @@
# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/adt7475.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: ADT7475 hwmon sensor
maintainers:
- Jean Delvare <jdelvare@suse.com>
description: |
The ADT7473, ADT7475, ADT7476, and ADT7490 are thermal monitors and multiple
PWN fan controllers.
They support monitoring and controlling up to four fans (the ADT7490 can only
control up to three). They support reading a single on chip temperature
sensor and two off chip temperature sensors (the ADT7490 additionally
supports measuring up to three current external temperature sensors with
series resistance cancellation (SRC)).
Datasheets:
https://www.onsemi.com/pub/Collateral/ADT7473-D.PDF
https://www.onsemi.com/pub/Collateral/ADT7475-D.PDF
https://www.onsemi.com/pub/Collateral/ADT7476-D.PDF
https://www.onsemi.com/pub/Collateral/ADT7490-D.PDF
Description taken from onsemiconductors specification sheets, with minor
rephrasing.
properties:
compatible:
enum:
- adi,adt7473
- adi,adt7475
- adi,adt7476
- adi,adt7490
reg:
maxItems: 1
patternProperties:
"^adi,bypass-attenuator-in[0-4]$":
description: |
Configures bypassing the individual voltage input attenuator. If
set to 1 the attenuator is bypassed if set to 0 the attenuator is
not bypassed. If the property is absent then the attenuator
retains it's configuration from the bios/bootloader.
allOf:
- $ref: /schemas/types.yaml#/definitions/uint32
- enum: [0, 1]
"^adi,pwm-active-state$":
description: |
Integer array, represents the active state of the pwm outputs If set to 0
the pwm uses a logic low output for 100% duty cycle. If set to 1 the pwm
uses a logic high output for 100% duty cycle.
allOf:
- $ref: /schemas/types.yaml#/definitions/uint32-array
- minItems: 3
maxItems: 3
items:
enum: [0, 1]
default: 1
required:
- compatible
- reg
examples:
- |
i2c {
#address-cells = <1>;
#size-cells = <0>;
hwmon@2e {
compatible = "adi,adt7476";
reg = <0x2e>;
adi,bypass-attenuator-in0 = <1>;
adi,bypass-attenuator-in1 = <0>;
adi,pwm-active-state = <1 0 1>;
};
};

22
Documentation/devicetree/bindings/hwmon/ltc2978.txt
View File

@@ -2,20 +2,30 @@ ltc2978
Required properties:
- compatible: should contain one of:
* "lltc,ltc2972"
* "lltc,ltc2974"
* "lltc,ltc2975"
* "lltc,ltc2977"
* "lltc,ltc2978"
* "lltc,ltc2979"
* "lltc,ltc2980"
* "lltc,ltc3880"
* "lltc,ltc3882"
* "lltc,ltc3883"
* "lltc,ltc3884"
* "lltc,ltc3886"
* "lltc,ltc3887"
* "lltc,ltc3889"
* "lltc,ltc7880"
* "lltc,ltm2987"
* "lltc,ltm4664"
* "lltc,ltm4675"
* "lltc,ltm4676"
* "lltc,ltm4677"
* "lltc,ltm4678"
* "lltc,ltm4680"
* "lltc,ltm4686"
* "lltc,ltm4700"
- reg: I2C slave address
Optional properties:
@@ -25,13 +35,17 @@ Optional properties:
standard binding for regulators; see regulator.txt.
Valid names of regulators depend on number of supplies supported per device:
* ltc2972 vout0 - vout1
* ltc2974, ltc2975 : vout0 - vout3
* ltc2977, ltc2980, ltm2987 : vout0 - vout7
* ltc2977, ltc2979, ltc2980, ltm2987 : vout0 - vout7
* ltc2978 : vout0 - vout7
* ltc3880, ltc3882, ltc3886 : vout0 - vout1
* ltc3880, ltc3882, ltc3884, ltc3886, ltc3887, ltc3889 : vout0 - vout1
* ltc7880 : vout0 - vout1
* ltc3883 : vout0
* ltm4676 : vout0 - vout1
* ltm4686 : vout0 - vout1
* ltm4664 : vout0 - vout1
* ltm4675, ltm4676, ltm4677, ltm4678 : vout0 - vout1
* ltm4680, ltm4686 : vout0 - vout1
* ltm4700 : vout0 - vout1
Example:
ltc2978@5e {

65
Documentation/devicetree/bindings/iio/adc/adi,ad7923.yaml Normal file
View File

@@ -0,0 +1,65 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/iio/adc/adi,ad7923.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Analog Devices AD7923 and similars with 4 and 8 Channel ADCs.
maintainers:
- Michael Hennerich <michael.hennerich@analog.com>
- Patrick Vasseur <patrick.vasseur@c-s.fr>
description: |
Analog Devices AD7904, AD7914, AD7923, AD7924 4 Channel ADCs, and AD7908,
AD7918, AD7928 8 Channels ADCs.
Specifications about the part can be found at:
https://www.analog.com/media/en/technical-documentation/data-sheets/AD7923.pdf
https://www.analog.com/media/en/technical-documentation/data-sheets/AD7904_7914_7924.pdf
https://www.analog.com/media/en/technical-documentation/data-sheets/AD7908_7918_7928.pdf
properties:
compatible:
enum:
- adi,ad7904
- adi,ad7914
- adi,ad7923
- adi,ad7924
- adi,ad7908
- adi,ad7918
- adi,ad7928
reg:
maxItems: 1
refin-supply:
description: |
The regulator supply for ADC reference voltage.
'#address-cells':
const: 1
'#size-cells':
const: 0
required:
- compatible
- reg
examples:
- |
spi {
#address-cells = <1>;
#size-cells = <0>;
ad7928: adc@0 {
compatible = "adi,ad7928";
reg = <0>;
spi-max-frequency = <25000000>;
refin-supply = <&adc_vref>;
#address-cells = <1>;
#size-cells = <0>;
};
};

63
Documentation/devicetree/bindings/iio/adc/max1363.txt
View File

@@ -1,63 +0,0 @@
* Maxim 1x3x/136x/116xx Analog to Digital Converter (ADC)
The node for this driver must be a child node of a I2C controller, hence
all mandatory properties for your controller must be specified. See directory:
Documentation/devicetree/bindings/i2c
for more details.
Required properties:
- compatible: Should be one of
"maxim,max1361"
"maxim,max1362"
"maxim,max1363"
"maxim,max1364"
"maxim,max1036"
"maxim,max1037"
"maxim,max1038"
"maxim,max1039"
"maxim,max1136"
"maxim,max1137"
"maxim,max1138"
"maxim,max1139"
"maxim,max1236"
"maxim,max1237"
"maxim,max1238"
"maxim,max1239"
"maxim,max11600"
"maxim,max11601"
"maxim,max11602"
"maxim,max11603"
"maxim,max11604"
"maxim,max11605"
"maxim,max11606"
"maxim,max11607"
"maxim,max11608"
"maxim,max11609"
"maxim,max11610"
"maxim,max11611"
"maxim,max11612"
"maxim,max11613"
"maxim,max11614"
"maxim,max11615"
"maxim,max11616"
"maxim,max11617"
"maxim,max11644"
"maxim,max11645"
"maxim,max11646"
"maxim,max11647"
- reg: Should contain the ADC I2C address
Optional properties:
- vcc-supply: phandle to the regulator that provides power to the ADC.
- vref-supply: phandle to the regulator for ADC reference voltage.
- interrupts: IRQ line for the ADC. If not used the driver will use
polling.
Example:
adc: max11644@36 {
compatible = "maxim,max11644";
reg = <0x36>;
vref-supply = <&adc_vref>;
};

76
Documentation/devicetree/bindings/iio/adc/maxim,max1238.yaml Normal file
View File

@@ -0,0 +1,76 @@
# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/iio/adc/maxim,max1238.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Maxim MAX1238 and similar ADCs
maintainers:
- Jonathan Cameron <jic23@kernel.org>
description: |
Family of simple ADCs with i2c inteface and internal references.
properties:
compatible:
enum:
- maxim,max1036
- maxim,max1037
- maxim,max1038
- maxim,max1039
- maxim,max1136
- maxim,max1137
- maxim,max1138
- maxim,max1139
- maxim,max1236
- maxim,max1237
- maxim,max1238
- maxim,max1239
- maxim,max11600
- maxim,max11601
- maxim,max11602
- maxim,max11603
- maxim,max11604
- maxim,max11605
- maxim,max11606
- maxim,max11607
- maxim,max11608
- maxim,max11609
- maxim,max11610
- maxim,max11611
- maxim,max11612
- maxim,max11613
- maxim,max11614
- maxim,max11615
- maxim,max11616
- maxim,max11617
- maxim,max11644
- maxim,max11645
- maxim,max11646
- maxim,max11647
reg:
maxItems: 1
vcc-supply: true
vref-supply:
description: Optional external reference. If not supplied, internal
reference will be used.
required:
- compatible
- reg
examples:
- |
i2c {
#address-cells = <1>;
#size-cells = <0>;
adc@36 {
compatible = "maxim,max1238";
reg = <0x36>;
};
};
...

50
Documentation/devicetree/bindings/iio/adc/maxim,max1363.yaml Normal file
View File

@@ -0,0 +1,50 @@
# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/iio/adc/maxim,max1363.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Maxim MAX1363 and similar ADCs
maintainers:
- Jonathan Cameron <jic23@kernel.org>
description: |
Family of ADCs with i2c inteface, internal references and threshold
monitoring.
properties:
compatible:
enum:
- maxim,max1361
- maxim,max1362
- maxim,max1363
- maxim,max1364
reg:
maxItems: 1
vcc-supply: true
vref-supply:
description: Optional external reference. If not supplied, internal
reference will be used.
interrupts:
maxItems: 1
required:
- compatible
- reg
examples:
- |
i2c {
#address-cells = <1>;
#size-cells = <0>;
adc@36 {
compatible = "maxim,max1363";
reg = <0x36>;
};
};
...

2
Documentation/devicetree/bindings/iio/adc/nuvoton,npcm-adc.txt
View File

@@ -6,6 +6,7 @@ Required properties:
- compatible: "nuvoton,npcm750-adc" for the NPCM7XX BMC.
- reg: specifies physical base address and size of the registers.
- interrupts: Contain the ADC interrupt with flags for falling edge.
- resets : phandle to the reset control for this device.
Optional properties:
- clocks: phandle of ADC reference clock, in case the clock is not
@@ -21,4 +22,5 @@ adc: adc@f000c000 {
reg = <0xf000c000 0x8>;
interrupts = <GIC_SPI 0 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&clk NPCM7XX_CLK_ADC>;
resets = <&rstc NPCM7XX_RESET_IPSRST1 NPCM7XX_RESET_ADC>;
};

149
Documentation/devicetree/bindings/iio/adc/st,stm32-adc.txt
View File

@@ -1,149 +0,0 @@
STMicroelectronics STM32 ADC device driver
STM32 ADC is a successive approximation analog-to-digital converter.
It has several multiplexed input channels. Conversions can be performed
in single, continuous, scan or discontinuous mode. Result of the ADC is
stored in a left-aligned or right-aligned 32-bit data register.
Conversions can be launched in software or using hardware triggers.
The analog watchdog feature allows the application to detect if the input
voltage goes beyond the user-defined, higher or lower thresholds.
Each STM32 ADC block can have up to 3 ADC instances.
Each instance supports two contexts to manage conversions, each one has its
own configurable sequence and trigger:
- regular conversion can be done in sequence, running in background
- injected conversions have higher priority, and so have the ability to
interrupt regular conversion sequence (either triggered in SW or HW).
Regular sequence is resumed, in case it has been interrupted.
Contents of a stm32 adc root node:
-----------------------------------
Required properties:
- compatible: Should be one of:
"st,stm32f4-adc-core"
"st,stm32h7-adc-core"
"st,stm32mp1-adc-core"
- reg: Offset and length of the ADC block register set.
- interrupts: One or more interrupts for ADC block. Some parts like stm32f4
and stm32h7 share a common ADC interrupt line. stm32mp1 has two separate
interrupt lines, one for each ADC within ADC block.
- clocks: Core can use up to two clocks, depending on part used:
- "adc" clock: for the analog circuitry, common to all ADCs.
It's required on stm32f4.
It's optional on stm32h7.
- "bus" clock: for registers access, common to all ADCs.
It's not present on stm32f4.
It's required on stm32h7.
- clock-names: Must be "adc" and/or "bus" depending on part used.
- interrupt-controller: Identifies the controller node as interrupt-parent
- vdda-supply: Phandle to the vdda input analog voltage.
- vref-supply: Phandle to the vref input analog reference voltage.
- #interrupt-cells = <1>;
- #address-cells = <1>;
- #size-cells = <0>;
Optional properties:
- A pinctrl state named "default" for each ADC channel may be defined to set
inX ADC pins in mode of operation for analog input on external pin.
- booster-supply: Phandle to the embedded booster regulator that can be used
to supply ADC analog input switches on stm32h7 and stm32mp1.
- vdd-supply: Phandle to the vdd input voltage. It can be used to supply ADC
analog input switches on stm32mp1.
- st,syscfg: Phandle to system configuration controller. It can be used to
control the analog circuitry on stm32mp1.
- st,max-clk-rate-hz: Allow to specify desired max clock rate used by analog
circuitry.
Contents of a stm32 adc child node:
-----------------------------------
An ADC block node should contain at least one subnode, representing an
ADC instance available on the machine.
Required properties:
- compatible: Should be one of:
"st,stm32f4-adc"
"st,stm32h7-adc"
"st,stm32mp1-adc"
- reg: Offset of ADC instance in ADC block (e.g. may be 0x0, 0x100, 0x200).
- clocks: Input clock private to this ADC instance. It's required only on
stm32f4, that has per instance clock input for registers access.
- interrupts: IRQ Line for the ADC (e.g. may be 0 for adc@0, 1 for adc@100 or
2 for adc@200).
- st,adc-channels: List of single-ended channels muxed for this ADC.
It can have up to 16 channels on stm32f4 or 20 channels on stm32h7, numbered
from 0 to 15 or 19 (resp. for in0..in15 or in0..in19).
- st,adc-diff-channels: List of differential channels muxed for this ADC.
Depending on part used, some channels can be configured as differential
instead of single-ended (e.g. stm32h7). List here positive and negative
inputs pairs as <vinp vinn>, <vinp vinn>,... vinp and vinn are numbered
from 0 to 19 on stm32h7)
Note: At least one of "st,adc-channels" or "st,adc-diff-channels" is required.
Both properties can be used together. Some channels can be used as
single-ended and some other ones as differential (mixed). But channels
can't be configured both as single-ended and differential (invalid).
- #io-channel-cells = <1>: See the IIO bindings section "IIO consumers" in
Documentation/devicetree/bindings/iio/iio-bindings.txt
Optional properties:
- dmas: Phandle to dma channel for this ADC instance.
See ../../dma/dma.txt for details.
- dma-names: Must be "rx" when dmas property is being used.
- assigned-resolution-bits: Resolution (bits) to use for conversions. Must
match device available resolutions:
* can be 6, 8, 10 or 12 on stm32f4
* can be 8, 10, 12, 14 or 16 on stm32h7
Default is maximum resolution if unset.
- st,min-sample-time-nsecs: Minimum sampling time in nanoseconds.
Depending on hardware (board) e.g. high/low analog input source impedance,
fine tune of ADC sampling time may be recommended.
This can be either one value or an array that matches 'st,adc-channels' list,
to set sample time resp. for all channels, or independently for each channel.
Example:
adc: adc@40012000 {
compatible = "st,stm32f4-adc-core";
reg = <0x40012000 0x400>;
interrupts = <18>;
clocks = <&rcc 0 168>;
clock-names = "adc";
vref-supply = <&reg_vref>;
interrupt-controller;
pinctrl-names = "default";
pinctrl-0 = <&adc3_in8_pin>;
#interrupt-cells = <1>;
#address-cells = <1>;
#size-cells = <0>;
adc@0 {
compatible = "st,stm32f4-adc";
#io-channel-cells = <1>;
reg = <0x0>;
clocks = <&rcc 0 168>;
interrupt-parent = <&adc>;
interrupts = <0>;
st,adc-channels = <8>;
dmas = <&dma2 0 0 0x400 0x0>;
dma-names = "rx";
assigned-resolution-bits = <8>;
};
...
other adc child nodes follow...
};
Example to setup:
- channel 1 as single-ended
- channels 2 & 3 as differential (with resp. 6 & 7 negative inputs)
adc: adc@40022000 {
compatible = "st,stm32h7-adc-core";
...
adc1: adc@0 {
compatible = "st,stm32h7-adc";
...
st,adc-channels = <1>;
st,adc-diff-channels = <2 6>, <3 7>;
};
};

458
Documentation/devicetree/bindings/iio/adc/st,stm32-adc.yaml Normal file
View File

@@ -0,0 +1,458 @@
# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
%YAML 1.2
---
$id: "http://devicetree.org/schemas/bindings/iio/adc/st,stm32-adc.yaml#"
$schema: "http://devicetree.org/meta-schemas/core.yaml#"
title: STMicroelectronics STM32 ADC bindings
description: |
STM32 ADC is a successive approximation analog-to-digital converter.
It has several multiplexed input channels. Conversions can be performed
in single, continuous, scan or discontinuous mode. Result of the ADC is
stored in a left-aligned or right-aligned 32-bit data register.
Conversions can be launched in software or using hardware triggers.
The analog watchdog feature allows the application to detect if the input
voltage goes beyond the user-defined, higher or lower thresholds.
Each STM32 ADC block can have up to 3 ADC instances.
maintainers:
- Fabrice Gasnier <fabrice.gasnier@st.com>
properties:
compatible:
enum:
- st,stm32f4-adc-core
- st,stm32h7-adc-core
- st,stm32mp1-adc-core
reg:
maxItems: 1
interrupts:
description: |
One or more interrupts for ADC block, depending on part used:
- stm32f4 and stm32h7 share a common ADC interrupt line.
- stm32mp1 has two separate interrupt lines, one for each ADC within
ADC block.
minItems: 1
maxItems: 2
clocks:
description: |
Core can use up to two clocks, depending on part used:
- "adc" clock: for the analog circuitry, common to all ADCs.
It's required on stm32f4.
It's optional on stm32h7 and stm32mp1.
- "bus" clock: for registers access, common to all ADCs.
It's not present on stm32f4.
It's required on stm32h7 and stm32mp1.
clock-names: true
st,max-clk-rate-hz:
description:
Allow to specify desired max clock rate used by analog circuitry.
vdda-supply:
description: Phandle to the vdda input analog voltage.
vref-supply:
description: Phandle to the vref input analog reference voltage.
booster-supply:
description:
Phandle to the embedded booster regulator that can be used to supply ADC
analog input switches on stm32h7 and stm32mp1.
vdd-supply:
description:
Phandle to the vdd input voltage. It can be used to supply ADC analog
input switches on stm32mp1.
st,syscfg:
description:
Phandle to system configuration controller. It can be used to control the
analog circuitry on stm32mp1.
allOf:
- $ref: "/schemas/types.yaml#/definitions/phandle-array"
interrupt-controller: true
'#interrupt-cells':
const: 1
'#address-cells':
const: 1
'#size-cells':
const: 0
allOf:
- if:
properties:
compatible:
contains:
const: st,stm32f4-adc-core
then:
properties:
clocks:
maxItems: 1
clock-names:
const: adc
interrupts:
items:
- description: interrupt line common for all ADCs
st,max-clk-rate-hz:
minimum: 600000
maximum: 36000000
default: 36000000
booster-supply: false
vdd-supply: false
st,syscfg: false
- if:
properties:
compatible:
contains:
const: st,stm32h7-adc-core
then:
properties:
clocks:
minItems: 1
maxItems: 2
clock-names:
items:
- const: bus
- const: adc
minItems: 1
maxItems: 2
interrupts:
items:
- description: interrupt line common for all ADCs
st,max-clk-rate-hz:
minimum: 120000
maximum: 36000000
default: 36000000
vdd-supply: false
st,syscfg: false
- if:
properties:
compatible:
contains:
const: st,stm32mp1-adc-core
then:
properties:
clocks:
minItems: 1
maxItems: 2
clock-names:
items:
- const: bus
- const: adc
minItems: 1
maxItems: 2
interrupts:
items:
- description: interrupt line for ADC1
- description: interrupt line for ADC2
st,max-clk-rate-hz:
minimum: 120000
maximum: 36000000
default: 36000000
additionalProperties: false
required:
- compatible
- reg
- interrupts
- clocks
- clock-names
- vdda-supply
- vref-supply
- interrupt-controller
- '#interrupt-cells'
- '#address-cells'
- '#size-cells'
patternProperties:
"^adc@[0-9]+$":
type: object
description:
An ADC block node should contain at least one subnode, representing an
ADC instance available on the machine.
properties:
compatible:
enum:
- st,stm32f4-adc
- st,stm32h7-adc
- st,stm32mp1-adc
reg:
description: |
Offset of ADC instance in ADC block. Valid values are:
- 0x0: ADC1
- 0x100: ADC2
- 0x200: ADC3 (stm32f4 only)
maxItems: 1
'#io-channel-cells':
const: 1
interrupts:
description: |
IRQ Line for the ADC instance. Valid values are:
- 0 for adc@0
- 1 for adc@100
- 2 for adc@200 (stm32f4 only)
maxItems: 1
clocks:
description:
Input clock private to this ADC instance. It's required only on
stm32f4, that has per instance clock input for registers access.
maxItems: 1
dmas:
description: RX DMA Channel
maxItems: 1
dma-names:
const: rx
assigned-resolution-bits:
description: |
Resolution (bits) to use for conversions:
- can be 6, 8, 10 or 12 on stm32f4
- can be 8, 10, 12, 14 or 16 on stm32h7 and stm32mp1
allOf:
- $ref: /schemas/types.yaml#/definitions/uint32
st,adc-channels:
description: |
List of single-ended channels muxed for this ADC. It can have up to:
- 16 channels, numbered from 0 to 15 (for in0..in15) on stm32f4
- 20 channels, numbered from 0 to 19 (for in0..in19) on stm32h7 and
stm32mp1.
allOf:
- $ref: /schemas/types.yaml#/definitions/uint32-array
st,adc-diff-channels:
description: |
List of differential channels muxed for this ADC. Some channels can
be configured as differential instead of single-ended on stm32h7 and
on stm32mp1. Positive and negative inputs pairs are listed:
<vinp vinn>, <vinp vinn>,... vinp and vinn are numbered from 0 to 19.
Note: At least one of "st,adc-channels" or "st,adc-diff-channels" is
required. Both properties can be used together. Some channels can be
used as single-ended and some other ones as differential (mixed). But
channels can't be configured both as single-ended and differential.
allOf:
- $ref: /schemas/types.yaml#/definitions/uint32-matrix
- items:
items:
- description: |
"vinp" indicates positive input number
minimum: 0
maximum: 19
- description: |
"vinn" indicates negative input number
minimum: 0
maximum: 19
st,min-sample-time-nsecs:
description:
Minimum sampling time in nanoseconds. Depending on hardware (board)
e.g. high/low analog input source impedance, fine tune of ADC
sampling time may be recommended. This can be either one value or an
array that matches "st,adc-channels" and/or "st,adc-diff-channels"
list, to set sample time resp. for all channels, or independently for
each channel.
allOf:
- $ref: /schemas/types.yaml#/definitions/uint32-array
allOf:
- if:
properties:
compatible:
contains:
const: st,stm32f4-adc
then:
properties:
reg:
enum:
- 0x0
- 0x100
- 0x200
interrupts:
minimum: 0
maximum: 2
assigned-resolution-bits:
enum: [6, 8, 10, 12]
default: 12
st,adc-channels:
minItems: 1
maxItems: 16
items:
minimum: 0
maximum: 15
st,adc-diff-channels: false
st,min-sample-time-nsecs:
minItems: 1
maxItems: 16
items:
minimum: 80
required:
- clocks
- if:
properties:
compatible:
contains:
enum:
- st,stm32h7-adc
- st,stm32mp1-adc
then:
properties:
reg:
enum:
- 0x0
- 0x100
interrupts:
minimum: 0
maximum: 1
assigned-resolution-bits:
enum: [8, 10, 12, 14, 16]
default: 16
st,adc-channels:
minItems: 1
maxItems: 20
items:
minimum: 0
maximum: 19
st,min-sample-time-nsecs:
minItems: 1
maxItems: 20
items:
minimum: 40
additionalProperties: false
anyOf:
- required:
- st,adc-channels
- required:
- st,adc-diff-channels
required:
- compatible
- reg
- interrupts
- '#io-channel-cells'
examples:
- |
// Example 1: with stm32f429, ADC1, single-ended channel 8
adc123: adc@40012000 {
compatible = "st,stm32f4-adc-core";
reg = <0x40012000 0x400>;
interrupts = <18>;
clocks = <&rcc 0 168>;
clock-names = "adc";
st,max-clk-rate-hz = <36000000>;
vdda-supply = <&vdda>;
vref-supply = <&vref>;
interrupt-controller;
#interrupt-cells = <1>;
#address-cells = <1>;
#size-cells = <0>;
adc@0 {
compatible = "st,stm32f4-adc";
#io-channel-cells = <1>;
reg = <0x0>;
clocks = <&rcc 0 168>;
interrupt-parent = <&adc123>;
interrupts = <0>;
st,adc-channels = <8>;
dmas = <&dma2 0 0 0x400 0x0>;
dma-names = "rx";
assigned-resolution-bits = <8>;
};
// ...
// other adc child nodes follow...
};
- |
// Example 2: with stm32mp157c to setup ADC1 with:
// - channels 0 & 1 as single-ended
// - channels 2 & 3 as differential (with resp. 6 & 7 negative inputs)
#include <dt-bindings/interrupt-controller/arm-gic.h>
#include <dt-bindings/clock/stm32mp1-clks.h>
adc12: adc@48003000 {
compatible = "st,stm32mp1-adc-core";
reg = <0x48003000 0x400>;
interrupts = <GIC_SPI 18 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 90 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&rcc ADC12>, <&rcc ADC12_K>;
clock-names = "bus", "adc";
booster-supply = <&booster>;
vdd-supply = <&vdd>;
vdda-supply = <&vdda>;
vref-supply = <&vref>;
st,syscfg = <&syscfg>;
interrupt-controller;
#interrupt-cells = <1>;
#address-cells = <1>;
#size-cells = <0>;
adc@0 {
compatible = "st,stm32mp1-adc";
#io-channel-cells = <1>;
reg = <0x0>;
interrupt-parent = <&adc12>;
interrupts = <0>;
st,adc-channels = <0 1>;
st,adc-diff-channels = <2 6>, <3 7>;
st,min-sample-time-nsecs = <5000>;
dmas = <&dmamux1 9 0x400 0x05>;
dma-names = "rx";
};
// ...
// other adc child node follow...
};
...

49
Documentation/devicetree/bindings/iio/amplifiers/adi,hmc425a.yaml Normal file
View File

@@ -0,0 +1,49 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/iio/amplifiers/adi,hmc425a.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: HMC425A 6-bit Digital Step Attenuator
maintainers:
- Michael Hennerich <michael.hennerich@analog.com>
- Beniamin Bia <beniamin.bia@analog.com>
description: |
Digital Step Attenuator IIO device with gpio interface.
HMC425A 0.5 dB LSB GaAs MMIC 6-BIT DIGITAL POSITIVE CONTROL ATTENUATOR, 2.2 - 8.0 GHz
https://www.analog.com/media/en/technical-documentation/data-sheets/hmc425A.pdf
properties:
compatible:
enum:
- adi,hmc425a
vcc-supply: true
ctrl-gpios:
description:
Must contain an array of 6 GPIO specifiers, referring to the GPIO pins
connected to the control pins V1-V6.
minItems: 6
maxItems: 6
required:
- compatible
- ctrl-gpios
examples:
- |
#include <dt-bindings/gpio/gpio.h>
gpio_hmc425a: hmc425a {
compatible = "adi,hmc425a";
ctrl-gpios = <&gpio 40 GPIO_ACTIVE_HIGH>,
<&gpio 39 GPIO_ACTIVE_HIGH>,
<&gpio 38 GPIO_ACTIVE_HIGH>,
<&gpio 37 GPIO_ACTIVE_HIGH>,
<&gpio 36 GPIO_ACTIVE_HIGH>,
<&gpio 35 GPIO_ACTIVE_HIGH>;
vcc-supply = <&foo>;
};
...

21
Documentation/devicetree/bindings/iio/chemical/atlas,ec-sm.txt
View File

@@ -1,21 +0,0 @@
* Atlas Scientific EC-SM OEM sensor
http://www.atlas-scientific.com/_files/_datasheets/_oem/EC_oem_datasheet.pdf
Required properties:
- compatible: must be "atlas,ec-sm"
- reg: the I2C address of the sensor
- interrupts: the sole interrupt generated by the device
Refer to interrupt-controller/interrupts.txt for generic interrupt client
node bindings.
Example:
atlas@64 {
compatible = "atlas,ec-sm";
reg = <0x64>;
interrupt-parent = <&gpio1>;
interrupts = <16 2>;
};

21
Documentation/devicetree/bindings/iio/chemical/atlas,orp-sm.txt
View File

@@ -1,21 +0,0 @@
* Atlas Scientific ORP-SM OEM sensor
https://www.atlas-scientific.com/_files/_datasheets/_oem/ORP_oem_datasheet.pdf
Required properties:
- compatible: must be "atlas,orp-sm"
- reg: the I2C address of the sensor
- interrupts: the sole interrupt generated by the device
Refer to interrupt-controller/interrupts.txt for generic interrupt client
node bindings.
Example:
atlas@66 {
compatible = "atlas,orp-sm";
reg = <0x66>;
interrupt-parent = <&gpio1>;
interrupts = <16 2>;
};

21
Documentation/devicetree/bindings/iio/chemical/atlas,ph-sm.txt
View File

@@ -1,21 +0,0 @@
* Atlas Scientific pH-SM OEM sensor
http://www.atlas-scientific.com/_files/_datasheets/_oem/pH_oem_datasheet.pdf
Required properties:
- compatible: must be "atlas,ph-sm"
- reg: the I2C address of the sensor
- interrupts: the sole interrupt generated by the device
Refer to interrupt-controller/interrupts.txt for generic interrupt client
node bindings.
Example:
atlas@65 {
compatible = "atlas,ph-sm";
reg = <0x65>;
interrupt-parent = <&gpio1>;
interrupts = <16 2>;
};

53
Documentation/devicetree/bindings/iio/chemical/atlas,sensor.yaml Normal file
View File

@@ -0,0 +1,53 @@
# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/iio/chemical/atlas,sensor.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Atlas Scientific OEM sensors
maintainers:
- Matt Ranostay <matt.ranostay@konsulko.com>
description: |
Atlas Scientific OEM sensors connected via I2C
Datasheets:
http://www.atlas-scientific.com/_files/_datasheets/_oem/DO_oem_datasheet.pdf
http://www.atlas-scientific.com/_files/_datasheets/_oem/EC_oem_datasheet.pdf
http://www.atlas-scientific.com/_files/_datasheets/_oem/ORP_oem_datasheet.pdf
http://www.atlas-scientific.com/_files/_datasheets/_oem/pH_oem_datasheet.pdf
properties:
compatible:
enum:
- atlas,do-sm
- atlas,ec-sm
- atlas,orp-sm
- atlas,ph-sm
reg:
maxItems: 1
interrupts:
maxItems: 1
required:
- compatible
- reg
additionalProperties: false
examples:
- |
i2c {
#address-cells = <1>;
#size-cells = <0>;
atlas@66 {
compatible = "atlas,orp-sm";
reg = <0x66>;
interrupt-parent = <&gpio1>;
interrupts = <16 2>;
};
};

185
Documentation/devicetree/bindings/iio/dac/adi,ad5770r.yaml Normal file
View File

@@ -0,0 +1,185 @@
# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
# Copyright 2020 Analog Devices Inc.
%YAML 1.2
---
$id: http://devicetree.org/schemas/bindings/iio/dac/adi,ad5770r.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Analog Devices AD5770R DAC device driver
maintainers:
- Mircea Caprioru <mircea.caprioru@analog.com>
description: |
Bindings for the Analog Devices AD5770R current DAC device. Datasheet can be
found here:
https://www.analog.com/media/en/technical-documentation/data-sheets/AD5770R.pdf
properties:
compatible:
enum:
- adi,ad5770r
reg:
maxItems: 1
avdd-supply:
description:
AVdd voltage supply. Represents two different supplies in the datasheet
that are in fact the same.
iovdd-supply:
description:
Voltage supply for the chip interface.
vref-supply:
description: Specify the voltage of the external reference used.
Available reference options are 1.25 V or 2.5 V. If no
external reference declared then the device will use the
internal reference of 1.25 V.
adi,external-resistor:
description: Specify if an external 2.5k ohm resistor is used. If not
specified the device will use an internal 2.5k ohm resistor.
The precision resistor is used for reference current generation.
type: boolean
reset-gpios:
description: GPIO spec for the RESET pin. If specified, it will be
asserted during driver probe.
maxItems: 1
channel0:
description: Represents an external channel which are
connected to the DAC. Channel 0 can act both as a current
source and sink.
type: object
properties:
num:
description: This represents the channel number.
items:
const: 0
adi,range-microamp:
description: Output range of the channel.
oneOf:
- $ref: /schemas/types.yaml#/definitions/int32-array
- items:
- enum: [0 300000]
- enum: [-60000 0]
- enum: [-60000 300000]
channel1:
description: Represents an external channel which are
connected to the DAC.
type: object
properties:
num:
description: This represents the channel number.
items:
const: 1
adi,range-microamp:
description: Output range of the channel.
oneOf:
- $ref: /schemas/types.yaml#/definitions/uint32-array
- items:
- enum: [0 140000]
- enum: [0 250000]
channel2:
description: Represents an external channel which are
connected to the DAC.
type: object
properties:
num:
description: This represents the channel number.
items:
const: 2
adi,range-microamp:
description: Output range of the channel.
oneOf:
- $ref: /schemas/types.yaml#/definitions/uint32-array
- items:
- enum: [0 140000]
- enum: [0 250000]
patternProperties:
"^channel@([3-5])$":
type: object
description: Represents the external channels which are connected to the DAC.
properties:
num:
description: This represents the channel number.
items:
minimum: 3
maximum: 5
adi,range-microamp:
description: Output range of the channel.
oneOf:
- $ref: /schemas/types.yaml#/definitions/uint32-array
- items:
- enum: [0 45000]
- enum: [0 100000]
required:
- reg
- diff-channels
- channel0
- channel1
- channel2
- channel3
- channel4
- channel5
examples:
- |
spi {
#address-cells = <1>;
#size-cells = <0>;
ad5770r@0 {
compatible = "ad5770r";
reg = <0>;
spi-max-frequency = <1000000>;
vref-supply = <&vref>;
adi,external-resistor;
reset-gpios = <&gpio 22 0>;
channel@0 {
num = <0>;
adi,range-microamp = <(-60000) 300000>;
};
channel@1 {
num = <1>;
adi,range-microamp = <0 140000>;
};
channel@2 {
num = <2>;
adi,range-microamp = <0 55000>;
};
channel@3 {
num = <3>;
adi,range-microamp = <0 45000>;
};
channel@4 {
num = <4>;
adi,range-microamp = <0 45000>;
};
channel@5 {
num = <5>;
adi,range-microamp = <0 45000>;
};
};
};
...

8
Documentation/devicetree/bindings/iio/dac/ltc2632.txt
View File

@@ -1,4 +1,4 @@
Linear Technology LTC2632 DAC device driver
Linear Technology LTC2632/2636 DAC
Required properties:
- compatible: Has to contain one of the following:
@@ -8,6 +8,12 @@ Required properties:
lltc,ltc2632-h12
lltc,ltc2632-h10
lltc,ltc2632-h8
lltc,ltc2636-l12
lltc,ltc2636-l10
lltc,ltc2636-l8
lltc,ltc2636-h12
lltc,ltc2636-h10
lltc,ltc2636-h8
Property rules described in Documentation/devicetree/bindings/spi/spi-bus.txt
apply. In particular, "reg" and "spi-max-frequency" properties must be given.

5
Documentation/devicetree/bindings/iio/imu/inv_mpu6050.txt
View File

@@ -4,6 +4,7 @@ http://www.invensense.com/mems/gyro/mpu6050.html
Required properties:
- compatible : should be one of
"invensense,mpu6000"
"invensense,mpu6050"
"invensense,mpu6500"
"invensense,mpu6515"
@@ -11,7 +12,11 @@ Required properties:
"invensense,mpu9250"
"invensense,mpu9255"
"invensense,icm20608"
"invensense,icm20609"
"invensense,icm20689"
"invensense,icm20602"
"invensense,icm20690"
"invensense,iam20680"
- reg : the I2C address of the sensor
- interrupts: interrupt mapping for IRQ. It should be configured with flags
IRQ_TYPE_LEVEL_HIGH, IRQ_TYPE_EDGE_RISING, IRQ_TYPE_LEVEL_LOW or

43
Documentation/devicetree/bindings/iio/light/dynaimage,al3010.yaml Normal file
View File

@@ -0,0 +1,43 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/iio/light/dynaimage,al3010.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Dyna-Image AL3010 sensor
maintainers:
- David Heidelberg <david@ixit.cz>
properties:
compatible:
const: dynaimage,al3010
reg:
maxItems: 1
interrupts:
maxItems: 1
vdd-supply:
description: Regulator that provides power to the sensor
required:
- compatible
- reg
examples:
- |
#include <dt-bindings/interrupt-controller/irq.h>
i2c {
#address-cells = <1>;
#size-cells = <0>;
light-sensor@1c {
compatible = "dynaimage,al3010";
reg = <0x1c>;
vdd-supply = <&vdd_reg>;
interrupts = <0 99 4>;
};
};

43
Documentation/devicetree/bindings/iio/light/dynaimage,al3320a.yaml Normal file
View File

@@ -0,0 +1,43 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/iio/light/dynaimage,al3320a.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Dyna-Image AL3320A sensor
maintainers:
- David Heidelberg <david@ixit.cz>
properties:
compatible:
const: dynaimage,al3320a
reg:
maxItems: 1
interrupts:
maxItems: 1
vdd-supply:
description: Regulator that provides power to the sensor
required:
- compatible
- reg
examples:
- |
#include <dt-bindings/interrupt-controller/irq.h>
i2c {
#address-cells = <1>;
#size-cells = <0>;
light-sensor@1c {
compatible = "dynaimage,al3320a";
reg = <0x1c>;
vdd-supply = <&vdd_reg>;
interrupts = <0 99 4>;
};
};

85
Documentation/devicetree/bindings/iio/light/sharp,gp2ap002.yaml Normal file
View File

@@ -0,0 +1,85 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/iio/light/sharp,gp2ap002.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Sharp GP2AP002A00F and GP2AP002S00F proximity and ambient light sensors
maintainers:
- Linus Walleij <linus.walleij@linaro.org>
description: |
Proximity and ambient light sensor with IR LED for the proximity
sensing and an analog output for light intensity. The ambient light
sensor output is not available on the GP2AP002S00F variant.
properties:
compatible:
enum:
- sharp,gp2ap002a00f
- sharp,gp2ap002s00f
reg:
maxItems: 1
interrupts:
maxItems: 1
description: an interrupt for proximity, usually a GPIO line
vdd-supply:
description: VDD power supply a phandle to a regulator
vio-supply:
description: VIO power supply a phandle to a regulator
io-channels:
maxItems: 1
description: ALSOUT ADC channel to read the ambient light
io-channel-names:
const: alsout
sharp,proximity-far-hysteresis:
$ref: /schemas/types.yaml#/definitions/uint8
description: |
Hysteresis setting for "far" object detection, this setting is
device-unique and adjust the optical setting for proximity detection
of a "far away" object in front of the sensor.
sharp,proximity-close-hysteresis:
$ref: /schemas/types.yaml#/definitions/uint8
description: |
Hysteresis setting for "close" object detection, this setting is
device-unique and adjust the optical setting for proximity detection
of a "close" object in front of the sensor.
required:
- compatible
- reg
- interrupts
- sharp,proximity-far-hysteresis
- sharp,proximity-close-hysteresis
examples:
- |
#include <dt-bindings/interrupt-controller/irq.h>
i2c {
#address-cells = <1>;
#size-cells = <0>;
light-sensor@44 {
compatible = "sharp,gp2ap002a00f";
reg = <0x44>;
interrupts = <18 IRQ_TYPE_EDGE_FALLING>;
vdd-supply = <&vdd_regulator>;
vio-supply = <&vio_regulator>;
io-channels = <&adc_channel>;
io-channel-names = "alsout";
sharp,proximity-far-hysteresis = /bits/ 8 <0x2f>;
sharp,proximity-close-hysteresis = /bits/ 8 <0x0f>;
};
};
...

18
Documentation/devicetree/bindings/iio/proximity/devantech-srf04.yaml
View File

@@ -51,6 +51,24 @@ properties:
the time between two interrupts is measured in the driver.
maxItems: 1
power-gpios:
description:
Definition of the GPIO for power management of connected peripheral
(output).
This GPIO can be used by the external hardware for power management.
When the device gets suspended it's switched off and when it resumes
it's switched on again. After some period of inactivity the driver
get suspended automatically (autosuspend feature).
maxItems: 1
startup-time-ms:
description:
This is the startup time the device needs after a resume to be up and
running.
minimum: 0
maximum: 1000
default: 100
required:
- compatible
- trig-gpios

70
Documentation/devicetree/bindings/media/allwinner,sun8i-a83t-de2-rotate.yaml Normal file
View File

@@ -0,0 +1,70 @@
# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/media/allwinner,sun8i-a83t-de2-rotate.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Allwinner A83T DE2 Rotate Device Tree Bindings
maintainers:
- Jernej Skrabec <jernej.skrabec@siol.net>
- Chen-Yu Tsai <wens@csie.org>
- Maxime Ripard <mripard@kernel.org>
description: |-
The Allwinner A83T and A64 have a rotation core used for
rotating and flipping images.
properties:
compatible:
oneOf:
- const: allwinner,sun8i-a83t-de2-rotate
- items:
- const: allwinner,sun50i-a64-de2-rotate
- const: allwinner,sun8i-a83t-de2-rotate
reg:
maxItems: 1
interrupts:
maxItems: 1
clocks:
items:
- description: Rotate interface clock
- description: Rotate module clock
clock-names:
items:
- const: bus
- const: mod
resets:
maxItems: 1
required:
- compatible
- reg
- interrupts
- clocks
additionalProperties: false
examples:
- |
#include <dt-bindings/interrupt-controller/arm-gic.h>
#include <dt-bindings/clock/sun8i-de2.h>
#include <dt-bindings/reset/sun8i-de2.h>
rotate: rotate@1020000 {
compatible = "allwinner,sun8i-a83t-de2-rotate";
reg = <0x1020000 0x10000>;
interrupts = <GIC_SPI 92 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&display_clocks CLK_BUS_ROT>,
<&display_clocks CLK_ROT>;
clock-names = "bus",
"mod";
resets = <&display_clocks RST_ROT>;
};
...

6
Documentation/devicetree/bindings/media/allwinner,sun8i-h3-deinterlace.yaml
View File

@@ -17,7 +17,11 @@ description: |-
properties:
compatible:
const: allwinner,sun8i-h3-deinterlace
oneOf:
- const: allwinner,sun8i-h3-deinterlace
- items:
- const: allwinner,sun50i-a64-deinterlace
- const: allwinner,sun8i-h3-deinterlace
reg:
maxItems: 1

5
Documentation/devicetree/bindings/media/aspeed-video.txt
View File

@@ -1,11 +1,12 @@
* Device tree bindings for Aspeed Video Engine
The Video Engine (VE) embedded in the Aspeed AST2400 and AST2500 SOCs can
The Video Engine (VE) embedded in the Aspeed AST2400/2500/2600 SOCs can
capture and compress video data from digital or analog sources.
Required properties:
- compatible: "aspeed,ast2400-video-engine" or
"aspeed,ast2500-video-engine"
"aspeed,ast2500-video-engine" or
"aspeed,ast2600-video-engine"
- reg: contains the offset and length of the VE memory region
- clocks: clock specifiers for the syscon clocks associated with
the VE (ordering must match the clock-names property)

114
Documentation/devicetree/bindings/media/i2c/imx219.yaml Normal file
View File

@@ -0,0 +1,114 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/media/i2c/imx219.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Sony 1/4.0-Inch 8Mpixel CMOS Digital Image Sensor
maintainers:
- Dave Stevenson <dave.stevenson@raspberrypi.com>
description: |-
The Sony imx219 is a 1/4.0-inch CMOS active pixel digital image sensor
with an active array size of 3280H x 2464V. It is programmable through
I2C interface. The I2C address is fixed to 0x10 as per sensor data sheet.
Image data is sent through MIPI CSI-2, which is configured as either 2 or
4 data lanes.
properties:
compatible:
const: sony,imx219
reg:
description: I2C device address
maxItems: 1
clocks:
maxItems: 1
VDIG-supply:
description:
Digital I/O voltage supply, 1.8 volts
VANA-supply:
description:
Analog voltage supply, 2.8 volts
VDDL-supply:
description:
Digital core voltage supply, 1.2 volts
reset-gpios:
description: |-
Reference to the GPIO connected to the xclr pin, if any.
Must be released (set high) after all supplies are applied.
# See ../video-interfaces.txt for more details
port:
type: object
properties:
endpoint:
type: object
properties:
data-lanes:
description: |-
The sensor supports either two-lane, or four-lane operation.
If this property is omitted four-lane operation is assumed.
For two-lane operation the property must be set to <1 2>.
items:
- const: 1
- const: 2
clock-noncontinuous:
type: boolean
description: |-
MIPI CSI-2 clock is non-continuous if this property is present,
otherwise it's continuous.
link-frequencies:
allOf:
- $ref: /schemas/types.yaml#/definitions/uint64-array
description:
Allowed data bus frequencies.
required:
- link-frequencies
required:
- compatible
- reg
- clocks
- VANA-supply
- VDIG-supply
- VDDL-supply
- port
additionalProperties: false
examples:
- |
i2c0 {
#address-cells = <1>;
#size-cells = <0>;
imx219: sensor@10 {
compatible = "sony,imx219";
reg = <0x10>;
clocks = <&imx219_clk>;
VANA-supply = <&imx219_vana>; /* 2.8v */
VDIG-supply = <&imx219_vdig>; /* 1.8v */
VDDL-supply = <&imx219_vddl>; /* 1.2v */
port {
imx219_0: endpoint {
remote-endpoint = <&csi1_ep>;
data-lanes = <1 2>;
clock-noncontinuous;
link-frequencies = /bits/ 64 <456000000>;
};
};
};
};
...

146
Documentation/devicetree/bindings/media/i2c/tvp5150.txt
View File

@@ -5,38 +5,150 @@ The TVP5150 and TVP5151 are video decoders that convert baseband NTSC and PAL
with discrete syncs or 8-bit ITU-R BT.656 with embedded syncs output formats.
Required Properties:
- compatible: value must be "ti,tvp5150"
- reg: I2C slave address
====================
- compatible: Value must be "ti,tvp5150".
- reg: I2C slave address.
Optional Properties:
- pdn-gpios: phandle for the GPIO connected to the PDN pin, if any.
- reset-gpios: phandle for the GPIO connected to the RESETB pin, if any.
====================
- pdn-gpios: Phandle for the GPIO connected to the PDN pin, if any.
- reset-gpios: Phandle for the GPIO connected to the RESETB pin, if any.
The device node must contain one 'port' child node for its digital output
video port, in accordance with the video interface bindings defined in
Documentation/devicetree/bindings/media/video-interfaces.txt.
The device node must contain one 'port' child node per device physical input
and output port, in accordance with the video interface bindings defined in
Documentation/devicetree/bindings/media/video-interfaces.txt. The port nodes
are numbered as follows
Required Endpoint Properties for parallel synchronization:
Name Type Port
--------------------------------------
AIP1A sink 0
AIP1B sink 1
Y-OUT src 2
- hsync-active: active state of the HSYNC signal. Must be <1> (HIGH).
- vsync-active: active state of the VSYNC signal. Must be <1> (HIGH).
- field-even-active: field signal level during the even field data
transmission. Must be <0>.
The device node must contain at least one sink port and the src port. Each input
port must be linked to an endpoint defined in [1]. The port/connector layout is
as follows
If none of hsync-active, vsync-active and field-even-active is specified,
the endpoint is assumed to use embedded BT.656 synchronization.
tvp-5150 port@0 (AIP1A)
endpoint@0 -----------> Comp0-Con port
endpoint@1 ------+----> Svideo-Con port
tvp-5150 port@1 (AIP1B) |
endpoint@1 ------+
endpoint@0 -----------> Comp1-Con port
tvp-5150 port@2
endpoint (video bitstream output at YOUT[0-7] parallel bus)
Example:
Required Endpoint Properties for parallel synchronization on output port:
=========================================================================
- hsync-active: Active state of the HSYNC signal. Must be <1> (HIGH).
- vsync-active: Active state of the VSYNC signal. Must be <1> (HIGH).
- field-even-active: Field signal level during the even field data
transmission. Must be <0>.
Note: Do not specify any of these properties if you want to use the embedded
BT.656 synchronization.
Optional Connector Properties:
==============================
- sdtv-standards: Set the possible signals to which the hardware tries to lock
instead of using the autodetection mechnism. Please look at
[1] for more information.
[1] Documentation/devicetree/bindings/display/connector/analog-tv-connector.txt.
Example - three input sources:
#include <dt-bindings/display/sdtv-standards.h>
comp_connector_0 {
compatible = "composite-video-connector";
label = "Composite0";
sdtv-standards = <SDTV_STD_PAL_M>; /* limit to pal-m signals */
port {
composite0_to_tvp5150: endpoint {
remote-endpoint = <&tvp5150_to_composite0>;
};
};
};
comp_connector_1 {
compatible = "composite-video-connector";
label = "Composite1";
sdtv-standards = <SDTV_STD_NTSC_M>; /* limit to ntsc-m signals */
port {
composite1_to_tvp5150: endpoint {
remote-endpoint = <&tvp5150_to_composite1>;
};
};
};
svideo_connector {
compatible = "svideo-connector";
label = "S-Video";
port {
#address-cells = <1>;
#size-cells = <0>;
svideo_luma_to_tvp5150: endpoint@0 {
reg = <0>;
remote-endpoint = <&tvp5150_to_svideo_luma>;
};
svideo_chroma_to_tvp5150: endpoint@1 {
reg = <1>;
remote-endpoint = <&tvp5150_to_svideo_chroma>;
};
};
};
&i2c2 {
...
tvp5150@5c {
compatible = "ti,tvp5150";
reg = <0x5c>;
pdn-gpios = <&gpio4 30 GPIO_ACTIVE_LOW>;
reset-gpios = <&gpio6 7 GPIO_ACTIVE_LOW>;
#address-cells = <1>;
#size-cells = <0>;
port@0 {
#address-cells = <1>;
#size-cells = <0>;
reg = <0>;
tvp5150_to_composite0: endpoint@0 {
reg = <0>;
remote-endpoint = <&composite0_to_tvp5150>;
};
tvp5150_to_svideo_luma: endpoint@1 {
reg = <1>;
remote-endpoint = <&svideo_luma_to_tvp5150>;
};
};
port@1 {
#address-cells = <1>;
#size-cells = <0>;
reg = <1>;
tvp5150_to_composite1: endpoint@0 {
reg = <0>;
remote-endpoint = <&composite1_to_tvp5150>;
};
tvp5150_to_svideo_chroma: endpoint@1 {
reg = <1>;
remote-endpoint = <&svideo_chroma_to_tvp5150>;
};
};
port@2 {
reg = <2>;
port {
tvp5150_1: endpoint {
remote-endpoint = <&ccdc_ep>;
};

77
Documentation/devicetree/bindings/media/nxp,imx8mq-vpu.yaml Normal file
View File

@@ -0,0 +1,77 @@
# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
%YAML 1.2
---
$id: "http://devicetree.org/schemas/media/nxp,imx8mq-vpu.yaml#"
$schema: "http://devicetree.org/meta-schemas/core.yaml#"
title: Hantro G1/G2 VPU codecs implemented on i.MX8MQ SoCs
maintainers:
- Philipp Zabel <p.zabel@pengutronix.de>
description:
Hantro G1/G2 video decode accelerators present on i.MX8MQ SoCs.
properties:
compatible:
const: nxp,imx8mq-vpu
reg:
maxItems: 3
reg-names:
items:
- const: g1
- const: g2
- const: ctrl
interrupts:
maxItems: 2
interrupt-names:
items:
- const: g1
- const: g2
clocks:
maxItems: 3
clock-names:
items:
- const: g1
- const: g2
- const: bus
power-domains:
maxItems: 1
required:
- compatible
- reg
- reg-names
- interrupts
- interrupt-names
- clocks
- clock-names
examples:
- |
#include <dt-bindings/clock/imx8mq-clock.h>
#include <dt-bindings/interrupt-controller/arm-gic.h>
vpu: video-codec@38300000 {
compatible = "nxp,imx8mq-vpu";
reg = <0x38300000 0x10000>,
<0x38310000 0x10000>,
<0x38320000 0x10000>;
reg-names = "g1", "g2", "ctrl";
interrupts = <GIC_SPI 7 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 8 IRQ_TYPE_LEVEL_HIGH>;
interrupt-names = "g1", "g2";
clocks = <&clk IMX8MQ_CLK_VPU_G1_ROOT>,
<&clk IMX8MQ_CLK_VPU_G2_ROOT>,
<&clk IMX8MQ_CLK_VPU_DEC_ROOT>;
clock-names = "g1", "g2", "bus";
power-domains = <&pgc_vpu>;
};

119
Documentation/devicetree/bindings/media/qcom,msm8916-venus.yaml Normal file
View File

@@ -0,0 +1,119 @@
# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
%YAML 1.2
---
$id: "http://devicetree.org/schemas/media/qcom,msm8916-venus.yaml#"
$schema: "http://devicetree.org/meta-schemas/core.yaml#"
title: Qualcomm Venus video encode and decode accelerators
maintainers:
- Stanimir Varbanov <stanimir.varbanov@linaro.org>
description: |
The Venus IP is a video encode and decode accelerator present
on Qualcomm platforms
properties:
compatible:
const: qcom,msm8916-venus
reg:
maxItems: 1
interrupts:
maxItems: 1
power-domains:
maxItems: 1
clocks:
maxItems: 3
clock-names:
items:
- const: core
- const: iface
- const: bus
iommus:
maxItems: 1
memory-region:
maxItems: 1
video-decoder:
type: object
properties:
compatible:
const: "venus-decoder"
required:
- compatible
additionalProperties: false
video-encoder:
type: object
properties:
compatible:
const: "venus-encoder"
required:
- compatible
additionalProperties: false
video-firmware:
type: object
description: |
Firmware subnode is needed when the platform does not
have TrustZone.
properties:
iommus:
maxItems: 1
required:
- iommus
required:
- compatible
- reg
- interrupts
- power-domains
- clocks
- clock-names
- iommus
- memory-region
- video-decoder
- video-encoder
examples:
- |
#include <dt-bindings/interrupt-controller/arm-gic.h>
#include <dt-bindings/clock/qcom,gcc-msm8916.h>
video-codec@1d00000 {
compatible = "qcom,msm8916-venus";
reg = <0x01d00000 0xff000>;
interrupts = <GIC_SPI 44 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&gcc GCC_VENUS0_VCODEC0_CLK>,
<&gcc GCC_VENUS0_AHB_CLK>,
<&gcc GCC_VENUS0_AXI_CLK>;
clock-names = "core", "iface", "bus";
power-domains = <&gcc VENUS_GDSC>;
iommus = <&apps_iommu 5>;
memory-region = <&venus_mem>;
video-decoder {
compatible = "venus-decoder";
};
video-encoder {
compatible = "venus-encoder";
};
};

172
Documentation/devicetree/bindings/media/qcom,msm8996-venus.yaml Normal file
View File

@@ -0,0 +1,172 @@
# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
%YAML 1.2
---
$id: "http://devicetree.org/schemas/media/qcom,msm8996-venus.yaml#"
$schema: "http://devicetree.org/meta-schemas/core.yaml#"
title: Qualcomm Venus video encode and decode accelerators
maintainers:
- Stanimir Varbanov <stanimir.varbanov@linaro.org>
description: |
The Venus IP is a video encode and decode accelerator present
on Qualcomm platforms
properties:
compatible:
const: qcom,msm8996-venus
reg:
maxItems: 1
interrupts:
maxItems: 1
power-domains:
maxItems: 1
clocks:
maxItems: 4
clock-names:
items:
- const: core
- const: iface
- const: bus
- const: mbus
iommus:
maxItems: 20
memory-region:
maxItems: 1
video-decoder:
type: object
properties:
compatible:
const: venus-decoder
clocks:
maxItems: 1
clock-names:
items:
- const: core
power-domains:
maxItems: 1
required:
- compatible
- clocks
- clock-names
- power-domains
additionalProperties: false
video-encoder:
type: object
properties:
compatible:
const: venus-encoder
clocks:
maxItems: 1
clock-names:
items:
- const: core
power-domains:
maxItems: 1
required:
- compatible
- clocks
- clock-names
- power-domains
additionalProperties: false
video-firmware:
type: object
description: |
Firmware subnode is needed when the platform does not
have TrustZone.
properties:
iommus:
maxItems: 1
required:
- iommus
required:
- compatible
- reg
- interrupts
- power-domains
- clocks
- clock-names
- iommus
- memory-region
- video-decoder
- video-encoder
examples:
- |
#include <dt-bindings/interrupt-controller/arm-gic.h>
#include <dt-bindings/clock/qcom,mmcc-msm8996.h>
video-codec@c00000 {
compatible = "qcom,msm8996-venus";
reg = <0x00c00000 0xff000>;
interrupts = <GIC_SPI 287 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&mmcc VIDEO_CORE_CLK>,
<&mmcc VIDEO_AHB_CLK>,
<&mmcc VIDEO_AXI_CLK>,
<&mmcc VIDEO_MAXI_CLK>;
clock-names = "core", "iface", "bus", "mbus";
power-domains = <&mmcc VENUS_GDSC>;
iommus = <&venus_smmu 0x00>,
<&venus_smmu 0x01>,
<&venus_smmu 0x0a>,
<&venus_smmu 0x07>,
<&venus_smmu 0x0e>,
<&venus_smmu 0x0f>,
<&venus_smmu 0x08>,
<&venus_smmu 0x09>,
<&venus_smmu 0x0b>,
<&venus_smmu 0x0c>,
<&venus_smmu 0x0d>,
<&venus_smmu 0x10>,
<&venus_smmu 0x11>,
<&venus_smmu 0x21>,
<&venus_smmu 0x28>,
<&venus_smmu 0x29>,
<&venus_smmu 0x2b>,
<&venus_smmu 0x2c>,
<&venus_smmu 0x2d>,
<&venus_smmu 0x31>;
memory-region = <&venus_mem>;
video-decoder {
compatible = "venus-decoder";
clocks = <&mmcc VIDEO_SUBCORE0_CLK>;
clock-names = "core";
power-domains = <&mmcc VENUS_CORE0_GDSC>;
};
video-encoder {
compatible = "venus-encoder";
clocks = <&mmcc VIDEO_SUBCORE1_CLK>;
clock-names = "core";
power-domains = <&mmcc VENUS_CORE1_GDSC>;
};
};

140
Documentation/devicetree/bindings/media/qcom,sc7180-venus.yaml Normal file
View File

@@ -0,0 +1,140 @@
# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
%YAML 1.2
---
$id: "http://devicetree.org/schemas/media/qcom,sc7180-venus.yaml#"
$schema: "http://devicetree.org/meta-schemas/core.yaml#"
title: Qualcomm Venus video encode and decode accelerators
maintainers:
- Stanimir Varbanov <stanimir.varbanov@linaro.org>
description: |
The Venus IP is a video encode and decode accelerator present
on Qualcomm platforms
properties:
compatible:
const: qcom,sc7180-venus
reg:
maxItems: 1
interrupts:
maxItems: 1
power-domains:
maxItems: 2
power-domain-names:
items:
- const: venus
- const: vcodec0
clocks:
maxItems: 5
clock-names:
items:
- const: core
- const: iface
- const: bus
- const: vcodec0_core
- const: vcodec0_bus
iommus:
maxItems: 1
memory-region:
maxItems: 1
interconnects:
maxItems: 2
interconnect-names:
items:
- const: video-mem
- const: cpu-cfg
video-decoder:
type: object
properties:
compatible:
const: venus-decoder
required:
- compatible
additionalProperties: false
video-encoder:
type: object
properties:
compatible:
const: venus-encoder
required:
- compatible
additionalProperties: false
video-firmware:
type: object
description: |
Firmware subnode is needed when the platform does not
have TrustZone.
properties:
iommus:
maxItems: 1
required:
- iommus
required:
- compatible
- reg
- interrupts
- power-domains
- power-domain-names
- clocks
- clock-names
- iommus
- memory-region
- video-decoder
- video-encoder
examples:
- |
#include <dt-bindings/interrupt-controller/arm-gic.h>
#include <dt-bindings/clock/qcom,videocc-sc7180.h>
venus: video-codec@aa00000 {
compatible = "qcom,sc7180-venus";
reg = <0 0x0aa00000 0 0xff000>;
interrupts = <GIC_SPI 174 IRQ_TYPE_LEVEL_HIGH>;
power-domains = <&videocc VENUS_GDSC>,
<&videocc VCODEC0_GDSC>;
power-domain-names = "venus", "vcodec0";
clocks = <&videocc VIDEO_CC_VENUS_CTL_CORE_CLK>,
<&videocc VIDEO_CC_VENUS_AHB_CLK>,
<&videocc VIDEO_CC_VENUS_CTL_AXI_CLK>,
<&videocc VIDEO_CC_VCODEC0_CORE_CLK>,
<&videocc VIDEO_CC_VCODEC0_AXI_CLK>;
clock-names = "core", "iface", "bus",
"vcodec0_core", "vcodec0_bus";
iommus = <&apps_smmu 0x0c00 0x60>;
memory-region = <&venus_mem>;
video-decoder {
compatible = "venus-decoder";
};
video-encoder {
compatible = "venus-encoder";
};
};

140
Documentation/devicetree/bindings/media/qcom,sdm845-venus-v2.yaml Normal file
View File

@@ -0,0 +1,140 @@
# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
%YAML 1.2
---
$id: "http://devicetree.org/schemas/media/qcom,sdm845-venus-v2.yaml#"
$schema: "http://devicetree.org/meta-schemas/core.yaml#"
title: Qualcomm Venus video encode and decode accelerators
maintainers:
- Stanimir Varbanov <stanimir.varbanov@linaro.org>
description: |
The Venus IP is a video encode and decode accelerator present
on Qualcomm platforms
properties:
compatible:
const: qcom,sdm845-venus-v2
reg:
maxItems: 1
interrupts:
maxItems: 1
power-domains:
maxItems: 3
power-domain-names:
items:
- const: venus
- const: vcodec0
- const: vcodec1
clocks:
maxItems: 7
clock-names:
items:
- const: core
- const: iface
- const: bus
- const: vcodec0_core
- const: vcodec0_bus
- const: vcodec1_core
- const: vcodec1_bus
iommus:
maxItems: 2
memory-region:
maxItems: 1
video-core0:
type: object
properties:
compatible:
const: venus-decoder
required:
- compatible
additionalProperties: false
video-core1:
type: object
properties:
compatible:
const: venus-encoder
required:
- compatible
additionalProperties: false
video-firmware:
type: object
description: |
Firmware subnode is needed when the platform does not
have TrustZone.
properties:
iommus:
maxItems: 1
required:
- iommus
required:
- compatible
- reg
- interrupts
- power-domains
- power-domain-names
- clocks
- clock-names
- iommus
- memory-region
- video-core0
- video-core1
examples:
- |
#include <dt-bindings/interrupt-controller/arm-gic.h>
#include <dt-bindings/clock/qcom,videocc-sdm845.h>
video-codec@aa00000 {
compatible = "qcom,sdm845-venus-v2";
reg = <0 0x0aa00000 0 0xff000>;
interrupts = <GIC_SPI 174 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&videocc VIDEO_CC_VENUS_CTL_CORE_CLK>,
<&videocc VIDEO_CC_VENUS_AHB_CLK>,
<&videocc VIDEO_CC_VENUS_CTL_AXI_CLK>,
<&videocc VIDEO_CC_VCODEC0_CORE_CLK>,
<&videocc VIDEO_CC_VCODEC0_AXI_CLK>,
<&videocc VIDEO_CC_VCODEC1_CORE_CLK>,
<&videocc VIDEO_CC_VCODEC1_AXI_CLK>;
clock-names = "core", "iface", "bus",
"vcodec0_core", "vcodec0_bus",
"vcodec1_core", "vcodec1_bus";
power-domains = <&videocc VENUS_GDSC>,
<&videocc VCODEC0_GDSC>,
<&videocc VCODEC1_GDSC>;
power-domain-names = "venus", "vcodec0", "vcodec1";
iommus = <&apps_smmu 0x10a0 0x8>,
<&apps_smmu 0x10b0 0x0>;
memory-region = <&venus_mem>;
video-core0 {
compatible = "venus-decoder";
};
video-core1 {
compatible = "venus-encoder";
};
};

156
Documentation/devicetree/bindings/media/qcom,sdm845-venus.yaml Normal file
View File

@@ -0,0 +1,156 @@
# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
%YAML 1.2
---
$id: "http://devicetree.org/schemas/media/qcom,sdm845-venus.yaml#"
$schema: "http://devicetree.org/meta-schemas/core.yaml#"
title: Qualcomm Venus video encode and decode accelerators
maintainers:
- Stanimir Varbanov <stanimir.varbanov@linaro.org>
description: |
The Venus IP is a video encode and decode accelerator present
on Qualcomm platforms
properties:
compatible:
const: qcom,sdm845-venus
reg:
maxItems: 1
interrupts:
maxItems: 1
power-domains:
maxItems: 1
clocks:
maxItems: 3
clock-names:
items:
- const: core
- const: iface
- const: bus
iommus:
maxItems: 2
memory-region:
maxItems: 1
video-core0:
type: object
properties:
compatible:
const: venus-decoder
clocks:
maxItems: 2
clock-names:
items:
- const: core
- const: bus
power-domains:
maxItems: 1
required:
- compatible
- clocks
- clock-names
- power-domains
additionalProperties: false
video-core1:
type: object
properties:
compatible:
const: venus-encoder
clocks:
maxItems: 2
clock-names:
items:
- const: core
- const: bus
power-domains:
maxItems: 1
required:
- compatible
- clocks
- clock-names
- power-domains
additionalProperties: false
video-firmware:
type: object
description: |
Firmware subnode is needed when the platform does not
have TrustZone.
properties:
iommus:
maxItems: 1
required:
- iommus
required:
- compatible
- reg
- interrupts
- power-domains
- clocks
- clock-names
- iommus
- memory-region
- video-core0
- video-core1
examples:
- |
#include <dt-bindings/interrupt-controller/arm-gic.h>
#include <dt-bindings/clock/qcom,videocc-sdm845.h>
video-codec@aa00000 {
compatible = "qcom,sdm845-venus";
reg = <0 0x0aa00000 0 0xff000>;
interrupts = <GIC_SPI 174 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&videocc VIDEO_CC_VENUS_CTL_CORE_CLK>,
<&videocc VIDEO_CC_VENUS_AHB_CLK>,
<&videocc VIDEO_CC_VENUS_CTL_AXI_CLK>;
clock-names = "core", "iface", "bus";
power-domains = <&videocc VENUS_GDSC>;
iommus = <&apps_smmu 0x10a0 0x8>,
<&apps_smmu 0x10b0 0x0>;
memory-region = <&venus_mem>;
video-core0 {
compatible = "venus-decoder";
clocks = <&videocc VIDEO_CC_VCODEC0_CORE_CLK>,
<&videocc VIDEO_CC_VCODEC0_AXI_CLK>;
clock-names = "core", "bus";
power-domains = <&videocc VCODEC0_GDSC>;
};
video-core1 {
compatible = "venus-encoder";
clocks = <&videocc VIDEO_CC_VCODEC1_CORE_CLK>,
<&videocc VIDEO_CC_VCODEC1_AXI_CLK>;
clock-names = "core", "bus";
power-domains = <&videocc VCODEC1_GDSC>;
};
};

120
Documentation/devicetree/bindings/media/qcom,venus.txt
View File

@@ -1,120 +0,0 @@
* Qualcomm Venus video encoder/decoder accelerators
- compatible:
Usage: required
Value type: <stringlist>
Definition: Value should contain one of:
- "qcom,msm8916-venus"
- "qcom,msm8996-venus"
- "qcom,sdm845-venus"
- reg:
Usage: required
Value type: <prop-encoded-array>
Definition: Register base address and length of the register map.
- interrupts:
Usage: required
Value type: <prop-encoded-array>
Definition: Should contain interrupt line number.
- clocks:
Usage: required
Value type: <prop-encoded-array>
Definition: A List of phandle and clock specifier pairs as listed
in clock-names property.
- clock-names:
Usage: required for msm8916
Value type: <stringlist>
Definition: Should contain the following entries:
- "core" Core video accelerator clock
- "iface" Video accelerator AHB clock
- "bus" Video accelerator AXI clock
- clock-names:
Usage: required for msm8996
Value type: <stringlist>
Definition: Should contain the following entries:
- "core" Core video accelerator clock
- "iface" Video accelerator AHB clock
- "bus" Video accelerator AXI clock
- "mbus" Video MAXI clock
- power-domains:
Usage: required
Value type: <prop-encoded-array>
Definition: A phandle and power domain specifier pairs to the
power domain which is responsible for collapsing
and restoring power to the peripheral.
- iommus:
Usage: required
Value type: <prop-encoded-array>
Definition: A list of phandle and IOMMU specifier pairs.
- memory-region:
Usage: required
Value type: <phandle>
Definition: reference to the reserved-memory for the firmware
memory region.
* Subnodes
The Venus video-codec node must contain two subnodes representing
video-decoder and video-encoder, and one optional firmware subnode.
Firmware subnode is needed when the platform does not have TrustZone.
Every of video-encoder or video-decoder subnode should have:
- compatible:
Usage: required
Value type: <stringlist>
Definition: Value should contain "venus-decoder" or "venus-encoder"
- clocks:
Usage: required for msm8996
Value type: <prop-encoded-array>
Definition: A List of phandle and clock specifier pairs as listed
in clock-names property.
- clock-names:
Usage: required for msm8996
Value type: <stringlist>
Definition: Should contain the following entries:
- "core" Subcore video accelerator clock
- power-domains:
Usage: required for msm8996
Value type: <prop-encoded-array>
Definition: A phandle and power domain specifier pairs to the
power domain which is responsible for collapsing
and restoring power to the subcore.
The firmware subnode must have:
- iommus:
Usage: required
Value type: <prop-encoded-array>
Definition: A list of phandle and IOMMU specifier pairs.
* An Example
video-codec@1d00000 {
compatible = "qcom,msm8916-venus";
reg = <0x01d00000 0xff000>;
interrupts = <GIC_SPI 44 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&gcc GCC_VENUS0_VCODEC0_CLK>,
<&gcc GCC_VENUS0_AHB_CLK>,
<&gcc GCC_VENUS0_AXI_CLK>;
clock-names = "core", "iface", "bus";
power-domains = <&gcc VENUS_GDSC>;
iommus = <&apps_iommu 5>;
memory-region = <&venus_mem>;
video-decoder {
compatible = "venus-decoder";
clocks = <&mmcc VIDEO_SUBCORE0_CLK>;
clock-names = "core";
power-domains = <&mmcc VENUS_CORE0_GDSC>;
};
video-encoder {
compatible = "venus-encoder";
clocks = <&mmcc VIDEO_SUBCORE1_CLK>;
clock-names = "core";
power-domains = <&mmcc VENUS_CORE1_GDSC>;
};
video-firmware {
iommus = <&apps_iommu 0x10b2 0x0>;
};
};

1
Documentation/devicetree/bindings/media/rc.yaml
View File

@@ -143,6 +143,7 @@ properties:
- rc-videomate-k100
- rc-videomate-s350
- rc-videomate-tv-pvr
- rc-videostrong-kii-pro
- rc-wetek-hub
- rc-wetek-play2
- rc-winfast

5
Documentation/devicetree/bindings/media/rockchip-rga.txt
View File

@@ -6,8 +6,9 @@ BitBLT, alpha blending and image blur/sharpness.
Required properties:
- compatible: value should be one of the following
"rockchip,rk3288-rga";
"rockchip,rk3399-rga";
"rockchip,rk3228-rga", "rockchip,rk3288-rga": for Rockchip RK3228
"rockchip,rk3288-rga": for Rockchip RK3288
"rockchip,rk3399-rga": for Rockchip RK3399
- interrupts: RGA interrupt specifier.

4
Documentation/devicetree/bindings/mfd/qcom-rpm.txt
View File

@@ -61,6 +61,7 @@ Regulator nodes are identified by their compatible:
"qcom,rpm-pm8901-regulators"
"qcom,rpm-pm8921-regulators"
"qcom,rpm-pm8018-regulators"
"qcom,rpm-smb208-regulators"
- vdd_l0_l1_lvs-supply:
- vdd_l2_l11_l12-supply:
@@ -171,6 +172,9 @@ pm8018:
s1, s2, s3, s4, s5, , l1, l2, l3, l4, l5, l6, l7, l8, l9, l10, l11,
l12, l14, lvs1
smb208:
s1a, s1b, s2a, s2b
The content of each sub-node is defined by the standard binding for regulators -
see regulator.txt - with additional custom properties described below:

3
Documentation/devicetree/bindings/opp/qcom-nvmem-cpufreq.txt
View File

@@ -19,7 +19,8 @@ In 'cpu' nodes:
In 'operating-points-v2' table:
- compatible: Should be
- 'operating-points-v2-kryo-cpu' for apq8096 and msm8996.
- 'operating-points-v2-kryo-cpu' for apq8096, msm8996, msm8974,
apq8064, ipq8064, msm8960 and ipq8074.
Optional properties:
--------------------

14
Documentation/devicetree/bindings/phy/amlogic,meson-g12a-usb2-phy.yaml
View File

@@ -14,6 +14,7 @@ properties:
compatible:
enum:
- amlogic,meson-g12a-usb2-phy
- amlogic,meson-a1-usb2-phy
reg:
maxItems: 1
@@ -49,6 +50,19 @@ required:
- reset-names
- "#phy-cells"
if:
properties:
compatible:
enum:
- amlogic,meson-a1-usb-ctrl
then:
properties:
power-domains:
maxItems: 1
required:
- power-domains
examples:
- |
phy@36000 {

30
Documentation/devicetree/bindings/phy/phy-cadence-dp.txt
View File

@@ -1,30 +0,0 @@
Cadence MHDP DisplayPort SD0801 PHY binding
===========================================
This binding describes the Cadence SD0801 PHY hardware included with
the Cadence MHDP DisplayPort controller.
-------------------------------------------------------------------------------
Required properties (controller (parent) node):
- compatible : Should be "cdns,dp-phy"
- reg : Defines the following sets of registers in the parent
mhdp device:
- Offset of the DPTX PHY configuration registers
- Offset of the SD0801 PHY configuration registers
- #phy-cells : from the generic PHY bindings, must be 0.
Optional properties:
- num_lanes : Number of DisplayPort lanes to use (1, 2 or 4)
- max_bit_rate : Maximum DisplayPort link bit rate to use, in Mbps (2160,
2430, 2700, 3240, 4320, 5400 or 8100)
-------------------------------------------------------------------------------
Example:
dp_phy: phy@f0fb030a00 {
compatible = "cdns,dp-phy";
reg = <0xf0 0xfb030a00 0x0 0x00000040>,
<0xf0 0xfb500000 0x0 0x00100000>;
num_lanes = <4>;
max_bit_rate = <8100>;
#phy-cells = <0>;
};

143
Documentation/devicetree/bindings/phy/phy-cadence-torrent.yaml Normal file
View File

@@ -0,0 +1,143 @@
# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
%YAML 1.2
---
$id: "http://devicetree.org/schemas/phy/phy-cadence-torrent.yaml#"
$schema: "http://devicetree.org/meta-schemas/core.yaml#"
title: Cadence Torrent SD0801 PHY binding for DisplayPort
description:
This binding describes the Cadence SD0801 PHY (also known as Torrent PHY)
hardware included with the Cadence MHDP DisplayPort controller.
maintainers:
- Swapnil Jakhade <sjakhade@cadence.com>
- Yuti Amonkar <yamonkar@cadence.com>
properties:
compatible:
enum:
- cdns,torrent-phy
- ti,j721e-serdes-10g
'#address-cells':
const: 1
'#size-cells':
const: 0
clocks:
maxItems: 1
description:
PHY reference clock. Must contain an entry in clock-names.
clock-names:
const: refclk
reg:
minItems: 1
maxItems: 2
items:
- description: Offset of the Torrent PHY configuration registers.
- description: Offset of the DPTX PHY configuration registers.
reg-names:
minItems: 1
maxItems: 2
items:
- const: torrent_phy
- const: dptx_phy
resets:
maxItems: 1
description:
Torrent PHY reset.
See Documentation/devicetree/bindings/reset/reset.txt
patternProperties:
'^phy@[0-7]+$':
type: object
description:
Each group of PHY lanes with a single master lane should be represented as a sub-node.
properties:
reg:
description:
The master lane number. This is the lowest numbered lane in the lane group.
resets:
minItems: 1
maxItems: 4
description:
Contains list of resets, one per lane, to get all the link lanes out of reset.
"#phy-cells":
const: 0
cdns,phy-type:
description:
Specifies the type of PHY for which the group of PHY lanes is used.
Refer include/dt-bindings/phy/phy.h. Constants from the header should be used.
allOf:
- $ref: /schemas/types.yaml#/definitions/uint32
- enum: [1, 2, 3, 4, 5, 6]
cdns,num-lanes:
description:
Number of DisplayPort lanes.
allOf:
- $ref: /schemas/types.yaml#/definitions/uint32
- enum: [1, 2, 4]
default: 4
cdns,max-bit-rate:
description:
Maximum DisplayPort link bit rate to use, in Mbps
allOf:
- $ref: /schemas/types.yaml#/definitions/uint32
- enum: [2160, 2430, 2700, 3240, 4320, 5400, 8100]
default: 8100
required:
- reg
- resets
- "#phy-cells"
- cdns,phy-type
additionalProperties: false
required:
- compatible
- "#address-cells"
- "#size-cells"
- clocks
- clock-names
- reg
- reg-names
- resets
additionalProperties: false
examples:
- |
#include <dt-bindings/phy/phy.h>
torrent_phy: torrent-phy@f0fb500000 {
compatible = "cdns,torrent-phy";
reg = <0xf0 0xfb500000 0x0 0x00100000>,
<0xf0 0xfb030a00 0x0 0x00000040>;
reg-names = "torrent_phy", "dptx_phy";
resets = <&phyrst 0>;
clocks = <&ref_clk>;
clock-names = "refclk";
#address-cells = <1>;
#size-cells = <0>;
torrent_phy_dp: phy@0 {
reg = <0>;
resets = <&phyrst 1>, <&phyrst 2>,
<&phyrst 3>, <&phyrst 4>;
#phy-cells = <0>;
cdns,phy-type = <PHY_TYPE_DP>;
cdns,num-lanes = <4>;
cdns,max-bit-rate = <8100>;
};
};
...

32
Documentation/devicetree/bindings/phy/phy-mtk-tphy.txt
View File

@@ -13,10 +13,16 @@ Required properties (controller (parent) node):
"mediatek,mt8173-u3phy";
make use of "mediatek,generic-tphy-v1" on mt2701 instead and
"mediatek,generic-tphy-v2" on mt2712 instead.
- clocks : (deprecated, use port's clocks instead) a list of phandle +
clock-specifier pairs, one for each entry in clock-names
- clock-names : (deprecated, use port's one instead) must contain
"u3phya_ref": for reference clock of usb3.0 analog phy.
- #address-cells: the number of cells used to represent physical
base addresses.
- #size-cells: the number of cells used to represent the size of an address.
- ranges: the address mapping relationship to the parent, defined with
- empty value: if optional 'reg' is used.
- non-empty value: if optional 'reg' is not used. should set
the child's base address to 0, the physical address
within parent's address space, and the length of
the address map.
Required nodes : a sub-node is required for each port the controller
provides. Address range information including the usual
@@ -34,12 +40,6 @@ Optional properties (controller (parent) node):
Required properties (port (child) node):
- reg : address and length of the register set for the port.
- clocks : a list of phandle + clock-specifier pairs, one for each
entry in clock-names
- clock-names : must contain
"ref": 48M reference clock for HighSpeed analog phy; and 26M
reference clock for SuperSpeed analog phy, sometimes is
24M, 25M or 27M, depended on platform.
- #phy-cells : should be 1 (See second example)
cell after port phandle is phy type from:
- PHY_TYPE_USB2
@@ -48,10 +48,22 @@ Required properties (port (child) node):
- PHY_TYPE_SATA
Optional properties (PHY_TYPE_USB2 port (child) node):
- clocks : a list of phandle + clock-specifier pairs, one for each
entry in clock-names
- clock-names : may contain
"ref": 48M reference clock for HighSpeed (digital) phy; and 26M
reference clock for SuperSpeed (digital) phy, sometimes is
24M, 25M or 27M, depended on platform.
"da_ref": the reference clock of analog phy, used if the clocks
of analog and digital phys are separated, otherwise uses
"ref" clock only if needed.
- mediatek,eye-src : u32, the value of slew rate calibrate
- mediatek,eye-vrt : u32, the selection of VRT reference voltage
- mediatek,eye-term : u32, the selection of HS_TX TERM reference voltage
- mediatek,bc12 : bool, enable BC12 of u2phy if support it
- mediatek,discth : u32, the selection of disconnect threshold
- mediatek,intr : u32, the selection of internal R (resistance)
Example:

185
Documentation/devicetree/bindings/phy/qcom,qusb2-phy.yaml Normal file
View File

@@ -0,0 +1,185 @@
# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
%YAML 1.2
---
$id: "http://devicetree.org/schemas/phy/qcom,qusb2-phy.yaml#"
$schema: "http://devicetree.org/meta-schemas/core.yaml#"
title: Qualcomm QUSB2 phy controller
maintainers:
- Manu Gautam <mgautam@codeaurora.org>
description:
QUSB2 controller supports LS/FS/HS usb connectivity on Qualcomm chipsets.
properties:
compatible:
oneOf:
- items:
- enum:
- qcom,msm8996-qusb2-phy
- qcom,msm8998-qusb2-phy
- items:
- enum:
- qcom,sc7180-qusb2-phy
- qcom,sdm845-qusb2-phy
- const: qcom,qusb2-v2-phy
reg:
maxItems: 1
"#phy-cells":
const: 0
clocks:
minItems: 2
maxItems: 3
items:
- description: phy config clock
- description: 19.2 MHz ref clk
- description: phy interface clock (Optional)
clock-names:
minItems: 2
maxItems: 3
items:
- const: cfg_ahb
- const: ref
- const: iface
vdda-pll-supply:
description:
Phandle to 1.8V regulator supply to PHY refclk pll block.
vdda-phy-dpdm-supply:
description:
Phandle to 3.1V regulator supply to Dp/Dm port signals.
resets:
maxItems: 1
description:
Phandle to reset to phy block.
nvmem-cells:
maxItems: 1
description:
Phandle to nvmem cell that contains 'HS Tx trim'
tuning parameter value for qusb2 phy.
qcom,tcsr-syscon:
description:
Phandle to TCSR syscon register region.
$ref: /schemas/types.yaml#/definitions/phandle
if:
properties:
compatible:
contains:
const: qcom,qusb2-v2-phy
then:
properties:
qcom,imp-res-offset-value:
description:
It is a 6 bit value that specifies offset to be
added to PHY refgen RESCODE via IMP_CTRL1 register. It is a PHY
tuning parameter that may vary for different boards of same SOC.
allOf:
- $ref: /schemas/types.yaml#/definitions/uint32
- minimum: 0
maximum: 63
default: 0
qcom,bias-ctrl-value:
description:
It is a 6 bit value that specifies bias-ctrl-value. It is a PHY
tuning parameter that may vary for different boards of same SOC.
allOf:
- $ref: /schemas/types.yaml#/definitions/uint32
- minimum: 0
maximum: 63
default: 0
qcom,charge-ctrl-value:
description:
It is a 2 bit value that specifies charge-ctrl-value. It is a PHY
tuning parameter that may vary for different boards of same SOC.
allOf:
- $ref: /schemas/types.yaml#/definitions/uint32
- minimum: 0
maximum: 3
default: 0
qcom,hstx-trim-value:
description:
It is a 4 bit value that specifies tuning for HSTX
output current.
Possible range is - 15mA to 24mA (stepsize of 600 uA).
See dt-bindings/phy/phy-qcom-qusb2.h for applicable values.
allOf:
- $ref: /schemas/types.yaml#/definitions/uint32
- minimum: 0
maximum: 15
default: 3
qcom,preemphasis-level:
description:
It is a 2 bit value that specifies pre-emphasis level.
Possible range is 0 to 15% (stepsize of 5%).
See dt-bindings/phy/phy-qcom-qusb2.h for applicable values.
allOf:
- $ref: /schemas/types.yaml#/definitions/uint32
- minimum: 0
maximum: 3
default: 2
qcom,preemphasis-width:
description:
It is a 1 bit value that specifies how long the HSTX
pre-emphasis (specified using qcom,preemphasis-level) must be in
effect. Duration could be half-bit of full-bit.
See dt-bindings/phy/phy-qcom-qusb2.h for applicable values.
allOf:
- $ref: /schemas/types.yaml#/definitions/uint32
- minimum: 0
maximum: 1
default: 0
qcom,hsdisc-trim-value:
description:
It is a 2 bit value tuning parameter that control disconnect
threshold and may vary for different boards of same SOC.
allOf:
- $ref: /schemas/types.yaml#/definitions/uint32
- minimum: 0
maximum: 3
default: 0
required:
- compatible
- reg
- "#phy-cells"
- clocks
- clock-names
- vdda-pll-supply
- vdda-phy-dpdm-supply
- resets
examples:
- |
#include <dt-bindings/clock/qcom,gcc-msm8996.h>
hsusb_phy: phy@7411000 {
compatible = "qcom,msm8996-qusb2-phy";
reg = <0x7411000 0x180>;
#phy-cells = <0>;
clocks = <&gcc GCC_USB_PHY_CFG_AHB2PHY_CLK>,
<&gcc GCC_RX1_USB2_CLKREF_CLK>;
clock-names = "cfg_ahb", "ref";
vdda-pll-supply = <&pm8994_l12>;
vdda-phy-dpdm-supply = <&pm8994_l24>;
resets = <&gcc GCC_QUSB2PHY_PRIM_BCR>;
nvmem-cells = <&qusb2p_hstx_trim>;
};

90
Documentation/devicetree/bindings/phy/qcom,usb-hs-28nm.yaml Normal file
View File

@@ -0,0 +1,90 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: "http://devicetree.org/schemas/phy/qcom,usb-hs-28nm.yaml#"
$schema: "http://devicetree.org/meta-schemas/core.yaml#"
title: Qualcomm Synopsys DesignWare Core 28nm High-Speed PHY
maintainers:
- Bryan O'Donoghue <bryan.odonoghue@linaro.org>
description: |
Qualcomm Low-Speed, Full-Speed, Hi-Speed 28nm USB PHY
properties:
compatible:
enum:
- qcom,usb-hs-28nm-femtophy
reg:
maxItems: 1
"#phy-cells":
const: 0
clocks:
items:
- description: rpmcc ref clock
- description: PHY AHB clock
- description: Rentention clock
clock-names:
items:
- const: ref
- const: ahb
- const: sleep
resets:
items:
- description: PHY core reset
- description: POR reset
reset-names:
items:
- const: phy
- const: por
vdd-supply:
description: phandle to the regulator VDD supply node.
vdda1p8-supply:
description: phandle to the regulator 1.8V supply node.
vdda3p3-supply:
description: phandle to the regulator 3.3V supply node.
required:
- compatible
- reg
- "#phy-cells"
- clocks
- clock-names
- resets
- reset-names
- vdd-supply
- vdda1p8-supply
- vdda3p3-supply
additionalProperties: false
examples:
- |
#include <dt-bindings/clock/qcom,gcc-qcs404.h>
#include <dt-bindings/clock/qcom,rpmcc.h>
usb2_phy_prim: phy@7a000 {
compatible = "qcom,usb-hs-28nm-femtophy";
reg = <0x0007a000 0x200>;
#phy-cells = <0>;
clocks = <&rpmcc RPM_SMD_LN_BB_CLK>,
<&gcc GCC_USB_HS_PHY_CFG_AHB_CLK>,
<&gcc GCC_USB2A_PHY_SLEEP_CLK>;
clock-names = "ref", "ahb", "sleep";
resets = <&gcc GCC_USB_HS_PHY_CFG_AHB_BCR>,
<&gcc GCC_USB2A_PHY_BCR>;
reset-names = "phy", "por";
vdd-supply = <&vreg_l4_1p2>;
vdda1p8-supply = <&vreg_l5_1p8>;
vdda3p3-supply = <&vreg_l12_3p3>;
};
...

83
Documentation/devicetree/bindings/phy/qcom,usb-ss.yaml Normal file
View File

@@ -0,0 +1,83 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: "http://devicetree.org/schemas/phy/qcom,usb-ss.yaml#"
$schema: "http://devicetree.org/meta-schemas/core.yaml#"
title: Qualcomm Synopsys 1.0.0 SuperSpeed USB PHY
maintainers:
- Bryan O'Donoghue <bryan.odonoghue@linaro.org>
description: |
Qualcomm Synopsys 1.0.0 SuperSpeed USB PHY
properties:
compatible:
enum:
- qcom,usb-ss-28nm-phy
reg:
maxItems: 1
"#phy-cells":
const: 0
clocks:
items:
- description: rpmcc clock
- description: PHY AHB clock
- description: SuperSpeed pipe clock
clock-names:
items:
- const: ref
- const: ahb
- const: pipe
vdd-supply:
description: phandle to the regulator VDD supply node.
vdda1p8-supply:
description: phandle to the regulator 1.8V supply node.
resets:
items:
- description: COM reset
- description: PHY reset line
reset-names:
items:
- const: com
- const: phy
required:
- compatible
- reg
- "#phy-cells"
- clocks
- clock-names
- vdd-supply
- vdda1p8-supply
additionalProperties: false
examples:
- |
#include <dt-bindings/clock/qcom,gcc-qcs404.h>
#include <dt-bindings/clock/qcom,rpmcc.h>
usb3_phy: usb3-phy@78000 {
compatible = "qcom,usb-ss-28nm-phy";
reg = <0x78000 0x400>;
#phy-cells = <0>;
clocks = <&rpmcc RPM_SMD_LN_BB_CLK>,
<&gcc GCC_USB_HS_PHY_CFG_AHB_CLK>,
<&gcc GCC_USB3_PHY_PIPE_CLK>;
clock-names = "ref", "ahb", "pipe";
resets = <&gcc GCC_USB3_PHY_BCR>,
<&gcc GCC_USB3PHY_PHY_BCR>;
reset-names = "com", "phy";
vdd-supply = <&vreg_l3_1p05>;
vdda1p8-supply = <&vreg_l5_1p8>;
};
...

37
Documentation/devicetree/bindings/phy/qcom-dwc3-usb-phy.txt
View File

@@ -1,37 +0,0 @@
Qualcomm DWC3 HS AND SS PHY CONTROLLER
--------------------------------------
DWC3 PHY nodes are defined to describe on-chip Synopsis Physical layer
controllers. Each DWC3 PHY controller should have its own node.
Required properties:
- compatible: should contain one of the following:
- "qcom,dwc3-hs-usb-phy" for High Speed Synopsis PHY controller
- "qcom,dwc3-ss-usb-phy" for Super Speed Synopsis PHY controller
- reg: offset and length of the DWC3 PHY controller register set
- #phy-cells: must be zero
- clocks: a list of phandles and clock-specifier pairs, one for each entry in
clock-names.
- clock-names: Should contain "ref" for the PHY reference clock
Optional clocks:
"xo" External reference clock
Example:
phy@100f8800 {
compatible = "qcom,dwc3-hs-usb-phy";
reg = <0x100f8800 0x30>;
clocks = <&gcc USB30_0_UTMI_CLK>;
clock-names = "ref";
#phy-cells = <0>;
};
phy@100f8830 {
compatible = "qcom,dwc3-ss-usb-phy";
reg = <0x100f8830 0x30>;
clocks = <&gcc USB30_0_MASTER_CLK>;
clock-names = "ref";
#phy-cells = <0>;
};

15
Documentation/devicetree/bindings/phy/qcom-qmp-phy.txt
View File

@@ -8,10 +8,13 @@ Required properties:
- compatible: compatible list, contains:
"qcom,ipq8074-qmp-pcie-phy" for PCIe phy on IPQ8074
"qcom,msm8996-qmp-pcie-phy" for 14nm PCIe phy on msm8996,
"qcom,msm8996-qmp-ufs-phy" for 14nm UFS phy on msm8996,
"qcom,msm8996-qmp-usb3-phy" for 14nm USB3 phy on msm8996,
"qcom,msm8998-qmp-usb3-phy" for USB3 QMP V3 phy on msm8998,
"qcom,msm8998-qmp-ufs-phy" for UFS QMP phy on msm8998,
"qcom,msm8998-qmp-pcie-phy" for PCIe QMP phy on msm8998,
"qcom,sdm845-qhp-pcie-phy" for QHP PCIe phy on sdm845,
"qcom,sdm845-qmp-pcie-phy" for QMP PCIe phy on sdm845,
"qcom,sdm845-qmp-usb3-phy" for USB3 QMP V3 phy on sdm845,
"qcom,sdm845-qmp-usb3-uni-phy" for USB3 QMP V3 UNI phy on sdm845,
"qcom,sdm845-qmp-ufs-phy" for UFS QMP phy on sdm845,
@@ -44,6 +47,8 @@ Required properties:
For "qcom,ipq8074-qmp-pcie-phy": no clocks are listed.
For "qcom,msm8996-qmp-pcie-phy" must contain:
"aux", "cfg_ahb", "ref".
For "qcom,msm8996-qmp-ufs-phy" must contain:
"ref".
For "qcom,msm8996-qmp-usb3-phy" must contain:
"aux", "cfg_ahb", "ref".
For "qcom,msm8998-qmp-usb3-phy" must contain:
@@ -52,6 +57,10 @@ Required properties:
"ref", "ref_aux".
For "qcom,msm8998-qmp-pcie-phy" must contain:
"aux", "cfg_ahb", "ref".
For "qcom,sdm845-qhp-pcie-phy" must contain:
"aux", "cfg_ahb", "ref", "refgen".
For "qcom,sdm845-qmp-pcie-phy" must contain:
"aux", "cfg_ahb", "ref", "refgen".
For "qcom,sdm845-qmp-usb3-phy" must contain:
"aux", "cfg_ahb", "ref", "com_aux".
For "qcom,sdm845-qmp-usb3-uni-phy" must contain:
@@ -72,6 +81,8 @@ Required properties:
"phy", "common".
For "qcom,msm8996-qmp-pcie-phy" must contain:
"phy", "common", "cfg".
For "qcom,msm8996-qmp-ufs-phy": must contain:
"ufsphy".
For "qcom,msm8996-qmp-usb3-phy" must contain
"phy", "common".
For "qcom,msm8998-qmp-usb3-phy" must contain
@@ -80,6 +91,10 @@ Required properties:
"ufsphy".
For "qcom,msm8998-qmp-pcie-phy" must contain:
"phy", "common".
For "qcom,sdm845-qhp-pcie-phy" must contain:
"phy".
For "qcom,sdm845-qmp-pcie-phy" must contain:
"phy".
For "qcom,sdm845-qmp-usb3-phy" must contain:
"phy", "common".
For "qcom,sdm845-qmp-usb3-uni-phy" must contain:

68
Documentation/devicetree/bindings/phy/qcom-qusb2-phy.txt
View File

@@ -1,68 +0,0 @@
Qualcomm QUSB2 phy controller
=============================
QUSB2 controller supports LS/FS/HS usb connectivity on Qualcomm chipsets.
Required properties:
- compatible: compatible list, contains
"qcom,msm8996-qusb2-phy" for 14nm PHY on msm8996,
"qcom,msm8998-qusb2-phy" for 10nm PHY on msm8998,
"qcom,sdm845-qusb2-phy" for 10nm PHY on sdm845.
- reg: offset and length of the PHY register set.
- #phy-cells: must be 0.
- clocks: a list of phandles and clock-specifier pairs,
one for each entry in clock-names.
- clock-names: must be "cfg_ahb" for phy config clock,
"ref" for 19.2 MHz ref clk,
"iface" for phy interface clock (Optional).
- vdda-pll-supply: Phandle to 1.8V regulator supply to PHY refclk pll block.
- vdda-phy-dpdm-supply: Phandle to 3.1V regulator supply to Dp/Dm port signals.
- resets: Phandle to reset to phy block.
Optional properties:
- nvmem-cells: Phandle to nvmem cell that contains 'HS Tx trim'
tuning parameter value for qusb2 phy.
- qcom,tcsr-syscon: Phandle to TCSR syscon register region.
- qcom,imp-res-offset-value: It is a 6 bit value that specifies offset to be
added to PHY refgen RESCODE via IMP_CTRL1 register. It is a PHY
tuning parameter that may vary for different boards of same SOC.
This property is applicable to only QUSB2 v2 PHY (sdm845).
- qcom,hstx-trim-value: It is a 4 bit value that specifies tuning for HSTX
output current.
Possible range is - 15mA to 24mA (stepsize of 600 uA).
See dt-bindings/phy/phy-qcom-qusb2.h for applicable values.
This property is applicable to only QUSB2 v2 PHY (sdm845).
Default value is 22.2mA for sdm845.
- qcom,preemphasis-level: It is a 2 bit value that specifies pre-emphasis level.
Possible range is 0 to 15% (stepsize of 5%).
See dt-bindings/phy/phy-qcom-qusb2.h for applicable values.
This property is applicable to only QUSB2 v2 PHY (sdm845).
Default value is 10% for sdm845.
- qcom,preemphasis-width: It is a 1 bit value that specifies how long the HSTX
pre-emphasis (specified using qcom,preemphasis-level) must be in
effect. Duration could be half-bit of full-bit.
See dt-bindings/phy/phy-qcom-qusb2.h for applicable values.
This property is applicable to only QUSB2 v2 PHY (sdm845).
Default value is full-bit width for sdm845.
Example:
hsusb_phy: phy@7411000 {
compatible = "qcom,msm8996-qusb2-phy";
reg = <0x7411000 0x180>;
#phy-cells = <0>;
clocks = <&gcc GCC_USB_PHY_CFG_AHB2PHY_CLK>,
<&gcc GCC_RX1_USB2_CLKREF_CLK>,
clock-names = "cfg_ahb", "ref";
vdda-pll-supply = <&pm8994_l12>;
vdda-phy-dpdm-supply = <&pm8994_l24>;
resets = <&gcc GCC_QUSB2PHY_PRIM_BCR>;
nvmem-cells = <&qusb2p_hstx_trim>;
};

1
Documentation/devicetree/bindings/phy/ti-phy-gmii-sel.txt
View File

@@ -40,6 +40,7 @@ Required properties:
"ti,dra7xx-phy-gmii-sel" for dra7xx/am57xx platform
"ti,am43xx-phy-gmii-sel" for am43xx platform
"ti,dm814-phy-gmii-sel" for dm814x platform
"ti,am654-phy-gmii-sel" for AM654x/J721E platform
- reg : Address and length of the register set for the device
- #phy-cells : must be 2.
cell 1 - CPSW port number (starting from 1)

13
Documentation/devicetree/bindings/phy/uniphier-pcie-phy.txt
View File

@@ -5,14 +5,19 @@ PCIe controller implemented on Socionext UniPhier SoCs.
Required properties:
- compatible: Should contain one of the following:
"socionext,uniphier-pro5-pcie-phy" - for Pro5 PHY
"socionext,uniphier-ld20-pcie-phy" - for LD20 PHY
"socionext,uniphier-pxs3-pcie-phy" - for PXs3 PHY
- reg: Specifies offset and length of the register set for the device.
- #phy-cells: Must be zero.
- clocks: A phandle to the clock gate for PCIe glue layer including
this phy.
- resets: A phandle to the reset line for PCIe glue layer including
this phy.
- clocks: A list of phandles to the clock gate for PCIe glue layer
including this phy.
- clock-names: For Pro5 only, should contain the following:
"gio", "link" - for Pro5 SoC
- resets: A list of phandles to the reset line for PCIe glue layer
including this phy.
- reset-names: For Pro5 only, should contain the following:
"gio", "link" - for Pro5 SoC
Optional properties:
- socionext,syscon: A phandle to system control to set configurations

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