public-mirrors/linux
1
0
Fork 0
mirror of git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git synced 2025-09-18 22:14:16 +00:00
Code Issues Projects Releases Packages Wiki Activity Actions

Merge branch 'for-5.18/amd-sfh' into for-linus

Browse source 
- dead code elimination (Christophe JAILLET)
This commit is contained in:
Jiri Kosina 2022-03-23 09:58:40 +01:00
commit b690490d6d
5436 changed files with 192303 additions and 109938 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

1
.clang-format
View file

@ -216,7 +216,6 @@ ForEachMacros:
- 'for_each_migratetype_order'
- 'for_each_msi_entry'
- 'for_each_msi_entry_safe'
- 'for_each_msi_vector'
- 'for_each_net'
- 'for_each_net_continue_reverse'
- 'for_each_netdev'

2
.mailmap
View file

@ -49,10 +49,12 @@ Andy Adamson <andros@citi.umich.edu>
Antoine Tenart <atenart@kernel.org> <antoine.tenart@bootlin.com>
Antoine Tenart <atenart@kernel.org> <antoine.tenart@free-electrons.com>
Antonio Ospite <ao2@ao2.it> <ao2@amarulasolutions.com>
Anup Patel <anup@brainfault.org> <anup.patel@wdc.com>
Archit Taneja <archit@ti.com>
Ard Biesheuvel <ardb@kernel.org> <ard.biesheuvel@linaro.org>
Arnaud Patard <arnaud.patard@rtp-net.org>
Arnd Bergmann <arnd@arndb.de>
Atish Patra <atishp@atishpatra.org> <atish.patra@wdc.com>
Axel Dyks <xl@xlsigned.net>
Axel Lin <axel.lin@gmail.com>
Bart Van Assche <bvanassche@acm.org> <bart.vanassche@sandisk.com>

5
CREDITS
View file

@ -315,6 +315,11 @@ S: Via Delle Palme, 9
S: Terni 05100
S: Italy
N: Ohad Ben Cohen
E: ohad@wizery.com
D: Remote Processor (remoteproc) subsystem
D: Remote Processor Messaging (rpmsg) subsystem
N: Krzysztof Benedyczak
E: golbi@mat.uni.torun.pl
W: http://www.mat.uni.torun.pl/~golbi

22
Documentation/ABI/obsolete/sysfs-class-dax
View file

@ -1,22 +0,0 @@
What: /sys/class/dax/
Date: May, 2016
KernelVersion: v4.7
Contact: nvdimm@lists.linux.dev
Description: Device DAX is the device-centric analogue of Filesystem
DAX (CONFIG_FS_DAX). It allows memory ranges to be
allocated and mapped without need of an intervening file
system. Device DAX is strict, precise and predictable.
Specifically this interface:
1. Guarantees fault granularity with respect to a given
page size (pte, pmd, or pud) set at configuration time.
2. Enforces deterministic behavior by being strict about
what fault scenarios are supported.
The /sys/class/dax/ interface enumerates all the
device-dax instances in the system. The ABI is
deprecated and will be removed after 2020. It is
replaced with the DAX bus interface /sys/bus/dax/ where
device-dax instances can be found under
/sys/bus/dax/devices/

676
Documentation/ABI/stable/sysfs-block Normal file
View file

@ -0,0 +1,676 @@
What: /sys/block/<disk>/alignment_offset
Date: April 2009
Contact: Martin K. Petersen <martin.petersen@oracle.com>
Description:
Storage devices may report a physical block size that is
bigger than the logical block size (for instance a drive
with 4KB physical sectors exposing 512-byte logical
blocks to the operating system). This parameter
indicates how many bytes the beginning of the device is
offset from the disk's natural alignment.
What: /sys/block/<disk>/discard_alignment
Date: May 2011
Contact: Martin K. Petersen <martin.petersen@oracle.com>
Description:
Devices that support discard functionality may
internally allocate space in units that are bigger than
the exported logical block size. The discard_alignment
parameter indicates how many bytes the beginning of the
device is offset from the internal allocation unit's
natural alignment.
What: /sys/block/<disk>/diskseq
Date: February 2021
Contact: Matteo Croce <mcroce@microsoft.com>
Description:
The /sys/block/<disk>/diskseq files reports the disk
sequence number, which is a monotonically increasing
number assigned to every drive.
Some devices, like the loop device, refresh such number
every time the backing file is changed.
The value type is 64 bit unsigned.
What: /sys/block/<disk>/inflight
Date: October 2009
Contact: Jens Axboe <axboe@kernel.dk>, Nikanth Karthikesan <knikanth@suse.de>
Description:
Reports the number of I/O requests currently in progress
(pending / in flight) in a device driver. This can be less
than the number of requests queued in the block device queue.
The report contains 2 fields: one for read requests
and one for write requests.
The value type is unsigned int.
Cf. Documentation/block/stat.rst which contains a single value for
requests in flight.
This is related to /sys/block/<disk>/queue/nr_requests
and for SCSI device also its queue_depth.
What: /sys/block/<disk>/integrity/device_is_integrity_capable
Date: July 2014
Contact: Martin K. Petersen <martin.petersen@oracle.com>
Description:
Indicates whether a storage device is capable of storing
integrity metadata. Set if the device is T10 PI-capable.
What: /sys/block/<disk>/integrity/format
Date: June 2008
Contact: Martin K. Petersen <martin.petersen@oracle.com>
Description:
Metadata format for integrity capable block device.
E.g. T10-DIF-TYPE1-CRC.
What: /sys/block/<disk>/integrity/protection_interval_bytes
Date: July 2015
Contact: Martin K. Petersen <martin.petersen@oracle.com>
Description:
Describes the number of data bytes which are protected
by one integrity tuple. Typically the device's logical
block size.
What: /sys/block/<disk>/integrity/read_verify
Date: June 2008
Contact: Martin K. Petersen <martin.petersen@oracle.com>
Description:
Indicates whether the block layer should verify the
integrity of read requests serviced by devices that
support sending integrity metadata.
What: /sys/block/<disk>/integrity/tag_size
Date: June 2008
Contact: Martin K. Petersen <martin.petersen@oracle.com>
Description:
Number of bytes of integrity tag space available per
512 bytes of data.
What: /sys/block/<disk>/integrity/write_generate
Date: June 2008
Contact: Martin K. Petersen <martin.petersen@oracle.com>
Description:
Indicates whether the block layer should automatically
generate checksums for write requests bound for
devices that support receiving integrity metadata.
What: /sys/block/<disk>/<partition>/alignment_offset
Date: April 2009
Contact: Martin K. Petersen <martin.petersen@oracle.com>
Description:
Storage devices may report a physical block size that is
bigger than the logical block size (for instance a drive
with 4KB physical sectors exposing 512-byte logical
blocks to the operating system). This parameter
indicates how many bytes the beginning of the partition
is offset from the disk's natural alignment.
What: /sys/block/<disk>/<partition>/discard_alignment
Date: May 2011
Contact: Martin K. Petersen <martin.petersen@oracle.com>
Description:
Devices that support discard functionality may
internally allocate space in units that are bigger than
the exported logical block size. The discard_alignment
parameter indicates how many bytes the beginning of the
partition is offset from the internal allocation unit's
natural alignment.
What: /sys/block/<disk>/<partition>/stat
Date: February 2008
Contact: Jerome Marchand <jmarchan@redhat.com>
Description:
The /sys/block/<disk>/<partition>/stat files display the
I/O statistics of partition <partition>. The format is the
same as the format of /sys/block/<disk>/stat.
What: /sys/block/<disk>/queue/add_random
Date: June 2010
Contact: linux-block@vger.kernel.org
Description:
[RW] This file allows to turn off the disk entropy contribution.
Default value of this file is '1'(on).
What: /sys/block/<disk>/queue/chunk_sectors
Date: September 2016
Contact: Hannes Reinecke <hare@suse.com>
Description:
[RO] chunk_sectors has different meaning depending on the type
of the disk. For a RAID device (dm-raid), chunk_sectors
indicates the size in 512B sectors of the RAID volume stripe
segment. For a zoned block device, either host-aware or
host-managed, chunk_sectors indicates the size in 512B sectors
of the zones of the device, with the eventual exception of the
last zone of the device which may be smaller.
What: /sys/block/<disk>/queue/dax
Date: June 2016
Contact: linux-block@vger.kernel.org
Description:
[RO] This file indicates whether the device supports Direct
Access (DAX), used by CPU-addressable storage to bypass the
pagecache. It shows '1' if true, '0' if not.
What: /sys/block/<disk>/queue/discard_granularity
Date: May 2011
Contact: Martin K. Petersen <martin.petersen@oracle.com>
Description:
[RO] Devices that support discard functionality may internally
allocate space using units that are bigger than the logical
block size. The discard_granularity parameter indicates the size
of the internal allocation unit in bytes if reported by the
device. Otherwise the discard_granularity will be set to match
the device's physical block size. A discard_granularity of 0
means that the device does not support discard functionality.
What: /sys/block/<disk>/queue/discard_max_bytes
Date: May 2011
Contact: Martin K. Petersen <martin.petersen@oracle.com>
Description:
[RW] While discard_max_hw_bytes is the hardware limit for the
device, this setting is the software limit. Some devices exhibit
large latencies when large discards are issued, setting this
value lower will make Linux issue smaller discards and
potentially help reduce latencies induced by large discard
operations.
What: /sys/block/<disk>/queue/discard_max_hw_bytes
Date: July 2015
Contact: linux-block@vger.kernel.org
Description:
[RO] Devices that support discard functionality may have
internal limits on the number of bytes that can be trimmed or
unmapped in a single operation. The `discard_max_hw_bytes`
parameter is set by the device driver to the maximum number of
bytes that can be discarded in a single operation. Discard
requests issued to the device must not exceed this limit. A
`discard_max_hw_bytes` value of 0 means that the device does not
support discard functionality.
What: /sys/block/<disk>/queue/discard_zeroes_data
Date: May 2011
Contact: Martin K. Petersen <martin.petersen@oracle.com>
Description:
[RO] Will always return 0. Don't rely on any specific behavior
for discards, and don't read this file.
What: /sys/block/<disk>/queue/fua
Date: May 2018
Contact: linux-block@vger.kernel.org
Description:
[RO] Whether or not the block driver supports the FUA flag for
write requests. FUA stands for Force Unit Access. If the FUA
flag is set that means that write requests must bypass the
volatile cache of the storage device.
What: /sys/block/<disk>/queue/hw_sector_size
Date: January 2008
Contact: linux-block@vger.kernel.org
Description:
[RO] This is the hardware sector size of the device, in bytes.
What: /sys/block/<disk>/queue/independent_access_ranges/
Date: October 2021
Contact: linux-block@vger.kernel.org
Description:
[RO] The presence of this sub-directory of the
/sys/block/xxx/queue/ directory indicates that the device is
capable of executing requests targeting different sector ranges
in parallel. For instance, single LUN multi-actuator hard-disks
will have an independent_access_ranges directory if the device
correctly advertizes the sector ranges of its actuators.
The independent_access_ranges directory contains one directory
per access range, with each range described using the sector
(RO) attribute file to indicate the first sector of the range
and the nr_sectors (RO) attribute file to indicate the total
number of sectors in the range starting from the first sector of
the range. For example, a dual-actuator hard-disk will have the
following independent_access_ranges entries.::
$ tree /sys/block/<disk>/queue/independent_access_ranges/
/sys/block/<disk>/queue/independent_access_ranges/
|-- 0
| |-- nr_sectors
| `-- sector
`-- 1
|-- nr_sectors
`-- sector
The sector and nr_sectors attributes use 512B sector unit,
regardless of the actual block size of the device. Independent
access ranges do not overlap and include all sectors within the
device capacity. The access ranges are numbered in increasing
order of the range start sector, that is, the sector attribute
of range 0 always has the value 0.
What: /sys/block/<disk>/queue/io_poll
Date: November 2015
Contact: linux-block@vger.kernel.org
Description:
[RW] When read, this file shows whether polling is enabled (1)
or disabled (0). Writing '0' to this file will disable polling
for this device. Writing any non-zero value will enable this
feature.
What: /sys/block/<disk>/queue/io_poll_delay
Date: November 2016
Contact: linux-block@vger.kernel.org
Description:
[RW] If polling is enabled, this controls what kind of polling
will be performed. It defaults to -1, which is classic polling.
In this mode, the CPU will repeatedly ask for completions
without giving up any time. If set to 0, a hybrid polling mode
is used, where the kernel will attempt to make an educated guess
at when the IO will complete. Based on this guess, the kernel
will put the process issuing IO to sleep for an amount of time,
before entering a classic poll loop. This mode might be a little
slower than pure classic polling, but it will be more efficient.
If set to a value larger than 0, the kernel will put the process
issuing IO to sleep for this amount of microseconds before
entering classic polling.
What: /sys/block/<disk>/queue/io_timeout
Date: November 2018
Contact: Weiping Zhang <zhangweiping@didiglobal.com>
Description:
[RW] io_timeout is the request timeout in milliseconds. If a
request does not complete in this time then the block driver
timeout handler is invoked. That timeout handler can decide to
retry the request, to fail it or to start a device recovery
strategy.
What: /sys/block/<disk>/queue/iostats
Date: January 2009
Contact: linux-block@vger.kernel.org
Description:
[RW] This file is used to control (on/off) the iostats
accounting of the disk.
What: /sys/block/<disk>/queue/logical_block_size
Date: May 2009
Contact: Martin K. Petersen <martin.petersen@oracle.com>
Description:
[RO] This is the smallest unit the storage device can address.
It is typically 512 bytes.
What: /sys/block/<disk>/queue/max_active_zones
Date: July 2020
Contact: Niklas Cassel <niklas.cassel@wdc.com>
Description:
[RO] For zoned block devices (zoned attribute indicating
"host-managed" or "host-aware"), the sum of zones belonging to
any of the zone states: EXPLICIT OPEN, IMPLICIT OPEN or CLOSED,
is limited by this value. If this value is 0, there is no limit.
If the host attempts to exceed this limit, the driver should
report this error with BLK_STS_ZONE_ACTIVE_RESOURCE, which user
space may see as the EOVERFLOW errno.
What: /sys/block/<disk>/queue/max_discard_segments
Date: February 2017
Contact: linux-block@vger.kernel.org
Description:
[RO] The maximum number of DMA scatter/gather entries in a
discard request.
What: /sys/block/<disk>/queue/max_hw_sectors_kb
Date: September 2004
Contact: linux-block@vger.kernel.org
Description:
[RO] This is the maximum number of kilobytes supported in a
single data transfer.
What: /sys/block/<disk>/queue/max_integrity_segments
Date: September 2010
Contact: linux-block@vger.kernel.org
Description:
[RO] Maximum number of elements in a DMA scatter/gather list
with integrity data that will be submitted by the block layer
core to the associated block driver.
What: /sys/block/<disk>/queue/max_open_zones
Date: July 2020
Contact: Niklas Cassel <niklas.cassel@wdc.com>
Description:
[RO] For zoned block devices (zoned attribute indicating
"host-managed" or "host-aware"), the sum of zones belonging to
any of the zone states: EXPLICIT OPEN or IMPLICIT OPEN, is
limited by this value. If this value is 0, there is no limit.
What: /sys/block/<disk>/queue/max_sectors_kb
Date: September 2004
Contact: linux-block@vger.kernel.org
Description:
[RW] This is the maximum number of kilobytes that the block
layer will allow for a filesystem request. Must be smaller than
or equal to the maximum size allowed by the hardware.
What: /sys/block/<disk>/queue/max_segment_size
Date: March 2010
Contact: linux-block@vger.kernel.org
Description:
[RO] Maximum size in bytes of a single element in a DMA
scatter/gather list.
What: /sys/block/<disk>/queue/max_segments
Date: March 2010
Contact: linux-block@vger.kernel.org
Description:
[RO] Maximum number of elements in a DMA scatter/gather list
that is submitted to the associated block driver.
What: /sys/block/<disk>/queue/minimum_io_size
Date: April 2009
Contact: Martin K. Petersen <martin.petersen@oracle.com>
Description:
[RO] Storage devices may report a granularity or preferred
minimum I/O size which is the smallest request the device can
perform without incurring a performance penalty. For disk
drives this is often the physical block size. For RAID arrays
it is often the stripe chunk size. A properly aligned multiple
of minimum_io_size is the preferred request size for workloads
where a high number of I/O operations is desired.
What: /sys/block/<disk>/queue/nomerges
Date: January 2010
Contact: linux-block@vger.kernel.org
Description:
[RW] Standard I/O elevator operations include attempts to merge
contiguous I/Os. For known random I/O loads these attempts will
always fail and result in extra cycles being spent in the
kernel. This allows one to turn off this behavior on one of two
ways: When set to 1, complex merge checks are disabled, but the
simple one-shot merges with the previous I/O request are
enabled. When set to 2, all merge tries are disabled. The
default value is 0 - which enables all types of merge tries.
What: /sys/block/<disk>/queue/nr_requests
Date: July 2003
Contact: linux-block@vger.kernel.org
Description:
[RW] This controls how many requests may be allocated in the
block layer for read or write requests. Note that the total
allocated number may be twice this amount, since it applies only
to reads or writes (not the accumulated sum).
To avoid priority inversion through request starvation, a
request queue maintains a separate request pool per each cgroup
when CONFIG_BLK_CGROUP is enabled, and this parameter applies to
each such per-block-cgroup request pool. IOW, if there are N
block cgroups, each request queue may have up to N request
pools, each independently regulated by nr_requests.
What: /sys/block/<disk>/queue/nr_zones
Date: November 2018
Contact: Damien Le Moal <damien.lemoal@wdc.com>
Description:
[RO] nr_zones indicates the total number of zones of a zoned
block device ("host-aware" or "host-managed" zone model). For
regular block devices, the value is always 0.
What: /sys/block/<disk>/queue/optimal_io_size
Date: April 2009
Contact: Martin K. Petersen <martin.petersen@oracle.com>
Description:
[RO] Storage devices may report an optimal I/O size, which is
the device's preferred unit for sustained I/O. This is rarely
reported for disk drives. For RAID arrays it is usually the
stripe width or the internal track size. A properly aligned
multiple of optimal_io_size is the preferred request size for
workloads where sustained throughput is desired. If no optimal
I/O size is reported this file contains 0.
What: /sys/block/<disk>/queue/physical_block_size
Date: May 2009
Contact: Martin K. Petersen <martin.petersen@oracle.com>
Description:
[RO] This is the smallest unit a physical storage device can
write atomically. It is usually the same as the logical block
size but may be bigger. One example is SATA drives with 4KB
sectors that expose a 512-byte logical block size to the
operating system. For stacked block devices the
physical_block_size variable contains the maximum
physical_block_size of the component devices.
What: /sys/block/<disk>/queue/read_ahead_kb
Date: May 2004
Contact: linux-block@vger.kernel.org
Description:
[RW] Maximum number of kilobytes to read-ahead for filesystems
on this block device.
What: /sys/block/<disk>/queue/rotational
Date: January 2009
Contact: linux-block@vger.kernel.org
Description:
[RW] This file is used to stat if the device is of rotational
type or non-rotational type.
What: /sys/block/<disk>/queue/rq_affinity
Date: September 2008
Contact: linux-block@vger.kernel.org
Description:
[RW] If this option is '1', the block layer will migrate request
completions to the cpu "group" that originally submitted the
request. For some workloads this provides a significant
reduction in CPU cycles due to caching effects.
For storage configurations that need to maximize distribution of
completion processing setting this option to '2' forces the
completion to run on the requesting cpu (bypassing the "group"
aggregation logic).
What: /sys/block/<disk>/queue/scheduler
Date: October 2004
Contact: linux-block@vger.kernel.org
Description:
[RW] When read, this file will display the current and available
IO schedulers for this block device. The currently active IO
scheduler will be enclosed in [] brackets. Writing an IO
scheduler name to this file will switch control of this block
device to that new IO scheduler. Note that writing an IO
scheduler name to this file will attempt to load that IO
scheduler module, if it isn't already present in the system.
What: /sys/block/<disk>/queue/stable_writes
Date: September 2020
Contact: linux-block@vger.kernel.org
Description:
[RW] This file will contain '1' if memory must not be modified
while it is being used in a write request to this device. When
this is the case and the kernel is performing writeback of a
page, the kernel will wait for writeback to complete before
allowing the page to be modified again, rather than allowing
immediate modification as is normally the case. This
restriction arises when the device accesses the memory multiple
times where the same data must be seen every time -- for
example, once to calculate a checksum and once to actually write
the data. If no such restriction exists, this file will contain
'0'. This file is writable for testing purposes.
What: /sys/block/<disk>/queue/throttle_sample_time
Date: March 2017
Contact: linux-block@vger.kernel.org
Description:
[RW] This is the time window that blk-throttle samples data, in
millisecond. blk-throttle makes decision based on the
samplings. Lower time means cgroups have more smooth throughput,
but higher CPU overhead. This exists only when
CONFIG_BLK_DEV_THROTTLING_LOW is enabled.
What: /sys/block/<disk>/queue/virt_boundary_mask
Date: April 2021
Contact: linux-block@vger.kernel.org
Description:
[RO] This file shows the I/O segment memory alignment mask for
the block device. I/O requests to this device will be split
between segments wherever either the memory address of the end
of the previous segment or the memory address of the beginning
of the current segment is not aligned to virt_boundary_mask + 1
bytes.
What: /sys/block/<disk>/queue/wbt_lat_usec
Date: November 2016
Contact: linux-block@vger.kernel.org
Description:
[RW] If the device is registered for writeback throttling, then
this file shows the target minimum read latency. If this latency
is exceeded in a given window of time (see wb_window_usec), then
the writeback throttling will start scaling back writes. Writing
a value of '0' to this file disables the feature. Writing a
value of '-1' to this file resets the value to the default
setting.
What: /sys/block/<disk>/queue/write_cache
Date: April 2016
Contact: linux-block@vger.kernel.org
Description:
[RW] When read, this file will display whether the device has
write back caching enabled or not. It will return "write back"
for the former case, and "write through" for the latter. Writing
to this file can change the kernels view of the device, but it
doesn't alter the device state. This means that it might not be
safe to toggle the setting from "write back" to "write through",
since that will also eliminate cache flushes issued by the
kernel.
What: /sys/block/<disk>/queue/write_same_max_bytes
Date: January 2012
Contact: Martin K. Petersen <martin.petersen@oracle.com>
Description:
[RO] Some devices support a write same operation in which a
single data block can be written to a range of several
contiguous blocks on storage. This can be used to wipe areas on
disk or to initialize drives in a RAID configuration.
write_same_max_bytes indicates how many bytes can be written in
a single write same command. If write_same_max_bytes is 0, write
same is not supported by the device.
What: /sys/block/<disk>/queue/write_zeroes_max_bytes
Date: November 2016
Contact: Chaitanya Kulkarni <chaitanya.kulkarni@wdc.com>
Description:
[RO] Devices that support write zeroes operation in which a
single request can be issued to zero out the range of contiguous
blocks on storage without having any payload in the request.
This can be used to optimize writing zeroes to the devices.
write_zeroes_max_bytes indicates how many bytes can be written
in a single write zeroes command. If write_zeroes_max_bytes is
0, write zeroes is not supported by the device.
What: /sys/block/<disk>/queue/zone_append_max_bytes
Date: May 2020
Contact: linux-block@vger.kernel.org
Description:
[RO] This is the maximum number of bytes that can be written to
a sequential zone of a zoned block device using a zone append
write operation (REQ_OP_ZONE_APPEND). This value is always 0 for
regular block devices.
What: /sys/block/<disk>/queue/zone_write_granularity
Date: January 2021
Contact: linux-block@vger.kernel.org
Description:
[RO] This indicates the alignment constraint, in bytes, for
write operations in sequential zones of zoned block devices
(devices with a zoned attributed that reports "host-managed" or
"host-aware"). This value is always 0 for regular block devices.
What: /sys/block/<disk>/queue/zoned
Date: September 2016
Contact: Damien Le Moal <damien.lemoal@wdc.com>
Description:
[RO] zoned indicates if the device is a zoned block device and
the zone model of the device if it is indeed zoned. The
possible values indicated by zoned are "none" for regular block
devices and "host-aware" or "host-managed" for zoned block
devices. The characteristics of host-aware and host-managed
zoned block devices are described in the ZBC (Zoned Block
Commands) and ZAC (Zoned Device ATA Command Set) standards.
These standards also define the "drive-managed" zone model.
However, since drive-managed zoned block devices do not support
zone commands, they will be treated as regular block devices and
zoned will report "none".
What: /sys/block/<disk>/stat
Date: February 2008
Contact: Jerome Marchand <jmarchan@redhat.com>
Description:
The /sys/block/<disk>/stat files displays the I/O
statistics of disk <disk>. They contain 11 fields:
== ==============================================
1 reads completed successfully
2 reads merged
3 sectors read
4 time spent reading (ms)
5 writes completed
6 writes merged
7 sectors written
8 time spent writing (ms)
9 I/Os currently in progress
10 time spent doing I/Os (ms)
11 weighted time spent doing I/Os (ms)
12 discards completed
13 discards merged
14 sectors discarded
15 time spent discarding (ms)
16 flush requests completed
17 time spent flushing (ms)
== ==============================================
For more details refer Documentation/admin-guide/iostats.rst

52
Documentation/ABI/stable/sysfs-driver-dma-idxd
View file

@ -41,14 +41,14 @@ KernelVersion: 5.6.0
Contact: dmaengine@vger.kernel.org
Description: The maximum number of groups can be created under this device.
What: /sys/bus/dsa/devices/dsa<m>/max_tokens
Date: Oct 25, 2019
KernelVersion: 5.6.0
What: /sys/bus/dsa/devices/dsa<m>/max_read_buffers
Date: Dec 10, 2021
KernelVersion: 5.17.0
Contact: dmaengine@vger.kernel.org
Description: The total number of bandwidth tokens supported by this device.
The bandwidth tokens represent resources within the DSA
Description: The total number of read buffers supported by this device.
The read buffers represent resources within the DSA
implementation, and these resources are allocated by engines to
support operations.
support operations. See DSA spec v1.2 9.2.4 Total Read Buffers.
What: /sys/bus/dsa/devices/dsa<m>/max_transfer_size
Date: Oct 25, 2019
@ -115,13 +115,13 @@ KernelVersion: 5.6.0
Contact: dmaengine@vger.kernel.org
Description: To indicate if this device is configurable or not.
What: /sys/bus/dsa/devices/dsa<m>/token_limit
Date: Oct 25, 2019
KernelVersion: 5.6.0
What: /sys/bus/dsa/devices/dsa<m>/read_buffer_limit
Date: Dec 10, 2021
KernelVersion: 5.17.0
Contact: dmaengine@vger.kernel.org
Description: The maximum number of bandwidth tokens that may be in use at
Description: The maximum number of read buffers that may be in use at
one time by operations that access low bandwidth memory in the
device.
device. See DSA spec v1.2 9.2.8 GENCFG on Global Read Buffer Limit.
What: /sys/bus/dsa/devices/dsa<m>/cmd_status
Date: Aug 28, 2020
@ -220,8 +220,38 @@ Contact: dmaengine@vger.kernel.org
Description: Show the current number of entries in this WQ if WQ Occupancy
Support bit WQ capabilities is 1.
What: /sys/bus/dsa/devices/wq<m>.<n>/enqcmds_retries
Date Oct 29, 2021
KernelVersion: 5.17.0
Contact: dmaengine@vger.kernel.org
Description: Indicate the number of retires for an enqcmds submission on a sharedwq.
A max value to set attribute is capped at 64.
What: /sys/bus/dsa/devices/engine<m>.<n>/group_id
Date: Oct 25, 2019
KernelVersion: 5.6.0
Contact: dmaengine@vger.kernel.org
Description: The group that this engine belongs to.
What: /sys/bus/dsa/devices/group<m>.<n>/use_read_buffer_limit
Date: Dec 10, 2021
KernelVersion: 5.17.0
Contact: dmaengine@vger.kernel.org
Description: Enable the use of global read buffer limit for the group. See DSA
spec v1.2 9.2.18 GRPCFG Use Global Read Buffer Limit.
What: /sys/bus/dsa/devices/group<m>.<n>/read_buffers_allowed
Date: Dec 10, 2021
KernelVersion: 5.17.0
Contact: dmaengine@vger.kernel.org
Description: Indicates max number of read buffers that may be in use at one time
by all engines in the group. See DSA spec v1.2 9.2.18 GRPCFG Read
Buffers Allowed.
What: /sys/bus/dsa/devices/group<m>.<n>/read_buffers_reserved
Date: Dec 10, 2021
KernelVersion: 5.17.0
Contact: dmaengine@vger.kernel.org
Description: Indicates the number of Read Buffers reserved for the use of
engines in the group. See DSA spec v1.2 9.2.18 GRPCFG Read Buffers
Reserved.

2
Documentation/ABI/testing/configfs-usb-gadget-uac1
View file

@ -27,6 +27,6 @@ Description:
(in 1/256 dB)
p_volume_res playback volume control resolution
(in 1/256 dB)
req_number the number of pre-allocated request
req_number the number of pre-allocated requests
for both capture and playback
===================== =======================================

2
Documentation/ABI/testing/configfs-usb-gadget-uac2
View file

@ -30,4 +30,6 @@ Description:
(in 1/256 dB)
p_volume_res playback volume control resolution
(in 1/256 dB)
req_number the number of pre-allocated requests
for both capture and playback
===================== =======================================

23
Documentation/ABI/testing/debugfs-driver-habanalabs
View file

@ -21,11 +21,11 @@ Description: Allow the root user to disable/enable in runtime the clock
a different engine to disable/enable its clock gating feature.
The bitmask is composed of 20 bits:
======= ============
======= ============
0 - 7 DMA channels
8 - 11 MME engines
12 - 19 TPC engines
======= ============
======= ============
The bit's location of a specific engine can be determined
using (1 << GAUDI_ENGINE_ID_*). GAUDI_ENGINE_ID_* values
@ -155,6 +155,13 @@ Description: Triggers an I2C transaction that is generated by the device's
CPU. Writing to this file generates a write transaction while
reading from the file generates a read transaction
What: /sys/kernel/debug/habanalabs/hl<n>/i2c_len
Date: Dec 2021
KernelVersion: 5.17
Contact: obitton@habana.ai
Description: Sets I2C length in bytes for I2C transaction that is generated by
the device's CPU
What: /sys/kernel/debug/habanalabs/hl<n>/i2c_reg
Date: Jan 2019
KernelVersion: 5.1
@ -226,12 +233,6 @@ Description: Gets the state dump occurring on a CS timeout or failure.
Writing an integer X discards X state dumps, so that the
next read would return X+1-st newest state dump.
What: /sys/kernel/debug/habanalabs/hl<n>/timeout_locked
Date: Sep 2021
KernelVersion: 5.16
Contact: obitton@habana.ai
Description: Sets the command submission timeout value in seconds.
What: /sys/kernel/debug/habanalabs/hl<n>/stop_on_err
Date: Mar 2020
KernelVersion: 5.6
@ -239,6 +240,12 @@ Contact: ogabbay@kernel.org
Description: Sets the stop-on_error option for the device engines. Value of
"0" is for disable, otherwise enable.
What: /sys/kernel/debug/habanalabs/hl<n>/timeout_locked
Date: Sep 2021
KernelVersion: 5.16
Contact: obitton@habana.ai
Description: Sets the command submission timeout value in seconds.
What: /sys/kernel/debug/habanalabs/hl<n>/userptr
Date: Jan 2019
KernelVersion: 5.1

346
Documentation/ABI/testing/sysfs-block
View file

@ -1,346 +0,0 @@
What: /sys/block/<disk>/stat
Date: February 2008
Contact: Jerome Marchand <jmarchan@redhat.com>
Description:
The /sys/block/<disk>/stat files displays the I/O
statistics of disk <disk>. They contain 11 fields:
== ==============================================
1 reads completed successfully
2 reads merged
3 sectors read
4 time spent reading (ms)
5 writes completed
6 writes merged
7 sectors written
8 time spent writing (ms)
9 I/Os currently in progress
10 time spent doing I/Os (ms)
11 weighted time spent doing I/Os (ms)
12 discards completed
13 discards merged
14 sectors discarded
15 time spent discarding (ms)
16 flush requests completed
17 time spent flushing (ms)
== ==============================================
For more details refer Documentation/admin-guide/iostats.rst
What: /sys/block/<disk>/inflight
Date: October 2009
Contact: Jens Axboe <axboe@kernel.dk>, Nikanth Karthikesan <knikanth@suse.de>
Description:
Reports the number of I/O requests currently in progress
(pending / in flight) in a device driver. This can be less
than the number of requests queued in the block device queue.
The report contains 2 fields: one for read requests
and one for write requests.
The value type is unsigned int.
Cf. Documentation/block/stat.rst which contains a single value for
requests in flight.
This is related to nr_requests in Documentation/block/queue-sysfs.rst
and for SCSI device also its queue_depth.
What: /sys/block/<disk>/diskseq
Date: February 2021
Contact: Matteo Croce <mcroce@microsoft.com>
Description:
The /sys/block/<disk>/diskseq files reports the disk
sequence number, which is a monotonically increasing
number assigned to every drive.
Some devices, like the loop device, refresh such number
every time the backing file is changed.
The value type is 64 bit unsigned.
What: /sys/block/<disk>/<part>/stat
Date: February 2008
Contact: Jerome Marchand <jmarchan@redhat.com>
Description:
The /sys/block/<disk>/<part>/stat files display the
I/O statistics of partition <part>. The format is the
same as the above-written /sys/block/<disk>/stat
format.
What: /sys/block/<disk>/integrity/format
Date: June 2008
Contact: Martin K. Petersen <martin.petersen@oracle.com>
Description:
Metadata format for integrity capable block device.
E.g. T10-DIF-TYPE1-CRC.
What: /sys/block/<disk>/integrity/read_verify
Date: June 2008
Contact: Martin K. Petersen <martin.petersen@oracle.com>
Description:
Indicates whether the block layer should verify the
integrity of read requests serviced by devices that
support sending integrity metadata.
What: /sys/block/<disk>/integrity/tag_size
Date: June 2008
Contact: Martin K. Petersen <martin.petersen@oracle.com>
Description:
Number of bytes of integrity tag space available per
512 bytes of data.
What: /sys/block/<disk>/integrity/device_is_integrity_capable
Date: July 2014
Contact: Martin K. Petersen <martin.petersen@oracle.com>
Description:
Indicates whether a storage device is capable of storing
integrity metadata. Set if the device is T10 PI-capable.
What: /sys/block/<disk>/integrity/protection_interval_bytes
Date: July 2015
Contact: Martin K. Petersen <martin.petersen@oracle.com>
Description:
Describes the number of data bytes which are protected
by one integrity tuple. Typically the device's logical
block size.
What: /sys/block/<disk>/integrity/write_generate
Date: June 2008
Contact: Martin K. Petersen <martin.petersen@oracle.com>
Description:
Indicates whether the block layer should automatically
generate checksums for write requests bound for
devices that support receiving integrity metadata.
What: /sys/block/<disk>/alignment_offset
Date: April 2009
Contact: Martin K. Petersen <martin.petersen@oracle.com>
Description:
Storage devices may report a physical block size that is
bigger than the logical block size (for instance a drive
with 4KB physical sectors exposing 512-byte logical
blocks to the operating system). This parameter
indicates how many bytes the beginning of the device is
offset from the disk's natural alignment.
What: /sys/block/<disk>/<partition>/alignment_offset
Date: April 2009
Contact: Martin K. Petersen <martin.petersen@oracle.com>
Description:
Storage devices may report a physical block size that is
bigger than the logical block size (for instance a drive
with 4KB physical sectors exposing 512-byte logical
blocks to the operating system). This parameter
indicates how many bytes the beginning of the partition
is offset from the disk's natural alignment.
What: /sys/block/<disk>/queue/logical_block_size
Date: May 2009
Contact: Martin K. Petersen <martin.petersen@oracle.com>
Description:
This is the smallest unit the storage device can
address. It is typically 512 bytes.
What: /sys/block/<disk>/queue/physical_block_size
Date: May 2009
Contact: Martin K. Petersen <martin.petersen@oracle.com>
Description:
This is the smallest unit a physical storage device can
write atomically. It is usually the same as the logical
block size but may be bigger. One example is SATA
drives with 4KB sectors that expose a 512-byte logical
block size to the operating system. For stacked block
devices the physical_block_size variable contains the
maximum physical_block_size of the component devices.
What: /sys/block/<disk>/queue/minimum_io_size
Date: April 2009
Contact: Martin K. Petersen <martin.petersen@oracle.com>
Description:
Storage devices may report a granularity or preferred
minimum I/O size which is the smallest request the
device can perform without incurring a performance
penalty. For disk drives this is often the physical
block size. For RAID arrays it is often the stripe
chunk size. A properly aligned multiple of
minimum_io_size is the preferred request size for
workloads where a high number of I/O operations is
desired.
What: /sys/block/<disk>/queue/optimal_io_size
Date: April 2009
Contact: Martin K. Petersen <martin.petersen@oracle.com>
Description:
Storage devices may report an optimal I/O size, which is
the device's preferred unit for sustained I/O. This is
rarely reported for disk drives. For RAID arrays it is
usually the stripe width or the internal track size. A
properly aligned multiple of optimal_io_size is the
preferred request size for workloads where sustained
throughput is desired. If no optimal I/O size is
reported this file contains 0.
What: /sys/block/<disk>/queue/nomerges
Date: January 2010
Contact:
Description:
Standard I/O elevator operations include attempts to
merge contiguous I/Os. For known random I/O loads these
attempts will always fail and result in extra cycles
being spent in the kernel. This allows one to turn off
this behavior on one of two ways: When set to 1, complex
merge checks are disabled, but the simple one-shot merges
with the previous I/O request are enabled. When set to 2,
all merge tries are disabled. The default value is 0 -
which enables all types of merge tries.
What: /sys/block/<disk>/discard_alignment
Date: May 2011
Contact: Martin K. Petersen <martin.petersen@oracle.com>
Description:
Devices that support discard functionality may
internally allocate space in units that are bigger than
the exported logical block size. The discard_alignment
parameter indicates how many bytes the beginning of the
device is offset from the internal allocation unit's
natural alignment.
What: /sys/block/<disk>/<partition>/discard_alignment
Date: May 2011
Contact: Martin K. Petersen <martin.petersen@oracle.com>
Description:
Devices that support discard functionality may
internally allocate space in units that are bigger than
the exported logical block size. The discard_alignment
parameter indicates how many bytes the beginning of the
partition is offset from the internal allocation unit's
natural alignment.
What: /sys/block/<disk>/queue/discard_granularity
Date: May 2011
Contact: Martin K. Petersen <martin.petersen@oracle.com>
Description:
Devices that support discard functionality may
internally allocate space using units that are bigger
than the logical block size. The discard_granularity
parameter indicates the size of the internal allocation
unit in bytes if reported by the device. Otherwise the
discard_granularity will be set to match the device's
physical block size. A discard_granularity of 0 means
that the device does not support discard functionality.
What: /sys/block/<disk>/queue/discard_max_bytes
Date: May 2011
Contact: Martin K. Petersen <martin.petersen@oracle.com>
Description:
Devices that support discard functionality may have
internal limits on the number of bytes that can be
trimmed or unmapped in a single operation. Some storage
protocols also have inherent limits on the number of
blocks that can be described in a single command. The
discard_max_bytes parameter is set by the device driver
to the maximum number of bytes that can be discarded in
a single operation. Discard requests issued to the
device must not exceed this limit. A discard_max_bytes
value of 0 means that the device does not support
discard functionality.
What: /sys/block/<disk>/queue/discard_zeroes_data
Date: May 2011
Contact: Martin K. Petersen <martin.petersen@oracle.com>
Description:
Will always return 0. Don't rely on any specific behavior
for discards, and don't read this file.
What: /sys/block/<disk>/queue/write_same_max_bytes
Date: January 2012
Contact: Martin K. Petersen <martin.petersen@oracle.com>
Description:
Some devices support a write same operation in which a
single data block can be written to a range of several
contiguous blocks on storage. This can be used to wipe
areas on disk or to initialize drives in a RAID
configuration. write_same_max_bytes indicates how many
bytes can be written in a single write same command. If
write_same_max_bytes is 0, write same is not supported
by the device.
What: /sys/block/<disk>/queue/write_zeroes_max_bytes
Date: November 2016
Contact: Chaitanya Kulkarni <chaitanya.kulkarni@wdc.com>
Description:
Devices that support write zeroes operation in which a
single request can be issued to zero out the range of
contiguous blocks on storage without having any payload
in the request. This can be used to optimize writing zeroes
to the devices. write_zeroes_max_bytes indicates how many
bytes can be written in a single write zeroes command. If
write_zeroes_max_bytes is 0, write zeroes is not supported
by the device.
What: /sys/block/<disk>/queue/zoned
Date: September 2016
Contact: Damien Le Moal <damien.lemoal@wdc.com>
Description:
zoned indicates if the device is a zoned block device
and the zone model of the device if it is indeed zoned.
The possible values indicated by zoned are "none" for
regular block devices and "host-aware" or "host-managed"
for zoned block devices. The characteristics of
host-aware and host-managed zoned block devices are
described in the ZBC (Zoned Block Commands) and ZAC
(Zoned Device ATA Command Set) standards. These standards
also define the "drive-managed" zone model. However,
since drive-managed zoned block devices do not support
zone commands, they will be treated as regular block
devices and zoned will report "none".
What: /sys/block/<disk>/queue/nr_zones
Date: November 2018
Contact: Damien Le Moal <damien.lemoal@wdc.com>
Description:
nr_zones indicates the total number of zones of a zoned block
device ("host-aware" or "host-managed" zone model). For regular
block devices, the value is always 0.
What: /sys/block/<disk>/queue/max_active_zones
Date: July 2020
Contact: Niklas Cassel <niklas.cassel@wdc.com>
Description:
For zoned block devices (zoned attribute indicating
"host-managed" or "host-aware"), the sum of zones belonging to
any of the zone states: EXPLICIT OPEN, IMPLICIT OPEN or CLOSED,
is limited by this value. If this value is 0, there is no limit.
What: /sys/block/<disk>/queue/max_open_zones
Date: July 2020
Contact: Niklas Cassel <niklas.cassel@wdc.com>
Description:
For zoned block devices (zoned attribute indicating
"host-managed" or "host-aware"), the sum of zones belonging to
any of the zone states: EXPLICIT OPEN or IMPLICIT OPEN,
is limited by this value. If this value is 0, there is no limit.
What: /sys/block/<disk>/queue/chunk_sectors
Date: September 2016
Contact: Hannes Reinecke <hare@suse.com>
Description:
chunk_sectors has different meaning depending on the type
of the disk. For a RAID device (dm-raid), chunk_sectors
indicates the size in 512B sectors of the RAID volume
stripe segment. For a zoned block device, either
host-aware or host-managed, chunk_sectors indicates the
size in 512B sectors of the zones of the device, with
the eventual exception of the last zone of the device
which may be smaller.
What: /sys/block/<disk>/queue/io_timeout
Date: November 2018
Contact: Weiping Zhang <zhangweiping@didiglobal.com>
Description:
io_timeout is the request timeout in milliseconds. If a request
does not complete in this time then the block driver timeout
handler is invoked. That timeout handler can decide to retry
the request, to fail it or to start a device recovery strategy.

16
Documentation/ABI/testing/sysfs-bus-iio-filter-admv8818 Normal file
View file

@ -0,0 +1,16 @@
What: /sys/bus/iio/devices/iio:deviceX/filter_mode_available
KernelVersion:
Contact: linux-iio@vger.kernel.org
Description:
Reading this returns the valid values that can be written to the
on_altvoltage0_mode attribute:
- auto -> Adjust bandpass filter to track changes in input clock rate.
- manual -> disable/unregister the clock rate notifier / input clock tracking.
What: /sys/bus/iio/devices/iio:deviceX/filter_mode
KernelVersion:
Contact: linux-iio@vger.kernel.org
Description:
This attribute configures the filter mode.
Reading returns the actual mode.

38
Documentation/ABI/testing/sysfs-bus-iio-frequency-admv1013 Normal file
View file

@ -0,0 +1,38 @@
What: /sys/bus/iio/devices/iio:deviceX/in_altvoltage0-1_i_calibphase
KernelVersion:
Contact: linux-iio@vger.kernel.org
Description:
Read/write unscaled value for the Local Oscillatior path quadrature I phase shift.
What: /sys/bus/iio/devices/iio:deviceX/in_altvoltage0-1_q_calibphase
KernelVersion:
Contact: linux-iio@vger.kernel.org
Description:
Read/write unscaled value for the Local Oscillatior path quadrature Q phase shift.
What: /sys/bus/iio/devices/iio:deviceX/in_altvoltage0_i_calibbias
KernelVersion:
Contact: linux-iio@vger.kernel.org
Description:
Read/write value for the Local Oscillatior Feedthrough Offset Calibration I Positive
side.
What: /sys/bus/iio/devices/iio:deviceX/in_altvoltage0_q_calibbias
KernelVersion:
Contact: linux-iio@vger.kernel.org
Description:
Read/write value for the Local Oscillatior Feedthrough Offset Calibration Q Positive side.
What: /sys/bus/iio/devices/iio:deviceX/in_altvoltage1_i_calibbias
KernelVersion:
Contact: linux-iio@vger.kernel.org
Description:
Read/write raw value for the Local Oscillatior Feedthrough Offset Calibration I Negative
side.
What: /sys/bus/iio/devices/iio:deviceX/in_altvoltage1_q_calibbias
KernelVersion:
Contact: linux-iio@vger.kernel.org
Description:
Read/write raw value for the Local Oscillatior Feedthrough Offset Calibration Q Negative
side.

9
Documentation/ABI/testing/sysfs-bus-usb
View file

@ -244,6 +244,15 @@ Description:
is permitted, "u2" if only u2 is permitted, "u1_u2" if both u1 and
u2 are permitted.
What: /sys/bus/usb/devices/.../<hub_interface>/port<X>/connector
Date: December 2021
Contact: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Description:
Link to the USB Type-C connector when available. This link is
only created when USB Type-C Connector Class is enabled, and
only if the system firmware is capable of describing the
connection between a port and its connector.
What: /sys/bus/usb/devices/.../power/usb2_lpm_l1_timeout
Date: May 2013
Contact: Mathias Nyman <mathias.nyman@linux.intel.com>

57
Documentation/ABI/testing/sysfs-bus-vdpa Normal file
View file

@ -0,0 +1,57 @@
What: /sys/bus/vdpa/driver_autoprobe
Date: March 2020
Contact: virtualization@lists.linux-foundation.org
Description:
This file determines whether new devices are immediately bound
to a driver after the creation. It initially contains 1, which
means the kernel automatically binds devices to a compatible
driver immediately after they are created.
Writing "0" to this file disable this feature, any other string
enable it.
What: /sys/bus/vdpa/driver_probe
Date: March 2020
Contact: virtualization@lists.linux-foundation.org
Description:
Writing a device name to this file will cause the kernel binds
devices to a compatible driver.
This can be useful when /sys/bus/vdpa/driver_autoprobe is
disabled.
What: /sys/bus/vdpa/drivers/.../bind
Date: March 2020
Contact: virtualization@lists.linux-foundation.org
Description:
Writing a device name to this file will cause the driver to
attempt to bind to the device. This is useful for overriding
default bindings.
What: /sys/bus/vdpa/drivers/.../unbind
Date: March 2020
Contact: virtualization@lists.linux-foundation.org
Description:
Writing a device name to this file will cause the driver to
attempt to unbind from the device. This may be useful when
overriding default bindings.
What: /sys/bus/vdpa/devices/.../driver_override
Date: November 2021
Contact: virtualization@lists.linux-foundation.org
Description:
This file allows the driver for a device to be specified.
When specified, only a driver with a name matching the value
written to driver_override will have an opportunity to bind to
the device. The override is specified by writing a string to the
driver_override file (echo vhost-vdpa > driver_override) and may
be cleared with an empty string (echo > driver_override).
This returns the device to standard matching rules binding.
Writing to driver_override does not automatically unbind the
device from its current driver or make any attempt to
automatically load the specified driver. If no driver with a
matching name is currently loaded in the kernel, the device will
not bind to any driver. This also allows devices to opt-out of
driver binding using a driver_override name such as "none".
Only a single driver may be specified in the override, there is
no support for parsing delimiters.

32
Documentation/ABI/testing/sysfs-class-firmware-attributes
View file

@ -161,6 +161,15 @@ Description:
power-on:
Representing a password required to use
the system
system-mgmt:
Representing System Management password.
See Lenovo extensions section for details
HDD:
Representing HDD password
See Lenovo extensions section for details
NVMe:
Representing NVMe password
See Lenovo extensions section for details
mechanism:
The means of authentication. This attribute is mandatory.
@ -207,6 +216,13 @@ Description:
On Lenovo systems the following additional settings are available:
role: system-mgmt This gives the same authority as the bios-admin password to control
security related features. The authorities allocated can be set via
the BIOS menu SMP Access Control Policy
role: HDD & NVMe This password is used to unlock access to the drive at boot. Note see
'level' and 'index' extensions below.
lenovo_encoding:
The encoding method that is used. This can be either "ascii"
or "scancode". Default is set to "ascii"
@ -216,6 +232,22 @@ Description:
two char code (e.g. "us", "fr", "gr") and may vary per platform.
Default is set to "us"
level:
Available for HDD and NVMe authentication to set 'user' or 'master'
privilege level.
If only the user password is configured then this should be used to
unlock the drive at boot. If both master and user passwords are set
then either can be used. If a master password is set a user password
is required.
This attribute defaults to 'user' level
index:
Used with HDD and NVME authentication to set the drive index
that is being referenced (e.g hdd0, hdd1 etc)
This attribute defaults to device 0.
What: /sys/class/firmware-attributes/*/attributes/pending_reboot
Date: February 2021
KernelVersion: 5.11

16
Documentation/ABI/testing/sysfs-class-power
View file

@ -413,7 +413,7 @@ Description:
"Over voltage", "Unspecified failure", "Cold",
"Watchdog timer expire", "Safety timer expire",
"Over current", "Calibration required", "Warm",
"Cool", "Hot"
"Cool", "Hot", "No battery"
What: /sys/class/power_supply/<supply_name>/precharge_current
Date: June 2017
@ -455,6 +455,20 @@ Description:
"Unknown", "Charging", "Discharging",
"Not charging", "Full"
What: /sys/class/power_supply/<supply_name>/charge_behaviour
Date: November 2021
Contact: linux-pm@vger.kernel.org
Description:
Represents the charging behaviour.
Access: Read, Write
Valid values:
================ ====================================
auto: Charge normally, respect thresholds
inhibit-charge: Do not charge while AC is attached
force-discharge: Force discharge while AC is attached
What: /sys/class/power_supply/<supply_name>/technology
Date: May 2007
Contact: linux-pm@vger.kernel.org

15
Documentation/ABI/testing/sysfs-devices-system-cpu
View file

@ -666,3 +666,18 @@ Description: Preferred MTE tag checking mode
================ ==============================================
See also: Documentation/arm64/memory-tagging-extension.rst
What: /sys/devices/system/cpu/nohz_full
Date: Apr 2015
Contact: Linux kernel mailing list <linux-kernel@vger.kernel.org>
Description:
(RO) the list of CPUs that are in nohz_full mode.
These CPUs are set by boot parameter "nohz_full=".
What: /sys/devices/system/cpu/isolated
Date: Apr 2015
Contact: Linux kernel mailing list <linux-kernel@vger.kernel.org>
Description:
(RO) the list of CPUs that are isolated and don't
participate in load balancing. These CPUs are set by
boot parameter "isolcpus=".

16
Documentation/ABI/testing/sysfs-fs-erofs Normal file
View file

@ -0,0 +1,16 @@
What: /sys/fs/erofs/features/
Date: November 2021
Contact: "Huang Jianan" <huangjianan@oppo.com>
Description: Shows all enabled kernel features.
Supported features:
zero_padding, compr_cfgs, big_pcluster, chunked_file,
device_table, compr_head2, sb_chksum.
What: /sys/fs/erofs/<disk>/sync_decompress
Date: November 2021
Contact: "Huang Jianan" <huangjianan@oppo.com>
Description: Control strategy of sync decompression
- 0 (default, auto): enable for readpage, and enable for
readahead on atomic contexts only,
- 1 (force on): enable for readpage and readahead.
- 2 (force off): disable for all situations.

12
Documentation/ABI/testing/sysfs-fs-f2fs
View file

@ -112,6 +112,11 @@ Contact: "Jaegeuk Kim" <jaegeuk@kernel.org>
Description: Set timeout to issue discard commands during umount.
Default: 5 secs
What: /sys/fs/f2fs/<disk>/pending_discard
Date: November 2021
Contact: "Jaegeuk Kim" <jaegeuk@kernel.org>
Description: Shows the number of pending discard commands in the queue.
What: /sys/fs/f2fs/<disk>/max_victim_search
Date: January 2014
Contact: "Jaegeuk Kim" <jaegeuk.kim@samsung.com>
@ -528,3 +533,10 @@ Description: With "mode=fragment:block" mount options, we can scatter block allo
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>/gc_urgent_high_remaining
Date: December 2021
Contact: "Daeho Jeong" <daehojeong@google.com>
Description: You can set the trial count limit for GC urgent high mode with this value.
If GC thread gets to the limit, the mode will turn back to GC normal mode.
By default, the value is zero, which means there is no limit like before.

35
Documentation/ABI/testing/sysfs-fs-ubifs Normal file
View file

@ -0,0 +1,35 @@
What: /sys/fs/ubifsX_Y/error_magic
Date: October 2021
KernelVersion: 5.16
Contact: linux-mtd@lists.infradead.org
Description:
Exposes magic errors: every node starts with a magic number.
This counter keeps track of the number of accesses of nodes
with a corrupted magic number.
The counter is reset to 0 with a remount.
What: /sys/fs/ubifsX_Y/error_node
Date: October 2021
KernelVersion: 5.16
Contact: linux-mtd@lists.infradead.org
Description:
Exposes node errors. Every node embeds its type.
This counter keeps track of the number of accesses of nodes
with a corrupted node type.
The counter is reset to 0 with a remount.
What: /sys/fs/ubifsX_Y/error_crc
Date: October 2021
KernelVersion: 5.16
Contact: linux-mtd@lists.infradead.org
Description:
Exposes crc errors: every node embeds a crc checksum.
This counter keeps track of the number of accesses of nodes
with a bad crc checksum.
The counter is reset to 0 with a remount.

55
Documentation/accounting/delay-accounting.rst
View file

@ -13,6 +13,8 @@ a) waiting for a CPU (while being runnable)
b) completion of synchronous block I/O initiated by the task
c) swapping in pages
d) memory reclaim
e) thrashing page cache
f) direct compact
and makes these statistics available to userspace through
the taskstats interface.
@ -41,11 +43,12 @@ generic data structure to userspace corresponding to per-pid and per-tgid
statistics. The delay accounting functionality populates specific fields of
this structure. See
include/linux/taskstats.h
include/uapi/linux/taskstats.h
for a description of the fields pertaining to delay accounting.
It will generally be in the form of counters returning the cumulative
delay seen for cpu, sync block I/O, swapin, memory reclaim etc.
delay seen for cpu, sync block I/O, swapin, memory reclaim, thrash page
cache, direct compact etc.
Taking the difference of two successive readings of a given
counter (say cpu_delay_total) for a task will give the delay
@ -88,41 +91,37 @@ seen.
General format of the getdelays command::
getdelays [-t tgid] [-p pid] [-c cmd...]
getdelays [-dilv] [-t tgid] [-p pid]
Get delays, since system boot, for pid 10::
# ./getdelays -p 10
# ./getdelays -d -p 10
(output similar to next case)
Get sum of delays, since system boot, for all pids with tgid 5::
# ./getdelays -t 5
# ./getdelays -d -t 5
print delayacct stats ON
TGID 5
CPU count real total virtual total delay total
7876 92005750 100000000 24001500
IO count delay total
0 0
SWAP count delay total
0 0
RECLAIM count delay total
0 0
CPU count real total virtual total delay total delay average
8 7000000 6872122 3382277 0.423ms
IO count delay total delay average
0 0 0ms
SWAP count delay total delay average
0 0 0ms
RECLAIM count delay total delay average
0 0 0ms
THRASHING count delay total delay average
0 0 0ms
COMPACT count delay total delay average
0 0 0ms
Get delays seen in executing a given simple command::
Get IO accounting for pid 1, it works only with -p::
# ./getdelays -c ls /
# ./getdelays -i -p 1
printing IO accounting
linuxrc: read=65536, write=0, cancelled_write=0
bin data1 data3 data5 dev home media opt root srv sys usr
boot data2 data4 data6 etc lib mnt proc sbin subdomain tmp var
CPU count real total virtual total delay total
6 4000250 4000000 0
IO count delay total
0 0
SWAP count delay total
0 0
RECLAIM count delay total
0 0
The above command can be used with -v to get more debug information.

4
Documentation/admin-guide/cgroup-v1/hugetlb.rst
View file

@ -29,12 +29,14 @@ Brief summary of control files::
hugetlb.<hugepagesize>.max_usage_in_bytes # show max "hugepagesize" hugetlb usage recorded
hugetlb.<hugepagesize>.usage_in_bytes # show current usage for "hugepagesize" hugetlb
hugetlb.<hugepagesize>.failcnt # show the number of allocation failure due to HugeTLB usage limit
hugetlb.<hugepagesize>.numa_stat # show the numa information of the hugetlb memory charged to this cgroup
For a system supporting three hugepage sizes (64k, 32M and 1G), the control
files include::
hugetlb.1GB.limit_in_bytes
hugetlb.1GB.max_usage_in_bytes
hugetlb.1GB.numa_stat
hugetlb.1GB.usage_in_bytes
hugetlb.1GB.failcnt
hugetlb.1GB.rsvd.limit_in_bytes
@ -43,6 +45,7 @@ files include::
hugetlb.1GB.rsvd.failcnt
hugetlb.64KB.limit_in_bytes
hugetlb.64KB.max_usage_in_bytes
hugetlb.64KB.numa_stat
hugetlb.64KB.usage_in_bytes
hugetlb.64KB.failcnt
hugetlb.64KB.rsvd.limit_in_bytes
@ -51,6 +54,7 @@ files include::
hugetlb.64KB.rsvd.failcnt
hugetlb.32MB.limit_in_bytes
hugetlb.32MB.max_usage_in_bytes
hugetlb.32MB.numa_stat
hugetlb.32MB.usage_in_bytes
hugetlb.32MB.failcnt
hugetlb.32MB.rsvd.limit_in_bytes

11
Documentation/admin-guide/cgroup-v2.rst
View file

@ -1268,6 +1268,9 @@ PAGE_SIZE multiple when read back.
The number of processes belonging to this cgroup
killed by any kind of OOM killer.
oom_group_kill
The number of times a group OOM has occurred.
memory.events.local
Similar to memory.events but the fields in the file are local
to the cgroup i.e. not hierarchical. The file modified event
@ -1311,6 +1314,9 @@ PAGE_SIZE multiple when read back.
sock (npn)
Amount of memory used in network transmission buffers
vmalloc (npn)
Amount of memory used for vmap backed memory.
shmem
Amount of cached filesystem data that is swap-backed,
such as tmpfs, shm segments, shared anonymous mmap()s
@ -2260,6 +2266,11 @@ HugeTLB Interface Files
are local to the cgroup i.e. not hierarchical. The file modified event
generated on this file reflects only the local events.
hugetlb.<hugepagesize>.numa_stat
Similar to memory.numa_stat, it shows the numa information of the
hugetlb pages of <hugepagesize> in this cgroup. Only active in
use hugetlb pages are included. The per-node values are in bytes.
Misc
----

25
Documentation/admin-guide/cputopology.rst
View file

@ -8,11 +8,9 @@ to /proc/cpuinfo output of some architectures. They reside in
Documentation/ABI/stable/sysfs-devices-system-cpu.
Architecture-neutral, drivers/base/topology.c, exports these attributes.
However, the book and drawer related sysfs files will only be created if
CONFIG_SCHED_BOOK and CONFIG_SCHED_DRAWER are selected, respectively.
CONFIG_SCHED_BOOK and CONFIG_SCHED_DRAWER are currently only used on s390,
where they reflect the cpu and cache hierarchy.
However the die, cluster, book, and drawer hierarchy related sysfs files will
only be created if an architecture provides the related macros as described
below.
For an architecture to support this feature, it must define some of
these macros in include/asm-XXX/topology.h::
@ -43,15 +41,14 @@ not defined by include/asm-XXX/topology.h:
2) topology_die_id: -1
3) topology_cluster_id: -1
4) topology_core_id: 0
5) topology_sibling_cpumask: just the given CPU
6) topology_core_cpumask: just the given CPU
7) topology_cluster_cpumask: just the given CPU
8) topology_die_cpumask: just the given CPU
For architectures that don't support books (CONFIG_SCHED_BOOK) there are no
default definitions for topology_book_id() and topology_book_cpumask().
For architectures that don't support drawers (CONFIG_SCHED_DRAWER) there are
no default definitions for topology_drawer_id() and topology_drawer_cpumask().
5) topology_book_id: -1
6) topology_drawer_id: -1
7) topology_sibling_cpumask: just the given CPU
8) topology_core_cpumask: just the given CPU
9) topology_cluster_cpumask: just the given CPU
10) topology_die_cpumask: just the given CPU
11) topology_book_cpumask: just the given CPU
12) topology_drawer_cpumask: just the given CPU
Additionally, CPU topology information is provided under
/sys/devices/system/cpu and includes these files. The internal

134
Documentation/admin-guide/gpio/gpio-sim.rst Normal file
View file

@ -0,0 +1,134 @@
.. SPDX-License-Identifier: GPL-2.0-or-later
Configfs GPIO Simulator
=======================
The configfs GPIO Simulator (gpio-sim) provides a way to create simulated GPIO
chips for testing purposes. The lines exposed by these chips can be accessed
using the standard GPIO character device interface as well as manipulated
using sysfs attributes.
Creating simulated chips
------------------------
The gpio-sim module registers a configfs subsystem called ``'gpio-sim'``. For
details of the configfs filesystem, please refer to the configfs documentation.
The user can create a hierarchy of configfs groups and items as well as modify
values of exposed attributes. Once the chip is instantiated, this hierarchy
will be translated to appropriate device properties. The general structure is:
**Group:** ``/config/gpio-sim``
This is the top directory of the gpio-sim configfs tree.
**Group:** ``/config/gpio-sim/gpio-device``
**Attribute:** ``/config/gpio-sim/gpio-device/dev_name``
**Attribute:** ``/config/gpio-sim/gpio-device/live``
This is a directory representing a GPIO platform device. The ``'dev_name'``
attribute is read-only and allows the user-space to read the platform device
name (e.g. ``'gpio-sim.0'``). The ``'live'`` attribute allows to trigger the
actual creation of the device once it's fully configured. The accepted values
are: ``'1'`` to enable the simulated device and ``'0'`` to disable and tear
it down.
**Group:** ``/config/gpio-sim/gpio-device/gpio-bankX``
**Attribute:** ``/config/gpio-sim/gpio-device/gpio-bankX/chip_name``
**Attribute:** ``/config/gpio-sim/gpio-device/gpio-bankX/num_lines``
This group represents a bank of GPIOs under the top platform device. The
``'chip_name'`` attribute is read-only and allows the user-space to read the
device name of the bank device. The ``'num_lines'`` attribute allows to specify
the number of lines exposed by this bank.
**Group:** ``/config/gpio-sim/gpio-device/gpio-bankX/lineY``
**Attribute:** ``/config/gpio-sim/gpio-device/gpio-bankX/lineY/name``
This group represents a single line at the offset Y. The 'name' attribute
allows to set the line name as represented by the 'gpio-line-names' property.
**Item:** ``/config/gpio-sim/gpio-device/gpio-bankX/lineY/hog``
**Attribute:** ``/config/gpio-sim/gpio-device/gpio-bankX/lineY/hog/name``
**Attribute:** ``/config/gpio-sim/gpio-device/gpio-bankX/lineY/hog/direction``
This item makes the gpio-sim module hog the associated line. The ``'name'``
attribute specifies the in-kernel consumer name to use. The ``'direction'``
attribute specifies the hog direction and must be one of: ``'input'``,
``'output-high'`` and ``'output-low'``.
Inside each bank directory, there's a set of attributes that can be used to
configure the new chip. Additionally the user can ``mkdir()`` subdirectories
inside the chip's directory that allow to pass additional configuration for
specific lines. The name of those subdirectories must take the form of:
``'line<offset>'`` (e.g. ``'line0'``, ``'line20'``, etc.) as the name will be
used by the module to assign the config to the specific line at given offset.
Once the confiuration is complete, the ``'live'`` attribute must be set to 1 in
order to instantiate the chip. It can be set back to 0 to destroy the simulated
chip. The module will synchronously wait for the new simulated device to be
successfully probed and if this doesn't happen, writing to ``'live'`` will
result in an error.
Simulated GPIO chips can also be defined in device-tree. The compatible string
must be: ``"gpio-simulator"``. Supported properties are:
``"gpio-sim,label"`` - chip label
Other standard GPIO properties (like ``"gpio-line-names"``, ``"ngpios"`` or
``"gpio-hog"``) are also supported. Please refer to the GPIO documentation for
details.
An example device-tree code defining a GPIO simulator:
.. code-block :: none
gpio-sim {
compatible = "gpio-simulator";
bank0 {
gpio-controller;
#gpio-cells = <2>;
ngpios = <16>;
gpio-sim,label = "dt-bank0";
gpio-line-names = "", "sim-foo", "", "sim-bar";
};
bank1 {
gpio-controller;
#gpio-cells = <2>;
ngpios = <8>;
gpio-sim,label = "dt-bank1";
line3 {
gpio-hog;
gpios = <3 0>;
output-high;
line-name = "sim-hog-from-dt";
};
};
};
Manipulating simulated lines
----------------------------
Each simulated GPIO chip creates a separate sysfs group under its device
directory for each exposed line
(e.g. ``/sys/devices/platform/gpio-sim.X/gpiochipY/``). The name of each group
is of the form: ``'sim_gpioX'`` where X is the offset of the line. Inside each
group there are two attibutes:
``pull`` - allows to read and set the current simulated pull setting for
every line, when writing the value must be one of: ``'pull-up'``,
``'pull-down'``
``value`` - allows to read the current value of the line which may be
different from the pull if the line is being driven from
user-space

20
Documentation/admin-guide/kernel-parameters.txt
View file

@ -612,8 +612,8 @@
clocksource.max_cswd_read_retries= [KNL]
Number of clocksource_watchdog() retries due to
external delays before the clock will be marked
unstable. Defaults to three retries, that is,
four attempts to read the clock under test.
unstable. Defaults to two retries, that is,
three attempts to read the clock under test.
clocksource.verify_n_cpus= [KNL]
Limit the number of CPUs checked for clocksources
@ -3393,7 +3393,7 @@
Disable SMAP (Supervisor Mode Access Prevention)
even if it is supported by processor.
nosmep [X86,PPC]
nosmep [X86,PPC64s]
Disable SMEP (Supervisor Mode Execution Prevention)
even if it is supported by processor.
@ -4166,6 +4166,14 @@
Override pmtimer IOPort with a hex value.
e.g. pmtmr=0x508
pmu_override= [PPC] Override the PMU.
This option takes over the PMU facility, so it is no
longer usable by perf. Setting this option starts the
PMU counters by setting MMCR0 to 0 (the FC bit is
cleared). If a number is given, then MMCR1 is set to
that number, otherwise (e.g., 'pmu_override=on'), MMCR1
remains 0.
pm_debug_messages [SUSPEND,KNL]
Enable suspend/resume debug messages during boot up.
@ -6494,6 +6502,12 @@
controller on both pseries and powernv
platforms. Only useful on POWER9 and above.
xive.store-eoi=off [PPC]
By default on POWER10 and above, the kernel will use
stores for EOI handling when the XIVE interrupt mode
is active. This option allows the XIVE driver to use
loads instead, as on POWER9.
xhci-hcd.quirks [USB,KNL]
A hex value specifying bitmask with supplemental xhci
host controller quirks. Meaning of each bit can be

25
Documentation/admin-guide/mm/damon/reclaim.rst
View file

@ -208,6 +208,31 @@ PID of the DAMON thread.
If DAMON_RECLAIM is enabled, this becomes the PID of the worker thread. Else,
-1.
nr_reclaim_tried_regions
------------------------
Number of memory regions that tried to be reclaimed by DAMON_RECLAIM.
bytes_reclaim_tried_regions
---------------------------
Total bytes of memory regions that tried to be reclaimed by DAMON_RECLAIM.
nr_reclaimed_regions
--------------------
Number of memory regions that successfully be reclaimed by DAMON_RECLAIM.
bytes_reclaimed_regions
-----------------------
Total bytes of memory regions that successfully be reclaimed by DAMON_RECLAIM.
nr_quota_exceeds
----------------
Number of times that the time/space quota limits have exceeded.
Example
=======

225
Documentation/admin-guide/mm/damon/usage.rst
View file

@ -7,37 +7,40 @@ Detailed Usages
DAMON provides below three interfaces for different users.
- *DAMON user space tool.*
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 both virtual and physical address spaces
monitoring.
`This <https://github.com/awslabs/damo>`_ 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 both
virtual and physical address spaces monitoring. For more detail, please
refer to its `usage document
<https://github.com/awslabs/damo/blob/next/USAGE.md>`_.
- *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 both virtual and physical
address spaces monitoring.
:ref:`This <debugfs_interface>` 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
<https://github.com/awslabs/damo>`_ is one example of such programs. It
supports both virtual and physical address spaces monitoring. Note that this
interface provides only simple :ref:`statistics <damos_stats>` for the
monitoring results. For detailed monitoring results, DAMON provides a
:ref:`tracepoint <tracepoint>`.
- *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
DAMON application programs for you. You can even extend DAMON for various
address spaces.
:doc:`This </vm/damon/api>` is for kernel space programmers. Using this,
users can utilize every feature of DAMON most flexibly and efficiently by
writing kernel space DAMON application programs for you. You can even extend
DAMON for various address spaces. For detail, please refer to the interface
:doc:`document </vm/damon/api>`.
Nevertheless, you could write your own user space tool using the debugfs
interface. A reference implementation is available at
https://github.com/awslabs/damo. If you are a kernel programmer, you could
refer to :doc:`/vm/damon/api` for the kernel space programming interface. For
the reason, this document describes only the debugfs interface
.. _debugfs_interface:
debugfs Interface
=================
DAMON exports five files, ``attrs``, ``target_ids``, ``init_regions``,
``schemes`` and ``monitor_on`` under its debugfs directory,
``<debugfs>/damon/``.
DAMON exports eight files, ``attrs``, ``target_ids``, ``init_regions``,
``schemes``, ``monitor_on``, ``kdamond_pid``, ``mk_contexts`` and
``rm_contexts`` under its debugfs directory, ``<debugfs>/damon/``.
Attributes
@ -131,24 +134,38 @@ 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.
region of a specific access pattern. DAMON receives such formalized operation
schemes from the user and applies those to the target processes.
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:
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
<target access pattern> <action> <quota> <watermarks>
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.
You can disable schemes by simply writing an empty string to the file.
Target Access Pattern
~~~~~~~~~~~~~~~~~~~~~
The ``<target access pattern>`` is constructed with three ranges in below
form::
min-size max-size min-acc max-acc min-age max-age
Specifically, 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``) are specified. Note that the ranges are
closed interval.
Action
~~~~~~
The ``<action>`` is a predefined integer for memory management actions, which
DAMON will apply to the regions having the target access pattern. 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``
@ -157,20 +174,82 @@ numbers and their meanings are as below.
- 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. ::
Quota
~~~~~
Optimal ``target access pattern`` for each ``action`` is workload dependent, so
not easy to find. Worse yet, setting a scheme of some action too aggressive
can cause severe overhead. To avoid such overhead, users can limit time and
size quota for the scheme via the ``<quota>`` in below form::
<ms> <sz> <reset interval> <priority weights>
This makes DAMON to try to use only up to ``<ms>`` milliseconds for applying
the action to memory regions of the ``target access pattern`` within the
``<reset interval>`` milliseconds, and to apply the action to only up to
``<sz>`` bytes of memory regions within the ``<reset interval>``. Setting both
``<ms>`` and ``<sz>`` zero disables the quota limits.
When the quota limit is expected to be exceeded, DAMON prioritizes found memory
regions of the ``target access pattern`` based on their size, access frequency,
and age. For personalized prioritization, users can set the weights for the
three properties in ``<priority weights>`` in below form::
<size weight> <access frequency weight> <age weight>
Watermarks
~~~~~~~~~~
Some schemes would need to run based on current value of the system's specific
metrics like free memory ratio. For such cases, users can specify watermarks
for the condition.::
<metric> <check interval> <high mark> <middle mark> <low mark>
``<metric>`` is a predefined integer for the metric to be checked. The
supported numbers and their meanings are as below.
- 0: Ignore the watermarks
- 1: System's free memory rate (per thousand)
The value of the metric is checked every ``<check interval>`` microseconds.
If the value is higher than ``<high mark>`` or lower than ``<low mark>``, the
scheme is deactivated. If the value is lower than ``<mid mark>``, the scheme
is activated.
.. _damos_stats:
Statistics
~~~~~~~~~~
It also counts the total number and bytes of regions that each scheme is tried
to be applied, the two numbers for the regions that each scheme is successfully
applied, and the total number of the quota limit exceeds. This statistics can
be used for online analysis or tuning of the schemes.
The statistics can be shown by reading the ``schemes`` file. Reading the file
will show each scheme you entered in each line, and the five numbers for the
statistics will be added at the end of each line.
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. For the paging out, use only up to
10ms per second, and also don't page out more than 1GiB per second. Under the
limitation, page out memory regions having longer age first. Also, check the
free memory rate of the system every 5 seconds, start the monitoring and paging
out when the free memory rate becomes lower than 50%, but stop it if the free
memory rate becomes larger than 60%, or lower than 30%".::
# 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.
# scheme="4096 8192 0 5 10 20 2" # target access pattern and action
# scheme+=" 10 $((1024*1024*1024)) 1000" # quotas
# scheme+=" 0 0 100" # prioritization weights
# scheme+=" 1 5000000 600 500 300" # watermarks
# echo "$scheme" > schemes
Turning On/Off
@ -195,6 +274,54 @@ the monitoring is turned on. If you write to the files while DAMON is running,
an error code such as ``-EBUSY`` will be returned.
Monitoring Thread PID
---------------------
DAMON does requested monitoring with a kernel thread called ``kdamond``. You
can get the pid of the thread by reading the ``kdamond_pid`` file. When the
monitoring is turned off, reading the file returns ``none``. ::
# cd <debugfs>/damon
# cat monitor_on
off
# cat kdamond_pid
none
# echo on > monitor_on
# cat kdamond_pid
18594
Using Multiple Monitoring Threads
---------------------------------
One ``kdamond`` thread is created for each monitoring context. You can create
and remove monitoring contexts for multiple ``kdamond`` required use case using
the ``mk_contexts`` and ``rm_contexts`` files.
Writing the name of the new context to the ``mk_contexts`` file creates a
directory of the name on the DAMON debugfs directory. The directory will have
DAMON debugfs files for the context. ::
# cd <debugfs>/damon
# ls foo
# ls: cannot access 'foo': No such file or directory
# echo foo > mk_contexts
# ls foo
# attrs init_regions kdamond_pid schemes target_ids
If the context is not needed anymore, you can remove it and the corresponding
directory by putting the name of the context to the ``rm_contexts`` file. ::
# echo foo > rm_contexts
# ls foo
# ls: cannot access 'foo': No such file or directory
Note that ``mk_contexts``, ``rm_contexts``, and ``monitor_on`` files are in the
root directory only.
.. _tracepoint:
Tracepoint for Monitoring Results
=================================

16
Documentation/admin-guide/mm/numa_memory_policy.rst
View file

@ -408,7 +408,7 @@ follows:
Memory Policy APIs
==================
Linux supports 3 system calls for controlling memory policy. These APIS
Linux supports 4 system calls for controlling memory policy. These APIS
always affect only the calling task, the calling task's address space, or
some shared object mapped into the calling task's address space.
@ -460,6 +460,20 @@ requested via the 'flags' argument.
See the mbind(2) man page for more details.
Set home node for a Range of Task's Address Spacec::
long sys_set_mempolicy_home_node(unsigned long start, unsigned long len,
unsigned long home_node,
unsigned long flags);
sys_set_mempolicy_home_node set the home node for a VMA policy present in the
task's address range. The system call updates the home node only for the existing
mempolicy range. Other address ranges are ignored. A home node is the NUMA node
closest to which page allocation will come from. Specifying the home node override
the default allocation policy to allocate memory close to the local node for an
executing CPU.
Memory Policy Command Line Interface
====================================

2
Documentation/admin-guide/sysctl/vm.rst
View file

@ -948,7 +948,7 @@ how much memory needs to be free before kswapd goes back to sleep.
The unit is in fractions of 10,000. The default value of 10 means the
distances between watermarks are 0.1% of the available memory in the
node/system. The maximum value is 1000, or 10% of memory.
node/system. The maximum value is 3000, or 30% of memory.
A high rate of threads entering direct reclaim (allocstall) or kswapd
going to sleep prematurely (kswapd_low_wmark_hit_quickly) can indicate

1
Documentation/block/index.rst
View file

@ -20,7 +20,6 @@ Block
kyber-iosched
null_blk
pr
queue-sysfs
request
stat
switching-sched

321
Documentation/block/queue-sysfs.rst
View file

@ -1,321 +0,0 @@
=================
Queue sysfs files
=================
This text file will detail the queue files that are located in the sysfs tree
for each block device. Note that stacked devices typically do not export
any settings, since their queue merely functions as a remapping target.
These files are the ones found in the /sys/block/xxx/queue/ directory.
Files denoted with a RO postfix are readonly and the RW postfix means
read-write.
add_random (RW)
---------------
This file allows to turn off the disk entropy contribution. Default
value of this file is '1'(on).
chunk_sectors (RO)
------------------
This has different meaning depending on the type of the block device.
For a RAID device (dm-raid), chunk_sectors indicates the size in 512B sectors
of the RAID volume stripe segment. For a zoned block device, either host-aware
or host-managed, chunk_sectors indicates the size in 512B sectors of the zones
of the device, with the eventual exception of the last zone of the device which
may be smaller.
dax (RO)
--------
This file indicates whether the device supports Direct Access (DAX),
used by CPU-addressable storage to bypass the pagecache. It shows '1'
if true, '0' if not.
discard_granularity (RO)
------------------------
This shows the size of internal allocation of the device in bytes, if
reported by the device. A value of '0' means device does not support
the discard functionality.
discard_max_hw_bytes (RO)
-------------------------
Devices that support discard functionality may have internal limits on
the number of bytes that can be trimmed or unmapped in a single operation.
The `discard_max_hw_bytes` parameter is set by the device driver to the
maximum number of bytes that can be discarded in a single operation.
Discard requests issued to the device must not exceed this limit.
A `discard_max_hw_bytes` value of 0 means that the device does not support
discard functionality.
discard_max_bytes (RW)
----------------------
While discard_max_hw_bytes is the hardware limit for the device, this
setting is the software limit. Some devices exhibit large latencies when
large discards are issued, setting this value lower will make Linux issue
smaller discards and potentially help reduce latencies induced by large
discard operations.
discard_zeroes_data (RO)
------------------------
Obsolete. Always zero.
fua (RO)
--------
Whether or not the block driver supports the FUA flag for write requests.
FUA stands for Force Unit Access. If the FUA flag is set that means that
write requests must bypass the volatile cache of the storage device.
hw_sector_size (RO)
-------------------
This is the hardware sector size of the device, in bytes.
io_poll (RW)
------------
When read, this file shows whether polling is enabled (1) or disabled
(0). Writing '0' to this file will disable polling for this device.
Writing any non-zero value will enable this feature.
io_poll_delay (RW)
------------------
If polling is enabled, this controls what kind of polling will be
performed. It defaults to -1, which is classic polling. In this mode,
the CPU will repeatedly ask for completions without giving up any time.
If set to 0, a hybrid polling mode is used, where the kernel will attempt
to make an educated guess at when the IO will complete. Based on this
guess, the kernel will put the process issuing IO to sleep for an amount
of time, before entering a classic poll loop. This mode might be a
little slower than pure classic polling, but it will be more efficient.
If set to a value larger than 0, the kernel will put the process issuing
IO to sleep for this amount of microseconds before entering classic
polling.
io_timeout (RW)
---------------
io_timeout is the request timeout in milliseconds. If a request does not
complete in this time then the block driver timeout handler is invoked.
That timeout handler can decide to retry the request, to fail it or to start
a device recovery strategy.
iostats (RW)
-------------
This file is used to control (on/off) the iostats accounting of the
disk.
logical_block_size (RO)
-----------------------
This is the logical block size of the device, in bytes.
max_discard_segments (RO)
-------------------------
The maximum number of DMA scatter/gather entries in a discard request.
max_hw_sectors_kb (RO)
----------------------
This is the maximum number of kilobytes supported in a single data transfer.
max_integrity_segments (RO)
---------------------------
Maximum number of elements in a DMA scatter/gather list with integrity
data that will be submitted by the block layer core to the associated
block driver.
max_active_zones (RO)
---------------------
For zoned block devices (zoned attribute indicating "host-managed" or
"host-aware"), the sum of zones belonging to any of the zone states:
EXPLICIT OPEN, IMPLICIT OPEN or CLOSED, is limited by this value.
If this value is 0, there is no limit.
If the host attempts to exceed this limit, the driver should report this error
with BLK_STS_ZONE_ACTIVE_RESOURCE, which user space may see as the EOVERFLOW
errno.
max_open_zones (RO)
-------------------
For zoned block devices (zoned attribute indicating "host-managed" or
"host-aware"), the sum of zones belonging to any of the zone states:
EXPLICIT OPEN or IMPLICIT OPEN, is limited by this value.
If this value is 0, there is no limit.
If the host attempts to exceed this limit, the driver should report this error
with BLK_STS_ZONE_OPEN_RESOURCE, which user space may see as the ETOOMANYREFS
errno.
max_sectors_kb (RW)
-------------------
This is the maximum number of kilobytes that the block layer will allow
for a filesystem request. Must be smaller than or equal to the maximum
size allowed by the hardware.
max_segments (RO)
-----------------
Maximum number of elements in a DMA scatter/gather list that is submitted
to the associated block driver.
max_segment_size (RO)
---------------------
Maximum size in bytes of a single element in a DMA scatter/gather list.
minimum_io_size (RO)
--------------------
This is the smallest preferred IO size reported by the device.
nomerges (RW)
-------------
This enables the user to disable the lookup logic involved with IO
merging requests in the block layer. By default (0) all merges are
enabled. When set to 1 only simple one-hit merges will be tried. When
set to 2 no merge algorithms will be tried (including one-hit or more
complex tree/hash lookups).
nr_requests (RW)
----------------
This controls how many requests may be allocated in the block layer for
read or write requests. Note that the total allocated number may be twice
this amount, since it applies only to reads or writes (not the accumulated
sum).
To avoid priority inversion through request starvation, a request
queue maintains a separate request pool per each cgroup when
CONFIG_BLK_CGROUP is enabled, and this parameter applies to each such
per-block-cgroup request pool. IOW, if there are N block cgroups,
each request queue may have up to N request pools, each independently
regulated by nr_requests.
nr_zones (RO)
-------------
For zoned block devices (zoned attribute indicating "host-managed" or
"host-aware"), this indicates the total number of zones of the device.
This is always 0 for regular block devices.
optimal_io_size (RO)
--------------------
This is the optimal IO size reported by the device.
physical_block_size (RO)
------------------------
This is the physical block size of device, in bytes.
read_ahead_kb (RW)
------------------
Maximum number of kilobytes to read-ahead for filesystems on this block
device.
rotational (RW)
---------------
This file is used to stat if the device is of rotational type or
non-rotational type.
rq_affinity (RW)
----------------
If this option is '1', the block layer will migrate request completions to the
cpu "group" that originally submitted the request. For some workloads this
provides a significant reduction in CPU cycles due to caching effects.
For storage configurations that need to maximize distribution of completion
processing setting this option to '2' forces the completion to run on the
requesting cpu (bypassing the "group" aggregation logic).
scheduler (RW)
--------------
When read, this file will display the current and available IO schedulers
for this block device. The currently active IO scheduler will be enclosed
in [] brackets. Writing an IO scheduler name to this file will switch
control of this block device to that new IO scheduler. Note that writing
an IO scheduler name to this file will attempt to load that IO scheduler
module, if it isn't already present in the system.
write_cache (RW)
----------------
When read, this file will display whether the device has write back
caching enabled or not. It will return "write back" for the former
case, and "write through" for the latter. Writing to this file can
change the kernels view of the device, but it doesn't alter the
device state. This means that it might not be safe to toggle the
setting from "write back" to "write through", since that will also
eliminate cache flushes issued by the kernel.
write_same_max_bytes (RO)
-------------------------
This is the number of bytes the device can write in a single write-same
command. A value of '0' means write-same is not supported by this
device.
wbt_lat_usec (RW)
-----------------
If the device is registered for writeback throttling, then this file shows
the target minimum read latency. If this latency is exceeded in a given
window of time (see wb_window_usec), then the writeback throttling will start
scaling back writes. Writing a value of '0' to this file disables the
feature. Writing a value of '-1' to this file resets the value to the
default setting.
throttle_sample_time (RW)
-------------------------
This is the time window that blk-throttle samples data, in millisecond.
blk-throttle makes decision based on the samplings. Lower time means cgroups
have more smooth throughput, but higher CPU overhead. This exists only when
CONFIG_BLK_DEV_THROTTLING_LOW is enabled.
write_zeroes_max_bytes (RO)
---------------------------
For block drivers that support REQ_OP_WRITE_ZEROES, the maximum number of
bytes that can be zeroed at once. The value 0 means that REQ_OP_WRITE_ZEROES
is not supported.
zone_append_max_bytes (RO)
--------------------------
This is the maximum number of bytes that can be written to a sequential
zone of a zoned block device using a zone append write operation
(REQ_OP_ZONE_APPEND). This value is always 0 for regular block devices.
zoned (RO)
----------
This indicates if the device is a zoned block device and the zone model of the
device if it is indeed zoned. The possible values indicated by zoned are
"none" for regular block devices and "host-aware" or "host-managed" for zoned
block devices. The characteristics of host-aware and host-managed zoned block
devices are described in the ZBC (Zoned Block Commands) and ZAC
(Zoned Device ATA Command Set) standards. These standards also define the
"drive-managed" zone model. However, since drive-managed zoned block devices
do not support zone commands, they will be treated as regular block devices
and zoned will report "none".
zone_write_granularity (RO)
---------------------------
This indicates the alignment constraint, in bytes, for write operations in
sequential zones of zoned block devices (devices with a zoned attributed
that reports "host-managed" or "host-aware"). This value is always 0 for
regular block devices.
independent_access_ranges (RO)
------------------------------
The presence of this sub-directory of the /sys/block/xxx/queue/ directory
indicates that the device is capable of executing requests targeting
different sector ranges in parallel. For instance, single LUN multi-actuator
hard-disks will have an independent_access_ranges directory if the device
correctly advertizes the sector ranges of its actuators.
The independent_access_ranges directory contains one directory per access
range, with each range described using the sector (RO) attribute file to
indicate the first sector of the range and the nr_sectors (RO) attribute file
to indicate the total number of sectors in the range starting from the first
sector of the range. For example, a dual-actuator hard-disk will have the
following independent_access_ranges entries.::
$ tree /sys/block/<device>/queue/independent_access_ranges/
/sys/block/<device>/queue/independent_access_ranges/
|-- 0
| |-- nr_sectors
| `-- sector
`-- 1
|-- nr_sectors
`-- sector
The sector and nr_sectors attributes use 512B sector unit, regardless of
the actual block size of the device. Independent access ranges do not
overlap and include all sectors within the device capacity. The access
ranges are numbered in increasing order of the range start sector,
that is, the sector attribute of range 0 always has the value 0.
Jens Axboe <jens.axboe@oracle.com>, February 2009

4
Documentation/core-api/kernel-api.rst
View file

@ -279,6 +279,7 @@ Accounting Framework
Block Devices
=============
.. kernel-doc:: include/linux/bio.h
.. kernel-doc:: block/blk-core.c
:export:
@ -294,9 +295,6 @@ Block Devices
.. kernel-doc:: block/blk-settings.c
:export:
.. kernel-doc:: block/blk-exec.c
:export:
.. kernel-doc:: block/blk-flush.c
:export:

16
Documentation/core-api/kobject.rst
View file

@ -118,7 +118,7 @@ Initialization of kobjects
Code which creates a kobject must, of course, initialize that object. Some
of the internal fields are setup with a (mandatory) call to kobject_init()::
void kobject_init(struct kobject *kobj, struct kobj_type *ktype);
void kobject_init(struct kobject *kobj, const struct kobj_type *ktype);
The ktype is required for a kobject to be created properly, as every kobject
must have an associated kobj_type. After calling kobject_init(), to
@ -156,7 +156,7 @@ kobject_name()::
There is a helper function to both initialize and add the kobject to the
kernel at the same time, called surprisingly enough kobject_init_and_add()::
int kobject_init_and_add(struct kobject *kobj, struct kobj_type *ktype,
int kobject_init_and_add(struct kobject *kobj, const struct kobj_type *ktype,
struct kobject *parent, const char *fmt, ...);
The arguments are the same as the individual kobject_init() and
@ -299,7 +299,6 @@ kobj_type::
struct kobj_type {
void (*release)(struct kobject *kobj);
const struct sysfs_ops *sysfs_ops;
struct attribute **default_attrs;
const struct attribute_group **default_groups;
const struct kobj_ns_type_operations *(*child_ns_type)(struct kobject *kobj);
const void *(*namespace)(struct kobject *kobj);
@ -313,10 +312,10 @@ call kobject_init() or kobject_init_and_add().
The release field in struct kobj_type is, of course, a pointer to the
release() method for this type of kobject. The other two fields (sysfs_ops
and default_attrs) control how objects of this type are represented in
and default_groups) control how objects of this type are represented in
sysfs; they are beyond the scope of this document.
The default_attrs pointer is a list of default attributes that will be
The default_groups pointer is a list of default attributes that will be
automatically created for any kobject that is registered with this ktype.
@ -373,10 +372,9 @@ If a kset wishes to control the uevent operations of the kobjects
associated with it, it can use the struct kset_uevent_ops to handle it::
struct kset_uevent_ops {
int (* const filter)(struct kset *kset, struct kobject *kobj);
const char *(* const name)(struct kset *kset, struct kobject *kobj);
int (* const uevent)(struct kset *kset, struct kobject *kobj,
struct kobj_uevent_env *env);
int (* const filter)(struct kobject *kobj);
const char *(* const name)(struct kobject *kobj);
int (* const uevent)(struct kobject *kobj, struct kobj_uevent_env *env);
};

4
Documentation/devicetree/bindings/Makefile
View file

@ -65,7 +65,9 @@ DT_DOCS = $(patsubst $(srctree)/%,%,$(shell $(find_all_cmd)))
override DTC_FLAGS := \
-Wno-avoid_unnecessary_addr_size \
-Wno-graph_child_address \
-Wno-interrupt_provider
-Wno-interrupt_provider \
-Wno-unique_unit_address \
-Wunique_unit_address_if_enabled
# Disable undocumented compatible checks until warning free
override DT_CHECKER_FLAGS ?=

10
Documentation/devicetree/bindings/arm/arm,cci-400.yaml
View file

@ -166,16 +166,6 @@ examples:
};
};
dma0: dma@3000000 {
/* compatible = "arm,pl330", "arm,primecell"; */
cci-control-port = <&cci_control0>;
reg = <0x0 0x3000000 0x0 0x1000>;
interrupts = <10>;
#dma-cells = <1>;
#dma-channels = <8>;
#dma-requests = <32>;
};
cci@2c090000 {
compatible = "arm,cci-400";
#address-cells = <1>;

27
Documentation/devicetree/bindings/arm/arm-dsu-pmu.txt
View file

@ -1,27 +0,0 @@
* ARM DynamIQ Shared Unit (DSU) Performance Monitor Unit (PMU)
ARM DyanmIQ Shared Unit (DSU) integrates one or more CPU cores
with a shared L3 memory system, control logic and external interfaces to
form a multicore cluster. The PMU enables to gather various statistics on
the operations of the DSU. The PMU provides independent 32bit counters that
can count any of the supported events, along with a 64bit cycle counter.
The PMU is accessed via CPU system registers and has no MMIO component.
** DSU PMU required properties:
- compatible : should be one of :
"arm,dsu-pmu"
- interrupts : Exactly 1 SPI must be listed.
- cpus : List of phandles for the CPUs connected to this DSU instance.
** Example:
dsu-pmu-0 {
compatible = "arm,dsu-pmu";
interrupts = <GIC_SPI 02 IRQ_TYPE_LEVEL_HIGH>;
cpus = <&cpu_0>, <&cpu_1>;
};

7
Documentation/devicetree/bindings/arm/cpus.yaml
View file

@ -137,6 +137,9 @@ properties:
- arm,cortex-a75
- arm,cortex-a76
- arm,cortex-a77
- arm,cortex-a78
- arm,cortex-a510
- arm,cortex-a710
- arm,cortex-m0
- arm,cortex-m0+
- arm,cortex-m1
@ -145,8 +148,12 @@ properties:
- arm,cortex-r4
- arm,cortex-r5
- arm,cortex-r7
- arm,cortex-x1
- arm,cortex-x2
- arm,neoverse-e1
- arm,neoverse-n1
- arm,neoverse-n2
- arm,neoverse-v1
- brcm,brahma-b15
- brcm,brahma-b53
- brcm,vulcan

1
Documentation/devicetree/bindings/arm/mediatek/mediatek,apmixedsys.txt
View file

@ -14,6 +14,7 @@ Required Properties:
- "mediatek,mt7622-apmixedsys"
- "mediatek,mt7623-apmixedsys", "mediatek,mt2701-apmixedsys"
- "mediatek,mt7629-apmixedsys"
- "mediatek,mt7986-apmixedsys"
- "mediatek,mt8135-apmixedsys"
- "mediatek,mt8167-apmixedsys", "syscon"
- "mediatek,mt8173-apmixedsys"

1
Documentation/devicetree/bindings/arm/mediatek/mediatek,ethsys.txt
View file

@ -10,6 +10,7 @@ Required Properties:
- "mediatek,mt7622-ethsys", "syscon"
- "mediatek,mt7623-ethsys", "mediatek,mt2701-ethsys", "syscon"
- "mediatek,mt7629-ethsys", "syscon"
- "mediatek,mt7986-ethsys", "syscon"
- #clock-cells: Must be 1
- #reset-cells: Must be 1

1
Documentation/devicetree/bindings/arm/mediatek/mediatek,infracfg.txt
View file

@ -15,6 +15,7 @@ Required Properties:
- "mediatek,mt7622-infracfg", "syscon"
- "mediatek,mt7623-infracfg", "mediatek,mt2701-infracfg", "syscon"
- "mediatek,mt7629-infracfg", "syscon"
- "mediatek,mt7986-infracfg", "syscon"
- "mediatek,mt8135-infracfg", "syscon"
- "mediatek,mt8167-infracfg", "syscon"
- "mediatek,mt8173-infracfg", "syscon"

2
Documentation/devicetree/bindings/arm/mediatek/mediatek,sgmiisys.txt
View file

@ -8,6 +8,8 @@ Required Properties:
- compatible: Should be:
- "mediatek,mt7622-sgmiisys", "syscon"
- "mediatek,mt7629-sgmiisys", "syscon"
- "mediatek,mt7986-sgmiisys_0", "syscon"
- "mediatek,mt7986-sgmiisys_1", "syscon"
- #clock-cells: Must be 1
The SGMIISYS controller uses the common clk binding from

1
Documentation/devicetree/bindings/arm/mediatek/mediatek,topckgen.txt
View file

@ -14,6 +14,7 @@ Required Properties:
- "mediatek,mt7622-topckgen"
- "mediatek,mt7623-topckgen", "mediatek,mt2701-topckgen"
- "mediatek,mt7629-topckgen"
- "mediatek,mt7986-topckgen", "syscon"
- "mediatek,mt8135-topckgen"
- "mediatek,mt8167-topckgen", "syscon"
- "mediatek,mt8173-topckgen"

8
Documentation/devicetree/bindings/arm/pmu.yaml
View file

@ -44,10 +44,18 @@ properties:
- arm,cortex-a76-pmu
- arm,cortex-a77-pmu
- arm,cortex-a78-pmu
- arm,cortex-a510-pmu
- arm,cortex-a710-pmu
- arm,cortex-x1-pmu
- arm,cortex-x2-pmu
- arm,neoverse-e1-pmu
- arm,neoverse-n1-pmu
- arm,neoverse-n2-pmu
- arm,neoverse-v1-pmu
- brcm,vulcan-pmu
- cavium,thunder-pmu
- nvidia,denver-pmu
- nvidia,carmel-pmu
- qcom,krait-pmu
- qcom,scorpion-pmu
- qcom,scorpion-mp-pmu

30
Documentation/devicetree/bindings/arm/ux500.yaml
View file

@ -20,6 +20,11 @@ properties:
- const: st-ericsson,mop500
- const: st-ericsson,u8500
- description: ST-Ericsson HREF520
items:
- const: st-ericsson,href520
- const: st-ericsson,u8500
- description: ST-Ericsson HREF (v60+)
items:
- const: st-ericsson,hrefv60+
@ -30,9 +35,34 @@ properties:
- const: calaosystems,snowball-a9500
- const: st-ericsson,u9500
- description: Samsung Galaxy Ace 2 (GT-I8160)
items:
- const: samsung,codina
- const: st-ericsson,u8500
- description: Samsung Galaxy Beam (GT-I8530)
items:
- const: samsung,gavini
- const: st-ericsson,u8500
- description: Samsung Galaxy S III mini (GT-I8190)
items:
- const: samsung,golden
- const: st-ericsson,u8500
- description: Samsung Galaxy S Advance (GT-I9070)
items:
- const: samsung,janice
- const: st-ericsson,u8500
- description: Samsung Galaxy Amp (SGH-I407)
items:
- const: samsung,kyle
- const: st-ericsson,u8500
- description: Samsung Galaxy XCover 2 (GT-S7710)
items:
- const: samsung,skomer
- const: st-ericsson,u8500
additionalProperties: true

14
Documentation/devicetree/bindings/arm/xen.txt
View file

@ -7,15 +7,17 @@ the following properties:
compatible = "xen,xen-<version>", "xen,xen";
where <version> is the version of the Xen ABI of the platform.
- reg: specifies the base physical address and size of a region in
memory where the grant table should be mapped to, using an
HYPERVISOR_memory_op hypercall. The memory region is large enough to map
the whole grant table (it is larger or equal to gnttab_max_grant_frames()).
This property is unnecessary when booting Dom0 using ACPI.
- reg: specifies the base physical address and size of the regions in memory
where the special resources should be mapped to, using an HYPERVISOR_memory_op
hypercall.
Region 0 is reserved for mapping grant table, it must be always present.
The memory region is large enough to map the whole grant table (it is larger
or equal to gnttab_max_grant_frames()).
Regions 1...N are extended regions (unused address space) for mapping foreign
GFNs and grants, they might be absent if there is nothing to expose.
- interrupts: the interrupt used by Xen to inject event notifications.
A GIC node is also required.
This property is unnecessary when booting Dom0 using ACPI.
To support UEFI on Xen ARM virtual platforms, Xen populates the FDT "uefi" node
under /hypervisor with following parameters:

45
Documentation/devicetree/bindings/ata/brcm,sata-brcm.txt
View file

@ -1,45 +0,0 @@
* Broadcom SATA3 AHCI Controller
SATA nodes are defined to describe on-chip Serial ATA controllers.
Each SATA controller should have its own node.
Required properties:
- compatible : should be one or more of
"brcm,bcm7216-ahci"
"brcm,bcm7425-ahci"
"brcm,bcm7445-ahci"
"brcm,bcm-nsp-ahci"
"brcm,sata3-ahci"
"brcm,bcm63138-ahci"
- reg : register mappings for AHCI and SATA_TOP_CTRL
- reg-names : "ahci" and "top-ctrl"
- interrupts : interrupt mapping for SATA IRQ
Optional properties:
- reset: for "brcm,bcm7216-ahci" must be a valid reset phandle
pointing to the RESCAL reset controller provider node.
- reset-names: for "brcm,bcm7216-ahci", must be "rescal".
Also see ahci-platform.txt.
Example:
sata@f045a000 {
compatible = "brcm,bcm7445-ahci", "brcm,sata3-ahci";
reg = <0xf045a000 0xa9c>, <0xf0458040 0x24>;
reg-names = "ahci", "top-ctrl";
interrupts = <0 30 0>;
#address-cells = <1>;
#size-cells = <0>;
sata0: sata-port@0 {
reg = <0>;
phys = <&sata_phy 0>;
};
sata1: sata-port@1 {
reg = <1>;
phys = <&sata_phy 1>;
};
};

90
Documentation/devicetree/bindings/ata/brcm,sata-brcm.yaml Normal file
View file

@ -0,0 +1,90 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/ata/brcm,sata-brcm.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Broadcom SATA3 AHCI Controller
description:
SATA nodes are defined to describe on-chip Serial ATA controllers.
Each SATA controller should have its own node.
maintainers:
- Florian Fainelli <f.fainelli@gmail.com>
allOf:
- $ref: sata-common.yaml#
properties:
compatible:
oneOf:
- items:
- enum:
- brcm,bcm7216-ahci
- brcm,bcm7445-ahci
- brcm,bcm7425-ahci
- brcm,bcm63138-ahci
- const: brcm,sata3-ahci
- items:
- const: brcm,bcm-nsp-ahci
reg:
minItems: 2
maxItems: 2
reg-names:
items:
- const: ahci
- const: top-ctrl
interrupts:
maxItems: 1
dma-coherent: true
if:
properties:
compatible:
contains:
enum:
- brcm,bcm7216-ahci
- brcm,bcm63138-ahci
then:
properties:
resets:
maxItems: 1
reset-names:
enum:
- rescal
- ahci
required:
- compatible
- reg
- interrupts
- "#address-cells"
- "#size-cells"
unevaluatedProperties: false
examples:
- |
sata@f045a000 {
compatible = "brcm,bcm7445-ahci", "brcm,sata3-ahci";
reg = <0xf045a000 0xa9c>, <0xf0458040 0x24>;
reg-names = "ahci", "top-ctrl";
interrupts = <0 30 0>;
#address-cells = <1>;
#size-cells = <0>;
sata0: sata-port@0 {
reg = <0>;
phys = <&sata_phy 0>;
};
sata1: sata-port@1 {
reg = <1>;
phys = <&sata_phy 1>;
};
};

34
Documentation/devicetree/bindings/bus/brcm,gisb-arb.txt
View file

@ -1,34 +0,0 @@
Broadcom GISB bus Arbiter controller
Required properties:
- compatible:
"brcm,bcm7278-gisb-arb" for V7 28nm chips
"brcm,gisb-arb" or "brcm,bcm7445-gisb-arb" for other 28nm chips
"brcm,bcm7435-gisb-arb" for newer 40nm chips
"brcm,bcm7400-gisb-arb" for older 40nm chips and all 65nm chips
"brcm,bcm7038-gisb-arb" for 130nm chips
- reg: specifies the base physical address and size of the registers
- interrupts: specifies the two interrupts (timeout and TEA) to be used from
the parent interrupt controller. A third optional interrupt may be specified
for breakpoints.
Optional properties:
- brcm,gisb-arb-master-mask: 32-bits wide bitmask used to specify which GISB
masters are valid at the system level
- brcm,gisb-arb-master-names: string list of the litteral name of the GISB
masters. Should match the number of bits set in brcm,gisb-master-mask and
the order in which they appear
Example:
gisb-arb@f0400000 {
compatible = "brcm,gisb-arb";
reg = <0xf0400000 0x800>;
interrupts = <0>, <2>;
interrupt-parent = <&sun_l2_intc>;
brcm,gisb-arb-master-mask = <0x7>;
brcm,gisb-arb-master-names = "bsp_0", "scpu_0", "cpu_0";
};

66
Documentation/devicetree/bindings/bus/brcm,gisb-arb.yaml Normal file
View file

@ -0,0 +1,66 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/bus/brcm,gisb-arb.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Broadcom GISB bus Arbiter controller
maintainers:
- Florian Fainelli <f.fainelli@gmail.com>
properties:
compatible:
oneOf:
- items:
- enum:
- brcm,bcm7445-gisb-arb # for other 28nm chips
- const: brcm,gisb-arb
- items:
- enum:
- brcm,bcm7278-gisb-arb # for V7 28nm chips
- brcm,bcm7435-gisb-arb # for newer 40nm chips
- brcm,bcm7400-gisb-arb # for older 40nm chips and all 65nm chips
- brcm,bcm7038-gisb-arb # for 130nm chips
- brcm,gisb-arb # fallback compatible
reg:
maxItems: 1
interrupts:
minItems: 2
items:
- description: timeout interrupt line
- description: target abort interrupt line
- description: breakpoint interrupt line
brcm,gisb-arb-master-mask:
$ref: /schemas/types.yaml#/definitions/uint32
description: >
32-bits wide bitmask used to specify which GISB masters are valid at the
system level
brcm,gisb-arb-master-names:
$ref: /schemas/types.yaml#/definitions/string-array
description: >
String list of the litteral name of the GISB masters. Should match the
number of bits set in brcm,gisb-master-mask and the order in which they
appear from MSB to LSB.
required:
- compatible
- reg
- interrupts
additionalProperties: false
examples:
- |
gisb-arb@f0400000 {
compatible = "brcm,gisb-arb";
reg = <0xf0400000 0x800>;
interrupts = <0>, <2>;
interrupt-parent = <&sun_l2_intc>;
brcm,gisb-arb-master-mask = <0x7>;
brcm,gisb-arb-master-names = "bsp_0", "scpu_0", "cpu_0";
};

4
Documentation/devicetree/bindings/clock/allwinner,sun4i-a10-ccu.yaml
View file

@ -34,6 +34,8 @@ properties:
- allwinner,sun8i-v3-ccu
- allwinner,sun8i-v3s-ccu
- allwinner,sun9i-a80-ccu
- allwinner,sun20i-d1-ccu
- allwinner,sun20i-d1-r-ccu
- allwinner,sun50i-a64-ccu
- allwinner,sun50i-a64-r-ccu
- allwinner,sun50i-a100-ccu
@ -79,6 +81,7 @@ if:
enum:
- allwinner,sun8i-a83t-r-ccu
- allwinner,sun8i-h3-r-ccu
- allwinner,sun20i-d1-r-ccu
- allwinner,sun50i-a64-r-ccu
- allwinner,sun50i-a100-r-ccu
- allwinner,sun50i-h6-r-ccu
@ -99,6 +102,7 @@ else:
properties:
compatible:
enum:
- allwinner,sun20i-d1-ccu
- allwinner,sun50i-a100-ccu
- allwinner,sun50i-h6-ccu
- allwinner,sun50i-h616-ccu

190
Documentation/devicetree/bindings/clock/exynos5260-clock.txt
View file

@ -1,190 +0,0 @@
* Samsung Exynos5260 Clock Controller
Exynos5260 has 13 clock controllers which are instantiated
independently from the device-tree. These clock controllers
generate and supply clocks to various hardware blocks within
the SoC.
Each clock is assigned an identifier and client nodes can use
this identifier to specify the clock which they consume. All
available clocks are defined as preprocessor macros in
dt-bindings/clock/exynos5260-clk.h header and can be used in
device tree sources.
External clocks:
There are several clocks that are generated outside the SoC. It
is expected that they are defined using standard clock bindings
with following clock-output-names:
- "fin_pll" - PLL input clock from XXTI
- "xrtcxti" - input clock from XRTCXTI
- "ioclk_pcm_extclk" - pcm external operation clock
- "ioclk_spdif_extclk" - spdif external operation clock
- "ioclk_i2s_cdclk" - i2s0 codec clock
Phy clocks:
There are several clocks which are generated by specific PHYs.
These clocks are fed into the clock controller and then routed to
the hardware blocks. These clocks are defined as fixed clocks in the
driver with following names:
- "phyclk_dptx_phy_ch3_txd_clk" - dp phy clock for channel 3
- "phyclk_dptx_phy_ch2_txd_clk" - dp phy clock for channel 2
- "phyclk_dptx_phy_ch1_txd_clk" - dp phy clock for channel 1
- "phyclk_dptx_phy_ch0_txd_clk" - dp phy clock for channel 0
- "phyclk_hdmi_phy_tmds_clko" - hdmi phy tmds clock
- "phyclk_hdmi_phy_pixel_clko" - hdmi phy pixel clock
- "phyclk_hdmi_link_o_tmds_clkhi" - hdmi phy for hdmi link
- "phyclk_dptx_phy_o_ref_clk_24m" - dp phy reference clock
- "phyclk_dptx_phy_clk_div2"
- "phyclk_mipi_dphy_4l_m_rxclkesc0"
- "phyclk_usbhost20_phy_phyclock" - usb 2.0 phy clock
- "phyclk_usbhost20_phy_freeclk"
- "phyclk_usbhost20_phy_clk48mohci"
- "phyclk_usbdrd30_udrd30_pipe_pclk"
- "phyclk_usbdrd30_udrd30_phyclock" - usb 3.0 phy clock
Required Properties for Clock Controller:
- compatible: should be one of the following.
1) "samsung,exynos5260-clock-top"
2) "samsung,exynos5260-clock-peri"
3) "samsung,exynos5260-clock-egl"
4) "samsung,exynos5260-clock-kfc"
5) "samsung,exynos5260-clock-g2d"
6) "samsung,exynos5260-clock-mif"
7) "samsung,exynos5260-clock-mfc"
8) "samsung,exynos5260-clock-g3d"
9) "samsung,exynos5260-clock-fsys"
10) "samsung,exynos5260-clock-aud"
11) "samsung,exynos5260-clock-isp"
12) "samsung,exynos5260-clock-gscl"
13) "samsung,exynos5260-clock-disp"
- reg: physical base address of the controller and the length of
memory mapped region.
- #clock-cells: should be 1.
- clocks: list of clock identifiers which are fed as the input to
the given clock controller. Please refer the next section to find
the input clocks for a given controller.
- clock-names: list of names of clocks which are fed as the input
to the given clock controller.
Input clocks for top clock controller:
- fin_pll
- dout_mem_pll
- dout_bus_pll
- dout_media_pll
Input clocks for peri clock controller:
- fin_pll
- ioclk_pcm_extclk
- ioclk_i2s_cdclk
- ioclk_spdif_extclk
- phyclk_hdmi_phy_ref_cko
- dout_aclk_peri_66
- dout_sclk_peri_uart0
- dout_sclk_peri_uart1
- dout_sclk_peri_uart2
- dout_sclk_peri_spi0_b
- dout_sclk_peri_spi1_b
- dout_sclk_peri_spi2_b
- dout_aclk_peri_aud
- dout_sclk_peri_spi0_b
Input clocks for egl clock controller:
- fin_pll
- dout_bus_pll
Input clocks for kfc clock controller:
- fin_pll
- dout_media_pll
Input clocks for g2d clock controller:
- fin_pll
- dout_aclk_g2d_333
Input clocks for mif clock controller:
- fin_pll
Input clocks for mfc clock controller:
- fin_pll
- dout_aclk_mfc_333
Input clocks for g3d clock controller:
- fin_pll
Input clocks for fsys clock controller:
- fin_pll
- phyclk_usbhost20_phy_phyclock
- phyclk_usbhost20_phy_freeclk
- phyclk_usbhost20_phy_clk48mohci
- phyclk_usbdrd30_udrd30_pipe_pclk
- phyclk_usbdrd30_udrd30_phyclock
- dout_aclk_fsys_200
Input clocks for aud clock controller:
- fin_pll
- fout_aud_pll
- ioclk_i2s_cdclk
- ioclk_pcm_extclk
Input clocks for isp clock controller:
- fin_pll
- dout_aclk_isp1_266
- dout_aclk_isp1_400
- mout_aclk_isp1_266
Input clocks for gscl clock controller:
- fin_pll
- dout_aclk_gscl_400
- dout_aclk_gscl_333
Input clocks for disp clock controller:
- fin_pll
- phyclk_dptx_phy_ch3_txd_clk
- phyclk_dptx_phy_ch2_txd_clk
- phyclk_dptx_phy_ch1_txd_clk
- phyclk_dptx_phy_ch0_txd_clk
- phyclk_hdmi_phy_tmds_clko
- phyclk_hdmi_phy_ref_clko
- phyclk_hdmi_phy_pixel_clko
- phyclk_hdmi_link_o_tmds_clkhi
- phyclk_mipi_dphy_4l_m_txbyte_clkhs
- phyclk_dptx_phy_o_ref_clk_24m
- phyclk_dptx_phy_clk_div2
- phyclk_mipi_dphy_4l_m_rxclkesc0
- phyclk_hdmi_phy_ref_cko
- ioclk_spdif_extclk
- dout_aclk_peri_aud
- dout_aclk_disp_222
- dout_sclk_disp_pixel
- dout_aclk_disp_333
Example 1: An example of a clock controller node is listed below.
clock_mfc: clock-controller@11090000 {
compatible = "samsung,exynos5260-clock-mfc";
clock = <&fin_pll>, <&clock_top TOP_DOUT_ACLK_MFC_333>;
clock-names = "fin_pll", "dout_aclk_mfc_333";
reg = <0x11090000 0x10000>;
#clock-cells = <1>;
};
Example 2: UART controller node that consumes the clock generated by the
peri clock controller. Refer to the standard clock bindings for
information about 'clocks' and 'clock-names' property.
serial@12c00000 {
compatible = "samsung,exynos4210-uart";
reg = <0x12C00000 0x100>;
interrupts = <0 146 0>;
clocks = <&clock_peri PERI_PCLK_UART0>, <&clock_peri PERI_SCLK_UART0>;
clock-names = "uart", "clk_uart_baud0";
};

50
Documentation/devicetree/bindings/clock/exynos5410-clock.txt
View file

@ -1,50 +0,0 @@
* Samsung Exynos5410 Clock Controller
The Exynos5410 clock controller generates and supplies clock to various
controllers within the Exynos5410 SoC.
Required Properties:
- compatible: should be "samsung,exynos5410-clock"
- reg: physical base address of the controller and length of memory mapped
region.
- #clock-cells: should be 1.
- clocks: should contain an entry specifying the root clock from external
oscillator supplied through XXTI or XusbXTI pin. This clock should be
defined using standard clock bindings with "fin_pll" clock-output-name.
That clock is being passed internally to the 9 PLLs.
All available clocks are defined as preprocessor macros in
dt-bindings/clock/exynos5410.h header and can be used in device
tree sources.
Example 1: An example of a clock controller node is listed below.
fin_pll: xxti {
compatible = "fixed-clock";
clock-frequency = <24000000>;
clock-output-names = "fin_pll";
#clock-cells = <0>;
};
clock: clock-controller@10010000 {
compatible = "samsung,exynos5410-clock";
reg = <0x10010000 0x30000>;
#clock-cells = <1>;
clocks = <&fin_pll>;
};
Example 2: UART controller node that consumes the clock generated by the clock
controller. Refer to the standard clock bindings for information
about 'clocks' and 'clock-names' property.
serial@12c20000 {
compatible = "samsung,exynos4210-uart";
reg = <0x12C00000 0x100>;
interrupts = <0 51 0>;
clocks = <&clock CLK_UART0>, <&clock CLK_SCLK_UART0>;
clock-names = "uart", "clk_uart_baud0";
};

507
Documentation/devicetree/bindings/clock/exynos5433-clock.txt
View file

@ -1,507 +0,0 @@
* Samsung Exynos5433 CMU (Clock Management Units)
The Exynos5433 clock controller generates and supplies clock to various
controllers within the Exynos5433 SoC.
Required Properties:
- compatible: should be one of the following.
- "samsung,exynos5433-cmu-top" - clock controller compatible for CMU_TOP
which generates clocks for IMEM/FSYS/G3D/GSCL/HEVC/MSCL/G2D/MFC/PERIC/PERIS
domains and bus clocks.
- "samsung,exynos5433-cmu-cpif" - clock controller compatible for CMU_CPIF
which generates clocks for LLI (Low Latency Interface) IP.
- "samsung,exynos5433-cmu-mif" - clock controller compatible for CMU_MIF
which generates clocks for DRAM Memory Controller domain.
- "samsung,exynos5433-cmu-peric" - clock controller compatible for CMU_PERIC
which generates clocks for UART/I2C/SPI/I2S/PCM/SPDIF/PWM/SLIMBUS IPs.
- "samsung,exynos5433-cmu-peris" - clock controller compatible for CMU_PERIS
which generates clocks for PMU/TMU/MCT/WDT/RTC/SECKEY/TZPC IPs.
- "samsung,exynos5433-cmu-fsys" - clock controller compatible for CMU_FSYS
which generates clocks for USB/UFS/SDMMC/TSI/PDMA IPs.
- "samsung,exynos5433-cmu-g2d" - clock controller compatible for CMU_G2D
which generates clocks for G2D/MDMA IPs.
- "samsung,exynos5433-cmu-disp" - clock controller compatible for CMU_DISP
which generates clocks for Display (DECON/HDMI/DSIM/MIXER) IPs.
- "samsung,exynos5433-cmu-aud" - clock controller compatible for CMU_AUD
which generates clocks for Cortex-A5/BUS/AUDIO clocks.
- "samsung,exynos5433-cmu-bus0", "samsung,exynos5433-cmu-bus1"
and "samsung,exynos5433-cmu-bus2" - clock controller compatible for CMU_BUS
which generates global data buses clock and global peripheral buses clock.
- "samsung,exynos5433-cmu-g3d" - clock controller compatible for CMU_G3D
which generates clocks for 3D Graphics Engine IP.
- "samsung,exynos5433-cmu-gscl" - clock controller compatible for CMU_GSCL
which generates clocks for GSCALER IPs.
- "samsung,exynos5433-cmu-apollo"- clock controller compatible for CMU_APOLLO
which generates clocks for Cortex-A53 Quad-core processor.
- "samsung,exynos5433-cmu-atlas" - clock controller compatible for CMU_ATLAS
which generates clocks for Cortex-A57 Quad-core processor, CoreSight and
L2 cache controller.
- "samsung,exynos5433-cmu-mscl" - clock controller compatible for CMU_MSCL
which generates clocks for M2M (Memory to Memory) scaler and JPEG IPs.
- "samsung,exynos5433-cmu-mfc" - clock controller compatible for CMU_MFC
which generates clocks for MFC(Multi-Format Codec) IP.
- "samsung,exynos5433-cmu-hevc" - clock controller compatible for CMU_HEVC
which generates clocks for HEVC(High Efficiency Video Codec) decoder IP.
- "samsung,exynos5433-cmu-isp" - clock controller compatible for CMU_ISP
which generates clocks for FIMC-ISP/DRC/SCLC/DIS/3DNR IPs.
- "samsung,exynos5433-cmu-cam0" - clock controller compatible for CMU_CAM0
which generates clocks for MIPI_CSIS{0|1}/FIMC_LITE_{A|B|D}/FIMC_3AA{0|1}
IPs.
- "samsung,exynos5433-cmu-cam1" - clock controller compatible for CMU_CAM1
which generates clocks for Cortex-A5/MIPI_CSIS2/FIMC-LITE_C/FIMC-FD IPs.
- "samsung,exynos5433-cmu-imem" - clock controller compatible for CMU_IMEM
which generates clocks for SSS (Security SubSystem) and SlimSSS IPs.
- reg: physical base address of the controller and length of memory mapped
region.
- #clock-cells: should be 1.
- clocks: list of the clock controller input clock identifiers,
from common clock bindings. Please refer the next section
to find the input clocks for a given controller.
- clock-names: list of the clock controller input clock names,
as described in clock-bindings.txt.
Input clocks for top clock controller:
- oscclk
- sclk_mphy_pll
- sclk_mfc_pll
- sclk_bus_pll
Input clocks for cpif clock controller:
- oscclk
Input clocks for mif clock controller:
- oscclk
- sclk_mphy_pll
Input clocks for fsys clock controller:
- oscclk
- sclk_ufs_mphy
- aclk_fsys_200
- sclk_pcie_100_fsys
- sclk_ufsunipro_fsys
- sclk_mmc2_fsys
- sclk_mmc1_fsys
- sclk_mmc0_fsys
- sclk_usbhost30_fsys
- sclk_usbdrd30_fsys
Input clocks for g2d clock controller:
- oscclk
- aclk_g2d_266
- aclk_g2d_400
Input clocks for disp clock controller:
- oscclk
- sclk_dsim1_disp
- sclk_dsim0_disp
- sclk_dsd_disp
- sclk_decon_tv_eclk_disp
- sclk_decon_vclk_disp
- sclk_decon_eclk_disp
- sclk_decon_tv_vclk_disp
- aclk_disp_333
Input clocks for audio clock controller:
- oscclk
- fout_aud_pll
Input clocks for bus0 clock controller:
- aclk_bus0_400
Input clocks for bus1 clock controller:
- aclk_bus1_400
Input clocks for bus2 clock controller:
- oscclk
- aclk_bus2_400
Input clocks for g3d clock controller:
- oscclk
- aclk_g3d_400
Input clocks for gscl clock controller:
- oscclk
- aclk_gscl_111
- aclk_gscl_333
Input clocks for apollo clock controller:
- oscclk
- sclk_bus_pll_apollo
Input clocks for atlas clock controller:
- oscclk
- sclk_bus_pll_atlas
Input clocks for mscl clock controller:
- oscclk
- sclk_jpeg_mscl
- aclk_mscl_400
Input clocks for mfc clock controller:
- oscclk
- aclk_mfc_400
Input clocks for hevc clock controller:
- oscclk
- aclk_hevc_400
Input clocks for isp clock controller:
- oscclk
- aclk_isp_dis_400
- aclk_isp_400
Input clocks for cam0 clock controller:
- oscclk
- aclk_cam0_333
- aclk_cam0_400
- aclk_cam0_552
Input clocks for cam1 clock controller:
- oscclk
- sclk_isp_uart_cam1
- sclk_isp_spi1_cam1
- sclk_isp_spi0_cam1
- aclk_cam1_333
- aclk_cam1_400
- aclk_cam1_552
Input clocks for imem clock controller:
- oscclk
- aclk_imem_sssx_266
- aclk_imem_266
- aclk_imem_200
Optional properties:
- power-domains: a phandle to respective power domain node as described by
generic PM domain bindings (see power/power_domain.txt for more
information).
Each clock is assigned an identifier and client nodes can use this identifier
to specify the clock which they consume.
All available clocks are defined as preprocessor macros in
dt-bindings/clock/exynos5433.h header and can be used in device
tree sources.
Example 1: Examples of 'oscclk' source clock node are listed below.
xxti: xxti {
compatible = "fixed-clock";
clock-output-names = "oscclk";
#clock-cells = <0>;
};
Example 2: Examples of clock controller nodes are listed below.
cmu_top: clock-controller@10030000 {
compatible = "samsung,exynos5433-cmu-top";
reg = <0x10030000 0x0c04>;
#clock-cells = <1>;
clock-names = "oscclk",
"sclk_mphy_pll",
"sclk_mfc_pll",
"sclk_bus_pll";
clocks = <&xxti>,
<&cmu_cpif CLK_SCLK_MPHY_PLL>,
<&cmu_mif CLK_SCLK_MFC_PLL>,
<&cmu_mif CLK_SCLK_BUS_PLL>;
};
cmu_cpif: clock-controller@10fc0000 {
compatible = "samsung,exynos5433-cmu-cpif";
reg = <0x10fc0000 0x0c04>;
#clock-cells = <1>;
clock-names = "oscclk";
clocks = <&xxti>;
};
cmu_mif: clock-controller@105b0000 {
compatible = "samsung,exynos5433-cmu-mif";
reg = <0x105b0000 0x100c>;
#clock-cells = <1>;
clock-names = "oscclk",
"sclk_mphy_pll";
clocks = <&xxti>,
<&cmu_cpif CLK_SCLK_MPHY_PLL>;
};
cmu_peric: clock-controller@14c80000 {
compatible = "samsung,exynos5433-cmu-peric";
reg = <0x14c80000 0x0b08>;
#clock-cells = <1>;
};
cmu_peris: clock-controller@10040000 {
compatible = "samsung,exynos5433-cmu-peris";
reg = <0x10040000 0x0b20>;
#clock-cells = <1>;
};
cmu_fsys: clock-controller@156e0000 {
compatible = "samsung,exynos5433-cmu-fsys";
reg = <0x156e0000 0x0b04>;
#clock-cells = <1>;
clock-names = "oscclk",
"sclk_ufs_mphy",
"aclk_fsys_200",
"sclk_pcie_100_fsys",
"sclk_ufsunipro_fsys",
"sclk_mmc2_fsys",
"sclk_mmc1_fsys",
"sclk_mmc0_fsys",
"sclk_usbhost30_fsys",
"sclk_usbdrd30_fsys";
clocks = <&xxti>,
<&cmu_cpif CLK_SCLK_UFS_MPHY>,
<&cmu_top CLK_ACLK_FSYS_200>,
<&cmu_top CLK_SCLK_PCIE_100_FSYS>,
<&cmu_top CLK_SCLK_UFSUNIPRO_FSYS>,
<&cmu_top CLK_SCLK_MMC2_FSYS>,
<&cmu_top CLK_SCLK_MMC1_FSYS>,
<&cmu_top CLK_SCLK_MMC0_FSYS>,
<&cmu_top CLK_SCLK_USBHOST30_FSYS>,
<&cmu_top CLK_SCLK_USBDRD30_FSYS>;
};
cmu_g2d: clock-controller@12460000 {
compatible = "samsung,exynos5433-cmu-g2d";
reg = <0x12460000 0x0b08>;
#clock-cells = <1>;
clock-names = "oscclk",
"aclk_g2d_266",
"aclk_g2d_400";
clocks = <&xxti>,
<&cmu_top CLK_ACLK_G2D_266>,
<&cmu_top CLK_ACLK_G2D_400>;
power-domains = <&pd_g2d>;
};
cmu_disp: clock-controller@13b90000 {
compatible = "samsung,exynos5433-cmu-disp";
reg = <0x13b90000 0x0c04>;
#clock-cells = <1>;
clock-names = "oscclk",
"sclk_dsim1_disp",
"sclk_dsim0_disp",
"sclk_dsd_disp",
"sclk_decon_tv_eclk_disp",
"sclk_decon_vclk_disp",
"sclk_decon_eclk_disp",
"sclk_decon_tv_vclk_disp",
"aclk_disp_333";
clocks = <&xxti>,
<&cmu_mif CLK_SCLK_DSIM1_DISP>,
<&cmu_mif CLK_SCLK_DSIM0_DISP>,
<&cmu_mif CLK_SCLK_DSD_DISP>,
<&cmu_mif CLK_SCLK_DECON_TV_ECLK_DISP>,
<&cmu_mif CLK_SCLK_DECON_VCLK_DISP>,
<&cmu_mif CLK_SCLK_DECON_ECLK_DISP>,
<&cmu_mif CLK_SCLK_DECON_TV_VCLK_DISP>,
<&cmu_mif CLK_ACLK_DISP_333>;
power-domains = <&pd_disp>;
};
cmu_aud: clock-controller@114c0000 {
compatible = "samsung,exynos5433-cmu-aud";
reg = <0x114c0000 0x0b04>;
#clock-cells = <1>;
clock-names = "oscclk", "fout_aud_pll";
clocks = <&xxti>, <&cmu_top CLK_FOUT_AUD_PLL>;
power-domains = <&pd_aud>;
};
cmu_bus0: clock-controller@13600000 {
compatible = "samsung,exynos5433-cmu-bus0";
reg = <0x13600000 0x0b04>;
#clock-cells = <1>;
clock-names = "aclk_bus0_400";
clocks = <&cmu_top CLK_ACLK_BUS0_400>;
};
cmu_bus1: clock-controller@14800000 {
compatible = "samsung,exynos5433-cmu-bus1";
reg = <0x14800000 0x0b04>;
#clock-cells = <1>;
clock-names = "aclk_bus1_400";
clocks = <&cmu_top CLK_ACLK_BUS1_400>;
};
cmu_bus2: clock-controller@13400000 {
compatible = "samsung,exynos5433-cmu-bus2";
reg = <0x13400000 0x0b04>;
#clock-cells = <1>;
clock-names = "oscclk", "aclk_bus2_400";
clocks = <&xxti>, <&cmu_mif CLK_ACLK_BUS2_400>;
};
cmu_g3d: clock-controller@14aa0000 {
compatible = "samsung,exynos5433-cmu-g3d";
reg = <0x14aa0000 0x1000>;
#clock-cells = <1>;
clock-names = "oscclk", "aclk_g3d_400";
clocks = <&xxti>, <&cmu_top CLK_ACLK_G3D_400>;
power-domains = <&pd_g3d>;
};
cmu_gscl: clock-controller@13cf0000 {
compatible = "samsung,exynos5433-cmu-gscl";
reg = <0x13cf0000 0x0b10>;
#clock-cells = <1>;
clock-names = "oscclk",
"aclk_gscl_111",
"aclk_gscl_333";
clocks = <&xxti>,
<&cmu_top CLK_ACLK_GSCL_111>,
<&cmu_top CLK_ACLK_GSCL_333>;
power-domains = <&pd_gscl>;
};
cmu_apollo: clock-controller@11900000 {
compatible = "samsung,exynos5433-cmu-apollo";
reg = <0x11900000 0x1088>;
#clock-cells = <1>;
clock-names = "oscclk", "sclk_bus_pll_apollo";
clocks = <&xxti>, <&cmu_mif CLK_SCLK_BUS_PLL_APOLLO>;
};
cmu_atlas: clock-controller@11800000 {
compatible = "samsung,exynos5433-cmu-atlas";
reg = <0x11800000 0x1088>;
#clock-cells = <1>;
clock-names = "oscclk", "sclk_bus_pll_atlas";
clocks = <&xxti>, <&cmu_mif CLK_SCLK_BUS_PLL_ATLAS>;
};
cmu_mscl: clock-controller@105d0000 {
compatible = "samsung,exynos5433-cmu-mscl";
reg = <0x105d0000 0x0b10>;
#clock-cells = <1>;
clock-names = "oscclk",
"sclk_jpeg_mscl",
"aclk_mscl_400";
clocks = <&xxti>,
<&cmu_top CLK_SCLK_JPEG_MSCL>,
<&cmu_top CLK_ACLK_MSCL_400>;
power-domains = <&pd_mscl>;
};
cmu_mfc: clock-controller@15280000 {
compatible = "samsung,exynos5433-cmu-mfc";
reg = <0x15280000 0x0b08>;
#clock-cells = <1>;
clock-names = "oscclk", "aclk_mfc_400";
clocks = <&xxti>, <&cmu_top CLK_ACLK_MFC_400>;
power-domains = <&pd_mfc>;
};
cmu_hevc: clock-controller@14f80000 {
compatible = "samsung,exynos5433-cmu-hevc";
reg = <0x14f80000 0x0b08>;
#clock-cells = <1>;
clock-names = "oscclk", "aclk_hevc_400";
clocks = <&xxti>, <&cmu_top CLK_ACLK_HEVC_400>;
power-domains = <&pd_hevc>;
};
cmu_isp: clock-controller@146d0000 {
compatible = "samsung,exynos5433-cmu-isp";
reg = <0x146d0000 0x0b0c>;
#clock-cells = <1>;
clock-names = "oscclk",
"aclk_isp_dis_400",
"aclk_isp_400";
clocks = <&xxti>,
<&cmu_top CLK_ACLK_ISP_DIS_400>,
<&cmu_top CLK_ACLK_ISP_400>;
power-domains = <&pd_isp>;
};
cmu_cam0: clock-controller@120d0000 {
compatible = "samsung,exynos5433-cmu-cam0";
reg = <0x120d0000 0x0b0c>;
#clock-cells = <1>;
clock-names = "oscclk",
"aclk_cam0_333",
"aclk_cam0_400",
"aclk_cam0_552";
clocks = <&xxti>,
<&cmu_top CLK_ACLK_CAM0_333>,
<&cmu_top CLK_ACLK_CAM0_400>,
<&cmu_top CLK_ACLK_CAM0_552>;
power-domains = <&pd_cam0>;
};
cmu_cam1: clock-controller@145d0000 {
compatible = "samsung,exynos5433-cmu-cam1";
reg = <0x145d0000 0x0b08>;
#clock-cells = <1>;
clock-names = "oscclk",
"sclk_isp_uart_cam1",
"sclk_isp_spi1_cam1",
"sclk_isp_spi0_cam1",
"aclk_cam1_333",
"aclk_cam1_400",
"aclk_cam1_552";
clocks = <&xxti>,
<&cmu_top CLK_SCLK_ISP_UART_CAM1>,
<&cmu_top CLK_SCLK_ISP_SPI1_CAM1>,
<&cmu_top CLK_SCLK_ISP_SPI0_CAM1>,
<&cmu_top CLK_ACLK_CAM1_333>,
<&cmu_top CLK_ACLK_CAM1_400>,
<&cmu_top CLK_ACLK_CAM1_552>;
power-domains = <&pd_cam1>;
};
cmu_imem: clock-controller@11060000 {
compatible = "samsung,exynos5433-cmu-imem";
reg = <0x11060000 0x1000>;
#clock-cells = <1>;
clock-names = "oscclk",
"aclk_imem_sssx_266",
"aclk_imem_266",
"aclk_imem_200";
clocks = <&xxti>,
<&cmu_top CLK_DIV_ACLK_IMEM_SSSX_266>,
<&cmu_top CLK_DIV_ACLK_IMEM_266>,
<&cmu_top CLK_DIV_ACLK_IMEM_200>;
};
Example 3: UART controller node that consumes the clock generated by the clock
controller.
serial_0: serial@14c10000 {
compatible = "samsung,exynos5433-uart";
reg = <0x14C10000 0x100>;
interrupts = <0 421 0>;
clocks = <&cmu_peric CLK_PCLK_UART0>,
<&cmu_peric CLK_SCLK_UART0>;
clock-names = "uart", "clk_uart_baud0";
pinctrl-names = "default";
pinctrl-0 = <&uart0_bus>;
};

108
Documentation/devicetree/bindings/clock/exynos7-clock.txt
View file

@ -1,108 +0,0 @@
* Samsung Exynos7 Clock Controller
Exynos7 clock controller has various blocks which are instantiated
independently from the device-tree. These clock controllers
generate and supply clocks to various hardware blocks within
the SoC.
Each clock is assigned an identifier and client nodes can use
this identifier to specify the clock which they consume. All
available clocks are defined as preprocessor macros in
dt-bindings/clock/exynos7-clk.h header and can be used in
device tree sources.
External clocks:
There are several clocks that are generated outside the SoC. It
is expected that they are defined using standard clock bindings
with following clock-output-names:
- "fin_pll" - PLL input clock from XXTI
Required Properties for Clock Controller:
- compatible: clock controllers will use one of the following
compatible strings to indicate the clock controller
functionality.
- "samsung,exynos7-clock-topc"
- "samsung,exynos7-clock-top0"
- "samsung,exynos7-clock-top1"
- "samsung,exynos7-clock-ccore"
- "samsung,exynos7-clock-peric0"
- "samsung,exynos7-clock-peric1"
- "samsung,exynos7-clock-peris"
- "samsung,exynos7-clock-fsys0"
- "samsung,exynos7-clock-fsys1"
- "samsung,exynos7-clock-mscl"
- "samsung,exynos7-clock-aud"
- reg: physical base address of the controller and the length of
memory mapped region.
- #clock-cells: should be 1.
- clocks: list of clock identifiers which are fed as the input to
the given clock controller. Please refer the next section to
find the input clocks for a given controller.
- clock-names: list of names of clocks which are fed as the input
to the given clock controller.
Input clocks for top0 clock controller:
- fin_pll
- dout_sclk_bus0_pll
- dout_sclk_bus1_pll
- dout_sclk_cc_pll
- dout_sclk_mfc_pll
- dout_sclk_aud_pll
Input clocks for top1 clock controller:
- fin_pll
- dout_sclk_bus0_pll
- dout_sclk_bus1_pll
- dout_sclk_cc_pll
- dout_sclk_mfc_pll
Input clocks for ccore clock controller:
- fin_pll
- dout_aclk_ccore_133
Input clocks for peric0 clock controller:
- fin_pll
- dout_aclk_peric0_66
- sclk_uart0
Input clocks for peric1 clock controller:
- fin_pll
- dout_aclk_peric1_66
- sclk_uart1
- sclk_uart2
- sclk_uart3
- sclk_spi0
- sclk_spi1
- sclk_spi2
- sclk_spi3
- sclk_spi4
- sclk_i2s1
- sclk_pcm1
- sclk_spdif
Input clocks for peris clock controller:
- fin_pll
- dout_aclk_peris_66
Input clocks for fsys0 clock controller:
- fin_pll
- dout_aclk_fsys0_200
- dout_sclk_mmc2
Input clocks for fsys1 clock controller:
- fin_pll
- dout_aclk_fsys1_200
- dout_sclk_mmc0
- dout_sclk_mmc1
Input clocks for aud clock controller:
- fin_pll
- fout_aud_pll

9
Documentation/devicetree/bindings/clock/imx5-clock.yaml
View file

@ -55,11 +55,4 @@ examples:
<0 72 IRQ_TYPE_LEVEL_HIGH>;
#clock-cells = <1>;
};
can@53fc8000 {
compatible = "fsl,imx53-flexcan", "fsl,imx25-flexcan";
reg = <0x53fc8000 0x4000>;
interrupts = <82>;
clocks = <&clks IMX5_CLK_CAN1_IPG_GATE>, <&clks IMX5_CLK_CAN1_SERIAL_GATE>;
clock-names = "ipg", "per";
};
...

60
Documentation/devicetree/bindings/clock/microchip,lan966x-gck.yaml Normal file
View file

@ -0,0 +1,60 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/clock/microchip,lan966x-gck.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Microchip LAN966X Generic Clock Controller
maintainers:
- Kavyasree Kotagiri <kavyasree.kotagiri@microchip.com>
description: |
The LAN966X Generic clock controller contains 3 PLLs - cpu_clk,
ddr_clk and sys_clk. This clock controller generates and supplies
clock to various peripherals within the SoC.
properties:
compatible:
const: microchip,lan966x-gck
reg:
minItems: 1
items:
- description: Generic clock registers
- description: Optional gate clock registers
clocks:
items:
- description: CPU clock source
- description: DDR clock source
- description: System clock source
clock-names:
items:
- const: cpu
- const: ddr
- const: sys
'#clock-cells':
const: 1
required:
- compatible
- reg
- clocks
- clock-names
- '#clock-cells'
additionalProperties: false
examples:
- |
clks: clock-controller@e00c00a8 {
compatible = "microchip,lan966x-gck";
#clock-cells = <1>;
clocks = <&cpu_clk>, <&ddr_clk>, <&sys_clk>;
clock-names = "cpu", "ddr", "sys";
reg = <0xe00c00a8 0x38>;
};
...

97
Documentation/devicetree/bindings/clock/qcom,gcc-msm8976.yaml Normal file
View file

@ -0,0 +1,97 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/clock/qcom,gcc-msm8976.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Qualcomm Global Clock & Reset Controller Binding for MSM8976
maintainers:
- Stephen Boyd <sboyd@kernel.org>
- Taniya Das <tdas@codeaurora.org>
description: |
Qualcomm global clock control module which supports the clocks, resets and
power domains on MSM8976.
See also:
- dt-bindings/clock/qcom,gcc-msm8976.h
properties:
compatible:
enum:
- qcom,gcc-msm8976
- qcom,gcc-msm8976-v1.1
clocks:
items:
- description: XO source
- description: Always-on XO source
- description: Pixel clock from DSI PHY0
- description: Byte clock from DSI PHY0
- description: Pixel clock from DSI PHY1
- description: Byte clock from DSI PHY1
clock-names:
items:
- const: xo
- const: xo_a
- const: dsi0pll
- const: dsi0pllbyte
- const: dsi1pll
- const: dsi1pllbyte
vdd_gfx-supply:
description:
Phandle to voltage regulator providing power to the GX domain.
'#clock-cells':
const: 1
'#reset-cells':
const: 1
'#power-domain-cells':
const: 1
reg:
maxItems: 1
required:
- compatible
- reg
- clocks
- clock-names
- vdd_gfx-supply
- '#clock-cells'
- '#reset-cells'
- '#power-domain-cells'
additionalProperties: false
examples:
- |
clock-controller@1800000 {
compatible = "qcom,gcc-msm8976";
#clock-cells = <1>;
#reset-cells = <1>;
#power-domain-cells = <1>;
reg = <0x1800000 0x80000>;
clocks = <&xo_board>,
<&xo_board>,
<&dsi0_phy 1>,
<&dsi0_phy 0>,
<&dsi1_phy 1>,
<&dsi1_phy 0>;
clock-names = "xo",
"xo_a",
"dsi0pll",
"dsi0pllbyte",
"dsi1pll",
"dsi1pllbyte";
vdd_gfx-supply = <&pm8004_s5>;
};
...

2
Documentation/devicetree/bindings/clock/qcom,rpmhcc.yaml
View file

@ -22,10 +22,12 @@ properties:
- qcom,sc8180x-rpmh-clk
- qcom,sdm845-rpmh-clk
- qcom,sdx55-rpmh-clk
- qcom,sdx65-rpmh-clk
- qcom,sm6350-rpmh-clk
- qcom,sm8150-rpmh-clk
- qcom,sm8250-rpmh-clk
- qcom,sm8350-rpmh-clk
- qcom,sm8450-rpmh-clk
clocks:
maxItems: 1

1
Documentation/devicetree/bindings/clock/renesas,cpg-mssr.yaml
View file

@ -48,6 +48,7 @@ properties:
- renesas,r8a77990-cpg-mssr # R-Car E3
- renesas,r8a77995-cpg-mssr # R-Car D3
- renesas,r8a779a0-cpg-mssr # R-Car V3U
- renesas,r8a779f0-cpg-mssr # R-Car S4-8
reg:
maxItems: 1

382
Documentation/devicetree/bindings/clock/samsung,exynos5260-clock.yaml Normal file
View file

@ -0,0 +1,382 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/clock/samsung,exynos5260-clock.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Samsung Exynos5260 SoC clock controller
maintainers:
- Chanwoo Choi <cw00.choi@samsung.com>
- Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com>
- Sylwester Nawrocki <s.nawrocki@samsung.com>
- Tomasz Figa <tomasz.figa@gmail.com>
description: |
Expected external clocks, defined in DTS as fixed-rate clocks with a matching
name::
- "fin_pll" - PLL input clock from XXTI
- "xrtcxti" - input clock from XRTCXTI
- "ioclk_pcm_extclk" - pcm external operation clock
- "ioclk_spdif_extclk" - spdif external operation clock
- "ioclk_i2s_cdclk" - i2s0 codec clock
Phy clocks::
There are several clocks which are generated by specific PHYs. These clocks
are fed into the clock controller and then routed to the hardware blocks.
These clocks are defined as fixed clocks in the driver with following names::
- "phyclk_dptx_phy_ch3_txd_clk" - dp phy clock for channel 3
- "phyclk_dptx_phy_ch2_txd_clk" - dp phy clock for channel 2
- "phyclk_dptx_phy_ch1_txd_clk" - dp phy clock for channel 1
- "phyclk_dptx_phy_ch0_txd_clk" - dp phy clock for channel 0
- "phyclk_hdmi_phy_tmds_clko" - hdmi phy tmds clock
- "phyclk_hdmi_phy_pixel_clko" - hdmi phy pixel clock
- "phyclk_hdmi_link_o_tmds_clkhi" - hdmi phy for hdmi link
- "phyclk_dptx_phy_o_ref_clk_24m" - dp phy reference clock
- "phyclk_dptx_phy_clk_div2"
- "phyclk_mipi_dphy_4l_m_rxclkesc0"
- "phyclk_usbhost20_phy_phyclock" - usb 2.0 phy clock
- "phyclk_usbhost20_phy_freeclk"
- "phyclk_usbhost20_phy_clk48mohci"
- "phyclk_usbdrd30_udrd30_pipe_pclk"
- "phyclk_usbdrd30_udrd30_phyclock" - usb 3.0 phy clock
All available clocks are defined as preprocessor macros in
include/dt-bindings/clock/exynos5260-clk.h header.
properties:
compatible:
enum:
- samsung,exynos5260-clock-top
- samsung,exynos5260-clock-peri
- samsung,exynos5260-clock-egl
- samsung,exynos5260-clock-kfc
- samsung,exynos5260-clock-g2d
- samsung,exynos5260-clock-mif
- samsung,exynos5260-clock-mfc
- samsung,exynos5260-clock-g3d
- samsung,exynos5260-clock-fsys
- samsung,exynos5260-clock-aud
- samsung,exynos5260-clock-isp
- samsung,exynos5260-clock-gscl
- samsung,exynos5260-clock-disp
clocks:
minItems: 1
maxItems: 19
clock-names:
minItems: 1
maxItems: 19
"#clock-cells":
const: 1
reg:
maxItems: 1
required:
- compatible
- "#clock-cells"
- reg
allOf:
- if:
properties:
compatible:
contains:
const: samsung,exynos5260-clock-top
then:
properties:
clocks:
minItems: 4
maxItems: 4
clock-names:
items:
- const: fin_pll
- const: dout_mem_pll
- const: dout_bus_pll
- const: dout_media_pll
required:
- clock-names
- clocks
- if:
properties:
compatible:
contains:
const: samsung,exynos5260-clock-peri
then:
properties:
clocks:
minItems: 13
maxItems: 13
clock-names:
items:
- const: fin_pll
- const: ioclk_pcm_extclk
- const: ioclk_i2s_cdclk
- const: ioclk_spdif_extclk
- const: phyclk_hdmi_phy_ref_cko
- const: dout_aclk_peri_66
- const: dout_sclk_peri_uart0
- const: dout_sclk_peri_uart1
- const: dout_sclk_peri_uart2
- const: dout_sclk_peri_spi0_b
- const: dout_sclk_peri_spi1_b
- const: dout_sclk_peri_spi2_b
- const: dout_aclk_peri_aud
required:
- clock-names
- clocks
- if:
properties:
compatible:
contains:
const: samsung,exynos5260-clock-egl
then:
properties:
clocks:
minItems: 2
maxItems: 2
clock-names:
items:
- const: fin_pll
- const: dout_bus_pll
required:
- clock-names
- clocks
- if:
properties:
compatible:
contains:
const: samsung,exynos5260-clock-kfc
then:
properties:
clocks:
minItems: 2
maxItems: 2
clock-names:
items:
- const: fin_pll
- const: dout_media_pll
required:
- clock-names
- clocks
- if:
properties:
compatible:
contains:
const: samsung,exynos5260-clock-g2d
then:
properties:
clocks:
minItems: 2
maxItems: 2
clock-names:
items:
- const: fin_pll
- const: dout_aclk_g2d_333
required:
- clock-names
- clocks
- if:
properties:
compatible:
contains:
const: samsung,exynos5260-clock-mif
then:
properties:
clocks:
minItems: 1
maxItems: 1
clock-names:
items:
- const: fin_pll
required:
- clock-names
- clocks
- if:
properties:
compatible:
contains:
const: samsung,exynos5260-clock-mfc
then:
properties:
clocks:
minItems: 2
maxItems: 2
clock-names:
items:
- const: fin_pll
- const: dout_aclk_mfc_333
required:
- clock-names
- clocks
- if:
properties:
compatible:
contains:
const: samsung,exynos5260-clock-g3d
then:
properties:
clocks:
minItems: 1
maxItems: 1
clock-names:
items:
- const: fin_pll
required:
- clock-names
- clocks
- if:
properties:
compatible:
contains:
const: samsung,exynos5260-clock-fsys
then:
properties:
clocks:
minItems: 7
maxItems: 7
clock-names:
items:
- const: fin_pll
- const: phyclk_usbhost20_phy_phyclock
- const: phyclk_usbhost20_phy_freeclk
- const: phyclk_usbhost20_phy_clk48mohci
- const: phyclk_usbdrd30_udrd30_pipe_pclk
- const: phyclk_usbdrd30_udrd30_phyclock
- const: dout_aclk_fsys_200
required:
- clock-names
- clocks
- if:
properties:
compatible:
contains:
const: samsung,exynos5260-clock-aud
then:
properties:
clocks:
minItems: 4
maxItems: 4
clock-names:
items:
- const: fin_pll
- const: fout_aud_pll
- const: ioclk_i2s_cdclk
- const: ioclk_pcm_extclk
required:
- clock-names
- clocks
- if:
properties:
compatible:
contains:
const: samsung,exynos5260-clock-isp
then:
properties:
clocks:
minItems: 4
maxItems: 4
clock-names:
items:
- const: fin_pll
- const: dout_aclk_isp1_266
- const: dout_aclk_isp1_400
- const: mout_aclk_isp1_266
required:
- clock-names
- clocks
- if:
properties:
compatible:
contains:
const: samsung,exynos5260-clock-gscl
then:
properties:
clocks:
minItems: 3
maxItems: 3
clock-names:
items:
- const: fin_pll
- const: dout_aclk_gscl_400
- const: dout_aclk_gscl_333
required:
- clock-names
- clocks
- if:
properties:
compatible:
contains:
const: samsung,exynos5260-clock-disp
then:
properties:
clocks:
minItems: 19
maxItems: 19
clock-names:
items:
- const: fin_pll
- const: phyclk_dptx_phy_ch3_txd_clk
- const: phyclk_dptx_phy_ch2_txd_clk
- const: phyclk_dptx_phy_ch1_txd_clk
- const: phyclk_dptx_phy_ch0_txd_clk
- const: phyclk_hdmi_phy_tmds_clko
- const: phyclk_hdmi_phy_ref_clko
- const: phyclk_hdmi_phy_pixel_clko
- const: phyclk_hdmi_link_o_tmds_clkhi
- const: phyclk_mipi_dphy_4l_m_txbyte_clkhs
- const: phyclk_dptx_phy_o_ref_clk_24m
- const: phyclk_dptx_phy_clk_div2
- const: phyclk_mipi_dphy_4l_m_rxclkesc0
- const: phyclk_hdmi_phy_ref_cko
- const: ioclk_spdif_extclk
- const: dout_aclk_peri_aud
- const: dout_aclk_disp_222
- const: dout_sclk_disp_pixel
- const: dout_aclk_disp_333
required:
- clock-names
- clocks
additionalProperties: false
examples:
- |
#include <dt-bindings/clock/exynos5260-clk.h>
fin_pll: clock {
compatible = "fixed-clock";
clock-output-names = "fin_pll";
#clock-cells = <0>;
clock-frequency = <24000000>;
};
clock-controller@10010000 {
compatible = "samsung,exynos5260-clock-top";
reg = <0x10010000 0x10000>;
#clock-cells = <1>;
clocks = <&fin_pll>,
<&clock_mif MIF_DOUT_MEM_PLL>,
<&clock_mif MIF_DOUT_BUS_PLL>,
<&clock_mif MIF_DOUT_MEDIA_PLL>;
clock-names = "fin_pll",
"dout_mem_pll",
"dout_bus_pll",
"dout_media_pll";
};

66
Documentation/devicetree/bindings/clock/samsung,exynos5410-clock.yaml Normal file
View file

@ -0,0 +1,66 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/clock/samsung,exynos5410-clock.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Samsung Exynos5410 SoC clock controller
maintainers:
- Chanwoo Choi <cw00.choi@samsung.com>
- Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com>
- Sylwester Nawrocki <s.nawrocki@samsung.com>
- Tomasz Figa <tomasz.figa@gmail.com>
description: |
Expected external clocks, defined in DTS as fixed-rate clocks with a matching
name::
- "fin_pll" - PLL input clock from XXTI
All available clocks are defined as preprocessor macros in
include/dt-bindings/clock/exynos5410.h header.
properties:
compatible:
oneOf:
- enum:
- samsung,exynos5410-clock
clocks:
description:
Should contain an entry specifying the root clock from external
oscillator supplied through XXTI or XusbXTI pin. This clock should be
defined using standard clock bindings with "fin_pll" clock-output-name.
That clock is being passed internally to the 9 PLLs.
maxItems: 1
"#clock-cells":
const: 1
reg:
maxItems: 1
required:
- compatible
- "#clock-cells"
- reg
additionalProperties: false
examples:
- |
#include <dt-bindings/clock/exynos5410.h>
fin_pll: osc-clock {
compatible = "fixed-clock";
clock-frequency = <24000000>;
clock-output-names = "fin_pll";
#clock-cells = <0>;
};
clock-controller@10010000 {
compatible = "samsung,exynos5410-clock";
reg = <0x10010000 0x30000>;
#clock-cells = <1>;
clocks = <&fin_pll>;
};

524
Documentation/devicetree/bindings/clock/samsung,exynos5433-clock.yaml Normal file
View file

@ -0,0 +1,524 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/clock/samsung,exynos5433-clock.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Samsung Exynos5433 SoC clock controller
maintainers:
- Chanwoo Choi <cw00.choi@samsung.com>
- Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com>
- Sylwester Nawrocki <s.nawrocki@samsung.com>
- Tomasz Figa <tomasz.figa@gmail.com>
description: |
Expected external clocks, defined in DTS as fixed-rate clocks with a matching
name::
- "oscclk" - PLL input clock from XXTI
All available clocks are defined as preprocessor macros in
include/dt-bindings/clock/exynos5433.h header.
properties:
compatible:
enum:
# CMU_TOP which generates clocks for
# IMEM/FSYS/G3D/GSCL/HEVC/MSCL/G2D/MFC/PERIC/PERIS domains and bus
# clocks
- samsung,exynos5433-cmu-top
# CMU_CPIF which generates clocks for LLI (Low Latency Interface) IP
- samsung,exynos5433-cmu-cpif
# CMU_MIF which generates clocks for DRAM Memory Controller domain
- samsung,exynos5433-cmu-mif
# CMU_PERIC which generates clocks for
# UART/I2C/SPI/I2S/PCM/SPDIF/PWM/SLIMBUS IPs
- samsung,exynos5433-cmu-peric
# CMU_PERIS which generates clocks for PMU/TMU/MCT/WDT/RTC/SECKEY/TZPC IPs
- samsung,exynos5433-cmu-peris
# CMU_FSYS which generates clocks for USB/UFS/SDMMC/TSI/PDMA IPs
- samsung,exynos5433-cmu-fsys
- samsung,exynos5433-cmu-g2d
# CMU_DISP which generates clocks for Display (DECON/HDMI/DSIM/MIXER) IPs
- samsung,exynos5433-cmu-disp
- samsung,exynos5433-cmu-aud
- samsung,exynos5433-cmu-bus0
- samsung,exynos5433-cmu-bus1
- samsung,exynos5433-cmu-bus2
- samsung,exynos5433-cmu-g3d
- samsung,exynos5433-cmu-gscl
- samsung,exynos5433-cmu-apollo
# CMU_ATLAS which generates clocks for Cortex-A57 Quad-core processor,
# CoreSight and L2 cache controller
- samsung,exynos5433-cmu-atlas
# CMU_MSCL which generates clocks for M2M (Memory to Memory) scaler and
# JPEG IPs
- samsung,exynos5433-cmu-mscl
- samsung,exynos5433-cmu-mfc
- samsung,exynos5433-cmu-hevc
# CMU_ISP which generates clocks for FIMC-ISP/DRC/SCLC/DIS/3DNR IPs
- samsung,exynos5433-cmu-isp
# CMU_CAM0 which generates clocks for
# MIPI_CSIS{0|1}/FIMC_LITE_{A|B|D}/FIMC_3AA{0|1} IPs
- samsung,exynos5433-cmu-cam0
# CMU_CAM1 which generates clocks for
# Cortex-A5/MIPI_CSIS2/FIMC-LITE_C/FIMC-FD IPs
- samsung,exynos5433-cmu-cam1
# CMU_IMEM which generates clocks for SSS (Security SubSystem) and
# SlimSSS IPs
- samsung,exynos5433-cmu-imem
clocks:
minItems: 1
maxItems: 10
clock-names:
minItems: 1
maxItems: 10
"#clock-cells":
const: 1
power-domains:
maxItems: 1
reg:
maxItems: 1
required:
- compatible
- "#clock-cells"
- reg
allOf:
- if:
properties:
compatible:
contains:
const: samsung,exynos5433-cmu-top
then:
properties:
clocks:
minItems: 4
maxItems: 4
clock-names:
items:
- const: oscclk
- const: sclk_mphy_pll
- const: sclk_mfc_pll
- const: sclk_bus_pll
required:
- clock-names
- clocks
- if:
properties:
compatible:
contains:
const: samsung,exynos5433-cmu-cpif
then:
properties:
clocks:
minItems: 1
maxItems: 1
clock-names:
items:
- const: oscclk
required:
- clock-names
- clocks
- if:
properties:
compatible:
contains:
const: samsung,exynos5433-cmu-mif
then:
properties:
clocks:
minItems: 2
maxItems: 2
clock-names:
items:
- const: oscclk
- const: sclk_mphy_pll
required:
- clock-names
- clocks
- if:
properties:
compatible:
contains:
const: samsung,exynos5433-cmu-fsys
then:
properties:
clocks:
minItems: 10
maxItems: 10
clock-names:
items:
- const: oscclk
- const: sclk_ufs_mphy
- const: aclk_fsys_200
- const: sclk_pcie_100_fsys
- const: sclk_ufsunipro_fsys
- const: sclk_mmc2_fsys
- const: sclk_mmc1_fsys
- const: sclk_mmc0_fsys
- const: sclk_usbhost30_fsys
- const: sclk_usbdrd30_fsys
required:
- clock-names
- clocks
- if:
properties:
compatible:
contains:
const: samsung,exynos5433-cmu-g2d
then:
properties:
clocks:
minItems: 3
maxItems: 3
clock-names:
items:
- const: oscclk
- const: aclk_g2d_266
- const: aclk_g2d_400
required:
- clock-names
- clocks
- if:
properties:
compatible:
contains:
const: samsung,exynos5433-cmu-disp
then:
properties:
clocks:
minItems: 9
maxItems: 9
clock-names:
items:
- const: oscclk
- const: sclk_dsim1_disp
- const: sclk_dsim0_disp
- const: sclk_dsd_disp
- const: sclk_decon_tv_eclk_disp
- const: sclk_decon_vclk_disp
- const: sclk_decon_eclk_disp
- const: sclk_decon_tv_vclk_disp
- const: aclk_disp_333
required:
- clock-names
- clocks
- if:
properties:
compatible:
contains:
const: samsung,exynos5433-cmu-aud
then:
properties:
clocks:
minItems: 2
maxItems: 2
clock-names:
items:
- const: oscclk
- const: fout_aud_pll
required:
- clock-names
- clocks
- if:
properties:
compatible:
contains:
const: samsung,exynos5433-cmu-bus0
then:
properties:
clocks:
minItems: 1
maxItems: 1
clock-names:
items:
- const: aclk_bus0_400
required:
- clock-names
- clocks
- if:
properties:
compatible:
contains:
const: samsung,exynos5433-cmu-bus1
then:
properties:
clocks:
minItems: 1
maxItems: 1
clock-names:
items:
- const: aclk_bus1_400
required:
- clock-names
- clocks
- if:
properties:
compatible:
contains:
const: samsung,exynos5433-cmu-bus2
then:
properties:
clocks:
minItems: 2
maxItems: 2
clock-names:
items:
- const: oscclk
- const: aclk_bus2_400
required:
- clock-names
- clocks
- if:
properties:
compatible:
contains:
const: samsung,exynos5433-cmu-g3d
then:
properties:
clocks:
minItems: 2
maxItems: 2
clock-names:
items:
- const: oscclk
- const: aclk_g3d_400
required:
- clock-names
- clocks
- if:
properties:
compatible:
contains:
const: samsung,exynos5433-cmu-gscl
then:
properties:
clocks:
minItems: 3
maxItems: 3
clock-names:
items:
- const: oscclk
- const: aclk_gscl_111
- const: aclk_gscl_333
required:
- clock-names
- clocks
- if:
properties:
compatible:
contains:
const: samsung,exynos5433-cmu-apollo
then:
properties:
clocks:
minItems: 2
maxItems: 2
clock-names:
items:
- const: oscclk
- const: sclk_bus_pll_apollo
required:
- clock-names
- clocks
- if:
properties:
compatible:
contains:
const: samsung,exynos5433-cmu-atlas
then:
properties:
clocks:
minItems: 2
maxItems: 2
clock-names:
items:
- const: oscclk
- const: sclk_bus_pll_atlas
required:
- clock-names
- clocks
- if:
properties:
compatible:
contains:
const: samsung,exynos5433-cmu-mscl
then:
properties:
clocks:
minItems: 3
maxItems: 3
clock-names:
items:
- const: oscclk
- const: sclk_jpeg_mscl
- const: aclk_mscl_400
required:
- clock-names
- clocks
- if:
properties:
compatible:
contains:
const: samsung,exynos5433-cmu-mfc
then:
properties:
clocks:
minItems: 2
maxItems: 2
clock-names:
items:
- const: oscclk
- const: aclk_mfc_400
required:
- clock-names
- clocks
- if:
properties:
compatible:
contains:
const: samsung,exynos5433-cmu-hevc
then:
properties:
clocks:
minItems: 2
maxItems: 2
clock-names:
items:
- const: oscclk
- const: aclk_hevc_400
required:
- clock-names
- clocks
- if:
properties:
compatible:
contains:
const: samsung,exynos5433-cmu-isp
then:
properties:
clocks:
minItems: 3
maxItems: 3
clock-names:
items:
- const: oscclk
- const: aclk_isp_dis_400
- const: aclk_isp_400
required:
- clock-names
- clocks
- if:
properties:
compatible:
contains:
const: samsung,exynos5433-cmu-cam0
then:
properties:
clocks:
minItems: 4
maxItems: 4
clock-names:
items:
- const: oscclk
- const: aclk_cam0_333
- const: aclk_cam0_400
- const: aclk_cam0_552
required:
- clock-names
- clocks
- if:
properties:
compatible:
contains:
const: samsung,exynos5433-cmu-cam1
then:
properties:
clocks:
minItems: 7
maxItems: 7
clock-names:
items:
- const: oscclk
- const: sclk_isp_uart_cam1
- const: sclk_isp_spi1_cam1
- const: sclk_isp_spi0_cam1
- const: aclk_cam1_333
- const: aclk_cam1_400
- const: aclk_cam1_552
required:
- clock-names
- clocks
- if:
properties:
compatible:
contains:
const: samsung,exynos5433-cmu-imem
then:
properties:
clocks:
minItems: 4
maxItems: 4
clock-names:
items:
- const: oscclk
- const: aclk_imem_sssx_266
- const: aclk_imem_266
- const: aclk_imem_200
required:
- clock-names
- clocks
additionalProperties: false
examples:
- |
#include <dt-bindings/clock/exynos5433.h>
xxti: clock {
compatible = "fixed-clock";
clock-output-names = "oscclk";
#clock-cells = <0>;
clock-frequency = <24000000>;
};
clock-controller@10030000 {
compatible = "samsung,exynos5433-cmu-top";
reg = <0x10030000 0x1000>;
#clock-cells = <1>;
clock-names = "oscclk",
"sclk_mphy_pll",
"sclk_mfc_pll",
"sclk_bus_pll";
clocks = <&xxti>,
<&cmu_cpif CLK_SCLK_MPHY_PLL>,
<&cmu_mif CLK_SCLK_MFC_PLL>,
<&cmu_mif CLK_SCLK_BUS_PLL>;
};

272
Documentation/devicetree/bindings/clock/samsung,exynos7-clock.yaml Normal file
View file

@ -0,0 +1,272 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/clock/samsung,exynos7-clock.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Samsung Exynos7 SoC clock controller
maintainers:
- Chanwoo Choi <cw00.choi@samsung.com>
- Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com>
- Sylwester Nawrocki <s.nawrocki@samsung.com>
- Tomasz Figa <tomasz.figa@gmail.com>
description: |
Expected external clocks, defined in DTS as fixed-rate clocks with a matching
name::
- "fin_pll" - PLL input clock from XXTI
All available clocks are defined as preprocessor macros in
include/dt-bindings/clock/exynos7-clk.h header.
properties:
compatible:
enum:
- samsung,exynos7-clock-topc
- samsung,exynos7-clock-top0
- samsung,exynos7-clock-top1
- samsung,exynos7-clock-ccore
- samsung,exynos7-clock-peric0
- samsung,exynos7-clock-peric1
- samsung,exynos7-clock-peris
- samsung,exynos7-clock-fsys0
- samsung,exynos7-clock-fsys1
- samsung,exynos7-clock-mscl
- samsung,exynos7-clock-aud
clocks:
minItems: 1
maxItems: 13
clock-names:
minItems: 1
maxItems: 13
"#clock-cells":
const: 1
reg:
maxItems: 1
required:
- compatible
- "#clock-cells"
- reg
allOf:
- if:
properties:
compatible:
contains:
const: samsung,exynos7-clock-top0
then:
properties:
clocks:
minItems: 6
maxItems: 6
clock-names:
items:
- const: fin_pll
- const: dout_sclk_bus0_pll
- const: dout_sclk_bus1_pll
- const: dout_sclk_cc_pll
- const: dout_sclk_mfc_pll
- const: dout_sclk_aud_pll
required:
- clock-names
- clocks
- if:
properties:
compatible:
contains:
const: samsung,exynos7-clock-top1
then:
properties:
clocks:
minItems: 5
maxItems: 5
clock-names:
items:
- const: fin_pll
- const: dout_sclk_bus0_pll
- const: dout_sclk_bus1_pll
- const: dout_sclk_cc_pll
- const: dout_sclk_mfc_pll
required:
- clock-names
- clocks
- if:
properties:
compatible:
contains:
const: samsung,exynos7-clock-ccore
then:
properties:
clocks:
minItems: 2
maxItems: 2
clock-names:
items:
- const: fin_pll
- const: dout_aclk_ccore_133
required:
- clock-names
- clocks
- if:
properties:
compatible:
contains:
const: samsung,exynos7-clock-peric0
then:
properties:
clocks:
minItems: 3
maxItems: 3
clock-names:
items:
- const: fin_pll
- const: dout_aclk_peric0_66
- const: sclk_uart0
required:
- clock-names
- clocks
- if:
properties:
compatible:
contains:
const: samsung,exynos7-clock-peric1
then:
properties:
clocks:
minItems: 13
maxItems: 13
clock-names:
items:
- const: fin_pll
- const: dout_aclk_peric1_66
- const: sclk_uart1
- const: sclk_uart2
- const: sclk_uart3
- const: sclk_spi0
- const: sclk_spi1
- const: sclk_spi2
- const: sclk_spi3
- const: sclk_spi4
- const: sclk_i2s1
- const: sclk_pcm1
- const: sclk_spdif
required:
- clock-names
- clocks
- if:
properties:
compatible:
contains:
const: samsung,exynos7-clock-peris
then:
properties:
clocks:
minItems: 2
maxItems: 2
clock-names:
items:
- const: fin_pll
- const: dout_aclk_peris_66
required:
- clock-names
- clocks
- if:
properties:
compatible:
contains:
const: samsung,exynos7-clock-fsys0
then:
properties:
clocks:
minItems: 3
maxItems: 3
clock-names:
items:
- const: fin_pll
- const: dout_aclk_fsys0_200
- const: dout_sclk_mmc2
required:
- clock-names
- clocks
- if:
properties:
compatible:
contains:
const: samsung,exynos7-clock-fsys1
then:
properties:
clocks:
minItems: 7
maxItems: 7
clock-names:
items:
- const: fin_pll
- const: dout_aclk_fsys1_200
- const: dout_sclk_mmc0
- const: dout_sclk_mmc1
- const: dout_sclk_ufsunipro20
- const: dout_sclk_phy_fsys1
- const: dout_sclk_phy_fsys1_26m
required:
- clock-names
- clocks
- if:
properties:
compatible:
contains:
const: samsung,exynos7-clock-aud
then:
properties:
clocks:
minItems: 2
maxItems: 2
clock-names:
items:
- const: fin_pll
- const: fout_aud_pll
required:
- clock-names
- clocks
additionalProperties: false
examples:
- |
#include <dt-bindings/clock/exynos7-clk.h>
fin_pll: clock {
compatible = "fixed-clock";
clock-output-names = "fin_pll";
#clock-cells = <0>;
clock-frequency = <24000000>;
};
clock-controller@105e0000 {
compatible = "samsung,exynos7-clock-top1";
reg = <0x105e0000 0xb000>;
#clock-cells = <1>;
clocks = <&fin_pll>,
<&clock_topc DOUT_SCLK_BUS0_PLL>,
<&clock_topc DOUT_SCLK_BUS1_PLL>,
<&clock_topc DOUT_SCLK_CC_PLL>,
<&clock_topc DOUT_SCLK_MFC_PLL>;
clock-names = "fin_pll",
"dout_sclk_bus0_pll",
"dout_sclk_bus1_pll",
"dout_sclk_cc_pll",
"dout_sclk_mfc_pll";
};

166
Documentation/devicetree/bindings/clock/samsung,exynos7885-clock.yaml Normal file
View file

@ -0,0 +1,166 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/clock/samsung,exynos7885-clock.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Samsung Exynos7885 SoC clock controller
maintainers:
- Dávid Virág <virag.david003@gmail.com>
- Chanwoo Choi <cw00.choi@samsung.com>
- Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com>
- Sylwester Nawrocki <s.nawrocki@samsung.com>
- Tomasz Figa <tomasz.figa@gmail.com>
description: |
Exynos7885 clock controller is comprised of several CMU units, generating
clocks for different domains. Those CMU units are modeled as separate device
tree nodes, and might depend on each other. The root clock in that root tree
is an external clock: OSCCLK (26 MHz). This external clock must be defined
as a fixed-rate clock in dts.
CMU_TOP is a top-level CMU, where all base clocks are prepared using PLLs and
dividers; all other leaf clocks (other CMUs) are usually derived from CMU_TOP.
Each clock is assigned an identifier and client nodes can use this identifier
to specify the clock which they consume. All clocks available for usage
in clock consumer nodes are defined as preprocessor macros in
'dt-bindings/clock/exynos7885.h' header.
properties:
compatible:
enum:
- samsung,exynos7885-cmu-top
- samsung,exynos7885-cmu-core
- samsung,exynos7885-cmu-peri
clocks:
minItems: 1
maxItems: 10
clock-names:
minItems: 1
maxItems: 10
"#clock-cells":
const: 1
reg:
maxItems: 1
allOf:
- if:
properties:
compatible:
contains:
const: samsung,exynos7885-cmu-top
then:
properties:
clocks:
items:
- description: External reference clock (26 MHz)
clock-names:
items:
- const: oscclk
- if:
properties:
compatible:
contains:
const: samsung,exynos7885-cmu-core
then:
properties:
clocks:
items:
- description: External reference clock (26 MHz)
- description: CMU_CORE bus clock (from CMU_TOP)
- description: CCI clock (from CMU_TOP)
- description: G3D clock (from CMU_TOP)
clock-names:
items:
- const: oscclk
- const: dout_core_bus
- const: dout_core_cci
- const: dout_core_g3d
- if:
properties:
compatible:
contains:
const: samsung,exynos7885-cmu-peri
then:
properties:
clocks:
items:
- description: External reference clock (26 MHz)
- description: CMU_PERI bus clock (from CMU_TOP)
- description: SPI0 clock (from CMU_TOP)
- description: SPI1 clock (from CMU_TOP)
- description: UART0 clock (from CMU_TOP)
- description: UART1 clock (from CMU_TOP)
- description: UART2 clock (from CMU_TOP)
- description: USI0 clock (from CMU_TOP)
- description: USI1 clock (from CMU_TOP)
- description: USI2 clock (from CMU_TOP)
clock-names:
items:
- const: oscclk
- const: dout_peri_bus
- const: dout_peri_spi0
- const: dout_peri_spi1
- const: dout_peri_uart0
- const: dout_peri_uart1
- const: dout_peri_uart2
- const: dout_peri_usi0
- const: dout_peri_usi1
- const: dout_peri_usi2
required:
- compatible
- "#clock-cells"
- clocks
- clock-names
- reg
additionalProperties: false
examples:
# Clock controller node for CMU_PERI
- |
#include <dt-bindings/clock/exynos7885.h>
cmu_peri: clock-controller@10010000 {
compatible = "samsung,exynos7885-cmu-peri";
reg = <0x10010000 0x8000>;
#clock-cells = <1>;
clocks = <&oscclk>,
<&cmu_top CLK_DOUT_PERI_BUS>,
<&cmu_top CLK_DOUT_PERI_SPI0>,
<&cmu_top CLK_DOUT_PERI_SPI1>,
<&cmu_top CLK_DOUT_PERI_UART0>,
<&cmu_top CLK_DOUT_PERI_UART1>,
<&cmu_top CLK_DOUT_PERI_UART2>,
<&cmu_top CLK_DOUT_PERI_USI0>,
<&cmu_top CLK_DOUT_PERI_USI1>,
<&cmu_top CLK_DOUT_PERI_USI2>;
clock-names = "oscclk",
"dout_peri_bus",
"dout_peri_spi0",
"dout_peri_spi1",
"dout_peri_uart0",
"dout_peri_uart1",
"dout_peri_uart2",
"dout_peri_usi0",
"dout_peri_usi1",
"dout_peri_usi2";
};
...

38
Documentation/devicetree/bindings/clock/samsung,exynos850-clock.yaml
View file

@ -32,6 +32,8 @@ properties:
compatible:
enum:
- samsung,exynos850-cmu-top
- samsung,exynos850-cmu-apm
- samsung,exynos850-cmu-cmgp
- samsung,exynos850-cmu-core
- samsung,exynos850-cmu-dpu
- samsung,exynos850-cmu-hsi
@ -68,6 +70,42 @@ allOf:
items:
- const: oscclk
- if:
properties:
compatible:
contains:
const: samsung,exynos850-cmu-apm
then:
properties:
clocks:
items:
- description: External reference clock (26 MHz)
- description: CMU_APM bus clock (from CMU_TOP)
clock-names:
items:
- const: oscclk
- const: dout_clkcmu_apm_bus
- if:
properties:
compatible:
contains:
const: samsung,exynos850-cmu-cmgp
then:
properties:
clocks:
items:
- description: External reference clock (26 MHz)
- description: CMU_CMGP bus clock (from CMU_APM)
clock-names:
items:
- const: oscclk
- const: gout_clkcmu_cmgp_bus
- if:
properties:
compatible:

77
Documentation/devicetree/bindings/clock/samsung,s5pv210-clock.txt
View file

@ -1,77 +0,0 @@
* Samsung S5P6442/S5PC110/S5PV210 Clock Controller
Samsung S5P6442, S5PC110 and S5PV210 SoCs contain integrated clock
controller, which generates and supplies clock to various controllers
within the SoC.
Required Properties:
- compatible: should be one of following:
- "samsung,s5pv210-clock" : for clock controller of Samsung
S5PC110/S5PV210 SoCs,
- "samsung,s5p6442-clock" : for clock controller of Samsung
S5P6442 SoC.
- reg: physical base address of the controller and length of memory mapped
region.
- #clock-cells: should be 1.
All available clocks are defined as preprocessor macros in
dt-bindings/clock/s5pv210.h header and can be used in device tree sources.
External clocks:
There are several clocks that are generated outside the SoC. It is expected
that they are defined using standard clock bindings with following
clock-output-names:
- "xxti": external crystal oscillator connected to XXTI and XXTO pins of
the SoC,
- "xusbxti": external crystal oscillator connected to XUSBXTI and XUSBXTO
pins of the SoC,
A subset of above clocks available on given board shall be specified in
board device tree, including the system base clock, as selected by XOM[0]
pin of the SoC. Refer to generic fixed rate clock bindings
documentation[1] for more information how to specify these clocks.
[1] Documentation/devicetree/bindings/clock/fixed-clock.yaml
Example: Clock controller node:
clock: clock-controller@7e00f000 {
compatible = "samsung,s5pv210-clock";
reg = <0x7e00f000 0x1000>;
#clock-cells = <1>;
};
Example: Required external clocks:
xxti: clock-xxti {
compatible = "fixed-clock";
clock-output-names = "xxti";
clock-frequency = <24000000>;
#clock-cells = <0>;
};
xusbxti: clock-xusbxti {
compatible = "fixed-clock";
clock-output-names = "xusbxti";
clock-frequency = <24000000>;
#clock-cells = <0>;
};
Example: UART controller node that consumes the clock generated by the clock
controller (refer to the standard clock bindings for information about
"clocks" and "clock-names" properties):
uart0: serial@e2900000 {
compatible = "samsung,s5pv210-uart";
reg = <0xe2900000 0x400>;
interrupt-parent = <&vic1>;
interrupts = <10>;
clock-names = "uart", "clk_uart_baud0",
"clk_uart_baud1";
clocks = <&clocks UART0>, <&clocks UART0>,
<&clocks SCLK_UART0>;
};

79
Documentation/devicetree/bindings/clock/samsung,s5pv210-clock.yaml Normal file
View file

@ -0,0 +1,79 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/clock/samsung,s5pv210-clock.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Samsung S5P6442/S5PC110/S5PV210 SoC clock controller
maintainers:
- Chanwoo Choi <cw00.choi@samsung.com>
- Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com>
- Sylwester Nawrocki <s.nawrocki@samsung.com>
- Tomasz Figa <tomasz.figa@gmail.com>
description: |
Expected external clocks, defined in DTS as fixed-rate clocks with a matching
name::
- "xxti" - external crystal oscillator connected to XXTI and XXTO pins of
the SoC,
- "xusbxti" - external crystal oscillator connected to XUSBXTI and XUSBXTO
pins of the SoC,
All available clocks are defined as preprocessor macros in
include/dt-bindings/clock/s5pv210.h header.
properties:
compatible:
enum:
- samsung,s5pv210-clock
- samsung,s5p6442-clock
clocks:
items:
- description: xxti clock
- description: xusbxti clock
clock-names:
items:
- const: xxti
- const: xusbxti
"#clock-cells":
const: 1
reg:
maxItems: 1
required:
- compatible
- "#clock-cells"
- reg
additionalProperties: false
examples:
- |
#include <dt-bindings/clock/s5pv210.h>
xxti: clock-0 {
compatible = "fixed-clock";
clock-frequency = <0>;
clock-output-names = "xxti";
#clock-cells = <0>;
};
xusbxti: clock-1 {
compatible = "fixed-clock";
clock-frequency = <0>;
clock-output-names = "xusbxti";
#clock-cells = <0>;
};
clock-controller@e0100000 {
compatible = "samsung,s5pv210-clock";
reg = <0xe0100000 0x10000>;
clock-names = "xxti", "xusbxti";
clocks = <&xxti>, <&xusbxti>;
#clock-cells = <1>;
};

57
Documentation/devicetree/bindings/clock/toshiba,tmpv770x-pipllct.yaml Normal file
View file

@ -0,0 +1,57 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/clock/toshiba,tmpv770x-pipllct.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Toshiba Visconti5 TMPV770X PLL Controller Device Tree Bindings
maintainers:
- Nobuhiro Iwamatsu <nobuhiro1.iwamatsu@toshiba.co.jp>
description:
Toshia Visconti5 PLL controller which supports the PLLs on TMPV770X.
properties:
compatible:
const: toshiba,tmpv7708-pipllct
reg:
maxItems: 1
'#clock-cells':
const: 1
clocks:
description: External reference clock (OSC2)
maxItems: 1
required:
- compatible
- reg
- "#clock-cells"
- clocks
additionalProperties: false
examples:
- |
osc2_clk: osc2-clk {
compatible = "fixed-clock";
clock-frequency = <20000000>;
#clock-cells = <0>;
};
soc {
#address-cells = <2>;
#size-cells = <2>;
pipllct: clock-controller@24220000 {
compatible = "toshiba,tmpv7708-pipllct";
reg = <0 0x24220000 0 0x820>;
#clock-cells = <1>;
clocks = <&osc2_clk>;
};
};
...

52
Documentation/devicetree/bindings/clock/toshiba,tmpv770x-pismu.yaml Normal file
View file

@ -0,0 +1,52 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/clock/toshiba,tmpv770x-pismu.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Toshiba Visconti5 TMPV770x SMU controller Device Tree Bindings
maintainers:
- Nobuhiro Iwamatsu <nobuhiro1.iwamatsu@toshiba.co.jp>
description:
Toshia Visconti5 SMU (System Management Unit) which supports the clock
and resets on TMPV770x.
properties:
compatible:
items:
- const: toshiba,tmpv7708-pismu
- const: syscon
reg:
maxItems: 1
'#clock-cells':
const: 1
'#reset-cells':
const: 1
required:
- compatible
- reg
- "#clock-cells"
- "#reset-cells"
additionalProperties: false
examples:
- |
soc {
#address-cells = <2>;
#size-cells = <2>;
pismu: syscon@24200000 {
compatible = "toshiba,tmpv7708-pismu", "syscon";
reg = <0 0x24200000 0 0x2140>;
#clock-cells = <1>;
#reset-cells = <1>;
};
};
...

19
Documentation/devicetree/bindings/crypto/qcom,prng.txt
View file

@ -1,19 +0,0 @@
Qualcomm MSM pseudo random number generator.
Required properties:
- compatible : should be "qcom,prng" for 8916 etc
: should be "qcom,prng-ee" for 8996 and later using EE
(Execution Environment) slice of prng
- reg : specifies base physical address and size of the registers map
- clocks : phandle to clock-controller plus clock-specifier pair
- clock-names : "core" clocks all registers, FIFO and circuits in PRNG IP block
Example:
rng@f9bff000 {
compatible = "qcom,prng";
reg = <0xf9bff000 0x200>;
clocks = <&clock GCC_PRNG_AHB_CLK>;
clock-names = "core";
};

43
Documentation/devicetree/bindings/crypto/qcom,prng.yaml Normal file
View file

@ -0,0 +1,43 @@
# SPDX-License-Identifier: GPL-2.0-only
%YAML 1.2
---
$id: http://devicetree.org/schemas/crypto/qcom,prng.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Qualcomm Pseudo Random Number Generator
maintainers:
- Vinod Koul <vkoul@kernel.org>
properties:
compatible:
enum:
- qcom,prng # 8916 etc.
- qcom,prng-ee # 8996 and later using EE
reg:
maxItems: 1
clocks:
maxItems: 1
clock-names:
items:
- const: core
required:
- compatible
- reg
- clocks
- clock-names
additionalProperties: false
examples:
- |
rng@f9bff000 {
compatible = "qcom,prng";
reg = <0xf9bff000 0x200>;
clocks = <&clk 125>;
clock-names = "core";
};

5
Documentation/devicetree/bindings/display/amlogic,meson-dw-hdmi.yaml
View file

@ -10,6 +10,9 @@ title: Amlogic specific extensions to the Synopsys Designware HDMI Controller
maintainers:
- Neil Armstrong <narmstrong@baylibre.com>
allOf:
- $ref: /schemas/sound/name-prefix.yaml#
description: |
The Amlogic Meson Synopsys Designware Integration is composed of
- A Synopsys DesignWare HDMI Controller IP
@ -99,6 +102,8 @@ properties:
"#sound-dai-cells":
const: 0
sound-name-prefix: true
required:
- compatible
- reg

6
Documentation/devicetree/bindings/display/amlogic,meson-vpu.yaml
View file

@ -78,6 +78,10 @@ properties:
interrupts:
maxItems: 1
amlogic,canvas:
description: should point to a canvas provider node
$ref: /schemas/types.yaml#/definitions/phandle
power-domains:
maxItems: 1
description: phandle to the associated power domain
@ -106,6 +110,7 @@ required:
- port@1
- "#address-cells"
- "#size-cells"
- amlogic,canvas
additionalProperties: false
@ -118,6 +123,7 @@ examples:
interrupts = <3>;
#address-cells = <1>;
#size-cells = <0>;
amlogic,canvas = <&canvas>;
/* CVBS VDAC output port */
port@0 {

5
Documentation/devicetree/bindings/display/msm/dpu-sdm845.yaml
View file

@ -31,13 +31,11 @@ properties:
clocks:
items:
- description: Display AHB clock from gcc
- description: Display AXI clock
- description: Display core clock
clock-names:
items:
- const: iface
- const: bus
- const: core
interrupts:
@ -160,9 +158,8 @@ examples:
power-domains = <&dispcc MDSS_GDSC>;
clocks = <&gcc GCC_DISP_AHB_CLK>,
<&gcc GCC_DISP_AXI_CLK>,
<&dispcc DISP_CC_MDSS_MDP_CLK>;
clock-names = "iface", "bus", "core";
clock-names = "iface", "core";
interrupts = <GIC_SPI 83 IRQ_TYPE_LEVEL_HIGH>;
interrupt-controller;

2
Documentation/devicetree/bindings/display/panel/jdi,lt070me05000.yaml
View file

@ -35,6 +35,8 @@ properties:
phandle of the gpio for power ic line
Power IC supply enable, High active
port: true
required:
- compatible
- reg

4
Documentation/devicetree/bindings/display/panel/novatek,nt36672a.yaml
View file

@ -34,7 +34,7 @@ properties:
description: phandle of gpio for reset line - This should be 8mA, gpio
can be configured using mux, pinctrl, pinctrl-names (active high)
vddio-supply:
vddi0-supply:
description: phandle of the regulator that provides the supply voltage
Power IC supply
@ -75,8 +75,6 @@ examples:
reset-gpios = <&tlmm 6 GPIO_ACTIVE_HIGH>;
#address-cells = <1>;
#size-cells = <0>;
port {
tianma_nt36672a_in_0: endpoint {
remote-endpoint = <&dsi0_out>;

12
Documentation/devicetree/bindings/display/simple-framebuffer.yaml
View file

@ -83,13 +83,25 @@ properties:
format:
description: >
Format of the framebuffer:
* `a1r5g5b5` - 16-bit pixels, d[15]=a, d[14:10]=r, d[9:5]=g, d[4:0]=b
* `a2r10g10b10` - 32-bit pixels, d[31:30]=a, d[29:20]=r, d[19:10]=g, d[9:0]=b
* `a8b8g8r8` - 32-bit pixels, d[31:24]=a, d[23:16]=b, d[15:8]=g, d[7:0]=r
* `a8r8g8b8` - 32-bit pixels, d[31:24]=a, d[23:16]=r, d[15:8]=g, d[7:0]=b
* `r5g6b5` - 16-bit pixels, d[15:11]=r, d[10:5]=g, d[4:0]=b
* `r5g5b5a1` - 16-bit pixels, d[15:11]=r, d[10:6]=g, d[5:1]=b d[1:0]=a
* `r8g8b8` - 24-bit pixels, d[23:16]=r, d[15:8]=g, d[7:0]=b
* `x1r5g5b5` - 16-bit pixels, d[14:10]=r, d[9:5]=g, d[4:0]=b
* `x2r10g10b10` - 32-bit pixels, d[29:20]=r, d[19:10]=g, d[9:0]=b
* `x8r8g8b8` - 32-bit pixels, d[23:16]=r, d[15:8]=g, d[7:0]=b
enum:
- a1r5g5b5
- a2r10g10b10
- a8b8g8r8
- a8r8g8b8
- r5g6b5
- r5g5b5a1
- r8g8b8
- x1r5g5b5
- x2r10g10b10
- x8r8g8b8

3
Documentation/devicetree/bindings/display/st,stm32-dsi.yaml
View file

@ -110,7 +110,7 @@ examples:
};
};
panel-dsi@0 {
panel@0 {
compatible = "orisetech,otm8009a";
reg = <0>;
reset-gpios = <&gpioe 4 GPIO_ACTIVE_LOW>;
@ -125,4 +125,3 @@ examples:
};
...

83
Documentation/devicetree/bindings/dma/arm,pl330.yaml Normal file
View file

@ -0,0 +1,83 @@
# SPDX-License-Identifier: GPL-2.0
%YAML 1.2
---
$id: http://devicetree.org/schemas/dma/arm,pl330.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: ARM PrimeCell PL330 DMA Controller
maintainers:
- Vinod Koul <vkoul@kernel.org>
description:
The ARM PrimeCell PL330 DMA controller can move blocks of memory contents
between memory and peripherals or memory to memory.
# We need a select here so we don't match all nodes with 'arm,primecell'
select:
properties:
compatible:
contains:
const: arm,pl330
required:
- compatible
allOf:
- $ref: dma-controller.yaml#
- $ref: /schemas/arm/primecell.yaml#
properties:
compatible:
items:
- enum:
- arm,pl330
- const: arm,primecell
reg:
maxItems: 1
interrupts:
minItems: 1
maxItems: 32
description: A single combined interrupt or an interrupt per event
'#dma-cells':
const: 1
description: Contains the DMA request number for the consumer
arm,pl330-broken-no-flushp:
type: boolean
description: quirk for avoiding to execute DMAFLUSHP
arm,pl330-periph-burst:
type: boolean
description: quirk for performing burst transfer only
dma-coherent: true
resets:
minItems: 1
maxItems: 2
reset-names:
minItems: 1
items:
- const: dma
- const: dma-ocp
required:
- compatible
- reg
- interrupts
unevaluatedProperties: false
examples:
- |
dma-controller@12680000 {
compatible = "arm,pl330", "arm,primecell";
reg = <0x12680000 0x1000>;
interrupts = <99>;
#dma-cells = <1>;
};
...

4
Documentation/devicetree/bindings/dma/arm-pl08x.yaml
View file

@ -10,6 +10,7 @@ maintainers:
- Vinod Koul <vkoul@kernel.org>
allOf:
- $ref: /schemas/arm/primecell.yaml#
- $ref: "dma-controller.yaml#"
# We need a select here so we don't match all nodes with 'arm,primecell'
@ -89,6 +90,9 @@ properties:
- 64
description: bus width used for memcpy in bits. FTDMAC020 also accept 64 bits
resets:
maxItems: 1
required:
- reg
- interrupts

49
Documentation/devicetree/bindings/dma/arm-pl330.txt
View file

@ -1,49 +0,0 @@
* ARM PrimeCell PL330 DMA Controller
The ARM PrimeCell PL330 DMA controller can move blocks of memory contents
between memory and peripherals or memory to memory.
Required properties:
- compatible: should include both "arm,pl330" and "arm,primecell".
- reg: physical base address of the controller and length of memory mapped
region.
- interrupts: interrupt number to the cpu.
Optional properties:
- dma-coherent : Present if dma operations are coherent
- #dma-cells: must be <1>. used to represent the number of integer
cells in the dmas property of client device.
- dma-channels: contains the total number of DMA channels supported by the DMAC
- dma-requests: contains the total number of DMA requests supported by the DMAC
- arm,pl330-broken-no-flushp: quirk for avoiding to execute DMAFLUSHP
- arm,pl330-periph-burst: quirk for performing burst transfer only
- resets: contains an entry for each entry in reset-names.
See ../reset/reset.txt for details.
- reset-names: must contain at least "dma", and optional is "dma-ocp".
Example:
pdma0: pdma@12680000 {
compatible = "arm,pl330", "arm,primecell";
reg = <0x12680000 0x1000>;
interrupts = <99>;
#dma-cells = <1>;
#dma-channels = <8>;
#dma-requests = <32>;
};
Client drivers (device nodes requiring dma transfers from dev-to-mem or
mem-to-dev) should specify the DMA channel numbers and dma channel names
as shown below.
[property name] = <[phandle of the dma controller] [dma request id]>;
[property name] = <[dma channel name]>
where 'dma request id' is the dma request number which is connected
to the client controller. The 'property name' 'dmas' and 'dma-names'
as required by the generic dma device tree binding helpers. The dma
names correspond 1:1 with the dma request ids in the dmas property.
Example: dmas = <&pdma0 12
&pdma1 11>;
dma-names = "tx", "rx";

8
Documentation/devicetree/bindings/dma/dma-controller.yaml
View file

@ -24,10 +24,10 @@ examples:
dma: dma-controller@48000000 {
compatible = "ti,omap-sdma";
reg = <0x48000000 0x1000>;
interrupts = <0 12 0x4
0 13 0x4
0 14 0x4
0 15 0x4>;
interrupts = <0 12 0x4>,
<0 13 0x4>,
<0 14 0x4>,
<0 15 0x4>;
#dma-cells = <1>;
dma-channels = <32>;
dma-requests = <127>;

40
Documentation/devicetree/bindings/dma/ingenic,dma.yaml
View file

@ -14,15 +14,23 @@ allOf:
properties:
compatible:
enum:
- ingenic,jz4740-dma
- ingenic,jz4725b-dma
- ingenic,jz4760-dma
- ingenic,jz4760b-dma
- ingenic,jz4770-dma
- ingenic,jz4780-dma
- ingenic,x1000-dma
- ingenic,x1830-dma
oneOf:
- enum:
- ingenic,jz4740-dma
- ingenic,jz4725b-dma
- ingenic,jz4760-dma
- ingenic,jz4760-bdma
- ingenic,jz4760-mdma
- ingenic,jz4760b-dma
- ingenic,jz4760b-bdma
- ingenic,jz4760b-mdma
- ingenic,jz4770-dma
- ingenic,jz4780-dma
- ingenic,x1000-dma
- ingenic,x1830-dma
- items:
- const: ingenic,jz4770-bdma
- const: ingenic,jz4760b-bdma
reg:
items:
@ -36,13 +44,19 @@ properties:
maxItems: 1
"#dma-cells":
const: 2
enum: [2, 3]
description: >
DMA clients must use the format described in dma.txt, giving a phandle
to the DMA controller plus the following 2 integer cells:
to the DMA controller plus the following integer cells:
- Request type: The DMA request type for transfers to/from the
device on the allocated channel, as defined in the SoC documentation.
- Request type: The DMA request type specifies the device endpoint that
will be the source or destination of the DMA transfer.
If "#dma-cells" is 2, the request type is a single cell, and the
direction will be unidirectional (either RX or TX but not both).
If "#dma-cells" is 3, the request type has two cells; the first
one corresponds to the host to device direction (TX), the second one
corresponds to the device to host direction (RX). The DMA channel is
then bidirectional.
- Channel: If set to 0xffffffff, any available channel will be allocated
for the client. Otherwise, the exact channel specified will be used.

5
Documentation/devicetree/bindings/dma/renesas,rcar-dmac.yaml
View file

@ -44,6 +44,10 @@ properties:
- items:
- const: renesas,dmac-r8a779a0 # R-Car V3U
- items:
- const: renesas,dmac-r8a779f0 # R-Car S4-8
- const: renesas,rcar-gen4-dmac
reg: true
interrupts:
@ -118,6 +122,7 @@ if:
contains:
enum:
- renesas,dmac-r8a779a0
- renesas,rcar-gen4-dmac
then:
properties:
reg:

2
Documentation/devicetree/bindings/dma/sifive,fu540-c000-pdma.yaml
View file

@ -50,7 +50,7 @@ examples:
dma@3000000 {
compatible = "sifive,fu540-c000-pdma";
reg = <0x3000000 0x8000>;
interrupts = <23 24 25 26 27 28 29 30>;
interrupts = <23>, <24>, <25>, <26>, <27>, <28>, <29>, <30>;
#dma-cells = <1>;
};

3
Documentation/devicetree/bindings/dma/snps,dw-axi-dmac.yaml
View file

@ -53,6 +53,9 @@ properties:
minimum: 1
maximum: 8
resets:
maxItems: 1
snps,dma-masters:
description: |
Number of AXI masters supported by the hardware.

1
Documentation/devicetree/bindings/dma/ti/k3-bcdma.yaml
View file

@ -30,6 +30,7 @@ description: |
allOf:
- $ref: /schemas/dma/dma-controller.yaml#
- $ref: /schemas/arm/keystone/ti,k3-sci-common.yaml#
properties:
compatible:

1
Documentation/devicetree/bindings/dma/ti/k3-pktdma.yaml
View file

@ -25,6 +25,7 @@ description: |
allOf:
- $ref: /schemas/dma/dma-controller.yaml#
- $ref: /schemas/arm/keystone/ti,k3-sci-common.yaml#
properties:
compatible:

29
Documentation/devicetree/bindings/eeprom/at24.yaml
View file

@ -86,6 +86,10 @@ properties:
pattern: c1024$
- items:
pattern: cs1024$
- items:
pattern: c1025$
- items:
pattern: cs1025$
- items:
pattern: c2048$
- items:
@ -95,17 +99,20 @@ properties:
# These are special cases that don't conform to the above pattern.
# Each requires a standard at24 model as fallback.
- items:
- const: nxp,se97b
- enum:
- rohm,br24g01
- rohm,br24t01
- const: atmel,24c01
- items:
- enum:
- nxp,se97b
- renesas,r1ex24002
- const: atmel,24c02
- items:
- const: onnn,cat24c04
- enum:
- onnn,cat24c04
- onnn,cat24c05
- const: atmel,24c04
- items:
- const: onnn,cat24c05
- const: atmel,24c04
- items:
- const: renesas,r1ex24002
- const: atmel,24c02
- items:
- const: renesas,r1ex24016
- const: atmel,24c16
@ -115,12 +122,6 @@ properties:
- items:
- const: renesas,r1ex24128
- const: atmel,24c128
- items:
- const: rohm,br24g01
- const: atmel,24c01
- items:
- const: rohm,br24t01
- const: atmel,24c01
label:
description: Descriptive name of the EEPROM.

83
Documentation/devicetree/bindings/gpio/brcm,brcmstb-gpio.txt
View file

@ -1,83 +0,0 @@
Broadcom STB "UPG GIO" GPIO controller
The controller's registers are organized as sets of eight 32-bit
registers with each set controlling a bank of up to 32 pins. A single
interrupt is shared for all of the banks handled by the controller.
Required properties:
- compatible:
Must be "brcm,brcmstb-gpio"
- reg:
Define the base and range of the I/O address space containing
the brcmstb GPIO controller registers
- #gpio-cells:
Should be <2>. The first cell is the pin number (within the controller's
pin space), and the second is used for the following:
bit[0]: polarity (0 for active-high, 1 for active-low)
- gpio-controller:
Specifies that the node is a GPIO controller.
- brcm,gpio-bank-widths:
Number of GPIO lines for each bank. Number of elements must
correspond to number of banks suggested by the 'reg' property.
Optional properties:
- interrupts:
The interrupt shared by all GPIO lines for this controller.
- interrupts-extended:
Alternate form of specifying interrupts and parents that allows for
multiple parents. This takes precedence over 'interrupts' and
'interrupt-parent'. Wakeup-capable GPIO controllers often route their
wakeup interrupt lines through a different interrupt controller than the
primary interrupt line, making this property necessary.
- #interrupt-cells:
Should be <2>. The first cell is the GPIO number, the second should specify
flags. The following subset of flags is supported:
- bits[3:0] trigger type and level flags
1 = low-to-high edge triggered
2 = high-to-low edge triggered
4 = active high level-sensitive
8 = active low level-sensitive
Valid combinations are 1, 2, 3, 4, 8.
See also Documentation/devicetree/bindings/interrupt-controller/interrupts.txt
- interrupt-controller:
Marks the device node as an interrupt controller
- wakeup-source:
GPIOs for this controller can be used as a wakeup source
Example:
upg_gio: gpio@f040a700 {
#gpio-cells = <2>;
#interrupt-cells = <2>;
compatible = "brcm,bcm7445-gpio", "brcm,brcmstb-gpio";
gpio-controller;
interrupt-controller;
reg = <0xf040a700 0x80>;
interrupt-parent = <&irq0_intc>;
interrupts = <0x6>;
brcm,gpio-bank-widths = <32 32 32 24>;
};
upg_gio_aon: gpio@f04172c0 {
#gpio-cells = <2>;
#interrupt-cells = <2>;
compatible = "brcm,bcm7445-gpio", "brcm,brcmstb-gpio";
gpio-controller;
interrupt-controller;
reg = <0xf04172c0 0x40>;
interrupt-parent = <&irq0_aon_intc>;
interrupts = <0x6>;
interrupts-extended = <&irq0_aon_intc 0x6>,
<&aon_pm_l2_intc 0x5>;
wakeup-source;
brcm,gpio-bank-widths = <18 4>;
};

104
Documentation/devicetree/bindings/gpio/brcm,brcmstb-gpio.yaml Normal file
View file

@ -0,0 +1,104 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/gpio/brcm,brcmstb-gpio.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Broadcom STB "UPG GIO" GPIO controller
description: >
The controller's registers are organized as sets of eight 32-bit
registers with each set controlling a bank of up to 32 pins. A single
interrupt is shared for all of the banks handled by the controller.
maintainers:
- Doug Berger <opendmb@gmail.com>
- Florian Fainelli <f.fainelli@gmail.com>
properties:
compatible:
items:
- enum:
- brcm,bcm7445-gpio
- const: brcm,brcmstb-gpio
reg:
maxItems: 1
description: >
Define the base and range of the I/O address space containing
the brcmstb GPIO controller registers
"#gpio-cells":
const: 2
description: >
The first cell is the pin number (within the controller's
pin space), and the second is used for the following:
bit[0]: polarity (0 for active-high, 1 for active-low)
gpio-controller: true
brcm,gpio-bank-widths:
$ref: /schemas/types.yaml#/definitions/uint32-array
description: >
Number of GPIO lines for each bank. Number of elements must
correspond to number of banks suggested by the 'reg' property.
interrupts:
maxItems: 1
description: >
The interrupt shared by all GPIO lines for this controller.
"#interrupt-cells":
const: 2
description: |
The first cell is the GPIO number, the second should specify
flags. The following subset of flags is supported:
- bits[3:0] trigger type and level flags
1 = low-to-high edge triggered
2 = high-to-low edge triggered
4 = active high level-sensitive
8 = active low level-sensitive
Valid combinations are 1, 2, 3, 4, 8.
interrupt-controller: true
wakeup-source:
type: boolean
description: >
GPIOs for this controller can be used as a wakeup source
required:
- compatible
- reg
- gpio-controller
- "#gpio-cells"
- "brcm,gpio-bank-widths"
additionalProperties: false
examples:
- |
upg_gio: gpio@f040a700 {
#gpio-cells = <2>;
#interrupt-cells = <2>;
compatible = "brcm,bcm7445-gpio", "brcm,brcmstb-gpio";
gpio-controller;
interrupt-controller;
reg = <0xf040a700 0x80>;
interrupt-parent = <&irq0_intc>;
interrupts = <0x6>;
brcm,gpio-bank-widths = <32 32 32 24>;
};
upg_gio_aon: gpio@f04172c0 {
#gpio-cells = <2>;
#interrupt-cells = <2>;
compatible = "brcm,bcm7445-gpio", "brcm,brcmstb-gpio";
gpio-controller;
interrupt-controller;
reg = <0xf04172c0 0x40>;
interrupt-parent = <&irq0_aon_intc>;
interrupts = <0x6>;
wakeup-source;
brcm,gpio-bank-widths = <18 4>;
};

41
Documentation/devicetree/bindings/gpio/gpio-samsung.txt
View file

@ -1,41 +0,0 @@
Samsung Exynos4 GPIO Controller
Required properties:
- compatible: Compatible property value should be "samsung,exynos4-gpio>".
- reg: Physical base address of the controller and length of memory mapped
region.
- #gpio-cells: Should be 4. The syntax of the gpio specifier used by client nodes
should be the following with values derived from the SoC user manual.
<[phandle of the gpio controller node]
[pin number within the gpio controller]
[mux function]
[flags and pull up/down]
[drive strength]>
Values for gpio specifier:
- Pin number: is a value between 0 to 7.
- Flags and Pull Up/Down: 0 - Pull Up/Down Disabled.
1 - Pull Down Enabled.
3 - Pull Up Enabled.
Bit 16 (0x00010000) - Input is active low.
- Drive Strength: 0 - 1x,
1 - 3x,
2 - 2x,
3 - 4x
- gpio-controller: Specifies that the node is a gpio controller.
- #address-cells: should be 1.
- #size-cells: should be 1.
Example:
gpa0: gpio-controller@11400000 {
#address-cells = <1>;
#size-cells = <1>;
compatible = "samsung,exynos4-gpio";
reg = <0x11400000 0x20>;
#gpio-cells = <4>;
gpio-controller;
};

3
Documentation/devicetree/bindings/gpio/gpio-vf610.yaml
View file

@ -24,6 +24,9 @@ properties:
- items:
- const: fsl,imx7ulp-gpio
- const: fsl,vf610-gpio
- items:
- const: fsl,imx8ulp-gpio
- const: fsl,imx7ulp-gpio
reg:
description: The first reg tuple represents the PORT module, the second tuple

4
Documentation/devicetree/bindings/gpio/mstar,msc313-gpio.yaml
View file

@ -14,7 +14,9 @@ properties:
pattern: "^gpio@[0-9a-f]+$"
compatible:
const: mstar,msc313-gpio
enum:
- mstar,msc313-gpio
- sstar,ssd20xd-gpio
reg:
maxItems: 1

165
Documentation/devicetree/bindings/gpio/nvidia,tegra186-gpio.txt
View file

@ -1,165 +0,0 @@
NVIDIA Tegra186 GPIO controllers
Tegra186 contains two GPIO controllers; a main controller and an "AON"
controller. This binding document applies to both controllers. The register
layouts for the controllers share many similarities, but also some significant
differences. Hence, this document describes closely related but different
bindings and compatible values.
The Tegra186 GPIO controller allows software to set the IO direction of, and
read/write the value of, numerous GPIO signals. Routing of GPIO signals to
package balls is under the control of a separate pin controller HW block. Two
major sets of registers exist:
a) Security registers, which allow configuration of allowed access to the GPIO
register set. These registers exist in a single contiguous block of physical
address space. The size of this block, and the security features available,
varies between the different GPIO controllers.
Access to this set of registers is not necessary in all circumstances. Code
that wishes to configure access to the GPIO registers needs access to these
registers to do so. Code which simply wishes to read or write GPIO data does not
need access to these registers.
b) GPIO registers, which allow manipulation of the GPIO signals. In some GPIO
controllers, these registers are exposed via multiple "physical aliases" in
address space, each of which access the same underlying state. See the hardware
documentation for rationale. Any particular GPIO client is expected to access
just one of these physical aliases.
Tegra HW documentation describes a unified naming convention for all GPIOs
implemented by the SoC. Each GPIO is assigned to a port, and a port may control
a number of GPIOs. Thus, each GPIO is named according to an alphabetical port
name and an integer GPIO name within the port. For example, GPIO_PA0, GPIO_PN6,
or GPIO_PCC3.
The number of ports implemented by each GPIO controller varies. The number of
implemented GPIOs within each port varies. GPIO registers within a controller
are grouped and laid out according to the port they affect.
The mapping from port name to the GPIO controller that implements that port, and
the mapping from port name to register offset within a controller, are both
extremely non-linear. The header file <dt-bindings/gpio/tegra186-gpio.h>
describes the port-level mapping. In that file, the naming convention for ports
matches the HW documentation. The values chosen for the names are alphabetically
sorted within a particular controller. Drivers need to map between the DT GPIO
IDs and HW register offsets using a lookup table.
Each GPIO controller can generate a number of interrupt signals. Each signal
represents the aggregate status for all GPIOs within a set of ports. Thus, the
number of interrupt signals generated by a controller varies as a rough function
of the number of ports it implements. Note that the HW documentation refers to
both the overall controller HW module and the sets-of-ports as "controllers".
Each GPIO controller in fact generates multiple interrupts signals for each set
of ports. Each GPIO may be configured to feed into a specific one of the
interrupt signals generated by a set-of-ports. The intent is for each generated
signal to be routed to a different CPU, thus allowing different CPUs to each
handle subsets of the interrupts within a port. The status of each of these
per-port-set signals is reported via a separate register. Thus, a driver needs
to know which status register to observe. This binding currently defines no
configuration mechanism for this. By default, drivers should use register
GPIO_${port}_INTERRUPT_STATUS_G1_0. Future revisions to the binding could
define a property to configure this.
Required properties:
- compatible
Array of strings.
One of:
- "nvidia,tegra186-gpio".
- "nvidia,tegra186-gpio-aon".
- "nvidia,tegra194-gpio".
- "nvidia,tegra194-gpio-aon".
- reg-names
Array of strings.
Contains a list of names for the register spaces described by the reg
property. May contain the following entries, in any order:
- "gpio": Mandatory. GPIO control registers. This may cover either:
a) The single physical alias that this OS should use.
b) All physical aliases that exist in the controller. This is
appropriate when the OS is responsible for managing assignment of
the physical aliases.
- "security": Optional. Security configuration registers.
Users of this binding MUST look up entries in the reg property by name,
using this reg-names property to do so.
- reg
Array of (physical base address, length) tuples.
Must contain one entry per entry in the reg-names property, in a matching
order.
- interrupts
Array of interrupt specifiers.
The interrupt outputs from the HW block, one per set of ports, in the
order the HW manual describes them. The number of entries required varies
depending on compatible value:
- "nvidia,tegra186-gpio": 6 entries.
- "nvidia,tegra186-gpio-aon": 1 entry.
- "nvidia,tegra194-gpio": 6 entries.
- "nvidia,tegra194-gpio-aon": 1 entry.
- gpio-controller
Boolean.
Marks the device node as a GPIO controller/provider.
- #gpio-cells
Single-cell integer.
Must be <2>.
Indicates how many cells are used in a consumer's GPIO specifier.
In the specifier:
- The first cell is the pin number.
See <dt-bindings/gpio/tegra186-gpio.h>.
- The second cell contains flags:
- Bit 0 specifies polarity
- 0: Active-high (normal).
- 1: Active-low (inverted).
- interrupt-controller
Boolean.
Marks the device node as an interrupt controller/provider.
- #interrupt-cells
Single-cell integer.
Must be <2>.
Indicates how many cells are used in a consumer's interrupt specifier.
In the specifier:
- The first cell is the GPIO number.
See <dt-bindings/gpio/tegra186-gpio.h>.
- The second cell is contains flags:
- Bits [3:0] indicate trigger type and level:
- 1: Low-to-high edge triggered.
- 2: High-to-low edge triggered.
- 4: Active high level-sensitive.
- 8: Active low level-sensitive.
Valid combinations are 1, 2, 3, 4, 8.
Example:
#include <dt-bindings/interrupt-controller/irq.h>
gpio@2200000 {
compatible = "nvidia,tegra186-gpio";
reg-names = "security", "gpio";
reg =
<0x0 0x2200000 0x0 0x10000>,
<0x0 0x2210000 0x0 0x10000>;
interrupts =
<0 47 IRQ_TYPE_LEVEL_HIGH>,
<0 50 IRQ_TYPE_LEVEL_HIGH>,
<0 53 IRQ_TYPE_LEVEL_HIGH>,
<0 56 IRQ_TYPE_LEVEL_HIGH>,
<0 59 IRQ_TYPE_LEVEL_HIGH>,
<0 180 IRQ_TYPE_LEVEL_HIGH>;
gpio-controller;
#gpio-cells = <2>;
interrupt-controller;
#interrupt-cells = <2>;
};
gpio@c2f0000 {
compatible = "nvidia,tegra186-gpio-aon";
reg-names = "security", "gpio";
reg =
<0x0 0xc2f0000 0x0 0x1000>,
<0x0 0xc2f1000 0x0 0x1000>;
interrupts =
<0 60 IRQ_TYPE_LEVEL_HIGH>;
gpio-controller;
#gpio-cells = <2>;
interrupt-controller;
#interrupt-cells = <2>;
};

214
Documentation/devicetree/bindings/gpio/nvidia,tegra186-gpio.yaml Normal file
View file

@ -0,0 +1,214 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/gpio/nvidia,tegra186-gpio.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: NVIDIA Tegra GPIO Controller (Tegra186 and later)
maintainers:
- Thierry Reding <thierry.reding@gmail.com>
- Jon Hunter <jonathanh@nvidia.com>
description: |
Tegra186 contains two GPIO controllers; a main controller and an "AON"
controller. This binding document applies to both controllers. The register
layouts for the controllers share many similarities, but also some
significant differences. Hence, this document describes closely related but
different bindings and compatible values.
The Tegra186 GPIO controller allows software to set the IO direction of,
and read/write the value of, numerous GPIO signals. Routing of GPIO signals
to package balls is under the control of a separate pin controller hardware
block. Two major sets of registers exist:
a) Security registers, which allow configuration of allowed access to the
GPIO register set. These registers exist in a single contiguous block
of physical address space. The size of this block, and the security
features available, varies between the different GPIO controllers.
Access to this set of registers is not necessary in all circumstances.
Code that wishes to configure access to the GPIO registers needs access
to these registers to do so. Code which simply wishes to read or write
GPIO data does not need access to these registers.
b) GPIO registers, which allow manipulation of the GPIO signals. In some
GPIO controllers, these registers are exposed via multiple "physical
aliases" in address space, each of which access the same underlying
state. See the hardware documentation for rationale. Any particular
GPIO client is expected to access just one of these physical aliases.
Tegra HW documentation describes a unified naming convention for all GPIOs
implemented by the SoC. Each GPIO is assigned to a port, and a port may
control a number of GPIOs. Thus, each GPIO is named according to an
alphabetical port name and an integer GPIO name within the port. For
example, GPIO_PA0, GPIO_PN6, or GPIO_PCC3.
The number of ports implemented by each GPIO controller varies. The number
of implemented GPIOs within each port varies. GPIO registers within a
controller are grouped and laid out according to the port they affect.
The mapping from port name to the GPIO controller that implements that
port, and the mapping from port name to register offset within a
controller, are both extremely non-linear. The header file
<dt-bindings/gpio/tegra186-gpio.h> describes the port-level mapping. In
that file, the naming convention for ports matches the HW documentation.
The values chosen for the names are alphabetically sorted within a
particular controller. Drivers need to map between the DT GPIO IDs and HW
register offsets using a lookup table.
Each GPIO controller can generate a number of interrupt signals. Each
signal represents the aggregate status for all GPIOs within a set of
ports. Thus, the number of interrupt signals generated by a controller
varies as a rough function of the number of ports it implements. Note
that the HW documentation refers to both the overall controller HW
module and the sets-of-ports as "controllers".
Each GPIO controller in fact generates multiple interrupts signals for
each set of ports. Each GPIO may be configured to feed into a specific
one of the interrupt signals generated by a set-of-ports. The intent is
for each generated signal to be routed to a different CPU, thus allowing
different CPUs to each handle subsets of the interrupts within a port.
The status of each of these per-port-set signals is reported via a
separate register. Thus, a driver needs to know which status register to
observe. This binding currently defines no configuration mechanism for
this. By default, drivers should use register
GPIO_${port}_INTERRUPT_STATUS_G1_0. Future revisions to the binding could
define a property to configure this.
properties:
compatible:
enum:
- nvidia,tegra186-gpio
- nvidia,tegra186-gpio-aon
- nvidia,tegra194-gpio
- nvidia,tegra194-gpio-aon
- nvidia,tegra234-gpio
- nvidia,tegra234-gpio-aon
reg-names:
items:
- const: security
- const: gpio
minItems: 1
reg:
items:
- description: Security configuration registers.
- description: |
GPIO control registers. This may cover either:
a) The single physical alias that this OS should use.
b) All physical aliases that exist in the controller. This is
appropriate when the OS is responsible for managing assignment
of the physical aliases.
minItems: 1
interrupts:
description: The interrupt outputs from the HW block, one per set of
ports, in the order the HW manual describes them. The number of entries
required varies depending on compatible value.
gpio-controller: true
"#gpio-cells":
description: |
Indicates how many cells are used in a consumer's GPIO specifier. In the
specifier:
- The first cell is the pin number.
See <dt-bindings/gpio/tegra186-gpio.h>.
- The second cell contains flags:
- Bit 0 specifies polarity
- 0: Active-high (normal).
- 1: Active-low (inverted).
const: 2
interrupt-controller: true
"#interrupt-cells":
description: |
Indicates how many cells are used in a consumer's interrupt specifier.
In the specifier:
- The first cell is the GPIO number.
See <dt-bindings/gpio/tegra186-gpio.h>.
- The second cell is contains flags:
- Bits [3:0] indicate trigger type and level:
- 1: Low-to-high edge triggered.
- 2: High-to-low edge triggered.
- 4: Active high level-sensitive.
- 8: Active low level-sensitive.
Valid combinations are 1, 2, 3, 4, 8.
const: 2
allOf:
- if:
properties:
compatible:
contains:
enum:
- nvidia,tegra186-gpio
- nvidia,tegra194-gpio
- nvidia,tegra234-gpio
then:
properties:
interrupts:
minItems: 6
maxItems: 48
- if:
properties:
compatible:
contains:
enum:
- nvidia,tegra186-gpio-aon
- nvidia,tegra194-gpio-aon
- nvidia,tegra234-gpio-aon
then:
properties:
interrupts:
minItems: 1
maxItems: 4
required:
- compatible
- reg
- reg-names
- interrupts
additionalProperties: false
examples:
- |
#include <dt-bindings/interrupt-controller/irq.h>
gpio@2200000 {
compatible = "nvidia,tegra186-gpio";
reg-names = "security", "gpio";
reg = <0x2200000 0x10000>,
<0x2210000 0x10000>;
interrupts = <0 47 IRQ_TYPE_LEVEL_HIGH>,
<0 50 IRQ_TYPE_LEVEL_HIGH>,
<0 53 IRQ_TYPE_LEVEL_HIGH>,
<0 56 IRQ_TYPE_LEVEL_HIGH>,
<0 59 IRQ_TYPE_LEVEL_HIGH>,
<0 180 IRQ_TYPE_LEVEL_HIGH>;
gpio-controller;
#gpio-cells = <2>;
interrupt-controller;
#interrupt-cells = <2>;
};
gpio@c2f0000 {
compatible = "nvidia,tegra186-gpio-aon";
reg-names = "security", "gpio";
reg = <0xc2f0000 0x1000>,
<0xc2f1000 0x1000>;
interrupts = <0 60 IRQ_TYPE_LEVEL_HIGH>;
gpio-controller;
#gpio-cells = <2>;
interrupt-controller;
#interrupt-cells = <2>;
};

40
Documentation/devicetree/bindings/gpio/nvidia,tegra20-gpio.txt
View file

@ -1,40 +0,0 @@
NVIDIA Tegra GPIO controller
Required properties:
- compatible : "nvidia,tegra<chip>-gpio"
- reg : Physical base address and length of the controller's registers.
- interrupts : The interrupt outputs from the controller. For Tegra20,
there should be 7 interrupts specified, and for Tegra30, there should
be 8 interrupts specified.
- #gpio-cells : Should be two. The first cell is the pin number and the
second cell is used to specify optional parameters:
- bit 0 specifies polarity (0 for normal, 1 for inverted)
- gpio-controller : Marks the device node as a GPIO controller.
- #interrupt-cells : Should be 2.
The first cell is the GPIO number.
The second cell is used to specify flags:
bits[3:0] trigger type and level flags:
1 = low-to-high edge triggered.
2 = high-to-low edge triggered.
4 = active high level-sensitive.
8 = active low level-sensitive.
Valid combinations are 1, 2, 3, 4, 8.
- interrupt-controller : Marks the device node as an interrupt controller.
Example:
gpio: gpio@6000d000 {
compatible = "nvidia,tegra20-gpio";
reg = < 0x6000d000 0x1000 >;
interrupts = < 0 32 0x04
0 33 0x04
0 34 0x04
0 35 0x04
0 55 0x04
0 87 0x04
0 89 0x04 >;
#gpio-cells = <2>;
gpio-controller;
#interrupt-cells = <2>;
interrupt-controller;
};

110
Documentation/devicetree/bindings/gpio/nvidia,tegra20-gpio.yaml Normal file
View file

@ -0,0 +1,110 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/gpio/nvidia,tegra20-gpio.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: NVIDIA Tegra GPIO Controller (Tegra20 - Tegra210)
maintainers:
- Thierry Reding <thierry.reding@gmail.com>
- Jon Hunter <jonathanh@nvidia.com>
properties:
compatible:
oneOf:
- enum:
- nvidia,tegra20-gpio
- nvidia,tegra30-gpio
- items:
- enum:
- nvidia,tegra114-gpio
- nvidia,tegra124-gpio
- nvidia,tegra210-gpio
- const: nvidia,tegra30-gpio
reg:
maxItems: 1
interrupts:
description: The interrupt outputs from the controller. For Tegra20,
there should be 7 interrupts specified, and for Tegra30, there should
be 8 interrupts specified.
"#gpio-cells":
description: The first cell is the pin number and the second cell is used
to specify the GPIO polarity (0 = active high, 1 = active low).
const: 2
gpio-controller: true
gpio-ranges:
maxItems: 1
"#interrupt-cells":
description: |
Should be 2. The first cell is the GPIO number. The second cell is
used to specify flags:
bits[3:0] trigger type and level flags:
1 = low-to-high edge triggered.
2 = high-to-low edge triggered.
4 = active high level-sensitive.
8 = active low level-sensitive.
Valid combinations are 1, 2, 3, 4, 8.
const: 2
interrupt-controller: true
allOf:
- if:
properties:
compatible:
contains:
const: nvidia,tegra30-gpio
then:
properties:
interrupts:
minItems: 8
maxItems: 8
else:
properties:
interrupts:
minItems: 7
maxItems: 7
required:
- compatible
- reg
- interrupts
- "#gpio-cells"
- gpio-controller
- "#interrupt-cells"
- interrupt-controller
additionalProperties:
type: object
required:
- gpio-hog
examples:
- |
#include <dt-bindings/interrupt-controller/arm-gic.h>
gpio: gpio@6000d000 {
compatible = "nvidia,tegra20-gpio";
reg = <0x6000d000 0x1000>;
interrupts = <GIC_SPI 32 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 33 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 34 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 35 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 55 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 87 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 89 IRQ_TYPE_LEVEL_HIGH>;
#gpio-cells = <2>;
gpio-controller;
#interrupt-cells = <2>;
interrupt-controller;
};

3
Documentation/devicetree/bindings/gpio/sifive,gpio.yaml
View file

@ -77,7 +77,8 @@ examples:
gpio@10060000 {
compatible = "sifive,fu540-c000-gpio", "sifive,gpio0";
interrupt-parent = <&plic>;
interrupts = <7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22>;
interrupts = <7>, <8>, <9>, <10>, <11>, <12>, <13>, <14>, <15>, <16>,
<17>, <18>, <19>, <20>, <21>, <22>;
reg = <0x10060000 0x1000>;
clocks = <&tlclk PRCI_CLK_TLCLK>;
gpio-controller;

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