diff options
Diffstat (limited to 'Documentation')
894 files changed, 33575 insertions, 13988 deletions
diff --git a/Documentation/ABI/obsolete/sysfs-class-dax b/Documentation/ABI/obsolete/sysfs-class-dax deleted file mode 100644 index 5bcce27458e3..000000000000 --- a/Documentation/ABI/obsolete/sysfs-class-dax +++ /dev/null @@ -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/ diff --git a/Documentation/ABI/stable/sysfs-block b/Documentation/ABI/stable/sysfs-block new file mode 100644 index 000000000000..8dd3e84a8aad --- /dev/null +++ b/Documentation/ABI/stable/sysfs-block @@ -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 diff --git a/Documentation/ABI/stable/sysfs-devices-node b/Documentation/ABI/stable/sysfs-devices-node index 484fc04bcc25..8db67aa472f1 100644 --- a/Documentation/ABI/stable/sysfs-devices-node +++ b/Documentation/ABI/stable/sysfs-devices-node @@ -176,3 +176,9 @@ Contact: Keith Busch <keith.busch@intel.com> Description: The cache write policy: 0 for write-back, 1 for write-through, other or unknown. + +What: /sys/devices/system/node/nodeX/x86/sgx_total_bytes +Date: November 2021 +Contact: Jarkko Sakkinen <jarkko@kernel.org> +Description: + The total amount of SGX physical memory in bytes. diff --git a/Documentation/ABI/stable/sysfs-driver-dma-idxd b/Documentation/ABI/stable/sysfs-driver-dma-idxd index df4afbccf037..0c2b613f2373 100644 --- a/Documentation/ABI/stable/sysfs-driver-dma-idxd +++ b/Documentation/ABI/stable/sysfs-driver-dma-idxd @@ -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. diff --git a/Documentation/ABI/testing/configfs-usb-gadget-uac1 b/Documentation/ABI/testing/configfs-usb-gadget-uac1 index b576b3d6ea6d..d4b8cf40a9e4 100644 --- a/Documentation/ABI/testing/configfs-usb-gadget-uac1 +++ b/Documentation/ABI/testing/configfs-usb-gadget-uac1 @@ -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 ===================== ======================================= diff --git a/Documentation/ABI/testing/configfs-usb-gadget-uac2 b/Documentation/ABI/testing/configfs-usb-gadget-uac2 index 244d96650123..7fb3dbe26857 100644 --- a/Documentation/ABI/testing/configfs-usb-gadget-uac2 +++ b/Documentation/ABI/testing/configfs-usb-gadget-uac2 @@ -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 ===================== ======================================= diff --git a/Documentation/ABI/testing/debugfs-driver-habanalabs b/Documentation/ABI/testing/debugfs-driver-habanalabs index 63c46d9d538f..2667cbf940f3 100644 --- a/Documentation/ABI/testing/debugfs-driver-habanalabs +++ b/Documentation/ABI/testing/debugfs-driver-habanalabs @@ -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 diff --git a/Documentation/ABI/testing/sysfs-block b/Documentation/ABI/testing/sysfs-block deleted file mode 100644 index b16b0c45a272..000000000000 --- a/Documentation/ABI/testing/sysfs-block +++ /dev/null @@ -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. diff --git a/Documentation/ABI/testing/sysfs-bus-iio-filter-admv8818 b/Documentation/ABI/testing/sysfs-bus-iio-filter-admv8818 new file mode 100644 index 000000000000..f6c035752639 --- /dev/null +++ b/Documentation/ABI/testing/sysfs-bus-iio-filter-admv8818 @@ -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. diff --git a/Documentation/ABI/testing/sysfs-bus-iio-frequency-admv1013 b/Documentation/ABI/testing/sysfs-bus-iio-frequency-admv1013 new file mode 100644 index 000000000000..de1e323e5d47 --- /dev/null +++ b/Documentation/ABI/testing/sysfs-bus-iio-frequency-admv1013 @@ -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. diff --git a/Documentation/ABI/testing/sysfs-bus-usb b/Documentation/ABI/testing/sysfs-bus-usb index 2ebe5708b4bc..7efe31ed3a25 100644 --- a/Documentation/ABI/testing/sysfs-bus-usb +++ b/Documentation/ABI/testing/sysfs-bus-usb @@ -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> diff --git a/Documentation/ABI/testing/sysfs-bus-vdpa b/Documentation/ABI/testing/sysfs-bus-vdpa new file mode 100644 index 000000000000..28a6111202ba --- /dev/null +++ b/Documentation/ABI/testing/sysfs-bus-vdpa @@ -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. diff --git a/Documentation/ABI/testing/sysfs-class-firmware-attributes b/Documentation/ABI/testing/sysfs-class-firmware-attributes index 90fdf935aa5e..13e31c6a0e9c 100644 --- a/Documentation/ABI/testing/sysfs-class-firmware-attributes +++ b/Documentation/ABI/testing/sysfs-class-firmware-attributes @@ -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 diff --git a/Documentation/ABI/testing/sysfs-class-power b/Documentation/ABI/testing/sysfs-class-power index f7904efc4cfa..fde21d900420 100644 --- a/Documentation/ABI/testing/sysfs-class-power +++ b/Documentation/ABI/testing/sysfs-class-power @@ -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 diff --git a/Documentation/ABI/testing/sysfs-devices-system-cpu b/Documentation/ABI/testing/sysfs-devices-system-cpu index 69c65da16dff..61f5676a7429 100644 --- a/Documentation/ABI/testing/sysfs-devices-system-cpu +++ b/Documentation/ABI/testing/sysfs-devices-system-cpu @@ -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=". diff --git a/Documentation/ABI/testing/sysfs-fs-erofs b/Documentation/ABI/testing/sysfs-fs-erofs new file mode 100644 index 000000000000..05482374a741 --- /dev/null +++ b/Documentation/ABI/testing/sysfs-fs-erofs @@ -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. diff --git a/Documentation/ABI/testing/sysfs-fs-f2fs b/Documentation/ABI/testing/sysfs-fs-f2fs index b268e3e18b4a..2416b03ff283 100644 --- a/Documentation/ABI/testing/sysfs-fs-f2fs +++ b/Documentation/ABI/testing/sysfs-fs-f2fs @@ -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. diff --git a/Documentation/ABI/testing/sysfs-fs-ubifs b/Documentation/ABI/testing/sysfs-fs-ubifs new file mode 100644 index 000000000000..af5afda30220 --- /dev/null +++ b/Documentation/ABI/testing/sysfs-fs-ubifs @@ -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. diff --git a/Documentation/Makefile b/Documentation/Makefile index c3feb657b654..9f4bd42cef18 100644 --- a/Documentation/Makefile +++ b/Documentation/Makefile @@ -19,6 +19,8 @@ endif SPHINXBUILD = sphinx-build SPHINXOPTS = SPHINXDIRS = . +DOCS_THEME = +DOCS_CSS = _SPHINXDIRS = $(sort $(patsubst $(srctree)/Documentation/%/index.rst,%,$(wildcard $(srctree)/Documentation/*/index.rst))) SPHINX_CONF = conf.py PAPER = @@ -84,7 +86,10 @@ quiet_cmd_sphinx = SPHINX $@ --> file://$(abspath $(BUILDDIR)/$3/$4) -D version=$(KERNELVERSION) -D release=$(KERNELRELEASE) \ $(ALLSPHINXOPTS) \ $(abspath $(srctree)/$(src)/$5) \ - $(abspath $(BUILDDIR)/$3/$4) + $(abspath $(BUILDDIR)/$3/$4) && \ + if [ "x$(DOCS_CSS)" != "x" ]; then \ + cp $(if $(patsubst /%,,$(DOCS_CSS)),$(abspath $(srctree)/$(DOCS_CSS)),$(DOCS_CSS)) $(BUILDDIR)/$3/_static/; \ + fi htmldocs: @$(srctree)/scripts/sphinx-pre-install --version-check @@ -154,4 +159,8 @@ dochelp: @echo ' make SPHINX_CONF={conf-file} [target] use *additional* sphinx-build' @echo ' configuration. This is e.g. useful to build with nit-picking config.' @echo + @echo ' make DOCS_THEME={sphinx-theme} selects a different Sphinx theme.' + @echo + @echo ' make DOCS_CSS={a .css file} adds a DOCS_CSS override file for html/epub output.' + @echo @echo ' Default location for the generated documents is Documentation/output' diff --git a/Documentation/RCU/Design/Expedited-Grace-Periods/Funnel0.svg b/Documentation/RCU/Design/Expedited-Grace-Periods/Funnel0.svg index 98af66557908..16b1ff0ad38c 100644 --- a/Documentation/RCU/Design/Expedited-Grace-Periods/Funnel0.svg +++ b/Documentation/RCU/Design/Expedited-Grace-Periods/Funnel0.svg @@ -116,7 +116,7 @@ <flowRoot xml:space="preserve" id="flowRoot2985" - style="font-size:10px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:center;line-height:125%;letter-spacing:0px;word-spacing:0px;writing-mode:lr-tb;text-anchor:middle;fill:#000000;fill-opacity:1;stroke:none;font-family:Symbol;-inkscape-font-specification:Symbol"><flowRegion + style="font-size:10px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:center;line-height:125%;letter-spacing:0px;word-spacing:0px;writing-mode:lr-tb;text-anchor:middle;fill:#000000;fill-opacity:1;stroke:none;font-family:monospace;-inkscape-font-specification:monospace"><flowRegion id="flowRegion2987"><rect id="rect2989" width="82.85714" @@ -125,7 +125,7 @@ y="492.36218" /></flowRegion><flowPara id="flowPara2991" /></flowRoot> <text xml:space="preserve" - style="font-size:10px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:center;line-height:125%;letter-spacing:0px;word-spacing:0px;writing-mode:lr-tb;text-anchor:middle;fill:#000000;fill-opacity:1;stroke:none;font-family:Symbol;-inkscape-font-specification:Symbol" + style="font-size:10px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:center;line-height:125%;letter-spacing:0px;word-spacing:0px;writing-mode:lr-tb;text-anchor:middle;fill:#000000;fill-opacity:1;stroke:none;font-family:monospace;-inkscape-font-specification:monospace" x="362.371" y="262.51819" id="text4441" diff --git a/Documentation/RCU/Design/Expedited-Grace-Periods/Funnel1.svg b/Documentation/RCU/Design/Expedited-Grace-Periods/Funnel1.svg index e0184a37aec7..684a4b969725 100644 --- a/Documentation/RCU/Design/Expedited-Grace-Periods/Funnel1.svg +++ b/Documentation/RCU/Design/Expedited-Grace-Periods/Funnel1.svg @@ -116,7 +116,7 @@ <flowRoot xml:space="preserve" id="flowRoot2985" - style="font-size:10px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:center;line-height:125%;letter-spacing:0px;word-spacing:0px;writing-mode:lr-tb;text-anchor:middle;fill:#000000;fill-opacity:1;stroke:none;font-family:Symbol;-inkscape-font-specification:Symbol"><flowRegion + style="font-size:10px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:center;line-height:125%;letter-spacing:0px;word-spacing:0px;writing-mode:lr-tb;text-anchor:middle;fill:#000000;fill-opacity:1;stroke:none;font-family:monospace;-inkscape-font-specification:monospace"><flowRegion id="flowRegion2987"><rect id="rect2989" width="82.85714" @@ -125,7 +125,7 @@ y="492.36218" /></flowRegion><flowPara id="flowPara2991" /></flowRoot> <text xml:space="preserve" - style="font-size:10px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:center;line-height:125%;letter-spacing:0px;word-spacing:0px;writing-mode:lr-tb;text-anchor:middle;fill:#000000;fill-opacity:1;stroke:none;font-family:Symbol;-inkscape-font-specification:Symbol" + style="font-size:10px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:center;line-height:125%;letter-spacing:0px;word-spacing:0px;writing-mode:lr-tb;text-anchor:middle;fill:#000000;fill-opacity:1;stroke:none;font-family:monospace;-inkscape-font-specification:monospace" x="362.371" y="262.51819" id="text4441" diff --git a/Documentation/RCU/Design/Expedited-Grace-Periods/Funnel2.svg b/Documentation/RCU/Design/Expedited-Grace-Periods/Funnel2.svg index 1bc3fed54d58..8fb2454d9544 100644 --- a/Documentation/RCU/Design/Expedited-Grace-Periods/Funnel2.svg +++ b/Documentation/RCU/Design/Expedited-Grace-Periods/Funnel2.svg @@ -116,7 +116,7 @@ <flowRoot xml:space="preserve" id="flowRoot2985" - style="font-size:10px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:center;line-height:125%;letter-spacing:0px;word-spacing:0px;writing-mode:lr-tb;text-anchor:middle;fill:#000000;fill-opacity:1;stroke:none;font-family:Symbol;-inkscape-font-specification:Symbol"><flowRegion + style="font-size:10px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:center;line-height:125%;letter-spacing:0px;word-spacing:0px;writing-mode:lr-tb;text-anchor:middle;fill:#000000;fill-opacity:1;stroke:none;font-family:monospace;-inkscape-font-specification:monospace"><flowRegion id="flowRegion2987"><rect id="rect2989" width="82.85714" @@ -125,7 +125,7 @@ y="492.36218" /></flowRegion><flowPara id="flowPara2991" /></flowRoot> <text xml:space="preserve" - style="font-size:10px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:center;line-height:125%;letter-spacing:0px;word-spacing:0px;writing-mode:lr-tb;text-anchor:middle;fill:#000000;fill-opacity:1;stroke:none;font-family:Symbol;-inkscape-font-specification:Symbol" + style="font-size:10px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:center;line-height:125%;letter-spacing:0px;word-spacing:0px;writing-mode:lr-tb;text-anchor:middle;fill:#000000;fill-opacity:1;stroke:none;font-family:monospace;-inkscape-font-specification:monospace" x="362.371" y="262.51819" id="text4441" diff --git a/Documentation/RCU/Design/Expedited-Grace-Periods/Funnel3.svg b/Documentation/RCU/Design/Expedited-Grace-Periods/Funnel3.svg index 6d8a1bffb3e4..5d4f22d5662c 100644 --- a/Documentation/RCU/Design/Expedited-Grace-Periods/Funnel3.svg +++ b/Documentation/RCU/Design/Expedited-Grace-Periods/Funnel3.svg @@ -116,7 +116,7 @@ <flowRoot xml:space="preserve" id="flowRoot2985" - style="font-size:10px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:center;line-height:125%;letter-spacing:0px;word-spacing:0px;writing-mode:lr-tb;text-anchor:middle;fill:#000000;fill-opacity:1;stroke:none;font-family:Symbol;-inkscape-font-specification:Symbol"><flowRegion + style="font-size:10px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:center;line-height:125%;letter-spacing:0px;word-spacing:0px;writing-mode:lr-tb;text-anchor:middle;fill:#000000;fill-opacity:1;stroke:none;font-family:monospace;-inkscape-font-specification:monospace"><flowRegion id="flowRegion2987"><rect id="rect2989" width="82.85714" @@ -125,7 +125,7 @@ y="492.36218" /></flowRegion><flowPara id="flowPara2991" /></flowRoot> <text xml:space="preserve" - style="font-size:10px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:center;line-height:125%;letter-spacing:0px;word-spacing:0px;writing-mode:lr-tb;text-anchor:middle;fill:#000000;fill-opacity:1;stroke:none;font-family:Symbol;-inkscape-font-specification:Symbol" + style="font-size:10px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:center;line-height:125%;letter-spacing:0px;word-spacing:0px;writing-mode:lr-tb;text-anchor:middle;fill:#000000;fill-opacity:1;stroke:none;font-family:monospace;-inkscape-font-specification:monospace" x="362.371" y="262.51819" id="text4441" diff --git a/Documentation/RCU/Design/Expedited-Grace-Periods/Funnel4.svg b/Documentation/RCU/Design/Expedited-Grace-Periods/Funnel4.svg index 44018fd6342b..b89b02869914 100644 --- a/Documentation/RCU/Design/Expedited-Grace-Periods/Funnel4.svg +++ b/Documentation/RCU/Design/Expedited-Grace-Periods/Funnel4.svg @@ -116,7 +116,7 @@ <flowRoot xml:space="preserve" id="flowRoot2985" - style="font-size:10px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:center;line-height:125%;letter-spacing:0px;word-spacing:0px;writing-mode:lr-tb;text-anchor:middle;fill:#000000;fill-opacity:1;stroke:none;font-family:Symbol;-inkscape-font-specification:Symbol"><flowRegion + style="font-size:10px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:center;line-height:125%;letter-spacing:0px;word-spacing:0px;writing-mode:lr-tb;text-anchor:middle;fill:#000000;fill-opacity:1;stroke:none;font-family:monospace;-inkscape-font-specification:monospace"><flowRegion id="flowRegion2987"><rect id="rect2989" width="82.85714" @@ -125,7 +125,7 @@ y="492.36218" /></flowRegion><flowPara id="flowPara2991" /></flowRoot> <text xml:space="preserve" - style="font-size:10px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:center;line-height:125%;letter-spacing:0px;word-spacing:0px;writing-mode:lr-tb;text-anchor:middle;fill:#000000;fill-opacity:1;stroke:none;font-family:Symbol;-inkscape-font-specification:Symbol" + style="font-size:10px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:center;line-height:125%;letter-spacing:0px;word-spacing:0px;writing-mode:lr-tb;text-anchor:middle;fill:#000000;fill-opacity:1;stroke:none;font-family:monospace;-inkscape-font-specification:monospace" x="362.371" y="262.51819" id="text4441" diff --git a/Documentation/RCU/Design/Expedited-Grace-Periods/Funnel5.svg b/Documentation/RCU/Design/Expedited-Grace-Periods/Funnel5.svg index e5eef50454fb..90f1c77bea2f 100644 --- a/Documentation/RCU/Design/Expedited-Grace-Periods/Funnel5.svg +++ b/Documentation/RCU/Design/Expedited-Grace-Periods/Funnel5.svg @@ -116,7 +116,7 @@ <flowRoot xml:space="preserve" id="flowRoot2985" - style="font-size:10px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:center;line-height:125%;letter-spacing:0px;word-spacing:0px;writing-mode:lr-tb;text-anchor:middle;fill:#000000;fill-opacity:1;stroke:none;font-family:Symbol;-inkscape-font-specification:Symbol"><flowRegion + style="font-size:10px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:center;line-height:125%;letter-spacing:0px;word-spacing:0px;writing-mode:lr-tb;text-anchor:middle;fill:#000000;fill-opacity:1;stroke:none;font-family:monospace;-inkscape-font-specification:monospace"><flowRegion id="flowRegion2987"><rect id="rect2989" width="82.85714" @@ -125,7 +125,7 @@ y="492.36218" /></flowRegion><flowPara id="flowPara2991" /></flowRoot> <text xml:space="preserve" - style="font-size:10px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:center;line-height:125%;letter-spacing:0px;word-spacing:0px;writing-mode:lr-tb;text-anchor:middle;fill:#000000;fill-opacity:1;stroke:none;font-family:Symbol;-inkscape-font-specification:Symbol" + style="font-size:10px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:center;line-height:125%;letter-spacing:0px;word-spacing:0px;writing-mode:lr-tb;text-anchor:middle;fill:#000000;fill-opacity:1;stroke:none;font-family:monospace;-inkscape-font-specification:monospace" x="362.371" y="262.51819" id="text4441" diff --git a/Documentation/RCU/Design/Expedited-Grace-Periods/Funnel6.svg b/Documentation/RCU/Design/Expedited-Grace-Periods/Funnel6.svg index fbd2c1892886..3e5651da031a 100644 --- a/Documentation/RCU/Design/Expedited-Grace-Periods/Funnel6.svg +++ b/Documentation/RCU/Design/Expedited-Grace-Periods/Funnel6.svg @@ -116,7 +116,7 @@ <flowRoot xml:space="preserve" id="flowRoot2985" - style="font-size:10px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:center;line-height:125%;letter-spacing:0px;word-spacing:0px;writing-mode:lr-tb;text-anchor:middle;fill:#000000;fill-opacity:1;stroke:none;font-family:Symbol;-inkscape-font-specification:Symbol"><flowRegion + style="font-size:10px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:center;line-height:125%;letter-spacing:0px;word-spacing:0px;writing-mode:lr-tb;text-anchor:middle;fill:#000000;fill-opacity:1;stroke:none;font-family:monospace;-inkscape-font-specification:monospace"><flowRegion id="flowRegion2987"><rect id="rect2989" width="82.85714" @@ -125,7 +125,7 @@ y="492.36218" /></flowRegion><flowPara id="flowPara2991" /></flowRoot> <text xml:space="preserve" - style="font-size:10px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:center;line-height:125%;letter-spacing:0px;word-spacing:0px;writing-mode:lr-tb;text-anchor:middle;fill:#000000;fill-opacity:1;stroke:none;font-family:Symbol;-inkscape-font-specification:Symbol" + style="font-size:10px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:center;line-height:125%;letter-spacing:0px;word-spacing:0px;writing-mode:lr-tb;text-anchor:middle;fill:#000000;fill-opacity:1;stroke:none;font-family:monospace;-inkscape-font-specification:monospace" x="362.371" y="262.51819" id="text4441" diff --git a/Documentation/RCU/Design/Expedited-Grace-Periods/Funnel7.svg b/Documentation/RCU/Design/Expedited-Grace-Periods/Funnel7.svg index 502e159ed278..9483f08d345e 100644 --- a/Documentation/RCU/Design/Expedited-Grace-Periods/Funnel7.svg +++ b/Documentation/RCU/Design/Expedited-Grace-Periods/Funnel7.svg @@ -116,7 +116,7 @@ <flowRoot xml:space="preserve" id="flowRoot2985" - style="font-size:10px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:center;line-height:125%;letter-spacing:0px;word-spacing:0px;writing-mode:lr-tb;text-anchor:middle;fill:#000000;fill-opacity:1;stroke:none;font-family:Symbol;-inkscape-font-specification:Symbol"><flowRegion + style="font-size:10px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:center;line-height:125%;letter-spacing:0px;word-spacing:0px;writing-mode:lr-tb;text-anchor:middle;fill:#000000;fill-opacity:1;stroke:none;font-family:monospace;-inkscape-font-specification:monospace"><flowRegion id="flowRegion2987"><rect id="rect2989" width="82.85714" @@ -125,7 +125,7 @@ y="492.36218" /></flowRegion><flowPara id="flowPara2991" /></flowRoot> <text xml:space="preserve" - style="font-size:10px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:center;line-height:125%;letter-spacing:0px;word-spacing:0px;writing-mode:lr-tb;text-anchor:middle;fill:#000000;fill-opacity:1;stroke:none;font-family:Symbol;-inkscape-font-specification:Symbol" + style="font-size:10px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:center;line-height:125%;letter-spacing:0px;word-spacing:0px;writing-mode:lr-tb;text-anchor:middle;fill:#000000;fill-opacity:1;stroke:none;font-family:monospace;-inkscape-font-specification:monospace" x="362.371" y="262.51819" id="text4441" diff --git a/Documentation/RCU/Design/Expedited-Grace-Periods/Funnel8.svg b/Documentation/RCU/Design/Expedited-Grace-Periods/Funnel8.svg index 677401551c7d..1101ec30e604 100644 --- a/Documentation/RCU/Design/Expedited-Grace-Periods/Funnel8.svg +++ b/Documentation/RCU/Design/Expedited-Grace-Periods/Funnel8.svg @@ -116,7 +116,7 @@ <flowRoot xml:space="preserve" id="flowRoot2985" - style="font-size:10px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:center;line-height:125%;letter-spacing:0px;word-spacing:0px;writing-mode:lr-tb;text-anchor:middle;fill:#000000;fill-opacity:1;stroke:none;font-family:Symbol;-inkscape-font-specification:Symbol"><flowRegion + style="font-size:10px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:center;line-height:125%;letter-spacing:0px;word-spacing:0px;writing-mode:lr-tb;text-anchor:middle;fill:#000000;fill-opacity:1;stroke:none;font-family:monospace;-inkscape-font-specification:monospace"><flowRegion id="flowRegion2987"><rect id="rect2989" width="82.85714" @@ -125,7 +125,7 @@ y="492.36218" /></flowRegion><flowPara id="flowPara2991" /></flowRoot> <text xml:space="preserve" - style="font-size:10px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:center;line-height:125%;letter-spacing:0px;word-spacing:0px;writing-mode:lr-tb;text-anchor:middle;fill:#000000;fill-opacity:1;stroke:none;font-family:Symbol;-inkscape-font-specification:Symbol" + style="font-size:10px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:center;line-height:125%;letter-spacing:0px;word-spacing:0px;writing-mode:lr-tb;text-anchor:middle;fill:#000000;fill-opacity:1;stroke:none;font-family:monospace;-inkscape-font-specification:monospace" x="362.371" y="262.51819" id="text4441" diff --git a/Documentation/RCU/Design/Requirements/GPpartitionReaders1.svg b/Documentation/RCU/Design/Requirements/GPpartitionReaders1.svg index 4b4014fda770..87851a8fac1e 100644 --- a/Documentation/RCU/Design/Requirements/GPpartitionReaders1.svg +++ b/Documentation/RCU/Design/Requirements/GPpartitionReaders1.svg @@ -88,7 +88,7 @@ <flowRoot xml:space="preserve" id="flowRoot2985" - style="font-size:10px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:center;line-height:125%;letter-spacing:0px;word-spacing:0px;writing-mode:lr-tb;text-anchor:middle;fill:#000000;fill-opacity:1;stroke:none;font-family:Symbol;-inkscape-font-specification:Symbol"><flowRegion + style="font-size:10px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:center;line-height:125%;letter-spacing:0px;word-spacing:0px;writing-mode:lr-tb;text-anchor:middle;fill:#000000;fill-opacity:1;stroke:none;font-family:monospace;-inkscape-font-specification:monospace"><flowRegion id="flowRegion2987"><rect id="rect2989" width="82.85714" @@ -103,7 +103,7 @@ id="text2993" y="-261.66608" x="412.12299" - style="font-size:10px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:center;line-height:125%;letter-spacing:0px;word-spacing:0px;writing-mode:lr-tb;text-anchor:middle;fill:#000000;fill-opacity:1;stroke:none;font-family:Symbol;-inkscape-font-specification:Symbol" + style="font-size:10px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:center;line-height:125%;letter-spacing:0px;word-spacing:0px;writing-mode:lr-tb;text-anchor:middle;fill:#000000;fill-opacity:1;stroke:none;font-family:monospace;-inkscape-font-specification:monospace" xml:space="preserve" transform="matrix(0,1,-1,0,0,0)"><tspan y="-261.66608" @@ -135,7 +135,7 @@ </g> <text xml:space="preserve" - style="font-size:10px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:center;line-height:125%;letter-spacing:0px;word-spacing:0px;writing-mode:lr-tb;text-anchor:middle;fill:#000000;fill-opacity:1;stroke:none;font-family:Symbol;-inkscape-font-specification:Symbol" + style="font-size:10px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:center;line-height:125%;letter-spacing:0px;word-spacing:0px;writing-mode:lr-tb;text-anchor:middle;fill:#000000;fill-opacity:1;stroke:none;font-family:monospace;-inkscape-font-specification:monospace" x="112.04738" y="268.18076" id="text4429" @@ -146,7 +146,7 @@ y="268.18076">WRITE_ONCE(a, 1);</tspan></text> <text xml:space="preserve" - style="font-size:10px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:center;line-height:125%;letter-spacing:0px;word-spacing:0px;writing-mode:lr-tb;text-anchor:middle;fill:#000000;fill-opacity:1;stroke:none;font-family:Symbol;-inkscape-font-specification:Symbol" + style="font-size:10px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:center;line-height:125%;letter-spacing:0px;word-spacing:0px;writing-mode:lr-tb;text-anchor:middle;fill:#000000;fill-opacity:1;stroke:none;font-family:monospace;-inkscape-font-specification:monospace" x="112.04738" y="439.13766" id="text4441" @@ -157,7 +157,7 @@ y="439.13766">WRITE_ONCE(b, 1);</tspan></text> <text xml:space="preserve" - style="font-size:10px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:center;line-height:125%;letter-spacing:0px;word-spacing:0px;writing-mode:lr-tb;text-anchor:middle;fill:#000000;fill-opacity:1;stroke:none;font-family:Symbol;-inkscape-font-specification:Symbol" + style="font-size:10px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:center;line-height:125%;letter-spacing:0px;word-spacing:0px;writing-mode:lr-tb;text-anchor:middle;fill:#000000;fill-opacity:1;stroke:none;font-family:monospace;-inkscape-font-specification:monospace" x="255.60869" y="309.29346" id="text4445" @@ -168,7 +168,7 @@ y="309.29346">r1 = READ_ONCE(a);</tspan></text> <text xml:space="preserve" - style="font-size:10px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:center;line-height:125%;letter-spacing:0px;word-spacing:0px;writing-mode:lr-tb;text-anchor:middle;fill:#000000;fill-opacity:1;stroke:none;font-family:Symbol;-inkscape-font-specification:Symbol" + style="font-size:10px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:center;line-height:125%;letter-spacing:0px;word-spacing:0px;writing-mode:lr-tb;text-anchor:middle;fill:#000000;fill-opacity:1;stroke:none;font-family:monospace;-inkscape-font-specification:monospace" x="255.14423" y="520.61786" id="text4449" @@ -179,7 +179,7 @@ y="520.61786">WRITE_ONCE(c, 1);</tspan></text> <text xml:space="preserve" - style="font-size:10px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:center;line-height:125%;letter-spacing:0px;word-spacing:0px;writing-mode:lr-tb;text-anchor:middle;fill:#000000;fill-opacity:1;stroke:none;font-family:Symbol;-inkscape-font-specification:Symbol" + style="font-size:10px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:center;line-height:125%;letter-spacing:0px;word-spacing:0px;writing-mode:lr-tb;text-anchor:middle;fill:#000000;fill-opacity:1;stroke:none;font-family:monospace;-inkscape-font-specification:monospace" x="396.10254" y="384.71124" id="text4453" @@ -190,7 +190,7 @@ y="384.71124">r2 = READ_ONCE(b);</tspan></text> <text xml:space="preserve" - style="font-size:10px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:center;line-height:125%;letter-spacing:0px;word-spacing:0px;writing-mode:lr-tb;text-anchor:middle;fill:#000000;fill-opacity:1;stroke:none;font-family:Symbol;-inkscape-font-specification:Symbol" + style="font-size:10px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:center;line-height:125%;letter-spacing:0px;word-spacing:0px;writing-mode:lr-tb;text-anchor:middle;fill:#000000;fill-opacity:1;stroke:none;font-family:monospace;-inkscape-font-specification:monospace" x="396.10254" y="582.13617" id="text4457" @@ -201,7 +201,7 @@ y="582.13617">r3 = READ_ONCE(c);</tspan></text> <text xml:space="preserve" - style="font-size:10px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:center;line-height:125%;letter-spacing:0px;word-spacing:0px;writing-mode:lr-tb;text-anchor:middle;fill:#000000;fill-opacity:1;stroke:none;font-family:Symbol;-inkscape-font-specification:Symbol" + style="font-size:10px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:center;line-height:125%;letter-spacing:0px;word-spacing:0px;writing-mode:lr-tb;text-anchor:middle;fill:#000000;fill-opacity:1;stroke:none;font-family:monospace;-inkscape-font-specification:monospace" x="112.08231" y="213.91006" id="text4461" @@ -212,7 +212,7 @@ y="213.91006">thread0()</tspan></text> <text xml:space="preserve" - style="font-size:10px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:center;line-height:125%;letter-spacing:0px;word-spacing:0px;writing-mode:lr-tb;text-anchor:middle;fill:#000000;fill-opacity:1;stroke:none;font-family:Symbol;-inkscape-font-specification:Symbol" + style="font-size:10px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:center;line-height:125%;letter-spacing:0px;word-spacing:0px;writing-mode:lr-tb;text-anchor:middle;fill:#000000;fill-opacity:1;stroke:none;font-family:monospace;-inkscape-font-specification:monospace" x="252.34512" y="213.91006" id="text4461-6" @@ -223,7 +223,7 @@ y="213.91006">thread1()</tspan></text> <text xml:space="preserve" - style="font-size:10px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:center;line-height:125%;letter-spacing:0px;word-spacing:0px;writing-mode:lr-tb;text-anchor:middle;fill:#000000;fill-opacity:1;stroke:none;font-family:Symbol;-inkscape-font-specification:Symbol" + style="font-size:10px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:center;line-height:125%;letter-spacing:0px;word-spacing:0px;writing-mode:lr-tb;text-anchor:middle;fill:#000000;fill-opacity:1;stroke:none;font-family:monospace;-inkscape-font-specification:monospace" x="396.42557" y="213.91006" id="text4461-2" @@ -251,7 +251,7 @@ inkscape:connector-curvature="0" /> <text xml:space="preserve" - style="font-size:10px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:center;line-height:125%;letter-spacing:0px;word-spacing:0px;writing-mode:lr-tb;text-anchor:middle;fill:#000000;fill-opacity:1;stroke:none;font-family:Symbol;-inkscape-font-specification:Symbol" + style="font-size:10px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:center;line-height:125%;letter-spacing:0px;word-spacing:0px;writing-mode:lr-tb;text-anchor:middle;fill:#000000;fill-opacity:1;stroke:none;font-family:monospace;-inkscape-font-specification:monospace" x="111.75929" y="251.53981" id="text4429-8" @@ -262,7 +262,7 @@ y="251.53981">rcu_read_lock();</tspan></text> <text xml:space="preserve" - style="font-size:10px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:center;line-height:125%;letter-spacing:0px;word-spacing:0px;writing-mode:lr-tb;text-anchor:middle;fill:#000000;fill-opacity:1;stroke:none;font-family:Symbol;-inkscape-font-specification:Symbol" + style="font-size:10px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:center;line-height:125%;letter-spacing:0px;word-spacing:0px;writing-mode:lr-tb;text-anchor:middle;fill:#000000;fill-opacity:1;stroke:none;font-family:monospace;-inkscape-font-specification:monospace" x="396.10254" y="367.91556" id="text4429-8-9" @@ -273,7 +273,7 @@ y="367.91556">rcu_read_lock();</tspan></text> <text xml:space="preserve" - style="font-size:10px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:center;line-height:125%;letter-spacing:0px;word-spacing:0px;writing-mode:lr-tb;text-anchor:middle;fill:#000000;fill-opacity:1;stroke:none;font-family:Symbol;-inkscape-font-specification:Symbol" + style="font-size:10px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:center;line-height:125%;letter-spacing:0px;word-spacing:0px;writing-mode:lr-tb;text-anchor:middle;fill:#000000;fill-opacity:1;stroke:none;font-family:monospace;-inkscape-font-specification:monospace" x="396.10254" y="597.40289" id="text4429-8-9-3" @@ -284,7 +284,7 @@ y="597.40289">rcu_read_unlock();</tspan></text> <text xml:space="preserve" - style="font-size:10px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:center;line-height:125%;letter-spacing:0px;word-spacing:0px;writing-mode:lr-tb;text-anchor:middle;fill:#000000;fill-opacity:1;stroke:none;font-family:Symbol;-inkscape-font-specification:Symbol" + style="font-size:10px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:center;line-height:125%;letter-spacing:0px;word-spacing:0px;writing-mode:lr-tb;text-anchor:middle;fill:#000000;fill-opacity:1;stroke:none;font-family:monospace;-inkscape-font-specification:monospace" x="111.75929" y="453.15311" id="text4429-8-9-3-1" @@ -300,7 +300,7 @@ inkscape:connector-curvature="0" /> <text xml:space="preserve" - style="font-size:10px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:center;line-height:125%;letter-spacing:0px;word-spacing:0px;writing-mode:lr-tb;text-anchor:middle;fill:#000000;fill-opacity:1;stroke:none;font-family:Symbol;-inkscape-font-specification:Symbol" + style="font-size:10px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:center;line-height:125%;letter-spacing:0px;word-spacing:0px;writing-mode:lr-tb;text-anchor:middle;fill:#000000;fill-opacity:1;stroke:none;font-family:monospace;-inkscape-font-specification:monospace" x="394.94427" y="345.66351" id="text4648" @@ -324,7 +324,7 @@ sodipodi:open="true" /> <text xml:space="preserve" - style="font-size:10px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:center;line-height:125%;letter-spacing:0px;word-spacing:0px;writing-mode:lr-tb;text-anchor:middle;fill:#000000;fill-opacity:1;stroke:none;font-family:Symbol;-inkscape-font-specification:Symbol" + style="font-size:10px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:center;line-height:125%;letter-spacing:0px;word-spacing:0px;writing-mode:lr-tb;text-anchor:middle;fill:#000000;fill-opacity:1;stroke:none;font-family:monospace;-inkscape-font-specification:monospace" x="112.11968" y="475.77856" id="text4648-4" @@ -361,7 +361,7 @@ sodipodi:open="true" /> <text xml:space="preserve" - style="font-size:10px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:center;line-height:125%;letter-spacing:0px;word-spacing:0px;writing-mode:lr-tb;text-anchor:middle;fill:#000000;fill-opacity:1;stroke:none;font-family:Symbol;-inkscape-font-specification:Symbol" + style="font-size:10px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:center;line-height:125%;letter-spacing:0px;word-spacing:0px;writing-mode:lr-tb;text-anchor:middle;fill:#000000;fill-opacity:1;stroke:none;font-family:monospace;-inkscape-font-specification:monospace" x="254.85066" y="348.96619" id="text4648-4-3" diff --git a/Documentation/RCU/Design/Requirements/ReadersPartitionGP1.svg b/Documentation/RCU/Design/Requirements/ReadersPartitionGP1.svg index 48cd1623d4d4..e2a8af592bab 100644 --- a/Documentation/RCU/Design/Requirements/ReadersPartitionGP1.svg +++ b/Documentation/RCU/Design/Requirements/ReadersPartitionGP1.svg @@ -116,7 +116,7 @@ <flowRoot xml:space="preserve" id="flowRoot2985" - style="font-size:10px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:center;line-height:125%;letter-spacing:0px;word-spacing:0px;writing-mode:lr-tb;text-anchor:middle;fill:#000000;fill-opacity:1;stroke:none;font-family:Symbol;-inkscape-font-specification:Symbol"><flowRegion + style="font-size:10px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:center;line-height:125%;letter-spacing:0px;word-spacing:0px;writing-mode:lr-tb;text-anchor:middle;fill:#000000;fill-opacity:1;stroke:none;font-family:monospace;-inkscape-font-specification:monospace"><flowRegion id="flowRegion2987"><rect id="rect2989" width="82.85714" @@ -131,7 +131,7 @@ id="text2993" y="-261.66608" x="436.12299" - style="font-size:10px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:center;line-height:125%;letter-spacing:0px;word-spacing:0px;writing-mode:lr-tb;text-anchor:middle;fill:#000000;fill-opacity:1;stroke:none;font-family:Symbol;-inkscape-font-specification:Symbol" + style="font-size:10px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:center;line-height:125%;letter-spacing:0px;word-spacing:0px;writing-mode:lr-tb;text-anchor:middle;fill:#000000;fill-opacity:1;stroke:none;font-family:monospace;-inkscape-font-specification:monospace" xml:space="preserve" transform="matrix(0,1,-1,0,0,0)"><tspan y="-261.66608" @@ -163,7 +163,7 @@ </g> <text xml:space="preserve" - style="font-size:10px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:center;line-height:125%;letter-spacing:0px;word-spacing:0px;writing-mode:lr-tb;text-anchor:middle;fill:#000000;fill-opacity:1;stroke:none;font-family:Symbol;-inkscape-font-specification:Symbol" + style="font-size:10px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:center;line-height:125%;letter-spacing:0px;word-spacing:0px;writing-mode:lr-tb;text-anchor:middle;fill:#000000;fill-opacity:1;stroke:none;font-family:monospace;-inkscape-font-specification:monospace" x="112.04738" y="268.18076" id="text4429" @@ -174,7 +174,7 @@ y="268.18076">WRITE_ONCE(a, 1);</tspan></text> <text xml:space="preserve" - style="font-size:10px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:center;line-height:125%;letter-spacing:0px;word-spacing:0px;writing-mode:lr-tb;text-anchor:middle;fill:#000000;fill-opacity:1;stroke:none;font-family:Symbol;-inkscape-font-specification:Symbol" + style="font-size:10px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:center;line-height:125%;letter-spacing:0px;word-spacing:0px;writing-mode:lr-tb;text-anchor:middle;fill:#000000;fill-opacity:1;stroke:none;font-family:monospace;-inkscape-font-specification:monospace" x="112.04738" y="487.13766" id="text4441" @@ -185,7 +185,7 @@ y="487.13766">WRITE_ONCE(b, 1);</tspan></text> <text xml:space="preserve" - style="font-size:10px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:center;line-height:125%;letter-spacing:0px;word-spacing:0px;writing-mode:lr-tb;text-anchor:middle;fill:#000000;fill-opacity:1;stroke:none;font-family:Symbol;-inkscape-font-specification:Symbol" + style="font-size:10px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:center;line-height:125%;letter-spacing:0px;word-spacing:0px;writing-mode:lr-tb;text-anchor:middle;fill:#000000;fill-opacity:1;stroke:none;font-family:monospace;-inkscape-font-specification:monospace" x="255.60869" y="297.29346" id="text4445" @@ -196,7 +196,7 @@ y="297.29346">r1 = READ_ONCE(a);</tspan></text> <text xml:space="preserve" - style="font-size:10px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:center;line-height:125%;letter-spacing:0px;word-spacing:0px;writing-mode:lr-tb;text-anchor:middle;fill:#000000;fill-opacity:1;stroke:none;font-family:Symbol;-inkscape-font-specification:Symbol" + style="font-size:10px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:center;line-height:125%;letter-spacing:0px;word-spacing:0px;writing-mode:lr-tb;text-anchor:middle;fill:#000000;fill-opacity:1;stroke:none;font-family:monospace;-inkscape-font-specification:monospace" x="255.14423" y="554.61786" id="text4449" @@ -207,7 +207,7 @@ y="554.61786">WRITE_ONCE(c, 1);</tspan></text> <text xml:space="preserve" - style="font-size:10px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:center;line-height:125%;letter-spacing:0px;word-spacing:0px;writing-mode:lr-tb;text-anchor:middle;fill:#000000;fill-opacity:1;stroke:none;font-family:Symbol;-inkscape-font-specification:Symbol" + style="font-size:10px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:center;line-height:125%;letter-spacing:0px;word-spacing:0px;writing-mode:lr-tb;text-anchor:middle;fill:#000000;fill-opacity:1;stroke:none;font-family:monospace;-inkscape-font-specification:monospace" x="396.10254" y="370.71124" id="text4453" @@ -218,7 +218,7 @@ y="370.71124">WRITE_ONCE(d, 1);</tspan></text> <text xml:space="preserve" - style="font-size:10px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:center;line-height:125%;letter-spacing:0px;word-spacing:0px;writing-mode:lr-tb;text-anchor:middle;fill:#000000;fill-opacity:1;stroke:none;font-family:Symbol;-inkscape-font-specification:Symbol" + style="font-size:10px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:center;line-height:125%;letter-spacing:0px;word-spacing:0px;writing-mode:lr-tb;text-anchor:middle;fill:#000000;fill-opacity:1;stroke:none;font-family:monospace;-inkscape-font-specification:monospace" x="396.10254" y="572.13617" id="text4457" @@ -229,7 +229,7 @@ y="572.13617">r2 = READ_ONCE(c);</tspan></text> <text xml:space="preserve" - style="font-size:10px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:center;line-height:125%;letter-spacing:0px;word-spacing:0px;writing-mode:lr-tb;text-anchor:middle;fill:#000000;fill-opacity:1;stroke:none;font-family:Symbol;-inkscape-font-specification:Symbol" + style="font-size:10px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:center;line-height:125%;letter-spacing:0px;word-spacing:0px;writing-mode:lr-tb;text-anchor:middle;fill:#000000;fill-opacity:1;stroke:none;font-family:monospace;-inkscape-font-specification:monospace" x="112.08231" y="213.91006" id="text4461" @@ -240,7 +240,7 @@ y="213.91006">thread0()</tspan></text> <text xml:space="preserve" - style="font-size:10px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:center;line-height:125%;letter-spacing:0px;word-spacing:0px;writing-mode:lr-tb;text-anchor:middle;fill:#000000;fill-opacity:1;stroke:none;font-family:Symbol;-inkscape-font-specification:Symbol" + style="font-size:10px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:center;line-height:125%;letter-spacing:0px;word-spacing:0px;writing-mode:lr-tb;text-anchor:middle;fill:#000000;fill-opacity:1;stroke:none;font-family:monospace;-inkscape-font-specification:monospace" x="252.34512" y="213.91006" id="text4461-6" @@ -251,7 +251,7 @@ y="213.91006">thread1()</tspan></text> <text xml:space="preserve" - style="font-size:10px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:center;line-height:125%;letter-spacing:0px;word-spacing:0px;writing-mode:lr-tb;text-anchor:middle;fill:#000000;fill-opacity:1;stroke:none;font-family:Symbol;-inkscape-font-specification:Symbol" + style="font-size:10px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:center;line-height:125%;letter-spacing:0px;word-spacing:0px;writing-mode:lr-tb;text-anchor:middle;fill:#000000;fill-opacity:1;stroke:none;font-family:monospace;-inkscape-font-specification:monospace" x="396.42557" y="213.91006" id="text4461-2" @@ -281,7 +281,7 @@ sodipodi:nodetypes="cc" /> <text xml:space="preserve" - style="font-size:10px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:center;line-height:125%;letter-spacing:0px;word-spacing:0px;writing-mode:lr-tb;text-anchor:middle;fill:#000000;fill-opacity:1;stroke:none;font-family:Symbol;-inkscape-font-specification:Symbol" + style="font-size:10px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:center;line-height:125%;letter-spacing:0px;word-spacing:0px;writing-mode:lr-tb;text-anchor:middle;fill:#000000;fill-opacity:1;stroke:none;font-family:monospace;-inkscape-font-specification:monospace" x="111.75929" y="251.53981" id="text4429-8" @@ -292,7 +292,7 @@ y="251.53981">rcu_read_lock();</tspan></text> <text xml:space="preserve" - style="font-size:10px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:center;line-height:125%;letter-spacing:0px;word-spacing:0px;writing-mode:lr-tb;text-anchor:middle;fill:#000000;fill-opacity:1;stroke:none;font-family:Symbol;-inkscape-font-specification:Symbol" + style="font-size:10px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:center;line-height:125%;letter-spacing:0px;word-spacing:0px;writing-mode:lr-tb;text-anchor:middle;fill:#000000;fill-opacity:1;stroke:none;font-family:monospace;-inkscape-font-specification:monospace" x="396.10254" y="353.91556" id="text4429-8-9" @@ -303,7 +303,7 @@ y="353.91556">rcu_read_lock();</tspan></text> <text xml:space="preserve" - style="font-size:10px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:center;line-height:125%;letter-spacing:0px;word-spacing:0px;writing-mode:lr-tb;text-anchor:middle;fill:#000000;fill-opacity:1;stroke:none;font-family:Symbol;-inkscape-font-specification:Symbol" + style="font-size:10px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:center;line-height:125%;letter-spacing:0px;word-spacing:0px;writing-mode:lr-tb;text-anchor:middle;fill:#000000;fill-opacity:1;stroke:none;font-family:monospace;-inkscape-font-specification:monospace" x="396.10254" y="587.40289" id="text4429-8-9-3" @@ -314,7 +314,7 @@ y="587.40289">rcu_read_unlock();</tspan></text> <text xml:space="preserve" - style="font-size:10px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:center;line-height:125%;letter-spacing:0px;word-spacing:0px;writing-mode:lr-tb;text-anchor:middle;fill:#000000;fill-opacity:1;stroke:none;font-family:Symbol;-inkscape-font-specification:Symbol" + style="font-size:10px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:center;line-height:125%;letter-spacing:0px;word-spacing:0px;writing-mode:lr-tb;text-anchor:middle;fill:#000000;fill-opacity:1;stroke:none;font-family:monospace;-inkscape-font-specification:monospace" x="111.75929" y="501.15311" id="text4429-8-9-3-1" @@ -331,7 +331,7 @@ sodipodi:nodetypes="cc" /> <text xml:space="preserve" - style="font-size:10px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:center;line-height:125%;letter-spacing:0px;word-spacing:0px;writing-mode:lr-tb;text-anchor:middle;fill:#000000;fill-opacity:1;stroke:none;font-family:Symbol;-inkscape-font-specification:Symbol" + style="font-size:10px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:center;line-height:125%;letter-spacing:0px;word-spacing:0px;writing-mode:lr-tb;text-anchor:middle;fill:#000000;fill-opacity:1;stroke:none;font-family:monospace;-inkscape-font-specification:monospace" x="394.94427" y="331.66351" id="text4648" @@ -355,7 +355,7 @@ sodipodi:open="true" /> <text xml:space="preserve" - style="font-size:10px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:center;line-height:125%;letter-spacing:0px;word-spacing:0px;writing-mode:lr-tb;text-anchor:middle;fill:#000000;fill-opacity:1;stroke:none;font-family:Symbol;-inkscape-font-specification:Symbol" + style="font-size:10px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:center;line-height:125%;letter-spacing:0px;word-spacing:0px;writing-mode:lr-tb;text-anchor:middle;fill:#000000;fill-opacity:1;stroke:none;font-family:monospace;-inkscape-font-specification:monospace" x="112.11968" y="523.77856" id="text4648-4" @@ -392,7 +392,7 @@ sodipodi:open="true" /> <text xml:space="preserve" - style="font-size:10px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:center;line-height:125%;letter-spacing:0px;word-spacing:0px;writing-mode:lr-tb;text-anchor:middle;fill:#000000;fill-opacity:1;stroke:none;font-family:Symbol;-inkscape-font-specification:Symbol" + style="font-size:10px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:center;line-height:125%;letter-spacing:0px;word-spacing:0px;writing-mode:lr-tb;text-anchor:middle;fill:#000000;fill-opacity:1;stroke:none;font-family:monospace;-inkscape-font-specification:monospace" x="254.85066" y="336.96619" id="text4648-4-3" @@ -421,7 +421,7 @@ id="text2993-7" y="-261.66608" x="440.12299" - style="font-size:10px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:center;line-height:125%;letter-spacing:0px;word-spacing:0px;writing-mode:lr-tb;text-anchor:middle;fill:#000000;fill-opacity:1;stroke:none;font-family:Symbol;-inkscape-font-specification:Symbol" + style="font-size:10px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:center;line-height:125%;letter-spacing:0px;word-spacing:0px;writing-mode:lr-tb;text-anchor:middle;fill:#000000;fill-opacity:1;stroke:none;font-family:monospace;-inkscape-font-specification:monospace" xml:space="preserve" transform="matrix(0,1,-1,0,0,0)"><tspan y="-261.66608" @@ -453,7 +453,7 @@ </g> <text xml:space="preserve" - style="font-size:10px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:center;line-height:125%;letter-spacing:0px;word-spacing:0px;writing-mode:lr-tb;text-anchor:middle;fill:#000000;fill-opacity:1;stroke:none;font-family:Symbol;-inkscape-font-specification:Symbol" + style="font-size:10px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:center;line-height:125%;letter-spacing:0px;word-spacing:0px;writing-mode:lr-tb;text-anchor:middle;fill:#000000;fill-opacity:1;stroke:none;font-family:monospace;-inkscape-font-specification:monospace" x="541.70508" y="387.6217" id="text4445-0" @@ -464,7 +464,7 @@ y="387.6217">r3 = READ_ONCE(d);</tspan></text> <text xml:space="preserve" - style="font-size:10px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:center;line-height:125%;letter-spacing:0px;word-spacing:0px;writing-mode:lr-tb;text-anchor:middle;fill:#000000;fill-opacity:1;stroke:none;font-family:Symbol;-inkscape-font-specification:Symbol" + style="font-size:10px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:center;line-height:125%;letter-spacing:0px;word-spacing:0px;writing-mode:lr-tb;text-anchor:middle;fill:#000000;fill-opacity:1;stroke:none;font-family:monospace;-inkscape-font-specification:monospace" x="541.2406" y="646.94611" id="text4449-6" @@ -488,7 +488,7 @@ sodipodi:open="true" /> <text xml:space="preserve" - style="font-size:10px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:center;line-height:125%;letter-spacing:0px;word-spacing:0px;writing-mode:lr-tb;text-anchor:middle;fill:#000000;fill-opacity:1;stroke:none;font-family:Symbol;-inkscape-font-specification:Symbol" + style="font-size:10px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:center;line-height:125%;letter-spacing:0px;word-spacing:0px;writing-mode:lr-tb;text-anchor:middle;fill:#000000;fill-opacity:1;stroke:none;font-family:monospace;-inkscape-font-specification:monospace" x="540.94702" y="427.29443" id="text4648-4-3-1" @@ -499,7 +499,7 @@ y="427.29443">QS</tspan></text> <text xml:space="preserve" - style="font-size:10px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:center;line-height:125%;letter-spacing:0px;word-spacing:0px;writing-mode:lr-tb;text-anchor:middle;fill:#000000;fill-opacity:1;stroke:none;font-family:Symbol;-inkscape-font-specification:Symbol" + style="font-size:10px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:center;line-height:125%;letter-spacing:0px;word-spacing:0px;writing-mode:lr-tb;text-anchor:middle;fill:#000000;fill-opacity:1;stroke:none;font-family:monospace;-inkscape-font-specification:monospace" x="686.27747" y="461.83929" id="text4453-7" @@ -510,7 +510,7 @@ y="461.83929">r4 = READ_ONCE(b);</tspan></text> <text xml:space="preserve" - style="font-size:10px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:center;line-height:125%;letter-spacing:0px;word-spacing:0px;writing-mode:lr-tb;text-anchor:middle;fill:#000000;fill-opacity:1;stroke:none;font-family:Symbol;-inkscape-font-specification:Symbol" + style="font-size:10px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:center;line-height:125%;letter-spacing:0px;word-spacing:0px;writing-mode:lr-tb;text-anchor:middle;fill:#000000;fill-opacity:1;stroke:none;font-family:monospace;-inkscape-font-specification:monospace" x="686.27747" y="669.26422" id="text4457-9" @@ -521,7 +521,7 @@ y="669.26422">r5 = READ_ONCE(e);</tspan></text> <text xml:space="preserve" - style="font-size:10px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:center;line-height:125%;letter-spacing:0px;word-spacing:0px;writing-mode:lr-tb;text-anchor:middle;fill:#000000;fill-opacity:1;stroke:none;font-family:Symbol;-inkscape-font-specification:Symbol" + style="font-size:10px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:center;line-height:125%;letter-spacing:0px;word-spacing:0px;writing-mode:lr-tb;text-anchor:middle;fill:#000000;fill-opacity:1;stroke:none;font-family:monospace;-inkscape-font-specification:monospace" x="686.27747" y="445.04358" id="text4429-8-9-33" @@ -532,7 +532,7 @@ y="445.04358">rcu_read_lock();</tspan></text> <text xml:space="preserve" - style="font-size:10px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:center;line-height:125%;letter-spacing:0px;word-spacing:0px;writing-mode:lr-tb;text-anchor:middle;fill:#000000;fill-opacity:1;stroke:none;font-family:Symbol;-inkscape-font-specification:Symbol" + style="font-size:10px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:center;line-height:125%;letter-spacing:0px;word-spacing:0px;writing-mode:lr-tb;text-anchor:middle;fill:#000000;fill-opacity:1;stroke:none;font-family:monospace;-inkscape-font-specification:monospace" x="686.27747" y="684.53094" id="text4429-8-9-3-8" @@ -543,7 +543,7 @@ y="684.53094">rcu_read_unlock();</tspan></text> <text xml:space="preserve" - style="font-size:10px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:center;line-height:125%;letter-spacing:0px;word-spacing:0px;writing-mode:lr-tb;text-anchor:middle;fill:#000000;fill-opacity:1;stroke:none;font-family:Symbol;-inkscape-font-specification:Symbol" + style="font-size:10px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:center;line-height:125%;letter-spacing:0px;word-spacing:0px;writing-mode:lr-tb;text-anchor:middle;fill:#000000;fill-opacity:1;stroke:none;font-family:monospace;-inkscape-font-specification:monospace" x="685.11914" y="422.79153" id="text4648-9" @@ -567,7 +567,7 @@ sodipodi:open="true" /> <text xml:space="preserve" - style="font-size:10px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:center;line-height:125%;letter-spacing:0px;word-spacing:0px;writing-mode:lr-tb;text-anchor:middle;fill:#000000;fill-opacity:1;stroke:none;font-family:Symbol;-inkscape-font-specification:Symbol" + style="font-size:10px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:center;line-height:125%;letter-spacing:0px;word-spacing:0px;writing-mode:lr-tb;text-anchor:middle;fill:#000000;fill-opacity:1;stroke:none;font-family:monospace;-inkscape-font-specification:monospace" x="397.85934" y="609.59003" id="text4648-5" @@ -591,7 +591,7 @@ sodipodi:open="true" /> <text xml:space="preserve" - style="font-size:10px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:center;line-height:125%;letter-spacing:0px;word-spacing:0px;writing-mode:lr-tb;text-anchor:middle;fill:#000000;fill-opacity:1;stroke:none;font-family:Symbol;-inkscape-font-specification:Symbol" + style="font-size:10px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:center;line-height:125%;letter-spacing:0px;word-spacing:0px;writing-mode:lr-tb;text-anchor:middle;fill:#000000;fill-opacity:1;stroke:none;font-family:monospace;-inkscape-font-specification:monospace" x="256.75986" y="586.99133" id="text4648-5-2" @@ -615,7 +615,7 @@ sodipodi:open="true" /> <text xml:space="preserve" - style="font-size:10px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:center;line-height:125%;letter-spacing:0px;word-spacing:0px;writing-mode:lr-tb;text-anchor:middle;fill:#000000;fill-opacity:1;stroke:none;font-family:Symbol;-inkscape-font-specification:Symbol" + style="font-size:10px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:center;line-height:125%;letter-spacing:0px;word-spacing:0px;writing-mode:lr-tb;text-anchor:middle;fill:#000000;fill-opacity:1;stroke:none;font-family:monospace;-inkscape-font-specification:monospace" x="546.22791" y="213.91006" id="text4461-2-5" @@ -626,7 +626,7 @@ y="213.91006">thread3()</tspan></text> <text xml:space="preserve" - style="font-size:10px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:center;line-height:125%;letter-spacing:0px;word-spacing:0px;writing-mode:lr-tb;text-anchor:middle;fill:#000000;fill-opacity:1;stroke:none;font-family:Symbol;-inkscape-font-specification:Symbol" + style="font-size:10px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:center;line-height:125%;letter-spacing:0px;word-spacing:0px;writing-mode:lr-tb;text-anchor:middle;fill:#000000;fill-opacity:1;stroke:none;font-family:monospace;-inkscape-font-specification:monospace" x="684.00067" y="213.91006" id="text4461-2-1" diff --git a/Documentation/RCU/stallwarn.rst b/Documentation/RCU/stallwarn.rst index 28f8ad16db25..78404625bad2 100644 --- a/Documentation/RCU/stallwarn.rst +++ b/Documentation/RCU/stallwarn.rst @@ -254,17 +254,6 @@ period (in this case 2603), the grace-period sequence number (7075), and an estimate of the total number of RCU callbacks queued across all CPUs (625 in this case). -In kernels with CONFIG_RCU_FAST_NO_HZ, more information is printed -for each CPU:: - - 0: (64628 ticks this GP) idle=dd5/3fffffffffffffff/0 softirq=82/543 last_accelerate: a345/d342 dyntick_enabled: 1 - -The "last_accelerate:" prints the low-order 16 bits (in hex) of the -jiffies counter when this CPU last invoked rcu_try_advance_all_cbs() -from rcu_needs_cpu() or last invoked rcu_accelerate_cbs() from -rcu_prepare_for_idle(). "dyntick_enabled: 1" indicates that dyntick-idle -processing is enabled. - If the grace period ends just as the stall warning starts printing, there will be a spurious stall-warning message, which will include the following:: diff --git a/Documentation/RCU/whatisRCU.rst b/Documentation/RCU/whatisRCU.rst index 17e95ab2a201..c34d2212eaca 100644 --- a/Documentation/RCU/whatisRCU.rst +++ b/Documentation/RCU/whatisRCU.rst @@ -39,9 +39,11 @@ different paths, as follows: :ref:`6. ANALOGY WITH READER-WRITER LOCKING <6_whatisRCU>` -:ref:`7. FULL LIST OF RCU APIs <7_whatisRCU>` +:ref:`7. ANALOGY WITH REFERENCE COUNTING <7_whatisRCU>` -:ref:`8. ANSWERS TO QUICK QUIZZES <8_whatisRCU>` +:ref:`8. FULL LIST OF RCU APIs <8_whatisRCU>` + +:ref:`9. ANSWERS TO QUICK QUIZZES <9_whatisRCU>` People who prefer starting with a conceptual overview should focus on Section 1, though most readers will profit by reading this section at @@ -677,7 +679,7 @@ Quick Quiz #1: occur when using this algorithm in a real-world Linux kernel? How could this deadlock be avoided? -:ref:`Answers to Quick Quiz <8_whatisRCU>` +:ref:`Answers to Quick Quiz <9_whatisRCU>` 5B. "TOY" EXAMPLE #2: CLASSIC RCU ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ @@ -732,7 +734,7 @@ Quick Quiz #2: Give an example where Classic RCU's read-side overhead is **negative**. -:ref:`Answers to Quick Quiz <8_whatisRCU>` +:ref:`Answers to Quick Quiz <9_whatisRCU>` .. _quiz_3: @@ -741,7 +743,7 @@ Quick Quiz #3: critical section, what the heck do you do in CONFIG_PREEMPT_RT, where normal spinlocks can block??? -:ref:`Answers to Quick Quiz <8_whatisRCU>` +:ref:`Answers to Quick Quiz <9_whatisRCU>` .. _6_whatisRCU: @@ -872,7 +874,79 @@ be used in place of synchronize_rcu(). .. _7_whatisRCU: -7. FULL LIST OF RCU APIs +7. ANALOGY WITH REFERENCE COUNTING +----------------------------------- + +The reader-writer analogy (illustrated by the previous section) is not +always the best way to think about using RCU. Another helpful analogy +considers RCU an effective reference count on everything which is +protected by RCU. + +A reference count typically does not prevent the referenced object's +values from changing, but does prevent changes to type -- particularly the +gross change of type that happens when that object's memory is freed and +re-allocated for some other purpose. Once a type-safe reference to the +object is obtained, some other mechanism is needed to ensure consistent +access to the data in the object. This could involve taking a spinlock, +but with RCU the typical approach is to perform reads with SMP-aware +operations such as smp_load_acquire(), to perform updates with atomic +read-modify-write operations, and to provide the necessary ordering. +RCU provides a number of support functions that embed the required +operations and ordering, such as the list_for_each_entry_rcu() macro +used in the previous section. + +A more focused view of the reference counting behavior is that, +between rcu_read_lock() and rcu_read_unlock(), any reference taken with +rcu_dereference() on a pointer marked as ``__rcu`` can be treated as +though a reference-count on that object has been temporarily increased. +This prevents the object from changing type. Exactly what this means +will depend on normal expectations of objects of that type, but it +typically includes that spinlocks can still be safely locked, normal +reference counters can be safely manipulated, and ``__rcu`` pointers +can be safely dereferenced. + +Some operations that one might expect to see on an object for +which an RCU reference is held include: + + - Copying out data that is guaranteed to be stable by the object's type. + - Using kref_get_unless_zero() or similar to get a longer-term + reference. This may fail of course. + - Acquiring a spinlock in the object, and checking if the object still + is the expected object and if so, manipulating it freely. + +The understanding that RCU provides a reference that only prevents a +change of type is particularly visible with objects allocated from a +slab cache marked ``SLAB_TYPESAFE_BY_RCU``. RCU operations may yield a +reference to an object from such a cache that has been concurrently +freed and the memory reallocated to a completely different object, +though of the same type. In this case RCU doesn't even protect the +identity of the object from changing, only its type. So the object +found may not be the one expected, but it will be one where it is safe +to take a reference or spinlock and then confirm that the identity +matches the expectations. + +With traditional reference counting -- such as that implemented by the +kref library in Linux -- there is typically code that runs when the last +reference to an object is dropped. With kref, this is the function +passed to kref_put(). When RCU is being used, such finalization code +must not be run until all ``__rcu`` pointers referencing the object have +been updated, and then a grace period has passed. Every remaining +globally visible pointer to the object must be considered to be a +potential counted reference, and the finalization code is typically run +using call_rcu() only after all those pointers have been changed. + +To see how to choose between these two analogies -- of RCU as a +reader-writer lock and RCU as a reference counting system -- it is useful +to reflect on the scale of the thing being protected. The reader-writer +lock analogy looks at larger multi-part objects such as a linked list +and shows how RCU can facilitate concurrency while elements are added +to, and removed from, the list. The reference-count analogy looks at +the individual objects and looks at how they can be accessed safely +within whatever whole they are a part of. + +.. _8_whatisRCU: + +8. FULL LIST OF RCU APIs ------------------------- The RCU APIs are documented in docbook-format header comments in the @@ -1035,9 +1109,9 @@ g. Otherwise, use RCU. Of course, this all assumes that you have determined that RCU is in fact the right tool for your job. -.. _8_whatisRCU: +.. _9_whatisRCU: -8. ANSWERS TO QUICK QUIZZES +9. ANSWERS TO QUICK QUIZZES ---------------------------- Quick Quiz #1: diff --git a/Documentation/accounting/delay-accounting.rst b/Documentation/accounting/delay-accounting.rst index 1b8b46deeb29..197fe319cbec 100644 --- a/Documentation/accounting/delay-accounting.rst +++ b/Documentation/accounting/delay-accounting.rst @@ -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 - - - 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 + # ./getdelays -d -t 5 + print delayacct stats ON + TGID 5 -Get delays seen in executing a given simple command:: - # ./getdelays -c ls / + 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 - bin data1 data3 data5 dev home media opt root srv sys usr - boot data2 data4 data6 etc lib mnt proc sbin subdomain tmp var +Get IO accounting for pid 1, it works only with -p:: + # ./getdelays -i -p 1 + printing IO accounting + linuxrc: read=65536, write=0, cancelled_write=0 - 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. diff --git a/Documentation/accounting/psi.rst b/Documentation/accounting/psi.rst index f2b3439edcc2..860fe651d645 100644 --- a/Documentation/accounting/psi.rst +++ b/Documentation/accounting/psi.rst @@ -92,7 +92,8 @@ Triggers can be set on more than one psi metric and more than one trigger for the same psi metric can be specified. However for each trigger a separate file descriptor is required to be able to poll it separately from others, therefore for each trigger a separate open() syscall should be made even -when opening the same psi interface file. +when opening the same psi interface file. Write operations to a file descriptor +with an already existing psi trigger will fail with EBUSY. Monitors activate only when system enters stall state for the monitored psi metric and deactivates upon exit from the stall state. While system is diff --git a/Documentation/admin-guide/acpi/cppc_sysfs.rst b/Documentation/admin-guide/acpi/cppc_sysfs.rst index fccf22114e85..e53d76365aa7 100644 --- a/Documentation/admin-guide/acpi/cppc_sysfs.rst +++ b/Documentation/admin-guide/acpi/cppc_sysfs.rst @@ -4,6 +4,8 @@ Collaborative Processor Performance Control (CPPC) ================================================== +.. _cppc_sysfs: + CPPC ==== diff --git a/Documentation/admin-guide/blockdev/drbd/figures.rst b/Documentation/admin-guide/blockdev/drbd/figures.rst index bd9a4901fe46..9f73253ea353 100644 --- a/Documentation/admin-guide/blockdev/drbd/figures.rst +++ b/Documentation/admin-guide/blockdev/drbd/figures.rst @@ -25,6 +25,6 @@ Sub graphs of DRBD's state transitions :alt: disk-states-8.dot :align: center -.. kernel-figure:: node-states-8.dot - :alt: node-states-8.dot +.. kernel-figure:: peer-states-8.dot + :alt: peer-states-8.dot :align: center diff --git a/Documentation/admin-guide/blockdev/drbd/node-states-8.dot b/Documentation/admin-guide/blockdev/drbd/peer-states-8.dot index bfa54e1f8016..6dc3954954d6 100644 --- a/Documentation/admin-guide/blockdev/drbd/node-states-8.dot +++ b/Documentation/admin-guide/blockdev/drbd/peer-states-8.dot @@ -1,8 +1,3 @@ -digraph node_states { - Secondary -> Primary [ label = "ioctl_set_state()" ] - Primary -> Secondary [ label = "ioctl_set_state()" ] -} - digraph peer_states { Secondary -> Primary [ label = "recv state packet" ] Primary -> Secondary [ label = "recv state packet" ] diff --git a/Documentation/admin-guide/cgroup-v1/hugetlb.rst b/Documentation/admin-guide/cgroup-v1/hugetlb.rst index 338f2c7d7a1c..0fa724d82abb 100644 --- a/Documentation/admin-guide/cgroup-v1/hugetlb.rst +++ b/Documentation/admin-guide/cgroup-v1/hugetlb.rst @@ -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 diff --git a/Documentation/admin-guide/cgroup-v2.rst b/Documentation/admin-guide/cgroup-v2.rst index 2aeb7ae8b393..5aa368d165da 100644 --- a/Documentation/admin-guide/cgroup-v2.rst +++ b/Documentation/admin-guide/cgroup-v2.rst @@ -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 ---- diff --git a/Documentation/admin-guide/cifs/usage.rst b/Documentation/admin-guide/cifs/usage.rst index f170d8820258..3766bf8a1c20 100644 --- a/Documentation/admin-guide/cifs/usage.rst +++ b/Documentation/admin-guide/cifs/usage.rst @@ -734,10 +734,9 @@ SecurityFlags Flags which control security negotiation and using weaker password hashes is 0x37037 (lanman, plaintext, ntlm, ntlmv2, signing allowed). Some SecurityFlags require the corresponding menuconfig - options to be enabled (lanman and plaintext require - CONFIG_CIFS_WEAK_PW_HASH for example). Enabling - plaintext authentication currently requires also - enabling lanman authentication in the security flags + options to be enabled. Enabling plaintext + authentication currently requires also enabling + lanman authentication in the security flags because the cifs module only supports sending laintext passwords using the older lanman dialect form of the session setup SMB. (e.g. for authentication diff --git a/Documentation/admin-guide/cputopology.rst b/Documentation/admin-guide/cputopology.rst index 6b62e182baf4..d29cacc9b3c3 100644 --- a/Documentation/admin-guide/cputopology.rst +++ b/Documentation/admin-guide/cputopology.rst @@ -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 diff --git a/Documentation/admin-guide/devices.txt b/Documentation/admin-guide/devices.txt index 922c23bb4372..c07dc0ee860e 100644 --- a/Documentation/admin-guide/devices.txt +++ b/Documentation/admin-guide/devices.txt @@ -2339,13 +2339,7 @@ disks (see major number 3) except that the limit on partitions is 31. - 162 char Raw block device interface - 0 = /dev/rawctl Raw I/O control device - 1 = /dev/raw/raw1 First raw I/O device - 2 = /dev/raw/raw2 Second raw I/O device - ... - max minor number of raw device is set by kernel config - MAX_RAW_DEVS or raw module parameter 'max_raw_devs' + 162 char Used for (now removed) raw block device interface 163 char diff --git a/Documentation/admin-guide/gpio/gpio-sim.rst b/Documentation/admin-guide/gpio/gpio-sim.rst new file mode 100644 index 000000000000..d8a90c81b9ee --- /dev/null +++ b/Documentation/admin-guide/gpio/gpio-sim.rst @@ -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 diff --git a/Documentation/admin-guide/gpio/index.rst b/Documentation/admin-guide/gpio/index.rst index 7db367572f30..f6861ca16ffe 100644 --- a/Documentation/admin-guide/gpio/index.rst +++ b/Documentation/admin-guide/gpio/index.rst @@ -10,6 +10,7 @@ gpio gpio-aggregator sysfs gpio-mockup + gpio-sim .. only:: subproject and html diff --git a/Documentation/admin-guide/hw-vuln/spectre.rst b/Documentation/admin-guide/hw-vuln/spectre.rst index ab7d402c1677..a2b22d5640ec 100644 --- a/Documentation/admin-guide/hw-vuln/spectre.rst +++ b/Documentation/admin-guide/hw-vuln/spectre.rst @@ -468,7 +468,7 @@ Spectre variant 2 before invoking any firmware code to prevent Spectre variant 2 exploits using the firmware. - Using kernel address space randomization (CONFIG_RANDOMIZE_SLAB=y + Using kernel address space randomization (CONFIG_RANDOMIZE_BASE=y and CONFIG_SLAB_FREELIST_RANDOM=y in the kernel configuration) makes attacks on the kernel generally more difficult. diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt index eb258526d70d..f5a27f067db9 100644 --- a/Documentation/admin-guide/kernel-parameters.txt +++ b/Documentation/admin-guide/kernel-parameters.txt @@ -225,14 +225,23 @@ For broken nForce2 BIOS resulting in XT-PIC timer. acpi_sleep= [HW,ACPI] Sleep options - Format: { s3_bios, s3_mode, s3_beep, s4_nohwsig, - old_ordering, nonvs, sci_force_enable, nobl } + Format: { s3_bios, s3_mode, s3_beep, s4_hwsig, + s4_nohwsig, old_ordering, nonvs, + sci_force_enable, nobl } See Documentation/power/video.rst for information on s3_bios and s3_mode. s3_beep is for debugging; it makes the PC's speaker beep as soon as the kernel's real-mode entry point is called. + s4_hwsig causes the kernel to check the ACPI hardware + signature during resume from hibernation, and gracefully + refuse to resume if it has changed. This complies with + the ACPI specification but not with reality, since + Windows does not do this and many laptops do change it + on docking. So the default behaviour is to allow resume + and simply warn when the signature changes, unless the + s4_hwsig option is enabled. s4_nohwsig prevents ACPI hardware signature from being - used during resume from hibernation. + used (or even warned about) during resume. old_ordering causes the ACPI 1.0 ordering of the _PTS control method, with respect to putting devices into low power states, to be enforced (the ACPI 2.0 ordering @@ -603,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 @@ -1689,6 +1698,8 @@ architectures force reset to be always executed i8042.unlock [HW] Unlock (ignore) the keylock i8042.kbdreset [HW] Reset device connected to KBD port + i8042.probe_defer + [HW] Allow deferred probing upon i8042 probe errors i810= [HW,DRM] @@ -2413,8 +2424,12 @@ Default is 1 (enabled) kvm-intel.emulate_invalid_guest_state= - [KVM,Intel] Enable emulation of invalid guest states - Default is 0 (disabled) + [KVM,Intel] Disable emulation of invalid guest state. + Ignored if kvm-intel.enable_unrestricted_guest=1, as + guest state is never invalid for unrestricted guests. + This param doesn't apply to nested guests (L2), as KVM + never emulates invalid L2 guest state. + Default is 1 (enabled) kvm-intel.flexpriority= [KVM,Intel] Disable FlexPriority feature (TPR shadow). @@ -2934,7 +2949,7 @@ both parameters are enabled, hugetlb_free_vmemmap takes precedence over memory_hotplug.memmap_on_memory. - memtest= [KNL,X86,ARM,PPC,RISCV] Enable memtest + memtest= [KNL,X86,ARM,M68K,PPC,RISCV] Enable memtest Format: <integer> default : 0 <disable> Specifies the number of memtest passes to be @@ -3378,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. @@ -4151,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. @@ -4350,19 +4373,30 @@ Disable the Correctable Errors Collector, see CONFIG_RAS_CEC help text. - rcu_nocbs= [KNL] - The argument is a cpu list, as described above. - - In kernels built with CONFIG_RCU_NOCB_CPU=y, set - the specified list of CPUs to be no-callback CPUs. - Invocation of these CPUs' RCU callbacks will be - offloaded to "rcuox/N" kthreads created for that - purpose, where "x" is "p" for RCU-preempt, and - "s" for RCU-sched, and "N" is the CPU number. - This reduces OS jitter on the offloaded CPUs, - which can be useful for HPC and real-time - workloads. It can also improve energy efficiency - for asymmetric multiprocessors. + rcu_nocbs[=cpu-list] + [KNL] The optional argument is a cpu list, + as described above. + + In kernels built with CONFIG_RCU_NOCB_CPU=y, + enable the no-callback CPU mode, which prevents + such CPUs' callbacks from being invoked in + softirq context. Invocation of such CPUs' RCU + callbacks will instead be offloaded to "rcuox/N" + kthreads created for that purpose, where "x" is + "p" for RCU-preempt, "s" for RCU-sched, and "g" + for the kthreads that mediate grace periods; and + "N" is the CPU number. This reduces OS jitter on + the offloaded CPUs, which can be useful for HPC + and real-time workloads. It can also improve + energy efficiency for asymmetric multiprocessors. + + If a cpulist is passed as an argument, the specified + list of CPUs is set to no-callback mode from boot. + + Otherwise, if the '=' sign and the cpulist + arguments are omitted, no CPU will be set to + no-callback mode from boot but the mode may be + toggled at runtime via cpusets. rcu_nocb_poll [KNL] Rather than requiring that offloaded CPUs @@ -4496,10 +4530,6 @@ on rcutree.qhimark at boot time and to zero to disable more aggressive help enlistment. - rcutree.rcu_idle_gp_delay= [KNL] - Set wakeup interval for idle CPUs that have - RCU callbacks (RCU_FAST_NO_HZ=y). - rcutree.rcu_kick_kthreads= [KNL] Cause the grace-period kthread to get an extra wake_up() if it sleeps three times longer than @@ -4610,8 +4640,12 @@ in seconds. rcutorture.fwd_progress= [KNL] - Enable RCU grace-period forward-progress testing + Specifies the number of kthreads to be used + for RCU grace-period forward-progress testing for the types of RCU supporting this notion. + Defaults to 1 kthread, values less than zero or + greater than the number of CPUs cause the number + of CPUs to be used. rcutorture.fwd_progress_div= [KNL] Specify the fraction of a CPU-stall-warning @@ -4812,6 +4846,29 @@ period to instead use normal non-expedited grace-period processing. + rcupdate.rcu_task_collapse_lim= [KNL] + Set the maximum number of callbacks present + at the beginning of a grace period that allows + the RCU Tasks flavors to collapse back to using + a single callback queue. This switching only + occurs when rcupdate.rcu_task_enqueue_lim is + set to the default value of -1. + + rcupdate.rcu_task_contend_lim= [KNL] + Set the minimum number of callback-queuing-time + lock-contention events per jiffy required to + cause the RCU Tasks flavors to switch to per-CPU + callback queuing. This switching only occurs + when rcupdate.rcu_task_enqueue_lim is set to + the default value of -1. + + rcupdate.rcu_task_enqueue_lim= [KNL] + Set the number of callback queues to use for the + RCU Tasks family of RCU flavors. The default + of -1 allows this to be automatically (and + dynamically) adjusted. This parameter is intended + for use in testing. + rcupdate.rcu_task_ipi_delay= [KNL] Set time in jiffies during which RCU tasks will avoid sending IPIs, starting with the beginning @@ -6445,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 diff --git a/Documentation/admin-guide/kernel-per-CPU-kthreads.rst b/Documentation/admin-guide/kernel-per-CPU-kthreads.rst index 5e51ee5b0358..e4a5fc26f1a9 100644 --- a/Documentation/admin-guide/kernel-per-CPU-kthreads.rst +++ b/Documentation/admin-guide/kernel-per-CPU-kthreads.rst @@ -208,7 +208,7 @@ Do at least one of the following: 2. Enable RCU to do its processing remotely via dyntick-idle by doing all of the following: - a. Build with CONFIG_NO_HZ=y and CONFIG_RCU_FAST_NO_HZ=y. + a. Build with CONFIG_NO_HZ=y. b. Ensure that the CPU goes idle frequently, allowing other CPUs to detect that it has passed through an RCU quiescent state. If the kernel is built with CONFIG_NO_HZ_FULL=y, diff --git a/Documentation/admin-guide/media/platform-cardlist.rst b/Documentation/admin-guide/media/platform-cardlist.rst index 261e7772eb3e..ac73c4166d1e 100644 --- a/Documentation/admin-guide/media/platform-cardlist.rst +++ b/Documentation/admin-guide/media/platform-cardlist.rst @@ -60,6 +60,7 @@ s5p-mfc Samsung S5P MFC Video Codec sh_veu SuperH VEU mem2mem video processing sh_vou SuperH VOU video output stm32-dcmi STM32 Digital Camera Memory Interface (DCMI) +stm32-dma2d STM32 Chrom-Art Accelerator Unit sun4i-csi Allwinner A10 CMOS Sensor Interface Support sun6i-csi Allwinner V3s Camera Sensor Interface sun8i-di Allwinner Deinterlace diff --git a/Documentation/admin-guide/mm/damon/reclaim.rst b/Documentation/admin-guide/mm/damon/reclaim.rst index fb9def3a7355..0af51a9705b1 100644 --- a/Documentation/admin-guide/mm/damon/reclaim.rst +++ b/Documentation/admin-guide/mm/damon/reclaim.rst @@ -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 ======= diff --git a/Documentation/admin-guide/mm/damon/usage.rst b/Documentation/admin-guide/mm/damon/usage.rst index ed96bbf0daff..59b84904a854 100644 --- a/Documentation/admin-guide/mm/damon/usage.rst +++ b/Documentation/admin-guide/mm/damon/usage.rst @@ -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:: + + <target access pattern> <action> <quota> <watermarks> + +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 - min-size max-size min-acc max-acc min-age max-age action +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. -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. +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 +~~~~~ - # 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 +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. -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. +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 + # 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 ================================= diff --git a/Documentation/admin-guide/mm/numa_memory_policy.rst b/Documentation/admin-guide/mm/numa_memory_policy.rst index 64fd0ba0d057..5a6afecbb0d0 100644 --- a/Documentation/admin-guide/mm/numa_memory_policy.rst +++ b/Documentation/admin-guide/mm/numa_memory_policy.rst @@ -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 ==================================== diff --git a/Documentation/admin-guide/perf/hisi-pcie-pmu.rst b/Documentation/admin-guide/perf/hisi-pcie-pmu.rst new file mode 100644 index 000000000000..294ebbdb22af --- /dev/null +++ b/Documentation/admin-guide/perf/hisi-pcie-pmu.rst @@ -0,0 +1,106 @@ +================================================ +HiSilicon PCIe Performance Monitoring Unit (PMU) +================================================ + +On Hip09, HiSilicon PCIe Performance Monitoring Unit (PMU) could monitor +bandwidth, latency, bus utilization and buffer occupancy data of PCIe. + +Each PCIe Core has a PMU to monitor multi Root Ports of this PCIe Core and +all Endpoints downstream these Root Ports. + + +HiSilicon PCIe PMU driver +========================= + +The PCIe PMU driver registers a perf PMU with the name of its sicl-id and PCIe +Core id.:: + + /sys/bus/event_source/hisi_pcie<sicl>_<core> + +PMU driver provides description of available events and filter options in sysfs, +see /sys/bus/event_source/devices/hisi_pcie<sicl>_<core>. + +The "format" directory describes all formats of the config (events) and config1 +(filter options) fields of the perf_event_attr structure. The "events" directory +describes all documented events shown in perf list. + +The "identifier" sysfs file allows users to identify the version of the +PMU hardware device. + +The "bus" sysfs file allows users to get the bus number of Root Ports +monitored by PMU. + +Example usage of perf:: + + $# perf list + hisi_pcie0_0/rx_mwr_latency/ [kernel PMU event] + hisi_pcie0_0/rx_mwr_cnt/ [kernel PMU event] + ------------------------------------------ + + $# perf stat -e hisi_pcie0_0/rx_mwr_latency/ + $# perf stat -e hisi_pcie0_0/rx_mwr_cnt/ + $# perf stat -g -e hisi_pcie0_0/rx_mwr_latency/ -e hisi_pcie0_0/rx_mwr_cnt/ + +The current driver does not support sampling. So "perf record" is unsupported. +Also attach to a task is unsupported for PCIe PMU. + +Filter options +-------------- + +1. Target filter +PMU could only monitor the performance of traffic downstream target Root Ports +or downstream target Endpoint. PCIe PMU driver support "port" and "bdf" +interfaces for users, and these two interfaces aren't supported at the same +time. + +-port +"port" filter can be used in all PCIe PMU events, target Root Port can be +selected by configuring the 16-bits-bitmap "port". Multi ports can be selected +for AP-layer-events, and only one port can be selected for TL/DL-layer-events. + +For example, if target Root Port is 0000:00:00.0 (x8 lanes), bit0 of bitmap +should be set, port=0x1; if target Root Port is 0000:00:04.0 (x4 lanes), +bit8 is set, port=0x100; if these two Root Ports are both monitored, port=0x101. + +Example usage of perf:: + + $# perf stat -e hisi_pcie0_0/rx_mwr_latency,port=0x1/ sleep 5 + +-bdf + +"bdf" filter can only be used in bandwidth events, target Endpoint is selected +by configuring BDF to "bdf". Counter only counts the bandwidth of message +requested by target Endpoint. + +For example, "bdf=0x3900" means BDF of target Endpoint is 0000:39:00.0. + +Example usage of perf:: + + $# perf stat -e hisi_pcie0_0/rx_mrd_flux,bdf=0x3900/ sleep 5 + +2. Trigger filter +Event statistics start when the first time TLP length is greater/smaller +than trigger condition. You can set the trigger condition by writing "trig_len", +and set the trigger mode by writing "trig_mode". This filter can only be used +in bandwidth events. + +For example, "trig_len=4" means trigger condition is 2^4 DW, "trig_mode=0" +means statistics start when TLP length > trigger condition, "trig_mode=1" +means start when TLP length < condition. + +Example usage of perf:: + + $# perf stat -e hisi_pcie0_0/rx_mrd_flux,trig_len=0x4,trig_mode=1/ sleep 5 + +3. Threshold filter +Counter counts when TLP length within the specified range. You can set the +threshold by writing "thr_len", and set the threshold mode by writing +"thr_mode". This filter can only be used in bandwidth events. + +For example, "thr_len=4" means threshold is 2^4 DW, "thr_mode=0" means +counter counts when TLP length >= threshold, and "thr_mode=1" means counts +when TLP length < threshold. + +Example usage of perf:: + + $# perf stat -e hisi_pcie0_0/rx_mrd_flux,thr_len=0x4,thr_mode=1/ sleep 5 diff --git a/Documentation/admin-guide/pm/amd-pstate.rst b/Documentation/admin-guide/pm/amd-pstate.rst new file mode 100644 index 000000000000..2f066df4ee9c --- /dev/null +++ b/Documentation/admin-guide/pm/amd-pstate.rst @@ -0,0 +1,382 @@ +.. SPDX-License-Identifier: GPL-2.0 +.. include:: <isonum.txt> + +=============================================== +``amd-pstate`` CPU Performance Scaling Driver +=============================================== + +:Copyright: |copy| 2021 Advanced Micro Devices, Inc. + +:Author: Huang Rui <ray.huang@amd.com> + + +Introduction +=================== + +``amd-pstate`` is the AMD CPU performance scaling driver that introduces a +new CPU frequency control mechanism on modern AMD APU and CPU series in +Linux kernel. The new mechanism is based on Collaborative Processor +Performance Control (CPPC) which provides finer grain frequency management +than legacy ACPI hardware P-States. Current AMD CPU/APU platforms are using +the ACPI P-states driver to manage CPU frequency and clocks with switching +only in 3 P-states. CPPC replaces the ACPI P-states controls, allows a +flexible, low-latency interface for the Linux kernel to directly +communicate the performance hints to hardware. + +``amd-pstate`` leverages the Linux kernel governors such as ``schedutil``, +``ondemand``, etc. to manage the performance hints which are provided by +CPPC hardware functionality that internally follows the hardware +specification (for details refer to AMD64 Architecture Programmer's Manual +Volume 2: System Programming [1]_). Currently ``amd-pstate`` supports basic +frequency control function according to kernel governors on some of the +Zen2 and Zen3 processors, and we will implement more AMD specific functions +in future after we verify them on the hardware and SBIOS. + + +AMD CPPC Overview +======================= + +Collaborative Processor Performance Control (CPPC) interface enumerates a +continuous, abstract, and unit-less performance value in a scale that is +not tied to a specific performance state / frequency. This is an ACPI +standard [2]_ which software can specify application performance goals and +hints as a relative target to the infrastructure limits. AMD processors +provides the low latency register model (MSR) instead of AML code +interpreter for performance adjustments. ``amd-pstate`` will initialize a +``struct cpufreq_driver`` instance ``amd_pstate_driver`` with the callbacks +to manage each performance update behavior. :: + + Highest Perf ------>+-----------------------+ +-----------------------+ + | | | | + | | | | + | | Max Perf ---->| | + | | | | + | | | | + Nominal Perf ------>+-----------------------+ +-----------------------+ + | | | | + | | | | + | | | | + | | | | + | | | | + | | | | + | | Desired Perf ---->| | + | | | | + | | | | + | | | | + | | | | + | | | | + | | | | + | | | | + | | | | + | | | | + Lowest non- | | | | + linear perf ------>+-----------------------+ +-----------------------+ + | | | | + | | Lowest perf ---->| | + | | | | + Lowest perf ------>+-----------------------+ +-----------------------+ + | | | | + | | | | + | | | | + 0 ------>+-----------------------+ +-----------------------+ + + AMD P-States Performance Scale + + +.. _perf_cap: + +AMD CPPC Performance Capability +-------------------------------- + +Highest Performance (RO) +......................... + +It is the absolute maximum performance an individual processor may reach, +assuming ideal conditions. This performance level may not be sustainable +for long durations and may only be achievable if other platform components +are in a specific state; for example, it may require other processors be in +an idle state. This would be equivalent to the highest frequencies +supported by the processor. + +Nominal (Guaranteed) Performance (RO) +...................................... + +It is the maximum sustained performance level of the processor, assuming +ideal operating conditions. In absence of an external constraint (power, +thermal, etc.) this is the performance level the processor is expected to +be able to maintain continuously. All cores/processors are expected to be +able to sustain their nominal performance state simultaneously. + +Lowest non-linear Performance (RO) +................................... + +It is the lowest performance level at which nonlinear power savings are +achieved, for example, due to the combined effects of voltage and frequency +scaling. Above this threshold, lower performance levels should be generally +more energy efficient than higher performance levels. This register +effectively conveys the most efficient performance level to ``amd-pstate``. + +Lowest Performance (RO) +........................ + +It is the absolute lowest performance level of the processor. Selecting a +performance level lower than the lowest nonlinear performance level may +cause an efficiency penalty but should reduce the instantaneous power +consumption of the processor. + +AMD CPPC Performance Control +------------------------------ + +``amd-pstate`` passes performance goals through these registers. The +register drives the behavior of the desired performance target. + +Minimum requested performance (RW) +................................... + +``amd-pstate`` specifies the minimum allowed performance level. + +Maximum requested performance (RW) +................................... + +``amd-pstate`` specifies a limit the maximum performance that is expected +to be supplied by the hardware. + +Desired performance target (RW) +................................... + +``amd-pstate`` specifies a desired target in the CPPC performance scale as +a relative number. This can be expressed as percentage of nominal +performance (infrastructure max). Below the nominal sustained performance +level, desired performance expresses the average performance level of the +processor subject to hardware. Above the nominal performance level, +processor must provide at least nominal performance requested and go higher +if current operating conditions allow. + +Energy Performance Preference (EPP) (RW) +......................................... + +Provides a hint to the hardware if software wants to bias toward performance +(0x0) or energy efficiency (0xff). + + +Key Governors Support +======================= + +``amd-pstate`` can be used with all the (generic) scaling governors listed +by the ``scaling_available_governors`` policy attribute in ``sysfs``. Then, +it is responsible for the configuration of policy objects corresponding to +CPUs and provides the ``CPUFreq`` core (and the scaling governors attached +to the policy objects) with accurate information on the maximum and minimum +operating frequencies supported by the hardware. Users can check the +``scaling_cur_freq`` information comes from the ``CPUFreq`` core. + +``amd-pstate`` mainly supports ``schedutil`` and ``ondemand`` for dynamic +frequency control. It is to fine tune the processor configuration on +``amd-pstate`` to the ``schedutil`` with CPU CFS scheduler. ``amd-pstate`` +registers adjust_perf callback to implement the CPPC similar performance +update behavior. It is initialized by ``sugov_start`` and then populate the +CPU's update_util_data pointer to assign ``sugov_update_single_perf`` as +the utilization update callback function in CPU scheduler. CPU scheduler +will call ``cpufreq_update_util`` and assign the target performance +according to the ``struct sugov_cpu`` that utilization update belongs to. +Then ``amd-pstate`` updates the desired performance according to the CPU +scheduler assigned. + + +Processor Support +======================= + +The ``amd-pstate`` initialization will fail if the _CPC in ACPI SBIOS is +not existed at the detected processor, and it uses ``acpi_cpc_valid`` to +check the _CPC existence. All Zen based processors support legacy ACPI +hardware P-States function, so while the ``amd-pstate`` fails to be +initialized, the kernel will fall back to initialize ``acpi-cpufreq`` +driver. + +There are two types of hardware implementations for ``amd-pstate``: one is +`Full MSR Support <perf_cap_>`_ and another is `Shared Memory Support +<perf_cap_>`_. It can use :c:macro:`X86_FEATURE_CPPC` feature flag (for +details refer to Processor Programming Reference (PPR) for AMD Family +19h Model 51h, Revision A1 Processors [3]_) to indicate the different +types. ``amd-pstate`` is to register different ``static_call`` instances +for different hardware implementations. + +Currently, some of Zen2 and Zen3 processors support ``amd-pstate``. In the +future, it will be supported on more and more AMD processors. + +Full MSR Support +----------------- + +Some new Zen3 processors such as Cezanne provide the MSR registers directly +while the :c:macro:`X86_FEATURE_CPPC` CPU feature flag is set. +``amd-pstate`` can handle the MSR register to implement the fast switch +function in ``CPUFreq`` that can shrink latency of frequency control on the +interrupt context. The functions with ``pstate_xxx`` prefix represent the +operations of MSR registers. + +Shared Memory Support +---------------------- + +If :c:macro:`X86_FEATURE_CPPC` CPU feature flag is not set, that means the +processor supports shared memory solution. In this case, ``amd-pstate`` +uses the ``cppc_acpi`` helper methods to implement the callback functions +that defined on ``static_call``. The functions with ``cppc_xxx`` prefix +represent the operations of acpi cppc helpers for shared memory solution. + + +AMD P-States and ACPI hardware P-States always can be supported in one +processor. But AMD P-States has the higher priority and if it is enabled +with :c:macro:`MSR_AMD_CPPC_ENABLE` or ``cppc_set_enable``, it will respond +to the request from AMD P-States. + + +User Space Interface in ``sysfs`` +================================== + +``amd-pstate`` exposes several global attributes (files) in ``sysfs`` to +control its functionality at the system level. They located in the +``/sys/devices/system/cpu/cpufreq/policyX/`` directory and affect all CPUs. :: + + root@hr-test1:/home/ray# ls /sys/devices/system/cpu/cpufreq/policy0/*amd* + /sys/devices/system/cpu/cpufreq/policy0/amd_pstate_highest_perf + /sys/devices/system/cpu/cpufreq/policy0/amd_pstate_lowest_nonlinear_freq + /sys/devices/system/cpu/cpufreq/policy0/amd_pstate_max_freq + + +``amd_pstate_highest_perf / amd_pstate_max_freq`` + +Maximum CPPC performance and CPU frequency that the driver is allowed to +set in percent of the maximum supported CPPC performance level (the highest +performance supported in `AMD CPPC Performance Capability <perf_cap_>`_). +In some of ASICs, the highest CPPC performance is not the one in the _CPC +table, so we need to expose it to sysfs. If boost is not active but +supported, this maximum frequency will be larger than the one in +``cpuinfo``. +This attribute is read-only. + +``amd_pstate_lowest_nonlinear_freq`` + +The lowest non-linear CPPC CPU frequency that the driver is allowed to set +in percent of the maximum supported CPPC performance level (Please see the +lowest non-linear performance in `AMD CPPC Performance Capability +<perf_cap_>`_). +This attribute is read-only. + +For other performance and frequency values, we can read them back from +``/sys/devices/system/cpu/cpuX/acpi_cppc/``, see :ref:`cppc_sysfs`. + + +``amd-pstate`` vs ``acpi-cpufreq`` +====================================== + +On majority of AMD platforms supported by ``acpi-cpufreq``, the ACPI tables +provided by the platform firmware used for CPU performance scaling, but +only provides 3 P-states on AMD processors. +However, on modern AMD APU and CPU series, it provides the collaborative +processor performance control according to ACPI protocol and customize this +for AMD platforms. That is fine-grain and continuous frequency range +instead of the legacy hardware P-states. ``amd-pstate`` is the kernel +module which supports the new AMD P-States mechanism on most of future AMD +platforms. The AMD P-States mechanism will be the more performance and energy +efficiency frequency management method on AMD processors. + +Kernel Module Options for ``amd-pstate`` +========================================= + +``shared_mem`` +Use a module param (shared_mem) to enable related processors manually with +**amd_pstate.shared_mem=1**. +Due to the performance issue on the processors with `Shared Memory Support +<perf_cap_>`_, so we disable it for the moment and will enable this by default +once we address performance issue on this solution. + +The way to check whether current processor is `Full MSR Support <perf_cap_>`_ +or `Shared Memory Support <perf_cap_>`_ : :: + + ray@hr-test1:~$ lscpu | grep cppc + Flags: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm constant_tsc rep_good nopl nonstop_tsc cpuid extd_apicid aperfmperf rapl pni pclmulqdq monitor ssse3 fma cx16 sse4_1 sse4_2 x2apic movbe popcnt aes xsave avx f16c rdrand lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw ibs skinit wdt tce topoext perfctr_core perfctr_nb bpext perfctr_llc mwaitx cpb cat_l3 cdp_l3 hw_pstate ssbd mba ibrs ibpb stibp vmmcall fsgsbase bmi1 avx2 smep bmi2 erms invpcid cqm rdt_a rdseed adx smap clflushopt clwb sha_ni xsaveopt xsavec xgetbv1 xsaves cqm_llc cqm_occup_llc cqm_mbm_total cqm_mbm_local clzero irperf xsaveerptr rdpru wbnoinvd cppc arat npt lbrv svm_lock nrip_save tsc_scale vmcb_clean flushbyasid decodeassists pausefilter pfthreshold avic v_vmsave_vmload vgif v_spec_ctrl umip pku ospke vaes vpclmulqdq rdpid overflow_recov succor smca fsrm + +If CPU Flags have cppc, then this processor supports `Full MSR Support +<perf_cap_>`_. Otherwise it supports `Shared Memory Support <perf_cap_>`_. + + +``cpupower`` tool support for ``amd-pstate`` +=============================================== + +``amd-pstate`` is supported on ``cpupower`` tool that can be used to dump the frequency +information. And it is in progress to support more and more operations for new +``amd-pstate`` module with this tool. :: + + root@hr-test1:/home/ray# cpupower frequency-info + analyzing CPU 0: + driver: amd-pstate + CPUs which run at the same hardware frequency: 0 + CPUs which need to have their frequency coordinated by software: 0 + maximum transition latency: 131 us + hardware limits: 400 MHz - 4.68 GHz + available cpufreq governors: ondemand conservative powersave userspace performance schedutil + current policy: frequency should be within 400 MHz and 4.68 GHz. + The governor "schedutil" may decide which speed to use + within this range. + current CPU frequency: Unable to call hardware + current CPU frequency: 4.02 GHz (asserted by call to kernel) + boost state support: + Supported: yes + Active: yes + AMD PSTATE Highest Performance: 166. Maximum Frequency: 4.68 GHz. + AMD PSTATE Nominal Performance: 117. Nominal Frequency: 3.30 GHz. + AMD PSTATE Lowest Non-linear Performance: 39. Lowest Non-linear Frequency: 1.10 GHz. + AMD PSTATE Lowest Performance: 15. Lowest Frequency: 400 MHz. + + +Diagnostics and Tuning +======================= + +Trace Events +-------------- + +There are two static trace events that can be used for ``amd-pstate`` +diagnostics. One of them is the cpu_frequency trace event generally used +by ``CPUFreq``, and the other one is the ``amd_pstate_perf`` trace event +specific to ``amd-pstate``. The following sequence of shell commands can +be used to enable them and see their output (if the kernel is generally +configured to support event tracing). :: + + root@hr-test1:/home/ray# cd /sys/kernel/tracing/ + root@hr-test1:/sys/kernel/tracing# echo 1 > events/amd_cpu/enable + root@hr-test1:/sys/kernel/tracing# cat trace + # tracer: nop + # + # entries-in-buffer/entries-written: 47827/42233061 #P:2 + # + # _-----=> irqs-off + # / _----=> need-resched + # | / _---=> hardirq/softirq + # || / _--=> preempt-depth + # ||| / delay + # TASK-PID CPU# |||| TIMESTAMP FUNCTION + # | | | |||| | | + <idle>-0 [015] dN... 4995.979886: amd_pstate_perf: amd_min_perf=85 amd_des_perf=85 amd_max_perf=166 cpu_id=15 changed=false fast_switch=true + <idle>-0 [007] d.h.. 4995.979893: amd_pstate_perf: amd_min_perf=85 amd_des_perf=85 amd_max_perf=166 cpu_id=7 changed=false fast_switch=true + cat-2161 [000] d.... 4995.980841: amd_pstate_perf: amd_min_perf=85 amd_des_perf=85 amd_max_perf=166 cpu_id=0 changed=false fast_switch=true + sshd-2125 [004] d.s.. 4995.980968: amd_pstate_perf: amd_min_perf=85 amd_des_perf=85 amd_max_perf=166 cpu_id=4 changed=false fast_switch=true + <idle>-0 [007] d.s.. 4995.980968: amd_pstate_perf: amd_min_perf=85 amd_des_perf=85 amd_max_perf=166 cpu_id=7 changed=false fast_switch=true + <idle>-0 [003] d.s.. 4995.980971: amd_pstate_perf: amd_min_perf=85 amd_des_perf=85 amd_max_perf=166 cpu_id=3 changed=false fast_switch=true + <idle>-0 [011] d.s.. 4995.980996: amd_pstate_perf: amd_min_perf=85 amd_des_perf=85 amd_max_perf=166 cpu_id=11 changed=false fast_switch=true + +The cpu_frequency trace event will be triggered either by the ``schedutil`` scaling +governor (for the policies it is attached to), or by the ``CPUFreq`` core (for the +policies with other scaling governors). + + +Reference +=========== + +.. [1] AMD64 Architecture Programmer's Manual Volume 2: System Programming, + https://www.amd.com/system/files/TechDocs/24593.pdf + +.. [2] Advanced Configuration and Power Interface Specification, + https://uefi.org/sites/default/files/resources/ACPI_Spec_6_4_Jan22.pdf + +.. [3] Processor Programming Reference (PPR) for AMD Family 19h Model 51h, Revision A1 Processors + https://www.amd.com/system/files/TechDocs/56569-A1-PUB.zip diff --git a/Documentation/admin-guide/pm/working-state.rst b/Documentation/admin-guide/pm/working-state.rst index f40994c422dc..5d2757e2de65 100644 --- a/Documentation/admin-guide/pm/working-state.rst +++ b/Documentation/admin-guide/pm/working-state.rst @@ -11,6 +11,7 @@ Working-State Power Management intel_idle cpufreq intel_pstate + amd-pstate cpufreq_drivers intel_epb intel-speed-select diff --git a/Documentation/admin-guide/sysctl/kernel.rst b/Documentation/admin-guide/sysctl/kernel.rst index 0e486f41185e..d359bcfadd39 100644 --- a/Documentation/admin-guide/sysctl/kernel.rst +++ b/Documentation/admin-guide/sysctl/kernel.rst @@ -905,6 +905,17 @@ enabled, otherwise writing to this file will return ``-EBUSY``. The default value is 8. +perf_user_access (arm64 only) +================================= + +Controls user space access for reading perf event counters. When set to 1, +user space can read performance monitor counter registers directly. + +The default value is 0 (access disabled). + +See Documentation/arm64/perf.rst for more information. + + pid_max ======= diff --git a/Documentation/admin-guide/sysctl/vm.rst b/Documentation/admin-guide/sysctl/vm.rst index 5e795202111f..f4804ce37c58 100644 --- a/Documentation/admin-guide/sysctl/vm.rst +++ b/Documentation/admin-guide/sysctl/vm.rst @@ -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 diff --git a/Documentation/arc/arc.rst b/Documentation/arc/arc.rst new file mode 100644 index 000000000000..6c4d978f3f4e --- /dev/null +++ b/Documentation/arc/arc.rst @@ -0,0 +1,85 @@ +.. SPDX-License-Identifier: GPL-2.0 + +Linux kernel for ARC processors +******************************* + +Other sources of information +############################ + +Below are some resources where more information can be found on +ARC processors and relevant open source projects. + +- `<https://embarc.org>`_ - Community portal for open source on ARC. + Good place to start to find relevant FOSS projects, toolchain releases, + news items and more. + +- `<https://github.com/foss-for-synopsys-dwc-arc-processors>`_ - + Home for all development activities regarding open source projects for + ARC processors. Some of the projects are forks of various upstream projects, + where "work in progress" is hosted prior to submission to upstream projects. + Other projects are developed by Synopsys and made available to community + as open source for use on ARC Processors. + +- `Official Synopsys ARC Processors website + <https://www.synopsys.com/designware-ip/processor-solutions.html>`_ - + location, with access to some IP documentation (`Programmer's Reference + Manual, AKA PRM for ARC HS processors + <https://www.synopsys.com/dw/doc.php/ds/cc/programmers-reference-manual-ARC-HS.pdf>`_) + and free versions of some commercial tools (`Free nSIM + <https://www.synopsys.com/cgi-bin/dwarcnsim/req1.cgi>`_ and + `MetaWare Light Edition <https://www.synopsys.com/cgi-bin/arcmwtk_lite/reg1.cgi>`_). + Please note though, registration is required to access both the documentation and + the tools. + +Important note on ARC processors configurability +################################################ + +ARC processors are highly configurable and several configurable options +are supported in Linux. Some options are transparent to software +(i.e cache geometries, some can be detected at runtime and configured +and used accordingly, while some need to be explicitly selected or configured +in the kernel's configuration utility (AKA "make menuconfig"). + +However not all configurable options are supported when an ARC processor +is to run Linux. SoC design teams should refer to "Appendix E: +Configuration for ARC Linux" in the ARC HS Databook for configurability +guidelines. + +Following these guidelines and selecting valid configuration options +up front is critical to help prevent any unwanted issues during +SoC bringup and software development in general. + +Building the Linux kernel for ARC processors +############################################ + +The process of kernel building for ARC processors is the same as for any other +architecture and could be done in 2 ways: + +- Cross-compilation: process of compiling for ARC targets on a development + host with a different processor architecture (generally x86_64/amd64). +- Native compilation: process of compiling for ARC on a ARC platform + (hardware board or a simulator like QEMU) with complete development environment + (GNU toolchain, dtc, make etc) installed on the platform. + +In both cases, up-to-date GNU toolchain for ARC for the host is needed. +Synopsys offers prebuilt toolchain releases which can be used for this purpose, +available from: + +- Synopsys GNU toolchain releases: + `<https://github.com/foss-for-synopsys-dwc-arc-processors/toolchain/releases>`_ + +- Linux kernel compilers collection: + `<https://mirrors.edge.kernel.org/pub/tools/crosstool>`_ + +- Bootlin's toolchain collection: `<https://toolchains.bootlin.com>`_ + +Once the toolchain is installed in the system, make sure its "bin" folder +is added in your ``PATH`` environment variable. Then set ``ARCH=arc`` & +``CROSS_COMPILE=arc-linux`` (or whatever matches installed ARC toolchain prefix) +and then as usual ``make defconfig && make``. + +This will produce "vmlinux" file in the root of the kernel source tree +usable for loading on the target system via JTAG. +If you need to get an image usable with U-Boot bootloader, +type ``make uImage`` and ``uImage`` will be produced in ``arch/arc/boot`` +folder. diff --git a/Documentation/arc/features.rst b/Documentation/arc/features.rst new file mode 100644 index 000000000000..b793583d688a --- /dev/null +++ b/Documentation/arc/features.rst @@ -0,0 +1,3 @@ +.. SPDX-License-Identifier: GPL-2.0 + +.. kernel-feat:: $srctree/Documentation/features arc diff --git a/Documentation/arc/index.rst b/Documentation/arc/index.rst new file mode 100644 index 000000000000..7b098d4a5e3e --- /dev/null +++ b/Documentation/arc/index.rst @@ -0,0 +1,17 @@ +=================== +ARC architecture +=================== + +.. toctree:: + :maxdepth: 1 + + arc + + features + +.. only:: subproject and html + + Indices + ======= + + * :ref:`genindex` diff --git a/Documentation/arch.rst b/Documentation/arch.rst index f10bd32a5972..14bcd8294b93 100644 --- a/Documentation/arch.rst +++ b/Documentation/arch.rst @@ -9,6 +9,7 @@ implementation. .. toctree:: :maxdepth: 2 + arc/index arm/index arm64/index ia64/index diff --git a/Documentation/arm/marvell.rst b/Documentation/arm/marvell.rst index 9485a5a2e2e9..2f41caa0096c 100644 --- a/Documentation/arm/marvell.rst +++ b/Documentation/arm/marvell.rst @@ -266,10 +266,12 @@ Avanta family ------------- Flavors: + - 88F6500 - 88F6510 - 88F6530P - 88F6550 - 88F6560 + - 88F6601 Homepage: https://web.archive.org/web/20181005145041/http://www.marvell.com/broadband/ diff --git a/Documentation/arm64/cpu-feature-registers.rst b/Documentation/arm64/cpu-feature-registers.rst index 9f9b8fd06089..749ae970c319 100644 --- a/Documentation/arm64/cpu-feature-registers.rst +++ b/Documentation/arm64/cpu-feature-registers.rst @@ -275,6 +275,23 @@ infrastructure: | SVEVer | [3-0] | y | +------------------------------+---------+---------+ + 8) ID_AA64MMFR1_EL1 - Memory model feature register 1 + + +------------------------------+---------+---------+ + | Name | bits | visible | + +------------------------------+---------+---------+ + | AFP | [47-44] | y | + +------------------------------+---------+---------+ + + 9) ID_AA64ISAR2_EL1 - Instruction set attribute register 2 + + +------------------------------+---------+---------+ + | Name | bits | visible | + +------------------------------+---------+---------+ + | RPRES | [7-4] | y | + +------------------------------+---------+---------+ + + Appendix I: Example ------------------- diff --git a/Documentation/arm64/elf_hwcaps.rst b/Documentation/arm64/elf_hwcaps.rst index af106af8e1c0..b72ff17d600a 100644 --- a/Documentation/arm64/elf_hwcaps.rst +++ b/Documentation/arm64/elf_hwcaps.rst @@ -251,6 +251,14 @@ HWCAP2_ECV Functionality implied by ID_AA64MMFR0_EL1.ECV == 0b0001. +HWCAP2_AFP + + Functionality implied by ID_AA64MFR1_EL1.AFP == 0b0001. + +HWCAP2_RPRES + + Functionality implied by ID_AA64ISAR2_EL1.RPRES == 0b0001. + 4. Unused AT_HWCAP bits ----------------------- diff --git a/Documentation/arm64/perf.rst b/Documentation/arm64/perf.rst index b567f177d385..1f87b57c2332 100644 --- a/Documentation/arm64/perf.rst +++ b/Documentation/arm64/perf.rst @@ -2,7 +2,10 @@ .. _perf_index: -===================== +==== +Perf +==== + Perf Event Attributes ===================== @@ -88,3 +91,76 @@ exclude_host. However when using !exclude_hv there is a small blackout window at the guest entry/exit where host events are not captured. On VHE systems there are no blackout windows. + +Perf Userspace PMU Hardware Counter Access +========================================== + +Overview +-------- +The perf userspace tool relies on the PMU to monitor events. It offers an +abstraction layer over the hardware counters since the underlying +implementation is cpu-dependent. +Arm64 allows userspace tools to have access to the registers storing the +hardware counters' values directly. + +This targets specifically self-monitoring tasks in order to reduce the overhead +by directly accessing the registers without having to go through the kernel. + +How-to +------ +The focus is set on the armv8 PMUv3 which makes sure that the access to the pmu +registers is enabled and that the userspace has access to the relevant +information in order to use them. + +In order to have access to the hardware counters, the global sysctl +kernel/perf_user_access must first be enabled: + +.. code-block:: sh + + echo 1 > /proc/sys/kernel/perf_user_access + +It is necessary to open the event using the perf tool interface with config1:1 +attr bit set: the sys_perf_event_open syscall returns a fd which can +subsequently be used with the mmap syscall in order to retrieve a page of memory +containing information about the event. The PMU driver uses this page to expose +to the user the hardware counter's index and other necessary data. Using this +index enables the user to access the PMU registers using the `mrs` instruction. +Access to the PMU registers is only valid while the sequence lock is unchanged. +In particular, the PMSELR_EL0 register is zeroed each time the sequence lock is +changed. + +The userspace access is supported in libperf using the perf_evsel__mmap() +and perf_evsel__read() functions. See `tools/lib/perf/tests/test-evsel.c`_ for +an example. + +About heterogeneous systems +--------------------------- +On heterogeneous systems such as big.LITTLE, userspace PMU counter access can +only be enabled when the tasks are pinned to a homogeneous subset of cores and +the corresponding PMU instance is opened by specifying the 'type' attribute. +The use of generic event types is not supported in this case. + +Have a look at `tools/perf/arch/arm64/tests/user-events.c`_ for an example. It +can be run using the perf tool to check that the access to the registers works +correctly from userspace: + +.. code-block:: sh + + perf test -v user + +About chained events and counter sizes +-------------------------------------- +The user can request either a 32-bit (config1:0 == 0) or 64-bit (config1:0 == 1) +counter along with userspace access. The sys_perf_event_open syscall will fail +if a 64-bit counter is requested and the hardware doesn't support 64-bit +counters. Chained events are not supported in conjunction with userspace counter +access. If a 32-bit counter is requested on hardware with 64-bit counters, then +userspace must treat the upper 32-bits read from the counter as UNKNOWN. The +'pmc_width' field in the user page will indicate the valid width of the counter +and should be used to mask the upper bits as needed. + +.. Links +.. _tools/perf/arch/arm64/tests/user-events.c: + https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/tools/perf/arch/arm64/tests/user-events.c +.. _tools/lib/perf/tests/test-evsel.c: + https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/tools/lib/perf/tests/test-evsel.c diff --git a/Documentation/arm64/pointer-authentication.rst b/Documentation/arm64/pointer-authentication.rst index f127666ea3a8..e5dad2e40aa8 100644 --- a/Documentation/arm64/pointer-authentication.rst +++ b/Documentation/arm64/pointer-authentication.rst @@ -53,11 +53,10 @@ The number of bits that the PAC occupies in a pointer is 55 minus the virtual address size configured by the kernel. For example, with a virtual address size of 48, the PAC is 7 bits wide. -Recent versions of GCC can compile code with APIAKey-based return -address protection when passed the -msign-return-address option. This -uses instructions in the HINT space (unless -march=armv8.3-a or higher -is also passed), and such code can run on systems without the pointer -authentication extension. +When ARM64_PTR_AUTH_KERNEL is selected, the kernel will be compiled +with HINT space pointer authentication instructions protecting +function returns. Kernels built with this option will work on hardware +with or without pointer authentication support. In addition to exec(), keys can also be reinitialized to random values using the PR_PAC_RESET_KEYS prctl. A bitmask of PR_PAC_APIAKEY, diff --git a/Documentation/arm64/silicon-errata.rst b/Documentation/arm64/silicon-errata.rst index 5342e895fb60..0ec7b7f1524b 100644 --- a/Documentation/arm64/silicon-errata.rst +++ b/Documentation/arm64/silicon-errata.rst @@ -52,6 +52,12 @@ stable kernels. | Allwinner | A64/R18 | UNKNOWN1 | SUN50I_ERRATUM_UNKNOWN1 | +----------------+-----------------+-----------------+-----------------------------+ +----------------+-----------------+-----------------+-----------------------------+ +| ARM | Cortex-A510 | #2064142 | ARM64_ERRATUM_2064142 | ++----------------+-----------------+-----------------+-----------------------------+ +| ARM | Cortex-A510 | #2038923 | ARM64_ERRATUM_2038923 | ++----------------+-----------------+-----------------+-----------------------------+ +| ARM | Cortex-A510 | #1902691 | ARM64_ERRATUM_1902691 | ++----------------+-----------------+-----------------+-----------------------------+ | ARM | Cortex-A53 | #826319 | ARM64_ERRATUM_826319 | +----------------+-----------------+-----------------+-----------------------------+ | ARM | Cortex-A53 | #827319 | ARM64_ERRATUM_827319 | @@ -92,12 +98,18 @@ stable kernels. +----------------+-----------------+-----------------+-----------------------------+ | ARM | Cortex-A77 | #1508412 | ARM64_ERRATUM_1508412 | +----------------+-----------------+-----------------+-----------------------------+ +| ARM | Cortex-A510 | #2051678 | ARM64_ERRATUM_2051678 | ++----------------+-----------------+-----------------+-----------------------------+ | ARM | Cortex-A710 | #2119858 | ARM64_ERRATUM_2119858 | +----------------+-----------------+-----------------+-----------------------------+ | ARM | Cortex-A710 | #2054223 | ARM64_ERRATUM_2054223 | +----------------+-----------------+-----------------+-----------------------------+ | ARM | Cortex-A710 | #2224489 | ARM64_ERRATUM_2224489 | +----------------+-----------------+-----------------+-----------------------------+ +| ARM | Cortex-X2 | #2119858 | ARM64_ERRATUM_2119858 | ++----------------+-----------------+-----------------+-----------------------------+ +| ARM | Cortex-X2 | #2224489 | ARM64_ERRATUM_2224489 | ++----------------+-----------------+-----------------+-----------------------------+ | ARM | Neoverse-N1 | #1188873,1418040| ARM64_ERRATUM_1418040 | +----------------+-----------------+-----------------+-----------------------------+ | ARM | Neoverse-N1 | #1349291 | N/A | diff --git a/Documentation/arm64/sve.rst b/Documentation/arm64/sve.rst index 03137154299e..9d9a4de5bc34 100644 --- a/Documentation/arm64/sve.rst +++ b/Documentation/arm64/sve.rst @@ -255,7 +255,7 @@ prctl(PR_SVE_GET_VL) vector length change (which would only normally be the case between a fork() or vfork() and the corresponding execve() in typical use). - To extract the vector length from the result, and it with + To extract the vector length from the result, bitwise and it with PR_SVE_VL_LEN_MASK. Return value: a nonnegative value on success, or a negative value on error: diff --git a/Documentation/arm64/tagged-address-abi.rst b/Documentation/arm64/tagged-address-abi.rst index 0c9120ec58ae..540a1d4fc6c9 100644 --- a/Documentation/arm64/tagged-address-abi.rst +++ b/Documentation/arm64/tagged-address-abi.rst @@ -49,7 +49,7 @@ how the user addresses are used by the kernel: - ``brk()``, ``mmap()`` and the ``new_address`` argument to ``mremap()`` as these have the potential to alias with existing - user addresses. + user addresses. NOTE: This behaviour changed in v5.6 and so some earlier kernels may incorrectly accept valid tagged pointers for the ``brk()``, diff --git a/Documentation/block/index.rst b/Documentation/block/index.rst index 86dcf7159f99..3a41495dd77b 100644 --- a/Documentation/block/index.rst +++ b/Documentation/block/index.rst @@ -20,7 +20,6 @@ Block kyber-iosched null_blk pr - queue-sysfs request stat switching-sched diff --git a/Documentation/block/queue-sysfs.rst b/Documentation/block/queue-sysfs.rst deleted file mode 100644 index 3f569d532485..000000000000 --- a/Documentation/block/queue-sysfs.rst +++ /dev/null @@ -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 diff --git a/Documentation/bpf/btf.rst b/Documentation/bpf/btf.rst index 9ad4218a751f..1ebf4c5c7ddc 100644 --- a/Documentation/bpf/btf.rst +++ b/Documentation/bpf/btf.rst @@ -3,7 +3,7 @@ BPF Type Format (BTF) ===================== 1. Introduction -*************** +=============== BTF (BPF Type Format) is the metadata format which encodes the debug info related to BPF program/map. The name BTF was used initially to describe data @@ -30,7 +30,7 @@ sections are discussed in details in :ref:`BTF_Type_String`. .. _BTF_Type_String: 2. BTF Type and String Encoding -******************************* +=============================== The file ``include/uapi/linux/btf.h`` provides high-level definition of how types/strings are encoded. @@ -57,13 +57,13 @@ little-endian target. The ``btf_header`` is designed to be extensible with generated. 2.1 String Encoding -=================== +------------------- The first string in the string section must be a null string. The rest of string table is a concatenation of other null-terminated strings. 2.2 Type Encoding -================= +----------------- The type id ``0`` is reserved for ``void`` type. The type section is parsed sequentially and type id is assigned to each recognized type starting from id @@ -86,6 +86,7 @@ sequentially and type id is assigned to each recognized type starting from id #define BTF_KIND_DATASEC 15 /* Section */ #define BTF_KIND_FLOAT 16 /* Floating point */ #define BTF_KIND_DECL_TAG 17 /* Decl Tag */ + #define BTF_KIND_TYPE_TAG 18 /* Type Tag */ Note that the type section encodes debug info, not just pure types. ``BTF_KIND_FUNC`` is not a type, and it represents a defined subprogram. @@ -107,7 +108,7 @@ Each type contains the following common data:: * "size" tells the size of the type it is describing. * * "type" is used by PTR, TYPEDEF, VOLATILE, CONST, RESTRICT, - * FUNC, FUNC_PROTO and DECL_TAG. + * FUNC, FUNC_PROTO, DECL_TAG and TYPE_TAG. * "type" is a type_id referring to another type. */ union { @@ -492,8 +493,18 @@ the attribute is applied to a ``struct``/``union`` member or a ``func`` argument, and ``btf_decl_tag.component_idx`` should be a valid index (starting from 0) pointing to a member or an argument. +2.2.17 BTF_KIND_TYPE_TAG +~~~~~~~~~~~~~~~~~~~~~~~~ + +``struct btf_type`` encoding requirement: + * ``name_off``: offset to a non-empty string + * ``info.kind_flag``: 0 + * ``info.kind``: BTF_KIND_TYPE_TAG + * ``info.vlen``: 0 + * ``type``: the type with ``btf_type_tag`` attribute + 3. BTF Kernel API -***************** +================= The following bpf syscall command involves BTF: * BPF_BTF_LOAD: load a blob of BTF data into kernel @@ -536,14 +547,14 @@ The workflow typically looks like: 3.1 BPF_BTF_LOAD -================ +---------------- Load a blob of BTF data into kernel. A blob of data, described in :ref:`BTF_Type_String`, can be directly loaded into the kernel. A ``btf_fd`` is returned to a userspace. 3.2 BPF_MAP_CREATE -================== +------------------ A map can be created with ``btf_fd`` and specified key/value type id.:: @@ -570,7 +581,7 @@ automatically. .. _BPF_Prog_Load: 3.3 BPF_PROG_LOAD -================= +----------------- During prog_load, func_info and line_info can be passed to kernel with proper values for the following attributes: @@ -620,7 +631,7 @@ For line_info, the line number and column number are defined as below: #define BPF_LINE_INFO_LINE_COL(line_col) ((line_col) & 0x3ff) 3.4 BPF_{PROG,MAP}_GET_NEXT_ID -============================== +------------------------------ In kernel, every loaded program, map or btf has a unique id. The id won't change during the lifetime of a program, map, or btf. @@ -630,13 +641,13 @@ each command, to user space, for bpf program or maps, respectively, so an inspection tool can inspect all programs and maps. 3.5 BPF_{PROG,MAP}_GET_FD_BY_ID -=============================== +------------------------------- An introspection tool cannot use id to get details about program or maps. A file descriptor needs to be obtained first for reference-counting purpose. 3.6 BPF_OBJ_GET_INFO_BY_FD -========================== +-------------------------- Once a program/map fd is acquired, an introspection tool can get the detailed information from kernel about this fd, some of which are BTF-related. For @@ -645,7 +656,7 @@ example, ``bpf_map_info`` returns ``btf_id`` and key/value type ids. bpf byte codes, and jited_line_info. 3.7 BPF_BTF_GET_FD_BY_ID -======================== +------------------------ With ``btf_id`` obtained in ``bpf_map_info`` and ``bpf_prog_info``, bpf syscall command BPF_BTF_GET_FD_BY_ID can retrieve a btf fd. Then, with @@ -657,10 +668,10 @@ tool has full btf knowledge and is able to pretty print map key/values, dump func signatures and line info, along with byte/jit codes. 4. ELF File Format Interface -**************************** +============================ 4.1 .BTF section -================ +---------------- The .BTF section contains type and string data. The format of this section is same as the one describe in :ref:`BTF_Type_String`. @@ -668,7 +679,7 @@ same as the one describe in :ref:`BTF_Type_String`. .. _BTF_Ext_Section: 4.2 .BTF.ext section -==================== +-------------------- The .BTF.ext section encodes func_info and line_info which needs loader manipulation before loading into the kernel. @@ -732,7 +743,7 @@ bpf_insn``. For ELF API, the ``insn_off`` is the byte offset from the beginning of section (``btf_ext_info_sec->sec_name_off``). 4.2 .BTF_ids section -==================== +-------------------- The .BTF_ids section encodes BTF ID values that are used within the kernel. @@ -793,10 +804,10 @@ All the BTF ID lists and sets are compiled in the .BTF_ids section and resolved during the linking phase of kernel build by ``resolve_btfids`` tool. 5. Using BTF -************ +============ 5.1 bpftool map pretty print -============================ +---------------------------- With BTF, the map key/value can be printed based on fields rather than simply raw bytes. This is especially valuable for large structure or if your data @@ -838,7 +849,7 @@ bpftool is able to pretty print like below: ] 5.2 bpftool prog dump -===================== +--------------------- The following is an example showing how func_info and line_info can help prog dump with better kernel symbol names, function prototypes and line @@ -872,7 +883,7 @@ information.:: [...] 5.3 Verifier Log -================ +---------------- The following is an example of how line_info can help debugging verification failure.:: @@ -898,7 +909,7 @@ failure.:: R2 offset is outside of the packet 6. BTF Generation -***************** +================= You need latest pahole @@ -1005,6 +1016,6 @@ format.:: .long 8206 # Line 8 Col 14 7. Testing -********** +========== Kernel bpf selftest `test_btf.c` provides extensive set of BTF-related tests. diff --git a/Documentation/bpf/classic_vs_extended.rst b/Documentation/bpf/classic_vs_extended.rst new file mode 100644 index 000000000000..2f81a81f5267 --- /dev/null +++ b/Documentation/bpf/classic_vs_extended.rst @@ -0,0 +1,376 @@ + +=================== +Classic BPF vs eBPF +=================== + +eBPF is designed to be JITed with one to one mapping, which can also open up +the possibility for GCC/LLVM compilers to generate optimized eBPF code through +an eBPF backend that performs almost as fast as natively compiled code. + +Some core changes of the eBPF format from classic BPF: + +- Number of registers increase from 2 to 10: + + The old format had two registers A and X, and a hidden frame pointer. The + new layout extends this to be 10 internal registers and a read-only frame + pointer. Since 64-bit CPUs are passing arguments to functions via registers + the number of args from eBPF program to in-kernel function is restricted + to 5 and one register is used to accept return value from an in-kernel + function. Natively, x86_64 passes first 6 arguments in registers, aarch64/ + sparcv9/mips64 have 7 - 8 registers for arguments; x86_64 has 6 callee saved + registers, and aarch64/sparcv9/mips64 have 11 or more callee saved registers. + + Thus, all eBPF registers map one to one to HW registers on x86_64, aarch64, + etc, and eBPF calling convention maps directly to ABIs used by the kernel on + 64-bit architectures. + + On 32-bit architectures JIT may map programs that use only 32-bit arithmetic + and may let more complex programs to be interpreted. + + R0 - R5 are scratch registers and eBPF program needs spill/fill them if + necessary across calls. Note that there is only one eBPF program (== one + eBPF main routine) and it cannot call other eBPF functions, it can only + call predefined in-kernel functions, though. + +- Register width increases from 32-bit to 64-bit: + + Still, the semantics of the original 32-bit ALU operations are preserved + via 32-bit subregisters. All eBPF registers are 64-bit with 32-bit lower + subregisters that zero-extend into 64-bit if they are being written to. + That behavior maps directly to x86_64 and arm64 subregister definition, but + makes other JITs more difficult. + + 32-bit architectures run 64-bit eBPF programs via interpreter. + Their JITs may convert BPF programs that only use 32-bit subregisters into + native instruction set and let the rest being interpreted. + + Operation is 64-bit, because on 64-bit architectures, pointers are also + 64-bit wide, and we want to pass 64-bit values in/out of kernel functions, + so 32-bit eBPF registers would otherwise require to define register-pair + ABI, thus, there won't be able to use a direct eBPF register to HW register + mapping and JIT would need to do combine/split/move operations for every + register in and out of the function, which is complex, bug prone and slow. + Another reason is the use of atomic 64-bit counters. + +- Conditional jt/jf targets replaced with jt/fall-through: + + While the original design has constructs such as ``if (cond) jump_true; + else jump_false;``, they are being replaced into alternative constructs like + ``if (cond) jump_true; /* else fall-through */``. + +- Introduces bpf_call insn and register passing convention for zero overhead + calls from/to other kernel functions: + + Before an in-kernel function call, the eBPF program needs to + place function arguments into R1 to R5 registers to satisfy calling + convention, then the interpreter will take them from registers and pass + to in-kernel function. If R1 - R5 registers are mapped to CPU registers + that are used for argument passing on given architecture, the JIT compiler + doesn't need to emit extra moves. Function arguments will be in the correct + registers and BPF_CALL instruction will be JITed as single 'call' HW + instruction. This calling convention was picked to cover common call + situations without performance penalty. + + After an in-kernel function call, R1 - R5 are reset to unreadable and R0 has + a return value of the function. Since R6 - R9 are callee saved, their state + is preserved across the call. + + For example, consider three C functions:: + + u64 f1() { return (*_f2)(1); } + u64 f2(u64 a) { return f3(a + 1, a); } + u64 f3(u64 a, u64 b) { return a - b; } + + GCC can compile f1, f3 into x86_64:: + + f1: + movl $1, %edi + movq _f2(%rip), %rax + jmp *%rax + f3: + movq %rdi, %rax + subq %rsi, %rax + ret + + Function f2 in eBPF may look like:: + + f2: + bpf_mov R2, R1 + bpf_add R1, 1 + bpf_call f3 + bpf_exit + + If f2 is JITed and the pointer stored to ``_f2``. The calls f1 -> f2 -> f3 and + returns will be seamless. Without JIT, __bpf_prog_run() interpreter needs to + be used to call into f2. + + For practical reasons all eBPF programs have only one argument 'ctx' which is + already placed into R1 (e.g. on __bpf_prog_run() startup) and the programs + can call kernel functions with up to 5 arguments. Calls with 6 or more arguments + are currently not supported, but these restrictions can be lifted if necessary + in the future. + + On 64-bit architectures all register map to HW registers one to one. For + example, x86_64 JIT compiler can map them as ... + + :: + + R0 - rax + R1 - rdi + R2 - rsi + R3 - rdx + R4 - rcx + R5 - r8 + R6 - rbx + R7 - r13 + R8 - r14 + R9 - r15 + R10 - rbp + + ... since x86_64 ABI mandates rdi, rsi, rdx, rcx, r8, r9 for argument passing + and rbx, r12 - r15 are callee saved. + + Then the following eBPF pseudo-program:: + + bpf_mov R6, R1 /* save ctx */ + bpf_mov R2, 2 + bpf_mov R3, 3 + bpf_mov R4, 4 + bpf_mov R5, 5 + bpf_call foo + bpf_mov R7, R0 /* save foo() return value */ + bpf_mov R1, R6 /* restore ctx for next call */ + bpf_mov R2, 6 + bpf_mov R3, 7 + bpf_mov R4, 8 + bpf_mov R5, 9 + bpf_call bar + bpf_add R0, R7 + bpf_exit + + After JIT to x86_64 may look like:: + + push %rbp + mov %rsp,%rbp + sub $0x228,%rsp + mov %rbx,-0x228(%rbp) + mov %r13,-0x220(%rbp) + mov %rdi,%rbx + mov $0x2,%esi + mov $0x3,%edx + mov $0x4,%ecx + mov $0x5,%r8d + callq foo + mov %rax,%r13 + mov %rbx,%rdi + mov $0x6,%esi + mov $0x7,%edx + mov $0x8,%ecx + mov $0x9,%r8d + callq bar + add %r13,%rax + mov -0x228(%rbp),%rbx + mov -0x220(%rbp),%r13 + leaveq + retq + + Which is in this example equivalent in C to:: + + u64 bpf_filter(u64 ctx) + { + return foo(ctx, 2, 3, 4, 5) + bar(ctx, 6, 7, 8, 9); + } + + In-kernel functions foo() and bar() with prototype: u64 (*)(u64 arg1, u64 + arg2, u64 arg3, u64 arg4, u64 arg5); will receive arguments in proper + registers and place their return value into ``%rax`` which is R0 in eBPF. + Prologue and epilogue are emitted by JIT and are implicit in the + interpreter. R0-R5 are scratch registers, so eBPF program needs to preserve + them across the calls as defined by calling convention. + + For example the following program is invalid:: + + bpf_mov R1, 1 + bpf_call foo + bpf_mov R0, R1 + bpf_exit + + After the call the registers R1-R5 contain junk values and cannot be read. + An in-kernel verifier.rst is used to validate eBPF programs. + +Also in the new design, eBPF is limited to 4096 insns, which means that any +program will terminate quickly and will only call a fixed number of kernel +functions. Original BPF and eBPF are two operand instructions, +which helps to do one-to-one mapping between eBPF insn and x86 insn during JIT. + +The input context pointer for invoking the interpreter function is generic, +its content is defined by a specific use case. For seccomp register R1 points +to seccomp_data, for converted BPF filters R1 points to a skb. + +A program, that is translated internally consists of the following elements:: + + op:16, jt:8, jf:8, k:32 ==> op:8, dst_reg:4, src_reg:4, off:16, imm:32 + +So far 87 eBPF instructions were implemented. 8-bit 'op' opcode field +has room for new instructions. Some of them may use 16/24/32 byte encoding. New +instructions must be multiple of 8 bytes to preserve backward compatibility. + +eBPF is a general purpose RISC instruction set. Not every register and +every instruction are used during translation from original BPF to eBPF. +For example, socket filters are not using ``exclusive add`` instruction, but +tracing filters may do to maintain counters of events, for example. Register R9 +is not used by socket filters either, but more complex filters may be running +out of registers and would have to resort to spill/fill to stack. + +eBPF can be used as a generic assembler for last step performance +optimizations, socket filters and seccomp are using it as assembler. Tracing +filters may use it as assembler to generate code from kernel. In kernel usage +may not be bounded by security considerations, since generated eBPF code +may be optimizing internal code path and not being exposed to the user space. +Safety of eBPF can come from the verifier.rst. In such use cases as +described, it may be used as safe instruction set. + +Just like the original BPF, eBPF runs within a controlled environment, +is deterministic and the kernel can easily prove that. The safety of the program +can be determined in two steps: first step does depth-first-search to disallow +loops and other CFG validation; second step starts from the first insn and +descends all possible paths. It simulates execution of every insn and observes +the state change of registers and stack. + +opcode encoding +=============== + +eBPF is reusing most of the opcode encoding from classic to simplify conversion +of classic BPF to eBPF. + +For arithmetic and jump instructions the 8-bit 'code' field is divided into three +parts:: + + +----------------+--------+--------------------+ + | 4 bits | 1 bit | 3 bits | + | operation code | source | instruction class | + +----------------+--------+--------------------+ + (MSB) (LSB) + +Three LSB bits store instruction class which is one of: + + =================== =============== + Classic BPF classes eBPF classes + =================== =============== + BPF_LD 0x00 BPF_LD 0x00 + BPF_LDX 0x01 BPF_LDX 0x01 + BPF_ST 0x02 BPF_ST 0x02 + BPF_STX 0x03 BPF_STX 0x03 + BPF_ALU 0x04 BPF_ALU 0x04 + BPF_JMP 0x05 BPF_JMP 0x05 + BPF_RET 0x06 BPF_JMP32 0x06 + BPF_MISC 0x07 BPF_ALU64 0x07 + =================== =============== + +The 4th bit encodes the source operand ... + + :: + + BPF_K 0x00 + BPF_X 0x08 + + * in classic BPF, this means:: + + BPF_SRC(code) == BPF_X - use register X as source operand + BPF_SRC(code) == BPF_K - use 32-bit immediate as source operand + + * in eBPF, this means:: + + BPF_SRC(code) == BPF_X - use 'src_reg' register as source operand + BPF_SRC(code) == BPF_K - use 32-bit immediate as source operand + +... and four MSB bits store operation code. + +If BPF_CLASS(code) == BPF_ALU or BPF_ALU64 [ in eBPF ], BPF_OP(code) is one of:: + + BPF_ADD 0x00 + BPF_SUB 0x10 + BPF_MUL 0x20 + BPF_DIV 0x30 + BPF_OR 0x40 + BPF_AND 0x50 + BPF_LSH 0x60 + BPF_RSH 0x70 + BPF_NEG 0x80 + BPF_MOD 0x90 + BPF_XOR 0xa0 + BPF_MOV 0xb0 /* eBPF only: mov reg to reg */ + BPF_ARSH 0xc0 /* eBPF only: sign extending shift right */ + BPF_END 0xd0 /* eBPF only: endianness conversion */ + +If BPF_CLASS(code) == BPF_JMP or BPF_JMP32 [ in eBPF ], BPF_OP(code) is one of:: + + BPF_JA 0x00 /* BPF_JMP only */ + BPF_JEQ 0x10 + BPF_JGT 0x20 + BPF_JGE 0x30 + BPF_JSET 0x40 + BPF_JNE 0x50 /* eBPF only: jump != */ + BPF_JSGT 0x60 /* eBPF only: signed '>' */ + BPF_JSGE 0x70 /* eBPF only: signed '>=' */ + BPF_CALL 0x80 /* eBPF BPF_JMP only: function call */ + BPF_EXIT 0x90 /* eBPF BPF_JMP only: function return */ + BPF_JLT 0xa0 /* eBPF only: unsigned '<' */ + BPF_JLE 0xb0 /* eBPF only: unsigned '<=' */ + BPF_JSLT 0xc0 /* eBPF only: signed '<' */ + BPF_JSLE 0xd0 /* eBPF only: signed '<=' */ + +So BPF_ADD | BPF_X | BPF_ALU means 32-bit addition in both classic BPF +and eBPF. There are only two registers in classic BPF, so it means A += X. +In eBPF it means dst_reg = (u32) dst_reg + (u32) src_reg; similarly, +BPF_XOR | BPF_K | BPF_ALU means A ^= imm32 in classic BPF and analogous +src_reg = (u32) src_reg ^ (u32) imm32 in eBPF. + +Classic BPF is using BPF_MISC class to represent A = X and X = A moves. +eBPF is using BPF_MOV | BPF_X | BPF_ALU code instead. Since there are no +BPF_MISC operations in eBPF, the class 7 is used as BPF_ALU64 to mean +exactly the same operations as BPF_ALU, but with 64-bit wide operands +instead. So BPF_ADD | BPF_X | BPF_ALU64 means 64-bit addition, i.e.: +dst_reg = dst_reg + src_reg + +Classic BPF wastes the whole BPF_RET class to represent a single ``ret`` +operation. Classic BPF_RET | BPF_K means copy imm32 into return register +and perform function exit. eBPF is modeled to match CPU, so BPF_JMP | BPF_EXIT +in eBPF means function exit only. The eBPF program needs to store return +value into register R0 before doing a BPF_EXIT. Class 6 in eBPF is used as +BPF_JMP32 to mean exactly the same operations as BPF_JMP, but with 32-bit wide +operands for the comparisons instead. + +For load and store instructions the 8-bit 'code' field is divided as:: + + +--------+--------+-------------------+ + | 3 bits | 2 bits | 3 bits | + | mode | size | instruction class | + +--------+--------+-------------------+ + (MSB) (LSB) + +Size modifier is one of ... + +:: + + BPF_W 0x00 /* word */ + BPF_H 0x08 /* half word */ + BPF_B 0x10 /* byte */ + BPF_DW 0x18 /* eBPF only, double word */ + +... which encodes size of load/store operation:: + + B - 1 byte + H - 2 byte + W - 4 byte + DW - 8 byte (eBPF only) + +Mode modifier is one of:: + + BPF_IMM 0x00 /* used for 32-bit mov in classic BPF and 64-bit in eBPF */ + BPF_ABS 0x20 + BPF_IND 0x40 + BPF_MEM 0x60 + BPF_LEN 0x80 /* classic BPF only, reserved in eBPF */ + BPF_MSH 0xa0 /* classic BPF only, reserved in eBPF */ + BPF_ATOMIC 0xc0 /* eBPF only, atomic operations */ diff --git a/Documentation/bpf/faq.rst b/Documentation/bpf/faq.rst new file mode 100644 index 000000000000..a622602ce9ad --- /dev/null +++ b/Documentation/bpf/faq.rst @@ -0,0 +1,11 @@ +================================ +Frequently asked questions (FAQ) +================================ + +Two sets of Questions and Answers (Q&A) are maintained. + +.. toctree:: + :maxdepth: 1 + + bpf_design_QA + bpf_devel_QA diff --git a/Documentation/bpf/helpers.rst b/Documentation/bpf/helpers.rst new file mode 100644 index 000000000000..c4ee0cc20dec --- /dev/null +++ b/Documentation/bpf/helpers.rst @@ -0,0 +1,7 @@ +Helper functions +================ + +* `bpf-helpers(7)`_ maintains a list of helpers available to eBPF programs. + +.. Links +.. _bpf-helpers(7): https://man7.org/linux/man-pages/man7/bpf-helpers.7.html
\ No newline at end of file diff --git a/Documentation/bpf/index.rst b/Documentation/bpf/index.rst index 610450f59e05..ef5c996547ec 100644 --- a/Documentation/bpf/index.rst +++ b/Documentation/bpf/index.rst @@ -5,104 +5,33 @@ BPF Documentation This directory contains documentation for the BPF (Berkeley Packet Filter) facility, with a focus on the extended BPF version (eBPF). -This kernel side documentation is still work in progress. The main -textual documentation is (for historical reasons) described in -:ref:`networking-filter`, which describe both classical and extended -BPF instruction-set. +This kernel side documentation is still work in progress. The Cilium project also maintains a `BPF and XDP Reference Guide`_ that goes into great technical depth about the BPF Architecture. -libbpf -====== - -Documentation/bpf/libbpf/index.rst is a userspace library for loading and interacting with bpf programs. - -BPF Type Format (BTF) -===================== - .. toctree:: :maxdepth: 1 + instruction-set + verifier + libbpf/index btf - - -Frequently asked questions (FAQ) -================================ - -Two sets of Questions and Answers (Q&A) are maintained. - -.. toctree:: - :maxdepth: 1 - - bpf_design_QA - bpf_devel_QA - -Syscall API -=========== - -The primary info for the bpf syscall is available in the `man-pages`_ -for `bpf(2)`_. For more information about the userspace API, see -Documentation/userspace-api/ebpf/index.rst. - -Helper functions -================ - -* `bpf-helpers(7)`_ maintains a list of helpers available to eBPF programs. - - -Program types -============= - -.. toctree:: - :maxdepth: 1 - - prog_cgroup_sockopt - prog_cgroup_sysctl - prog_flow_dissector - bpf_lsm - prog_sk_lookup - - -Map types -========= - -.. toctree:: - :maxdepth: 1 - - map_cgroup_storage - - -Testing and debugging BPF -========================= - -.. toctree:: - :maxdepth: 1 - - drgn - s390 - - -Licensing -========= - -.. toctree:: - :maxdepth: 1 - + faq + syscall_api + helpers + programs + maps + classic_vs_extended.rst bpf_licensing + test_debug + other +.. only:: subproject and html -Other -===== - -.. toctree:: - :maxdepth: 1 + Indices + ======= - ringbuf - llvm_reloc + * :ref:`genindex` .. Links: -.. _networking-filter: ../networking/filter.rst -.. _man-pages: https://www.kernel.org/doc/man-pages/ -.. _bpf(2): https://man7.org/linux/man-pages/man2/bpf.2.html -.. _bpf-helpers(7): https://man7.org/linux/man-pages/man7/bpf-helpers.7.html .. _BPF and XDP Reference Guide: https://docs.cilium.io/en/latest/bpf/ diff --git a/Documentation/bpf/instruction-set.rst b/Documentation/bpf/instruction-set.rst new file mode 100644 index 000000000000..3704836fe6df --- /dev/null +++ b/Documentation/bpf/instruction-set.rst @@ -0,0 +1,279 @@ + +==================== +eBPF Instruction Set +==================== + +Registers and calling convention +================================ + +eBPF has 10 general purpose registers and a read-only frame pointer register, +all of which are 64-bits wide. + +The eBPF calling convention is defined as: + + * R0: return value from function calls, and exit value for eBPF programs + * R1 - R5: arguments for function calls + * R6 - R9: callee saved registers that function calls will preserve + * R10: read-only frame pointer to access stack + +R0 - R5 are scratch registers and eBPF programs needs to spill/fill them if +necessary across calls. + +Instruction encoding +==================== + +eBPF uses 64-bit instructions with the following encoding: + + ============= ======= =============== ==================== ============ + 32 bits (MSB) 16 bits 4 bits 4 bits 8 bits (LSB) + ============= ======= =============== ==================== ============ + immediate offset source register destination register opcode + ============= ======= =============== ==================== ============ + +Note that most instructions do not use all of the fields. +Unused fields shall be cleared to zero. + +Instruction classes +------------------- + +The three LSB bits of the 'opcode' field store the instruction class: + + ========= ===== =============================== + class value description + ========= ===== =============================== + BPF_LD 0x00 non-standard load operations + BPF_LDX 0x01 load into register operations + BPF_ST 0x02 store from immediate operations + BPF_STX 0x03 store from register operations + BPF_ALU 0x04 32-bit arithmetic operations + BPF_JMP 0x05 64-bit jump operations + BPF_JMP32 0x06 32-bit jump operations + BPF_ALU64 0x07 64-bit arithmetic operations + ========= ===== =============================== + +Arithmetic and jump instructions +================================ + +For arithmetic and jump instructions (BPF_ALU, BPF_ALU64, BPF_JMP and +BPF_JMP32), the 8-bit 'opcode' field is divided into three parts: + + ============== ====== ================= + 4 bits (MSB) 1 bit 3 bits (LSB) + ============== ====== ================= + operation code source instruction class + ============== ====== ================= + +The 4th bit encodes the source operand: + + ====== ===== ======================================== + source value description + ====== ===== ======================================== + BPF_K 0x00 use 32-bit immediate as source operand + BPF_X 0x08 use 'src_reg' register as source operand + ====== ===== ======================================== + +The four MSB bits store the operation code. + + +Arithmetic instructions +----------------------- + +BPF_ALU uses 32-bit wide operands while BPF_ALU64 uses 64-bit wide operands for +otherwise identical operations. +The code field encodes the operation as below: + + ======== ===== ========================== + code value description + ======== ===== ========================== + BPF_ADD 0x00 dst += src + BPF_SUB 0x10 dst -= src + BPF_MUL 0x20 dst \*= src + BPF_DIV 0x30 dst /= src + BPF_OR 0x40 dst \|= src + BPF_AND 0x50 dst &= src + BPF_LSH 0x60 dst <<= src + BPF_RSH 0x70 dst >>= src + BPF_NEG 0x80 dst = ~src + BPF_MOD 0x90 dst %= src + BPF_XOR 0xa0 dst ^= src + BPF_MOV 0xb0 dst = src + BPF_ARSH 0xc0 sign extending shift right + BPF_END 0xd0 endianness conversion + ======== ===== ========================== + +BPF_ADD | BPF_X | BPF_ALU means:: + + dst_reg = (u32) dst_reg + (u32) src_reg; + +BPF_ADD | BPF_X | BPF_ALU64 means:: + + dst_reg = dst_reg + src_reg + +BPF_XOR | BPF_K | BPF_ALU means:: + + src_reg = (u32) src_reg ^ (u32) imm32 + +BPF_XOR | BPF_K | BPF_ALU64 means:: + + src_reg = src_reg ^ imm32 + + +Jump instructions +----------------- + +BPF_JMP32 uses 32-bit wide operands while BPF_JMP uses 64-bit wide operands for +otherwise identical operations. +The code field encodes the operation as below: + + ======== ===== ========================= ============ + code value description notes + ======== ===== ========================= ============ + BPF_JA 0x00 PC += off BPF_JMP only + BPF_JEQ 0x10 PC += off if dst == src + BPF_JGT 0x20 PC += off if dst > src unsigned + BPF_JGE 0x30 PC += off if dst >= src unsigned + BPF_JSET 0x40 PC += off if dst & src + BPF_JNE 0x50 PC += off if dst != src + BPF_JSGT 0x60 PC += off if dst > src signed + BPF_JSGE 0x70 PC += off if dst >= src signed + BPF_CALL 0x80 function call + BPF_EXIT 0x90 function / program return BPF_JMP only + BPF_JLT 0xa0 PC += off if dst < src unsigned + BPF_JLE 0xb0 PC += off if dst <= src unsigned + BPF_JSLT 0xc0 PC += off if dst < src signed + BPF_JSLE 0xd0 PC += off if dst <= src signed + ======== ===== ========================= ============ + +The eBPF program needs to store the return value into register R0 before doing a +BPF_EXIT. + + +Load and store instructions +=========================== + +For load and store instructions (BPF_LD, BPF_LDX, BPF_ST and BPF_STX), the +8-bit 'opcode' field is divided as: + + ============ ====== ================= + 3 bits (MSB) 2 bits 3 bits (LSB) + ============ ====== ================= + mode size instruction class + ============ ====== ================= + +The size modifier is one of: + + ============= ===== ===================== + size modifier value description + ============= ===== ===================== + BPF_W 0x00 word (4 bytes) + BPF_H 0x08 half word (2 bytes) + BPF_B 0x10 byte + BPF_DW 0x18 double word (8 bytes) + ============= ===== ===================== + +The mode modifier is one of: + + ============= ===== ==================================== + mode modifier value description + ============= ===== ==================================== + BPF_IMM 0x00 used for 64-bit mov + BPF_ABS 0x20 legacy BPF packet access + BPF_IND 0x40 legacy BPF packet access + BPF_MEM 0x60 all normal load and store operations + BPF_ATOMIC 0xc0 atomic operations + ============= ===== ==================================== + +BPF_MEM | <size> | BPF_STX means:: + + *(size *) (dst_reg + off) = src_reg + +BPF_MEM | <size> | BPF_ST means:: + + *(size *) (dst_reg + off) = imm32 + +BPF_MEM | <size> | BPF_LDX means:: + + dst_reg = *(size *) (src_reg + off) + +Where size is one of: BPF_B or BPF_H or BPF_W or BPF_DW. + +Atomic operations +----------------- + +eBPF includes atomic operations, which use the immediate field for extra +encoding:: + + .imm = BPF_ADD, .code = BPF_ATOMIC | BPF_W | BPF_STX: lock xadd *(u32 *)(dst_reg + off16) += src_reg + .imm = BPF_ADD, .code = BPF_ATOMIC | BPF_DW | BPF_STX: lock xadd *(u64 *)(dst_reg + off16) += src_reg + +The basic atomic operations supported are:: + + BPF_ADD + BPF_AND + BPF_OR + BPF_XOR + +Each having equivalent semantics with the ``BPF_ADD`` example, that is: the +memory location addresed by ``dst_reg + off`` is atomically modified, with +``src_reg`` as the other operand. If the ``BPF_FETCH`` flag is set in the +immediate, then these operations also overwrite ``src_reg`` with the +value that was in memory before it was modified. + +The more special operations are:: + + BPF_XCHG + +This atomically exchanges ``src_reg`` with the value addressed by ``dst_reg + +off``. :: + + BPF_CMPXCHG + +This atomically compares the value addressed by ``dst_reg + off`` with +``R0``. If they match it is replaced with ``src_reg``. In either case, the +value that was there before is zero-extended and loaded back to ``R0``. + +Note that 1 and 2 byte atomic operations are not supported. + +Clang can generate atomic instructions by default when ``-mcpu=v3`` is +enabled. If a lower version for ``-mcpu`` is set, the only atomic instruction +Clang can generate is ``BPF_ADD`` *without* ``BPF_FETCH``. If you need to enable +the atomics features, while keeping a lower ``-mcpu`` version, you can use +``-Xclang -target-feature -Xclang +alu32``. + +You may encounter ``BPF_XADD`` - this is a legacy name for ``BPF_ATOMIC``, +referring to the exclusive-add operation encoded when the immediate field is +zero. + +16-byte instructions +-------------------- + +eBPF has one 16-byte instruction: ``BPF_LD | BPF_DW | BPF_IMM`` which consists +of two consecutive ``struct bpf_insn`` 8-byte blocks and interpreted as single +instruction that loads 64-bit immediate value into a dst_reg. + +Packet access instructions +-------------------------- + +eBPF has two non-generic instructions: (BPF_ABS | <size> | BPF_LD) and +(BPF_IND | <size> | BPF_LD) which are used to access packet data. + +They had to be carried over from classic BPF to have strong performance of +socket filters running in eBPF interpreter. These instructions can only +be used when interpreter context is a pointer to ``struct sk_buff`` and +have seven implicit operands. Register R6 is an implicit input that must +contain pointer to sk_buff. Register R0 is an implicit output which contains +the data fetched from the packet. Registers R1-R5 are scratch registers +and must not be used to store the data across BPF_ABS | BPF_LD or +BPF_IND | BPF_LD instructions. + +These instructions have implicit program exit condition as well. When +eBPF program is trying to access the data beyond the packet boundary, +the interpreter will abort the execution of the program. JIT compilers +therefore must preserve this property. src_reg and imm32 fields are +explicit inputs to these instructions. + +For example, BPF_IND | BPF_W | BPF_LD means:: + + R0 = ntohl(*(u32 *) (((struct sk_buff *) R6)->data + src_reg + imm32)) + +and R1 - R5 are clobbered. diff --git a/Documentation/bpf/libbpf/index.rst b/Documentation/bpf/libbpf/index.rst index 4f8adfc3ab83..4e8c656b539a 100644 --- a/Documentation/bpf/libbpf/index.rst +++ b/Documentation/bpf/libbpf/index.rst @@ -3,8 +3,6 @@ libbpf ====== -For API documentation see the `versioned API documentation site <https://libbpf.readthedocs.io/en/latest/api.html>`_. - .. toctree:: :maxdepth: 1 @@ -14,6 +12,8 @@ For API documentation see the `versioned API documentation site <https://libbpf. This is documentation for libbpf, a userspace library for loading and interacting with bpf programs. +For API documentation see the `versioned API documentation site <https://libbpf.readthedocs.io/en/latest/api.html>`_. + All general BPF questions, including kernel functionality, libbpf APIs and their application, should be sent to bpf@vger.kernel.org mailing list. You can `subscribe <http://vger.kernel.org/vger-lists.html#bpf>`_ to the diff --git a/Documentation/bpf/maps.rst b/Documentation/bpf/maps.rst new file mode 100644 index 000000000000..f41619e312ac --- /dev/null +++ b/Documentation/bpf/maps.rst @@ -0,0 +1,52 @@ + +========= +eBPF maps +========= + +'maps' is a generic storage of different types for sharing data between kernel +and userspace. + +The maps are accessed from user space via BPF syscall, which has commands: + +- create a map with given type and attributes + ``map_fd = bpf(BPF_MAP_CREATE, union bpf_attr *attr, u32 size)`` + using attr->map_type, attr->key_size, attr->value_size, attr->max_entries + returns process-local file descriptor or negative error + +- lookup key in a given map + ``err = bpf(BPF_MAP_LOOKUP_ELEM, union bpf_attr *attr, u32 size)`` + using attr->map_fd, attr->key, attr->value + returns zero and stores found elem into value or negative error + +- create or update key/value pair in a given map + ``err = bpf(BPF_MAP_UPDATE_ELEM, union bpf_attr *attr, u32 size)`` + using attr->map_fd, attr->key, attr->value + returns zero or negative error + +- find and delete element by key in a given map + ``err = bpf(BPF_MAP_DELETE_ELEM, union bpf_attr *attr, u32 size)`` + using attr->map_fd, attr->key + +- to delete map: close(fd) + Exiting process will delete maps automatically + +userspace programs use this syscall to create/access maps that eBPF programs +are concurrently updating. + +maps can have different types: hash, array, bloom filter, radix-tree, etc. + +The map is defined by: + + - type + - max number of elements + - key size in bytes + - value size in bytes + +Map Types +========= + +.. toctree:: + :maxdepth: 1 + :glob: + + map_*
\ No newline at end of file diff --git a/Documentation/bpf/other.rst b/Documentation/bpf/other.rst new file mode 100644 index 000000000000..3d61963403b4 --- /dev/null +++ b/Documentation/bpf/other.rst @@ -0,0 +1,9 @@ +===== +Other +===== + +.. toctree:: + :maxdepth: 1 + + ringbuf + llvm_reloc
\ No newline at end of file diff --git a/Documentation/bpf/bpf_lsm.rst b/Documentation/bpf/prog_lsm.rst index 0dc3fb0d9544..0dc3fb0d9544 100644 --- a/Documentation/bpf/bpf_lsm.rst +++ b/Documentation/bpf/prog_lsm.rst diff --git a/Documentation/bpf/programs.rst b/Documentation/bpf/programs.rst new file mode 100644 index 000000000000..620eb667ac7a --- /dev/null +++ b/Documentation/bpf/programs.rst @@ -0,0 +1,9 @@ +============= +Program Types +============= + +.. toctree:: + :maxdepth: 1 + :glob: + + prog_* diff --git a/Documentation/bpf/syscall_api.rst b/Documentation/bpf/syscall_api.rst new file mode 100644 index 000000000000..f0a1dff087ad --- /dev/null +++ b/Documentation/bpf/syscall_api.rst @@ -0,0 +1,11 @@ +=========== +Syscall API +=========== + +The primary info for the bpf syscall is available in the `man-pages`_ +for `bpf(2)`_. For more information about the userspace API, see +Documentation/userspace-api/ebpf/index.rst. + +.. Links: +.. _man-pages: https://www.kernel.org/doc/man-pages/ +.. _bpf(2): https://man7.org/linux/man-pages/man2/bpf.2.html
\ No newline at end of file diff --git a/Documentation/bpf/test_debug.rst b/Documentation/bpf/test_debug.rst new file mode 100644 index 000000000000..ebf0caceb6a6 --- /dev/null +++ b/Documentation/bpf/test_debug.rst @@ -0,0 +1,9 @@ +========================= +Testing and debugging BPF +========================= + +.. toctree:: + :maxdepth: 1 + + drgn + s390 diff --git a/Documentation/bpf/verifier.rst b/Documentation/bpf/verifier.rst new file mode 100644 index 000000000000..fae5f6273bac --- /dev/null +++ b/Documentation/bpf/verifier.rst @@ -0,0 +1,529 @@ + +============= +eBPF verifier +============= + +The safety of the eBPF program is determined in two steps. + +First step does DAG check to disallow loops and other CFG validation. +In particular it will detect programs that have unreachable instructions. +(though classic BPF checker allows them) + +Second step starts from the first insn and descends all possible paths. +It simulates execution of every insn and observes the state change of +registers and stack. + +At the start of the program the register R1 contains a pointer to context +and has type PTR_TO_CTX. +If verifier sees an insn that does R2=R1, then R2 has now type +PTR_TO_CTX as well and can be used on the right hand side of expression. +If R1=PTR_TO_CTX and insn is R2=R1+R1, then R2=SCALAR_VALUE, +since addition of two valid pointers makes invalid pointer. +(In 'secure' mode verifier will reject any type of pointer arithmetic to make +sure that kernel addresses don't leak to unprivileged users) + +If register was never written to, it's not readable:: + + bpf_mov R0 = R2 + bpf_exit + +will be rejected, since R2 is unreadable at the start of the program. + +After kernel function call, R1-R5 are reset to unreadable and +R0 has a return type of the function. + +Since R6-R9 are callee saved, their state is preserved across the call. + +:: + + bpf_mov R6 = 1 + bpf_call foo + bpf_mov R0 = R6 + bpf_exit + +is a correct program. If there was R1 instead of R6, it would have +been rejected. + +load/store instructions are allowed only with registers of valid types, which +are PTR_TO_CTX, PTR_TO_MAP, PTR_TO_STACK. They are bounds and alignment checked. +For example:: + + bpf_mov R1 = 1 + bpf_mov R2 = 2 + bpf_xadd *(u32 *)(R1 + 3) += R2 + bpf_exit + +will be rejected, since R1 doesn't have a valid pointer type at the time of +execution of instruction bpf_xadd. + +At the start R1 type is PTR_TO_CTX (a pointer to generic ``struct bpf_context``) +A callback is used to customize verifier to restrict eBPF program access to only +certain fields within ctx structure with specified size and alignment. + +For example, the following insn:: + + bpf_ld R0 = *(u32 *)(R6 + 8) + +intends to load a word from address R6 + 8 and store it into R0 +If R6=PTR_TO_CTX, via is_valid_access() callback the verifier will know +that offset 8 of size 4 bytes can be accessed for reading, otherwise +the verifier will reject the program. +If R6=PTR_TO_STACK, then access should be aligned and be within +stack bounds, which are [-MAX_BPF_STACK, 0). In this example offset is 8, +so it will fail verification, since it's out of bounds. + +The verifier will allow eBPF program to read data from stack only after +it wrote into it. + +Classic BPF verifier does similar check with M[0-15] memory slots. +For example:: + + bpf_ld R0 = *(u32 *)(R10 - 4) + bpf_exit + +is invalid program. +Though R10 is correct read-only register and has type PTR_TO_STACK +and R10 - 4 is within stack bounds, there were no stores into that location. + +Pointer register spill/fill is tracked as well, since four (R6-R9) +callee saved registers may not be enough for some programs. + +Allowed function calls are customized with bpf_verifier_ops->get_func_proto() +The eBPF verifier will check that registers match argument constraints. +After the call register R0 will be set to return type of the function. + +Function calls is a main mechanism to extend functionality of eBPF programs. +Socket filters may let programs to call one set of functions, whereas tracing +filters may allow completely different set. + +If a function made accessible to eBPF program, it needs to be thought through +from safety point of view. The verifier will guarantee that the function is +called with valid arguments. + +seccomp vs socket filters have different security restrictions for classic BPF. +Seccomp solves this by two stage verifier: classic BPF verifier is followed +by seccomp verifier. In case of eBPF one configurable verifier is shared for +all use cases. + +See details of eBPF verifier in kernel/bpf/verifier.c + +Register value tracking +======================= + +In order to determine the safety of an eBPF program, the verifier must track +the range of possible values in each register and also in each stack slot. +This is done with ``struct bpf_reg_state``, defined in include/linux/ +bpf_verifier.h, which unifies tracking of scalar and pointer values. Each +register state has a type, which is either NOT_INIT (the register has not been +written to), SCALAR_VALUE (some value which is not usable as a pointer), or a +pointer type. The types of pointers describe their base, as follows: + + + PTR_TO_CTX + Pointer to bpf_context. + CONST_PTR_TO_MAP + Pointer to struct bpf_map. "Const" because arithmetic + on these pointers is forbidden. + PTR_TO_MAP_VALUE + Pointer to the value stored in a map element. + PTR_TO_MAP_VALUE_OR_NULL + Either a pointer to a map value, or NULL; map accesses + (see maps.rst) return this type, which becomes a + PTR_TO_MAP_VALUE when checked != NULL. Arithmetic on + these pointers is forbidden. + PTR_TO_STACK + Frame pointer. + PTR_TO_PACKET + skb->data. + PTR_TO_PACKET_END + skb->data + headlen; arithmetic forbidden. + PTR_TO_SOCKET + Pointer to struct bpf_sock_ops, implicitly refcounted. + PTR_TO_SOCKET_OR_NULL + Either a pointer to a socket, or NULL; socket lookup + returns this type, which becomes a PTR_TO_SOCKET when + checked != NULL. PTR_TO_SOCKET is reference-counted, + so programs must release the reference through the + socket release function before the end of the program. + Arithmetic on these pointers is forbidden. + +However, a pointer may be offset from this base (as a result of pointer +arithmetic), and this is tracked in two parts: the 'fixed offset' and 'variable +offset'. The former is used when an exactly-known value (e.g. an immediate +operand) is added to a pointer, while the latter is used for values which are +not exactly known. The variable offset is also used in SCALAR_VALUEs, to track +the range of possible values in the register. + +The verifier's knowledge about the variable offset consists of: + +* minimum and maximum values as unsigned +* minimum and maximum values as signed + +* knowledge of the values of individual bits, in the form of a 'tnum': a u64 + 'mask' and a u64 'value'. 1s in the mask represent bits whose value is unknown; + 1s in the value represent bits known to be 1. Bits known to be 0 have 0 in both + mask and value; no bit should ever be 1 in both. For example, if a byte is read + into a register from memory, the register's top 56 bits are known zero, while + the low 8 are unknown - which is represented as the tnum (0x0; 0xff). If we + then OR this with 0x40, we get (0x40; 0xbf), then if we add 1 we get (0x0; + 0x1ff), because of potential carries. + +Besides arithmetic, the register state can also be updated by conditional +branches. For instance, if a SCALAR_VALUE is compared > 8, in the 'true' branch +it will have a umin_value (unsigned minimum value) of 9, whereas in the 'false' +branch it will have a umax_value of 8. A signed compare (with BPF_JSGT or +BPF_JSGE) would instead update the signed minimum/maximum values. Information +from the signed and unsigned bounds can be combined; for instance if a value is +first tested < 8 and then tested s> 4, the verifier will conclude that the value +is also > 4 and s< 8, since the bounds prevent crossing the sign boundary. + +PTR_TO_PACKETs with a variable offset part have an 'id', which is common to all +pointers sharing that same variable offset. This is important for packet range +checks: after adding a variable to a packet pointer register A, if you then copy +it to another register B and then add a constant 4 to A, both registers will +share the same 'id' but the A will have a fixed offset of +4. Then if A is +bounds-checked and found to be less than a PTR_TO_PACKET_END, the register B is +now known to have a safe range of at least 4 bytes. See 'Direct packet access', +below, for more on PTR_TO_PACKET ranges. + +The 'id' field is also used on PTR_TO_MAP_VALUE_OR_NULL, common to all copies of +the pointer returned from a map lookup. This means that when one copy is +checked and found to be non-NULL, all copies can become PTR_TO_MAP_VALUEs. +As well as range-checking, the tracked information is also used for enforcing +alignment of pointer accesses. For instance, on most systems the packet pointer +is 2 bytes after a 4-byte alignment. If a program adds 14 bytes to that to jump +over the Ethernet header, then reads IHL and addes (IHL * 4), the resulting +pointer will have a variable offset known to be 4n+2 for some n, so adding the 2 +bytes (NET_IP_ALIGN) gives a 4-byte alignment and so word-sized accesses through +that pointer are safe. +The 'id' field is also used on PTR_TO_SOCKET and PTR_TO_SOCKET_OR_NULL, common +to all copies of the pointer returned from a socket lookup. This has similar +behaviour to the handling for PTR_TO_MAP_VALUE_OR_NULL->PTR_TO_MAP_VALUE, but +it also handles reference tracking for the pointer. PTR_TO_SOCKET implicitly +represents a reference to the corresponding ``struct sock``. To ensure that the +reference is not leaked, it is imperative to NULL-check the reference and in +the non-NULL case, and pass the valid reference to the socket release function. + +Direct packet access +==================== + +In cls_bpf and act_bpf programs the verifier allows direct access to the packet +data via skb->data and skb->data_end pointers. +Ex:: + + 1: r4 = *(u32 *)(r1 +80) /* load skb->data_end */ + 2: r3 = *(u32 *)(r1 +76) /* load skb->data */ + 3: r5 = r3 + 4: r5 += 14 + 5: if r5 > r4 goto pc+16 + R1=ctx R3=pkt(id=0,off=0,r=14) R4=pkt_end R5=pkt(id=0,off=14,r=14) R10=fp + 6: r0 = *(u16 *)(r3 +12) /* access 12 and 13 bytes of the packet */ + +this 2byte load from the packet is safe to do, since the program author +did check ``if (skb->data + 14 > skb->data_end) goto err`` at insn #5 which +means that in the fall-through case the register R3 (which points to skb->data) +has at least 14 directly accessible bytes. The verifier marks it +as R3=pkt(id=0,off=0,r=14). +id=0 means that no additional variables were added to the register. +off=0 means that no additional constants were added. +r=14 is the range of safe access which means that bytes [R3, R3 + 14) are ok. +Note that R5 is marked as R5=pkt(id=0,off=14,r=14). It also points +to the packet data, but constant 14 was added to the register, so +it now points to ``skb->data + 14`` and accessible range is [R5, R5 + 14 - 14) +which is zero bytes. + +More complex packet access may look like:: + + + R0=inv1 R1=ctx R3=pkt(id=0,off=0,r=14) R4=pkt_end R5=pkt(id=0,off=14,r=14) R10=fp + 6: r0 = *(u8 *)(r3 +7) /* load 7th byte from the packet */ + 7: r4 = *(u8 *)(r3 +12) + 8: r4 *= 14 + 9: r3 = *(u32 *)(r1 +76) /* load skb->data */ + 10: r3 += r4 + 11: r2 = r1 + 12: r2 <<= 48 + 13: r2 >>= 48 + 14: r3 += r2 + 15: r2 = r3 + 16: r2 += 8 + 17: r1 = *(u32 *)(r1 +80) /* load skb->data_end */ + 18: if r2 > r1 goto pc+2 + R0=inv(id=0,umax_value=255,var_off=(0x0; 0xff)) R1=pkt_end R2=pkt(id=2,off=8,r=8) R3=pkt(id=2,off=0,r=8) R4=inv(id=0,umax_value=3570,var_off=(0x0; 0xfffe)) R5=pkt(id=0,off=14,r=14) R10=fp + 19: r1 = *(u8 *)(r3 +4) + +The state of the register R3 is R3=pkt(id=2,off=0,r=8) +id=2 means that two ``r3 += rX`` instructions were seen, so r3 points to some +offset within a packet and since the program author did +``if (r3 + 8 > r1) goto err`` at insn #18, the safe range is [R3, R3 + 8). +The verifier only allows 'add'/'sub' operations on packet registers. Any other +operation will set the register state to 'SCALAR_VALUE' and it won't be +available for direct packet access. + +Operation ``r3 += rX`` may overflow and become less than original skb->data, +therefore the verifier has to prevent that. So when it sees ``r3 += rX`` +instruction and rX is more than 16-bit value, any subsequent bounds-check of r3 +against skb->data_end will not give us 'range' information, so attempts to read +through the pointer will give "invalid access to packet" error. + +Ex. after insn ``r4 = *(u8 *)(r3 +12)`` (insn #7 above) the state of r4 is +R4=inv(id=0,umax_value=255,var_off=(0x0; 0xff)) which means that upper 56 bits +of the register are guaranteed to be zero, and nothing is known about the lower +8 bits. After insn ``r4 *= 14`` the state becomes +R4=inv(id=0,umax_value=3570,var_off=(0x0; 0xfffe)), since multiplying an 8-bit +value by constant 14 will keep upper 52 bits as zero, also the least significant +bit will be zero as 14 is even. Similarly ``r2 >>= 48`` will make +R2=inv(id=0,umax_value=65535,var_off=(0x0; 0xffff)), since the shift is not sign +extending. This logic is implemented in adjust_reg_min_max_vals() function, +which calls adjust_ptr_min_max_vals() for adding pointer to scalar (or vice +versa) and adjust_scalar_min_max_vals() for operations on two scalars. + +The end result is that bpf program author can access packet directly +using normal C code as:: + + void *data = (void *)(long)skb->data; + void *data_end = (void *)(long)skb->data_end; + struct eth_hdr *eth = data; + struct iphdr *iph = data + sizeof(*eth); + struct udphdr *udp = data + sizeof(*eth) + sizeof(*iph); + + if (data + sizeof(*eth) + sizeof(*iph) + sizeof(*udp) > data_end) + return 0; + if (eth->h_proto != htons(ETH_P_IP)) + return 0; + if (iph->protocol != IPPROTO_UDP || iph->ihl != 5) + return 0; + if (udp->dest == 53 || udp->source == 9) + ...; + +which makes such programs easier to write comparing to LD_ABS insn +and significantly faster. + +Pruning +======= + +The verifier does not actually walk all possible paths through the program. For +each new branch to analyse, the verifier looks at all the states it's previously +been in when at this instruction. If any of them contain the current state as a +subset, the branch is 'pruned' - that is, the fact that the previous state was +accepted implies the current state would be as well. For instance, if in the +previous state, r1 held a packet-pointer, and in the current state, r1 holds a +packet-pointer with a range as long or longer and at least as strict an +alignment, then r1 is safe. Similarly, if r2 was NOT_INIT before then it can't +have been used by any path from that point, so any value in r2 (including +another NOT_INIT) is safe. The implementation is in the function regsafe(). +Pruning considers not only the registers but also the stack (and any spilled +registers it may hold). They must all be safe for the branch to be pruned. +This is implemented in states_equal(). + +Understanding eBPF verifier messages +==================================== + +The following are few examples of invalid eBPF programs and verifier error +messages as seen in the log: + +Program with unreachable instructions:: + + static struct bpf_insn prog[] = { + BPF_EXIT_INSN(), + BPF_EXIT_INSN(), + }; + +Error: + + unreachable insn 1 + +Program that reads uninitialized register:: + + BPF_MOV64_REG(BPF_REG_0, BPF_REG_2), + BPF_EXIT_INSN(), + +Error:: + + 0: (bf) r0 = r2 + R2 !read_ok + +Program that doesn't initialize R0 before exiting:: + + BPF_MOV64_REG(BPF_REG_2, BPF_REG_1), + BPF_EXIT_INSN(), + +Error:: + + 0: (bf) r2 = r1 + 1: (95) exit + R0 !read_ok + +Program that accesses stack out of bounds:: + + BPF_ST_MEM(BPF_DW, BPF_REG_10, 8, 0), + BPF_EXIT_INSN(), + +Error:: + + 0: (7a) *(u64 *)(r10 +8) = 0 + invalid stack off=8 size=8 + +Program that doesn't initialize stack before passing its address into function:: + + BPF_MOV64_REG(BPF_REG_2, BPF_REG_10), + BPF_ALU64_IMM(BPF_ADD, BPF_REG_2, -8), + BPF_LD_MAP_FD(BPF_REG_1, 0), + BPF_RAW_INSN(BPF_JMP | BPF_CALL, 0, 0, 0, BPF_FUNC_map_lookup_elem), + BPF_EXIT_INSN(), + +Error:: + + 0: (bf) r2 = r10 + 1: (07) r2 += -8 + 2: (b7) r1 = 0x0 + 3: (85) call 1 + invalid indirect read from stack off -8+0 size 8 + +Program that uses invalid map_fd=0 while calling to map_lookup_elem() function:: + + BPF_ST_MEM(BPF_DW, BPF_REG_10, -8, 0), + BPF_MOV64_REG(BPF_REG_2, BPF_REG_10), + BPF_ALU64_IMM(BPF_ADD, BPF_REG_2, -8), + BPF_LD_MAP_FD(BPF_REG_1, 0), + BPF_RAW_INSN(BPF_JMP | BPF_CALL, 0, 0, 0, BPF_FUNC_map_lookup_elem), + BPF_EXIT_INSN(), + +Error:: + + 0: (7a) *(u64 *)(r10 -8) = 0 + 1: (bf) r2 = r10 + 2: (07) r2 += -8 + 3: (b7) r1 = 0x0 + 4: (85) call 1 + fd 0 is not pointing to valid bpf_map + +Program that doesn't check return value of map_lookup_elem() before accessing +map element:: + + BPF_ST_MEM(BPF_DW, BPF_REG_10, -8, 0), + BPF_MOV64_REG(BPF_REG_2, BPF_REG_10), + BPF_ALU64_IMM(BPF_ADD, BPF_REG_2, -8), + BPF_LD_MAP_FD(BPF_REG_1, 0), + BPF_RAW_INSN(BPF_JMP | BPF_CALL, 0, 0, 0, BPF_FUNC_map_lookup_elem), + BPF_ST_MEM(BPF_DW, BPF_REG_0, 0, 0), + BPF_EXIT_INSN(), + +Error:: + + 0: (7a) *(u64 *)(r10 -8) = 0 + 1: (bf) r2 = r10 + 2: (07) r2 += -8 + 3: (b7) r1 = 0x0 + 4: (85) call 1 + 5: (7a) *(u64 *)(r0 +0) = 0 + R0 invalid mem access 'map_value_or_null' + +Program that correctly checks map_lookup_elem() returned value for NULL, but +accesses the memory with incorrect alignment:: + + BPF_ST_MEM(BPF_DW, BPF_REG_10, -8, 0), + BPF_MOV64_REG(BPF_REG_2, BPF_REG_10), + BPF_ALU64_IMM(BPF_ADD, BPF_REG_2, -8), + BPF_LD_MAP_FD(BPF_REG_1, 0), + BPF_RAW_INSN(BPF_JMP | BPF_CALL, 0, 0, 0, BPF_FUNC_map_lookup_elem), + BPF_JMP_IMM(BPF_JEQ, BPF_REG_0, 0, 1), + BPF_ST_MEM(BPF_DW, BPF_REG_0, 4, 0), + BPF_EXIT_INSN(), + +Error:: + + 0: (7a) *(u64 *)(r10 -8) = 0 + 1: (bf) r2 = r10 + 2: (07) r2 += -8 + 3: (b7) r1 = 1 + 4: (85) call 1 + 5: (15) if r0 == 0x0 goto pc+1 + R0=map_ptr R10=fp + 6: (7a) *(u64 *)(r0 +4) = 0 + misaligned access off 4 size 8 + +Program that correctly checks map_lookup_elem() returned value for NULL and +accesses memory with correct alignment in one side of 'if' branch, but fails +to do so in the other side of 'if' branch:: + + BPF_ST_MEM(BPF_DW, BPF_REG_10, -8, 0), + BPF_MOV64_REG(BPF_REG_2, BPF_REG_10), + BPF_ALU64_IMM(BPF_ADD, BPF_REG_2, -8), + BPF_LD_MAP_FD(BPF_REG_1, 0), + BPF_RAW_INSN(BPF_JMP | BPF_CALL, 0, 0, 0, BPF_FUNC_map_lookup_elem), + BPF_JMP_IMM(BPF_JEQ, BPF_REG_0, 0, 2), + BPF_ST_MEM(BPF_DW, BPF_REG_0, 0, 0), + BPF_EXIT_INSN(), + BPF_ST_MEM(BPF_DW, BPF_REG_0, 0, 1), + BPF_EXIT_INSN(), + +Error:: + + 0: (7a) *(u64 *)(r10 -8) = 0 + 1: (bf) r2 = r10 + 2: (07) r2 += -8 + 3: (b7) r1 = 1 + 4: (85) call 1 + 5: (15) if r0 == 0x0 goto pc+2 + R0=map_ptr R10=fp + 6: (7a) *(u64 *)(r0 +0) = 0 + 7: (95) exit + + from 5 to 8: R0=imm0 R10=fp + 8: (7a) *(u64 *)(r0 +0) = 1 + R0 invalid mem access 'imm' + +Program that performs a socket lookup then sets the pointer to NULL without +checking it:: + + BPF_MOV64_IMM(BPF_REG_2, 0), + BPF_STX_MEM(BPF_W, BPF_REG_10, BPF_REG_2, -8), + BPF_MOV64_REG(BPF_REG_2, BPF_REG_10), + BPF_ALU64_IMM(BPF_ADD, BPF_REG_2, -8), + BPF_MOV64_IMM(BPF_REG_3, 4), + BPF_MOV64_IMM(BPF_REG_4, 0), + BPF_MOV64_IMM(BPF_REG_5, 0), + BPF_EMIT_CALL(BPF_FUNC_sk_lookup_tcp), + BPF_MOV64_IMM(BPF_REG_0, 0), + BPF_EXIT_INSN(), + +Error:: + + 0: (b7) r2 = 0 + 1: (63) *(u32 *)(r10 -8) = r2 + 2: (bf) r2 = r10 + 3: (07) r2 += -8 + 4: (b7) r3 = 4 + 5: (b7) r4 = 0 + 6: (b7) r5 = 0 + 7: (85) call bpf_sk_lookup_tcp#65 + 8: (b7) r0 = 0 + 9: (95) exit + Unreleased reference id=1, alloc_insn=7 + +Program that performs a socket lookup but does not NULL-check the returned +value:: + + BPF_MOV64_IMM(BPF_REG_2, 0), + BPF_STX_MEM(BPF_W, BPF_REG_10, BPF_REG_2, -8), + BPF_MOV64_REG(BPF_REG_2, BPF_REG_10), + BPF_ALU64_IMM(BPF_ADD, BPF_REG_2, -8), + BPF_MOV64_IMM(BPF_REG_3, 4), + BPF_MOV64_IMM(BPF_REG_4, 0), + BPF_MOV64_IMM(BPF_REG_5, 0), + BPF_EMIT_CALL(BPF_FUNC_sk_lookup_tcp), + BPF_EXIT_INSN(), + +Error:: + + 0: (b7) r2 = 0 + 1: (63) *(u32 *)(r10 -8) = r2 + 2: (bf) r2 = r10 + 3: (07) r2 += -8 + 4: (b7) r3 = 4 + 5: (b7) r4 = 0 + 6: (b7) r5 = 0 + 7: (85) call bpf_sk_lookup_tcp#65 + 8: (95) exit + Unreleased reference id=1, alloc_insn=7 diff --git a/Documentation/conf.py b/Documentation/conf.py index 17f7cee56987..f07f2e9b9f2c 100644 --- a/Documentation/conf.py +++ b/Documentation/conf.py @@ -208,16 +208,86 @@ highlight_language = 'none' # The theme to use for HTML and HTML Help pages. See the documentation for # a list of builtin themes. -# The Read the Docs theme is available from -# - https://github.com/snide/sphinx_rtd_theme -# - https://pypi.python.org/pypi/sphinx_rtd_theme -# - python-sphinx-rtd-theme package (on Debian) -try: - import sphinx_rtd_theme - html_theme = 'sphinx_rtd_theme' - html_theme_path = [sphinx_rtd_theme.get_html_theme_path()] -except ImportError: - sys.stderr.write('Warning: The Sphinx \'sphinx_rtd_theme\' HTML theme was not found. Make sure you have the theme installed to produce pretty HTML output. Falling back to the default theme.\n') +# Default theme +html_theme = 'sphinx_rtd_theme' +html_css_files = [] + +if "DOCS_THEME" in os.environ: + html_theme = os.environ["DOCS_THEME"] + +if html_theme == 'sphinx_rtd_theme' or html_theme == 'sphinx_rtd_dark_mode': + # Read the Docs theme + try: + import sphinx_rtd_theme + html_theme_path = [sphinx_rtd_theme.get_html_theme_path()] + + # Add any paths that contain custom static files (such as style sheets) here, + # relative to this directory. They are copied after the builtin static files, + # so a file named "default.css" will overwrite the builtin "default.css". + html_css_files = [ + 'theme_overrides.css', + ] + + # Read the Docs dark mode override theme + if html_theme == 'sphinx_rtd_dark_mode': + try: + import sphinx_rtd_dark_mode + extensions.append('sphinx_rtd_dark_mode') + except ImportError: + html_theme == 'sphinx_rtd_theme' + + if html_theme == 'sphinx_rtd_theme': + # Add color-specific RTD normal mode + html_css_files.append('theme_rtd_colors.css') + + except ImportError: + html_theme = 'classic' + +if "DOCS_CSS" in os.environ: + css = os.environ["DOCS_CSS"].split(" ") + + for l in css: + html_css_files.append(l) + +if major <= 1 and minor < 8: + html_context = { + 'css_files': [], + } + + for l in html_css_files: + html_context['css_files'].append('_static/' + l) + +if html_theme == 'classic': + html_theme_options = { + 'rightsidebar': False, + 'stickysidebar': True, + 'collapsiblesidebar': True, + 'externalrefs': False, + + 'footerbgcolor': "white", + 'footertextcolor': "white", + 'sidebarbgcolor': "white", + 'sidebarbtncolor': "black", + 'sidebartextcolor': "black", + 'sidebarlinkcolor': "#686bff", + 'relbarbgcolor': "#133f52", + 'relbartextcolor': "white", + 'relbarlinkcolor': "white", + 'bgcolor': "white", + 'textcolor': "black", + 'headbgcolor': "#f2f2f2", + 'headtextcolor': "#20435c", + 'headlinkcolor': "#c60f0f", + 'linkcolor': "#355f7c", + 'visitedlinkcolor': "#355f7c", + 'codebgcolor': "#3f3f3f", + 'codetextcolor': "white", + + 'bodyfont': "serif", + 'headfont': "sans-serif", + } + +sys.stderr.write("Using %s theme\n" % html_theme) # Theme options are theme-specific and customize the look and feel of a theme # further. For a list of options available for each theme, see the @@ -246,15 +316,8 @@ except ImportError: # Add any paths that contain custom static files (such as style sheets) here, # relative to this directory. They are copied after the builtin static files, # so a file named "default.css" will overwrite the builtin "default.css". - html_static_path = ['sphinx-static'] -html_context = { - 'css_files': [ - '_static/theme_overrides.css', - ], -} - # Add any extra paths that contain custom files (such as robots.txt or # .htaccess) here, relative to this directory. These files are copied # directly to the root of the documentation. diff --git a/Documentation/core-api/kernel-api.rst b/Documentation/core-api/kernel-api.rst index 2e7186805148..d6b3f94b9f1f 100644 --- a/Documentation/core-api/kernel-api.rst +++ b/Documentation/core-api/kernel-api.rst @@ -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: diff --git a/Documentation/core-api/kobject.rst b/Documentation/core-api/kobject.rst index 2739f8b72575..7310247310a0 100644 --- a/Documentation/core-api/kobject.rst +++ b/Documentation/core-api/kobject.rst @@ -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); }; diff --git a/Documentation/cpu-freq/core.rst b/Documentation/cpu-freq/core.rst index 33cb90bd1d8f..4ceef8e7217c 100644 --- a/Documentation/cpu-freq/core.rst +++ b/Documentation/cpu-freq/core.rst @@ -73,12 +73,12 @@ CPUFREQ_POSTCHANGE. The third argument is a struct cpufreq_freqs with the following values: -===== =========================== -cpu number of the affected CPU +====== ====================================== +policy a pointer to the struct cpufreq_policy old old frequency new new frequency flags flags of the cpufreq driver -===== =========================== +====== ====================================== 3. CPUFreq Table Generation with Operating Performance Point (OPP) ================================================================== diff --git a/Documentation/dev-tools/index.rst b/Documentation/dev-tools/index.rst index 010a2af1e7d9..4621eac290f4 100644 --- a/Documentation/dev-tools/index.rst +++ b/Documentation/dev-tools/index.rst @@ -32,6 +32,7 @@ Documentation/dev-tools/testing-overview.rst kgdb kselftest kunit/index + ktap .. only:: subproject and html diff --git a/Documentation/dev-tools/kcsan.rst b/Documentation/dev-tools/kcsan.rst index 7db43c7c09b8..3ae866dcc924 100644 --- a/Documentation/dev-tools/kcsan.rst +++ b/Documentation/dev-tools/kcsan.rst @@ -204,17 +204,17 @@ Ultimately this allows to determine the possible executions of concurrent code, and if that code is free from data races. KCSAN is aware of *marked atomic operations* (``READ_ONCE``, ``WRITE_ONCE``, -``atomic_*``, etc.), but is oblivious of any ordering guarantees and simply -assumes that memory barriers are placed correctly. In other words, KCSAN -assumes that as long as a plain access is not observed to race with another -conflicting access, memory operations are correctly ordered. - -This means that KCSAN will not report *potential* data races due to missing -memory ordering. Developers should therefore carefully consider the required -memory ordering requirements that remain unchecked. If, however, missing -memory ordering (that is observable with a particular compiler and -architecture) leads to an observable data race (e.g. entering a critical -section erroneously), KCSAN would report the resulting data race. +``atomic_*``, etc.), and a subset of ordering guarantees implied by memory +barriers. With ``CONFIG_KCSAN_WEAK_MEMORY=y``, KCSAN models load or store +buffering, and can detect missing ``smp_mb()``, ``smp_wmb()``, ``smp_rmb()``, +``smp_store_release()``, and all ``atomic_*`` operations with equivalent +implied barriers. + +Note, KCSAN will not report all data races due to missing memory ordering, +specifically where a memory barrier would be required to prohibit subsequent +memory operation from reordering before the barrier. Developers should +therefore carefully consider the required memory ordering requirements that +remain unchecked. Race Detection Beyond Data Races -------------------------------- @@ -268,6 +268,56 @@ marked operations, if all accesses to a variable that is accessed concurrently are properly marked, KCSAN will never trigger a watchpoint and therefore never report the accesses. +Modeling Weak Memory +~~~~~~~~~~~~~~~~~~~~ + +KCSAN's approach to detecting data races due to missing memory barriers is +based on modeling access reordering (with ``CONFIG_KCSAN_WEAK_MEMORY=y``). +Each plain memory access for which a watchpoint is set up, is also selected for +simulated reordering within the scope of its function (at most 1 in-flight +access). + +Once an access has been selected for reordering, it is checked along every +other access until the end of the function scope. If an appropriate memory +barrier is encountered, the access will no longer be considered for simulated +reordering. + +When the result of a memory operation should be ordered by a barrier, KCSAN can +then detect data races where the conflict only occurs as a result of a missing +barrier. Consider the example:: + + int x, flag; + void T1(void) + { + x = 1; // data race! + WRITE_ONCE(flag, 1); // correct: smp_store_release(&flag, 1) + } + void T2(void) + { + while (!READ_ONCE(flag)); // correct: smp_load_acquire(&flag) + ... = x; // data race! + } + +When weak memory modeling is enabled, KCSAN can consider ``x`` in ``T1`` for +simulated reordering. After the write of ``flag``, ``x`` is again checked for +concurrent accesses: because ``T2`` is able to proceed after the write of +``flag``, a data race is detected. With the correct barriers in place, ``x`` +would not be considered for reordering after the proper release of ``flag``, +and no data race would be detected. + +Deliberate trade-offs in complexity but also practical limitations mean only a +subset of data races due to missing memory barriers can be detected. With +currently available compiler support, the implementation is limited to modeling +the effects of "buffering" (delaying accesses), since the runtime cannot +"prefetch" accesses. Also recall that watchpoints are only set up for plain +accesses, and the only access type for which KCSAN simulates reordering. This +means reordering of marked accesses is not modeled. + +A consequence of the above is that acquire operations do not require barrier +instrumentation (no prefetching). Furthermore, marked accesses introducing +address or control dependencies do not require special handling (the marked +access cannot be reordered, later dependent accesses cannot be prefetched). + Key Properties ~~~~~~~~~~~~~~ @@ -290,8 +340,8 @@ Key Properties 4. **Detects Racy Writes from Devices:** Due to checking data values upon setting up watchpoints, racy writes from devices can also be detected. -5. **Memory Ordering:** KCSAN is *not* explicitly aware of the LKMM's ordering - rules; this may result in missed data races (false negatives). +5. **Memory Ordering:** KCSAN is aware of only a subset of LKMM ordering rules; + this may result in missed data races (false negatives). 6. **Analysis Accuracy:** For observed executions, due to using a sampling strategy, the analysis is *unsound* (false negatives possible), but aims to diff --git a/Documentation/dev-tools/kgdb.rst b/Documentation/dev-tools/kgdb.rst index 43456244651a..f83ba2601e55 100644 --- a/Documentation/dev-tools/kgdb.rst +++ b/Documentation/dev-tools/kgdb.rst @@ -402,7 +402,7 @@ This is a quick example of how to use kdb. 2. Enter the kernel debugger manually or by waiting for an oops or fault. There are several ways you can enter the kernel debugger manually; all involve using the :kbd:`SysRq-G`, which means you must have - enabled ``CONFIG_MAGIC_SysRq=y`` in your kernel config. + enabled ``CONFIG_MAGIC_SYSRQ=y`` in your kernel config. - When logged in as root or with a super user session you can run:: @@ -461,7 +461,7 @@ This is a quick example of how to use kdb with a keyboard. 2. Enter the kernel debugger manually or by waiting for an oops or fault. There are several ways you can enter the kernel debugger manually; all involve using the :kbd:`SysRq-G`, which means you must have - enabled ``CONFIG_MAGIC_SysRq=y`` in your kernel config. + enabled ``CONFIG_MAGIC_SYSRQ=y`` in your kernel config. - When logged in as root or with a super user session you can run:: @@ -557,7 +557,7 @@ Connecting with gdb to a serial port Example (using a directly connected port):: % gdb ./vmlinux - (gdb) set remotebaud 115200 + (gdb) set serial baud 115200 (gdb) target remote /dev/ttyS0 diff --git a/Documentation/dev-tools/ktap.rst b/Documentation/dev-tools/ktap.rst new file mode 100644 index 000000000000..878530cb9c27 --- /dev/null +++ b/Documentation/dev-tools/ktap.rst @@ -0,0 +1,298 @@ +.. SPDX-License-Identifier: GPL-2.0 + +======================================== +The Kernel Test Anything Protocol (KTAP) +======================================== + +TAP, or the Test Anything Protocol is a format for specifying test results used +by a number of projects. It's website and specification are found at this `link +<https://testanything.org/>`_. The Linux Kernel largely uses TAP output for test +results. However, Kernel testing frameworks have special needs for test results +which don't align with the original TAP specification. Thus, a "Kernel TAP" +(KTAP) format is specified to extend and alter TAP to support these use-cases. +This specification describes the generally accepted format of KTAP as it is +currently used in the kernel. + +KTAP test results describe a series of tests (which may be nested: i.e., test +can have subtests), each of which can contain both diagnostic data -- e.g., log +lines -- and a final result. The test structure and results are +machine-readable, whereas the diagnostic data is unstructured and is there to +aid human debugging. + +KTAP output is built from four different types of lines: +- Version lines +- Plan lines +- Test case result lines +- Diagnostic lines + +In general, valid KTAP output should also form valid TAP output, but some +information, in particular nested test results, may be lost. Also note that +there is a stagnant draft specification for TAP14, KTAP diverges from this in +a couple of places (notably the "Subtest" header), which are described where +relevant later in this document. + +Version lines +------------- + +All KTAP-formatted results begin with a "version line" which specifies which +version of the (K)TAP standard the result is compliant with. + +For example: +- "KTAP version 1" +- "TAP version 13" +- "TAP version 14" + +Note that, in KTAP, subtests also begin with a version line, which denotes the +start of the nested test results. This differs from TAP14, which uses a +separate "Subtest" line. + +While, going forward, "KTAP version 1" should be used by compliant tests, it +is expected that most parsers and other tooling will accept the other versions +listed here for compatibility with existing tests and frameworks. + +Plan lines +---------- + +A test plan provides the number of tests (or subtests) in the KTAP output. + +Plan lines must follow the format of "1..N" where N is the number of tests or subtests. +Plan lines follow version lines to indicate the number of nested tests. + +While there are cases where the number of tests is not known in advance -- in +which case the test plan may be omitted -- it is strongly recommended one is +present where possible. + +Test case result lines +---------------------- + +Test case result lines indicate the final status of a test. +They are required and must have the format: + +.. code-block:: + + <result> <number> [<description>][ # [<directive>] [<diagnostic data>]] + +The result can be either "ok", which indicates the test case passed, +or "not ok", which indicates that the test case failed. + +<number> represents the number of the test being performed. The first test must +have the number 1 and the number then must increase by 1 for each additional +subtest within the same test at the same nesting level. + +The description is a description of the test, generally the name of +the test, and can be any string of words (can't include #). The +description is optional, but recommended. + +The directive and any diagnostic data is optional. If either are present, they +must follow a hash sign, "#". + +A directive is a keyword that indicates a different outcome for a test other +than passed and failed. The directive is optional, and consists of a single +keyword preceding the diagnostic data. In the event that a parser encounters +a directive it doesn't support, it should fall back to the "ok" / "not ok" +result. + +Currently accepted directives are: + +- "SKIP", which indicates a test was skipped (note the result of the test case + result line can be either "ok" or "not ok" if the SKIP directive is used) +- "TODO", which indicates that a test is not expected to pass at the moment, + e.g. because the feature it is testing is known to be broken. While this + directive is inherited from TAP, its use in the kernel is discouraged. +- "XFAIL", which indicates that a test is expected to fail. This is similar + to "TODO", above, and is used by some kselftest tests. +- “TIMEOUT”, which indicates a test has timed out (note the result of the test + case result line should be “not ok” if the TIMEOUT directive is used) +- “ERROR”, which indicates that the execution of a test has failed due to a + specific error that is included in the diagnostic data. (note the result of + the test case result line should be “not ok” if the ERROR directive is used) + +The diagnostic data is a plain-text field which contains any additional details +about why this result was produced. This is typically an error message for ERROR +or failed tests, or a description of missing dependencies for a SKIP result. + +The diagnostic data field is optional, and results which have neither a +directive nor any diagnostic data do not need to include the "#" field +separator. + +Example result lines include: + +.. code-block:: + + ok 1 test_case_name + +The test "test_case_name" passed. + +.. code-block:: + + not ok 1 test_case_name + +The test "test_case_name" failed. + +.. code-block:: + + ok 1 test # SKIP necessary dependency unavailable + +The test "test" was SKIPPED with the diagnostic message "necessary dependency +unavailable". + +.. code-block:: + + not ok 1 test # TIMEOUT 30 seconds + +The test "test" timed out, with diagnostic data "30 seconds". + +.. code-block:: + + ok 5 check return code # rcode=0 + +The test "check return code" passed, with additional diagnostic data “rcode=0” + + +Diagnostic lines +---------------- + +If tests wish to output any further information, they should do so using +"diagnostic lines". Diagnostic lines are optional, freeform text, and are +often used to describe what is being tested and any intermediate results in +more detail than the final result and diagnostic data line provides. + +Diagnostic lines are formatted as "# <diagnostic_description>", where the +description can be any string. Diagnostic lines can be anywhere in the test +output. As a rule, diagnostic lines regarding a test are directly before the +test result line for that test. + +Note that most tools will treat unknown lines (see below) as diagnostic lines, +even if they do not start with a "#": this is to capture any other useful +kernel output which may help debug the test. It is nevertheless recommended +that tests always prefix any diagnostic output they have with a "#" character. + +Unknown lines +------------- + +There may be lines within KTAP output that do not follow the format of one of +the four formats for lines described above. This is allowed, however, they will +not influence the status of the tests. + +Nested tests +------------ + +In KTAP, tests can be nested. This is done by having a test include within its +output an entire set of KTAP-formatted results. This can be used to categorize +and group related tests, or to split out different results from the same test. + +The "parent" test's result should consist of all of its subtests' results, +starting with another KTAP version line and test plan, and end with the overall +result. If one of the subtests fail, for example, the parent test should also +fail. + +Additionally, all result lines in a subtest should be indented. One level of +indentation is two spaces: " ". The indentation should begin at the version +line and should end before the parent test's result line. + +An example of a test with two nested subtests: + +.. code-block:: + + KTAP version 1 + 1..1 + KTAP version 1 + 1..2 + ok 1 test_1 + not ok 2 test_2 + # example failed + not ok 1 example + +An example format with multiple levels of nested testing: + +.. code-block:: + + KTAP version 1 + 1..2 + KTAP version 1 + 1..2 + KTAP version 1 + 1..2 + not ok 1 test_1 + ok 2 test_2 + not ok 1 test_3 + ok 2 test_4 # SKIP + not ok 1 example_test_1 + ok 2 example_test_2 + + +Major differences between TAP and KTAP +-------------------------------------- + +Note the major differences between the TAP and KTAP specification: +- yaml and json are not recommended in diagnostic messages +- TODO directive not recognized +- KTAP allows for an arbitrary number of tests to be nested + +The TAP14 specification does permit nested tests, but instead of using another +nested version line, uses a line of the form +"Subtest: <name>" where <name> is the name of the parent test. + +Example KTAP output +-------------------- +.. code-block:: + + KTAP version 1 + 1..1 + KTAP version 1 + 1..3 + KTAP version 1 + 1..1 + # test_1: initializing test_1 + ok 1 test_1 + ok 1 example_test_1 + KTAP version 1 + 1..2 + ok 1 test_1 # SKIP test_1 skipped + ok 2 test_2 + ok 2 example_test_2 + KTAP version 1 + 1..3 + ok 1 test_1 + # test_2: FAIL + not ok 2 test_2 + ok 3 test_3 # SKIP test_3 skipped + not ok 3 example_test_3 + not ok 1 main_test + +This output defines the following hierarchy: + +A single test called "main_test", which fails, and has three subtests: +- "example_test_1", which passes, and has one subtest: + + - "test_1", which passes, and outputs the diagnostic message "test_1: initializing test_1" + +- "example_test_2", which passes, and has two subtests: + + - "test_1", which is skipped, with the explanation "test_1 skipped" + - "test_2", which passes + +- "example_test_3", which fails, and has three subtests + + - "test_1", which passes + - "test_2", which outputs the diagnostic line "test_2: FAIL", and fails. + - "test_3", which is skipped with the explanation "test_3 skipped" + +Note that the individual subtests with the same names do not conflict, as they +are found in different parent tests. This output also exhibits some sensible +rules for "bubbling up" test results: a test fails if any of its subtests fail. +Skipped tests do not affect the result of the parent test (though it often +makes sense for a test to be marked skipped if _all_ of its subtests have been +skipped). + +See also: +--------- + +- The TAP specification: + https://testanything.org/tap-version-13-specification.html +- The (stagnant) TAP version 14 specification: + https://github.com/TestAnything/Specification/blob/tap-14-specification/specification.md +- The kselftest documentation: + Documentation/dev-tools/kselftest.rst +- The KUnit documentation: + Documentation/dev-tools/kunit/index.rst diff --git a/Documentation/dev-tools/kunit/api/index.rst b/Documentation/dev-tools/kunit/api/index.rst index b33ad72bcf0b..3006cadcf44a 100644 --- a/Documentation/dev-tools/kunit/api/index.rst +++ b/Documentation/dev-tools/kunit/api/index.rst @@ -12,5 +12,4 @@ following sections: Documentation/dev-tools/kunit/api/test.rst - - documents all of the standard testing API excluding mocking - or mocking related features. + - documents all of the standard testing API diff --git a/Documentation/dev-tools/kunit/api/test.rst b/Documentation/dev-tools/kunit/api/test.rst index aaa97f17e5b3..c5eca423e8b6 100644 --- a/Documentation/dev-tools/kunit/api/test.rst +++ b/Documentation/dev-tools/kunit/api/test.rst @@ -4,8 +4,7 @@ Test API ======== -This file documents all of the standard testing API excluding mocking or mocking -related features. +This file documents all of the standard testing API. .. kernel-doc:: include/kunit/test.h :internal: diff --git a/Documentation/dev-tools/kunit/architecture.rst b/Documentation/dev-tools/kunit/architecture.rst new file mode 100644 index 000000000000..aa2cea821e25 --- /dev/null +++ b/Documentation/dev-tools/kunit/architecture.rst @@ -0,0 +1,204 @@ +.. SPDX-License-Identifier: GPL-2.0 + +================== +KUnit Architecture +================== + +The KUnit architecture can be divided into two parts: + +- Kernel testing library +- kunit_tool (Command line test harness) + +In-Kernel Testing Framework +=========================== + +The kernel testing library supports KUnit tests written in C using +KUnit. KUnit tests are kernel code. KUnit does several things: + +- Organizes tests +- Reports test results +- Provides test utilities + +Test Cases +---------- + +The fundamental unit in KUnit is the test case. The KUnit test cases are +grouped into KUnit suites. A KUnit test case is a function with type +signature ``void (*)(struct kunit *test)``. +These test case functions are wrapped in a struct called +``struct kunit_case``. For code, see: + +.. kernel-doc:: include/kunit/test.h + :identifiers: kunit_case + +.. note: + ``generate_params`` is optional for non-parameterized tests. + +Each KUnit test case gets a ``struct kunit`` context +object passed to it that tracks a running test. The KUnit assertion +macros and other KUnit utilities use the ``struct kunit`` context +object. As an exception, there are two fields: + +- ``->priv``: The setup functions can use it to store arbitrary test + user data. + +- ``->param_value``: It contains the parameter value which can be + retrieved in the parameterized tests. + +Test Suites +----------- + +A KUnit suite includes a collection of test cases. The KUnit suites +are represented by the ``struct kunit_suite``. For example: + +.. code-block:: c + + static struct kunit_case example_test_cases[] = { + KUNIT_CASE(example_test_foo), + KUNIT_CASE(example_test_bar), + KUNIT_CASE(example_test_baz), + {} + }; + + static struct kunit_suite example_test_suite = { + .name = "example", + .init = example_test_init, + .exit = example_test_exit, + .test_cases = example_test_cases, + }; + kunit_test_suite(example_test_suite); + +In the above example, the test suite ``example_test_suite``, runs the +test cases ``example_test_foo``, ``example_test_bar``, and +``example_test_baz``. Before running the test, the ``example_test_init`` +is called and after running the test, ``example_test_exit`` is called. +The ``kunit_test_suite(example_test_suite)`` registers the test suite +with the KUnit test framework. + +Executor +-------- + +The KUnit executor can list and run built-in KUnit tests on boot. +The Test suites are stored in a linker section +called ``.kunit_test_suites``. For code, see: +https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/include/asm-generic/vmlinux.lds.h?h=v5.15#n945. +The linker section consists of an array of pointers to +``struct kunit_suite``, and is populated by the ``kunit_test_suites()`` +macro. To run all tests compiled into the kernel, the KUnit executor +iterates over the linker section array. + +.. kernel-figure:: kunit_suitememorydiagram.svg + :alt: KUnit Suite Memory + + KUnit Suite Memory Diagram + +On the kernel boot, the KUnit executor uses the start and end addresses +of this section to iterate over and run all tests. For code, see: +https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/lib/kunit/executor.c + +When built as a module, the ``kunit_test_suites()`` macro defines a +``module_init()`` function, which runs all the tests in the compilation +unit instead of utilizing the executor. + +In KUnit tests, some error classes do not affect other tests +or parts of the kernel, each KUnit case executes in a separate thread +context. For code, see: +https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/lib/kunit/try-catch.c?h=v5.15#n58 + +Assertion Macros +---------------- + +KUnit tests verify state using expectations/assertions. +All expectations/assertions are formatted as: +``KUNIT_{EXPECT|ASSERT}_<op>[_MSG](kunit, property[, message])`` + +- ``{EXPECT|ASSERT}`` determines whether the check is an assertion or an + expectation. + + - For an expectation, if the check fails, marks the test as failed + and logs the failure. + + - An assertion, on failure, causes the test case to terminate + immediately. + + - Assertions call function: + ``void __noreturn kunit_abort(struct kunit *)``. + + - ``kunit_abort`` calls function: + ``void __noreturn kunit_try_catch_throw(struct kunit_try_catch *try_catch)``. + + - ``kunit_try_catch_throw`` calls function: + ``void complete_and_exit(struct completion *, long) __noreturn;`` + and terminates the special thread context. + +- ``<op>`` denotes a check with options: ``TRUE`` (supplied property + has the boolean value “true”), ``EQ`` (two supplied properties are + equal), ``NOT_ERR_OR_NULL`` (supplied pointer is not null and does not + contain an “err” value). + +- ``[_MSG]`` prints a custom message on failure. + +Test Result Reporting +--------------------- +KUnit prints test results in KTAP format. KTAP is based on TAP14, see: +https://github.com/isaacs/testanything.github.io/blob/tap14/tap-version-14-specification.md. +KTAP (yet to be standardized format) works with KUnit and Kselftest. +The KUnit executor prints KTAP results to dmesg, and debugfs +(if configured). + +Parameterized Tests +------------------- + +Each KUnit parameterized test is associated with a collection of +parameters. The test is invoked multiple times, once for each parameter +value and the parameter is stored in the ``param_value`` field. +The test case includes a ``KUNIT_CASE_PARAM()`` macro that accepts a +generator function. +The generator function is passed the previous parameter and returns the next +parameter. It also provides a macro to generate common-case generators based on +arrays. + +For code, see: + +.. kernel-doc:: include/kunit/test.h + :identifiers: KUNIT_ARRAY_PARAM + + +kunit_tool (Command Line Test Harness) +====================================== + +kunit_tool is a Python script ``(tools/testing/kunit/kunit.py)`` +that can be used to configure, build, exec, parse and run (runs other +commands in order) test results. You can either run KUnit tests using +kunit_tool or can include KUnit in kernel and parse manually. + +- ``configure`` command generates the kernel ``.config`` from a + ``.kunitconfig`` file (and any architecture-specific options). + For some architectures, additional config options are specified in the + ``qemu_config`` Python script + (For example: ``tools/testing/kunit/qemu_configs/powerpc.py``). + It parses both the existing ``.config`` and the ``.kunitconfig`` files + and ensures that ``.config`` is a superset of ``.kunitconfig``. + If this is not the case, it will combine the two and run + ``make olddefconfig`` to regenerate the ``.config`` file. It then + verifies that ``.config`` is now a superset. This checks if all + Kconfig dependencies are correctly specified in ``.kunitconfig``. + ``kunit_config.py`` includes the parsing Kconfigs code. The code which + runs ``make olddefconfig`` is a part of ``kunit_kernel.py``. You can + invoke this command via: ``./tools/testing/kunit/kunit.py config`` and + generate a ``.config`` file. +- ``build`` runs ``make`` on the kernel tree with required options + (depends on the architecture and some options, for example: build_dir) + and reports any errors. + To build a KUnit kernel from the current ``.config``, you can use the + ``build`` argument: ``./tools/testing/kunit/kunit.py build``. +- ``exec`` command executes kernel results either directly (using + User-mode Linux configuration), or via an emulator such + as QEMU. It reads results from the log via standard + output (stdout), and passes them to ``parse`` to be parsed. + If you already have built a kernel with built-in KUnit tests, + you can run the kernel and display the test results with the ``exec`` + argument: ``./tools/testing/kunit/kunit.py exec``. +- ``parse`` extracts the KTAP output from a kernel log, parses + the test results, and prints a summary. For failed tests, any + diagnostic output will be included. diff --git a/Documentation/dev-tools/kunit/faq.rst b/Documentation/dev-tools/kunit/faq.rst index 5c6555d020f3..172e239791a8 100644 --- a/Documentation/dev-tools/kunit/faq.rst +++ b/Documentation/dev-tools/kunit/faq.rst @@ -4,56 +4,55 @@ Frequently Asked Questions ========================== -How is this different from Autotest, kselftest, etc? -==================================================== +How is this different from Autotest, kselftest, and so on? +========================================================== KUnit is a unit testing framework. Autotest, kselftest (and some others) are not. A `unit test <https://martinfowler.com/bliki/UnitTest.html>`_ is supposed to -test a single unit of code in isolation, hence the name. A unit test should be -the finest granularity of testing and as such should allow all possible code -paths to be tested in the code under test; this is only possible if the code -under test is very small and does not have any external dependencies outside of +test a single unit of code in isolation and hence the name *unit test*. A unit +test should be the finest granularity of testing and should allow all possible +code paths to be tested in the code under test. This is only possible if the +code under test is small and does not have any external dependencies outside of the test's control like hardware. There are no testing frameworks currently available for the kernel that do not -require installing the kernel on a test machine or in a VM and all require -tests to be written in userspace and run on the kernel under test; this is true -for Autotest, kselftest, and some others, disqualifying any of them from being -considered unit testing frameworks. +require installing the kernel on a test machine or in a virtual machine. All +testing frameworks require tests to be written in userspace and run on the +kernel under test. This is true for Autotest, kselftest, and some others, +disqualifying any of them from being considered unit testing frameworks. Does KUnit support running on architectures other than UML? =========================================================== -Yes, well, mostly. +Yes, mostly. -For the most part, the KUnit core framework (what you use to write the tests) -can compile to any architecture; it compiles like just another part of the +For the most part, the KUnit core framework (what we use to write the tests) +can compile to any architecture. It compiles like just another part of the kernel and runs when the kernel boots, or when built as a module, when the -module is loaded. However, there is some infrastructure, -like the KUnit Wrapper (``tools/testing/kunit/kunit.py``) that does not support -other architectures. +module is loaded. However, there is infrastructure, like the KUnit Wrapper +(``tools/testing/kunit/kunit.py``) that does not support other architectures. -In short, this means that, yes, you can run KUnit on other architectures, but -it might require more work than using KUnit on UML. +In short, yes, you can run KUnit on other architectures, but it might require +more work than using KUnit on UML. For more information, see :ref:`kunit-on-non-uml`. -What is the difference between a unit test and these other kinds of tests? -========================================================================== +What is the difference between a unit test and other kinds of tests? +==================================================================== Most existing tests for the Linux kernel would be categorized as an integration test, or an end-to-end test. -- A unit test is supposed to test a single unit of code in isolation, hence the - name. A unit test should be the finest granularity of testing and as such - should allow all possible code paths to be tested in the code under test; this - is only possible if the code under test is very small and does not have any - external dependencies outside of the test's control like hardware. +- A unit test is supposed to test a single unit of code in isolation. A unit + test should be the finest granularity of testing and, as such, allows all + possible code paths to be tested in the code under test. This is only possible + if the code under test is small and does not have any external dependencies + outside of the test's control like hardware. - An integration test tests the interaction between a minimal set of components, usually just two or three. For example, someone might write an integration test to test the interaction between a driver and a piece of hardware, or to test the interaction between the userspace libraries the kernel provides and - the kernel itself; however, one of these tests would probably not test the + the kernel itself. However, one of these tests would probably not test the entire kernel along with hardware interactions and interactions with the userspace. - An end-to-end test usually tests the entire system from the perspective of the @@ -62,26 +61,26 @@ test, or an end-to-end test. hardware with a production userspace and then trying to exercise some behavior that depends on interactions between the hardware, the kernel, and userspace. -KUnit isn't working, what should I do? -====================================== +KUnit is not working, what should I do? +======================================= Unfortunately, there are a number of things which can break, but here are some things to try. -1. Try running ``./tools/testing/kunit/kunit.py run`` with the ``--raw_output`` +1. Run ``./tools/testing/kunit/kunit.py run`` with the ``--raw_output`` parameter. This might show details or error messages hidden by the kunit_tool parser. 2. Instead of running ``kunit.py run``, try running ``kunit.py config``, ``kunit.py build``, and ``kunit.py exec`` independently. This can help track down where an issue is occurring. (If you think the parser is at fault, you - can run it manually against stdin or a file with ``kunit.py parse``.) -3. Running the UML kernel directly can often reveal issues or error messages - kunit_tool ignores. This should be as simple as running ``./vmlinux`` after - building the UML kernel (e.g., by using ``kunit.py build``). Note that UML - has some unusual requirements (such as the host having a tmpfs filesystem - mounted), and has had issues in the past when built statically and the host - has KASLR enabled. (On older host kernels, you may need to run ``setarch - `uname -m` -R ./vmlinux`` to disable KASLR.) + can run it manually against ``stdin`` or a file with ``kunit.py parse``.) +3. Running the UML kernel directly can often reveal issues or error messages, + ``kunit_tool`` ignores. This should be as simple as running ``./vmlinux`` + after building the UML kernel (for example, by using ``kunit.py build``). + Note that UML has some unusual requirements (such as the host having a tmpfs + filesystem mounted), and has had issues in the past when built statically and + the host has KASLR enabled. (On older host kernels, you may need to run + ``setarch `uname -m` -R ./vmlinux`` to disable KASLR.) 4. Make sure the kernel .config has ``CONFIG_KUNIT=y`` and at least one test (e.g. ``CONFIG_KUNIT_EXAMPLE_TEST=y``). kunit_tool will keep its .config around, so you can see what config was used after running ``kunit.py run``. diff --git a/Documentation/dev-tools/kunit/index.rst b/Documentation/dev-tools/kunit/index.rst index cacb35ec658d..595205348d2d 100644 --- a/Documentation/dev-tools/kunit/index.rst +++ b/Documentation/dev-tools/kunit/index.rst @@ -1,13 +1,17 @@ .. SPDX-License-Identifier: GPL-2.0 -========================================= -KUnit - Unit Testing for the Linux Kernel -========================================= +================================= +KUnit - Linux Kernel Unit Testing +================================= .. toctree:: :maxdepth: 2 + :caption: Contents: start + architecture + run_wrapper + run_manual usage kunit-tool api/index @@ -16,82 +20,94 @@ KUnit - Unit Testing for the Linux Kernel tips running_tips -What is KUnit? -============== - -KUnit is a lightweight unit testing and mocking framework for the Linux kernel. - -KUnit is heavily inspired by JUnit, Python's unittest.mock, and -Googletest/Googlemock for C++. KUnit provides facilities for defining unit test -cases, grouping related test cases into test suites, providing common -infrastructure for running tests, and much more. - -KUnit consists of a kernel component, which provides a set of macros for easily -writing unit tests. Tests written against KUnit will run on kernel boot if -built-in, or when loaded if built as a module. These tests write out results to -the kernel log in `TAP <https://testanything.org/>`_ format. - -To make running these tests (and reading the results) easier, KUnit offers -:doc:`kunit_tool <kunit-tool>`, which builds a `User Mode Linux -<http://user-mode-linux.sourceforge.net>`_ kernel, runs it, and parses the test -results. This provides a quick way of running KUnit tests during development, -without requiring a virtual machine or separate hardware. - -Get started now: Documentation/dev-tools/kunit/start.rst - -Why KUnit? -========== - -A unit test is supposed to test a single unit of code in isolation, hence the -name. A unit test should be the finest granularity of testing and as such should -allow all possible code paths to be tested in the code under test; this is only -possible if the code under test is very small and does not have any external -dependencies outside of the test's control like hardware. - -KUnit provides a common framework for unit tests within the kernel. - -KUnit tests can be run on most architectures, and most tests are architecture -independent. All built-in KUnit tests run on kernel startup. Alternatively, -KUnit and KUnit tests can be built as modules and tests will run when the test -module is loaded. - -.. note:: - - KUnit can also run tests without needing a virtual machine or actual - hardware under User Mode Linux. User Mode Linux is a Linux architecture, - like ARM or x86, which compiles the kernel as a Linux executable. KUnit - can be used with UML either by building with ``ARCH=um`` (like any other - architecture), or by using :doc:`kunit_tool <kunit-tool>`. - -KUnit is fast. Excluding build time, from invocation to completion KUnit can run -several dozen tests in only 10 to 20 seconds; this might not sound like a big -deal to some people, but having such fast and easy to run tests fundamentally -changes the way you go about testing and even writing code in the first place. -Linus himself said in his `git talk at Google -<https://gist.github.com/lorn/1272686/revisions#diff-53c65572127855f1b003db4064a94573R874>`_: - - "... a lot of people seem to think that performance is about doing the - same thing, just doing it faster, and that is not true. That is not what - performance is all about. If you can do something really fast, really - well, people will start using it differently." - -In this context Linus was talking about branching and merging, -but this point also applies to testing. If your tests are slow, unreliable, are -difficult to write, and require a special setup or special hardware to run, -then you wait a lot longer to write tests, and you wait a lot longer to run -tests; this means that tests are likely to break, unlikely to test a lot of -things, and are unlikely to be rerun once they pass. If your tests are really -fast, you run them all the time, every time you make a change, and every time -someone sends you some code. Why trust that someone ran all their tests -correctly on every change when you can just run them yourself in less time than -it takes to read their test log? +This section details the kernel unit testing framework. + +Introduction +============ + +KUnit (Kernel unit testing framework) provides a common framework for +unit tests within the Linux kernel. Using KUnit, you can define groups +of test cases called test suites. The tests either run on kernel boot +if built-in, or load as a module. KUnit automatically flags and reports +failed test cases in the kernel log. The test results appear in `TAP +(Test Anything Protocol) format <https://testanything.org/>`_. It is inspired by +JUnit, Python’s unittest.mock, and GoogleTest/GoogleMock (C++ unit testing +framework). + +KUnit tests are part of the kernel, written in the C (programming) +language, and test parts of the Kernel implementation (example: a C +language function). Excluding build time, from invocation to +completion, KUnit can run around 100 tests in less than 10 seconds. +KUnit can test any kernel component, for example: file system, system +calls, memory management, device drivers and so on. + +KUnit follows the white-box testing approach. The test has access to +internal system functionality. KUnit runs in kernel space and is not +restricted to things exposed to user-space. + +In addition, KUnit has kunit_tool, a script (``tools/testing/kunit/kunit.py``) +that configures the Linux kernel, runs KUnit tests under QEMU or UML (`User Mode +Linux <http://user-mode-linux.sourceforge.net/>`_), parses the test results and +displays them in a user friendly manner. + +Features +-------- + +- Provides a framework for writing unit tests. +- Runs tests on any kernel architecture. +- Runs a test in milliseconds. + +Prerequisites +------------- + +- Any Linux kernel compatible hardware. +- For Kernel under test, Linux kernel version 5.5 or greater. + +Unit Testing +============ + +A unit test tests a single unit of code in isolation. A unit test is the finest +granularity of testing and allows all possible code paths to be tested in the +code under test. This is possible if the code under test is small and does not +have any external dependencies outside of the test's control like hardware. + + +Write Unit Tests +---------------- + +To write good unit tests, there is a simple but powerful pattern: +Arrange-Act-Assert. This is a great way to structure test cases and +defines an order of operations. + +- Arrange inputs and targets: At the start of the test, arrange the data + that allows a function to work. Example: initialize a statement or + object. +- Act on the target behavior: Call your function/code under test. +- Assert expected outcome: Verify that the result (or resulting state) is as + expected. + +Unit Testing Advantages +----------------------- + +- Increases testing speed and development in the long run. +- Detects bugs at initial stage and therefore decreases bug fix cost + compared to acceptance testing. +- Improves code quality. +- Encourages writing testable code. How do I use it? ================ -* Documentation/dev-tools/kunit/start.rst - for new users of KUnit -* Documentation/dev-tools/kunit/tips.rst - for short examples of best practices -* Documentation/dev-tools/kunit/usage.rst - for a more detailed explanation of KUnit features -* Documentation/dev-tools/kunit/api/index.rst - for the list of KUnit APIs used for testing -* Documentation/dev-tools/kunit/kunit-tool.rst - for more information on the kunit_tool helper script -* Documentation/dev-tools/kunit/faq.rst - for answers to some common questions about KUnit +* Documentation/dev-tools/kunit/start.rst - for KUnit new users. +* Documentation/dev-tools/kunit/architecture.rst - KUnit architecture. +* Documentation/dev-tools/kunit/run_wrapper.rst - run kunit_tool. +* Documentation/dev-tools/kunit/run_manual.rst - run tests without kunit_tool. +* Documentation/dev-tools/kunit/usage.rst - write tests. +* Documentation/dev-tools/kunit/tips.rst - best practices with + examples. +* Documentation/dev-tools/kunit/api/index.rst - KUnit APIs + used for testing. +* Documentation/dev-tools/kunit/kunit-tool.rst - kunit_tool helper + script. +* Documentation/dev-tools/kunit/faq.rst - KUnit common questions and + answers. diff --git a/Documentation/dev-tools/kunit/kunit_suitememorydiagram.svg b/Documentation/dev-tools/kunit/kunit_suitememorydiagram.svg new file mode 100644 index 000000000000..cf8fddc27500 --- /dev/null +++ b/Documentation/dev-tools/kunit/kunit_suitememorydiagram.svg @@ -0,0 +1,81 @@ +<?xml version="1.0" encoding="UTF-8"?> +<svg width="796.93" height="555.73" version="1.1" viewBox="0 0 796.93 555.73" xmlns="http://www.w3.org/2000/svg"> + <g transform="translate(-13.724 -17.943)"> + <g fill="#dad4d4" fill-opacity=".91765" stroke="#1a1a1a"> + <rect x="323.56" y="18.443" width="115.75" height="41.331"/> + <rect x="323.56" y="463.09" width="115.75" height="41.331"/> + <rect x="323.56" y="531.84" width="115.75" height="41.331"/> + <rect x="323.56" y="88.931" width="115.75" height="74.231"/> + </g> + <g> + <rect x="323.56" y="421.76" width="115.75" height="41.331" fill="#b9dbc6" stroke="#1a1a1a"/> + <text x="328.00888" y="446.61826" fill="#000000" font-family="sans-serif" font-size="16px" style="line-height:1.25" xml:space="preserve"><tspan x="328.00888" y="446.61826" font-family="monospace" font-size="16px">kunit_suite</tspan></text> + </g> + <g transform="translate(0 -258.6)"> + <rect x="323.56" y="421.76" width="115.75" height="41.331" fill="#b9dbc6" stroke="#1a1a1a"/> + <text x="328.00888" y="446.61826" fill="#000000" font-family="sans-serif" font-size="16px" style="line-height:1.25" xml:space="preserve"><tspan x="328.00888" y="446.61826" font-family="monospace" font-size="16px">kunit_suite</tspan></text> + </g> + <g transform="translate(0 -217.27)"> + <rect x="323.56" y="421.76" width="115.75" height="41.331" fill="#b9dbc6" stroke="#1a1a1a"/> + <text x="328.00888" y="446.61826" fill="#000000" font-family="sans-serif" font-size="16px" style="line-height:1.25" xml:space="preserve"><tspan x="328.00888" y="446.61826" font-family="monospace" font-size="16px">kunit_suite</tspan></text> + </g> + <g transform="translate(0 -175.94)"> + <rect x="323.56" y="421.76" width="115.75" height="41.331" fill="#b9dbc6" stroke="#1a1a1a"/> + <text x="328.00888" y="446.61826" fill="#000000" font-family="sans-serif" font-size="16px" style="line-height:1.25" xml:space="preserve"><tspan x="328.00888" y="446.61826" font-family="monospace" font-size="16px">kunit_suite</tspan></text> + </g> + <g transform="translate(0 -134.61)"> + <rect x="323.56" y="421.76" width="115.75" height="41.331" fill="#b9dbc6" stroke="#1a1a1a"/> + <text x="328.00888" y="446.61826" fill="#000000" font-family="sans-serif" font-size="16px" style="line-height:1.25" xml:space="preserve"><tspan x="328.00888" y="446.61826" font-family="monospace" font-size="16px">kunit_suite</tspan></text> + </g> + <g transform="translate(0 -41.331)"> + <rect x="323.56" y="421.76" width="115.75" height="41.331" fill="#b9dbc6" stroke="#1a1a1a"/> + <text x="328.00888" y="446.61826" fill="#000000" font-family="sans-serif" font-size="16px" style="line-height:1.25" xml:space="preserve"><tspan x="328.00888" y="446.61826" font-family="monospace" font-size="16px">kunit_suite</tspan></text> + </g> + <g transform="translate(3.4459e-5 -.71088)"> + <rect x="502.19" y="143.16" width="201.13" height="41.331" fill="#dad4d4" fill-opacity=".91765" stroke="#1a1a1a"/> + <text x="512.02319" y="168.02026" font-family="sans-serif" font-size="16px" style="line-height:1.25" xml:space="preserve"><tspan x="512.02319" y="168.02026" font-family="monospace">_kunit_suites_start</tspan></text> + </g> + <g transform="translate(3.0518e-5 -3.1753)"> + <rect x="502.19" y="445.69" width="201.13" height="41.331" fill="#dad4d4" fill-opacity=".91765" stroke="#1a1a1a"/> + <text x="521.61694" y="470.54846" font-family="sans-serif" font-size="16px" style="line-height:1.25" xml:space="preserve"><tspan x="521.61694" y="470.54846" font-family="monospace">_kunit_suites_end</tspan></text> + </g> + <rect x="14.224" y="277.78" width="134.47" height="41.331" fill="#dad4d4" fill-opacity=".91765" stroke="#1a1a1a"/> + <text x="32.062176" y="304.41287" font-family="sans-serif" font-size="16px" style="line-height:1.25" xml:space="preserve"><tspan x="32.062176" y="304.41287" font-family="monospace">.init.data</tspan></text> + <g transform="translate(217.98 145.12)" stroke="#1a1a1a"> + <circle cx="149.97" cy="373.01" r="3.4012"/> + <circle cx="163.46" cy="373.01" r="3.4012"/> + <circle cx="176.95" cy="373.01" r="3.4012"/> + </g> + <g transform="translate(217.98 -298.66)" stroke="#1a1a1a"> + <circle cx="149.97" cy="373.01" r="3.4012"/> + <circle cx="163.46" cy="373.01" r="3.4012"/> + <circle cx="176.95" cy="373.01" r="3.4012"/> + </g> + <g stroke="#1a1a1a"> + <rect x="323.56" y="328.49" width="115.75" height="51.549" fill="#b9dbc6"/> + <g transform="translate(217.98 -18.75)"> + <circle cx="149.97" cy="373.01" r="3.4012"/> + <circle cx="163.46" cy="373.01" r="3.4012"/> + <circle cx="176.95" cy="373.01" r="3.4012"/> + </g> + </g> + <g transform="scale(1.0933 .9147)" stroke-width="32.937" aria-label="{"> + <path d="m275.49 545.57c-35.836-8.432-47.43-24.769-47.957-64.821v-88.536c-0.527-44.795-10.54-57.97-49.538-67.456 38.998-10.013 49.011-23.715 49.538-67.983v-88.536c0.527-40.052 12.121-56.389 47.957-64.821v-5.797c-65.348 0-85.901 17.391-86.955 73.253v93.806c-0.527 36.89-10.013 50.065-44.795 59.551 34.782 10.013 44.268 23.188 44.795 60.078v93.279c1.581 56.389 21.607 73.78 86.955 73.78z"/> + </g> + <g transform="scale(1.1071 .90325)" stroke-width="14.44" aria-label="{"> + <path d="m461.46 443.55c-15.711-3.6967-20.794-10.859-21.025-28.418v-38.815c-0.23104-19.639-4.6209-25.415-21.718-29.574 17.097-4.3898 21.487-10.397 21.718-29.805v-38.815c0.23105-17.559 5.314-24.722 21.025-28.418v-2.5415c-28.649 0-37.66 7.6244-38.122 32.115v41.126c-0.23105 16.173-4.3898 21.949-19.639 26.108 15.249 4.3898 19.408 10.166 19.639 26.339v40.895c0.69313 24.722 9.4728 32.346 38.122 32.346z"/> + </g> + <path d="m449.55 161.84v2.5h49.504v-2.5z" color="#000000" style="-inkscape-stroke:none"/> + <g fill-rule="evenodd"> + <path d="m443.78 163.09 8.65-5v10z" color="#000000" stroke-width="1pt" style="-inkscape-stroke:none"/> + <path d="m453.1 156.94-10.648 6.1543 0.99804 0.57812 9.6504 5.5781zm-1.334 2.3125v7.6856l-6.6504-3.8438z" color="#000000" style="-inkscape-stroke:none"/> + </g> + <path d="m449.55 461.91v2.5h49.504v-2.5z" color="#000000" style="-inkscape-stroke:none"/> + <g fill-rule="evenodd"> + <path d="m443.78 463.16 8.65-5v10z" color="#000000" stroke-width="1pt" style="-inkscape-stroke:none"/> + <path d="m453.1 457-10.648 6.1562 0.99804 0.57617 9.6504 5.5781zm-1.334 2.3125v7.6856l-6.6504-3.8438z" color="#000000" style="-inkscape-stroke:none"/> + </g> + <rect x="515.64" y="223.9" width="294.52" height="178.49" fill="#dad4d4" fill-opacity=".91765" stroke="#1a1a1a"/> + <text x="523.33319" y="262.52542" font-family="monospace" font-size="14.667px" style="line-height:1.25" xml:space="preserve"><tspan x="523.33319" y="262.52542"><tspan fill="#008000" font-family="monospace" font-size="14.667px" font-weight="bold">struct</tspan> kunit_suite {</tspan><tspan x="523.33319" y="280.8588"><tspan fill="#008000" font-family="monospace" font-size="14.667px" font-weight="bold"> const char</tspan> name[<tspan fill="#ff00ff" font-size="14.667px">256</tspan>];</tspan><tspan x="523.33319" y="299.19217"> <tspan fill="#008000" font-family="monospace" font-size="14.667px" font-weight="bold">int</tspan> (*init)(<tspan fill="#008000" font-family="monospace" font-size="14.667px" font-weight="bold">struct</tspan> kunit *);</tspan><tspan x="523.33319" y="317.52554"> <tspan fill="#008000" font-family="monospace" font-size="14.667px" font-weight="bold">void</tspan> (*exit)(<tspan fill="#008000" font-family="monospace" font-size="14.667px" font-weight="bold">struct</tspan> kunit *);</tspan><tspan x="523.33319" y="335.85892"> <tspan fill="#008000" font-family="monospace" font-size="14.667px" font-weight="bold">struct</tspan> kunit_case *test_cases;</tspan><tspan x="523.33319" y="354.19229"> ...</tspan><tspan x="523.33319" y="372.52567">};</tspan></text> + </g> +</svg> diff --git a/Documentation/dev-tools/kunit/run_manual.rst b/Documentation/dev-tools/kunit/run_manual.rst new file mode 100644 index 000000000000..e7b46421f247 --- /dev/null +++ b/Documentation/dev-tools/kunit/run_manual.rst @@ -0,0 +1,57 @@ +.. SPDX-License-Identifier: GPL-2.0 + +============================ +Run Tests without kunit_tool +============================ + +If we do not want to use kunit_tool (For example: we want to integrate +with other systems, or run tests on real hardware), we can +include KUnit in any kernel, read out results, and parse manually. + +.. note:: KUnit is not designed for use in a production system. It is + possible that tests may reduce the stability or security of + the system. + +Configure the Kernel +==================== + +KUnit tests can run without kunit_tool. This can be useful, if: + +- We have an existing kernel configuration to test. +- Need to run on real hardware (or using an emulator/VM kunit_tool + does not support). +- Wish to integrate with some existing testing systems. + +KUnit is configured with the ``CONFIG_KUNIT`` option, and individual +tests can also be built by enabling their config options in our +``.config``. KUnit tests usually (but don't always) have config options +ending in ``_KUNIT_TEST``. Most tests can either be built as a module, +or be built into the kernel. + +.. note :: + + We can enable the ``KUNIT_ALL_TESTS`` config option to + automatically enable all tests with satisfied dependencies. This is + a good way of quickly testing everything applicable to the current + config. + +Once we have built our kernel (and/or modules), it is simple to run +the tests. If the tests are built-in, they will run automatically on the +kernel boot. The results will be written to the kernel log (``dmesg``) +in TAP format. + +If the tests are built as modules, they will run when the module is +loaded. + +.. code-block :: bash + + # modprobe example-test + +The results will appear in TAP format in ``dmesg``. + +.. note :: + + If ``CONFIG_KUNIT_DEBUGFS`` is enabled, KUnit test results will + be accessible from the ``debugfs`` filesystem (if mounted). + They will be in ``/sys/kernel/debug/kunit/<test_suite>/results``, in + TAP format. diff --git a/Documentation/dev-tools/kunit/run_wrapper.rst b/Documentation/dev-tools/kunit/run_wrapper.rst new file mode 100644 index 000000000000..653985ce9cae --- /dev/null +++ b/Documentation/dev-tools/kunit/run_wrapper.rst @@ -0,0 +1,247 @@ +.. SPDX-License-Identifier: GPL-2.0 + +========================= +Run Tests with kunit_tool +========================= + +We can either run KUnit tests using kunit_tool or can run tests +manually, and then use kunit_tool to parse the results. To run tests +manually, see: Documentation/dev-tools/kunit/run_manual.rst. +As long as we can build the kernel, we can run KUnit. + +kunit_tool is a Python script which configures and builds a kernel, runs +tests, and formats the test results. + +Run command: + +.. code-block:: + + ./tools/testing/kunit/kunit.py run + +We should see the following: + +.. code-block:: + + Generating .config... + Building KUnit kernel... + Starting KUnit kernel... + +We may want to use the following options: + +.. code-block:: + + ./tools/testing/kunit/kunit.py run --timeout=30 --jobs=`nproc --all + +- ``--timeout`` sets a maximum amount of time for tests to run. +- ``--jobs`` sets the number of threads to build the kernel. + +kunit_tool will generate a ``.kunitconfig`` with a default +configuration, if no other ``.kunitconfig`` file exists +(in the build directory). In addition, it verifies that the +generated ``.config`` file contains the ``CONFIG`` options in the +``.kunitconfig``. +It is also possible to pass a separate ``.kunitconfig`` fragment to +kunit_tool. This is useful if we have several different groups of +tests we want to run independently, or if we want to use pre-defined +test configs for certain subsystems. + +To use a different ``.kunitconfig`` file (such as one +provided to test a particular subsystem), pass it as an option: + +.. code-block:: + + ./tools/testing/kunit/kunit.py run --kunitconfig=fs/ext4/.kunitconfig + +To view kunit_tool flags (optional command-line arguments), run: + +.. code-block:: + + ./tools/testing/kunit/kunit.py run --help + +Create a ``.kunitconfig`` File +=============================== + +If we want to run a specific set of tests (rather than those listed +in the KUnit ``defconfig``), we can provide Kconfig options in the +``.kunitconfig`` file. For default .kunitconfig, see: +https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/tools/testing/kunit/configs/default.config. +A ``.kunitconfig`` is a ``minconfig`` (a .config +generated by running ``make savedefconfig``), used for running a +specific set of tests. This file contains the regular Kernel configs +with specific test targets. The ``.kunitconfig`` also +contains any other config options required by the tests (For example: +dependencies for features under tests, configs that enable/disable +certain code blocks, arch configs and so on). + +To create a ``.kunitconfig``, using the KUnit ``defconfig``: + +.. code-block:: + + cd $PATH_TO_LINUX_REPO + cp tools/testing/kunit/configs/default.config .kunit/.kunitconfig + +We can then add any other Kconfig options. For example: + +.. code-block:: + + CONFIG_LIST_KUNIT_TEST=y + +kunit_tool ensures that all config options in ``.kunitconfig`` are +set in the kernel ``.config`` before running the tests. It warns if we +have not included the options dependencies. + +.. note:: Removing something from the ``.kunitconfig`` will + not rebuild the ``.config file``. The configuration is only + updated if the ``.kunitconfig`` is not a subset of ``.config``. + This means that we can use other tools + (For example: ``make menuconfig``) to adjust other config options. + The build dir needs to be set for ``make menuconfig`` to + work, therefore by default use ``make O=.kunit menuconfig``. + +Configure, Build, and Run Tests +=============================== + +If we want to make manual changes to the KUnit build process, we +can run part of the KUnit build process independently. +When running kunit_tool, from a ``.kunitconfig``, we can generate a +``.config`` by using the ``config`` argument: + +.. code-block:: + + ./tools/testing/kunit/kunit.py config + +To build a KUnit kernel from the current ``.config``, we can use the +``build`` argument: + +.. code-block:: + + ./tools/testing/kunit/kunit.py build + +If we already have built UML kernel with built-in KUnit tests, we +can run the kernel, and display the test results with the ``exec`` +argument: + +.. code-block:: + + ./tools/testing/kunit/kunit.py exec + +The ``run`` command discussed in section: **Run Tests with kunit_tool**, +is equivalent to running the above three commands in sequence. + +Parse Test Results +================== + +KUnit tests output displays results in TAP (Test Anything Protocol) +format. When running tests, kunit_tool parses this output and prints +a summary. To see the raw test results in TAP format, we can pass the +``--raw_output`` argument: + +.. code-block:: + + ./tools/testing/kunit/kunit.py run --raw_output + +If we have KUnit results in the raw TAP format, we can parse them and +print the human-readable summary with the ``parse`` command for +kunit_tool. This accepts a filename for an argument, or will read from +standard input. + +.. code-block:: bash + + # Reading from a file + ./tools/testing/kunit/kunit.py parse /var/log/dmesg + # Reading from stdin + dmesg | ./tools/testing/kunit/kunit.py parse + +Run Selected Test Suites +======================== + +By passing a bash style glob filter to the ``exec`` or ``run`` +commands, we can run a subset of the tests built into a kernel . For +example: if we only want to run KUnit resource tests, use: + +.. code-block:: + + ./tools/testing/kunit/kunit.py run 'kunit-resource*' + +This uses the standard glob format with wildcard characters. + +Run Tests on qemu +================= + +kunit_tool supports running tests on qemu as well as +via UML. To run tests on qemu, by default it requires two flags: + +- ``--arch``: Selects a configs collection (Kconfig, qemu config options + and so on), that allow KUnit tests to be run on the specified + architecture in a minimal way. The architecture argument is same as + the option name passed to the ``ARCH`` variable used by Kbuild. + Not all architectures currently support this flag, but we can use + ``--qemu_config`` to handle it. If ``um`` is passed (or this flag + is ignored), the tests will run via UML. Non-UML architectures, + for example: i386, x86_64, arm and so on; run on qemu. + +- ``--cross_compile``: Specifies the Kbuild toolchain. It passes the + same argument as passed to the ``CROSS_COMPILE`` variable used by + Kbuild. As a reminder, this will be the prefix for the toolchain + binaries such as GCC. For example: + + - ``sparc64-linux-gnu`` if we have the sparc toolchain installed on + our system. + + - ``$HOME/toolchains/microblaze/gcc-9.2.0-nolibc/microblaze-linux/bin/microblaze-linux`` + if we have downloaded the microblaze toolchain from the 0-day + website to a directory in our home directory called toolchains. + +If we want to run KUnit tests on an architecture not supported by +the ``--arch`` flag, or want to run KUnit tests on qemu using a +non-default configuration; then we can write our own``QemuConfig``. +These ``QemuConfigs`` are written in Python. They have an import line +``from..qemu_config import QemuArchParams`` at the top of the file. +The file must contain a variable called ``QEMU_ARCH`` that has an +instance of ``QemuArchParams`` assigned to it. See example in: +``tools/testing/kunit/qemu_configs/x86_64.py``. + +Once we have a ``QemuConfig``, we can pass it into kunit_tool, +using the ``--qemu_config`` flag. When used, this flag replaces the +``--arch`` flag. For example: using +``tools/testing/kunit/qemu_configs/x86_64.py``, the invocation appear +as + +.. code-block:: bash + + ./tools/testing/kunit/kunit.py run \ + --timeout=60 \ + --jobs=12 \ + --qemu_config=./tools/testing/kunit/qemu_configs/x86_64.py + +To run existing KUnit tests on non-UML architectures, see: +Documentation/dev-tools/kunit/non_uml.rst. + +Command-Line Arguments +====================== + +kunit_tool has a number of other command-line arguments which can +be useful for our test environment. Below the most commonly used +command line arguments: + +- ``--help``: Lists all available options. To list common options, + place ``--help`` before the command. To list options specific to that + command, place ``--help`` after the command. + + .. note:: Different commands (``config``, ``build``, ``run``, etc) + have different supported options. +- ``--build_dir``: Specifies kunit_tool build directory. It includes + the ``.kunitconfig``, ``.config`` files and compiled kernel. + +- ``--make_options``: Specifies additional options to pass to make, when + compiling a kernel (using ``build`` or ``run`` commands). For example: + to enable compiler warnings, we can pass ``--make_options W=1``. + +- ``--alltests``: Builds a UML kernel with all config options enabled + using ``make allyesconfig``. This allows us to run as many tests as + possible. + + .. note:: It is slow and prone to breakage as new options are + added or modified. Instead, enable all tests + which have satisfied dependencies by adding + ``CONFIG_KUNIT_ALL_TESTS=y`` to your ``.kunitconfig``. diff --git a/Documentation/dev-tools/kunit/start.rst b/Documentation/dev-tools/kunit/start.rst index 1e00f9226f74..ad168d16968f 100644 --- a/Documentation/dev-tools/kunit/start.rst +++ b/Documentation/dev-tools/kunit/start.rst @@ -4,132 +4,137 @@ Getting Started =============== -Installing dependencies +Installing Dependencies ======================= -KUnit has the same dependencies as the Linux kernel. As long as you can build -the kernel, you can run KUnit. +KUnit has the same dependencies as the Linux kernel. As long as you can +build the kernel, you can run KUnit. -Running tests with the KUnit Wrapper -==================================== -Included with KUnit is a simple Python wrapper which runs tests under User Mode -Linux, and formats the test results. - -The wrapper can be run with: +Running tests with kunit_tool +============================= +kunit_tool is a Python script, which configures and builds a kernel, runs +tests, and formats the test results. From the kernel repository, you +can run kunit_tool: .. code-block:: bash ./tools/testing/kunit/kunit.py run -For more information on this wrapper (also called kunit_tool) check out the -Documentation/dev-tools/kunit/kunit-tool.rst page. +For more information on this wrapper, see: +Documentation/dev-tools/kunit/run_wrapper.rst. + +Creating a ``.kunitconfig`` +--------------------------- + +By default, kunit_tool runs a selection of tests. However, you can specify which +unit tests to run by creating a ``.kunitconfig`` file with kernel config options +that enable only a specific set of tests and their dependencies. +The ``.kunitconfig`` file contains a list of kconfig options which are required +to run the desired targets. The ``.kunitconfig`` also contains any other test +specific config options, such as test dependencies. For example: the +``FAT_FS`` tests - ``FAT_KUNIT_TEST``, depends on +``FAT_FS``. ``FAT_FS`` can be enabled by selecting either ``MSDOS_FS`` +or ``VFAT_FS``. To run ``FAT_KUNIT_TEST``, the ``.kunitconfig`` has: -Creating a .kunitconfig ------------------------ -If you want to run a specific set of tests (rather than those listed in the -KUnit defconfig), you can provide Kconfig options in the ``.kunitconfig`` file. -This file essentially contains the regular Kernel config, with the specific -test targets as well. The ``.kunitconfig`` should also contain any other config -options required by the tests. +.. code-block:: none + + CONFIG_KUNIT=y + CONFIG_MSDOS_FS=y + CONFIG_FAT_KUNIT_TEST=y -A good starting point for a ``.kunitconfig`` is the KUnit defconfig: +1. A good starting point for the ``.kunitconfig``, is the KUnit default + config. Run the command: .. code-block:: bash cd $PATH_TO_LINUX_REPO cp tools/testing/kunit/configs/default.config .kunitconfig -You can then add any other Kconfig options you wish, e.g.: +.. note :: + You may want to remove CONFIG_KUNIT_ALL_TESTS from the ``.kunitconfig`` as + it will enable a number of additional tests that you may not want. + +2. You can then add any other Kconfig options, for example: .. code-block:: none CONFIG_LIST_KUNIT_TEST=y -:doc:`kunit_tool <kunit-tool>` will ensure that all config options set in -``.kunitconfig`` are set in the kernel ``.config`` before running the tests. -It'll warn you if you haven't included the dependencies of the options you're -using. +Before running the tests, kunit_tool ensures that all config options +set in ``.kunitconfig`` are set in the kernel ``.config``. It will warn +you if you have not included dependencies for the options used. -.. note:: - Note that removing something from the ``.kunitconfig`` will not trigger a - rebuild of the ``.config`` file: the configuration is only updated if the - ``.kunitconfig`` is not a subset of ``.config``. This means that you can use - other tools (such as make menuconfig) to adjust other config options. +.. note :: + If you change the ``.kunitconfig``, kunit.py will trigger a rebuild of the + ``.config`` file. But you can edit the ``.config`` file directly or with + tools like ``make menuconfig O=.kunit``. As long as its a superset of + ``.kunitconfig``, kunit.py won't overwrite your changes. - -Running the tests (KUnit Wrapper) ---------------------------------- - -To make sure that everything is set up correctly, simply invoke the Python -wrapper from your kernel repo: +Running Tests (KUnit Wrapper) +----------------------------- +1. To make sure that everything is set up correctly, invoke the Python + wrapper from your kernel repository: .. code-block:: bash ./tools/testing/kunit/kunit.py run -.. note:: - You may want to run ``make mrproper`` first. - If everything worked correctly, you should see the following: -.. code-block:: bash +.. code-block:: Generating .config ... Building KUnit Kernel ... Starting KUnit Kernel ... -followed by a list of tests that are run. All of them should be passing. +The tests will pass or fail. -.. note:: - Because it is building a lot of sources for the first time, the - ``Building KUnit kernel`` step may take a while. +.. note :: + Because it is building a lot of sources for the first time, the + ``Building KUnit kernel`` may take a while. -Running tests without the KUnit Wrapper +Running Tests without the KUnit Wrapper ======================================= - -If you'd rather not use the KUnit Wrapper (if, for example, you need to -integrate with other systems, or use an architecture other than UML), KUnit can -be included in any kernel, and the results read out and parsed manually. - -.. note:: - KUnit is not designed for use in a production system, and it's possible that - tests may reduce the stability or security of the system. - - - -Configuring the kernel +If you do not want to use the KUnit Wrapper (for example: you want code +under test to integrate with other systems, or use a different/ +unsupported architecture or configuration), KUnit can be included in +any kernel, and the results are read out and parsed manually. + +.. note :: + ``CONFIG_KUNIT`` should not be enabled in a production environment. + Enabling KUnit disables Kernel Address-Space Layout Randomization + (KASLR), and tests may affect the state of the kernel in ways not + suitable for production. + +Configuring the Kernel ---------------------- +To enable KUnit itself, you need to enable the ``CONFIG_KUNIT`` Kconfig +option (under Kernel Hacking/Kernel Testing and Coverage in +``menuconfig``). From there, you can enable any KUnit tests. They +usually have config options ending in ``_KUNIT_TEST``. -In order to enable KUnit itself, you simply need to enable the ``CONFIG_KUNIT`` -Kconfig option (it's under Kernel Hacking/Kernel Testing and Coverage in -menuconfig). From there, you can enable any KUnit tests you want: they usually -have config options ending in ``_KUNIT_TEST``. - -KUnit and KUnit tests can be compiled as modules: in this case the tests in a -module will be run when the module is loaded. +KUnit and KUnit tests can be compiled as modules. The tests in a module +will run when the module is loaded. - -Running the tests (w/o KUnit Wrapper) +Running Tests (without KUnit Wrapper) ------------------------------------- +Build and run your kernel. In the kernel log, the test output is printed +out in the TAP format. This will only happen by default if KUnit/tests +are built-in. Otherwise the module will need to be loaded. -Build and run your kernel as usual. Test output will be written to the kernel -log in `TAP <https://testanything.org/>`_ format. - -.. note:: - It's possible that there will be other lines and/or data interspersed in the - TAP output. - +.. note :: + Some lines and/or data may get interspersed in the TAP output. -Writing your first test +Writing Your First Test ======================= +In your kernel repository, let's add some code that we can test. -In your kernel repo let's add some code that we can test. Create a file -``drivers/misc/example.h`` with the contents: +1. Create a file ``drivers/misc/example.h``, which includes: .. code-block:: c int misc_example_add(int left, int right); -create a file ``drivers/misc/example.c``: +2. Create a file ``drivers/misc/example.c``, which includes: .. code-block:: c @@ -142,21 +147,22 @@ create a file ``drivers/misc/example.c``: return left + right; } -Now add the following lines to ``drivers/misc/Kconfig``: +3. Add the following lines to ``drivers/misc/Kconfig``: .. code-block:: kconfig config MISC_EXAMPLE bool "My example" -and the following lines to ``drivers/misc/Makefile``: +4. Add the following lines to ``drivers/misc/Makefile``: .. code-block:: make obj-$(CONFIG_MISC_EXAMPLE) += example.o -Now we are ready to write the test. The test will be in -``drivers/misc/example-test.c``: +Now we are ready to write the test cases. + +1. Add the below test case in ``drivers/misc/example_test.c``: .. code-block:: c @@ -191,7 +197,7 @@ Now we are ready to write the test. The test will be in }; kunit_test_suite(misc_example_test_suite); -Now add the following to ``drivers/misc/Kconfig``: +2. Add the following lines to ``drivers/misc/Kconfig``: .. code-block:: kconfig @@ -200,20 +206,20 @@ Now add the following to ``drivers/misc/Kconfig``: depends on MISC_EXAMPLE && KUNIT=y default KUNIT_ALL_TESTS -and the following to ``drivers/misc/Makefile``: +3. Add the following lines to ``drivers/misc/Makefile``: .. code-block:: make - obj-$(CONFIG_MISC_EXAMPLE_TEST) += example-test.o + obj-$(CONFIG_MISC_EXAMPLE_TEST) += example_test.o -Now add it to your ``.kunitconfig``: +4. Add the following lines to ``.kunitconfig``: .. code-block:: none CONFIG_MISC_EXAMPLE=y CONFIG_MISC_EXAMPLE_TEST=y -Now you can run the test: +5. Run the test: .. code-block:: bash @@ -227,16 +233,23 @@ You should see the following failure: [16:08:57] [PASSED] misc-example:misc_example_add_test_basic [16:08:57] [FAILED] misc-example:misc_example_test_failure [16:08:57] EXPECTATION FAILED at drivers/misc/example-test.c:17 - [16:08:57] This test never passes. + [16:08:57] This test never passes. ... -Congrats! You just wrote your first KUnit test! +Congrats! You just wrote your first KUnit test. Next Steps ========== -* Check out the Documentation/dev-tools/kunit/tips.rst page for tips on - writing idiomatic KUnit tests. -* Check out the :doc:`running_tips` page for tips on - how to make running KUnit tests easier. -* Optional: see the :doc:`usage` page for a more - in-depth explanation of KUnit. + +* Documentation/dev-tools/kunit/architecture.rst - KUnit architecture. +* Documentation/dev-tools/kunit/run_wrapper.rst - run kunit_tool. +* Documentation/dev-tools/kunit/run_manual.rst - run tests without kunit_tool. +* Documentation/dev-tools/kunit/usage.rst - write tests. +* Documentation/dev-tools/kunit/tips.rst - best practices with + examples. +* Documentation/dev-tools/kunit/api/index.rst - KUnit APIs + used for testing. +* Documentation/dev-tools/kunit/kunit-tool.rst - kunit_tool helper + script. +* Documentation/dev-tools/kunit/faq.rst - KUnit common questions and + answers. diff --git a/Documentation/dev-tools/kunit/style.rst b/Documentation/dev-tools/kunit/style.rst index 8dbcdc552606..b6d0d7359f00 100644 --- a/Documentation/dev-tools/kunit/style.rst +++ b/Documentation/dev-tools/kunit/style.rst @@ -4,37 +4,36 @@ Test Style and Nomenclature =========================== -To make finding, writing, and using KUnit tests as simple as possible, it's +To make finding, writing, and using KUnit tests as simple as possible, it is strongly encouraged that they are named and written according to the guidelines -below. While it's possible to write KUnit tests which do not follow these rules, +below. While it is possible to write KUnit tests which do not follow these rules, they may break some tooling, may conflict with other tests, and may not be run automatically by testing systems. -It's recommended that you only deviate from these guidelines when: +It is recommended that you only deviate from these guidelines when: -1. Porting tests to KUnit which are already known with an existing name, or -2. Writing tests which would cause serious problems if automatically run (e.g., - non-deterministically producing false positives or negatives, or taking an - extremely long time to run). +1. Porting tests to KUnit which are already known with an existing name. +2. Writing tests which would cause serious problems if automatically run. For + example, non-deterministically producing false positives or negatives, or + taking a long time to run. Subsystems, Suites, and Tests ============================= -In order to make tests as easy to find as possible, they're grouped into suites -and subsystems. A test suite is a group of tests which test a related area of -the kernel, and a subsystem is a set of test suites which test different parts -of the same kernel subsystem or driver. +To make tests easy to find, they are grouped into suites and subsystems. A test +suite is a group of tests which test a related area of the kernel. A subsystem +is a set of test suites which test different parts of a kernel subsystem +or a driver. Subsystems ---------- Every test suite must belong to a subsystem. A subsystem is a collection of one or more KUnit test suites which test the same driver or part of the kernel. A -rule of thumb is that a test subsystem should match a single kernel module. If -the code being tested can't be compiled as a module, in many cases the subsystem -should correspond to a directory in the source tree or an entry in the -MAINTAINERS file. If unsure, follow the conventions set by tests in similar -areas. +test subsystem should match a single kernel module. If the code being tested +cannot be compiled as a module, in many cases the subsystem should correspond to +a directory in the source tree or an entry in the ``MAINTAINERS`` file. If +unsure, follow the conventions set by tests in similar areas. Test subsystems should be named after the code being tested, either after the module (wherever possible), or after the directory or files being tested. Test @@ -42,9 +41,8 @@ subsystems should be named to avoid ambiguity where necessary. If a test subsystem name has multiple components, they should be separated by underscores. *Do not* include "test" or "kunit" directly in the subsystem name -unless you are actually testing other tests or the kunit framework itself. - -Example subsystems could be: +unless we are actually testing other tests or the kunit framework itself. For +example, subsystems could be called: ``ext4`` Matches the module and filesystem name. @@ -56,48 +54,46 @@ Example subsystems could be: Has several components (``snd``, ``hda``, ``codec``, ``hdmi``) separated by underscores. Matches the module name. -Avoid names like these: +Avoid names as shown in examples below: ``linear-ranges`` Names should use underscores, not dashes, to separate words. Prefer ``linear_ranges``. ``qos-kunit-test`` - As well as using underscores, this name should not have "kunit-test" as a - suffix, and ``qos`` is ambiguous as a subsystem name. ``power_qos`` would be a - better name. + This name should use underscores, and not have "kunit-test" as a + suffix. ``qos`` is also ambiguous as a subsystem name, because several parts + of the kernel have a ``qos`` subsystem. ``power_qos`` would be a better name. ``pc_parallel_port`` The corresponding module name is ``parport_pc``, so this subsystem should also be named ``parport_pc``. .. note:: - The KUnit API and tools do not explicitly know about subsystems. They're - simply a way of categorising test suites and naming modules which - provides a simple, consistent way for humans to find and run tests. This - may change in the future, though. + The KUnit API and tools do not explicitly know about subsystems. They are + a way of categorizing test suites and naming modules which provides a + simple, consistent way for humans to find and run tests. This may change + in the future. Suites ------ KUnit tests are grouped into test suites, which cover a specific area of -functionality being tested. Test suites can have shared initialisation and -shutdown code which is run for all tests in the suite. -Not all subsystems will need to be split into multiple test suites (e.g. simple drivers). +functionality being tested. Test suites can have shared initialization and +shutdown code which is run for all tests in the suite. Not all subsystems need +to be split into multiple test suites (for example, simple drivers). Test suites are named after the subsystem they are part of. If a subsystem contains several suites, the specific area under test should be appended to the subsystem name, separated by an underscore. In the event that there are multiple types of test using KUnit within a -subsystem (e.g., both unit tests and integration tests), they should be put into -separate suites, with the type of test as the last element in the suite name. -Unless these tests are actually present, avoid using ``_test``, ``_unittest`` or -similar in the suite name. +subsystem (for example, both unit tests and integration tests), they should be +put into separate suites, with the type of test as the last element in the suite +name. Unless these tests are actually present, avoid using ``_test``, ``_unittest`` +or similar in the suite name. The full test suite name (including the subsystem name) should be specified as the ``.name`` member of the ``kunit_suite`` struct, and forms the base for the -module name (see below). - -Example test suites could include: +module name. For example, test suites could include: ``ext4_inode`` Part of the ``ext4`` subsystem, testing the ``inode`` area. @@ -109,26 +105,27 @@ Example test suites could include: The ``kasan`` subsystem has only one suite, so the suite name is the same as the subsystem name. -Avoid names like: +Avoid names, for example: ``ext4_ext4_inode`` - There's no reason to state the subsystem twice. + There is no reason to state the subsystem twice. ``property_entry`` The suite name is ambiguous without the subsystem name. ``kasan_integration_test`` Because there is only one suite in the ``kasan`` subsystem, the suite should - just be called ``kasan``. There's no need to redundantly add - ``integration_test``. Should a separate test suite with, for example, unit - tests be added, then that suite could be named ``kasan_unittest`` or similar. + just be called as ``kasan``. Do not redundantly add + ``integration_test``. It should be a separate test suite. For example, if the + unit tests are added, then that suite could be named as ``kasan_unittest`` or + similar. Test Cases ---------- Individual tests consist of a single function which tests a constrained -codepath, property, or function. In the test output, individual tests' results -will show up as subtests of the suite's results. +codepath, property, or function. In the test output, an individual test's +results will show up as subtests of the suite's results. -Tests should be named after what they're testing. This is often the name of the +Tests should be named after what they are testing. This is often the name of the function being tested, with a description of the input or codepath being tested. As tests are C functions, they should be named and written in accordance with the kernel coding style. @@ -136,7 +133,7 @@ the kernel coding style. .. note:: As tests are themselves functions, their names cannot conflict with other C identifiers in the kernel. This may require some creative - naming. It's a good idea to make your test functions `static` to avoid + naming. It is a good idea to make your test functions `static` to avoid polluting the global namespace. Example test names include: @@ -162,16 +159,16 @@ This Kconfig entry must: * be named ``CONFIG_<name>_KUNIT_TEST``: where <name> is the name of the test suite. * be listed either alongside the config entries for the driver/subsystem being - tested, or be under [Kernel Hacking]→[Kernel Testing and Coverage] -* depend on ``CONFIG_KUNIT`` + tested, or be under [Kernel Hacking]->[Kernel Testing and Coverage] +* depend on ``CONFIG_KUNIT``. * be visible only if ``CONFIG_KUNIT_ALL_TESTS`` is not enabled. * have a default value of ``CONFIG_KUNIT_ALL_TESTS``. -* have a brief description of KUnit in the help text +* have a brief description of KUnit in the help text. -Unless there's a specific reason not to (e.g. the test is unable to be built as -a module), Kconfig entries for tests should be tristate. +If we are not able to meet above conditions (for example, the test is unable to +be built as a module), Kconfig entries for tests should be tristate. -An example Kconfig entry: +For example, a Kconfig entry might look like: .. code-block:: none @@ -182,8 +179,8 @@ An example Kconfig entry: help This builds unit tests for foo. - For more information on KUnit and unit tests in general, please refer - to the KUnit documentation in Documentation/dev-tools/kunit/. + For more information on KUnit and unit tests in general, + please refer to the KUnit documentation in Documentation/dev-tools/kunit/. If unsure, say N. diff --git a/Documentation/dev-tools/kunit/usage.rst b/Documentation/dev-tools/kunit/usage.rst index 63f1bb89ebf5..76af931a332c 100644 --- a/Documentation/dev-tools/kunit/usage.rst +++ b/Documentation/dev-tools/kunit/usage.rst @@ -1,57 +1,13 @@ .. SPDX-License-Identifier: GPL-2.0 -=========== -Using KUnit -=========== - -The purpose of this document is to describe what KUnit is, how it works, how it -is intended to be used, and all the concepts and terminology that are needed to -understand it. This guide assumes a working knowledge of the Linux kernel and -some basic knowledge of testing. - -For a high level introduction to KUnit, including setting up KUnit for your -project, see Documentation/dev-tools/kunit/start.rst. - -Organization of this document -============================= - -This document is organized into two main sections: Testing and Common Patterns. -The first covers what unit tests are and how to use KUnit to write them. The -second covers common testing patterns, e.g. how to isolate code and make it -possible to unit test code that was otherwise un-unit-testable. - -Testing -======= - -What is KUnit? --------------- - -"K" is short for "kernel" so "KUnit" is the "(Linux) Kernel Unit Testing -Framework." KUnit is intended first and foremost for writing unit tests; it is -general enough that it can be used to write integration tests; however, this is -a secondary goal. KUnit has no ambition of being the only testing framework for -the kernel; for example, it does not intend to be an end-to-end testing -framework. - -What is Unit Testing? ---------------------- - -A `unit test <https://martinfowler.com/bliki/UnitTest.html>`_ is a test that -tests code at the smallest possible scope, a *unit* of code. In the C -programming language that's a function. - -Unit tests should be written for all the publicly exposed functions in a -compilation unit; so that is all the functions that are exported in either a -*class* (defined below) or all functions which are **not** static. - Writing Tests -------------- +============= Test Cases -~~~~~~~~~~ +---------- The fundamental unit in KUnit is the test case. A test case is a function with -the signature ``void (*)(struct kunit *test)``. It calls a function to be tested +the signature ``void (*)(struct kunit *test)``. It calls the function under test and then sets *expectations* for what should happen. For example: .. code-block:: c @@ -65,18 +21,19 @@ and then sets *expectations* for what should happen. For example: KUNIT_FAIL(test, "This test never passes."); } -In the above example ``example_test_success`` always passes because it does -nothing; no expectations are set, so all expectations pass. On the other hand -``example_test_failure`` always fails because it calls ``KUNIT_FAIL``, which is -a special expectation that logs a message and causes the test case to fail. +In the above example, ``example_test_success`` always passes because it does +nothing; no expectations are set, and therefore all expectations pass. On the +other hand ``example_test_failure`` always fails because it calls ``KUNIT_FAIL``, +which is a special expectation that logs a message and causes the test case to +fail. Expectations ~~~~~~~~~~~~ -An *expectation* is a way to specify that you expect a piece of code to do -something in a test. An expectation is called like a function. A test is made -by setting expectations about the behavior of a piece of code under test; when -one or more of the expectations fail, the test case fails and information about -the failure is logged. For example: +An *expectation* specifies that we expect a piece of code to do something in a +test. An expectation is called like a function. A test is made by setting +expectations about the behavior of a piece of code under test. When one or more +expectations fail, the test case fails and information about the failure is +logged. For example: .. code-block:: c @@ -86,29 +43,28 @@ the failure is logged. For example: KUNIT_EXPECT_EQ(test, 2, add(1, 1)); } -In the above example ``add_test_basic`` makes a number of assertions about the -behavior of a function called ``add``; the first parameter is always of type -``struct kunit *``, which contains information about the current test context; -the second parameter, in this case, is what the value is expected to be; the +In the above example, ``add_test_basic`` makes a number of assertions about the +behavior of a function called ``add``. The first parameter is always of type +``struct kunit *``, which contains information about the current test context. +The second parameter, in this case, is what the value is expected to be. The last value is what the value actually is. If ``add`` passes all of these expectations, the test case, ``add_test_basic`` will pass; if any one of these expectations fails, the test case will fail. -It is important to understand that a test case *fails* when any expectation is -violated; however, the test will continue running, potentially trying other -expectations until the test case ends or is otherwise terminated. This is as -opposed to *assertions* which are discussed later. +A test case *fails* when any expectation is violated; however, the test will +continue to run, and try other expectations until the test case ends or is +otherwise terminated. This is as opposed to *assertions* which are discussed +later. -To learn about more expectations supported by KUnit, see -Documentation/dev-tools/kunit/api/test.rst. +To learn about more KUnit expectations, see Documentation/dev-tools/kunit/api/test.rst. .. note:: - A single test case should be pretty short, pretty easy to understand, - focused on a single behavior. + A single test case should be short, easy to understand, and focused on a + single behavior. -For example, if we wanted to properly test the add function above, we would -create additional tests cases which would each test a different property that an -add function should have like this: +For example, if we want to rigorously test the ``add`` function above, create +additional tests cases which would test each property that an ``add`` function +should have as shown below: .. code-block:: c @@ -134,56 +90,43 @@ add function should have like this: KUNIT_EXPECT_EQ(test, INT_MIN, add(INT_MAX, 1)); } -Notice how it is immediately obvious what all the properties that we are testing -for are. - Assertions ~~~~~~~~~~ -KUnit also has the concept of an *assertion*. An assertion is just like an -expectation except the assertion immediately terminates the test case if it is -not satisfied. - -For example: +An assertion is like an expectation, except that the assertion immediately +terminates the test case if the condition is not satisfied. For example: .. code-block:: c - static void mock_test_do_expect_default_return(struct kunit *test) + static void test_sort(struct kunit *test) { - struct mock_test_context *ctx = test->priv; - struct mock *mock = ctx->mock; - int param0 = 5, param1 = -5; - const char *two_param_types[] = {"int", "int"}; - const void *two_params[] = {¶m0, ¶m1}; - const void *ret; - - ret = mock->do_expect(mock, - "test_printk", test_printk, - two_param_types, two_params, - ARRAY_SIZE(two_params)); - KUNIT_ASSERT_NOT_ERR_OR_NULL(test, ret); - KUNIT_EXPECT_EQ(test, -4, *((int *) ret)); + int *a, i, r = 1; + a = kunit_kmalloc_array(test, TEST_LEN, sizeof(*a), GFP_KERNEL); + KUNIT_ASSERT_NOT_ERR_OR_NULL(test, a); + for (i = 0; i < TEST_LEN; i++) { + r = (r * 725861) % 6599; + a[i] = r; + } + sort(a, TEST_LEN, sizeof(*a), cmpint, NULL); + for (i = 0; i < TEST_LEN-1; i++) + KUNIT_EXPECT_LE(test, a[i], a[i + 1]); } -In this example, the method under test should return a pointer to a value, so -if the pointer returned by the method is null or an errno, we don't want to -bother continuing the test since the following expectation could crash the test -case. `ASSERT_NOT_ERR_OR_NULL(...)` allows us to bail out of the test case if -the appropriate conditions have not been satisfied to complete the test. +In this example, the method under test should return pointer to a value. If the +pointer returns null or an errno, we want to stop the test since the following +expectation could crash the test case. `ASSERT_NOT_ERR_OR_NULL(...)` allows us +to bail out of the test case if the appropriate conditions are not satisfied to +complete the test. Test Suites ~~~~~~~~~~~ -Now obviously one unit test isn't very helpful; the power comes from having -many test cases covering all of a unit's behaviors. Consequently it is common -to have many *similar* tests; in order to reduce duplication in these closely -related tests most unit testing frameworks - including KUnit - provide the -concept of a *test suite*. A *test suite* is just a collection of test cases -for a unit of code with a set up function that gets invoked before every test -case and then a tear down function that gets invoked after every test case -completes. - -Example: +We need many test cases covering all the unit's behaviors. It is common to have +many similar tests. In order to reduce duplication in these closely related +tests, most unit testing frameworks (including KUnit) provide the concept of a +*test suite*. A test suite is a collection of test cases for a unit of code +with a setup function that gets invoked before every test case and then a tear +down function that gets invoked after every test case completes. For example: .. code-block:: c @@ -202,23 +145,48 @@ Example: }; kunit_test_suite(example_test_suite); -In the above example the test suite, ``example_test_suite``, would run the test -cases ``example_test_foo``, ``example_test_bar``, and ``example_test_baz``; -each would have ``example_test_init`` called immediately before it and would -have ``example_test_exit`` called immediately after it. +In the above example, the test suite ``example_test_suite`` would run the test +cases ``example_test_foo``, ``example_test_bar``, and ``example_test_baz``. Each +would have ``example_test_init`` called immediately before it and +``example_test_exit`` called immediately after it. ``kunit_test_suite(example_test_suite)`` registers the test suite with the KUnit test framework. .. note:: - A test case will only be run if it is associated with a test suite. + A test case will only run if it is associated with a test suite. + +``kunit_test_suite(...)`` is a macro which tells the linker to put the +specified test suite in a special linker section so that it can be run by KUnit +either after ``late_init``, or when the test module is loaded (if the test was +built as a module). + +For more information, see Documentation/dev-tools/kunit/api/test.rst. + +Writing Tests For Other Architectures +------------------------------------- + +It is better to write tests that run on UML to tests that only run under a +particular architecture. It is better to write tests that run under QEMU or +another easy to obtain (and monetarily free) software environment to a specific +piece of hardware. -``kunit_test_suite(...)`` is a macro which tells the linker to put the specified -test suite in a special linker section so that it can be run by KUnit either -after late_init, or when the test module is loaded (depending on whether the -test was built in or not). +Nevertheless, there are still valid reasons to write a test that is architecture +or hardware specific. For example, we might want to test code that really +belongs in ``arch/some-arch/*``. Even so, try to write the test so that it does +not depend on physical hardware. Some of our test cases may not need hardware, +only few tests actually require the hardware to test it. When hardware is not +available, instead of disabling tests, we can skip them. -For more information on these types of things see the -Documentation/dev-tools/kunit/api/test.rst. +Now that we have narrowed down exactly what bits are hardware specific, the +actual procedure for writing and running the tests is same as writing normal +KUnit tests. + +.. important:: + We may have to reset hardware state. If this is not possible, we may only + be able to run one test case per invocation. + +.. TODO(brendanhiggins@google.com): Add an actual example of an architecture- + dependent KUnit test. Common Patterns =============== @@ -226,43 +194,39 @@ Common Patterns Isolating Behavior ------------------ -The most important aspect of unit testing that other forms of testing do not -provide is the ability to limit the amount of code under test to a single unit. -In practice, this is only possible by being able to control what code gets run -when the unit under test calls a function and this is usually accomplished -through some sort of indirection where a function is exposed as part of an API -such that the definition of that function can be changed without affecting the -rest of the code base. In the kernel this primarily comes from two constructs, -classes, structs that contain function pointers that are provided by the -implementer, and architecture-specific functions which have definitions selected -at compile time. +Unit testing limits the amount of code under test to a single unit. It controls +what code gets run when the unit under test calls a function. Where a function +is exposed as part of an API such that the definition of that function can be +changed without affecting the rest of the code base. In the kernel, this comes +from two constructs: classes, which are structs that contain function pointers +provided by the implementer, and architecture-specific functions, which have +definitions selected at compile time. Classes ~~~~~~~ Classes are not a construct that is built into the C programming language; -however, it is an easily derived concept. Accordingly, pretty much every project -that does not use a standardized object oriented library (like GNOME's GObject) -has their own slightly different way of doing object oriented programming; the -Linux kernel is no exception. +however, it is an easily derived concept. Accordingly, in most cases, every +project that does not use a standardized object oriented library (like GNOME's +GObject) has their own slightly different way of doing object oriented +programming; the Linux kernel is no exception. The central concept in kernel object oriented programming is the class. In the kernel, a *class* is a struct that contains function pointers. This creates a contract between *implementers* and *users* since it forces them to use the -same function signature without having to call the function directly. In order -for it to truly be a class, the function pointers must specify that a pointer -to the class, known as a *class handle*, be one of the parameters; this makes -it possible for the member functions (also known as *methods*) to have access -to member variables (more commonly known as *fields*) allowing the same -implementation to have multiple *instances*. - -Typically a class can be *overridden* by *child classes* by embedding the -*parent class* in the child class. Then when a method provided by the child -class is called, the child implementation knows that the pointer passed to it is -of a parent contained within the child; because of this, the child can compute -the pointer to itself because the pointer to the parent is always a fixed offset -from the pointer to the child; this offset is the offset of the parent contained -in the child struct. For example: +same function signature without having to call the function directly. To be a +class, the function pointers must specify that a pointer to the class, known as +a *class handle*, be one of the parameters. Thus the member functions (also +known as *methods*) have access to member variables (also known as *fields*) +allowing the same implementation to have multiple *instances*. + +A class can be *overridden* by *child classes* by embedding the *parent class* +in the child class. Then when the child class *method* is called, the child +implementation knows that the pointer passed to it is of a parent contained +within the child. Thus, the child can compute the pointer to itself because the +pointer to the parent is always a fixed offset from the pointer to the child. +This offset is the offset of the parent contained in the child struct. For +example: .. code-block:: c @@ -290,8 +254,8 @@ in the child struct. For example: self->width = width; } -In this example (as in most kernel code) the operation of computing the pointer -to the child from the pointer to the parent is done by ``container_of``. +In this example, computing the pointer to the child from the pointer to the +parent is done by ``container_of``. Faking Classes ~~~~~~~~~~~~~~ @@ -300,14 +264,11 @@ In order to unit test a piece of code that calls a method in a class, the behavior of the method must be controllable, otherwise the test ceases to be a unit test and becomes an integration test. -A fake just provides an implementation of a piece of code that is different than -what runs in a production instance, but behaves identically from the standpoint -of the callers; this is usually done to replace a dependency that is hard to -deal with, or is slow. - -A good example for this might be implementing a fake EEPROM that just stores the -"contents" in an internal buffer. For example, let's assume we have a class that -represents an EEPROM: +A fake class implements a piece of code that is different than what runs in a +production instance, but behaves identical from the standpoint of the callers. +This is done to replace a dependency that is hard to deal with, or is slow. For +example, implementing a fake EEPROM that stores the "contents" in an +internal buffer. Assume we have a class that represents an EEPROM: .. code-block:: c @@ -316,7 +277,7 @@ represents an EEPROM: ssize_t (*write)(struct eeprom *this, size_t offset, const char *buffer, size_t count); }; -And we want to test some code that buffers writes to the EEPROM: +And we want to test code that buffers writes to the EEPROM: .. code-block:: c @@ -329,7 +290,7 @@ And we want to test some code that buffers writes to the EEPROM: struct eeprom_buffer *new_eeprom_buffer(struct eeprom *eeprom); void destroy_eeprom_buffer(struct eeprom *eeprom); -We can easily test this code by *faking out* the underlying EEPROM: +We can test this code by *faking out* the underlying EEPROM: .. code-block:: c @@ -456,14 +417,14 @@ We can now use it to test ``struct eeprom_buffer``: destroy_eeprom_buffer(ctx->eeprom_buffer); } -Testing against multiple inputs +Testing Against Multiple Inputs ------------------------------- -Testing just a few inputs might not be enough to have confidence that the code -works correctly, e.g. for a hash function. +Testing just a few inputs is not enough to ensure that the code works correctly, +for example: testing a hash function. -In such cases, it can be helpful to have a helper macro or function, e.g. this -fictitious example for ``sha1sum(1)`` +We can write a helper macro or function. The function is called for each input. +For example, to test ``sha1sum(1)``, we can write: .. code-block:: c @@ -475,16 +436,15 @@ fictitious example for ``sha1sum(1)`` TEST_SHA1("hello world", "2aae6c35c94fcfb415dbe95f408b9ce91ee846ed"); TEST_SHA1("hello world!", "430ce34d020724ed75a196dfc2ad67c77772d169"); +Note the use of the ``_MSG`` version of ``KUNIT_EXPECT_STREQ`` to print a more +detailed error and make the assertions clearer within the helper macros. -Note the use of ``KUNIT_EXPECT_STREQ_MSG`` to give more context when it fails -and make it easier to track down. (Yes, in this example, ``want`` is likely -going to be unique enough on its own). +The ``_MSG`` variants are useful when the same expectation is called multiple +times (in a loop or helper function) and thus the line number is not enough to +identify what failed, as shown below. -The ``_MSG`` variants are even more useful when the same expectation is called -multiple times (in a loop or helper function) and thus the line number isn't -enough to identify what failed, like below. - -In some cases, it can be helpful to write a *table-driven test* instead, e.g. +In complicated cases, we recommend using a *table-driven test* compared to the +helper macro variation, for example: .. code-block:: c @@ -513,17 +473,18 @@ In some cases, it can be helpful to write a *table-driven test* instead, e.g. } -There's more boilerplate involved, but it can: +There is more boilerplate code involved, but it can: + +* be more readable when there are multiple inputs/outputs (due to field names). -* be more readable when there are multiple inputs/outputs thanks to field names, + * For example, see ``fs/ext4/inode-test.c``. - * E.g. see ``fs/ext4/inode-test.c`` for an example of both. -* reduce duplication if test cases can be shared across multiple tests. +* reduce duplication if test cases are shared across multiple tests. - * E.g. if we wanted to also test ``sha256sum``, we could add a ``sha256`` + * For example: if we want to test ``sha256sum``, we could add a ``sha256`` field and reuse ``cases``. -* be converted to a "parameterized test", see below. +* be converted to a "parameterized test". Parameterized Testing ~~~~~~~~~~~~~~~~~~~~~ @@ -531,7 +492,7 @@ Parameterized Testing The table-driven testing pattern is common enough that KUnit has special support for it. -Reusing the same ``cases`` array from above, we can write the test as a +By reusing the same ``cases`` array from above, we can write the test as a "parameterized test" with the following. .. code-block:: c @@ -582,193 +543,160 @@ Reusing the same ``cases`` array from above, we can write the test as a .. _kunit-on-non-uml: -KUnit on non-UML architectures -============================== - -By default KUnit uses UML as a way to provide dependencies for code under test. -Under most circumstances KUnit's usage of UML should be treated as an -implementation detail of how KUnit works under the hood. Nevertheless, there -are instances where being able to run architecture-specific code or test -against real hardware is desirable. For these reasons KUnit supports running on -other architectures. - -Running existing KUnit tests on non-UML architectures ------------------------------------------------------ +Exiting Early on Failed Expectations +------------------------------------ -There are some special considerations when running existing KUnit tests on -non-UML architectures: +We can use ``KUNIT_EXPECT_EQ`` to mark the test as failed and continue +execution. In some cases, it is unsafe to continue. We can use the +``KUNIT_ASSERT`` variant to exit on failure. -* Hardware may not be deterministic, so a test that always passes or fails - when run under UML may not always do so on real hardware. -* Hardware and VM environments may not be hermetic. KUnit tries its best to - provide a hermetic environment to run tests; however, it cannot manage state - that it doesn't know about outside of the kernel. Consequently, tests that - may be hermetic on UML may not be hermetic on other architectures. -* Some features and tooling may not be supported outside of UML. -* Hardware and VMs are slower than UML. +.. code-block:: c -None of these are reasons not to run your KUnit tests on real hardware; they are -only things to be aware of when doing so. + void example_test_user_alloc_function(struct kunit *test) + { + void *object = alloc_some_object_for_me(); -Currently, the KUnit Wrapper (``tools/testing/kunit/kunit.py``) (aka -kunit_tool) only fully supports running tests inside of UML and QEMU; however, -this is only due to our own time limitations as humans working on KUnit. It is -entirely possible to support other emulators and even actual hardware, but for -now QEMU and UML is what is fully supported within the KUnit Wrapper. Again, to -be clear, this is just the Wrapper. The actualy KUnit tests and the KUnit -library they are written in is fully architecture agnostic and can be used in -virtually any setup, you just won't have the benefit of typing a single command -out of the box and having everything magically work perfectly. + /* Make sure we got a valid pointer back. */ + KUNIT_ASSERT_NOT_ERR_OR_NULL(test, object); + do_something_with_object(object); + } -Again, all core KUnit framework features are fully supported on all -architectures, and using them is straightforward: Most popular architectures -are supported directly in the KUnit Wrapper via QEMU. Currently, supported -architectures on QEMU include: +Allocating Memory +----------------- -* i386 -* x86_64 -* arm -* arm64 -* alpha -* powerpc -* riscv -* s390 -* sparc +Where you might use ``kzalloc``, you can instead use ``kunit_kzalloc`` as KUnit +will then ensure that the memory is freed once the test completes. -In order to run KUnit tests on one of these architectures via QEMU with the -KUnit wrapper, all you need to do is specify the flags ``--arch`` and -``--cross_compile`` when invoking the KUnit Wrapper. For example, we could run -the default KUnit tests on ARM in the following manner (assuming we have an ARM -toolchain installed): +This is useful because it lets us use the ``KUNIT_ASSERT_EQ`` macros to exit +early from a test without having to worry about remembering to call ``kfree``. +For example: -.. code-block:: bash +.. code-block:: c - tools/testing/kunit/kunit.py run --timeout=60 --jobs=12 --arch=arm --cross_compile=arm-linux-gnueabihf- + void example_test_allocation(struct kunit *test) + { + char *buffer = kunit_kzalloc(test, 16, GFP_KERNEL); + /* Ensure allocation succeeded. */ + KUNIT_ASSERT_NOT_ERR_OR_NULL(test, buffer); -Alternatively, if you want to run your tests on real hardware or in some other -emulation environment, all you need to do is to take your kunitconfig, your -Kconfig options for the tests you would like to run, and merge them into -whatever config your are using for your platform. That's it! + KUNIT_ASSERT_STREQ(test, buffer, ""); + } -For example, let's say you have the following kunitconfig: -.. code-block:: none +Testing Static Functions +------------------------ - CONFIG_KUNIT=y - CONFIG_KUNIT_EXAMPLE_TEST=y +If we do not want to expose functions or variables for testing, one option is to +conditionally ``#include`` the test file at the end of your .c file. For +example: -If you wanted to run this test on an x86 VM, you might add the following config -options to your ``.config``: +.. code-block:: c -.. code-block:: none + /* In my_file.c */ - CONFIG_KUNIT=y - CONFIG_KUNIT_EXAMPLE_TEST=y - CONFIG_SERIAL_8250=y - CONFIG_SERIAL_8250_CONSOLE=y + static int do_interesting_thing(); -All these new options do is enable support for a common serial console needed -for logging. + #ifdef CONFIG_MY_KUNIT_TEST + #include "my_kunit_test.c" + #endif -Next, you could build a kernel with these tests as follows: +Injecting Test-Only Code +------------------------ +Similar to as shown above, we can add test-specific logic. For example: -.. code-block:: bash +.. code-block:: c - make ARCH=x86 olddefconfig - make ARCH=x86 + /* In my_file.h */ -Once you have built a kernel, you could run it on QEMU as follows: + #ifdef CONFIG_MY_KUNIT_TEST + /* Defined in my_kunit_test.c */ + void test_only_hook(void); + #else + void test_only_hook(void) { } + #endif -.. code-block:: bash +This test-only code can be made more useful by accessing the current ``kunit_test`` +as shown in next section: *Accessing The Current Test*. - qemu-system-x86_64 -enable-kvm \ - -m 1024 \ - -kernel arch/x86_64/boot/bzImage \ - -append 'console=ttyS0' \ - --nographic +Accessing The Current Test +-------------------------- -Interspersed in the kernel logs you might see the following: +In some cases, we need to call test-only code from outside the test file. +For example, see example in section *Injecting Test-Only Code* or if +we are providing a fake implementation of an ops struct. Using +``kunit_test`` field in ``task_struct``, we can access it via +``current->kunit_test``. -.. code-block:: none +The example below includes how to implement "mocking": - TAP version 14 - # Subtest: example - 1..1 - # example_simple_test: initializing - ok 1 - example_simple_test - ok 1 - example +.. code-block:: c -Congratulations, you just ran a KUnit test on the x86 architecture! + #include <linux/sched.h> /* for current */ -In a similar manner, kunit and kunit tests can also be built as modules, -so if you wanted to run tests in this way you might add the following config -options to your ``.config``: + struct test_data { + int foo_result; + int want_foo_called_with; + }; -.. code-block:: none + static int fake_foo(int arg) + { + struct kunit *test = current->kunit_test; + struct test_data *test_data = test->priv; - CONFIG_KUNIT=m - CONFIG_KUNIT_EXAMPLE_TEST=m + KUNIT_EXPECT_EQ(test, test_data->want_foo_called_with, arg); + return test_data->foo_result; + } -Once the kernel is built and installed, a simple + static void example_simple_test(struct kunit *test) + { + /* Assume priv (private, a member used to pass test data from + * the init function) is allocated in the suite's .init */ + struct test_data *test_data = test->priv; -.. code-block:: bash + test_data->foo_result = 42; + test_data->want_foo_called_with = 1; - modprobe example-test + /* In a real test, we'd probably pass a pointer to fake_foo somewhere + * like an ops struct, etc. instead of calling it directly. */ + KUNIT_EXPECT_EQ(test, fake_foo(1), 42); + } -...will run the tests. +In this example, we are using the ``priv`` member of ``struct kunit`` as a way +of passing data to the test from the init function. In general ``priv`` is +pointer that can be used for any user data. This is preferred over static +variables, as it avoids concurrency issues. -.. note:: - Note that you should make sure your test depends on ``KUNIT=y`` in Kconfig - if the test does not support module build. Otherwise, it will trigger - compile errors if ``CONFIG_KUNIT`` is ``m``. +Had we wanted something more flexible, we could have used a named ``kunit_resource``. +Each test can have multiple resources which have string names providing the same +flexibility as a ``priv`` member, but also, for example, allowing helper +functions to create resources without conflicting with each other. It is also +possible to define a clean up function for each resource, making it easy to +avoid resource leaks. For more information, see Documentation/dev-tools/kunit/api/test.rst. -Writing new tests for other architectures ------------------------------------------ +Failing The Current Test +------------------------ -The first thing you must do is ask yourself whether it is necessary to write a -KUnit test for a specific architecture, and then whether it is necessary to -write that test for a particular piece of hardware. In general, writing a test -that depends on having access to a particular piece of hardware or software (not -included in the Linux source repo) should be avoided at all costs. +If we want to fail the current test, we can use ``kunit_fail_current_test(fmt, args...)`` +which is defined in ``<kunit/test-bug.h>`` and does not require pulling in ``<kunit/test.h>``. +For example, we have an option to enable some extra debug checks on some data +structures as shown below: -Even if you only ever plan on running your KUnit test on your hardware -configuration, other people may want to run your tests and may not have access -to your hardware. If you write your test to run on UML, then anyone can run your -tests without knowing anything about your particular setup, and you can still -run your tests on your hardware setup just by compiling for your architecture. +.. code-block:: c -.. important:: - Always prefer tests that run on UML to tests that only run under a particular - architecture, and always prefer tests that run under QEMU or another easy - (and monetarily free) to obtain software environment to a specific piece of - hardware. - -Nevertheless, there are still valid reasons to write an architecture or hardware -specific test: for example, you might want to test some code that really belongs -in ``arch/some-arch/*``. Even so, try your best to write the test so that it -does not depend on physical hardware: if some of your test cases don't need the -hardware, only require the hardware for tests that actually need it. - -Now that you have narrowed down exactly what bits are hardware specific, the -actual procedure for writing and running the tests is pretty much the same as -writing normal KUnit tests. One special caveat is that you have to reset -hardware state in between test cases; if this is not possible, you may only be -able to run one test case per invocation. + #include <kunit/test-bug.h> -.. TODO(brendanhiggins@google.com): Add an actual example of an architecture- - dependent KUnit test. + #ifdef CONFIG_EXTRA_DEBUG_CHECKS + static void validate_my_data(struct data *data) + { + if (is_valid(data)) + return; -KUnit debugfs representation -============================ -When kunit test suites are initialized, they create an associated directory -in ``/sys/kernel/debug/kunit/<test-suite>``. The directory contains one file + kunit_fail_current_test("data %p is invalid", data); -- results: "cat results" displays results of each test case and the results - of the entire suite for the last test run. + /* Normal, non-KUnit, error reporting code here. */ + } + #else + static void my_debug_function(void) { } + #endif -The debugfs representation is primarily of use when kunit test suites are -run in a native environment, either as modules or builtin. Having a way -to display results like this is valuable as otherwise results can be -intermixed with other events in dmesg output. The maximum size of each -results file is KUNIT_LOG_SIZE bytes (defined in ``include/kunit/test.h``). diff --git a/Documentation/devicetree/bindings/Makefile b/Documentation/devicetree/bindings/Makefile index c9abfbe3f0aa..41c555181b6f 100644 --- a/Documentation/devicetree/bindings/Makefile +++ b/Documentation/devicetree/bindings/Makefile @@ -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 ?= diff --git a/Documentation/devicetree/bindings/arm/apple.yaml b/Documentation/devicetree/bindings/arm/apple.yaml index 1e772c85206c..8d93e8a6cc18 100644 --- a/Documentation/devicetree/bindings/arm/apple.yaml +++ b/Documentation/devicetree/bindings/arm/apple.yaml @@ -12,12 +12,19 @@ maintainers: description: | ARM platforms using SoCs designed by Apple Inc., branded "Apple Silicon". - This currently includes devices based on the "M1" SoC, starting with the - three Mac models released in late 2020: + This currently includes devices based on the "M1" SoC: - Mac mini (M1, 2020) - MacBook Pro (13-inch, M1, 2020) - MacBook Air (M1, 2020) + - iMac (24-inch, M1, 2021) + + And devices based on the "M1 Pro" and "M1 Max" SoCs: + + - MacBook Pro (14-inch, M1 Pro, 2021) + - MacBook Pro (14-inch, M1 Max, 2021) + - MacBook Pro (16-inch, M1 Pro, 2021) + - MacBook Pro (16-inch, M1 Max, 2021) The compatible property should follow this format: @@ -56,8 +63,24 @@ properties: - apple,j274 # Mac mini (M1, 2020) - apple,j293 # MacBook Pro (13-inch, M1, 2020) - apple,j313 # MacBook Air (M1, 2020) + - apple,j456 # iMac (24-inch, 4x USB-C, M1, 2021) + - apple,j457 # iMac (24-inch, 2x USB-C, M1, 2021) - const: apple,t8103 - const: apple,arm-platform + - description: Apple M1 Pro SoC based platforms + items: + - enum: + - apple,j314s # MacBook Pro (14-inch, M1 Pro, 2021) + - apple,j316s # MacBook Pro (16-inch, M1 Pro, 2021) + - const: apple,t6000 + - const: apple,arm-platform + - description: Apple M1 Max SoC based platforms + items: + - enum: + - apple,j314c # MacBook Pro (14-inch, M1 Max, 2021) + - apple,j316c # MacBook Pro (16-inch, M1 Max, 2021) + - const: apple,t6001 + - const: apple,arm-platform additionalProperties: true diff --git a/Documentation/devicetree/bindings/arm/apple/apple,pmgr.yaml b/Documentation/devicetree/bindings/arm/apple/apple,pmgr.yaml new file mode 100644 index 000000000000..b6b5d3a912b3 --- /dev/null +++ b/Documentation/devicetree/bindings/arm/apple/apple,pmgr.yaml @@ -0,0 +1,134 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/arm/apple/apple,pmgr.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Apple SoC Power Manager (PMGR) + +maintainers: + - Hector Martin <marcan@marcan.st> + +description: | + Apple SoCs include PMGR blocks responsible for power management, + which can control various clocks, resets, power states, and + performance features. This node represents the PMGR as a syscon, + with sub-nodes representing individual features. + +properties: + $nodename: + pattern: "^power-management@[0-9a-f]+$" + + compatible: + items: + - enum: + - apple,t8103-pmgr + - apple,t6000-pmgr + - const: apple,pmgr + - const: syscon + - const: simple-mfd + + reg: + maxItems: 1 + + "#address-cells": + const: 1 + + "#size-cells": + const: 1 + +patternProperties: + "power-controller@[0-9a-f]+$": + description: + The individual power management domains within this controller + type: object + $ref: /power/apple,pmgr-pwrstate.yaml# + +required: + - compatible + - reg + +additionalProperties: false + +examples: + - | + soc { + #address-cells = <2>; + #size-cells = <2>; + + power-management@23b700000 { + compatible = "apple,t8103-pmgr", "apple,pmgr", "syscon", "simple-mfd"; + #address-cells = <1>; + #size-cells = <1>; + reg = <0x2 0x3b700000 0x0 0x14000>; + + ps_sio: power-controller@1c0 { + compatible = "apple,t8103-pmgr-pwrstate", "apple,pmgr-pwrstate"; + reg = <0x1c0 8>; + #power-domain-cells = <0>; + #reset-cells = <0>; + label = "sio"; + apple,always-on; + }; + + ps_uart_p: power-controller@220 { + compatible = "apple,t8103-pmgr-pwrstate", "apple,pmgr-pwrstate"; + reg = <0x220 8>; + #power-domain-cells = <0>; + #reset-cells = <0>; + label = "uart_p"; + power-domains = <&ps_sio>; + }; + + ps_uart0: power-controller@270 { + compatible = "apple,t8103-pmgr-pwrstate", "apple,pmgr-pwrstate"; + reg = <0x270 8>; + #power-domain-cells = <0>; + #reset-cells = <0>; + label = "uart0"; + power-domains = <&ps_uart_p>; + }; + }; + + power-management@23d280000 { + compatible = "apple,t8103-pmgr", "apple,pmgr", "syscon", "simple-mfd"; + #address-cells = <1>; + #size-cells = <1>; + reg = <0x2 0x3d280000 0x0 0xc000>; + + ps_aop_filter: power-controller@4000 { + compatible = "apple,t8103-pmgr-pwrstate", "apple,pmgr-pwrstate"; + reg = <0x4000 8>; + #power-domain-cells = <0>; + #reset-cells = <0>; + label = "aop_filter"; + }; + + ps_aop_base: power-controller@4010 { + compatible = "apple,t8103-pmgr-pwrstate", "apple,pmgr-pwrstate"; + reg = <0x4010 8>; + #power-domain-cells = <0>; + #reset-cells = <0>; + label = "aop_base"; + power-domains = <&ps_aop_filter>; + }; + + ps_aop_shim: power-controller@4038 { + compatible = "apple,t8103-pmgr-pwrstate", "apple,pmgr-pwrstate"; + reg = <0x4038 8>; + #power-domain-cells = <0>; + #reset-cells = <0>; + label = "aop_shim"; + power-domains = <&ps_aop_base>; + }; + + ps_aop_uart0: power-controller@4048 { + compatible = "apple,t8103-pmgr-pwrstate", "apple,pmgr-pwrstate"; + reg = <0x4048 8>; + #power-domain-cells = <0>; + #reset-cells = <0>; + label = "aop_uart0"; + power-domains = <&ps_aop_shim>; + }; + }; + }; diff --git a/Documentation/devicetree/bindings/arm/arm,cci-400.yaml b/Documentation/devicetree/bindings/arm/arm,cci-400.yaml index 4682f991a5c8..f8530a50863a 100644 --- a/Documentation/devicetree/bindings/arm/arm,cci-400.yaml +++ b/Documentation/devicetree/bindings/arm/arm,cci-400.yaml @@ -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>; diff --git a/Documentation/devicetree/bindings/arm/arm-dsu-pmu.txt b/Documentation/devicetree/bindings/arm/arm-dsu-pmu.txt deleted file mode 100644 index 6efabba530f1..000000000000 --- a/Documentation/devicetree/bindings/arm/arm-dsu-pmu.txt +++ /dev/null @@ -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>; -}; diff --git a/Documentation/devicetree/bindings/arm/aspeed/aspeed,sbc.yaml b/Documentation/devicetree/bindings/arm/aspeed/aspeed,sbc.yaml new file mode 100644 index 000000000000..c72aab706484 --- /dev/null +++ b/Documentation/devicetree/bindings/arm/aspeed/aspeed,sbc.yaml @@ -0,0 +1,37 @@ +# SPDX-License-Identifier: (GPL-2.0-or-later OR BSD-2-Clause) +# Copyright 2021 Joel Stanley, IBM Corp. +%YAML 1.2 +--- +$id: "http://devicetree.org/schemas/arm/aspeed/aspeed,sbc.yaml#" +$schema: "http://devicetree.org/meta-schemas/core.yaml#" + +title: ASPEED Secure Boot Controller + +maintainers: + - Joel Stanley <joel@jms.id.au> + - Andrew Jeffery <andrew@aj.id.au> + +description: | + The ASPEED SoCs have a register bank for interacting with the secure boot + controller. + +properties: + compatible: + items: + - const: aspeed,ast2600-sbc + + reg: + maxItems: 1 + +required: + - compatible + - reg + +additionalProperties: false + +examples: + - | + sbc: secure-boot-controller@1e6f2000 { + compatible = "aspeed,ast2600-sbc"; + reg = <0x1e6f2000 0x1000>; + }; diff --git a/Documentation/devicetree/bindings/arm/bcm/brcm,bcm4908.yaml b/Documentation/devicetree/bindings/arm/bcm/brcm,bcm4908.yaml index 2cd4e4a32278..9b745531ff04 100644 --- a/Documentation/devicetree/bindings/arm/bcm/brcm,bcm4908.yaml +++ b/Documentation/devicetree/bindings/arm/bcm/brcm,bcm4908.yaml @@ -29,6 +29,7 @@ properties: items: - enum: - asus,gt-ac5300 + - netgear,raxe500 - const: brcm,bcm4908 - description: BCM49408 based boards diff --git a/Documentation/devicetree/bindings/arm/cpus.yaml b/Documentation/devicetree/bindings/arm/cpus.yaml index f2ab6423b4af..0dcebc48ea22 100644 --- a/Documentation/devicetree/bindings/arm/cpus.yaml +++ b/Documentation/devicetree/bindings/arm/cpus.yaml @@ -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 @@ -174,6 +181,7 @@ properties: - qcom,kryo560 - qcom,kryo570 - qcom,kryo685 + - qcom,kryo780 - qcom,scorpion enable-method: diff --git a/Documentation/devicetree/bindings/arm/firmware/linaro,optee-tz.yaml b/Documentation/devicetree/bindings/arm/firmware/linaro,optee-tz.yaml index c24047c1fdd5..9a426110a14a 100644 --- a/Documentation/devicetree/bindings/arm/firmware/linaro,optee-tz.yaml +++ b/Documentation/devicetree/bindings/arm/firmware/linaro,optee-tz.yaml @@ -24,6 +24,12 @@ properties: compatible: const: linaro,optee-tz + interrupts: + maxItems: 1 + description: | + This interrupt which is used to signal an event by the secure world + software is expected to be edge-triggered. + method: enum: [smc, hvc] description: | @@ -42,10 +48,12 @@ additionalProperties: false examples: - | + #include <dt-bindings/interrupt-controller/arm-gic.h> firmware { optee { compatible = "linaro,optee-tz"; method = "smc"; + interrupts = <GIC_SPI 187 IRQ_TYPE_EDGE_RISING>; }; }; diff --git a/Documentation/devicetree/bindings/arm/fsl.yaml b/Documentation/devicetree/bindings/arm/fsl.yaml index 0b595b26061f..97f6eebad76a 100644 --- a/Documentation/devicetree/bindings/arm/fsl.yaml +++ b/Documentation/devicetree/bindings/arm/fsl.yaml @@ -240,6 +240,7 @@ properties: - uniwest,imx6q-evi # Uniwest Evi - variscite,dt6customboard - wand,imx6q-wandboard # Wandboard i.MX6 Quad Board + - ysoft,imx6q-yapp4-crux # i.MX6 Quad Y Soft IOTA Crux board - zealz,imx6q-gk802 # Zealz GK802 - zii,imx6q-zii-rdu2 # ZII RDU2 Board - const: fsl,imx6q @@ -323,6 +324,20 @@ properties: - const: toradex,apalis_imx6q - const: fsl,imx6q + - description: TQ-Systems TQMa6Q SoM (variant A) on MBa6x + items: + - const: tq,imx6q-mba6x-a + - const: tq,mba6a # Expected by bootloader, to be removed in the future + - const: tq,imx6q-tqma6q-a + - const: fsl,imx6q + + - description: TQ-Systems TQMa6Q SoM (variant B) on MBa6x + items: + - const: tq,imx6q-mba6x-b + - const: tq,mba6b # Expected by bootloader, to be removed in the future + - const: tq,imx6q-tqma6q-b + - const: fsl,imx6q + - description: i.MX6QP based Boards items: - enum: @@ -334,6 +349,7 @@ properties: - kvg,vicutp # Kverneland UT1P board - prt,prtwd3 # Protonic WD3 board - wand,imx6qp-wandboard # Wandboard i.MX6 QuadPlus Board + - ysoft,imx6qp-yapp4-crux-plus # i.MX6 Quad Plus Y Soft IOTA Crux+ board - zii,imx6qp-zii-rdu2 # ZII RDU2+ Board - const: fsl,imx6qp @@ -344,6 +360,13 @@ properties: - const: phytec,imx6qdl-pcm058 # PHYTEC phyCORE-i.MX6 - const: fsl,imx6qp + - description: TQ-Systems TQMa6QP SoM on MBa6x + items: + - const: tq,imx6qp-mba6x-b + - const: tq,mba6b # Expected by bootloader, to be removed in the future + - const: tq,imx6qp-tqma6qp-b + - const: fsl,imx6qp + - description: i.MX6DL based Boards items: - enum: @@ -482,6 +505,20 @@ properties: - const: dh,imx6s-dhcom-som - const: fsl,imx6dl + - description: TQ-Systems TQMa6DL SoM (variant A) on MBa6x + items: + - const: tq,imx6dl-mba6x-a + - const: tq,mba6a # Expected by bootloader, to be removed in the future + - const: tq,imx6dl-tqma6dl-a + - const: fsl,imx6dl + + - description: TQ-Systems TQMa6DL SoM (variant B) on MBa6x + items: + - const: tq,imx6dl-mba6x-b + - const: tq,mba6b # Expected by bootloader, to be removed in the future + - const: tq,imx6dl-tqma6dl-b + - const: fsl,imx6dl + - description: i.MX6SL based Boards items: - enum: @@ -580,6 +617,7 @@ properties: items: - enum: - fsl,imx6ull-14x14-evk # i.MX6 UltraLiteLite 14x14 EVK Board + - joz,jozacp # JOZ Access Point - kontron,imx6ull-n6411-som # Kontron N6411 SOM - myir,imx6ull-mys-6ulx-eval # MYiR Tech iMX6ULL Evaluation Board - toradex,colibri-imx6ull # Colibri iMX6ULL Modules @@ -632,6 +670,7 @@ properties: - description: i.MX6ULZ based Boards items: - enum: + - bsh,imx6ulz-bsh-smm-m2 # i.MX6 ULZ BSH SystemMaster - fsl,imx6ulz-14x14-evk # i.MX6 ULZ 14x14 EVK Board - const: fsl,imx6ull # This seems odd. Should be last? - const: fsl,imx6ulz @@ -754,10 +793,23 @@ properties: - const: variscite,var-som-mx8mm - const: fsl,imx8mm + - description: + TQMa8MxML is a series of SOM featuring NXP i.MX8MM system-on-chip + variants. It is designed to be soldered on different carrier boards. + All variants (TQMa8M[Q,D,S][L]ML) use the same device tree, hence only + one compatible is needed. + items: + - enum: + - tq,imx8mm-tqma8mqml-mba8mx # TQ-Systems GmbH i.MX8MM TQMa8MQML SOM on MBa8Mx + - const: tq,imx8mm-tqma8mqml # TQ-Systems GmbH i.MX8MM TQMa8MQML SOM + - const: fsl,imx8mm + - description: i.MX8MN based Boards items: - enum: - beacon,imx8mn-beacon-kit # i.MX8MN Beacon Development Kit + - bsh,imx8mn-bsh-smm-s2 # i.MX8MN BSH SystemMaster S2 + - bsh,imx8mn-bsh-smm-s2pro # i.MX8MN BSH SystemMaster S2 PRO - fsl,imx8mn-ddr4-evk # i.MX8MN DDR4 EVK Board - fsl,imx8mn-evk # i.MX8MN LPDDR4 EVK Board - gw,imx8mn-gw7902 # i.MX8MM Gateworks Board @@ -769,6 +821,17 @@ properties: - const: variscite,var-som-mx8mn - const: fsl,imx8mn + - description: + TQMa8MxNL is a series of SOM featuring NXP i.MX8MN system-on-chip + variants. It is designed to be soldered on different carrier boards. + All variants (TQMa8M[Q,D,S][L]NL) use the same device tree, hence only + one compatible is needed. + items: + - enum: + - tq,imx8mn-tqma8mqnl-mba8mx # TQ-Systems GmbH i.MX8MN TQMa8MQNL SOM on MBa8Mx + - const: tq,imx8mn-tqma8mqnl # TQ-Systems GmbH i.MX8MN TQMa8MQNL SOM + - const: fsl,imx8mn + - description: i.MX8MP based Boards items: - enum: @@ -805,6 +868,15 @@ properties: - const: purism,librem5 - const: fsl,imx8mq + - description: + TQMa8Mx is a series of SOM featuring NXP i.MX8MQ system-on-chip + variants. It is designed to be clicked on different carrier boards. + items: + - enum: + - tq,imx8mq-tqma8mq-mba8mx # TQ-Systems GmbH i.MX8MQ TQMa8Mx SOM on MBa8Mx + - const: tq,imx8mq-tqma8mq # TQ-Systems GmbH i.MX8MQ TQMa8Mx SOM + - const: fsl,imx8mq + - description: Zodiac Inflight Innovations Ultra Boards items: - enum: @@ -834,6 +906,12 @@ properties: - const: toradex,colibri-imx8x - const: fsl,imx8qxp + - description: i.MX8ULP based Boards + items: + - enum: + - fsl,imx8ulp-evk # i.MX8ULP EVK Board + - const: fsl,imx8ulp + - description: Freescale Vybrid Platform Device Tree Bindings diff --git a/Documentation/devicetree/bindings/arm/mediatek.yaml b/Documentation/devicetree/bindings/arm/mediatek.yaml index 0fa55497b96f..0ffe1acf1344 100644 --- a/Documentation/devicetree/bindings/arm/mediatek.yaml +++ b/Documentation/devicetree/bindings/arm/mediatek.yaml @@ -79,6 +79,14 @@ properties: - const: mediatek,mt7629 - items: - enum: + - mediatek,mt7986a-rfb + - const: mediatek,mt7986a + - items: + - enum: + - mediatek,mt7986b-rfb + - const: mediatek,mt7986b + - items: + - enum: - mediatek,mt8127-moose - const: mediatek,mt8127 - items: @@ -134,6 +142,10 @@ properties: - google,krane-sku176 - const: google,krane - const: mediatek,mt8183 + - description: Google Cozmo (Acer Chromebook 314) + items: + - const: google,cozmo + - const: mediatek,mt8183 - description: Google Damu (ASUS Chromebook Flip CM3) items: - const: google,damu @@ -143,7 +155,9 @@ properties: - enum: - google,fennel-sku0 - google,fennel-sku1 + - google,fennel-sku2 - google,fennel-sku6 + - google,fennel-sku7 - const: google,fennel - const: mediatek,mt8183 - description: Google Juniper (Acer Chromebook Spin 311) / Kenzo (Acer Chromebook 311) @@ -159,6 +173,12 @@ properties: - const: google,kakadu-rev2 - const: google,kakadu - const: mediatek,mt8183 + - description: Google Kakadu (ASUS Chromebook Detachable CM3) + items: + - const: google,kakadu-rev3-sku22 + - const: google,kakadu-rev2-sku22 + - const: google,kakadu + - const: mediatek,mt8183 - description: Google Kappa (HP Chromebook 11a) items: - const: google,kappa diff --git a/Documentation/devicetree/bindings/arm/mediatek/mediatek,apmixedsys.txt b/Documentation/devicetree/bindings/arm/mediatek/mediatek,apmixedsys.txt index ea827e8763de..3fa755866528 100644 --- a/Documentation/devicetree/bindings/arm/mediatek/mediatek,apmixedsys.txt +++ b/Documentation/devicetree/bindings/arm/mediatek/mediatek,apmixedsys.txt @@ -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" diff --git a/Documentation/devicetree/bindings/arm/mediatek/mediatek,ethsys.txt b/Documentation/devicetree/bindings/arm/mediatek/mediatek,ethsys.txt index 6b7e8067e7aa..0502db73686b 100644 --- a/Documentation/devicetree/bindings/arm/mediatek/mediatek,ethsys.txt +++ b/Documentation/devicetree/bindings/arm/mediatek/mediatek,ethsys.txt @@ -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 diff --git a/Documentation/devicetree/bindings/arm/mediatek/mediatek,infracfg.txt b/Documentation/devicetree/bindings/arm/mediatek/mediatek,infracfg.txt index eb3523c7a7be..f66bd720571d 100644 --- a/Documentation/devicetree/bindings/arm/mediatek/mediatek,infracfg.txt +++ b/Documentation/devicetree/bindings/arm/mediatek/mediatek,infracfg.txt @@ -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" diff --git a/Documentation/devicetree/bindings/arm/mediatek/mediatek,sgmiisys.txt b/Documentation/devicetree/bindings/arm/mediatek/mediatek,sgmiisys.txt index 30cb645c0e54..29ca7a10b315 100644 --- a/Documentation/devicetree/bindings/arm/mediatek/mediatek,sgmiisys.txt +++ b/Documentation/devicetree/bindings/arm/mediatek/mediatek,sgmiisys.txt @@ -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 diff --git a/Documentation/devicetree/bindings/arm/mediatek/mediatek,topckgen.txt b/Documentation/devicetree/bindings/arm/mediatek/mediatek,topckgen.txt index 5ce7578cf274..b82422bb717f 100644 --- a/Documentation/devicetree/bindings/arm/mediatek/mediatek,topckgen.txt +++ b/Documentation/devicetree/bindings/arm/mediatek/mediatek,topckgen.txt @@ -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" diff --git a/Documentation/devicetree/bindings/arm/msm/qcom,llcc.yaml b/Documentation/devicetree/bindings/arm/msm/qcom,llcc.yaml index 62fcbd883392..03882aac8d2d 100644 --- a/Documentation/devicetree/bindings/arm/msm/qcom,llcc.yaml +++ b/Documentation/devicetree/bindings/arm/msm/qcom,llcc.yaml @@ -24,6 +24,7 @@ properties: - qcom,sc7180-llcc - qcom,sc7280-llcc - qcom,sdm845-llcc + - qcom,sm6350-llcc - qcom,sm8150-llcc - qcom,sm8250-llcc @@ -44,7 +45,6 @@ required: - compatible - reg - reg-names - - interrupts additionalProperties: false diff --git a/Documentation/devicetree/bindings/arm/pmu.yaml b/Documentation/devicetree/bindings/arm/pmu.yaml index e17ac049e890..981bac451698 100644 --- a/Documentation/devicetree/bindings/arm/pmu.yaml +++ b/Documentation/devicetree/bindings/arm/pmu.yaml @@ -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 diff --git a/Documentation/devicetree/bindings/arm/qcom.yaml b/Documentation/devicetree/bindings/arm/qcom.yaml index c8808e0f9e64..370aab274cd1 100644 --- a/Documentation/devicetree/bindings/arm/qcom.yaml +++ b/Documentation/devicetree/bindings/arm/qcom.yaml @@ -48,8 +48,10 @@ description: | sdx65 sm7225 sm8150 + sdx65 sm8250 sm8350 + sm8450 The 'board' element must be one of the following strings: @@ -201,8 +203,10 @@ properties: - items: - enum: + - qcom,sc7280-crd - qcom,sc7280-idp - qcom,sc7280-idp2 + - google,hoglin - google,piglin - google,senor - const: qcom,sc7280 @@ -226,6 +230,11 @@ properties: - items: - enum: + - qcom,sdx65-mtp + - const: qcom,sdx65 + + - items: + - enum: - qcom,ipq6018-cp01 - qcom,ipq6018-cp01-c1 - const: qcom,ipq6018 @@ -257,6 +266,11 @@ properties: - qcom,sm8350-mtp - const: qcom,sm8350 + - items: + - enum: + - qcom,sm8450-qrd + - const: qcom,sm8450 + additionalProperties: true ... diff --git a/Documentation/devicetree/bindings/arm/renesas.yaml b/Documentation/devicetree/bindings/arm/renesas.yaml index 517206507801..6a9350ee690b 100644 --- a/Documentation/devicetree/bindings/arm/renesas.yaml +++ b/Documentation/devicetree/bindings/arm/renesas.yaml @@ -315,6 +315,18 @@ properties: - const: renesas,falcon-cpu - const: renesas,r8a779a0 + - description: R-Car S4-8 (R8A779F0) + items: + - enum: + - renesas,spider-cpu # Spider CPU board (RTP8A779F0ASKB0SC2S) + - const: renesas,r8a779f0 + + - items: + - enum: + - renesas,spider-breakout # Spider BreakOut board (RTP8A779F0ASKB0SB0S) + - const: renesas,spider-cpu + - const: renesas,r8a779f0 + - description: R-Car H3e (R8A779M0) items: - enum: diff --git a/Documentation/devicetree/bindings/arm/samsung/samsung-boards.yaml b/Documentation/devicetree/bindings/arm/samsung/samsung-boards.yaml index ef6dc14be4b5..052cd94113d4 100644 --- a/Documentation/devicetree/bindings/arm/samsung/samsung-boards.yaml +++ b/Documentation/devicetree/bindings/arm/samsung/samsung-boards.yaml @@ -199,6 +199,18 @@ properties: - samsung,exynos7-espresso # Samsung Exynos7 Espresso - const: samsung,exynos7 + - description: Exynos7885 based boards + items: + - enum: + - samsung,jackpotlte # Samsung Galaxy A8 (2018) + - const: samsung,exynos7885 + + - description: Exynos850 based boards + items: + - enum: + - winlink,e850-96 # WinLink E850-96 + - const: samsung,exynos850 + - description: Exynos Auto v9 based boards items: - enum: diff --git a/Documentation/devicetree/bindings/arm/stm32/stm32.yaml b/Documentation/devicetree/bindings/arm/stm32/stm32.yaml index bcaf7be3ab37..b07720ea9611 100644 --- a/Documentation/devicetree/bindings/arm/stm32/stm32.yaml +++ b/Documentation/devicetree/bindings/arm/stm32/stm32.yaml @@ -77,6 +77,7 @@ properties: items: - enum: - engicam,icore-stm32mp1-ctouch2 # STM32MP1 Engicam i.Core STM32MP1 C.TOUCH 2.0 + - engicam,icore-stm32mp1-ctouch2-of10 # STM32MP1 Engicam i.Core STM32MP1 C.TOUCH 2.0 10.1" OF - engicam,icore-stm32mp1-edimm2.2 # STM32MP1 Engicam i.Core STM32MP1 EDIMM2.2 Starter Kit - const: engicam,icore-stm32mp1 # STM32MP1 Engicam i.Core STM32MP1 SoM - const: st,stm32mp157 diff --git a/Documentation/devicetree/bindings/arm/sunxi.yaml b/Documentation/devicetree/bindings/arm/sunxi.yaml index 889128acf49a..c8a3102c0fde 100644 --- a/Documentation/devicetree/bindings/arm/sunxi.yaml +++ b/Documentation/devicetree/bindings/arm/sunxi.yaml @@ -808,6 +808,11 @@ properties: - const: oranth,tanix-tx6 - const: allwinner,sun50i-h6 + - description: Tanix TX6 mini + items: + - const: oranth,tanix-tx6-mini + - const: allwinner,sun50i-h6 + - description: TBS A711 Tablet items: - const: tbs-biometrics,a711 diff --git a/Documentation/devicetree/bindings/arm/sunxi/allwinner,sun4i-a10-mbus.yaml b/Documentation/devicetree/bindings/arm/sunxi/allwinner,sun4i-a10-mbus.yaml index 29c9961ee2d8..8eee312c2e6f 100644 --- a/Documentation/devicetree/bindings/arm/sunxi/allwinner,sun4i-a10-mbus.yaml +++ b/Documentation/devicetree/bindings/arm/sunxi/allwinner,sun4i-a10-mbus.yaml @@ -32,12 +32,38 @@ properties: - allwinner,sun8i-h3-mbus - allwinner,sun8i-r40-mbus - allwinner,sun50i-a64-mbus + - allwinner,sun50i-h5-mbus reg: - maxItems: 1 + minItems: 1 + items: + - description: MBUS interconnect/bandwidth limit/PMU registers + - description: DRAM controller/PHY registers + + reg-names: + minItems: 1 + items: + - const: mbus + - const: dram clocks: + minItems: 1 + items: + - description: MBUS interconnect module clock + - description: DRAM controller/PHY module clock + - description: Register bus clock, shared by MBUS and DRAM + + clock-names: + minItems: 1 + items: + - const: mbus + - const: dram + - const: bus + + interrupts: maxItems: 1 + description: + MBUS PMU activity interrupt. dma-ranges: description: @@ -54,13 +80,55 @@ required: - clocks - dma-ranges +if: + properties: + compatible: + contains: + enum: + - allwinner,sun8i-h3-mbus + - allwinner,sun50i-a64-mbus + - allwinner,sun50i-h5-mbus + +then: + properties: + reg: + minItems: 2 + + reg-names: + minItems: 2 + + clocks: + minItems: 3 + + clock-names: + minItems: 3 + + required: + - reg-names + - clock-names + +else: + properties: + reg: + maxItems: 1 + + reg-names: + maxItems: 1 + + clocks: + maxItems: 1 + + clock-names: + maxItems: 1 + additionalProperties: false examples: - | - #include <dt-bindings/clock/sun5i-ccu.h> + #include <dt-bindings/clock/sun50i-a64-ccu.h> + #include <dt-bindings/interrupt-controller/arm-gic.h> - mbus: dram-controller@1c01000 { + dram-controller@1c01000 { compatible = "allwinner,sun5i-a13-mbus"; reg = <0x01c01000 0x1000>; clocks = <&ccu CLK_MBUS>; @@ -70,4 +138,21 @@ examples: #interconnect-cells = <1>; }; + - | + dram-controller@1c62000 { + compatible = "allwinner,sun50i-a64-mbus"; + reg = <0x01c62000 0x1000>, + <0x01c63000 0x1000>; + reg-names = "mbus", "dram"; + clocks = <&ccu CLK_MBUS>, + <&ccu CLK_DRAM>, + <&ccu CLK_BUS_DRAM>; + clock-names = "mbus", "dram", "bus"; + interrupts = <GIC_SPI 69 IRQ_TYPE_LEVEL_HIGH>; + #address-cells = <1>; + #size-cells = <1>; + dma-ranges = <0x00000000 0x40000000 0xc0000000>; + #interconnect-cells = <1>; + }; + ... diff --git a/Documentation/devicetree/bindings/arm/tegra.yaml b/Documentation/devicetree/bindings/arm/tegra.yaml index d79d36ac0c44..49841ca272ee 100644 --- a/Documentation/devicetree/bindings/arm/tegra.yaml +++ b/Documentation/devicetree/bindings/arm/tegra.yaml @@ -37,6 +37,9 @@ properties: - const: toradex,colibri_t20 - const: nvidia,tegra20 - items: + - const: asus,tf101 + - const: nvidia,tegra20 + - items: - const: acer,picasso - const: nvidia,tegra20 - items: @@ -50,6 +53,18 @@ properties: - const: nvidia,cardhu - const: nvidia,tegra30 - items: + - const: asus,tf201 + - const: nvidia,tegra30 + - items: + - const: asus,tf300t + - const: nvidia,tegra30 + - items: + - const: asus,tf300tg + - const: nvidia,tegra30 + - items: + - const: asus,tf700t + - const: nvidia,tegra30 + - items: - const: toradex,apalis_t30-eval - const: toradex,apalis_t30 - const: nvidia,tegra30 @@ -75,7 +90,11 @@ properties: - const: ouya,ouya - const: nvidia,tegra30 - items: + - const: pegatron,chagall + - const: nvidia,tegra30 + - items: - enum: + - asus,tf701t - nvidia,dalmore - nvidia,roth - nvidia,tn7 @@ -108,14 +127,17 @@ properties: - nvidia,p2571 - nvidia,p2894-0050-a08 - const: nvidia,tegra210 - - items: - - enum: - - nvidia,p2771-0000 - - nvidia,p3509-0000+p3636-0001 + - description: Jetson TX2 Developer Kit + items: + - const: nvidia,p2771-0000 - const: nvidia,tegra186 - - items: - - enum: - - nvidia,p2972-0000 + - description: Jetson TX2 NX Developer Kit + items: + - const: nvidia,p3509-0000+p3636-0001 + - const: nvidia,tegra186 + - description: Jetson AGX Xavier Developer Kit + items: + - const: nvidia,p2972-0000 - const: nvidia,tegra194 - description: Jetson Xavier NX items: @@ -134,8 +156,16 @@ properties: - const: nvidia,p3509-0000+p3668-0001 - const: nvidia,tegra194 - items: - - enum: - - nvidia,tegra234-vdk + - const: nvidia,tegra234-vdk + - const: nvidia,tegra234 + - description: Jetson AGX Orin + items: + - const: nvidia,p3701-0000 + - const: nvidia,tegra234 + - description: Jetson AGX Orin Developer Kit + items: + - const: nvidia,p3737-0000+p3701-0000 + - const: nvidia,p3701-0000 - const: nvidia,tegra234 additionalProperties: true diff --git a/Documentation/devicetree/bindings/arm/tegra/nvidia,tegra186-pmc.txt b/Documentation/devicetree/bindings/arm/tegra/nvidia,tegra186-pmc.txt deleted file mode 100644 index 576462fae27f..000000000000 --- a/Documentation/devicetree/bindings/arm/tegra/nvidia,tegra186-pmc.txt +++ /dev/null @@ -1,133 +0,0 @@ -NVIDIA Tegra Power Management Controller (PMC) - -Required properties: -- compatible: Should contain one of the following: - - "nvidia,tegra186-pmc": for Tegra186 - - "nvidia,tegra194-pmc": for Tegra194 - - "nvidia,tegra234-pmc": for Tegra234 -- reg: Must contain an (offset, length) pair of the register set for each - entry in reg-names. -- reg-names: Must include the following entries: - - "pmc" - - "wake" - - "aotag" - - "scratch" - - "misc" (Only for Tegra194 and later) - -Optional properties: -- nvidia,invert-interrupt: If present, inverts the PMU interrupt signal. -- interrupt-controller: Identifies the node as an interrupt controller. -- #interrupt-cells: Specifies the number of cells needed to encode an - interrupt source. The value must be 2. - -Example: - -SoC DTSI: - - pmc@c3600000 { - compatible = "nvidia,tegra186-pmc"; - reg = <0 0x0c360000 0 0x10000>, - <0 0x0c370000 0 0x10000>, - <0 0x0c380000 0 0x10000>, - <0 0x0c390000 0 0x10000>; - reg-names = "pmc", "wake", "aotag", "scratch"; - }; - -Board DTS: - - pmc@c360000 { - nvidia,invert-interrupt; - }; - -== Pad Control == - -On Tegra SoCs a pad is a set of pins which are configured as a group. -The pin grouping is a fixed attribute of the hardware. The PMC can be -used to set pad power state and signaling voltage. A pad can be either -in active or power down mode. The support for power state and signaling -voltage configuration varies depending on the pad in question. 3.3 V and -1.8 V signaling voltages are supported on pins where software -controllable signaling voltage switching is available. - -Pad configurations are described with pin configuration nodes which -are placed under the pmc node and they are referred to by the pinctrl -client properties. For more information see -Documentation/devicetree/bindings/pinctrl/pinctrl-bindings.txt. - -The following pads are present on Tegra186: -csia csib dsi mipi-bias -pex-clk-bias pex-clk3 pex-clk2 pex-clk1 -usb0 usb1 usb2 usb-bias -uart audio hsic dbg -hdmi-dp0 hdmi-dp1 pex-cntrl sdmmc2-hv -sdmmc4 cam dsib dsic -dsid csic csid csie -dsif spi ufs dmic-hv -edp sdmmc1-hv sdmmc3-hv conn -audio-hv ao-hv - -Required pin configuration properties: - - pins: A list of strings, each of which contains the name of a pad - to be configured. - -Optional pin configuration properties: - - low-power-enable: Configure the pad into power down mode - - low-power-disable: Configure the pad into active mode - - power-source: Must contain either TEGRA_IO_PAD_VOLTAGE_1V8 or - TEGRA_IO_PAD_VOLTAGE_3V3 to select between signaling voltages. - The values are defined in - include/dt-bindings/pinctrl/pinctrl-tegra-io-pad.h. - -Note: The power state can be configured on all of the above pads except - for ao-hv. Following pads have software configurable signaling - voltages: sdmmc2-hv, dmic-hv, sdmmc1-hv, sdmmc3-hv, audio-hv, - ao-hv. - -Pad configuration state example: - pmc: pmc@7000e400 { - compatible = "nvidia,tegra186-pmc"; - reg = <0 0x0c360000 0 0x10000>, - <0 0x0c370000 0 0x10000>, - <0 0x0c380000 0 0x10000>, - <0 0x0c390000 0 0x10000>; - reg-names = "pmc", "wake", "aotag", "scratch"; - - ... - - sdmmc1_3v3: sdmmc1-3v3 { - pins = "sdmmc1-hv"; - power-source = <TEGRA_IO_PAD_VOLTAGE_3V3>; - }; - - sdmmc1_1v8: sdmmc1-1v8 { - pins = "sdmmc1-hv"; - power-source = <TEGRA_IO_PAD_VOLTAGE_1V8>; - }; - - hdmi_off: hdmi-off { - pins = "hdmi"; - low-power-enable; - } - - hdmi_on: hdmi-on { - pins = "hdmi"; - low-power-disable; - } - }; - -Pinctrl client example: - sdmmc1: sdhci@3400000 { - ... - pinctrl-names = "sdmmc-3v3", "sdmmc-1v8"; - pinctrl-0 = <&sdmmc1_3v3>; - pinctrl-1 = <&sdmmc1_1v8>; - }; - - ... - - sor0: sor@15540000 { - ... - pinctrl-0 = <&hdmi_off>; - pinctrl-1 = <&hdmi_on>; - pinctrl-names = "hdmi-on", "hdmi-off"; - }; diff --git a/Documentation/devicetree/bindings/arm/tegra/nvidia,tegra186-pmc.yaml b/Documentation/devicetree/bindings/arm/tegra/nvidia,tegra186-pmc.yaml new file mode 100644 index 000000000000..0faa403f68c8 --- /dev/null +++ b/Documentation/devicetree/bindings/arm/tegra/nvidia,tegra186-pmc.yaml @@ -0,0 +1,198 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/arm/tegra/nvidia,tegra186-pmc.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: NVIDIA Tegra Power Management Controller (PMC) + +maintainers: + - Thierry Reding <thierry.reding@gmail.com> + - Jon Hunter <jonathanh@nvidia.com> + +properties: + compatible: + enum: + - nvidia,tegra186-pmc + - nvidia,tegra194-pmc + - nvidia,tegra234-pmc + + reg: + minItems: 4 + maxItems: 5 + + reg-names: + minItems: 4 + items: + - const: pmc + - const: wake + - const: aotag + - const: scratch + - const: misc + + interrupt-controller: true + + "#interrupt-cells": + description: Specifies the number of cells needed to encode an + interrupt source. The value must be 2. + const: 2 + + nvidia,invert-interrupt: + description: If present, inverts the PMU interrupt signal. + $ref: /schemas/types.yaml#/definitions/flag + +if: + properties: + compatible: + contains: + const: nvidia,tegra186-pmc +then: + properties: + reg: + maxItems: 4 + + reg-names: + maxItems: 4 +else: + properties: + reg: + minItems: 5 + + reg-names: + minItems: 5 + +patternProperties: + "^[a-z0-9]+-[a-z0-9]+$": + if: + type: object + then: + description: | + These are pad configuration nodes. On Tegra SoCs a pad is a set of + pins which are configured as a group. The pin grouping is a fixed + attribute of the hardware. The PMC can be used to set pad power + state and signaling voltage. A pad can be either in active or + power down mode. The support for power state and signaling voltage + configuration varies depending on the pad in question. 3.3 V and + 1.8 V signaling voltages are supported on pins where software + controllable signaling voltage switching is available. + + Pad configurations are described with pin configuration nodes + which are placed under the pmc node and they are referred to by + the pinctrl client properties. For more information see + + Documentation/devicetree/bindings/pinctrl/pinctrl-bindings.txt + + The following pads are present on Tegra186: + + csia, csib, dsi, mipi-bias, pex-clk-bias, pex-clk3, pex-clk2, + pex-clk1, usb0, usb1, usb2, usb-bias, uart, audio, hsic, dbg, + hdmi-dp0, hdmi-dp1, pex-cntrl, sdmmc2-hv, sdmmc4, cam, dsib, + dsic, dsid, csic, csid, csie, dsif, spi, ufs, dmic-hv, edp, + sdmmc1-hv, sdmmc3-hv, conn, audio-hv, ao-hv + + The following pads are present on Tegra194: + + csia, csib, mipi-bias, pex-clk-bias, pex-clk3, pex-clk2, + pex-clk1, eqos, pex-clk-2-bias, pex-clk-2, dap3, dap5, uart, + pwr-ctl, soc-gpio53, audio, gp-pwm2, gp-pwm3, soc-gpio12, + soc-gpio13, soc-gpio10, uart4, uart5, dbg, hdmi-dp3, hdmi-dp2, + hdmi-dp0, hdmi-dp1, pex-cntrl, pex-ctl2, pex-l0-rst, + pex-l1-rst, sdmmc4, pex-l5-rst, cam, csic, csid, csie, csif, + spi, ufs, csig, csih, edp, sdmmc1-hv, sdmmc3-hv, conn, + audio-hv, ao-hv + + properties: + pins: + $ref: /schemas/types.yaml#/definitions/string + description: Must contain the name of the pad(s) to be + configured. + + low-power-enable: + description: Configure the pad into power down mode. + $ref: /schemas/types.yaml#/definitions/flag + + low-power-disable: + description: Configure the pad into active mode. + $ref: /schemas/types.yaml#/definitions/flag + + power-source: + $ref: /schemas/types.yaml#/definitions/uint32 + description: | + Must contain either TEGRA_IO_PAD_VOLTAGE_1V8 or + TEGRA_IO_PAD_VOLTAGE_3V3 to select between signalling + voltages. + + The values are defined in + + include/dt-bindings/pinctrl/pinctrl-tegra-io-pad.h + + The power state can be configured on all of the above pads + except for ao-hv. Following pads have software configurable + signaling voltages: sdmmc2-hv, dmic-hv, sdmmc1-hv, sdmmc3-hv, + audio-hv, ao-hv. + + phandle: true + + required: + - pins + + additionalProperties: false + +required: + - compatible + - reg + - reg-names + +additionalProperties: false + +dependencies: + interrupt-controller: ['#interrupt-cells'] + "#interrupt-cells": + required: + - interrupt-controller + +examples: + - | + #include <dt-bindings/clock/tegra186-clock.h> + #include <dt-bindings/interrupt-controller/arm-gic.h> + #include <dt-bindings/pinctrl/pinctrl-tegra-io-pad.h> + #include <dt-bindings/memory/tegra186-mc.h> + #include <dt-bindings/reset/tegra186-reset.h> + + pmc@c3600000 { + compatible = "nvidia,tegra186-pmc"; + reg = <0x0c360000 0x10000>, + <0x0c370000 0x10000>, + <0x0c380000 0x10000>, + <0x0c390000 0x10000>; + reg-names = "pmc", "wake", "aotag", "scratch"; + nvidia,invert-interrupt; + + sdmmc1_3v3: sdmmc1-3v3 { + pins = "sdmmc1-hv"; + power-source = <TEGRA_IO_PAD_VOLTAGE_3V3>; + }; + + sdmmc1_1v8: sdmmc1-1v8 { + pins = "sdmmc1-hv"; + power-source = <TEGRA_IO_PAD_VOLTAGE_1V8>; + }; + }; + + sdmmc1: mmc@3400000 { + compatible = "nvidia,tegra186-sdhci"; + reg = <0x03400000 0x10000>; + interrupts = <GIC_SPI 62 IRQ_TYPE_LEVEL_HIGH>; + clocks = <&bpmp TEGRA186_CLK_SDMMC1>, + <&bpmp TEGRA186_CLK_SDMMC_LEGACY_TM>; + clock-names = "sdhci", "tmclk"; + resets = <&bpmp TEGRA186_RESET_SDMMC1>; + reset-names = "sdhci"; + interconnects = <&mc TEGRA186_MEMORY_CLIENT_SDMMCRA &emc>, + <&mc TEGRA186_MEMORY_CLIENT_SDMMCWA &emc>; + interconnect-names = "dma-mem", "write"; + iommus = <&smmu TEGRA186_SID_SDMMC1>; + pinctrl-names = "sdmmc-3v3", "sdmmc-1v8"; + pinctrl-0 = <&sdmmc1_3v3>; + pinctrl-1 = <&sdmmc1_1v8>; + }; diff --git a/Documentation/devicetree/bindings/arm/ti/k3.yaml b/Documentation/devicetree/bindings/arm/ti/k3.yaml index cf327230fc0e..b03c10fa2e7a 100644 --- a/Documentation/devicetree/bindings/arm/ti/k3.yaml +++ b/Documentation/devicetree/bindings/arm/ti/k3.yaml @@ -53,6 +53,12 @@ properties: - ti,am642-sk - const: ti,am642 + - description: K3 J721s2 SoC + items: + - enum: + - ti,j721s2-evm + - const: ti,j721s2 + additionalProperties: true ... diff --git a/Documentation/devicetree/bindings/arm/ux500.yaml b/Documentation/devicetree/bindings/arm/ux500.yaml index 5db7cfba81a4..a46193ad94e0 100644 --- a/Documentation/devicetree/bindings/arm/ux500.yaml +++ b/Documentation/devicetree/bindings/arm/ux500.yaml @@ -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 diff --git a/Documentation/devicetree/bindings/arm/xen.txt b/Documentation/devicetree/bindings/arm/xen.txt index db5c56db30ec..61d77acbeb5e 100644 --- a/Documentation/devicetree/bindings/arm/xen.txt +++ b/Documentation/devicetree/bindings/arm/xen.txt @@ -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: diff --git a/Documentation/devicetree/bindings/ata/brcm,sata-brcm.txt b/Documentation/devicetree/bindings/ata/brcm,sata-brcm.txt deleted file mode 100644 index b9ae4ce4a0a0..000000000000 --- a/Documentation/devicetree/bindings/ata/brcm,sata-brcm.txt +++ /dev/null @@ -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>; - }; - }; diff --git a/Documentation/devicetree/bindings/ata/brcm,sata-brcm.yaml b/Documentation/devicetree/bindings/ata/brcm,sata-brcm.yaml new file mode 100644 index 000000000000..235a93ac86b0 --- /dev/null +++ b/Documentation/devicetree/bindings/ata/brcm,sata-brcm.yaml @@ -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>; + }; + }; diff --git a/Documentation/devicetree/bindings/bus/brcm,gisb-arb.txt b/Documentation/devicetree/bindings/bus/brcm,gisb-arb.txt deleted file mode 100644 index 10f6d0a8159d..000000000000 --- a/Documentation/devicetree/bindings/bus/brcm,gisb-arb.txt +++ /dev/null @@ -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"; -}; diff --git a/Documentation/devicetree/bindings/bus/brcm,gisb-arb.yaml b/Documentation/devicetree/bindings/bus/brcm,gisb-arb.yaml new file mode 100644 index 000000000000..b23c3001991e --- /dev/null +++ b/Documentation/devicetree/bindings/bus/brcm,gisb-arb.yaml @@ -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"; + }; diff --git a/Documentation/devicetree/bindings/bus/fsl,spba-bus.yaml b/Documentation/devicetree/bindings/bus/fsl,spba-bus.yaml new file mode 100644 index 000000000000..d42dbb0bbc2e --- /dev/null +++ b/Documentation/devicetree/bindings/bus/fsl,spba-bus.yaml @@ -0,0 +1,68 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/bus/fsl,spba-bus.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Shared Peripherals Bus Interface + +maintainers: + - Shawn Guo <shawnguo@kernel.org> + +description: | + A simple bus enabling access to shared peripherals. + + The "spba-bus" follows the "simple-bus" set of properties, as + specified in the Devicetree Specification. It is an extension of + "simple-bus" because the SDMA controller uses this compatible flag to + determine which peripherals are available to it and the range over which + the SDMA can access. There are no special clocks for the bus, because + the SDMA controller itself has its interrupt and clock assignments. + +select: + properties: + compatible: + contains: + const: fsl,spba-bus + required: + - compatible + +properties: + $nodename: + pattern: "^spba-bus(@[0-9a-f]+)?$" + + compatible: + items: + - const: fsl,spba-bus + - const: simple-bus + + '#address-cells': + enum: [ 1, 2 ] + + '#size-cells': + enum: [ 1, 2 ] + + reg: + maxItems: 1 + + ranges: true + +required: + - compatible + - '#address-cells' + - '#size-cells' + - reg + - ranges + +additionalProperties: + type: object + +examples: + - | + spba-bus@30000000 { + compatible = "fsl,spba-bus", "simple-bus"; + #address-cells = <1>; + #size-cells = <1>; + reg = <0x30000000 0x100000>; + ranges; + }; diff --git a/Documentation/devicetree/bindings/bus/imx-weim.txt b/Documentation/devicetree/bindings/bus/imx-weim.txt index 1b1d1c5c21ea..e7f502070d77 100644 --- a/Documentation/devicetree/bindings/bus/imx-weim.txt +++ b/Documentation/devicetree/bindings/bus/imx-weim.txt @@ -48,6 +48,11 @@ Optional properties: devices, the presence of this property indicates that the weim bus should operate in Burst Clock Mode. + - fsl,continuous-burst-clk Make Burst Clock to output continuous clock. + Without this option Burst Clock will output clock + only when necessary. This takes effect only if + "fsl,burst-clk-enable" is set. + Timing property for child nodes. It is mandatory, not optional. - fsl,weim-cs-timing: The timing array, contains timing values for the diff --git a/Documentation/devicetree/bindings/clock/allwinner,sun4i-a10-ccu.yaml b/Documentation/devicetree/bindings/clock/allwinner,sun4i-a10-ccu.yaml index c4b7243ddcf2..15ed64d35261 100644 --- a/Documentation/devicetree/bindings/clock/allwinner,sun4i-a10-ccu.yaml +++ b/Documentation/devicetree/bindings/clock/allwinner,sun4i-a10-ccu.yaml @@ -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 diff --git a/Documentation/devicetree/bindings/clock/exynos5260-clock.txt b/Documentation/devicetree/bindings/clock/exynos5260-clock.txt deleted file mode 100644 index c79d31f7f66e..000000000000 --- a/Documentation/devicetree/bindings/clock/exynos5260-clock.txt +++ /dev/null @@ -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"; - }; - diff --git a/Documentation/devicetree/bindings/clock/exynos5410-clock.txt b/Documentation/devicetree/bindings/clock/exynos5410-clock.txt deleted file mode 100644 index 217beb27c30e..000000000000 --- a/Documentation/devicetree/bindings/clock/exynos5410-clock.txt +++ /dev/null @@ -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"; - }; diff --git a/Documentation/devicetree/bindings/clock/exynos5433-clock.txt b/Documentation/devicetree/bindings/clock/exynos5433-clock.txt deleted file mode 100644 index 183c327a7d6b..000000000000 --- a/Documentation/devicetree/bindings/clock/exynos5433-clock.txt +++ /dev/null @@ -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>; - }; diff --git a/Documentation/devicetree/bindings/clock/exynos7-clock.txt b/Documentation/devicetree/bindings/clock/exynos7-clock.txt deleted file mode 100644 index 6bf1e7493f61..000000000000 --- a/Documentation/devicetree/bindings/clock/exynos7-clock.txt +++ /dev/null @@ -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 diff --git a/Documentation/devicetree/bindings/clock/imx5-clock.yaml b/Documentation/devicetree/bindings/clock/imx5-clock.yaml index b1740d7abe68..c0e19ff92c76 100644 --- a/Documentation/devicetree/bindings/clock/imx5-clock.yaml +++ b/Documentation/devicetree/bindings/clock/imx5-clock.yaml @@ -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"; - }; +... diff --git a/Documentation/devicetree/bindings/clock/microchip,lan966x-gck.yaml b/Documentation/devicetree/bindings/clock/microchip,lan966x-gck.yaml new file mode 100644 index 000000000000..df2bec188706 --- /dev/null +++ b/Documentation/devicetree/bindings/clock/microchip,lan966x-gck.yaml @@ -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>; + }; +... diff --git a/Documentation/devicetree/bindings/clock/nvidia,tegra20-car.yaml b/Documentation/devicetree/bindings/clock/nvidia,tegra20-car.yaml index 459d2a525393..f832abb7f11a 100644 --- a/Documentation/devicetree/bindings/clock/nvidia,tegra20-car.yaml +++ b/Documentation/devicetree/bindings/clock/nvidia,tegra20-car.yaml @@ -42,6 +42,36 @@ properties: "#reset-cells": const: 1 +patternProperties: + "^(sclk)|(pll-[cem])$": + type: object + properties: + compatible: + enum: + - nvidia,tegra20-sclk + - nvidia,tegra30-sclk + - nvidia,tegra30-pllc + - nvidia,tegra30-plle + - nvidia,tegra30-pllm + + operating-points-v2: true + + clocks: + items: + - description: node's clock + + power-domains: + maxItems: 1 + description: phandle to the core SoC power domain + + required: + - compatible + - operating-points-v2 + - clocks + - power-domains + + additionalProperties: false + required: - compatible - reg @@ -59,6 +89,13 @@ examples: reg = <0x60006000 0x1000>; #clock-cells = <1>; #reset-cells = <1>; + + sclk { + compatible = "nvidia,tegra20-sclk"; + operating-points-v2 = <&opp_table>; + clocks = <&tegra_car TEGRA20_CLK_SCLK>; + power-domains = <&domain>; + }; }; usb-controller@c5004000 { diff --git a/Documentation/devicetree/bindings/clock/qcom,gcc-msm8976.yaml b/Documentation/devicetree/bindings/clock/qcom,gcc-msm8976.yaml new file mode 100644 index 000000000000..f3430b159caa --- /dev/null +++ b/Documentation/devicetree/bindings/clock/qcom,gcc-msm8976.yaml @@ -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>; + }; +... diff --git a/Documentation/devicetree/bindings/clock/qcom,gcc-sdx65.yaml b/Documentation/devicetree/bindings/clock/qcom,gcc-sdx65.yaml new file mode 100644 index 000000000000..16c4cdc7b4d6 --- /dev/null +++ b/Documentation/devicetree/bindings/clock/qcom,gcc-sdx65.yaml @@ -0,0 +1,80 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/clock/qcom,gcc-sdx65.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Qualcomm Global Clock & Reset Controller Binding for SDX65 + +maintainers: + - Vamsi krishna Lanka <quic_vamslank@quicinc.com> + +description: | + Qualcomm global clock control module which supports the clocks, resets and + power domains on SDX65 + + See also: + - dt-bindings/clock/qcom,gcc-sdx65.h + +properties: + compatible: + const: qcom,gcc-sdx65 + + reg: + maxItems: 1 + + clocks: + items: + - description: Board XO source + - description: Board active XO source + - description: Sleep clock source + - description: PCIE Pipe clock source + - description: USB3 phy wrapper pipe clock source + - description: PLL test clock source (Optional clock) + minItems: 5 + + clock-names: + items: + - const: bi_tcxo + - const: bi_tcxo_ao + - const: sleep_clk + - const: pcie_pipe_clk + - const: usb3_phy_wrapper_gcc_usb30_pipe_clk + - const: core_bi_pll_test_se # Optional clock + minItems: 5 + + '#clock-cells': + const: 1 + + '#reset-cells': + const: 1 + + '#power-domain-cells': + const: 1 + +required: + - compatible + - reg + - clocks + - clock-names + - '#clock-cells' + - '#reset-cells' + - '#power-domain-cells' + +additionalProperties: false + +examples: + - | + #include <dt-bindings/clock/qcom,rpmh.h> + clock-controller@100000 { + compatible = "qcom,gcc-sdx65"; + reg = <0x100000 0x1f7400>; + clocks = <&rpmhcc RPMH_CXO_CLK>, <&rpmhcc RPMH_CXO_CLK_A>, <&sleep_clk>, + <&pcie_pipe_clk>, <&usb3_phy_wrapper_gcc_usb30_pipe_clk>, <&pll_test_clk>; + clock-names = "bi_tcxo", "bi_tcxo_ao", "sleep_clk", + "pcie_pipe_clk", "usb3_phy_wrapper_gcc_usb30_pipe_clk", "core_bi_pll_test_se"; + #clock-cells = <1>; + #reset-cells = <1>; + #power-domain-cells = <1>; + }; +... diff --git a/Documentation/devicetree/bindings/clock/qcom,gcc-sm8450.yaml b/Documentation/devicetree/bindings/clock/qcom,gcc-sm8450.yaml new file mode 100644 index 000000000000..58d98a766de6 --- /dev/null +++ b/Documentation/devicetree/bindings/clock/qcom,gcc-sm8450.yaml @@ -0,0 +1,85 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/clock/qcom,gcc-sm8450.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Qualcomm Global Clock & Reset Controller Binding for SM8450 + +maintainers: + - Vinod Koul <vkoul@kernel.org> + +description: | + Qualcomm global clock control module which supports the clocks, resets and + power domains on SM8450 + + See also: + - dt-bindings/clock/qcom,gcc-sm8450.h + +properties: + compatible: + const: qcom,gcc-sm8450 + + clocks: + items: + - description: Board XO source + - description: Sleep clock source + - description: PCIE 0 Pipe clock source (Optional clock) + - description: PCIE 1 Pipe clock source (Optional clock) + - description: PCIE 1 Phy Auxillary clock source (Optional clock) + - description: UFS Phy Rx symbol 0 clock source (Optional clock) + - description: UFS Phy Rx symbol 1 clock source (Optional clock) + - description: UFS Phy Tx symbol 0 clock source (Optional clock) + - description: USB3 Phy wrapper pipe clock source (Optional clock) + minItems: 2 + + clock-names: + items: + - const: bi_tcxo + - const: sleep_clk + - const: pcie_0_pipe_clk # Optional clock + - const: pcie_1_pipe_clk # Optional clock + - const: pcie_1_phy_aux_clk # Optional clock + - const: ufs_phy_rx_symbol_0_clk # Optional clock + - const: ufs_phy_rx_symbol_1_clk # Optional clock + - const: ufs_phy_tx_symbol_0_clk # Optional clock + - const: usb3_phy_wrapper_gcc_usb30_pipe_clk # Optional clock + minItems: 2 + + '#clock-cells': + const: 1 + + '#reset-cells': + const: 1 + + '#power-domain-cells': + const: 1 + + reg: + maxItems: 1 + +required: + - compatible + - reg + - clocks + - clock-names + - '#clock-cells' + - '#reset-cells' + - '#power-domain-cells' + +additionalProperties: false + +examples: + - | + #include <dt-bindings/clock/qcom,rpmh.h> + clock-controller@100000 { + compatible = "qcom,gcc-sm8450"; + reg = <0x00100000 0x001f4200>; + clocks = <&rpmhcc RPMH_CXO_CLK>, <&sleep_clk>; + clock-names = "bi_tcxo", "sleep_clk"; + #clock-cells = <1>; + #reset-cells = <1>; + #power-domain-cells = <1>; + }; + +... diff --git a/Documentation/devicetree/bindings/clock/qcom,rpmhcc.yaml b/Documentation/devicetree/bindings/clock/qcom,rpmhcc.yaml index 72212970e6f5..8406dde17937 100644 --- a/Documentation/devicetree/bindings/clock/qcom,rpmhcc.yaml +++ b/Documentation/devicetree/bindings/clock/qcom,rpmhcc.yaml @@ -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 diff --git a/Documentation/devicetree/bindings/clock/renesas,cpg-mssr.yaml b/Documentation/devicetree/bindings/clock/renesas,cpg-mssr.yaml index 9b414fbde6d7..e0b86214f0f5 100644 --- a/Documentation/devicetree/bindings/clock/renesas,cpg-mssr.yaml +++ b/Documentation/devicetree/bindings/clock/renesas,cpg-mssr.yaml @@ -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 diff --git a/Documentation/devicetree/bindings/clock/samsung,exynos5260-clock.yaml b/Documentation/devicetree/bindings/clock/samsung,exynos5260-clock.yaml new file mode 100644 index 000000000000..a3fac5c6809d --- /dev/null +++ b/Documentation/devicetree/bindings/clock/samsung,exynos5260-clock.yaml @@ -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"; + }; diff --git a/Documentation/devicetree/bindings/clock/samsung,exynos5410-clock.yaml b/Documentation/devicetree/bindings/clock/samsung,exynos5410-clock.yaml new file mode 100644 index 000000000000..032862e9f55b --- /dev/null +++ b/Documentation/devicetree/bindings/clock/samsung,exynos5410-clock.yaml @@ -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>; + }; diff --git a/Documentation/devicetree/bindings/clock/samsung,exynos5433-clock.yaml b/Documentation/devicetree/bindings/clock/samsung,exynos5433-clock.yaml new file mode 100644 index 000000000000..edd1b4ac4334 --- /dev/null +++ b/Documentation/devicetree/bindings/clock/samsung,exynos5433-clock.yaml @@ -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>; + }; diff --git a/Documentation/devicetree/bindings/clock/samsung,exynos7-clock.yaml b/Documentation/devicetree/bindings/clock/samsung,exynos7-clock.yaml new file mode 100644 index 000000000000..599baf0b7231 --- /dev/null +++ b/Documentation/devicetree/bindings/clock/samsung,exynos7-clock.yaml @@ -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"; + }; diff --git a/Documentation/devicetree/bindings/clock/samsung,exynos7885-clock.yaml b/Documentation/devicetree/bindings/clock/samsung,exynos7885-clock.yaml new file mode 100644 index 000000000000..7e5a9cac2fd2 --- /dev/null +++ b/Documentation/devicetree/bindings/clock/samsung,exynos7885-clock.yaml @@ -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"; + }; + +... diff --git a/Documentation/devicetree/bindings/clock/samsung,exynos850-clock.yaml b/Documentation/devicetree/bindings/clock/samsung,exynos850-clock.yaml index 7f8c91a29b91..80ba60838f2b 100644 --- a/Documentation/devicetree/bindings/clock/samsung,exynos850-clock.yaml +++ b/Documentation/devicetree/bindings/clock/samsung,exynos850-clock.yaml @@ -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 @@ -72,6 +74,42 @@ allOf: 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: + contains: const: samsung,exynos850-cmu-core then: diff --git a/Documentation/devicetree/bindings/clock/samsung,s5pv210-clock.txt b/Documentation/devicetree/bindings/clock/samsung,s5pv210-clock.txt deleted file mode 100644 index a86c83bf9d4e..000000000000 --- a/Documentation/devicetree/bindings/clock/samsung,s5pv210-clock.txt +++ /dev/null @@ -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>; - }; diff --git a/Documentation/devicetree/bindings/clock/samsung,s5pv210-clock.yaml b/Documentation/devicetree/bindings/clock/samsung,s5pv210-clock.yaml new file mode 100644 index 000000000000..dcb29a2d1159 --- /dev/null +++ b/Documentation/devicetree/bindings/clock/samsung,s5pv210-clock.yaml @@ -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>; + }; diff --git a/Documentation/devicetree/bindings/clock/starfive,jh7100-clkgen.yaml b/Documentation/devicetree/bindings/clock/starfive,jh7100-clkgen.yaml new file mode 100644 index 000000000000..12f17b60ecbe --- /dev/null +++ b/Documentation/devicetree/bindings/clock/starfive,jh7100-clkgen.yaml @@ -0,0 +1,56 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/clock/starfive,jh7100-clkgen.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: StarFive JH7100 Clock Generator + +maintainers: + - Geert Uytterhoeven <geert@linux-m68k.org> + - Emil Renner Berthing <kernel@esmil.dk> + +properties: + compatible: + const: starfive,jh7100-clkgen + + reg: + maxItems: 1 + + clocks: + items: + - description: Main clock source (25 MHz) + - description: Application-specific clock source (12-27 MHz) + - description: RMII reference clock (50 MHz) + - description: RGMII RX clock (125 MHz) + + clock-names: + items: + - const: osc_sys + - const: osc_aud + - const: gmac_rmii_ref + - const: gmac_gr_mii_rxclk + + '#clock-cells': + const: 1 + description: + See <dt-bindings/clock/starfive-jh7100.h> for valid indices. + +required: + - compatible + - reg + - clocks + - clock-names + - '#clock-cells' + +additionalProperties: false + +examples: + - | + clock-controller@11800000 { + compatible = "starfive,jh7100-clkgen"; + reg = <0x11800000 0x10000>; + clocks = <&osc_sys>, <&osc_aud>, <&gmac_rmii_ref>, <&gmac_gr_mii_rxclk>; + clock-names = "osc_sys", "osc_aud", "gmac_rmii_ref", "gmac_gr_mii_rxclk"; + #clock-cells = <1>; + }; diff --git a/Documentation/devicetree/bindings/clock/toshiba,tmpv770x-pipllct.yaml b/Documentation/devicetree/bindings/clock/toshiba,tmpv770x-pipllct.yaml new file mode 100644 index 000000000000..7b7300ce96d6 --- /dev/null +++ b/Documentation/devicetree/bindings/clock/toshiba,tmpv770x-pipllct.yaml @@ -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>; + }; + }; +... diff --git a/Documentation/devicetree/bindings/clock/toshiba,tmpv770x-pismu.yaml b/Documentation/devicetree/bindings/clock/toshiba,tmpv770x-pismu.yaml new file mode 100644 index 000000000000..ed79f16fe6bc --- /dev/null +++ b/Documentation/devicetree/bindings/clock/toshiba,tmpv770x-pismu.yaml @@ -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>; + }; + }; +... diff --git a/Documentation/devicetree/bindings/crypto/allwinner,sun4i-a10-crypto.yaml b/Documentation/devicetree/bindings/crypto/allwinner,sun4i-a10-crypto.yaml index 0429fb774f10..dedc99e34ebc 100644 --- a/Documentation/devicetree/bindings/crypto/allwinner,sun4i-a10-crypto.yaml +++ b/Documentation/devicetree/bindings/crypto/allwinner,sun4i-a10-crypto.yaml @@ -44,6 +44,16 @@ properties: - const: ahb - const: mod + dmas: + items: + - description: RX DMA Channel + - description: TX DMA Channel + + dma-names: + items: + - const: rx + - const: tx + resets: maxItems: 1 diff --git a/Documentation/devicetree/bindings/crypto/qcom,prng.txt b/Documentation/devicetree/bindings/crypto/qcom,prng.txt deleted file mode 100644 index 7ee0e9eac973..000000000000 --- a/Documentation/devicetree/bindings/crypto/qcom,prng.txt +++ /dev/null @@ -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"; - }; diff --git a/Documentation/devicetree/bindings/crypto/qcom,prng.yaml b/Documentation/devicetree/bindings/crypto/qcom,prng.yaml new file mode 100644 index 000000000000..bb42f4588b40 --- /dev/null +++ b/Documentation/devicetree/bindings/crypto/qcom,prng.yaml @@ -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"; + }; diff --git a/Documentation/devicetree/bindings/display/amlogic,meson-dw-hdmi.yaml b/Documentation/devicetree/bindings/display/amlogic,meson-dw-hdmi.yaml index cf5a208f2f10..343598c9f473 100644 --- a/Documentation/devicetree/bindings/display/amlogic,meson-dw-hdmi.yaml +++ b/Documentation/devicetree/bindings/display/amlogic,meson-dw-hdmi.yaml @@ -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 diff --git a/Documentation/devicetree/bindings/display/amlogic,meson-vpu.yaml b/Documentation/devicetree/bindings/display/amlogic,meson-vpu.yaml index 851cb0781217..047fd69e0377 100644 --- a/Documentation/devicetree/bindings/display/amlogic,meson-vpu.yaml +++ b/Documentation/devicetree/bindings/display/amlogic,meson-vpu.yaml @@ -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 { diff --git a/Documentation/devicetree/bindings/display/bridge/analogix,anx7814.yaml b/Documentation/devicetree/bindings/display/bridge/analogix,anx7814.yaml index 8e13f27b28ed..bce96b5b0db0 100644 --- a/Documentation/devicetree/bindings/display/bridge/analogix,anx7814.yaml +++ b/Documentation/devicetree/bindings/display/bridge/analogix,anx7814.yaml @@ -7,7 +7,9 @@ $schema: http://devicetree.org/meta-schemas/core.yaml# title: Analogix ANX7814 SlimPort (Full-HD Transmitter) maintainers: - - Enric Balletbo i Serra <enric.balletbo@collabora.com> + - Andrzej Hajda <andrzej.hajda@intel.com> + - Neil Armstrong <narmstrong@baylibre.com> + - Robert Foss <robert.foss@linaro.org> properties: compatible: diff --git a/Documentation/devicetree/bindings/display/bridge/google,cros-ec-anx7688.yaml b/Documentation/devicetree/bindings/display/bridge/google,cros-ec-anx7688.yaml index 9f7cc6b757cb..a88a5d8c7ba5 100644 --- a/Documentation/devicetree/bindings/display/bridge/google,cros-ec-anx7688.yaml +++ b/Documentation/devicetree/bindings/display/bridge/google,cros-ec-anx7688.yaml @@ -8,7 +8,6 @@ title: ChromeOS EC ANX7688 HDMI to DP Converter through Type-C Port maintainers: - Nicolas Boichat <drinkcat@chromium.org> - - Enric Balletbo i Serra <enric.balletbo@collabora.com> description: | ChromeOS EC ANX7688 is a display bridge that converts HDMI 2.0 to diff --git a/Documentation/devicetree/bindings/display/bridge/lvds-codec.yaml b/Documentation/devicetree/bindings/display/bridge/lvds-codec.yaml index 1faae3e323a4..5079c1cc337b 100644 --- a/Documentation/devicetree/bindings/display/bridge/lvds-codec.yaml +++ b/Documentation/devicetree/bindings/display/bridge/lvds-codec.yaml @@ -79,6 +79,14 @@ properties: - port@0 - port@1 + pclk-sample: + description: + Data sampling on rising or falling edge. + enum: + - 0 # Falling edge + - 1 # Rising edge + default: 0 + powerdown-gpios: description: The GPIO used to control the power down line of this device. @@ -86,21 +94,32 @@ properties: power-supply: true -if: - not: - properties: - compatible: - contains: - const: lvds-decoder -then: - properties: - ports: +allOf: + - if: + not: + properties: + compatible: + contains: + const: lvds-decoder + then: properties: - port@0: + ports: properties: - endpoint: + port@0: properties: - data-mapping: false + endpoint: + properties: + data-mapping: false + + - if: + not: + properties: + compatible: + contains: + const: lvds-encoder + then: + properties: + pclk-sample: false required: - compatible diff --git a/Documentation/devicetree/bindings/display/bridge/ps8640.yaml b/Documentation/devicetree/bindings/display/bridge/ps8640.yaml index cdaf7a7a8f88..186e17be51fb 100644 --- a/Documentation/devicetree/bindings/display/bridge/ps8640.yaml +++ b/Documentation/devicetree/bindings/display/bridge/ps8640.yaml @@ -8,7 +8,6 @@ title: MIPI DSI to eDP Video Format Converter Device Tree Bindings maintainers: - Nicolas Boichat <drinkcat@chromium.org> - - Enric Balletbo i Serra <enric.balletbo@collabora.com> description: | The PS8640 is a low power MIPI-to-eDP video format converter supporting diff --git a/Documentation/devicetree/bindings/display/bridge/renesas,dsi-csi2-tx.yaml b/Documentation/devicetree/bindings/display/bridge/renesas,dsi-csi2-tx.yaml new file mode 100644 index 000000000000..afeeb967393d --- /dev/null +++ b/Documentation/devicetree/bindings/display/bridge/renesas,dsi-csi2-tx.yaml @@ -0,0 +1,118 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/display/bridge/renesas,dsi-csi2-tx.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Renesas R-Car MIPI DSI/CSI-2 Encoder + +maintainers: + - Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> + +description: | + This binding describes the MIPI DSI/CSI-2 encoder embedded in the Renesas + R-Car V3U SoC. The encoder can operate in either DSI or CSI-2 mode, with up + to four data lanes. + +properties: + compatible: + enum: + - renesas,r8a779a0-dsi-csi2-tx # for V3U + + reg: + maxItems: 1 + + clocks: + items: + - description: Functional clock + - description: DSI (and CSI-2) functional clock + - description: PLL reference clock + + clock-names: + items: + - const: fck + - const: dsi + - const: pll + + power-domains: + maxItems: 1 + + resets: + maxItems: 1 + + ports: + $ref: /schemas/graph.yaml#/properties/ports + + properties: + port@0: + $ref: /schemas/graph.yaml#/properties/port + description: Parallel input port + + port@1: + $ref: /schemas/graph.yaml#/$defs/port-base + unevaluatedProperties: false + description: DSI/CSI-2 output port + + properties: + endpoint: + $ref: /schemas/media/video-interfaces.yaml# + unevaluatedProperties: false + + properties: + data-lanes: + minItems: 1 + maxItems: 4 + + required: + - data-lanes + + required: + - port@0 + - port@1 + +required: + - compatible + - reg + - clocks + - power-domains + - resets + - ports + +additionalProperties: false + +examples: + - | + #include <dt-bindings/clock/r8a779a0-cpg-mssr.h> + #include <dt-bindings/power/r8a779a0-sysc.h> + + dsi0: dsi-encoder@fed80000 { + compatible = "renesas,r8a779a0-dsi-csi2-tx"; + reg = <0xfed80000 0x10000>; + power-domains = <&sysc R8A779A0_PD_ALWAYS_ON>; + clocks = <&cpg CPG_MOD 415>, + <&cpg CPG_CORE R8A779A0_CLK_DSI>, + <&cpg CPG_CORE R8A779A0_CLK_CP>; + clock-names = "fck", "dsi", "pll"; + resets = <&cpg 415>; + + ports { + #address-cells = <1>; + #size-cells = <0>; + + port@0 { + reg = <0>; + dsi0_in: endpoint { + remote-endpoint = <&du_out_dsi0>; + }; + }; + + port@1 { + reg = <1>; + dsi0_out: endpoint { + data-lanes = <1 2>; + remote-endpoint = <&sn65dsi86_in>; + }; + }; + }; + }; +... diff --git a/Documentation/devicetree/bindings/display/msm/dp-controller.yaml b/Documentation/devicetree/bindings/display/msm/dp-controller.yaml index 63e585f48789..5457612ab136 100644 --- a/Documentation/devicetree/bindings/display/msm/dp-controller.yaml +++ b/Documentation/devicetree/bindings/display/msm/dp-controller.yaml @@ -17,6 +17,8 @@ properties: compatible: enum: - qcom,sc7180-dp + - qcom,sc7280-dp + - qcom,sc7280-edp - qcom,sc8180x-dp - qcom,sc8180x-edp diff --git a/Documentation/devicetree/bindings/display/msm/dpu-sdm845.yaml b/Documentation/devicetree/bindings/display/msm/dpu-sdm845.yaml index b4ea7c92fb3d..0dca4b3d66e4 100644 --- a/Documentation/devicetree/bindings/display/msm/dpu-sdm845.yaml +++ b/Documentation/devicetree/bindings/display/msm/dpu-sdm845.yaml @@ -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; diff --git a/Documentation/devicetree/bindings/display/msm/edp.txt b/Documentation/devicetree/bindings/display/msm/edp.txt deleted file mode 100644 index eff9daff418c..000000000000 --- a/Documentation/devicetree/bindings/display/msm/edp.txt +++ /dev/null @@ -1,56 +0,0 @@ -Qualcomm Technologies Inc. adreno/snapdragon eDP output - -Required properties: -- compatible: - * "qcom,mdss-edp" -- reg: Physical base address and length of the registers of controller and PLL -- reg-names: The names of register regions. The following regions are required: - * "edp" - * "pll_base" -- interrupts: The interrupt signal from the eDP block. -- power-domains: Should be <&mmcc MDSS_GDSC>. -- clocks: device clocks - See Documentation/devicetree/bindings/clock/clock-bindings.txt for details. -- clock-names: the following clocks are required: - * "core" - * "iface" - * "mdp_core" - * "pixel" - * "link" -- #clock-cells: The value should be 1. -- vdda-supply: phandle to vdda regulator device node -- lvl-vdd-supply: phandle to regulator device node which is used to supply power - to HPD receiving chip -- panel-en-gpios: GPIO pin to supply power to panel. -- panel-hpd-gpios: GPIO pin used for eDP hpd. - - -Example: - mdss_edp: qcom,mdss_edp@fd923400 { - compatible = "qcom,mdss-edp"; - reg-names = - "edp", - "pll_base"; - reg = <0xfd923400 0x700>, - <0xfd923a00 0xd4>; - interrupt-parent = <&mdss_mdp>; - interrupts = <12 0>; - power-domains = <&mmcc MDSS_GDSC>; - clock-names = - "core", - "pixel", - "iface", - "link", - "mdp_core"; - clocks = - <&mmcc MDSS_EDPAUX_CLK>, - <&mmcc MDSS_EDPPIXEL_CLK>, - <&mmcc MDSS_AHB_CLK>, - <&mmcc MDSS_EDPLINK_CLK>, - <&mmcc MDSS_MDP_CLK>; - #clock-cells = <1>; - vdda-supply = <&pma8084_l12>; - lvl-vdd-supply = <&lvl_vreg>; - panel-en-gpios = <&tlmm 137 0>; - panel-hpd-gpios = <&tlmm 103 0>; - }; diff --git a/Documentation/devicetree/bindings/display/panel/abt,y030xx067a.yaml b/Documentation/devicetree/bindings/display/panel/abt,y030xx067a.yaml index a108029ecfab..acd2f3faa6b9 100644 --- a/Documentation/devicetree/bindings/display/panel/abt,y030xx067a.yaml +++ b/Documentation/devicetree/bindings/display/panel/abt,y030xx067a.yaml @@ -6,15 +6,12 @@ $schema: http://devicetree.org/meta-schemas/core.yaml# title: Asia Better Technology 3.0" (320x480 pixels) 24-bit IPS LCD panel -description: | - The panel must obey the rules for a SPI slave device as specified in - spi/spi-controller.yaml - maintainers: - Paul Cercueil <paul@crapouillou.net> allOf: - $ref: panel-common.yaml# + - $ref: /schemas/spi/spi-peripheral-props.yaml# properties: compatible: diff --git a/Documentation/devicetree/bindings/display/panel/ilitek,ili9322.yaml b/Documentation/devicetree/bindings/display/panel/ilitek,ili9322.yaml index e89c1ea62ffa..7d221ef35443 100644 --- a/Documentation/devicetree/bindings/display/panel/ilitek,ili9322.yaml +++ b/Documentation/devicetree/bindings/display/panel/ilitek,ili9322.yaml @@ -15,11 +15,9 @@ description: | 960 TFT source driver pins and 240 TFT gate driver pins, VCOM, VCOML and VCOMH outputs. - The panel must obey the rules for a SPI slave device as specified in - spi/spi-controller.yaml - allOf: - $ref: panel-common.yaml# + - $ref: /schemas/spi/spi-peripheral-props.yaml# properties: compatible: diff --git a/Documentation/devicetree/bindings/display/panel/innolux,ej030na.yaml b/Documentation/devicetree/bindings/display/panel/innolux,ej030na.yaml index cda36c04e85c..72788e3e6c59 100644 --- a/Documentation/devicetree/bindings/display/panel/innolux,ej030na.yaml +++ b/Documentation/devicetree/bindings/display/panel/innolux,ej030na.yaml @@ -6,15 +6,12 @@ $schema: http://devicetree.org/meta-schemas/core.yaml# title: Innolux EJ030NA 3.0" (320x480 pixels) 24-bit TFT LCD panel -description: | - The panel must obey the rules for a SPI slave device as specified in - spi/spi-controller.yaml - maintainers: - Paul Cercueil <paul@crapouillou.net> allOf: - $ref: panel-common.yaml# + - $ref: /schemas/spi/spi-peripheral-props.yaml# properties: compatible: diff --git a/Documentation/devicetree/bindings/display/panel/jdi,lt070me05000.yaml b/Documentation/devicetree/bindings/display/panel/jdi,lt070me05000.yaml index 4f92365e888a..63c82a4378ff 100644 --- a/Documentation/devicetree/bindings/display/panel/jdi,lt070me05000.yaml +++ b/Documentation/devicetree/bindings/display/panel/jdi,lt070me05000.yaml @@ -35,6 +35,8 @@ properties: phandle of the gpio for power ic line Power IC supply enable, High active + port: true + required: - compatible - reg diff --git a/Documentation/devicetree/bindings/display/panel/kingdisplay,kd035g6-54nt.yaml b/Documentation/devicetree/bindings/display/panel/kingdisplay,kd035g6-54nt.yaml index c45c92a3d41f..2a2756d19681 100644 --- a/Documentation/devicetree/bindings/display/panel/kingdisplay,kd035g6-54nt.yaml +++ b/Documentation/devicetree/bindings/display/panel/kingdisplay,kd035g6-54nt.yaml @@ -6,15 +6,12 @@ $schema: http://devicetree.org/meta-schemas/core.yaml# title: King Display KD035G6-54NT 3.5" (320x240 pixels) 24-bit TFT LCD panel -description: | - The panel must obey the rules for a SPI slave device as specified in - spi/spi-controller.yaml - maintainers: - Paul Cercueil <paul@crapouillou.net> allOf: - $ref: panel-common.yaml# + - $ref: /schemas/spi/spi-peripheral-props.yaml# properties: compatible: diff --git a/Documentation/devicetree/bindings/display/panel/lgphilips,lb035q02.yaml b/Documentation/devicetree/bindings/display/panel/lgphilips,lb035q02.yaml index 830e335ddb53..5e4e0e552c2f 100644 --- a/Documentation/devicetree/bindings/display/panel/lgphilips,lb035q02.yaml +++ b/Documentation/devicetree/bindings/display/panel/lgphilips,lb035q02.yaml @@ -6,15 +6,12 @@ $schema: http://devicetree.org/meta-schemas/core.yaml# title: LG.Philips LB035Q02 Panel -description: | - The panel must obey the rules for a SPI slave device as specified in - spi/spi-controller.yaml - maintainers: - Tomi Valkeinen <tomi.valkeinen@ti.com> allOf: - $ref: panel-common.yaml# + - $ref: /schemas/spi/spi-peripheral-props.yaml# properties: compatible: diff --git a/Documentation/devicetree/bindings/display/panel/novatek,nt36672a.yaml b/Documentation/devicetree/bindings/display/panel/novatek,nt36672a.yaml index ef4c0a24512d..563766d283f6 100644 --- a/Documentation/devicetree/bindings/display/panel/novatek,nt36672a.yaml +++ b/Documentation/devicetree/bindings/display/panel/novatek,nt36672a.yaml @@ -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>; diff --git a/Documentation/devicetree/bindings/display/panel/panel-simple.yaml b/Documentation/devicetree/bindings/display/panel/panel-simple.yaml index f3c9395d23b6..62f5f050c1bc 100644 --- a/Documentation/devicetree/bindings/display/panel/panel-simple.yaml +++ b/Documentation/devicetree/bindings/display/panel/panel-simple.yaml @@ -290,6 +290,8 @@ properties: - starry,kr070pe2t # Starry 12.2" (1920x1200 pixels) TFT LCD panel - starry,kr122ea0sra + # Team Source Display Technology TST043015CMHX 4.3" WQVGA TFT LCD panel + - team-source-display,tst043015cmhx # Tianma Micro-electronics TM070JDHG30 7.0" WXGA TFT LCD panel - tianma,tm070jdhg30 # Tianma Micro-electronics TM070JVHG33 7.0" WXGA TFT LCD panel diff --git a/Documentation/devicetree/bindings/display/panel/samsung,ld9040.yaml b/Documentation/devicetree/bindings/display/panel/samsung,ld9040.yaml index 060ee27a4749..d525165d6d63 100644 --- a/Documentation/devicetree/bindings/display/panel/samsung,ld9040.yaml +++ b/Documentation/devicetree/bindings/display/panel/samsung,ld9040.yaml @@ -6,15 +6,12 @@ $schema: http://devicetree.org/meta-schemas/core.yaml# title: Samsung LD9040 AMOLED LCD parallel RGB panel with SPI control bus -description: | - The panel must obey the rules for a SPI slave device as specified in - spi/spi-controller.yaml - maintainers: - Andrzej Hajda <a.hajda@samsung.com> allOf: - $ref: panel-common.yaml# + - $ref: /schemas/spi/spi-peripheral-props.yaml# properties: compatible: @@ -63,8 +60,6 @@ examples: lcd@0 { compatible = "samsung,ld9040"; - #address-cells = <1>; - #size-cells = <0>; reg = <0>; vdd3-supply = <&ldo7_reg>; diff --git a/Documentation/devicetree/bindings/display/panel/samsung,s6e63m0.yaml b/Documentation/devicetree/bindings/display/panel/samsung,s6e63m0.yaml index ea58df49263a..940f7f88526f 100644 --- a/Documentation/devicetree/bindings/display/panel/samsung,s6e63m0.yaml +++ b/Documentation/devicetree/bindings/display/panel/samsung,s6e63m0.yaml @@ -12,6 +12,7 @@ maintainers: allOf: - $ref: panel-common.yaml# - $ref: /schemas/leds/backlight/common.yaml# + - $ref: /schemas/spi/spi-peripheral-props.yaml# properties: compatible: diff --git a/Documentation/devicetree/bindings/display/panel/sitronix,st7789v.yaml b/Documentation/devicetree/bindings/display/panel/sitronix,st7789v.yaml index fa46d151e7b3..9e1d707c2ace 100644 --- a/Documentation/devicetree/bindings/display/panel/sitronix,st7789v.yaml +++ b/Documentation/devicetree/bindings/display/panel/sitronix,st7789v.yaml @@ -6,15 +6,12 @@ $schema: http://devicetree.org/meta-schemas/core.yaml# title: Sitronix ST7789V RGB panel with SPI control bus -description: | - The panel must obey the rules for a SPI slave device as specified in - spi/spi-controller.yaml - maintainers: - Maxime Ripard <mripard@kernel.org> allOf: - $ref: panel-common.yaml# + - $ref: /schemas/spi/spi-peripheral-props.yaml# properties: compatible: diff --git a/Documentation/devicetree/bindings/display/panel/sony,acx565akm.yaml b/Documentation/devicetree/bindings/display/panel/sony,acx565akm.yaml index 95d053c548ab..98abdf4ddeac 100644 --- a/Documentation/devicetree/bindings/display/panel/sony,acx565akm.yaml +++ b/Documentation/devicetree/bindings/display/panel/sony,acx565akm.yaml @@ -6,15 +6,12 @@ $schema: http://devicetree.org/meta-schemas/core.yaml# title: Sony ACX565AKM SDI Panel -description: | - The panel must obey the rules for a SPI slave device as specified in - spi/spi-controller.yaml - maintainers: - Tomi Valkeinen <tomi.valkeinen@ti.com> allOf: - $ref: panel-common.yaml# + - $ref: /schemas/spi/spi-peripheral-props.yaml# properties: compatible: diff --git a/Documentation/devicetree/bindings/display/panel/tpo,td.yaml b/Documentation/devicetree/bindings/display/panel/tpo,td.yaml index 4aa605613445..f902a9d74141 100644 --- a/Documentation/devicetree/bindings/display/panel/tpo,td.yaml +++ b/Documentation/devicetree/bindings/display/panel/tpo,td.yaml @@ -6,16 +6,13 @@ $schema: http://devicetree.org/meta-schemas/core.yaml# title: Toppoly TD Panels -description: | - The panel must obey the rules for a SPI slave device as specified in - spi/spi-controller.yaml - maintainers: - Marek Belisko <marek@goldelico.com> - H. Nikolaus Schaller <hns@goldelico.com> allOf: - $ref: panel-common.yaml# + - $ref: /schemas/spi/spi-peripheral-props.yaml# properties: compatible: diff --git a/Documentation/devicetree/bindings/display/rockchip/rockchip,rk3066-hdmi.yaml b/Documentation/devicetree/bindings/display/rockchip/rockchip,rk3066-hdmi.yaml index 008c144257cb..1a68a940d165 100644 --- a/Documentation/devicetree/bindings/display/rockchip/rockchip,rk3066-hdmi.yaml +++ b/Documentation/devicetree/bindings/display/rockchip/rockchip,rk3066-hdmi.yaml @@ -26,14 +26,6 @@ properties: clock-names: const: hclk - pinctrl-0: - maxItems: 2 - - pinctrl-names: - const: default - description: - Switch the iomux for the HPD/I2C pins to HDMI function. - power-domains: maxItems: 1 diff --git a/Documentation/devicetree/bindings/display/simple-framebuffer.yaml b/Documentation/devicetree/bindings/display/simple-framebuffer.yaml index c2499a7906f5..44a29d813f14 100644 --- a/Documentation/devicetree/bindings/display/simple-framebuffer.yaml +++ b/Documentation/devicetree/bindings/display/simple-framebuffer.yaml @@ -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 diff --git a/Documentation/devicetree/bindings/display/sprd/sprd,display-subsystem.yaml b/Documentation/devicetree/bindings/display/sprd/sprd,display-subsystem.yaml new file mode 100644 index 000000000000..3d107e9434be --- /dev/null +++ b/Documentation/devicetree/bindings/display/sprd/sprd,display-subsystem.yaml @@ -0,0 +1,64 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/display/sprd/sprd,display-subsystem.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Unisoc DRM master device + +maintainers: + - Kevin Tang <kevin.tang@unisoc.com> + +description: | + The Unisoc DRM master device is a virtual device needed to list all + DPU devices or other display interface nodes that comprise the + graphics subsystem. + + Unisoc's display pipeline have several components as below description, + multi display controllers and corresponding physical interfaces. + For different display scenarios, dpu0 and dpu1 maybe binding to different + encoder. + + E.g: + dpu0 and dpu1 both binding to DSI for dual mipi-dsi display; + dpu0 binding to DSI for primary display, and dpu1 binding to DP for external display; + + +-----------------------------------------+ + | | + | +---------+ | + +----+ | +----+ +---------+ |DPHY/CPHY| | +------+ + | +----->+dpu0+--->+MIPI|DSI +--->+Combo +----->+Panel0| + |AXI | | +----+ +---------+ +---------+ | +------+ + | | | ^ | + | | | | | + | | | +-----------+ | + | | | | | + |APB | | +--+-+ +-----------+ +---+ | +------+ + | +----->+dpu1+--->+DisplayPort+--->+PHY+--------->+Panel1| + | | | +----+ +-----------+ +---+ | +------+ + +----+ | | + +-----------------------------------------+ + +properties: + compatible: + const: sprd,display-subsystem + + ports: + $ref: /schemas/types.yaml#/definitions/phandle-array + description: + Should contain a list of phandles pointing to display interface port + of DPU devices. + +required: + - compatible + - ports + +additionalProperties: false + +examples: + - | + display-subsystem { + compatible = "sprd,display-subsystem"; + ports = <&dpu_out>; + }; + diff --git a/Documentation/devicetree/bindings/display/sprd/sprd,sharkl3-dpu.yaml b/Documentation/devicetree/bindings/display/sprd/sprd,sharkl3-dpu.yaml new file mode 100644 index 000000000000..4ebea60b8c5b --- /dev/null +++ b/Documentation/devicetree/bindings/display/sprd/sprd,sharkl3-dpu.yaml @@ -0,0 +1,77 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/display/sprd/sprd,sharkl3-dpu.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Unisoc Sharkl3 Display Processor Unit (DPU) + +maintainers: + - Kevin Tang <kevin.tang@unisoc.com> + +description: | + DPU (Display Processor Unit) is the Display Controller for the Unisoc SoCs + which transfers the image data from a video memory buffer to an internal + LCD interface. + +properties: + compatible: + const: sprd,sharkl3-dpu + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + clocks: + minItems: 2 + + clock-names: + items: + - const: clk_src_128m + - const: clk_src_384m + + power-domains: + maxItems: 1 + + iommus: + maxItems: 1 + + port: + type: object + description: + A port node with endpoint definitions as defined in + Documentation/devicetree/bindings/media/video-interfaces.txt. + That port should be the output endpoint, usually output to + the associated DSI. + +required: + - compatible + - reg + - interrupts + - clocks + - clock-names + - port + +additionalProperties: false + +examples: + - | + #include <dt-bindings/interrupt-controller/arm-gic.h> + #include <dt-bindings/clock/sprd,sc9860-clk.h> + dpu: dpu@63000000 { + compatible = "sprd,sharkl3-dpu"; + reg = <0x63000000 0x1000>; + interrupts = <GIC_SPI 46 IRQ_TYPE_LEVEL_HIGH>; + clock-names = "clk_src_128m", "clk_src_384m"; + + clocks = <&pll CLK_TWPLL_128M>, + <&pll CLK_TWPLL_384M>; + + dpu_port: port { + dpu_out: endpoint { + remote-endpoint = <&dsi_in>; + }; + }; + }; diff --git a/Documentation/devicetree/bindings/display/sprd/sprd,sharkl3-dsi-host.yaml b/Documentation/devicetree/bindings/display/sprd/sprd,sharkl3-dsi-host.yaml new file mode 100644 index 000000000000..bc5594d18643 --- /dev/null +++ b/Documentation/devicetree/bindings/display/sprd/sprd,sharkl3-dsi-host.yaml @@ -0,0 +1,88 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/display/sprd/sprd,sharkl3-dsi-host.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Unisoc MIPI DSI Controller + +maintainers: + - Kevin Tang <kevin.tang@unisoc.com> + +properties: + compatible: + const: sprd,sharkl3-dsi-host + + reg: + maxItems: 1 + + interrupts: + maxItems: 2 + + clocks: + minItems: 1 + + clock-names: + items: + - const: clk_src_96m + + power-domains: + maxItems: 1 + + ports: + type: object + + properties: + "#address-cells": + const: 1 + + "#size-cells": + const: 0 + + port@0: + type: object + description: + A port node with endpoint definitions as defined in + Documentation/devicetree/bindings/media/video-interfaces.txt. + That port should be the input endpoint, usually coming from + the associated DPU. + + required: + - "#address-cells" + - "#size-cells" + - port@0 + + additionalProperties: false + +required: + - compatible + - reg + - interrupts + - clocks + - clock-names + - ports + +additionalProperties: false + +examples: + - | + #include <dt-bindings/interrupt-controller/arm-gic.h> + #include <dt-bindings/clock/sprd,sc9860-clk.h> + dsi: dsi@63100000 { + compatible = "sprd,sharkl3-dsi-host"; + reg = <0x63100000 0x1000>; + interrupts = <GIC_SPI 48 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 49 IRQ_TYPE_LEVEL_HIGH>; + clock-names = "clk_src_96m"; + clocks = <&pll CLK_TWPLL_96M>; + ports { + #address-cells = <1>; + #size-cells = <0>; + port@0 { + reg = <0>; + dsi_in: endpoint { + remote-endpoint = <&dpu_out>; + }; + }; + }; + }; diff --git a/Documentation/devicetree/bindings/display/st,stm32-dsi.yaml b/Documentation/devicetree/bindings/display/st,stm32-dsi.yaml index ce1ef93cce93..54f67cb51040 100644 --- a/Documentation/devicetree/bindings/display/st,stm32-dsi.yaml +++ b/Documentation/devicetree/bindings/display/st,stm32-dsi.yaml @@ -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: }; ... - diff --git a/Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-host1x.txt b/Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-host1x.txt index 8a6d3e1ee306..e61999ce54e9 100644 --- a/Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-host1x.txt +++ b/Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-host1x.txt @@ -19,6 +19,19 @@ Required properties: See ../reset/reset.txt for details. - reset-names: Must include the following entries: - host1x + - mc + +Optional properties: +- operating-points-v2: See ../bindings/opp/opp.txt for details. + - power-domains: Phandle to HEG or core power domain. + +For each opp entry in 'operating-points-v2' table of host1x and its modules: +- opp-supported-hw: One bitfield indicating: + On Tegra20: SoC process ID mask + On Tegra30+: SoC speedo ID mask + + A bitwise AND is performed against the value and if any bit + matches, the OPP gets enabled. Each host1x client module having to perform DMA through the Memory Controller should have the interconnect endpoints set to the Memory Client and External @@ -45,6 +58,8 @@ of the following host1x client modules: - interconnect-names: Must include name of the interconnect path for each interconnect entry. Consult TRM documentation for information about available memory clients, see MEMORY CONTROLLER section. + - operating-points-v2: See ../bindings/opp/opp.txt for details. + - power-domains: Phandle to MPE power domain. - vi: video input @@ -128,6 +143,8 @@ of the following host1x client modules: - interconnect-names: Must include name of the interconnect path for each interconnect entry. Consult TRM documentation for information about available memory clients, see MEMORY CONTROLLER section. + - operating-points-v2: See ../bindings/opp/opp.txt for details. + - power-domains: Phandle to VENC power domain. - epp: encoder pre-processor @@ -147,6 +164,8 @@ of the following host1x client modules: - interconnect-names: Must include name of the interconnect path for each interconnect entry. Consult TRM documentation for information about available memory clients, see MEMORY CONTROLLER section. + - operating-points-v2: See ../bindings/opp/opp.txt for details. + - power-domains: Phandle to HEG or core power domain. - isp: image signal processor @@ -166,6 +185,7 @@ of the following host1x client modules: - interconnect-names: Must include name of the interconnect path for each interconnect entry. Consult TRM documentation for information about available memory clients, see MEMORY CONTROLLER section. + - power-domains: Phandle to VENC or core power domain. - gr2d: 2D graphics engine @@ -179,12 +199,15 @@ of the following host1x client modules: See ../reset/reset.txt for details. - reset-names: Must include the following entries: - 2d + - mc Optional properties: - interconnects: Must contain entry for the GR2D memory clients. - interconnect-names: Must include name of the interconnect path for each interconnect entry. Consult TRM documentation for information about available memory clients, see MEMORY CONTROLLER section. + - operating-points-v2: See ../bindings/opp/opp.txt for details. + - power-domains: Phandle to HEG or core power domain. - gr3d: 3D graphics engine @@ -203,12 +226,16 @@ of the following host1x client modules: - reset-names: Must include the following entries: - 3d - 3d2 (Only required on SoCs with two 3D clocks) + - mc + - mc2 (Only required on SoCs with two 3D clocks) Optional properties: - interconnects: Must contain entry for the GR3D memory clients. - interconnect-names: Must include name of the interconnect path for each interconnect entry. Consult TRM documentation for information about available memory clients, see MEMORY CONTROLLER section. + - operating-points-v2: See ../bindings/opp/opp.txt for details. + - power-domains: Phandles to 3D or core power domain. - dc: display controller @@ -241,6 +268,8 @@ of the following host1x client modules: - interconnect-names: Must include name of the interconnect path for each interconnect entry. Consult TRM documentation for information about available memory clients, see MEMORY CONTROLLER section. + - operating-points-v2: See ../bindings/opp/opp.txt for details. + - power-domains: Phandle to core power domain. - hdmi: High Definition Multimedia Interface @@ -267,6 +296,7 @@ of the following host1x client modules: - nvidia,hpd-gpio: specifies a GPIO used for hotplug detection - nvidia,edid: supplies a binary EDID blob - nvidia,panel: phandle of a display panel + - operating-points-v2: See ../bindings/opp/opp.txt for details. - tvo: TV encoder output @@ -277,6 +307,10 @@ of the following host1x client modules: - clocks: Must contain one entry, for the module clock. See ../clocks/clock-bindings.txt for details. + Optional properties: + - operating-points-v2: See ../bindings/opp/opp.txt for details. + - power-domains: Phandle to core power domain. + - dsi: display serial interface Required properties: @@ -305,6 +339,7 @@ of the following host1x client modules: - nvidia,panel: phandle of a display panel - nvidia,ganged-mode: contains a phandle to a second DSI controller to gang up with in order to support up to 8 data lanes + - operating-points-v2: See ../bindings/opp/opp.txt for details. - sor: serial output resource @@ -408,6 +443,8 @@ Example: clocks = <&tegra_car TEGRA20_CLK_HOST1X>; resets = <&tegra_car 28>; reset-names = "host1x"; + operating-points-v2 = <&dvfs_opp_table>; + power-domains = <&domain>; #address-cells = <1>; #size-cells = <1>; @@ -421,6 +458,8 @@ Example: clocks = <&tegra_car TEGRA20_CLK_MPE>; resets = <&tegra_car 60>; reset-names = "mpe"; + operating-points-v2 = <&dvfs_opp_table>; + power-domains = <&domain>; }; vi@54080000 { @@ -429,6 +468,7 @@ Example: interrupts = <GIC_SPI 69 IRQ_TYPE_LEVEL_HIGH>; assigned-clocks = <&tegra_car TEGRA210_CLK_VI>; assigned-clock-parents = <&tegra_car TEGRA210_CLK_PLL_C4_OUT0>; + operating-points-v2 = <&dvfs_opp_table>; clocks = <&tegra_car TEGRA210_CLK_VI>; power-domains = <&pd_venc>; @@ -510,6 +550,8 @@ Example: clocks = <&tegra_car TEGRA20_CLK_EPP>; resets = <&tegra_car 19>; reset-names = "epp"; + operating-points-v2 = <&dvfs_opp_table>; + power-domains = <&domain>; }; isp { @@ -528,6 +570,8 @@ Example: clocks = <&tegra_car TEGRA20_CLK_GR2D>; resets = <&tegra_car 21>; reset-names = "2d"; + operating-points-v2 = <&dvfs_opp_table>; + power-domains = <&domain>; }; gr3d { @@ -536,6 +580,8 @@ Example: clocks = <&tegra_car TEGRA20_CLK_GR3D>; resets = <&tegra_car 24>; reset-names = "3d"; + operating-points-v2 = <&dvfs_opp_table>; + power-domains = <&domain>; }; dc@54200000 { @@ -547,6 +593,8 @@ Example: clock-names = "dc", "parent"; resets = <&tegra_car 27>; reset-names = "dc"; + operating-points-v2 = <&dvfs_opp_table>; + power-domains = <&domain>; interconnects = <&mc TEGRA20_MC_DISPLAY0A &emc>, <&mc TEGRA20_MC_DISPLAY0B &emc>, @@ -571,6 +619,8 @@ Example: clock-names = "dc", "parent"; resets = <&tegra_car 26>; reset-names = "dc"; + operating-points-v2 = <&dvfs_opp_table>; + power-domains = <&domain>; interconnects = <&mc TEGRA20_MC_DISPLAY0AB &emc>, <&mc TEGRA20_MC_DISPLAY0BB &emc>, @@ -596,6 +646,7 @@ Example: resets = <&tegra_car 51>; reset-names = "hdmi"; status = "disabled"; + operating-points-v2 = <&dvfs_opp_table>; }; tvo { @@ -604,6 +655,7 @@ Example: interrupts = <0 76 0x04>; clocks = <&tegra_car TEGRA20_CLK_TVO>; status = "disabled"; + operating-points-v2 = <&dvfs_opp_table>; }; dsi { @@ -615,6 +667,7 @@ Example: resets = <&tegra_car 48>; reset-names = "dsi"; status = "disabled"; + operating-points-v2 = <&dvfs_opp_table>; }; }; diff --git a/Documentation/devicetree/bindings/dma/arm,pl330.yaml b/Documentation/devicetree/bindings/dma/arm,pl330.yaml new file mode 100644 index 000000000000..decab185cf4d --- /dev/null +++ b/Documentation/devicetree/bindings/dma/arm,pl330.yaml @@ -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>; + }; +... diff --git a/Documentation/devicetree/bindings/dma/arm-pl08x.yaml b/Documentation/devicetree/bindings/dma/arm-pl08x.yaml index 3bd9eea543ca..9193b18fb75f 100644 --- a/Documentation/devicetree/bindings/dma/arm-pl08x.yaml +++ b/Documentation/devicetree/bindings/dma/arm-pl08x.yaml @@ -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 diff --git a/Documentation/devicetree/bindings/dma/arm-pl330.txt b/Documentation/devicetree/bindings/dma/arm-pl330.txt deleted file mode 100644 index 315e90122afa..000000000000 --- a/Documentation/devicetree/bindings/dma/arm-pl330.txt +++ /dev/null @@ -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"; diff --git a/Documentation/devicetree/bindings/dma/dma-controller.yaml b/Documentation/devicetree/bindings/dma/dma-controller.yaml index 0043b91da95e..6d3727267fa8 100644 --- a/Documentation/devicetree/bindings/dma/dma-controller.yaml +++ b/Documentation/devicetree/bindings/dma/dma-controller.yaml @@ -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>; diff --git a/Documentation/devicetree/bindings/dma/ingenic,dma.yaml b/Documentation/devicetree/bindings/dma/ingenic,dma.yaml index dc059d6fd037..3b0b3b919af8 100644 --- a/Documentation/devicetree/bindings/dma/ingenic,dma.yaml +++ b/Documentation/devicetree/bindings/dma/ingenic,dma.yaml @@ -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: - - - Request type: The DMA request type for transfers to/from the - device on the allocated channel, as defined in the SoC documentation. + to the DMA controller plus the following integer cells: + + - 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. diff --git a/Documentation/devicetree/bindings/dma/renesas,rcar-dmac.yaml b/Documentation/devicetree/bindings/dma/renesas,rcar-dmac.yaml index d8142cbd13d3..7c6badf39921 100644 --- a/Documentation/devicetree/bindings/dma/renesas,rcar-dmac.yaml +++ b/Documentation/devicetree/bindings/dma/renesas,rcar-dmac.yaml @@ -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: diff --git a/Documentation/devicetree/bindings/dma/sifive,fu540-c000-pdma.yaml b/Documentation/devicetree/bindings/dma/sifive,fu540-c000-pdma.yaml index d32a71b975fe..75ad898c59bc 100644 --- a/Documentation/devicetree/bindings/dma/sifive,fu540-c000-pdma.yaml +++ b/Documentation/devicetree/bindings/dma/sifive,fu540-c000-pdma.yaml @@ -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>; }; diff --git a/Documentation/devicetree/bindings/dma/snps,dw-axi-dmac.yaml b/Documentation/devicetree/bindings/dma/snps,dw-axi-dmac.yaml index 79e241498e25..4324a94b26b2 100644 --- a/Documentation/devicetree/bindings/dma/snps,dw-axi-dmac.yaml +++ b/Documentation/devicetree/bindings/dma/snps,dw-axi-dmac.yaml @@ -53,6 +53,9 @@ properties: minimum: 1 maximum: 8 + resets: + maxItems: 1 + snps,dma-masters: description: | Number of AXI masters supported by the hardware. diff --git a/Documentation/devicetree/bindings/dma/ti/k3-bcdma.yaml b/Documentation/devicetree/bindings/dma/ti/k3-bcdma.yaml index df29d59d13a8..08627d91e607 100644 --- a/Documentation/devicetree/bindings/dma/ti/k3-bcdma.yaml +++ b/Documentation/devicetree/bindings/dma/ti/k3-bcdma.yaml @@ -30,6 +30,7 @@ description: | allOf: - $ref: /schemas/dma/dma-controller.yaml# + - $ref: /schemas/arm/keystone/ti,k3-sci-common.yaml# properties: compatible: diff --git a/Documentation/devicetree/bindings/dma/ti/k3-pktdma.yaml b/Documentation/devicetree/bindings/dma/ti/k3-pktdma.yaml index ea19d12a9337..507d16d84ade 100644 --- a/Documentation/devicetree/bindings/dma/ti/k3-pktdma.yaml +++ b/Documentation/devicetree/bindings/dma/ti/k3-pktdma.yaml @@ -25,6 +25,7 @@ description: | allOf: - $ref: /schemas/dma/dma-controller.yaml# + - $ref: /schemas/arm/keystone/ti,k3-sci-common.yaml# properties: compatible: diff --git a/Documentation/devicetree/bindings/eeprom/at24.yaml b/Documentation/devicetree/bindings/eeprom/at24.yaml index 4c5396a9744f..6b61a8cf6137 100644 --- a/Documentation/devicetree/bindings/eeprom/at24.yaml +++ b/Documentation/devicetree/bindings/eeprom/at24.yaml @@ -87,6 +87,10 @@ properties: - items: pattern: cs1024$ - items: + pattern: c1025$ + - items: + pattern: cs1025$ + - items: pattern: c2048$ - items: pattern: cs2048$ @@ -95,18 +99,21 @@ 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 - - const: atmel,24c02 + - enum: + - rohm,br24g01 + - rohm,br24t01 + - const: atmel,24c01 - items: - - const: onnn,cat24c04 - - const: atmel,24c04 + - enum: + - nxp,se97b + - renesas,r1ex24002 + - const: atmel,24c02 - items: - - const: onnn,cat24c05 + - enum: + - onnn,cat24c04 + - onnn,cat24c05 - const: atmel,24c04 - items: - - const: renesas,r1ex24002 - - const: atmel,24c02 - - items: - const: renesas,r1ex24016 - const: atmel,24c16 - items: @@ -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. diff --git a/Documentation/devicetree/bindings/extcon/extcon-usbc-cros-ec.yaml b/Documentation/devicetree/bindings/extcon/extcon-usbc-cros-ec.yaml index 20e1ccfc8630..2d82b44268db 100644 --- a/Documentation/devicetree/bindings/extcon/extcon-usbc-cros-ec.yaml +++ b/Documentation/devicetree/bindings/extcon/extcon-usbc-cros-ec.yaml @@ -8,7 +8,6 @@ title: ChromeOS EC USB Type-C cable and accessories detection maintainers: - Benson Leung <bleung@chromium.org> - - Enric Balletbo i Serra <enric.balletbo@collabora.com> description: | On ChromeOS systems with USB Type C ports, the ChromeOS Embedded Controller is diff --git a/Documentation/devicetree/bindings/firmware/intel,ixp4xx-network-processing-engine.yaml b/Documentation/devicetree/bindings/firmware/intel,ixp4xx-network-processing-engine.yaml index c435c9f369a4..9a785bbaafb7 100644 --- a/Documentation/devicetree/bindings/firmware/intel,ixp4xx-network-processing-engine.yaml +++ b/Documentation/devicetree/bindings/firmware/intel,ixp4xx-network-processing-engine.yaml @@ -37,6 +37,20 @@ properties: should be named with the instance number of the NPE engine used for the crypto engine. + "#address-cells": + const: 1 + + "#size-cells": + const: 0 + +patternProperties: + hss@[0-9]+$: + $ref: /schemas/net/intel,ixp4xx-hss.yaml# + type: object + description: Optional node for the High Speed Serial link (HSS), the + node should be named with the instance number of the NPE engine + used for the HSS. + required: - compatible - reg @@ -45,9 +59,30 @@ additionalProperties: false examples: - | + #include <dt-bindings/gpio/gpio.h> + npe: npe@c8006000 { compatible = "intel,ixp4xx-network-processing-engine"; reg = <0xc8006000 0x1000>, <0xc8007000 0x1000>, <0xc8008000 0x1000>; + #address-cells = <1>; + #size-cells = <0>; + + hss@0 { + compatible = "intel,ixp4xx-hss"; + reg = <0>; + intel,npe-handle = <&npe 0>; + intel,queue-chl-rxtrig = <&qmgr 12>; + intel,queue-chl-txready = <&qmgr 34>; + intel,queue-pkt-rx = <&qmgr 13>; + intel,queue-pkt-tx = <&qmgr 14>, <&qmgr 15>, <&qmgr 16>, <&qmgr 17>; + intel,queue-pkt-rxfree = <&qmgr 18>, <&qmgr 19>, <&qmgr 20>, <&qmgr 21>; + intel,queue-pkt-txdone = <&qmgr 22>; + cts-gpios = <&gpio0 10 GPIO_ACTIVE_LOW>; + rts-gpios = <&gpio0 14 GPIO_ACTIVE_LOW>; + dcd-gpios = <&gpio0 6 GPIO_ACTIVE_LOW>; + dtr-gpios = <&gpio_74 2 GPIO_ACTIVE_LOW>; + clk-internal-gpios = <&gpio_74 0 GPIO_ACTIVE_HIGH>; + }; crypto { compatible = "intel,ixp4xx-crypto"; diff --git a/Documentation/devicetree/bindings/firmware/nvidia,tegra186-bpmp.txt b/Documentation/devicetree/bindings/firmware/nvidia,tegra186-bpmp.txt deleted file mode 100644 index e44a13bc06ed..000000000000 --- a/Documentation/devicetree/bindings/firmware/nvidia,tegra186-bpmp.txt +++ /dev/null @@ -1,107 +0,0 @@ -NVIDIA Tegra Boot and Power Management Processor (BPMP) - -The BPMP is a specific processor in Tegra chip, which is designed for -booting process handling and offloading the power management, clock -management, and reset control tasks from the CPU. The binding document -defines the resources that would be used by the BPMP firmware driver, -which can create the interprocessor communication (IPC) between the CPU -and BPMP. - -Required properties: -- compatible - Array of strings - One of: - - "nvidia,tegra186-bpmp" -- mboxes : The phandle of mailbox controller and the mailbox specifier. -- shmem : List of the phandle of the TX and RX shared memory area that - the IPC between CPU and BPMP is based on. -- #clock-cells : Should be 1. -- #power-domain-cells : Should be 1. -- #reset-cells : Should be 1. - -This node is a mailbox consumer. See the following files for details of -the mailbox subsystem, and the specifiers implemented by the relevant -provider(s): - -- .../mailbox/mailbox.txt -- .../mailbox/nvidia,tegra186-hsp.txt - -This node is a clock, power domain, and reset provider. See the following -files for general documentation of those features, and the specifiers -implemented by this node: - -- .../clock/clock-bindings.txt -- <dt-bindings/clock/tegra186-clock.h> -- ../power/power-domain.yaml -- <dt-bindings/power/tegra186-powergate.h> -- .../reset/reset.txt -- <dt-bindings/reset/tegra186-reset.h> - -The BPMP implements some services which must be represented by separate nodes. -For example, it can provide access to certain I2C controllers, and the I2C -bindings represent each I2C controller as a device tree node. Such nodes should -be nested directly inside the main BPMP node. - -Software can determine whether a child node of the BPMP node represents a device -by checking for a compatible property. Any node with a compatible property -represents a device that can be instantiated. Nodes without a compatible -property may be used to provide configuration information regarding the BPMP -itself, although no such configuration nodes are currently defined by this -binding. - -The BPMP firmware defines no single global name-/numbering-space for such -services. Put another way, the numbering scheme for I2C buses is distinct from -the numbering scheme for any other service the BPMP may provide (e.g. a future -hypothetical SPI bus service). As such, child device nodes will have no reg -property, and the BPMP node will have no #address-cells or #size-cells property. - -The shared memory bindings for BPMP ------------------------------------ - -The shared memory area for the IPC TX and RX between CPU and BPMP are -predefined and work on top of sysram, which is an SRAM inside the chip. - -See ".../sram/sram.txt" for the bindings. - -Example: - -hsp_top0: hsp@3c00000 { - ... - #mbox-cells = <2>; -}; - -sysram@30000000 { - compatible = "nvidia,tegra186-sysram", "mmio-sram"; - reg = <0x0 0x30000000 0x0 0x50000>; - #address-cells = <2>; - #size-cells = <2>; - ranges = <0 0x0 0x0 0x30000000 0x0 0x50000>; - - cpu_bpmp_tx: shmem@4e000 { - compatible = "nvidia,tegra186-bpmp-shmem"; - reg = <0x0 0x4e000 0x0 0x1000>; - label = "cpu-bpmp-tx"; - pool; - }; - - cpu_bpmp_rx: shmem@4f000 { - compatible = "nvidia,tegra186-bpmp-shmem"; - reg = <0x0 0x4f000 0x0 0x1000>; - label = "cpu-bpmp-rx"; - pool; - }; -}; - -bpmp { - compatible = "nvidia,tegra186-bpmp"; - mboxes = <&hsp_top0 TEGRA_HSP_MBOX_TYPE_DB TEGRA_HSP_DB_MASTER_BPMP>; - shmem = <&cpu_bpmp_tx &cpu_bpmp_rx>; - #clock-cells = <1>; - #power-domain-cells = <1>; - #reset-cells = <1>; - - i2c { - compatible = "..."; - ... - }; -}; diff --git a/Documentation/devicetree/bindings/firmware/nvidia,tegra186-bpmp.yaml b/Documentation/devicetree/bindings/firmware/nvidia,tegra186-bpmp.yaml new file mode 100644 index 000000000000..833c07f1685c --- /dev/null +++ b/Documentation/devicetree/bindings/firmware/nvidia,tegra186-bpmp.yaml @@ -0,0 +1,186 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/firmware/nvidia,tegra186-bpmp.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: NVIDIA Tegra Boot and Power Management Processor (BPMP) + +maintainers: + - Thierry Reding <thierry.reding@gmail.com> + - Jon Hunter <jonathanh@nvidia.com> + +description: | + The BPMP is a specific processor in Tegra chip, which is designed for + booting process handling and offloading the power management, clock + management, and reset control tasks from the CPU. The binding document + defines the resources that would be used by the BPMP firmware driver, + which can create the interprocessor communication (IPC) between the + CPU and BPMP. + + This node is a mailbox consumer. See the following files for details + of the mailbox subsystem, and the specifiers implemented by the + relevant provider(s): + + - .../mailbox/mailbox.txt + - .../mailbox/nvidia,tegra186-hsp.yaml + + This node is a clock, power domain, and reset provider. See the + following files for general documentation of those features, and the + specifiers implemented by this node: + + - .../clock/clock-bindings.txt + - <dt-bindings/clock/tegra186-clock.h> + - ../power/power-domain.yaml + - <dt-bindings/power/tegra186-powergate.h> + - .../reset/reset.txt + - <dt-bindings/reset/tegra186-reset.h> + + The BPMP implements some services which must be represented by + separate nodes. For example, it can provide access to certain I2C + controllers, and the I2C bindings represent each I2C controller as a + device tree node. Such nodes should be nested directly inside the main + BPMP node. + + Software can determine whether a child node of the BPMP node + represents a device by checking for a compatible property. Any node + with a compatible property represents a device that can be + instantiated. Nodes without a compatible property may be used to + provide configuration information regarding the BPMP itself, although + no such configuration nodes are currently defined by this binding. + + The BPMP firmware defines no single global name-/numbering-space for + such services. Put another way, the numbering scheme for I2C buses is + distinct from the numbering scheme for any other service the BPMP may + provide (e.g. a future hypothetical SPI bus service). As such, child + device nodes will have no reg property, and the BPMP node will have no + "#address-cells" or "#size-cells" property. + + The shared memory area for the IPC TX and RX between CPU and BPMP are + predefined and work on top of sysram, which is an SRAM inside the + chip. See ".../sram/sram.yaml" for the bindings. + +properties: + compatible: + oneOf: + - items: + - enum: + - nvidia,tegra194-bpmp + - nvidia,tegra234-bpmp + - const: nvidia,tegra186-bpmp + - const: nvidia,tegra186-bpmp + + mboxes: + description: A phandle and channel specifier for the mailbox used to + communicate with the BPMP. + maxItems: 1 + + shmem: + description: List of the phandle to the TX and RX shared memory area + that the IPC between CPU and BPMP is based on. + minItems: 2 + maxItems: 2 + + "#clock-cells": + const: 1 + + "#power-domain-cells": + const: 1 + + "#reset-cells": + const: 1 + + interconnects: + items: + - description: memory read client + - description: memory write client + - description: DMA read client + - description: DMA write client + + interconnect-names: + items: + - const: read + - const: write + - const: dma-mem # dma-read + - const: dma-write + + iommus: + maxItems: 1 + + i2c: + type: object + + thermal: + type: object + +additionalProperties: false + +required: + - compatible + - mboxes + - shmem + - "#clock-cells" + - "#power-domain-cells" + - "#reset-cells" + +examples: + - | + #include <dt-bindings/interrupt-controller/arm-gic.h> + #include <dt-bindings/mailbox/tegra186-hsp.h> + #include <dt-bindings/memory/tegra186-mc.h> + + hsp_top0: hsp@3c00000 { + compatible = "nvidia,tegra186-hsp"; + reg = <0x03c00000 0xa0000>; + interrupts = <GIC_SPI 176 IRQ_TYPE_LEVEL_HIGH>; + interrupt-names = "doorbell"; + #mbox-cells = <2>; + }; + + sram@30000000 { + compatible = "nvidia,tegra186-sysram", "mmio-sram"; + reg = <0x30000000 0x50000>; + #address-cells = <1>; + #size-cells = <1>; + ranges = <0x0 0x30000000 0x50000>; + + cpu_bpmp_tx: sram@4e000 { + reg = <0x4e000 0x1000>; + label = "cpu-bpmp-tx"; + pool; + }; + + cpu_bpmp_rx: sram@4f000 { + reg = <0x4f000 0x1000>; + label = "cpu-bpmp-rx"; + pool; + }; + }; + + bpmp { + compatible = "nvidia,tegra186-bpmp"; + interconnects = <&mc TEGRA186_MEMORY_CLIENT_BPMPR &emc>, + <&mc TEGRA186_MEMORY_CLIENT_BPMPW &emc>, + <&mc TEGRA186_MEMORY_CLIENT_BPMPDMAR &emc>, + <&mc TEGRA186_MEMORY_CLIENT_BPMPDMAW &emc>; + interconnect-names = "read", "write", "dma-mem", "dma-write"; + iommus = <&smmu TEGRA186_SID_BPMP>; + mboxes = <&hsp_top0 TEGRA_HSP_MBOX_TYPE_DB + TEGRA_HSP_DB_MASTER_BPMP>; + shmem = <&cpu_bpmp_tx>, <&cpu_bpmp_rx>; + #clock-cells = <1>; + #power-domain-cells = <1>; + #reset-cells = <1>; + + i2c { + compatible = "nvidia,tegra186-bpmp-i2c"; + nvidia,bpmp-bus-id = <5>; + #address-cells = <1>; + #size-cells = <0>; + }; + + thermal { + compatible = "nvidia,tegra186-bpmp-thermal"; + #thermal-sensor-cells = <1>; + }; + }; diff --git a/Documentation/devicetree/bindings/firmware/qcom,scm.txt b/Documentation/devicetree/bindings/firmware/qcom,scm.txt index d7e3cda8924e..b1cd4ad1889a 100644 --- a/Documentation/devicetree/bindings/firmware/qcom,scm.txt +++ b/Documentation/devicetree/bindings/firmware/qcom,scm.txt @@ -26,9 +26,11 @@ Required properties: * "qcom,scm-sc7280" * "qcom,scm-sdm845" * "qcom,scm-sdx55" + * "qcom,scm-sm6350" * "qcom,scm-sm8150" * "qcom,scm-sm8250" * "qcom,scm-sm8350" + * "qcom,scm-sm8450" and: * "qcom,scm" - clocks: Specifies clocks needed by the SCM interface, if any: diff --git a/Documentation/devicetree/bindings/fuse/nvidia,tegra20-fuse.txt b/Documentation/devicetree/bindings/fuse/nvidia,tegra20-fuse.txt deleted file mode 100644 index b109911669e4..000000000000 --- a/Documentation/devicetree/bindings/fuse/nvidia,tegra20-fuse.txt +++ /dev/null @@ -1,42 +0,0 @@ -NVIDIA Tegra20/Tegra30/Tegr114/Tegra124 fuse block. - -Required properties: -- compatible : For Tegra20, must contain "nvidia,tegra20-efuse". For Tegra30, - must contain "nvidia,tegra30-efuse". For Tegra114, must contain - "nvidia,tegra114-efuse". For Tegra124, must contain "nvidia,tegra124-efuse". - For Tegra132 must contain "nvidia,tegra132-efuse", "nvidia,tegra124-efuse". - For Tegra210 must contain "nvidia,tegra210-efuse". For Tegra186 must contain - "nvidia,tegra186-efuse". For Tegra194 must contain "nvidia,tegra194-efuse". - For Tegra234 must contain "nvidia,tegra234-efuse". - Details: - nvidia,tegra20-efuse: Tegra20 requires using APB DMA to read the fuse data - due to a hardware bug. Tegra20 also lacks certain information which is - available in later generations such as fab code, lot code, wafer id,.. - nvidia,tegra30-efuse, nvidia,tegra114-efuse and nvidia,tegra124-efuse: - The differences between these SoCs are the size of the efuse array, - the location of the spare (OEM programmable) bits and the location of - the speedo data. -- reg: Should contain 1 entry: the entry gives the physical address and length - of the fuse registers. -- clocks: Must contain an entry for each entry in clock-names. - See ../clocks/clock-bindings.txt for details. -- clock-names: Must include the following entries: - - fuse -- resets: Must contain an entry for each entry in reset-names. - See ../reset/reset.txt for details. -- reset-names: Must include the following entries: - - fuse - -Example: - - fuse@7000f800 { - compatible = "nvidia,tegra20-efuse"; - reg = <0x7000f800 0x400>, - <0x70000000 0x400>; - clocks = <&tegra_car TEGRA20_CLK_FUSE>; - clock-names = "fuse"; - resets = <&tegra_car 39>; - reset-names = "fuse"; - }; - - diff --git a/Documentation/devicetree/bindings/fuse/nvidia,tegra20-fuse.yaml b/Documentation/devicetree/bindings/fuse/nvidia,tegra20-fuse.yaml new file mode 100644 index 000000000000..481901269872 --- /dev/null +++ b/Documentation/devicetree/bindings/fuse/nvidia,tegra20-fuse.yaml @@ -0,0 +1,89 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/fuse/nvidia,tegra20-fuse.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: NVIDIA Tegra FUSE block + +maintainers: + - Thierry Reding <thierry.reding@gmail.com> + - Jon Hunter <jonathanh@nvidia.com> + +properties: + compatible: + oneOf: + - enum: + - nvidia,tegra20-efuse + - nvidia,tegra30-efuse + - nvidia,tegra114-efuse + - nvidia,tegra124-efuse + - nvidia,tegra210-efuse + - nvidia,tegra186-efuse + - nvidia,tegra194-efuse + - nvidia,tegra234-efuse + + - items: + - const: nvidia,tegra132-efuse + - const: nvidia,tegra124-efuse + + reg: + maxItems: 1 + + clocks: + maxItems: 1 + + clock-names: + items: + - const: fuse + + resets: + maxItems: 1 + + reset-names: + items: + - const: fuse + + operating-points-v2: + $ref: "/schemas/types.yaml#/definitions/phandle" + + power-domains: + items: + - description: phandle to the core power domain + +additionalProperties: false + +required: + - compatible + - reg + - clocks + - clock-names + +if: + properties: + compatible: + contains: + enum: + - nvidia,tegra20-efuse + - nvidia,tegra30-efuse + - nvidia,tegra114-efuse + - nvidia,tegra124-efuse + - nvidia,tegra132-efuse + - nvidia,tegra210-efuse +then: + required: + - resets + - reset-names + +examples: + - | + #include <dt-bindings/clock/tegra20-car.h> + + fuse@7000f800 { + compatible = "nvidia,tegra20-efuse"; + reg = <0x7000f800 0x400>; + clocks = <&tegra_car TEGRA20_CLK_FUSE>; + clock-names = "fuse"; + resets = <&tegra_car 39>; + reset-names = "fuse"; + }; diff --git a/Documentation/devicetree/bindings/gpio/brcm,brcmstb-gpio.txt b/Documentation/devicetree/bindings/gpio/brcm,brcmstb-gpio.txt deleted file mode 100644 index 5d468ecd1809..000000000000 --- a/Documentation/devicetree/bindings/gpio/brcm,brcmstb-gpio.txt +++ /dev/null @@ -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>; - }; diff --git a/Documentation/devicetree/bindings/gpio/brcm,brcmstb-gpio.yaml b/Documentation/devicetree/bindings/gpio/brcm,brcmstb-gpio.yaml new file mode 100644 index 000000000000..4a896ff7edc5 --- /dev/null +++ b/Documentation/devicetree/bindings/gpio/brcm,brcmstb-gpio.yaml @@ -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>; + }; diff --git a/Documentation/devicetree/bindings/gpio/gpio-samsung.txt b/Documentation/devicetree/bindings/gpio/gpio-samsung.txt deleted file mode 100644 index 5375625e8cd2..000000000000 --- a/Documentation/devicetree/bindings/gpio/gpio-samsung.txt +++ /dev/null @@ -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; - }; diff --git a/Documentation/devicetree/bindings/gpio/gpio-vf610.yaml b/Documentation/devicetree/bindings/gpio/gpio-vf610.yaml index 19738a457a58..e1359391d3a4 100644 --- a/Documentation/devicetree/bindings/gpio/gpio-vf610.yaml +++ b/Documentation/devicetree/bindings/gpio/gpio-vf610.yaml @@ -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 diff --git a/Documentation/devicetree/bindings/gpio/mstar,msc313-gpio.yaml b/Documentation/devicetree/bindings/gpio/mstar,msc313-gpio.yaml index fe1e1c63ffe3..18fe90387b87 100644 --- a/Documentation/devicetree/bindings/gpio/mstar,msc313-gpio.yaml +++ b/Documentation/devicetree/bindings/gpio/mstar,msc313-gpio.yaml @@ -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 diff --git a/Documentation/devicetree/bindings/gpio/nvidia,tegra186-gpio.txt b/Documentation/devicetree/bindings/gpio/nvidia,tegra186-gpio.txt deleted file mode 100644 index adff16c71d21..000000000000 --- a/Documentation/devicetree/bindings/gpio/nvidia,tegra186-gpio.txt +++ /dev/null @@ -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>; -}; diff --git a/Documentation/devicetree/bindings/gpio/nvidia,tegra186-gpio.yaml b/Documentation/devicetree/bindings/gpio/nvidia,tegra186-gpio.yaml new file mode 100644 index 000000000000..4ef06b2ff1ff --- /dev/null +++ b/Documentation/devicetree/bindings/gpio/nvidia,tegra186-gpio.yaml @@ -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>; + }; diff --git a/Documentation/devicetree/bindings/gpio/nvidia,tegra20-gpio.txt b/Documentation/devicetree/bindings/gpio/nvidia,tegra20-gpio.txt deleted file mode 100644 index 023c9526e5f8..000000000000 --- a/Documentation/devicetree/bindings/gpio/nvidia,tegra20-gpio.txt +++ /dev/null @@ -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; -}; diff --git a/Documentation/devicetree/bindings/gpio/nvidia,tegra20-gpio.yaml b/Documentation/devicetree/bindings/gpio/nvidia,tegra20-gpio.yaml new file mode 100644 index 000000000000..94b51749ee76 --- /dev/null +++ b/Documentation/devicetree/bindings/gpio/nvidia,tegra20-gpio.yaml @@ -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; + }; diff --git a/Documentation/devicetree/bindings/gpio/sifive,gpio.yaml b/Documentation/devicetree/bindings/gpio/sifive,gpio.yaml index c2902aac2514..e04349567eeb 100644 --- a/Documentation/devicetree/bindings/gpio/sifive,gpio.yaml +++ b/Documentation/devicetree/bindings/gpio/sifive,gpio.yaml @@ -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; diff --git a/Documentation/devicetree/bindings/gpio/toshiba,gpio-visconti.yaml b/Documentation/devicetree/bindings/gpio/toshiba,gpio-visconti.yaml index 9ad470e01953..b085450b527f 100644 --- a/Documentation/devicetree/bindings/gpio/toshiba,gpio-visconti.yaml +++ b/Documentation/devicetree/bindings/gpio/toshiba,gpio-visconti.yaml @@ -43,7 +43,6 @@ required: - gpio-controller - interrupt-controller - "#interrupt-cells" - - interrupt-parent additionalProperties: false diff --git a/Documentation/devicetree/bindings/gpu/arm,mali-bifrost.yaml b/Documentation/devicetree/bindings/gpu/arm,mali-bifrost.yaml index 6f98dd55fb4c..63a08f3f321d 100644 --- a/Documentation/devicetree/bindings/gpu/arm,mali-bifrost.yaml +++ b/Documentation/devicetree/bindings/gpu/arm,mali-bifrost.yaml @@ -19,6 +19,7 @@ properties: - amlogic,meson-g12a-mali - mediatek,mt8183-mali - realtek,rtd1619-mali + - renesas,r9a07g044-mali - rockchip,px30-mali - rockchip,rk3568-mali - const: arm,mali-bifrost # Mali Bifrost GPU model/revision is fully discoverable @@ -27,19 +28,26 @@ properties: maxItems: 1 interrupts: + minItems: 3 items: - description: Job interrupt - description: MMU interrupt - description: GPU interrupt + - description: Event interrupt interrupt-names: + minItems: 3 items: - const: job - const: mmu - const: gpu + - const: event clocks: - maxItems: 1 + minItems: 1 + maxItems: 3 + + clock-names: true mali-supply: true @@ -52,7 +60,10 @@ properties: maxItems: 3 resets: - maxItems: 2 + minItems: 1 + maxItems: 3 + + reset-names: true "#cooling-cells": const: 2 @@ -98,6 +109,36 @@ allOf: properties: compatible: contains: + const: renesas,r9a07g044-mali + then: + properties: + interrupts: + minItems: 4 + interrupt-names: + minItems: 4 + clocks: + minItems: 3 + clock-names: + items: + - const: gpu + - const: bus + - const: bus_ace + resets: + minItems: 3 + reset-names: + items: + - const: rst + - const: axi_rst + - const: ace_rst + required: + - clock-names + - power-domains + - resets + - reset-names + - if: + properties: + compatible: + contains: const: mediatek,mt8183-mali then: properties: diff --git a/Documentation/devicetree/bindings/gpu/host1x/nvidia,tegra210-nvenc.yaml b/Documentation/devicetree/bindings/gpu/host1x/nvidia,tegra210-nvenc.yaml new file mode 100644 index 000000000000..e63ae1a00818 --- /dev/null +++ b/Documentation/devicetree/bindings/gpu/host1x/nvidia,tegra210-nvenc.yaml @@ -0,0 +1,135 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +%YAML 1.2 +--- +$id: "http://devicetree.org/schemas/gpu/host1x/nvidia,tegra210-nvenc.yaml#" +$schema: "http://devicetree.org/meta-schemas/core.yaml#" + +title: Device tree binding for NVIDIA Tegra NVENC + +description: | + NVENC is the hardware video encoder present on NVIDIA Tegra210 + and newer chips. It is located on the Host1x bus and typically + programmed through Host1x channels. + +maintainers: + - Thierry Reding <treding@gmail.com> + - Mikko Perttunen <mperttunen@nvidia.com> + +properties: + $nodename: + pattern: "^nvenc@[0-9a-f]*$" + + compatible: + enum: + - nvidia,tegra210-nvenc + - nvidia,tegra186-nvenc + - nvidia,tegra194-nvenc + + reg: + maxItems: 1 + + clocks: + maxItems: 1 + + clock-names: + items: + - const: nvenc + + resets: + maxItems: 1 + + reset-names: + items: + - const: nvenc + + power-domains: + maxItems: 1 + + iommus: + maxItems: 1 + + dma-coherent: true + + interconnects: + minItems: 2 + maxItems: 3 + + interconnect-names: + minItems: 2 + maxItems: 3 + + nvidia,host1x-class: + description: | + Host1x class of the engine, used to specify the targeted engine + when programming the engine through Host1x channels or when + configuring engine-specific behavior in Host1x. + default: 0x21 + $ref: /schemas/types.yaml#/definitions/uint32 + +required: + - compatible + - reg + - clocks + - clock-names + - resets + - reset-names + - power-domains + +allOf: + - if: + properties: + compatible: + enum: + - nvidia,tegra210-nvenc + - nvidia,tegra186-nvenc + then: + properties: + interconnects: + items: + - description: DMA read memory client + - description: DMA write memory client + interconnect-names: + items: + - const: dma-mem + - const: write + - if: + properties: + compatible: + enum: + - nvidia,tegra194-nvenc + then: + properties: + interconnects: + items: + - description: DMA read memory client + - description: DMA read 2 memory client + - description: DMA write memory client + interconnect-names: + items: + - const: dma-mem + - const: read-1 + - const: write + +additionalProperties: false + +examples: + - | + #include <dt-bindings/clock/tegra186-clock.h> + #include <dt-bindings/memory/tegra186-mc.h> + #include <dt-bindings/power/tegra186-powergate.h> + #include <dt-bindings/reset/tegra186-reset.h> + + nvenc@154c0000 { + compatible = "nvidia,tegra186-nvenc"; + reg = <0x154c0000 0x40000>; + clocks = <&bpmp TEGRA186_CLK_NVENC>; + clock-names = "nvenc"; + resets = <&bpmp TEGRA186_RESET_NVENC>; + reset-names = "nvenc"; + + power-domains = <&bpmp TEGRA186_POWER_DOMAIN_MPE>; + interconnects = <&mc TEGRA186_MEMORY_CLIENT_NVENCSRD &emc>, + <&mc TEGRA186_MEMORY_CLIENT_NVENCSWR &emc>; + interconnect-names = "dma-mem", "write"; + iommus = <&smmu TEGRA186_SID_NVENC>; + }; diff --git a/Documentation/devicetree/bindings/gpu/host1x/nvidia,tegra210-nvjpg.yaml b/Documentation/devicetree/bindings/gpu/host1x/nvidia,tegra210-nvjpg.yaml new file mode 100644 index 000000000000..8647404d67e4 --- /dev/null +++ b/Documentation/devicetree/bindings/gpu/host1x/nvidia,tegra210-nvjpg.yaml @@ -0,0 +1,94 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +%YAML 1.2 +--- +$id: "http://devicetree.org/schemas/gpu/host1x/nvidia,tegra210-nvjpg.yaml#" +$schema: "http://devicetree.org/meta-schemas/core.yaml#" + +title: Device tree binding for NVIDIA Tegra NVJPG + +description: | + NVJPG is the hardware JPEG decoder and encoder present on NVIDIA Tegra210 + and newer chips. It is located on the Host1x bus and typically programmed + through Host1x channels. + +maintainers: + - Thierry Reding <treding@gmail.com> + - Mikko Perttunen <mperttunen@nvidia.com> + +properties: + $nodename: + pattern: "^nvjpg@[0-9a-f]*$" + + compatible: + enum: + - nvidia,tegra210-nvjpg + - nvidia,tegra186-nvjpg + - nvidia,tegra194-nvjpg + + reg: + maxItems: 1 + + clocks: + maxItems: 1 + + clock-names: + items: + - const: nvjpg + + resets: + maxItems: 1 + + reset-names: + items: + - const: nvjpg + + power-domains: + maxItems: 1 + + iommus: + maxItems: 1 + + dma-coherent: true + + interconnects: + items: + - description: DMA read memory client + - description: DMA write memory client + + interconnect-names: + items: + - const: dma-mem + - const: write + +required: + - compatible + - reg + - clocks + - clock-names + - resets + - reset-names + - power-domains + +additionalProperties: false + +examples: + - | + #include <dt-bindings/clock/tegra186-clock.h> + #include <dt-bindings/memory/tegra186-mc.h> + #include <dt-bindings/power/tegra186-powergate.h> + #include <dt-bindings/reset/tegra186-reset.h> + + nvjpg@15380000 { + compatible = "nvidia,tegra186-nvjpg"; + reg = <0x15380000 0x40000>; + clocks = <&bpmp TEGRA186_CLK_NVJPG>; + clock-names = "nvjpg"; + resets = <&bpmp TEGRA186_RESET_NVJPG>; + reset-names = "nvjpg"; + + power-domains = <&bpmp TEGRA186_POWER_DOMAIN_NVJPG>; + interconnects = <&mc TEGRA186_MEMORY_CLIENT_NVJPGSRD &emc>, + <&mc TEGRA186_MEMORY_CLIENT_NVJPGSWR &emc>; + interconnect-names = "dma-mem", "write"; + iommus = <&smmu TEGRA186_SID_NVJPG>; + }; diff --git a/Documentation/devicetree/bindings/hwmon/ntc-thermistor.yaml b/Documentation/devicetree/bindings/hwmon/ntc-thermistor.yaml index 9e77cee07dbc..3d3b139a91a2 100644 --- a/Documentation/devicetree/bindings/hwmon/ntc-thermistor.yaml +++ b/Documentation/devicetree/bindings/hwmon/ntc-thermistor.yaml @@ -76,6 +76,7 @@ properties: - const: murata,ncp15wl333 - const: murata,ncp03wf104 - const: murata,ncp15xh103 + - const: samsung,1404-001221 # Deprecated "ntp," compatible strings - const: ntc,ncp15wb473 deprecated: true diff --git a/Documentation/devicetree/bindings/hwmon/ti,ina2xx.yaml b/Documentation/devicetree/bindings/hwmon/ti,ina2xx.yaml index 6f0443322a36..47af97bb4ced 100644 --- a/Documentation/devicetree/bindings/hwmon/ti,ina2xx.yaml +++ b/Documentation/devicetree/bindings/hwmon/ti,ina2xx.yaml @@ -26,6 +26,7 @@ properties: - ti,ina226 - ti,ina230 - ti,ina231 + - ti,ina238 reg: maxItems: 1 @@ -35,6 +36,27 @@ properties: Shunt resistor value in micro-Ohm. $ref: /schemas/types.yaml#/definitions/uint32 + ti,shunt-gain: + description: | + Programmable gain divisor for the shunt voltage accuracy and range. This + property only applies to devices that have configurable PGA/ADCRANGE. The + gain value is used configure the gain and to convert the shunt voltage, + current and power register values when reading measurements from the + device. + + For devices that have a configurable PGA (e.g. INA209, INA219, INA220), + the gain value maps directly with the PG bits of the config register. + + For devices that have ADCRANGE configuration (e.g. INA238) a shunt-gain + value of 1 maps to ADCRANGE=1 where no gain divisor is applied to the + shunt voltage, and a value of 4 maps to ADCRANGE=0 such that a wider + voltage range is used. + + The default value is device dependent, and is defined by the reset value + of PGA/ADCRANGE in the respective configuration registers. + $ref: /schemas/types.yaml#/definitions/uint32 + enum: [1, 2, 4, 8] + required: - compatible - reg diff --git a/Documentation/devicetree/bindings/i2c/apple,i2c.yaml b/Documentation/devicetree/bindings/i2c/apple,i2c.yaml index 22fc8483256f..4ac61fec90e2 100644 --- a/Documentation/devicetree/bindings/i2c/apple,i2c.yaml +++ b/Documentation/devicetree/bindings/i2c/apple,i2c.yaml @@ -20,9 +20,11 @@ allOf: properties: compatible: - enum: - - apple,t8103-i2c - - apple,i2c + items: + - enum: + - apple,t8103-i2c + - apple,t6000-i2c + - const: apple,i2c reg: maxItems: 1 @@ -40,6 +42,9 @@ properties: used. This frequency is generated by dividing the reference clock. Allowed values are between ref_clk/(16*4) and ref_clk/(16*255). + power-domains: + maxItems: 1 + required: - compatible - reg @@ -51,7 +56,7 @@ unevaluatedProperties: false examples: - | i2c@35010000 { - compatible = "apple,t8103-i2c"; + compatible = "apple,t8103-i2c", "apple,i2c"; reg = <0x35010000 0x4000>; interrupt-parent = <&aic>; interrupts = <0 627 4>; diff --git a/Documentation/devicetree/bindings/i2c/aspeed,i2c.yaml b/Documentation/devicetree/bindings/i2c/aspeed,i2c.yaml index ea643e6c3ef5..f597f73ccd87 100644 --- a/Documentation/devicetree/bindings/i2c/aspeed,i2c.yaml +++ b/Documentation/devicetree/bindings/i2c/aspeed,i2c.yaml @@ -63,7 +63,6 @@ examples: i2c0: i2c-bus@40 { #address-cells = <1>; #size-cells = <0>; - #interrupt-cells = <1>; compatible = "aspeed,ast2500-i2c-bus"; reg = <0x40 0x40>; clocks = <&syscon ASPEED_CLK_APB>; diff --git a/Documentation/devicetree/bindings/i2c/brcm,bcm2835-i2c.txt b/Documentation/devicetree/bindings/i2c/brcm,bcm2835-i2c.txt deleted file mode 100644 index a8a35df41951..000000000000 --- a/Documentation/devicetree/bindings/i2c/brcm,bcm2835-i2c.txt +++ /dev/null @@ -1,22 +0,0 @@ -Broadcom BCM2835 I2C controller - -Required properties: -- compatible : Should be one of: - "brcm,bcm2711-i2c" - "brcm,bcm2835-i2c" -- reg: Should contain register location and length. -- interrupts: Should contain interrupt. -- clocks : The clock feeding the I2C controller. - -Recommended properties: -- clock-frequency : desired I2C bus clock frequency in Hz. - -Example: - -i2c@7e205000 { - compatible = "brcm,bcm2835-i2c"; - reg = <0x7e205000 0x1000>; - interrupts = <2 21>; - clocks = <&clk_i2c>; - clock-frequency = <100000>; -}; diff --git a/Documentation/devicetree/bindings/i2c/brcm,bcm2835-i2c.yaml b/Documentation/devicetree/bindings/i2c/brcm,bcm2835-i2c.yaml new file mode 100644 index 000000000000..8256490a7af2 --- /dev/null +++ b/Documentation/devicetree/bindings/i2c/brcm,bcm2835-i2c.yaml @@ -0,0 +1,54 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/i2c/brcm,bcm2835-i2c.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Broadcom BCM2835 I2C controller + +maintainers: + - Stephen Warren <swarren@wwwdotorg.org> + +allOf: + - $ref: /schemas/i2c/i2c-controller.yaml# + +properties: + compatible: + oneOf: + - enum: + - brcm,bcm2835-i2c + - items: + - const: brcm,bcm2711-i2c + - const: brcm,bcm2835-i2c + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + clock-names: + maxItems: 1 + + clocks: + maxItems: 1 + + clock-frequency: true + +required: + - compatible + - reg + - interrupts + - clocks + +unevaluatedProperties: false + +examples: + - | + i2c@7e205000 { + compatible = "brcm,bcm2835-i2c"; + reg = <0x7e205000 0x1000>; + interrupts = <2 21>; + clocks = <&clk_i2c>; + clock-frequency = <100000>; + }; diff --git a/Documentation/devicetree/bindings/i2c/google,cros-ec-i2c-tunnel.yaml b/Documentation/devicetree/bindings/i2c/google,cros-ec-i2c-tunnel.yaml index b386e4128a79..6e1c70e9275e 100644 --- a/Documentation/devicetree/bindings/i2c/google,cros-ec-i2c-tunnel.yaml +++ b/Documentation/devicetree/bindings/i2c/google,cros-ec-i2c-tunnel.yaml @@ -10,7 +10,6 @@ title: I2C bus that tunnels through the ChromeOS EC (cros-ec) maintainers: - Doug Anderson <dianders@chromium.org> - Benson Leung <bleung@chromium.org> - - Enric Balletbo i Serra <enric.balletbo@collabora.com> description: | On some ChromeOS board designs we've got a connection to the EC diff --git a/Documentation/devicetree/bindings/i2c/i2c-exynos5.txt b/Documentation/devicetree/bindings/i2c/i2c-exynos5.txt deleted file mode 100644 index 2dbc0b62daa6..000000000000 --- a/Documentation/devicetree/bindings/i2c/i2c-exynos5.txt +++ /dev/null @@ -1,53 +0,0 @@ -* Samsung's High Speed I2C controller - -The Samsung's High Speed I2C controller is used to interface with I2C devices -at various speeds ranging from 100khz to 3.4Mhz. - -Required properties: - - compatible: value should be. - -> "samsung,exynos5-hsi2c", (DEPRECATED) - for i2c compatible with HSI2C available - on Exynos5250 and Exynos5420 SoCs. - -> "samsung,exynos5250-hsi2c", for i2c compatible with HSI2C available - on Exynos5250 and Exynos5420 SoCs. - -> "samsung,exynos5260-hsi2c", for i2c compatible with HSI2C available - on Exynos5260 SoCs. - -> "samsung,exynos7-hsi2c", for i2c compatible with HSI2C available - on Exynos7 SoCs. - - - reg: physical base address of the controller and length of memory mapped - region. - - interrupts: interrupt number to the cpu. - - #address-cells: always 1 (for i2c addresses) - - #size-cells: always 0 - - - Pinctrl: - - pinctrl-0: Pin control group to be used for this controller. - - pinctrl-names: Should contain only one value - "default". - -Optional properties: - - clock-frequency: Desired operating frequency in Hz of the bus. - -> If not specified, the bus operates in fast-speed mode at - at 100khz. - -> If specified, the bus operates in high-speed mode only if the - clock-frequency is >= 1Mhz. - -Example: - -hsi2c@12ca0000 { - compatible = "samsung,exynos5250-hsi2c"; - reg = <0x12ca0000 0x100>; - interrupts = <56>; - clock-frequency = <100000>; - - pinctrl-0 = <&i2c4_bus>; - pinctrl-names = "default"; - - #address-cells = <1>; - #size-cells = <0>; - - s2mps11_pmic@66 { - compatible = "samsung,s2mps11-pmic"; - reg = <0x66>; - }; -}; diff --git a/Documentation/devicetree/bindings/i2c/i2c-exynos5.yaml b/Documentation/devicetree/bindings/i2c/i2c-exynos5.yaml new file mode 100644 index 000000000000..19874e8b73b9 --- /dev/null +++ b/Documentation/devicetree/bindings/i2c/i2c-exynos5.yaml @@ -0,0 +1,133 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/i2c/i2c-exynos5.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Samsung's High Speed I2C controller + +maintainers: + - Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com> + +description: | + The Samsung's High Speed I2C controller is used to interface with I2C devices + at various speeds ranging from 100kHz to 3.4MHz. + + In case the HSI2C controller is encapsulated within USI block (it's the case + e.g. for Exynos850 and Exynos Auto V9 SoCs), it might be also necessary to + define USI node in device tree file, choosing "i2c" configuration. Please see + Documentation/devicetree/bindings/soc/samsung/exynos-usi.yaml for details. + +properties: + compatible: + oneOf: + - enum: + - samsung,exynos5250-hsi2c # Exynos5250 and Exynos5420 + - samsung,exynos5260-hsi2c # Exynos5260 + - samsung,exynos7-hsi2c # Exynos7 + - samsung,exynosautov9-hsi2c # ExynosAutoV9 and Exynos850 + - const: samsung,exynos5-hsi2c # Exynos5250 and Exynos5420 + deprecated: true + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + clock-frequency: + default: 100000 + description: + Desired operating frequency in Hz of the bus. + + If not specified, the bus operates in fast-speed mode at 100kHz. + + If specified, the bus operates in high-speed mode only if the + clock-frequency is >= 1MHz. + + clocks: + minItems: 1 + items: + - description: I2C operating clock + - description: Bus clock (APB) + + clock-names: + minItems: 1 + items: + - const: hsi2c + - const: hsi2c_pclk + +required: + - compatible + - reg + - interrupts + - clocks + +allOf: + - $ref: /schemas/i2c/i2c-controller.yaml# + - if: + properties: + compatible: + contains: + enum: + - samsung,exynosautov9-hsi2c + + then: + properties: + clocks: + minItems: 2 + + clock-names: + minItems: 2 + + required: + - clock-names + + else: + properties: + clocks: + maxItems: 1 + +unevaluatedProperties: false + +examples: + - | + #include <dt-bindings/clock/exynos5420.h> + #include <dt-bindings/interrupt-controller/arm-gic.h> + #include <dt-bindings/interrupt-controller/irq.h> + + hsi2c_8: i2c@12e00000 { + compatible = "samsung,exynos5250-hsi2c"; + reg = <0x12e00000 0x1000>; + interrupts = <GIC_SPI 87 IRQ_TYPE_LEVEL_HIGH>; + #address-cells = <1>; + #size-cells = <0>; + clock-frequency = <100000>; + clocks = <&clock CLK_USI4>; + clock-names = "hsi2c"; + + pmic@66 { + /* compatible = "samsung,s2mps11-pmic"; */ + reg = <0x66>; + }; + }; + + - | + #include <dt-bindings/clock/exynos850.h> + #include <dt-bindings/interrupt-controller/arm-gic.h> + + hsi2c_2: i2c@138c0000 { + compatible = "samsung,exynosautov9-hsi2c"; + reg = <0x138c0000 0xc0>; + interrupts = <GIC_SPI 195 IRQ_TYPE_LEVEL_HIGH>; + #address-cells = <1>; + #size-cells = <0>; + clocks = <&cmu_peri CLK_GOUT_HSI2C2_IPCLK>, + <&cmu_peri CLK_GOUT_HSI2C2_PCLK>; + clock-names = "hsi2c", "hsi2c_pclk"; + + pmic@66 { + /* compatible = "samsung,s2mps11-pmic"; */ + reg = <0x66>; + }; + }; diff --git a/Documentation/devicetree/bindings/i2c/i2c-gate.yaml b/Documentation/devicetree/bindings/i2c/i2c-gate.yaml index 66472f12a7e2..bd67b0766599 100644 --- a/Documentation/devicetree/bindings/i2c/i2c-gate.yaml +++ b/Documentation/devicetree/bindings/i2c/i2c-gate.yaml @@ -31,7 +31,7 @@ examples: #address-cells = <1>; #size-cells = <0>; ak8975@c { - compatible = "ak,ak8975"; + compatible = "asahi-kasei,ak8975"; reg = <0x0c>; }; }; diff --git a/Documentation/devicetree/bindings/i2c/i2c-imx-lpi2c.yaml b/Documentation/devicetree/bindings/i2c/i2c-imx-lpi2c.yaml index 29b9447f3b84..529bea56d324 100644 --- a/Documentation/devicetree/bindings/i2c/i2c-imx-lpi2c.yaml +++ b/Documentation/devicetree/bindings/i2c/i2c-imx-lpi2c.yaml @@ -17,9 +17,12 @@ properties: oneOf: - enum: - fsl,imx7ulp-lpi2c - - fsl,imx8qm-lpi2c - items: - - const: fsl,imx8qxp-lpi2c + - enum: + - fsl,imx8qxp-lpi2c + - fsl,imx8dxl-lpi2c + - fsl,imx8qm-lpi2c + - fsl,imx8ulp-lpi2c - const: fsl,imx7ulp-lpi2c reg: diff --git a/Documentation/devicetree/bindings/i2c/i2c-mux-gpio.txt b/Documentation/devicetree/bindings/i2c/i2c-mux-gpio.txt deleted file mode 100644 index d4cf10582a26..000000000000 --- a/Documentation/devicetree/bindings/i2c/i2c-mux-gpio.txt +++ /dev/null @@ -1,80 +0,0 @@ -GPIO-based I2C Bus Mux - -This binding describes an I2C bus multiplexer that uses GPIOs to -route the I2C signals. - - +-----+ +-----+ - | dev | | dev | - +------------+ +-----+ +-----+ - | SoC | | | - | | /--------+--------+ - | +------+ | +------+ child bus A, on GPIO value set to 0 - | | I2C |-|--| Mux | - | +------+ | +--+---+ child bus B, on GPIO value set to 1 - | | | \----------+--------+--------+ - | +------+ | | | | | - | | GPIO |-|-----+ +-----+ +-----+ +-----+ - | +------+ | | dev | | dev | | dev | - +------------+ +-----+ +-----+ +-----+ - -Required properties: -- compatible: i2c-mux-gpio -- i2c-parent: The phandle of the I2C bus that this multiplexer's master-side - port is connected to. -- mux-gpios: list of gpios used to control the muxer -* Standard I2C mux properties. See i2c-mux.yaml in this directory. -* I2C child bus nodes. See i2c-mux.yaml in this directory. - -Optional properties: -- idle-state: value to set the muxer to when idle. When no value is - given, it defaults to the last value used. - -For each i2c child node, an I2C child bus will be created. They will -be numbered based on their order in the device tree. - -Whenever an access is made to a device on a child bus, the value set -in the relevant node's reg property will be output using the list of -GPIOs, the first in the list holding the least-significant value. - -If an idle state is defined, using the idle-state (optional) property, -whenever an access is not being made to a device on a child bus, the -GPIOs will be set according to the idle value. - -If an idle state is not defined, the most recently used value will be -left programmed into hardware whenever no access is being made to a -device on a child bus. - -Example: - i2cmux { - compatible = "i2c-mux-gpio"; - #address-cells = <1>; - #size-cells = <0>; - mux-gpios = <&gpio1 22 0 &gpio1 23 0>; - i2c-parent = <&i2c1>; - - i2c@1 { - reg = <1>; - #address-cells = <1>; - #size-cells = <0>; - - ssd1307: oled@3c { - compatible = "solomon,ssd1307fb-i2c"; - reg = <0x3c>; - pwms = <&pwm 4 3000>; - reset-gpios = <&gpio2 7 1>; - }; - }; - - i2c@3 { - reg = <3>; - #address-cells = <1>; - #size-cells = <0>; - - pca9555: pca9555@20 { - compatible = "nxp,pca9555"; - gpio-controller; - #gpio-cells = <2>; - reg = <0x20>; - }; - }; - }; diff --git a/Documentation/devicetree/bindings/i2c/i2c-mux-gpio.yaml b/Documentation/devicetree/bindings/i2c/i2c-mux-gpio.yaml new file mode 100644 index 000000000000..6e0a5686af04 --- /dev/null +++ b/Documentation/devicetree/bindings/i2c/i2c-mux-gpio.yaml @@ -0,0 +1,104 @@ +# SPDX-License-Identifier: GPL-2.0-only +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/i2c/i2c-mux-gpio.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: GPIO-based I2C Bus Mux + +maintainers: + - Wolfram Sang <wsa@kernel.org> + +description: | + This binding describes an I2C bus multiplexer that uses GPIOs to route the I2C signals. + + +-----+ +-----+ + | dev | | dev | + +------------+ +-----+ +-----+ + | SoC | | | + | | /--------+--------+ + | +------+ | +------+ child bus A, on GPIO value set to 0 + | | I2C |-|--| Mux | + | +------+ | +--+---+ child bus B, on GPIO value set to 1 + | | | \----------+--------+--------+ + | +------+ | | | | | + | | GPIO |-|-----+ +-----+ +-----+ +-----+ + | +------+ | | dev | | dev | | dev | + +------------+ +-----+ +-----+ +-----+ + + For each I2C child node, an I2C child bus will be created. They will be numbered based on their + order in the device tree. + + Whenever an access is made to a device on a child bus, the value set in the relevant node's reg + property will be output using the list of GPIOs, the first in the list holding the least- + significant value. + + If an idle state is defined, using the idle-state (optional) property, whenever an access is not + being made to a device on a child bus, the GPIOs will be set according to the idle value. + + If an idle state is not defined, the most recently used value will be left programmed into + hardware whenever no access is being made to a device on a child bus. + +properties: + compatible: + const: i2c-mux-gpio + + i2c-parent: + description: phandle of the I2C bus that this multiplexer's master-side port is connected to + $ref: "/schemas/types.yaml#/definitions/phandle" + + mux-gpios: + description: list of GPIOs used to control the muxer + minItems: 1 + maxItems: 4 # Should be enough + + idle-state: + description: Value to set the muxer to when idle. When no value is given, it defaults to the + last value used. + $ref: "/schemas/types.yaml#/definitions/uint32" + +allOf: + - $ref: i2c-mux.yaml + +unevaluatedProperties: false + +required: + - compatible + - i2c-parent + - mux-gpios + +examples: + - | + i2cmux { + compatible = "i2c-mux-gpio"; + #address-cells = <1>; + #size-cells = <0>; + mux-gpios = <&gpio1 22 0>, <&gpio1 23 0>; + i2c-parent = <&i2c1>; + + i2c@1 { + reg = <1>; + #address-cells = <1>; + #size-cells = <0>; + + ssd1307: oled@3c { + compatible = "solomon,ssd1307fb-i2c"; + reg = <0x3c>; + pwms = <&pwm 4 3000>; + reset-gpios = <&gpio2 7 1>; + }; + }; + + i2c@3 { + reg = <3>; + #address-cells = <1>; + #size-cells = <0>; + + pca9555: pca9555@20 { + compatible = "nxp,pca9555"; + gpio-controller; + #gpio-cells = <2>; + reg = <0x20>; + }; + }; + }; diff --git a/Documentation/devicetree/bindings/i2c/i2c-mux-pinctrl.txt b/Documentation/devicetree/bindings/i2c/i2c-mux-pinctrl.txt deleted file mode 100644 index 997a287ed3f6..000000000000 --- a/Documentation/devicetree/bindings/i2c/i2c-mux-pinctrl.txt +++ /dev/null @@ -1,93 +0,0 @@ -Pinctrl-based I2C Bus Mux - -This binding describes an I2C bus multiplexer that uses pin multiplexing to -route the I2C signals, and represents the pin multiplexing configuration -using the pinctrl device tree bindings. - - +-----+ +-----+ - | dev | | dev | - +------------------------+ +-----+ +-----+ - | SoC | | | - | /----|------+--------+ - | +---+ +------+ | child bus A, on first set of pins - | |I2C|---|Pinmux| | - | +---+ +------+ | child bus B, on second set of pins - | \----|------+--------+--------+ - | | | | | - +------------------------+ +-----+ +-----+ +-----+ - | dev | | dev | | dev | - +-----+ +-----+ +-----+ - -Required properties: -- compatible: i2c-mux-pinctrl -- i2c-parent: The phandle of the I2C bus that this multiplexer's master-side - port is connected to. - -Also required are: - -* Standard pinctrl properties that specify the pin mux state for each child - bus. See ../pinctrl/pinctrl-bindings.txt. - -* Standard I2C mux properties. See i2c-mux.yaml in this directory. - -* I2C child bus nodes. See i2c-mux.yaml in this directory. - -For each named state defined in the pinctrl-names property, an I2C child bus -will be created. I2C child bus numbers are assigned based on the index into -the pinctrl-names property. - -The only exception is that no bus will be created for a state named "idle". If -such a state is defined, it must be the last entry in pinctrl-names. For -example: - - pinctrl-names = "ddc", "pta", "idle" -> ddc = bus 0, pta = bus 1 - pinctrl-names = "ddc", "idle", "pta" -> Invalid ("idle" not last) - pinctrl-names = "idle", "ddc", "pta" -> Invalid ("idle" not last) - -Whenever an access is made to a device on a child bus, the relevant pinctrl -state will be programmed into hardware. - -If an idle state is defined, whenever an access is not being made to a device -on a child bus, the idle pinctrl state will be programmed into hardware. - -If an idle state is not defined, the most recently used pinctrl state will be -left programmed into hardware whenever no access is being made of a device on -a child bus. - -Example: - - i2cmux { - compatible = "i2c-mux-pinctrl"; - #address-cells = <1>; - #size-cells = <0>; - - i2c-parent = <&i2c1>; - - pinctrl-names = "ddc", "pta", "idle"; - pinctrl-0 = <&state_i2cmux_ddc>; - pinctrl-1 = <&state_i2cmux_pta>; - pinctrl-2 = <&state_i2cmux_idle>; - - i2c@0 { - reg = <0>; - #address-cells = <1>; - #size-cells = <0>; - - eeprom { - compatible = "eeprom"; - reg = <0x50>; - }; - }; - - i2c@1 { - reg = <1>; - #address-cells = <1>; - #size-cells = <0>; - - eeprom { - compatible = "eeprom"; - reg = <0x50>; - }; - }; - }; - diff --git a/Documentation/devicetree/bindings/i2c/i2c-mux-pinctrl.yaml b/Documentation/devicetree/bindings/i2c/i2c-mux-pinctrl.yaml new file mode 100644 index 000000000000..2e3d555eb96c --- /dev/null +++ b/Documentation/devicetree/bindings/i2c/i2c-mux-pinctrl.yaml @@ -0,0 +1,103 @@ +# SPDX-License-Identifier: GPL-2.0-only +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/i2c/i2c-mux-pinctrl.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Pinctrl-based I2C Bus Mux + +maintainers: + - Wolfram Sang <wsa@kernel.org> + +description: | + This binding describes an I2C bus multiplexer that uses pin multiplexing to route the I2C + signals, and represents the pin multiplexing configuration using the pinctrl device tree + bindings. + + +-----+ +-----+ + | dev | | dev | + +------------------------+ +-----+ +-----+ + | SoC | | | + | /----|------+--------+ + | +---+ +------+ | child bus A, on first set of pins + | |I2C|---|Pinmux| | + | +---+ +------+ | child bus B, on second set of pins + | \----|------+--------+--------+ + | | | | | + +------------------------+ +-----+ +-----+ +-----+ + | dev | | dev | | dev | + +-----+ +-----+ +-----+ + + For each named state defined in the pinctrl-names property, an I2C child bus will be created. + I2C child bus numbers are assigned based on the index into the pinctrl-names property. + + The only exception is that no bus will be created for a state named "idle". If such a state is + defined, it must be the last entry in pinctrl-names. For example: + + pinctrl-names = "ddc", "pta", "idle" -> ddc = bus 0, pta = bus 1 + pinctrl-names = "ddc", "idle", "pta" -> Invalid ("idle" not last) + pinctrl-names = "idle", "ddc", "pta" -> Invalid ("idle" not last) + + Whenever an access is made to a device on a child bus, the relevant pinctrl state will be + programmed into hardware. + + If an idle state is defined, whenever an access is not being made to a device on a child bus, + the idle pinctrl state will be programmed into hardware. + + If an idle state is not defined, the most recently used pinctrl state will be left programmed + into hardware whenever no access is being made of a device on a child bus. + +properties: + compatible: + const: i2c-mux-pinctrl + + i2c-parent: + $ref: /schemas/types.yaml#/definitions/phandle + description: The phandle of the I2C bus that this multiplexer's master-side port is connected + to. + +allOf: + - $ref: i2c-mux.yaml + +unevaluatedProperties: false + +required: + - compatible + - i2c-parent + +examples: + - | + i2cmux { + compatible = "i2c-mux-pinctrl"; + #address-cells = <1>; + #size-cells = <0>; + + i2c-parent = <&i2c1>; + + pinctrl-names = "ddc", "pta", "idle"; + pinctrl-0 = <&state_i2cmux_ddc>; + pinctrl-1 = <&state_i2cmux_pta>; + pinctrl-2 = <&state_i2cmux_idle>; + + i2c@0 { + reg = <0>; + #address-cells = <1>; + #size-cells = <0>; + + eeprom@50 { + compatible = "atmel,24c02"; + reg = <0x50>; + }; + }; + + i2c@1 { + reg = <1>; + #address-cells = <1>; + #size-cells = <0>; + + eeprom@50 { + compatible = "atmel,24c02"; + reg = <0x50>; + }; + }; + }; diff --git a/Documentation/devicetree/bindings/i2c/nvidia,tegra186-bpmp-i2c.txt b/Documentation/devicetree/bindings/i2c/nvidia,tegra186-bpmp-i2c.txt deleted file mode 100644 index ab240e10debc..000000000000 --- a/Documentation/devicetree/bindings/i2c/nvidia,tegra186-bpmp-i2c.txt +++ /dev/null @@ -1,42 +0,0 @@ -NVIDIA Tegra186 BPMP I2C controller - -In Tegra186, the BPMP (Boot and Power Management Processor) owns certain HW -devices, such as the I2C controller for the power management I2C bus. Software -running on other CPUs must perform IPC to the BPMP in order to execute -transactions on that I2C bus. This binding describes an I2C bus that is -accessed in such a fashion. - -The BPMP I2C node must be located directly inside the main BPMP node. See -../firmware/nvidia,tegra186-bpmp.txt for details of the BPMP binding. - -This node represents an I2C controller. See ../i2c/i2c.txt for details of the -core I2C binding. - -Required properties: -- compatible: - Array of strings. - One of: - - "nvidia,tegra186-bpmp-i2c". -- #address-cells: Address cells for I2C device address. - Single-cell integer. - Must be <1>. -- #size-cells: - Single-cell integer. - Must be <0>. -- nvidia,bpmp-bus-id: - Single-cell integer. - Indicates the I2C bus number this DT node represent, as defined by the - BPMP firmware. - -Example: - -bpmp { - ... - - i2c { - compatible = "nvidia,tegra186-bpmp-i2c"; - #address-cells = <1>; - #size-cells = <0>; - nvidia,bpmp-bus-id = <5>; - }; -}; diff --git a/Documentation/devicetree/bindings/i2c/nvidia,tegra186-bpmp-i2c.yaml b/Documentation/devicetree/bindings/i2c/nvidia,tegra186-bpmp-i2c.yaml new file mode 100644 index 000000000000..b8319dcf3d8a --- /dev/null +++ b/Documentation/devicetree/bindings/i2c/nvidia,tegra186-bpmp-i2c.yaml @@ -0,0 +1,45 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/i2c/nvidia,tegra186-bpmp-i2c.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: NVIDIA Tegra186 (and later) BPMP I2C controller + +maintainers: + - Thierry Reding <thierry.reding@gmail.com> + - Jon Hunter <jonathanh@nvidia.com> + +description: | + In Tegra186 and later, the BPMP (Boot and Power Management Processor) + owns certain HW devices, such as the I2C controller for the power + management I2C bus. Software running on other CPUs must perform IPC to + the BPMP in order to execute transactions on that I2C bus. This + binding describes an I2C bus that is accessed in such a fashion. + + The BPMP I2C node must be located directly inside the main BPMP node. + See ../firmware/nvidia,tegra186-bpmp.yaml for details of the BPMP + binding. + + This node represents an I2C controller. See ../i2c/i2c.txt for details + of the core I2C binding. + +properties: + compatible: + const: nvidia,tegra186-bpmp-i2c + + nvidia,bpmp-bus-id: + $ref: /schemas/types.yaml#/definitions/uint32 + description: Indicates the I2C bus number this DT node represents, + as defined by the BPMP firmware. + +allOf: + - $ref: /schemas/i2c/i2c-controller.yaml + +unevaluatedProperties: false + +required: + - compatible + - "#address-cells" + - "#size-cells" + - nvidia,bpmp-bus-id diff --git a/Documentation/devicetree/bindings/i2c/nvidia,tegra20-i2c.txt b/Documentation/devicetree/bindings/i2c/nvidia,tegra20-i2c.txt deleted file mode 100644 index 3f2f990c2e62..000000000000 --- a/Documentation/devicetree/bindings/i2c/nvidia,tegra20-i2c.txt +++ /dev/null @@ -1,87 +0,0 @@ -NVIDIA Tegra20/Tegra30/Tegra114 I2C controller driver. - -Required properties: -- compatible : For Tegra20, must be one of "nvidia,tegra20-i2c-dvc" or - "nvidia,tegra20-i2c". For Tegra30, must be "nvidia,tegra30-i2c". - For Tegra114, must be "nvidia,tegra114-i2c". Otherwise, must be - "nvidia,<chip>-i2c", plus at least one of the above, where <chip> is - tegra124, tegra132, or tegra210. - Details of compatible are as follows: - nvidia,tegra20-i2c-dvc: Tegra20 has specific I2C controller called as DVC I2C - controller. This only support master mode of I2C communication. Register - interface/offset and interrupts handling are different than generic I2C - controller. Driver of DVC I2C controller is only compatible with - "nvidia,tegra20-i2c-dvc". - nvidia,tegra20-i2c: Tegra20 has 4 generic I2C controller. This can support - master and slave mode of I2C communication. The i2c-tegra driver only - support master mode of I2C communication. Driver of I2C controller is - only compatible with "nvidia,tegra20-i2c". - nvidia,tegra30-i2c: Tegra30 has 5 generic I2C controller. This controller is - very much similar to Tegra20 I2C controller with additional feature: - Continue Transfer Support. This feature helps to implement M_NO_START - as per I2C core API transfer flags. Driver of I2C controller is - compatible with "nvidia,tegra30-i2c" to enable the continue transfer - support. This is also compatible with "nvidia,tegra20-i2c" without - continue transfer support. - nvidia,tegra114-i2c: Tegra114 has 5 generic I2C controller. This controller is - very much similar to Tegra30 I2C controller with some hardware - modification: - - Tegra30/Tegra20 I2C controller has 2 clock source called div-clk and - fast-clk. Tegra114 has only one clock source called as div-clk and - hence clock mechanism is changed in I2C controller. - - Tegra30/Tegra20 I2C controller has enabled per packet transfer by - default and there is no way to disable it. Tegra114 has this - interrupt disable by default and SW need to enable explicitly. - Due to above changes, Tegra114 I2C driver makes incompatible with - previous hardware driver. Hence, tegra114 I2C controller is compatible - with "nvidia,tegra114-i2c". - nvidia,tegra210-i2c-vi: Tegra210 has one I2C controller that is on host1x bus - and is part of VE power domain and typically used for camera use-cases. - This VI I2C controller is mostly compatible with the programming model - of the regular I2C controllers with a few exceptions. The I2C registers - start at an offset of 0xc00 (instead of 0), registers are 16 bytes - apart (rather than 4) and the controller does not support slave mode. -- reg: Should contain I2C controller registers physical address and length. -- interrupts: Should contain I2C controller interrupts. -- address-cells: Address cells for I2C device address. -- size-cells: Size of the I2C device address. -- clocks: Must contain an entry for each entry in clock-names. - See ../clocks/clock-bindings.txt for details. -- clock-names: Must include the following entries: - Tegra20/Tegra30: - - div-clk - - fast-clk - Tegra114: - - div-clk - Tegra210: - - div-clk - - slow (only for nvidia,tegra210-i2c-vi compatible node) -- resets: Must contain an entry for each entry in reset-names. - See ../reset/reset.txt for details. -- reset-names: Must include the following entries: - - i2c -- power-domains: Only for nvidia,tegra210-i2c-vi compatible node and must - include venc powergate node as vi i2c is part of VE power domain. - tegra210-i2c-vi: - - pd_venc -- dmas: Must contain an entry for each entry in clock-names. - See ../dma/dma.txt for details. -- dma-names: Must include the following entries: - - rx - - tx - -Example: - - i2c@7000c000 { - compatible = "nvidia,tegra20-i2c"; - reg = <0x7000c000 0x100>; - interrupts = <0 38 0x04>; - #address-cells = <1>; - #size-cells = <0>; - clocks = <&tegra_car 12>, <&tegra_car 124>; - clock-names = "div-clk", "fast-clk"; - resets = <&tegra_car 12>; - reset-names = "i2c"; - dmas = <&apbdma 16>, <&apbdma 16>; - dma-names = "rx", "tx"; - }; diff --git a/Documentation/devicetree/bindings/i2c/nvidia,tegra20-i2c.yaml b/Documentation/devicetree/bindings/i2c/nvidia,tegra20-i2c.yaml new file mode 100644 index 000000000000..424a4fc218b6 --- /dev/null +++ b/Documentation/devicetree/bindings/i2c/nvidia,tegra20-i2c.yaml @@ -0,0 +1,192 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/i2c/nvidia,tegra20-i2c.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +maintainers: + - Thierry Reding <thierry.reding@gmail.com> + - Jon Hunter <jonathanh@nvidia.com> + +title: NVIDIA Tegra I2C controller driver + +properties: + compatible: + oneOf: + - description: Tegra20 has 4 generic I2C controller. This can support + master and slave mode of I2C communication. The i2c-tegra driver + only support master mode of I2C communication. Driver of I2C + controller is only compatible with "nvidia,tegra20-i2c". + const: nvidia,tegra20-i2c + - description: Tegra20 has specific I2C controller called as DVC I2C + controller. This only support master mode of I2C communication. + Register interface/offset and interrupts handling are different than + generic I2C controller. Driver of DVC I2C controller is only + compatible with "nvidia,tegra20-i2c-dvc". + const: nvidia,tegra20-i2c-dvc + - description: | + Tegra30 has 5 generic I2C controller. This controller is very much + similar to Tegra20 I2C controller with additional feature: Continue + Transfer Support. This feature helps to implement M_NO_START as per + I2C core API transfer flags. Driver of I2C controller is compatible + with "nvidia,tegra30-i2c" to enable the continue transfer support. + This is also compatible with "nvidia,tegra20-i2c" without continue + transfer support. + items: + - const: nvidia,tegra30-i2c + - const: nvidia,tegra20-i2c + - description: | + Tegra114 has 5 generic I2C controllers. This controller is very much + similar to Tegra30 I2C controller with some hardware modification: + - Tegra30/Tegra20 I2C controller has 2 clock source called div-clk + and fast-clk. Tegra114 has only one clock source called as + div-clk and hence clock mechanism is changed in I2C controller. + - Tegra30/Tegra20 I2C controller has enabled per packet transfer + by default and there is no way to disable it. Tegra114 has this + interrupt disable by default and SW need to enable explicitly. + Due to above changes, Tegra114 I2C driver makes incompatible with + previous hardware driver. Hence, Tegra114 I2C controller is + compatible with "nvidia,tegra114-i2c". + const: nvidia,tegra114-i2c + - description: | + Tegra124 has 6 generic I2C controllers. These controllers are very + similar to those found on Tegra114 but also contain several hardware + improvements and new registers. + const: nvidia,tegra124-i2c + - description: | + Tegra210 has 6 generic I2C controllers. These controllers are very + similar to those found on Tegra124. + items: + - const: nvidia,tegra210-i2c + - const: nvidia,tegra124-i2c + - description: | + Tegra210 has one I2C controller that is on host1x bus and is part of + the VE power domain and typically used for camera use-cases. This VI + I2C controller is mostly compatible with the programming model of + the regular I2C controllers with a few exceptions. The I2C registers + start at an offset of 0xc00 (instead of 0), registers are 16 bytes + apart (rather than 4) and the controller does not support slave + mode. + const: nvidia,tegra210-i2c-vi + - description: | + Tegra186 has 9 generic I2C controllers, two of which are in the AON + (always-on) partition of the SoC. All of these controllers are very + similar to those found on Tegra210. + const: nvidia,tegra186-i2c + - description: | + Tegra194 has 8 generic I2C controllers, two of which are in the AON + (always-on) partition of the SoC. All of these controllers are very + similar to those found on Tegra186. However, these controllers have + support for 64 KiB transactions whereas earlier chips supported no + more than 4 KiB per transactions. + const: nvidia,tegra194-i2c + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + '#address-cells': + const: 1 + + '#size-cells': + const: 0 + + clocks: + minItems: 1 + maxItems: 2 + + clock-names: + minItems: 1 + maxItems: 2 + + resets: + items: + - description: module reset + + reset-names: + items: + - const: i2c + + dmas: + items: + - description: DMA channel for the reception FIFO + - description: DMA channel for the transmission FIFO + + dma-names: + items: + - const: rx + - const: tx + +allOf: + - $ref: /schemas/i2c/i2c-controller.yaml + - if: + properties: + compatible: + contains: + enum: + - nvidia,tegra20-i2c + - nvidia,tegra30-i2c + then: + properties: + clock-names: + items: + - const: div-clk + - const: fast-clk + + - if: + properties: + compatible: + contains: + const: nvidia,tegra114-i2c + then: + properties: + clock-names: + items: + - const: div-clk + + - if: + properties: + compatible: + contains: + const: nvidia,tegra210-i2c + then: + properties: + clock-names: + items: + - const: div-clk + + - if: + properties: + compatible: + contains: + const: nvidia,tegra210-i2c-vi + then: + properties: + clock-names: + items: + - const: div-clk + - const: slow + power-domains: + items: + - description: phandle to the VENC power domain + +unevaluatedProperties: false + +examples: + - | + i2c@7000c000 { + compatible = "nvidia,tegra20-i2c"; + reg = <0x7000c000 0x100>; + interrupts = <0 38 0x04>; + clocks = <&tegra_car 12>, <&tegra_car 124>; + clock-names = "div-clk", "fast-clk"; + resets = <&tegra_car 12>; + reset-names = "i2c"; + dmas = <&apbdma 16>, <&apbdma 16>; + dma-names = "rx", "tx"; + + #address-cells = <1>; + #size-cells = <0>; + }; diff --git a/Documentation/devicetree/bindings/i2c/st,stm32-i2c.yaml b/Documentation/devicetree/bindings/i2c/st,stm32-i2c.yaml index c07289a643d8..46b62e1c9273 100644 --- a/Documentation/devicetree/bindings/i2c/st,stm32-i2c.yaml +++ b/Documentation/devicetree/bindings/i2c/st,stm32-i2c.yaml @@ -112,6 +112,9 @@ examples: clocks = <&rcc 0 149>; }; + - | + #include <dt-bindings/mfd/stm32f7-rcc.h> + #include <dt-bindings/clock/stm32fx-clock.h> //Example 2 (with st,stm32f7-i2c compatible) i2c@40005800 { compatible = "st,stm32f7-i2c"; @@ -124,6 +127,9 @@ examples: clocks = <&rcc 1 CLK_I2C1>; }; + - | + #include <dt-bindings/mfd/stm32f7-rcc.h> + #include <dt-bindings/clock/stm32fx-clock.h> //Example 3 (with st,stm32mp15-i2c compatible on stm32mp) #include <dt-bindings/interrupt-controller/arm-gic.h> #include <dt-bindings/clock/stm32mp1-clks.h> diff --git a/Documentation/devicetree/bindings/iio/adc/fsl,vf610-adc.yaml b/Documentation/devicetree/bindings/iio/adc/fsl,vf610-adc.yaml index 1ca571056ea9..925f355cc21f 100644 --- a/Documentation/devicetree/bindings/iio/adc/fsl,vf610-adc.yaml +++ b/Documentation/devicetree/bindings/iio/adc/fsl,vf610-adc.yaml @@ -7,7 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml# title: ADC found on Freescale vf610 and similar SoCs maintainers: - - Fugang Duan <fugang.duan@nxp.com> + - Haibo Chen <haibo.chen@nxp.com> description: ADCs found on vf610/i.MX6slx and upward SoCs from Freescale. diff --git a/Documentation/devicetree/bindings/iio/adc/samsung,exynos-adc.yaml b/Documentation/devicetree/bindings/iio/adc/samsung,exynos-adc.yaml index c65921e66dc1..81c87295912c 100644 --- a/Documentation/devicetree/bindings/iio/adc/samsung,exynos-adc.yaml +++ b/Documentation/devicetree/bindings/iio/adc/samsung,exynos-adc.yaml @@ -136,7 +136,7 @@ examples: samsung,syscon-phandle = <&pmu_system_controller>; /* NTC thermistor is a hwmon device */ - ncp15wb473 { + thermistor { compatible = "murata,ncp15wb473"; pullup-uv = <1800000>; pullup-ohm = <47000>; diff --git a/Documentation/devicetree/bindings/iio/adc/x-powers,axp209-adc.yaml b/Documentation/devicetree/bindings/iio/adc/x-powers,axp209-adc.yaml index e759a5da708d..d6d3d8590171 100644 --- a/Documentation/devicetree/bindings/iio/adc/x-powers,axp209-adc.yaml +++ b/Documentation/devicetree/bindings/iio/adc/x-powers,axp209-adc.yaml @@ -27,6 +27,7 @@ description: | 8 | batt_v 9 | batt_chrg_i 10 | batt_dischrg_i + 11 | ts_v AXP22x ------ @@ -34,6 +35,7 @@ description: | 1 | batt_v 2 | batt_chrg_i 3 | batt_dischrg_i + 4 | ts_v AXP813 ------ @@ -42,6 +44,7 @@ description: | 2 | batt_v 3 | batt_chrg_i 4 | batt_dischrg_i + 5 | ts_v properties: diff --git a/Documentation/devicetree/bindings/iio/adc/xlnx,zynqmp-ams.yaml b/Documentation/devicetree/bindings/iio/adc/xlnx,zynqmp-ams.yaml new file mode 100644 index 000000000000..87992db389b2 --- /dev/null +++ b/Documentation/devicetree/bindings/iio/adc/xlnx,zynqmp-ams.yaml @@ -0,0 +1,227 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/iio/adc/xlnx,zynqmp-ams.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Xilinx Zynq Ultrascale AMS controller + +maintainers: + - Anand Ashok Dumbre <anand.ashok.dumbre@xilinx.com> + +description: | + The AMS (Analog Monitoring System) includes an ADC as well as on-chip sensors + that can be used to sample external voltages and monitor on-die operating + conditions, such as temperature and supply voltage levels. + The AMS has two SYSMON blocks which are PL (Programmable Logic) SYSMON and + PS (Processing System) SYSMON. + All designs should have AMS registers, but PS and PL are optional. The + AMS controller can work with only PS, only PL and both PS and PL + configurations. Please specify registers according to your design. Devicetree + should always have AMS module property. Providing PS & PL module is optional. + + AMS Channel Details + ``````````````````` + Sysmon Block |Channel| Details |Measurement + |Number | |Type + --------------------------------------------------------------------------------------------------------- + AMS CTRL |0 |System PLLs voltage measurement, VCC_PSPLL. |Voltage + |1 |Battery voltage measurement, VCC_PSBATT. |Voltage + |2 |PL Internal voltage measurement, VCCINT. |Voltage + |3 |Block RAM voltage measurement, VCCBRAM. |Voltage + |4 |PL Aux voltage measurement, VCCAUX. |Voltage + |5 |Voltage measurement for six DDR I/O PLLs, VCC_PSDDR_PLL. |Voltage + |6 |VCC_PSINTFP_DDR voltage measurement. |Voltage + --------------------------------------------------------------------------------------------------------- + PS Sysmon |7 |LPD temperature measurement. |Temperature + |8 |FPD temperature measurement (REMOTE). |Temperature + |9 |VCC PS LPD voltage measurement (supply1). |Voltage + |10 |VCC PS FPD voltage measurement (supply2). |Voltage + |11 |PS Aux voltage reference (supply3). |Voltage + |12 |DDR I/O VCC voltage measurement. |Voltage + |13 |PS IO Bank 503 voltage measurement (supply5). |Voltage + |14 |PS IO Bank 500 voltage measurement (supply6). |Voltage + |15 |VCCO_PSIO1 voltage measurement. |Voltage + |16 |VCCO_PSIO2 voltage measurement. |Voltage + |17 |VCC_PS_GTR voltage measurement (VPS_MGTRAVCC). |Voltage + |18 |VTT_PS_GTR voltage measurement (VPS_MGTRAVTT). |Voltage + |19 |VCC_PSADC voltage measurement. |Voltage + --------------------------------------------------------------------------------------------------------- + PL Sysmon |20 |PL temperature measurement. |Temperature + |21 |PL Internal voltage measurement, VCCINT. |Voltage + |22 |PL Auxiliary voltage measurement, VCCAUX. |Voltage + |23 |ADC Reference P+ voltage measurement. |Voltage + |24 |ADC Reference N- voltage measurement. |Voltage + |25 |PL Block RAM voltage measurement, VCCBRAM. |Voltage + |26 |LPD Internal voltage measurement, VCC_PSINTLP (supply4). |Voltage + |27 |FPD Internal voltage measurement, VCC_PSINTFP (supply5). |Voltage + |28 |PS Auxiliary voltage measurement (supply6). |Voltage + |29 |PL VCCADC voltage measurement (vccams). |Voltage + |30 |Differential analog input signal voltage measurment. |Voltage + |31 |VUser0 voltage measurement (supply7). |Voltage + |32 |VUser1 voltage measurement (supply8). |Voltage + |33 |VUser2 voltage measurement (supply9). |Voltage + |34 |VUser3 voltage measurement (supply10). |Voltage + |35 |Auxiliary ch 0 voltage measurement (VAux0). |Voltage + |36 |Auxiliary ch 1 voltage measurement (VAux1). |Voltage + |37 |Auxiliary ch 2 voltage measurement (VAux2). |Voltage + |38 |Auxiliary ch 3 voltage measurement (VAux3). |Voltage + |39 |Auxiliary ch 4 voltage measurement (VAux4). |Voltage + |40 |Auxiliary ch 5 voltage measurement (VAux5). |Voltage + |41 |Auxiliary ch 6 voltage measurement (VAux6). |Voltage + |42 |Auxiliary ch 7 voltage measurement (VAux7). |Voltage + |43 |Auxiliary ch 8 voltage measurement (VAux8). |Voltage + |44 |Auxiliary ch 9 voltage measurement (VAux9). |Voltage + |45 |Auxiliary ch 10 voltage measurement (VAux10). |Voltage + |46 |Auxiliary ch 11 voltage measurement (VAux11). |Voltage + |47 |Auxiliary ch 12 voltage measurement (VAux12). |Voltage + |48 |Auxiliary ch 13 voltage measurement (VAux13). |Voltage + |49 |Auxiliary ch 14 voltage measurement (VAux14). |Voltage + |50 |Auxiliary ch 15 voltage measurement (VAux15). |Voltage + -------------------------------------------------------------------------------------------------------- + +properties: + compatible: + enum: + - xlnx,zynqmp-ams + + interrupts: + maxItems: 1 + + reg: + description: AMS Controller register space + maxItems: 1 + + ranges: + description: + Maps the child address space for PS and/or PL. + maxItems: 1 + + '#address-cells': + const: 1 + + '#size-cells': + const: 1 + + '#io-channel-cells': + const: 1 + + ams-ps@0: + type: object + description: | + PS (Processing System) SYSMON is memory mapped to PS. This block has + built-in alarm generation logic that is used to interrupt the processor + based on condition set. + + properties: + compatible: + enum: + - xlnx,zynqmp-ams-ps + + reg: + description: Register Space for PS-SYSMON + maxItems: 1 + + required: + - compatible + - reg + + additionalProperties: false + + ams-pl@400: + type: object + description: + PL-SYSMON is capable of monitoring off chip voltage and temperature. + PL-SYSMON block has DRP, JTAG and I2C interface to enable monitoring + from external master. Out of this interface currently only DRP is + supported. This block has alarm generation logic that is used to + interrupt the processor based on condition set. + + properties: + compatible: + items: + - enum: + - xlnx,zynqmp-ams-pl + + reg: + description: Register Space for PL-SYSMON. + maxItems: 1 + + '#address-cells': + const: 1 + + '#size-cells': + const: 0 + + patternProperties: + "^channel@([2-4][0-9]|50)$": + type: object + description: + Describes the external channels connected. + + properties: + reg: + description: + Pair of pins the channel is connected to. This value is + same as Channel Number for a particular channel. + minimum: 20 + maximum: 50 + + xlnx,bipolar: + $ref: /schemas/types.yaml#/definitions/flag + type: boolean + description: + If the set channel is used in bipolar mode. + + required: + - reg + + additionalProperties: false + +required: + - compatible + - reg + - ranges + +additionalProperties: false + +examples: + - | + bus { + #address-cells = <2>; + #size-cells = <2>; + + xilinx_ams: ams@ffa50000 { + compatible = "xlnx,zynqmp-ams"; + interrupt-parent = <&gic>; + interrupts = <0 56 4>; + reg = <0x0 0xffa50000 0x0 0x800>; + #address-cells = <1>; + #size-cells = <1>; + #io-channel-cells = <1>; + ranges = <0 0 0xffa50800 0x800>; + + ams_ps: ams-ps@0 { + compatible = "xlnx,zynqmp-ams-ps"; + reg = <0 0x400>; + }; + + ams_pl: ams-pl@400 { + compatible = "xlnx,zynqmp-ams-pl"; + reg = <0x400 0x400>; + #address-cells = <1>; + #size-cells = <0>; + channel@30 { + reg = <30>; + xlnx,bipolar; + }; + channel@31 { + reg = <31>; + }; + channel@38 { + reg = <38>; + xlnx,bipolar; + }; + }; + }; + }; diff --git a/Documentation/devicetree/bindings/iio/addac/adi,ad74413r.yaml b/Documentation/devicetree/bindings/iio/addac/adi,ad74413r.yaml new file mode 100644 index 000000000000..baa65a521bad --- /dev/null +++ b/Documentation/devicetree/bindings/iio/addac/adi,ad74413r.yaml @@ -0,0 +1,158 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/iio/addac/adi,ad74413r.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Analog Devices AD74412R/AD74413R device + +maintainers: + - Cosmin Tanislav <cosmin.tanislav@analog.com> + +description: | + The AD74412R and AD74413R are quad-channel software configurable input/output + solutions for building and process control applications. They contain + functionality for analog output, analog input, digital input, resistance + temperature detector, and thermocouple measurements integrated + into a single chip solution with an SPI interface. + The devices feature a 16-bit ADC and four configurable 13-bit DACs to provide + four configurable input/output channels and a suite of diagnostic functions. + The AD74413R differentiates itself from the AD74412R by being HART-compatible. + https://www.analog.com/en/products/ad74412r.html + https://www.analog.com/en/products/ad74413r.html + +properties: + compatible: + enum: + - adi,ad74412r + - adi,ad74413r + + reg: + maxItems: 1 + + '#address-cells': + const: 1 + + '#size-cells': + const: 0 + + spi-max-frequency: + maximum: 1000000 + + spi-cpol: true + + interrupts: + maxItems: 1 + + refin-supply: true + + shunt-resistor-micro-ohms: + description: + Shunt (sense) resistor value in micro-Ohms. + default: 100000000 + +required: + - compatible + - reg + - spi-max-frequency + - spi-cpol + - refin-supply + +additionalProperties: false + +patternProperties: + "^channel@[0-3]$": + type: object + description: Represents the external channels which are connected to the device. + + properties: + reg: + description: | + The channel number. It can have up to 4 channels numbered from 0 to 3. + minimum: 0 + maximum: 3 + + adi,ch-func: + $ref: /schemas/types.yaml#/definitions/uint32 + description: | + Channel function. + HART functions are not supported on AD74412R. + 0 - CH_FUNC_HIGH_IMPEDANCE + 1 - CH_FUNC_VOLTAGE_OUTPUT + 2 - CH_FUNC_CURRENT_OUTPUT + 3 - CH_FUNC_VOLTAGE_INPUT + 4 - CH_FUNC_CURRENT_INPUT_EXT_POWER + 5 - CH_FUNC_CURRENT_INPUT_LOOP_POWER + 6 - CH_FUNC_RESISTANCE_INPUT + 7 - CH_FUNC_DIGITAL_INPUT_LOGIC + 8 - CH_FUNC_DIGITAL_INPUT_LOOP_POWER + 9 - CH_FUNC_CURRENT_INPUT_EXT_POWER_HART + 10 - CH_FUNC_CURRENT_INPUT_LOOP_POWER_HART + minimum: 0 + maximum: 10 + default: 0 + + adi,gpo-comparator: + type: boolean + description: | + Whether to configure GPO as a comparator or not. + When not configured as a comparator, the GPO will be treated as an + output-only GPIO. + + required: + - reg + +examples: + - | + #include <dt-bindings/gpio/gpio.h> + #include <dt-bindings/interrupt-controller/irq.h> + #include <dt-bindings/iio/addac/adi,ad74413r.h> + + spi { + #address-cells = <1>; + #size-cells = <0>; + + cs-gpios = <&gpio 17 GPIO_ACTIVE_LOW>; + status = "okay"; + + ad74413r@0 { + compatible = "adi,ad74413r"; + reg = <0>; + spi-max-frequency = <1000000>; + spi-cpol; + + #address-cells = <1>; + #size-cells = <0>; + + interrupt-parent = <&gpio>; + interrupts = <26 IRQ_TYPE_EDGE_FALLING>; + + refin-supply = <&ad74413r_refin>; + + channel@0 { + reg = <0>; + + adi,ch-func = <CH_FUNC_VOLTAGE_OUTPUT>; + }; + + channel@1 { + reg = <1>; + + adi,ch-func = <CH_FUNC_CURRENT_OUTPUT>; + }; + + channel@2 { + reg = <2>; + + adi,ch-func = <CH_FUNC_DIGITAL_INPUT_LOGIC>; + adi,gpo-comparator; + }; + + channel@3 { + reg = <3>; + + adi,ch-func = <CH_FUNC_CURRENT_INPUT_EXT_POWER>; + }; + }; + }; +... diff --git a/Documentation/devicetree/bindings/iio/dac/adi,ad3552r.yaml b/Documentation/devicetree/bindings/iio/dac/adi,ad3552r.yaml new file mode 100644 index 000000000000..501a463e5d88 --- /dev/null +++ b/Documentation/devicetree/bindings/iio/dac/adi,ad3552r.yaml @@ -0,0 +1,217 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +# Copyright 2020 Analog Devices Inc. +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/iio/dac/adi,ad3552r.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Analog Devices AD2552R DAC device driver + +maintainers: + - Mihail Chindris <mihail.chindris@analog.com> + +description: | + Bindings for the Analog Devices AD3552R DAC device and similar. + Datasheet can be found here: + https://www.analog.com/media/en/technical-documentation/data-sheets/ad3542r.pdf + https://www.analog.com/media/en/technical-documentation/data-sheets/ad3552r.pdf + +properties: + compatible: + enum: + - adi,ad3542r + - adi,ad3552r + + reg: + maxItems: 1 + + spi-max-frequency: + maximum: 30000000 + + reset-gpios: + maxItems: 1 + + ldac-gpios: + description: | + LDAC pin to be used as a hardware trigger to update the DAC channels. + maxItems: 1 + + vref-supply: + description: + The regulator to use as an external reference. If it does not exists the + internal reference will be used. External reference must be 2.5V + + adi,vref-out-en: + description: Vref I/O driven by internal vref to 2.5V. If not set, Vref pin + will be floating. + type: boolean + + adi,sdo-drive-strength: + description: | + Configure SDIO0 and SDIO1 strength levels: + - 0: low SDO drive strength. + - 1: medium low SDO drive strength. + - 2: medium high SDO drive strength. + - 3: high SDO drive strength + $ref: /schemas/types.yaml#/definitions/uint32 + enum: [0, 1, 2, 3] + + '#address-cells': + const: 1 + + '#size-cells': + const: 0 + +patternProperties: + "^channel@([0-1])$": + type: object + description: Configurations of the DAC Channels + + additionalProperties: false + + properties: + reg: + description: Channel number + enum: [0, 1] + + adi,output-range-microvolt: true + + custom-output-range-config: + type: object + description: Configuration of custom range when + adi,output-range-microvolt is not present. + The formulas for calculation the output voltages are + Vout_fs = 2.5 + [(GainN + Offset/1024) * 2.5 * Rfbx * 1.03] + Vout_zs = 2.5 - [(GainP + Offset/1024) * 2.5 * Rfbx * 1.03] + + properties: + adi,gain-offset: + description: Gain offset used in the above formula + $ref: /schemas/types.yaml#/definitions/int32 + maximum: 511 + minimum: -511 + + adi,gain-scaling-p-inv-log2: + description: GainP = 1 / ( 2 ^ adi,gain-scaling-p-inv-log2) + $ref: /schemas/types.yaml#/definitions/uint32 + enum: [0, 1, 2, 3] + + adi,gain-scaling-n-inv-log2: + description: GainN = 1 / ( 2 ^ adi,gain-scaling-n-inv-log2) + $ref: /schemas/types.yaml#/definitions/uint32 + enum: [0, 1, 2, 3] + + adi,rfb-ohms: + description: Feedback Resistor + + required: + - adi,gain-offset + - adi,gain-scaling-p-inv-log2 + - adi,gain-scaling-n-inv-log2 + - adi,rfb-ohms + + required: + - reg + + oneOf: + # If adi,output-range-microvolt is missing, + # custom-output-range-config must be used + - required: + - adi,output-range-microvolt + + - required: + - custom-output-range-config + +allOf: + - if: + properties: + compatible: + contains: + const: adi,ad3542r + then: + patternProperties: + "^channel@([0-1])$": + type: object + properties: + adi,output-range-microvolt: + description: | + Voltage output range of the channel as <minimum, maximum> + Required connections: + Rfb1x for: 0 to 2.5 V; 0 to 3V; 0 to 5 V; + Rfb2x for: 0 to 10 V; 2.5 to 7.5V; -5 to 5 V; + oneOf: + - items: + - const: 0 + - enum: [2500000, 3000000, 5000000, 10000000] + - items: + - const: -2500000 + - const: 7500000 + - items: + - const: -5000000 + - const: 5000000 + + required: + - adi,output-range-microvolt + + - if: + properties: + compatible: + contains: + const: adi,ad3552r + then: + patternProperties: + "^channel@([0-1])$": + type: object + properties: + adi,output-range-microvolt: + description: | + Voltage output range of the channel as <minimum, maximum> + Required connections: + Rfb1x for: 0 to 2.5 V; 0 to 5 V; + Rfb2x for: 0 to 10 V; -5 to 5 V; + Rfb4x for: -10 to 10V + oneOf: + - items: + - const: 0 + - enum: [2500000, 5000000, 10000000] + - items: + - const: -5000000 + - const: 5000000 + - items: + - const: -10000000 + - const: 10000000 + +required: + - compatible + - reg + - spi-max-frequency + +additionalProperties: false + +examples: + - | + spi { + #address-cells = <1>; + #size-cells = <0>; + ad3552r@0 { + compatible = "adi,ad3552r"; + reg = <0>; + spi-max-frequency = <20000000>; + #address-cells = <1>; + #size-cells = <0>; + channel@0 { + reg = <0>; + adi,output-range-microvolt = <0 10000000>; + }; + channel@1 { + reg = <1>; + custom-output-range-config { + adi,gain-offset = <5>; + adi,gain-scaling-p-inv-log2 = <1>; + adi,gain-scaling-n-inv-log2 = <2>; + adi,rfb-ohms = <1>; + }; + }; + }; + }; +... diff --git a/Documentation/devicetree/bindings/iio/dac/adi,ad5755.yaml b/Documentation/devicetree/bindings/iio/dac/adi,ad5755.yaml index be419ac46caa..f866b88e1440 100644 --- a/Documentation/devicetree/bindings/iio/dac/adi,ad5755.yaml +++ b/Documentation/devicetree/bindings/iio/dac/adi,ad5755.yaml @@ -125,7 +125,6 @@ oneOf: examples: - | - #include <dt-bindings/iio/adi,ad5592r.h> spi { #address-cells = <1>; #size-cells = <0>; diff --git a/Documentation/devicetree/bindings/iio/dac/adi,ad7293.yaml b/Documentation/devicetree/bindings/iio/dac/adi,ad7293.yaml new file mode 100644 index 000000000000..5ee80bf6aa11 --- /dev/null +++ b/Documentation/devicetree/bindings/iio/dac/adi,ad7293.yaml @@ -0,0 +1,61 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/iio/dac/adi,ad7293.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: AD7293 12-Bit Power Amplifier Current Controller with ADC, + DACs, Temperature and Current Sensors + +maintainers: + - Antoniu Miclaus <antoniu.miclaus@analog.com> + +description: | + Power Amplifier drain current controller containing functionality + for general-purpose monitoring and control of current, voltage, + and temperature, integrated into a single chip solution with an + SPI-compatible interface. + + https://www.analog.com/en/products/ad7293.html + +properties: + compatible: + enum: + - adi,ad7293 + + avdd-supply: true + + vdrive-supply: true + + reset-gpios: + maxItems: 1 + + reg: + maxItems: 1 + + spi-max-frequency: + maximum: 1000000 + +required: + - compatible + - reg + - avdd-supply + - vdrive-supply + +additionalProperties: false + +examples: + - | + spi { + #address-cells = <1>; + #size-cells = <0>; + ad7293@0 { + compatible = "adi,ad7293"; + reg = <0>; + spi-max-frequency = <1000000>; + avdd-supply = <&avdd>; + vdrive-supply = <&vdrive>; + reset-gpios = <&gpio 10 0>; + }; + }; +... diff --git a/Documentation/devicetree/bindings/iio/filter/adi,admv8818.yaml b/Documentation/devicetree/bindings/iio/filter/adi,admv8818.yaml new file mode 100644 index 000000000000..b77e855bd594 --- /dev/null +++ b/Documentation/devicetree/bindings/iio/filter/adi,admv8818.yaml @@ -0,0 +1,66 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/iio/filter/adi,admv8818.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: ADMV8818 Digitally Tunable, High-Pass and Low-Pass Filter + +maintainers: + - Antoniu Miclaus <antoniu.miclaus@analog.com> + +description: | + Fully monolithic microwave integrated circuit (MMIC) that + features a digitally selectable frequency of operation. + The device features four independently controlled high-pass + filters (HPFs) and four independently controlled low-pass filters + (LPFs) that span the 2 GHz to 18 GHz frequency range. + + https://www.analog.com/en/products/admv8818.html + +properties: + compatible: + enum: + - adi,admv8818 + + reg: + maxItems: 1 + + spi-max-frequency: + maximum: 10000000 + + clocks: + description: + Definition of the external clock. + minItems: 1 + + clock-names: + items: + - const: rf_in + + clock-output-names: + maxItems: 1 + + '#clock-cells': + const: 0 + +required: + - compatible + - reg + +additionalProperties: false + +examples: + - | + spi { + #address-cells = <1>; + #size-cells = <0>; + admv8818@0 { + compatible = "adi,admv8818"; + reg = <0>; + spi-max-frequency = <10000000>; + clocks = <&admv8818_rfin>; + clock-names = "rf_in"; + }; + }; +... diff --git a/Documentation/devicetree/bindings/iio/frequency/adi,admv1013.yaml b/Documentation/devicetree/bindings/iio/frequency/adi,admv1013.yaml new file mode 100644 index 000000000000..23f1f3b55abb --- /dev/null +++ b/Documentation/devicetree/bindings/iio/frequency/adi,admv1013.yaml @@ -0,0 +1,91 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/iio/frequency/adi,admv1013.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: ADMV1013 Microwave Upconverter + +maintainers: + - Antoniu Miclaus <antoniu.miclaus@analog.com> + +description: | + Wideband, microwave upconverter optimized for point to point microwave + radio designs operating in the 24 GHz to 44 GHz frequency range. + + https://www.analog.com/en/products/admv1013.html + +properties: + compatible: + enum: + - adi,admv1013 + + reg: + maxItems: 1 + + spi-max-frequency: + maximum: 1000000 + + clocks: + description: + Definition of the external clock. + minItems: 1 + + clock-names: + items: + - const: lo_in + + vcm-supply: + description: + Analog voltage regulator. + + adi,detector-enable: + description: + Enable the Envelope Detector available at output pins VENV_P and + VENV_N. Disable to reduce power consumption. + type: boolean + + adi,input-mode: + description: + Select the input mode. + iq - in-phase quadrature (I/Q) input + if - complex intermediate frequency (IF) input + enum: [iq, if] + + adi,quad-se-mode: + description: + Switch the LO path from differential to single-ended operation. + se-neg - Single-Ended Mode, Negative Side Disabled. + se-pos - Single-Ended Mode, Positive Side Disabled. + diff - Differential Mode. + enum: [se-neg, se-pos, diff] + + '#clock-cells': + const: 0 + +required: + - compatible + - reg + - clocks + - clock-names + - vcm-supply + +additionalProperties: false + +examples: + - | + spi { + #address-cells = <1>; + #size-cells = <0>; + admv1013@0{ + compatible = "adi,admv1013"; + reg = <0>; + spi-max-frequency = <1000000>; + clocks = <&admv1013_lo>; + clock-names = "lo_in"; + vcm-supply = <&vcm>; + adi,quad-se-mode = "diff"; + adi,detector-enable; + }; + }; +... diff --git a/Documentation/devicetree/bindings/iio/gyroscope/invensense,mpu3050.yaml b/Documentation/devicetree/bindings/iio/gyroscope/invensense,mpu3050.yaml index 7e2accc3d5ce..d1a6103fc37a 100644 --- a/Documentation/devicetree/bindings/iio/gyroscope/invensense,mpu3050.yaml +++ b/Documentation/devicetree/bindings/iio/gyroscope/invensense,mpu3050.yaml @@ -61,7 +61,7 @@ examples: #size-cells = <0>; magnetometer@c { - compatible = "ak,ak8975"; + compatible = "asahi-kasei,ak8975"; reg = <0x0c>; }; }; diff --git a/Documentation/devicetree/bindings/iio/imu/invensense,mpu6050.yaml b/Documentation/devicetree/bindings/iio/imu/invensense,mpu6050.yaml index edbc2921aabd..d69595a524c1 100644 --- a/Documentation/devicetree/bindings/iio/imu/invensense,mpu6050.yaml +++ b/Documentation/devicetree/bindings/iio/imu/invensense,mpu6050.yaml @@ -95,7 +95,7 @@ examples: #address-cells = <1>; #size-cells = <0>; magnetometer@c { - compatible = "ak,ak8975"; + compatible = "asahi-kasei,ak8975"; reg = <0x0c>; }; }; diff --git a/Documentation/devicetree/bindings/iio/imu/st,lsm6dsx.yaml b/Documentation/devicetree/bindings/iio/imu/st,lsm6dsx.yaml index d9b3213318fb..0750f700a143 100644 --- a/Documentation/devicetree/bindings/iio/imu/st,lsm6dsx.yaml +++ b/Documentation/devicetree/bindings/iio/imu/st,lsm6dsx.yaml @@ -61,6 +61,13 @@ properties: type: boolean description: enable/disable internal i2c controller pullup resistors. + st,disable-sensor-hub: + type: boolean + description: + Enable/disable internal i2c controller slave autoprobing at bootstrap. + Disable sensor-hub is useful if i2c controller clock/data lines are + connected through a pull-up with other chip lines (e.g. SDO/SA0). + drive-open-drain: type: boolean description: diff --git a/Documentation/devicetree/bindings/iio/light/liteon,ltr501.yaml b/Documentation/devicetree/bindings/iio/light/liteon,ltr501.yaml index db0407bc9209..c8074f180a79 100644 --- a/Documentation/devicetree/bindings/iio/light/liteon,ltr501.yaml +++ b/Documentation/devicetree/bindings/iio/light/liteon,ltr501.yaml @@ -9,6 +9,9 @@ title: LiteON LTR501 I2C Proximity and Light sensor maintainers: - Nikita Travkin <nikita@trvn.ru> +allOf: + - $ref: ../common.yaml# + properties: compatible: enum: @@ -25,6 +28,8 @@ properties: interrupts: maxItems: 1 + proximity-near-level: true + additionalProperties: false required: @@ -42,6 +47,8 @@ examples: light-sensor@23 { compatible = "liteon,ltr559"; reg = <0x23>; + proximity-near-level = <75>; + vdd-supply = <&pm8916_l17>; vddio-supply = <&pm8916_l6>; diff --git a/Documentation/devicetree/bindings/iio/magnetometer/yamaha,yas530.yaml b/Documentation/devicetree/bindings/iio/magnetometer/yamaha,yas530.yaml index 4b0ef1ef5445..9438fffaf0ba 100644 --- a/Documentation/devicetree/bindings/iio/magnetometer/yamaha,yas530.yaml +++ b/Documentation/devicetree/bindings/iio/magnetometer/yamaha,yas530.yaml @@ -96,7 +96,7 @@ examples: vdd-supply = <&ldo1_reg>; iovdd-supply = <&ldo2_reg>; reset-gpios = <&gpio6 12 GPIO_ACTIVE_LOW>; - interrupts = <&gpio6 13 IRQ_TYPE_EDGE_RISING>; + interrupts = <13 IRQ_TYPE_EDGE_RISING>; }; }; diff --git a/Documentation/devicetree/bindings/iio/proximity/google,cros-ec-mkbp-proximity.yaml b/Documentation/devicetree/bindings/iio/proximity/google,cros-ec-mkbp-proximity.yaml index 099b4be927d4..00e3b59641d2 100644 --- a/Documentation/devicetree/bindings/iio/proximity/google,cros-ec-mkbp-proximity.yaml +++ b/Documentation/devicetree/bindings/iio/proximity/google,cros-ec-mkbp-proximity.yaml @@ -10,7 +10,6 @@ title: ChromeOS EC MKBP Proximity Sensor maintainers: - Stephen Boyd <swboyd@chromium.org> - Benson Leung <bleung@chromium.org> - - Enric Balletbo i Serra <enric.balletbo@collabora.com> description: | Google's ChromeOS EC sometimes has the ability to detect user proximity. diff --git a/Documentation/devicetree/bindings/iio/temperature/adi,ltc2983.yaml b/Documentation/devicetree/bindings/iio/temperature/adi,ltc2983.yaml index 0f79d9a01c49..722781aa4697 100644 --- a/Documentation/devicetree/bindings/iio/temperature/adi,ltc2983.yaml +++ b/Documentation/devicetree/bindings/iio/temperature/adi,ltc2983.yaml @@ -448,17 +448,17 @@ examples: reg = <20>; adi,sensor-type = <9>; //custom thermocouple adi,single-ended; - adi,custom-thermocouple = /bits/ 64 - <(-50220000) 0>, - <(-30200000) 99100000>, - <(-5300000) 135400000>, - <0 273150000>, - <40200000 361200000>, - <55300000 522100000>, - <88300000 720300000>, - <132200000 811200000>, - <188700000 922500000>, - <460400000 1000000000>; //10 pairs + adi,custom-thermocouple = + /bits/ 64 <(-50220000) 0>, + /bits/ 64 <(-30200000) 99100000>, + /bits/ 64 <(-5300000) 135400000>, + /bits/ 64 <0 273150000>, + /bits/ 64 <40200000 361200000>, + /bits/ 64 <55300000 522100000>, + /bits/ 64 <88300000 720300000>, + /bits/ 64 <132200000 811200000>, + /bits/ 64 <188700000 922500000>, + /bits/ 64 <460400000 1000000000>; //10 pairs }; }; diff --git a/Documentation/devicetree/bindings/input/google,cros-ec-keyb.yaml b/Documentation/devicetree/bindings/input/google,cros-ec-keyb.yaml index 5377b232fa10..e8f137abb03c 100644 --- a/Documentation/devicetree/bindings/input/google,cros-ec-keyb.yaml +++ b/Documentation/devicetree/bindings/input/google,cros-ec-keyb.yaml @@ -10,7 +10,6 @@ title: ChromeOS EC Keyboard maintainers: - Simon Glass <sjg@chromium.org> - Benson Leung <bleung@chromium.org> - - Enric Balletbo i Serra <enric.balletbo@collabora.com> description: | Google's ChromeOS EC Keyboard is a simple matrix keyboard diff --git a/Documentation/devicetree/bindings/input/gpio-keys.yaml b/Documentation/devicetree/bindings/input/gpio-keys.yaml index 060a309ff8e7..7fe1966ea28a 100644 --- a/Documentation/devicetree/bindings/input/gpio-keys.yaml +++ b/Documentation/devicetree/bindings/input/gpio-keys.yaml @@ -88,12 +88,6 @@ patternProperties: which can be disabled to suppress events from the button. type: boolean - pinctrl-0: - maxItems: 1 - - pinctrl-names: - maxItems: 1 - required: - linux,code @@ -142,7 +136,7 @@ examples: down { label = "GPIO Key DOWN"; linux,code = <108>; - interrupts = <1 IRQ_TYPE_LEVEL_HIGH 7>; + interrupts = <1 IRQ_TYPE_EDGE_FALLING>; }; }; diff --git a/Documentation/devicetree/bindings/input/hid-over-i2c.txt b/Documentation/devicetree/bindings/input/hid-over-i2c.txt index c76bafaf98d2..34c43d3bddfd 100644 --- a/Documentation/devicetree/bindings/input/hid-over-i2c.txt +++ b/Documentation/devicetree/bindings/input/hid-over-i2c.txt @@ -32,6 +32,8 @@ device-specific compatible properties, which should be used in addition to the - vdd-supply: phandle of the regulator that provides the supply voltage. - post-power-on-delay-ms: time required by the device after enabling its regulators or powering it on, before it is ready for communication. +- touchscreen-inverted-x: See touchscreen.txt +- touchscreen-inverted-y: See touchscreen.txt Example: diff --git a/Documentation/devicetree/bindings/input/pwm-vibrator.txt b/Documentation/devicetree/bindings/input/pwm-vibrator.txt deleted file mode 100644 index 88c775a3fe21..000000000000 --- a/Documentation/devicetree/bindings/input/pwm-vibrator.txt +++ /dev/null @@ -1,66 +0,0 @@ -* PWM vibrator device tree bindings - -Registers a PWM device as vibrator. It is expected, that the vibrator's -strength increases based on the duty cycle of the enable PWM channel -(100% duty cycle meaning strongest vibration, 0% meaning no vibration). - -The binding supports an optional direction PWM channel, that can be -driven at fixed duty cycle. If available this is can be used to increase -the vibration effect of some devices. - -Required properties: -- compatible: should contain "pwm-vibrator" -- pwm-names: Should contain "enable" and optionally "direction" -- pwms: Should contain a PWM handle for each entry in pwm-names - -Optional properties: -- vcc-supply: Phandle for the regulator supplying power -- direction-duty-cycle-ns: Duty cycle of the direction PWM channel in - nanoseconds, defaults to 50% of the channel's - period. - -Example from Motorola Droid 4: - -&omap4_pmx_core { - vibrator_direction_pin: pinmux_vibrator_direction_pin { - pinctrl-single,pins = < - OMAP4_IOPAD(0x1ce, PIN_OUTPUT | MUX_MODE1) /* dmtimer8_pwm_evt (gpio_27) */ - >; - }; - - vibrator_enable_pin: pinmux_vibrator_enable_pin { - pinctrl-single,pins = < - OMAP4_IOPAD(0X1d0, PIN_OUTPUT | MUX_MODE1) /* dmtimer9_pwm_evt (gpio_28) */ - >; - }; -}; - -/ { - pwm8: dmtimer-pwm { - pinctrl-names = "default"; - pinctrl-0 = <&vibrator_direction_pin>; - - compatible = "ti,omap-dmtimer-pwm"; - #pwm-cells = <3>; - ti,timers = <&timer8>; - ti,clock-source = <0x01>; - }; - - pwm9: dmtimer-pwm { - pinctrl-names = "default"; - pinctrl-0 = <&vibrator_enable_pin>; - - compatible = "ti,omap-dmtimer-pwm"; - #pwm-cells = <3>; - ti,timers = <&timer9>; - ti,clock-source = <0x01>; - }; - - vibrator { - compatible = "pwm-vibrator"; - pwms = <&pwm9 0 1000000000 0>, - <&pwm8 0 1000000000 0>; - pwm-names = "enable", "direction"; - direction-duty-cycle-ns = <1000000000>; - }; -}; diff --git a/Documentation/devicetree/bindings/input/pwm-vibrator.yaml b/Documentation/devicetree/bindings/input/pwm-vibrator.yaml new file mode 100644 index 000000000000..a70a636ee112 --- /dev/null +++ b/Documentation/devicetree/bindings/input/pwm-vibrator.yaml @@ -0,0 +1,57 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: "http://devicetree.org/schemas/input/pwm-vibrator.yaml#" +$schema: "http://devicetree.org/meta-schemas/core.yaml#" + +title: PWM vibrator + +maintainers: + - Sebastian Reichel <sre@kernel.org> + +description: > + Registers a PWM device as vibrator. It is expected, that the vibrator's + strength increases based on the duty cycle of the enable PWM channel + (100% duty cycle meaning strongest vibration, 0% meaning no vibration). + + The binding supports an optional direction PWM channel, that can be + driven at fixed duty cycle. If available this is can be used to increase + the vibration effect of some devices. + +properties: + compatible: + const: pwm-vibrator + + pwm-names: + items: + - const: enable + - const: direction + minItems: 1 + + pwms: + minItems: 1 + maxItems: 2 + + vcc-supply: true + + direction-duty-cycle-ns: + description: > + Duty cycle of the direction PWM channel in nanoseconds, + defaults to 50% of the channel's period. + +required: + - compatible + - pwm-names + - pwms + +additionalProperties: false + +examples: + - | + vibrator { + compatible = "pwm-vibrator"; + pwms = <&pwm9 0 1000000000 0>, + <&pwm8 0 1000000000 0>; + pwm-names = "enable", "direction"; + direction-duty-cycle-ns = <1000000000>; + }; diff --git a/Documentation/devicetree/bindings/input/touchscreen/zinitix,bt400.yaml b/Documentation/devicetree/bindings/input/touchscreen/zinitix,bt400.yaml new file mode 100644 index 000000000000..b4e5ba7c0b49 --- /dev/null +++ b/Documentation/devicetree/bindings/input/touchscreen/zinitix,bt400.yaml @@ -0,0 +1,115 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/input/touchscreen/zinitix,bt400.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Zinitix BT4xx and BT5xx series touchscreen controller bindings + +description: The Zinitix BT4xx and BT5xx series of touchscreen controllers + are Korea-produced touchscreens with embedded microcontrollers. The + BT4xx series was produced 2010-2013 and the BT5xx series 2013-2014. + +maintainers: + - Michael Srba <Michael.Srba@seznam.cz> + - Linus Walleij <linus.walleij@linaro.org> + +allOf: + - $ref: touchscreen.yaml# + +properties: + $nodename: + pattern: "^touchscreen(@.*)?$" + + compatible: + enum: + - zinitix,bt402 + - zinitix,bt403 + - zinitix,bt404 + - zinitix,bt412 + - zinitix,bt413 + - zinitix,bt431 + - zinitix,bt432 + - zinitix,bt531 + - zinitix,bt532 + - zinitix,bt538 + - zinitix,bt541 + - zinitix,bt548 + - zinitix,bt554 + - zinitix,at100 + + reg: + description: I2C address on the I2C bus + + clock-frequency: + description: I2C client clock frequency, defined for host when using + the device on the I2C bus + minimum: 0 + maximum: 400000 + + interrupts: + description: Interrupt to host + maxItems: 1 + + vcca-supply: + description: Analog power supply regulator on the VCCA pin + + vdd-supply: + description: Digital power supply regulator on the VDD pin. + In older device trees this can be the accidental name for the analog + supply on the VCCA pin, and in that case the deprecated vddo-supply is + used for the digital power supply. + + vddo-supply: + description: Deprecated name for the digital power supply, use vdd-supply + as this reflects the real name of the pin. If this supply is present, + the vdd-supply represents VCCA instead of VDD. Implementers should first + check for this property, and if it is present assume that the vdd-supply + represents the analog supply. + deprecated: true + + reset-gpios: + description: Reset line for the touchscreen, should be tagged + as GPIO_ACTIVE_LOW + + zinitix,mode: + description: Mode of reporting touch points. Some modes may not work + with a particular ts firmware for unknown reasons. Available modes are + 1 and 2. Mode 2 is the default and preferred. + $ref: /schemas/types.yaml#/definitions/uint32 + enum: [1, 2] + + touchscreen-size-x: true + touchscreen-size-y: true + touchscreen-fuzz-x: true + touchscreen-fuzz-y: true + +additionalProperties: false + +required: + - compatible + - reg + - interrupts + - touchscreen-size-x + - touchscreen-size-y + +examples: + - | + #include <dt-bindings/interrupt-controller/irq.h> + #include <dt-bindings/gpio/gpio.h> + i2c { + #address-cells = <1>; + #size-cells = <0>; + + touchscreen@20 { + compatible = "zinitix,bt541"; + reg = <0x20>; + interrupt-parent = <&gpio>; + interrupts = <13 IRQ_TYPE_EDGE_FALLING>; + vcca-supply = <®_vcca_tsp>; + vdd-supply = <®_vdd_tsp>; + touchscreen-size-x = <540>; + touchscreen-size-y = <960>; + zinitix,mode = <2>; + }; + }; diff --git a/Documentation/devicetree/bindings/input/touchscreen/zinitix.txt b/Documentation/devicetree/bindings/input/touchscreen/zinitix.txt deleted file mode 100644 index 446efb9f5f55..000000000000 --- a/Documentation/devicetree/bindings/input/touchscreen/zinitix.txt +++ /dev/null @@ -1,40 +0,0 @@ -Device tree bindings for Zinitx BT541 touchscreen controller - -Required properties: - - - compatible : Should be "zinitix,bt541" - - reg : I2C address of the chip. Should be 0x20 - - interrupts : Interrupt to which the chip is connected - -Optional properties: - - - vdd-supply : Analog power supply regulator on VCCA pin - - vddo-supply : Digital power supply regulator on VDD pin - - zinitix,mode : Mode of reporting touch points. Some modes may not work - with a particular ts firmware for unknown reasons. Available - modes are 1 and 2. Mode 2 is the default and preferred. - -The touchscreen-* properties are documented in touchscreen.txt in this -directory. - -Example: - - i2c@00000000 { - /* ... */ - - bt541@20 { - compatible = "zinitix,bt541"; - reg = <0x20>; - interrupt-parent = <&msmgpio>; - interrupts = <13 IRQ_TYPE_EDGE_FALLING>; - pinctrl-names = "default"; - pinctrl-0 = <&tsp_default>; - vdd-supply = <®_vdd_tsp>; - vddo-supply = <&pm8916_l6>; - touchscreen-size-x = <540>; - touchscreen-size-y = <960>; - zinitix,mode = <2>; - }; - - /* ... */ - }; diff --git a/Documentation/devicetree/bindings/interconnect/qcom,osm-l3.yaml b/Documentation/devicetree/bindings/interconnect/qcom,osm-l3.yaml index e701524ee811..116e434d0daa 100644 --- a/Documentation/devicetree/bindings/interconnect/qcom,osm-l3.yaml +++ b/Documentation/devicetree/bindings/interconnect/qcom,osm-l3.yaml @@ -18,6 +18,7 @@ properties: compatible: enum: - qcom,sc7180-osm-l3 + - qcom,sc7280-epss-l3 - qcom,sc8180x-osm-l3 - qcom,sdm845-osm-l3 - qcom,sm8150-osm-l3 diff --git a/Documentation/devicetree/bindings/interconnect/qcom,qcm2290.yaml b/Documentation/devicetree/bindings/interconnect/qcom,qcm2290.yaml new file mode 100644 index 000000000000..f65a2fe846de --- /dev/null +++ b/Documentation/devicetree/bindings/interconnect/qcom,qcm2290.yaml @@ -0,0 +1,137 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/interconnect/qcom,qcm2290.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Qualcomm QCM2290 Network-On-Chip interconnect + +maintainers: + - Shawn Guo <shawn.guo@linaro.org> + +description: | + The Qualcomm QCM2290 interconnect providers support adjusting the + bandwidth requirements between the various NoC fabrics. + +properties: + reg: + maxItems: 1 + + compatible: + enum: + - qcom,qcm2290-bimc + - qcom,qcm2290-cnoc + - qcom,qcm2290-snoc + + '#interconnect-cells': + const: 1 + + clock-names: + items: + - const: bus + - const: bus_a + + clocks: + items: + - description: Bus Clock + - description: Bus A Clock + +# Child node's properties +patternProperties: + '^interconnect-[a-z0-9]+$': + type: object + description: + The interconnect providers do not have a separate QoS register space, + but share parent's space. + + properties: + compatible: + enum: + - qcom,qcm2290-qup-virt + - qcom,qcm2290-mmrt-virt + - qcom,qcm2290-mmnrt-virt + + '#interconnect-cells': + const: 1 + + clock-names: + items: + - const: bus + - const: bus_a + + clocks: + items: + - description: Bus Clock + - description: Bus A Clock + + required: + - compatible + - '#interconnect-cells' + - clock-names + - clocks + + additionalProperties: false + +required: + - compatible + - reg + - '#interconnect-cells' + - clock-names + - clocks + +additionalProperties: false + +examples: + - | + #include <dt-bindings/clock/qcom,rpmcc.h> + + snoc: interconnect@1880000 { + compatible = "qcom,qcm2290-snoc"; + reg = <0x01880000 0x60200>; + #interconnect-cells = <1>; + clock-names = "bus", "bus_a"; + clocks = <&rpmcc RPM_SMD_SNOC_CLK>, + <&rpmcc RPM_SMD_SNOC_A_CLK>; + + qup_virt: interconnect-qup { + compatible = "qcom,qcm2290-qup-virt"; + #interconnect-cells = <1>; + clock-names = "bus", "bus_a"; + clocks = <&rpmcc RPM_SMD_QUP_CLK>, + <&rpmcc RPM_SMD_QUP_A_CLK>; + }; + + mmnrt_virt: interconnect-mmnrt { + compatible = "qcom,qcm2290-mmnrt-virt"; + #interconnect-cells = <1>; + clock-names = "bus", "bus_a"; + clocks = <&rpmcc RPM_SMD_MMNRT_CLK>, + <&rpmcc RPM_SMD_MMNRT_A_CLK>; + }; + + mmrt_virt: interconnect-mmrt { + compatible = "qcom,qcm2290-mmrt-virt"; + #interconnect-cells = <1>; + clock-names = "bus", "bus_a"; + clocks = <&rpmcc RPM_SMD_MMRT_CLK>, + <&rpmcc RPM_SMD_MMRT_A_CLK>; + }; + }; + + cnoc: interconnect@1900000 { + compatible = "qcom,qcm2290-cnoc"; + reg = <0x01900000 0x8200>; + #interconnect-cells = <1>; + clock-names = "bus", "bus_a"; + clocks = <&rpmcc RPM_SMD_CNOC_CLK>, + <&rpmcc RPM_SMD_CNOC_A_CLK>; + }; + + bimc: interconnect@4480000 { + compatible = "qcom,qcm2290-bimc"; + reg = <0x04480000 0x80000>; + #interconnect-cells = <1>; + clock-names = "bus", "bus_a"; + clocks = <&rpmcc RPM_SMD_BIMC_CLK>, + <&rpmcc RPM_SMD_BIMC_A_CLK>; + }; diff --git a/Documentation/devicetree/bindings/interconnect/qcom,rpm.yaml b/Documentation/devicetree/bindings/interconnect/qcom,rpm.yaml index 983d71fb5399..e4c3c2818119 100644 --- a/Documentation/devicetree/bindings/interconnect/qcom,rpm.yaml +++ b/Documentation/devicetree/bindings/interconnect/qcom,rpm.yaml @@ -27,22 +27,37 @@ properties: - qcom,msm8939-pcnoc - qcom,msm8939-snoc - qcom,msm8939-snoc-mm + - qcom,msm8996-a0noc + - qcom,msm8996-a1noc + - qcom,msm8996-a2noc + - qcom,msm8996-bimc + - qcom,msm8996-cnoc + - qcom,msm8996-mnoc + - qcom,msm8996-pnoc + - qcom,msm8996-snoc - qcom,qcs404-bimc - qcom,qcs404-pcnoc - qcom,qcs404-snoc + - qcom,sdm660-a2noc + - qcom,sdm660-bimc + - qcom,sdm660-cnoc + - qcom,sdm660-gnoc + - qcom,sdm660-mnoc + - qcom,sdm660-snoc '#interconnect-cells': const: 1 + clocks: + minItems: 2 + maxItems: 7 + clock-names: - items: - - const: bus - - const: bus_a + minItems: 2 + maxItems: 7 - clocks: - items: - - description: Bus Clock - - description: Bus A Clock + power-domains: + maxItems: 1 required: - compatible @@ -53,6 +68,120 @@ required: additionalProperties: false +allOf: + - if: + properties: + compatible: + contains: + enum: + - qcom,msm8916-bimc + - qcom,msm8916-pcnoc + - qcom,msm8916-snoc + - qcom,msm8939-bimc + - qcom,msm8939-pcnoc + - qcom,msm8939-snoc + - qcom,msm8939-snoc-mm + - qcom,msm8996-a1noc + - qcom,msm8996-a2noc + - qcom,msm8996-bimc + - qcom,msm8996-cnoc + - qcom,msm8996-pnoc + - qcom,msm8996-snoc + - qcom,qcs404-bimc + - qcom,qcs404-pcnoc + - qcom,qcs404-snoc + - qcom,sdm660-bimc + - qcom,sdm660-cnoc + - qcom,sdm660-gnoc + - qcom,sdm660-snoc + + then: + properties: + clock-names: + items: + - const: bus + - const: bus_a + + clocks: + items: + - description: Bus Clock + - description: Bus A Clock + + - if: + properties: + compatible: + contains: + enum: + - qcom,msm8996-mnoc + - qcom,sdm660-mnoc + + then: + properties: + clock-names: + items: + - const: bus + - const: bus_a + - const: iface + + clocks: + items: + - description: Bus Clock. + - description: Bus A Clock. + - description: CPU-NoC High-performance Bus Clock. + + - if: + properties: + compatible: + contains: + enum: + - qcom,msm8996-a0noc + + then: + properties: + clock-names: + items: + - const: aggre0_snoc_axi + - const: aggre0_cnoc_ahb + - const: aggre0_noc_mpu_cfg + + clocks: + items: + - description: Aggregate0 System NoC AXI Clock. + - description: Aggregate0 Config NoC AHB Clock. + - description: Aggregate0 NoC MPU Clock. + + required: + - power-domains + + - if: + properties: + compatible: + contains: + enum: + - qcom,sdm660-a2noc + + then: + properties: + clock-names: + items: + - const: bus + - const: bus_a + - const: ipa + - const: ufs_axi + - const: aggre2_ufs_axi + - const: aggre2_usb3_axi + - const: cfg_noc_usb2_axi + + clocks: + items: + - description: Bus Clock. + - description: Bus A Clock. + - description: IPA Clock. + - description: UFS AXI Clock. + - description: Aggregate2 UFS AXI Clock. + - description: Aggregate2 USB3 AXI Clock. + - description: Config NoC USB2 AXI Clock. + examples: - | #include <dt-bindings/clock/qcom,rpmcc.h> diff --git a/Documentation/devicetree/bindings/interconnect/qcom,rpmh.yaml b/Documentation/devicetree/bindings/interconnect/qcom,rpmh.yaml index 3fd1a134162d..cbb24f9bb609 100644 --- a/Documentation/devicetree/bindings/interconnect/qcom,rpmh.yaml +++ b/Documentation/devicetree/bindings/interconnect/qcom,rpmh.yaml @@ -104,6 +104,17 @@ properties: - qcom,sm8350-mmss-noc - qcom,sm8350-compute-noc - qcom,sm8350-system-noc + - qcom,sm8450-aggre1-noc + - qcom,sm8450-aggre2-noc + - qcom,sm8450-clk-virt + - qcom,sm8450-config-noc + - qcom,sm8450-gem-noc + - qcom,sm8450-lpass-ag-noc + - qcom,sm8450-mc-virt + - qcom,sm8450-mmss-noc + - qcom,sm8450-nsp-noc + - qcom,sm8450-pcie-anoc + - qcom,sm8450-system-noc '#interconnect-cells': enum: [ 1, 2 ] diff --git a/Documentation/devicetree/bindings/interconnect/qcom,sdm660.yaml b/Documentation/devicetree/bindings/interconnect/qcom,sdm660.yaml deleted file mode 100644 index bcd41e491f1d..000000000000 --- a/Documentation/devicetree/bindings/interconnect/qcom,sdm660.yaml +++ /dev/null @@ -1,185 +0,0 @@ -# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) -%YAML 1.2 ---- -$id: http://devicetree.org/schemas/interconnect/qcom,sdm660.yaml# -$schema: http://devicetree.org/meta-schemas/core.yaml# - -title: Qualcomm SDM660 Network-On-Chip interconnect - -maintainers: - - AngeloGioacchino Del Regno <kholk11@gmail.com> - -description: | - The Qualcomm SDM660 interconnect providers support adjusting the - bandwidth requirements between the various NoC fabrics. - -properties: - reg: - maxItems: 1 - - compatible: - enum: - - qcom,sdm660-a2noc - - qcom,sdm660-bimc - - qcom,sdm660-cnoc - - qcom,sdm660-gnoc - - qcom,sdm660-mnoc - - qcom,sdm660-snoc - - '#interconnect-cells': - const: 1 - - clocks: - minItems: 1 - maxItems: 7 - - clock-names: - minItems: 1 - maxItems: 7 - -required: - - compatible - - reg - - '#interconnect-cells' - - clock-names - - clocks - -additionalProperties: false - -allOf: - - if: - properties: - compatible: - contains: - enum: - - qcom,sdm660-mnoc - then: - properties: - clocks: - items: - - description: Bus Clock. - - description: Bus A Clock. - - description: CPU-NoC High-performance Bus Clock. - clock-names: - items: - - const: bus - - const: bus_a - - const: iface - - - if: - properties: - compatible: - contains: - enum: - - qcom,sdm660-a2noc - then: - properties: - clocks: - items: - - description: Bus Clock. - - description: Bus A Clock. - - description: IPA Clock. - - description: UFS AXI Clock. - - description: Aggregate2 UFS AXI Clock. - - description: Aggregate2 USB3 AXI Clock. - - description: Config NoC USB2 AXI Clock. - clock-names: - items: - - const: bus - - const: bus_a - - const: ipa - - const: ufs_axi - - const: aggre2_ufs_axi - - const: aggre2_usb3_axi - - const: cfg_noc_usb2_axi - - - if: - properties: - compatible: - contains: - enum: - - qcom,sdm660-bimc - - qcom,sdm660-cnoc - - qcom,sdm660-gnoc - - qcom,sdm660-snoc - then: - properties: - clocks: - items: - - description: Bus Clock. - - description: Bus A Clock. - clock-names: - items: - - const: bus - - const: bus_a - -examples: - - | - #include <dt-bindings/clock/qcom,rpmcc.h> - #include <dt-bindings/clock/qcom,mmcc-sdm660.h> - #include <dt-bindings/clock/qcom,gcc-sdm660.h> - - bimc: interconnect@1008000 { - compatible = "qcom,sdm660-bimc"; - reg = <0x01008000 0x78000>; - #interconnect-cells = <1>; - clock-names = "bus", "bus_a"; - clocks = <&rpmcc RPM_SMD_BIMC_CLK>, - <&rpmcc RPM_SMD_BIMC_A_CLK>; - }; - - cnoc: interconnect@1500000 { - compatible = "qcom,sdm660-cnoc"; - reg = <0x01500000 0x10000>; - #interconnect-cells = <1>; - clock-names = "bus", "bus_a"; - clocks = <&rpmcc RPM_SMD_CNOC_CLK>, - <&rpmcc RPM_SMD_CNOC_A_CLK>; - }; - - snoc: interconnect@1626000 { - compatible = "qcom,sdm660-snoc"; - reg = <0x01626000 0x7090>; - #interconnect-cells = <1>; - clock-names = "bus", "bus_a"; - clocks = <&rpmcc RPM_SMD_SNOC_CLK>, - <&rpmcc RPM_SMD_SNOC_A_CLK>; - }; - - a2noc: interconnect@1704000 { - compatible = "qcom,sdm660-a2noc"; - reg = <0x01704000 0xc100>; - #interconnect-cells = <1>; - clock-names = "bus", - "bus_a", - "ipa", - "ufs_axi", - "aggre2_ufs_axi", - "aggre2_usb3_axi", - "cfg_noc_usb2_axi"; - clocks = <&rpmcc RPM_SMD_AGGR2_NOC_CLK>, - <&rpmcc RPM_SMD_AGGR2_NOC_A_CLK>, - <&rpmcc RPM_SMD_IPA_CLK>, - <&gcc GCC_UFS_AXI_CLK>, - <&gcc GCC_AGGRE2_UFS_AXI_CLK>, - <&gcc GCC_AGGRE2_USB3_AXI_CLK>, - <&gcc GCC_CFG_NOC_USB2_AXI_CLK>; - }; - - mnoc: interconnect@1745000 { - compatible = "qcom,sdm660-mnoc"; - reg = <0x01745000 0xa010>; - #interconnect-cells = <1>; - clock-names = "bus", "bus_a", "iface"; - clocks = <&rpmcc RPM_SMD_MMSSNOC_AXI_CLK>, - <&rpmcc RPM_SMD_MMSSNOC_AXI_CLK_A>, - <&mmcc AHB_CLK_SRC>; - }; - - gnoc: interconnect@17900000 { - compatible = "qcom,sdm660-gnoc"; - reg = <0x17900000 0xe000>; - #interconnect-cells = <1>; - clock-names = "bus", "bus_a"; - clocks = <&xo_board>, <&xo_board>; - }; diff --git a/Documentation/devicetree/bindings/interrupt-controller/apple,aic.yaml b/Documentation/devicetree/bindings/interrupt-controller/apple,aic.yaml index cf6c091a07b1..97359024709a 100644 --- a/Documentation/devicetree/bindings/interrupt-controller/apple,aic.yaml +++ b/Documentation/devicetree/bindings/interrupt-controller/apple,aic.yaml @@ -65,6 +65,9 @@ properties: Specifies base physical address and size of the AIC registers. maxItems: 1 + power-domains: + maxItems: 1 + required: - compatible - '#interrupt-cells' diff --git a/Documentation/devicetree/bindings/interrupt-controller/arm,gic-v3.yaml b/Documentation/devicetree/bindings/interrupt-controller/arm,gic-v3.yaml index c84f9fe7f254..cfb3ec27bd2b 100644 --- a/Documentation/devicetree/bindings/interrupt-controller/arm,gic-v3.yaml +++ b/Documentation/devicetree/bindings/interrupt-controller/arm,gic-v3.yaml @@ -239,6 +239,7 @@ examples: }; }; + - | interrupt-controller@2c010000 { compatible = "arm,gic-v3"; #interrupt-cells = <4>; @@ -254,7 +255,7 @@ examples: <0x2c040000 0x2000>, // GICC <0x2c060000 0x2000>, // GICH <0x2c080000 0x2000>; // GICV - interrupts = <1 9 4>; + interrupts = <1 9 4 0>; msi-controller@2c200000 { compatible = "arm,gic-v3-its"; diff --git a/Documentation/devicetree/bindings/interrupt-controller/brcm,bcm3380-l2-intc.txt b/Documentation/devicetree/bindings/interrupt-controller/brcm,bcm3380-l2-intc.txt deleted file mode 100644 index 37aea40d5430..000000000000 --- a/Documentation/devicetree/bindings/interrupt-controller/brcm,bcm3380-l2-intc.txt +++ /dev/null @@ -1,39 +0,0 @@ -Broadcom BCM3380-style Level 1 / Level 2 interrupt controller - -This interrupt controller shows up in various forms on many BCM338x/BCM63xx -chipsets. It has the following properties: - -- outputs a single interrupt signal to its interrupt controller parent - -- contains one or more enable/status word pairs, which often appear at - different offsets in different blocks - -- no atomic set/clear operations - -Required properties: - -- compatible: should be "brcm,bcm3380-l2-intc" -- reg: specifies one or more enable/status pairs, in the following format: - <enable_reg 0x4 status_reg 0x4>... -- interrupt-controller: identifies the node as an interrupt controller -- #interrupt-cells: specifies the number of cells needed to encode an interrupt - source, should be 1. -- interrupts: specifies the interrupt line in the interrupt-parent controller - node, valid values depend on the type of parent interrupt controller - -Optional properties: - -- brcm,irq-can-wake: if present, this means the L2 controller can be used as a - wakeup source for system suspend/resume. - -Example: - -irq0_intc: interrupt-controller@10000020 { - compatible = "brcm,bcm3380-l2-intc"; - reg = <0x10000024 0x4 0x1000002c 0x4>, - <0x10000020 0x4 0x10000028 0x4>; - interrupt-controller; - #interrupt-cells = <1>; - interrupt-parent = <&cpu_intc>; - interrupts = <2>; -}; diff --git a/Documentation/devicetree/bindings/interrupt-controller/brcm,bcm7038-l1-intc.txt b/Documentation/devicetree/bindings/interrupt-controller/brcm,bcm7038-l1-intc.txt deleted file mode 100644 index 5ddef1dc0c1a..000000000000 --- a/Documentation/devicetree/bindings/interrupt-controller/brcm,bcm7038-l1-intc.txt +++ /dev/null @@ -1,61 +0,0 @@ -Broadcom BCM7038-style Level 1 interrupt controller - -This block is a first level interrupt controller that is typically connected -directly to one of the HW INT lines on each CPU. Every BCM7xxx set-top chip -since BCM7038 has contained this hardware. - -Key elements of the hardware design include: - -- 64, 96, 128, or 160 incoming level IRQ lines - -- Most onchip peripherals are wired directly to an L1 input - -- A separate instance of the register set for each CPU, allowing individual - peripheral IRQs to be routed to any CPU - -- Atomic mask/unmask operations - -- No polarity/level/edge settings - -- No FIFO or priority encoder logic; software is expected to read all - 2-5 status words to determine which IRQs are pending - -Required properties: - -- compatible: should be "brcm,bcm7038-l1-intc" -- reg: specifies the base physical address and size of the registers; - the number of supported IRQs is inferred from the size argument -- interrupt-controller: identifies the node as an interrupt controller -- #interrupt-cells: specifies the number of cells needed to encode an interrupt - source, should be 1. -- interrupts: specifies the interrupt line(s) in the interrupt-parent controller - node; valid values depend on the type of parent interrupt controller - -Optional properties: - -- brcm,irq-can-wake: If present, this means the L1 controller can be used as a - wakeup source for system suspend/resume. - -Optional properties: - -- brcm,int-fwd-mask: if present, a bit mask to indicate which interrupts - have already been configured by the firmware and should be left unmanaged. - This should have one 32-bit word per status/set/clear/mask group. - -If multiple reg ranges and interrupt-parent entries are present on an SMP -system, the driver will allow IRQ SMP affinity to be set up through the -/proc/irq/ interface. In the simplest possible configuration, only one -reg range and one interrupt-parent is needed. - -Example: - -periph_intc: periph_intc@1041a400 { - compatible = "brcm,bcm7038-l1-intc"; - reg = <0x1041a400 0x30 0x1041a600 0x30>; - - interrupt-controller; - #interrupt-cells = <1>; - - interrupt-parent = <&cpu_intc>; - interrupts = <2>, <3>; -}; diff --git a/Documentation/devicetree/bindings/interrupt-controller/brcm,bcm7038-l1-intc.yaml b/Documentation/devicetree/bindings/interrupt-controller/brcm,bcm7038-l1-intc.yaml new file mode 100644 index 000000000000..5ecb6faa70dc --- /dev/null +++ b/Documentation/devicetree/bindings/interrupt-controller/brcm,bcm7038-l1-intc.yaml @@ -0,0 +1,91 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/interrupt-controller/brcm,bcm7038-l1-intc.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Broadcom BCM7038-style Level 1 interrupt controller + +description: > + This block is a first level interrupt controller that is typically connected + directly to one of the HW INT lines on each CPU. Every BCM7xxx set-top chip + since BCM7038 has contained this hardware. + + Key elements of the hardware design include: + + - 64, 96, 128, or 160 incoming level IRQ lines + + - Most onchip peripherals are wired directly to an L1 input + + - A separate instance of the register set for each CPU, allowing individual + peripheral IRQs to be routed to any CPU + + - Atomic mask/unmask operations + + - No polarity/level/edge settings + + - No FIFO or priority encoder logic; software is expected to read all + 2-5 status words to determine which IRQs are pending + + If multiple reg ranges and interrupt-parent entries are present on an SMP + system, the driver will allow IRQ SMP affinity to be set up through the + /proc/irq/ interface. In the simplest possible configuration, only one + reg range and one interrupt-parent is needed. + +maintainers: + - Florian Fainelli <f.fainelli@gmail.com> + +allOf: + - $ref: /schemas/interrupt-controller.yaml# + +properties: + compatible: + const: brcm,bcm7038-l1-intc + + reg: + description: > + Specifies the base physical address and size of the registers + the number of supported IRQs is inferred from the size argument + + interrupt-controller: true + + "#interrupt-cells": + const: 1 + + interrupts: + description: > + Specifies the interrupt line(s) in the interrupt-parent controller node; + valid values depend on the type of parent interrupt controller + + brcm,irq-can-wake: + type: boolean + description: > + If present, this means the L1 controller can be used as a + wakeup source for system suspend/resume. + + brcm,int-fwd-mask: + $ref: /schemas/types.yaml#/definitions/uint32-array + description: + If present, a bit mask to indicate which interrupts have already been + configured by the firmware and should be left unmanaged. This should + have one 32-bit word per status/set/clear/mask group. + +required: + - compatible + - reg + - interrupt-controller + - "#interrupt-cells" + - interrupts + +additionalProperties: false + +examples: + - | + periph_intc: interrupt-controller@1041a400 { + compatible = "brcm,bcm7038-l1-intc"; + reg = <0x1041a400 0x30>, <0x1041a600 0x30>; + interrupt-controller; + #interrupt-cells = <1>; + interrupt-parent = <&cpu_intc>; + interrupts = <2>, <3>; + }; diff --git a/Documentation/devicetree/bindings/interrupt-controller/brcm,bcm7120-l2-intc.txt b/Documentation/devicetree/bindings/interrupt-controller/brcm,bcm7120-l2-intc.txt deleted file mode 100644 index addd86b6ca2f..000000000000 --- a/Documentation/devicetree/bindings/interrupt-controller/brcm,bcm7120-l2-intc.txt +++ /dev/null @@ -1,88 +0,0 @@ -Broadcom BCM7120-style Level 2 interrupt controller - -This interrupt controller hardware is a second level interrupt controller that -is hooked to a parent interrupt controller: e.g: ARM GIC for ARM-based -platforms. It can be found on BCM7xxx products starting with BCM7120. - -Such an interrupt controller has the following hardware design: - -- outputs multiple interrupts signals towards its interrupt controller parent - -- controls how some of the interrupts will be flowing, whether they will - directly output an interrupt signal towards the interrupt controller parent, - or if they will output an interrupt signal at this 2nd level interrupt - controller, in particular for UARTs - -- has one 32-bit enable word and one 32-bit status word - -- no atomic set/clear operations - -- not all bits within the interrupt controller actually map to an interrupt - -The typical hardware layout for this controller is represented below: - -2nd level interrupt line Outputs for the parent controller (e.g: ARM GIC) - -0 -----[ MUX ] ------------|==========> GIC interrupt 75 - \-----------\ - | -1 -----[ MUX ] --------)---|==========> GIC interrupt 76 - \------------| - | -2 -----[ MUX ] --------)---|==========> GIC interrupt 77 - \------------| - | -3 ---------------------| -4 ---------------------| -5 ---------------------| -7 ---------------------|---|===========> GIC interrupt 66 -9 ---------------------| -10 --------------------| -11 --------------------/ - -6 ------------------------\ - |===========> GIC interrupt 64 -8 ------------------------/ - -12 ........................ X -13 ........................ X (not connected) -.. -31 ........................ X - -Required properties: - -- compatible: should be "brcm,bcm7120-l2-intc" -- reg: specifies the base physical address and size of the registers -- interrupt-controller: identifies the node as an interrupt controller -- #interrupt-cells: specifies the number of cells needed to encode an interrupt - source, should be 1. -- interrupts: specifies the interrupt line(s) in the interrupt-parent controller - node, valid values depend on the type of parent interrupt controller -- brcm,int-map-mask: 32-bits bit mask describing how many and which interrupts - are wired to this 2nd level interrupt controller, and how they match their - respective interrupt parents. Should match exactly the number of interrupts - specified in the 'interrupts' property. - -Optional properties: - -- brcm,irq-can-wake: if present, this means the L2 controller can be used as a - wakeup source for system suspend/resume. - -- brcm,int-fwd-mask: if present, a bit mask to configure the interrupts which - have a mux gate, typically UARTs. Setting these bits will make their - respective interrupt outputs bypass this 2nd level interrupt controller - completely; it is completely transparent for the interrupt controller - parent. This should have one 32-bit word per enable/status pair. - -Example: - -irq0_intc: interrupt-controller@f0406800 { - compatible = "brcm,bcm7120-l2-intc"; - interrupt-parent = <&intc>; - #interrupt-cells = <1>; - reg = <0xf0406800 0x8>; - interrupt-controller; - interrupts = <0x0 0x42 0x0>, <0x0 0x40 0x0>; - brcm,int-map-mask = <0xeb8>, <0x140>; - brcm,int-fwd-mask = <0x7>; -}; diff --git a/Documentation/devicetree/bindings/interrupt-controller/brcm,bcm7120-l2-intc.yaml b/Documentation/devicetree/bindings/interrupt-controller/brcm,bcm7120-l2-intc.yaml new file mode 100644 index 000000000000..46b2eb3c43ee --- /dev/null +++ b/Documentation/devicetree/bindings/interrupt-controller/brcm,bcm7120-l2-intc.yaml @@ -0,0 +1,151 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/interrupt-controller/brcm,bcm7120-l2-intc.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Broadcom BCM7120-style Level 2 and Broadcom BCM3380 Level 1 / Level 2 + +maintainers: + - Florian Fainelli <f.fainelli@gmail.com> + +description: > + This interrupt controller hardware is a second level interrupt controller that + is hooked to a parent interrupt controller: e.g: ARM GIC for ARM-based + platforms. It can be found on BCM7xxx products starting with BCM7120. + + Such an interrupt controller has the following hardware design: + + - outputs multiple interrupts signals towards its interrupt controller parent + + - controls how some of the interrupts will be flowing, whether they will + directly output an interrupt signal towards the interrupt controller parent, + or if they will output an interrupt signal at this 2nd level interrupt + controller, in particular for UARTs + + - has one 32-bit enable word and one 32-bit status word + + - no atomic set/clear operations + + - not all bits within the interrupt controller actually map to an interrupt + + The typical hardware layout for this controller is represented below: + + 2nd level interrupt line Outputs for the parent controller (e.g: ARM GIC) + + 0 -----[ MUX ] ------------|==========> GIC interrupt 75 + \-----------\ + | + 1 -----[ MUX ] --------)---|==========> GIC interrupt 76 + \------------| + | + 2 -----[ MUX ] --------)---|==========> GIC interrupt 77 + \------------| + | + 3 ---------------------| + 4 ---------------------| + 5 ---------------------| + 7 ---------------------|---|===========> GIC interrupt 66 + 9 ---------------------| + 10 --------------------| + 11 --------------------/ + + 6 ------------------------\ + |===========> GIC interrupt 64 + 8 ------------------------/ + + 12 ........................ X + 13 ........................ X (not connected) + .. + 31 ........................ X + + The BCM3380 Level 1 / Level 2 interrrupt controller shows up in various forms + on many BCM338x/BCM63xx chipsets. It has the following properties: + + - outputs a single interrupt signal to its interrupt controller parent + + - contains one or more enable/status word pairs, which often appear at + different offsets in different blocks + + - no atomic set/clear operations + +allOf: + - $ref: /schemas/interrupt-controller.yaml# + +properties: + compatible: + items: + - enum: + - brcm,bcm7120-l2-intc + - brcm,bcm3380-l2-intc + + reg: + minItems: 1 + maxItems: 4 + description: > + Specifies the base physical address and size of the registers + + interrupt-controller: true + + "#interrupt-cells": + const: 1 + + interrupts: + minItems: 1 + maxItems: 32 + + brcm,int-map-mask: + $ref: /schemas/types.yaml#/definitions/uint32-array + description: > + 32-bits bit mask describing how many and which interrupts are wired to + this 2nd level interrupt controller, and how they match their respective + interrupt parents. Should match exactly the number of interrupts + specified in the 'interrupts' property. + + brcm,irq-can-wake: + type: boolean + description: > + If present, this means the L2 controller can be used as a wakeup source + for system suspend/resume. + + brcm,int-fwd-mask: + $ref: /schemas/types.yaml#/definitions/uint32 + description: > + if present, a bit mask to configure the interrupts which have a mux gate, + typically UARTs. Setting these bits will make their respective interrupt + outputs bypass this 2nd level interrupt controller completely; it is + completely transparent for the interrupt controller parent. This should + have one 32-bit word per enable/status pair. + +additionalProperties: false + +required: + - compatible + - reg + - interrupt-controller + - "#interrupt-cells" + - interrupts + +examples: + - | + irq0_intc: interrupt-controller@f0406800 { + compatible = "brcm,bcm7120-l2-intc"; + interrupt-parent = <&intc>; + #interrupt-cells = <1>; + reg = <0xf0406800 0x8>; + interrupt-controller; + interrupts = <0x0 0x42 0x0>, <0x0 0x40 0x0>; + brcm,int-map-mask = <0xeb8>, <0x140>; + brcm,int-fwd-mask = <0x7>; + }; + + - | + irq1_intc: interrupt-controller@10000020 { + compatible = "brcm,bcm3380-l2-intc"; + reg = <0x10000024 0x4>, <0x1000002c 0x4>, + <0x10000020 0x4>, <0x10000028 0x4>; + interrupt-controller; + #interrupt-cells = <1>; + interrupt-parent = <&cpu_intc>; + interrupts = <2>; + }; diff --git a/Documentation/devicetree/bindings/interrupt-controller/brcm,l2-intc.txt b/Documentation/devicetree/bindings/interrupt-controller/brcm,l2-intc.txt deleted file mode 100644 index 021cf822395c..000000000000 --- a/Documentation/devicetree/bindings/interrupt-controller/brcm,l2-intc.txt +++ /dev/null @@ -1,31 +0,0 @@ -Broadcom Generic Level 2 Interrupt Controller - -Required properties: - -- compatible: should be one of: - "brcm,hif-spi-l2-intc" or - "brcm,upg-aux-aon-l2-intc" or - "brcm,l2-intc" for latched interrupt controllers - should be "brcm,bcm7271-l2-intc" for level interrupt controllers -- reg: specifies the base physical address and size of the registers -- interrupt-controller: identifies the node as an interrupt controller -- #interrupt-cells: specifies the number of cells needed to encode an - interrupt source. Should be 1. -- interrupts: specifies the interrupt line in the interrupt-parent irq space - to be used for cascading - -Optional properties: - -- brcm,irq-can-wake: If present, this means the L2 controller can be used as a - wakeup source for system suspend/resume. - -Example: - -hif_intr2_intc: interrupt-controller@f0441000 { - compatible = "brcm,l2-intc"; - reg = <0xf0441000 0x30>; - interrupt-controller; - #interrupt-cells = <1>; - interrupt-parent = <&intc>; - interrupts = <0x0 0x20 0x0>; -}; diff --git a/Documentation/devicetree/bindings/interrupt-controller/brcm,l2-intc.yaml b/Documentation/devicetree/bindings/interrupt-controller/brcm,l2-intc.yaml new file mode 100644 index 000000000000..8961afca96f1 --- /dev/null +++ b/Documentation/devicetree/bindings/interrupt-controller/brcm,l2-intc.yaml @@ -0,0 +1,72 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/interrupt-controller/brcm,l2-intc.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Broadcom Generic Level 2 Interrupt Controller + +maintainers: + - Florian Fainelli <f.fainelli@gmail.com> + +allOf: + - $ref: /schemas/interrupt-controller.yaml# + +properties: + compatible: + oneOf: + - items: + - enum: + - brcm,hif-spi-l2-intc + - brcm,upg-aux-aon-l2-intc + - const: brcm,l2-intc + - items: + - enum: + - brcm,bcm2711-l2-intc + - const: brcm,l2-intc + - items: + - const: brcm,bcm7271-l2-intc + - items: + - const: brcm,l2-intc + + reg: + maxItems: 1 + description: > + Specifies the base physical address and size of the registers + + interrupt-controller: true + + "#interrupt-cells": + const: 1 + + interrupts: + maxItems: 1 + + interrupt-names: + maxItems: 1 + + brcm,irq-can-wake: + type: boolean + description: > + If present, this means the L2 controller can be used as a wakeup source + for system suspend/resume. + +additionalProperties: false + +required: + - compatible + - reg + - interrupt-controller + - "#interrupt-cells" + - interrupts + +examples: + - | + hif_intr2_intc: interrupt-controller@f0441000 { + compatible = "brcm,l2-intc"; + reg = <0xf0441000 0x30>; + interrupt-controller; + #interrupt-cells = <1>; + interrupt-parent = <&intc>; + interrupts = <0x0 0x20 0x0>; + }; diff --git a/Documentation/devicetree/bindings/interrupt-controller/renesas,irqc.yaml b/Documentation/devicetree/bindings/interrupt-controller/renesas,irqc.yaml index 79d0358e2f61..620f01775e42 100644 --- a/Documentation/devicetree/bindings/interrupt-controller/renesas,irqc.yaml +++ b/Documentation/devicetree/bindings/interrupt-controller/renesas,irqc.yaml @@ -36,6 +36,7 @@ properties: - renesas,intc-ex-r8a77980 # R-Car V3H - renesas,intc-ex-r8a77990 # R-Car E3 - renesas,intc-ex-r8a77995 # R-Car D3 + - renesas,intc-ex-r8a779a0 # R-Car V3U - const: renesas,irqc '#interrupt-cells': diff --git a/Documentation/devicetree/bindings/interrupt-controller/sifive,plic-1.0.0.yaml b/Documentation/devicetree/bindings/interrupt-controller/sifive,plic-1.0.0.yaml index 08d5a57ce00f..0dfa6b26e099 100644 --- a/Documentation/devicetree/bindings/interrupt-controller/sifive,plic-1.0.0.yaml +++ b/Documentation/devicetree/bindings/interrupt-controller/sifive,plic-1.0.0.yaml @@ -45,6 +45,7 @@ properties: items: - enum: - sifive,fu540-c000-plic + - starfive,jh7100-plic - canaan,k210-plic - const: sifive,plic-1.0.0 @@ -61,6 +62,7 @@ properties: interrupts-extended: minItems: 1 + maxItems: 15872 description: Specifies which contexts are connected to the PLIC, with "-1" specifying that a context is not present. Each node pointed to should be a @@ -89,12 +91,11 @@ examples: #interrupt-cells = <1>; compatible = "sifive,fu540-c000-plic", "sifive,plic-1.0.0"; interrupt-controller; - interrupts-extended = < - &cpu0_intc 11 - &cpu1_intc 11 &cpu1_intc 9 - &cpu2_intc 11 &cpu2_intc 9 - &cpu3_intc 11 &cpu3_intc 9 - &cpu4_intc 11 &cpu4_intc 9>; + interrupts-extended = <&cpu0_intc 11>, + <&cpu1_intc 11>, <&cpu1_intc 9>, + <&cpu2_intc 11>, <&cpu2_intc 9>, + <&cpu3_intc 11>, <&cpu3_intc 9>, + <&cpu4_intc 11>, <&cpu4_intc 9>; reg = <0xc000000 0x4000000>; riscv,ndev = <10>; }; diff --git a/Documentation/devicetree/bindings/iommu/apple,dart.yaml b/Documentation/devicetree/bindings/iommu/apple,dart.yaml index 94aa9e9afa59..82ad669feef7 100644 --- a/Documentation/devicetree/bindings/iommu/apple,dart.yaml +++ b/Documentation/devicetree/bindings/iommu/apple,dart.yaml @@ -41,6 +41,9 @@ properties: Has to be one. The single cell describes the stream id emitted by a master to the IOMMU. + power-domains: + maxItems: 1 + required: - compatible - reg diff --git a/Documentation/devicetree/bindings/iommu/arm,smmu.yaml b/Documentation/devicetree/bindings/iommu/arm,smmu.yaml index f66a3effba73..da5381c8ee11 100644 --- a/Documentation/devicetree/bindings/iommu/arm,smmu.yaml +++ b/Documentation/devicetree/bindings/iommu/arm,smmu.yaml @@ -38,10 +38,12 @@ properties: - qcom,sc7280-smmu-500 - qcom,sc8180x-smmu-500 - qcom,sdm845-smmu-500 + - qcom,sdx55-smmu-500 - qcom,sm6350-smmu-500 - qcom,sm8150-smmu-500 - qcom,sm8250-smmu-500 - qcom,sm8350-smmu-500 + - qcom,sm8450-smmu-500 - const: arm,mmu-500 - description: Qcom Adreno GPUs implementing "arm,smmu-v2" items: diff --git a/Documentation/devicetree/bindings/ipmi/aspeed,ast2400-ibt-bmc.txt b/Documentation/devicetree/bindings/ipmi/aspeed,ast2400-ibt-bmc.txt index c9902fd4b38b..25f86da804b7 100644 --- a/Documentation/devicetree/bindings/ipmi/aspeed,ast2400-ibt-bmc.txt +++ b/Documentation/devicetree/bindings/ipmi/aspeed,ast2400-ibt-bmc.txt @@ -11,6 +11,7 @@ Required properties: "aspeed,ast2500-ibt-bmc" "aspeed,ast2600-ibt-bmc" - reg: physical address and size of the registers +- clocks: clock for the device Optional properties: @@ -23,4 +24,5 @@ Example: compatible = "aspeed,ast2400-ibt-bmc"; reg = <0x1e789140 0x18>; interrupts = <8>; + clocks = <&syscon ASPEED_CLK_GATE_LCLK>; }; diff --git a/Documentation/devicetree/bindings/leds/leds-bcm6328.txt b/Documentation/devicetree/bindings/leds/leds-bcm6328.txt deleted file mode 100644 index a555d94084b7..000000000000 --- a/Documentation/devicetree/bindings/leds/leds-bcm6328.txt +++ /dev/null @@ -1,319 +0,0 @@ -LEDs connected to Broadcom BCM6328 controller - -This controller is present on BCM6318, BCM6328, BCM6362 and BCM63268. -In these SoCs it's possible to control LEDs both as GPIOs or by hardware. -However, on some devices there are Serial LEDs (LEDs connected to a 74x164 -controller), which can either be controlled by software (exporting the 74x164 -as spi-gpio. See Documentation/devicetree/bindings/gpio/fairchild,74hc595.yaml), -or by hardware using this driver. -Some of these Serial LEDs are hardware controlled (e.g. ethernet LEDs) and -exporting the 74x164 as spi-gpio prevents those LEDs to be hardware -controlled, so the only chance to keep them working is by using this driver. - -BCM6328 LED controller has a HWDIS register, which controls whether a LED -should be controlled by a hardware signal instead of the MODE register value, -with 0 meaning hardware control enabled and 1 hardware control disabled. This -is usually 1:1 for hardware to LED signals, but through the activity/link -registers you have some limited control over rerouting the LEDs (as -explained later in brcm,link-signal-sources). Even if a LED is hardware -controlled you are still able to make it blink or light it up if it isn't, -but you can't turn it off if the hardware decides to light it up. For this -reason, hardware controlled LEDs aren't registered as LED class devices. - -Required properties: - - compatible : should be "brcm,bcm6328-leds". - - #address-cells : must be 1. - - #size-cells : must be 0. - - reg : BCM6328 LED controller address and size. - -Optional properties: - - brcm,serial-leds : Boolean, enables Serial LEDs. - Default : false - - brcm,serial-mux : Boolean, enables Serial LEDs multiplexing. - Default : false - - brcm,serial-clk-low : Boolean, makes clock signal active low. - Default : false - - brcm,serial-dat-low : Boolean, makes data signal active low. - Default : false - - brcm,serial-shift-inv : Boolean, inverts Serial LEDs shift direction. - Default : false - -Each LED is represented as a sub-node of the brcm,bcm6328-leds device. - -LED sub-node required properties: - - reg : LED pin number (only LEDs 0 to 23 are valid). - -LED sub-node optional properties: - a) Optional properties for sub-nodes related to software controlled LEDs: - - label : see Documentation/devicetree/bindings/leds/common.txt - - active-low : Boolean, makes LED active low. - Default : false - - default-state : see - Documentation/devicetree/bindings/leds/common.txt - - linux,default-trigger : see - Documentation/devicetree/bindings/leds/common.txt - - b) Optional properties for sub-nodes related to hardware controlled LEDs: - - brcm,hardware-controlled : Boolean, makes this LED hardware controlled. - Default : false - - brcm,link-signal-sources : An array of hardware link - signal sources. Up to four link hardware signals can get muxed into - these LEDs. Only valid for LEDs 0 to 7, where LED signals 0 to 3 may - be muxed to LEDs 0 to 3, and signals 4 to 7 may be muxed to LEDs - 4 to 7. A signal can be muxed to more than one LED, and one LED can - have more than one source signal. - - brcm,activity-signal-sources : An array of hardware activity - signal sources. Up to four activity hardware signals can get muxed into - these LEDs. Only valid for LEDs 0 to 7, where LED signals 0 to 3 may - be muxed to LEDs 0 to 3, and signals 4 to 7 may be muxed to LEDs - 4 to 7. A signal can be muxed to more than one LED, and one LED can - have more than one source signal. - -Examples: -Scenario 1 : BCM6328 with 4 EPHY LEDs - leds0: led-controller@10000800 { - compatible = "brcm,bcm6328-leds"; - #address-cells = <1>; - #size-cells = <0>; - reg = <0x10000800 0x24>; - - alarm_red@2 { - reg = <2>; - active-low; - label = "red:alarm"; - }; - inet_green@3 { - reg = <3>; - active-low; - label = "green:inet"; - }; - power_green@4 { - reg = <4>; - active-low; - label = "green:power"; - default-state = "on"; - }; - ephy0_spd@17 { - reg = <17>; - brcm,hardware-controlled; - }; - ephy1_spd@18 { - reg = <18>; - brcm,hardware-controlled; - }; - ephy2_spd@19 { - reg = <19>; - brcm,hardware-controlled; - }; - ephy3_spd@20 { - reg = <20>; - brcm,hardware-controlled; - }; - }; - -Scenario 2 : BCM63268 with Serial/GPHY0 LEDs - leds0: led-controller@10001900 { - compatible = "brcm,bcm6328-leds"; - #address-cells = <1>; - #size-cells = <0>; - reg = <0x10001900 0x24>; - brcm,serial-leds; - brcm,serial-dat-low; - brcm,serial-shift-inv; - - gphy0_spd0@0 { - reg = <0>; - brcm,hardware-controlled; - brcm,link-signal-sources = <0>; - }; - gphy0_spd1@1 { - reg = <1>; - brcm,hardware-controlled; - brcm,link-signal-sources = <1>; - }; - inet_red@2 { - reg = <2>; - active-low; - label = "red:inet"; - }; - dsl_green@3 { - reg = <3>; - active-low; - label = "green:dsl"; - }; - usb_green@4 { - reg = <4>; - active-low; - label = "green:usb"; - }; - wps_green@7 { - reg = <7>; - active-low; - label = "green:wps"; - }; - inet_green@8 { - reg = <8>; - active-low; - label = "green:inet"; - }; - ephy0_act@9 { - reg = <9>; - brcm,hardware-controlled; - }; - ephy1_act@10 { - reg = <10>; - brcm,hardware-controlled; - }; - ephy2_act@11 { - reg = <11>; - brcm,hardware-controlled; - }; - gphy0_act@12 { - reg = <12>; - brcm,hardware-controlled; - }; - ephy0_spd@13 { - reg = <13>; - brcm,hardware-controlled; - }; - ephy1_spd@14 { - reg = <14>; - brcm,hardware-controlled; - }; - ephy2_spd@15 { - reg = <15>; - brcm,hardware-controlled; - }; - power_green@20 { - reg = <20>; - active-low; - label = "green:power"; - default-state = "on"; - }; - }; - -Scenario 3 : BCM6362 with 1 LED for each EPHY - leds0: led-controller@10001900 { - compatible = "brcm,bcm6328-leds"; - #address-cells = <1>; - #size-cells = <0>; - reg = <0x10001900 0x24>; - - usb@0 { - reg = <0>; - brcm,hardware-controlled; - brcm,link-signal-sources = <0>; - brcm,activity-signal-sources = <0>; - /* USB link/activity routed to USB LED */ - }; - inet@1 { - reg = <1>; - brcm,hardware-controlled; - brcm,activity-signal-sources = <1>; - /* INET activity routed to INET LED */ - }; - ephy0@4 { - reg = <4>; - brcm,hardware-controlled; - brcm,link-signal-sources = <4>; - /* EPHY0 link routed to EPHY0 LED */ - }; - ephy1@5 { - reg = <5>; - brcm,hardware-controlled; - brcm,link-signal-sources = <5>; - /* EPHY1 link routed to EPHY1 LED */ - }; - ephy2@6 { - reg = <6>; - brcm,hardware-controlled; - brcm,link-signal-sources = <6>; - /* EPHY2 link routed to EPHY2 LED */ - }; - ephy3@7 { - reg = <7>; - brcm,hardware-controlled; - brcm,link-signal-sources = <7>; - /* EPHY3 link routed to EPHY3 LED */ - }; - power_green@20 { - reg = <20>; - active-low; - label = "green:power"; - default-state = "on"; - }; - }; - -Scenario 4 : BCM6362 with 1 LED for all EPHYs - leds0: led-controller@10001900 { - compatible = "brcm,bcm6328-leds"; - #address-cells = <1>; - #size-cells = <0>; - reg = <0x10001900 0x24>; - - usb@0 { - reg = <0>; - brcm,hardware-controlled; - brcm,link-signal-sources = <0 1>; - brcm,activity-signal-sources = <0 1>; - /* USB/INET link/activity routed to USB LED */ - }; - ephy@4 { - reg = <4>; - brcm,hardware-controlled; - brcm,link-signal-sources = <4 5 6 7>; - /* EPHY0/1/2/3 link routed to EPHY0 LED */ - }; - power_green@20 { - reg = <20>; - active-low; - label = "green:power"; - default-state = "on"; - }; - }; - -Scenario 5 : BCM6362 with EPHY LEDs swapped - leds0: led-controller@10001900 { - compatible = "brcm,bcm6328-leds"; - #address-cells = <1>; - #size-cells = <0>; - reg = <0x10001900 0x24>; - - usb@0 { - reg = <0>; - brcm,hardware-controlled; - brcm,link-signal-sources = <0>; - brcm,activity-signal-sources = <0 1>; - /* USB link/act and INET act routed to USB LED */ - }; - ephy0@4 { - reg = <4>; - brcm,hardware-controlled; - brcm,link-signal-sources = <7>; - /* EPHY3 link routed to EPHY0 LED */ - }; - ephy1@5 { - reg = <5>; - brcm,hardware-controlled; - brcm,link-signal-sources = <6>; - /* EPHY2 link routed to EPHY1 LED */ - }; - ephy2@6 { - reg = <6>; - brcm,hardware-controlled; - brcm,link-signal-sources = <5>; - /* EPHY1 link routed to EPHY2 LED */ - }; - ephy3@7 { - reg = <7>; - brcm,hardware-controlled; - brcm,link-signal-sources = <4>; - /* EPHY0 link routed to EPHY3 LED */ - }; - power_green@20 { - reg = <20>; - active-low; - label = "green:power"; - default-state = "on"; - }; - }; diff --git a/Documentation/devicetree/bindings/leds/leds-bcm6328.yaml b/Documentation/devicetree/bindings/leds/leds-bcm6328.yaml new file mode 100644 index 000000000000..51cc0d82c12e --- /dev/null +++ b/Documentation/devicetree/bindings/leds/leds-bcm6328.yaml @@ -0,0 +1,404 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/leds/leds-bcm6328.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: LEDs connected to Broadcom BCM6328 controller + +maintainers: + - Álvaro Fernández Rojas <noltari@gmail.com> + +description: | + This controller is present on BCM6318, BCM6328, BCM6362 and BCM63268. + In these SoCs it's possible to control LEDs both as GPIOs or by hardware. + However, on some devices there are Serial LEDs (LEDs connected to a 74x164 + controller), which can either be controlled by software (exporting the 74x164 + as spi-gpio. See + Documentation/devicetree/bindings/gpio/fairchild,74hc595.yaml), or by hardware + using this driver. + Some of these Serial LEDs are hardware controlled (e.g. ethernet LEDs) and + exporting the 74x164 as spi-gpio prevents those LEDs to be hardware + controlled, so the only chance to keep them working is by using this driver. + + BCM6328 LED controller has a HWDIS register, which controls whether a LED + should be controlled by a hardware signal instead of the MODE register value, + with 0 meaning hardware control enabled and 1 hardware control disabled. This + is usually 1:1 for hardware to LED signals, but through the activity/link + registers you have some limited control over rerouting the LEDs (as + explained later in brcm,link-signal-sources). Even if a LED is hardware + controlled you are still able to make it blink or light it up if it isn't, + but you can't turn it off if the hardware decides to light it up. For this + reason, hardware controlled LEDs aren't registered as LED class devices. + + Each LED is represented as a sub-node of the brcm,bcm6328-leds device. + +properties: + compatible: + const: brcm,bcm6328-leds + + reg: + maxItems: 1 + + brcm,serial-leds: + type: boolean + description: Enables Serial LEDs. + + brcm,serial-mux: + type: boolean + description: Enables Serial LEDs multiplexing. + + brcm,serial-clk-low: + type: boolean + description: Makes clock signal active low. + + brcm,serial-dat-low: + type: boolean + description: Makes data signal active low. + + brcm,serial-shift-inv: + type: boolean + description: Inverts Serial LEDs shift direction. + + "#address-cells": + const: 1 + + "#size-cells": + const: 0 + +patternProperties: + "@[a-f0-9]+$": + type: object + + $ref: common.yaml# + + properties: + reg: + items: + - maximum: 23 + description: LED pin number (only LEDs 0 to 23 are valid). + + active-low: + type: boolean + description: Makes LED active low. + + brcm,hardware-controlled: + type: boolean + description: Makes this LED hardware controlled. + + brcm,link-signal-sources: + $ref: /schemas/types.yaml#/definitions/uint32-array + minItems: 1 + maxItems: 4 + description: > + An array of hardware link signal sources. Up to four link hardware + signals can get muxed into these LEDs. Only valid for LEDs 0 to 7, + where LED signals 0 to 3 may be muxed to LEDs 0 to 3, and signals 4 to + 7 may be muxed to LEDs 4 to 7. A signal can be muxed to more than one + LED, and one LED can have more than one source signal. + + brcm,activity-signal-sources: + $ref: /schemas/types.yaml#/definitions/uint32-array + minItems: 1 + maxItems: 4 + description: > + An array of hardware activity signal sources. Up to four activity + hardware signals can get muxed into these LEDs. Only valid for LEDs 0 + to 7, where LED signals 0 to 3 may be muxed to LEDs 0 to 3, and + signals 4 to 7 may be muxed to LEDs 4 to 7. A signal can be muxed to + more than one LED, and one LED can have more than one source signal. + + required: + - reg + + unevaluatedProperties: false + +required: + - reg + - "#address-cells" + - "#size-cells" + +additionalProperties: false + +examples: + - | + /* BCM6328 with 4 EPHY LEDs */ + led-controller@10000800 { + compatible = "brcm,bcm6328-leds"; + #address-cells = <1>; + #size-cells = <0>; + reg = <0x10000800 0x24>; + + alarm_red@2 { + reg = <2>; + active-low; + label = "red:alarm"; + }; + + inet_green@3 { + reg = <3>; + active-low; + label = "green:inet"; + }; + + power_green@4 { + reg = <4>; + active-low; + label = "green:power"; + default-state = "on"; + }; + + ephy0_spd@17 { + reg = <17>; + brcm,hardware-controlled; + }; + + ephy1_spd@18 { + reg = <18>; + brcm,hardware-controlled; + }; + + ephy2_spd@19 { + reg = <19>; + brcm,hardware-controlled; + }; + + ephy3_spd@20 { + reg = <20>; + brcm,hardware-controlled; + }; + }; + - | + /* BCM63268 with Serial/GPHY0 LEDs */ + led-controller@10001900 { + compatible = "brcm,bcm6328-leds"; + #address-cells = <1>; + #size-cells = <0>; + reg = <0x10001900 0x24>; + brcm,serial-leds; + brcm,serial-dat-low; + brcm,serial-shift-inv; + + gphy0_spd0@0 { + reg = <0>; + brcm,hardware-controlled; + brcm,link-signal-sources = <0>; + }; + + gphy0_spd1@1 { + reg = <1>; + brcm,hardware-controlled; + brcm,link-signal-sources = <1>; + }; + + inet_red@2 { + reg = <2>; + active-low; + label = "red:inet"; + }; + + dsl_green@3 { + reg = <3>; + active-low; + label = "green:dsl"; + }; + + usb_green@4 { + reg = <4>; + active-low; + label = "green:usb"; + }; + + wps_green@7 { + reg = <7>; + active-low; + label = "green:wps"; + }; + + inet_green@8 { + reg = <8>; + active-low; + label = "green:inet"; + }; + + ephy0_act@9 { + reg = <9>; + brcm,hardware-controlled; + }; + + ephy1_act@10 { + reg = <10>; + brcm,hardware-controlled; + }; + + ephy2_act@11 { + reg = <11>; + brcm,hardware-controlled; + }; + + gphy0_act@12 { + reg = <12>; + brcm,hardware-controlled; + }; + + ephy0_spd@13 { + reg = <13>; + brcm,hardware-controlled; + }; + + ephy1_spd@14 { + reg = <14>; + brcm,hardware-controlled; + }; + + ephy2_spd@15 { + reg = <15>; + brcm,hardware-controlled; + }; + + power_green@20 { + reg = <20>; + active-low; + label = "green:power"; + default-state = "on"; + }; + }; + - | + /* BCM6362 with 1 LED for each EPHY */ + led-controller@10001900 { + compatible = "brcm,bcm6328-leds"; + #address-cells = <1>; + #size-cells = <0>; + reg = <0x10001900 0x24>; + + usb@0 { + reg = <0>; + brcm,hardware-controlled; + brcm,link-signal-sources = <0>; + brcm,activity-signal-sources = <0>; + /* USB link/activity routed to USB LED */ + }; + + inet@1 { + reg = <1>; + brcm,hardware-controlled; + brcm,activity-signal-sources = <1>; + /* INET activity routed to INET LED */ + }; + + ephy0@4 { + reg = <4>; + brcm,hardware-controlled; + brcm,link-signal-sources = <4>; + /* EPHY0 link routed to EPHY0 LED */ + }; + + ephy1@5 { + reg = <5>; + brcm,hardware-controlled; + brcm,link-signal-sources = <5>; + /* EPHY1 link routed to EPHY1 LED */ + }; + + ephy2@6 { + reg = <6>; + brcm,hardware-controlled; + brcm,link-signal-sources = <6>; + /* EPHY2 link routed to EPHY2 LED */ + }; + + ephy3@7 { + reg = <7>; + brcm,hardware-controlled; + brcm,link-signal-sources = <7>; + /* EPHY3 link routed to EPHY3 LED */ + }; + + power_green@20 { + reg = <20>; + active-low; + label = "green:power"; + default-state = "on"; + }; + }; + - | + /* BCM6362 with 1 LED for all EPHYs */ + led-controller@10001900 { + compatible = "brcm,bcm6328-leds"; + #address-cells = <1>; + #size-cells = <0>; + reg = <0x10001900 0x24>; + + usb@0 { + reg = <0>; + brcm,hardware-controlled; + brcm,link-signal-sources = <0 1>; + brcm,activity-signal-sources = <0 1>; + /* USB/INET link/activity routed to USB LED */ + }; + + ephy@4 { + reg = <4>; + brcm,hardware-controlled; + brcm,link-signal-sources = <4 5 6 7>; + /* EPHY0/1/2/3 link routed to EPHY0 LED */ + }; + + power_green@20 { + reg = <20>; + active-low; + label = "green:power"; + default-state = "on"; + }; + }; + - | + /* BCM6362 with EPHY LEDs swapped */ + led-controller@10001900 { + compatible = "brcm,bcm6328-leds"; + #address-cells = <1>; + #size-cells = <0>; + reg = <0x10001900 0x24>; + + usb@0 { + reg = <0>; + brcm,hardware-controlled; + brcm,link-signal-sources = <0>; + brcm,activity-signal-sources = <0 1>; + /* USB link/act and INET act routed to USB LED */ + }; + + ephy0@4 { + reg = <4>; + brcm,hardware-controlled; + brcm,link-signal-sources = <7>; + /* EPHY3 link routed to EPHY0 LED */ + }; + + ephy1@5 { + reg = <5>; + brcm,hardware-controlled; + brcm,link-signal-sources = <6>; + /* EPHY2 link routed to EPHY1 LED */ + }; + + ephy2@6 { + reg = <6>; + brcm,hardware-controlled; + brcm,link-signal-sources = <5>; + /* EPHY1 link routed to EPHY2 LED */ + }; + + ephy3@7 { + reg = <7>; + brcm,hardware-controlled; + brcm,link-signal-sources = <4>; + /* EPHY0 link routed to EPHY3 LED */ + }; + + power_green@20 { + reg = <20>; + active-low; + label = "green:power"; + default-state = "on"; + }; + }; diff --git a/Documentation/devicetree/bindings/leds/leds-mt6360.yaml b/Documentation/devicetree/bindings/leds/leds-mt6360.yaml new file mode 100644 index 000000000000..b2fe6eb89389 --- /dev/null +++ b/Documentation/devicetree/bindings/leds/leds-mt6360.yaml @@ -0,0 +1,159 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/leds/leds-mt6360.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: LED driver for MT6360 PMIC from MediaTek Integrated. + +maintainers: + - Gene Chen <gene_chen@richtek.com> + +description: | + This module is part of the MT6360 MFD device. + see Documentation/devicetree/bindings/mfd/mt6360.yaml + Add MT6360 LED driver include 2-channel Flash LED with torch/strobe mode, + and 4-channel RGB LED support Register/Flash/Breath Mode + +properties: + compatible: + const: mediatek,mt6360-led + + "#address-cells": + const: 1 + + "#size-cells": + const: 0 + +patternProperties: + "^(multi-)?led@[0-5]$": + type: object + $ref: common.yaml# + description: + Properties for a single LED. + + properties: + reg: + description: Index of the LED. + enum: + - 0 # LED output ISINK1 + - 1 # LED output ISINK2 + - 2 # LED output ISINK3 + - 3 # LED output ISINKML + - 4 # LED output FLASH1 + - 5 # LED output FLASH2 + +unevaluatedProperties: false + +required: + - compatible + - "#address-cells" + - "#size-cells" + +additionalProperties: false + +examples: + - | + #include <dt-bindings/leds/common.h> + led-controller { + compatible = "mediatek,mt6360-led"; + #address-cells = <1>; + #size-cells = <0>; + + multi-led@0 { + reg = <0>; + function = LED_FUNCTION_INDICATOR; + color = <LED_COLOR_ID_RGB>; + led-max-microamp = <24000>; + #address-cells = <1>; + #size-cells = <0>; + led@0 { + reg = <0>; + color = <LED_COLOR_ID_RED>; + }; + led@1 { + reg = <1>; + color = <LED_COLOR_ID_GREEN>; + }; + led@2 { + reg = <2>; + color = <LED_COLOR_ID_BLUE>; + }; + }; + led@3 { + reg = <3>; + function = LED_FUNCTION_INDICATOR; + color = <LED_COLOR_ID_WHITE>; + led-max-microamp = <150000>; + }; + led@4 { + reg = <4>; + function = LED_FUNCTION_FLASH; + color = <LED_COLOR_ID_WHITE>; + function-enumerator = <1>; + led-max-microamp = <200000>; + flash-max-microamp = <500000>; + flash-max-timeout-us = <1024000>; + }; + led@5 { + reg = <5>; + function = LED_FUNCTION_FLASH; + color = <LED_COLOR_ID_WHITE>; + function-enumerator = <2>; + led-max-microamp = <200000>; + flash-max-microamp = <500000>; + flash-max-timeout-us = <1024000>; + }; + }; + + - | + + led-controller { + compatible = "mediatek,mt6360-led"; + #address-cells = <1>; + #size-cells = <0>; + + led@0 { + reg = <0>; + function = LED_FUNCTION_INDICATOR; + color = <LED_COLOR_ID_RED>; + led-max-microamp = <24000>; + }; + led@1 { + reg = <1>; + function = LED_FUNCTION_INDICATOR; + color = <LED_COLOR_ID_GREEN>; + led-max-microamp = <24000>; + }; + led@2 { + reg = <2>; + function = LED_FUNCTION_INDICATOR; + color = <LED_COLOR_ID_BLUE>; + led-max-microamp = <24000>; + }; + led@3 { + reg = <3>; + function = LED_FUNCTION_INDICATOR; + color = <LED_COLOR_ID_WHITE>; + led-max-microamp = <150000>; + }; + led@4 { + reg = <4>; + function = LED_FUNCTION_FLASH; + color = <LED_COLOR_ID_WHITE>; + function-enumerator = <1>; + led-max-microamp = <200000>; + flash-max-microamp = <500000>; + flash-max-timeout-us = <1024000>; + }; + led@5 { + reg = <5>; + function = LED_FUNCTION_FLASH; + color = <LED_COLOR_ID_WHITE>; + function-enumerator = <2>; + led-max-microamp = <200000>; + flash-max-microamp = <500000>; + flash-max-timeout-us = <1024000>; + }; + }; +... diff --git a/Documentation/devicetree/bindings/mailbox/apple,mailbox.yaml b/Documentation/devicetree/bindings/mailbox/apple,mailbox.yaml index 2c1704b34e7a..5c5c328b3134 100644 --- a/Documentation/devicetree/bindings/mailbox/apple,mailbox.yaml +++ b/Documentation/devicetree/bindings/mailbox/apple,mailbox.yaml @@ -27,14 +27,20 @@ properties: for example for the display controller, the system management controller and the NVMe coprocessor. items: - - const: apple,t8103-asc-mailbox + - enum: + - apple,t8103-asc-mailbox + - apple,t6000-asc-mailbox + - const: apple,asc-mailbox-v4 - description: M3 mailboxes are an older variant with a slightly different MMIO interface still found on the M1. It is used for the Thunderbolt co-processors. items: - - const: apple,t8103-m3-mailbox + - enum: + - apple,t8103-m3-mailbox + - apple,t6000-m3-mailbox + - const: apple,m3-mailbox-v2 reg: maxItems: 1 @@ -56,6 +62,9 @@ properties: "#mbox-cells": const: 0 + power-domains: + maxItems: 1 + required: - compatible - reg @@ -68,7 +77,7 @@ additionalProperties: false examples: - | mailbox@77408000 { - compatible = "apple,t8103-asc-mailbox"; + compatible = "apple,t8103-asc-mailbox", "apple,asc-mailbox-v4"; reg = <0x77408000 0x4000>; interrupts = <1 583 4>, <1 584 4>, <1 585 4>, <1 586 4>; interrupt-names = "send-empty", "send-not-empty", diff --git a/Documentation/devicetree/bindings/mailbox/nvidia,tegra186-hsp.txt b/Documentation/devicetree/bindings/mailbox/nvidia,tegra186-hsp.txt deleted file mode 100644 index ff3eafc5a882..000000000000 --- a/Documentation/devicetree/bindings/mailbox/nvidia,tegra186-hsp.txt +++ /dev/null @@ -1,72 +0,0 @@ -NVIDIA Tegra Hardware Synchronization Primitives (HSP) - -The HSP modules are used for the processors to share resources and communicate -together. It provides a set of hardware synchronization primitives for -interprocessor communication. So the interprocessor communication (IPC) -protocols can use hardware synchronization primitives, when operating between -two processors not in an SMP relationship. - -The features that HSP supported are shared mailboxes, shared semaphores, -arbitrated semaphores and doorbells. - -Required properties: -- name : Should be hsp -- compatible - Array of strings. - one of: - - "nvidia,tegra186-hsp" - - "nvidia,tegra194-hsp", "nvidia,tegra186-hsp" -- reg : Offset and length of the register set for the device. -- interrupt-names - Array of strings. - Contains a list of names for the interrupts described by the interrupt - property. May contain the following entries, in any order: - - "doorbell" - - "sharedN", where 'N' is a number from zero up to the number of - external interrupts supported by the HSP instance minus one. - Users of this binding MUST look up entries in the interrupt property - by name, using this interrupt-names property to do so. -- interrupts - Array of interrupt specifiers. - Must contain one entry per entry in the interrupt-names property, - in a matching order. -- #mbox-cells : Should be 2. - -The mbox specifier of the "mboxes" property in the client node should contain -two cells. The first cell determines the HSP type and the second cell is used -to identify the mailbox that the client is going to use. - -For doorbells, the second cell specifies the index of the doorbell to use. - -For shared mailboxes, the second cell is composed of two fields: -- bits 31..24: - A bit mask of flags that further specify how the shared mailbox will be - used. Valid flags are: - - bit 31: - Defines the direction of the mailbox. If set, the mailbox will be used - as a producer (i.e. used to send data). If cleared, the mailbox is the - consumer of data sent by a producer. - -- bits 23.. 0: - The index of the shared mailbox to use. The number of available mailboxes - may vary by instance of the HSP block and SoC generation. - -The following file contains definitions that can be used to construct mailbox -specifiers: - - <dt-bindings/mailbox/tegra186-hsp.h> - -Example: - -hsp_top0: hsp@3c00000 { - compatible = "nvidia,tegra186-hsp"; - reg = <0x0 0x03c00000 0x0 0xa0000>; - interrupts = <GIC_SPI 176 IRQ_TYPE_LEVEL_HIGH>; - interrupt-names = "doorbell"; - #mbox-cells = <2>; -}; - -client { - ... - mboxes = <&hsp_top0 TEGRA_HSP_MBOX_TYPE_DB TEGRA_HSP_DB_MASTER_XXX>; -}; diff --git a/Documentation/devicetree/bindings/mailbox/nvidia,tegra186-hsp.yaml b/Documentation/devicetree/bindings/mailbox/nvidia,tegra186-hsp.yaml new file mode 100644 index 000000000000..9f7a7296b57f --- /dev/null +++ b/Documentation/devicetree/bindings/mailbox/nvidia,tegra186-hsp.yaml @@ -0,0 +1,114 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/mailbox/nvidia,tegra186-hsp.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: NVIDIA Tegra Hardware Synchronization Primitives (HSP) + +maintainers: + - Thierry Reding <thierry.reding@gmail.com> + - Jon Hunter <jonathanh@nvidia.com> + +description: | + The HSP modules are used for the processors to share resources and + communicate together. It provides a set of hardware synchronization + primitives for interprocessor communication. So the interprocessor + communication (IPC) protocols can use hardware synchronization + primitives, when operating between two processors not in an SMP + relationship. + + The features that HSP supported are shared mailboxes, shared + semaphores, arbitrated semaphores and doorbells. + + The mbox specifier of the "mboxes" property in the client node should + contain two cells. The first cell determines the HSP type and the + second cell is used to identify the mailbox that the client is going + to use. + + For doorbells, the second cell specifies the index of the doorbell to + use. + + For shared mailboxes, the second cell is composed of two fields: + - bits 31..24: + A bit mask of flags that further specify how the shared mailbox + will be used. Valid flags are: + - bit 31: + Defines the direction of the mailbox. If set, the mailbox + will be used as a producer (i.e. used to send data). If + cleared, the mailbox is the consumer of data sent by a + producer. + + - bits 23..0: + The index of the shared mailbox to use. The number of available + mailboxes may vary by instance of the HSP block and SoC + generation. + + The following file contains definitions that can be used to + construct mailbox specifiers: + + <dt-bindings/mailbox/tegra186-hsp.h> + +properties: + $nodename: + pattern: "^hsp@[0-9a-f]+$" + + compatible: + oneOf: + - const: nvidia,tegra186-hsp + - const: nvidia,tegra194-hsp + - items: + - const: nvidia,tegra234-hsp + - const: nvidia,tegra194-hsp + + reg: + maxItems: 1 + + interrupts: + minItems: 1 + maxItems: 9 + + interrupt-names: + oneOf: + # shared interrupts are optional + - items: + - const: doorbell + + - items: + - const: doorbell + - pattern: "^shared[0-7]$" + - pattern: "^shared[0-7]$" + - pattern: "^shared[0-7]$" + - pattern: "^shared[0-7]$" + - pattern: "^shared[0-7]$" + - pattern: "^shared[0-7]$" + - pattern: "^shared[0-7]$" + - pattern: "^shared[0-7]$" + + - items: + - pattern: "^shared[0-7]$" + - pattern: "^shared[0-7]$" + - pattern: "^shared[0-7]$" + - pattern: "^shared[0-7]$" + + "#mbox-cells": + const: 2 + +additionalProperties: false + +examples: + - | + #include <dt-bindings/interrupt-controller/arm-gic.h> + #include <dt-bindings/mailbox/tegra186-hsp.h> + + hsp_top0: hsp@3c00000 { + compatible = "nvidia,tegra186-hsp"; + reg = <0x03c00000 0xa0000>; + interrupts = <GIC_SPI 176 IRQ_TYPE_LEVEL_HIGH>; + interrupt-names = "doorbell"; + #mbox-cells = <2>; + }; + + client { + mboxes = <&hsp_top0 TEGRA_HSP_MBOX_TYPE_DB TEGRA_HSP_DB_MASTER_CCPLEX>; + }; diff --git a/Documentation/devicetree/bindings/mailbox/ti,omap-mailbox.yaml b/Documentation/devicetree/bindings/mailbox/ti,omap-mailbox.yaml index e864d798168d..d433e496ec6e 100644 --- a/Documentation/devicetree/bindings/mailbox/ti,omap-mailbox.yaml +++ b/Documentation/devicetree/bindings/mailbox/ti,omap-mailbox.yaml @@ -180,15 +180,6 @@ allOf: compatible: enum: - ti,am654-mailbox - then: - required: - - interrupt-parent - - - if: - properties: - compatible: - enum: - - ti,am654-mailbox - ti,am64-mailbox then: properties: diff --git a/Documentation/devicetree/bindings/media/allwinner,sun4i-a10-video-engine.yaml b/Documentation/devicetree/bindings/media/allwinner,sun4i-a10-video-engine.yaml index c34303b87a5b..c3de96d10396 100644 --- a/Documentation/devicetree/bindings/media/allwinner,sun4i-a10-video-engine.yaml +++ b/Documentation/devicetree/bindings/media/allwinner,sun4i-a10-video-engine.yaml @@ -20,6 +20,7 @@ properties: - allwinner,sun8i-h3-video-engine - allwinner,sun8i-v3s-video-engine - allwinner,sun8i-r40-video-engine + - allwinner,sun20i-d1-video-engine - allwinner,sun50i-a64-video-engine - allwinner,sun50i-h5-video-engine - allwinner,sun50i-h6-video-engine diff --git a/Documentation/devicetree/bindings/media/allwinner,sun50i-h6-vpu-g2.yaml b/Documentation/devicetree/bindings/media/allwinner,sun50i-h6-vpu-g2.yaml new file mode 100644 index 000000000000..24d7bf21499e --- /dev/null +++ b/Documentation/devicetree/bindings/media/allwinner,sun50i-h6-vpu-g2.yaml @@ -0,0 +1,64 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) + +%YAML 1.2 +--- +$id: "http://devicetree.org/schemas/media/allwinner,sun50i-h6-vpu-g2.yaml#" +$schema: "http://devicetree.org/meta-schemas/core.yaml#" + +title: Hantro G2 VPU codec implemented on Allwinner H6 SoC + +maintainers: + - Jernej Skrabec <jernej.skrabec@gmail.com> + +description: + Hantro G2 video decode accelerator present on Allwinner H6 SoC. + +properties: + compatible: + const: allwinner,sun50i-h6-vpu-g2 + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + clocks: + items: + - description: Bus Clock + - description: Module Clock + + clock-names: + items: + - const: bus + - const: mod + + resets: + maxItems: 1 + +required: + - compatible + - reg + - interrupts + - clocks + - clock-names + - resets + +additionalProperties: false + +examples: + - | + #include <dt-bindings/interrupt-controller/arm-gic.h> + #include <dt-bindings/clock/sun50i-h6-ccu.h> + #include <dt-bindings/reset/sun50i-h6-ccu.h> + + video-codec-g2@1c00000 { + compatible = "allwinner,sun50i-h6-vpu-g2"; + reg = <0x01c00000 0x1000>; + interrupts = <GIC_SPI 90 IRQ_TYPE_LEVEL_HIGH>; + clocks = <&ccu CLK_BUS_VP9>, <&ccu CLK_VP9>; + clock-names = "bus", "mod"; + resets = <&ccu RST_BUS_VP9>; + }; + +... diff --git a/Documentation/devicetree/bindings/media/i2c/adv748x.txt b/Documentation/devicetree/bindings/media/i2c/adv748x.txt deleted file mode 100644 index 4f91686e54a6..000000000000 --- a/Documentation/devicetree/bindings/media/i2c/adv748x.txt +++ /dev/null @@ -1,116 +0,0 @@ -* Analog Devices ADV748X video decoder with HDMI receiver - -The ADV7481 and ADV7482 are multi format video decoders with an integrated -HDMI receiver. They can output CSI-2 on two independent outputs TXA and TXB -from three input sources HDMI, analog and TTL. - -Required Properties: - - - compatible: Must contain one of the following - - "adi,adv7481" for the ADV7481 - - "adi,adv7482" for the ADV7482 - - - reg: I2C slave addresses - The ADV748x has up to twelve 256-byte maps that can be accessed via the - main I2C ports. Each map has it own I2C address and acts as a standard - slave device on the I2C bus. The main address is mandatory, others are - optional and remain at default values if not specified. - -Optional Properties: - - - interrupt-names: Should specify the interrupts as "intrq1", "intrq2" and/or - "intrq3". All interrupts are optional. The "intrq3" interrupt - is only available on the adv7481 - - interrupts: Specify the interrupt lines for the ADV748x - - reg-names : Names of maps with programmable addresses. - It shall contain all maps needing a non-default address. - Possible map names are: - "main", "dpll", "cp", "hdmi", "edid", "repeater", - "infoframe", "cbus", "cec", "sdp", "txa", "txb" - -The device node must contain one 'port' child node per device input and output -port, in accordance with the video interface bindings defined in -Documentation/devicetree/bindings/media/video-interfaces.txt. The port nodes -are numbered as follows. - - Name Type Port - --------------------------------------- - AIN0 sink 0 - AIN1 sink 1 - AIN2 sink 2 - AIN3 sink 3 - AIN4 sink 4 - AIN5 sink 5 - AIN6 sink 6 - AIN7 sink 7 - HDMI sink 8 - TTL sink 9 - TXA source 10 - TXB source 11 - -The digital output port nodes, when present, shall contain at least one -endpoint. Each of those endpoints shall contain the data-lanes property as -described in video-interfaces.txt. - -Required source endpoint properties: - - data-lanes: an array of physical data lane indexes - The accepted value(s) for this property depends on which of the two - sources are described. For TXA 1, 2 or 4 data lanes can be described - while for TXB only 1 data lane is valid. See video-interfaces.txt - for detailed description. - -Ports are optional if they are not connected to anything at the hardware level. - -Example: - - video-receiver@70 { - compatible = "adi,adv7482"; - reg = <0x70 0x71 0x72 0x73 0x74 0x75 - 0x60 0x61 0x62 0x63 0x64 0x65>; - reg-names = "main", "dpll", "cp", "hdmi", "edid", "repeater", - "infoframe", "cbus", "cec", "sdp", "txa", "txb"; - - #address-cells = <1>; - #size-cells = <0>; - - interrupt-parent = <&gpio6>; - interrupt-names = "intrq1", "intrq2"; - interrupts = <30 IRQ_TYPE_LEVEL_LOW>, - <31 IRQ_TYPE_LEVEL_LOW>; - - port@7 { - reg = <7>; - - adv7482_ain7: endpoint { - remote-endpoint = <&cvbs_in>; - }; - }; - - port@8 { - reg = <8>; - - adv7482_hdmi: endpoint { - remote-endpoint = <&hdmi_in>; - }; - }; - - port@a { - reg = <10>; - - adv7482_txa: endpoint { - clock-lanes = <0>; - data-lanes = <1 2 3 4>; - remote-endpoint = <&csi40_in>; - }; - }; - - port@b { - reg = <11>; - - adv7482_txb: endpoint { - clock-lanes = <0>; - data-lanes = <1>; - remote-endpoint = <&csi20_in>; - }; - }; - }; diff --git a/Documentation/devicetree/bindings/media/i2c/adv748x.yaml b/Documentation/devicetree/bindings/media/i2c/adv748x.yaml new file mode 100644 index 000000000000..d6353081402b --- /dev/null +++ b/Documentation/devicetree/bindings/media/i2c/adv748x.yaml @@ -0,0 +1,212 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/media/i2c/adv748x.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Analog Devices ADV748X video decoder with HDMI receiver + +maintainers: + - Kieran Bingham <kieran.bingham@ideasonboard.com> + - Niklas Söderlund <niklas.soderlund@ragnatech.se> + +description: + The ADV7481 and ADV7482 are multi format video decoders with an integrated + HDMI receiver. They can output CSI-2 on two independent outputs TXA and TXB + from three input sources HDMI, analog and TTL. + +properties: + compatible: + items: + - enum: + - adi,adv7481 + - adi,adv7482 + + reg: + minItems: 1 + maxItems: 12 + description: + The ADV748x has up to twelve 256-byte maps that can be accessed via the + main I2C ports. Each map has it own I2C address and acts as a standard + slave device on the I2C bus. The main address is mandatory, others are + optional and remain at default values if not specified. + + reg-names: + minItems: 1 + items: + - const: main + - enum: [ dpll, cp, hdmi, edid, repeater, infoframe, cbus, cec, sdp, txa, txb ] + - enum: [ dpll, cp, hdmi, edid, repeater, infoframe, cbus, cec, sdp, txa, txb ] + - enum: [ dpll, cp, hdmi, edid, repeater, infoframe, cbus, cec, sdp, txa, txb ] + - enum: [ dpll, cp, hdmi, edid, repeater, infoframe, cbus, cec, sdp, txa, txb ] + - enum: [ dpll, cp, hdmi, edid, repeater, infoframe, cbus, cec, sdp, txa, txb ] + - enum: [ dpll, cp, hdmi, edid, repeater, infoframe, cbus, cec, sdp, txa, txb ] + - enum: [ dpll, cp, hdmi, edid, repeater, infoframe, cbus, cec, sdp, txa, txb ] + - enum: [ dpll, cp, hdmi, edid, repeater, infoframe, cbus, cec, sdp, txa, txb ] + - enum: [ dpll, cp, hdmi, edid, repeater, infoframe, cbus, cec, sdp, txa, txb ] + - enum: [ dpll, cp, hdmi, edid, repeater, infoframe, cbus, cec, sdp, txa, txb ] + - enum: [ dpll, cp, hdmi, edid, repeater, infoframe, cbus, cec, sdp, txa, txb ] + + interrupts: true + + interrupt-names: true + + ports: + $ref: /schemas/graph.yaml#/properties/ports + + patternProperties: + "^port@[0-7]$": + $ref: /schemas/graph.yaml#/properties/port + description: Input port nodes for analog inputs AIN[0-7]. + + properties: + port@8: + $ref: /schemas/graph.yaml#/properties/port + description: Input port node for HDMI. + + port@9: + $ref: /schemas/graph.yaml#/properties/port + description: Input port node for TTL. + + port@a: + $ref: /schemas/graph.yaml#/$defs/port-base + unevaluatedProperties: false + description: + Output port node, single endpoint describing the CSI-2 transmitter TXA. + + properties: + endpoint: + $ref: /schemas/media/video-interfaces.yaml# + unevaluatedProperties: false + + properties: + clock-lanes: + maxItems: 1 + + data-lanes: + minItems: 1 + maxItems: 4 + + required: + - clock-lanes + - data-lanes + + port@b: + $ref: /schemas/graph.yaml#/$defs/port-base + unevaluatedProperties: false + description: + Output port node, single endpoint describing the CSI-2 transmitter TXB. + + properties: + endpoint: + $ref: /schemas/media/video-interfaces.yaml# + unevaluatedProperties: false + + properties: + clock-lanes: + maxItems: 1 + + data-lanes: + maxItems: 1 + + required: + - clock-lanes + - data-lanes + +allOf: + - if: + properties: + compatible: + contains: + const: adi,adv7481 + then: + properties: + interrupts: + minItems: 1 + maxItems: 3 + + interrupt-names: + minItems: 1 + maxItems: 3 + items: + enum: [ intrq1, intrq2, intrq3 ] + else: + properties: + interrupts: + minItems: 1 + maxItems: 2 + + interrupt-names: + minItems: 1 + maxItems: 2 + items: + enum: [ intrq1, intrq2 ] + +additionalProperties: false + +required: + - compatible + - reg + - ports + +examples: + - | + #include <dt-bindings/interrupt-controller/irq.h> + + i2c { + #address-cells = <1>; + #size-cells = <0>; + + video-receiver@70 { + compatible = "adi,adv7482"; + reg = <0x70 0x71 0x72 0x73 0x74 0x75 + 0x60 0x61 0x62 0x63 0x64 0x65>; + reg-names = "main", "dpll", "cp", "hdmi", "edid", "repeater", + "infoframe", "cbus", "cec", "sdp", "txa", "txb"; + + interrupt-parent = <&gpio6>; + interrupts = <30 IRQ_TYPE_LEVEL_LOW>, <31 IRQ_TYPE_LEVEL_LOW>; + interrupt-names = "intrq1", "intrq2"; + + ports { + #address-cells = <1>; + #size-cells = <0>; + + port@7 { + reg = <7>; + + adv7482_ain7: endpoint { + remote-endpoint = <&cvbs_in>; + }; + }; + + port@8 { + reg = <8>; + + adv7482_hdmi: endpoint { + remote-endpoint = <&hdmi_in>; + }; + }; + + port@a { + reg = <10>; + + adv7482_txa: endpoint { + clock-lanes = <0>; + data-lanes = <1 2 3 4>; + remote-endpoint = <&csi40_in>; + }; + }; + + port@b { + reg = <11>; + + adv7482_txb: endpoint { + clock-lanes = <0>; + data-lanes = <1>; + remote-endpoint = <&csi20_in>; + }; + }; + }; + }; + }; diff --git a/Documentation/devicetree/bindings/media/i2c/maxim,max96712.yaml b/Documentation/devicetree/bindings/media/i2c/maxim,max96712.yaml new file mode 100644 index 000000000000..444f24838d3d --- /dev/null +++ b/Documentation/devicetree/bindings/media/i2c/maxim,max96712.yaml @@ -0,0 +1,111 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +# Copyright (C) 2021 Renesas Electronics Corp. +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/media/i2c/maxim,max96712.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Quad GMSL2 to CSI-2 Deserializer with GMSL1 Compatibility + +maintainers: + - Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se> + +description: | + The MAX96712 deserializer converts GMSL2 or GMSL1 serial inputs into MIPI + CSI-2 D-PHY or C-PHY formatted outputs. The device allows each link to + simultaneously transmit bidirectional control-channel data while forward + video transmissions are in progress. The MAX96712 can accommodate as many as + four remotely located sensors using industry-standard coax or STP + interconnects. + + Each GMSL2 serial link operates at a fixed rate of 3Gbps or 6Gbps in the + forward direction and 187.5Mbps in the reverse direction. In GMSL1 mode, the + MAX96712 can be paired with first-generation 3.12Gbps or 1.5Gbps GMSL1 + serializers or operate up to 3.12Gbps with GMSL2 serializers in GMSL1 mode. + +properties: + compatible: + const: maxim,max96712 + + reg: + description: I2C device address + maxItems: 1 + + enable-gpios: true + + ports: + $ref: /schemas/graph.yaml#/properties/ports + + properties: + port@0: + $ref: /schemas/graph.yaml#/properties/port + description: GMSL Input 0 + + port@1: + $ref: /schemas/graph.yaml#/properties/port + description: GMSL Input 1 + + port@2: + $ref: /schemas/graph.yaml#/properties/port + description: GMSL Input 2 + + port@3: + $ref: /schemas/graph.yaml#/properties/port + description: GMSL Input 3 + + port@4: + $ref: /schemas/graph.yaml#/$defs/port-base + unevaluatedProperties: false + description: CSI-2 Output + + properties: + endpoint: + $ref: /schemas/media/video-interfaces.yaml# + unevaluatedProperties: false + + properties: + data-lanes: true + + required: + - data-lanes + + required: + - port@4 + +required: + - compatible + - reg + - ports + +additionalProperties: false + +examples: + - | + #include <dt-bindings/gpio/gpio.h> + + i2c@e6508000 { + #address-cells = <1>; + #size-cells = <0>; + + reg = <0 0xe6508000>; + + gmsl0: gmsl-deserializer@49 { + compatible = "maxim,max96712"; + reg = <0x49>; + enable-gpios = <&pca9654_a 0 GPIO_ACTIVE_HIGH>; + + ports { + #address-cells = <1>; + #size-cells = <0>; + + port@4 { + reg = <4>; + max96712_out0: endpoint { + clock-lanes = <0>; + data-lanes = <1 2 3 4>; + remote-endpoint = <&csi40_in>; + }; + }; + }; + }; + }; diff --git a/Documentation/devicetree/bindings/media/nvidia,tegra-vde.txt b/Documentation/devicetree/bindings/media/nvidia,tegra-vde.txt deleted file mode 100644 index 602169b8aa19..000000000000 --- a/Documentation/devicetree/bindings/media/nvidia,tegra-vde.txt +++ /dev/null @@ -1,64 +0,0 @@ -NVIDIA Tegra Video Decoder Engine - -Required properties: -- compatible : Must contain one of the following values: - - "nvidia,tegra20-vde" - - "nvidia,tegra30-vde" - - "nvidia,tegra114-vde" - - "nvidia,tegra124-vde" - - "nvidia,tegra132-vde" -- reg : Must contain an entry for each entry in reg-names. -- reg-names : Must include the following entries: - - sxe - - bsev - - mbe - - ppe - - mce - - tfe - - ppb - - vdma - - frameid -- iram : Must contain phandle to the mmio-sram device node that represents - IRAM region used by VDE. -- interrupts : Must contain an entry for each entry in interrupt-names. -- interrupt-names : Must include the following entries: - - sync-token - - bsev - - sxe -- clocks : Must include the following entries: - - vde -- resets : Must contain an entry for each entry in reset-names. -- reset-names : Should include the following entries: - - vde - -Optional properties: -- resets : Must contain an entry for each entry in reset-names. -- reset-names : Must include the following entries: - - mc -- iommus: Must contain phandle to the IOMMU device node. - -Example: - -video-codec@6001a000 { - compatible = "nvidia,tegra20-vde"; - reg = <0x6001a000 0x1000 /* Syntax Engine */ - 0x6001b000 0x1000 /* Video Bitstream Engine */ - 0x6001c000 0x100 /* Macroblock Engine */ - 0x6001c200 0x100 /* Post-processing Engine */ - 0x6001c400 0x100 /* Motion Compensation Engine */ - 0x6001c600 0x100 /* Transform Engine */ - 0x6001c800 0x100 /* Pixel prediction block */ - 0x6001ca00 0x100 /* Video DMA */ - 0x6001d800 0x300 /* Video frame controls */>; - reg-names = "sxe", "bsev", "mbe", "ppe", "mce", - "tfe", "ppb", "vdma", "frameid"; - iram = <&vde_pool>; /* IRAM region */ - interrupts = <GIC_SPI 9 IRQ_TYPE_LEVEL_HIGH>, /* Sync token interrupt */ - <GIC_SPI 10 IRQ_TYPE_LEVEL_HIGH>, /* BSE-V interrupt */ - <GIC_SPI 12 IRQ_TYPE_LEVEL_HIGH>; /* SXE interrupt */ - interrupt-names = "sync-token", "bsev", "sxe"; - clocks = <&tegra_car TEGRA20_CLK_VDE>; - reset-names = "vde", "mc"; - resets = <&tegra_car 61>, <&mc TEGRA20_MC_RESET_VDE>; - iommus = <&mc TEGRA_SWGROUP_VDE>; -}; diff --git a/Documentation/devicetree/bindings/media/nvidia,tegra-vde.yaml b/Documentation/devicetree/bindings/media/nvidia,tegra-vde.yaml new file mode 100644 index 000000000000..4ecdee1be37e --- /dev/null +++ b/Documentation/devicetree/bindings/media/nvidia,tegra-vde.yaml @@ -0,0 +1,119 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/media/nvidia,tegra-vde.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: NVIDIA Tegra Video Decoder Engine + +maintainers: + - Dmitry Osipenko <digetx@gmail.com> + - Jon Hunter <jonathanh@nvidia.com> + - Thierry Reding <thierry.reding@gmail.com> + +properties: + compatible: + oneOf: + - items: + - enum: + - nvidia,tegra132-vde + - nvidia,tegra124-vde + - nvidia,tegra114-vde + - items: + - const: nvidia,tegra30-vde + - const: nvidia,tegra20-vde + - items: + - const: nvidia,tegra20-vde + + reg: + maxItems: 9 + + reg-names: + items: + - const: sxe + - const: bsev + - const: mbe + - const: ppe + - const: mce + - const: tfe + - const: ppb + - const: vdma + - const: frameid + + clocks: + maxItems: 1 + + resets: + maxItems: 2 + + reset-names: + items: + - const: vde + - const: mc + + interrupts: + maxItems: 3 + + interrupt-names: + items: + - const: sync-token + - const: bsev + - const: sxe + + iommus: + maxItems: 1 + + iram: + $ref: /schemas/types.yaml#/definitions/phandle + description: + Phandle of the SRAM MMIO node. + + operating-points-v2: + description: + Should contain freqs and voltages and opp-supported-hw property, + which is a bitfield indicating SoC speedo or process ID mask. + + power-domains: + maxItems: 1 + description: + Phandle to the SoC core power domain. + +required: + - compatible + - reg + - reg-names + - clocks + - resets + - reset-names + - interrupts + - interrupt-names + +additionalProperties: false + +examples: + - | + video-codec@6001a000 { + compatible = "nvidia,tegra20-vde"; + reg = <0x6001a000 0x1000>, /* Syntax Engine */ + <0x6001b000 0x1000>, /* Video Bitstream Engine */ + <0x6001c000 0x100>, /* Macroblock Engine */ + <0x6001c200 0x100>, /* Post-processing Engine */ + <0x6001c400 0x100>, /* Motion Compensation Engine */ + <0x6001c600 0x100>, /* Transform Engine */ + <0x6001c800 0x100>, /* Pixel prediction block */ + <0x6001ca00 0x100>, /* Video DMA */ + <0x6001d800 0x300>; /* Video frame controls */ + reg-names = "sxe", "bsev", "mbe", "ppe", "mce", + "tfe", "ppb", "vdma", "frameid"; + iram = <&iram>; /* IRAM MMIO region */ + interrupts = <0 9 4>, /* Sync token */ + <0 10 4>, /* BSE-V */ + <0 12 4>; /* SXE */ + interrupt-names = "sync-token", "bsev", "sxe"; + clocks = <&clk 61>; + reset-names = "vde", "mc"; + resets = <&rst 61>, <&mem 13>; + iommus = <&mem 15>; + operating-points-v2 = <&dvfs_opp_table>; + power-domains = <&domain>; + }; diff --git a/Documentation/devicetree/bindings/media/nxp,imx7-mipi-csi2.yaml b/Documentation/devicetree/bindings/media/nxp,imx7-mipi-csi2.yaml index 877183cf4278..e2e6e9aa0fe6 100644 --- a/Documentation/devicetree/bindings/media/nxp,imx7-mipi-csi2.yaml +++ b/Documentation/devicetree/bindings/media/nxp,imx7-mipi-csi2.yaml @@ -79,30 +79,18 @@ properties: properties: data-lanes: + description: + Note that 'fsl,imx7-mipi-csi2' only supports up to 2 data lines. + minItems: 1 items: - minItems: 1 - maxItems: 4 - items: - - const: 1 - - const: 2 - - const: 3 - - const: 4 + - const: 1 + - const: 2 + - const: 3 + - const: 4 required: - data-lanes - allOf: - - if: - properties: - compatible: - contains: - const: fsl,imx7-mipi-csi2 - then: - properties: - data-lanes: - items: - maxItems: 2 - port@1: $ref: /schemas/graph.yaml#/properties/port description: diff --git a/Documentation/devicetree/bindings/media/nxp,imx8mq-mipi-csi2.yaml b/Documentation/devicetree/bindings/media/nxp,imx8mq-mipi-csi2.yaml index 9c04fa85ee5c..1b3e1c4b99ed 100644 --- a/Documentation/devicetree/bindings/media/nxp,imx8mq-mipi-csi2.yaml +++ b/Documentation/devicetree/bindings/media/nxp,imx8mq-mipi-csi2.yaml @@ -87,14 +87,12 @@ properties: properties: data-lanes: + minItems: 1 items: - minItems: 1 - maxItems: 4 - items: - - const: 1 - - const: 2 - - const: 3 - - const: 4 + - const: 1 + - const: 2 + - const: 3 + - const: 4 required: - data-lanes diff --git a/Documentation/devicetree/bindings/media/renesas,jpu.txt b/Documentation/devicetree/bindings/media/renesas,jpu.txt deleted file mode 100644 index d3436e5190f9..000000000000 --- a/Documentation/devicetree/bindings/media/renesas,jpu.txt +++ /dev/null @@ -1,25 +0,0 @@ -* Renesas JPEG Processing Unit - -The JPEG processing unit (JPU) incorporates the JPEG codec with an encoding -and decoding function conforming to the JPEG baseline process, so that the JPU -can encode image data and decode JPEG data quickly. - -Required properties: -- compatible: "renesas,jpu-<soctype>", "renesas,rcar-gen2-jpu" as fallback. - Examples with soctypes are: - - "renesas,jpu-r8a7790" for R-Car H2 - - "renesas,jpu-r8a7791" for R-Car M2-W - - "renesas,jpu-r8a7792" for R-Car V2H - - "renesas,jpu-r8a7793" for R-Car M2-N - - - reg: Base address and length of the registers block for the JPU. - - interrupts: JPU interrupt specifier. - - clocks: A phandle + clock-specifier pair for the JPU functional clock. - -Example: R8A7790 (R-Car H2) JPU node - jpeg-codec@fe980000 { - compatible = "renesas,jpu-r8a7790", "renesas,rcar-gen2-jpu"; - reg = <0 0xfe980000 0 0x10300>; - interrupts = <0 272 IRQ_TYPE_LEVEL_HIGH>; - clocks = <&mstp1_clks R8A7790_CLK_JPU>; - }; diff --git a/Documentation/devicetree/bindings/media/renesas,jpu.yaml b/Documentation/devicetree/bindings/media/renesas,jpu.yaml new file mode 100644 index 000000000000..2f55968e864f --- /dev/null +++ b/Documentation/devicetree/bindings/media/renesas,jpu.yaml @@ -0,0 +1,65 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/media/renesas,jpu.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Renesas JPEG Processing Unit + +maintainers: + - Mikhail Ulyanov <mikhail.ulyanov@cogentembedded.com> + +description: + The JPEG processing unit (JPU) incorporates the JPEG codec with an encoding + and decoding function conforming to the JPEG baseline process, so that the + JPU can encode image data and decode JPEG data quickly. + +properties: + compatible: + items: + - enum: + - renesas,jpu-r8a7790 # R-Car H2 + - renesas,jpu-r8a7791 # R-Car M2-W + - renesas,jpu-r8a7792 # R-Car V2H + - renesas,jpu-r8a7793 # R-Car M2-N + - const: renesas,rcar-gen2-jpu # R-Car Gen2 + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + clocks: + maxItems: 1 + + power-domains: + maxItems: 1 + + resets: + maxItems: 1 + +required: + - compatible + - reg + - interrupts + - clocks + - power-domains + - resets + +additionalProperties: false + +examples: + - | + #include <dt-bindings/clock/r8a7790-cpg-mssr.h> + #include <dt-bindings/interrupt-controller/arm-gic.h> + #include <dt-bindings/power/r8a7790-sysc.h> + + jpeg-codec@fe980000 { + compatible = "renesas,jpu-r8a7790", "renesas,rcar-gen2-jpu"; + reg = <0xfe980000 0x10300>; + interrupts = <GIC_SPI 272 IRQ_TYPE_LEVEL_HIGH>; + clocks = <&cpg CPG_MOD 106>; + power-domains = <&sysc R8A7790_PD_ALWAYS_ON>; + resets = <&cpg 106>; + }; diff --git a/Documentation/devicetree/bindings/media/st,stm32-dma2d.yaml b/Documentation/devicetree/bindings/media/st,stm32-dma2d.yaml new file mode 100644 index 000000000000..f97b4a246605 --- /dev/null +++ b/Documentation/devicetree/bindings/media/st,stm32-dma2d.yaml @@ -0,0 +1,71 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/media/st,stm32-dma2d.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: STMicroelectronics STM32 Chrom-Art Accelerator DMA2D binding + +description: + Chrom-ART Accelerator(DMA2D), graphical hardware accelerator + enabling enhanced graphical user interface with minimum CPU load + + It can perform the following operations. + + - Filling a part or the whole of a destination image with a specific color. + - Copying a part or the whole of a source image into a part or the whole of + a destination image. + - Copying a part or the whole of a source image into a part or the whole of + a destination image with a pixel format conversion. + - Blending a part and/or two complete source images with different pixel + format and copy the result into a part or the whole of a destination image + with a different color format. (TODO) + + +maintainers: + - Dillon Min <dillon.minfei@gmail.com> + +properties: + compatible: + const: st,stm32-dma2d + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + clocks: + maxItems: 1 + + clock-names: + items: + - const: dma2d + + resets: + maxItems: 1 + +required: + - compatible + - reg + - interrupts + - clocks + - clock-names + - resets + +additionalProperties: false + +examples: + - | + #include <dt-bindings/clock/stm32fx-clock.h> + #include <dt-bindings/mfd/stm32f4-rcc.h> + dma2d: dma2d@4002b000 { + compatible = "st,stm32-dma2d"; + reg = <0x4002b000 0xc00>; + interrupts = <90>; + resets = <&rcc STM32F4_AHB1_RESET(DMA2D)>; + clocks = <&rcc 0 STM32F4_AHB1_CLOCK(DMA2D)>; + clock-names = "dma2d"; + }; + +... diff --git a/Documentation/devicetree/bindings/memory-controllers/nvidia,tegra186-mc.yaml b/Documentation/devicetree/bindings/memory-controllers/nvidia,tegra186-mc.yaml index 611bda38d187..13c4c82fd0d3 100644 --- a/Documentation/devicetree/bindings/memory-controllers/nvidia,tegra186-mc.yaml +++ b/Documentation/devicetree/bindings/memory-controllers/nvidia,tegra186-mc.yaml @@ -31,12 +31,15 @@ properties: - enum: - nvidia,tegra186-mc - nvidia,tegra194-mc + - nvidia,tegra234-mc reg: - maxItems: 1 + minItems: 1 + maxItems: 3 interrupts: - maxItems: 1 + items: + - description: MC general interrupt "#address-cells": const: 2 @@ -48,6 +51,9 @@ properties: dma-ranges: true + "#interconnect-cells": + const: 1 + patternProperties: "^external-memory-controller@[0-9a-f]+$": description: @@ -63,12 +69,15 @@ patternProperties: - enum: - nvidia,tegra186-emc - nvidia,tegra194-emc + - nvidia,tegra234-emc reg: - maxItems: 1 + minItems: 1 + maxItems: 2 interrupts: - maxItems: 1 + items: + - description: EMC general interrupt clocks: items: @@ -78,11 +87,83 @@ patternProperties: items: - const: emc + "#interconnect-cells": + const: 0 + nvidia,bpmp: $ref: /schemas/types.yaml#/definitions/phandle description: phandle of the node representing the BPMP + allOf: + - if: + properties: + compatible: + const: nvidia,tegra186-emc + then: + properties: + reg: + maxItems: 1 + + - if: + properties: + compatible: + const: nvidia,tegra194-emc + then: + properties: + reg: + minItems: 2 + + - if: + properties: + compatible: + const: nvidia,tegra234-emc + then: + properties: + reg: + minItems: 2 + + additionalProperties: false + + required: + - compatible + - reg + - interrupts + - clocks + - clock-names + - "#interconnect-cells" + - nvidia,bpmp + +allOf: + - if: + properties: + compatible: + const: nvidia,tegra186-mc + then: + properties: + reg: + maxItems: 1 + + - if: + properties: + compatible: + const: nvidia,tegra194-mc + then: + properties: + reg: + minItems: 3 + + - if: + properties: + compatible: + const: nvidia,tegra234-mc + then: + properties: + reg: + minItems: 3 + +additionalProperties: false + required: - compatible - reg @@ -90,8 +171,6 @@ required: - "#address-cells" - "#size-cells" -additionalProperties: false - examples: - | #include <dt-bindings/clock/tegra186-clock.h> @@ -124,12 +203,9 @@ examples: clocks = <&bpmp TEGRA186_CLK_EMC>; clock-names = "emc"; + #interconnect-cells = <0>; + nvidia,bpmp = <&bpmp>; }; }; }; - - bpmp: bpmp { - compatible = "nvidia,tegra186-bpmp"; - #clock-cells = <1>; - }; diff --git a/Documentation/devicetree/bindings/memory-controllers/renesas,rpc-if.yaml b/Documentation/devicetree/bindings/memory-controllers/renesas,rpc-if.yaml index 9da80e8f2444..294f1036420d 100644 --- a/Documentation/devicetree/bindings/memory-controllers/renesas,rpc-if.yaml +++ b/Documentation/devicetree/bindings/memory-controllers/renesas,rpc-if.yaml @@ -24,17 +24,23 @@ allOf: properties: compatible: - items: - - enum: - - renesas,r8a774a1-rpc-if # RZ/G2M - - renesas,r8a774b1-rpc-if # RZ/G2N - - renesas,r8a774c0-rpc-if # RZ/G2E - - renesas,r8a774e1-rpc-if # RZ/G2H - - renesas,r8a77970-rpc-if # R-Car V3M - - renesas,r8a77980-rpc-if # R-Car V3H - - renesas,r8a77995-rpc-if # R-Car D3 - - renesas,r8a779a0-rpc-if # R-Car V3U - - const: renesas,rcar-gen3-rpc-if # a generic R-Car gen3 or RZ/G2 device + oneOf: + - items: + - enum: + - renesas,r8a774a1-rpc-if # RZ/G2M + - renesas,r8a774b1-rpc-if # RZ/G2N + - renesas,r8a774c0-rpc-if # RZ/G2E + - renesas,r8a774e1-rpc-if # RZ/G2H + - renesas,r8a77970-rpc-if # R-Car V3M + - renesas,r8a77980-rpc-if # R-Car V3H + - renesas,r8a77995-rpc-if # R-Car D3 + - renesas,r8a779a0-rpc-if # R-Car V3U + - const: renesas,rcar-gen3-rpc-if # a generic R-Car gen3 or RZ/G2{E,H,M,N} device + + - items: + - enum: + - renesas,r9a07g044-rpc-if # RZ/G2{L,LC} + - const: renesas,rzg2l-rpc-if # RZ/G2L family reg: items: @@ -48,7 +54,9 @@ properties: - const: dirmap - const: wbuf - clocks: + clocks: true + + interrupts: maxItems: 1 power-domains: @@ -67,8 +75,6 @@ patternProperties: - cfi-flash - jedec,spi-nor -unevaluatedProperties: false - required: - compatible - reg @@ -79,6 +85,26 @@ required: - '#address-cells' - '#size-cells' +if: + properties: + compatible: + contains: + enum: + - renesas,rzg2l-rpc-if +then: + properties: + clocks: + items: + - description: SPI Multi IO Register access clock (SPI_CLK2) + - description: SPI Multi IO Main clock (SPI_CLK). + +else: + properties: + clocks: + maxItems: 1 + +unevaluatedProperties: false + examples: - | #include <dt-bindings/clock/renesas-cpg-mssr.h> diff --git a/Documentation/devicetree/bindings/memory-controllers/synopsys,ddrc-ecc.yaml b/Documentation/devicetree/bindings/memory-controllers/synopsys,ddrc-ecc.yaml index a24588474625..fb7ae38a9c86 100644 --- a/Documentation/devicetree/bindings/memory-controllers/synopsys,ddrc-ecc.yaml +++ b/Documentation/devicetree/bindings/memory-controllers/synopsys,ddrc-ecc.yaml @@ -26,6 +26,7 @@ properties: enum: - xlnx,zynq-ddrc-a05 - xlnx,zynqmp-ddrc-2.40a + - snps,ddrc-3.80a interrupts: maxItems: 1 diff --git a/Documentation/devicetree/bindings/memory-controllers/ti,gpmc.yaml b/Documentation/devicetree/bindings/memory-controllers/ti,gpmc.yaml index 25b42d68f9b3..e188a4bf755c 100644 --- a/Documentation/devicetree/bindings/memory-controllers/ti,gpmc.yaml +++ b/Documentation/devicetree/bindings/memory-controllers/ti,gpmc.yaml @@ -23,13 +23,20 @@ properties: items: - enum: - ti,am3352-gpmc + - ti,am64-gpmc - ti,omap2420-gpmc - ti,omap2430-gpmc - ti,omap3430-gpmc - ti,omap4430-gpmc reg: - maxItems: 1 + minItems: 1 + maxItems: 2 + + reg-names: + items: + - const: cfg + - const: data interrupts: maxItems: 1 @@ -44,6 +51,9 @@ properties: items: - const: fck + power-domains: + maxItems: 1 + dmas: items: - description: DMA channel for GPMC NAND prefetch @@ -119,11 +129,8 @@ patternProperties: The child device node represents the device connected to the GPMC bus. The device can be a NAND chip, SRAM device, NOR device or an ASIC. + $ref: "ti,gpmc-child.yaml" - allOf: - - $ref: "ti,gpmc-child.yaml" - - unevaluatedProperties: false required: - compatible @@ -133,6 +140,17 @@ required: - "#address-cells" - "#size-cells" +allOf: + - if: + properties: + compatible: + contains: + const: ti,am64-gpmc + then: + required: + - reg-names + - power-domains + additionalProperties: false examples: diff --git a/Documentation/devicetree/bindings/mfd/bd9571mwv.txt b/Documentation/devicetree/bindings/mfd/bd9571mwv.txt deleted file mode 100644 index 1d6413e96c37..000000000000 --- a/Documentation/devicetree/bindings/mfd/bd9571mwv.txt +++ /dev/null @@ -1,69 +0,0 @@ -* ROHM BD9571MWV/BD9574MWF Power Management Integrated Circuit (PMIC) bindings - -Required properties: - - compatible : Should be "rohm,bd9571mwv" or "rohm,bd9574mwf". - - reg : I2C slave address. - - interrupts : The interrupt line the device is connected to. - - interrupt-controller : Marks the device node as an interrupt controller. - - #interrupt-cells : The number of cells to describe an IRQ, should be 2. - The first cell is the IRQ number. - The second cell is the flags, encoded as trigger - masks from ../interrupt-controller/interrupts.txt. - - gpio-controller : Marks the device node as a GPIO Controller. - - #gpio-cells : Should be two. The first cell is the pin number and - the second cell is used to specify flags. - See ../gpio/gpio.txt for more information. - - regulators: : List of child nodes that specify the regulator - initialization data. Child nodes must be named - after their hardware counterparts: - - vd09 - - vd18 - - vd25 - - vd33 - - dvfs - Each child node is defined using the standard - binding for regulators. - -Optional properties: - - rohm,ddr-backup-power : Value to use for DDR-Backup Power (default 0). - This is a bitmask that specifies which DDR power - rails need to be kept powered when backup mode is - entered, for system suspend: - - bit 0: DDR0 - - bit 1: DDR1 - - bit 2: DDR0C - - bit 3: DDR1C - These bits match the KEEPON_DDR* bits in the - documentation for the "BKUP Mode Cnt" register. - - rohm,rstbmode-level: The RSTB signal is configured for level mode, to - accommodate a toggle power switch (the RSTBMODE pin is - strapped low). - - rohm,rstbmode-pulse: The RSTB signal is configured for pulse mode, to - accommodate a momentary power switch (the RSTBMODE pin - is strapped high). - The two properties above are mutually exclusive. - -Example: - - pmic: pmic@30 { - compatible = "rohm,bd9571mwv"; - reg = <0x30>; - interrupt-parent = <&gpio2>; - interrupts = <0 IRQ_TYPE_LEVEL_LOW>; - interrupt-controller; - #interrupt-cells = <2>; - gpio-controller; - #gpio-cells = <2>; - rohm,ddr-backup-power = <0xf>; - rohm,rstbmode-pulse; - - regulators { - dvfs: dvfs { - regulator-name = "dvfs"; - regulator-min-microvolt = <750000>; - regulator-max-microvolt = <1030000>; - regulator-boot-on; - regulator-always-on; - }; - }; - }; diff --git a/Documentation/devicetree/bindings/mfd/brcm,twd.yaml b/Documentation/devicetree/bindings/mfd/brcm,twd.yaml new file mode 100644 index 000000000000..634526f790b8 --- /dev/null +++ b/Documentation/devicetree/bindings/mfd/brcm,twd.yaml @@ -0,0 +1,61 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/mfd/brcm,twd.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Broadcom's Timer-Watchdog (aka TWD) + +maintainers: + - Rafał Miłecki <rafal@milecki.pl> + +description: | + Broadcom has a Timer-Watchdog block used in multiple SoCs (e.g., BCM4908, + BCM63xx, BCM7038). There are few variants available (they differ slightly in + registers layout). This block consists of: timers, watchdog and optionally a + software reset handler. + +properties: + compatible: + items: + - enum: + - brcm,bcm4908-twd + - brcm,bcm7038-twd + - const: simple-mfd + - const: syscon + + reg: + maxItems: 1 + + ranges: true + + "#address-cells": + const: 1 + + "#size-cells": + const: 1 + +patternProperties: + '^watchdog@[a-f0-9]+$': + $ref: /schemas/watchdog/brcm,bcm7038-wdt.yaml + +additionalProperties: false + +required: + - reg + +examples: + - | + timer-mfd@ff800400 { + compatible = "brcm,bcm4908-twd", "simple-mfd", "syscon"; + reg = <0xff800400 0x4c>; + ranges = <0x00000000 0xff800400 0x4c>; + + #address-cells = <1>; + #size-cells = <1>; + + watchdog@28 { + compatible = "brcm,bcm7038-wdt"; + reg = <0x28 0x8>; + }; + }; diff --git a/Documentation/devicetree/bindings/mfd/cirrus,madera.yaml b/Documentation/devicetree/bindings/mfd/cirrus,madera.yaml index 499c62c04daa..68c75a517c92 100644 --- a/Documentation/devicetree/bindings/mfd/cirrus,madera.yaml +++ b/Documentation/devicetree/bindings/mfd/cirrus,madera.yaml @@ -221,7 +221,6 @@ required: - '#gpio-cells' - interrupt-controller - '#interrupt-cells' - - interrupt-parent - interrupts - AVDD-supply - DBVDD1-supply @@ -246,8 +245,7 @@ examples: interrupt-controller; #interrupt-cells = <2>; - interrupts = <&host_irq1>; - interrupt-parent = <&gic>; + interrupts = <4 1 0>; gpio-controller; #gpio-cells = <2>; diff --git a/Documentation/devicetree/bindings/mfd/da9063.txt b/Documentation/devicetree/bindings/mfd/da9063.txt index 8da879935c59..91b79a21d403 100644 --- a/Documentation/devicetree/bindings/mfd/da9063.txt +++ b/Documentation/devicetree/bindings/mfd/da9063.txt @@ -1,6 +1,6 @@ * Dialog DA9063/DA9063L Power Management Integrated Circuit (PMIC) -DA9093 consists of a large and varied group of sub-devices (I2C Only): +DA9063 consists of a large and varied group of sub-devices (I2C Only): Device Supply Names Description ------ ------------ ----------- diff --git a/Documentation/devicetree/bindings/mfd/google,cros-ec.yaml b/Documentation/devicetree/bindings/mfd/google,cros-ec.yaml index d793dd0316b7..d1f53bd449f7 100644 --- a/Documentation/devicetree/bindings/mfd/google,cros-ec.yaml +++ b/Documentation/devicetree/bindings/mfd/google,cros-ec.yaml @@ -8,7 +8,6 @@ title: ChromeOS Embedded Controller maintainers: - Benson Leung <bleung@chromium.org> - - Enric Balletbo i Serra <enric.balletbo@collabora.com> - Guenter Roeck <groeck@chromium.org> description: @@ -59,7 +58,7 @@ properties: whether this nvram is present or not. type: boolean - mtk,rpmsg-name: + mediatek,rpmsg-name: description: Must be defined if the cros-ec is a rpmsg device for a Mediatek ARM Cortex M4 Co-processor. Contains the name pf the rpmsg diff --git a/Documentation/devicetree/bindings/mfd/max77686.txt b/Documentation/devicetree/bindings/mfd/max77686.txt deleted file mode 100644 index 4447d074894a..000000000000 --- a/Documentation/devicetree/bindings/mfd/max77686.txt +++ /dev/null @@ -1,26 +0,0 @@ -Maxim MAX77686 multi-function device - -MAX77686 is a Multifunction device with PMIC, RTC and Charger on chip. It is -interfaced to host controller using i2c interface. PMIC and Charger submodules -are addressed using same i2c slave address whereas RTC submodule uses -different i2c slave address,presently for which we are statically creating i2c -client while probing.This document describes the binding for mfd device and -PMIC submodule. - -Bindings for the built-in 32k clock generator block and -regulators are defined in ../clk/maxim,max77686.txt and -../regulator/max77686.txt respectively. - -Required properties: -- compatible : Must be "maxim,max77686"; -- reg : Specifies the i2c slave address of PMIC block. -- interrupts : This i2c device has an IRQ line connected to the main SoC. - -Example: - - max77686: pmic@9 { - compatible = "maxim,max77686"; - interrupt-parent = <&wakeup_eint>; - interrupts = <26 IRQ_TYPE_LEVEL_LOW>; - reg = <0x09>; - }; diff --git a/Documentation/devicetree/bindings/mfd/maxim,max77686.yaml b/Documentation/devicetree/bindings/mfd/maxim,max77686.yaml new file mode 100644 index 000000000000..859655a789c3 --- /dev/null +++ b/Documentation/devicetree/bindings/mfd/maxim,max77686.yaml @@ -0,0 +1,132 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/mfd/maxim,max77686.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Maxim MAX77686 Power Management IC + +maintainers: + - Chanwoo Choi <cw00.choi@samsung.com> + - Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com> + +description: | + This is a part of device tree bindings for Maxim MAX77686 Power Management + Integrated Circuit (PMIC). + + The Maxim MAX77686 is a Power Management IC which includes voltage and + current regulators, RTC and clock outputs. + + The MAX77686 provides three 32.768khz clock outputs that can be controlled + (gated/ungated) over I2C. The clock IDs are defined as preprocessor macros + in dt-bindings/clock/maxim,max77686.h. + +properties: + compatible: + const: maxim,max77686 + + '#clock-cells': + const: 1 + + interrupts: + maxItems: 1 + + reg: + maxItems: 1 + + voltage-regulators: + $ref: ../regulator/maxim,max77686.yaml + description: + List of child nodes that specify the regulators. + + wakeup-source: true + +required: + - compatible + - '#clock-cells' + - reg + +additionalProperties: false + +examples: + - | + #include <dt-bindings/gpio/gpio.h> + #include <dt-bindings/interrupt-controller/irq.h> + + i2c { + #address-cells = <1>; + #size-cells = <0>; + + max77686: pmic@9 { + compatible = "maxim,max77686"; + reg = <0x09>; + + interrupt-parent = <&gpx0>; + interrupts = <7 IRQ_TYPE_LEVEL_LOW>; + pinctrl-0 = <&max77686_irq>; + pinctrl-names = "default"; + wakeup-source; + #clock-cells = <1>; + + voltage-regulators { + LDO1 { + regulator-name = "VALIVE_1.0V_AP"; + regulator-min-microvolt = <1000000>; + regulator-max-microvolt = <1000000>; + regulator-always-on; + }; + + LDO2 { + regulator-name = "VM1M2_1.2V_AP"; + regulator-min-microvolt = <1200000>; + regulator-max-microvolt = <1200000>; + regulator-always-on; + regulator-state-mem { + regulator-on-in-suspend; + }; + }; + + // ... + + LDO22 { + regulator-name = "VMEM_VDD_2.8V"; + regulator-min-microvolt = <2800000>; + regulator-max-microvolt = <2800000>; + maxim,ena-gpios = <&gpk0 2 GPIO_ACTIVE_HIGH>; + }; + + // ... + + BUCK1 { + regulator-name = "VDD_MIF"; + regulator-min-microvolt = <850000>; + regulator-max-microvolt = <1100000>; + regulator-always-on; + regulator-boot-on; + regulator-state-mem { + regulator-off-in-suspend; + }; + }; + + BUCK2 { + regulator-name = "VDD_ARM"; + regulator-min-microvolt = <850000>; + regulator-max-microvolt = <1500000>; + regulator-always-on; + regulator-boot-on; + regulator-state-mem { + regulator-on-in-suspend; + }; + }; + + // ... + + BUCK9 { + regulator-name = "CAM_ISP_CORE_1.2V"; + regulator-min-microvolt = <1000000>; + regulator-max-microvolt = <1200000>; + maxim,ena-gpios = <&gpm0 3 GPIO_ACTIVE_HIGH>; + }; + }; + }; + }; diff --git a/Documentation/devicetree/bindings/mfd/rohm,bd70528-pmic.txt b/Documentation/devicetree/bindings/mfd/rohm,bd70528-pmic.txt deleted file mode 100644 index 386eec06cf08..000000000000 --- a/Documentation/devicetree/bindings/mfd/rohm,bd70528-pmic.txt +++ /dev/null @@ -1,102 +0,0 @@ -* ROHM BD70528 Power Management Integrated Circuit bindings - -BD70528MWV is an ultra-low quiescent current general purpose, single-chip, -power management IC for battery-powered portable devices. The IC -integrates 3 ultra-low current consumption buck converters, 3 LDOs and 2 -LED Drivers. Also included are 4 GPIOs, a real-time clock (RTC), a 32kHz -clock gate, high-accuracy VREF for use with an external ADC, flexible -dual-input power path, 10 bit SAR ADC for battery temperature monitor and -1S battery charger with scalable charge currents. - -Required properties: - - compatible : Should be "rohm,bd70528" - - reg : I2C slave address. - - interrupts : The interrupt line the device is connected to. - - interrupt-controller : To indicate BD70528 acts as an interrupt controller. - - #interrupt-cells : Should be 2. Usage is compliant to the 2 cells - variant of ../interrupt-controller/interrupts.txt - - gpio-controller : To indicate BD70528 acts as a GPIO controller. - - #gpio-cells : Should be 2. The first cell is the pin number and - the second cell is used to specify flags. See - ../gpio/gpio.txt for more information. - - #clock-cells : Should be 0. - - regulators: : List of child nodes that specify the regulators. - Please see ../regulator/rohm,bd70528-regulator.txt - -Optional properties: - - clock-output-names : Should contain name for output clock. - -Example: -/* External oscillator */ -osc: oscillator { - compatible = "fixed-clock"; - #clock-cells = <1>; - clock-frequency = <32768>; - clock-output-names = "osc"; -}; - -pmic: pmic@4b { - compatible = "rohm,bd70528"; - reg = <0x4b>; - interrupt-parent = <&gpio1>; - interrupts = <29 IRQ_TYPE_LEVEL_LOW>; - clocks = <&osc 0>; - #clock-cells = <0>; - clock-output-names = "bd70528-32k-out"; - #gpio-cells = <2>; - gpio-controller; - interrupt-controller; - #interrupt-cells = <2>; - - regulators { - buck1: BUCK1 { - regulator-name = "buck1"; - regulator-min-microvolt = <1200000>; - regulator-max-microvolt = <3400000>; - regulator-boot-on; - regulator-ramp-delay = <125>; - }; - buck2: BUCK2 { - regulator-name = "buck2"; - regulator-min-microvolt = <1200000>; - regulator-max-microvolt = <3300000>; - regulator-boot-on; - regulator-ramp-delay = <125>; - }; - buck3: BUCK3 { - regulator-name = "buck3"; - regulator-min-microvolt = <800000>; - regulator-max-microvolt = <1800000>; - regulator-boot-on; - regulator-ramp-delay = <250>; - }; - ldo1: LDO1 { - regulator-name = "ldo1"; - regulator-min-microvolt = <1650000>; - regulator-max-microvolt = <3300000>; - regulator-boot-on; - }; - ldo2: LDO2 { - regulator-name = "ldo2"; - regulator-min-microvolt = <1650000>; - regulator-max-microvolt = <3300000>; - regulator-boot-on; - }; - - ldo3: LDO3 { - regulator-name = "ldo3"; - regulator-min-microvolt = <1650000>; - regulator-max-microvolt = <3300000>; - }; - led_ldo1: LED_LDO1 { - regulator-name = "led_ldo1"; - regulator-min-microvolt = <200000>; - regulator-max-microvolt = <300000>; - }; - led_ldo2: LED_LDO2 { - regulator-name = "led_ldo2"; - regulator-min-microvolt = <200000>; - regulator-max-microvolt = <300000>; - }; - }; -}; diff --git a/Documentation/devicetree/bindings/mfd/rohm,bd9571mwv.yaml b/Documentation/devicetree/bindings/mfd/rohm,bd9571mwv.yaml new file mode 100644 index 000000000000..89f9efee465b --- /dev/null +++ b/Documentation/devicetree/bindings/mfd/rohm,bd9571mwv.yaml @@ -0,0 +1,127 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/mfd/rohm,bd9571mwv.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: ROHM BD9571MWV/BD9574MWF Power Management Integrated Circuit (PMIC) + +maintainers: + - Marek Vasut <marek.vasut@gmail.com> + +properties: + compatible: + enum: + - rohm,bd9571mwv + - rohm,bd9574mwf + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + interrupt-controller: true + + '#interrupt-cells': + const: 2 + + gpio-controller: true + + '#gpio-cells': + const: 2 + + rohm,ddr-backup-power: + $ref: /schemas/types.yaml#/definitions/uint32 + minimum: 0x0 + maximum: 0xf + description: | + Value to use for DDR-Backup Power (default 0). + This is a bitmask that specifies which DDR power rails need to be kept + powered when backup mode is entered, for system suspend: + - bit 0: DDR0 + - bit 1: DDR1 + - bit 2: DDR0C + - bit 3: DDR1C + These bits match the KEEPON_DDR* bits in the documentation for the "BKUP + Mode Cnt" register. + + rohm,rstbmode-level: + $ref: /schemas/types.yaml#/definitions/flag + description: + The RSTB signal is configured for level mode, to accommodate a toggle + power switch (the RSTBMODE pin is strapped low). + + rohm,rstbmode-pulse: + $ref: /schemas/types.yaml#/definitions/flag + description: + The RSTB signal is configured for pulse mode, to accommodate a momentary + power switch (the RSTBMODE pin is strapped high). + + regulators: + type: object + description: + List of child nodes that specify the regulator initialization data. + Child nodes must be named after their hardware counterparts. + + patternProperties: + "^(vd09|vd18|vd25|vd33|dvfs)$": + type: object + $ref: ../regulator/regulator.yaml# + + properties: + regulator-name: + pattern: "^(vd09|vd18|vd25|vd33|dvfs)$" + + unevaluatedProperties: false + + additionalProperties: false + +additionalProperties: false + +required: + - compatible + - reg + - interrupts + - interrupt-controller + - '#interrupt-cells' + - gpio-controller + - '#gpio-cells' + +oneOf: + - required: + - rohm,rstbmode-level + - required: + - rohm,rstbmode-pulse + +examples: + - | + #include <dt-bindings/interrupt-controller/irq.h> + + i2c { + #address-cells = <1>; + #size-cells = <0>; + + pmic: pmic@30 { + compatible = "rohm,bd9571mwv"; + reg = <0x30>; + interrupt-parent = <&gpio2>; + interrupts = <0 IRQ_TYPE_LEVEL_LOW>; + interrupt-controller; + #interrupt-cells = <2>; + gpio-controller; + #gpio-cells = <2>; + rohm,ddr-backup-power = <0xf>; + rohm,rstbmode-pulse; + + regulators { + dvfs: dvfs { + regulator-name = "dvfs"; + regulator-min-microvolt = <750000>; + regulator-max-microvolt = <1030000>; + regulator-boot-on; + regulator-always-on; + }; + }; + }; + }; diff --git a/Documentation/devicetree/bindings/mfd/syscon.yaml b/Documentation/devicetree/bindings/mfd/syscon.yaml index 5de16388a089..eeac1cbc5a17 100644 --- a/Documentation/devicetree/bindings/mfd/syscon.yaml +++ b/Documentation/devicetree/bindings/mfd/syscon.yaml @@ -39,6 +39,7 @@ properties: - allwinner,sun8i-v3s-system-controller - allwinner,sun50i-a64-system-controller - brcm,cru-clkset + - freecom,fsg-cs2-system-controller - hisilicon,dsa-subctrl - hisilicon,hi6220-sramctrl - hisilicon,pcie-sas-subctrl @@ -57,6 +58,7 @@ properties: - samsung,exynos4-sysreg - samsung,exynos5-sysreg - samsung,exynos5433-sysreg + - samsung,exynos850-sysreg - samsung,exynosautov9-sysreg - const: syscon diff --git a/Documentation/devicetree/bindings/mips/loongson/ls2k-reset.yaml b/Documentation/devicetree/bindings/mips/loongson/ls2k-reset.yaml new file mode 100644 index 000000000000..20b5836efd90 --- /dev/null +++ b/Documentation/devicetree/bindings/mips/loongson/ls2k-reset.yaml @@ -0,0 +1,38 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: "http://devicetree.org/schemas/mips/loongson/ls2k-reset.yaml#" +$schema: "http://devicetree.org/meta-schemas/core.yaml#" + +title: Loongson 2K1000 PM Controller + +maintainers: + - Qing Zhang <zhangqing@loongson.cn> + +description: | + This controller can be found in Loongson-2K1000 Soc systems. + +properties: + compatible: + const: loongson,ls2k-pm + + reg: + maxItems: 1 + +required: + - compatible + - reg + +additionalProperties: false + +examples: + - | + bus { + #address-cells = <2>; + #size-cells = <2>; + pm: reset-controller@1fe07000 { + compatible = "loongson,ls2k-pm"; + reg = <0 0x1fe07000 0 0x422>; + }; + }; +... diff --git a/Documentation/devicetree/bindings/misc/nvidia,tegra186-misc.txt b/Documentation/devicetree/bindings/misc/nvidia,tegra186-misc.txt deleted file mode 100644 index 43d777ed8316..000000000000 --- a/Documentation/devicetree/bindings/misc/nvidia,tegra186-misc.txt +++ /dev/null @@ -1,14 +0,0 @@ -NVIDIA Tegra186 (and later) MISC register block - -The MISC register block found on Tegra186 and later SoCs contains registers -that can be used to identify a given chip and various strapping options. - -Required properties: -- compatible: Must be: - - Tegra186: "nvidia,tegra186-misc" - - Tegra194: "nvidia,tegra194-misc" - - Tegra234: "nvidia,tegra234-misc" -- reg: Should contain 2 entries: The first entry gives the physical address - and length of the register region which contains revision and debug - features. The second entry specifies the physical address and length - of the register region indicating the strapping options. diff --git a/Documentation/devicetree/bindings/misc/nvidia,tegra186-misc.yaml b/Documentation/devicetree/bindings/misc/nvidia,tegra186-misc.yaml new file mode 100644 index 000000000000..cacb845868f4 --- /dev/null +++ b/Documentation/devicetree/bindings/misc/nvidia,tegra186-misc.yaml @@ -0,0 +1,43 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/misc/nvidia,tegra186-misc.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: NVIDIA Tegra186 (and later) MISC register block + +maintainers: + - Thierry Reding <thierry.reding@gmail.com> + - Jon Hunter <jonathanh@nvidia.com> + +description: The MISC register block found on Tegra186 and later SoCs contains + registers that can be used to identify a given chip and various strapping + options. + +properties: + compatible: + enum: + - nvidia,tegra186-misc + - nvidia,tegra194-misc + - nvidia,tegra234-misc + + reg: + items: + - description: physical address and length of the registers which + contain revision and debug features + - description: physical address and length of the registers which + indicate strapping options + +additionalProperties: false + +required: + - compatible + - reg + +examples: + - | + misc@100000 { + compatible = "nvidia,tegra186-misc"; + reg = <0x00100000 0xf000>, + <0x0010f000 0x1000>; + }; diff --git a/Documentation/devicetree/bindings/misc/nvidia,tegra20-apbmisc.txt b/Documentation/devicetree/bindings/misc/nvidia,tegra20-apbmisc.txt deleted file mode 100644 index 83f6a251ba3e..000000000000 --- a/Documentation/devicetree/bindings/misc/nvidia,tegra20-apbmisc.txt +++ /dev/null @@ -1,17 +0,0 @@ -NVIDIA Tegra APBMISC block - -Required properties: -- compatible: Must be: - - Tegra20: "nvidia,tegra20-apbmisc" - - Tegra30: "nvidia,tegra30-apbmisc", "nvidia,tegra20-apbmisc" - - Tegra114: "nvidia,tegra114-apbmisc", "nvidia,tegra20-apbmisc" - - Tegra124: "nvidia,tegra124-apbmisc", "nvidia,tegra20-apbmisc" - - Tegra132: "nvidia,tegra124-apbmisc", "nvidia,tegra20-apbmisc" - - Tegra210: "nvidia,tegra210-apbmisc", "nvidia,tegra20-apbmisc" -- reg: Should contain 2 entries: the first entry gives the physical address - and length of the registers which contain revision and debug features. - The second entry gives the physical address and length of the - registers indicating the strapping options. - -Optional properties: -- nvidia,long-ram-code: If present, the RAM code is long (4 bit). If not, short (2 bit). diff --git a/Documentation/devicetree/bindings/misc/nvidia,tegra20-apbmisc.yaml b/Documentation/devicetree/bindings/misc/nvidia,tegra20-apbmisc.yaml new file mode 100644 index 000000000000..6f504fa74007 --- /dev/null +++ b/Documentation/devicetree/bindings/misc/nvidia,tegra20-apbmisc.yaml @@ -0,0 +1,51 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/misc/nvidia,tegra20-apbmisc.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: NVIDIA Tegra APBMISC block + +maintainers: + - Thierry Reding <thierry.reding@gmail.com> + - Jon Hunter <jonathanh@nvidia.com> + +properties: + compatible: + oneOf: + - items: + - enum: + - nvidia,tegra210-apbmisc + - nvidia,tegra124-apbmisc + - nvidia,tegra114-apbmisc + - nvidia,tegra30-apbmisc + - const: nvidia,tegra20-apbmisc + + - items: + - const: nvidia,tegra20-apbmisc + + reg: + items: + - description: physical address and length of the registers which + contain revision and debug features + - description: physical address and length of the registers which + indicate strapping options + + nvidia,long-ram-code: + description: If present, the RAM code is long (4 bit). If not, short + (2 bit). + type: boolean + +additionalProperties: false + +required: + - compatible + - reg + +examples: + - | + apbmisc@70000800 { + compatible = "nvidia,tegra20-apbmisc"; + reg = <0x70000800 0x64>, /* Chip revision */ + <0x70000008 0x04>; /* Strapping options */ + }; diff --git a/Documentation/devicetree/bindings/mmc/arasan,sdhci.yaml b/Documentation/devicetree/bindings/mmc/arasan,sdhci.yaml index de6f076e0ece..83be9e93d221 100644 --- a/Documentation/devicetree/bindings/mmc/arasan,sdhci.yaml +++ b/Documentation/devicetree/bindings/mmc/arasan,sdhci.yaml @@ -118,6 +118,9 @@ properties: phy-names: const: phy_arasan + resets: + maxItems: 1 + arasan,soc-ctl-syscon: $ref: /schemas/types.yaml#/definitions/phandle description: diff --git a/Documentation/devicetree/bindings/mmc/arm,pl18x.yaml b/Documentation/devicetree/bindings/mmc/arm,pl18x.yaml index 47595cb483be..1e69a5a42439 100644 --- a/Documentation/devicetree/bindings/mmc/arm,pl18x.yaml +++ b/Documentation/devicetree/bindings/mmc/arm,pl18x.yaml @@ -53,6 +53,12 @@ properties: items: - const: arm,pl18x - const: arm,primecell + - description: Entry for STMicroelectronics variant of PL18x. + This dedicated compatible is used by bootloaders. + items: + - const: st,stm32-sdmmc2 + - const: arm,pl18x + - const: arm,primecell clocks: description: One or two clocks, the "apb_pclk" and the "MCLK" @@ -60,6 +66,18 @@ properties: minItems: 1 maxItems: 2 + dmas: + maxItems: 2 + + dma-names: + oneOf: + - items: + - const: tx + - const: rx + - items: + - const: rx + - const: tx + power-domains: true resets: @@ -167,6 +185,9 @@ examples: clock-names = "mclk", "apb_pclk"; }; + - | + #include <dt-bindings/interrupt-controller/irq.h> + mmc@80126000 { compatible = "arm,pl18x", "arm,primecell"; reg = <0x80126000 0x1000>; @@ -188,12 +209,12 @@ examples: vqmmc-supply = <&vmmci>; }; + - | mmc@101f6000 { compatible = "arm,pl18x", "arm,primecell"; reg = <0x101f6000 0x1000>; clocks = <&sdiclk>, <&pclksdi>; clock-names = "mclk", "apb_pclk"; - interrupt-parent = <&vica>; interrupts = <22>; max-frequency = <400000>; bus-width = <4>; @@ -208,12 +229,12 @@ examples: vmmc-supply = <&vmmc_regulator>; }; + - | mmc@52007000 { compatible = "arm,pl18x", "arm,primecell"; arm,primecell-periphid = <0x10153180>; reg = <0x52007000 0x1000>; interrupts = <49>; - interrupt-names = "cmd_irq"; clocks = <&rcc 0>; clock-names = "apb_pclk"; resets = <&rcc 1>; diff --git a/Documentation/devicetree/bindings/mmc/brcm,sdhci-brcmstb.txt b/Documentation/devicetree/bindings/mmc/brcm,sdhci-brcmstb.txt deleted file mode 100644 index ae2074184528..000000000000 --- a/Documentation/devicetree/bindings/mmc/brcm,sdhci-brcmstb.txt +++ /dev/null @@ -1,53 +0,0 @@ -* BROADCOM BRCMSTB/BMIPS SDHCI Controller - -This file documents differences between the core properties in mmc.txt -and the properties used by the sdhci-brcmstb driver. - -NOTE: The driver disables all UHS speed modes by default and depends -on Device Tree properties to enable them for SoC/Board combinations -that support them. - -Required properties: -- compatible: should be one of the following - - "brcm,bcm7425-sdhci" - - "brcm,bcm7445-sdhci" - - "brcm,bcm7216-sdhci" - -Refer to clocks/clock-bindings.txt for generic clock consumer properties. - -Example: - - sdhci@84b0000 { - sd-uhs-sdr50; - sd-uhs-ddr50; - sd-uhs-sdr104; - sdhci,auto-cmd12; - compatible = "brcm,bcm7216-sdhci", - "brcm,bcm7445-sdhci", - "brcm,sdhci-brcmstb"; - reg = <0x84b0000 0x260 0x84b0300 0x200>; - reg-names = "host", "cfg"; - interrupts = <0x0 0x26 0x4>; - interrupt-names = "sdio0_0"; - clocks = <&scmi_clk 245>; - clock-names = "sw_sdio"; - }; - - sdhci@84b1000 { - mmc-ddr-1_8v; - mmc-hs200-1_8v; - mmc-hs400-1_8v; - mmc-hs400-enhanced-strobe; - supports-cqe; - non-removable; - bus-width = <0x8>; - compatible = "brcm,bcm7216-sdhci", - "brcm,bcm7445-sdhci", - "brcm,sdhci-brcmstb"; - reg = <0x84b1000 0x260 0x84b1300 0x200>; - reg-names = "host", "cfg"; - interrupts = <0x0 0x27 0x4>; - interrupt-names = "sdio1_0"; - clocks = <&scmi_clk 245>; - clock-names = "sw_sdio"; - }; diff --git a/Documentation/devicetree/bindings/mmc/brcm,sdhci-brcmstb.yaml b/Documentation/devicetree/bindings/mmc/brcm,sdhci-brcmstb.yaml new file mode 100644 index 000000000000..dccd5ad96981 --- /dev/null +++ b/Documentation/devicetree/bindings/mmc/brcm,sdhci-brcmstb.yaml @@ -0,0 +1,100 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/mmc/brcm,sdhci-brcmstb.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Broadcom BRCMSTB/BMIPS SDHCI Controller binding + +maintainers: + - Al Cooper <alcooperx@gmail.com> + - Florian Fainelli <f.fainelli@gmail.com> + +allOf: + - $ref: mmc-controller.yaml# + +properties: + compatible: + oneOf: + - items: + - enum: + - brcm,bcm7216-sdhci + - const: brcm,bcm7445-sdhci + - const: brcm,sdhci-brcmstb + - items: + - enum: + - brcm,bcm7445-sdhci + - const: brcm,sdhci-brcmstb + - items: + - enum: + - brcm,bcm7425-sdhci + - const: brcm,sdhci-brcmstb + + reg: + minItems: 2 + + reg-names: + items: + - const: host + - const: cfg + + interrupts: + maxItems: 1 + + clocks: + maxItems: 1 + description: + handle to core clock for the sdhci controller. + + clock-names: + items: + - const: sw_sdio + + sdhci,auto-cmd12: + type: boolean + description: Specifies that controller should use auto CMD12 + +required: + - compatible + - reg + - interrupts + - clocks + +unevaluatedProperties: false + +examples: + - | + mmc@84b0000 { + sd-uhs-sdr50; + sd-uhs-ddr50; + sd-uhs-sdr104; + sdhci,auto-cmd12; + compatible = "brcm,bcm7216-sdhci", + "brcm,bcm7445-sdhci", + "brcm,sdhci-brcmstb"; + reg = <0x84b0000 0x260>, <0x84b0300 0x200>; + reg-names = "host", "cfg"; + interrupts = <0x0 0x26 0x4>; + interrupt-names = "sdio0_0"; + clocks = <&scmi_clk 245>; + clock-names = "sw_sdio"; + }; + + mmc@84b1000 { + mmc-ddr-1_8v; + mmc-hs200-1_8v; + mmc-hs400-1_8v; + mmc-hs400-enhanced-strobe; + supports-cqe; + non-removable; + bus-width = <0x8>; + compatible = "brcm,bcm7216-sdhci", + "brcm,bcm7445-sdhci", + "brcm,sdhci-brcmstb"; + reg = <0x84b1000 0x260>, <0x84b1300 0x200>; + reg-names = "host", "cfg"; + interrupts = <0x0 0x27 0x4>; + interrupt-names = "sdio1_0"; + clocks = <&scmi_clk 245>; + clock-names = "sw_sdio"; + }; diff --git a/Documentation/devicetree/bindings/mmc/exynos-dw-mshc.txt b/Documentation/devicetree/bindings/mmc/exynos-dw-mshc.txt index 0419a63f73a0..753e9d7d8956 100644 --- a/Documentation/devicetree/bindings/mmc/exynos-dw-mshc.txt +++ b/Documentation/devicetree/bindings/mmc/exynos-dw-mshc.txt @@ -22,6 +22,8 @@ Required Properties: specific extensions. - "samsung,exynos7-dw-mshc-smu": for controllers with Samsung Exynos7 specific extensions having an SMU. + - "axis,artpec8-dw-mshc": for controllers with ARTPEC-8 specific + extensions. * samsung,dw-mshc-ciu-div: Specifies the divider value for the card interface unit (ciu) clock. This property is applicable only for Exynos5 SoC's and diff --git a/Documentation/devicetree/bindings/mmc/fsl-imx-esdhc.yaml b/Documentation/devicetree/bindings/mmc/fsl-imx-esdhc.yaml index 19621a2f8beb..17acbc665f5a 100644 --- a/Documentation/devicetree/bindings/mmc/fsl-imx-esdhc.yaml +++ b/Documentation/devicetree/bindings/mmc/fsl-imx-esdhc.yaml @@ -34,6 +34,7 @@ properties: - fsl,imx6ull-usdhc - fsl,imx7d-usdhc - fsl,imx7ulp-usdhc + - fsl,imxrt1050-usdhc - nxp,s32g2-usdhc - items: - enum: @@ -44,6 +45,10 @@ properties: - fsl,imx8qm-usdhc - fsl,imx8qxp-usdhc - const: fsl,imx7d-usdhc + - items: + - enum: + - fsl,imx8ulp-usdhc + - const: fsl,imx8mm-usdhc reg: maxItems: 1 @@ -116,6 +121,9 @@ properties: - const: ahb - const: per + power-domains: + maxItems: 1 + pinctrl-names: oneOf: - minItems: 3 diff --git a/Documentation/devicetree/bindings/mmc/img-dw-mshc.txt b/Documentation/devicetree/bindings/mmc/img-dw-mshc.txt deleted file mode 100644 index c54e577eea07..000000000000 --- a/Documentation/devicetree/bindings/mmc/img-dw-mshc.txt +++ /dev/null @@ -1,28 +0,0 @@ -* Imagination specific extensions to the Synopsys Designware Mobile Storage - Host Controller - -The Synopsys designware mobile storage host controller is used to interface -a SoC with storage medium such as eMMC or SD/MMC cards. This file documents -differences between the core Synopsys dw mshc controller properties described -by synopsys-dw-mshc.txt and the properties used by the Imagination specific -extensions to the Synopsys Designware Mobile Storage Host Controller. - -Required Properties: - -* compatible: should be - - "img,pistachio-dw-mshc": for Pistachio SoCs - -Example: - - mmc@18142000 { - compatible = "img,pistachio-dw-mshc"; - reg = <0x18142000 0x400>; - interrupts = <GIC_SHARED 39 IRQ_TYPE_LEVEL_HIGH>; - - clocks = <&system_clk>, <&sdhost_clk>; - clock-names = "biu", "ciu"; - - fifo-depth = <0x20>; - bus-width = <4>; - disable-wp; - }; diff --git a/Documentation/devicetree/bindings/mmc/ingenic,mmc.yaml b/Documentation/devicetree/bindings/mmc/ingenic,mmc.yaml index 01d5c6da0eeb..2d10aedf2e00 100644 --- a/Documentation/devicetree/bindings/mmc/ingenic,mmc.yaml +++ b/Documentation/devicetree/bindings/mmc/ingenic,mmc.yaml @@ -39,14 +39,15 @@ properties: const: mmc dmas: - items: - - description: DMA controller phandle and request line for RX - - description: DMA controller phandle and request line for TX + minItems: 1 + maxItems: 2 dma-names: - items: - - const: rx - - const: tx + oneOf: + - items: + - const: rx + - const: tx + - const: tx-rx required: - compatible @@ -80,3 +81,27 @@ examples: <&dma JZ4780_DMA_MSC0_TX 0xffffffff>; dma-names = "rx", "tx"; }; + - | + #include <dt-bindings/clock/ingenic,jz4780-cgu.h> + #include <dt-bindings/dma/jz4780-dma.h> + /* + * Alternative version of the example above, + * but using one single DMA channel for both + * TX and RX. + */ + mmc1: mmc@13460000 { + compatible = "ingenic,jz4780-mmc"; + reg = <0x13460000 0x1000>; + + interrupt-parent = <&intc>; + interrupts = <36>; + + clocks = <&cgu JZ4780_CLK_MSC1>; + clock-names = "mmc"; + + cap-sd-highspeed; + cap-mmc-highspeed; + cap-sdio-irq; + dmas = <&dma JZ4780_DMA_MSC1_TX JZ4780_DMA_MSC1_RX 0xffffffff>; + dma-names = "tx-rx"; + }; diff --git a/Documentation/devicetree/bindings/mmc/mtk-sd.yaml b/Documentation/devicetree/bindings/mmc/mtk-sd.yaml index 82768a807294..faf89b0c918f 100644 --- a/Documentation/devicetree/bindings/mmc/mtk-sd.yaml +++ b/Documentation/devicetree/bindings/mmc/mtk-sd.yaml @@ -36,6 +36,9 @@ properties: - const: mediatek,mt8195-mmc - const: mediatek,mt8183-mmc + reg: + maxItems: 1 + clocks: description: Should contain phandle for the clock feeding the MMC controller. @@ -62,6 +65,9 @@ properties: - const: axi_cg - const: ahb_cg + interrupts: + maxItems: 1 + pinctrl-names: items: - const: default diff --git a/Documentation/devicetree/bindings/mmc/nvidia,tegra20-sdhci.txt b/Documentation/devicetree/bindings/mmc/nvidia,tegra20-sdhci.txt deleted file mode 100644 index 96c0b1440c9c..000000000000 --- a/Documentation/devicetree/bindings/mmc/nvidia,tegra20-sdhci.txt +++ /dev/null @@ -1,143 +0,0 @@ -* NVIDIA Tegra Secure Digital Host Controller - -This controller on Tegra family SoCs provides an interface for MMC, SD, -and SDIO types of memory cards. - -This file documents differences between the core properties described -by mmc.txt and the properties used by the sdhci-tegra driver. - -Required properties: -- compatible : should be one of: - - "nvidia,tegra20-sdhci": for Tegra20 - - "nvidia,tegra30-sdhci": for Tegra30 - - "nvidia,tegra114-sdhci": for Tegra114 - - "nvidia,tegra124-sdhci": for Tegra124 and Tegra132 - - "nvidia,tegra210-sdhci": for Tegra210 - - "nvidia,tegra186-sdhci": for Tegra186 - - "nvidia,tegra194-sdhci": for Tegra194 -- clocks: For Tegra210, Tegra186 and Tegra194 must contain two entries. - One for the module clock and one for the timeout clock. - For all other Tegra devices, must contain a single entry for - the module clock. See ../clocks/clock-bindings.txt for details. -- clock-names: For Tegra210, Tegra186 and Tegra194 must contain the - strings 'sdhci' and 'tmclk' to represent the module and - the timeout clocks, respectively. - For all other Tegra devices must contain the string 'sdhci' - to represent the module clock. -- resets : Must contain an entry for each entry in reset-names. - See ../reset/reset.txt for details. -- reset-names : Must include the following entries: - - sdhci - -Optional properties: -- power-gpios : Specify GPIOs for power control - -Example: - -sdhci@c8000200 { - compatible = "nvidia,tegra20-sdhci"; - reg = <0xc8000200 0x200>; - interrupts = <47>; - clocks = <&tegra_car 14>; - resets = <&tegra_car 14>; - reset-names = "sdhci"; - cd-gpios = <&gpio 69 0>; /* gpio PI5 */ - wp-gpios = <&gpio 57 0>; /* gpio PH1 */ - power-gpios = <&gpio 155 0>; /* gpio PT3 */ - bus-width = <8>; -}; - -Optional properties for Tegra210, Tegra186 and Tegra194: -- pinctrl-names, pinctrl-0, pinctrl-1 : Specify pad voltage - configurations. Valid pinctrl-names are "sdmmc-3v3" and "sdmmc-1v8" - for controllers supporting multiple voltage levels. The order of names - should correspond to the pin configuration states in pinctrl-0 and - pinctrl-1. -- pinctrl-names : "sdmmc-3v3-drv" and "sdmmc-1v8-drv" are applicable for - Tegra210 where pad config registers are in the pinmux register domain - for pull-up-strength and pull-down-strength values configuration when - using pads at 3V3 and 1V8 levels. -- nvidia,only-1-8-v : The presence of this property indicates that the - controller operates at a 1.8 V fixed I/O voltage. -- nvidia,pad-autocal-pull-up-offset-3v3, - nvidia,pad-autocal-pull-down-offset-3v3 : Specify drive strength - calibration offsets for 3.3 V signaling modes. -- nvidia,pad-autocal-pull-up-offset-1v8, - nvidia,pad-autocal-pull-down-offset-1v8 : Specify drive strength - calibration offsets for 1.8 V signaling modes. -- nvidia,pad-autocal-pull-up-offset-3v3-timeout, - nvidia,pad-autocal-pull-down-offset-3v3-timeout : Specify drive - strength used as a fallback in case the automatic calibration times - out on a 3.3 V signaling mode. -- nvidia,pad-autocal-pull-up-offset-1v8-timeout, - nvidia,pad-autocal-pull-down-offset-1v8-timeout : Specify drive - strength used as a fallback in case the automatic calibration times - out on a 1.8 V signaling mode. -- nvidia,pad-autocal-pull-up-offset-sdr104, - nvidia,pad-autocal-pull-down-offset-sdr104 : Specify drive strength - calibration offsets for SDR104 mode. -- nvidia,pad-autocal-pull-up-offset-hs400, - nvidia,pad-autocal-pull-down-offset-hs400 : Specify drive strength - calibration offsets for HS400 mode. -- nvidia,default-tap : Specify the default inbound sampling clock - trimmer value for non-tunable modes. -- nvidia,default-trim : Specify the default outbound clock trimmer - value. -- nvidia,dqs-trim : Specify DQS trim value for HS400 timing - - Notes on the pad calibration pull up and pulldown offset values: - - The property values are drive codes which are programmed into the - PD_OFFSET and PU_OFFSET sections of the - SDHCI_TEGRA_AUTO_CAL_CONFIG register. - - A higher value corresponds to higher drive strength. Please refer - to the reference manual of the SoC for correct values. - - The SDR104 and HS400 timing specific values are used in - corresponding modes if specified. - - Notes on tap and trim values: - - The values are used for compensating trace length differences - by adjusting the sampling point. - - The values are programmed to the Vendor Clock Control Register. - Please refer to the reference manual of the SoC for correct - values. - - The DQS trim values are only used on controllers which support - HS400 timing. Only SDMMC4 on Tegra210 and Tegra 186 supports - HS400. - -Example: -sdhci@700b0000 { - compatible = "nvidia,tegra124-sdhci"; - reg = <0x0 0x700b0000 0x0 0x200>; - interrupts = <GIC_SPI 14 IRQ_TYPE_LEVEL_HIGH>; - clocks = <&tegra_car TEGRA210_CLK_SDMMC1>; - clock-names = "sdhci"; - resets = <&tegra_car 14>; - reset-names = "sdhci"; - pinctrl-names = "sdmmc-3v3", "sdmmc-1v8"; - pinctrl-0 = <&sdmmc1_3v3>; - pinctrl-1 = <&sdmmc1_1v8>; - nvidia,pad-autocal-pull-up-offset-3v3 = <0x00>; - nvidia,pad-autocal-pull-down-offset-3v3 = <0x7d>; - nvidia,pad-autocal-pull-up-offset-1v8 = <0x7b>; - nvidia,pad-autocal-pull-down-offset-1v8 = <0x7b>; - status = "disabled"; -}; - -sdhci@700b0000 { - compatible = "nvidia,tegra210-sdhci"; - reg = <0x0 0x700b0000 0x0 0x200>; - interrupts = <GIC_SPI 14 IRQ_TYPE_LEVEL_HIGH>; - clocks = <&tegra_car TEGRA210_CLK_SDMMC1>, - <&tegra_car TEGRA210_CLK_SDMMC_LEGACY>; - clock-names = "sdhci", "tmclk"; - resets = <&tegra_car 14>; - reset-names = "sdhci"; - pinctrl-names = "sdmmc-3v3", "sdmmc-1v8"; - pinctrl-0 = <&sdmmc1_3v3>; - pinctrl-1 = <&sdmmc1_1v8>; - nvidia,pad-autocal-pull-up-offset-3v3 = <0x00>; - nvidia,pad-autocal-pull-down-offset-3v3 = <0x7d>; - nvidia,pad-autocal-pull-up-offset-1v8 = <0x7b>; - nvidia,pad-autocal-pull-down-offset-1v8 = <0x7b>; - status = "disabled"; -}; diff --git a/Documentation/devicetree/bindings/mmc/nvidia,tegra20-sdhci.yaml b/Documentation/devicetree/bindings/mmc/nvidia,tegra20-sdhci.yaml new file mode 100644 index 000000000000..ce64b3498378 --- /dev/null +++ b/Documentation/devicetree/bindings/mmc/nvidia,tegra20-sdhci.yaml @@ -0,0 +1,317 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/mmc/nvidia,tegra20-sdhci.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: NVIDIA Tegra Secure Digital Host Controller + +maintainers: + - Thierry Reding <thierry.reding@gmail.com> + - Jon Hunter <jonathanh@nvidia.com> + +description: | + This controller on Tegra family SoCs provides an interface for MMC, SD, and + SDIO types of memory cards. + + This file documents differences between the core properties described by + mmc-controller.yaml and the properties for the Tegra SDHCI controller. + +properties: + compatible: + oneOf: + - enum: + - nvidia,tegra20-sdhci + - nvidia,tegra30-sdhci + - nvidia,tegra114-sdhci + - nvidia,tegra124-sdhci + - nvidia,tegra210-sdhci + - nvidia,tegra186-sdhci + - nvidia,tegra194-sdhci + + - items: + - const: nvidia,tegra132-sdhci + - const: nvidia,tegra124-sdhci + + - items: + - enum: + - nvidia,tegra194-sdhci + - nvidia,tegra234-sdhci + - const: nvidia,tegra186-sdhci + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + assigned-clocks: true + assigned-clock-parents: true + assigned-clock-rates: true + + clocks: + minItems: 1 + maxItems: 2 + + clock-names: + minItems: 1 + maxItems: 2 + + resets: + items: + - description: module reset + + reset-names: + items: + - const: sdhci + + power-gpios: + description: specify GPIOs for power control + maxItems: 1 + + interconnects: + items: + - description: memory read client + - description: memory write client + + interconnect-names: + items: + - const: dma-mem # read + - const: write + + iommus: + maxItems: 1 + + operating-points-v2: + $ref: "/schemas/types.yaml#/definitions/phandle" + + power-domains: + items: + - description: phandle to the core power domain + + nvidia,default-tap: + description: Specify the default inbound sampling clock trimmer value for + non-tunable modes. + + The values are used for compensating trace length differences by + adjusting the sampling point. The values are programmed to the Vendor + Clock Control Register. Please refer to the reference manual of the SoC + for correct values. + + The DQS trim values are only used on controllers which support HS400 + timing. Only SDMMC4 on Tegra210 and Tegra186 supports HS400. + $ref: "/schemas/types.yaml#/definitions/uint32" + + nvidia,default-trim: + description: Specify the default outbound clock trimmer value. + $ref: "/schemas/types.yaml#/definitions/uint32" + + nvidia,dqs-trim: + description: Specify DQS trim value for HS400 timing. + $ref: "/schemas/types.yaml#/definitions/uint32" + + nvidia,pad-autocal-pull-down-offset-1v8: + description: Specify drive strength calibration offsets for 1.8 V + signaling modes. + $ref: "/schemas/types.yaml#/definitions/uint32" + + nvidia,pad-autocal-pull-down-offset-1v8-timeout: + description: Specify drive strength used as a fallback in case the + automatic calibration times out on a 1.8 V signaling mode. + $ref: "/schemas/types.yaml#/definitions/uint32" + + nvidia,pad-autocal-pull-down-offset-3v3: + description: Specify drive strength calibration offsets for 3.3 V + signaling modes. + $ref: "/schemas/types.yaml#/definitions/uint32" + + nvidia,pad-autocal-pull-down-offset-3v3-timeout: + description: Specify drive strength used as a fallback in case the + automatic calibration times out on a 3.3 V signaling mode. + $ref: "/schemas/types.yaml#/definitions/uint32" + + nvidia,pad-autocal-pull-down-offset-sdr104: + description: Specify drive strength calibration offsets for SDR104 mode. + $ref: "/schemas/types.yaml#/definitions/uint32" + + nvidia,pad-autocal-pull-down-offset-hs400: + description: Specify drive strength calibration offsets for HS400 mode. + $ref: "/schemas/types.yaml#/definitions/uint32" + + nvidia,pad-autocal-pull-up-offset-1v8: + description: Specify drive strength calibration offsets for 1.8 V + signaling modes. + $ref: "/schemas/types.yaml#/definitions/uint32" + + nvidia,pad-autocal-pull-up-offset-1v8-timeout: + description: Specify drive strength used as a fallback in case the + automatic calibration times out on a 1.8 V signaling mode. + $ref: "/schemas/types.yaml#/definitions/uint32" + + nvidia,pad-autocal-pull-up-offset-3v3: + description: Specify drive strength calibration offsets for 3.3 V + signaling modes. + + The property values are drive codes which are programmed into the + PD_OFFSET and PU_OFFSET sections of the SDHCI_TEGRA_AUTO_CAL_CONFIG + register. A higher value corresponds to higher drive strength. Please + refer to the reference manual of the SoC for correct values. The SDR104 + and HS400 timing specific values are used in corresponding modes if + specified. + $ref: "/schemas/types.yaml#/definitions/uint32" + + nvidia,pad-autocal-pull-up-offset-3v3-timeout: + description: Specify drive strength used as a fallback in case the + automatic calibration times out on a 3.3 V signaling mode. + $ref: "/schemas/types.yaml#/definitions/uint32" + + nvidia,pad-autocal-pull-up-offset-sdr104: + description: Specify drive strength calibration offsets for SDR104 mode. + $ref: "/schemas/types.yaml#/definitions/uint32" + + nvidia,pad-autocal-pull-up-offset-hs400: + description: Specify drive strength calibration offsets for HS400 mode. + $ref: "/schemas/types.yaml#/definitions/uint32" + + nvidia,only-1-8v: + description: The presence of this property indicates that the controller + operates at a 1.8 V fixed I/O voltage. + $ref: "/schemas/types.yaml#/definitions/flag" + +required: + - compatible + - reg + - interrupts + - clocks + - resets + - reset-names + +allOf: + - $ref: "mmc-controller.yaml" + - if: + properties: + compatible: + contains: + enum: + - nvidia,tegra20-sdhci + - nvidia,tegra30-sdhci + - nvidia,tegra114-sdhci + - nvidia,tegra124-sdhci + clocks: + items: + - description: module clock + minItems: 1 + maxItems: 1 + else: + properties: + clocks: + items: + - description: module clock + - description: timeout clock + minItems: 2 + maxItems: 2 + clock-names: + items: + - const: sdhci + - const: tmclk + minItems: 2 + maxItems: 2 + required: + - clock-names + + - if: + properties: + compatible: + contains: + const: nvidia,tegra210-sdhci + then: + properties: + pinctrl-names: + oneOf: + - items: + - const: sdmmc-3v3 + description: pad configuration for 3.3 V + - const: sdmmc-1v8 + description: pad configuration for 1.8 V + - const: sdmmc-3v3-drv + description: pull-up/down configuration for 3.3 V + - const: sdmmc-1v8-drv + description: pull-up/down configuration for 1.8 V + - items: + - const: sdmmc-3v3-drv + description: pull-up/down configuration for 3.3 V + - const: sdmmc-1v8-drv + description: pull-up/down configuration for 1.8 V + - items: + - const: sdmmc-1v8-drv + description: pull-up/down configuration for 1.8 V + required: + - clock-names + - if: + properties: + compatible: + contains: + enum: + - nvidia,tegra186-sdhci + - nvidia,tegra194-sdhci + then: + properties: + pinctrl-names: + items: + - const: sdmmc-3v3 + description: pad configuration for 3.3 V + - const: sdmmc-1v8 + description: pad configuration for 1.8 V + required: + - clock-names + +unevaluatedProperties: false + +examples: + - | + #include <dt-bindings/interrupt-controller/arm-gic.h> + + mmc@c8000200 { + compatible = "nvidia,tegra20-sdhci"; + reg = <0xc8000200 0x200>; + interrupts = <47>; + clocks = <&tegra_car 14>; + resets = <&tegra_car 14>; + reset-names = "sdhci"; + cd-gpios = <&gpio 69 0>; /* gpio PI5 */ + wp-gpios = <&gpio 57 0>; /* gpio PH1 */ + power-gpios = <&gpio 155 0>; /* gpio PT3 */ + bus-width = <8>; + }; + + - | + #include <dt-bindings/clock/tegra210-car.h> + #include <dt-bindings/interrupt-controller/arm-gic.h> + + mmc@700b0000 { + compatible = "nvidia,tegra210-sdhci"; + reg = <0x700b0000 0x200>; + interrupts = <GIC_SPI 14 IRQ_TYPE_LEVEL_HIGH>; + clocks = <&tegra_car TEGRA210_CLK_SDMMC1>, + <&tegra_car TEGRA210_CLK_SDMMC_LEGACY>; + clock-names = "sdhci", "tmclk"; + resets = <&tegra_car 14>; + reset-names = "sdhci"; + pinctrl-names = "sdmmc-3v3", "sdmmc-1v8", + "sdmmc-3v3-drv", "sdmmc-1v8-drv"; + pinctrl-0 = <&sdmmc1_3v3>; + pinctrl-1 = <&sdmmc1_1v8>; + pinctrl-2 = <&sdmmc1_3v3_drv>; + pinctrl-3 = <&sdmmc1_1v8_drv>; + nvidia,pad-autocal-pull-up-offset-3v3 = <0x00>; + nvidia,pad-autocal-pull-down-offset-3v3 = <0x7d>; + nvidia,pad-autocal-pull-up-offset-1v8 = <0x7b>; + nvidia,pad-autocal-pull-down-offset-1v8 = <0x7b>; + nvidia,default-tap = <0x2>; + nvidia,default-trim = <0x4>; + assigned-clocks = <&tegra_car TEGRA210_CLK_SDMMC4>, + <&tegra_car TEGRA210_CLK_PLL_C4_OUT0>, + <&tegra_car TEGRA210_CLK_PLL_C4>; + assigned-clock-parents = <&tegra_car TEGRA210_CLK_PLL_C4_OUT0>; + assigned-clock-rates = <200000000>, <1000000000>, <1000000000>; + }; diff --git a/Documentation/devicetree/bindings/mmc/renesas,sdhi.yaml b/Documentation/devicetree/bindings/mmc/renesas,sdhi.yaml index 9f1e7092cf44..9ce6e06c19db 100644 --- a/Documentation/devicetree/bindings/mmc/renesas,sdhi.yaml +++ b/Documentation/devicetree/bindings/mmc/renesas,sdhi.yaml @@ -113,31 +113,51 @@ allOf: clocks: items: - description: IMCLK, SDHI channel main clock1. + - description: CLK_HS, SDHI channel High speed clock which operates + 4 times that of SDHI channel main clock1. - description: IMCLK2, SDHI channel main clock2. When this clock is turned off, external SD card detection cannot be detected. - - description: CLK_HS, SDHI channel High speed clock which operates - 4 times that of SDHI channel main clock1. - description: ACLK, SDHI channel bus clock. clock-names: items: - - const: imclk - - const: imclk2 - - const: clk_hs + - const: core + - const: clkh + - const: cd - const: aclk required: - clock-names - resets else: - properties: - clocks: - minItems: 1 - maxItems: 2 - clock-names: - minItems: 1 - items: - - const: core - - const: cd + if: + properties: + compatible: + contains: + enum: + - renesas,rcar-gen2-sdhi + - renesas,rcar-gen3-sdhi + then: + properties: + clocks: + minItems: 1 + maxItems: 3 + clock-names: + minItems: 1 + uniqueItems: true + items: + - const: core + - enum: [ clkh, cd ] + - const: cd + else: + properties: + clocks: + minItems: 1 + maxItems: 2 + clock-names: + minItems: 1 + items: + - const: core + - const: cd - if: properties: diff --git a/Documentation/devicetree/bindings/mmc/sdhci-am654.yaml b/Documentation/devicetree/bindings/mmc/sdhci-am654.yaml index 224303f5b913..9fbf16b3bc8d 100644 --- a/Documentation/devicetree/bindings/mmc/sdhci-am654.yaml +++ b/Documentation/devicetree/bindings/mmc/sdhci-am654.yaml @@ -48,6 +48,8 @@ properties: - const: clk_ahb - const: clk_xin + sdhci-caps-mask: true + # PHY output tap delays: # Used to delay the data valid window and align it to the sampling clock. # Binding needs to be provided for each supported speed mode otherwise the diff --git a/Documentation/devicetree/bindings/mmc/sdhci-msm.txt b/Documentation/devicetree/bindings/mmc/sdhci-msm.txt index 50841e2843fc..6a8cc261bf61 100644 --- a/Documentation/devicetree/bindings/mmc/sdhci-msm.txt +++ b/Documentation/devicetree/bindings/mmc/sdhci-msm.txt @@ -17,6 +17,7 @@ Required properties: "qcom,msm8974-sdhci", "qcom,sdhci-msm-v4" "qcom,msm8916-sdhci", "qcom,sdhci-msm-v4" "qcom,msm8992-sdhci", "qcom,sdhci-msm-v4" + "qcom,msm8994-sdhci", "qcom,sdhci-msm-v4" "qcom,msm8996-sdhci", "qcom,sdhci-msm-v4" "qcom,qcs404-sdhci", "qcom,sdhci-msm-v5" "qcom,sc7180-sdhci", "qcom,sdhci-msm-v5"; diff --git a/Documentation/devicetree/bindings/mmc/socfpga-dw-mshc.txt b/Documentation/devicetree/bindings/mmc/socfpga-dw-mshc.txt deleted file mode 100644 index 4897bea7e3f8..000000000000 --- a/Documentation/devicetree/bindings/mmc/socfpga-dw-mshc.txt +++ /dev/null @@ -1,23 +0,0 @@ -* Altera SOCFPGA specific extensions to the Synopsys Designware Mobile - Storage Host Controller - -The Synopsys designware mobile storage host controller is used to interface -a SoC with storage medium such as eMMC or SD/MMC cards. This file documents -differences between the core Synopsys dw mshc controller properties described -by synopsys-dw-mshc.txt and the properties used by the Altera SOCFPGA specific -extensions to the Synopsys Designware Mobile Storage Host Controller. - -Required Properties: - -* compatible: should be - - "altr,socfpga-dw-mshc": for Altera's SOCFPGA platform - -Example: - - mmc: dwmmc0@ff704000 { - compatible = "altr,socfpga-dw-mshc"; - reg = <0xff704000 0x1000>; - interrupts = <0 129 4>; - #address-cells = <1>; - #size-cells = <0>; - }; diff --git a/Documentation/devicetree/bindings/mmc/socionext,uniphier-sd.yaml b/Documentation/devicetree/bindings/mmc/socionext,uniphier-sd.yaml index 56f9ff12742d..a586fad0a46b 100644 --- a/Documentation/devicetree/bindings/mmc/socionext,uniphier-sd.yaml +++ b/Documentation/devicetree/bindings/mmc/socionext,uniphier-sd.yaml @@ -26,6 +26,12 @@ properties: clocks: maxItems: 1 + dmas: + maxItems: 1 + + dma-names: + const: rx-tx + reset-names: description: | There are three reset signals at maximum diff --git a/Documentation/devicetree/bindings/mmc/synopsys-dw-mshc.yaml b/Documentation/devicetree/bindings/mmc/synopsys-dw-mshc.yaml index 240abb6f102c..ae6d6fca79e2 100644 --- a/Documentation/devicetree/bindings/mmc/synopsys-dw-mshc.yaml +++ b/Documentation/devicetree/bindings/mmc/synopsys-dw-mshc.yaml @@ -15,7 +15,10 @@ maintainers: # Everything else is described in the common file properties: compatible: - const: snps,dw-mshc + enum: + - altr,socfpga-dw-mshc + - img,pistachio-dw-mshc + - snps,dw-mshc reg: maxItems: 1 diff --git a/Documentation/devicetree/bindings/mtd/jedec,spi-nor.yaml b/Documentation/devicetree/bindings/mtd/jedec,spi-nor.yaml index ed590d7c6e37..39421f7233e4 100644 --- a/Documentation/devicetree/bindings/mtd/jedec,spi-nor.yaml +++ b/Documentation/devicetree/bindings/mtd/jedec,spi-nor.yaml @@ -11,6 +11,7 @@ maintainers: allOf: - $ref: "mtd.yaml#" + - $ref: /schemas/spi/spi-peripheral-props.yaml# properties: compatible: @@ -88,7 +89,7 @@ patternProperties: "^otp(-[0-9]+)?$": type: object -additionalProperties: false +unevaluatedProperties: false examples: - | diff --git a/Documentation/devicetree/bindings/mtd/renesas-nandc.yaml b/Documentation/devicetree/bindings/mtd/renesas-nandc.yaml new file mode 100644 index 000000000000..2870d36361c4 --- /dev/null +++ b/Documentation/devicetree/bindings/mtd/renesas-nandc.yaml @@ -0,0 +1,61 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/mtd/renesas-nandc.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Renesas R-Car Gen3 & RZ/N1x NAND flash controller device tree bindings + +maintainers: + - Miquel Raynal <miquel.raynal@bootlin.com> + +allOf: + - $ref: "nand-controller.yaml" + +properties: + compatible: + oneOf: + - items: + - enum: + - renesas,r9a06g032-nandc + - const: renesas,rzn1-nandc + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + clocks: + items: + - description: APB host controller clock + - description: External NAND bus clock + + clock-names: + items: + - const: hclk + - const: eclk + +required: + - compatible + - reg + - clocks + - clock-names + - interrupts + +unevaluatedProperties: false + +examples: + - | + #include <dt-bindings/interrupt-controller/arm-gic.h> + #include <dt-bindings/clock/r9a06g032-sysctrl.h> + + nand-controller@40102000 { + compatible = "renesas,r9a06g032-nandc", "renesas,rzn1-nandc"; + reg = <0x40102000 0x2000>; + interrupts = <GIC_SPI 58 IRQ_TYPE_LEVEL_HIGH>; + clocks = <&sysctrl R9A06G032_HCLK_NAND>, <&sysctrl R9A06G032_CLK_NAND>; + clock-names = "hclk", "eclk"; + #address-cells = <1>; + #size-cells = <0>; + }; diff --git a/Documentation/devicetree/bindings/mtd/ti,gpmc-nand.yaml b/Documentation/devicetree/bindings/mtd/ti,gpmc-nand.yaml index beb26b9bcfb2..4ac198814b7a 100644 --- a/Documentation/devicetree/bindings/mtd/ti,gpmc-nand.yaml +++ b/Documentation/devicetree/bindings/mtd/ti,gpmc-nand.yaml @@ -16,7 +16,10 @@ description: properties: compatible: - const: ti,omap2-nand + items: + - enum: + - ti,am64-nand + - ti,omap2-nand reg: maxItems: 1 @@ -53,6 +56,11 @@ properties: enum: [8, 16] default: 8 + rb-gpios: + description: + GPIO connection to R/B signal from NAND chip + maxItems: 1 + patternProperties: "@[0-9a-f]+$": $ref: "/schemas/mtd/partitions/partition.yaml" diff --git a/Documentation/devicetree/bindings/mux/gpio-mux.yaml b/Documentation/devicetree/bindings/mux/gpio-mux.yaml index 0a7c8d64981a..ee4de9fbaf4d 100644 --- a/Documentation/devicetree/bindings/mux/gpio-mux.yaml +++ b/Documentation/devicetree/bindings/mux/gpio-mux.yaml @@ -26,7 +26,10 @@ properties: List of gpios used to control the multiplexer, least significant bit first. '#mux-control-cells': - const: 0 + enum: [ 0, 1 ] + + '#mux-state-cells': + enum: [ 1, 2 ] idle-state: default: -1 @@ -34,7 +37,11 @@ properties: required: - compatible - mux-gpios - - "#mux-control-cells" +anyOf: + - required: + - "#mux-control-cells" + - required: + - "#mux-state-cells" additionalProperties: false diff --git a/Documentation/devicetree/bindings/mux/mux-consumer.yaml b/Documentation/devicetree/bindings/mux/mux-consumer.yaml index 7af93298ab5c..d3d854967359 100644 --- a/Documentation/devicetree/bindings/mux/mux-consumer.yaml +++ b/Documentation/devicetree/bindings/mux/mux-consumer.yaml @@ -25,6 +25,17 @@ description: | strings to label each of the mux controllers listed in the "mux-controls" property. + If it is required to provide the state that the mux controller needs to + be set to, the property "mux-states" must be used. An optional property + "mux-state-names" can be used to provide a list of strings, to label + each of the multiplixer states listed in the "mux-states" property. + + Properties "mux-controls" and "mux-states" can be used depending on how + the consumers want to control the mux controller. If the consumer needs + needs to set multiple states in a mux controller, then property + "mux-controls" can be used. If the consumer needs to set the mux + controller to a given state then property "mux-states" can be used. + mux-ctrl-specifier typically encodes the chip-relative mux controller number. If the mux controller chip only provides a single mux controller, the mux-ctrl-specifier can typically be left out. @@ -35,12 +46,22 @@ properties: mux-controls: $ref: /schemas/types.yaml#/definitions/phandle-array + mux-states: + $ref: /schemas/types.yaml#/definitions/phandle-array + mux-control-names: description: Devices that use more than a single mux controller can use the "mux-control-names" property to map the name of the requested mux controller to an index into the list given by the "mux-controls" property. + mux-state-names: + description: + Devices that use more than a single multiplexer state can use the + "mux-state-names" property to map the name of the requested mux + controller to an index into the list given by the "mux-states" + property. + additionalProperties: true ... diff --git a/Documentation/devicetree/bindings/mux/mux-controller.yaml b/Documentation/devicetree/bindings/mux/mux-controller.yaml index 736a84c3b6a5..c855fbad3884 100644 --- a/Documentation/devicetree/bindings/mux/mux-controller.yaml +++ b/Documentation/devicetree/bindings/mux/mux-controller.yaml @@ -25,7 +25,9 @@ description: | -------------------- Mux controller nodes must specify the number of cells used for the - specifier using the '#mux-control-cells' property. + specifier using the '#mux-control-cells' or '#mux-state-cells' property. + The value of '#mux-state-cells' will always be one greater than the value + of '#mux-control-cells'. Optionally, mux controller nodes can also specify the state the mux should have when it is idle. The idle-state property is used for this. If the @@ -67,6 +69,8 @@ select: pattern: '^mux-controller' - required: - '#mux-control-cells' + - required: + - '#mux-state-cells' properties: $nodename: @@ -75,6 +79,9 @@ properties: '#mux-control-cells': enum: [ 0, 1 ] + '#mux-state-cells': + enum: [ 1, 2 ] + idle-state: $ref: /schemas/types.yaml#/definitions/int32 minimum: -2 @@ -179,4 +186,21 @@ examples: }; }; }; + + - | + #include <dt-bindings/gpio/gpio.h> + + mux1: mux-controller { + compatible = "gpio-mux"; + #mux-state-cells = <1>; + mux-gpios = <&exp_som 2 GPIO_ACTIVE_HIGH>; + }; + + transceiver4: can-phy4 { + compatible = "ti,tcan1042"; + #phy-cells = <0>; + max-bitrate = <5000000>; + standby-gpios = <&exp_som 7 GPIO_ACTIVE_HIGH>; + mux-states = <&mux1 1>; + }; ... diff --git a/Documentation/devicetree/bindings/net/actions,owl-emac.yaml b/Documentation/devicetree/bindings/net/actions,owl-emac.yaml index 1626e0a821b0..d30fada2ac39 100644 --- a/Documentation/devicetree/bindings/net/actions,owl-emac.yaml +++ b/Documentation/devicetree/bindings/net/actions,owl-emac.yaml @@ -51,6 +51,10 @@ properties: description: Phandle to the device containing custom config. + mdio: + $ref: mdio.yaml# + unevaluatedProperties: false + required: - compatible - reg diff --git a/Documentation/devicetree/bindings/net/allwinner,sun8i-a83t-emac.yaml b/Documentation/devicetree/bindings/net/allwinner,sun8i-a83t-emac.yaml index 407586bc366b..6a4831fd3616 100644 --- a/Documentation/devicetree/bindings/net/allwinner,sun8i-a83t-emac.yaml +++ b/Documentation/devicetree/bindings/net/allwinner,sun8i-a83t-emac.yaml @@ -122,6 +122,7 @@ allOf: mdio-mux: type: object + unevaluatedProperties: false properties: compatible: @@ -132,17 +133,18 @@ allOf: description: Phandle to EMAC MDIO. + "#address-cells": + const: 1 + + "#size-cells": + const: 0 + mdio@1: - type: object + $ref: mdio.yaml# + unevaluatedProperties: false description: Internal MDIO Bus properties: - "#address-cells": - const: 1 - - "#size-cells": - const: 0 - compatible: const: allwinner,sun8i-h3-mdio-internal @@ -168,16 +170,11 @@ allOf: mdio@2: - type: object + $ref: mdio.yaml# + unevaluatedProperties: false description: External MDIO Bus (H3 only) properties: - "#address-cells": - const: 1 - - "#size-cells": - const: 0 - reg: const: 2 diff --git a/Documentation/devicetree/bindings/net/brcm,amac.txt b/Documentation/devicetree/bindings/net/brcm,amac.txt deleted file mode 100644 index 0120ebe93262..000000000000 --- a/Documentation/devicetree/bindings/net/brcm,amac.txt +++ /dev/null @@ -1,30 +0,0 @@ -Broadcom AMAC Ethernet Controller Device Tree Bindings -------------------------------------------------------------- - -Required properties: - - compatible: "brcm,amac" - "brcm,nsp-amac" - "brcm,ns2-amac" - - reg: Address and length of the register set for the device. It - contains the information of registers in the same order as - described by reg-names - - reg-names: Names of the registers. - "amac_base": Address and length of the GMAC registers - "idm_base": Address and length of the GMAC IDM registers - (required for NSP and Northstar2) - "nicpm_base": Address and length of the NIC Port Manager - registers (required for Northstar2) - - interrupts: Interrupt number - -The MAC address will be determined using the optional properties -defined in ethernet.txt. - -Examples: - -amac0: ethernet@18022000 { - compatible = "brcm,nsp-amac"; - reg = <0x18022000 0x1000>, - <0x18110000 0x1000>; - reg-names = "amac_base", "idm_base"; - interrupts = <GIC_SPI 147 IRQ_TYPE_LEVEL_HIGH>; -}; diff --git a/Documentation/devicetree/bindings/net/brcm,amac.yaml b/Documentation/devicetree/bindings/net/brcm,amac.yaml new file mode 100644 index 000000000000..8f031932c8af --- /dev/null +++ b/Documentation/devicetree/bindings/net/brcm,amac.yaml @@ -0,0 +1,88 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/net/brcm,amac.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Broadcom AMAC Ethernet Controller Device Tree Bindings + +maintainers: + - Florian Fainelli <f.fainelli@gmail.com> + +allOf: + - $ref: "ethernet-controller.yaml#" + - if: + properties: + compatible: + contains: + enum: + - brcm,amac + then: + properties: + reg: + maxItems: 2 + reg-names: + maxItems: 2 + + - if: + properties: + compatible: + contains: + enum: + - brcm,nsp-amac + then: + properties: + reg: + minItems: 2 + maxItems: 2 + reg-names: + minItems: 2 + maxItems: 2 + + - if: + properties: + compatible: + contains: + enum: + - brcm,ns2-amac + then: + properties: + reg: + minItems: 3 + reg-names: + minItems: 3 + +properties: + compatible: + enum: + - brcm,amac + - brcm,nsp-amac + - brcm,ns2-amac + + interrupts: + maxItems: 1 + + reg: + minItems: 1 + maxItems: 3 + + reg-names: + minItems: 1 + items: + - const: amac_base + - const: idm_base + - const: nicpm_base + +unevaluatedProperties: false + +examples: + - | + #include <dt-bindings/interrupt-controller/arm-gic.h> + + amac0: ethernet@18022000 { + compatible = "brcm,nsp-amac"; + reg = <0x18022000 0x1000>, + <0x18110000 0x1000>; + reg-names = "amac_base", "idm_base"; + interrupts = <GIC_SPI 147 IRQ_TYPE_LEVEL_HIGH>; + }; diff --git a/Documentation/devicetree/bindings/net/brcm,bcm6368-mdio-mux.yaml b/Documentation/devicetree/bindings/net/brcm,bcm6368-mdio-mux.yaml index 2f34fda55fd0..9ef28c2a0afc 100644 --- a/Documentation/devicetree/bindings/net/brcm,bcm6368-mdio-mux.yaml +++ b/Documentation/devicetree/bindings/net/brcm,bcm6368-mdio-mux.yaml @@ -15,18 +15,12 @@ description: properties as well to generate desired MDIO transaction on appropriate bus. allOf: - - $ref: "mdio.yaml#" + - $ref: mdio-mux.yaml# properties: compatible: const: brcm,bcm6368-mdio-mux - "#address-cells": - const: 1 - - "#size-cells": - const: 0 - reg: maxItems: 1 @@ -34,24 +28,6 @@ required: - compatible - reg -patternProperties: - '^mdio@[0-1]$': - type: object - properties: - reg: - maxItems: 1 - - "#address-cells": - const: 1 - - "#size-cells": - const: 0 - - required: - - reg - - "#address-cells" - - "#size-cells" - unevaluatedProperties: false examples: diff --git a/Documentation/devicetree/bindings/net/brcm,bcmgenet.txt b/Documentation/devicetree/bindings/net/brcm,bcmgenet.txt deleted file mode 100644 index 0b5994fba35f..000000000000 --- a/Documentation/devicetree/bindings/net/brcm,bcmgenet.txt +++ /dev/null @@ -1,125 +0,0 @@ -* Broadcom BCM7xxx Ethernet Controller (GENET) - -Required properties: -- compatible: should contain one of "brcm,genet-v1", "brcm,genet-v2", - "brcm,genet-v3", "brcm,genet-v4", "brcm,genet-v5", "brcm,bcm2711-genet-v5" or - "brcm,bcm7712-genet-v5". -- reg: address and length of the register set for the device -- interrupts and/or interrupts-extended: must be two cells, the first cell - is the general purpose interrupt line, while the second cell is the - interrupt for the ring RX and TX queues operating in ring mode. An - optional third interrupt cell for Wake-on-LAN can be specified. - See Documentation/devicetree/bindings/interrupt-controller/interrupts.txt - for information on the property specifics. -- phy-mode: see ethernet.txt file in the same directory -- #address-cells: should be 1 -- #size-cells: should be 1 - -Optional properties: -- clocks: When provided, must be two phandles to the functional clocks nodes - of the GENET block. The first phandle is the main GENET clock used during - normal operation, while the second phandle is the Wake-on-LAN clock. -- clock-names: When provided, names of the functional clock phandles, first - name should be "enet" and second should be "enet-wol". - -- phy-handle: See ethernet.txt file in the same directory; used to describe - configurations where a PHY (internal or external) is used. - -- fixed-link: When the GENET interface is connected to a MoCA hardware block or - when operating in a RGMII to RGMII type of connection, or when the MDIO bus is - voluntarily disabled, this property should be used to describe the "fixed link". - See Documentation/devicetree/bindings/net/fixed-link.txt for information on - the property specifics - -Required child nodes: - -- mdio bus node: this node should always be present regardless of the PHY - configuration of the GENET instance - -MDIO bus node required properties: - -- compatible: should contain one of "brcm,genet-mdio-v1", "brcm,genet-mdio-v2" - "brcm,genet-mdio-v3", "brcm,genet-mdio-v4", "brcm,genet-mdio-v5", the version - has to match the parent node compatible property (e.g: brcm,genet-v4 pairs - with brcm,genet-mdio-v4) -- reg: address and length relative to the parent node base register address -- #address-cells: address cell for MDIO bus addressing, should be 1 -- #size-cells: size of the cells for MDIO bus addressing, should be 0 - -Ethernet PHY node properties: - -See Documentation/devicetree/bindings/net/phy.txt for the list of required and -optional properties. - -Internal Gigabit PHY example: - -ethernet@f0b60000 { - phy-mode = "internal"; - phy-handle = <&phy1>; - mac-address = [ 00 10 18 36 23 1a ]; - compatible = "brcm,genet-v4"; - #address-cells = <0x1>; - #size-cells = <0x1>; - reg = <0xf0b60000 0xfc4c>; - interrupts = <0x0 0x14 0x0>, <0x0 0x15 0x0>; - - mdio@e14 { - compatible = "brcm,genet-mdio-v4"; - #address-cells = <0x1>; - #size-cells = <0x0>; - reg = <0xe14 0x8>; - - phy1: ethernet-phy@1 { - max-speed = <1000>; - reg = <0x1>; - compatible = "ethernet-phy-ieee802.3-c22"; - }; - }; -}; - -MoCA interface / MAC to MAC example: - -ethernet@f0b80000 { - phy-mode = "moca"; - fixed-link = <1 0 1000 0 0>; - mac-address = [ 00 10 18 36 24 1a ]; - compatible = "brcm,genet-v4"; - #address-cells = <0x1>; - #size-cells = <0x1>; - reg = <0xf0b80000 0xfc4c>; - interrupts = <0x0 0x16 0x0>, <0x0 0x17 0x0>; - - mdio@e14 { - compatible = "brcm,genet-mdio-v4"; - #address-cells = <0x1>; - #size-cells = <0x0>; - reg = <0xe14 0x8>; - }; -}; - - -External MDIO-connected Gigabit PHY/switch: - -ethernet@f0ba0000 { - phy-mode = "rgmii"; - phy-handle = <&phy0>; - mac-address = [ 00 10 18 36 26 1a ]; - compatible = "brcm,genet-v4"; - #address-cells = <0x1>; - #size-cells = <0x1>; - reg = <0xf0ba0000 0xfc4c>; - interrupts = <0x0 0x18 0x0>, <0x0 0x19 0x0>; - - mdio@e14 { - compatible = "brcm,genet-mdio-v4"; - #address-cells = <0x1>; - #size-cells = <0x0>; - reg = <0xe14 0x8>; - - phy0: ethernet-phy@0 { - max-speed = <1000>; - reg = <0x0>; - compatible = "ethernet-phy-ieee802.3-c22"; - }; - }; -}; diff --git a/Documentation/devicetree/bindings/net/brcm,bcmgenet.yaml b/Documentation/devicetree/bindings/net/brcm,bcmgenet.yaml new file mode 100644 index 000000000000..e5af53508e25 --- /dev/null +++ b/Documentation/devicetree/bindings/net/brcm,bcmgenet.yaml @@ -0,0 +1,145 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/net/brcm,bcmgenet.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Broadcom BCM7xxx Ethernet Controller (GENET) binding + +maintainers: + - Doug Berger <opendmb@gmail.com> + - Florian Fainelli <f.fainelli@gmail.com> + +properties: + compatible: + enum: + - brcm,genet-v1 + - brcm,genet-v2 + - brcm,genet-v3 + - brcm,genet-v4 + - brcm,genet-v5 + - brcm,bcm2711-genet-v5 + - brcm,bcm7712-genet-v5 + + reg: + maxItems: 1 + + interrupts: + minItems: 2 + items: + - description: general purpose interrupt line + - description: RX and TX rings interrupt line + - description: Wake-on-LAN interrupt line + + + clocks: + minItems: 1 + items: + - description: main clock + - description: EEE clock + - description: Wake-on-LAN clock + + clock-names: + minItems: 1 + items: + - const: enet + - const: enet-eee + - const: enet-wol + + "#address-cells": + const: 1 + + "#size-cells": + const: 1 + +patternProperties: + "^mdio@[0-9a-f]+$": + type: object + $ref: "brcm,unimac-mdio.yaml" + + description: + GENET internal UniMAC MDIO bus + +required: + - reg + - interrupts + - phy-mode + - "#address-cells" + - "#size-cells" + +allOf: + - $ref: ethernet-controller.yaml + +unevaluatedProperties: false + +examples: + #include <dt-bindings/interrupt-controller/arm-gic.h> + + - | + ethernet@f0b60000 { + phy-mode = "internal"; + phy-handle = <&phy1>; + mac-address = [ 00 10 18 36 23 1a ]; + compatible = "brcm,genet-v4"; + reg = <0xf0b60000 0xfc4c>; + interrupts = <0x0 0x14 0x0>, <0x0 0x15 0x0>; + #address-cells = <1>; + #size-cells = <1>; + + mdio0: mdio@e14 { + compatible = "brcm,genet-mdio-v4"; + #address-cells = <1>; + #size-cells = <0>; + reg = <0xe14 0x8>; + + phy1: ethernet-phy@1 { + max-speed = <1000>; + reg = <1>; + compatible = "ethernet-phy-ieee802.3-c22"; + }; + }; + }; + + - | + ethernet@f0b80000 { + phy-mode = "moca"; + fixed-link = <1 0 1000 0 0>; + mac-address = [ 00 10 18 36 24 1a ]; + compatible = "brcm,genet-v4"; + #address-cells = <1>; + #size-cells = <1>; + reg = <0xf0b80000 0xfc4c>; + interrupts = <0x0 0x16 0x0>, <0x0 0x17 0x0>; + + mdio1: mdio@e14 { + compatible = "brcm,genet-mdio-v4"; + #address-cells = <1>; + #size-cells = <0>; + reg = <0xe14 0x8>; + }; + }; + + - | + ethernet@f0ba0000 { + phy-mode = "rgmii"; + phy-handle = <&phy0>; + mac-address = [ 00 10 18 36 26 1a ]; + compatible = "brcm,genet-v4"; + #address-cells = <1>; + #size-cells = <1>; + reg = <0xf0ba0000 0xfc4c>; + interrupts = <0x0 0x18 0x0>, <0x0 0x19 0x0>; + + mdio2: mdio@e14 { + compatible = "brcm,genet-mdio-v4"; + #address-cells = <1>; + #size-cells = <0>; + reg = <0xe14 0x8>; + + phy0: ethernet-phy@0 { + max-speed = <1000>; + reg = <0>; + compatible = "ethernet-phy-ieee802.3-c22"; + }; + }; + }; diff --git a/Documentation/devicetree/bindings/net/brcm,mdio-mux-iproc.txt b/Documentation/devicetree/bindings/net/brcm,mdio-mux-iproc.txt deleted file mode 100644 index deb9e852ea27..000000000000 --- a/Documentation/devicetree/bindings/net/brcm,mdio-mux-iproc.txt +++ /dev/null @@ -1,62 +0,0 @@ -Properties for an MDIO bus multiplexer found in Broadcom iProc based SoCs. - -This MDIO bus multiplexer defines buses that could be internal as well as -external to SoCs and could accept MDIO transaction compatible to C-22 or -C-45 Clause. When child bus is selected, one needs to select these two -properties as well to generate desired MDIO transaction on appropriate bus. - -Required properties in addition to the generic multiplexer properties: - -MDIO multiplexer node: -- compatible: brcm,mdio-mux-iproc. - -Every non-ethernet PHY requires a compatible so that it could be probed based -on this compatible string. - -Optional properties: -- clocks: phandle of the core clock which drives the mdio block. - -Additional information regarding generic multiplexer properties can be found -at- Documentation/devicetree/bindings/net/mdio-mux.yaml - - -for example: - mdio_mux_iproc: mdio-mux@66020000 { - compatible = "brcm,mdio-mux-iproc"; - reg = <0x66020000 0x250>; - #address-cells = <1>; - #size-cells = <0>; - - mdio@0 { - reg = <0x0>; - #address-cells = <1>; - #size-cells = <0>; - - pci_phy0: pci-phy@0 { - compatible = "brcm,ns2-pcie-phy"; - reg = <0x0>; - #phy-cells = <0>; - }; - }; - - mdio@7 { - reg = <0x7>; - #address-cells = <1>; - #size-cells = <0>; - - pci_phy1: pci-phy@0 { - compatible = "brcm,ns2-pcie-phy"; - reg = <0x0>; - #phy-cells = <0>; - }; - }; - mdio@10 { - reg = <0x10>; - #address-cells = <1>; - #size-cells = <0>; - - gphy0: eth-phy@10 { - reg = <0x10>; - }; - }; - }; diff --git a/Documentation/devicetree/bindings/net/brcm,mdio-mux-iproc.yaml b/Documentation/devicetree/bindings/net/brcm,mdio-mux-iproc.yaml new file mode 100644 index 000000000000..af96b4fd89d5 --- /dev/null +++ b/Documentation/devicetree/bindings/net/brcm,mdio-mux-iproc.yaml @@ -0,0 +1,80 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/net/brcm,mdio-mux-iproc.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: MDIO bus multiplexer found in Broadcom iProc based SoCs. + +maintainers: + - Florian Fainelli <f.fainelli@gmail.com> + +description: + This MDIO bus multiplexer defines buses that could be internal as well as + external to SoCs and could accept MDIO transaction compatible to C-22 or + C-45 Clause. When child bus is selected, one needs to select these two + properties as well to generate desired MDIO transaction on appropriate bus. + +allOf: + - $ref: /schemas/net/mdio-mux.yaml# + +properties: + compatible: + const: brcm,mdio-mux-iproc + + reg: + maxItems: 1 + + clocks: + maxItems: 1 + description: core clock driving the MDIO block + + +required: + - compatible + - reg + +unevaluatedProperties: false + +examples: + - | + mdio_mux_iproc: mdio-mux@66020000 { + compatible = "brcm,mdio-mux-iproc"; + reg = <0x66020000 0x250>; + #address-cells = <1>; + #size-cells = <0>; + + mdio@0 { + reg = <0x0>; + #address-cells = <1>; + #size-cells = <0>; + + pci_phy0: pci-phy@0 { + compatible = "brcm,ns2-pcie-phy"; + reg = <0x0>; + #phy-cells = <0>; + }; + }; + + mdio@7 { + reg = <0x7>; + #address-cells = <1>; + #size-cells = <0>; + + pci_phy1: pci-phy@0 { + compatible = "brcm,ns2-pcie-phy"; + reg = <0x0>; + #phy-cells = <0>; + }; + }; + + mdio@10 { + reg = <0x10>; + #address-cells = <1>; + #size-cells = <0>; + + gphy0: eth-phy@10 { + reg = <0x10>; + }; + }; + }; diff --git a/Documentation/devicetree/bindings/net/brcm,systemport.txt b/Documentation/devicetree/bindings/net/brcm,systemport.txt deleted file mode 100644 index 75736739bfdd..000000000000 --- a/Documentation/devicetree/bindings/net/brcm,systemport.txt +++ /dev/null @@ -1,38 +0,0 @@ -* Broadcom BCM7xxx Ethernet Systemport Controller (SYSTEMPORT) - -Required properties: -- compatible: should be one of: - "brcm,systemport-v1.00" - "brcm,systemportlite-v1.00" or - "brcm,systemport" -- reg: address and length of the register set for the device. -- interrupts: interrupts for the device, first cell must be for the rx - interrupts, and the second cell should be for the transmit queues. An - optional third interrupt cell for Wake-on-LAN can be specified -- local-mac-address: Ethernet MAC address (48 bits) of this adapter -- phy-mode: Should be a string describing the PHY interface to the - Ethernet switch/PHY, see Documentation/devicetree/bindings/net/ethernet.txt -- fixed-link: see Documentation/devicetree/bindings/net/fixed-link.txt for - the property specific details - -Optional properties: -- systemport,num-tier2-arb: number of tier 2 arbiters, an integer -- systemport,num-tier1-arb: number of tier 1 arbiters, an integer -- systemport,num-txq: number of HW transmit queues, an integer -- systemport,num-rxq: number of HW receive queues, an integer -- clocks: When provided, must be two phandles to the functional clocks nodes of - the SYSTEMPORT block. The first phandle is the main SYSTEMPORT clock used - during normal operation, while the second phandle is the Wake-on-LAN clock. -- clock-names: When provided, names of the functional clock phandles, first - name should be "sw_sysport" and second should be "sw_sysportwol". - -Example: -ethernet@f04a0000 { - compatible = "brcm,systemport-v1.00"; - reg = <0xf04a0000 0x4650>; - local-mac-address = [ 00 11 22 33 44 55 ]; - fixed-link = <0 1 1000 0 0>; - phy-mode = "gmii"; - interrupts = <0x0 0x16 0x0>, - <0x0 0x17 0x0>; -}; diff --git a/Documentation/devicetree/bindings/net/brcm,systemport.yaml b/Documentation/devicetree/bindings/net/brcm,systemport.yaml new file mode 100644 index 000000000000..5fc9c9fafd85 --- /dev/null +++ b/Documentation/devicetree/bindings/net/brcm,systemport.yaml @@ -0,0 +1,86 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/net/brcm,systemport.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Broadcom BCM7xxx Ethernet Systemport Controller (SYSTEMPORT) + +maintainers: + - Florian Fainelli <f.fainelli@gmail.com> + +properties: + compatible: + enum: + - brcm,systemport-v1.00 + - brcm,systemportlite-v1.00 + - brcm,systemport + + reg: + maxItems: 1 + + interrupts: + minItems: 2 + items: + - description: interrupt line for RX queues + - description: interrupt line for TX queues + - description: interrupt line for Wake-on-LAN + + clocks: + items: + - description: main clock + - description: Wake-on-LAN clock + + clock-names: + items: + - const: sw_sysport + - const: sw_sysportwol + + systemport,num-tier2-arb: + $ref: /schemas/types.yaml#/definitions/uint32 + description: + Number of tier 2 arbiters + + systemport,num-tier1-arb: + $ref: /schemas/types.yaml#/definitions/uint32 + description: + Number of tier 2 arbiters + + systemport,num-txq: + $ref: /schemas/types.yaml#/definitions/uint32 + minimum: 1 + maximum: 32 + description: + Number of HW transmit queues + + systemport,num-rxq: + $ref: /schemas/types.yaml#/definitions/uint32 + minimum: 1 + maximum: 32 + description: + Number of HW receive queues + +required: + - reg + - interrupts + - phy-mode + +allOf: + - $ref: "ethernet-controller.yaml#" + +unevaluatedProperties: false + +examples: + - | + ethernet@f04a0000 { + compatible = "brcm,systemport-v1.00"; + reg = <0xf04a0000 0x4650>; + local-mac-address = [ 00 11 22 33 44 55 ]; + phy-mode = "gmii"; + interrupts = <0x0 0x16 0x0>, + <0x0 0x17 0x0>; + fixed-link { + speed = <1000>; + full-duplex; + }; + }; diff --git a/Documentation/devicetree/bindings/net/brcm,unimac-mdio.yaml b/Documentation/devicetree/bindings/net/brcm,unimac-mdio.yaml index f4f4c37f1d4e..0be426ee1e44 100644 --- a/Documentation/devicetree/bindings/net/brcm,unimac-mdio.yaml +++ b/Documentation/devicetree/bindings/net/brcm,unimac-mdio.yaml @@ -7,6 +7,8 @@ $schema: http://devicetree.org/meta-schemas/core.yaml# title: Broadcom UniMAC MDIO bus controller maintainers: + - Doug Berger <opendmb@gmail.com> + - Florian Fainelli <f.fainelli@gmail.com> - Rafał Miłecki <rafal@milecki.pl> allOf: @@ -64,7 +66,6 @@ unevaluatedProperties: false required: - reg - - reg-names - '#address-cells' - '#size-cells' diff --git a/Documentation/devicetree/bindings/net/can/allwinner,sun4i-a10-can.yaml b/Documentation/devicetree/bindings/net/can/allwinner,sun4i-a10-can.yaml index a95960ee3feb..c93fe9d3ea82 100644 --- a/Documentation/devicetree/bindings/net/can/allwinner,sun4i-a10-can.yaml +++ b/Documentation/devicetree/bindings/net/can/allwinner,sun4i-a10-can.yaml @@ -17,6 +17,7 @@ properties: - const: allwinner,sun7i-a20-can - const: allwinner,sun4i-a10-can - const: allwinner,sun4i-a10-can + - const: allwinner,sun8i-r40-can reg: maxItems: 1 @@ -27,6 +28,19 @@ properties: clocks: maxItems: 1 + resets: + maxItems: 1 + +if: + properties: + compatible: + contains: + const: allwinner,sun8i-r40-can + +then: + required: + - resets + required: - compatible - reg @@ -47,5 +61,15 @@ examples: interrupts = <GIC_SPI 26 IRQ_TYPE_LEVEL_HIGH>; clocks = <&ccu CLK_APB1_CAN>; }; + - | + #define RST_BUS_CAN 68 + #define CLK_BUS_CAN 91 + can1: can@1c2bc00 { + compatible = "allwinner,sun8i-r40-can"; + reg = <0x01c2bc00 0x400>; + interrupts = <GIC_SPI 26 IRQ_TYPE_LEVEL_HIGH>; + clocks = <&ccu CLK_BUS_CAN>; + resets = <&ccu RST_BUS_CAN>; + }; ... diff --git a/Documentation/devicetree/bindings/net/can/bosch,m_can.yaml b/Documentation/devicetree/bindings/net/can/bosch,m_can.yaml index fb547e26c676..401ab7cdb379 100644 --- a/Documentation/devicetree/bindings/net/can/bosch,m_can.yaml +++ b/Documentation/devicetree/bindings/net/can/bosch,m_can.yaml @@ -76,33 +76,31 @@ properties: M_CAN user manual for details. $ref: /schemas/types.yaml#/definitions/int32-array items: - items: - - description: The 'offset' is an address offset of the Message RAM where - the following elements start from. This is usually set to 0x0 if - you're using a private Message RAM. - default: 0 - - description: 11-bit Filter 0-128 elements / 0-128 words - minimum: 0 - maximum: 128 - - description: 29-bit Filter 0-64 elements / 0-128 words - minimum: 0 - maximum: 64 - - description: Rx FIFO 0 0-64 elements / 0-1152 words - minimum: 0 - maximum: 64 - - description: Rx FIFO 1 0-64 elements / 0-1152 words - minimum: 0 - maximum: 64 - - description: Rx Buffers 0-64 elements / 0-1152 words - minimum: 0 - maximum: 64 - - description: Tx Event FIFO 0-32 elements / 0-64 words - minimum: 0 - maximum: 32 - - description: Tx Buffers 0-32 elements / 0-576 words - minimum: 0 - maximum: 32 - maxItems: 1 + - description: The 'offset' is an address offset of the Message RAM where + the following elements start from. This is usually set to 0x0 if + you're using a private Message RAM. + default: 0 + - description: 11-bit Filter 0-128 elements / 0-128 words + minimum: 0 + maximum: 128 + - description: 29-bit Filter 0-64 elements / 0-128 words + minimum: 0 + maximum: 64 + - description: Rx FIFO 0 0-64 elements / 0-1152 words + minimum: 0 + maximum: 64 + - description: Rx FIFO 1 0-64 elements / 0-1152 words + minimum: 0 + maximum: 64 + - description: Rx Buffers 0-64 elements / 0-1152 words + minimum: 0 + maximum: 64 + - description: Tx Event FIFO 0-32 elements / 0-64 words + minimum: 0 + maximum: 32 + - description: Tx Buffers 0-32 elements / 0-576 words + minimum: 0 + maximum: 32 power-domains: description: diff --git a/Documentation/devicetree/bindings/net/can/tcan4x5x.txt b/Documentation/devicetree/bindings/net/can/tcan4x5x.txt index 0968b40aef1e..e3501bfa22e9 100644 --- a/Documentation/devicetree/bindings/net/can/tcan4x5x.txt +++ b/Documentation/devicetree/bindings/net/can/tcan4x5x.txt @@ -31,7 +31,7 @@ tcan4x5x: tcan4x5x@0 { #address-cells = <1>; #size-cells = <1>; spi-max-frequency = <10000000>; - bosch,mram-cfg = <0x0 0 0 32 0 0 1 1>; + bosch,mram-cfg = <0x0 0 0 16 0 0 1 1>; interrupt-parent = <&gpio1>; interrupts = <14 IRQ_TYPE_LEVEL_LOW>; device-state-gpios = <&gpio3 21 GPIO_ACTIVE_HIGH>; diff --git a/Documentation/devicetree/bindings/net/cdns,macb.yaml b/Documentation/devicetree/bindings/net/cdns,macb.yaml new file mode 100644 index 000000000000..8dd06db34169 --- /dev/null +++ b/Documentation/devicetree/bindings/net/cdns,macb.yaml @@ -0,0 +1,159 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/net/cdns,macb.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Cadence MACB/GEM Ethernet controller + +maintainers: + - Nicolas Ferre <nicolas.ferre@microchip.com> + - Claudiu Beznea <claudiu.beznea@microchip.com> + +properties: + compatible: + oneOf: + - items: + - enum: + - cdns,at91rm9200-emac # Atmel at91rm9200 SoC + - const: cdns,emac # Generic + + - items: + - enum: + - cdns,zynq-gem # Xilinx Zynq-7xxx SoC + - cdns,zynqmp-gem # Xilinx Zynq Ultrascale+ MPSoC + - const: cdns,gem # Generic + + - items: + - enum: + - cdns,at91sam9260-macb # Atmel at91sam9 SoCs + - cdns,sam9x60-macb # Microchip sam9x60 SoC + - const: cdns,macb # Generic + + - items: + - enum: + - atmel,sama5d3-macb # 10/100Mbit IP on Atmel sama5d3 SoCs + - enum: + - cdns,at91sam9260-macb # Atmel at91sam9 SoCs. + - const: cdns,macb # Generic + + - enum: + - atmel,sama5d29-gem # GEM XL IP (10/100) on Atmel sama5d29 SoCs + - atmel,sama5d2-gem # GEM IP (10/100) on Atmel sama5d2 SoCs + - atmel,sama5d3-gem # Gigabit IP on Atmel sama5d3 SoCs + - atmel,sama5d4-gem # GEM IP (10/100) on Atmel sama5d4 SoCs + - cdns,at32ap7000-macb # Other 10/100 usage or use the generic form + - cdns,np4-macb # NP4 SoC devices + - microchip,sama7g5-emac # Microchip SAMA7G5 ethernet interface + - microchip,sama7g5-gem # Microchip SAMA7G5 gigabit ethernet interface + - sifive,fu540-c000-gem # SiFive FU540-C000 SoC + - cdns,emac # Generic + - cdns,gem # Generic + - cdns,macb # Generic + + reg: + minItems: 1 + items: + - description: Basic register set + - description: GEMGXL Management block registers on SiFive FU540-C000 SoC + + interrupts: + minItems: 1 + maxItems: 8 + description: One interrupt per available hardware queue + + clocks: + minItems: 1 + maxItems: 5 + + clock-names: + minItems: 1 + items: + - enum: [ ether_clk, hclk, pclk ] + - enum: [ hclk, pclk ] + - const: tx_clk + - enum: [ rx_clk, tsu_clk ] + - const: tsu_clk + + local-mac-address: true + + phy-mode: true + + phy-handle: true + + fixed-link: true + + iommus: + maxItems: 1 + + power-domains: + maxItems: 1 + + '#address-cells': + const: 1 + + '#size-cells': + const: 0 + + mdio: + type: object + description: + Node containing PHY children. If this node is not present, then PHYs will + be direct children. + +patternProperties: + "^ethernet-phy@[0-9a-f]$": + type: object + $ref: ethernet-phy.yaml# + + properties: + reset-gpios: true + + magic-packet: + description: + Indicates that the hardware supports waking up via magic packet. + + unevaluatedProperties: false + +required: + - compatible + - reg + - interrupts + - clocks + - clock-names + - phy-mode + +allOf: + - $ref: ethernet-controller.yaml# + + - if: + not: + properties: + compatible: + contains: + const: sifive,fu540-c000-gem + then: + properties: + reg: + maxItems: 1 + +unevaluatedProperties: false + +examples: + - | + macb0: ethernet@fffc4000 { + compatible = "cdns,at32ap7000-macb"; + reg = <0xfffc4000 0x4000>; + interrupts = <21>; + phy-mode = "rmii"; + local-mac-address = [3a 0e 03 04 05 06]; + clock-names = "pclk", "hclk", "tx_clk"; + clocks = <&clkc 30>, <&clkc 30>, <&clkc 13>; + #address-cells = <1>; + #size-cells = <0>; + + ethernet-phy@1 { + reg = <0x1>; + reset-gpios = <&pioE 6 1>; + }; + }; diff --git a/Documentation/devicetree/bindings/net/dsa/dsa-port.yaml b/Documentation/devicetree/bindings/net/dsa/dsa-port.yaml new file mode 100644 index 000000000000..702df848a71d --- /dev/null +++ b/Documentation/devicetree/bindings/net/dsa/dsa-port.yaml @@ -0,0 +1,77 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/net/dsa/dsa-port.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Ethernet Switch port Device Tree Bindings + +maintainers: + - Andrew Lunn <andrew@lunn.ch> + - Florian Fainelli <f.fainelli@gmail.com> + - Vivien Didelot <vivien.didelot@gmail.com> + +description: + Ethernet switch port Description + +allOf: + - $ref: "http://devicetree.org/schemas/net/ethernet-controller.yaml#" + +properties: + reg: + description: Port number + + label: + description: + Describes the label associated with this port, which will become + the netdev name + $ref: /schemas/types.yaml#/definitions/string + + link: + description: + Should be a list of phandles to other switch's DSA port. This + port is used as the outgoing port towards the phandle ports. The + full routing information must be given, not just the one hop + routes to neighbouring switches + $ref: /schemas/types.yaml#/definitions/phandle-array + + ethernet: + description: + Should be a phandle to a valid Ethernet device node. This host + device is what the switch port is connected to + $ref: /schemas/types.yaml#/definitions/phandle + + dsa-tag-protocol: + description: + Instead of the default, the switch will use this tag protocol if + possible. Useful when a device supports multiple protocols and + the default is incompatible with the Ethernet device. + enum: + - dsa + - edsa + - ocelot + - ocelot-8021q + - seville + + phy-handle: true + + phy-mode: true + + fixed-link: true + + mac-address: true + + sfp: true + + managed: true + + rx-internal-delay-ps: true + + tx-internal-delay-ps: true + +required: + - reg + +additionalProperties: true + +... diff --git a/Documentation/devicetree/bindings/net/dsa/dsa.yaml b/Documentation/devicetree/bindings/net/dsa/dsa.yaml index 2ad7f79ad371..b9d48e357e77 100644 --- a/Documentation/devicetree/bindings/net/dsa/dsa.yaml +++ b/Documentation/devicetree/bindings/net/dsa/dsa.yaml @@ -46,65 +46,9 @@ patternProperties: type: object description: Ethernet switch ports - allOf: - - $ref: "http://devicetree.org/schemas/net/ethernet-controller.yaml#" + $ref: dsa-port.yaml# - properties: - reg: - description: Port number - - label: - description: - Describes the label associated with this port, which will become - the netdev name - $ref: /schemas/types.yaml#/definitions/string - - link: - description: - Should be a list of phandles to other switch's DSA port. This - port is used as the outgoing port towards the phandle ports. The - full routing information must be given, not just the one hop - routes to neighbouring switches - $ref: /schemas/types.yaml#/definitions/phandle-array - - ethernet: - description: - Should be a phandle to a valid Ethernet device node. This host - device is what the switch port is connected to - $ref: /schemas/types.yaml#/definitions/phandle - - dsa-tag-protocol: - description: - Instead of the default, the switch will use this tag protocol if - possible. Useful when a device supports multiple protocols and - the default is incompatible with the Ethernet device. - enum: - - dsa - - edsa - - ocelot - - ocelot-8021q - - seville - - phy-handle: true - - phy-mode: true - - fixed-link: true - - mac-address: true - - sfp: true - - managed: true - - rx-internal-delay-ps: true - - tx-internal-delay-ps: true - - required: - - reg - - additionalProperties: false + unevaluatedProperties: false oneOf: - required: diff --git a/Documentation/devicetree/bindings/net/dsa/nxp,sja1105.yaml b/Documentation/devicetree/bindings/net/dsa/nxp,sja1105.yaml index 24cd733c11d1..1ea0bd490473 100644 --- a/Documentation/devicetree/bindings/net/dsa/nxp,sja1105.yaml +++ b/Documentation/devicetree/bindings/net/dsa/nxp,sja1105.yaml @@ -52,10 +52,8 @@ properties: patternProperties: "^mdio@[0-1]$": - type: object - - allOf: - - $ref: "http://devicetree.org/schemas/net/mdio.yaml#" + $ref: /schemas/net/mdio.yaml# + unevaluatedProperties: false properties: compatible: diff --git a/Documentation/devicetree/bindings/net/dsa/qca8k.yaml b/Documentation/devicetree/bindings/net/dsa/qca8k.yaml index 48de0ace265d..f3c88371d76c 100644 --- a/Documentation/devicetree/bindings/net/dsa/qca8k.yaml +++ b/Documentation/devicetree/bindings/net/dsa/qca8k.yaml @@ -58,33 +58,14 @@ properties: B68 on the QCA832x and B49 on the QCA833x. mdio: - type: object + $ref: /schemas/net/mdio.yaml# + unevaluatedProperties: false description: Qca8k switch have an internal mdio to access switch port. If this is not present, the legacy mapping is used and the internal mdio access is used. With the legacy mapping the reg corresponding to the internal mdio is the switch reg with an offset of -1. - properties: - '#address-cells': - const: 1 - '#size-cells': - const: 0 - - patternProperties: - "^(ethernet-)?phy@[0-4]$": - type: object - - allOf: - - $ref: "http://devicetree.org/schemas/net/mdio.yaml#" - - properties: - reg: - maxItems: 1 - - required: - - reg - patternProperties: "^(ethernet-)?ports$": type: object @@ -99,40 +80,9 @@ patternProperties: type: object description: Ethernet switch ports - properties: - reg: - description: Port number - - label: - description: - Describes the label associated with this port, which will become - the netdev name - $ref: /schemas/types.yaml#/definitions/string - - link: - description: - Should be a list of phandles to other switch's DSA port. This - port is used as the outgoing port towards the phandle ports. The - full routing information must be given, not just the one hop - routes to neighbouring switches - $ref: /schemas/types.yaml#/definitions/phandle-array - - ethernet: - description: - Should be a phandle to a valid Ethernet device node. This host - device is what the switch port is connected to - $ref: /schemas/types.yaml#/definitions/phandle - - phy-handle: true - - phy-mode: true - - fixed-link: true - - mac-address: true - - sfp: true + $ref: dsa-port.yaml# + properties: qca,sgmii-rxclk-falling-edge: $ref: /schemas/types.yaml#/definitions/flag description: @@ -154,10 +104,7 @@ patternProperties: SGMII on the QCA8337, it is advised to set this unless a communication issue is observed. - required: - - reg - - additionalProperties: false + unevaluatedProperties: false oneOf: - required: diff --git a/Documentation/devicetree/bindings/net/engleder,tsnep.yaml b/Documentation/devicetree/bindings/net/engleder,tsnep.yaml new file mode 100644 index 000000000000..d0e1476e15b5 --- /dev/null +++ b/Documentation/devicetree/bindings/net/engleder,tsnep.yaml @@ -0,0 +1,79 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/net/engleder,tsnep.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: TSN endpoint Ethernet MAC binding + +maintainers: + - Gerhard Engleder <gerhard@engleder-embedded.com> + +allOf: + - $ref: ethernet-controller.yaml# + +properties: + compatible: + const: engleder,tsnep + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + local-mac-address: true + + mac-address: true + + nvmem-cells: true + + nvmem-cells-names: true + + phy-connection-type: + enum: + - mii + - gmii + - rgmii + - rgmii-id + + phy-mode: true + + phy-handle: true + + mdio: + type: object + $ref: "mdio.yaml#" + description: optional node for embedded MDIO controller + +required: + - compatible + - reg + - interrupts + +additionalProperties: false + +examples: + - | + axi { + #address-cells = <2>; + #size-cells = <2>; + tnsep0: ethernet@a0000000 { + compatible = "engleder,tsnep"; + reg = <0x0 0xa0000000 0x0 0x10000>; + interrupts = <0 89 1>; + interrupt-parent = <&gic>; + local-mac-address = [00 00 00 00 00 00]; + phy-mode = "rgmii"; + phy-handle = <&phy0>; + mdio { + #address-cells = <1>; + #size-cells = <0>; + suppress-preamble; + phy0: ethernet-phy@1 { + reg = <1>; + rxc-skew-ps = <1080>; + }; + }; + }; + }; diff --git a/Documentation/devicetree/bindings/net/ethernet-controller.yaml b/Documentation/devicetree/bindings/net/ethernet-controller.yaml index b0933a8c295a..34c5463abcec 100644 --- a/Documentation/devicetree/bindings/net/ethernet-controller.yaml +++ b/Documentation/devicetree/bindings/net/ethernet-controller.yaml @@ -17,9 +17,8 @@ properties: description: Specifies the MAC address that was assigned to the network device. $ref: /schemas/types.yaml#/definitions/uint8-array - items: - - minItems: 6 - maxItems: 6 + minItems: 6 + maxItems: 6 mac-address: description: @@ -28,9 +27,8 @@ properties: to the device by the boot program is different from the local-mac-address property. $ref: /schemas/types.yaml#/definitions/uint8-array - items: - - minItems: 6 - maxItems: 6 + minItems: 6 + maxItems: 6 max-frame-size: $ref: /schemas/types.yaml#/definitions/uint32 @@ -69,6 +67,7 @@ properties: - rev-mii - rmii - rev-rmii + - moca # RX and TX delays are added by the MAC when required - rgmii @@ -163,33 +162,30 @@ properties: type: array then: deprecated: true - minItems: 1 - maxItems: 1 items: - items: - - minimum: 0 - maximum: 31 - description: - Emulated PHY ID, choose any but unique to the all - specified fixed-links + - minimum: 0 + maximum: 31 + description: + Emulated PHY ID, choose any but unique to the all + specified fixed-links - - enum: [0, 1] - description: - Duplex configuration. 0 for half duplex or 1 for - full duplex + - enum: [0, 1] + description: + Duplex configuration. 0 for half duplex or 1 for + full duplex - - enum: [10, 100, 1000] - description: - Link speed in Mbits/sec. + - enum: [10, 100, 1000, 2500, 10000] + description: + Link speed in Mbits/sec. - - enum: [0, 1] - description: - Pause configuration. 0 for no pause, 1 for pause + - enum: [0, 1] + description: + Pause configuration. 0 for no pause, 1 for pause - - enum: [0, 1] - description: - Asymmetric pause configuration. 0 for no asymmetric - pause, 1 for asymmetric pause + - enum: [0, 1] + description: + Asymmetric pause configuration. 0 for no asymmetric + pause, 1 for asymmetric pause - if: @@ -200,7 +196,7 @@ properties: description: Link speed. $ref: /schemas/types.yaml#/definitions/uint32 - enum: [10, 100, 1000] + enum: [10, 100, 1000, 2500, 10000] full-duplex: $ref: /schemas/types.yaml#/definitions/flag diff --git a/Documentation/devicetree/bindings/net/ethernet-phy.yaml b/Documentation/devicetree/bindings/net/ethernet-phy.yaml index 2766fe45bb98..ee42328a109d 100644 --- a/Documentation/devicetree/bindings/net/ethernet-phy.yaml +++ b/Documentation/devicetree/bindings/net/ethernet-phy.yaml @@ -91,6 +91,14 @@ properties: compensate for the board being designed with the lanes swapped. + enet-phy-lane-no-swap: + $ref: /schemas/types.yaml#/definitions/flag + description: + If set, indicates that PHY will disable swap of the + TX/RX lanes. This property allows the PHY to work correcly after + e.g. wrong bootstrap configuration caused by issues in PCB + layout design. + eee-broken-100tx: $ref: /schemas/types.yaml#/definitions/flag description: diff --git a/Documentation/devicetree/bindings/net/fsl,fec.yaml b/Documentation/devicetree/bindings/net/fsl,fec.yaml index eca41443fcce..fd8371e31867 100644 --- a/Documentation/devicetree/bindings/net/fsl,fec.yaml +++ b/Documentation/devicetree/bindings/net/fsl,fec.yaml @@ -165,7 +165,8 @@ properties: req_bit is the gpr bit offset for ENET stop request. mdio: - type: object + $ref: mdio.yaml# + unevaluatedProperties: false description: Specifies the mdio bus in the FEC, used as a container for phy nodes. diff --git a/Documentation/devicetree/bindings/net/fsl-fman.txt b/Documentation/devicetree/bindings/net/fsl-fman.txt index c00fb0d22c7b..020337f3c05f 100644 --- a/Documentation/devicetree/bindings/net/fsl-fman.txt +++ b/Documentation/devicetree/bindings/net/fsl-fman.txt @@ -410,6 +410,15 @@ PROPERTIES The settings and programming routines for internal/external MDIO are different. Must be included for internal MDIO. +- fsl,erratum-a009885 + Usage: optional + Value type: <boolean> + Definition: Indicates the presence of the A009885 + erratum describing that the contents of MDIO_DATA may + become corrupt unless it is read within 16 MDC cycles + of MDIO_CFG[BSY] being cleared, when performing an + MDIO read operation. + - fsl,erratum-a011043 Usage: optional Value type: <boolean> diff --git a/Documentation/devicetree/bindings/net/intel,dwmac-plat.yaml b/Documentation/devicetree/bindings/net/intel,dwmac-plat.yaml index 08a3f1f6aea2..52a7fa4f49a4 100644 --- a/Documentation/devicetree/bindings/net/intel,dwmac-plat.yaml +++ b/Documentation/devicetree/bindings/net/intel,dwmac-plat.yaml @@ -117,7 +117,7 @@ examples: snps,mtl-tx-config = <&mtl_tx_setup>; snps,tso; - mdio0 { + mdio { #address-cells = <1>; #size-cells = <0>; compatible = "snps,dwmac-mdio"; diff --git a/Documentation/devicetree/bindings/net/intel,ixp4xx-ethernet.yaml b/Documentation/devicetree/bindings/net/intel,ixp4xx-ethernet.yaml index 378ed2d3b003..67eaf02dda80 100644 --- a/Documentation/devicetree/bindings/net/intel,ixp4xx-ethernet.yaml +++ b/Documentation/devicetree/bindings/net/intel,ixp4xx-ethernet.yaml @@ -48,8 +48,8 @@ properties: and the instance to use in the second cell mdio: - type: object - $ref: "mdio.yaml#" + $ref: mdio.yaml# + unevaluatedProperties: false description: optional node for embedded MDIO controller required: diff --git a/Documentation/devicetree/bindings/net/intel,ixp4xx-hss.yaml b/Documentation/devicetree/bindings/net/intel,ixp4xx-hss.yaml new file mode 100644 index 000000000000..4dcd53c3e0b4 --- /dev/null +++ b/Documentation/devicetree/bindings/net/intel,ixp4xx-hss.yaml @@ -0,0 +1,100 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +# Copyright 2021 Linaro Ltd. +%YAML 1.2 +--- +$id: "http://devicetree.org/schemas/net/intel,ixp4xx-hss.yaml#" +$schema: "http://devicetree.org/meta-schemas/core.yaml#" + +title: Intel IXP4xx V.35 WAN High Speed Serial Link (HSS) + +maintainers: + - Linus Walleij <linus.walleij@linaro.org> + +description: | + The Intel IXP4xx HSS makes use of the IXP4xx NPE (Network + Processing Engine) and the IXP4xx Queue Manager to process + V.35 Wideband Modem (WAN) links. + +properties: + compatible: + const: intel,ixp4xx-hss + + reg: + maxItems: 1 + description: The HSS instance + + intel,npe-handle: + $ref: '/schemas/types.yaml#/definitions/phandle-array' + maxItems: 1 + description: phandle to the NPE this HSS instance is using + and the instance to use in the second cell + + intel,queue-chl-rxtrig: + $ref: '/schemas/types.yaml#/definitions/phandle-array' + maxItems: 1 + description: phandle to the RX trigger queue on the NPE + + intel,queue-chl-txready: + $ref: '/schemas/types.yaml#/definitions/phandle-array' + maxItems: 1 + description: phandle to the TX ready queue on the NPE + + intel,queue-pkt-rx: + $ref: '/schemas/types.yaml#/definitions/phandle-array' + maxItems: 1 + description: phandle to the packet RX queue on the NPE + + intel,queue-pkt-tx: + $ref: '/schemas/types.yaml#/definitions/phandle-array' + maxItems: 4 + description: phandle to the packet TX0, TX1, TX2 and TX3 queues on the NPE + + intel,queue-pkt-rxfree: + $ref: '/schemas/types.yaml#/definitions/phandle-array' + maxItems: 4 + description: phandle to the packet RXFREE0, RXFREE1, RXFREE2 and + RXFREE3 queues on the NPE + + intel,queue-pkt-txdone: + $ref: '/schemas/types.yaml#/definitions/phandle-array' + maxItems: 1 + description: phandle to the packet TXDONE queue on the NPE + + cts-gpios: + maxItems: 1 + description: Clear To Send (CTS) GPIO line + + rts-gpios: + maxItems: 1 + description: Ready To Send (RTS) GPIO line + + dcd-gpios: + maxItems: 1 + description: Data Carrier Detect (DCD) GPIO line + + dtr-gpios: + maxItems: 1 + description: Data Terminal Ready (DTR) GPIO line + + clk-internal-gpios: + maxItems: 1 + description: Clock internal GPIO line, driving this high will make the HSS + use internal clocking as opposed to external clocking + +required: + - compatible + - reg + - intel,npe-handle + - intel,queue-chl-rxtrig + - intel,queue-chl-txready + - intel,queue-pkt-rx + - intel,queue-pkt-tx + - intel,queue-pkt-rxfree + - intel,queue-pkt-txdone + - cts-gpios + - rts-gpios + - dcd-gpios + - dtr-gpios + - clk-internal-gpios + +additionalProperties: false diff --git a/Documentation/devicetree/bindings/net/lantiq,etop-xway.yaml b/Documentation/devicetree/bindings/net/lantiq,etop-xway.yaml index 437502c5ca96..3ce9f9a16baf 100644 --- a/Documentation/devicetree/bindings/net/lantiq,etop-xway.yaml +++ b/Documentation/devicetree/bindings/net/lantiq,etop-xway.yaml @@ -46,7 +46,6 @@ properties: required: - compatible - reg - - interrupt-parent - interrupts - interrupt-names - lantiq,tx-burst-length diff --git a/Documentation/devicetree/bindings/net/lantiq,xrx200-net.yaml b/Documentation/devicetree/bindings/net/lantiq,xrx200-net.yaml index 7bc074a42369..5bc1a21ca579 100644 --- a/Documentation/devicetree/bindings/net/lantiq,xrx200-net.yaml +++ b/Documentation/devicetree/bindings/net/lantiq,xrx200-net.yaml @@ -38,7 +38,6 @@ properties: required: - compatible - reg - - interrupt-parent - interrupts - interrupt-names - "#address-cells" diff --git a/Documentation/devicetree/bindings/net/litex,liteeth.yaml b/Documentation/devicetree/bindings/net/litex,liteeth.yaml index 76c164a8199a..ebf4e360f8dd 100644 --- a/Documentation/devicetree/bindings/net/litex,liteeth.yaml +++ b/Documentation/devicetree/bindings/net/litex,liteeth.yaml @@ -62,6 +62,7 @@ properties: mdio: $ref: mdio.yaml# + unevaluatedProperties: false required: - compatible diff --git a/Documentation/devicetree/bindings/net/macb.txt b/Documentation/devicetree/bindings/net/macb.txt deleted file mode 100644 index a1b06fd1962e..000000000000 --- a/Documentation/devicetree/bindings/net/macb.txt +++ /dev/null @@ -1,60 +0,0 @@ -* Cadence MACB/GEM Ethernet controller - -Required properties: -- compatible: Should be "cdns,[<chip>-]{macb|gem}" - Use "cdns,at91rm9200-emac" Atmel at91rm9200 SoC. - Use "cdns,at91sam9260-macb" for Atmel at91sam9 SoCs. - Use "cdns,sam9x60-macb" for Microchip sam9x60 SoC. - Use "cdns,np4-macb" for NP4 SoC devices. - Use "cdns,at32ap7000-macb" for other 10/100 usage or use the generic form: "cdns,macb". - Use "atmel,sama5d2-gem" for the GEM IP (10/100) available on Atmel sama5d2 SoCs. - Use "atmel,sama5d29-gem" for GEM XL IP (10/100) available on Atmel sama5d29 SoCs. - Use "atmel,sama5d3-macb" for the 10/100Mbit IP available on Atmel sama5d3 SoCs. - Use "atmel,sama5d3-gem" for the Gigabit IP available on Atmel sama5d3 SoCs. - Use "atmel,sama5d4-gem" for the GEM IP (10/100) available on Atmel sama5d4 SoCs. - Use "cdns,zynq-gem" Xilinx Zynq-7xxx SoC. - Use "cdns,zynqmp-gem" for Zynq Ultrascale+ MPSoC. - Use "sifive,fu540-c000-gem" for SiFive FU540-C000 SoC. - Use "microchip,sama7g5-emac" for Microchip SAMA7G5 ethernet interface. - Use "microchip,sama7g5-gem" for Microchip SAMA7G5 gigabit ethernet interface. - Or the generic form: "cdns,emac". -- reg: Address and length of the register set for the device - For "sifive,fu540-c000-gem", second range is required to specify the - address and length of the registers for GEMGXL Management block. -- interrupts: Should contain macb interrupt -- phy-mode: See ethernet.txt file in the same directory. -- clock-names: Tuple listing input clock names. - Required elements: 'pclk', 'hclk' - Optional elements: 'tx_clk' - Optional elements: 'rx_clk' applies to cdns,zynqmp-gem - Optional elements: 'tsu_clk' -- clocks: Phandles to input clocks. - -Optional properties: -- mdio: node containing PHY children. If this node is not present, then PHYs - will be direct children. - -The MAC address will be determined using the optional properties -defined in ethernet.txt. - -Optional properties for PHY child node: -- reset-gpios : Should specify the gpio for phy reset -- magic-packet : If present, indicates that the hardware supports waking - up via magic packet. -- phy-handle : see ethernet.txt file in the same directory - -Examples: - - macb0: ethernet@fffc4000 { - compatible = "cdns,at32ap7000-macb"; - reg = <0xfffc4000 0x4000>; - interrupts = <21>; - phy-mode = "rmii"; - local-mac-address = [3a 0e 03 04 05 06]; - clock-names = "pclk", "hclk", "tx_clk"; - clocks = <&clkc 30>, <&clkc 30>, <&clkc 13>; - ethernet-phy@1 { - reg = <0x1>; - reset-gpios = <&pioE 6 1>; - }; - }; diff --git a/Documentation/devicetree/bindings/net/mdio-mux.yaml b/Documentation/devicetree/bindings/net/mdio-mux.yaml index d169adf5d9f4..4321c87de86f 100644 --- a/Documentation/devicetree/bindings/net/mdio-mux.yaml +++ b/Documentation/devicetree/bindings/net/mdio-mux.yaml @@ -15,9 +15,6 @@ description: |+ bus multiplexer/switch will have one child node for each child bus. properties: - $nodename: - pattern: '^mdio-mux[\-@]?' - mdio-parent-bus: $ref: /schemas/types.yaml#/definitions/phandle description: @@ -32,12 +29,12 @@ properties: patternProperties: '^mdio@[0-9a-f]+$': - type: object + $ref: mdio.yaml# + unevaluatedProperties: false properties: reg: maxItems: 1 - description: The sub-bus number. additionalProperties: true diff --git a/Documentation/devicetree/bindings/net/mdio.yaml b/Documentation/devicetree/bindings/net/mdio.yaml index 08e15fb1584f..b5706d4e7e38 100644 --- a/Documentation/devicetree/bindings/net/mdio.yaml +++ b/Documentation/devicetree/bindings/net/mdio.yaml @@ -59,7 +59,7 @@ properties: type: boolean patternProperties: - "^ethernet-phy@[0-9a-f]+$": + '@[0-9a-f]+$': type: object properties: @@ -76,12 +76,6 @@ patternProperties: the turn around line low at end of the control phase of the MDIO transaction. - resets: - maxItems: 1 - - reset-names: - const: phy - reset-gpios: maxItems: 1 description: diff --git a/Documentation/devicetree/bindings/net/mediatek,star-emac.yaml b/Documentation/devicetree/bindings/net/mediatek,star-emac.yaml index e6a5ff208253..def994c9cbb4 100644 --- a/Documentation/devicetree/bindings/net/mediatek,star-emac.yaml +++ b/Documentation/devicetree/bindings/net/mediatek,star-emac.yaml @@ -48,9 +48,8 @@ properties: to control the MII mode. mdio: - type: object - description: - Creates and registers an MDIO bus. + $ref: mdio.yaml# + unevaluatedProperties: false required: - compatible diff --git a/Documentation/devicetree/bindings/net/microchip,lan966x-switch.yaml b/Documentation/devicetree/bindings/net/microchip,lan966x-switch.yaml new file mode 100644 index 000000000000..e79e4e166ad8 --- /dev/null +++ b/Documentation/devicetree/bindings/net/microchip,lan966x-switch.yaml @@ -0,0 +1,169 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/net/microchip,lan966x-switch.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Microchip Lan966x Ethernet switch controller + +maintainers: + - Horatiu Vultur <horatiu.vultur@microchip.com> + +description: | + The lan966x switch is a multi-port Gigabit AVB/TSN Ethernet Switch with + two integrated 10/100/1000Base-T PHYs. In addition to the integrated PHYs, + it supports up to 2RGMII/RMII, up to 3BASE-X/SERDES/2.5GBASE-X and up to + 2 Quad-SGMII/Quad-USGMII interfaces. + +properties: + $nodename: + pattern: "^switch@[0-9a-f]+$" + + compatible: + const: microchip,lan966x-switch + + reg: + items: + - description: cpu target + - description: general control block target + + reg-names: + items: + - const: cpu + - const: gcb + + interrupts: + minItems: 1 + items: + - description: register based extraction + - description: frame dma based extraction + - description: analyzer interrupt + + interrupt-names: + minItems: 1 + items: + - const: xtr + - const: fdma + - const: ana + + resets: + items: + - description: Reset controller used for switch core reset (soft reset) + - description: Reset controller used for releasing the phy from reset + + reset-names: + items: + - const: switch + - const: phy + + ethernet-ports: + type: object + + properties: + '#address-cells': + const: 1 + '#size-cells': + const: 0 + + additionalProperties: false + + patternProperties: + "^port@[0-9a-f]+$": + type: object + + $ref: "/schemas/net/ethernet-controller.yaml#" + unevaluatedProperties: false + + properties: + '#address-cells': + const: 1 + '#size-cells': + const: 0 + + reg: + description: + Switch port number + + phys: + description: + Phandle of a Ethernet SerDes PHY + + phy-mode: + description: + This specifies the interface used by the Ethernet SerDes towards + the PHY or SFP. + enum: + - gmii + - sgmii + - qsgmii + - 1000base-x + - 2500base-x + + phy-handle: + description: + Phandle of a Ethernet PHY. + + sfp: + description: + Phandle of an SFP. + + managed: true + + required: + - reg + - phys + - phy-mode + + oneOf: + - required: + - phy-handle + - required: + - sfp + - managed + +required: + - compatible + - reg + - reg-names + - interrupts + - interrupt-names + - resets + - reset-names + - ethernet-ports + +additionalProperties: false + +examples: + - | + #include <dt-bindings/interrupt-controller/arm-gic.h> + switch: switch@e0000000 { + compatible = "microchip,lan966x-switch"; + reg = <0xe0000000 0x0100000>, + <0xe2000000 0x0800000>; + reg-names = "cpu", "gcb"; + interrupts = <GIC_SPI 30 IRQ_TYPE_LEVEL_HIGH>; + interrupt-names = "xtr"; + resets = <&switch_reset 0>, <&phy_reset 0>; + reset-names = "switch", "phy"; + ethernet-ports { + #address-cells = <1>; + #size-cells = <0>; + + port0: port@0 { + reg = <0>; + phy-handle = <&phy0>; + phys = <&serdes 0 0>; + phy-mode = "gmii"; + }; + + port1: port@1 { + reg = <1>; + sfp = <&sfp_eth1>; + managed = "in-band-status"; + phys = <&serdes 2 4>; + phy-mode = "sgmii"; + }; + }; + }; + +... diff --git a/Documentation/devicetree/bindings/net/oxnas-dwmac.txt b/Documentation/devicetree/bindings/net/oxnas-dwmac.txt index d7117a22fd87..27db496f1ce8 100644 --- a/Documentation/devicetree/bindings/net/oxnas-dwmac.txt +++ b/Documentation/devicetree/bindings/net/oxnas-dwmac.txt @@ -9,6 +9,9 @@ Required properties on all platforms: - compatible: For the OX820 SoC, it should be : - "oxsemi,ox820-dwmac" to select glue - "snps,dwmac-3.512" to select IP version. + For the OX810SE SoC, it should be : + - "oxsemi,ox810se-dwmac" to select glue + - "snps,dwmac-3.512" to select IP version. - clocks: Should contain phandles to the following clocks - clock-names: Should contain the following: diff --git a/Documentation/devicetree/bindings/net/qca,ar71xx.yaml b/Documentation/devicetree/bindings/net/qca,ar71xx.yaml index cf4d35edaa1b..1ebf9e8c8a1d 100644 --- a/Documentation/devicetree/bindings/net/qca,ar71xx.yaml +++ b/Documentation/devicetree/bindings/net/qca,ar71xx.yaml @@ -34,14 +34,6 @@ properties: interrupts: maxItems: 1 - '#address-cells': - description: number of address cells for the MDIO bus - const: 1 - - '#size-cells': - description: number of size cells on the MDIO bus - const: 0 - clocks: items: - description: MAC main clock @@ -62,6 +54,10 @@ properties: - const: mac - const: mdio + mdio: + $ref: mdio.yaml# + unevaluatedProperties: false + required: - compatible - reg @@ -85,7 +81,6 @@ examples: reset-names = "mac", "mdio"; clocks = <&pll 1>, <&pll 2>; clock-names = "eth", "mdio"; - qca,ethcfg = <ðcfg>; phy-mode = "mii"; phy-handle = <&phy_port4>; }; @@ -111,9 +106,6 @@ examples: #size-cells = <0>; switch10: switch@10 { - #address-cells = <1>; - #size-cells = <0>; - compatible = "qca,ar9331-switch"; reg = <0x10>; resets = <&rst 8>; diff --git a/Documentation/devicetree/bindings/net/qcom,bam-dmux.yaml b/Documentation/devicetree/bindings/net/qcom,bam-dmux.yaml new file mode 100644 index 000000000000..b30544410d09 --- /dev/null +++ b/Documentation/devicetree/bindings/net/qcom,bam-dmux.yaml @@ -0,0 +1,92 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/net/qcom,bam-dmux.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Qualcomm BAM Data Multiplexer + +maintainers: + - Stephan Gerhold <stephan@gerhold.net> + +description: | + The BAM Data Multiplexer provides access to the network data channels + of modems integrated into many older Qualcomm SoCs, e.g. Qualcomm MSM8916 + or MSM8974. It is built using a simple protocol layer on top of a DMA engine + (Qualcomm BAM DMA) and bidirectional interrupts to coordinate power control. + + Note that this schema does not directly describe a hardware block but rather + a firmware convention that combines several other hardware blocks (such as the + DMA engine). As such it is specific to a firmware version, not a particular + SoC or hardware version. + +properties: + compatible: + const: qcom,bam-dmux + + interrupts: + description: + Interrupts used by the modem to signal the AP. + Both interrupts must be declared as IRQ_TYPE_EDGE_BOTH. + items: + - description: Power control + - description: Power control acknowledgment + + interrupt-names: + items: + - const: pc + - const: pc-ack + + qcom,smem-states: + $ref: /schemas/types.yaml#/definitions/phandle-array + description: State bits used by the AP to signal the modem. + items: + - description: Power control + - description: Power control acknowledgment + + qcom,smem-state-names: + description: Names for the state bits used by the AP to signal the modem. + items: + - const: pc + - const: pc-ack + + dmas: + items: + - description: TX DMA channel phandle + - description: RX DMA channel phandle + + dma-names: + items: + - const: tx + - const: rx + +required: + - compatible + - interrupts + - interrupt-names + - qcom,smem-states + - qcom,smem-state-names + - dmas + - dma-names + +additionalProperties: false + +examples: + - | + #include <dt-bindings/interrupt-controller/irq.h> + + mpss: remoteproc { + bam-dmux { + compatible = "qcom,bam-dmux"; + + interrupt-parent = <&modem_smsm>; + interrupts = <1 IRQ_TYPE_EDGE_BOTH>, <11 IRQ_TYPE_EDGE_BOTH>; + interrupt-names = "pc", "pc-ack"; + + qcom,smem-states = <&apps_smsm 1>, <&apps_smsm 11>; + qcom,smem-state-names = "pc", "pc-ack"; + + dmas = <&bam_dmux_dma 4>, <&bam_dmux_dma 5>; + dma-names = "tx", "rx"; + }; + }; diff --git a/Documentation/devicetree/bindings/net/snps,dwmac.yaml b/Documentation/devicetree/bindings/net/snps,dwmac.yaml index 7ae70dc27f78..7eb43707e601 100644 --- a/Documentation/devicetree/bindings/net/snps,dwmac.yaml +++ b/Documentation/devicetree/bindings/net/snps,dwmac.yaml @@ -286,7 +286,8 @@ properties: MAC2MAC connection. mdio: - type: object + $ref: mdio.yaml# + unevaluatedProperties: false description: Creates and registers an MDIO bus. @@ -326,6 +327,9 @@ allOf: - ingenic,x1600-mac - ingenic,x1830-mac - ingenic,x2000-mac + - snps,dwmac-3.50a + - snps,dwmac-4.10a + - snps,dwmac-4.20a - snps,dwxgmac - snps,dwxgmac-2.10 - st,spear600-gmac diff --git a/Documentation/devicetree/bindings/net/socionext,uniphier-ave4.yaml b/Documentation/devicetree/bindings/net/socionext,uniphier-ave4.yaml index 6bc61c42418f..aad5a9f3f962 100644 --- a/Documentation/devicetree/bindings/net/socionext,uniphier-ave4.yaml +++ b/Documentation/devicetree/bindings/net/socionext,uniphier-ave4.yaml @@ -72,6 +72,7 @@ properties: mdio: $ref: mdio.yaml# + unevaluatedProperties: false required: - compatible diff --git a/Documentation/devicetree/bindings/net/stm32-dwmac.yaml b/Documentation/devicetree/bindings/net/stm32-dwmac.yaml index 577f4e284425..3d8a3b763ae6 100644 --- a/Documentation/devicetree/bindings/net/stm32-dwmac.yaml +++ b/Documentation/devicetree/bindings/net/stm32-dwmac.yaml @@ -44,6 +44,12 @@ properties: - st,stm32-dwmac - const: snps,dwmac-3.50a + reg: true + + reg-names: + items: + - const: stmmaceth + clocks: minItems: 3 items: @@ -102,7 +108,7 @@ examples: compatible = "st,stm32mp1-dwmac", "snps,dwmac-4.20a"; reg = <0x5800a000 0x2000>; reg-names = "stmmaceth"; - interrupts = <&intc GIC_SPI 61 IRQ_TYPE_LEVEL_HIGH>; + interrupts = <GIC_SPI 61 IRQ_TYPE_LEVEL_HIGH>; interrupt-names = "macirq"; clock-names = "stmmaceth", "mac-clk-tx", @@ -121,6 +127,7 @@ examples: phy-mode = "rgmii"; }; + - | //Example 2 (MCU example) ethernet1: ethernet@40028000 { compatible = "st,stm32-dwmac", "snps,dwmac-3.50a"; @@ -136,6 +143,7 @@ examples: phy-mode = "mii"; }; + - | //Example 3 ethernet2: ethernet@40027000 { compatible = "st,stm32-dwmac", "snps,dwmac-4.10a"; diff --git a/Documentation/devicetree/bindings/net/ti,davinci-mdio.yaml b/Documentation/devicetree/bindings/net/ti,davinci-mdio.yaml index 5728fe23f530..dbfca5ee9139 100644 --- a/Documentation/devicetree/bindings/net/ti,davinci-mdio.yaml +++ b/Documentation/devicetree/bindings/net/ti,davinci-mdio.yaml @@ -37,6 +37,13 @@ properties: maximum: 2500000 description: MDIO Bus frequency + clocks: + maxItems: 1 + + clock-names: + items: + - const: fck + ti,hwmods: description: TI hwmod name deprecated: true diff --git a/Documentation/devicetree/bindings/net/ti,dp83869.yaml b/Documentation/devicetree/bindings/net/ti,dp83869.yaml index 70a1209cb13b..1b780dce61ab 100644 --- a/Documentation/devicetree/bindings/net/ti,dp83869.yaml +++ b/Documentation/devicetree/bindings/net/ti,dp83869.yaml @@ -92,7 +92,7 @@ examples: tx-fifo-depth = <DP83869_PHYCR_FIFO_DEPTH_4_B_NIB>; rx-fifo-depth = <DP83869_PHYCR_FIFO_DEPTH_4_B_NIB>; ti,op-mode = <DP83869_RGMII_COPPER_ETHERNET>; - ti,max-output-impedance = "true"; + ti,max-output-impedance; ti,clk-output-sel = <DP83869_CLK_O_SEL_CHN_A_RCLK>; rx-internal-delay-ps = <2000>; tx-internal-delay-ps = <2000>; diff --git a/Documentation/devicetree/bindings/net/toshiba,visconti-dwmac.yaml b/Documentation/devicetree/bindings/net/toshiba,visconti-dwmac.yaml index 59724d18e6f3..b12bfe61c67a 100644 --- a/Documentation/devicetree/bindings/net/toshiba,visconti-dwmac.yaml +++ b/Documentation/devicetree/bindings/net/toshiba,visconti-dwmac.yaml @@ -71,7 +71,7 @@ examples: phy-mode = "rgmii-id"; phy-handle = <&phy0>; - mdio0 { + mdio { #address-cells = <0x1>; #size-cells = <0x0>; compatible = "snps,dwmac-mdio"; diff --git a/Documentation/devicetree/bindings/net/vertexcom-mse102x.yaml b/Documentation/devicetree/bindings/net/vertexcom-mse102x.yaml new file mode 100644 index 000000000000..8156a9aeb589 --- /dev/null +++ b/Documentation/devicetree/bindings/net/vertexcom-mse102x.yaml @@ -0,0 +1,71 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: "http://devicetree.org/schemas/net/vertexcom-mse102x.yaml#" +$schema: "http://devicetree.org/meta-schemas/core.yaml#" + +title: The Vertexcom MSE102x (SPI) Device Tree Bindings + +maintainers: + - Stefan Wahren <stefan.wahren@in-tech.com> + +description: + Vertexcom's MSE102x are a family of HomePlug GreenPHY chips. + They can be connected either via RGMII, RMII or SPI to a host CPU. + + In order to use a MSE102x chip as SPI device, it must be defined as + a child of an SPI master device in the device tree. + + More information can be found at + http://www.vertexcom.com/doc/MSE1022%20Product%20Brief.pdf + +allOf: + - $ref: ethernet-controller.yaml# + +properties: + compatible: + enum: + - vertexcom,mse1021 + - vertexcom,mse1022 + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + spi-cpha: true + + spi-cpol: true + + spi-max-frequency: + minimum: 6000000 + maximum: 7142857 + +required: + - compatible + - reg + - interrupts + - spi-cpha + - spi-cpol + - spi-max-frequency + +additionalProperties: false + +examples: + - | + #include <dt-bindings/interrupt-controller/irq.h> + spi0 { + #address-cells = <1>; + #size-cells = <0>; + + ethernet@0 { + compatible = "vertexcom,mse1021"; + reg = <0>; + interrupt-parent = <&gpio>; + interrupts = <23 IRQ_TYPE_EDGE_RISING>; + spi-cpha; + spi-cpol; + spi-max-frequency = <7142857>; + }; + }; diff --git a/Documentation/devicetree/bindings/net/wireless/mediatek,mt76.yaml b/Documentation/devicetree/bindings/net/wireless/mediatek,mt76.yaml index 1489d3c1cd6e..269cd63fb544 100644 --- a/Documentation/devicetree/bindings/net/wireless/mediatek,mt76.yaml +++ b/Documentation/devicetree/bindings/net/wireless/mediatek,mt76.yaml @@ -191,9 +191,9 @@ examples: channels = <36 48>; rates-ofdm = /bits/ 8 <23 23 23 23 23 23 23 23>; rates-mcs = /bits/ 8 <1 23 23 23 23 23 23 23 23 23 23>, - <3 22 22 22 22 22 22 22 22 22 22>; + /bits/ 8 <3 22 22 22 22 22 22 22 22 22 22>; rates-ru = /bits/ 8 <3 22 22 22 22 22 22 22 22 22 22 22 22>, - <4 20 20 20 20 20 20 20 20 20 20 20 20>; + /bits/ 8 <4 20 20 20 20 20 20 20 20 20 20 20 20>; }; b1 { channels = <100 181>; diff --git a/Documentation/devicetree/bindings/net/wireless/microchip,wilc1000.yaml b/Documentation/devicetree/bindings/net/wireless/microchip,wilc1000.yaml index 6c35682377e6..60de78f1bc7b 100644 --- a/Documentation/devicetree/bindings/net/wireless/microchip,wilc1000.yaml +++ b/Documentation/devicetree/bindings/net/wireless/microchip,wilc1000.yaml @@ -32,6 +32,21 @@ properties: clock-names: const: rtc + enable-gpios: + maxItems: 1 + description: Used by wilc1000-spi to determine the GPIO line + connected to the ENABLE line. If specified, reset-gpios + must be specified as well as otherwise the driver cannot + ensure the timing required between asserting ENABLE + and deasserting RESET. This should be declared as an + active-high signal. + + reset-gpios: + maxItems: 1 + description: Used by wilc1000-spi to determine the GPIO line + connected to the RESET line. This should be declared as an + active-low signal. + required: - compatible - interrupts @@ -40,6 +55,8 @@ additionalProperties: false examples: - | + #include <dt-bindings/gpio/gpio.h> + spi { #address-cells = <1>; #size-cells = <0>; @@ -51,6 +68,8 @@ examples: interrupts = <27 0>; clocks = <&pck1>; clock-names = "rtc"; + enable-gpios = <&pioA 5 GPIO_ACTIVE_HIGH>; + reset-gpios = <&pioA 6 GPIO_ACTIVE_LOW>; }; }; diff --git a/Documentation/devicetree/bindings/net/wireless/qcom,ath11k.yaml b/Documentation/devicetree/bindings/net/wireless/qcom,ath11k.yaml index 85c2f699d602..cdf7b873b419 100644 --- a/Documentation/devicetree/bindings/net/wireless/qcom,ath11k.yaml +++ b/Documentation/devicetree/bindings/net/wireless/qcom,ath11k.yaml @@ -150,6 +150,12 @@ properties: string to uniquely identify variant of the calibration data in the board-2.bin for designs with colliding bus and device specific ids + memory-region: + maxItems: 1 + description: + phandle to a node describing reserved memory (System RAM memory) + used by ath11k firmware (see bindings/reserved-memory/reserved-memory.txt) + required: - compatible - reg @@ -279,3 +285,27 @@ examples: "tcl2host-status-ring"; qcom,rproc = <&q6v5_wcss>; }; + + - | + + reserved-memory { + #address-cells = <2>; + #size-cells = <2>; + + qcn9074_0: qcn9074_0@51100000 { + no-map; + reg = <0x0 0x51100000 0x0 0x03500000>; + }; + }; + + pci { + pcie0 { + #size-cells = <2>; + #address-cells = <3>; + + wifi_0: wifi@0 { + reg = <0 0 0 0 0>; + memory-region = <&qcn9074_0>; + }; + }; + }; diff --git a/Documentation/devicetree/bindings/nvmem/brcm,nvram.yaml b/Documentation/devicetree/bindings/nvmem/brcm,nvram.yaml index 58ff6b0bdb1a..8c3f0cd22821 100644 --- a/Documentation/devicetree/bindings/nvmem/brcm,nvram.yaml +++ b/Documentation/devicetree/bindings/nvmem/brcm,nvram.yaml @@ -24,6 +24,9 @@ properties: compatible: const: brcm,nvram + reg: + maxItems: 1 + unevaluatedProperties: false examples: diff --git a/Documentation/devicetree/bindings/nvmem/mtk-efuse.txt b/Documentation/devicetree/bindings/nvmem/mtk-efuse.txt index b6791702bcfc..39d529599444 100644 --- a/Documentation/devicetree/bindings/nvmem/mtk-efuse.txt +++ b/Documentation/devicetree/bindings/nvmem/mtk-efuse.txt @@ -8,8 +8,10 @@ Required properties: "mediatek,mt7623-efuse", "mediatek,efuse": for MT7623 "mediatek,mt8173-efuse" or "mediatek,efuse": for MT8173 "mediatek,mt8192-efuse", "mediatek,efuse": for MT8192 + "mediatek,mt8195-efuse", "mediatek,efuse": for MT8195 "mediatek,mt8516-efuse", "mediatek,efuse": for MT8516 - reg: Should contain registers location and length +- bits: contain the bits range by offset and size = Data cells = Are child nodes of MTK-EFUSE, bindings of which as described in diff --git a/Documentation/devicetree/bindings/nvmem/nvmem.yaml b/Documentation/devicetree/bindings/nvmem/nvmem.yaml index 456fb808100a..43ed7e32e5ac 100644 --- a/Documentation/devicetree/bindings/nvmem/nvmem.yaml +++ b/Documentation/devicetree/bindings/nvmem/nvmem.yaml @@ -50,16 +50,15 @@ patternProperties: Offset and size in bytes within the storage device. bits: - maxItems: 1 + $ref: /schemas/types.yaml#/definitions/uint32-array items: - items: - - minimum: 0 - maximum: 7 - description: - Offset in bit within the address range specified by reg. - - minimum: 1 - description: - Size in bit within the address range specified by reg. + - minimum: 0 + maximum: 7 + description: + Offset in bit within the address range specified by reg. + - minimum: 1 + description: + Size in bit within the address range specified by reg. required: - reg diff --git a/Documentation/devicetree/bindings/nvmem/rmem.yaml b/Documentation/devicetree/bindings/nvmem/rmem.yaml index 1d85a0a30846..a4a755dcfc43 100644 --- a/Documentation/devicetree/bindings/nvmem/rmem.yaml +++ b/Documentation/devicetree/bindings/nvmem/rmem.yaml @@ -19,6 +19,9 @@ properties: - raspberrypi,bootloader-config - const: nvmem-rmem + reg: + maxItems: 1 + no-map: $ref: /schemas/types.yaml#/definitions/flag description: diff --git a/Documentation/devicetree/bindings/nvmem/st,stm32-romem.yaml b/Documentation/devicetree/bindings/nvmem/st,stm32-romem.yaml index a48c8fa56bce..448a2678dc62 100644 --- a/Documentation/devicetree/bindings/nvmem/st,stm32-romem.yaml +++ b/Documentation/devicetree/bindings/nvmem/st,stm32-romem.yaml @@ -24,6 +24,9 @@ properties: - st,stm32f4-otp - st,stm32mp15-bsec + reg: + maxItems: 1 + patternProperties: "^.*@[0-9a-f]+$": type: object diff --git a/Documentation/devicetree/bindings/pci/apple,pcie.yaml b/Documentation/devicetree/bindings/pci/apple,pcie.yaml index ef1d424ec299..7f01e15fc81c 100644 --- a/Documentation/devicetree/bindings/pci/apple,pcie.yaml +++ b/Documentation/devicetree/bindings/pci/apple,pcie.yaml @@ -28,19 +28,17 @@ description: | distributed over the root ports as the OS sees fit by programming the PCIe controller's port registers. -allOf: - - $ref: /schemas/pci/pci-bus.yaml# - - $ref: /schemas/interrupt-controller/msi-controller.yaml# - properties: compatible: items: - - const: apple,t8103-pcie + - enum: + - apple,t8103-pcie + - apple,t6000-pcie - const: apple,pcie reg: minItems: 3 - maxItems: 5 + maxItems: 6 reg-names: minItems: 3 @@ -50,6 +48,7 @@ properties: - const: port0 - const: port1 - const: port2 + - const: port3 ranges: minItems: 2 @@ -59,7 +58,7 @@ properties: description: Interrupt specifiers, one for each root port. minItems: 1 - maxItems: 3 + maxItems: 4 msi-parent: true @@ -81,6 +80,21 @@ required: unevaluatedProperties: false +allOf: + - $ref: /schemas/pci/pci-bus.yaml# + - $ref: /schemas/interrupt-controller/msi-controller.yaml# + - if: + properties: + compatible: + contains: + const: apple,t8103-pcie + then: + properties: + reg: + maxItems: 5 + interrupts: + maxItems: 3 + examples: - | #include <dt-bindings/interrupt-controller/apple-aic.h> diff --git a/Documentation/devicetree/bindings/pci/brcm,iproc-pcie.txt b/Documentation/devicetree/bindings/pci/brcm,iproc-pcie.txt deleted file mode 100644 index df065aa53a83..000000000000 --- a/Documentation/devicetree/bindings/pci/brcm,iproc-pcie.txt +++ /dev/null @@ -1,133 +0,0 @@ -* Broadcom iProc PCIe controller with the platform bus interface - -Required properties: -- compatible: - "brcm,iproc-pcie" for the first generation of PAXB based controller, -used in SoCs including NSP, Cygnus, NS2, and Pegasus - "brcm,iproc-pcie-paxb-v2" for the second generation of PAXB-based -controllers, used in Stingray - "brcm,iproc-pcie-paxc" for the first generation of PAXC based -controller, used in NS2 - "brcm,iproc-pcie-paxc-v2" for the second generation of PAXC based -controller, used in Stingray - PAXB-based root complex is used for external endpoint devices. PAXC-based -root complex is connected to emulated endpoint devices internal to the ASIC -- reg: base address and length of the PCIe controller I/O register space -- #interrupt-cells: set to <1> -- interrupt-map-mask and interrupt-map, standard PCI properties to define the - mapping of the PCIe interface to interrupt numbers -- linux,pci-domain: PCI domain ID. Should be unique for each host controller -- bus-range: PCI bus numbers covered -- #address-cells: set to <3> -- #size-cells: set to <2> -- device_type: set to "pci" -- ranges: ranges for the PCI memory and I/O regions - -Optional properties: -- phys: phandle of the PCIe PHY device -- phy-names: must be "pcie-phy" -- dma-coherent: present if DMA operations are coherent -- dma-ranges: Some PAXB-based root complexes do not have inbound mapping done - by the ASIC after power on reset. In this case, SW is required to configure -the mapping, based on inbound memory regions specified by this property. - -- brcm,pcie-ob: Some iProc SoCs do not have the outbound address mapping done -by the ASIC after power on reset. In this case, SW needs to configure it - -If the brcm,pcie-ob property is present, the following properties become -effective: - -Required: -- brcm,pcie-ob-axi-offset: The offset from the AXI address to the internal -address used by the iProc PCIe core (not the PCIe address) - -MSI support (optional): - -For older platforms without MSI integrated in the GIC, iProc PCIe core provides -an event queue based MSI support. The iProc MSI uses host memories to store -MSI posted writes in the event queues - -On newer iProc platforms, gicv2m or gicv3-its based MSI support should be used - -- msi-map: Maps a Requester ID to an MSI controller and associated MSI -sideband data - -- msi-parent: Link to the device node of the MSI controller, used when no MSI -sideband data is passed between the iProc PCIe controller and the MSI -controller - -Refer to the following binding documents for more detailed description on -the use of 'msi-map' and 'msi-parent': - Documentation/devicetree/bindings/pci/pci-msi.txt - Documentation/devicetree/bindings/interrupt-controller/msi.txt - -When the iProc event queue based MSI is used, one needs to define the -following properties in the MSI device node: -- compatible: Must be "brcm,iproc-msi" -- msi-controller: claims itself as an MSI controller -- interrupts: List of interrupt IDs from its parent interrupt device - -Optional properties: -- brcm,pcie-msi-inten: Needs to be present for some older iProc platforms that -require the interrupt enable registers to be set explicitly to enable MSI - -Example: - pcie0: pcie@18012000 { - compatible = "brcm,iproc-pcie"; - reg = <0x18012000 0x1000>; - - #interrupt-cells = <1>; - interrupt-map-mask = <0 0 0 0>; - interrupt-map = <0 0 0 0 &gic GIC_SPI 100 IRQ_TYPE_NONE>; - - linux,pci-domain = <0>; - - bus-range = <0x00 0xff>; - - #address-cells = <3>; - #size-cells = <2>; - device_type = "pci"; - ranges = <0x81000000 0 0 0x28000000 0 0x00010000 - 0x82000000 0 0x20000000 0x20000000 0 0x04000000>; - - phys = <&phy 0 5>; - phy-names = "pcie-phy"; - - brcm,pcie-ob; - brcm,pcie-ob-axi-offset = <0x00000000>; - - msi-parent = <&msi0>; - - /* iProc event queue based MSI */ - msi0: msi@18012000 { - compatible = "brcm,iproc-msi"; - msi-controller; - interrupt-parent = <&gic>; - interrupts = <GIC_SPI 96 IRQ_TYPE_NONE>, - <GIC_SPI 97 IRQ_TYPE_NONE>, - <GIC_SPI 98 IRQ_TYPE_NONE>, - <GIC_SPI 99 IRQ_TYPE_NONE>, - }; - }; - - pcie1: pcie@18013000 { - compatible = "brcm,iproc-pcie"; - reg = <0x18013000 0x1000>; - - #interrupt-cells = <1>; - interrupt-map-mask = <0 0 0 0>; - interrupt-map = <0 0 0 0 &gic GIC_SPI 106 IRQ_TYPE_NONE>; - - linux,pci-domain = <1>; - - bus-range = <0x00 0xff>; - - #address-cells = <3>; - #size-cells = <2>; - device_type = "pci"; - ranges = <0x81000000 0 0 0x48000000 0 0x00010000 - 0x82000000 0 0x40000000 0x40000000 0 0x04000000>; - - phys = <&phy 1 6>; - phy-names = "pcie-phy"; - }; diff --git a/Documentation/devicetree/bindings/pci/brcm,iproc-pcie.yaml b/Documentation/devicetree/bindings/pci/brcm,iproc-pcie.yaml new file mode 100644 index 000000000000..0972868735fc --- /dev/null +++ b/Documentation/devicetree/bindings/pci/brcm,iproc-pcie.yaml @@ -0,0 +1,184 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/pci/brcm,iproc-pcie.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Broadcom iProc PCIe controller with the platform bus interface + +maintainers: + - Ray Jui <ray.jui@broadcom.com> + - Scott Branden <scott.branden@broadcom.com> + +allOf: + - $ref: /schemas/pci/pci-bus.yaml# + - $ref: /schemas/interrupt-controller/msi-controller.yaml# + +properties: + compatible: + items: + - enum: + # for the first generation of PAXB based controller, used in SoCs + # including NSP, Cygnus, NS2, and Pegasus + - brcm,iproc-pcie + # for the second generation of PAXB-based controllers, used in + # Stingray + - brcm,iproc-pcie-paxb-v2 + # For the first generation of PAXC based controller, used in NS2 + - brcm,iproc-pcie-paxc + # For the second generation of PAXC based controller, used in Stingray + - brcm,iproc-pcie-paxc-v2 + + reg: + maxItems: 1 + description: > + Base address and length of the PCIe controller I/O register space + + interrupt-map: true + + interrupt-map-mask: true + + "#interrupt-cells": + const: 1 + + ranges: + minItems: 1 + maxItems: 2 + description: > + Ranges for the PCI memory and I/O regions + + phys: + maxItems: 1 + + phy-names: + items: + - const: pcie-phy + + bus-range: true + + dma-coherent: true + + "#address-cells": true + + "#size-cells": true + + device_type: true + + brcm,pcie-ob: + type: boolean + description: > + Some iProc SoCs do not have the outbound address mapping done by the + ASIC after power on reset. In this case, SW needs to configure it + + brcm,pcie-ob-axi-offset: + $ref: /schemas/types.yaml#/definitions/uint32 + description: > + The offset from the AXI address to the internal address used by the + iProc PCIe core (not the PCIe address) + + msi: + type: object + properties: + compatible: + items: + - const: brcm,iproc-msi + + msi-parent: true + + msi-controller: true + + brcm,pcie-msi-inten: + type: boolean + description: > + Needs to be present for some older iProc platforms that require the + interrupt enable registers to be set explicitly to enable MSI + +dependencies: + brcm,pcie-ob-axi-offset: ["brcm,pcie-ob"] + brcm,pcie-msi-inten: [msi-controller] + +required: + - compatible + - reg + - ranges + +if: + properties: + compatible: + contains: + enum: + - brcm,iproc-pcie +then: + required: + - interrupt-map + - interrupt-map-mask + +unevaluatedProperties: false + +examples: + - | + #include <dt-bindings/interrupt-controller/arm-gic.h> + + bus { + #address-cells = <1>; + #size-cells = <1>; + pcie0: pcie@18012000 { + compatible = "brcm,iproc-pcie"; + reg = <0x18012000 0x1000>; + + #interrupt-cells = <1>; + interrupt-map-mask = <0 0 0 0>; + interrupt-map = <0 0 0 0 &gic GIC_SPI 100 IRQ_TYPE_NONE>; + + linux,pci-domain = <0>; + + bus-range = <0x00 0xff>; + + #address-cells = <3>; + #size-cells = <2>; + device_type = "pci"; + ranges = <0x81000000 0 0 0x28000000 0 0x00010000>, + <0x82000000 0 0x20000000 0x20000000 0 0x04000000>; + + phys = <&phy 0 5>; + phy-names = "pcie-phy"; + + brcm,pcie-ob; + brcm,pcie-ob-axi-offset = <0x00000000>; + + msi-parent = <&msi0>; + + /* iProc event queue based MSI */ + msi0: msi { + compatible = "brcm,iproc-msi"; + msi-controller; + interrupt-parent = <&gic>; + interrupts = <GIC_SPI 96 IRQ_TYPE_NONE>, + <GIC_SPI 97 IRQ_TYPE_NONE>, + <GIC_SPI 98 IRQ_TYPE_NONE>, + <GIC_SPI 99 IRQ_TYPE_NONE>; + }; + }; + + pcie1: pcie@18013000 { + compatible = "brcm,iproc-pcie"; + reg = <0x18013000 0x1000>; + + #interrupt-cells = <1>; + interrupt-map-mask = <0 0 0 0>; + interrupt-map = <0 0 0 0 &gic GIC_SPI 106 IRQ_TYPE_NONE>; + + linux,pci-domain = <1>; + + bus-range = <0x00 0xff>; + + #address-cells = <3>; + #size-cells = <2>; + device_type = "pci"; + ranges = <0x81000000 0 0 0x48000000 0 0x00010000>, + <0x82000000 0 0x40000000 0x40000000 0 0x04000000>; + + phys = <&phy 1 6>; + phy-names = "pcie-phy"; + }; + }; diff --git a/Documentation/devicetree/bindings/pci/brcm,stb-pcie.yaml b/Documentation/devicetree/bindings/pci/brcm,stb-pcie.yaml index 1fe102743f82..0f064e4222f3 100644 --- a/Documentation/devicetree/bindings/pci/brcm,stb-pcie.yaml +++ b/Documentation/devicetree/bindings/pci/brcm,stb-pcie.yaml @@ -19,6 +19,8 @@ properties: - brcm,bcm7278-pcie # Broadcom 7278 Arm - brcm,bcm7216-pcie # Broadcom 7216 Arm - brcm,bcm7445-pcie # Broadcom 7445 Arm + - brcm,bcm7425-pcie # Broadcom 7425 MIPs + - brcm,bcm7435-pcie # Broadcom 7435 MIPs reg: maxItems: 1 @@ -76,6 +78,7 @@ properties: maxItems: 3 required: + - compatible - reg - ranges - dma-ranges @@ -143,11 +146,15 @@ examples: #address-cells = <3>; #size-cells = <2>; #interrupt-cells = <1>; - interrupts = <GIC_SPI 148 IRQ_TYPE_LEVEL_HIGH>, + interrupts = <GIC_SPI 147 IRQ_TYPE_LEVEL_HIGH>, <GIC_SPI 148 IRQ_TYPE_LEVEL_HIGH>; interrupt-names = "pcie", "msi"; interrupt-map-mask = <0x0 0x0 0x0 0x7>; - interrupt-map = <0 0 0 1 &gicv2 GIC_SPI 143 IRQ_TYPE_LEVEL_HIGH>; + interrupt-map = <0 0 0 1 &gicv2 GIC_SPI 143 IRQ_TYPE_LEVEL_HIGH + 0 0 0 2 &gicv2 GIC_SPI 144 IRQ_TYPE_LEVEL_HIGH + 0 0 0 3 &gicv2 GIC_SPI 145 IRQ_TYPE_LEVEL_HIGH + 0 0 0 4 &gicv2 GIC_SPI 146 IRQ_TYPE_LEVEL_HIGH>; + msi-parent = <&pcie0>; msi-controller; ranges = <0x02000000 0x0 0xf8000000 0x6 0x00000000 0x0 0x04000000>; @@ -155,5 +162,24 @@ examples: <0x42000000 0x1 0x80000000 0x3 0x00000000 0x0 0x80000000>; brcm,enable-ssc; brcm,scb-sizes = <0x0000000080000000 0x0000000080000000>; + + /* PCIe bridge, Root Port */ + pci@0,0 { + #address-cells = <3>; + #size-cells = <2>; + reg = <0x0 0x0 0x0 0x0 0x0>; + compatible = "pciclass,0604"; + device_type = "pci"; + vpcie3v3-supply = <&vreg7>; + ranges; + + /* PCIe endpoint */ + pci-ep@0,0 { + assigned-addresses = + <0x82010000 0x0 0xf8000000 0x6 0x00000000 0x0 0x2000>; + reg = <0x0 0x0 0x0 0x0 0x0>; + compatible = "pci14e4,1688"; + }; + }; }; }; diff --git a/Documentation/devicetree/bindings/pci/cdns,cdns-pcie-ep.yaml b/Documentation/devicetree/bindings/pci/cdns,cdns-pcie-ep.yaml index 651eee88989d..e6ef1012a580 100644 --- a/Documentation/devicetree/bindings/pci/cdns,cdns-pcie-ep.yaml +++ b/Documentation/devicetree/bindings/pci/cdns,cdns-pcie-ep.yaml @@ -11,7 +11,6 @@ maintainers: allOf: - $ref: "cdns-pcie-ep.yaml#" - - $ref: "pci-ep.yaml#" properties: compatible: diff --git a/Documentation/devicetree/bindings/pci/cdns-pcie-ep.yaml b/Documentation/devicetree/bindings/pci/cdns-pcie-ep.yaml index 21e8a8849076..baeafda36ebe 100644 --- a/Documentation/devicetree/bindings/pci/cdns-pcie-ep.yaml +++ b/Documentation/devicetree/bindings/pci/cdns-pcie-ep.yaml @@ -11,6 +11,7 @@ maintainers: allOf: - $ref: "cdns-pcie.yaml#" + - $ref: "pci-ep.yaml#" properties: cdns,max-outbound-regions: diff --git a/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.yaml b/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.yaml index acea1cd444fd..643a6333b07b 100644 --- a/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.yaml +++ b/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.yaml @@ -127,6 +127,12 @@ properties: enum: [1, 2, 3, 4] default: 1 + phys: + maxItems: 1 + + phy-names: + const: pcie-phy + reset-gpio: description: Should specify the GPIO for controlling the PCI bus device reset signal. It's not polarity aware and defaults to active-low reset diff --git a/Documentation/devicetree/bindings/pci/hisilicon,kirin-pcie.yaml b/Documentation/devicetree/bindings/pci/hisilicon,kirin-pcie.yaml index cbee87802559..c9f04999c9cf 100644 --- a/Documentation/devicetree/bindings/pci/hisilicon,kirin-pcie.yaml +++ b/Documentation/devicetree/bindings/pci/hisilicon,kirin-pcie.yaml @@ -37,6 +37,19 @@ properties: minItems: 3 maxItems: 4 + clocks: true + + clock-names: + items: + - const: pcie_phy_ref + - const: pcie_aux + - const: pcie_apb_phy + - const: pcie_apb_sys + - const: pcie_aclk + + phys: + maxItems: 1 + hisilicon,clken-gpios: description: | Clock input enablement GPIOs from PCI devices like Ethernet, M.2 and diff --git a/Documentation/devicetree/bindings/pci/mediatek,mt7621-pcie.yaml b/Documentation/devicetree/bindings/pci/mediatek,mt7621-pcie.yaml index 044fa967bc8b..d60f43fd9c5a 100644 --- a/Documentation/devicetree/bindings/pci/mediatek,mt7621-pcie.yaml +++ b/Documentation/devicetree/bindings/pci/mediatek,mt7621-pcie.yaml @@ -45,6 +45,9 @@ patternProperties: phys: maxItems: 1 + phy-names: + pattern: '^pcie-phy[0-2]$' + required: - "#interrupt-cells" - interrupt-map-mask diff --git a/Documentation/devicetree/bindings/pci/mediatek-pcie-gen3.yaml b/Documentation/devicetree/bindings/pci/mediatek-pcie-gen3.yaml index 742206dbd965..0499b94627ae 100644 --- a/Documentation/devicetree/bindings/pci/mediatek-pcie-gen3.yaml +++ b/Documentation/devicetree/bindings/pci/mediatek-pcie-gen3.yaml @@ -95,6 +95,10 @@ properties: phys: maxItems: 1 + phy-names: + items: + - const: pcie-phy + '#interrupt-cells': const: 1 diff --git a/Documentation/devicetree/bindings/pci/microchip,pcie-host.yaml b/Documentation/devicetree/bindings/pci/microchip,pcie-host.yaml index 7b0776457178..edb4f81253c8 100644 --- a/Documentation/devicetree/bindings/pci/microchip,pcie-host.yaml +++ b/Documentation/devicetree/bindings/pci/microchip,pcie-host.yaml @@ -46,6 +46,24 @@ properties: msi-parent: description: MSI controller the device is capable of using. + interrupt-controller: + type: object + properties: + '#address-cells': + const: 0 + + '#interrupt-cells': + const: 1 + + interrupt-controller: true + + required: + - '#address-cells' + - '#interrupt-cells' + - interrupt-controller + + additionalProperties: false + required: - reg - reg-names diff --git a/Documentation/devicetree/bindings/pci/sifive,fu740-pcie.yaml b/Documentation/devicetree/bindings/pci/sifive,fu740-pcie.yaml index 2b9d1d6fc661..392f0ab488c2 100644 --- a/Documentation/devicetree/bindings/pci/sifive,fu740-pcie.yaml +++ b/Documentation/devicetree/bindings/pci/sifive,fu740-pcie.yaml @@ -32,6 +32,8 @@ properties: - const: config - const: mgmt + dma-coherent: true + num-lanes: const: 8 @@ -61,10 +63,8 @@ required: - num-lanes - interrupts - interrupt-names - - interrupt-parent - interrupt-map-mask - interrupt-map - - clock-names - clocks - resets - pwren-gpios @@ -104,7 +104,6 @@ examples: <0x0 0x0 0x0 0x2 &plic0 58>, <0x0 0x0 0x0 0x3 &plic0 59>, <0x0 0x0 0x0 0x4 &plic0 60>; - clock-names = "pcie_aux"; clocks = <&prci PRCI_CLK_PCIE_AUX>; resets = <&prci 4>; pwren-gpios = <&gpio 5 0>; diff --git a/Documentation/devicetree/bindings/pci/snps,dw-pcie-ep.yaml b/Documentation/devicetree/bindings/pci/snps,dw-pcie-ep.yaml index b5935b1b153f..e59059ab5be0 100644 --- a/Documentation/devicetree/bindings/pci/snps,dw-pcie-ep.yaml +++ b/Documentation/devicetree/bindings/pci/snps,dw-pcie-ep.yaml @@ -64,16 +64,12 @@ properties: maxItems: 1 deprecated: true - max-functions: - $ref: /schemas/types.yaml#/definitions/uint32 - description: maximum number of functions that can be configured - required: - reg - reg-names - compatible -unevaluatedProperties: false +additionalProperties: true examples: - | diff --git a/Documentation/devicetree/bindings/pci/snps,dw-pcie.yaml b/Documentation/devicetree/bindings/pci/snps,dw-pcie.yaml index 9ed0dfba7f89..a5345c494744 100644 --- a/Documentation/devicetree/bindings/pci/snps,dw-pcie.yaml +++ b/Documentation/devicetree/bindings/pci/snps,dw-pcie.yaml @@ -73,7 +73,7 @@ properties: does not specify it, the driver autodetects it. deprecated: true -unevaluatedProperties: false +additionalProperties: true required: - reg diff --git a/Documentation/devicetree/bindings/pci/socionext,uniphier-pcie-ep.yaml b/Documentation/devicetree/bindings/pci/socionext,uniphier-pcie-ep.yaml index 144cbcd60a1c..179ab0858482 100644 --- a/Documentation/devicetree/bindings/pci/socionext,uniphier-pcie-ep.yaml +++ b/Documentation/devicetree/bindings/pci/socionext,uniphier-pcie-ep.yaml @@ -79,7 +79,7 @@ required: - resets - reset-names -additionalProperties: false +unevaluatedProperties: false examples: - | diff --git a/Documentation/devicetree/bindings/pci/ti,am65-pci-ep.yaml b/Documentation/devicetree/bindings/pci/ti,am65-pci-ep.yaml index 78c217d362a7..74195c1f5292 100644 --- a/Documentation/devicetree/bindings/pci/ti,am65-pci-ep.yaml +++ b/Documentation/devicetree/bindings/pci/ti,am65-pci-ep.yaml @@ -32,8 +32,12 @@ properties: maxItems: 1 ti,syscon-pcie-mode: + $ref: /schemas/types.yaml#/definitions/phandle-array + items: + - items: + - description: Phandle to the SYSCON entry + - description: pcie_ctrl register offset within SYSCON description: Phandle to the SYSCON entry required for configuring PCIe in RC or EP mode. - $ref: /schemas/types.yaml#/definitions/phandle interrupts: minItems: 1 @@ -65,9 +69,7 @@ examples: <0x5506000 0x1000>; reg-names = "app", "dbics", "addr_space", "atu"; power-domains = <&k3_pds 120 TI_SCI_PD_EXCLUSIVE>; - ti,syscon-pcie-mode = <&pcie0_mode>; - num-ib-windows = <16>; - num-ob-windows = <16>; + ti,syscon-pcie-mode = <&scm_conf 0x4060>; max-link-speed = <2>; dma-coherent; interrupts = <GIC_SPI 340 IRQ_TYPE_EDGE_RISING>; diff --git a/Documentation/devicetree/bindings/pci/ti,am65-pci-host.yaml b/Documentation/devicetree/bindings/pci/ti,am65-pci-host.yaml index 834dc1c1743c..a20dccbafd94 100644 --- a/Documentation/devicetree/bindings/pci/ti,am65-pci-host.yaml +++ b/Documentation/devicetree/bindings/pci/ti,am65-pci-host.yaml @@ -29,16 +29,27 @@ properties: - const: config - const: atu + interrupts: + maxItems: 1 + power-domains: maxItems: 1 ti,syscon-pcie-id: + $ref: /schemas/types.yaml#/definitions/phandle-array + items: + - items: + - description: Phandle to the SYSCON entry + - description: pcie_device_id register offset within SYSCON description: Phandle to the SYSCON entry required for getting PCIe device/vendor ID - $ref: /schemas/types.yaml#/definitions/phandle ti,syscon-pcie-mode: + $ref: /schemas/types.yaml#/definitions/phandle-array + items: + - items: + - description: Phandle to the SYSCON entry + - description: pcie_ctrl register offset within SYSCON description: Phandle to the SYSCON entry required for configuring PCIe in RC or EP mode. - $ref: /schemas/types.yaml#/definitions/phandle msi-map: true @@ -84,10 +95,9 @@ examples: #size-cells = <2>; ranges = <0x81000000 0 0 0x10020000 0 0x00010000>, <0x82000000 0 0x10030000 0x10030000 0 0x07FD0000>; - ti,syscon-pcie-id = <&pcie_devid>; - ti,syscon-pcie-mode = <&pcie0_mode>; + ti,syscon-pcie-id = <&scm_conf 0x0210>; + ti,syscon-pcie-mode = <&scm_conf 0x4060>; bus-range = <0x0 0xff>; - num-viewport = <16>; max-link-speed = <2>; dma-coherent; interrupts = <GIC_SPI 340 IRQ_TYPE_EDGE_RISING>; diff --git a/Documentation/devicetree/bindings/pci/ti,j721e-pci-host.yaml b/Documentation/devicetree/bindings/pci/ti,j721e-pci-host.yaml index cc900202df29..2115d5a3f0e1 100644 --- a/Documentation/devicetree/bindings/pci/ti,j721e-pci-host.yaml +++ b/Documentation/devicetree/bindings/pci/ti,j721e-pci-host.yaml @@ -60,6 +60,8 @@ properties: - const: fck - const: pcie_refclk + dma-coherent: true + vendor-id: const: 0x104c diff --git a/Documentation/devicetree/bindings/pci/xilinx-versal-cpm.yaml b/Documentation/devicetree/bindings/pci/xilinx-versal-cpm.yaml index a2bbc0eb7220..32f4641085bc 100644 --- a/Documentation/devicetree/bindings/pci/xilinx-versal-cpm.yaml +++ b/Documentation/devicetree/bindings/pci/xilinx-versal-cpm.yaml @@ -55,7 +55,6 @@ required: - reg-names - "#interrupt-cells" - interrupts - - interrupt-parent - interrupt-map - interrupt-map-mask - bus-range diff --git a/Documentation/devicetree/bindings/perf/arm,cmn.yaml b/Documentation/devicetree/bindings/perf/arm,cmn.yaml index 42424ccbdd0c..2d4219ec7eda 100644 --- a/Documentation/devicetree/bindings/perf/arm,cmn.yaml +++ b/Documentation/devicetree/bindings/perf/arm,cmn.yaml @@ -12,12 +12,14 @@ maintainers: properties: compatible: - const: arm,cmn-600 + enum: + - arm,cmn-600 + - arm,ci-700 reg: items: - description: Physical address of the base (PERIPHBASE) and - size (up to 64MB) of the configuration address space. + size of the configuration address space. interrupts: minItems: 1 @@ -31,14 +33,23 @@ properties: arm,root-node: $ref: /schemas/types.yaml#/definitions/uint32 - description: Offset from PERIPHBASE of the configuration - discovery node (see TRM definition of ROOTNODEBASE). + description: Offset from PERIPHBASE of CMN-600's configuration + discovery node (see TRM definition of ROOTNODEBASE). Not + relevant for newer CMN/CI products. required: - compatible - reg - interrupts - - arm,root-node + +if: + properties: + compatible: + contains: + const: arm,cmn-600 +then: + required: + - arm,root-node additionalProperties: false diff --git a/Documentation/devicetree/bindings/perf/arm,dsu-pmu.yaml b/Documentation/devicetree/bindings/perf/arm,dsu-pmu.yaml new file mode 100644 index 000000000000..aef63a542f34 --- /dev/null +++ b/Documentation/devicetree/bindings/perf/arm,dsu-pmu.yaml @@ -0,0 +1,45 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +# Copyright 2021 Arm Ltd. +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/perf/arm,dsu-pmu.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: ARM DynamIQ Shared Unit (DSU) Performance Monitor Unit (PMU) + +maintainers: + - Suzuki K Poulose <suzuki.poulose@arm.com> + - Robin Murphy <robin.murphy@arm.com> + +description: + ARM DynamIQ 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 gathering various statistics on the operation of the + DSU. The PMU provides independent 32-bit counters that can count any of the + supported events, along with a 64-bit cycle counter. The PMU is accessed via + CPU system registers and has no MMIO component. + +properties: + compatible: + oneOf: + - const: arm,dsu-pmu + - items: + - const: arm,dsu-110-pmu + - const: arm,dsu-pmu + + interrupts: + items: + - description: nCLUSTERPMUIRQ interrupt + + cpus: + $ref: /schemas/types.yaml#/definitions/phandle-array + minItems: 1 + maxItems: 12 + description: List of phandles for the CPUs connected to this DSU instance. + +required: + - compatible + - interrupts + - cpus + +additionalProperties: false diff --git a/Documentation/devicetree/bindings/perf/arm,smmu-v3-pmcg.yaml b/Documentation/devicetree/bindings/perf/arm,smmu-v3-pmcg.yaml new file mode 100644 index 000000000000..a4b53a6a1ebf --- /dev/null +++ b/Documentation/devicetree/bindings/perf/arm,smmu-v3-pmcg.yaml @@ -0,0 +1,70 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/perf/arm,smmu-v3-pmcg.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Arm SMMUv3 Performance Monitor Counter Group + +maintainers: + - Will Deacon <will@kernel.org> + - Robin Murphy <robin.murphy@arm.com> + +description: | + An SMMUv3 may have several Performance Monitor Counter Group (PMCG). + They are standalone performance monitoring units that support both + architected and IMPLEMENTATION DEFINED event counters. + +properties: + $nodename: + pattern: "^pmu@[0-9a-f]*" + compatible: + oneOf: + - items: + - const: arm,mmu-600-pmcg + - const: arm,smmu-v3-pmcg + - const: arm,smmu-v3-pmcg + + reg: + items: + - description: Register page 0 + - description: Register page 1, if SMMU_PMCG_CFGR.RELOC_CTRS = 1 + minItems: 1 + + interrupts: + maxItems: 1 + + msi-parent: true + +required: + - compatible + - reg + +anyOf: + - required: + - interrupts + - required: + - msi-parent + +additionalProperties: false + +examples: + - | + #include <dt-bindings/interrupt-controller/arm-gic.h> + #include <dt-bindings/interrupt-controller/irq.h> + + pmu@2b420000 { + compatible = "arm,smmu-v3-pmcg"; + reg = <0x2b420000 0x1000>, + <0x2b430000 0x1000>; + interrupts = <GIC_SPI 80 IRQ_TYPE_EDGE_RISING>; + msi-parent = <&its 0xff0000>; + }; + + pmu@2b440000 { + compatible = "arm,smmu-v3-pmcg"; + reg = <0x2b440000 0x1000>, + <0x2b450000 0x1000>; + interrupts = <GIC_SPI 81 IRQ_TYPE_EDGE_RISING>; + msi-parent = <&its 0xff0000>; + }; diff --git a/Documentation/devicetree/bindings/perf/marvell-cn10k-tad.yaml b/Documentation/devicetree/bindings/perf/marvell-cn10k-tad.yaml new file mode 100644 index 000000000000..362142252667 --- /dev/null +++ b/Documentation/devicetree/bindings/perf/marvell-cn10k-tad.yaml @@ -0,0 +1,63 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/perf/marvell-cn10k-tad.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Marvell CN10K LLC-TAD performance monitor + +maintainers: + - Bhaskara Budiredla <bbudiredla@marvell.com> + +description: | + The Tag-and-Data units (TADs) maintain coherence and contain CN10K + shared on-chip last level cache (LLC). The tad pmu measures the + performance of last-level cache. Each tad pmu supports up to eight + counters. + + The DT setup comprises of number of tad blocks, the sizes of pmu + regions, tad blocks and overall base address of the HW. + +properties: + compatible: + const: marvell,cn10k-tad-pmu + + reg: + maxItems: 1 + + marvell,tad-cnt: + description: specifies the number of tads on the soc + $ref: /schemas/types.yaml#/definitions/uint32 + + marvell,tad-page-size: + description: specifies the size of each tad page + $ref: /schemas/types.yaml#/definitions/uint32 + + marvell,tad-pmu-page-size: + description: specifies the size of page that the pmu uses + $ref: /schemas/types.yaml#/definitions/uint32 + +required: + - compatible + - reg + - marvell,tad-cnt + - marvell,tad-page-size + - marvell,tad-pmu-page-size + +additionalProperties: false + +examples: + - | + + tad { + #address-cells = <2>; + #size-cells = <2>; + + tad_pmu@80000000 { + compatible = "marvell,cn10k-tad-pmu"; + reg = <0x87e2 0x80000000 0x0 0x1000>; + marvell,tad-cnt = <1>; + marvell,tad-page-size = <0x1000>; + marvell,tad-pmu-page-size = <0x1000>; + }; + }; diff --git a/Documentation/devicetree/bindings/phy/amlogic,meson8-hdmi-tx-phy.yaml b/Documentation/devicetree/bindings/phy/amlogic,meson8-hdmi-tx-phy.yaml new file mode 100644 index 000000000000..1f085cdd1c85 --- /dev/null +++ b/Documentation/devicetree/bindings/phy/amlogic,meson8-hdmi-tx-phy.yaml @@ -0,0 +1,65 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +%YAML 1.2 +--- +$id: "http://devicetree.org/schemas/phy/amlogic,meson8-hdmi-tx-phy.yaml#" +$schema: "http://devicetree.org/meta-schemas/core.yaml#" + +title: Amlogic Meson8, Meson8b and Meson8m2 HDMI TX PHY + +maintainers: + - Martin Blumenstingl <martin.blumenstingl@googlemail.com> + +description: |+ + The HDMI TX PHY node should be the child of a syscon node with the + required property: + + compatible = "amlogic,meson-hhi-sysctrl", "simple-mfd", "syscon" + + Refer to the bindings described in + Documentation/devicetree/bindings/mfd/syscon.yaml + +properties: + $nodename: + pattern: "^hdmi-phy@[0-9a-f]+$" + + compatible: + oneOf: + - items: + - enum: + - amlogic,meson8b-hdmi-tx-phy + - amlogic,meson8m2-hdmi-tx-phy + - const: amlogic,meson8-hdmi-tx-phy + - const: amlogic,meson8-hdmi-tx-phy + + reg: + maxItems: 1 + + clocks: + minItems: 1 + description: + HDMI TMDS clock + + "#phy-cells": + const: 0 + +required: + - compatible + - "#phy-cells" + +additionalProperties: false + +examples: + - | + hdmi-phy@3a0 { + compatible = "amlogic,meson8-hdmi-tx-phy"; + reg = <0x3a0 0xc>; + clocks = <&tmds_clock>; + #phy-cells = <0>; + }; + - | + hdmi-phy@3a0 { + compatible = "amlogic,meson8b-hdmi-tx-phy", "amlogic,meson8-hdmi-tx-phy"; + reg = <0x3a0 0xc>; + clocks = <&tmds_clock>; + #phy-cells = <0>; + }; diff --git a/Documentation/devicetree/bindings/phy/brcm,cygnus-pcie-phy.txt b/Documentation/devicetree/bindings/phy/brcm,cygnus-pcie-phy.txt deleted file mode 100644 index 10efff28b52b..000000000000 --- a/Documentation/devicetree/bindings/phy/brcm,cygnus-pcie-phy.txt +++ /dev/null @@ -1,47 +0,0 @@ -Broadcom Cygnus PCIe PHY - -Required properties: -- compatible: must be "brcm,cygnus-pcie-phy" -- reg: base address and length of the PCIe PHY block -- #address-cells: must be 1 -- #size-cells: must be 0 - -Each PCIe PHY should be represented by a child node - -Required properties For the child node: -- reg: the PHY ID -0 - PCIe RC 0 -1 - PCIe RC 1 -- #phy-cells: must be 0 - -Example: - pcie_phy: phy@301d0a0 { - compatible = "brcm,cygnus-pcie-phy"; - reg = <0x0301d0a0 0x14>; - - pcie0_phy: phy@0 { - reg = <0>; - #phy-cells = <0>; - }; - - pcie1_phy: phy@1 { - reg = <1>; - #phy-cells = <0>; - }; - }; - - /* users of the PCIe phy */ - - pcie0: pcie@18012000 { - ... - ... - phys = <&pcie0_phy>; - phy-names = "pcie-phy"; - }; - - pcie1: pcie@18013000 { - ... - ... - phys = <pcie1_phy>; - phy-names = "pcie-phy"; - }; diff --git a/Documentation/devicetree/bindings/phy/brcm,cygnus-pcie-phy.yaml b/Documentation/devicetree/bindings/phy/brcm,cygnus-pcie-phy.yaml new file mode 100644 index 000000000000..045699c65779 --- /dev/null +++ b/Documentation/devicetree/bindings/phy/brcm,cygnus-pcie-phy.yaml @@ -0,0 +1,76 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/phy/brcm,cygnus-pcie-phy.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Broadcom Cygnus PCIe PHY + +maintainers: + - Ray Jui <ray.jui@broadcom.com> + - Scott Branden <scott.branden@broadcom.com> + +properties: + $nodename: + pattern: "^pcie[-|_]phy(@.*)?$" + + compatible: + items: + - const: brcm,cygnus-pcie-phy + + reg: + maxItems: 1 + description: > + Base address and length of the PCIe PHY block + + "#address-cells": + const: 1 + + "#size-cells": + const: 0 + +patternProperties: + "^pcie-phy@[0-9]+$": + type: object + description: > + PCIe PHY child nodes + + properties: + reg: + maxItems: 1 + description: > + The PCIe PHY port number + + "#phy-cells": + const: 0 + + required: + - reg + - "#phy-cells" + +required: + - compatible + - reg + - "#address-cells" + - "#size-cells" + +additionalProperties: false + +examples: + - | + pcie_phy: pcie_phy@301d0a0 { + compatible = "brcm,cygnus-pcie-phy"; + reg = <0x0301d0a0 0x14>; + #address-cells = <1>; + #size-cells = <0>; + + pcie0_phy: pcie-phy@0 { + reg = <0>; + #phy-cells = <0>; + }; + + pcie1_phy: pcie-phy@1 { + reg = <1>; + #phy-cells = <0>; + }; + }; diff --git a/Documentation/devicetree/bindings/phy/brcm,mdio-mux-bus-pci.txt b/Documentation/devicetree/bindings/phy/brcm,mdio-mux-bus-pci.txt deleted file mode 100644 index 5b51007c6f24..000000000000 --- a/Documentation/devicetree/bindings/phy/brcm,mdio-mux-bus-pci.txt +++ /dev/null @@ -1,27 +0,0 @@ -* Broadcom NS2 PCIe PHY binding document - -Required bus properties: -- reg: MDIO Bus number for the MDIO interface -- #address-cells: must be 1 -- #size-cells: must be 0 - -Required PHY properties: -- compatible: should be "brcm,ns2-pcie-phy" -- reg: MDIO Phy ID for the MDIO interface -- #phy-cells: must be 0 - -This is a child bus node of "brcm,mdio-mux-iproc" node. - -Example: - -mdio@0 { - reg = <0x0>; - #address-cells = <1>; - #size-cells = <0>; - - pci_phy0: pci-phy@0 { - compatible = "brcm,ns2-pcie-phy"; - reg = <0x0>; - #phy-cells = <0>; - }; -}; diff --git a/Documentation/devicetree/bindings/phy/brcm,ns2-pcie-phy.yaml b/Documentation/devicetree/bindings/phy/brcm,ns2-pcie-phy.yaml new file mode 100644 index 000000000000..70eb48b391c9 --- /dev/null +++ b/Documentation/devicetree/bindings/phy/brcm,ns2-pcie-phy.yaml @@ -0,0 +1,41 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/phy/brcm,ns2-pcie-phy.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Broadcom NS2 PCIe PHY binding document + +maintainers: + - Ray Jui <ray.jui@broadcom.com> + - Scott Branden <scott.branden@broadcom.com> + +properties: + compatible: + const: brcm,ns2-pcie-phy + + reg: + maxItems: 1 + + "#phy-cells": + const: 0 + +required: + - compatible + - reg + - "#phy-cells" + +additionalProperties: false + +examples: + - | + mdio { + #address-cells = <1>; + #size-cells = <0>; + + pci-phy@0 { + compatible = "brcm,ns2-pcie-phy"; + reg = <0x0>; + #phy-cells = <0>; + }; + }; diff --git a/Documentation/devicetree/bindings/phy/fsl,imx8-pcie-phy.yaml b/Documentation/devicetree/bindings/phy/fsl,imx8-pcie-phy.yaml new file mode 100644 index 000000000000..b6421eedece3 --- /dev/null +++ b/Documentation/devicetree/bindings/phy/fsl,imx8-pcie-phy.yaml @@ -0,0 +1,92 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/phy/fsl,imx8-pcie-phy.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Freescale i.MX8 SoC series PCIe PHY Device Tree Bindings + +maintainers: + - Richard Zhu <hongxing.zhu@nxp.com> + +properties: + "#phy-cells": + const: 0 + + compatible: + enum: + - fsl,imx8mm-pcie-phy + + reg: + maxItems: 1 + + clocks: + maxItems: 1 + + clock-names: + items: + - const: ref + + resets: + maxItems: 1 + + reset-names: + items: + - const: pciephy + + fsl,refclk-pad-mode: + description: | + Specifies the mode of the refclk pad used. It can be UNUSED(PHY + refclock is derived from SoC internal source), INPUT(PHY refclock + is provided externally via the refclk pad) or OUTPUT(PHY refclock + is derived from SoC internal source and provided on the refclk pad). + Refer include/dt-bindings/phy/phy-imx8-pcie.h for the constants + to be used. + $ref: /schemas/types.yaml#/definitions/uint32 + enum: [ 0, 1, 2 ] + + fsl,tx-deemph-gen1: + description: Gen1 De-emphasis value (optional). + $ref: /schemas/types.yaml#/definitions/uint32 + default: 0 + + fsl,tx-deemph-gen2: + description: Gen2 De-emphasis value (optional). + $ref: /schemas/types.yaml#/definitions/uint32 + default: 0 + + fsl,clkreq-unsupported: + type: boolean + description: A boolean property indicating the CLKREQ# signal is + not supported in the board design (optional) + +required: + - "#phy-cells" + - compatible + - reg + - clocks + - clock-names + - fsl,refclk-pad-mode + +additionalProperties: false + +examples: + - | + #include <dt-bindings/clock/imx8mm-clock.h> + #include <dt-bindings/phy/phy-imx8-pcie.h> + #include <dt-bindings/reset/imx8mq-reset.h> + + pcie_phy: pcie-phy@32f00000 { + compatible = "fsl,imx8mm-pcie-phy"; + reg = <0x32f00000 0x10000>; + clocks = <&clk IMX8MM_CLK_PCIE1_PHY>; + clock-names = "ref"; + assigned-clocks = <&clk IMX8MM_CLK_PCIE1_PHY>; + assigned-clock-rates = <100000000>; + assigned-clock-parents = <&clk IMX8MM_SYS_PLL2_100M>; + resets = <&src IMX8MQ_RESET_PCIEPHY>; + reset-names = "pciephy"; + fsl,refclk-pad-mode = <IMX8_PCIE_REFCLK_PAD_INPUT>; + #phy-cells = <0>; + }; +... diff --git a/Documentation/devicetree/bindings/phy/intel,phy-thunderbay-emmc.yaml b/Documentation/devicetree/bindings/phy/intel,phy-thunderbay-emmc.yaml new file mode 100644 index 000000000000..34bdb5c4cae8 --- /dev/null +++ b/Documentation/devicetree/bindings/phy/intel,phy-thunderbay-emmc.yaml @@ -0,0 +1,46 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/phy/intel,phy-thunderbay-emmc.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Intel Thunder Bay eMMC PHY bindings + +maintainers: + - Srikandan Nandhini <nandhini.srikandan@intel.com> + +properties: + compatible: + const: intel,thunderbay-emmc-phy + + "#phy-cells": + const: 0 + + reg: + maxItems: 1 + + clocks: + maxItems: 1 + + clock-names: + items: + - const: emmcclk + +required: + - "#phy-cells" + - compatible + - reg + - clocks + +additionalProperties: false + +examples: + - | + mmc_phy@80440800 { + #phy-cells = <0x0>; + compatible = "intel,thunderbay-emmc-phy"; + status = "okay"; + reg = <0x80440800 0x100>; + clocks = <&emmc>; + clock-names = "emmcclk"; + }; diff --git a/Documentation/devicetree/bindings/phy/mediatek,tphy.yaml b/Documentation/devicetree/bindings/phy/mediatek,tphy.yaml index 9e6c0f43f1c6..05ee274b4b71 100644 --- a/Documentation/devicetree/bindings/phy/mediatek,tphy.yaml +++ b/Documentation/devicetree/bindings/phy/mediatek,tphy.yaml @@ -160,6 +160,24 @@ patternProperties: - PHY_TYPE_PCIE - PHY_TYPE_SATA + nvmem-cells: + items: + - description: internal R efuse for U2 PHY or U3/PCIe PHY + - description: rx_imp_sel efuse for U3/PCIe PHY + - description: tx_imp_sel efuse for U3/PCIe PHY + description: | + Phandles to nvmem cell that contains the efuse data; + Available only for U2 PHY or U3/PCIe PHY of version 2/3, these + three items should be provided at the same time for U3/PCIe PHY, + when use software to load efuse; + If unspecified, will use hardware auto-load efuse. + + nvmem-cell-names: + items: + - const: intr + - const: rx_imp + - const: tx_imp + # The following optional vendor properties are only for debug or HQA test mediatek,eye-src: description: diff --git a/Documentation/devicetree/bindings/phy/microchip,lan966x-serdes.yaml b/Documentation/devicetree/bindings/phy/microchip,lan966x-serdes.yaml new file mode 100644 index 000000000000..6e914fbbac56 --- /dev/null +++ b/Documentation/devicetree/bindings/phy/microchip,lan966x-serdes.yaml @@ -0,0 +1,59 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/phy/microchip,lan966x-serdes.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Microchip Lan966x Serdes controller + +maintainers: + - Horatiu Vultur <horatiu.vultur@microchip.com> + +description: | + Lan966x has 7 interfaces, consisting of 2 copper transceivers(CU), + 3 SERDES6G and 2 RGMII interfaces. Two of the SERDES6G support QSGMII. + Also it has 8 logical Ethernet ports which can be connected to these + interfaces. The Serdes controller will allow to configure these interfaces + and allows to "mux" the interfaces to different ports. + + For simple selection of the interface that is used with a port, the + following macros are defined CU(X), SERDES6G(X), RGMII(X). Where X is a + number that represents the index of that interface type. For example + CU(1) means use interface copper transceivers 1. SERDES6G(2) means use + interface SerDes 2. + +properties: + $nodename: + pattern: "^serdes@[0-9a-f]+$" + + compatible: + const: microchip,lan966x-serdes + + reg: + items: + - description: HSIO registers + - description: HW_STAT register + + '#phy-cells': + const: 2 + description: | + - Input port to use for a given macro. + - The macro to be used. The macros are defined in + dt-bindings/phy/phy-lan966x-serdes. + +required: + - compatible + - reg + - '#phy-cells' + +additionalProperties: false + +examples: + - | + serdes: serdes@e2004010 { + compatible = "microchip,lan966x-serdes"; + reg = <0xe202c000 0x9c>, <0xe2004010 0x4>; + #phy-cells = <2>; + }; + +... diff --git a/Documentation/devicetree/bindings/phy/phy-cadence-sierra.yaml b/Documentation/devicetree/bindings/phy/phy-cadence-sierra.yaml index e71b32c9c0d1..a9e227d8b076 100644 --- a/Documentation/devicetree/bindings/phy/phy-cadence-sierra.yaml +++ b/Documentation/devicetree/bindings/phy/phy-cadence-sierra.yaml @@ -113,6 +113,15 @@ patternProperties: minimum: 1 maximum: 16 + cdns,ssc-mode: + description: + Specifies the Spread Spectrum Clocking mode used. It can be NO_SSC, + EXTERNAL_SSC or INTERNAL_SSC. + Refer include/dt-bindings/phy/phy-cadence.h for the constants to be used. + $ref: /schemas/types.yaml#/definitions/uint32 + enum: [0, 1, 2] + default: 1 + required: - reg - resets diff --git a/Documentation/devicetree/bindings/phy/phy-cadence-torrent.yaml b/Documentation/devicetree/bindings/phy/phy-cadence-torrent.yaml index bd9ae11c9994..2fec9e54ad0e 100644 --- a/Documentation/devicetree/bindings/phy/phy-cadence-torrent.yaml +++ b/Documentation/devicetree/bindings/phy/phy-cadence-torrent.yaml @@ -202,7 +202,7 @@ examples: #phy-cells = <0>; cdns,phy-type = <PHY_TYPE_PCIE>; cdns,num-lanes = <2>; - cdns,ssc-mode = <TORRENT_SERDES_NO_SSC>; + cdns,ssc-mode = <CDNS_SERDES_NO_SSC>; }; phy@2 { @@ -211,7 +211,7 @@ examples: #phy-cells = <0>; cdns,phy-type = <PHY_TYPE_SGMII>; cdns,num-lanes = <1>; - cdns,ssc-mode = <TORRENT_SERDES_NO_SSC>; + cdns,ssc-mode = <CDNS_SERDES_NO_SSC>; }; }; }; diff --git a/Documentation/devicetree/bindings/phy/phy-rockchip-inno-usb2.yaml b/Documentation/devicetree/bindings/phy/phy-rockchip-inno-usb2.yaml index 5bebd86bf8b6..4b75289735eb 100644 --- a/Documentation/devicetree/bindings/phy/phy-rockchip-inno-usb2.yaml +++ b/Documentation/devicetree/bindings/phy/phy-rockchip-inno-usb2.yaml @@ -18,6 +18,7 @@ properties: - rockchip,rk3328-usb2phy - rockchip,rk3366-usb2phy - rockchip,rk3399-usb2phy + - rockchip,rk3568-usb2phy - rockchip,rv1108-usb2phy reg: @@ -50,6 +51,10 @@ properties: description: Phandle to the extcon device providing the cable state for the otg phy. + interrupts: + description: Muxed interrupt for both ports + maxItems: 1 + rockchip,usbgrf: $ref: /schemas/types.yaml#/definitions/phandle description: @@ -67,6 +72,7 @@ properties: interrupts: description: host linestate interrupt + maxItems: 1 interrupt-names: const: linestate @@ -78,8 +84,6 @@ properties: required: - "#phy-cells" - - interrupts - - interrupt-names otg-port: type: object @@ -109,8 +113,6 @@ properties: required: - "#phy-cells" - - interrupts - - interrupt-names required: - compatible @@ -120,6 +122,40 @@ required: - host-port - otg-port +allOf: + - if: + properties: + compatible: + contains: + const: rockchip,rk3568-usb2phy + + then: + properties: + host-port: + properties: + interrupts: false + + otg-port: + properties: + interrupts: false + + required: + - interrupts + + else: + properties: + interrupts: false + + host-port: + required: + - interrupts + - interrupt-names + + otg-port: + required: + - interrupts + - interrupt-names + additionalProperties: false examples: diff --git a/Documentation/devicetree/bindings/phy/phy-tegra194-p2u.txt b/Documentation/devicetree/bindings/phy/phy-tegra194-p2u.txt deleted file mode 100644 index d23ff90baad5..000000000000 --- a/Documentation/devicetree/bindings/phy/phy-tegra194-p2u.txt +++ /dev/null @@ -1,28 +0,0 @@ -NVIDIA Tegra194 P2U binding - -Tegra194 has two PHY bricks namely HSIO (High Speed IO) and NVHS (NVIDIA High -Speed) each interfacing with 12 and 8 P2U instances respectively. -A P2U instance is a glue logic between Synopsys DesignWare Core PCIe IP's PIPE -interface and PHY of HSIO/NVHS bricks. Each P2U instance represents one PCIe -lane. - -Required properties: -- compatible: For Tegra19x, must contain "nvidia,tegra194-p2u". -- reg: Should be the physical address space and length of respective each P2U - instance. -- reg-names: Must include the entry "ctl". - -Required properties for PHY port node: -- #phy-cells: Defined by generic PHY bindings. Must be 0. - -Refer to phy/phy-bindings.txt for the generic PHY binding properties. - -Example: - -p2u_hsio_0: phy@3e10000 { - compatible = "nvidia,tegra194-p2u"; - reg = <0x03e10000 0x10000>; - reg-names = "ctl"; - - #phy-cells = <0>; -}; diff --git a/Documentation/devicetree/bindings/phy/phy-tegra194-p2u.yaml b/Documentation/devicetree/bindings/phy/phy-tegra194-p2u.yaml new file mode 100644 index 000000000000..9a89d05efbda --- /dev/null +++ b/Documentation/devicetree/bindings/phy/phy-tegra194-p2u.yaml @@ -0,0 +1,44 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +%YAML 1.2 +--- +$id: "http://devicetree.org/schemas/phy/phy-tegra194-p2u.yaml#" +$schema: "http://devicetree.org/meta-schemas/core.yaml#" + +title: NVIDIA Tegra194 P2U binding + +maintainers: + - Thierry Reding <treding@nvidia.com> + +description: > + Tegra194 has two PHY bricks namely HSIO (High Speed IO) and NVHS (NVIDIA High + Speed) each interfacing with 12 and 8 P2U instances respectively. + A P2U instance is a glue logic between Synopsys DesignWare Core PCIe IP's PIPE + interface and PHY of HSIO/NVHS bricks. Each P2U instance represents one PCIe + lane. + +properties: + compatible: + const: nvidia,tegra194-p2u + + reg: + maxItems: 1 + description: Should be the physical address space and length of respective each P2U instance. + + reg-names: + items: + - const: ctl + + '#phy-cells': + const: 0 + +additionalProperties: false + +examples: + - | + p2u_hsio_0: phy@3e10000 { + compatible = "nvidia,tegra194-p2u"; + reg = <0x03e10000 0x10000>; + reg-names = "ctl"; + + #phy-cells = <0>; + }; diff --git a/Documentation/devicetree/bindings/phy/qcom,edp-phy.yaml b/Documentation/devicetree/bindings/phy/qcom,edp-phy.yaml new file mode 100644 index 000000000000..9076e19b6417 --- /dev/null +++ b/Documentation/devicetree/bindings/phy/qcom,edp-phy.yaml @@ -0,0 +1,67 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) + +%YAML 1.2 +--- +$id: "http://devicetree.org/schemas/phy/qcom,edp-phy.yaml#" +$schema: "http://devicetree.org/meta-schemas/core.yaml#" + +title: Qualcomm eDP PHY + +maintainers: + - Bjorn Andersson <bjorn.andersson@linaro.org> + +description: + The Qualcomm eDP PHY is found in a number of Qualcomm platform and provides + the physical interface for Embedded Display Port. + +properties: + compatible: + const: qcom,sc8180x-edp-phy + + reg: + items: + - description: PHY base register block + - description: tx0 register block + - description: tx1 register block + - description: PLL register block + + clocks: + maxItems: 2 + + clock-names: + items: + - const: aux + - const: cfg_ahb + + "#clock-cells": + const: 1 + + "#phy-cells": + const: 0 + +required: + - compatible + - reg + - clocks + - clock-names + - "#clock-cells" + - "#phy-cells" + +additionalProperties: false + +examples: + - | + phy@aec2a00 { + compatible = "qcom,sc8180x-edp-phy"; + reg = <0x0aec2a00 0x1c0>, + <0x0aec2200 0xa0>, + <0x0aec2600 0xa0>, + <0x0aec2000 0x19c>; + + clocks = <&dispcc 0>, <&dispcc 1>; + clock-names = "aux", "cfg_ahb"; + + #clock-cells = <1>; + #phy-cells = <0>; + }; +... diff --git a/Documentation/devicetree/bindings/phy/qcom,qmp-phy.yaml b/Documentation/devicetree/bindings/phy/qcom,qmp-phy.yaml index 630ceaf915e2..e417cd667997 100644 --- a/Documentation/devicetree/bindings/phy/qcom,qmp-phy.yaml +++ b/Documentation/devicetree/bindings/phy/qcom,qmp-phy.yaml @@ -50,6 +50,10 @@ properties: - qcom,sm8350-qmp-ufs-phy - qcom,sm8350-qmp-usb3-phy - qcom,sm8350-qmp-usb3-uni-phy + - qcom,sm8450-qmp-gen3x1-pcie-phy + - qcom,sm8450-qmp-gen4x2-pcie-phy + - qcom,sm8450-qmp-ufs-phy + - qcom,sm8450-qmp-usb3-phy - qcom,sdx55-qmp-pcie-phy - qcom,sdx55-qmp-usb3-uni-phy @@ -332,6 +336,8 @@ allOf: - qcom,sm8250-qmp-gen3x1-pcie-phy - qcom,sm8250-qmp-gen3x2-pcie-phy - qcom,sm8250-qmp-modem-pcie-phy + - qcom,sm8450-qmp-gen3x1-pcie-phy + - qcom,sm8450-qmp-gen4x2-pcie-phy then: properties: clocks: diff --git a/Documentation/devicetree/bindings/phy/qcom,qusb2-phy.yaml b/Documentation/devicetree/bindings/phy/qcom,qusb2-phy.yaml index aa2e409a1a09..e651a63a4be3 100644 --- a/Documentation/devicetree/bindings/phy/qcom,qusb2-phy.yaml +++ b/Documentation/devicetree/bindings/phy/qcom,qusb2-phy.yaml @@ -30,6 +30,7 @@ properties: - enum: - qcom,sc7180-qusb2-phy - qcom,sdm845-qusb2-phy + - qcom,sm6350-qusb2-phy - const: qcom,qusb2-v2-phy reg: maxItems: 1 diff --git a/Documentation/devicetree/bindings/phy/qcom,usb-snps-femto-v2.yaml b/Documentation/devicetree/bindings/phy/qcom,usb-snps-femto-v2.yaml index 20203a8a9e41..0dfe6914ec87 100644 --- a/Documentation/devicetree/bindings/phy/qcom,usb-snps-femto-v2.yaml +++ b/Documentation/devicetree/bindings/phy/qcom,usb-snps-femto-v2.yaml @@ -20,6 +20,7 @@ properties: - qcom,sm8150-usb-hs-phy - qcom,sm8250-usb-hs-phy - qcom,sm8350-usb-hs-phy + - qcom,sm8450-usb-hs-phy - qcom,usb-snps-femto-v2-phy reg: diff --git a/Documentation/devicetree/bindings/phy/socionext,uniphier-ahci-phy.yaml b/Documentation/devicetree/bindings/phy/socionext,uniphier-ahci-phy.yaml index 745c525ce6b9..3b400a85b44a 100644 --- a/Documentation/devicetree/bindings/phy/socionext,uniphier-ahci-phy.yaml +++ b/Documentation/devicetree/bindings/phy/socionext,uniphier-ahci-phy.yaml @@ -16,6 +16,7 @@ maintainers: properties: compatible: enum: + - socionext,uniphier-pro4-ahci-phy - socionext,uniphier-pxs2-ahci-phy - socionext,uniphier-pxs3-ahci-phy @@ -26,23 +27,35 @@ properties: const: 0 clocks: + minItems: 1 maxItems: 2 clock-names: oneOf: - items: # for PXs2 - const: link + - items: # for Pro4 + - const: link + - const: gio - items: # for others - const: link - const: phy resets: - maxItems: 2 + minItems: 2 + maxItems: 5 reset-names: - items: - - const: link - - const: phy + oneOf: + - items: # for Pro4 + - const: link + - const: gio + - const: pm + - const: tx + - const: rx + - items: # for others + - const: link + - const: phy required: - compatible diff --git a/Documentation/devicetree/bindings/phy/socionext,uniphier-pcie-phy.yaml b/Documentation/devicetree/bindings/phy/socionext,uniphier-pcie-phy.yaml index 3e0566899041..fbb71d6dd531 100644 --- a/Documentation/devicetree/bindings/phy/socionext,uniphier-pcie-phy.yaml +++ b/Documentation/devicetree/bindings/phy/socionext,uniphier-pcie-phy.yaml @@ -19,6 +19,7 @@ properties: - socionext,uniphier-pro5-pcie-phy - socionext,uniphier-ld20-pcie-phy - socionext,uniphier-pxs3-pcie-phy + - socionext,uniphier-nx1-pcie-phy reg: maxItems: 1 diff --git a/Documentation/devicetree/bindings/phy/socionext,uniphier-usb3hs-phy.yaml b/Documentation/devicetree/bindings/phy/socionext,uniphier-usb3hs-phy.yaml index a681cbc3b4ef..33946efcac5e 100644 --- a/Documentation/devicetree/bindings/phy/socionext,uniphier-usb3hs-phy.yaml +++ b/Documentation/devicetree/bindings/phy/socionext,uniphier-usb3hs-phy.yaml @@ -22,6 +22,7 @@ properties: - socionext,uniphier-pxs2-usb3-hsphy - socionext,uniphier-ld20-usb3-hsphy - socionext,uniphier-pxs3-usb3-hsphy + - socionext,uniphier-nx1-usb3-hsphy reg: maxItems: 1 diff --git a/Documentation/devicetree/bindings/phy/socionext,uniphier-usb3ss-phy.yaml b/Documentation/devicetree/bindings/phy/socionext,uniphier-usb3ss-phy.yaml index 41c0dd68ee25..92d46eb913a3 100644 --- a/Documentation/devicetree/bindings/phy/socionext,uniphier-usb3ss-phy.yaml +++ b/Documentation/devicetree/bindings/phy/socionext,uniphier-usb3ss-phy.yaml @@ -23,6 +23,7 @@ properties: - socionext,uniphier-pxs2-usb3-ssphy - socionext,uniphier-ld20-usb3-ssphy - socionext,uniphier-pxs3-usb3-ssphy + - socionext,uniphier-nx1-usb3-ssphy reg: maxItems: 1 diff --git a/Documentation/devicetree/bindings/phy/xlnx,zynqmp-psgtr.yaml b/Documentation/devicetree/bindings/phy/xlnx,zynqmp-psgtr.yaml index 04d5654efb38..79906519c652 100644 --- a/Documentation/devicetree/bindings/phy/xlnx,zynqmp-psgtr.yaml +++ b/Documentation/devicetree/bindings/phy/xlnx,zynqmp-psgtr.yaml @@ -29,7 +29,7 @@ properties: - PHY_TYPE_PCIE - PHY_TYPE_SATA - PHY_TYPE_SGMII - - PHY_TYPE_USB + - PHY_TYPE_USB3 - description: The PHY instance minimum: 0 maximum: 1 # for DP, SATA or USB diff --git a/Documentation/devicetree/bindings/pinctrl/actions,s500-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/actions,s500-pinctrl.yaml index 3f94f6944740..fb0f69ce9c16 100644 --- a/Documentation/devicetree/bindings/pinctrl/actions,s500-pinctrl.yaml +++ b/Documentation/devicetree/bindings/pinctrl/actions,s500-pinctrl.yaml @@ -184,6 +184,9 @@ patternProperties: additionalProperties: false +allOf: + - $ref: "pinctrl.yaml#" + required: - compatible - reg diff --git a/Documentation/devicetree/bindings/pinctrl/allwinner,sun4i-a10-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/allwinner,sun4i-a10-pinctrl.yaml index cce63c3cc463..bfce850c2035 100644 --- a/Documentation/devicetree/bindings/pinctrl/allwinner,sun4i-a10-pinctrl.yaml +++ b/Documentation/devicetree/bindings/pinctrl/allwinner,sun4i-a10-pinctrl.yaml @@ -147,6 +147,7 @@ allOf: # boards are defining it at the moment so it would generate a lot of # warnings. + - $ref: "pinctrl.yaml#" - if: properties: compatible: diff --git a/Documentation/devicetree/bindings/pinctrl/apple,pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/apple,pinctrl.yaml index 07b00de79755..d3b11351ca45 100644 --- a/Documentation/devicetree/bindings/pinctrl/apple,pinctrl.yaml +++ b/Documentation/devicetree/bindings/pinctrl/apple,pinctrl.yaml @@ -17,7 +17,9 @@ description: | properties: compatible: items: - - const: apple,t8103-pinctrl + - enum: + - apple,t8103-pinctrl + - apple,t6000-pinctrl - const: apple,pinctrl reg: @@ -50,6 +52,9 @@ properties: '#interrupt-cells': const: 2 + power-domains: + maxItems: 1 + patternProperties: '-pins$': type: object @@ -67,6 +72,9 @@ patternProperties: additionalProperties: false +allOf: + - $ref: "pinctrl.yaml#" + required: - compatible - reg diff --git a/Documentation/devicetree/bindings/pinctrl/aspeed,ast2400-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/aspeed,ast2400-pinctrl.yaml index 100bb6dea3ec..c689bea7ce6e 100644 --- a/Documentation/devicetree/bindings/pinctrl/aspeed,ast2400-pinctrl.yaml +++ b/Documentation/devicetree/bindings/pinctrl/aspeed,ast2400-pinctrl.yaml @@ -50,6 +50,9 @@ patternProperties: TXD3, TXD4, UART6, USB11D1, USB11H2, USB2D1, USB2H1, USBCKI, VGABIOS_ROM, VGAHS, VGAVS, VPI18, VPI24, VPI30, VPO12, VPO24, WDTRST1, WDTRST2] +allOf: + - $ref: "pinctrl.yaml#" + required: - compatible diff --git a/Documentation/devicetree/bindings/pinctrl/aspeed,ast2500-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/aspeed,ast2500-pinctrl.yaml index 904697bc9415..d316cc082107 100644 --- a/Documentation/devicetree/bindings/pinctrl/aspeed,ast2500-pinctrl.yaml +++ b/Documentation/devicetree/bindings/pinctrl/aspeed,ast2500-pinctrl.yaml @@ -62,6 +62,9 @@ patternProperties: USB11BHID, USB2AD, USB2AH, USB2BD, USB2BH, USBCKI, VGABIOSROM, VGAHS, VGAVS, VPI24, VPO, WDTRST1, WDTRST2] +allOf: + - $ref: "pinctrl.yaml#" + required: - compatible - aspeed,external-nodes diff --git a/Documentation/devicetree/bindings/pinctrl/aspeed,ast2600-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/aspeed,ast2600-pinctrl.yaml index ad2866c99738..57b68d6c7c70 100644 --- a/Documentation/devicetree/bindings/pinctrl/aspeed,ast2600-pinctrl.yaml +++ b/Documentation/devicetree/bindings/pinctrl/aspeed,ast2600-pinctrl.yaml @@ -83,6 +83,9 @@ patternProperties: UART7, UART8, UART9, USBA, USBB, VB, VGAHS, VGAVS, WDTRST1, WDTRST2, WDTRST3, WDTRST4] +allOf: + - $ref: "pinctrl.yaml#" + required: - compatible diff --git a/Documentation/devicetree/bindings/pinctrl/brcm,bcm6318-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/brcm,bcm6318-pinctrl.yaml index 08995a4f854b..ab019a1998e8 100644 --- a/Documentation/devicetree/bindings/pinctrl/brcm,bcm6318-pinctrl.yaml +++ b/Documentation/devicetree/bindings/pinctrl/brcm,bcm6318-pinctrl.yaml @@ -37,6 +37,9 @@ patternProperties: enum: [ gpio0, gpio1, gpio2, gpio3, gpio4, gpio5, gpio6, gpio7, gpio8, gpio9, gpio10, gpio11, gpio12, gpio13, gpio40 ] +allOf: + - $ref: "pinctrl.yaml#" + required: - compatible - reg diff --git a/Documentation/devicetree/bindings/pinctrl/brcm,bcm63268-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/brcm,bcm63268-pinctrl.yaml index 58ffed44b3c4..8c9d4668c8c4 100644 --- a/Documentation/devicetree/bindings/pinctrl/brcm,bcm63268-pinctrl.yaml +++ b/Documentation/devicetree/bindings/pinctrl/brcm,bcm63268-pinctrl.yaml @@ -41,6 +41,9 @@ patternProperties: vdsl_phy_override_1_grp, vdsl_phy_override_2_grp, vdsl_phy_override_3_grp, dsl_gpio8, dsl_gpio9 ] +allOf: + - $ref: "pinctrl.yaml#" + required: - compatible - reg diff --git a/Documentation/devicetree/bindings/pinctrl/brcm,bcm6328-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/brcm,bcm6328-pinctrl.yaml index 0fd24f40afb1..a8e22ec02215 100644 --- a/Documentation/devicetree/bindings/pinctrl/brcm,bcm6328-pinctrl.yaml +++ b/Documentation/devicetree/bindings/pinctrl/brcm,bcm6328-pinctrl.yaml @@ -36,6 +36,9 @@ patternProperties: gpio20, gpio25, gpio26, gpio27, gpio28, hsspi_cs1, usb_port1 ] +allOf: + - $ref: "pinctrl.yaml#" + required: - compatible - reg diff --git a/Documentation/devicetree/bindings/pinctrl/brcm,bcm6358-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/brcm,bcm6358-pinctrl.yaml index 0c3ce256aa78..35867355a47a 100644 --- a/Documentation/devicetree/bindings/pinctrl/brcm,bcm6358-pinctrl.yaml +++ b/Documentation/devicetree/bindings/pinctrl/brcm,bcm6358-pinctrl.yaml @@ -34,6 +34,9 @@ patternProperties: enum: [ ebi_cs_grp, uart1_grp, serial_led_grp, legacy_led_grp, led_grp, spi_cs_grp, utopia_grp, pwm_syn_clk, sys_irq_grp ] +allOf: + - $ref: "pinctrl.yaml#" + required: - compatible - reg diff --git a/Documentation/devicetree/bindings/pinctrl/brcm,bcm6362-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/brcm,bcm6362-pinctrl.yaml index 6f68fee373bd..b584d4b27223 100644 --- a/Documentation/devicetree/bindings/pinctrl/brcm,bcm6362-pinctrl.yaml +++ b/Documentation/devicetree/bindings/pinctrl/brcm,bcm6362-pinctrl.yaml @@ -41,6 +41,9 @@ patternProperties: gpio15, gpio16, gpio17, gpio18, gpio19, gpio20, gpio21, gpio22, gpio23, gpio24, gpio25, gpio26, gpio27, nand_grp ] +allOf: + - $ref: "pinctrl.yaml#" + required: - compatible - reg diff --git a/Documentation/devicetree/bindings/pinctrl/brcm,bcm6368-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/brcm,bcm6368-pinctrl.yaml index f4168b9f4460..229323d9237d 100644 --- a/Documentation/devicetree/bindings/pinctrl/brcm,bcm6368-pinctrl.yaml +++ b/Documentation/devicetree/bindings/pinctrl/brcm,bcm6368-pinctrl.yaml @@ -42,6 +42,9 @@ patternProperties: gpio24, gpio25, gpio26, gpio27, gpio28, gpio29, gpio30, gpio31, uart1_grp ] +allOf: + - $ref: "pinctrl.yaml#" + required: - compatible - reg diff --git a/Documentation/devicetree/bindings/pinctrl/brcm,ns-pinmux.yaml b/Documentation/devicetree/bindings/pinctrl/brcm,ns-pinmux.yaml index fc39e3e9f71c..8d1e5b1cdd5f 100644 --- a/Documentation/devicetree/bindings/pinctrl/brcm,ns-pinmux.yaml +++ b/Documentation/devicetree/bindings/pinctrl/brcm,ns-pinmux.yaml @@ -53,6 +53,7 @@ patternProperties: additionalProperties: false allOf: + - $ref: "pinctrl.yaml#" - if: properties: compatible: @@ -77,7 +78,7 @@ additionalProperties: false examples: - | - pin-controller@1800c1c0 { + pinctrl@1800c1c0 { compatible = "brcm,bcm4708-pinmux"; reg = <0x1800c1c0 0x24>; reg-names = "cru_gpio_control"; diff --git a/Documentation/devicetree/bindings/pinctrl/canaan,k210-fpioa.yaml b/Documentation/devicetree/bindings/pinctrl/canaan,k210-fpioa.yaml index 46fbc73ab26b..a44691d9c57d 100644 --- a/Documentation/devicetree/bindings/pinctrl/canaan,k210-fpioa.yaml +++ b/Documentation/devicetree/bindings/pinctrl/canaan,k210-fpioa.yaml @@ -137,6 +137,9 @@ patternProperties: additionalProperties: false +allOf: + - $ref: "pinctrl.yaml#" + required: - compatible - reg @@ -151,9 +154,9 @@ examples: #include <dt-bindings/clock/k210-clk.h> #include <dt-bindings/reset/k210-rst.h> - fpioa: pinmux@502B0000 { + fpioa: pinmux@502b0000 { compatible = "canaan,k210-fpioa"; - reg = <0x502B0000 0x100>; + reg = <0x502b0000 0x100>; clocks = <&sysclk K210_CLK_FPIOA>, <&sysclk K210_CLK_APB0>; clock-names = "ref", "pclk"; diff --git a/Documentation/devicetree/bindings/pinctrl/cirrus,lochnagar.yaml b/Documentation/devicetree/bindings/pinctrl/cirrus,lochnagar.yaml index a07dd197176a..5cd512b7d5ba 100644 --- a/Documentation/devicetree/bindings/pinctrl/cirrus,lochnagar.yaml +++ b/Documentation/devicetree/bindings/pinctrl/cirrus,lochnagar.yaml @@ -51,15 +51,6 @@ properties: appropriate of the LOCHNAGARx_PIN_NUM_GPIOS define, see [3]. maxItems: 1 - pinctrl-0: - description: - A phandle to the default pinctrl state. - - pinctrl-names: - description: - A pinctrl state named "default" must be defined. - const: default - pin-settings: type: object patternProperties: @@ -181,6 +172,9 @@ properties: additionalProperties: false +allOf: + - $ref: "pinctrl.yaml#" + required: - compatible - gpio-controller diff --git a/Documentation/devicetree/bindings/pinctrl/cirrus,madera.yaml b/Documentation/devicetree/bindings/pinctrl/cirrus,madera.yaml index 4cb174bf31ff..c85f759ae5a3 100644 --- a/Documentation/devicetree/bindings/pinctrl/cirrus,madera.yaml +++ b/Documentation/devicetree/bindings/pinctrl/cirrus,madera.yaml @@ -30,16 +30,6 @@ description: | Documentation/devicetree/bindings/pinctrl/pinctrl-bindings.txt properties: - pinctrl-0: - description: - A phandle to the node containing the subnodes containing default - configurations. - - pinctrl-names: - description: - A pinctrl state named "default" must be defined. - const: default - pin-settings: description: One subnode is required to contain the default settings. It @@ -117,6 +107,9 @@ properties: additionalProperties: false +allOf: + - $ref: "pinctrl.yaml#" + required: - pinctrl-0 - pinctrl-names diff --git a/Documentation/devicetree/bindings/pinctrl/fsl,imx8mm-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/fsl,imx8mm-pinctrl.yaml index 6d7d162e6171..6717f163390b 100644 --- a/Documentation/devicetree/bindings/pinctrl/fsl,imx8mm-pinctrl.yaml +++ b/Documentation/devicetree/bindings/pinctrl/fsl,imx8mm-pinctrl.yaml @@ -58,6 +58,9 @@ patternProperties: additionalProperties: false +allOf: + - $ref: "pinctrl.yaml#" + required: - compatible - reg diff --git a/Documentation/devicetree/bindings/pinctrl/fsl,imx8mn-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/fsl,imx8mn-pinctrl.yaml index 7131cfd1fc45..b1cdbb56d4e4 100644 --- a/Documentation/devicetree/bindings/pinctrl/fsl,imx8mn-pinctrl.yaml +++ b/Documentation/devicetree/bindings/pinctrl/fsl,imx8mn-pinctrl.yaml @@ -58,6 +58,9 @@ patternProperties: additionalProperties: false +allOf: + - $ref: "pinctrl.yaml#" + required: - compatible - reg diff --git a/Documentation/devicetree/bindings/pinctrl/fsl,imx8mp-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/fsl,imx8mp-pinctrl.yaml index d474bc1f393b..4eed3a4e153a 100644 --- a/Documentation/devicetree/bindings/pinctrl/fsl,imx8mp-pinctrl.yaml +++ b/Documentation/devicetree/bindings/pinctrl/fsl,imx8mp-pinctrl.yaml @@ -58,6 +58,9 @@ patternProperties: additionalProperties: false +allOf: + - $ref: "pinctrl.yaml#" + required: - compatible - reg diff --git a/Documentation/devicetree/bindings/pinctrl/fsl,imx8mq-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/fsl,imx8mq-pinctrl.yaml index 0af2b6c95c17..d4a8ea5551a5 100644 --- a/Documentation/devicetree/bindings/pinctrl/fsl,imx8mq-pinctrl.yaml +++ b/Documentation/devicetree/bindings/pinctrl/fsl,imx8mq-pinctrl.yaml @@ -58,6 +58,9 @@ patternProperties: additionalProperties: false +allOf: + - $ref: "pinctrl.yaml#" + required: - compatible - reg diff --git a/Documentation/devicetree/bindings/pinctrl/fsl,imx8ulp-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/fsl,imx8ulp-pinctrl.yaml index 86622c4f374b..693398d88223 100644 --- a/Documentation/devicetree/bindings/pinctrl/fsl,imx8ulp-pinctrl.yaml +++ b/Documentation/devicetree/bindings/pinctrl/fsl,imx8ulp-pinctrl.yaml @@ -56,6 +56,9 @@ patternProperties: additionalProperties: false +allOf: + - $ref: "pinctrl.yaml#" + required: - compatible - reg diff --git a/Documentation/devicetree/bindings/pinctrl/fsl,imxrt1050.yaml b/Documentation/devicetree/bindings/pinctrl/fsl,imxrt1050.yaml new file mode 100644 index 000000000000..1278f7293560 --- /dev/null +++ b/Documentation/devicetree/bindings/pinctrl/fsl,imxrt1050.yaml @@ -0,0 +1,79 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/pinctrl/fsl,imxrt1050.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Freescale IMXRT1050 IOMUX Controller + +maintainers: + - Giulio Benetti <giulio.benetti@benettiengineering.com> + - Jesse Taube <Mr.Bossman075@gmail.com> + +description: + Please refer to fsl,imx-pinctrl.txt and pinctrl-bindings.txt in this directory + for common binding part and usage. + +properties: + compatible: + const: fsl,imxrt1050-iomuxc + + reg: + maxItems: 1 + +# Client device subnode's properties +patternProperties: + 'grp$': + type: object + description: + Pinctrl node's client devices use subnodes for desired pin configuration. + Client device subnodes use below standard properties. + + properties: + fsl,pins: + description: + each entry consists of 6 integers and represents the mux and config + setting for one pin. The first 5 integers <mux_reg conf_reg input_reg + mux_val input_val> are specified using a PIN_FUNC_ID macro, which can + be found in <include/dt-bindings/pinctrl/pins-imxrt1050.h>. The last + integer CONFIG is the pad setting value like pull-up on this pin. Please + refer to i.MXRT1050 Reference Manual for detailed CONFIG settings. + $ref: /schemas/types.yaml#/definitions/uint32-matrix + items: + items: + - description: | + "mux_reg" indicates the offset of mux register. + - description: | + "conf_reg" indicates the offset of pad configuration register. + - description: | + "input_reg" indicates the offset of select input register. + - description: | + "mux_val" indicates the mux value to be applied. + - description: | + "input_val" indicates the select input value to be applied. + - description: | + "pad_setting" indicates the pad configuration value to be applied. + + required: + - fsl,pins + + additionalProperties: false + +required: + - compatible + - reg + +additionalProperties: false + +examples: + - | + iomuxc: iomuxc@401f8000 { + compatible = "fsl,imxrt1050-iomuxc"; + reg = <0x401f8000 0x4000>; + + pinctrl_lpuart1: lpuart1grp { + fsl,pins = + <0x0EC 0x2DC 0x000 0x2 0x0 0xf1>, + <0x0F0 0x2E0 0x000 0x2 0x0 0xf1>; + }; + }; diff --git a/Documentation/devicetree/bindings/pinctrl/ingenic,pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/ingenic,pinctrl.yaml index a12d0ceb7637..c2c370448b81 100644 --- a/Documentation/devicetree/bindings/pinctrl/ingenic,pinctrl.yaml +++ b/Documentation/devicetree/bindings/pinctrl/ingenic,pinctrl.yaml @@ -28,9 +28,6 @@ maintainers: - Paul Cercueil <paul@crapouillou.net> properties: - nodename: - pattern: "^pinctrl@[0-9a-f]+$" - compatible: oneOf: - enum: @@ -121,6 +118,9 @@ patternProperties: additionalProperties: false +allOf: + - $ref: "pinctrl.yaml#" + required: - compatible - reg @@ -169,7 +169,7 @@ additionalProperties: examples: - | - pin-controller@10010000 { + pinctrl@10010000 { compatible = "ingenic,jz4770-pinctrl"; reg = <0x10010000 0x600>; diff --git a/Documentation/devicetree/bindings/pinctrl/intel,lgm-io.yaml b/Documentation/devicetree/bindings/pinctrl/intel,lgm-io.yaml index 2c0acb405e6c..b42548350188 100644 --- a/Documentation/devicetree/bindings/pinctrl/intel,lgm-io.yaml +++ b/Documentation/devicetree/bindings/pinctrl/intel,lgm-io.yaml @@ -47,6 +47,9 @@ patternProperties: additionalProperties: false +allOf: + - $ref: "pinctrl.yaml#" + required: - compatible - reg diff --git a/Documentation/devicetree/bindings/pinctrl/intel,pinctrl-thunderbay.yaml b/Documentation/devicetree/bindings/pinctrl/intel,pinctrl-thunderbay.yaml new file mode 100644 index 000000000000..0ec476248f21 --- /dev/null +++ b/Documentation/devicetree/bindings/pinctrl/intel,pinctrl-thunderbay.yaml @@ -0,0 +1,119 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/pinctrl/intel,pinctrl-thunderbay.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Intel Thunder Bay pin controller Device Tree Bindings + +maintainers: + - Lakshmi Sowjanya D <lakshmi.sowjanya.d@intel.com> + +description: | + Intel Thunder Bay SoC integrates a pin controller which enables control + of pin directions, input/output values and configuration + for a total of 67 pins. + +properties: + compatible: + const: intel,thunderbay-pinctrl + + reg: + maxItems: 1 + + gpio-controller: true + + '#gpio-cells': + const: 2 + + gpio-ranges: + maxItems: 1 + + interrupts: + description: + Specifies the interrupt lines to be used by the controller. + maxItems: 2 + + interrupt-controller: true + + '#interrupt-cells': + const: 2 + +patternProperties: + '^gpio@[0-9a-f]*$': + type: object + + description: + Child nodes can be specified to contain pin configuration information, + which can then be utilized by pinctrl client devices. + The following properties are supported. + + properties: + pins: + description: | + The name(s) of the pins to be configured in the child node. + Supported pin names are "GPIO0" up to "GPIO66". + + bias-disable: true + + bias-pull-down: true + + bias-pull-up: true + + drive-strength: + description: Drive strength for the pad. + enum: [0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15] + + bias-bus-hold: + type: boolean + + input-schmitt-enable: + type: boolean + + slew-rate: + description: GPIO slew rate control. + 0 - Slow + 1 - Fast + enum: [0, 1] + +additionalProperties: false + +required: + - compatible + - reg + - gpio-controller + - '#gpio-cells' + - gpio-ranges + - interrupts + - interrupt-controller + - '#interrupt-cells' + +examples: + - | + #include <dt-bindings/interrupt-controller/arm-gic.h> + #include <dt-bindings/interrupt-controller/irq.h> + // Example 1 + pinctrl0: gpio@0 { + compatible = "intel,thunderbay-pinctrl"; + reg = <0x600b0000 0x88>; + gpio-controller; + #gpio-cells = <0x2>; + gpio-ranges = <&pinctrl0 0 0 67>; + interrupts = <GIC_SPI 94 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 95 IRQ_TYPE_LEVEL_HIGH>; + interrupt-controller; + #interrupt-cells = <2>; + }; + + // Example 2 + pinctrl1: gpio@1 { + compatible = "intel,thunderbay-pinctrl"; + reg = <0x600c0000 0x88>; + gpio-controller; + #gpio-cells = <0x2>; + gpio-ranges = <&pinctrl1 0 0 53>; + interrupts = <GIC_SPI 94 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 95 IRQ_TYPE_LEVEL_HIGH>; + interrupt-controller; + #interrupt-cells = <2>; + }; diff --git a/Documentation/devicetree/bindings/pinctrl/mediatek,mt65xx-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/mediatek,mt65xx-pinctrl.yaml index f8e6e138dc13..6953c958ff7c 100644 --- a/Documentation/devicetree/bindings/pinctrl/mediatek,mt65xx-pinctrl.yaml +++ b/Documentation/devicetree/bindings/pinctrl/mediatek,mt65xx-pinctrl.yaml @@ -64,6 +64,9 @@ required: - gpio-controller - "#gpio-cells" +allOf: + - $ref: "pinctrl.yaml#" + patternProperties: '-[0-9]+$': type: object diff --git a/Documentation/devicetree/bindings/pinctrl/mediatek,mt6779-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/mediatek,mt6779-pinctrl.yaml index 152c151c27ad..e7601c0f5a69 100644 --- a/Documentation/devicetree/bindings/pinctrl/mediatek,mt6779-pinctrl.yaml +++ b/Documentation/devicetree/bindings/pinctrl/mediatek,mt6779-pinctrl.yaml @@ -59,6 +59,9 @@ properties: "#interrupt-cells": const: 2 +allOf: + - $ref: "pinctrl.yaml#" + required: - compatible - reg diff --git a/Documentation/devicetree/bindings/pinctrl/mediatek,mt6797-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/mediatek,mt6797-pinctrl.yaml index 76a6df75ed9c..d42215f59afd 100644 --- a/Documentation/devicetree/bindings/pinctrl/mediatek,mt6797-pinctrl.yaml +++ b/Documentation/devicetree/bindings/pinctrl/mediatek,mt6797-pinctrl.yaml @@ -45,6 +45,9 @@ properties: "#interrupt-cells": const: 2 +allOf: + - $ref: "pinctrl.yaml#" + required: - compatible - reg diff --git a/Documentation/devicetree/bindings/pinctrl/mediatek,mt7622-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/mediatek,mt7622-pinctrl.yaml index 0feecd376c69..78a0175cecc7 100644 --- a/Documentation/devicetree/bindings/pinctrl/mediatek,mt7622-pinctrl.yaml +++ b/Documentation/devicetree/bindings/pinctrl/mediatek,mt7622-pinctrl.yaml @@ -42,6 +42,9 @@ properties: "#interrupt-cells": const: 2 +allOf: + - $ref: "pinctrl.yaml#" + required: - compatible - reg diff --git a/Documentation/devicetree/bindings/pinctrl/mediatek,mt7986-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/mediatek,mt7986-pinctrl.yaml index 7602b11e8bce..4eadea55df10 100644 --- a/Documentation/devicetree/bindings/pinctrl/mediatek,mt7986-pinctrl.yaml +++ b/Documentation/devicetree/bindings/pinctrl/mediatek,mt7986-pinctrl.yaml @@ -56,6 +56,9 @@ properties: "#interrupt-cells": const: 2 +allOf: + - $ref: "pinctrl.yaml#" + required: - compatible - reg diff --git a/Documentation/devicetree/bindings/pinctrl/mediatek,mt8183-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/mediatek,mt8183-pinctrl.yaml index cc1509e9b981..2d13a57b8961 100644 --- a/Documentation/devicetree/bindings/pinctrl/mediatek,mt8183-pinctrl.yaml +++ b/Documentation/devicetree/bindings/pinctrl/mediatek,mt8183-pinctrl.yaml @@ -56,6 +56,9 @@ properties: "#interrupt-cells": const: 2 +allOf: + - $ref: "pinctrl.yaml#" + required: - compatible - reg diff --git a/Documentation/devicetree/bindings/pinctrl/mscc,ocelot-pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/mscc,ocelot-pinctrl.txt index db99bd95d423..3bb76487669f 100644 --- a/Documentation/devicetree/bindings/pinctrl/mscc,ocelot-pinctrl.txt +++ b/Documentation/devicetree/bindings/pinctrl/mscc,ocelot-pinctrl.txt @@ -4,7 +4,8 @@ Microsemi Ocelot pin controller Device Tree Bindings Required properties: - compatible : Should be "mscc,ocelot-pinctrl", "mscc,jaguar2-pinctrl", "microchip,sparx5-pinctrl", - "mscc,luton-pinctrl" or "mscc,serval-pinctrl" + "mscc,luton-pinctrl", "mscc,serval-pinctrl" or + "microchip,lan966x-pinctrl" - reg : Address and length of the register set for the device - gpio-controller : Indicates this device is a GPIO controller - #gpio-cells : Must be 2. diff --git a/Documentation/devicetree/bindings/pinctrl/pincfg-node.yaml b/Documentation/devicetree/bindings/pinctrl/pincfg-node.yaml index 71ed0a9def84..4b22a9e3a447 100644 --- a/Documentation/devicetree/bindings/pinctrl/pincfg-node.yaml +++ b/Documentation/devicetree/bindings/pinctrl/pincfg-node.yaml @@ -114,6 +114,9 @@ properties: description: enable output on a pin without actively driving it (such as enabling an output buffer) + output-impedance-ohms: + description: set the output impedance of a pin to at most X ohms + output-low: type: boolean description: set the pin to output mode with low level diff --git a/Documentation/devicetree/bindings/pinctrl/pinctrl-bindings.txt b/Documentation/devicetree/bindings/pinctrl/pinctrl-bindings.txt index 9dae60acf950..6904072d3944 100644 --- a/Documentation/devicetree/bindings/pinctrl/pinctrl-bindings.txt +++ b/Documentation/devicetree/bindings/pinctrl/pinctrl-bindings.txt @@ -97,47 +97,8 @@ For example: }; == Pin controller devices == -Required properties: See the pin controller driver specific documentation -Optional properties: -#pinctrl-cells: Number of pin control cells in addition to the index within the - pin controller device instance - -pinctrl-use-default: Boolean. Indicates that the OS can use the boot default - pin configuration. This allows using an OS that does not have a - driver for the pin controller. This property can be set either - globally for the pin controller or in child nodes for individual - pin group control. - -Pin controller devices should contain the pin configuration nodes that client -devices reference. - -For example: - - pincontroller { - ... /* Standard DT properties for the device itself elided */ - - state_0_node_a { - ... - }; - state_1_node_a { - ... - }; - state_1_node_b { - ... - }; - } - -The contents of each of those pin configuration child nodes is defined -entirely by the binding for the individual pin controller device. There -exists no common standard for this content. The pinctrl framework only -provides generic helper bindings that the pin controller driver can use. - -The pin configuration nodes need not be direct children of the pin controller -device; they may be grandchildren, for example. Whether this is legal, and -whether there is any interaction between the child and intermediate parent -nodes, is again defined entirely by the binding for the individual pin -controller device. +See pinctrl.yaml == Generic pin multiplexing node content == diff --git a/Documentation/devicetree/bindings/pinctrl/pinctrl-mt8192.yaml b/Documentation/devicetree/bindings/pinctrl/pinctrl-mt8192.yaml index c4c071211611..3c84676a167d 100644 --- a/Documentation/devicetree/bindings/pinctrl/pinctrl-mt8192.yaml +++ b/Documentation/devicetree/bindings/pinctrl/pinctrl-mt8192.yaml @@ -108,6 +108,9 @@ patternProperties: additionalProperties: false +allOf: + - $ref: "pinctrl.yaml#" + required: - compatible - reg diff --git a/Documentation/devicetree/bindings/pinctrl/pinctrl-mt8195.yaml b/Documentation/devicetree/bindings/pinctrl/pinctrl-mt8195.yaml index 5e2bb2bf3a55..328ea59c5466 100644 --- a/Documentation/devicetree/bindings/pinctrl/pinctrl-mt8195.yaml +++ b/Documentation/devicetree/bindings/pinctrl/pinctrl-mt8195.yaml @@ -55,137 +55,162 @@ properties: Identifying i2c pins pull up/down type which is RSEL. It can support RSEL define or si unit value(ohm) to set different resistance. -#PIN CONFIGURATION NODES +# PIN CONFIGURATION NODES patternProperties: '-pins$': type: object - description: | - A pinctrl node should contain at least one subnodes representing the - pinctrl groups available on the machine. Each subnode will list the - pins it needs, and how they should be configured, with regard to muxer - configuration, pullups, drive strength, input enable/disable and - input schmitt. - An example of using macro: - pincontroller { - /* GPIO0 set as multifunction GPIO0 */ - gpio_pin { - pinmux = <PINMUX_GPIO0__FUNC_GPIO0>; - }; - /* GPIO8 set as multifunction SDA0 */ - i2c0_pin { - pinmux = <PINMUX_GPIO8__FUNC_SDA0>; - }; - }; - $ref: "pinmux-node.yaml" - - properties: - pinmux: - description: | - Integer array, represents gpio pin number and mux setting. - Supported pin number and mux varies for different SoCs, and are defined - as macros in dt-bindings/pinctrl/<soc>-pinfunc.h directly. - - drive-strength: - enum: [2, 4, 6, 8, 10, 12, 14, 16] - - bias-pull-down: - description: | - For pull down type is normal, it don't need add RSEL & R1R0 define - and resistance value. - For pull down type is PUPD/R0/R1 type, it can add R1R0 define to - set different resistance. It can support "MTK_PUPD_SET_R1R0_00" & - "MTK_PUPD_SET_R1R0_01" & "MTK_PUPD_SET_R1R0_10" & "MTK_PUPD_SET_R1R0_11" - define in mt8195. - For pull down type is RSEL, it can add RSEL define & resistance value(ohm) - to set different resistance by identifying property "mediatek,rsel_resistance_in_si_unit". - It can support "MTK_PULL_SET_RSEL_000" & "MTK_PULL_SET_RSEL_001" - & "MTK_PULL_SET_RSEL_010" & "MTK_PULL_SET_RSEL_011" & "MTK_PULL_SET_RSEL_100" - & "MTK_PULL_SET_RSEL_101" & "MTK_PULL_SET_RSEL_110" & "MTK_PULL_SET_RSEL_111" - define in mt8195. It can also support resistance value(ohm) "75000" & "5000" in mt8195. - oneOf: - - enum: [100, 101, 102, 103] - - description: mt8195 pull down PUPD/R0/R1 type define value. - - enum: [200, 201, 202, 203, 204, 205, 206, 207] - - description: mt8195 pull down RSEL type define value. - - enum: [75000, 5000] - - description: mt8195 pull down RSEL type si unit value(ohm). - - An example of using RSEL define: - pincontroller { - i2c0_pin { - pinmux = <PINMUX_GPIO8__FUNC_SDA0>; - bias-pull-down = <MTK_PULL_SET_RSEL_001>; - }; - }; - An example of using si unit resistance value(ohm): - &pio { - mediatek,rsel_resistance_in_si_unit; - } - pincontroller { - i2c0_pin { - pinmux = <PINMUX_GPIO8__FUNC_SDA0>; - bias-pull-down = <75000>; - }; - }; - - bias-pull-up: + additionalProperties: false + patternProperties: + '^pins': + type: object + additionalProperties: false description: | - For pull up type is normal, it don't need add RSEL & R1R0 define - and resistance value. - For pull up type is PUPD/R0/R1 type, it can add R1R0 define to - set different resistance. It can support "MTK_PUPD_SET_R1R0_00" & - "MTK_PUPD_SET_R1R0_01" & "MTK_PUPD_SET_R1R0_10" & "MTK_PUPD_SET_R1R0_11" - define in mt8195. - For pull up type is RSEL, it can add RSEL define & resistance value(ohm) - to set different resistance by identifying property "mediatek,rsel_resistance_in_si_unit". - It can support "MTK_PULL_SET_RSEL_000" & "MTK_PULL_SET_RSEL_001" - & "MTK_PULL_SET_RSEL_010" & "MTK_PULL_SET_RSEL_011" & "MTK_PULL_SET_RSEL_100" - & "MTK_PULL_SET_RSEL_101" & "MTK_PULL_SET_RSEL_110" & "MTK_PULL_SET_RSEL_111" - define in mt8195. It can also support resistance value(ohm) - "1000" & "1500" & "2000" & "3000" & "4000" & "5000" & "10000" & "75000" in mt8195. - oneOf: - - enum: [100, 101, 102, 103] - - description: mt8195 pull up PUPD/R0/R1 type define value. - - enum: [200, 201, 202, 203, 204, 205, 206, 207] - - description: mt8195 pull up RSEL type define value. - - enum: [1000, 1500, 2000, 3000, 4000, 5000, 10000, 75000] - - description: mt8195 pull up RSEL type si unit value(ohm). - An example of using RSEL define: + A pinctrl node should contain at least one subnodes representing the + pinctrl groups available on the machine. Each subnode will list the + pins it needs, and how they should be configured, with regard to muxer + configuration, pullups, drive strength, input enable/disable and + input schmitt. + An example of using macro: pincontroller { - i2c0_pin { - pinmux = <PINMUX_GPIO8__FUNC_SDA0>; - bias-pull-up = <MTK_PULL_SET_RSEL_001>; + /* GPIO0 set as multifunction GPIO0 */ + gpio-pins { + pins { + pinmux = <PINMUX_GPIO0__FUNC_GPIO0>; + } }; - }; - An example of using si unit resistance value(ohm): - &pio { - mediatek,rsel_resistance_in_si_unit; - } - pincontroller { - i2c0_pin { - pinmux = <PINMUX_GPIO8__FUNC_SDA0>; - bias-pull-up = <1000>; + /* GPIO8 set as multifunction SDA0 */ + i2c0-pins { + pins { + pinmux = <PINMUX_GPIO8__FUNC_SDA0>; + } }; }; - - bias-disable: true - - output-high: true - - output-low: true - - input-enable: true - - input-disable: true - - input-schmitt-enable: true - - input-schmitt-disable: true - - required: - - pinmux - - additionalProperties: false + $ref: "pinmux-node.yaml" + + properties: + pinmux: + description: | + Integer array, represents gpio pin number and mux setting. + Supported pin number and mux varies for different SoCs, and are + defined as macros in dt-bindings/pinctrl/<soc>-pinfunc.h + directly. + + drive-strength: + enum: [2, 4, 6, 8, 10, 12, 14, 16] + + bias-pull-down: + description: | + For pull down type is normal, it don't need add RSEL & R1R0 define + and resistance value. + For pull down type is PUPD/R0/R1 type, it can add R1R0 define to + set different resistance. It can support "MTK_PUPD_SET_R1R0_00" & + "MTK_PUPD_SET_R1R0_01" & "MTK_PUPD_SET_R1R0_10" & + "MTK_PUPD_SET_R1R0_11" define in mt8195. + For pull down type is RSEL, it can add RSEL define & resistance + value(ohm) to set different resistance by identifying property + "mediatek,rsel_resistance_in_si_unit". + It can support "MTK_PULL_SET_RSEL_000" & "MTK_PULL_SET_RSEL_001" + & "MTK_PULL_SET_RSEL_010" & "MTK_PULL_SET_RSEL_011" + & "MTK_PULL_SET_RSEL_100" & "MTK_PULL_SET_RSEL_101" + & "MTK_PULL_SET_RSEL_110" & "MTK_PULL_SET_RSEL_111" + define in mt8195. It can also support resistance value(ohm) + "75000" & "5000" in mt8195. + oneOf: + - enum: [100, 101, 102, 103] + - description: mt8195 pull down PUPD/R0/R1 type define value. + - enum: [200, 201, 202, 203, 204, 205, 206, 207] + - description: mt8195 pull down RSEL type define value. + - enum: [75000, 5000] + - description: mt8195 pull down RSEL type si unit value(ohm). + + An example of using RSEL define: + pincontroller { + i2c0_pin { + pins { + pinmux = <PINMUX_GPIO8__FUNC_SDA0>; + bias-pull-down = <MTK_PULL_SET_RSEL_001>; + } + }; + }; + An example of using si unit resistance value(ohm): + &pio { + mediatek,rsel_resistance_in_si_unit; + } + pincontroller { + i2c0_pin { + pins { + pinmux = <PINMUX_GPIO8__FUNC_SDA0>; + bias-pull-down = <75000>; + } + }; + }; + + bias-pull-up: + description: | + For pull up type is normal, it don't need add RSEL & R1R0 define + and resistance value. + For pull up type is PUPD/R0/R1 type, it can add R1R0 define to + set different resistance. It can support "MTK_PUPD_SET_R1R0_00" & + "MTK_PUPD_SET_R1R0_01" & "MTK_PUPD_SET_R1R0_10" & + "MTK_PUPD_SET_R1R0_11" define in mt8195. + For pull up type is RSEL, it can add RSEL define & resistance + value(ohm) to set different resistance by identifying property + "mediatek,rsel_resistance_in_si_unit". + It can support "MTK_PULL_SET_RSEL_000" & "MTK_PULL_SET_RSEL_001" + & "MTK_PULL_SET_RSEL_010" & "MTK_PULL_SET_RSEL_011" + & "MTK_PULL_SET_RSEL_100" & "MTK_PULL_SET_RSEL_101" + & "MTK_PULL_SET_RSEL_110" & "MTK_PULL_SET_RSEL_111" + define in mt8195. It can also support resistance value(ohm) + "1000" & "1500" & "2000" & "3000" & "4000" & "5000" & "10000" & + "75000" in mt8195. + oneOf: + - enum: [100, 101, 102, 103] + - description: mt8195 pull up PUPD/R0/R1 type define value. + - enum: [200, 201, 202, 203, 204, 205, 206, 207] + - description: mt8195 pull up RSEL type define value. + - enum: [1000, 1500, 2000, 3000, 4000, 5000, 10000, 75000] + - description: mt8195 pull up RSEL type si unit value(ohm). + An example of using RSEL define: + pincontroller { + i2c0-pins { + pins { + pinmux = <PINMUX_GPIO8__FUNC_SDA0>; + bias-pull-up = <MTK_PULL_SET_RSEL_001>; + } + }; + }; + An example of using si unit resistance value(ohm): + &pio { + mediatek,rsel_resistance_in_si_unit; + } + pincontroller { + i2c0-pins { + pins { + pinmux = <PINMUX_GPIO8__FUNC_SDA0>; + bias-pull-up = <1000>; + } + }; + }; + + bias-disable: true + + output-high: true + + output-low: true + + input-enable: true + + input-disable: true + + input-schmitt-enable: true + + input-schmitt-disable: true + + required: + - pinmux + +allOf: + - $ref: "pinctrl.yaml#" required: - compatible @@ -201,30 +226,46 @@ additionalProperties: false examples: - | - #include <dt-bindings/pinctrl/mt8195-pinfunc.h> - #include <dt-bindings/interrupt-controller/arm-gic.h> - pio: pinctrl@10005000 { - compatible = "mediatek,mt8195-pinctrl"; - reg = <0x10005000 0x1000>, - <0x11d10000 0x1000>, - <0x11d30000 0x1000>, - <0x11d40000 0x1000>, - <0x11e20000 0x1000>, - <0x11eb0000 0x1000>, - <0x11f40000 0x1000>, - <0x1000b000 0x1000>; - reg-names = "iocfg0", "iocfg_bm", "iocfg_bl", - "iocfg_br", "iocfg_lm", "iocfg_rb", - "iocfg_tl", "eint"; - gpio-controller; - #gpio-cells = <2>; - gpio-ranges = <&pio 0 0 144>; - interrupt-controller; - interrupts = <GIC_SPI 225 IRQ_TYPE_LEVEL_HIGH 0>; - #interrupt-cells = <2>; - - pio-pins { - pinmux = <PINMUX_GPIO0__FUNC_GPIO0>; - output-low; - }; - }; + #include <dt-bindings/pinctrl/mt8195-pinfunc.h> + #include <dt-bindings/interrupt-controller/arm-gic.h> + # + pio: pinctrl@10005000 { + compatible = "mediatek,mt8195-pinctrl"; + reg = <0x10005000 0x1000>, + <0x11d10000 0x1000>, + <0x11d30000 0x1000>, + <0x11d40000 0x1000>, + <0x11e20000 0x1000>, + <0x11eb0000 0x1000>, + <0x11f40000 0x1000>, + <0x1000b000 0x1000>; + reg-names = "iocfg0", "iocfg_bm", "iocfg_bl", + "iocfg_br", "iocfg_lm", "iocfg_rb", + "iocfg_tl", "eint"; + gpio-controller; + #gpio-cells = <2>; + gpio-ranges = <&pio 0 0 144>; + interrupt-controller; + interrupts = <GIC_SPI 225 IRQ_TYPE_LEVEL_HIGH 0>; + #interrupt-cells = <2>; + + pio-pins { + pins { + pinmux = <PINMUX_GPIO0__FUNC_GPIO0>; + output-low; + }; + }; + + spi0-pins { + pins-spi { + pinmux = <PINMUX_GPIO132__FUNC_SPIM0_CSB>, + <PINMUX_GPIO134__FUNC_SPIM0_MO>, + <PINMUX_GPIO133__FUNC_SPIM0_CLK>; + bias-disable; + }; + pins-spi-mi { + pinmux = <PINMUX_GPIO135__FUNC_SPIM0_MI>; + bias-pull-down; + }; + }; + }; diff --git a/Documentation/devicetree/bindings/pinctrl/pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/pinctrl.yaml new file mode 100644 index 000000000000..d471563119a9 --- /dev/null +++ b/Documentation/devicetree/bindings/pinctrl/pinctrl.yaml @@ -0,0 +1,45 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/pinctrl/pinctrl.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Pin controller device + +maintainers: + - Linus Walleij <linus.walleij@linaro.org> + - Rafał Miłecki <rafal@milecki.pl> + +description: | + Pin controller devices should contain the pin configuration nodes that client + devices reference. + + The contents of each of those pin configuration child nodes is defined + entirely by the binding for the individual pin controller device. There + exists no common standard for this content. The pinctrl framework only + provides generic helper bindings that the pin controller driver can use. + + The pin configuration nodes need not be direct children of the pin controller + device; they may be grandchildren, for example. Whether this is legal, and + whether there is any interaction between the child and intermediate parent + nodes, is again defined entirely by the binding for the individual pin + controller device. + +properties: + $nodename: + pattern: "^(pinctrl|pinmux)(@[0-9a-f]+)?$" + + "#pinctrl-cells": + description: > + Number of pin control cells in addition to the index within the pin + controller device instance. + + pinctrl-use-default: + type: boolean + description: > + Indicates that the OS can use the boot default pin configuration. This + allows using an OS that does not have a driver for the pin controller. + This property can be set either globally for the pin controller or in + child nodes for individual pin group control. + +additionalProperties: true diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,ipq6018-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/qcom,ipq6018-pinctrl.yaml index c64c93206817..b83c7f476e19 100644 --- a/Documentation/devicetree/bindings/pinctrl/qcom,ipq6018-pinctrl.yaml +++ b/Documentation/devicetree/bindings/pinctrl/qcom,ipq6018-pinctrl.yaml @@ -118,6 +118,9 @@ patternProperties: additionalProperties: false +allOf: + - $ref: "pinctrl.yaml#" + required: - compatible - reg diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,lpass-lpi-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/qcom,lpass-lpi-pinctrl.yaml index e47ebf934daf..5c5542f1627c 100644 --- a/Documentation/devicetree/bindings/pinctrl/qcom,lpass-lpi-pinctrl.yaml +++ b/Documentation/devicetree/bindings/pinctrl/qcom,lpass-lpi-pinctrl.yaml @@ -103,6 +103,9 @@ patternProperties: additionalProperties: false +allOf: + - $ref: "pinctrl.yaml#" + required: - compatible - reg diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,mdm9607-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/qcom,mdm9607-pinctrl.yaml index 3b02dc6626ed..f7bd4be1739e 100644 --- a/Documentation/devicetree/bindings/pinctrl/qcom,mdm9607-pinctrl.yaml +++ b/Documentation/devicetree/bindings/pinctrl/qcom,mdm9607-pinctrl.yaml @@ -14,6 +14,7 @@ description: | MDM9607 platform. allOf: + - $ref: "pinctrl.yaml#" - $ref: /schemas/pinctrl/qcom,tlmm-common.yaml# properties: diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,msm8226-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/qcom,msm8226-pinctrl.yaml index 040d2ada3669..ab4a2b4cfda2 100644 --- a/Documentation/devicetree/bindings/pinctrl/qcom,msm8226-pinctrl.yaml +++ b/Documentation/devicetree/bindings/pinctrl/qcom,msm8226-pinctrl.yaml @@ -97,6 +97,9 @@ patternProperties: additionalProperties: false +allOf: + - $ref: "pinctrl.yaml#" + required: - compatible - reg diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,msm8953-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/qcom,msm8953-pinctrl.yaml index abe9f4c9b1e3..64c0a41ca0c3 100644 --- a/Documentation/devicetree/bindings/pinctrl/qcom,msm8953-pinctrl.yaml +++ b/Documentation/devicetree/bindings/pinctrl/qcom,msm8953-pinctrl.yaml @@ -133,6 +133,9 @@ patternProperties: additionalProperties: false +allOf: + - $ref: "pinctrl.yaml#" + required: - compatible - reg diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,pmic-gpio.yaml b/Documentation/devicetree/bindings/pinctrl/qcom,pmic-gpio.yaml index 8952b4cc1262..9400b665a46f 100644 --- a/Documentation/devicetree/bindings/pinctrl/qcom,pmic-gpio.yaml +++ b/Documentation/devicetree/bindings/pinctrl/qcom,pmic-gpio.yaml @@ -17,6 +17,7 @@ properties: compatible: items: - enum: + - qcom,pm2250-gpio - qcom,pm660-gpio - qcom,pm660l-gpio - qcom,pm6150-gpio @@ -26,10 +27,12 @@ properties: - qcom,pm8005-gpio - qcom,pm8008-gpio - qcom,pm8018-gpio + - qcom,pm8019-gpio - qcom,pm8038-gpio - qcom,pm8058-gpio - qcom,pm8150-gpio - qcom,pm8150b-gpio + - qcom,pm8226-gpio - qcom,pm8350-gpio - qcom,pm8350b-gpio - qcom,pm8350c-gpio diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,qcm2290-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/qcom,qcm2290-pinctrl.yaml index 13f338619d77..206f4f238736 100644 --- a/Documentation/devicetree/bindings/pinctrl/qcom,qcm2290-pinctrl.yaml +++ b/Documentation/devicetree/bindings/pinctrl/qcom,qcm2290-pinctrl.yaml @@ -118,6 +118,9 @@ patternProperties: additionalProperties: false +allOf: + - $ref: "pinctrl.yaml#" + required: - compatible - reg diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,sc7280-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/qcom,sc7280-pinctrl.yaml index 7d6a2ab10eec..6c7c3f6a140e 100644 --- a/Documentation/devicetree/bindings/pinctrl/qcom,sc7280-pinctrl.yaml +++ b/Documentation/devicetree/bindings/pinctrl/qcom,sc7280-pinctrl.yaml @@ -123,6 +123,9 @@ patternProperties: additionalProperties: false +allOf: + - $ref: "pinctrl.yaml#" + required: - compatible - reg diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,sc8180x-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/qcom,sc8180x-pinctrl.yaml index a82dab898395..86509172603d 100644 --- a/Documentation/devicetree/bindings/pinctrl/qcom,sc8180x-pinctrl.yaml +++ b/Documentation/devicetree/bindings/pinctrl/qcom,sc8180x-pinctrl.yaml @@ -14,6 +14,7 @@ description: | SC8180X platform. allOf: + - $ref: "pinctrl.yaml#" - $ref: /schemas/pinctrl/qcom,tlmm-common.yaml# properties: diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,sdx55-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/qcom,sdx55-pinctrl.yaml index 112dd59ce7ed..a38090b14aab 100644 --- a/Documentation/devicetree/bindings/pinctrl/qcom,sdx55-pinctrl.yaml +++ b/Documentation/devicetree/bindings/pinctrl/qcom,sdx55-pinctrl.yaml @@ -118,6 +118,9 @@ patternProperties: additionalProperties: false +allOf: + - $ref: "pinctrl.yaml#" + required: - compatible - reg diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,sdx65-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/qcom,sdx65-pinctrl.yaml new file mode 100644 index 000000000000..cdfcf29dffee --- /dev/null +++ b/Documentation/devicetree/bindings/pinctrl/qcom,sdx65-pinctrl.yaml @@ -0,0 +1,191 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/pinctrl/qcom,sdx65-pinctrl.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Qualcomm Technologies, Inc. SDX65 TLMM block + +maintainers: + - Vamsi krishna Lanka <quic_vamslank@quicinc.com> + +description: + This binding describes the Top Level Mode Multiplexer block found in the + SDX65 platform. + +properties: + compatible: + const: qcom,sdx65-tlmm + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + interrupt-controller: true + + '#interrupt-cells': + description: Specifies the PIN numbers and Flags, as defined in + include/dt-bindings/interrupt-controller/irq.h + const: 2 + + gpio-controller: true + + '#gpio-cells': + description: Specifying the pin number and flags, as defined in + include/dt-bindings/gpio/gpio.h + const: 2 + + gpio-ranges: + maxItems: 1 + + gpio-reserved-ranges: + maxItems: 1 + +#PIN CONFIGURATION NODES +patternProperties: + '-state$': + oneOf: + - $ref: "#/$defs/qcom-sdx65-tlmm-state" + - patternProperties: + ".*": + $ref: "#/$defs/qcom-sdx65-tlmm-state" +'$defs': + qcom-sdx65-tlmm-state: + type: object + description: + Pinctrl node's client devices use subnodes for desired pin configuration. + Client device subnodes use below standard properties. + $ref: "qcom,tlmm-common.yaml#/$defs/qcom-tlmm-state" + + properties: + pins: + description: + List of gpio pins affected by the properties specified in this subnode. + items: + oneOf: + - pattern: "^gpio([0-9]|[1-9][0-9]|10[0-7])$" + - enum: [ ufs_reset, sdc1_clk, sdc1_cmd, sdc1_data, sdc2_clk, sdc2_cmd, sdc2_data, sdc1_rclk ] + minItems: 1 + maxItems: 150 + + function: + description: + Specify the alternative function to be configured for the specified + pins. Functions are only valid for gpio pins. + enum: [ blsp_uart1, blsp_spi1, blsp_i2c1, blsp_uim1, atest_tsens, + bimc_dte1, dac_calib0, blsp_spi8, blsp_uart8, blsp_uim8, + qdss_cti_trig_out_b, bimc_dte0, dac_calib1, qdss_cti_trig_in_b, + dac_calib2, atest_tsens2, atest_usb1, blsp_spi10, blsp_uart10, + blsp_uim10, atest_bbrx1, atest_usb13, atest_bbrx0, atest_usb12, + mdp_vsync, edp_lcd, blsp_i2c10, atest_gpsadc1, atest_usb11, + atest_gpsadc0, edp_hot, atest_usb10, m_voc, dac_gpio, atest_char, + cam_mclk, pll_bypassnl, qdss_stm7, blsp_i2c8, qdss_tracedata_b, + pll_reset, qdss_stm6, qdss_stm5, qdss_stm4, atest_usb2, cci_i2c, + qdss_stm3, dac_calib3, atest_usb23, atest_char3, dac_calib4, + qdss_stm2, atest_usb22, atest_char2, qdss_stm1, dac_calib5, + atest_usb21, atest_char1, dbg_out, qdss_stm0, dac_calib6, + atest_usb20, atest_char0, dac_calib10, qdss_stm10, + qdss_cti_trig_in_a, cci_timer4, blsp_spi6, blsp_uart6, blsp_uim6, + blsp2_spi, qdss_stm9, qdss_cti_trig_out_a, dac_calib11, + qdss_stm8, cci_timer0, qdss_stm13, dac_calib7, cci_timer1, + qdss_stm12, dac_calib8, cci_timer2, blsp1_spi, qdss_stm11, + dac_calib9, cci_timer3, cci_async, dac_calib12, blsp_i2c6, + qdss_tracectl_a, dac_calib13, qdss_traceclk_a, dac_calib14, + dac_calib15, hdmi_rcv, dac_calib16, hdmi_cec, pwr_modem, + dac_calib17, hdmi_ddc, pwr_nav, dac_calib18, pwr_crypto, + dac_calib19, hdmi_hot, dac_calib20, dac_calib21, pci_e0, + dac_calib22, dac_calib23, dac_calib24, tsif1_sync, dac_calib25, + sd_write, tsif1_error, blsp_spi2, blsp_uart2, blsp_uim2, + qdss_cti, blsp_i2c2, blsp_spi3, blsp_uart3, blsp_uim3, blsp_i2c3, + uim3, blsp_spi9, blsp_uart9, blsp_uim9, blsp10_spi, blsp_i2c9, + blsp_spi7, blsp_uart7, blsp_uim7, qdss_tracedata_a, blsp_i2c7, + qua_mi2s, gcc_gp1_clk_a, ssc_irq, uim4, blsp_spi11, blsp_uart11, + blsp_uim11, gcc_gp2_clk_a, gcc_gp3_clk_a, blsp_i2c11, cri_trng0, + cri_trng1, cri_trng, qdss_stm18, pri_mi2s, qdss_stm17, blsp_spi4, + blsp_uart4, blsp_uim4, qdss_stm16, qdss_stm15, blsp_i2c4, + qdss_stm14, dac_calib26, spkr_i2s, audio_ref, lpass_slimbus, + isense_dbg, tsense_pwm1, tsense_pwm2, btfm_slimbus, ter_mi2s, + qdss_stm22, qdss_stm21, qdss_stm20, qdss_stm19, gcc_gp1_clk_b, + sec_mi2s, blsp_spi5, blsp_uart5, blsp_uim5, gcc_gp2_clk_b, + gcc_gp3_clk_b, blsp_i2c5, blsp_spi12, blsp_uart12, blsp_uim12, + qdss_stm25, qdss_stm31, blsp_i2c12, qdss_stm30, qdss_stm29, + tsif1_clk, qdss_stm28, tsif1_en, tsif1_data, sdc4_cmd, qdss_stm27, + qdss_traceclk_b, tsif2_error, sdc43, vfr_1, qdss_stm26, tsif2_clk, + sdc4_clk, qdss_stm24, tsif2_en, sdc42, qdss_stm23, qdss_tracectl_b, + sd_card, tsif2_data, sdc41, tsif2_sync, sdc40, mdp_vsync_p_b, + ldo_en, mdp_vsync_s_b, ldo_update, blsp11_uart_tx_b, blsp11_uart_rx_b, + blsp11_i2c_sda_b, prng_rosc, blsp11_i2c_scl_b, uim2, uim1, uim_batt, + pci_e2, pa_indicator, adsp_ext, ddr_bist, qdss_tracedata_11, + qdss_tracedata_12, modem_tsync, nav_dr, nav_pps, pci_e1, gsm_tx, + qspi_cs, ssbi2, ssbi1, mss_lte, qspi_clk, qspi0, qspi1, qspi2, qspi3, + gpio ] + + drive-strength: + enum: [2, 4, 6, 8, 10, 12, 14, 16] + default: 2 + description: + Selects the drive strength for the specified pins, in mA. + + bias-pull-down: true + + bias-pull-up: true + + bias-disable: true + + output-high: true + + output-low: true + + required: + - pins + - function + + additionalProperties: false + +required: + - compatible + - reg + - interrupts + - interrupt-controller + - '#interrupt-cells' + - gpio-controller + - '#gpio-cells' + - gpio-ranges + +additionalProperties: false + +examples: + - | + #include <dt-bindings/interrupt-controller/arm-gic.h> + tlmm: pinctrl@f100000 { + compatible = "qcom,sdx65-tlmm"; + reg = <0x03000000 0xdc2000>; + gpio-controller; + #gpio-cells = <2>; + gpio-ranges = <&tlmm 0 0 109>; + interrupt-controller; + #interrupt-cells = <2>; + interrupts = <GIC_SPI 212 IRQ_TYPE_LEVEL_HIGH>; + + gpio-wo-subnode-state { + pins = "gpio1"; + function = "gpio"; + }; + + uart-w-subnodes-state { + rx { + pins = "gpio4"; + function = "blsp_uart1"; + bias-pull-up; + }; + + tx { + pins = "gpio5"; + function = "blsp_uart1"; + bias-disable; + }; + }; + }; +... diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,sm6115-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/qcom,sm6115-pinctrl.yaml index 8fc06f6a3ef4..cfcde405d30a 100644 --- a/Documentation/devicetree/bindings/pinctrl/qcom,sm6115-pinctrl.yaml +++ b/Documentation/devicetree/bindings/pinctrl/qcom,sm6115-pinctrl.yaml @@ -121,6 +121,9 @@ patternProperties: additionalProperties: false +allOf: + - $ref: "pinctrl.yaml#" + required: - compatible - reg diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,sm6125-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/qcom,sm6125-pinctrl.yaml index 5f7adaa81f83..c8eec845ade9 100644 --- a/Documentation/devicetree/bindings/pinctrl/qcom,sm6125-pinctrl.yaml +++ b/Documentation/devicetree/bindings/pinctrl/qcom,sm6125-pinctrl.yaml @@ -13,6 +13,7 @@ description: | in the SM6125 platform. allOf: + - $ref: "pinctrl.yaml#" - $ref: /schemas/pinctrl/qcom,tlmm-common.yaml# properties: diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,sm6350-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/qcom,sm6350-pinctrl.yaml index 554992a681f3..898608671c4b 100644 --- a/Documentation/devicetree/bindings/pinctrl/qcom,sm6350-pinctrl.yaml +++ b/Documentation/devicetree/bindings/pinctrl/qcom,sm6350-pinctrl.yaml @@ -14,6 +14,7 @@ description: | in the SM6350 platform. allOf: + - $ref: "pinctrl.yaml#" - $ref: /schemas/pinctrl/qcom,tlmm-common.yaml# properties: diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,sm8250-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/qcom,sm8250-pinctrl.yaml index 8508c57522fd..cfa2c50fdb93 100644 --- a/Documentation/devicetree/bindings/pinctrl/qcom,sm8250-pinctrl.yaml +++ b/Documentation/devicetree/bindings/pinctrl/qcom,sm8250-pinctrl.yaml @@ -115,6 +115,9 @@ patternProperties: additionalProperties: false +allOf: + - $ref: "pinctrl.yaml#" + required: - compatible - reg diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,sm8350-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/qcom,sm8350-pinctrl.yaml index 4f2667ea2805..6b7789db2f75 100644 --- a/Documentation/devicetree/bindings/pinctrl/qcom,sm8350-pinctrl.yaml +++ b/Documentation/devicetree/bindings/pinctrl/qcom,sm8350-pinctrl.yaml @@ -14,6 +14,7 @@ description: | in the SM8350 platform. allOf: + - $ref: "pinctrl.yaml#" - $ref: /schemas/pinctrl/qcom,tlmm-common.yaml# properties: diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,sm8450-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/qcom,sm8450-pinctrl.yaml new file mode 100644 index 000000000000..9c891246245b --- /dev/null +++ b/Documentation/devicetree/bindings/pinctrl/qcom,sm8450-pinctrl.yaml @@ -0,0 +1,143 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/pinctrl/qcom,sm8450-pinctrl.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Qualcomm Technologies, Inc. SM8450 TLMM block + +maintainers: + - Vinod Koul <vkoul@kernel.org> + +description: | + This binding describes the Top Level Mode Multiplexer (TLMM) block found + in the SM8450 platform. + +allOf: + - $ref: /schemas/pinctrl/qcom,tlmm-common.yaml# + +properties: + compatible: + const: qcom,sm8450-tlmm + + reg: + maxItems: 1 + + interrupts: true + interrupt-controller: true + '#interrupt-cells': true + gpio-controller: true + gpio-reserved-ranges: true + '#gpio-cells': true + gpio-ranges: true + wakeup-parent: true + +required: + - compatible + - reg + +additionalProperties: false + +patternProperties: + '-state$': + oneOf: + - $ref: "#/$defs/qcom-sm8450-tlmm-state" + - patternProperties: + ".*": + $ref: "#/$defs/qcom-sm8450-tlmm-state" + +$defs: + qcom-sm8450-tlmm-state: + type: object + description: + Pinctrl node's client devices use subnodes for desired pin configuration. + Client device subnodes use below standard properties. + $ref: "qcom,tlmm-common.yaml#/$defs/qcom-tlmm-state" + + properties: + pins: + description: + List of gpio pins affected by the properties specified in this + subnode. + items: + oneOf: + - pattern: "^gpio([0-9]|[1-9][0-9]|1[0-9][0-9]|20[0-9])$" + - enum: [ ufs_reset, sdc2_clk, sdc2_cmd, sdc2_data ] + minItems: 1 + maxItems: 36 + + function: + description: + Specify the alternative function to be configured for the specified + pins. + enum: [ aon_cam, atest_char, atest_usb, audio_ref, cam_mclk, cci_async, + cci_i2c, cci_timer, cmu_rng, coex_uart1, coex_uart2, cri_trng, + cri_trng0, cri_trng1, dbg_out, ddr_bist, ddr_pxi0, ddr_pxi1, + ddr_pxi2, ddr_pxi3, dp_hot, gcc_gp1, gcc_gp2, gcc_gp3, + gpio, ibi_i3c, jitter_bist, mdp_vsync, mdp_vsync0, mdp_vsync1, + mdp_vsync2, mdp_vsync3, mi2s0_data0, mi2s0_data1, mi2s0_sck, + mi2s0_ws, mi2s2_data0, mi2s2_data1, mi2s2_sck, mi2s2_ws, + mss_grfc0, mss_grfc1, mss_grfc10, mss_grfc11, mss_grfc12, + mss_grfc2, mss_grfc3, mss_grfc4, mss_grfc5, mss_grfc6, + mss_grfc7, mss_grfc8, mss_grfc9, nav, pcie0_clkreqn, + pcie1_clkreqn, phase_flag, pll_bist, pll_clk, pri_mi2s, + prng_rosc, qdss_cti, qdss_gpio, qlink0_enable, qlink0_request, + qlink0_wmss, qlink1_enable, qlink1_request, qlink1_wmss, + qlink2_enable, qlink2_request, qlink2_wmss, qspi0, qspi1, + qspi2, qspi3, qspi_clk, qspi_cs, qup0, qup1, qup10, qup11, + qup12, qup13, qup14, qup15, qup16, qup17, qup18, qup19, qup2, + qup20, qup21, qup3, qup4, qup5, qup6, qup7, qup8, qup9, qup_l4, + qup_l5, qup_l6, sd_write, sdc40, sdc41, sdc42, sdc43, sdc4_clk, + sdc4_cmd, sec_mi2s, tb_trig, tgu_ch0, tgu_ch1, tgu_ch2, + tgu_ch3, tmess_prng0, tmess_prng1, tmess_prng2, tmess_prng3, + tsense_pwm1, tsense_pwm2, uim0_clk, uim0_data, uim0_present, + uim0_reset, uim1_clk, uim1_data, uim1_present, uim1_reset, + usb2phy_ac, usb_phy, vfr_0, vfr_1, vsense_trigger ] + + bias-disable: true + bias-pull-down: true + bias-pull-up: true + drive-strength: true + input-enable: true + output-high: true + output-low: true + + required: + - pins + - function + + additionalProperties: false + +examples: + - | + #include <dt-bindings/interrupt-controller/arm-gic.h> + pinctrl@f100000 { + compatible = "qcom,sm8450-tlmm"; + reg = <0x0f100000 0x300000>; + gpio-controller; + #gpio-cells = <2>; + gpio-ranges = <&tlmm 0 0 211>; + interrupt-controller; + #interrupt-cells = <2>; + interrupts = <GIC_SPI 208 IRQ_TYPE_LEVEL_HIGH>; + + gpio-wo-subnode-state { + pins = "gpio1"; + function = "gpio"; + }; + + uart-w-subnodes-state { + rx { + pins = "gpio26"; + function = "qup7"; + bias-pull-up; + }; + + tx { + pins = "gpio27"; + function = "qup7"; + bias-disable; + }; + }; + }; +... diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,tlmm-common.yaml b/Documentation/devicetree/bindings/pinctrl/qcom,tlmm-common.yaml index 3b37cf102d41..be8cb0ead62f 100644 --- a/Documentation/devicetree/bindings/pinctrl/qcom,tlmm-common.yaml +++ b/Documentation/devicetree/bindings/pinctrl/qcom,tlmm-common.yaml @@ -51,6 +51,9 @@ properties: should not be accessed by the OS. Please see the ../gpio/gpio.txt for more information. +allOf: + - $ref: "pinctrl.yaml#" + required: - interrupts - interrupt-controller diff --git a/Documentation/devicetree/bindings/pinctrl/ralink,rt2880-pinmux.yaml b/Documentation/devicetree/bindings/pinctrl/ralink,rt2880-pinmux.yaml index b32f2676cab5..f0c52feb24d7 100644 --- a/Documentation/devicetree/bindings/pinctrl/ralink,rt2880-pinmux.yaml +++ b/Documentation/devicetree/bindings/pinctrl/ralink,rt2880-pinmux.yaml @@ -44,6 +44,9 @@ patternProperties: additionalProperties: false +allOf: + - $ref: "pinctrl.yaml#" + required: - compatible diff --git a/Documentation/devicetree/bindings/pinctrl/renesas,pfc.yaml b/Documentation/devicetree/bindings/pinctrl/renesas,pfc.yaml index ac4e068aa03f..8548e3639b75 100644 --- a/Documentation/devicetree/bindings/pinctrl/renesas,pfc.yaml +++ b/Documentation/devicetree/bindings/pinctrl/renesas,pfc.yaml @@ -70,6 +70,9 @@ properties: power-domains: maxItems: 1 +allOf: + - $ref: "pinctrl.yaml#" + required: - compatible - reg diff --git a/Documentation/devicetree/bindings/pinctrl/renesas,rza1-ports.yaml b/Documentation/devicetree/bindings/pinctrl/renesas,rza1-ports.yaml index 7f80578dc229..8ed4b98a1628 100644 --- a/Documentation/devicetree/bindings/pinctrl/renesas,rza1-ports.yaml +++ b/Documentation/devicetree/bindings/pinctrl/renesas,rza1-ports.yaml @@ -31,6 +31,9 @@ properties: reg: maxItems: 1 +allOf: + - $ref: "pinctrl.yaml#" + required: - compatible - reg diff --git a/Documentation/devicetree/bindings/pinctrl/renesas,rza2-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/renesas,rza2-pinctrl.yaml index ce1f7343788f..d761fddc2206 100644 --- a/Documentation/devicetree/bindings/pinctrl/renesas,rza2-pinctrl.yaml +++ b/Documentation/devicetree/bindings/pinctrl/renesas,rza2-pinctrl.yaml @@ -72,6 +72,9 @@ patternProperties: additionalProperties: false +allOf: + - $ref: "pinctrl.yaml#" + required: - compatible - reg diff --git a/Documentation/devicetree/bindings/pinctrl/renesas,rzg2l-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/renesas,rzg2l-pinctrl.yaml index ef68dabcf4dc..b749c82edebd 100644 --- a/Documentation/devicetree/bindings/pinctrl/renesas,rzg2l-pinctrl.yaml +++ b/Documentation/devicetree/bindings/pinctrl/renesas,rzg2l-pinctrl.yaml @@ -73,6 +73,8 @@ additionalProperties: pins: true drive-strength: enum: [ 2, 4, 8, 12 ] + output-impedance-ohms: + enum: [ 33, 50, 66, 100 ] power-source: enum: [ 1800, 2500, 3300 ] slew-rate: true @@ -90,6 +92,9 @@ additionalProperties: additionalProperties: $ref: "#/additionalProperties/anyOf/0" +allOf: + - $ref: "pinctrl.yaml#" + required: - compatible - reg diff --git a/Documentation/devicetree/bindings/pinctrl/renesas,rzn1-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/renesas,rzn1-pinctrl.yaml index 4a43af0d6e02..70b1788ab594 100644 --- a/Documentation/devicetree/bindings/pinctrl/renesas,rzn1-pinctrl.yaml +++ b/Documentation/devicetree/bindings/pinctrl/renesas,rzn1-pinctrl.yaml @@ -31,6 +31,9 @@ properties: description: The bus clock, sometimes described as pclk, for register accesses. +allOf: + - $ref: "pinctrl.yaml#" + required: - compatible - reg diff --git a/Documentation/devicetree/bindings/pinctrl/rockchip,pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/rockchip,pinctrl.yaml index 07c0a98ef9c6..b0eae3a67ab1 100644 --- a/Documentation/devicetree/bindings/pinctrl/rockchip,pinctrl.yaml +++ b/Documentation/devicetree/bindings/pinctrl/rockchip,pinctrl.yaml @@ -67,6 +67,9 @@ properties: ranges: true +allOf: + - $ref: "pinctrl.yaml#" + required: - compatible - rockchip,grf diff --git a/Documentation/devicetree/bindings/pinctrl/samsung-pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/samsung-pinctrl.txt index b8b475967ff9..9e70edceb21b 100644 --- a/Documentation/devicetree/bindings/pinctrl/samsung-pinctrl.txt +++ b/Documentation/devicetree/bindings/pinctrl/samsung-pinctrl.txt @@ -22,6 +22,7 @@ Required Properties: - "samsung,exynos5420-pinctrl": for Exynos5420 compatible pin-controller. - "samsung,exynos5433-pinctrl": for Exynos5433 compatible pin-controller. - "samsung,exynos7-pinctrl": for Exynos7 compatible pin-controller. + - "samsung,exynos7885-pinctrl": for Exynos7885 compatible pin-controller. - "samsung,exynos850-pinctrl": for Exynos850 compatible pin-controller. - "samsung,exynosautov9-pinctrl": for ExynosAutov9 compatible pin-controller. diff --git a/Documentation/devicetree/bindings/pinctrl/socionext,uniphier-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/socionext,uniphier-pinctrl.yaml index a804d9bc1602..14a8c0215cc6 100644 --- a/Documentation/devicetree/bindings/pinctrl/socionext,uniphier-pinctrl.yaml +++ b/Documentation/devicetree/bindings/pinctrl/socionext,uniphier-pinctrl.yaml @@ -10,9 +10,6 @@ maintainers: - Masahiro Yamada <yamada.masahiro@socionext.com> properties: - $nodename: - pattern: "pinctrl" - compatible: enum: - socionext,uniphier-ld4-pinctrl @@ -26,11 +23,48 @@ properties: - socionext,uniphier-pxs3-pinctrl - socionext,uniphier-nx1-pinctrl +additionalProperties: + type: object + + allOf: + - $ref: pincfg-node.yaml# + - $ref: pinmux-node.yaml# + + properties: + phandle: true + function: true + groups: true + pins: true + bias-pull-up: true + bias-pull-down: true + bias-pull-pin-default: true + drive-strength: true + + additionalProperties: + type: object + + allOf: + - $ref: pincfg-node.yaml# + - $ref: pinmux-node.yaml# + + properties: + phandle: true + function: true + groups: true + pins: true + bias-pull-up: true + bias-pull-down: true + bias-pull-pin-default: true + drive-strength: true + + unevaluatedProperties: false + +allOf: + - $ref: "pinctrl.yaml#" + required: - compatible -additionalProperties: false - examples: - | // The UniPhier pinctrl should be a subnode of a "syscon" compatible node. diff --git a/Documentation/devicetree/bindings/pinctrl/st,stm32-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/st,stm32-pinctrl.yaml index ac88e01ec430..83a18d0331b1 100644 --- a/Documentation/devicetree/bindings/pinctrl/st,stm32-pinctrl.yaml +++ b/Documentation/devicetree/bindings/pinctrl/st,stm32-pinctrl.yaml @@ -183,6 +183,9 @@ patternProperties: required: - pinmux +allOf: + - $ref: "pinctrl.yaml#" + required: - compatible - '#address-cells' diff --git a/Documentation/devicetree/bindings/pinctrl/starfive,jh7100-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/starfive,jh7100-pinctrl.yaml new file mode 100644 index 000000000000..92963604422f --- /dev/null +++ b/Documentation/devicetree/bindings/pinctrl/starfive,jh7100-pinctrl.yaml @@ -0,0 +1,307 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/pinctrl/starfive,jh7100-pinctrl.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: StarFive JH7100 Pin Controller Device Tree Bindings + +description: | + Bindings for the JH7100 RISC-V SoC from StarFive Ltd. + + Out of the SoC's many pins only the ones named PAD_GPIO[0] to PAD_GPIO[63] + and PAD_FUNC_SHARE[0] to PAD_FUNC_SHARE[141] can be multiplexed and have + configurable bias, drive strength, schmitt trigger etc. The SoC has an + interesting 2-layered approach to pin muxing best illustrated by the diagram + below. + + Signal group 0, 1, ... or 6 + ___|___ + | | + LCD output -----------------| | + CMOS Camera interface ------| |--- PAD_GPIO[0] + Ethernet PHY interface -----| MUX |--- PAD_GPIO[1] + ... | | ... + | |--- PAD_GPIO[63] + -------- GPIO0 ------------| | + | -------|-- GPIO1 --------| |--- PAD_FUNC_SHARE[0] + | | | | | |--- PAD_FUNC_SHARE[1] + | | | | ... | | ... + | | | | | |--- PAD_FUNC_SHARE[141] + | | -----|---|-- GPIO63 ---| | + | | | | | | ------- + UART0 UART1 -- + + + The big MUX in the diagram only has 7 different ways of mapping peripherals + on the left to pins on the right. StarFive calls the 7 configurations "signal + groups". + However some peripherals have their I/O go through the 64 "GPIOs". The + diagram only shows UART0 and UART1, but this also includes a number of other + UARTs, I2Cs, SPIs, PWMs etc. All these peripherals are connected to all 64 + GPIOs such that any GPIO can be set up to be controlled by any of the + peripherals. + Note that signal group 0 doesn't map any of the GPIOs to pins, and only + signal group 1 maps the GPIOs to the pins named PAD_GPIO[0] to PAD_GPIO[63]. + +maintainers: + - Emil Renner Berthing <kernel@esmil.dk> + - Drew Fustini <drew@beagleboard.org> + +properties: + compatible: + const: starfive,jh7100-pinctrl + + reg: + minItems: 2 + maxItems: 2 + + reg-names: + items: + - const: gpio + - const: padctl + + clocks: + maxItems: 1 + + resets: + maxItems: 1 + + gpio-controller: true + + "#gpio-cells": + const: 2 + + interrupts: + maxItems: 1 + description: The GPIO parent interrupt. + + interrupt-controller: true + + "#interrupt-cells": + const: 2 + + starfive,signal-group: + description: | + Select one of the 7 signal groups. If this property is not set it + defaults to the configuration already chosen by the earlier boot stages. + $ref: /schemas/types.yaml#/definitions/uint32 + enum: [0, 1, 2, 3, 4, 5, 6] + +required: + - compatible + - reg + - reg-names + - clocks + - gpio-controller + - "#gpio-cells" + - interrupts + - interrupt-controller + - "#interrupt-cells" + +patternProperties: + '-[0-9]+$': + type: object + patternProperties: + '-pins$': + type: object + description: | + A pinctrl node should contain at least one subnode representing the + pinctrl groups available on the machine. Each subnode will list the + pins it needs, and how they should be configured, with regard to + muxer configuration, bias, input enable/disable, input schmitt + trigger enable/disable, slew-rate and drive strength. + $ref: "/schemas/pinctrl/pincfg-node.yaml" + + properties: + pins: + description: | + The list of pin identifiers that properties in the node apply to. + This should be set using either the PAD_GPIO or PAD_FUNC_SHARE + macros. + Either this or "pinmux" has to be specified, but not both. + $ref: "/schemas/pinctrl/pinmux-node.yaml#/properties/pins" + + pinmux: + description: | + The list of GPIOs and their mux settings that properties in the + node apply to. This should be set using the GPIOMUX macro. + Either this or "pins" has to be specified, but not both. + $ref: "/schemas/pinctrl/pinmux-node.yaml#/properties/pinmux" + + bias-disable: true + + bias-pull-up: + type: boolean + + bias-pull-down: + type: boolean + + drive-strength: + enum: [ 14, 21, 28, 35, 42, 49, 56, 63 ] + + input-enable: true + + input-disable: true + + input-schmitt-enable: true + + input-schmitt-disable: true + + slew-rate: + maximum: 7 + + starfive,strong-pull-up: + description: enable strong pull-up. + type: boolean + + additionalProperties: false + + additionalProperties: false + +additionalProperties: false + +examples: + - | + #include <dt-bindings/clock/starfive-jh7100.h> + #include <dt-bindings/reset/starfive-jh7100.h> + #include <dt-bindings/pinctrl/pinctrl-starfive.h> + + soc { + #address-cells = <2>; + #size-cells = <2>; + + pinctrl@11910000 { + compatible = "starfive,jh7100-pinctrl"; + reg = <0x0 0x11910000 0x0 0x10000>, + <0x0 0x11858000 0x0 0x1000>; + reg-names = "gpio", "padctl"; + clocks = <&clkgen JH7100_CLK_GPIO_APB>; + resets = <&clkgen JH7100_RSTN_GPIO_APB>; + interrupts = <32>; + gpio-controller; + #gpio-cells = <2>; + interrupt-controller; + #interrupt-cells = <2>; + starfive,signal-group = <6>; + + gmac_pins_default: gmac-0 { + gtxclk-pins { + pins = <PAD_FUNC_SHARE(115)>; + bias-pull-up; + drive-strength = <35>; + input-enable; + input-schmitt-enable; + slew-rate = <0>; + }; + miitxclk-pins { + pins = <PAD_FUNC_SHARE(116)>; + bias-pull-up; + drive-strength = <14>; + input-enable; + input-schmitt-disable; + slew-rate = <0>; + }; + tx-pins { + pins = <PAD_FUNC_SHARE(117)>, + <PAD_FUNC_SHARE(119)>, + <PAD_FUNC_SHARE(120)>, + <PAD_FUNC_SHARE(121)>, + <PAD_FUNC_SHARE(122)>, + <PAD_FUNC_SHARE(123)>, + <PAD_FUNC_SHARE(124)>, + <PAD_FUNC_SHARE(125)>, + <PAD_FUNC_SHARE(126)>; + bias-disable; + drive-strength = <35>; + input-disable; + input-schmitt-disable; + slew-rate = <0>; + }; + rxclk-pins { + pins = <PAD_FUNC_SHARE(127)>; + bias-pull-up; + drive-strength = <14>; + input-enable; + input-schmitt-disable; + slew-rate = <6>; + }; + rxer-pins { + pins = <PAD_FUNC_SHARE(129)>; + bias-pull-up; + drive-strength = <14>; + input-enable; + input-schmitt-disable; + slew-rate = <0>; + }; + rx-pins { + pins = <PAD_FUNC_SHARE(128)>, + <PAD_FUNC_SHARE(130)>, + <PAD_FUNC_SHARE(131)>, + <PAD_FUNC_SHARE(132)>, + <PAD_FUNC_SHARE(133)>, + <PAD_FUNC_SHARE(134)>, + <PAD_FUNC_SHARE(135)>, + <PAD_FUNC_SHARE(136)>, + <PAD_FUNC_SHARE(137)>, + <PAD_FUNC_SHARE(138)>, + <PAD_FUNC_SHARE(139)>, + <PAD_FUNC_SHARE(140)>, + <PAD_FUNC_SHARE(141)>; + bias-pull-up; + drive-strength = <14>; + input-enable; + input-schmitt-enable; + slew-rate = <0>; + }; + }; + + i2c0_pins_default: i2c0-0 { + i2c-pins { + pinmux = <GPIOMUX(62, GPO_LOW, + GPO_I2C0_PAD_SCK_OEN, + GPI_I2C0_PAD_SCK_IN)>, + <GPIOMUX(61, GPO_LOW, + GPO_I2C0_PAD_SDA_OEN, + GPI_I2C0_PAD_SDA_IN)>; + bias-disable; /* external pull-up */ + input-enable; + input-schmitt-enable; + }; + }; + + uart3_pins_default: uart3-0 { + rx-pins { + pinmux = <GPIOMUX(13, GPO_LOW, GPO_DISABLE, + GPI_UART3_PAD_SIN)>; + bias-pull-up; + input-enable; + input-schmitt-enable; + }; + tx-pins { + pinmux = <GPIOMUX(14, GPO_UART3_PAD_SOUT, + GPO_ENABLE, GPI_NONE)>; + bias-disable; + input-disable; + input-schmitt-disable; + }; + }; + }; + + gmac { + pinctrl-0 = <&gmac_pins_default>; + pinctrl-names = "default"; + }; + + i2c0 { + pinctrl-0 = <&i2c0_pins_default>; + pinctrl-names = "default"; + }; + + uart3 { + pinctrl-0 = <&uart3_pins_default>; + pinctrl-names = "default"; + }; + }; + +... diff --git a/Documentation/devicetree/bindings/pinctrl/toshiba,visconti-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/toshiba,visconti-pinctrl.yaml index 9f1dab0c2430..306524885a2b 100644 --- a/Documentation/devicetree/bindings/pinctrl/toshiba,visconti-pinctrl.yaml +++ b/Documentation/devicetree/bindings/pinctrl/toshiba,visconti-pinctrl.yaml @@ -20,6 +20,9 @@ properties: reg: maxItems: 1 +allOf: + - $ref: "pinctrl.yaml#" + required: - compatible - reg @@ -80,7 +83,7 @@ examples: #address-cells = <2>; #size-cells = <2>; - pmux: pmux@24190000 { + pmux: pinmux@24190000 { compatible = "toshiba,tmpv7708-pinctrl"; reg = <0 0x24190000 0 0x10000>; diff --git a/Documentation/devicetree/bindings/pinctrl/xlnx,zynq-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/xlnx,zynq-pinctrl.yaml index ac97dbf6998e..cfd0cc549a7b 100644 --- a/Documentation/devicetree/bindings/pinctrl/xlnx,zynq-pinctrl.yaml +++ b/Documentation/devicetree/bindings/pinctrl/xlnx,zynq-pinctrl.yaml @@ -167,6 +167,9 @@ patternProperties: additionalProperties: false +allOf: + - $ref: "pinctrl.yaml#" + required: - compatible - reg diff --git a/Documentation/devicetree/bindings/pinctrl/xlnx,zynqmp-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/xlnx,zynqmp-pinctrl.yaml index 8ef0d07d35fe..2722dc7bb03d 100644 --- a/Documentation/devicetree/bindings/pinctrl/xlnx,zynqmp-pinctrl.yaml +++ b/Documentation/devicetree/bindings/pinctrl/xlnx,zynqmp-pinctrl.yaml @@ -290,6 +290,9 @@ patternProperties: additionalProperties: false +allOf: + - $ref: pinctrl.yaml# + required: - compatible diff --git a/Documentation/devicetree/bindings/power/apple,pmgr-pwrstate.yaml b/Documentation/devicetree/bindings/power/apple,pmgr-pwrstate.yaml new file mode 100644 index 000000000000..19a194980142 --- /dev/null +++ b/Documentation/devicetree/bindings/power/apple,pmgr-pwrstate.yaml @@ -0,0 +1,79 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/power/apple,pmgr-pwrstate.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Apple SoC PMGR Power States + +maintainers: + - Hector Martin <marcan@marcan.st> + +allOf: + - $ref: "power-domain.yaml#" + +description: | + Apple SoCs include PMGR blocks responsible for power management, + which can control various clocks, resets, power states, and + performance features. This binding describes the device power + state registers, which control power states and resets. + + Each instance of a power controller within the PMGR syscon node + represents a generic power domain provider, as documented in + Documentation/devicetree/bindings/power/power-domain.yaml. + The provider controls a single SoC block. The power hierarchy is + represented via power-domains relationships between these nodes. + + See Documentation/devicetree/bindings/arm/apple/apple,pmgr.yaml + for the top-level PMGR node documentation. + +properties: + compatible: + items: + - enum: + - apple,t8103-pmgr-pwrstate + - apple,t6000-pmgr-pwrstate + - const: apple,pmgr-pwrstate + + reg: + maxItems: 1 + + "#power-domain-cells": + const: 0 + + "#reset-cells": + const: 0 + + power-domains: + description: + Reference to parent power domains. A domain may have multiple parents, + and all will be powered up when it is powered. + minItems: 1 + maxItems: 8 # Arbitrary, should be enough + + label: + description: + Specifies the name of the SoC domain being controlled. This is used to + name the power/reset domains. + + apple,always-on: + description: + Forces this power domain to always be powered up. + type: boolean + + apple,min-state: + description: + Specifies the minimum power state for auto-PM. + 0 = power gated, 4 = clock gated, 15 = on. + $ref: /schemas/types.yaml#/definitions/uint32 + minimum: 0 + maximum: 15 + +required: + - compatible + - reg + - "#power-domain-cells" + - "#reset-cells" + - label + +additionalProperties: false diff --git a/Documentation/devicetree/bindings/power/qcom,rpmpd.yaml b/Documentation/devicetree/bindings/power/qcom,rpmpd.yaml index e810480e3eb7..f48bc41d81ec 100644 --- a/Documentation/devicetree/bindings/power/qcom,rpmpd.yaml +++ b/Documentation/devicetree/bindings/power/qcom,rpmpd.yaml @@ -24,6 +24,7 @@ properties: - qcom,msm8994-rpmpd - qcom,msm8996-rpmpd - qcom,msm8998-rpmpd + - qcom,qcm2290-rpmpd - qcom,qcs404-rpmpd - qcom,sdm660-rpmpd - qcom,sc7180-rpmhpd @@ -32,10 +33,12 @@ properties: - qcom,sdm845-rpmhpd - qcom,sdx55-rpmhpd - qcom,sm6115-rpmpd + - qcom,sm6125-rpmpd - qcom,sm6350-rpmhpd - qcom,sm8150-rpmhpd - qcom,sm8250-rpmhpd - qcom,sm8350-rpmhpd + - qcom,sm8450-rpmhpd '#power-domain-cells': const: 1 diff --git a/Documentation/devicetree/bindings/power/renesas,rcar-sysc.yaml b/Documentation/devicetree/bindings/power/renesas,rcar-sysc.yaml index 99e8042ac111..62a49ca319ec 100644 --- a/Documentation/devicetree/bindings/power/renesas,rcar-sysc.yaml +++ b/Documentation/devicetree/bindings/power/renesas,rcar-sysc.yaml @@ -41,6 +41,7 @@ properties: - renesas,r8a77990-sysc # R-Car E3 - renesas,r8a77995-sysc # R-Car D3 - renesas,r8a779a0-sysc # R-Car V3U + - renesas,r8a779f0-sysc # R-Car S4-8 reg: maxItems: 1 diff --git a/Documentation/devicetree/bindings/power/reset/gpio-poweroff.txt b/Documentation/devicetree/bindings/power/reset/gpio-poweroff.txt deleted file mode 100644 index 3e56c1b34a4c..000000000000 --- a/Documentation/devicetree/bindings/power/reset/gpio-poweroff.txt +++ /dev/null @@ -1,41 +0,0 @@ -Driver a GPIO line that can be used to turn the power off. - -The driver supports both level triggered and edge triggered power off. -At driver load time, the driver will request the given gpio line and -install a handler to power off the system. If the optional properties -'input' is not found, the GPIO line will be driven in the inactive -state. Otherwise its configured as an input. - -When the power-off handler is called, the gpio is configured as an -output, and drive active, so triggering a level triggered power off -condition. This will also cause an inactive->active edge condition, so -triggering positive edge triggered power off. After a delay of 100ms, -the GPIO is set to inactive, thus causing an active->inactive edge, -triggering negative edge triggered power off. After another 100ms -delay the GPIO is driver active again. If the power is still on and -the CPU still running after a 3000ms delay, a WARN_ON(1) is emitted. - -Required properties: -- compatible : should be "gpio-poweroff". -- gpios : The GPIO to set high/low, see "gpios property" in - Documentation/devicetree/bindings/gpio/gpio.txt. If the pin should be - low to power down the board set it to "Active Low", otherwise set - gpio to "Active High". - -Optional properties: -- input : Initially configure the GPIO line as an input. Only reconfigure - it to an output when the power-off handler is called. If this optional - property is not specified, the GPIO is initialized as an output in its - inactive state. -- active-delay-ms: Delay (default 100) to wait after driving gpio active -- inactive-delay-ms: Delay (default 100) to wait after driving gpio inactive -- timeout-ms: Time to wait before asserting a WARN_ON(1). If nothing is - specified, 3000 ms is used. - -Examples: - -gpio-poweroff { - compatible = "gpio-poweroff"; - gpios = <&gpio 4 0>; - timeout-ms = <3000>; -}; diff --git a/Documentation/devicetree/bindings/power/reset/gpio-poweroff.yaml b/Documentation/devicetree/bindings/power/reset/gpio-poweroff.yaml new file mode 100644 index 000000000000..45d66c775115 --- /dev/null +++ b/Documentation/devicetree/bindings/power/reset/gpio-poweroff.yaml @@ -0,0 +1,59 @@ +# SPDX-License-Identifier: (GPL-2.0-only or BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/power/reset/gpio-poweroff.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: GPIO controlled power off + +maintainers: + - Sebastian Reichel <sre@kernel.org> + +description: > + System power off support via a GPIO line. When a shutdown is + executed the operating system is expected to switch the GPIO + from inactive to active. After a delay (active-delay-ms) it + is expected to be switched back to inactive. After another + delay (inactive-delay-ms) it is configured as active again. + Finally the operating system assumes the power off failed if + the system is still running after waiting some time (timeout-ms). + +properties: + compatible: + const: gpio-poweroff + + gpios: + maxItems: 1 + + input: + type: boolean + description: > + Initially configure the GPIO line as an input. Only reconfigure + it to an output when the power-off sequence is initiated. If this optional + property is not specified, the GPIO is initialized as an output in its inactive state. + + active-delay-ms: + default: 100 + description: Delay to wait after driving gpio active + + inactive-delay-ms: + default: 100 + description: Delay to wait after driving gpio inactive + + timeout-ms: + default: 3000 + description: Time to wait before assuming the power off sequence failed. + +required: + - compatible + - gpios + +additionalProperties: false + +examples: + - | + gpio-poweroff { + compatible = "gpio-poweroff"; + gpios = <&gpio 4 0>; + timeout-ms = <3000>; + }; diff --git a/Documentation/devicetree/bindings/power/reset/gpio-restart.txt b/Documentation/devicetree/bindings/power/reset/gpio-restart.txt deleted file mode 100644 index af3701bc15c4..000000000000 --- a/Documentation/devicetree/bindings/power/reset/gpio-restart.txt +++ /dev/null @@ -1,54 +0,0 @@ -Drive a GPIO line that can be used to restart the system from a restart -handler. - -This binding supports level and edge triggered reset. At driver load -time, the driver will request the given gpio line and install a restart -handler. If the optional properties 'open-source' is not found, the GPIO line -will be driven in the inactive state. Otherwise its not driven until -the restart is initiated. - -When the system is restarted, the restart handler will be invoked in -priority order. The gpio is configured as an output, and driven active, -triggering a level triggered reset condition. This will also cause an -inactive->active edge condition, triggering positive edge triggered -reset. After a delay specified by active-delay, the GPIO is set to -inactive, thus causing an active->inactive edge, triggering negative edge -triggered reset. After a delay specified by inactive-delay, the GPIO -is driven active again. After a delay specified by wait-delay, the -restart handler completes allowing other restart handlers to be attempted. - -Required properties: -- compatible : should be "gpio-restart". -- gpios : The GPIO to set high/low, see "gpios property" in - Documentation/devicetree/bindings/gpio/gpio.txt. If the pin should be - low to reset the board set it to "Active Low", otherwise set - gpio to "Active High". - -Optional properties: -- open-source : Treat the GPIO as being open source and defer driving - it to when the restart is initiated. If this optional property is not - specified, the GPIO is initialized as an output in its inactive state. -- priority : A priority ranging from 0 to 255 (default 128) according to - the following guidelines: - 0: Restart handler of last resort, with limited restart - capabilities - 128: Default restart handler; use if no other restart handler is - expected to be available, and/or if restart functionality is - sufficient to restart the entire system - 255: Highest priority restart handler, will preempt all other - restart handlers -- active-delay: Delay (default 100) to wait after driving gpio active [ms] -- inactive-delay: Delay (default 100) to wait after driving gpio inactive [ms] -- wait-delay: Delay (default 3000) to wait after completing restart - sequence [ms] - -Examples: - -gpio-restart { - compatible = "gpio-restart"; - gpios = <&gpio 4 0>; - priority = <128>; - active-delay = <100>; - inactive-delay = <100>; - wait-delay = <3000>; -}; diff --git a/Documentation/devicetree/bindings/power/reset/gpio-restart.yaml b/Documentation/devicetree/bindings/power/reset/gpio-restart.yaml new file mode 100644 index 000000000000..a72d5c721516 --- /dev/null +++ b/Documentation/devicetree/bindings/power/reset/gpio-restart.yaml @@ -0,0 +1,86 @@ +# SPDX-License-Identifier: (GPL-2.0-only or BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/power/reset/gpio-restart.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: GPIO controlled reset + +maintainers: + - Sebastian Reichel <sre@kernel.org> + +description: > + Drive a GPIO line that can be used to restart the system from a restart handler. + + This binding supports level and edge triggered reset. At driver load time, the driver will + request the given gpio line and install a restart handler. If the optional properties + 'open-source' is not found, the GPIO line will be driven in the inactive state. Otherwise its + not driven until the restart is initiated. + + When the system is restarted, the restart handler will be invoked in priority order. The GPIO + is configured as an output, and driven active, triggering a level triggered reset condition. + This will also cause an inactive->active edge condition, triggering positive edge triggered + reset. After a delay specified by active-delay, the GPIO is set to inactive, thus causing an + active->inactive edge, triggering negative edge triggered reset. After a delay specified by + inactive-delay, the GPIO is driven active again. After a delay specified by wait-delay, the + restart handler completes allowing other restart handlers to be attempted. + +properties: + compatible: + const: gpio-restart + + gpios: + description: The GPIO to set high/low, see "gpios property" in + Documentation/devicetree/bindings/gpio/gpio.txt. If the pin should be low to reset the board + set it to "Active Low", otherwise set GPIO to "Active High". + + open-source: + $ref: /schemas/types.yaml#/definitions/flag + description: Treat the GPIO as being open source and defer driving it to when the restart is + initiated. If this optional property is not specified, the GPIO is initialized as an output + in its inactive state. + + priority: + $ref: /schemas/types.yaml#/definitions/uint32 + description: | + A priority ranging from 0 to 255 (default 129) according to the following guidelines: + + 0: Restart handler of last resort, with limited restart capabilities. + 128: Default restart handler; use if no other restart handler is expected to be available, + and/or if restart functionality is sufficient to restart the entire system. + 255: Highest priority restart handler, will preempt all other restart handlers. + minimum: 0 + maximum: 255 + default: 129 + + active-delay: + $ref: /schemas/types.yaml#/definitions/uint32 + description: Delay (default 100) to wait after driving gpio active [ms] + default: 100 + + inactive-delay: + $ref: /schemas/types.yaml#/definitions/uint32 + description: Delay (default 100) to wait after driving gpio inactive [ms] + default: 100 + + wait-delay: + $ref: /schemas/types.yaml#/definitions/uint32 + description: Delay (default 3000) to wait after completing restart sequence [ms] + default: 100 + +additionalProperties: false + +required: + - compatible + - gpios + +examples: + - | + gpio-restart { + compatible = "gpio-restart"; + gpios = <&gpio 4 0>; + priority = <128>; + active-delay = <100>; + inactive-delay = <100>; + wait-delay = <3000>; + }; diff --git a/Documentation/devicetree/bindings/power/supply/bq25980.yaml b/Documentation/devicetree/bindings/power/supply/bq25980.yaml index 06eca6667f67..8367a1fd4057 100644 --- a/Documentation/devicetree/bindings/power/supply/bq25980.yaml +++ b/Documentation/devicetree/bindings/power/supply/bq25980.yaml @@ -105,7 +105,7 @@ examples: reg = <0x65>; interrupt-parent = <&gpio1>; interrupts = <16 IRQ_TYPE_EDGE_FALLING>; - ti,watchdog-timer = <0>; + ti,watchdog-timeout-ms = <0>; ti,sc-ocp-limit-microamp = <2000000>; ti,sc-ovp-limit-microvolt = <17800000>; monitored-battery = <&bat>; diff --git a/Documentation/devicetree/bindings/power/supply/maxim,max17040.yaml b/Documentation/devicetree/bindings/power/supply/maxim,max17040.yaml index ffb344987a7b..6b4588a3253b 100644 --- a/Documentation/devicetree/bindings/power/supply/maxim,max17040.yaml +++ b/Documentation/devicetree/bindings/power/supply/maxim,max17040.yaml @@ -44,7 +44,9 @@ properties: SoC == State of Charge == Capacity. maxim,rcomp: - $ref: /schemas/types.yaml#/definitions/uint32 + $ref: /schemas/types.yaml#/definitions/uint8-array + minItems: 1 + maxItems: 2 description: | A value to compensate readings for various battery chemistries and operating temperatures. max17040,41 have 2 byte rcomp, default to 0x97 0x00. diff --git a/Documentation/devicetree/bindings/power/supply/maxim,max77976.yaml b/Documentation/devicetree/bindings/power/supply/maxim,max77976.yaml new file mode 100644 index 000000000000..675b9b26d233 --- /dev/null +++ b/Documentation/devicetree/bindings/power/supply/maxim,max77976.yaml @@ -0,0 +1,44 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/power/supply/maxim,max77976.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Maxim Integrated MAX77976 Battery charger + +maintainers: + - Luca Ceresoli <luca@lucaceresoli.net> + +description: | + The Maxim MAX77976 is a 19Vin / 5.5A, 1-Cell Li+ battery charger + configured via I2C. + +allOf: + - $ref: power-supply.yaml# + +properties: + compatible: + const: maxim,max77976 + + reg: + maxItems: 1 + +required: + - compatible + - reg + +unevaluatedProperties: false + +examples: + - | + i2c { + #address-cells = <1>; + #size-cells = <0>; + + charger@6b { + compatible = "maxim,max77976"; + reg = <0x6b>; + }; + }; + +... diff --git a/Documentation/devicetree/bindings/power/supply/qcom,pm8941-charger.yaml b/Documentation/devicetree/bindings/power/supply/qcom,pm8941-charger.yaml index bc8904872d1b..caeff68c66d5 100644 --- a/Documentation/devicetree/bindings/power/supply/qcom,pm8941-charger.yaml +++ b/Documentation/devicetree/bindings/power/supply/qcom,pm8941-charger.yaml @@ -11,7 +11,9 @@ maintainers: properties: compatible: - const: qcom,pm8941-charger + enum: + - qcom,pm8226-charger + - qcom,pm8941-charger reg: maxItems: 1 diff --git a/Documentation/devicetree/bindings/pwm/brcm,bcm7038-pwm.txt b/Documentation/devicetree/bindings/pwm/brcm,bcm7038-pwm.txt deleted file mode 100644 index 0e662d7f6bd1..000000000000 --- a/Documentation/devicetree/bindings/pwm/brcm,bcm7038-pwm.txt +++ /dev/null @@ -1,20 +0,0 @@ -Broadcom BCM7038 PWM controller (BCM7xxx Set Top Box PWM controller) - -Required properties: - -- compatible: must be "brcm,bcm7038-pwm" -- reg: physical base address and length for this controller -- #pwm-cells: should be 2. See pwm.yaml in this directory for a description - of the cells format -- clocks: a phandle to the reference clock for this block which is fed through - its internal variable clock frequency generator - - -Example: - - pwm: pwm@f0408000 { - compatible = "brcm,bcm7038-pwm"; - reg = <0xf0408000 0x28>; - #pwm-cells = <2>; - clocks = <&upg_fixed>; - }; diff --git a/Documentation/devicetree/bindings/pwm/brcm,bcm7038-pwm.yaml b/Documentation/devicetree/bindings/pwm/brcm,bcm7038-pwm.yaml new file mode 100644 index 000000000000..4080e098f746 --- /dev/null +++ b/Documentation/devicetree/bindings/pwm/brcm,bcm7038-pwm.yaml @@ -0,0 +1,43 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/pwm/brcm,bcm7038-pwm.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Broadcom BCM7038 PWM controller (BCM7xxx Set Top Box PWM controller) + +maintainers: + - Florian Fainelli <f.fainelli@gmail.com> + +allOf: + - $ref: pwm.yaml# + +properties: + compatible: + const: brcm,bcm7038-pwm + + reg: + maxItems: 1 + + "#pwm-cells": + const: 2 + + clocks: + maxItems: 1 + +required: + - compatible + - reg + - "#pwm-cells" + - clocks + +additionalProperties: false + +examples: + - | + pwm: pwm@f0408000 { + compatible = "brcm,bcm7038-pwm"; + reg = <0xf0408000 0x28>; + #pwm-cells = <2>; + clocks = <&upg_fixed>; + }; diff --git a/Documentation/devicetree/bindings/pwm/pwm.yaml b/Documentation/devicetree/bindings/pwm/pwm.yaml index 2effe6c0de6b..3c01f85029e5 100644 --- a/Documentation/devicetree/bindings/pwm/pwm.yaml +++ b/Documentation/devicetree/bindings/pwm/pwm.yaml @@ -9,6 +9,8 @@ title: PWM controllers (providers) maintainers: - Thierry Reding <thierry.reding@gmail.com> +select: false + properties: $nodename: pattern: "^pwm(@.*|-[0-9a-f])*$" diff --git a/Documentation/devicetree/bindings/regulator/dlg,da9121.yaml b/Documentation/devicetree/bindings/regulator/dlg,da9121.yaml index 228018c87bea..24ace6e1e5ec 100644 --- a/Documentation/devicetree/bindings/regulator/dlg,da9121.yaml +++ b/Documentation/devicetree/bindings/regulator/dlg,da9121.yaml @@ -17,27 +17,39 @@ description: | Dialog Semiconductor DA9130 Single-channel 10A double-phase buck converter Dialog Semiconductor DA9131 Double-channel 5A single-phase buck converter Dialog Semiconductor DA9132 Double-channel 3A single-phase buck converter - - Current limits - - This is PER PHASE, and the current limit setting in the devices reflect - that with a maximum 10A limit. Allowing for transients at/near double - the rated current, this translates across the device range to per - channel figures as so... - - | DA9121 DA9122 DA9220 DA9217 DA9140 - | /DA9130 /DA9131 /DA9132 - ----------------------------------------------------------------------------- - Output current / channel | 10000000 5000000 3000000 6000000 40000000 - Output current / phase | 5000000 5000000 3000000 3000000 9500000 - ----------------------------------------------------------------------------- - Min regulator-min-microvolt| 300000 300000 300000 300000 500000 - Max regulator-max-microvolt| 1900000 1900000 1900000 1900000 1000000 - Device hardware default | 1000000 1000000 1000000 1000000 1000000 - ----------------------------------------------------------------------------- - Min regulator-min-microamp | 7000000 3500000 3500000 7000000 26000000 - Max regulator-max-microamp | 20000000 10000000 6000000 12000000 78000000 - Device hardware default | 15000000 7500000 5500000 11000000 58000000 + Dialog Semiconductor DA9141 Single-channel 40A quad-phase buck converter + Dialog Semiconductor DA9142 Single-channel 20A double-phase buck converter + + Device parameter ranges + + The current limits can be set to at/near double the rated current per channel + to allow for transient peaks. + Current limit changes when the output is enabled are not supported, as a + precaution against undefined behaviour. + + |----------------------------------------------| + | | range & reset default value | + | Device |------------------------------| + | | microvolt | microamp | + |----------------------------------------------| + | DA9121/DA9130 | Min: 300000 | Min: 7000000 | + | | Max: 1900000 | Max: 20000000 | + |----------------------------------------------| + | DA9121/DA9131 | Min: 300000 | Min: 3500000 | + | | Max: 1900000 | Max: 10000000 | + |----------------------------------------------| + | DA9121/DA9131 | Min: 300000 | Min: 3500000 | + | | Max: 1900000 | Max: 6000000 | + |----------------------------------------------| + | DA9217 | Min: 300000 | Min: 7000000 | + | | Max: 1900000 | Max: 12000000 | + |----------------------------------------------| + | DA9141 | Min: 300000 | Min: 26000000 | + | | Max: 1300000 | Max: 78000000 | + |----------------------------------------------| + | DA9142 | Min: 300000 | Min: 13000000 | + | | Max: 1300000 | Max: 39000000 | + |----------------------------------------------| properties: $nodename: @@ -51,7 +63,8 @@ properties: - dlg,da9130 - dlg,da9131 - dlg,da9132 - - dlg,da9140 + - dlg,da9141 + - dlg,da9142 reg: maxItems: 1 @@ -70,26 +83,24 @@ properties: regulators: type: object - $ref: regulator.yaml# description: | - This node defines the settings for the BUCK. The content of the - sub-node is defined by the standard binding for regulators; see regulator.yaml. - The DA9121 regulator is bound using their names listed below - buck1 - BUCK1 - buck2 - BUCK2 //DA9122, DA9220, DA9131, DA9132 only + List of regulators provided by the device patternProperties: "^buck([1-2])$": type: object $ref: regulator.yaml# + description: | + Properties for a single BUCK regulator properties: - regulator-mode: - maxItems: 1 - description: Defined in include/dt-bindings/regulator/dlg,da9121-regulator.h + regulator-name: + pattern: "^BUCK([1-2])$" + description: | + BUCK2 present in DA9122, DA9220, DA9131, DA9132 only regulator-initial-mode: - maxItems: 1 + enum: [ 0, 1, 2, 3 ] description: Defined in include/dt-bindings/regulator/dlg,da9121-regulator.h enable-gpios: @@ -98,6 +109,7 @@ properties: dlg,ripple-cancel: $ref: "/schemas/types.yaml#/definitions/uint32" + enum: [ 0, 1, 2, 3 ] description: | Defined in include/dt-bindings/regulator/dlg,da9121-regulator.h Only present on multi-channel devices (DA9122, DA9220, DA9131, DA9132) diff --git a/Documentation/devicetree/bindings/regulator/max77686.txt b/Documentation/devicetree/bindings/regulator/max77686.txt deleted file mode 100644 index ff3d2dec8c4b..000000000000 --- a/Documentation/devicetree/bindings/regulator/max77686.txt +++ /dev/null @@ -1,71 +0,0 @@ -Binding for Maxim MAX77686 regulators - -This is a part of the device tree bindings of MAX77686 multi-function device. -More information can be found in ../mfd/max77686.txt file. - -The MAX77686 PMIC has 9 high-efficiency Buck and 26 Low-DropOut (LDO) -regulators that can be controlled over I2C. - -Following properties should be present in main device node of the MFD chip. - -Optional node: -- voltage-regulators : The regulators of max77686 have to be instantiated - under subnode named "voltage-regulators" using the following format. - - regulator_name { - regulator-compatible = LDOn/BUCKn - standard regulator constraints.... - }; - refer Documentation/devicetree/bindings/regulator/regulator.txt - - The regulator node's name should be initialized with a string -to get matched with their hardware counterparts as follow: - - -LDOn : for LDOs, where n can lie in range 1 to 26. - example: LDO1, LDO2, LDO26. - -BUCKn : for BUCKs, where n can lie in range 1 to 9. - example: BUCK1, BUCK5, BUCK9. - - Regulators which can be turned off during system suspend: - -LDOn : 2, 6-8, 10-12, 14-16, - -BUCKn : 1-4. - Use standard regulator bindings for it ('regulator-off-in-suspend'). - - LDO20, LDO21, LDO22, BUCK8 and BUCK9 can be configured to GPIO enable - control. To turn this feature on this property must be added to the regulator - sub-node: - - maxim,ena-gpios : one GPIO specifier enable control (the gpio - flags are actually ignored and always - ACTIVE_HIGH is used) - -Example: - - max77686: pmic@9 { - compatible = "maxim,max77686"; - interrupt-parent = <&wakeup_eint>; - interrupts = <26 IRQ_TYPE_LEVEL_LOW>; - reg = <0x09>; - - voltage-regulators { - ldo11_reg: LDO11 { - regulator-name = "vdd_ldo11"; - regulator-min-microvolt = <1900000>; - regulator-max-microvolt = <1900000>; - regulator-always-on; - }; - - buck1_reg: BUCK1 { - regulator-name = "vdd_mif"; - regulator-min-microvolt = <950000>; - regulator-max-microvolt = <1300000>; - regulator-always-on; - regulator-boot-on; - }; - - buck9_reg: BUCK9 { - regulator-name = "CAM_ISP_CORE_1.2V"; - regulator-min-microvolt = <1000000>; - regulator-max-microvolt = <1200000>; - maxim,ena-gpios = <&gpm0 3 GPIO_ACTIVE_HIGH>; - }; - }; diff --git a/Documentation/devicetree/bindings/regulator/maxim,max20086.yaml b/Documentation/devicetree/bindings/regulator/maxim,max20086.yaml new file mode 100644 index 000000000000..05f72391185e --- /dev/null +++ b/Documentation/devicetree/bindings/regulator/maxim,max20086.yaml @@ -0,0 +1,106 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/regulator/maxim,max20086.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Maxim Integrated MAX20086-MAX20089 Camera Power Protector + +maintainers: + - Laurent Pinchart <laurent.pinchart@ideasonboard.com> + +description: | + The MAX20086-MAX20089 are dual/quad camera power protectors, designed to + deliver power over coax for radar and camera modules. They support + software-configurable output switching and monitoring. The output voltage and + current limit are fixed by the hardware design. + +properties: + compatible: + enum: + - maxim,max20086 + - maxim,max20087 + - maxim,max20088 + - maxim,max20089 + + reg: + maxItems: 1 + + enable-gpios: + maxItems: 1 + description: GPIO connected to the EN pin, active high + + in-supply: + description: Input supply for the camera outputs (IN pin, 3.0V to 15.0V) + + vdd-supply: + description: Input supply for the device (VDD pin, 3.0V to 5.5V) + + regulators: + type: object + + patternProperties: + "^OUT[1-4]$": + type: object + $ref: regulator.yaml# + + additionalProperties: false + +required: + - compatible + - reg + - in-supply + - vdd-supply + - regulators + +allOf: + - if: + properties: + compatible: + contains: + enum: + - maxim,max20088 + - maxim,max20089 + then: + properties: + regulators: + properties: + OUT3: false + OUT4: false + +additionalProperties: false + +examples: + - | + #include <dt-bindings/gpio/gpio.h> + + i2c { + #address-cells = <1>; + #size-cells = <0>; + + regulator@28 { + compatible = "maxim,max20087"; + reg = <0x28>; + + in-supply = <®_12v0>; + vdd-supply = <®_3v3>; + + enable-gpios = <&gpio 108 GPIO_ACTIVE_HIGH>; + + regulators { + OUT1 { + regulator-name = "VOUT1"; + }; + OUT2 { + regulator-name = "VOUT2"; + }; + OUT3 { + regulator-name = "VOUT3"; + }; + OUT4 { + regulator-name = "VOUT4"; + }; + }; + }; + }; +... diff --git a/Documentation/devicetree/bindings/regulator/maxim,max77686.yaml b/Documentation/devicetree/bindings/regulator/maxim,max77686.yaml new file mode 100644 index 000000000000..bb64b679f765 --- /dev/null +++ b/Documentation/devicetree/bindings/regulator/maxim,max77686.yaml @@ -0,0 +1,83 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/regulator/maxim,max77686.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Maxim MAX77686 Power Management IC regulators + +maintainers: + - Chanwoo Choi <cw00.choi@samsung.com> + - Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com> + +description: | + This is a part of device tree bindings for Maxim MAX77686 Power Management + Integrated Circuit (PMIC). + + The Maxim MAX77686 provides high-efficiency Buck and 26 Low-DropOut (LDO) + regulators. + + See also Documentation/devicetree/bindings/mfd/maxim,max77686.yaml for + additional information and example. + +patternProperties: + # 26 LDOs + "^LDO([1-9]|1[0-9]|2[3-6])$": + type: object + $ref: regulator.yaml# + unevaluatedProperties: false + description: | + Properties for single LDO regulator. + Regulators which can be turned off during system suspend: + LDO2, LDO6-8, LDO10-12, LDO14-16 + + required: + - regulator-name + + # LDO20-LDO22 with maxim,ena-gpios + "^LDO2[0-2]$": + type: object + $ref: regulator.yaml# + unevaluatedProperties: false + description: | + Properties for single LDO regulator. + + properties: + maxim,ena-gpios: + maxItems: 1 + description: | + GPIO specifier to enable the GPIO control (on/off) for regulator. + + required: + - regulator-name + + # 9 bucks + "^BUCK[1-7]$": + type: object + $ref: regulator.yaml# + unevaluatedProperties: false + description: | + Properties for single BUCK regulator. + Regulators which can be turned off during system suspend: + BUCK[1-4] + + required: + - regulator-name + + "^BUCK[89]$": + type: object + $ref: regulator.yaml# + unevaluatedProperties: false + description: | + Properties for single BUCK regulator. + + properties: + maxim,ena-gpios: + maxItems: 1 + description: | + GPIO specifier to enable the GPIO control (on/off) for regulator. + + required: + - regulator-name + +additionalProperties: false diff --git a/Documentation/devicetree/bindings/regulator/maxim,max8973.yaml b/Documentation/devicetree/bindings/regulator/maxim,max8973.yaml index 54522827265b..35c53e27f78c 100644 --- a/Documentation/devicetree/bindings/regulator/maxim,max8973.yaml +++ b/Documentation/devicetree/bindings/regulator/maxim,max8973.yaml @@ -86,6 +86,9 @@ properties: reg: maxItems: 1 + interrupts: + maxItems: 1 + required: - compatible - reg diff --git a/Documentation/devicetree/bindings/regulator/qcom,rpmh-regulator.yaml b/Documentation/devicetree/bindings/regulator/qcom,rpmh-regulator.yaml index b959504e0ea4..5c73d3f639c7 100644 --- a/Documentation/devicetree/bindings/regulator/qcom,rpmh-regulator.yaml +++ b/Documentation/devicetree/bindings/regulator/qcom,rpmh-regulator.yaml @@ -43,6 +43,7 @@ description: | For PM8150L, smps1 - smps8, ldo1 - ldo11, bob, flash, rgb For PM8350, smps1 - smps12, ldo1 - ldo10 For PM8350C, smps1 - smps10, ldo1 - ldo13, bob + For PM8450, smps1 - smps6, ldo1 - ldo4 For PM8998, smps1 - smps13, ldo1 - ldo28, lvs1 - lvs2 For PMI8998, bob For PMR735A, smps1 - smps3, ldo1 - ldo7 @@ -62,7 +63,9 @@ properties: - qcom,pm8150l-rpmh-regulators - qcom,pm8350-rpmh-regulators - qcom,pm8350c-rpmh-regulators + - qcom,pm8450-rpmh-regulators - qcom,pm8998-rpmh-regulators + - qcom,pmg1110-rpmh-regulators - qcom,pmi8998-rpmh-regulators - qcom,pmm8155au-rpmh-regulators - qcom,pmr735a-rpmh-regulators diff --git a/Documentation/devicetree/bindings/regulator/qcom,spmi-regulator.txt b/Documentation/devicetree/bindings/regulator/qcom,spmi-regulator.txt index 2b544059e029..c2a39b121b1b 100644 --- a/Documentation/devicetree/bindings/regulator/qcom,spmi-regulator.txt +++ b/Documentation/devicetree/bindings/regulator/qcom,spmi-regulator.txt @@ -6,6 +6,7 @@ Qualcomm SPMI Regulators Definition: must be one of: "qcom,pm8004-regulators" "qcom,pm8005-regulators" + "qcom,pm8226-regulators" "qcom,pm8841-regulators" "qcom,pm8916-regulators" "qcom,pm8941-regulators" diff --git a/Documentation/devicetree/bindings/regulator/regulator.yaml b/Documentation/devicetree/bindings/regulator/regulator.yaml index a6ae9ecae5cc..ed560ee8714e 100644 --- a/Documentation/devicetree/bindings/regulator/regulator.yaml +++ b/Documentation/devicetree/bindings/regulator/regulator.yaml @@ -218,7 +218,7 @@ properties: description: Array of maximum spread between voltages of coupled regulators in microvolts, each value in the array relates to the corresponding couple specified by the regulator-coupled-with property. - $ref: "/schemas/types.yaml#/definitions/uint32" + $ref: "/schemas/types.yaml#/definitions/uint32-array" regulator-max-step-microvolt: description: Maximum difference between current and target voltages diff --git a/Documentation/devicetree/bindings/regulator/rohm,bd70528-regulator.txt b/Documentation/devicetree/bindings/regulator/rohm,bd70528-regulator.txt deleted file mode 100644 index 698cfc3bc3dd..000000000000 --- a/Documentation/devicetree/bindings/regulator/rohm,bd70528-regulator.txt +++ /dev/null @@ -1,68 +0,0 @@ -ROHM BD70528 Power Management Integrated Circuit regulator bindings - -Required properties: - - regulator-name: should be "buck1", "buck2", "buck3", "ldo1", "ldo2", "ldo3", - "led_ldo1", "led_ldo2" - -List of regulators provided by this controller. BD70528 regulators node -should be sub node of the BD70528 MFD node. See BD70528 MFD bindings at -Documentation/devicetree/bindings/mfd/rohm,bd70528-pmic.txt - -The valid names for BD70528 regulator nodes are: -BUCK1, BUCK2, BUCK3, LDO1, LDO2, LDO3, LED_LDO1, LED_LDO2 - -Optional properties: -- Any optional property defined in bindings/regulator/regulator.txt - -Example: -regulators { - buck1: BUCK1 { - regulator-name = "buck1"; - regulator-min-microvolt = <1200000>; - regulator-max-microvolt = <3400000>; - regulator-boot-on; - regulator-ramp-delay = <125>; - }; - buck2: BUCK2 { - regulator-name = "buck2"; - regulator-min-microvolt = <1200000>; - regulator-max-microvolt = <3300000>; - regulator-boot-on; - regulator-ramp-delay = <125>; - }; - buck3: BUCK3 { - regulator-name = "buck3"; - regulator-min-microvolt = <800000>; - regulator-max-microvolt = <1800000>; - regulator-boot-on; - regulator-ramp-delay = <250>; - }; - ldo1: LDO1 { - regulator-name = "ldo1"; - regulator-min-microvolt = <1650000>; - regulator-max-microvolt = <3300000>; - regulator-boot-on; - }; - ldo2: LDO2 { - regulator-name = "ldo2"; - regulator-min-microvolt = <1650000>; - regulator-max-microvolt = <3300000>; - regulator-boot-on; - }; - - ldo3: LDO3 { - regulator-name = "ldo3"; - regulator-min-microvolt = <1650000>; - regulator-max-microvolt = <3300000>; - }; - led_ldo1: LED_LDO1 { - regulator-name = "led_ldo1"; - regulator-min-microvolt = <200000>; - regulator-max-microvolt = <300000>; - }; - led_ldo2: LED_LDO2 { - regulator-name = "led_ldo2"; - regulator-min-microvolt = <200000>; - regulator-max-microvolt = <300000>; - }; -}; diff --git a/Documentation/devicetree/bindings/regulator/samsung,s5m8767.yaml b/Documentation/devicetree/bindings/regulator/samsung,s5m8767.yaml index 80a63d47790a..3c1617b66861 100644 --- a/Documentation/devicetree/bindings/regulator/samsung,s5m8767.yaml +++ b/Documentation/devicetree/bindings/regulator/samsung,s5m8767.yaml @@ -51,11 +51,25 @@ patternProperties: description: Properties for single BUCK regulator. + properties: + op_mode: + $ref: /schemas/types.yaml#/definitions/uint32 + enum: [0, 1, 2, 3] + default: 1 + description: | + Describes the different operating modes of the regulator with power + mode change in SOC. The different possible values are: + 0 - always off mode + 1 - on in normal mode + 2 - low power mode + 3 - suspend mode + required: - regulator-name +properties: # 9 buck - "^BUCK9$": + BUCK9: type: object $ref: regulator.yaml# unevaluatedProperties: false @@ -63,6 +77,18 @@ patternProperties: Properties for single BUCK regulator. properties: + op_mode: + $ref: /schemas/types.yaml#/definitions/uint32 + enum: [0, 1, 2, 3] + default: 1 + description: | + Describes the different operating modes of the regulator with power + mode change in SOC. The different possible values are: + 0 - always off mode + 1 - on in normal mode + 2 - low power mode + 3 - suspend mode + s5m8767,pmic-ext-control-gpios: maxItems: 1 description: | diff --git a/Documentation/devicetree/bindings/remoteproc/qcom,adsp.yaml b/Documentation/devicetree/bindings/remoteproc/qcom,adsp.yaml index 63e06d93bca3..c635c181d2c2 100644 --- a/Documentation/devicetree/bindings/remoteproc/qcom,adsp.yaml +++ b/Documentation/devicetree/bindings/remoteproc/qcom,adsp.yaml @@ -33,6 +33,9 @@ properties: - qcom,sdm845-adsp-pas - qcom,sdm845-cdsp-pas - qcom,sdx55-mpss-pas + - qcom,sm6350-adsp-pas + - qcom,sm6350-cdsp-pas + - qcom,sm6350-mpss-pas - qcom,sm8150-adsp-pas - qcom,sm8150-cdsp-pas - qcom,sm8150-mpss-pas @@ -158,6 +161,9 @@ allOf: - qcom,sc8180x-mpss-pas - qcom,sdm845-adsp-pas - qcom,sdm845-cdsp-pas + - qcom,sm6350-adsp-pas + - qcom,sm6350-cdsp-pas + - qcom,sm6350-mpss-pas - qcom,sm8150-adsp-pas - qcom,sm8150-cdsp-pas - qcom,sm8150-mpss-pas @@ -266,6 +272,8 @@ allOf: - qcom,sc8180x-cdsp-pas - qcom,sdm845-adsp-pas - qcom,sdm845-cdsp-pas + - qcom,sm6350-adsp-pas + - qcom,sm6350-cdsp-pas - qcom,sm8150-adsp-pas - qcom,sm8150-cdsp-pas - qcom,sm8150-slpi-pas @@ -301,6 +309,7 @@ allOf: - qcom,sc7280-mpss-pas - qcom,sc8180x-mpss-pas - qcom,sdx55-mpss-pas + - qcom,sm6350-mpss-pas - qcom,sm8150-mpss-pas - qcom,sm8350-mpss-pas then: @@ -390,6 +399,23 @@ allOf: compatible: contains: enum: + - qcom,sm6350-cdsp-pas + then: + properties: + power-domains: + items: + - description: CX power domain + - description: MX power domain + power-domain-names: + items: + - const: cx + - const: mx + + - if: + properties: + compatible: + contains: + enum: - qcom,sm8150-adsp-pas - qcom,sm8150-cdsp-pas then: @@ -405,6 +431,7 @@ allOf: enum: - qcom,sc7280-mpss-pas - qcom,sdx55-mpss-pas + - qcom,sm6350-mpss-pas - qcom,sm8150-mpss-pas - qcom,sm8350-mpss-pas then: @@ -425,6 +452,7 @@ allOf: enum: - qcom,sc8180x-adsp-pas - qcom,sc8180x-cdsp-pas + - qcom,sm6350-adsp-pas - qcom,sm8150-slpi-pas - qcom,sm8250-adsp-pas - qcom,sm8250-slpi-pas diff --git a/Documentation/devicetree/bindings/remoteproc/renesas,rcar-rproc.yaml b/Documentation/devicetree/bindings/remoteproc/renesas,rcar-rproc.yaml new file mode 100644 index 000000000000..a7d25fa920e5 --- /dev/null +++ b/Documentation/devicetree/bindings/remoteproc/renesas,rcar-rproc.yaml @@ -0,0 +1,65 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +%YAML 1.2 +--- +$id: "http://devicetree.org/schemas/remoteproc/renesas,rcar-rproc.yaml#" +$schema: "http://devicetree.org/meta-schemas/core.yaml#" + +title: Renesas R-Car remote processor controller bindings + +maintainers: + - Julien Massot <julien.massot@iot.bzh> + +description: | + This document defines the bindings for the remoteproc component that loads and + boots firmwares on the Renesas R-Car family chipset. + R-Car gen3 family may have a realtime processor, this processor shares peripheral + and RAM with the host processor with the same address map. + +properties: + compatible: + const: renesas,rcar-cr7 + + resets: + maxItems: 1 + + power-domains: + maxItems: 1 + + memory-region: + description: + List of phandles to the reserved memory regions associated with the + remoteproc device. This is variable and describes the memories shared with + the remote processor (e.g. remoteproc firmware and carveouts, rpmsg + vrings, ...). + (see ../reserved-memory/reserved-memory.yaml) + +required: + - compatible + - resets + - memory-region + - power-domains + +additionalProperties: false + +examples: + - | + #include <dt-bindings/clock/r8a7795-cpg-mssr.h> + #include <dt-bindings/power/r8a7795-sysc.h> + reserved-memory { + #address-cells = <2>; + #size-cells = <2>; + + cr7_ram: cr7_ram@40040000 { + no-map; + reg = <0x0 0x40040000 0x0 0x1fc0000>; + }; + }; + + cr7_rproc: cr7 { + compatible = "renesas,rcar-cr7"; + memory-region = <&cr7_ram>; + power-domains = <&sysc R8A7795_PD_CR7>; + resets = <&cpg 222>; + }; + +... diff --git a/Documentation/devicetree/bindings/remoteproc/ti,k3-dsp-rproc.yaml b/Documentation/devicetree/bindings/remoteproc/ti,k3-dsp-rproc.yaml index 5ec6505ac408..7b56497eec4d 100644 --- a/Documentation/devicetree/bindings/remoteproc/ti,k3-dsp-rproc.yaml +++ b/Documentation/devicetree/bindings/remoteproc/ti,k3-dsp-rproc.yaml @@ -33,9 +33,11 @@ properties: enum: - ti,j721e-c66-dsp - ti,j721e-c71-dsp + - ti,j721s2-c71-dsp description: Use "ti,j721e-c66-dsp" for C66x DSPs on K3 J721E SoCs Use "ti,j721e-c71-dsp" for C71x DSPs on K3 J721E SoCs + Use "ti,j721s2-c71-dsp" for C71x DSPs on K3 J721S2 SoCs resets: description: | @@ -106,6 +108,7 @@ else: compatible: enum: - ti,j721e-c71-dsp + - ti,j721s2-c71-dsp then: properties: reg: diff --git a/Documentation/devicetree/bindings/remoteproc/ti,k3-r5f-rproc.yaml b/Documentation/devicetree/bindings/remoteproc/ti,k3-r5f-rproc.yaml index eeef255c4045..d9c7e8c2b268 100644 --- a/Documentation/devicetree/bindings/remoteproc/ti,k3-r5f-rproc.yaml +++ b/Documentation/devicetree/bindings/remoteproc/ti,k3-r5f-rproc.yaml @@ -38,6 +38,7 @@ properties: - ti,j721e-r5fss - ti,j7200-r5fss - ti,am64-r5fss + - ti,j721s2-r5fss power-domains: description: | @@ -64,9 +65,9 @@ properties: description: | Configuration Mode for the Dual R5F cores within the R5F cluster. Should be either a value of 1 (LockStep mode) or 0 (Split mode) on - most SoCs (AM65x, J721E, J7200), default is LockStep mode if omitted; - and should be either a value of 0 (Split mode) or 2 (Single-CPU mode) - on AM64x SoCs, default is Split mode if omitted. + most SoCs (AM65x, J721E, J7200, J721s2), default is LockStep mode if + omitted; and should be either a value of 0 (Split mode) or 2 + (Single-CPU mode) on AM64x SoCs, default is Split mode if omitted. # R5F Processor Child Nodes: # ========================== @@ -104,6 +105,7 @@ patternProperties: - ti,j721e-r5f - ti,j7200-r5f - ti,am64-r5f + - ti,j721s2-r5f reg: items: diff --git a/Documentation/devicetree/bindings/reserved-memory/nvidia,tegra210-emc-table.yaml b/Documentation/devicetree/bindings/reserved-memory/nvidia,tegra210-emc-table.yaml new file mode 100644 index 000000000000..035a50fe3ee4 --- /dev/null +++ b/Documentation/devicetree/bindings/reserved-memory/nvidia,tegra210-emc-table.yaml @@ -0,0 +1,31 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/reserved-memory/nvidia,tegra210-emc-table.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: NVIDIA Tegra210 EMC Frequency Table Device Tree Bindings + +maintainers: + - Thierry Reding <thierry.reding@gmail.com> + - Jon Hunter <jonathanh@nvidia.com> + +description: On Tegra210, firmware passes a binary representation of the + EMC frequency table via a reserved memory region. + +allOf: + - $ref: "reserved-memory.yaml" + +properties: + compatible: + const: nvidia,tegra210-emc-table + + reg: + description: region of memory reserved by firmware to pass the EMC + frequency table + +unevaluatedProperties: false + +required: + - compatible + - reg diff --git a/Documentation/devicetree/bindings/reserved-memory/qcom,cmd-db.txt b/Documentation/devicetree/bindings/reserved-memory/qcom,cmd-db.txt deleted file mode 100644 index 68395530c0a5..000000000000 --- a/Documentation/devicetree/bindings/reserved-memory/qcom,cmd-db.txt +++ /dev/null @@ -1,37 +0,0 @@ -Command DB ---------- - -Command DB is a database that provides a mapping between resource key and the -resource address for a system resource managed by a remote processor. The data -is stored in a shared memory region and is loaded by the remote processor. - -Some of the Qualcomm Technologies Inc SoC's have hardware accelerators for -controlling shared resources. Depending on the board configuration the shared -resource properties may change. These properties are dynamically probed by the -remote processor and made available in the shared memory. - -The bindings for Command DB is specified in the reserved-memory section in -devicetree. The devicetree representation of the command DB driver should be: - -Properties: -- compatible: - Usage: required - Value type: <string> - Definition: Should be "qcom,cmd-db" - -- reg: - Usage: required - Value type: <prop encoded array> - Definition: The register address that points to the actual location of - the Command DB in memory. - -Example: - - reserved-memory { - [...] - reserved-memory@85fe0000 { - reg = <0x0 0x85fe0000 0x0 0x20000>; - compatible = "qcom,cmd-db"; - no-map; - }; - }; diff --git a/Documentation/devicetree/bindings/reserved-memory/qcom,cmd-db.yaml b/Documentation/devicetree/bindings/reserved-memory/qcom,cmd-db.yaml new file mode 100644 index 000000000000..df1b5e0ed3f4 --- /dev/null +++ b/Documentation/devicetree/bindings/reserved-memory/qcom,cmd-db.yaml @@ -0,0 +1,46 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: "http://devicetree.org/schemas/reserved-memory/qcom,cmd-db.yaml#" +$schema: "http://devicetree.org/meta-schemas/core.yaml#" + +title: Qualcomm Command DB + +description: | + Command DB is a database that provides a mapping between resource key and the + resource address for a system resource managed by a remote processor. The data + is stored in a shared memory region and is loaded by the remote processor. + + Some of the Qualcomm Technologies Inc SoC's have hardware accelerators for + controlling shared resources. Depending on the board configuration the shared + resource properties may change. These properties are dynamically probed by the + remote processor and made available in the shared memory. + +maintainers: + - Bjorn Andersson <bjorn.andersson@linaro.org> + +allOf: + - $ref: "reserved-memory.yaml" + +properties: + compatible: + const: qcom,cmd-db + +required: + - reg + +unevaluatedProperties: false + +examples: + - | + reserved-memory { + #address-cells = <1>; + #size-cells = <1>; + ranges; + + reserved-memory@85fe0000 { + reg = <0x85fe0000 0x20000>; + compatible = "qcom,cmd-db"; + no-map; + }; + }; diff --git a/Documentation/devicetree/bindings/reserved-memory/qcom,rmtfs-mem.txt b/Documentation/devicetree/bindings/reserved-memory/qcom,rmtfs-mem.txt deleted file mode 100644 index 8562ba1dce69..000000000000 --- a/Documentation/devicetree/bindings/reserved-memory/qcom,rmtfs-mem.txt +++ /dev/null @@ -1,51 +0,0 @@ -Qualcomm Remote File System Memory binding - -This binding describes the Qualcomm remote filesystem memory, which serves the -purpose of describing the shared memory region used for remote processors to -access block device data using the Remote Filesystem protocol. - -- compatible: - Usage: required - Value type: <stringlist> - Definition: must be: - "qcom,rmtfs-mem" - -- reg: - Usage: required for static allocation - Value type: <prop-encoded-array> - Definition: must specify base address and size of the memory region, - as described in reserved-memory.txt - -- size: - Usage: required for dynamic allocation - Value type: <prop-encoded-array> - Definition: must specify a size of the memory region, as described in - reserved-memory.txt - -- qcom,client-id: - Usage: required - Value type: <u32> - Definition: identifier of the client to use this region for buffers. - -- qcom,vmid: - Usage: optional - Value type: <u32> - Definition: vmid of the remote processor, to set up memory protection. - -= EXAMPLE -The following example shows the remote filesystem memory setup for APQ8016, -with the rmtfs region for the Hexagon DSP (id #1) located at 0x86700000. - - reserved-memory { - #address-cells = <2>; - #size-cells = <2>; - ranges; - - rmtfs@86700000 { - compatible = "qcom,rmtfs-mem"; - reg = <0x0 0x86700000 0x0 0xe0000>; - no-map; - - qcom,client-id = <1>; - }; - }; diff --git a/Documentation/devicetree/bindings/reserved-memory/qcom,rmtfs-mem.yaml b/Documentation/devicetree/bindings/reserved-memory/qcom,rmtfs-mem.yaml new file mode 100644 index 000000000000..2998f1c8f0db --- /dev/null +++ b/Documentation/devicetree/bindings/reserved-memory/qcom,rmtfs-mem.yaml @@ -0,0 +1,53 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: "http://devicetree.org/schemas/reserved-memory/qcom,rmtfs-mem.yaml#" +$schema: "http://devicetree.org/meta-schemas/core.yaml#" + +title: Qualcomm Remote File System Memory + +description: | + This binding describes the Qualcomm remote filesystem memory, which serves the + purpose of describing the shared memory region used for remote processors to + access block device data using the Remote Filesystem protocol. + +maintainers: + - Bjorn Andersson <bjorn.andersson@linaro.org> + +allOf: + - $ref: "reserved-memory.yaml" + +properties: + compatible: + const: qcom,rmtfs-mem + + qcom,client-id: + $ref: /schemas/types.yaml#/definitions/uint32 + description: > + identifier of the client to use this region for buffers + + qcom,vmid: + $ref: /schemas/types.yaml#/definitions/uint32 + description: > + vmid of the remote processor, to set up memory protection + +required: + - qcom,client-id + +unevaluatedProperties: false + +examples: + - | + reserved-memory { + #address-cells = <1>; + #size-cells = <1>; + ranges; + + rmtfs@86700000 { + compatible = "qcom,rmtfs-mem"; + reg = <0x86700000 0xe0000>; + no-map; + + qcom,client-id = <1>; + }; + }; diff --git a/Documentation/devicetree/bindings/reset/brcm,brcmstb-reset.txt b/Documentation/devicetree/bindings/reset/brcm,brcmstb-reset.txt deleted file mode 100644 index ee59409640f2..000000000000 --- a/Documentation/devicetree/bindings/reset/brcm,brcmstb-reset.txt +++ /dev/null @@ -1,27 +0,0 @@ -Broadcom STB SW_INIT-style reset controller -=========================================== - -Broadcom STB SoCs have a SW_INIT-style reset controller with separate -SET/CLEAR/STATUS registers and possibly multiple banks, each of 32 bit -reset lines. - -Please also refer to reset.txt in this directory for common reset -controller binding usage. - -Required properties: -- compatible: should be brcm,brcmstb-reset -- reg: register base and length -- #reset-cells: must be set to 1 - -Example: - - reset: reset-controller@8404318 { - compatible = "brcm,brcmstb-reset"; - reg = <0x8404318 0x30>; - #reset-cells = <1>; - }; - - ðernet_switch { - resets = <&reset 26>; - reset-names = "switch"; - }; diff --git a/Documentation/devicetree/bindings/reset/brcm,brcmstb-reset.yaml b/Documentation/devicetree/bindings/reset/brcm,brcmstb-reset.yaml new file mode 100644 index 000000000000..e00efa88a198 --- /dev/null +++ b/Documentation/devicetree/bindings/reset/brcm,brcmstb-reset.yaml @@ -0,0 +1,48 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +%YAML 1.2 +--- +$id: "http://devicetree.org/schemas/reset/brcm,brcmstb-reset.yaml#" +$schema: "http://devicetree.org/meta-schemas/core.yaml#" + +title: Broadcom STB SW_INIT-style reset controller + +description: + Broadcom STB SoCs have a SW_INIT-style reset controller with separate + SET/CLEAR/STATUS registers and possibly multiple banks, each of 32 bit + reset lines. + + Please also refer to reset.txt in this directory for common reset + controller binding usage. + +maintainers: + - Florian Fainelli <f.fainelli@gmail.com> + +properties: + compatible: + const: brcm,brcmstb-reset + + reg: + maxItems: 1 + + "#reset-cells": + const: 1 + +required: + - compatible + - reg + - "#reset-cells" + +additionalProperties: false + +examples: + - | + reset: reset-controller@8404318 { + compatible = "brcm,brcmstb-reset"; + reg = <0x8404318 0x30>; + #reset-cells = <1>; + }; + + ethernet_switch { + resets = <&reset 26>; + reset-names = "switch"; + }; diff --git a/Documentation/devicetree/bindings/reset/renesas,rst.yaml b/Documentation/devicetree/bindings/reset/renesas,rst.yaml index 620cd0538bbe..bbe313bf1796 100644 --- a/Documentation/devicetree/bindings/reset/renesas,rst.yaml +++ b/Documentation/devicetree/bindings/reset/renesas,rst.yaml @@ -48,6 +48,7 @@ properties: - renesas,r8a77990-rst # R-Car E3 - renesas,r8a77995-rst # R-Car D3 - renesas,r8a779a0-rst # R-Car V3U + - renesas,r8a779f0-rst # R-Car S4-8 reg: maxItems: 1 diff --git a/Documentation/devicetree/bindings/reset/starfive,jh7100-reset.yaml b/Documentation/devicetree/bindings/reset/starfive,jh7100-reset.yaml new file mode 100644 index 000000000000..300359a5e14b --- /dev/null +++ b/Documentation/devicetree/bindings/reset/starfive,jh7100-reset.yaml @@ -0,0 +1,38 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/reset/starfive,jh7100-reset.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: StarFive JH7100 SoC Reset Controller Device Tree Bindings + +maintainers: + - Emil Renner Berthing <kernel@esmil.dk> + +properties: + compatible: + enum: + - starfive,jh7100-reset + + reg: + maxItems: 1 + + "#reset-cells": + const: 1 + +required: + - compatible + - reg + - "#reset-cells" + +additionalProperties: false + +examples: + - | + reset-controller@11840000 { + compatible = "starfive,jh7100-reset"; + reg = <0x11840000 0x10000>; + #reset-cells = <1>; + }; + +... diff --git a/Documentation/devicetree/bindings/rng/apm,rng.txt b/Documentation/devicetree/bindings/rng/apm,rng.txt deleted file mode 100644 index 4dde4b06cdd9..000000000000 --- a/Documentation/devicetree/bindings/rng/apm,rng.txt +++ /dev/null @@ -1,17 +0,0 @@ -APM X-Gene SoC random number generator. - -Required properties: - -- compatible : should be "apm,xgene-rng" -- reg : specifies base physical address and size of the registers map -- clocks : phandle to clock-controller plus clock-specifier pair -- interrupts : specify the fault interrupt for the RNG device - -Example: - - rng: rng@10520000 { - compatible = "apm,xgene-rng"; - reg = <0x0 0x10520000 0x0 0x100>; - interrupts = <0x0 0x41 0x4>; - clocks = <&rngpkaclk 0>; - }; diff --git a/Documentation/devicetree/bindings/rng/apm,x-gene-rng.yaml b/Documentation/devicetree/bindings/rng/apm,x-gene-rng.yaml new file mode 100644 index 000000000000..02be143cc829 --- /dev/null +++ b/Documentation/devicetree/bindings/rng/apm,x-gene-rng.yaml @@ -0,0 +1,47 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/rng/apm,x-gene-rng.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: APM X-Gene SoC Random Number Generator + +maintainers: + - Khuong Dinh <khuong@os.amperecomputing.com> + +properties: + compatible: + const: apm,xgene-rng + + clocks: + maxItems: 1 + + interrupts: + maxItems: 1 + + reg: + maxItems: 1 + +required: + - compatible + - clocks + - interrupts + - reg + +additionalProperties: false + +examples: + - | + #include <dt-bindings/interrupt-controller/arm-gic.h> + + soc { + #address-cells = <2>; + #size-cells = <2>; + + rng@10520000 { + compatible = "apm,xgene-rng"; + reg = <0x0 0x10520000 0x0 0x100>; + interrupts = <GIC_SPI 65 IRQ_TYPE_LEVEL_HIGH>; + clocks = <&rngpkaclk 0>; + }; + }; diff --git a/Documentation/devicetree/bindings/rng/atmel,at91-trng.yaml b/Documentation/devicetree/bindings/rng/atmel,at91-trng.yaml new file mode 100644 index 000000000000..c1527637eb74 --- /dev/null +++ b/Documentation/devicetree/bindings/rng/atmel,at91-trng.yaml @@ -0,0 +1,51 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/rng/atmel,at91-trng.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Atmel AT91 True Random Number Generator + +maintainers: + - Nicolas Ferre <nicolas.ferre@microchip.com> + - Alexandre Belloni <alexandre.belloni@bootlin.com> + - Ludovic Desroches <ludovic.desroches@microchip.com> + +properties: + compatible: + oneOf: + - enum: + - atmel,at91sam9g45-trng + - microchip,sam9x60-trng + - items: + - enum: + - microchip,sama7g5-trng + - const: atmel,at91sam9g45-trng + + clocks: + maxItems: 1 + + interrupts: + maxItems: 1 + + reg: + maxItems: 1 + +required: + - compatible + - clocks + - interrupts + - reg + +additionalProperties: false + +examples: + - | + #include <dt-bindings/interrupt-controller/irq.h> + + rng@fffcc000 { + compatible = "atmel,at91sam9g45-trng"; + reg = <0xfffcc000 0x4000>; + interrupts = <6 IRQ_TYPE_LEVEL_HIGH 0>; + clocks = <&trng_clk>; + }; diff --git a/Documentation/devicetree/bindings/rng/atmel-trng.txt b/Documentation/devicetree/bindings/rng/atmel-trng.txt deleted file mode 100644 index 3900ee4f3532..000000000000 --- a/Documentation/devicetree/bindings/rng/atmel-trng.txt +++ /dev/null @@ -1,16 +0,0 @@ -Atmel TRNG (True Random Number Generator) block - -Required properties: -- compatible : Should be "atmel,at91sam9g45-trng" or "microchip,sam9x60-trng" -- reg : Offset and length of the register set of this block -- interrupts : the interrupt number for the TRNG block -- clocks: should contain the TRNG clk source - -Example: - -trng@fffcc000 { - compatible = "atmel,at91sam9g45-trng"; - reg = <0xfffcc000 0x4000>; - interrupts = <6 IRQ_TYPE_LEVEL_HIGH 0>; - clocks = <&trng_clk>; -}; diff --git a/Documentation/devicetree/bindings/rng/brcm,iproc-rng200.txt b/Documentation/devicetree/bindings/rng/brcm,iproc-rng200.txt deleted file mode 100644 index 802523196ee5..000000000000 --- a/Documentation/devicetree/bindings/rng/brcm,iproc-rng200.txt +++ /dev/null @@ -1,16 +0,0 @@ -HWRNG support for the iproc-rng200 driver - -Required properties: -- compatible : Must be one of: - "brcm,bcm2711-rng200" - "brcm,bcm7211-rng200" - "brcm,bcm7278-rng200" - "brcm,iproc-rng200" -- reg : base address and size of control register block - -Example: - -rng { - compatible = "brcm,iproc-rng200"; - reg = <0x18032000 0x28>; -}; diff --git a/Documentation/devicetree/bindings/rng/brcm,iproc-rng200.yaml b/Documentation/devicetree/bindings/rng/brcm,iproc-rng200.yaml new file mode 100644 index 000000000000..a00e9bc8b609 --- /dev/null +++ b/Documentation/devicetree/bindings/rng/brcm,iproc-rng200.yaml @@ -0,0 +1,30 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +%YAML 1.2 +--- +$id: "http://devicetree.org/schemas/rng/brcm,iproc-rng200.yaml#" +$schema: "http://devicetree.org/meta-schemas/core.yaml#" + +title: HWRNG support for the iproc-rng200 driver + +maintainers: + - Florian Fainelli <f.fainelli@gmail.com> + +properties: + compatible: + enum: + - brcm,bcm2711-rng200 + - brcm,bcm7211-rng200 + - brcm,bcm7278-rng200 + - brcm,iproc-rng200 + + reg: + maxItems: 1 + +additionalProperties: false + +examples: + - | + rng@18032000 { + compatible = "brcm,iproc-rng200"; + reg = <0x18032000 0x28>; + }; diff --git a/Documentation/devicetree/bindings/rng/ks-sa-rng.txt b/Documentation/devicetree/bindings/rng/ks-sa-rng.txt deleted file mode 100644 index b7a65b487901..000000000000 --- a/Documentation/devicetree/bindings/rng/ks-sa-rng.txt +++ /dev/null @@ -1,21 +0,0 @@ -Keystone SoC Hardware Random Number Generator(HWRNG) Module - -On Keystone SoCs HWRNG module is a submodule of the Security Accelerator. - -- compatible: should be "ti,keystone-rng" -- ti,syscon-sa-cfg: phandle to syscon node of the SA configuration registers. - This registers are shared between hwrng and crypto drivers. -- clocks: phandle to the reference clocks for the subsystem -- clock-names: functional clock name. Should be set to "fck" -- reg: HWRNG module register space - -Example: -/* K2HK */ - -rng@24000 { - compatible = "ti,keystone-rng"; - ti,syscon-sa-cfg = <&sa_config>; - clocks = <&clksa>; - clock-names = "fck"; - reg = <0x24000 0x1000>; -}; diff --git a/Documentation/devicetree/bindings/rng/nuvoton,npcm-rng.txt b/Documentation/devicetree/bindings/rng/nuvoton,npcm-rng.txt deleted file mode 100644 index 65c04172fc8c..000000000000 --- a/Documentation/devicetree/bindings/rng/nuvoton,npcm-rng.txt +++ /dev/null @@ -1,12 +0,0 @@ -NPCM SoC Random Number Generator - -Required properties: -- compatible : "nuvoton,npcm750-rng" for the NPCM7XX BMC. -- reg : Specifies physical base address and size of the registers. - -Example: - -rng: rng@f000b000 { - compatible = "nuvoton,npcm750-rng"; - reg = <0xf000b000 0x8>; -}; diff --git a/Documentation/devicetree/bindings/rng/nuvoton,npcm-rng.yaml b/Documentation/devicetree/bindings/rng/nuvoton,npcm-rng.yaml new file mode 100644 index 000000000000..abd134c9d400 --- /dev/null +++ b/Documentation/devicetree/bindings/rng/nuvoton,npcm-rng.yaml @@ -0,0 +1,35 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/rng/nuvoton,npcm-rng.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Nuvoton NPCM SoC Random Number Generator + +maintainers: + - Avi Fishman <avifishman70@gmail.com> + - Tomer Maimon <tmaimon77@gmail.com> + - Tali Perry <tali.perry1@gmail.com> + - Patrick Venture <venture@google.com> + - Nancy Yuen <yuenn@google.com> + - Benjamin Fair <benjaminfair@google.com> + +properties: + compatible: + const: nuvoton,npcm750-rng + + reg: + maxItems: 1 + +required: + - compatible + - reg + +additionalProperties: false + +examples: + - | + rng@f000b000 { + compatible = "nuvoton,npcm750-rng"; + reg = <0xf000b000 0x8>; + }; diff --git a/Documentation/devicetree/bindings/rng/omap3_rom_rng.txt b/Documentation/devicetree/bindings/rng/omap3_rom_rng.txt deleted file mode 100644 index f315c9723bd2..000000000000 --- a/Documentation/devicetree/bindings/rng/omap3_rom_rng.txt +++ /dev/null @@ -1,27 +0,0 @@ -OMAP ROM RNG driver binding - -Secure SoCs may provide RNG via secure ROM calls like Nokia N900 does. The -implementation can depend on the SoC secure ROM used. - -- compatible: - Usage: required - Value type: <string> - Definition: must be "nokia,n900-rom-rng" - -- clocks: - Usage: required - Value type: <prop-encoded-array> - Definition: reference to the the RNG interface clock - -- clock-names: - Usage: required - Value type: <stringlist> - Definition: must be "ick" - -Example: - - rom_rng: rng { - compatible = "nokia,n900-rom-rng"; - clocks = <&rng_ick>; - clock-names = "ick"; - }; diff --git a/Documentation/devicetree/bindings/rng/st,rng.txt b/Documentation/devicetree/bindings/rng/st,rng.txt deleted file mode 100644 index 35734bc282e9..000000000000 --- a/Documentation/devicetree/bindings/rng/st,rng.txt +++ /dev/null @@ -1,15 +0,0 @@ -STMicroelectronics HW Random Number Generator ----------------------------------------------- - -Required parameters: -compatible : Should be "st,rng" -reg : Base address and size of IP's register map. -clocks : Phandle to device's clock (See: ../clocks/clock-bindings.txt) - -Example: - -rng@fee80000 { - compatible = "st,rng"; - reg = <0xfee80000 0x1000>; - clocks = <&clk_sysin>; -} diff --git a/Documentation/devicetree/bindings/rng/st,rng.yaml b/Documentation/devicetree/bindings/rng/st,rng.yaml new file mode 100644 index 000000000000..ff1211ef9046 --- /dev/null +++ b/Documentation/devicetree/bindings/rng/st,rng.yaml @@ -0,0 +1,35 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/rng/st,rng.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: STMicroelectronics Hardware Random Number Generator + +maintainers: + - Patrice Chotard <patrice.chotard@foss.st.com> + +properties: + compatible: + const: st,rng + + clocks: + maxItems: 1 + + reg: + maxItems: 1 + +required: + - compatible + - clocks + - reg + +additionalProperties: false + +examples: + - | + rng@fee80000 { + compatible = "st,rng"; + reg = <0xfee80000 0x1000>; + clocks = <&clk_sysin>; + }; diff --git a/Documentation/devicetree/bindings/rng/ti,keystone-rng.yaml b/Documentation/devicetree/bindings/rng/ti,keystone-rng.yaml new file mode 100644 index 000000000000..e749818fc193 --- /dev/null +++ b/Documentation/devicetree/bindings/rng/ti,keystone-rng.yaml @@ -0,0 +1,50 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/rng/ti,keystone-rng.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Keystone SoC Hardware Random Number Generator + +maintainers: + - Nishanth Menon <nm@ti.com> + - Santosh Shilimkar <ssantosh@kernel.org> + +properties: + compatible: + const: ti,keystone-rng + + clocks: + maxItems: 1 + + clock-names: + items: + - const: fck + + reg: + maxItems: 1 + + ti,syscon-sa-cfg: + $ref: "/schemas/types.yaml#/definitions/phandle" + description: | + Phandle to syscon node of the SA configuration registers. These + registers are shared between HWRNG and crypto drivers. + +required: + - compatible + - clocks + - clock-names + - reg + - ti,syscon-sa-cfg + +additionalProperties: false + +examples: + - | + rng@24000 { + compatible = "ti,keystone-rng"; + ti,syscon-sa-cfg = <&sa_config>; + clocks = <&clksa>; + clock-names = "fck"; + reg = <0x24000 0x1000>; + }; diff --git a/Documentation/devicetree/bindings/rng/ti,omap-rom-rng.yaml b/Documentation/devicetree/bindings/rng/ti,omap-rom-rng.yaml new file mode 100644 index 000000000000..9a58440b1ab1 --- /dev/null +++ b/Documentation/devicetree/bindings/rng/ti,omap-rom-rng.yaml @@ -0,0 +1,41 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/rng/ti,omap-rom-rng.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: OMAP ROM Random Number Generator + +maintainers: + - Pali Rohár <pali@kernel.org> + - Tony Lindgren <tony@atomide.com> + +description: + Secure SoCs may provide RNG via secure ROM calls like Nokia N900 does. + The implementation can depend on the SoC secure ROM used. + +properties: + compatible: + const: nokia,n900-rom-rng + + clocks: + maxItems: 1 + + clock-names: + items: + - const: ick + +required: + - compatible + - clocks + - clock-names + +additionalProperties: false + +examples: + - | + rng { + compatible = "nokia,n900-rom-rng"; + clocks = <&rng_ick>; + clock-names = "ick"; + }; diff --git a/Documentation/devicetree/bindings/rng/timeriomem_rng.txt b/Documentation/devicetree/bindings/rng/timeriomem_rng.txt deleted file mode 100644 index fb4846160047..000000000000 --- a/Documentation/devicetree/bindings/rng/timeriomem_rng.txt +++ /dev/null @@ -1,25 +0,0 @@ -HWRNG support for the timeriomem_rng driver - -Required properties: -- compatible : "timeriomem_rng" -- reg : base address to sample from -- period : wait time in microseconds to use between samples - -Optional properties: -- quality : estimated number of bits of true entropy per 1024 bits read from the - rng. Defaults to zero which causes the kernel's default quality to - be used instead. Note that the default quality is usually zero - which disables using this rng to automatically fill the kernel's - entropy pool. - -N.B. currently 'reg' must be at least four bytes wide and 32-bit aligned - -Example: - -hwrng@44 { - #address-cells = <1>; - #size-cells = <1>; - compatible = "timeriomem_rng"; - reg = <0x44 0x04>; - period = <1000000>; -}; diff --git a/Documentation/devicetree/bindings/rng/timeriomem_rng.yaml b/Documentation/devicetree/bindings/rng/timeriomem_rng.yaml new file mode 100644 index 000000000000..84bf518a5549 --- /dev/null +++ b/Documentation/devicetree/bindings/rng/timeriomem_rng.yaml @@ -0,0 +1,48 @@ +# SPDX-License-Identifier: GPL-2.0-only +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/rng/timeriomem_rng.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: TimerIO Random Number Generator + +maintainers: + - Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com> + +properties: + compatible: + const: timeriomem_rng + + period: + $ref: /schemas/types.yaml#/definitions/uint32 + description: wait time in microseconds to use between samples + + quality: + $ref: /schemas/types.yaml#/definitions/uint32 + default: 0 + description: + Estimated number of bits of true entropy per 1024 bits read from the rng. + Defaults to zero which causes the kernel's default quality to be used + instead. Note that the default quality is usually zero which disables + using this rng to automatically fill the kernel's entropy pool. + + reg: + maxItems: 1 + description: + Base address to sample from. Currently 'reg' must be at least four bytes + wide and 32-bit aligned. + +required: + - compatible + - period + - reg + +additionalProperties: false + +examples: + - | + rng@44 { + compatible = "timeriomem_rng"; + reg = <0x44 0x04>; + period = <1000000>; + }; diff --git a/Documentation/devicetree/bindings/rtc/brcm,brcmstb-waketimer.txt b/Documentation/devicetree/bindings/rtc/brcm,brcmstb-waketimer.txt deleted file mode 100644 index d946f28502b3..000000000000 --- a/Documentation/devicetree/bindings/rtc/brcm,brcmstb-waketimer.txt +++ /dev/null @@ -1,20 +0,0 @@ -Broadcom STB wake-up Timer - -The Broadcom STB wake-up timer provides a 27Mhz resolution timer, with the -ability to wake up the system from low-power suspend/standby modes. - -Required properties: -- compatible : should contain "brcm,brcmstb-waketimer" -- reg : the register start and length for the WKTMR block -- interrupts : The TIMER interrupt -- clocks : The phandle to the UPG fixed clock (27Mhz domain) - -Example: - -waketimer@f0411580 { - compatible = "brcm,brcmstb-waketimer"; - reg = <0xf0411580 0x14>; - interrupts = <0x3>; - interrupt-parent = <&aon_pm_l2_intc>; - clocks = <&upg_fixed>; -}; diff --git a/Documentation/devicetree/bindings/rtc/brcm,brcmstb-waketimer.yaml b/Documentation/devicetree/bindings/rtc/brcm,brcmstb-waketimer.yaml new file mode 100644 index 000000000000..9fe079917a98 --- /dev/null +++ b/Documentation/devicetree/bindings/rtc/brcm,brcmstb-waketimer.yaml @@ -0,0 +1,44 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/rtc/brcm,brcmstb-waketimer.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Broadcom STB wake-up Timer + +maintainers: + - Florian Fainelli <f.fainelli@gmail.com> + +description: + The Broadcom STB wake-up timer provides a 27Mhz resolution timer, with the + ability to wake up the system from low-power suspend/standby modes. + +allOf: + - $ref: "rtc.yaml#" + +properties: + compatible: + const: brcm,brcmstb-waketimer + + reg: + maxItems: 1 + + interrupts: + description: the TIMER interrupt + maxItems: 1 + + clocks: + description: clock reference in the 27MHz domain + maxItems: 1 + +additionalProperties: false + +examples: + - | + rtc@f0411580 { + compatible = "brcm,brcmstb-waketimer"; + reg = <0xf0411580 0x14>; + interrupts = <0x3>; + interrupt-parent = <&aon_pm_l2_intc>; + clocks = <&upg_fixed>; + }; diff --git a/Documentation/devicetree/bindings/rtc/epson,rx8900.yaml b/Documentation/devicetree/bindings/rtc/epson,rx8900.yaml index 29fe39bb08ad..d12855e7ffd7 100644 --- a/Documentation/devicetree/bindings/rtc/epson,rx8900.yaml +++ b/Documentation/devicetree/bindings/rtc/epson,rx8900.yaml @@ -15,6 +15,7 @@ allOf: properties: compatible: enum: + - epson,rx8804 - epson,rx8900 - microcrystal,rv8803 diff --git a/Documentation/devicetree/bindings/rtc/nvidia,tegra20-rtc.txt b/Documentation/devicetree/bindings/rtc/nvidia,tegra20-rtc.txt deleted file mode 100644 index b7d98ed3e098..000000000000 --- a/Documentation/devicetree/bindings/rtc/nvidia,tegra20-rtc.txt +++ /dev/null @@ -1,24 +0,0 @@ -NVIDIA Tegra20 real-time clock - -The Tegra RTC maintains seconds and milliseconds counters, and five alarm -registers. The alarms and other interrupts may wake the system from low-power -state. - -Required properties: - -- compatible : For Tegra20, must contain "nvidia,tegra20-rtc". Otherwise, - must contain '"nvidia,<chip>-rtc", "nvidia,tegra20-rtc"', where <chip> - can be tegra30, tegra114, tegra124, or tegra132. -- reg : Specifies base physical address and size of the registers. -- interrupts : A single interrupt specifier. -- clocks : Must contain one entry, for the module clock. - See ../clocks/clock-bindings.txt for details. - -Example: - -timer { - compatible = "nvidia,tegra20-rtc"; - reg = <0x7000e000 0x100>; - interrupts = <0 2 0x04>; - clocks = <&tegra_car 4>; -}; diff --git a/Documentation/devicetree/bindings/rtc/nvidia,tegra20-rtc.yaml b/Documentation/devicetree/bindings/rtc/nvidia,tegra20-rtc.yaml new file mode 100644 index 000000000000..17d6280e5515 --- /dev/null +++ b/Documentation/devicetree/bindings/rtc/nvidia,tegra20-rtc.yaml @@ -0,0 +1,61 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/rtc/nvidia,tegra20-rtc.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: NVIDIA Tegra real-time clock + +maintainers: + - Thierry Reding <thierry.reding@gmail.com> + - Jon Hunter <jonathanh@nvidia.com> + +description: | + The Tegra RTC maintains seconds and milliseconds counters, and five + alarm registers. The alarms and other interrupts may wake the system + from low-power state. + +properties: + compatible: + oneOf: + - const: nvidia,tegra20-rtc + - items: + - enum: + - nvidia,tegra30-rtc + - nvidia,tegra114-rtc + - nvidia,tegra124-rtc + - nvidia,tegra210-rtc + - nvidia,tegra186-rtc + - nvidia,tegra194-rtc + - nvidia,tegra234-rtc + - const: nvidia,tegra20-rtc + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + clocks: + maxItems: 1 + + clock-names: + items: + - const: rtc + +additionalProperties: false + +required: + - compatible + - reg + - interrupts + - clocks + +examples: + - | + timer@7000e000 { + compatible = "nvidia,tegra20-rtc"; + reg = <0x7000e000 0x100>; + interrupts = <0 2 0x04>; + clocks = <&tegra_car 4>; + }; diff --git a/Documentation/devicetree/bindings/rtc/qcom-pm8xxx-rtc.yaml b/Documentation/devicetree/bindings/rtc/qcom-pm8xxx-rtc.yaml index 4fba6dba16f3..6fa7d9fc2dc7 100644 --- a/Documentation/devicetree/bindings/rtc/qcom-pm8xxx-rtc.yaml +++ b/Documentation/devicetree/bindings/rtc/qcom-pm8xxx-rtc.yaml @@ -19,7 +19,14 @@ properties: - qcom,pmk8350-rtc reg: - maxItems: 1 + minItems: 1 + maxItems: 2 + + reg-names: + minItems: 1 + items: + - const: rtc + - const: alarm interrupts: maxItems: 1 diff --git a/Documentation/devicetree/bindings/rtc/st,stm32-rtc.yaml b/Documentation/devicetree/bindings/rtc/st,stm32-rtc.yaml index 2359f541b770..764717ce1873 100644 --- a/Documentation/devicetree/bindings/rtc/st,stm32-rtc.yaml +++ b/Documentation/devicetree/bindings/rtc/st,stm32-rtc.yaml @@ -127,6 +127,7 @@ examples: st,syscfg = <&pwrcfg 0x00 0x100>; }; + - | #include <dt-bindings/interrupt-controller/arm-gic.h> #include <dt-bindings/clock/stm32mp1-clks.h> rtc@5c004000 { diff --git a/Documentation/devicetree/bindings/rtc/sunplus,sp7021-rtc.yaml b/Documentation/devicetree/bindings/rtc/sunplus,sp7021-rtc.yaml new file mode 100644 index 000000000000..fd1b3e71ff2c --- /dev/null +++ b/Documentation/devicetree/bindings/rtc/sunplus,sp7021-rtc.yaml @@ -0,0 +1,56 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +# Copyright (C) Sunplus Co., Ltd. 2021 +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/rtc/sunplus,sp7021-rtc.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Sunplus SP7021 Real Time Clock controller + +maintainers: + - Vincent Shih <vincent.sunplus@gmail.com> + +properties: + compatible: + const: sunplus,sp7021-rtc + + reg: + maxItems: 1 + + reg-names: + items: + - const: rtc + + clocks: + maxItems: 1 + + resets: + maxItems: 1 + + interrupts: + maxItems: 1 + +required: + - compatible + - reg + - reg-names + - clocks + - resets + - interrupts + +additionalProperties: false + +examples: + - | + #include <dt-bindings/interrupt-controller/irq.h> + + rtc: serial@9c003a00 { + compatible = "sunplus,sp7021-rtc"; + reg = <0x9c003a00 0x80>; + reg-names = "rtc"; + clocks = <&clkc 0x12>; + resets = <&rstc 0x02>; + interrupt-parent = <&intc>; + interrupts = <163 IRQ_TYPE_EDGE_RISING>; + }; +... diff --git a/Documentation/devicetree/bindings/serial/8250.yaml b/Documentation/devicetree/bindings/serial/8250.yaml index fa767440f281..3bab2f27b970 100644 --- a/Documentation/devicetree/bindings/serial/8250.yaml +++ b/Documentation/devicetree/bindings/serial/8250.yaml @@ -113,9 +113,10 @@ properties: - nvidia,tegra30-uart - nvidia,tegra114-uart - nvidia,tegra124-uart + - nvidia,tegra210-uart - nvidia,tegra186-uart - nvidia,tegra194-uart - - nvidia,tegra210-uart + - nvidia,tegra234-uart - const: nvidia,tegra20-uart reg: diff --git a/Documentation/devicetree/bindings/serial/amlogic,meson-uart.yaml b/Documentation/devicetree/bindings/serial/amlogic,meson-uart.yaml index 7487aa6ef849..72e8868db3e0 100644 --- a/Documentation/devicetree/bindings/serial/amlogic,meson-uart.yaml +++ b/Documentation/devicetree/bindings/serial/amlogic,meson-uart.yaml @@ -29,6 +29,7 @@ properties: - amlogic,meson8-uart - amlogic,meson8b-uart - amlogic,meson-gx-uart + - amlogic,meson-s4-uart - const: amlogic,meson-ao-uart - description: Everything-Else power domain UART controller enum: @@ -36,6 +37,7 @@ properties: - amlogic,meson8-uart - amlogic,meson8b-uart - amlogic,meson-gx-uart + - amlogic,meson-s4-uart reg: maxItems: 1 diff --git a/Documentation/devicetree/bindings/serial/fsl-lpuart.yaml b/Documentation/devicetree/bindings/serial/fsl-lpuart.yaml index a90c971b4f1f..6e04e3848261 100644 --- a/Documentation/devicetree/bindings/serial/fsl-lpuart.yaml +++ b/Documentation/devicetree/bindings/serial/fsl-lpuart.yaml @@ -21,9 +21,15 @@ properties: - fsl,ls1028a-lpuart - fsl,imx7ulp-lpuart - fsl,imx8qm-lpuart + - fsl,imxrt1050-lpuart - items: - - const: fsl,imx8qxp-lpuart + - enum: + - fsl,imx8qxp-lpuart + - fsl,imx8ulp-lpuart - const: fsl,imx7ulp-lpuart + - items: + - const: fsl,imx8qm-lpuart + - const: fsl,imx8qxp-lpuart reg: maxItems: 1 diff --git a/Documentation/devicetree/bindings/serial/nvidia,tegra194-tcu.txt b/Documentation/devicetree/bindings/serial/nvidia,tegra194-tcu.txt deleted file mode 100644 index 085a8591accd..000000000000 --- a/Documentation/devicetree/bindings/serial/nvidia,tegra194-tcu.txt +++ /dev/null @@ -1,35 +0,0 @@ -NVIDIA Tegra Combined UART (TCU) - -The TCU is a system for sharing a hardware UART instance among multiple -systems within the Tegra SoC. It is implemented through a mailbox- -based protocol where each "virtual UART" has a pair of mailboxes, one -for transmitting and one for receiving, that is used to communicate -with the hardware implementing the TCU. - -Required properties: -- name : Should be tcu -- compatible - Array of strings - One of: - - "nvidia,tegra194-tcu" -- mbox-names: - "rx" - Mailbox for receiving data from hardware UART - "tx" - Mailbox for transmitting data to hardware UART -- mboxes: Mailboxes corresponding to the mbox-names. - -This node is a mailbox consumer. See the following files for details of -the mailbox subsystem, and the specifiers implemented by the relevant -provider(s): - -- .../mailbox/mailbox.txt -- .../mailbox/nvidia,tegra186-hsp.txt - -Example bindings: ------------------ - -tcu: tcu { - compatible = "nvidia,tegra194-tcu"; - mboxes = <&hsp_top0 TEGRA_HSP_MBOX_TYPE_SM 0>, - <&hsp_aon TEGRA_HSP_MBOX_TYPE_SM 1>; - mbox-names = "rx", "tx"; -}; diff --git a/Documentation/devicetree/bindings/serial/nvidia,tegra194-tcu.yaml b/Documentation/devicetree/bindings/serial/nvidia,tegra194-tcu.yaml new file mode 100644 index 000000000000..e2d111b3e0b0 --- /dev/null +++ b/Documentation/devicetree/bindings/serial/nvidia,tegra194-tcu.yaml @@ -0,0 +1,61 @@ +# SPDX-License-Identifier: GPL-2.0 +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/serial/nvidia,tegra194-tcu.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: NVIDIA Tegra Combined UART (TCU) + +maintainers: + - Thierry Reding <thierry.reding@gmail.com> + - Jonathan Hunter <jonathanh@nvidia.com> + +description: + The TCU is a system for sharing a hardware UART instance among multiple + systems within the Tegra SoC. It is implemented through a mailbox- + based protocol where each "virtual UART" has a pair of mailboxes, one + for transmitting and one for receiving, that is used to communicate + with the hardware implementing the TCU. + +properties: + $nodename: + pattern: "^serial(@.*)?$" + + compatible: + oneOf: + - const: nvidia,tegra194-tcu + - items: + - enum: + - nvidia,tegra234-tcu + - const: nvidia,tegra194-tcu + + mbox-names: + items: + - const: rx + - const: tx + + mboxes: + description: | + List of phandles to mailbox channels used for receiving and + transmitting data from and to the hardware UART. + items: + - description: mailbox for receiving data from hardware UART + - description: mailbox for transmitting data to hardware UART + +required: + - compatible + - mbox-names + - mboxes + +additionalProperties: false + +examples: + - | + #include <dt-bindings/mailbox/tegra186-hsp.h> + + tcu: serial { + compatible = "nvidia,tegra194-tcu"; + mboxes = <&hsp_top0 TEGRA_HSP_MBOX_TYPE_SM 0>, + <&hsp_aon TEGRA_HSP_MBOX_TYPE_SM 1>; + mbox-names = "rx", "tx"; + }; diff --git a/Documentation/devicetree/bindings/serial/pl011.yaml b/Documentation/devicetree/bindings/serial/pl011.yaml index 5ea00f8a283d..d8aed84abcd3 100644 --- a/Documentation/devicetree/bindings/serial/pl011.yaml +++ b/Documentation/devicetree/bindings/serial/pl011.yaml @@ -91,6 +91,9 @@ properties: 3000ms. default: 3000 + resets: + maxItems: 1 + required: - compatible - reg diff --git a/Documentation/devicetree/bindings/serial/renesas,sci.yaml b/Documentation/devicetree/bindings/serial/renesas,sci.yaml index 22ed2f0b1dc3..8dda4e10e09d 100644 --- a/Documentation/devicetree/bindings/serial/renesas,sci.yaml +++ b/Documentation/devicetree/bindings/serial/renesas,sci.yaml @@ -14,7 +14,15 @@ allOf: properties: compatible: - const: renesas,sci + oneOf: + - items: + - enum: + - renesas,r9a07g044-sci # RZ/G2{L,LC} + - renesas,r9a07g054-sci # RZ/V2L + - const: renesas,sci # generic SCI compatible UART + + - items: + - const: renesas,sci # generic SCI compatible UART reg: maxItems: 1 @@ -54,18 +62,46 @@ required: - clocks - clock-names +if: + properties: + compatible: + contains: + enum: + - renesas,r9a07g044-sci + - renesas,r9a07g054-sci +then: + properties: + resets: + maxItems: 1 + + power-domains: + maxItems: 1 + + required: + - resets + - power-domains + unevaluatedProperties: false examples: - | + #include <dt-bindings/clock/r9a07g044-cpg.h> + #include <dt-bindings/interrupt-controller/arm-gic.h> + aliases { serial0 = &sci0; }; - sci0: serial@ffff78 { - compatible = "renesas,sci"; - reg = <0xffff78 8>; - interrupts = <88 0>, <89 0>, <90 0>, <91 0>; - clocks = <&fclk>; + sci0: serial@1004d000 { + compatible = "renesas,r9a07g044-sci", "renesas,sci"; + reg = <0x1004d000 0x400>; + interrupts = <GIC_SPI 405 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 406 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 407 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 408 IRQ_TYPE_LEVEL_HIGH>; + interrupt-names = "eri", "rxi", "txi", "tei"; + clocks = <&cpg CPG_MOD R9A07G044_SCI0_CLKP>; clock-names = "fck"; + power-domains = <&cpg>; + resets = <&cpg R9A07G044_SCI0_RST>; }; diff --git a/Documentation/devicetree/bindings/serial/renesas,scif.yaml b/Documentation/devicetree/bindings/serial/renesas,scif.yaml index 6b8731f7f2fb..ba5d3e0acc63 100644 --- a/Documentation/devicetree/bindings/serial/renesas,scif.yaml +++ b/Documentation/devicetree/bindings/serial/renesas,scif.yaml @@ -66,7 +66,19 @@ properties: - items: - enum: + - renesas,scif-r8a779f0 # R-Car S4-8 + - const: renesas,rcar-gen4-scif # R-Car Gen4 + - const: renesas,scif # generic SCIF compatible UART + + - items: + - enum: - renesas,scif-r9a07g044 # RZ/G2{L,LC} + - renesas,scif-r9a07g054 # RZ/V2L + + - items: + - enum: + - renesas,scif-r9a07g054 # RZ/V2L + - const: renesas,scif-r9a07g044 # RZ/G2{L,LC} fallback for RZ/V2L reg: maxItems: 1 @@ -153,6 +165,9 @@ if: enum: - renesas,rcar-gen2-scif - renesas,rcar-gen3-scif + - renesas,rcar-gen4-scif + - renesas,scif-r9a07g044 + - renesas,scif-r9a07g054 then: required: - resets diff --git a/Documentation/devicetree/bindings/serial/snps-dw-apb-uart.yaml b/Documentation/devicetree/bindings/serial/snps-dw-apb-uart.yaml index b49fda5e608f..12137fe80acf 100644 --- a/Documentation/devicetree/bindings/serial/snps-dw-apb-uart.yaml +++ b/Documentation/devicetree/bindings/serial/snps-dw-apb-uart.yaml @@ -40,6 +40,11 @@ properties: - brcm,bcm11351-dw-apb-uart - brcm,bcm21664-dw-apb-uart - const: snps,dw-apb-uart + - items: + - enum: + - starfive,jh7100-hsuart + - starfive,jh7100-uart + - const: snps,dw-apb-uart - const: snps,dw-apb-uart reg: diff --git a/Documentation/devicetree/bindings/soc/bcm/brcm,bcm2835-vchiq.txt b/Documentation/devicetree/bindings/soc/bcm/brcm,bcm2835-vchiq.txt deleted file mode 100644 index f331316183f6..000000000000 --- a/Documentation/devicetree/bindings/soc/bcm/brcm,bcm2835-vchiq.txt +++ /dev/null @@ -1,17 +0,0 @@ -Broadcom VCHIQ firmware services - -Required properties: - -- compatible: Should be "brcm,bcm2835-vchiq" on BCM2835, otherwise - "brcm,bcm2836-vchiq". -- reg: Physical base address and length of the doorbell register pair -- interrupts: The interrupt number - See bindings/interrupt-controller/brcm,bcm2835-armctrl-ic.txt - -Example: - -mailbox@7e00b840 { - compatible = "brcm,bcm2835-vchiq"; - reg = <0x7e00b840 0xf>; - interrupts = <0 2>; -}; diff --git a/Documentation/devicetree/bindings/soc/bcm/brcm,bcm2835-vchiq.yaml b/Documentation/devicetree/bindings/soc/bcm/brcm,bcm2835-vchiq.yaml new file mode 100644 index 000000000000..e04439b3355b --- /dev/null +++ b/Documentation/devicetree/bindings/soc/bcm/brcm,bcm2835-vchiq.yaml @@ -0,0 +1,53 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/soc/bcm/brcm,bcm2835-vchiq.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Broadcom VCHIQ firmware services + +maintainers: + - Nicolas Saenz Julienne <nsaenz@kernel.org> + +description: + The VCHIQ communication channel can be provided by BCM283x and Capri SoCs, + to communicate with the VPU-side OS services. + +properties: + compatible: + oneOf: + - description: BCM2835 based boards + items: + - enum: + - brcm,bcm2835-vchiq + + - description: BCM2836/BCM2837 based boards + items: + - enum: + - brcm,bcm2836-vchiq + - const: brcm,bcm2835-vchiq + + reg: + description: Physical base address and length of the doorbell register pair + minItems: 1 + + interrupts: + description: Interrupt number of the doorbell interrupt + minItems: 1 + +required: + - compatible + - reg + - interrupts + +additionalProperties: false + +examples: + - | + mailbox@7e00b840 { + compatible = "brcm,bcm2835-vchiq"; + reg = <0x7e00b840 0xf>; + interrupts = <0 2>; + }; + +... diff --git a/Documentation/devicetree/bindings/soc/imx/fsl,imx8mn-disp-blk-ctrl.yaml b/Documentation/devicetree/bindings/soc/imx/fsl,imx8mn-disp-blk-ctrl.yaml new file mode 100644 index 000000000000..fbeaac399c50 --- /dev/null +++ b/Documentation/devicetree/bindings/soc/imx/fsl,imx8mn-disp-blk-ctrl.yaml @@ -0,0 +1,97 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/soc/imx/fsl,imx8mn-disp-blk-ctrl.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: NXP i.MX8MN DISP blk-ctrl + +maintainers: + - Lucas Stach <l.stach@pengutronix.de> + +description: + The i.MX8MN DISP blk-ctrl is a top-level peripheral providing access to + the NoC and ensuring proper power sequencing of the display and MIPI CSI + peripherals located in the DISP domain of the SoC. + +properties: + compatible: + items: + - const: fsl,imx8mn-disp-blk-ctrl + - const: syscon + + reg: + maxItems: 1 + + '#power-domain-cells': + const: 1 + + power-domains: + minItems: 5 + maxItems: 5 + + power-domain-names: + items: + - const: bus + - const: isi + - const: lcdif + - const: mipi-dsi + - const: mipi-csi + + clocks: + minItems: 11 + maxItems: 11 + + clock-names: + items: + - const: disp_axi + - const: disp_apb + - const: disp_axi_root + - const: disp_apb_root + - const: lcdif-axi + - const: lcdif-apb + - const: lcdif-pix + - const: dsi-pclk + - const: dsi-ref + - const: csi-aclk + - const: csi-pclk + +required: + - compatible + - reg + - power-domains + - power-domain-names + - clocks + - clock-names + +additionalProperties: false + +examples: + - | + #include <dt-bindings/clock/imx8mn-clock.h> + #include <dt-bindings/power/imx8mn-power.h> + + disp_blk_ctl: blk_ctrl@32e28000 { + compatible = "fsl,imx8mn-disp-blk-ctrl", "syscon"; + reg = <0x32e28000 0x100>; + power-domains = <&pgc_dispmix>, <&pgc_dispmix>, + <&pgc_dispmix>, <&pgc_mipi>, + <&pgc_mipi>; + power-domain-names = "bus", "isi", "lcdif", "mipi-dsi", + "mipi-csi"; + clocks = <&clk IMX8MN_CLK_DISP_AXI>, + <&clk IMX8MN_CLK_DISP_APB>, + <&clk IMX8MN_CLK_DISP_AXI_ROOT>, + <&clk IMX8MN_CLK_DISP_APB_ROOT>, + <&clk IMX8MN_CLK_DISP_AXI_ROOT>, + <&clk IMX8MN_CLK_DISP_APB_ROOT>, + <&clk IMX8MN_CLK_DISP_PIXEL_ROOT>, + <&clk IMX8MN_CLK_DSI_CORE>, + <&clk IMX8MN_CLK_DSI_PHY_REF>, + <&clk IMX8MN_CLK_CSI1_PHY_REF>, + <&clk IMX8MN_CLK_CAMERA_PIXEL_ROOT>; + clock-names = "disp_axi", "disp_apb", "disp_axi_root", "disp_apb_root", + "lcdif-axi", "lcdif-apb", "lcdif-pix", "dsi-pclk", + "dsi-ref", "csi-aclk", "csi-pclk"; + #power-domain-cells = <1>; + }; diff --git a/Documentation/devicetree/bindings/soc/qcom/qcom-stats.yaml b/Documentation/devicetree/bindings/soc/qcom/qcom-stats.yaml index 99dff7d73b7e..473adca4e973 100644 --- a/Documentation/devicetree/bindings/soc/qcom/qcom-stats.yaml +++ b/Documentation/devicetree/bindings/soc/qcom/qcom-stats.yaml @@ -21,6 +21,11 @@ properties: enum: - qcom,rpmh-stats - qcom,rpm-stats + # For older RPM firmware versions with fixed offset for the sleep stats + - qcom,apq8084-rpm-stats + - qcom,msm8226-rpm-stats + - qcom,msm8916-rpm-stats + - qcom,msm8974-rpm-stats reg: maxItems: 1 diff --git a/Documentation/devicetree/bindings/arm/samsung/exynos-chipid.yaml b/Documentation/devicetree/bindings/soc/samsung/exynos-chipid.yaml index bfc352a2fdd6..4bb8efb83ac1 100644 --- a/Documentation/devicetree/bindings/arm/samsung/exynos-chipid.yaml +++ b/Documentation/devicetree/bindings/soc/samsung/exynos-chipid.yaml @@ -1,7 +1,7 @@ # SPDX-License-Identifier: GPL-2.0 %YAML 1.2 --- -$id: http://devicetree.org/schemas/arm/samsung/exynos-chipid.yaml# +$id: http://devicetree.org/schemas/soc/samsung/exynos-chipid.yaml# $schema: http://devicetree.org/meta-schemas/core.yaml# title: Samsung Exynos SoC series Chipid driver diff --git a/Documentation/devicetree/bindings/arm/samsung/pmu.yaml b/Documentation/devicetree/bindings/soc/samsung/exynos-pmu.yaml index 17678d9686c1..c30a6437030d 100644 --- a/Documentation/devicetree/bindings/arm/samsung/pmu.yaml +++ b/Documentation/devicetree/bindings/soc/samsung/exynos-pmu.yaml @@ -1,7 +1,7 @@ # SPDX-License-Identifier: GPL-2.0 %YAML 1.2 --- -$id: http://devicetree.org/schemas/arm/samsung/pmu.yaml# +$id: http://devicetree.org/schemas/soc/samsung/exynos-pmu.yaml# $schema: http://devicetree.org/meta-schemas/core.yaml# title: Samsung Exynos SoC series Power Management Unit (PMU) @@ -24,6 +24,7 @@ select: - samsung,exynos5420-pmu - samsung,exynos5433-pmu - samsung,exynos7-pmu + - samsung,exynos850-pmu - samsung-s5pv210-pmu required: - compatible @@ -41,6 +42,7 @@ properties: - samsung,exynos5420-pmu - samsung,exynos5433-pmu - samsung,exynos7-pmu + - samsung,exynos850-pmu - samsung-s5pv210-pmu - const: syscon diff --git a/Documentation/devicetree/bindings/soc/samsung/exynos-usi.yaml b/Documentation/devicetree/bindings/soc/samsung/exynos-usi.yaml new file mode 100644 index 000000000000..273f2d95a043 --- /dev/null +++ b/Documentation/devicetree/bindings/soc/samsung/exynos-usi.yaml @@ -0,0 +1,159 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/soc/samsung/exynos-usi.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Samsung's Exynos USI (Universal Serial Interface) binding + +maintainers: + - Sam Protsenko <semen.protsenko@linaro.org> + - Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com> + +description: | + USI IP-core provides selectable serial protocol (UART, SPI or High-Speed I2C). + USI shares almost all internal circuits within each protocol, so only one + protocol can be chosen at a time. USI is modeled as a node with zero or more + child nodes, each representing a serial sub-node device. The mode setting + selects which particular function will be used. + + Refer to next bindings documentation for information on protocol subnodes that + can exist under USI node: + + [1] Documentation/devicetree/bindings/serial/samsung_uart.yaml + [2] Documentation/devicetree/bindings/i2c/i2c-exynos5.txt + [3] Documentation/devicetree/bindings/spi/spi-samsung.txt + +properties: + $nodename: + pattern: "^usi@[0-9a-f]+$" + + compatible: + enum: + - samsung,exynos850-usi # for USIv2 (Exynos850, ExynosAutoV9) + + reg: true + + clocks: true + + clock-names: true + + ranges: true + + "#address-cells": + const: 1 + + "#size-cells": + const: 1 + + samsung,sysreg: + $ref: /schemas/types.yaml#/definitions/phandle-array + description: + Should be phandle/offset pair. The phandle to System Register syscon node + (for the same domain where this USI controller resides) and the offset + of SW_CONF register for this USI controller. + + samsung,mode: + $ref: /schemas/types.yaml#/definitions/uint32 + description: + Selects USI function (which serial protocol to use). Refer to + <include/dt-bindings/soc/samsung,exynos-usi.h> for valid USI mode values. + + samsung,clkreq-on: + type: boolean + description: + Enable this property if underlying protocol requires the clock to be + continuously provided without automatic gating. As suggested by SoC + manual, it should be set in case of SPI/I2C slave, UART Rx and I2C + multi-master mode. Usually this property is needed if USI mode is set + to "UART". + + This property is optional. + +patternProperties: + # All other properties should be child nodes + "^(serial|spi|i2c)@[0-9a-f]+$": + type: object + description: Child node describing underlying USI serial protocol + +required: + - compatible + - ranges + - "#address-cells" + - "#size-cells" + - samsung,sysreg + - samsung,mode + +if: + properties: + compatible: + contains: + enum: + - samsung,exynos850-usi + +then: + properties: + reg: + maxItems: 1 + + clocks: + items: + - description: Bus (APB) clock + - description: Operating clock for UART/SPI/I2C protocol + + clock-names: + items: + - const: pclk + - const: ipclk + + required: + - reg + - clocks + - clock-names + +else: + properties: + reg: false + clocks: false + clock-names: false + samsung,clkreq-on: false + +additionalProperties: false + +examples: + - | + #include <dt-bindings/interrupt-controller/arm-gic.h> + #include <dt-bindings/soc/samsung,exynos-usi.h> + + usi0: usi@138200c0 { + compatible = "samsung,exynos850-usi"; + reg = <0x138200c0 0x20>; + samsung,sysreg = <&sysreg_peri 0x1010>; + samsung,mode = <USI_V2_UART>; + samsung,clkreq-on; /* needed for UART mode */ + #address-cells = <1>; + #size-cells = <1>; + ranges; + clocks = <&cmu_peri 32>, <&cmu_peri 31>; + clock-names = "pclk", "ipclk"; + + serial_0: serial@13820000 { + compatible = "samsung,exynos850-uart"; + reg = <0x13820000 0xc0>; + interrupts = <GIC_SPI 227 IRQ_TYPE_LEVEL_HIGH>; + clocks = <&cmu_peri 32>, <&cmu_peri 31>; + clock-names = "uart", "clk_uart_baud0"; + status = "disabled"; + }; + + hsi2c_0: i2c@13820000 { + compatible = "samsung,exynosautov9-hsi2c"; + reg = <0x13820000 0xc0>; + interrupts = <GIC_SPI 227 IRQ_TYPE_LEVEL_HIGH>; + #address-cells = <1>; + #size-cells = <0>; + clocks = <&cmu_peri 31>, <&cmu_peri 32>; + clock-names = "hsi2c", "hsi2c_pclk"; + status = "disabled"; + }; + }; diff --git a/Documentation/devicetree/bindings/sound/ak4375.yaml b/Documentation/devicetree/bindings/sound/ak4375.yaml new file mode 100644 index 000000000000..f1d5074a024d --- /dev/null +++ b/Documentation/devicetree/bindings/sound/ak4375.yaml @@ -0,0 +1,57 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/sound/ak4375.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: AK4375 DAC and headphones amplifier Device Tree Bindings + +maintainers: + - Vincent Knecht <vincent.knecht@mailoo.org> + +properties: + compatible: + const: asahi-kasei,ak4375 + + reg: + maxItems: 1 + + '#sound-dai-cells': + const: 0 + + avdd-supply: + description: regulator phandle for the AVDD power supply. + + tvdd-supply: + description: regulator phandle for the TVDD power supply. + + pdn-gpios: + description: optional GPIO to set the PDN pin. + +required: + - compatible + - reg + - '#sound-dai-cells' + - avdd-supply + - tvdd-supply + +additionalProperties: false + +examples: + - | + #include <dt-bindings/gpio/gpio.h> + i2c { + #address-cells = <1>; + #size-cells = <0>; + + headphones: audio-codec@10 { + compatible = "asahi-kasei,ak4375"; + reg = <0x10>; + avdd-supply = <®_headphones_avdd>; + tvdd-supply = <&pm8916_l6>; + pdn-gpios = <&msmgpio 114 GPIO_ACTIVE_HIGH>; + pinctrl-names = "default"; + pinctrl-0 = <&headphones_pdn_default>; + #sound-dai-cells = <0>; + }; + }; diff --git a/Documentation/devicetree/bindings/sound/amlogic,aiu.yaml b/Documentation/devicetree/bindings/sound/amlogic,aiu.yaml index f50558ed914f..0705f91199a0 100644 --- a/Documentation/devicetree/bindings/sound/amlogic,aiu.yaml +++ b/Documentation/devicetree/bindings/sound/amlogic,aiu.yaml @@ -9,6 +9,9 @@ title: Amlogic AIU audio output controller maintainers: - Jerome Brunet <jbrunet@baylibre.com> +allOf: + - $ref: name-prefix.yaml# + properties: $nodename: pattern: "^audio-controller@.*" @@ -65,6 +68,8 @@ properties: resets: maxItems: 1 + sound-name-prefix: true + required: - "#sound-dai-cells" - compatible diff --git a/Documentation/devicetree/bindings/sound/amlogic,g12a-toacodec.yaml b/Documentation/devicetree/bindings/sound/amlogic,g12a-toacodec.yaml index 3c3891d17238..77469a45bb7a 100644 --- a/Documentation/devicetree/bindings/sound/amlogic,g12a-toacodec.yaml +++ b/Documentation/devicetree/bindings/sound/amlogic,g12a-toacodec.yaml @@ -9,6 +9,9 @@ title: Amlogic G12a Internal DAC Control Glue maintainers: - Jerome Brunet <jbrunet@baylibre.com> +allOf: + - $ref: name-prefix.yaml# + properties: $nodename: pattern: "^audio-controller@.*" @@ -31,6 +34,8 @@ properties: resets: maxItems: 1 + sound-name-prefix: true + required: - "#sound-dai-cells" - compatible diff --git a/Documentation/devicetree/bindings/sound/amlogic,t9015.yaml b/Documentation/devicetree/bindings/sound/amlogic,t9015.yaml index db7b04da0b39..580a3d040abc 100644 --- a/Documentation/devicetree/bindings/sound/amlogic,t9015.yaml +++ b/Documentation/devicetree/bindings/sound/amlogic,t9015.yaml @@ -9,6 +9,9 @@ title: Amlogic T9015 Internal Audio DAC maintainers: - Jerome Brunet <jbrunet@baylibre.com> +allOf: + - $ref: name-prefix.yaml# + properties: $nodename: pattern: "^audio-controller@.*" @@ -38,6 +41,8 @@ properties: description: Analogue power supply. + sound-name-prefix: true + required: - "#sound-dai-cells" - compatible diff --git a/Documentation/devicetree/bindings/sound/audio-graph-port.yaml b/Documentation/devicetree/bindings/sound/audio-graph-port.yaml index 43e7f86e3b23..476dcb49ece6 100644 --- a/Documentation/devicetree/bindings/sound/audio-graph-port.yaml +++ b/Documentation/devicetree/bindings/sound/audio-graph-port.yaml @@ -42,10 +42,15 @@ patternProperties: $ref: /schemas/types.yaml#/definitions/flag frame-master: description: Indicates dai-link frame master. - $ref: /schemas/types.yaml#/definitions/phandle + oneOf: + - $ref: /schemas/types.yaml#/definitions/flag + - $ref: /schemas/types.yaml#/definitions/phandle bitclock-master: description: Indicates dai-link bit clock master - $ref: /schemas/types.yaml#/definitions/phandle + oneOf: + - $ref: /schemas/types.yaml#/definitions/flag + - $ref: /schemas/types.yaml#/definitions/phandle + dai-format: description: audio format. items: diff --git a/Documentation/devicetree/bindings/sound/cirrus,cs42l42.yaml b/Documentation/devicetree/bindings/sound/cirrus,cs42l42.yaml new file mode 100644 index 000000000000..31800f70e9d9 --- /dev/null +++ b/Documentation/devicetree/bindings/sound/cirrus,cs42l42.yaml @@ -0,0 +1,225 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/sound/cirrus,cs42l42.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Cirrus Logic CS42L42 audio CODEC + +maintainers: + - patches@opensource.cirrus.com + +description: + The CS42L42 is a low-power audio codec designed for portable applications. + It provides a high-dynamic range, stereo DAC for audio playback and a mono + high-dynamic-range ADC for audio capture. There is an integrated headset + detection block. + +properties: + compatible: + enum: + - cirrus,cs42l42 + + reg: + description: + The I2C address of the CS42L42. + maxItems: 1 + + VP-supply: + description: + VP power supply. + + VCP-supply: + description: + Charge pump power supply. + + VD_FILT-supply: + description: + FILT+ power supply. + + VL-supply: + description: + Logic power supply. + + VA-supply: + description: + Analog power supply. + + reset-gpios: + description: + This pin will be asserted and then deasserted to reset the + CS42L42 before communication starts. + maxItems: 1 + + interrupts: + description: + Interrupt for CS42L42 IRQ line. + maxItems: 1 + + cirrus,ts-inv: + description: | + Sets the behaviour of the jack plug detect switch. + + 0 - (Default) Shorted to tip when unplugged, open when plugged. + This is "inverted tip sense (ITS)" in the datasheet. + + 1 - Open when unplugged, shorted to tip when plugged. + This is "normal tip sense (TS)" in the datasheet. + + The CS42L42_TS_INV_* defines are available for this. + $ref: "/schemas/types.yaml#/definitions/uint32" + minimum: 0 + maximum: 1 + + cirrus,ts-dbnc-rise: + description: | + Debounce the rising edge of TIP_SENSE_PLUG. With no + debounce, the tip sense pin might be noisy on a plug event. + + 0 - 0ms + 1 - 125ms + 2 - 250ms + 3 - 500ms + 4 - 750ms + 5 - 1s (Default) + 6 - 1.25s + 7 - 1.5s + + The CS42L42_TS_DBNCE_* defines are available for this. + $ref: "/schemas/types.yaml#/definitions/uint32" + minimum: 0 + maximum: 7 + + cirrus,ts-dbnc-fall: + description: | + Debounce the falling edge of TIP_SENSE_UNPLUG. With no + debounce, the tip sense pin might be noisy on an unplug event. + + 0 - 0ms + 1 - 125ms + 2 - 250ms + 3 - 500ms + 4 - 750ms + 5 - 1s (Default) + 6 - 1.25s + 7 - 1.5s + + The CS42L42_TS_DBNCE_* defines are available for this. + $ref: "/schemas/types.yaml#/definitions/uint32" + minimum: 0 + maximum: 7 + + cirrus,btn-det-init-dbnce: + description: | + This sets how long to wait after enabling button detection + interrupts before servicing button interrupts, to allow the + HS bias time to settle. Value is in milliseconds. + There may be erroneous button interrupts if this debounce time + is too short. + + 0ms - 200ms, + Default = 100ms + $ref: "/schemas/types.yaml#/definitions/uint32" + minimum: 0 + maximum: 200 + + cirrus,btn-det-event-dbnce: + description: | + This sets how long to wait after receiving a button press + interrupt before processing it. Allows time for the button + press to make a clean connection with the bias resistors. + Value is in milliseconds. + + 0ms - 20ms, + Default = 10ms + $ref: "/schemas/types.yaml#/definitions/uint32" + minimum: 0 + maximum: 20 + + cirrus,bias-lvls: + description: | + For a level-detect headset button scheme, each button will bias + the mic pin to a certain voltage. To determine which button was + pressed, the voltage is compared to sequential, decreasing + voltages, until the compared voltage < bias voltage. + For different hardware setups, a designer might want to tweak this. + This is an array of descending values for the comparator voltage, + given as percent of the HSBIAS voltage. + + Array of 4 values, each 0-63 + < x1 x2 x3 x4 > + Default = < 15 8 4 1 > + $ref: /schemas/types.yaml#/definitions/uint32-array + minItems: 4 + maxItems: 4 + items: + minimum: 0 + maximum: 63 + + cirrus,hs-bias-ramp-rate: + description: | + If present this sets the rate that the HS bias should rise and fall. + The actual rise and fall times depend on external hardware (the + datasheet gives several rise and fall time examples). + + 0 - Fast rise time; slow, load-dependent fall time + 1 - Fast + 2 - Slow (default) + 3 - Slowest + + The CS42L42_HSBIAS_RAMP_* defines are available for this. + $ref: "/schemas/types.yaml#/definitions/uint32" + minimum: 0 + maximum: 3 + + cirrus,hs-bias-sense-disable: + description: | + If present the HSBIAS sense is disabled. Configures HSBIAS output + current sense through the external 2.21-k resistor. HSBIAS_SENSE + is a hardware feature to reduce the potential pop noise when the + headset plug is removed slowly. But on some platforms ESD voltage + will affect it causing plug detection to fail, especially with CTIA + headset type. For different hardware setups, a designer might want + to tweak default behavior. + type: boolean + +required: + - compatible + - reg + - VP-supply + - VCP-supply + - VD_FILT-supply + - VL-supply + - VA-supply + +additionalProperties: false + +examples: + - | + #include <dt-bindings/sound/cs42l42.h> + i2c { + #address-cells = <1>; + #size-cells = <0>; + + cs42l42: cs42l42@48 { + compatible = "cirrus,cs42l42"; + reg = <0x48>; + VA-supply = <&dummy_vreg>; + VP-supply = <&dummy_vreg>; + VCP-supply = <&dummy_vreg>; + VD_FILT-supply = <&dummy_vreg>; + VL-supply = <&dummy_vreg>; + + reset-gpios = <&axi_gpio_0 1 0>; + interrupt-parent = <&gpio0>; + interrupts = <55 8>; + + cirrus,ts-inv = <CS42L42_TS_INV_DIS>; + cirrus,ts-dbnc-rise = <CS42L42_TS_DBNCE_1000>; + cirrus,ts-dbnc-fall = <CS42L42_TS_DBNCE_0>; + cirrus,btn-det-init-dbnce = <100>; + cirrus,btn-det-event-dbnce = <10>; + cirrus,bias-lvls = <0x0F 0x08 0x04 0x01>; + cirrus,hs-bias-ramp-rate = <CS42L42_HSBIAS_RAMP_SLOW>; + }; + }; diff --git a/Documentation/devicetree/bindings/sound/cs42l42.txt b/Documentation/devicetree/bindings/sound/cs42l42.txt deleted file mode 100644 index 3b7705623980..000000000000 --- a/Documentation/devicetree/bindings/sound/cs42l42.txt +++ /dev/null @@ -1,115 +0,0 @@ -CS42L42 audio CODEC - -Required properties: - - - compatible : "cirrus,cs42l42" - - - reg : the I2C address of the device for I2C. - - - VP-supply, VCP-supply, VD_FILT-supply, VL-supply, VA-supply : - power supplies for the device, as covered in - Documentation/devicetree/bindings/regulator/regulator.txt. - -Optional properties: - - - reset-gpios : a GPIO spec for the reset pin. If specified, it will be - deasserted before communication to the codec starts. - - - interrupts : IRQ line info CS42L42. - (See Documentation/devicetree/bindings/interrupt-controller/interrupts.txt - for further information relating to interrupt properties) - - - cirrus,ts-inv : Boolean property. Sets the behaviour of the jack plug - detect switch. - - 0 = (Default) Shorted to tip when unplugged, open when plugged. - This is "inverted tip sense (ITS)" in the datasheet. - - 1 = Open when unplugged, shorted to tip when plugged. - This is "normal tip sense (TS)" in the datasheet. - - - cirrus,ts-dbnc-rise : Debounce the rising edge of TIP_SENSE_PLUG. With no - debounce, the tip sense pin might be noisy on a plug event. - - 0 - 0ms, - 1 - 125ms, - 2 - 250ms, - 3 - 500ms, - 4 - 750ms, - 5 - (Default) 1s, - 6 - 1.25s, - 7 - 1.5s, - - - cirrus,ts-dbnc-fall : Debounce the falling edge of TIP_SENSE_UNPLUG. - With no debounce, the tip sense pin might be noisy on an unplug event. - - 0 - 0ms, - 1 - 125ms, - 2 - 250ms, - 3 - 500ms, - 4 - 750ms, - 5 - (Default) 1s, - 6 - 1.25s, - 7 - 1.5s, - - - cirrus,btn-det-init-dbnce : This sets how long the driver sleeps after - enabling button detection interrupts. After auto-detection and before - servicing button interrupts, the HS bias needs time to settle. If you - don't wait, there is possibility for erroneous button interrupt. - - 0ms - 200ms, - Default = 100ms - - - cirrus,btn-det-event-dbnce : This sets how long the driver delays after - receiving a button press interrupt. With level detect interrupts, you want - to wait a small amount of time to make sure the button press is making a - clean connection with the bias resistors. - - 0ms - 20ms, - Default = 10ms - - - cirrus,bias-lvls : For a level-detect headset button scheme, each button - will bias the mic pin to a certain voltage. To determine which button was - pressed, the driver will compare this biased voltage to sequential, - decreasing voltages and will stop when a comparator is tripped, - indicating a comparator voltage < bias voltage. This value represents a - percentage of the internally generated HS bias voltage. For different - hardware setups, a designer might want to tweak this. This is an array of - descending values for the comparator voltage. - - Array of 4 values - Each 0-63 - < x1 x2 x3 x4 > - Default = < 15 8 4 1> - - - cirrus,hs-bias-sense-disable: This is boolean property. If present the - HSBIAS sense is disabled. Configures HSBIAS output current sense through - the external 2.21-k resistor. HSBIAS_SENSE is hardware feature to reduce - the potential pop noise during the headset plug out slowly. But on some - platforms ESD voltage will affect it causing test to fail, especially - with CTIA headset type. For different hardware setups, a designer might - want to tweak default behavior. - -Example: - -cs42l42: cs42l42@48 { - compatible = "cirrus,cs42l42"; - reg = <0x48>; - VA-supply = <&dummy_vreg>; - VP-supply = <&dummy_vreg>; - VCP-supply = <&dummy_vreg>; - VD_FILT-supply = <&dummy_vreg>; - VL-supply = <&dummy_vreg>; - - reset-gpios = <&axi_gpio_0 1 0>; - interrupt-parent = <&gpio0>; - interrupts = <55 8> - - cirrus,ts-inv = <0x00>; - cirrus,ts-dbnc-rise = <0x05>; - cirrus,ts-dbnc-fall = <0x00>; - cirrus,btn-det-init-dbnce = <100>; - cirrus,btn-det-event-dbnce = <10>; - cirrus,bias-lvls = <0x0F 0x08 0x04 0x01>; - cirrus,hs-bias-ramp-rate = <0x02>; -}; diff --git a/Documentation/devicetree/bindings/sound/linux,spdif-dit.yaml b/Documentation/devicetree/bindings/sound/linux,spdif-dit.yaml index c6b070e1d014..a4f9257e313d 100644 --- a/Documentation/devicetree/bindings/sound/linux,spdif-dit.yaml +++ b/Documentation/devicetree/bindings/sound/linux,spdif-dit.yaml @@ -9,6 +9,9 @@ title: Dummy SPDIF Transmitter Device Tree Bindings maintainers: - Mark Brown <broonie@kernel.org> +allOf: + - $ref: name-prefix.yaml# + properties: compatible: const: linux,spdif-dit @@ -16,6 +19,8 @@ properties: "#sound-dai-cells": const: 0 + sound-name-prefix: true + required: - "#sound-dai-cells" - compatible diff --git a/Documentation/devicetree/bindings/sound/mt8195-afe-pcm.yaml b/Documentation/devicetree/bindings/sound/mt8195-afe-pcm.yaml index dcf790b053d2..6d0975b33d15 100644 --- a/Documentation/devicetree/bindings/sound/mt8195-afe-pcm.yaml +++ b/Documentation/devicetree/bindings/sound/mt8195-afe-pcm.yaml @@ -19,6 +19,12 @@ properties: interrupts: maxItems: 1 + memory-region: + maxItems: 1 + description: | + Shared memory region for AFE memif. A "shared-dma-pool". + See ../reserved-memory/reserved-memory.txt for details. + mediatek,topckgen: $ref: "/schemas/types.yaml#/definitions/phandle" description: The phandle of the mediatek topckgen controller @@ -125,6 +131,7 @@ required: - power-domains - clocks - clock-names + - memory-region additionalProperties: false @@ -139,6 +146,7 @@ examples: interrupts = <GIC_SPI 822 IRQ_TYPE_LEVEL_HIGH 0>; mediatek,topckgen = <&topckgen>; power-domains = <&spm 7>; //MT8195_POWER_DOMAIN_AUDIO + memory-region = <&snd_dma_mem_reserved>; clocks = <&clk26m>, <&topckgen 163>, //CLK_TOP_APLL1 <&topckgen 166>, //CLK_TOP_APLL2 diff --git a/Documentation/devicetree/bindings/sound/mt8195-mt6359-rt1011-rt5682.yaml b/Documentation/devicetree/bindings/sound/mt8195-mt6359-rt1011-rt5682.yaml index d354c30d3377..cf6ad7933e23 100644 --- a/Documentation/devicetree/bindings/sound/mt8195-mt6359-rt1011-rt5682.yaml +++ b/Documentation/devicetree/bindings/sound/mt8195-mt6359-rt1011-rt5682.yaml @@ -16,6 +16,10 @@ properties: compatible: const: mediatek,mt8195_mt6359_rt1011_rt5682 + model: + $ref: /schemas/types.yaml#/definitions/string + description: User specified audio sound card name + mediatek,platform: $ref: "/schemas/types.yaml#/definitions/phandle" description: The phandle of MT8195 ASoC platform. diff --git a/Documentation/devicetree/bindings/sound/mt8195-mt6359-rt1019-rt5682.yaml b/Documentation/devicetree/bindings/sound/mt8195-mt6359-rt1019-rt5682.yaml index 20bc0ffd0e34..8f177e02ad35 100644 --- a/Documentation/devicetree/bindings/sound/mt8195-mt6359-rt1019-rt5682.yaml +++ b/Documentation/devicetree/bindings/sound/mt8195-mt6359-rt1019-rt5682.yaml @@ -16,6 +16,10 @@ properties: compatible: const: mediatek,mt8195_mt6359_rt1019_rt5682 + model: + $ref: /schemas/types.yaml#/definitions/string + description: User specified audio sound card name + mediatek,platform: $ref: "/schemas/types.yaml#/definitions/phandle" description: The phandle of MT8195 ASoC platform. @@ -28,6 +32,16 @@ properties: $ref: "/schemas/types.yaml#/definitions/phandle" description: The phandle of MT8195 HDMI codec node. + mediatek,adsp: + $ref: "/schemas/types.yaml#/definitions/phandle" + description: The phandle of MT8195 ADSP platform. + + mediatek,dai-link: + $ref: /schemas/types.yaml#/definitions/string-array + description: + A list of the desired dai-links in the sound card. Each entry is a + name defined in the machine driver. + additionalProperties: false required: diff --git a/Documentation/devicetree/bindings/sound/nvidia,tegra-audio-alc5632.txt b/Documentation/devicetree/bindings/sound/nvidia,tegra-audio-alc5632.txt deleted file mode 100644 index 57f40f93453e..000000000000 --- a/Documentation/devicetree/bindings/sound/nvidia,tegra-audio-alc5632.txt +++ /dev/null @@ -1,48 +0,0 @@ -NVIDIA Tegra audio complex - -Required properties: -- compatible : "nvidia,tegra-audio-alc5632" -- clocks : Must contain an entry for each entry in clock-names. - See ../clocks/clock-bindings.txt for details. -- clock-names : Must include the following entries: - - pll_a - - pll_a_out0 - - mclk (The Tegra cdev1/extern1 clock, which feeds the CODEC's mclk) -- nvidia,model : The user-visible name of this sound complex. -- nvidia,audio-routing : A list of the connections between audio components. - Each entry is a pair of strings, the first being the connection's sink, - the second being the connection's source. Valid names for sources and - sinks are the ALC5632's pins as documented in the binding for the device - and: - - * Headset Stereophone - * Int Spk - * Headset Mic - * Digital Mic - -- nvidia,i2s-controller : The phandle of the Tegra I2S controller -- nvidia,audio-codec : The phandle of the ALC5632 audio codec - -Example: - -sound { - compatible = "nvidia,tegra-audio-alc5632-paz00", - "nvidia,tegra-audio-alc5632"; - - nvidia,model = "Compal PAZ00"; - - nvidia,audio-routing = - "Int Spk", "SPK_OUTP", - "Int Spk", "SPK_OUTN", - "Headset Mic","MICBIAS1", - "MIC1_N", "Headset Mic", - "MIC1_P", "Headset Mic", - "Headset Stereophone", "HP_OUT_R", - "Headset Stereophone", "HP_OUT_L"; - - nvidia,i2s-controller = <&tegra_i2s1>; - nvidia,audio-codec = <&alc5632>; - - clocks = <&tegra_car 112>, <&tegra_car 113>, <&tegra_car 93>; - clock-names = "pll_a", "pll_a_out0", "mclk"; -}; diff --git a/Documentation/devicetree/bindings/sound/nvidia,tegra-audio-alc5632.yaml b/Documentation/devicetree/bindings/sound/nvidia,tegra-audio-alc5632.yaml new file mode 100644 index 000000000000..7ef774910e5c --- /dev/null +++ b/Documentation/devicetree/bindings/sound/nvidia,tegra-audio-alc5632.yaml @@ -0,0 +1,74 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/sound/nvidia,tegra-audio-alc5632.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: NVIDIA Tegra audio complex with ALC5632 CODEC + +maintainers: + - Jon Hunter <jonathanh@nvidia.com> + - Thierry Reding <thierry.reding@gmail.com> + +allOf: + - $ref: nvidia,tegra-audio-common.yaml# + +properties: + compatible: + items: + - pattern: '^[a-z0-9]+,tegra-audio-alc5632(-[a-z0-9]+)+$' + - const: nvidia,tegra-audio-alc5632 + + nvidia,audio-routing: + $ref: /schemas/types.yaml#/definitions/non-unique-string-array + description: | + A list of the connections between audio components. + Each entry is a pair of strings, the first being the connection's sink, + the second being the connection's source. Valid names for sources and + sinks are the pins (documented in the binding document), + and the jacks on the board. + minItems: 2 + items: + enum: + # Board Connectors + - "Headset Stereophone" + - "Int Spk" + - "Headset Mic" + - "Digital Mic" + + # CODEC Pins + - SPKOUT + - SPKOUTN + - MICBIAS1 + - MIC1 + - HPR + - HPL + - DMICDAT + +required: + - nvidia,i2s-controller + +unevaluatedProperties: false + +examples: + - | + sound { + compatible = "nvidia,tegra-audio-alc5632-paz00", + "nvidia,tegra-audio-alc5632"; + + nvidia,model = "Compal PAZ00"; + + nvidia,audio-routing = "Int Spk", "SPKOUT", + "Int Spk", "SPKOUTN", + "Headset Mic", "MICBIAS1", + "MIC1", "Headset Mic", + "Headset Stereophone", "HPR", + "Headset Stereophone", "HPL", + "DMICDAT", "Digital Mic"; + + nvidia,i2s-controller = <&i2s>; + nvidia,audio-codec = <&codec>; + + clocks = <&clk 112>, <&clk 113>, <&clk 93>; + clock-names = "pll_a", "pll_a_out0", "mclk"; + }; diff --git a/Documentation/devicetree/bindings/sound/nvidia,tegra-audio-common.yaml b/Documentation/devicetree/bindings/sound/nvidia,tegra-audio-common.yaml new file mode 100644 index 000000000000..82801b4f46dd --- /dev/null +++ b/Documentation/devicetree/bindings/sound/nvidia,tegra-audio-common.yaml @@ -0,0 +1,83 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: "http://devicetree.org/schemas/sound/nvidia,tegra-audio-common.yaml#" +$schema: "http://devicetree.org/meta-schemas/core.yaml#" + +title: Common properties for NVIDIA Tegra audio complexes + +maintainers: + - Jon Hunter <jonathanh@nvidia.com> + - Thierry Reding <thierry.reding@gmail.com> + +properties: + clocks: + items: + - description: PLL A clock + - description: PLL A OUT0 clock + - description: The Tegra cdev1/extern1 clock, which feeds the card's mclk + + clock-names: + items: + - const: pll_a + - const: pll_a_out0 + - const: mclk + + nvidia,model: + $ref: /schemas/types.yaml#/definitions/string + description: The user-visible name of this sound complex. + + nvidia,audio-routing: + $ref: /schemas/types.yaml#/definitions/non-unique-string-array + description: | + A list of the connections between audio components. + Each entry is a pair of strings, the first being the connection's sink, + the second being the connection's source. Valid names for sources and + sinks are the pins (documented in the binding document), + and the jacks on the board. + + nvidia,ac97-controller: + $ref: /schemas/types.yaml#/definitions/phandle + description: The phandle of the AC97 controller + + nvidia,i2s-controller: + $ref: /schemas/types.yaml#/definitions/phandle + description: The phandle of the Tegra I2S controller + + nvidia,audio-codec: + $ref: /schemas/types.yaml#/definitions/phandle + description: The phandle of audio codec + + nvidia,spkr-en-gpios: + maxItems: 1 + description: The GPIO that enables the speakers + + nvidia,hp-mute-gpios: + maxItems: 1 + description: The GPIO that mutes the headphones + + nvidia,hp-det-gpios: + maxItems: 1 + description: The GPIO that detect headphones are plugged in + + nvidia,mic-det-gpios: + maxItems: 1 + description: The GPIO that detect microphone is plugged in + + nvidia,ear-sel-gpios: + maxItems: 1 + description: The GPIO that switch between the microphones + + nvidia,int-mic-en-gpios: + maxItems: 1 + description: The GPIO that enables the internal microphone + + nvidia,ext-mic-en-gpios: + maxItems: 1 + description: The GPIO that enables the external microphone + + nvidia,headset: + type: boolean + description: The Mic Jack represents state of the headset microphone pin + +additionalProperties: true diff --git a/Documentation/devicetree/bindings/sound/nvidia,tegra-audio-graph-card.yaml b/Documentation/devicetree/bindings/sound/nvidia,tegra-audio-graph-card.yaml index 5bdd30a8a404..b4bee466d67a 100644 --- a/Documentation/devicetree/bindings/sound/nvidia,tegra-audio-graph-card.yaml +++ b/Documentation/devicetree/bindings/sound/nvidia,tegra-audio-graph-card.yaml @@ -44,6 +44,16 @@ properties: minItems: 1 maxItems: 3 + interconnects: + items: + - description: APE read memory client + - description: APE write memory client + + interconnect-names: + items: + - const: dma-mem # read + - const: write + iommus: maxItems: 1 diff --git a/Documentation/devicetree/bindings/sound/nvidia,tegra-audio-max98090.txt b/Documentation/devicetree/bindings/sound/nvidia,tegra-audio-max98090.txt deleted file mode 100644 index c3495beba358..000000000000 --- a/Documentation/devicetree/bindings/sound/nvidia,tegra-audio-max98090.txt +++ /dev/null @@ -1,53 +0,0 @@ -NVIDIA Tegra audio complex, with MAX98090 CODEC - -Required properties: -- compatible : "nvidia,tegra-audio-max98090" -- clocks : Must contain an entry for each entry in clock-names. - See ../clocks/clock-bindings.txt for details. -- clock-names : Must include the following entries: - - pll_a - - pll_a_out0 - - mclk (The Tegra cdev1/extern1 clock, which feeds the CODEC's mclk) -- nvidia,model : The user-visible name of this sound complex. -- nvidia,audio-routing : A list of the connections between audio components. - Each entry is a pair of strings, the first being the connection's sink, - the second being the connection's source. Valid names for sources and - sinks are the MAX98090's pins (as documented in its binding), and the jacks - on the board: - - * Headphones - * Speakers - * Mic Jack - * Int Mic - -- nvidia,i2s-controller : The phandle of the Tegra I2S controller that's - connected to the CODEC. -- nvidia,audio-codec : The phandle of the MAX98090 audio codec. - -Optional properties: -- nvidia,hp-det-gpios : The GPIO that detect headphones are plugged in -- nvidia,mic-det-gpios : The GPIO that detect microphones are plugged in - -Example: - -sound { - compatible = "nvidia,tegra-audio-max98090-venice2", - "nvidia,tegra-audio-max98090"; - nvidia,model = "NVIDIA Tegra Venice2"; - - nvidia,audio-routing = - "Headphones", "HPR", - "Headphones", "HPL", - "Speakers", "SPKR", - "Speakers", "SPKL", - "Mic Jack", "MICBIAS", - "IN34", "Mic Jack"; - - nvidia,i2s-controller = <&tegra_i2s1>; - nvidia,audio-codec = <&acodec>; - - clocks = <&tegra_car TEGRA124_CLK_PLL_A>, - <&tegra_car TEGRA124_CLK_PLL_A_OUT0>, - <&tegra_car TEGRA124_CLK_EXTERN1>; - clock-names = "pll_a", "pll_a_out0", "mclk"; -}; diff --git a/Documentation/devicetree/bindings/sound/nvidia,tegra-audio-max98090.yaml b/Documentation/devicetree/bindings/sound/nvidia,tegra-audio-max98090.yaml new file mode 100644 index 000000000000..ccc2ee77ca30 --- /dev/null +++ b/Documentation/devicetree/bindings/sound/nvidia,tegra-audio-max98090.yaml @@ -0,0 +1,97 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/sound/nvidia,tegra-audio-max98090.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: NVIDIA Tegra audio complex with MAX98090 CODEC + +maintainers: + - Jon Hunter <jonathanh@nvidia.com> + - Thierry Reding <thierry.reding@gmail.com> + +allOf: + - $ref: nvidia,tegra-audio-common.yaml# + +properties: + compatible: + oneOf: + - items: + - pattern: '^[a-z0-9]+,tegra-audio-max98090(-[a-z0-9]+)+$' + - const: nvidia,tegra-audio-max98090 + - items: + - enum: + - nvidia,tegra-audio-max98090-nyan-big + - nvidia,tegra-audio-max98090-nyan-blaze + - const: nvidia,tegra-audio-max98090-nyan + - const: nvidia,tegra-audio-max98090 + + nvidia,audio-routing: + $ref: /schemas/types.yaml#/definitions/non-unique-string-array + description: | + A list of the connections between audio components. + Each entry is a pair of strings, the first being the connection's sink, + the second being the connection's source. Valid names for sources and + sinks are the pins (documented in the binding document), + and the jacks on the board. + minItems: 2 + items: + enum: + # Board Connectors + - "Headphones" + - "Speakers" + - "Mic Jack" + - "Int Mic" + + # CODEC Pins + - MIC1 + - MIC2 + - DMICL + - DMICR + - IN1 + - IN2 + - IN3 + - IN4 + - IN5 + - IN6 + - IN12 + - IN34 + - IN56 + - HPL + - HPR + - SPKL + - SPKR + - RCVL + - RCVR + - MICBIAS + +required: + - nvidia,i2s-controller + +unevaluatedProperties: false + +examples: + - | + #include <dt-bindings/clock/tegra124-car.h> + + sound { + compatible = "nvidia,tegra-audio-max98090-venice2", + "nvidia,tegra-audio-max98090"; + nvidia,model = "NVIDIA Tegra Venice2"; + + nvidia,audio-routing = + "Headphones", "HPR", + "Headphones", "HPL", + "Speakers", "SPKR", + "Speakers", "SPKL", + "Mic Jack", "MICBIAS", + "IN34", "Mic Jack"; + + nvidia,i2s-controller = <&tegra_i2s1>; + nvidia,audio-codec = <&acodec>; + + clocks = <&tegra_car TEGRA124_CLK_PLL_A>, + <&tegra_car TEGRA124_CLK_PLL_A_OUT0>, + <&tegra_car TEGRA124_CLK_EXTERN1>; + clock-names = "pll_a", "pll_a_out0", "mclk"; + }; diff --git a/Documentation/devicetree/bindings/sound/nvidia,tegra-audio-rt5640.txt b/Documentation/devicetree/bindings/sound/nvidia,tegra-audio-rt5640.txt deleted file mode 100644 index 7788808dcd0b..000000000000 --- a/Documentation/devicetree/bindings/sound/nvidia,tegra-audio-rt5640.txt +++ /dev/null @@ -1,52 +0,0 @@ -NVIDIA Tegra audio complex, with RT5640 CODEC - -Required properties: -- compatible : "nvidia,tegra-audio-rt5640" -- clocks : Must contain an entry for each entry in clock-names. - See ../clocks/clock-bindings.txt for details. -- clock-names : Must include the following entries: - - pll_a - - pll_a_out0 - - mclk (The Tegra cdev1/extern1 clock, which feeds the CODEC's mclk) -- nvidia,model : The user-visible name of this sound complex. -- nvidia,audio-routing : A list of the connections between audio components. - Each entry is a pair of strings, the first being the connection's sink, - the second being the connection's source. Valid names for sources and - sinks are the RT5640's pins (as documented in its binding), and the jacks - on the board: - - * Headphones - * Speakers - * Mic Jack - -- nvidia,i2s-controller : The phandle of the Tegra I2S controller that's - connected to the CODEC. -- nvidia,audio-codec : The phandle of the RT5640 audio codec. This binding - assumes that AIF1 on the CODEC is connected to Tegra. - -Optional properties: -- nvidia,hp-det-gpios : The GPIO that detects headphones are plugged in - -Example: - -sound { - compatible = "nvidia,tegra-audio-rt5640-dalmore", - "nvidia,tegra-audio-rt5640"; - nvidia,model = "NVIDIA Tegra Dalmore"; - - nvidia,audio-routing = - "Headphones", "HPOR", - "Headphones", "HPOL", - "Speakers", "SPORP", - "Speakers", "SPORN", - "Speakers", "SPOLP", - "Speakers", "SPOLN"; - - nvidia,i2s-controller = <&tegra_i2s1>; - nvidia,audio-codec = <&rt5640>; - - nvidia,hp-det-gpios = <&gpio 143 0>; /* GPIO PR7 */ - - clocks = <&tegra_car 216>, <&tegra_car 217>, <&tegra_car 120>; - clock-names = "pll_a", "pll_a_out0", "mclk"; -}; diff --git a/Documentation/devicetree/bindings/sound/nvidia,tegra-audio-rt5640.yaml b/Documentation/devicetree/bindings/sound/nvidia,tegra-audio-rt5640.yaml new file mode 100644 index 000000000000..e768fb0e9a59 --- /dev/null +++ b/Documentation/devicetree/bindings/sound/nvidia,tegra-audio-rt5640.yaml @@ -0,0 +1,85 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/sound/nvidia,tegra-audio-rt5640.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: NVIDIA Tegra audio complex with RT5639 or RT5640 CODEC + +maintainers: + - Jon Hunter <jonathanh@nvidia.com> + - Thierry Reding <thierry.reding@gmail.com> + +allOf: + - $ref: nvidia,tegra-audio-common.yaml# + +properties: + compatible: + items: + - pattern: '^[a-z0-9]+,tegra-audio-rt56(39|40)(-[a-z0-9]+)+$' + - const: nvidia,tegra-audio-rt5640 + + nvidia,audio-routing: + $ref: /schemas/types.yaml#/definitions/non-unique-string-array + description: | + A list of the connections between audio components. + Each entry is a pair of strings, the first being the connection's sink, + the second being the connection's source. Valid names for sources and + sinks are the pins (documented in the binding document), + and the jacks on the board. + minItems: 2 + items: + enum: + # Board Connectors + - "Headphones" + - "Speakers" + - "Mic Jack" + + # CODEC Pins + - DMIC1 + - DMIC2 + - MICBIAS1 + - IN1P + - IN1R + - IN2P + - IN2R + - HPOL + - HPOR + - LOUTL + - LOUTR + - MONOP + - MONON + - SPOLP + - SPOLN + - SPORP + - SPORN + +required: + - nvidia,i2s-controller + +unevaluatedProperties: false + +examples: + - | + sound { + compatible = "nvidia,tegra-audio-rt5640-dalmore", + "nvidia,tegra-audio-rt5640"; + nvidia,model = "NVIDIA Tegra Dalmore"; + + nvidia,audio-routing = + "Headphones", "HPOR", + "Headphones", "HPOL", + "Speakers", "SPORP", + "Speakers", "SPORN", + "Speakers", "SPOLP", + "Speakers", "SPOLN"; + + nvidia,i2s-controller = <&tegra_i2s1>; + nvidia,audio-codec = <&rt5640>; + + nvidia,hp-det-gpios = <&gpio 143 0>; + + clocks = <&clk 216>, <&clk 217>, <&clk 120>; + clock-names = "pll_a", "pll_a_out0", "mclk"; + }; + diff --git a/Documentation/devicetree/bindings/sound/nvidia,tegra-audio-rt5677.txt b/Documentation/devicetree/bindings/sound/nvidia,tegra-audio-rt5677.txt deleted file mode 100644 index a4589cda214e..000000000000 --- a/Documentation/devicetree/bindings/sound/nvidia,tegra-audio-rt5677.txt +++ /dev/null @@ -1,67 +0,0 @@ -NVIDIA Tegra audio complex, with RT5677 CODEC - -Required properties: -- compatible : "nvidia,tegra-audio-rt5677" -- clocks : Must contain an entry for each entry in clock-names. - See ../clocks/clock-bindings.txt for details. -- clock-names : Must include the following entries: - - pll_a - - pll_a_out0 - - mclk (The Tegra cdev1/extern1 clock, which feeds the CODEC's mclk) -- nvidia,model : The user-visible name of this sound complex. -- nvidia,audio-routing : A list of the connections between audio components. - Each entry is a pair of strings, the first being the connection's sink, - the second being the connection's source. Valid names for sources and - sinks are the RT5677's pins (as documented in its binding), and the jacks - on the board: - - * Headphone - * Speaker - * Headset Mic - * Internal Mic 1 - * Internal Mic 2 - -- nvidia,i2s-controller : The phandle of the Tegra I2S controller that's - connected to the CODEC. -- nvidia,audio-codec : The phandle of the RT5677 audio codec. This binding - assumes that AIF1 on the CODEC is connected to Tegra. - -Optional properties: -- nvidia,hp-det-gpios : The GPIO that detects headphones are plugged in -- nvidia,hp-en-gpios : The GPIO that enables headphone amplifier -- nvidia,mic-present-gpios: The GPIO that mic jack is plugged in -- nvidia,dmic-clk-en-gpios : The GPIO that gates DMIC clock signal - -Example: - -sound { - compatible = "nvidia,tegra-audio-rt5677-ryu", - "nvidia,tegra-audio-rt5677"; - nvidia,model = "NVIDIA Tegra Ryu"; - - nvidia,audio-routing = - "Headphone", "LOUT2", - "Headphone", "LOUT1", - "Headset Mic", "MICBIAS1", - "IN1P", "Headset Mic", - "IN1N", "Headset Mic", - "DMIC L1", "Internal Mic 1", - "DMIC R1", "Internal Mic 1", - "DMIC L2", "Internal Mic 2", - "DMIC R2", "Internal Mic 2", - "Speaker", "PDM1L", - "Speaker", "PDM1R"; - - nvidia,i2s-controller = <&tegra_i2s1>; - nvidia,audio-codec = <&rt5677>; - - nvidia,hp-det-gpios = <&gpio TEGRA_GPIO(R, 7) GPIO_ACTIVE_HIGH>; - nvidia,mic-present-gpios = <&gpio TEGRA_GPIO(O, 5) GPIO_ACTIVE_LOW>; - nvidia,hp-en-gpios = <&rt5677 1 GPIO_ACTIVE_HIGH>; - nvidia,dmic-clk-en-gpios = <&rt5677 2 GPIO_ACTIVE_HIGH>; - - clocks = <&tegra_car TEGRA124_CLK_PLL_A>, - <&tegra_car TEGRA124_CLK_PLL_A_OUT0>, - <&tegra_car TEGRA124_CLK_EXTERN1>; - clock-names = "pll_a", "pll_a_out0", "mclk"; -}; diff --git a/Documentation/devicetree/bindings/sound/nvidia,tegra-audio-rt5677.yaml b/Documentation/devicetree/bindings/sound/nvidia,tegra-audio-rt5677.yaml new file mode 100644 index 000000000000..a49997d6028b --- /dev/null +++ b/Documentation/devicetree/bindings/sound/nvidia,tegra-audio-rt5677.yaml @@ -0,0 +1,100 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/sound/nvidia,tegra-audio-rt5677.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: NVIDIA Tegra audio complex with RT5677 CODEC + +maintainers: + - Jon Hunter <jonathanh@nvidia.com> + - Thierry Reding <thierry.reding@gmail.com> + +allOf: + - $ref: nvidia,tegra-audio-common.yaml# + +properties: + compatible: + items: + - pattern: '^[a-z0-9]+,tegra-audio-rt5677(-[a-z0-9]+)+$' + - const: nvidia,tegra-audio-rt5677 + + nvidia,audio-routing: + $ref: /schemas/types.yaml#/definitions/non-unique-string-array + description: | + A list of the connections between audio components. + Each entry is a pair of strings, the first being the connection's sink, + the second being the connection's source. Valid names for sources and + sinks are the pins (documented in the binding document), + and the jacks on the board. + minItems: 2 + items: + enum: + # Board Connectors + - "Headphone" + - "Speaker" + - "Headset Mic" + - "Internal Mic 1" + - "Internal Mic 2" + + # CODEC Pins + - IN1P + - IN1N + - IN2P + - IN2N + - MICBIAS1 + - DMIC1 + - DMIC2 + - DMIC3 + - DMIC4 + - "DMIC L1" + - "DMIC L2" + - "DMIC L3" + - "DMIC L4" + - "DMIC R1" + - "DMIC R2" + - "DMIC R3" + - "DMIC R4" + - LOUT1 + - LOUT2 + - LOUT3 + - PDM1L + - PDM1R + - PDM2L + - PDM2R + +required: + - nvidia,i2s-controller + +unevaluatedProperties: false + +examples: + - | + sound { + compatible = "nvidia,tegra-audio-rt5677-ryu", + "nvidia,tegra-audio-rt5677"; + nvidia,model = "NVIDIA Tegra Ryu"; + + nvidia,audio-routing = + "Headphone", "LOUT2", + "Headphone", "LOUT1", + "Headset Mic", "MICBIAS1", + "IN1P", "Headset Mic", + "IN1N", "Headset Mic", + "DMIC L1", "Internal Mic 1", + "DMIC R1", "Internal Mic 1", + "DMIC L2", "Internal Mic 2", + "DMIC R2", "Internal Mic 2", + "Speaker", "PDM1L", + "Speaker", "PDM1R"; + + nvidia,i2s-controller = <&tegra_i2s1>; + nvidia,audio-codec = <&rt5677>; + + nvidia,hp-det-gpios = <&gpio 143 0>; + + clocks = <&clk 216>, + <&clk 217>, + <&clk 121>; + clock-names = "pll_a", "pll_a_out0", "mclk"; + }; diff --git a/Documentation/devicetree/bindings/sound/nvidia,tegra-audio-sgtl5000.txt b/Documentation/devicetree/bindings/sound/nvidia,tegra-audio-sgtl5000.txt deleted file mode 100644 index 5da7da4ea07a..000000000000 --- a/Documentation/devicetree/bindings/sound/nvidia,tegra-audio-sgtl5000.txt +++ /dev/null @@ -1,42 +0,0 @@ -NVIDIA Tegra audio complex, with SGTL5000 CODEC - -Required properties: -- compatible : "nvidia,tegra-audio-sgtl5000" -- clocks : Must contain an entry for each entry in clock-names. - See ../clocks/clock-bindings.txt for details. -- clock-names : Must include the following entries: - - pll_a - - pll_a_out0 - - mclk (The Tegra cdev1/extern1 clock, which feeds the CODEC's mclk) -- nvidia,model : The user-visible name of this sound complex. -- nvidia,audio-routing : A list of the connections between audio components. - Each entry is a pair of strings, the first being the connection's sink, - the second being the connection's source. Valid names for sources and - sinks are the SGTL5000's pins (as documented in its binding), and the jacks - on the board: - - * Headphone Jack - * Line In Jack - * Mic Jack - -- nvidia,i2s-controller : The phandle of the Tegra I2S controller that's - connected to the CODEC. -- nvidia,audio-codec : The phandle of the SGTL5000 audio codec. - -Example: - -sound { - compatible = "toradex,tegra-audio-sgtl5000-apalis_t30", - "nvidia,tegra-audio-sgtl5000"; - nvidia,model = "Toradex Apalis T30"; - nvidia,audio-routing = - "Headphone Jack", "HP_OUT", - "LINE_IN", "Line In Jack", - "MIC_IN", "Mic Jack"; - nvidia,i2s-controller = <&tegra_i2s2>; - nvidia,audio-codec = <&sgtl5000>; - clocks = <&tegra_car TEGRA30_CLK_PLL_A>, - <&tegra_car TEGRA30_CLK_PLL_A_OUT0>, - <&tegra_car TEGRA30_CLK_EXTERN1>; - clock-names = "pll_a", "pll_a_out0", "mclk"; -}; diff --git a/Documentation/devicetree/bindings/sound/nvidia,tegra-audio-sgtl5000.yaml b/Documentation/devicetree/bindings/sound/nvidia,tegra-audio-sgtl5000.yaml new file mode 100644 index 000000000000..943e7c01741c --- /dev/null +++ b/Documentation/devicetree/bindings/sound/nvidia,tegra-audio-sgtl5000.yaml @@ -0,0 +1,67 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/sound/nvidia,tegra-audio-sgtl5000.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: NVIDIA Tegra audio complex with SGTL5000 CODEC + +maintainers: + - Jon Hunter <jonathanh@nvidia.com> + - Thierry Reding <thierry.reding@gmail.com> + +allOf: + - $ref: nvidia,tegra-audio-common.yaml# + +properties: + compatible: + items: + - pattern: '^[a-z0-9]+,tegra-audio-sgtl5000([-_][a-z0-9]+)+$' + - const: nvidia,tegra-audio-sgtl5000 + + nvidia,audio-routing: + $ref: /schemas/types.yaml#/definitions/non-unique-string-array + description: | + A list of the connections between audio components. + Each entry is a pair of strings, the first being the connection's sink, + the second being the connection's source. Valid names for sources and + sinks are the pins (documented in the binding document), + and the jacks on the board. + minItems: 2 + items: + enum: + # Board Connectors + - "Headphone Jack" + - "Line In Jack" + - "Mic Jack" + + # CODEC Pins + - HP_OUT + - LINE_OUT + - LINE_IN + - MIC_IN + +required: + - nvidia,i2s-controller + +unevaluatedProperties: false + +examples: + - | + #include <dt-bindings/clock/tegra30-car.h> + + sound { + compatible = "toradex,tegra-audio-sgtl5000-apalis_t30", + "nvidia,tegra-audio-sgtl5000"; + nvidia,model = "Toradex Apalis T30 SGTL5000"; + nvidia,audio-routing = + "Headphone Jack", "HP_OUT", + "LINE_IN", "Line In Jack", + "MIC_IN", "Mic Jack"; + nvidia,i2s-controller = <&tegra_i2s2>; + nvidia,audio-codec = <&codec>; + clocks = <&tegra_car TEGRA30_CLK_PLL_A>, + <&tegra_car TEGRA30_CLK_PLL_A_OUT0>, + <&tegra_car TEGRA30_CLK_EXTERN1>; + clock-names = "pll_a", "pll_a_out0", "mclk"; + }; diff --git a/Documentation/devicetree/bindings/sound/nvidia,tegra-audio-trimslice.txt b/Documentation/devicetree/bindings/sound/nvidia,tegra-audio-trimslice.txt deleted file mode 100644 index ef1fe7358279..000000000000 --- a/Documentation/devicetree/bindings/sound/nvidia,tegra-audio-trimslice.txt +++ /dev/null @@ -1,21 +0,0 @@ -NVIDIA Tegra audio complex for TrimSlice - -Required properties: -- compatible : "nvidia,tegra-audio-trimslice" -- clocks : Must contain an entry for each entry in clock-names. -- clock-names : Must include the following entries: - "pll_a" (The Tegra clock of that name), - "pll_a_out0" (The Tegra clock of that name), - "mclk" (The Tegra cdev1/extern1 clock, which feeds the CODEC's mclk) -- nvidia,i2s-controller : The phandle of the Tegra I2S1 controller -- nvidia,audio-codec : The phandle of the WM8903 audio codec - -Example: - -sound { - compatible = "nvidia,tegra-audio-trimslice"; - nvidia,i2s-controller = <&tegra_i2s1>; - nvidia,audio-codec = <&codec>; - clocks = <&tegra_car 112>, <&tegra_car 113>, <&tegra_car 93>; - clock-names = "pll_a", "pll_a_out0", "mclk"; -}; diff --git a/Documentation/devicetree/bindings/sound/nvidia,tegra-audio-trimslice.yaml b/Documentation/devicetree/bindings/sound/nvidia,tegra-audio-trimslice.yaml new file mode 100644 index 000000000000..8c87cd166238 --- /dev/null +++ b/Documentation/devicetree/bindings/sound/nvidia,tegra-audio-trimslice.yaml @@ -0,0 +1,33 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/sound/nvidia,tegra-audio-trimslice.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: NVIDIA Tegra audio complex with TrimSlice CODEC + +maintainers: + - Jon Hunter <jonathanh@nvidia.com> + - Thierry Reding <thierry.reding@gmail.com> + +allOf: + - $ref: nvidia,tegra-audio-common.yaml# + +properties: + compatible: + const: nvidia,tegra-audio-trimslice + +required: + - nvidia,i2s-controller + +unevaluatedProperties: false + +examples: + - | + sound { + compatible = "nvidia,tegra-audio-trimslice"; + nvidia,i2s-controller = <&tegra_i2s1>; + nvidia,audio-codec = <&codec>; + clocks = <&tegra_car 112>, <&tegra_car 113>, <&tegra_car 93>; + clock-names = "pll_a", "pll_a_out0", "mclk"; + }; diff --git a/Documentation/devicetree/bindings/sound/nvidia,tegra-audio-wm8753.txt b/Documentation/devicetree/bindings/sound/nvidia,tegra-audio-wm8753.txt deleted file mode 100644 index 96f6a57dd6b4..000000000000 --- a/Documentation/devicetree/bindings/sound/nvidia,tegra-audio-wm8753.txt +++ /dev/null @@ -1,40 +0,0 @@ -NVIDIA Tegra audio complex - -Required properties: -- compatible : "nvidia,tegra-audio-wm8753" -- clocks : Must contain an entry for each entry in clock-names. - See ../clocks/clock-bindings.txt for details. -- clock-names : Must include the following entries: - - pll_a - - pll_a_out0 - - mclk (The Tegra cdev1/extern1 clock, which feeds the CODEC's mclk) -- nvidia,model : The user-visible name of this sound complex. -- nvidia,audio-routing : A list of the connections between audio components. - Each entry is a pair of strings, the first being the connection's sink, - the second being the connection's source. Valid names for sources and - sinks are the WM8753's pins as documented in the binding for the WM8753, - and the jacks on the board: - - * Headphone Jack - * Mic Jack - -- nvidia,i2s-controller : The phandle of the Tegra I2S1 controller -- nvidia,audio-codec : The phandle of the WM8753 audio codec -Example: - -sound { - compatible = "nvidia,tegra-audio-wm8753-whistler", - "nvidia,tegra-audio-wm8753" - nvidia,model = "tegra-wm8753-harmony"; - - nvidia,audio-routing = - "Headphone Jack", "LOUT1", - "Headphone Jack", "ROUT1"; - - nvidia,i2s-controller = <&i2s1>; - nvidia,audio-codec = <&wm8753>; - - clocks = <&tegra_car 112>, <&tegra_car 113>, <&tegra_car 93>; - clock-names = "pll_a", "pll_a_out0", "mclk"; -}; - diff --git a/Documentation/devicetree/bindings/sound/nvidia,tegra-audio-wm8753.yaml b/Documentation/devicetree/bindings/sound/nvidia,tegra-audio-wm8753.yaml new file mode 100644 index 000000000000..a5b431d7d0c2 --- /dev/null +++ b/Documentation/devicetree/bindings/sound/nvidia,tegra-audio-wm8753.yaml @@ -0,0 +1,79 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/sound/nvidia,tegra-audio-wm8753.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: NVIDIA Tegra audio complex with WM8753 CODEC + +maintainers: + - Jon Hunter <jonathanh@nvidia.com> + - Thierry Reding <thierry.reding@gmail.com> + +allOf: + - $ref: nvidia,tegra-audio-common.yaml# + +properties: + compatible: + items: + - pattern: '^[a-z0-9]+,tegra-audio-wm8753(-[a-z0-9]+)+$' + - const: nvidia,tegra-audio-wm8753 + + nvidia,audio-routing: + $ref: /schemas/types.yaml#/definitions/non-unique-string-array + description: | + A list of the connections between audio components. + Each entry is a pair of strings, the first being the connection's sink, + the second being the connection's source. Valid names for sources and + sinks are the pins (documented in the binding document), + and the jacks on the board. + minItems: 2 + items: + enum: + # Board Connectors + - "Headphone Jack" + - "Mic Jack" + + # CODEC Pins + - LOUT1 + - LOUT2 + - ROUT1 + - ROUT2 + - MONO1 + - MONO2 + - OUT3 + - OUT4 + - LINE1 + - LINE2 + - RXP + - RXN + - ACIN + - ACOP + - MIC1N + - MIC1 + - MIC2N + - MIC2 + - "Mic Bias" + +required: + - nvidia,i2s-controller + +unevaluatedProperties: false + +examples: + - | + sound { + compatible = "nvidia,tegra-audio-wm8753-whistler", + "nvidia,tegra-audio-wm8753"; + nvidia,model = "tegra-wm8753-harmony"; + + nvidia,audio-routing = + "Headphone Jack", "LOUT1", + "Headphone Jack", "ROUT1"; + + nvidia,i2s-controller = <&i2s1>; + nvidia,audio-codec = <&wm8753>; + + clocks = <&clk 112>, <&clk 113>, <&clk 93>; + clock-names = "pll_a", "pll_a_out0", "mclk"; + }; diff --git a/Documentation/devicetree/bindings/sound/nvidia,tegra-audio-wm8903.txt b/Documentation/devicetree/bindings/sound/nvidia,tegra-audio-wm8903.txt deleted file mode 100644 index bbd581a8c5bc..000000000000 --- a/Documentation/devicetree/bindings/sound/nvidia,tegra-audio-wm8903.txt +++ /dev/null @@ -1,62 +0,0 @@ -NVIDIA Tegra audio complex - -Required properties: -- compatible : "nvidia,tegra-audio-wm8903" -- clocks : Must contain an entry for each entry in clock-names. - See ../clocks/clock-bindings.txt for details. -- clock-names : Must include the following entries: - - pll_a - - pll_a_out0 - - mclk (The Tegra cdev1/extern1 clock, which feeds the CODEC's mclk) -- nvidia,model : The user-visible name of this sound complex. -- nvidia,audio-routing : A list of the connections between audio components. - Each entry is a pair of strings, the first being the connection's sink, - the second being the connection's source. Valid names for sources and - sinks are the WM8903's pins (documented in the WM8903 binding document), - and the jacks on the board: - - * Headphone Jack - * Int Spk - * Mic Jack - * Int Mic - -- nvidia,i2s-controller : The phandle of the Tegra I2S1 controller -- nvidia,audio-codec : The phandle of the WM8903 audio codec - -Optional properties: -- nvidia,spkr-en-gpios : The GPIO that enables the speakers -- nvidia,hp-mute-gpios : The GPIO that mutes the headphones -- nvidia,hp-det-gpios : The GPIO that detect headphones are plugged in -- nvidia,int-mic-en-gpios : The GPIO that enables the internal microphone -- nvidia,ext-mic-en-gpios : The GPIO that enables the external microphone -- nvidia,headset : The Mic Jack represents state of the headset microphone pin - -Example: - -sound { - compatible = "nvidia,tegra-audio-wm8903-harmony", - "nvidia,tegra-audio-wm8903" - nvidia,model = "tegra-wm8903-harmony"; - - nvidia,audio-routing = - "Headphone Jack", "HPOUTR", - "Headphone Jack", "HPOUTL", - "Int Spk", "ROP", - "Int Spk", "RON", - "Int Spk", "LOP", - "Int Spk", "LON", - "Mic Jack", "MICBIAS", - "IN1L", "Mic Jack"; - - nvidia,i2s-controller = <&i2s1>; - nvidia,audio-codec = <&wm8903>; - - nvidia,spkr-en-gpios = <&codec 2 0>; - nvidia,hp-det-gpios = <&gpio 178 0>; /* gpio PW2 */ - nvidia,int-mic-en-gpios = <&gpio 184 0>; /*gpio PX0 */ - nvidia,ext-mic-en-gpios = <&gpio 185 0>; /* gpio PX1 */ - - clocks = <&tegra_car 112>, <&tegra_car 113>, <&tegra_car 93>; - clock-names = "pll_a", "pll_a_out0", "mclk"; -}; - diff --git a/Documentation/devicetree/bindings/sound/nvidia,tegra-audio-wm8903.yaml b/Documentation/devicetree/bindings/sound/nvidia,tegra-audio-wm8903.yaml new file mode 100644 index 000000000000..1b836acab980 --- /dev/null +++ b/Documentation/devicetree/bindings/sound/nvidia,tegra-audio-wm8903.yaml @@ -0,0 +1,93 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/sound/nvidia,tegra-audio-wm8903.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: NVIDIA Tegra audio complex with WM8903 CODEC + +maintainers: + - Jon Hunter <jonathanh@nvidia.com> + - Thierry Reding <thierry.reding@gmail.com> + +allOf: + - $ref: nvidia,tegra-audio-common.yaml# + +properties: + compatible: + oneOf: + - items: + - pattern: '^[a-z0-9]+,tegra-audio-wm8903(-[a-z0-9]+)+$' + - const: nvidia,tegra-audio-wm8903 + - items: + - pattern: ad,tegra-audio-plutux + - const: nvidia,tegra-audio-wm8903 + + nvidia,audio-routing: + $ref: /schemas/types.yaml#/definitions/non-unique-string-array + description: | + A list of the connections between audio components. + Each entry is a pair of strings, the first being the connection's sink, + the second being the connection's source. Valid names for sources and + sinks are the pins (documented in the binding document), + and the jacks on the board. + minItems: 2 + items: + enum: + # Board Connectors + - "Headphone Jack" + - "Int Spk" + - "Mic Jack" + - "Int Mic" + + # CODEC Pins + - IN1L + - IN1R + - IN2L + - IN2R + - IN3L + - IN3R + - DMICDAT + - HPOUTL + - HPOUTR + - LINEOUTL + - LINEOUTR + - LOP + - LON + - ROP + - RON + - MICBIAS + +required: + - nvidia,i2s-controller + +unevaluatedProperties: false + +examples: + - | + sound { + compatible = "nvidia,tegra-audio-wm8903-harmony", + "nvidia,tegra-audio-wm8903"; + nvidia,model = "tegra-wm8903-harmony"; + + nvidia,audio-routing = + "Headphone Jack", "HPOUTR", + "Headphone Jack", "HPOUTL", + "Int Spk", "ROP", + "Int Spk", "RON", + "Int Spk", "LOP", + "Int Spk", "LON", + "Mic Jack", "MICBIAS", + "IN1L", "Mic Jack"; + + nvidia,i2s-controller = <&i2s1>; + nvidia,audio-codec = <&wm8903>; + + nvidia,spkr-en-gpios = <&codec 2 0>; + nvidia,hp-det-gpios = <&gpio 178 0>; + nvidia,int-mic-en-gpios = <&gpio 184 0>; + nvidia,ext-mic-en-gpios = <&gpio 185 0>; + + clocks = <&clk 112>, <&clk 113>, <&clk 93>; + clock-names = "pll_a", "pll_a_out0", "mclk"; + }; diff --git a/Documentation/devicetree/bindings/sound/nvidia,tegra-audio-wm9712.txt b/Documentation/devicetree/bindings/sound/nvidia,tegra-audio-wm9712.txt deleted file mode 100644 index 436f6cd9d07c..000000000000 --- a/Documentation/devicetree/bindings/sound/nvidia,tegra-audio-wm9712.txt +++ /dev/null @@ -1,60 +0,0 @@ -NVIDIA Tegra audio complex - -Required properties: -- compatible : "nvidia,tegra-audio-wm9712" -- clocks : Must contain an entry for each entry in clock-names. - See ../clocks/clock-bindings.txt for details. -- clock-names : Must include the following entries: - - pll_a - - pll_a_out0 - - mclk (The Tegra cdev1/extern1 clock, which feeds the CODEC's mclk) -- nvidia,model : The user-visible name of this sound complex. -- nvidia,audio-routing : A list of the connections between audio components. - Each entry is a pair of strings, the first being the connection's sink, - the second being the connection's source. Valid names for sources and - sinks are the WM9712's pins, and the jacks on the board: - - WM9712 pins: - - * MONOOUT - * HPOUTL - * HPOUTR - * LOUT2 - * ROUT2 - * OUT3 - * LINEINL - * LINEINR - * PHONE - * PCBEEP - * MIC1 - * MIC2 - * Mic Bias - - Board connectors: - - * Headphone - * LineIn - * Mic - -- nvidia,ac97-controller : The phandle of the Tegra AC97 controller - - -Example: - -sound { - compatible = "nvidia,tegra-audio-wm9712-colibri_t20", - "nvidia,tegra-audio-wm9712"; - nvidia,model = "Toradex Colibri T20"; - - nvidia,audio-routing = - "Headphone", "HPOUTL", - "Headphone", "HPOUTR", - "LineIn", "LINEINL", - "LineIn", "LINEINR", - "Mic", "MIC1"; - - nvidia,ac97-controller = <&ac97>; - - clocks = <&tegra_car 112>, <&tegra_car 113>, <&tegra_car 93>; - clock-names = "pll_a", "pll_a_out0", "mclk"; -}; diff --git a/Documentation/devicetree/bindings/sound/nvidia,tegra-audio-wm9712.yaml b/Documentation/devicetree/bindings/sound/nvidia,tegra-audio-wm9712.yaml new file mode 100644 index 000000000000..a1448283344b --- /dev/null +++ b/Documentation/devicetree/bindings/sound/nvidia,tegra-audio-wm9712.yaml @@ -0,0 +1,76 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/sound/nvidia,tegra-audio-wm9712.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: NVIDIA Tegra audio complex with WM9712 CODEC + +maintainers: + - Jon Hunter <jonathanh@nvidia.com> + - Thierry Reding <thierry.reding@gmail.com> + +allOf: + - $ref: nvidia,tegra-audio-common.yaml# + +properties: + compatible: + items: + - pattern: '^[a-z0-9]+,tegra-audio-wm9712([-_][a-z0-9]+)+$' + - const: nvidia,tegra-audio-wm9712 + + nvidia,audio-routing: + $ref: /schemas/types.yaml#/definitions/non-unique-string-array + description: | + A list of the connections between audio components. + Each entry is a pair of strings, the first being the connection's sink, + the second being the connection's source. Valid names for sources and + sinks are the pins (documented in the binding document), + and the jacks on the board. + minItems: 2 + items: + enum: + # Board Connectors + - "Headphone" + - "LineIn" + - "Mic" + + # CODEC Pins + - MONOOUT + - HPOUTL + - HPOUTR + - LOUT2 + - ROUT2 + - OUT3 + - LINEINL + - LINEINR + - PHONE + - PCBEEP + - MIC1 + - MIC2 + - "Mic Bias" + +required: + - nvidia,ac97-controller + +unevaluatedProperties: false + +examples: + - | + sound { + compatible = "nvidia,tegra-audio-wm9712-colibri_t20", + "nvidia,tegra-audio-wm9712"; + nvidia,model = "Toradex Colibri T20"; + + nvidia,audio-routing = + "Headphone", "HPOUTL", + "Headphone", "HPOUTR", + "LineIn", "LINEINL", + "LineIn", "LINEINR", + "Mic", "MIC1"; + + nvidia,ac97-controller = <&ac97>; + + clocks = <&clk 112>, <&clk 113>, <&clk 93>; + clock-names = "pll_a", "pll_a_out0", "mclk"; + }; diff --git a/Documentation/devicetree/bindings/sound/nvidia,tegra20-i2s.txt b/Documentation/devicetree/bindings/sound/nvidia,tegra20-i2s.txt deleted file mode 100644 index dc30c6bfbe95..000000000000 --- a/Documentation/devicetree/bindings/sound/nvidia,tegra20-i2s.txt +++ /dev/null @@ -1,30 +0,0 @@ -NVIDIA Tegra 20 I2S controller - -Required properties: -- compatible : "nvidia,tegra20-i2s" -- reg : Should contain I2S registers location and length -- interrupts : Should contain I2S interrupt -- resets : Must contain an entry for each entry in reset-names. - See ../reset/reset.txt for details. -- reset-names : Must include the following entries: - - i2s -- dmas : Must contain an entry for each entry in clock-names. - See ../dma/dma.txt for details. -- dma-names : Must include the following entries: - - rx - - tx -- clocks : Must contain one entry, for the module clock. - See ../clocks/clock-bindings.txt for details. - -Example: - -i2s@70002800 { - compatible = "nvidia,tegra20-i2s"; - reg = <0x70002800 0x200>; - interrupts = < 45 >; - clocks = <&tegra_car 11>; - resets = <&tegra_car 11>; - reset-names = "i2s"; - dmas = <&apbdma 21>, <&apbdma 21>; - dma-names = "rx", "tx"; -}; diff --git a/Documentation/devicetree/bindings/sound/nvidia,tegra20-i2s.yaml b/Documentation/devicetree/bindings/sound/nvidia,tegra20-i2s.yaml new file mode 100644 index 000000000000..68ae124eaf80 --- /dev/null +++ b/Documentation/devicetree/bindings/sound/nvidia,tegra20-i2s.yaml @@ -0,0 +1,77 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/sound/nvidia,tegra20-i2s.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: NVIDIA Tegra20 I2S Controller + +description: | + The I2S Controller streams synchronous serial audio data between system + memory and an external audio device. The controller supports the I2S Left + Justified Mode, Right Justified Mode, and DSP mode formats. + +maintainers: + - Thierry Reding <treding@nvidia.com> + - Jon Hunter <jonathanh@nvidia.com> + +properties: + compatible: + const: nvidia,tegra20-i2s + + reg: + maxItems: 1 + + resets: + maxItems: 1 + + reset-names: + const: i2s + + interrupts: + maxItems: 1 + + clocks: + minItems: 1 + + dmas: + minItems: 2 + + dma-names: + items: + - const: rx + - const: tx + + nvidia,fixed-parent-rate: + description: | + Specifies whether board prefers parent clock to stay at a fixed rate. + This allows multiple Tegra20 audio components work simultaneously by + limiting number of supportable audio rates. + type: boolean + +required: + - compatible + - reg + - resets + - reset-names + - interrupts + - clocks + - dmas + - dma-names + +additionalProperties: false + +examples: + - | + i2s@70002800 { + compatible = "nvidia,tegra20-i2s"; + reg = <0x70002800 0x200>; + interrupts = <45>; + clocks = <&tegra_car 11>; + resets = <&tegra_car 11>; + reset-names = "i2s"; + dmas = <&apbdma 21>, <&apbdma 21>; + dma-names = "rx", "tx"; + }; + +... diff --git a/Documentation/devicetree/bindings/sound/nvidia,tegra20-spdif.yaml b/Documentation/devicetree/bindings/sound/nvidia,tegra20-spdif.yaml new file mode 100644 index 000000000000..60a368a132b8 --- /dev/null +++ b/Documentation/devicetree/bindings/sound/nvidia,tegra20-spdif.yaml @@ -0,0 +1,85 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/sound/nvidia,tegra20-spdif.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: NVIDIA Tegra20 S/PDIF Controller + +description: | + The S/PDIF controller supports both input and output in serial audio + digital interface format. The input controller can digitally recover + a clock from the received stream. The S/PDIF controller is also used + to generate the embedded audio for HDMI output channel. + +maintainers: + - Thierry Reding <treding@nvidia.com> + - Jon Hunter <jonathanh@nvidia.com> + +properties: + compatible: + const: nvidia,tegra20-spdif + + reg: + maxItems: 1 + + resets: + maxItems: 1 + + interrupts: + maxItems: 1 + + clocks: + minItems: 2 + + clock-names: + items: + - const: out + - const: in + + dmas: + minItems: 2 + + dma-names: + items: + - const: rx + - const: tx + + "#sound-dai-cells": + const: 0 + + nvidia,fixed-parent-rate: + description: | + Specifies whether board prefers parent clock to stay at a fixed rate. + This allows multiple Tegra20 audio components work simultaneously by + limiting number of supportable audio rates. + type: boolean + +required: + - compatible + - reg + - resets + - interrupts + - clocks + - clock-names + - dmas + - dma-names + - "#sound-dai-cells" + +additionalProperties: false + +examples: + - | + spdif@70002400 { + compatible = "nvidia,tegra20-spdif"; + reg = <0x70002400 0x200>; + interrupts = <77>; + clocks = <&clk 99>, <&clk 98>; + clock-names = "out", "in"; + resets = <&rst 10>; + dmas = <&apbdma 3>, <&apbdma 3>; + dma-names = "rx", "tx"; + #sound-dai-cells = <0>; + }; + +... diff --git a/Documentation/devicetree/bindings/sound/nvidia,tegra30-hda.yaml b/Documentation/devicetree/bindings/sound/nvidia,tegra30-hda.yaml index b55775e21de6..2c913aa44fee 100644 --- a/Documentation/devicetree/bindings/sound/nvidia,tegra30-hda.yaml +++ b/Documentation/devicetree/bindings/sound/nvidia,tegra30-hda.yaml @@ -50,9 +50,11 @@ properties: - const: hda2codec_2x resets: + minItems: 2 maxItems: 3 reset-names: + minItems: 2 items: - const: hda - const: hda2hdmi diff --git a/Documentation/devicetree/bindings/sound/nxp,tfa989x.yaml b/Documentation/devicetree/bindings/sound/nxp,tfa989x.yaml index 7667471be1e4..b9b1dba40856 100644 --- a/Documentation/devicetree/bindings/sound/nxp,tfa989x.yaml +++ b/Documentation/devicetree/bindings/sound/nxp,tfa989x.yaml @@ -24,11 +24,23 @@ properties: '#sound-dai-cells': const: 0 + rcv-gpios: + description: optional GPIO to be asserted when receiver mode is enabled. + sound-name-prefix: true vddd-supply: description: regulator phandle for the VDDD power supply. +if: + not: + properties: + compatible: + const: nxp,tfa9897 +then: + properties: + rcv-gpios: false + required: - compatible - reg @@ -55,3 +67,32 @@ examples: #sound-dai-cells = <0>; }; }; + + - | + #include <dt-bindings/gpio/gpio.h> + i2c { + #address-cells = <1>; + #size-cells = <0>; + + speaker_codec_top: audio-codec@34 { + compatible = "nxp,tfa9897"; + reg = <0x34>; + vddd-supply = <&pm8916_l6>; + rcv-gpios = <&msmgpio 50 GPIO_ACTIVE_HIGH>; + pinctrl-names = "default"; + pinctrl-0 = <&speaker_top_default>; + sound-name-prefix = "Speaker Top"; + #sound-dai-cells = <0>; + }; + + speaker_codec_bottom: audio-codec@36 { + compatible = "nxp,tfa9897"; + reg = <0x36>; + vddd-supply = <&pm8916_l6>; + rcv-gpios = <&msmgpio 111 GPIO_ACTIVE_HIGH>; + pinctrl-names = "default"; + pinctrl-0 = <&speaker_bottom_default>; + sound-name-prefix = "Speaker Bottom"; + #sound-dai-cells = <0>; + }; + }; diff --git a/Documentation/devicetree/bindings/sound/qcom,apq8016-sbc.txt b/Documentation/devicetree/bindings/sound/qcom,apq8016-sbc.txt deleted file mode 100644 index 23998262a0a7..000000000000 --- a/Documentation/devicetree/bindings/sound/qcom,apq8016-sbc.txt +++ /dev/null @@ -1,96 +0,0 @@ -* Qualcomm Technologies APQ8016 SBC ASoC machine driver - -This node models the Qualcomm Technologies APQ8016 SBC ASoC machine driver - -Required properties: - -- compatible : "qcom,apq8016-sbc-sndcard" - -- pinctrl-N : One property must exist for each entry in - pinctrl-names. See ../pinctrl/pinctrl-bindings.txt - for details of the property values. -- pinctrl-names : Must contain a "default" entry. -- reg : Must contain an address for each entry in reg-names. -- reg-names : A list which must include the following entries: - * "mic-iomux" - * "spkr-iomux" -- qcom,model : Name of the sound card. - -- qcom,audio-routing : A list of the connections between audio components. - Each entry is a pair of strings, the first being the - connection's sink, the second being the connection's - source. Valid names could be power supplies, MicBias - of msm8x16_wcd codec and the jacks on the board: - - Power supplies: - * MIC BIAS External1 - * MIC BIAS External2 - * MIC BIAS Internal1 - * MIC BIAS Internal2 - - Board connectors: - * Headset Mic - * Secondary Mic - * DMIC - * Ext Spk - -Optional properties: - -- aux-devs : A list of phandles for auxiliary devices (e.g. analog - amplifiers) that do not appear directly within the DAI - links. Should be connected to another audio component - using "qcom,audio-routing". - -Dai-link subnode properties and subnodes: - -Required dai-link subnodes: - -- cpu : CPU sub-node -- codec : CODEC sub-node - -Required CPU/CODEC subnodes properties: - --link-name : Name of the dai link. --sound-dai : phandle/s and port of CPU/CODEC - -Example: - -sound: sound { - compatible = "qcom,apq8016-sbc-sndcard"; - reg = <0x07702000 0x4>, <0x07702004 0x4>; - reg-names = "mic-iomux", "spkr-iomux"; - qcom,model = "DB410c"; - - qcom,audio-routing = - "MIC BIAS External1", "Handset Mic", - "MIC BIAS Internal2", "Headset Mic", - "MIC BIAS External1", "Secondary Mic", - "AMIC1", "MIC BIAS External1", - "AMIC2", "MIC BIAS Internal2", - "AMIC3", "MIC BIAS External1", - "DMIC1", "MIC BIAS Internal1", - "MIC BIAS Internal1", "Digital Mic1", - "DMIC2", "MIC BIAS Internal1", - "MIC BIAS Internal1", "Digital Mic2"; - - /* I2S - Internal codec */ - internal-dai-link@0 { - cpu { /* PRIMARY */ - sound-dai = <&lpass MI2S_PRIMARY>; - }; - codec { - sound-dai = <&lpass_codec 0>, <&wcd_codec 0>; - }; - }; - - /* External Primary or External Secondary -ADV7533 HDMI */ - external-dai-link@0 { - link-name = "ADV7533"; - cpu { /* QUAT */ - sound-dai = <&lpass MI2S_QUATERNARY>; - }; - codec { - sound-dai = <&adv_bridge 0>; - }; - }; -}; diff --git a/Documentation/devicetree/bindings/sound/qcom,sm8250.yaml b/Documentation/devicetree/bindings/sound/qcom,sm8250.yaml index 7d57eb91657a..4bfda04b4608 100644 --- a/Documentation/devicetree/bindings/sound/qcom,sm8250.yaml +++ b/Documentation/devicetree/bindings/sound/qcom,sm8250.yaml @@ -4,18 +4,20 @@ $id: http://devicetree.org/schemas/sound/qcom,sm8250.yaml# $schema: http://devicetree.org/meta-schemas/core.yaml# -title: Qualcomm Technologies Inc. SM8250 ASoC sound card driver +title: Qualcomm Technologies Inc. ASoC sound card drivers maintainers: - Srinivas Kandagatla <srinivas.kandagatla@linaro.org> description: - This bindings describes SC8250 SoC based sound cards + This bindings describes Qualcomm SoC based sound cards which uses LPASS internal codec for audio. properties: compatible: enum: + - qcom,apq8016-sbc-sndcard + - qcom,msm8916-qdsp6-sndcard - qcom,sm8250-sndcard - qcom,qrb5165-rb5-sndcard @@ -27,10 +29,28 @@ properties: being the connection's source. Valid names could be power supplies, MicBias of codec and the jacks on the board. + aux-devs: + $ref: /schemas/types.yaml#/definitions/phandle-array + description: | + List of phandles pointing to auxiliary devices, such + as amplifiers, to be added to the sound card. + model: $ref: /schemas/types.yaml#/definitions/string description: User visible long sound card name + pin-switches: + description: List of widget names for which pin switches should be created. + $ref: /schemas/types.yaml#/definitions/string-array + + widgets: + description: User specified audio sound widgets. + $ref: /schemas/types.yaml#/definitions/non-unique-string-array + + # Only valid for some compatibles (see allOf if below) + reg: true + reg-names: true + patternProperties: ".*-dai-link$": description: @@ -73,6 +93,34 @@ required: - compatible - model +allOf: + - if: + properties: + compatible: + contains: + enum: + - qcom,apq8016-sbc-sndcard + - qcom,msm8916-qdsp6-sndcard + then: + properties: + reg: + items: + - description: Microphone I/O mux register address + - description: Speaker I/O mux register address + reg-names: + items: + - const: mic-iomux + - const: spkr-iomux + required: + - compatible + - model + - reg + - reg-names + else: + properties: + reg: false + reg-names: false + additionalProperties: false examples: @@ -86,10 +134,7 @@ examples: audio-routing = "SpkrLeft IN", "WSA_SPK1 OUT", "SpkrRight IN", "WSA_SPK2 OUT", "VA DMIC0", "vdd-micb", - "VA DMIC1", "vdd-micb", - "MM_DL1", "MultiMedia1 Playback", - "MM_DL2", "MultiMedia2 Playback", - "MultiMedia3 Capture", "MM_UL3"; + "VA DMIC1", "vdd-micb"; mm1-dai-link { link-name = "MultiMedia0"; @@ -157,3 +202,98 @@ examples: }; }; }; + + - | + #include <dt-bindings/sound/qcom,lpass.h> + sound@7702000 { + compatible = "qcom,apq8016-sbc-sndcard"; + reg = <0x07702000 0x4>, <0x07702004 0x4>; + reg-names = "mic-iomux", "spkr-iomux"; + + model = "DB410c"; + audio-routing = + "AMIC2", "MIC BIAS Internal2", + "AMIC3", "MIC BIAS External1"; + + pinctrl-0 = <&cdc_pdm_lines_act &ext_sec_tlmm_lines_act &ext_mclk_tlmm_lines_act>; + pinctrl-1 = <&cdc_pdm_lines_sus &ext_sec_tlmm_lines_sus &ext_mclk_tlmm_lines_sus>; + pinctrl-names = "default", "sleep"; + + quaternary-dai-link { + link-name = "ADV7533"; + cpu { + sound-dai = <&lpass MI2S_QUATERNARY>; + }; + codec { + sound-dai = <&adv_bridge 0>; + }; + }; + + primary-dai-link { + link-name = "WCD"; + cpu { + sound-dai = <&lpass MI2S_PRIMARY>; + }; + codec { + sound-dai = <&lpass_codec 0>, <&wcd_codec 0>; + }; + }; + + tertiary-dai-link { + link-name = "WCD-Capture"; + cpu { + sound-dai = <&lpass MI2S_TERTIARY>; + }; + codec { + sound-dai = <&lpass_codec 1>, <&wcd_codec 1>; + }; + }; + }; + + - | + #include <dt-bindings/sound/qcom,q6afe.h> + #include <dt-bindings/sound/qcom,q6asm.h> + sound@7702000 { + compatible = "qcom,msm8916-qdsp6-sndcard"; + reg = <0x07702000 0x4>, <0x07702004 0x4>; + reg-names = "mic-iomux", "spkr-iomux"; + + model = "msm8916"; + widgets = + "Speaker", "Speaker", + "Headphone", "Headphones"; + pin-switches = "Speaker"; + audio-routing = + "Speaker", "Speaker Amp OUT", + "Speaker Amp IN", "HPH_R", + "Headphones", "HPH_L", + "Headphones", "HPH_R", + "AMIC1", "MIC BIAS Internal1", + "AMIC2", "MIC BIAS Internal2", + "AMIC3", "MIC BIAS Internal3"; + aux-devs = <&speaker_amp>; + + pinctrl-names = "default", "sleep"; + pinctrl-0 = <&cdc_pdm_lines_act>; + pinctrl-1 = <&cdc_pdm_lines_sus>; + + mm1-dai-link { + link-name = "MultiMedia1"; + cpu { + sound-dai = <&q6asmdai MSM_FRONTEND_DAI_MULTIMEDIA1>; + }; + }; + + primary-dai-link { + link-name = "Primary MI2S"; + cpu { + sound-dai = <&q6afedai PRIMARY_MI2S_RX>; + }; + platform { + sound-dai = <&q6routing>; + }; + codec { + sound-dai = <&lpass_codec 0>, <&wcd_codec 0>; + }; + }; + }; diff --git a/Documentation/devicetree/bindings/sound/realtek,rt5682s.yaml b/Documentation/devicetree/bindings/sound/realtek,rt5682s.yaml index 2b8b7b51fe55..d65c0ed5060c 100644 --- a/Documentation/devicetree/bindings/sound/realtek,rt5682s.yaml +++ b/Documentation/devicetree/bindings/sound/realtek,rt5682s.yaml @@ -61,6 +61,10 @@ properties: description: | Set the delay time (ms) for the requirement of the particular DMIC. + realtek,amic-delay-ms: + description: | + Set the delay time (ms) for the requirement of the particular platform or AMIC. + realtek,dmic-clk-driving-high: type: boolean description: | diff --git a/Documentation/devicetree/bindings/sound/samsung-i2s.yaml b/Documentation/devicetree/bindings/sound/samsung-i2s.yaml index 2e3628ef48df..84c4d6cba521 100644 --- a/Documentation/devicetree/bindings/sound/samsung-i2s.yaml +++ b/Documentation/devicetree/bindings/sound/samsung-i2s.yaml @@ -110,12 +110,6 @@ properties: Internal DMA register base address of the audio subsystem (used in secondary sound source). - pinctrl-0: - description: Should specify pin control groups used for this controller. - - pinctrl-names: - const: default - power-domains: maxItems: 1 diff --git a/Documentation/devicetree/bindings/sound/simple-audio-amplifier.yaml b/Documentation/devicetree/bindings/sound/simple-audio-amplifier.yaml index 26379377a7ac..8327846356d3 100644 --- a/Documentation/devicetree/bindings/sound/simple-audio-amplifier.yaml +++ b/Documentation/devicetree/bindings/sound/simple-audio-amplifier.yaml @@ -9,6 +9,9 @@ title: Simple Audio Amplifier Device Tree Bindings maintainers: - Jerome Brunet <jbrunet@baylibre.com> +allOf: + - $ref: name-prefix.yaml# + properties: compatible: enum: @@ -22,10 +25,7 @@ properties: description: > power supply for the device - sound-name-prefix: - $ref: /schemas/types.yaml#/definitions/string - description: > - See ./name-prefix.txt + sound-name-prefix: true required: - compatible diff --git a/Documentation/devicetree/bindings/sound/ti,tlv320adc3xxx.yaml b/Documentation/devicetree/bindings/sound/ti,tlv320adc3xxx.yaml new file mode 100644 index 000000000000..83936f594d1a --- /dev/null +++ b/Documentation/devicetree/bindings/sound/ti,tlv320adc3xxx.yaml @@ -0,0 +1,137 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/sound/ti,tlv320adc3xxx.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Texas Instruments TLV320ADC3001/TLV320ADC3101 Stereo ADC + +maintainers: + - Ricard Wanderlof <ricardw@axis.com> + +description: | + Texas Instruments TLV320ADC3001 and TLV320ADC3101 Stereo ADC + https://www.ti.com/product/TLV320ADC3001 + https://www.ti.com/product/TLV320ADC3101 + +properties: + compatible: + enum: + - ti,tlv320adc3001 + - ti,tlv320adc3101 + + reg: + maxItems: 1 + description: I2C address + + '#sound-dai-cells': + const: 0 + + '#gpio-cells': + const: 2 + + gpio-controller: true + + reset-gpios: + maxItems: 1 + description: GPIO pin used for codec reset (RESET pin) + + clocks: + maxItems: 1 + description: Master clock (MCLK) + + ti,dmdin-gpio1: + $ref: /schemas/types.yaml#/definitions/uint32 + enum: + - 0 # ADC3XXX_GPIO_DISABLED - I/O buffers powered down and not used + - 1 # ADC3XXX_GPIO_INPUT - Various non-GPIO input functions + - 2 # ADC3XXX_GPIO_GPI - General purpose input + - 3 # ADC3XXX_GPIO_GPO - General purpose output + - 4 # ADC3XXX_GPIO_CLKOUT - Clock source set in CLKOUT_MUX reg + - 5 # ADC3XXX_GPIO_INT1 - INT1 output + - 6 # ADC3XXX_GPIO_SECONDARY_BCLK - Codec interface secondary BCLK + - 7 # ADC3XXX_GPIO_SECONDARY_WCLK - Codec interface secondary WCLK + default: 0 + description: | + Configuration for DMDIN/GPIO1 pin. + + When ADC3XXX_GPIO_GPO is configured, this causes corresponding the + ALSA control "GPIOx Output" to appear, as a switch control. + + ti,dmclk-gpio2: + $ref: /schemas/types.yaml#/definitions/uint32 + enum: + - 0 # ADC3XXX_GPIO_DISABLED - I/O buffers powered down and not used + - 1 # ADC3XXX_GPIO_INPUT - Various non-GPIO input functions + - 2 # ADC3XXX_GPIO_GPI - General purpose input + - 3 # ADC3XXX_GPIO_GPO - General purpose output + - 4 # ADC3XXX_GPIO_CLKOUT - Clock source set in CLKOUT_MUX reg + - 5 # ADC3XXX_GPIO_INT1 - INT1 output + - 6 # ADC3XXX_GPIO_SECONDARY_BCLK - Codec interface secondary BCLK + - 7 # ADC3XXX_GPIO_SECONDARY_WCLK - Codec interface secondary WCLK + default: 0 + description: | + Configuration for DMCLK/GPIO2 pin. + + When ADC3XXX_GPIO_GPO is configured, this causes corresponding the + ALSA control "GPIOx Output" to appear, as a switch control. + + Note that there is currently no support for reading the GPIO pins as + inputs. + + ti,micbias1-vg: + $ref: /schemas/types.yaml#/definitions/uint32 + enum: + - 0 # ADC3XXX_MICBIAS_OFF - Mic bias is powered down + - 1 # ADC3XXX_MICBIAS_2_0V - Mic bias is set to 2.0V + - 2 # ADC3XXX_MICBIAS_2_5V - Mic bias is set to 2.5V + - 3 # ADC3XXX_MICBIAS_AVDD - Mic bias is same as AVDD supply + default: 0 + description: | + Mic bias voltage output on MICBIAS1 pin + + ti,micbias2-vg: + $ref: /schemas/types.yaml#/definitions/uint32 + enum: + - 0 # ADC3XXX_MICBIAS_OFF - Mic bias is powered down + - 1 # ADC3XXX_MICBIAS_2_0V - Mic bias is set to 2.0V + - 2 # ADC3XXX_MICBIAS_2_5V - Mic bias is set to 2.5V + - 3 # ADC3XXX_MICBIAS_AVDD - Mic bias is same as AVDD supply + default: 0 + description: | + Mic bias voltage output on MICBIAS2 pin + +required: + - compatible + - reg + - clocks + +additionalProperties: false + +examples: + - | + + #include <dt-bindings/gpio/gpio.h> + #include <dt-bindings/sound/tlv320adc3xxx.h> + + i2c { + #address-cells = <1>; + #size-cells = <0>; + tlv320adc3101: audio-codec@18 { + compatible = "ti,tlv320adc3101"; + reg = <0x18>; + reset-gpios = <&gpio_pc 3 GPIO_ACTIVE_LOW>; + clocks = <&audio_mclk>; + gpio-controller; + #gpio-cells = <2>; + ti,dmdin-gpio1 = <ADC3XXX_GPIO_GPO>; + ti,micbias1-vg = <ADC3XXX_MICBIAS_AVDD>; + }; + }; + + audio_mclk: clock { + compatible = "fixed-clock"; + #clock-cells = <0>; + clock-frequency = <24576000>; + }; +... diff --git a/Documentation/devicetree/bindings/sound/wlf,wm8903.yaml b/Documentation/devicetree/bindings/sound/wlf,wm8903.yaml new file mode 100644 index 000000000000..7105ed5fd6c7 --- /dev/null +++ b/Documentation/devicetree/bindings/sound/wlf,wm8903.yaml @@ -0,0 +1,116 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +%YAML 1.2 +--- +$id: "http://devicetree.org/schemas/sound/wlf,wm8903.yaml#" +$schema: "http://devicetree.org/meta-schemas/core.yaml#" + +title: WM8903 audio codec + +description: | + This device supports I2C only. + Pins on the device (for linking into audio routes): + * IN1L + * IN1R + * IN2L + * IN2R + * IN3L + * IN3R + * DMICDAT + * HPOUTL + * HPOUTR + * LINEOUTL + * LINEOUTR + * LOP + * LON + * ROP + * RON + * MICBIAS + +maintainers: + - patches@opensource.cirrus.com + +properties: + compatible: + const: wlf,wm8903 + + reg: + maxItems: 1 + + gpio-controller: true + '#gpio-cells': + const: 2 + + interrupts: + maxItems: 1 + + micdet-cfg: + $ref: /schemas/types.yaml#/definitions/uint32 + default: 0 + description: Default register value for R6 (Mic Bias). + + micdet-delay: + $ref: /schemas/types.yaml#/definitions/uint32 + default: 100 + description: The debounce delay for microphone detection in mS. + + gpio-cfg: + $ref: /schemas/types.yaml#/definitions/uint32-array + description: | + minItems: 5 + maxItems: 5 + A list of GPIO configuration register values. + If absent, no configuration of these registers is performed. + If any entry has the value 0xffffffff, that GPIO's + configuration will not be modified. + + AVDD-supply: + description: Analog power supply regulator on the AVDD pin. + + CPVDD-supply: + description: Charge pump supply regulator on the CPVDD pin. + + DBVDD-supply: + description: Digital buffer supply regulator for the DBVDD pin. + + DCVDD-supply: + description: Digital core supply regulator for the DCVDD pin. + + +required: + - compatible + - reg + - gpio-controller + - '#gpio-cells' + +additionalProperties: false + +examples: + - | + i2c { + #address-cells = <1>; + #size-cells = <0>; + + wm8903: codec@1a { + compatible = "wlf,wm8903"; + reg = <0x1a>; + interrupts = <347>; + + AVDD-supply = <&fooreg_a>; + CPVDD-supply = <&fooreg_b>; + DBVDD-supply = <&fooreg_c>; + DCVDD-supply = <&fooreg_d>; + + gpio-controller; + #gpio-cells = <2>; + + micdet-cfg = <0>; + micdet-delay = <100>; + gpio-cfg = < + 0x0600 /* DMIC_LR, output */ + 0x0680 /* DMIC_DAT, input */ + 0x0000 /* GPIO, output, low */ + 0x0200 /* Interrupt, output */ + 0x01a0 /* BCLK, input, active high */ + >; + }; + }; diff --git a/Documentation/devicetree/bindings/sound/wlf,wm8962.yaml b/Documentation/devicetree/bindings/sound/wlf,wm8962.yaml index 0e6249d7c133..5e172e9462b9 100644 --- a/Documentation/devicetree/bindings/sound/wlf,wm8962.yaml +++ b/Documentation/devicetree/bindings/sound/wlf,wm8962.yaml @@ -19,6 +19,9 @@ properties: clocks: maxItems: 1 + interrupts: + maxItems: 1 + "#sound-dai-cells": const: 0 diff --git a/Documentation/devicetree/bindings/sound/wm8903.txt b/Documentation/devicetree/bindings/sound/wm8903.txt deleted file mode 100644 index 6371c2434afe..000000000000 --- a/Documentation/devicetree/bindings/sound/wm8903.txt +++ /dev/null @@ -1,82 +0,0 @@ -WM8903 audio CODEC - -This device supports I2C only. - -Required properties: - - - compatible : "wlf,wm8903" - - - reg : the I2C address of the device. - - - gpio-controller : Indicates this device is a GPIO controller. - - - #gpio-cells : Should be two. The first cell is the pin number and the - second cell is used to specify optional parameters (currently unused). - -Optional properties: - - - interrupts : The interrupt line the codec is connected to. - - - micdet-cfg : Default register value for R6 (Mic Bias). If absent, the - default is 0. - - - micdet-delay : The debounce delay for microphone detection in mS. If - absent, the default is 100. - - - gpio-cfg : A list of GPIO configuration register values. The list must - be 5 entries long. If absent, no configuration of these registers is - performed. If any entry has the value 0xffffffff, that GPIO's - configuration will not be modified. - - - AVDD-supply : Analog power supply regulator on the AVDD pin. - - - CPVDD-supply : Charge pump supply regulator on the CPVDD pin. - - - DBVDD-supply : Digital buffer supply regulator for the DBVDD pin. - - - DCVDD-supply : Digital core supply regulator for the DCVDD pin. - -Pins on the device (for linking into audio routes): - - * IN1L - * IN1R - * IN2L - * IN2R - * IN3L - * IN3R - * DMICDAT - * HPOUTL - * HPOUTR - * LINEOUTL - * LINEOUTR - * LOP - * LON - * ROP - * RON - * MICBIAS - -Example: - -wm8903: codec@1a { - compatible = "wlf,wm8903"; - reg = <0x1a>; - interrupts = < 347 >; - - AVDD-supply = <&fooreg_a>; - CPVDD-supply = <&fooreg_b>; - DBVDD-supply = <&fooreg_c>; - DCVDC-supply = <&fooreg_d>; - - gpio-controller; - #gpio-cells = <2>; - - micdet-cfg = <0>; - micdet-delay = <100>; - gpio-cfg = < - 0x0600 /* DMIC_LR, output */ - 0x0680 /* DMIC_DAT, input */ - 0x0000 /* GPIO, output, low */ - 0x0200 /* Interrupt, output */ - 0x01a0 /* BCLK, input, active high */ - >; -}; diff --git a/Documentation/devicetree/bindings/spi/atmel,quadspi.yaml b/Documentation/devicetree/bindings/spi/atmel,quadspi.yaml new file mode 100644 index 000000000000..1d493add4053 --- /dev/null +++ b/Documentation/devicetree/bindings/spi/atmel,quadspi.yaml @@ -0,0 +1,99 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/spi/atmel,quadspi.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Atmel Quad Serial Peripheral Interface (QSPI) + +maintainers: + - Tudor Ambarus <tudor.ambarus@microchip.com> + +allOf: + - $ref: spi-controller.yaml# + +properties: + compatible: + enum: + - atmel,sama5d2-qspi + - microchip,sam9x60-qspi + - microchip,sama7g5-qspi + - microchip,sama7g5-ospi + + reg: + items: + - description: base registers + - description: mapped memory + + reg-names: + items: + - const: qspi_base + - const: qspi_mmap + + clocks: + minItems: 1 + items: + - description: peripheral clock + - description: system clock or generic clock, if available + + clock-names: + minItems: 1 + items: + - const: pclk + - enum: [ qspick, gclk ] + + interrupts: + maxItems: 1 + + dmas: + items: + - description: tx DMA channel + - description: rx DMA channel + + dma-names: + items: + - const: tx + - const: rx + + '#address-cells': + const: 1 + + '#size-cells': + const: 0 + +required: + - compatible + - reg + - reg-names + - interrupts + - clocks + - clock-names + - '#address-cells' + - '#size-cells' + +unevaluatedProperties: false + +examples: + - | + #include <dt-bindings/interrupt-controller/irq.h> + #include <dt-bindings/clock/at91.h> + spi@f0020000 { + compatible = "atmel,sama5d2-qspi"; + reg = <0xf0020000 0x100>, <0xd0000000 0x8000000>; + reg-names = "qspi_base", "qspi_mmap"; + interrupts = <52 IRQ_TYPE_LEVEL_HIGH 7>; + clocks = <&pmc PMC_TYPE_PERIPHERAL 52>; + clock-names = "pclk"; + #address-cells = <1>; + #size-cells = <0>; + pinctrl-names = "default"; + pinctrl-0 = <&pinctrl_spi0_default>; + + flash@0 { + compatible = "jedec,spi-nor"; + spi-max-frequency = <50000000>; + reg = <0>; + spi-rx-bus-width = <4>; + spi-tx-bus-width = <4>; + }; + }; diff --git a/Documentation/devicetree/bindings/spi/atmel-quadspi.txt b/Documentation/devicetree/bindings/spi/atmel-quadspi.txt deleted file mode 100644 index 7c40ea694352..000000000000 --- a/Documentation/devicetree/bindings/spi/atmel-quadspi.txt +++ /dev/null @@ -1,37 +0,0 @@ -* Atmel Quad Serial Peripheral Interface (QSPI) - -Required properties: -- compatible: Should be one of the following: - - "atmel,sama5d2-qspi" - - "microchip,sam9x60-qspi" -- reg: Should contain the locations and lengths of the base registers - and the mapped memory. -- reg-names: Should contain the resource reg names: - - qspi_base: configuration register address space - - qspi_mmap: memory mapped address space -- interrupts: Should contain the interrupt for the device. -- clocks: Should reference the peripheral clock and the QSPI system - clock if available. -- clock-names: Should contain "pclk" for the peripheral clock and "qspick" - for the system clock when available. -- #address-cells: Should be <1>. -- #size-cells: Should be <0>. - -Example: - -spi@f0020000 { - compatible = "atmel,sama5d2-qspi"; - reg = <0xf0020000 0x100>, <0xd0000000 0x8000000>; - reg-names = "qspi_base", "qspi_mmap"; - interrupts = <52 IRQ_TYPE_LEVEL_HIGH 7>; - clocks = <&pmc PMC_TYPE_PERIPHERAL 52>; - clock-names = "pclk"; - #address-cells = <1>; - #size-cells = <0>; - pinctrl-names = "default"; - pinctrl-0 = <&pinctrl_spi0_default>; - - m25p80@0 { - ... - }; -}; diff --git a/Documentation/devicetree/bindings/spi/cdns,qspi-nor-peripheral-props.yaml b/Documentation/devicetree/bindings/spi/cdns,qspi-nor-peripheral-props.yaml new file mode 100644 index 000000000000..553601a441a7 --- /dev/null +++ b/Documentation/devicetree/bindings/spi/cdns,qspi-nor-peripheral-props.yaml @@ -0,0 +1,42 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/spi/cdns,qspi-nor-peripheral-props.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Peripheral-specific properties for the Cadence QSPI controller. + +description: + See spi-peripheral-props.yaml for more info. + +maintainers: + - Pratyush Yadav <p.yadav@ti.com> + +properties: + # cdns,qspi-nor.yaml + cdns,read-delay: + $ref: /schemas/types.yaml#/definitions/uint32 + description: + Delay for read capture logic, in clock cycles. + + cdns,tshsl-ns: + description: + Delay in nanoseconds for the length that the master mode chip select + outputs are de-asserted between transactions. + + cdns,tsd2d-ns: + description: + Delay in nanoseconds between one chip select being de-activated + and the activation of another. + + cdns,tchsh-ns: + description: + Delay in nanoseconds between last bit of current transaction and + deasserting the device chip select (qspi_n_ss_out). + + cdns,tslch-ns: + description: + Delay in nanoseconds between setting qspi_n_ss_out low and + first bit transfer. + +additionalProperties: true diff --git a/Documentation/devicetree/bindings/spi/cdns,qspi-nor.yaml b/Documentation/devicetree/bindings/spi/cdns,qspi-nor.yaml index ca155abbda7a..0a537fa3a641 100644 --- a/Documentation/devicetree/bindings/spi/cdns,qspi-nor.yaml +++ b/Documentation/devicetree/bindings/spi/cdns,qspi-nor.yaml @@ -29,6 +29,7 @@ properties: - ti,am654-ospi - intel,lgm-qspi - xlnx,versal-ospi-1.0 + - intel,socfpga-qspi - const: cdns,qspi-nor - const: cdns,qspi-nor @@ -86,39 +87,6 @@ properties: items: enum: [ qspi, qspi-ocp ] -# subnode's properties -patternProperties: - "@[0-9a-f]+$": - type: object - description: - Flash device uses the below defined properties in the subnode. - - properties: - cdns,read-delay: - $ref: /schemas/types.yaml#/definitions/uint32 - description: - Delay for read capture logic, in clock cycles. - - cdns,tshsl-ns: - description: - Delay in nanoseconds for the length that the master mode chip select - outputs are de-asserted between transactions. - - cdns,tsd2d-ns: - description: - Delay in nanoseconds between one chip select being de-activated - and the activation of another. - - cdns,tchsh-ns: - description: - Delay in nanoseconds between last bit of current transaction and - deasserting the device chip select (qspi_n_ss_out). - - cdns,tslch-ns: - description: - Delay in nanoseconds between setting qspi_n_ss_out low and - first bit transfer. - required: - compatible - reg diff --git a/Documentation/devicetree/bindings/spi/mediatek,spi-mtk-nor.yaml b/Documentation/devicetree/bindings/spi/mediatek,spi-mtk-nor.yaml index 7393f30535df..4e4694e3d539 100644 --- a/Documentation/devicetree/bindings/spi/mediatek,spi-mtk-nor.yaml +++ b/Documentation/devicetree/bindings/spi/mediatek,spi-mtk-nor.yaml @@ -43,14 +43,19 @@ properties: maxItems: 1 clocks: + minItems: 2 items: - description: clock used for spi bus - description: clock used for controller + - description: clock used for nor dma bus. this depends on hardware + design, so this is optional. clock-names: + minItems: 2 items: - const: spi - const: sf + - const: axi required: - compatible @@ -72,7 +77,7 @@ examples: nor_flash: spi@1100d000 { compatible = "mediatek,mt8173-nor"; reg = <0 0x1100d000 0 0xe0>; - interrupts = <&spi_flash_irq>; + interrupts = <1>; clocks = <&pericfg CLK_PERI_SPI>, <&topckgen CLK_TOP_SPINFI_IFR_SEL>; clock-names = "spi", "sf"; #address-cells = <1>; @@ -84,4 +89,3 @@ examples: }; }; }; - diff --git a/Documentation/devicetree/bindings/spi/renesas,rspi.yaml b/Documentation/devicetree/bindings/spi/renesas,rspi.yaml index 8397f60d80a2..76e6d9e52fc7 100644 --- a/Documentation/devicetree/bindings/spi/renesas,rspi.yaml +++ b/Documentation/devicetree/bindings/spi/renesas,rspi.yaml @@ -21,7 +21,8 @@ properties: - enum: - renesas,rspi-r7s72100 # RZ/A1H - renesas,rspi-r7s9210 # RZ/A2 - - const: renesas,rspi-rz # RZ/A + - renesas,r9a07g044-rspi # RZ/G2{L,LC} + - const: renesas,rspi-rz # RZ/A and RZ/G2{L,LC} - items: - enum: @@ -122,6 +123,7 @@ allOf: contains: enum: - renesas,qspi + - renesas,r9a07g044-rspi then: required: - resets diff --git a/Documentation/devicetree/bindings/spi/spi-controller.yaml b/Documentation/devicetree/bindings/spi/spi-controller.yaml index 8246891602e7..36b72518f565 100644 --- a/Documentation/devicetree/bindings/spi/spi-controller.yaml +++ b/Documentation/devicetree/bindings/spi/spi-controller.yaml @@ -94,73 +94,8 @@ patternProperties: "^.*@[0-9a-f]+$": type: object - properties: - compatible: - description: - Compatible of the SPI device. - - reg: - minItems: 1 - maxItems: 256 - items: - minimum: 0 - maximum: 256 - description: - Chip select used by the device. - - spi-3wire: - $ref: /schemas/types.yaml#/definitions/flag - description: - The device requires 3-wire mode. - - spi-cpha: - $ref: /schemas/types.yaml#/definitions/flag - description: - The device requires shifted clock phase (CPHA) mode. - - spi-cpol: - $ref: /schemas/types.yaml#/definitions/flag - description: - The device requires inverse clock polarity (CPOL) mode. - - spi-cs-high: - $ref: /schemas/types.yaml#/definitions/flag - description: - The device requires the chip select active high. - - spi-lsb-first: - $ref: /schemas/types.yaml#/definitions/flag - description: - The device requires the LSB first mode. - - spi-max-frequency: - $ref: /schemas/types.yaml#/definitions/uint32 - description: - Maximum SPI clocking speed of the device in Hz. - - spi-rx-bus-width: - description: - Bus width to the SPI bus used for read transfers. - If 0 is provided, then no RX will be possible on this device. - $ref: /schemas/types.yaml#/definitions/uint32 - enum: [0, 1, 2, 4, 8] - default: 1 - - spi-rx-delay-us: - description: - Delay, in microseconds, after a read transfer. - - spi-tx-bus-width: - description: - Bus width to the SPI bus used for write transfers. - If 0 is provided, then no TX will be possible on this device. - $ref: /schemas/types.yaml#/definitions/uint32 - enum: [0, 1, 2, 4, 8] - default: 1 - - spi-tx-delay-us: - description: - Delay, in microseconds, after a write transfer. + allOf: + - $ref: spi-peripheral-props.yaml required: - compatible diff --git a/Documentation/devicetree/bindings/spi/spi-fsl-lpspi.yaml b/Documentation/devicetree/bindings/spi/spi-fsl-lpspi.yaml index 312d8fee9dbb..1d46877fe46a 100644 --- a/Documentation/devicetree/bindings/spi/spi-fsl-lpspi.yaml +++ b/Documentation/devicetree/bindings/spi/spi-fsl-lpspi.yaml @@ -14,10 +14,13 @@ allOf: properties: compatible: - enum: - - fsl,imx7ulp-spi - - fsl,imx8qxp-spi - + oneOf: + - enum: + - fsl,imx7ulp-spi + - fsl,imx8qxp-spi + - items: + - const: fsl,imx8ulp-spi + - const: fsl,imx7ulp-spi reg: maxItems: 1 diff --git a/Documentation/devicetree/bindings/spi/spi-mux.yaml b/Documentation/devicetree/bindings/spi/spi-mux.yaml index 51c7622dc20b..7ea79f6d33f3 100644 --- a/Documentation/devicetree/bindings/spi/spi-mux.yaml +++ b/Documentation/devicetree/bindings/spi/spi-mux.yaml @@ -31,6 +31,7 @@ description: | allOf: - $ref: "/schemas/spi/spi-controller.yaml#" + - $ref: "/schemas/spi/spi-peripheral-props.yaml#" maintainers: - Chris Packham <chris.packham@alliedtelesis.co.nz> diff --git a/Documentation/devicetree/bindings/spi/spi-peripheral-props.yaml b/Documentation/devicetree/bindings/spi/spi-peripheral-props.yaml new file mode 100644 index 000000000000..5dd209206e88 --- /dev/null +++ b/Documentation/devicetree/bindings/spi/spi-peripheral-props.yaml @@ -0,0 +1,89 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/spi/spi-peripheral-props.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Peripheral-specific properties for a SPI bus. + +description: + Many SPI controllers need to add properties to peripheral devices. They could + be common properties like spi-max-frequency, spi-cpha, etc. or they could be + controller specific like delay in clock or data lines, etc. These properties + need to be defined in the peripheral node because they are per-peripheral and + there can be multiple peripherals attached to a controller. All those + properties are listed here. The controller specific properties should go in + their own separate schema that should be referenced from here. + +maintainers: + - Pratyush Yadav <p.yadav@ti.com> + +properties: + reg: + minItems: 1 + maxItems: 256 + items: + minimum: 0 + maximum: 256 + description: + Chip select used by the device. + + spi-3wire: + $ref: /schemas/types.yaml#/definitions/flag + description: + The device requires 3-wire mode. + + spi-cpha: + $ref: /schemas/types.yaml#/definitions/flag + description: + The device requires shifted clock phase (CPHA) mode. + + spi-cpol: + $ref: /schemas/types.yaml#/definitions/flag + description: + The device requires inverse clock polarity (CPOL) mode. + + spi-cs-high: + $ref: /schemas/types.yaml#/definitions/flag + description: + The device requires the chip select active high. + + spi-lsb-first: + $ref: /schemas/types.yaml#/definitions/flag + description: + The device requires the LSB first mode. + + spi-max-frequency: + $ref: /schemas/types.yaml#/definitions/uint32 + description: + Maximum SPI clocking speed of the device in Hz. + + spi-rx-bus-width: + description: + Bus width to the SPI bus used for read transfers. + If 0 is provided, then no RX will be possible on this device. + $ref: /schemas/types.yaml#/definitions/uint32 + enum: [0, 1, 2, 4, 8] + default: 1 + + spi-rx-delay-us: + description: + Delay, in microseconds, after a read transfer. + + spi-tx-bus-width: + description: + Bus width to the SPI bus used for write transfers. + If 0 is provided, then no TX will be possible on this device. + $ref: /schemas/types.yaml#/definitions/uint32 + enum: [0, 1, 2, 4, 8] + default: 1 + + spi-tx-delay-us: + description: + Delay, in microseconds, after a write transfer. + +# The controller specific properties go here. +allOf: + - $ref: cdns,qspi-nor-peripheral-props.yaml# + +additionalProperties: true diff --git a/Documentation/devicetree/bindings/spi/spi-pl022.yaml b/Documentation/devicetree/bindings/spi/spi-pl022.yaml index a91d868e40c5..6d633728fc2b 100644 --- a/Documentation/devicetree/bindings/spi/spi-pl022.yaml +++ b/Documentation/devicetree/bindings/spi/spi-pl022.yaml @@ -72,6 +72,9 @@ properties: - const: rx - const: tx + resets: + maxItems: 1 + patternProperties: "^[a-zA-Z][a-zA-Z0-9,+\\-._]{0,63}@[0-9a-f]+$": type: object diff --git a/Documentation/devicetree/bindings/spi/spi-rockchip.yaml b/Documentation/devicetree/bindings/spi/spi-rockchip.yaml index 7f987e79337c..52a78a2e362e 100644 --- a/Documentation/devicetree/bindings/spi/spi-rockchip.yaml +++ b/Documentation/devicetree/bindings/spi/spi-rockchip.yaml @@ -33,6 +33,7 @@ properties: - rockchip,rk3328-spi - rockchip,rk3368-spi - rockchip,rk3399-spi + - rockchip,rk3568-spi - rockchip,rv1126-spi - const: rockchip,rk3066-spi diff --git a/Documentation/devicetree/bindings/spmi/mtk,spmi-mtk-pmif.yaml b/Documentation/devicetree/bindings/spmi/mtk,spmi-mtk-pmif.yaml new file mode 100644 index 000000000000..2445c5e0b0ef --- /dev/null +++ b/Documentation/devicetree/bindings/spmi/mtk,spmi-mtk-pmif.yaml @@ -0,0 +1,76 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/spmi/mtk,spmi-mtk-pmif.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Mediatek SPMI Controller Device Tree Bindings + +maintainers: + - Hsin-Hsiung Wang <hsin-hsiung.wang@mediatek.com> + +description: |+ + On MediaTek SoCs the PMIC is connected via SPMI and the controller allows + for multiple SoCs to control a single SPMI master. + +allOf: + - $ref: "spmi.yaml" + +properties: + compatible: + enum: + - mediatek,mt6873-spmi + - mediatek,mt8195-spmi + + reg: + maxItems: 2 + + reg-names: + items: + - const: pmif + - const: spmimst + + clocks: + minItems: 3 + maxItems: 3 + + clock-names: + items: + - const: pmif_sys_ck + - const: pmif_tmr_ck + - const: spmimst_clk_mux + + assigned-clocks: + maxItems: 1 + + assigned-clock-parents: + maxItems: 1 + +required: + - compatible + - reg + - reg-names + - clocks + - clock-names + +unevaluatedProperties: false + +examples: + - | + #include <dt-bindings/clock/mt8192-clk.h> + + spmi: spmi@10027000 { + compatible = "mediatek,mt6873-spmi"; + reg = <0x10027000 0xe00>, + <0x10029000 0x100>; + reg-names = "pmif", "spmimst"; + clocks = <&infracfg CLK_INFRA_PMIC_AP>, + <&infracfg CLK_INFRA_PMIC_TMR>, + <&topckgen CLK_TOP_SPMI_MST_SEL>; + clock-names = "pmif_sys_ck", + "pmif_tmr_ck", + "spmimst_clk_mux"; + assigned-clocks = <&topckgen CLK_TOP_PWRAP_ULPOSC_SEL>; + assigned-clock-parents = <&topckgen CLK_TOP_OSC_D10>; + }; +... diff --git a/Documentation/devicetree/bindings/spmi/spmi.yaml b/Documentation/devicetree/bindings/spmi/spmi.yaml index 1d243faef2f8..c1b06fa5c631 100644 --- a/Documentation/devicetree/bindings/spmi/spmi.yaml +++ b/Documentation/devicetree/bindings/spmi/spmi.yaml @@ -24,9 +24,6 @@ properties: $nodename: pattern: "^spmi@.*" - reg: - maxItems: 1 - "#address-cells": const: 2 diff --git a/Documentation/devicetree/bindings/sram/sram.yaml b/Documentation/devicetree/bindings/sram/sram.yaml index d4e418b6a1c1..668a9a41a775 100644 --- a/Documentation/devicetree/bindings/sram/sram.yaml +++ b/Documentation/devicetree/bindings/sram/sram.yaml @@ -31,6 +31,9 @@ properties: - amlogic,meson-gxbb-sram - arm,juno-sram-ns - atmel,sama5d2-securam + - nvidia,tegra186-sysram + - nvidia,tegra194-sysram + - nvidia,tegra234-sysram - qcom,rpm-msg-ram - rockchip,rk3288-pmu-sram diff --git a/Documentation/devicetree/bindings/thermal/brcm,avs-tmon.txt b/Documentation/devicetree/bindings/thermal/brcm,avs-tmon.txt deleted file mode 100644 index 74a9ef09db8b..000000000000 --- a/Documentation/devicetree/bindings/thermal/brcm,avs-tmon.txt +++ /dev/null @@ -1,23 +0,0 @@ -* Broadcom STB thermal management - -Thermal management core, provided by the AVS TMON hardware block. - -Required properties: -- compatible: must be one of: - "brcm,avs-tmon-bcm7216" - "brcm,avs-tmon-bcm7445" - "brcm,avs-tmon" -- reg: address range for the AVS TMON registers -- interrupts: temperature monitor interrupt, for high/low threshold triggers, - required except for "brcm,avs-tmon-bcm7216" -- interrupt-names: should be "tmon" - -Example: - - thermal@f04d1500 { - compatible = "brcm,avs-tmon-bcm7445", "brcm,avs-tmon"; - reg = <0xf04d1500 0x28>; - interrupts = <0x6>; - interrupt-names = "tmon"; - interrupt-parent = <&avs_host_l2_intc>; - }; diff --git a/Documentation/devicetree/bindings/thermal/brcm,avs-tmon.yaml b/Documentation/devicetree/bindings/thermal/brcm,avs-tmon.yaml new file mode 100644 index 000000000000..267a0f423504 --- /dev/null +++ b/Documentation/devicetree/bindings/thermal/brcm,avs-tmon.yaml @@ -0,0 +1,56 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/thermal/brcm,avs-tmon.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Broadcom STB thermal management + +description: Thermal management core, provided by the AVS TMON hardware block. + +maintainers: + - Florian Fainelli <f.fainelli@gmail.com> + +allOf: + - $ref: thermal-sensor.yaml# + +properties: + compatible: + items: + - enum: + - brcm,avs-tmon-bcm7216 + - brcm,avs-tmon-bcm7445 + - const: brcm,avs-tmon + + reg: + maxItems: 1 + description: > + Address range for the AVS TMON registers + + interrupts: + maxItems: 1 + + interrupt-names: + items: + - const: tmon + + "#thermal-sensor-cells": + const: 0 + +additionalProperties: false + +required: + - compatible + - reg + - "#thermal-sensor-cells" + +examples: + - | + thermal@f04d1500 { + compatible = "brcm,avs-tmon-bcm7445", "brcm,avs-tmon"; + reg = <0xf04d1500 0x28>; + interrupts = <0x6>; + interrupt-names = "tmon"; + interrupt-parent = <&avs_host_l2_intc>; + #thermal-sensor-cells = <0>; + }; diff --git a/Documentation/devicetree/bindings/thermal/nvidia,tegra186-bpmp-thermal.txt b/Documentation/devicetree/bindings/thermal/nvidia,tegra186-bpmp-thermal.txt deleted file mode 100644 index fc87f6aa1b8f..000000000000 --- a/Documentation/devicetree/bindings/thermal/nvidia,tegra186-bpmp-thermal.txt +++ /dev/null @@ -1,33 +0,0 @@ -NVIDIA Tegra186 BPMP thermal sensor - -In Tegra186, the BPMP (Boot and Power Management Processor) implements an -interface that is used to read system temperatures, including CPU cluster -and GPU temperatures. This binding describes the thermal sensor that is -exposed by BPMP. - -The BPMP thermal node must be located directly inside the main BPMP node. See -../firmware/nvidia,tegra186-bpmp.txt for details of the BPMP binding. - -This node represents a thermal sensor. See Documentation/devicetree/bindings/thermal/thermal-sensor.yaml for details of the -core thermal binding. - -Required properties: -- compatible: - Array of strings. - One of: - - "nvidia,tegra186-bpmp-thermal" - - "nvidia,tegra194-bpmp-thermal" -- #thermal-sensor-cells: Cell for sensor index. - Single-cell integer. - Must be <1>. - -Example: - -bpmp { - ... - - bpmp_thermal: thermal { - compatible = "nvidia,tegra186-bpmp-thermal"; - #thermal-sensor-cells = <1>; - }; -}; diff --git a/Documentation/devicetree/bindings/thermal/nvidia,tegra186-bpmp-thermal.yaml b/Documentation/devicetree/bindings/thermal/nvidia,tegra186-bpmp-thermal.yaml new file mode 100644 index 000000000000..c91fd07e4061 --- /dev/null +++ b/Documentation/devicetree/bindings/thermal/nvidia,tegra186-bpmp-thermal.yaml @@ -0,0 +1,42 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/thermal/nvidia,tegra186-bpmp-thermal.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: NVIDIA Tegra186 (and later) BPMP thermal sensor + +maintainers: + - Thierry Reding <thierry.reding@gmail.com> + - Jon Hunter <jonathanh@nvidia.com> + +description: | + In Tegra186, the BPMP (Boot and Power Management Processor) implements + an interface that is used to read system temperatures, including CPU + cluster and GPU temperatures. This binding describes the thermal + sensor that is exposed by BPMP. + + The BPMP thermal node must be located directly inside the main BPMP + node. See ../firmware/nvidia,tegra186-bpmp.yaml for details of the + BPMP binding. + + This node represents a thermal sensor. See + + Documentation/devicetree/bindings/thermal/thermal-sensor.yaml + + for details of the core thermal binding. + +properties: + compatible: + enum: + - nvidia,tegra186-bpmp-thermal + - nvidia,tegra194-bpmp-thermal + + '#thermal-sensor-cells': + $ref: /schemas/types.yaml#/definitions/uint32 + description: Number of cells needed in the phandle specifier to + identify a given sensor. Must be 1 and the single cell specifies + the sensor index. + const: 1 + +additionalProperties: false diff --git a/Documentation/devicetree/bindings/thermal/rzg2l-thermal.yaml b/Documentation/devicetree/bindings/thermal/rzg2l-thermal.yaml new file mode 100644 index 000000000000..ccab9511a042 --- /dev/null +++ b/Documentation/devicetree/bindings/thermal/rzg2l-thermal.yaml @@ -0,0 +1,76 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/thermal/rzg2l-thermal.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Renesas RZ/G2L Thermal Sensor Unit + +description: + On RZ/G2L SoCs, the thermal sensor unit (TSU) measures the + temperature(Tj) inside the LSI. + +maintainers: + - Biju Das <biju.das.jz@bp.renesas.com> + +properties: + compatible: + items: + - enum: + - renesas,r9a07g044-tsu # RZ/G2{L,LC} + - const: renesas,rzg2l-tsu + + reg: + maxItems: 1 + + clocks: + maxItems: 1 + + power-domains: + maxItems: 1 + + resets: + maxItems: 1 + + "#thermal-sensor-cells": + const: 1 + +required: + - compatible + - reg + - clocks + - power-domains + - resets + - "#thermal-sensor-cells" + +additionalProperties: false + +examples: + - | + #include <dt-bindings/clock/r9a07g044-cpg.h> + + tsu: thermal@10059400 { + compatible = "renesas,r9a07g044-tsu", + "renesas,rzg2l-tsu"; + reg = <0x10059400 0x400>; + clocks = <&cpg CPG_MOD R9A07G044_TSU_PCLK>; + resets = <&cpg R9A07G044_TSU_PRESETN>; + power-domains = <&cpg>; + #thermal-sensor-cells = <1>; + }; + + thermal-zones { + cpu-thermal { + polling-delay-passive = <250>; + polling-delay = <1000>; + thermal-sensors = <&tsu 0>; + + trips { + sensor_crit: sensor-crit { + temperature = <125000>; + hysteresis = <1000>; + type = "critical"; + }; + }; + }; + }; diff --git a/Documentation/devicetree/bindings/thermal/thermal-zones.yaml b/Documentation/devicetree/bindings/thermal/thermal-zones.yaml index a07de5ed0ca6..2d34f3ccb257 100644 --- a/Documentation/devicetree/bindings/thermal/thermal-zones.yaml +++ b/Documentation/devicetree/bindings/thermal/thermal-zones.yaml @@ -199,12 +199,11 @@ patternProperties: contribution: $ref: /schemas/types.yaml#/definitions/uint32 - minimum: 0 - maximum: 100 description: - The percentage contribution of the cooling devices at the - specific trip temperature referenced in this map - to this thermal zone + The cooling contribution to the thermal zone of the referred + cooling device at the referred trip point. The contribution is + a ratio of the sum of all cooling contributions within a + thermal zone. required: - trip diff --git a/Documentation/devicetree/bindings/timer/cdns,ttc.yaml b/Documentation/devicetree/bindings/timer/cdns,ttc.yaml index 8615353f69b4..c3386076a98c 100644 --- a/Documentation/devicetree/bindings/timer/cdns,ttc.yaml +++ b/Documentation/devicetree/bindings/timer/cdns,ttc.yaml @@ -25,6 +25,9 @@ properties: clocks: maxItems: 1 + power-domains: + maxItems: 1 + timer-width: $ref: "/schemas/types.yaml#/definitions/uint32" description: | diff --git a/Documentation/devicetree/bindings/timer/mstar,msc313e-timer.yaml b/Documentation/devicetree/bindings/timer/mstar,msc313e-timer.yaml new file mode 100644 index 000000000000..03d5dba5d5b3 --- /dev/null +++ b/Documentation/devicetree/bindings/timer/mstar,msc313e-timer.yaml @@ -0,0 +1,46 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/timer/mstar,msc313e-timer.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Mstar MSC313e Timer Device Tree Bindings + +maintainers: + - Daniel Palmer <daniel@0x0f.com> + - Romain Perier <romain.perier@gmail.com> + +properties: + compatible: + enum: + - mstar,msc313e-timer + - sstar,ssd20xd-timer + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + clocks: + maxItems: 1 + +required: + - compatible + - reg + - interrupts + - clocks + +additionalProperties: false + +examples: + - | + #include <dt-bindings/interrupt-controller/arm-gic.h> + + timer@6040 { + compatible = "mstar,msc313e-timer"; + reg = <0x6040 0x40>; + clocks = <&xtal_div2>; + interrupts-extended = <&intc_fiq GIC_SPI 0 IRQ_TYPE_LEVEL_HIGH>; + }; +... diff --git a/Documentation/devicetree/bindings/timer/nxp,tpm-timer.yaml b/Documentation/devicetree/bindings/timer/nxp,tpm-timer.yaml index edd9585f6726..f69773a8e4b9 100644 --- a/Documentation/devicetree/bindings/timer/nxp,tpm-timer.yaml +++ b/Documentation/devicetree/bindings/timer/nxp,tpm-timer.yaml @@ -19,7 +19,11 @@ description: | properties: compatible: - const: fsl,imx7ulp-tpm + oneOf: + - const: fsl,imx7ulp-tpm + - items: + - const: fsl,imx8ulp-tpm + - const: fsl,imx7ulp-tpm reg: maxItems: 1 diff --git a/Documentation/devicetree/bindings/timer/renesas,ostm.yaml b/Documentation/devicetree/bindings/timer/renesas,ostm.yaml index 600d47ab7d58..7fa7f977b44c 100644 --- a/Documentation/devicetree/bindings/timer/renesas,ostm.yaml +++ b/Documentation/devicetree/bindings/timer/renesas,ostm.yaml @@ -21,9 +21,10 @@ properties: compatible: items: - enum: - - renesas,r7s72100-ostm # RZ/A1H - - renesas,r7s9210-ostm # RZ/A2M - - const: renesas,ostm # Generic + - renesas,r7s72100-ostm # RZ/A1H + - renesas,r7s9210-ostm # RZ/A2M + - renesas,r9a07g044-ostm # RZ/G2{L,LC} + - const: renesas,ostm # Generic reg: maxItems: 1 @@ -37,6 +38,9 @@ properties: power-domains: maxItems: 1 + resets: + maxItems: 1 + required: - compatible - reg @@ -44,6 +48,16 @@ required: - clocks - power-domains +if: + properties: + compatible: + contains: + enum: + - renesas,r9a07g044-ostm +then: + required: + - resets + additionalProperties: false examples: diff --git a/Documentation/devicetree/bindings/timer/rockchip,rk-timer.yaml b/Documentation/devicetree/bindings/timer/rockchip,rk-timer.yaml index e26ecb5893ae..5d157d87dad5 100644 --- a/Documentation/devicetree/bindings/timer/rockchip,rk-timer.yaml +++ b/Documentation/devicetree/bindings/timer/rockchip,rk-timer.yaml @@ -18,7 +18,6 @@ properties: - enum: - rockchip,rv1108-timer - rockchip,rk3036-timer - - rockchip,rk3066-timer - rockchip,rk3188-timer - rockchip,rk3228-timer - rockchip,rk3229-timer diff --git a/Documentation/devicetree/bindings/timer/sifive,clint.yaml b/Documentation/devicetree/bindings/timer/sifive,clint.yaml index a35952f48742..8d5f4687add9 100644 --- a/Documentation/devicetree/bindings/timer/sifive,clint.yaml +++ b/Documentation/devicetree/bindings/timer/sifive,clint.yaml @@ -25,6 +25,7 @@ properties: items: - enum: - sifive,fu540-c000-clint + - starfive,jh7100-clint - canaan,k210-clint - const: sifive,clint0 diff --git a/Documentation/devicetree/bindings/trivial-devices.yaml b/Documentation/devicetree/bindings/trivial-devices.yaml index 791079021f1b..091792ba993e 100644 --- a/Documentation/devicetree/bindings/trivial-devices.yaml +++ b/Documentation/devicetree/bindings/trivial-devices.yaml @@ -31,7 +31,7 @@ properties: - enum: # SMBus/I2C Digital Temperature Sensor in 6-Pin SOT with SMBus Alert and Over Temperature Pin - ad,ad7414 - # ADM9240: Complete System Hardware Monitor for uProcessor-Based Systems + # ADM9240: Complete System Hardware Monitor for uProcessor-Based Systems - ad,adm9240 # AD5110 - Nonvolatile Digital Potentiometer - adi,ad5110 @@ -43,7 +43,7 @@ properties: - adi,adp5589 # AMS iAQ-Core VOC Sensor - ams,iaq-core - # i2c serial eeprom (24cxx) + # i2c serial eeprom (24cxx) - at,24c08 # i2c trusted platform module (TPM) - atmel,at97sc3204t @@ -73,6 +73,8 @@ properties: - dallas,ds4510 # Digital Thermometer and Thermostat - dallas,ds75 + # Delta AHE-50DC Open19 power shelf fan control module + - delta,ahe50dc-fan # Delta Electronics DPS-650-AB power supply - delta,dps650ab # Delta Electronics DPS920AB 920W 54V Power Supply @@ -121,8 +123,14 @@ properties: - ibm,cffps2 # Infineon IR36021 digital POL buck controller - infineon,ir36021 + # Infineon IR38060 Voltage Regulator + - infineon,ir38060 # Infineon IR38064 Voltage Regulator - infineon,ir38064 + # Infineon IR38164 Voltage Regulator + - infineon,ir38164 + # Infineon IR38263 Voltage Regulator + - infineon,ir38263 # Infineon SLB9635 (Soft-) I2C TPM (old protocol, max 100khz) - infineon,slb9635tt # Infineon SLB9645 I2C TPM (new protocol, max 400khz) @@ -281,6 +289,8 @@ properties: - sensirion,sgp30 # Sensirion gas sensor with I2C interface - sensirion,sgp40 + # Sensirion temperature & humidity sensor with I2C interface + - sensirion,sht4x # Sensortek 3 axis accelerometer - sensortek,stk8312 # Sensortek 3 axis accelerometer @@ -293,9 +303,9 @@ properties: - skyworks,sky81452 # Socionext SynQuacer TPM MMIO module - socionext,synquacer-tpm-mmio - # i2c serial eeprom (24cxx) - - sparkfun,qwiic-joystick # SparkFun Qwiic Joystick (COM-15168) with i2c interface + - sparkfun,qwiic-joystick + # i2c serial eeprom (24cxx) - st,24c256 # Ambient Light Sensor with SMBUS/Two Wire Serial Interface - taos,tsl2550 @@ -329,12 +339,19 @@ properties: - ti,tmp122 # Digital Temperature Sensor - ti,tmp275 + # TI DC-DC converter on PMBus + - ti,tps40400 # TI Dual channel DCAP+ multiphase controller TPS53676 with AVSBus - ti,tps53676 # TI Dual channel DCAP+ multiphase controller TPS53679 - ti,tps53679 # TI Dual channel DCAP+ multiphase controller TPS53688 - ti,tps53688 + # TI DC-DC converters on PMBus + - ti,tps544b20 + - ti,tps544b25 + - ti,tps544c20 + - ti,tps544c25 # Winbond/Nuvoton H/W Monitor - winbond,w83793 # i2c trusted platform module (TPM) diff --git a/Documentation/devicetree/bindings/ufs/ufshcd-pltfrm.txt b/Documentation/devicetree/bindings/ufs/ufshcd-pltfrm.txt index d8fd4df81743..d0fee78e6203 100644 --- a/Documentation/devicetree/bindings/ufs/ufshcd-pltfrm.txt +++ b/Documentation/devicetree/bindings/ufs/ufshcd-pltfrm.txt @@ -16,6 +16,7 @@ Required properties: "qcom,sm8150-ufshc", "qcom,ufshc", "jedec,ufs-2.0" "qcom,sm8250-ufshc", "qcom,ufshc", "jedec,ufs-2.0" "qcom,sm8350-ufshc", "qcom,ufshc", "jedec,ufs-2.0" + "qcom,sm8450-ufshc", "qcom,ufshc", "jedec,ufs-2.0" - interrupts : <interrupt mapping for UFS host controller IRQ> - reg : <registers mapping> diff --git a/Documentation/devicetree/bindings/usb/brcm,bdc.txt b/Documentation/devicetree/bindings/usb/brcm,bdc.txt deleted file mode 100644 index c9f52b97cef1..000000000000 --- a/Documentation/devicetree/bindings/usb/brcm,bdc.txt +++ /dev/null @@ -1,29 +0,0 @@ -Broadcom USB Device Controller (BDC) -==================================== - -Required properties: - -- compatible: must be one of: - "brcm,bdc-udc-v2" - "brcm,bdc" -- reg: the base register address and length -- interrupts: the interrupt line for this controller - -Optional properties: - -On Broadcom STB platforms, these properties are required: - -- phys: phandle to one or two USB PHY blocks - NOTE: Some SoC's have a single phy and some have - USB 2.0 and USB 3.0 phys -- clocks: phandle to the functional clock of this block - -Example: - - bdc@f0b02000 { - compatible = "brcm,bdc-udc-v2"; - reg = <0xf0b02000 0xfc4>; - interrupts = <0x0 0x60 0x0>; - phys = <&usbphy_0 0x0>; - clocks = <&sw_usbd>; - }; diff --git a/Documentation/devicetree/bindings/usb/brcm,bdc.yaml b/Documentation/devicetree/bindings/usb/brcm,bdc.yaml new file mode 100644 index 000000000000..9e561fee98f1 --- /dev/null +++ b/Documentation/devicetree/bindings/usb/brcm,bdc.yaml @@ -0,0 +1,50 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/usb/brcm,bdc.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Broadcom USB Device Controller (BDC) + +maintainers: + - Al Cooper <alcooperx@gmail.com> + - Florian Fainelli <f.fainelli@gmail.com> + +properties: + compatible: + items: + - enum: + - brcm,bdc-udc-v2 + - brcm,bdc + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + phys: + minItems: 1 + items: + - description: USB 2.0 or 3.0 PHY + - description: USB 3.0 PHY if there is a dedicated 2.0 PHY + + clocks: + maxItems: 1 + +required: + - compatible + - reg + - interrupts + +additionalProperties: false + +examples: + - | + usb@f0b02000 { + compatible = "brcm,bdc-udc-v2"; + reg = <0xf0b02000 0xfc4>; + interrupts = <0x0 0x60 0x0>; + phys = <&usbphy_0 0x0>; + clocks = <&sw_usbd>; + }; diff --git a/Documentation/devicetree/bindings/usb/dwc2.yaml b/Documentation/devicetree/bindings/usb/dwc2.yaml index 56a818478cd7..f00867ebc147 100644 --- a/Documentation/devicetree/bindings/usb/dwc2.yaml +++ b/Documentation/devicetree/bindings/usb/dwc2.yaml @@ -114,6 +114,8 @@ properties: usb-role-switch: true + role-switch-default-mode: true + g-rx-fifo-size: $ref: /schemas/types.yaml#/definitions/uint32 description: size of rx fifo size in gadget mode. @@ -136,6 +138,17 @@ properties: description: If present indicates that we need to reset the PHY when we detect a wakeup. This is due to a hardware errata. + port: + description: + Any connector to the data bus of this controller should be modelled + using the OF graph bindings specified, if the "usb-role-switch" + property is used. + $ref: /schemas/graph.yaml#/properties/port + +dependencies: + port: [ usb-role-switch ] + role-switch-default-mode: [ usb-role-switch ] + required: - compatible - reg diff --git a/Documentation/devicetree/bindings/usb/dwc3-xilinx.txt b/Documentation/devicetree/bindings/usb/dwc3-xilinx.txt deleted file mode 100644 index 04813a46e5d0..000000000000 --- a/Documentation/devicetree/bindings/usb/dwc3-xilinx.txt +++ /dev/null @@ -1,56 +0,0 @@ -Xilinx SuperSpeed DWC3 USB SoC controller - -Required properties: -- compatible: May contain "xlnx,zynqmp-dwc3" or "xlnx,versal-dwc3" -- reg: Base address and length of the register control block -- clocks: A list of phandles for the clocks listed in clock-names -- clock-names: Should contain the following: - "bus_clk" Master/Core clock, have to be >= 125 MHz for SS - operation and >= 60MHz for HS operation - - "ref_clk" Clock source to core during PHY power down -- resets: A list of phandles for resets listed in reset-names -- reset-names: - "usb_crst" USB core reset - "usb_hibrst" USB hibernation reset - "usb_apbrst" USB APB reset - -Required child node: -A child node must exist to represent the core DWC3 IP block. The name of -the node is not important. The content of the node is defined in dwc3.txt. - -Optional properties for snps,dwc3: -- dma-coherent: Enable this flag if CCI is enabled in design. Adding this - flag configures Global SoC bus Configuration Register and - Xilinx USB 3.0 IP - USB coherency register to enable CCI. -- interrupt-names: Should contain the following: - "dwc_usb3" USB gadget mode interrupts - "otg" USB OTG mode interrupts - "hiber" USB hibernation interrupts - -Example device node: - - usb@0 { - #address-cells = <0x2>; - #size-cells = <0x1>; - compatible = "xlnx,zynqmp-dwc3"; - reg = <0x0 0xff9d0000 0x0 0x100>; - clock-names = "bus_clk", "ref_clk"; - clocks = <&clk125>, <&clk125>; - resets = <&zynqmp_reset ZYNQMP_RESET_USB1_CORERESET>, - <&zynqmp_reset ZYNQMP_RESET_USB1_HIBERRESET>, - <&zynqmp_reset ZYNQMP_RESET_USB1_APB>; - reset-names = "usb_crst", "usb_hibrst", "usb_apbrst"; - ranges; - - dwc3@fe200000 { - compatible = "snps,dwc3"; - reg = <0x0 0xfe200000 0x40000>; - interrupt-names = "dwc_usb3", "otg", "hiber"; - interrupts = <0 65 4>, <0 69 4>, <0 75 4>; - phys = <&psgtr 2 PHY_TYPE_USB3 0 2>; - phy-names = "usb3-phy"; - dr_mode = "host"; - dma-coherent; - }; - }; diff --git a/Documentation/devicetree/bindings/usb/dwc3-xilinx.yaml b/Documentation/devicetree/bindings/usb/dwc3-xilinx.yaml new file mode 100644 index 000000000000..f77c16e203d5 --- /dev/null +++ b/Documentation/devicetree/bindings/usb/dwc3-xilinx.yaml @@ -0,0 +1,131 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/usb/dwc3-xilinx.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Xilinx SuperSpeed DWC3 USB SoC controller + +maintainers: + - Manish Narani <manish.narani@xilinx.com> + +properties: + compatible: + items: + - enum: + - xlnx,zynqmp-dwc3 + - xlnx,versal-dwc3 + reg: + maxItems: 1 + + "#address-cells": + enum: [ 1, 2 ] + + "#size-cells": + enum: [ 1, 2 ] + + ranges: true + + power-domains: + description: specifies a phandle to PM domain provider node + maxItems: 1 + + clocks: + description: + A list of phandle and clock-specifier pairs for the clocks + listed in clock-names. + items: + - description: Master/Core clock, has to be >= 125 MHz + for SS operation and >= 60MHz for HS operation. + - description: Clock source to core during PHY power down. + + clock-names: + items: + - const: bus_clk + - const: ref_clk + + resets: + description: + A list of phandles for resets listed in reset-names. + + items: + - description: USB core reset + - description: USB hibernation reset + - description: USB APB reset + + reset-names: + items: + - const: usb_crst + - const: usb_hibrst + - const: usb_apbrst + + phys: + minItems: 1 + maxItems: 2 + + phy-names: + minItems: 1 + maxItems: 2 + items: + enum: + - usb2-phy + - usb3-phy + +# Required child node: + +patternProperties: + "^usb@[0-9a-f]+$": + $ref: snps,dwc3.yaml# + +required: + - compatible + - reg + - "#address-cells" + - "#size-cells" + - ranges + - power-domains + - clocks + - clock-names + - resets + - reset-names + +additionalProperties: false + +examples: + - | + #include <dt-bindings/dma/xlnx-zynqmp-dpdma.h> + #include <dt-bindings/power/xlnx-zynqmp-power.h> + #include <dt-bindings/reset/xlnx-zynqmp-resets.h> + #include <dt-bindings/clock/xlnx-zynqmp-clk.h> + #include <dt-bindings/reset/xlnx-zynqmp-resets.h> + #include <dt-bindings/phy/phy.h> + axi { + #address-cells = <2>; + #size-cells = <2>; + + usb@0 { + #address-cells = <0x2>; + #size-cells = <0x2>; + compatible = "xlnx,zynqmp-dwc3"; + reg = <0x0 0xff9d0000 0x0 0x100>; + clocks = <&zynqmp_clk USB0_BUS_REF>, <&zynqmp_clk USB3_DUAL_REF>; + clock-names = "bus_clk", "ref_clk"; + power-domains = <&zynqmp_firmware PD_USB_0>; + resets = <&zynqmp_reset ZYNQMP_RESET_USB1_CORERESET>, + <&zynqmp_reset ZYNQMP_RESET_USB1_HIBERRESET>, + <&zynqmp_reset ZYNQMP_RESET_USB1_APB>; + reset-names = "usb_crst", "usb_hibrst", "usb_apbrst"; + phys = <&psgtr 2 PHY_TYPE_USB3 0 2>; + phy-names = "usb3-phy"; + ranges; + + usb@fe200000 { + compatible = "snps,dwc3"; + reg = <0x0 0xfe200000 0x0 0x40000>; + interrupt-names = "host", "otg"; + interrupts = <0 65 4>, <0 69 4>; + dr_mode = "host"; + dma-coherent; + }; + }; + }; diff --git a/Documentation/devicetree/bindings/usb/intel,keembay-dwc3.yaml b/Documentation/devicetree/bindings/usb/intel,keembay-dwc3.yaml index 43b91ab62004..d3511f48cd55 100644 --- a/Documentation/devicetree/bindings/usb/intel,keembay-dwc3.yaml +++ b/Documentation/devicetree/bindings/usb/intel,keembay-dwc3.yaml @@ -13,6 +13,9 @@ properties: compatible: const: intel,keembay-dwc3 + reg: + maxItems: 1 + clocks: maxItems: 4 diff --git a/Documentation/devicetree/bindings/usb/nvidia,tegra-xudc.yaml b/Documentation/devicetree/bindings/usb/nvidia,tegra-xudc.yaml index 8428415896ce..a39c76b89484 100644 --- a/Documentation/devicetree/bindings/usb/nvidia,tegra-xudc.yaml +++ b/Documentation/devicetree/bindings/usb/nvidia,tegra-xudc.yaml @@ -59,6 +59,19 @@ properties: - const: fs_src - const: hs_src + interconnects: + items: + - description: memory read client + - description: memory write client + + interconnect-names: + items: + - const: dma-mem # read + - const: write + + iommus: + maxItems: 1 + power-domains: items: - description: XUSBB(device) power-domain diff --git a/Documentation/devicetree/bindings/usb/qcom,dwc3.yaml b/Documentation/devicetree/bindings/usb/qcom,dwc3.yaml index 2bdaba023c01..2d23a4ff702f 100644 --- a/Documentation/devicetree/bindings/usb/qcom,dwc3.yaml +++ b/Documentation/devicetree/bindings/usb/qcom,dwc3.yaml @@ -13,7 +13,9 @@ properties: compatible: items: - enum: + - qcom,ipq4019-dwc3 - qcom,ipq6018-dwc3 + - qcom,ipq8064-dwc3 - qcom,msm8996-dwc3 - qcom,msm8998-dwc3 - qcom,sc7180-dwc3 @@ -23,9 +25,11 @@ properties: - qcom,sdx55-dwc3 - qcom,sm4250-dwc3 - qcom,sm6115-dwc3 + - qcom,sm6350-dwc3 - qcom,sm8150-dwc3 - qcom,sm8250-dwc3 - qcom,sm8350-dwc3 + - qcom,sm8450-dwc3 - const: qcom,dwc3 reg: diff --git a/Documentation/devicetree/bindings/usb/snps,dwc3.yaml b/Documentation/devicetree/bindings/usb/snps,dwc3.yaml index 25ac2c93dc6c..d29ffcd27472 100644 --- a/Documentation/devicetree/bindings/usb/snps,dwc3.yaml +++ b/Documentation/devicetree/bindings/usb/snps,dwc3.yaml @@ -36,6 +36,9 @@ properties: - const: synopsys,dwc3 deprecated: true + reg: + maxItems: 1 + interrupts: description: It's either a single common DWC3 interrupt (dwc_usb3) or individual @@ -65,6 +68,9 @@ properties: - enum: [bus_early, ref, suspend] - true + iommus: + maxItems: 1 + usb-phy: minItems: 1 items: diff --git a/Documentation/devicetree/bindings/vendor-prefixes.yaml b/Documentation/devicetree/bindings/vendor-prefixes.yaml index 7463870d0922..294093d45a23 100644 --- a/Documentation/devicetree/bindings/vendor-prefixes.yaml +++ b/Documentation/devicetree/bindings/vendor-prefixes.yaml @@ -25,6 +25,8 @@ patternProperties: # Keep list in alphabetical order. "^70mai,.*": description: 70mai Co., Ltd. + "^8dev,.*": + description: 8devices, UAB "^abb,.*": description: ABB "^abilis,.*": @@ -187,6 +189,8 @@ patternProperties: description: Shanghai Broadmobi Communication Technology Co.,Ltd. "^brcm,.*": description: Broadcom Corporation + "^bsh,.*": + description: BSH Hausgeraete GmbH "^buffalo,.*": description: Buffalo, Inc. "^bur,.*": @@ -379,6 +383,8 @@ patternProperties: description: Silicon Laboratories (formerly Energy Micro AS) "^engicam,.*": description: Engicam S.r.l. + "^engleder,.*": + description: Engleder "^epcos,.*": description: EPCOS AG "^epfl,.*": @@ -437,6 +443,8 @@ patternProperties: description: Freescale Semiconductor "^fujitsu,.*": description: Fujitsu Ltd. + "^fxtec,.*": + description: FX Technology Ltd. "^gardena,.*": description: GARDENA GmbH "^gateworks,.*": @@ -511,6 +519,8 @@ patternProperties: description: HannStar Display Co. "^holtek,.*": description: Holtek Semiconductor, Inc. + "^huawei,.*": + description: Huawei Technologies Co., Ltd. "^hugsun,.*": description: Shenzhen Hugsun Technology Co. Ltd. "^hwacom,.*": @@ -593,6 +603,8 @@ patternProperties: description: JetHome (IP Sokolov P.A.) "^jianda,.*": description: Jiandangjing Technology Co., Ltd. + "^joz,.*": + description: JOZ BV "^kam,.*": description: Kamstrup A/S "^karo,.*": @@ -852,6 +864,8 @@ patternProperties: description: OLIMEX Ltd. "^olpc,.*": description: One Laptop Per Child + "^oneplus,.*": + description: OnePlus Technology (Shenzhen) Co., Ltd. "^onion,.*": description: Onion Corporation "^onnn,.*": @@ -1153,6 +1167,8 @@ patternProperties: description: Summit microelectronics "^sunchip,.*": description: Shenzhen Sunchip Technology Co., Ltd + "^sunplus,.*": + description: Sunplus Technology Co., Ltd. "^SUNW,.*": description: Sun Microsystems, Inc "^supermicro,.*": @@ -1191,10 +1207,14 @@ patternProperties: description: Terasic Inc. "^tfc,.*": description: Three Five Corp + "^thead,.*": + description: T-Head Semiconductor Co., Ltd. "^thine,.*": description: THine Electronics, Inc. "^thingyjp,.*": description: thingy.jp + "^thundercomm,.*": + description: Thundercomm Technology Co., Ltd. "^ti,.*": description: Texas Instruments "^tianma,.*": @@ -1236,6 +1256,8 @@ patternProperties: description: Truly Semiconductors Limited "^visionox,.*": description: Visionox + "^team-source-display,.*": + description: Shenzhen Team Source Display Technology Co., Ltd. (TSD) "^tsd,.*": description: Theobroma Systems Design und Consulting GmbH "^tyan,.*": @@ -1272,6 +1294,8 @@ patternProperties: description: Variscite Ltd. "^vdl,.*": description: Van der Laan b.v. + "^vertexcom,.*": + description: Vertexcom Technologies, Inc. "^via,.*": description: VIA Technologies, Inc. "^videostrong,.*": @@ -1318,6 +1342,10 @@ patternProperties: description: Wiligear, Ltd. "^winbond,.*": description: Winbond Electronics corp. + "^wingtech,.*": + description: Wingtech Technology Co., Ltd. + "^winlink,.*": + description: WinLink Co., Ltd "^winstar,.*": description: Winstar Display Corp. "^wits,.*": @@ -1352,6 +1380,8 @@ patternProperties: description: Shenzhen Xunlong Software CO.,Limited "^xylon,.*": description: Xylon + "^yadro,.*": + description: YADRO "^yamaha,.*": description: Yamaha Corporation "^yes-optoelectronics,.*": diff --git a/Documentation/devicetree/bindings/watchdog/apple,wdt.yaml b/Documentation/devicetree/bindings/watchdog/apple,wdt.yaml new file mode 100644 index 000000000000..e58c56a6fdf6 --- /dev/null +++ b/Documentation/devicetree/bindings/watchdog/apple,wdt.yaml @@ -0,0 +1,52 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/watchdog/apple,wdt.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Apple SoC Watchdog + +allOf: + - $ref: "watchdog.yaml#" + +maintainers: + - Sven Peter <sven@svenpeter.dev> + +properties: + compatible: + items: + - enum: + - apple,t8103-wdt + - apple,t6000-wdt + - const: apple,wdt + + reg: + maxItems: 1 + + clocks: + maxItems: 1 + + interrupts: + maxItems: 1 + +required: + - compatible + - reg + - clocks + - interrupts + +unevaluatedProperties: false + +examples: + - | + #include <dt-bindings/interrupt-controller/apple-aic.h> + #include <dt-bindings/interrupt-controller/irq.h> + + wdt: watchdog@50000000 { + compatible = "apple,t8103-wdt", "apple,wdt"; + reg = <0x50000000 0x4000>; + clocks = <&clk>; + interrupts = <AIC_IRQ 123 IRQ_TYPE_LEVEL_HIGH>; + }; + +... diff --git a/Documentation/devicetree/bindings/watchdog/atmel,sama5d4-wdt.yaml b/Documentation/devicetree/bindings/watchdog/atmel,sama5d4-wdt.yaml index 9856cd76c28d..a9635c03761c 100644 --- a/Documentation/devicetree/bindings/watchdog/atmel,sama5d4-wdt.yaml +++ b/Documentation/devicetree/bindings/watchdog/atmel,sama5d4-wdt.yaml @@ -22,6 +22,9 @@ properties: reg: maxItems: 1 + interrupts: + maxItems: 1 + atmel,watchdog-type: $ref: /schemas/types.yaml#/definitions/string description: should be hardware or software. diff --git a/Documentation/devicetree/bindings/watchdog/brcm,bcm7038-wdt.txt b/Documentation/devicetree/bindings/watchdog/brcm,bcm7038-wdt.txt deleted file mode 100644 index 84122270be8f..000000000000 --- a/Documentation/devicetree/bindings/watchdog/brcm,bcm7038-wdt.txt +++ /dev/null @@ -1,19 +0,0 @@ -BCM7038 Watchdog timer - -Required properties: - -- compatible : should be "brcm,bcm7038-wdt" -- reg : Specifies base physical address and size of the registers. - -Optional properties: - -- clocks: The clock running the watchdog. If no clock is found the - driver will default to 27000000 Hz. - -Example: - -watchdog@f040a7e8 { - compatible = "brcm,bcm7038-wdt"; - clocks = <&upg_fixed>; - reg = <0xf040a7e8 0x16>; -}; diff --git a/Documentation/devicetree/bindings/watchdog/brcm,bcm7038-wdt.yaml b/Documentation/devicetree/bindings/watchdog/brcm,bcm7038-wdt.yaml new file mode 100644 index 000000000000..a926809352b8 --- /dev/null +++ b/Documentation/devicetree/bindings/watchdog/brcm,bcm7038-wdt.yaml @@ -0,0 +1,43 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/watchdog/brcm,bcm7038-wdt.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: BCM63xx and BCM7038 watchdog timer + +allOf: + - $ref: "watchdog.yaml#" + +maintainers: + - Florian Fainelli <f.fainelli@gmail.com> + - Justin Chen <justinpopo6@gmail.com> + - Rafał Miłecki <rafal@milecki.pl> + +properties: + compatible: + enum: + - brcm,bcm6345-wdt + - brcm,bcm7038-wdt + + reg: + maxItems: 1 + + clocks: + maxItems: 1 + description: > + The clock running the watchdog. If no clock is found the driver will + default to 27000000 Hz. + +unevaluatedProperties: false + +required: + - reg + +examples: + - | + watchdog@f040a7e8 { + compatible = "brcm,bcm7038-wdt"; + reg = <0xf040a7e8 0x16>; + clocks = <&upg_fixed>; + }; diff --git a/Documentation/devicetree/bindings/watchdog/fsl-imx7ulp-wdt.yaml b/Documentation/devicetree/bindings/watchdog/fsl-imx7ulp-wdt.yaml index 51d6d482bbc2..fb603a20e396 100644 --- a/Documentation/devicetree/bindings/watchdog/fsl-imx7ulp-wdt.yaml +++ b/Documentation/devicetree/bindings/watchdog/fsl-imx7ulp-wdt.yaml @@ -14,8 +14,11 @@ allOf: properties: compatible: - enum: - - fsl,imx7ulp-wdt + oneOf: + - const: fsl,imx7ulp-wdt + - items: + - const: fsl,imx8ulp-wdt + - const: fsl,imx7ulp-wdt reg: maxItems: 1 diff --git a/Documentation/devicetree/bindings/watchdog/qcom-wdt.yaml b/Documentation/devicetree/bindings/watchdog/qcom-wdt.yaml index ba60bdf1fecc..16c6f82a13ca 100644 --- a/Documentation/devicetree/bindings/watchdog/qcom-wdt.yaml +++ b/Documentation/devicetree/bindings/watchdog/qcom-wdt.yaml @@ -20,7 +20,9 @@ properties: - qcom,apss-wdt-sc7280 - qcom,apss-wdt-sdm845 - qcom,apss-wdt-sdx55 + - qcom,apss-wdt-sm6350 - qcom,apss-wdt-sm8150 + - qcom,apss-wdt-sm8250 - qcom,kpss-timer - qcom,kpss-wdt - qcom,kpss-wdt-apq8064 diff --git a/Documentation/devicetree/bindings/watchdog/realtek,otto-wdt.yaml b/Documentation/devicetree/bindings/watchdog/realtek,otto-wdt.yaml new file mode 100644 index 000000000000..11b220a5e0f6 --- /dev/null +++ b/Documentation/devicetree/bindings/watchdog/realtek,otto-wdt.yaml @@ -0,0 +1,91 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/watchdog/realtek,otto-wdt.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Realtek Otto watchdog timer + +maintainers: + - Sander Vanheule <sander@svanheule.net> + +description: | + The timer has two timeout phases. Both phases have a maximum duration of 32 + prescaled clock ticks, which is ca. 43s with a bus clock of 200MHz. The + minimum duration of each phase is one tick. Each phase can trigger an + interrupt, although the phase 2 interrupt will occur with the system reset. + - Phase 1: During this phase, the WDT can be pinged to reset the timeout. + - Phase 2: Starts after phase 1 has timed out, and only serves to give the + system some time to clean up, or notify others that it's going to reset. + During this phase, pinging the WDT has no effect, and a reset is + unavoidable, unless the WDT is disabled. + +allOf: + - $ref: watchdog.yaml# + +properties: + compatible: + enum: + - realtek,rtl8380-wdt + - realtek,rtl8390-wdt + - realtek,rtl9300-wdt + + reg: + maxItems: 1 + + clocks: + maxItems: 1 + + interrupts: + items: + - description: interrupt specifier for pretimeout + - description: interrupt specifier for timeout + + interrupt-names: + items: + - const: phase1 + - const: phase2 + + realtek,reset-mode: + $ref: /schemas/types.yaml#/definitions/string + description: | + Specify how the system is reset after a timeout. Defaults to "cpu" if + left unspecified. + oneOf: + - description: Reset the entire chip + const: soc + - description: | + Reset the CPU and IPsec engine, but leave other peripherals untouched + const: cpu + - description: | + Reset the execution pointer, but don't actually reset any hardware + const: software + +required: + - compatible + - reg + - clocks + - interrupts + +unevaluatedProperties: false + +dependencies: + interrupts: [ interrupt-names ] + +examples: + - | + watchdog: watchdog@3150 { + compatible = "realtek,rtl8380-wdt"; + reg = <0x3150 0xc>; + + realtek,reset-mode = "soc"; + + clocks = <&lxbus_clock>; + timeout-sec = <20>; + + interrupt-parent = <&rtlintc>; + interrupt-names = "phase1", "phase2"; + interrupts = <19>, <18>; + }; + +... diff --git a/Documentation/devicetree/bindings/watchdog/renesas,wdt.yaml b/Documentation/devicetree/bindings/watchdog/renesas,wdt.yaml index ab66d3f0c476..91a98ccd4226 100644 --- a/Documentation/devicetree/bindings/watchdog/renesas,wdt.yaml +++ b/Documentation/devicetree/bindings/watchdog/renesas,wdt.yaml @@ -10,9 +10,6 @@ maintainers: - Wolfram Sang <wsa+renesas@sang-engineering.com> - Geert Uytterhoeven <geert+renesas@glider.be> -allOf: - - $ref: "watchdog.yaml#" - properties: compatible: oneOf: @@ -24,6 +21,11 @@ properties: - items: - enum: + - renesas,r9a07g044-wdt # RZ/G2{L,LC} + - const: renesas,rzg2l-wdt # RZ/G2L + + - items: + - enum: - renesas,r8a7742-wdt # RZ/G1H - renesas,r8a7743-wdt # RZ/G1M - renesas,r8a7744-wdt # RZ/G1N @@ -56,11 +58,13 @@ properties: reg: maxItems: 1 - interrupts: - maxItems: 1 + interrupts: true - clocks: - maxItems: 1 + interrupt-names: true + + clocks: true + + clock-names: true power-domains: maxItems: 1 @@ -75,17 +79,52 @@ required: - reg - clocks -if: - not: - properties: - compatible: - contains: - enum: - - renesas,rza-wdt -then: - required: - - power-domains - - resets +allOf: + - $ref: "watchdog.yaml#" + + - if: + not: + properties: + compatible: + contains: + enum: + - renesas,rza-wdt + then: + required: + - power-domains + - resets + + - if: + properties: + compatible: + contains: + enum: + - renesas,rzg2l-wdt + then: + properties: + interrupts: + maxItems: 2 + interrupt-names: + items: + - const: wdt + - const: perrout + clocks: + items: + - description: Register access clock + - description: Main clock + clock-names: + items: + - const: pclk + - const: oscclk + required: + - clock-names + - interrupt-names + else: + properties: + interrupts: + maxItems: 1 + clocks: + maxItems: 1 additionalProperties: false diff --git a/Documentation/devicetree/bindings/watchdog/samsung-wdt.yaml b/Documentation/devicetree/bindings/watchdog/samsung-wdt.yaml index 76cb9586ee00..b08373336b16 100644 --- a/Documentation/devicetree/bindings/watchdog/samsung-wdt.yaml +++ b/Documentation/devicetree/bindings/watchdog/samsung-wdt.yaml @@ -22,25 +22,32 @@ properties: - samsung,exynos5250-wdt # for Exynos5250 - samsung,exynos5420-wdt # for Exynos5420 - samsung,exynos7-wdt # for Exynos7 + - samsung,exynos850-wdt # for Exynos850 reg: maxItems: 1 clocks: - maxItems: 1 + minItems: 1 + maxItems: 2 clock-names: - items: - - const: watchdog + minItems: 1 + maxItems: 2 interrupts: maxItems: 1 + samsung,cluster-index: + $ref: /schemas/types.yaml#/definitions/uint32 + description: + Index of CPU cluster on which watchdog is running (in case of Exynos850) + samsung,syscon-phandle: $ref: /schemas/types.yaml#/definitions/phandle description: - Phandle to the PMU system controller node (in case of Exynos5250 - and Exynos5420). + Phandle to the PMU system controller node (in case of Exynos5250, + Exynos5420, Exynos7 and Exynos850). required: - compatible @@ -58,9 +65,40 @@ allOf: enum: - samsung,exynos5250-wdt - samsung,exynos5420-wdt + - samsung,exynos7-wdt + - samsung,exynos850-wdt then: required: - samsung,syscon-phandle + - if: + properties: + compatible: + contains: + enum: + - samsung,exynos850-wdt + then: + properties: + clocks: + items: + - description: Bus clock, used for register interface + - description: Source clock (driving watchdog counter) + clock-names: + items: + - const: watchdog + - const: watchdog_src + samsung,cluster-index: + enum: [0, 1] + required: + - samsung,cluster-index + else: + properties: + clocks: + items: + - description: Bus clock, which is also a source clock + clock-names: + items: + - const: watchdog + samsung,cluster-index: false unevaluatedProperties: false diff --git a/Documentation/devicetree/bindings/watchdog/ti,rti-wdt.yaml b/Documentation/devicetree/bindings/watchdog/ti,rti-wdt.yaml index 054584d7543a..2f33635876ff 100644 --- a/Documentation/devicetree/bindings/watchdog/ti,rti-wdt.yaml +++ b/Documentation/devicetree/bindings/watchdog/ti,rti-wdt.yaml @@ -34,12 +34,6 @@ properties: power-domains: maxItems: 1 - assigned-clocks: - maxItems: 1 - - assigned-clocks-parents: - maxItems: 1 - required: - compatible - reg diff --git a/Documentation/doc-guide/sphinx.rst b/Documentation/doc-guide/sphinx.rst index e445cb146efe..bb36f18ae9ac 100644 --- a/Documentation/doc-guide/sphinx.rst +++ b/Documentation/doc-guide/sphinx.rst @@ -138,6 +138,17 @@ To pass extra options to Sphinx, you can use the ``SPHINXOPTS`` make variable. For example, use ``make SPHINXOPTS=-v htmldocs`` to get more verbose output. +It is also possible to pass an extra DOCS_CSS overlay file, in order to customize +the html layout, by using the ``DOCS_CSS`` make variable. + +By default, the build will try to use the Read the Docs sphinx theme: + + https://github.com/readthedocs/sphinx_rtd_theme + +If the theme is not available, it will fall-back to the classic one. + +The Sphinx theme can be overridden by using the ``DOCS_THEME`` make variable. + To remove the generated documentation, run ``make cleandocs``. Writing Documentation @@ -250,12 +261,11 @@ please feel free to remove it. list tables ----------- -We recommend the use of *list table* formats. The *list table* formats are -double-stage lists. Compared to the ASCII-art they might not be as -comfortable for -readers of the text files. Their advantage is that they are easy to -create or modify and that the diff of a modification is much more meaningful, -because it is limited to the modified content. +The list-table formats can be useful for tables that are not easily laid +out in the usual Sphinx ASCII-art formats. These formats are nearly +impossible for readers of the plain-text documents to understand, though, +and should be avoided in the absence of a strong justification for their +use. The ``flat-table`` is a double-stage list similar to the ``list-table`` with some additional features: diff --git a/Documentation/driver-api/auxiliary_bus.rst b/Documentation/driver-api/auxiliary_bus.rst index ef902daf0d68..cec84908fbc0 100644 --- a/Documentation/driver-api/auxiliary_bus.rst +++ b/Documentation/driver-api/auxiliary_bus.rst @@ -6,231 +6,45 @@ Auxiliary Bus ============= -In some subsystems, the functionality of the core device (PCI/ACPI/other) is -too complex for a single device to be managed by a monolithic driver -(e.g. Sound Open Firmware), multiple devices might implement a common -intersection of functionality (e.g. NICs + RDMA), or a driver may want to -export an interface for another subsystem to drive (e.g. SIOV Physical Function -export Virtual Function management). A split of the functionality into child- -devices representing sub-domains of functionality makes it possible to -compartmentalize, layer, and distribute domain-specific concerns via a Linux -device-driver model. - -An example for this kind of requirement is the audio subsystem where a single -IP is handling multiple entities such as HDMI, Soundwire, local devices such as -mics/speakers etc. The split for the core's functionality can be arbitrary or -be defined by the DSP firmware topology and include hooks for test/debug. This -allows for the audio core device to be minimal and focused on hardware-specific -control and communication. - -Each auxiliary_device represents a part of its parent functionality. The -generic behavior can be extended and specialized as needed by encapsulating an -auxiliary_device within other domain-specific structures and the use of .ops -callbacks. Devices on the auxiliary bus do not share any structures and the use -of a communication channel with the parent is domain-specific. - -Note that ops are intended as a way to augment instance behavior within a class -of auxiliary devices, it is not the mechanism for exporting common -infrastructure from the parent. Consider EXPORT_SYMBOL_NS() to convey -infrastructure from the parent module to the auxiliary module(s). - +.. kernel-doc:: drivers/base/auxiliary.c + :doc: PURPOSE When Should the Auxiliary Bus Be Used ===================================== -The auxiliary bus is to be used when a driver and one or more kernel modules, -who share a common header file with the driver, need a mechanism to connect and -provide access to a shared object allocated by the auxiliary_device's -registering driver. The registering driver for the auxiliary_device(s) and the -kernel module(s) registering auxiliary_drivers can be from the same subsystem, -or from multiple subsystems. - -The emphasis here is on a common generic interface that keeps subsystem -customization out of the bus infrastructure. - -One example is a PCI network device that is RDMA-capable and exports a child -device to be driven by an auxiliary_driver in the RDMA subsystem. The PCI -driver allocates and registers an auxiliary_device for each physical -function on the NIC. The RDMA driver registers an auxiliary_driver that claims -each of these auxiliary_devices. This conveys data/ops published by the parent -PCI device/driver to the RDMA auxiliary_driver. - -Another use case is for the PCI device to be split out into multiple sub -functions. For each sub function an auxiliary_device is created. A PCI sub -function driver binds to such devices that creates its own one or more class -devices. A PCI sub function auxiliary device is likely to be contained in a -struct with additional attributes such as user defined sub function number and -optional attributes such as resources and a link to the parent device. These -attributes could be used by systemd/udev; and hence should be initialized -before a driver binds to an auxiliary_device. - -A key requirement for utilizing the auxiliary bus is that there is no -dependency on a physical bus, device, register accesses or regmap support. -These individual devices split from the core cannot live on the platform bus as -they are not physical devices that are controlled by DT/ACPI. The same -argument applies for not using MFD in this scenario as MFD relies on individual -function devices being physical devices. - -Auxiliary Device -================ - -An auxiliary_device represents a part of its parent device's functionality. It -is given a name that, combined with the registering drivers KBUILD_MODNAME, -creates a match_name that is used for driver binding, and an id that combined -with the match_name provide a unique name to register with the bus subsystem. - -Registering an auxiliary_device is a two-step process. First call -auxiliary_device_init(), which checks several aspects of the auxiliary_device -struct and performs a device_initialize(). After this step completes, any -error state must have a call to auxiliary_device_uninit() in its resolution path. -The second step in registering an auxiliary_device is to perform a call to -auxiliary_device_add(), which sets the name of the device and add the device to -the bus. - -Unregistering an auxiliary_device is also a two-step process to mirror the -register process. First call auxiliary_device_delete(), then call -auxiliary_device_uninit(). - -.. code-block:: c - - struct auxiliary_device { - struct device dev; - const char *name; - u32 id; - }; - -If two auxiliary_devices both with a match_name "mod.foo" are registered onto -the bus, they must have unique id values (e.g. "x" and "y") so that the -registered devices names are "mod.foo.x" and "mod.foo.y". If match_name + id -are not unique, then the device_add fails and generates an error message. - -The auxiliary_device.dev.type.release or auxiliary_device.dev.release must be -populated with a non-NULL pointer to successfully register the auxiliary_device. - -The auxiliary_device.dev.parent must also be populated. +.. kernel-doc:: drivers/base/auxiliary.c + :doc: USAGE + + +Auxiliary Device Creation +========================= + +.. kernel-doc:: include/linux/auxiliary_bus.h + :identifiers: auxiliary_device + +.. kernel-doc:: drivers/base/auxiliary.c + :identifiers: auxiliary_device_init __auxiliary_device_add + auxiliary_find_device Auxiliary Device Memory Model and Lifespan ------------------------------------------ -The registering driver is the entity that allocates memory for the -auxiliary_device and register it on the auxiliary bus. It is important to note -that, as opposed to the platform bus, the registering driver is wholly -responsible for the management for the memory used for the driver object. - -A parent object, defined in the shared header file, contains the -auxiliary_device. It also contains a pointer to the shared object(s), which -also is defined in the shared header. Both the parent object and the shared -object(s) are allocated by the registering driver. This layout allows the -auxiliary_driver's registering module to perform a container_of() call to go -from the pointer to the auxiliary_device, that is passed during the call to the -auxiliary_driver's probe function, up to the parent object, and then have -access to the shared object(s). - -The memory for the auxiliary_device is freed only in its release() callback -flow as defined by its registering driver. - -The memory for the shared object(s) must have a lifespan equal to, or greater -than, the lifespan of the memory for the auxiliary_device. The auxiliary_driver -should only consider that this shared object is valid as long as the -auxiliary_device is still registered on the auxiliary bus. It is up to the -registering driver to manage (e.g. free or keep available) the memory for the -shared object beyond the life of the auxiliary_device. - -The registering driver must unregister all auxiliary devices before its own -driver.remove() is completed. +.. kernel-doc:: include/linux/auxiliary_bus.h + :doc: DEVICE_LIFESPAN + Auxiliary Drivers ================= -Auxiliary drivers follow the standard driver model convention, where -discovery/enumeration is handled by the core, and drivers -provide probe() and remove() methods. They support power management -and shutdown notifications using the standard conventions. - -.. code-block:: c +.. kernel-doc:: include/linux/auxiliary_bus.h + :identifiers: auxiliary_driver module_auxiliary_driver - struct auxiliary_driver { - int (*probe)(struct auxiliary_device *, - const struct auxiliary_device_id *id); - void (*remove)(struct auxiliary_device *); - void (*shutdown)(struct auxiliary_device *); - int (*suspend)(struct auxiliary_device *, pm_message_t); - int (*resume)(struct auxiliary_device *); - struct device_driver driver; - const struct auxiliary_device_id *id_table; - }; - -Auxiliary drivers register themselves with the bus by calling -auxiliary_driver_register(). The id_table contains the match_names of auxiliary -devices that a driver can bind with. +.. kernel-doc:: drivers/base/auxiliary.c + :identifiers: __auxiliary_driver_register auxiliary_driver_unregister Example Usage ============= -Auxiliary devices are created and registered by a subsystem-level core device -that needs to break up its functionality into smaller fragments. One way to -extend the scope of an auxiliary_device is to encapsulate it within a domain- -pecific structure defined by the parent device. This structure contains the -auxiliary_device and any associated shared data/callbacks needed to establish -the connection with the parent. - -An example is: - -.. code-block:: c - - struct foo { - struct auxiliary_device auxdev; - void (*connect)(struct auxiliary_device *auxdev); - void (*disconnect)(struct auxiliary_device *auxdev); - void *data; - }; - -The parent device then registers the auxiliary_device by calling -auxiliary_device_init(), and then auxiliary_device_add(), with the pointer to -the auxdev member of the above structure. The parent provides a name for the -auxiliary_device that, combined with the parent's KBUILD_MODNAME, creates a -match_name that is be used for matching and binding with a driver. - -Whenever an auxiliary_driver is registered, based on the match_name, the -auxiliary_driver's probe() is invoked for the matching devices. The -auxiliary_driver can also be encapsulated inside custom drivers that make the -core device's functionality extensible by adding additional domain-specific ops -as follows: - -.. code-block:: c - - struct my_ops { - void (*send)(struct auxiliary_device *auxdev); - void (*receive)(struct auxiliary_device *auxdev); - }; - - - struct my_driver { - struct auxiliary_driver auxiliary_drv; - const struct my_ops ops; - }; - -An example of this type of usage is: - -.. code-block:: c - - const struct auxiliary_device_id my_auxiliary_id_table[] = { - { .name = "foo_mod.foo_dev" }, - { }, - }; - - const struct my_ops my_custom_ops = { - .send = my_tx, - .receive = my_rx, - }; - - const struct my_driver my_drv = { - .auxiliary_drv = { - .name = "myauxiliarydrv", - .id_table = my_auxiliary_id_table, - .probe = my_probe, - .remove = my_remove, - .shutdown = my_shutdown, - }, - .ops = my_custom_ops, - }; +.. kernel-doc:: drivers/base/auxiliary.c + :doc: EXAMPLE + diff --git a/Documentation/driver-api/dmaengine/dmatest.rst b/Documentation/driver-api/dmaengine/dmatest.rst index ee268d445d38..cf9859cd0b43 100644 --- a/Documentation/driver-api/dmaengine/dmatest.rst +++ b/Documentation/driver-api/dmaengine/dmatest.rst @@ -6,6 +6,16 @@ Andy Shevchenko <andriy.shevchenko@linux.intel.com> This small document introduces how to test DMA drivers using dmatest module. +The dmatest module tests DMA memcpy, memset, XOR and RAID6 P+Q operations using +various lengths and various offsets into the source and destination buffers. It +will initialize both buffers with a repeatable pattern and verify that the DMA +engine copies the requested region and nothing more. It will also verify that +the bytes aren't swapped around, and that the source buffer isn't modified. + +The dmatest module can be configured to test a specific channel. It can also +test multiple channels at the same time, and it can start multiple threads +competing for the same channel. + .. note:: The test suite works only on the channels that have at least one capability of the following: DMA_MEMCPY (memory-to-memory), DMA_MEMSET @@ -143,13 +153,14 @@ Part 5 - Handling channel allocation Allocating Channels ------------------- -Channels are required to be configured prior to starting the test run. -Attempting to run the test without configuring the channels will fail. +Channels do not need to be configured prior to starting a test run. Attempting +to run the test without configuring the channels will result in testing any +channels that are available. Example:: % echo 1 > /sys/module/dmatest/parameters/run - dmatest: Could not start test, no channels configured + dmatest: No channels configured, continue with any Channels are registered using the "channel" parameter. Channels can be requested by their name, once requested, the channel is registered and a pending thread is added to the test list. diff --git a/Documentation/driver-api/dmaengine/provider.rst b/Documentation/driver-api/dmaengine/provider.rst index ddb0a81a796c..0072c9c7efd3 100644 --- a/Documentation/driver-api/dmaengine/provider.rst +++ b/Documentation/driver-api/dmaengine/provider.rst @@ -162,6 +162,29 @@ Currently, the types available are: - The device is able to do memory to memory copies +- - DMA_MEMCPY_SG + + - The device supports memory to memory scatter-gather transfers. + + - Even though a plain memcpy can look like a particular case of a + scatter-gather transfer, with a single chunk to copy, it's a distinct + transaction type in the mem2mem transfer case. This is because some very + simple devices might be able to do contiguous single-chunk memory copies, + but have no support for more complex SG transfers. + + - No matter what the overall size of the combined chunks for source and + destination is, only as many bytes as the smallest of the two will be + transmitted. That means the number and size of the scatter-gather buffers in + both lists need not be the same, and that the operation functionally is + equivalent to a ``strncpy`` where the ``count`` argument equals the smallest + total size of the two scatter-gather list buffers. + + - It's usually used for copying pixel data between host memory and + memory-mapped GPU device memory, such as found on modern PCI video graphics + cards. The most immediate example is the OpenGL API function + ``glReadPielx()``, which might require a verbatim copy of a huge framebuffer + from local device memory onto host memory. + - DMA_XOR - The device is able to perform XOR operations on memory areas diff --git a/Documentation/driver-api/firewire.rst b/Documentation/driver-api/firewire.rst index 94a2d7f01d99..d3cfa73cbb2b 100644 --- a/Documentation/driver-api/firewire.rst +++ b/Documentation/driver-api/firewire.rst @@ -19,7 +19,7 @@ of kernel interfaces is available via exported symbols in `firewire-core` module Firewire char device data structures ==================================== -.. include:: /ABI/stable/firewire-cdev +.. include:: ../ABI/stable/firewire-cdev :literal: .. kernel-doc:: include/uapi/linux/firewire-cdev.h @@ -28,7 +28,7 @@ Firewire char device data structures Firewire device probing and sysfs interfaces ============================================ -.. include:: /ABI/stable/sysfs-bus-firewire +.. include:: ../ABI/stable/sysfs-bus-firewire :literal: .. kernel-doc:: drivers/firewire/core-device.c diff --git a/Documentation/driver-api/fpga/fpga-bridge.rst b/Documentation/driver-api/fpga/fpga-bridge.rst index 8d650b4e2ce6..604208534095 100644 --- a/Documentation/driver-api/fpga/fpga-bridge.rst +++ b/Documentation/driver-api/fpga/fpga-bridge.rst @@ -6,8 +6,7 @@ API to implement a new FPGA bridge * struct fpga_bridge - The FPGA Bridge structure * struct fpga_bridge_ops - Low level Bridge driver ops -* devm_fpga_bridge_create() - Allocate and init a bridge struct -* fpga_bridge_register() - Register a bridge +* fpga_bridge_register() - Create and register a bridge * fpga_bridge_unregister() - Unregister a bridge .. kernel-doc:: include/linux/fpga/fpga-bridge.h @@ -17,9 +16,6 @@ API to implement a new FPGA bridge :functions: fpga_bridge_ops .. kernel-doc:: drivers/fpga/fpga-bridge.c - :functions: devm_fpga_bridge_create - -.. kernel-doc:: drivers/fpga/fpga-bridge.c :functions: fpga_bridge_register .. kernel-doc:: drivers/fpga/fpga-bridge.c diff --git a/Documentation/driver-api/fpga/fpga-mgr.rst b/Documentation/driver-api/fpga/fpga-mgr.rst index 4d926b452cb3..42c01f396dce 100644 --- a/Documentation/driver-api/fpga/fpga-mgr.rst +++ b/Documentation/driver-api/fpga/fpga-mgr.rst @@ -24,7 +24,7 @@ How to support a new FPGA device -------------------------------- To add another FPGA manager, write a driver that implements a set of ops. The -probe function calls fpga_mgr_register(), such as:: +probe function calls fpga_mgr_register() or fpga_mgr_register_full(), such as:: static const struct fpga_manager_ops socfpga_fpga_ops = { .write_init = socfpga_fpga_ops_configure_init, @@ -49,14 +49,14 @@ probe function calls fpga_mgr_register(), such as:: * them in priv */ - mgr = devm_fpga_mgr_create(dev, "Altera SOCFPGA FPGA Manager", - &socfpga_fpga_ops, priv); - if (!mgr) - return -ENOMEM; + mgr = fpga_mgr_register(dev, "Altera SOCFPGA FPGA Manager", + &socfpga_fpga_ops, priv); + if (IS_ERR(mgr)) + return PTR_ERR(mgr); platform_set_drvdata(pdev, mgr); - return fpga_mgr_register(mgr); + return 0; } static int socfpga_fpga_remove(struct platform_device *pdev) @@ -68,6 +68,11 @@ probe function calls fpga_mgr_register(), such as:: return 0; } +Alternatively, the probe function could call one of the resource managed +register functions, devm_fpga_mgr_register() or devm_fpga_mgr_register_full(). +When these functions are used, the parameter syntax is the same, but the call +to fpga_mgr_unregister() should be removed. In the above example, the +socfpga_fpga_remove() function would not be required. The ops will implement whatever device specific register writes are needed to do the programming sequence for this particular FPGA. These ops return 0 for @@ -104,8 +109,14 @@ API for implementing a new FPGA Manager driver * ``fpga_mgr_states`` - Values for :c:expr:`fpga_manager->state`. * struct fpga_manager - the FPGA manager struct * struct fpga_manager_ops - Low level FPGA manager driver ops -* devm_fpga_mgr_create() - Allocate and init a manager struct -* fpga_mgr_register() - Register an FPGA manager +* struct fpga_manager_info - Parameter structure for fpga_mgr_register_full() +* fpga_mgr_register_full() - Create and register an FPGA manager using the + fpga_mgr_info structure to provide the full flexibility of options +* fpga_mgr_register() - Create and register an FPGA manager using standard + arguments +* devm_fpga_mgr_register_full() - Resource managed version of + fpga_mgr_register_full() +* devm_fpga_mgr_register() - Resource managed version of fpga_mgr_register() * fpga_mgr_unregister() - Unregister an FPGA manager .. kernel-doc:: include/linux/fpga/fpga-mgr.h @@ -117,11 +128,20 @@ API for implementing a new FPGA Manager driver .. kernel-doc:: include/linux/fpga/fpga-mgr.h :functions: fpga_manager_ops +.. kernel-doc:: include/linux/fpga/fpga-mgr.h + :functions: fpga_manager_info + .. kernel-doc:: drivers/fpga/fpga-mgr.c - :functions: devm_fpga_mgr_create + :functions: fpga_mgr_register_full .. kernel-doc:: drivers/fpga/fpga-mgr.c :functions: fpga_mgr_register .. kernel-doc:: drivers/fpga/fpga-mgr.c + :functions: devm_fpga_mgr_register_full + +.. kernel-doc:: drivers/fpga/fpga-mgr.c + :functions: devm_fpga_mgr_register + +.. kernel-doc:: drivers/fpga/fpga-mgr.c :functions: fpga_mgr_unregister diff --git a/Documentation/driver-api/fpga/fpga-region.rst b/Documentation/driver-api/fpga/fpga-region.rst index 2636a27c11b2..dc55d60a0b4a 100644 --- a/Documentation/driver-api/fpga/fpga-region.rst +++ b/Documentation/driver-api/fpga/fpga-region.rst @@ -46,8 +46,11 @@ API to add a new FPGA region ---------------------------- * struct fpga_region - The FPGA region struct -* devm_fpga_region_create() - Allocate and init a region struct -* fpga_region_register() - Register an FPGA region +* struct fpga_region_info - Parameter structure for fpga_region_register_full() +* fpga_region_register_full() - Create and register an FPGA region using the + fpga_region_info structure to provide the full flexibility of options +* fpga_region_register() - Create and register an FPGA region using standard + arguments * fpga_region_unregister() - Unregister an FPGA region The FPGA region's probe function will need to get a reference to the FPGA @@ -75,8 +78,11 @@ following APIs to handle building or tearing down that list. .. kernel-doc:: include/linux/fpga/fpga-region.h :functions: fpga_region +.. kernel-doc:: include/linux/fpga/fpga-region.h + :functions: fpga_region_info + .. kernel-doc:: drivers/fpga/fpga-region.c - :functions: devm_fpga_region_create + :functions: fpga_region_register_full .. kernel-doc:: drivers/fpga/fpga-region.c :functions: fpga_region_register diff --git a/Documentation/driver-api/generic-counter.rst b/Documentation/driver-api/generic-counter.rst index 1b487a331467..71ccc30e586b 100644 --- a/Documentation/driver-api/generic-counter.rst +++ b/Documentation/driver-api/generic-counter.rst @@ -262,11 +262,11 @@ order to communicate with the device: to read and write various Signals and Counts, and to set and get the "action mode" and "function mode" for various Synapses and Counts respectively. -A defined counter_device structure may be registered to the system by -passing it to the counter_register function, and unregistered by passing -it to the counter_unregister function. Similarly, the -devm_counter_register function may be used if device memory-managed -registration is desired. +A counter_device structure is allocated using counter_alloc() and then +registered to the system by passing it to the counter_add() function, and +unregistered by passing it to the counter_unregister function. There are +device managed variants of these functions: devm_counter_alloc() and +devm_counter_add(). The struct counter_comp structure is used to define counter extensions for Signals, Synapses, and Counts. diff --git a/Documentation/driver-api/media/drivers/index.rst b/Documentation/driver-api/media/drivers/index.rst index 426cda633bf0..32406490557c 100644 --- a/Documentation/driver-api/media/drivers/index.rst +++ b/Documentation/driver-api/media/drivers/index.rst @@ -21,6 +21,7 @@ Video4Linux (V4L) drivers pvrusb2 pxa_camera radiotrack + rkisp1 saa7134-devel sh_mobile_ceu_camera tuners diff --git a/Documentation/driver-api/pci/pci.rst b/Documentation/driver-api/pci/pci.rst index ca85e5e78b2c..4843cfad4f60 100644 --- a/Documentation/driver-api/pci/pci.rst +++ b/Documentation/driver-api/pci/pci.rst @@ -13,7 +13,7 @@ PCI Support Library .. kernel-doc:: drivers/pci/search.c :export: -.. kernel-doc:: drivers/pci/msi.c +.. kernel-doc:: drivers/pci/msi/msi.c :export: .. kernel-doc:: drivers/pci/bus.c diff --git a/Documentation/driver-api/serial/index.rst b/Documentation/driver-api/serial/index.rst index 8f7d7af3b90b..7eb21a695fc3 100644 --- a/Documentation/driver-api/serial/index.rst +++ b/Documentation/driver-api/serial/index.rst @@ -9,7 +9,6 @@ Support for Serial devices driver - tty Serial drivers ============== diff --git a/Documentation/driver-api/serial/n_gsm.rst b/Documentation/driver-api/serial/n_gsm.rst index 8fe723ab9c67..49956509ad73 100644 --- a/Documentation/driver-api/serial/n_gsm.rst +++ b/Documentation/driver-api/serial/n_gsm.rst @@ -18,9 +18,12 @@ How to use it 1.1 initialize the modem in 0710 mux mode (usually AT+CMUX= command) through its serial port. Depending on the modem used, you can pass more or less parameters to this command. + 1.2 switch the serial line to using the n_gsm line discipline by using TIOCSETD ioctl. + 1.3 configure the mux using GSMIOC_GETCONF / GSMIOC_SETCONF ioctl. + 1.4 obtain base gsmtty number for the used serial port. Major parts of the initialization program : @@ -95,10 +98,13 @@ Major parts of the initialization program : 2.1 receive string "AT+CMUX= command" through its serial port,initialize mux mode config + 2.2 switch the serial line to using the n_gsm line discipline by using TIOCSETD ioctl. + 2.3 configure the mux using GSMIOC_GETCONF / GSMIOC_SETCONF ioctl. -2.4 obtain base gsmtty number for the used serial port, + +2.4 obtain base gsmtty number for the used serial port:: #include <stdio.h> #include <stdint.h> diff --git a/Documentation/driver-api/serial/tty.rst b/Documentation/driver-api/serial/tty.rst deleted file mode 100644 index 4b709f392713..000000000000 --- a/Documentation/driver-api/serial/tty.rst +++ /dev/null @@ -1,328 +0,0 @@ -================= -The Lockronomicon -================= - -Your guide to the ancient and twisted locking policies of the tty layer and -the warped logic behind them. Beware all ye who read on. - - -Line Discipline ---------------- - -Line disciplines are registered with tty_register_ldisc() passing the -discipline number and the ldisc structure. At the point of registration the -discipline must be ready to use and it is possible it will get used before -the call returns success. If the call returns an error then it won't get -called. Do not re-use ldisc numbers as they are part of the userspace ABI -and writing over an existing ldisc will cause demons to eat your computer. -After the return the ldisc data has been copied so you may free your own -copy of the structure. You must not re-register over the top of the line -discipline even with the same data or your computer again will be eaten by -demons. - -In order to remove a line discipline call tty_unregister_ldisc(). -In ancient times this always worked. In modern times the function will -return -EBUSY if the ldisc is currently in use. Since the ldisc referencing -code manages the module counts this should not usually be a concern. - -Heed this warning: the reference count field of the registered copies of the -tty_ldisc structure in the ldisc table counts the number of lines using this -discipline. The reference count of the tty_ldisc structure within a tty -counts the number of active users of the ldisc at this instant. In effect it -counts the number of threads of execution within an ldisc method (plus those -about to enter and exit although this detail matters not). - -Line Discipline Methods ------------------------ - -TTY side interfaces -^^^^^^^^^^^^^^^^^^^ - -======================= ======================================================= -open() Called when the line discipline is attached to - the terminal. No other call into the line - discipline for this tty will occur until it - completes successfully. Should initialize any - state needed by the ldisc, and set receive_room - in the tty_struct to the maximum amount of data - the line discipline is willing to accept from the - driver with a single call to receive_buf(). - Returning an error will prevent the ldisc from - being attached. Can sleep. - -close() This is called on a terminal when the line - discipline is being unplugged. At the point of - execution no further users will enter the - ldisc code for this tty. Can sleep. - -hangup() Called when the tty line is hung up. - The line discipline should cease I/O to the tty. - No further calls into the ldisc code will occur. - Can sleep. - -read() (optional) A process requests reading data from - the line. Multiple read calls may occur in parallel - and the ldisc must deal with serialization issues. - If not defined, the process will receive an EIO - error. May sleep. - -write() (optional) A process requests writing data to the - line. Multiple write calls are serialized by the - tty layer for the ldisc. If not defined, the - process will receive an EIO error. May sleep. - -flush_buffer() (optional) May be called at any point between - open and close, and instructs the line discipline - to empty its input buffer. - -set_termios() (optional) Called on termios structure changes. - The caller passes the old termios data and the - current data is in the tty. Called under the - termios semaphore so allowed to sleep. Serialized - against itself only. - -poll() (optional) Check the status for the poll/select - calls. Multiple poll calls may occur in parallel. - May sleep. - -ioctl() (optional) Called when an ioctl is handed to the - tty layer that might be for the ldisc. Multiple - ioctl calls may occur in parallel. May sleep. - -compat_ioctl() (optional) Called when a 32 bit ioctl is handed - to the tty layer that might be for the ldisc. - Multiple ioctl calls may occur in parallel. - May sleep. -======================= ======================================================= - -Driver Side Interfaces -^^^^^^^^^^^^^^^^^^^^^^ - -======================= ======================================================= -receive_buf() (optional) Called by the low-level driver to hand - a buffer of received bytes to the ldisc for - processing. The number of bytes is guaranteed not - to exceed the current value of tty->receive_room. - All bytes must be processed. - -receive_buf2() (optional) Called by the low-level driver to hand - a buffer of received bytes to the ldisc for - processing. Returns the number of bytes processed. - - If both receive_buf() and receive_buf2() are - defined, receive_buf2() should be preferred. - -write_wakeup() May be called at any point between open and close. - The TTY_DO_WRITE_WAKEUP flag indicates if a call - is needed but always races versus calls. Thus the - ldisc must be careful about setting order and to - handle unexpected calls. Must not sleep. - - The driver is forbidden from calling this directly - from the ->write call from the ldisc as the ldisc - is permitted to call the driver write method from - this function. In such a situation defer it. - -dcd_change() Report to the tty line the current DCD pin status - changes and the relative timestamp. The timestamp - cannot be NULL. -======================= ======================================================= - - -Driver Access -^^^^^^^^^^^^^ - -Line discipline methods can call the following methods of the underlying -hardware driver through the function pointers within the tty->driver -structure: - -======================= ======================================================= -write() Write a block of characters to the tty device. - Returns the number of characters accepted. The - character buffer passed to this method is already - in kernel space. - -put_char() Queues a character for writing to the tty device. - If there is no room in the queue, the character is - ignored. - -flush_chars() (Optional) If defined, must be called after - queueing characters with put_char() in order to - start transmission. - -write_room() Returns the numbers of characters the tty driver - will accept for queueing to be written. - -ioctl() Invoke device specific ioctl. - Expects data pointers to refer to userspace. - Returns ENOIOCTLCMD for unrecognized ioctl numbers. - -set_termios() Notify the tty driver that the device's termios - settings have changed. New settings are in - tty->termios. Previous settings should be passed in - the "old" argument. - - The API is defined such that the driver should return - the actual modes selected. This means that the - driver function is responsible for modifying any - bits in the request it cannot fulfill to indicate - the actual modes being used. A device with no - hardware capability for change (e.g. a USB dongle or - virtual port) can provide NULL for this method. - -throttle() Notify the tty driver that input buffers for the - line discipline are close to full, and it should - somehow signal that no more characters should be - sent to the tty. - -unthrottle() Notify the tty driver that characters can now be - sent to the tty without fear of overrunning the - input buffers of the line disciplines. - -stop() Ask the tty driver to stop outputting characters - to the tty device. - -start() Ask the tty driver to resume sending characters - to the tty device. - -hangup() Ask the tty driver to hang up the tty device. - -break_ctl() (Optional) Ask the tty driver to turn on or off - BREAK status on the RS-232 port. If state is -1, - then the BREAK status should be turned on; if - state is 0, then BREAK should be turned off. - If this routine is not implemented, use ioctls - TIOCSBRK / TIOCCBRK instead. - -wait_until_sent() Waits until the device has written out all of the - characters in its transmitter FIFO. - -send_xchar() Send a high-priority XON/XOFF character to the device. -======================= ======================================================= - - -Flags -^^^^^ - -Line discipline methods have access to tty->flags field containing the -following interesting flags: - -======================= ======================================================= -TTY_THROTTLED Driver input is throttled. The ldisc should call - tty->driver->unthrottle() in order to resume - reception when it is ready to process more data. - -TTY_DO_WRITE_WAKEUP If set, causes the driver to call the ldisc's - write_wakeup() method in order to resume - transmission when it can accept more data - to transmit. - -TTY_IO_ERROR If set, causes all subsequent userspace read/write - calls on the tty to fail, returning -EIO. - -TTY_OTHER_CLOSED Device is a pty and the other side has closed. - -TTY_NO_WRITE_SPLIT Prevent driver from splitting up writes into - smaller chunks. -======================= ======================================================= - - -Locking -^^^^^^^ - -Callers to the line discipline functions from the tty layer are required to -take line discipline locks. The same is true of calls from the driver side -but not yet enforced. - -Three calls are now provided:: - - ldisc = tty_ldisc_ref(tty); - -takes a handle to the line discipline in the tty and returns it. If no ldisc -is currently attached or the ldisc is being closed and re-opened at this -point then NULL is returned. While this handle is held the ldisc will not -change or go away:: - - tty_ldisc_deref(ldisc) - -Returns the ldisc reference and allows the ldisc to be closed. Returning the -reference takes away your right to call the ldisc functions until you take -a new reference:: - - ldisc = tty_ldisc_ref_wait(tty); - -Performs the same function as tty_ldisc_ref except that it will wait for an -ldisc change to complete and then return a reference to the new ldisc. - -While these functions are slightly slower than the old code they should have -minimal impact as most receive logic uses the flip buffers and they only -need to take a reference when they push bits up through the driver. - -A caution: The ldisc->open(), ldisc->close() and driver->set_ldisc -functions are called with the ldisc unavailable. Thus tty_ldisc_ref will -fail in this situation if used within these functions. Ldisc and driver -code calling its own functions must be careful in this case. - - -Driver Interface ----------------- - -======================= ======================================================= -open() Called when a device is opened. May sleep - -close() Called when a device is closed. At the point of - return from this call the driver must make no - further ldisc calls of any kind. May sleep - -write() Called to write bytes to the device. May not - sleep. May occur in parallel in special cases. - Because this includes panic paths drivers generally - shouldn't try and do clever locking here. - -put_char() Stuff a single character onto the queue. The - driver is guaranteed following up calls to - flush_chars. - -flush_chars() Ask the kernel to write put_char queue - -write_room() Return the number of characters that can be stuffed - into the port buffers without overflow (or less). - The ldisc is responsible for being intelligent - about multi-threading of write_room/write calls - -ioctl() Called when an ioctl may be for the driver - -set_termios() Called on termios change, serialized against - itself by a semaphore. May sleep. - -set_ldisc() Notifier for discipline change. At the point this - is done the discipline is not yet usable. Can now - sleep (I think) - -throttle() Called by the ldisc to ask the driver to do flow - control. Serialization including with unthrottle - is the job of the ldisc layer. - -unthrottle() Called by the ldisc to ask the driver to stop flow - control. - -stop() Ldisc notifier to the driver to stop output. As with - throttle the serializations with start() are down - to the ldisc layer. - -start() Ldisc notifier to the driver to start output. - -hangup() Ask the tty driver to cause a hangup initiated - from the host side. [Can sleep ??] - -break_ctl() Send RS232 break. Can sleep. Can get called in - parallel, driver must serialize (for now), and - with write calls. - -wait_until_sent() Wait for characters to exit the hardware queue - of the driver. Can sleep - -send_xchar() Send XON/XOFF and if possible jump the queue with - it in order to get fast flow control responses. - Cannot sleep ?? -======================= ======================================================= diff --git a/Documentation/driver-api/usb/writing_usb_driver.rst b/Documentation/driver-api/usb/writing_usb_driver.rst index b43e1ce49f0e..95c4f5d14052 100644 --- a/Documentation/driver-api/usb/writing_usb_driver.rst +++ b/Documentation/driver-api/usb/writing_usb_driver.rst @@ -94,8 +94,8 @@ usually in the driver's init function, as shown here:: /* register this driver with the USB subsystem */ result = usb_register(&skel_driver); if (result < 0) { - err("usb_register failed for the "__FILE__ "driver." - "Error number %d", result); + pr_err("usb_register failed for the %s driver. Error number %d\n", + skel_driver.name, result); return -1; } @@ -170,8 +170,8 @@ structure. This is done so that future calls to file operations will enable the driver to determine which device the user is addressing. All of this is done with the following code:: - /* increment our usage count for the module */ - ++skel->open_count; + /* increment our usage count for the device */ + kref_get(&dev->kref); /* save our object in the file's private structure */ file->private_data = dev; @@ -188,24 +188,26 @@ space, points the urb to the data and submits the urb to the USB subsystem. This can be seen in the following code:: /* we can only write as much as 1 urb will hold */ - bytes_written = (count > skel->bulk_out_size) ? skel->bulk_out_size : count; + size_t writesize = min_t(size_t, count, MAX_TRANSFER); /* copy the data from user space into our urb */ - copy_from_user(skel->write_urb->transfer_buffer, buffer, bytes_written); + copy_from_user(buf, user_buffer, writesize); /* set up our urb */ - usb_fill_bulk_urb(skel->write_urb, - skel->dev, - usb_sndbulkpipe(skel->dev, skel->bulk_out_endpointAddr), - skel->write_urb->transfer_buffer, - bytes_written, + usb_fill_bulk_urb(urb, + dev->udev, + usb_sndbulkpipe(dev->udev, dev->bulk_out_endpointAddr), + buf, + writesize, skel_write_bulk_callback, - skel); + dev); /* send the data out the bulk port */ - result = usb_submit_urb(skel->write_urb); - if (result) { - err("Failed submitting write urb, error %d", result); + retval = usb_submit_urb(urb, GFP_KERNEL); + if (retval) { + dev_err(&dev->interface->dev, + "%s - failed submitting write urb, error %d\n", + __func__, retval); } diff --git a/Documentation/features/core/thread-info-in-task/arch-support.txt b/Documentation/features/core/thread-info-in-task/arch-support.txt index 3361e86b0958..bc74d8beea72 100644 --- a/Documentation/features/core/thread-info-in-task/arch-support.txt +++ b/Documentation/features/core/thread-info-in-task/arch-support.txt @@ -8,7 +8,7 @@ ----------------------- | alpha: | TODO | | arc: | TODO | - | arm: | TODO | + | arm: | ok | | arm64: | ok | | csky: | TODO | | h8300: | TODO | diff --git a/Documentation/filesystems/caching/backend-api.rst b/Documentation/filesystems/caching/backend-api.rst index 19fbf6b9aa36..be793c49a772 100644 --- a/Documentation/filesystems/caching/backend-api.rst +++ b/Documentation/filesystems/caching/backend-api.rst @@ -1,727 +1,479 @@ .. SPDX-License-Identifier: GPL-2.0 -========================== -FS-Cache Cache backend API -========================== +================= +Cache Backend API +================= The FS-Cache system provides an API by which actual caches can be supplied to FS-Cache for it to then serve out to network filesystems and other interested -parties. +parties. This API is used by:: -This API is declared in <linux/fscache-cache.h>. + #include <linux/fscache-cache.h>. -Initialising and Registering a Cache -==================================== - -To start off, a cache definition must be initialised and registered for each -cache the backend wants to make available. For instance, CacheFS does this in -the fill_super() operation on mounting. - -The cache definition (struct fscache_cache) should be initialised by calling:: - - void fscache_init_cache(struct fscache_cache *cache, - struct fscache_cache_ops *ops, - const char *idfmt, - ...); - -Where: - - * "cache" is a pointer to the cache definition; - - * "ops" is a pointer to the table of operations that the backend supports on - this cache; and - - * "idfmt" is a format and printf-style arguments for constructing a label - for the cache. - - -The cache should then be registered with FS-Cache by passing a pointer to the -previously initialised cache definition to:: - - int fscache_add_cache(struct fscache_cache *cache, - struct fscache_object *fsdef, - const char *tagname); - -Two extra arguments should also be supplied: - - * "fsdef" which should point to the object representation for the FS-Cache - master index in this cache. Netfs primary index entries will be created - here. FS-Cache keeps the caller's reference to the index object if - successful and will release it upon withdrawal of the cache. - - * "tagname" which, if given, should be a text string naming this cache. If - this is NULL, the identifier will be used instead. For CacheFS, the - identifier is set to name the underlying block device and the tag can be - supplied by mount. - -This function may return -ENOMEM if it ran out of memory or -EEXIST if the tag -is already in use. 0 will be returned on success. - - -Unregistering a Cache -===================== - -A cache can be withdrawn from the system by calling this function with a -pointer to the cache definition:: - - void fscache_withdraw_cache(struct fscache_cache *cache); - -In CacheFS's case, this is called by put_super(). - - -Security +Overview ======== -The cache methods are executed one of two contexts: - - (1) that of the userspace process that issued the netfs operation that caused - the cache method to be invoked, or - - (2) that of one of the processes in the FS-Cache thread pool. - -In either case, this may not be an appropriate context in which to access the -cache. - -The calling process's fsuid, fsgid and SELinux security identities may need to -be masqueraded for the duration of the cache driver's access to the cache. -This is left to the cache to handle; FS-Cache makes no effort in this regard. - +Interaction with the API is handled on three levels: cache, volume and data +storage, and each level has its own type of cookie object: -Control and Statistics Presentation -=================================== + ======================= ======================= + COOKIE C TYPE + ======================= ======================= + Cache cookie struct fscache_cache + Volume cookie struct fscache_volume + Data storage cookie struct fscache_cookie + ======================= ======================= -The cache may present data to the outside world through FS-Cache's interfaces -in sysfs and procfs - the former for control and the latter for statistics. +Cookies are used to provide some filesystem data to the cache, manage state and +pin the cache during access in addition to acting as reference points for the +API functions. Each cookie has a debugging ID that is included in trace points +to make it easier to correlate traces. Note, though, that debugging IDs are +simply allocated from incrementing counters and will eventually wrap. -A sysfs directory called /sys/fs/fscache/<cachetag>/ is created if CONFIG_SYSFS -is enabled. This is accessible through the kobject struct fscache_cache::kobj -and is for use by the cache as it sees fit. +The cache backend and the network filesystem can both ask for cache cookies - +and if they ask for one of the same name, they'll get the same cookie. Volume +and data cookies, however, are created at the behest of the filesystem only. -Relevant Data Structures -======================== +Cache Cookies +============= - * Index/Data file FS-Cache representation cookie:: +Caches are represented in the API by cache cookies. These are objects of +type:: - struct fscache_cookie { - struct fscache_object_def *def; - struct fscache_netfs *netfs; - void *netfs_data; - ... - }; - - The fields that might be of use to the backend describe the object - definition, the netfs definition and the netfs's data for this cookie. - The object definition contain functions supplied by the netfs for loading - and matching index entries; these are required to provide some of the - cache operations. - - - * In-cache object representation:: - - struct fscache_object { - int debug_id; - enum { - FSCACHE_OBJECT_RECYCLING, - ... - } state; - spinlock_t lock - struct fscache_cache *cache; - struct fscache_cookie *cookie; + struct fscache_cache { + void *cache_priv; + unsigned int debug_id; + char *name; ... }; - Structures of this type should be allocated by the cache backend and - passed to FS-Cache when requested by the appropriate cache operation. In - the case of CacheFS, they're embedded in CacheFS's internal object - structures. +There are a few fields that the cache backend might be interested in. The +``debug_id`` can be used in tracing to match lines referring to the same cache +and ``name`` is the name the cache was registered with. The ``cache_priv`` +member is private data provided by the cache when it is brought online. The +other fields are for internal use. - The debug_id is a simple integer that can be used in debugging messages - that refer to a particular object. In such a case it should be printed - using "OBJ%x" to be consistent with FS-Cache. - Each object contains a pointer to the cookie that represents the object it - is backing. An object should retired when put_object() is called if it is - in state FSCACHE_OBJECT_RECYCLING. The fscache_object struct should be - initialised by calling fscache_object_init(object). +Registering a Cache +=================== +When a cache backend wants to bring a cache online, it should first register +the cache name and that will get it a cache cookie. This is done with:: - * FS-Cache operation record:: + struct fscache_cache *fscache_acquire_cache(const char *name); - struct fscache_operation { - atomic_t usage; - struct fscache_object *object; - unsigned long flags; - #define FSCACHE_OP_EXCLUSIVE - void (*processor)(struct fscache_operation *op); - void (*release)(struct fscache_operation *op); - ... - }; +This will look up and potentially create a cache cookie. The cache cookie may +have already been created by a network filesystem looking for it, in which case +that cache cookie will be used. If the cache cookie is not in use by another +cache, it will be moved into the preparing state, otherwise it will return +busy. - FS-Cache has a pool of threads that it uses to give CPU time to the - various asynchronous operations that need to be done as part of driving - the cache. These are represented by the above structure. The processor - method is called to give the op CPU time, and the release method to get - rid of it when its usage count reaches 0. +If successful, the cache backend can then start setting up the cache. In the +event that the initialisation fails, the cache backend should call:: - An operation can be made exclusive upon an object by setting the - appropriate flag before enqueuing it with fscache_enqueue_operation(). If - an operation needs more processing time, it should be enqueued again. + void fscache_relinquish_cookie(struct fscache_cache *cache); +to reset and discard the cookie. - * FS-Cache retrieval operation record:: - struct fscache_retrieval { - struct fscache_operation op; - struct address_space *mapping; - struct list_head *to_do; - ... - }; +Bringing a Cache Online +======================= - A structure of this type is allocated by FS-Cache to record retrieval and - allocation requests made by the netfs. This struct is then passed to the - backend to do the operation. The backend may get extra refs to it by - calling fscache_get_retrieval() and refs may be discarded by calling - fscache_put_retrieval(). +Once the cache is set up, it can be brought online by calling:: - A retrieval operation can be used by the backend to do retrieval work. To - do this, the retrieval->op.processor method pointer should be set - appropriately by the backend and fscache_enqueue_retrieval() called to - submit it to the thread pool. CacheFiles, for example, uses this to queue - page examination when it detects PG_lock being cleared. + int fscache_add_cache(struct fscache_cache *cache, + const struct fscache_cache_ops *ops, + void *cache_priv); - The to_do field is an empty list available for the cache backend to use as - it sees fit. +This stores the cache operations table pointer and cache private data into the +cache cookie and moves the cache to the active state, thereby allowing accesses +to take place. - * FS-Cache storage operation record:: +Withdrawing a Cache From Service +================================ - struct fscache_storage { - struct fscache_operation op; - pgoff_t store_limit; - ... - }; +The cache backend can withdraw a cache from service by calling this function:: - A structure of this type is allocated by FS-Cache to record outstanding - writes to be made. FS-Cache itself enqueues this operation and invokes - the write_page() method on the object at appropriate times to effect - storage. + void fscache_withdraw_cache(struct fscache_cache *cache); +This moves the cache to the withdrawn state to prevent new cache- and +volume-level accesses from starting and then waits for outstanding cache-level +accesses to complete. -Cache Operations -================ +The cache must then go through the data storage objects it has and tell fscache +to withdraw them, calling:: -The cache backend provides FS-Cache with a table of operations that can be -performed on the denizens of the cache. These are held in a structure of type: + void fscache_withdraw_cookie(struct fscache_cookie *cookie); - :: +on the cookie that each object belongs to. This schedules the specified cookie +for withdrawal. This gets offloaded to a workqueue. The cache backend can +test for completion by calling:: - struct fscache_cache_ops + bool fscache_are_objects_withdrawn(struct fscache_cookie *cache); - * Name of cache provider [mandatory]:: +Once all the cookies are withdrawn, a cache backend can withdraw all the +volumes, calling:: - const char *name + void fscache_withdraw_volume(struct fscache_volume *volume); - This isn't strictly an operation, but should be pointed at a string naming - the backend. +to tell fscache that a volume has been withdrawn. This waits for all +outstanding accesses on the volume to complete before returning. +When the the cache is completely withdrawn, fscache should be notified by +calling:: - * Allocate a new object [mandatory]:: + void fscache_cache_relinquish(struct fscache_cache *cache); - struct fscache_object *(*alloc_object)(struct fscache_cache *cache, - struct fscache_cookie *cookie) +to clear fields in the cookie and discard the caller's ref on it. - This method is used to allocate a cache object representation to back a - cookie in a particular cache. fscache_object_init() should be called on - the object to initialise it prior to returning. - This function may also be used to parse the index key to be used for - multiple lookup calls to turn it into a more convenient form. FS-Cache - will call the lookup_complete() method to allow the cache to release the - form once lookup is complete or aborted. +Volume Cookies +============== +Within a cache, the data storage objects are organised into logical volumes. +These are represented in the API as objects of type:: - * Look up and create object [mandatory]:: + struct fscache_volume { + struct fscache_cache *cache; + void *cache_priv; + unsigned int debug_id; + char *key; + unsigned int key_hash; + ... + u8 coherency_len; + u8 coherency[]; + }; - void (*lookup_object)(struct fscache_object *object) +There are a number of fields here that are of interest to the caching backend: - This method is used to look up an object, given that the object is already - allocated and attached to the cookie. This should instantiate that object - in the cache if it can. + * ``cache`` - The parent cache cookie. - The method should call fscache_object_lookup_negative() as soon as - possible if it determines the object doesn't exist in the cache. If the - object is found to exist and the netfs indicates that it is valid then - fscache_obtained_object() should be called once the object is in a - position to have data stored in it. Similarly, fscache_obtained_object() - should also be called once a non-present object has been created. + * ``cache_priv`` - A place for the cache to stash private data. - If a lookup error occurs, fscache_object_lookup_error() should be called - to abort the lookup of that object. + * ``debug_id`` - A debugging ID for logging in tracepoints. + * ``key`` - A printable string with no '/' characters in it that represents + the index key for the volume. The key is NUL-terminated and padded out to + a multiple of 4 bytes. - * Release lookup data [mandatory]:: + * ``key_hash`` - A hash of the index key. This should work out the same, no + matter the cpu arch and endianness. - void (*lookup_complete)(struct fscache_object *object) + * ``coherency`` - A piece of coherency data that should be checked when the + volume is bound to in the cache. - This method is called to ask the cache to release any resources it was - using to perform a lookup. + * ``coherency_len`` - The amount of data in the coherency buffer. - * Increment object refcount [mandatory]:: +Data Storage Cookies +==================== - struct fscache_object *(*grab_object)(struct fscache_object *object) +A volume is a logical group of data storage objects, each of which is +represented to the network filesystem by a cookie. Cookies are represented in +the API as objects of type:: - This method is called to increment the reference count on an object. It - may fail (for instance if the cache is being withdrawn) by returning NULL. - It should return the object pointer if successful. + struct fscache_cookie { + struct fscache_volume *volume; + void *cache_priv; + unsigned long flags; + unsigned int debug_id; + unsigned int inval_counter; + loff_t object_size; + u8 advice; + u32 key_hash; + u8 key_len; + u8 aux_len; + ... + }; +The fields in the cookie that are of interest to the cache backend are: - * Lock/Unlock object [mandatory]:: + * ``volume`` - The parent volume cookie. - void (*lock_object)(struct fscache_object *object) - void (*unlock_object)(struct fscache_object *object) + * ``cache_priv`` - A place for the cache to stash private data. - These methods are used to exclusively lock an object. It must be possible - to schedule with the lock held, so a spinlock isn't sufficient. + * ``flags`` - A collection of bit flags, including: + * FSCACHE_COOKIE_NO_DATA_TO_READ - There is no data available in the + cache to be read as the cookie has been created or invalidated. - * Pin/Unpin object [optional]:: + * FSCACHE_COOKIE_NEEDS_UPDATE - The coherency data and/or object size has + been changed and needs committing. - int (*pin_object)(struct fscache_object *object) - void (*unpin_object)(struct fscache_object *object) + * FSCACHE_COOKIE_LOCAL_WRITE - The netfs's data has been modified + locally, so the cache object may be in an incoherent state with respect + to the server. - These methods are used to pin an object into the cache. Once pinned an - object cannot be reclaimed to make space. Return -ENOSPC if there's not - enough space in the cache to permit this. + * FSCACHE_COOKIE_HAVE_DATA - The backend should set this if it + successfully stores data into the cache. + * FSCACHE_COOKIE_RETIRED - The cookie was invalidated when it was + relinquished and the cached data should be discarded. - * Check coherency state of an object [mandatory]:: + * ``debug_id`` - A debugging ID for logging in tracepoints. - int (*check_consistency)(struct fscache_object *object) + * ``inval_counter`` - The number of invalidations done on the cookie. - This method is called to have the cache check the saved auxiliary data of - the object against the netfs's idea of the state. 0 should be returned - if they're consistent and -ESTALE otherwise. -ENOMEM and -ERESTARTSYS - may also be returned. + * ``advice`` - Information about how the cookie is to be used. - * Update object [mandatory]:: + * ``key_hash`` - A hash of the index key. This should work out the same, no + matter the cpu arch and endianness. - int (*update_object)(struct fscache_object *object) + * ``key_len`` - The length of the index key. - This is called to update the index entry for the specified object. The - new information should be in object->cookie->netfs_data. This can be - obtained by calling object->cookie->def->get_aux()/get_attr(). + * ``aux_len`` - The length of the coherency data buffer. +Each cookie has an index key, which may be stored inline to the cookie or +elsewhere. A pointer to this can be obtained by calling:: - * Invalidate data object [mandatory]:: + void *fscache_get_key(struct fscache_cookie *cookie); - int (*invalidate_object)(struct fscache_operation *op) +The index key is a binary blob, the storage for which is padded out to a +multiple of 4 bytes. - This is called to invalidate a data object (as pointed to by op->object). - All the data stored for this object should be discarded and an - attr_changed operation should be performed. The caller will follow up - with an object update operation. +Each cookie also has a buffer for coherency data. This may also be inline or +detached from the cookie and a pointer is obtained by calling:: - fscache_op_complete() must be called on op before returning. + void *fscache_get_aux(struct fscache_cookie *cookie); - * Discard object [mandatory]:: - void (*drop_object)(struct fscache_object *object) +Cookie Accounting +================= - This method is called to indicate that an object has been unbound from its - cookie, and that the cache should release the object's resources and - retire it if it's in state FSCACHE_OBJECT_RECYCLING. +Data storage cookies are counted and this is used to block cache withdrawal +completion until all objects have been destroyed. The following functions are +provided to the cache to deal with that:: - This method should not attempt to release any references held by the - caller. The caller will invoke the put_object() method as appropriate. + void fscache_count_object(struct fscache_cache *cache); + void fscache_uncount_object(struct fscache_cache *cache); + void fscache_wait_for_objects(struct fscache_cache *cache); +The count function records the allocation of an object in a cache and the +uncount function records its destruction. Warning: by the time the uncount +function returns, the cache may have been destroyed. - * Release object reference [mandatory]:: +The wait function can be used during the withdrawal procedure to wait for +fscache to finish withdrawing all the objects in the cache. When it completes, +there will be no remaining objects referring to the cache object or any volume +objects. - void (*put_object)(struct fscache_object *object) - This method is used to discard a reference to an object. The object may - be freed when all the references to it are released. +Cache Management API +==================== +The cache backend implements the cache management API by providing a table of +operations that fscache can use to manage various aspects of the cache. These +are held in a structure of type:: - * Synchronise a cache [mandatory]:: + struct fscache_cache_ops { + const char *name; + ... + }; - void (*sync)(struct fscache_cache *cache) +This contains a printable name for the cache backend driver plus a number of +pointers to methods to allow fscache to request management of the cache: - This is called to ask the backend to synchronise a cache with its backing - device. + * Set up a volume cookie [optional]:: + void (*acquire_volume)(struct fscache_volume *volume); - * Dissociate a cache [mandatory]:: + This method is called when a volume cookie is being created. The caller + holds a cache-level access pin to prevent the cache from going away for + the duration. This method should set up the resources to access a volume + in the cache and should not return until it has done so. - void (*dissociate_pages)(struct fscache_cache *cache) + If successful, it can set ``cache_priv`` to its own data. - This is called to ask a cache to perform any page dissociations as part of - cache withdrawal. + * Clean up volume cookie [optional]:: - * Notification that the attributes on a netfs file changed [mandatory]:: + void (*free_volume)(struct fscache_volume *volume); - int (*attr_changed)(struct fscache_object *object); + This method is called when a volume cookie is being released if + ``cache_priv`` is set. - This is called to indicate to the cache that certain attributes on a netfs - file have changed (for example the maximum size a file may reach). The - cache can read these from the netfs by calling the cookie's get_attr() - method. - The cache may use the file size information to reserve space on the cache. - It should also call fscache_set_store_limit() to indicate to FS-Cache the - highest byte it's willing to store for an object. + * Look up a cookie in the cache [mandatory]:: - This method may return -ve if an error occurred or the cache object cannot - be expanded. In such a case, the object will be withdrawn from service. + bool (*lookup_cookie)(struct fscache_cookie *cookie); - This operation is run asynchronously from FS-Cache's thread pool, and - storage and retrieval operations from the netfs are excluded during the - execution of this operation. + This method is called to look up/create the resources needed to access the + data storage for a cookie. It is called from a worker thread with a + volume-level access pin in the cache to prevent it from being withdrawn. + True should be returned if successful and false otherwise. If false is + returned, the withdraw_cookie op (see below) will be called. - * Reserve cache space for an object's data [optional]:: + If lookup fails, but the object could still be created (e.g. it hasn't + been cached before), then:: - int (*reserve_space)(struct fscache_object *object, loff_t size); + void fscache_cookie_lookup_negative( + struct fscache_cookie *cookie); - This is called to request that cache space be reserved to hold the data - for an object and the metadata used to track it. Zero size should be - taken as request to cancel a reservation. + can be called to let the network filesystem proceed and start downloading + stuff whilst the cache backend gets on with the job of creating things. - This should return 0 if successful, -ENOSPC if there isn't enough space - available, or -ENOMEM or -EIO on other errors. + If successful, ``cookie->cache_priv`` can be set. - The reservation may exceed the current size of the object, thus permitting - future expansion. If the amount of space consumed by an object would - exceed the reservation, it's permitted to refuse requests to allocate - pages, but not required. An object may be pruned down to its reservation - size if larger than that already. + * Withdraw an object without any cookie access counts held [mandatory]:: - * Request page be read from cache [mandatory]:: + void (*withdraw_cookie)(struct fscache_cookie *cookie); - int (*read_or_alloc_page)(struct fscache_retrieval *op, - struct page *page, - gfp_t gfp) + This method is called to withdraw a cookie from service. It will be + called when the cookie is relinquished by the netfs, withdrawn or culled + by the cache backend or closed after a period of non-use by fscache. - This is called to attempt to read a netfs page from the cache, or to - reserve a backing block if not. FS-Cache will have done as much checking - as it can before calling, but most of the work belongs to the backend. + The caller doesn't hold any access pins, but it is called from a + non-reentrant work item to manage races between the various ways + withdrawal can occur. - If there's no page in the cache, then -ENODATA should be returned if the - backend managed to reserve a backing block; -ENOBUFS or -ENOMEM if it - didn't. + The cookie will have the ``FSCACHE_COOKIE_RETIRED`` flag set on it if the + associated data is to be removed from the cache. - If there is suitable data in the cache, then a read operation should be - queued and 0 returned. When the read finishes, fscache_end_io() should be - called. - The fscache_mark_pages_cached() should be called for the page if any cache - metadata is retained. This will indicate to the netfs that the page needs - explicit uncaching. This operation takes a pagevec, thus allowing several - pages to be marked at once. + * Change the size of a data storage object [mandatory]:: - The retrieval record pointed to by op should be retained for each page - queued and released when I/O on the page has been formally ended. - fscache_get/put_retrieval() are available for this purpose. + void (*resize_cookie)(struct netfs_cache_resources *cres, + loff_t new_size); - The retrieval record may be used to get CPU time via the FS-Cache thread - pool. If this is desired, the op->op.processor should be set to point to - the appropriate processing routine, and fscache_enqueue_retrieval() should - be called at an appropriate point to request CPU time. For instance, the - retrieval routine could be enqueued upon the completion of a disk read. - The to_do field in the retrieval record is provided to aid in this. + This method is called to inform the cache backend of a change in size of + the netfs file due to local truncation. The cache backend should make all + of the changes it needs to make before returning as this is done under the + netfs inode mutex. - If an I/O error occurs, fscache_io_error() should be called and -ENOBUFS - returned if possible or fscache_end_io() called with a suitable error - code. + The caller holds a cookie-level access pin to prevent a race with + withdrawal and the netfs must have the cookie marked in-use to prevent + garbage collection or culling from removing any resources. - fscache_put_retrieval() should be called after a page or pages are dealt - with. This will complete the operation when all pages are dealt with. + * Invalidate a data storage object [mandatory]:: - * Request pages be read from cache [mandatory]:: + bool (*invalidate_cookie)(struct fscache_cookie *cookie); - int (*read_or_alloc_pages)(struct fscache_retrieval *op, - struct list_head *pages, - unsigned *nr_pages, - gfp_t gfp) + This is called when the network filesystem detects a third-party + modification or when an O_DIRECT write is made locally. This requests + that the cache backend should throw away all the data in the cache for + this object and start afresh. It should return true if successful and + false otherwise. - This is like the read_or_alloc_page() method, except it is handed a list - of pages instead of one page. Any pages on which a read operation is - started must be added to the page cache for the specified mapping and also - to the LRU. Such pages must also be removed from the pages list and - ``*nr_pages`` decremented per page. + On entry, new I O/operations are blocked. Once the cache is in a position + to accept I/O again, the backend should release the block by calling:: - If there was an error such as -ENOMEM, then that should be returned; else - if one or more pages couldn't be read or allocated, then -ENOBUFS should - be returned; else if one or more pages couldn't be read, then -ENODATA - should be returned. If all the pages are dispatched then 0 should be - returned. + void fscache_resume_after_invalidation(struct fscache_cookie *cookie); + If the method returns false, caching will be withdrawn for this cookie. - * Request page be allocated in the cache [mandatory]:: - int (*allocate_page)(struct fscache_retrieval *op, - struct page *page, - gfp_t gfp) + * Prepare to make local modifications to the cache [mandatory]:: - This is like the read_or_alloc_page() method, except that it shouldn't - read from the cache, even if there's data there that could be retrieved. - It should, however, set up any internal metadata required such that - the write_page() method can write to the cache. + void (*prepare_to_write)(struct fscache_cookie *cookie); - If there's no backing block available, then -ENOBUFS should be returned - (or -ENOMEM if there were other problems). If a block is successfully - allocated, then the netfs page should be marked and 0 returned. + This method is called when the network filesystem finds that it is going + to need to modify the contents of the cache due to local writes or + truncations. This gives the cache a chance to note that a cache object + may be incoherent with respect to the server and may need writing back + later. This may also cause the cached data to be scrapped on later + rebinding if not properly committed. - * Request pages be allocated in the cache [mandatory]:: + * Begin an operation for the netfs lib [mandatory]:: - int (*allocate_pages)(struct fscache_retrieval *op, - struct list_head *pages, - unsigned *nr_pages, - gfp_t gfp) + bool (*begin_operation)(struct netfs_cache_resources *cres, + enum fscache_want_state want_state); - This is an multiple page version of the allocate_page() method. pages and - nr_pages should be treated as for the read_or_alloc_pages() method. + This method is called when an I/O operation is being set up (read, write + or resize). The caller holds an access pin on the cookie and must have + marked the cookie as in-use. + If it can, the backend should attach any resources it needs to keep around + to the netfs_cache_resources object and return true. - * Request page be written to cache [mandatory]:: + If it can't complete the setup, it should return false. - int (*write_page)(struct fscache_storage *op, - struct page *page); + The want_state parameter indicates the state the caller needs the cache + object to be in and what it wants to do during the operation: - This is called to write from a page on which there was a previously - successful read_or_alloc_page() call or similar. FS-Cache filters out - pages that don't have mappings. + * ``FSCACHE_WANT_PARAMS`` - The caller just wants to access cache + object parameters; it doesn't need to do data I/O yet. - This method is called asynchronously from the FS-Cache thread pool. It is - not required to actually store anything, provided -ENODATA is then - returned to the next read of this page. + * ``FSCACHE_WANT_READ`` - The caller wants to read data. - If an error occurred, then a negative error code should be returned, - otherwise zero should be returned. FS-Cache will take appropriate action - in response to an error, such as withdrawing this object. + * ``FSCACHE_WANT_WRITE`` - The caller wants to write to or resize the + cache object. - If this method returns success then FS-Cache will inform the netfs - appropriately. + Note that there won't necessarily be anything attached to the cookie's + cache_priv yet if the cookie is still being created. - * Discard retained per-page metadata [mandatory]:: +Data I/O API +============ - void (*uncache_page)(struct fscache_object *object, struct page *page) +A cache backend provides a data I/O API by through the netfs library's ``struct +netfs_cache_ops`` attached to a ``struct netfs_cache_resources`` by the +``begin_operation`` method described above. - This is called when a netfs page is being evicted from the pagecache. The - cache backend should tear down any internal representation or tracking it - maintains for this page. +See the Documentation/filesystems/netfs_library.rst for a description. -FS-Cache Utilities -================== +Miscellaneous Functions +======================= FS-Cache provides some utilities that a cache backend may make use of: * Note occurrence of an I/O error in a cache:: - void fscache_io_error(struct fscache_cache *cache) + void fscache_io_error(struct fscache_cache *cache); - This tells FS-Cache that an I/O error occurred in the cache. After this - has been called, only resource dissociation operations (object and page - release) will be passed from the netfs to the cache backend for the - specified cache. + This tells FS-Cache that an I/O error occurred in the cache. This + prevents any new I/O from being started on the cache. This does not actually withdraw the cache. That must be done separately. + * Note cessation of caching on a cookie due to failure:: - * Invoke the retrieval I/O completion function:: - - void fscache_end_io(struct fscache_retrieval *op, struct page *page, - int error); - - This is called to note the end of an attempt to retrieve a page. The - error value should be 0 if successful and an error otherwise. - - - * Record that one or more pages being retrieved or allocated have been dealt - with:: - - void fscache_retrieval_complete(struct fscache_retrieval *op, - int n_pages); - - This is called to record the fact that one or more pages have been dealt - with and are no longer the concern of this operation. When the number of - pages remaining in the operation reaches 0, the operation will be - completed. - - - * Record operation completion:: - - void fscache_op_complete(struct fscache_operation *op); - - This is called to record the completion of an operation. This deducts - this operation from the parent object's run state, potentially permitting - one or more pending operations to start running. - - - * Set highest store limit:: - - void fscache_set_store_limit(struct fscache_object *object, - loff_t i_size); - - This sets the limit FS-Cache imposes on the highest byte it's willing to - try and store for a netfs. Any page over this limit is automatically - rejected by fscache_read_alloc_page() and co with -ENOBUFS. - - - * Mark pages as being cached:: - - void fscache_mark_pages_cached(struct fscache_retrieval *op, - struct pagevec *pagevec); - - This marks a set of pages as being cached. After this has been called, - the netfs must call fscache_uncache_page() to unmark the pages. - - - * Perform coherency check on an object:: - - enum fscache_checkaux fscache_check_aux(struct fscache_object *object, - const void *data, - uint16_t datalen); - - This asks the netfs to perform a coherency check on an object that has - just been looked up. The cookie attached to the object will determine the - netfs to use. data and datalen should specify where the auxiliary data - retrieved from the cache can be found. - - One of three values will be returned: - - FSCACHE_CHECKAUX_OKAY - The coherency data indicates the object is valid as is. - - FSCACHE_CHECKAUX_NEEDS_UPDATE - The coherency data needs updating, but otherwise the object is - valid. - - FSCACHE_CHECKAUX_OBSOLETE - The coherency data indicates that the object is obsolete and should - be discarded. - - - * Initialise a freshly allocated object:: - - void fscache_object_init(struct fscache_object *object); - - This initialises all the fields in an object representation. - - - * Indicate the destruction of an object:: - - void fscache_object_destroyed(struct fscache_cache *cache); - - This must be called to inform FS-Cache that an object that belonged to a - cache has been destroyed and deallocated. This will allow continuation - of the cache withdrawal process when it is stopped pending destruction of - all the objects. - - - * Indicate negative lookup on an object:: - - void fscache_object_lookup_negative(struct fscache_object *object); - - This is called to indicate to FS-Cache that a lookup process for an object - found a negative result. - - This changes the state of an object to permit reads pending on lookup - completion to go off and start fetching data from the netfs server as it's - known at this point that there can't be any data in the cache. - - This may be called multiple times on an object. Only the first call is - significant - all subsequent calls are ignored. - - - * Indicate an object has been obtained:: - - void fscache_obtained_object(struct fscache_object *object); - - This is called to indicate to FS-Cache that a lookup process for an object - produced a positive result, or that an object was created. This should - only be called once for any particular object. - - This changes the state of an object to indicate: - - (1) if no call to fscache_object_lookup_negative() has been made on - this object, that there may be data available, and that reads can - now go and look for it; and - - (2) that writes may now proceed against this object. - - - * Indicate that object lookup failed:: - - void fscache_object_lookup_error(struct fscache_object *object); - - This marks an object as having encountered a fatal error (usually EIO) - and causes it to move into a state whereby it will be withdrawn as soon - as possible. - - - * Indicate that a stale object was found and discarded:: - - void fscache_object_retrying_stale(struct fscache_object *object); - - This is called to indicate that the lookup procedure found an object in - the cache that the netfs decided was stale. The object has been - discarded from the cache and the lookup will be performed again. - - - * Indicate that the caching backend killed an object:: - - void fscache_object_mark_killed(struct fscache_object *object, - enum fscache_why_object_killed why); - - This is called to indicate that the cache backend preemptively killed an - object. The why parameter should be set to indicate the reason: + void fscache_caching_failed(struct fscache_cookie *cookie); - FSCACHE_OBJECT_IS_STALE - - the object was stale and needs discarding. + This notes that a the caching that was being done on a cookie failed in + some way, for instance the backing storage failed to be created or + invalidation failed and that no further I/O operations should take place + on it until the cache is reset. - FSCACHE_OBJECT_NO_SPACE - - there was insufficient cache space + * Count I/O requests:: - FSCACHE_OBJECT_WAS_RETIRED - - the object was retired when relinquished. + void fscache_count_read(void); + void fscache_count_write(void); - FSCACHE_OBJECT_WAS_CULLED - - the object was culled to make space. + These record reads and writes from/to the cache. The numbers are + displayed in /proc/fs/fscache/stats. + * Count out-of-space errors:: - * Get and release references on a retrieval record:: + void fscache_count_no_write_space(void); + void fscache_count_no_create_space(void); - void fscache_get_retrieval(struct fscache_retrieval *op); - void fscache_put_retrieval(struct fscache_retrieval *op); + These record ENOSPC errors in the cache, divided into failures of data + writes and failures of filesystem object creations (e.g. mkdir). - These two functions are used to retain a retrieval record while doing - asynchronous data retrieval and block allocation. + * Count objects culled:: + void fscache_count_culled(void); - * Enqueue a retrieval record for processing:: + This records the culling of an object. - void fscache_enqueue_retrieval(struct fscache_retrieval *op); + * Get the cookie from a set of cache resources:: - This enqueues a retrieval record for processing by the FS-Cache thread - pool. One of the threads in the pool will invoke the retrieval record's - op->op.processor callback function. This function may be called from - within the callback function. + struct fscache_cookie *fscache_cres_cookie(struct netfs_cache_resources *cres) + Pull a pointer to the cookie from the cache resources. This may return a + NULL cookie if no cookie was set. - * List of object state names:: - const char *fscache_object_states[]; +API Function Reference +====================== - For debugging purposes, this may be used to turn the state that an object - is in into a text string for display purposes. +.. kernel-doc:: include/linux/fscache-cache.h diff --git a/Documentation/filesystems/caching/cachefiles.rst b/Documentation/filesystems/caching/cachefiles.rst index e58bc1fd312a..8bf396b76359 100644 --- a/Documentation/filesystems/caching/cachefiles.rst +++ b/Documentation/filesystems/caching/cachefiles.rst @@ -1,8 +1,8 @@ .. SPDX-License-Identifier: GPL-2.0 -=============================================== -CacheFiles: CACHE ON ALREADY MOUNTED FILESYSTEM -=============================================== +=================================== +Cache on Already Mounted Filesystem +=================================== .. Contents: diff --git a/Documentation/filesystems/caching/fscache.rst b/Documentation/filesystems/caching/fscache.rst index 70de86922b6a..a74d7b052dc1 100644 --- a/Documentation/filesystems/caching/fscache.rst +++ b/Documentation/filesystems/caching/fscache.rst @@ -10,25 +10,25 @@ Overview This facility is a general purpose cache for network filesystems, though it could be used for caching other things such as ISO9660 filesystems too. -FS-Cache mediates between cache backends (such as CacheFS) and network +FS-Cache mediates between cache backends (such as CacheFiles) and network filesystems:: +---------+ - | | +--------------+ - | NFS |--+ | | - | | | +-->| CacheFS | - +---------+ | +----------+ | | /dev/hda5 | - | | | | +--------------+ - +---------+ +-->| | | - | | | |--+ - | AFS |----->| FS-Cache | - | | | |--+ - +---------+ +-->| | | - | | | | +--------------+ - +---------+ | +----------+ | | | - | | | +-->| CacheFiles | - | ISOFS |--+ | /var/cache | - | | +--------------+ + | | +--------------+ + | NFS |--+ | | + | | | +-->| CacheFS | + +---------+ | +----------+ | | /dev/hda5 | + | | | | +--------------+ + +---------+ +-------------->| | | + | | +-------+ | |--+ + | AFS |----->| | | FS-Cache | + | | | netfs |-->| |--+ + +---------+ +-->| lib | | | | + | | | | | | +--------------+ + +---------+ | +-------+ +----------+ | | | + | | | +-->| CacheFiles | + | 9P |--+ | /var/cache | + | | +--------------+ +---------+ Or to look at it another way, FS-Cache is a module that provides a caching @@ -84,101 +84,62 @@ then serving the pages out of that cache rather than the netfs inode because: one-off access of a small portion of it (such as might be done with the "file" program). -It instead serves the cache out in PAGE_SIZE chunks as and when requested by -the netfs('s) using it. +It instead serves the cache out in chunks as and when requested by the netfs +using it. FS-Cache provides the following facilities: - (1) More than one cache can be used at once. Caches can be selected + * More than one cache can be used at once. Caches can be selected explicitly by use of tags. - (2) Caches can be added / removed at any time. + * Caches can be added / removed at any time, even whilst being accessed. - (3) The netfs is provided with an interface that allows either party to + * The netfs is provided with an interface that allows either party to withdraw caching facilities from a file (required for (2)). - (4) The interface to the netfs returns as few errors as possible, preferring + * The interface to the netfs returns as few errors as possible, preferring rather to let the netfs remain oblivious. - (5) Cookies are used to represent indices, files and other objects to the - netfs. The simplest cookie is just a NULL pointer - indicating nothing - cached there. - - (6) The netfs is allowed to propose - dynamically - any index hierarchy it - desires, though it must be aware that the index search function is - recursive, stack space is limited, and indices can only be children of - indices. - - (7) Data I/O is done direct to and from the netfs's pages. The netfs - indicates that page A is at index B of the data-file represented by cookie - C, and that it should be read or written. The cache backend may or may - not start I/O on that page, but if it does, a netfs callback will be - invoked to indicate completion. The I/O may be either synchronous or - asynchronous. - - (8) Cookies can be "retired" upon release. At this point FS-Cache will mark - them as obsolete and the index hierarchy rooted at that point will get - recycled. - - (9) The netfs provides a "match" function for index searches. In addition to - saying whether a match was made or not, this can also specify that an - entry should be updated or deleted. - -(10) As much as possible is done asynchronously. - - -FS-Cache maintains a virtual indexing tree in which all indices, files, objects -and pages are kept. Bits of this tree may actually reside in one or more -caches:: - - FSDEF - | - +------------------------------------+ - | | - NFS AFS - | | - +--------------------------+ +-----------+ - | | | | - homedir mirror afs.org redhat.com - | | | - +------------+ +---------------+ +----------+ - | | | | | | - 00001 00002 00007 00125 vol00001 vol00002 - | | | | | - +---+---+ +-----+ +---+ +------+------+ +-----+----+ - | | | | | | | | | | | | | - PG0 PG1 PG2 PG0 XATTR PG0 PG1 DIRENT DIRENT DIRENT R/W R/O Bak - | | - PG0 +-------+ - | | - 00001 00003 - | - +---+---+ - | | | - PG0 PG1 PG2 - -In the example above, you can see two netfs's being backed: NFS and AFS. These -have different index hierarchies: - - * The NFS primary index contains per-server indices. Each server index is - indexed by NFS file handles to get data file objects. Each data file - objects can have an array of pages, but may also have further child - objects, such as extended attributes and directory entries. Extended - attribute objects themselves have page-array contents. - - * The AFS primary index contains per-cell indices. Each cell index contains - per-logical-volume indices. Each of volume index contains up to three - indices for the read-write, read-only and backup mirrors of those volumes. - Each of these contains vnode data file objects, each of which contains an - array of pages. - -The very top index is the FS-Cache master index in which individual netfs's -have entries. - -Any index object may reside in more than one cache, provided it only has index -children. Any index with non-index object children will be assumed to only -reside in one cache. + * There are three types of cookie: cache, volume and data file cookies. + Cache cookies represent the cache as a whole and are not normally visible + to the netfs; the netfs gets a volume cookie to represent a collection of + files (typically something that a netfs would get for a superblock); and + data file cookies are used to cache data (something that would be got for + an inode). + + * Volumes are matched using a key. This is a printable string that is used + to encode all the information that might be needed to distinguish one + superblock, say, from another. This would be a compound of things like + cell name or server address, volume name or share path. It must be a + valid pathname. + + * Cookies are matched using a key. This is a binary blob and is used to + represent the object within a volume (so the volume key need not form + part of the blob). This might include things like an inode number and + uniquifier or a file handle. + + * Cookie resources are set up and pinned by marking the cookie in-use. + This prevents the backing resources from being culled. Timed garbage + collection is employed to eliminate cookies that haven't been used for a + short while, thereby reducing resource overload. This is intended to be + used when a file is opened or closed. + + A cookie can be marked in-use multiple times simultaneously; each mark + must be unused. + + * Begin/end access functions are provided to delay cache withdrawal for the + duration of an operation and prevent structs from being freed whilst + we're looking at them. + + * Data I/O is done by asynchronous DIO to/from a buffer described by the + netfs using an iov_iter. + + * An invalidation facility is available to discard data from the cache and + to deal with I/O that's in progress that is accessing old data. + + * Cookies can be "retired" upon release, thereby causing the object to be + removed from the cache. The netfs API to FS-Cache can be found in: @@ -189,11 +150,6 @@ The cache backend API to FS-Cache can be found in: Documentation/filesystems/caching/backend-api.rst -A description of the internal representations and object state machine can be -found in: - - Documentation/filesystems/caching/object.rst - Statistical Information ======================= @@ -201,333 +157,162 @@ Statistical Information If FS-Cache is compiled with the following options enabled:: CONFIG_FSCACHE_STATS=y - CONFIG_FSCACHE_HISTOGRAM=y -then it will gather certain statistics and display them through a number of -proc files. +then it will gather certain statistics and display them through: -/proc/fs/fscache/stats ----------------------- + /proc/fs/fscache/stats - This shows counts of a number of events that can happen in FS-Cache: +This shows counts of a number of events that can happen in FS-Cache: +--------------+-------+-------------------------------------------------------+ |CLASS |EVENT |MEANING | +==============+=======+=======================================================+ -|Cookies |idx=N |Number of index cookies allocated | -+ +-------+-------------------------------------------------------+ -| |dat=N |Number of data storage cookies allocated | +|Cookies |n=N |Number of data storage cookies allocated | + +-------+-------------------------------------------------------+ -| |spc=N |Number of special cookies allocated | -+--------------+-------+-------------------------------------------------------+ -|Objects |alc=N |Number of objects allocated | -+ +-------+-------------------------------------------------------+ -| |nal=N |Number of object allocation failures | +| |v=N |Number of volume index cookies allocated | + +-------+-------------------------------------------------------+ -| |avl=N |Number of objects that reached the available state | -+ +-------+-------------------------------------------------------+ -| |ded=N |Number of objects that reached the dead state | -+--------------+-------+-------------------------------------------------------+ -|ChkAux |non=N |Number of objects that didn't have a coherency check | +| |vcol=N |Number of volume index key collisions | + +-------+-------------------------------------------------------+ -| |ok=N |Number of objects that passed a coherency check | -+ +-------+-------------------------------------------------------+ -| |upd=N |Number of objects that needed a coherency data update | -+ +-------+-------------------------------------------------------+ -| |obs=N |Number of objects that were declared obsolete | -+--------------+-------+-------------------------------------------------------+ -|Pages |mrk=N |Number of pages marked as being cached | -| |unc=N |Number of uncache page requests seen | +| |voom=N |Number of OOM events when allocating volume cookies | +--------------+-------+-------------------------------------------------------+ |Acquire |n=N |Number of acquire cookie requests seen | + +-------+-------------------------------------------------------+ -| |nul=N |Number of acq reqs given a NULL parent | -+ +-------+-------------------------------------------------------+ -| |noc=N |Number of acq reqs rejected due to no cache available | -+ +-------+-------------------------------------------------------+ | |ok=N |Number of acq reqs succeeded | + +-------+-------------------------------------------------------+ -| |nbf=N |Number of acq reqs rejected due to error | -+ +-------+-------------------------------------------------------+ | |oom=N |Number of acq reqs failed on ENOMEM | +--------------+-------+-------------------------------------------------------+ -|Lookups |n=N |Number of lookup calls made on cache backends | +|LRU |n=N |Number of cookies currently on the LRU | + +-------+-------------------------------------------------------+ -| |neg=N |Number of negative lookups made | +| |exp=N |Number of cookies expired off of the LRU | + +-------+-------------------------------------------------------+ -| |pos=N |Number of positive lookups made | +| |rmv=N |Number of cookies removed from the LRU | + +-------+-------------------------------------------------------+ -| |crt=N |Number of objects created by lookup | +| |drp=N |Number of LRU'd cookies relinquished/withdrawn | + +-------+-------------------------------------------------------+ -| |tmo=N |Number of lookups timed out and requeued | +| |at=N |Time till next LRU cull (jiffies) | ++--------------+-------+-------------------------------------------------------+ +|Invals |n=N |Number of invalidations | +--------------+-------+-------------------------------------------------------+ |Updates |n=N |Number of update cookie requests seen | + +-------+-------------------------------------------------------+ -| |nul=N |Number of upd reqs given a NULL parent | +| |rsz=N |Number of resize requests | + +-------+-------------------------------------------------------+ -| |run=N |Number of upd reqs granted CPU time | +| |rsn=N |Number of skipped resize requests | +--------------+-------+-------------------------------------------------------+ |Relinqs |n=N |Number of relinquish cookie requests seen | + +-------+-------------------------------------------------------+ -| |nul=N |Number of rlq reqs given a NULL parent | +| |rtr=N |Number of rlq reqs with retire=true | + +-------+-------------------------------------------------------+ -| |wcr=N |Number of rlq reqs waited on completion of creation | +| |drop=N |Number of cookies no longer blocking re-acquisition | +--------------+-------+-------------------------------------------------------+ -|AttrChg |n=N |Number of attribute changed requests seen | -+ +-------+-------------------------------------------------------+ -| |ok=N |Number of attr changed requests queued | -+ +-------+-------------------------------------------------------+ -| |nbf=N |Number of attr changed rejected -ENOBUFS | +|NoSpace |nwr=N |Number of write requests refused due to lack of space | + +-------+-------------------------------------------------------+ -| |oom=N |Number of attr changed failed -ENOMEM | +| |ncr=N |Number of create requests refused due to lack of space | + +-------+-------------------------------------------------------+ -| |run=N |Number of attr changed ops given CPU time | +| |cull=N |Number of objects culled to make space | +--------------+-------+-------------------------------------------------------+ -|Allocs |n=N |Number of allocation requests seen | +|IO |rd=N |Number of read operations in the cache | + +-------+-------------------------------------------------------+ -| |ok=N |Number of successful alloc reqs | -+ +-------+-------------------------------------------------------+ -| |wt=N |Number of alloc reqs that waited on lookup completion | -+ +-------+-------------------------------------------------------+ -| |nbf=N |Number of alloc reqs rejected -ENOBUFS | -+ +-------+-------------------------------------------------------+ -| |int=N |Number of alloc reqs aborted -ERESTARTSYS | -+ +-------+-------------------------------------------------------+ -| |ops=N |Number of alloc reqs submitted | -+ +-------+-------------------------------------------------------+ -| |owt=N |Number of alloc reqs waited for CPU time | -+ +-------+-------------------------------------------------------+ -| |abt=N |Number of alloc reqs aborted due to object death | -+--------------+-------+-------------------------------------------------------+ -|Retrvls |n=N |Number of retrieval (read) requests seen | -+ +-------+-------------------------------------------------------+ -| |ok=N |Number of successful retr reqs | -+ +-------+-------------------------------------------------------+ -| |wt=N |Number of retr reqs that waited on lookup completion | -+ +-------+-------------------------------------------------------+ -| |nod=N |Number of retr reqs returned -ENODATA | -+ +-------+-------------------------------------------------------+ -| |nbf=N |Number of retr reqs rejected -ENOBUFS | -+ +-------+-------------------------------------------------------+ -| |int=N |Number of retr reqs aborted -ERESTARTSYS | -+ +-------+-------------------------------------------------------+ -| |oom=N |Number of retr reqs failed -ENOMEM | -+ +-------+-------------------------------------------------------+ -| |ops=N |Number of retr reqs submitted | -+ +-------+-------------------------------------------------------+ -| |owt=N |Number of retr reqs waited for CPU time | -+ +-------+-------------------------------------------------------+ -| |abt=N |Number of retr reqs aborted due to object death | -+--------------+-------+-------------------------------------------------------+ -|Stores |n=N |Number of storage (write) requests seen | -+ +-------+-------------------------------------------------------+ -| |ok=N |Number of successful store reqs | -+ +-------+-------------------------------------------------------+ -| |agn=N |Number of store reqs on a page already pending storage | -+ +-------+-------------------------------------------------------+ -| |nbf=N |Number of store reqs rejected -ENOBUFS | -+ +-------+-------------------------------------------------------+ -| |oom=N |Number of store reqs failed -ENOMEM | -+ +-------+-------------------------------------------------------+ -| |ops=N |Number of store reqs submitted | -+ +-------+-------------------------------------------------------+ -| |run=N |Number of store reqs granted CPU time | -+ +-------+-------------------------------------------------------+ -| |pgs=N |Number of pages given store req processing time | -+ +-------+-------------------------------------------------------+ -| |rxd=N |Number of store reqs deleted from tracking tree | -+ +-------+-------------------------------------------------------+ -| |olm=N |Number of store reqs over store limit | -+--------------+-------+-------------------------------------------------------+ -|VmScan |nos=N |Number of release reqs against pages with no | -| | |pending store | -+ +-------+-------------------------------------------------------+ -| |gon=N |Number of release reqs against pages stored by | -| | |time lock granted | -+ +-------+-------------------------------------------------------+ -| |bsy=N |Number of release reqs ignored due to in-progress store| -+ +-------+-------------------------------------------------------+ -| |can=N |Number of page stores cancelled due to release req | -+--------------+-------+-------------------------------------------------------+ -|Ops |pend=N |Number of times async ops added to pending queues | -+ +-------+-------------------------------------------------------+ -| |run=N |Number of times async ops given CPU time | -+ +-------+-------------------------------------------------------+ -| |enq=N |Number of times async ops queued for processing | -+ +-------+-------------------------------------------------------+ -| |can=N |Number of async ops cancelled | -+ +-------+-------------------------------------------------------+ -| |rej=N |Number of async ops rejected due to object | -| | |lookup/create failure | -+ +-------+-------------------------------------------------------+ -| |ini=N |Number of async ops initialised | -+ +-------+-------------------------------------------------------+ -| |dfr=N |Number of async ops queued for deferred release | -+ +-------+-------------------------------------------------------+ -| |rel=N |Number of async ops released | -| | |(should equal ini=N when idle) | -+ +-------+-------------------------------------------------------+ -| |gc=N |Number of deferred-release async ops garbage collected | -+--------------+-------+-------------------------------------------------------+ -|CacheOp |alo=N |Number of in-progress alloc_object() cache ops | -+ +-------+-------------------------------------------------------+ -| |luo=N |Number of in-progress lookup_object() cache ops | -+ +-------+-------------------------------------------------------+ -| |luc=N |Number of in-progress lookup_complete() cache ops | -+ +-------+-------------------------------------------------------+ -| |gro=N |Number of in-progress grab_object() cache ops | -+ +-------+-------------------------------------------------------+ -| |upo=N |Number of in-progress update_object() cache ops | -+ +-------+-------------------------------------------------------+ -| |dro=N |Number of in-progress drop_object() cache ops | -+ +-------+-------------------------------------------------------+ -| |pto=N |Number of in-progress put_object() cache ops | -+ +-------+-------------------------------------------------------+ -| |syn=N |Number of in-progress sync_cache() cache ops | -+ +-------+-------------------------------------------------------+ -| |atc=N |Number of in-progress attr_changed() cache ops | -+ +-------+-------------------------------------------------------+ -| |rap=N |Number of in-progress read_or_alloc_page() cache ops | -+ +-------+-------------------------------------------------------+ -| |ras=N |Number of in-progress read_or_alloc_pages() cache ops | -+ +-------+-------------------------------------------------------+ -| |alp=N |Number of in-progress allocate_page() cache ops | -+ +-------+-------------------------------------------------------+ -| |als=N |Number of in-progress allocate_pages() cache ops | -+ +-------+-------------------------------------------------------+ -| |wrp=N |Number of in-progress write_page() cache ops | -+ +-------+-------------------------------------------------------+ -| |ucp=N |Number of in-progress uncache_page() cache ops | -+ +-------+-------------------------------------------------------+ -| |dsp=N |Number of in-progress dissociate_pages() cache ops | -+--------------+-------+-------------------------------------------------------+ -|CacheEv |nsp=N |Number of object lookups/creations rejected due to | -| | |lack of space | -+ +-------+-------------------------------------------------------+ -| |stl=N |Number of stale objects deleted | -+ +-------+-------------------------------------------------------+ -| |rtr=N |Number of objects retired when relinquished | -+ +-------+-------------------------------------------------------+ -| |cul=N |Number of objects culled | +| |wr=N |Number of write operations in the cache | +--------------+-------+-------------------------------------------------------+ +Netfslib will also add some stats counters of its own. -/proc/fs/fscache/histogram --------------------------- +Cache List +========== - :: +FS-Cache provides a list of cache cookies: - cat /proc/fs/fscache/histogram - JIFS SECS OBJ INST OP RUNS OBJ RUNS RETRV DLY RETRIEVLS - ===== ===== ========= ========= ========= ========= ========= + /proc/fs/fscache/cookies - This shows the breakdown of the number of times each amount of time - between 0 jiffies and HZ-1 jiffies a variety of tasks took to run. The - columns are as follows: +This will look something like:: - ========= ======================================================= - COLUMN TIME MEASUREMENT - ========= ======================================================= - OBJ INST Length of time to instantiate an object - OP RUNS Length of time a call to process an operation took - OBJ RUNS Length of time a call to process an object event took - RETRV DLY Time between an requesting a read and lookup completing - RETRIEVLS Time between beginning and end of a retrieval - ========= ======================================================= + # cat /proc/fs/fscache/caches + CACHE REF VOLS OBJS ACCES S NAME + ======== ===== ===== ===== ===== = =============== + 00000001 2 1 2123 1 A default - Each row shows the number of events that took a particular range of times. - Each step is 1 jiffy in size. The JIFS column indicates the particular - jiffy range covered, and the SECS field the equivalent number of seconds. +where the columns are: + ======= =============================================================== + COLUMN DESCRIPTION + ======= =============================================================== + CACHE Cache cookie debug ID (also appears in traces) + REF Number of references on the cache cookie + VOLS Number of volumes cookies in this cache + OBJS Number of cache objects in use + ACCES Number of accesses pinning the cache + S State + NAME Name of the cache. + ======= =============================================================== + +The state can be (-) Inactive, (P)reparing, (A)ctive, (E)rror or (W)ithdrawing. -Object List +Volume List =========== -If CONFIG_FSCACHE_OBJECT_LIST is enabled, the FS-Cache facility will maintain a -list of all the objects currently allocated and allow them to be viewed -through:: +FS-Cache provides a list of volume cookies: - /proc/fs/fscache/objects + /proc/fs/fscache/volumes This will look something like:: - [root@andromeda ~]# head /proc/fs/fscache/objects - OBJECT PARENT STAT CHLDN OPS OOP IPR EX READS EM EV F S | NETFS_COOKIE_DEF TY FL NETFS_DATA OBJECT_KEY, AUX_DATA - ======== ======== ==== ===== === === === == ===== == == = = | ================ == == ================ ================ - 17e4b 2 ACTV 0 0 0 0 0 0 7b 4 0 0 | NFS.fh DT 0 ffff88001dd82820 010006017edcf8bbc93b43298fdfbe71e50b57b13a172c0117f38472, e567634700000000000000000000000063f2404a000000000000000000000000c9030000000000000000000063f2404a - 1693a 2 ACTV 0 0 0 0 0 0 7b 4 0 0 | NFS.fh DT 0 ffff88002db23380 010006017edcf8bbc93b43298fdfbe71e50b57b1e0162c01a2df0ea6, 420ebc4a000000000000000000000000420ebc4a0000000000000000000000000e1801000000000000000000420ebc4a + VOLUME REF nCOOK ACC FL CACHE KEY + ======== ===== ===== === == =============== ================ + 00000001 55 54 1 00 default afs,example.com,100058 -where the first set of columns before the '|' describe the object: +where the columns are: ======= =============================================================== COLUMN DESCRIPTION ======= =============================================================== - OBJECT Object debugging ID (appears as OBJ%x in some debug messages) - PARENT Debugging ID of parent object - STAT Object state - CHLDN Number of child objects of this object - OPS Number of outstanding operations on this object - OOP Number of outstanding child object management operations - IPR - EX Number of outstanding exclusive operations - READS Number of outstanding read operations - EM Object's event mask - EV Events raised on this object - F Object flags - S Object work item busy state mask (1:pending 2:running) + VOLUME The volume cookie debug ID (also appears in traces) + REF Number of references on the volume cookie + nCOOK Number of cookies in the volume + ACC Number of accesses pinning the cache + FL Flags on the volume cookie + CACHE Name of the cache or "-" + KEY The indexing key for the volume ======= =============================================================== -and the second set of columns describe the object's cookie, if present: - - ================ ====================================================== - COLUMN DESCRIPTION - ================ ====================================================== - NETFS_COOKIE_DEF Name of netfs cookie definition - TY Cookie type (IX - index, DT - data, hex - special) - FL Cookie flags - NETFS_DATA Netfs private data stored in the cookie - OBJECT_KEY Object key } 1 column, with separating comma - AUX_DATA Object aux data } presence may be configured - ================ ====================================================== - -The data shown may be filtered by attaching the a key to an appropriate keyring -before viewing the file. Something like:: - - keyctl add user fscache:objlist <restrictions> @s - -where <restrictions> are a selection of the following letters: - == ========================================================= - K Show hexdump of object key (don't show if not given) - A Show hexdump of object aux data (don't show if not given) - == ========================================================= +Cookie List +=========== -and the following paired letters: +FS-Cache provides a list of cookies: - == ========================================================= - C Show objects that have a cookie - c Show objects that don't have a cookie - B Show objects that are busy - b Show objects that aren't busy - W Show objects that have pending writes - w Show objects that don't have pending writes - R Show objects that have outstanding reads - r Show objects that don't have outstanding reads - S Show objects that have work queued - s Show objects that don't have work queued - == ========================================================= + /proc/fs/fscache/cookies -If neither side of a letter pair is given, then both are implied. For example: +This will look something like:: - keyctl add user fscache:objlist KB @s + # head /proc/fs/fscache/cookies + COOKIE VOLUME REF ACT ACC S FL DEF + ======== ======== === === === = == ================ + 00000435 00000001 1 0 -1 - 08 0000000201d080070000000000000000, 0000000000000000 + 00000436 00000001 1 0 -1 - 00 0000005601d080080000000000000000, 0000000000000051 + 00000437 00000001 1 0 -1 - 08 00023b3001d0823f0000000000000000, 0000000000000000 + 00000438 00000001 1 0 -1 - 08 0000005801d0807b0000000000000000, 0000000000000000 + 00000439 00000001 1 0 -1 - 08 00023b3201d080a10000000000000000, 0000000000000000 + 0000043a 00000001 1 0 -1 - 08 00023b3401d080a30000000000000000, 0000000000000000 + 0000043b 00000001 1 0 -1 - 08 00023b3601d080b30000000000000000, 0000000000000000 + 0000043c 00000001 1 0 -1 - 08 00023b3801d080b40000000000000000, 0000000000000000 -shows objects that are busy, and lists their object keys, but does not dump -their auxiliary data. It also implies "CcWwRrSs", but as 'B' is given, 'b' is -not implied. +where the columns are: -By default all objects and all fields will be shown. + ======= =============================================================== + COLUMN DESCRIPTION + ======= =============================================================== + COOKIE The cookie debug ID (also appears in traces) + VOLUME The parent volume cookie debug ID + REF Number of references on the volume cookie + ACT Number of times the cookie is marked for in use + ACC Number of access pins in the cookie + S State of the cookie + FL Flags on the cookie + DEF Key, auxiliary data + ======= =============================================================== Debugging @@ -549,10 +334,8 @@ This is a bitmask of debugging streams to enable: 3 8 Cookie management Function entry trace 4 16 Function exit trace 5 32 General - 6 64 Page handling Function entry trace - 7 128 Function exit trace - 8 256 General - 9 512 Operation management Function entry trace + 6-8 (Not used) + 9 512 I/O operation management Function entry trace 10 1024 Function exit trace 11 2048 General ======= ======= =============================== ======================= @@ -560,6 +343,6 @@ This is a bitmask of debugging streams to enable: The appropriate set of values should be OR'd together and the result written to the control file. For example:: - echo $((1|8|64)) >/sys/module/fscache/parameters/debug + echo $((1|8|512)) >/sys/module/fscache/parameters/debug will turn on all function entry debugging. diff --git a/Documentation/filesystems/caching/index.rst b/Documentation/filesystems/caching/index.rst index 033da7ac7c6e..df4307124b00 100644 --- a/Documentation/filesystems/caching/index.rst +++ b/Documentation/filesystems/caching/index.rst @@ -7,8 +7,6 @@ Filesystem Caching :maxdepth: 2 fscache - object + netfs-api backend-api cachefiles - netfs-api - operations diff --git a/Documentation/filesystems/caching/netfs-api.rst b/Documentation/filesystems/caching/netfs-api.rst index d9f14b8610ba..f84e9ffdf0b4 100644 --- a/Documentation/filesystems/caching/netfs-api.rst +++ b/Documentation/filesystems/caching/netfs-api.rst @@ -1,896 +1,452 @@ .. SPDX-License-Identifier: GPL-2.0 -=============================== -FS-Cache Network Filesystem API -=============================== +============================== +Network Filesystem Caching API +============================== -There's an API by which a network filesystem can make use of the FS-Cache -facilities. This is based around a number of principles: +Fscache provides an API by which a network filesystem can make use of local +caching facilities. The API is arranged around a number of principles: - (1) Caches can store a number of different object types. There are two main - object types: indices and files. The first is a special type used by - FS-Cache to make finding objects faster and to make retiring of groups of - objects easier. + (1) A cache is logically organised into volumes and data storage objects + within those volumes. - (2) Every index, file or other object is represented by a cookie. This cookie - may or may not have anything associated with it, but the netfs doesn't - need to care. + (2) Volumes and data storage objects are represented by various types of + cookie. - (3) Barring the top-level index (one entry per cached netfs), the index - hierarchy for each netfs is structured according the whim of the netfs. + (3) Cookies have keys that distinguish them from their peers. -This API is declared in <linux/fscache.h>. + (4) Cookies have coherency data that allows a cache to determine if the + cached data is still valid. -.. This document contains the following sections: - - (1) Network filesystem definition - (2) Index definition - (3) Object definition - (4) Network filesystem (un)registration - (5) Cache tag lookup - (6) Index registration - (7) Data file registration - (8) Miscellaneous object registration - (9) Setting the data file size - (10) Page alloc/read/write - (11) Page uncaching - (12) Index and data file consistency - (13) Cookie enablement - (14) Miscellaneous cookie operations - (15) Cookie unregistration - (16) Index invalidation - (17) Data file invalidation - (18) FS-Cache specific page flags. - - -Network Filesystem Definition -============================= - -FS-Cache needs a description of the network filesystem. This is specified -using a record of the following structure:: - - struct fscache_netfs { - uint32_t version; - const char *name; - struct fscache_cookie *primary_index; - ... - }; - -This first two fields should be filled in before registration, and the third -will be filled in by the registration function; any other fields should just be -ignored and are for internal use only. - -The fields are: - - (1) The name of the netfs (used as the key in the toplevel index). - - (2) The version of the netfs (if the name matches but the version doesn't, the - entire in-cache hierarchy for this netfs will be scrapped and begun - afresh). - - (3) The cookie representing the primary index will be allocated according to - another parameter passed into the registration function. - -For example, kAFS (linux/fs/afs/) uses the following definitions to describe -itself:: - - struct fscache_netfs afs_cache_netfs = { - .version = 0, - .name = "afs", - }; - - -Index Definition -================ - -Indices are used for two purposes: - - (1) To aid the finding of a file based on a series of keys (such as AFS's - "cell", "volume ID", "vnode ID"). - - (2) To make it easier to discard a subset of all the files cached based around - a particular key - for instance to mirror the removal of an AFS volume. - -However, since it's unlikely that any two netfs's are going to want to define -their index hierarchies in quite the same way, FS-Cache tries to impose as few -restraints as possible on how an index is structured and where it is placed in -the tree. The netfs can even mix indices and data files at the same level, but -it's not recommended. - -Each index entry consists of a key of indeterminate length plus some auxiliary -data, also of indeterminate length. - -There are some limits on indices: - - (1) Any index containing non-index objects should be restricted to a single - cache. Any such objects created within an index will be created in the - first cache only. The cache in which an index is created can be - controlled by cache tags (see below). - - (2) The entry data must be atomically journallable, so it is limited to about - 400 bytes at present. At least 400 bytes will be available. - - (3) The depth of the index tree should be judged with care as the search - function is recursive. Too many layers will run the kernel out of stack. - - -Object Definition -================= - -To define an object, a structure of the following type should be filled out:: - - struct fscache_cookie_def - { - uint8_t name[16]; - uint8_t type; - - struct fscache_cache_tag *(*select_cache)( - const void *parent_netfs_data, - const void *cookie_netfs_data); - - enum fscache_checkaux (*check_aux)(void *cookie_netfs_data, - const void *data, - uint16_t datalen, - loff_t object_size); - - void (*get_context)(void *cookie_netfs_data, void *context); - - void (*put_context)(void *cookie_netfs_data, void *context); - - void (*mark_pages_cached)(void *cookie_netfs_data, - struct address_space *mapping, - struct pagevec *cached_pvec); - }; - -This has the following fields: - - (1) The type of the object [mandatory]. - - This is one of the following values: - - FSCACHE_COOKIE_TYPE_INDEX - This defines an index, which is a special FS-Cache type. - - FSCACHE_COOKIE_TYPE_DATAFILE - This defines an ordinary data file. - - Any other value between 2 and 255 - This defines an extraordinary object such as an XATTR. - - (2) The name of the object type (NUL terminated unless all 16 chars are used) - [optional]. - - (3) A function to select the cache in which to store an index [optional]. - - This function is invoked when an index needs to be instantiated in a cache - during the instantiation of a non-index object. Only the immediate index - parent for the non-index object will be queried. Any indices above that - in the hierarchy may be stored in multiple caches. This function does not - need to be supplied for any non-index object or any index that will only - have index children. - - If this function is not supplied or if it returns NULL then the first - cache in the parent's list will be chosen, or failing that, the first - cache in the master list. - - (4) A function to check the auxiliary data [optional]. - - This function will be called to check that a match found in the cache for - this object is valid. For instance with AFS it could check the auxiliary - data against the data version number returned by the server to determine - whether the index entry in a cache is still valid. - - If this function is absent, it will be assumed that matching objects in a - cache are always valid. - - The function is also passed the cache's idea of the object size and may - use this to manage coherency also. - - If present, the function should return one of the following values: - - FSCACHE_CHECKAUX_OKAY - - the entry is okay as is - - FSCACHE_CHECKAUX_NEEDS_UPDATE - - the entry requires update - - FSCACHE_CHECKAUX_OBSOLETE - - the entry should be deleted + (5) I/O is done asynchronously where possible. - This function can also be used to extract data from the auxiliary data in - the cache and copy it into the netfs's structures. +This API is used by:: - (5) A pair of functions to manage contexts for the completion callback - [optional]. + #include <linux/fscache.h>. - The cache read/write functions are passed a context which is then passed - to the I/O completion callback function. To ensure this context remains - valid until after the I/O completion is called, two functions may be - provided: one to get an extra reference on the context, and one to drop a - reference to it. - - If the context is not used or is a type of object that won't go out of - scope, then these functions are not required. These functions are not - required for indices as indices may not contain data. These functions may - be called in interrupt context and so may not sleep. - - (6) A function to mark a page as retaining cache metadata [optional]. - - This is called by the cache to indicate that it is retaining in-memory - information for this page and that the netfs should uncache the page when - it has finished. This does not indicate whether there's data on the disk - or not. Note that several pages at once may be presented for marking. - - The PG_fscache bit is set on the pages before this function would be - called, so the function need not be provided if this is sufficient. - - This function is not required for indices as they're not permitted data. - - (7) A function to unmark all the pages retaining cache metadata [mandatory]. - - This is called by FS-Cache to indicate that a backing store is being - unbound from a cookie and that all the marks on the pages should be - cleared to prevent confusion. Note that the cache will have torn down all - its tracking information so that the pages don't need to be explicitly - uncached. - - This function is not required for indices as they're not permitted data. - - -Network Filesystem (Un)registration -=================================== - -The first step is to declare the network filesystem to the cache. This also -involves specifying the layout of the primary index (for AFS, this would be the -"cell" level). - -The registration function is:: - - int fscache_register_netfs(struct fscache_netfs *netfs); - -It just takes a pointer to the netfs definition. It returns 0 or an error as -appropriate. - -For kAFS, registration is done as follows:: - - ret = fscache_register_netfs(&afs_cache_netfs); - -The last step is, of course, unregistration:: - - void fscache_unregister_netfs(struct fscache_netfs *netfs); - - -Cache Tag Lookup -================ - -FS-Cache permits the use of more than one cache. To permit particular index -subtrees to be bound to particular caches, the second step is to look up cache -representation tags. This step is optional; it can be left entirely up to -FS-Cache as to which cache should be used. The problem with doing that is that -FS-Cache will always pick the first cache that was registered. - -To get the representation for a named tag:: - - struct fscache_cache_tag *fscache_lookup_cache_tag(const char *name); - -This takes a text string as the name and returns a representation of a tag. It -will never return an error. It may return a dummy tag, however, if it runs out -of memory; this will inhibit caching with this tag. - -Any representation so obtained must be released by passing it to this function:: - - void fscache_release_cache_tag(struct fscache_cache_tag *tag); +.. This document contains the following sections: -The tag will be retrieved by FS-Cache when it calls the object definition -operation select_cache(). + (1) Overview + (2) Volume registration + (3) Data file registration + (4) Declaring a cookie to be in use + (5) Resizing a data file (truncation) + (6) Data I/O API + (7) Data file coherency + (8) Data file invalidation + (9) Write back resource management + (10) Caching of local modifications + (11) Page release and invalidation + + +Overview +======== + +The fscache hierarchy is organised on two levels from a network filesystem's +point of view. The upper level represents "volumes" and the lower level +represents "data storage objects". These are represented by two types of +cookie, hereafter referred to as "volume cookies" and "cookies". + +A network filesystem acquires a volume cookie for a volume using a volume key, +which represents all the information that defines that volume (e.g. cell name +or server address, volume ID or share name). This must be rendered as a +printable string that can be used as a directory name (ie. no '/' characters +and shouldn't begin with a '.'). The maximum name length is one less than the +maximum size of a filename component (allowing the cache backend one char for +its own purposes). + +A filesystem would typically have a volume cookie for each superblock. + +The filesystem then acquires a cookie for each file within that volume using an +object key. Object keys are binary blobs and only need to be unique within +their parent volume. The cache backend is reponsible for rendering the binary +blob into something it can use and may employ hash tables, trees or whatever to +improve its ability to find an object. This is transparent to the network +filesystem. + +A filesystem would typically have a cookie for each inode, and would acquire it +in iget and relinquish it when evicting the cookie. + +Once it has a cookie, the filesystem needs to mark the cookie as being in use. +This causes fscache to send the cache backend off to look up/create resources +for the cookie in the background, to check its coherency and, if necessary, to +mark the object as being under modification. + +A filesystem would typically "use" the cookie in its file open routine and +unuse it in file release and it needs to use the cookie around calls to +truncate the cookie locally. It *also* needs to use the cookie when the +pagecache becomes dirty and unuse it when writeback is complete. This is +slightly tricky, and provision is made for it. + +When performing a read, write or resize on a cookie, the filesystem must first +begin an operation. This copies the resources into a holding struct and puts +extra pins into the cache to stop cache withdrawal from tearing down the +structures being used. The actual operation can then be issued and conflicting +invalidations can be detected upon completion. + +The filesystem is expected to use netfslib to access the cache, but that's not +actually required and it can use the fscache I/O API directly. + + +Volume Registration +=================== + +The first step for a network filsystem is to acquire a volume cookie for the +volume it wants to access:: + + struct fscache_volume * + fscache_acquire_volume(const char *volume_key, + const char *cache_name, + const void *coherency_data, + size_t coherency_len); + +This function creates a volume cookie with the specified volume key as its name +and notes the coherency data. + +The volume key must be a printable string with no '/' characters in it. It +should begin with the name of the filesystem and should be no longer than 254 +characters. It should uniquely represent the volume and will be matched with +what's stored in the cache. + +The caller may also specify the name of the cache to use. If specified, +fscache will look up or create a cache cookie of that name and will use a cache +of that name if it is online or comes online. If no cache name is specified, +it will use the first cache that comes to hand and set the name to that. + +The specified coherency data is stored in the cookie and will be matched +against coherency data stored on disk. The data pointer may be NULL if no data +is provided. If the coherency data doesn't match, the entire cache volume will +be invalidated. + +This function can return errors such as EBUSY if the volume key is already in +use by an acquired volume or ENOMEM if an allocation failure occured. It may +also return a NULL volume cookie if fscache is not enabled. It is safe to +pass a NULL cookie to any function that takes a volume cookie. This will +cause that function to do nothing. + + +When the network filesystem has finished with a volume, it should relinquish it +by calling:: + + void fscache_relinquish_volume(struct fscache_volume *volume, + const void *coherency_data, + bool invalidate); + +This will cause the volume to be committed or removed, and if sealed the +coherency data will be set to the value supplied. The amount of coherency data +must match the length specified when the volume was acquired. Note that all +data cookies obtained in this volume must be relinquished before the volume is +relinquished. -Index Registration -================== +Data File Registration +====================== -The third step is to inform FS-Cache about part of an index hierarchy that can -be used to locate files. This is done by requesting a cookie for each index in -the path to the file:: +Once it has a volume cookie, a network filesystem can use it to acquire a +cookie for data storage:: struct fscache_cookie * - fscache_acquire_cookie(struct fscache_cookie *parent, - const struct fscache_object_def *def, + fscache_acquire_cookie(struct fscache_volume *volume, + u8 advice, const void *index_key, size_t index_key_len, const void *aux_data, size_t aux_data_len, - void *netfs_data, - loff_t object_size, - bool enable); + loff_t object_size) -This function creates an index entry in the index represented by parent, -filling in the index entry by calling the operations pointed to by def. +This creates the cookie in the volume using the specified index key. The index +key is a binary blob of the given length and must be unique for the volume. +This is saved into the cookie. There are no restrictions on the content, but +its length shouldn't exceed about three quarters of the maximum filename length +to allow for encoding. -A unique key that represents the object within the parent must be pointed to by -index_key and is of length index_key_len. +The caller should also pass in a piece of coherency data in aux_data. A buffer +of size aux_data_len will be allocated and the coherency data copied in. It is +assumed that the size is invariant over time. The coherency data is used to +check the validity of data in the cache. Functions are provided by which the +coherency data can be updated. -An optional blob of auxiliary data that is to be stored within the cache can be -pointed to with aux_data and should be of length aux_data_len. This would -typically be used for storing coherency data. +The file size of the object being cached should also be provided. This may be +used to trim the data and will be stored with the coherency data. -The netfs may pass an arbitrary value in netfs_data and this will be presented -to it in the event of any calling back. This may also be used in tracing or -logging of messages. +This function never returns an error, though it may return a NULL cookie on +allocation failure or if fscache is not enabled. It is safe to pass in a NULL +volume cookie and pass the NULL cookie returned to any function that takes it. +This will cause that function to do nothing. -The cache tracks the size of the data attached to an object and this set to be -object_size. For indices, this should be 0. This value will be passed to the -->check_aux() callback. -Note that this function never returns an error - all errors are handled -internally. It may, however, return NULL to indicate no cookie. It is quite -acceptable to pass this token back to this function as the parent to another -acquisition (or even to the relinquish cookie, read page and write page -functions - see below). +When the network filesystem has finished with a cookie, it should relinquish it +by calling:: -Note also that no indices are actually created in a cache until a non-index -object needs to be created somewhere down the hierarchy. Furthermore, an index -may be created in several different caches independently at different times. -This is all handled transparently, and the netfs doesn't see any of it. + void fscache_relinquish_cookie(struct fscache_cookie *cookie, + bool retire); -A cookie will be created in the disabled state if enabled is false. A cookie -must be enabled to do anything with it. A disabled cookie can be enabled by -calling fscache_enable_cookie() (see below). +This will cause fscache to either commit the storage backing the cookie or +delete it. -For example, with AFS, a cell would be added to the primary index. This index -entry would have a dependent inode containing volume mappings within this cell:: - cell->cache = - fscache_acquire_cookie(afs_cache_netfs.primary_index, - &afs_cell_cache_index_def, - cell->name, strlen(cell->name), - NULL, 0, - cell, 0, true); +Marking A Cookie In-Use +======================= -And then a particular volume could be added to that index by ID, creating -another index for vnodes (AFS inode equivalents):: +Once a cookie has been acquired by a network filesystem, the filesystem should +tell fscache when it intends to use the cookie (typically done on file open) +and should say when it has finished with it (typically on file close):: - volume->cache = - fscache_acquire_cookie(volume->cell->cache, - &afs_volume_cache_index_def, - &volume->vid, sizeof(volume->vid), - NULL, 0, - volume, 0, true); + void fscache_use_cookie(struct fscache_cookie *cookie, + bool will_modify); + void fscache_unuse_cookie(struct fscache_cookie *cookie, + const void *aux_data, + const loff_t *object_size); +The *use* function tells fscache that it will use the cookie and, additionally, +indicate if the user is intending to modify the contents locally. If not yet +done, this will trigger the cache backend to go and gather the resources it +needs to access/store data in the cache. This is done in the background, and +so may not be complete by the time the function returns. -Data File Registration -====================== +The *unuse* function indicates that a filesystem has finished using a cookie. +It optionally updates the stored coherency data and object size and then +decreases the in-use counter. When the last user unuses the cookie, it is +scheduled for garbage collection. If not reused within a short time, the +resources will be released to reduce system resource consumption. -The fourth step is to request a data file be created in the cache. This is -identical to index cookie acquisition. The only difference is that the type in -the object definition should be something other than index type:: +A cookie must be marked in-use before it can be accessed for read, write or +resize - and an in-use mark must be kept whilst there is dirty data in the +pagecache in order to avoid an oops due to trying to open a file during process +exit. - vnode->cache = - fscache_acquire_cookie(volume->cache, - &afs_vnode_cache_object_def, - &key, sizeof(key), - &aux, sizeof(aux), - vnode, vnode->status.size, true); +Note that in-use marks are cumulative. For each time a cookie is marked +in-use, it must be unused. -Miscellaneous Object Registration +Resizing A Data File (Truncation) ================================= -An optional step is to request an object of miscellaneous type be created in -the cache. This is almost identical to index cookie acquisition. The only -difference is that the type in the object definition should be something other -than index type. While the parent object could be an index, it's more likely -it would be some other type of object such as a data file:: - - xattr->cache = - fscache_acquire_cookie(vnode->cache, - &afs_xattr_cache_object_def, - &xattr->name, strlen(xattr->name), - NULL, 0, - xattr, strlen(xattr->val), true); - -Miscellaneous objects might be used to store extended attributes or directory -entries for example. - - -Setting the Data File Size -========================== +If a network filesystem file is resized locally by truncation, the following +should be called to notify the cache:: -The fifth step is to set the physical attributes of the file, such as its size. -This doesn't automatically reserve any space in the cache, but permits the -cache to adjust its metadata for data tracking appropriately:: + void fscache_resize_cookie(struct fscache_cookie *cookie, + loff_t new_size); - int fscache_attr_changed(struct fscache_cookie *cookie); +The caller must have first marked the cookie in-use. The cookie and the new +size are passed in and the cache is synchronously resized. This is expected to +be called from ``->setattr()`` inode operation under the inode lock. -The cache will return -ENOBUFS if there is no backing cache or if there is no -space to allocate any extra metadata required in the cache. -Note that attempts to read or write data pages in the cache over this size may -be rebuffed with -ENOBUFS. +Data I/O API +============ -This operation schedules an attribute adjustment to happen asynchronously at -some point in the future, and as such, it may happen after the function returns -to the caller. The attribute adjustment excludes read and write operations. +To do data I/O operations directly through a cookie, the following functions +are available:: + int fscache_begin_read_operation(struct netfs_cache_resources *cres, + struct fscache_cookie *cookie); + int fscache_read(struct netfs_cache_resources *cres, + loff_t start_pos, + struct iov_iter *iter, + enum netfs_read_from_hole read_hole, + netfs_io_terminated_t term_func, + void *term_func_priv); + int fscache_write(struct netfs_cache_resources *cres, + loff_t start_pos, + struct iov_iter *iter, + netfs_io_terminated_t term_func, + void *term_func_priv); -Page alloc/read/write -===================== +The *begin* function sets up an operation, attaching the resources required to +the cache resources block from the cookie. Assuming it doesn't return an error +(for instance, it will return -ENOBUFS if given a NULL cookie, but otherwise do +nothing), then one of the other two functions can be issued. -And the sixth step is to store and retrieve pages in the cache. There are -three functions that are used to do this. +The *read* and *write* functions initiate a direct-IO operation. Both take the +previously set up cache resources block, an indication of the start file +position, and an I/O iterator that describes buffer and indicates the amount of +data. -Note: +The read function also takes a parameter to indicate how it should handle a +partially populated region (a hole) in the disk content. This may be to ignore +it, skip over an initial hole and place zeros in the buffer or give an error. - (1) A page should not be re-read or re-allocated without uncaching it first. - - (2) A read or allocated page must be uncached when the netfs page is released - from the pagecache. - - (3) A page should only be written to the cache if previous read or allocated. - -This permits the cache to maintain its page tracking in proper order. - - -PAGE READ ---------- - -Firstly, the netfs should ask FS-Cache to examine the caches and read the -contents cached for a particular page of a particular file if present, or else -allocate space to store the contents if not:: +The read and write functions can be given an optional termination function that +will be run on completion:: typedef - void (*fscache_rw_complete_t)(struct page *page, - void *context, - int error); - - int fscache_read_or_alloc_page(struct fscache_cookie *cookie, - struct page *page, - fscache_rw_complete_t end_io_func, - void *context, - gfp_t gfp); - -The cookie argument must specify a cookie for an object that isn't an index, -the page specified will have the data loaded into it (and is also used to -specify the page number), and the gfp argument is used to control how any -memory allocations made are satisfied. - -If the cookie indicates the inode is not cached: - - (1) The function will return -ENOBUFS. - -Else if there's a copy of the page resident in the cache: - - (1) The mark_pages_cached() cookie operation will be called on that page. + void (*netfs_io_terminated_t)(void *priv, ssize_t transferred_or_error, + bool was_async); - (2) The function will submit a request to read the data from the cache's - backing device directly into the page specified. +If a termination function is given, the operation will be run asynchronously +and the termination function will be called upon completion. If not given, the +operation will be run synchronously. Note that in the asynchronous case, it is +possible for the operation to complete before the function returns. - (3) The function will return 0. +Both the read and write functions end the operation when they complete, +detaching any pinned resources. - (4) When the read is complete, end_io_func() will be invoked with: +The read operation will fail with ESTALE if invalidation occurred whilst the +operation was ongoing. - * The netfs data supplied when the cookie was created. - * The page descriptor. +Data File Coherency +=================== - * The context argument passed to the above function. This will be - maintained with the get_context/put_context functions mentioned above. - - * An argument that's 0 on success or negative for an error code. - - If an error occurs, it should be assumed that the page contains no usable - data. fscache_readpages_cancel() may need to be called. - - end_io_func() will be called in process context if the read is results in - an error, but it might be called in interrupt context if the read is - successful. - -Otherwise, if there's not a copy available in cache, but the cache may be able -to store the page: - - (1) The mark_pages_cached() cookie operation will be called on that page. - - (2) A block may be reserved in the cache and attached to the object at the - appropriate place. - - (3) The function will return -ENODATA. - -This function may also return -ENOMEM or -EINTR, in which case it won't have -read any data from the cache. - - -Page Allocate -------------- - -Alternatively, if there's not expected to be any data in the cache for a page -because the file has been extended, a block can simply be allocated instead:: - - int fscache_alloc_page(struct fscache_cookie *cookie, - struct page *page, - gfp_t gfp); - -This is similar to the fscache_read_or_alloc_page() function, except that it -never reads from the cache. It will return 0 if a block has been allocated, -rather than -ENODATA as the other would. One or the other must be performed -before writing to the cache. - -The mark_pages_cached() cookie operation will be called on the page if -successful. - - -Page Write ----------- - -Secondly, if the netfs changes the contents of the page (either due to an -initial download or if a user performs a write), then the page should be -written back to the cache:: - - int fscache_write_page(struct fscache_cookie *cookie, - struct page *page, - loff_t object_size, - gfp_t gfp); - -The cookie argument must specify a data file cookie, the page specified should -contain the data to be written (and is also used to specify the page number), -object_size is the revised size of the object and the gfp argument is used to -control how any memory allocations made are satisfied. - -The page must have first been read or allocated successfully and must not have -been uncached before writing is performed. - -If the cookie indicates the inode is not cached then: - - (1) The function will return -ENOBUFS. - -Else if space can be allocated in the cache to hold this page: - - (1) PG_fscache_write will be set on the page. - - (2) The function will submit a request to write the data to cache's backing - device directly from the page specified. - - (3) The function will return 0. - - (4) When the write is complete PG_fscache_write is cleared on the page and - anyone waiting for that bit will be woken up. - -Else if there's no space available in the cache, -ENOBUFS will be returned. It -is also possible for the PG_fscache_write bit to be cleared when no write took -place if unforeseen circumstances arose (such as a disk error). - -Writing takes place asynchronously. - - -Multiple Page Read ------------------- - -A facility is provided to read several pages at once, as requested by the -readpages() address space operation:: - - int fscache_read_or_alloc_pages(struct fscache_cookie *cookie, - struct address_space *mapping, - struct list_head *pages, - int *nr_pages, - fscache_rw_complete_t end_io_func, - void *context, - gfp_t gfp); - -This works in a similar way to fscache_read_or_alloc_page(), except: - - (1) Any page it can retrieve data for is removed from pages and nr_pages and - dispatched for reading to the disk. Reads of adjacent pages on disk may - be merged for greater efficiency. - - (2) The mark_pages_cached() cookie operation will be called on several pages - at once if they're being read or allocated. - - (3) If there was an general error, then that error will be returned. - - Else if some pages couldn't be allocated or read, then -ENOBUFS will be - returned. - - Else if some pages couldn't be read but were allocated, then -ENODATA will - be returned. - - Otherwise, if all pages had reads dispatched, then 0 will be returned, the - list will be empty and ``*nr_pages`` will be 0. - - (4) end_io_func will be called once for each page being read as the reads - complete. It will be called in process context if error != 0, but it may - be called in interrupt context if there is no error. - -Note that a return of -ENODATA, -ENOBUFS or any other error does not preclude -some of the pages being read and some being allocated. Those pages will have -been marked appropriately and will need uncaching. - - -Cancellation of Unread Pages ----------------------------- - -If one or more pages are passed to fscache_read_or_alloc_pages() but not then -read from the cache and also not read from the underlying filesystem then -those pages will need to have any marks and reservations removed. This can be -done by calling:: - - void fscache_readpages_cancel(struct fscache_cookie *cookie, - struct list_head *pages); - -prior to returning to the caller. The cookie argument should be as passed to -fscache_read_or_alloc_pages(). Every page in the pages list will be examined -and any that have PG_fscache set will be uncached. - - -Page Uncaching -============== - -To uncache a page, this function should be called:: - - void fscache_uncache_page(struct fscache_cookie *cookie, - struct page *page); - -This function permits the cache to release any in-memory representation it -might be holding for this netfs page. This function must be called once for -each page on which the read or write page functions above have been called to -make sure the cache's in-memory tracking information gets torn down. - -Note that pages can't be explicitly deleted from the a data file. The whole -data file must be retired (see the relinquish cookie function below). - -Furthermore, note that this does not cancel the asynchronous read or write -operation started by the read/alloc and write functions, so the page -invalidation functions must use:: - - bool fscache_check_page_write(struct fscache_cookie *cookie, - struct page *page); - -to see if a page is being written to the cache, and:: - - void fscache_wait_on_page_write(struct fscache_cookie *cookie, - struct page *page); - -to wait for it to finish if it is. - - -When releasepage() is being implemented, a special FS-Cache function exists to -manage the heuristics of coping with vmscan trying to eject pages, which may -conflict with the cache trying to write pages to the cache (which may itself -need to allocate memory):: - - bool fscache_maybe_release_page(struct fscache_cookie *cookie, - struct page *page, - gfp_t gfp); - -This takes the netfs cookie, and the page and gfp arguments as supplied to -releasepage(). It will return false if the page cannot be released yet for -some reason and if it returns true, the page has been uncached and can now be -released. - -To make a page available for release, this function may wait for an outstanding -storage request to complete, or it may attempt to cancel the storage request - -in which case the page will not be stored in the cache this time. - - -Bulk Image Page Uncache ------------------------ - -A convenience routine is provided to perform an uncache on all the pages -attached to an inode. This assumes that the pages on the inode correspond on a -1:1 basis with the pages in the cache:: - - void fscache_uncache_all_inode_pages(struct fscache_cookie *cookie, - struct inode *inode); - -This takes the netfs cookie that the pages were cached with and the inode that -the pages are attached to. This function will wait for pages to finish being -written to the cache and for the cache to finish with the page generally. No -error is returned. - - -Index and Data File consistency -=============================== - -To find out whether auxiliary data for an object is up to data within the -cache, the following function can be called:: - - int fscache_check_consistency(struct fscache_cookie *cookie, - const void *aux_data); - -This will call back to the netfs to check whether the auxiliary data associated -with a cookie is correct; if aux_data is non-NULL, it will update the auxiliary -data buffer first. It returns 0 if it is and -ESTALE if it isn't; it may also -return -ENOMEM and -ERESTARTSYS. - -To request an update of the index data for an index or other object, the -following function should be called:: +To request an update of the coherency data and file size on a cookie, the +following should be called:: void fscache_update_cookie(struct fscache_cookie *cookie, - const void *aux_data); - -This function will update the cookie's auxiliary data buffer from aux_data if -that is non-NULL and then schedule this to be stored on disk. The update -method in the parent index definition will be called to transfer the data. - -Note that partial updates may happen automatically at other times, such as when -data blocks are added to a data file object. - - -Cookie Enablement -================= - -Cookies exist in one of two states: enabled and disabled. If a cookie is -disabled, it ignores all attempts to acquire child cookies; check, update or -invalidate its state; allocate, read or write backing pages - though it is -still possible to uncache pages and relinquish the cookie. - -The initial enablement state is set by fscache_acquire_cookie(), but the cookie -can be enabled or disabled later. To disable a cookie, call:: - - void fscache_disable_cookie(struct fscache_cookie *cookie, - const void *aux_data, - bool invalidate); - -If the cookie is not already disabled, this locks the cookie against other -enable and disable ops, marks the cookie as being disabled, discards or -invalidates any backing objects and waits for cessation of activity on any -associated object before unlocking the cookie. - -All possible failures are handled internally. The caller should consider -calling fscache_uncache_all_inode_pages() afterwards to make sure all page -markings are cleared up. - -Cookies can be enabled or reenabled with:: - - void fscache_enable_cookie(struct fscache_cookie *cookie, const void *aux_data, - loff_t object_size, - bool (*can_enable)(void *data), - void *data) - -If the cookie is not already enabled, this locks the cookie against other -enable and disable ops, invokes can_enable() and, if the cookie is not an index -cookie, will begin the procedure of acquiring backing objects. - -The optional can_enable() function is passed the data argument and returns a -ruling as to whether or not enablement should actually be permitted to begin. + const loff_t *object_size); -All possible failures are handled internally. The cookie will only be marked -as enabled if provisional backing objects are allocated. +This will update the cookie's coherency data and/or file size. -The object's data size is updated from object_size and is passed to the -->check_aux() function. -In both cases, the cookie's auxiliary data buffer is updated from aux_data if -that is non-NULL inside the enablement lock before proceeding. - - -Miscellaneous Cookie operations -=============================== +Data File Invalidation +====================== -There are a number of operations that can be used to control cookies: +Sometimes it will be necessary to invalidate an object that contains data. +Typically this will be necessary when the server informs the network filesystem +of a remote third-party change - at which point the filesystem has to throw +away the state and cached data that it had for an file and reload from the +server. - * Cookie pinning:: +To indicate that a cache object should be invalidated, the following should be +called:: - int fscache_pin_cookie(struct fscache_cookie *cookie); - void fscache_unpin_cookie(struct fscache_cookie *cookie); + void fscache_invalidate(struct fscache_cookie *cookie, + const void *aux_data, + loff_t size, + unsigned int flags); - These operations permit data cookies to be pinned into the cache and to - have the pinning removed. They are not permitted on index cookies. +This increases the invalidation counter in the cookie to cause outstanding +reads to fail with -ESTALE, sets the coherency data and file size from the +information supplied, blocks new I/O on the cookie and dispatches the cache to +go and get rid of the old data. - The pinning function will return 0 if successful, -ENOBUFS in the cookie - isn't backed by a cache, -EOPNOTSUPP if the cache doesn't support pinning, - -ENOSPC if there isn't enough space to honour the operation, -ENOMEM or - -EIO if there's any other problem. +Invalidation runs asynchronously in a worker thread so that it doesn't block +too much. - * Data space reservation:: - int fscache_reserve_space(struct fscache_cookie *cookie, loff_t size); +Write-Back Resource Management +============================== - This permits a netfs to request cache space be reserved to store up to the - given amount of a file. It is permitted to ask for more than the current - size of the file to allow for future file expansion. +To write data to the cache from network filesystem writeback, the cache +resources required need to be pinned at the point the modification is made (for +instance when the page is marked dirty) as it's not possible to open a file in +a thread that's exiting. - If size is given as zero then the reservation will be cancelled. +The following facilities are provided to manage this: - The function will return 0 if successful, -ENOBUFS in the cookie isn't - backed by a cache, -EOPNOTSUPP if the cache doesn't support reservations, - -ENOSPC if there isn't enough space to honour the operation, -ENOMEM or - -EIO if there's any other problem. + * An inode flag, ``I_PINNING_FSCACHE_WB``, is provided to indicate that an + in-use is held on the cookie for this inode. It can only be changed if the + the inode lock is held. - Note that this doesn't pin an object in a cache; it can still be culled to - make space if it's not in use. + * A flag, ``unpinned_fscache_wb`` is placed in the ``writeback_control`` + struct that gets set if ``__writeback_single_inode()`` clears + ``I_PINNING_FSCACHE_WB`` because all the dirty pages were cleared. +To support this, the following functions are provided:: -Cookie Unregistration -===================== + int fscache_set_page_dirty(struct page *page, + struct fscache_cookie *cookie); + void fscache_unpin_writeback(struct writeback_control *wbc, + struct fscache_cookie *cookie); + void fscache_clear_inode_writeback(struct fscache_cookie *cookie, + struct inode *inode, + const void *aux); -To get rid of a cookie, this function should be called:: +The *set* function is intended to be called from the filesystem's +``set_page_dirty`` address space operation. If ``I_PINNING_FSCACHE_WB`` is not +set, it sets that flag and increments the use count on the cookie (the caller +must already have called ``fscache_use_cookie()``). - void fscache_relinquish_cookie(struct fscache_cookie *cookie, - const void *aux_data, - bool retire); +The *unpin* function is intended to be called from the filesystem's +``write_inode`` superblock operation. It cleans up after writing by unusing +the cookie if unpinned_fscache_wb is set in the writeback_control struct. -If retire is non-zero, then the object will be marked for recycling, and all -copies of it will be removed from all active caches in which it is present. -Not only that but all child objects will also be retired. +The *clear* function is intended to be called from the netfs's ``evict_inode`` +superblock operation. It must be called *after* +``truncate_inode_pages_final()``, but *before* ``clear_inode()``. This cleans +up any hanging ``I_PINNING_FSCACHE_WB``. It also allows the coherency data to +be updated. -If retire is zero, then the object may be available again when next the -acquisition function is called. Retirement here will overrule the pinning on a -cookie. -The cookie's auxiliary data will be updated from aux_data if that is non-NULL -so that the cache can lazily update it on disk. +Caching of Local Modifications +============================== -One very important note - relinquish must NOT be called for a cookie unless all -the cookies for "child" indices, objects and pages have been relinquished -first. +If a network filesystem has locally modified data that it wants to write to the +cache, it needs to mark the pages to indicate that a write is in progress, and +if the mark is already present, it needs to wait for it to be removed first +(presumably due to an already in-progress operation). This prevents multiple +competing DIO writes to the same storage in the cache. +Firstly, the netfs should determine if caching is available by doing something +like:: -Index Invalidation -================== + bool caching = fscache_cookie_enabled(cookie); -There is no direct way to invalidate an index subtree. To do this, the caller -should relinquish and retire the cookie they have, and then acquire a new one. +If caching is to be attempted, pages should be waited for and then marked using +the following functions provided by the netfs helper library:: + void set_page_fscache(struct page *page); + void wait_on_page_fscache(struct page *page); + int wait_on_page_fscache_killable(struct page *page); -Data File Invalidation -====================== +Once all the pages in the span are marked, the netfs can ask fscache to +schedule a write of that region:: -Sometimes it will be necessary to invalidate an object that contains data. -Typically this will be necessary when the server tells the netfs of a foreign -change - at which point the netfs has to throw away all the state it had for an -inode and reload from the server. + void fscache_write_to_cache(struct fscache_cookie *cookie, + struct address_space *mapping, + loff_t start, size_t len, loff_t i_size, + netfs_io_terminated_t term_func, + void *term_func_priv, + bool caching) -To indicate that a cache object should be invalidated, the following function -can be called:: +And if an error occurs before that point is reached, the marks can be removed +by calling:: - void fscache_invalidate(struct fscache_cookie *cookie); + void fscache_clear_page_bits(struct fscache_cookie *cookie, + struct address_space *mapping, + loff_t start, size_t len, + bool caching) -This can be called with spinlocks held as it defers the work to a thread pool. -All extant storage, retrieval and attribute change ops at this point are -cancelled and discarded. Some future operations will be rejected until the -cache has had a chance to insert a barrier in the operations queue. After -that, operations will be queued again behind the invalidation operation. +In both of these functions, the cookie representing the cache object to be +written to and a pointer to the mapping to which the source pages are attached +are passed in; start and len indicate the size of the region that's going to be +written (it doesn't have to align to page boundaries necessarily, but it does +have to align to DIO boundaries on the backing filesystem). The caching +parameter indicates if caching should be skipped, and if false, the functions +do nothing. -The invalidation operation will perform an attribute change operation and an -auxiliary data update operation as it is very likely these will have changed. +The write function takes some additional parameters: i_size indicates the size +of the netfs file and term_func indicates an optional completion function, to +which term_func_priv will be passed, along with the error or amount written. -Using the following function, the netfs can wait for the invalidation operation -to have reached a point at which it can start submitting ordinary operations -once again:: +Note that the write function will always run asynchronously and will unmark all +the pages upon completion before calling term_func. - void fscache_wait_on_invalidate(struct fscache_cookie *cookie); +Page Release and Invalidation +============================= -FS-cache Specific Page Flag -=========================== +Fscache keeps track of whether we have any data in the cache yet for a cache +object we've just created. It knows it doesn't have to do any reading until it +has done a write and then the page it wrote from has been released by the VM, +after which it *has* to look in the cache. -FS-Cache makes use of a page flag, PG_private_2, for its own purpose. This is -given the alternative name PG_fscache. +To inform fscache that a page might now be in the cache, the following function +should be called from the ``releasepage`` address space op:: -PG_fscache is used to indicate that the page is known by the cache, and that -the cache must be informed if the page is going to go away. It's an indication -to the netfs that the cache has an interest in this page, where an interest may -be a pointer to it, resources allocated or reserved for it, or I/O in progress -upon it. + void fscache_note_page_release(struct fscache_cookie *cookie); -The netfs can use this information in methods such as releasepage() to -determine whether it needs to uncache a page or update it. +if the page has been released (ie. releasepage returned true). -Furthermore, if this bit is set, releasepage() and invalidatepage() operations -will be called on a page to get rid of it, even if PG_private is not set. This -allows caching to attempted on a page before read_cache_pages() to be called -after fscache_read_or_alloc_pages() as the former will try and release pages it -was given under certain circumstances. +Page release and page invalidation should also wait for any mark left on the +page to say that a DIO write is underway from that page:: -This bit does not overlap with such as PG_private. This means that FS-Cache -can be used with a filesystem that uses the block buffering code. + void wait_on_page_fscache(struct page *page); + int wait_on_page_fscache_killable(struct page *page); -There are a number of operations defined on this flag:: - int PageFsCache(struct page *page); - void SetPageFsCache(struct page *page) - void ClearPageFsCache(struct page *page) - int TestSetPageFsCache(struct page *page) - int TestClearPageFsCache(struct page *page) +API Function Reference +====================== -These functions are bit test, bit set, bit clear, bit test and set and bit -test and clear operations on PG_fscache. +.. kernel-doc:: include/linux/fscache.h diff --git a/Documentation/filesystems/caching/object.rst b/Documentation/filesystems/caching/object.rst deleted file mode 100644 index ce0e043ccd33..000000000000 --- a/Documentation/filesystems/caching/object.rst +++ /dev/null @@ -1,313 +0,0 @@ -.. SPDX-License-Identifier: GPL-2.0 - -==================================================== -In-Kernel Cache Object Representation and Management -==================================================== - -By: David Howells <dhowells@redhat.com> - -.. Contents: - - (*) Representation - - (*) Object management state machine. - - - Provision of cpu time. - - Locking simplification. - - (*) The set of states. - - (*) The set of events. - - -Representation -============== - -FS-Cache maintains an in-kernel representation of each object that a netfs is -currently interested in. Such objects are represented by the fscache_cookie -struct and are referred to as cookies. - -FS-Cache also maintains a separate in-kernel representation of the objects that -a cache backend is currently actively caching. Such objects are represented by -the fscache_object struct. The cache backends allocate these upon request, and -are expected to embed them in their own representations. These are referred to -as objects. - -There is a 1:N relationship between cookies and objects. A cookie may be -represented by multiple objects - an index may exist in more than one cache - -or even by no objects (it may not be cached). - -Furthermore, both cookies and objects are hierarchical. The two hierarchies -correspond, but the cookies tree is a superset of the union of the object trees -of multiple caches:: - - NETFS INDEX TREE : CACHE 1 : CACHE 2 - : : - : +-----------+ : - +----------->| IObject | : - +-----------+ | : +-----------+ : - | ICookie |-------+ : | : - +-----------+ | : | : +-----------+ - | +------------------------------>| IObject | - | : | : +-----------+ - | : V : | - | : +-----------+ : | - V +----------->| IObject | : | - +-----------+ | : +-----------+ : | - | ICookie |-------+ : | : V - +-----------+ | : | : +-----------+ - | +------------------------------>| IObject | - +-----+-----+ : | : +-----------+ - | | : | : | - V | : V : | - +-----------+ | : +-----------+ : | - | ICookie |------------------------->| IObject | : | - +-----------+ | : +-----------+ : | - | V : | : V - | +-----------+ : | : +-----------+ - | | ICookie |-------------------------------->| IObject | - | +-----------+ : | : +-----------+ - V | : V : | - +-----------+ | : +-----------+ : | - | DCookie |------------------------->| DObject | : | - +-----------+ | : +-----------+ : | - | : : | - +-------+-------+ : : | - | | : : | - V V : : V - +-----------+ +-----------+ : : +-----------+ - | DCookie | | DCookie |------------------------>| DObject | - +-----------+ +-----------+ : : +-----------+ - : : - -In the above illustration, ICookie and IObject represent indices and DCookie -and DObject represent data storage objects. Indices may have representation in -multiple caches, but currently, non-index objects may not. Objects of any type -may also be entirely unrepresented. - -As far as the netfs API goes, the netfs is only actually permitted to see -pointers to the cookies. The cookies themselves and any objects attached to -those cookies are hidden from it. - - -Object Management State Machine -=============================== - -Within FS-Cache, each active object is managed by its own individual state -machine. The state for an object is kept in the fscache_object struct, in -object->state. A cookie may point to a set of objects that are in different -states. - -Each state has an action associated with it that is invoked when the machine -wakes up in that state. There are four logical sets of states: - - (1) Preparation: states that wait for the parent objects to become ready. The - representations are hierarchical, and it is expected that an object must - be created or accessed with respect to its parent object. - - (2) Initialisation: states that perform lookups in the cache and validate - what's found and that create on disk any missing metadata. - - (3) Normal running: states that allow netfs operations on objects to proceed - and that update the state of objects. - - (4) Termination: states that detach objects from their netfs cookies, that - delete objects from disk, that handle disk and system errors and that free - up in-memory resources. - - -In most cases, transitioning between states is in response to signalled events. -When a state has finished processing, it will usually set the mask of events in -which it is interested (object->event_mask) and relinquish the worker thread. -Then when an event is raised (by calling fscache_raise_event()), if the event -is not masked, the object will be queued for processing (by calling -fscache_enqueue_object()). - - -Provision of CPU Time ---------------------- - -The work to be done by the various states was given CPU time by the threads of -the slow work facility. This was used in preference to the workqueue facility -because: - - (1) Threads may be completely occupied for very long periods of time by a - particular work item. These state actions may be doing sequences of - synchronous, journalled disk accesses (lookup, mkdir, create, setxattr, - getxattr, truncate, unlink, rmdir, rename). - - (2) Threads may do little actual work, but may rather spend a lot of time - sleeping on I/O. This means that single-threaded and 1-per-CPU-threaded - workqueues don't necessarily have the right numbers of threads. - - -Locking Simplification ----------------------- - -Because only one worker thread may be operating on any particular object's -state machine at once, this simplifies the locking, particularly with respect -to disconnecting the netfs's representation of a cache object (fscache_cookie) -from the cache backend's representation (fscache_object) - which may be -requested from either end. - - -The Set of States -================= - -The object state machine has a set of states that it can be in. There are -preparation states in which the object sets itself up and waits for its parent -object to transit to a state that allows access to its children: - - (1) State FSCACHE_OBJECT_INIT. - - Initialise the object and wait for the parent object to become active. In - the cache, it is expected that it will not be possible to look an object - up from the parent object, until that parent object itself has been looked - up. - -There are initialisation states in which the object sets itself up and accesses -disk for the object metadata: - - (2) State FSCACHE_OBJECT_LOOKING_UP. - - Look up the object on disk, using the parent as a starting point. - FS-Cache expects the cache backend to probe the cache to see whether this - object is represented there, and if it is, to see if it's valid (coherency - management). - - The cache should call fscache_object_lookup_negative() to indicate lookup - failure for whatever reason, and should call fscache_obtained_object() to - indicate success. - - At the completion of lookup, FS-Cache will let the netfs go ahead with - read operations, no matter whether the file is yet cached. If not yet - cached, read operations will be immediately rejected with ENODATA until - the first known page is uncached - as to that point there can be no data - to be read out of the cache for that file that isn't currently also held - in the pagecache. - - (3) State FSCACHE_OBJECT_CREATING. - - Create an object on disk, using the parent as a starting point. This - happens if the lookup failed to find the object, or if the object's - coherency data indicated what's on disk is out of date. In this state, - FS-Cache expects the cache to create - - The cache should call fscache_obtained_object() if creation completes - successfully, fscache_object_lookup_negative() otherwise. - - At the completion of creation, FS-Cache will start processing write - operations the netfs has queued for an object. If creation failed, the - write ops will be transparently discarded, and nothing recorded in the - cache. - -There are some normal running states in which the object spends its time -servicing netfs requests: - - (4) State FSCACHE_OBJECT_AVAILABLE. - - A transient state in which pending operations are started, child objects - are permitted to advance from FSCACHE_OBJECT_INIT state, and temporary - lookup data is freed. - - (5) State FSCACHE_OBJECT_ACTIVE. - - The normal running state. In this state, requests the netfs makes will be - passed on to the cache. - - (6) State FSCACHE_OBJECT_INVALIDATING. - - The object is undergoing invalidation. When the state comes here, it - discards all pending read, write and attribute change operations as it is - going to clear out the cache entirely and reinitialise it. It will then - continue to the FSCACHE_OBJECT_UPDATING state. - - (7) State FSCACHE_OBJECT_UPDATING. - - The state machine comes here to update the object in the cache from the - netfs's records. This involves updating the auxiliary data that is used - to maintain coherency. - -And there are terminal states in which an object cleans itself up, deallocates -memory and potentially deletes stuff from disk: - - (8) State FSCACHE_OBJECT_LC_DYING. - - The object comes here if it is dying because of a lookup or creation - error. This would be due to a disk error or system error of some sort. - Temporary data is cleaned up, and the parent is released. - - (9) State FSCACHE_OBJECT_DYING. - - The object comes here if it is dying due to an error, because its parent - cookie has been relinquished by the netfs or because the cache is being - withdrawn. - - Any child objects waiting on this one are given CPU time so that they too - can destroy themselves. This object waits for all its children to go away - before advancing to the next state. - -(10) State FSCACHE_OBJECT_ABORT_INIT. - - The object comes to this state if it was waiting on its parent in - FSCACHE_OBJECT_INIT, but its parent died. The object will destroy itself - so that the parent may proceed from the FSCACHE_OBJECT_DYING state. - -(11) State FSCACHE_OBJECT_RELEASING. -(12) State FSCACHE_OBJECT_RECYCLING. - - The object comes to one of these two states when dying once it is rid of - all its children, if it is dying because the netfs relinquished its - cookie. In the first state, the cached data is expected to persist, and - in the second it will be deleted. - -(13) State FSCACHE_OBJECT_WITHDRAWING. - - The object transits to this state if the cache decides it wants to - withdraw the object from service, perhaps to make space, but also due to - error or just because the whole cache is being withdrawn. - -(14) State FSCACHE_OBJECT_DEAD. - - The object transits to this state when the in-memory object record is - ready to be deleted. The object processor shouldn't ever see an object in - this state. - - -The Set of Events ------------------ - -There are a number of events that can be raised to an object state machine: - - FSCACHE_OBJECT_EV_UPDATE - The netfs requested that an object be updated. The state machine will ask - the cache backend to update the object, and the cache backend will ask the - netfs for details of the change through its cookie definition ops. - - FSCACHE_OBJECT_EV_CLEARED - This is signalled in two circumstances: - - (a) when an object's last child object is dropped and - - (b) when the last operation outstanding on an object is completed. - - This is used to proceed from the dying state. - - FSCACHE_OBJECT_EV_ERROR - This is signalled when an I/O error occurs during the processing of some - object. - - FSCACHE_OBJECT_EV_RELEASE, FSCACHE_OBJECT_EV_RETIRE - These are signalled when the netfs relinquishes a cookie it was using. - The event selected depends on whether the netfs asks for the backing - object to be retired (deleted) or retained. - - FSCACHE_OBJECT_EV_WITHDRAW - This is signalled when the cache backend wants to withdraw an object. - This means that the object will have to be detached from the netfs's - cookie. - -Because the withdrawing releasing/retiring events are all handled by the object -state machine, it doesn't matter if there's a collision with both ends trying -to sever the connection at the same time. The state machine can just pick -which one it wants to honour, and that effects the other. diff --git a/Documentation/filesystems/caching/operations.rst b/Documentation/filesystems/caching/operations.rst deleted file mode 100644 index 9983e1675447..000000000000 --- a/Documentation/filesystems/caching/operations.rst +++ /dev/null @@ -1,210 +0,0 @@ -.. SPDX-License-Identifier: GPL-2.0 - -================================ -Asynchronous Operations Handling -================================ - -By: David Howells <dhowells@redhat.com> - -.. Contents: - - (*) Overview. - - (*) Operation record initialisation. - - (*) Parameters. - - (*) Procedure. - - (*) Asynchronous callback. - - -Overview -======== - -FS-Cache has an asynchronous operations handling facility that it uses for its -data storage and retrieval routines. Its operations are represented by -fscache_operation structs, though these are usually embedded into some other -structure. - -This facility is available to and expected to be used by the cache backends, -and FS-Cache will create operations and pass them off to the appropriate cache -backend for completion. - -To make use of this facility, <linux/fscache-cache.h> should be #included. - - -Operation Record Initialisation -=============================== - -An operation is recorded in an fscache_operation struct:: - - struct fscache_operation { - union { - struct work_struct fast_work; - struct slow_work slow_work; - }; - unsigned long flags; - fscache_operation_processor_t processor; - ... - }; - -Someone wanting to issue an operation should allocate something with this -struct embedded in it. They should initialise it by calling:: - - void fscache_operation_init(struct fscache_operation *op, - fscache_operation_release_t release); - -with the operation to be initialised and the release function to use. - -The op->flags parameter should be set to indicate the CPU time provision and -the exclusivity (see the Parameters section). - -The op->fast_work, op->slow_work and op->processor flags should be set as -appropriate for the CPU time provision (see the Parameters section). - -FSCACHE_OP_WAITING may be set in op->flags prior to each submission of the -operation and waited for afterwards. - - -Parameters -========== - -There are a number of parameters that can be set in the operation record's flag -parameter. There are three options for the provision of CPU time in these -operations: - - (1) The operation may be done synchronously (FSCACHE_OP_MYTHREAD). A thread - may decide it wants to handle an operation itself without deferring it to - another thread. - - This is, for example, used in read operations for calling readpages() on - the backing filesystem in CacheFiles. Although readpages() does an - asynchronous data fetch, the determination of whether pages exist is done - synchronously - and the netfs does not proceed until this has been - determined. - - If this option is to be used, FSCACHE_OP_WAITING must be set in op->flags - before submitting the operation, and the operating thread must wait for it - to be cleared before proceeding:: - - wait_on_bit(&op->flags, FSCACHE_OP_WAITING, - TASK_UNINTERRUPTIBLE); - - - (2) The operation may be fast asynchronous (FSCACHE_OP_FAST), in which case it - will be given to keventd to process. Such an operation is not permitted - to sleep on I/O. - - This is, for example, used by CacheFiles to copy data from a backing fs - page to a netfs page after the backing fs has read the page in. - - If this option is used, op->fast_work and op->processor must be - initialised before submitting the operation:: - - INIT_WORK(&op->fast_work, do_some_work); - - - (3) The operation may be slow asynchronous (FSCACHE_OP_SLOW), in which case it - will be given to the slow work facility to process. Such an operation is - permitted to sleep on I/O. - - This is, for example, used by FS-Cache to handle background writes of - pages that have just been fetched from a remote server. - - If this option is used, op->slow_work and op->processor must be - initialised before submitting the operation:: - - fscache_operation_init_slow(op, processor) - - -Furthermore, operations may be one of two types: - - (1) Exclusive (FSCACHE_OP_EXCLUSIVE). Operations of this type may not run in - conjunction with any other operation on the object being operated upon. - - An example of this is the attribute change operation, in which the file - being written to may need truncation. - - (2) Shareable. Operations of this type may be running simultaneously. It's - up to the operation implementation to prevent interference between other - operations running at the same time. - - -Procedure -========= - -Operations are used through the following procedure: - - (1) The submitting thread must allocate the operation and initialise it - itself. Normally this would be part of a more specific structure with the - generic op embedded within. - - (2) The submitting thread must then submit the operation for processing using - one of the following two functions:: - - int fscache_submit_op(struct fscache_object *object, - struct fscache_operation *op); - - int fscache_submit_exclusive_op(struct fscache_object *object, - struct fscache_operation *op); - - The first function should be used to submit non-exclusive ops and the - second to submit exclusive ones. The caller must still set the - FSCACHE_OP_EXCLUSIVE flag. - - If successful, both functions will assign the operation to the specified - object and return 0. -ENOBUFS will be returned if the object specified is - permanently unavailable. - - The operation manager will defer operations on an object that is still - undergoing lookup or creation. The operation will also be deferred if an - operation of conflicting exclusivity is in progress on the object. - - If the operation is asynchronous, the manager will retain a reference to - it, so the caller should put their reference to it by passing it to:: - - void fscache_put_operation(struct fscache_operation *op); - - (3) If the submitting thread wants to do the work itself, and has marked the - operation with FSCACHE_OP_MYTHREAD, then it should monitor - FSCACHE_OP_WAITING as described above and check the state of the object if - necessary (the object might have died while the thread was waiting). - - When it has finished doing its processing, it should call - fscache_op_complete() and fscache_put_operation() on it. - - (4) The operation holds an effective lock upon the object, preventing other - exclusive ops conflicting until it is released. The operation can be - enqueued for further immediate asynchronous processing by adjusting the - CPU time provisioning option if necessary, eg:: - - op->flags &= ~FSCACHE_OP_TYPE; - op->flags |= ~FSCACHE_OP_FAST; - - and calling:: - - void fscache_enqueue_operation(struct fscache_operation *op) - - This can be used to allow other things to have use of the worker thread - pools. - - -Asynchronous Callback -===================== - -When used in asynchronous mode, the worker thread pool will invoke the -processor method with a pointer to the operation. This should then get at the -container struct by using container_of():: - - static void fscache_write_op(struct fscache_operation *_op) - { - struct fscache_storage *op = - container_of(_op, struct fscache_storage, op); - ... - } - -The caller holds a reference on the operation, and will invoke -fscache_put_operation() when the processor function returns. The processor -function is at liberty to call fscache_enqueue_operation() or to take extra -references. diff --git a/Documentation/filesystems/ceph.rst b/Documentation/filesystems/ceph.rst index 7d2ef4e27273..4942e018db85 100644 --- a/Documentation/filesystems/ceph.rst +++ b/Documentation/filesystems/ceph.rst @@ -82,7 +82,7 @@ Mount Syntax The basic mount syntax is:: - # mount -t ceph monip[:port][,monip2[:port]...]:/[subdir] mnt + # mount -t ceph user@fsid.fs_name=/[subdir] mnt -o mon_addr=monip1[:port][/monip2[:port]] You only need to specify a single monitor, as the client will get the full list when it connects. (However, if the monitor you specify @@ -90,16 +90,35 @@ happens to be down, the mount won't succeed.) The port can be left off if the monitor is using the default. So if the monitor is at 1.2.3.4:: - # mount -t ceph 1.2.3.4:/ /mnt/ceph + # mount -t ceph cephuser@07fe3187-00d9-42a3-814b-72a4d5e7d5be.cephfs=/ /mnt/ceph -o mon_addr=1.2.3.4 is sufficient. If /sbin/mount.ceph is installed, a hostname can be -used instead of an IP address. +used instead of an IP address and the cluster FSID can be left out +(as the mount helper will fill it in by reading the ceph configuration +file):: + # mount -t ceph cephuser@cephfs=/ /mnt/ceph -o mon_addr=mon-addr +Multiple monitor addresses can be passed by separating each address with a slash (`/`):: + + # mount -t ceph cephuser@cephfs=/ /mnt/ceph -o mon_addr=192.168.1.100/192.168.1.101 + +When using the mount helper, monitor address can be read from ceph +configuration file if available. Note that, the cluster FSID (passed as part +of the device string) is validated by checking it with the FSID reported by +the monitor. Mount Options ============= + mon_addr=ip_address[:port][/ip_address[:port]] + Monitor address to the cluster. This is used to bootstrap the + connection to the cluster. Once connection is established, the + monitor addresses in the monitor map are followed. + + fsid=cluster-id + FSID of the cluster (from `ceph fsid` command). + ip=A.B.C.D[:N] Specify the IP and/or port the client should bind to locally. There is normally not much reason to do this. If the IP is not diff --git a/Documentation/filesystems/cifs/ksmbd.rst b/Documentation/filesystems/cifs/ksmbd.rst index a1326157d53f..b0d354fd8066 100644 --- a/Documentation/filesystems/cifs/ksmbd.rst +++ b/Documentation/filesystems/cifs/ksmbd.rst @@ -50,11 +50,11 @@ ksmbd.mountd (user space daemon) -------------------------------- ksmbd.mountd is userspace process to, transfer user account and password that -are registered using ksmbd.adduser(part of utils for user space). Further it +are registered using ksmbd.adduser (part of utils for user space). Further it allows sharing information parameters that parsed from smb.conf to ksmbd in kernel. For the execution part it has a daemon which is continuously running and connected to the kernel interface using netlink socket, it waits for the -requests(dcerpc and share/user info). It handles RPC calls (at a minimum few +requests (dcerpc and share/user info). It handles RPC calls (at a minimum few dozen) that are most important for file server from NetShareEnum and NetServerGetInfo. Complete DCE/RPC response is prepared from the user space and passed over to the associated kernel thread for the client. @@ -154,11 +154,11 @@ Each layer 1. Enable all component prints # sudo ksmbd.control -d "all" -2. Enable one of components(smb, auth, vfs, oplock, ipc, conn, rdma) +2. Enable one of components (smb, auth, vfs, oplock, ipc, conn, rdma) # sudo ksmbd.control -d "smb" -3. Show what prints are enable. - # cat/sys/class/ksmbd-control/debug +3. Show what prints are enabled. + # cat /sys/class/ksmbd-control/debug [smb] auth vfs oplock ipc conn [rdma] 4. Disable prints: diff --git a/Documentation/filesystems/dax.rst b/Documentation/filesystems/dax.rst index 9a1b8fd9e82b..e3b30429d703 100644 --- a/Documentation/filesystems/dax.rst +++ b/Documentation/filesystems/dax.rst @@ -23,8 +23,8 @@ on it as usual. The `DAX` code currently only supports files with a block size equal to your kernel's `PAGE_SIZE`, so you may need to specify a block size when creating the filesystem. -Currently 3 filesystems support `DAX`: ext2, ext4 and xfs. Enabling `DAX` on them -is different. +Currently 4 filesystems support `DAX`: ext2, ext4, xfs and virtiofs. +Enabling `DAX` on them is different. Enabling DAX on ext2 -------------------- @@ -168,6 +168,22 @@ if the underlying media does not support dax and/or the filesystem is overridden with a mount option. +Enabling DAX on virtiofs +---------------------------- +The semantic of DAX on virtiofs is basically equal to that on ext4 and xfs, +except that when '-o dax=inode' is specified, virtiofs client derives the hint +whether DAX shall be enabled or not from virtiofs server through FUSE protocol, +rather than the persistent `FS_XFLAG_DAX` flag. That is, whether DAX shall be +enabled or not is completely determined by virtiofs server, while virtiofs +server itself may deploy various algorithm making this decision, e.g. depending +on the persistent `FS_XFLAG_DAX` flag on the host. + +It is still supported to set or clear persistent `FS_XFLAG_DAX` flag inside +guest, but it is not guaranteed that DAX will be enabled or disabled for +corresponding file then. Users inside guest still need to call statx(2) and +check the statx flag `STATX_ATTR_DAX` to see if DAX is enabled for this file. + + Implementation Tips for Block Driver Writers -------------------------------------------- diff --git a/Documentation/filesystems/erofs.rst b/Documentation/filesystems/erofs.rst index 01df283c7d04..7119aa213be7 100644 --- a/Documentation/filesystems/erofs.rst +++ b/Documentation/filesystems/erofs.rst @@ -93,6 +93,14 @@ dax A legacy option which is an alias for ``dax=always``. device=%s Specify a path to an extra device to be used together. =================== ========================================================= +Sysfs Entries +============= + +Information about mounted erofs file systems can be found in /sys/fs/erofs. +Each mounted filesystem will have a directory in /sys/fs/erofs based on its +device name (i.e., /sys/fs/erofs/sda). +(see also Documentation/ABI/testing/sysfs-fs-erofs) + On-disk details =============== diff --git a/Documentation/filesystems/f2fs.rst b/Documentation/filesystems/f2fs.rst index d7b84695f56a..4a2426f0485a 100644 --- a/Documentation/filesystems/f2fs.rst +++ b/Documentation/filesystems/f2fs.rst @@ -198,6 +198,7 @@ fault_type=%d Support configuring fault injection type, should be FAULT_WRITE_IO 0x000004000 FAULT_SLAB_ALLOC 0x000008000 FAULT_DQUOT_INIT 0x000010000 + FAULT_LOCK_OP 0x000020000 =================== =========== mode=%s Control block allocation mode which supports "adaptive" and "lfs". In "lfs" mode, there should be no random diff --git a/Documentation/filesystems/idmappings.rst b/Documentation/filesystems/idmappings.rst index 1229a75ec75d..7a879ec3b6bf 100644 --- a/Documentation/filesystems/idmappings.rst +++ b/Documentation/filesystems/idmappings.rst @@ -952,75 +952,3 @@ The raw userspace id that is put on disk is ``u1000`` so when the user takes their home directory back to their home computer where they are assigned ``u1000`` using the initial idmapping and mount the filesystem with the initial idmapping they will see all those files owned by ``u1000``. - -Shortcircuting --------------- - -Currently, the implementation of idmapped mounts enforces that the filesystem -is mounted with the initial idmapping. The reason is simply that none of the -filesystems that we targeted were mountable with a non-initial idmapping. But -that might change soon enough. As we've seen above, thanks to the properties of -idmappings the translation works for both filesystems mounted with the initial -idmapping and filesystem with non-initial idmappings. - -Based on this current restriction to filesystem mounted with the initial -idmapping two noticeable shortcuts have been taken: - -1. We always stash a reference to the initial user namespace in ``struct - vfsmount``. Idmapped mounts are thus mounts that have a non-initial user - namespace attached to them. - - In order to support idmapped mounts this needs to be changed. Instead of - stashing the initial user namespace the user namespace the filesystem was - mounted with must be stashed. An idmapped mount is then any mount that has - a different user namespace attached then the filesystem was mounted with. - This has no user-visible consequences. - -2. The translation algorithms in ``mapped_fs*id()`` and ``i_*id_into_mnt()`` - are simplified. - - Let's consider ``mapped_fs*id()`` first. This function translates the - caller's kernel id into a kernel id in the filesystem's idmapping via - a mount's idmapping. The full algorithm is:: - - mapped_fsuid(kid): - /* Map the kernel id up into a userspace id in the mount's idmapping. */ - from_kuid(mount-idmapping, kid) = uid - - /* Map the userspace id down into a kernel id in the filesystem's idmapping. */ - make_kuid(filesystem-idmapping, uid) = kuid - - We know that the filesystem is always mounted with the initial idmapping as - we enforce this in ``mount_setattr()``. So this can be shortened to:: - - mapped_fsuid(kid): - /* Map the kernel id up into a userspace id in the mount's idmapping. */ - from_kuid(mount-idmapping, kid) = uid - - /* Map the userspace id down into a kernel id in the filesystem's idmapping. */ - KUIDT_INIT(uid) = kuid - - Similarly, for ``i_*id_into_mnt()`` which translated the filesystem's kernel - id into a mount's kernel id:: - - i_uid_into_mnt(kid): - /* Map the kernel id up into a userspace id in the filesystem's idmapping. */ - from_kuid(filesystem-idmapping, kid) = uid - - /* Map the userspace id down into a kernel id in the mounts's idmapping. */ - make_kuid(mount-idmapping, uid) = kuid - - Again, we know that the filesystem is always mounted with the initial - idmapping as we enforce this in ``mount_setattr()``. So this can be - shortened to:: - - i_uid_into_mnt(kid): - /* Map the kernel id up into a userspace id in the filesystem's idmapping. */ - __kuid_val(kid) = uid - - /* Map the userspace id down into a kernel id in the mounts's idmapping. */ - make_kuid(mount-idmapping, uid) = kuid - -Handling filesystems mounted with non-initial idmappings requires that the -translation functions be converted to their full form. They can still be -shortcircuited on non-idmapped mounts. This has no user-visible consequences. diff --git a/Documentation/filesystems/locking.rst b/Documentation/filesystems/locking.rst index d36fe79167b3..3f9b1497ebb8 100644 --- a/Documentation/filesystems/locking.rst +++ b/Documentation/filesystems/locking.rst @@ -169,7 +169,6 @@ prototypes:: int (*show_options)(struct seq_file *, struct dentry *); ssize_t (*quota_read)(struct super_block *, int, char *, size_t, loff_t); ssize_t (*quota_write)(struct super_block *, int, const char *, size_t, loff_t); - int (*bdev_try_to_free_page)(struct super_block*, struct page*, gfp_t); locking rules: All may block [not true, see below] @@ -194,7 +193,6 @@ umount_begin: no show_options: no (namespace_sem) quota_read: no (see below) quota_write: no (see below) -bdev_try_to_free_page: no (see below) ====================== ============ ======================== ->statfs() has s_umount (shared) when called by ustat(2) (native or @@ -210,9 +208,6 @@ dqio_sem) (unless an admin really wants to screw up something and writes to quota files with quotas on). For other details about locking see also dquot_operations section. -->bdev_try_to_free_page is called from the ->releasepage handler of -the block device inode. See there for more details. - file_system_type ================ diff --git a/Documentation/filesystems/netfs_library.rst b/Documentation/filesystems/netfs_library.rst index bb68d39f03b7..136f8da3d0e2 100644 --- a/Documentation/filesystems/netfs_library.rst +++ b/Documentation/filesystems/netfs_library.rst @@ -1,7 +1,7 @@ .. SPDX-License-Identifier: GPL-2.0 ================================= -NETWORK FILESYSTEM HELPER LIBRARY +Network Filesystem Helper Library ================================= .. Contents: @@ -37,22 +37,22 @@ into a common call framework. The following services are provided: - * Handles transparent huge pages (THPs). + * Handle folios that span multiple pages. - * Insulates the netfs from VM interface changes. + * Insulate the netfs from VM interface changes. - * Allows the netfs to arbitrarily split reads up into pieces, even ones that - don't match page sizes or page alignments and that may cross pages. + * Allow the netfs to arbitrarily split reads up into pieces, even ones that + don't match folio sizes or folio alignments and that may cross folios. - * Allows the netfs to expand a readahead request in both directions to meet - its needs. + * Allow the netfs to expand a readahead request in both directions to meet its + needs. - * Allows the netfs to partially fulfil a read, which will then be resubmitted. + * Allow the netfs to partially fulfil a read, which will then be resubmitted. - * Handles local caching, allowing cached data and server-read data to be + * Handle local caching, allowing cached data and server-read data to be interleaved for a single request. - * Handles clearing of bufferage that aren't on the server. + * Handle clearing of bufferage that aren't on the server. * Handle retrying of reads that failed, switching reads from the cache to the server as necessary. @@ -70,22 +70,22 @@ Read Helper Functions Three read helpers are provided:: - * void netfs_readahead(struct readahead_control *ractl, - const struct netfs_read_request_ops *ops, - void *netfs_priv);`` - * int netfs_readpage(struct file *file, - struct page *page, - const struct netfs_read_request_ops *ops, - void *netfs_priv); - * int netfs_write_begin(struct file *file, - struct address_space *mapping, - loff_t pos, - unsigned int len, - unsigned int flags, - struct page **_page, - void **_fsdata, - const struct netfs_read_request_ops *ops, - void *netfs_priv); + void netfs_readahead(struct readahead_control *ractl, + const struct netfs_read_request_ops *ops, + void *netfs_priv); + int netfs_readpage(struct file *file, + struct folio *folio, + const struct netfs_read_request_ops *ops, + void *netfs_priv); + int netfs_write_begin(struct file *file, + struct address_space *mapping, + loff_t pos, + unsigned int len, + unsigned int flags, + struct folio **_folio, + void **_fsdata, + const struct netfs_read_request_ops *ops, + void *netfs_priv); Each corresponds to a VM operation, with the addition of a couple of parameters for the use of the read helpers: @@ -103,8 +103,8 @@ Both of these values will be stored into the read request structure. For ->readahead() and ->readpage(), the network filesystem should just jump into the corresponding read helper; whereas for ->write_begin(), it may be a little more complicated as the network filesystem might want to flush -conflicting writes or track dirty data and needs to put the acquired page if an -error occurs after calling the helper. +conflicting writes or track dirty data and needs to put the acquired folio if +an error occurs after calling the helper. The helpers manage the read request, calling back into the network filesystem through the suppplied table of operations. Waits will be performed as @@ -253,7 +253,7 @@ through which it can issue requests and negotiate:: void (*issue_op)(struct netfs_read_subrequest *subreq); bool (*is_still_valid)(struct netfs_read_request *rreq); int (*check_write_begin)(struct file *file, loff_t pos, unsigned len, - struct page *page, void **_fsdata); + struct folio *folio, void **_fsdata); void (*done)(struct netfs_read_request *rreq); void (*cleanup)(struct address_space *mapping, void *netfs_priv); }; @@ -313,13 +313,14 @@ The operations are as follows: There is no return value; the netfs_subreq_terminated() function should be called to indicate whether or not the operation succeeded and how much data - it transferred. The filesystem also should not deal with setting pages + it transferred. The filesystem also should not deal with setting folios uptodate, unlocking them or dropping their refs - the helpers need to deal with this as they have to coordinate with copying to the local cache. - Note that the helpers have the pages locked, but not pinned. It is possible - to use the ITER_XARRAY iov iterator to refer to the range of the inode that - is being operated upon without the need to allocate large bvec tables. + Note that the helpers have the folios locked, but not pinned. It is + possible to use the ITER_XARRAY iov iterator to refer to the range of the + inode that is being operated upon without the need to allocate large bvec + tables. * ``is_still_valid()`` @@ -330,15 +331,15 @@ The operations are as follows: * ``check_write_begin()`` [Optional] This is called from the netfs_write_begin() helper once it has - allocated/grabbed the page to be modified to allow the filesystem to flush + allocated/grabbed the folio to be modified to allow the filesystem to flush conflicting state before allowing it to be modified. - It should return 0 if everything is now fine, -EAGAIN if the page should be + It should return 0 if everything is now fine, -EAGAIN if the folio should be regrabbed and any other error code to abort the operation. * ``done`` - [Optional] This is called after the pages in the request have all been + [Optional] This is called after the folios in the request have all been unlocked (and marked uptodate if applicable). * ``cleanup`` @@ -390,7 +391,7 @@ The read helpers work by the following general procedure: * If NETFS_SREQ_CLEAR_TAIL was set, a short read will be cleared to the end of the slice instead of reissuing. - * Once the data is read, the pages that have been fully read/cleared: + * Once the data is read, the folios that have been fully read/cleared: * Will be marked uptodate. @@ -398,11 +399,11 @@ The read helpers work by the following general procedure: * Unlocked - * Any pages that need writing to the cache will then have DIO writes issued. + * Any folios that need writing to the cache will then have DIO writes issued. * Synchronous operations will wait for reading to be complete. - * Writes to the cache will proceed asynchronously and the pages will have the + * Writes to the cache will proceed asynchronously and the folios will have the PG_fscache mark removed when that completes. * The request structures will be cleaned up when everything has completed. @@ -452,6 +453,10 @@ operation table looks like the following:: netfs_io_terminated_t term_func, void *term_func_priv); + int (*prepare_write)(struct netfs_cache_resources *cres, + loff_t *_start, size_t *_len, loff_t i_size, + bool no_space_allocated_yet); + int (*write)(struct netfs_cache_resources *cres, loff_t start_pos, struct iov_iter *iter, @@ -509,6 +514,17 @@ The methods defined in the table are: indicating whether the termination is definitely happening in the caller's context. + * ``prepare_write()`` + + [Required] Called to prepare a write to the cache to take place. This + involves checking to see whether the cache has sufficient space to honour + the write. ``*_start`` and ``*_len`` indicate the region to be written; the + region can be shrunk or it can be expanded to a page boundary either way as + necessary to align for direct I/O. i_size holds the size of the object and + is provided for reference. no_space_allocated_yet is set to true if the + caller is certain that no data has been written to that region - for example + if it tried to do a read from there already. + * ``write()`` [Required] Called to write to the cache. The start file offset is given @@ -525,4 +541,9 @@ not the read request structure as they could be used in other situations where there isn't a read request structure as well, such as writing dirty data to the cache. + +API Function Reference +====================== + .. kernel-doc:: include/linux/netfs.h +.. kernel-doc:: fs/netfs/read_helper.c diff --git a/Documentation/filesystems/proc.rst b/Documentation/filesystems/proc.rst index 8d7f141c6fc7..061744c436d9 100644 --- a/Documentation/filesystems/proc.rst +++ b/Documentation/filesystems/proc.rst @@ -426,12 +426,14 @@ with the memory region, as the case would be with BSS (uninitialized data). The "pathname" shows the name associated file for this mapping. If the mapping is not associated with a file: - ======= ==================================== + ============= ==================================== [heap] the heap of the program [stack] the stack of the main process [vdso] the "virtual dynamic shared object", the kernel system call handler - ======= ==================================== + [anon:<name>] an anonymous mapping that has been + named by userspace + ============= ==================================== or if empty, the mapping is anonymous. diff --git a/Documentation/firmware-guide/acpi/apei/einj.rst b/Documentation/firmware-guide/acpi/apei/einj.rst index c042176e1707..55e2331a6438 100644 --- a/Documentation/firmware-guide/acpi/apei/einj.rst +++ b/Documentation/firmware-guide/acpi/apei/einj.rst @@ -181,5 +181,24 @@ You should see something like this in dmesg:: [22715.834759] EDAC sbridge MC3: PROCESSOR 0:306e7 TIME 1422553404 SOCKET 0 APIC 0 [22716.616173] EDAC MC3: 1 CE memory read error on CPU_SrcID#0_Channel#0_DIMM#0 (channel:0 slot:0 page:0x12345 offset:0x0 grain:32 syndrome:0x0 - area:DRAM err_code:0001:0090 socket:0 channel_mask:1 rank:0) +Special notes for injection into SGX enclaves: + +There may be a separate BIOS setup option to enable SGX injection. + +The injection process consists of setting some special memory controller +trigger that will inject the error on the next write to the target +address. But the h/w prevents any software outside of an SGX enclave +from accessing enclave pages (even BIOS SMM mode). + +The following sequence can be used: + 1) Determine physical address of enclave page + 2) Use "notrigger=1" mode to inject (this will setup + the injection address, but will not actually inject) + 3) Enter the enclave + 4) Store data to the virtual address matching physical address from step 1 + 5) Execute CLFLUSH for that virtual address + 6) Spin delay for 250ms + 7) Read from the virtual address. This will trigger the error + For more information about EINJ, please refer to ACPI specification version 4.0, section 17.5 and ACPI 5.0, section 18.6. diff --git a/Documentation/firmware-guide/acpi/dsd/data-node-references.rst b/Documentation/firmware-guide/acpi/dsd/data-node-references.rst index b7ad47df49de..8d8b53e96bcf 100644 --- a/Documentation/firmware-guide/acpi/dsd/data-node-references.rst +++ b/Documentation/firmware-guide/acpi/dsd/data-node-references.rst @@ -5,7 +5,7 @@ Referencing hierarchical data nodes =================================== -:Copyright: |copy| 2018 Intel Corporation +:Copyright: |copy| 2018, 2021 Intel Corporation :Author: Sakari Ailus <sakari.ailus@linux.intel.com> ACPI in general allows referring to device objects in the tree only. @@ -13,9 +13,9 @@ Hierarchical data extension nodes may not be referred to directly, hence this document defines a scheme to implement such references. A reference consist of the device object name followed by one or more -hierarchical data extension [1] keys. Specifically, the hierarchical data -extension node which is referred to by the key shall lie directly under the -parent object i.e. either the device object or another hierarchical data +hierarchical data extension [dsd-guide] keys. Specifically, the hierarchical +data extension node which is referred to by the key shall lie directly under +the parent object i.e. either the device object or another hierarchical data extension node. The keys in the hierarchical data nodes shall consist of the name of the node, @@ -33,7 +33,7 @@ extension key. Example ======= -In the ASL snippet below, the "reference" _DSD property [2] contains a +In the ASL snippet below, the "reference" _DSD property contains a device object reference to DEV0 and under that device object, a hierarchical data extension key "node@1" referring to the NOD1 object and lastly, a hierarchical data extension key "anothernode" referring to @@ -52,12 +52,14 @@ the ANOD object which is also the final target node of the reference. Name (NOD0, Package() { ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"), Package () { + Package () { "reg", 0 }, Package () { "random-property", 3 }, } }) Name (NOD1, Package() { ToUUID("dbb8e3e6-5886-4ba6-8795-1319f52a966b"), Package () { + Package () { "reg", 1 }, Package () { "anothernode", "ANOD" }, } }) @@ -74,7 +76,11 @@ the ANOD object which is also the final target node of the reference. Name (_DSD, Package () { ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"), Package () { - Package () { "reference", ^DEV0, "node@1", "anothernode" }, + Package () { + "reference", Package () { + ^DEV0, "node@1", "anothernode" + } + }, } }) } @@ -85,10 +91,6 @@ Documentation/firmware-guide/acpi/dsd/graph.rst. References ========== -[1] Hierarchical Data Extension UUID For _DSD. -<https://www.uefi.org/sites/default/files/resources/_DSD-hierarchical-data-extension-UUID-v1.1.pdf>, -referenced 2018-07-17. - -[2] Device Properties UUID For _DSD. -<https://www.uefi.org/sites/default/files/resources/_DSD-device-properties-UUID.pdf>, -referenced 2016-10-04. +[dsd-guide] DSD Guide. + https://github.com/UEFI/DSD-Guide/blob/main/dsd-guide.adoc, referenced + 2021-11-30. diff --git a/Documentation/firmware-guide/acpi/dsd/graph.rst b/Documentation/firmware-guide/acpi/dsd/graph.rst index 0ced07cb1be3..b9dbfc73ed25 100644 --- a/Documentation/firmware-guide/acpi/dsd/graph.rst +++ b/Documentation/firmware-guide/acpi/dsd/graph.rst @@ -7,11 +7,11 @@ Graphs _DSD ==== -_DSD (Device Specific Data) [7] is a predefined ACPI device +_DSD (Device Specific Data) [dsd-guide] is a predefined ACPI device configuration object that can be used to convey information on hardware features which are not specifically covered by the ACPI -specification [1][6]. There are two _DSD extensions that are relevant -for graphs: property [4] and hierarchical data extensions [5]. The +specification [acpi]. There are two _DSD extensions that are relevant +for graphs: property [dsd-guide] and hierarchical data extensions. The property extension provides generic key-value pairs whereas the hierarchical data extension supports nodes with references to other nodes, forming a tree. The nodes in the tree may contain properties as @@ -36,8 +36,9 @@ Ports and endpoints =================== The port and endpoint concepts are very similar to those in Devicetree -[3]. A port represents an interface in a device, and an endpoint -represents a connection to that interface. +[devicetree, graph-bindings]. A port represents an interface in a device, and +an endpoint represents a connection to that interface. Also see [data-node-ref] +for generic data node references. All port nodes are located under the device's "_DSD" node in the hierarchical data extension tree. The data extension related to each port node must begin @@ -153,25 +154,20 @@ the "ISP" device and vice versa. References ========== -[1] _DSD (Device Specific Data) Implementation Guide. - https://www.uefi.org/sites/default/files/resources/_DSD-implementation-guide-toplevel-1_1.htm, - referenced 2016-10-03. +[acpi] Advanced Configuration and Power Interface Specification. + https://uefi.org/specifications/ACPI/6.4/, referenced 2021-11-30. -[2] Devicetree. https://www.devicetree.org, referenced 2016-10-03. +[data-node-ref] Documentation/firmware-guide/acpi/dsd/data-node-references.rst -[3] Documentation/devicetree/bindings/graph.txt +[devicetree] Devicetree. https://www.devicetree.org, referenced 2016-10-03. -[4] Device Properties UUID For _DSD. - https://www.uefi.org/sites/default/files/resources/_DSD-device-properties-UUID.pdf, - referenced 2016-10-04. +[dsd-guide] DSD Guide. + https://github.com/UEFI/DSD-Guide/blob/main/dsd-guide.adoc, referenced + 2021-11-30. -[5] Hierarchical Data Extension UUID For _DSD. - https://www.uefi.org/sites/default/files/resources/_DSD-hierarchical-data-extension-UUID-v1.1.pdf, - referenced 2016-10-04. - -[6] Advanced Configuration and Power Interface Specification. - https://www.uefi.org/sites/default/files/resources/ACPI_6_1.pdf, - referenced 2016-10-04. - -[7] _DSD Device Properties Usage Rules. +[dsd-rules] _DSD Device Properties Usage Rules. Documentation/firmware-guide/acpi/DSD-properties-rules.rst + +[graph-bindings] Common bindings for device graphs (Devicetree). + https://github.com/devicetree-org/dt-schema/blob/main/schemas/graph.yaml, + referenced 2021-11-30. diff --git a/Documentation/firmware-guide/acpi/dsd/leds.rst b/Documentation/firmware-guide/acpi/dsd/leds.rst index b99fff8e06f2..93db592c93c7 100644 --- a/Documentation/firmware-guide/acpi/dsd/leds.rst +++ b/Documentation/firmware-guide/acpi/dsd/leds.rst @@ -5,19 +5,20 @@ Describing and referring to LEDs in ACPI ======================================== -Individual LEDs are described by hierarchical data extension [6] nodes under the +Individual LEDs are described by hierarchical data extension [5] nodes under the device node, the LED driver chip. The "reg" property in the LED specific nodes tells the numerical ID of each individual LED output to which the LEDs are -connected. [3] The hierarchical data nodes are named "led@X", where X is the +connected. [leds] The hierarchical data nodes are named "led@X", where X is the number of the LED output. -Referring to LEDs in Device tree is documented in [4], in "flash-leds" property -documentation. In short, LEDs are directly referred to by using phandles. +Referring to LEDs in Device tree is documented in [video-interfaces], in +"flash-leds" property documentation. In short, LEDs are directly referred to by +using phandles. -While Device tree allows referring to any node in the tree[1], in ACPI -references are limited to device nodes only [2]. For this reason using the same -mechanism on ACPI is not possible. A mechanism to refer to non-device ACPI nodes -is documented in [7]. +While Device tree allows referring to any node in the tree [devicetree], in +ACPI references are limited to device nodes only [acpi]. For this reason using +the same mechanism on ACPI is not possible. A mechanism to refer to non-device +ACPI nodes is documented in [data-node-ref]. ACPI allows (as does DT) using integer arguments after the reference. A combination of the LED driver device reference and an integer argument, @@ -90,22 +91,17 @@ where References ========== -[1] Device tree. https://www.devicetree.org, referenced 2019-02-21. +[acpi] Advanced Configuration and Power Interface Specification. + https://uefi.org/specifications/ACPI/6.4/, referenced 2021-11-30. -[2] Advanced Configuration and Power Interface Specification. - https://uefi.org/sites/default/files/resources/ACPI_6_3_final_Jan30.pdf, - referenced 2019-02-21. +[data-node-ref] Documentation/firmware-guide/acpi/dsd/data-node-references.rst -[3] Documentation/devicetree/bindings/leds/common.txt +[devicetree] Devicetree. https://www.devicetree.org, referenced 2019-02-21. -[4] Documentation/devicetree/bindings/media/video-interfaces.txt +[dsd-guide] DSD Guide. + https://github.com/UEFI/DSD-Guide/blob/main/dsd-guide.adoc, referenced + 2021-11-30. -[5] Device Properties UUID For _DSD. - https://www.uefi.org/sites/default/files/resources/_DSD-device-properties-UUID.pdf, - referenced 2019-02-21. +[leds] Documentation/devicetree/bindings/leds/common.yaml -[6] Hierarchical Data Extension UUID For _DSD. - https://www.uefi.org/sites/default/files/resources/_DSD-hierarchical-data-extension-UUID-v1.1.pdf, - referenced 2019-02-21. - -[7] Documentation/firmware-guide/acpi/dsd/data-node-references.rst +[video-interfaces] Documentation/devicetree/bindings/media/video-interfaces.yaml diff --git a/Documentation/firmware-guide/acpi/dsd/phy.rst b/Documentation/firmware-guide/acpi/dsd/phy.rst index 680ad179e5f9..673ac374f92a 100644 --- a/Documentation/firmware-guide/acpi/dsd/phy.rst +++ b/Documentation/firmware-guide/acpi/dsd/phy.rst @@ -4,17 +4,17 @@ MDIO bus and PHYs in ACPI ========================= -The PHYs on an MDIO bus [1] are probed and registered using +The PHYs on an MDIO bus [phy] are probed and registered using fwnode_mdiobus_register_phy(). Later, for connecting these PHYs to their respective MACs, the PHYs registered on the MDIO bus have to be referenced. This document introduces two _DSD properties that are to be used -for connecting PHYs on the MDIO bus [3] to the MAC layer. +for connecting PHYs on the MDIO bus [dsd-properties-rules] to the MAC layer. These properties are defined in accordance with the "Device -Properties UUID For _DSD" [2] document and the +Properties UUID For _DSD" [dsd-guide] document and the daffd814-6eba-4d8c-8a91-bc9bbf4aa301 UUID must be used in the Device Data Descriptors containing them. @@ -48,22 +48,22 @@ as device object references (e.g. \_SB.MDI0.PHY1). phy-mode -------- The "phy-mode" _DSD property is used to describe the connection to -the PHY. The valid values for "phy-mode" are defined in [4]. +the PHY. The valid values for "phy-mode" are defined in [ethernet-controller]. managed ------- Optional property, which specifies the PHY management type. -The valid values for "managed" are defined in [4]. +The valid values for "managed" are defined in [ethernet-controller]. fixed-link ---------- The "fixed-link" is described by a data-only subnode of the MAC port, which is linked in the _DSD package via hierarchical data extension (UUID dbb8e3e6-5886-4ba6-8795-1319f52a966b -in accordance with [5] "_DSD Implementation Guide" document). +in accordance with [dsd-guide] "_DSD Implementation Guide" document). The subnode should comprise a required property ("speed") and possibly the optional ones - complete list of parameters and -their values are specified in [4]. +their values are specified in [ethernet-controller]. The following ASL example illustrates the usage of these properties. @@ -188,12 +188,14 @@ MAC node example with a "fixed-link" subnode. References ========== -[1] Documentation/networking/phy.rst +[phy] Documentation/networking/phy.rst -[2] https://www.uefi.org/sites/default/files/resources/_DSD-device-properties-UUID.pdf +[dsd-properties-rules] + Documentation/firmware-guide/acpi/DSD-properties-rules.rst -[3] Documentation/firmware-guide/acpi/DSD-properties-rules.rst +[ethernet-controller] + Documentation/devicetree/bindings/net/ethernet-controller.yaml -[4] Documentation/devicetree/bindings/net/ethernet-controller.yaml - -[5] https://github.com/UEFI/DSD-Guide/blob/main/dsd-guide.pdf +[dsd-guide] DSD Guide. + https://github.com/UEFI/DSD-Guide/blob/main/dsd-guide.adoc, referenced + 2021-11-30. diff --git a/Documentation/gpu/amdgpu-dc.rst b/Documentation/gpu/amdgpu-dc.rst deleted file mode 100644 index f7ff7e1309de..000000000000 --- a/Documentation/gpu/amdgpu-dc.rst +++ /dev/null @@ -1,74 +0,0 @@ -=================================== -drm/amd/display - Display Core (DC) -=================================== - -*placeholder - general description of supported platforms, what dc is, etc.* - -Because it is partially shared with other operating systems, the Display Core -Driver is divided in two pieces. - -1. **Display Core (DC)** contains the OS-agnostic components. Things like - hardware programming and resource management are handled here. -2. **Display Manager (DM)** contains the OS-dependent components. Hooks to the - amdgpu base driver and DRM are implemented here. - -It doesn't help that the entire package is frequently referred to as DC. But -with the context in mind, it should be clear. - -When CONFIG_DRM_AMD_DC is enabled, DC will be initialized by default for -supported ASICs. To force disable, set `amdgpu.dc=0` on kernel command line. -Likewise, to force enable on unsupported ASICs, set `amdgpu.dc=1`. - -To determine if DC is loaded, search dmesg for the following entry: - -``Display Core initialized with <version number here>`` - -AMDgpu Display Manager -====================== - -.. kernel-doc:: drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c - :doc: overview - -.. kernel-doc:: drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h - :internal: - -Lifecycle ---------- - -.. kernel-doc:: drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c - :doc: DM Lifecycle - -.. kernel-doc:: drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c - :functions: dm_hw_init dm_hw_fini - -Interrupts ----------- - -.. kernel-doc:: drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_irq.c - :doc: overview - -.. kernel-doc:: drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_irq.c - :internal: - -.. kernel-doc:: drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c - :functions: register_hpd_handlers dm_crtc_high_irq dm_pflip_high_irq - -Atomic Implementation ---------------------- - -.. kernel-doc:: drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c - :doc: atomic - -.. kernel-doc:: drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c - :functions: amdgpu_dm_atomic_check amdgpu_dm_atomic_commit_tail - -Display Core -============ - -**WIP** - -FreeSync Video --------------- - -.. kernel-doc:: drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c - :doc: FreeSync Video diff --git a/Documentation/gpu/amdgpu.rst b/Documentation/gpu/amdgpu.rst deleted file mode 100644 index 8ba72e898099..000000000000 --- a/Documentation/gpu/amdgpu.rst +++ /dev/null @@ -1,324 +0,0 @@ -========================= - drm/amdgpu AMDgpu driver -========================= - -The drm/amdgpu driver supports all AMD Radeon GPUs based on the Graphics Core -Next (GCN) architecture. - -Module Parameters -================= - -The amdgpu driver supports the following module parameters: - -.. kernel-doc:: drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c - -Core Driver Infrastructure -========================== - -This section covers core driver infrastructure. - -.. _amdgpu_memory_domains: - -Memory Domains --------------- - -.. kernel-doc:: include/uapi/drm/amdgpu_drm.h - :doc: memory domains - -Buffer Objects --------------- - -.. kernel-doc:: drivers/gpu/drm/amd/amdgpu/amdgpu_object.c - :doc: amdgpu_object - -.. kernel-doc:: drivers/gpu/drm/amd/amdgpu/amdgpu_object.c - :internal: - -PRIME Buffer Sharing --------------------- - -.. kernel-doc:: drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c - :doc: PRIME Buffer Sharing - -.. kernel-doc:: drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c - :internal: - -MMU Notifier ------------- - -.. kernel-doc:: drivers/gpu/drm/amd/amdgpu/amdgpu_mn.c - :doc: MMU Notifier - -.. kernel-doc:: drivers/gpu/drm/amd/amdgpu/amdgpu_mn.c - :internal: - -AMDGPU Virtual Memory ---------------------- - -.. kernel-doc:: drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c - :doc: GPUVM - -.. kernel-doc:: drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c - :internal: - -Interrupt Handling ------------------- - -.. kernel-doc:: drivers/gpu/drm/amd/amdgpu/amdgpu_irq.c - :doc: Interrupt Handling - -.. kernel-doc:: drivers/gpu/drm/amd/amdgpu/amdgpu_irq.c - :internal: - -IP Blocks ------------------- - -.. kernel-doc:: drivers/gpu/drm/amd/include/amd_shared.h - :doc: IP Blocks - -.. kernel-doc:: drivers/gpu/drm/amd/include/amd_shared.h - :identifiers: amd_ip_block_type amd_ip_funcs - -AMDGPU XGMI Support -=================== - -.. kernel-doc:: drivers/gpu/drm/amd/amdgpu/amdgpu_xgmi.c - -AMDGPU RAS Support -================== - -The AMDGPU RAS interfaces are exposed via sysfs (for informational queries) and -debugfs (for error injection). - -RAS debugfs/sysfs Control and Error Injection Interfaces --------------------------------------------------------- - -.. kernel-doc:: drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c - :doc: AMDGPU RAS debugfs control interface - -RAS Reboot Behavior for Unrecoverable Errors --------------------------------------------------------- - -.. kernel-doc:: drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c - :doc: AMDGPU RAS Reboot Behavior for Unrecoverable Errors - -RAS Error Count sysfs Interface -------------------------------- - -.. kernel-doc:: drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c - :doc: AMDGPU RAS sysfs Error Count Interface - -RAS EEPROM debugfs Interface ----------------------------- - -.. kernel-doc:: drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c - :doc: AMDGPU RAS debugfs EEPROM table reset interface - -RAS VRAM Bad Pages sysfs Interface ----------------------------------- - -.. kernel-doc:: drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c - :doc: AMDGPU RAS sysfs gpu_vram_bad_pages Interface - -Sample Code ------------ -Sample code for testing error injection can be found here: -https://cgit.freedesktop.org/mesa/drm/tree/tests/amdgpu/ras_tests.c - -This is part of the libdrm amdgpu unit tests which cover several areas of the GPU. -There are four sets of tests: - -RAS Basic Test - -The test verifies the RAS feature enabled status and makes sure the necessary sysfs and debugfs files -are present. - -RAS Query Test - -This test checks the RAS availability and enablement status for each supported IP block as well as -the error counts. - -RAS Inject Test - -This test injects errors for each IP. - -RAS Disable Test - -This test tests disabling of RAS features for each IP block. - - -GPU Power/Thermal Controls and Monitoring -========================================= - -This section covers hwmon and power/thermal controls. - -HWMON Interfaces ----------------- - -.. kernel-doc:: drivers/gpu/drm/amd/pm/amdgpu_pm.c - :doc: hwmon - -GPU sysfs Power State Interfaces --------------------------------- - -GPU power controls are exposed via sysfs files. - -power_dpm_state -~~~~~~~~~~~~~~~ - -.. kernel-doc:: drivers/gpu/drm/amd/pm/amdgpu_pm.c - :doc: power_dpm_state - -power_dpm_force_performance_level -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -.. kernel-doc:: drivers/gpu/drm/amd/pm/amdgpu_pm.c - :doc: power_dpm_force_performance_level - -pp_table -~~~~~~~~ - -.. kernel-doc:: drivers/gpu/drm/amd/pm/amdgpu_pm.c - :doc: pp_table - -pp_od_clk_voltage -~~~~~~~~~~~~~~~~~ - -.. kernel-doc:: drivers/gpu/drm/amd/pm/amdgpu_pm.c - :doc: pp_od_clk_voltage - -pp_dpm_* -~~~~~~~~ - -.. kernel-doc:: drivers/gpu/drm/amd/pm/amdgpu_pm.c - :doc: pp_dpm_sclk pp_dpm_mclk pp_dpm_socclk pp_dpm_fclk pp_dpm_dcefclk pp_dpm_pcie - -pp_power_profile_mode -~~~~~~~~~~~~~~~~~~~~~ - -.. kernel-doc:: drivers/gpu/drm/amd/pm/amdgpu_pm.c - :doc: pp_power_profile_mode - -\*_busy_percent -~~~~~~~~~~~~~~~ - -.. kernel-doc:: drivers/gpu/drm/amd/pm/amdgpu_pm.c - :doc: gpu_busy_percent - -.. kernel-doc:: drivers/gpu/drm/amd/pm/amdgpu_pm.c - :doc: mem_busy_percent - -gpu_metrics -~~~~~~~~~~~~~~~~~~~~~ - -.. kernel-doc:: drivers/gpu/drm/amd/pm/amdgpu_pm.c - :doc: gpu_metrics - -GPU Product Information -======================= - -Information about the GPU can be obtained on certain cards -via sysfs - -product_name ------------- - -.. kernel-doc:: drivers/gpu/drm/amd/amdgpu/amdgpu_device.c - :doc: product_name - -product_number --------------- - -.. kernel-doc:: drivers/gpu/drm/amd/amdgpu/amdgpu_device.c - :doc: product_name - -serial_number -------------- - -.. kernel-doc:: drivers/gpu/drm/amd/amdgpu/amdgpu_device.c - :doc: serial_number - -unique_id ---------- - -.. kernel-doc:: drivers/gpu/drm/amd/pm/amdgpu_pm.c - :doc: unique_id - -GPU Memory Usage Information -============================ - -Various memory accounting can be accessed via sysfs - -mem_info_vram_total -------------------- - -.. kernel-doc:: drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c - :doc: mem_info_vram_total - -mem_info_vram_used ------------------- - -.. kernel-doc:: drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c - :doc: mem_info_vram_used - -mem_info_vis_vram_total ------------------------ - -.. kernel-doc:: drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c - :doc: mem_info_vis_vram_total - -mem_info_vis_vram_used ----------------------- - -.. kernel-doc:: drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c - :doc: mem_info_vis_vram_used - -mem_info_gtt_total ------------------- - -.. kernel-doc:: drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c - :doc: mem_info_gtt_total - -mem_info_gtt_used ------------------ - -.. kernel-doc:: drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c - :doc: mem_info_gtt_used - -PCIe Accounting Information -=========================== - -pcie_bw -------- - -.. kernel-doc:: drivers/gpu/drm/amd/pm/amdgpu_pm.c - :doc: pcie_bw - -pcie_replay_count ------------------ - -.. kernel-doc:: drivers/gpu/drm/amd/amdgpu/amdgpu_device.c - :doc: pcie_replay_count - -GPU SmartShift Information -========================== - -GPU SmartShift information via sysfs - -smartshift_apu_power --------------------- - -.. kernel-doc:: drivers/gpu/drm/amd/pm/amdgpu_pm.c - :doc: smartshift_apu_power - -smartshift_dgpu_power ---------------------- - -.. kernel-doc:: drivers/gpu/drm/amd/pm/amdgpu_pm.c - :doc: smartshift_dgpu_power - -smartshift_bias ---------------- - -.. kernel-doc:: drivers/gpu/drm/amd/pm/amdgpu_pm.c - :doc: smartshift_bias diff --git a/Documentation/gpu/amdgpu/amdgpu-glossary.rst b/Documentation/gpu/amdgpu/amdgpu-glossary.rst new file mode 100644 index 000000000000..859dcec6c6f9 --- /dev/null +++ b/Documentation/gpu/amdgpu/amdgpu-glossary.rst @@ -0,0 +1,87 @@ +=============== +AMDGPU Glossary +=============== + +Here you can find some generic acronyms used in the amdgpu driver. Notice that +we have a dedicated glossary for Display Core at +'Documentation/gpu/amdgpu/display/dc-glossary.rst'. + +.. glossary:: + + CP + Command Processor + + CPLIB + Content Protection Library + + DFS + Digital Frequency Synthesizer + + ECP + Enhanced Content Protection + + EOP + End Of Pipe/Pipeline + + GC + Graphics and Compute + + GMC + Graphic Memory Controller + + IH + Interrupt Handler + + HQD + Hardware Queue Descriptor + + IB + Indirect Buffer + + IP + Intellectual Property blocks + + KCQ + Kernel Compute Queue + + KGQ + Kernel Graphics Queue + + KIQ + Kernel Interface Queue + + MEC + MicroEngine Compute + + MES + MicroEngine Scheduler + + MMHUB + Multi-Media HUB + + MQD + Memory Queue Descriptor + + PPLib + PowerPlay Library - PowerPlay is the power management component. + + PSP + Platform Security Processor + + RCL + RunList Controller + + SDMA + System DMA + + SMU + System Management Unit + + SS + Spread Spectrum + + VCE + Video Compression Engine + + VCN + Video Codec Next diff --git a/Documentation/gpu/amdgpu/display/config_example.svg b/Documentation/gpu/amdgpu/display/config_example.svg new file mode 100644 index 000000000000..cdac9858601c --- /dev/null +++ b/Documentation/gpu/amdgpu/display/config_example.svg @@ -0,0 +1,414 @@ +<?xml version="1.0" encoding="UTF-8" standalone="no"?> +<!-- Created with Inkscape (http://www.inkscape.org/) --> + +<svg + xmlns:dc="http://purl.org/dc/elements/1.1/" + xmlns:cc="http://creativecommons.org/ns#" + xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" + xmlns:svg="http://www.w3.org/2000/svg" + xmlns="http://www.w3.org/2000/svg" + xmlns:sodipodi="http://sodipodi.sourceforge.net/DTD/sodipodi-0.dtd" + xmlns:inkscape="http://www.inkscape.org/namespaces/inkscape" + width="144.63406mm" + height="66.596054mm" + viewBox="0 0 144.15195 66.596054" + version="1.1" + id="svg8" + inkscape:version="0.92.5 (2060ec1f9f, 2020-04-08)" + sodipodi:docname="config_example.svg"> + <defs + id="defs2"> + <marker + inkscape:stockid="Arrow1Mend" + orient="auto" + refY="0" + refX="0" + id="Arrow1Mend" + style="overflow:visible" + inkscape:isstock="true"> + <path + id="path4547" + d="M 0,0 5,-5 -12.5,0 5,5 Z" + style="fill:#ff0000;fill-opacity:1;fill-rule:evenodd;stroke:#ff0000;stroke-width:1.00000003pt;stroke-opacity:1" + transform="matrix(-0.4,0,0,-0.4,-4,0)" + inkscape:connector-curvature="0" /> + </marker> + <marker + inkscape:stockid="Arrow1Mend" + orient="auto" + refY="0" + refX="0" + id="Arrow1Mend-3" + style="overflow:visible" + inkscape:isstock="true"> + <path + inkscape:connector-curvature="0" + id="path4547-6" + d="M 0,0 5,-5 -12.5,0 5,5 Z" + style="fill:#ff0000;fill-opacity:1;fill-rule:evenodd;stroke:#ff0000;stroke-width:1.00000003pt;stroke-opacity:1" + transform="matrix(-0.4,0,0,-0.4,-4,0)" /> + </marker> + <marker + inkscape:stockid="Arrow1Mend" + orient="auto" + refY="0" + refX="0" + id="Arrow1Mend-3-5" + style="overflow:visible" + inkscape:isstock="true"> + <path + inkscape:connector-curvature="0" + id="path4547-6-3" + d="M 0,0 5,-5 -12.5,0 5,5 Z" + style="fill:#ff0000;fill-opacity:1;fill-rule:evenodd;stroke:#ff0000;stroke-width:1.00000003pt;stroke-opacity:1" + transform="matrix(-0.4,0,0,-0.4,-4,0)" /> + </marker> + <marker + inkscape:stockid="Arrow1Mend" + orient="auto" + refY="0" + refX="0" + id="Arrow1Mend-3-5-0" + style="overflow:visible" + inkscape:isstock="true"> + <path + inkscape:connector-curvature="0" + id="path4547-6-3-6" + d="M 0,0 5,-5 -12.5,0 5,5 Z" + style="fill:#ff0000;fill-opacity:1;fill-rule:evenodd;stroke:#ff0000;stroke-width:1.00000003pt;stroke-opacity:1" + transform="matrix(-0.4,0,0,-0.4,-4,0)" /> + </marker> + <marker + inkscape:stockid="Arrow1Mend" + orient="auto" + refY="0" + refX="0" + id="Arrow1Mend-3-5-7" + style="overflow:visible" + inkscape:isstock="true"> + <path + inkscape:connector-curvature="0" + id="path4547-6-3-3" + d="M 0,0 5,-5 -12.5,0 5,5 Z" + style="fill:#ff0000;fill-opacity:1;fill-rule:evenodd;stroke:#ff0000;stroke-width:1.00000003pt;stroke-opacity:1" + transform="matrix(-0.4,0,0,-0.4,-4,0)" /> + </marker> + </defs> + <sodipodi:namedview + id="base" + pagecolor="#ffffff" + bordercolor="#666666" + borderopacity="1.0" + inkscape:pageopacity="0.0" + inkscape:pageshadow="2" + inkscape:zoom="0.98994949" + inkscape:cx="518.91791" + inkscape:cy="172.50112" + inkscape:document-units="mm" + inkscape:current-layer="layer1" + showgrid="true" + viewbox-width="209.3" + inkscape:window-width="3840" + inkscape:window-height="1136" + inkscape:window-x="0" + inkscape:window-y="27" + inkscape:window-maximized="1" + fit-margin-top="0" + fit-margin-left="0" + fit-margin-right="0" + fit-margin-bottom="0"> + <inkscape:grid + type="xygrid" + id="grid817" + originx="4.390216" + originy="-208.88856" /> + </sodipodi:namedview> + <metadata + id="metadata5"> + <rdf:RDF> + <cc:Work + rdf:about=""> + <dc:format>image/svg+xml</dc:format> + <dc:type + rdf:resource="http://purl.org/dc/dcmitype/StillImage" /> + <dc:title></dc:title> + </cc:Work> + </rdf:RDF> + </metadata> + <g + inkscape:label="Layer 1" + inkscape:groupmode="layer" + id="layer1" + transform="translate(4.4048992,-21.515392)"> + <path + style="fill:none;stroke:#000000;stroke-width:0.26458335px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1" + d="m 20.816662,35.062492 h 23.8125 v -5.291667 h 5.291667 v 5.291667 h 10.583334 v -5.291667 h 5.291667 v 5.291667 h 2.645833 v -5.291667 h 5.291667 v 5.291667 h 66.14583" + id="path4522" + inkscape:connector-curvature="0" /> + <path + style="fill:none;stroke:#000000;stroke-width:0.26458335px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1" + d="m 20.816662,48.291659 h 7.9375 v -5.291667 h 5.291667 v 5.291667 h 58.208335 v -5.291667 h 5.291666 v 5.291667 h 42.33333" + id="path4524" + inkscape:connector-curvature="0" /> + <path + style="fill:none;stroke:#000000;stroke-width:0.26458335px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1" + d="m 20.816662,61.520826 h 26.458334 v -5.291667 h 44.979168 v 5.291667 h 47.624996" + id="path4526" + inkscape:connector-curvature="0" /> + <path + style="fill:none;stroke:#000000;stroke-width:0.26458335px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1" + d="M 20.816662,72.104159 H 139.87916" + id="path4528" + inkscape:connector-curvature="0" /> + <path + style="fill:none;stroke:#000000;stroke-width:0.26458335px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1" + d="M 20.816662,77.395826 H 139.87916" + id="path4530" + inkscape:connector-curvature="0" /> + <path + style="fill:none;stroke:#000000;stroke-width:0.26458335px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1" + d="M 20.816662,82.687493 H 139.87916" + id="path4532" + inkscape:connector-curvature="0" /> + <path + style="fill:none;stroke:#000000;stroke-width:0.26458335px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1" + d="M 20.816662,87.97916 H 139.87916" + id="path4534" + inkscape:connector-curvature="0" /> + <path + style="fill:none;stroke:#ff0000;stroke-width:0.5291667;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:0.52916668, 0.52916668;stroke-dashoffset:0;stroke-opacity:1;marker-end:url(#Arrow1Mend)" + d="m 47.274996,29.770826 c 3.836215,14.933158 3.472151,27.586643 0.264583,41.010418" + id="path4536" + inkscape:connector-curvature="0" + sodipodi:nodetypes="cc" /> + <path + style="fill:none;stroke:#ff0000;stroke-width:0.5291667;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:0.52916669, 0.52916669;stroke-dashoffset:0;stroke-opacity:1;marker-end:url(#Arrow1Mend-3)" + d="m 63.149996,29.770826 c 3.836214,14.933158 5.059652,27.586642 1.852084,41.010418" + id="path4536-7" + inkscape:connector-curvature="0" + sodipodi:nodetypes="cc" /> + <path + style="fill:none;stroke:#ff0000;stroke-width:0.5291667;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:0.5291667, 0.5291667;stroke-dashoffset:0;stroke-opacity:1;marker-end:url(#Arrow1Mend-3-5)" + d="m 71.087496,29.770825 c 3.836214,14.933158 5.059652,27.586643 1.852084,41.010419" + id="path4536-7-5" + inkscape:connector-curvature="0" + sodipodi:nodetypes="cc" /> + <text + xml:space="preserve" + style="font-style:normal;font-weight:normal;font-size:10.58333397px;line-height:1.25;font-family:sans-serif;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;stroke-width:0.26458335" + x="59.359009" + y="24.195677" + id="text6572"><tspan + sodipodi:role="line" + x="59.359009" + y="24.195677" + style="font-size:3.52777791px;line-height:5.39999962;text-align:center;text-anchor:middle;stroke-width:0.26458335" + id="tspan6574">Configurations</tspan></text> + <text + xml:space="preserve" + style="font-style:normal;font-weight:normal;font-size:10.58333397px;line-height:1.25;font-family:sans-serif;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;stroke-width:0.26458335" + x="46.825508" + y="28.542402" + id="text6572-6"><tspan + sodipodi:role="line" + x="46.825508" + y="28.542402" + style="font-size:3.52777815px;line-height:5.39999962;text-align:center;text-anchor:middle;fill:#008000;stroke-width:0.26458335" + id="tspan6574-2">A</tspan></text> + <text + xml:space="preserve" + style="font-style:normal;font-weight:normal;font-size:10.58333397px;line-height:1.25;font-family:sans-serif;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;stroke-width:0.26458335" + x="62.8895" + y="28.825886" + id="text6572-6-2"><tspan + sodipodi:role="line" + x="62.8895" + y="28.825886" + style="font-size:3.52777839px;line-height:5.39999962;text-align:center;text-anchor:middle;fill:#0000ff;stroke-width:0.26458335" + id="tspan6574-2-7">B</tspan></text> + <text + xml:space="preserve" + style="font-style:normal;font-weight:normal;font-size:10.58333397px;line-height:1.25;font-family:sans-serif;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;stroke-width:0.26458335" + x="70.827003" + y="29.109362" + id="text6572-6-2-3"><tspan + sodipodi:role="line" + x="70.827003" + y="29.109362" + style="font-size:3.52777863px;line-height:5.39999962;text-align:center;text-anchor:middle;fill:#c87137;stroke-width:0.26458335" + id="tspan6574-2-7-6">C</tspan></text> + <path + style="fill:none;stroke:#ff0000;stroke-width:0.5291667;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:0.52916671, 0.52916671;stroke-dashoffset:0;stroke-opacity:1;marker-end:url(#Arrow1Mend-3-5-0)" + d="m 92.254164,42.999993 c 9.142136,12.745655 4.411987,28.608461 0.529167,38.364584" + id="path4536-7-5-2" + inkscape:connector-curvature="0" + sodipodi:nodetypes="cc" /> + <path + style="fill:none;stroke:#000000;stroke-width:0.5291667;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1" + d="m 47.274996,72.104159 v 5.291667" + id="path8053" + inkscape:connector-curvature="0" /> + <path + style="fill:none;stroke:#000000;stroke-width:0.5291667;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1" + d="m 64.472913,72.10416 v 5.291667" + id="path8053-6" + inkscape:connector-curvature="0" /> + <path + style="fill:none;stroke:#000000;stroke-width:0.5291667;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1" + d="m 72.410413,72.10416 v 5.291667" + id="path8053-6-1" + inkscape:connector-curvature="0" /> + <path + style="fill:none;stroke:#000000;stroke-width:0.5291667;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1" + d="m 92.254164,82.687494 v 5.291667" + id="path8053-6-1-8" + inkscape:connector-curvature="0" /> + <text + xml:space="preserve" + style="font-style:normal;font-weight:normal;font-size:10.58333397px;line-height:1.25;font-family:sans-serif;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;stroke-width:0.26458335" + x="55.802444" + y="76.167412" + id="text6572-6-7"><tspan + sodipodi:role="line" + x="55.802444" + y="76.167412" + style="font-size:3.52777839px;line-height:5.39999962;text-align:center;text-anchor:middle;fill:#008000;stroke-width:0.26458335" + id="tspan6574-2-9">A</tspan></text> + <text + xml:space="preserve" + style="font-style:normal;font-weight:normal;font-size:10.58333397px;line-height:1.25;font-family:sans-serif;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;stroke-width:0.26458335" + x="68.559143" + y="75.883926" + id="text6572-6-2-2"><tspan + sodipodi:role="line" + x="68.559143" + y="75.883926" + style="font-size:3.52777863px;line-height:5.39999962;text-align:center;text-anchor:middle;fill:#0000ff;stroke-width:0.26458335" + id="tspan6574-2-7-0">B</tspan></text> + <text + xml:space="preserve" + style="font-style:normal;font-weight:normal;font-size:10.58333397px;line-height:1.25;font-family:sans-serif;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;stroke-width:0.26458335" + x="84.812119" + y="75.883911" + id="text6572-6-2-3-2"><tspan + sodipodi:role="line" + x="84.812119" + y="75.883911" + style="font-size:3.52777863px;line-height:5.39999962;text-align:center;text-anchor:middle;fill:#c87137;stroke-width:0.26458335" + id="tspan6574-2-7-6-3">C</tspan></text> + <text + xml:space="preserve" + style="font-style:normal;font-weight:normal;font-size:10.58333397px;line-height:1.25;font-family:sans-serif;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;stroke-width:0.26458335" + x="98.513756" + y="86.845222" + id="text6572-6-2-3-2-7"><tspan + sodipodi:role="line" + x="98.513756" + y="86.845222" + style="font-size:3.52777863px;line-height:5.39999962;text-align:center;text-anchor:middle;fill:#c87137;stroke-width:0.26458335" + id="tspan6574-2-7-6-3-5">C</tspan></text> + <text + xml:space="preserve" + style="font-style:normal;font-weight:normal;font-size:10.58333397px;line-height:1.25;font-family:sans-serif;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;stroke-width:0.26458335" + x="35.452015" + y="75.694931" + id="text6572-9"><tspan + sodipodi:role="line" + x="35.452015" + y="75.694931" + style="font-size:3.52777815px;line-height:5.39999962;text-align:center;text-anchor:middle;stroke-width:0.26458335" + id="tspan6574-22">Old config</tspan></text> + <text + xml:space="preserve" + style="font-style:normal;font-weight:normal;font-size:10.58333397px;line-height:1.25;font-family:sans-serif;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;stroke-width:0.26458335" + x="55.484753" + y="86.656235" + id="text6572-9-8"><tspan + sodipodi:role="line" + x="55.484753" + y="86.656235" + style="font-size:3.52777839px;line-height:5.39999962;text-align:center;text-anchor:middle;stroke-width:0.26458335" + id="tspan6574-22-9">Old config</tspan></text> + <path + style="fill:none;stroke:#ff0000;stroke-width:0.5291667;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:0.52916671, 0.52916671;stroke-dashoffset:0;stroke-opacity:1;marker-end:url(#Arrow1Mend-3-5-7)" + d="m 92.254164,42.999993 c 4.233333,4.7625 2.645833,13.229167 0.79375,17.197917" + inkscape:connector-curvature="0" + sodipodi:nodetypes="cc" /> + <text + xml:space="preserve" + style="font-style:normal;font-weight:normal;font-size:10.58333397px;line-height:1.25;font-family:sans-serif;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;stroke-width:0.26458335" + x="3.7020128" + y="33.550579" + id="text6572-1"><tspan + sodipodi:role="line" + x="3.7020128" + y="42.914349" + style="font-size:3.52777815px;line-height:5.39999962;text-align:center;text-anchor:middle;stroke-width:0.26458335" + id="tspan15310" /></text> + <text + xml:space="preserve" + style="font-style:normal;font-weight:normal;font-size:3.17500019px;line-height:1.25;font-family:sans-serif;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;stroke-width:0.26458335" + x="13.366468" + y="46.590767" + id="text15316"><tspan + sodipodi:role="line" + x="13.366468" + y="46.590767" + style="text-align:center;text-anchor:middle;stroke-width:0.26458335" + id="tspan15318">VUpdate</tspan></text> + <text + xml:space="preserve" + style="font-style:normal;font-weight:normal;font-size:3.17500043px;line-height:1.25;font-family:sans-serif;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;stroke-width:0.26458335" + x="14.45245" + y="29.676321" + id="text15316-3"><tspan + sodipodi:role="line" + id="tspan15314-1" + x="14.45245" + y="29.676321" + style="text-align:center;text-anchor:middle;stroke-width:0.26458335">Update</tspan><tspan + sodipodi:role="line" + x="14.45245" + y="33.645073" + style="text-align:center;text-anchor:middle;stroke-width:0.26458335" + id="tspan15318-9">Lock</tspan></text> + <text + xml:space="preserve" + style="font-style:normal;font-weight:normal;font-size:3.17500043px;line-height:1.25;font-family:sans-serif;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;stroke-width:0.26458335" + x="7.5676007" + y="56.985115" + id="text15316-4"><tspan + sodipodi:role="line" + x="7.5676007" + y="56.985115" + style="text-align:center;text-anchor:middle;stroke-width:0.26458335" + id="tspan15318-7">Register update</tspan><tspan + sodipodi:role="line" + x="7.5676007" + y="60.953865" + style="text-align:center;text-anchor:middle;stroke-width:0.26458335" + id="tspan15361">Pending Status</tspan></text> + <text + xml:space="preserve" + style="font-style:normal;font-weight:normal;font-size:3.17500043px;line-height:1.25;font-family:sans-serif;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;stroke-width:0.26458335" + x="16.074829" + y="76.167404" + id="text15316-8"><tspan + sodipodi:role="line" + x="16.074829" + y="76.167404" + style="text-align:center;text-anchor:middle;stroke-width:0.26458335" + id="tspan15318-4">Buf 0</tspan></text> + <text + xml:space="preserve" + style="font-style:normal;font-weight:normal;font-size:3.17500067px;line-height:1.25;font-family:sans-serif;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;stroke-width:0.26458335" + x="16.156994" + y="86.089279" + id="text15316-8-5"><tspan + sodipodi:role="line" + x="16.156994" + y="86.089279" + style="text-align:center;text-anchor:middle;stroke-width:0.26458335" + id="tspan15318-4-0">Buf 1</tspan></text> + </g> +</svg> diff --git a/Documentation/gpu/amdgpu/display/dc-debug.rst b/Documentation/gpu/amdgpu/display/dc-debug.rst new file mode 100644 index 000000000000..40c55a618918 --- /dev/null +++ b/Documentation/gpu/amdgpu/display/dc-debug.rst @@ -0,0 +1,77 @@ +======================== +Display Core Debug tools +======================== + +DC Visual Confirmation +====================== + +Display core provides a feature named visual confirmation, which is a set of +bars added at the scanout time by the driver to convey some specific +information. In general, you can enable this debug option by using:: + + echo <N> > /sys/kernel/debug/dri/0/amdgpu_dm_visual_confirm + +Where `N` is an integer number for some specific scenarios that the developer +wants to enable, you will see some of these debug cases in the following +subsection. + +Multiple Planes Debug +--------------------- + +If you want to enable or debug multiple planes in a specific user-space +application, you can leverage a debug feature named visual confirm. For +enabling it, you will need:: + + echo 1 > /sys/kernel/debug/dri/0/amdgpu_dm_visual_confirm + +You need to reload your GUI to see the visual confirmation. When the plane +configuration changes or a full update occurs there will be a colored bar at +the bottom of each hardware plane being drawn on the screen. + +* The color indicates the format - For example, red is AR24 and green is NV12 +* The height of the bar indicates the index of the plane +* Pipe split can be observed if there are two bars with a difference in height + covering the same plane + +Consider the video playback case in which a video is played in a specific +plane, and the desktop is drawn in another plane. The video plane should +feature one or two green bars at the bottom of the video depending on pipe +split configuration. + +* There should **not** be any visual corruption +* There should **not** be any underflow or screen flashes +* There should **not** be any black screens +* There should **not** be any cursor corruption +* Multiple plane **may** be briefly disabled during window transitions or + resizing but should come back after the action has finished + +Pipe Split Debug +---------------- + +Sometimes we need to debug if DCN is splitting pipes correctly, and visual +confirmation is also handy for this case. Similar to the MPO case, you can use +the below command to enable visual confirmation:: + + echo 1 > /sys/kernel/debug/dri/0/amdgpu_dm_visual_confirm + +In this case, if you have a pipe split, you will see one small red bar at the +bottom of the display covering the entire display width and another bar +covering the second pipe. In other words, you will see a bit high bar in the +second pipe. + +DTN Debug +========= + +DC (DCN) provides an extensive log that dumps multiple details from our +hardware configuration. Via debugfs, you can capture those status values by +using Display Test Next (DTN) log, which can be captured via debugfs by using:: + + cat /sys/kernel/debug/dri/0/amdgpu_dm_dtn_log + +Since this log is updated accordingly with DCN status, you can also follow the +change in real-time by using something like:: + + sudo watch -d cat /sys/kernel/debug/dri/0/amdgpu_dm_dtn_log + +When reporting a bug related to DC, consider attaching this log before and +after you reproduce the bug. diff --git a/Documentation/gpu/amdgpu/display/dc-glossary.rst b/Documentation/gpu/amdgpu/display/dc-glossary.rst new file mode 100644 index 000000000000..116f5f0942fd --- /dev/null +++ b/Documentation/gpu/amdgpu/display/dc-glossary.rst @@ -0,0 +1,237 @@ +=========== +DC Glossary +=========== + +On this page, we try to keep track of acronyms related to the display +component. If you do not find what you are looking for, look at the +'Documentation/gpu/amdgpu/amdgpu-glossary.rst'; if you cannot find it anywhere, +consider asking in the amdgfx and update this page. + +.. glossary:: + + ABM + Adaptive Backlight Modulation + + APU + Accelerated Processing Unit + + ASIC + Application-Specific Integrated Circuit + + ASSR + Alternate Scrambler Seed Reset + + AZ + Azalia (HD audio DMA engine) + + BPC + Bits Per Colour/Component + + BPP + Bits Per Pixel + + Clocks + * PCLK: Pixel Clock + * SYMCLK: Symbol Clock + * SOCCLK: GPU Engine Clock + * DISPCLK: Display Clock + * DPPCLK: DPP Clock + * DCFCLK: Display Controller Fabric Clock + * REFCLK: Real Time Reference Clock + * PPLL: Pixel PLL + * FCLK: Fabric Clock + * MCLK: Memory Clock + + CRC + Cyclic Redundancy Check + + CRTC + Cathode Ray Tube Controller - commonly called "Controller" - Generates + raw stream of pixels, clocked at pixel clock + + CVT + Coordinated Video Timings + + DAL + Display Abstraction layer + + DC (Software) + Display Core + + DC (Hardware) + Display Controller + + DCC + Delta Colour Compression + + DCE + Display Controller Engine + + DCHUB + Display Controller HUB + + ARB + Arbiter + + VTG + Vertical Timing Generator + + DCN + Display Core Next + + DCCG + Display Clock Generator block + + DDC + Display Data Channel + + DIO + Display IO + + DPP + Display Pipes and Planes + + DSC + Display Stream Compression (Reduce the amount of bits to represent pixel + count while at the same pixel clock) + + dGPU + discrete GPU + + DMIF + Display Memory Interface + + DML + Display Mode Library + + DMCU + Display Micro-Controller Unit + + DMCUB + Display Micro-Controller Unit, version B + + DPCD + DisplayPort Configuration Data + + DPM(S) + Display Power Management (Signaling) + + DRR + Dynamic Refresh Rate + + DWB + Display Writeback + + FB + Frame Buffer + + FBC + Frame Buffer Compression + + FEC + Forward Error Correction + + FRL + Fixed Rate Link + + GCO + Graphical Controller Object + + GSL + Global Swap Lock + + iGPU + integrated GPU + + ISR + Interrupt Service Request + + ISV + Independent Software Vendor + + KMD + Kernel Mode Driver + + LB + Line Buffer + + LFC + Low Framerate Compensation + + LTTPR + Link Training Tunable Phy Repeater + + LUT + Lookup Table + + MALL + Memory Access at Last Level + + MC + Memory Controller + + MPC + Multiple pipes and plane combine + + MPO + Multi Plane Overlay + + MST + Multi Stream Transport + + NBP State + Northbridge Power State + + NBIO + North Bridge Input/Output + + ODM + Output Data Mapping + + OPM + Output Protection Manager + + OPP + Output Plane Processor + + OPTC + Output Pipe Timing Combiner + + OTG + Output Timing Generator + + PCON + Power Controller + + PGFSM + Power Gate Finite State Machine + + PSR + Panel Self Refresh + + SCL + Scaler + + SDP + Scalable Data Port + + SLS + Single Large Surface + + SST + Single Stream Transport + + TMDS + Transition-Minimized Differential Signaling + + TMZ + Trusted Memory Zone + + TTU + Time to Underflow + + VRR + Variable Refresh Rate + + UVD + Unified Video Decoder diff --git a/Documentation/gpu/amdgpu/display/dc_pipeline_overview.svg b/Documentation/gpu/amdgpu/display/dc_pipeline_overview.svg new file mode 100644 index 000000000000..9adecebfe65b --- /dev/null +++ b/Documentation/gpu/amdgpu/display/dc_pipeline_overview.svg @@ -0,0 +1,1125 @@ +<?xml version="1.0" encoding="UTF-8" standalone="no"?> +<!-- Created with Inkscape (http://www.inkscape.org/) --> + +<svg + xmlns:dc="http://purl.org/dc/elements/1.1/" + xmlns:cc="http://creativecommons.org/ns#" + xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" + xmlns:svg="http://www.w3.org/2000/svg" + xmlns="http://www.w3.org/2000/svg" + xmlns:sodipodi="http://sodipodi.sourceforge.net/DTD/sodipodi-0.dtd" + xmlns:inkscape="http://www.inkscape.org/namespaces/inkscape" + width="1296.7491" + height="741.97845" + viewBox="0 0 343.0982 196.31514" + version="1.1" + id="svg8" + inkscape:version="0.92.5 (2060ec1f9f, 2020-04-08)" + sodipodi:docname="dc_pipeline_overview.svg"> + <defs + id="defs2"> + <marker + inkscape:stockid="Arrow2Mend" + orient="auto" + refY="0" + refX="0" + id="marker8858" + style="overflow:visible" + inkscape:isstock="true"> + <path + id="path8616" + style="fill:#aa00d4;fill-opacity:1;fill-rule:evenodd;stroke:#aa00d4;stroke-width:0.625;stroke-linejoin:round;stroke-opacity:1" + d="M 8.7185878,4.0337352 -2.2072895,0.01601326 8.7185884,-4.0017078 c -1.7454984,2.3720609 -1.7354408,5.6174519 -6e-7,8.035443 z" + transform="scale(-0.6)" + inkscape:connector-curvature="0" /> + </marker> + <marker + inkscape:stockid="Arrow2Send" + orient="auto" + refY="0" + refX="0" + id="Arrow2Send" + style="overflow:visible" + inkscape:isstock="true"> + <path + id="path8622" + style="fill:#ff0000;fill-opacity:1;fill-rule:evenodd;stroke:#ff0000;stroke-width:0.625;stroke-linejoin:round;stroke-opacity:1" + d="M 8.7185878,4.0337352 -2.2072895,0.01601326 8.7185884,-4.0017078 c -1.7454984,2.3720609 -1.7354408,5.6174519 -6e-7,8.035443 z" + transform="matrix(-0.3,0,0,-0.3,0.69,0)" + inkscape:connector-curvature="0" /> + </marker> + <marker + inkscape:stockid="Arrow1Lend" + orient="auto" + refY="0" + refX="0" + id="Arrow1Lend" + style="overflow:visible" + inkscape:isstock="true"> + <path + id="path8592" + d="M 0,0 5,-5 -12.5,0 5,5 Z" + style="fill:#ff0000;fill-opacity:1;fill-rule:evenodd;stroke:#ff0000;stroke-width:1.00000003pt;stroke-opacity:1" + transform="matrix(-0.8,0,0,-0.8,-10,0)" + inkscape:connector-curvature="0" /> + </marker> + <marker + inkscape:stockid="Arrow2Lend" + orient="auto" + refY="0" + refX="0" + id="Arrow2Lend" + style="overflow:visible" + inkscape:isstock="true"> + <path + id="path8610" + style="fill:#ff0000;fill-opacity:1;fill-rule:evenodd;stroke:#ff0000;stroke-width:0.625;stroke-linejoin:round;stroke-opacity:1" + d="M 8.7185878,4.0337352 -2.2072895,0.01601326 8.7185884,-4.0017078 c -1.7454984,2.3720609 -1.7354408,5.6174519 -6e-7,8.035443 z" + transform="matrix(-1.1,0,0,-1.1,-1.1,0)" + inkscape:connector-curvature="0" /> + </marker> + <marker + inkscape:stockid="Arrow2Mend" + orient="auto" + refY="0" + refX="0" + id="Arrow2Mend" + style="overflow:visible" + inkscape:isstock="true"> + <path + id="path1200" + style="fill:#ff0000;fill-opacity:1;fill-rule:evenodd;stroke:#ff0000;stroke-width:0.625;stroke-linejoin:round;stroke-opacity:1" + d="M 8.7185878,4.0337352 -2.2072895,0.01601326 8.7185884,-4.0017078 c -1.7454984,2.3720609 -1.7354408,5.6174519 -6e-7,8.035443 z" + transform="scale(-0.6)" + inkscape:connector-curvature="0" /> + </marker> + <marker + inkscape:stockid="Arrow2Mend" + orient="auto" + refY="0" + refX="0" + id="Arrow2Mend-8" + style="overflow:visible" + inkscape:isstock="true"> + <path + inkscape:connector-curvature="0" + id="path1200-9" + style="fill:#ff0000;fill-opacity:1;fill-rule:evenodd;stroke:#ff0000;stroke-width:0.625;stroke-linejoin:round;stroke-opacity:1" + d="M 8.7185878,4.0337352 -2.2072895,0.01601326 8.7185884,-4.0017078 c -1.7454984,2.3720609 -1.7354408,5.6174519 -6e-7,8.035443 z" + transform="scale(-0.6)" /> + </marker> + <marker + inkscape:stockid="Arrow2Mend" + orient="auto" + refY="0" + refX="0" + id="Arrow2Mend-8-3" + style="overflow:visible" + inkscape:isstock="true"> + <path + inkscape:connector-curvature="0" + id="path1200-9-6" + style="fill:#ff0000;fill-opacity:1;fill-rule:evenodd;stroke:#ff0000;stroke-width:0.625;stroke-linejoin:round;stroke-opacity:1" + d="M 8.7185878,4.0337352 -2.2072895,0.01601326 8.7185884,-4.0017078 c -1.7454984,2.3720609 -1.7354408,5.6174519 -6e-7,8.035443 z" + transform="scale(-0.6)" /> + </marker> + <marker + inkscape:stockid="Arrow2Mend" + orient="auto" + refY="0" + refX="0" + id="Arrow2Mend-8-3-2" + style="overflow:visible" + inkscape:isstock="true"> + <path + inkscape:connector-curvature="0" + id="path1200-9-6-9" + style="fill:#ff0000;fill-opacity:1;fill-rule:evenodd;stroke:#ff0000;stroke-width:0.625;stroke-linejoin:round;stroke-opacity:1" + d="M 8.7185878,4.0337352 -2.2072895,0.01601326 8.7185884,-4.0017078 c -1.7454984,2.3720609 -1.7354408,5.6174519 -6e-7,8.035443 z" + transform="scale(-0.6)" /> + </marker> + <marker + inkscape:stockid="Arrow2Mend" + orient="auto" + refY="0" + refX="0" + id="Arrow2Mend-8-3-2-1" + style="overflow:visible" + inkscape:isstock="true"> + <path + inkscape:connector-curvature="0" + id="path1200-9-6-9-9" + style="fill:#ff0000;fill-opacity:1;fill-rule:evenodd;stroke:#ff0000;stroke-width:0.625;stroke-linejoin:round;stroke-opacity:1" + d="M 8.7185878,4.0337352 -2.2072895,0.01601326 8.7185884,-4.0017078 c -1.7454984,2.3720609 -1.7354408,5.6174519 -6e-7,8.035443 z" + transform="scale(-0.6)" /> + </marker> + <marker + inkscape:stockid="Arrow2Mend" + orient="auto" + refY="0" + refX="0" + id="Arrow2Mend-8-3-2-7" + style="overflow:visible" + inkscape:isstock="true"> + <path + inkscape:connector-curvature="0" + id="path1200-9-6-9-8" + style="fill:#008000;fill-opacity:1;fill-rule:evenodd;stroke:#008000;stroke-width:0.625;stroke-linejoin:round;stroke-opacity:1" + d="M 8.7185878,4.0337352 -2.2072895,0.01601326 8.7185884,-4.0017078 c -1.7454984,2.3720609 -1.7354408,5.6174519 -6e-7,8.035443 z" + transform="scale(-0.6)" /> + </marker> + <marker + inkscape:stockid="Arrow2Mend" + orient="auto" + refY="0" + refX="0" + id="Arrow2Mend-8-3-4" + style="overflow:visible" + inkscape:isstock="true"> + <path + inkscape:connector-curvature="0" + id="path1200-9-6-5" + style="fill:#008000;fill-opacity:1;fill-rule:evenodd;stroke:#008000;stroke-width:0.625;stroke-linejoin:round;stroke-opacity:1" + d="M 8.7185878,4.0337352 -2.2072895,0.01601326 8.7185884,-4.0017078 c -1.7454984,2.3720609 -1.7354408,5.6174519 -6e-7,8.035443 z" + transform="scale(-0.6)" /> + </marker> + <marker + inkscape:stockid="Arrow2Mend" + orient="auto" + refY="0" + refX="0" + id="Arrow2Mend-8-0" + style="overflow:visible" + inkscape:isstock="true"> + <path + inkscape:connector-curvature="0" + id="path1200-9-3" + style="fill:#008000;fill-opacity:1;fill-rule:evenodd;stroke:#008000;stroke-width:0.625;stroke-linejoin:round;stroke-opacity:1" + d="M 8.7185878,4.0337352 -2.2072895,0.01601326 8.7185884,-4.0017078 c -1.7454984,2.3720609 -1.7354408,5.6174519 -6e-7,8.035443 z" + transform="scale(-0.6)" /> + </marker> + <marker + inkscape:stockid="Arrow2Mend" + orient="auto" + refY="0" + refX="0" + id="Arrow2Mend-6" + style="overflow:visible" + inkscape:isstock="true"> + <path + inkscape:connector-curvature="0" + id="path1200-1" + style="fill:#008000;fill-opacity:1;fill-rule:evenodd;stroke:#008000;stroke-width:0.625;stroke-linejoin:round;stroke-opacity:1" + d="M 8.7185878,4.0337352 -2.2072895,0.01601326 8.7185884,-4.0017078 c -1.7454984,2.3720609 -1.7354408,5.6174519 -6e-7,8.035443 z" + transform="scale(-0.6)" /> + </marker> + <marker + inkscape:stockid="Arrow2Mend" + orient="auto" + refY="0" + refX="0" + id="Arrow2Mend-8-3-2-6" + style="overflow:visible" + inkscape:isstock="true"> + <path + inkscape:connector-curvature="0" + id="path1200-9-6-9-1" + style="fill:#ff0000;fill-opacity:1;fill-rule:evenodd;stroke:#ff0000;stroke-width:0.625;stroke-linejoin:round;stroke-opacity:1" + d="M 8.7185878,4.0337352 -2.2072895,0.01601326 8.7185884,-4.0017078 c -1.7454984,2.3720609 -1.7354408,5.6174519 -6e-7,8.035443 z" + transform="scale(-0.6)" /> + </marker> + <marker + inkscape:stockid="Arrow2Mend" + orient="auto" + refY="0" + refX="0" + id="Arrow2Mend-8-0-7" + style="overflow:visible" + inkscape:isstock="true"> + <path + inkscape:connector-curvature="0" + id="path1200-9-3-4" + style="fill:#008000;fill-opacity:1;fill-rule:evenodd;stroke:#008000;stroke-width:0.625;stroke-linejoin:round;stroke-opacity:1" + d="M 8.7185878,4.0337352 -2.2072895,0.01601326 8.7185884,-4.0017078 c -1.7454984,2.3720609 -1.7354408,5.6174519 -6e-7,8.035443 z" + transform="scale(-0.6)" /> + </marker> + <marker + inkscape:stockid="Arrow2Mend" + orient="auto" + refY="0" + refX="0" + id="Arrow2Mend-6-3" + style="overflow:visible" + inkscape:isstock="true"> + <path + inkscape:connector-curvature="0" + id="path1200-1-0" + style="fill:#008000;fill-opacity:1;fill-rule:evenodd;stroke:#008000;stroke-width:0.625;stroke-linejoin:round;stroke-opacity:1" + d="M 8.7185878,4.0337352 -2.2072895,0.01601326 8.7185884,-4.0017078 c -1.7454984,2.3720609 -1.7354408,5.6174519 -6e-7,8.035443 z" + transform="scale(-0.6)" /> + </marker> + <marker + inkscape:stockid="Arrow2Mend" + orient="auto" + refY="0" + refX="0" + id="Arrow2Mend-8-3-2-8" + style="overflow:visible" + inkscape:isstock="true"> + <path + inkscape:connector-curvature="0" + id="path1200-9-6-9-6" + style="fill:#ff0000;fill-opacity:1;fill-rule:evenodd;stroke:#ff0000;stroke-width:0.625;stroke-linejoin:round;stroke-opacity:1" + d="M 8.7185878,4.0337352 -2.2072895,0.01601326 8.7185884,-4.0017078 c -1.7454984,2.3720609 -1.7354408,5.6174519 -6e-7,8.035443 z" + transform="scale(-0.6)" /> + </marker> + <marker + inkscape:stockid="Arrow2Mend" + orient="auto" + refY="0" + refX="0" + id="Arrow2Mend-3" + style="overflow:visible" + inkscape:isstock="true"> + <path + id="path1200-6" + style="fill:#ff0000;fill-opacity:1;fill-rule:evenodd;stroke:#ff0000;stroke-width:0.625;stroke-linejoin:round;stroke-opacity:1" + d="M 8.7185878,4.0337352 -2.2072895,0.01601326 8.7185884,-4.0017078 c -1.7454984,2.3720609 -1.7354408,5.6174519 -6e-7,8.035443 z" + transform="scale(-0.6)" + inkscape:connector-curvature="0" /> + </marker> + <marker + inkscape:stockid="Arrow2Mend" + orient="auto" + refY="0" + refX="0" + id="marker8858-3" + style="overflow:visible" + inkscape:isstock="true"> + <path + id="path8616-5" + style="fill:#00ffcc;fill-opacity:1;fill-rule:evenodd;stroke:#00ffcc;stroke-width:0.625;stroke-linejoin:round;stroke-opacity:1" + d="M 8.7185878,4.0337352 -2.2072895,0.01601326 8.7185884,-4.0017078 c -1.7454984,2.3720609 -1.7354408,5.6174519 -6e-7,8.035443 z" + transform="scale(-0.6)" + inkscape:connector-curvature="0" /> + </marker> + <marker + inkscape:stockid="Arrow2Mend" + orient="auto" + refY="0" + refX="0" + id="Arrow2Mend-8-3-3" + style="overflow:visible" + inkscape:isstock="true"> + <path + inkscape:connector-curvature="0" + id="path1200-9-6-56" + style="fill:#ff0000;fill-opacity:1;fill-rule:evenodd;stroke:#ff0000;stroke-width:0.625;stroke-linejoin:round;stroke-opacity:1" + d="M 8.7185878,4.0337352 -2.2072895,0.01601326 8.7185884,-4.0017078 c -1.7454984,2.3720609 -1.7354408,5.6174519 -6e-7,8.035443 z" + transform="scale(-0.6)" /> + </marker> + <marker + inkscape:stockid="Arrow2Mend" + orient="auto" + refY="0" + refX="0" + id="Arrow2Mend-8-0-2" + style="overflow:visible" + inkscape:isstock="true"> + <path + inkscape:connector-curvature="0" + id="path1200-9-3-9" + style="fill:#008000;fill-opacity:1;fill-rule:evenodd;stroke:#008000;stroke-width:0.625;stroke-linejoin:round;stroke-opacity:1" + d="M 8.7185878,4.0337352 -2.2072895,0.01601326 8.7185884,-4.0017078 c -1.7454984,2.3720609 -1.7354408,5.6174519 -6e-7,8.035443 z" + transform="scale(-0.6)" /> + </marker> + </defs> + <sodipodi:namedview + id="base" + pagecolor="#ffffff" + bordercolor="#666666" + borderopacity="1.0" + inkscape:pageopacity="0.0" + inkscape:pageshadow="2" + inkscape:zoom="2.8" + inkscape:cx="603.80172" + inkscape:cy="404.14319" + inkscape:document-units="mm" + inkscape:current-layer="layer1" + showgrid="false" + inkscape:window-width="3840" + inkscape:window-height="2096" + inkscape:window-x="0" + inkscape:window-y="27" + inkscape:window-maximized="1" + showguides="false" + fit-margin-top="0" + fit-margin-left="0" + fit-margin-right="0" + fit-margin-bottom="0" + units="px" + inkscape:snap-global="false" /> + <metadata + id="metadata5"> + <rdf:RDF> + <cc:Work + rdf:about=""> + <dc:format>image/svg+xml</dc:format> + <dc:type + rdf:resource="http://purl.org/dc/dcmitype/StillImage" /> + <dc:title /> + </cc:Work> + </rdf:RDF> + </metadata> + <g + inkscape:label="Layer 1" + inkscape:groupmode="layer" + id="layer1" + transform="translate(419.79645,20.103767)"> + <path + style="fill:#008000;stroke:#008000;stroke-width:0.59275198;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1;marker-end:url(#Arrow2Mend-8-3-2-7)" + d="m -340.37552,57.5332 h -14.81024" + id="path1171-7-1-3-0" + inkscape:connector-curvature="0" /> + <path + style="fill:#008000;stroke:#008000;stroke-width:0.59715915;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1;marker-end:url(#Arrow2Mend-8-3-4)" + d="m -293.23443,57.5332 h -15.03129" + id="path1171-7-1-32" + inkscape:connector-curvature="0" /> + <path + style="fill:#008000;stroke:#008000;stroke-width:0.59275198;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1;marker-end:url(#Arrow2Mend-8-0)" + d="M -246.45946,57.5332 H -261.2697" + id="path1171-7-6" + inkscape:connector-curvature="0" /> + <path + style="fill:#008000;stroke:#008000;stroke-width:0.59275198;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1;marker-end:url(#Arrow2Mend-6)" + d="m -151.28623,57.5332 h -14.81024" + id="path1171-0" + inkscape:connector-curvature="0" /> + <path + style="fill:none;stroke:#ff0000;stroke-width:0.98222464;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1;marker-end:url(#Arrow2Mend-8-3-2-6)" + d="m -310.11621,-10.988713 h -35.41856" + id="path1171-7-1-3-5" + inkscape:connector-curvature="0" + sodipodi:nodetypes="cc" /> + <path + style="fill:none;stroke:#ff0000;stroke-width:1.33745635;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1;marker-end:url(#Arrow2Mend-8-3-2-1)" + d="M -174.42569,48.441117 V -10.963061 L -277.26548,-11.45916" + id="path1171-7-1-3-4" + inkscape:connector-curvature="0" + sodipodi:nodetypes="ccc" /> + <path + style="fill:none;stroke:#ff0000;stroke-width:0.95872593;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1;marker-end:url(#Arrow2Mend-8-3)" + d="m -262.79442,87.935594 h 14.32069" + id="path1171-7-1" + inkscape:connector-curvature="0" /> + <path + style="fill:none;stroke:#ff0000;stroke-width:0.97006679;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1;marker-end:url(#Arrow2Mend-8)" + d="m -309.80088,87.935594 h 14.44587" + id="path1171-7" + inkscape:connector-curvature="0" /> + <path + style="fill:none;stroke:#ff0000;stroke-width:0.96187615;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1;marker-end:url(#Arrow2Mend)" + d="m -356.45657,87.935594 h 14.20296" + id="path1171" + inkscape:connector-curvature="0" /> + <path + style="fill:none;stroke:#ff0000;stroke-width:0.96061862;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1;marker-end:url(#Arrow2Mend-8-3-2)" + d="m -167.44556,87.935594 h 14.16584" + id="path1171-7-1-3" + inkscape:connector-curvature="0" /> + <path + style="fill:none;stroke:#008000;stroke-width:0.87091714;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1;marker-end:url(#Arrow2Mend-8-0-7)" + d="M -193.82812,48.312503 V 14.168502 l -84.03577,-0.467726" + id="path1171-7-6-4" + inkscape:connector-curvature="0" + sodipodi:nodetypes="ccc" /> + <path + style="fill:none;stroke:#000000;stroke-width:0.81852055;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:4.91112339, 0.81852057;stroke-dashoffset:0;stroke-opacity:1" + d="m -133.33998,42.989657 v 5.457081" + id="path7149-3-7" + inkscape:connector-curvature="0" /> + <path + style="fill:none;stroke:#000000;stroke-width:0.81852055;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:4.91112339, 0.81852057;stroke-dashoffset:0;stroke-opacity:1" + d="m -298.69506,162.44998 v 13.31197" + id="path7149" + inkscape:connector-curvature="0" /> + <path + style="fill:none;stroke:#008080;stroke-width:0.81852055;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:0.81852057, 0.81852057;stroke-dashoffset:0;stroke-opacity:1" + d="m -242.80131,107.00907 v 9.60171" + id="path7040-5-4-7-5-6-9" + inkscape:connector-curvature="0" /> + <path + style="fill:none;stroke:#008080;stroke-width:0.81852055;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:0.81852057, 0.81852057;stroke-dashoffset:0;stroke-opacity:1" + d="m -300.34873,107.17445 v 9.6017" + id="path7040-5-4-7-5-6" + inkscape:connector-curvature="0" /> + <path + style="fill:none;stroke:#008080;stroke-width:0.81852055;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:0.81852057, 0.81852057;stroke-dashoffset:0;stroke-opacity:1" + d="m -359.26293,106.99745 v 9.60171" + id="path7040-5-4-7-5" + inkscape:connector-curvature="0" /> + <path + style="fill:none;stroke:#008080;stroke-width:0.81852055;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:0.81852057, 0.81852057;stroke-dashoffset:0;stroke-opacity:1" + d="M -369.74543,25.114933 V 37.991587" + id="path7040-5-4-7-6" + inkscape:connector-curvature="0" /> + <path + style="fill:none;stroke:#008080;stroke-width:0.91136348;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:0.91136346, 0.91136346;stroke-dashoffset:0;stroke-opacity:1" + d="M -135.17034,93.582486 V 107.10642 H -403.93077 V 37.882965 h 109.60575 V 25.225991" + id="path7038" + inkscape:connector-curvature="0" + sodipodi:nodetypes="cccccc" /> + <path + style="fill:none;stroke:#008080;stroke-width:0.81852055;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:0.81852057, 0.81852057;stroke-dashoffset:0;stroke-opacity:1" + d="M -231.106,94.010086 V 106.96943" + id="path7040" + inkscape:connector-curvature="0" /> + <path + style="fill:none;stroke:#008080;stroke-width:0.81852055;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:0.81852057, 0.81852057;stroke-dashoffset:0;stroke-opacity:1" + d="M -278.50224,93.844719 V 106.80406" + id="path7040-5" + inkscape:connector-curvature="0" /> + <path + style="fill:none;stroke:#008080;stroke-width:0.81852055;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:0.81852057, 0.81852057;stroke-dashoffset:0;stroke-opacity:1" + d="M -325.89848,93.701083 V 106.99115" + id="path7040-5-4" + inkscape:connector-curvature="0" /> + <path + style="fill:none;stroke:#008080;stroke-width:0.81852055;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:0.81852057, 0.81852057;stroke-dashoffset:0;stroke-opacity:1" + d="M -373.29471,93.899037 V 107.27179" + id="path7040-5-4-7" + inkscape:connector-curvature="0" /> + <g + id="g934" + transform="matrix(0.61872421,0,0,0.61872421,-154.16506,-3.5724799)"> + <rect + ry="2.1052283e-06" + y="84.280701" + x="-376.383" + height="72.786827" + width="49.352299" + id="rect834" + style="fill:none;stroke:#000000;stroke-width:1.16258347;stroke-linecap:round;stroke-linejoin:bevel;stroke-miterlimit:4;stroke-dasharray:none" /> + <text + id="text838" + y="95.916664" + x="-371.17261" + style="font-style:normal;font-weight:normal;font-size:10.58333302px;line-height:1.25;font-family:sans-serif;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;stroke-width:0.26458332" + xml:space="preserve"><tspan + style="stroke-width:0.26458332" + y="95.916664" + x="-371.17261" + id="tspan836" + sodipodi:role="line">DCHUB</tspan></text> + <text + id="text846" + y="121.99702" + x="-352.74997" + style="font-style:normal;font-weight:normal;font-size:10.58333302px;line-height:1.25;font-family:sans-serif;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;stroke-width:0.26458332" + xml:space="preserve"><tspan + style="text-align:center;text-anchor:middle;stroke-width:0.26458332" + y="121.99702" + x="-352.74997" + id="tspan844" + sodipodi:role="line">HUBP</tspan><tspan + id="tspan863" + style="text-align:center;text-anchor:middle;stroke-width:0.26458332" + y="135.22618" + x="-352.74997" + sodipodi:role="line">(n)</tspan></text> + </g> + <g + id="g942" + transform="matrix(0.61872421,0,0,0.61872421,-158.40385,-3.2216813)"> + <text + id="text838-5" + y="116.65257" + x="-269.45752" + style="font-style:normal;font-weight:normal;font-size:10.58333302px;line-height:1.25;font-family:sans-serif;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;stroke-width:0.26458332" + xml:space="preserve"><tspan + style="text-align:center;text-anchor:middle;stroke-width:0.26458332" + y="116.65257" + x="-269.45752" + id="tspan836-3" + sodipodi:role="line">DPP</tspan><tspan + id="tspan936" + style="text-align:center;text-anchor:middle;stroke-width:0.26458332" + y="129.88174" + x="-269.45752" + sodipodi:role="line">(n)</tspan></text> + <rect + ry="2.1052283e-06" + y="83.71373" + x="-293.7952" + height="72.786827" + width="49.352303" + id="rect834-5" + style="fill:none;stroke:#000000;stroke-width:1.16258347;stroke-linecap:round;stroke-linejoin:bevel;stroke-miterlimit:4;stroke-dasharray:none" /> + </g> + <g + id="g1158" + transform="matrix(0.61872421,0,0,0.61872421,-154.34048,-6.2618995)"> + <text + id="text838-5-2" + y="128.87331" + x="-200.18195" + style="font-style:normal;font-weight:normal;font-size:10.58333302px;line-height:1.25;font-family:sans-serif;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;stroke-width:0.26458332" + xml:space="preserve"><tspan + id="tspan936-1" + style="text-align:center;text-anchor:middle;stroke-width:0.26458332" + y="128.87331" + x="-200.18195" + sodipodi:role="line">MPC</tspan></text> + <rect + ry="2.1052283e-06" + y="88.627419" + x="-224.62555" + height="72.786827" + width="49.352303" + id="rect834-5-2" + style="fill:none;stroke:#000000;stroke-width:1.16258347;stroke-linecap:round;stroke-linejoin:bevel;stroke-miterlimit:4;stroke-dasharray:none" /> + </g> + <g + id="g1153" + transform="matrix(0.61872421,0,0,0.61872421,-108.51628,-6.4957668)"> + <text + id="text838-5-2-7" + y="129.2513" + x="-120.96272" + style="font-style:normal;font-weight:normal;font-size:10.58333302px;line-height:1.25;font-family:sans-serif;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;stroke-width:0.26458332" + xml:space="preserve"><tspan + id="tspan936-1-0" + style="text-align:center;text-anchor:middle;stroke-width:0.26458332" + y="129.2513" + x="-120.96272" + sodipodi:role="line">OPTC</tspan></text> + <rect + ry="2.1052283e-06" + y="89.005402" + x="-145.62854" + height="72.786827" + width="49.352306" + id="rect834-5-2-9" + style="fill:none;stroke:#000000;stroke-width:1.16258347;stroke-linecap:round;stroke-linejoin:bevel;stroke-miterlimit:4;stroke-dasharray:none" /> + </g> + <g + id="g1148" + transform="matrix(0.61872421,0,0,0.61872421,-105.25474,-7.6650796)"> + <text + id="text838-5-2-7-3" + y="131.14117" + x="-48.981136" + style="font-style:normal;font-weight:normal;font-size:10.58333302px;line-height:1.25;font-family:sans-serif;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;stroke-width:0.26458332" + xml:space="preserve"><tspan + id="tspan936-1-0-6" + style="text-align:center;text-anchor:middle;stroke-width:0.26458332" + y="131.14117" + x="-48.981136" + sodipodi:role="line">DIO</tspan></text> + <rect + ry="2.1052283e-06" + y="90.895279" + x="-73.435081" + height="72.786827" + width="49.352306" + id="rect834-5-2-9-0" + style="fill:none;stroke:#000000;stroke-width:1.16258347;stroke-linecap:round;stroke-linejoin:bevel;stroke-miterlimit:4;stroke-dasharray:none" /> + </g> + <g + id="g1133" + transform="matrix(0.61872421,0,0,0.61872421,-181.52704,-7.6650796)"> + <text + id="text838-5-2-6" + y="241.13223" + x="-286.96921" + style="font-style:normal;font-weight:normal;font-size:10.58333302px;line-height:1.25;font-family:sans-serif;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;stroke-width:0.26458332" + xml:space="preserve"><tspan + id="tspan936-1-2" + style="text-align:center;text-anchor:middle;stroke-width:0.26458332" + y="241.13223" + x="-286.96921" + sodipodi:role="line">DCCG</tspan></text> + <rect + ry="2.1052283e-06" + y="200.88634" + x="-311.56009" + height="72.786827" + width="49.352306" + id="rect834-5-2-6" + style="fill:none;stroke:#000000;stroke-width:1.16258347;stroke-linecap:round;stroke-linejoin:bevel;stroke-miterlimit:4;stroke-dasharray:none" /> + </g> + <g + id="g1138" + transform="matrix(0.61872421,0,0,0.61872421,-181.52704,-7.6650796)"> + <text + id="text838-5-2-6-1" + y="241.81844" + x="-190.55942" + style="font-style:normal;font-weight:normal;font-size:10.58333302px;line-height:1.25;font-family:sans-serif;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;stroke-width:0.26458332" + xml:space="preserve"><tspan + id="tspan936-1-2-8" + style="text-align:center;text-anchor:middle;stroke-width:0.26458332" + y="241.81844" + x="-190.55942" + sodipodi:role="line">DMU</tspan></text> + <rect + ry="2.1052283e-06" + y="201.6423" + x="-215.17615" + height="72.786827" + width="49.352306" + id="rect834-5-2-6-7" + style="fill:none;stroke:#000000;stroke-width:1.16258347;stroke-linecap:round;stroke-linejoin:bevel;stroke-miterlimit:4;stroke-dasharray:none" /> + </g> + <text + xml:space="preserve" + style="font-style:normal;font-weight:normal;font-size:6.54816437px;line-height:1.25;font-family:sans-serif;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;stroke-width:0.1637041" + x="-297.75696" + y="109.44505" + id="text1063"><tspan + sodipodi:role="line" + id="tspan1061" + x="-297.75696" + y="115.23865" + style="stroke-width:0.1637041" /></text> + <g + id="g1143" + transform="matrix(0.61872421,0,0,0.61872421,-181.52704,-8.9747125)"> + <text + id="text838-5-2-6-1-9" + y="243.02728" + x="-99.967323" + style="font-style:normal;font-weight:normal;font-size:10.58333302px;line-height:1.25;font-family:sans-serif;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;stroke-width:0.26458332" + xml:space="preserve"><tspan + id="tspan936-1-2-8-2" + style="text-align:center;text-anchor:middle;stroke-width:0.26458332" + y="243.02728" + x="-99.967323" + sodipodi:role="line">AZ</tspan></text> + <rect + ry="2.1052283e-06" + y="202.77623" + x="-124.83984" + height="72.786827" + width="49.352306" + id="rect834-5-2-6-7-0" + style="fill:none;stroke:#000000;stroke-width:1.16258347;stroke-linecap:round;stroke-linejoin:bevel;stroke-miterlimit:4;stroke-dasharray:none" /> + </g> + <g + id="g1169" + transform="matrix(0.61872421,0,0,0.61872421,-154.16506,1.4555785)"> + <text + id="text838-5-2-6-2" + y="5.9612885" + x="-348.74365" + style="font-style:normal;font-weight:normal;font-size:10.58333302px;line-height:1.25;font-family:sans-serif;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;stroke-width:0.26458332" + xml:space="preserve"><tspan + id="tspan936-1-2-3" + style="text-align:center;text-anchor:middle;stroke-width:0.26458332" + y="5.9612885" + x="-348.74365" + sodipodi:role="line">MMHUBBUB</tspan></text> + <rect + ry="2.1010696e-06" + y="-34.142948" + x="-384.64743" + height="72.643044" + width="72.096924" + id="rect834-5-2-6-75" + style="fill:none;stroke:#000000;stroke-width:1.40378118;stroke-linecap:round;stroke-linejoin:bevel;stroke-miterlimit:4;stroke-dasharray:none" /> + </g> + <g + id="g1164" + transform="matrix(0.61872421,0,0,0.61872421,-154.16506,-7.6650796)"> + <text + id="text838-5-2-6-9" + y="13.465075" + x="-227.30836" + style="font-style:normal;font-weight:normal;font-size:10.58333302px;line-height:1.25;font-family:sans-serif;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;stroke-width:0.26458332" + xml:space="preserve"><tspan + id="tspan936-1-2-2" + style="text-align:center;text-anchor:middle;stroke-width:0.26458332" + y="13.465075" + x="-227.30836" + sodipodi:role="line">DWB</tspan><tspan + id="tspan1128" + style="text-align:center;text-anchor:middle;stroke-width:0.26458332" + y="26.694241" + x="-227.30836" + sodipodi:role="line">(n)</tspan></text> + <rect + ry="2.1052283e-06" + y="-19.473768" + x="-251.83983" + height="72.786827" + width="49.352306" + id="rect834-5-2-6-2" + style="fill:none;stroke:#000000;stroke-width:1.16258347;stroke-linecap:round;stroke-linejoin:bevel;stroke-miterlimit:4;stroke-dasharray:none" /> + </g> + <path + style="fill:none;stroke:#000000;stroke-width:0.91371936;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:5.48231601, 0.91371934;stroke-dashoffset:0;stroke-opacity:1" + d="m -358.95963,161.63019 v 14.12431 h 250.20395 V 43.149938 H -361.845 V 25.478973" + id="path7147" + inkscape:connector-curvature="0" + sodipodi:nodetypes="cccccc" /> + <path + style="fill:none;stroke:#000000;stroke-width:0.81852055;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:4.91112339, 0.81852057;stroke-dashoffset:0;stroke-opacity:1" + d="m -242.92533,161.58513 v 14.05612" + id="path7149-3" + inkscape:connector-curvature="0" /> + <path + style="fill:none;stroke:#000000;stroke-width:0.81852055;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:4.91112339, 0.81852057;stroke-dashoffset:0;stroke-opacity:1" + d="m -184.37695,42.955607 v 5.457082" + id="path7149-3-7-4" + inkscape:connector-curvature="0" /> + <path + style="fill:none;stroke:#000000;stroke-width:0.81852055;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:4.91112339, 0.81852057;stroke-dashoffset:0;stroke-opacity:1" + d="m -277.36283,43.141644 v 5.457082" + id="path7149-3-7-5" + inkscape:connector-curvature="0" /> + <path + style="fill:none;stroke:#000000;stroke-width:0.81852055;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:4.91112339, 0.81852057;stroke-dashoffset:0;stroke-opacity:1" + d="M -325.48437,42.976278 V 48.43336" + id="path7149-3-7-2" + inkscape:connector-curvature="0" /> + <path + style="fill:none;stroke:#000000;stroke-width:0.81852055;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:4.91112339, 0.81852057;stroke-dashoffset:0;stroke-opacity:1" + d="m -361.86492,43.141644 v 5.457083" + id="path7149-3-7-54" + inkscape:connector-curvature="0" /> + <path + style="fill:#008000;stroke:#008000;stroke-width:0.46329758;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1;marker-end:url(#Arrow2Mend-6-3)" + d="m -147.58542,-8.2978166 h -9.04766" + id="path1171-0-7" + inkscape:connector-curvature="0" /> + <path + style="fill:none;stroke:#ff0000;stroke-width:0.98222464;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1;marker-end:url(#Arrow2Mend-8-3-2-8)" + d="m -157.13421,-1.6500501 h 8.66407" + id="path1171-7-1-3-8" + inkscape:connector-curvature="0" /> + <path + style="fill:none;stroke:#000000;stroke-width:0.74503672;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:4.47022031, 0.74503672;stroke-dashoffset:0;stroke-opacity:1" + d="m -148.50314,4.9845652 h -7.91265" + id="path7149-3-7-8" + inkscape:connector-curvature="0" /> + <path + style="fill:none;stroke:#008080;stroke-width:0.81852055;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:0.81852057, 0.81852057;stroke-dashoffset:0;stroke-opacity:1" + d="m -157.59442,11.623513 h 10.26991" + id="path7040-4" + inkscape:connector-curvature="0" /> + <text + xml:space="preserve" + style="font-style:normal;font-weight:normal;font-size:6.54816437px;line-height:1.25;font-family:sans-serif;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;stroke-width:0.1637041" + x="-142.72867" + y="-6.9685979" + id="text12079"><tspan + sodipodi:role="line" + id="tspan12077" + x="-142.72867" + y="-6.9685979" + style="font-size:4.80198765px;stroke-width:0.1637041">Global sync</tspan></text> + <text + xml:space="preserve" + style="font-style:normal;font-weight:normal;font-size:6.54816437px;line-height:1.25;font-family:sans-serif;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;stroke-width:0.1637041" + x="-142.93031" + y="0.13578746" + id="text12079-3"><tspan + sodipodi:role="line" + id="tspan12077-1" + x="-142.93031" + y="0.13578746" + style="font-size:4.80198765px;stroke-width:0.1637041">Pixel data</tspan></text> + <text + xml:space="preserve" + style="font-style:normal;font-weight:normal;font-size:6.54816437px;line-height:1.25;font-family:sans-serif;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;stroke-width:0.1637041" + x="-142.77556" + y="6.3093324" + id="text12079-3-4"><tspan + sodipodi:role="line" + id="tspan12077-1-9" + x="-142.77556" + y="6.3093324" + style="font-size:4.80198765px;stroke-width:0.1637041">Sideband signal</tspan></text> + <text + xml:space="preserve" + style="font-style:normal;font-weight:normal;font-size:6.54816437px;line-height:1.25;font-family:sans-serif;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;stroke-width:0.1637041" + x="-142.72867" + y="12.948278" + id="text12079-3-4-2"><tspan + sodipodi:role="line" + id="tspan12077-1-9-0" + x="-142.72867" + y="12.948278" + style="font-size:4.80198765px;stroke-width:0.1637041">Config. Bus</tspan></text> + <path + style="fill:none;stroke:#aa00d4;stroke-width:1.32291663;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1;marker-end:url(#marker8858)" + d="m -406.68795,73.185276 h 14.20296" + id="path1171-75" + inkscape:connector-curvature="0" /> + <text + xml:space="preserve" + style="font-style:normal;font-weight:normal;font-size:3.17499995px;line-height:1.25;font-family:sans-serif;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;stroke-width:0.26458332" + x="-420.21503" + y="75.065918" + id="text8862"><tspan + sodipodi:role="line" + id="tspan8860" + x="-420.21503" + y="75.065918" + style="font-size:6.3499999px;stroke-width:0.26458332">SDP</tspan></text> + <path + style="fill:none;stroke:#00ffcc;stroke-width:1.25980031;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1;marker-end:url(#marker8858-3)" + d="m -119.19923,72.243805 h 12.88004" + id="path1171-75-6" + inkscape:connector-curvature="0" /> + <text + xml:space="preserve" + style="font-style:normal;font-weight:normal;font-size:3.17499995px;line-height:1.25;font-family:sans-serif;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;stroke-width:0.26458332" + x="-104.87327" + y="74.54258" + id="text8862-2"><tspan + sodipodi:role="line" + id="tspan8860-9" + x="-104.87327" + y="74.54258" + style="font-size:6.3499999px;stroke-width:0.26458332">Monitor</tspan></text> + <g + id="g6280" + transform="translate(-133.43389,-37.35791)"> + <text + id="text838-5-2-7-6" + y="110.67171" + x="-97.4758" + style="font-style:normal;font-weight:normal;font-size:6.54816437px;line-height:1.25;font-family:sans-serif;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;stroke-width:0.16370411" + xml:space="preserve"><tspan + id="tspan936-1-0-7" + style="text-align:center;text-anchor:middle;stroke-width:0.16370411" + y="110.67171" + x="-97.4758" + sodipodi:role="line">OPP</tspan></text> + <rect + ry="1.3025557e-06" + y="85.770599" + x="-112.73714" + height="45.034973" + width="30.535467" + id="rect834-5-2-9-5" + style="fill:none;stroke:#000000;stroke-width:0.71931857;stroke-linecap:round;stroke-linejoin:bevel;stroke-miterlimit:4;stroke-dasharray:none" /> + </g> + <path + style="fill:#008000;stroke:#008000;stroke-width:0.59275198;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1;marker-end:url(#Arrow2Mend-8-0-2)" + d="m -199.6735,57.600919 h -14.81024" + id="path1171-7-6-1" + inkscape:connector-curvature="0" /> + <path + style="fill:none;stroke:#ff0000;stroke-width:0.95872593;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1;marker-end:url(#Arrow2Mend-8-3-3)" + d="m -214.95012,88.003315 h 14.32069" + id="path1171-7-1-2" + inkscape:connector-curvature="0" /> + <path + style="fill:none;stroke:#008080;stroke-width:0.81852055;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:0.81852058, 0.81852058;stroke-dashoffset:0;stroke-opacity:1" + d="M -182.99565,94.057598 V 107.01694" + id="path7040-7" + inkscape:connector-curvature="0" /> + <path + style="fill:none;stroke:#000000;stroke-width:0.81852055;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:4.91112344, 0.81852058;stroke-dashoffset:0;stroke-opacity:1" + d="m -231.7616,43.563759 v 5.457082" + id="path7149-3-7-4-0" + inkscape:connector-curvature="0" /> + <g + aria-label="[" + transform="matrix(0,-1,0.74237844,0,14.567595,39.540924)" + style="font-style:normal;font-weight:normal;font-size:3.17499995px;line-height:1.25;font-family:sans-serif;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;stroke-width:0.26458332" + id="text6872"> + <path + d="m -65.936923,-548.78511 h 8.816294 v 2.79112 h -6.82247 v 176.34952 h 6.82247 v 2.41314 h -8.816294 z" + style="font-size:50.79999924px;stroke-width:0.26458332" + id="path6874" + inkscape:connector-curvature="0" + sodipodi:nodetypes="ccccccccc" /> + </g> + <g + aria-label="[" + transform="rotate(-90,182.49521,-144.01791)" + style="font-style:normal;font-weight:normal;font-size:3.17499995px;line-height:1.25;font-family:sans-serif;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;stroke-width:0.26458332" + id="text6872-3"> + <path + d="m -63.825546,-623.34091 h 7.228794 v 2.26195 h -5.764137 l 0,127.08032 h 5.764137 v 1.88397 h -7.228794 z" + style="font-size:50.79999924px;stroke-width:0.26458332" + id="path6874-6" + inkscape:connector-curvature="0" + sodipodi:nodetypes="ccccccccc" /> + </g> + <text + xml:space="preserve" + style="font-style:normal;font-weight:normal;font-size:3.17499995px;line-height:1.25;font-family:sans-serif;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;stroke-width:0.26458332" + x="-359.80389" + y="99.104233" + id="text6929"><tspan + sodipodi:role="line" + id="tspan6927" + x="-359.80389" + y="99.104233" + style="font-style:normal;font-variant:normal;font-weight:bold;font-stretch:normal;font-size:5.64444447px;font-family:sans-serif;-inkscape-font-specification:'sans-serif Bold';stroke-width:0.26458332">dc_plane</tspan></text> + <text + xml:space="preserve" + style="font-style:normal;font-weight:normal;font-size:3.17499995px;line-height:1.25;font-family:sans-serif;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;stroke-width:0.26458332" + x="-223.56163" + y="99.142021" + id="text6933"><tspan + sodipodi:role="line" + id="tspan6931" + x="-223.56163" + y="99.142021" + style="font-style:normal;font-variant:normal;font-weight:bold;font-stretch:normal;font-size:5.64444447px;font-family:sans-serif;-inkscape-font-specification:'sans-serif Bold';stroke-width:0.26458332">dc_stream</tspan></text> + <g + aria-label="[" + transform="matrix(0,1,1,0,153.30551,96.566025)" + style="font-style:normal;font-weight:normal;font-size:3.17499995px;line-height:1.25;font-family:sans-serif;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;stroke-width:0.26458332" + id="text6872-35"> + <path + d="m -65.936923,-545.95029 h 8.816294 v 2.79112 h -6.898066 v 271.78851 h 6.898066 v 2.41314 h -8.816294 z" + style="font-size:50.79999924px;stroke-width:0.26458332" + id="path6874-62" + inkscape:connector-curvature="0" + sodipodi:nodetypes="ccccccccc" /> + </g> + <text + xml:space="preserve" + style="font-style:normal;font-weight:normal;font-size:3.17499995px;line-height:1.25;font-family:sans-serif;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;stroke-width:0.26458332" + x="-267.43958" + y="28.5028" + id="text6933-9"><tspan + sodipodi:role="line" + id="tspan6931-1" + x="-267.43958" + y="28.5028" + style="font-style:normal;font-variant:normal;font-weight:bold;font-stretch:normal;font-size:5.64444447px;font-family:sans-serif;-inkscape-font-specification:'sans-serif Bold';stroke-width:0.26458332">dc_state</tspan></text> + <g + aria-label="[" + transform="matrix(0,0.98158883,-1.0187565,0,0,-7.4835468)" + style="font-style:normal;font-variant:normal;font-weight:bold;font-stretch:normal;font-size:6.62759447px;line-height:1.25;font-family:sans-serif;-inkscape-font-specification:'sans-serif Bold';letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;stroke-width:0.5522995" + id="text6973"> + <path + d="m 23.679381,144.30265 h 3.028123 v 1.29445 h -1.820839 v 7.91629 h 1.820839 v 1.29445 h -3.028123 z" + style="font-style:normal;font-variant:normal;font-weight:bold;font-stretch:normal;font-size:11.78239059px;font-family:sans-serif;-inkscape-font-specification:'sans-serif Bold';stroke-width:0.5522995" + id="path6975" + inkscape:connector-curvature="0" + sodipodi:nodetypes="ccccccccc" /> + </g> + <text + xml:space="preserve" + style="font-style:normal;font-weight:normal;font-size:3.17499995px;line-height:1.25;font-family:sans-serif;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;stroke-width:0.26458332" + x="-142.71655" + y="18.955769" + id="text6980"><tspan + sodipodi:role="line" + id="tspan6978" + x="-142.71655" + y="18.955769" + style="font-size:4.58611107px;stroke-width:0.26458332">Code struct</tspan></text> + <g + aria-label="[" + transform="rotate(-90,94.826273,-58.762727)" + style="font-style:normal;font-weight:normal;font-size:3.17499995px;line-height:1.25;font-family:sans-serif;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;stroke-width:0.26458332" + id="text6872-35-2"> + <path + d="m -66.881863,-308.95922 h 7.115401 l 0,1.69499 h -5.197173 v 42.03568 h 5.197173 v 1.78948 h -7.115401 z" + style="font-size:50.79999924px;stroke-width:0.26458332" + id="path6874-62-7" + inkscape:connector-curvature="0" + sodipodi:nodetypes="ccccccccc" /> + </g> + <text + xml:space="preserve" + style="font-style:normal;font-weight:normal;font-size:3.17499995px;line-height:1.25;font-family:sans-serif;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;stroke-width:0.26458332" + x="-134.09625" + y="99.354439" + id="text6933-9-0"><tspan + sodipodi:role="line" + id="tspan6931-1-9" + x="-134.09625" + y="99.354439" + style="font-style:normal;font-variant:normal;font-weight:bold;font-stretch:normal;font-size:5.64444447px;font-family:sans-serif;-inkscape-font-specification:'sans-serif Bold';stroke-width:0.26458332">dc_link</tspan></text> + <g + aria-label="}" + transform="rotate(90,-145.27371,-140.09832)" + style="font-style:normal;font-weight:normal;font-size:3.17499995px;line-height:1.25;font-family:sans-serif;letter-spacing:0px;word-spacing:0px;fill:#3771c8;fill-opacity:1;stroke:none;stroke-width:0.26458332" + id="text1003"> + <path + d="m 102.58571,58.211269 h 0.86816 c 1.15755,0 3.11267,-0.177767 3.45994,-0.5333 0.35553,-0.355534 1.28925,-1.124479 1.28925,-2.306836 V -61.475482 c 0,-1.289844 0.18603,-2.228288 0.5581,-2.815332 0.37207,-0.587044 0.26105,-0.992187 1.17882,-1.215429 -0.91777,-0.206706 -0.80675,-0.603581 -1.17882,-1.190625 -0.37207,-0.587045 -0.5581,-1.529623 -0.5581,-2.827735 v -3.075781 c 0,-1.174088 -0.93372,-1.938899 -1.28925,-2.294433 -0.34727,-0.363802 -2.30239,-0.545703 -3.45994,-0.545703 h -0.86816 v -1.773536 h 0.78134 c 2.05879,0 4.63403,0.305924 5.32029,0.917774 0.69453,0.60358 1.0418,1.81901 1.0418,3.646289 v 2.976562 c 0,1.231966 0.22324,2.087728 0.66973,2.567285 0.44648,0.471289 5.80035,0.706934 6.97444,0.706934 h 0.76894 v 1.773535 h -0.76894 c -1.17409,0 -6.52796,0.239778 -6.97444,0.719336 -0.44649,0.479557 -0.66973,1.343587 -0.66973,2.59209 V 55.420742 c 0,1.827279 -0.34727,3.046842 -1.0418,3.658691 -0.68626,0.611849 -3.2615,0.917774 -5.32029,0.917774 h -0.78134 z" + style="font-size:25.39999962px;fill:#3771c8;stroke-width:0.26458332" + id="path1005" + inkscape:connector-curvature="0" + sodipodi:nodetypes="cscsscccsscsccscsscsccscsscscc" /> + </g> + <text + xml:space="preserve" + style="font-style:normal;font-weight:normal;font-size:3.17499995px;line-height:1.25;font-family:sans-serif;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;stroke-width:0.26458332" + x="-200.59984" + y="129.60852" + id="text1010"><tspan + sodipodi:role="line" + id="tspan1008" + x="-200.59984" + y="129.60852" + style="font-style:italic;font-variant:normal;font-weight:bold;font-stretch:normal;font-size:6.3499999px;font-family:sans-serif;-inkscape-font-specification:'sans-serif Bold Italic';text-align:center;text-anchor:middle;stroke-width:0.26458332">Floating point</tspan><tspan + sodipodi:role="line" + x="-200.59984" + y="137.54602" + style="font-size:6.3499999px;text-align:center;text-anchor:middle;stroke-width:0.26458332" + id="tspan1059">calculation</tspan></text> + <g + aria-label="}" + transform="rotate(90,-94.294068,-92.593178)" + style="font-style:normal;font-weight:normal;font-size:3.17499995px;line-height:1.25;font-family:sans-serif;letter-spacing:0px;word-spacing:0px;fill:#3771c8;fill-opacity:1;stroke:none;stroke-width:0.26458332" + id="text1003-5"> + <path + d="m 102.58571,58.211269 h 0.86816 c 1.15755,0 3.11267,-0.177767 3.45994,-0.5333 0.35553,-0.355534 1.10026,-1.124479 1.10026,-2.306836 V -44.637502 c 0,-1.289844 0.18603,-2.228288 0.5581,-2.815332 0.37207,-0.587044 0.45004,-0.992187 1.36781,-1.215429 -0.91777,-0.206706 -0.99574,-0.603581 -1.36781,-1.190625 -0.37207,-0.587045 -0.5581,-1.529623 -0.5581,-2.827735 v -19.913761 c 0,-1.174088 -0.74473,-1.938899 -1.10026,-2.294433 -0.34727,-0.363802 -2.30239,-0.545703 -3.45994,-0.545703 h -0.86816 v -1.773536 h 0.78134 c 2.05879,0 4.63403,0.305924 5.32029,0.917774 0.69453,0.60358 1.0418,1.81901 1.0418,3.646289 v 19.814542 c 0,1.231966 0.22324,2.087728 0.66973,2.567285 0.44648,0.471289 1.25677,0.706934 2.43086,0.706934 h 0.76894 v 1.773535 h -0.76894 c -1.17409,0 -1.98438,0.239778 -2.43086,0.719336 -0.44649,0.479557 -0.66973,1.343587 -0.66973,2.59209 v 99.897013 c 0,1.827279 -0.34727,3.046842 -1.0418,3.658691 -0.68626,0.611849 -3.2615,0.917774 -5.32029,0.917774 h -0.78134 z" + style="font-size:25.39999962px;fill:#3771c8;stroke-width:0.26458332" + id="path1005-3" + inkscape:connector-curvature="0" + sodipodi:nodetypes="cscsscccsscsccscsscsccscsscscc" /> + </g> + <text + xml:space="preserve" + style="font-style:normal;font-weight:normal;font-size:3.17499995px;line-height:1.25;font-family:sans-serif;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;stroke-width:0.26458332" + x="-137.43764" + y="122.46283" + id="text1010-5"><tspan + sodipodi:role="line" + id="tspan1008-6" + x="-137.43764" + y="122.46283" + style="font-size:6.3499999px;text-align:center;text-anchor:middle;stroke-width:0.26458332">bit-depth</tspan><tspan + sodipodi:role="line" + x="-137.43764" + y="130.40033" + style="font-size:6.3499999px;text-align:center;text-anchor:middle;stroke-width:0.26458332" + id="tspan1057">reduction/dither</tspan></text> + <text + xml:space="preserve" + style="font-style:normal;font-weight:normal;font-size:3.17499995px;line-height:1.25;font-family:sans-serif;letter-spacing:0px;word-spacing:0px;fill:#3771c8;fill-opacity:1;stroke:none;stroke-width:0.26458332;" + x="21.087883" + y="155.64751" + id="text1064" + transform="rotate(90)"><tspan + sodipodi:role="line" + id="tspan1062" + x="21.087883" + y="155.64751" + style="font-size:9.87777805px;stroke-width:0.26458332;fill:#3771c8;">}</tspan></text> + <text + xml:space="preserve" + style="font-style:normal;font-weight:normal;font-size:3.17499995px;line-height:1.25;font-family:sans-serif;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;stroke-width:0.26458332" + x="-142.71655" + y="25.939869" + id="text6980-9"><tspan + sodipodi:role="line" + id="tspan6978-1" + x="-142.71655" + y="25.939869" + style="font-size:4.58611107px;stroke-width:0.26458332">Notes</tspan></text> + </g> +</svg> diff --git a/Documentation/gpu/amdgpu/display/dcn-overview.rst b/Documentation/gpu/amdgpu/display/dcn-overview.rst new file mode 100644 index 000000000000..f98624d7828e --- /dev/null +++ b/Documentation/gpu/amdgpu/display/dcn-overview.rst @@ -0,0 +1,171 @@ +======================= +Display Core Next (DCN) +======================= + +To equip our readers with the basic knowledge of how AMD Display Core Next +(DCN) works, we need to start with an overview of the hardware pipeline. Below +you can see a picture that provides a DCN overview, keep in mind that this is a +generic diagram, and we have variations per ASIC. + +.. kernel-figure:: dc_pipeline_overview.svg + +Based on this diagram, we can pass through each block and briefly describe +them: + +* **Display Controller Hub (DCHUB)**: This is the gateway between the Scalable + Data Port (SDP) and DCN. This component has multiple features, such as memory + arbitration, rotation, and cursor manipulation. + +* **Display Pipe and Plane (DPP)**: This block provides pre-blend pixel + processing such as color space conversion, linearization of pixel data, tone + mapping, and gamut mapping. + +* **Multiple Pipe/Plane Combined (MPC)**: This component performs blending of + multiple planes, using global or per-pixel alpha. + +* **Output Pixel Processing (OPP)**: Process and format pixels to be sent to + the display. + +* **Output Pipe Timing Combiner (OPTC)**: It generates time output to combine + streams or divide capabilities. CRC values are generated in this block. + +* **Display Output (DIO)**: Codify the output to the display connected to our + GPU. + +* **Display Writeback (DWB)**: It provides the ability to write the output of + the display pipe back to memory as video frames. + +* **Multi-Media HUB (MMHUBBUB)**: Memory controller interface for DMCUB and DWB + (Note that DWB is not hooked yet). + +* **DCN Management Unit (DMU)**: It provides registers with access control and + interrupts the controller to the SOC host interrupt unit. This block includes + the Display Micro-Controller Unit - version B (DMCUB), which is handled via + firmware. + +* **DCN Clock Generator Block (DCCG)**: It provides the clocks and resets + for all of the display controller clock domains. + +* **Azalia (AZ)**: Audio engine. + +The above diagram is an architecture generalization of DCN, which means that +every ASIC has variations around this base model. Notice that the display +pipeline is connected to the Scalable Data Port (SDP) via DCHUB; you can see +the SDP as the element from our Data Fabric that feeds the display pipe. + +Always approach the DCN architecture as something flexible that can be +configured and reconfigured in multiple ways; in other words, each block can be +setup or ignored accordingly with userspace demands. For example, if we +want to drive an 8k@60Hz with a DSC enabled, our DCN may require 4 DPP and 2 +OPP. It is DC's responsibility to drive the best configuration for each +specific scenario. Orchestrate all of these components together requires a +sophisticated communication interface which is highlighted in the diagram by +the edges that connect each block; from the chart, each connection between +these blocks represents: + +1. Pixel data interface (red): Represents the pixel data flow; +2. Global sync signals (green): It is a set of synchronization signals composed + by VStartup, VUpdate, and VReady; +3. Config interface: Responsible to configure blocks; +4. Sideband signals: All other signals that do not fit the previous one. + +These signals are essential and play an important role in DCN. Nevertheless, +the Global Sync deserves an extra level of detail described in the next +section. + +All of these components are represented by a data structure named dc_state. +From DCHUB to MPC, we have a representation called dc_plane; from MPC to OPTC, +we have dc_stream, and the output (DIO) is handled by dc_link. Keep in mind +that HUBP accesses a surface using a specific format read from memory, and our +dc_plane should work to convert all pixels in the plane to something that can +be sent to the display via dc_stream and dc_link. + +Front End and Back End +---------------------- + +Display pipeline can be broken down into two components that are usually +referred as **Front End (FE)** and **Back End (BE)**, where FE consists of: + +* DCHUB (Mainly referring to a subcomponent named HUBP) +* DPP +* MPC + +On the other hand, BE consist of + +* OPP +* OPTC +* DIO (DP/HDMI stream encoder and link encoder) + +OPP and OPTC are two joining blocks between FE and BE. On a side note, this is +a one-to-one mapping of the link encoder to PHY, but we can configure the DCN +to choose which link encoder to connect to which PHY. FE's main responsibility +is to change, blend and compose pixel data, while BE's job is to frame a +generic pixel stream to a specific display's pixel stream. + +Data Flow +--------- + +Initially, data is passed in from VRAM through Data Fabric (DF) in native pixel +formats. Such data format stays through till HUBP in DCHUB, where HUBP unpacks +different pixel formats and outputs them to DPP in uniform streams through 4 +channels (1 for alpha + 3 for colors). + +The Converter and Cursor (CNVC) in DPP would then normalize the data +representation and convert them to a DCN specific floating-point format (i.e., +different from the IEEE floating-point format). In the process, CNVC also +applies a degamma function to transform the data from non-linear to linear +space to relax the floating-point calculations following. Data would stay in +this floating-point format from DPP to OPP. + +Starting OPP, because color transformation and blending have been completed +(i.e alpha can be dropped), and the end sinks do not require the precision and +dynamic range that floating points provide (i.e. all displays are in integer +depth format), bit-depth reduction/dithering would kick in. In OPP, we would +also apply a regamma function to introduce the gamma removed earlier back. +Eventually, we output data in integer format at DIO. + +Global Sync +----------- + +Many DCN registers are double buffered, most importantly the surface address. +This allows us to update DCN hardware atomically for page flips, as well as +for most other updates that don't require enabling or disabling of new pipes. + +(Note: There are many scenarios when DC will decide to reserve extra pipes +in order to support outputs that need a very high pixel clock, or for +power saving purposes.) + +These atomic register updates are driven by global sync signals in DCN. In +order to understand how atomic updates interact with DCN hardware, and how DCN +signals page flip and vblank events it is helpful to understand how global sync +is programmed. + +Global sync consists of three signals, VSTARTUP, VUPDATE, and VREADY. These are +calculated by the Display Mode Library - DML (drivers/gpu/drm/amd/display/dc/dml) +based on a large number of parameters and ensure our hardware is able to feed +the DCN pipeline without underflows or hangs in any given system configuration. +The global sync signals always happen during VBlank, are independent from the +VSync signal, and do not overlap each other. + +VUPDATE is the only signal that is of interest to the rest of the driver stack +or userspace clients as it signals the point at which hardware latches to +atomically programmed (i.e. double buffered) registers. Even though it is +independent of the VSync signal we use VUPDATE to signal the VSync event as it +provides the best indication of how atomic commits and hardware interact. + +Since DCN hardware is double-buffered the DC driver is able to program the +hardware at any point during the frame. + +The below picture illustrates the global sync signals: + +.. kernel-figure:: global_sync_vblank.svg + +These signals affect core DCN behavior. Programming them incorrectly will lead +to a number of negative consequences, most of them quite catastrophic. + +The following picture shows how global sync allows for a mailbox style of +updates, i.e. it allows for multiple re-configurations between VUpdate +events where only the last configuration programmed before the VUpdate signal +becomes effective. + +.. kernel-figure:: config_example.svg diff --git a/Documentation/gpu/amdgpu/display/display-manager.rst b/Documentation/gpu/amdgpu/display/display-manager.rst new file mode 100644 index 000000000000..7ce31f89d9a0 --- /dev/null +++ b/Documentation/gpu/amdgpu/display/display-manager.rst @@ -0,0 +1,42 @@ +====================== +AMDgpu Display Manager +====================== + +.. contents:: Table of Contents + :depth: 3 + +.. kernel-doc:: drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c + :doc: overview + +.. kernel-doc:: drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h + :internal: + +Lifecycle +========= + +.. kernel-doc:: drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c + :doc: DM Lifecycle + +.. kernel-doc:: drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c + :functions: dm_hw_init dm_hw_fini + +Interrupts +========== + +.. kernel-doc:: drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_irq.c + :doc: overview + +.. kernel-doc:: drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_irq.c + :internal: + +.. kernel-doc:: drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c + :functions: register_hpd_handlers dm_crtc_high_irq dm_pflip_high_irq + +Atomic Implementation +===================== + +.. kernel-doc:: drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c + :doc: atomic + +.. kernel-doc:: drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c + :functions: amdgpu_dm_atomic_check amdgpu_dm_atomic_commit_tail diff --git a/Documentation/gpu/amdgpu/display/global_sync_vblank.svg b/Documentation/gpu/amdgpu/display/global_sync_vblank.svg new file mode 100644 index 000000000000..48f5dc4fd5d3 --- /dev/null +++ b/Documentation/gpu/amdgpu/display/global_sync_vblank.svg @@ -0,0 +1,485 @@ +<?xml version="1.0" encoding="UTF-8" standalone="no"?> +<!-- Created with Inkscape (http://www.inkscape.org/) --> + +<svg + xmlns:dc="http://purl.org/dc/elements/1.1/" + xmlns:cc="http://creativecommons.org/ns#" + xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" + xmlns:svg="http://www.w3.org/2000/svg" + xmlns="http://www.w3.org/2000/svg" + xmlns:sodipodi="http://sodipodi.sourceforge.net/DTD/sodipodi-0.dtd" + xmlns:inkscape="http://www.inkscape.org/namespaces/inkscape" + width="232.24133mm" + height="96.174995mm" + viewBox="0 0 232.24133 96.174995" + version="1.1" + id="svg8" + inkscape:version="0.92.5 (2060ec1f9f, 2020-04-08)" + sodipodi:docname="global_sync_vblank.svg"> + <defs + id="defs2"> + <marker + inkscape:stockid="Arrow2Mend" + orient="auto" + refY="0" + refX="0" + id="Arrow2Mend" + style="overflow:visible" + inkscape:isstock="true"> + <path + id="path862" + style="fill:#800080;fill-opacity:1;fill-rule:evenodd;stroke:#800080;stroke-width:0.625;stroke-linejoin:round;stroke-opacity:1" + d="M 8.7185878,4.0337352 -2.2072895,0.01601326 8.7185884,-4.0017078 c -1.7454984,2.3720609 -1.7354408,5.6174519 -6e-7,8.035443 z" + transform="scale(-0.6)" + inkscape:connector-curvature="0" /> + </marker> + <marker + inkscape:stockid="Arrow2Send" + orient="auto" + refY="0" + refX="0" + id="Arrow2Send" + style="overflow:visible" + inkscape:isstock="true"> + <path + id="path868" + style="fill:#ff00ff;fill-opacity:1;fill-rule:evenodd;stroke:#ff00ff;stroke-width:0.625;stroke-linejoin:round;stroke-opacity:1" + d="M 8.7185878,4.0337352 -2.2072895,0.01601326 8.7185884,-4.0017078 c -1.7454984,2.3720609 -1.7354408,5.6174519 -6e-7,8.035443 z" + transform="matrix(-0.3,0,0,-0.3,0.69,0)" + inkscape:connector-curvature="0" /> + </marker> + <marker + inkscape:stockid="Arrow2Lend" + orient="auto" + refY="0" + refX="0" + id="Arrow2Lend" + style="overflow:visible" + inkscape:isstock="true"> + <path + id="path856" + style="fill:#ff00ff;fill-opacity:1;fill-rule:evenodd;stroke:#ff00ff;stroke-width:0.625;stroke-linejoin:round;stroke-opacity:1" + d="M 8.7185878,4.0337352 -2.2072895,0.01601326 8.7185884,-4.0017078 c -1.7454984,2.3720609 -1.7354408,5.6174519 -6e-7,8.035443 z" + transform="matrix(-1.1,0,0,-1.1,-1.1,0)" + inkscape:connector-curvature="0" /> + </marker> + <marker + inkscape:stockid="Arrow1Lend" + orient="auto" + refY="0" + refX="0" + id="marker1719" + style="overflow:visible" + inkscape:isstock="true"> + <path + id="path1717" + d="M 0,0 5,-5 -12.5,0 5,5 Z" + style="fill:#ff00ff;fill-opacity:1;fill-rule:evenodd;stroke:#ff00ff;stroke-width:1.00000003pt;stroke-opacity:1" + transform="matrix(-0.8,0,0,-0.8,-10,0)" + inkscape:connector-curvature="0" /> + </marker> + <marker + inkscape:stockid="Arrow1Lend" + orient="auto" + refY="0" + refX="0" + id="marker1661" + style="overflow:visible" + inkscape:isstock="true"> + <path + id="path1659" + d="M 0,0 5,-5 -12.5,0 5,5 Z" + style="fill:#ff00ff;fill-opacity:1;fill-rule:evenodd;stroke:#ff00ff;stroke-width:1.00000003pt;stroke-opacity:1" + transform="matrix(-0.8,0,0,-0.8,-10,0)" + inkscape:connector-curvature="0" /> + </marker> + <marker + inkscape:isstock="true" + style="overflow:visible" + id="marker1311" + refX="0" + refY="0" + orient="auto" + inkscape:stockid="Arrow1Lend" + inkscape:collect="always"> + <path + transform="matrix(-0.8,0,0,-0.8,-10,0)" + style="fill:#ff0000;fill-opacity:1;fill-rule:evenodd;stroke:#ff0000;stroke-width:1.00000003pt;stroke-opacity:1" + d="M 0,0 5,-5 -12.5,0 5,5 Z" + id="path1309" + inkscape:connector-curvature="0" /> + </marker> + <marker + inkscape:isstock="true" + style="overflow:visible" + id="marker1253" + refX="0" + refY="0" + orient="auto" + inkscape:stockid="Arrow1Lstart"> + <path + transform="matrix(0.8,0,0,0.8,10,0)" + style="fill:#ff0000;fill-opacity:1;fill-rule:evenodd;stroke:#ff0000;stroke-width:1.00000003pt;stroke-opacity:1" + d="M 0,0 5,-5 -12.5,0 5,5 Z" + id="path1251" + inkscape:connector-curvature="0" /> + </marker> + <marker + inkscape:stockid="Arrow1Lend" + orient="auto" + refY="0" + refX="0" + id="Arrow1Lend" + style="overflow:visible" + inkscape:isstock="true" + inkscape:collect="always"> + <path + id="path838" + d="M 0,0 5,-5 -12.5,0 5,5 Z" + style="fill:#ff0000;fill-opacity:1;fill-rule:evenodd;stroke:#ff0000;stroke-width:1.00000003pt;stroke-opacity:1" + transform="matrix(-0.8,0,0,-0.8,-10,0)" + inkscape:connector-curvature="0" /> + </marker> + <marker + inkscape:stockid="Arrow1Lstart" + orient="auto" + refY="0" + refX="0" + id="Arrow1Lstart" + style="overflow:visible" + inkscape:isstock="true" + inkscape:collect="always"> + <path + id="path835" + d="M 0,0 5,-5 -12.5,0 5,5 Z" + style="fill:#ff0000;fill-opacity:1;fill-rule:evenodd;stroke:#ff0000;stroke-width:1.00000003pt;stroke-opacity:1" + transform="matrix(0.8,0,0,0.8,10,0)" + inkscape:connector-curvature="0" /> + </marker> + <marker + inkscape:stockid="Arrow1Send" + orient="auto" + refY="0" + refX="0" + id="Arrow1Send" + style="overflow:visible" + inkscape:isstock="true"> + <path + id="path850" + d="M 0,0 5,-5 -12.5,0 5,5 Z" + style="fill:#000000;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:1.00000003pt;stroke-opacity:1" + transform="matrix(-0.2,0,0,-0.2,-1.2,0)" + inkscape:connector-curvature="0" /> + </marker> + <marker + inkscape:stockid="Arrow2Sstart" + orient="auto" + refY="0" + refX="0" + id="Arrow2Sstart" + style="overflow:visible" + inkscape:isstock="true"> + <path + id="path865" + style="fill:#000000;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:0.625;stroke-linejoin:round;stroke-opacity:1" + d="M 8.7185878,4.0337352 -2.2072895,0.01601326 8.7185884,-4.0017078 c -1.7454984,2.3720609 -1.7354408,5.6174519 -6e-7,8.035443 z" + transform="matrix(0.3,0,0,0.3,-0.69,0)" + inkscape:connector-curvature="0" /> + </marker> + <marker + inkscape:stockid="Arrow2Mend" + orient="auto" + refY="0" + refX="0" + id="Arrow2Mend-2" + style="overflow:visible" + inkscape:isstock="true"> + <path + inkscape:connector-curvature="0" + id="path862-3" + style="fill:#800080;fill-opacity:1;fill-rule:evenodd;stroke:#800080;stroke-width:0.625;stroke-linejoin:round;stroke-opacity:1" + d="M 8.7185878,4.0337352 -2.2072895,0.01601326 8.7185884,-4.0017078 c -1.7454984,2.3720609 -1.7354408,5.6174519 -6e-7,8.035443 z" + transform="scale(-0.6)" /> + </marker> + <marker + inkscape:stockid="Arrow2Mend" + orient="auto" + refY="0" + refX="0" + id="Arrow2Mend-2-5" + style="overflow:visible" + inkscape:isstock="true"> + <path + inkscape:connector-curvature="0" + id="path862-3-9" + style="fill:#800080;fill-opacity:1;fill-rule:evenodd;stroke:#800080;stroke-width:0.625;stroke-linejoin:round;stroke-opacity:1" + d="M 8.7185878,4.0337352 -2.2072895,0.01601326 8.7185884,-4.0017078 c -1.7454984,2.3720609 -1.7354408,5.6174519 -6e-7,8.035443 z" + transform="scale(-0.6)" /> + </marker> + </defs> + <sodipodi:namedview + id="base" + pagecolor="#ffffff" + bordercolor="#666666" + borderopacity="1.0" + inkscape:pageopacity="0.0" + inkscape:pageshadow="2" + inkscape:zoom="1.979899" + inkscape:cx="747.52324" + inkscape:cy="319.84503" + inkscape:document-units="mm" + inkscape:current-layer="layer1" + showgrid="true" + inkscape:window-width="3840" + inkscape:window-height="2096" + inkscape:window-x="0" + inkscape:window-y="27" + inkscape:window-maximized="1" + fit-margin-top="0" + fit-margin-left="0" + fit-margin-right="0" + fit-margin-bottom="0"> + <inkscape:grid + type="xygrid" + id="grid815" + originx="15.282997" + originy="-184.54792" /> + </sodipodi:namedview> + <metadata + id="metadata5"> + <rdf:RDF> + <cc:Work + rdf:about=""> + <dc:format>image/svg+xml</dc:format> + <dc:type + rdf:resource="http://purl.org/dc/dcmitype/StillImage" /> + <dc:title /> + </cc:Work> + </rdf:RDF> + </metadata> + <g + inkscape:label="Layer 1" + inkscape:groupmode="layer" + id="layer1" + transform="translate(15.282998,-16.277083)"> + <path + style="fill:none;stroke:#000000;stroke-width:0.5291667;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1" + d="M 15.875,27.125001 V 16.541666 H 26.458333 V 27.125001 H 177.27084 V 16.541666 h 10.58333 v 10.583335 h 29.10416" + id="path817" + inkscape:connector-curvature="0" + sodipodi:nodetypes="ccccccccc" /> + <path + style="fill:none;stroke:#000000;stroke-width:0.5291667;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1" + d="M 15.875,37.708334 H 44.979166 V 48.291667 H 100.54167 V 37.708334 H 206.375 v 10.583333 h 10.58333" + id="path819" + inkscape:connector-curvature="0" /> + <path + style="fill:none;stroke:#000000;stroke-width:0.5291667;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1" + d="m 15.875,66.8125 h 97.89583 V 56.229167 h 7.9375 V 66.8125 h 92.60417" + id="path821" + inkscape:connector-curvature="0" /> + <path + style="fill:none;stroke:#000000;stroke-width:0.5291667;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1" + d="m 15.875,85.333334 c 0,0 132.29166,0 132.29166,0 V 74.75 h 15.875 v 10.583334 h 47.625" + id="path823" + inkscape:connector-curvature="0" /> + <path + style="fill:none;stroke:#000000;stroke-width:0.5291667;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1" + d="M 15.875,101.20833 H 187.85416 V 90.625 h 10.58334 v 10.58333 h 10.58333" + id="path825" + inkscape:connector-curvature="0" /> + <path + style="fill:none;stroke:#000000;stroke-width:0.5291667;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:0.52916667, 0.52916667;stroke-dashoffset:0;stroke-opacity:1" + d="M 100.54167,48.291667 V 111.79167" + id="path827" + inkscape:connector-curvature="0" /> + <path + style="fill:none;stroke:#000000;stroke-width:0.5291667;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:0.52916667, 0.52916667;stroke-dashoffset:0;stroke-opacity:1" + d="m 113.77083,66.8125 v 44.97917" + id="path829" + inkscape:connector-curvature="0" /> + <path + style="fill:none;stroke:#000000;stroke-width:0.5291667;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:0.52916667, 0.52916667;stroke-dashoffset:0;stroke-opacity:1" + d="M 206.375,48.291667 V 109.14583" + id="path831" + inkscape:connector-curvature="0" /> + <path + style="fill:none;stroke:#ff0000;stroke-width:0.26458332px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;marker-start:url(#Arrow1Lstart);marker-end:url(#Arrow1Lend)" + d="m 100.54167,106.5 h 13.22916" + id="path833" + inkscape:connector-curvature="0" /> + <path + style="fill:none;stroke:#ff0000;stroke-width:0.26458332px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;marker-start:url(#marker1253);marker-end:url(#marker1311)" + d="M 113.77083,106.5 H 206.375" + id="path1243" + inkscape:connector-curvature="0" /> + <text + xml:space="preserve" + style="font-style:normal;font-weight:normal;font-size:3.17499995px;line-height:1.25;font-family:sans-serif;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;stroke-width:0.26458332" + x="105.83333" + y="111.79166" + id="text1405"><tspan + sodipodi:role="line" + id="tspan1403" + x="105.83333" + y="111.79166" + style="stroke-width:0.26458332">To</tspan></text> + <text + xml:space="preserve" + style="font-style:normal;font-weight:normal;font-size:3.17499995px;line-height:1.25;font-family:sans-serif;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;stroke-width:0.26458332" + x="145.52083" + y="111.79166" + id="text1409"><tspan + sodipodi:role="line" + id="tspan1407" + x="145.52083" + y="111.79166" + style="stroke-width:0.26458332">VStartup Period</tspan></text> + <text + xml:space="preserve" + style="font-style:normal;font-weight:normal;font-size:3.17499995px;line-height:1.25;font-family:sans-serif;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;stroke-width:0.26458332" + x="156.01123" + y="78.71875" + id="text1413"><tspan + sodipodi:role="line" + x="156.01123" + y="78.71875" + style="font-weight:bold;text-align:center;text-anchor:middle;stroke-width:0.26458332" + id="tspan1415">VUpdate</tspan><tspan + sodipodi:role="line" + x="156.01123" + y="82.6875" + style="font-weight:bold;text-align:center;text-anchor:middle;stroke-width:0.26458332" + id="tspan1440">Width</tspan></text> + <text + xml:space="preserve" + style="font-style:normal;font-weight:normal;font-size:3.17499995px;line-height:1.25;font-family:sans-serif;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;stroke-width:0.26458332" + x="173.77611" + y="92.703873" + id="text1413-3"><tspan + sodipodi:role="line" + id="tspan1411-6" + x="173.77611" + y="92.703873" + style="font-weight:bold;text-align:center;text-anchor:middle;stroke-width:0.26458332">VReady</tspan><tspan + sodipodi:role="line" + x="173.77611" + y="96.672623" + style="font-weight:bold;text-align:center;text-anchor:middle;stroke-width:0.26458332" + id="tspan1415-7">Offset</tspan></text> + <text + xml:space="preserve" + style="font-style:normal;font-weight:normal;font-size:3.17499995px;line-height:1.25;font-family:sans-serif;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;stroke-width:0.26458332" + x="135.78951" + y="70.78125" + id="text1413-5"><tspan + sodipodi:role="line" + x="135.78951" + y="70.78125" + style="font-weight:bold;text-align:center;text-anchor:middle;stroke-width:0.26458332" + id="tspan1440-5">VUpdate</tspan><tspan + sodipodi:role="line" + x="135.78951" + y="74.75" + style="font-weight:bold;text-align:center;text-anchor:middle;stroke-width:0.26458332" + id="tspan1465">Offset</tspan></text> + <text + xml:space="preserve" + style="font-style:normal;font-weight:normal;font-size:3.17499995px;line-height:1.25;font-family:sans-serif;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;stroke-width:0.26458332" + x="137.39433" + y="48.291664" + id="text1479"><tspan + sodipodi:role="line" + id="tspan1477" + x="137.39433" + y="48.291664" + style="font-weight:bold;stroke-width:0.26458332">VSTARTUP_START</tspan></text> + <text + xml:space="preserve" + style="font-style:normal;font-weight:normal;font-size:3.17499995px;line-height:1.25;font-family:sans-serif;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;stroke-width:0.26458332" + x="-5.4806676" + y="22.778271" + id="text1479-1"><tspan + sodipodi:role="line" + id="tspan1477-2" + x="-5.4806676" + y="22.778271" + style="font-weight:bold;font-size:4.93888903px;stroke-width:0.26458332">VSYNC</tspan></text> + <text + xml:space="preserve" + style="font-style:normal;font-weight:normal;font-size:3.17499995px;line-height:1.25;font-family:sans-serif;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;stroke-width:0.26458332" + x="-9.3767252" + y="45.64584" + id="text1479-1-7"><tspan + sodipodi:role="line" + id="tspan1477-2-0" + x="-9.3767252" + y="45.64584" + style="font-weight:bold;font-size:5.64444447px;stroke-width:0.26458332">VBlank</tspan></text> + <text + xml:space="preserve" + style="font-style:normal;font-weight:normal;font-size:3.17499995px;line-height:1.25;font-family:sans-serif;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;stroke-width:0.26458332" + x="-15.310558" + y="64.92263" + id="text1479-1-7-9"><tspan + sodipodi:role="line" + id="tspan1477-2-0-3" + x="-15.310558" + y="64.92263" + style="font-weight:bold;font-size:5.64444447px;stroke-width:0.26458332">VStartup</tspan></text> + <text + xml:space="preserve" + style="font-style:normal;font-weight:normal;font-size:3.17499995px;line-height:1.25;font-family:sans-serif;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;stroke-width:0.26458332" + x="-14.17781" + y="85.144356" + id="text1479-1-7-9-6"><tspan + sodipodi:role="line" + id="tspan1477-2-0-3-0" + x="-14.17781" + y="85.144356" + style="font-weight:bold;font-size:5.64444447px;stroke-width:0.26458332">VUpdate</tspan></text> + <text + xml:space="preserve" + style="font-style:normal;font-weight:normal;font-size:3.17499995px;line-height:1.25;font-family:sans-serif;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;stroke-width:0.26458332" + x="-11.052421" + y="101.39733" + id="text1479-1-7-9-6-6"><tspan + sodipodi:role="line" + id="tspan1477-2-0-3-0-2" + x="-11.052421" + y="101.39733" + style="font-weight:bold;font-size:5.64444447px;stroke-width:0.26458332">VReady</tspan></text> + <g + id="g5189" + transform="translate(269.875,-14.287499)"> + <path + sodipodi:nodetypes="cc" + inkscape:connector-curvature="0" + id="path5143" + d="m -202.40625,45.645828 3.96875,-7.9375" + style="fill:none;stroke:#000000;stroke-width:0.5291667;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1" /> + <path + sodipodi:nodetypes="cc" + inkscape:connector-curvature="0" + id="path5143-2" + d="m -199.76042,45.645828 3.96874,-7.937499" + style="fill:none;stroke:#000000;stroke-width:0.52916676;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1" /> + </g> + <g + id="g5189-3" + transform="translate(268.55209,7.9375003)"> + <path + sodipodi:nodetypes="cc" + inkscape:connector-curvature="0" + id="path5143-6" + d="m -202.40625,45.645828 3.96875,-7.9375" + style="fill:none;stroke:#000000;stroke-width:0.5291667;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1" /> + <path + sodipodi:nodetypes="cc" + inkscape:connector-curvature="0" + id="path5143-2-1" + d="m -199.76042,45.645828 3.96874,-7.937499" + style="fill:none;stroke:#000000;stroke-width:0.52916676;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1" /> + </g> + </g> +</svg> diff --git a/Documentation/gpu/amdgpu/display/index.rst b/Documentation/gpu/amdgpu/display/index.rst new file mode 100644 index 000000000000..c1fb2fb3c710 --- /dev/null +++ b/Documentation/gpu/amdgpu/display/index.rst @@ -0,0 +1,31 @@ +.. _amdgpu-display-core: + +=================================== +drm/amd/display - Display Core (DC) +=================================== + +AMD display engine is partially shared with other operating systems; for this +reason, our Display Core Driver is divided into two pieces: + +1. **Display Core (DC)** contains the OS-agnostic components. Things like + hardware programming and resource management are handled here. +2. **Display Manager (DM)** contains the OS-dependent components. Hooks to the + amdgpu base driver and DRM are implemented here. + +The display pipe is responsible for "scanning out" a rendered frame from the +GPU memory (also called VRAM, FrameBuffer, etc.) to a display. In other words, +it would: + +1. Read frame information from memory; +2. Perform required transformation; +3. Send pixel data to sink devices. + +If you want to learn more about our driver details, take a look at the below +table of content: + +.. toctree:: + + display-manager.rst + dc-debug.rst + dcn-overview.rst + dc-glossary.rst diff --git a/Documentation/gpu/amdgpu/driver-core.rst b/Documentation/gpu/amdgpu/driver-core.rst new file mode 100644 index 000000000000..ebf5932845a9 --- /dev/null +++ b/Documentation/gpu/amdgpu/driver-core.rst @@ -0,0 +1,182 @@ +============================ + Core Driver Infrastructure +============================ + +GPU Hardware Structure +====================== + +Each ASIC is a collection of hardware blocks. We refer to them as +"IPs" (Intellectual Property blocks). Each IP encapsulates certain +functionality. IPs are versioned and can also be mixed and matched. +E.g., you might have two different ASICs that both have System DMA (SDMA) 5.x IPs. +The driver is arranged by IPs. There are driver components to handle +the initialization and operation of each IP. There are also a bunch +of smaller IPs that don't really need much if any driver interaction. +Those end up getting lumped into the common stuff in the soc files. +The soc files (e.g., vi.c, soc15.c nv.c) contain code for aspects of +the SoC itself rather than specific IPs. E.g., things like GPU resets +and register access functions are SoC dependent. + +An APU contains more than just CPU and GPU, it also contains all of +the platform stuff (audio, usb, gpio, etc.). Also, a lot of +components are shared between the CPU, platform, and the GPU (e.g., +SMU, PSP, etc.). Specific components (CPU, GPU, etc.) usually have +their interface to interact with those common components. For things +like S0i3 there is a ton of coordination required across all the +components, but that is probably a bit beyond the scope of this +section. + +With respect to the GPU, we have the following major IPs: + +GMC (Graphics Memory Controller) + This was a dedicated IP on older pre-vega chips, but has since + become somewhat decentralized on vega and newer chips. They now + have dedicated memory hubs for specific IPs or groups of IPs. We + still treat it as a single component in the driver however since + the programming model is still pretty similar. This is how the + different IPs on the GPU get the memory (VRAM or system memory). + It also provides the support for per process GPU virtual address + spaces. + +IH (Interrupt Handler) + This is the interrupt controller on the GPU. All of the IPs feed + their interrupts into this IP and it aggregates them into a set of + ring buffers that the driver can parse to handle interrupts from + different IPs. + +PSP (Platform Security Processor) + This handles security policy for the SoC and executes trusted + applications, and validates and loads firmwares for other blocks. + +SMU (System Management Unit) + This is the power management microcontroller. It manages the entire + SoC. The driver interacts with it to control power management + features like clocks, voltages, power rails, etc. + +DCN (Display Controller Next) + This is the display controller. It handles the display hardware. + It is described in more details in :ref:`Display Core <amdgpu-display-core>`. + +SDMA (System DMA) + This is a multi-purpose DMA engine. The kernel driver uses it for + various things including paging and GPU page table updates. It's also + exposed to userspace for use by user mode drivers (OpenGL, Vulkan, + etc.) + +GC (Graphics and Compute) + This is the graphics and compute engine, i.e., the block that + encompasses the 3D pipeline and and shader blocks. This is by far the + largest block on the GPU. The 3D pipeline has tons of sub-blocks. In + addition to that, it also contains the CP microcontrollers (ME, PFP, + CE, MEC) and the RLC microcontroller. It's exposed to userspace for + user mode drivers (OpenGL, Vulkan, OpenCL, etc.) + +VCN (Video Core Next) + This is the multi-media engine. It handles video and image encode and + decode. It's exposed to userspace for user mode drivers (VA-API, + OpenMAX, etc.) + +Graphics and Compute Microcontrollers +------------------------------------- + +CP (Command Processor) + The name for the hardware block that encompasses the front end of the + GFX/Compute pipeline. Consists mainly of a bunch of microcontrollers + (PFP, ME, CE, MEC). The firmware that runs on these microcontrollers + provides the driver interface to interact with the GFX/Compute engine. + + MEC (MicroEngine Compute) + This is the microcontroller that controls the compute queues on the + GFX/compute engine. + + MES (MicroEngine Scheduler) + This is a new engine for managing queues. This is currently unused. + +RLC (RunList Controller) + This is another microcontroller in the GFX/Compute engine. It handles + power management related functionality within the GFX/Compute engine. + The name is a vestige of old hardware where it was originally added + and doesn't really have much relation to what the engine does now. + +Driver Structure +================ + +In general, the driver has a list of all of the IPs on a particular +SoC and for things like init/fini/suspend/resume, more or less just +walks the list and handles each IP. + +Some useful constructs: + +KIQ (Kernel Interface Queue) + This is a control queue used by the kernel driver to manage other gfx + and compute queues on the GFX/compute engine. You can use it to + map/unmap additional queues, etc. + +IB (Indirect Buffer) + A command buffer for a particular engine. Rather than writing + commands directly to the queue, you can write the commands into a + piece of memory and then put a pointer to the memory into the queue. + The hardware will then follow the pointer and execute the commands in + the memory, then returning to the rest of the commands in the ring. + +.. _amdgpu_memory_domains: + +Memory Domains +============== + +.. kernel-doc:: include/uapi/drm/amdgpu_drm.h + :doc: memory domains + +Buffer Objects +============== + +.. kernel-doc:: drivers/gpu/drm/amd/amdgpu/amdgpu_object.c + :doc: amdgpu_object + +.. kernel-doc:: drivers/gpu/drm/amd/amdgpu/amdgpu_object.c + :internal: + +PRIME Buffer Sharing +==================== + +.. kernel-doc:: drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c + :doc: PRIME Buffer Sharing + +.. kernel-doc:: drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c + :internal: + +MMU Notifier +============ + +.. kernel-doc:: drivers/gpu/drm/amd/amdgpu/amdgpu_mn.c + :doc: MMU Notifier + +.. kernel-doc:: drivers/gpu/drm/amd/amdgpu/amdgpu_mn.c + :internal: + +AMDGPU Virtual Memory +===================== + +.. kernel-doc:: drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c + :doc: GPUVM + +.. kernel-doc:: drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c + :internal: + +Interrupt Handling +================== + +.. kernel-doc:: drivers/gpu/drm/amd/amdgpu/amdgpu_irq.c + :doc: Interrupt Handling + +.. kernel-doc:: drivers/gpu/drm/amd/amdgpu/amdgpu_irq.c + :internal: + +IP Blocks +========= + +.. kernel-doc:: drivers/gpu/drm/amd/include/amd_shared.h + :doc: IP Blocks + +.. kernel-doc:: drivers/gpu/drm/amd/include/amd_shared.h + :identifiers: amd_ip_block_type amd_ip_funcs diff --git a/Documentation/gpu/amdgpu/driver-misc.rst b/Documentation/gpu/amdgpu/driver-misc.rst new file mode 100644 index 000000000000..e3d6b2fa2493 --- /dev/null +++ b/Documentation/gpu/amdgpu/driver-misc.rst @@ -0,0 +1,112 @@ +================================ + Misc AMDGPU driver information +================================ + +GPU Product Information +======================= + +Information about the GPU can be obtained on certain cards +via sysfs + +product_name +------------ + +.. kernel-doc:: drivers/gpu/drm/amd/amdgpu/amdgpu_device.c + :doc: product_name + +product_number +-------------- + +.. kernel-doc:: drivers/gpu/drm/amd/amdgpu/amdgpu_device.c + :doc: product_name + +serial_number +------------- + +.. kernel-doc:: drivers/gpu/drm/amd/amdgpu/amdgpu_device.c + :doc: serial_number + +unique_id +--------- + +.. kernel-doc:: drivers/gpu/drm/amd/pm/amdgpu_pm.c + :doc: unique_id + +GPU Memory Usage Information +============================ + +Various memory accounting can be accessed via sysfs + +mem_info_vram_total +------------------- + +.. kernel-doc:: drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c + :doc: mem_info_vram_total + +mem_info_vram_used +------------------ + +.. kernel-doc:: drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c + :doc: mem_info_vram_used + +mem_info_vis_vram_total +----------------------- + +.. kernel-doc:: drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c + :doc: mem_info_vis_vram_total + +mem_info_vis_vram_used +---------------------- + +.. kernel-doc:: drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c + :doc: mem_info_vis_vram_used + +mem_info_gtt_total +------------------ + +.. kernel-doc:: drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c + :doc: mem_info_gtt_total + +mem_info_gtt_used +----------------- + +.. kernel-doc:: drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c + :doc: mem_info_gtt_used + +PCIe Accounting Information +=========================== + +pcie_bw +------- + +.. kernel-doc:: drivers/gpu/drm/amd/pm/amdgpu_pm.c + :doc: pcie_bw + +pcie_replay_count +----------------- + +.. kernel-doc:: drivers/gpu/drm/amd/amdgpu/amdgpu_device.c + :doc: pcie_replay_count + +GPU SmartShift Information +========================== + +GPU SmartShift information via sysfs + +smartshift_apu_power +-------------------- + +.. kernel-doc:: drivers/gpu/drm/amd/pm/amdgpu_pm.c + :doc: smartshift_apu_power + +smartshift_dgpu_power +--------------------- + +.. kernel-doc:: drivers/gpu/drm/amd/pm/amdgpu_pm.c + :doc: smartshift_dgpu_power + +smartshift_bias +--------------- + +.. kernel-doc:: drivers/gpu/drm/amd/pm/amdgpu_pm.c + :doc: smartshift_bias diff --git a/Documentation/gpu/amdgpu/index.rst b/Documentation/gpu/amdgpu/index.rst new file mode 100644 index 000000000000..a24e1cfa7407 --- /dev/null +++ b/Documentation/gpu/amdgpu/index.rst @@ -0,0 +1,17 @@ +========================== + drm/amdgpu AMDgpu driver +========================== + +The drm/amdgpu driver supports all AMD Radeon GPUs based on the Graphics Core +Next (GCN) architecture. + +.. toctree:: + + module-parameters + driver-core + display/index + xgmi + ras + thermal + driver-misc + amdgpu-glossary diff --git a/Documentation/gpu/amdgpu/module-parameters.rst b/Documentation/gpu/amdgpu/module-parameters.rst new file mode 100644 index 000000000000..ea538c8dda35 --- /dev/null +++ b/Documentation/gpu/amdgpu/module-parameters.rst @@ -0,0 +1,7 @@ +=================== + Module Parameters +=================== + +The amdgpu driver supports the following module parameters: + +.. kernel-doc:: drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c diff --git a/Documentation/gpu/amdgpu/ras.rst b/Documentation/gpu/amdgpu/ras.rst new file mode 100644 index 000000000000..047f76e395cf --- /dev/null +++ b/Documentation/gpu/amdgpu/ras.rst @@ -0,0 +1,62 @@ +==================== + AMDGPU RAS Support +==================== + +The AMDGPU RAS interfaces are exposed via sysfs (for informational queries) and +debugfs (for error injection). + +RAS debugfs/sysfs Control and Error Injection Interfaces +======================================================== + +.. kernel-doc:: drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c + :doc: AMDGPU RAS debugfs control interface + +RAS Reboot Behavior for Unrecoverable Errors +============================================ + +.. kernel-doc:: drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c + :doc: AMDGPU RAS Reboot Behavior for Unrecoverable Errors + +RAS Error Count sysfs Interface +=============================== + +.. kernel-doc:: drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c + :doc: AMDGPU RAS sysfs Error Count Interface + +RAS EEPROM debugfs Interface +============================ + +.. kernel-doc:: drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c + :doc: AMDGPU RAS debugfs EEPROM table reset interface + +RAS VRAM Bad Pages sysfs Interface +================================== + +.. kernel-doc:: drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c + :doc: AMDGPU RAS sysfs gpu_vram_bad_pages Interface + +Sample Code +=========== +Sample code for testing error injection can be found here: +https://cgit.freedesktop.org/mesa/drm/tree/tests/amdgpu/ras_tests.c + +This is part of the libdrm amdgpu unit tests which cover several areas of the GPU. +There are four sets of tests: + +RAS Basic Test + +The test verifies the RAS feature enabled status and makes sure the necessary sysfs and debugfs files +are present. + +RAS Query Test + +This test checks the RAS availability and enablement status for each supported IP block as well as +the error counts. + +RAS Inject Test + +This test injects errors for each IP. + +RAS Disable Test + +This test tests disabling of RAS features for each IP block. diff --git a/Documentation/gpu/amdgpu/thermal.rst b/Documentation/gpu/amdgpu/thermal.rst new file mode 100644 index 000000000000..8aeb0186c9ef --- /dev/null +++ b/Documentation/gpu/amdgpu/thermal.rst @@ -0,0 +1,65 @@ +=========================================== + GPU Power/Thermal Controls and Monitoring +=========================================== + +HWMON Interfaces +================ + +.. kernel-doc:: drivers/gpu/drm/amd/pm/amdgpu_pm.c + :doc: hwmon + +GPU sysfs Power State Interfaces +================================ + +GPU power controls are exposed via sysfs files. + +power_dpm_state +--------------- + +.. kernel-doc:: drivers/gpu/drm/amd/pm/amdgpu_pm.c + :doc: power_dpm_state + +power_dpm_force_performance_level +--------------------------------- + +.. kernel-doc:: drivers/gpu/drm/amd/pm/amdgpu_pm.c + :doc: power_dpm_force_performance_level + +pp_table +-------- + +.. kernel-doc:: drivers/gpu/drm/amd/pm/amdgpu_pm.c + :doc: pp_table + +pp_od_clk_voltage +----------------- + +.. kernel-doc:: drivers/gpu/drm/amd/pm/amdgpu_pm.c + :doc: pp_od_clk_voltage + +pp_dpm_* +-------- + +.. kernel-doc:: drivers/gpu/drm/amd/pm/amdgpu_pm.c + :doc: pp_dpm_sclk pp_dpm_mclk pp_dpm_socclk pp_dpm_fclk pp_dpm_dcefclk pp_dpm_pcie + +pp_power_profile_mode +--------------------- + +.. kernel-doc:: drivers/gpu/drm/amd/pm/amdgpu_pm.c + :doc: pp_power_profile_mode + +\*_busy_percent +--------------- + +.. kernel-doc:: drivers/gpu/drm/amd/pm/amdgpu_pm.c + :doc: gpu_busy_percent + +.. kernel-doc:: drivers/gpu/drm/amd/pm/amdgpu_pm.c + :doc: mem_busy_percent + +gpu_metrics +----------- + +.. kernel-doc:: drivers/gpu/drm/amd/pm/amdgpu_pm.c + :doc: gpu_metrics diff --git a/Documentation/gpu/amdgpu/xgmi.rst b/Documentation/gpu/amdgpu/xgmi.rst new file mode 100644 index 000000000000..23f2856f4524 --- /dev/null +++ b/Documentation/gpu/amdgpu/xgmi.rst @@ -0,0 +1,5 @@ +===================== + AMDGPU XGMI Support +===================== + +.. kernel-doc:: drivers/gpu/drm/amd/amdgpu/amdgpu_xgmi.c diff --git a/Documentation/gpu/drivers.rst b/Documentation/gpu/drivers.rst index b4a0ed3ca961..3a52f48215a3 100644 --- a/Documentation/gpu/drivers.rst +++ b/Documentation/gpu/drivers.rst @@ -4,8 +4,7 @@ GPU Driver Documentation .. toctree:: - amdgpu - amdgpu-dc + amdgpu/index i915 mcde meson diff --git a/Documentation/gpu/todo.rst b/Documentation/gpu/todo.rst index f504d363fef5..da138dd39883 100644 --- a/Documentation/gpu/todo.rst +++ b/Documentation/gpu/todo.rst @@ -646,6 +646,17 @@ See drivers/gpu/drm/amd/display/TODO for tasks. Contact: Harry Wentland, Alex Deucher +vmwgfx: Replace hashtable with Linux' implementation +---------------------------------------------------- + +The vmwgfx driver uses its own hashtable implementation. Replace the +code with Linux' implementation and update the callers. It's mostly a +refactoring task, but the interfaces are different. + +Contact: Zack Rusin, Thomas Zimmermann <tzimmermann@suse.de> + +Level: Intermediate + Bootsplash ========== diff --git a/Documentation/hwmon/asus_wmi_ec_sensors.rst b/Documentation/hwmon/asus_wmi_ec_sensors.rst new file mode 100644 index 000000000000..1b287f229e86 --- /dev/null +++ b/Documentation/hwmon/asus_wmi_ec_sensors.rst @@ -0,0 +1,38 @@ +.. SPDX-License-Identifier: GPL-2.0-or-later + +Kernel driver asus_wmi_ec_sensors +================================= + +Supported boards: + * PRIME X570-PRO, + * Pro WS X570-ACE, + * ROG CROSSHAIR VIII DARK HERO, + * ROG CROSSHAIR VIII FORMULA, + * ROG CROSSHAIR VIII HERO, + * ROG STRIX B550-E GAMING, + * ROG STRIX B550-I GAMING, + * ROG STRIX X570-E GAMING. + +Authors: + - Eugene Shalygin <eugene.shalygin@gmail.com> + +Description: +------------ +ASUS mainboards publish hardware monitoring information via Super I/O +chip and the ACPI embedded controller (EC) registers. Some of the sensors +are only available via the EC. + +ASUS WMI interface provides a method (BREC) to read data from EC registers, +which is utilized by this driver to publish those sensor readings to the +HWMON system. The driver is aware of and reads the following sensors: + +1. Chipset (PCH) temperature +2. CPU package temperature +3. Motherboard temperature +4. Readings from the T_Sensor header +5. VRM temperature +6. CPU_Opt fan RPM +7. Chipset fan RPM +8. Readings from the "Water flow meter" header (RPM) +9. Readings from the "Water In" and "Water Out" temperature headers +10. CPU current diff --git a/Documentation/hwmon/asus_wmi_sensors.rst b/Documentation/hwmon/asus_wmi_sensors.rst new file mode 100644 index 000000000000..8f2096cf5183 --- /dev/null +++ b/Documentation/hwmon/asus_wmi_sensors.rst @@ -0,0 +1,78 @@ +.. SPDX-License-Identifier: GPL-2.0-or-later + +Kernel driver asus_wmi_sensors +================================= + +Supported boards: + * PRIME X399-A, + * PRIME X470-PRO, + * ROG CROSSHAIR VI EXTREME, + * ROG CROSSHAIR VI HERO, + * ROG CROSSHAIR VI HERO (WI-FI AC), + * ROG CROSSHAIR VII HERO, + * ROG CROSSHAIR VII HERO (WI-FI), + * ROG STRIX B450-E GAMING, + * ROG STRIX B450-F GAMING, + * ROG STRIX B450-I GAMING, + * ROG STRIX X399-E GAMING, + * ROG STRIX X470-F GAMING, + * ROG STRIX X470-I GAMING, + * ROG ZENITH EXTREME, + * ROG ZENITH EXTREME ALPHA. + +Authors: + - Ed Brindley <kernel@maidavale.org> + +Description: +------------ +ASUS mainboards publish hardware monitoring information via WMI interface. + +ASUS WMI interface provides a methods to get list of sensors and values of +such, which is utilized by this driver to publish those sensor readings to the +HWMON system. + +The driver is aware of and reads the following sensors: + * CPU Core Voltage, + * CPU SOC Voltage, + * DRAM Voltage, + * VDDP Voltage, + * 1.8V PLL Voltage, + * +12V Voltage, + * +5V Voltage, + * 3VSB Voltage, + * VBAT Voltage, + * AVCC3 Voltage, + * SB 1.05V Voltage, + * CPU Core Voltage, + * CPU SOC Voltage, + * DRAM Voltage, + * CPU Fan RPM, + * Chassis Fan 1 RPM, + * Chassis Fan 2 RPM, + * Chassis Fan 3 RPM, + * HAMP Fan RPM, + * Water Pump RPM, + * CPU OPT RPM, + * Water Flow RPM, + * AIO Pump RPM, + * CPU Temperature, + * CPU Socket Temperature, + * Motherboard Temperature, + * Chipset Temperature, + * Tsensor 1 Temperature, + * CPU VRM Temperature, + * Water In, + * Water Out, + * CPU VRM Output Current. + +Known Issues: + * The WMI implementation in some of Asus' BIOSes is buggy. This can result in + fans stopping, fans getting stuck at max speed, or temperature readouts + getting stuck. This is not an issue with the driver, but the BIOS. The Prime + X470 Pro seems particularly bad for this. The more frequently the WMI + interface is polled the greater the potential for this to happen. Until you + have subjected your computer to an extended soak test while polling the + sensors frequently, don't leave you computer unattended. Upgrading to new + BIOS version with method version greater than or equal to two should + rectify the issue. + * A few boards report 12v voltages to be ~10v. diff --git a/Documentation/hwmon/ina238.rst b/Documentation/hwmon/ina238.rst new file mode 100644 index 000000000000..d9f479984420 --- /dev/null +++ b/Documentation/hwmon/ina238.rst @@ -0,0 +1,56 @@ +.. SPDX-License-Identifier: GPL-2.0-only + +Kernel driver ina238 +==================== + +Supported chips: + + * Texas Instruments INA238 + + Prefix: 'ina238' + + Addresses: I2C 0x40 - 0x4f + + Datasheet: + https://www.ti.com/lit/gpn/ina238 + +Author: Nathan Rossi <nathan.rossi@digi.com> + +Description +----------- + +The INA238 is a current shunt, power and temperature monitor with an I2C +interface. It includes a number of programmable functions including alerts, +conversion rate, sample averaging and selectable shunt voltage accuracy. + +The shunt value in micro-ohms can be set via platform data or device tree at +compile-time or via the shunt_resistor attribute in sysfs at run-time. Please +refer to the Documentation/devicetree/bindings/hwmon/ti,ina2xx.yaml for bindings +if the device tree is used. + +Sysfs entries +------------- + +======================= ======================================================= +in0_input Shunt voltage (mV) +in0_min Minimum shunt voltage threshold (mV) +in0_min_alarm Minimum shunt voltage alarm +in0_max Maximum shunt voltage threshold (mV) +in0_max_alarm Maximum shunt voltage alarm + +in1_input Bus voltage (mV) +in1_min Minimum bus voltage threshold (mV) +in1_min_alarm Minimum shunt voltage alarm +in1_max Maximum bus voltage threshold (mV) +in1_max_alarm Maximum shunt voltage alarm + +power1_input Power measurement (uW) +power1_max Maximum power threshold (uW) +power1_max_alarm Maximum power alarm + +curr1_input Current measurement (mA) + +temp1_input Die temperature measurement (mC) +temp1_max Maximum die temperature threshold (mC) +temp1_max_alarm Maximum die temperature alarm +======================= ======================================================= diff --git a/Documentation/hwmon/index.rst b/Documentation/hwmon/index.rst index 7046bf1870d9..df20022c741f 100644 --- a/Documentation/hwmon/index.rst +++ b/Documentation/hwmon/index.rst @@ -43,6 +43,8 @@ Hardware Monitoring Kernel Drivers asb100 asc7621 aspeed-pwm-tacho + asus_wmi_ec_sensors + asus_wmi_sensors bcm54140 bel-pfe bpa-rs600 @@ -76,6 +78,7 @@ Hardware Monitoring Kernel Drivers ibmpowernv ina209 ina2xx + ina238 ina3221 intel-m10-bmc-hwmon ir35221 @@ -142,6 +145,7 @@ Hardware Monitoring Kernel Drivers mlxreg-fan mp2888 mp2975 + mp5023 nct6683 nct6775 nct7802 @@ -150,6 +154,7 @@ Hardware Monitoring Kernel Drivers nsa320 ntc_thermistor nzxt-kraken2 + nzxt-smart2 occ pc87360 pc87427 diff --git a/Documentation/hwmon/ir38064.rst b/Documentation/hwmon/ir38064.rst index c455d755a267..e1148f21ea2a 100644 --- a/Documentation/hwmon/ir38064.rst +++ b/Documentation/hwmon/ir38064.rst @@ -3,14 +3,38 @@ Kernel driver ir38064 Supported chips: + * Infineon IR38060 + + Prefix: 'IR38060' + Addresses scanned: - + + Datasheet: Publicly available at the Infineon website + https://www.infineon.com/dgdl/Infineon-IR38060M-DS-v03_16-EN.pdf?fileId=5546d4625c167129015c3291ea9a4cee + * Infineon IR38064 Prefix: 'ir38064' Addresses scanned: - - Datasheet: Publicly available at the Infineon webiste + Datasheet: Publicly available at the Infineon website https://www.infineon.com/dgdl/Infineon-IR38064MTRPBF-DS-v03_07-EN.pdf?fileId=5546d462584d1d4a0158db0d9efb67ca + * Infineon IR38164 + + Prefix: 'ir38164' + Addresses scanned: - + + Datasheet: Publicly available at the Infineon website + https://www.infineon.com/dgdl/Infineon-IR38164M-DS-v02_02-EN.pdf?fileId=5546d462636cc8fb01640046efea1248 + + * Infineon ir38263 + + Prefix: 'ir38263' + Addresses scanned: - + + Datasheet: Publicly available at the Infineon website + https://www.infineon.com/dgdl/Infineon-IR38263M-DataSheet-v03_05-EN.pdf?fileId=5546d4625b62cd8a015bcf81f90a6e52 + Authors: - Maxim Sloyko <maxims@google.com> - Patrick Venture <venture@google.com> @@ -18,7 +42,7 @@ Authors: Description ----------- -IR38064 is a Single-input Voltage, Synchronous Buck Regulator, DC-DC Converter. +IR38x6x are a Single-input Voltage, Synchronous Buck Regulator, DC-DC Converter. Usage Notes ----------- diff --git a/Documentation/hwmon/mp5023.rst b/Documentation/hwmon/mp5023.rst new file mode 100644 index 000000000000..af5ab1345a91 --- /dev/null +++ b/Documentation/hwmon/mp5023.rst @@ -0,0 +1,84 @@ +.. SPDX-License-Identifier: GPL-2.0 + +Kernel driver mp5023 +==================== + +Supported chips: + + * MPS MP5023 + + Prefix: 'mp5023' + + * Datasheet + + Publicly available at the MPS website : https://www.monolithicpower.com/en/mp5023.html + +Author: + + Howard Chiu <howard.chiu@quantatw.com> + +Description +----------- + +This driver implements support for Monolithic Power Systems, Inc. (MPS) +MP5023 Hot-Swap Controller. + +Device complaint with: + +- PMBus rev 1.3 interface. + +Device supports direct format for reading input voltage, output voltage, +output current, input power and temperature. + +The driver exports the following attributes via the 'sysfs' files +for input voltage: + +**in1_input** + +**in1_label** + +**in1_max** + +**in1_max_alarm** + +**in1_min** + +**in1_min_alarm** + +The driver provides the following attributes for output voltage: + +**in2_input** + +**in2_label** + +**in2_alarm** + +The driver provides the following attributes for output current: + +**curr1_input** + +**curr1_label** + +**curr1_alarm** + +**curr1_max** + +The driver provides the following attributes for input power: + +**power1_input** + +**power1_label** + +**power1_alarm** + +The driver provides the following attributes for temperature: + +**temp1_input** + +**temp1_max** + +**temp1_max_alarm** + +**temp1_crit** + +**temp1_crit_alarm** diff --git a/Documentation/hwmon/nzxt-smart2.rst b/Documentation/hwmon/nzxt-smart2.rst new file mode 100644 index 000000000000..d9d1b2742665 --- /dev/null +++ b/Documentation/hwmon/nzxt-smart2.rst @@ -0,0 +1,62 @@ +.. SPDX-License-Identifier: GPL-2.0-or-later + +Kernel driver nzxt-smart2 +========================= + +Supported devices: + +- NZXT RGB & Fan controller +- NZXT Smart Device v2 + +Description +----------- + +This driver implements monitoring and control of fans plugged into the device. +Besides typical speed monitoring and PWM duty cycle control, voltage and current +is reported for every fan. + +The device also has two connectors for RGB LEDs; support for them isn't +implemented (mainly because there is no standardized sysfs interface). + +Also, the device has a noise sensor, but the sensor seems to be completely +useless (and very imprecise), so support for it isn't implemented too. + +Usage Notes +----------- + +The device should be autodetected, and the driver should load automatically. + +If fans are plugged in/unplugged while the system is powered on, the driver +must be reloaded to detect configuration changes; otherwise, new fans can't +be controlled (`pwm*` changes will be ignored). It is necessary because the +device has a dedicated "detect fans" command, and currently, it is executed only +during initialization. Speed, voltage, current monitoring will work even without +reload. As an alternative to reloading the module, a userspace tool (like +`liquidctl`_) can be used to run "detect fans" command through hidraw interface. + +The driver coexists with userspace tools that access the device through hidraw +interface with no known issues. + +.. _liquidctl: https://github.com/liquidctl/liquidctl + +Sysfs entries +------------- + +======================= ======================================================== +fan[1-3]_input Fan speed monitoring (in rpm). +curr[1-3]_input Current supplied to the fan (in milliamperes). +in[0-2]_input Voltage supplied to the fan (in millivolts). +pwm[1-3] Controls fan speed: PWM duty cycle for PWM-controlled + fans, voltage for other fans. Voltage can be changed in + 9-12 V range, but the value of the sysfs attribute is + always in 0-255 range (1 = 9V, 255 = 12V). Setting the + attribute to 0 turns off the fan completely. +pwm[1-3]_enable 1 if the fan can be controlled by writing to the + corresponding pwm* attribute, 0 otherwise. The device + can control only the fans it detected itself, so the + attribute is read-only. +pwm[1-3]_mode Read-only, 1 for PWM-controlled fans, 0 for other fans + (or if no fan connected). +update_interval The interval at which all inputs are updated (in + milliseconds). The default is 1000ms. Minimum is 250ms. +======================= ======================================================== diff --git a/Documentation/i2c/smbus-protocol.rst b/Documentation/i2c/smbus-protocol.rst index 9e07e6bbe6a3..00d8e17d0aca 100644 --- a/Documentation/i2c/smbus-protocol.rst +++ b/Documentation/i2c/smbus-protocol.rst @@ -36,6 +36,8 @@ Key to symbols =============== ============================================================= S Start condition +Sr Repeated start condition, used to switch from write to + read mode. P Stop condition Rd/Wr (1 bit) Read/Write bit. Rd equals 1, Wr equals 0. A, NA (1 bit) Acknowledge (ACK) and Not Acknowledge (NACK) bit @@ -100,7 +102,7 @@ Implemented by i2c_smbus_read_byte_data() This reads a single byte from a device, from a designated register. The register is specified through the Comm byte:: - S Addr Wr [A] Comm [A] S Addr Rd [A] [Data] NA P + S Addr Wr [A] Comm [A] Sr Addr Rd [A] [Data] NA P Functionality flag: I2C_FUNC_SMBUS_READ_BYTE_DATA @@ -114,7 +116,7 @@ This operation is very like Read Byte; again, data is read from a device, from a designated register that is specified through the Comm byte. But this time, the data is a complete word (16 bits):: - S Addr Wr [A] Comm [A] S Addr Rd [A] [DataLow] A [DataHigh] NA P + S Addr Wr [A] Comm [A] Sr Addr Rd [A] [DataLow] A [DataHigh] NA P Functionality flag: I2C_FUNC_SMBUS_READ_WORD_DATA @@ -164,7 +166,7 @@ This command selects a device register (through the Comm byte), sends 16 bits of data to it, and reads 16 bits of data in return:: S Addr Wr [A] Comm [A] DataLow [A] DataHigh [A] - S Addr Rd [A] [DataLow] A [DataHigh] NA P + Sr Addr Rd [A] [DataLow] A [DataHigh] NA P Functionality flag: I2C_FUNC_SMBUS_PROC_CALL @@ -181,7 +183,7 @@ of data is specified by the device in the Count byte. :: S Addr Wr [A] Comm [A] - S Addr Rd [A] [Count] A [Data] A [Data] A ... A [Data] NA P + Sr Addr Rd [A] [Count] A [Data] A [Data] A ... A [Data] NA P Functionality flag: I2C_FUNC_SMBUS_READ_BLOCK_DATA @@ -212,7 +214,7 @@ This command selects a device register (through the Comm byte), sends 1 to 31 bytes of data to it, and reads 1 to 31 bytes of data in return:: S Addr Wr [A] Comm [A] Count [A] Data [A] ... - S Addr Rd [A] [Count] A [Data] ... A P + Sr Addr Rd [A] [Count] A [Data] ... A P Functionality flag: I2C_FUNC_SMBUS_BLOCK_PROC_CALL @@ -300,7 +302,7 @@ This command reads a block of bytes from a device, from a designated register that is specified through the Comm byte:: S Addr Wr [A] Comm [A] - S Addr Rd [A] [Data] A [Data] A ... A [Data] NA P + Sr Addr Rd [A] [Data] A [Data] A ... A [Data] NA P Functionality flag: I2C_FUNC_SMBUS_READ_I2C_BLOCK diff --git a/Documentation/i2c/summary.rst b/Documentation/i2c/summary.rst index 136c4e333be7..786c618ba3be 100644 --- a/Documentation/i2c/summary.rst +++ b/Documentation/i2c/summary.rst @@ -11,9 +11,11 @@ systems. Some systems use variants that don't meet branding requirements, and so are not advertised as being I2C but come under different names, e.g. TWI (Two Wire Interface), IIC. -The official I2C specification is the `"I2C-bus specification and user -manual" (UM10204) <https://www.nxp.com/docs/en/user-guide/UM10204.pdf>`_ -published by NXP Semiconductors. +The latest official I2C specification is the `"I2C-bus specification and user +manual" (UM10204) <https://www.nxp.com/webapp/Download?colCode=UM10204>`_ +published by NXP Semiconductors. However, you need to log-in to the site to +access the PDF. An older version of the specification (revision 6) is archived +`here <https://web.archive.org/web/20210813122132/https://www.nxp.com/docs/en/user-guide/UM10204.pdf>`_. SMBus (System Management Bus) is based on the I2C protocol, and is mostly a subset of I2C protocols and signaling. Many I2C devices will work on an diff --git a/Documentation/index.rst b/Documentation/index.rst index 54ce34fd6fbd..b58692d687f6 100644 --- a/Documentation/index.rst +++ b/Documentation/index.rst @@ -137,6 +137,7 @@ needed). misc-devices/index scheduler/index mhi/index + tty/index Architecture-agnostic documentation ----------------------------------- @@ -165,6 +166,7 @@ to ReStructured Text format, or are simply too old. .. toctree:: :maxdepth: 2 + tools/index staging/index watch_queue diff --git a/Documentation/kbuild/kconfig-language.rst b/Documentation/kbuild/kconfig-language.rst index 98c24183d8c3..93a5b6e1fabd 100644 --- a/Documentation/kbuild/kconfig-language.rst +++ b/Documentation/kbuild/kconfig-language.rst @@ -176,7 +176,7 @@ applicable everywhere (see syntax). y y y Y/m/n n m n N/m m m m M/n - y m n M/n + y m m M/n y n * N === === ============= ============== diff --git a/Documentation/kernel-hacking/locking.rst b/Documentation/kernel-hacking/locking.rst index e6cd40663ea5..4cbd50edf277 100644 --- a/Documentation/kernel-hacking/locking.rst +++ b/Documentation/kernel-hacking/locking.rst @@ -295,7 +295,7 @@ Pete Zaitcev gives the following summary: - If you are in a process context (any syscall) and want to lock other process out, use a mutex. You can take a mutex and sleep - (``copy_from_user*(`` or ``kmalloc(x,GFP_KERNEL)``). + (``copy_from_user()`` or ``kmalloc(x,GFP_KERNEL)``). - Otherwise (== data can be touched in an interrupt), use spin_lock_irqsave() and diff --git a/Documentation/livepatch/api.rst b/Documentation/livepatch/api.rst new file mode 100644 index 000000000000..78944b63d74b --- /dev/null +++ b/Documentation/livepatch/api.rst @@ -0,0 +1,30 @@ +.. SPDX-License-Identifier: GPL-2.0 + +================= +Livepatching APIs +================= + +Livepatch Enablement +==================== + +.. kernel-doc:: kernel/livepatch/core.c + :export: + + +Shadow Variables +================ + +.. kernel-doc:: kernel/livepatch/shadow.c + :export: + +System State Changes +==================== + +.. kernel-doc:: kernel/livepatch/state.c + :export: + +Object Types +============ + +.. kernel-doc:: include/linux/livepatch.h + :identifiers: klp_patch klp_object klp_func klp_callbacks klp_state diff --git a/Documentation/livepatch/index.rst b/Documentation/livepatch/index.rst index 43cce5fad705..cebf1c71d4a5 100644 --- a/Documentation/livepatch/index.rst +++ b/Documentation/livepatch/index.rst @@ -14,6 +14,7 @@ Kernel Livepatching shadow-vars system-state reliable-stacktrace + api .. only:: subproject and html diff --git a/Documentation/livepatch/shadow-vars.rst b/Documentation/livepatch/shadow-vars.rst index 6a7d43a8787d..7a7098bfb5c8 100644 --- a/Documentation/livepatch/shadow-vars.rst +++ b/Documentation/livepatch/shadow-vars.rst @@ -82,8 +82,8 @@ to do actions that can be done only once when a new variable is allocated. - call destructor function if defined - free shadow variable -* klp_shadow_free_all() - detach and free all <*, id> shadow variables - - find and remove any <*, id> references from global hashtable +* klp_shadow_free_all() - detach and free all <_, id> shadow variables + - find and remove any <_, id> references from global hashtable - if found diff --git a/Documentation/livepatch/system-state.rst b/Documentation/livepatch/system-state.rst index c6d127c2d9aa..7a3935fd812b 100644 --- a/Documentation/livepatch/system-state.rst +++ b/Documentation/livepatch/system-state.rst @@ -52,12 +52,12 @@ struct klp_state: The state can be manipulated using two functions: - - *klp_get_state(patch, id)* + - klp_get_state() - Get struct klp_state associated with the given livepatch and state id. - - *klp_get_prev_state(id)* + - klp_get_prev_state() - Get struct klp_state associated with the given feature id and already installed livepatches. diff --git a/Documentation/locking/locktypes.rst b/Documentation/locking/locktypes.rst index ddada4a53749..4fd7b70fcde1 100644 --- a/Documentation/locking/locktypes.rst +++ b/Documentation/locking/locktypes.rst @@ -439,11 +439,9 @@ preemption. The following substitution works on both kernels:: spin_lock(&p->lock); p->count += this_cpu_read(var2); -On a non-PREEMPT_RT kernel migrate_disable() maps to preempt_disable() -which makes the above code fully equivalent. On a PREEMPT_RT kernel migrate_disable() ensures that the task is pinned on the current CPU which in turn guarantees that the per-CPU access to var1 and var2 are staying on -the same CPU. +the same CPU while the task remains preemptible. The migrate_disable() substitution is not valid for the following scenario:: @@ -456,9 +454,8 @@ scenario:: p = this_cpu_ptr(&var1); p->val = func2(); -While correct on a non-PREEMPT_RT kernel, this breaks on PREEMPT_RT because -here migrate_disable() does not protect against reentrancy from a -preempting task. A correct substitution for this case is:: +This breaks because migrate_disable() does not protect against reentrancy from +a preempting task. A correct substitution for this case is:: func() { diff --git a/Documentation/memory-barriers.txt b/Documentation/memory-barriers.txt index 7367ada13208..b12df9137e1c 100644 --- a/Documentation/memory-barriers.txt +++ b/Documentation/memory-barriers.txt @@ -1950,6 +1950,14 @@ There are some more advanced barrier functions: For load from persistent memory, existing read memory barriers are sufficient to ensure read ordering. + (*) io_stop_wc(); + + For memory accesses with write-combining attributes (e.g. those returned + by ioremap_wc(), the CPU may wait for prior accesses to be merged with + subsequent ones. io_stop_wc() can be used to prevent the merging of + write-combining memory accesses before this macro with those after it when + such wait has performance implications. + =============================== IMPLICIT KERNEL MEMORY BARRIERS =============================== diff --git a/Documentation/networking/bonding.rst b/Documentation/networking/bonding.rst index 31cfd7d674a6..ab98373535ea 100644 --- a/Documentation/networking/bonding.rst +++ b/Documentation/networking/bonding.rst @@ -196,11 +196,12 @@ ad_actor_sys_prio ad_actor_system In an AD system, this specifies the mac-address for the actor in - protocol packet exchanges (LACPDUs). The value cannot be NULL or - multicast. It is preferred to have the local-admin bit set for this - mac but driver does not enforce it. If the value is not given then - system defaults to using the masters' mac address as actors' system - address. + protocol packet exchanges (LACPDUs). The value cannot be a multicast + address. If the all-zeroes MAC is specified, bonding will internally + use the MAC of the bond itself. It is preferred to have the + local-admin bit set for this mac but driver does not enforce it. If + the value is not given then system defaults to using the masters' + mac address as actors' system address. This parameter has effect only in 802.3ad mode and is available through SysFs interface. @@ -421,6 +422,17 @@ arp_all_targets consider the slave up only when all of the arp_ip_targets are reachable +arp_missed_max + + Specifies the number of arp_interval monitor checks that must + fail in order for an interface to be marked down by the ARP monitor. + + In order to provide orderly failover semantics, backup interfaces + are permitted an extra monitor check (i.e., they must fail + arp_missed_max + 1 times before being marked down). + + The default value is 2, and the allowable range is 1 - 255. + downdelay Specifies the time, in milliseconds, to wait before disabling diff --git a/Documentation/networking/device_drivers/can/freescale/flexcan.rst b/Documentation/networking/device_drivers/can/freescale/flexcan.rst new file mode 100644 index 000000000000..4e3eec6cecd2 --- /dev/null +++ b/Documentation/networking/device_drivers/can/freescale/flexcan.rst @@ -0,0 +1,54 @@ +.. SPDX-License-Identifier: GPL-2.0+ + +============================= +Flexcan CAN Controller driver +============================= + +Authors: Marc Kleine-Budde <mkl@pengutronix.de>, +Dario Binacchi <dario.binacchi@amarula.solutions.com> + +On/off RTR frames reception +=========================== + +For most flexcan IP cores the driver supports 2 RX modes: + +- FIFO +- mailbox + +The older flexcan cores (integrated into the i.MX25, i.MX28, i.MX35 +and i.MX53 SOCs) only receive RTR frames if the controller is +configured for RX-FIFO mode. + +The RX FIFO mode uses a hardware FIFO with a depth of 6 CAN frames, +while the mailbox mode uses a software FIFO with a depth of up to 62 +CAN frames. With the help of the bigger buffer, the mailbox mode +performs better under high system load situations. + +As reception of RTR frames is part of the CAN standard, all flexcan +cores come up in a mode where RTR reception is possible. + +With the "rx-rtr" private flag the ability to receive RTR frames can +be waived at the expense of losing the ability to receive RTR +messages. This trade off is beneficial in certain use cases. + +"rx-rtr" on + Receive RTR frames. (default) + + The CAN controller can and will receive RTR frames. + + On some IP cores the controller cannot receive RTR frames in the + more performant "RX mailbox" mode and will use "RX FIFO" mode + instead. + +"rx-rtr" off + + Waive ability to receive RTR frames. (not supported on all IP cores) + + This mode activates the "RX mailbox mode" for better performance, on + some IP cores RTR frames cannot be received anymore. + +The setting can only be changed if the interface is down:: + + ip link set dev can0 down + ethtool --set-priv-flags can0 rx-rtr {off|on} + ip link set dev can0 up diff --git a/Documentation/networking/device_drivers/can/index.rst b/Documentation/networking/device_drivers/can/index.rst new file mode 100644 index 000000000000..58b6e0ad3030 --- /dev/null +++ b/Documentation/networking/device_drivers/can/index.rst @@ -0,0 +1,20 @@ +.. SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) + +Controller Area Network (CAN) Device Drivers +============================================ + +Device drivers for CAN devices. + +Contents: + +.. toctree:: + :maxdepth: 2 + + freescale/flexcan + +.. only:: subproject and html + + Indices + ======= + + * :ref:`genindex` diff --git a/Documentation/networking/device_drivers/ethernet/amazon/ena.rst b/Documentation/networking/device_drivers/ethernet/amazon/ena.rst index 01b2a69b0cb0..8bcb173e0353 100644 --- a/Documentation/networking/device_drivers/ethernet/amazon/ena.rst +++ b/Documentation/networking/device_drivers/ethernet/amazon/ena.rst @@ -135,7 +135,7 @@ The ENA driver supports two Queue Operation modes for Tx SQs: - **Low Latency Queue (LLQ) mode or "push-mode":** In this mode the driver pushes the transmit descriptors and the - first 128 bytes of the packet directly to the ENA device memory + first 96 bytes of the packet directly to the ENA device memory space. The rest of the packet payload is fetched by the device. For this operation mode, the driver uses a dedicated PCI device memory BAR, which is mapped with write-combine capability. diff --git a/Documentation/networking/device_drivers/ethernet/freescale/dpaa2/overview.rst b/Documentation/networking/device_drivers/ethernet/freescale/dpaa2/overview.rst index d638b5a8aadd..199647729251 100644 --- a/Documentation/networking/device_drivers/ethernet/freescale/dpaa2/overview.rst +++ b/Documentation/networking/device_drivers/ethernet/freescale/dpaa2/overview.rst @@ -183,6 +183,7 @@ PHY and allows physical transmission and reception of Ethernet frames. IRQ config, enable, reset DPNI (Datapath Network Interface) +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Contains TX/RX queues, network interface configuration, and RX buffer pool configuration mechanisms. The TX/RX queues are in memory and are identified by queue number. diff --git a/Documentation/networking/device_drivers/ethernet/intel/ixgbe.rst b/Documentation/networking/device_drivers/ethernet/intel/ixgbe.rst index f1d5233e5e51..0a233b17c664 100644 --- a/Documentation/networking/device_drivers/ethernet/intel/ixgbe.rst +++ b/Documentation/networking/device_drivers/ethernet/intel/ixgbe.rst @@ -440,6 +440,22 @@ NOTE: For 82599-based network connections, if you are enabling jumbo frames in a virtual function (VF), jumbo frames must first be enabled in the physical function (PF). The VF MTU setting cannot be larger than the PF MTU. +NBASE-T Support +--------------- +The ixgbe driver supports NBASE-T on some devices. However, the advertisement +of NBASE-T speeds is suppressed by default, to accommodate broken network +switches which cannot cope with advertised NBASE-T speeds. Use the ethtool +command to enable advertising NBASE-T speeds on devices which support it:: + + ethtool -s eth? advertise 0x1800000001028 + +On Linux systems with INTERFACES(5), this can be specified as a pre-up command +in /etc/network/interfaces so that the interface is always brought up with +NBASE-T support, e.g.:: + + iface eth? inet dhcp + pre-up ethtool -s eth? advertise 0x1800000001028 || true + Generic Receive Offload, aka GRO -------------------------------- The driver supports the in-kernel software implementation of GRO. GRO has diff --git a/Documentation/networking/device_drivers/index.rst b/Documentation/networking/device_drivers/index.rst index 3a5a1d46e77e..5f5cfdb2a300 100644 --- a/Documentation/networking/device_drivers/index.rst +++ b/Documentation/networking/device_drivers/index.rst @@ -11,6 +11,7 @@ Contents: appletalk/index atm/index cable/index + can/index cellular/index ethernet/index fddi/index diff --git a/Documentation/networking/devlink/devlink-params.rst b/Documentation/networking/devlink/devlink-params.rst index 4878907e9232..4e01dc32bc08 100644 --- a/Documentation/networking/devlink/devlink-params.rst +++ b/Documentation/networking/devlink/devlink-params.rst @@ -109,14 +109,19 @@ own name. - Boolean - When enabled, the device driver will instantiate VDPA networking specific auxiliary device of the devlink device. + * - ``enable_iwarp`` + - Boolean + - Enable handling of iWARP traffic in the device. * - ``internal_err_reset`` - Boolean - When enabled, the device driver will reset the device on internal errors. * - ``max_macs`` - u32 - - Specifies the maximum number of MAC addresses per ethernet port of - this device. + - Typically macvlan, vlan net devices mac are also programmed in their + parent netdevice's Function rx filter. This parameter limit the + maximum number of unicast mac address filters to receive traffic from + per ethernet port of this device. * - ``region_snapshot_enable`` - Boolean - Enable capture of ``devlink-region`` snapshots. @@ -126,3 +131,9 @@ own name. will NACK any attempt of other host to reset the device. This parameter is useful for setups where a device is shared by different hosts, such as multi-host setup. + * - ``io_eq_size`` + - u32 + - Control the size of I/O completion EQs. + * - ``event_eq_size`` + - u32 + - Control the size of asynchronous control events EQ. diff --git a/Documentation/networking/devlink/ice.rst b/Documentation/networking/devlink/ice.rst index 59c78e9717d2..8c082b139bbd 100644 --- a/Documentation/networking/devlink/ice.rst +++ b/Documentation/networking/devlink/ice.rst @@ -26,8 +26,10 @@ The ``ice`` driver reports the following versions * - ``fw.mgmt`` - running - 2.1.7 - - 3-digit version number of the management firmware that controls the - PHY, link, etc. + - 3-digit version number of the management firmware running on the + Embedded Management Processor of the device. It controls the PHY, + link, access to device resources, etc. Intel documentation refers to + this as the EMP firmware. * - ``fw.mgmt.api`` - running - 1.5.1 @@ -119,6 +121,24 @@ preserving settings, and thus ``DEVLINK_FLASH_OVERWRITE_IDENTIFIERS`` on its own will be rejected. If no overwrite mask is provided, the firmware will be instructed to preserve all settings and identifying fields when updating. +Reload +====== + +The ``ice`` driver supports activating new firmware after a flash update +using ``DEVLINK_CMD_RELOAD`` with the ``DEVLINK_RELOAD_ACTION_FW_ACTIVATE`` +action. + +.. code:: shell + + $ devlink dev reload pci/0000:01:00.0 reload action fw_activate + +The new firmware is activated by issuing a device specific Embedded +Management Processor reset which requests the device to reset and reload the +EMP firmware image. + +The driver does not currently support reloading the driver via +``DEVLINK_RELOAD_ACTION_DRIVER_REINIT``. + Regions ======= diff --git a/Documentation/networking/devlink/mlx5.rst b/Documentation/networking/devlink/mlx5.rst index 4e4b97f7971a..29ad304e6fba 100644 --- a/Documentation/networking/devlink/mlx5.rst +++ b/Documentation/networking/devlink/mlx5.rst @@ -14,8 +14,19 @@ Parameters * - Name - Mode + - Validation * - ``enable_roce`` - driverinit + - Type: Boolean + * - ``io_eq_size`` + - driverinit + - The range is between 64 and 4096. + * - ``event_eq_size`` + - driverinit + - The range is between 64 and 4096. + * - ``max_macs`` + - driverinit + - The range is between 1 and 2^31. Only power of 2 values are supported. The ``mlx5`` driver also implements the following driver-specific parameters. diff --git a/Documentation/networking/ethtool-netlink.rst b/Documentation/networking/ethtool-netlink.rst index 7b598c7e3912..9d98e0511249 100644 --- a/Documentation/networking/ethtool-netlink.rst +++ b/Documentation/networking/ethtool-netlink.rst @@ -849,7 +849,7 @@ Request contents: Kernel response contents: - ==================================== ====== ========================== + ==================================== ====== =========================== ``ETHTOOL_A_RINGS_HEADER`` nested reply header ``ETHTOOL_A_RINGS_RX_MAX`` u32 max size of RX ring ``ETHTOOL_A_RINGS_RX_MINI_MAX`` u32 max size of RX mini ring @@ -859,7 +859,8 @@ Kernel response contents: ``ETHTOOL_A_RINGS_RX_MINI`` u32 size of RX mini ring ``ETHTOOL_A_RINGS_RX_JUMBO`` u32 size of RX jumbo ring ``ETHTOOL_A_RINGS_TX`` u32 size of TX ring - ==================================== ====== ========================== + ``ETHTOOL_A_RINGS_RX_BUF_LEN`` u32 size of buffers on the ring + ==================================== ====== =========================== RINGS_SET @@ -869,13 +870,14 @@ Sets ring sizes like ``ETHTOOL_SRINGPARAM`` ioctl request. Request contents: - ==================================== ====== ========================== + ==================================== ====== =========================== ``ETHTOOL_A_RINGS_HEADER`` nested reply header ``ETHTOOL_A_RINGS_RX`` u32 size of RX ring ``ETHTOOL_A_RINGS_RX_MINI`` u32 size of RX mini ring ``ETHTOOL_A_RINGS_RX_JUMBO`` u32 size of RX jumbo ring ``ETHTOOL_A_RINGS_TX`` u32 size of TX ring - ==================================== ====== ========================== + ``ETHTOOL_A_RINGS_RX_BUF_LEN`` u32 size of buffers on the ring + ==================================== ====== =========================== Kernel checks that requested ring sizes do not exceed limits reported by driver. Driver may impose additional constraints and may not suspport all diff --git a/Documentation/networking/filter.rst b/Documentation/networking/filter.rst index ce2b8e8bb9ab..43cdc4d34745 100644 --- a/Documentation/networking/filter.rst +++ b/Documentation/networking/filter.rst @@ -6,6 +6,13 @@ Linux Socket Filtering aka Berkeley Packet Filter (BPF) ======================================================= +Notice +------ + +This file used to document the eBPF format and mechanisms even when not +related to socket filtering. The ../bpf/index.rst has more details +on eBPF. + Introduction ------------ @@ -617,15 +624,11 @@ format with similar underlying principles from BPF described in previous paragraphs is being used. However, the instruction set format is modelled closer to the underlying architecture to mimic native instruction sets, so that a better performance can be achieved (more details later). This new -ISA is called 'eBPF' or 'internal BPF' interchangeably. (Note: eBPF which +ISA is called eBPF. See the ../bpf/index.rst for details. (Note: eBPF which originates from [e]xtended BPF is not the same as BPF extensions! While eBPF is an ISA, BPF extensions date back to classic BPF's 'overloading' of BPF_LD | BPF_{B,H,W} | BPF_ABS instruction.) -It is designed to be JITed with one to one mapping, which can also open up -the possibility for GCC/LLVM compilers to generate optimized eBPF code through -an eBPF backend that performs almost as fast as natively compiled code. - The new instruction set was originally designed with the possible goal in mind to write programs in "restricted C" and compile into eBPF with a optional GCC/LLVM backend, so that it can just-in-time map to modern 64-bit CPUs with @@ -650,1032 +653,11 @@ Currently, the classic BPF format is being used for JITing on most sparc64, arm32, riscv64, riscv32 perform JIT compilation from eBPF instruction set. -Some core changes of the new internal format: - -- Number of registers increase from 2 to 10: - - The old format had two registers A and X, and a hidden frame pointer. The - new layout extends this to be 10 internal registers and a read-only frame - pointer. Since 64-bit CPUs are passing arguments to functions via registers - the number of args from eBPF program to in-kernel function is restricted - to 5 and one register is used to accept return value from an in-kernel - function. Natively, x86_64 passes first 6 arguments in registers, aarch64/ - sparcv9/mips64 have 7 - 8 registers for arguments; x86_64 has 6 callee saved - registers, and aarch64/sparcv9/mips64 have 11 or more callee saved registers. - - Therefore, eBPF calling convention is defined as: - - * R0 - return value from in-kernel function, and exit value for eBPF program - * R1 - R5 - arguments from eBPF program to in-kernel function - * R6 - R9 - callee saved registers that in-kernel function will preserve - * R10 - read-only frame pointer to access stack - - Thus, all eBPF registers map one to one to HW registers on x86_64, aarch64, - etc, and eBPF calling convention maps directly to ABIs used by the kernel on - 64-bit architectures. - - On 32-bit architectures JIT may map programs that use only 32-bit arithmetic - and may let more complex programs to be interpreted. - - R0 - R5 are scratch registers and eBPF program needs spill/fill them if - necessary across calls. Note that there is only one eBPF program (== one - eBPF main routine) and it cannot call other eBPF functions, it can only - call predefined in-kernel functions, though. - -- Register width increases from 32-bit to 64-bit: - - Still, the semantics of the original 32-bit ALU operations are preserved - via 32-bit subregisters. All eBPF registers are 64-bit with 32-bit lower - subregisters that zero-extend into 64-bit if they are being written to. - That behavior maps directly to x86_64 and arm64 subregister definition, but - makes other JITs more difficult. - - 32-bit architectures run 64-bit internal BPF programs via interpreter. - Their JITs may convert BPF programs that only use 32-bit subregisters into - native instruction set and let the rest being interpreted. - - Operation is 64-bit, because on 64-bit architectures, pointers are also - 64-bit wide, and we want to pass 64-bit values in/out of kernel functions, - so 32-bit eBPF registers would otherwise require to define register-pair - ABI, thus, there won't be able to use a direct eBPF register to HW register - mapping and JIT would need to do combine/split/move operations for every - register in and out of the function, which is complex, bug prone and slow. - Another reason is the use of atomic 64-bit counters. - -- Conditional jt/jf targets replaced with jt/fall-through: - - While the original design has constructs such as ``if (cond) jump_true; - else jump_false;``, they are being replaced into alternative constructs like - ``if (cond) jump_true; /* else fall-through */``. - -- Introduces bpf_call insn and register passing convention for zero overhead - calls from/to other kernel functions: - - Before an in-kernel function call, the internal BPF program needs to - place function arguments into R1 to R5 registers to satisfy calling - convention, then the interpreter will take them from registers and pass - to in-kernel function. If R1 - R5 registers are mapped to CPU registers - that are used for argument passing on given architecture, the JIT compiler - doesn't need to emit extra moves. Function arguments will be in the correct - registers and BPF_CALL instruction will be JITed as single 'call' HW - instruction. This calling convention was picked to cover common call - situations without performance penalty. - - After an in-kernel function call, R1 - R5 are reset to unreadable and R0 has - a return value of the function. Since R6 - R9 are callee saved, their state - is preserved across the call. - - For example, consider three C functions:: - - u64 f1() { return (*_f2)(1); } - u64 f2(u64 a) { return f3(a + 1, a); } - u64 f3(u64 a, u64 b) { return a - b; } - - GCC can compile f1, f3 into x86_64:: - - f1: - movl $1, %edi - movq _f2(%rip), %rax - jmp *%rax - f3: - movq %rdi, %rax - subq %rsi, %rax - ret - - Function f2 in eBPF may look like:: - - f2: - bpf_mov R2, R1 - bpf_add R1, 1 - bpf_call f3 - bpf_exit - - If f2 is JITed and the pointer stored to ``_f2``. The calls f1 -> f2 -> f3 and - returns will be seamless. Without JIT, __bpf_prog_run() interpreter needs to - be used to call into f2. - - For practical reasons all eBPF programs have only one argument 'ctx' which is - already placed into R1 (e.g. on __bpf_prog_run() startup) and the programs - can call kernel functions with up to 5 arguments. Calls with 6 or more arguments - are currently not supported, but these restrictions can be lifted if necessary - in the future. - - On 64-bit architectures all register map to HW registers one to one. For - example, x86_64 JIT compiler can map them as ... - - :: - - R0 - rax - R1 - rdi - R2 - rsi - R3 - rdx - R4 - rcx - R5 - r8 - R6 - rbx - R7 - r13 - R8 - r14 - R9 - r15 - R10 - rbp - - ... since x86_64 ABI mandates rdi, rsi, rdx, rcx, r8, r9 for argument passing - and rbx, r12 - r15 are callee saved. - - Then the following internal BPF pseudo-program:: - - bpf_mov R6, R1 /* save ctx */ - bpf_mov R2, 2 - bpf_mov R3, 3 - bpf_mov R4, 4 - bpf_mov R5, 5 - bpf_call foo - bpf_mov R7, R0 /* save foo() return value */ - bpf_mov R1, R6 /* restore ctx for next call */ - bpf_mov R2, 6 - bpf_mov R3, 7 - bpf_mov R4, 8 - bpf_mov R5, 9 - bpf_call bar - bpf_add R0, R7 - bpf_exit - - After JIT to x86_64 may look like:: - - push %rbp - mov %rsp,%rbp - sub $0x228,%rsp - mov %rbx,-0x228(%rbp) - mov %r13,-0x220(%rbp) - mov %rdi,%rbx - mov $0x2,%esi - mov $0x3,%edx - mov $0x4,%ecx - mov $0x5,%r8d - callq foo - mov %rax,%r13 - mov %rbx,%rdi - mov $0x6,%esi - mov $0x7,%edx - mov $0x8,%ecx - mov $0x9,%r8d - callq bar - add %r13,%rax - mov -0x228(%rbp),%rbx - mov -0x220(%rbp),%r13 - leaveq - retq - - Which is in this example equivalent in C to:: - - u64 bpf_filter(u64 ctx) - { - return foo(ctx, 2, 3, 4, 5) + bar(ctx, 6, 7, 8, 9); - } - - In-kernel functions foo() and bar() with prototype: u64 (*)(u64 arg1, u64 - arg2, u64 arg3, u64 arg4, u64 arg5); will receive arguments in proper - registers and place their return value into ``%rax`` which is R0 in eBPF. - Prologue and epilogue are emitted by JIT and are implicit in the - interpreter. R0-R5 are scratch registers, so eBPF program needs to preserve - them across the calls as defined by calling convention. - - For example the following program is invalid:: - - bpf_mov R1, 1 - bpf_call foo - bpf_mov R0, R1 - bpf_exit - - After the call the registers R1-R5 contain junk values and cannot be read. - An in-kernel eBPF verifier is used to validate internal BPF programs. - -Also in the new design, eBPF is limited to 4096 insns, which means that any -program will terminate quickly and will only call a fixed number of kernel -functions. Original BPF and the new format are two operand instructions, -which helps to do one-to-one mapping between eBPF insn and x86 insn during JIT. - -The input context pointer for invoking the interpreter function is generic, -its content is defined by a specific use case. For seccomp register R1 points -to seccomp_data, for converted BPF filters R1 points to a skb. - -A program, that is translated internally consists of the following elements:: - - op:16, jt:8, jf:8, k:32 ==> op:8, dst_reg:4, src_reg:4, off:16, imm:32 - -So far 87 internal BPF instructions were implemented. 8-bit 'op' opcode field -has room for new instructions. Some of them may use 16/24/32 byte encoding. New -instructions must be multiple of 8 bytes to preserve backward compatibility. - -Internal BPF is a general purpose RISC instruction set. Not every register and -every instruction are used during translation from original BPF to new format. -For example, socket filters are not using ``exclusive add`` instruction, but -tracing filters may do to maintain counters of events, for example. Register R9 -is not used by socket filters either, but more complex filters may be running -out of registers and would have to resort to spill/fill to stack. - -Internal BPF can be used as a generic assembler for last step performance -optimizations, socket filters and seccomp are using it as assembler. Tracing -filters may use it as assembler to generate code from kernel. In kernel usage -may not be bounded by security considerations, since generated internal BPF code -may be optimizing internal code path and not being exposed to the user space. -Safety of internal BPF can come from a verifier (TBD). In such use cases as -described, it may be used as safe instruction set. - -Just like the original BPF, the new format runs within a controlled environment, -is deterministic and the kernel can easily prove that. The safety of the program -can be determined in two steps: first step does depth-first-search to disallow -loops and other CFG validation; second step starts from the first insn and -descends all possible paths. It simulates execution of every insn and observes -the state change of registers and stack. - -eBPF opcode encoding --------------------- - -eBPF is reusing most of the opcode encoding from classic to simplify conversion -of classic BPF to eBPF. For arithmetic and jump instructions the 8-bit 'code' -field is divided into three parts:: - - +----------------+--------+--------------------+ - | 4 bits | 1 bit | 3 bits | - | operation code | source | instruction class | - +----------------+--------+--------------------+ - (MSB) (LSB) - -Three LSB bits store instruction class which is one of: - - =================== =============== - Classic BPF classes eBPF classes - =================== =============== - BPF_LD 0x00 BPF_LD 0x00 - BPF_LDX 0x01 BPF_LDX 0x01 - BPF_ST 0x02 BPF_ST 0x02 - BPF_STX 0x03 BPF_STX 0x03 - BPF_ALU 0x04 BPF_ALU 0x04 - BPF_JMP 0x05 BPF_JMP 0x05 - BPF_RET 0x06 BPF_JMP32 0x06 - BPF_MISC 0x07 BPF_ALU64 0x07 - =================== =============== - -When BPF_CLASS(code) == BPF_ALU or BPF_JMP, 4th bit encodes source operand ... - - :: - - BPF_K 0x00 - BPF_X 0x08 - - * in classic BPF, this means:: - - BPF_SRC(code) == BPF_X - use register X as source operand - BPF_SRC(code) == BPF_K - use 32-bit immediate as source operand - - * in eBPF, this means:: - - BPF_SRC(code) == BPF_X - use 'src_reg' register as source operand - BPF_SRC(code) == BPF_K - use 32-bit immediate as source operand - -... and four MSB bits store operation code. - -If BPF_CLASS(code) == BPF_ALU or BPF_ALU64 [ in eBPF ], BPF_OP(code) is one of:: - - BPF_ADD 0x00 - BPF_SUB 0x10 - BPF_MUL 0x20 - BPF_DIV 0x30 - BPF_OR 0x40 - BPF_AND 0x50 - BPF_LSH 0x60 - BPF_RSH 0x70 - BPF_NEG 0x80 - BPF_MOD 0x90 - BPF_XOR 0xa0 - BPF_MOV 0xb0 /* eBPF only: mov reg to reg */ - BPF_ARSH 0xc0 /* eBPF only: sign extending shift right */ - BPF_END 0xd0 /* eBPF only: endianness conversion */ - -If BPF_CLASS(code) == BPF_JMP or BPF_JMP32 [ in eBPF ], BPF_OP(code) is one of:: - - BPF_JA 0x00 /* BPF_JMP only */ - BPF_JEQ 0x10 - BPF_JGT 0x20 - BPF_JGE 0x30 - BPF_JSET 0x40 - BPF_JNE 0x50 /* eBPF only: jump != */ - BPF_JSGT 0x60 /* eBPF only: signed '>' */ - BPF_JSGE 0x70 /* eBPF only: signed '>=' */ - BPF_CALL 0x80 /* eBPF BPF_JMP only: function call */ - BPF_EXIT 0x90 /* eBPF BPF_JMP only: function return */ - BPF_JLT 0xa0 /* eBPF only: unsigned '<' */ - BPF_JLE 0xb0 /* eBPF only: unsigned '<=' */ - BPF_JSLT 0xc0 /* eBPF only: signed '<' */ - BPF_JSLE 0xd0 /* eBPF only: signed '<=' */ - -So BPF_ADD | BPF_X | BPF_ALU means 32-bit addition in both classic BPF -and eBPF. There are only two registers in classic BPF, so it means A += X. -In eBPF it means dst_reg = (u32) dst_reg + (u32) src_reg; similarly, -BPF_XOR | BPF_K | BPF_ALU means A ^= imm32 in classic BPF and analogous -src_reg = (u32) src_reg ^ (u32) imm32 in eBPF. - -Classic BPF is using BPF_MISC class to represent A = X and X = A moves. -eBPF is using BPF_MOV | BPF_X | BPF_ALU code instead. Since there are no -BPF_MISC operations in eBPF, the class 7 is used as BPF_ALU64 to mean -exactly the same operations as BPF_ALU, but with 64-bit wide operands -instead. So BPF_ADD | BPF_X | BPF_ALU64 means 64-bit addition, i.e.: -dst_reg = dst_reg + src_reg - -Classic BPF wastes the whole BPF_RET class to represent a single ``ret`` -operation. Classic BPF_RET | BPF_K means copy imm32 into return register -and perform function exit. eBPF is modeled to match CPU, so BPF_JMP | BPF_EXIT -in eBPF means function exit only. The eBPF program needs to store return -value into register R0 before doing a BPF_EXIT. Class 6 in eBPF is used as -BPF_JMP32 to mean exactly the same operations as BPF_JMP, but with 32-bit wide -operands for the comparisons instead. - -For load and store instructions the 8-bit 'code' field is divided as:: - - +--------+--------+-------------------+ - | 3 bits | 2 bits | 3 bits | - | mode | size | instruction class | - +--------+--------+-------------------+ - (MSB) (LSB) - -Size modifier is one of ... - -:: - - BPF_W 0x00 /* word */ - BPF_H 0x08 /* half word */ - BPF_B 0x10 /* byte */ - BPF_DW 0x18 /* eBPF only, double word */ - -... which encodes size of load/store operation:: - - B - 1 byte - H - 2 byte - W - 4 byte - DW - 8 byte (eBPF only) - -Mode modifier is one of:: - - BPF_IMM 0x00 /* used for 32-bit mov in classic BPF and 64-bit in eBPF */ - BPF_ABS 0x20 - BPF_IND 0x40 - BPF_MEM 0x60 - BPF_LEN 0x80 /* classic BPF only, reserved in eBPF */ - BPF_MSH 0xa0 /* classic BPF only, reserved in eBPF */ - BPF_ATOMIC 0xc0 /* eBPF only, atomic operations */ - -eBPF has two non-generic instructions: (BPF_ABS | <size> | BPF_LD) and -(BPF_IND | <size> | BPF_LD) which are used to access packet data. - -They had to be carried over from classic to have strong performance of -socket filters running in eBPF interpreter. These instructions can only -be used when interpreter context is a pointer to ``struct sk_buff`` and -have seven implicit operands. Register R6 is an implicit input that must -contain pointer to sk_buff. Register R0 is an implicit output which contains -the data fetched from the packet. Registers R1-R5 are scratch registers -and must not be used to store the data across BPF_ABS | BPF_LD or -BPF_IND | BPF_LD instructions. - -These instructions have implicit program exit condition as well. When -eBPF program is trying to access the data beyond the packet boundary, -the interpreter will abort the execution of the program. JIT compilers -therefore must preserve this property. src_reg and imm32 fields are -explicit inputs to these instructions. - -For example:: - - BPF_IND | BPF_W | BPF_LD means: - - R0 = ntohl(*(u32 *) (((struct sk_buff *) R6)->data + src_reg + imm32)) - and R1 - R5 were scratched. - -Unlike classic BPF instruction set, eBPF has generic load/store operations:: - - BPF_MEM | <size> | BPF_STX: *(size *) (dst_reg + off) = src_reg - BPF_MEM | <size> | BPF_ST: *(size *) (dst_reg + off) = imm32 - BPF_MEM | <size> | BPF_LDX: dst_reg = *(size *) (src_reg + off) - -Where size is one of: BPF_B or BPF_H or BPF_W or BPF_DW. - -It also includes atomic operations, which use the immediate field for extra -encoding:: - - .imm = BPF_ADD, .code = BPF_ATOMIC | BPF_W | BPF_STX: lock xadd *(u32 *)(dst_reg + off16) += src_reg - .imm = BPF_ADD, .code = BPF_ATOMIC | BPF_DW | BPF_STX: lock xadd *(u64 *)(dst_reg + off16) += src_reg - -The basic atomic operations supported are:: - - BPF_ADD - BPF_AND - BPF_OR - BPF_XOR - -Each having equivalent semantics with the ``BPF_ADD`` example, that is: the -memory location addresed by ``dst_reg + off`` is atomically modified, with -``src_reg`` as the other operand. If the ``BPF_FETCH`` flag is set in the -immediate, then these operations also overwrite ``src_reg`` with the -value that was in memory before it was modified. - -The more special operations are:: - - BPF_XCHG - -This atomically exchanges ``src_reg`` with the value addressed by ``dst_reg + -off``. :: - - BPF_CMPXCHG - -This atomically compares the value addressed by ``dst_reg + off`` with -``R0``. If they match it is replaced with ``src_reg``. In either case, the -value that was there before is zero-extended and loaded back to ``R0``. - -Note that 1 and 2 byte atomic operations are not supported. - -Clang can generate atomic instructions by default when ``-mcpu=v3`` is -enabled. If a lower version for ``-mcpu`` is set, the only atomic instruction -Clang can generate is ``BPF_ADD`` *without* ``BPF_FETCH``. If you need to enable -the atomics features, while keeping a lower ``-mcpu`` version, you can use -``-Xclang -target-feature -Xclang +alu32``. - -You may encounter ``BPF_XADD`` - this is a legacy name for ``BPF_ATOMIC``, -referring to the exclusive-add operation encoded when the immediate field is -zero. - -eBPF has one 16-byte instruction: ``BPF_LD | BPF_DW | BPF_IMM`` which consists -of two consecutive ``struct bpf_insn`` 8-byte blocks and interpreted as single -instruction that loads 64-bit immediate value into a dst_reg. -Classic BPF has similar instruction: ``BPF_LD | BPF_W | BPF_IMM`` which loads -32-bit immediate value into a register. - -eBPF verifier -------------- -The safety of the eBPF program is determined in two steps. - -First step does DAG check to disallow loops and other CFG validation. -In particular it will detect programs that have unreachable instructions. -(though classic BPF checker allows them) - -Second step starts from the first insn and descends all possible paths. -It simulates execution of every insn and observes the state change of -registers and stack. - -At the start of the program the register R1 contains a pointer to context -and has type PTR_TO_CTX. -If verifier sees an insn that does R2=R1, then R2 has now type -PTR_TO_CTX as well and can be used on the right hand side of expression. -If R1=PTR_TO_CTX and insn is R2=R1+R1, then R2=SCALAR_VALUE, -since addition of two valid pointers makes invalid pointer. -(In 'secure' mode verifier will reject any type of pointer arithmetic to make -sure that kernel addresses don't leak to unprivileged users) - -If register was never written to, it's not readable:: - - bpf_mov R0 = R2 - bpf_exit - -will be rejected, since R2 is unreadable at the start of the program. - -After kernel function call, R1-R5 are reset to unreadable and -R0 has a return type of the function. - -Since R6-R9 are callee saved, their state is preserved across the call. - -:: - - bpf_mov R6 = 1 - bpf_call foo - bpf_mov R0 = R6 - bpf_exit - -is a correct program. If there was R1 instead of R6, it would have -been rejected. - -load/store instructions are allowed only with registers of valid types, which -are PTR_TO_CTX, PTR_TO_MAP, PTR_TO_STACK. They are bounds and alignment checked. -For example:: - - bpf_mov R1 = 1 - bpf_mov R2 = 2 - bpf_xadd *(u32 *)(R1 + 3) += R2 - bpf_exit - -will be rejected, since R1 doesn't have a valid pointer type at the time of -execution of instruction bpf_xadd. - -At the start R1 type is PTR_TO_CTX (a pointer to generic ``struct bpf_context``) -A callback is used to customize verifier to restrict eBPF program access to only -certain fields within ctx structure with specified size and alignment. - -For example, the following insn:: - - bpf_ld R0 = *(u32 *)(R6 + 8) - -intends to load a word from address R6 + 8 and store it into R0 -If R6=PTR_TO_CTX, via is_valid_access() callback the verifier will know -that offset 8 of size 4 bytes can be accessed for reading, otherwise -the verifier will reject the program. -If R6=PTR_TO_STACK, then access should be aligned and be within -stack bounds, which are [-MAX_BPF_STACK, 0). In this example offset is 8, -so it will fail verification, since it's out of bounds. - -The verifier will allow eBPF program to read data from stack only after -it wrote into it. - -Classic BPF verifier does similar check with M[0-15] memory slots. -For example:: - - bpf_ld R0 = *(u32 *)(R10 - 4) - bpf_exit - -is invalid program. -Though R10 is correct read-only register and has type PTR_TO_STACK -and R10 - 4 is within stack bounds, there were no stores into that location. - -Pointer register spill/fill is tracked as well, since four (R6-R9) -callee saved registers may not be enough for some programs. - -Allowed function calls are customized with bpf_verifier_ops->get_func_proto() -The eBPF verifier will check that registers match argument constraints. -After the call register R0 will be set to return type of the function. - -Function calls is a main mechanism to extend functionality of eBPF programs. -Socket filters may let programs to call one set of functions, whereas tracing -filters may allow completely different set. - -If a function made accessible to eBPF program, it needs to be thought through -from safety point of view. The verifier will guarantee that the function is -called with valid arguments. - -seccomp vs socket filters have different security restrictions for classic BPF. -Seccomp solves this by two stage verifier: classic BPF verifier is followed -by seccomp verifier. In case of eBPF one configurable verifier is shared for -all use cases. - -See details of eBPF verifier in kernel/bpf/verifier.c - -Register value tracking ------------------------ -In order to determine the safety of an eBPF program, the verifier must track -the range of possible values in each register and also in each stack slot. -This is done with ``struct bpf_reg_state``, defined in include/linux/ -bpf_verifier.h, which unifies tracking of scalar and pointer values. Each -register state has a type, which is either NOT_INIT (the register has not been -written to), SCALAR_VALUE (some value which is not usable as a pointer), or a -pointer type. The types of pointers describe their base, as follows: - - - PTR_TO_CTX - Pointer to bpf_context. - CONST_PTR_TO_MAP - Pointer to struct bpf_map. "Const" because arithmetic - on these pointers is forbidden. - PTR_TO_MAP_VALUE - Pointer to the value stored in a map element. - PTR_TO_MAP_VALUE_OR_NULL - Either a pointer to a map value, or NULL; map accesses - (see section 'eBPF maps', below) return this type, - which becomes a PTR_TO_MAP_VALUE when checked != NULL. - Arithmetic on these pointers is forbidden. - PTR_TO_STACK - Frame pointer. - PTR_TO_PACKET - skb->data. - PTR_TO_PACKET_END - skb->data + headlen; arithmetic forbidden. - PTR_TO_SOCKET - Pointer to struct bpf_sock_ops, implicitly refcounted. - PTR_TO_SOCKET_OR_NULL - Either a pointer to a socket, or NULL; socket lookup - returns this type, which becomes a PTR_TO_SOCKET when - checked != NULL. PTR_TO_SOCKET is reference-counted, - so programs must release the reference through the - socket release function before the end of the program. - Arithmetic on these pointers is forbidden. - -However, a pointer may be offset from this base (as a result of pointer -arithmetic), and this is tracked in two parts: the 'fixed offset' and 'variable -offset'. The former is used when an exactly-known value (e.g. an immediate -operand) is added to a pointer, while the latter is used for values which are -not exactly known. The variable offset is also used in SCALAR_VALUEs, to track -the range of possible values in the register. - -The verifier's knowledge about the variable offset consists of: - -* minimum and maximum values as unsigned -* minimum and maximum values as signed - -* knowledge of the values of individual bits, in the form of a 'tnum': a u64 - 'mask' and a u64 'value'. 1s in the mask represent bits whose value is unknown; - 1s in the value represent bits known to be 1. Bits known to be 0 have 0 in both - mask and value; no bit should ever be 1 in both. For example, if a byte is read - into a register from memory, the register's top 56 bits are known zero, while - the low 8 are unknown - which is represented as the tnum (0x0; 0xff). If we - then OR this with 0x40, we get (0x40; 0xbf), then if we add 1 we get (0x0; - 0x1ff), because of potential carries. - -Besides arithmetic, the register state can also be updated by conditional -branches. For instance, if a SCALAR_VALUE is compared > 8, in the 'true' branch -it will have a umin_value (unsigned minimum value) of 9, whereas in the 'false' -branch it will have a umax_value of 8. A signed compare (with BPF_JSGT or -BPF_JSGE) would instead update the signed minimum/maximum values. Information -from the signed and unsigned bounds can be combined; for instance if a value is -first tested < 8 and then tested s> 4, the verifier will conclude that the value -is also > 4 and s< 8, since the bounds prevent crossing the sign boundary. - -PTR_TO_PACKETs with a variable offset part have an 'id', which is common to all -pointers sharing that same variable offset. This is important for packet range -checks: after adding a variable to a packet pointer register A, if you then copy -it to another register B and then add a constant 4 to A, both registers will -share the same 'id' but the A will have a fixed offset of +4. Then if A is -bounds-checked and found to be less than a PTR_TO_PACKET_END, the register B is -now known to have a safe range of at least 4 bytes. See 'Direct packet access', -below, for more on PTR_TO_PACKET ranges. - -The 'id' field is also used on PTR_TO_MAP_VALUE_OR_NULL, common to all copies of -the pointer returned from a map lookup. This means that when one copy is -checked and found to be non-NULL, all copies can become PTR_TO_MAP_VALUEs. -As well as range-checking, the tracked information is also used for enforcing -alignment of pointer accesses. For instance, on most systems the packet pointer -is 2 bytes after a 4-byte alignment. If a program adds 14 bytes to that to jump -over the Ethernet header, then reads IHL and addes (IHL * 4), the resulting -pointer will have a variable offset known to be 4n+2 for some n, so adding the 2 -bytes (NET_IP_ALIGN) gives a 4-byte alignment and so word-sized accesses through -that pointer are safe. -The 'id' field is also used on PTR_TO_SOCKET and PTR_TO_SOCKET_OR_NULL, common -to all copies of the pointer returned from a socket lookup. This has similar -behaviour to the handling for PTR_TO_MAP_VALUE_OR_NULL->PTR_TO_MAP_VALUE, but -it also handles reference tracking for the pointer. PTR_TO_SOCKET implicitly -represents a reference to the corresponding ``struct sock``. To ensure that the -reference is not leaked, it is imperative to NULL-check the reference and in -the non-NULL case, and pass the valid reference to the socket release function. - -Direct packet access --------------------- -In cls_bpf and act_bpf programs the verifier allows direct access to the packet -data via skb->data and skb->data_end pointers. -Ex:: - - 1: r4 = *(u32 *)(r1 +80) /* load skb->data_end */ - 2: r3 = *(u32 *)(r1 +76) /* load skb->data */ - 3: r5 = r3 - 4: r5 += 14 - 5: if r5 > r4 goto pc+16 - R1=ctx R3=pkt(id=0,off=0,r=14) R4=pkt_end R5=pkt(id=0,off=14,r=14) R10=fp - 6: r0 = *(u16 *)(r3 +12) /* access 12 and 13 bytes of the packet */ - -this 2byte load from the packet is safe to do, since the program author -did check ``if (skb->data + 14 > skb->data_end) goto err`` at insn #5 which -means that in the fall-through case the register R3 (which points to skb->data) -has at least 14 directly accessible bytes. The verifier marks it -as R3=pkt(id=0,off=0,r=14). -id=0 means that no additional variables were added to the register. -off=0 means that no additional constants were added. -r=14 is the range of safe access which means that bytes [R3, R3 + 14) are ok. -Note that R5 is marked as R5=pkt(id=0,off=14,r=14). It also points -to the packet data, but constant 14 was added to the register, so -it now points to ``skb->data + 14`` and accessible range is [R5, R5 + 14 - 14) -which is zero bytes. - -More complex packet access may look like:: - - - R0=inv1 R1=ctx R3=pkt(id=0,off=0,r=14) R4=pkt_end R5=pkt(id=0,off=14,r=14) R10=fp - 6: r0 = *(u8 *)(r3 +7) /* load 7th byte from the packet */ - 7: r4 = *(u8 *)(r3 +12) - 8: r4 *= 14 - 9: r3 = *(u32 *)(r1 +76) /* load skb->data */ - 10: r3 += r4 - 11: r2 = r1 - 12: r2 <<= 48 - 13: r2 >>= 48 - 14: r3 += r2 - 15: r2 = r3 - 16: r2 += 8 - 17: r1 = *(u32 *)(r1 +80) /* load skb->data_end */ - 18: if r2 > r1 goto pc+2 - R0=inv(id=0,umax_value=255,var_off=(0x0; 0xff)) R1=pkt_end R2=pkt(id=2,off=8,r=8) R3=pkt(id=2,off=0,r=8) R4=inv(id=0,umax_value=3570,var_off=(0x0; 0xfffe)) R5=pkt(id=0,off=14,r=14) R10=fp - 19: r1 = *(u8 *)(r3 +4) - -The state of the register R3 is R3=pkt(id=2,off=0,r=8) -id=2 means that two ``r3 += rX`` instructions were seen, so r3 points to some -offset within a packet and since the program author did -``if (r3 + 8 > r1) goto err`` at insn #18, the safe range is [R3, R3 + 8). -The verifier only allows 'add'/'sub' operations on packet registers. Any other -operation will set the register state to 'SCALAR_VALUE' and it won't be -available for direct packet access. - -Operation ``r3 += rX`` may overflow and become less than original skb->data, -therefore the verifier has to prevent that. So when it sees ``r3 += rX`` -instruction and rX is more than 16-bit value, any subsequent bounds-check of r3 -against skb->data_end will not give us 'range' information, so attempts to read -through the pointer will give "invalid access to packet" error. - -Ex. after insn ``r4 = *(u8 *)(r3 +12)`` (insn #7 above) the state of r4 is -R4=inv(id=0,umax_value=255,var_off=(0x0; 0xff)) which means that upper 56 bits -of the register are guaranteed to be zero, and nothing is known about the lower -8 bits. After insn ``r4 *= 14`` the state becomes -R4=inv(id=0,umax_value=3570,var_off=(0x0; 0xfffe)), since multiplying an 8-bit -value by constant 14 will keep upper 52 bits as zero, also the least significant -bit will be zero as 14 is even. Similarly ``r2 >>= 48`` will make -R2=inv(id=0,umax_value=65535,var_off=(0x0; 0xffff)), since the shift is not sign -extending. This logic is implemented in adjust_reg_min_max_vals() function, -which calls adjust_ptr_min_max_vals() for adding pointer to scalar (or vice -versa) and adjust_scalar_min_max_vals() for operations on two scalars. - -The end result is that bpf program author can access packet directly -using normal C code as:: - - void *data = (void *)(long)skb->data; - void *data_end = (void *)(long)skb->data_end; - struct eth_hdr *eth = data; - struct iphdr *iph = data + sizeof(*eth); - struct udphdr *udp = data + sizeof(*eth) + sizeof(*iph); - - if (data + sizeof(*eth) + sizeof(*iph) + sizeof(*udp) > data_end) - return 0; - if (eth->h_proto != htons(ETH_P_IP)) - return 0; - if (iph->protocol != IPPROTO_UDP || iph->ihl != 5) - return 0; - if (udp->dest == 53 || udp->source == 9) - ...; - -which makes such programs easier to write comparing to LD_ABS insn -and significantly faster. - -eBPF maps ---------- -'maps' is a generic storage of different types for sharing data between kernel -and userspace. - -The maps are accessed from user space via BPF syscall, which has commands: - -- create a map with given type and attributes - ``map_fd = bpf(BPF_MAP_CREATE, union bpf_attr *attr, u32 size)`` - using attr->map_type, attr->key_size, attr->value_size, attr->max_entries - returns process-local file descriptor or negative error - -- lookup key in a given map - ``err = bpf(BPF_MAP_LOOKUP_ELEM, union bpf_attr *attr, u32 size)`` - using attr->map_fd, attr->key, attr->value - returns zero and stores found elem into value or negative error - -- create or update key/value pair in a given map - ``err = bpf(BPF_MAP_UPDATE_ELEM, union bpf_attr *attr, u32 size)`` - using attr->map_fd, attr->key, attr->value - returns zero or negative error - -- find and delete element by key in a given map - ``err = bpf(BPF_MAP_DELETE_ELEM, union bpf_attr *attr, u32 size)`` - using attr->map_fd, attr->key - -- to delete map: close(fd) - Exiting process will delete maps automatically - -userspace programs use this syscall to create/access maps that eBPF programs -are concurrently updating. - -maps can have different types: hash, array, bloom filter, radix-tree, etc. - -The map is defined by: - - - type - - max number of elements - - key size in bytes - - value size in bytes - -Pruning -------- -The verifier does not actually walk all possible paths through the program. For -each new branch to analyse, the verifier looks at all the states it's previously -been in when at this instruction. If any of them contain the current state as a -subset, the branch is 'pruned' - that is, the fact that the previous state was -accepted implies the current state would be as well. For instance, if in the -previous state, r1 held a packet-pointer, and in the current state, r1 holds a -packet-pointer with a range as long or longer and at least as strict an -alignment, then r1 is safe. Similarly, if r2 was NOT_INIT before then it can't -have been used by any path from that point, so any value in r2 (including -another NOT_INIT) is safe. The implementation is in the function regsafe(). -Pruning considers not only the registers but also the stack (and any spilled -registers it may hold). They must all be safe for the branch to be pruned. -This is implemented in states_equal(). - -Understanding eBPF verifier messages ------------------------------------- - -The following are few examples of invalid eBPF programs and verifier error -messages as seen in the log: - -Program with unreachable instructions:: - - static struct bpf_insn prog[] = { - BPF_EXIT_INSN(), - BPF_EXIT_INSN(), - }; - -Error: - - unreachable insn 1 - -Program that reads uninitialized register:: - - BPF_MOV64_REG(BPF_REG_0, BPF_REG_2), - BPF_EXIT_INSN(), - -Error:: - - 0: (bf) r0 = r2 - R2 !read_ok - -Program that doesn't initialize R0 before exiting:: - - BPF_MOV64_REG(BPF_REG_2, BPF_REG_1), - BPF_EXIT_INSN(), - -Error:: - - 0: (bf) r2 = r1 - 1: (95) exit - R0 !read_ok - -Program that accesses stack out of bounds:: - - BPF_ST_MEM(BPF_DW, BPF_REG_10, 8, 0), - BPF_EXIT_INSN(), - -Error:: - - 0: (7a) *(u64 *)(r10 +8) = 0 - invalid stack off=8 size=8 - -Program that doesn't initialize stack before passing its address into function:: - - BPF_MOV64_REG(BPF_REG_2, BPF_REG_10), - BPF_ALU64_IMM(BPF_ADD, BPF_REG_2, -8), - BPF_LD_MAP_FD(BPF_REG_1, 0), - BPF_RAW_INSN(BPF_JMP | BPF_CALL, 0, 0, 0, BPF_FUNC_map_lookup_elem), - BPF_EXIT_INSN(), - -Error:: - - 0: (bf) r2 = r10 - 1: (07) r2 += -8 - 2: (b7) r1 = 0x0 - 3: (85) call 1 - invalid indirect read from stack off -8+0 size 8 - -Program that uses invalid map_fd=0 while calling to map_lookup_elem() function:: - - BPF_ST_MEM(BPF_DW, BPF_REG_10, -8, 0), - BPF_MOV64_REG(BPF_REG_2, BPF_REG_10), - BPF_ALU64_IMM(BPF_ADD, BPF_REG_2, -8), - BPF_LD_MAP_FD(BPF_REG_1, 0), - BPF_RAW_INSN(BPF_JMP | BPF_CALL, 0, 0, 0, BPF_FUNC_map_lookup_elem), - BPF_EXIT_INSN(), - -Error:: - - 0: (7a) *(u64 *)(r10 -8) = 0 - 1: (bf) r2 = r10 - 2: (07) r2 += -8 - 3: (b7) r1 = 0x0 - 4: (85) call 1 - fd 0 is not pointing to valid bpf_map - -Program that doesn't check return value of map_lookup_elem() before accessing -map element:: - - BPF_ST_MEM(BPF_DW, BPF_REG_10, -8, 0), - BPF_MOV64_REG(BPF_REG_2, BPF_REG_10), - BPF_ALU64_IMM(BPF_ADD, BPF_REG_2, -8), - BPF_LD_MAP_FD(BPF_REG_1, 0), - BPF_RAW_INSN(BPF_JMP | BPF_CALL, 0, 0, 0, BPF_FUNC_map_lookup_elem), - BPF_ST_MEM(BPF_DW, BPF_REG_0, 0, 0), - BPF_EXIT_INSN(), - -Error:: - - 0: (7a) *(u64 *)(r10 -8) = 0 - 1: (bf) r2 = r10 - 2: (07) r2 += -8 - 3: (b7) r1 = 0x0 - 4: (85) call 1 - 5: (7a) *(u64 *)(r0 +0) = 0 - R0 invalid mem access 'map_value_or_null' - -Program that correctly checks map_lookup_elem() returned value for NULL, but -accesses the memory with incorrect alignment:: - - BPF_ST_MEM(BPF_DW, BPF_REG_10, -8, 0), - BPF_MOV64_REG(BPF_REG_2, BPF_REG_10), - BPF_ALU64_IMM(BPF_ADD, BPF_REG_2, -8), - BPF_LD_MAP_FD(BPF_REG_1, 0), - BPF_RAW_INSN(BPF_JMP | BPF_CALL, 0, 0, 0, BPF_FUNC_map_lookup_elem), - BPF_JMP_IMM(BPF_JEQ, BPF_REG_0, 0, 1), - BPF_ST_MEM(BPF_DW, BPF_REG_0, 4, 0), - BPF_EXIT_INSN(), - -Error:: - - 0: (7a) *(u64 *)(r10 -8) = 0 - 1: (bf) r2 = r10 - 2: (07) r2 += -8 - 3: (b7) r1 = 1 - 4: (85) call 1 - 5: (15) if r0 == 0x0 goto pc+1 - R0=map_ptr R10=fp - 6: (7a) *(u64 *)(r0 +4) = 0 - misaligned access off 4 size 8 - -Program that correctly checks map_lookup_elem() returned value for NULL and -accesses memory with correct alignment in one side of 'if' branch, but fails -to do so in the other side of 'if' branch:: - - BPF_ST_MEM(BPF_DW, BPF_REG_10, -8, 0), - BPF_MOV64_REG(BPF_REG_2, BPF_REG_10), - BPF_ALU64_IMM(BPF_ADD, BPF_REG_2, -8), - BPF_LD_MAP_FD(BPF_REG_1, 0), - BPF_RAW_INSN(BPF_JMP | BPF_CALL, 0, 0, 0, BPF_FUNC_map_lookup_elem), - BPF_JMP_IMM(BPF_JEQ, BPF_REG_0, 0, 2), - BPF_ST_MEM(BPF_DW, BPF_REG_0, 0, 0), - BPF_EXIT_INSN(), - BPF_ST_MEM(BPF_DW, BPF_REG_0, 0, 1), - BPF_EXIT_INSN(), - -Error:: - - 0: (7a) *(u64 *)(r10 -8) = 0 - 1: (bf) r2 = r10 - 2: (07) r2 += -8 - 3: (b7) r1 = 1 - 4: (85) call 1 - 5: (15) if r0 == 0x0 goto pc+2 - R0=map_ptr R10=fp - 6: (7a) *(u64 *)(r0 +0) = 0 - 7: (95) exit - - from 5 to 8: R0=imm0 R10=fp - 8: (7a) *(u64 *)(r0 +0) = 1 - R0 invalid mem access 'imm' - -Program that performs a socket lookup then sets the pointer to NULL without -checking it:: - - BPF_MOV64_IMM(BPF_REG_2, 0), - BPF_STX_MEM(BPF_W, BPF_REG_10, BPF_REG_2, -8), - BPF_MOV64_REG(BPF_REG_2, BPF_REG_10), - BPF_ALU64_IMM(BPF_ADD, BPF_REG_2, -8), - BPF_MOV64_IMM(BPF_REG_3, 4), - BPF_MOV64_IMM(BPF_REG_4, 0), - BPF_MOV64_IMM(BPF_REG_5, 0), - BPF_EMIT_CALL(BPF_FUNC_sk_lookup_tcp), - BPF_MOV64_IMM(BPF_REG_0, 0), - BPF_EXIT_INSN(), - -Error:: - - 0: (b7) r2 = 0 - 1: (63) *(u32 *)(r10 -8) = r2 - 2: (bf) r2 = r10 - 3: (07) r2 += -8 - 4: (b7) r3 = 4 - 5: (b7) r4 = 0 - 6: (b7) r5 = 0 - 7: (85) call bpf_sk_lookup_tcp#65 - 8: (b7) r0 = 0 - 9: (95) exit - Unreleased reference id=1, alloc_insn=7 - -Program that performs a socket lookup but does not NULL-check the returned -value:: - - BPF_MOV64_IMM(BPF_REG_2, 0), - BPF_STX_MEM(BPF_W, BPF_REG_10, BPF_REG_2, -8), - BPF_MOV64_REG(BPF_REG_2, BPF_REG_10), - BPF_ALU64_IMM(BPF_ADD, BPF_REG_2, -8), - BPF_MOV64_IMM(BPF_REG_3, 4), - BPF_MOV64_IMM(BPF_REG_4, 0), - BPF_MOV64_IMM(BPF_REG_5, 0), - BPF_EMIT_CALL(BPF_FUNC_sk_lookup_tcp), - BPF_EXIT_INSN(), - -Error:: - - 0: (b7) r2 = 0 - 1: (63) *(u32 *)(r10 -8) = r2 - 2: (bf) r2 = r10 - 3: (07) r2 += -8 - 4: (b7) r3 = 4 - 5: (b7) r4 = 0 - 6: (b7) r5 = 0 - 7: (85) call bpf_sk_lookup_tcp#65 - 8: (95) exit - Unreleased reference id=1, alloc_insn=7 - Testing ------- Next to the BPF toolchain, the kernel also ships a test module that contains -various test cases for classic and internal BPF that can be executed against +various test cases for classic and eBPF that can be executed against the BPF interpreter and JIT compiler. It can be found in lib/test_bpf.c and enabled via Kconfig:: diff --git a/Documentation/networking/ip-sysctl.rst b/Documentation/networking/ip-sysctl.rst index c04431144f7a..2572eecc3e86 100644 --- a/Documentation/networking/ip-sysctl.rst +++ b/Documentation/networking/ip-sysctl.rst @@ -25,7 +25,8 @@ ip_default_ttl - INTEGER ip_no_pmtu_disc - INTEGER Disable Path MTU Discovery. If enabled in mode 1 and a fragmentation-required ICMP is received, the PMTU to this - destination will be set to min_pmtu (see below). You will need + destination will be set to the smallest of the old MTU to + this destination and min_pmtu (see below). You will need to raise min_pmtu to the smallest interface MTU on your system manually if you want to avoid locally generated fragments. @@ -49,7 +50,8 @@ ip_no_pmtu_disc - INTEGER Default: FALSE min_pmtu - INTEGER - default 552 - minimum discovered Path MTU + default 552 - minimum Path MTU. Unless this is changed mannually, + each cached pmtu will never be lower than this setting. ip_forward_use_pmtu - BOOLEAN By default we don't trust protocol path MTUs while forwarding diff --git a/Documentation/networking/ipvs-sysctl.rst b/Documentation/networking/ipvs-sysctl.rst index 95ef56d62077..387fda80f05f 100644 --- a/Documentation/networking/ipvs-sysctl.rst +++ b/Documentation/networking/ipvs-sysctl.rst @@ -37,8 +37,7 @@ conn_reuse_mode - INTEGER 0: disable any special handling on port reuse. The new connection will be delivered to the same real server that was - servicing the previous connection. This will effectively - disable expire_nodest_conn. + servicing the previous connection. bit 1: enable rescheduling of new connections when it is safe. That is, whenever expire_nodest_conn and for TCP sockets, when diff --git a/Documentation/networking/net_failover.rst b/Documentation/networking/net_failover.rst index e143ab79a960..3a662f2b4d6e 100644 --- a/Documentation/networking/net_failover.rst +++ b/Documentation/networking/net_failover.rst @@ -35,7 +35,7 @@ To support this, the hypervisor needs to enable VIRTIO_NET_F_STANDBY feature on the virtio-net interface and assign the same MAC address to both virtio-net and VF interfaces. -Here is an example XML snippet that shows such configuration. +Here is an example libvirt XML snippet that shows such configuration: :: <interface type='network'> @@ -45,18 +45,32 @@ Here is an example XML snippet that shows such configuration. <model type='virtio'/> <driver name='vhost' queues='4'/> <link state='down'/> - <address type='pci' domain='0x0000' bus='0x00' slot='0x0a' function='0x0'/> + <teaming type='persistent'/> + <alias name='ua-backup0'/> </interface> <interface type='hostdev' managed='yes'> <mac address='52:54:00:00:12:53'/> <source> <address type='pci' domain='0x0000' bus='0x42' slot='0x02' function='0x5'/> </source> - <address type='pci' domain='0x0000' bus='0x00' slot='0x0b' function='0x0'/> + <teaming type='transient' persistent='ua-backup0'/> </interface> +In this configuration, the first device definition is for the virtio-net +interface and this acts as the 'persistent' device indicating that this +interface will always be plugged in. This is specified by the 'teaming' tag with +required attribute type having value 'persistent'. The link state for the +virtio-net device is set to 'down' to ensure that the 'failover' netdev prefers +the VF passthrough device for normal communication. The virtio-net device will +be brought UP during live migration to allow uninterrupted communication. + +The second device definition is for the VF passthrough interface. Here the +'teaming' tag is provided with type 'transient' indicating that this device may +periodically be unplugged. A second attribute - 'persistent' is provided and +points to the alias name declared for the virtio-net device. + Booting a VM with the above configuration will result in the following 3 -netdevs created in the VM. +interfaces created in the VM: :: 4: ens10: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000 @@ -65,13 +79,36 @@ netdevs created in the VM. valid_lft 42482sec preferred_lft 42482sec inet6 fe80::97d8:db2:8c10:b6d6/64 scope link valid_lft forever preferred_lft forever - 5: ens10nsby: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel master ens10 state UP group default qlen 1000 + 5: ens10nsby: <BROADCAST,MULTICAST> mtu 1500 qdisc fq_codel master ens10 state DOWN group default qlen 1000 link/ether 52:54:00:00:12:53 brd ff:ff:ff:ff:ff:ff 7: ens11: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq master ens10 state UP group default qlen 1000 link/ether 52:54:00:00:12:53 brd ff:ff:ff:ff:ff:ff -ens10 is the 'failover' master netdev, ens10nsby and ens11 are the slave -'standby' and 'primary' netdevs respectively. +Here, ens10 is the 'failover' master interface, ens10nsby is the slave 'standby' +virtio-net interface, and ens11 is the slave 'primary' VF passthrough interface. + +One point to note here is that some user space network configuration daemons +like systemd-networkd, ifupdown, etc, do not understand the 'net_failover' +device; and on the first boot, the VM might end up with both 'failover' device +and VF accquiring IP addresses (either same or different) from the DHCP server. +This will result in lack of connectivity to the VM. So some tweaks might be +needed to these network configuration daemons to make sure that an IP is +received only on the 'failover' device. + +Below is the patch snippet used with 'cloud-ifupdown-helper' script found on +Debian cloud images: + +:: + @@ -27,6 +27,8 @@ do_setup() { + local working="$cfgdir/.$INTERFACE" + local final="$cfgdir/$INTERFACE" + + + if [ -d "/sys/class/net/${INTERFACE}/master" ]; then exit 0; fi + + + if ifup --no-act "$INTERFACE" > /dev/null 2>&1; then + # interface is already known to ifupdown, no need to generate cfg + log "Skipping configuration generation for $INTERFACE" + Live Migration of a VM with SR-IOV VF & virtio-net in STANDBY mode ================================================================== @@ -80,40 +117,68 @@ net_failover also enables hypervisor controlled live migration to be supported with VMs that have direct attached SR-IOV VF devices by automatic failover to the paravirtual datapath when the VF is unplugged. -Here is a sample script that shows the steps to initiate live migration on -the source hypervisor. +Here is a sample script that shows the steps to initiate live migration from +the source hypervisor. Note: It is assumed that the VM is connected to a +software bridge 'br0' which has a single VF attached to it along with the vnet +device to the VM. This is not the VF that was passthrough'd to the VM (seen in +the vf.xml file). :: - # cat vf_xml + # cat vf.xml <interface type='hostdev' managed='yes'> <mac address='52:54:00:00:12:53'/> <source> <address type='pci' domain='0x0000' bus='0x42' slot='0x02' function='0x5'/> </source> - <address type='pci' domain='0x0000' bus='0x00' slot='0x0b' function='0x0'/> + <teaming type='transient' persistent='ua-backup0'/> </interface> - # Source Hypervisor + # Source Hypervisor migrate.sh #!/bin/bash - DOMAIN=fedora27-tap01 - PF=enp66s0f0 - VF_NUM=5 - TAP_IF=tap01 - VF_XML= + DOMAIN=vm-01 + PF=ens6np0 + VF=ens6v1 # VF attached to the bridge. + VF_NUM=1 + TAP_IF=vmtap01 # virtio-net interface in the VM. + VF_XML=vf.xml MAC=52:54:00:00:12:53 ZERO_MAC=00:00:00:00:00:00 + # Set the virtio-net interface up. virsh domif-setlink $DOMAIN $TAP_IF up - bridge fdb del $MAC dev $PF master - virsh detach-device $DOMAIN $VF_XML + + # Remove the VF that was passthrough'd to the VM. + virsh detach-device --live --config $DOMAIN $VF_XML + ip link set $PF vf $VF_NUM mac $ZERO_MAC - virsh migrate --live $DOMAIN qemu+ssh://$REMOTE_HOST/system + # Add FDB entry for traffic to continue going to the VM via + # the VF -> br0 -> vnet interface path. + bridge fdb add $MAC dev $VF + bridge fdb add $MAC dev $TAP_IF master + + # Migrate the VM + virsh migrate --live --persistent $DOMAIN qemu+ssh://$REMOTE_HOST/system + + # Clean up FDB entries after migration completes. + bridge fdb del $MAC dev $VF + bridge fdb del $MAC dev $TAP_IF master - # Destination Hypervisor +On the destination hypervisor, a shared bridge 'br0' is created before migration +starts, and a VF from the destination PF is added to the bridge. Similarly an +appropriate FDB entry is added. + +The following script is executed on the destination hypervisor once migration +completes, and it reattaches the VF to the VM and brings down the virtio-net +interface. + +:: + # reattach-vf.sh #!/bin/bash - virsh attach-device $DOMAIN $VF_XML - virsh domif-setlink $DOMAIN $TAP_IF down + bridge fdb del 52:54:00:00:12:53 dev ens36v0 + bridge fdb del 52:54:00:00:12:53 dev vmtap01 master + virsh attach-device --config --live vm01 vf.xml + virsh domif-setlink vm01 vmtap01 down diff --git a/Documentation/networking/phy.rst b/Documentation/networking/phy.rst index 571ba08386e7..d43da709bf40 100644 --- a/Documentation/networking/phy.rst +++ b/Documentation/networking/phy.rst @@ -237,6 +237,11 @@ negotiation results. Some of the interface modes are described below: +``PHY_INTERFACE_MODE_SMII`` + This is serial MII, clocked at 125MHz, supporting 100M and 10M speeds. + Some details can be found in + https://opencores.org/ocsvn/smii/smii/trunk/doc/SMII.pdf + ``PHY_INTERFACE_MODE_1000BASEX`` This defines the 1000BASE-X single-lane serdes link as defined by the 802.3 standard section 36. The link operates at a fixed bit rate of diff --git a/Documentation/networking/rds.rst b/Documentation/networking/rds.rst index 44936c27ab3a..498395f5fbcb 100644 --- a/Documentation/networking/rds.rst +++ b/Documentation/networking/rds.rst @@ -1,6 +1,6 @@ .. SPDX-License-Identifier: GPL-2.0 -== +=== RDS === diff --git a/Documentation/networking/timestamping.rst b/Documentation/networking/timestamping.rst index a722eb30e014..f5809206eb93 100644 --- a/Documentation/networking/timestamping.rst +++ b/Documentation/networking/timestamping.rst @@ -486,8 +486,8 @@ of packets. Drivers are free to use a more permissive configuration than the requested configuration. It is expected that drivers should only implement directly the most generic mode that can be supported. For example if the hardware can -support HWTSTAMP_FILTER_V2_EVENT, then it should generally always upscale -HWTSTAMP_FILTER_V2_L2_SYNC_MESSAGE, and so forth, as HWTSTAMP_FILTER_V2_EVENT +support HWTSTAMP_FILTER_PTP_V2_EVENT, then it should generally always upscale +HWTSTAMP_FILTER_PTP_V2_L2_SYNC, and so forth, as HWTSTAMP_FILTER_PTP_V2_EVENT is more generic (and more useful to applications). A driver which supports hardware time stamping shall update the struct @@ -582,8 +582,8 @@ Time stamps for outgoing packets are to be generated as follows: and hardware timestamping is not possible (SKBTX_IN_PROGRESS not set). - As soon as the driver has sent the packet and/or obtained a hardware time stamp for it, it passes the time stamp back by - calling skb_hwtstamp_tx() with the original skb, the raw - hardware time stamp. skb_hwtstamp_tx() clones the original skb and + calling skb_tstamp_tx() with the original skb, the raw + hardware time stamp. skb_tstamp_tx() clones the original skb and adds the timestamps, therefore the original skb has to be freed now. If obtaining the hardware time stamp somehow fails, then the driver should not fall back to software time stamping. The rationale is that diff --git a/Documentation/power/opp.rst b/Documentation/power/opp.rst index e3cc4f349ea8..a7c03c470980 100644 --- a/Documentation/power/opp.rst +++ b/Documentation/power/opp.rst @@ -48,9 +48,9 @@ We can represent these as three OPPs as the following {Hz, uV} tuples: OPP library provides a set of helper functions to organize and query the OPP information. The library is located in drivers/opp/ directory and the header is located in include/linux/pm_opp.h. OPP library can be enabled by enabling -CONFIG_PM_OPP from power management menuconfig menu. OPP library depends on -CONFIG_PM as certain SoCs such as Texas Instrument's OMAP framework allows to -optionally boot at a certain OPP without needing cpufreq. +CONFIG_PM_OPP from power management menuconfig menu. Certain SoCs such as Texas +Instrument's OMAP framework allows to optionally boot at a certain OPP without +needing cpufreq. Typical usage of the OPP library is as follows:: @@ -75,8 +75,8 @@ operations until that OPP could be re-enabled if possible. OPP library facilitates this concept in its implementation. The following operational functions operate only on available opps: -opp_find_freq_{ceil, floor}, dev_pm_opp_get_voltage, dev_pm_opp_get_freq, -dev_pm_opp_get_opp_count +dev_pm_opp_find_freq_{ceil, floor}, dev_pm_opp_get_voltage, dev_pm_opp_get_freq, +dev_pm_opp_get_opp_count. dev_pm_opp_find_freq_exact is meant to be used to find the opp pointer which can then be used for dev_pm_opp_enable/disable functions to make an @@ -103,7 +103,7 @@ dev_pm_opp_add The OPP is defined using the frequency and voltage. Once added, the OPP is assumed to be available and control of its availability can be done with the dev_pm_opp_enable/disable functions. OPP library - internally stores and manages this information in the opp struct. + internally stores and manages this information in the dev_pm_opp struct. This function may be used by SoC framework to define a optimal list as per the demands of SoC usage environment. @@ -247,7 +247,7 @@ dev_pm_opp_disable 5. OPP Data Retrieval Functions =============================== Since OPP library abstracts away the OPP information, a set of functions to pull -information from the OPP structure is necessary. Once an OPP pointer is +information from the dev_pm_opp structure is necessary. Once an OPP pointer is retrieved using the search functions, the following functions can be used by SoC framework to retrieve the information represented inside the OPP layer. diff --git a/Documentation/power/runtime_pm.rst b/Documentation/power/runtime_pm.rst index d6bf84f061f4..65b86e487afe 100644 --- a/Documentation/power/runtime_pm.rst +++ b/Documentation/power/runtime_pm.rst @@ -265,6 +265,10 @@ defined in include/linux/pm.h: RPM_SUSPENDED, which means that each device is initially regarded by the PM core as 'suspended', regardless of its real hardware status + `enum rpm_status last_status;` + - the last runtime PM status of the device captured before disabling runtime + PM for it (invalid initially and when disable_depth is 0) + `unsigned int runtime_auto;` - if set, indicates that the user space has allowed the device driver to power manage the device at run time via the /sys/devices/.../power/control @@ -333,10 +337,12 @@ drivers/base/power/runtime.c and include/linux/pm_runtime.h: `int pm_runtime_resume(struct device *dev);` - execute the subsystem-level resume callback for the device; returns 0 on - success, 1 if the device's runtime PM status was already 'active' or - error code on failure, where -EAGAIN means it may be safe to attempt to - resume the device again in future, but 'power.runtime_error' should be - checked additionally, and -EACCES means that 'power.disable_depth' is + success, 1 if the device's runtime PM status is already 'active' (also if + 'power.disable_depth' is nonzero, but the status was 'active' when it was + changing from 0 to 1) or error code on failure, where -EAGAIN means it may + be safe to attempt to resume the device again in future, but + 'power.runtime_error' should be checked additionally, and -EACCES means + that the callback could not be run, because 'power.disable_depth' was different from 0 `int pm_runtime_resume_and_get(struct device *dev);` diff --git a/Documentation/process/5.Posting.rst b/Documentation/process/5.Posting.rst index 855a70b80269..bd36ecb29409 100644 --- a/Documentation/process/5.Posting.rst +++ b/Documentation/process/5.Posting.rst @@ -197,14 +197,29 @@ the build process, for example, or editor backup files) in the patch. The file "dontdiff" in the Documentation directory can help in this regard; pass it to diff with the "-X" option. -The tags mentioned above are used to describe how various developers have -been associated with the development of this patch. They are described in -detail in -the :ref:`Documentation/process/submitting-patches.rst <submittingpatches>` -document; what follows here is a brief summary. Each of these lines has -the format: +The tags already briefly mentioned above are used to provide insights how +the patch came into being. They are described in detail in the +:ref:`Documentation/process/submitting-patches.rst <submittingpatches>` +document; what follows here is a brief summary. -:: +One tag is used to refer to earlier commits which introduced problems fixed by +the patch:: + + Fixes: 1f2e3d4c5b6a ("The first line of the commit specified by the first 12 characters of its SHA-1 ID") + +Another tag is used for linking web pages with additional backgrounds or +details, for example a report about a bug fixed by the patch or a document +with a specification implemented by the patch:: + + Link: https://example.com/somewhere.html optional-other-stuff + +Many maintainers when applying a patch also add this tag to link to the +latest public review posting of the patch; often this is automatically done +by tools like b4 or a git hook like the one described in +'Documentation/maintainer/configure-git.rst'. + +A third kind of tag is used to document who was involved in the development of +the patch. Each of these uses this format:: tag: Full Name <email address> optional-other-stuff diff --git a/Documentation/process/changes.rst b/Documentation/process/changes.rst index b398b8576417..a337e8eabfe1 100644 --- a/Documentation/process/changes.rst +++ b/Documentation/process/changes.rst @@ -30,11 +30,12 @@ you probably needn't concern yourself with pcmciautils. Program Minimal version Command to check the version ====================== =============== ======================================== GNU C 5.1 gcc --version -Clang/LLVM (optional) 10.0.1 clang --version +Clang/LLVM (optional) 11.0.0 clang --version GNU make 3.81 make --version binutils 2.23 ld -v flex 2.5.35 flex --version bison 2.0 bison --version +pahole 1.16 pahole --version util-linux 2.10o fdformat --version kmod 13 depmod -V e2fsprogs 1.41.4 e2fsck -V @@ -108,6 +109,16 @@ Bison Since Linux 4.16, the build system generates parsers during build. This requires bison 2.0 or later. +pahole: +------- + +Since Linux 5.2, if CONFIG_DEBUG_INFO_BTF is selected, the build system +generates BTF (BPF Type Format) from DWARF in vmlinux, a bit later from kernel +modules as well. This requires pahole v1.16 or later. + +It is found in the 'dwarves' or 'pahole' distro packages or from +https://fedorapeople.org/~acme/dwarves/. + Perl ---- diff --git a/Documentation/process/submitting-patches.rst b/Documentation/process/submitting-patches.rst index da085d63af9b..31ea120ce531 100644 --- a/Documentation/process/submitting-patches.rst +++ b/Documentation/process/submitting-patches.rst @@ -14,7 +14,8 @@ works, see Documentation/process/development-process.rst. Also, read Documentation/process/submit-checklist.rst for a list of items to check before submitting code. If you are submitting a driver, also read Documentation/process/submitting-drivers.rst; for device -tree binding patches, read Documentation/process/submitting-patches.rst. +tree binding patches, read +Documentation/devicetree/bindings/submitting-patches.rst. This documentation assumes that you're using ``git`` to prepare your patches. If you're unfamiliar with ``git``, you would be well-advised to learn how to @@ -270,25 +271,6 @@ least a notification of the change, so that some information makes its way into the manual pages. User-space API changes should also be copied to linux-api@vger.kernel.org. -For small patches you may want to CC the Trivial Patch Monkey -trivial@kernel.org which collects "trivial" patches. Have a look -into the MAINTAINERS file for its current manager. - -Trivial patches must qualify for one of the following rules: - -- Spelling fixes in documentation -- Spelling fixes for errors which could break :manpage:`grep(1)` -- Warning fixes (cluttering with useless warnings is bad) -- Compilation fixes (only if they are actually correct) -- Runtime fixes (only if they actually fix things) -- Removing use of deprecated functions/macros -- Contact detail and documentation fixes -- Non-portable code replaced by portable code (even in arch-specific, - since people copy, as long as it's trivial) -- Any fix by the author/maintainer of the file (ie. patch monkey - in re-transmission mode) - - No MIME, no links, no compression, no attachments. Just plain text ------------------------------------------------------------------- diff --git a/Documentation/riscv/vm-layout.rst b/Documentation/riscv/vm-layout.rst index b7f98930d38d..1bd687b97104 100644 --- a/Documentation/riscv/vm-layout.rst +++ b/Documentation/riscv/vm-layout.rst @@ -47,12 +47,12 @@ RISC-V Linux Kernel SV39 | Kernel-space virtual memory, shared between all processes: ____________________________________________________________|___________________________________________________________ | | | | - ffffffc000000000 | -256 GB | ffffffc7ffffffff | 32 GB | kasan - ffffffcefee00000 | -196 GB | ffffffcefeffffff | 2 MB | fixmap - ffffffceff000000 | -196 GB | ffffffceffffffff | 16 MB | PCI io - ffffffcf00000000 | -196 GB | ffffffcfffffffff | 4 GB | vmemmap - ffffffd000000000 | -192 GB | ffffffdfffffffff | 64 GB | vmalloc/ioremap space - ffffffe000000000 | -128 GB | ffffffff7fffffff | 124 GB | direct mapping of all physical memory + ffffffc6fee00000 | -228 GB | ffffffc6feffffff | 2 MB | fixmap + ffffffc6ff000000 | -228 GB | ffffffc6ffffffff | 16 MB | PCI io + ffffffc700000000 | -228 GB | ffffffc7ffffffff | 4 GB | vmemmap + ffffffc800000000 | -224 GB | ffffffd7ffffffff | 64 GB | vmalloc/ioremap space + ffffffd800000000 | -160 GB | fffffff6ffffffff | 124 GB | direct mapping of all physical memory + fffffff700000000 | -36 GB | fffffffeffffffff | 32 GB | kasan __________________|____________|__________________|_________|____________________________________________________________ | | diff --git a/Documentation/scheduler/sched-bwc.rst b/Documentation/scheduler/sched-bwc.rst index 173c14110c85..f166b182ff95 100644 --- a/Documentation/scheduler/sched-bwc.rst +++ b/Documentation/scheduler/sched-bwc.rst @@ -74,7 +74,6 @@ Quota, period and burst are managed within the cpu subsystem via cgroupfs. to cgroup v1. For cgroup v2, see :ref:`Documentation/admin-guide/cgroup-v2.rst <cgroup-v2-cpu>`. -- cpu.cfs_quota_us: the total available run-time within a period (in - cpu.cfs_quota_us: run-time replenished within a period (in microseconds) - cpu.cfs_period_us: the length of a period (in microseconds) - cpu.stat: exports throttling statistics [explained further below] @@ -135,7 +134,7 @@ cpu.stat: of the group have been throttled. - nr_bursts: Number of periods burst occurs. - burst_time: Cumulative wall-time (in nanoseconds) that any CPUs has used - above quota in respective periods + above quota in respective periods. This interface is read-only. @@ -238,7 +237,7 @@ Examples additionally, in case accumulation has been done. With 50ms period, 20ms quota will be equivalent to 40% of 1 CPU. - And 10ms burst will be equivalent to 20% of 1 CPU. + And 10ms burst will be equivalent to 20% of 1 CPU:: # echo 20000 > cpu.cfs_quota_us /* quota = 20ms */ # echo 50000 > cpu.cfs_period_us /* period = 50ms */ diff --git a/Documentation/security/self-protection.rst b/Documentation/security/self-protection.rst index f584fb74b4ff..910668e665cb 100644 --- a/Documentation/security/self-protection.rst +++ b/Documentation/security/self-protection.rst @@ -81,8 +81,7 @@ of the kernel, gaining the protection of the kernel's strict memory permissions as described above. For variables that are initialized once at ``__init`` time, these can -be marked with the (new and under development) ``__ro_after_init`` -attribute. +be marked with the ``__ro_after_init`` attribute. What remains are variables that are updated rarely (e.g. GDT). These will need another infrastructure (similar to the temporary exceptions diff --git a/Documentation/sound/hd-audio/models.rst b/Documentation/sound/hd-audio/models.rst index 0ea967d34583..d25335993e55 100644 --- a/Documentation/sound/hd-audio/models.rst +++ b/Documentation/sound/hd-audio/models.rst @@ -326,6 +326,8 @@ usi-headset Headset support on USI machines dual-codecs Lenovo laptops with dual codecs +alc285-hp-amp-init + HP laptops which require speaker amplifier initialization (ALC285) ALC680 ====== diff --git a/Documentation/sphinx-static/theme_overrides.css b/Documentation/sphinx-static/theme_overrides.css index 459ec5b29d68..f6f2b941a5d6 100644 --- a/Documentation/sphinx-static/theme_overrides.css +++ b/Documentation/sphinx-static/theme_overrides.css @@ -1,14 +1,14 @@ /* -*- coding: utf-8; mode: css -*- * * Sphinx HTML theme customization: read the doc - * + * Please don't add any color definition here, as the theme should + * work for both normal and dark modes. */ /* Improve contrast and increase size for easier reading. */ body { font-family: serif; - color: black; font-size: 100%; } @@ -16,17 +16,8 @@ h1, h2, .rst-content .toctree-wrapper p.caption, h3, h4, h5, h6, legend { font-family: sans-serif; } -.wy-menu-vertical li.current a { - color: #505050; -} - -.wy-menu-vertical li.on a, .wy-menu-vertical li.current > a { - color: #303030; -} - div[class^="highlight"] pre { font-family: monospace; - color: black; font-size: 100%; } @@ -104,13 +95,10 @@ div[class^="highlight"] pre { /* Menu selection and keystrokes */ span.menuselection { - color: blue; font-family: "Courier New", Courier, monospace } code.kbd, code.kbd span { - color: white; - background-color: darkblue; font-weight: bold; font-family: "Courier New", Courier, monospace } diff --git a/Documentation/sphinx-static/theme_rtd_colors.css b/Documentation/sphinx-static/theme_rtd_colors.css new file mode 100644 index 000000000000..55b6e1c3664b --- /dev/null +++ b/Documentation/sphinx-static/theme_rtd_colors.css @@ -0,0 +1,37 @@ +/* -*- coding: utf-8; mode: css -*- + * + * Sphinx HTML theme customization: color settings for RTD (non-dark) theme + * + */ + +/* Improve contrast and increase size for easier reading. */ + +body { + color: black; +} + +.wy-menu-vertical li.current a { + color: #505050; +} + +.wy-menu-vertical li.on a, .wy-menu-vertical li.current > a { + color: #303030; +} + +div[class^="highlight"] pre { + color: black; +} + +@media screen { + + /* Menu selection and keystrokes */ + + span.menuselection { + color: blue; + } + + code.kbd, code.kbd span { + color: white; + background-color: darkblue; + } +} diff --git a/Documentation/sphinx/automarkup.py b/Documentation/sphinx/automarkup.py index acf5473002f3..cc348b219fca 100644 --- a/Documentation/sphinx/automarkup.py +++ b/Documentation/sphinx/automarkup.py @@ -271,19 +271,30 @@ def get_c_namespace(app, docname): def auto_markup(app, doctree, name): global c_namespace c_namespace = get_c_namespace(app, name) + def text_but_not_a_reference(node): + # The nodes.literal test catches ``literal text``, its purpose is to + # avoid adding cross-references to functions that have been explicitly + # marked with cc:func:. + if not isinstance(node, nodes.Text) or isinstance(node.parent, nodes.literal): + return False + + child_of_reference = False + parent = node.parent + while parent: + if isinstance(parent, nodes.Referential): + child_of_reference = True + break + parent = parent.parent + return not child_of_reference + # # This loop could eventually be improved on. Someday maybe we # want a proper tree traversal with a lot of awareness of which # kinds of nodes to prune. But this works well for now. # - # The nodes.literal test catches ``literal text``, its purpose is to - # avoid adding cross-references to functions that have been explicitly - # marked with cc:func:. - # for para in doctree.traverse(nodes.paragraph): - for node in para.traverse(nodes.Text): - if not isinstance(node.parent, nodes.literal): - node.parent.replace(node, markup_refs(name, app, node)) + for node in para.traverse(condition=text_but_not_a_reference): + node.parent.replace(node, markup_refs(name, app, node)) def setup(app): app.connect('doctree-resolved', auto_markup) diff --git a/Documentation/sphinx/kernel_abi.py b/Documentation/sphinx/kernel_abi.py index efe760e410c4..4392b3cb4020 100644 --- a/Documentation/sphinx/kernel_abi.py +++ b/Documentation/sphinx/kernel_abi.py @@ -104,7 +104,7 @@ class KernelCmd(Directive): return nodeList def runCmd(self, cmd, **kwargs): - u"""Run command ``cmd`` and return it's stdout as unicode.""" + u"""Run command ``cmd`` and return its stdout as unicode.""" try: proc = subprocess.Popen( diff --git a/Documentation/sphinx/kernel_feat.py b/Documentation/sphinx/kernel_feat.py index c91ea2b27697..8138d69a6987 100644 --- a/Documentation/sphinx/kernel_feat.py +++ b/Documentation/sphinx/kernel_feat.py @@ -106,7 +106,7 @@ class KernelFeat(Directive): return nodeList def runCmd(self, cmd, **kwargs): - u"""Run command ``cmd`` and return it's stdout as unicode.""" + u"""Run command ``cmd`` and return its stdout as unicode.""" try: proc = subprocess.Popen( diff --git a/Documentation/spi/pxa2xx.rst b/Documentation/spi/pxa2xx.rst index 6312968acfe9..6347580826be 100644 --- a/Documentation/spi/pxa2xx.rst +++ b/Documentation/spi/pxa2xx.rst @@ -101,8 +101,7 @@ device. All fields are optional. u8 rx_threshold; u8 dma_burst_size; u32 timeout; - u8 enable_loopback; - void (*cs_control)(u32 command); + int gpio_cs; }; The "pxa2xx_spi_chip.tx_threshold" and "pxa2xx_spi_chip.rx_threshold" fields are @@ -128,16 +127,6 @@ dependent on the SPI bus speed ("spi_board_info.max_speed_hz") and the specific slave device. Please note that the PXA2xx SSP 1 does not support trailing byte timeouts and must busy-wait any trailing bytes. -The "pxa2xx_spi_chip.enable_loopback" field is used to place the SSP porting -into internal loopback mode. In this mode the SSP controller internally -connects the SSPTX pin to the SSPRX pin. This is useful for initial setup -testing. - -The "pxa2xx_spi_chip.cs_control" field is used to point to a board specific -function for asserting/deasserting a slave device chip select. If the field is -NULL, the pxa2xx_spi master controller driver assumes that the SSP port is -configured to use GPIO or SSPFRM instead. - NOTE: the SPI driver cannot control the chip select if SSPFRM is used, so the chipselect is dropped after each spi_transfer. Most devices need chip select asserted around the complete message. Use SSPFRM as a GPIO (through a descriptor) @@ -152,30 +141,12 @@ field. Below is a sample configuration using the PXA255 NSSP. :: - /* Chip Select control for the CS8415A SPI slave device */ - static void cs8415a_cs_control(u32 command) - { - if (command & PXA2XX_CS_ASSERT) - GPCR(2) = GPIO_bit(2); - else - GPSR(2) = GPIO_bit(2); - } - - /* Chip Select control for the CS8405A SPI slave device */ - static void cs8405a_cs_control(u32 command) - { - if (command & PXA2XX_CS_ASSERT) - GPCR(3) = GPIO_bit(3); - else - GPSR(3) = GPIO_bit(3); - } - static struct pxa2xx_spi_chip cs8415a_chip_info = { .tx_threshold = 8, /* SSP hardward FIFO threshold */ .rx_threshold = 8, /* SSP hardward FIFO threshold */ .dma_burst_size = 8, /* Byte wide transfers used so 8 byte bursts */ .timeout = 235, /* See Intel documentation */ - .cs_control = cs8415a_cs_control, /* Use external chip select */ + .gpio_cs = 2, /* Use external chip select */ }; static struct pxa2xx_spi_chip cs8405a_chip_info = { @@ -183,7 +154,7 @@ field. Below is a sample configuration using the PXA255 NSSP. .rx_threshold = 8, /* SSP hardward FIFO threshold */ .dma_burst_size = 8, /* Byte wide transfers used so 8 byte bursts */ .timeout = 235, /* See Intel documentation */ - .cs_control = cs8405a_cs_control, /* Use external chip select */ + .gpio_cs = 3, /* Use external chip select */ }; static struct spi_board_info streetracer_spi_board_info[] __initdata = { diff --git a/Documentation/spi/spidev.rst b/Documentation/spi/spidev.rst index f05dbc5ccdbc..369c657ba435 100644 --- a/Documentation/spi/spidev.rst +++ b/Documentation/spi/spidev.rst @@ -29,21 +29,49 @@ of the driver stack) that are not accessible to userspace. DEVICE CREATION, DRIVER BINDING =============================== -The simplest way to arrange to use this driver is to just list it in the -spi_board_info for a device as the driver it should use: the "modalias" -entry is "spidev", matching the name of the driver exposing this API. -Set up the other device characteristics (bits per word, SPI clocking, -chipselect polarity, etc) as usual, so you won't always need to override -them later. - -(Sysfs also supports userspace driven binding/unbinding of drivers to -devices. That mechanism might be supported here in the future.) - -When you do that, the sysfs node for the SPI device will include a child -device node with a "dev" attribute that will be understood by udev or mdev. -(Larger systems will have "udev". Smaller ones may configure "mdev" into -busybox; it's less featureful, but often enough.) For a SPI device with -chipselect C on bus B, you should see: + +The spidev driver contains lists of SPI devices that are supported for +the different hardware topology representations. + +The following are the SPI device tables supported by the spidev driver: + + - struct spi_device_id spidev_spi_ids[]: list of devices that can be + bound when these are defined using a struct spi_board_info with a + .modalias field matching one of the entries in the table. + + - struct of_device_id spidev_dt_ids[]: list of devices that can be + bound when these are defined using a Device Tree node that has a + compatible string matching one of the entries in the table. + + - struct acpi_device_id spidev_acpi_ids[]: list of devices that can + be bound when these are defined using a ACPI device object with a + _HID matching one of the entries in the table. + +You are encouraged to add an entry for your SPI device name to relevant +tables, if these don't already have an entry for the device. To do that, +post a patch for spidev to the linux-spi@vger.kernel.org mailing list. + +It used to be supported to define an SPI device using the "spidev" name. +For example, as .modalias = "spidev" or compatible = "spidev". But this +is no longer supported by the Linux kernel and instead a real SPI device +name as listed in one of the tables must be used. + +Not having a real SPI device name will lead to an error being printed and +the spidev driver failing to probe. + +Sysfs also supports userspace driven binding/unbinding of drivers to +devices that do not bind automatically using one of the tables above. +To make the spidev driver bind to such a device, use the following: + + echo spidev > /sys/bus/spi/devices/spiB.C/driver_override + echo spiB.C > /sys/bus/spi/drivers/spidev/bind + +When the spidev driver is bound to a SPI device, the sysfs node for the +device will include a child device node with a "dev" attribute that will +be understood by udev or mdev (udev replacement from BusyBox; it's less +featureful, but often enough). + +For a SPI device with chipselect C on bus B, you should see: /dev/spidevB.C ... character special device, major number 153 with diff --git a/Documentation/staging/tee.rst b/Documentation/staging/tee.rst index 4d4b5f889603..498343c7ab08 100644 --- a/Documentation/staging/tee.rst +++ b/Documentation/staging/tee.rst @@ -184,6 +184,36 @@ order to support device enumeration. In other words, OP-TEE driver invokes this application to retrieve a list of Trusted Applications which can be registered as devices on the TEE bus. +OP-TEE notifications +-------------------- + +There are two kinds of notifications that secure world can use to make +normal world aware of some event. + +1. Synchronous notifications delivered with ``OPTEE_RPC_CMD_NOTIFICATION`` + using the ``OPTEE_RPC_NOTIFICATION_SEND`` parameter. +2. Asynchronous notifications delivered with a combination of a non-secure + edge-triggered interrupt and a fast call from the non-secure interrupt + handler. + +Synchronous notifications are limited by depending on RPC for delivery, +this is only usable when secure world is entered with a yielding call via +``OPTEE_SMC_CALL_WITH_ARG``. This excludes such notifications from secure +world interrupt handlers. + +An asynchronous notification is delivered via a non-secure edge-triggered +interrupt to an interrupt handler registered in the OP-TEE driver. The +actual notification value are retrieved with the fast call +``OPTEE_SMC_GET_ASYNC_NOTIF_VALUE``. Note that one interrupt can represent +multiple notifications. + +One notification value ``OPTEE_SMC_ASYNC_NOTIF_VALUE_DO_BOTTOM_HALF`` has a +special meaning. When this value is received it means that normal world is +supposed to make a yielding call ``OPTEE_MSG_CMD_DO_BOTTOM_HALF``. This +call is done from the thread assisting the interrupt handler. This is a +building block for OP-TEE OS in secure world to implement the top half and +bottom half style of device drivers. + AMD-TEE driver ============== @@ -225,7 +255,7 @@ The following picture shows a high level overview of AMD-TEE:: +--------------------------+ +---------+--------------------+ At the lowest level (in x86), the AMD Secure Processor (ASP) driver uses the -CPU to PSP mailbox regsister to submit commands to the PSP. The format of the +CPU to PSP mailbox register to submit commands to the PSP. The format of the command buffer is opaque to the ASP driver. It's role is to submit commands to the secure processor and return results to AMD-TEE driver. The interface between AMD-TEE driver and AMD Secure Processor driver can be found in [6]. @@ -260,7 +290,7 @@ cancel_req driver callback is not supported by AMD-TEE. The GlobalPlatform TEE Client API [5] can be used by the user space (client) to talk to AMD's TEE. AMD's TEE provides a secure environment for loading, opening -a session, invoking commands and clossing session with TA. +a session, invoking commands and closing session with TA. References ========== diff --git a/Documentation/timers/no_hz.rst b/Documentation/timers/no_hz.rst index 20ad23a6c618..f8786be15183 100644 --- a/Documentation/timers/no_hz.rst +++ b/Documentation/timers/no_hz.rst @@ -184,16 +184,12 @@ There are situations in which idle CPUs cannot be permitted to enter either dyntick-idle mode or adaptive-tick mode, the most common being when that CPU has RCU callbacks pending. -The CONFIG_RCU_FAST_NO_HZ=y Kconfig option may be used to cause such CPUs -to enter dyntick-idle mode or adaptive-tick mode anyway. In this case, -a timer will awaken these CPUs every four jiffies in order to ensure -that the RCU callbacks are processed in a timely fashion. - -Another approach is to offload RCU callback processing to "rcuo" kthreads +Avoid this by offloading RCU callback processing to "rcuo" kthreads using the CONFIG_RCU_NOCB_CPU=y Kconfig option. The specific CPUs to offload may be selected using The "rcu_nocbs=" kernel boot parameter, which takes a comma-separated list of CPUs and CPU ranges, for example, -"1,3-5" selects CPUs 1, 3, 4, and 5. +"1,3-5" selects CPUs 1, 3, 4, and 5. Note that CPUs specified by +the "nohz_full" kernel boot parameter are also offloaded. The offloaded CPUs will never queue RCU callbacks, and therefore RCU never prevents offloaded CPUs from entering either dyntick-idle mode diff --git a/Documentation/tools/index.rst b/Documentation/tools/index.rst new file mode 100644 index 000000000000..0bb1e61bdcc0 --- /dev/null +++ b/Documentation/tools/index.rst @@ -0,0 +1,20 @@ +.. SPDX-License-Identifier: GPL-2.0 + +============ +Kernel tools +============ + +This book covers user-space tools that are shipped with the kernel source; +more additions are needed here: + +.. toctree:: + :maxdepth: 1 + + rtla/index + +.. only:: subproject and html + + Indices + ======= + + * :ref:`genindex` diff --git a/Documentation/tools/rtla/Makefile b/Documentation/tools/rtla/Makefile new file mode 100644 index 000000000000..9f2b84af1a6c --- /dev/null +++ b/Documentation/tools/rtla/Makefile @@ -0,0 +1,41 @@ +# SPDX-License-Identifier: GPL-2.0-only +# Based on bpftool's Documentation Makefile + +INSTALL ?= install +RM ?= rm -f +RMDIR ?= rmdir --ignore-fail-on-non-empty + +PREFIX ?= /usr/share +MANDIR ?= $(PREFIX)/man +MAN1DIR = $(MANDIR)/man1 + +MAN1_RST = $(wildcard rtla*.rst) + +_DOC_MAN1 = $(patsubst %.rst,%.1,$(MAN1_RST)) +DOC_MAN1 = $(addprefix $(OUTPUT),$(_DOC_MAN1)) + +RST2MAN_DEP := $(shell command -v rst2man 2>/dev/null) +RST2MAN_OPTS += --verbose + +$(OUTPUT)%.1: %.rst +ifndef RST2MAN_DEP + $(error "rst2man not found, but required to generate man pages") +endif + rst2man $(RST2MAN_OPTS) $< > $@ + +man1: $(DOC_MAN1) +man: man1 + +clean: + $(RM) $(DOC_MAN1) + +install: man + $(INSTALL) -d -m 755 $(DESTDIR)$(MAN1DIR) + $(INSTALL) -m 644 $(DOC_MAN1) $(DESTDIR)$(MAN1DIR) + +uninstall: + $(RM) $(addprefix $(DESTDIR)$(MAN1DIR)/,$(_DOC_MAN1)) + $(RMDIR) $(DESTDIR)$(MAN1DIR) + +.PHONY: man man1 clean install uninstall +.DEFAULT_GOAL := man diff --git a/Documentation/tools/rtla/common_appendix.rst b/Documentation/tools/rtla/common_appendix.rst new file mode 100644 index 000000000000..b494084acccd --- /dev/null +++ b/Documentation/tools/rtla/common_appendix.rst @@ -0,0 +1,12 @@ +REPORTING BUGS +============== +Report bugs to <lkml@vger.kernel.org> + +LICENSE +======= +**rtla** is Free Software licensed under the GNU GPLv2 + +COPYING +======= +Copyright \(C) 2021 Red Hat, Inc. Free use of this software is granted under +the terms of the GNU Public License (GPL). diff --git a/Documentation/tools/rtla/common_hist_options.rst b/Documentation/tools/rtla/common_hist_options.rst new file mode 100644 index 000000000000..0266cd08a6c9 --- /dev/null +++ b/Documentation/tools/rtla/common_hist_options.rst @@ -0,0 +1,23 @@ +**-b**, **--bucket-size** *N* + + Set the histogram bucket size (default *1*). + +**-e**, **--entries** *N* + + Set the number of entries of the histogram (default 256). + +**--no-header** + + Do not print header. + +**--no-summary** + + Do not print summary. + +**--no-index** + + Do not print index. + +**--with-zeros** + + Print zero only entries. diff --git a/Documentation/tools/rtla/common_options.rst b/Documentation/tools/rtla/common_options.rst new file mode 100644 index 000000000000..721790ad984e --- /dev/null +++ b/Documentation/tools/rtla/common_options.rst @@ -0,0 +1,28 @@ +**-c**, **--cpus** *cpu-list* + + Set the osnoise tracer to run the sample threads in the cpu-list. + +**-d**, **--duration** *time[s|m|h|d]* + + Set the duration of the session. + +**-D**, **--debug** + + Print debug info. + +**-t**, **--trace**\[*=file*] + + Save the stopped trace to [*file|osnoise_trace.txt*]. + +**-P**, **--priority** *o:prio|r:prio|f:prio|d:runtime:period* + + Set scheduling parameters to the osnoise tracer threads, the format to set the priority are: + + - *o:prio* - use SCHED_OTHER with *prio*; + - *r:prio* - use SCHED_RR with *prio*; + - *f:prio* - use SCHED_FIFO with *prio*; + - *d:runtime[us|ms|s]:period[us|ms|s]* - use SCHED_DEADLINE with *runtime* and *period* in nanoseconds. + +**-h**, **--help** + + Print help menu. diff --git a/Documentation/tools/rtla/common_osnoise_description.rst b/Documentation/tools/rtla/common_osnoise_description.rst new file mode 100644 index 000000000000..8973c5df888f --- /dev/null +++ b/Documentation/tools/rtla/common_osnoise_description.rst @@ -0,0 +1,8 @@ +The **rtla osnoise** tool is an interface for the *osnoise* tracer. The +*osnoise* tracer dispatches a kernel thread per-cpu. These threads read the +time in a loop while with preemption, softirq and IRQs enabled, thus +allowing all the sources of operating systme noise during its execution. +The *osnoise*'s tracer threads take note of the delta between each time +read, along with an interference counter of all sources of interference. +At the end of each period, the *osnoise* tracer displays a summary of +the results. diff --git a/Documentation/tools/rtla/common_osnoise_options.rst b/Documentation/tools/rtla/common_osnoise_options.rst new file mode 100644 index 000000000000..d556883e4e26 --- /dev/null +++ b/Documentation/tools/rtla/common_osnoise_options.rst @@ -0,0 +1,17 @@ +**-p**, **--period** *us* + + Set the *osnoise* tracer period in microseconds. + +**-r**, **--runtime** *us* + + Set the *osnoise* tracer runtime in microseconds. + +**-s**, **--stop** *us* + + Stop the trace if a single sample is higher than the argument in microseconds. + If **-T** is set, it will also save the trace to the output. + +**-S**, **--stop-total** *us* + + Stop the trace if the total sample is higher than the argument in microseconds. + If **-T** is set, it will also save the trace to the output. diff --git a/Documentation/tools/rtla/common_timerlat_description.rst b/Documentation/tools/rtla/common_timerlat_description.rst new file mode 100644 index 000000000000..321201cb8597 --- /dev/null +++ b/Documentation/tools/rtla/common_timerlat_description.rst @@ -0,0 +1,10 @@ +The **rtla timerlat** tool is an interface for the *timerlat* tracer. The +*timerlat* tracer dispatches a kernel thread per-cpu. These threads +set a periodic timer to wake themselves up and go back to sleep. After +the wakeup, they collect and generate useful information for the +debugging of operating system timer latency. + +The *timerlat* tracer outputs information in two ways. It periodically +prints the timer latency at the timer *IRQ* handler and the *Thread* +handler. It also enable the trace of the most relevant information via +**osnoise:** tracepoints. diff --git a/Documentation/tools/rtla/common_timerlat_options.rst b/Documentation/tools/rtla/common_timerlat_options.rst new file mode 100644 index 000000000000..e9c1bfd55d48 --- /dev/null +++ b/Documentation/tools/rtla/common_timerlat_options.rst @@ -0,0 +1,16 @@ +**-p**, **--period** *us* + + Set the *timerlat* tracer period in microseconds. + +**-i**, **--irq** *us* + + Stop trace if the *IRQ* latency is higher than the argument in us. + +**-T**, **--thread** *us* + + Stop trace if the *Thread* latency is higher than the argument in us. + +**-s**, **--stack** *us* + + Save the stack trace at the *IRQ* if a *Thread* latency is higher than the + argument in us. diff --git a/Documentation/tools/rtla/common_top_options.rst b/Documentation/tools/rtla/common_top_options.rst new file mode 100644 index 000000000000..f48878938f84 --- /dev/null +++ b/Documentation/tools/rtla/common_top_options.rst @@ -0,0 +1,3 @@ +**-q**, **--quiet** + + Print only a summary at the end of the session. diff --git a/Documentation/tools/rtla/index.rst b/Documentation/tools/rtla/index.rst new file mode 100644 index 000000000000..840f0bf3e803 --- /dev/null +++ b/Documentation/tools/rtla/index.rst @@ -0,0 +1,26 @@ +.. SPDX-License-Identifier: GPL-2.0 + +================================ +The realtime Linux analysis tool +================================ + +RTLA provides a set of tools for the analysis of the kernel's realtime +behavior on specific hardware. + +.. toctree:: + :maxdepth: 1 + + rtla + rtla-osnoise + rtla-osnoise-hist + rtla-osnoise-top + rtla-timerlat + rtla-timerlat-hist + rtla-timerlat-top + +.. only:: subproject and html + + Indices + ======= + + * :ref:`genindex` diff --git a/Documentation/tools/rtla/rtla-osnoise-hist.rst b/Documentation/tools/rtla/rtla-osnoise-hist.rst new file mode 100644 index 000000000000..52298ddd8701 --- /dev/null +++ b/Documentation/tools/rtla/rtla-osnoise-hist.rst @@ -0,0 +1,66 @@ +=================== +rtla-osnoise-hist +=================== +------------------------------------------------------ +Display a histogram of the osnoise tracer samples +------------------------------------------------------ + +:Manual section: 1 + +SYNOPSIS +======== +**rtla osnoise hist** [*OPTIONS*] + +DESCRIPTION +=========== +.. include:: common_osnoise_description.rst + +The **rtla osnoise hist** tool collects all **osnoise:sample_threshold** +occurrence in a histogram, displaying the results in a user-friendly way. +The tool also allows many configurations of the *osnoise* tracer and the +collection of the tracer output. + +OPTIONS +======= +.. include:: common_osnoise_options.rst + +.. include:: common_hist_options.rst + +.. include:: common_options.rst + +EXAMPLE +======= +In the example below, *osnoise* tracer threads are set to run with real-time +priority *FIFO:1*, on CPUs *0-11*, for *900ms* at each period (*1s* by +default). The reason for reducing the runtime is to avoid starving the +**rtla** tool. The tool is also set to run for *one minute*. The output +histogram is set to group outputs in buckets of *10us* and *25* entries:: + + [root@f34 ~/]# rtla osnoise hist -P F:1 -c 0-11 -r 900000 -d 1M -b 10 -e 25 + # RTLA osnoise histogram + # Time unit is microseconds (us) + # Duration: 0 00:01:00 + Index CPU-000 CPU-001 CPU-002 CPU-003 CPU-004 CPU-005 CPU-006 CPU-007 CPU-008 CPU-009 CPU-010 CPU-011 + 0 42982 46287 51779 53740 52024 44817 49898 36500 50408 50128 49523 52377 + 10 12224 8356 2912 878 2667 10155 4573 18894 4214 4836 5708 2413 + 20 8 5 12 2 13 24 20 41 29 53 39 39 + 30 1 1 0 0 10 3 6 19 15 31 30 38 + 40 0 0 0 0 0 4 2 7 2 3 8 11 + 50 0 0 0 0 0 0 0 0 0 1 1 2 + over: 0 0 0 0 0 0 0 0 0 0 0 0 + count: 55215 54649 54703 54620 54714 55003 54499 55461 54668 55052 55309 54880 + min: 0 0 0 0 0 0 0 0 0 0 0 0 + avg: 0 0 0 0 0 0 0 0 0 0 0 0 + max: 30 30 20 20 30 40 40 40 40 50 50 50 + +SEE ALSO +======== +**rtla-osnoise**\(1), **rtla-osnoise-top**\(1) + +*osnoise* tracer documentation: <https://www.kernel.org/doc/html/latest/trace/osnoise-tracer.html> + +AUTHOR +====== +Written by Daniel Bristot de Oliveira <bristot@kernel.org> + +.. include:: common_appendix.rst diff --git a/Documentation/tools/rtla/rtla-osnoise-top.rst b/Documentation/tools/rtla/rtla-osnoise-top.rst new file mode 100644 index 000000000000..5d75d1394516 --- /dev/null +++ b/Documentation/tools/rtla/rtla-osnoise-top.rst @@ -0,0 +1,61 @@ +=================== +rtla-osnoise-top +=================== +----------------------------------------------- +Display a summary of the operating system noise +----------------------------------------------- + +:Manual section: 1 + +SYNOPSIS +======== +**rtla osnoise top** [*OPTIONS*] + +DESCRIPTION +=========== +.. include:: common_osnoise_description.rst + +**rtla osnoise top** collects the periodic summary from the *osnoise* tracer, +including the counters of the occurrence of the interference source, +displaying the results in a user-friendly format. + +The tool also allows many configurations of the *osnoise* tracer and the +collection of the tracer output. + +OPTIONS +======= +.. include:: common_osnoise_options.rst + +.. include:: common_top_options.rst + +.. include:: common_options.rst + +EXAMPLE +======= +In the example below, the **rtla osnoise top** tool is set to run with a +real-time priority *FIFO:1*, on CPUs *0-3*, for *900ms* at each period +(*1s* by default). The reason for reducing the runtime is to avoid starving +the rtla tool. The tool is also set to run for *one minute* and to display +a summary of the report at the end of the session:: + + [root@f34 ~]# rtla osnoise top -P F:1 -c 0-3 -r 900000 -d 1M -q + Operating System Noise + duration: 0 00:01:00 | time is in us + CPU Period Runtime Noise % CPU Aval Max Noise Max Single HW NMI IRQ Softirq Thread + 0 #59 53100000 304896 99.42580 6978 56 549 0 53111 1590 13 + 1 #59 53100000 338339 99.36282 8092 24 399 0 53130 1448 31 + 2 #59 53100000 290842 99.45227 6582 39 855 0 53110 1406 12 + 3 #59 53100000 204935 99.61405 6251 33 290 0 53156 1460 12 + +SEE ALSO +======== + +**rtla-osnoise**\(1), **rtla-osnoise-hist**\(1) + +Osnoise tracer documentation: <https://www.kernel.org/doc/html/latest/trace/osnoise-tracer.html> + +AUTHOR +====== +Written by Daniel Bristot de Oliveira <bristot@kernel.org> + +.. include:: common_appendix.rst diff --git a/Documentation/tools/rtla/rtla-osnoise.rst b/Documentation/tools/rtla/rtla-osnoise.rst new file mode 100644 index 000000000000..c129b206ce34 --- /dev/null +++ b/Documentation/tools/rtla/rtla-osnoise.rst @@ -0,0 +1,59 @@ +=============== +rtla-osnoise +=============== +------------------------------------------------------------------ +Measure the operating system noise +------------------------------------------------------------------ + +:Manual section: 1 + +SYNOPSIS +======== +**rtla osnoise** [*MODE*] ... + +DESCRIPTION +=========== + +.. include:: common_osnoise_description.rst + +The *osnoise* tracer outputs information in two ways. It periodically prints +a summary of the noise of the operating system, including the counters of +the occurrence of the source of interference. It also provides information +for each noise via the **osnoise:** tracepoints. The **rtla osnoise top** +mode displays information about the periodic summary from the *osnoise* tracer. +The **rtla osnoise hist** mode displays information about the noise using +the **osnoise:** tracepoints. For further details, please refer to the +respective man page. + +MODES +===== +**top** + + Prints the summary from osnoise tracer. + +**hist** + + Prints a histogram of osnoise samples. + +If no MODE is given, the top mode is called, passing the arguments. + +OPTIONS +======= + +**-h**, **--help** + + Display the help text. + +For other options, see the man page for the corresponding mode. + +SEE ALSO +======== +**rtla-osnoise-top**\(1), **rtla-osnoise-hist**\(1) + +Osnoise tracer documentation: <https://www.kernel.org/doc/html/latest/trace/osnoise-tracer.html> + +AUTHOR +====== +Written by Daniel Bristot de Oliveira <bristot@kernel.org> + +.. include:: common_appendix.rst diff --git a/Documentation/tools/rtla/rtla-timerlat-hist.rst b/Documentation/tools/rtla/rtla-timerlat-hist.rst new file mode 100644 index 000000000000..e12eae1f3301 --- /dev/null +++ b/Documentation/tools/rtla/rtla-timerlat-hist.rst @@ -0,0 +1,106 @@ +===================== +rtla-timerlat-hist +===================== +------------------------------------------------ +Histograms of the operating system timer latency +------------------------------------------------ + +:Manual section: 1 + +SYNOPSIS +======== +**rtla timerlat hist** [*OPTIONS*] ... + +DESCRIPTION +=========== + +.. include:: common_timerlat_description.rst + +The **rtla timerlat hist** displays a histogram of each tracer event +occurrence. This tool uses the periodic information, and the +**osnoise:** tracepoints are enabled when using the **-T** option. + +OPTIONS +======= + +.. include:: common_timerlat_options.rst + +.. include:: common_hist_options.rst + +.. include:: common_options.rst + +EXAMPLE +======= +In the example below, **rtla timerlat hist** is set to run for *10* minutes, +in the cpus *0-4*, *skipping zero* only lines. Moreover, **rtla timerlat +hist** will change the priority of the *timelat* threads to run under +*SCHED_DEADLINE* priority, with a *10us* runtime every *1ms* period. The +*1ms* period is also passed to the *timerlat* tracer:: + + [root@alien ~]# timerlat hist -d 10m -c 0-4 -P d:100us:1ms -p 1ms + # RTLA timerlat histogram + # Time unit is microseconds (us) + # Duration: 0 00:10:00 + Index IRQ-000 Thr-000 IRQ-001 Thr-001 IRQ-002 Thr-002 IRQ-003 Thr-003 IRQ-004 Thr-004 + 0 276489 0 206089 0 466018 0 481102 0 205546 0 + 1 318327 35487 388149 30024 94531 48382 83082 71078 388026 55730 + 2 3282 122584 4019 126527 28231 109012 23311 89309 4568 98739 + 3 940 11815 837 9863 6209 16227 6895 17196 910 9780 + 4 444 17287 424 11574 2097 38443 2169 36736 462 13476 + 5 206 43291 255 25581 1223 101908 1304 101137 236 28913 + 6 132 101501 96 64584 635 213774 757 215471 99 73453 + 7 74 169347 65 124758 350 57466 441 53639 69 148573 + 8 53 85183 31 156751 229 9052 306 9026 39 139907 + 9 22 10387 12 42762 161 2554 225 2689 19 26192 + 10 13 1898 8 5770 114 1247 128 1405 13 3772 + 11 9 560 9 924 71 686 76 765 8 713 + 12 4 256 2 360 50 411 64 474 3 278 + 13 2 167 2 172 43 256 53 350 4 180 + 14 1 88 1 116 15 198 42 223 0 115 + 15 2 63 3 94 11 139 20 150 0 58 + 16 2 37 0 56 5 78 10 102 0 39 + 17 0 18 0 28 4 57 8 80 0 15 + 18 0 8 0 17 2 50 6 56 0 12 + 19 0 9 0 5 0 19 0 48 0 18 + 20 0 4 0 8 0 11 2 27 0 4 + 21 0 2 0 3 1 9 1 18 0 6 + 22 0 1 0 3 1 7 0 3 0 5 + 23 0 2 0 4 0 2 0 7 0 2 + 24 0 2 0 2 1 3 0 3 0 5 + 25 0 0 0 1 0 1 0 1 0 3 + 26 0 1 0 0 0 2 0 2 0 0 + 27 0 0 0 3 0 1 0 0 0 1 + 28 0 0 0 3 0 0 0 1 0 0 + 29 0 0 0 2 0 2 0 1 0 3 + 30 0 1 0 0 0 0 0 0 0 0 + 31 0 1 0 0 0 0 0 2 0 2 + 32 0 0 0 1 0 2 0 0 0 0 + 33 0 0 0 2 0 0 0 0 0 1 + 34 0 0 0 0 0 0 0 0 0 2 + 35 0 1 0 1 0 0 0 0 0 1 + 36 0 1 0 0 0 1 0 1 0 0 + 37 0 0 0 1 0 0 0 0 0 0 + 40 0 0 0 0 0 1 0 1 0 0 + 41 0 0 0 0 0 0 0 0 0 1 + 42 0 0 0 0 0 0 0 0 0 1 + 44 0 0 0 0 0 1 0 0 0 0 + 46 0 0 0 0 0 0 0 1 0 0 + 47 0 0 0 0 0 0 0 0 0 1 + 50 0 0 0 0 0 0 0 0 0 1 + 54 0 0 0 1 0 0 0 0 0 0 + 58 0 0 0 1 0 0 0 0 0 0 + over: 0 0 0 0 0 0 0 0 0 0 + count: 600002 600002 600002 600002 600002 600002 600002 600002 600002 600002 + min: 0 1 0 1 0 1 0 1 0 1 + avg: 0 5 0 5 0 4 0 4 0 5 + max: 16 36 15 58 24 44 21 46 13 50 + +SEE ALSO +======== +**rtla-timerlat**\(1), **rtla-timerlat-top**\(1) + +*timerlat* tracer documentation: <https://www.kernel.org/doc/html/latest/trace/timerlat-tracer.html> + +AUTHOR +====== +Written by Daniel Bristot de Oliveira <bristot@kernel.org> diff --git a/Documentation/tools/rtla/rtla-timerlat-top.rst b/Documentation/tools/rtla/rtla-timerlat-top.rst new file mode 100644 index 000000000000..1c321de1c171 --- /dev/null +++ b/Documentation/tools/rtla/rtla-timerlat-top.rst @@ -0,0 +1,145 @@ +==================== +rtla-timerlat-top +==================== +------------------------------------------- +Measures the operating system timer latency +------------------------------------------- + +:Manual section: 1 + +SYNOPSIS +======== +**rtla timerlat top** [*OPTIONS*] ... + +DESCRIPTION +=========== + +.. include:: common_timerlat_description.rst + +The **rtla timerlat top** displays a summary of the periodic output +from the *timerlat* tracer. It also provides information for each +operating system noise via the **osnoise:** tracepoints that can be +seem with the option **-T**. + +OPTIONS +======= + +.. include:: common_timerlat_options.rst + +.. include:: common_top_options.rst + +.. include:: common_options.rst + +EXAMPLE +======= + +In the example below, the *timerlat* tracer is set to capture the stack trace at +the IRQ handler, printing it to the buffer if the *Thread* timer latency is +higher than *30 us*. It is also set to stop the session if a *Thread* timer +latency higher than *30 us* is hit. Finally, it is set to save the trace +buffer if the stop condition is hit:: + + [root@alien ~]# rtla timerlat top -s 30 -t 30 -T + Timer Latency + 0 00:00:59 | IRQ Timer Latency (us) | Thread Timer Latency (us) + CPU COUNT | cur min avg max | cur min avg max + 0 #58634 | 1 0 1 10 | 11 2 10 23 + 1 #58634 | 1 0 1 9 | 12 2 9 23 + 2 #58634 | 0 0 1 11 | 10 2 9 23 + 3 #58634 | 1 0 1 11 | 11 2 9 24 + 4 #58634 | 1 0 1 10 | 11 2 9 26 + 5 #58634 | 1 0 1 8 | 10 2 9 25 + 6 #58634 | 12 0 1 12 | 30 2 10 30 <--- CPU with spike + 7 #58634 | 1 0 1 9 | 11 2 9 23 + 8 #58633 | 1 0 1 9 | 11 2 9 26 + 9 #58633 | 1 0 1 9 | 10 2 9 26 + 10 #58633 | 1 0 1 13 | 11 2 9 28 + 11 #58633 | 1 0 1 13 | 12 2 9 24 + 12 #58633 | 1 0 1 8 | 10 2 9 23 + 13 #58633 | 1 0 1 10 | 10 2 9 22 + 14 #58633 | 1 0 1 18 | 12 2 9 27 + 15 #58633 | 1 0 1 10 | 11 2 9 28 + 16 #58633 | 0 0 1 11 | 7 2 9 26 + 17 #58633 | 1 0 1 13 | 10 2 9 24 + 18 #58633 | 1 0 1 9 | 13 2 9 22 + 19 #58633 | 1 0 1 10 | 11 2 9 23 + 20 #58633 | 1 0 1 12 | 11 2 9 28 + 21 #58633 | 1 0 1 14 | 11 2 9 24 + 22 #58633 | 1 0 1 8 | 11 2 9 22 + 23 #58633 | 1 0 1 10 | 11 2 9 27 + timerlat hit stop tracing + saving trace to timerlat_trace.txt + [root@alien bristot]# tail -60 timerlat_trace.txt + [...] + timerlat/5-79755 [005] ....... 426.271226: #58634 context thread timer_latency 10823 ns + sh-109404 [006] dnLh213 426.271247: #58634 context irq timer_latency 12505 ns + sh-109404 [006] dNLh313 426.271258: irq_noise: local_timer:236 start 426.271245463 duration 12553 ns + sh-109404 [006] d...313 426.271263: thread_noise: sh:109404 start 426.271245853 duration 4769 ns + timerlat/6-79756 [006] ....... 426.271264: #58634 context thread timer_latency 30328 ns + timerlat/6-79756 [006] ....1.. 426.271265: <stack trace> + => timerlat_irq + => __hrtimer_run_queues + => hrtimer_interrupt + => __sysvec_apic_timer_interrupt + => sysvec_apic_timer_interrupt + => asm_sysvec_apic_timer_interrupt + => _raw_spin_unlock_irqrestore <---- spinlock that disabled interrupt. + => try_to_wake_up + => autoremove_wake_function + => __wake_up_common + => __wake_up_common_lock + => ep_poll_callback + => __wake_up_common + => __wake_up_common_lock + => fsnotify_add_event + => inotify_handle_inode_event + => fsnotify + => __fsnotify_parent + => __fput + => task_work_run + => exit_to_user_mode_prepare + => syscall_exit_to_user_mode + => do_syscall_64 + => entry_SYSCALL_64_after_hwframe + => 0x7265000001378c + => 0x10000cea7 + => 0x25a00000204a + => 0x12e302d00000000 + => 0x19b51010901b6 + => 0x283ce00726500 + => 0x61ea308872 + => 0x00000fe3 + bash-109109 [007] d..h... 426.271265: #58634 context irq timer_latency 1211 ns + timerlat/6-79756 [006] ....... 426.271267: timerlat_main: stop tracing hit on cpu 6 + +In the trace, it is possible the notice that the *IRQ* timer latency was +already high, accounting *12505 ns*. The IRQ delay was caused by the +*bash-109109* process that disabled IRQs in the wake-up path +(*_try_to_wake_up()* function). The duration of the IRQ handler that woke +up the timerlat thread, informed with the **osnoise:irq_noise** event, was +also high and added more *12553 ns* to the Thread latency. Finally, the +**osnoise:thread_noise** added by the currently running thread (including +the scheduling overhead) added more *4769 ns*. Summing up these values, +the *Thread* timer latency accounted for *30328 ns*. + +The primary reason for this high value is the wake-up path that was hit +twice during this case: when the *bash-109109* was waking up a thread +and then when the *timerlat* thread was awakened. This information can +then be used as the starting point of a more fine-grained analysis. + +Note that **rtla timerlat** was dispatched without changing *timerlat* tracer +threads' priority. That is generally not needed because these threads hava +priority *FIFO:95* by default, which is a common priority used by real-time +kernel developers to analyze scheduling delays. + +SEE ALSO +-------- +**rtla-timerlat**\(1), **rtla-timerlat-hist**\(1) + +*timerlat* tracer documentation: <https://www.kernel.org/doc/html/latest/trace/timerlat-tracer.html> + +AUTHOR +------ +Written by Daniel Bristot de Oliveira <bristot@kernel.org> + +.. include:: common_appendix.rst diff --git a/Documentation/tools/rtla/rtla-timerlat.rst b/Documentation/tools/rtla/rtla-timerlat.rst new file mode 100644 index 000000000000..44a49e6f302b --- /dev/null +++ b/Documentation/tools/rtla/rtla-timerlat.rst @@ -0,0 +1,57 @@ +================ +rtla-timerlat +================ +------------------------------------------- +Measures the operating system timer latency +------------------------------------------- + +:Manual section: 1 + +SYNOPSIS +======== +**rtla timerlat** [*MODE*] ... + +DESCRIPTION +=========== + +.. include:: common_timerlat_description.rst + +The *timerlat* tracer outputs information in two ways. It periodically +prints the timer latency at the timer *IRQ* handler and the *Thread* handler. +It also provides information for each noise via the **osnoise:** tracepoints. +The **rtla timerlat top** mode displays a summary of the periodic output +from the *timerlat* tracer. The **rtla hist hist** mode displays a histogram +of each tracer event occurrence. For further details, please refer to the +respective man page. + +MODES +===== +**top** + + Prints the summary from *timerlat* tracer. + +**hist** + + Prints a histogram of timerlat samples. + +If no *MODE* is given, the top mode is called, passing the arguments. + +OPTIONS +======= +**-h**, **--help** + + Display the help text. + +For other options, see the man page for the corresponding mode. + +SEE ALSO +======== +**rtla-timerlat-top**\(1), **rtla-timerlat-hist**\(1) + +*timerlat* tracer documentation: <https://www.kernel.org/doc/html/latest/trace/timerlat-tracer.html> + +AUTHOR +====== +Written by Daniel Bristot de Oliveira <bristot@kernel.org> + +.. include:: common_appendix.rst diff --git a/Documentation/tools/rtla/rtla.rst b/Documentation/tools/rtla/rtla.rst new file mode 100644 index 000000000000..fc0d233efcd5 --- /dev/null +++ b/Documentation/tools/rtla/rtla.rst @@ -0,0 +1,48 @@ +========= +rtla +========= +-------------------------------- +Real-time Linux Analysis tool +-------------------------------- + +:Manual section: 1 + +SYNOPSIS +======== +**rtla** *COMMAND* [*OPTIONS*] + +DESCRIPTION +=========== +The **rtla** is a meta-tool that includes a set of commands that aims to +analyze the real-time properties of Linux. But instead of testing Linux +as a black box, **rtla** leverages kernel tracing capabilities to provide +precise information about the properties and root causes of unexpected +results. + +COMMANDS +======== +**osnoise** + + Gives information about the operating system noise (osnoise). + +**timerlat** + + Measures the IRQ and thread timer latency. + +OPTIONS +======= +**-h**, **--help** + + Display the help text. + +For other options, see the man page for the corresponding command. + +SEE ALSO +======== +**rtla-osnoise**\(1), **rtla-timerlat**\(1) + +AUTHOR +====== +Daniel Bristot de Oliveira <bristot@kernel.org> + +.. include:: common_appendix.rst diff --git a/Documentation/trace/boottime-trace.rst b/Documentation/trace/boottime-trace.rst index 6dcfbc64014d..d594597201fd 100644 --- a/Documentation/trace/boottime-trace.rst +++ b/Documentation/trace/boottime-trace.rst @@ -131,9 +131,7 @@ Ftrace Histogram Options Since it is too long to write a histogram action as a string for per-event action option, there are tree-style options under per-event 'hist' subkey for the histogram actions. For the detail of the each parameter, -please read the event histogram document [3]_. - -.. [3] See :ref:`Documentation/trace/histogram.rst <histogram>` +please read the event histogram document (Documentation/trace/histogram.rst) ftrace.[instance.INSTANCE.]event.GROUP.EVENT.hist.[N.]keys = KEY1[, KEY2[...]] Set histogram key parameters. (Mandatory) diff --git a/Documentation/trace/coresight/coresight-config.rst b/Documentation/trace/coresight/coresight-config.rst index a4e3ef295240..6d5ffa6f7347 100644 --- a/Documentation/trace/coresight/coresight-config.rst +++ b/Documentation/trace/coresight/coresight-config.rst @@ -155,14 +155,14 @@ follows:: autofdo $ cd autofdo/ $ ls - description preset1 preset3 preset5 preset7 preset9 - feature_refs preset2 preset4 preset6 preset8 + description feature_refs preset1 preset3 preset5 preset7 preset9 + enable preset preset2 preset4 preset6 preset8 $ cat description Setup ETMs with strobing for autofdo $ cat feature_refs strobing -Each preset declared has a preset<n> subdirectory declared. The values for +Each preset declared has a 'preset<n>' subdirectory declared. The values for the preset can be examined:: $ cat preset1/values @@ -170,6 +170,9 @@ the preset can be examined:: $ cat preset2/values strobing.window = 0x1388 strobing.period = 0x4 +The 'enable' and 'preset' files allow the control of a configuration when +using CoreSight with sysfs. + The features referenced by the configuration can be examined in the features directory:: @@ -211,19 +214,13 @@ also declared in the perf 'cs_etm' event infrastructure so that they can be selected when running trace under perf:: $ ls /sys/devices/cs_etm - configurations format perf_event_mux_interval_ms sinks type - events nr_addr_filters power - -Key directories here are 'configurations' - which lists the loaded -configurations, and 'events' - a generic perf directory which allows -selection on the perf command line.:: + cpu0 cpu2 events nr_addr_filters power subsystem uevent + cpu1 cpu3 format perf_event_mux_interval_ms sinks type - $ ls configurations/ - autofdo - $ cat configurations/autofdo - 0xa7c3dddd +The key directory here is 'events' - a generic perf directory which allows +selection on the perf command line. As with the sinks entries, this provides +a hash of the configuration name. -As with the sinks entries, this provides a hash of the configuration name. The entry in the 'events' directory uses perfs built in syntax generator to substitute the syntax for the name when evaluating the command:: @@ -242,3 +239,56 @@ A preset to override the current parameter values can also be selected:: When configurations are selected in this way, then the trace sink used is automatically selected. + +Using Configurations in sysfs +============================= + +Coresight can be controlled using sysfs. When this is in use then a configuration +can be made active for the devices that are used in the sysfs session. + +In a configuration there are 'enable' and 'preset' files. + +To enable a configuration for use with sysfs:: + + $ cd configurations/autofdo + $ echo 1 > enable + +This will then use any default parameter values in the features - which can be +adjusted as described above. + +To use a preset<n> set of parameter values:: + + $ echo 3 > preset + +This will select preset3 for the configuration. +The valid values for preset are 0 - to deselect presets, and any value of +<n> where a preset<n> sub-directory is present. + +Note that the active sysfs configuration is a global parameter, therefore +only a single configuration can be active for sysfs at any one time. +Attempting to enable a second configuration will result in an error. +Additionally, attempting to disable the configuration while in use will +also result in an error. + +The use of the active configuration by sysfs is independent of the configuration +used in perf. + + +Creating and Loading Custom Configurations +========================================== + +Custom configurations and / or features can be dynamically loaded into the +system by using a loadable module. + +An example of a custom configuration is found in ./samples/coresight. + +This creates a new configuration that uses the existing built in +strobing feature, but provides a different set of presets. + +When the module is loaded, then the configuration appears in the configfs +file system and is selectable in the same way as the built in configuration +described above. + +Configurations can use previously loaded features. The system will ensure +that it is not possible to unload a feature that is currently in use, by +enforcing the unload order as the strict reverse of the load order. diff --git a/Documentation/trace/events.rst b/Documentation/trace/events.rst index 8ddb9b09451c..c47f381d0c00 100644 --- a/Documentation/trace/events.rst +++ b/Documentation/trace/events.rst @@ -198,6 +198,15 @@ The glob (~) accepts a wild card character (\*,?) and character classes prev_comm ~ "*sh*" prev_comm ~ "ba*sh" +If the field is a pointer that points into user space (for example +"filename" from sys_enter_openat), then you have to append ".ustring" to the +field name:: + + filename.ustring ~ "password" + +As the kernel will have to know how to retrieve the memory that the pointer +is at from user space. + 5.2 Setting filters ------------------- @@ -230,6 +239,16 @@ Currently the caret ('^') for an error always appears at the beginning of the filter string; the error message should still be useful though even without more accurate position info. +5.2.1 Filter limitations +------------------------ + +If a filter is placed on a string pointer ``(char *)`` that does not point +to a string on the ring buffer, but instead points to kernel or user space +memory, then, for safety reasons, at most 1024 bytes of the content is +copied onto a temporary buffer to do the compare. If the copy of the memory +faults (the pointer points to memory that should not be accessed), then the +string compare will be treated as not matching. + 5.3 Clearing filters -------------------- diff --git a/Documentation/trace/ftrace.rst b/Documentation/trace/ftrace.rst index b3166c4a7867..45b8c56af67a 100644 --- a/Documentation/trace/ftrace.rst +++ b/Documentation/trace/ftrace.rst @@ -3370,7 +3370,7 @@ one of the latency tracers, you will get the following results. Instances --------- -In the tracefs tracing directory is a directory called "instances". +In the tracefs tracing directory, there is a directory called "instances". This directory can have new directories created inside of it using mkdir, and removing directories with rmdir. The directory created with mkdir in this directory will already contain files and other diff --git a/Documentation/translations/it_IT/process/submitting-patches.rst b/Documentation/translations/it_IT/process/submitting-patches.rst index c2fb712a1377..4fb5b3aa306d 100644 --- a/Documentation/translations/it_IT/process/submitting-patches.rst +++ b/Documentation/translations/it_IT/process/submitting-patches.rst @@ -276,25 +276,6 @@ cosicché l'informazione possa trovare la sua strada nel manuale. Le modifiche all'API dello spazio utente dovrebbero essere inviate in copia anche a linux-api@vger.kernel.org. -Per le piccole patch potreste aggiungere in CC l'indirizzo -*Trivial Patch Monkey trivial@kernel.org* che ha lo scopo di raccogliere -le patch "banali". Date uno sguardo al file MAINTAINERS per vedere chi -è l'attuale amministratore. - -Le patch banali devono rientrare in una delle seguenti categorie: - -- errori grammaticali nella documentazione -- errori grammaticali negli errori che potrebbero rompere :manpage:`grep(1)` -- correzione di avvisi di compilazione (riempirsi di avvisi inutili è negativo) -- correzione di errori di compilazione (solo se correggono qualcosa sul serio) -- rimozione di funzioni/macro deprecate -- sostituzione di codice non potabile con uno portabile (anche in codice - specifico per un'architettura, dato che le persone copiano, fintanto che - la modifica sia banale) -- qualsiasi modifica dell'autore/manutentore di un file (in pratica - "patch monkey" in modalità ritrasmissione) - - Niente: MIME, links, compressione, allegati. Solo puro testo ------------------------------------------------------------- diff --git a/Documentation/translations/ja_JP/SubmittingPatches b/Documentation/translations/ja_JP/SubmittingPatches index 6854f5add72e..0d308edef781 100644 --- a/Documentation/translations/ja_JP/SubmittingPatches +++ b/Documentation/translations/ja_JP/SubmittingPatches @@ -208,21 +208,6 @@ VGER.KERNEL.ORG でホスティングされているメーリングリストの たとえ、メンテナが #5 で反応がなかったとしても、メンテナのコードに変更を 加えたときには、いつもメンテナに CC するのを忘れないようにしてください。 -小さなパッチであれば、Trivial Patch Monkey(ちょっとしたパッチを集めている) -<trivial@kernel.org>に CC してもいいです。その現管理者については MAINTAINERS -ファイルを見てください。ちょっとしたパッチとは以下のルールのどれか1つを満たして -いなければなりません。 - ・ドキュメントのスペルミスの修正 - ・grep(1) コマンドによる検索を困難にしているスペルの修正 - ・コンパイル時の警告の修正(無駄な警告が散乱することは好ましくないた - めです) - ・コンパイル問題の修正(それらの修正が本当に正しい場合に限る) - ・実行時の問題の修正(それらの修正が本当に問題を修正している場合に限る) - ・廃止予定の関数やマクロを使用しているコードの除去(例 check_region ) - ・問い合わせ先やドキュメントの修正 - ・移植性のないコードから移植性のあるコードへの置き換え(小さい範囲で - あればアーキテクチャ特有のことでも他の人がコピーできます) - ・作者やメンテナによる修正(すなわち patch monkey の再転送モード) 7) MIME やリンクや圧縮ファイルや添付ファイルではなくプレインテキストのみ diff --git a/Documentation/translations/zh_CN/PCI/index.rst b/Documentation/translations/zh_CN/PCI/index.rst index 5c96017e9f41..16acb2bd9b58 100644 --- a/Documentation/translations/zh_CN/PCI/index.rst +++ b/Documentation/translations/zh_CN/PCI/index.rst @@ -22,13 +22,14 @@ Linux PCI总线子系统 :numbered: pci - -Todolist: - pciebus-howto pci-iov-howto msi-howto sysfs-pci + + +Todolist: + acpi-info pci-error-recovery pcieaer-howto diff --git a/Documentation/translations/zh_CN/PCI/msi-howto.rst b/Documentation/translations/zh_CN/PCI/msi-howto.rst new file mode 100644 index 000000000000..7ea4d50cdad2 --- /dev/null +++ b/Documentation/translations/zh_CN/PCI/msi-howto.rst @@ -0,0 +1,233 @@ +.. SPDX-License-Identifier: GPL-2.0 +.. include:: <isonum.txt> +.. include:: ../disclaimer-zh_CN.rst + +:Original: Documentation/PCI/msi-howto.rst + +:翻译: + + 司延腾 Yanteng Si <siyanteng@loongson.cn> + +:校译: + + + +=========== +MSI驱动指南 +=========== + +:作者: Tom L Nguyen; Martine Silbermann; Matthew Wilcox + +:版权: 2003, 2008 Intel Corporation + +关于本指南 +========== + +本指南介绍了消息标记中断（MSI）的基本知识，使用MSI相对于传统中断机制的优势，如何 +改变你的驱动程序以使用MSI或MSI-X，以及在设备不支持MSI时可以尝试的一些基本诊断方法。 + + +什么是MSI? +========== + +信息信号中断是指从设备写到一个特殊的地址，导致CPU接收到一个中断。 + +MSI能力首次在PCI 2.2中规定，后来在PCI 3.0中得到增强，允许对每个中断进行单独屏蔽。 +MSI-X功能也随着PCI 3.0被引入。它比MSI支持每个设备更多的中断，并允许独立配置中断。 + +设备可以同时支持MSI和MSI-X，但一次只能启用一个。 + + +为什么用MSI? +============ + +有三个原因可以说明为什么使用MSI比传统的基于针脚的中断有优势。 + +基于针脚的PCI中断通常在几个设备之间共享。为了支持这一点，内核必须调用每个与中断相 +关的中断处理程序，这导致了整个系统性能的降低。MSI从不共享，所以这个问题不会出现。 + +当一个设备将数据写入内存，然后引发一个基于引脚的中断时，有可能在所有的数据到达内存 +之前，中断就已经到达了（这在PCI-PCI桥后面的设备中变得更有可能）。为了确保所有的数 +据已经到达内存中，中断处理程序必须在引发中断的设备上读取一个寄存器。PCI事务排序规 +则要求所有的数据在返回寄存器的值之前到达内存。使用MSI可以避免这个问题，因为中断产 +生的写入不能通过数据写入，所以当中断发生时，驱动程序知道所有的数据已经到达内存中。 + +PCI设备每个功能只能支持一个基于引脚的中断。通常情况下，驱动程序必须查询设备以找出 +发生了什么事件，这就减慢了对常见情况的中断处理。有了MSI，设备可以支持更多的中断， +允许每个中断被专门用于不同的目的。一种可能的设计是给不经常发生的情况（如错误）提供 +自己的中断，这使得驱动程序可以更有效地处理正常的中断处理路径。其他可能的设计包括给 +网卡的每个数据包队列或存储控制器的每个端口提供一个中断。 + + +如何使用MSI +=========== + +PCI设备被初始化为使用基于引脚的中断。设备驱动程序必须将设备设置为使用MSI或MSI-X。 +并非所有的机器都能正确地支持MSI，对于这些机器，下面描述的API将简单地失败，设备将 +继续使用基于引脚的中断。 + +加入内核对MSI的支持 +------------------- + +为了支持MSI或MSI-X，内核在构建时必须启用CONFIG_PCI_MSI选项。这个选项只在某些架 +构上可用，而且它可能取决于其他一些选项的设置。例如，在x86上，你必须同时启用X86_UP_APIC +或SMP，才能看到CONFIG_PCI_MSI选项。 + +使用MSI +------- + +大部分沉重的工作是在PCI层为驱动程序完成的。驱动程序只需要请求PCI层为这个设备设置 +MSI功能。 + +要自动使用MSI或MSI-X中断向量，请使用以下函数:: + + int pci_alloc_irq_vectors(struct pci_dev *dev, unsigned int min_vecs, + unsigned int max_vecs, unsigned int flags); + +它为一个PCI设备分配最多至max_vecs的中断向量。它返回分配的向量数量或一个负的错误。 +如果设备对最小数量的向量有要求，驱动程序可以传递一个min_vecs参数，设置为这个限制， +如果PCI核不能满足最小数量的向量，将返回-ENOSPC。 + +flags参数用来指定设备和驱动程序可以使用哪种类型的中断（PCI_IRQ_LEGACY, PCI_IRQ_MSI, +PCI_IRQ_MSIX）。一个方便的短语（PCI_IRQ_ALL_TYPES）也可以用来要求任何可能的中断类型。 +如果PCI_IRQ_AFFINITY标志被设置，pci_alloc_irq_vectors()将把中断分散到可用的CPU上。 + +要获得传递给require_irq()和free_irq()的Linux IRQ号码和向量，请使用以下函数:: + + int pci_irq_vector(struct pci_dev *dev, unsigned int nr); + +在删除设备之前，应使用以下功能释放任何已分配的资源:: + + void pci_free_irq_vectors(struct pci_dev *dev); + +如果一个设备同时支持MSI-X和MSI功能，这个API将优先使用MSI-X，而不是MSI。MSI-X支 +持1到2048之间的任何数量的中断。相比之下，MSI被限制为最多32个中断（而且必须是2的幂）。 +此外，MSI中断向量必须连续分配，所以系统可能无法为MSI分配像MSI-X那样多的向量。在一 +些平台上，MSI中断必须全部针对同一组CPU，而MSI-X中断可以全部针对不同的CPU。 + +如果一个设备既不支持MSI-X，也不支持MSI，它就会退回到一个传统的IRQ向量。 + +MSI或MSI-X中断的典型用法是分配尽可能多的向量，可能达到设备支持的极限。如果nvec大于 +设备支持的数量，它将自动被限制在支持的限度内，所以没有必要事先查询支持的向量的数量。:: + + nvec = pci_alloc_irq_vectors(pdev, 1, nvec, PCI_IRQ_ALL_TYPES) + if (nvec < 0) + goto out_err; + +如果一个驱动程序不能或不愿意处理可变数量的MSI中断，它可以要求一个特定数量的中断，将该 +数量作为“min_vecs“和“max_vecs“参数传递给pci_alloc_irq_vectors()函数。:: + + ret = pci_alloc_irq_vectors(pdev, nvec, nvec, PCI_IRQ_ALL_TYPES); + if (ret < 0) + goto out_err; + +上述请求类型的最臭名昭著的例子是为一个设备启用单一的MSI模式。它可以通过传递两个1作为 +'min_vecs'和'max_vecs'来实现:: + + ret = pci_alloc_irq_vectors(pdev, 1, 1, PCI_IRQ_ALL_TYPES); + if (ret < 0) + goto out_err; + +一些设备可能不支持使用传统的线路中断，在这种情况下，驱动程序可以指定只接受MSI或MSI-X。:: + + nvec = pci_alloc_irq_vectors(pdev, 1, nvec, PCI_IRQ_MSI | PCI_IRQ_MSIX); + if (nvec < 0) + goto out_err; + +传统API +----------- + +以下用于启用和禁用MSI或MSI-X中断的旧API不应该在新代码中使用:: + + pci_enable_msi() /* deprecated */ + pci_disable_msi() /* deprecated */ + pci_enable_msix_range() /* deprecated */ + pci_enable_msix_exact() /* deprecated */ + pci_disable_msix() /* deprecated */ + +此外，还有一些API来提供支持的MSI或MSI-X向量的数量：pci_msi_vec_count()和 +pci_msix_vec_count()。一般来说，应该避免使用这些方法，而是让pci_alloc_irq_vectors() +来限制向量的数量。如果你对向量的数量有合法的特殊用例，我们可能要重新审视这个决定， +并增加一个pci_nr_irq_vectors()助手，透明地处理MSI和MSI-X。 + +使用MSI时需要考虑的因素 +----------------------- + +自旋锁 +~~~~~~ + +大多数设备驱动程序都有一个每的自旋锁，在中断处理程序中被占用。对于基于引脚的中断 +或单一的MSI，没有必要禁用中断（Linux保证同一中断不会被重新输入）。如果一个设备 +使用多个中断，驱动程序必须在锁被持有的时候禁用中断。如果设备发出一个不同的中断， +驱动程序将死锁，试图递归地获取自旋锁。这种死锁可以通过使用spin_lock_irqsave() +或spin_lock_irq()来避免，它们可以禁用本地中断并获取锁（见《不可靠的锁定指南》）。 + +如何判断一个设备上是否启用了MSI/MSI-X +------------------------------------- + +使用“lspci -v“（以root身份）可能会显示一些具有“MSI“、“Message Signalled Interrupts“ +或“MSI-X“功能的设备。这些功能中的每一个都有一个“启用“标志，后面是“+“（启用） +或“-“（禁用）。 + + +MSI特性 +======= + +众所周知，一些PCI芯片组或设备不支持MSI。PCI协议栈提供了三种禁用MSI的方法: + +1. 全局的 +2. 在一个特定的桥后面的所有设备上 +3. 在单一设备上 + +全局禁用MSI +----------- + +一些主控芯片组根本无法正确支持MSI。如果我们幸运的话，制造商知道这一点，并在 +ACPI FADT表中指明了它。在这种情况下，Linux会自动禁用MSI。有些板卡在表中没 +有包括这一信息，因此我们必须自己检测它们。完整的列表可以在drivers/pci/quirks.c +中的quirk_disable_all_msi()函数附近找到。 + +如果你有一块有MSI问题的板子，你可以在内核命令行中传递pci=nomsi来禁用所有设 +备上的MSI。你最好把问题报告给linux-pci@vger.kernel.org，包括完整的 +“lspci -v“，这样我们就可以把这些怪癖添加到内核中。 + +禁用桥下的MSI +------------- + +一些PCI桥接器不能在总线之间正确地路由MSI。在这种情况下，必须在桥接器后面的所 +有设备上禁用MSI。 + +一些桥接器允许你通过改变PCI配置空间的一些位来启用MSI（特别是Hypertransport +芯片组，如nVidia nForce和Serverworks HT2000）。与主机芯片组一样，Linux大 +多知道它们，如果可以的话，会自动启用MSI。如果你有一个Linux不知道的网桥，你可以 +用你知道的任何方法在配置空间中启用MSI，然后通过以下方式在该网桥上启用MSI:: + + echo 1 > /sys/bus/pci/devices/$bridge/msi_bus + +其中$bridge是你所启用的桥的PCI地址（例如0000:00:0e.0）。 + +要禁用MSI，请回显0而不是1。改变这个值应该谨慎进行，因为它可能会破坏这个桥下面所 +有设备的中断处理。 + +同样，请通知 linux-pci@vger.kernel.org 任何需要特殊处理的桥。 + +在单一设备上关闭MSIs +-------------------- + +众所周知，有些设备的MSI实现是有问题的。通常情况下，这是在单个设备驱动程序中处理的， +但偶尔也有必要用一个古怪的方法来处理。一些驱动程序有一个选项可以禁用MSI的使用。虽然 +这对驱动程序的作者来说是一个方便的变通办法，但这不是一个好的做法，不应该被模仿。 + +寻找设备上MSI被禁用的原因 +------------------------- + +从以上三个部分，你可以看到有许多原因导致MSI没有在某个设备上被启用。你的第一步应该是 +仔细检查你的dmesg以确定你的机器是否启用了MSI。你还应该检查你的.config以确定你已经 +启用了CONFIG_PCI_MSI。 + +然后，“lspci -t“给出一个设备上面的网列表。读取 ``/sys/bus/pci/devices/*/msi_bus`` +将告诉你MSI是否被启用（1）或禁用（0）。如果在任何属于PCI根和设备之间的桥的msi_bus +文件中发现0，说明MSI被禁用。 + +也需要检查设备驱动程序，看它是否支持MSI。例如，它可能包含对带有PCI_IRQ_MSI或 +PCI_IRQ_MSIX标志的pci_alloc_irq_vectors（）的调用。 diff --git a/Documentation/translations/zh_CN/PCI/pci-iov-howto.rst b/Documentation/translations/zh_CN/PCI/pci-iov-howto.rst new file mode 100644 index 000000000000..fbc83dfdcead --- /dev/null +++ b/Documentation/translations/zh_CN/PCI/pci-iov-howto.rst @@ -0,0 +1,170 @@ +.. SPDX-License-Identifier: GPL-2.0 +.. include:: <isonum.txt> +.. include:: ../disclaimer-zh_CN.rst + +:Original: Documentation/PCI/pci-iov-howto.rst + +:翻译: + + 司延腾 Yanteng Si <siyanteng@loongson.cn> + +:校译: + + + +.. _cn_pci-iov-howto: + +========================== +PCI Express I/O 虚拟化指南 +========================== + +:版权: |copy| 2009 Intel Corporation +:作者: - Yu Zhao <yu.zhao@intel.com> + - Donald Dutile <ddutile@redhat.com> + +概述 +==== + +什么是SR-IOV +------------ + +单根I/O虚拟化（SR-IOV）是一种PCI Express扩展功能，它使一个物理设备显示为多个 +虚拟设备。物理设备被称为物理功能（PF），而虚拟设备被称为虚拟功能（VF）。VF的分 +配可以由PF通过封装在该功能中的寄存器动态控制。默认情况下，该功能未被启用，PF表 +现为传统的PCIe设备。一旦开启，每个VF的PCI配置空间都可以通过自己的总线、设备和 +功能编号（路由ID）来访问。而且每个VF也有PCI内存空间，用于映射其寄存器集。VF设 +备驱动程序对寄存器集进行操作，这样它就可以发挥功能，并作为一个真正的现有PCI设备 +出现。 + +使用指南 +======== + +我怎样才能启用SR-IOV功能 +------------------------ + +有多种方法可用于SR-IOV的启用。在第一种方法中，设备驱动（PF驱动）将通过SR-IOV +核心提供的API控制功能的启用和禁用。如果硬件具有SR-IOV能力，加载其PF驱动器将启 +用它和与PF相关的所有VF。一些PF驱动需要设置一个模块参数，以确定要启用的VF的数量。 +在第二种方法中，对sysfs文件sriov_numvfs的写入将启用和禁用与PCIe PF相关的VF。 +这种方法实现了每个PF的VF启用/禁用值，而第一种方法则适用于同一设备的所有PF。此外， +PCI SRIOV核心支持确保启用/禁用操作是有效的，以减少同一检查在多个驱动程序中的重 +复，例如，如果启用VF，检查numvfs == 0，确保numvfs <= totalvfs。 +第二种方法是对新的/未来的VF设备的推荐方法。 + +我怎样才能使用虚拟功能 +---------------------- + +在内核中，VF被视为热插拔的PCI设备，所以它们应该能够以与真正的PCI设备相同的方式 +工作。VF需要的设备驱动与普通PCI设备的驱动相同。 + +开发者指南 +========== + +SR-IOV API +---------- + +用来开启SR-IOV功能: + +(a) 对于第一种方法，在驱动程序中:: + + int pci_enable_sriov(struct pci_dev *dev, int nr_virtfn); + +nr_virtfn'是要启用的VF的编号。 + +(b) 对于第二种方法，从sysfs:: + + echo 'nr_virtfn' > \ + /sys/bus/pci/devices/<DOMAIN:BUS:DEVICE.FUNCTION>/sriov_numvfs + +用来关闭SR-IOV功能: + +(a) 对于第一种方法，在驱动程序中:: + + void pci_disable_sriov(struct pci_dev *dev); + +(b) 对于第二种方法，从sysfs:: + + echo 0 > \ + /sys/bus/pci/devices/<DOMAIN:BUS:DEVICE.FUNCTION>/sriov_numvfs + +要想通过主机上的兼容驱动启用自动探测VF，在启用SR-IOV功能之前运行下面的命令。这 +是默认的行为。 +:: + + echo 1 > \ + /sys/bus/pci/devices/<DOMAIN:BUS:DEVICE.FUNCTION>/sriov_drivers_autoprobe + +要禁止主机上的兼容驱动自动探测VF，请在启用SR-IOV功能之前运行以下命令。更新这个 +入口不会影响已经被探测的VF。 +:: + + echo 0 > \ + /sys/bus/pci/devices/<DOMAIN:BUS:DEVICE.FUNCTION>/sriov_drivers_autoprobe + +用例 +---- + +下面的代码演示了SR-IOV API的用法 +:: + + static int dev_probe(struct pci_dev *dev, const struct pci_device_id *id) + { + pci_enable_sriov(dev, NR_VIRTFN); + + ... + + return 0; + } + + static void dev_remove(struct pci_dev *dev) + { + pci_disable_sriov(dev); + + ... + } + + static int dev_suspend(struct pci_dev *dev, pm_message_t state) + { + ... + + return 0; + } + + static int dev_resume(struct pci_dev *dev) + { + ... + + return 0; + } + + static void dev_shutdown(struct pci_dev *dev) + { + ... + } + + static int dev_sriov_configure(struct pci_dev *dev, int numvfs) + { + if (numvfs > 0) { + ... + pci_enable_sriov(dev, numvfs); + ... + return numvfs; + } + if (numvfs == 0) { + .... + pci_disable_sriov(dev); + ... + return 0; + } + } + + static struct pci_driver dev_driver = { + .name = "SR-IOV Physical Function driver", + .id_table = dev_id_table, + .probe = dev_probe, + .remove = dev_remove, + .suspend = dev_suspend, + .resume = dev_resume, + .shutdown = dev_shutdown, + .sriov_configure = dev_sriov_configure, + }; diff --git a/Documentation/translations/zh_CN/PCI/pciebus-howto.rst b/Documentation/translations/zh_CN/PCI/pciebus-howto.rst new file mode 100644 index 000000000000..65c4301f12cd --- /dev/null +++ b/Documentation/translations/zh_CN/PCI/pciebus-howto.rst @@ -0,0 +1,192 @@ +.. SPDX-License-Identifier: GPL-2.0 +.. include:: <isonum.txt> +.. include:: ../disclaimer-zh_CN.rst + +:Original: Documentation/PCI/pciebus-howto.rst + +:翻译: + + 司延腾 Yanteng Si <siyanteng@loongson.cn> + +:校译: + + + +.. _cn_pciebus-howto: + +=========================== +PCI Express端口总线驱动指南 +=========================== + +:作者: Tom L Nguyen tom.l.nguyen@intel.com 11/03/2004 +:版权: |copy| 2004 Intel Corporation + +关于本指南 +========== + +本指南介绍了PCI Express端口总线驱动程序的基本知识，并提供了如何使服务驱 +动程序在PCI Express端口总线驱动程序中注册/取消注册的介绍。 + + +什么是PCI Express端口总线驱动程序 +================================= + +一个PCI Express端口是一个逻辑的PCI-PCI桥结构。有两种类型的PCI Express端 +口：根端口和交换端口。根端口从PCI Express根综合体发起一个PCI Express链接， +交换端口将PCI Express链接连接到内部逻辑PCI总线。交换机端口，其二级总线代表 +交换机的内部路由逻辑，被称为交换机的上行端口。交换机的下行端口是从交换机的内部 +路由总线桥接到代表来自PCI Express交换机的下游PCI Express链接的总线。 + +一个PCI Express端口可以提供多达四个不同的功能，在本文中被称为服务，这取决于 +其端口类型。PCI Express端口的服务包括本地热拔插支持（HP）、电源管理事件支持（PME）、 +高级错误报告支持（AER）和虚拟通道支持（VC）。这些服务可以由一个复杂的驱动程序 +处理，也可以单独分布并由相应的服务驱动程序处理。 + +为什么要使用PCI Express端口总线驱动程序？ +========================================= + +在现有的Linux内核中，Linux设备驱动模型允许一个物理设备只由一个驱动处理。 +PCI Express端口是一个具有多个不同服务的PCI-PCI桥设备。为了保持一个干净和简 +单的解决方案，每个服务都可以有自己的软件服务驱动。在这种情况下，几个服务驱动将 +竞争一个PCI-PCI桥设备。例如，如果PCI Express根端口的本机热拔插服务驱动程序 +首先被加载，它就会要求一个PCI-PCI桥根端口。因此，内核不会为该根端口加载其他服 +务驱动。换句话说，使用当前的驱动模型，不可能让多个服务驱动同时加载并运行在 +PCI-PCI桥设备上。 + +为了使多个服务驱动程序同时运行，需要有一个PCI Express端口总线驱动程序，它管 +理所有填充的PCI Express端口，并根据需要将所有提供的服务请求分配给相应的服务 +驱动程序。下面列出了使用PCI Express端口总线驱动程序的一些关键优势: + + - 允许在一个PCI-PCI桥接端口设备上同时运行多个服务驱动。 + + - 允许以独立的分阶段方式实施服务驱动程序。 + + - 允许一个服务驱动程序在多个PCI-PCI桥接端口设备上运行。 + + - 管理和分配PCI-PCI桥接端口设备的资源给要求的服务驱动程序。 + +配置PCI Express端口总线驱动程序与服务驱动程序 +============================================= + +将PCI Express端口总线驱动支持纳入内核 +------------------------------------- + +包括PCI Express端口总线驱动程序取决于内核配置中是否包含PCI Express支持。当内核 +中的PCI Express支持被启用时，内核将自动包含PCI Express端口总线驱动程序作为内核 +驱动程序。 + +启用服务驱动支持 +---------------- + +PCI设备驱动是基于Linux设备驱动模型实现的。所有的服务驱动都是PCI设备驱动。如上所述， +一旦内核加载了PCI Express端口总线驱动程序，就不可能再加载任何服务驱动程序。为了满 +足PCI Express端口总线驱动程序模型，需要对现有的服务驱动程序进行一些最小的改变，其 +对现有的服务驱动程序的功能没有影响。 + +服务驱动程序需要使用下面所示的两个API，将其服务注册到PCI Express端口总线驱动程 +序中（见第5.2.1和5.2.2节）。在调用这些API之前，服务驱动程序必须初始化头文件 +/include/linux/pcieport_if.h中的pcie_port_service_driver数据结构。如果不这 +样做，将导致身份不匹配，从而使PCI Express端口总线驱动程序无法加载服务驱动程序。 + +pcie_port_service_register +~~~~~~~~~~~~~~~~~~~~~~~~~~ +:: + + int pcie_port_service_register(struct pcie_port_service_driver *new) + +这个API取代了Linux驱动模型的 pci_register_driver API。一个服务驱动应该总是在模 +块启动时调用 pcie_port_service_register。请注意，在服务驱动被加载后，诸如 +pci_enable_device(dev) 和 pci_set_master(dev) 的调用不再需要，因为这些调用由 +PCI端口总线驱动执行。 + +pcie_port_service_unregister +~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +:: + + void pcie_port_service_unregister(struct pcie_port_service_driver *new) + +pcie_port_service_unregister取代了Linux驱动模型的pci_unregister_driver。当一 +个模块退出时，它总是被服务驱动调用。 + +示例代码 +~~~~~~~~ + +下面是服务驱动代码示例，用于初始化端口服务的驱动程序数据结构。 +:: + + static struct pcie_port_service_id service_id[] = { { + .vendor = PCI_ANY_ID, + .device = PCI_ANY_ID, + .port_type = PCIE_RC_PORT, + .service_type = PCIE_PORT_SERVICE_AER, + }, { /* end: all zeroes */ } + }; + + static struct pcie_port_service_driver root_aerdrv = { + .name = (char *)device_name, + .id_table = &service_id[0], + + .probe = aerdrv_load, + .remove = aerdrv_unload, + + .suspend = aerdrv_suspend, + .resume = aerdrv_resume, + }; + +下面是一个注册/取消注册服务驱动的示例代码。 +:: + + static int __init aerdrv_service_init(void) + { + int retval = 0; + + retval = pcie_port_service_register(&root_aerdrv); + if (!retval) { + /* + * FIX ME + */ + } + return retval; + } + + static void __exit aerdrv_service_exit(void) + { + pcie_port_service_unregister(&root_aerdrv); + } + + module_init(aerdrv_service_init); + module_exit(aerdrv_service_exit); + +可能的资源冲突 +============== + +由于PCI-PCI桥接端口设备的所有服务驱动被允许同时运行，下面列出了一些可能的资源冲突和 +建议的解决方案。 + +MSI 和 MSI-X 向量资源 +--------------------- + +一旦设备上的MSI或MSI-X中断被启用，它就会一直保持这种模式，直到它们再次被禁用。由于同 +一个PCI-PCI桥接端口的服务驱动程序共享同一个物理设备，如果一个单独的服务驱动程序启用或 +禁用MSI/MSI-X模式，可能会导致不可预知的行为。 + +为了避免这种情况，所有的服务驱动程序都不允许在其设备上切换中断模式。PCI Express端口 +总线驱动程序负责确定中断模式，这对服务驱动程序来说应该是透明的。服务驱动程序只需要知道 +分配给结构体pcie_device的字段irq的向量IRQ，当PCI Express端口总线驱动程序探测每 +个服务驱动程序时，它被传入。服务驱动应该使用（struct pcie_device*）dev->irq来调用 +request_irq/free_irq。此外，中断模式被存储在struct pcie_device的interrupt_mode +字段中。 + +PCI内存/IO映射的区域 +-------------------- + +PCI Express电源管理（PME）、高级错误报告（AER）、热插拔（HP）和虚拟通道（VC）的服务 +驱动程序访问PCI Express端口的PCI配置空间。在所有情况下，访问的寄存器是相互独立的。这 +个补丁假定所有的服务驱动程序都会表现良好，不会覆盖其他服务驱动程序的配置设置。 + +PCI配置寄存器 +------------- + +每个服务驱动都在自己的功能结构体上运行PCI配置操作，除了PCI Express功能结构体，其中根控制 +寄存器和设备控制寄存器是在PME和AER之间共享。这个补丁假定所有的服务驱动都会表现良好，不会 +覆盖其他服务驱动的配置设置。 diff --git a/Documentation/translations/zh_CN/PCI/sysfs-pci.rst b/Documentation/translations/zh_CN/PCI/sysfs-pci.rst new file mode 100644 index 000000000000..0d75c2e99d52 --- /dev/null +++ b/Documentation/translations/zh_CN/PCI/sysfs-pci.rst @@ -0,0 +1,126 @@ +.. SPDX-License-Identifier: GPL-2.0 +.. include:: ../disclaimer-zh_CN.rst + +:Original: Documentation/PCI/sysfs-pci.rst + +:翻译: + + 司延腾 Yanteng Si <siyanteng@loongson.cn> + +:校译: + + + +======================== +通过sysfs访问PCI设备资源 +======================== + +sysfs，通常挂载在/sys，在支持它的平台上提供对PCI资源的访问。例如，一个特定的总线可能看起 +来像这样:: + + /sys/devices/pci0000:17 + |-- 0000:17:00.0 + | |-- class + | |-- config + | |-- device + | |-- enable + | |-- irq + | |-- local_cpus + | |-- remove + | |-- resource + | |-- resource0 + | |-- resource1 + | |-- resource2 + | |-- revision + | |-- rom + | |-- subsystem_device + | |-- subsystem_vendor + | `-- vendor + `-- ... + +最上面的元素描述了PCI域和总线号码。在这种情况下，域号是0000，总线号是17（两个值都是十六进制）。 +这个总线在0号插槽中包含一个单一功能的设备。为了方便起见，我们复制了域和总线的编号。在设备目录 +下有几个文件，每个文件都有自己的功能。 + + =================== ===================================================== + 文件 功能 + =================== ===================================================== + class PCI级别 (ascii, ro) + config PCI配置空间 (binary, rw) + device PCI设备 (ascii, ro) + enable 设备是否被启用 (ascii, rw) + irq IRQ编号 (ascii, ro) + local_cpus 临近CPU掩码(cpumask, ro) + remove 从内核的列表中删除设备 (ascii, wo) + resource PCI资源主机地址 (ascii, ro) + resource0..N PCI资源N，如果存在的话 (binary, mmap, rw\ [1]_) + resource0_wc..N_wc PCI WC映射资源N，如果可预取的话 (binary, mmap) + revision PCI修订版 (ascii, ro) + rom PCI ROM资源，如果存在的话 (binary, ro) + subsystem_device PCI子系统设备 (ascii, ro) + subsystem_vendor PCI子系统供应商 (ascii, ro) + vendor PCI供应商 (ascii, ro) + =================== ===================================================== + +:: + + ro - 只读文件 + rw - 文件是可读和可写的 + wo - 只写文件 + mmap - 文件是可移动的 + ascii - 文件包含ascii文本 + binary - 文件包含二进制数据 + cpumask - 文件包含一个cpumask类型的 + +.. [1] rw 仅适用于 IORESOURCE_IO（I/O 端口）区域 + +只读文件是信息性的，对它们的写入将被忽略，但 "rom "文件除外。可写文件可以用来在设备上执 +行操作（例如，改变配置空间，分离设备）。 mmapable文件可以通过偏移量为0的文件的mmap获得， +可以用来从用户空间进行实际的设备编程。注意，有些平台不支持某些资源的mmapping，所以一定要 +检查任何尝试的mmap的返回值。其中最值得注意的是I/O端口资源，它也提供读/写访问。 + +enable "文件提供了一个计数器，表明设备已经被启用了多少次。如果'enable'文件目前返回'4'， +而一个'1'被呼入它，它将返回'5'。向它呼入一个'0'会减少计数。不过，即使它返回到0，一些初始 +化可能也不会被逆转。 + +rom "文件很特别，因为它提供了对设备ROM文件的只读访问，如果有的话。然而，它在默认情况下是 +禁用的，所以应用程序应该在尝试读取调用之前将字符串 "1 "写入该文件以启用它，并在访问之后将 +"0 "写入该文件以禁用它。请注意，设备必须被启用，才能成功返回数据。如果驱动没有被绑定到设备 +上，可以使用上面提到的 "enable "文件将其启用。 + +remove "文件是用来移除PCI设备的，通过向该文件写入一个非零的整数。这并不涉及任何形式的热插 +拔功能，例如关闭设备的电源。该设备被从内核的PCI设备列表中移除，它的sysfs目录被移除，并且该 +设备将被从任何连接到它的驱动程序中移除。移除PCI根总线是不允许的。 + +通过sysfs访问原有资源 +--------------------- + +如果底层平台支持的话，传统的I/O端口和ISA内存资源也会在sysfs中提供。它们位于PCI类的层次结构 +中，例如:: + + /sys/class/pci_bus/0000:17/ + |-- bridge -> ../../../devices/pci0000:17 + |-- cpuaffinity + |-- legacy_io + `-- legacy_mem + +legacy_io文件是一个读/写文件，可以被应用程序用来做传统的端口I/O。应用程序应该打开该文件，寻 +找所需的端口（例如0x3e8），并进行1、2或4字节的读或写。legacy_mem文件应该被mmapped，其偏移 +量与所需的内存偏移量相对应，例如0xa0000用于VGA帧缓冲器。然后，应用程序可以简单地解除引用返回 +的指针（当然是在检查了错误之后）来访问遗留内存空间。 + +支持新平台上的PCI访问 +--------------------- + +为了支持上述的PCI资源映射，Linux平台代码最好定义ARCH_GENERIC_PCI_MMAP_RESOURCE并使用该 +功能的通用实现。为了支持通过/proc/bus/pci中的文件实现mmap()的历史接口，平台也可以设置 +HAVE_PCI_MMAP。 + +另外，设置了 HAVE_PCI_MMAP 的平台可以提供他们自己的 pci_mmap_page_range() 实现，而不是定 +义 ARCH_GENERIC_PCI_MMAP_RESOURCE。 + +支持PCI资源的写组合映射的平台必须定义arch_can_pci_mmap_wc()，当写组合被允许时，在运行时应 +评估为非零。支持I/O资源映射的平台同样定义arch_can_pci_mmap_io()。 + +遗留资源由HAVE_PCI_LEGACY定义保护。希望支持遗留功能的平台应该定义它并提供 pci_legacy_read, +pci_legacy_write 和 pci_mmap_legacy_page_range 函数。 diff --git a/Documentation/translations/zh_CN/accounting/delay-accounting.rst b/Documentation/translations/zh_CN/accounting/delay-accounting.rst new file mode 100644 index 000000000000..67d5606e5401 --- /dev/null +++ b/Documentation/translations/zh_CN/accounting/delay-accounting.rst @@ -0,0 +1,111 @@ +.. include:: ../disclaimer-zh_CN.rst + +:Original: Documentation/accounting/delay-accounting.rst + +:Translator: Yang Yang <yang.yang29@zte.com.cn> + +======== +延时计数 +======== + +任务在等待某些内核资源可用时，会造成延时。例如一个可运行的任务可能会等待 +一个空闲CPU来运行。 + +基于每任务的延时计数功能度量由以下情况造成的任务延时： + +a) 等待一个CPU（任务为可运行） +b) 完成由该任务发起的块I/O同步请求 +c) 页面交换 +d) 内存回收 + +并将这些统计信息通过taskstats接口提供给用户空间。 + +这些延时信息为适当的调整任务CPU优先级、io优先级、rss限制提供反馈。重要任务 +长期延时，表示可能需要提高其相关优先级。 + +通过使用taskstats接口，本功能还可提供一个线程组（对应传统Unix进程）所有任务 +（或线程）的总延时统计信息。此类汇总往往是需要的，由内核来完成更加高效。 + +用户空间的实体，特别是资源管理程序，可将延时统计信息汇总到任意组中。为实现 +这一点，任务的延时统计信息在其生命周期内和退出时皆可获取，从而确保可进行 +连续、完整的监控。 + +接口 +---- + +延时计数使用taskstats接口，该接口由本目录另一个单独的文档详细描述。Taskstats +向用户态返回一个通用数据结构，对应每pid或每tgid的统计信息。延时计数功能填写 +该数据结构的特定字段。见 + + include/linux/taskstats.h + +其描述了延时计数相关字段。系统通常以计数器形式返回 CPU、同步块 I/O、交换、内存 +回收等的累积延时。 + +取任务某计数器两个连续读数的差值，将得到任务在该时间间隔内等待对应资源的总延时。 + +当任务退出时，内核会将包含每任务的统计信息发送给用户空间，而无需额外的命令。 +若其为线程组最后一个退出的任务，内核还会发送每tgid的统计信息。更多详细信息见 +taskstats接口的描述。 + +tools/accounting目录中的用户空间程序getdelays.c提供了一些简单的命令，用以显示 +延时统计信息。其也是使用taskstats接口的示例。 + +用法 +---- + +使用以下配置编译内核:: + + CONFIG_TASK_DELAY_ACCT=y + CONFIG_TASKSTATS=y + +延时计数在启动时默认关闭。 +若需开启，在启动参数中增加:: + + delayacct + +本文后续的说明基于延时计数已开启。也可在系统运行时，使用sysctl的 +kernel.task_delayacct进行开关。注意，只有在启用延时计数后启动的 +任务才会有相关信息。 + +系统启动后，使用类似getdelays.c的工具获取任务或线程组（tgid）的延时信息。 + +getdelays命令的一般格式:: + + getdelays [-t tgid] [-p pid] [-c cmd...] + +获取pid为10的任务从系统启动后的延时信息:: + + # ./getdelays -p 10 + （输出信息和下例相似） + +获取所有tgid为5的任务从系统启动后的总延时信息:: + + # ./getdelays -t 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 + +获取指定简单命令运行时的延时信息:: + + # ./getdelays -c ls / + + 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 diff --git a/Documentation/translations/zh_CN/accounting/index.rst b/Documentation/translations/zh_CN/accounting/index.rst index 362e907b41f9..a34952e12a27 100644 --- a/Documentation/translations/zh_CN/accounting/index.rst +++ b/Documentation/translations/zh_CN/accounting/index.rst @@ -15,11 +15,11 @@ .. toctree:: :maxdepth: 1 + delay-accounting psi + taskstats Todolist: cgroupstats - delay-accounting - taskstats taskstats-struct diff --git a/Documentation/translations/zh_CN/accounting/taskstats.rst b/Documentation/translations/zh_CN/accounting/taskstats.rst new file mode 100644 index 000000000000..307ac5ce0e4b --- /dev/null +++ b/Documentation/translations/zh_CN/accounting/taskstats.rst @@ -0,0 +1,145 @@ +.. include:: ../disclaimer-zh_CN.rst + +:Original: Documentation/accounting/taskstats.rst + +:Translator: Yang Yang <yang.yang29@zte.com.cn> + +================ +每任务的统计接口 +================ + +Taskstats是一个基于netlink的接口，用于从内核向用户空间发送每任务及每进程的 +统计信息。 + +Taskstats设计目的： + +- 在任务生命周期内和退出时高效的提供统计信息 +- 统一不同计数子系统的接口 +- 支持未来计数系统的扩展 + +术语 +---- + +“pid”、“tid”、“任务”互换使用，用于描述由struct task_struct定义的标准 +Linux任务。“每pid的统计数据”等价于“每任务的统计数据”。 + +“tgid”、“进程”、“线程组”互换使用，用于描述共享mm_struct的任务集， +也就是传统的Unix进程。尽管使用了tgid这个词，即使一个任务是线程组组长， +对它的处理也没有什么不同。只要一个进程还有任何归属它的任务，它就被认为 +活着。 + +用法 +---- + +为了在任务生命周期内获得统计信息，用户空间需打开一个单播的netlink套接字 +（NETLINK_GENERIC族）然后发送指定pid或tgid的命令。响应消息中包含单个 +任务的统计信息（若指定了pid）或进程所有任务汇总的统计信息（若指定了tgid）。 + +为了在任务退出时获取统计信息，用户空间的监听者发送一个指定cpu掩码的注册命令。 +cpu掩码内的cpu上有任务退出时，每pid的统计信息将发送给注册成功的监听者。使用 +cpu掩码可以限制一个监听者收到的数据，并有助于对netlink接口进行流量控制，后文 +将进行更详细的解释。 + +如果正在退出的任务是线程组中最后一个退出的线程，额外一条包含每tgid统计信息的 +记录也将发送给用户空间。后者包含线程组中所有线程（包括过去和现在）的每pid统计 +信息总和。 + +getdelays.c是一个简单的示例，用以演示如何使用taskstats接口获取延迟统计信息。 +用户可注册cpu掩码、发送命令和处理响应、监听每tid/tgid退出数据、将收到的数据 +写入文件、通过增大接收缓冲区进行基本的流量控制。 + +接口 +---- + +内核用户接口封装在include/linux/taskstats.h。 + +为避免本文档随着接口的演进而过期，本文仅给出当前版本的概要。当本文与taskstats.h +不一致时，以taskstats.h为准。 + +struct taskstats是每pid和每tgid数据共用的计数结构体。它是版本化的，可在内核新增 +计数子系统时进行扩展。taskstats.h中定义了各字段及语义。 + +用户、内核空间的数据交换是属于NETLINK_GENERIC族的netlink消息，使用netlink属性 +接口。消息格式如下:: + + +----------+- - -+-------------+-------------------+ + | nlmsghdr | Pad | genlmsghdr | taskstats payload | + +----------+- - -+-------------+-------------------+ + +Taskstats载荷有三种类型： + +1. 命令：由用户发送给内核。获取指定pid/tgid数据的命令包含一个类型为 +TASKSTATS_CMD_ATTR_PID/TGID的属性，该属性包含u32的pid或tgid载荷。 +pid/tgid指示用户空间要统计的任务/进程。 + +注册/注销获取指定cpu集上退出数据的命令包含一个类型为 +TASKSTATS_CMD_ATTR_REGISTER/DEREGISTER_CPUMASK的属性，该属性包含cpu掩码载荷。 +cpu掩码是以ascii码表示，用逗号分隔的cpu范围。例如若需监听1,2,3,5,7,8号cpu的 +退出数据，cpu掩码表示为"1-3,5,7-8"。若用户空间在关闭监听套接字前忘了注销监听 +的cpu集，随着时间的推移，内核会清理此监听集。但是，出于提效的目的，建议明确 +执行注销。 + +2. 命令的应答：内核发出应答用户空间的命令。载荷有三类属性： + +a) TASKSTATS_TYPE_AGGR_PID/TGID： 本属性不包含载荷，用以指示其后为被统计对象 +的pig/tgid。 + +b) TASKSTATS_TYPE_PID/TGID：本属性的载荷为pig/tgid，其统计信息将被返回。 + +c) TASKSTATS_TYPE_STATS：本属性的载荷为一个struct taskstats实例。每pid和 +每tgid统计信息共用该结构体。 + +3. 内核会在任务退出时发送新消息。其载荷包含一系列以下类型的属性： + +a) TASKSTATS_TYPE_AGGR_PID：指示其后两个属性为pid+stats。 +b) TASKSTATS_TYPE_PID：包含退出任务的pid。 +c) TASKSTATS_TYPE_STATS：包含退出任务的每pid统计信息 +d) TASKSTATS_TYPE_AGGR_TGID：指示其后两个属性为tgid+stats。 +e) TASKSTATS_TYPE_TGID：包含任务所属进程的tgid +f) TASKSTATS_TYPE_STATS：包含退出任务所属进程的每tgid统计信息 + +每tgid的统计 +------------ + +除了每任务的统计信息，taskstats还提供每进程的统计信息，因为资源管理通常以进程 +粒度完成，并且仅在用户空间聚合任务统计信息效率低下且可能不准确（缺乏原子性）。 + +然而，除了每任务统计信息，在内核中维护每进程统计信息存在额外的时间和空间开销。 +为解决此问题，taskstats代码将退出任务的统计信息累积到进程范围的数据结构中。 +当进程最后一个任务退出时，累积的进程级数据也会发送到用户空间（与每任务数据一起）。 + +当用户查询每tgid数据时，内核将指定线程组中所有活动线程的统计信息相加，并添加到 +该线程组的累积总数（含之前退出的线程）。 + +扩展taskstats +------------- + +有两种方法可在未来修改内核扩展taskstats接口，以导出更多的每任务/进程统计信息： + +1. 在现有struct taskstats末尾增加字段。该结构体中的版本号确保了向后兼容性。 +用户空间将仅使用与其版本对应的结构体字段。 + +2. 定义单独的统计结构体并使用netlink属性接口返回对应的数据。由于用户空间独立 +处理每个netlink属性，所以总是可以忽略其不理解类型的属性（因为使用了旧版本接口）。 + +在1.和2.之间进行选择，属于权衡灵活性和开销的问题。若仅需增加少数字段，那么1.是 +首选方法，因为内核和用户空间无需承担处理新netlink属性的开销。但若新字段过多的 +扩展现有结构体，导致不同的用户空间计数程序不必要的接收大型结构体，而对结构体 +字段并不感兴趣，那么2.是值得的。 + +Taskstats的流量控制 +------------------- + +当退出任务数速率变大，监听者可能跟不上内核发送每tid/tgid退出数据的速率，而导致 +数据丢失。taskstats结构体变大、cpu数量上升，都会导致这种可能性增加。 + +为避免统计信息丢失，用户空间应执行以下操作中至少一项： + +- 增大监听者用于接收退出数据的netlink套接字接收缓存区。 + +- 创建更多的监听者，减少每个监听者监听的cpu数量。极端情况下可为每个cpu创建 + 一个监听者。用户还可考虑将监听者的cpu亲和性设置为监听cpu的子集，特别是当他们 + 仅监听一个cpu。 + +尽管采取了这些措施，若用户空间仍收到指示接收缓存区溢出的ENOBUFS错误消息， +则应采取其他措施处理数据丢失。 diff --git a/Documentation/translations/zh_CN/admin-guide/README.rst b/Documentation/translations/zh_CN/admin-guide/README.rst index 980eb20521cf..d20949e8bf6f 100644 --- a/Documentation/translations/zh_CN/admin-guide/README.rst +++ b/Documentation/translations/zh_CN/admin-guide/README.rst @@ -133,7 +133,7 @@ Linux内核5.x版本 <http://kernel.org/> 即使只升级一个小版本，也不要跳过此步骤。每个版本中都会添加新的配置选项， 如果配置文件没有按预定设置，就会出现奇怪的问题。如果您想以最少的工作量 - 将现有配置升级到新版本，请使用 ``makeoldconfig`` ，它只会询问您新配置 + 将现有配置升级到新版本，请使用 ``make oldconfig`` ，它只会询问您新配置 选项的答案。 - 其他配置命令包括:: @@ -161,7 +161,7 @@ Linux内核5.x版本 <http://kernel.org/> "make ${PLATFORM}_defconfig" 使用arch/$arch/configs/${PLATFORM}_defconfig中 的默认选项值创建一个./.config文件。 - 用“makehelp”来获取您体系架构中所有可用平台的列表。 + 用“make help”来获取您体系架构中所有可用平台的列表。 "make allyesconfig" 通过尽可能将选项值设置为“y”，创建一个 @@ -197,9 +197,10 @@ Linux内核5.x版本 <http://kernel.org/> "make localyesconfig" 与localmodconfig类似，只是它会将所有模块选项转换 为内置（=y）。你可以同时通过LMC_KEEP保留模块。 - "make kvmconfig" 为kvm客体内核支持启用其他选项。 + "make kvm_guest.config" + 为kvm客户机内核支持启用其他选项。 - "make xenconfig" 为xen dom0客体内核支持启用其他选项。 + "make xen.config" 为xen dom0客户机内核支持启用其他选项。 "make tinyconfig" 配置尽可能小的内核。 @@ -229,7 +230,7 @@ Linux内核5.x版本 <http://kernel.org/> 请注意，您仍然可以使用此内核运行a.out用户程序。 - 执行 ``make`` 来创建压缩内核映像。如果您安装了lilo以适配内核makefile， - 那么也可以进行 ``makeinstall`` ，但是您可能需要先检查特定的lilo设置。 + 那么也可以进行 ``make install`` ，但是您可能需要先检查特定的lilo设置。 实际安装必须以root身份执行，但任何正常构建都不需要。 无须徒然使用root身份。 diff --git a/Documentation/translations/zh_CN/admin-guide/cputopology.rst b/Documentation/translations/zh_CN/admin-guide/cputopology.rst new file mode 100644 index 000000000000..544d42f8f3fa --- /dev/null +++ b/Documentation/translations/zh_CN/admin-guide/cputopology.rst @@ -0,0 +1,96 @@ +.. SPDX-License-Identifier: GPL-2.0 +.. include:: ../disclaimer-zh_CN.rst + +:Original: Documentation/admin-guide/cputopology.rst + +:翻译: + + 唐艺舟 Tang Yizhou <tangyeechou@gmail.com> + +========================== +如何通过sysfs将CPU拓扑导出 +========================== + +CPU拓扑信息通过sysfs导出。显示的项（属性）和某些架构的/proc/cpuinfo输出相似。它们位于 +/sys/devices/system/cpu/cpuX/topology/。请阅读ABI文件： +Documentation/ABI/stable/sysfs-devices-system-cpu。 + +drivers/base/topology.c是体系结构中性的，它导出了这些属性。然而，die、cluster、book、 +draw这些层次结构相关的文件仅在体系结构提供了下文描述的宏的条件下被创建。 + +对于支持这个特性的体系结构，它必须在include/asm-XXX/topology.h中定义这些宏中的一部分:: + + #define topology_physical_package_id(cpu) + #define topology_die_id(cpu) + #define topology_cluster_id(cpu) + #define topology_core_id(cpu) + #define topology_book_id(cpu) + #define topology_drawer_id(cpu) + #define topology_sibling_cpumask(cpu) + #define topology_core_cpumask(cpu) + #define topology_cluster_cpumask(cpu) + #define topology_die_cpumask(cpu) + #define topology_book_cpumask(cpu) + #define topology_drawer_cpumask(cpu) + +``**_id macros`` 的类型是int。 +``**_cpumask macros`` 的类型是 ``(const) struct cpumask *`` 。后者和恰当的 +``**_siblings`` sysfs属性对应（除了topology_sibling_cpumask()，它和thread_siblings +对应）。 + +为了在所有体系结构上保持一致，include/linux/topology.h提供了上述所有宏的默认定义，以防 +它们未在include/asm-XXX/topology.h中定义: + +1) topology_physical_package_id: -1 +2) topology_die_id: -1 +3) topology_cluster_id: -1 +4) topology_core_id: 0 +5) topology_book_id: -1 +6) topology_drawer_id: -1 +7) topology_sibling_cpumask: 仅入参CPU +8) topology_core_cpumask: 仅入参CPU +9) topology_cluster_cpumask: 仅入参CPU +10) topology_die_cpumask: 仅入参CPU +11) topology_book_cpumask: 仅入参CPU +12) topology_drawer_cpumask: 仅入参CPU + +此外，CPU拓扑信息由/sys/devices/system/cpu提供，包含下述文件。输出对应的内部数据源放在 +方括号（"[]"）中。 + + =========== ================================================================== + kernel_max: 内核配置允许的最大CPU下标值。[NR_CPUS-1] + + offline: 由于热插拔移除或者超过内核允许的CPU上限（上文描述的kernel_max） + 导致未上线的CPU。[~cpu_online_mask + cpus >= NR_CPUS] + + online: 在线的CPU，可供调度使用。[cpu_online_mask] + + possible: 已被分配资源的CPU，如果它们CPU实际存在，可以上线。 + [cpu_possible_mask] + + present: 被系统识别实际存在的CPU。[cpu_present_mask] + =========== ================================================================== + +上述输出的格式和cpulist_parse()兼容[参见 <linux/cpumask.h>]。下面给些例子。 + +在本例中，系统中有64个CPU，但是CPU 32-63超过了kernel_max值，因为NR_CPUS配置项是32， +取值范围被限制为0..31。此外注意CPU2和4-31未上线，但是可以上线，因为它们同时存在于 +present和possible:: + + kernel_max: 31 + offline: 2,4-31,32-63 + online: 0-1,3 + possible: 0-31 + present: 0-31 + +在本例中，NR_CPUS配置项是128，但内核启动时设置possible_cpus=144。系统中有4个CPU， +CPU2被手动设置下线（也是唯一一个可以上线的CPU）:: + + kernel_max: 127 + offline: 2,4-127,128-143 + online: 0-1,3 + possible: 0-127 + present: 0-3 + +阅读Documentation/core-api/cpu_hotplug.rst可了解开机参数possible_cpus=NUM，同时还 +可以了解各种cpumask的信息。 diff --git a/Documentation/translations/zh_CN/admin-guide/index.rst b/Documentation/translations/zh_CN/admin-guide/index.rst index 83db84282562..548e57f4b3f1 100644 --- a/Documentation/translations/zh_CN/admin-guide/index.rst +++ b/Documentation/translations/zh_CN/admin-guide/index.rst @@ -65,6 +65,7 @@ Todolist: clearing-warn-once cpu-load + cputopology lockup-watchdogs unicode sysrq @@ -84,7 +85,6 @@ Todolist: cgroup-v1/index cgroup-v2 cifs/index - cputopology dell_rbu device-mapper/index edid diff --git a/Documentation/translations/zh_CN/core-api/kernel-api.rst b/Documentation/translations/zh_CN/core-api/kernel-api.rst index ab7d81889340..e45fe80d1cd8 100644 --- a/Documentation/translations/zh_CN/core-api/kernel-api.rst +++ b/Documentation/translations/zh_CN/core-api/kernel-api.rst @@ -292,8 +292,6 @@ block/blk-sysfs.c block/blk-settings.c -block/blk-exec.c - block/blk-flush.c block/blk-lib.c diff --git a/Documentation/translations/zh_CN/core-api/kobject.rst b/Documentation/translations/zh_CN/core-api/kobject.rst index b7c37794cc7f..0747b472fdea 100644 --- a/Documentation/translations/zh_CN/core-api/kobject.rst +++ b/Documentation/translations/zh_CN/core-api/kobject.rst @@ -258,7 +258,6 @@ kobject_put()以避免错误的发生是一个很好的做法。 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); @@ -271,10 +270,10 @@ kobject_init()或kobject_init_and_add()时必须指定一个指向该结构的 指针。 当然，kobj_type结构中的release字段是指向这种类型的kobject的release() -方法的一个指针。另外两个字段（sysfs_ops 和 default_attrs）控制这种 +方法的一个指针。另外两个字段（sysfs_ops 和 default_groups）控制这种 类型的对象如何在 sysfs 中被表示；它们超出了本文的范围。 -default_attrs 指针是一个默认属性的列表，它将为任何用这个 ktype 注册 +default_groups 指针是一个默认属性的列表，它将为任何用这个 ktype 注册 的 kobject 自动创建。 @@ -325,10 +324,9 @@ ksets 结构体kset_uevent_ops来处理它:: 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); }; diff --git a/Documentation/translations/zh_CN/cpu-freq/core.rst b/Documentation/translations/zh_CN/cpu-freq/core.rst index 0c6fd447ced6..b3c095306ffe 100644 --- a/Documentation/translations/zh_CN/cpu-freq/core.rst +++ b/Documentation/translations/zh_CN/cpu-freq/core.rst @@ -7,7 +7,9 @@ 司延腾 Yanteng Si <siyanteng@loongson.cn> -.. _cn_core.rst: +:校译: + + 唐艺舟 Tang Yizhou <tangyeechou@gmail.com> ==================================== CPUFreq核心和CPUFreq通知器的通用说明 @@ -29,10 +31,10 @@ CPUFreq核心和CPUFreq通知器的通用说明 ====================== cpufreq核心代码位于drivers/cpufreq/cpufreq.c中。这些cpufreq代码为CPUFreq架构的驱 -动程序（那些操作硬件切换频率的代码）以及 "通知器 "提供了一个标准化的接口。 -这些是设备驱动程序或需要了解策略变化的其它内核部分（如 ACPI 热量管理）或所有频率更改（除 -计时代码外），甚至需要强制确定速度限制的通知器（如 ARM 架构上的 LCD 驱动程序）。 -此外， 内核 "常数" loops_per_jiffy会根据频率变化而更新。 +动程序（那些执行硬件频率切换的代码）以及 "通知器" 提供了一个标准化的接口。 +包括设备驱动程序；需要了解策略变化（如 ACPI 热量管理），或所有频率变化（如计时代码）， +甚至需要强制限制为指定频率（如 ARM 架构上的 LCD 驱动程序）的其它内核组件。 +此外，内核 "常数" loops_per_jiffy 会根据频率变化而更新。 cpufreq策略的引用计数由 cpufreq_cpu_get 和 cpufreq_cpu_put 来完成，以确保 cpufreq 驱 动程序被正确地注册到核心中，并且驱动程序在 cpufreq_put_cpu 被调用之前不会被卸载。这也保证 @@ -41,7 +43,7 @@ cpufreq策略的引用计数由 cpufreq_cpu_get 和 cpufreq_cpu_put 来完成， 2. CPUFreq 通知器 ==================== -CPUFreq通知器符合标准的内核通知器接口。 +CPUFreq通知器遵循标准的内核通知器接口。 关于通知器的细节请参阅 linux/include/linux/notifier.h。 这里有两个不同的CPUfreq通知器 - 策略通知器和转换通知器。 @@ -69,20 +71,20 @@ CPUFreq通知器符合标准的内核通知器接口。 第三个参数是一个包含如下值的结构体cpufreq_freqs： -===== ==================== -cpu 受影响cpu的编号 +====== =============================== +policy 指向struct cpufreq_policy的指针 old 旧频率 new 新频率 flags cpufreq驱动的标志 -===== ==================== +====== =============================== 3. 含有Operating Performance Point (OPP)的CPUFreq表的生成 ================================================================== 关于OPP的细节请参阅 Documentation/power/opp.rst dev_pm_opp_init_cpufreq_table - - 这个功能提供了一个随时可用的转换程序，用来将OPP层关于可用频率的内部信息翻译成一种容易提供给 - cpufreq的格式。 + 这个函数提供了一个随时可用的转换例程，用来将OPP层关于可用频率的内部信息翻译成一种 + cpufreq易于处理的格式。 .. Warning:: diff --git a/Documentation/translations/zh_CN/cpu-freq/cpu-drivers.rst b/Documentation/translations/zh_CN/cpu-freq/cpu-drivers.rst index 0fc5d1495789..87a36044f828 100644 --- a/Documentation/translations/zh_CN/cpu-freq/cpu-drivers.rst +++ b/Documentation/translations/zh_CN/cpu-freq/cpu-drivers.rst @@ -8,7 +8,9 @@ 司延腾 Yanteng Si <siyanteng@loongson.cn> -.. _cn_cpu-drivers.rst: +:校译: + + 唐艺舟 Tang Yizhou <tangyeechou@gmail.com> ======================================= 如何实现一个新的CPUFreq处理器驱动程序？ @@ -38,14 +40,14 @@ 1. 怎么做？ =========== -如此，你刚刚得到了一个全新的CPU/芯片组及其数据手册，并希望为这个CPU/芯片组添加cpufreq +如果，你刚刚得到了一个全新的CPU/芯片组及其数据手册，并希望为这个CPU/芯片组添加cpufreq 支持？很好，这里有一些至关重要的提示： 1.1 初始化 ---------- -首先，在__initcall_level_7 (module_init())或更靠后的函数中检查这个内核是否 +首先，在 __initcall level 7 (module_init())或更靠后的函数中检查这个内核是否 运行在正确的CPU和正确的芯片组上。如果是，则使用cpufreq_register_driver()向 CPUfreq核心层注册一个cpufreq_driver结构体。 @@ -60,11 +62,11 @@ CPUfreq核心层注册一个cpufreq_driver结构体。 .setpolicy 或 .fast_switch 或 .target 或 .target_index - 差异见 下文。 -并且可选择 +其它可选成员 - .flags - cpufreq核的提示。 + .flags - 给cpufreq核心的提示。 - .driver_data - cpufreq驱动程序的特定数据。 + .driver_data - cpufreq驱动程序的特有数据。 .get_intermediate 和 target_intermediate - 用于在改变CPU频率时切换到稳定 的频率。 @@ -73,16 +75,16 @@ CPUfreq核心层注册一个cpufreq_driver结构体。 .bios_limit - 返回HW/BIOS对CPU的最大频率限制值。 - .exit - 一个指向per-policy清理函数的指针，该函数在cpu热插拔过程的CPU_POST_DEAD + .exit - 一个指向per-policy清理函数的指针，该函数在CPU热插拔过程的CPU_POST_DEAD 阶段被调用。 .suspend - 一个指向per-policy暂停函数的指针，该函数在关中断且在该策略的调节器停止 后被调用。 - .resume - 一个指向per-policy恢复函数的指针，该函数在关中断且在调节器再一次开始前被 + .resume - 一个指向per-policy恢复函数的指针，该函数在关中断且在调节器再一次启动前被 调用。 - .attr - 一个指向NULL结尾的"struct freq_attr"列表的指针，该函数允许导出值到 + .attr - 一个指向NULL结尾的"struct freq_attr"列表的指针，该列表允许导出值到 sysfs。 .boost_enabled - 如果设置，则启用提升(boost)频率。 @@ -93,95 +95,93 @@ CPUfreq核心层注册一个cpufreq_driver结构体。 1.2 Per-CPU 初始化 ------------------ -每当一个新的CPU被注册到设备模型中，或者在cpufreq驱动注册自己之后，如果此CPU的cpufreq策 -略不存在，则会调用per-policy的初始化函数cpufreq_driver.init。请注意，.init()和.exit()程序 -只对策略调用一次，而不是对策略管理的每个CPU调用一次。它需要一个 ``struct cpufreq_policy +每当一个新的CPU被注册到设备模型中，或者当cpufreq驱动注册自身之后，如果此CPU的cpufreq策 +略不存在，则会调用per-policy的初始化函数cpufreq_driver.init。请注意，.init()和.exit()例程 +只为某个策略调用一次，而不是对该策略管理的每个CPU调用一次。它需要一个 ``struct cpufreq_policy *policy`` 作为参数。现在该怎么做呢？ 如果有必要，请在你的CPU上激活CPUfreq功能支持。 -然后，驱动程序必须填写以下数值: +然后，驱动程序必须填写以下值: +-----------------------------------+--------------------------------------+ -|policy->cpuinfo.min_freq 和 | | -|policy->cpuinfo.max_freq | 该CPU支持的最低和最高频率（kHz） | -| | | -| | | +|policy->cpuinfo.min_freq和 | 该CPU支持的最低和最高频率（kHz） | +|policy->cpuinfo.max_freq | | +| | | +-----------------------------------+--------------------------------------+ -|policy->cpuinfo.transition_latency | | -| | CPU在两个频率之间切换所需的时间，以 | -| | 纳秒为单位（如适用，否则指定 | -| | CPUFREQ_ETERNAL） | +|policy->cpuinfo.transition_latency | CPU在两个频率之间切换所需的时间，以 | +| | 纳秒为单位（如不适用，设定为 | +| | CPUFREQ_ETERNAL） | +| | | +-----------------------------------+--------------------------------------+ -|policy->cur | 该CPU当前的工作频率(如适用) | -| | | +|policy->cur | 该CPU当前的工作频率(如适用) | +| | | +-----------------------------------+--------------------------------------+ -|policy->min, | | -|policy->max, | | -|policy->policy and, if necessary, | | -|policy->governor | 必须包含该cpu的 “默认策略”。稍后 | -| | 会用这些值调用 | -| | cpufreq_driver.verify and either | -| | cpufreq_driver.setpolicy or | -| | cpufreq_driver.target/target_index | -| | | +|policy->min, | 必须包含该CPU的"默认策略"。稍后 | +|policy->max, | 会用这些值调用 | +|policy->policy and, if necessary, | cpufreq_driver.verify和下面函数 | +|policy->governor | 之一：cpufreq_driver.setpolicy或 | +| | cpufreq_driver.target/target_index | +| | | +-----------------------------------+--------------------------------------+ -|policy->cpus | 用与这个CPU一起做DVFS的(在线+离线) | -| | CPU(即与它共享时钟/电压轨)的掩码更新 | -| | 这个 | -| | | +|policy->cpus | 该policy通过DVFS框架影响的全部CPU | +| | (即与本CPU共享"时钟/电压"对)构成 | +| | 掩码(同时包含在线和离线CPU)，用掩码 | +| | 更新本字段 | +| | | +-----------------------------------+--------------------------------------+ -对于设置其中的一些值(cpuinfo.min[max]_freq, policy->min[max])，频率表助手可能会有帮 +对于设置其中的一些值(cpuinfo.min[max]_freq, policy->min[max])，频率表辅助函数可能会有帮 助。关于它们的更多信息，请参见第2节。 1.3 验证 -------- -当用户决定设置一个新的策略(由 “policy,governor,min,max组成”)时，必须对这个策略进行验证， +当用户决定设置一个新的策略(由"policy,governor,min,max组成")时，必须对这个策略进行验证， 以便纠正不兼容的值。为了验证这些值，cpufreq_verify_within_limits(``struct cpufreq_policy *policy``, ``unsigned int min_freq``, ``unsigned int max_freq``)函数可能会有帮助。 -关于频率表助手的详细内容请参见第2节。 +关于频率表辅助函数的详细内容请参见第2节。 您需要确保至少有一个有效频率（或工作范围）在 policy->min 和 policy->max 范围内。如果有必 -要，先增加policy->max，只有在没有办法的情况下，才减少policy->min。 +要，先增大policy->max，只有在没有解决方案的情况下，才减小policy->min。 1.4 target 或 target_index 或 setpolicy 或 fast_switch? ------------------------------------------------------- -大多数cpufreq驱动甚至大多数cpu频率升降算法只允许将CPU频率设置为预定义的固定值。对于这些，你 +大多数cpufreq驱动甚至大多数CPU频率升降算法只允许将CPU频率设置为预定义的固定值。对于这些，你 可以使用->target()，->target_index()或->fast_switch()回调。 -有些cpufreq功能的处理器可以自己在某些限制之间切换频率。这些应使用->setpolicy()回调。 +有些具有硬件调频能力的处理器可以自行依据某些限制来切换CPU频率。它们应使用->setpolicy()回调。 1.5. target/target_index ------------------------ -target_index调用有两个参数：``struct cpufreq_policy * policy``和``unsigned int`` -索引(于列出的频率表)。 +target_index调用有两个参数： ``struct cpufreq_policy * policy`` 和 ``unsigned int`` +索引(用于索引频率表项)。 当调用这里时，CPUfreq驱动必须设置新的频率。实际频率必须由freq_table[index].frequency决定。 -它应该总是在错误的情况下恢复到之前的频率(即policy->restore_freq)，即使我们之前切换到中间频率。 +在发生错误的情况下总是应该恢复到之前的频率(即policy->restore_freq)，即使我们已经切换到了 +中间频率。 已弃用 ---------- -目标调用有三个参数。``struct cpufreq_policy * policy``, unsigned int target_frequency, +target调用有三个参数。``struct cpufreq_policy * policy``, unsigned int target_frequency, unsigned int relation. CPUfreq驱动在调用这里时必须设置新的频率。实际的频率必须使用以下规则来确定。 -- 紧跟 "目标频率"。 +- 尽量贴近"目标频率"。 - policy->min <= new_freq <= policy->max (这必须是有效的!!!) - 如果 relation==CPUFREQ_REL_L，尝试选择一个高于或等于 target_freq 的 new_freq。("L代表 最低，但不能低于") - 如果 relation==CPUFREQ_REL_H，尝试选择一个低于或等于 target_freq 的 new_freq。("H代表 最高，但不能高于") -这里，频率表助手可能会帮助你--详见第2节。 +这里，频率表辅助函数可能会帮助你 -- 详见第2节。 1.6. fast_switch ---------------- @@ -195,42 +195,43 @@ CPUfreq驱动在调用这里时必须设置新的频率。实际的频率必须 1.7 setpolicy ------------- -setpolicy调用只需要一个``struct cpufreq_policy * policy``作为参数。需要将处理器内或芯片组内动态频 +setpolicy调用只需要一个 ``struct cpufreq_policy * policy`` 作为参数。需要将处理器内或芯片组内动态频 率切换的下限设置为policy->min，上限设置为policy->max，如果支持的话，当policy->policy为 -CPUFREQ_POLICY_PERFORMANCE时选择面向性能的设置，当CPUFREQ_POLICY_POWERSAVE时选择面向省电的设置。 +CPUFREQ_POLICY_PERFORMANCE时选择面向性能的设置，为CPUFREQ_POLICY_POWERSAVE时选择面向省电的设置。 也可以查看drivers/cpufreq/longrun.c中的参考实现。 1.8 get_intermediate 和 target_intermediate -------------------------------------------- -仅适用于 target_index() 和 CPUFREQ_ASYNC_NOTIFICATION 未设置的驱动。 +仅适用于未设置 target_index() 和 CPUFREQ_ASYNC_NOTIFICATION 的驱动。 get_intermediate应该返回一个平台想要切换到的稳定的中间频率，target_intermediate()应该将CPU设置为 -该频率，然后再跳转到'index'对应的频率。核心会负责发送通知，驱动不必在target_intermediate()或 -target_index()中处理。 +该频率，然后再跳转到'index'对应的频率。cpufreq核心会负责发送通知，驱动不必在 +target_intermediate()或target_index()中处理它们。 -在驱动程序不想因为某个目标频率切换到中间频率的情况下，它们可以从get_intermediate()中返回'0'。在这种情况 -下，核心将直接调用->target_index()。 +在驱动程序不想为某个目标频率切换到中间频率的情况下，它们可以让get_intermediate()返回'0'。 +在这种情况下，cpufreq核心将直接调用->target_index()。 -注意：->target_index()应该在失败的情况下恢复到policy->restore_freq，因为core会为此发送通知。 +注意：->target_index()应该在发生失败的情况下将频率恢复到policy->restore_freq， +因为cpufreq核心会为此发送通知。 -2. 频率表助手 -============= +2. 频率表辅助函数 +================= -由于大多数cpufreq处理器只允许被设置为几个特定的频率，因此，一个带有一些函数的 “频率表”可能会辅助处理器驱动 -程序的一些工作。这样的 "频率表" 由一个cpufreq_frequency_table条目构成的数组组成，"driver_data" 中包 -含了驱动程序的具体数值，"frequency" 中包含了相应的频率，并设置了标志。在表的最后，需要添加一个 -cpufreq_frequency_table条目，频率设置为CPUFREQ_TABLE_END。而如果想跳过表中的一个条目，则将频率设置为 -CPUFREQ_ENTRY_INVALID。这些条目不需要按照任何特定的顺序排序，但如果它们是cpufreq 核心会对它们进行快速的DVFS， +由于大多数支持cpufreq的处理器只允许被设置为几个特定的频率，因此，"频率表"和一些相关函数可能会辅助处理器驱动 +程序的一些工作。这样的"频率表"是一个由struct cpufreq_frequency_table的条目构成的数组，"driver_data"成员包 +含驱动程序的专用值，"frequency"成员包含了相应的频率，此外还有标志成员。在表的最后，需要添加一个 +cpufreq_frequency_table条目，频率设置为CPUFREQ_TABLE_END。如果想跳过表中的一个条目，则将频率设置为 +CPUFREQ_ENTRY_INVALID。这些条目不需要按照任何特定的顺序排序，如果排序了，cpufreq核心执行DVFS会更快一点， 因为搜索最佳匹配会更快。 -如果策略在其policy->freq_table字段中包含一个有效的指针，cpufreq表就会被核心自动验证。 +如果在policy->freq_table字段中包含一个有效的频率表指针，频率表就会被cpufreq核心自动验证。 cpufreq_frequency_table_verify()保证至少有一个有效的频率在policy->min和policy->max范围内，并且所有其他 -标准都被满足。这对->verify调用很有帮助。 +准则都被满足。这对->verify调用很有帮助。 -cpufreq_frequency_table_target()是对应于->target阶段的频率表助手。只要把数值传递给这个函数，这个函数就会返 +cpufreq_frequency_table_target()是对应于->target阶段的频率表辅助函数。只要把值传递给这个函数，这个函数就会返 回包含CPU要设置的频率的频率表条目。 以下宏可以作为cpufreq_frequency_table的迭代器。 @@ -238,8 +239,8 @@ cpufreq_frequency_table_target()是对应于->target阶段的频率表助手。 cpufreq_for_each_entry(pos, table) - 遍历频率表的所有条目。 cpufreq_for_each_valid_entry(pos, table) - 该函数遍历所有条目，不包括CPUFREQ_ENTRY_INVALID频率。 -使用参数 "pos"-一个``cpufreq_frequency_table * `` 作为循环变量，使用参数 "table"-作为你想迭代 -的``cpufreq_frequency_table * `` 。 +使用参数"pos" -- 一个 ``cpufreq_frequency_table *`` 作为循环指针，使用参数"table" -- 作为你想迭代 +的 ``cpufreq_frequency_table *`` 。 例如:: @@ -250,5 +251,5 @@ cpufreq_for_each_valid_entry(pos, table) - 该函数遍历所有条目，不包 pos->frequency = ... } -如果你需要在driver_freq_table中处理pos的位置，不要减去指针，因为它的代价相当高。相反，使用宏 +如果你需要在driver_freq_table中处理pos的位置，不要做指针减法，因为它的代价相当高。作为替代，使用宏 cpufreq_for_each_entry_idx() 和 cpufreq_for_each_valid_entry_idx() 。 diff --git a/Documentation/translations/zh_CN/cpu-freq/cpufreq-stats.rst b/Documentation/translations/zh_CN/cpu-freq/cpufreq-stats.rst index f14423099d4b..e8fdba923cd5 100644 --- a/Documentation/translations/zh_CN/cpu-freq/cpufreq-stats.rst +++ b/Documentation/translations/zh_CN/cpu-freq/cpufreq-stats.rst @@ -8,13 +8,15 @@ 司延腾 Yanteng Si <siyanteng@loongson.cn> -.. _cn_cpufreq-stats.rst: +:校译: + + 唐艺舟 Tang Yizhou <tangyeechou@gmail.com> ========================================== sysfs CPUFreq Stats的一般说明 ========================================== -用户信息 +为使用者准备的信息 作者: Venkatesh Pallipadi <venkatesh.pallipadi@intel.com> @@ -29,17 +31,16 @@ sysfs CPUFreq Stats的一般说明 1. 简介 =============== -cpufreq-stats是一个为每个CPU提供CPU频率统计的驱动。 -这些统计数据在/sysfs中以一堆只读接口的形式提供。这个接口（在配置好后）将出现在 -/sysfs（<sysfs root>/devices/system/cpu/cpuX/cpufreq/stats/）中cpufreq下的一个单 -独的目录中，提供给每个CPU。 -各种统计数据将在此目录下形成只读文件。 +cpufreq-stats是一种为每个CPU提供CPU频率统计的驱动。 +这些统计数据以/sysfs中一系列只读接口的形式呈现。cpufreq-stats接口（若已配置）将为每个CPU生成 +/sysfs（<sysfs root>/devices/system/cpu/cpuX/cpufreq/stats/）中cpufreq目录下的stats目录。 +各项统计数据将在stats目录下形成对应的只读文件。 -此驱动是独立于任何可能运行在你所用CPU上的特定cpufreq_driver而设计的。因此，它将与所有 -cpufreq_driver一起工作。 +此驱动是以独立于任何可能运行在你所用CPU上的特定cpufreq_driver的方式设计的。因此，它将能和任何 +cpufreq_driver协同工作。 -2. 提供的统计数据(举例说明) +2. 已提供的统计数据(有例子) ===================================== cpufreq stats提供了以下统计数据（在下面详细解释）。 @@ -48,8 +49,8 @@ cpufreq stats提供了以下统计数据（在下面详细解释）。 - total_trans - trans_table -所有的统计数据将从统计驱动被载入的时间（或统计被重置的时间）开始，到某一统计数据被读取的时间为止。 -显然，统计驱动不会有任何关于统计驱动载入之前的频率转换信息。 +所有统计数据来自以下时间范围：从统计驱动被加载的时间（或统计数据被重置的时间）开始，到某一统计数据被读取的时间为止。 +显然，统计驱动不会保存它被加载之前的任何频率转换信息。 :: @@ -64,14 +65,14 @@ cpufreq stats提供了以下统计数据（在下面详细解释）。 - **reset** -只写属性，可用于重置统计计数器。这对于评估不同调节器下的系统行为非常有用，且无需重启。 +只写属性，可用于重置统计计数器。这对于评估不同调节器的系统行为非常有用，且无需重启。 - **time_in_state** -此项给出了这个CPU所支持的每个频率所花费的时间。cat输出的每一行都会有"<frequency> -<time>"对，表示这个CPU在<frequency>上花费了<time>个usertime单位的时间。这里的 -usertime单位是10mS（类似于/proc中输出的其他时间）。 +此文件给出了在本CPU支持的每个频率上分别花费的时间。cat输出的每一行都是一个"<frequency> +<time>"对，表示这个CPU在<frequency>上花费了<time>个usertime单位的时间。输出的每一行对应 +一个CPU支持的频率。这里usertime单位是10mS（类似于/proc导出的其它时间）。 :: @@ -85,7 +86,7 @@ usertime单位是10mS（类似于/proc中输出的其他时间）。 - **total_trans** -给出了这个CPU上频率转换的总次数。cat的输出将有一个单一的计数，这就是频率转换的总数。 +此文件给出了这个CPU频率转换的总次数。cat的输出是一个计数值，它就是频率转换的总次数。 :: @@ -94,10 +95,10 @@ usertime单位是10mS（类似于/proc中输出的其他时间）。 - **trans_table** -这将提供所有CPU频率转换的细粒度信息。这里的cat输出是一个二维矩阵，其中一个条目<i, j>（第 +本文件提供所有CPU频率转换的细粒度信息。这里的cat输出是一个二维矩阵，其中一个条目<i, j>（第 i行，第j列）代表从Freq_i到Freq_j的转换次数。Freq_i行和Freq_j列遵循驱动最初提供给cpufreq -核的频率表的排序顺序，因此可以排序（升序或降序）或不排序。 这里的输出也包含了每行每列的实际 -频率值，以便更好地阅读。 +核心的频率表的排列顺序，因此可以已排序（升序或降序）或未排序。这里的输出也包含了实际 +频率值，分别按行和按列显示，以便更好地阅读。 如果转换表大于PAGE_SIZE，读取时将返回一个-EFBIG错误。 @@ -115,7 +116,7 @@ i行，第j列）代表从Freq_i到Freq_j的转换次数。Freq_i行和Freq_j列 3. 配置cpufreq-stats ============================ -要在你的内核中配置cpufreq-stats:: +按以下方式在你的内核中配置cpufreq-stats:: Config Main Menu Power management options (ACPI, APM) ---> @@ -124,7 +125,7 @@ i行，第j列）代表从Freq_i到Freq_j的转换次数。Freq_i行和Freq_j列 [*] CPU frequency translation statistics -"CPU Frequency scaling" (CONFIG_CPU_FREQ) 应该被启用以配置cpufreq-stats。 +"CPU Frequency scaling" (CONFIG_CPU_FREQ) 应该被启用，以支持配置cpufreq-stats。 "CPU frequency translation statistics" (CONFIG_CPU_FREQ_STAT)提供了包括 time_in_state、total_trans和trans_table的统计数据。 diff --git a/Documentation/translations/zh_CN/dev-tools/index.rst b/Documentation/translations/zh_CN/dev-tools/index.rst index 0f770b8664e9..77a8c44cdf49 100644 --- a/Documentation/translations/zh_CN/dev-tools/index.rst +++ b/Documentation/translations/zh_CN/dev-tools/index.rst @@ -22,13 +22,13 @@ Documentation/translations/zh_CN/dev-tools/testing-overview.rst :maxdepth: 2 testing-overview + sparse gcov kasan Todolist: - coccinelle - - sparse - kcov - ubsan - kmemleak diff --git a/Documentation/translations/zh_CN/sparse.txt b/Documentation/translations/zh_CN/dev-tools/sparse.rst index 0f444b83d639..556282437aad 100644 --- a/Documentation/translations/zh_CN/sparse.txt +++ b/Documentation/translations/zh_CN/dev-tools/sparse.rst @@ -1,34 +1,34 @@ -Chinese translated version of Documentation/dev-tools/sparse.rst +Copyright 2004 Linus Torvalds +Copyright 2004 Pavel Machek <pavel@ucw.cz> +Copyright 2006 Bob Copeland <me@bobcopeland.com> -If you have any comment or update to the content, please contact the -original document maintainer directly. However, if you have a problem -communicating in English you can also ask the Chinese maintainer for -help. Contact the Chinese maintainer if this translation is outdated -or if there is a problem with the translation. +.. include:: ../disclaimer-zh_CN.rst -Chinese maintainer: Li Yang <leoyang.li@nxp.com> ---------------------------------------------------------------------- -Documentation/dev-tools/sparse.rst 的中文翻译 +:Original: Documentation/dev-tools/sparse.rst -如果想评论或更新本文的内容，请直接联系原文档的维护者。如果你使用英文 -交流有困难的话，也可以向中文版维护者求助。如果本翻译更新不及时或者翻 -译存在问题，请联系中文版维护者。 +:翻译: -中文版维护者： 李阳 Li Yang <leoyang.li@nxp.com> -中文版翻译者： 李阳 Li Yang <leoyang.li@nxp.com> + Li Yang <leoyang.li@nxp.com> +:校译: -以下为正文 ---------------------------------------------------------------------- + 司延腾 Yanteng Si <siyanteng@loongson.cn> -Copyright 2004 Linus Torvalds -Copyright 2004 Pavel Machek <pavel@ucw.cz> -Copyright 2006 Bob Copeland <me@bobcopeland.com> +.. _cn_sparse: + +Sparse +====== + +Sparse是一个C程序的语义检查器；它可以用来发现内核代码的一些潜在问题。 关 +于sparse的概述，请参见https://lwn.net/Articles/689907/；本文档包含 +一些针对内核的sparse信息。 +关于sparse的更多信息，主要是关于它的内部结构，可以在它的官方网页上找到： +https://sparse.docs.kernel.org。 使用 sparse 工具做类型检查 ~~~~~~~~~~~~~~~~~~~~~~~~~~ -"__bitwise" 是一种类型属性，所以你应该这样使用它： +"__bitwise" 是一种类型属性，所以你应该这样使用它:: typedef int __bitwise pm_request_t; @@ -48,7 +48,7 @@ Copyright 2006 Bob Copeland <me@bobcopeland.com> 坦白来说，你并不需要使用枚举类型。上面那些实际都可以浓缩成一个特殊的"int __bitwise"类型。 -所以更简单的办法只要这样做： +所以更简单的办法只要这样做:: typedef int __bitwise pm_request_t; @@ -60,25 +60,42 @@ __bitwise"类型。 一个小提醒：常数整数"0"是特殊的。你可以直接把常数零当作位方式整数使用而 不用担心 sparse 会抱怨。这是因为"bitwise"（恰如其名）是用来确保不同位方 式类型不会被弄混（小尾模式，大尾模式，cpu尾模式，或者其他），对他们来说 -常数"0"确实是特殊的。 +常数"0"确实 **是** 特殊的。 + +使用sparse进行锁检查 +-------------------- + +下面的宏对于 gcc 来说是未定义的，在 sparse 运行时定义，以使用sparse的“上下文” +跟踪功能，应用于锁定。 这些注释告诉 sparse 什么时候有锁，以及注释的函数的进入和 +退出。 + +__must_hold - 指定的锁在函数进入和退出时被持有。 + +__acquires - 指定的锁在函数退出时被持有，但在进入时不被持有。 + +__releases - 指定的锁在函数进入时被持有，但在退出时不被持有。 + +如果函数在不持有锁的情况下进入和退出，在函数内部以平衡的方式获取和释放锁，则不 +需要注释。 +上面的三个注释是针对sparse否则会报告上下文不平衡的情况。 获取 sparse 工具 ~~~~~~~~~~~~~~~~ 你可以从 Sparse 的主页获取最新的发布版本： - http://www.kernel.org/pub/linux/kernel/people/josh/sparse/ + https://www.kernel.org/pub/software/devel/sparse/dist/ 或者，你也可以使用 git 克隆最新的 sparse 开发版本： - git://git.kernel.org/pub/scm/linux/kernel/git/josh/sparse.git + git://git.kernel.org/pub/scm/devel/sparse/sparse.git 一旦你下载了源码，只要以普通用户身份运行： make make install -它将会被自动安装到你的 ~/bin 目录下。 +如果是标准的用户，它将会被自动安装到你的~/bin目录下。 使用 sparse 工具 ~~~~~~~~~~~~~~~~ diff --git a/Documentation/translations/zh_CN/index.rst b/Documentation/translations/zh_CN/index.rst index a34e58733ac8..46e14ec9963d 100644 --- a/Documentation/translations/zh_CN/index.rst +++ b/Documentation/translations/zh_CN/index.rst @@ -23,6 +23,11 @@ 另外，随时欢迎您对内核文档进行改进；如果您想提供帮助，请加入vger.kernel.org 上的linux-doc邮件列表。 +顺便说下，中文文档也需要遵守内核编码风格，风格中中文和英文的主要不同就是中文 +的字符标点占用两个英文字符宽度， 所以，当英文要求不要超过每行100个字符时， +中文就不要超过50个字符。另外，也要注意'-'，'=' 等符号与相关标题的对齐。在将 +补丁提交到社区之前，一定要进行必要的checkpatch.pl检查和编译测试。 + 许可证文档 ---------- @@ -106,6 +111,7 @@ TODOList: virt/index infiniband/index accounting/index + scheduler/index TODOList: @@ -140,7 +146,6 @@ TODOList: * PCI/index * scsi/index * misc-devices/index -* scheduler/index * mhi/index 体系结构无关文档 diff --git a/Documentation/translations/zh_CN/process/submitting-patches.rst b/Documentation/translations/zh_CN/process/submitting-patches.rst index 3f1683cd4727..a9570165582a 100644 --- a/Documentation/translations/zh_CN/process/submitting-patches.rst +++ b/Documentation/translations/zh_CN/process/submitting-patches.rst @@ -254,29 +254,6 @@ Linus Torvalds 是决定改动能否进入 Linux 内核的最终裁决者。他 手册页补丁，或至少发送更改通知，以便一些信息进入手册页。还应将用户空间API 更改复制到 linux-api@vger.kernel.org。 -对于小的补丁，你也许会CC到搜集琐碎补丁的邮件列表(Trivial Patch Monkey) -trivial@kernel.org，那里专门收集琐碎的补丁。下面这样的补丁会被看作“琐碎的” -补丁： - - - 文档的拼写修正。 - - 修正会影响到 grep(1) 的拼写。 - - 警告信息修正(频繁的打印无用的警告是不好的。) - - 编译错误修正（代码逻辑的确是对的，只是编译有问题。） - - 运行时修正（只要真的修正了错误。） - - 移除使用了被废弃的函数/宏的代码(例如 check_region。) - - 联系方式和文档修正。 - - 用可移植的代码替换不可移植的代码（即使在体系结构相关的代码中，既然有 - - 人拷贝，只要它是琐碎的） - - 任何文件的作者/维护者对该文件的改动（例如 patch monkey 在重传模式下） - -(译注，关于“琐碎补丁”的一些说明：因为原文的这一部分写得比较简单，所以不得不 -违例写一下译注。"trivial"这个英文单词的本意是“琐碎的，不重要的。”但是在这里 -有稍微有一些变化，例如对一些明显的NULL指针的修正，属于运行时修正，会被归类 -到琐碎补丁里。虽然NULL指针的修正很重要，但是这样的修正往往很小而且很容易得到 -检验，所以也被归入琐碎补丁。琐碎补丁更精确的归类应该是 -“simple, localized & easy to verify”，也就是说简单的，局部的和易于检验的。 -trivial@kernel.org邮件列表的目的是针对这样的补丁，为提交者提供一个中心，来 -降低提交的门槛。) 6) 没有 MIME 编码，没有链接，没有压缩，没有附件，只有纯文本 ----------------------------------------------------------- diff --git a/Documentation/translations/zh_CN/scheduler/completion.rst b/Documentation/translations/zh_CN/scheduler/completion.rst new file mode 100644 index 000000000000..bc8218514e0a --- /dev/null +++ b/Documentation/translations/zh_CN/scheduler/completion.rst @@ -0,0 +1,256 @@ +.. include:: ../disclaimer-zh_CN.rst + +:Original: Documentation/scheduler/completion.rst + +:翻译: + + 司延腾 Yanteng Si <siyanteng@loongson.cn> + +:校译: + + 唐艺舟 Tang Yizhou <tangyeechou@gmail.com> + +======================================= +完成 - "等待完成" 屏障应用程序接口(API) +======================================= + +简介: +----- + +如果你有一个或多个线程必须等待某些内核活动达到某个点或某个特定的状态，完成可以为这 +个问题提供一个无竞争的解决方案。从语义上讲，它们有点像pthread_barrier()，并且使 +用的案例类似 + +完成是一种代码同步机制，它比任何滥用锁/信号量和忙等待循环的行为都要好。当你想用yield() +或一些古怪的msleep(1)循环来允许其它代码继续运行时，你可能想用wait_for_completion*() +调用和completion()来代替。 + +使用“完成”的好处是，它们有一个良好定义、聚焦的目标，这不仅使得我们很容易理解代码的意图， +而且它们也会生成更高效的代码，因为所有线程都可以继续执行，直到真正需要结果的时刻。而且等 +待和信号都高效的使用了低层调度器的睡眠/唤醒设施。 + +完成是建立在Linux调度器的等待队列和唤醒基础设施之上的。等待队列中的线程所等待的 +事件被简化为 ``struct completion`` 中的一个简单标志，被恰如其名地称为‘done’。 + +由于完成与调度有关，代码可以在kernel/sched/completion.c中找到。 + + +用法: +----- + +使用完成需要三个主要部分: + + - 'struct completion' 同步对象的初始化 + - 通过调用wait_for_completion()的一个变体来实现等待部分。 + - 通过调用complete()或complete_all()实现发信端。 + +也有一些辅助函数用于检查完成的状态。请注意，虽然必须先做初始化，但等待和信号部分可以 +按任何时间顺序出现。也就是说，一个线程在另一个线程检查是否需要等待它之前，已经将一个 +完成标记为 "done"，这是完全正常的。 + +要使用完成API，你需要#include <linux/completion.h>并创建一个静态或动态的 +``struct completion`` 类型的变量，它只有两个字段:: + + struct completion { + unsigned int done; + wait_queue_head_t wait; + }; + +结构体提供了->wait等待队列来放置任务进行等待（如果有的话），以及->done完成标志来表明它 +是否完成。 + +完成的命名应当与正在被同步的事件名一致。一个好的例子是:: + + wait_for_completion(&early_console_added); + + complete(&early_console_added); + +好的、直观的命名（一如既往地）有助于代码的可读性。将一个完成命名为 ``complete`` +是没有帮助的，除非其目的是超级明显的... + + +初始化完成: +----------- + +动态分配的完成对象最好被嵌入到数据结构中，以确保在函数/驱动的生命周期内存活，以防 +止与异步complete()调用发生竞争。 + +在使用wait_for_completion()的_timeout()或_killable()/_interruptible()变体 +时应特别小心，因为必须保证在所有相关活动（complete()或reinit_completion()）发生 +之前不会发生内存解除分配，即使这些等待函数由于超时或信号触发而过早返回。 + +动态分配的完成对象的初始化是通过调用init_completion()来完成的:: + + init_completion(&dynamic_object->done); + +在这个调用中，我们初始化 waitqueue 并将 ->done 设置为 0，即“not completed”或 +“not done”。 + +重新初始化函数reinit_completion()，只是将->done字段重置为0（“not done”），而 +不触及等待队列。这个函数的调用者必须确保没有任何令人讨厌的wait_for_completion() +调用在并行进行。 + +在同一个完成对象上调用init_completion()两次很可能是一个bug，因为它将队列重新初始 +化为一个空队列，已排队的任务可能会“丢失”--在这种情况下使用reinit_completion()，但 +要注意其他竞争。 + +对于静态声明和初始化，可以使用宏。 + +对于文件范围内的静态（或全局）声明，你可以使用 DECLARE_COMPLETION():: + + static DECLARE_COMPLETION(setup_done); + DECLARE_COMPLETION(setup_done); + +注意，在这种情况下，完成在启动时（或模块加载时）被初始化为“not done”，不需要调用 +init_completion()。 + +当完成被声明为一个函数中的局部变量时，那么应该总是明确地使用 +DECLARE_COMPLETION_ONSTACK()来初始化，这不仅仅是为了让lockdep正确运行，也是明确表 +名它有限的使用范围是有意为之并被仔细考虑的:: + + DECLARE_COMPLETION_ONSTACK(setup_done) + +请注意，当使用完成对象作为局部变量时，你必须敏锐地意识到函数堆栈的短暂生命期：在所有 +活动（如等待的线程）停止并且完成对象完全未被使用之前，函数不得返回到调用上下文。 + +再次强调这一点：特别是在使用一些具有更复杂结果的等待API变体时，比如超时或信号 +（_timeout(), _killable()和_interruptible()）变体，等待可能会提前完成，而对象可 +能仍在被其他线程使用 - 从wait_on_completion*()调用者函数的返回会取消分配函数栈，如 +果complete()在其它某线程中完成调用，会引起微小的数据损坏。简单的测试可能不会触发这 +些类型的竞争。 + +如果不确定的话，使用动态分配的完成对象， 最好是嵌入到其它一些生命周期长的对象中，长到 +超过使用完成对象的任何辅助线程的生命周期，或者有一个锁或其他同步机制来确保complete() +不会在一个被释放的对象中调用。 + +在堆栈上单纯地调用DECLARE_COMPLETION()会触发一个lockdep警告。 + +等待完成: +--------- + +对于一个线程来说，要等待一些并发活动的完成，它要在初始化的完成结构体上调用 +wait_for_completion():: + + void wait_for_completion(struct completion *done) + +一个典型的使用场景是:: + + CPU#1 CPU#2 + + struct completion setup_done; + + init_completion(&setup_done); + initialize_work(...,&setup_done,...); + + /* run non-dependent code */ /* do setup */ + + wait_for_completion(&setup_done); complete(setup_done); + +这并不意味着调用wait_for_completion()和complete()有任何特定的时间顺序--如果调 +用complete()发生在调用wait_for_completion()之前，那么等待方将立即继续执行，因为 +所有的依赖都得到了满足；如果没有，它将阻塞，直到complete()发出完成的信号。 + +注意，wait_for_completion()是在调用spin_lock_irq()/spin_unlock_irq()，所以 +只有当你知道中断被启用时才能安全地调用它。从IRQs-off的原子上下文中调用它将导致难以检 +测的错误的中断启用。 + +默认行为是不带超时的等待，并将任务标记为“UNINTERRUPTIBLE”状态。wait_for_completion() +及其变体只有在进程上下文中才是安全的（因为它们可以休眠），但在原子上下文、中断上下文、IRQ +被禁用或抢占被禁用的情况下是不安全的--关于在原子/中断上下文中处理完成的问题，还请看下面的 +try_wait_for_completion()。 + +由于wait_for_completion()的所有变体都可能（很明显）阻塞很长时间，这取决于它们所等 +待的活动的性质，所以在大多数情况下，你可能不想在持有mutex锁的情况下调用它。 + + +wait_for_completion*()可用的变体: +--------------------------------- + +下面的变体都会返回状态，在大多数(/所有)情况下都应该检查这个状态--在故意不检查状态的情 +况下，你可能要做一个说明(例如，见arch/arm/kernel/smp.c:__cpu_up())。 + +一个常见的问题是不准确的返回类型赋值，所以要注意将返回值赋值给适当类型的变量。 + +检查返回值的具体含义也可能被发现是相当不准确的，例如，像这样的构造:: + + if (!wait_for_completion_interruptible_timeout(...)) + +...会在成功完成和中断的情况下执行相同的代码路径--这可能不是你想要的结果:: + + int wait_for_completion_interruptible(struct completion *done) + +这个函数在任务等待时标记为TASK_INTERRUPTIBLE。如果在等待期间收到信号，它将返回 +-ERESTARTSYS；否则为0:: + + unsigned long wait_for_completion_timeout(struct completion *done, unsigned long timeout) + +该任务被标记为TASK_UNINTERRUPTIBLE，并将最多超时等待“timeout”个jiffies。如果超时发生，则 +返回0，否则返回剩余的时间（但至少是1）。 + +超时最好用msecs_to_jiffies()或usecs_to_jiffies()计算，以使代码在很大程度上不受 +HZ的影响。 + +如果返回的超时值被故意忽略，那么注释应该解释原因 +（例如，见drivers/mfd/wm8350-core.c wm8350_read_auxadc():: + + long wait_for_completion_interruptible_timeout(struct completion *done, unsigned long timeout) + +这个函数传递一个以jiffies为单位的超时，并将任务标记为TASK_INTERRUPTIBLE。如果收到 +信号，则返回-ERESTARTSYS；否则，如果完成超时，则返回0；如果完成了，则返回剩余的时间 +（jiffies）。 + +更多的变体包括_killable，它使用TASK_KILLABLE作为指定的任务状态，如果它被中断，将返 +回-ERESTARTSYS，如果完成了，则返回0。它也有一个_timeout变体:: + + long wait_for_completion_killable(struct completion *done) + long wait_for_completion_killable_timeout(struct completion *done, unsigned long timeout) + +wait_for_completion_io()的_io变体的行为与非_io变体相同，只是将等待时间计为“IO等待”， +这对任务在调度/IO统计中的计算方式有影响:: + + void wait_for_completion_io(struct completion *done) + unsigned long wait_for_completion_io_timeout(struct completion *done, unsigned long timeout) + + +对完成发信号: +------------- + +一个线程想要发出信号通知继续的条件已经达到，就会调用complete()，向其中一个等待者发出信 +号表明它可以继续:: + + void complete(struct completion *done) + +... or calls complete_all() to signal all current and future waiters:: + + void complete_all(struct completion *done) + +即使在线程开始等待之前就发出了完成的信号，信号传递也会继续进行。这是通过等待者 +“consuming”（递减）“struct completion” 的完成字段来实现的。等待的线程唤醒的顺序 +与它们被排队的顺序相同（FIFO顺序）。 + +如果多次调用complete()，那么这将允许该数量的等待者继续进行--每次调用complete()将 +简单地增加已完成的字段。但多次调用complete_all()是一个错误。complete()和 +complete_all()都可以在IRQ/atomic上下文中安全调用。 + +在任何时候，只能有一个线程在一个特定的 “struct completion”上调用 complete() 或 +complete_all() - 通过等待队列自旋锁进行序列化。任何对 complete() 或 +complete_all() 的并发调用都可能是一个设计错误。 + +从IRQ上下文中发出完成信号 是可行的，因为它将正确地用 +spin_lock_irqsave()/spin_unlock_irqrestore()执行锁操作 + + +try_wait_for_completion()/completion_done(): +-------------------------------------------- + +try_wait_for_completion()函数不会将线程放在等待队列中，而是在需要排队（阻塞）线 +程时返回false，否则会消耗一个已发布的完成并返回true:: + + bool try_wait_for_completion(struct completion *done) + +最后，为了在不以任何方式改变完成的情况下检查完成的状态，可以调用completion_done()， +如果没有发布的完成尚未被等待者消耗，则返回false（意味着存在等待者），否则返回true:: + + bool completion_done(struct completion *done) + +try_wait_for_completion()和completion_done()都可以在IRQ或原子上下文中安全调用。 diff --git a/Documentation/translations/zh_CN/scheduler/index.rst b/Documentation/translations/zh_CN/scheduler/index.rst new file mode 100644 index 000000000000..f8f8f35d53c7 --- /dev/null +++ b/Documentation/translations/zh_CN/scheduler/index.rst @@ -0,0 +1,44 @@ +.. include:: ../disclaimer-zh_CN.rst + +:Original: Documentation/scheduler/index.rst + +:翻译: + + 司延腾 Yanteng Si <siyanteng@loongson.cn> + +:校译: + + + +=============== +Linux调度器 +=============== + +.. toctree:: + :maxdepth: 1 + + completion + sched-arch + sched-bwc + sched-design-CFS + sched-domains + sched-capacity + + +TODOList: + + sched-bwc + sched-deadline + sched-energy + sched-nice-design + sched-rt-group + sched-stats + + text_files + +.. only:: subproject and html + + Indices + ======= + + * :ref:`genindex` diff --git a/Documentation/translations/zh_CN/scheduler/sched-arch.rst b/Documentation/translations/zh_CN/scheduler/sched-arch.rst new file mode 100644 index 000000000000..754a15c6b60f --- /dev/null +++ b/Documentation/translations/zh_CN/scheduler/sched-arch.rst @@ -0,0 +1,76 @@ +.. include:: ../disclaimer-zh_CN.rst + +:Original: Documentation/scheduler/sched-arch.rst + +:翻译: + + 司延腾 Yanteng Si <siyanteng@loongson.cn> + +:校译: + + + +=============================== +架构特定代码的CPU调度器实现提示 +=============================== + + Nick Piggin, 2005 + +上下文切换 +========== +1. 运行队列锁 +默认情况下，switch_to arch函数在调用时锁定了运行队列。这通常不是一个问题，除非 +switch_to可能需要获取运行队列锁。这通常是由于上下文切换中的唤醒操作造成的。见 +arch/ia64/include/asm/switch_to.h的例子。 + +为了要求调度器在运行队列解锁的情况下调用switch_to，你必须在头文件 +中`#define __ARCH_WANT_UNLOCKED_CTXSW`(通常是定义switch_to的那个文件）。 + +在CONFIG_SMP的情况下，解锁的上下文切换对核心调度器的实现只带来了非常小的性能损 +失。 + +CPU空转 +======= +你的cpu_idle程序需要遵守以下规则： + +1. 现在抢占应该在空闲的例程上禁用。应该只在调用schedule()时启用，然后再禁用。 + +2. need_resched/TIF_NEED_RESCHED 只会被设置，并且在运行任务调用 schedule() + 之前永远不会被清除。空闲线程只需要查询need_resched，并且永远不会设置或清除它。 + +3. 当cpu_idle发现（need_resched() == 'true'），它应该调用schedule()。否则 + 它不应该调用schedule()。 + +4. 在检查need_resched时，唯一需要禁用中断的情况是，我们要让处理器休眠到下一个中 + 断（这并不对need_resched提供任何保护，它可以防止丢失一个中断）: + + 4a. 这种睡眠类型的常见问题似乎是:: + + local_irq_disable(); + if (!need_resched()) { + local_irq_enable(); + *** resched interrupt arrives here *** + __asm__("sleep until next interrupt"); + } + +5. 当need_resched变为高电平时，TIF_POLLING_NRFLAG可以由不需要中断来唤醒它们 + 的空闲程序设置。换句话说，它们必须定期轮询need_resched，尽管做一些后台工作或 + 进入低CPU优先级可能是合理的。 + + - 5a. 如果TIF_POLLING_NRFLAG被设置，而我们确实决定进入一个中断睡眠，那 + 么需要清除它，然后发出一个内存屏障（接着测试need_resched，禁用中断，如3中解释）。 + +arch/x86/kernel/process.c有轮询和睡眠空闲函数的例子。 + + +可能出现的arch/问题 +=================== + +我发现的可能的arch问题（并试图解决或没有解决）。: + +ia64 - safe_halt的调用与中断相比，是否很荒谬？ (它睡眠了吗) (参考 #4a) + +sh64 - 睡眠与中断相比，是否很荒谬？ (参考 #4a) + +sparc - 在这一点上，IRQ是开着的（？），把local_irq_save改为_disable。 + - 待办事项: 需要第二个CPU来禁用抢占 (参考 #1) diff --git a/Documentation/translations/zh_CN/scheduler/sched-bwc.rst b/Documentation/translations/zh_CN/scheduler/sched-bwc.rst new file mode 100644 index 000000000000..90e931f4ceed --- /dev/null +++ b/Documentation/translations/zh_CN/scheduler/sched-bwc.rst @@ -0,0 +1,204 @@ +.. include:: ../disclaimer-zh_CN.rst + +:Original: Documentation/scheduler/sched-bwc.rst + +:翻译: + + 司延腾 Yanteng Si <siyanteng@loongson.cn> + +:校译: + + + +============ +CFS 带宽控制 +============ + +.. note:: + 本文只讨论了SCHED_NORMAL的CPU带宽控制。 + SCHED_RT的情况在Documentation/scheduler/sched-rt-group.rst中有涉及。 + +CFS带宽控制是一个CONFIG_FAIR_GROUP_SCHED扩展，它允许指定一个组或层次的最大CPU带宽。 + +一个组允许的带宽是用配额和周期指定的。在每个给定的”周期“（微秒）内，一个任务组被分配多 +达“配额”微秒的CPU时间。当cgroup中的线程可运行时，该配额以时间片段的方式被分配到每个cpu +运行队列中。一旦所有的配额被分配，任何额外的配额请求将导致这些线程被限流。被限流的线程将不 +能再次运行，直到下一个时期的配额得到补充。 + +一个组的未分配配额是全局跟踪的，在每个周期边界被刷新为cfs_quota单元。当线程消耗这个带宽时， +它以需求为基础被转移到cpu-local“筒仓”，在每次更新中转移的数量是可调整的，被描述为“片“（时 +间片）。 + +突发特性 +-------- +现在这个功能借来的时间是用于防范我们对未来的低估，代价是对其他系统用户的干扰增加。所有这些都 +有很好的限制。 + +传统的（UP-EDF）带宽控制是这样的: + + (U = \Sum u_i) <= 1 + +这既保证了每个最后期限的实现，也保证了系统的稳定。毕竟，如果U>1，那么每一秒钟的壁钟时间，我 +们就必须运行超过一秒钟的程序时间，显然会错过我们的最后期限，但下一个最后期限会更远，永远没有 +时间赶上，无边无界的失败。 + +突发特性观察到工作负载并不总是执行全部配额；这使得人们可以将u_i描述为一个统计分布。 + +例如，让u_i = {x,e}_i，其中x是p(95)和x+e p(100)（传统的WCET）。这实际上允许u更小，提 +高了效率（我们可以在系统中打包更多的任务），但代价是当所有的概率都一致时，会错过最后期限。然 +而，它确实保持了稳定性，因为只要我们的x高于平均水平，每一次超限都必须与低估相匹配。 + +也就是说，假设我们有两个任务，都指定了一个p(95)值，那么我们有一个p(95)*p(95)=90.25%的机 +会，两个任务都在他们的配额内，一切都很好。同时，我们有一个p(5)p(5)=0.25%的机会，两个任务同 +时超过他们的配额（保证最后期限失败）。在这两者之间有一个阈值，其中一个超过了，而另一个没有不足， +无法补偿；这取决于具体的CDFs。 + +同时，我们可以说，最坏的情况下的截止日期失败，将是Sum e_i；也就是说，有一个有界的迟延（在假 +设x+e确实是WCET的情况下）。 + +使用突发时的干扰是由错过最后期限的可能性和平均WCET来评价的。测试结果表明，当有许多cgroup或 +CPU未被充分利用时，干扰是有限的。更多的细节显示在： +https://lore.kernel.org/lkml/5371BD36-55AE-4F71-B9D7-B86DC32E3D2B@linux.alibaba.com/ + +管理 +---- +配额、周期和突发是在cpu子系统内通过cgroupfs管理的。 + +.. note:: + 本节描述的cgroupfs文件只适用于cgroup v1.对于cgroup v2，请参阅Control Group v2。 + :ref:`Documentation/admin-guide/cgroup-v2.rst <cgroup-v2-cpu>`. + +- cpu.cfs_quota_us：在一个时期内补充的运行时间（微秒）。 +- cpu.cfs_period_us：一个周期的长度（微秒）。 +- cpu.stat: 输出节流统计数据[下面进一步解释] +- cpu.cfs_burst_us：最大累积运行时间（微秒）。 + +默认值是:: + + cpu.cfs_period_us=100ms + cpu.cfs_quota_us=-1 + cpu.cfs_burst_us=0 + +cpu.cfs_quota_us的值为-1表示该组没有任何带宽限制，这样的组被描述为无限制的带宽组。这代表 +了CFS的传统工作保护行为。 + +写入不小于cpu.cfs_burst_us的任何（有效的）正值将配发指定的带宽限制。该配额或周期允许的最 +小配额是1ms。周期长度也有一个1s的上限。当带宽限制以分层方式使用时，存在额外的限制，这些在下 +面有更详细的解释。 + +向cpu.cfs_quota_us写入任何负值都会移除带宽限制，并使组再次回到无限制的状态。 + +cpu.cfs_burst_us的值为0表示该组不能积累任何未使用的带宽。它使得CFS的传统带宽控制行为没有 +改变。将不大于 cpu.cfs_quota_us 的任何(有效的)正值写入 cpu.cfs_burst_us 将配发未使用 +带宽累积的上限。 + +如果一个组处于受限状态，对该组带宽规格的任何更新都将导致其成为无限流状态。 + +系统范围设置 +------------ +为了提高效率，运行时间在全局池和CPU本地“筒仓”之间以批处理方式转移。这大大减少了大型系统的全 +局核算压力。每次需要进行这种更新时，传输的数量被描述为 "片"。 + +这是可以通过procfs调整的:: + + /proc/sys/kernel/sched_cfs_bandwidth_slice_us (default=5ms) + +较大的时间片段值将减少传输开销，而较小的值则允许更精细的消费。 + +统计 +---- +一个组的带宽统计数据通过cpu.stat的5个字段导出。 + +cpu.stat: + +- nr_periods：已经过去的执行间隔的数量。 +- nr_throttled: 该组已被节流/限制的次数。 +- throttled_time: 该组的实体被限流的总时间长度（纳秒）。 +- nr_bursts：突发发生的周期数。 +- burst_time: 任何CPU在各个时期使用超过配额的累计壁钟时间（纳秒）。 + +这个接口是只读的。 + +分层考虑 +-------- +该接口强制要求单个实体的带宽总是可以达到的，即：max(c_i) <= C。然而，在总体情况下，是明确 +允许过度订阅的，以便在一个层次结构中实现工作保护语义: + + 例如，Sum (c_i)可能超过C + +[ 其中C是父方的带宽，c_i是其子方的带宽。 ] + +.. note:: + 译文中的父亲/孩子指的是cgroup parent, cgroup children。 + +有两种方式可以使一个组变得限流: + + a. 它在一段时期内完全消耗自己的配额 + b. 父方的配额在其期间内全部用完 + +在上述b)情况下，即使孩子可能有剩余的运行时间，它也不会被允许，直到父亲的运行时间被刷新。 + +CFS带宽配额的注意事项 +--------------------- +一旦一个片断被分配给一个cpu，它就不会过期。然而，如果该cpu上的所有线程都无法运行，那么除了 +1ms以外的所有时间片都可以返回到全局池中。这是在编译时由min_cfs_rq_runtime变量配置的。这 +是一个性能调整，有助于防止对全局锁的额外争夺。 + +cpu-local分片不会过期的事实导致了一些有趣的罕见案例，应该被理解。 + +对于cgroup cpu限制的应用程序来说，这是一个相对有意义的问题，因为他们自然会消耗他们的全部配 +额，以及每个cpu-本地片在每个时期的全部。因此，预计nr_periods大致等于nr_throttled，并且 +cpuacct.用量的增加大致等于cfs_quota_us在每个周期的增加。 + +对于高线程、非cpu绑定的应用程序，这种非过期的细微差别允许应用程序短暂地突破他们的配额限制， +即任务组正在运行的每个cpu上未使用的片断量（通常每个cpu最多1ms或由min_cfs_rq_runtime定 +义）。这种轻微的突发只适用于配额已经分配给cpu，然后没有完全使用或在以前的时期返回。这个突发 +量不会在核心之间转移。因此，这种机制仍然严格限制任务组的配额平均使用量，尽管是在比单一时期更 +长的时间窗口。这也限制了突发能力，每个cpu不超过1ms。这为在高核数机器上有小配额限制的高线程 +应用提供了更好的更可预测的用户体验。它还消除了在使用低于配额的cpu时对这些应用进行节流的倾向。 +另一种说法是，通过允许一个片断的未使用部分在不同时期保持有效，我们减少了在不需要整个片断的cpu +时间的cpu-local 筒仓上浪费配额的可能性。 + +绑定cpu和非绑定cpu的交互式应用之间的互动也应该被考虑，特别是当单核使用率达到100%时。如果你 +给了这些应用程序一半的cpu-core，并且它们都被安排在同一个CPU上，理论上非cpu绑定的应用程序有 +可能在某些时期使用多达1ms的额外配额，从而阻止cpu绑定的应用程序完全使用其配额，这也是同样的数 +量。在这些情况下，将由CFS算法（见CFS调度器）来决定选择哪个应用程序来运行，因为它们都是可运行 +的，并且有剩余的配额。这个运行时间的差异将在接下来的交互式应用程序空闲期间得到弥补。 + +例子 +---- +1. 限制一个组的运行时间为1个CPU的价值:: + + 如果周期是250ms，配额也是250ms，那么该组将每250ms获得价值1个CPU的运行时间。 + + # echo 250000 > cpu.cfs_quota_us /* quota = 250ms */ + # echo 250000 > cpu.cfs_period_us /* period = 250ms */ + +2. 在多CPU机器上，将一个组的运行时间限制为2个CPU的价值 + + 在500ms周期和1000ms配额的情况下，该组每500ms可以获得2个CPU的运行时间:: + + # echo 1000000 > cpu.cfs_quota_us /* quota = 1000ms */ + # echo 500000 > cpu.cfs_period_us /* period = 500ms */ + + 这里较大的周期允许增加突发能力。 + +3. 将一个组限制在1个CPU的20%。 + + 在50ms周期内，10ms配额将相当于1个CPU的20%。:: + + # echo 10000 > cpu.cfs_quota_us /* quota = 10ms */ + # echo 50000 > cpu.cfs_period_us /* period = 50ms */ + + 通过在这里使用一个小的周期，我们以牺牲突发容量为代价来确保稳定的延迟响应。 + +4. 将一个组限制在1个CPU的40%，并允许累积到1个CPU的20%，如果已经累积了的话。 + + 在50ms周期内，20ms配额将相当于1个CPU的40%。而10毫秒的突发将相当于1个 + CPU的20%:: + + # echo 20000 > cpu.cfs_quota_us /* quota = 20ms */ + # echo 50000 > cpu.cfs_period_us /* period = 50ms */ + # echo 10000 > cpu.cfs_burst_us /* burst = 10ms */ + + 较大的缓冲区设置（不大于配额）允许更大的突发容量。 diff --git a/Documentation/translations/zh_CN/scheduler/sched-capacity.rst b/Documentation/translations/zh_CN/scheduler/sched-capacity.rst new file mode 100644 index 000000000000..3a52053c29dc --- /dev/null +++ b/Documentation/translations/zh_CN/scheduler/sched-capacity.rst @@ -0,0 +1,390 @@ +.. SPDX-License-Identifier: GPL-2.0 +.. include:: ../disclaimer-zh_CN.rst + +:Original: Documentation/scheduler/sched-capacity.rst + +:翻译: + + 唐艺舟 Tang Yizhou <tangyeechou@gmail.com> + +:校译: + + 时奎亮 Alex Shi <alexs@kernel.org> + +============= +算力感知调度 +============= + +1. CPU算力 +========== + +1.1 简介 +-------- + +一般来说，同构的SMP平台由完全相同的CPU构成。异构的平台则由性能特征不同的CPU构成，在这样的 +平台中，CPU不能被认为是相同的。 + +我们引入CPU算力（capacity）的概念来测量每个CPU能达到的性能，它的值相对系统中性能最强的CPU +做过归一化处理。异构系统也被称为非对称CPU算力系统，因为它们由不同算力的CPU组成。 + +最大可达性能（换言之，最大CPU算力）的差异有两个主要来源: + +- 不是所有CPU的微架构都相同。 +- 在动态电压频率升降（Dynamic Voltage and Frequency Scaling，DVFS）框架中，不是所有的CPU都 + 能达到一样高的操作性能值（Operating Performance Points，OPP。译注，也就是“频率-电压”对）。 + +Arm大小核（big.LITTLE）系统是同时具有两种差异的一个例子。相较小核，大核面向性能（拥有更多的 +流水线层级，更大的缓存，更智能的分支预测器等），通常可以达到更高的操作性能值。 + +CPU性能通常由每秒百万指令（Millions of Instructions Per Second，MIPS）表示，也可表示为 +per Hz能执行的指令数，故:: + + capacity(cpu) = work_per_hz(cpu) * max_freq(cpu) + +1.2 调度器术语 +-------------- + +调度器使用了两种不同的算力值。CPU的 ``capacity_orig`` 是它的最大可达算力，即最大可达性能等级。 +CPU的 ``capacity`` 是 ``capacity_orig`` 扣除了一些性能损失（比如处理中断的耗时）的值。 + +注意CPU的 ``capacity`` 仅仅被设计用于CFS调度类，而 ``capacity_orig`` 是不感知调度类的。为 +简洁起见，本文档的剩余部分将不加区分的使用术语 ``capacity`` 和 ``capacity_orig`` 。 + +1.3 平台示例 +------------ + +1.3.1 操作性能值相同 +~~~~~~~~~~~~~~~~~~~~ + +考虑一个假想的双核非对称CPU算力系统，其中 + +- work_per_hz(CPU0) = W +- work_per_hz(CPU1) = W/2 +- 所有CPU以相同的固定频率运行 + +根据上文对算力的定义: + +- capacity(CPU0) = C +- capacity(CPU1) = C/2 + +若这是Arm大小核系统，那么CPU0是大核，而CPU1是小核。 + +考虑一种周期性产生固定工作量的工作负载，你将会得到类似下图的执行轨迹:: + + CPU0 work ^ + | ____ ____ ____ + | | | | | | | + +----+----+----+----+----+----+----+----+----+----+-> time + + CPU1 work ^ + | _________ _________ ____ + | | | | | | + +----+----+----+----+----+----+----+----+----+----+-> time + +CPU0在系统中具有最高算力（C），它使用T个单位时间完成固定工作量W。另一方面，CPU1只有CPU0一半 +算力，因此在T个单位时间内仅完成工作量W/2。 + +1.3.2 最大操作性能值不同 +~~~~~~~~~~~~~~~~~~~~~~~~ + +具有不同算力值的CPU，通常来说最大操作性能值也不同。考虑上一小节提到的CPU（也就是说， +work_per_hz()相同）: + +- max_freq(CPU0) = F +- max_freq(CPU1) = 2/3 * F + +这将推出： + +- capacity(CPU0) = C +- capacity(CPU1) = C/3 + +执行1.3.1节描述的工作负载，每个CPU按最大频率运行，结果为:: + + CPU0 work ^ + | ____ ____ ____ + | | | | | | | + +----+----+----+----+----+----+----+----+----+----+-> time + + workload on CPU1 + CPU1 work ^ + | ______________ ______________ ____ + | | | | | | + +----+----+----+----+----+----+----+----+----+----+-> time + +1.4 关于计算方式的注意事项 +-------------------------- + +需要注意的是，使用单一值来表示CPU性能的差异是有些争议的。两个不同的微架构的相对性能差异应该 +描述为：X%整数运算差异，Y%浮点数运算差异，Z%分支跳转差异，等等。尽管如此，使用简单计算方式 +的结果目前还是令人满意的。 + +2. 任务使用率 +============= + +2.1 简介 +-------- + +算力感知调度要求描述任务需求，描述方式要和CPU算力相关。每个调度类可以用不同的方式描述它。 +任务使用率是CFS独有的描述方式，不过在这里介绍它有助于引入更多一般性的概念。 + +任务使用率是一种用百分比来描述任务吞吐率需求的方式。一个简单的近似是任务的占空比，也就是说:: + + task_util(p) = duty_cycle(p) + +在频率固定的SMP系统中，100%的利用率意味着任务是忙等待循环。反之，10%的利用率暗示这是一个 +小周期任务，它在睡眠上花费的时间比执行更多。 + +2.2 频率不变性 +-------------- + +一个需要考虑的议题是，工作负载的占空比受CPU正在运行的操作性能值直接影响。考虑以给定的频率F +执行周期性工作负载:: + + CPU work ^ + | ____ ____ ____ + | | | | | | | + +----+----+----+----+----+----+----+----+----+----+-> time + +可以算出 duty_cycle(p) == 25%。 + +现在，考虑以给定频率F/2执行 *同一个* 工作负载:: + + CPU work ^ + | _________ _________ ____ + | | | | | | + +----+----+----+----+----+----+----+----+----+----+-> time + +可以算出 duty_cycle(p) == 50%，尽管两次执行中，任务的行为完全一致（也就是说，执行的工作量 +相同）。 + +任务利用率信号可按下面公式处理成频率不变的（译注：这里的术语用到了信号与系统的概念）:: + + task_util_freq_inv(p) = duty_cycle(p) * (curr_frequency(cpu) / max_frequency(cpu)) + +对上面两个例子运用该公式，可以算出频率不变的任务利用率均为25%。 + +2.3 CPU不变性 +------------- + +CPU算力与任务利用率具有类型的效应，在算力不同的CPU上执行完全相同的工作负载，将算出不同的 +占空比。 + +考虑1.3.2节提到的系统，也就是说:: + +- capacity(CPU0) = C +- capacity(CPU1) = C/3 + +每个CPU按最大频率执行指定周期性工作负载，结果为:: + + CPU0 work ^ + | ____ ____ ____ + | | | | | | | + +----+----+----+----+----+----+----+----+----+----+-> time + + CPU1 work ^ + | ______________ ______________ ____ + | | | | | | + +----+----+----+----+----+----+----+----+----+----+-> time + +也就是说， + +- duty_cycle(p) == 25%，如果任务p在CPU0上按最大频率运行。 +- duty_cycle(p) == 75%，如果任务p在CPU1上按最大频率运行。 + +任务利用率信号可按下面公式处理成CPU算力不变的:: + + task_util_cpu_inv(p) = duty_cycle(p) * (capacity(cpu) / max_capacity) + +其中 ``max_capacity`` 是系统中最高的CPU算力。对上面的例子运用该公式，可以算出CPU算力不变 +的任务利用率均为25%。 + +2.4 任务利用率不变量 +-------------------- + +频率和CPU算力不变性都需要被应用到任务利用率的计算中，以便求出真正的不变信号。 +任务利用率的伪计算公式是同时具备CPU和频率不变性的，也就是说，对于指定任务p:: + + curr_frequency(cpu) capacity(cpu) + task_util_inv(p) = duty_cycle(p) * ------------------- * ------------- + max_frequency(cpu) max_capacity + +也就是说，任务利用率不变量假定任务在系统中最高算力CPU上以最高频率运行，以此描述任务的行为。 + +在接下来的章节中提到的任何任务利用率，均是不变量的形式。 + +2.5 利用率估算 +-------------- + +由于预测未来的水晶球不存在，当任务第一次变成可运行时，任务的行为和任务利用率均不能被准确预测。 +CFS调度类基于实体负载跟踪机制（Per-Entity Load Tracking, PELT）维护了少量CPU和任务信号， +其中之一可以算出平均利用率（与瞬时相反）。 + +这意味着，尽管运用“真实的”任务利用率（凭借水晶球）写出算力感知调度的准则，但是它的实现将只能 +用任务利用率的估算值。 + +3. 算力感知调度的需求 +===================== + +3.1 CPU算力 +----------- + +当前，Linux无法凭自身算出CPU算力，因此必须要有把这个信息传递给Linux的方式。每个架构必须为此 +定义arch_scale_cpu_capacity()函数。 + +arm和arm64架构直接把这个信息映射到arch_topology驱动的CPU scaling数据中（译注：参考 +arch_topology.h的percpu变量cpu_scale），它是从capacity-dmips-mhz CPU binding中衍生计算 +出来的。参见Documentation/devicetree/bindings/arm/cpu-capacity.txt。 + +3.2 频率不变性 +-------------- + +如2.2节所述，算力感知调度需要频率不变的任务利用率。每个架构必须为此定义 +arch_scale_freq_capacity(cpu)函数。 + +实现该函数要求计算出每个CPU当前以什么频率在运行。实现它的一种方式是利用硬件计数器（x86的 +APERF/MPERF，arm64的AMU），它能按CPU当前频率动态可扩展地升降递增计数器的速率。另一种方式是 +在cpufreq频率变化时直接使用钩子函数，内核此时感知到将要被切换的频率（也被arm/arm64实现了）。 + +4. 调度器拓扑结构 +================= + +在构建调度域时，调度器将会发现系统是否表现为非对称CPU算力。如果是，那么： + +- sched_asym_cpucapacity静态键（static key）将使能。 +- SD_ASYM_CPUCAPACITY_FULL标志位将在尽量最低调度域层级中被设置，同时要满足条件：调度域恰好 + 完整包含某个CPU算力值的全部CPU。 +- SD_ASYM_CPUCAPACITY标志将在所有包含非对称CPU的调度域中被设置。 + +sched_asym_cpucapacity静态键的设计意图是，保护为非对称CPU算力系统所准备的代码。不过要注意的 +是，这个键是系统范围可见的。想象下面使用了cpuset的步骤:: + + capacity C/2 C + ________ ________ + / \ / \ + CPUs 0 1 2 3 4 5 6 7 + \__/ \______________/ + cpusets cs0 cs1 + +可以通过下面的方式创建： + +.. code-block:: sh + + mkdir /sys/fs/cgroup/cpuset/cs0 + echo 0-1 > /sys/fs/cgroup/cpuset/cs0/cpuset.cpus + echo 0 > /sys/fs/cgroup/cpuset/cs0/cpuset.mems + + mkdir /sys/fs/cgroup/cpuset/cs1 + echo 2-7 > /sys/fs/cgroup/cpuset/cs1/cpuset.cpus + echo 0 > /sys/fs/cgroup/cpuset/cs1/cpuset.mems + + echo 0 > /sys/fs/cgroup/cpuset/cpuset.sched_load_balance + +由于“这是”非对称CPU算力系统，sched_asym_cpucapacity静态键将使能。然而，CPU 0--1对应的 +调度域层级，算力值仅有一个，该层级中SD_ASYM_CPUCAPACITY未被设置，它描述的是一个SMP区域，也 +应该被以此处理。 + +因此，“典型的”保护非对称CPU算力代码路径的代码模式是： + +- 检查sched_asym_cpucapacity静态键 +- 如果它被使能，接着检查调度域层级中SD_ASYM_CPUCAPACITY标志位是否出现 + +5. 算力感知调度的实现 +===================== + +5.1 CFS +------- + +5.1.1 算力适应性（fitness） +~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +CFS最主要的算力调度准则是:: + + task_util(p) < capacity(task_cpu(p)) + +它通常被称为算力适应性准则。也就是说，CFS必须保证任务“适合”在某个CPU上运行。如果准则被违反， +任务将要更长地消耗该CPU，任务是CPU受限的（CPU-bound）。 + +此外，uclamp允许用户空间指定任务的最小和最大利用率，要么以sched_setattr()的方式，要么以 +cgroup接口的方式（参阅Documentation/admin-guide/cgroup-v2.rst）。如其名字所暗示，uclamp +可以被用在前一条准则中限制task_util()。 + +5.1.2 被唤醒任务的CPU选择 +~~~~~~~~~~~~~~~~~~~~~~~~~ + +CFS任务唤醒的CPU选择，遵循上面描述的算力适应性准则。在此之上，uclamp被用来限制任务利用率， +这令用户空间对CFS任务的CPU选择有更多的控制。也就是说，CFS被唤醒任务的CPU选择，搜索满足以下 +条件的CPU:: + + clamp(task_util(p), task_uclamp_min(p), task_uclamp_max(p)) < capacity(cpu) + +通过使用uclamp，举例来说，用户空间可以允许忙等待循环（100%使用率）在任意CPU上运行，只要给 +它设置低的uclamp.max值。相反，uclamp能强制一个小的周期性任务（比如，10%利用率）在最高性能 +的CPU上运行，只要给它设置高的uclamp.min值。 + +.. note:: + + CFS的被唤醒的任务的CPU选择，可被能耗感知调度（Energy Aware Scheduling，EAS）覆盖，在 + Documentation/scheduler/sched-energy.rst中描述。 + +5.1.3 负载均衡 +~~~~~~~~~~~~~~ + +被唤醒任务的CPU选择的一个病理性的例子是，任务几乎不睡眠，那么也几乎不发生唤醒。考虑:: + + w == wakeup event + + capacity(CPU0) = C + capacity(CPU1) = C / 3 + + workload on CPU0 + CPU work ^ + | _________ _________ ____ + | | | | | | + +----+----+----+----+----+----+----+----+----+----+-> time + w w w + + workload on CPU1 + CPU work ^ + | ____________________________________________ + | | + +----+----+----+----+----+----+----+----+----+----+-> + w + +该工作负载应该在CPU0上运行，不过如果任务满足以下条件之一： + +- 一开始发生不合适的调度（不准确的初始利用率估计） +- 一开始调度正确，但突然需要更多的处理器功率 + +则任务可能变为CPU受限的，也就是说 ``task_util(p) > capacity(task_cpu(p))`` ；CPU算力 +调度准则被违反，将不会有任何唤醒事件来修复这个错误的CPU选择。 + +这种场景下的任务被称为“不合适的”（misfit）任务，处理这个场景的机制同样也以此命名。Misfit +任务迁移借助CFS负载均衡器，更明确的说，是主动负载均衡的部分（用来迁移正在运行的任务）。 +当发生负载均衡时，如果一个misfit任务可以被迁移到一个相较当前运行的CPU具有更高算力的CPU上， +那么misfit任务的主动负载均衡将被触发。 + +5.2 实时调度 +------------ + +5.2.1 被唤醒任务的CPU选择 +~~~~~~~~~~~~~~~~~~~~~~~~~ + +实时任务唤醒时的CPU选择，搜索满足以下条件的CPU:: + + task_uclamp_min(p) <= capacity(task_cpu(cpu)) + +同时仍然允许接着使用常规的优先级限制。如果没有CPU能满足这个算力准则，那么将使用基于严格 +优先级的调度，CPU算力将被忽略。 + +5.3 最后期限调度 +---------------- + +5.3.1 被唤醒任务的CPU选择 +~~~~~~~~~~~~~~~~~~~~~~~~~ + +最后期限任务唤醒时的CPU选择，搜索满足以下条件的CPU:: + + task_bandwidth(p) < capacity(task_cpu(p)) + +同时仍然允许接着使用常规的带宽和截止期限限制。如果没有CPU能满足这个算力准则，那么任务依然 +在当前CPU队列中。 diff --git a/Documentation/translations/zh_CN/scheduler/sched-design-CFS.rst b/Documentation/translations/zh_CN/scheduler/sched-design-CFS.rst new file mode 100644 index 000000000000..26b0f36f793d --- /dev/null +++ b/Documentation/translations/zh_CN/scheduler/sched-design-CFS.rst @@ -0,0 +1,205 @@ +.. SPDX-License-Identifier: GPL-2.0 +.. include:: ../disclaimer-zh_CN.rst + +:Original: Documentation/scheduler/sched-design-CFS.rst + +:翻译: + + 唐艺舟 Tang Yizhou <tangyeechou@gmail.com> + +=============== +完全公平调度器 +=============== + + +1. 概述 +======= + +CFS表示“完全公平调度器”，它是为桌面新设计的进程调度器，由Ingo Molnar实现并合入Linux +2.6.23。它替代了之前原始调度器中SCHED_OTHER策略的交互式代码。 + +CFS 80%的设计可以总结为一句话：CFS在真实硬件上建模了一个“理想的，精确的多任务CPU”。 + +“理想的多任务CPU”是一种（不存在的 :-)）具有100%物理算力的CPU，它能让每个任务精确地以 +相同的速度并行运行，速度均为1/nr_running。举例来说，如果有两个任务正在运行，那么每个 +任务获得50%物理算力。 --- 也就是说，真正的并行。 + +在真实的硬件上，一次只能运行一个任务，所以我们需要介绍“虚拟运行时间”的概念。任务的虚拟 +运行时间表明，它的下一个时间片将在上文描述的理想多任务CPU上开始执行。在实践中，任务的 +虚拟运行时间由它的真实运行时间相较正在运行的任务总数归一化计算得到。 + + + +2. 一些实现细节 +=============== + +在CFS中，虚拟运行时间由每个任务的p->se.vruntime（单位为纳秒）的值表达和跟踪。因此， +精确地计时和测量一个任务应得的“预期的CPU时间”是可能的。 + + 一些细节：在“理想的”硬件上，所有的任务在任何时刻都应该具有一样的p->se.vruntime值， + --- 也就是说，任务应当同时执行，没有任务会在“理想的”CPU分时中变得“不平衡”。 + +CFS的任务选择逻辑基于p->se.vruntime的值，因此非常简单：总是试图选择p->se.vruntime值 +最小的任务运行（也就是说，至今执行时间最少的任务）。CFS总是尽可能尝试按“理想多任务硬件” +那样将CPU时间在可运行任务中均分。 + +CFS剩下的其它设计，一般脱离了这个简单的概念，附加的设计包括nice级别，多处理，以及各种 +用来识别已睡眠任务的算法变体。 + + + +3. 红黑树 +========= + +CFS的设计非常激进：它不使用运行队列的旧数据结构，而是使用按时间排序的红黑树，构建出 +任务未来执行的“时间线”。因此没有任何“数组切换”的旧包袱（之前的原始调度器和RSDL/SD都 +被它影响）。 + +CFS同样维护了rq->cfs.min_vruntime值，它是单调递增的，跟踪运行队列中的所有任务的最小 +虚拟运行时间值。系统做的全部工作是：使用min_vruntime跟踪，然后用它的值将新激活的调度 +实体尽可能地放在红黑树的左侧。 + +运行队列中正在运行的任务的总数由rq->cfs.load计数，它是运行队列中的任务的权值之和。 + +CFS维护了一个按时间排序的红黑树，所有可运行任务以p->se.vruntime为键值排序。CFS从这颗 +树上选择“最左侧”的任务并运行。系统继续运行，被执行过的任务越来越被放到树的右侧 --- 缓慢， +但很明确每个任务都有成为“最左侧任务”的机会，因此任务将确定性地获得一定量CPU时间。 + +总结一下，CFS工作方式像这样：它运行一个任务一会儿，当任务发生调度（或者调度器时钟滴答 +tick产生），就会考虑任务的CPU使用率：任务刚刚花在物理CPU上的（少量）时间被加到 +p->se.vruntime。一旦p->se.vruntime变得足够大，其它的任务将成为按时间排序的红黑树的 +“最左侧任务”（相较最左侧的任务，还要加上一个很小的“粒度”量，使得我们不会对任务过度调度， +导致缓存颠簸），然后新的最左侧任务将被选中，当前任务被抢占。 + + + + +4. CFS的一些特征 +================ + +CFS使用纳秒粒度的计时，不依赖于任何jiffies或HZ的细节。因此CFS并不像之前的调度器那样 +有“时间片”的概念，也没有任何启发式的设计。唯一可调的参数（你需要打开CONFIG_SCHED_DEBUG）是： + + /proc/sys/kernel/sched_min_granularity_ns + +它可以用来将调度器从“桌面”模式（也就是低时延）调节为“服务器”（也就是高批处理）模式。 +它的默认设置是适合桌面的工作负载。SCHED_BATCH也被CFS调度器模块处理。 + +CFS的设计不易受到当前存在的任何针对stock调度器的“攻击”的影响，包括fiftyp.c，thud.c， +chew.c，ring-test.c，massive_intr.c，它们都能很好地运行，不会影响交互性，将产生 +符合预期的行为。 + +CFS调度器处理nice级别和SCHED_BATCH的能力比之前的原始调度器更强：两种类型的工作负载 +都被更激进地隔离了。 + +SMP负载均衡被重做/清理过：遍历运行队列的假设已经从负载均衡的代码中移除，使用调度模块 +的迭代器。结果是，负载均衡代码变得简单不少。 + + + +5. 调度策略 +=========== + +CFS实现了三种调度策略： + + - SCHED_NORMAL：（传统被称为SCHED_OTHER）：该调度策略用于普通任务。 + + - SCHED_BATCH：抢占不像普通任务那样频繁，因此允许任务运行更长时间，更好地利用缓存， + 不过要以交互性为代价。它很适合批处理工作。 + + - SCHED_IDLE：它比nice 19更弱，不过它不是真正的idle定时器调度器，因为要避免给机器 + 带来死锁的优先级反转问题。 + +SCHED_FIFO/_RR被实现在sched/rt.c中，它们由POSIX具体说明。 + +util-linux-ng 2.13.1.1中的chrt命令可以设置以上所有策略，除了SCHED_IDLE。 + + + +6. 调度类 +========= + +新的CFS调度器被设计成支持“调度类”，一种调度模块的可扩展层次结构。这些模块封装了调度策略 +细节，由调度器核心代码处理，且无需对它们做太多假设。 + +sched/fair.c 实现了上文描述的CFS调度器。 + +sched/rt.c 实现了SCHED_FIFO和SCHED_RR语义，且比之前的原始调度器更简洁。它使用了100个 +运行队列（总共100个实时优先级，替代了之前调度器的140个），且不需要过期数组（expired +array）。 + +调度类由sched_class结构体实现，它包括一些函数钩子，当感兴趣的事件发生时，钩子被调用。 + +这是（部分）钩子的列表： + + - enqueue_task(...) + + 当任务进入可运行状态时，被调用。它将调度实体（任务）放到红黑树中，增加nr_running变量 + 的值。 + + - dequeue_task(...) + + 当任务不再可运行时，这个函数被调用，对应的调度实体被移出红黑树。它减少nr_running变量 + 的值。 + + - yield_task(...) + + 这个函数的行为基本上是出队，紧接着入队，除非compat_yield sysctl被开启。在那种情况下， + 它将调度实体放在红黑树的最右端。 + + - check_preempt_curr(...) + + 这个函数检查进入可运行状态的任务能否抢占当前正在运行的任务。 + + - pick_next_task(...) + + 这个函数选择接下来最适合运行的任务。 + + - set_curr_task(...) + + 这个函数在任务改变调度类或改变任务组时被调用。 + + - task_tick(...) + + 这个函数最常被时间滴答函数调用，它可能导致进程切换。这驱动了运行时抢占。 + + + + +7. CFS的组调度扩展 +================== + +通常，调度器操作粒度为任务，努力为每个任务提供公平的CPU时间。有时可能希望将任务编组， +并为每个组提供公平的CPU时间。举例来说，可能首先希望为系统中的每个用户提供公平的CPU +时间，接下来才是某个用户的每个任务。 + +CONFIG_CGROUP_SCHED 力求实现它。它将任务编组，并为这些组公平地分配CPU时间。 + +CONFIG_RT_GROUP_SCHED 允许将实时（也就是说，SCHED_FIFO和SCHED_RR）任务编组。 + +CONFIG_FAIR_GROUP_SCHED 允许将CFS（也就是说，SCHED_NORMAL和SCHED_BATCH）任务编组。 + + 这些编译选项要求CONFIG_CGROUPS被定义，然后管理员能使用cgroup伪文件系统任意创建任务组。 + 关于该文件系统的更多信息，参见Documentation/admin-guide/cgroup-v1/cgroups.rst + +当CONFIG_FAIR_GROUP_SCHED被定义后，通过伪文件系统，每个组被创建一个“cpu.shares”文件。 +参见下面的例子来创建任务组，并通过“cgroup”伪文件系统修改它们的CPU份额:: + + # mount -t tmpfs cgroup_root /sys/fs/cgroup + # mkdir /sys/fs/cgroup/cpu + # mount -t cgroup -ocpu none /sys/fs/cgroup/cpu + # cd /sys/fs/cgroup/cpu + + # mkdir multimedia # 创建 "multimedia" 任务组 + # mkdir browser # 创建 "browser" 任务组 + + # #配置multimedia组，令其获得browser组两倍CPU带宽 + + # echo 2048 > multimedia/cpu.shares + # echo 1024 > browser/cpu.shares + + # firefox & # 启动firefox并把它移到 "browser" 组 + # echo <firefox_pid> > browser/tasks + + # #启动gmplayer（或者你最喜欢的电影播放器） + # echo <movie_player_pid> > multimedia/tasks diff --git a/Documentation/translations/zh_CN/scheduler/sched-domains.rst b/Documentation/translations/zh_CN/scheduler/sched-domains.rst new file mode 100644 index 000000000000..e814d4c01141 --- /dev/null +++ b/Documentation/translations/zh_CN/scheduler/sched-domains.rst @@ -0,0 +1,72 @@ +.. SPDX-License-Identifier: GPL-2.0 +.. include:: ../disclaimer-zh_CN.rst + +:Original: Documentation/scheduler/sched-domains.rst + +:翻译: + + 唐艺舟 Tang Yizhou <tangyeechou@gmail.com> + +:校译: + + 司延腾 Yanteng Si <siyanteng@loongson.cn> + +====== +调度域 +====== + +每个CPU有一个“基”调度域（struct sched_domain）。调度域层次结构从基调度域构建而来，可 +通过->parent指针自下而上遍历。->parent必须以NULL结尾，调度域结构体必须是per-CPU的， +因为它们无锁更新。 + +每个调度域管辖数个CPU（存储在->span字段中）。一个调度域的span必须是它的子调度域span的 +超集（如有需求出现，这个限制可以放宽）。CPU i的基调度域必须至少管辖CPU i。每个CPU的 +顶层调度域通常将会管辖系统中的全部CPU，尽管严格来说这不是必须的，假如是这样，会导致某些 +CPU出现永远不会被指定任务运行的情况，直到允许的CPU掩码被显式设定。调度域的span字段意味 +着“在这些CPU中做进程负载均衡”。 + +每个调度域必须具有一个或多个CPU调度组（struct sched_group），它们以单向循环链表的形式 +组织，存储在->groups指针中。这些组的CPU掩码的并集必须和调度域span字段一致。->groups +指针指向的这些组包含的CPU，必须被调度域管辖。组包含的是只读数据，被创建之后，可能被多个 +CPU共享。任意两个组的CPU掩码的交集不一定为空，如果是这种情况，对应调度域的SD_OVERLAP +标志位被设置，它管辖的调度组可能不能在多个CPU中共享。 + +调度域中的负载均衡发生在调度组中。也就是说，每个组被视为一个实体。组的负载被定义为它 +管辖的每个CPU的负载之和。仅当组的负载不均衡后，任务才在组之间发生迁移。 + +在kernel/sched/core.c中，trigger_load_balance()在每个CPU上通过scheduler_tick() +周期执行。在当前运行队列下一个定期调度再平衡事件到达后，它引发一个软中断。负载均衡真正 +的工作由run_rebalance_domains()->rebalance_domains()完成，在软中断上下文中执行 +（SCHED_SOFTIRQ）。 + +后一个函数有两个入参：当前CPU的运行队列、它在scheduler_tick()调用时是否空闲。函数会从 +当前CPU所在的基调度域开始迭代执行，并沿着parent指针链向上进入更高层级的调度域。在迭代 +过程中，函数会检查当前调度域是否已经耗尽了再平衡的时间间隔，如果是，它在该调度域运行 +load_balance()。接下来它检查父调度域（如果存在），再后来父调度域的父调度域，以此类推。 + +起初，load_balance()查找当前调度域中最繁忙的调度组。如果成功，在该调度组管辖的全部CPU +的运行队列中找出最繁忙的运行队列。如能找到，对当前的CPU运行队列和新找到的最繁忙运行 +队列均加锁，并把任务从最繁忙队列中迁移到当前CPU上。被迁移的任务数量等于在先前迭代执行 +中计算出的该调度域的调度组的不均衡值。 + +实现调度域 +========== + +基调度域会管辖CPU层次结构中的第一层。对于超线程（SMT）而言，基调度域将会管辖同一个物理 +CPU的全部虚拟CPU，每个虚拟CPU对应一个调度组。 + +在SMP中，基调度域的父调度域将会管辖同一个结点中的全部物理CPU，每个调度组对应一个物理CPU。 +接下来，如果是非统一内存访问（NUMA）系统，SMP调度域的父调度域将管辖整个机器，一个结点的 +CPU掩码对应一个调度组。亦或，你可以使用多级NUMA；举例来说Opteron处理器，可能仅用一个 +调度域来覆盖它的一个NUMA层级。 + +实现者需要阅读include/linux/sched/sd_flags.h的注释：读SD_*来了解具体情况以及调度域的 +SD标志位调节了哪些东西。 + +体系结构可以把指定的拓扑层级的通用调度域构建器和默认的SD标志位覆盖掉，方法是创建一个 +sched_domain_topology_level数组，并以该数组作为入参调用set_sched_topology()。 + +调度域调试基础设施可以通过CONFIG_SCHED_DEBUG开启，并在开机启动命令行中增加 +“sched_verbose”。如果你忘记调整开机启动命令行了，也可以打开 +/sys/kernel/debug/sched/verbose开关。这将开启调度域错误检查的解析，它应该能捕获（上文 +描述过的）绝大多数错误，同时以可视化格式打印调度域的结构。 diff --git a/Documentation/translations/zh_TW/process/submitting-patches.rst b/Documentation/translations/zh_TW/process/submitting-patches.rst index 37eccf9e2746..c4fd48f5bd8b 100644 --- a/Documentation/translations/zh_TW/process/submitting-patches.rst +++ b/Documentation/translations/zh_TW/process/submitting-patches.rst @@ -257,30 +257,6 @@ Linus Torvalds 是決定改動能否進入 Linux 內核的最終裁決者。他 手冊頁補丁，或至少發送更改通知，以便一些信息進入手冊頁。還應將用戶空間API 更改複製到 linux-api@vger.kernel.org。 -對於小的補丁，你也許會CC到搜集瑣碎補丁的郵件列表(Trivial Patch Monkey) -trivial@kernel.org，那裡專門收集瑣碎的補丁。下面這樣的補丁會被看作「瑣碎的」 -補丁： - - - 文檔的拼寫修正。 - - 修正會影響到 grep(1) 的拼寫。 - - 警告信息修正(頻繁的列印無用的警告是不好的。) - - 編譯錯誤修正（代碼邏輯的確是對的，只是編譯有問題。） - - 運行時修正（只要真的修正了錯誤。） - - 移除使用了被廢棄的函數/宏的代碼(例如 check_region。) - - 聯繫方式和文檔修正。 - - 用可移植的代碼替換不可移植的代碼（即使在體系結構相關的代碼中，既然有 - - 人拷貝，只要它是瑣碎的） - - 任何文件的作者/維護者對該文件的改動（例如 patch monkey 在重傳模式下） - -(譯註，關於「瑣碎補丁」的一些說明：因爲原文的這一部分寫得比較簡單，所以不得不 -違例寫一下譯註。"trivial"這個英文單詞的本意是「瑣碎的，不重要的。」但是在這裡 -有稍微有一些變化，例如對一些明顯的NULL指針的修正，屬於運行時修正，會被歸類 -到瑣碎補丁里。雖然NULL指針的修正很重要，但是這樣的修正往往很小而且很容易得到 -檢驗，所以也被歸入瑣碎補丁。瑣碎補丁更精確的歸類應該是 -「simple, localized & easy to verify」，也就是說簡單的，局部的和易於檢驗的。 -trivial@kernel.org郵件列表的目的是針對這樣的補丁，爲提交者提供一個中心，來 -降低提交的門檻。) - 6) 沒有 MIME 編碼，沒有連結，沒有壓縮，沒有附件，只有純文本 ----------------------------------------------------------- diff --git a/Documentation/tty/index.rst b/Documentation/tty/index.rst new file mode 100644 index 000000000000..21ea0cb21e55 --- /dev/null +++ b/Documentation/tty/index.rst @@ -0,0 +1,63 @@ +.. SPDX-License-Identifier: GPL-2.0 + +=== +TTY +=== + +Teletypewriter (TTY) layer takes care of all those serial devices. Including +the virtual ones like pseudoterminal (PTY). + +TTY structures +============== + +There are several major TTY structures. Every TTY device in a system has a +corresponding struct tty_port. These devices are maintained by a TTY driver +which is struct tty_driver. This structure describes the driver but also +contains a reference to operations which could be performed on the TTYs. It is +struct tty_operations. Then, upon open, a struct tty_struct is allocated and +lives until the final close. During this time, several callbacks from struct +tty_operations are invoked by the TTY layer. + +Every character received by the kernel (both from devices and users) is passed +through a preselected :doc:`tty_ldisc` (in +short ldisc; in C, struct tty_ldisc_ops). Its task is to transform characters +as defined by a particular ldisc or by user too. The default one is n_tty, +implementing echoes, signal handling, jobs control, special characters +processing, and more. The transformed characters are passed further to +user/device, depending on the source. + +In-detail description of the named TTY structures is in separate documents: + +.. toctree:: + :maxdepth: 2 + + tty_driver + tty_port + tty_struct + tty_ldisc + tty_buffer + n_tty + tty_internals + +Writing TTY Driver +================== + +Before one starts writing a TTY driver, they must consider +:doc:`Serial <../driver-api/serial/driver>` and :doc:`USB Serial +<../usb/usb-serial>` layers +first. Drivers for serial devices can often use one of these specific layers to +implement a serial driver. Only special devices should be handled directly by +the TTY Layer. If you are about to write such a driver, read on. + +A *typical* sequence a TTY driver performs is as follows: + +#. Allocate and register a TTY driver (module init) +#. Create and register TTY devices as they are probed (probe function) +#. Handle TTY operations and events like interrupts (TTY core invokes the + former, the device the latter) +#. Remove devices as they are going away (remove function) +#. Unregister and free the TTY driver (module exit) + +Steps regarding driver, i.e. 1., 3., and 5. are described in detail in +:doc:`tty_driver`. For the other two (devices handling), look into +:doc:`tty_port`. diff --git a/Documentation/tty/n_tty.rst b/Documentation/tty/n_tty.rst new file mode 100644 index 000000000000..15b70faee72d --- /dev/null +++ b/Documentation/tty/n_tty.rst @@ -0,0 +1,22 @@ +.. SPDX-License-Identifier: GPL-2.0 + +===== +N_TTY +===== + +.. contents:: :local: + +The default (and fallback) :doc:`TTY line discipline <tty_ldisc>`. It tries to +handle characters as per POSIX. + +External Functions +================== + +.. kernel-doc:: drivers/tty/n_tty.c + :export: + +Internal Functions +================== + +.. kernel-doc:: drivers/tty/n_tty.c + :internal: diff --git a/Documentation/tty/tty_buffer.rst b/Documentation/tty/tty_buffer.rst new file mode 100644 index 000000000000..a39d4781e0d2 --- /dev/null +++ b/Documentation/tty/tty_buffer.rst @@ -0,0 +1,46 @@ +.. SPDX-License-Identifier: GPL-2.0 + +========== +TTY Buffer +========== + +.. contents:: :local: + +Here, we document functions for taking care of tty buffer and their flipping. +Drivers are supposed to fill the buffer by one of those functions below and +then flip the buffer, so that the data are passed to :doc:`line discipline +<tty_ldisc>` for further processing. + +Flip Buffer Management +====================== + +.. kernel-doc:: drivers/tty/tty_buffer.c + :identifiers: tty_prepare_flip_string tty_insert_flip_string_fixed_flag + tty_insert_flip_string_flags __tty_insert_flip_char + tty_flip_buffer_push tty_ldisc_receive_buf + +---- + +Other Functions +=============== + +.. kernel-doc:: drivers/tty/tty_buffer.c + :identifiers: tty_buffer_space_avail tty_buffer_set_limit + +---- + +Buffer Locking +============== + +These are used only in special circumstances. Avoid them. + +.. kernel-doc:: drivers/tty/tty_buffer.c + :identifiers: tty_buffer_lock_exclusive tty_buffer_unlock_exclusive + +---- + +Internal Functions +================== + +.. kernel-doc:: drivers/tty/tty_buffer.c + :internal: diff --git a/Documentation/tty/tty_driver.rst b/Documentation/tty/tty_driver.rst new file mode 100644 index 000000000000..cc529f863406 --- /dev/null +++ b/Documentation/tty/tty_driver.rst @@ -0,0 +1,128 @@ +.. SPDX-License-Identifier: GPL-2.0 + +============================= +TTY Driver and TTY Operations +============================= + +.. contents:: :local: + +Allocation +========== + +The first thing a driver needs to do is to allocate a struct tty_driver. This +is done by tty_alloc_driver() (or __tty_alloc_driver()). Next, the newly +allocated structure is filled with information. See `TTY Driver Reference`_ at +the end of this document on what actually shall be filled in. + +The allocation routines expect a number of devices the driver can handle at +most and flags. Flags are those starting ``TTY_DRIVER_`` listed and described +in `TTY Driver Flags`_ below. + +When the driver is about to be freed, tty_driver_kref_put() is called on that. +It will decrements the reference count and if it reaches zero, the driver is +freed. + +For reference, both allocation and deallocation functions are explained here in +detail: + +.. kernel-doc:: drivers/tty/tty_io.c + :identifiers: __tty_alloc_driver tty_driver_kref_put + +TTY Driver Flags +---------------- + +Here comes the documentation of flags accepted by tty_alloc_driver() (or +__tty_alloc_driver()): + +.. kernel-doc:: include/linux/tty_driver.h + :doc: TTY Driver Flags + +---- + +Registration +============ + +When a struct tty_driver is allocated and filled in, it can be registered using +tty_register_driver(). It is recommended to pass ``TTY_DRIVER_DYNAMIC_DEV`` in +flags of tty_alloc_driver(). If it is not passed, *all* devices are also +registered during tty_register_driver() and the following paragraph of +registering devices can be skipped for such drivers. However, the struct +tty_port part in `Registering Devices`_ is still relevant there. + +.. kernel-doc:: drivers/tty/tty_io.c + :identifiers: tty_register_driver tty_unregister_driver + +Registering Devices +------------------- + +Every TTY device shall be backed by a struct tty_port. Usually, TTY drivers +embed tty_port into device's private structures. Further details about handling +tty_port can be found in :doc:`tty_port`. The driver is also recommended to use +tty_port's reference counting by tty_port_get() and tty_port_put(). The final +put is supposed to free the tty_port including the device's private struct. + +Unless ``TTY_DRIVER_DYNAMIC_DEV`` was passed as flags to tty_alloc_driver(), +TTY driver is supposed to register every device discovered in the system +(the latter is preferred). This is performed by tty_register_device(). Or by +tty_register_device_attr() if the driver wants to expose some information +through struct attribute_group. Both of them register ``index``'th device and +upon return, the device can be opened. There are also preferred tty_port +variants described in `Linking Devices to Ports`_ later. It is up to driver to +manage free indices and choosing the right one. The TTY layer only refuses to +register more devices than passed to tty_alloc_driver(). + +When the device is opened, the TTY layer allocates struct tty_struct and starts +calling operations from :c:member:`tty_driver.ops`, see `TTY Operations +Reference`_. + +The registration routines are documented as follows: + +.. kernel-doc:: drivers/tty/tty_io.c + :identifiers: tty_register_device tty_register_device_attr + tty_unregister_device + +---- + +Linking Devices to Ports +------------------------ +As stated earlier, every TTY device shall have a struct tty_port assigned to +it. It must be known to the TTY layer at :c:member:`tty_driver.ops.install()` +at latest. There are few helpers to *link* the two. Ideally, the driver uses +tty_port_register_device() or tty_port_register_device_attr() instead of +tty_register_device() and tty_register_device_attr() at the registration time. +This way, the driver needs not care about linking later on. + +If that is not possible, the driver still can link the tty_port to a specific +index *before* the actual registration by tty_port_link_device(). If it still +does not fit, tty_port_install() can be used from the +:c:member:`tty_driver.ops.install` hook as a last resort. The last one is +dedicated mostly for in-memory devices like PTY where tty_ports are allocated +on demand. + +The linking routines are documented here: + +.. kernel-doc:: drivers/tty/tty_port.c + :identifiers: tty_port_link_device tty_port_register_device + tty_port_register_device_attr + +---- + +TTY Driver Reference +==================== + +All members of struct tty_driver are documented here. The required members are +noted at the end. struct tty_operations are documented next. + +.. kernel-doc:: include/linux/tty_driver.h + :identifiers: tty_driver + +---- + +TTY Operations Reference +======================== + +When a TTY is registered, these driver hooks can be invoked by the TTY layer: + +.. kernel-doc:: include/linux/tty_driver.h + :identifiers: tty_operations + diff --git a/Documentation/tty/tty_internals.rst b/Documentation/tty/tty_internals.rst new file mode 100644 index 000000000000..d0d415820300 --- /dev/null +++ b/Documentation/tty/tty_internals.rst @@ -0,0 +1,31 @@ +.. SPDX-License-Identifier: GPL-2.0 + +============= +TTY Internals +============= + +.. contents:: :local: + +Kopen +===== + +These functions serve for opening a TTY from the kernelspace: + +.. kernel-doc:: drivers/tty/tty_io.c + :identifiers: tty_kopen_exclusive tty_kopen_shared tty_kclose + +---- + +Exported Internal Functions +=========================== + +.. kernel-doc:: drivers/tty/tty_io.c + :identifiers: tty_release_struct tty_dev_name_to_number tty_get_icount + +---- + +Internal Functions +================== + +.. kernel-doc:: drivers/tty/tty_io.c + :internal: diff --git a/Documentation/tty/tty_ldisc.rst b/Documentation/tty/tty_ldisc.rst new file mode 100644 index 000000000000..5144751be804 --- /dev/null +++ b/Documentation/tty/tty_ldisc.rst @@ -0,0 +1,85 @@ +.. SPDX-License-Identifier: GPL-2.0 + +=================== +TTY Line Discipline +=================== + +.. contents:: :local: + +TTY line discipline process all incoming and outgoing character from/to a tty +device. The default line discipline is :doc:`N_TTY <n_tty>`. It is also a +fallback if establishing any other discipline for a tty fails. If even N_TTY +fails, N_NULL takes over. That never fails, but also does not process any +characters -- it throws them away. + +Registration +============ + +Line disciplines are registered with tty_register_ldisc() passing the ldisc +structure. At the point of registration the discipline must be ready to use and +it is possible it will get used before the call returns success. If the call +returns an error then it won’t get called. Do not re-use ldisc numbers as they +are part of the userspace ABI and writing over an existing ldisc will cause +demons to eat your computer. You must not re-register over the top of the line +discipline even with the same data or your computer again will be eaten by +demons. In order to remove a line discipline call tty_unregister_ldisc(). + +Heed this warning: the reference count field of the registered copies of the +tty_ldisc structure in the ldisc table counts the number of lines using this +discipline. The reference count of the tty_ldisc structure within a tty counts +the number of active users of the ldisc at this instant. In effect it counts +the number of threads of execution within an ldisc method (plus those about to +enter and exit although this detail matters not). + +.. kernel-doc:: drivers/tty/tty_ldisc.c + :identifiers: tty_register_ldisc tty_unregister_ldisc + +Other Functions +=============== + +.. kernel-doc:: drivers/tty/tty_ldisc.c + :identifiers: tty_set_ldisc tty_ldisc_flush + +Line Discipline Operations Reference +==================================== + +.. kernel-doc:: include/linux/tty_ldisc.h + :identifiers: tty_ldisc_ops + +Driver Access +============= + +Line discipline methods can call the methods of the underlying hardware driver. +These are documented as a part of struct tty_operations. + +TTY Flags +========= + +Line discipline methods have access to :c:member:`tty_struct.flags` field. See +:doc:`tty_struct`. + +Locking +======= + +Callers to the line discipline functions from the tty layer are required to +take line discipline locks. The same is true of calls from the driver side +but not yet enforced. + +.. kernel-doc:: drivers/tty/tty_ldisc.c + :identifiers: tty_ldisc_ref_wait tty_ldisc_ref tty_ldisc_deref + +While these functions are slightly slower than the old code they should have +minimal impact as most receive logic uses the flip buffers and they only +need to take a reference when they push bits up through the driver. + +A caution: The :c:member:`tty_ldisc_ops.open()`, +:c:member:`tty_ldisc_ops.close()` and :c:member:`tty_driver.set_ldisc()` +functions are called with the ldisc unavailable. Thus tty_ldisc_ref() will fail +in this situation if used within these functions. Ldisc and driver code +calling its own functions must be careful in this case. + +Internal Functions +================== + +.. kernel-doc:: drivers/tty/tty_ldisc.c + :internal: diff --git a/Documentation/tty/tty_port.rst b/Documentation/tty/tty_port.rst new file mode 100644 index 000000000000..5cb90e954fcf --- /dev/null +++ b/Documentation/tty/tty_port.rst @@ -0,0 +1,70 @@ +.. SPDX-License-Identifier: GPL-2.0 + +======== +TTY Port +======== + +.. contents:: :local: + +The TTY drivers are advised to use struct tty_port helpers as much as possible. +If the drivers implement :c:member:`tty_port.ops.activate()` and +:c:member:`tty_port.ops.shutdown()`, they can use tty_port_open(), +tty_port_close(), and tty_port_hangup() in respective +:c:member:`tty_struct.ops` hooks. + +The reference and details are contained in the `TTY Port Reference`_ and `TTY +Port Operations Reference`_ sections at the bottom. + +TTY Port Functions +================== + +Init & Destroy +-------------- + +.. kernel-doc:: drivers/tty/tty_port.c + :identifiers: tty_port_init tty_port_destroy + tty_port_get tty_port_put + +Open/Close/Hangup Helpers +------------------------- + +.. kernel-doc:: drivers/tty/tty_port.c + :identifiers: tty_port_install tty_port_open tty_port_block_til_ready + tty_port_close tty_port_close_start tty_port_close_end tty_port_hangup + tty_port_shutdown + +TTY Refcounting +--------------- + +.. kernel-doc:: drivers/tty/tty_port.c + :identifiers: tty_port_tty_get tty_port_tty_set + +TTY Helpers +----------- + +.. kernel-doc:: drivers/tty/tty_port.c + :identifiers: tty_port_tty_hangup tty_port_tty_wakeup + + +Modem Signals +------------- + +.. kernel-doc:: drivers/tty/tty_port.c + :identifiers: tty_port_carrier_raised tty_port_raise_dtr_rts + tty_port_lower_dtr_rts + +---- + +TTY Port Reference +================== + +.. kernel-doc:: include/linux/tty_port.h + :identifiers: tty_port + +---- + +TTY Port Operations Reference +============================= + +.. kernel-doc:: include/linux/tty_port.h + :identifiers: tty_port_operations diff --git a/Documentation/tty/tty_struct.rst b/Documentation/tty/tty_struct.rst new file mode 100644 index 000000000000..c72f5a4293b2 --- /dev/null +++ b/Documentation/tty/tty_struct.rst @@ -0,0 +1,81 @@ +.. SPDX-License-Identifier: GPL-2.0 + +========== +TTY Struct +========== + +.. contents:: :local: + +struct tty_struct is allocated by the TTY layer upon the first open of the TTY +device and released after the last close. The TTY layer passes this structure +to most of struct tty_operation's hooks. Members of tty_struct are documented +in `TTY Struct Reference`_ at the bottom. + +Initialization +============== + +.. kernel-doc:: drivers/tty/tty_io.c + :identifiers: tty_init_termios + +Name +==== + +.. kernel-doc:: drivers/tty/tty_io.c + :identifiers: tty_name + +Reference counting +================== + +.. kernel-doc:: include/linux/tty.h + :identifiers: tty_kref_get + +.. kernel-doc:: drivers/tty/tty_io.c + :identifiers: tty_kref_put + +Install +======= + +.. kernel-doc:: drivers/tty/tty_io.c + :identifiers: tty_standard_install + +Read & Write +============ + +.. kernel-doc:: drivers/tty/tty_io.c + :identifiers: tty_put_char + +Start & Stop +============ + +.. kernel-doc:: drivers/tty/tty_io.c + :identifiers: start_tty stop_tty + +Wakeup +====== + +.. kernel-doc:: drivers/tty/tty_io.c + :identifiers: tty_wakeup + +Hangup +====== + +.. kernel-doc:: drivers/tty/tty_io.c + :identifiers: tty_hangup tty_vhangup tty_hung_up_p + +Misc +==== + +.. kernel-doc:: drivers/tty/tty_io.c + :identifiers: tty_do_resize + +TTY Struct Flags +================ + +.. kernel-doc:: include/linux/tty.h + :doc: TTY Struct Flags + +TTY Struct Reference +==================== + +.. kernel-doc:: include/linux/tty.h + :identifiers: tty_struct diff --git a/Documentation/usb/gadget-testing.rst b/Documentation/usb/gadget-testing.rst index c18113077889..cbbd948c626f 100644 --- a/Documentation/usb/gadget-testing.rst +++ b/Documentation/usb/gadget-testing.rst @@ -931,7 +931,7 @@ The uac1 function provides these attributes in its function directory: p_volume_min playback volume control min value (in 1/256 dB) p_volume_max playback volume control max value (in 1/256 dB) p_volume_res playback volume control resolution (in 1/256 dB) - req_number the number of pre-allocated request for both capture + req_number the number of pre-allocated requests for both capture and playback ================ ==================================================== diff --git a/Documentation/userspace-api/ioctl/ioctl-number.rst b/Documentation/userspace-api/ioctl/ioctl-number.rst index cfe6cccf0f44..687efcf245c1 100644 --- a/Documentation/userspace-api/ioctl/ioctl-number.rst +++ b/Documentation/userspace-api/ioctl/ioctl-number.rst @@ -367,6 +367,7 @@ Code Seq# Include File Comments <mailto:aherrman@de.ibm.com> 0xE5 00-3F linux/fuse.h 0xEC 00-01 drivers/platform/chrome/cros_ec_dev.h ChromeOS EC driver +0xEE 00-09 uapi/linux/pfrut.h Platform Firmware Runtime Update and Telemetry 0xF3 00-3F drivers/usb/misc/sisusbvga/sisusb.h sisfb (in development) <mailto:thomas@winischhofer.net> 0xF6 all LTTng Linux Trace Toolkit Next Generation diff --git a/Documentation/userspace-api/media/cec/cec-ioc-receive.rst b/Documentation/userspace-api/media/cec/cec-ioc-receive.rst index bd7f7e7235cb..364938ad34df 100644 --- a/Documentation/userspace-api/media/cec/cec-ioc-receive.rst +++ b/Documentation/userspace-api/media/cec/cec-ioc-receive.rst @@ -48,9 +48,12 @@ it will return -1 and set errno to the ``ETIMEDOUT`` error code. A received message can be: 1. a message received from another CEC device (the ``sequence`` field will - be 0). -2. the result of an earlier non-blocking transmit (the ``sequence`` field will - be non-zero). + be 0, ``tx_status`` will be 0 and ``rx_status`` will be non-zero). +2. the transmit result of an earlier non-blocking transmit (the ``sequence`` + field will be non-zero, ``tx_status`` will be non-zero and ``rx_status`` + will be 0). +3. the reply to an earlier non-blocking transmit (the ``sequence`` field will + be non-zero, ``tx_status`` will be 0 and ``rx_status`` will be non-zero). To send a CEC message the application has to fill in the struct :c:type:`cec_msg` and pass it to :ref:`ioctl CEC_TRANSMIT <CEC_TRANSMIT>`. @@ -64,12 +67,11 @@ idea to fully fill up the transmit queue. If the file descriptor is in non-blocking mode then the transmit will return 0 and the result of the transmit will be available via -:ref:`ioctl CEC_RECEIVE <CEC_RECEIVE>` once the transmit has finished -(including waiting for a reply, if requested). - -The ``sequence`` field is filled in for every transmit and this can be -checked against the received messages to find the corresponding transmit -result. +:ref:`ioctl CEC_RECEIVE <CEC_RECEIVE>` once the transmit has finished. +If a non-blocking transmit also specified waiting for a reply, then +the reply will arrive in a later message. The ``sequence`` field can +be used to associate both transmit results and replies with the original +transmit. Normally calling :ref:`ioctl CEC_TRANSMIT <CEC_TRANSMIT>` when the physical address is invalid (due to e.g. a disconnect) will return ``ENONET``. @@ -123,18 +125,17 @@ View On' messages from initiator 0xf ('Unregistered') to destination 0 ('TV'). - ``sequence`` - A non-zero sequence number is automatically assigned by the CEC framework for all transmitted messages. It is used by the CEC framework when it queues - the transmit result (when transmit was called in non-blocking mode). This - allows the application to associate the received message with the original - transmit. + the transmit result for a non-blocking transmit. This allows the application + to associate the received message with the original transmit. + + In addition, if a non-blocking transmit will wait for a reply (ii.e. ``timeout`` + was not 0), then the ``sequence`` field of the reply will be set to the sequence + value of the original transmit. This allows the application to associate the + received message with the original transmit. * - __u32 - ``flags`` - Flags. See :ref:`cec-msg-flags` for a list of available flags. * - __u8 - - ``tx_status`` - - The status bits of the transmitted message. See - :ref:`cec-tx-status` for the possible status values. It is 0 if - this message was received, not transmitted. - * - __u8 - ``msg[16]`` - The message payload. For :ref:`ioctl CEC_TRANSMIT <CEC_TRANSMIT>` this is filled in by the application. The driver will fill this in for :ref:`ioctl CEC_RECEIVE <CEC_RECEIVE>`. @@ -162,15 +163,17 @@ View On' messages from initiator 0xf ('Unregistered') to destination 0 ('TV'). * - __u8 - ``rx_status`` - The status bits of the received message. See - :ref:`cec-rx-status` for the possible status values. It is 0 if - this message was transmitted, not received, unless this is the - reply to a transmitted message. In that case both ``rx_status`` - and ``tx_status`` are set. + :ref:`cec-rx-status` for the possible status values. * - __u8 - ``tx_status`` - The status bits of the transmitted message. See - :ref:`cec-tx-status` for the possible status values. It is 0 if - this message was received, not transmitted. + :ref:`cec-tx-status` for the possible status values. + When calling :ref:`ioctl CEC_TRANSMIT <CEC_TRANSMIT>` in non-blocking mode, + this field will be 0 if the transmit started, or non-0 if the transmit + result is known immediately. The latter would be the case when attempting + to transmit a Poll message to yourself. That results in a + :ref:`CEC_TX_STATUS_NACK <CEC-TX-STATUS-NACK>` without ever actually + transmitting the Poll message. * - __u8 - ``tx_arb_lost_cnt`` - A counter of the number of transmit attempts that resulted in the diff --git a/Documentation/userspace-api/media/lirc.h.rst.exceptions b/Documentation/userspace-api/media/lirc.h.rst.exceptions index e74b73cd0e9e..ec86e82d026d 100644 --- a/Documentation/userspace-api/media/lirc.h.rst.exceptions +++ b/Documentation/userspace-api/media/lirc.h.rst.exceptions @@ -33,6 +33,7 @@ ignore define LIRC_CAN_SET_REC_DUTY_CYCLE # Obsolete ioctls ignore ioctl LIRC_GET_LENGTH +ignore ioctl LIRC_SET_REC_TIMEOUT_REPORTS # rc protocols @@ -73,6 +74,7 @@ ignore define PULSE_MASK ignore define LIRC_MODE2_SPACE ignore define LIRC_MODE2_PULSE +ignore define LIRC_MODE2_TIMEOUT ignore define LIRC_VALUE_MASK ignore define LIRC_MODE2_MASK diff --git a/Documentation/userspace-api/media/rc/lirc-dev-intro.rst b/Documentation/userspace-api/media/rc/lirc-dev-intro.rst index c88973732282..9a5e5f0aae11 100644 --- a/Documentation/userspace-api/media/rc/lirc-dev-intro.rst +++ b/Documentation/userspace-api/media/rc/lirc-dev-intro.rst @@ -117,11 +117,9 @@ on the following table. ``LIRC_MODE2_TIMEOUT`` - If timeout reports are enabled with - :ref:`lirc_set_rec_timeout_reports`, when the timeout set with - :ref:`lirc_set_rec_timeout` expires due to no IR being detected, - this packet will be sent, with the number of microseconds with - no IR. + When the timeout set with :ref:`lirc_set_rec_timeout` expires due + to no IR being detected, this packet will be sent, with the number + of microseconds with no IR. .. _lirc-mode-pulse: diff --git a/Documentation/userspace-api/media/rc/lirc-func.rst b/Documentation/userspace-api/media/rc/lirc-func.rst index 793f295d3ac9..5c84888f1eca 100644 --- a/Documentation/userspace-api/media/rc/lirc-func.rst +++ b/Documentation/userspace-api/media/rc/lirc-func.rst @@ -22,6 +22,5 @@ LIRC Function Reference lirc-set-rec-carrier-range lirc-set-send-carrier lirc-set-transmitter-mask - lirc-set-rec-timeout-reports lirc-set-measure-carrier-mode lirc-set-wideband-receiver diff --git a/Documentation/userspace-api/media/rc/lirc-set-rec-timeout-reports.rst b/Documentation/userspace-api/media/rc/lirc-set-rec-timeout-reports.rst deleted file mode 100644 index aebe81012939..000000000000 --- a/Documentation/userspace-api/media/rc/lirc-set-rec-timeout-reports.rst +++ /dev/null @@ -1,49 +0,0 @@ -.. SPDX-License-Identifier: GPL-2.0 OR GFDL-1.1-no-invariants-or-later -.. c:namespace:: RC - -.. _lirc_set_rec_timeout_reports: - -********************************** -ioctl LIRC_SET_REC_TIMEOUT_REPORTS -********************************** - -Name -==== - -LIRC_SET_REC_TIMEOUT_REPORTS - enable or disable timeout reports for IR receive - -Synopsis -======== - -.. c:macro:: LIRC_SET_REC_TIMEOUT_REPORTS - -``int ioctl(int fd, LIRC_SET_REC_TIMEOUT_REPORTS, __u32 *enable)`` - -Arguments -========= - -``fd`` - File descriptor returned by open(). - -``enable`` - enable = 1 means enable timeout report, enable = 0 means disable timeout - reports. - -Description -=========== - -.. _lirc-mode2-timeout: - -Enable or disable timeout reports for IR receive. By default, timeout reports -should be turned off. - -.. note:: - - This ioctl is only valid for :ref:`LIRC_MODE_MODE2 <lirc-mode-mode2>`. - -Return Value -============ - -On success 0 is returned, on error -1 and the ``errno`` variable is set -appropriately. The generic error codes are described at the -:ref:`Generic Error Codes <gen-errors>` chapter. diff --git a/Documentation/userspace-api/media/v4l/biblio.rst b/Documentation/userspace-api/media/v4l/biblio.rst index 7b8e6738ff9e..9cd18c153d19 100644 --- a/Documentation/userspace-api/media/v4l/biblio.rst +++ b/Documentation/userspace-api/media/v4l/biblio.rst @@ -417,3 +417,13 @@ VP8 :title: RFC 6386: "VP8 Data Format and Decoding Guide" :author: J. Bankoski et al. + +.. _vp9: + +VP9 +=== + + +:title: VP9 Bitstream & Decoding Process Specification + +:author: Adrian Grange (Google), Peter de Rivaz (Argon Design), Jonathan Hunt (Argon Design) diff --git a/Documentation/userspace-api/media/v4l/capture.c.rst b/Documentation/userspace-api/media/v4l/capture.c.rst index ccbd52c3897f..eef6772967a1 100644 --- a/Documentation/userspace-api/media/v4l/capture.c.rst +++ b/Documentation/userspace-api/media/v4l/capture.c.rst @@ -56,7 +56,7 @@ file: media/v4l/capture.c static void errno_exit(const char *s) { - fprintf(stderr, "%s error %d, %s\\n", s, errno, strerror(errno)); + fprintf(stderr, "%s error %d, %s\n", s, errno, strerror(errno)); exit(EXIT_FAILURE); } @@ -201,7 +201,7 @@ file: media/v4l/capture.c } if (0 == r) { - fprintf(stderr, "select timeout\\n"); + fprintf(stderr, "select timeout\n"); exit(EXIT_FAILURE); } @@ -307,7 +307,7 @@ file: media/v4l/capture.c buffers = calloc(1, sizeof(*buffers)); if (!buffers) { - fprintf(stderr, "Out of memory\\n"); + fprintf(stderr, "Out of memory\n"); exit(EXIT_FAILURE); } @@ -315,7 +315,7 @@ file: media/v4l/capture.c buffers[0].start = malloc(buffer_size); if (!buffers[0].start) { - fprintf(stderr, "Out of memory\\n"); + fprintf(stderr, "Out of memory\n"); exit(EXIT_FAILURE); } } @@ -341,7 +341,7 @@ file: media/v4l/capture.c } if (req.count < 2) { - fprintf(stderr, "Insufficient buffer memory on %s\\n", + fprintf(stderr, "Insufficient buffer memory on %s\n", dev_name); exit(EXIT_FAILURE); } @@ -349,7 +349,7 @@ file: media/v4l/capture.c buffers = calloc(req.count, sizeof(*buffers)); if (!buffers) { - fprintf(stderr, "Out of memory\\n"); + fprintf(stderr, "Out of memory\n"); exit(EXIT_FAILURE); } @@ -401,7 +401,7 @@ file: media/v4l/capture.c buffers = calloc(4, sizeof(*buffers)); if (!buffers) { - fprintf(stderr, "Out of memory\\n"); + fprintf(stderr, "Out of memory\n"); exit(EXIT_FAILURE); } @@ -410,7 +410,7 @@ file: media/v4l/capture.c buffers[n_buffers].start = malloc(buffer_size); if (!buffers[n_buffers].start) { - fprintf(stderr, "Out of memory\\n"); + fprintf(stderr, "Out of memory\n"); exit(EXIT_FAILURE); } } @@ -426,7 +426,7 @@ file: media/v4l/capture.c if (-1 == xioctl(fd, VIDIOC_QUERYCAP, &cap)) { if (EINVAL == errno) { - fprintf(stderr, "%s is no V4L2 device\\n", + fprintf(stderr, "%s is no V4L2 device\n", dev_name); exit(EXIT_FAILURE); } else { @@ -435,7 +435,7 @@ file: media/v4l/capture.c } if (!(cap.capabilities & V4L2_CAP_VIDEO_CAPTURE)) { - fprintf(stderr, "%s is no video capture device\\n", + fprintf(stderr, "%s is no video capture device\n", dev_name); exit(EXIT_FAILURE); } @@ -443,7 +443,7 @@ file: media/v4l/capture.c switch (io) { case IO_METHOD_READ: if (!(cap.capabilities & V4L2_CAP_READWRITE)) { - fprintf(stderr, "%s does not support read i/o\\n", + fprintf(stderr, "%s does not support read i/o\n", dev_name); exit(EXIT_FAILURE); } @@ -452,7 +452,7 @@ file: media/v4l/capture.c case IO_METHOD_MMAP: case IO_METHOD_USERPTR: if (!(cap.capabilities & V4L2_CAP_STREAMING)) { - fprintf(stderr, "%s does not support streaming i/o\\n", + fprintf(stderr, "%s does not support streaming i/o\n", dev_name); exit(EXIT_FAILURE); } @@ -541,7 +541,7 @@ file: media/v4l/capture.c struct stat st; if (-1 == stat(dev_name, &st)) { - fprintf(stderr, "Cannot identify '%s': %d, %s\\n", + fprintf(stderr, "Cannot identify '%s': %d, %s\n", dev_name, errno, strerror(errno)); exit(EXIT_FAILURE); } @@ -554,7 +554,7 @@ file: media/v4l/capture.c fd = open(dev_name, O_RDWR /* required */ | O_NONBLOCK, 0); if (-1 == fd) { - fprintf(stderr, "Cannot open '%s': %d, %s\\n", + fprintf(stderr, "Cannot open '%s': %d, %s\n", dev_name, errno, strerror(errno)); exit(EXIT_FAILURE); } @@ -563,17 +563,17 @@ file: media/v4l/capture.c static void usage(FILE *fp, int argc, char **argv) { fprintf(fp, - "Usage: %s [options]\\n\\n" - "Version 1.3\\n" - "Options:\\n" - "-d | --device name Video device name [%s]n" - "-h | --help Print this messagen" - "-m | --mmap Use memory mapped buffers [default]n" - "-r | --read Use read() callsn" - "-u | --userp Use application allocated buffersn" - "-o | --output Outputs stream to stdoutn" - "-f | --format Force format to 640x480 YUYVn" - "-c | --count Number of frames to grab [%i]n" + "Usage: %s [options]\n\n" + "Version 1.3\n" + "Options:\n" + "-d | --device name Video device name [%s]\n" + "-h | --help Print this message\n" + "-m | --mmap Use memory mapped buffers [default]\n" + "-r | --read Use read() calls\n" + "-u | --userp Use application allocated buffers\n" + "-o | --output Outputs stream to stdout\n" + "-f | --format Force format to 640x480 YUYV\n" + "-c | --count Number of frames to grab [%i]\n" "", argv[0], dev_name, frame_count); } @@ -659,6 +659,6 @@ file: media/v4l/capture.c stop_capturing(); uninit_device(); close_device(); - fprintf(stderr, "\\n"); + fprintf(stderr, "\n"); return 0; } diff --git a/Documentation/userspace-api/media/v4l/control.rst b/Documentation/userspace-api/media/v4l/control.rst index f8d0b923da20..3eec65174260 100644 --- a/Documentation/userspace-api/media/v4l/control.rst +++ b/Documentation/userspace-api/media/v4l/control.rst @@ -242,8 +242,17 @@ Control IDs * - ``V4L2_COLORFX_SET_CBCR`` - The Cb and Cr chroma components are replaced by fixed coefficients determined by ``V4L2_CID_COLORFX_CBCR`` control. + * - ``V4L2_COLORFX_SET_RGB`` + - The RGB components are replaced by the fixed RGB components determined + by ``V4L2_CID_COLORFX_RGB`` control. +``V4L2_CID_COLORFX_RGB`` ``(integer)`` + Determines the Red, Green, and Blue coefficients for + ``V4L2_COLORFX_SET_RGB`` color effect. + Bits [7:0] of the supplied 32 bit value are interpreted as Blue component, + bits [15:8] as Green component, bits [23:16] as Red component, and + bits [31:24] must be zero. ``V4L2_CID_COLORFX_CBCR`` ``(integer)`` Determines the Cb and Cr coefficients for ``V4L2_COLORFX_SET_CBCR`` diff --git a/Documentation/userspace-api/media/v4l/dev-decoder.rst b/Documentation/userspace-api/media/v4l/dev-decoder.rst index 5b9b83feeceb..3cf2b496f2d0 100644 --- a/Documentation/userspace-api/media/v4l/dev-decoder.rst +++ b/Documentation/userspace-api/media/v4l/dev-decoder.rst @@ -752,6 +752,23 @@ available to dequeue. Specifically: buffers are out-of-order compared to the ``OUTPUT`` buffers): ``CAPTURE`` timestamps will not retain the order of ``OUTPUT`` timestamps. +.. note:: + + The backing memory of ``CAPTURE`` buffers that are used as reference frames + by the stream may be read by the hardware even after they are dequeued. + Consequently, the client should avoid writing into this memory while the + ``CAPTURE`` queue is streaming. Failure to observe this may result in + corruption of decoded frames. + + Similarly, when using a memory type other than ``V4L2_MEMORY_MMAP``, the + client should make sure that each ``CAPTURE`` buffer is always queued with + the same backing memory for as long as the ``CAPTURE`` queue is streaming. + The reason for this is that V4L2 buffer indices can be used by drivers to + identify frames. Thus, if the backing memory of a reference frame is + submitted under a different buffer ID, the driver may misidentify it and + decode a new frame into it while it is still in use, resulting in corruption + of the following frames. + During the decoding, the decoder may initiate one of the special sequences, as listed below. The sequences will result in the decoder returning all the ``CAPTURE`` buffers that originated from all the ``OUTPUT`` buffers processed diff --git a/Documentation/userspace-api/media/v4l/ext-ctrls-codec-stateless.rst b/Documentation/userspace-api/media/v4l/ext-ctrls-codec-stateless.rst index 72f5e85b4f34..cc080c4257d0 100644 --- a/Documentation/userspace-api/media/v4l/ext-ctrls-codec-stateless.rst +++ b/Documentation/userspace-api/media/v4l/ext-ctrls-codec-stateless.rst @@ -1458,3 +1458,576 @@ FWHT Flags .. raw:: latex \normalsize + +.. _v4l2-codec-stateless-vp9: + +``V4L2_CID_STATELESS_VP9_COMPRESSED_HDR (struct)`` + Stores VP9 probabilities updates as parsed from the current compressed frame + header. A value of zero in an array element means no update of the relevant + probability. Motion vector-related updates contain a new value or zero. All + other updates contain values translated with inv_map_table[] (see 6.3.5 in + :ref:`vp9`). + +.. c:type:: v4l2_ctrl_vp9_compressed_hdr + +.. tabularcolumns:: |p{1cm}|p{4.8cm}|p{11.4cm}| + +.. cssclass:: longtable + +.. flat-table:: struct v4l2_ctrl_vp9_compressed_hdr + :header-rows: 0 + :stub-columns: 0 + :widths: 1 1 2 + + * - __u8 + - ``tx_mode`` + - Specifies the TX mode. See :ref:`TX Mode <vp9_tx_mode>` for more details. + * - __u8 + - ``tx8[2][1]`` + - TX 8x8 probabilities delta. + * - __u8 + - ``tx16[2][2]`` + - TX 16x16 probabilities delta. + * - __u8 + - ``tx32[2][3]`` + - TX 32x32 probabilities delta. + * - __u8 + - ``coef[4][2][2][6][6][3]`` + - Coefficient probabilities delta. + * - __u8 + - ``skip[3]`` + - Skip probabilities delta. + * - __u8 + - ``inter_mode[7][3]`` + - Inter prediction mode probabilities delta. + * - __u8 + - ``interp_filter[4][2]`` + - Interpolation filter probabilities delta. + * - __u8 + - ``is_inter[4]`` + - Is inter-block probabilities delta. + * - __u8 + - ``comp_mode[5]`` + - Compound prediction mode probabilities delta. + * - __u8 + - ``single_ref[5][2]`` + - Single reference probabilities delta. + * - __u8 + - ``comp_ref[5]`` + - Compound reference probabilities delta. + * - __u8 + - ``y_mode[4][9]`` + - Y prediction mode probabilities delta. + * - __u8 + - ``uv_mode[10][9]`` + - UV prediction mode probabilities delta. + * - __u8 + - ``partition[16][3]`` + - Partition probabilities delta. + * - __u8 + - ``mv.joint[3]`` + - Motion vector joint probabilities delta. + * - __u8 + - ``mv.sign[2]`` + - Motion vector sign probabilities delta. + * - __u8 + - ``mv.classes[2][10]`` + - Motion vector class probabilities delta. + * - __u8 + - ``mv.class0_bit[2]`` + - Motion vector class0 bit probabilities delta. + * - __u8 + - ``mv.bits[2][10]`` + - Motion vector bits probabilities delta. + * - __u8 + - ``mv.class0_fr[2][2][3]`` + - Motion vector class0 fractional bit probabilities delta. + * - __u8 + - ``mv.fr[2][3]`` + - Motion vector fractional bit probabilities delta. + * - __u8 + - ``mv.class0_hp[2]`` + - Motion vector class0 high precision fractional bit probabilities delta. + * - __u8 + - ``mv.hp[2]`` + - Motion vector high precision fractional bit probabilities delta. + +.. _vp9_tx_mode: + +``TX Mode`` + +.. tabularcolumns:: |p{6.5cm}|p{0.5cm}|p{10.3cm}| + +.. flat-table:: + :header-rows: 0 + :stub-columns: 0 + :widths: 1 1 2 + + * - ``V4L2_VP9_TX_MODE_ONLY_4X4`` + - 0 + - Transform size is 4x4. + * - ``V4L2_VP9_TX_MODE_ALLOW_8X8`` + - 1 + - Transform size can be up to 8x8. + * - ``V4L2_VP9_TX_MODE_ALLOW_16X16`` + - 2 + - Transform size can be up to 16x16. + * - ``V4L2_VP9_TX_MODE_ALLOW_32X32`` + - 3 + - transform size can be up to 32x32. + * - ``V4L2_VP9_TX_MODE_SELECT`` + - 4 + - Bitstream contains the transform size for each block. + +See section '7.3.1 Tx mode semantics' of the :ref:`vp9` specification for more details. + +``V4L2_CID_STATELESS_VP9_FRAME (struct)`` + Specifies the frame parameters for the associated VP9 frame decode request. + This includes the necessary parameters for configuring a stateless hardware + decoding pipeline for VP9. The bitstream parameters are defined according + to :ref:`vp9`. + +.. c:type:: v4l2_ctrl_vp9_frame + +.. raw:: latex + + \small + +.. tabularcolumns:: |p{4.7cm}|p{5.5cm}|p{7.1cm}| + +.. cssclass:: longtable + +.. flat-table:: struct v4l2_ctrl_vp9_frame + :header-rows: 0 + :stub-columns: 0 + :widths: 1 1 2 + + * - struct :c:type:`v4l2_vp9_loop_filter` + - ``lf`` + - Loop filter parameters. See struct :c:type:`v4l2_vp9_loop_filter` for more details. + * - struct :c:type:`v4l2_vp9_quantization` + - ``quant`` + - Quantization parameters. See :c:type:`v4l2_vp9_quantization` for more details. + * - struct :c:type:`v4l2_vp9_segmentation` + - ``seg`` + - Segmentation parameters. See :c:type:`v4l2_vp9_segmentation` for more details. + * - __u32 + - ``flags`` + - Combination of V4L2_VP9_FRAME_FLAG_* flags. See :ref:`Frame Flags<vp9_frame_flags>`. + * - __u16 + - ``compressed_header_size`` + - Compressed header size in bytes. + * - __u16 + - ``uncompressed_header_size`` + - Uncompressed header size in bytes. + * - __u16 + - ``frame_width_minus_1`` + - Add 1 to get the frame width expressed in pixels. See section 7.2.3 in :ref:`vp9`. + * - __u16 + - ``frame_height_minus_1`` + - Add 1 to get the frame height expressed in pixels. See section 7.2.3 in :ref:`vp9`. + * - __u16 + - ``render_width_minus_1`` + - Add 1 to get the expected render width expressed in pixels. This is + not used during the decoding process but might be used by HW scalers to + prepare a frame that's ready for scanout. See section 7.2.4 in :ref:`vp9`. + * - __u16 + - render_height_minus_1 + - Add 1 to get the expected render height expressed in pixels. This is + not used during the decoding process but might be used by HW scalers to + prepare a frame that's ready for scanout. See section 7.2.4 in :ref:`vp9`. + * - __u64 + - ``last_frame_ts`` + - "last" reference buffer timestamp. + The timestamp refers to the ``timestamp`` field in + struct :c:type:`v4l2_buffer`. Use the :c:func:`v4l2_timeval_to_ns()` + function to convert the struct :c:type:`timeval` in struct + :c:type:`v4l2_buffer` to a __u64. + * - __u64 + - ``golden_frame_ts`` + - "golden" reference buffer timestamp. + The timestamp refers to the ``timestamp`` field in + struct :c:type:`v4l2_buffer`. Use the :c:func:`v4l2_timeval_to_ns()` + function to convert the struct :c:type:`timeval` in struct + :c:type:`v4l2_buffer` to a __u64. + * - __u64 + - ``alt_frame_ts`` + - "alt" reference buffer timestamp. + The timestamp refers to the ``timestamp`` field in + struct :c:type:`v4l2_buffer`. Use the :c:func:`v4l2_timeval_to_ns()` + function to convert the struct :c:type:`timeval` in struct + :c:type:`v4l2_buffer` to a __u64. + * - __u8 + - ``ref_frame_sign_bias`` + - a bitfield specifying whether the sign bias is set for a given + reference frame. See :ref:`Reference Frame Sign Bias<vp9_ref_frame_sign_bias>` + for more details. + * - __u8 + - ``reset_frame_context`` + - specifies whether the frame context should be reset to default values. See + :ref:`Reset Frame Context<vp9_reset_frame_context>` for more details. + * - __u8 + - ``frame_context_idx`` + - Frame context that should be used/updated. + * - __u8 + - ``profile`` + - VP9 profile. Can be 0, 1, 2 or 3. + * - __u8 + - ``bit_depth`` + - Component depth in bits. Can be 8, 10 or 12. Note that not all profiles + support 10 and/or 12 bits depths. + * - __u8 + - ``interpolation_filter`` + - Specifies the filter selection used for performing inter prediction. See + :ref:`Interpolation Filter<vp9_interpolation_filter>` for more details. + * - __u8 + - ``tile_cols_log2`` + - Specifies the base 2 logarithm of the width of each tile (where the + width is measured in units of 8x8 blocks). Shall be less than or equal + to 6. + * - __u8 + - ``tile_rows_log2`` + - Specifies the base 2 logarithm of the height of each tile (where the + height is measured in units of 8x8 blocks). + * - __u8 + - ``reference_mode`` + - Specifies the type of inter prediction to be used. See + :ref:`Reference Mode<vp9_reference_mode>` for more details. + * - __u8 + - ``reserved[7]`` + - Applications and drivers must set this to zero. + +.. raw:: latex + + \normalsize + +.. _vp9_frame_flags: + +``Frame Flags`` + +.. tabularcolumns:: |p{10.0cm}|p{1.2cm}|p{6.1cm}| + +.. flat-table:: + :header-rows: 0 + :stub-columns: 0 + :widths: 1 1 2 + + * - ``V4L2_VP9_FRAME_FLAG_KEY_FRAME`` + - 0x001 + - The frame is a key frame. + * - ``V4L2_VP9_FRAME_FLAG_SHOW_FRAME`` + - 0x002 + - The frame should be displayed. + * - ``V4L2_VP9_FRAME_FLAG_ERROR_RESILIENT`` + - 0x004 + - The decoding should be error resilient. + * - ``V4L2_VP9_FRAME_FLAG_INTRA_ONLY`` + - 0x008 + - The frame does not reference other frames. + * - ``V4L2_VP9_FRAME_FLAG_ALLOW_HIGH_PREC_MV`` + - 0x010 + - The frame can use high precision motion vectors. + * - ``V4L2_VP9_FRAME_FLAG_REFRESH_FRAME_CTX`` + - 0x020 + - Frame context should be updated after decoding. + * - ``V4L2_VP9_FRAME_FLAG_PARALLEL_DEC_MODE`` + - 0x040 + - Parallel decoding is used. + * - ``V4L2_VP9_FRAME_FLAG_X_SUBSAMPLING`` + - 0x080 + - Vertical subsampling is enabled. + * - ``V4L2_VP9_FRAME_FLAG_Y_SUBSAMPLING`` + - 0x100 + - Horizontal subsampling is enabled. + * - ``V4L2_VP9_FRAME_FLAG_COLOR_RANGE_FULL_SWING`` + - 0x200 + - The full UV range is used. + +.. _vp9_ref_frame_sign_bias: + +``Reference Frame Sign Bias`` + +.. tabularcolumns:: |p{7.0cm}|p{1.2cm}|p{9.1cm}| + +.. flat-table:: + :header-rows: 0 + :stub-columns: 0 + :widths: 1 1 2 + + * - ``V4L2_VP9_SIGN_BIAS_LAST`` + - 0x1 + - Sign bias is set for the last reference frame. + * - ``V4L2_VP9_SIGN_BIAS_GOLDEN`` + - 0x2 + - Sign bias is set for the golden reference frame. + * - ``V4L2_VP9_SIGN_BIAS_ALT`` + - 0x2 + - Sign bias is set for the alt reference frame. + +.. _vp9_reset_frame_context: + +``Reset Frame Context`` + +.. tabularcolumns:: |p{7.0cm}|p{1.2cm}|p{9.1cm}| + +.. flat-table:: + :header-rows: 0 + :stub-columns: 0 + :widths: 1 1 2 + + * - ``V4L2_VP9_RESET_FRAME_CTX_NONE`` + - 0 + - Do not reset any frame context. + * - ``V4L2_VP9_RESET_FRAME_CTX_SPEC`` + - 1 + - Reset the frame context pointed to by + :c:type:`v4l2_ctrl_vp9_frame`.frame_context_idx. + * - ``V4L2_VP9_RESET_FRAME_CTX_ALL`` + - 2 + - Reset all frame contexts. + +See section '7.2 Uncompressed header semantics' of the :ref:`vp9` specification +for more details. + +.. _vp9_interpolation_filter: + +``Interpolation Filter`` + +.. tabularcolumns:: |p{9.0cm}|p{1.2cm}|p{7.1cm}| + +.. flat-table:: + :header-rows: 0 + :stub-columns: 0 + :widths: 1 1 2 + + * - ``V4L2_VP9_INTERP_FILTER_EIGHTTAP`` + - 0 + - Eight tap filter. + * - ``V4L2_VP9_INTERP_FILTER_EIGHTTAP_SMOOTH`` + - 1 + - Eight tap smooth filter. + * - ``V4L2_VP9_INTERP_FILTER_EIGHTTAP_SHARP`` + - 2 + - Eeight tap sharp filter. + * - ``V4L2_VP9_INTERP_FILTER_BILINEAR`` + - 3 + - Bilinear filter. + * - ``V4L2_VP9_INTERP_FILTER_SWITCHABLE`` + - 4 + - Filter selection is signaled at the block level. + +See section '7.2.7 Interpolation filter semantics' of the :ref:`vp9` specification +for more details. + +.. _vp9_reference_mode: + +``Reference Mode`` + +.. tabularcolumns:: |p{9.6cm}|p{0.5cm}|p{7.2cm}| + +.. flat-table:: + :header-rows: 0 + :stub-columns: 0 + :widths: 1 1 2 + + * - ``V4L2_VP9_REFERENCE_MODE_SINGLE_REFERENCE`` + - 0 + - Indicates that all the inter blocks use only a single reference frame + to generate motion compensated prediction. + * - ``V4L2_VP9_REFERENCE_MODE_COMPOUND_REFERENCE`` + - 1 + - Requires all the inter blocks to use compound mode. Single reference + frame prediction is not allowed. + * - ``V4L2_VP9_REFERENCE_MODE_SELECT`` + - 2 + - Allows each individual inter block to select between single and + compound prediction modes. + +See section '7.3.6 Frame reference mode semantics' of the :ref:`vp9` specification for more details. + +.. c:type:: v4l2_vp9_segmentation + +Encodes the quantization parameters. See section '7.2.10 Segmentation +params syntax' of the :ref:`vp9` specification for more details. + +.. tabularcolumns:: |p{0.8cm}|p{5cm}|p{11.4cm}| + +.. cssclass:: longtable + +.. flat-table:: struct v4l2_vp9_segmentation + :header-rows: 0 + :stub-columns: 0 + :widths: 1 1 2 + + * - __u8 + - ``feature_data[8][4]`` + - Data attached to each feature. Data entry is only valid if the feature + is enabled. The array shall be indexed with segment number as the first dimension + (0..7) and one of V4L2_VP9_SEG_* as the second dimension. + See :ref:`Segment Feature IDs<vp9_segment_feature>`. + * - __u8 + - ``feature_enabled[8]`` + - Bitmask defining which features are enabled in each segment. The value for each + segment is a combination of V4L2_VP9_SEGMENT_FEATURE_ENABLED(id) values where id is + one of V4L2_VP9_SEG_*. See :ref:`Segment Feature IDs<vp9_segment_feature>`. + * - __u8 + - ``tree_probs[7]`` + - Specifies the probability values to be used when decoding a Segment-ID. + See '5.15. Segmentation map' section of :ref:`vp9` for more details. + * - __u8 + - ``pred_probs[3]`` + - Specifies the probability values to be used when decoding a + Predicted-Segment-ID. See '6.4.14. Get segment id syntax' + section of :ref:`vp9` for more details. + * - __u8 + - ``flags`` + - Combination of V4L2_VP9_SEGMENTATION_FLAG_* flags. See + :ref:`Segmentation Flags<vp9_segmentation_flags>`. + * - __u8 + - ``reserved[5]`` + - Applications and drivers must set this to zero. + +.. _vp9_segment_feature: + +``Segment feature IDs`` + +.. tabularcolumns:: |p{6.0cm}|p{1cm}|p{10.3cm}| + +.. flat-table:: + :header-rows: 0 + :stub-columns: 0 + :widths: 1 1 2 + + * - ``V4L2_VP9_SEG_LVL_ALT_Q`` + - 0 + - Quantizer segment feature. + * - ``V4L2_VP9_SEG_LVL_ALT_L`` + - 1 + - Loop filter segment feature. + * - ``V4L2_VP9_SEG_LVL_REF_FRAME`` + - 2 + - Reference frame segment feature. + * - ``V4L2_VP9_SEG_LVL_SKIP`` + - 3 + - Skip segment feature. + * - ``V4L2_VP9_SEG_LVL_MAX`` + - 4 + - Number of segment features. + +.. _vp9_segmentation_flags: + +``Segmentation Flags`` + +.. tabularcolumns:: |p{10.6cm}|p{0.8cm}|p{5.9cm}| + +.. flat-table:: + :header-rows: 0 + :stub-columns: 0 + :widths: 1 1 2 + + * - ``V4L2_VP9_SEGMENTATION_FLAG_ENABLED`` + - 0x01 + - Indicates that this frame makes use of the segmentation tool. + * - ``V4L2_VP9_SEGMENTATION_FLAG_UPDATE_MAP`` + - 0x02 + - Indicates that the segmentation map should be updated during the + decoding of this frame. + * - ``V4L2_VP9_SEGMENTATION_FLAG_TEMPORAL_UPDATE`` + - 0x04 + - Indicates that the updates to the segmentation map are coded + relative to the existing segmentation map. + * - ``V4L2_VP9_SEGMENTATION_FLAG_UPDATE_DATA`` + - 0x08 + - Indicates that new parameters are about to be specified for each + segment. + * - ``V4L2_VP9_SEGMENTATION_FLAG_ABS_OR_DELTA_UPDATE`` + - 0x10 + - Indicates that the segmentation parameters represent the actual values + to be used. + +.. c:type:: v4l2_vp9_quantization + +Encodes the quantization parameters. See section '7.2.9 Quantization params +syntax' of the VP9 specification for more details. + +.. tabularcolumns:: |p{0.8cm}|p{4cm}|p{12.4cm}| + +.. cssclass:: longtable + +.. flat-table:: struct v4l2_vp9_quantization + :header-rows: 0 + :stub-columns: 0 + :widths: 1 1 2 + + * - __u8 + - ``base_q_idx`` + - Indicates the base frame qindex. + * - __s8 + - ``delta_q_y_dc`` + - Indicates the Y DC quantizer relative to base_q_idx. + * - __s8 + - ``delta_q_uv_dc`` + - Indicates the UV DC quantizer relative to base_q_idx. + * - __s8 + - ``delta_q_uv_ac`` + - Indicates the UV AC quantizer relative to base_q_idx. + * - __u8 + - ``reserved[4]`` + - Applications and drivers must set this to zero. + +.. c:type:: v4l2_vp9_loop_filter + +This structure contains all loop filter related parameters. See sections +'7.2.8 Loop filter semantics' of the :ref:`vp9` specification for more details. + +.. tabularcolumns:: |p{0.8cm}|p{4cm}|p{12.4cm}| + +.. cssclass:: longtable + +.. flat-table:: struct v4l2_vp9_loop_filter + :header-rows: 0 + :stub-columns: 0 + :widths: 1 1 2 + + * - __s8 + - ``ref_deltas[4]`` + - Contains the adjustment needed for the filter level based on the chosen + reference frame. + * - __s8 + - ``mode_deltas[2]`` + - Contains the adjustment needed for the filter level based on the chosen + mode. + * - __u8 + - ``level`` + - Indicates the loop filter strength. + * - __u8 + - ``sharpness`` + - Indicates the sharpness level. + * - __u8 + - ``flags`` + - Combination of V4L2_VP9_LOOP_FILTER_FLAG_* flags. + See :ref:`Loop Filter Flags <vp9_loop_filter_flags>`. + * - __u8 + - ``reserved[7]`` + - Applications and drivers must set this to zero. + + +.. _vp9_loop_filter_flags: + +``Loop Filter Flags`` + +.. tabularcolumns:: |p{9.6cm}|p{0.5cm}|p{7.2cm}| + +.. flat-table:: + :header-rows: 0 + :stub-columns: 0 + :widths: 1 1 2 + + * - ``V4L2_VP9_LOOP_FILTER_FLAG_DELTA_ENABLED`` + - 0x1 + - When set, the filter level depends on the mode and reference frame used + to predict a block. + * - ``V4L2_VP9_LOOP_FILTER_FLAG_DELTA_UPDATE`` + - 0x2 + - When set, the bitstream contains additional syntax elements that + specify which mode and reference frame deltas are to be updated. diff --git a/Documentation/userspace-api/media/v4l/libv4l-introduction.rst b/Documentation/userspace-api/media/v4l/libv4l-introduction.rst index 05690f2358ce..90215313b965 100644 --- a/Documentation/userspace-api/media/v4l/libv4l-introduction.rst +++ b/Documentation/userspace-api/media/v4l/libv4l-introduction.rst @@ -26,7 +26,7 @@ found in V4L2 drivers into a few common RGB and YUY formats. It currently accepts the following V4L2 driver formats: :ref:`V4L2_PIX_FMT_BGR24 <V4L2-PIX-FMT-BGR24>`, -:ref:`V4L2_PIX_FMT_HM12 <V4L2-PIX-FMT-HM12>`, +:ref:`V4L2_PIX_FMT_NV12_16L16 <V4L2-PIX-FMT-NV12-16L16>`, :ref:`V4L2_PIX_FMT_JPEG <V4L2-PIX-FMT-JPEG>`, :ref:`V4L2_PIX_FMT_MJPEG <V4L2-PIX-FMT-MJPEG>`, :ref:`V4L2_PIX_FMT_MR97310A <V4L2-PIX-FMT-MR97310A>`, diff --git a/Documentation/userspace-api/media/v4l/pixfmt-compressed.rst b/Documentation/userspace-api/media/v4l/pixfmt-compressed.rst index 0ede39907ee2..967fc803ef94 100644 --- a/Documentation/userspace-api/media/v4l/pixfmt-compressed.rst +++ b/Documentation/userspace-api/media/v4l/pixfmt-compressed.rst @@ -172,6 +172,21 @@ Compressed Formats - VP9 compressed video frame. The encoder generates one compressed frame per buffer, and the decoder requires one compressed frame per buffer. + * .. _V4L2-PIX-FMT-VP9-FRAME: + + - ``V4L2_PIX_FMT_VP9_FRAME`` + - 'VP9F' + - VP9 parsed frame, including the frame header, as extracted from the container. + This format is adapted for stateless video decoders that implement a + VP9 pipeline with the :ref:`stateless_decoder`. + Metadata associated with the frame to decode is required to be passed + through the ``V4L2_CID_STATELESS_VP9_FRAME`` and + the ``V4L2_CID_STATELESS_VP9_COMPRESSED_HDR`` controls. + See the :ref:`associated Codec Control IDs <v4l2-codec-stateless-vp9>`. + Exactly one output and one capture buffer must be provided for use with + this pixel format. The output buffer must contain the appropriate number + of macroblocks to decode a full corresponding frame to the matching + capture buffer. * .. _V4L2-PIX-FMT-HEVC: - ``V4L2_PIX_FMT_HEVC`` diff --git a/Documentation/userspace-api/media/v4l/subdev-formats.rst b/Documentation/userspace-api/media/v4l/subdev-formats.rst index bd68588b2683..0cbc045d5df6 100644 --- a/Documentation/userspace-api/media/v4l/subdev-formats.rst +++ b/Documentation/userspace-api/media/v4l/subdev-formats.rst @@ -7833,7 +7833,7 @@ The following table lists existing HSV/HSL formats. .. raw:: latex - \normalsize + \endgroup JPEG Compressed Formats diff --git a/Documentation/userspace-api/media/v4l/v4l2grab.c.rst b/Documentation/userspace-api/media/v4l/v4l2grab.c.rst index eaa0f95048e7..b38f661da733 100644 --- a/Documentation/userspace-api/media/v4l/v4l2grab.c.rst +++ b/Documentation/userspace-api/media/v4l/v4l2grab.c.rst @@ -46,7 +46,7 @@ file: media/v4l/v4l2grab.c } while (r == -1 && ((errno == EINTR) || (errno == EAGAIN))); if (r == -1) { - fprintf(stderr, "error %d, %s\\n", errno, strerror(errno)); + fprintf(stderr, "error %d, %s\n", errno, strerror(errno)); exit(EXIT_FAILURE); } } @@ -80,11 +80,11 @@ file: media/v4l/v4l2grab.c fmt.fmt.pix.field = V4L2_FIELD_INTERLACED; xioctl(fd, VIDIOC_S_FMT, &fmt); if (fmt.fmt.pix.pixelformat != V4L2_PIX_FMT_RGB24) { - printf("Libv4l didn't accept RGB24 format. Can't proceed.\\n"); + printf("Libv4l didn't accept RGB24 format. Can't proceed.\n"); exit(EXIT_FAILURE); } if ((fmt.fmt.pix.width != 640) || (fmt.fmt.pix.height != 480)) - printf("Warning: driver is sending image at %dx%d\\n", + printf("Warning: driver is sending image at %dx%d\n", fmt.fmt.pix.width, fmt.fmt.pix.height); CLEAR(req); @@ -151,7 +151,7 @@ file: media/v4l/v4l2grab.c perror("Cannot open image"); exit(EXIT_FAILURE); } - fprintf(fout, "P6\\n%d %d 255\\n", + fprintf(fout, "P6\n%d %d 255\n", fmt.fmt.pix.width, fmt.fmt.pix.height); fwrite(buffers[buf.index].start, buf.bytesused, 1, fout); fclose(fout); diff --git a/Documentation/userspace-api/media/v4l/vidioc-g-ext-ctrls.rst b/Documentation/userspace-api/media/v4l/vidioc-g-ext-ctrls.rst index fdde0ae6d521..29971a45a2d4 100644 --- a/Documentation/userspace-api/media/v4l/vidioc-g-ext-ctrls.rst +++ b/Documentation/userspace-api/media/v4l/vidioc-g-ext-ctrls.rst @@ -233,6 +233,14 @@ still cause this situation. - ``p_mpeg2_quantisation`` - A pointer to a struct :c:type:`v4l2_ctrl_mpeg2_quantisation`. Valid if this control is of type ``V4L2_CTRL_TYPE_MPEG2_QUANTISATION``. + * - struct :c:type:`v4l2_ctrl_vp9_compressed_hdr` * + - ``p_vp9_compressed_hdr_probs`` + - A pointer to a struct :c:type:`v4l2_ctrl_vp9_compressed_hdr`. Valid if this + control is of type ``V4L2_CTRL_TYPE_VP9_COMPRESSED_HDR``. + * - struct :c:type:`v4l2_ctrl_vp9_frame` * + - ``p_vp9_frame`` + - A pointer to a struct :c:type:`v4l2_ctrl_vp9_frame`. Valid if this + control is of type ``V4L2_CTRL_TYPE_VP9_FRAME``. * - struct :c:type:`v4l2_ctrl_hdr10_cll_info` * - ``p_hdr10_cll`` - A pointer to a struct :c:type:`v4l2_ctrl_hdr10_cll_info`. Valid if this control is diff --git a/Documentation/userspace-api/media/v4l/vidioc-queryctrl.rst b/Documentation/userspace-api/media/v4l/vidioc-queryctrl.rst index 2f491c17dd5d..88f630252d98 100644 --- a/Documentation/userspace-api/media/v4l/vidioc-queryctrl.rst +++ b/Documentation/userspace-api/media/v4l/vidioc-queryctrl.rst @@ -513,6 +513,18 @@ See also the examples in :ref:`control`. - n/a - A struct :c:type:`v4l2_ctrl_hevc_decode_params`, containing HEVC decoding parameters for stateless video decoders. + * - ``V4L2_CTRL_TYPE_VP9_COMPRESSED_HDR`` + - n/a + - n/a + - n/a + - A struct :c:type:`v4l2_ctrl_vp9_compressed_hdr`, containing VP9 + probabilities updates for stateless video decoders. + * - ``V4L2_CTRL_TYPE_VP9_FRAME`` + - n/a + - n/a + - n/a + - A struct :c:type:`v4l2_ctrl_vp9_frame`, containing VP9 + frame decode parameters for stateless video decoders. .. raw:: latex diff --git a/Documentation/userspace-api/media/videodev2.h.rst.exceptions b/Documentation/userspace-api/media/videodev2.h.rst.exceptions index eb0b1cd37abd..9cbb7a0c354a 100644 --- a/Documentation/userspace-api/media/videodev2.h.rst.exceptions +++ b/Documentation/userspace-api/media/videodev2.h.rst.exceptions @@ -149,6 +149,8 @@ replace symbol V4L2_CTRL_TYPE_HEVC_SLICE_PARAMS :c:type:`v4l2_ctrl_type` replace symbol V4L2_CTRL_TYPE_AREA :c:type:`v4l2_ctrl_type` replace symbol V4L2_CTRL_TYPE_FWHT_PARAMS :c:type:`v4l2_ctrl_type` replace symbol V4L2_CTRL_TYPE_VP8_FRAME :c:type:`v4l2_ctrl_type` +replace symbol V4L2_CTRL_TYPE_VP9_COMPRESSED_HDR :c:type:`v4l2_ctrl_type` +replace symbol V4L2_CTRL_TYPE_VP9_FRAME :c:type:`v4l2_ctrl_type` replace symbol V4L2_CTRL_TYPE_HDR10_CLL_INFO :c:type:`v4l2_ctrl_type` replace symbol V4L2_CTRL_TYPE_HDR10_MASTERING_DISPLAY :c:type:`v4l2_ctrl_type` diff --git a/Documentation/virt/kvm/amd-memory-encryption.rst b/Documentation/virt/kvm/amd-memory-encryption.rst index 5c081c8c7164..1c6847fff304 100644 --- a/Documentation/virt/kvm/amd-memory-encryption.rst +++ b/Documentation/virt/kvm/amd-memory-encryption.rst @@ -85,6 +85,12 @@ guests, such as launching, running, snapshotting, migrating and decommissioning. The KVM_SEV_INIT command is used by the hypervisor to initialize the SEV platform context. In a typical workflow, this command should be the first command issued. +The firmware can be initialized either by using its own non-volatile storage or +the OS can manage the NV storage for the firmware using the module parameter +``init_ex_path``. The file specified by ``init_ex_path`` must exist. To create +a new NV storage file allocate the file with 32KB bytes of 0xFF as required by +the SEV spec. + Returns: 0 on success, -negative on error 2. KVM_SEV_LAUNCH_START diff --git a/Documentation/virt/kvm/api.rst b/Documentation/virt/kvm/api.rst index aeeb071c7688..a4267104db50 100644 --- a/Documentation/virt/kvm/api.rst +++ b/Documentation/virt/kvm/api.rst @@ -371,6 +371,9 @@ The bits in the dirty bitmap are cleared before the ioctl returns, unless KVM_CAP_MANUAL_DIRTY_LOG_PROTECT2 is enabled. For more information, see the description of the capability. +Note that the Xen shared info page, if configured, shall always be assumed +to be dirty. KVM will not explicitly mark it such. + 4.9 KVM_SET_MEMORY_ALIAS ------------------------ @@ -1566,6 +1569,7 @@ otherwise it will return EBUSY error. struct kvm_xsave { __u32 region[1024]; + __u32 extra[0]; }; This ioctl would copy current vcpu's xsave struct to the userspace. @@ -1574,7 +1578,7 @@ This ioctl would copy current vcpu's xsave struct to the userspace. 4.43 KVM_SET_XSAVE ------------------ -:Capability: KVM_CAP_XSAVE +:Capability: KVM_CAP_XSAVE and KVM_CAP_XSAVE2 :Architectures: x86 :Type: vcpu ioctl :Parameters: struct kvm_xsave (in) @@ -1585,9 +1589,18 @@ This ioctl would copy current vcpu's xsave struct to the userspace. struct kvm_xsave { __u32 region[1024]; + __u32 extra[0]; }; -This ioctl would copy userspace's xsave struct to the kernel. +This ioctl would copy userspace's xsave struct to the kernel. It copies +as many bytes as are returned by KVM_CHECK_EXTENSION(KVM_CAP_XSAVE2), +when invoked on the vm file descriptor. The size value returned by +KVM_CHECK_EXTENSION(KVM_CAP_XSAVE2) will always be at least 4096. +Currently, it is only greater than 4096 if a dynamic feature has been +enabled with ``arch_prctl()``, but this may change in the future. + +The offsets of the state save areas in struct kvm_xsave follow the +contents of CPUID leaf 0xD on the host. 4.44 KVM_GET_XCRS @@ -1684,6 +1697,10 @@ userspace capabilities, and with user requirements (for example, the user may wish to constrain cpuid to emulate older hardware, or for feature consistency across a cluster). +Dynamically-enabled feature bits need to be requested with +``arch_prctl()`` before calling this ioctl. Feature bits that have not +been requested are excluded from the result. + Note that certain capabilities, such as KVM_CAP_X86_DISABLE_EXITS, may expose cpuid features (e.g. MONITOR) which are not supported by kvm in its default configuration. If userspace enables such capabilities, it @@ -1796,6 +1813,7 @@ No flags are specified so far, the corresponding field must be set to zero. struct kvm_irq_routing_msi msi; struct kvm_irq_routing_s390_adapter adapter; struct kvm_irq_routing_hv_sint hv_sint; + struct kvm_irq_routing_xen_evtchn xen_evtchn; __u32 pad[8]; } u; }; @@ -1805,6 +1823,7 @@ No flags are specified so far, the corresponding field must be set to zero. #define KVM_IRQ_ROUTING_MSI 2 #define KVM_IRQ_ROUTING_S390_ADAPTER 3 #define KVM_IRQ_ROUTING_HV_SINT 4 + #define KVM_IRQ_ROUTING_XEN_EVTCHN 5 flags: @@ -1856,6 +1875,20 @@ address_hi must be zero. __u32 sint; }; + struct kvm_irq_routing_xen_evtchn { + __u32 port; + __u32 vcpu; + __u32 priority; + }; + + +When KVM_CAP_XEN_HVM includes the KVM_XEN_HVM_CONFIG_EVTCHN_2LEVEL bit +in its indication of supported features, routing to Xen event channels +is supported. Although the priority field is present, only the value +KVM_XEN_HVM_CONFIG_EVTCHN_2LEVEL is supported, which means delivery by +2 level event channels. FIFO event channel support may be added in +the future. + 4.55 KVM_SET_TSC_KHZ -------------------- @@ -3235,6 +3268,7 @@ number. :Capability: KVM_CAP_DEVICE_CTRL, KVM_CAP_VM_ATTRIBUTES for vm device, KVM_CAP_VCPU_ATTRIBUTES for vcpu device + KVM_CAP_SYS_ATTRIBUTES for system (/dev/kvm) device (no set) :Type: device ioctl, vm ioctl, vcpu ioctl :Parameters: struct kvm_device_attr :Returns: 0 on success, -1 on error @@ -3269,7 +3303,8 @@ transferred is defined by the particular attribute. ------------------------ :Capability: KVM_CAP_DEVICE_CTRL, KVM_CAP_VM_ATTRIBUTES for vm device, - KVM_CAP_VCPU_ATTRIBUTES for vcpu device + KVM_CAP_VCPU_ATTRIBUTES for vcpu device + KVM_CAP_SYS_ATTRIBUTES for system (/dev/kvm) device :Type: device ioctl, vm ioctl, vcpu ioctl :Parameters: struct kvm_device_attr :Returns: 0 on success, -1 on error @@ -3701,7 +3736,7 @@ KVM with the currently defined set of flags. :Architectures: s390 :Type: vm ioctl :Parameters: struct kvm_s390_skeys -:Returns: 0 on success, KVM_S390_GET_KEYS_NONE if guest is not using storage +:Returns: 0 on success, KVM_S390_GET_SKEYS_NONE if guest is not using storage keys, negative value on error This ioctl is used to get guest storage key values on the s390 @@ -3720,7 +3755,7 @@ you want to get. The count field is the number of consecutive frames (starting from start_gfn) whose storage keys to get. The count field must be at least 1 and the maximum -allowed value is defined as KVM_S390_SKEYS_ALLOC_MAX. Values outside this range +allowed value is defined as KVM_S390_SKEYS_MAX. Values outside this range will cause the ioctl to return -EINVAL. The skeydata_addr field is the address to a buffer large enough to hold count @@ -3744,7 +3779,7 @@ you want to set. The count field is the number of consecutive frames (starting from start_gfn) whose storage keys to get. The count field must be at least 1 and the maximum -allowed value is defined as KVM_S390_SKEYS_ALLOC_MAX. Values outside this range +allowed value is defined as KVM_S390_SKEYS_MAX. Values outside this range will cause the ioctl to return -EINVAL. The skeydata_addr field is the address to a buffer containing count bytes of @@ -5134,6 +5169,15 @@ KVM_XEN_ATTR_TYPE_SHARED_INFO not aware of the Xen CPU id which is used as the index into the vcpu_info[] array, so cannot know the correct default location. + Note that the shared info page may be constantly written to by KVM; + it contains the event channel bitmap used to deliver interrupts to + a Xen guest, amongst other things. It is exempt from dirty tracking + mechanisms — KVM will not explicitly mark the page as dirty each + time an event channel interrupt is delivered to the guest! Thus, + userspace should always assume that the designated GFN is dirty if + any vCPU has been running or any event channel interrupts can be + routed to the guest. + KVM_XEN_ATTR_TYPE_UPCALL_VECTOR Sets the exception vector used to deliver Xen event channel upcalls. @@ -5503,6 +5547,34 @@ the trailing ``'\0'``, is indicated by ``name_size`` in the header. The Stats Data block contains an array of 64-bit values in the same order as the descriptors in Descriptors block. +4.134 KVM_GET_XSAVE2 +-------------------- + +:Capability: KVM_CAP_XSAVE2 +:Architectures: x86 +:Type: vcpu ioctl +:Parameters: struct kvm_xsave (out) +:Returns: 0 on success, -1 on error + + +:: + + struct kvm_xsave { + __u32 region[1024]; + __u32 extra[0]; + }; + +This ioctl would copy current vcpu's xsave struct to the userspace. It +copies as many bytes as are returned by KVM_CHECK_EXTENSION(KVM_CAP_XSAVE2) +when invoked on the vm file descriptor. The size value returned by +KVM_CHECK_EXTENSION(KVM_CAP_XSAVE2) will always be at least 4096. +Currently, it is only greater than 4096 if a dynamic feature has been +enabled with ``arch_prctl()``, but this may change in the future. + +The offsets of the state save areas in struct kvm_xsave follow the contents +of CPUID leaf 0xD on the host. + + 5. The kvm_run structure ======================== @@ -7293,7 +7365,7 @@ trap and emulate MSRs that are outside of the scope of KVM as well as limit the attack surface on KVM's MSR emulation code. 8.28 KVM_CAP_ENFORCE_PV_FEATURE_CPUID ------------------------------ +------------------------------------- Architectures: x86 @@ -7401,6 +7473,7 @@ PVHVM guests. Valid flags are:: #define KVM_XEN_HVM_CONFIG_INTERCEPT_HCALL (1 << 1) #define KVM_XEN_HVM_CONFIG_SHARED_INFO (1 << 2) #define KVM_XEN_HVM_CONFIG_RUNSTATE (1 << 2) + #define KVM_XEN_HVM_CONFIG_EVTCHN_2LEVEL (1 << 3) The KVM_XEN_HVM_CONFIG_HYPERCALL_MSR flag indicates that the KVM_XEN_HVM_CONFIG ioctl is available, for the guest to set its hypercall page. @@ -7420,6 +7493,10 @@ The KVM_XEN_HVM_CONFIG_RUNSTATE flag indicates that the runstate-related features KVM_XEN_VCPU_ATTR_TYPE_RUNSTATE_ADDR/_CURRENT/_DATA/_ADJUST are supported by the KVM_XEN_VCPU_SET_ATTR/KVM_XEN_VCPU_GET_ATTR ioctls. +The KVM_XEN_HVM_CONFIG_EVTCHN_2LEVEL flag indicates that IRQ routing entries +of the type KVM_IRQ_ROUTING_XEN_EVTCHN are supported, with the priority +field set to indicate 2 level event channel delivery. + 8.31 KVM_CAP_PPC_MULTITCE ------------------------- diff --git a/Documentation/virt/kvm/mmu.rst b/Documentation/virt/kvm/mmu.rst index f60f5488e121..5b1ebad24c77 100644 --- a/Documentation/virt/kvm/mmu.rst +++ b/Documentation/virt/kvm/mmu.rst @@ -161,7 +161,7 @@ Shadow pages contain the following information: If clear, this page corresponds to a guest page table denoted by the gfn field. role.quadrant: - When role.gpte_is_8_bytes=0, the guest uses 32-bit gptes while the host uses 64-bit + When role.has_4_byte_gpte=1, the guest uses 32-bit gptes while the host uses 64-bit sptes. That means a guest page table contains more ptes than the host, so multiple shadow pages are needed to shadow one guest page. For first-level shadow pages, role.quadrant can be 0 or 1 and denotes the @@ -177,9 +177,9 @@ Shadow pages contain the following information: The page is invalid and should not be used. It is a root page that is currently pinned (by a cpu hardware register pointing to it); once it is unpinned it will be destroyed. - role.gpte_is_8_bytes: - Reflects the size of the guest PTE for which the page is valid, i.e. '1' - if 64-bit gptes are in use, '0' if 32-bit gptes are in use. + role.has_4_byte_gpte: + Reflects the size of the guest PTE for which the page is valid, i.e. '0' + if direct map or 64-bit gptes are in use, '1' if 32-bit gptes are in use. role.efer_nx: Contains the value of efer.nx for which the page is valid. role.cr0_wp: diff --git a/Documentation/vm/arch_pgtable_helpers.rst b/Documentation/vm/arch_pgtable_helpers.rst index 552567d863b8..f8b225fc9190 100644 --- a/Documentation/vm/arch_pgtable_helpers.rst +++ b/Documentation/vm/arch_pgtable_helpers.rst @@ -66,9 +66,11 @@ PTE Page Table Helpers +---------------------------+--------------------------------------------------+ | pte_mknotpresent | Invalidates a mapped PTE | +---------------------------+--------------------------------------------------+ -| ptep_get_and_clear | Clears a PTE | +| ptep_clear | Clears a PTE | +---------------------------+--------------------------------------------------+ -| ptep_get_and_clear_full | Clears a PTE | +| ptep_get_and_clear | Clears and returns PTE | ++---------------------------+--------------------------------------------------+ +| ptep_get_and_clear_full | Clears and returns PTE (batched PTE unmap) | +---------------------------+--------------------------------------------------+ | ptep_test_and_clear_young | Clears young from a PTE | +---------------------------+--------------------------------------------------+ @@ -247,12 +249,12 @@ SWAP Page Table Helpers | __swp_to_pmd_entry | Creates a mapped PMD from a swapped entry (arch) | +---------------------------+--------------------------------------------------+ | is_migration_entry | Tests a migration (read or write) swapped entry | -+---------------------------+--------------------------------------------------+ -| is_write_migration_entry | Tests a write migration swapped entry | -+---------------------------+--------------------------------------------------+ -| make_migration_entry_read | Converts into read migration swapped entry | -+---------------------------+--------------------------------------------------+ -| make_migration_entry | Creates a migration swapped entry (read or write)| -+---------------------------+--------------------------------------------------+ ++-------------------------------+----------------------------------------------+ +| is_writable_migration_entry | Tests a write migration swapped entry | ++-------------------------------+----------------------------------------------+ +| make_readable_migration_entry | Creates a read migration swapped entry | ++-------------------------------+----------------------------------------------+ +| make_writable_migration_entry | Creates a write migration swapped entry | ++-------------------------------+----------------------------------------------+ [1] https://lore.kernel.org/linux-mm/20181017020930.GN30832@redhat.com/ diff --git a/Documentation/vm/cleancache.rst b/Documentation/vm/cleancache.rst deleted file mode 100644 index 68cba9131c31..000000000000 --- a/Documentation/vm/cleancache.rst +++ /dev/null @@ -1,296 +0,0 @@ -.. _cleancache: - -========== -Cleancache -========== - -Motivation -========== - -Cleancache is a new optional feature provided by the VFS layer that -potentially dramatically increases page cache effectiveness for -many workloads in many environments at a negligible cost. - -Cleancache can be thought of as a page-granularity victim cache for clean -pages that the kernel's pageframe replacement algorithm (PFRA) would like -to keep around, but can't since there isn't enough memory. So when the -PFRA "evicts" a page, it first attempts to use cleancache code to -put the data contained in that page into "transcendent memory", memory -that is not directly accessible or addressable by the kernel and is -of unknown and possibly time-varying size. - -Later, when a cleancache-enabled filesystem wishes to access a page -in a file on disk, it first checks cleancache to see if it already -contains it; if it does, the page of data is copied into the kernel -and a disk access is avoided. - -Transcendent memory "drivers" for cleancache are currently implemented -in Xen (using hypervisor memory) and zcache (using in-kernel compressed -memory) and other implementations are in development. - -:ref:`FAQs <faq>` are included below. - -Implementation Overview -======================= - -A cleancache "backend" that provides transcendent memory registers itself -to the kernel's cleancache "frontend" by calling cleancache_register_ops, -passing a pointer to a cleancache_ops structure with funcs set appropriately. -The functions provided must conform to certain semantics as follows: - -Most important, cleancache is "ephemeral". Pages which are copied into -cleancache have an indefinite lifetime which is completely unknowable -by the kernel and so may or may not still be in cleancache at any later time. -Thus, as its name implies, cleancache is not suitable for dirty pages. -Cleancache has complete discretion over what pages to preserve and what -pages to discard and when. - -Mounting a cleancache-enabled filesystem should call "init_fs" to obtain a -pool id which, if positive, must be saved in the filesystem's superblock; -a negative return value indicates failure. A "put_page" will copy a -(presumably about-to-be-evicted) page into cleancache and associate it with -the pool id, a file key, and a page index into the file. (The combination -of a pool id, a file key, and an index is sometimes called a "handle".) -A "get_page" will copy the page, if found, from cleancache into kernel memory. -An "invalidate_page" will ensure the page no longer is present in cleancache; -an "invalidate_inode" will invalidate all pages associated with the specified -file; and, when a filesystem is unmounted, an "invalidate_fs" will invalidate -all pages in all files specified by the given pool id and also surrender -the pool id. - -An "init_shared_fs", like init_fs, obtains a pool id but tells cleancache -to treat the pool as shared using a 128-bit UUID as a key. On systems -that may run multiple kernels (such as hard partitioned or virtualized -systems) that may share a clustered filesystem, and where cleancache -may be shared among those kernels, calls to init_shared_fs that specify the -same UUID will receive the same pool id, thus allowing the pages to -be shared. Note that any security requirements must be imposed outside -of the kernel (e.g. by "tools" that control cleancache). Or a -cleancache implementation can simply disable shared_init by always -returning a negative value. - -If a get_page is successful on a non-shared pool, the page is invalidated -(thus making cleancache an "exclusive" cache). On a shared pool, the page -is NOT invalidated on a successful get_page so that it remains accessible to -other sharers. The kernel is responsible for ensuring coherency between -cleancache (shared or not), the page cache, and the filesystem, using -cleancache invalidate operations as required. - -Note that cleancache must enforce put-put-get coherency and get-get -coherency. For the former, if two puts are made to the same handle but -with different data, say AAA by the first put and BBB by the second, a -subsequent get can never return the stale data (AAA). For get-get coherency, -if a get for a given handle fails, subsequent gets for that handle will -never succeed unless preceded by a successful put with that handle. - -Last, cleancache provides no SMP serialization guarantees; if two -different Linux threads are simultaneously putting and invalidating a page -with the same handle, the results are indeterminate. Callers must -lock the page to ensure serial behavior. - -Cleancache Performance Metrics -============================== - -If properly configured, monitoring of cleancache is done via debugfs in -the `/sys/kernel/debug/cleancache` directory. The effectiveness of cleancache -can be measured (across all filesystems) with: - -``succ_gets`` - number of gets that were successful - -``failed_gets`` - number of gets that failed - -``puts`` - number of puts attempted (all "succeed") - -``invalidates`` - number of invalidates attempted - -A backend implementation may provide additional metrics. - -.. _faq: - -FAQ -=== - -* Where's the value? (Andrew Morton) - -Cleancache provides a significant performance benefit to many workloads -in many environments with negligible overhead by improving the -effectiveness of the pagecache. Clean pagecache pages are -saved in transcendent memory (RAM that is otherwise not directly -addressable to the kernel); fetching those pages later avoids "refaults" -and thus disk reads. - -Cleancache (and its sister code "frontswap") provide interfaces for -this transcendent memory (aka "tmem"), which conceptually lies between -fast kernel-directly-addressable RAM and slower DMA/asynchronous devices. -Disallowing direct kernel or userland reads/writes to tmem -is ideal when data is transformed to a different form and size (such -as with compression) or secretly moved (as might be useful for write- -balancing for some RAM-like devices). Evicted page-cache pages (and -swap pages) are a great use for this kind of slower-than-RAM-but-much- -faster-than-disk transcendent memory, and the cleancache (and frontswap) -"page-object-oriented" specification provides a nice way to read and -write -- and indirectly "name" -- the pages. - -In the virtual case, the whole point of virtualization is to statistically -multiplex physical resources across the varying demands of multiple -virtual machines. This is really hard to do with RAM and efforts to -do it well with no kernel change have essentially failed (except in some -well-publicized special-case workloads). Cleancache -- and frontswap -- -with a fairly small impact on the kernel, provide a huge amount -of flexibility for more dynamic, flexible RAM multiplexing. -Specifically, the Xen Transcendent Memory backend allows otherwise -"fallow" hypervisor-owned RAM to not only be "time-shared" between multiple -virtual machines, but the pages can be compressed and deduplicated to -optimize RAM utilization. And when guest OS's are induced to surrender -underutilized RAM (e.g. with "self-ballooning"), page cache pages -are the first to go, and cleancache allows those pages to be -saved and reclaimed if overall host system memory conditions allow. - -And the identical interface used for cleancache can be used in -physical systems as well. The zcache driver acts as a memory-hungry -device that stores pages of data in a compressed state. And -the proposed "RAMster" driver shares RAM across multiple physical -systems. - -* Why does cleancache have its sticky fingers so deep inside the - filesystems and VFS? (Andrew Morton and Christoph Hellwig) - -The core hooks for cleancache in VFS are in most cases a single line -and the minimum set are placed precisely where needed to maintain -coherency (via cleancache_invalidate operations) between cleancache, -the page cache, and disk. All hooks compile into nothingness if -cleancache is config'ed off and turn into a function-pointer- -compare-to-NULL if config'ed on but no backend claims the ops -functions, or to a compare-struct-element-to-negative if a -backend claims the ops functions but a filesystem doesn't enable -cleancache. - -Some filesystems are built entirely on top of VFS and the hooks -in VFS are sufficient, so don't require an "init_fs" hook; the -initial implementation of cleancache didn't provide this hook. -But for some filesystems (such as btrfs), the VFS hooks are -incomplete and one or more hooks in fs-specific code are required. -And for some other filesystems, such as tmpfs, cleancache may -be counterproductive. So it seemed prudent to require a filesystem -to "opt in" to use cleancache, which requires adding a hook in -each filesystem. Not all filesystems are supported by cleancache -only because they haven't been tested. The existing set should -be sufficient to validate the concept, the opt-in approach means -that untested filesystems are not affected, and the hooks in the -existing filesystems should make it very easy to add more -filesystems in the future. - -The total impact of the hooks to existing fs and mm files is only -about 40 lines added (not counting comments and blank lines). - -* Why not make cleancache asynchronous and batched so it can more - easily interface with real devices with DMA instead of copying each - individual page? (Minchan Kim) - -The one-page-at-a-time copy semantics simplifies the implementation -on both the frontend and backend and also allows the backend to -do fancy things on-the-fly like page compression and -page deduplication. And since the data is "gone" (copied into/out -of the pageframe) before the cleancache get/put call returns, -a great deal of race conditions and potential coherency issues -are avoided. While the interface seems odd for a "real device" -or for real kernel-addressable RAM, it makes perfect sense for -transcendent memory. - -* Why is non-shared cleancache "exclusive"? And where is the - page "invalidated" after a "get"? (Minchan Kim) - -The main reason is to free up space in transcendent memory and -to avoid unnecessary cleancache_invalidate calls. If you want inclusive, -the page can be "put" immediately following the "get". If -put-after-get for inclusive becomes common, the interface could -be easily extended to add a "get_no_invalidate" call. - -The invalidate is done by the cleancache backend implementation. - -* What's the performance impact? - -Performance analysis has been presented at OLS'09 and LCA'10. -Briefly, performance gains can be significant on most workloads, -especially when memory pressure is high (e.g. when RAM is -overcommitted in a virtual workload); and because the hooks are -invoked primarily in place of or in addition to a disk read/write, -overhead is negligible even in worst case workloads. Basically -cleancache replaces I/O with memory-copy-CPU-overhead; on older -single-core systems with slow memory-copy speeds, cleancache -has little value, but in newer multicore machines, especially -consolidated/virtualized machines, it has great value. - -* How do I add cleancache support for filesystem X? (Boaz Harrash) - -Filesystems that are well-behaved and conform to certain -restrictions can utilize cleancache simply by making a call to -cleancache_init_fs at mount time. Unusual, misbehaving, or -poorly layered filesystems must either add additional hooks -and/or undergo extensive additional testing... or should just -not enable the optional cleancache. - -Some points for a filesystem to consider: - - - The FS should be block-device-based (e.g. a ram-based FS such - as tmpfs should not enable cleancache) - - To ensure coherency/correctness, the FS must ensure that all - file removal or truncation operations either go through VFS or - add hooks to do the equivalent cleancache "invalidate" operations - - To ensure coherency/correctness, either inode numbers must - be unique across the lifetime of the on-disk file OR the - FS must provide an "encode_fh" function. - - The FS must call the VFS superblock alloc and deactivate routines - or add hooks to do the equivalent cleancache calls done there. - - To maximize performance, all pages fetched from the FS should - go through the do_mpag_readpage routine or the FS should add - hooks to do the equivalent (cf. btrfs) - - Currently, the FS blocksize must be the same as PAGESIZE. This - is not an architectural restriction, but no backends currently - support anything different. - - A clustered FS should invoke the "shared_init_fs" cleancache - hook to get best performance for some backends. - -* Why not use the KVA of the inode as the key? (Christoph Hellwig) - -If cleancache would use the inode virtual address instead of -inode/filehandle, the pool id could be eliminated. But, this -won't work because cleancache retains pagecache data pages -persistently even when the inode has been pruned from the -inode unused list, and only invalidates the data page if the file -gets removed/truncated. So if cleancache used the inode kva, -there would be potential coherency issues if/when the inode -kva is reused for a different file. Alternately, if cleancache -invalidated the pages when the inode kva was freed, much of the value -of cleancache would be lost because the cache of pages in cleanache -is potentially much larger than the kernel pagecache and is most -useful if the pages survive inode cache removal. - -* Why is a global variable required? - -The cleancache_enabled flag is checked in all of the frequently-used -cleancache hooks. The alternative is a function call to check a static -variable. Since cleancache is enabled dynamically at runtime, systems -that don't enable cleancache would suffer thousands (possibly -tens-of-thousands) of unnecessary function calls per second. So the -global variable allows cleancache to be enabled by default at compile -time, but have insignificant performance impact when cleancache remains -disabled at runtime. - -* Does cleanache work with KVM? - -The memory model of KVM is sufficiently different that a cleancache -backend may have less value for KVM. This remains to be tested, -especially in an overcommitted system. - -* Does cleancache work in userspace? It sounds useful for - memory hungry caches like web browsers. (Jamie Lokier) - -No plans yet, though we agree it sounds useful, at least for -apps that bypass the page cache (e.g. O_DIRECT). - -Last updated: Dan Magenheimer, April 13 2011 diff --git a/Documentation/vm/frontswap.rst b/Documentation/vm/frontswap.rst index 1979f430c1c5..feecc5e24477 100644 --- a/Documentation/vm/frontswap.rst +++ b/Documentation/vm/frontswap.rst @@ -8,12 +8,6 @@ Frontswap provides a "transcendent memory" interface for swap pages. In some environments, dramatic performance savings may be obtained because swapped pages are saved in RAM (or a RAM-like device) instead of a swap disk. -(Note, frontswap -- and :ref:`cleancache` (merged at 3.0) -- are the "frontends" -and the only necessary changes to the core kernel for transcendent memory; -all other supporting code -- the "backends" -- is implemented as drivers. -See the LWN.net article `Transcendent memory in a nutshell`_ -for a detailed overview of frontswap and related kernel parts) - .. _Transcendent memory in a nutshell: https://lwn.net/Articles/454795/ Frontswap is so named because it can be thought of as the opposite of @@ -45,12 +39,6 @@ a disk write and, if the data is later read back, a disk read are avoided. If a store returns failure, transcendent memory has rejected the data, and the page can be written to swap as usual. -If a backend chooses, frontswap can be configured as a "writethrough -cache" by calling frontswap_writethrough(). In this mode, the reduction -in swap device writes is lost (and also a non-trivial performance advantage) -in order to allow the backend to arbitrarily "reclaim" space used to -store frontswap pages to more completely manage its memory usage. - Note that if a page is stored and the page already exists in transcendent memory (a "duplicate" store), either the store succeeds and the data is overwritten, or the store fails AND the page is invalidated. This ensures stale data may @@ -87,11 +75,9 @@ This interface is ideal when data is transformed to a different form and size (such as with compression) or secretly moved (as might be useful for write-balancing for some RAM-like devices). Swap pages (and evicted page-cache pages) are a great use for this kind of slower-than-RAM- -but-much-faster-than-disk "pseudo-RAM device" and the frontswap (and -cleancache) interface to transcendent memory provides a nice way to read -and write -- and indirectly "name" -- the pages. +but-much-faster-than-disk "pseudo-RAM device". -Frontswap -- and cleancache -- with a fairly small impact on the kernel, +Frontswap with a fairly small impact on the kernel, provides a huge amount of flexibility for more dynamic, flexible RAM utilization in various system configurations: @@ -269,19 +255,6 @@ the old data and ensure that it is no longer accessible. Since the swap subsystem then writes the new data to the read swap device, this is the correct course of action to ensure coherency. -* What is frontswap_shrink for? - -When the (non-frontswap) swap subsystem swaps out a page to a real -swap device, that page is only taking up low-value pre-allocated disk -space. But if frontswap has placed a page in transcendent memory, that -page may be taking up valuable real estate. The frontswap_shrink -routine allows code outside of the swap subsystem to force pages out -of the memory managed by frontswap and back into kernel-addressable memory. -For example, in RAMster, a "suction driver" thread will attempt -to "repatriate" pages sent to a remote machine back to the local machine; -this is driven using the frontswap_shrink mechanism when memory pressure -subsides. - * Why does the frontswap patch create the new include file swapfile.h? The frontswap code depends on some swap-subsystem-internal data diff --git a/Documentation/vm/index.rst b/Documentation/vm/index.rst index 6f5ffef4b716..44365c4574a3 100644 --- a/Documentation/vm/index.rst +++ b/Documentation/vm/index.rst @@ -15,7 +15,6 @@ algorithms. If you are looking for advice on simply allocating memory, see the active_mm arch_pgtable_helpers balance - cleancache damon/index free_page_reporting frontswap @@ -31,10 +30,12 @@ algorithms. If you are looking for advice on simply allocating memory, see the page_migration page_frags page_owner + page_table_check remap_file_pages slub split_page_table_lock transhuge unevictable-lru + vmalloced-kernel-stacks z3fold zsmalloc diff --git a/Documentation/vm/overcommit-accounting.rst b/Documentation/vm/overcommit-accounting.rst index 0dd54bbe4afa..1addb0c374a4 100644 --- a/Documentation/vm/overcommit-accounting.rst +++ b/Documentation/vm/overcommit-accounting.rst @@ -34,7 +34,8 @@ The Linux kernel supports the following overcommit handling modes The overcommit policy is set via the sysctl ``vm.overcommit_memory``. The overcommit amount can be set via ``vm.overcommit_ratio`` (percentage) -or ``vm.overcommit_kbytes`` (absolute value). +or ``vm.overcommit_kbytes`` (absolute value). These only have an effect +when ``vm.overcommit_memory`` is set to 2. The current overcommit limit and amount committed are viewable in ``/proc/meminfo`` as CommitLimit and Committed_AS respectively. diff --git a/Documentation/vm/page_migration.rst b/Documentation/vm/page_migration.rst index 08810f549f70..8c5cb8147e55 100644 --- a/Documentation/vm/page_migration.rst +++ b/Documentation/vm/page_migration.rst @@ -263,15 +263,15 @@ Monitoring Migration The following events (counters) can be used to monitor page migration. 1. PGMIGRATE_SUCCESS: Normal page migration success. Each count means that a - page was migrated. If the page was a non-THP page, then this counter is - increased by one. If the page was a THP, then this counter is increased by - the number of THP subpages. For example, migration of a single 2MB THP that - has 4KB-size base pages (subpages) will cause this counter to increase by - 512. + page was migrated. If the page was a non-THP and non-hugetlb page, then + this counter is increased by one. If the page was a THP or hugetlb, then + this counter is increased by the number of THP or hugetlb subpages. + For example, migration of a single 2MB THP that has 4KB-size base pages + (subpages) will cause this counter to increase by 512. 2. PGMIGRATE_FAIL: Normal page migration failure. Same counting rules as for PGMIGRATE_SUCCESS, above: this will be increased by the number of subpages, - if it was a THP. + if it was a THP or hugetlb. 3. THP_MIGRATION_SUCCESS: A THP was migrated without being split. diff --git a/Documentation/vm/page_table_check.rst b/Documentation/vm/page_table_check.rst new file mode 100644 index 000000000000..1a09472f10a3 --- /dev/null +++ b/Documentation/vm/page_table_check.rst @@ -0,0 +1,56 @@ +.. SPDX-License-Identifier: GPL-2.0 + +.. _page_table_check: + +================ +Page Table Check +================ + +Introduction +============ + +Page table check allows to harden the kernel by ensuring that some types of +the memory corruptions are prevented. + +Page table check performs extra verifications at the time when new pages become +accessible from the userspace by getting their page table entries (PTEs PMDs +etc.) added into the table. + +In case of detected corruption, the kernel is crashed. There is a small +performance and memory overhead associated with the page table check. Therefore, +it is disabled by default, but can be optionally enabled on systems where the +extra hardening outweighs the performance costs. Also, because page table check +is synchronous, it can help with debugging double map memory corruption issues, +by crashing kernel at the time wrong mapping occurs instead of later which is +often the case with memory corruptions bugs. + +Double mapping detection logic +============================== + ++-------------------+-------------------+-------------------+------------------+ +| Current Mapping | New mapping | Permissions | Rule | ++===================+===================+===================+==================+ +| Anonymous | Anonymous | Read | Allow | ++-------------------+-------------------+-------------------+------------------+ +| Anonymous | Anonymous | Read / Write | Prohibit | ++-------------------+-------------------+-------------------+------------------+ +| Anonymous | Named | Any | Prohibit | ++-------------------+-------------------+-------------------+------------------+ +| Named | Anonymous | Any | Prohibit | ++-------------------+-------------------+-------------------+------------------+ +| Named | Named | Any | Allow | ++-------------------+-------------------+-------------------+------------------+ + +Enabling Page Table Check +========================= + +Build kernel with: + +- PAGE_TABLE_CHECK=y + Note, it can only be enabled on platforms where ARCH_SUPPORTS_PAGE_TABLE_CHECK + is available. + +- Boot with 'page_table_check=on' kernel parameter. + +Optionally, build kernel with PAGE_TABLE_CHECK_ENFORCED in order to have page +table support without extra kernel parameter. diff --git a/Documentation/vm/vmalloced-kernel-stacks.rst b/Documentation/vm/vmalloced-kernel-stacks.rst new file mode 100644 index 000000000000..fc8c67833af6 --- /dev/null +++ b/Documentation/vm/vmalloced-kernel-stacks.rst @@ -0,0 +1,153 @@ +.. SPDX-License-Identifier: GPL-2.0 + +===================================== +Virtually Mapped Kernel Stack Support +===================================== + +:Author: Shuah Khan <skhan@linuxfoundation.org> + +.. contents:: :local: + +Overview +-------- + +This is a compilation of information from the code and original patch +series that introduced the `Virtually Mapped Kernel Stacks feature +<https://lwn.net/Articles/694348/>` + +Introduction +------------ + +Kernel stack overflows are often hard to debug and make the kernel +susceptible to exploits. Problems could show up at a later time making +it difficult to isolate and root-cause. + +Virtually-mapped kernel stacks with guard pages causes kernel stack +overflows to be caught immediately rather than causing difficult to +diagnose corruptions. + +HAVE_ARCH_VMAP_STACK and VMAP_STACK configuration options enable +support for virtually mapped stacks with guard pages. This feature +causes reliable faults when the stack overflows. The usability of +the stack trace after overflow and response to the overflow itself +is architecture dependent. + +.. note:: + As of this writing, arm64, powerpc, riscv, s390, um, and x86 have + support for VMAP_STACK. + +HAVE_ARCH_VMAP_STACK +-------------------- + +Architectures that can support Virtually Mapped Kernel Stacks should +enable this bool configuration option. The requirements are: + +- vmalloc space must be large enough to hold many kernel stacks. This + may rule out many 32-bit architectures. +- Stacks in vmalloc space need to work reliably. For example, if + vmap page tables are created on demand, either this mechanism + needs to work while the stack points to a virtual address with + unpopulated page tables or arch code (switch_to() and switch_mm(), + most likely) needs to ensure that the stack's page table entries + are populated before running on a possibly unpopulated stack. +- If the stack overflows into a guard page, something reasonable + should happen. The definition of "reasonable" is flexible, but + instantly rebooting without logging anything would be unfriendly. + +VMAP_STACK +---------- + +VMAP_STACK bool configuration option when enabled allocates virtually +mapped task stacks. This option depends on HAVE_ARCH_VMAP_STACK. + +- Enable this if you want the use virtually-mapped kernel stacks + with guard pages. This causes kernel stack overflows to be caught + immediately rather than causing difficult-to-diagnose corruption. + +.. note:: + + Using this feature with KASAN requires architecture support + for backing virtual mappings with real shadow memory, and + KASAN_VMALLOC must be enabled. + +.. note:: + + VMAP_STACK is enabled, it is not possible to run DMA on stack + allocated data. + +Kernel configuration options and dependencies keep changing. Refer to +the latest code base: + +`Kconfig <https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/Kconfig>` + +Allocation +----------- + +When a new kernel thread is created, thread stack is allocated from +virtually contiguous memory pages from the page level allocator. These +pages are mapped into contiguous kernel virtual space with PAGE_KERNEL +protections. + +alloc_thread_stack_node() calls __vmalloc_node_range() to allocate stack +with PAGE_KERNEL protections. + +- Allocated stacks are cached and later reused by new threads, so memcg + accounting is performed manually on assigning/releasing stacks to tasks. + Hence, __vmalloc_node_range is called without __GFP_ACCOUNT. +- vm_struct is cached to be able to find when thread free is initiated + in interrupt context. free_thread_stack() can be called in interrupt + context. +- On arm64, all VMAP's stacks need to have the same alignment to ensure + that VMAP'd stack overflow detection works correctly. Arch specific + vmap stack allocator takes care of this detail. +- This does not address interrupt stacks - according to the original patch + +Thread stack allocation is initiated from clone(), fork(), vfork(), +kernel_thread() via kernel_clone(). Leaving a few hints for searching +the code base to understand when and how thread stack is allocated. + +Bulk of the code is in: +`kernel/fork.c <https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/kernel/fork.c>`. + +stack_vm_area pointer in task_struct keeps track of the virtually allocated +stack and a non-null stack_vm_area pointer serves as a indication that the +virtually mapped kernel stacks are enabled. + +:: + + struct vm_struct *stack_vm_area; + +Stack overflow handling +----------------------- + +Leading and trailing guard pages help detect stack overflows. When stack +overflows into the guard pages, handlers have to be careful not overflow +the stack again. When handlers are called, it is likely that very little +stack space is left. + +On x86, this is done by handling the page fault indicating the kernel +stack overflow on the double-fault stack. + +Testing VMAP allocation with guard pages +---------------------------------------- + +How do we ensure that VMAP_STACK is actually allocating with a leading +and trailing guard page? The following lkdtm tests can help detect any +regressions. + +:: + + void lkdtm_STACK_GUARD_PAGE_LEADING() + void lkdtm_STACK_GUARD_PAGE_TRAILING() + +Conclusions +----------- + +- A percpu cache of vmalloced stacks appears to be a bit faster than a + high-order stack allocation, at least when the cache hits. +- THREAD_INFO_IN_TASK gets rid of arch-specific thread_info entirely and + simply embed the thread_info (containing only flags) and 'int cpu' into + task_struct. +- The thread stack can be free'ed as soon as the task is dead (without + waiting for RCU) and then, if vmapped stacks are in use, cache the + entire stack for reuse on the same cpu. diff --git a/Documentation/x86/sgx.rst b/Documentation/x86/sgx.rst index a608f667fb95..265568a9292c 100644 --- a/Documentation/x86/sgx.rst +++ b/Documentation/x86/sgx.rst @@ -10,7 +10,7 @@ Overview Software Guard eXtensions (SGX) hardware enables for user space applications to set aside private memory regions of code and data: -* Privileged (ring-0) ENCLS functions orchestrate the construction of the. +* Privileged (ring-0) ENCLS functions orchestrate the construction of the regions. * Unprivileged (ring-3) ENCLU functions allow an application to enter and execute inside the regions. @@ -91,7 +91,7 @@ In addition to the traditional compiler and linker build process, SGX has a separate enclave “build” process. Enclaves must be built before they can be executed (entered). The first step in building an enclave is opening the **/dev/sgx_enclave** device. Since enclave memory is protected from direct -access, special privileged instructions are Then used to copy data into enclave +access, special privileged instructions are then used to copy data into enclave pages and establish enclave page permissions. .. kernel-doc:: arch/x86/kernel/cpu/sgx/ioctl.c @@ -126,13 +126,13 @@ the need to juggle signal handlers. ksgxd ===== -SGX support includes a kernel thread called *ksgxwapd*. +SGX support includes a kernel thread called *ksgxd*. EPC sanitization ---------------- ksgxd is started when SGX initializes. Enclave memory is typically ready -For use when the processor powers on or resets. However, if SGX has been in +for use when the processor powers on or resets. However, if SGX has been in use since the reset, enclave pages may be in an inconsistent state. This might occur after a crash and kexec() cycle, for instance. At boot, ksgxd reinitializes all enclave pages so that they can be allocated and re-used. @@ -147,7 +147,7 @@ Page reclaimer Similar to the core kswapd, ksgxd, is responsible for managing the overcommitment of enclave memory. If the system runs out of enclave memory, -*ksgxwapd* “swaps” enclave memory to normal memory. +*ksgxd* “swaps” enclave memory to normal memory. Launch Control ============== @@ -156,7 +156,7 @@ SGX provides a launch control mechanism. After all enclave pages have been copied, kernel executes EINIT function, which initializes the enclave. Only after this the CPU can execute inside the enclave. -ENIT function takes an RSA-3072 signature of the enclave measurement. The function +EINIT function takes an RSA-3072 signature of the enclave measurement. The function checks that the measurement is correct and signature is signed with the key hashed to the four **IA32_SGXLEPUBKEYHASH{0, 1, 2, 3}** MSRs representing the SHA256 of a public key. @@ -184,7 +184,7 @@ CPUs starting from Icelake use Total Memory Encryption (TME) in the place of MEE. TME-based SGX implementations do not have an integrity Merkle tree, which means integrity and replay-attacks are not mitigated. B, it includes additional changes to prevent cipher text from being returned and SW memory -aliases from being Created. +aliases from being created. DMA to enclave memory is blocked by range registers on both MEE and TME systems (SDM section 41.10). |
