Merge branch 'for-5.17/core' into for-linus
- 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
commit
8a2094d679
5
.mailmap
5
.mailmap
|
|
@ -71,8 +71,13 @@ Chao Yu <chao@kernel.org> <chao2.yu@samsung.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@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>
|
||||
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>
|
||||
Damian Hobson-Garcia <dhobsong@igel.co.jp>
|
||||
Daniel Borkmann <daniel@iogearbox.net> <danborkmann@googlemail.com>
|
||||
|
|
|
|||
|
|
@ -100,6 +100,17 @@ Description:
|
|||
This attribute indicates the mode that the irq vector named by
|
||||
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
|
||||
Date: January 2009
|
||||
Contact: Linux PCI developers <linux-pci@vger.kernel.org>
|
||||
|
|
|
|||
|
|
@ -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>:"
|
||||
|
|
@ -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
|
||||
Date: February 2018
|
||||
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
|
||||
the particular logical unit. The full information about
|
||||
the attribute could be found at UFS specifications 2.1.
|
||||
|
|
|
|||
|
|
@ -512,3 +512,19 @@ Date: July 2021
|
|||
Contact: "Daeho Jeong" <daehojeong@google.com>
|
||||
Description: You can control the multiplier value of bdi device readahead window size
|
||||
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.
|
||||
|
|
|
|||
|
|
@ -328,6 +328,14 @@ as idle::
|
|||
From now on, any pages on zram are idle pages. The idle mark
|
||||
will be removed until someone requests access of the block.
|
||||
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::
|
||||
|
||||
|
|
|
|||
|
|
@ -87,10 +87,8 @@ Brief summary of control files.
|
|||
memory.oom_control set/show oom controls.
|
||||
memory.numa_stat show the number of memory usage per numa
|
||||
node
|
||||
memory.kmem.limit_in_bytes set/show hard limit for kernel memory
|
||||
This knob is deprecated and shouldn't be
|
||||
used. It is planned that this be removed in
|
||||
the foreseeable future.
|
||||
memory.kmem.limit_in_bytes This knob is deprecated and writing to
|
||||
it will return -ENOTSUPP.
|
||||
memory.kmem.usage_in_bytes show current kernel memory allocation
|
||||
memory.kmem.failcnt show the number of kernel memory usage
|
||||
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
|
||||
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
|
||||
-------------
|
||||
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
|
|
@ -61,8 +61,9 @@ arg3:
|
|||
``pid`` of the task for which the operation applies.
|
||||
|
||||
arg4:
|
||||
``pid_type`` for which the operation applies. It is of type ``enum pid_type``.
|
||||
For example, if arg4 is ``PIDTYPE_TGID``, then the operation of this command
|
||||
``pid_type`` for which the operation applies. It is one of
|
||||
``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``.
|
||||
|
||||
arg5:
|
||||
|
|
|
|||
|
|
@ -82,6 +82,7 @@ configure specific aspects of kernel behavior to your liking.
|
|||
edid
|
||||
efi-stub
|
||||
ext4
|
||||
filesystem-monitoring
|
||||
nfs/index
|
||||
gpio/index
|
||||
highuid
|
||||
|
|
|
|||
|
|
@ -1582,8 +1582,10 @@
|
|||
registers. Default set by CONFIG_HPET_MMAP_DEFAULT.
|
||||
|
||||
hugetlb_cma= [HW,CMA] The size of a CMA area used for allocation
|
||||
of gigantic hugepages.
|
||||
Format: nn[KMGTPE]
|
||||
of gigantic hugepages. Or using node format, the size
|
||||
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
|
||||
hugepages using the CMA allocator. If enabled, the
|
||||
|
|
@ -1594,9 +1596,11 @@
|
|||
the number of pages of hugepagesz to be allocated.
|
||||
If this is the first HugeTLB parameter on the command
|
||||
line, it specifies the number of pages to allocate for
|
||||
the default huge page size. See also
|
||||
Documentation/admin-guide/mm/hugetlbpage.rst.
|
||||
Format: <integer>
|
||||
the default huge page size. If using node format, the
|
||||
number of pages to allocate per-node can be specified.
|
||||
See also Documentation/admin-guide/mm/hugetlbpage.rst.
|
||||
Format: <integer> or (node format)
|
||||
<node>:<integer>[,<node>:<integer>]
|
||||
|
||||
hugepagesz=
|
||||
[HW] The size of the HugeTLB pages. This is used in
|
||||
|
|
@ -3249,6 +3253,19 @@
|
|||
driver. A non-zero value sets the minimum interval
|
||||
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=
|
||||
[NFSv4] When set to the default of '1', the NFSv4
|
||||
server will return only numeric uids and gids to
|
||||
|
|
@ -3256,6 +3273,7 @@
|
|||
and gids from such clients. This is intended to ease
|
||||
migration from NFSv2/v3.
|
||||
|
||||
|
||||
nmi_backtrace.backtrace_idle [KNL]
|
||||
Dump stacks even of idle CPUs in response to an
|
||||
NMI stack-backtrace request.
|
||||
|
|
@ -4988,6 +5006,18 @@
|
|||
an IOTLB flush. Default is lazy flushing before reuse,
|
||||
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]
|
||||
See drivers/net/irda/sa1100_ir.c.
|
||||
|
||||
|
|
@ -6363,6 +6393,13 @@
|
|||
improve timer resolution at the expense of processing
|
||||
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]
|
||||
How long to delay EOI handling in case of event
|
||||
storms (jiffies). Default is 10.
|
||||
|
|
|
|||
|
|
@ -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
|
||||
and set.
|
||||
|
||||
- 1 = Home mode
|
||||
- 2 = Web-browser mode
|
||||
- 3 = Web-conference mode
|
||||
- 4 = Function mode
|
||||
- 5 = Layflat mode
|
||||
- 0 = Home mode
|
||||
- 1 = Web-browser mode
|
||||
- 2 = Web-conference mode
|
||||
- 3 = Function mode
|
||||
- 4 = Layflat mode
|
||||
|
||||
For more details about which buttons will appear depending on the mode, please
|
||||
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
|
||||
----------------------
|
||||
|
|
|
|||
|
|
@ -13,3 +13,4 @@ optimize those.
|
|||
|
||||
start
|
||||
usage
|
||||
reclaim
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
@ -6,39 +6,9 @@ Getting Started
|
|||
|
||||
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
|
||||
of its features for brevity. Please refer to :doc:`usage` 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)
|
||||
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.
|
||||
|
||||
|
||||
Prerequisites
|
||||
|
|
@ -91,24 +61,74 @@ pattern in the ``damon.data`` file.
|
|||
Visualizing Recorded Patterns
|
||||
=============================
|
||||
|
||||
The following three commands visualize the recorded access patterns and save
|
||||
the results as separate image files. ::
|
||||
You can visualize the pattern in a heatmap, showing which memory region
|
||||
(x-axis) got accessed when (y-axis) and how frequently (number).::
|
||||
|
||||
$ damo report heats --heatmap access_pattern_heatmap.png
|
||||
$ damo report wss --range 0 101 1 --plot wss_dist.png
|
||||
$ damo report wss --range 0 101 1 --sortby time --plot wss_chron_change.png
|
||||
$ sudo damo report heats --heatmap stdout
|
||||
22222222222222222222222222222222222222211111111111111111111111111111111111111100
|
||||
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
|
||||
heatmap, showing which memory region (y-axis) got accessed when (x-axis)
|
||||
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 also visualize the distribution of the working set size, sorted by the
|
||||
size.::
|
||||
|
||||
You can view the visualizations of this example workload at [1]_.
|
||||
Visualizations of other realistic workloads are available at [2]_ [3]_ [4]_.
|
||||
$ sudo damo report wss --range 0 101 10
|
||||
# <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
|
||||
.. [2] https://damonitor.github.io/test/result/visual/latest/rec.heatmap.1.png.html
|
||||
.. [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
|
||||
Using ``--sortby`` option with the above command, you can show how the working
|
||||
set size has chronologically changed.::
|
||||
|
||||
$ 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>
|
||||
|
|
|
|||
|
|
@ -10,15 +10,16 @@ DAMON provides below three interfaces for different users.
|
|||
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
|
||||
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.*
|
||||
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
|
||||
from and writing to special debugfs files. Therefore, you can write and use
|
||||
your personalized DAMON debugfs wrapper programs that reads/writes the
|
||||
debugfs files instead of you. The DAMON user space tool is also a reference
|
||||
implementation of such programs. It supports only virtual address spaces
|
||||
monitoring.
|
||||
implementation of such programs. It supports both virtual and physical
|
||||
address spaces monitoring.
|
||||
- *Kernel Space Programming Interface.*
|
||||
This is for kernel space programmers. Using this, users can utilize every
|
||||
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
|
||||
=================
|
||||
|
||||
DAMON exports three files, ``attrs``, ``target_ids``, and ``monitor_on`` under
|
||||
its debugfs directory, ``<debugfs>/damon/``.
|
||||
DAMON exports five files, ``attrs``, ``target_ids``, ``init_regions``,
|
||||
``schemes`` and ``monitor_on`` under its debugfs directory,
|
||||
``<debugfs>/damon/``.
|
||||
|
||||
|
||||
Attributes
|
||||
|
|
@ -71,9 +73,106 @@ check it again::
|
|||
# cat target_ids
|
||||
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.
|
||||
|
||||
|
||||
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
|
||||
--------------
|
||||
|
||||
|
|
|
|||
|
|
@ -128,7 +128,9 @@ hugepages
|
|||
implicitly specifies the number of huge pages of default size to
|
||||
allocate. If the number of huge pages of default size is implicitly
|
||||
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::
|
||||
|
||||
|
|
@ -138,6 +140,14 @@ hugepages
|
|||
indicating that the hugepages=512 parameter is ignored. If a hugepages
|
||||
parameter is preceded by an invalid hugepagesz parameter, it will
|
||||
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
|
||||
Specify the default huge page size. This parameter can
|
||||
only be specified once on the command line. default_hugepagesz can
|
||||
|
|
@ -234,8 +244,12 @@ will exist, of the form::
|
|||
|
||||
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_mempolicy
|
||||
nr_overcommit_hugepages
|
||||
|
|
@ -243,7 +257,29 @@ Inside each of these directories, the same set of files will exist::
|
|||
resv_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:
|
||||
|
||||
|
|
|
|||
|
|
@ -37,5 +37,7 @@ the Linux memory management.
|
|||
numaperf
|
||||
pagemap
|
||||
soft-dirty
|
||||
swap_numa
|
||||
transhuge
|
||||
userfaultfd
|
||||
zswap
|
||||
|
|
|
|||
|
|
@ -165,9 +165,8 @@ Or alternatively::
|
|||
|
||||
% echo 1 > /sys/devices/system/memory/memoryXXX/online
|
||||
|
||||
The kernel will select the target zone automatically, usually defaulting to
|
||||
``ZONE_NORMAL`` unless ``movablecore=1`` has been specified on the kernel
|
||||
command line or if the memory block would intersect the ZONE_MOVABLE already.
|
||||
The kernel will select the target zone automatically, depending on the
|
||||
configured ``online_policy``.
|
||||
|
||||
One can explicitly request to associate an offline memory block with
|
||||
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
|
||||
|
||||
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
|
||||
memory blocks only.
|
||||
|
||||
|
|
@ -393,11 +395,16 @@ command line parameters are relevant:
|
|||
======================== =======================================================
|
||||
``memhp_default_state`` configure auto-onlining by essentially setting
|
||||
``/sys/devices/system/memory/auto_online_blocks``.
|
||||
``movablecore`` configure automatic zone selection of the kernel. When
|
||||
set, the kernel will default to ZONE_MOVABLE, unless
|
||||
other zones can be kept contiguous.
|
||||
``movable_node`` configure automatic zone selection in the kernel when
|
||||
using the ``contig-zones`` online policy. When
|
||||
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
|
||||
------------------
|
||||
|
||||
|
|
@ -410,24 +417,118 @@ them with ``memory_hotplug.`` such as::
|
|||
|
||||
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:
|
||||
|
||||
======================== =======================================================
|
||||
``memmap_on_memory`` read-write: Allocate memory for the memmap from the
|
||||
added memory block itself. Even if enabled, actual
|
||||
support depends on various other system properties and
|
||||
should only be regarded as a hint whether the behavior
|
||||
would be desired.
|
||||
================================ ===============================================
|
||||
``memmap_on_memory`` read-write: Allocate memory for the memmap from
|
||||
the added memory block itself. Even if enabled,
|
||||
actual support depends on various other system
|
||||
properties and should only be regarded as a
|
||||
hint whether the behavior would be desired.
|
||||
|
||||
While allocating the memmap from the memory block
|
||||
itself makes memory hotplug less likely to fail and
|
||||
keeps the memmap on the same NUMA node in any case, it
|
||||
can fragment physical memory in a way that huge pages
|
||||
in bigger granularity cannot be formed on hotplugged
|
||||
memory.
|
||||
======================== =======================================================
|
||||
While allocating the memmap from the memory
|
||||
block itself makes memory hotplug less likely
|
||||
to fail and keeps the memmap on the same NUMA
|
||||
node in any case, it can fragment physical
|
||||
memory in a way that huge pages in bigger
|
||||
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
|
||||
============
|
||||
|
|
|
|||
|
|
@ -90,13 +90,14 @@ Short descriptions to the page flags
|
|||
====================================
|
||||
|
||||
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
|
||||
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
|
||||
page; SLOB will not flag it at all.
|
||||
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.
|
||||
An order N block has 2^N physically contiguous pages, with the BUDDY flag
|
||||
set for and _only_ for the first page.
|
||||
|
|
@ -112,65 +113,65 @@ Short descriptions to the page flags
|
|||
16 - COMPOUND_TAIL
|
||||
A compound page tail (see description above).
|
||||
17 - HUGE
|
||||
this is an integral part of a HugeTLB page
|
||||
This is an integral part of a HugeTLB page.
|
||||
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
|
||||
no page frame exists at the requested address
|
||||
No page frame exists at the requested address.
|
||||
21 - KSM
|
||||
identical memory pages dynamically shared between one or more processes
|
||||
Identical memory pages dynamically shared between one or more processes.
|
||||
22 - THP
|
||||
contiguous pages which construct transparent hugepages
|
||||
Contiguous pages which construct transparent hugepages.
|
||||
23 - OFFLINE
|
||||
page is logically offline
|
||||
The page is logically offline.
|
||||
24 - ZERO_PAGE
|
||||
zero page for pfn_zero or huge_zero page
|
||||
Zero page for pfn_zero or huge_zero page.
|
||||
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>`).
|
||||
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
|
||||
``/sys/kernel/mm/page_idle/bitmap`` first.
|
||||
26 - PGTABLE
|
||||
page is in use as a page table
|
||||
The page is in use as a page table.
|
||||
|
||||
IO related page flags
|
||||
---------------------
|
||||
|
||||
1 - ERROR
|
||||
IO error occurred
|
||||
IO error occurred.
|
||||
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)
|
||||
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)
|
||||
8 - WRITEBACK
|
||||
page is being synced to disk
|
||||
The page is being synced to disk.
|
||||
|
||||
LRU related page flags
|
||||
----------------------
|
||||
|
||||
5 - LRU
|
||||
page is in one of the LRU lists
|
||||
The page is in one of the LRU lists.
|
||||
6 - ACTIVE
|
||||
page is in the active LRU list
|
||||
The page is in the active LRU list.
|
||||
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,
|
||||
shmctl(SHM_LOCK) and mlock() memory segments
|
||||
shmctl(SHM_LOCK) and mlock() memory segments.
|
||||
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
|
||||
page will be reclaimed soon after its pageout IO completed
|
||||
The page will be reclaimed soon after its pageout IO completed.
|
||||
11 - MMAP
|
||||
a memory mapped page
|
||||
A memory mapped page.
|
||||
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
|
||||
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
|
||||
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
|
||||
above flags.
|
||||
|
|
|
|||
|
|
@ -1099,7 +1099,7 @@ task_delayacct
|
|||
===============
|
||||
|
||||
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
|
||||
and performance tuning. It is required by some tools such as iotop.
|
||||
|
||||
|
|
|
|||
|
|
@ -104,6 +104,8 @@ Discovery family
|
|||
|
||||
Not supported by the Linux kernel.
|
||||
|
||||
Homepage:
|
||||
https://web.archive.org/web/20110924171043/http://www.marvell.com/embedded-processors/discovery-innovation/
|
||||
Core:
|
||||
Feroceon 88fr571-vd ARMv5 compatible
|
||||
|
||||
|
|
@ -120,6 +122,7 @@ EBU Armada family
|
|||
- 88F6707
|
||||
- 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
|
||||
- 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
|
||||
|
|
@ -127,9 +130,29 @@ EBU Armada family
|
|||
Core:
|
||||
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:
|
||||
- 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
|
||||
|
||||
Core:
|
||||
|
|
@ -162,29 +185,6 @@ EBU Armada family
|
|||
Core:
|
||||
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:
|
||||
arch/arm/mach-mvebu
|
||||
Linux kernel plat directory:
|
||||
|
|
@ -436,7 +436,7 @@ Berlin family (Multimedia Solutions)
|
|||
- Flavors:
|
||||
- 88DE3010, Armada 1000 (no Linux support)
|
||||
- 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
|
||||
- Design name: BG2CD
|
||||
- Core: ARM Cortex-A9, PL310 L2CC
|
||||
|
|
|
|||
|
|
@ -15,7 +15,7 @@ that goes into great technical depth about the BPF Architecture.
|
|||
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)
|
||||
=====================
|
||||
|
|
|
|||
|
|
@ -57,7 +57,6 @@ The third argument (arg) passes a pointer of struct memory_notify::
|
|||
unsigned long start_pfn;
|
||||
unsigned long nr_pages;
|
||||
int status_change_nid_normal;
|
||||
int status_change_nid_high;
|
||||
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.
|
||||
- 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.
|
||||
- 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)
|
||||
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.
|
||||
|
|
|
|||
|
|
@ -50,6 +50,7 @@ program using kcov:
|
|||
#include <sys/mman.h>
|
||||
#include <unistd.h>
|
||||
#include <fcntl.h>
|
||||
#include <linux/types.h>
|
||||
|
||||
#define KCOV_INIT_TRACE _IOR('c', 1, unsigned long)
|
||||
#define KCOV_ENABLE _IO('c', 100)
|
||||
|
|
@ -177,6 +178,8 @@ Comparison operands collection is similar to coverage collection:
|
|||
/* Read number of comparisons collected. */
|
||||
n = __atomic_load_n(&cover[0], __ATOMIC_RELAXED);
|
||||
for (i = 0; i < n; i++) {
|
||||
uint64_t ip;
|
||||
|
||||
type = cover[i * KCOV_WORDS_PER_CMP + 1];
|
||||
/* arg1 and arg2 - operands of the comparison. */
|
||||
arg1 = cover[i * KCOV_WORDS_PER_CMP + 2];
|
||||
|
|
@ -251,6 +254,8 @@ selectively from different subsystems.
|
|||
|
||||
.. code-block:: c
|
||||
|
||||
/* Same includes and defines as above. */
|
||||
|
||||
struct kcov_remote_arg {
|
||||
__u32 trace_mode;
|
||||
__u32 area_size;
|
||||
|
|
|
|||
|
|
@ -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
|
||||
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
|
||||
the next allocation is set up after the expiration of the interval. To "gate" a
|
||||
KFENCE allocation through the main allocator's fast-path without overhead,
|
||||
KFENCE relies on static branches via the static keys infrastructure. The static
|
||||
branch is toggled to redirect the allocation to KFENCE.
|
||||
the next allocation is set up after the expiration of the interval.
|
||||
|
||||
When using ``CONFIG_KFENCE_STATIC_KEYS=y``, KFENCE allocations are "gated"
|
||||
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
|
||||
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
|
||||
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
|
||||
---------
|
||||
|
||||
|
|
|
|||
|
|
@ -7,7 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml#
|
|||
title: ST STi Platforms Device Tree Bindings
|
||||
|
||||
maintainers:
|
||||
- Patrice Chotard <patrice.chotard@st.com>
|
||||
- Patrice Chotard <patrice.chotard@foss.st.com>
|
||||
|
||||
properties:
|
||||
$nodename:
|
||||
|
|
|
|||
|
|
@ -7,8 +7,8 @@ $schema: "http://devicetree.org/meta-schemas/core.yaml#"
|
|||
title: STMicroelectronics STM32 ML-AHB interconnect bindings
|
||||
|
||||
maintainers:
|
||||
- Fabien Dessenne <fabien.dessenne@st.com>
|
||||
- Arnaud Pouliquen <arnaud.pouliquen@st.com>
|
||||
- Fabien Dessenne <fabien.dessenne@foss.st.com>
|
||||
- Arnaud Pouliquen <arnaud.pouliquen@foss.st.com>
|
||||
|
||||
description: |
|
||||
These bindings describe the STM32 SoCs ML-AHB interconnect bus which connects
|
||||
|
|
|
|||
|
|
@ -7,8 +7,8 @@ $schema: "http://devicetree.org/meta-schemas/core.yaml#"
|
|||
title: STMicroelectronics STM32 Platforms System Controller bindings
|
||||
|
||||
maintainers:
|
||||
- Alexandre Torgue <alexandre.torgue@st.com>
|
||||
- Christophe Roullier <christophe.roullier@st.com>
|
||||
- Alexandre Torgue <alexandre.torgue@foss.st.com>
|
||||
- Christophe Roullier <christophe.roullier@foss.st.com>
|
||||
|
||||
properties:
|
||||
compatible:
|
||||
|
|
|
|||
|
|
@ -7,7 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml#
|
|||
title: STMicroelectronics STM32 Platforms Device Tree Bindings
|
||||
|
||||
maintainers:
|
||||
- Alexandre Torgue <alexandre.torgue@st.com>
|
||||
- Alexandre Torgue <alexandre.torgue@foss.st.com>
|
||||
|
||||
properties:
|
||||
$nodename:
|
||||
|
|
|
|||
|
|
@ -14,14 +14,21 @@ allOf:
|
|||
|
||||
properties:
|
||||
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:
|
||||
maxItems: 1
|
||||
|
||||
refresh-rate-hz:
|
||||
maxItems: 1
|
||||
description: Display update interval in Hertz
|
||||
description: Display update interval in Hertz for dot-matrix displays
|
||||
|
||||
interrupts:
|
||||
maxItems: 1
|
||||
|
|
@ -41,10 +48,22 @@ properties:
|
|||
default: 16
|
||||
description: Initial brightness level
|
||||
|
||||
led:
|
||||
type: object
|
||||
$ref: /schemas/leds/common.yaml#
|
||||
unevaluatedProperties: false
|
||||
|
||||
required:
|
||||
- compatible
|
||||
- reg
|
||||
- refresh-rate-hz
|
||||
|
||||
if:
|
||||
properties:
|
||||
compatible:
|
||||
const: holtek,ht16k33
|
||||
then:
|
||||
required:
|
||||
- refresh-rate-hz
|
||||
|
||||
additionalProperties: false
|
||||
|
||||
|
|
@ -52,6 +71,7 @@ examples:
|
|||
- |
|
||||
#include <dt-bindings/interrupt-controller/irq.h>
|
||||
#include <dt-bindings/input/input.h>
|
||||
#include <dt-bindings/leds/common.h>
|
||||
i2c1 {
|
||||
#address-cells = <1>;
|
||||
#size-cells = <0>;
|
||||
|
|
@ -73,5 +93,11 @@ examples:
|
|||
<MATRIX_KEY(4, 1, KEY_F9)>,
|
||||
<MATRIX_KEY(5, 1, KEY_F3)>,
|
||||
<MATRIX_KEY(6, 1, KEY_F1)>;
|
||||
|
||||
led {
|
||||
color = <LED_COLOR_ID_RED>;
|
||||
function = LED_FUNCTION_BACKLIGHT;
|
||||
linux,default-trigger = "backlight";
|
||||
};
|
||||
};
|
||||
};
|
||||
|
|
|
|||
|
|
@ -104,7 +104,7 @@ additionalProperties: false
|
|||
|
||||
examples:
|
||||
- |
|
||||
#include <dt-bindings/clock/jz4770-cgu.h>
|
||||
#include <dt-bindings/clock/ingenic,jz4770-cgu.h>
|
||||
cgu: clock-controller@10000000 {
|
||||
compatible = "ingenic,jz4770-cgu", "simple-mfd";
|
||||
reg = <0x10000000 0x100>;
|
||||
|
|
|
|||
|
|
@ -49,7 +49,7 @@ Example:
|
|||
max77686: max77686@9 {
|
||||
compatible = "maxim,max77686";
|
||||
interrupt-parent = <&wakeup_eint>;
|
||||
interrupts = <26 0>;
|
||||
interrupts = <26 IRQ_TYPE_LEVEL_LOW>;
|
||||
reg = <0x09>;
|
||||
#clock-cells = <1>;
|
||||
|
||||
|
|
@ -74,7 +74,7 @@ Example:
|
|||
max77802: max77802@9 {
|
||||
compatible = "maxim,max77802";
|
||||
interrupt-parent = <&wakeup_eint>;
|
||||
interrupts = <26 0>;
|
||||
interrupts = <26 IRQ_TYPE_LEVEL_LOW>;
|
||||
reg = <0x09>;
|
||||
#clock-cells = <1>;
|
||||
|
||||
|
|
|
|||
|
|
@ -42,6 +42,9 @@ properties:
|
|||
"#clock-cells":
|
||||
const: 1
|
||||
|
||||
"#reset-cells":
|
||||
const: 1
|
||||
|
||||
required:
|
||||
- compatible
|
||||
- reg
|
||||
|
|
@ -57,4 +60,5 @@ examples:
|
|||
reg = <0x10000000 0x1000>;
|
||||
clocks = <&hfclk>, <&rtcclk>;
|
||||
#clock-cells = <1>;
|
||||
#reset-cells = <1>;
|
||||
};
|
||||
|
|
|
|||
|
|
@ -2,7 +2,7 @@ Binding for Silicon Labs Si5351a/b/c programmable i2c clock generator.
|
|||
|
||||
Reference
|
||||
[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
|
||||
clocks. Si5351a also has a reduced pin-count package (MSOP10) where only
|
||||
|
|
|
|||
|
|
@ -23,6 +23,7 @@ properties:
|
|||
- socionext,uniphier-ld11-clock
|
||||
- socionext,uniphier-ld20-clock
|
||||
- socionext,uniphier-pxs3-clock
|
||||
- socionext,uniphier-nx1-clock
|
||||
- description: Media I/O (MIO) clock, SD clock
|
||||
enum:
|
||||
- socionext,uniphier-ld4-mio-clock
|
||||
|
|
@ -33,6 +34,7 @@ properties:
|
|||
- socionext,uniphier-ld11-mio-clock
|
||||
- socionext,uniphier-ld20-sd-clock
|
||||
- socionext,uniphier-pxs3-sd-clock
|
||||
- socionext,uniphier-nx1-sd-clock
|
||||
- description: Peripheral clock
|
||||
enum:
|
||||
- socionext,uniphier-ld4-peri-clock
|
||||
|
|
@ -43,6 +45,10 @@ properties:
|
|||
- socionext,uniphier-ld11-peri-clock
|
||||
- socionext,uniphier-ld20-peri-clock
|
||||
- socionext,uniphier-pxs3-peri-clock
|
||||
- socionext,uniphier-nx1-peri-clock
|
||||
- description: SoC-glue clock
|
||||
enum:
|
||||
- socionext,uniphier-pro4-sg-clock
|
||||
|
||||
"#clock-cells":
|
||||
const: 1
|
||||
|
|
|
|||
|
|
@ -7,7 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml#
|
|||
title: Reset Clock Controller Binding
|
||||
|
||||
maintainers:
|
||||
- Gabriel Fernandez <gabriel.fernandez@st.com>
|
||||
- Gabriel Fernandez <gabriel.fernandez@foss.st.com>
|
||||
|
||||
description: |
|
||||
The RCC IP is both a reset and a clock controller.
|
||||
|
|
|
|||
|
|
@ -7,7 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml#
|
|||
title: STMicroelectronics STM32 CRC bindings
|
||||
|
||||
maintainers:
|
||||
- Lionel Debieve <lionel.debieve@st.com>
|
||||
- Lionel Debieve <lionel.debieve@foss.st.com>
|
||||
|
||||
properties:
|
||||
compatible:
|
||||
|
|
|
|||
|
|
@ -7,7 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml#
|
|||
title: STMicroelectronics STM32 CRYP bindings
|
||||
|
||||
maintainers:
|
||||
- Lionel Debieve <lionel.debieve@st.com>
|
||||
- Lionel Debieve <lionel.debieve@foss.st.com>
|
||||
|
||||
properties:
|
||||
compatible:
|
||||
|
|
|
|||
|
|
@ -7,7 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml#
|
|||
title: STMicroelectronics STM32 HASH bindings
|
||||
|
||||
maintainers:
|
||||
- Lionel Debieve <lionel.debieve@st.com>
|
||||
- Lionel Debieve <lionel.debieve@foss.st.com>
|
||||
|
||||
properties:
|
||||
compatible:
|
||||
|
|
|
|||
|
|
@ -49,11 +49,26 @@ properties:
|
|||
|
||||
properties:
|
||||
port@0:
|
||||
$ref: /schemas/graph.yaml#/properties/port
|
||||
$ref: /schemas/graph.yaml#/$defs/port-base
|
||||
description: |
|
||||
For LVDS encoders, port 0 is the parallel 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:
|
||||
$ref: /schemas/graph.yaml#/properties/port
|
||||
description: |
|
||||
|
|
@ -71,6 +86,22 @@ properties:
|
|||
|
||||
power-supply: true
|
||||
|
||||
if:
|
||||
not:
|
||||
properties:
|
||||
compatible:
|
||||
contains:
|
||||
const: lvds-decoder
|
||||
then:
|
||||
properties:
|
||||
ports:
|
||||
properties:
|
||||
port@0:
|
||||
properties:
|
||||
endpoint:
|
||||
properties:
|
||||
data-mapping: false
|
||||
|
||||
required:
|
||||
- compatible
|
||||
- ports
|
||||
|
|
|
|||
|
|
@ -40,6 +40,9 @@ properties:
|
|||
vdd33-supply:
|
||||
description: Regulator for 3.3V digital core power.
|
||||
|
||||
aux-bus:
|
||||
$ref: /schemas/display/dp-aux-bus.yaml#
|
||||
|
||||
ports:
|
||||
$ref: /schemas/graph.yaml#/properties/ports
|
||||
|
||||
|
|
@ -98,7 +101,21 @@ examples:
|
|||
reg = <1>;
|
||||
ps8640_out: endpoint {
|
||||
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>;
|
||||
};
|
||||
};
|
||||
};
|
||||
};
|
||||
};
|
||||
|
|
|
|||
|
|
@ -7,7 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml#
|
|||
title: Synopsys DesignWare MIPI DSI host controller
|
||||
|
||||
maintainers:
|
||||
- Philippe CORNU <philippe.cornu@st.com>
|
||||
- Philippe CORNU <philippe.cornu@foss.st.com>
|
||||
|
||||
description: |
|
||||
This document defines device tree properties for the Synopsys DesignWare MIPI
|
||||
|
|
|
|||
|
|
@ -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>;
|
||||
};
|
||||
};
|
||||
};
|
||||
};
|
||||
|
|
@ -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>;
|
||||
};
|
||||
};
|
||||
};
|
||||
};
|
||||
};
|
||||
|
|
@ -45,7 +45,7 @@ additionalProperties: false
|
|||
|
||||
examples:
|
||||
- |
|
||||
#include <dt-bindings/clock/jz4770-cgu.h>
|
||||
#include <dt-bindings/clock/ingenic,jz4770-cgu.h>
|
||||
ipu@13080000 {
|
||||
compatible = "ingenic,jz4770-ipu", "ingenic,jz4760-ipu";
|
||||
reg = <0x13080000 0x800>;
|
||||
|
|
|
|||
|
|
@ -88,7 +88,7 @@ additionalProperties: false
|
|||
|
||||
examples:
|
||||
- |
|
||||
#include <dt-bindings/clock/jz4740-cgu.h>
|
||||
#include <dt-bindings/clock/ingenic,jz4740-cgu.h>
|
||||
lcd-controller@13050000 {
|
||||
compatible = "ingenic,jz4740-lcd";
|
||||
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 {
|
||||
compatible = "ingenic,jz4725b-lcd";
|
||||
reg = <0x13050000 0x1000>;
|
||||
|
|
|
|||
|
|
@ -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)
|
||||
|
||||
maintainers:
|
||||
- Philippe CORNU <philippe.cornu@st.com>
|
||||
- Philippe CORNU <philippe.cornu@foss.st.com>
|
||||
|
||||
description: |
|
||||
The Orise Tech OTM8009A is a 3.97" 480x800 TFT LCD panel connected using
|
||||
|
|
|
|||
|
|
@ -166,6 +166,8 @@ properties:
|
|||
- innolux,at070tn92
|
||||
# Innolux G070Y2-L01 7" WVGA (800x480) TFT LCD panel
|
||||
- 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,g101ice-l01
|
||||
# Innolux Corporation 12.1" WXGA (1280x800) TFT LCD panel
|
||||
|
|
@ -309,6 +311,8 @@ properties:
|
|||
- urt,umsh-8596md-11t
|
||||
- urt,umsh-8596md-19t
|
||||
- urt,umsh-8596md-20t
|
||||
# Vivax TPC-9150 tablet 9.0" WSVGA TFT LCD panel
|
||||
- vivax,tpc9150-panel
|
||||
# VXT 800x480 color TFT LCD panel
|
||||
- vxt,vl050-8048nt-c01
|
||||
# Winstar Display Corporation 3.5" QVGA (320x240) TFT LCD panel
|
||||
|
|
@ -317,6 +321,7 @@ properties:
|
|||
- yes-optoelectronics,ytc700tlag-05-201c
|
||||
|
||||
backlight: true
|
||||
ddc-i2c-bus: true
|
||||
enable-gpios: true
|
||||
port: true
|
||||
power-supply: true
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
||||
maintainers:
|
||||
- Philippe CORNU <philippe.cornu@st.com>
|
||||
- Philippe CORNU <philippe.cornu@foss.st.com>
|
||||
|
||||
description: |
|
||||
The Raydium Semiconductor Corporation RM68200 is a 5.5" 720x1280 TFT LCD
|
||||
|
|
|
|||
|
|
@ -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>;
|
||||
};
|
||||
};
|
||||
|
||||
...
|
||||
|
|
@ -7,8 +7,8 @@ $schema: http://devicetree.org/meta-schemas/core.yaml#
|
|||
title: STMicroelectronics STM32 DSI host controller
|
||||
|
||||
maintainers:
|
||||
- Philippe Cornu <philippe.cornu@st.com>
|
||||
- Yannick Fertre <yannick.fertre@st.com>
|
||||
- Philippe Cornu <philippe.cornu@foss.st.com>
|
||||
- Yannick Fertre <yannick.fertre@foss.st.com>
|
||||
|
||||
description:
|
||||
The STMicroelectronics STM32 DSI controller uses the Synopsys DesignWare MIPI-DSI host controller.
|
||||
|
|
|
|||
|
|
@ -7,8 +7,8 @@ $schema: http://devicetree.org/meta-schemas/core.yaml#
|
|||
title: STMicroelectronics STM32 lcd-tft display controller
|
||||
|
||||
maintainers:
|
||||
- Philippe Cornu <philippe.cornu@st.com>
|
||||
- Yannick Fertre <yannick.fertre@st.com>
|
||||
- Philippe Cornu <philippe.cornu@foss.st.com>
|
||||
- Yannick Fertre <yannick.fertre@foss.st.com>
|
||||
|
||||
properties:
|
||||
compatible:
|
||||
|
|
|
|||
|
|
@ -68,7 +68,7 @@ unevaluatedProperties: false
|
|||
|
||||
examples:
|
||||
- |
|
||||
#include <dt-bindings/clock/jz4780-cgu.h>
|
||||
#include <dt-bindings/clock/ingenic,jz4780-cgu.h>
|
||||
dma: dma-controller@13420000 {
|
||||
compatible = "ingenic,jz4780-dma";
|
||||
reg = <0x13420000 0x400>, <0x13421000 0x40>;
|
||||
|
|
|
|||
|
|
@ -15,6 +15,8 @@ Required properties:
|
|||
the secure world.
|
||||
- qcom,controlled-remotely : optional, indicates that the bam is controlled by
|
||||
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
|
||||
remotely controlled bam.
|
||||
- qcom,num-ees : optional, indicates supported number of Execution Environments
|
||||
|
|
|
|||
|
|
@ -50,7 +50,7 @@ description: |
|
|||
|
||||
|
||||
maintainers:
|
||||
- Amelie Delaunay <amelie.delaunay@st.com>
|
||||
- Amelie Delaunay <amelie.delaunay@foss.st.com>
|
||||
|
||||
allOf:
|
||||
- $ref: "dma-controller.yaml#"
|
||||
|
|
|
|||
|
|
@ -7,7 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml#
|
|||
title: STMicroelectronics STM32 DMA MUX (DMA request router) bindings
|
||||
|
||||
maintainers:
|
||||
- Amelie Delaunay <amelie.delaunay@st.com>
|
||||
- Amelie Delaunay <amelie.delaunay@foss.st.com>
|
||||
|
||||
allOf:
|
||||
- $ref: "dma-router.yaml#"
|
||||
|
|
|
|||
|
|
@ -50,7 +50,7 @@ description: |
|
|||
if no HW ack signal is used by the MDMA client
|
||||
|
||||
maintainers:
|
||||
- Amelie Delaunay <amelie.delaunay@st.com>
|
||||
- Amelie Delaunay <amelie.delaunay@foss.st.com>
|
||||
|
||||
allOf:
|
||||
- $ref: "dma-controller.yaml#"
|
||||
|
|
|
|||
|
|
@ -8,6 +8,7 @@ title: NXP i.MX8 DSP core
|
|||
|
||||
maintainers:
|
||||
- Daniel Baluta <daniel.baluta@nxp.com>
|
||||
- Shengjiu Wang <shengjiu.wang@nxp.com>
|
||||
|
||||
description: |
|
||||
Some boards from i.MX8 family contain a DSP core used for
|
||||
|
|
@ -19,6 +20,10 @@ properties:
|
|||
- fsl,imx8qxp-dsp
|
||||
- fsl,imx8qm-dsp
|
||||
- fsl,imx8mp-dsp
|
||||
- fsl,imx8qxp-hifi4
|
||||
- fsl,imx8qm-hifi4
|
||||
- fsl,imx8mp-hifi4
|
||||
- fsl,imx8ulp-hifi4
|
||||
|
||||
reg:
|
||||
maxItems: 1
|
||||
|
|
@ -28,37 +33,53 @@ properties:
|
|||
- description: ipg clock
|
||||
- description: ocram clock
|
||||
- description: core clock
|
||||
- description: debug interface clock
|
||||
- description: message unit clock
|
||||
minItems: 3
|
||||
|
||||
clock-names:
|
||||
items:
|
||||
- const: ipg
|
||||
- const: ocram
|
||||
- const: core
|
||||
- const: debug
|
||||
- const: mu
|
||||
minItems: 3
|
||||
|
||||
power-domains:
|
||||
description:
|
||||
List of phandle and PM domain specifier as documented in
|
||||
Documentation/devicetree/bindings/power/power_domain.txt
|
||||
minItems: 1
|
||||
maxItems: 4
|
||||
|
||||
mboxes:
|
||||
description:
|
||||
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)
|
||||
minItems: 3
|
||||
maxItems: 4
|
||||
|
||||
mbox-names:
|
||||
items:
|
||||
- const: txdb0
|
||||
- const: txdb1
|
||||
- const: rxdb0
|
||||
- const: rxdb1
|
||||
minItems: 3
|
||||
maxItems: 4
|
||||
|
||||
memory-region:
|
||||
description:
|
||||
phandle to a node describing reserved memory (System RAM memory)
|
||||
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:
|
||||
- compatible
|
||||
|
|
@ -70,6 +91,58 @@ required:
|
|||
- mbox-names
|
||||
- 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
|
||||
|
||||
examples:
|
||||
|
|
@ -91,3 +164,41 @@ examples:
|
|||
mboxes = <&lsio_mu13 2 0>, <&lsio_mu13 2 1>, <&lsio_mu13 3 0>, <&lsio_mu13 3 1>;
|
||||
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>;
|
||||
};
|
||||
|
|
|
|||
|
|
@ -97,6 +97,12 @@ properties:
|
|||
- items:
|
||||
- const: nxp,se97b
|
||||
- const: atmel,24c02
|
||||
- items:
|
||||
- const: onnn,cat24c04
|
||||
- const: atmel,24c04
|
||||
- items:
|
||||
- const: onnn,cat24c05
|
||||
- const: atmel,24c04
|
||||
- items:
|
||||
- const: renesas,r1ex24002
|
||||
- const: atmel,24c02
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
@ -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;
|
||||
};
|
||||
|
|
@ -29,6 +29,8 @@ properties:
|
|||
|
||||
gpio-controller: true
|
||||
|
||||
gpio-line-names: true
|
||||
|
||||
"#gpio-cells":
|
||||
const: 2
|
||||
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
||||
...
|
||||
|
|
@ -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>;
|
||||
};
|
||||
};
|
||||
|
||||
...
|
||||
|
|
@ -7,8 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml#
|
|||
title: STMicroelectronics STM32 Hardware Spinlock bindings
|
||||
|
||||
maintainers:
|
||||
- Benjamin Gaignard <benjamin.gaignard@st.com>
|
||||
- Fabien Dessenne <fabien.dessenne@st.com>
|
||||
- Fabien Dessenne <fabien.dessenne@foss.st.com>
|
||||
|
||||
properties:
|
||||
"#hwlock-cells":
|
||||
|
|
|
|||
|
|
@ -55,7 +55,7 @@ examples:
|
|||
#size-cells = <0>;
|
||||
|
||||
axp221: pmic@68 {
|
||||
compatible = "x-powers,axp221";
|
||||
/* compatible = "x-powers,axp221"; */
|
||||
reg = <0x68>;
|
||||
};
|
||||
};
|
||||
|
|
|
|||
|
|
@ -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>;
|
||||
};
|
||||
|
|
@ -57,7 +57,9 @@ properties:
|
|||
const: ipg
|
||||
|
||||
clock-frequency:
|
||||
enum: [ 100000, 400000 ]
|
||||
minimum: 1
|
||||
default: 100000
|
||||
maximum: 400000
|
||||
|
||||
dmas:
|
||||
items:
|
||||
|
|
|
|||
|
|
@ -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>;
|
||||
};
|
||||
|
|
@ -60,7 +60,7 @@ unevaluatedProperties: false
|
|||
|
||||
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/interrupt-controller/irq.h>
|
||||
i2c@10054000 {
|
||||
|
|
|
|||
|
|
@ -7,7 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml#
|
|||
title: I2C controller embedded in STMicroelectronics STM32 I2C platform
|
||||
|
||||
maintainers:
|
||||
- Pierre-Yves MORDRET <pierre-yves.mordret@st.com>
|
||||
- Pierre-Yves MORDRET <pierre-yves.mordret@foss.st.com>
|
||||
|
||||
allOf:
|
||||
- $ref: /schemas/i2c/i2c-controller.yaml#
|
||||
|
|
|
|||
|
|
@ -74,7 +74,7 @@ additionalProperties: false
|
|||
|
||||
examples:
|
||||
- |
|
||||
#include <dt-bindings/clock/jz4740-cgu.h>
|
||||
#include <dt-bindings/clock/ingenic,jz4740-cgu.h>
|
||||
#include <dt-bindings/iio/adc/ingenic,adc.h>
|
||||
|
||||
adc@10070000 {
|
||||
|
|
|
|||
|
|
@ -7,7 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml#
|
|||
title: Device-Tree bindings for sigma delta modulator
|
||||
|
||||
maintainers:
|
||||
- Arnaud Pouliquen <arnaud.pouliquen@st.com>
|
||||
- Arnaud Pouliquen <arnaud.pouliquen@foss.st.com>
|
||||
|
||||
properties:
|
||||
compatible:
|
||||
|
|
|
|||
|
|
@ -19,7 +19,7 @@ description: |
|
|||
Each STM32 ADC block can have up to 3 ADC instances.
|
||||
|
||||
maintainers:
|
||||
- Fabrice Gasnier <fabrice.gasnier@st.com>
|
||||
- Fabrice Gasnier <fabrice.gasnier@foss.st.com>
|
||||
|
||||
properties:
|
||||
compatible:
|
||||
|
|
|
|||
|
|
@ -7,8 +7,8 @@ $schema: http://devicetree.org/meta-schemas/core.yaml#
|
|||
title: STMicroelectronics STM32 DFSDM ADC device driver
|
||||
|
||||
maintainers:
|
||||
- Fabrice Gasnier <fabrice.gasnier@st.com>
|
||||
- Olivier Moysan <olivier.moysan@st.com>
|
||||
- Fabrice Gasnier <fabrice.gasnier@foss.st.com>
|
||||
- Olivier Moysan <olivier.moysan@foss.st.com>
|
||||
|
||||
description: |
|
||||
STM32 DFSDM ADC is a sigma delta analog-to-digital converter dedicated to
|
||||
|
|
|
|||
|
|
@ -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>;
|
||||
};
|
||||
|
|
@ -15,7 +15,7 @@ description: |
|
|||
current.
|
||||
|
||||
maintainers:
|
||||
- Fabrice Gasnier <fabrice.gasnier@st.com>
|
||||
- Fabrice Gasnier <fabrice.gasnier@foss.st.com>
|
||||
|
||||
properties:
|
||||
compatible:
|
||||
|
|
|
|||
|
|
@ -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>;
|
||||
};
|
||||
};
|
||||
|
|
@ -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.
|
||||
- post-power-on-delay-ms: time required by the device after enabling its regulators
|
||||
or powering it on, before it is ready for communication.
|
||||
- touchscreen-inverted-x: See touchscreen.txt
|
||||
- touchscreen-inverted-y: See touchscreen.txt
|
||||
|
||||
Example:
|
||||
|
||||
|
|
|
|||
|
|
@ -19,6 +19,7 @@ properties:
|
|||
- microchip,cap1106
|
||||
- microchip,cap1126
|
||||
- microchip,cap1188
|
||||
- microchip,cap1206
|
||||
|
||||
reg:
|
||||
maxItems: 1
|
||||
|
|
|
|||
|
|
@ -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>;
|
||||
};
|
||||
|
|
@ -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>;
|
||||
};
|
||||
}
|
||||
|
|
@ -7,8 +7,8 @@ $schema: http://devicetree.org/meta-schemas/core.yaml#
|
|||
title: STM32 External Interrupt Controller Device Tree Bindings
|
||||
|
||||
maintainers:
|
||||
- Alexandre Torgue <alexandre.torgue@st.com>
|
||||
- Ludovic Barre <ludovic.barre@st.com>
|
||||
- Alexandre Torgue <alexandre.torgue@foss.st.com>
|
||||
- Ludovic Barre <ludovic.barre@foss.st.com>
|
||||
|
||||
properties:
|
||||
compatible:
|
||||
|
|
|
|||
|
|
@ -13,8 +13,8 @@ description:
|
|||
channels (N) can be read from a dedicated register.
|
||||
|
||||
maintainers:
|
||||
- Fabien Dessenne <fabien.dessenne@st.com>
|
||||
- Arnaud Pouliquen <arnaud.pouliquen@st.com>
|
||||
- Fabien Dessenne <fabien.dessenne@foss.st.com>
|
||||
- Arnaud Pouliquen <arnaud.pouliquen@foss.st.com>
|
||||
|
||||
properties:
|
||||
compatible:
|
||||
|
|
|
|||
|
|
@ -30,7 +30,6 @@ properties:
|
|||
|
||||
power-domain-names:
|
||||
minItems: 2
|
||||
maxItems: 3
|
||||
items:
|
||||
- const: venus
|
||||
- const: vcodec0
|
||||
|
|
|
|||
|
|
@ -7,8 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml#
|
|||
title: STMicroelectronics STM32 CEC bindings
|
||||
|
||||
maintainers:
|
||||
- Benjamin Gaignard <benjamin.gaignard@st.com>
|
||||
- Yannick Fertre <yannick.fertre@st.com>
|
||||
- Yannick Fertre <yannick.fertre@foss.st.com>
|
||||
|
||||
properties:
|
||||
compatible:
|
||||
|
|
|
|||
|
|
@ -7,7 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml#
|
|||
title: STMicroelectronics STM32 Digital Camera Memory Interface (DCMI) binding
|
||||
|
||||
maintainers:
|
||||
- Hugues Fruchet <hugues.fruchet@st.com>
|
||||
- Hugues Fruchet <hugues.fruchet@foss.st.com>
|
||||
|
||||
properties:
|
||||
compatible:
|
||||
|
|
|
|||
|
|
@ -84,7 +84,7 @@ additionalProperties: false
|
|||
|
||||
examples:
|
||||
- |
|
||||
#include <dt-bindings/clock/jz4780-cgu.h>
|
||||
#include <dt-bindings/clock/ingenic,jz4780-cgu.h>
|
||||
#include <dt-bindings/gpio/gpio.h>
|
||||
nemc: memory-controller@13410000 {
|
||||
compatible = "ingenic,jz4780-nemc";
|
||||
|
|
|
|||
|
|
@ -19,7 +19,7 @@ description: |
|
|||
Select. The FMC2 performs only one access at a time to an external device.
|
||||
|
||||
maintainers:
|
||||
- Christophe Kerello <christophe.kerello@st.com>
|
||||
- Christophe Kerello <christophe.kerello@foss.st.com>
|
||||
|
||||
properties:
|
||||
compatible:
|
||||
|
|
|
|||
|
|
@ -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";
|
||||
};
|
||||
};
|
||||
|
|
@ -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 */
|
||||
};
|
||||
};
|
||||
};
|
||||
|
|
@ -36,9 +36,15 @@ patternProperties:
|
|||
'^clock-controller@[a-f0-9]+$':
|
||||
$ref: ../clock/brcm,iproc-clocks.yaml
|
||||
|
||||
'^phy@[a-f0-9]+$':
|
||||
$ref: ../phy/bcm-ns-usb2-phy.yaml
|
||||
|
||||
'^pin-controller@[a-f0-9]+$':
|
||||
$ref: ../pinctrl/brcm,ns-pinmux.yaml
|
||||
|
||||
'^syscon@[a-f0-9]+$':
|
||||
$ref: syscon.yaml
|
||||
|
||||
'^thermal@[a-f0-9]+$':
|
||||
$ref: ../thermal/brcm,ns-thermal.yaml
|
||||
|
||||
|
|
@ -49,6 +55,7 @@ required:
|
|||
|
||||
examples:
|
||||
- |
|
||||
#include <dt-bindings/clock/bcm-nsp.h>
|
||||
cru-bus@1800c100 {
|
||||
compatible = "brcm,ns-cru", "simple-mfd";
|
||||
reg = <0x1800c100 0x1d0>;
|
||||
|
|
@ -73,6 +80,20 @@ examples:
|
|||
"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 {
|
||||
compatible = "brcm,bcm4708-pinmux";
|
||||
reg = <0x1c0 0x24>;
|
||||
|
|
|
|||
|
|
@ -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>;
|
||||
};
|
||||
};
|
||||
|
|
@ -71,7 +71,7 @@ max14577@25 {
|
|||
compatible = "maxim,max14577";
|
||||
reg = <0x25>;
|
||||
interrupt-parent = <&gpx1>;
|
||||
interrupts = <5 IRQ_TYPE_NONE>;
|
||||
interrupts = <5 IRQ_TYPE_LEVEL_LOW>;
|
||||
|
||||
muic: max14577-muic {
|
||||
compatible = "maxim,max14577-muic";
|
||||
|
|
@ -106,7 +106,7 @@ max77836@25 {
|
|||
compatible = "maxim,max77836";
|
||||
reg = <0x25>;
|
||||
interrupt-parent = <&gpx1>;
|
||||
interrupts = <5 IRQ_TYPE_NONE>;
|
||||
interrupts = <5 IRQ_TYPE_LEVEL_LOW>;
|
||||
|
||||
muic: max77836-muic {
|
||||
compatible = "maxim,max77836-muic";
|
||||
|
|
|
|||
|
|
@ -21,6 +21,6 @@ Example:
|
|||
max77686: pmic@9 {
|
||||
compatible = "maxim,max77686";
|
||||
interrupt-parent = <&wakeup_eint>;
|
||||
interrupts = <26 0>;
|
||||
interrupts = <26 IRQ_TYPE_LEVEL_LOW>;
|
||||
reg = <0x09>;
|
||||
};
|
||||
|
|
|
|||
|
|
@ -139,7 +139,7 @@ Example:
|
|||
compatible = "maxim,max77693";
|
||||
reg = <0x66>;
|
||||
interrupt-parent = <&gpx1>;
|
||||
interrupts = <5 2>;
|
||||
interrupts = <5 IRQ_TYPE_LEVEL_LOW>;
|
||||
|
||||
regulators {
|
||||
esafeout@1 {
|
||||
|
|
|
|||
|
|
@ -15,29 +15,38 @@ each. A function can consume one or more of these fixed-size register regions.
|
|||
|
||||
Required properties:
|
||||
- compatible: Should contain one of:
|
||||
"qcom,pm8941",
|
||||
"qcom,pm8841",
|
||||
"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,pm660",
|
||||
"qcom,pm660l",
|
||||
"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,smb2351",
|
||||
or generalized "qcom,spmi-pmic".
|
||||
- reg: Specifies the SPMI USID slave address for this device.
|
||||
For more information see:
|
||||
|
|
|
|||
Some files were not shown because too many files have changed in this diff Show More
Loading…
Reference in New Issue