leandrof/linux
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

Merge branch 'for-5.17/core' into for-linus

Browse Source 
- support for USI style pens (Tero Kristo, Mika Westerberg)
- quirk for devices that need inverted X/Y axes (Alistair Francis)
- small core code cleanups and deduplication (Benjamin Tissoires)
This commit is contained in:
Jiri Kosina
2022-01-10 09:49:13 +01:00
parent 3809fe4798 b60d3c803d
commit 8a2094d679
3151 changed files with 90760 additions and 50224 deletions
Download Patch File Download Diff File Expand all files Collapse all files

5
.mailmap
View File

@@ -71,8 +71,13 @@ Chao Yu <chao@kernel.org> <chao2.yu@samsung.com>
Chao Yu <chao@kernel.org> <yuchao0@huawei.com> Chao Yu <chao@kernel.org> <yuchao0@huawei.com>
Chris Chiu <chris.chiu@canonical.com> <chiu@endlessm.com> Chris Chiu <chris.chiu@canonical.com> <chiu@endlessm.com>
Chris Chiu <chris.chiu@canonical.com> <chiu@endlessos.org> Chris Chiu <chris.chiu@canonical.com> <chiu@endlessos.org>
Christian Borntraeger <borntraeger@linux.ibm.com> <borntraeger@de.ibm.com>
Christian Borntraeger <borntraeger@linux.ibm.com> <cborntra@de.ibm.com>
Christian Borntraeger <borntraeger@linux.ibm.com> <borntrae@de.ibm.com>
Christophe Ricard <christophe.ricard@gmail.com> Christophe Ricard <christophe.ricard@gmail.com>
Christoph Hellwig <hch@lst.de> Christoph Hellwig <hch@lst.de>
Colin Ian King <colin.king@intel.com> <colin.king@canonical.com>
Colin Ian King <colin.king@intel.com> <colin.i.king@gmail.com>
Corey Minyard <minyard@acm.org> Corey Minyard <minyard@acm.org>
Damian Hobson-Garcia <dhobsong@igel.co.jp> Damian Hobson-Garcia <dhobsong@igel.co.jp>
Daniel Borkmann <daniel@iogearbox.net> <danborkmann@googlemail.com> Daniel Borkmann <daniel@iogearbox.net> <danborkmann@googlemail.com>

11
Documentation/ABI/testing/sysfs-bus-pci
View File

@@ -100,6 +100,17 @@ Description:
This attribute indicates the mode that the irq vector named by This attribute indicates the mode that the irq vector named by
the file is in (msi vs. msix) the file is in (msi vs. msix)
What: /sys/bus/pci/devices/.../irq
Date: August 2021
Contact: Linux PCI developers <linux-pci@vger.kernel.org>
Description:
If a driver has enabled MSI (not MSI-X), "irq" contains the
IRQ of the first MSI vector. Otherwise "irq" contains the
IRQ of the legacy INTx interrupt.
"irq" being set to 0 indicates that the device isn't
capable of generating legacy INTx interrupts.
What: /sys/bus/pci/devices/.../remove What: /sys/bus/pci/devices/.../remove
Date: January 2009 Date: January 2009
Contact: Linux PCI developers <linux-pci@vger.kernel.org> Contact: Linux PCI developers <linux-pci@vger.kernel.org>

27
Documentation/ABI/testing/sysfs-class-fc Normal file
View File

@@ -0,0 +1,27 @@
What: /sys/class/fc/fc_udev_device/appid_store
Date: Aug 2021
Contact: Muneendra Kumar <muneendra.kumar@broadconm.com>
Description:
This interface allows an admin to set an FC application
identifier in the blkcg associated with a cgroup id. The
identifier is typically a UUID that is associated with
an application or logical entity such as a virtual
machine or container group. The application or logical
entity utilizes a block device via the cgroup id.
FC adapter drivers may query the identifier and tag FC
traffic based on the identifier. FC host and FC fabric
entities can utilize the application id and FC traffic
tag to identify traffic sources.
The interface expects a string "<cgroupid>:<appid>" where:
<cgroupid> is inode of the cgroup in hexadecimal
<appid> is user provided string upto 128 characters
in length.
If an appid_store is done for a cgroup id that already
has an appid set, the new value will override the
previous value.
If an admin wants to remove an FC application identifier
from a cgroup, an appid_store should be done with the
following string: "<cgroupid>:"

2
Documentation/ABI/testing/sysfs-driver-ufs
View File

@@ -983,7 +983,7 @@ Description: This file shows the amount of data that the host plans to
What: /sys/class/scsi_device/*/device/dyn_cap_needed What: /sys/class/scsi_device/*/device/dyn_cap_needed
Date: February 2018 Date: February 2018
Contact: Stanislav Nijnikov <stanislav.nijnikov@wdc.com> Contact: Stanislav Nijnikov <stanislav.nijnikov@wdc.com>
Description: This file shows the The amount of physical memory needed Description: This file shows the amount of physical memory needed
to be removed from the physical memory resources pool of to be removed from the physical memory resources pool of
the particular logical unit. The full information about the particular logical unit. The full information about
the attribute could be found at UFS specifications 2.1. the attribute could be found at UFS specifications 2.1.

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

@@ -512,3 +512,19 @@ Date: July 2021
Contact: "Daeho Jeong" <daehojeong@google.com> Contact: "Daeho Jeong" <daehojeong@google.com>
Description: You can control the multiplier value of bdi device readahead window size Description: You can control the multiplier value of bdi device readahead window size
between 2 (default) and 256 for POSIX_FADV_SEQUENTIAL advise option. between 2 (default) and 256 for POSIX_FADV_SEQUENTIAL advise option.
What: /sys/fs/f2fs/<disk>/max_fragment_chunk
Date: August 2021
Contact: "Daeho Jeong" <daehojeong@google.com>
Description: With "mode=fragment:block" mount options, we can scatter block allocation.
f2fs will allocate 1..<max_fragment_chunk> blocks in a chunk and make a hole
in the length of 1..<max_fragment_hole> by turns. This value can be set
between 1..512 and the default value is 4.
What: /sys/fs/f2fs/<disk>/max_fragment_hole
Date: August 2021
Contact: "Daeho Jeong" <daehojeong@google.com>
Description: With "mode=fragment:block" mount options, we can scatter block allocation.
f2fs will allocate 1..<max_fragment_chunk> blocks in a chunk and make a hole
in the length of 1..<max_fragment_hole> by turns. This value can be set
between 1..512 and the default value is 4.

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

@@ -328,6 +328,14 @@ as idle::
From now on, any pages on zram are idle pages. The idle mark From now on, any pages on zram are idle pages. The idle mark
will be removed until someone requests access of the block. will be removed until someone requests access of the block.
IOW, unless there is access request, those pages are still idle pages. IOW, unless there is access request, those pages are still idle pages.
Additionally, when CONFIG_ZRAM_MEMORY_TRACKING is enabled pages can be
marked as idle based on how long (in seconds) it's been since they were
last accessed::
echo 86400 > /sys/block/zramX/idle
In this example all pages which haven't been accessed in more than 86400
seconds (one day) will be marked idle.
Admin can request writeback of those idle pages at right timing via:: Admin can request writeback of those idle pages at right timing via::

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

@@ -87,10 +87,8 @@ Brief summary of control files.
memory.oom_control set/show oom controls. memory.oom_control set/show oom controls.
memory.numa_stat show the number of memory usage per numa memory.numa_stat show the number of memory usage per numa
node node
memory.kmem.limit_in_bytes set/show hard limit for kernel memory memory.kmem.limit_in_bytes This knob is deprecated and writing to
This knob is deprecated and shouldn't be it will return -ENOTSUPP.
used. It is planned that this be removed in
the foreseeable future.
memory.kmem.usage_in_bytes show current kernel memory allocation memory.kmem.usage_in_bytes show current kernel memory allocation
memory.kmem.failcnt show the number of kernel memory usage memory.kmem.failcnt show the number of kernel memory usage
hits limits hits limits
@@ -518,11 +516,6 @@ will be charged as a new owner of it.
charged file caches. Some out-of-use page caches may keep charged until charged file caches. Some out-of-use page caches may keep charged until
memory pressure happens. If you want to avoid that, force_empty will be useful. memory pressure happens. If you want to avoid that, force_empty will be useful.
Also, note that when memory.kmem.limit_in_bytes is set the charges due to
kernel pages will still be seen. This is not considered a failure and the
write will still return success. In this case, it is expected that
memory.kmem.usage_in_bytes == memory.usage_in_bytes.
5.2 stat file 5.2 stat file
------------- -------------

78
Documentation/admin-guide/filesystem-monitoring.rst Normal file
View File

@@ -0,0 +1,78 @@
.. SPDX-License-Identifier: GPL-2.0
====================================
File system Monitoring with fanotify
====================================
File system Error Reporting
===========================
Fanotify supports the FAN_FS_ERROR event type for file system-wide error
reporting. It is meant to be used by file system health monitoring
daemons, which listen for these events and take actions (notify
sysadmin, start recovery) when a file system problem is detected.
By design, a FAN_FS_ERROR notification exposes sufficient information
for a monitoring tool to know a problem in the file system has happened.
It doesn't necessarily provide a user space application with semantics
to verify an IO operation was successfully executed. That is out of
scope for this feature. Instead, it is only meant as a framework for
early file system problem detection and reporting recovery tools.
When a file system operation fails, it is common for dozens of kernel
errors to cascade after the initial failure, hiding the original failure
log, which is usually the most useful debug data to troubleshoot the
problem. For this reason, FAN_FS_ERROR tries to report only the first
error that occurred for a file system since the last notification, and
it simply counts additional errors. This ensures that the most
important pieces of information are never lost.
FAN_FS_ERROR requires the fanotify group to be setup with the
FAN_REPORT_FID flag.
At the time of this writing, the only file system that emits FAN_FS_ERROR
notifications is Ext4.
A FAN_FS_ERROR Notification has the following format::
::
[ Notification Metadata (Mandatory) ]
[ Generic Error Record (Mandatory) ]
[ FID record (Mandatory) ]
The order of records is not guaranteed, and new records might be added
in the future. Therefore, applications must not rely on the order and
must be prepared to skip over unknown records. Please refer to
``samples/fanotify/fs-monitor.c`` for an example parser.
Generic error record
--------------------
The generic error record provides enough information for a file system
agnostic tool to learn about a problem in the file system, without
providing any additional details about the problem. This record is
identified by ``struct fanotify_event_info_header.info_type`` being set
to FAN_EVENT_INFO_TYPE_ERROR.
::
struct fanotify_event_info_error {
struct fanotify_event_info_header hdr;
__s32 error;
__u32 error_count;
};
The `error` field identifies the type of error using errno values.
`error_count` tracks the number of errors that occurred and were
suppressed to preserve the original error information, since the last
notification.
FID record
----------
The FID record can be used to uniquely identify the inode that triggered
the error through the combination of fsid and file handle. A file system
specific application can use that information to attempt a recovery
procedure. Errors that are not related to an inode are reported with an
empty file handle of type FILEID_INVALID.

5
Documentation/admin-guide/hw-vuln/core-scheduling.rst
View File

@@ -61,8 +61,9 @@ arg3:
``pid`` of the task for which the operation applies. ``pid`` of the task for which the operation applies.
arg4: arg4:
``pid_type`` for which the operation applies. It is of type ``enum pid_type``. ``pid_type`` for which the operation applies. It is one of
For example, if arg4 is ``PIDTYPE_TGID``, then the operation of this command ``PR_SCHED_CORE_SCOPE_``-prefixed macro constants. For example, if arg4
is ``PR_SCHED_CORE_SCOPE_THREAD_GROUP``, then the operation of this command
will be performed for all tasks in the task group of ``pid``. will be performed for all tasks in the task group of ``pid``.
arg5: arg5:

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

@@ -82,6 +82,7 @@ configure specific aspects of kernel behavior to your liking.
edid edid
efi-stub efi-stub
ext4 ext4
filesystem-monitoring
nfs/index nfs/index
gpio/index gpio/index
highuid highuid

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

@@ -1582,8 +1582,10 @@
registers. Default set by CONFIG_HPET_MMAP_DEFAULT. registers. Default set by CONFIG_HPET_MMAP_DEFAULT.
hugetlb_cma= [HW,CMA] The size of a CMA area used for allocation hugetlb_cma= [HW,CMA] The size of a CMA area used for allocation
of gigantic hugepages. of gigantic hugepages. Or using node format, the size
Format: nn[KMGTPE] of a CMA area per node can be specified.
Format: nn[KMGTPE] or (node format)
<node>:nn[KMGTPE][,<node>:nn[KMGTPE]]
Reserve a CMA area of given size and allocate gigantic Reserve a CMA area of given size and allocate gigantic
hugepages using the CMA allocator. If enabled, the hugepages using the CMA allocator. If enabled, the
@@ -1594,9 +1596,11 @@
the number of pages of hugepagesz to be allocated. the number of pages of hugepagesz to be allocated.
If this is the first HugeTLB parameter on the command If this is the first HugeTLB parameter on the command
line, it specifies the number of pages to allocate for line, it specifies the number of pages to allocate for
the default huge page size. See also the default huge page size. If using node format, the
Documentation/admin-guide/mm/hugetlbpage.rst. number of pages to allocate per-node can be specified.
Format: <integer> See also Documentation/admin-guide/mm/hugetlbpage.rst.
Format: <integer> or (node format)
<node>:<integer>[,<node>:<integer>]
hugepagesz= hugepagesz=
[HW] The size of the HugeTLB pages. This is used in [HW] The size of the HugeTLB pages. This is used in
@@ -3249,6 +3253,19 @@
driver. A non-zero value sets the minimum interval driver. A non-zero value sets the minimum interval
in seconds between layoutstats transmissions. in seconds between layoutstats transmissions.
nfsd.inter_copy_offload_enable =
[NFSv4.2] When set to 1, the server will support
server-to-server copies for which this server is
the destination of the copy.
nfsd.nfsd4_ssc_umount_timeout =
[NFSv4.2] When used as the destination of a
server-to-server copy, knfsd temporarily mounts
the source server. It caches the mount in case
it will be needed again, and discards it if not
used for the number of milliseconds specified by
this parameter.
nfsd.nfs4_disable_idmapping= nfsd.nfs4_disable_idmapping=
[NFSv4] When set to the default of '1', the NFSv4 [NFSv4] When set to the default of '1', the NFSv4
server will return only numeric uids and gids to server will return only numeric uids and gids to
@@ -3256,6 +3273,7 @@
and gids from such clients. This is intended to ease and gids from such clients. This is intended to ease
migration from NFSv2/v3. migration from NFSv2/v3.
nmi_backtrace.backtrace_idle [KNL] nmi_backtrace.backtrace_idle [KNL]
Dump stacks even of idle CPUs in response to an Dump stacks even of idle CPUs in response to an
NMI stack-backtrace request. NMI stack-backtrace request.
@@ -4988,6 +5006,18 @@
an IOTLB flush. Default is lazy flushing before reuse, an IOTLB flush. Default is lazy flushing before reuse,
which is faster. which is faster.
s390_iommu_aperture= [KNL,S390]
Specifies the size of the per device DMA address space
accessible through the DMA and IOMMU APIs as a decimal
factor of the size of main memory.
The default is 1 meaning that one can concurrently use
as many DMA addresses as physical memory is installed,
if supported by hardware, and thus map all of memory
once. With a value of 2 one can map all of memory twice
and so on. As a special case a factor of 0 imposes no
restrictions other than those given by hardware at the
cost of significant additional memory use for tables.
sa1100ir [NET] sa1100ir [NET]
See drivers/net/irda/sa1100_ir.c. See drivers/net/irda/sa1100_ir.c.
@@ -6363,6 +6393,13 @@
improve timer resolution at the expense of processing improve timer resolution at the expense of processing
more timer interrupts. more timer interrupts.
xen.balloon_boot_timeout= [XEN]
The time (in seconds) to wait before giving up to boot
in case initial ballooning fails to free enough memory.
Applies only when running as HVM or PVH guest and
started with less memory configured than allowed at
max. Default is 180.
xen.event_eoi_delay= [XEN] xen.event_eoi_delay= [XEN]
How long to delay EOI handling in case of event How long to delay EOI handling in case of event
storms (jiffies). Default is 10. storms (jiffies). Default is 10.

12
Documentation/admin-guide/laptops/thinkpad-acpi.rst
View File

@@ -1520,15 +1520,15 @@ This sysfs attribute controls the keyboard "face" that will be shown on the
Lenovo X1 Carbon 2nd gen (2014)'s adaptive keyboard. The value can be read Lenovo X1 Carbon 2nd gen (2014)'s adaptive keyboard. The value can be read
and set. and set.
- 1 = Home mode - 0 = Home mode
- 2 = Web-browser mode - 1 = Web-browser mode
- 3 = Web-conference mode - 2 = Web-conference mode
- 4 = Function mode - 3 = Function mode
- 5 = Layflat mode - 4 = Layflat mode
For more details about which buttons will appear depending on the mode, please For more details about which buttons will appear depending on the mode, please
review the laptop's user guide: review the laptop's user guide:
http://www.lenovo.com/shop/americas/content/user_guides/x1carbon_2_ug_en.pdf https://download.lenovo.com/ibmdl/pub/pc/pccbbs/mobiles_pdf/x1carbon_2_ug_en.pdf
Battery charge control Battery charge control
---------------------- ----------------------

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

@@ -13,3 +13,4 @@ optimize those.
start start
usage usage
reclaim

235
Documentation/admin-guide/mm/damon/reclaim.rst Normal file
View File

@@ -0,0 +1,235 @@
.. SPDX-License-Identifier: GPL-2.0
=======================
DAMON-based Reclamation
=======================
DAMON-based Reclamation (DAMON_RECLAIM) is a static kernel module that aimed to
be used for proactive and lightweight reclamation under light memory pressure.
It doesn't aim to replace the LRU-list based page_granularity reclamation, but
to be selectively used for different level of memory pressure and requirements.
Where Proactive Reclamation is Required?
========================================
On general memory over-committed systems, proactively reclaiming cold pages
helps saving memory and reducing latency spikes that incurred by the direct
reclaim of the process or CPU consumption of kswapd, while incurring only
minimal performance degradation [1]_ [2]_ .
Free Pages Reporting [3]_ based memory over-commit virtualization systems are
good example of the cases. In such systems, the guest VMs reports their free
memory to host, and the host reallocates the reported memory to other guests.
As a result, the memory of the systems are fully utilized. However, the
guests could be not so memory-frugal, mainly because some kernel subsystems and
user-space applications are designed to use as much memory as available. Then,
guests could report only small amount of memory as free to host, results in
memory utilization drop of the systems. Running the proactive reclamation in
guests could mitigate this problem.
How It Works?
=============
DAMON_RECLAIM finds memory regions that didn't accessed for specific time
duration and page out. To avoid it consuming too much CPU for the paging out
operation, a speed limit can be configured. Under the speed limit, it pages
out memory regions that didn't accessed longer time first. System
administrators can also configure under what situation this scheme should
automatically activated and deactivated with three memory pressure watermarks.
Interface: Module Parameters
============================
To use this feature, you should first ensure your system is running on a kernel
that is built with ``CONFIG_DAMON_RECLAIM=y``.
To let sysadmins enable or disable it and tune for the given system,
DAMON_RECLAIM utilizes module parameters. That is, you can put
``damon_reclaim.<parameter>=<value>`` on the kernel boot command line or write
proper values to ``/sys/modules/damon_reclaim/parameters/<parameter>`` files.
Note that the parameter values except ``enabled`` are applied only when
DAMON_RECLAIM starts. Therefore, if you want to apply new parameter values in
runtime and DAMON_RECLAIM is already enabled, you should disable and re-enable
it via ``enabled`` parameter file. Writing of the new values to proper
parameter values should be done before the re-enablement.
Below are the description of each parameter.
enabled
-------
Enable or disable DAMON_RECLAIM.
You can enable DAMON_RCLAIM by setting the value of this parameter as ``Y``.
Setting it as ``N`` disables DAMON_RECLAIM. Note that DAMON_RECLAIM could do
no real monitoring and reclamation due to the watermarks-based activation
condition. Refer to below descriptions for the watermarks parameter for this.
min_age
-------
Time threshold for cold memory regions identification in microseconds.
If a memory region is not accessed for this or longer time, DAMON_RECLAIM
identifies the region as cold, and reclaims it.
120 seconds by default.
quota_ms
--------
Limit of time for the reclamation in milliseconds.
DAMON_RECLAIM tries to use only up to this time within a time window
(quota_reset_interval_ms) for trying reclamation of cold pages. This can be
used for limiting CPU consumption of DAMON_RECLAIM. If the value is zero, the
limit is disabled.
10 ms by default.
quota_sz
--------
Limit of size of memory for the reclamation in bytes.
DAMON_RECLAIM charges amount of memory which it tried to reclaim within a time
window (quota_reset_interval_ms) and makes no more than this limit is tried.
This can be used for limiting consumption of CPU and IO. If this value is
zero, the limit is disabled.
128 MiB by default.
quota_reset_interval_ms
-----------------------
The time/size quota charge reset interval in milliseconds.
The charget reset interval for the quota of time (quota_ms) and size
(quota_sz). That is, DAMON_RECLAIM does not try reclamation for more than
quota_ms milliseconds or quota_sz bytes within quota_reset_interval_ms
milliseconds.
1 second by default.
wmarks_interval
---------------
Minimal time to wait before checking the watermarks, when DAMON_RECLAIM is
enabled but inactive due to its watermarks rule.
wmarks_high
-----------
Free memory rate (per thousand) for the high watermark.
If free memory of the system in bytes per thousand bytes is higher than this,
DAMON_RECLAIM becomes inactive, so it does nothing but only periodically checks
the watermarks.
wmarks_mid
----------
Free memory rate (per thousand) for the middle watermark.
If free memory of the system in bytes per thousand bytes is between this and
the low watermark, DAMON_RECLAIM becomes active, so starts the monitoring and
the reclaiming.
wmarks_low
----------
Free memory rate (per thousand) for the low watermark.
If free memory of the system in bytes per thousand bytes is lower than this,
DAMON_RECLAIM becomes inactive, so it does nothing but periodically checks the
watermarks. In the case, the system falls back to the LRU-list based page
granularity reclamation logic.
sample_interval
---------------
Sampling interval for the monitoring in microseconds.
The sampling interval of DAMON for the cold memory monitoring. Please refer to
the DAMON documentation (:doc:`usage`) for more detail.
aggr_interval
-------------
Aggregation interval for the monitoring in microseconds.
The aggregation interval of DAMON for the cold memory monitoring. Please
refer to the DAMON documentation (:doc:`usage`) for more detail.
min_nr_regions
--------------
Minimum number of monitoring regions.
The minimal number of monitoring regions of DAMON for the cold memory
monitoring. This can be used to set lower-bound of the monitoring quality.
But, setting this too high could result in increased monitoring overhead.
Please refer to the DAMON documentation (:doc:`usage`) for more detail.
max_nr_regions
--------------
Maximum number of monitoring regions.
The maximum number of monitoring regions of DAMON for the cold memory
monitoring. This can be used to set upper-bound of the monitoring overhead.
However, setting this too low could result in bad monitoring quality. Please
refer to the DAMON documentation (:doc:`usage`) for more detail.
monitor_region_start
--------------------
Start of target memory region in physical address.
The start physical address of memory region that DAMON_RECLAIM will do work
against. That is, DAMON_RECLAIM will find cold memory regions in this region
and reclaims. By default, biggest System RAM is used as the region.
monitor_region_end
------------------
End of target memory region in physical address.
The end physical address of memory region that DAMON_RECLAIM will do work
against. That is, DAMON_RECLAIM will find cold memory regions in this region
and reclaims. By default, biggest System RAM is used as the region.
kdamond_pid
-----------
PID of the DAMON thread.
If DAMON_RECLAIM is enabled, this becomes the PID of the worker thread. Else,
-1.
Example
=======
Below runtime example commands make DAMON_RECLAIM to find memory regions that
not accessed for 30 seconds or more and pages out. The reclamation is limited
to be done only up to 1 GiB per second to avoid DAMON_RECLAIM consuming too
much CPU time for the paging out operation. It also asks DAMON_RECLAIM to do
nothing if the system's free memory rate is more than 50%, but start the real
works if it becomes lower than 40%. If DAMON_RECLAIM doesn't make progress and
therefore the free memory rate becomes lower than 20%, it asks DAMON_RECLAIM to
do nothing again, so that we can fall back to the LRU-list based page
granularity reclamation. ::
# cd /sys/modules/damon_reclaim/parameters
# echo 30000000 > min_age
# echo $((1 * 1024 * 1024 * 1024)) > quota_sz
# echo 1000 > quota_reset_interval_ms
# echo 500 > wmarks_high
# echo 400 > wmarks_mid
# echo 200 > wmarks_low
# echo Y > enabled
.. [1] https://research.google/pubs/pub48551/
.. [2] https://lwn.net/Articles/787611/
.. [3] https://www.kernel.org/doc/html/latest/vm/free_page_reporting.html

120
Documentation/admin-guide/mm/damon/start.rst
View File

@@ -6,39 +6,9 @@ Getting Started
This document briefly describes how you can use DAMON by demonstrating its This document briefly describes how you can use DAMON by demonstrating its
default user space tool. Please note that this document describes only a part default user space tool. Please note that this document describes only a part
of its features for brevity. Please refer to :doc:`usage` for more details. of its features for brevity. Please refer to the usage `doc
<https://github.com/awslabs/damo/blob/next/USAGE.md>`_ of the tool for more
details.
TL; DR
======
Follow the commands below to monitor and visualize the memory access pattern of
your workload. ::
# # build the kernel with CONFIG_DAMON_*=y, install it, and reboot
# mount -t debugfs none /sys/kernel/debug/
# git clone https://github.com/awslabs/damo
# ./damo/damo record $(pidof <your workload>)
# ./damo/damo report heat --plot_ascii
The final command draws the access heatmap of ``<your workload>``. The heatmap
shows which memory region (x-axis) is accessed when (y-axis) and how frequently
(number; the higher the more accesses have been observed). ::
111111111111111111111111111111111111111111111111111111110000
111121111111111111111111111111211111111111111111111111110000
000000000000000000000000000000000000000000000000001555552000
000000000000000000000000000000000000000000000222223555552000
000000000000000000000000000000000000000011111677775000000000
000000000000000000000000000000000000000488888000000000000000
000000000000000000000000000000000177888400000000000000000000
000000000000000000000000000046666522222100000000000000000000
000000000000000000000014444344444300000000000000000000000000
000000000000000002222245555510000000000000000000000000000000
# access_frequency: 0 1 2 3 4 5 6 7 8 9
# x-axis: space (140286319947776-140286426374096: 101.496 MiB)
# y-axis: time (605442256436361-605479951866441: 37.695430s)
# resolution: 60x10 (1.692 MiB and 3.770s for each character)
Prerequisites Prerequisites
@@ -91,24 +61,74 @@ pattern in the ``damon.data`` file.
Visualizing Recorded Patterns Visualizing Recorded Patterns
============================= =============================
The following three commands visualize the recorded access patterns and save You can visualize the pattern in a heatmap, showing which memory region
the results as separate image files. :: (x-axis) got accessed when (y-axis) and how frequently (number).::
$ damo report heats --heatmap access_pattern_heatmap.png $ sudo damo report heats --heatmap stdout
$ damo report wss --range 0 101 1 --plot wss_dist.png 22222222222222222222222222222222222222211111111111111111111111111111111111111100
$ damo report wss --range 0 101 1 --sortby time --plot wss_chron_change.png 44444444444444444444444444444444444444434444444444444444444444444444444444443200
44444444444444444444444444444444444444433444444444444444444444444444444444444200
33333333333333333333333333333333333333344555555555555555555555555555555555555200
33333333333333333333333333333333333344444444444444444444444444444444444444444200
22222222222222222222222222222222222223355555555555555555555555555555555555555200
00000000000000000000000000000000000000288888888888888888888888888888888888888400
00000000000000000000000000000000000000288888888888888888888888888888888888888400
33333333333333333333333333333333333333355555555555555555555555555555555555555200
88888888888888888888888888888888888888600000000000000000000000000000000000000000
88888888888888888888888888888888888888600000000000000000000000000000000000000000
33333333333333333333333333333333333333444444444444444444444444444444444444443200
00000000000000000000000000000000000000288888888888888888888888888888888888888400
[...]
# access_frequency: 0 1 2 3 4 5 6 7 8 9
# x-axis: space (139728247021568-139728453431248: 196.848 MiB)
# y-axis: time (15256597248362-15326899978162: 1 m 10.303 s)
# resolution: 80x40 (2.461 MiB and 1.758 s for each character)
- ``access_pattern_heatmap.png`` will visualize the data access pattern in a You can also visualize the distribution of the working set size, sorted by the
heatmap, showing which memory region (y-axis) got accessed when (x-axis) size.::
and how frequently (color).
- ``wss_dist.png`` will show the distribution of the working set size.
- ``wss_chron_change.png`` will show how the working set size has
chronologically changed.
You can view the visualizations of this example workload at [1]_. $ sudo damo report wss --range 0 101 10
Visualizations of other realistic workloads are available at [2]_ [3]_ [4]_. # <percentile> <wss>
# target_id 18446632103789443072
# avr: 107.708 MiB
0 0 B | |
10 95.328 MiB |**************************** |
20 95.332 MiB |**************************** |
30 95.340 MiB |**************************** |
40 95.387 MiB |**************************** |
50 95.387 MiB |**************************** |
60 95.398 MiB |**************************** |
70 95.398 MiB |**************************** |
80 95.504 MiB |**************************** |
90 190.703 MiB |********************************************************* |
100 196.875 MiB |***********************************************************|
.. [1] https://damonitor.github.io/doc/html/v17/admin-guide/mm/damon/start.html#visualizing-recorded-patterns Using ``--sortby`` option with the above command, you can show how the working
.. [2] https://damonitor.github.io/test/result/visual/latest/rec.heatmap.1.png.html set size has chronologically changed.::
.. [3] https://damonitor.github.io/test/result/visual/latest/rec.wss_sz.png.html
.. [4] https://damonitor.github.io/test/result/visual/latest/rec.wss_time.png.html $ sudo damo report wss --range 0 101 10 --sortby time
# <percentile> <wss>
# target_id 18446632103789443072
# avr: 107.708 MiB
0 3.051 MiB | |
10 190.703 MiB |***********************************************************|
20 95.336 MiB |***************************** |
30 95.328 MiB |***************************** |
40 95.387 MiB |***************************** |
50 95.332 MiB |***************************** |
60 95.320 MiB |***************************** |
70 95.398 MiB |***************************** |
80 95.398 MiB |***************************** |
90 95.340 MiB |***************************** |
100 95.398 MiB |***************************** |
Data Access Pattern Aware Memory Management
===========================================
Below three commands make every memory region of size >=4K that doesn't
accessed for >=60 seconds in your workload to be swapped out. ::
$ echo "#min-size max-size min-acc max-acc min-age max-age action" > test_scheme
$ echo "4K max 0 0 60s max pageout" >> test_scheme
$ damo schemes -c test_scheme <pid of your workload>

109
Documentation/admin-guide/mm/damon/usage.rst
View File

@@ -10,15 +10,16 @@ DAMON provides below three interfaces for different users.
This is for privileged people such as system administrators who want a This is for privileged people such as system administrators who want a
just-working human-friendly interface. Using this, users can use the DAMON’s just-working human-friendly interface. Using this, users can use the DAMON’s
major features in a human-friendly way. It may not be highly tuned for major features in a human-friendly way. It may not be highly tuned for
special cases, though. It supports only virtual address spaces monitoring. special cases, though. It supports both virtual and physical address spaces
monitoring.
- *debugfs interface.* - *debugfs interface.*
This is for privileged user space programmers who want more optimized use of This is for privileged user space programmers who want more optimized use of
DAMON. Using this, users can use DAMON’s major features by reading DAMON. Using this, users can use DAMON’s major features by reading
from and writing to special debugfs files. Therefore, you can write and use from and writing to special debugfs files. Therefore, you can write and use
your personalized DAMON debugfs wrapper programs that reads/writes the your personalized DAMON debugfs wrapper programs that reads/writes the
debugfs files instead of you. The DAMON user space tool is also a reference debugfs files instead of you. The DAMON user space tool is also a reference
implementation of such programs. It supports only virtual address spaces implementation of such programs. It supports both virtual and physical
monitoring. address spaces monitoring.
- *Kernel Space Programming Interface.* - *Kernel Space Programming Interface.*
This is for kernel space programmers. Using this, users can utilize every This is for kernel space programmers. Using this, users can utilize every
feature of DAMON most flexibly and efficiently by writing kernel space feature of DAMON most flexibly and efficiently by writing kernel space
@@ -34,8 +35,9 @@ the reason, this document describes only the debugfs interface
debugfs Interface debugfs Interface
================= =================
DAMON exports three files, ``attrs``, ``target_ids``, and ``monitor_on`` under DAMON exports five files, ``attrs``, ``target_ids``, ``init_regions``,
its debugfs directory, ``<debugfs>/damon/``. ``schemes`` and ``monitor_on`` under its debugfs directory,
``<debugfs>/damon/``.
Attributes Attributes
@@ -71,9 +73,106 @@ check it again::
# cat target_ids # cat target_ids
42 4242 42 4242
Users can also monitor the physical memory address space of the system by
writing a special keyword, "``paddr\n``" to the file. Because physical address
space monitoring doesn't support multiple targets, reading the file will show a
fake value, ``42``, as below::
# cd <debugfs>/damon
# echo paddr > target_ids
# cat target_ids
42
Note that setting the target ids doesn't start the monitoring. Note that setting the target ids doesn't start the monitoring.
Initial Monitoring Target Regions
---------------------------------
In case of the virtual address space monitoring, DAMON automatically sets and
updates the monitoring target regions so that entire memory mappings of target
processes can be covered. However, users can want to limit the monitoring
region to specific address ranges, such as the heap, the stack, or specific
file-mapped area. Or, some users can know the initial access pattern of their
workloads and therefore want to set optimal initial regions for the 'adaptive
regions adjustment'.
In contrast, DAMON do not automatically sets and updates the monitoring target
regions in case of physical memory monitoring. Therefore, users should set the
monitoring target regions by themselves.
In such cases, users can explicitly set the initial monitoring target regions
as they want, by writing proper values to the ``init_regions`` file. Each line
of the input should represent one region in below form.::
<target id> <start address> <end address>
The ``target id`` should already in ``target_ids`` file, and the regions should
be passed in address order. For example, below commands will set a couple of
address ranges, ``1-100`` and ``100-200`` as the initial monitoring target
region of process 42, and another couple of address ranges, ``20-40`` and
``50-100`` as that of process 4242.::
# cd <debugfs>/damon
# echo "42 1 100
42 100 200
4242 20 40
4242 50 100" > init_regions
Note that this sets the initial monitoring target regions only. In case of
virtual memory monitoring, DAMON will automatically updates the boundary of the
regions after one ``regions update interval``. Therefore, users should set the
``regions update interval`` large enough in this case, if they don't want the
update.
Schemes
-------
For usual DAMON-based data access aware memory management optimizations, users
would simply want the system to apply a memory management action to a memory
region of a specific size having a specific access frequency for a specific
time. DAMON receives such formalized operation schemes from the user and
applies those to the target processes. It also counts the total number and
size of regions that each scheme is applied. This statistics can be used for
online analysis or tuning of the schemes.
Users can get and set the schemes by reading from and writing to ``schemes``
debugfs file. Reading the file also shows the statistics of each scheme. To
the file, each of the schemes should be represented in each line in below form:
min-size max-size min-acc max-acc min-age max-age action
Note that the ranges are closed interval. Bytes for the size of regions
(``min-size`` and ``max-size``), number of monitored accesses per aggregate
interval for access frequency (``min-acc`` and ``max-acc``), number of
aggregate intervals for the age of regions (``min-age`` and ``max-age``), and a
predefined integer for memory management actions should be used. The supported
numbers and their meanings are as below.
- 0: Call ``madvise()`` for the region with ``MADV_WILLNEED``
- 1: Call ``madvise()`` for the region with ``MADV_COLD``
- 2: Call ``madvise()`` for the region with ``MADV_PAGEOUT``
- 3: Call ``madvise()`` for the region with ``MADV_HUGEPAGE``
- 4: Call ``madvise()`` for the region with ``MADV_NOHUGEPAGE``
- 5: Do nothing but count the statistics
You can disable schemes by simply writing an empty string to the file. For
example, below commands applies a scheme saying "If a memory region of size in
[4KiB, 8KiB] is showing accesses per aggregate interval in [0, 5] for aggregate
interval in [10, 20], page out the region", check the entered scheme again, and
finally remove the scheme. ::
# cd <debugfs>/damon
# echo "4096 8192 0 5 10 20 2" > schemes
# cat schemes
4096 8192 0 5 10 20 2 0 0
# echo > schemes
The last two integers in the 4th line of above example is the total number and
the total size of the regions that the scheme is applied.
Turning On/Off Turning On/Off
-------------- --------------

42
Documentation/admin-guide/mm/hugetlbpage.rst
View File

@@ -128,7 +128,9 @@ hugepages
implicitly specifies the number of huge pages of default size to implicitly specifies the number of huge pages of default size to
allocate. If the number of huge pages of default size is implicitly allocate. If the number of huge pages of default size is implicitly
specified, it can not be overwritten by a hugepagesz,hugepages specified, it can not be overwritten by a hugepagesz,hugepages
parameter pair for the default size. parameter pair for the default size. This parameter also has a
node format. The node format specifies the number of huge pages
to allocate on specific nodes.
For example, on an architecture with 2M default huge page size:: For example, on an architecture with 2M default huge page size::
@@ -138,6 +140,14 @@ hugepages
indicating that the hugepages=512 parameter is ignored. If a hugepages indicating that the hugepages=512 parameter is ignored. If a hugepages
parameter is preceded by an invalid hugepagesz parameter, it will parameter is preceded by an invalid hugepagesz parameter, it will
be ignored. be ignored.
Node format example::
hugepagesz=2M hugepages=0:1,1:2
It will allocate 1 2M hugepage on node0 and 2 2M hugepages on node1.
If the node number is invalid, the parameter will be ignored.
default_hugepagesz default_hugepagesz
Specify the default huge page size. This parameter can Specify the default huge page size. This parameter can
only be specified once on the command line. default_hugepagesz can only be specified once on the command line. default_hugepagesz can
@@ -234,8 +244,12 @@ will exist, of the form::
hugepages-${size}kB hugepages-${size}kB
Inside each of these directories, the same set of files will exist:: Inside each of these directories, the set of files contained in ``/proc``
will exist. In addition, two additional interfaces for demoting huge
pages may exist::
demote
demote_size
nr_hugepages nr_hugepages
nr_hugepages_mempolicy nr_hugepages_mempolicy
nr_overcommit_hugepages nr_overcommit_hugepages
@@ -243,7 +257,29 @@ Inside each of these directories, the same set of files will exist::
resv_hugepages resv_hugepages
surplus_hugepages surplus_hugepages
which function as described above for the default huge page-sized case. The demote interfaces provide the ability to split a huge page into
smaller huge pages. For example, the x86 architecture supports both
1GB and 2MB huge pages sizes. A 1GB huge page can be split into 512
2MB huge pages. Demote interfaces are not available for the smallest
huge page size. The demote interfaces are:
demote_size
is the size of demoted pages. When a page is demoted a corresponding
number of huge pages of demote_size will be created. By default,
demote_size is set to the next smaller huge page size. If there are
multiple smaller huge page sizes, demote_size can be set to any of
these smaller sizes. Only huge page sizes less than the current huge
pages size are allowed.
demote
is used to demote a number of huge pages. A user with root privileges
can write to this file. It may not be possible to demote the
requested number of huge pages. To determine how many pages were
actually demoted, compare the value of nr_hugepages before and after
writing to the demote interface. demote is a write only interface.
The interfaces which are the same as in ``/proc`` (all except demote and
demote_size) function as described above for the default huge page-sized case.
.. _mem_policy_and_hp_alloc: .. _mem_policy_and_hp_alloc:

2
Documentation/admin-guide/mm/index.rst
View File

@@ -37,5 +37,7 @@ the Linux memory management.
numaperf numaperf
pagemap pagemap
soft-dirty soft-dirty
swap_numa
transhuge transhuge
userfaultfd userfaultfd
zswap

141
Documentation/admin-guide/mm/memory-hotplug.rst
View File

@@ -165,9 +165,8 @@ Or alternatively::
% echo 1 > /sys/devices/system/memory/memoryXXX/online % echo 1 > /sys/devices/system/memory/memoryXXX/online
The kernel will select the target zone automatically, usually defaulting to The kernel will select the target zone automatically, depending on the
``ZONE_NORMAL`` unless ``movablecore=1`` has been specified on the kernel configured ``online_policy``.
command line or if the memory block would intersect the ZONE_MOVABLE already.
One can explicitly request to associate an offline memory block with One can explicitly request to associate an offline memory block with
ZONE_MOVABLE by:: ZONE_MOVABLE by::
@@ -198,6 +197,9 @@ Auto-onlining can be enabled by writing ``online``, ``online_kernel`` or
% echo online > /sys/devices/system/memory/auto_online_blocks % echo online > /sys/devices/system/memory/auto_online_blocks
Similarly to manual onlining, with ``online`` the kernel will select the
target zone automatically, depending on the configured ``online_policy``.
Modifying the auto-online behavior will only affect all subsequently added Modifying the auto-online behavior will only affect all subsequently added
memory blocks only. memory blocks only.
@@ -393,11 +395,16 @@ command line parameters are relevant:
======================== ======================================================= ======================== =======================================================
``memhp_default_state`` configure auto-onlining by essentially setting ``memhp_default_state`` configure auto-onlining by essentially setting
``/sys/devices/system/memory/auto_online_blocks``. ``/sys/devices/system/memory/auto_online_blocks``.
``movablecore`` configure automatic zone selection of the kernel. When ``movable_node`` configure automatic zone selection in the kernel when
set, the kernel will default to ZONE_MOVABLE, unless using the ``contig-zones`` online policy. When
other zones can be kept contiguous. set, the kernel will default to ZONE_MOVABLE when
onlining a memory block, unless other zones can be kept
contiguous.
======================== ======================================================= ======================== =======================================================
See Documentation/admin-guide/kernel-parameters.txt for a more generic
description of these command line parameters.
Module Parameters Module Parameters
------------------ ------------------
@@ -410,24 +417,118 @@ them with ``memory_hotplug.`` such as::
and they can be observed (and some even modified at runtime) via:: and they can be observed (and some even modified at runtime) via::
/sys/modules/memory_hotplug/parameters/ /sys/module/memory_hotplug/parameters/
The following module parameters are currently defined: The following module parameters are currently defined:
======================== ======================================================= ================================ ===============================================
``memmap_on_memory`` read-write: Allocate memory for the memmap from the ``memmap_on_memory`` read-write: Allocate memory for the memmap from
added memory block itself. Even if enabled, actual the added memory block itself. Even if enabled,
support depends on various other system properties and actual support depends on various other system
should only be regarded as a hint whether the behavior properties and should only be regarded as a
would be desired. hint whether the behavior would be desired.
While allocating the memmap from the memory block While allocating the memmap from the memory
itself makes memory hotplug less likely to fail and block itself makes memory hotplug less likely
keeps the memmap on the same NUMA node in any case, it to fail and keeps the memmap on the same NUMA
can fragment physical memory in a way that huge pages node in any case, it can fragment physical
in bigger granularity cannot be formed on hotplugged memory in a way that huge pages in bigger
memory. granularity cannot be formed on hotplugged
======================== ======================================================= memory.
``online_policy`` read-write: Set the basic policy used for
automatic zone selection when onlining memory
blocks without specifying a target zone.
``contig-zones`` has been the kernel default
before this parameter was added. After an
online policy was configured and memory was
online, the policy should not be changed
anymore.
When set to ``contig-zones``, the kernel will
try keeping zones contiguous. If a memory block
intersects multiple zones or no zone, the
behavior depends on the ``movable_node`` kernel
command line parameter: default to ZONE_MOVABLE
if set, default to the applicable kernel zone
(usually ZONE_NORMAL) if not set.
When set to ``auto-movable``, the kernel will
try onlining memory blocks to ZONE_MOVABLE if
possible according to the configuration and
memory device details. With this policy, one
can avoid zone imbalances when eventually
hotplugging a lot of memory later and still
wanting to be able to hotunplug as much as
possible reliably, very desirable in
virtualized environments. This policy ignores
the ``movable_node`` kernel command line
parameter and isn't really applicable in
environments that require it (e.g., bare metal
with hotunpluggable nodes) where hotplugged
memory might be exposed via the
firmware-provided memory map early during boot
to the system instead of getting detected,
added and onlined later during boot (such as
done by virtio-mem or by some hypervisors
implementing emulated DIMMs). As one example, a
hotplugged DIMM will be onlined either
completely to ZONE_MOVABLE or completely to
ZONE_NORMAL, not a mixture.
As another example, as many memory blocks
belonging to a virtio-mem device will be
onlined to ZONE_MOVABLE as possible,
special-casing units of memory blocks that can
only get hotunplugged together. *This policy
does not protect from setups that are
problematic with ZONE_MOVABLE and does not
change the zone of memory blocks dynamically
after they were onlined.*
``auto_movable_ratio`` read-write: Set the maximum MOVABLE:KERNEL
memory ratio in % for the ``auto-movable``
online policy. Whether the ratio applies only
for the system across all NUMA nodes or also
per NUMA nodes depends on the
``auto_movable_numa_aware`` configuration.
All accounting is based on present memory pages
in the zones combined with accounting per
memory device. Memory dedicated to the CMA
allocator is accounted as MOVABLE, although
residing on one of the kernel zones. The
possible ratio depends on the actual workload.
The kernel default is "301" %, for example,
allowing for hotplugging 24 GiB to a 8 GiB VM
and automatically onlining all hotplugged
memory to ZONE_MOVABLE in many setups. The
additional 1% deals with some pages being not
present, for example, because of some firmware
allocations.
Note that ZONE_NORMAL memory provided by one
memory device does not allow for more
ZONE_MOVABLE memory for a different memory
device. As one example, onlining memory of a
hotplugged DIMM to ZONE_NORMAL will not allow
for another hotplugged DIMM to get onlined to
ZONE_MOVABLE automatically. In contrast, memory
hotplugged by a virtio-mem device that got
onlined to ZONE_NORMAL will allow for more
ZONE_MOVABLE memory within *the same*
virtio-mem device.
``auto_movable_numa_aware`` read-write: Configure whether the
``auto_movable_ratio`` in the ``auto-movable``
online policy also applies per NUMA
node in addition to the whole system across all
NUMA nodes. The kernel default is "Y".
Disabling NUMA awareness can be helpful when
dealing with NUMA nodes that should be
completely hotunpluggable, onlining the memory
completely to ZONE_MOVABLE automatically if
possible.
Parameter availability depends on CONFIG_NUMA.
================================ ===============================================
ZONE_MOVABLE ZONE_MOVABLE
============ ============

53
Documentation/admin-guide/mm/pagemap.rst
View File

@@ -90,13 +90,14 @@ Short descriptions to the page flags
==================================== ====================================
0 - LOCKED 0 - LOCKED
page is being locked for exclusive access, e.g. by undergoing read/write IO The page is being locked for exclusive access, e.g. by undergoing read/write
IO.
7 - SLAB 7 - SLAB
page is managed by the SLAB/SLOB/SLUB/SLQB kernel memory allocator The page is managed by the SLAB/SLOB/SLUB/SLQB kernel memory allocator.
When compound page is used, SLUB/SLQB will only set this flag on the head When compound page is used, SLUB/SLQB will only set this flag on the head
page; SLOB will not flag it at all. page; SLOB will not flag it at all.
10 - BUDDY 10 - BUDDY
a free memory block managed by the buddy system allocator A free memory block managed by the buddy system allocator.
The buddy system organizes free memory in blocks of various orders. The buddy system organizes free memory in blocks of various orders.
An order N block has 2^N physically contiguous pages, with the BUDDY flag An order N block has 2^N physically contiguous pages, with the BUDDY flag
set for and _only_ for the first page. set for and _only_ for the first page.
@@ -112,65 +113,65 @@ Short descriptions to the page flags
16 - COMPOUND_TAIL 16 - COMPOUND_TAIL
A compound page tail (see description above). A compound page tail (see description above).
17 - HUGE 17 - HUGE
this is an integral part of a HugeTLB page This is an integral part of a HugeTLB page.
19 - HWPOISON 19 - HWPOISON
hardware detected memory corruption on this page: don't touch the data! Hardware detected memory corruption on this page: don't touch the data!
20 - NOPAGE 20 - NOPAGE
no page frame exists at the requested address No page frame exists at the requested address.
21 - KSM 21 - KSM
identical memory pages dynamically shared between one or more processes Identical memory pages dynamically shared between one or more processes.
22 - THP 22 - THP
contiguous pages which construct transparent hugepages Contiguous pages which construct transparent hugepages.
23 - OFFLINE 23 - OFFLINE
page is logically offline The page is logically offline.
24 - ZERO_PAGE 24 - ZERO_PAGE
zero page for pfn_zero or huge_zero page Zero page for pfn_zero or huge_zero page.
25 - IDLE 25 - IDLE
page has not been accessed since it was marked idle (see The page has not been accessed since it was marked idle (see
:ref:`Documentation/admin-guide/mm/idle_page_tracking.rst <idle_page_tracking>`). :ref:`Documentation/admin-guide/mm/idle_page_tracking.rst <idle_page_tracking>`).
Note that this flag may be stale in case the page was accessed via Note that this flag may be stale in case the page was accessed via
a PTE. To make sure the flag is up-to-date one has to read a PTE. To make sure the flag is up-to-date one has to read
``/sys/kernel/mm/page_idle/bitmap`` first. ``/sys/kernel/mm/page_idle/bitmap`` first.
26 - PGTABLE 26 - PGTABLE
page is in use as a page table The page is in use as a page table.
IO related page flags IO related page flags
--------------------- ---------------------
1 - ERROR 1 - ERROR
IO error occurred IO error occurred.
3 - UPTODATE 3 - UPTODATE
page has up-to-date data The page has up-to-date data.
ie. for file backed page: (in-memory data revision >= on-disk one) ie. for file backed page: (in-memory data revision >= on-disk one)
4 - DIRTY 4 - DIRTY
page has been written to, hence contains new data The page has been written to, hence contains new data.
i.e. for file backed page: (in-memory data revision > on-disk one) i.e. for file backed page: (in-memory data revision > on-disk one)
8 - WRITEBACK 8 - WRITEBACK
page is being synced to disk The page is being synced to disk.
LRU related page flags LRU related page flags
---------------------- ----------------------
5 - LRU 5 - LRU
page is in one of the LRU lists The page is in one of the LRU lists.
6 - ACTIVE 6 - ACTIVE
page is in the active LRU list The page is in the active LRU list.
18 - UNEVICTABLE 18 - UNEVICTABLE
page is in the unevictable (non-)LRU list It is somehow pinned and The page is in the unevictable (non-)LRU list It is somehow pinned and
not a candidate for LRU page reclaims, e.g. ramfs pages, not a candidate for LRU page reclaims, e.g. ramfs pages,
shmctl(SHM_LOCK) and mlock() memory segments shmctl(SHM_LOCK) and mlock() memory segments.
2 - REFERENCED 2 - REFERENCED
page has been referenced since last LRU list enqueue/requeue The page has been referenced since last LRU list enqueue/requeue.
9 - RECLAIM 9 - RECLAIM
page will be reclaimed soon after its pageout IO completed The page will be reclaimed soon after its pageout IO completed.
11 - MMAP 11 - MMAP
a memory mapped page A memory mapped page.
12 - ANON 12 - ANON
a memory mapped page that is not part of a file A memory mapped page that is not part of a file.
13 - SWAPCACHE 13 - SWAPCACHE
page is mapped to swap space, i.e. has an associated swap entry The page is mapped to swap space, i.e. has an associated swap entry.
14 - SWAPBACKED 14 - SWAPBACKED
page is backed by swap/RAM The page is backed by swap/RAM.
The page-types tool in the tools/vm directory can be used to query the The page-types tool in the tools/vm directory can be used to query the
above flags. above flags.

0
Documentation/vm/swap_numa.rst → Documentation/admin-guide/mm/swap_numa.rst
View File

0
Documentation/vm/zswap.rst → Documentation/admin-guide/mm/zswap.rst
View File

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

@@ -1099,7 +1099,7 @@ task_delayacct
=============== ===============
Enables/disables task delay accounting (see Enables/disables task delay accounting (see
:doc:`accounting/delay-accounting.rst`). Enabling this feature incurs Documentation/accounting/delay-accounting.rst. Enabling this feature incurs
a small amount of overhead in the scheduler but is useful for debugging a small amount of overhead in the scheduler but is useful for debugging
and performance tuning. It is required by some tools such as iotop. and performance tuning. It is required by some tools such as iotop.

48
Documentation/arm/marvell.rst
View File

@@ -104,6 +104,8 @@ Discovery family
Not supported by the Linux kernel. Not supported by the Linux kernel.
Homepage:
https://web.archive.org/web/20110924171043/http://www.marvell.com/embedded-processors/discovery-innovation/
Core: Core:
Feroceon 88fr571-vd ARMv5 compatible Feroceon 88fr571-vd ARMv5 compatible
@@ -120,6 +122,7 @@ EBU Armada family
- 88F6707 - 88F6707
- 88F6W11 - 88F6W11
- Product infos: https://web.archive.org/web/20141002083258/http://www.marvell.com/embedded-processors/armada-370/
- Product Brief: https://web.archive.org/web/20121115063038/http://www.marvell.com/embedded-processors/armada-300/assets/Marvell_ARMADA_370_SoC.pdf - Product Brief: https://web.archive.org/web/20121115063038/http://www.marvell.com/embedded-processors/armada-300/assets/Marvell_ARMADA_370_SoC.pdf
- Hardware Spec: https://web.archive.org/web/20140617183747/http://www.marvell.com/embedded-processors/armada-300/assets/ARMADA370-datasheet.pdf - Hardware Spec: https://web.archive.org/web/20140617183747/http://www.marvell.com/embedded-processors/armada-300/assets/ARMADA370-datasheet.pdf
- Functional Spec: https://web.archive.org/web/20140617183701/http://www.marvell.com/embedded-processors/armada-300/assets/ARMADA370-FunctionalSpec-datasheet.pdf - Functional Spec: https://web.archive.org/web/20140617183701/http://www.marvell.com/embedded-processors/armada-300/assets/ARMADA370-FunctionalSpec-datasheet.pdf
@@ -127,9 +130,29 @@ EBU Armada family
Core: Core:
Sheeva ARMv7 compatible PJ4B Sheeva ARMv7 compatible PJ4B
Armada XP Flavors:
- MV78230
- MV78260
- MV78460
NOTE:
not to be confused with the non-SMP 78xx0 SoCs
- Product infos: https://web.archive.org/web/20150101215721/http://www.marvell.com/embedded-processors/armada-xp/
- Product Brief: https://web.archive.org/web/20121021173528/http://www.marvell.com/embedded-processors/armada-xp/assets/Marvell-ArmadaXP-SoC-product%20brief.pdf
- Functional Spec: https://web.archive.org/web/20180829171131/http://www.marvell.com/embedded-processors/armada-xp/assets/ARMADA-XP-Functional-SpecDatasheet.pdf
- Hardware Specs:
- https://web.archive.org/web/20141127013651/http://www.marvell.com/embedded-processors/armada-xp/assets/HW_MV78230_OS.PDF
- https://web.archive.org/web/20141222000224/http://www.marvell.com/embedded-processors/armada-xp/assets/HW_MV78260_OS.PDF
- https://web.archive.org/web/20141222000230/http://www.marvell.com/embedded-processors/armada-xp/assets/HW_MV78460_OS.PDF
Core:
Sheeva ARMv7 compatible Dual-core or Quad-core PJ4B-MP
Armada 375 Flavors: Armada 375 Flavors:
- 88F6720 - 88F6720
- Product infos: https://web.archive.org/web/20140108032402/http://www.marvell.com/embedded-processors/armada-375/
- Product Brief: https://web.archive.org/web/20131216023516/http://www.marvell.com/embedded-processors/armada-300/assets/ARMADA_375_SoC-01_product_brief.pdf - Product Brief: https://web.archive.org/web/20131216023516/http://www.marvell.com/embedded-processors/armada-300/assets/ARMADA_375_SoC-01_product_brief.pdf
Core: Core:
@@ -162,29 +185,6 @@ EBU Armada family
Core: Core:
ARM Cortex-A9 ARM Cortex-A9
Armada XP Flavors:
- MV78230
- MV78260
- MV78460
NOTE:
not to be confused with the non-SMP 78xx0 SoCs
Product Brief:
https://web.archive.org/web/20121021173528/http://www.marvell.com/embedded-processors/armada-xp/assets/Marvell-ArmadaXP-SoC-product%20brief.pdf
Functional Spec:
https://web.archive.org/web/20180829171131/http://www.marvell.com/embedded-processors/armada-xp/assets/ARMADA-XP-Functional-SpecDatasheet.pdf
- Hardware Specs:
- https://web.archive.org/web/20141127013651/http://www.marvell.com/embedded-processors/armada-xp/assets/HW_MV78230_OS.PDF
- https://web.archive.org/web/20141222000224/http://www.marvell.com/embedded-processors/armada-xp/assets/HW_MV78260_OS.PDF
- https://web.archive.org/web/20141222000230/http://www.marvell.com/embedded-processors/armada-xp/assets/HW_MV78460_OS.PDF
Core:
Sheeva ARMv7 compatible Dual-core or Quad-core PJ4B-MP
Linux kernel mach directory: Linux kernel mach directory:
arch/arm/mach-mvebu arch/arm/mach-mvebu
Linux kernel plat directory: Linux kernel plat directory:
@@ -436,7 +436,7 @@ Berlin family (Multimedia Solutions)
- Flavors: - Flavors:
- 88DE3010, Armada 1000 (no Linux support) - 88DE3010, Armada 1000 (no Linux support)
- Core: Marvell PJ1 (ARMv5TE), Dual-core - Core: Marvell PJ1 (ARMv5TE), Dual-core
- Product Brief: http://www.marvell.com.cn/digital-entertainment/assets/armada_1000_pb.pdf - Product Brief: https://web.archive.org/web/20131103162620/http://www.marvell.com/digital-entertainment/assets/armada_1000_pb.pdf
- 88DE3005, Armada 1500 Mini - 88DE3005, Armada 1500 Mini
- Design name: BG2CD - Design name: BG2CD
- Core: ARM Cortex-A9, PL310 L2CC - Core: ARM Cortex-A9, PL310 L2CC

2
Documentation/bpf/index.rst
View File

@@ -15,7 +15,7 @@ that goes into great technical depth about the BPF Architecture.
libbpf libbpf
====== ======
Documentation/bpf/libbpf/libbpf.rst is a userspace library for loading and interacting with bpf programs. Documentation/bpf/libbpf/index.rst is a userspace library for loading and interacting with bpf programs.
BPF Type Format (BTF) BPF Type Format (BTF)
===================== =====================

3
Documentation/core-api/memory-hotplug.rst
View File

@@ -57,7 +57,6 @@ The third argument (arg) passes a pointer of struct memory_notify::
unsigned long start_pfn; unsigned long start_pfn;
unsigned long nr_pages; unsigned long nr_pages;
int status_change_nid_normal; int status_change_nid_normal;
int status_change_nid_high;
int status_change_nid; int status_change_nid;
} }
@@ -65,8 +64,6 @@ The third argument (arg) passes a pointer of struct memory_notify::
- nr_pages is # of pages of online/offline memory. - nr_pages is # of pages of online/offline memory.
- status_change_nid_normal is set node id when N_NORMAL_MEMORY of nodemask - status_change_nid_normal is set node id when N_NORMAL_MEMORY of nodemask
is (will be) set/clear, if this is -1, then nodemask status is not changed. is (will be) set/clear, if this is -1, then nodemask status is not changed.
- status_change_nid_high is set node id when N_HIGH_MEMORY of nodemask
is (will be) set/clear, if this is -1, then nodemask status is not changed.
- status_change_nid is set node id when N_MEMORY of nodemask is (will be) - status_change_nid is set node id when N_MEMORY of nodemask is (will be)
set/clear. It means a new(memoryless) node gets new memory by online and a set/clear. It means a new(memoryless) node gets new memory by online and a
node loses all memory. If this is -1, then nodemask status is not changed. node loses all memory. If this is -1, then nodemask status is not changed.

5
Documentation/dev-tools/kcov.rst
View File

@@ -50,6 +50,7 @@ program using kcov:
#include <sys/mman.h> #include <sys/mman.h>
#include <unistd.h> #include <unistd.h>
#include <fcntl.h> #include <fcntl.h>
#include <linux/types.h>
#define KCOV_INIT_TRACE _IOR('c', 1, unsigned long) #define KCOV_INIT_TRACE _IOR('c', 1, unsigned long)
#define KCOV_ENABLE _IO('c', 100) #define KCOV_ENABLE _IO('c', 100)
@@ -177,6 +178,8 @@ Comparison operands collection is similar to coverage collection:
/* Read number of comparisons collected. */ /* Read number of comparisons collected. */
n = __atomic_load_n(&cover[0], __ATOMIC_RELAXED); n = __atomic_load_n(&cover[0], __ATOMIC_RELAXED);
for (i = 0; i < n; i++) { for (i = 0; i < n; i++) {
uint64_t ip;
type = cover[i * KCOV_WORDS_PER_CMP + 1]; type = cover[i * KCOV_WORDS_PER_CMP + 1];
/* arg1 and arg2 - operands of the comparison. */ /* arg1 and arg2 - operands of the comparison. */
arg1 = cover[i * KCOV_WORDS_PER_CMP + 2]; arg1 = cover[i * KCOV_WORDS_PER_CMP + 2];
@@ -251,6 +254,8 @@ selectively from different subsystems.
.. code-block:: c .. code-block:: c
/* Same includes and defines as above. */
struct kcov_remote_arg { struct kcov_remote_arg {
__u32 trace_mode; __u32 trace_mode;
__u32 area_size; __u32 area_size;

23
Documentation/dev-tools/kfence.rst
View File

@@ -231,10 +231,14 @@ Guarded allocations are set up based on the sample interval. After expiration
of the sample interval, the next allocation through the main allocator (SLAB or of the sample interval, the next allocation through the main allocator (SLAB or
SLUB) returns a guarded allocation from the KFENCE object pool (allocation SLUB) returns a guarded allocation from the KFENCE object pool (allocation
sizes up to PAGE_SIZE are supported). At this point, the timer is reset, and sizes up to PAGE_SIZE are supported). At this point, the timer is reset, and
the next allocation is set up after the expiration of the interval. To "gate" a the next allocation is set up after the expiration of the interval.
KFENCE allocation through the main allocator's fast-path without overhead,
KFENCE relies on static branches via the static keys infrastructure. The static When using ``CONFIG_KFENCE_STATIC_KEYS=y``, KFENCE allocations are "gated"
branch is toggled to redirect the allocation to KFENCE. through the main allocator's fast-path by relying on static branches via the
static keys infrastructure. The static branch is toggled to redirect the
allocation to KFENCE. Depending on sample interval, target workloads, and
system architecture, this may perform better than the simple dynamic branch.
Careful benchmarking is recommended.
KFENCE objects each reside on a dedicated page, at either the left or right KFENCE objects each reside on a dedicated page, at either the left or right
page boundaries selected at random. The pages to the left and right of the page boundaries selected at random. The pages to the left and right of the
@@ -269,6 +273,17 @@ tail of KFENCE's freelist, so that the least recently freed objects are reused
first, and the chances of detecting use-after-frees of recently freed objects first, and the chances of detecting use-after-frees of recently freed objects
is increased. is increased.
If pool utilization reaches 75% (default) or above, to reduce the risk of the
pool eventually being fully occupied by allocated objects yet ensure diverse
coverage of allocations, KFENCE limits currently covered allocations of the
same source from further filling up the pool. The "source" of an allocation is
based on its partial allocation stack trace. A side-effect is that this also
limits frequent long-lived allocations (e.g. pagecache) of the same source
filling up the pool permanently, which is the most common risk for the pool
becoming full and the sampled allocation rate dropping to zero. The threshold
at which to start limiting currently covered allocations can be configured via
the boot parameter ``kfence.skip_covered_thresh`` (pool usage%).
Interface Interface
--------- ---------

2
Documentation/devicetree/bindings/arm/sti.yaml
View File

@@ -7,7 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml#
title: ST STi Platforms Device Tree Bindings title: ST STi Platforms Device Tree Bindings
maintainers: maintainers:
- Patrice Chotard <patrice.chotard@st.com> - Patrice Chotard <patrice.chotard@foss.st.com>
properties: properties:
$nodename: $nodename:

4
Documentation/devicetree/bindings/arm/stm32/st,mlahb.yaml
View File

@@ -7,8 +7,8 @@ $schema: "http://devicetree.org/meta-schemas/core.yaml#"
title: STMicroelectronics STM32 ML-AHB interconnect bindings title: STMicroelectronics STM32 ML-AHB interconnect bindings
maintainers: maintainers:
- Fabien Dessenne <fabien.dessenne@st.com> - Fabien Dessenne <fabien.dessenne@foss.st.com>
- Arnaud Pouliquen <arnaud.pouliquen@st.com> - Arnaud Pouliquen <arnaud.pouliquen@foss.st.com>
description: | description: |
These bindings describe the STM32 SoCs ML-AHB interconnect bus which connects These bindings describe the STM32 SoCs ML-AHB interconnect bus which connects

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

@@ -7,8 +7,8 @@ $schema: "http://devicetree.org/meta-schemas/core.yaml#"
title: STMicroelectronics STM32 Platforms System Controller bindings title: STMicroelectronics STM32 Platforms System Controller bindings
maintainers: maintainers:
- Alexandre Torgue <alexandre.torgue@st.com> - Alexandre Torgue <alexandre.torgue@foss.st.com>
- Christophe Roullier <christophe.roullier@st.com> - Christophe Roullier <christophe.roullier@foss.st.com>
properties: properties:
compatible: compatible:

2
Documentation/devicetree/bindings/arm/stm32/stm32.yaml
View File

@@ -7,7 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml#
title: STMicroelectronics STM32 Platforms Device Tree Bindings title: STMicroelectronics STM32 Platforms Device Tree Bindings
maintainers: maintainers:
- Alexandre Torgue <alexandre.torgue@st.com> - Alexandre Torgue <alexandre.torgue@foss.st.com>
properties: properties:
$nodename: $nodename:

32
Documentation/devicetree/bindings/auxdisplay/holtek,ht16k33.yaml
View File

@@ -14,14 +14,21 @@ allOf:
properties: properties:
compatible: compatible:
const: holtek,ht16k33 oneOf:
- items:
- enum:
- adafruit,3108 # 0.56" 4-Digit 7-Segment FeatherWing Display (Red)
- adafruit,3130 # 0.54" Quad Alphanumeric FeatherWing Display (Red)
- const: holtek,ht16k33
- const: holtek,ht16k33 # Generic 16*8 LED controller with dot-matrix display
reg: reg:
maxItems: 1 maxItems: 1
refresh-rate-hz: refresh-rate-hz:
maxItems: 1 maxItems: 1
description: Display update interval in Hertz description: Display update interval in Hertz for dot-matrix displays
interrupts: interrupts:
maxItems: 1 maxItems: 1
@@ -41,10 +48,22 @@ properties:
default: 16 default: 16
description: Initial brightness level description: Initial brightness level
led:
type: object
$ref: /schemas/leds/common.yaml#
unevaluatedProperties: false
required: required:
- compatible - compatible
- reg - reg
- refresh-rate-hz
if:
properties:
compatible:
const: holtek,ht16k33
then:
required:
- refresh-rate-hz
additionalProperties: false additionalProperties: false
@@ -52,6 +71,7 @@ examples:
- | - |
#include <dt-bindings/interrupt-controller/irq.h> #include <dt-bindings/interrupt-controller/irq.h>
#include <dt-bindings/input/input.h> #include <dt-bindings/input/input.h>
#include <dt-bindings/leds/common.h>
i2c1 { i2c1 {
#address-cells = <1>; #address-cells = <1>;
#size-cells = <0>; #size-cells = <0>;
@@ -73,5 +93,11 @@ examples:
<MATRIX_KEY(4, 1, KEY_F9)>, <MATRIX_KEY(4, 1, KEY_F9)>,
<MATRIX_KEY(5, 1, KEY_F3)>, <MATRIX_KEY(5, 1, KEY_F3)>,
<MATRIX_KEY(6, 1, KEY_F1)>; <MATRIX_KEY(6, 1, KEY_F1)>;
led {
color = <LED_COLOR_ID_RED>;
function = LED_FUNCTION_BACKLIGHT;
linux,default-trigger = "backlight";
};
}; };
}; };

2
Documentation/devicetree/bindings/clock/ingenic,cgu.yaml
View File

@@ -104,7 +104,7 @@ additionalProperties: false
examples: examples:
- | - |
#include <dt-bindings/clock/jz4770-cgu.h> #include <dt-bindings/clock/ingenic,jz4770-cgu.h>
cgu: clock-controller@10000000 { cgu: clock-controller@10000000 {
compatible = "ingenic,jz4770-cgu", "simple-mfd"; compatible = "ingenic,jz4770-cgu", "simple-mfd";
reg = <0x10000000 0x100>; reg = <0x10000000 0x100>;

4
Documentation/devicetree/bindings/clock/maxim,max77686.txt
View File

@@ -49,7 +49,7 @@ Example:
max77686: max77686@9 { max77686: max77686@9 {
compatible = "maxim,max77686"; compatible = "maxim,max77686";
interrupt-parent = <&wakeup_eint>; interrupt-parent = <&wakeup_eint>;
interrupts = <26 0>; interrupts = <26 IRQ_TYPE_LEVEL_LOW>;
reg = <0x09>; reg = <0x09>;
#clock-cells = <1>; #clock-cells = <1>;
@@ -74,7 +74,7 @@ Example:
max77802: max77802@9 { max77802: max77802@9 {
compatible = "maxim,max77802"; compatible = "maxim,max77802";
interrupt-parent = <&wakeup_eint>; interrupt-parent = <&wakeup_eint>;
interrupts = <26 0>; interrupts = <26 IRQ_TYPE_LEVEL_LOW>;
reg = <0x09>; reg = <0x09>;
#clock-cells = <1>; #clock-cells = <1>;

4
Documentation/devicetree/bindings/clock/sifive/fu740-prci.yaml
View File

@@ -42,6 +42,9 @@ properties:
"#clock-cells": "#clock-cells":
const: 1 const: 1
"#reset-cells":
const: 1
required: required:
- compatible - compatible
- reg - reg
@@ -57,4 +60,5 @@ examples:
reg = <0x10000000 0x1000>; reg = <0x10000000 0x1000>;
clocks = <&hfclk>, <&rtcclk>; clocks = <&hfclk>, <&rtcclk>;
#clock-cells = <1>; #clock-cells = <1>;
#reset-cells = <1>;
}; };

2
Documentation/devicetree/bindings/clock/silabs,si5351.txt
View File

@@ -2,7 +2,7 @@ Binding for Silicon Labs Si5351a/b/c programmable i2c clock generator.
Reference Reference
[1] Si5351A/B/C Data Sheet [1] Si5351A/B/C Data Sheet
https://www.silabs.com/Support%20Documents/TechnicalDocs/Si5351.pdf https://www.skyworksinc.com/-/media/Skyworks/SL/documents/public/data-sheets/Si5351-B.pdf
The Si5351a/b/c are programmable i2c clock generators with up to 8 output The Si5351a/b/c are programmable i2c clock generators with up to 8 output
clocks. Si5351a also has a reduced pin-count package (MSOP10) where only clocks. Si5351a also has a reduced pin-count package (MSOP10) where only

6
Documentation/devicetree/bindings/clock/socionext,uniphier-clock.yaml
View File

@@ -23,6 +23,7 @@ properties:
- socionext,uniphier-ld11-clock - socionext,uniphier-ld11-clock
- socionext,uniphier-ld20-clock - socionext,uniphier-ld20-clock
- socionext,uniphier-pxs3-clock - socionext,uniphier-pxs3-clock
- socionext,uniphier-nx1-clock
- description: Media I/O (MIO) clock, SD clock - description: Media I/O (MIO) clock, SD clock
enum: enum:
- socionext,uniphier-ld4-mio-clock - socionext,uniphier-ld4-mio-clock
@@ -33,6 +34,7 @@ properties:
- socionext,uniphier-ld11-mio-clock - socionext,uniphier-ld11-mio-clock
- socionext,uniphier-ld20-sd-clock - socionext,uniphier-ld20-sd-clock
- socionext,uniphier-pxs3-sd-clock - socionext,uniphier-pxs3-sd-clock
- socionext,uniphier-nx1-sd-clock
- description: Peripheral clock - description: Peripheral clock
enum: enum:
- socionext,uniphier-ld4-peri-clock - socionext,uniphier-ld4-peri-clock
@@ -43,6 +45,10 @@ properties:
- socionext,uniphier-ld11-peri-clock - socionext,uniphier-ld11-peri-clock
- socionext,uniphier-ld20-peri-clock - socionext,uniphier-ld20-peri-clock
- socionext,uniphier-pxs3-peri-clock - socionext,uniphier-pxs3-peri-clock
- socionext,uniphier-nx1-peri-clock
- description: SoC-glue clock
enum:
- socionext,uniphier-pro4-sg-clock
"#clock-cells": "#clock-cells":
const: 1 const: 1

2
Documentation/devicetree/bindings/clock/st,stm32mp1-rcc.yaml
View File

@@ -7,7 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml#
title: Reset Clock Controller Binding title: Reset Clock Controller Binding
maintainers: maintainers:
- Gabriel Fernandez <gabriel.fernandez@st.com> - Gabriel Fernandez <gabriel.fernandez@foss.st.com>
description: | description: |
The RCC IP is both a reset and a clock controller. The RCC IP is both a reset and a clock controller.

2
Documentation/devicetree/bindings/crypto/st,stm32-crc.yaml
View File

@@ -7,7 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml#
title: STMicroelectronics STM32 CRC bindings title: STMicroelectronics STM32 CRC bindings
maintainers: maintainers:
- Lionel Debieve <lionel.debieve@st.com> - Lionel Debieve <lionel.debieve@foss.st.com>
properties: properties:
compatible: compatible:

2
Documentation/devicetree/bindings/crypto/st,stm32-cryp.yaml
View File

@@ -7,7 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml#
title: STMicroelectronics STM32 CRYP bindings title: STMicroelectronics STM32 CRYP bindings
maintainers: maintainers:
- Lionel Debieve <lionel.debieve@st.com> - Lionel Debieve <lionel.debieve@foss.st.com>
properties: properties:
compatible: compatible:

2
Documentation/devicetree/bindings/crypto/st,stm32-hash.yaml
View File

@@ -7,7 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml#
title: STMicroelectronics STM32 HASH bindings title: STMicroelectronics STM32 HASH bindings
maintainers: maintainers:
- Lionel Debieve <lionel.debieve@st.com> - Lionel Debieve <lionel.debieve@foss.st.com>
properties: properties:
compatible: compatible:

33
Documentation/devicetree/bindings/display/bridge/lvds-codec.yaml
View File

@@ -49,11 +49,26 @@ properties:
properties: properties:
port@0: port@0:
$ref: /schemas/graph.yaml#/properties/port $ref: /schemas/graph.yaml#/$defs/port-base
description: | description: |
For LVDS encoders, port 0 is the parallel input For LVDS encoders, port 0 is the parallel input
For LVDS decoders, port 0 is the LVDS input For LVDS decoders, port 0 is the LVDS input
properties:
endpoint:
$ref: /schemas/media/video-interfaces.yaml#
unevaluatedProperties: false
properties:
data-mapping:
enum:
- jeida-18
- jeida-24
- vesa-24
description: |
The color signals mapping order. See details in
Documentation/devicetree/bindings/display/panel/lvds.yaml
port@1: port@1:
$ref: /schemas/graph.yaml#/properties/port $ref: /schemas/graph.yaml#/properties/port
description: | description: |
@@ -71,6 +86,22 @@ properties:
power-supply: true power-supply: true
if:
not:
properties:
compatible:
contains:
const: lvds-decoder
then:
properties:
ports:
properties:
port@0:
properties:
endpoint:
properties:
data-mapping: false
required: required:
- compatible - compatible
- ports - ports

19
Documentation/devicetree/bindings/display/bridge/ps8640.yaml
View File

@@ -40,6 +40,9 @@ properties:
vdd33-supply: vdd33-supply:
description: Regulator for 3.3V digital core power. description: Regulator for 3.3V digital core power.
aux-bus:
$ref: /schemas/display/dp-aux-bus.yaml#
ports: ports:
$ref: /schemas/graph.yaml#/properties/ports $ref: /schemas/graph.yaml#/properties/ports
@@ -98,7 +101,21 @@ examples:
reg = <1>; reg = <1>;
ps8640_out: endpoint { ps8640_out: endpoint {
remote-endpoint = <&panel_in>; remote-endpoint = <&panel_in>;
}; };
};
};
aux-bus {
panel {
compatible = "boe,nv133fhm-n62";
power-supply = <&pp3300_dx_edp>;
backlight = <&backlight>;
port {
panel_in: endpoint {
remote-endpoint = <&ps8640_out>;
};
};
}; };
}; };
}; };

2
Documentation/devicetree/bindings/display/bridge/snps,dw-mipi-dsi.yaml
View File

@@ -7,7 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml#
title: Synopsys DesignWare MIPI DSI host controller title: Synopsys DesignWare MIPI DSI host controller
maintainers: maintainers:
- Philippe CORNU <philippe.cornu@st.com> - Philippe CORNU <philippe.cornu@foss.st.com>
description: | description: |
This document defines device tree properties for the Synopsys DesignWare MIPI This document defines device tree properties for the Synopsys DesignWare MIPI

54
Documentation/devicetree/bindings/display/bridge/toshiba,tc358767.txt
View File

@@ -1,54 +0,0 @@
Toshiba TC358767 eDP bridge bindings
Required properties:
- compatible: "toshiba,tc358767"
- reg: i2c address of the bridge, 0x68 or 0x0f, depending on bootstrap pins
- clock-names: should be "ref"
- clocks: OF device-tree clock specification for refclk input. The reference
clock rate must be 13 MHz, 19.2 MHz, 26 MHz, or 38.4 MHz.
Optional properties:
- shutdown-gpios: OF device-tree gpio specification for SD pin
(active high shutdown input)
- reset-gpios: OF device-tree gpio specification for RSTX pin
(active low system reset)
- toshiba,hpd-pin: TC358767 GPIO pin number to which HPD is connected to (0 or 1)
- ports: the ports node can contain video interface port nodes to connect
to a DPI/DSI source and to an eDP/DP sink according to [1][2]:
- port@0: DSI input port
- port@1: DPI input port
- port@2: eDP/DP output port
[1]: Documentation/devicetree/bindings/graph.txt
[2]: Documentation/devicetree/bindings/media/video-interfaces.txt
Example:
edp-bridge@68 {
compatible = "toshiba,tc358767";
reg = <0x68>;
shutdown-gpios = <&gpio3 23 GPIO_ACTIVE_HIGH>;
reset-gpios = <&gpio3 24 GPIO_ACTIVE_LOW>;
clock-names = "ref";
clocks = <&edp_refclk>;
ports {
#address-cells = <1>;
#size-cells = <0>;
port@1 {
reg = <1>;
bridge_in: endpoint {
remote-endpoint = <&dpi_out>;
};
};
port@2 {
reg = <2>;
bridge_out: endpoint {
remote-endpoint = <&panel_in>;
};
};
};
};

158
Documentation/devicetree/bindings/display/bridge/toshiba,tc358767.yaml Normal file
View File

@@ -0,0 +1,158 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/display/bridge/toshiba,tc358767.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Toshiba TC358767 eDP bridge bindings
maintainers:
- Andrey Gusakov <andrey.gusakov@cogentembedded.com>
description: The TC358767 is bridge device which converts DSI/DPI to eDP/DP
properties:
compatible:
const: toshiba,tc358767
reg:
enum:
- 0x68
- 0x0f
description: |
i2c address of the bridge, 0x68 or 0x0f, depending on bootstrap pins
clock-names:
const: "ref"
clocks:
maxItems: 1
description: |
OF device-tree clock specification for refclk input. The reference.
clock rate must be 13 MHz, 19.2 MHz, 26 MHz, or 38.4 MHz.
shutdown-gpios:
maxItems: 1
description: |
OF device-tree gpio specification for SD pin(active high shutdown input)
reset-gpios:
maxItems: 1
description: |
OF device-tree gpio specification for RSTX pin(active low system reset)
toshiba,hpd-pin:
$ref: /schemas/types.yaml#/definitions/uint32
enum:
- 0
- 1
description: TC358767 GPIO pin number to which HPD is connected to (0 or 1)
ports:
$ref: /schemas/graph.yaml#/properties/ports
properties:
port@0:
$ref: /schemas/graph.yaml#/properties/port
description: |
DSI input port. The remote endpoint phandle should be a
reference to a valid DSI output endpoint node
port@1:
$ref: /schemas/graph.yaml#/properties/port
description: |
DPI input port. The remote endpoint phandle should be a
reference to a valid DPI output endpoint node
port@2:
$ref: /schemas/graph.yaml#/properties/port
description: |
eDP/DP output port. The remote endpoint phandle should be a
reference to a valid eDP panel input endpoint node. This port is
optional, treated as DP panel if not defined
oneOf:
- required:
- port@0
- required:
- port@1
required:
- compatible
- reg
- clock-names
- clocks
- ports
additionalProperties: false
examples:
- |
#include <dt-bindings/gpio/gpio.h>
/* DPI input and eDP output */
i2c {
#address-cells = <1>;
#size-cells = <0>;
edp-bridge@68 {
compatible = "toshiba,tc358767";
reg = <0x68>;
shutdown-gpios = <&gpio3 23 GPIO_ACTIVE_HIGH>;
reset-gpios = <&gpio3 24 GPIO_ACTIVE_LOW>;
clock-names = "ref";
clocks = <&edp_refclk>;
ports {
#address-cells = <1>;
#size-cells = <0>;
port@1 {
reg = <1>;
bridge_in_0: endpoint {
remote-endpoint = <&dpi_out>;
};
};
port@2 {
reg = <2>;
bridge_out: endpoint {
remote-endpoint = <&panel_in>;
};
};
};
};
};
- |
/* DPI input and DP output */
i2c {
#address-cells = <1>;
#size-cells = <0>;
edp-bridge@68 {
compatible = "toshiba,tc358767";
reg = <0x68>;
shutdown-gpios = <&gpio3 23 GPIO_ACTIVE_HIGH>;
reset-gpios = <&gpio3 24 GPIO_ACTIVE_LOW>;
clock-names = "ref";
clocks = <&edp_refclk>;
ports {
#address-cells = <1>;
#size-cells = <0>;
port@1 {
reg = <1>;
bridge_in_1: endpoint {
remote-endpoint = <&dpi_out>;
};
};
};
};
};

2
Documentation/devicetree/bindings/display/ingenic,ipu.yaml
View File

@@ -45,7 +45,7 @@ additionalProperties: false
examples: examples:
- | - |
#include <dt-bindings/clock/jz4770-cgu.h> #include <dt-bindings/clock/ingenic,jz4770-cgu.h>
ipu@13080000 { ipu@13080000 {
compatible = "ingenic,jz4770-ipu", "ingenic,jz4760-ipu"; compatible = "ingenic,jz4770-ipu", "ingenic,jz4760-ipu";
reg = <0x13080000 0x800>; reg = <0x13080000 0x800>;

4
Documentation/devicetree/bindings/display/ingenic,lcd.yaml
View File

@@ -88,7 +88,7 @@ additionalProperties: false
examples: examples:
- | - |
#include <dt-bindings/clock/jz4740-cgu.h> #include <dt-bindings/clock/ingenic,jz4740-cgu.h>
lcd-controller@13050000 { lcd-controller@13050000 {
compatible = "ingenic,jz4740-lcd"; compatible = "ingenic,jz4740-lcd";
reg = <0x13050000 0x1000>; reg = <0x13050000 0x1000>;
@@ -107,7 +107,7 @@ examples:
}; };
- | - |
#include <dt-bindings/clock/jz4725b-cgu.h> #include <dt-bindings/clock/ingenic,jz4725b-cgu.h>
lcd-controller@13050000 { lcd-controller@13050000 {
compatible = "ingenic,jz4725b-lcd"; compatible = "ingenic,jz4725b-lcd";
reg = <0x13050000 0x1000>; reg = <0x13050000 0x1000>;

2
Documentation/devicetree/bindings/display/panel/orisetech,otm8009a.yaml
View File

@@ -7,7 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml#
title: Orise Tech OTM8009A 3.97" 480x800 TFT LCD panel (MIPI-DSI video mode) title: Orise Tech OTM8009A 3.97" 480x800 TFT LCD panel (MIPI-DSI video mode)
maintainers: maintainers:
- Philippe CORNU <philippe.cornu@st.com> - Philippe CORNU <philippe.cornu@foss.st.com>
description: | description: |
The Orise Tech OTM8009A is a 3.97" 480x800 TFT LCD panel connected using The Orise Tech OTM8009A is a 3.97" 480x800 TFT LCD panel connected using

5
Documentation/devicetree/bindings/display/panel/panel-simple.yaml
View File

@@ -166,6 +166,8 @@ properties:
- innolux,at070tn92 - innolux,at070tn92
# Innolux G070Y2-L01 7" WVGA (800x480) TFT LCD panel # Innolux G070Y2-L01 7" WVGA (800x480) TFT LCD panel
- innolux,g070y2-l01 - innolux,g070y2-l01
# Innolux G070Y2-T02 7" WVGA (800x480) TFT LCD TTL panel
- innolux,g070y2-t02
# Innolux Corporation 10.1" G101ICE-L01 WXGA (1280x800) LVDS panel # Innolux Corporation 10.1" G101ICE-L01 WXGA (1280x800) LVDS panel
- innolux,g101ice-l01 - innolux,g101ice-l01
# Innolux Corporation 12.1" WXGA (1280x800) TFT LCD panel # Innolux Corporation 12.1" WXGA (1280x800) TFT LCD panel
@@ -309,6 +311,8 @@ properties:
- urt,umsh-8596md-11t - urt,umsh-8596md-11t
- urt,umsh-8596md-19t - urt,umsh-8596md-19t
- urt,umsh-8596md-20t - urt,umsh-8596md-20t
# Vivax TPC-9150 tablet 9.0" WSVGA TFT LCD panel
- vivax,tpc9150-panel
# VXT 800x480 color TFT LCD panel # VXT 800x480 color TFT LCD panel
- vxt,vl050-8048nt-c01 - vxt,vl050-8048nt-c01
# Winstar Display Corporation 3.5" QVGA (320x240) TFT LCD panel # Winstar Display Corporation 3.5" QVGA (320x240) TFT LCD panel
@@ -317,6 +321,7 @@ properties:
- yes-optoelectronics,ytc700tlag-05-201c - yes-optoelectronics,ytc700tlag-05-201c
backlight: true backlight: true
ddc-i2c-bus: true
enable-gpios: true enable-gpios: true
port: true port: true
power-supply: true power-supply: true

2
Documentation/devicetree/bindings/display/panel/raydium,rm68200.yaml
View File

@@ -7,7 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml#
title: Raydium Semiconductor Corporation RM68200 5.5" 720p MIPI-DSI TFT LCD panel title: Raydium Semiconductor Corporation RM68200 5.5" 720p MIPI-DSI TFT LCD panel
maintainers: maintainers:
- Philippe CORNU <philippe.cornu@st.com> - Philippe CORNU <philippe.cornu@foss.st.com>
description: | description: |
The Raydium Semiconductor Corporation RM68200 is a 5.5" 720x1280 TFT LCD The Raydium Semiconductor Corporation RM68200 is a 5.5" 720x1280 TFT LCD

56
Documentation/devicetree/bindings/display/panel/sharp,ls060t1sx01.yaml Normal file
View File

@@ -0,0 +1,56 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/display/panel/sharp,ls060t1sx01.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Sharp Microelectronics 6.0" FullHD TFT LCD panel
maintainers:
- Dmitry Baryskov <dmitry.baryshkov@linaro.org>
allOf:
- $ref: panel-common.yaml#
properties:
compatible:
const: sharp,ls060t1sx01
reg: true
backlight: true
reset-gpios: true
port: true
avdd-supply:
description: handle of the regulator that provides the positive supply voltage
avee-supply:
description: handle of the regulator that provides the negative supply voltage
vddi-supply:
description: handle of the regulator that provides the I/O supply voltage
vddh-supply:
description: handle of the regulator that provides the analog supply voltage
required:
- compatible
- reg
additionalProperties: false
examples:
- |
#include <dt-bindings/gpio/gpio.h>
dsi {
#address-cells = <1>;
#size-cells = <0>;
panel@0 {
compatible = "sharp,ls060t1sx01";
reg = <0>;
avdd-supply = <&pm8941_l22>;
backlight = <&backlight>;
reset-gpios = <&pm8916_gpios 25 GPIO_ACTIVE_LOW>;
};
};
...

4
Documentation/devicetree/bindings/display/st,stm32-dsi.yaml
View File

@@ -7,8 +7,8 @@ $schema: http://devicetree.org/meta-schemas/core.yaml#
title: STMicroelectronics STM32 DSI host controller title: STMicroelectronics STM32 DSI host controller
maintainers: maintainers:
- Philippe Cornu <philippe.cornu@st.com> - Philippe Cornu <philippe.cornu@foss.st.com>
- Yannick Fertre <yannick.fertre@st.com> - Yannick Fertre <yannick.fertre@foss.st.com>
description: description:
The STMicroelectronics STM32 DSI controller uses the Synopsys DesignWare MIPI-DSI host controller. The STMicroelectronics STM32 DSI controller uses the Synopsys DesignWare MIPI-DSI host controller.

4
Documentation/devicetree/bindings/display/st,stm32-ltdc.yaml
View File

@@ -7,8 +7,8 @@ $schema: http://devicetree.org/meta-schemas/core.yaml#
title: STMicroelectronics STM32 lcd-tft display controller title: STMicroelectronics STM32 lcd-tft display controller
maintainers: maintainers:
- Philippe Cornu <philippe.cornu@st.com> - Philippe Cornu <philippe.cornu@foss.st.com>
- Yannick Fertre <yannick.fertre@st.com> - Yannick Fertre <yannick.fertre@foss.st.com>
properties: properties:
compatible: compatible:

2
Documentation/devicetree/bindings/dma/ingenic,dma.yaml
View File

@@ -68,7 +68,7 @@ unevaluatedProperties: false
examples: examples:
- | - |
#include <dt-bindings/clock/jz4780-cgu.h> #include <dt-bindings/clock/ingenic,jz4780-cgu.h>
dma: dma-controller@13420000 { dma: dma-controller@13420000 {
compatible = "ingenic,jz4780-dma"; compatible = "ingenic,jz4780-dma";
reg = <0x13420000 0x400>, <0x13421000 0x40>; reg = <0x13420000 0x400>, <0x13421000 0x40>;

2
Documentation/devicetree/bindings/dma/qcom_bam_dma.txt
View File

@@ -15,6 +15,8 @@ Required properties:
the secure world. the secure world.
- qcom,controlled-remotely : optional, indicates that the bam is controlled by - qcom,controlled-remotely : optional, indicates that the bam is controlled by
remote proccessor i.e. execution environment. remote proccessor i.e. execution environment.
- qcom,powered-remotely : optional, indicates that the bam is powered up by
a remote processor but must be initialized by the local processor.
- num-channels : optional, indicates supported number of DMA channels in a - num-channels : optional, indicates supported number of DMA channels in a
remotely controlled bam. remotely controlled bam.
- qcom,num-ees : optional, indicates supported number of Execution Environments - qcom,num-ees : optional, indicates supported number of Execution Environments

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

@@ -50,7 +50,7 @@ description: |
maintainers: maintainers:
- Amelie Delaunay <amelie.delaunay@st.com> - Amelie Delaunay <amelie.delaunay@foss.st.com>
allOf: allOf:
- $ref: "dma-controller.yaml#" - $ref: "dma-controller.yaml#"

2
Documentation/devicetree/bindings/dma/st,stm32-dmamux.yaml
View File

@@ -7,7 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml#
title: STMicroelectronics STM32 DMA MUX (DMA request router) bindings title: STMicroelectronics STM32 DMA MUX (DMA request router) bindings
maintainers: maintainers:
- Amelie Delaunay <amelie.delaunay@st.com> - Amelie Delaunay <amelie.delaunay@foss.st.com>
allOf: allOf:
- $ref: "dma-router.yaml#" - $ref: "dma-router.yaml#"

2
Documentation/devicetree/bindings/dma/st,stm32-mdma.yaml
View File

@@ -50,7 +50,7 @@ description: |
if no HW ack signal is used by the MDMA client if no HW ack signal is used by the MDMA client
maintainers: maintainers:
- Amelie Delaunay <amelie.delaunay@st.com> - Amelie Delaunay <amelie.delaunay@foss.st.com>
allOf: allOf:
- $ref: "dma-controller.yaml#" - $ref: "dma-controller.yaml#"

123
Documentation/devicetree/bindings/dsp/fsl,dsp.yaml
View File

@@ -8,6 +8,7 @@ title: NXP i.MX8 DSP core
maintainers: maintainers:
- Daniel Baluta <daniel.baluta@nxp.com> - Daniel Baluta <daniel.baluta@nxp.com>
- Shengjiu Wang <shengjiu.wang@nxp.com>
description: | description: |
Some boards from i.MX8 family contain a DSP core used for Some boards from i.MX8 family contain a DSP core used for
@@ -19,6 +20,10 @@ properties:
- fsl,imx8qxp-dsp - fsl,imx8qxp-dsp
- fsl,imx8qm-dsp - fsl,imx8qm-dsp
- fsl,imx8mp-dsp - fsl,imx8mp-dsp
- fsl,imx8qxp-hifi4
- fsl,imx8qm-hifi4
- fsl,imx8mp-hifi4
- fsl,imx8ulp-hifi4
reg: reg:
maxItems: 1 maxItems: 1
@@ -28,37 +33,53 @@ properties:
- description: ipg clock - description: ipg clock
- description: ocram clock - description: ocram clock
- description: core clock - description: core clock
- description: debug interface clock
- description: message unit clock
minItems: 3
clock-names: clock-names:
items: items:
- const: ipg - const: ipg
- const: ocram - const: ocram
- const: core - const: core
- const: debug
- const: mu
minItems: 3
power-domains: power-domains:
description: description:
List of phandle and PM domain specifier as documented in List of phandle and PM domain specifier as documented in
Documentation/devicetree/bindings/power/power_domain.txt Documentation/devicetree/bindings/power/power_domain.txt
minItems: 1
maxItems: 4 maxItems: 4
mboxes: mboxes:
description: description:
List of <&phandle type channel> - 2 channels for TXDB, 2 channels for RXDB List of <&phandle type channel> - 2 channels for TXDB, 2 channels for RXDB
or - 1 channel for TX, 1 channel for RX, 1 channel for RXDB
(see mailbox/fsl,mu.txt) (see mailbox/fsl,mu.txt)
minItems: 3
maxItems: 4 maxItems: 4
mbox-names: mbox-names:
items: minItems: 3
- const: txdb0 maxItems: 4
- const: txdb1
- const: rxdb0
- const: rxdb1
memory-region: memory-region:
description: description:
phandle to a node describing reserved memory (System RAM memory) phandle to a node describing reserved memory (System RAM memory)
used by DSP (see bindings/reserved-memory/reserved-memory.txt) used by DSP (see bindings/reserved-memory/reserved-memory.txt)
maxItems: 1 minItems: 1
maxItems: 4
firmware-name:
description: |
Default name of the firmware to load to the remote processor.
fsl,dsp-ctrl:
$ref: /schemas/types.yaml#/definitions/phandle
description:
Phandle to syscon block which provide access for processor enablement
required: required:
- compatible - compatible
@@ -70,6 +91,58 @@ required:
- mbox-names - mbox-names
- memory-region - memory-region
allOf:
- if:
properties:
compatible:
contains:
enum:
- fsl,imx8qxp-dsp
- fsl,imx8qm-dsp
- fsl,imx8qxp-hifi4
- fsl,imx8qm-hifi4
then:
properties:
power-domains:
minItems: 4
else:
properties:
power-domains:
maxItems: 1
- if:
properties:
compatible:
contains:
enum:
- fsl,imx8qxp-hifi4
- fsl,imx8qm-hifi4
- fsl,imx8mp-hifi4
- fsl,imx8ulp-hifi4
then:
properties:
memory-region:
minItems: 4
mboxes:
maxItems: 3
mbox-names:
items:
- const: tx
- const: rx
- const: rxdb
else:
properties:
memory-region:
maxItems: 1
mboxes:
minItems: 4
mbox-names:
items:
- const: txdb0
- const: txdb1
- const: rxdb0
- const: rxdb1
additionalProperties: false additionalProperties: false
examples: examples:
@@ -91,3 +164,41 @@ examples:
mboxes = <&lsio_mu13 2 0>, <&lsio_mu13 2 1>, <&lsio_mu13 3 0>, <&lsio_mu13 3 1>; mboxes = <&lsio_mu13 2 0>, <&lsio_mu13 2 1>, <&lsio_mu13 3 0>, <&lsio_mu13 3 1>;
memory-region = <&dsp_reserved>; memory-region = <&dsp_reserved>;
}; };
- |
#include <dt-bindings/clock/imx8mp-clock.h>
dsp_reserved: dsp@92400000 {
reg = <0x92400000 0x1000000>;
no-map;
};
dsp_vdev0vring0: vdev0vring0@942f0000 {
reg = <0x942f0000 0x8000>;
no-map;
};
dsp_vdev0vring1: vdev0vring1@942f8000 {
reg = <0x942f8000 0x8000>;
no-map;
};
dsp_vdev0buffer: vdev0buffer@94300000 {
compatible = "shared-dma-pool";
reg = <0x94300000 0x100000>;
no-map;
};
dsp: dsp@3b6e8000 {
compatible = "fsl,imx8mp-hifi4";
reg = <0x3b6e8000 0x88000>;
clocks = <&audio_blk_ctrl IMX8MP_CLK_AUDIOMIX_DSP_ROOT>,
<&audio_blk_ctrl IMX8MP_CLK_AUDIOMIX_OCRAMA_IPG>,
<&audio_blk_ctrl IMX8MP_CLK_AUDIOMIX_DSP_ROOT>,
<&audio_blk_ctrl IMX8MP_CLK_AUDIOMIX_DSPDBG_ROOT>;
clock-names = "ipg", "ocram", "core", "debug";
firmware-name = "imx/dsp/hifi4.bin";
power-domains = <&audiomix_pd>;
mbox-names = "tx", "rx", "rxdb";
mboxes = <&mu2 0 0>,
<&mu2 1 0>,
<&mu2 3 0>;
memory-region = <&dsp_vdev0buffer>, <&dsp_vdev0vring0>,
<&dsp_vdev0vring1>, <&dsp_reserved>;
fsl,dsp-ctrl = <&audio_blk_ctrl>;
};

6
Documentation/devicetree/bindings/eeprom/at24.yaml
View File

@@ -97,6 +97,12 @@ properties:
- items: - items:
- const: nxp,se97b - const: nxp,se97b
- const: atmel,24c02 - const: atmel,24c02
- items:
- const: onnn,cat24c04
- const: atmel,24c04
- items:
- const: onnn,cat24c05
- const: atmel,24c04
- items: - items:
- const: renesas,r1ex24002 - const: renesas,r1ex24002
- const: atmel,24c02 - const: atmel,24c02

75
Documentation/devicetree/bindings/gpio/gpio-axp209.txt
View File

@@ -1,75 +0,0 @@
AXP209 GPIO & pinctrl controller
This driver follows the usual GPIO bindings found in
Documentation/devicetree/bindings/gpio/gpio.txt
This driver follows the usual pinctrl bindings found in
Documentation/devicetree/bindings/pinctrl/pinctrl-bindings.txt
This driver employs the per-pin muxing pattern.
Required properties:
- compatible: Should be one of:
- "x-powers,axp209-gpio"
- "x-powers,axp813-gpio"
- #gpio-cells: Should be two. The first cell is the pin number and the
second is the GPIO flags.
- gpio-controller: Marks the device node as a GPIO controller.
This node must be a subnode of the axp20x PMIC, documented in
Documentation/devicetree/bindings/mfd/axp20x.txt
Example:
axp209: pmic@34 {
compatible = "x-powers,axp209";
reg = <0x34>;
interrupt-parent = <&nmi_intc>;
interrupts = <0 IRQ_TYPE_LEVEL_LOW>;
interrupt-controller;
#interrupt-cells = <1>;
axp_gpio: gpio {
compatible = "x-powers,axp209-gpio";
gpio-controller;
#gpio-cells = <2>;
};
};
The GPIOs can be muxed to other functions and therefore, must be a subnode of
axp_gpio.
Example:
&axp_gpio {
gpio0_adc: gpio0-adc {
pins = "GPIO0";
function = "adc";
};
};
&example_node {
pinctrl-names = "default";
pinctrl-0 = <&gpio0_adc>;
};
GPIOs and their functions
-------------------------
Each GPIO is independent from the other (i.e. GPIO0 in gpio_in function does
not force GPIO1 and GPIO2 to be in gpio_in function as well).
axp209
------
GPIO | Functions
------------------------
GPIO0 | gpio_in, gpio_out, ldo, adc
GPIO1 | gpio_in, gpio_out, ldo, adc
GPIO2 | gpio_in, gpio_out
axp813
------
GPIO | Functions
------------------------
GPIO0 | gpio_in, gpio_out, ldo, adc
GPIO1 | gpio_in, gpio_out, ldo

49
Documentation/devicetree/bindings/gpio/gpio-xlp.txt
View File

@@ -1,49 +0,0 @@
Netlogic XLP Family GPIO
========================
This GPIO driver is used for following Netlogic XLP SoCs:
XLP832, XLP316, XLP208, XLP980, XLP532
This GPIO driver is also compatible with GPIO controller found on
Broadcom Vulcan ARM64.
Required properties:
-------------------
- compatible: Should be one of the following:
- "netlogic,xlp832-gpio": For Netlogic XLP832
- "netlogic,xlp316-gpio": For Netlogic XLP316
- "netlogic,xlp208-gpio": For Netlogic XLP208
- "netlogic,xlp980-gpio": For Netlogic XLP980
- "netlogic,xlp532-gpio": For Netlogic XLP532
- "brcm,vulcan-gpio": For Broadcom Vulcan ARM64
- reg: Physical base address and length of the controller's registers.
- #gpio-cells: Should be two. The first cell is the pin number and the second
cell is used to specify optional parameters (currently unused).
- gpio-controller: Marks the device node as a GPIO controller.
- nr-gpios: Number of GPIO pins supported by the controller.
- interrupt-cells: Should be two. The first cell is the GPIO Number. The
second cell is used to specify flags. The following subset of flags is
supported:
- trigger type:
1 = low to high edge triggered.
2 = high to low edge triggered.
4 = active high level-sensitive.
8 = active low level-sensitive.
- interrupts: Interrupt number for this device.
- interrupt-controller: Identifies the node as an interrupt controller.
Example:
gpio: xlp_gpio@34000 {
compatible = "netlogic,xlp316-gpio";
reg = <0 0x34100 0x1000
0 0x35100 0x1000>;
#gpio-cells = <2>;
gpio-controller;
nr-gpios = <57>;
#interrupt-cells = <2>;
interrupt-parent = <&pic>;
interrupts = <39>;
interrupt-controller;
};

2
Documentation/devicetree/bindings/gpio/rockchip,gpio-bank.yaml
View File

@@ -29,6 +29,8 @@ properties:
gpio-controller: true gpio-controller: true
gpio-line-names: true
"#gpio-cells": "#gpio-cells":
const: 2 const: 2

55
Documentation/devicetree/bindings/gpio/x-powers,axp209-gpio.yaml Normal file
View File

@@ -0,0 +1,55 @@
# SPDX-License-Identifier: GPL-2.0
%YAML 1.2
---
$id: "http://devicetree.org/schemas/gpio/x-powers,axp209-gpio.yaml#"
$schema: "http://devicetree.org/meta-schemas/core.yaml#"
title: X-Powers AXP209 GPIO Device Tree Bindings
maintainers:
- Chen-Yu Tsai <wens@csie.org>
properties:
"#gpio-cells":
const: 2
description: >
The first cell is the pin number and the second is the GPIO flags.
compatible:
oneOf:
- enum:
- x-powers,axp209-gpio
- x-powers,axp813-gpio
- items:
- const: x-powers,axp803-gpio
- const: x-powers,axp813-gpio
gpio-controller: true
patternProperties:
"^.*-pins?$":
$ref: /schemas/pinctrl/pinmux-node.yaml#
properties:
pins:
items:
enum:
- GPIO0
- GPIO1
- GPIO2
function:
enum:
- adc
- ldo
- gpio_in
- gpio_out
required:
- compatible
- "#gpio-cells"
- gpio-controller
additionalProperties: false
...

43
Documentation/devicetree/bindings/gpio/xlnx,zynqmp-gpio-modepin.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/gpio/xlnx,zynqmp-gpio-modepin.yaml#"
$schema: "http://devicetree.org/meta-schemas/core.yaml#"
title: ZynqMP Mode Pin GPIO controller
description:
PS_MODE is 4-bits boot mode pins sampled on POR deassertion. Mode Pin
GPIO controller with configurable from numbers of pins (from 0 to 3 per
PS_MODE). Every pin can be configured as input/output.
maintainers:
- Piyush Mehta <piyush.mehta@xilinx.com>
properties:
compatible:
const: xlnx,zynqmp-gpio-modepin
gpio-controller: true
"#gpio-cells":
const: 2
required:
- compatible
- gpio-controller
- "#gpio-cells"
additionalProperties: false
examples:
- |
zynqmp-firmware {
gpio {
compatible = "xlnx,zynqmp-gpio-modepin";
gpio-controller;
#gpio-cells = <2>;
};
};
...

3
Documentation/devicetree/bindings/hwlock/st,stm32-hwspinlock.yaml
View File

@@ -7,8 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml#
title: STMicroelectronics STM32 Hardware Spinlock bindings title: STMicroelectronics STM32 Hardware Spinlock bindings
maintainers: maintainers:
- Benjamin Gaignard <benjamin.gaignard@st.com> - Fabien Dessenne <fabien.dessenne@foss.st.com>
- Fabien Dessenne <fabien.dessenne@st.com>
properties: properties:
"#hwlock-cells": "#hwlock-cells":

2
Documentation/devicetree/bindings/i2c/allwinner,sun6i-a31-p2wi.yaml
View File

@@ -55,7 +55,7 @@ examples:
#size-cells = <0>; #size-cells = <0>;
axp221: pmic@68 { axp221: pmic@68 {
compatible = "x-powers,axp221"; /* compatible = "x-powers,axp221"; */
reg = <0x68>; reg = <0x68>;
}; };
}; };

61
Documentation/devicetree/bindings/i2c/apple,i2c.yaml Normal file
View File

@@ -0,0 +1,61 @@
# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
%YAML 1.2
---
$id: "http://devicetree.org/schemas/i2c/apple,i2c.yaml#"
$schema: "http://devicetree.org/meta-schemas/core.yaml#"
title: Apple/PASemi I2C controller
maintainers:
- Sven Peter <sven@svenpeter.dev>
description: |
Apple SoCs such as the M1 come with a I2C controller based on the one found
in machines with P. A. Semi's PWRficient processors.
The bus is used to communicate with e.g. USB PD chips or the speaker
amp.
allOf:
- $ref: /schemas/i2c/i2c-controller.yaml#
properties:
compatible:
enum:
- apple,t8103-i2c
- apple,i2c
reg:
maxItems: 1
clocks:
items:
- description: I2C bus reference clock
interrupts:
maxItems: 1
clock-frequency:
description: |
Desired I2C bus clock frequency in Hz. If not specified, 100 kHz will be
used. This frequency is generated by dividing the reference clock.
Allowed values are between ref_clk/(16*4) and ref_clk/(16*255).
required:
- compatible
- reg
- clocks
- interrupts
unevaluatedProperties: false
examples:
- |
i2c@35010000 {
compatible = "apple,t8103-i2c";
reg = <0x35010000 0x4000>;
interrupt-parent = <&aic>;
interrupts = <0 627 4>;
clocks = <&ref_clk>;
#address-cells = <1>;
#size-cells = <0>;
};

4
Documentation/devicetree/bindings/i2c/i2c-imx.yaml
View File

@@ -57,7 +57,9 @@ properties:
const: ipg const: ipg
clock-frequency: clock-frequency:
enum: [ 100000, 400000 ] minimum: 1
default: 100000
maximum: 400000
dmas: dmas:
items: items:

22
Documentation/devicetree/bindings/i2c/i2c-xlp9xx.txt
View File

@@ -1,22 +0,0 @@
Device tree configuration for the I2C controller on the XLP9xx/5xx SoC
Required properties:
- compatible : should be "netlogic,xlp980-i2c"
- reg : bus address start and address range size of device
- interrupts : interrupt number
Optional properties:
- clock-frequency : frequency of bus clock in Hz
Defaults to 100 KHz when the property is not specified
Example:
i2c0: i2c@113100 {
compatible = "netlogic,xlp980-i2c";
#address-cells = <1>;
#size-cells = <0>;
reg = <0 0x113100 0x100>;
clock-frequency = <400000>;
interrupts = <30>;
interrupt-parent = <&pic>;
};

2
Documentation/devicetree/bindings/i2c/ingenic,i2c.yaml
View File

@@ -60,7 +60,7 @@ unevaluatedProperties: false
examples: examples:
- | - |
#include <dt-bindings/clock/jz4780-cgu.h> #include <dt-bindings/clock/ingenic,jz4780-cgu.h>
#include <dt-bindings/dma/jz4780-dma.h> #include <dt-bindings/dma/jz4780-dma.h>
#include <dt-bindings/interrupt-controller/irq.h> #include <dt-bindings/interrupt-controller/irq.h>
i2c@10054000 { i2c@10054000 {

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

@@ -7,7 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml#
title: I2C controller embedded in STMicroelectronics STM32 I2C platform title: I2C controller embedded in STMicroelectronics STM32 I2C platform
maintainers: maintainers:
- Pierre-Yves MORDRET <pierre-yves.mordret@st.com> - Pierre-Yves MORDRET <pierre-yves.mordret@foss.st.com>
allOf: allOf:
- $ref: /schemas/i2c/i2c-controller.yaml# - $ref: /schemas/i2c/i2c-controller.yaml#

2
Documentation/devicetree/bindings/iio/adc/ingenic,adc.yaml
View File

@@ -74,7 +74,7 @@ additionalProperties: false
examples: examples:
- | - |
#include <dt-bindings/clock/jz4740-cgu.h> #include <dt-bindings/clock/ingenic,jz4740-cgu.h>
#include <dt-bindings/iio/adc/ingenic,adc.h> #include <dt-bindings/iio/adc/ingenic,adc.h>
adc@10070000 { adc@10070000 {

2
Documentation/devicetree/bindings/iio/adc/sigma-delta-modulator.yaml
View File

@@ -7,7 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml#
title: Device-Tree bindings for sigma delta modulator title: Device-Tree bindings for sigma delta modulator
maintainers: maintainers:
- Arnaud Pouliquen <arnaud.pouliquen@st.com> - Arnaud Pouliquen <arnaud.pouliquen@foss.st.com>
properties: properties:
compatible: compatible:

2
Documentation/devicetree/bindings/iio/adc/st,stm32-adc.yaml
View File

@@ -19,7 +19,7 @@ description: |
Each STM32 ADC block can have up to 3 ADC instances. Each STM32 ADC block can have up to 3 ADC instances.
maintainers: maintainers:
- Fabrice Gasnier <fabrice.gasnier@st.com> - Fabrice Gasnier <fabrice.gasnier@foss.st.com>
properties: properties:
compatible: compatible:

4
Documentation/devicetree/bindings/iio/adc/st,stm32-dfsdm-adc.yaml
View File

@@ -7,8 +7,8 @@ $schema: http://devicetree.org/meta-schemas/core.yaml#
title: STMicroelectronics STM32 DFSDM ADC device driver title: STMicroelectronics STM32 DFSDM ADC device driver
maintainers: maintainers:
- Fabrice Gasnier <fabrice.gasnier@st.com> - Fabrice Gasnier <fabrice.gasnier@foss.st.com>
- Olivier Moysan <olivier.moysan@st.com> - Olivier Moysan <olivier.moysan@foss.st.com>
description: | description: |
STM32 DFSDM ADC is a sigma delta analog-to-digital converter dedicated to STM32 DFSDM ADC is a sigma delta analog-to-digital converter dedicated to

70
Documentation/devicetree/bindings/iio/adc/ti,am3359-adc.yaml Normal file
View File

@@ -0,0 +1,70 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/iio/adc/ti,am3359-adc.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: TI AM3359 ADC
maintainers:
- Miquel Raynal <miquel.raynal@bootlin.com>
properties:
compatible:
enum:
- ti,am3359-adc
- ti,am4372-adc
'#io-channel-cells':
const: 1
ti,adc-channels:
description: List of analog inputs available for ADC. AIN0 = 0, AIN1 = 1 and
so on until AIN7 = 7.
$ref: /schemas/types.yaml#/definitions/uint32-array
minItems: 1
maxItems: 8
ti,chan-step-opendelay:
description: List of open delays for each channel of ADC in the order of
ti,adc-channels. The value corresponds to the number of ADC clock cycles
to wait after applying the step configuration registers and before sending
the start of ADC conversion. Maximum value is 0x3FFFF.
$ref: /schemas/types.yaml#/definitions/uint32-array
minItems: 1
maxItems: 8
ti,chan-step-sampledelay:
description: List of sample delays for each channel of ADC in the order of
ti,adc-channels. The value corresponds to the number of ADC clock cycles
to sample (to hold start of conversion high). Maximum value is 0xFF.
$ref: /schemas/types.yaml#/definitions/uint32-array
minItems: 1
maxItems: 8
ti,chan-step-avg:
description: Number of averages to be performed for each channel of ADC. If
average is 16 (this is also the maximum) then input is sampled 16 times
and averaged to get more accurate value. This increases the time taken by
ADC to generate a sample. Maximum value is 16.
$ref: /schemas/types.yaml#/definitions/uint32-array
minItems: 1
maxItems: 8
required:
- compatible
- '#io-channel-cells'
- ti,adc-channels
additionalProperties: false
examples:
- |
adc {
compatible = "ti,am3359-adc";
#io-channel-cells = <1>;
ti,adc-channels = <4 5 6 7>;
ti,chan-step-opendelay = <0x098 0x3ffff 0x098 0x0>;
ti,chan-step-sampledelay = <0xff 0x0 0xf 0x0>;
ti,chan-step-avg = <16 2 4 8>;
};

2
Documentation/devicetree/bindings/iio/dac/st,stm32-dac.yaml
View File

@@ -15,7 +15,7 @@ description: |
current. current.
maintainers: maintainers:
- Fabrice Gasnier <fabrice.gasnier@st.com> - Fabrice Gasnier <fabrice.gasnier@foss.st.com>
properties: properties:
compatible: compatible:

61
Documentation/devicetree/bindings/input/cypress-sf.yaml Normal file
View File

@@ -0,0 +1,61 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/input/cypress-sf.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Cypress StreetFighter touchkey controller
maintainers:
- Yassine Oudjana <y.oudjana@protonmail.com>
allOf:
- $ref: input.yaml#
properties:
compatible:
const: cypress,sf3155
reg:
maxItems: 1
interrupts:
maxItems: 1
avdd-supply:
description: Regulator for AVDD analog voltage
vdd-supply:
description: Regulator for VDD digital voltage
linux,keycodes:
minItems: 1
maxItems: 8
required:
- compatible
- reg
- interrupts
- avdd-supply
- vdd-supply
additionalProperties: false
examples:
- |
#include <dt-bindings/input/input.h>
#include <dt-bindings/interrupt-controller/irq.h>
i2c {
#address-cells = <1>;
#size-cells = <0>;
touchkey@28 {
compatible = "cypress,sf3155";
reg = <0x28>;
interrupt-parent = <&msmgpio>;
interrupts = <77 IRQ_TYPE_EDGE_FALLING>;
avdd-supply = <&vreg_l6a_1p8>;
vdd-supply = <&vdd_3v2_tp>;
linux,keycodes = <KEY_BACK KEY_MENU>;
};
};

2
Documentation/devicetree/bindings/input/hid-over-i2c.txt
View File

@@ -32,6 +32,8 @@ device-specific compatible properties, which should be used in addition to the
- vdd-supply: phandle of the regulator that provides the supply voltage. - vdd-supply: phandle of the regulator that provides the supply voltage.
- post-power-on-delay-ms: time required by the device after enabling its regulators - post-power-on-delay-ms: time required by the device after enabling its regulators
or powering it on, before it is ready for communication. or powering it on, before it is ready for communication.
- touchscreen-inverted-x: See touchscreen.txt
- touchscreen-inverted-y: See touchscreen.txt
Example: Example:

1
Documentation/devicetree/bindings/input/microchip,cap11xx.yaml
View File

@@ -19,6 +19,7 @@ properties:
- microchip,cap1106 - microchip,cap1106
- microchip,cap1126 - microchip,cap1126
- microchip,cap1188 - microchip,cap1188
- microchip,cap1206
reg: reg:
maxItems: 1 maxItems: 1

76
Documentation/devicetree/bindings/input/touchscreen/ti,am3359-tsc.yaml Normal file
View File

@@ -0,0 +1,76 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/input/touchscreen/ti,am3359-tsc.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: TI AM3359 Touchscreen controller
maintainers:
- Miquel Raynal <miquel.raynal@bootlin.com>
properties:
compatible:
const: ti,am3359-tsc
ti,wires:
description: Wires refer to application modes i.e. 4/5/8 wire touchscreen
support on the platform.
$ref: /schemas/types.yaml#/definitions/uint32
enum: [4, 5, 8]
ti,x-plate-resistance:
description: X plate resistance
$ref: /schemas/types.yaml#/definitions/uint32
ti,coordinate-readouts:
description: The sequencer supports a total of 16 programmable steps. Each
step is used to read a single coordinate. A single readout is enough but
multiple reads can increase the quality. A value of 5 means, 5 reads for
X, 5 for Y and 2 for Z (always). This utilises 12 of the 16 software steps
available. The remaining 4 can be used by the ADC.
$ref: /schemas/types.yaml#/definitions/uint32
minimum: 1
maximum: 6
ti,wire-config:
description: Different boards could have a different order for connecting
wires on touchscreen. We need to provide an 8-bit number where the
first four bits represent the analog lines and the next 4 bits represent
positive/negative terminal on that input line. Notations to represent the
input lines and terminals respectively are as follows, AIN0 = 0, AIN1 = 1
and so on until AIN7 = 7. XP = 0, XN = 1, YP = 2, YN = 3.
$ref: /schemas/types.yaml#/definitions/uint32-array
minItems: 4
maxItems: 8
ti,charge-delay:
description: Length of touch screen charge delay step in terms of ADC clock
cycles. Charge delay value should be large in order to avoid false pen-up
events. This value effects the overall sampling speed, hence need to be
kept as low as possible, while avoiding false pen-up event. Start from a
lower value, say 0x400, and increase value until false pen-up events are
avoided. The pen-up detection happens immediately after the charge step,
so this does in fact function as a hardware knob for adjusting the amount
of "settling time".
$ref: /schemas/types.yaml#/definitions/uint32
required:
- compatible
- ti,wires
- ti,x-plate-resistance
- ti,coordinate-readouts
- ti,wire-config
additionalProperties: false
examples:
- |
tsc {
compatible = "ti,am3359-tsc";
ti,wires = <4>;
ti,x-plate-resistance = <200>;
ti,coordinate-readouts = <5>;
ti,wire-config = <0x00 0x11 0x22 0x33>;
ti,charge-delay = <0x400>;
};

91
Documentation/devicetree/bindings/input/touchscreen/ti-tsc-adc.txt
View File

@@ -1,91 +0,0 @@
* TI - TSC ADC (Touschscreen and analog digital converter)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Required properties:
- mfd
compatible: Should be
"ti,am3359-tscadc" for AM335x/AM437x SoCs
"ti,am654-tscadc", "ti,am3359-tscadc" for AM654 SoCs
- child "tsc"
compatible: Should be "ti,am3359-tsc".
ti,wires: Wires refer to application modes i.e. 4/5/8 wire touchscreen
support on the platform.
ti,x-plate-resistance: X plate resistance
ti,coordinate-readouts: The sequencer supports a total of 16
programmable steps each step is used to
read a single coordinate. A single
readout is enough but multiple reads can
increase the quality.
A value of 5 means, 5 reads for X, 5 for
Y and 2 for Z (always). This utilises 12
of the 16 software steps available. The
remaining 4 can be used by the ADC.
ti,wire-config: Different boards could have a different order for
connecting wires on touchscreen. We need to provide an
8 bit number where in the 1st four bits represent the
analog lines and the next 4 bits represent positive/
negative terminal on that input line. Notations to
represent the input lines and terminals resoectively
is as follows:
AIN0 = 0, AIN1 = 1 and so on till AIN7 = 7.
XP = 0, XN = 1, YP = 2, YN = 3.
- child "adc"
compatible: Should be
"ti,am3359-adc" for AM335x/AM437x SoCs
"ti,am654-adc", "ti,am3359-adc" for AM654 SoCs
ti,adc-channels: List of analog inputs available for ADC.
AIN0 = 0, AIN1 = 1 and so on till AIN7 = 7.
Optional properties:
- child "tsc"
ti,charge-delay: Length of touch screen charge delay step in terms of
ADC clock cycles. Charge delay value should be large
in order to avoid false pen-up events. This value
effects the overall sampling speed, hence need to be
kept as low as possible, while avoiding false pen-up
event. Start from a lower value, say 0x400, and
increase value until false pen-up events are avoided.
The pen-up detection happens immediately after the
charge step, so this does in fact function as a
hardware knob for adjusting the amount of "settling
time".
- child "adc"
ti,chan-step-opendelay: List of open delays for each channel of
ADC in the order of ti,adc-channels. The
value corresponds to the number of ADC
clock cycles to wait after applying the
step configuration registers and before
sending the start of ADC conversion.
Maximum value is 0x3FFFF.
ti,chan-step-sampledelay: List of sample delays for each channel
of ADC in the order of ti,adc-channels.
The value corresponds to the number of
ADC clock cycles to sample (to hold
start of conversion high).
Maximum value is 0xFF.
ti,chan-step-avg: Number of averages to be performed for each
channel of ADC. If average is 16 then input
is sampled 16 times and averaged to get more
accurate value. This increases the time taken
by ADC to generate a sample. Valid range is 0
average to 16 averages. Maximum value is 16.
Example:
tscadc: tscadc@44e0d000 {
compatible = "ti,am3359-tscadc";
tsc {
ti,wires = <4>;
ti,x-plate-resistance = <200>;
ti,coordiante-readouts = <5>;
ti,wire-config = <0x00 0x11 0x22 0x33>;
ti,charge-delay = <0x400>;
};
adc {
ti,adc-channels = <4 5 6 7>;
ti,chan-step-opendelay = <0x098 0x3ffff 0x098 0x0>;
ti,chan-step-sampledelay = <0xff 0x0 0xf 0x0>;
ti,chan-step-avg = <16 2 4 8>;
};
}

4
Documentation/devicetree/bindings/interrupt-controller/st,stm32-exti.yaml
View File

@@ -7,8 +7,8 @@ $schema: http://devicetree.org/meta-schemas/core.yaml#
title: STM32 External Interrupt Controller Device Tree Bindings title: STM32 External Interrupt Controller Device Tree Bindings
maintainers: maintainers:
- Alexandre Torgue <alexandre.torgue@st.com> - Alexandre Torgue <alexandre.torgue@foss.st.com>
- Ludovic Barre <ludovic.barre@st.com> - Ludovic Barre <ludovic.barre@foss.st.com>
properties: properties:
compatible: compatible:

4
Documentation/devicetree/bindings/mailbox/st,stm32-ipcc.yaml
View File

@@ -13,8 +13,8 @@ description:
channels (N) can be read from a dedicated register. channels (N) can be read from a dedicated register.
maintainers: maintainers:
- Fabien Dessenne <fabien.dessenne@st.com> - Fabien Dessenne <fabien.dessenne@foss.st.com>
- Arnaud Pouliquen <arnaud.pouliquen@st.com> - Arnaud Pouliquen <arnaud.pouliquen@foss.st.com>
properties: properties:
compatible: compatible:

1
Documentation/devicetree/bindings/media/qcom,sc7280-venus.yaml
View File

@@ -30,7 +30,6 @@ properties:
power-domain-names: power-domain-names:
minItems: 2 minItems: 2
maxItems: 3
items: items:
- const: venus - const: venus
- const: vcodec0 - const: vcodec0

3
Documentation/devicetree/bindings/media/st,stm32-cec.yaml
View File

@@ -7,8 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml#
title: STMicroelectronics STM32 CEC bindings title: STMicroelectronics STM32 CEC bindings
maintainers: maintainers:
- Benjamin Gaignard <benjamin.gaignard@st.com> - Yannick Fertre <yannick.fertre@foss.st.com>
- Yannick Fertre <yannick.fertre@st.com>
properties: properties:
compatible: compatible:

2
Documentation/devicetree/bindings/media/st,stm32-dcmi.yaml
View File

@@ -7,7 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml#
title: STMicroelectronics STM32 Digital Camera Memory Interface (DCMI) binding title: STMicroelectronics STM32 Digital Camera Memory Interface (DCMI) binding
maintainers: maintainers:
- Hugues Fruchet <hugues.fruchet@st.com> - Hugues Fruchet <hugues.fruchet@foss.st.com>
properties: properties:
compatible: compatible:

2
Documentation/devicetree/bindings/memory-controllers/ingenic,nemc.yaml
View File

@@ -84,7 +84,7 @@ additionalProperties: false
examples: examples:
- | - |
#include <dt-bindings/clock/jz4780-cgu.h> #include <dt-bindings/clock/ingenic,jz4780-cgu.h>
#include <dt-bindings/gpio/gpio.h> #include <dt-bindings/gpio/gpio.h>
nemc: memory-controller@13410000 { nemc: memory-controller@13410000 {
compatible = "ingenic,jz4780-nemc"; compatible = "ingenic,jz4780-nemc";

2
Documentation/devicetree/bindings/memory-controllers/st,stm32-fmc2-ebi.yaml
View File

@@ -19,7 +19,7 @@ description: |
Select. The FMC2 performs only one access at a time to an external device. Select. The FMC2 performs only one access at a time to an external device.
maintainers: maintainers:
- Christophe Kerello <christophe.kerello@st.com> - Christophe Kerello <christophe.kerello@foss.st.com>
properties: properties:
compatible: compatible:

50
Documentation/devicetree/bindings/mfd/ac100.txt
View File

@@ -1,50 +0,0 @@
X-Powers AC100 Codec/RTC IC Device Tree bindings
AC100 is a audio codec and RTC subsystem combo IC. The 2 parts are
separated, including power supplies and interrupt lines, but share
a common register address space and host interface.
Required properties:
- compatible: "x-powers,ac100"
- reg: The I2C slave address or RSB hardware address for the chip
- sub-nodes:
- codec
- compatible: "x-powers,ac100-codec"
- interrupts: SoC NMI / GPIO interrupt connected to the
IRQ_AUDIO pin
- #clock-cells: Shall be 0
- clock-output-names: "4M_adda"
- see clock/clock-bindings.txt for common clock bindings
- rtc
- compatible: "x-powers,ac100-rtc"
- clocks: A phandle to the codec's "4M_adda" clock
- #clock-cells: Shall be 1
- clock-output-names: "cko1_rtc", "cko2_rtc", "cko3_rtc"
- see clock/clock-bindings.txt for common clock bindings
Example:
ac100: codec@e89 {
compatible = "x-powers,ac100";
reg = <0xe89>;
ac100_codec: codec {
compatible = "x-powers,ac100-codec";
interrupt-parent = <&r_pio>;
interrupts = <0 9 IRQ_TYPE_LEVEL_LOW>; /* PL9 */
#clock-cells = <0>;
clock-output-names = "4M_adda";
};
ac100_rtc: rtc {
compatible = "x-powers,ac100-rtc";
interrupt-parent = <&nmi_intc>;
interrupts = <0 IRQ_TYPE_LEVEL_LOW>;
clocks = <&ac100_codec>;
#clock-cells = <1>;
clock-output-names = "cko1_rtc", "cko2_rtc", "cko3_rtc";
};
};

273
Documentation/devicetree/bindings/mfd/axp20x.txt
View File

@@ -1,273 +0,0 @@
AXP family PMIC device tree bindings
The axp20x family current members :
axp152 (X-Powers)
axp202 (X-Powers)
axp209 (X-Powers)
axp221 (X-Powers)
axp223 (X-Powers)
axp803 (X-Powers)
axp806 (X-Powers)
axp809 (X-Powers)
axp813 (X-Powers)
The AXP813 is 2 chips packaged into 1. The 2 chips do not share anything
other than the packaging. Pins are routed separately. As such they should
be treated as separate entities. The other half is an AC100 RTC/codec
combo chip. Please see ./ac100.txt for its bindings.
Required properties:
- compatible: should be one of:
* "x-powers,axp152"
* "x-powers,axp202"
* "x-powers,axp209"
* "x-powers,axp221"
* "x-powers,axp223"
* "x-powers,axp803"
* "x-powers,axp806"
* "x-powers,axp805", "x-powers,axp806"
* "x-powers,axp305", "x-powers,axp805", "x-powers,axp806"
* "x-powers,axp809"
* "x-powers,axp813"
- reg: The I2C slave address or RSB hardware address for the AXP chip
- interrupt-controller: The PMIC has its own internal IRQs
- #interrupt-cells: Should be set to 1
Supported common regulator properties, see ../regulator/regulator.txt for
more information:
- regulator-ramp-delay: sets the ramp up delay in uV/us
AXP20x/DCDC2: 1600, 800
AXP20x/LDO3: 1600, 800
- regulator-soft-start: enable the output at the lowest possible voltage and
only then set the desired voltage
AXP20x/LDO3: software-based implementation
Optional properties:
- interrupts: SoC NMI / GPIO interrupt connected to the PMIC's IRQ pin
- x-powers,dcdc-freq: defines the work frequency of DC-DC in KHz
AXP152/20X: range: 750-1875, Default: 1.5 MHz
AXP22X/8XX: range: 1800-4050, Default: 3 MHz
- x-powers,drive-vbus-en: boolean, set this when the N_VBUSEN pin is
used as an output pin to control an external
regulator to drive the OTG VBus, rather then
as an input pin which signals whether the
board is driving OTG VBus or not.
(axp221 / axp223 / axp803/ axp813 only)
- x-powers,self-working-mode and
x-powers,master-mode: Boolean (axp806 only). Set either of these when the
PMIC is wired for self-working mode or master mode.
If neither is set then slave mode is assumed.
This corresponds to how the MODESET pin is wired.
- <input>-supply: a phandle to the regulator supply node. May be omitted if
inputs are unregulated, such as using the IPSOUT output
from the PMIC.
- regulators: A node that houses a sub-node for each regulator. Regulators
not used but preferred to be managed by the OS should be
listed as well.
See Documentation/devicetree/bindings/regulator/regulator.txt
for more information on standard regulator bindings.
Optional properties for DCDC regulators:
- x-powers,dcdc-workmode: 1 for PWM mode, 0 for AUTO (PWM/PFM) mode
Default: Current hardware setting
The DCDC regulators work in a mixed PWM/PFM mode,
using PFM under light loads and switching to PWM
for heavier loads. Forcing PWM mode trades efficiency
under light loads for lower output noise. This
probably makes sense for HiFi audio related
applications that aren't battery constrained.
AXP202/AXP209 regulators, type, and corresponding input supply names:
Regulator Type Supply Name Notes
--------- ---- ----------- -----
DCDC2 : DC-DC buck : vin2-supply
DCDC3 : DC-DC buck : vin3-supply
LDO1 : LDO : acin-supply : always on
LDO2 : LDO : ldo24in-supply : shared supply
LDO3 : LDO : ldo3in-supply
LDO4 : LDO : ldo24in-supply : shared supply
LDO5 : LDO : ldo5in-supply
AXP221/AXP223 regulators, type, and corresponding input supply names:
Regulator Type Supply Name Notes
--------- ---- ----------- -----
DCDC1 : DC-DC buck : vin1-supply
DCDC2 : DC-DC buck : vin2-supply
DCDC3 : DC-DC buck : vin3-supply
DCDC4 : DC-DC buck : vin4-supply
DCDC5 : DC-DC buck : vin5-supply
DC1SW : On/Off Switch : : DCDC1 secondary output
DC5LDO : LDO : : input from DCDC5
ALDO1 : LDO : aldoin-supply : shared supply
ALDO2 : LDO : aldoin-supply : shared supply
ALDO3 : LDO : aldoin-supply : shared supply
DLDO1 : LDO : dldoin-supply : shared supply
DLDO2 : LDO : dldoin-supply : shared supply
DLDO3 : LDO : dldoin-supply : shared supply
DLDO4 : LDO : dldoin-supply : shared supply
ELDO1 : LDO : eldoin-supply : shared supply
ELDO2 : LDO : eldoin-supply : shared supply
ELDO3 : LDO : eldoin-supply : shared supply
LDO_IO0 : LDO : ips-supply : GPIO 0
LDO_IO1 : LDO : ips-supply : GPIO 1
RTC_LDO : LDO : ips-supply : always on
DRIVEVBUS : Enable output : drivevbus-supply : external regulator
AXP803 regulators, type, and corresponding input supply names:
Regulator Type Supply Name Notes
--------- ---- ----------- -----
DCDC1 : DC-DC buck : vin1-supply
DCDC2 : DC-DC buck : vin2-supply : poly-phase capable
DCDC3 : DC-DC buck : vin3-supply : poly-phase capable
DCDC4 : DC-DC buck : vin4-supply
DCDC5 : DC-DC buck : vin5-supply : poly-phase capable
DCDC6 : DC-DC buck : vin6-supply : poly-phase capable
DC1SW : On/Off Switch : : DCDC1 secondary output
ALDO1 : LDO : aldoin-supply : shared supply
ALDO2 : LDO : aldoin-supply : shared supply
ALDO3 : LDO : aldoin-supply : shared supply
DLDO1 : LDO : dldoin-supply : shared supply
DLDO2 : LDO : dldoin-supply : shared supply
DLDO3 : LDO : dldoin-supply : shared supply
DLDO4 : LDO : dldoin-supply : shared supply
ELDO1 : LDO : eldoin-supply : shared supply
ELDO2 : LDO : eldoin-supply : shared supply
ELDO3 : LDO : eldoin-supply : shared supply
FLDO1 : LDO : fldoin-supply : shared supply
FLDO2 : LDO : fldoin-supply : shared supply
LDO_IO0 : LDO : ips-supply : GPIO 0
LDO_IO1 : LDO : ips-supply : GPIO 1
RTC_LDO : LDO : ips-supply : always on
DRIVEVBUS : Enable output : drivevbus-supply : external regulator
AXP806 regulators, type, and corresponding input supply names:
Regulator Type Supply Name Notes
--------- ---- ----------- -----
DCDCA : DC-DC buck : vina-supply : poly-phase capable
DCDCB : DC-DC buck : vinb-supply : poly-phase capable
DCDCC : DC-DC buck : vinc-supply : poly-phase capable
DCDCD : DC-DC buck : vind-supply : poly-phase capable
DCDCE : DC-DC buck : vine-supply : poly-phase capable
ALDO1 : LDO : aldoin-supply : shared supply
ALDO2 : LDO : aldoin-supply : shared supply
ALDO3 : LDO : aldoin-supply : shared supply
BLDO1 : LDO : bldoin-supply : shared supply
BLDO2 : LDO : bldoin-supply : shared supply
BLDO3 : LDO : bldoin-supply : shared supply
BLDO4 : LDO : bldoin-supply : shared supply
CLDO1 : LDO : cldoin-supply : shared supply
CLDO2 : LDO : cldoin-supply : shared supply
CLDO3 : LDO : cldoin-supply : shared supply
SW : On/Off Switch : swin-supply
Additionally, the AXP806 DC-DC regulators support poly-phase arrangements
for higher output current. The possible groupings are: A+B, A+B+C, D+E.
AXP809 regulators, type, and corresponding input supply names:
Regulator Type Supply Name Notes
--------- ---- ----------- -----
DCDC1 : DC-DC buck : vin1-supply
DCDC2 : DC-DC buck : vin2-supply
DCDC3 : DC-DC buck : vin3-supply
DCDC4 : DC-DC buck : vin4-supply
DCDC5 : DC-DC buck : vin5-supply
DC1SW : On/Off Switch : : DCDC1 secondary output
DC5LDO : LDO : : input from DCDC5
ALDO1 : LDO : aldoin-supply : shared supply
ALDO2 : LDO : aldoin-supply : shared supply
ALDO3 : LDO : aldoin-supply : shared supply
DLDO1 : LDO : dldoin-supply : shared supply
DLDO2 : LDO : dldoin-supply : shared supply
ELDO1 : LDO : eldoin-supply : shared supply
ELDO2 : LDO : eldoin-supply : shared supply
ELDO3 : LDO : eldoin-supply : shared supply
LDO_IO0 : LDO : ips-supply : GPIO 0
LDO_IO1 : LDO : ips-supply : GPIO 1
RTC_LDO : LDO : ips-supply : always on
SW : On/Off Switch : swin-supply
AXP813 regulators, type, and corresponding input supply names:
Regulator Type Supply Name Notes
--------- ---- ----------- -----
DCDC1 : DC-DC buck : vin1-supply
DCDC2 : DC-DC buck : vin2-supply : poly-phase capable
DCDC3 : DC-DC buck : vin3-supply : poly-phase capable
DCDC4 : DC-DC buck : vin4-supply
DCDC5 : DC-DC buck : vin5-supply : poly-phase capable
DCDC6 : DC-DC buck : vin6-supply : poly-phase capable
DCDC7 : DC-DC buck : vin7-supply
ALDO1 : LDO : aldoin-supply : shared supply
ALDO2 : LDO : aldoin-supply : shared supply
ALDO3 : LDO : aldoin-supply : shared supply
DLDO1 : LDO : dldoin-supply : shared supply
DLDO2 : LDO : dldoin-supply : shared supply
DLDO3 : LDO : dldoin-supply : shared supply
DLDO4 : LDO : dldoin-supply : shared supply
ELDO1 : LDO : eldoin-supply : shared supply
ELDO2 : LDO : eldoin-supply : shared supply
ELDO3 : LDO : eldoin-supply : shared supply
FLDO1 : LDO : fldoin-supply : shared supply
FLDO2 : LDO : fldoin-supply : shared supply
FLDO3 : LDO : fldoin-supply : shared supply
LDO_IO0 : LDO : ips-supply : GPIO 0
LDO_IO1 : LDO : ips-supply : GPIO 1
RTC_LDO : LDO : ips-supply : always on
SW : On/Off Switch : swin-supply
DRIVEVBUS : Enable output : drivevbus-supply : external regulator
Example:
axp209: pmic@34 {
compatible = "x-powers,axp209";
reg = <0x34>;
interrupt-parent = <&nmi_intc>;
interrupts = <0 IRQ_TYPE_LEVEL_LOW>;
interrupt-controller;
#interrupt-cells = <1>;
regulators {
x-powers,dcdc-freq = <1500>;
vdd_cpu: dcdc2 {
regulator-always-on;
regulator-min-microvolt = <1000000>;
regulator-max-microvolt = <1450000>;
regulator-name = "vdd-cpu";
};
vdd_int_dll: dcdc3 {
regulator-always-on;
regulator-min-microvolt = <1000000>;
regulator-max-microvolt = <1400000>;
regulator-name = "vdd-int-dll";
};
vdd_rtc: ldo1 {
regulator-always-on;
regulator-min-microvolt = <1200000>;
regulator-max-microvolt = <1400000>;
regulator-name = "vdd-rtc";
};
avcc: ldo2 {
regulator-always-on;
regulator-min-microvolt = <2700000>;
regulator-max-microvolt = <3300000>;
regulator-name = "avcc";
};
ldo3 {
/* unused but preferred to be managed by OS */
};
};
};

21
Documentation/devicetree/bindings/mfd/brcm,cru.yaml
View File

@@ -36,9 +36,15 @@ patternProperties:
'^clock-controller@[a-f0-9]+$': '^clock-controller@[a-f0-9]+$':
$ref: ../clock/brcm,iproc-clocks.yaml $ref: ../clock/brcm,iproc-clocks.yaml
'^phy@[a-f0-9]+$':
$ref: ../phy/bcm-ns-usb2-phy.yaml
'^pin-controller@[a-f0-9]+$': '^pin-controller@[a-f0-9]+$':
$ref: ../pinctrl/brcm,ns-pinmux.yaml $ref: ../pinctrl/brcm,ns-pinmux.yaml
'^syscon@[a-f0-9]+$':
$ref: syscon.yaml
'^thermal@[a-f0-9]+$': '^thermal@[a-f0-9]+$':
$ref: ../thermal/brcm,ns-thermal.yaml $ref: ../thermal/brcm,ns-thermal.yaml
@@ -49,6 +55,7 @@ required:
examples: examples:
- | - |
#include <dt-bindings/clock/bcm-nsp.h>
cru-bus@1800c100 { cru-bus@1800c100 {
compatible = "brcm,ns-cru", "simple-mfd"; compatible = "brcm,ns-cru", "simple-mfd";
reg = <0x1800c100 0x1d0>; reg = <0x1800c100 0x1d0>;
@@ -73,6 +80,20 @@ examples:
"iprocfast", "sata1", "sata2"; "iprocfast", "sata1", "sata2";
}; };
phy@164 {
compatible = "brcm,ns-usb2-phy";
reg = <0x164 0x4>;
brcm,syscon-clkset = <&clkset>;
clocks = <&genpll BCM_NSP_GENPLL_USB_PHY_REF_CLK>;
clock-names = "phy-ref-clk";
#phy-cells = <0>;
};
clkset: syscon@180 {
compatible = "brcm,cru-clkset", "syscon";
reg = <0x180 0x4>;
};
pin-controller@1c0 { pin-controller@1c0 {
compatible = "brcm,bcm4708-pinmux"; compatible = "brcm,bcm4708-pinmux";
reg = <0x1c0 0x24>; reg = <0x1c0 0x24>;

60
Documentation/devicetree/bindings/mfd/brcm,misc.yaml Normal file
View File

@@ -0,0 +1,60 @@
# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
%YAML 1.2
---
$id: http://devicetree.org/schemas/mfd/brcm,misc.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Broadcom's MISC block
maintainers:
- Rafał Miłecki <rafal@milecki.pl>
description: |
Broadcom's MISC is a hardware block used on some SoCs (e.g. bcm63xx and
bcm4908). It's used to implement some simple functions like a watchdog, PCIe
reset, UniMAC control and more.
properties:
compatible:
items:
- const: brcm,misc
- const: simple-mfd
reg:
description: MISC block registers
ranges: true
"#address-cells":
const: 1
"#size-cells":
const: 1
patternProperties:
'^reset-controller@[a-f0-9]+$':
$ref: ../reset/brcm,bcm4908-misc-pcie-reset.yaml
additionalProperties: false
required:
- reg
- '#address-cells'
- '#size-cells'
examples:
- |
misc@ff802600 {
compatible = "brcm,misc", "simple-mfd";
reg = <0xff802600 0xe4>;
#address-cells = <1>;
#size-cells = <1>;
ranges = <0x0 0x0 0xe4>;
reset-controller@44 {
compatible = "brcm,bcm4908-misc-pcie-reset";
reg = <0x44 0x4>;
#reset-cells = <1>;
};
};

4
Documentation/devicetree/bindings/mfd/max14577.txt
View File

@@ -71,7 +71,7 @@ max14577@25 {
compatible = "maxim,max14577"; compatible = "maxim,max14577";
reg = <0x25>; reg = <0x25>;
interrupt-parent = <&gpx1>; interrupt-parent = <&gpx1>;
interrupts = <5 IRQ_TYPE_NONE>; interrupts = <5 IRQ_TYPE_LEVEL_LOW>;
muic: max14577-muic { muic: max14577-muic {
compatible = "maxim,max14577-muic"; compatible = "maxim,max14577-muic";
@@ -106,7 +106,7 @@ max77836@25 {
compatible = "maxim,max77836"; compatible = "maxim,max77836";
reg = <0x25>; reg = <0x25>;
interrupt-parent = <&gpx1>; interrupt-parent = <&gpx1>;
interrupts = <5 IRQ_TYPE_NONE>; interrupts = <5 IRQ_TYPE_LEVEL_LOW>;
muic: max77836-muic { muic: max77836-muic {
compatible = "maxim,max77836-muic"; compatible = "maxim,max77836-muic";

2
Documentation/devicetree/bindings/mfd/max77686.txt
View File

@@ -21,6 +21,6 @@ Example:
max77686: pmic@9 { max77686: pmic@9 {
compatible = "maxim,max77686"; compatible = "maxim,max77686";
interrupt-parent = <&wakeup_eint>; interrupt-parent = <&wakeup_eint>;
interrupts = <26 0>; interrupts = <26 IRQ_TYPE_LEVEL_LOW>;
reg = <0x09>; reg = <0x09>;
}; };

2
Documentation/devicetree/bindings/mfd/max77693.txt
View File

@@ -139,7 +139,7 @@ Example:
compatible = "maxim,max77693"; compatible = "maxim,max77693";
reg = <0x66>; reg = <0x66>;
interrupt-parent = <&gpx1>; interrupt-parent = <&gpx1>;
interrupts = <5 2>; interrupts = <5 IRQ_TYPE_LEVEL_LOW>;
regulators { regulators {
esafeout@1 { esafeout@1 {

51
Documentation/devicetree/bindings/mfd/qcom,spmi-pmic.txt
View File

@@ -15,29 +15,38 @@ each. A function can consume one or more of these fixed-size register regions.
Required properties: Required properties:
- compatible: Should contain one of: - compatible: Should contain one of:
"qcom,pm8941", "qcom,pm660",
"qcom,pm8841", "qcom,pm660l",
"qcom,pma8084",
"qcom,pm8019",
"qcom,pm8226",
"qcom,pm8110",
"qcom,pma8084",
"qcom,pmi8962",
"qcom,pmd9635",
"qcom,pm8994",
"qcom,pmi8994",
"qcom,pm8916",
"qcom,pm8004",
"qcom,pm8909",
"qcom,pm8950",
"qcom,pmi8950",
"qcom,pm8998",
"qcom,pmi8998",
"qcom,pm8005",
"qcom,pm8350c",
"qcom,pmk8350",
"qcom,pm7325", "qcom,pm7325",
"qcom,pm8004",
"qcom,pm8005",
"qcom,pm8019",
"qcom,pm8028",
"qcom,pm8110",
"qcom,pm8150",
"qcom,pm8150b",
"qcom,pm8150c",
"qcom,pm8150l",
"qcom,pm8226",
"qcom,pm8350c",
"qcom,pm8841",
"qcom,pm8901",
"qcom,pm8909",
"qcom,pm8916",
"qcom,pm8941",
"qcom,pm8950",
"qcom,pm8994",
"qcom,pm8998",
"qcom,pma8084",
"qcom,pmd9635",
"qcom,pmi8950",
"qcom,pmi8962",
"qcom,pmi8994",
"qcom,pmi8998",
"qcom,pmk8002",
"qcom,pmk8350",
"qcom,pmr735a", "qcom,pmr735a",
"qcom,smb2351",
or generalized "qcom,spmi-pmic". or generalized "qcom,spmi-pmic".
- reg: Specifies the SPMI USID slave address for this device. - reg: Specifies the SPMI USID slave address for this device.
For more information see: For more information see:

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