diff options
Diffstat (limited to 'Documentation')
510 files changed, 10690 insertions, 3238 deletions
diff --git a/Documentation/ABI/obsolete/sysfs-selinux-checkreqprot b/Documentation/ABI/removed/sysfs-selinux-checkreqprot index ed6b52ca210f..f599a0a87e8b 100644 --- a/Documentation/ABI/obsolete/sysfs-selinux-checkreqprot +++ b/Documentation/ABI/removed/sysfs-selinux-checkreqprot @@ -4,6 +4,9 @@ KernelVersion: 2.6.12-rc2 (predates git) Contact: selinux@vger.kernel.org Description: + REMOVAL UPDATE: The SELinux checkreqprot functionality was removed in + March 2023, the original deprecation notice is shown below. + The selinuxfs "checkreqprot" node allows SELinux to be configured to check the protection requested by userspace for mmap/mprotect calls instead of the actual protection applied by the kernel. diff --git a/Documentation/ABI/obsolete/sysfs-selinux-disable b/Documentation/ABI/removed/sysfs-selinux-disable index c340278e3cf8..cb783c64cab3 100644 --- a/Documentation/ABI/obsolete/sysfs-selinux-disable +++ b/Documentation/ABI/removed/sysfs-selinux-disable @@ -4,6 +4,9 @@ KernelVersion: 2.6.12-rc2 (predates git) Contact: selinux@vger.kernel.org Description: + REMOVAL UPDATE: The SELinux runtime disable functionality was removed + in March 2023, the original deprecation notice is shown below. + The selinuxfs "disable" node allows SELinux to be disabled at runtime prior to a policy being loaded into the kernel. If disabled via this mechanism, SELinux will remain disabled until the system is rebooted. diff --git a/Documentation/ABI/testing/sysfs-driver-intel-i915-hwmon b/Documentation/ABI/testing/sysfs-driver-intel-i915-hwmon index 2d6a472eef88..8d7d8f05f6cd 100644 --- a/Documentation/ABI/testing/sysfs-driver-intel-i915-hwmon +++ b/Documentation/ABI/testing/sysfs-driver-intel-i915-hwmon @@ -14,7 +14,9 @@ Description: RW. Card reactive sustained (PL1/Tau) power limit in microwatts. The power controller will throttle the operating frequency if the power averaged over a window (typically seconds) - exceeds this limit. + exceeds this limit. A read value of 0 means that the PL1 + power limit is disabled, writing 0 disables the + limit. Writing values > 0 will enable the power limit. Only supported for particular Intel i915 graphics platforms. diff --git a/Documentation/ABI/testing/sysfs-platform-intel-ifs b/Documentation/ABI/testing/sysfs-platform-intel-ifs index 55991983d0d0..41b4d5b1e21c 100644 --- a/Documentation/ABI/testing/sysfs-platform-intel-ifs +++ b/Documentation/ABI/testing/sysfs-platform-intel-ifs @@ -1,3 +1,7 @@ +Device instance to test mapping +intel_ifs_0 -> Scan Test +intel_ifs_1 -> Array BIST test + What: /sys/devices/virtual/misc/intel_ifs_<N>/run_test Date: Nov 16 2022 KernelVersion: 6.2 @@ -8,6 +12,7 @@ Description: Write <cpu#> to trigger IFS test for one online core. completes the test for the core containing that thread. Example: to test the core containing cpu5: echo 5 > /sys/devices/virtual/misc/intel_ifs_<N>/run_test +Devices: all What: /sys/devices/virtual/misc/intel_ifs_<N>/status Date: Nov 16 2022 @@ -15,21 +20,25 @@ KernelVersion: 6.2 Contact: "Jithu Joseph" <jithu.joseph@intel.com> Description: The status of the last test. It can be one of "pass", "fail" or "untested". +Devices: all What: /sys/devices/virtual/misc/intel_ifs_<N>/details Date: Nov 16 2022 KernelVersion: 6.2 Contact: "Jithu Joseph" <jithu.joseph@intel.com> Description: Additional information regarding the last test. The details file reports - the hex value of the SCAN_STATUS MSR. Note that the error_code field + the hex value of the STATUS MSR for this test. Note that the error_code field may contain driver defined software code not defined in the Intel SDM. +Devices: all What: /sys/devices/virtual/misc/intel_ifs_<N>/image_version Date: Nov 16 2022 KernelVersion: 6.2 Contact: "Jithu Joseph" <jithu.joseph@intel.com> -Description: Version (hexadecimal) of loaded IFS binary image. If no scan image - is loaded reports "none". +Description: Version (hexadecimal) of loaded IFS test image. If no test image + is loaded reports "none". Only present for device instances where a test image + is applicable. +Devices: intel_ifs_0 What: /sys/devices/virtual/misc/intel_ifs_<N>/current_batch Date: Nov 16 2022 @@ -39,3 +48,5 @@ Description: Write a number less than or equal to 0xff to load an IFS test image The number written treated as the 2 digit suffix in the following file name: /lib/firmware/intel/ifs_<N>/ff-mm-ss-02x.scan Reading the file will provide the suffix of the currently loaded IFS test image. + This file is present only for device instances where a test image is applicable. +Devices: intel_ifs_0 diff --git a/Documentation/ABI/testing/sysfs-platform-mellanox-bootctl b/Documentation/ABI/testing/sysfs-platform-mellanox-bootctl index e79ca22e2f45..9b99a81babb1 100644 --- a/Documentation/ABI/testing/sysfs-platform-mellanox-bootctl +++ b/Documentation/ABI/testing/sysfs-platform-mellanox-bootctl @@ -68,3 +68,10 @@ Description: Wasted burnt and invalid Invalid not burnt but marked as valid (error state). ======= =============================================== + +What: /sys/bus/platform/devices/MLNXBF04:00/bootfifo +Date: Apr 2023 +KernelVersion: 6.4 +Contact: "Liming Sun <limings@nvidia.com>" +Description: + The file used to access the BlueField boot fifo. diff --git a/Documentation/RCU/Design/Expedited-Grace-Periods/Expedited-Grace-Periods.rst b/Documentation/RCU/Design/Expedited-Grace-Periods/Expedited-Grace-Periods.rst index c9c957c85bac..93d899d53258 100644 --- a/Documentation/RCU/Design/Expedited-Grace-Periods/Expedited-Grace-Periods.rst +++ b/Documentation/RCU/Design/Expedited-Grace-Periods/Expedited-Grace-Periods.rst @@ -277,7 +277,7 @@ the following access functions: Again, only one request in a given batch need actually carry out a grace-period operation, which means there must be an efficient way to -identify which of many concurrent reqeusts will initiate the grace +identify which of many concurrent requests will initiate the grace period, and that there be an efficient way for the remaining requests to wait for that grace period to complete. However, that is the topic of the next section. @@ -405,7 +405,7 @@ Use of Workqueues In earlier implementations, the task requesting the expedited grace period also drove it to completion. This straightforward approach had the disadvantage of needing to account for POSIX signals sent to user -tasks, so more recent implemementations use the Linux kernel's +tasks, so more recent implementations use the Linux kernel's workqueues (see Documentation/core-api/workqueue.rst). The requesting task still does counter snapshotting and funnel-lock @@ -465,7 +465,7 @@ corresponding disadvantage that workqueues cannot be used until they are initialized, which does not happen until some time after the scheduler spawns the first task. Given that there are parts of the kernel that really do want to execute grace periods during this mid-boot “dead -zoneâ€, expedited grace periods must do something else during thie time. +zoneâ€, expedited grace periods must do something else during this time. What they do is to fall back to the old practice of requiring that the requesting task drive the expedited grace period, as was the case before diff --git a/Documentation/RCU/Design/Memory-Ordering/Tree-RCU-Memory-Ordering.rst b/Documentation/RCU/Design/Memory-Ordering/Tree-RCU-Memory-Ordering.rst index 7fdf151a8680..5750f125361b 100644 --- a/Documentation/RCU/Design/Memory-Ordering/Tree-RCU-Memory-Ordering.rst +++ b/Documentation/RCU/Design/Memory-Ordering/Tree-RCU-Memory-Ordering.rst @@ -168,7 +168,7 @@ an ``atomic_add_return()`` of zero) to detect idle CPUs. +-----------------------------------------------------------------------+ The approach must be extended to handle one final case, that of waking a -task blocked in ``synchronize_rcu()``. This task might be affinitied to +task blocked in ``synchronize_rcu()``. This task might be affined to a CPU that is not yet aware that the grace period has ended, and thus might not yet be subject to the grace period's memory ordering. Therefore, there is an ``smp_mb()`` after the return from diff --git a/Documentation/RCU/RTFP.txt b/Documentation/RCU/RTFP.txt index 588d97366a46..db8f16b392aa 100644 --- a/Documentation/RCU/RTFP.txt +++ b/Documentation/RCU/RTFP.txt @@ -201,7 +201,7 @@ work looked at debugging uses of RCU [Seyster:2011:RFA:2075416.2075425]. In 2012, Josh Triplett received his Ph.D. with his dissertation covering RCU-protected resizable hash tables and the relationship between memory barriers and read-side traversal order: If the updater -is making changes in the opposite direction from the read-side traveral +is making changes in the opposite direction from the read-side traversal order, the updater need only execute a memory-barrier instruction, but if in the same direction, the updater needs to wait for a grace period between the individual updates [JoshTriplettPhD]. Also in 2012, @@ -1245,7 +1245,7 @@ Oregon Health and Sciences University" [Viewed September 5, 2005]" ,annotation={ First posting showing how RCU can be safely adapted for - preemptable RCU read side critical sections. + preemptible RCU read side critical sections. } } @@ -1888,7 +1888,7 @@ Revised: \url{https://lore.kernel.org/r/20070910183004.GA3299@linux.vnet.ibm.com} [Viewed October 25, 2007]" ,annotation={ - Final patch for preemptable RCU to -rt. (Later patches were + Final patch for preemptible RCU to -rt. (Later patches were to mainline, eventually incorporated.) } } @@ -2275,7 +2275,7 @@ lot of {Linux} into your technology!!!" \url{https://lore.kernel.org/r/20090724001429.GA17374@linux.vnet.ibm.com} [Viewed August 15, 2009]" ,annotation={ - First posting of simple and fast preemptable RCU. + First posting of simple and fast preemptible RCU. } } @@ -2639,7 +2639,7 @@ lot of {Linux} into your technology!!!" RCU-protected hash tables, barriers vs. read-side traversal order. . If the updater is making changes in the opposite direction from - the read-side traveral order, the updater need only execute a + the read-side traversal order, the updater need only execute a memory-barrier instruction, but if in the same direction, the updater needs to wait for a grace period between the individual updates. diff --git a/Documentation/RCU/UP.rst b/Documentation/RCU/UP.rst index 8b20fd45f255..4060d7a2f62a 100644 --- a/Documentation/RCU/UP.rst +++ b/Documentation/RCU/UP.rst @@ -107,7 +107,7 @@ UP systems, including PREEMPT SMP builds running on UP systems. Quick Quiz #3: Why can't synchronize_rcu() return immediately on UP systems running - preemptable RCU? + preemptible RCU? .. _answer_quick_quiz_up: @@ -143,7 +143,7 @@ Answer to Quick Quiz #2: Answer to Quick Quiz #3: Why can't synchronize_rcu() return immediately on UP systems - running preemptable RCU? + running preemptible RCU? Because some other task might have been preempted in the middle of an RCU read-side critical section. If synchronize_rcu() diff --git a/Documentation/RCU/checklist.rst b/Documentation/RCU/checklist.rst index cc361fb01ed4..bd3c58c44bef 100644 --- a/Documentation/RCU/checklist.rst +++ b/Documentation/RCU/checklist.rst @@ -70,7 +70,7 @@ over a rather long period of time, but improvements are always welcome! can serve as rcu_read_lock_sched(), but is less readable and prevents lockdep from detecting locking issues. - Please not that you *cannot* rely on code known to be built + Please note that you *cannot* rely on code known to be built only in non-preemptible kernels. Such code can and will break, especially in kernels built with CONFIG_PREEMPT_COUNT=y. diff --git a/Documentation/RCU/lockdep.rst b/Documentation/RCU/lockdep.rst index 2749f43ec1b0..69e73a39bd11 100644 --- a/Documentation/RCU/lockdep.rst +++ b/Documentation/RCU/lockdep.rst @@ -65,7 +65,7 @@ checking of rcu_dereference() primitives: rcu_access_pointer(p): Return the value of the pointer and omit all barriers, but retain the compiler constraints that prevent duplicating - or coalescsing. This is useful when testing the + or coalescing. This is useful when testing the value of the pointer itself, for example, against NULL. The rcu_dereference_check() check expression can be any boolean diff --git a/Documentation/RCU/torture.rst b/Documentation/RCU/torture.rst index 0316ba0c6922..b3b6dfa85248 100644 --- a/Documentation/RCU/torture.rst +++ b/Documentation/RCU/torture.rst @@ -216,7 +216,7 @@ Kernel boot arguments can also be supplied, for example, to control rcutorture's module parameters. For example, to test a change to RCU's CPU stall-warning code, use "--bootargs 'rcutorture.stall_cpu=30'". This will of course result in the scripting reporting a failure, namely -the resuling RCU CPU stall warning. As noted above, reducing memory may +the resulting RCU CPU stall warning. As noted above, reducing memory may require disabling rcutorture's callback-flooding tests:: kvm.sh --cpus 448 --configs '56*TREE04' --memory 128M \ @@ -370,5 +370,5 @@ You can also re-run a previous remote run in a manner similar to kvm.sh: tools/testing/selftests/rcutorture/res/2022.11.03-11.26.28-remote \ --duration 24h -In this case, most of the kvm-again.sh parmeters may be supplied following +In this case, most of the kvm-again.sh parameters may be supplied following the pathname of the old run-results directory. diff --git a/Documentation/RCU/whatisRCU.rst b/Documentation/RCU/whatisRCU.rst index 2c5563a91998..8eddef28d3a1 100644 --- a/Documentation/RCU/whatisRCU.rst +++ b/Documentation/RCU/whatisRCU.rst @@ -597,10 +597,10 @@ to avoid having to write your own callback:: If the occasional sleep is permitted, the single-argument form may be used, omitting the rcu_head structure from struct foo. - kfree_rcu(old_fp); + kfree_rcu_mightsleep(old_fp); -This variant of kfree_rcu() almost never blocks, but might do so by -invoking synchronize_rcu() in response to memory-allocation failure. +This variant almost never blocks, but might do so by invoking +synchronize_rcu() in response to memory-allocation failure. Again, see checklist.rst for additional rules governing the use of RCU. diff --git a/Documentation/accel/index.rst b/Documentation/accel/index.rst index 2b43c9a7f67b..e94a0160b6a0 100644 --- a/Documentation/accel/index.rst +++ b/Documentation/accel/index.rst @@ -8,6 +8,7 @@ Compute Accelerators :maxdepth: 1 introduction + qaic/index .. only:: subproject and html diff --git a/Documentation/accel/qaic/aic100.rst b/Documentation/accel/qaic/aic100.rst new file mode 100644 index 000000000000..c80d0f1307db --- /dev/null +++ b/Documentation/accel/qaic/aic100.rst @@ -0,0 +1,510 @@ +.. SPDX-License-Identifier: GPL-2.0-only + +=============================== + Qualcomm Cloud AI 100 (AIC100) +=============================== + +Overview +======== + +The Qualcomm Cloud AI 100/AIC100 family of products (including SA9000P - part of +Snapdragon Ride) are PCIe adapter cards which contain a dedicated SoC ASIC for +the purpose of efficiently running Artificial Intelligence (AI) Deep Learning +inference workloads. They are AI accelerators. + +The PCIe interface of AIC100 is capable of PCIe Gen4 speeds over eight lanes +(x8). An individual SoC on a card can have up to 16 NSPs for running workloads. +Each SoC has an A53 management CPU. On card, there can be up to 32 GB of DDR. + +Multiple AIC100 cards can be hosted in a single system to scale overall +performance. AIC100 cards are multi-user capable and able to execute workloads +from multiple users in a concurrent manner. + +Hardware Description +==================== + +An AIC100 card consists of an AIC100 SoC, on-card DDR, and a set of misc +peripherals (PMICs, etc). + +An AIC100 card can either be a PCIe HHHL form factor (a traditional PCIe card), +or a Dual M.2 card. Both use PCIe to connect to the host system. + +As a PCIe endpoint/adapter, AIC100 uses the standard VendorID(VID)/ +DeviceID(DID) combination to uniquely identify itself to the host. AIC100 +uses the standard Qualcomm VID (0x17cb). All AIC100 SKUs use the same +AIC100 DID (0xa100). + +AIC100 does not implement FLR (function level reset). + +AIC100 implements MSI but does not implement MSI-X. AIC100 requires 17 MSIs to +operate (1 for MHI, 16 for the DMA Bridge). + +As a PCIe device, AIC100 utilizes BARs to provide host interfaces to the device +hardware. AIC100 provides 3, 64-bit BARs. + +* The first BAR is 4K in size, and exposes the MHI interface to the host. + +* The second BAR is 2M in size, and exposes the DMA Bridge interface to the + host. + +* The third BAR is variable in size based on an individual AIC100's + configuration, but defaults to 64K. This BAR currently has no purpose. + +From the host perspective, AIC100 has several key hardware components - + +* MHI (Modem Host Interface) +* QSM (QAIC Service Manager) +* NSPs (Neural Signal Processor) +* DMA Bridge +* DDR + +MHI +--- + +AIC100 has one MHI interface over PCIe. MHI itself is documented at +Documentation/mhi/index.rst MHI is the mechanism the host uses to communicate +with the QSM. Except for workload data via the DMA Bridge, all interaction with +the device occurs via MHI. + +QSM +--- + +QAIC Service Manager. This is an ARM A53 CPU that runs the primary +firmware of the card and performs on-card management tasks. It also +communicates with the host via MHI. Each AIC100 has one of +these. + +NSP +--- + +Neural Signal Processor. Each AIC100 has up to 16 of these. These are +the processors that run the workloads on AIC100. Each NSP is a Qualcomm Hexagon +(Q6) DSP with HVX and HMX. Each NSP can only run one workload at a time, but +multiple NSPs may be assigned to a single workload. Since each NSP can only run +one workload, AIC100 is limited to 16 concurrent workloads. Workload +"scheduling" is under the purview of the host. AIC100 does not automatically +timeslice. + +DMA Bridge +---------- + +The DMA Bridge is custom DMA engine that manages the flow of data +in and out of workloads. AIC100 has one of these. The DMA Bridge has 16 +channels, each consisting of a set of request/response FIFOs. Each active +workload is assigned a single DMA Bridge channel. The DMA Bridge exposes +hardware registers to manage the FIFOs (head/tail pointers), but requires host +memory to store the FIFOs. + +DDR +--- + +AIC100 has on-card DDR. In total, an AIC100 can have up to 32 GB of DDR. +This DDR is used to store workloads, data for the workloads, and is used by the +QSM for managing the device. NSPs are granted access to sections of the DDR by +the QSM. The host does not have direct access to the DDR, and must make +requests to the QSM to transfer data to the DDR. + +High-level Use Flow +=================== + +AIC100 is a multi-user, programmable accelerator typically used for running +neural networks in inferencing mode to efficiently perform AI operations. +AIC100 is not intended for training neural networks. AIC100 can be utilized +for generic compute workloads. + +Assuming a user wants to utilize AIC100, they would follow these steps: + +1. Compile the workload into an ELF targeting the NSP(s) +2. Make requests to the QSM to load the workload and related artifacts into the + device DDR +3. Make a request to the QSM to activate the workload onto a set of idle NSPs +4. Make requests to the DMA Bridge to send input data to the workload to be + processed, and other requests to receive processed output data from the + workload. +5. Once the workload is no longer required, make a request to the QSM to + deactivate the workload, thus putting the NSPs back into an idle state. +6. Once the workload and related artifacts are no longer needed for future + sessions, make requests to the QSM to unload the data from DDR. This frees + the DDR to be used by other users. + + +Boot Flow +========= + +AIC100 uses a flashless boot flow, derived from Qualcomm MSMs. + +When AIC100 is first powered on, it begins executing PBL (Primary Bootloader) +from ROM. PBL enumerates the PCIe link, and initializes the BHI (Boot Host +Interface) component of MHI. + +Using BHI, the host points PBL to the location of the SBL (Secondary Bootloader) +image. The PBL pulls the image from the host, validates it, and begins +execution of SBL. + +SBL initializes MHI, and uses MHI to notify the host that the device has entered +the SBL stage. SBL performs a number of operations: + +* SBL initializes the majority of hardware (anything PBL left uninitialized), + including DDR. +* SBL offloads the bootlog to the host. +* SBL synchronizes timestamps with the host for future logging. +* SBL uses the Sahara protocol to obtain the runtime firmware images from the + host. + +Once SBL has obtained and validated the runtime firmware, it brings the NSPs out +of reset, and jumps into the QSM. + +The QSM uses MHI to notify the host that the device has entered the QSM stage +(AMSS in MHI terms). At this point, the AIC100 device is fully functional, and +ready to process workloads. + +Userspace components +==================== + +Compiler +-------- + +An open compiler for AIC100 based on upstream LLVM can be found at: +https://github.com/quic/software-kit-for-qualcomm-cloud-ai-100-cc + +Usermode Driver (UMD) +--------------------- + +An open UMD that interfaces with the qaic kernel driver can be found at: +https://github.com/quic/software-kit-for-qualcomm-cloud-ai-100 + +Sahara loader +------------- + +An open implementation of the Sahara protocol called kickstart can be found at: +https://github.com/andersson/qdl + +MHI Channels +============ + +AIC100 defines a number of MHI channels for different purposes. This is a list +of the defined channels, and their uses. + ++----------------+---------+----------+----------------------------------------+ +| Channel name | IDs | EEs | Purpose | ++================+=========+==========+========================================+ +| QAIC_LOOPBACK | 0 & 1 | AMSS | Any data sent to the device on this | +| | | | channel is sent back to the host. | ++----------------+---------+----------+----------------------------------------+ +| QAIC_SAHARA | 2 & 3 | SBL | Used by SBL to obtain the runtime | +| | | | firmware from the host. | ++----------------+---------+----------+----------------------------------------+ +| QAIC_DIAG | 4 & 5 | AMSS | Used to communicate with QSM via the | +| | | | DIAG protocol. | ++----------------+---------+----------+----------------------------------------+ +| QAIC_SSR | 6 & 7 | AMSS | Used to notify the host of subsystem | +| | | | restart events, and to offload SSR | +| | | | crashdumps. | ++----------------+---------+----------+----------------------------------------+ +| QAIC_QDSS | 8 & 9 | AMSS | Used for the Qualcomm Debug Subsystem. | ++----------------+---------+----------+----------------------------------------+ +| QAIC_CONTROL | 10 & 11 | AMSS | Used for the Neural Network Control | +| | | | (NNC) protocol. This is the primary | +| | | | channel between host and QSM for | +| | | | managing workloads. | ++----------------+---------+----------+----------------------------------------+ +| QAIC_LOGGING | 12 & 13 | SBL | Used by the SBL to send the bootlog to | +| | | | the host. | ++----------------+---------+----------+----------------------------------------+ +| QAIC_STATUS | 14 & 15 | AMSS | Used to notify the host of Reliability,| +| | | | Accessibility, Serviceability (RAS) | +| | | | events. | ++----------------+---------+----------+----------------------------------------+ +| QAIC_TELEMETRY | 16 & 17 | AMSS | Used to get/set power/thermal/etc | +| | | | attributes. | ++----------------+---------+----------+----------------------------------------+ +| QAIC_DEBUG | 18 & 19 | AMSS | Not used. | ++----------------+---------+----------+----------------------------------------+ +| QAIC_TIMESYNC | 20 & 21 | SBL/AMSS | Used to synchronize timestamps in the | +| | | | device side logs with the host time | +| | | | source. | ++----------------+---------+----------+----------------------------------------+ + +DMA Bridge +========== + +Overview +-------- + +The DMA Bridge is one of the main interfaces to the host from the device +(the other being MHI). As part of activating a workload to run on NSPs, the QSM +assigns that network a DMA Bridge channel. A workload's DMA Bridge channel +(DBC for short) is solely for the use of that workload and is not shared with +other workloads. + +Each DBC is a pair of FIFOs that manage data in and out of the workload. One +FIFO is the request FIFO. The other FIFO is the response FIFO. + +Each DBC contains 4 registers in hardware: + +* Request FIFO head pointer (offset 0x0). Read only by the host. Indicates the + latest item in the FIFO the device has consumed. +* Request FIFO tail pointer (offset 0x4). Read/write by the host. Host + increments this register to add new items to the FIFO. +* Response FIFO head pointer (offset 0x8). Read/write by the host. Indicates + the latest item in the FIFO the host has consumed. +* Response FIFO tail pointer (offset 0xc). Read only by the host. Device + increments this register to add new items to the FIFO. + +The values in each register are indexes in the FIFO. To get the location of the +FIFO element pointed to by the register: FIFO base address + register * element +size. + +DBC registers are exposed to the host via the second BAR. Each DBC consumes +4KB of space in the BAR. + +The actual FIFOs are backed by host memory. When sending a request to the QSM +to activate a network, the host must donate memory to be used for the FIFOs. +Due to internal mapping limitations of the device, a single contiguous chunk of +memory must be provided per DBC, which hosts both FIFOs. The request FIFO will +consume the beginning of the memory chunk, and the response FIFO will consume +the end of the memory chunk. + +Request FIFO +------------ + +A request FIFO element has the following structure: + +.. code-block:: c + + struct request_elem { + u16 req_id; + u8 seq_id; + u8 pcie_dma_cmd; + u32 reserved; + u64 pcie_dma_source_addr; + u64 pcie_dma_dest_addr; + u32 pcie_dma_len; + u32 reserved; + u64 doorbell_addr; + u8 doorbell_attr; + u8 reserved; + u16 reserved; + u32 doorbell_data; + u32 sem_cmd0; + u32 sem_cmd1; + u32 sem_cmd2; + u32 sem_cmd3; + }; + +Request field descriptions: + +req_id + request ID. A request FIFO element and a response FIFO element with + the same request ID refer to the same command. + +seq_id + sequence ID within a request. Ignored by the DMA Bridge. + +pcie_dma_cmd + describes the DMA element of this request. + + * Bit(7) is the force msi flag, which overrides the DMA Bridge MSI logic + and generates a MSI when this request is complete, and QSM + configures the DMA Bridge to look at this bit. + * Bits(6:5) are reserved. + * Bit(4) is the completion code flag, and indicates that the DMA Bridge + shall generate a response FIFO element when this request is + complete. + * Bit(3) indicates if this request is a linked list transfer(0) or a bulk + transfer(1). + * Bit(2) is reserved. + * Bits(1:0) indicate the type of transfer. No transfer(0), to device(1), + from device(2). Value 3 is illegal. + +pcie_dma_source_addr + source address for a bulk transfer, or the address of the linked list. + +pcie_dma_dest_addr + destination address for a bulk transfer. + +pcie_dma_len + length of the bulk transfer. Note that the size of this field + limits transfers to 4G in size. + +doorbell_addr + address of the doorbell to ring when this request is complete. + +doorbell_attr + doorbell attributes. + + * Bit(7) indicates if a write to a doorbell is to occur. + * Bits(6:2) are reserved. + * Bits(1:0) contain the encoding of the doorbell length. 0 is 32-bit, + 1 is 16-bit, 2 is 8-bit, 3 is reserved. The doorbell address + must be naturally aligned to the specified length. + +doorbell_data + data to write to the doorbell. Only the bits corresponding to + the doorbell length are valid. + +sem_cmdN + semaphore command. + + * Bit(31) indicates this semaphore command is enabled. + * Bit(30) is the to-device DMA fence. Block this request until all + to-device DMA transfers are complete. + * Bit(29) is the from-device DMA fence. Block this request until all + from-device DMA transfers are complete. + * Bits(28:27) are reserved. + * Bits(26:24) are the semaphore command. 0 is NOP. 1 is init with the + specified value. 2 is increment. 3 is decrement. 4 is wait + until the semaphore is equal to the specified value. 5 is wait + until the semaphore is greater or equal to the specified value. + 6 is "P", wait until semaphore is greater than 0, then + decrement by 1. 7 is reserved. + * Bit(23) is reserved. + * Bit(22) is the semaphore sync. 0 is post sync, which means that the + semaphore operation is done after the DMA transfer. 1 is + presync, which gates the DMA transfer. Only one presync is + allowed per request. + * Bit(21) is reserved. + * Bits(20:16) is the index of the semaphore to operate on. + * Bits(15:12) are reserved. + * Bits(11:0) are the semaphore value to use in operations. + +Overall, a request is processed in 4 steps: + +1. If specified, the presync semaphore condition must be true +2. If enabled, the DMA transfer occurs +3. If specified, the postsync semaphore conditions must be true +4. If enabled, the doorbell is written + +By using the semaphores in conjunction with the workload running on the NSPs, +the data pipeline can be synchronized such that the host can queue multiple +requests of data for the workload to process, but the DMA Bridge will only copy +the data into the memory of the workload when the workload is ready to process +the next input. + +Response FIFO +------------- + +Once a request is fully processed, a response FIFO element is generated if +specified in pcie_dma_cmd. The structure of a response FIFO element: + +.. code-block:: c + + struct response_elem { + u16 req_id; + u16 completion_code; + }; + +req_id + matches the req_id of the request that generated this element. + +completion_code + status of this request. 0 is success. Non-zero is an error. + +The DMA Bridge will generate a MSI to the host as a reaction to activity in the +response FIFO of a DBC. The DMA Bridge hardware has an IRQ storm mitigation +algorithm, where it will only generate a MSI when the response FIFO transitions +from empty to non-empty (unless force MSI is enabled and triggered). In +response to this MSI, the host is expected to drain the response FIFO, and must +take care to handle any race conditions between draining the FIFO, and the +device inserting elements into the FIFO. + +Neural Network Control (NNC) Protocol +===================================== + +The NNC protocol is how the host makes requests to the QSM to manage workloads. +It uses the QAIC_CONTROL MHI channel. + +Each NNC request is packaged into a message. Each message is a series of +transactions. A passthrough type transaction can contain elements known as +commands. + +QSM requires NNC messages be little endian encoded and the fields be naturally +aligned. Since there are 64-bit elements in some NNC messages, 64-bit alignment +must be maintained. + +A message contains a header and then a series of transactions. A message may be +at most 4K in size from QSM to the host. From the host to the QSM, a message +can be at most 64K (maximum size of a single MHI packet), but there is a +continuation feature where message N+1 can be marked as a continuation of +message N. This is used for exceedingly large DMA xfer transactions. + +Transaction descriptions +------------------------ + +passthrough + Allows userspace to send an opaque payload directly to the QSM. + This is used for NNC commands. Userspace is responsible for managing + the QSM message requirements in the payload. + +dma_xfer + DMA transfer. Describes an object that the QSM should DMA into the + device via address and size tuples. + +activate + Activate a workload onto NSPs. The host must provide memory to be + used by the DBC. + +deactivate + Deactivate an active workload and return the NSPs to idle. + +status + Query the QSM about it's NNC implementation. Returns the NNC version, + and if CRC is used. + +terminate + Release a user's resources. + +dma_xfer_cont + Continuation of a previous DMA transfer. If a DMA transfer + cannot be specified in a single message (highly fragmented), this + transaction can be used to specify more ranges. + +validate_partition + Query to QSM to determine if a partition identifier is valid. + +Each message is tagged with a user id, and a partition id. The user id allows +QSM to track resources, and release them when the user goes away (eg the process +crashes). A partition id identifies the resource partition that QSM manages, +which this message applies to. + +Messages may have CRCs. Messages should have CRCs applied until the QSM +reports via the status transaction that CRCs are not needed. The QSM on the +SA9000P requires CRCs for black channel safing. + +Subsystem Restart (SSR) +======================= + +SSR is the concept of limiting the impact of an error. An AIC100 device may +have multiple users, each with their own workload running. If the workload of +one user crashes, the fallout of that should be limited to that workload and not +impact other workloads. SSR accomplishes this. + +If a particular workload crashes, QSM notifies the host via the QAIC_SSR MHI +channel. This notification identifies the workload by it's assigned DBC. A +multi-stage recovery process is then used to cleanup both sides, and get the +DBC/NSPs into a working state. + +When SSR occurs, any state in the workload is lost. Any inputs that were in +process, or queued by not yet serviced, are lost. The loaded artifacts will +remain in on-card DDR, but the host will need to re-activate the workload if +it desires to recover the workload. + +Reliability, Accessibility, Serviceability (RAS) +================================================ + +AIC100 is expected to be deployed in server systems where RAS ideology is +applied. Simply put, RAS is the concept of detecting, classifying, and +reporting errors. While PCIe has AER (Advanced Error Reporting) which factors +into RAS, AER does not allow for a device to report details about internal +errors. Therefore, AIC100 implements a custom RAS mechanism. When a RAS event +occurs, QSM will report the event with appropriate details via the QAIC_STATUS +MHI channel. A sysadmin may determine that a particular device needs +additional service based on RAS reports. + +Telemetry +========= + +QSM has the ability to report various physical attributes of the device, and in +some cases, to allow the host to control them. Examples include thermal limits, +thermal readings, and power readings. These items are communicated via the +QAIC_TELEMETRY MHI channel. diff --git a/Documentation/accel/qaic/index.rst b/Documentation/accel/qaic/index.rst new file mode 100644 index 000000000000..ad19b88d1a66 --- /dev/null +++ b/Documentation/accel/qaic/index.rst @@ -0,0 +1,13 @@ +.. SPDX-License-Identifier: GPL-2.0-only + +===================================== + accel/qaic Qualcomm Cloud AI driver +===================================== + +The accel/qaic driver supports the Qualcomm Cloud AI machine learning +accelerator cards. + +.. toctree:: + + qaic + aic100 diff --git a/Documentation/accel/qaic/qaic.rst b/Documentation/accel/qaic/qaic.rst new file mode 100644 index 000000000000..72a70ab6e3a8 --- /dev/null +++ b/Documentation/accel/qaic/qaic.rst @@ -0,0 +1,170 @@ +.. SPDX-License-Identifier: GPL-2.0-only + +============= + QAIC driver +============= + +The QAIC driver is the Kernel Mode Driver (KMD) for the AIC100 family of AI +accelerator products. + +Interrupts +========== + +While the AIC100 DMA Bridge hardware implements an IRQ storm mitigation +mechanism, it is still possible for an IRQ storm to occur. A storm can happen +if the workload is particularly quick, and the host is responsive. If the host +can drain the response FIFO as quickly as the device can insert elements into +it, then the device will frequently transition the response FIFO from empty to +non-empty and generate MSIs at a rate equivalent to the speed of the +workload's ability to process inputs. The lprnet (license plate reader network) +workload is known to trigger this condition, and can generate in excess of 100k +MSIs per second. It has been observed that most systems cannot tolerate this +for long, and will crash due to some form of watchdog due to the overhead of +the interrupt controller interrupting the host CPU. + +To mitigate this issue, the QAIC driver implements specific IRQ handling. When +QAIC receives an IRQ, it disables that line. This prevents the interrupt +controller from interrupting the CPU. Then AIC drains the FIFO. Once the FIFO +is drained, QAIC implements a "last chance" polling algorithm where QAIC will +sleep for a time to see if the workload will generate more activity. The IRQ +line remains disabled during this time. If no activity is detected, QAIC exits +polling mode and reenables the IRQ line. + +This mitigation in QAIC is very effective. The same lprnet usecase that +generates 100k IRQs per second (per /proc/interrupts) is reduced to roughly 64 +IRQs over 5 minutes while keeping the host system stable, and having the same +workload throughput performance (within run to run noise variation). + + +Neural Network Control (NNC) Protocol +===================================== + +The implementation of NNC is split between the KMD (QAIC) and UMD. In general +QAIC understands how to encode/decode NNC wire protocol, and elements of the +protocol which require kernel space knowledge to process (for example, mapping +host memory to device IOVAs). QAIC understands the structure of a message, and +all of the transactions. QAIC does not understand commands (the payload of a +passthrough transaction). + +QAIC handles and enforces the required little endianness and 64-bit alignment, +to the degree that it can. Since QAIC does not know the contents of a +passthrough transaction, it relies on the UMD to satisfy the requirements. + +The terminate transaction is of particular use to QAIC. QAIC is not aware of +the resources that are loaded onto a device since the majority of that activity +occurs within NNC commands. As a result, QAIC does not have the means to +roll back userspace activity. To ensure that a userspace client's resources +are fully released in the case of a process crash, or a bug, QAIC uses the +terminate command to let QSM know when a user has gone away, and the resources +can be released. + +QSM can report a version number of the NNC protocol it supports. This is in the +form of a Major number and a Minor number. + +Major number updates indicate changes to the NNC protocol which impact the +message format, or transactions (impacts QAIC). + +Minor number updates indicate changes to the NNC protocol which impact the +commands (does not impact QAIC). + +uAPI +==== + +QAIC defines a number of driver specific IOCTLs as part of the userspace API. +This section describes those APIs. + +DRM_IOCTL_QAIC_MANAGE + This IOCTL allows userspace to send a NNC request to the QSM. The call will + block until a response is received, or the request has timed out. + +DRM_IOCTL_QAIC_CREATE_BO + This IOCTL allows userspace to allocate a buffer object (BO) which can send + or receive data from a workload. The call will return a GEM handle that + represents the allocated buffer. The BO is not usable until it has been + sliced (see DRM_IOCTL_QAIC_ATTACH_SLICE_BO). + +DRM_IOCTL_QAIC_MMAP_BO + This IOCTL allows userspace to prepare an allocated BO to be mmap'd into the + userspace process. + +DRM_IOCTL_QAIC_ATTACH_SLICE_BO + This IOCTL allows userspace to slice a BO in preparation for sending the BO + to the device. Slicing is the operation of describing what portions of a BO + get sent where to a workload. This requires a set of DMA transfers for the + DMA Bridge, and as such, locks the BO to a specific DBC. + +DRM_IOCTL_QAIC_EXECUTE_BO + This IOCTL allows userspace to submit a set of sliced BOs to the device. The + call is non-blocking. Success only indicates that the BOs have been queued + to the device, but does not guarantee they have been executed. + +DRM_IOCTL_QAIC_PARTIAL_EXECUTE_BO + This IOCTL operates like DRM_IOCTL_QAIC_EXECUTE_BO, but it allows userspace + to shrink the BOs sent to the device for this specific call. If a BO + typically has N inputs, but only a subset of those is available, this IOCTL + allows userspace to indicate that only the first M bytes of the BO should be + sent to the device to minimize data transfer overhead. This IOCTL dynamically + recomputes the slicing, and therefore has some processing overhead before the + BOs can be queued to the device. + +DRM_IOCTL_QAIC_WAIT_BO + This IOCTL allows userspace to determine when a particular BO has been + processed by the device. The call will block until either the BO has been + processed and can be re-queued to the device, or a timeout occurs. + +DRM_IOCTL_QAIC_PERF_STATS_BO + This IOCTL allows userspace to collect performance statistics on the most + recent execution of a BO. This allows userspace to construct an end to end + timeline of the BO processing for a performance analysis. + +DRM_IOCTL_QAIC_PART_DEV + This IOCTL allows userspace to request a duplicate "shadow device". This extra + accelN device is associated with a specific partition of resources on the + AIC100 device and can be used for limiting a process to some subset of + resources. + +Userspace Client Isolation +========================== + +AIC100 supports multiple clients. Multiple DBCs can be consumed by a single +client, and multiple clients can each consume one or more DBCs. Workloads +may contain sensitive information therefore only the client that owns the +workload should be allowed to interface with the DBC. + +Clients are identified by the instance associated with their open(). A client +may only use memory they allocate, and DBCs that are assigned to their +workloads. Attempts to access resources assigned to other clients will be +rejected. + +Module parameters +================= + +QAIC supports the following module parameters: + +**datapath_polling (bool)** + +Configures QAIC to use a polling thread for datapath events instead of relying +on the device interrupts. Useful for platforms with broken multiMSI. Must be +set at QAIC driver initialization. Default is 0 (off). + +**mhi_timeout_ms (unsigned int)** + +Sets the timeout value for MHI operations in milliseconds (ms). Must be set +at the time the driver detects a device. Default is 2000 (2 seconds). + +**control_resp_timeout_s (unsigned int)** + +Sets the timeout value for QSM responses to NNC messages in seconds (s). Must +be set at the time the driver is sending a request to QSM. Default is 60 (one +minute). + +**wait_exec_default_timeout_ms (unsigned int)** + +Sets the default timeout for the wait_exec ioctl in milliseconds (ms). Must be +set prior to the waic_exec ioctl call. A value specified in the ioctl call +overrides this for that call. Default is 5000 (5 seconds). + +**datapath_poll_interval_us (unsigned int)** + +Sets the polling interval in microseconds (us) when datapath polling is active. +Takes effect at the next polling interval. Default is 100 (100 us). diff --git a/Documentation/admin-guide/gpio/sysfs.rst b/Documentation/admin-guide/gpio/sysfs.rst index ec09ffd983e7..35171d15f78d 100644 --- a/Documentation/admin-guide/gpio/sysfs.rst +++ b/Documentation/admin-guide/gpio/sysfs.rst @@ -145,7 +145,7 @@ requested using gpio_request():: /* export the GPIO to userspace */ int gpiod_export(struct gpio_desc *desc, bool direction_may_change); - /* reverse gpio_export() */ + /* reverse gpiod_export() */ void gpiod_unexport(struct gpio_desc *desc); /* create a sysfs link to an exported GPIO node */ diff --git a/Documentation/admin-guide/hw-vuln/mds.rst b/Documentation/admin-guide/hw-vuln/mds.rst index f491de74ea79..48ca0bd85604 100644 --- a/Documentation/admin-guide/hw-vuln/mds.rst +++ b/Documentation/admin-guide/hw-vuln/mds.rst @@ -58,7 +58,7 @@ Because the buffers are potentially shared between Hyper-Threads cross Hyper-Thread attacks are possible. Deeper technical information is available in the MDS specific x86 -architecture section: :ref:`Documentation/x86/mds.rst <mds>`. +architecture section: :ref:`Documentation/arch/x86/mds.rst <mds>`. Attack scenarios diff --git a/Documentation/admin-guide/hw-vuln/tsx_async_abort.rst b/Documentation/admin-guide/hw-vuln/tsx_async_abort.rst index 76673affd917..014167ef8dd1 100644 --- a/Documentation/admin-guide/hw-vuln/tsx_async_abort.rst +++ b/Documentation/admin-guide/hw-vuln/tsx_async_abort.rst @@ -63,7 +63,7 @@ attacker needs to begin a TSX transaction and raise an asynchronous abort which in turn potentially leaks data stored in the buffers. More detailed technical information is available in the TAA specific x86 -architecture section: :ref:`Documentation/x86/tsx_async_abort.rst <tsx_async_abort>`. +architecture section: :ref:`Documentation/arch/x86/tsx_async_abort.rst <tsx_async_abort>`. Attack scenarios diff --git a/Documentation/admin-guide/index.rst b/Documentation/admin-guide/index.rst index 0ad7e7ec0d27..43ea35613dfc 100644 --- a/Documentation/admin-guide/index.rst +++ b/Documentation/admin-guide/index.rst @@ -36,7 +36,7 @@ problems and bugs in particular. reporting-issues reporting-regressions - security-bugs + quickly-build-trimmed-linux bug-hunting bug-bisect tainted-kernels diff --git a/Documentation/admin-guide/kernel-parameters.rst b/Documentation/admin-guide/kernel-parameters.rst index 19600c50277b..1ba8f2a44aac 100644 --- a/Documentation/admin-guide/kernel-parameters.rst +++ b/Documentation/admin-guide/kernel-parameters.rst @@ -128,10 +128,11 @@ parameter is applicable:: KVM Kernel Virtual Machine support is enabled. LIBATA Libata driver is enabled LP Printer support is enabled. + LOONGARCH LoongArch architecture is enabled. LOOP Loopback device support is enabled. M68k M68k architecture is enabled. These options have more detailed description inside of - Documentation/m68k/kernel-options.rst. + Documentation/arch/m68k/kernel-options.rst. MDA MDA console support is enabled. MIPS MIPS architecture is enabled. MOUSE Appropriate mouse support is enabled. @@ -177,7 +178,7 @@ parameter is applicable:: X86-32 X86-32, aka i386 architecture is enabled. X86-64 X86-64 architecture is enabled. More X86-64 boot options can be found in - Documentation/x86/x86_64/boot-options.rst. + Documentation/arch/x86/x86_64/boot-options.rst. X86 Either 32-bit or 64-bit x86 (same as X86-32+X86-64) X86_UV SGI UV support is enabled. XEN Xen support is enabled @@ -192,10 +193,10 @@ In addition, the following text indicates that the option:: Parameters denoted with BOOT are actually interpreted by the boot loader, and have no meaning to the kernel directly. Do not modify the syntax of boot loader parameters without extreme -need or coordination with <Documentation/x86/boot.rst>. +need or coordination with <Documentation/arch/x86/boot.rst>. There are also arch-specific kernel-parameters not documented here. -See for example <Documentation/x86/x86_64/boot-options.rst>. +See for example <Documentation/arch/x86/x86_64/boot-options.rst>. Note that ALL kernel parameters listed below are CASE SENSITIVE, and that a trailing = on the name of any parameter states that that parameter will diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt index 6221a1d057dd..10e2e5c3ff0b 100644 --- a/Documentation/admin-guide/kernel-parameters.txt +++ b/Documentation/admin-guide/kernel-parameters.txt @@ -929,9 +929,6 @@ debug_objects [KNL] Enable object debugging - no_debug_objects - [KNL] Disable object debugging - debug_guardpage_minorder= [KNL] When CONFIG_DEBUG_PAGEALLOC is set, this parameter allows control of the order of pages that will @@ -2976,7 +2973,7 @@ mce [X86-32] Machine Check Exception - mce=option [X86-64] See Documentation/x86/x86_64/boot-options.rst + mce=option [X86-64] See Documentation/arch/x86/x86_64/boot-options.rst md= [HW] RAID subsystems devices and level See Documentation/admin-guide/md.rst. @@ -3184,9 +3181,6 @@ deep - Suspend-To-RAM or equivalent (if supported) See Documentation/admin-guide/pm/sleep-states.rst. - meye.*= [HW] Set MotionEye Camera parameters - See Documentation/admin-guide/media/meye.rst. - mfgpt_irq= [IA-32] Specify the IRQ to use for the Multi-Function General Purpose Timers on AMD Geode platforms. @@ -3428,14 +3422,13 @@ 1 to enable accounting Default value is 0. - nfsaddrs= [NFS] Deprecated. Use ip= instead. - See Documentation/admin-guide/nfs/nfsroot.rst. - - nfsroot= [NFS] nfs root filesystem for disk-less boxes. - See Documentation/admin-guide/nfs/nfsroot.rst. + nfs.cache_getent= + [NFS] sets the pathname to the program which is used + to update the NFS client cache entries. - nfsrootdebug [NFS] enable nfsroot debugging messages. - See Documentation/admin-guide/nfs/nfsroot.rst. + nfs.cache_getent_timeout= + [NFS] sets the timeout after which an attempt to + update a cache entry is deemed to have failed. nfs.callback_nr_threads= [NFSv4] set the total number of threads that the @@ -3446,18 +3439,6 @@ [NFS] set the TCP port on which the NFSv4 callback channel should listen. - nfs.cache_getent= - [NFS] sets the pathname to the program which is used - to update the NFS client cache entries. - - nfs.cache_getent_timeout= - [NFS] sets the timeout after which an attempt to - update a cache entry is deemed to have failed. - - nfs.idmap_cache_timeout= - [NFS] set the maximum lifetime for idmapper cache - entries. - nfs.enable_ino64= [NFS] enable 64-bit inode numbers. If zero, the NFS client will fake up a 32-bit inode @@ -3465,6 +3446,10 @@ of returning the full 64-bit number. The default is to return 64-bit inode numbers. + nfs.idmap_cache_timeout= + [NFS] set the maximum lifetime for idmapper cache + entries. + nfs.max_session_cb_slots= [NFSv4.1] Sets the maximum number of session slots the client will assign to the callback @@ -3492,21 +3477,14 @@ will be autodetected by the client, and it will fall back to using the idmapper. To turn off this behaviour, set the value to '0'. + nfs.nfs4_unique_id= [NFS4] Specify an additional fixed unique ident- ification string that NFSv4 clients can insert into their nfs_client_id4 string. This is typically a UUID that is generated at system install time. - nfs.send_implementation_id = - [NFSv4.1] Send client implementation identification - information in exchange_id requests. - If zero, no implementation identification information - will be sent. - The default is to send the implementation identification - information. - - nfs.recover_lost_locks = + nfs.recover_lost_locks= [NFSv4] Attempt to recover locks that were lost due to a lease timeout on the server. Please note that doing this risks data corruption, since there are @@ -3518,7 +3496,15 @@ The default parameter value of '0' causes the kernel not to attempt recovery of lost locks. - nfs4.layoutstats_timer = + nfs.send_implementation_id= + [NFSv4.1] Send client implementation identification + information in exchange_id requests. + If zero, no implementation identification information + will be sent. + The default is to send the implementation identification + information. + + nfs4.layoutstats_timer= [NFSv4.2] Change the rate at which the kernel sends layoutstats to the pNFS metadata server. @@ -3527,12 +3513,19 @@ driver. A non-zero value sets the minimum interval in seconds between layoutstats transmissions. - nfsd.inter_copy_offload_enable = + nfsd.inter_copy_offload_enable= [NFSv4.2] When set to 1, the server will support server-to-server copies for which this server is the destination of the copy. - nfsd.nfsd4_ssc_umount_timeout = + nfsd.nfs4_disable_idmapping= + [NFSv4] When set to the default of '1', the NFSv4 + server will return only numeric uids and gids to + clients using auth_sys, and will accept numeric uids + and gids from such clients. This is intended to ease + migration from NFSv2/v3. + + nfsd.nfsd4_ssc_umount_timeout= [NFSv4.2] When used as the destination of a server-to-server copy, knfsd temporarily mounts the source server. It caches the mount in case @@ -3540,13 +3533,14 @@ used for the number of milliseconds specified by this parameter. - nfsd.nfs4_disable_idmapping= - [NFSv4] When set to the default of '1', the NFSv4 - server will return only numeric uids and gids to - clients using auth_sys, and will accept numeric uids - and gids from such clients. This is intended to ease - migration from NFSv2/v3. + nfsaddrs= [NFS] Deprecated. Use ip= instead. + See Documentation/admin-guide/nfs/nfsroot.rst. + + nfsroot= [NFS] nfs root filesystem for disk-less boxes. + See Documentation/admin-guide/nfs/nfsroot.rst. + nfsrootdebug [NFS] enable nfsroot debugging messages. + See Documentation/admin-guide/nfs/nfsroot.rst. nmi_backtrace.backtrace_idle [KNL] Dump stacks even of idle CPUs in response to an @@ -3579,7 +3573,21 @@ no5lvl [X86-64] Disable 5-level paging mode. Forces kernel to use 4-level paging instead. - nofsgsbase [X86] Disables FSGSBASE instructions. + noaliencache [MM, NUMA, SLAB] Disables the allocation of alien + caches in the slab allocator. Saves per-node memory, + but will impact performance. + + noalign [KNL,ARM] + + noaltinstr [S390] Disables alternative instructions patching + (CPU alternatives feature). + + noapic [SMP,APIC] Tells the kernel to not make use of any + IOAPICs that may be present in the system. + + noautogroup Disable scheduler automatic task group creation. + + nocache [ARM] no_console_suspend [HW] Never suspend the console @@ -3596,32 +3604,8 @@ /sys/module/printk/parameters/console_suspend) to turn on/off it dynamically. - novmcoredd [KNL,KDUMP] - Disable device dump. Device dump allows drivers to - append dump data to vmcore so you can collect driver - specified debug info. Drivers can append the data - without any limit and this data is stored in memory, - so this may cause significant memory stress. Disabling - device dump can help save memory but the driver debug - data will be no longer available. This parameter - is only available when CONFIG_PROC_VMCORE_DEVICE_DUMP - is set. - - noaliencache [MM, NUMA, SLAB] Disables the allocation of alien - caches in the slab allocator. Saves per-node memory, - but will impact performance. - - noalign [KNL,ARM] - - noaltinstr [S390] Disables alternative instructions patching - (CPU alternatives feature). - - noapic [SMP,APIC] Tells the kernel to not make use of any - IOAPICs that may be present in the system. - - noautogroup Disable scheduler automatic task group creation. - - nocache [ARM] + no_debug_objects + [KNL] Disable object debugging nodsp [SH] Disable hardware DSP at boot time. @@ -3631,14 +3615,6 @@ noexec [IA-64] - nosmap [PPC] - Disable SMAP (Supervisor Mode Access Prevention) - even if it is supported by processor. - - nosmep [PPC64s] - Disable SMEP (Supervisor Mode Execution Prevention) - even if it is supported by processor. - noexec32 [X86-64] This affects only 32-bit executables. noexec32=on: enable non-executable mappings (default) @@ -3646,74 +3622,18 @@ noexec32=off: disable non-executable mappings read implies executable mappings + no_file_caps Tells the kernel not to honor file capabilities. The + only way then for a file to be executed with privilege + is to be setuid root or executed by root. + nofpu [MIPS,SH] Disable hardware FPU at boot time. + nofsgsbase [X86] Disables FSGSBASE instructions. + nofxsr [BUGS=X86-32] Disables x86 floating point extended register save and restore. The kernel will only save legacy floating-point registers on task switch. - nohugeiomap [KNL,X86,PPC,ARM64] Disable kernel huge I/O mappings. - - nohugevmalloc [KNL,X86,PPC,ARM64] Disable kernel huge vmalloc mappings. - - nosmt [KNL,S390] Disable symmetric multithreading (SMT). - Equivalent to smt=1. - - [KNL,X86] Disable symmetric multithreading (SMT). - nosmt=force: Force disable SMT, cannot be undone - via the sysfs control file. - - nospectre_v1 [X86,PPC] Disable mitigations for Spectre Variant 1 - (bounds check bypass). With this option data leaks are - possible in the system. - - nospectre_v2 [X86,PPC_E500,ARM64] Disable all mitigations for - the Spectre variant 2 (indirect branch prediction) - vulnerability. System may allow data leaks with this - option. - - nospectre_bhb [ARM64] Disable all mitigations for Spectre-BHB (branch - history injection) vulnerability. System may allow data leaks - with this option. - - nospec_store_bypass_disable - [HW] Disable all mitigations for the Speculative Store Bypass vulnerability - - no_uaccess_flush - [PPC] Don't flush the L1-D cache after accessing user data. - - noxsave [BUGS=X86] Disables x86 extended register state save - and restore using xsave. The kernel will fallback to - enabling legacy floating-point and sse state. - - noxsaveopt [X86] Disables xsaveopt used in saving x86 extended - register states. The kernel will fall back to use - xsave to save the states. By using this parameter, - performance of saving the states is degraded because - xsave doesn't support modified optimization while - xsaveopt supports it on xsaveopt enabled systems. - - noxsaves [X86] Disables xsaves and xrstors used in saving and - restoring x86 extended register state in compacted - form of xsave area. The kernel will fall back to use - xsaveopt and xrstor to save and restore the states - in standard form of xsave area. By using this - parameter, xsave area per process might occupy more - memory on xsaves enabled systems. - - nohlt [ARM,ARM64,MICROBLAZE,SH] Forces the kernel to busy wait - in do_idle() and not use the arch_cpu_idle() - implementation; requires CONFIG_GENERIC_IDLE_POLL_SETUP - to be effective. This is useful on platforms where the - sleep(SH) or wfi(ARM,ARM64) instructions do not work - correctly or when doing power measurements to evaluate - the impact of the sleep instructions. This is also - useful when using JTAG debugger. - - no_file_caps Tells the kernel not to honor file capabilities. The - only way then for a file to be executed with privilege - is to be setuid root or executed by root. - nohalt [IA-64] Tells the kernel not to use the power saving function PAL_HALT_LIGHT when idle. This increases power-consumption. On the positive side, it reduces @@ -3737,6 +3657,19 @@ nohibernate [HIBERNATION] Disable hibernation and resume. + nohlt [ARM,ARM64,MICROBLAZE,SH] Forces the kernel to busy wait + in do_idle() and not use the arch_cpu_idle() + implementation; requires CONFIG_GENERIC_IDLE_POLL_SETUP + to be effective. This is useful on platforms where the + sleep(SH) or wfi(ARM,ARM64) instructions do not work + correctly or when doing power measurements to evaluate + the impact of the sleep instructions. This is also + useful when using JTAG debugger. + + nohugeiomap [KNL,X86,PPC,ARM64] Disable kernel huge I/O mappings. + + nohugevmalloc [KNL,X86,PPC,ARM64] Disable kernel huge vmalloc mappings. + nohz= [KNL] Boottime enable/disable dynamic ticks Valid arguments: on, off Default: on @@ -3754,16 +3687,6 @@ Note that this argument takes precedence over the CONFIG_RCU_NOCB_CPU_DEFAULT_ALL option. - noiotrap [SH] Disables trapped I/O port accesses. - - noirqdebug [X86-32] Disables the code which attempts to detect and - disable unhandled interrupt sources. - - no_timer_check [X86,APIC] Disables the code which tests for - broken timer IRQ sources. - - noisapnp [ISAPNP] Disables ISA PnP code. - noinitrd [RAM] Tells the kernel not to load any configured initial RAM disk. @@ -3775,6 +3698,13 @@ noinvpcid [X86] Disable the INVPCID cpu feature. + noiotrap [SH] Disables trapped I/O port accesses. + + noirqdebug [X86-32] Disables the code which attempts to detect and + disable unhandled interrupt sources. + + noisapnp [ISAPNP] Disables ISA PnP code. + nojitter [IA-64] Disables jitter checking for ITC timers. nokaslr [KNL] @@ -3782,18 +3712,10 @@ kernel and module base offset ASLR (Address Space Layout Randomization). - no-kvmclock [X86,KVM] Disable paravirtualized KVM clock driver - no-kvmapf [X86,KVM] Disable paravirtualized asynchronous page fault handling. - no-vmw-sched-clock - [X86,PV_OPS] Disable paravirtualized VMware scheduler - clock and use the default one. - - no-steal-acc [X86,PV_OPS,ARM64,PPC/PSERIES] Disable paravirtualized - steal time accounting. steal time is computed, but - won't influence scheduler behaviour + no-kvmclock [X86,KVM] Disable paravirtualized KVM clock driver nolapic [X86-32,APIC] Do not enable or use the local APIC. @@ -3806,10 +3728,6 @@ nomfgpt [X86-32] Disable Multi-Function General Purpose Timer usage (for AMD Geode machines). - nonmi_ipi [X86] Disable using NMI IPIs during panic/reboot to - shutdown the other cpus. Instead use the REBOOT_VECTOR - irq. - nomodeset Disable kernel modesetting. Most systems' firmware sets up a display mode and provides framebuffer memory for output. With nomodeset, DRM and fbdev drivers will @@ -3822,6 +3740,10 @@ nomodule Disable module load + nonmi_ipi [X86] Disable using NMI IPIs during panic/reboot to + shutdown the other cpus. Instead use the REBOOT_VECTOR + irq. + nopat [X86] Disable PAT (page attribute table extension of pagetables) support. @@ -3830,6 +3752,9 @@ nopku [X86] Disable Memory Protection Keys CPU feature found in some Intel CPUs. + nopti [X86-64] + Equivalent to pti=off + nopv= [X86,XEN,KVM,HYPER_V,VMWARE] Disables the PV optimizations forcing the guest to run as generic guest with no PV drivers. Currently support @@ -3849,21 +3774,77 @@ noresume [SWSUSP] Disables resume and restores original swap space. + nosbagart [IA-64] + no-scroll [VGA] Disables scrollback. This is required for the Braillex ib80-piezo Braille reader made by F.H. Papenmeier (Germany). - nosbagart [IA-64] - nosgx [X86-64,SGX] Disables Intel SGX kernel support. + nosmap [PPC] + Disable SMAP (Supervisor Mode Access Prevention) + even if it is supported by processor. + + nosmep [PPC64s] + Disable SMEP (Supervisor Mode Execution Prevention) + even if it is supported by processor. + nosmp [SMP] Tells an SMP kernel to act as a UP kernel, and disable the IO APIC. legacy for "maxcpus=0". + nosmt [KNL,S390] Disable symmetric multithreading (SMT). + Equivalent to smt=1. + + [KNL,X86] Disable symmetric multithreading (SMT). + nosmt=force: Force disable SMT, cannot be undone + via the sysfs control file. + nosoftlockup [KNL] Disable the soft-lockup detector. + nospec_store_bypass_disable + [HW] Disable all mitigations for the Speculative Store Bypass vulnerability + + nospectre_bhb [ARM64] Disable all mitigations for Spectre-BHB (branch + history injection) vulnerability. System may allow data leaks + with this option. + + nospectre_v1 [X86,PPC] Disable mitigations for Spectre Variant 1 + (bounds check bypass). With this option data leaks are + possible in the system. + + nospectre_v2 [X86,PPC_E500,ARM64] Disable all mitigations for + the Spectre variant 2 (indirect branch prediction) + vulnerability. System may allow data leaks with this + option. + + no-steal-acc [X86,PV_OPS,ARM64,PPC/PSERIES] Disable paravirtualized + steal time accounting. steal time is computed, but + won't influence scheduler behaviour + nosync [HW,M68K] Disables sync negotiation for all devices. + no_timer_check [X86,APIC] Disables the code which tests for + broken timer IRQ sources. + + no_uaccess_flush + [PPC] Don't flush the L1-D cache after accessing user data. + + novmcoredd [KNL,KDUMP] + Disable device dump. Device dump allows drivers to + append dump data to vmcore so you can collect driver + specified debug info. Drivers can append the data + without any limit and this data is stored in memory, + so this may cause significant memory stress. Disabling + device dump can help save memory but the driver debug + data will be no longer available. This parameter + is only available when CONFIG_PROC_VMCORE_DEVICE_DUMP + is set. + + no-vmw-sched-clock + [X86,PV_OPS] Disable paravirtualized VMware scheduler + clock and use the default one. + nowatchdog [KNL] Disable both lockup detectors, i.e. soft-lockup and NMI watchdog (hard-lockup). @@ -3875,6 +3856,25 @@ LEGACY_XAPIC_DISABLED bit set in the IA32_XAPIC_DISABLE_STATUS MSR. + noxsave [BUGS=X86] Disables x86 extended register state save + and restore using xsave. The kernel will fallback to + enabling legacy floating-point and sse state. + + noxsaveopt [X86] Disables xsaveopt used in saving x86 extended + register states. The kernel will fall back to use + xsave to save the states. By using this parameter, + performance of saving the states is degraded because + xsave doesn't support modified optimization while + xsaveopt supports it on xsaveopt enabled systems. + + noxsaves [X86] Disables xsaves and xrstors used in saving and + restoring x86 extended register state in compacted + form of xsave area. The kernel will fall back to use + xsaveopt and xrstor to save and restore the states + in standard form of xsave area. By using this + parameter, xsave area per process might occupy more + memory on xsaves enabled systems. + nps_mtm_hs_ctr= [KNL,ARC] This parameter sets the maximum duration, in cycles, each HW thread of the CTOP can run @@ -4410,7 +4410,7 @@ and performance comparison. pirq= [SMP,APIC] Manual mp-table setup - See Documentation/x86/i386/IO-APIC.rst. + See Documentation/arch/x86/i386/IO-APIC.rst. plip= [PPT,NET] Parallel port network link Format: { parport<nr> | timid | 0 } @@ -4582,9 +4582,6 @@ Not specifying this option is equivalent to pti=auto. - nopti [X86-64] - Equivalent to pti=off - pty.legacy_count= [KNL] Number of legacy pty's. Overwrites compiled-in default number. @@ -5591,7 +5588,7 @@ serialnumber [BUGS=X86-32] - sev=option[,option...] [X86-64] See Documentation/x86/x86_64/boot-options.rst + sev=option[,option...] [X86-64] See Documentation/arch/x86/x86_64/boot-options.rst shapers= [NET] Maximal number of shapers. @@ -6770,7 +6767,7 @@ Can be used multiple times for multiple devices. vga= [BOOT,X86-32] Select a particular video mode - See Documentation/x86/boot.rst and + See Documentation/arch/x86/boot.rst and Documentation/admin-guide/svga.rst. Use vga=ask for menu. This is actually a boot loader parameter; the value is @@ -6933,6 +6930,12 @@ When enabled, memory and cache locality will be impacted. + writecombine= [LOONGARCH] Control the MAT (Memory Access Type) of + ioremap_wc(). + + on - Enable writecombine, use WUC for ioremap_wc() + off - Disable writecombine, use SUC for ioremap_wc() + x2apic_phys [X86-64,APIC] Use x2apic physical mode instead of default x2apic cluster mode on platforms supporting x2apic. diff --git a/Documentation/admin-guide/media/cec.rst b/Documentation/admin-guide/media/cec.rst index 14ec3ff317c2..6b30e355cf23 100644 --- a/Documentation/admin-guide/media/cec.rst +++ b/Documentation/admin-guide/media/cec.rst @@ -55,6 +55,15 @@ Miscellaneous: you can control the CEC line through this driver. This supports error injection as well. +- cec-gpio and Allwinner A10 (or any other driver that uses the CEC pin + framework to drive the CEC pin directly): the CEC pin framework uses + high-resolution timers. These timers are affected by NTP daemons that + speed up or slow down the clock to sync with the official time. The + chronyd server will by default increase or decrease the clock by + 1/12th. This will cause the CEC timings to go out of spec. To fix this, + add a 'maxslewrate 40000' line to chronyd.conf. This limits the clock + frequency change to 1/25th, which keeps the CEC timings within spec. + Utilities ========= @@ -296,69 +305,71 @@ broadcast messages twice to reduce the chance of them being lost. Specifically Making a CEC debugger ===================== -By using a Raspberry Pi 2B/3/4 and some cheap components you can make +By using a Raspberry Pi 4B and some cheap components you can make your own low-level CEC debugger. -Here is a picture of my setup: - -https://hverkuil.home.xs4all.nl/rpi3-cec.jpg - -It's a Raspberry Pi 3 together with a breadboard and some breadboard wires: - -http://www.dx.com/p/diy-40p-male-to-female-male-to-male-female-to-female-dupont-line-wire-3pcs-356089#.WYLOOXWGN7I - -Finally on of these HDMI female-female passthrough connectors (full soldering type 1): +The critical component is one of these HDMI female-female passthrough connectors +(full soldering type 1): https://elabbay.myshopify.com/collections/camera/products/hdmi-af-af-v1a-hdmi-type-a-female-to-hdmi-type-a-female-pass-through-adapter-breakout-board?variant=45533926147 -We've tested this and it works up to 4kp30 (297 MHz). The quality is not high -enough to pass-through 4kp60 (594 MHz). - -I also added an RTC and a breakout shield: - -https://www.amazon.com/Makerfire%C2%AE-Raspberry-Module-DS1307-Battery/dp/B00ZOXWHK4 +The video quality is variable and certainly not enough to pass-through 4kp60 +(594 MHz) video. You might be able to support 4kp30, but more likely you will +be limited to 1080p60 (148.5 MHz). But for CEC testing that is fine. -https://www.dx.com/p/raspberry-pi-gpio-expansion-board-breadboard-easy-multiplexing-board-one-to-three-with-screw-for-raspberry-pi-2-3-b-b-2729992.html#.YGRCG0MzZ7I +You need a breadboard and some breadboard wires: -These two are not needed but they make life a bit easier. +http://www.dx.com/p/diy-40p-male-to-female-male-to-male-female-to-female-dupont-line-wire-3pcs-356089#.WYLOOXWGN7I -If you want to monitor the HPD line as well, then you need one of these -level shifters: +If you want to monitor the HPD and/or 5V lines as well, then you need one of +these 5V to 3.3V level shifters: https://www.adafruit.com/product/757 (This is just where I got these components, there are many other places you can get similar things). +The ground pin of the HDMI connector needs to be connected to a ground +pin of the Raspberry Pi, of course. + The CEC pin of the HDMI connector needs to be connected to these pins: -CE0/IO8 and CE1/IO7 (pull-up GPIOs). The (optional) HPD pin of the HDMI -connector should be connected (via a level shifter to convert the 5V -to 3.3V) to these pins: IO17 and IO27. The (optional) 5V pin of the HDMI -connector should be connected (via a level shifter) to these pins: IO22 -and IO24. Monitoring the HPD an 5V lines is not necessary, but it is helpful. +GPIO 6 and GPIO 7. The optional HPD pin of the HDMI connector should +be connected via the level shifter to these pins: GPIO 23 and GPIO 12. +The optional 5V pin of the HDMI connector should be connected via the +level shifter to these pins: GPIO 25 and GPIO 22. Monitoring the HPD and +5V lines is not necessary, but it is helpful. -This kernel patch will hook up the cec-gpio driver correctly to -e.g. ``arch/arm/boot/dts/bcm2837-rpi-3-b-plus.dts``:: +This device tree addition in ``arch/arm/boot/dts/bcm2711-rpi-4-b.dts`` +will hook up the cec-gpio driver correctly:: + + cec@6 { + compatible = "cec-gpio"; + cec-gpios = <&gpio 6 (GPIO_ACTIVE_HIGH|GPIO_OPEN_DRAIN)>; + hpd-gpios = <&gpio 23 GPIO_ACTIVE_HIGH>; + v5-gpios = <&gpio 25 GPIO_ACTIVE_HIGH>; + }; cec@7 { compatible = "cec-gpio"; cec-gpios = <&gpio 7 (GPIO_ACTIVE_HIGH|GPIO_OPEN_DRAIN)>; - hpd-gpios = <&gpio 17 GPIO_ACTIVE_HIGH>; + hpd-gpios = <&gpio 12 GPIO_ACTIVE_HIGH>; v5-gpios = <&gpio 22 GPIO_ACTIVE_HIGH>; }; - cec@8 { - compatible = "cec-gpio"; - cec-gpios = <&gpio 8 (GPIO_ACTIVE_HIGH|GPIO_OPEN_DRAIN)>; - hpd-gpios = <&gpio 27 GPIO_ACTIVE_HIGH>; - v5-gpios = <&gpio 24 GPIO_ACTIVE_HIGH>; - }; +If you haven't hooked up the HPD and/or 5V lines, then just delete those +lines. This dts change will enable two cec GPIO devices: I typically use one to send/receive CEC commands and the other to monitor. If you monitor using an unconfigured CEC adapter then it will use GPIO interrupts which makes monitoring very accurate. +If you just want to monitor traffic, then a single instance is sufficient. +The minimum configuration is one HDMI female-female passthrough connector +and two female-female breadboard wires: one for connecting the HDMI ground +pin to a ground pin on the Raspberry Pi, and the other to connect the HDMI +CEC pin to GPIO 6 on the Raspberry Pi. + The documentation on how to use the error injection is here: :ref:`cec_pin_error_inj`. ``cec-ctl --monitor-pin`` will do low-level CEC bus sniffing and analysis. diff --git a/Documentation/admin-guide/media/i2c-cardlist.rst b/Documentation/admin-guide/media/i2c-cardlist.rst index ef3b5fff3b01..1825a0bb47bd 100644 --- a/Documentation/admin-guide/media/i2c-cardlist.rst +++ b/Documentation/admin-guide/media/i2c-cardlist.rst @@ -72,17 +72,13 @@ imx319 Sony IMX319 sensor imx334 Sony IMX334 sensor imx355 Sony IMX355 sensor imx412 Sony IMX412 sensor -m5mols Fujitsu M-5MOLS 8MP sensor mt9m001 mt9m001 -mt9m032 MT9M032 camera sensor mt9m111 mt9m111, mt9m112 and mt9m131 mt9p031 Aptina MT9P031 -mt9t001 Aptina MT9T001 mt9t112 Aptina MT9T111/MT9T112 mt9v011 Micron mt9v011 sensor mt9v032 Micron MT9V032 sensor mt9v111 Aptina MT9V111 sensor -noon010pc30 Siliconfile NOON010PC30 sensor ov13858 OmniVision OV13858 sensor ov13b10 OmniVision OV13B10 sensor ov2640 OmniVision OV2640 sensor @@ -109,9 +105,6 @@ s5c73m3 Samsung S5C73M3 sensor s5k4ecgx Samsung S5K4ECGX sensor s5k5baf Samsung S5K5BAF sensor s5k6a3 Samsung S5K6A3 sensor -s5k6aa Samsung S5K6AAFX sensor -sr030pc30 Siliconfile SR030PC30 sensor -vs6624 ST VS6624 sensor ============ ========================================================== Flash devices @@ -222,7 +215,6 @@ Video encoders ============ ========================================================== Driver Name ============ ========================================================== -ad9389b Analog Devices AD9389B encoder adv7170 Analog Devices ADV7170 video encoder adv7175 Analog Devices ADV7175 video encoder adv7343 ADV7343 video encoder diff --git a/Documentation/admin-guide/mm/pagemap.rst b/Documentation/admin-guide/mm/pagemap.rst index b5f970dc91e7..c8f380271cad 100644 --- a/Documentation/admin-guide/mm/pagemap.rst +++ b/Documentation/admin-guide/mm/pagemap.rst @@ -91,9 +91,9 @@ Short descriptions to the page flags The page is being locked for exclusive access, e.g. by undergoing read/write IO. 7 - SLAB - The page is managed by the SLAB/SLOB/SLUB/SLQB kernel memory allocator. - When compound page is used, SLUB/SLQB will only set this flag on the head - page; SLOB will not flag it at all. + The page is managed by the SLAB/SLUB kernel memory allocator. + When compound page is used, either will only set this flag on the head + page. 10 - BUDDY A free memory block managed by the buddy system allocator. The buddy system organizes free memory in blocks of various orders. diff --git a/Documentation/admin-guide/quickly-build-trimmed-linux.rst b/Documentation/admin-guide/quickly-build-trimmed-linux.rst new file mode 100644 index 000000000000..ff4f4cc8522b --- /dev/null +++ b/Documentation/admin-guide/quickly-build-trimmed-linux.rst @@ -0,0 +1,1092 @@ +.. SPDX-License-Identifier: (GPL-2.0+ OR CC-BY-4.0) +.. [see the bottom of this file for redistribution information] + +=========================================== +How to quickly build a trimmed Linux kernel +=========================================== + +This guide explains how to swiftly build Linux kernels that are ideal for +testing purposes, but perfectly fine for day-to-day use, too. + +The essence of the process (aka 'TL;DR') +======================================== + +*[If you are new to compiling Linux, ignore this TLDR and head over to the next +section below: it contains a step-by-step guide, which is more detailed, but +still brief and easy to follow; that guide and its accompanying reference +section also mention alternatives, pitfalls, and additional aspects, all of +which might be relevant for you.]* + +If your system uses techniques like Secure Boot, prepare it to permit starting +self-compiled Linux kernels; install compilers and everything else needed for +building Linux; make sure to have 12 Gigabyte free space in your home directory. +Now run the following commands to download fresh Linux mainline sources, which +you then use to configure, build and install your own kernel:: + + git clone --depth 1 -b master \ + https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git ~/linux/ + cd ~/linux/ + # Hint: if you want to apply patches, do it at this point. See below for details. + # Hint: it's recommended to tag your build at this point. See below for details. + yes "" | make localmodconfig + # Hint: at this point you might want to adjust the build configuration; you'll + # have to, if you are running Debian. See below for details. + make -j $(nproc --all) + # Note: on many commodity distributions the next command suffices, but on Arch + # Linux, its derivatives, and some others it does not. See below for details. + command -v installkernel && sudo make modules_install install + reboot + +If you later want to build a newer mainline snapshot, use these commands:: + + cd ~/linux/ + git fetch --depth 1 origin + # Note: the next command will discard any changes you did to the code: + git checkout --force --detach origin/master + # Reminder: if you want to (re)apply patches, do it at this point. + # Reminder: you might want to add or modify a build tag at this point. + make olddefconfig + make -j $(nproc --all) + # Reminder: the next command on some distributions does not suffice. + command -v installkernel && sudo make modules_install install + reboot + +Step-by-step guide +================== + +Compiling your own Linux kernel is easy in principle. There are various ways to +do it. Which of them actually work and is the best depends on the circumstances. + +This guide describes a way perfectly suited for those who want to quickly +install Linux from sources without being bothered by complicated details; the +goal is to cover everything typically needed on mainstream Linux distributions +running on commodity PC or server hardware. + +The described approach is great for testing purposes, for example to try a +proposed fix or to check if a problem was already fixed in the latest codebase. +Nonetheless, kernels built this way are also totally fine for day-to-day use +while at the same time being easy to keep up to date. + +The following steps describe the important aspects of the process; a +comprehensive reference section later explains each of them in more detail. It +sometimes also describes alternative approaches, pitfalls, as well as errors +that might occur at a particular point -- and how to then get things rolling +again. + +.. + Note: if you see this note, you are reading the text's source file. You + might want to switch to a rendered version, as it makes it a lot easier to + quickly look something up in the reference section and afterwards jump back + to where you left off. Find a the latest rendered version here: + https://docs.kernel.org/admin-guide/quickly-build-trimmed-linux.html + +.. _backup_sbs: + + * Create a fresh backup and put system repair and restore tools at hand, just + to be prepared for the unlikely case of something going sideways. + + [:ref:`details<backup>`] + +.. _secureboot_sbs: + + * On platforms with 'Secure Boot' or similar techniques, prepare everything to + ensure the system will permit your self-compiled kernel to boot later. The + quickest and easiest way to achieve this on commodity x86 systems is to + disable such techniques in the BIOS setup utility; alternatively, remove + their restrictions through a process initiated by + ``mokutil --disable-validation``. + + [:ref:`details<secureboot>`] + +.. _buildrequires_sbs: + + * Install all software required to build a Linux kernel. Often you will need: + 'bc', 'binutils' ('ld' et al.), 'bison', 'flex', 'gcc', 'git', 'openssl', + 'pahole', 'perl', and the development headers for 'libelf' and 'openssl'. The + reference section shows how to quickly install those on various popular Linux + distributions. + + [:ref:`details<buildrequires>`] + +.. _diskspace_sbs: + + * Ensure to have enough free space for building and installing Linux. For the + latter 150 Megabyte in /lib/ and 100 in /boot/ are a safe bet. For storing + sources and build artifacts 12 Gigabyte in your home directory should + typically suffice. If you have less available, be sure to check the reference + section for the step that explains adjusting your kernels build + configuration: it mentions a trick that reduce the amount of required space + in /home/ to around 4 Gigabyte. + + [:ref:`details<diskspace>`] + +.. _sources_sbs: + + * Retrieve the sources of the Linux version you intend to build; then change + into the directory holding them, as all further commands in this guide are + meant to be executed from there. + + *[Note: the following paragraphs describe how to retrieve the sources by + partially cloning the Linux stable git repository. This is called a shallow + clone. The reference section explains two alternatives:* :ref:`packaged + archives<sources_archive>` *and* :ref:`a full git clone<sources_full>` *; + prefer the latter, if downloading a lot of data does not bother you, as that + will avoid some* :ref:`peculiar characteristics of shallow clones the + reference section explains<sources_shallow>` *.]* + + First, execute the following command to retrieve a fresh mainline codebase:: + + git clone --no-checkout --depth 1 -b master \ + https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git ~/linux/ + cd ~/linux/ + + If you want to access recent mainline releases and pre-releases, deepen you + clone's history to the oldest mainline version you are interested in:: + + git fetch --shallow-exclude=v6.0 origin + + In case you want to access a stable/longterm release (say v6.1.5), simply add + the branch holding that series; afterwards fetch the history at least up to + the mainline version that started the series (v6.1):: + + git remote set-branches --add origin linux-6.1.y + git fetch --shallow-exclude=v6.0 origin + + Now checkout the code you are interested in. If you just performed the + initial clone, you will be able to check out a fresh mainline codebase, which + is ideal for checking whether developers already fixed an issue:: + + git checkout --detach origin/master + + If you deepened your clone, you instead of ``origin/master`` can specify the + version you deepened to (``v6.0`` above); later releases like ``v6.1`` and + pre-release like ``v6.2-rc1`` will work, too. Stable or longterm versions + like ``v6.1.5`` work just the same, if you added the appropriate + stable/longterm branch as described. + + [:ref:`details<sources>`] + +.. _patching_sbs: + + * In case you want to apply a kernel patch, do so now. Often a command like + this will do the trick:: + + patch -p1 < ../proposed-fix.patch + + If the ``-p1`` is actually needed, depends on how the patch was created; in + case it does not apply thus try without it. + + If you cloned the sources with git and anything goes sideways, run ``git + reset --hard`` to undo any changes to the sources. + + [:ref:`details<patching>`] + +.. _tagging_sbs: + + * If you patched your kernel or have one of the same version installed already, + better add a unique tag to the one you are about to build:: + + echo "-proposed_fix" > localversion + + Running ``uname -r`` under your kernel later will then print something like + '6.1-rc4-proposed_fix'. + + [:ref:`details<tagging>`] + + .. _configuration_sbs: + + * Create the build configuration for your kernel based on an existing + configuration. + + If you already prepared such a '.config' file yourself, copy it to + ~/linux/ and run ``make olddefconfig``. + + Use the same command, if your distribution or somebody else already tailored + your running kernel to your or your hardware's needs: the make target + 'olddefconfig' will then try to use that kernel's .config as base. + + Using this make target is fine for everybody else, too -- but you often can + save a lot of time by using this command instead:: + + yes "" | make localmodconfig + + This will try to pick your distribution's kernel as base, but then disable + modules for any features apparently superfluous for your setup. This will + reduce the compile time enormously, especially if you are running an + universal kernel from a commodity Linux distribution. + + There is a catch: the make target 'localmodconfig' will disable kernel + features you have not directly or indirectly through some program utilized + since you booted the system. You can reduce or nearly eliminate that risk by + using tricks outlined in the reference section; for quick testing purposes + that risk is often negligible, but it is an aspect you want to keep in mind + in case your kernel behaves oddly. + + [:ref:`details<configuration>`] + +.. _configmods_sbs: + + * Check if you might want to or have to adjust some kernel configuration + options: + + * Evaluate how you want to handle debug symbols. Enable them, if you later + might need to decode a stack trace found for example in a 'panic', 'Oops', + 'warning', or 'BUG'; on the other hand disable them, if you are short on + storage space or prefer a smaller kernel binary. See the reference section + for details on how to do either. If neither applies, it will likely be fine + to simply not bother with this. [:ref:`details<configmods_debugsymbols>`] + + * Are you running Debian? Then to avoid known problems by performing + additional adjustments explained in the reference section. + [:ref:`details<configmods_distros>`]. + + * If you want to influence the other aspects of the configuration, do so now + by using make targets like 'menuconfig' or 'xconfig'. + [:ref:`details<configmods_individual>`]. + +.. _build_sbs: + + * Build the image and the modules of your kernel:: + + make -j $(nproc --all) + + If you want your kernel packaged up as deb, rpm, or tar file, see the + reference section for alternatives. + + [:ref:`details<build>`] + +.. _install_sbs: + + * Now install your kernel:: + + command -v installkernel && sudo make modules_install install + + Often all left for you to do afterwards is a ``reboot``, as many commodity + Linux distributions will then create an initramfs (also known as initrd) and + an entry for your kernel in your bootloader's configuration; but on some + distributions you have to take care of these two steps manually for reasons + the reference section explains. + + On a few distributions like Arch Linux and its derivatives the above command + does nothing at all; in that case you have to manually install your kernel, + as outlined in the reference section. + + [:ref:`details<install>`] + +.. _another_sbs: + + * To later build another kernel you need similar steps, but sometimes slightly + different commands. + + First, switch back into the sources tree:: + + cd ~/linux/ + + In case you want to build a version from a stable/longterm series you have + not used yet (say 6.2.y), tell git to track it:: + + git remote set-branches --add origin linux-6.2.y + + Now fetch the latest upstream changes; you again need to specify the earliest + version you care about, as git otherwise might retrieve the entire commit + history:: + + git fetch --shallow-exclude=v6.1 origin + + If you modified the sources (for example by applying a patch), you now need + to discard those modifications; that's because git otherwise will not be able + to switch to the sources of another version due to potential conflicting + changes:: + + git reset --hard + + Now checkout the version you are interested in, as explained above:: + + git checkout --detach origin/master + + At this point you might want to patch the sources again or set/modify a build + tag, as explained earlier; afterwards adjust the build configuration to the + new codebase and build your next kernel:: + + # reminder: if you want to apply patches, do it at this point + # reminder: you might want to update your build tag at this point + make olddefconfig + make -j $(nproc --all) + + Install the kernel as outlined above:: + + command -v installkernel && sudo make modules_install install + + [:ref:`details<another>`] + +.. _uninstall_sbs: + + * Your kernel is easy to remove later, as its parts are only stored in two + places and clearly identifiable by the kernel's release name. Just ensure to + not delete the kernel you are running, as that might render your system + unbootable. + + Start by deleting the directory holding your kernel's modules, which is named + after its release name -- '6.0.1-foobar' in the following example:: + + sudo rm -rf /lib/modules/6.0.1-foobar + + Now try the following command, which on some distributions will delete all + other kernel files installed while also removing the kernel's entry from the + bootloader configuration:: + + command -v kernel-install && sudo kernel-install -v remove 6.0.1-foobar + + If that command does not output anything or fails, see the reference section; + do the same if any files named '*6.0.1-foobar*' remain in /boot/. + + [:ref:`details<uninstall>`] + +.. _submit_improvements: + +Did you run into trouble following any of the above steps that is not cleared up +by the reference section below? Or do you have ideas how to improve the text? +Then please take a moment of your time and let the maintainer of this document +know by email (Thorsten Leemhuis <linux@leemhuis.info>), ideally while CCing the +Linux docs mailing list (linux-doc@vger.kernel.org). Such feedback is vital to +improve this document further, which is in everybody's interest, as it will +enable more people to master the task described here. + +Reference section for the step-by-step guide +============================================ + +This section holds additional information for each of the steps in the above +guide. + +.. _backup: + +Prepare for emergencies +----------------------- + + *Create a fresh backup and put system repair and restore tools at hand* + [:ref:`... <backup_sbs>`] + +Remember, you are dealing with computers, which sometimes do unexpected things +-- especially if you fiddle with crucial parts like the kernel of an operating +system. That's what you are about to do in this process. Hence, better prepare +for something going sideways, even if that should not happen. + +[:ref:`back to step-by-step guide <backup_sbs>`] + +.. _secureboot: + +Dealing with techniques like Secure Boot +---------------------------------------- + + *On platforms with 'Secure Boot' or similar techniques, prepare everything to + ensure the system will permit your self-compiled kernel to boot later.* + [:ref:`... <secureboot_sbs>`] + +Many modern systems allow only certain operating systems to start; they thus by +default will reject booting self-compiled kernels. + +You ideally deal with this by making your platform trust your self-built kernels +with the help of a certificate and signing. How to do that is not described +here, as it requires various steps that would take the text too far away from +its purpose; 'Documentation/admin-guide/module-signing.rst' and various web +sides already explain this in more detail. + +Temporarily disabling solutions like Secure Boot is another way to make your own +Linux boot. On commodity x86 systems it is possible to do this in the BIOS Setup +utility; the steps to do so are not described here, as they greatly vary between +machines. + +On mainstream x86 Linux distributions there is a third and universal option: +disable all Secure Boot restrictions for your Linux environment. You can +initiate this process by running ``mokutil --disable-validation``; this will +tell you to create a one-time password, which is safe to write down. Now +restart; right after your BIOS performed all self-tests the bootloader Shim will +show a blue box with a message 'Press any key to perform MOK management'. Hit +some key before the countdown exposes. This will open a menu and choose 'Change +Secure Boot state' there. Shim's 'MokManager' will now ask you to enter three +randomly chosen characters from the one-time password specified earlier. Once +you provided them, confirm that you really want to disable the validation. +Afterwards, permit MokManager to reboot the machine. + +[:ref:`back to step-by-step guide <secureboot_sbs>`] + +.. _buildrequires: + +Install build requirements +-------------------------- + + *Install all software required to build a Linux kernel.* + [:ref:`...<buildrequires_sbs>`] + +The kernel is pretty stand-alone, but besides tools like the compiler you will +sometimes need a few libraries to build one. How to install everything needed +depends on your Linux distribution and the configuration of the kernel you are +about to build. + +Here are a few examples what you typically need on some mainstream +distributions: + + * Debian, Ubuntu, and derivatives:: + + sudo apt install bc binutils bison dwarves flex gcc git make openssl \ + pahole perl-base libssl-dev libelf-dev + + * Fedora and derivatives:: + + sudo dnf install binutils /usr/include/{libelf.h,openssl/pkcs7.h} \ + /usr/bin/{bc,bison,flex,gcc,git,openssl,make,perl,pahole} + + * openSUSE and derivatives:: + + sudo zypper install bc binutils bison dwarves flex gcc git make perl-base \ + openssl openssl-devel libelf-dev + +In case you wonder why these lists include openssl and its development headers: +they are needed for the Secure Boot support, which many distributions enable in +their kernel configuration for x86 machines. + +Sometimes you will need tools for compression formats like bzip2, gzip, lz4, +lzma, lzo, xz, or zstd as well. + +You might need additional libraries and their development headers in case you +perform tasks not covered in this guide. For example, zlib will be needed when +building kernel tools from the tools/ directory; adjusting the build +configuration with make targets like 'menuconfig' or 'xconfig' will require +development headers for ncurses or Qt5. + +[:ref:`back to step-by-step guide <buildrequires_sbs>`] + +.. _diskspace: + +Space requirements +------------------ + + *Ensure to have enough free space for building and installing Linux.* + [:ref:`... <diskspace_sbs>`] + +The numbers mentioned are rough estimates with a big extra charge to be on the +safe side, so often you will need less. + +If you have space constraints, remember to read the reference section when you +reach the :ref:`section about configuration adjustments' <configmods>`, as +ensuring debug symbols are disabled will reduce the consumed disk space by quite +a few gigabytes. + +[:ref:`back to step-by-step guide <diskspace_sbs>`] + + +.. _sources: + +Download the sources +-------------------- + + *Retrieve the sources of the Linux version you intend to build.* + [:ref:`...<sources_sbs>`] + +The step-by-step guide outlines how to retrieve Linux' sources using a shallow +git clone. There is :ref:`more to tell about this method<sources_shallow>` and +two alternate ways worth describing: :ref:`packaged archives<sources_archive>` +and :ref:`a full git clone<sources_full>`. And the aspects ':ref:`wouldn't it +be wiser to use a proper pre-release than the latest mainline code +<sources_snapshot>`' and ':ref:`how to get an even fresher mainline codebase +<sources_fresher>`' need elaboration, too. + +Note, to keep things simple the commands used in this guide store the build +artifacts in the source tree. If you prefer to separate them, simply add +something like ``O=~/linux-builddir/`` to all make calls; also adjust the path +in all commands that add files or modify any generated (like your '.config'). + +[:ref:`back to step-by-step guide <sources_sbs>`] + +.. _sources_shallow: + +Noteworthy characteristics of shallow clones +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +The step-by-step guide uses a shallow clone, as it is the best solution for most +of this document's target audience. There are a few aspects of this approach +worth mentioning: + + * This document in most places uses ``git fetch`` with ``--shallow-exclude=`` + to specify the earliest version you care about (or to be precise: its git + tag). You alternatively can use the parameter ``--shallow-since=`` to specify + an absolute (say ``'2023-07-15'``) or relative (``'12 months'``) date to + define the depth of the history you want to download. As a second + alternative, you can also specify a certain depth explicitly with a parameter + like ``--depth=1``, unless you add branches for stable/longterm kernels. + + * When running ``git fetch``, remember to always specify the oldest version, + the time you care about, or an explicit depth as shown in the step-by-step + guide. Otherwise you will risk downloading nearly the entire git history, + which will consume quite a bit of time and bandwidth while also stressing the + servers. + + Note, you do not have to use the same version or date all the time. But when + you change it over time, git will deepen or flatten the history to the + specified point. That allows you to retrieve versions you initially thought + you did not need -- or it will discard the sources of older versions, for + example in case you want to free up some disk space. The latter will happen + automatically when using ``--shallow-since=`` or + ``--depth=``. + + * Be warned, when deepening your clone you might encounter an error like + 'fatal: error in object: unshallow cafecaca0c0dacafecaca0c0dacafecaca0c0da'. + In that case run ``git repack -d`` and try again`` + + * In case you want to revert changes from a certain version (say Linux 6.3) or + perform a bisection (v6.2..v6.3), better tell ``git fetch`` to retrieve + objects up to three versions earlier (e.g. 6.0): ``git describe`` will then + be able to describe most commits just like it would in a full git clone. + +[:ref:`back to step-by-step guide <sources_sbs>`] [:ref:`back to section intro <sources>`] + +.. _sources_archive: + +Downloading the sources using a packages archive +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +People new to compiling Linux often assume downloading an archive via the +front-page of https://kernel.org is the best approach to retrieve Linux' +sources. It actually can be, if you are certain to build just one particular +kernel version without changing any code. Thing is: you might be sure this will +be the case, but in practice it often will turn out to be a wrong assumption. + +That's because when reporting or debugging an issue developers will often ask to +give another version a try. They also might suggest temporarily undoing a commit +with ``git revert`` or might provide various patches to try. Sometimes reporters +will also be asked to use ``git bisect`` to find the change causing a problem. +These things rely on git or are a lot easier and quicker to handle with it. + +A shallow clone also does not add any significant overhead. For example, when +you use ``git clone --depth=1`` to create a shallow clone of the latest mainline +codebase git will only retrieve a little more data than downloading the latest +mainline pre-release (aka 'rc') via the front-page of kernel.org would. + +A shallow clone therefore is often the better choice. If you nevertheless want +to use a packaged source archive, download one via kernel.org; afterwards +extract its content to some directory and change to the subdirectory created +during extraction. The rest of the step-by-step guide will work just fine, apart +from things that rely on git -- but this mainly concerns the section on +successive builds of other versions. + +[:ref:`back to step-by-step guide <sources_sbs>`] [:ref:`back to section intro <sources>`] + +.. _sources_full: + +Downloading the sources using a full git clone +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +If downloading and storing a lot of data (~4,4 Gigabyte as of early 2023) is +nothing that bothers you, instead of a shallow clone perform a full git clone +instead. You then will avoid the specialties mentioned above and will have all +versions and individual commits at hand at any time:: + + curl -L \ + https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/clone.bundle \ + -o linux-stable.git.bundle + git clone clone.bundle ~/linux/ + rm linux-stable.git.bundle + cd ~/linux/ + git remote set-url origin + https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git + git fetch origin + git checkout --detach origin/master + +[:ref:`back to step-by-step guide <sources_sbs>`] [:ref:`back to section intro <sources>`] + +.. _sources_snapshot: + +Proper pre-releases (RCs) vs. latest mainline +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +When cloning the sources using git and checking out origin/master, you often +will retrieve a codebase that is somewhere between the latest and the next +release or pre-release. This almost always is the code you want when giving +mainline a shot: pre-releases like v6.1-rc5 are in no way special, as they do +not get any significant extra testing before being published. + +There is one exception: you might want to stick to the latest mainline release +(say v6.1) before its successor's first pre-release (v6.2-rc1) is out. That is +because compiler errors and other problems are more likely to occur during this +time, as mainline then is in its 'merge window': a usually two week long phase, +in which the bulk of the changes for the next release is merged. + +[:ref:`back to step-by-step guide <sources_sbs>`] [:ref:`back to section intro <sources>`] + +.. _sources_fresher: + +Avoiding the mainline lag +~~~~~~~~~~~~~~~~~~~~~~~~~ + +The explanations for both the shallow clone and the full clone both retrieve the +code from the Linux stable git repository. That makes things simpler for this +document's audience, as it allows easy access to both mainline and +stable/longterm releases. This approach has just one downside: + +Changes merged into the mainline repository are only synced to the master branch +of the Linux stable repository every few hours. This lag most of the time is +not something to worry about; but in case you really need the latest code, just +add the mainline repo as additional remote and checkout the code from there:: + + git remote add mainline \ + https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git + git fetch mainline + git checkout --detach mainline/master + +When doing this with a shallow clone, remember to call ``git fetch`` with one +of the parameters described earlier to limit the depth. + +[:ref:`back to step-by-step guide <sources_sbs>`] [:ref:`back to section intro <sources>`] + +.. _patching: + +Patch the sources (optional) +---------------------------- + + *In case you want to apply a kernel patch, do so now.* + [:ref:`...<patching_sbs>`] + +This is the point where you might want to patch your kernel -- for example when +a developer proposed a fix and asked you to check if it helps. The step-by-step +guide already explains everything crucial here. + +[:ref:`back to step-by-step guide <patching_sbs>`] + +.. _tagging: + +Tagging this kernel build (optional, often wise) +------------------------------------------------ + + *If you patched your kernel or already have that kernel version installed, + better tag your kernel by extending its release name:* + [:ref:`...<tagging_sbs>`] + +Tagging your kernel will help avoid confusion later, especially when you patched +your kernel. Adding an individual tag will also ensure the kernel's image and +its modules are installed in parallel to any existing kernels. + +There are various ways to add such a tag. The step-by-step guide realizes one by +creating a 'localversion' file in your build directory from which the kernel +build scripts will automatically pick up the tag. You can later change that file +to use a different tag in subsequent builds or simply remove that file to dump +the tag. + +[:ref:`back to step-by-step guide <tagging_sbs>`] + +.. _configuration: + +Define the build configuration for your kernel +---------------------------------------------- + + *Create the build configuration for your kernel based on an existing + configuration.* [:ref:`... <configuration_sbs>`] + +There are various aspects for this steps that require a more careful +explanation: + +Pitfalls when using another configuration file as base +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +Make targets like localmodconfig and olddefconfig share a few common snares you +want to be aware of: + + * These targets will reuse a kernel build configuration in your build directory + (e.g. '~/linux/.config'), if one exists. In case you want to start from + scratch you thus need to delete it. + + * The make targets try to find the configuration for your running kernel + automatically, but might choose poorly. A line like '# using defaults found + in /boot/config-6.0.7-250.fc36.x86_64' or 'using config: + '/boot/config-6.0.7-250.fc36.x86_64' tells you which file they picked. If + that is not the intended one, simply store it as '~/linux/.config' + before using these make targets. + + * Unexpected things might happen if you try to use a config file prepared for + one kernel (say v6.0) on an older generation (say v5.15). In that case you + might want to use a configuration as base which your distribution utilized + when they used that or an slightly older kernel version. + +Influencing the configuration +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +The make target olddefconfig and the ``yes "" |`` used when utilizing +localmodconfig will set any undefined build options to their default value. This +among others will disable many kernel features that were introduced after your +base kernel was released. + +If you want to set these configurations options manually, use ``oldconfig`` +instead of ``olddefconfig`` or omit the ``yes "" |`` when utilizing +localmodconfig. Then for each undefined configuration option you will be asked +how to proceed. In case you are unsure what to answer, simply hit 'enter' to +apply the default value. + +Big pitfall when using localmodconfig +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +As explained briefly in the step-by-step guide already: with localmodconfig it +can easily happen that your self-built kernel will lack modules for tasks you +did not perform before utilizing this make target. That's because those tasks +require kernel modules that are normally autoloaded when you perform that task +for the first time; if you didn't perform that task at least once before using +localmodonfig, the latter will thus assume these modules are superfluous and +disable them. + +You can try to avoid this by performing typical tasks that often will autoload +additional kernel modules: start a VM, establish VPN connections, loop-mount a +CD/DVD ISO, mount network shares (CIFS, NFS, ...), and connect all external +devices (2FA keys, headsets, webcams, ...) as well as storage devices with file +systems you otherwise do not utilize (btrfs, ext4, FAT, NTFS, XFS, ...). But it +is hard to think of everything that might be needed -- even kernel developers +often forget one thing or another at this point. + +Do not let that risk bother you, especially when compiling a kernel only for +testing purposes: everything typically crucial will be there. And if you forget +something important you can turn on a missing feature later and quickly run the +commands to compile and install a better kernel. + +But if you plan to build and use self-built kernels regularly, you might want to +reduce the risk by recording which modules your system loads over the course of +a few weeks. You can automate this with `modprobed-db +<https://github.com/graysky2/modprobed-db>`_. Afterwards use ``LSMOD=<path>`` to +point localmodconfig to the list of modules modprobed-db noticed being used:: + + yes "" | make LSMOD="${HOME}"/.config/modprobed.db localmodconfig + +Remote building with localmodconfig +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +If you want to use localmodconfig to build a kernel for another machine, run +``lsmod > lsmod_foo-machine`` on it and transfer that file to your build host. +Now point the build scripts to the file like this: ``yes "" | make +LSMOD=~/lsmod_foo-machine localmodconfig``. Note, in this case +you likely want to copy a base kernel configuration from the other machine over +as well and place it as .config in your build directory. + +[:ref:`back to step-by-step guide <configuration_sbs>`] + +.. _configmods: + +Adjust build configuration +-------------------------- + + *Check if you might want to or have to adjust some kernel configuration + options:* + +Depending on your needs you at this point might want or have to adjust some +kernel configuration options. + +.. _configmods_debugsymbols: + +Debug symbols +~~~~~~~~~~~~~ + + *Evaluate how you want to handle debug symbols.* + [:ref:`...<configmods_sbs>`] + +Most users do not need to care about this, it's often fine to leave everything +as it is; but you should take a closer look at this, if you might need to decode +a stack trace or want to reduce space consumption. + +Having debug symbols available can be important when your kernel throws a +'panic', 'Oops', 'warning', or 'BUG' later when running, as then you will be +able to find the exact place where the problem occurred in the code. But +collecting and embedding the needed debug information takes time and consumes +quite a bit of space: in late 2022 the build artifacts for a typical x86 kernel +configured with localmodconfig consumed around 5 Gigabyte of space with debug +symbols, but less than 1 when they were disabled. The resulting kernel image and +the modules are bigger as well, which increases load times. + +Hence, if you want a small kernel and are unlikely to decode a stack trace +later, you might want to disable debug symbols to avoid above downsides:: + + ./scripts/config --file .config -d DEBUG_INFO \ + -d DEBUG_INFO_DWARF_TOOLCHAIN_DEFAULT -d DEBUG_INFO_DWARF4 \ + -d DEBUG_INFO_DWARF5 -e CONFIG_DEBUG_INFO_NONE + make olddefconfig + +You on the other hand definitely want to enable them, if there is a decent +chance that you need to decode a stack trace later (as explained by 'Decode +failure messages' in Documentation/admin-guide/tainted-kernels.rst in more +detail):: + + ./scripts/config --file .config -d DEBUG_INFO_NONE -e DEBUG_KERNEL + -e DEBUG_INFO -e DEBUG_INFO_DWARF_TOOLCHAIN_DEFAULT -e KALLSYMS -e KALLSYMS_ALL + make olddefconfig + +Note, many mainstream distributions enable debug symbols in their kernel +configurations -- make targets like localmodconfig and olddefconfig thus will +often pick that setting up. + +[:ref:`back to step-by-step guide <configmods_sbs>`] + +.. _configmods_distros: + +Distro specific adjustments +~~~~~~~~~~~~~~~~~~~~~~~~~~~ + + *Are you running* [:ref:`... <configmods_sbs>`] + +The following sections help you to avoid build problems that are known to occur +when following this guide on a few commodity distributions. + +**Debian:** + + * Remove a stale reference to a certificate file that would cause your build to + fail:: + + ./scripts/config --file .config --set-str SYSTEM_TRUSTED_KEYS '' + + Alternatively, download the needed certificate and make that configuration + option point to it, as `the Debian handbook explains in more detail + <https://debian-handbook.info/browse/stable/sect.kernel-compilation.html>`_ + -- or generate your own, as explained in + Documentation/admin-guide/module-signing.rst. + +[:ref:`back to step-by-step guide <configmods_sbs>`] + +.. _configmods_individual: + +Individual adjustments +~~~~~~~~~~~~~~~~~~~~~~ + + *If you want to influence the other aspects of the configuration, do so + now* [:ref:`... <configmods_sbs>`] + +You at this point can use a command like ``make menuconfig`` to enable or +disable certain features using a text-based user interface; to use a graphical +configuration utilize, use the make target ``xconfig`` or ``gconfig`` instead. +All of them require development libraries from toolkits they are based on +(ncurses, Qt5, Gtk2); an error message will tell you if something required is +missing. + +[:ref:`back to step-by-step guide <configmods_sbs>`] + +.. _build: + +Build your kernel +----------------- + + *Build the image and the modules of your kernel* [:ref:`... <build_sbs>`] + +A lot can go wrong at this stage, but the instructions below will help you help +yourself. Another subsection explains how to directly package your kernel up as +deb, rpm or tar file. + +Dealing with build errors +~~~~~~~~~~~~~~~~~~~~~~~~~ + +When a build error occurs, it might be caused by some aspect of your machine's +setup that often can be fixed quickly; other times though the problem lies in +the code and can only be fixed by a developer. A close examination of the +failure messages coupled with some research on the internet will often tell you +which of the two it is. To perform such a investigation, restart the build +process like this:: + + make V=1 + +The ``V=1`` activates verbose output, which might be needed to see the actual +error. To make it easier to spot, this command also omits the ``-j $(nproc +--all)`` used earlier to utilize every CPU core in the system for the job -- but +this parallelism also results in some clutter when failures occur. + +After a few seconds the build process should run into the error again. Now try +to find the most crucial line describing the problem. Then search the internet +for the most important and non-generic section of that line (say 4 to 8 words); +avoid or remove anything that looks remotely system-specific, like your username +or local path names like ``/home/username/linux/``. First try your regular +internet search engine with that string, afterwards search Linux kernel mailing +lists via `lore.kernel.org/all/ <https://lore.kernel.org/all/>`_. + +This most of the time will find something that will explain what is wrong; quite +often one of the hits will provide a solution for your problem, too. If you +do not find anything that matches your problem, try again from a different angle +by modifying your search terms or using another line from the error messages. + +In the end, most trouble you are to run into has likely been encountered and +reported by others already. That includes issues where the cause is not your +system, but lies the code. If you run into one of those, you might thus find a +solution (e.g. a patch) or workaround for your problem, too. + +Package your kernel up +~~~~~~~~~~~~~~~~~~~~~~ + +The step-by-step guide uses the default make targets (e.g. 'bzImage' and +'modules' on x86) to build the image and the modules of your kernel, which later +steps of the guide then install. You instead can also directly build everything +and directly package it up by using one of the following targets: + + * ``make -j $(nproc --all) bindeb-pkg`` to generate a deb package + + * ``make -j $(nproc --all) binrpm-pkg`` to generate a rpm package + + * ``make -j $(nproc --all) tarbz2-pkg`` to generate a bz2 compressed tarball + +This is just a selection of available make targets for this purpose, see +``make help`` for others. You can also use these targets after running +``make -j $(nproc --all)``, as they will pick up everything already built. + +If you employ the targets to generate deb or rpm packages, ignore the +step-by-step guide's instructions on installing and removing your kernel; +instead install and remove the packages using the package utility for the format +(e.g. dpkg and rpm) or a package management utility build on top of them (apt, +aptitude, dnf/yum, zypper, ...). Be aware that the packages generated using +these two make targets are designed to work on various distributions utilizing +those formats, they thus will sometimes behave differently than your +distribution's kernel packages. + +[:ref:`back to step-by-step guide <build_sbs>`] + +.. _install: + +Install your kernel +------------------- + + *Now install your kernel* [:ref:`... <install_sbs>`] + +What you need to do after executing the command in the step-by-step guide +depends on the existence and the implementation of an ``installkernel`` +executable. Many commodity Linux distributions ship such a kernel installer in +``/sbin/`` that does everything needed, hence there is nothing left for you +except rebooting. But some distributions contain an installkernel that does +only part of the job -- and a few lack it completely and leave all the work to +you. + +If ``installkernel`` is found, the kernel's build system will delegate the +actual installation of your kernel's image and related files to this executable. +On almost all Linux distributions it will store the image as '/boot/vmlinuz- +<your kernel's release name>' and put a 'System.map-<your kernel's release +name>' alongside it. Your kernel will thus be installed in parallel to any +existing ones, unless you already have one with exactly the same release name. + +Installkernel on many distributions will afterwards generate an 'initramfs' +(often also called 'initrd'), which commodity distributions rely on for booting; +hence be sure to keep the order of the two make targets used in the step-by-step +guide, as things will go sideways if you install your kernel's image before its +modules. Often installkernel will then add your kernel to the bootloader +configuration, too. You have to take care of one or both of these tasks +yourself, if your distributions installkernel doesn't handle them. + +A few distributions like Arch Linux and its derivatives totally lack an +installkernel executable. On those just install the modules using the kernel's +build system and then install the image and the System.map file manually:: + + sudo make modules_install + sudo install -m 0600 $(make -s image_name) /boot/vmlinuz-$(make -s kernelrelease) + sudo install -m 0600 System.map /boot/System.map-$(make -s kernelrelease) + +If your distribution boots with the help of an initramfs, now generate one for +your kernel using the tools your distribution provides for this process. +Afterwards add your kernel to your bootloader configuration and reboot. + +[:ref:`back to step-by-step guide <install_sbs>`] + +.. _another: + +Another round later +------------------- + + *To later build another kernel you need similar, but sometimes slightly + different commands* [:ref:`... <another_sbs>`] + +The process to build later kernels is similar, but at some points slightly +different. You for example do not want to use 'localmodconfig' for succeeding +kernel builds, as you already created a trimmed down configuration you want to +use from now on. Hence instead just use ``oldconfig`` or ``olddefconfig`` to +adjust your build configurations to the needs of the kernel version you are +about to build. + +If you created a shallow-clone with git, remember what the :ref:`section that +explained the setup described in more detail <sources>`: you need to use a +slightly different ``git fetch`` command and when switching to another series +need to add an additional remote branch. + +[:ref:`back to step-by-step guide <another_sbs>`] + +.. _uninstall: + +Uninstall the kernel later +-------------------------- + + *All parts of your installed kernel are identifiable by its release name and + thus easy to remove later.* [:ref:`... <uninstall_sbs>`] + +Do not worry installing your kernel manually and thus bypassing your +distribution's packaging system will totally mess up your machine: all parts of +your kernel are easy to remove later, as files are stored in two places only and +normally identifiable by the kernel's release name. + +One of the two places is a directory in /lib/modules/, which holds the modules +for each installed kernel. This directory is named after the kernel's release +name; hence, to remove all modules for one of your kernels, simply remove its +modules directory in /lib/modules/. + +The other place is /boot/, where typically one to five files will be placed +during installation of a kernel. All of them usually contain the release name in +their file name, but how many files and their name depends somewhat on your +distribution's installkernel executable (:ref:`see above <install>`) and its +initramfs generator. On some distributions the ``kernel-install`` command +mentioned in the step-by-step guide will remove all of these files for you -- +and the entry for your kernel in the bootloader configuration at the same time, +too. On others you have to take care of these steps yourself. The following +command should interactively remove the two main files of a kernel with the +release name '6.0.1-foobar':: + + rm -i /boot/{System.map,vmlinuz}-6.0.1-foobar + +Now remove the belonging initramfs, which often will be called something like +``/boot/initramfs-6.0.1-foobar.img`` or ``/boot/initrd.img-6.0.1-foobar``. +Afterwards check for other files in /boot/ that have '6.0.1-foobar' in their +name and delete them as well. Now remove the kernel from your bootloader's +configuration. + +Note, be very careful with wildcards like '*' when deleting files or directories +for kernels manually: you might accidentally remove files of a 6.0.11 kernel +when all you want is to remove 6.0 or 6.0.1. + +[:ref:`back to step-by-step guide <uninstall_sbs>`] + +.. _faq: + +FAQ +=== + +Why does this 'how-to' not work on my system? +--------------------------------------------- + +As initially stated, this guide is 'designed to cover everything typically +needed [to build a kernel] on mainstream Linux distributions running on +commodity PC or server hardware'. The outlined approach despite this should work +on many other setups as well. But trying to cover every possible use-case in one +guide would defeat its purpose, as without such a focus you would need dozens or +hundreds of constructs along the lines of 'in case you are having <insert +machine or distro>, you at this point have to do <this and that> +<instead|additionally>'. Each of which would make the text longer, more +complicated, and harder to follow. + +That being said: this of course is a balancing act. Hence, if you think an +additional use-case is worth describing, suggest it to the maintainers of this +document, as :ref:`described above <submit_improvements>`. + + +.. + end-of-content +.. + This document is maintained by Thorsten Leemhuis <linux@leemhuis.info>. If + you spot a typo or small mistake, feel free to let him know directly and + he'll fix it. You are free to do the same in a mostly informal way if you + want to contribute changes to the text -- but for copyright reasons please CC + linux-doc@vger.kernel.org and 'sign-off' your contribution as + Documentation/process/submitting-patches.rst explains in the section 'Sign + your work - the Developer's Certificate of Origin'. +.. + This text is available under GPL-2.0+ or CC-BY-4.0, as stated at the top + of the file. If you want to distribute this text under CC-BY-4.0 only, + please use 'The Linux kernel development community' for author attribution + and link this as source: + https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/plain/Documentation/admin-guide/quickly-build-trimmed-linux.rst +.. + Note: Only the content of this RST file as found in the Linux kernel sources + is available under CC-BY-4.0, as versions of this text that were processed + (for example by the kernel's build system) might contain content taken from + files which use a more restrictive license. + diff --git a/Documentation/admin-guide/ras.rst b/Documentation/admin-guide/ras.rst index 7b481b2a368e..8e03751d126d 100644 --- a/Documentation/admin-guide/ras.rst +++ b/Documentation/admin-guide/ras.rst @@ -199,7 +199,7 @@ Architecture (MCA)\ [#f3]_. mode). .. [#f3] For more details about the Machine Check Architecture (MCA), - please read Documentation/x86/x86_64/machinecheck.rst at the Kernel tree. + please read Documentation/arch/x86/x86_64/machinecheck.rst at the Kernel tree. EDAC - Error Detection And Correction ************************************* diff --git a/Documentation/admin-guide/reporting-issues.rst b/Documentation/admin-guide/reporting-issues.rst index ec62151fe672..2fd5a030235a 100644 --- a/Documentation/admin-guide/reporting-issues.rst +++ b/Documentation/admin-guide/reporting-issues.rst @@ -395,7 +395,7 @@ might want to be aware of; it for example explains how to add your issue to the list of tracked regressions, to ensure it won't fall through the cracks. What qualifies as security issue is left to your judgment. Consider reading -Documentation/admin-guide/security-bugs.rst before proceeding, as it +Documentation/process/security-bugs.rst before proceeding, as it provides additional details how to best handle security issues. An issue is a 'really severe problem' when something totally unacceptably bad @@ -1269,7 +1269,7 @@ them when sending the report by mail. If you filed it in a bug tracker, forward the report's text to these addresses; but on top of it put a small note where you mention that you filed it with a link to the ticket. -See Documentation/admin-guide/security-bugs.rst for more information. +See Documentation/process/security-bugs.rst for more information. Duties after the report went out diff --git a/Documentation/admin-guide/syscall-user-dispatch.rst b/Documentation/admin-guide/syscall-user-dispatch.rst index 60314953c728..e3cfffef5a63 100644 --- a/Documentation/admin-guide/syscall-user-dispatch.rst +++ b/Documentation/admin-guide/syscall-user-dispatch.rst @@ -73,6 +73,10 @@ thread-wide, without the need to invoke the kernel directly. selector can be set to SYSCALL_DISPATCH_FILTER_ALLOW or SYSCALL_DISPATCH_FILTER_BLOCK. Any other value should terminate the program with a SIGSYS. +Additionally, a tasks syscall user dispatch configuration can be peeked +and poked via the PTRACE_(GET|SET)_SYSCALL_USER_DISPATCH_CONFIG ptrace +requests. This is useful for checkpoint/restart software. + Security Notes -------------- diff --git a/Documentation/admin-guide/sysctl/kernel.rst b/Documentation/admin-guide/sysctl/kernel.rst index 4b7bfea28cd7..d85d90f5d000 100644 --- a/Documentation/admin-guide/sysctl/kernel.rst +++ b/Documentation/admin-guide/sysctl/kernel.rst @@ -95,7 +95,7 @@ is 0x15 and the full version number is 0x234, this file will contain the value 340 = 0x154. See the ``type_of_loader`` and ``ext_loader_type`` fields in -Documentation/x86/boot.rst for additional information. +Documentation/arch/x86/boot.rst for additional information. bootloader_version (x86 only) @@ -105,7 +105,7 @@ The complete bootloader version number. In the example above, this file will contain the value 564 = 0x234. See the ``type_of_loader`` and ``ext_loader_ver`` fields in -Documentation/x86/boot.rst for additional information. +Documentation/arch/x86/boot.rst for additional information. bpf_stats_enabled diff --git a/Documentation/admin-guide/unicode.rst b/Documentation/admin-guide/unicode.rst index 290fe83ebe82..cba7e5017d36 100644 --- a/Documentation/admin-guide/unicode.rst +++ b/Documentation/admin-guide/unicode.rst @@ -3,11 +3,10 @@ Unicode support Last update: 2005-01-17, version 1.4 -This file is maintained by H. Peter Anvin <unicode@lanana.org> as part -of the Linux Assigned Names And Numbers Authority (LANANA) project. -The current version can be found at: - - http://www.lanana.org/docs/unicode/admin-guide/unicode.rst +Note: The original version of this document, which was maintained at +lanana.org as part of the Linux Assigned Names And Numbers Authority +(LANANA) project, is no longer existent. So, this version in the +mainline Linux kernel is now the maintained main document. Introduction ------------ diff --git a/Documentation/arc/arc.rst b/Documentation/arch/arc/arc.rst index 6c4d978f3f4e..6c4d978f3f4e 100644 --- a/Documentation/arc/arc.rst +++ b/Documentation/arch/arc/arc.rst diff --git a/Documentation/arc/features.rst b/Documentation/arch/arc/features.rst index b793583d688a..b793583d688a 100644 --- a/Documentation/arc/features.rst +++ b/Documentation/arch/arc/features.rst diff --git a/Documentation/arc/index.rst b/Documentation/arch/arc/index.rst index 7b098d4a5e3e..7b098d4a5e3e 100644 --- a/Documentation/arc/index.rst +++ b/Documentation/arch/arc/index.rst diff --git a/Documentation/ia64/aliasing.rst b/Documentation/arch/ia64/aliasing.rst index 36a1e1d4842b..36a1e1d4842b 100644 --- a/Documentation/ia64/aliasing.rst +++ b/Documentation/arch/ia64/aliasing.rst diff --git a/Documentation/ia64/efirtc.rst b/Documentation/arch/ia64/efirtc.rst index fd8328408301..fd8328408301 100644 --- a/Documentation/ia64/efirtc.rst +++ b/Documentation/arch/ia64/efirtc.rst diff --git a/Documentation/ia64/err_inject.rst b/Documentation/arch/ia64/err_inject.rst index 900f71e93a29..900f71e93a29 100644 --- a/Documentation/ia64/err_inject.rst +++ b/Documentation/arch/ia64/err_inject.rst diff --git a/Documentation/ia64/features.rst b/Documentation/arch/ia64/features.rst index d7226fdcf5f8..d7226fdcf5f8 100644 --- a/Documentation/ia64/features.rst +++ b/Documentation/arch/ia64/features.rst diff --git a/Documentation/ia64/fsys.rst b/Documentation/arch/ia64/fsys.rst index a702d2cc94b6..a702d2cc94b6 100644 --- a/Documentation/ia64/fsys.rst +++ b/Documentation/arch/ia64/fsys.rst diff --git a/Documentation/ia64/ia64.rst b/Documentation/arch/ia64/ia64.rst index b725019a9492..b725019a9492 100644 --- a/Documentation/ia64/ia64.rst +++ b/Documentation/arch/ia64/ia64.rst diff --git a/Documentation/ia64/index.rst b/Documentation/arch/ia64/index.rst index 761f2154dfa2..761f2154dfa2 100644 --- a/Documentation/ia64/index.rst +++ b/Documentation/arch/ia64/index.rst diff --git a/Documentation/ia64/irq-redir.rst b/Documentation/arch/ia64/irq-redir.rst index 6bbbbe4f73ef..6bbbbe4f73ef 100644 --- a/Documentation/ia64/irq-redir.rst +++ b/Documentation/arch/ia64/irq-redir.rst diff --git a/Documentation/ia64/mca.rst b/Documentation/arch/ia64/mca.rst index 08270bba44a4..08270bba44a4 100644 --- a/Documentation/ia64/mca.rst +++ b/Documentation/arch/ia64/mca.rst diff --git a/Documentation/ia64/serial.rst b/Documentation/arch/ia64/serial.rst index 1de70c305a79..1de70c305a79 100644 --- a/Documentation/ia64/serial.rst +++ b/Documentation/arch/ia64/serial.rst diff --git a/Documentation/arch.rst b/Documentation/arch/index.rst index 41a66a8b38e4..80ee31016584 100644 --- a/Documentation/arch.rst +++ b/Documentation/arch/index.rst @@ -10,18 +10,18 @@ implementation. :maxdepth: 2 arc/index - arm/index - arm64/index + ../arm/index + ../arm64/index ia64/index - loongarch/index + ../loongarch/index m68k/index - mips/index + ../mips/index nios2/index openrisc/index parisc/index - powerpc/index - riscv/index - s390/index + ../powerpc/index + ../riscv/index + ../s390/index sh/index sparc/index x86/index diff --git a/Documentation/m68k/buddha-driver.rst b/Documentation/arch/m68k/buddha-driver.rst index 20e401413991..20e401413991 100644 --- a/Documentation/m68k/buddha-driver.rst +++ b/Documentation/arch/m68k/buddha-driver.rst diff --git a/Documentation/m68k/features.rst b/Documentation/arch/m68k/features.rst index 5107a2119472..5107a2119472 100644 --- a/Documentation/m68k/features.rst +++ b/Documentation/arch/m68k/features.rst diff --git a/Documentation/m68k/index.rst b/Documentation/arch/m68k/index.rst index 0f890dbb5fe2..0f890dbb5fe2 100644 --- a/Documentation/m68k/index.rst +++ b/Documentation/arch/m68k/index.rst diff --git a/Documentation/m68k/kernel-options.rst b/Documentation/arch/m68k/kernel-options.rst index 2008a20b4329..2008a20b4329 100644 --- a/Documentation/m68k/kernel-options.rst +++ b/Documentation/arch/m68k/kernel-options.rst diff --git a/Documentation/nios2/features.rst b/Documentation/arch/nios2/features.rst index 8449e63f69b2..8449e63f69b2 100644 --- a/Documentation/nios2/features.rst +++ b/Documentation/arch/nios2/features.rst diff --git a/Documentation/nios2/index.rst b/Documentation/arch/nios2/index.rst index 4468fe1a1037..4468fe1a1037 100644 --- a/Documentation/nios2/index.rst +++ b/Documentation/arch/nios2/index.rst diff --git a/Documentation/nios2/nios2.rst b/Documentation/arch/nios2/nios2.rst index 43da3f7cee76..43da3f7cee76 100644 --- a/Documentation/nios2/nios2.rst +++ b/Documentation/arch/nios2/nios2.rst diff --git a/Documentation/openrisc/features.rst b/Documentation/arch/openrisc/features.rst index 3f7c40d219f2..3f7c40d219f2 100644 --- a/Documentation/openrisc/features.rst +++ b/Documentation/arch/openrisc/features.rst diff --git a/Documentation/openrisc/index.rst b/Documentation/arch/openrisc/index.rst index 6879f998b87a..6879f998b87a 100644 --- a/Documentation/openrisc/index.rst +++ b/Documentation/arch/openrisc/index.rst diff --git a/Documentation/openrisc/openrisc_port.rst b/Documentation/arch/openrisc/openrisc_port.rst index 657ac4af7be6..657ac4af7be6 100644 --- a/Documentation/openrisc/openrisc_port.rst +++ b/Documentation/arch/openrisc/openrisc_port.rst diff --git a/Documentation/openrisc/todo.rst b/Documentation/arch/openrisc/todo.rst index 420b18b87eda..420b18b87eda 100644 --- a/Documentation/openrisc/todo.rst +++ b/Documentation/arch/openrisc/todo.rst diff --git a/Documentation/parisc/debugging.rst b/Documentation/arch/parisc/debugging.rst index de1b60402c5b..de1b60402c5b 100644 --- a/Documentation/parisc/debugging.rst +++ b/Documentation/arch/parisc/debugging.rst diff --git a/Documentation/parisc/features.rst b/Documentation/arch/parisc/features.rst index 501d7c450037..501d7c450037 100644 --- a/Documentation/parisc/features.rst +++ b/Documentation/arch/parisc/features.rst diff --git a/Documentation/parisc/index.rst b/Documentation/arch/parisc/index.rst index 240685751825..240685751825 100644 --- a/Documentation/parisc/index.rst +++ b/Documentation/arch/parisc/index.rst diff --git a/Documentation/parisc/registers.rst b/Documentation/arch/parisc/registers.rst index 59c8ecf3e856..59c8ecf3e856 100644 --- a/Documentation/parisc/registers.rst +++ b/Documentation/arch/parisc/registers.rst diff --git a/Documentation/sh/booting.rst b/Documentation/arch/sh/booting.rst index d851c49a01bf..d851c49a01bf 100644 --- a/Documentation/sh/booting.rst +++ b/Documentation/arch/sh/booting.rst diff --git a/Documentation/sh/features.rst b/Documentation/arch/sh/features.rst index f722af3b6c99..f722af3b6c99 100644 --- a/Documentation/sh/features.rst +++ b/Documentation/arch/sh/features.rst diff --git a/Documentation/sh/index.rst b/Documentation/arch/sh/index.rst index c64776738cf6..c64776738cf6 100644 --- a/Documentation/sh/index.rst +++ b/Documentation/arch/sh/index.rst diff --git a/Documentation/sh/new-machine.rst b/Documentation/arch/sh/new-machine.rst index e501c52b3b30..e501c52b3b30 100644 --- a/Documentation/sh/new-machine.rst +++ b/Documentation/arch/sh/new-machine.rst diff --git a/Documentation/sh/register-banks.rst b/Documentation/arch/sh/register-banks.rst index 2bef5c8fcbbc..2bef5c8fcbbc 100644 --- a/Documentation/sh/register-banks.rst +++ b/Documentation/arch/sh/register-banks.rst diff --git a/Documentation/sparc/adi.rst b/Documentation/arch/sparc/adi.rst index dbcd8b6e7bc3..dbcd8b6e7bc3 100644 --- a/Documentation/sparc/adi.rst +++ b/Documentation/arch/sparc/adi.rst diff --git a/Documentation/sparc/console.rst b/Documentation/arch/sparc/console.rst index 73132db83ece..73132db83ece 100644 --- a/Documentation/sparc/console.rst +++ b/Documentation/arch/sparc/console.rst diff --git a/Documentation/sparc/features.rst b/Documentation/arch/sparc/features.rst index c0c92468b0fe..c0c92468b0fe 100644 --- a/Documentation/sparc/features.rst +++ b/Documentation/arch/sparc/features.rst diff --git a/Documentation/sparc/index.rst b/Documentation/arch/sparc/index.rst index ae884224eec2..ae884224eec2 100644 --- a/Documentation/sparc/index.rst +++ b/Documentation/arch/sparc/index.rst diff --git a/Documentation/sparc/oradax/dax-hv-api.txt b/Documentation/arch/sparc/oradax/dax-hv-api.txt index 7ecd0bf4957b..7ecd0bf4957b 100644 --- a/Documentation/sparc/oradax/dax-hv-api.txt +++ b/Documentation/arch/sparc/oradax/dax-hv-api.txt diff --git a/Documentation/sparc/oradax/oracle-dax.rst b/Documentation/arch/sparc/oradax/oracle-dax.rst index d1e14d572918..d1e14d572918 100644 --- a/Documentation/sparc/oradax/oracle-dax.rst +++ b/Documentation/arch/sparc/oradax/oracle-dax.rst diff --git a/Documentation/x86/amd-memory-encryption.rst b/Documentation/arch/x86/amd-memory-encryption.rst index 934310ce7258..934310ce7258 100644 --- a/Documentation/x86/amd-memory-encryption.rst +++ b/Documentation/arch/x86/amd-memory-encryption.rst diff --git a/Documentation/x86/amd_hsmp.rst b/Documentation/arch/x86/amd_hsmp.rst index 440e4b645a1c..440e4b645a1c 100644 --- a/Documentation/x86/amd_hsmp.rst +++ b/Documentation/arch/x86/amd_hsmp.rst diff --git a/Documentation/x86/boot.rst b/Documentation/arch/x86/boot.rst index 240d084782a6..33520ecdb37a 100644 --- a/Documentation/x86/boot.rst +++ b/Documentation/arch/x86/boot.rst @@ -1344,7 +1344,7 @@ follow:: In addition to read/modify/write the setup header of the struct boot_params as that of 16-bit boot protocol, the boot loader should also fill the additional fields of the struct boot_params as -described in chapter Documentation/x86/zero-page.rst. +described in chapter Documentation/arch/x86/zero-page.rst. After setting up the struct boot_params, the boot loader can load the 32/64-bit kernel in the same way as that of 16-bit boot protocol. @@ -1380,7 +1380,7 @@ can be calculated as follows:: In addition to read/modify/write the setup header of the struct boot_params as that of 16-bit boot protocol, the boot loader should also fill the additional fields of the struct boot_params as described -in chapter Documentation/x86/zero-page.rst. +in chapter Documentation/arch/x86/zero-page.rst. After setting up the struct boot_params, the boot loader can load 64-bit kernel in the same way as that of 16-bit boot protocol, but diff --git a/Documentation/x86/booting-dt.rst b/Documentation/arch/x86/booting-dt.rst index 965a374071ab..b089ffd56e6e 100644 --- a/Documentation/x86/booting-dt.rst +++ b/Documentation/arch/x86/booting-dt.rst @@ -7,7 +7,7 @@ DeviceTree Booting the decompressor (the real mode entry point goes to the same 32bit entry point once it switched into protected mode). That entry point supports one calling convention which is documented in - Documentation/x86/boot.rst + Documentation/arch/x86/boot.rst The physical pointer to the device-tree block is passed via setup_data which requires at least boot protocol 2.09. The type filed is defined as diff --git a/Documentation/x86/buslock.rst b/Documentation/arch/x86/buslock.rst index 7c051e714943..31ec0ef78086 100644 --- a/Documentation/x86/buslock.rst +++ b/Documentation/arch/x86/buslock.rst @@ -53,8 +53,14 @@ parameter "split_lock_detect". Here is a summary of different options: |off |Do nothing |Do nothing | +------------------+----------------------------+-----------------------+ |warn |Kernel OOPs |Warn once per task and | -|(default) |Warn once per task and |and continues to run. | -| |disable future checking | | +|(default) |Warn once per task, add a |and continues to run. | +| |delay, add synchronization | | +| |to prevent more than one | | +| |core from executing a | | +| |split lock in parallel. | | +| |sysctl split_lock_mitigate | | +| |can be used to avoid the | | +| |delay and synchronization | | | |When both features are | | | |supported, warn in #AC | | +------------------+----------------------------+-----------------------+ diff --git a/Documentation/x86/cpuinfo.rst b/Documentation/arch/x86/cpuinfo.rst index 08246e8ac835..08246e8ac835 100644 --- a/Documentation/x86/cpuinfo.rst +++ b/Documentation/arch/x86/cpuinfo.rst diff --git a/Documentation/x86/earlyprintk.rst b/Documentation/arch/x86/earlyprintk.rst index 51ef11e8f725..51ef11e8f725 100644 --- a/Documentation/x86/earlyprintk.rst +++ b/Documentation/arch/x86/earlyprintk.rst diff --git a/Documentation/x86/elf_auxvec.rst b/Documentation/arch/x86/elf_auxvec.rst index 18e4744717f9..18e4744717f9 100644 --- a/Documentation/x86/elf_auxvec.rst +++ b/Documentation/arch/x86/elf_auxvec.rst diff --git a/Documentation/x86/entry_64.rst b/Documentation/arch/x86/entry_64.rst index 0afdce3c06f4..0afdce3c06f4 100644 --- a/Documentation/x86/entry_64.rst +++ b/Documentation/arch/x86/entry_64.rst diff --git a/Documentation/x86/exception-tables.rst b/Documentation/arch/x86/exception-tables.rst index efde1fef4fbd..efde1fef4fbd 100644 --- a/Documentation/x86/exception-tables.rst +++ b/Documentation/arch/x86/exception-tables.rst diff --git a/Documentation/x86/features.rst b/Documentation/arch/x86/features.rst index b663f15053ce..b663f15053ce 100644 --- a/Documentation/x86/features.rst +++ b/Documentation/arch/x86/features.rst diff --git a/Documentation/x86/i386/IO-APIC.rst b/Documentation/arch/x86/i386/IO-APIC.rst index ce4d8df15e7c..ce4d8df15e7c 100644 --- a/Documentation/x86/i386/IO-APIC.rst +++ b/Documentation/arch/x86/i386/IO-APIC.rst diff --git a/Documentation/x86/i386/index.rst b/Documentation/arch/x86/i386/index.rst index 8747cf5bbd49..8747cf5bbd49 100644 --- a/Documentation/x86/i386/index.rst +++ b/Documentation/arch/x86/i386/index.rst diff --git a/Documentation/x86/ifs.rst b/Documentation/arch/x86/ifs.rst index 97abb696a680..97abb696a680 100644 --- a/Documentation/x86/ifs.rst +++ b/Documentation/arch/x86/ifs.rst diff --git a/Documentation/x86/index.rst b/Documentation/arch/x86/index.rst index c73d133fd37c..c73d133fd37c 100644 --- a/Documentation/x86/index.rst +++ b/Documentation/arch/x86/index.rst diff --git a/Documentation/x86/intel-hfi.rst b/Documentation/arch/x86/intel-hfi.rst index 49dea58ea4fb..49dea58ea4fb 100644 --- a/Documentation/x86/intel-hfi.rst +++ b/Documentation/arch/x86/intel-hfi.rst diff --git a/Documentation/x86/intel_txt.rst b/Documentation/arch/x86/intel_txt.rst index d83c1a2122c9..d83c1a2122c9 100644 --- a/Documentation/x86/intel_txt.rst +++ b/Documentation/arch/x86/intel_txt.rst diff --git a/Documentation/x86/iommu.rst b/Documentation/arch/x86/iommu.rst index 42c7a6faa39a..42c7a6faa39a 100644 --- a/Documentation/x86/iommu.rst +++ b/Documentation/arch/x86/iommu.rst diff --git a/Documentation/x86/kernel-stacks.rst b/Documentation/arch/x86/kernel-stacks.rst index 6b0bcf027ff1..6b0bcf027ff1 100644 --- a/Documentation/x86/kernel-stacks.rst +++ b/Documentation/arch/x86/kernel-stacks.rst diff --git a/Documentation/x86/mds.rst b/Documentation/arch/x86/mds.rst index 5d4330be200f..5d4330be200f 100644 --- a/Documentation/x86/mds.rst +++ b/Documentation/arch/x86/mds.rst diff --git a/Documentation/x86/microcode.rst b/Documentation/arch/x86/microcode.rst index b627c6f36bcf..b627c6f36bcf 100644 --- a/Documentation/x86/microcode.rst +++ b/Documentation/arch/x86/microcode.rst diff --git a/Documentation/x86/mtrr.rst b/Documentation/arch/x86/mtrr.rst index 9f0b1851771a..f65ef034da7a 100644 --- a/Documentation/x86/mtrr.rst +++ b/Documentation/arch/x86/mtrr.rst @@ -28,7 +28,7 @@ are aligned with platform MTRR setup. If MTRRs are only set up by the platform firmware code though and the OS does not make any specific MTRR mapping requests mtrr_type_lookup() should always return MTRR_TYPE_INVALID. -For details refer to Documentation/x86/pat.rst. +For details refer to Documentation/arch/x86/pat.rst. .. tip:: On Intel P6 family processors (Pentium Pro, Pentium II and later) diff --git a/Documentation/x86/orc-unwinder.rst b/Documentation/arch/x86/orc-unwinder.rst index cdb257015bd9..cdb257015bd9 100644 --- a/Documentation/x86/orc-unwinder.rst +++ b/Documentation/arch/x86/orc-unwinder.rst diff --git a/Documentation/x86/pat.rst b/Documentation/arch/x86/pat.rst index 5d901771016d..5d901771016d 100644 --- a/Documentation/x86/pat.rst +++ b/Documentation/arch/x86/pat.rst diff --git a/Documentation/x86/pti.rst b/Documentation/arch/x86/pti.rst index 4b858a9bad8d..4b858a9bad8d 100644 --- a/Documentation/x86/pti.rst +++ b/Documentation/arch/x86/pti.rst diff --git a/Documentation/x86/resctrl.rst b/Documentation/arch/x86/resctrl.rst index 387ccbcb558f..387ccbcb558f 100644 --- a/Documentation/x86/resctrl.rst +++ b/Documentation/arch/x86/resctrl.rst diff --git a/Documentation/x86/sgx.rst b/Documentation/arch/x86/sgx.rst index 2bcbffacbed5..2bcbffacbed5 100644 --- a/Documentation/x86/sgx.rst +++ b/Documentation/arch/x86/sgx.rst diff --git a/Documentation/x86/sva.rst b/Documentation/arch/x86/sva.rst index 2e9b8b0f9a0f..2e9b8b0f9a0f 100644 --- a/Documentation/x86/sva.rst +++ b/Documentation/arch/x86/sva.rst diff --git a/Documentation/x86/tdx.rst b/Documentation/arch/x86/tdx.rst index dc8d9fd2c3f7..dc8d9fd2c3f7 100644 --- a/Documentation/x86/tdx.rst +++ b/Documentation/arch/x86/tdx.rst diff --git a/Documentation/x86/tlb.rst b/Documentation/arch/x86/tlb.rst index 82ec58ae63a8..82ec58ae63a8 100644 --- a/Documentation/x86/tlb.rst +++ b/Documentation/arch/x86/tlb.rst diff --git a/Documentation/x86/topology.rst b/Documentation/arch/x86/topology.rst index 7f58010ea86a..7f58010ea86a 100644 --- a/Documentation/x86/topology.rst +++ b/Documentation/arch/x86/topology.rst diff --git a/Documentation/x86/tsx_async_abort.rst b/Documentation/arch/x86/tsx_async_abort.rst index 583ddc185ba2..583ddc185ba2 100644 --- a/Documentation/x86/tsx_async_abort.rst +++ b/Documentation/arch/x86/tsx_async_abort.rst diff --git a/Documentation/x86/usb-legacy-support.rst b/Documentation/arch/x86/usb-legacy-support.rst index e01c08b7c981..e01c08b7c981 100644 --- a/Documentation/x86/usb-legacy-support.rst +++ b/Documentation/arch/x86/usb-legacy-support.rst diff --git a/Documentation/x86/x86_64/5level-paging.rst b/Documentation/arch/x86/x86_64/5level-paging.rst index b792bbdc0b01..71f882f4a173 100644 --- a/Documentation/x86/x86_64/5level-paging.rst +++ b/Documentation/arch/x86/x86_64/5level-paging.rst @@ -20,7 +20,7 @@ physical address space. This "ought to be enough for anybody" ©. QEMU 2.9 and later support 5-level paging. Virtual memory layout for 5-level paging is described in -Documentation/x86/x86_64/mm.rst +Documentation/arch/x86/x86_64/mm.rst Enabling 5-level paging diff --git a/Documentation/x86/x86_64/boot-options.rst b/Documentation/arch/x86/x86_64/boot-options.rst index cbd14124a667..137432d34109 100644 --- a/Documentation/x86/x86_64/boot-options.rst +++ b/Documentation/arch/x86/x86_64/boot-options.rst @@ -9,7 +9,7 @@ only the AMD64 specific ones are listed here. Machine check ============= -Please see Documentation/x86/x86_64/machinecheck.rst for sysfs runtime tunables. +Please see Documentation/arch/x86/x86_64/machinecheck.rst for sysfs runtime tunables. mce=off Disable machine check @@ -82,7 +82,7 @@ APICs Don't use the local APIC (alias for i386 compatibility) pirq=... - See Documentation/x86/i386/IO-APIC.rst + See Documentation/arch/x86/i386/IO-APIC.rst noapictimer Don't set up the APIC timer diff --git a/Documentation/x86/x86_64/cpu-hotplug-spec.rst b/Documentation/arch/x86/x86_64/cpu-hotplug-spec.rst index 8d1c91f0c880..8d1c91f0c880 100644 --- a/Documentation/x86/x86_64/cpu-hotplug-spec.rst +++ b/Documentation/arch/x86/x86_64/cpu-hotplug-spec.rst diff --git a/Documentation/x86/x86_64/fake-numa-for-cpusets.rst b/Documentation/arch/x86/x86_64/fake-numa-for-cpusets.rst index ff9bcfd2cc14..ba74617d4999 100644 --- a/Documentation/x86/x86_64/fake-numa-for-cpusets.rst +++ b/Documentation/arch/x86/x86_64/fake-numa-for-cpusets.rst @@ -18,7 +18,7 @@ For more information on the features of cpusets, see Documentation/admin-guide/cgroup-v1/cpusets.rst. There are a number of different configurations you can use for your needs. For more information on the numa=fake command line option and its various ways of -configuring fake nodes, see Documentation/x86/x86_64/boot-options.rst. +configuring fake nodes, see Documentation/arch/x86/x86_64/boot-options.rst. For the purposes of this introduction, we'll assume a very primitive NUMA emulation setup of "numa=fake=4*512,". This will split our system memory into diff --git a/Documentation/x86/x86_64/fsgs.rst b/Documentation/arch/x86/x86_64/fsgs.rst index 50960e09e1f6..50960e09e1f6 100644 --- a/Documentation/x86/x86_64/fsgs.rst +++ b/Documentation/arch/x86/x86_64/fsgs.rst diff --git a/Documentation/x86/x86_64/index.rst b/Documentation/arch/x86/x86_64/index.rst index a56070fc8e77..a56070fc8e77 100644 --- a/Documentation/x86/x86_64/index.rst +++ b/Documentation/arch/x86/x86_64/index.rst diff --git a/Documentation/x86/x86_64/machinecheck.rst b/Documentation/arch/x86/x86_64/machinecheck.rst index cea12ee97200..cea12ee97200 100644 --- a/Documentation/x86/x86_64/machinecheck.rst +++ b/Documentation/arch/x86/x86_64/machinecheck.rst diff --git a/Documentation/x86/x86_64/mm.rst b/Documentation/arch/x86/x86_64/mm.rst index 35e5e18c83d0..35e5e18c83d0 100644 --- a/Documentation/x86/x86_64/mm.rst +++ b/Documentation/arch/x86/x86_64/mm.rst diff --git a/Documentation/x86/x86_64/uefi.rst b/Documentation/arch/x86/x86_64/uefi.rst index fbc30c9a071d..fbc30c9a071d 100644 --- a/Documentation/x86/x86_64/uefi.rst +++ b/Documentation/arch/x86/x86_64/uefi.rst diff --git a/Documentation/x86/xstate.rst b/Documentation/arch/x86/xstate.rst index 5cec7fb558d6..5cec7fb558d6 100644 --- a/Documentation/x86/xstate.rst +++ b/Documentation/arch/x86/xstate.rst diff --git a/Documentation/x86/zero-page.rst b/Documentation/arch/x86/zero-page.rst index 45aa9cceb4f1..45aa9cceb4f1 100644 --- a/Documentation/x86/zero-page.rst +++ b/Documentation/arch/x86/zero-page.rst diff --git a/Documentation/xtensa/atomctl.rst b/Documentation/arch/xtensa/atomctl.rst index 1ecbd0ba9a2e..1ecbd0ba9a2e 100644 --- a/Documentation/xtensa/atomctl.rst +++ b/Documentation/arch/xtensa/atomctl.rst diff --git a/Documentation/xtensa/booting.rst b/Documentation/arch/xtensa/booting.rst index e1b83707e5b6..e1b83707e5b6 100644 --- a/Documentation/xtensa/booting.rst +++ b/Documentation/arch/xtensa/booting.rst diff --git a/Documentation/xtensa/features.rst b/Documentation/arch/xtensa/features.rst index 6b92c7bfa19d..6b92c7bfa19d 100644 --- a/Documentation/xtensa/features.rst +++ b/Documentation/arch/xtensa/features.rst diff --git a/Documentation/xtensa/index.rst b/Documentation/arch/xtensa/index.rst index 69952446a9be..69952446a9be 100644 --- a/Documentation/xtensa/index.rst +++ b/Documentation/arch/xtensa/index.rst diff --git a/Documentation/xtensa/mmu.rst b/Documentation/arch/xtensa/mmu.rst index 450573afa31a..450573afa31a 100644 --- a/Documentation/xtensa/mmu.rst +++ b/Documentation/arch/xtensa/mmu.rst diff --git a/Documentation/arm/index.rst b/Documentation/arm/index.rst index ae42fe886f0d..fd43502ae924 100644 --- a/Documentation/arm/index.rst +++ b/Documentation/arm/index.rst @@ -58,6 +58,7 @@ SoC-specific documents stm32/stm32f769-overview stm32/stm32f429-overview stm32/stm32mp13-overview + stm32/stm32mp151-overview stm32/stm32mp157-overview stm32/stm32-dma-mdma-chaining @@ -69,11 +70,9 @@ SoC-specific documents spear/overview - sti/stih416-overview sti/stih407-overview sti/stih418-overview sti/overview - sti/stih415-overview vfp/release-notes diff --git a/Documentation/arm/sti/overview.rst b/Documentation/arm/sti/overview.rst index 70743617a74f..ae16aced800f 100644 --- a/Documentation/arm/sti/overview.rst +++ b/Documentation/arm/sti/overview.rst @@ -7,22 +7,18 @@ Introduction The ST Microelectronics Multimedia and Application Processors range of CortexA9 System-on-Chip are supported by the 'STi' platform of - ARM Linux. Currently STiH415, STiH416 SOCs are supported with both - B2000 and B2020 Reference boards. + ARM Linux. Currently STiH407, STiH410 and STiH418 are supported. configuration ------------- - A generic configuration is provided for both STiH415/416, and can be used as the - default by:: - - make stih41x_defconfig + The configuration for the STi platform is supported via the multi_v7_defconfig. Layout ------ - All the files for multiple machine families (STiH415, STiH416, and STiG125) + All the files for multiple machine families (STiH407, STiH410, and STiH418) are located in the platform code contained in arch/arm/mach-sti There is a generic board board-dt.c in the mach folder which support diff --git a/Documentation/arm/sti/stih415-overview.rst b/Documentation/arm/sti/stih415-overview.rst deleted file mode 100644 index b67452d610c4..000000000000 --- a/Documentation/arm/sti/stih415-overview.rst +++ /dev/null @@ -1,14 +0,0 @@ -================ -STiH415 Overview -================ - -Introduction ------------- - - The STiH415 is the next generation of HD, AVC set-top box processors - for satellite, cable, terrestrial and IP-STB markets. - - Features: - - - ARM Cortex-A9 1.0 GHz, dual-core CPU - - SATA2x2,USB 2.0x3, PCIe, Gbit Ethernet MACx2 diff --git a/Documentation/arm/sti/stih416-overview.rst b/Documentation/arm/sti/stih416-overview.rst deleted file mode 100644 index 93f17d74d8db..000000000000 --- a/Documentation/arm/sti/stih416-overview.rst +++ /dev/null @@ -1,13 +0,0 @@ -================ -STiH416 Overview -================ - -Introduction ------------- - - The STiH416 is the next generation of HD, AVC set-top box processors - for satellite, cable, terrestrial and IP-STB markets. - - Features - - ARM Cortex-A9 1.2 GHz dual core CPU - - SATA2x2,USB 2.0x3, PCIe, Gbit Ethernet MACx2 diff --git a/Documentation/arm/stm32/stm32mp151-overview.rst b/Documentation/arm/stm32/stm32mp151-overview.rst new file mode 100644 index 000000000000..f42a2ac309c0 --- /dev/null +++ b/Documentation/arm/stm32/stm32mp151-overview.rst @@ -0,0 +1,36 @@ +=================== +STM32MP151 Overview +=================== + +Introduction +------------ + +The STM32MP151 is a Cortex-A MPU aimed at various applications. +It features: + +- Single Cortex-A7 application core +- Standard memories interface support +- Standard connectivity, widely inherited from the STM32 MCU family +- Comprehensive security support + +More details: + +- Cortex-A7 core running up to @800MHz +- FMC controller to connect SDRAM, NOR and NAND memories +- QSPI +- SD/MMC/SDIO support +- Ethernet controller +- ADC/DAC +- USB EHCI/OHCI controllers +- USB OTG +- I2C, SPI busses support +- Several general purpose timers +- Serial Audio interface +- LCD-TFT controller +- DCMIPP +- SPDIFRX +- DFSDM + +:Authors: + +- Roan van Dijk <roan@protonic.nl> diff --git a/Documentation/arm64/silicon-errata.rst b/Documentation/arm64/silicon-errata.rst index ec5f889d7681..9e311bc43e05 100644 --- a/Documentation/arm64/silicon-errata.rst +++ b/Documentation/arm64/silicon-errata.rst @@ -172,6 +172,8 @@ stable kernels. +----------------+-----------------+-----------------+-----------------------------+ | NVIDIA | Carmel Core | N/A | NVIDIA_CARMEL_CNP_ERRATUM | +----------------+-----------------+-----------------+-----------------------------+ +| NVIDIA | T241 GICv3/4.x | T241-FABRIC-4 | N/A | ++----------------+-----------------+-----------------+-----------------------------+ +----------------+-----------------+-----------------+-----------------------------+ | Freescale/NXP | LS2080A/LS1043A | A-008585 | FSL_ERRATUM_A008585 | +----------------+-----------------+-----------------+-----------------------------+ @@ -205,6 +207,9 @@ stable kernels. +----------------+-----------------+-----------------+-----------------------------+ | Qualcomm Tech. | Kryo4xx Gold | N/A | ARM64_ERRATUM_1286807 | +----------------+-----------------+-----------------+-----------------------------+ ++----------------+-----------------+-----------------+-----------------------------+ +| Rockchip | RK3588 | #3588001 | ROCKCHIP_ERRATUM_3588001 | ++----------------+-----------------+-----------------+-----------------------------+ +----------------+-----------------+-----------------+-----------------------------+ | Fujitsu | A64FX | E#010001 | FUJITSU_ERRATUM_010001 | diff --git a/Documentation/conf.py b/Documentation/conf.py index db16814f182f..37314afd1ac8 100644 --- a/Documentation/conf.py +++ b/Documentation/conf.py @@ -343,9 +343,10 @@ sys.stderr.write("Using %s theme\n" % html_theme) # so a file named "default.css" will overwrite the builtin "default.css". html_static_path = ['sphinx-static'] -# If true, SmartyPants will be used to convert quotes and dashes to -# typographically correct entities. -html_use_smartypants = False +# If true, Docutils "smart quotes" will be used to convert quotes and dashes +# to typographically correct entities. This will convert "--" to "—", +# which is not always what we want, so disable it. +smartquotes = False # Custom sidebar templates, maps document names to template names. # Note that the RTD theme ignores this diff --git a/Documentation/core-api/asm-annotations.rst b/Documentation/core-api/asm-annotations.rst index bc514ed59887..11c96d3f9ad6 100644 --- a/Documentation/core-api/asm-annotations.rst +++ b/Documentation/core-api/asm-annotations.rst @@ -44,7 +44,7 @@ information. In particular, on properly annotated objects, ``objtool`` can be run to check and fix the object if needed. Currently, ``objtool`` can report missing frame pointer setup/destruction in functions. It can also automatically generate annotations for the ORC unwinder -(Documentation/x86/orc-unwinder.rst) +(Documentation/arch/x86/orc-unwinder.rst) for most code. Both of these are especially important to support reliable stack traces which are in turn necessary for kernel live patching (Documentation/livepatch/livepatch.rst). diff --git a/Documentation/core-api/dma-api-howto.rst b/Documentation/core-api/dma-api-howto.rst index 828846804e25..72f6cdb6be1c 100644 --- a/Documentation/core-api/dma-api-howto.rst +++ b/Documentation/core-api/dma-api-howto.rst @@ -185,7 +185,7 @@ device struct of your device is embedded in the bus-specific device struct of your device. For example, &pdev->dev is a pointer to the device struct of a PCI device (pdev is a pointer to the PCI device struct of your device). -These calls usually return zero to indicated your device can perform DMA +These calls usually return zero to indicate your device can perform DMA properly on the machine given the address mask you provided, but they might return an error if the mask is too small to be supportable on the given system. If it returns non-zero, your device cannot perform DMA properly on diff --git a/Documentation/core-api/memory-allocation.rst b/Documentation/core-api/memory-allocation.rst index 5954ddf6ee13..1c58d883b273 100644 --- a/Documentation/core-api/memory-allocation.rst +++ b/Documentation/core-api/memory-allocation.rst @@ -170,7 +170,16 @@ should be used if a part of the cache might be copied to the userspace. After the cache is created kmem_cache_alloc() and its convenience wrappers can allocate memory from that cache. -When the allocated memory is no longer needed it must be freed. You can -use kvfree() for the memory allocated with `kmalloc`, `vmalloc` and -`kvmalloc`. The slab caches should be freed with kmem_cache_free(). And -don't forget to destroy the cache with kmem_cache_destroy(). +When the allocated memory is no longer needed it must be freed. + +Objects allocated by `kmalloc` can be freed by `kfree` or `kvfree`. Objects +allocated by `kmem_cache_alloc` can be freed with `kmem_cache_free`, `kfree` +or `kvfree`, where the latter two might be more convenient thanks to not +needing the kmem_cache pointer. + +The same rules apply to _bulk and _rcu flavors of freeing functions. + +Memory allocated by `vmalloc` can be freed with `vfree` or `kvfree`. +Memory allocated by `kvmalloc` can be freed with `kvfree`. +Caches created by `kmem_cache_create` should be freed with +`kmem_cache_destroy` only after freeing all the allocated objects first. diff --git a/Documentation/dev-tools/kmemleak.rst b/Documentation/dev-tools/kmemleak.rst index 5483fd39ef29..2cb00b53339f 100644 --- a/Documentation/dev-tools/kmemleak.rst +++ b/Documentation/dev-tools/kmemleak.rst @@ -227,7 +227,7 @@ Testing with kmemleak-test -------------------------- To check if you have all set up to use kmemleak, you can use the kmemleak-test -module, a module that deliberately leaks memory. Set CONFIG_DEBUG_KMEMLEAK_TEST +module, a module that deliberately leaks memory. Set CONFIG_SAMPLE_KMEMLEAK as module (it can't be used as built-in) and boot the kernel with kmemleak enabled. Load the module and perform a scan with:: diff --git a/Documentation/devicetree/bindings/arm/amlogic.yaml b/Documentation/devicetree/bindings/arm/amlogic.yaml index b634d5b04e15..274ee0890312 100644 --- a/Documentation/devicetree/bindings/arm/amlogic.yaml +++ b/Documentation/devicetree/bindings/arm/amlogic.yaml @@ -153,17 +153,27 @@ properties: - description: Boards with the Amlogic Meson G12B A311D SoC items: - enum: + - bananapi,bpi-m2s - khadas,vim3 - radxa,zero2 - const: amlogic,a311d - const: amlogic,g12b + - description: Boards using the BPI-CM4 module with Amlogic Meson G12B A311D SoC + items: + - enum: + - bananapi,bpi-cm4io + - const: bananapi,bpi-cm4 + - const: amlogic,a311d + - const: amlogic,g12b + - description: Boards with the Amlogic Meson G12B S922X SoC items: - enum: - azw,gsking-x - azw,gtking - azw,gtking-pro + - bananapi,bpi-m2s - hardkernel,odroid-go-ultra - hardkernel,odroid-n2 - hardkernel,odroid-n2l diff --git a/Documentation/devicetree/bindings/arm/amlogic/amlogic,meson-gx-ao-secure.yaml b/Documentation/devicetree/bindings/arm/amlogic/amlogic,meson-gx-ao-secure.yaml index 1748f1605cc7..7dff32f373cb 100644 --- a/Documentation/devicetree/bindings/arm/amlogic/amlogic,meson-gx-ao-secure.yaml +++ b/Documentation/devicetree/bindings/arm/amlogic/amlogic,meson-gx-ao-secure.yaml @@ -2,8 +2,8 @@ # Copyright 2019 BayLibre, SAS %YAML 1.2 --- -$id: "http://devicetree.org/schemas/arm/amlogic/amlogic,meson-gx-ao-secure.yaml#" -$schema: "http://devicetree.org/meta-schemas/core.yaml#" +$id: http://devicetree.org/schemas/arm/amlogic/amlogic,meson-gx-ao-secure.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# title: Amlogic Meson Firmware registers Interface diff --git a/Documentation/devicetree/bindings/arm/amlogic/amlogic,meson-mx-secbus2.yaml b/Documentation/devicetree/bindings/arm/amlogic/amlogic,meson-mx-secbus2.yaml index eee7cda9f91b..09b27e98d4c9 100644 --- a/Documentation/devicetree/bindings/arm/amlogic/amlogic,meson-mx-secbus2.yaml +++ b/Documentation/devicetree/bindings/arm/amlogic/amlogic,meson-mx-secbus2.yaml @@ -1,8 +1,8 @@ # SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) %YAML 1.2 --- -$id: "http://devicetree.org/schemas/arm/amlogic/amlogic,meson-mx-secbus2.yaml#" -$schema: "http://devicetree.org/meta-schemas/core.yaml#" +$id: http://devicetree.org/schemas/arm/amlogic/amlogic,meson-mx-secbus2.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# title: Amlogic Meson8/Meson8b/Meson8m2 SECBUS2 register interface diff --git a/Documentation/devicetree/bindings/arm/apple.yaml b/Documentation/devicetree/bindings/arm/apple.yaml index da78c69774f2..883fd67e3752 100644 --- a/Documentation/devicetree/bindings/arm/apple.yaml +++ b/Documentation/devicetree/bindings/arm/apple.yaml @@ -19,6 +19,12 @@ description: | - MacBook Air (M1, 2020) - iMac (24-inch, M1, 2021) + Devices based on the "M2" SoC: + + - MacBook Air (M2, 2022) + - MacBook Pro (13-inch, M2, 2022) + - Mac mini (M2, 2023) + And devices based on the "M1 Pro", "M1 Max" and "M1 Ultra" SoCs: - MacBook Pro (14-inch, M1 Pro, 2021) @@ -70,6 +76,15 @@ properties: - const: apple,t8103 - const: apple,arm-platform + - description: Apple M2 SoC based platforms + items: + - enum: + - apple,j413 # MacBook Air (M2, 2022) + - apple,j473 # Mac mini (M2, 2023) + - apple,j493 # MacBook Pro (13-inch, M2, 2022) + - const: apple,t8112 + - const: apple,arm-platform + - description: Apple M1 Pro SoC based platforms items: - enum: diff --git a/Documentation/devicetree/bindings/arm/apple/apple,pmgr.yaml b/Documentation/devicetree/bindings/arm/apple/apple,pmgr.yaml index 0dc957a56d35..673277a7a224 100644 --- a/Documentation/devicetree/bindings/arm/apple/apple,pmgr.yaml +++ b/Documentation/devicetree/bindings/arm/apple/apple,pmgr.yaml @@ -23,6 +23,7 @@ properties: items: - enum: - apple,t8103-pmgr + - apple,t8112-pmgr - apple,t6000-pmgr - const: apple,pmgr - const: syscon diff --git a/Documentation/devicetree/bindings/arm/cpus.yaml b/Documentation/devicetree/bindings/arm/cpus.yaml index c145f6a035ee..e287dcaec203 100644 --- a/Documentation/devicetree/bindings/arm/cpus.yaml +++ b/Documentation/devicetree/bindings/arm/cpus.yaml @@ -85,6 +85,8 @@ properties: compatible: enum: + - apple,avalanche + - apple,blizzard - apple,icestorm - apple,firestorm - arm,arm710t diff --git a/Documentation/devicetree/bindings/arm/firmware/linaro,optee-tz.yaml b/Documentation/devicetree/bindings/arm/firmware/linaro,optee-tz.yaml index d4dc0749f9fd..5d033570b57b 100644 --- a/Documentation/devicetree/bindings/arm/firmware/linaro,optee-tz.yaml +++ b/Documentation/devicetree/bindings/arm/firmware/linaro,optee-tz.yaml @@ -28,7 +28,8 @@ properties: maxItems: 1 description: | This interrupt which is used to signal an event by the secure world - software is expected to be edge-triggered. + software is expected to be either a per-cpu interrupt or an + edge-triggered peripheral interrupt. method: enum: [smc, hvc] diff --git a/Documentation/devicetree/bindings/arm/fsl.yaml b/Documentation/devicetree/bindings/arm/fsl.yaml index 442ce8f4d675..15d411084065 100644 --- a/Documentation/devicetree/bindings/arm/fsl.yaml +++ b/Documentation/devicetree/bindings/arm/fsl.yaml @@ -300,6 +300,7 @@ properties: - variscite,dt6customboard - wand,imx6q-wandboard # Wandboard i.MX6 Quad Board - ysoft,imx6q-yapp4-crux # i.MX6 Quad Y Soft IOTA Crux board + - ysoft,imx6q-yapp4-pegasus # i.MX6 Quad Y Soft IOTA Pegasus board - zealz,imx6q-gk802 # Zealz GK802 - zii,imx6q-zii-rdu2 # ZII RDU2 Board - const: fsl,imx6q @@ -410,6 +411,7 @@ properties: - 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 + - ysoft,imx6qp-yapp4-pegasus-plus # i.MX6 Quad Plus Y Soft IOTA Pegasus+ board - zii,imx6qp-zii-rdu2 # ZII RDU2+ Board - const: fsl,imx6qp @@ -474,9 +476,11 @@ properties: - udoo,imx6dl-udoo # Udoo i.MX6 Dual-lite Board - vdl,lanmcu # Van der Laan LANMCU board - wand,imx6dl-wandboard # Wandboard i.MX6 Dual Lite Board - - ysoft,imx6dl-yapp4-draco # i.MX6 DualLite Y Soft IOTA Draco board + - ysoft,imx6dl-yapp4-draco # i.MX6 Solo Y Soft IOTA Draco board - ysoft,imx6dl-yapp4-hydra # i.MX6 DualLite Y Soft IOTA Hydra board + - ysoft,imx6dl-yapp4-lynx # i.MX6 DualLite Y Soft IOTA Lynx board - ysoft,imx6dl-yapp4-orion # i.MX6 DualLite Y Soft IOTA Orion board + - ysoft,imx6dl-yapp4-phoenix # i.MX6 DualLite Y Soft IOTA Phoenix board - ysoft,imx6dl-yapp4-ursa # i.MX6 Solo Y Soft IOTA Ursa board - const: fsl,imx6dl @@ -581,6 +585,7 @@ properties: - kobo,aura2 - kobo,tolino-shine2hd - kobo,tolino-shine3 + - kobo,tolino-vision - kobo,tolino-vision5 - revotics,imx6sl-warp # Revotics WaRP Board - const: fsl,imx6sl @@ -702,6 +707,15 @@ properties: - const: armadeus,imx6ull-opos6ul # OPOS6UL (i.MX6ULL) SoM - const: fsl,imx6ull + - description: i.MX6ULL chargebyte Tarragon Boards + items: + - enum: + - chargebyte,imx6ull-tarragon-master + - chargebyte,imx6ull-tarragon-micro + - chargebyte,imx6ull-tarragon-slave + - chargebyte,imx6ull-tarragon-slavext + - const: fsl,imx6ull + - description: i.MX6ULL DHCOM SoM based Boards items: - enum: @@ -1002,6 +1016,7 @@ properties: items: - enum: - beacon,imx8mp-beacon-kit # i.MX8MP Beacon Development Kit + - dmo,imx8mp-data-modul-edm-sbc # i.MX8MP eDM SBC - fsl,imx8mp-evk # i.MX8MP EVK Board - gateworks,imx8mp-gw74xx # i.MX8MP Gateworks Board - polyhex,imx8mp-debix # Polyhex Debix boards @@ -1020,7 +1035,9 @@ properties: - description: i.MX8MP DHCOM based Boards items: - - const: dh,imx8mp-dhcom-pdk2 # i.MX8MP DHCOM SoM on PDK2 board + - enum: + - dh,imx8mp-dhcom-pdk2 # i.MX8MP DHCOM SoM on PDK2 board + - dh,imx8mp-dhcom-pdk3 # i.MX8MP DHCOM SoM on PDK3 board - const: dh,imx8mp-dhcom-som # i.MX8MP DHCOM SoM - const: fsl,imx8mp @@ -1119,6 +1136,25 @@ properties: items: - enum: - fsl,imx8qm-mek # i.MX8QM MEK Board + - toradex,apalis-imx8 # Apalis iMX8 Modules + - toradex,apalis-imx8-v1.1 # Apalis iMX8 V1.1 Modules + - const: fsl,imx8qm + + - description: i.MX8QM Boards with Toradex Apalis iMX8 Modules + items: + - enum: + - toradex,apalis-imx8-eval # Apalis iMX8 Module on Apalis Evaluation Board + - toradex,apalis-imx8-ixora-v1.1 # Apalis iMX8 Module on Ixora V1.1 Carrier Board + - const: toradex,apalis-imx8 + - const: fsl,imx8qm + + - description: i.MX8QM Boards with Toradex Apalis iMX8 V1.1 Modules + items: + - enum: + - toradex,apalis-imx8-v1.1-eval # Apalis iMX8 V1.1 Module on Apalis Eval. Board + - toradex,apalis-imx8-v1.1-ixora-v1.1 # Apalis iMX8 V1.1 Module on Ixora V1.1 C. Board + - toradex,apalis-imx8-v1.1-ixora-v1.2 # Apalis iMX8 V1.1 Module on Ixora V1.2 C. Board + - const: toradex,apalis-imx8-v1.1 - const: fsl,imx8qm - description: i.MX8QXP based Boards @@ -1135,10 +1171,13 @@ properties: - fsl,imx8dxl-evk # i.MX8DXL EVK Board - const: fsl,imx8dxl - - description: i.MX8QXP Boards with Toradex Coilbri iMX8X Modules + - description: i.MX8QXP Boards with Toradex Colibri iMX8X Modules items: - enum: + - toradex,colibri-imx8x-aster # Colibri iMX8X Module on Aster Board - toradex,colibri-imx8x-eval-v3 # Colibri iMX8X Module on Colibri Evaluation Board V3 + - toradex,colibri-imx8x-iris # Colibri iMX8X Module on Iris Board + - toradex,colibri-imx8x-iris-v2 # Colibri iMX8X Module on Iris Board V2 - const: toradex,colibri-imx8x - const: fsl,imx8qxp diff --git a/Documentation/devicetree/bindings/arm/msm/qcom,llcc.yaml b/Documentation/devicetree/bindings/arm/msm/qcom,llcc.yaml index 38efcad56dbd..02cc6894eb13 100644 --- a/Documentation/devicetree/bindings/arm/msm/qcom,llcc.yaml +++ b/Documentation/devicetree/bindings/arm/msm/qcom,llcc.yaml @@ -7,8 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml# title: Last Level Cache Controller maintainers: - - Rishabh Bhatnagar <rishabhb@codeaurora.org> - - Sai Prakash Ranjan <saiprakash.ranjan@codeaurora.org> + - Bjorn Andersson <andersson@kernel.org> description: | LLCC (Last Level Cache Controller) provides last level of cache memory in SoC, @@ -27,6 +26,7 @@ properties: - qcom,sc8280xp-llcc - qcom,sdm845-llcc - qcom,sm6350-llcc + - qcom,sm7150-llcc - qcom,sm8150-llcc - qcom,sm8250-llcc - qcom,sm8350-llcc @@ -34,14 +34,12 @@ properties: - qcom,sm8550-llcc reg: - items: - - description: LLCC base register region - - description: LLCC broadcast base register region + minItems: 2 + maxItems: 9 reg-names: - items: - - const: llcc_base - - const: llcc_broadcast_base + minItems: 2 + maxItems: 9 interrupts: maxItems: 1 @@ -51,15 +49,120 @@ required: - reg - reg-names +allOf: + - if: + properties: + compatible: + contains: + enum: + - qcom,sc7180-llcc + - qcom,sm6350-llcc + then: + properties: + reg: + items: + - description: LLCC0 base register region + - description: LLCC broadcast base register region + reg-names: + items: + - const: llcc0_base + - const: llcc_broadcast_base + + - if: + properties: + compatible: + contains: + enum: + - qcom,sc7280-llcc + then: + properties: + reg: + items: + - description: LLCC0 base register region + - description: LLCC1 base register region + - description: LLCC broadcast base register region + reg-names: + items: + - const: llcc0_base + - const: llcc1_base + - const: llcc_broadcast_base + + - if: + properties: + compatible: + contains: + enum: + - qcom,sc8180x-llcc + - qcom,sc8280xp-llcc + then: + properties: + reg: + items: + - description: LLCC0 base register region + - description: LLCC1 base register region + - description: LLCC2 base register region + - description: LLCC3 base register region + - description: LLCC4 base register region + - description: LLCC5 base register region + - description: LLCC6 base register region + - description: LLCC7 base register region + - description: LLCC broadcast base register region + reg-names: + items: + - const: llcc0_base + - const: llcc1_base + - const: llcc2_base + - const: llcc3_base + - const: llcc4_base + - const: llcc5_base + - const: llcc6_base + - const: llcc7_base + - const: llcc_broadcast_base + + - if: + properties: + compatible: + contains: + enum: + - qcom,sdm845-llcc + - qcom,sm8150-llcc + - qcom,sm8250-llcc + - qcom,sm8350-llcc + - qcom,sm8450-llcc + then: + properties: + reg: + items: + - description: LLCC0 base register region + - description: LLCC1 base register region + - description: LLCC2 base register region + - description: LLCC3 base register region + - description: LLCC broadcast base register region + reg-names: + items: + - const: llcc0_base + - const: llcc1_base + - const: llcc2_base + - const: llcc3_base + - const: llcc_broadcast_base + additionalProperties: false examples: - | #include <dt-bindings/interrupt-controller/arm-gic.h> - system-cache-controller@1100000 { - compatible = "qcom,sdm845-llcc"; - reg = <0x1100000 0x200000>, <0x1300000 0x50000> ; - reg-names = "llcc_base", "llcc_broadcast_base"; - interrupts = <GIC_SPI 582 IRQ_TYPE_LEVEL_HIGH>; + soc { + #address-cells = <2>; + #size-cells = <2>; + + system-cache-controller@1100000 { + compatible = "qcom,sdm845-llcc"; + reg = <0 0x01100000 0 0x50000>, <0 0x01180000 0 0x50000>, + <0 0x01200000 0 0x50000>, <0 0x01280000 0 0x50000>, + <0 0x01300000 0 0x50000>; + reg-names = "llcc0_base", "llcc1_base", "llcc2_base", + "llcc3_base", "llcc_broadcast_base"; + interrupts = <GIC_SPI 582 IRQ_TYPE_LEVEL_HIGH>; + }; }; diff --git a/Documentation/devicetree/bindings/arm/nvidia,tegra194-ccplex.yaml b/Documentation/devicetree/bindings/arm/nvidia,tegra194-ccplex.yaml index b6f57d79a753..84dc6b7512af 100644 --- a/Documentation/devicetree/bindings/arm/nvidia,tegra194-ccplex.yaml +++ b/Documentation/devicetree/bindings/arm/nvidia,tegra194-ccplex.yaml @@ -1,8 +1,8 @@ # SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) %YAML 1.2 --- -$id: "http://devicetree.org/schemas/arm/nvidia,tegra194-ccplex.yaml#" -$schema: "http://devicetree.org/meta-schemas/core.yaml#" +$id: http://devicetree.org/schemas/arm/nvidia,tegra194-ccplex.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# title: NVIDIA Tegra194 CPU Complex @@ -25,7 +25,7 @@ properties: - nvidia,tegra194-ccplex nvidia,bpmp: - $ref: '/schemas/types.yaml#/definitions/phandle' + $ref: /schemas/types.yaml#/definitions/phandle description: | Specifies the bpmp node that needs to be queried to get operating point data for all CPUs. diff --git a/Documentation/devicetree/bindings/arm/oxnas.txt b/Documentation/devicetree/bindings/arm/oxnas.txt deleted file mode 100644 index ac64e60f99f1..000000000000 --- a/Documentation/devicetree/bindings/arm/oxnas.txt +++ /dev/null @@ -1,14 +0,0 @@ -Oxford Semiconductor OXNAS SoCs Family device tree bindings -------------------------------------------- - -Boards with the OX810SE SoC shall have the following properties: - Required root node property: - compatible: "oxsemi,ox810se" - -Boards with the OX820 SoC shall have the following properties: - Required root node property: - compatible: "oxsemi,ox820" - -Board compatible values: - - "wd,mbwe" (OX810SE) - - "cloudengines,pogoplugv3" (OX820) diff --git a/Documentation/devicetree/bindings/arm/pmu.yaml b/Documentation/devicetree/bindings/arm/pmu.yaml index dbb6f3dc5ae5..e14358bf0b9c 100644 --- a/Documentation/devicetree/bindings/arm/pmu.yaml +++ b/Documentation/devicetree/bindings/arm/pmu.yaml @@ -20,6 +20,8 @@ properties: items: - enum: - apm,potenza-pmu + - apple,avalanche-pmu + - apple,blizzard-pmu - apple,firestorm-pmu - apple,icestorm-pmu - arm,armv8-pmuv3 # Only for s/w models diff --git a/Documentation/devicetree/bindings/arm/qcom.yaml b/Documentation/devicetree/bindings/arm/qcom.yaml index 1bb24d46e4ee..d9dd25695c3d 100644 --- a/Documentation/devicetree/bindings/arm/qcom.yaml +++ b/Documentation/devicetree/bindings/arm/qcom.yaml @@ -30,8 +30,10 @@ description: | apq8084 apq8096 ipq4018 + ipq5332 ipq6018 ipq8074 + ipq9574 mdm9615 msm8226 msm8916 @@ -45,7 +47,10 @@ description: | msm8996 msm8998 qcs404 + qcm2290 qdu1000 + qrb2210 + qrb4210 qru1000 sa8155p sa8540p @@ -80,6 +85,9 @@ description: | The 'board' element must be one of the following strings: adp + ap-al02-c7 + ap-mi01.2 + ap-mi01.6 cdp cp01-c1 dragonboard @@ -90,6 +98,7 @@ description: | liquid mtp qrd + rb2 ride sbc x100 @@ -226,6 +235,7 @@ properties: - thwc,uf896 - thwc,ufi001c - wingtech,wt88047 + - yiming,uz801-v3 - const: qcom,msm8916 - items: @@ -322,6 +332,12 @@ properties: - items: - enum: + - qcom,ipq5332-ap-mi01.2 + - qcom,ipq5332-ap-mi01.6 + - const: qcom,ipq5332 + + - items: + - enum: - mikrotik,rb3011 - qcom,ipq8064-ap148 - const: qcom,ipq8064 @@ -333,12 +349,24 @@ properties: - qcom,ipq8074-hk10-c2 - const: qcom,ipq8074 + - items: + - enum: + - qcom,ipq9574-ap-al02-c7 + - const: qcom,ipq9574 + - description: Sierra Wireless MangOH Green with WP8548 Module items: - const: swir,mangoh-green-wp8548 - const: swir,wp8548 - const: qcom,mdm9615 + - description: Qualcomm Technologies, Inc. Robotics RB1 + items: + - enum: + - qcom,qrb2210-rb1 + - const: qcom,qrb2210 + - const: qcom,qcm2290 + - description: Qualcomm Technologies, Inc. Distributed Unit 1000 platform items: - enum: @@ -850,6 +878,12 @@ properties: - items: - enum: + - qcom,qrb4210-rb2 + - const: qcom,qrb4210 + - const: qcom,sm4250 + + - items: + - enum: - lenovo,j606f - const: qcom,sm6115p - const: qcom,sm6115 @@ -857,6 +891,7 @@ properties: - items: - enum: - sony,pdx201 + - xiaomi,laurel-sprout - const: qcom,sm6125 - items: @@ -913,6 +948,7 @@ properties: - items: - enum: - qcom,sm8550-mtp + - qcom,sm8550-qrd - const: qcom,sm8550 # Board compatibles go above diff --git a/Documentation/devicetree/bindings/arm/rockchip.yaml b/Documentation/devicetree/bindings/arm/rockchip.yaml index 35f74eda30ae..ec141c937b8b 100644 --- a/Documentation/devicetree/bindings/arm/rockchip.yaml +++ b/Documentation/devicetree/bindings/arm/rockchip.yaml @@ -185,9 +185,11 @@ properties: - const: firefly,rk3566-roc-pc - const: rockchip,rk3566 - - description: FriendlyElec NanoPi R2S + - description: FriendlyElec NanoPi R2 series boards items: - - const: friendlyarm,nanopi-r2s + - enum: + - friendlyarm,nanopi-r2c + - friendlyarm,nanopi-r2s - const: rockchip,rk3328 - description: FriendlyElec NanoPi4 series boards @@ -201,6 +203,13 @@ properties: - friendlyarm,nanopi-r4s-enterprise - const: rockchip,rk3399 + - description: FriendlyElec NanoPi R5 series boards + items: + - enum: + - friendlyarm,nanopi-r5c + - friendlyarm,nanopi-r5s + - const: rockchip,rk3568 + - description: GeekBuying GeekBox items: - const: geekbuying,geekbox @@ -533,6 +542,11 @@ properties: - khadas,edge-v - const: rockchip,rk3399 + - description: Khadas Edge2 series boards + items: + - const: khadas,edge2 + - const: rockchip,rk3588s + - description: Kobol Helios64 items: - const: kobol,helios64 @@ -817,9 +831,11 @@ properties: - const: tronsmart,orion-r68-meta - const: rockchip,rk3368 - - description: Xunlong Orange Pi R1 Plus + - description: Xunlong Orange Pi R1 Plus / LTS items: - - const: xunlong,orangepi-r1-plus + - enum: + - xunlong,orangepi-r1-plus + - xunlong,orangepi-r1-plus-lts - const: rockchip,rk3328 - description: Zkmagic A95X Z2 diff --git a/Documentation/devicetree/bindings/arm/sunxi.yaml b/Documentation/devicetree/bindings/arm/sunxi.yaml index 3ad1cd50e3fe..013821f4a7b8 100644 --- a/Documentation/devicetree/bindings/arm/sunxi.yaml +++ b/Documentation/devicetree/bindings/arm/sunxi.yaml @@ -366,6 +366,12 @@ properties: - const: lamobo,lamobo-r1 - const: allwinner,sun7i-a20 + - description: Lctech Pi F1C200s + items: + - const: lctech,pi-f1c200s + - const: allwinner,suniv-f1c200s + - const: allwinner,suniv-f1c100s + - description: Libre Computer Board ALL-H3-CC H2+ items: - const: libretech,all-h3-cc-h2-plus @@ -807,6 +813,13 @@ properties: - const: sinlinx,sina33 - const: allwinner,sun8i-a33 + - description: SourceParts PopStick v1.1 + items: + - const: sourceparts,popstick-v1.1 + - const: sourceparts,popstick + - const: allwinner,suniv-f1c200s + - const: allwinner,suniv-f1c100s + - description: SL631 Action Camera with IMX179 items: - const: allwinner,sl631-imx179 @@ -843,6 +856,11 @@ properties: - const: wexler,tab7200 - const: allwinner,sun7i-a20 + - description: MangoPi MQ-R board + items: + - const: widora,mangopi-mq-r-t113 + - const: allwinner,sun8i-t113s + - description: WITS A31 Colombus Evaluation Board items: - const: wits,colombus diff --git a/Documentation/devicetree/bindings/arm/tegra.yaml b/Documentation/devicetree/bindings/arm/tegra.yaml index 1f62253f9410..0df41f5b7e2a 100644 --- a/Documentation/devicetree/bindings/arm/tegra.yaml +++ b/Documentation/devicetree/bindings/arm/tegra.yaml @@ -167,5 +167,14 @@ properties: - const: nvidia,p3737-0000+p3701-0000 - const: nvidia,p3701-0000 - const: nvidia,tegra234 + - description: Jetson Orin NX + items: + - const: nvidia,p3767-0000 + - const: nvidia,tegra234 + - description: Jetson Orin NX Engineering Reference Developer Kit + items: + - const: nvidia,p3768-0000+p3767-0000 + - const: nvidia,p3767-0000 + - const: nvidia,tegra234 additionalProperties: true diff --git a/Documentation/devicetree/bindings/arm/tegra/nvidia,tegra-ccplex-cluster.yaml b/Documentation/devicetree/bindings/arm/tegra/nvidia,tegra-ccplex-cluster.yaml index 6089a96eae4f..36dbd0838f2d 100644 --- a/Documentation/devicetree/bindings/arm/tegra/nvidia,tegra-ccplex-cluster.yaml +++ b/Documentation/devicetree/bindings/arm/tegra/nvidia,tegra-ccplex-cluster.yaml @@ -1,8 +1,8 @@ # SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) %YAML 1.2 --- -$id: "http://devicetree.org/schemas/arm/tegra/nvidia,tegra-ccplex-cluster.yaml#" -$schema: "http://devicetree.org/meta-schemas/core.yaml#" +$id: http://devicetree.org/schemas/arm/tegra/nvidia,tegra-ccplex-cluster.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# title: NVIDIA Tegra CPU COMPLEX CLUSTER area @@ -29,7 +29,7 @@ properties: maxItems: 1 nvidia,bpmp: - $ref: '/schemas/types.yaml#/definitions/phandle' + $ref: /schemas/types.yaml#/definitions/phandle description: | Specifies the BPMP node that needs to be queried to get operating point data for all CPUs. diff --git a/Documentation/devicetree/bindings/arm/tegra/nvidia,tegra194-axi2apb.yaml b/Documentation/devicetree/bindings/arm/tegra/nvidia,tegra194-axi2apb.yaml index 788a13f8aa93..5e0f1dc542b0 100644 --- a/Documentation/devicetree/bindings/arm/tegra/nvidia,tegra194-axi2apb.yaml +++ b/Documentation/devicetree/bindings/arm/tegra/nvidia,tegra194-axi2apb.yaml @@ -1,8 +1,8 @@ # SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) %YAML 1.2 --- -$id: "http://devicetree.org/schemas/arm/tegra/nvidia,tegra194-axi2apb.yaml#" -$schema: "http://devicetree.org/meta-schemas/core.yaml#" +$id: http://devicetree.org/schemas/arm/tegra/nvidia,tegra194-axi2apb.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# title: NVIDIA Tegra194 AXI2APB bridge diff --git a/Documentation/devicetree/bindings/arm/tegra/nvidia,tegra194-cbb.yaml b/Documentation/devicetree/bindings/arm/tegra/nvidia,tegra194-cbb.yaml index dd3a4770c6a1..d9c54c32c6b9 100644 --- a/Documentation/devicetree/bindings/arm/tegra/nvidia,tegra194-cbb.yaml +++ b/Documentation/devicetree/bindings/arm/tegra/nvidia,tegra194-cbb.yaml @@ -1,8 +1,8 @@ # SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) %YAML 1.2 --- -$id: "http://devicetree.org/schemas/arm/tegra/nvidia,tegra194-cbb.yaml#" -$schema: "http://devicetree.org/meta-schemas/core.yaml#" +$id: http://devicetree.org/schemas/arm/tegra/nvidia,tegra194-cbb.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# title: NVIDIA Tegra194 CBB 1.0 @@ -64,13 +64,13 @@ properties: - description: secure interrupt nvidia,axi2apb: - $ref: '/schemas/types.yaml#/definitions/phandle' + $ref: /schemas/types.yaml#/definitions/phandle description: Specifies the node having all axi2apb bridges which need to be checked for any error logged in their status register. nvidia,apbmisc: - $ref: '/schemas/types.yaml#/definitions/phandle' + $ref: /schemas/types.yaml#/definitions/phandle description: Specifies the apbmisc node which need to be used for reading the ERD register. diff --git a/Documentation/devicetree/bindings/arm/tegra/nvidia,tegra234-cbb.yaml b/Documentation/devicetree/bindings/arm/tegra/nvidia,tegra234-cbb.yaml index 44184ee01449..fcdf03131323 100644 --- a/Documentation/devicetree/bindings/arm/tegra/nvidia,tegra234-cbb.yaml +++ b/Documentation/devicetree/bindings/arm/tegra/nvidia,tegra234-cbb.yaml @@ -1,8 +1,8 @@ # SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) %YAML 1.2 --- -$id: "http://devicetree.org/schemas/arm/tegra/nvidia,tegra234-cbb.yaml#" -$schema: "http://devicetree.org/meta-schemas/core.yaml#" +$id: http://devicetree.org/schemas/arm/tegra/nvidia,tegra234-cbb.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# title: NVIDIA Tegra CBB 2.0 diff --git a/Documentation/devicetree/bindings/arm/ti/k3.yaml b/Documentation/devicetree/bindings/arm/ti/k3.yaml index a60a4065caa8..e1183f90bb06 100644 --- a/Documentation/devicetree/bindings/arm/ti/k3.yaml +++ b/Documentation/devicetree/bindings/arm/ti/k3.yaml @@ -28,7 +28,9 @@ properties: - description: K3 AM625 SoC items: - enum: + - beagle,am625-beagleplay - ti,am625-sk + - ti,am62-lp-sk - const: ti,am625 - description: K3 AM642 SoC diff --git a/Documentation/devicetree/bindings/auxdisplay/holtek,ht16k33.yaml b/Documentation/devicetree/bindings/auxdisplay/holtek,ht16k33.yaml index fc4873deb76f..4f6ffb8182a9 100644 --- a/Documentation/devicetree/bindings/auxdisplay/holtek,ht16k33.yaml +++ b/Documentation/devicetree/bindings/auxdisplay/holtek,ht16k33.yaml @@ -10,7 +10,7 @@ maintainers: - Robin van der Gracht <robin@protonic.nl> allOf: - - $ref: "/schemas/input/matrix-keymap.yaml#" + - $ref: /schemas/input/matrix-keymap.yaml# properties: compatible: diff --git a/Documentation/devicetree/bindings/clock/apple,nco.yaml b/Documentation/devicetree/bindings/clock/apple,nco.yaml index 74eab5c0d24a..8b8411dc42f6 100644 --- a/Documentation/devicetree/bindings/clock/apple,nco.yaml +++ b/Documentation/devicetree/bindings/clock/apple,nco.yaml @@ -23,6 +23,7 @@ properties: - enum: - apple,t6000-nco - apple,t8103-nco + - apple,t8112-nco - const: apple,nco clocks: diff --git a/Documentation/devicetree/bindings/clock/qcom,ipq5332-gcc.yaml b/Documentation/devicetree/bindings/clock/qcom,ipq5332-gcc.yaml new file mode 100644 index 000000000000..718fe0625424 --- /dev/null +++ b/Documentation/devicetree/bindings/clock/qcom,ipq5332-gcc.yaml @@ -0,0 +1,53 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/clock/qcom,ipq5332-gcc.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Qualcomm Global Clock & Reset Controller on IPQ5332 + +maintainers: + - Bjorn Andersson <andersson@kernel.org> + +description: | + Qualcomm global clock control module provides the clocks, resets and power + domains on IPQ5332. + + See also:: include/dt-bindings/clock/qcom,gcc-ipq5332.h + +allOf: + - $ref: qcom,gcc.yaml# + +properties: + compatible: + const: qcom,ipq5332-gcc + + clocks: + items: + - description: Board XO clock source + - description: Sleep clock source + - description: PCIE 2lane PHY pipe clock source + - description: PCIE 2lane x1 PHY pipe clock source (For second lane) + - description: USB PCIE wrapper pipe clock source + +required: + - compatible + - clocks + +unevaluatedProperties: false + +examples: + - | + clock-controller@1800000 { + compatible = "qcom,ipq5332-gcc"; + reg = <0x01800000 0x80000>; + clocks = <&xo_board>, + <&sleep_clk>, + <&pcie_2lane_phy_pipe_clk>, + <&pcie_2lane_phy_pipe_clk_x1>, + <&usb_pcie_wrapper_pipe_clk>; + #clock-cells = <1>; + #power-domain-cells = <1>; + #reset-cells = <1>; + }; +... diff --git a/Documentation/devicetree/bindings/clock/qcom,ipq9574-gcc.yaml b/Documentation/devicetree/bindings/clock/qcom,ipq9574-gcc.yaml new file mode 100644 index 000000000000..afc68eb9d7cc --- /dev/null +++ b/Documentation/devicetree/bindings/clock/qcom,ipq9574-gcc.yaml @@ -0,0 +1,61 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/clock/qcom,ipq9574-gcc.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Qualcomm Global Clock & Reset Controller on IPQ9574 + +maintainers: + - Anusha Rao <quic_anusha@quicinc.com> + +description: | + Qualcomm global clock control module provides the clocks, resets and power + domains on IPQ9574 + + See also:: + include/dt-bindings/clock/qcom,ipq9574-gcc.h + include/dt-bindings/reset/qcom,ipq9574-gcc.h + +properties: + compatible: + const: qcom,ipq9574-gcc + + clocks: + items: + - description: Board XO source + - description: Sleep clock source + - description: Bias PLL ubi clock source + - description: PCIE30 PHY0 pipe clock source + - description: PCIE30 PHY1 pipe clock source + - description: PCIE30 PHY2 pipe clock source + - description: PCIE30 PHY3 pipe clock source + - description: USB3 PHY pipe clock source + +required: + - compatible + - clocks + +allOf: + - $ref: qcom,gcc.yaml# + +unevaluatedProperties: false + +examples: + - | + clock-controller@1800000 { + compatible = "qcom,ipq9574-gcc"; + reg = <0x01800000 0x80000>; + clocks = <&xo_board_clk>, + <&sleep_clk>, + <&bias_pll_ubi_nc_clk>, + <&pcie30_phy0_pipe_clk>, + <&pcie30_phy1_pipe_clk>, + <&pcie30_phy2_pipe_clk>, + <&pcie30_phy3_pipe_clk>, + <&usb3phy_0_cc_pipe_clk>; + #clock-cells = <1>; + #reset-cells = <1>; + #power-domain-cells = <1>; + }; +... diff --git a/Documentation/devicetree/bindings/clock/qcom,sm6115-gpucc.yaml b/Documentation/devicetree/bindings/clock/qcom,sm6115-gpucc.yaml new file mode 100644 index 000000000000..cf19f44af774 --- /dev/null +++ b/Documentation/devicetree/bindings/clock/qcom,sm6115-gpucc.yaml @@ -0,0 +1,58 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/clock/qcom,sm6115-gpucc.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Qualcomm Graphics Clock & Reset Controller on SM6115 + +maintainers: + - Konrad Dybcio <konrad.dybcio@linaro.org> + +description: | + Qualcomm graphics clock control module provides clocks, resets and power + domains on Qualcomm SoCs. + + See also:: include/dt-bindings/clock/qcom,sm6115-gpucc.h + +properties: + compatible: + enum: + - qcom,sm6115-gpucc + + clocks: + items: + - description: Board XO source + - description: GPLL0 main branch source + - description: GPLL0 main div source + +required: + - compatible + - clocks + +allOf: + - $ref: qcom,gcc.yaml# + +unevaluatedProperties: false + +examples: + - | + #include <dt-bindings/clock/qcom,gcc-sm6115.h> + #include <dt-bindings/clock/qcom,rpmcc.h> + + soc { + #address-cells = <1>; + #size-cells = <1>; + + clock-controller@5990000 { + compatible = "qcom,sm6115-gpucc"; + reg = <0x05990000 0x9000>; + clocks = <&rpmcc RPM_SMD_XO_CLK_SRC>, + <&gcc GCC_GPU_GPLL0_CLK_SRC>, + <&gcc GCC_GPU_GPLL0_DIV_CLK_SRC>; + #clock-cells = <1>; + #reset-cells = <1>; + #power-domain-cells = <1>; + }; + }; +... diff --git a/Documentation/devicetree/bindings/clock/qcom,sm6125-gpucc.yaml b/Documentation/devicetree/bindings/clock/qcom,sm6125-gpucc.yaml new file mode 100644 index 000000000000..374a1844a159 --- /dev/null +++ b/Documentation/devicetree/bindings/clock/qcom,sm6125-gpucc.yaml @@ -0,0 +1,64 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/clock/qcom,sm6125-gpucc.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Qualcomm Graphics Clock & Reset Controller on SM6125 + +maintainers: + - Konrad Dybcio <konrad.dybcio@linaro.org> + +description: | + Qualcomm graphics clock control module provides clocks and power domains on + Qualcomm SoCs. + + See also:: include/dt-bindings/clock/qcom,sm6125-gpucc.h + +properties: + compatible: + enum: + - qcom,sm6125-gpucc + + clocks: + items: + - description: Board XO source + - description: GPLL0 main branch source + + '#clock-cells': + const: 1 + + '#power-domain-cells': + const: 1 + + reg: + maxItems: 1 + +required: + - compatible + - reg + - clocks + - '#clock-cells' + - '#power-domain-cells' + +additionalProperties: false + +examples: + - | + #include <dt-bindings/clock/qcom,gcc-sm6125.h> + #include <dt-bindings/clock/qcom,rpmcc.h> + + soc { + #address-cells = <1>; + #size-cells = <1>; + + clock-controller@5990000 { + compatible = "qcom,sm6125-gpucc"; + reg = <0x05990000 0x9000>; + clocks = <&rpmcc RPM_SMD_XO_CLK_SRC>, + <&gcc GCC_GPU_GPLL0_CLK_SRC>; + #clock-cells = <1>; + #power-domain-cells = <1>; + }; + }; +... diff --git a/Documentation/devicetree/bindings/clock/qcom,sm6375-gpucc.yaml b/Documentation/devicetree/bindings/clock/qcom,sm6375-gpucc.yaml new file mode 100644 index 000000000000..b480ead5bd69 --- /dev/null +++ b/Documentation/devicetree/bindings/clock/qcom,sm6375-gpucc.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/qcom,sm6375-gpucc.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Qualcomm Graphics Clock & Reset Controller on SM6375 + +maintainers: + - Konrad Dybcio <konrad.dybcio@linaro.org> + +description: | + Qualcomm graphics clock control module provides clocks, resets and power + domains on Qualcomm SoCs. + + See also:: include/dt-bindings/clock/qcom,sm6375-gpucc.h + +properties: + compatible: + enum: + - qcom,sm6375-gpucc + + clocks: + items: + - description: Board XO source + - description: GPLL0 main branch source + - description: GPLL0 div branch source + - description: SNoC DVM GFX source + +required: + - compatible + - clocks + +allOf: + - $ref: qcom,gcc.yaml# + +unevaluatedProperties: false + +examples: + - | + #include <dt-bindings/clock/qcom,sm6375-gcc.h> + #include <dt-bindings/clock/qcom,rpmcc.h> + + soc { + #address-cells = <2>; + #size-cells = <2>; + + clock-controller@5990000 { + compatible = "qcom,sm6375-gpucc"; + reg = <0 0x05990000 0 0x9000>; + clocks = <&rpmcc RPM_SMD_XO_CLK_SRC>, + <&gcc GCC_GPU_GPLL0_CLK_SRC>, + <&gcc GCC_GPU_GPLL0_DIV_CLK_SRC>, + <&gcc GCC_GPU_SNOC_DVM_GFX_CLK>; + #clock-cells = <1>; + #reset-cells = <1>; + #power-domain-cells = <1>; + }; + }; +... diff --git a/Documentation/devicetree/bindings/clock/samsung,exynos850-clock.yaml b/Documentation/devicetree/bindings/clock/samsung,exynos850-clock.yaml index 141cf173f87d..8aa87b8c1b33 100644 --- a/Documentation/devicetree/bindings/clock/samsung,exynos850-clock.yaml +++ b/Documentation/devicetree/bindings/clock/samsung,exynos850-clock.yaml @@ -37,6 +37,7 @@ properties: - samsung,exynos850-cmu-cmgp - samsung,exynos850-cmu-core - samsung,exynos850-cmu-dpu + - samsung,exynos850-cmu-g3d - samsung,exynos850-cmu-hsi - samsung,exynos850-cmu-is - samsung,exynos850-cmu-mfcmscl @@ -173,6 +174,24 @@ allOf: properties: compatible: contains: + const: samsung,exynos850-cmu-g3d + + then: + properties: + clocks: + items: + - description: External reference clock (26 MHz) + - description: G3D clock (from CMU_TOP) + + clock-names: + items: + - const: oscclk + - const: dout_g3d_switch + + - if: + properties: + compatible: + contains: const: samsung,exynos850-cmu-hsi then: diff --git a/Documentation/devicetree/bindings/clock/starfive,jh7110-aoncrg.yaml b/Documentation/devicetree/bindings/clock/starfive,jh7110-aoncrg.yaml new file mode 100644 index 000000000000..923680a44aef --- /dev/null +++ b/Documentation/devicetree/bindings/clock/starfive,jh7110-aoncrg.yaml @@ -0,0 +1,107 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/clock/starfive,jh7110-aoncrg.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: StarFive JH7110 Always-On Clock and Reset Generator + +maintainers: + - Emil Renner Berthing <kernel@esmil.dk> + +properties: + compatible: + const: starfive,jh7110-aoncrg + + reg: + maxItems: 1 + + clocks: + oneOf: + - items: + - description: Main Oscillator (24 MHz) + - description: GMAC0 RMII reference or GMAC0 RGMII RX + - description: STG AXI/AHB + - description: APB Bus + - description: GMAC0 GTX + + - items: + - description: Main Oscillator (24 MHz) + - description: GMAC0 RMII reference or GMAC0 RGMII RX + - description: STG AXI/AHB or GMAC0 RGMII RX + - description: APB Bus or STG AXI/AHB + - description: GMAC0 GTX or APB Bus + - description: RTC Oscillator (32.768 kHz) or GMAC0 GTX + + - items: + - description: Main Oscillator (24 MHz) + - description: GMAC0 RMII reference + - description: GMAC0 RGMII RX + - description: STG AXI/AHB + - description: APB Bus + - description: GMAC0 GTX + - description: RTC Oscillator (32.768 kHz) + + clock-names: + oneOf: + - minItems: 5 + items: + - const: osc + - enum: + - gmac0_rmii_refin + - gmac0_rgmii_rxin + - const: stg_axiahb + - const: apb_bus + - const: gmac0_gtxclk + - const: rtc_osc + + - minItems: 6 + items: + - const: osc + - const: gmac0_rmii_refin + - const: gmac0_rgmii_rxin + - const: stg_axiahb + - const: apb_bus + - const: gmac0_gtxclk + - const: rtc_osc + + '#clock-cells': + const: 1 + description: + See <dt-bindings/clock/starfive,jh7110-crg.h> for valid indices. + + '#reset-cells': + const: 1 + description: + See <dt-bindings/reset/starfive,jh7110-crg.h> for valid indices. + +required: + - compatible + - reg + - clocks + - clock-names + - '#clock-cells' + - '#reset-cells' + +additionalProperties: false + +examples: + - | + #include <dt-bindings/clock/starfive,jh7110-crg.h> + + clock-controller@17000000 { + compatible = "starfive,jh7110-aoncrg"; + reg = <0x17000000 0x10000>; + clocks = <&osc>, <&gmac0_rmii_refin>, + <&gmac0_rgmii_rxin>, + <&syscrg JH7110_SYSCLK_STG_AXIAHB>, + <&syscrg JH7110_SYSCLK_APB_BUS>, + <&syscrg JH7110_SYSCLK_GMAC0_GTXCLK>, + <&rtc_osc>; + clock-names = "osc", "gmac0_rmii_refin", + "gmac0_rgmii_rxin", "stg_axiahb", + "apb_bus", "gmac0_gtxclk", + "rtc_osc"; + #clock-cells = <1>; + #reset-cells = <1>; + }; diff --git a/Documentation/devicetree/bindings/clock/starfive,jh7110-syscrg.yaml b/Documentation/devicetree/bindings/clock/starfive,jh7110-syscrg.yaml new file mode 100644 index 000000000000..84373ae31644 --- /dev/null +++ b/Documentation/devicetree/bindings/clock/starfive,jh7110-syscrg.yaml @@ -0,0 +1,104 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/clock/starfive,jh7110-syscrg.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: StarFive JH7110 System Clock and Reset Generator + +maintainers: + - Emil Renner Berthing <kernel@esmil.dk> + +properties: + compatible: + const: starfive,jh7110-syscrg + + reg: + maxItems: 1 + + clocks: + oneOf: + - items: + - description: Main Oscillator (24 MHz) + - description: GMAC1 RMII reference or GMAC1 RGMII RX + - description: External I2S TX bit clock + - description: External I2S TX left/right channel clock + - description: External I2S RX bit clock + - description: External I2S RX left/right channel clock + - description: External TDM clock + - description: External audio master clock + + - items: + - description: Main Oscillator (24 MHz) + - description: GMAC1 RMII reference + - description: GMAC1 RGMII RX + - description: External I2S TX bit clock + - description: External I2S TX left/right channel clock + - description: External I2S RX bit clock + - description: External I2S RX left/right channel clock + - description: External TDM clock + - description: External audio master clock + + clock-names: + oneOf: + - items: + - const: osc + - enum: + - gmac1_rmii_refin + - gmac1_rgmii_rxin + - const: i2stx_bclk_ext + - const: i2stx_lrck_ext + - const: i2srx_bclk_ext + - const: i2srx_lrck_ext + - const: tdm_ext + - const: mclk_ext + + - items: + - const: osc + - const: gmac1_rmii_refin + - const: gmac1_rgmii_rxin + - const: i2stx_bclk_ext + - const: i2stx_lrck_ext + - const: i2srx_bclk_ext + - const: i2srx_lrck_ext + - const: tdm_ext + - const: mclk_ext + + '#clock-cells': + const: 1 + description: + See <dt-bindings/clock/starfive,jh7110-crg.h> for valid indices. + + '#reset-cells': + const: 1 + description: + See <dt-bindings/reset/starfive,jh7110-crg.h> for valid indices. + +required: + - compatible + - reg + - clocks + - clock-names + - '#clock-cells' + - '#reset-cells' + +additionalProperties: false + +examples: + - | + clock-controller@13020000 { + compatible = "starfive,jh7110-syscrg"; + reg = <0x13020000 0x10000>; + clocks = <&osc>, <&gmac1_rmii_refin>, + <&gmac1_rgmii_rxin>, + <&i2stx_bclk_ext>, <&i2stx_lrck_ext>, + <&i2srx_bclk_ext>, <&i2srx_lrck_ext>, + <&tdm_ext>, <&mclk_ext>; + clock-names = "osc", "gmac1_rmii_refin", + "gmac1_rgmii_rxin", + "i2stx_bclk_ext", "i2stx_lrck_ext", + "i2srx_bclk_ext", "i2srx_lrck_ext", + "tdm_ext", "mclk_ext"; + #clock-cells = <1>; + #reset-cells = <1>; + }; diff --git a/Documentation/devicetree/bindings/crypto/qcom,inline-crypto-engine.yaml b/Documentation/devicetree/bindings/crypto/qcom,inline-crypto-engine.yaml new file mode 100644 index 000000000000..92e1d76e29ee --- /dev/null +++ b/Documentation/devicetree/bindings/crypto/qcom,inline-crypto-engine.yaml @@ -0,0 +1,42 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/crypto/qcom,inline-crypto-engine.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Qualcomm Technologies, Inc. (QTI) Inline Crypto Engine + +maintainers: + - Bjorn Andersson <andersson@kernel.org> + +properties: + compatible: + items: + - enum: + - qcom,sm8550-inline-crypto-engine + - const: qcom,inline-crypto-engine + + reg: + maxItems: 1 + + clocks: + maxItems: 1 + +required: + - compatible + - reg + - clocks + +additionalProperties: false + +examples: + - | + #include <dt-bindings/clock/qcom,sm8550-gcc.h> + + crypto@1d88000 { + compatible = "qcom,sm8550-inline-crypto-engine", + "qcom,inline-crypto-engine"; + reg = <0x01d88000 0x8000>; + clocks = <&gcc GCC_UFS_PHY_ICE_CORE_CLK>; + }; +... diff --git a/Documentation/devicetree/bindings/display/amlogic,meson-dw-hdmi.yaml b/Documentation/devicetree/bindings/display/amlogic,meson-dw-hdmi.yaml index 74cefdf1b843..0c85894648d8 100644 --- a/Documentation/devicetree/bindings/display/amlogic,meson-dw-hdmi.yaml +++ b/Documentation/devicetree/bindings/display/amlogic,meson-dw-hdmi.yaml @@ -2,8 +2,8 @@ # Copyright 2019 BayLibre, SAS %YAML 1.2 --- -$id: "http://devicetree.org/schemas/display/amlogic,meson-dw-hdmi.yaml#" -$schema: "http://devicetree.org/meta-schemas/core.yaml#" +$id: http://devicetree.org/schemas/display/amlogic,meson-dw-hdmi.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# title: Amlogic specific extensions to the Synopsys Designware HDMI Controller diff --git a/Documentation/devicetree/bindings/display/amlogic,meson-vpu.yaml b/Documentation/devicetree/bindings/display/amlogic,meson-vpu.yaml index 6655a93b1874..0c72120acc4f 100644 --- a/Documentation/devicetree/bindings/display/amlogic,meson-vpu.yaml +++ b/Documentation/devicetree/bindings/display/amlogic,meson-vpu.yaml @@ -2,8 +2,8 @@ # Copyright 2019 BayLibre, SAS %YAML 1.2 --- -$id: "http://devicetree.org/schemas/display/amlogic,meson-vpu.yaml#" -$schema: "http://devicetree.org/meta-schemas/core.yaml#" +$id: http://devicetree.org/schemas/display/amlogic,meson-vpu.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# title: Amlogic Meson Display Controller diff --git a/Documentation/devicetree/bindings/display/bridge/analogix,anx7625.yaml b/Documentation/devicetree/bindings/display/bridge/analogix,anx7625.yaml index 4590186c4a0b..b42553ac505c 100644 --- a/Documentation/devicetree/bindings/display/bridge/analogix,anx7625.yaml +++ b/Documentation/devicetree/bindings/display/bridge/analogix,anx7625.yaml @@ -2,8 +2,8 @@ # Copyright 2019 Analogix Semiconductor, Inc. %YAML 1.2 --- -$id: "http://devicetree.org/schemas/display/bridge/analogix,anx7625.yaml#" -$schema: "http://devicetree.org/meta-schemas/core.yaml#" +$id: http://devicetree.org/schemas/display/bridge/analogix,anx7625.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# title: Analogix ANX7625 SlimPort (4K Mobile HD Transmitter) diff --git a/Documentation/devicetree/bindings/display/bridge/analogix,dp.yaml b/Documentation/devicetree/bindings/display/bridge/analogix,dp.yaml new file mode 100644 index 000000000000..c9b06885cc63 --- /dev/null +++ b/Documentation/devicetree/bindings/display/bridge/analogix,dp.yaml @@ -0,0 +1,63 @@ +# SPDX-License-Identifier: GPL-2.0 +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/display/bridge/analogix,dp.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Analogix Display Port bridge + +maintainers: + - Rob Herring <robh@kernel.org> + +properties: + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + clocks: true + + clock-names: true + + phys: true + + phy-names: + const: dp + + force-hpd: + description: + Indicate driver need force hpd when hpd detect failed, this + is used for some eDP screen which don not have a hpd signal. + + hpd-gpios: + description: + Hotplug detect GPIO. + Indicates which GPIO should be used for hotplug detection + + ports: + $ref: /schemas/graph.yaml#/properties/ports + + properties: + port@0: + $ref: /schemas/graph.yaml#/properties/port + description: + Input node to receive pixel data. + + port@1: + $ref: /schemas/graph.yaml#/properties/port + description: + Port node with one endpoint connected to a dp-connector node. + + required: + - port@0 + - port@1 + +required: + - reg + - interrupts + - clock-names + - clocks + - ports + +additionalProperties: true diff --git a/Documentation/devicetree/bindings/display/bridge/analogix_dp.txt b/Documentation/devicetree/bindings/display/bridge/analogix_dp.txt deleted file mode 100644 index 027d76c27a41..000000000000 --- a/Documentation/devicetree/bindings/display/bridge/analogix_dp.txt +++ /dev/null @@ -1,51 +0,0 @@ -Analogix Display Port bridge bindings - -Required properties for dp-controller: - -compatible: - platform specific such as: - * "samsung,exynos5-dp" - * "rockchip,rk3288-dp" - * "rockchip,rk3399-edp" - -reg: - physical base address of the controller and length - of memory mapped region. - -interrupts: - interrupt combiner values. - -clocks: - from common clock binding: handle to dp clock. - -clock-names: - from common clock binding: Shall be "dp". - -phys: - from general PHY binding: the phandle for the PHY device. - -phy-names: - from general PHY binding: Should be "dp". - -Optional properties for dp-controller: - -force-hpd: - Indicate driver need force hpd when hpd detect failed, this - is used for some eDP screen which don't have hpd signal. - -hpd-gpios: - Hotplug detect GPIO. - Indicates which GPIO should be used for hotplug detection - -port@[X]: SoC specific port nodes with endpoint definitions as defined - in Documentation/devicetree/bindings/media/video-interfaces.txt, - please refer to the SoC specific binding document: - * Documentation/devicetree/bindings/display/exynos/exynos_dp.txt - * Documentation/devicetree/bindings/display/rockchip/analogix_dp-rockchip.txt - -[1]: Documentation/devicetree/bindings/media/video-interfaces.txt -------------------------------------------------------------------------------- - -Example: - - dp-controller { - compatible = "samsung,exynos5-dp"; - reg = <0x145b0000 0x10000>; - interrupts = <10 3>; - interrupt-parent = <&combiner>; - clocks = <&clock 342>; - clock-names = "dp"; - - phys = <&dp_phy>; - phy-names = "dp"; - }; diff --git a/Documentation/devicetree/bindings/display/bridge/cdns,mhdp8546.yaml b/Documentation/devicetree/bindings/display/bridge/cdns,mhdp8546.yaml index b2e8bc6da9d0..c2b369456e4e 100644 --- a/Documentation/devicetree/bindings/display/bridge/cdns,mhdp8546.yaml +++ b/Documentation/devicetree/bindings/display/bridge/cdns,mhdp8546.yaml @@ -1,8 +1,8 @@ # SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) %YAML 1.2 --- -$id: "http://devicetree.org/schemas/display/bridge/cdns,mhdp8546.yaml#" -$schema: "http://devicetree.org/meta-schemas/core.yaml#" +$id: http://devicetree.org/schemas/display/bridge/cdns,mhdp8546.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# title: Cadence MHDP8546 bridge diff --git a/Documentation/devicetree/bindings/display/bridge/nxp,ptn3460.yaml b/Documentation/devicetree/bindings/display/bridge/nxp,ptn3460.yaml index 107dd138e6c6..cdeb67bc05f0 100644 --- a/Documentation/devicetree/bindings/display/bridge/nxp,ptn3460.yaml +++ b/Documentation/devicetree/bindings/display/bridge/nxp,ptn3460.yaml @@ -18,7 +18,7 @@ properties: maxItems: 1 edid-emulation: - $ref: "/schemas/types.yaml#/definitions/uint32" + $ref: /schemas/types.yaml#/definitions/uint32 description: The EDID emulation entry to use Value Resolution Description diff --git a/Documentation/devicetree/bindings/display/bridge/samsung,mipi-dsim.yaml b/Documentation/devicetree/bindings/display/bridge/samsung,mipi-dsim.yaml new file mode 100644 index 000000000000..e841659e20cd --- /dev/null +++ b/Documentation/devicetree/bindings/display/bridge/samsung,mipi-dsim.yaml @@ -0,0 +1,255 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/display/bridge/samsung,mipi-dsim.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Samsung MIPI DSIM bridge controller + +maintainers: + - Inki Dae <inki.dae@samsung.com> + - Jagan Teki <jagan@amarulasolutions.com> + - Marek Szyprowski <m.szyprowski@samsung.com> + +description: | + Samsung MIPI DSIM bridge controller can be found it on Exynos + and i.MX8M Mini/Nano/Plus SoC's. + +properties: + compatible: + oneOf: + - enum: + - samsung,exynos3250-mipi-dsi + - samsung,exynos4210-mipi-dsi + - samsung,exynos5410-mipi-dsi + - samsung,exynos5422-mipi-dsi + - samsung,exynos5433-mipi-dsi + - fsl,imx8mm-mipi-dsim + - fsl,imx8mp-mipi-dsim + - items: + - const: fsl,imx8mn-mipi-dsim + - const: fsl,imx8mm-mipi-dsim + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + '#address-cells': + const: 1 + + '#size-cells': + const: 0 + + clocks: + minItems: 2 + maxItems: 5 + + clock-names: + minItems: 2 + maxItems: 5 + + samsung,phy-type: + $ref: /schemas/types.yaml#/definitions/uint32 + description: phandle to the samsung phy-type + + power-domains: + maxItems: 1 + + samsung,power-domain: + $ref: /schemas/types.yaml#/definitions/phandle + description: phandle to the associated samsung power domain + + vddcore-supply: + description: MIPI DSIM Core voltage supply (e.g. 1.1V) + + vddio-supply: + description: MIPI DSIM I/O and PLL voltage supply (e.g. 1.8V) + + samsung,burst-clock-frequency: + $ref: /schemas/types.yaml#/definitions/uint32 + description: + DSIM high speed burst mode frequency. + + samsung,esc-clock-frequency: + $ref: /schemas/types.yaml#/definitions/uint32 + description: + DSIM escape mode frequency. + + samsung,pll-clock-frequency: + $ref: /schemas/types.yaml#/definitions/uint32 + description: + DSIM oscillator clock frequency. + + phys: + maxItems: 1 + + phy-names: + const: dsim + + ports: + $ref: /schemas/graph.yaml#/properties/ports + + properties: + port@0: + $ref: /schemas/graph.yaml#/properties/port + description: + Input port node to receive pixel data from the + display controller. Exactly one endpoint must be + specified. + + port@1: + $ref: /schemas/graph.yaml#/properties/port + description: + DSI output port node to the panel or the next bridge + in the chain. + +required: + - clock-names + - clocks + - compatible + - interrupts + - reg + - samsung,burst-clock-frequency + - samsung,esc-clock-frequency + - samsung,pll-clock-frequency + +allOf: + - $ref: ../dsi-controller.yaml# + - if: + properties: + compatible: + contains: + const: samsung,exynos5433-mipi-dsi + + then: + properties: + clocks: + minItems: 5 + + clock-names: + items: + - const: bus_clk + - const: phyclk_mipidphy0_bitclkdiv8 + - const: phyclk_mipidphy0_rxclkesc0 + - const: sclk_rgb_vclk_to_dsim0 + - const: sclk_mipi + + ports: + required: + - port@0 + + required: + - ports + - vddcore-supply + - vddio-supply + + - if: + properties: + compatible: + contains: + const: samsung,exynos5410-mipi-dsi + + then: + properties: + clocks: + minItems: 2 + + clock-names: + items: + - const: bus_clk + - const: pll_clk + + required: + - vddcore-supply + - vddio-supply + + - if: + properties: + compatible: + contains: + const: samsung,exynos4210-mipi-dsi + + then: + properties: + clocks: + minItems: 2 + + clock-names: + items: + - const: bus_clk + - const: sclk_mipi + + required: + - vddcore-supply + - vddio-supply + + - if: + properties: + compatible: + contains: + const: samsung,exynos3250-mipi-dsi + + then: + properties: + clocks: + minItems: 2 + + clock-names: + items: + - const: bus_clk + - const: pll_clk + + required: + - vddcore-supply + - vddio-supply + - samsung,phy-type + +additionalProperties: + type: object + +examples: + - | + #include <dt-bindings/clock/exynos5433.h> + #include <dt-bindings/gpio/gpio.h> + #include <dt-bindings/interrupt-controller/arm-gic.h> + + dsi@13900000 { + compatible = "samsung,exynos5433-mipi-dsi"; + reg = <0x13900000 0xC0>; + interrupts = <GIC_SPI 205 IRQ_TYPE_LEVEL_HIGH>; + phys = <&mipi_phy 1>; + phy-names = "dsim"; + clocks = <&cmu_disp CLK_PCLK_DSIM0>, + <&cmu_disp CLK_PHYCLK_MIPIDPHY0_BITCLKDIV8>, + <&cmu_disp CLK_PHYCLK_MIPIDPHY0_RXCLKESC0>, + <&cmu_disp CLK_SCLK_RGB_VCLK_TO_DSIM0>, + <&cmu_disp CLK_SCLK_DSIM0>; + clock-names = "bus_clk", + "phyclk_mipidphy0_bitclkdiv8", + "phyclk_mipidphy0_rxclkesc0", + "sclk_rgb_vclk_to_dsim0", + "sclk_mipi"; + power-domains = <&pd_disp>; + vddcore-supply = <&ldo6_reg>; + vddio-supply = <&ldo7_reg>; + samsung,burst-clock-frequency = <512000000>; + samsung,esc-clock-frequency = <16000000>; + samsung,pll-clock-frequency = <24000000>; + pinctrl-names = "default"; + pinctrl-0 = <&te_irq>; + + ports { + #address-cells = <1>; + #size-cells = <0>; + + port@0 { + reg = <0>; + + dsi_to_mic: endpoint { + remote-endpoint = <&mic_to_dsi>; + }; + }; + }; + }; diff --git a/Documentation/devicetree/bindings/display/bridge/snps,dw-mipi-dsi.yaml b/Documentation/devicetree/bindings/display/bridge/snps,dw-mipi-dsi.yaml index 11fd68a70dca..0b51c64f141a 100644 --- a/Documentation/devicetree/bindings/display/bridge/snps,dw-mipi-dsi.yaml +++ b/Documentation/devicetree/bindings/display/bridge/snps,dw-mipi-dsi.yaml @@ -26,19 +26,9 @@ properties: reg: maxItems: 1 - clocks: - items: - - description: Module clock - - description: DSI bus clock for either AHB and APB - - description: Pixel clock for the DPI/RGB input - minItems: 2 - - clock-names: - items: - - const: ref - - const: pclk - - const: px_clk - minItems: 2 + clocks: true + + clock-names: true resets: maxItems: 1 diff --git a/Documentation/devicetree/bindings/display/bridge/toshiba,tc358767.yaml b/Documentation/devicetree/bindings/display/bridge/toshiba,tc358767.yaml index 140927884418..e1494b5007cb 100644 --- a/Documentation/devicetree/bindings/display/bridge/toshiba,tc358767.yaml +++ b/Documentation/devicetree/bindings/display/bridge/toshiba,tc358767.yaml @@ -23,7 +23,7 @@ properties: i2c address of the bridge, 0x68 or 0x0f, depending on bootstrap pins clock-names: - const: "ref" + const: ref clocks: maxItems: 1 diff --git a/Documentation/devicetree/bindings/display/dp-aux-bus.yaml b/Documentation/devicetree/bindings/display/dp-aux-bus.yaml index 5e4afe9f98fb..0ece7b01790b 100644 --- a/Documentation/devicetree/bindings/display/dp-aux-bus.yaml +++ b/Documentation/devicetree/bindings/display/dp-aux-bus.yaml @@ -26,7 +26,7 @@ description: properties: $nodename: - const: "aux-bus" + const: aux-bus panel: $ref: panel/panel-common.yaml# diff --git a/Documentation/devicetree/bindings/display/dsi-controller.yaml b/Documentation/devicetree/bindings/display/dsi-controller.yaml index ca21671f6bdd..67ce10307ee0 100644 --- a/Documentation/devicetree/bindings/display/dsi-controller.yaml +++ b/Documentation/devicetree/bindings/display/dsi-controller.yaml @@ -30,6 +30,15 @@ properties: $nodename: pattern: "^dsi(@.*)?$" + clock-master: + type: boolean + description: + Should be enabled if the host is being used in conjunction with + another DSI host to drive the same peripheral. Hardware supporting + such a configuration generally requires the data on both the busses + to be driven by the same clock. Only the DSI host instance + controlling this clock should contain this property. + "#address-cells": const: 1 @@ -52,15 +61,6 @@ patternProperties: case the reg property can take multiple entries, one for each virtual channel that the peripheral responds to. - clock-master: - type: boolean - description: - Should be enabled if the host is being used in conjunction with - another DSI host to drive the same peripheral. Hardware supporting - such a configuration generally requires the data on both the busses - to be driven by the same clock. Only the DSI host instance - controlling this clock should contain this property. - enforce-video-mode: type: boolean description: diff --git a/Documentation/devicetree/bindings/display/exynos/exynos_dp.txt b/Documentation/devicetree/bindings/display/exynos/exynos_dp.txt index 9b6cba3f82af..3a401590320f 100644 --- a/Documentation/devicetree/bindings/display/exynos/exynos_dp.txt +++ b/Documentation/devicetree/bindings/display/exynos/exynos_dp.txt @@ -50,7 +50,7 @@ Optional properties for dp-controller: Documentation/devicetree/bindings/display/panel/display-timing.txt For the below properties, please refer to Analogix DP binding document: - * Documentation/devicetree/bindings/display/bridge/analogix_dp.txt + * Documentation/devicetree/bindings/display/bridge/analogix,dp.yaml -phys (required) -phy-names (required) -hpd-gpios (optional) diff --git a/Documentation/devicetree/bindings/display/exynos/exynos_dsim.txt b/Documentation/devicetree/bindings/display/exynos/exynos_dsim.txt deleted file mode 100644 index be377786e8cd..000000000000 --- a/Documentation/devicetree/bindings/display/exynos/exynos_dsim.txt +++ /dev/null @@ -1,90 +0,0 @@ -Exynos MIPI DSI Master - -Required properties: - - compatible: value should be one of the following - "samsung,exynos3250-mipi-dsi" /* for Exynos3250/3472 SoCs */ - "samsung,exynos4210-mipi-dsi" /* for Exynos4 SoCs */ - "samsung,exynos5410-mipi-dsi" /* for Exynos5410/5420/5440 SoCs */ - "samsung,exynos5422-mipi-dsi" /* for Exynos5422/5800 SoCs */ - "samsung,exynos5433-mipi-dsi" /* for Exynos5433 SoCs */ - - reg: physical base address and length of the registers set for the device - - interrupts: should contain DSI interrupt - - clocks: list of clock specifiers, must contain an entry for each required - entry in clock-names - - clock-names: should include "bus_clk"and "sclk_mipi" entries - the use of "pll_clk" is deprecated - - phys: list of phy specifiers, must contain an entry for each required - entry in phy-names - - phy-names: should include "dsim" entry - - vddcore-supply: MIPI DSIM Core voltage supply (e.g. 1.1V) - - vddio-supply: MIPI DSIM I/O and PLL voltage supply (e.g. 1.8V) - - samsung,pll-clock-frequency: specifies frequency of the oscillator clock - - #address-cells, #size-cells: should be set respectively to <1> and <0> - according to DSI host bindings (see MIPI DSI bindings [1]) - - samsung,burst-clock-frequency: specifies DSI frequency in high-speed burst - mode - - samsung,esc-clock-frequency: specifies DSI frequency in escape mode - -Optional properties: - - power-domains: a phandle to DSIM power domain node - -Child nodes: - Should contain DSI peripheral nodes (see MIPI DSI bindings [1]). - -Video interfaces: - Device node can contain following video interface port nodes according to [2]: - 0: RGB input, - 1: DSI output - -[1]: Documentation/devicetree/bindings/display/mipi-dsi-bus.txt -[2]: Documentation/devicetree/bindings/media/video-interfaces.txt - -Example: - - dsi@11c80000 { - compatible = "samsung,exynos4210-mipi-dsi"; - reg = <0x11C80000 0x10000>; - interrupts = <0 79 0>; - clocks = <&clock 286>, <&clock 143>; - clock-names = "bus_clk", "sclk_mipi"; - phys = <&mipi_phy 1>; - phy-names = "dsim"; - vddcore-supply = <&vusb_reg>; - vddio-supply = <&vmipi_reg>; - power-domains = <&pd_lcd0>; - #address-cells = <1>; - #size-cells = <0>; - samsung,pll-clock-frequency = <24000000>; - - panel@1 { - reg = <0>; - ... - port { - panel_ep: endpoint { - remote-endpoint = <&dsi_ep>; - }; - }; - }; - - ports { - #address-cells = <1>; - #size-cells = <0>; - - port@0 { - reg = <0>; - decon_to_mic: endpoint { - remote-endpoint = <&mic_to_decon>; - }; - }; - - port@1 { - reg = <1>; - dsi_ep: endpoint { - reg = <0>; - samsung,burst-clock-frequency = <500000000>; - samsung,esc-clock-frequency = <20000000>; - remote-endpoint = <&panel_ep>; - }; - }; - }; - }; diff --git a/Documentation/devicetree/bindings/display/imx/fsl,imx-lcdc.yaml b/Documentation/devicetree/bindings/display/imx/fsl,imx-lcdc.yaml index 35a8fff036ca..c2b29622bceb 100644 --- a/Documentation/devicetree/bindings/display/imx/fsl,imx-lcdc.yaml +++ b/Documentation/devicetree/bindings/display/imx/fsl,imx-lcdc.yaml @@ -21,6 +21,9 @@ properties: - fsl,imx25-fb - fsl,imx27-fb - const: fsl,imx21-fb + - items: + - const: fsl,imx25-lcdc + - const: fsl,imx21-lcdc clocks: maxItems: 3 @@ -31,6 +34,9 @@ properties: - const: ahb - const: per + port: + $ref: /schemas/graph.yaml#/properties/port + display: $ref: /schemas/types.yaml#/definitions/phandle @@ -59,11 +65,35 @@ properties: description: LCDC Sharp Configuration Register value. +allOf: + - if: + properties: + compatible: + contains: + enum: + - fsl,imx1-lcdc + - fsl,imx21-lcdc + then: + properties: + display: false + fsl,dmacr: false + fsl,lpccr: false + fsl,lscr1: false + + required: + - port + + else: + properties: + port: false + + required: + - display + required: - compatible - clocks - clock-names - - display - interrupts - reg @@ -71,6 +101,20 @@ additionalProperties: false examples: - | + lcdc@53fbc000 { + compatible = "fsl,imx25-lcdc", "fsl,imx21-lcdc"; + reg = <0x53fbc000 0x4000>; + interrupts = <39>; + clocks = <&clks 103>, <&clks 66>, <&clks 49>; + clock-names = "ipg", "ahb", "per"; + + port { + parallel_out: endpoint { + remote-endpoint = <&panel_in>; + }; + }; + }; + - | imxfb: fb@10021000 { compatible = "fsl,imx21-fb"; interrupts = <61>; diff --git a/Documentation/devicetree/bindings/display/imx/nxp,imx8mq-dcss.yaml b/Documentation/devicetree/bindings/display/imx/nxp,imx8mq-dcss.yaml index 989ab312c1f4..4ae6328cde64 100644 --- a/Documentation/devicetree/bindings/display/imx/nxp,imx8mq-dcss.yaml +++ b/Documentation/devicetree/bindings/display/imx/nxp,imx8mq-dcss.yaml @@ -2,8 +2,8 @@ # Copyright 2019 NXP %YAML 1.2 --- -$id: "http://devicetree.org/schemas/display/imx/nxp,imx8mq-dcss.yaml#" -$schema: "http://devicetree.org/meta-schemas/core.yaml#" +$id: http://devicetree.org/schemas/display/imx/nxp,imx8mq-dcss.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# title: iMX8MQ Display Controller Subsystem (DCSS) diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,ccorr.yaml b/Documentation/devicetree/bindings/display/mediatek/mediatek,ccorr.yaml index b04820c95b22..bda86e6857f5 100644 --- a/Documentation/devicetree/bindings/display/mediatek/mediatek,ccorr.yaml +++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,ccorr.yaml @@ -27,13 +27,10 @@ properties: - const: mediatek,mt8192-disp-ccorr - items: - enum: + - mediatek,mt8186-disp-ccorr - mediatek,mt8188-disp-ccorr - mediatek,mt8195-disp-ccorr - const: mediatek,mt8192-disp-ccorr - - items: - - enum: - - mediatek,mt8186-disp-ccorr - - const: mediatek,mt8192-disp-ccorr reg: maxItems: 1 diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,ethdr.yaml b/Documentation/devicetree/bindings/display/mediatek/mediatek,ethdr.yaml new file mode 100644 index 000000000000..801fa66ae615 --- /dev/null +++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,ethdr.yaml @@ -0,0 +1,182 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/display/mediatek/mediatek,ethdr.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: MediaTek Ethdr Device + +maintainers: + - Chun-Kuang Hu <chunkuang.hu@kernel.org> + - Philipp Zabel <p.zabel@pengutronix.de> + +description: + ETHDR (ET High Dynamic Range) is a MediaTek internal HDR engine and is + designed for HDR video and graphics conversion in the external display path. + It handles multiple HDR input types and performs tone mapping, color + space/color format conversion, and then combine different layers, + output the required HDR or SDR signal to the subsequent display path. + This engine is composed of two video frontends, two graphic frontends, + one video backend and a mixer. ETHDR has two DMA function blocks, DS and ADL. + These two function blocks read the pre-programmed registers from DRAM and + set them to HW in the v-blanking period. + +properties: + compatible: + const: mediatek,mt8195-disp-ethdr + + reg: + maxItems: 7 + + reg-names: + items: + - const: mixer + - const: vdo_fe0 + - const: vdo_fe1 + - const: gfx_fe0 + - const: gfx_fe1 + - const: vdo_be + - const: adl_ds + + interrupts: + maxItems: 1 + + iommus: + minItems: 1 + maxItems: 2 + + clocks: + items: + - description: mixer clock + - description: video frontend 0 clock + - description: video frontend 1 clock + - description: graphic frontend 0 clock + - description: graphic frontend 1 clock + - description: video backend clock + - description: autodownload and menuload clock + - description: video frontend 0 async clock + - description: video frontend 1 async clock + - description: graphic frontend 0 async clock + - description: graphic frontend 1 async clock + - description: video backend async clock + - description: ethdr top clock + + clock-names: + items: + - const: mixer + - const: vdo_fe0 + - const: vdo_fe1 + - const: gfx_fe0 + - const: gfx_fe1 + - const: vdo_be + - const: adl_ds + - const: vdo_fe0_async + - const: vdo_fe1_async + - const: gfx_fe0_async + - const: gfx_fe1_async + - const: vdo_be_async + - const: ethdr_top + + power-domains: + maxItems: 1 + + resets: + items: + - description: video frontend 0 async reset + - description: video frontend 1 async reset + - description: graphic frontend 0 async reset + - description: graphic frontend 1 async reset + - description: video backend async reset + + reset-names: + items: + - const: vdo_fe0_async + - const: vdo_fe1_async + - const: gfx_fe0_async + - const: gfx_fe1_async + - const: vdo_be_async + + mediatek,gce-client-reg: + $ref: /schemas/types.yaml#/definitions/phandle-array + minItems: 1 + maxItems: 7 + description: The register of display function block to be set by gce. + There are 4 arguments in this property, gce node, subsys id, offset and + register size. The subsys id is defined in the gce header of each chips + include/dt-bindings/gce/<chip>-gce.h, mapping to the register of display + function block. + +required: + - compatible + - reg + - clocks + - clock-names + - interrupts + - power-domains + - resets + - mediatek,gce-client-reg + +additionalProperties: false + +examples: + - | + #include <dt-bindings/interrupt-controller/arm-gic.h> + #include <dt-bindings/clock/mt8195-clk.h> + #include <dt-bindings/gce/mt8195-gce.h> + #include <dt-bindings/memory/mt8195-memory-port.h> + #include <dt-bindings/power/mt8195-power.h> + #include <dt-bindings/reset/mt8195-resets.h> + + soc { + #address-cells = <2>; + #size-cells = <2>; + + hdr-engine@1c114000 { + compatible = "mediatek,mt8195-disp-ethdr"; + reg = <0 0x1c114000 0 0x1000>, + <0 0x1c115000 0 0x1000>, + <0 0x1c117000 0 0x1000>, + <0 0x1c119000 0 0x1000>, + <0 0x1c11a000 0 0x1000>, + <0 0x1c11b000 0 0x1000>, + <0 0x1c11c000 0 0x1000>; + reg-names = "mixer", "vdo_fe0", "vdo_fe1", "gfx_fe0", "gfx_fe1", + "vdo_be", "adl_ds"; + mediatek,gce-client-reg = <&gce0 SUBSYS_1c11XXXX 0x4000 0x1000>, + <&gce0 SUBSYS_1c11XXXX 0x5000 0x1000>, + <&gce0 SUBSYS_1c11XXXX 0x7000 0x1000>, + <&gce0 SUBSYS_1c11XXXX 0x9000 0x1000>, + <&gce0 SUBSYS_1c11XXXX 0xa000 0x1000>, + <&gce0 SUBSYS_1c11XXXX 0xb000 0x1000>, + <&gce0 SUBSYS_1c11XXXX 0xc000 0x1000>; + clocks = <&vdosys1 CLK_VDO1_DISP_MIXER>, + <&vdosys1 CLK_VDO1_HDR_VDO_FE0>, + <&vdosys1 CLK_VDO1_HDR_VDO_FE1>, + <&vdosys1 CLK_VDO1_HDR_GFX_FE0>, + <&vdosys1 CLK_VDO1_HDR_GFX_FE1>, + <&vdosys1 CLK_VDO1_HDR_VDO_BE>, + <&vdosys1 CLK_VDO1_26M_SLOW>, + <&vdosys1 CLK_VDO1_HDR_VDO_FE0_DL_ASYNC>, + <&vdosys1 CLK_VDO1_HDR_VDO_FE1_DL_ASYNC>, + <&vdosys1 CLK_VDO1_HDR_GFX_FE0_DL_ASYNC>, + <&vdosys1 CLK_VDO1_HDR_GFX_FE1_DL_ASYNC>, + <&vdosys1 CLK_VDO1_HDR_VDO_BE_DL_ASYNC>, + <&topckgen CLK_TOP_ETHDR>; + clock-names = "mixer", "vdo_fe0", "vdo_fe1", "gfx_fe0", "gfx_fe1", + "vdo_be", "adl_ds", "vdo_fe0_async", "vdo_fe1_async", + "gfx_fe0_async", "gfx_fe1_async","vdo_be_async", + "ethdr_top"; + power-domains = <&spm MT8195_POWER_DOMAIN_VDOSYS1>; + iommus = <&iommu_vpp M4U_PORT_L3_HDR_DS>, + <&iommu_vpp M4U_PORT_L3_HDR_ADL>; + interrupts = <GIC_SPI 517 IRQ_TYPE_LEVEL_HIGH 0>; /* disp mixer */ + resets = <&vdosys1 MT8195_VDOSYS1_SW1_RST_B_HDR_VDO_FE0_DL_ASYNC>, + <&vdosys1 MT8195_VDOSYS1_SW1_RST_B_HDR_VDO_FE1_DL_ASYNC>, + <&vdosys1 MT8195_VDOSYS1_SW1_RST_B_HDR_GFX_FE0_DL_ASYNC>, + <&vdosys1 MT8195_VDOSYS1_SW1_RST_B_HDR_GFX_FE1_DL_ASYNC>, + <&vdosys1 MT8195_VDOSYS1_SW1_RST_B_HDR_VDO_BE_DL_ASYNC>; + reset-names = "vdo_fe0_async", "vdo_fe1_async", "gfx_fe0_async", + "gfx_fe1_async", "vdo_be_async"; + }; + }; +... diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,hdmi.yaml b/Documentation/devicetree/bindings/display/mediatek/mediatek,hdmi.yaml index 8afdd67d6780..b90b6d18a828 100644 --- a/Documentation/devicetree/bindings/display/mediatek/mediatek,hdmi.yaml +++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,hdmi.yaml @@ -50,7 +50,7 @@ properties: - const: hdmi mediatek,syscon-hdmi: - $ref: '/schemas/types.yaml#/definitions/phandle-array' + $ref: /schemas/types.yaml#/definitions/phandle-array items: - items: - description: phandle to system configuration registers diff --git a/Documentation/devicetree/bindings/display/msm/dp-controller.yaml b/Documentation/devicetree/bindings/display/msm/dp-controller.yaml index 0e8d8df686dc..f0c2237d5f82 100644 --- a/Documentation/devicetree/bindings/display/msm/dp-controller.yaml +++ b/Documentation/devicetree/bindings/display/msm/dp-controller.yaml @@ -15,16 +15,21 @@ description: | properties: compatible: - enum: - - qcom,sc7180-dp - - qcom,sc7280-dp - - qcom,sc7280-edp - - qcom,sc8180x-dp - - qcom,sc8180x-edp - - qcom,sc8280xp-dp - - qcom,sc8280xp-edp - - qcom,sdm845-dp - - qcom,sm8350-dp + oneOf: + - enum: + - qcom,sc7180-dp + - qcom,sc7280-dp + - qcom,sc7280-edp + - qcom,sc8180x-dp + - qcom,sc8180x-edp + - qcom,sc8280xp-dp + - qcom,sc8280xp-edp + - qcom,sdm845-dp + - qcom,sm8350-dp + - items: + - enum: + - qcom,sm8450-dp + - const: qcom,sm8350-dp reg: minItems: 4 diff --git a/Documentation/devicetree/bindings/display/msm/dsi-controller-main.yaml b/Documentation/devicetree/bindings/display/msm/dsi-controller-main.yaml index e75a3efe4dac..e6c1ebfe8a32 100644 --- a/Documentation/devicetree/bindings/display/msm/dsi-controller-main.yaml +++ b/Documentation/devicetree/bindings/display/msm/dsi-controller-main.yaml @@ -25,16 +25,16 @@ properties: - qcom,sc7280-dsi-ctrl - qcom,sdm660-dsi-ctrl - qcom,sdm845-dsi-ctrl + - qcom,sm6115-dsi-ctrl - qcom,sm8150-dsi-ctrl - qcom,sm8250-dsi-ctrl - qcom,sm8350-dsi-ctrl - qcom,sm8450-dsi-ctrl - qcom,sm8550-dsi-ctrl - const: qcom,mdss-dsi-ctrl - - items: - - enum: - - dsi-ctrl-6g-qcm2290 - - const: qcom,mdss-dsi-ctrl + - enum: + - qcom,dsi-ctrl-6g-qcm2290 + - qcom,mdss-dsi-ctrl # This should always come with an SoC-specific compatible deprecated: true reg: @@ -74,7 +74,7 @@ properties: syscon-sfpb: description: A phandle to mmss_sfpb syscon node (only for DSIv2). - $ref: "/schemas/types.yaml#/definitions/phandle" + $ref: /schemas/types.yaml#/definitions/phandle qcom,dual-dsi-mode: type: boolean @@ -105,14 +105,14 @@ properties: type: object ports: - $ref: "/schemas/graph.yaml#/properties/ports" + $ref: /schemas/graph.yaml#/properties/ports description: | Contains DSI controller input and output ports as children, each containing one endpoint subnode. properties: port@0: - $ref: "/schemas/graph.yaml#/$defs/port-base" + $ref: /schemas/graph.yaml#/$defs/port-base unevaluatedProperties: false description: | Input endpoints of the controller. @@ -128,7 +128,7 @@ properties: enum: [ 0, 1, 2, 3 ] port@1: - $ref: "/schemas/graph.yaml#/$defs/port-base" + $ref: /schemas/graph.yaml#/$defs/port-base unevaluatedProperties: false description: | Output endpoints of the controller. @@ -351,6 +351,7 @@ allOf: contains: enum: - qcom,sdm845-dsi-ctrl + - qcom,sm6115-dsi-ctrl then: properties: clocks: diff --git a/Documentation/devicetree/bindings/display/msm/dsi-phy-10nm.yaml b/Documentation/devicetree/bindings/display/msm/dsi-phy-10nm.yaml index 3ec466c3ab38..e6b00d7387ce 100644 --- a/Documentation/devicetree/bindings/display/msm/dsi-phy-10nm.yaml +++ b/Documentation/devicetree/bindings/display/msm/dsi-phy-10nm.yaml @@ -58,7 +58,7 @@ properties: maximum: 31 qcom,phy-drive-ldo-level: - $ref: "/schemas/types.yaml#/definitions/uint32" + $ref: /schemas/types.yaml#/definitions/uint32 description: The PHY LDO has an amplitude tuning feature to adjust the LDO output for the HSTX drive. Use supported levels (mV) to offset the drive level diff --git a/Documentation/devicetree/bindings/display/msm/gmu.yaml b/Documentation/devicetree/bindings/display/msm/gmu.yaml index ab14e81cb050..029d72822d8b 100644 --- a/Documentation/devicetree/bindings/display/msm/gmu.yaml +++ b/Documentation/devicetree/bindings/display/msm/gmu.yaml @@ -3,8 +3,8 @@ %YAML 1.2 --- -$id: "http://devicetree.org/schemas/display/msm/gmu.yaml#" -$schema: "http://devicetree.org/meta-schemas/core.yaml#" +$id: http://devicetree.org/schemas/display/msm/gmu.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# title: GMU attached to certain Adreno GPUs diff --git a/Documentation/devicetree/bindings/display/msm/gpu.yaml b/Documentation/devicetree/bindings/display/msm/gpu.yaml index d4191cca71fb..5dabe7b6794b 100644 --- a/Documentation/devicetree/bindings/display/msm/gpu.yaml +++ b/Documentation/devicetree/bindings/display/msm/gpu.yaml @@ -2,8 +2,8 @@ %YAML 1.2 --- -$id: "http://devicetree.org/schemas/display/msm/gpu.yaml#" -$schema: "http://devicetree.org/meta-schemas/core.yaml#" +$id: http://devicetree.org/schemas/display/msm/gpu.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# title: Adreno or Snapdragon GPUs diff --git a/Documentation/devicetree/bindings/display/msm/mdp4.yaml b/Documentation/devicetree/bindings/display/msm/mdp4.yaml index 58c13f5277b6..35204a287579 100644 --- a/Documentation/devicetree/bindings/display/msm/mdp4.yaml +++ b/Documentation/devicetree/bindings/display/msm/mdp4.yaml @@ -1,8 +1,8 @@ # SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) %YAML 1.2 --- -$id: "http://devicetree.org/schemas/display/msm/mdp4.yaml#" -$schema: "http://devicetree.org/meta-schemas/core.yaml#" +$id: http://devicetree.org/schemas/display/msm/mdp4.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# title: Qualcomm Adreno/Snapdragon MDP4 display controller diff --git a/Documentation/devicetree/bindings/display/msm/qcom,sm6115-mdss.yaml b/Documentation/devicetree/bindings/display/msm/qcom,sm6115-mdss.yaml index 2491cb100b33..b9f83088f370 100644 --- a/Documentation/devicetree/bindings/display/msm/qcom,sm6115-mdss.yaml +++ b/Documentation/devicetree/bindings/display/msm/qcom,sm6115-mdss.yaml @@ -40,7 +40,13 @@ patternProperties: type: object properties: compatible: - const: qcom,dsi-ctrl-6g-qcm2290 + oneOf: + - items: + - const: qcom,sm6115-dsi-ctrl + - const: qcom,mdss-dsi-ctrl + - description: Old binding, please don't use + deprecated: true + const: qcom,dsi-ctrl-6g-qcm2290 "^phy@[0-9a-f]+$": type: object @@ -114,7 +120,7 @@ examples: }; dsi@5e94000 { - compatible = "qcom,dsi-ctrl-6g-qcm2290"; + compatible = "qcom,sm6115-dsi-ctrl", "qcom,mdss-dsi-ctrl"; reg = <0x05e94000 0x400>; reg-names = "dsi_ctrl"; diff --git a/Documentation/devicetree/bindings/display/msm/qcom,sm8450-mdss.yaml b/Documentation/devicetree/bindings/display/msm/qcom,sm8450-mdss.yaml index 4c6929e2534c..f26eb5643aed 100644 --- a/Documentation/devicetree/bindings/display/msm/qcom,sm8450-mdss.yaml +++ b/Documentation/devicetree/bindings/display/msm/qcom,sm8450-mdss.yaml @@ -54,7 +54,7 @@ patternProperties: type: object properties: compatible: - const: qcom,dsi-phy-5nm-8450 + const: qcom,sm8450-dsi-phy-5nm required: - compatible @@ -254,7 +254,7 @@ examples: }; dsi0_phy: phy@ae94400 { - compatible = "qcom,dsi-phy-5nm-8450"; + compatible = "qcom,sm8450-dsi-phy-5nm"; reg = <0x0ae94400 0x200>, <0x0ae94600 0x280>, <0x0ae94900 0x260>; @@ -325,7 +325,7 @@ examples: }; dsi1_phy: phy@ae96400 { - compatible = "qcom,dsi-phy-5nm-8450"; + compatible = "qcom,sm8450-dsi-phy-5nm"; reg = <0x0ae96400 0x200>, <0x0ae96600 0x280>, <0x0ae96900 0x260>; diff --git a/Documentation/devicetree/bindings/display/msm/qcom,sm8550-dpu.yaml b/Documentation/devicetree/bindings/display/msm/qcom,sm8550-dpu.yaml new file mode 100644 index 000000000000..ff58a747bb6f --- /dev/null +++ b/Documentation/devicetree/bindings/display/msm/qcom,sm8550-dpu.yaml @@ -0,0 +1,133 @@ +# SPDX-License-Identifier: GPL-2.0-only or BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/display/msm/qcom,sm8550-dpu.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Qualcomm SM8550 Display DPU + +maintainers: + - Neil Armstrong <neil.armstrong@linaro.org> + +$ref: /schemas/display/msm/dpu-common.yaml# + +properties: + compatible: + const: qcom,sm8550-dpu + + reg: + items: + - description: Address offset and size for mdp register set + - description: Address offset and size for vbif register set + + reg-names: + items: + - const: mdp + - const: vbif + + clocks: + items: + - description: Display AHB + - description: Display hf axi + - description: Display MDSS ahb + - description: Display lut + - description: Display core + - description: Display vsync + + clock-names: + items: + - const: bus + - const: nrt_bus + - const: iface + - const: lut + - const: core + - const: vsync + +required: + - compatible + - reg + - reg-names + - clocks + - clock-names + +unevaluatedProperties: false + +examples: + - | + #include <dt-bindings/clock/qcom,sm8550-dispcc.h> + #include <dt-bindings/clock/qcom,sm8550-gcc.h> + #include <dt-bindings/interrupt-controller/arm-gic.h> + #include <dt-bindings/power/qcom-rpmpd.h> + + display-controller@ae01000 { + compatible = "qcom,sm8550-dpu"; + reg = <0x0ae01000 0x8f000>, + <0x0aeb0000 0x2008>; + reg-names = "mdp", "vbif"; + + clocks = <&gcc GCC_DISP_AHB_CLK>, + <&gcc GCC_DISP_HF_AXI_CLK>, + <&dispcc DISP_CC_MDSS_AHB_CLK>, + <&dispcc DISP_CC_MDSS_MDP_LUT_CLK>, + <&dispcc DISP_CC_MDSS_MDP_CLK>, + <&dispcc DISP_CC_MDSS_VSYNC_CLK>; + clock-names = "bus", + "nrt_bus", + "iface", + "lut", + "core", + "vsync"; + + assigned-clocks = <&dispcc DISP_CC_MDSS_VSYNC_CLK>; + assigned-clock-rates = <19200000>; + + operating-points-v2 = <&mdp_opp_table>; + power-domains = <&rpmhpd SM8550_MMCX>; + + interrupt-parent = <&mdss>; + interrupts = <0>; + + ports { + #address-cells = <1>; + #size-cells = <0>; + + port@0 { + reg = <0>; + dpu_intf1_out: endpoint { + remote-endpoint = <&dsi0_in>; + }; + }; + + port@1 { + reg = <1>; + dpu_intf2_out: endpoint { + remote-endpoint = <&dsi1_in>; + }; + }; + }; + + mdp_opp_table: opp-table { + compatible = "operating-points-v2"; + + opp-200000000 { + opp-hz = /bits/ 64 <200000000>; + required-opps = <&rpmhpd_opp_low_svs>; + }; + + opp-325000000 { + opp-hz = /bits/ 64 <325000000>; + required-opps = <&rpmhpd_opp_svs>; + }; + + opp-375000000 { + opp-hz = /bits/ 64 <375000000>; + required-opps = <&rpmhpd_opp_svs_l1>; + }; + + opp-514000000 { + opp-hz = /bits/ 64 <514000000>; + required-opps = <&rpmhpd_opp_nom>; + }; + }; + }; +... diff --git a/Documentation/devicetree/bindings/display/msm/qcom,sm8550-mdss.yaml b/Documentation/devicetree/bindings/display/msm/qcom,sm8550-mdss.yaml new file mode 100644 index 000000000000..887be33ba108 --- /dev/null +++ b/Documentation/devicetree/bindings/display/msm/qcom,sm8550-mdss.yaml @@ -0,0 +1,333 @@ +# SPDX-License-Identifier: GPL-2.0-only or BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/display/msm/qcom,sm8550-mdss.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Qualcomm SM8550 Display MDSS + +maintainers: + - Neil Armstrong <neil.armstrong@linaro.org> + +description: + SM8550 MSM Mobile Display Subsystem(MDSS), which encapsulates sub-blocks like + DPU display controller, DSI and DP interfaces etc. + +$ref: /schemas/display/msm/mdss-common.yaml# + +properties: + compatible: + const: qcom,sm8550-mdss + + clocks: + items: + - description: Display MDSS AHB + - description: Display AHB + - description: Display hf AXI + - description: Display core + + iommus: + maxItems: 1 + + interconnects: + maxItems: 2 + + interconnect-names: + maxItems: 2 + +patternProperties: + "^display-controller@[0-9a-f]+$": + type: object + properties: + compatible: + const: qcom,sm8550-dpu + + "^dsi@[0-9a-f]+$": + type: object + properties: + compatible: + items: + - const: qcom,sm8550-dsi-ctrl + - const: qcom,mdss-dsi-ctrl + + "^phy@[0-9a-f]+$": + type: object + properties: + compatible: + const: qcom,sm8550-dsi-phy-4nm + +required: + - compatible + +unevaluatedProperties: false + +examples: + - | + #include <dt-bindings/clock/qcom,sm8550-dispcc.h> + #include <dt-bindings/clock/qcom,sm8550-gcc.h> + #include <dt-bindings/clock/qcom,rpmh.h> + #include <dt-bindings/interrupt-controller/arm-gic.h> + #include <dt-bindings/interconnect/qcom,sm8550-rpmh.h> + #include <dt-bindings/power/qcom-rpmpd.h> + + display-subsystem@ae00000 { + compatible = "qcom,sm8550-mdss"; + reg = <0x0ae00000 0x1000>; + reg-names = "mdss"; + + interconnects = <&mmss_noc MASTER_MDP 0 &gem_noc SLAVE_LLCC 0>, + <&mc_virt MASTER_LLCC 0 &mc_virt SLAVE_EBI1 0>; + interconnect-names = "mdp0-mem", "mdp1-mem"; + + resets = <&dispcc DISP_CC_MDSS_CORE_BCR>; + + power-domains = <&dispcc MDSS_GDSC>; + + clocks = <&dispcc DISP_CC_MDSS_AHB_CLK>, + <&gcc GCC_DISP_AHB_CLK>, + <&gcc GCC_DISP_HF_AXI_CLK>, + <&dispcc DISP_CC_MDSS_MDP_CLK>; + clock-names = "iface", "bus", "nrt_bus", "core"; + + interrupts = <GIC_SPI 83 IRQ_TYPE_LEVEL_HIGH>; + interrupt-controller; + #interrupt-cells = <1>; + + iommus = <&apps_smmu 0x1c00 0x2>; + + #address-cells = <1>; + #size-cells = <1>; + ranges; + + display-controller@ae01000 { + compatible = "qcom,sm8550-dpu"; + reg = <0x0ae01000 0x8f000>, + <0x0aeb0000 0x2008>; + reg-names = "mdp", "vbif"; + + clocks = <&gcc GCC_DISP_AHB_CLK>, + <&gcc GCC_DISP_HF_AXI_CLK>, + <&dispcc DISP_CC_MDSS_AHB_CLK>, + <&dispcc DISP_CC_MDSS_MDP_LUT_CLK>, + <&dispcc DISP_CC_MDSS_MDP_CLK>, + <&dispcc DISP_CC_MDSS_VSYNC_CLK>; + clock-names = "bus", + "nrt_bus", + "iface", + "lut", + "core", + "vsync"; + + assigned-clocks = <&dispcc DISP_CC_MDSS_VSYNC_CLK>; + assigned-clock-rates = <19200000>; + + operating-points-v2 = <&mdp_opp_table>; + power-domains = <&rpmhpd SM8550_MMCX>; + + interrupt-parent = <&mdss>; + interrupts = <0>; + + ports { + #address-cells = <1>; + #size-cells = <0>; + + port@0 { + reg = <0>; + dpu_intf1_out: endpoint { + remote-endpoint = <&dsi0_in>; + }; + }; + + port@1 { + reg = <1>; + dpu_intf2_out: endpoint { + remote-endpoint = <&dsi1_in>; + }; + }; + }; + + mdp_opp_table: opp-table { + compatible = "operating-points-v2"; + + opp-200000000 { + opp-hz = /bits/ 64 <200000000>; + required-opps = <&rpmhpd_opp_low_svs>; + }; + + opp-325000000 { + opp-hz = /bits/ 64 <325000000>; + required-opps = <&rpmhpd_opp_svs>; + }; + + opp-375000000 { + opp-hz = /bits/ 64 <375000000>; + required-opps = <&rpmhpd_opp_svs_l1>; + }; + + opp-514000000 { + opp-hz = /bits/ 64 <514000000>; + required-opps = <&rpmhpd_opp_nom>; + }; + }; + }; + + dsi@ae94000 { + compatible = "qcom,sm8550-dsi-ctrl", "qcom,mdss-dsi-ctrl"; + reg = <0x0ae94000 0x400>; + reg-names = "dsi_ctrl"; + + interrupt-parent = <&mdss>; + interrupts = <4>; + + clocks = <&dispcc DISP_CC_MDSS_BYTE0_CLK>, + <&dispcc DISP_CC_MDSS_BYTE0_INTF_CLK>, + <&dispcc DISP_CC_MDSS_PCLK0_CLK>, + <&dispcc DISP_CC_MDSS_ESC0_CLK>, + <&dispcc DISP_CC_MDSS_AHB_CLK>, + <&gcc GCC_DISP_HF_AXI_CLK>; + clock-names = "byte", + "byte_intf", + "pixel", + "core", + "iface", + "bus"; + + assigned-clocks = <&dispcc DISP_CC_MDSS_BYTE0_CLK_SRC>, + <&dispcc DISP_CC_MDSS_PCLK0_CLK_SRC>; + assigned-clock-parents = <&dsi0_phy 0>, <&dsi0_phy 1>; + + operating-points-v2 = <&dsi_opp_table>; + power-domains = <&rpmhpd SM8550_MMCX>; + + phys = <&dsi0_phy>; + phy-names = "dsi"; + + #address-cells = <1>; + #size-cells = <0>; + + ports { + #address-cells = <1>; + #size-cells = <0>; + + port@0 { + reg = <0>; + dsi0_in: endpoint { + remote-endpoint = <&dpu_intf1_out>; + }; + }; + + port@1 { + reg = <1>; + dsi0_out: endpoint { + }; + }; + }; + + dsi_opp_table: opp-table { + compatible = "operating-points-v2"; + + opp-187500000 { + opp-hz = /bits/ 64 <187500000>; + required-opps = <&rpmhpd_opp_low_svs>; + }; + + opp-300000000 { + opp-hz = /bits/ 64 <300000000>; + required-opps = <&rpmhpd_opp_svs>; + }; + + opp-358000000 { + opp-hz = /bits/ 64 <358000000>; + required-opps = <&rpmhpd_opp_svs_l1>; + }; + }; + }; + + dsi0_phy: phy@ae94400 { + compatible = "qcom,sm8550-dsi-phy-4nm"; + reg = <0x0ae95000 0x200>, + <0x0ae95200 0x280>, + <0x0ae95500 0x400>; + reg-names = "dsi_phy", + "dsi_phy_lane", + "dsi_pll"; + + #clock-cells = <1>; + #phy-cells = <0>; + + clocks = <&dispcc DISP_CC_MDSS_AHB_CLK>, + <&rpmhcc RPMH_CXO_CLK>; + clock-names = "iface", "ref"; + }; + + dsi@ae96000 { + compatible = "qcom,sm8550-dsi-ctrl", "qcom,mdss-dsi-ctrl"; + reg = <0x0ae96000 0x400>; + reg-names = "dsi_ctrl"; + + interrupt-parent = <&mdss>; + interrupts = <5>; + + clocks = <&dispcc DISP_CC_MDSS_BYTE1_CLK>, + <&dispcc DISP_CC_MDSS_BYTE1_INTF_CLK>, + <&dispcc DISP_CC_MDSS_PCLK1_CLK>, + <&dispcc DISP_CC_MDSS_ESC1_CLK>, + <&dispcc DISP_CC_MDSS_AHB_CLK>, + <&gcc GCC_DISP_HF_AXI_CLK>; + clock-names = "byte", + "byte_intf", + "pixel", + "core", + "iface", + "bus"; + + assigned-clocks = <&dispcc DISP_CC_MDSS_BYTE1_CLK_SRC>, + <&dispcc DISP_CC_MDSS_PCLK1_CLK_SRC>; + assigned-clock-parents = <&dsi1_phy 0>, <&dsi1_phy 1>; + + operating-points-v2 = <&dsi_opp_table>; + power-domains = <&rpmhpd SM8550_MMCX>; + + phys = <&dsi1_phy>; + phy-names = "dsi"; + + #address-cells = <1>; + #size-cells = <0>; + + ports { + #address-cells = <1>; + #size-cells = <0>; + + port@0 { + reg = <0>; + dsi1_in: endpoint { + remote-endpoint = <&dpu_intf2_out>; + }; + }; + + port@1 { + reg = <1>; + dsi1_out: endpoint { + }; + }; + }; + }; + + dsi1_phy: phy@ae96400 { + compatible = "qcom,sm8550-dsi-phy-4nm"; + reg = <0x0ae97000 0x200>, + <0x0ae97200 0x280>, + <0x0ae97500 0x400>; + reg-names = "dsi_phy", + "dsi_phy_lane", + "dsi_pll"; + + #clock-cells = <1>; + #phy-cells = <0>; + + clocks = <&dispcc DISP_CC_MDSS_AHB_CLK>, + <&rpmhcc RPMH_CXO_CLK>; + clock-names = "iface", "ref"; + }; + }; +... diff --git a/Documentation/devicetree/bindings/display/panel/boe,tv101wum-nl6.yaml b/Documentation/devicetree/bindings/display/panel/boe,tv101wum-nl6.yaml index a2384bd74cf2..aed55608ebf6 100644 --- a/Documentation/devicetree/bindings/display/panel/boe,tv101wum-nl6.yaml +++ b/Documentation/devicetree/bindings/display/panel/boe,tv101wum-nl6.yaml @@ -30,6 +30,8 @@ properties: - boe,tv110c9m-ll3 # INX HJ110IZ-01A 10.95" WUXGA TFT LCD panel - innolux,hj110iz-01a + # STARRY 2081101QFH032011-53G 10.1" WUXGA TFT LCD panel + - starry,2081101qfh032011-53g reg: description: the virtual channel number of a DSI peripheral @@ -53,6 +55,7 @@ properties: description: phandle of the backlight device attached to the panel port: true + rotation: true required: - compatible diff --git a/Documentation/devicetree/bindings/display/panel/elida,kd35t133.yaml b/Documentation/devicetree/bindings/display/panel/elida,kd35t133.yaml index 7adb83e2e8d9..265ab6d30572 100644 --- a/Documentation/devicetree/bindings/display/panel/elida,kd35t133.yaml +++ b/Documentation/devicetree/bindings/display/panel/elida,kd35t133.yaml @@ -17,7 +17,9 @@ properties: const: elida,kd35t133 reg: true backlight: true + port: true reset-gpios: true + rotation: true iovcc-supply: description: regulator that supplies the iovcc voltage vdd-supply: @@ -27,6 +29,7 @@ required: - compatible - reg - backlight + - port - iovcc-supply - vdd-supply @@ -43,6 +46,12 @@ examples: backlight = <&backlight>; iovcc-supply = <&vcc_1v8>; vdd-supply = <&vcc3v3_lcd>; + + port { + mipi_in_panel: endpoint { + remote-endpoint = <&mipi_out_panel>; + }; + }; }; }; diff --git a/Documentation/devicetree/bindings/display/panel/feiyang,fy07024di26a30d.yaml b/Documentation/devicetree/bindings/display/panel/feiyang,fy07024di26a30d.yaml index 1cf84c8dd85e..92df69e80a82 100644 --- a/Documentation/devicetree/bindings/display/panel/feiyang,fy07024di26a30d.yaml +++ b/Documentation/devicetree/bindings/display/panel/feiyang,fy07024di26a30d.yaml @@ -26,6 +26,7 @@ properties: dvdd-supply: description: 3v3 digital regulator + port: true reset-gpios: true backlight: true @@ -35,6 +36,7 @@ required: - reg - avdd-supply - dvdd-supply + - port additionalProperties: false @@ -53,5 +55,11 @@ examples: dvdd-supply = <®_dldo2>; reset-gpios = <&pio 3 24 GPIO_ACTIVE_HIGH>; /* LCD-RST: PD24 */ backlight = <&backlight>; + + port { + mipi_in_panel: endpoint { + remote-endpoint = <&mipi_out_panel>; + }; + }; }; }; diff --git a/Documentation/devicetree/bindings/display/panel/innolux,p120zdg-bf1.yaml b/Documentation/devicetree/bindings/display/panel/innolux,p120zdg-bf1.yaml deleted file mode 100644 index 243dac2416f3..000000000000 --- a/Documentation/devicetree/bindings/display/panel/innolux,p120zdg-bf1.yaml +++ /dev/null @@ -1,43 +0,0 @@ -# SPDX-License-Identifier: GPL-2.0 -%YAML 1.2 ---- -$id: http://devicetree.org/schemas/display/panel/innolux,p120zdg-bf1.yaml# -$schema: http://devicetree.org/meta-schemas/core.yaml# - -title: Innolux P120ZDG-BF1 12.02 inch eDP 2K display panel - -maintainers: - - Sandeep Panda <spanda@codeaurora.org> - - Douglas Anderson <dianders@chromium.org> - -allOf: - - $ref: panel-common.yaml# - -properties: - compatible: - const: innolux,p120zdg-bf1 - - enable-gpios: true - power-supply: true - backlight: true - no-hpd: true - -required: - - compatible - - power-supply - -additionalProperties: false - -examples: - - | - #include <dt-bindings/gpio/gpio.h> - - panel_edp: panel-edp { - compatible = "innolux,p120zdg-bf1"; - enable-gpios = <&msmgpio 31 GPIO_ACTIVE_LOW>; - power-supply = <&pm8916_l2>; - backlight = <&backlight>; - no-hpd; - }; - -... diff --git a/Documentation/devicetree/bindings/display/panel/jadard,jd9365da-h3.yaml b/Documentation/devicetree/bindings/display/panel/jadard,jd9365da-h3.yaml index c06902e4fe70..41eb7fbf7715 100644 --- a/Documentation/devicetree/bindings/display/panel/jadard,jd9365da-h3.yaml +++ b/Documentation/devicetree/bindings/display/panel/jadard,jd9365da-h3.yaml @@ -17,6 +17,8 @@ properties: items: - enum: - chongzhou,cz101b4001 + - radxa,display-10hd-ad001 + - radxa,display-8hd-ad002 - const: jadard,jd9365da-h3 reg: true diff --git a/Documentation/devicetree/bindings/display/panel/novatek,nt36523.yaml b/Documentation/devicetree/bindings/display/panel/novatek,nt36523.yaml new file mode 100644 index 000000000000..0039561ef04c --- /dev/null +++ b/Documentation/devicetree/bindings/display/panel/novatek,nt36523.yaml @@ -0,0 +1,85 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/display/panel/novatek,nt36523.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Novatek NT36523 based DSI display Panels + +maintainers: + - Jianhua Lu <lujianhua000@gmail.com> + +description: | + The Novatek NT36523 is a generic DSI Panel IC used to drive dsi + panels. Support video mode panels from China Star Optoelectronics + Technology (CSOT) and BOE Technology. + +allOf: + - $ref: panel-common.yaml# + +properties: + compatible: + items: + - enum: + - xiaomi,elish-boe-nt36523 + - xiaomi,elish-csot-nt36523 + - const: novatek,nt36523 + + reset-gpios: + maxItems: 1 + description: phandle of gpio for reset line - This should be 8mA + + vddio-supply: + description: regulator that supplies the I/O voltage + + reg: true + ports: true + backlight: true + +required: + - compatible + - reg + - vddio-supply + - reset-gpios + - ports + +unevaluatedProperties: false + +examples: + - | + #include <dt-bindings/gpio/gpio.h> + + dsi { + #address-cells = <1>; + #size-cells = <0>; + + panel@0 { + compatible = "xiaomi,elish-csot-nt36523", "novatek,nt36523"; + reg = <0>; + + vddio-supply = <&vreg_l14a_1p88>; + reset-gpios = <&tlmm 75 GPIO_ACTIVE_LOW>; + backlight = <&backlight>; + + ports { + #address-cells = <1>; + #size-cells = <0>; + + port@0 { + reg = <0>; + panel_in_0: endpoint { + remote-endpoint = <&dsi0_out>; + }; + }; + + port@1{ + reg = <1>; + panel_in_1: endpoint { + remote-endpoint = <&dsi1_out>; + }; + }; + }; + }; + }; + +... diff --git a/Documentation/devicetree/bindings/display/panel/novatek,nt36672a.yaml b/Documentation/devicetree/bindings/display/panel/novatek,nt36672a.yaml index 41ee3157a1cd..ae821f465e1c 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) - vddi0-supply: + vddio-supply: description: phandle of the regulator that provides the supply voltage Power IC supply @@ -51,7 +51,7 @@ properties: required: - compatible - reg - - vddi0-supply + - vddio-supply - vddpos-supply - vddneg-supply - reset-gpios @@ -70,7 +70,7 @@ examples: panel@0 { compatible = "tianma,fhd-video", "novatek,nt36672a"; reg = <0>; - vddi0-supply = <&vreg_l14a_1p88>; + vddio-supply = <&vreg_l14a_1p88>; vddpos-supply = <&lab>; vddneg-supply = <&ibb>; diff --git a/Documentation/devicetree/bindings/display/panel/panel-simple-dsi.yaml b/Documentation/devicetree/bindings/display/panel/panel-simple-dsi.yaml index 2c00813f5d20..90c04cff8281 100644 --- a/Documentation/devicetree/bindings/display/panel/panel-simple-dsi.yaml +++ b/Documentation/devicetree/bindings/display/panel/panel-simple-dsi.yaml @@ -19,9 +19,6 @@ description: | If the panel is more advanced a dedicated binding file is required. -allOf: - - $ref: panel-common.yaml# - properties: compatible: @@ -67,12 +64,31 @@ properties: reset-gpios: true port: true power-supply: true + vddio-supply: true + +allOf: + - $ref: panel-common.yaml# + - if: + properties: + compatible: + enum: + - samsung,s6e3fc2x01 + - samsung,sofef00 + then: + properties: + power-supply: false + required: + - vddio-supply + else: + properties: + vddio-supply: false + required: + - power-supply additionalProperties: false required: - compatible - - power-supply - reg examples: diff --git a/Documentation/devicetree/bindings/display/panel/panel-simple.yaml b/Documentation/devicetree/bindings/display/panel/panel-simple.yaml index 18241f4051d2..01560fe226dd 100644 --- a/Documentation/devicetree/bindings/display/panel/panel-simple.yaml +++ b/Documentation/devicetree/bindings/display/panel/panel-simple.yaml @@ -192,6 +192,8 @@ properties: - innolux,n125hce-gn1 # InnoLux 15.6" WXGA TFT LCD panel - innolux,n156bge-l21 + # Innolux P120ZDG-BF1 12.02 inch eDP 2K display panel + - innolux,p120zdg-bf1 # Innolux Corporation 7.0" WSVGA (1024x600) TFT LCD panel - innolux,zj070na-01p # King & Display KD116N21-30NV-A010 eDP TFT LCD panel diff --git a/Documentation/devicetree/bindings/display/panel/panel-timing.yaml b/Documentation/devicetree/bindings/display/panel/panel-timing.yaml index 0d317e61edd8..aea69b84ca5d 100644 --- a/Documentation/devicetree/bindings/display/panel/panel-timing.yaml +++ b/Documentation/devicetree/bindings/display/panel/panel-timing.yaml @@ -17,29 +17,29 @@ description: | The parameters are defined as seen in the following illustration. - +----------+-------------------------------------+----------+-------+ - | | ^ | | | - | | |vback_porch | | | - | | v | | | - +----------#######################################----------+-------+ - | # ^ # | | - | # | # | | - | hback # | # hfront | hsync | - | porch # | hactive # porch | len | - |<-------->#<-------+--------------------------->#<-------->|<----->| - | # | # | | - | # |vactive # | | - | # | # | | - | # v # | | - +----------#######################################----------+-------+ - | | ^ | | | - | | |vfront_porch | | | - | | v | | | - +----------+-------------------------------------+----------+-------+ - | | ^ | | | - | | |vsync_len | | | - | | v | | | - +----------+-------------------------------------+----------+-------+ + +-------+----------+-------------------------------------+----------+ + | | | ^ | | + | | | |vsync_len | | + | | | v | | + +-------+----------+-------------------------------------+----------+ + | | | ^ | | + | | | |vback_porch | | + | | | v | | + +-------+----------#######################################----------+ + | | # ^ # | + | | # | # | + | hsync | hback # | # hfront | + | len | porch # | hactive # porch | + |<----->|<-------->#<-------+--------------------------->#<-------->| + | | # | # | + | | # |vactive # | + | | # | # | + | | # v # | + +-------+----------#######################################----------+ + | | | ^ | | + | | | |vfront_porch | | + | | | v | | + +-------+----------+-------------------------------------+----------+ The following is the panel timings shown with time on the x-axis. diff --git a/Documentation/devicetree/bindings/display/panel/ronbo,rb070d30.yaml b/Documentation/devicetree/bindings/display/panel/ronbo,rb070d30.yaml index d67617f6f74a..95ce22c6787a 100644 --- a/Documentation/devicetree/bindings/display/panel/ronbo,rb070d30.yaml +++ b/Documentation/devicetree/bindings/display/panel/ronbo,rb070d30.yaml @@ -37,7 +37,7 @@ properties: backlight: description: Backlight used by the panel - $ref: "/schemas/types.yaml#/definitions/phandle" + $ref: /schemas/types.yaml#/definitions/phandle required: - compatible diff --git a/Documentation/devicetree/bindings/display/panel/samsung,ams495qa01.yaml b/Documentation/devicetree/bindings/display/panel/samsung,ams495qa01.yaml new file mode 100644 index 000000000000..58fa073ce258 --- /dev/null +++ b/Documentation/devicetree/bindings/display/panel/samsung,ams495qa01.yaml @@ -0,0 +1,57 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/display/panel/samsung,ams495qa01.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Samsung AMS495QA01 panel with Magnachip D53E6EA8966 controller + +maintainers: + - Chris Morgan <macromorgan@hotmail.com> + +allOf: + - $ref: panel-common.yaml# + +properties: + compatible: + const: samsung,ams495qa01 + + reg: true + reset-gpios: + description: reset gpio, must be GPIO_ACTIVE_LOW + elvdd-supply: + description: regulator that supplies voltage to the panel display + enable-gpios: true + port: true + vdd-supply: + description: regulator that supplies voltage to panel logic + +required: + - compatible + - reg + - reset-gpios + - vdd-supply + +additionalProperties: false + +examples: + - | + #include <dt-bindings/gpio/gpio.h> + spi { + #address-cells = <1>; + #size-cells = <0>; + panel@0 { + compatible = "samsung,ams495qa01"; + reg = <0>; + reset-gpios = <&gpio4 0 GPIO_ACTIVE_LOW>; + vdd-supply = <&vcc_3v3>; + + port { + mipi_in_panel: endpoint { + remote-endpoint = <&mipi_out_panel>; + }; + }; + }; + }; + +... diff --git a/Documentation/devicetree/bindings/display/panel/samsung,s6e88a0-ams452ef01.yaml b/Documentation/devicetree/bindings/display/panel/samsung,s6e88a0-ams452ef01.yaml index 44ce98f68705..b749e9e906b7 100644 --- a/Documentation/devicetree/bindings/display/panel/samsung,s6e88a0-ams452ef01.yaml +++ b/Documentation/devicetree/bindings/display/panel/samsung,s6e88a0-ams452ef01.yaml @@ -16,6 +16,7 @@ properties: compatible: const: samsung,s6e88a0-ams452ef01 reg: true + port: true reset-gpios: true vdd3-supply: description: core voltage supply @@ -25,6 +26,7 @@ properties: required: - compatible - reg + - port - vdd3-supply - vci-supply - reset-gpios @@ -46,5 +48,11 @@ examples: vdd3-supply = <&pm8916_l17>; vci-supply = <®_vlcd_vci>; reset-gpios = <&msmgpio 25 GPIO_ACTIVE_HIGH>; + + port { + panel_in: endpoint { + remote-endpoint = <&dsi0_out>; + }; + }; }; }; diff --git a/Documentation/devicetree/bindings/display/panel/seiko,43wvf1g.yaml b/Documentation/devicetree/bindings/display/panel/seiko,43wvf1g.yaml index cfaa50cf5f5d..1df3cbb51ff9 100644 --- a/Documentation/devicetree/bindings/display/panel/seiko,43wvf1g.yaml +++ b/Documentation/devicetree/bindings/display/panel/seiko,43wvf1g.yaml @@ -7,7 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml# title: Seiko Instruments Inc. 4.3" WVGA (800 x RGB x 480) TFT with Touch-Panel maintainers: - - Marco Franchi <marco.franchi@nxp.com> + - Fabio Estevam <festevam@gmail.com> allOf: - $ref: panel-common.yaml# @@ -25,6 +25,8 @@ properties: avdd-supply: description: 5v analog regulator + enable-gpios: true + required: - compatible - dvdd-supply diff --git a/Documentation/devicetree/bindings/display/panel/sitronix,st7701.yaml b/Documentation/devicetree/bindings/display/panel/sitronix,st7701.yaml index 34d5e20c6cb3..4dc0cd4a6a77 100644 --- a/Documentation/devicetree/bindings/display/panel/sitronix,st7701.yaml +++ b/Documentation/devicetree/bindings/display/panel/sitronix,st7701.yaml @@ -28,6 +28,7 @@ properties: items: - enum: - densitron,dmt028vghmcmi-1a + - elida,kd50t048a - techstar,ts8550b - const: sitronix,st7701 @@ -41,7 +42,9 @@ properties: IOVCC-supply: description: I/O system regulator + port: true reset-gpios: true + rotation: true backlight: true @@ -50,6 +53,7 @@ required: - reg - VCC-supply - IOVCC-supply + - port - reset-gpios additionalProperties: false @@ -69,5 +73,11 @@ examples: IOVCC-supply = <®_dldo2>; reset-gpios = <&pio 3 24 GPIO_ACTIVE_HIGH>; /* LCD-RST: PD24 */ backlight = <&backlight>; + + port { + mipi_in_panel: endpoint { + remote-endpoint = <&mipi_out_panel>; + }; + }; }; }; diff --git a/Documentation/devicetree/bindings/display/panel/sitronix,st7789v.yaml b/Documentation/devicetree/bindings/display/panel/sitronix,st7789v.yaml index d984b59daa4a..fa6556363cca 100644 --- a/Documentation/devicetree/bindings/display/panel/sitronix,st7789v.yaml +++ b/Documentation/devicetree/bindings/display/panel/sitronix,st7789v.yaml @@ -26,6 +26,10 @@ properties: spi-cpha: true spi-cpol: true + dc-gpios: + maxItems: 1 + description: DCX pin, Display data/command selection pin in parallel interface + required: - compatible - reg diff --git a/Documentation/devicetree/bindings/display/panel/sony,td4353-jdi.yaml b/Documentation/devicetree/bindings/display/panel/sony,td4353-jdi.yaml new file mode 100644 index 000000000000..b6b885b4c22d --- /dev/null +++ b/Documentation/devicetree/bindings/display/panel/sony,td4353-jdi.yaml @@ -0,0 +1,82 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/display/panel/sony,td4353-jdi.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Sony TD4353 JDI 5 / 5.7" 2160x1080 MIPI-DSI Panel + +maintainers: + - Konrad Dybcio <konrad.dybcio@somainline.org> + +description: | + The Sony TD4353 JDI is a 5 (XZ2c) / 5.7 (XZ2) inch 2160x1080 + MIPI-DSI panel, used in Xperia XZ2 and XZ2 Compact smartphones. + +allOf: + - $ref: panel-common.yaml# + +properties: + compatible: + const: sony,td4353-jdi-tama + + reg: true + + backlight: true + + vddio-supply: + description: VDDIO 1.8V supply + + vsp-supply: + description: Positive 5.5V supply + + vsn-supply: + description: Negative 5.5V supply + + panel-reset-gpios: + description: Display panel reset pin + + touch-reset-gpios: + description: Touch panel reset pin + + port: true + +required: + - compatible + - reg + - vddio-supply + - vsp-supply + - vsn-supply + - panel-reset-gpios + - touch-reset-gpios + - port + +additionalProperties: false + +examples: + - | + #include <dt-bindings/gpio/gpio.h> + + dsi { + #address-cells = <1>; + #size-cells = <0>; + + panel: panel@0 { + compatible = "sony,td4353-jdi-tama"; + reg = <0>; + + backlight = <&pmi8998_wled>; + vddio-supply = <&vreg_l14a_1p8>; + vsp-supply = <&lab>; + vsn-supply = <&ibb>; + panel-reset-gpios = <&tlmm 6 GPIO_ACTIVE_HIGH>; + touch-reset-gpios = <&tlmm 99 GPIO_ACTIVE_HIGH>; + + port { + panel_in: endpoint { + remote-endpoint = <&dsi0_out>; + }; + }; + }; + }; +... diff --git a/Documentation/devicetree/bindings/display/panel/visionox,rm69299.yaml b/Documentation/devicetree/bindings/display/panel/visionox,rm69299.yaml index 481ef051df1e..444ac2a4772d 100644 --- a/Documentation/devicetree/bindings/display/panel/visionox,rm69299.yaml +++ b/Documentation/devicetree/bindings/display/panel/visionox,rm69299.yaml @@ -19,6 +19,8 @@ properties: compatible: const: visionox,rm69299-1080p-display + reg: true + vdda-supply: description: | Phandle of the regulator that provides the vdda supply voltage. @@ -34,6 +36,7 @@ additionalProperties: false required: - compatible + - reg - vdda-supply - vdd3p3-supply - reset-gpios @@ -41,16 +44,22 @@ required: examples: - | - panel { - compatible = "visionox,rm69299-1080p-display"; + dsi { + #address-cells = <1>; + #size-cells = <0>; + + panel@0 { + compatible = "visionox,rm69299-1080p-display"; + reg = <0>; - vdda-supply = <&src_pp1800_l8c>; - vdd3p3-supply = <&src_pp2800_l18a>; + vdda-supply = <&src_pp1800_l8c>; + vdd3p3-supply = <&src_pp2800_l18a>; - reset-gpios = <&pm6150l_gpio 3 0>; - port { - panel0_in: endpoint { - remote-endpoint = <&dsi0_out>; + reset-gpios = <&pm6150l_gpio 3 0>; + port { + panel0_in: endpoint { + remote-endpoint = <&dsi0_out>; + }; }; }; }; diff --git a/Documentation/devicetree/bindings/display/panel/xinpeng,xpp055c272.yaml b/Documentation/devicetree/bindings/display/panel/xinpeng,xpp055c272.yaml index d5c46a3cc2b0..c407deb6afb1 100644 --- a/Documentation/devicetree/bindings/display/panel/xinpeng,xpp055c272.yaml +++ b/Documentation/devicetree/bindings/display/panel/xinpeng,xpp055c272.yaml @@ -17,6 +17,7 @@ properties: const: xinpeng,xpp055c272 reg: true backlight: true + port: true reset-gpios: true iovcc-supply: description: regulator that supplies the iovcc voltage @@ -27,6 +28,7 @@ required: - compatible - reg - backlight + - port - iovcc-supply - vci-supply @@ -44,6 +46,12 @@ examples: backlight = <&backlight>; iovcc-supply = <&vcc_1v8>; vci-supply = <&vcc3v3_lcd>; + + port { + mipi_in_panel: endpoint { + remote-endpoint = <&mipi_out_panel>; + }; + }; }; }; diff --git a/Documentation/devicetree/bindings/display/renesas,du.yaml b/Documentation/devicetree/bindings/display/renesas,du.yaml index d4830f52c512..c5b9e6812bce 100644 --- a/Documentation/devicetree/bindings/display/renesas,du.yaml +++ b/Documentation/devicetree/bindings/display/renesas,du.yaml @@ -76,7 +76,7 @@ properties: unevaluatedProperties: false renesas,cmms: - $ref: "/schemas/types.yaml#/definitions/phandle-array" + $ref: /schemas/types.yaml#/definitions/phandle-array items: maxItems: 1 description: @@ -84,7 +84,7 @@ properties: available DU channel. renesas,vsps: - $ref: "/schemas/types.yaml#/definitions/phandle-array" + $ref: /schemas/types.yaml#/definitions/phandle-array items: items: - description: phandle to VSP instance that serves the DU channel diff --git a/Documentation/devicetree/bindings/display/rockchip/analogix_dp-rockchip.txt b/Documentation/devicetree/bindings/display/rockchip/analogix_dp-rockchip.txt deleted file mode 100644 index 43561584c13a..000000000000 --- a/Documentation/devicetree/bindings/display/rockchip/analogix_dp-rockchip.txt +++ /dev/null @@ -1,98 +0,0 @@ -Rockchip RK3288 specific extensions to the Analogix Display Port -================================ - -Required properties: -- compatible: "rockchip,rk3288-dp", - "rockchip,rk3399-edp"; - -- reg: physical base address of the controller and length - -- clocks: from common clock binding: handle to dp clock. - of memory mapped region. - -- clock-names: from common clock binding: - Required elements: "dp" "pclk" - -- resets: Must contain an entry for each entry in reset-names. - See ../reset/reset.txt for details. - -- pinctrl-names: Names corresponding to the chip hotplug pinctrl states. -- pinctrl-0: pin-control mode. should be <&edp_hpd> - -- reset-names: Must include the name "dp" - -- rockchip,grf: this soc should set GRF regs, so need get grf here. - -- ports: there are 2 port nodes with endpoint definitions as defined in - Documentation/devicetree/bindings/media/video-interfaces.txt. - Port 0: contained 2 endpoints, connecting to the output of vop. - Port 1: contained 1 endpoint, connecting to the input of panel. - -Optional property for different chips: -- clocks: from common clock binding: handle to grf_vio clock. - -- clock-names: from common clock binding: - Required elements: "grf" - -For the below properties, please refer to Analogix DP binding document: - * Documentation/devicetree/bindings/display/bridge/analogix_dp.txt -- phys (required) -- phy-names (required) -- hpd-gpios (optional) -- force-hpd (optional) -------------------------------------------------------------------------------- - -Example: - dp-controller: dp@ff970000 { - compatible = "rockchip,rk3288-dp"; - reg = <0xff970000 0x4000>; - interrupts = <GIC_SPI 98 IRQ_TYPE_LEVEL_HIGH>; - clocks = <&cru SCLK_EDP>, <&cru PCLK_EDP_CTRL>; - clock-names = "dp", "pclk"; - phys = <&dp_phy>; - phy-names = "dp"; - - rockchip,grf = <&grf>; - resets = <&cru 111>; - reset-names = "dp"; - - pinctrl-names = "default"; - pinctrl-0 = <&edp_hpd>; - - - ports { - #address-cells = <1>; - #size-cells = <0>; - edp_in: port@0 { - reg = <0>; - #address-cells = <1>; - #size-cells = <0>; - edp_in_vopb: endpoint@0 { - reg = <0>; - remote-endpoint = <&vopb_out_edp>; - }; - edp_in_vopl: endpoint@1 { - reg = <1>; - remote-endpoint = <&vopl_out_edp>; - }; - }; - - edp_out: port@1 { - reg = <1>; - #address-cells = <1>; - #size-cells = <0>; - edp_out_panel: endpoint { - reg = <0>; - remote-endpoint = <&panel_in_edp> - }; - }; - }; - }; - - pinctrl { - edp { - edp_hpd: edp-hpd { - rockchip,pins = <7 11 RK_FUNC_2 &pcfg_pull_none>; - }; - }; - }; diff --git a/Documentation/devicetree/bindings/display/rockchip/dw_mipi_dsi_rockchip.txt b/Documentation/devicetree/bindings/display/rockchip/dw_mipi_dsi_rockchip.txt deleted file mode 100644 index 9a223df8530c..000000000000 --- a/Documentation/devicetree/bindings/display/rockchip/dw_mipi_dsi_rockchip.txt +++ /dev/null @@ -1,94 +0,0 @@ -Rockchip specific extensions to the Synopsys Designware MIPI DSI -================================ - -Required properties: -- #address-cells: Should be <1>. -- #size-cells: Should be <0>. -- compatible: one of - "rockchip,px30-mipi-dsi", "snps,dw-mipi-dsi" - "rockchip,rk3288-mipi-dsi", "snps,dw-mipi-dsi" - "rockchip,rk3399-mipi-dsi", "snps,dw-mipi-dsi" - "rockchip,rk3568-mipi-dsi", "snps,dw-mipi-dsi" -- reg: Represent the physical address range of the controller. -- interrupts: Represent the controller's interrupt to the CPU(s). -- clocks, clock-names: Phandles to the controller's pll reference - clock(ref) when using an internal dphy and APB clock(pclk). - For RK3399, a phy config clock (phy_cfg) and a grf clock(grf) - are required. As described in [1]. -- rockchip,grf: this soc should set GRF regs to mux vopl/vopb. -- ports: contain a port node with endpoint definitions as defined in [2]. - For vopb,set the reg = <0> and set the reg = <1> for vopl. -- video port 0 for the VOP input, the remote endpoint maybe vopb or vopl -- video port 1 for either a panel or subsequent encoder - -Optional properties: -- phys: from general PHY binding: the phandle for the PHY device. -- phy-names: Should be "dphy" if phys references an external phy. -- #phy-cells: Defined when used as ISP phy, should be 0. -- power-domains: a phandle to mipi dsi power domain node. -- resets: list of phandle + reset specifier pairs, as described in [3]. -- reset-names: string reset name, must be "apb". - -[1] Documentation/devicetree/bindings/clock/clock-bindings.txt -[2] Documentation/devicetree/bindings/media/video-interfaces.txt -[3] Documentation/devicetree/bindings/reset/reset.txt - -Example: - mipi_dsi: mipi@ff960000 { - #address-cells = <1>; - #size-cells = <0>; - compatible = "rockchip,rk3288-mipi-dsi", "snps,dw-mipi-dsi"; - reg = <0xff960000 0x4000>; - interrupts = <GIC_SPI 83 IRQ_TYPE_LEVEL_HIGH>; - clocks = <&cru SCLK_MIPI_24M>, <&cru PCLK_MIPI_DSI0>; - clock-names = "ref", "pclk"; - resets = <&cru SRST_MIPIDSI0>; - reset-names = "apb"; - rockchip,grf = <&grf>; - - ports { - #address-cells = <1>; - #size-cells = <0>; - - mipi_in: port@0 { - reg = <0>; - #address-cells = <1>; - #size-cells = <0>; - - mipi_in_vopb: endpoint@0 { - reg = <0>; - remote-endpoint = <&vopb_out_mipi>; - }; - mipi_in_vopl: endpoint@1 { - reg = <1>; - remote-endpoint = <&vopl_out_mipi>; - }; - }; - - mipi_out: port@1 { - reg = <1>; - #address-cells = <1>; - #size-cells = <0>; - - mipi_out_panel: endpoint { - remote-endpoint = <&panel_in_mipi>; - }; - }; - }; - - panel { - compatible ="boe,tv080wum-nl0"; - reg = <0>; - - enable-gpios = <&gpio7 3 GPIO_ACTIVE_HIGH>; - pinctrl-names = "default"; - pinctrl-0 = <&lcd_en>; - backlight = <&backlight>; - - port { - panel_in_mipi: endpoint { - remote-endpoint = <&mipi_out_panel>; - }; - }; - }; - }; diff --git a/Documentation/devicetree/bindings/display/rockchip/rockchip,analogix-dp.yaml b/Documentation/devicetree/bindings/display/rockchip/rockchip,analogix-dp.yaml new file mode 100644 index 000000000000..60dedf9b2be7 --- /dev/null +++ b/Documentation/devicetree/bindings/display/rockchip/rockchip,analogix-dp.yaml @@ -0,0 +1,103 @@ +# SPDX-License-Identifier: GPL-2.0 +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/display/rockchip/rockchip,analogix-dp.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Rockchip specific extensions to the Analogix Display Port + +maintainers: + - Sandy Huang <hjc@rock-chips.com> + - Heiko Stuebner <heiko@sntech.de> + +properties: + compatible: + enum: + - rockchip,rk3288-dp + - rockchip,rk3399-edp + + clocks: + minItems: 2 + maxItems: 3 + + clock-names: + minItems: 2 + items: + - const: dp + - const: pclk + - const: grf + + power-domains: + maxItems: 1 + + resets: + maxItems: 1 + + reset-names: + const: dp + + rockchip,grf: + $ref: /schemas/types.yaml#/definitions/phandle + description: + This SoC makes use of GRF regs. + +required: + - compatible + - clocks + - clock-names + - resets + - reset-names + - rockchip,grf + +allOf: + - $ref: /schemas/display/bridge/analogix,dp.yaml# + +unevaluatedProperties: false + +examples: + - | + #include <dt-bindings/clock/rk3288-cru.h> + #include <dt-bindings/interrupt-controller/arm-gic.h> + #include <dt-bindings/interrupt-controller/irq.h> + dp@ff970000 { + compatible = "rockchip,rk3288-dp"; + reg = <0xff970000 0x4000>; + interrupts = <GIC_SPI 98 IRQ_TYPE_LEVEL_HIGH>; + clocks = <&cru SCLK_EDP>, <&cru PCLK_EDP_CTRL>; + clock-names = "dp", "pclk"; + phys = <&dp_phy>; + phy-names = "dp"; + resets = <&cru 111>; + reset-names = "dp"; + rockchip,grf = <&grf>; + pinctrl-0 = <&edp_hpd>; + pinctrl-names = "default"; + + ports { + #address-cells = <1>; + #size-cells = <0>; + + edp_in: port@0 { + reg = <0>; + #address-cells = <1>; + #size-cells = <0>; + + edp_in_vopb: endpoint@0 { + reg = <0>; + remote-endpoint = <&vopb_out_edp>; + }; + edp_in_vopl: endpoint@1 { + reg = <1>; + remote-endpoint = <&vopl_out_edp>; + }; + }; + + edp_out: port@1 { + reg = <1>; + + edp_out_panel: endpoint { + remote-endpoint = <&panel_in_edp>; + }; + }; + }; + }; diff --git a/Documentation/devicetree/bindings/display/rockchip/rockchip,dw-mipi-dsi.yaml b/Documentation/devicetree/bindings/display/rockchip/rockchip,dw-mipi-dsi.yaml new file mode 100644 index 000000000000..8e8a40879140 --- /dev/null +++ b/Documentation/devicetree/bindings/display/rockchip/rockchip,dw-mipi-dsi.yaml @@ -0,0 +1,166 @@ +# SPDX-License-Identifier: GPL-2.0 +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/display/rockchip/rockchip,dw-mipi-dsi.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Rockchip specific extensions to the Synopsys Designware MIPI DSI + +maintainers: + - Sandy Huang <hjc@rock-chips.com> + - Heiko Stuebner <heiko@sntech.de> + +properties: + compatible: + items: + - enum: + - rockchip,px30-mipi-dsi + - rockchip,rk3288-mipi-dsi + - rockchip,rk3399-mipi-dsi + - rockchip,rk3568-mipi-dsi + - const: snps,dw-mipi-dsi + + interrupts: + maxItems: 1 + + clocks: + minItems: 1 + maxItems: 4 + + clock-names: + oneOf: + - minItems: 2 + items: + - const: ref + - const: pclk + - const: phy_cfg + - const: grf + - const: pclk + + rockchip,grf: + $ref: /schemas/types.yaml#/definitions/phandle + description: + This SoC uses GRF regs to switch between vopl/vopb. + + phys: + maxItems: 1 + + phy-names: + const: dphy + + "#phy-cells": + const: 0 + description: + Defined when in use as ISP phy. + + power-domains: + maxItems: 1 + + "#address-cells": + const: 1 + + "#size-cells": + const: 0 + +required: + - compatible + - clocks + - clock-names + - rockchip,grf + +allOf: + - $ref: /schemas/display/bridge/snps,dw-mipi-dsi.yaml# + - if: + properties: + compatible: + contains: + enum: + - rockchip,px30-mipi-dsi + - rockchip,rk3568-mipi-dsi + + then: + properties: + clocks: + maxItems: 1 + + clock-names: + maxItems: 1 + + required: + - phys + - phy-names + + - if: + properties: + compatible: + contains: + const: rockchip,rk3288-mipi-dsi + + then: + properties: + clocks: + maxItems: 2 + + clock-names: + maxItems: 2 + + - if: + properties: + compatible: + contains: + const: rockchip,rk3399-mipi-dsi + + then: + properties: + clocks: + minItems: 4 + + clock-names: + minItems: 4 + +unevaluatedProperties: false + +examples: + - | + #include <dt-bindings/clock/rk3288-cru.h> + #include <dt-bindings/interrupt-controller/arm-gic.h> + #include <dt-bindings/interrupt-controller/irq.h> + + mipi_dsi: dsi@ff960000 { + compatible = "rockchip,rk3288-mipi-dsi", "snps,dw-mipi-dsi"; + reg = <0xff960000 0x4000>; + interrupts = <GIC_SPI 83 IRQ_TYPE_LEVEL_HIGH>; + clocks = <&cru SCLK_MIPIDSI_24M>, <&cru PCLK_MIPI_DSI0>; + clock-names = "ref", "pclk"; + resets = <&cru SRST_MIPIDSI0>; + reset-names = "apb"; + rockchip,grf = <&grf>; + + ports { + #address-cells = <1>; + #size-cells = <0>; + + mipi_in: port@0 { + reg = <0>; + #address-cells = <1>; + #size-cells = <0>; + + mipi_in_vopb: endpoint@0 { + reg = <0>; + remote-endpoint = <&vopb_out_mipi>; + }; + mipi_in_vopl: endpoint@1 { + reg = <1>; + remote-endpoint = <&vopl_out_mipi>; + }; + }; + + mipi_out: port@1 { + reg = <1>; + + mipi_out_panel: endpoint { + remote-endpoint = <&panel_in_mipi>; + }; + }; + }; + }; diff --git a/Documentation/devicetree/bindings/display/rockchip/rockchip,lvds.yaml b/Documentation/devicetree/bindings/display/rockchip/rockchip,lvds.yaml new file mode 100644 index 000000000000..03b002a05c47 --- /dev/null +++ b/Documentation/devicetree/bindings/display/rockchip/rockchip,lvds.yaml @@ -0,0 +1,170 @@ +# SPDX-License-Identifier: GPL-2.0 +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/display/rockchip/rockchip,lvds.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Rockchip low-voltage differential signal (LVDS) transmitter + +maintainers: + - Sandy Huang <hjc@rock-chips.com> + - Heiko Stuebner <heiko@sntech.de> + +properties: + compatible: + enum: + - rockchip,px30-lvds + - rockchip,rk3288-lvds + + reg: + maxItems: 1 + + clocks: + maxItems: 1 + + clock-names: + const: pclk_lvds + + avdd1v0-supply: + description: 1.0V analog power. + + avdd1v8-supply: + description: 1.8V analog power. + + avdd3v3-supply: + description: 3.3V analog power. + + rockchip,grf: + $ref: /schemas/types.yaml#/definitions/phandle + description: Phandle to the general register files syscon. + + rockchip,output: + $ref: /schemas/types.yaml#/definitions/string + enum: [rgb, lvds, duallvds] + description: This describes the output interface. + + phys: + maxItems: 1 + + phy-names: + const: dphy + + pinctrl-names: + const: lcdc + + pinctrl-0: true + + power-domains: + maxItems: 1 + + ports: + $ref: /schemas/graph.yaml#/properties/ports + + properties: + port@0: + $ref: /schemas/graph.yaml#/properties/port + description: + Video port 0 for the VOP input. + The remote endpoint maybe vopb or vopl. + + port@1: + $ref: /schemas/graph.yaml#/properties/port + description: + Video port 1 for either a panel or subsequent encoder. + + required: + - port@0 + - port@1 + +required: + - compatible + - rockchip,grf + - rockchip,output + - ports + +allOf: + - if: + properties: + compatible: + contains: + const: rockchip,px30-lvds + + then: + properties: + reg: false + clocks: false + clock-names: false + avdd1v0-supply: false + avdd1v8-supply: false + avdd3v3-supply: false + + required: + - phys + - phy-names + + - if: + properties: + compatible: + contains: + const: rockchip,rk3288-lvds + + then: + properties: + phys: false + phy-names: false + + required: + - reg + - clocks + - clock-names + - avdd1v0-supply + - avdd1v8-supply + - avdd3v3-supply + +additionalProperties: false + +examples: + - | + #include <dt-bindings/clock/rk3288-cru.h> + + lvds: lvds@ff96c000 { + compatible = "rockchip,rk3288-lvds"; + reg = <0xff96c000 0x4000>; + clocks = <&cru PCLK_LVDS_PHY>; + clock-names = "pclk_lvds"; + avdd1v0-supply = <&vdd10_lcd>; + avdd1v8-supply = <&vcc18_lcd>; + avdd3v3-supply = <&vcca_33>; + pinctrl-names = "lcdc"; + pinctrl-0 = <&lcdc_ctl>; + rockchip,grf = <&grf>; + rockchip,output = "rgb"; + + ports { + #address-cells = <1>; + #size-cells = <0>; + + lvds_in: port@0 { + reg = <0>; + #address-cells = <1>; + #size-cells = <0>; + + lvds_in_vopb: endpoint@0 { + reg = <0>; + remote-endpoint = <&vopb_out_lvds>; + }; + lvds_in_vopl: endpoint@1 { + reg = <1>; + remote-endpoint = <&vopl_out_lvds>; + }; + }; + + lvds_out: port@1 { + reg = <1>; + + lvds_out_panel: endpoint { + remote-endpoint = <&panel_in_lvds>; + }; + }; + }; + }; diff --git a/Documentation/devicetree/bindings/display/rockchip/rockchip-lvds.txt b/Documentation/devicetree/bindings/display/rockchip/rockchip-lvds.txt deleted file mode 100644 index aaf8c44cf90f..000000000000 --- a/Documentation/devicetree/bindings/display/rockchip/rockchip-lvds.txt +++ /dev/null @@ -1,92 +0,0 @@ -Rockchip RK3288 LVDS interface -================================ - -Required properties: -- compatible: matching the soc type, one of - - "rockchip,rk3288-lvds"; - - "rockchip,px30-lvds"; - -- reg: physical base address of the controller and length - of memory mapped region. -- clocks: must include clock specifiers corresponding to entries in the - clock-names property. -- clock-names: must contain "pclk_lvds" - -- avdd1v0-supply: regulator phandle for 1.0V analog power -- avdd1v8-supply: regulator phandle for 1.8V analog power -- avdd3v3-supply: regulator phandle for 3.3V analog power - -- rockchip,grf: phandle to the general register files syscon -- rockchip,output: "rgb", "lvds" or "duallvds", This describes the output interface - -- phys: LVDS/DSI DPHY (px30 only) -- phy-names: name of the PHY, must be "dphy" (px30 only) - -Optional properties: -- pinctrl-names: must contain a "lcdc" entry. -- pinctrl-0: pin control group to be used for this controller. - -Required nodes: - -The lvds has two video ports as described by - Documentation/devicetree/bindings/media/video-interfaces.txt -Their connections are modeled using the OF graph bindings specified in - Documentation/devicetree/bindings/graph.txt. - -- video port 0 for the VOP input, the remote endpoint maybe vopb or vopl -- video port 1 for either a panel or subsequent encoder - -Example: - -lvds_panel: lvds-panel { - compatible = "auo,b101ean01"; - enable-gpios = <&gpio7 21 GPIO_ACTIVE_HIGH>; - data-mapping = "jeida-24"; - - ports { - panel_in_lvds: endpoint { - remote-endpoint = <&lvds_out_panel>; - }; - }; -}; - -For Rockchip RK3288: - - lvds: lvds@ff96c000 { - compatible = "rockchip,rk3288-lvds"; - rockchip,grf = <&grf>; - reg = <0xff96c000 0x4000>; - clocks = <&cru PCLK_LVDS_PHY>; - clock-names = "pclk_lvds"; - pinctrl-names = "lcdc"; - pinctrl-0 = <&lcdc_ctl>; - avdd1v0-supply = <&vdd10_lcd>; - avdd1v8-supply = <&vcc18_lcd>; - avdd3v3-supply = <&vcca_33>; - rockchip,output = "rgb"; - ports { - #address-cells = <1>; - #size-cells = <0>; - - lvds_in: port@0 { - reg = <0>; - - lvds_in_vopb: endpoint@0 { - reg = <0>; - remote-endpoint = <&vopb_out_lvds>; - }; - lvds_in_vopl: endpoint@1 { - reg = <1>; - remote-endpoint = <&vopl_out_lvds>; - }; - }; - - lvds_out: port@1 { - reg = <1>; - - lvds_out_panel: endpoint { - remote-endpoint = <&panel_in_lvds>; - }; - }; - }; - }; diff --git a/Documentation/devicetree/bindings/display/simple-framebuffer.yaml b/Documentation/devicetree/bindings/display/simple-framebuffer.yaml index 3c9f29e428a4..296500f9da05 100644 --- a/Documentation/devicetree/bindings/display/simple-framebuffer.yaml +++ b/Documentation/devicetree/bindings/display/simple-framebuffer.yaml @@ -26,6 +26,11 @@ description: |+ over control to a driver for the real hardware. The bindings for the hw nodes must specify which node is considered the primary node. + If a panel node is given, then the driver uses this to configure the + physical width and height of the display. If no panel node is given, + then the driver uses the width and height properties of the simplefb + node to estimate it. + It is advised to add display# aliases to help the OS determine how to number things. If display# aliases are used, then if the simplefb node contains a display property then the /aliases/display# path @@ -117,6 +122,10 @@ properties: $ref: /schemas/types.yaml#/definitions/phandle description: Primary display hardware node + panel: + $ref: /schemas/types.yaml#/definitions/phandle + description: Display panel node + allwinner,pipeline: description: Pipeline used by the framebuffer on Allwinner SoCs enum: diff --git a/Documentation/devicetree/bindings/display/tegra/nvidia,tegra114-mipi.yaml b/Documentation/devicetree/bindings/display/tegra/nvidia,tegra114-mipi.yaml index d5ca8cf86e8e..f448624dd779 100644 --- a/Documentation/devicetree/bindings/display/tegra/nvidia,tegra114-mipi.yaml +++ b/Documentation/devicetree/bindings/display/tegra/nvidia,tegra114-mipi.yaml @@ -38,7 +38,7 @@ properties: description: The number of cells in a MIPI calibration specifier. Should be 1. The single cell specifies a bitmask of the pads that need to be calibrated for a given device. - $ref: "/schemas/types.yaml#/definitions/uint32" + $ref: /schemas/types.yaml#/definitions/uint32 const: 1 additionalProperties: false diff --git a/Documentation/devicetree/bindings/display/tegra/nvidia,tegra124-sor.yaml b/Documentation/devicetree/bindings/display/tegra/nvidia,tegra124-sor.yaml index 907fb0baccae..70f0e45c71d6 100644 --- a/Documentation/devicetree/bindings/display/tegra/nvidia,tegra124-sor.yaml +++ b/Documentation/devicetree/bindings/display/tegra/nvidia,tegra124-sor.yaml @@ -69,12 +69,12 @@ properties: # Tegra186 and later nvidia,interface: description: index of the SOR interface - $ref: "/schemas/types.yaml#/definitions/uint32" + $ref: /schemas/types.yaml#/definitions/uint32 nvidia,ddc-i2c-bus: description: phandle of an I2C controller used for DDC EDID probing - $ref: "/schemas/types.yaml#/definitions/phandle" + $ref: /schemas/types.yaml#/definitions/phandle nvidia,hpd-gpio: description: specifies a GPIO used for hotplug detection @@ -82,23 +82,23 @@ properties: nvidia,edid: description: supplies a binary EDID blob - $ref: "/schemas/types.yaml#/definitions/uint8-array" + $ref: /schemas/types.yaml#/definitions/uint8-array nvidia,panel: description: phandle of a display panel, required for eDP - $ref: "/schemas/types.yaml#/definitions/phandle" + $ref: /schemas/types.yaml#/definitions/phandle nvidia,xbar-cfg: description: 5 cells containing the crossbar configuration. Each lane of the SOR, identified by the cell's index, is mapped via the crossbar to the pad specified by the cell's value. - $ref: "/schemas/types.yaml#/definitions/uint32-array" + $ref: /schemas/types.yaml#/definitions/uint32-array # optional when driving an eDP output nvidia,dpaux: description: phandle to a DispayPort AUX interface - $ref: "/schemas/types.yaml#/definitions/phandle" + $ref: /schemas/types.yaml#/definitions/phandle allOf: - if: diff --git a/Documentation/devicetree/bindings/display/tegra/nvidia,tegra186-dc.yaml b/Documentation/devicetree/bindings/display/tegra/nvidia,tegra186-dc.yaml index 265a60d79d89..ce4589466a18 100644 --- a/Documentation/devicetree/bindings/display/tegra/nvidia,tegra186-dc.yaml +++ b/Documentation/devicetree/bindings/display/tegra/nvidia,tegra186-dc.yaml @@ -60,13 +60,13 @@ properties: nvidia,outputs: description: A list of phandles of outputs that this display controller can drive. - $ref: "/schemas/types.yaml#/definitions/phandle-array" + $ref: /schemas/types.yaml#/definitions/phandle-array nvidia,head: description: The number of the display controller head. This is used to setup the various types of output to receive video data from the given head. - $ref: "/schemas/types.yaml#/definitions/uint32" + $ref: /schemas/types.yaml#/definitions/uint32 additionalProperties: false diff --git a/Documentation/devicetree/bindings/display/tegra/nvidia,tegra186-dsi-padctl.yaml b/Documentation/devicetree/bindings/display/tegra/nvidia,tegra186-dsi-padctl.yaml index e5a6145c8c53..da75b71e8ece 100644 --- a/Documentation/devicetree/bindings/display/tegra/nvidia,tegra186-dsi-padctl.yaml +++ b/Documentation/devicetree/bindings/display/tegra/nvidia,tegra186-dsi-padctl.yaml @@ -29,7 +29,7 @@ properties: - const: dsi allOf: - - $ref: "/schemas/reset/reset.yaml" + - $ref: /schemas/reset/reset.yaml additionalProperties: false diff --git a/Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-dsi.yaml b/Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-dsi.yaml index 511cbe74e729..59e1dc0813e7 100644 --- a/Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-dsi.yaml +++ b/Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-dsi.yaml @@ -59,12 +59,12 @@ properties: description: Should contain a phandle and a specifier specifying which pads are used by this DSI output and need to be calibrated. See nvidia,tegra114-mipi.yaml for details. - $ref: "/schemas/types.yaml#/definitions/phandle-array" + $ref: /schemas/types.yaml#/definitions/phandle-array nvidia,ddc-i2c-bus: description: phandle of an I2C controller used for DDC EDID probing - $ref: "/schemas/types.yaml#/definitions/phandle" + $ref: /schemas/types.yaml#/definitions/phandle nvidia,hpd-gpio: description: specifies a GPIO used for hotplug detection @@ -72,19 +72,19 @@ properties: nvidia,edid: description: supplies a binary EDID blob - $ref: "/schemas/types.yaml#/definitions/uint8-array" + $ref: /schemas/types.yaml#/definitions/uint8-array nvidia,panel: description: phandle of a display panel - $ref: "/schemas/types.yaml#/definitions/phandle" + $ref: /schemas/types.yaml#/definitions/phandle nvidia,ganged-mode: description: contains a phandle to a second DSI controller to gang up with in order to support up to 8 data lanes - $ref: "/schemas/types.yaml#/definitions/phandle" + $ref: /schemas/types.yaml#/definitions/phandle allOf: - - $ref: "../dsi-controller.yaml#" + - $ref: ../dsi-controller.yaml# - if: properties: compatible: diff --git a/Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-hdmi.yaml b/Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-hdmi.yaml index f65e59cfffa7..f77197e4869f 100644 --- a/Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-hdmi.yaml +++ b/Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-hdmi.yaml @@ -68,7 +68,7 @@ properties: nvidia,ddc-i2c-bus: description: phandle of an I2C controller used for DDC EDID probing - $ref: "/schemas/types.yaml#/definitions/phandle" + $ref: /schemas/types.yaml#/definitions/phandle nvidia,hpd-gpio: description: specifies a GPIO used for hotplug detection @@ -76,11 +76,11 @@ properties: nvidia,edid: description: supplies a binary EDID blob - $ref: "/schemas/types.yaml#/definitions/uint8-array" + $ref: /schemas/types.yaml#/definitions/uint8-array nvidia,panel: description: phandle of a display panel - $ref: "/schemas/types.yaml#/definitions/phandle" + $ref: /schemas/types.yaml#/definitions/phandle "#sound-dai-cells": const: 0 diff --git a/Documentation/devicetree/bindings/display/ti/ti,am65x-dss.yaml b/Documentation/devicetree/bindings/display/ti/ti,am65x-dss.yaml index 5c7d2cbc4aac..b6b402f16161 100644 --- a/Documentation/devicetree/bindings/display/ti/ti,am65x-dss.yaml +++ b/Documentation/devicetree/bindings/display/ti/ti,am65x-dss.yaml @@ -2,8 +2,8 @@ # Copyright 2019 Texas Instruments Incorporated %YAML 1.2 --- -$id: "http://devicetree.org/schemas/display/ti/ti,am65x-dss.yaml#" -$schema: "http://devicetree.org/meta-schemas/core.yaml#" +$id: http://devicetree.org/schemas/display/ti/ti,am65x-dss.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# title: Texas Instruments AM65x Display Subsystem @@ -88,7 +88,7 @@ properties: The DSS DPI output port node from video port 2 ti,am65x-oldi-io-ctrl: - $ref: "/schemas/types.yaml#/definitions/phandle" + $ref: /schemas/types.yaml#/definitions/phandle description: phandle to syscon device node mapping OLDI IO_CTRL registers. The mapped range should point to OLDI_DAT0_IO_CTRL, map it and diff --git a/Documentation/devicetree/bindings/display/ti/ti,j721e-dss.yaml b/Documentation/devicetree/bindings/display/ti/ti,j721e-dss.yaml index 2986f9acc9f0..fad7cba58d39 100644 --- a/Documentation/devicetree/bindings/display/ti/ti,j721e-dss.yaml +++ b/Documentation/devicetree/bindings/display/ti/ti,j721e-dss.yaml @@ -2,8 +2,8 @@ # Copyright 2019 Texas Instruments Incorporated %YAML 1.2 --- -$id: "http://devicetree.org/schemas/display/ti/ti,j721e-dss.yaml#" -$schema: "http://devicetree.org/meta-schemas/core.yaml#" +$id: http://devicetree.org/schemas/display/ti/ti,j721e-dss.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# title: Texas Instruments J721E Display Subsystem diff --git a/Documentation/devicetree/bindings/display/ti/ti,k2g-dss.yaml b/Documentation/devicetree/bindings/display/ti/ti,k2g-dss.yaml index 7ce7bbad5780..96b1439f88e3 100644 --- a/Documentation/devicetree/bindings/display/ti/ti,k2g-dss.yaml +++ b/Documentation/devicetree/bindings/display/ti/ti,k2g-dss.yaml @@ -2,8 +2,8 @@ # Copyright 2019 Texas Instruments Incorporated %YAML 1.2 --- -$id: "http://devicetree.org/schemas/display/ti/ti,k2g-dss.yaml#" -$schema: "http://devicetree.org/meta-schemas/core.yaml#" +$id: http://devicetree.org/schemas/display/ti/ti,k2g-dss.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# title: Texas Instruments K2G Display Subsystem diff --git a/Documentation/devicetree/bindings/display/xylon,logicvc-display.yaml b/Documentation/devicetree/bindings/display/xylon,logicvc-display.yaml index fc02c5d50ce4..76b804b7c880 100644 --- a/Documentation/devicetree/bindings/display/xylon,logicvc-display.yaml +++ b/Documentation/devicetree/bindings/display/xylon,logicvc-display.yaml @@ -2,8 +2,8 @@ # Copyright 2019 Bootlin %YAML 1.2 --- -$id: "http://devicetree.org/schemas/display/xylon,logicvc-display.yaml#" -$schema: "http://devicetree.org/meta-schemas/core.yaml#" +$id: http://devicetree.org/schemas/display/xylon,logicvc-display.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# title: Xylon LogiCVC display controller @@ -89,25 +89,25 @@ properties: description: Display output colorspace (C_DISPLAY_COLOR_SPACE). xylon,display-depth: - $ref: "/schemas/types.yaml#/definitions/uint32" + $ref: /schemas/types.yaml#/definitions/uint32 description: Display output depth (C_PIXEL_DATA_WIDTH). xylon,row-stride: - $ref: "/schemas/types.yaml#/definitions/uint32" + $ref: /schemas/types.yaml#/definitions/uint32 description: Fixed number of pixels in a framebuffer row (C_ROW_STRIDE). xylon,dithering: - $ref: "/schemas/types.yaml#/definitions/flag" + $ref: /schemas/types.yaml#/definitions/flag description: Dithering module is enabled (C_XCOLOR) xylon,background-layer: - $ref: "/schemas/types.yaml#/definitions/flag" + $ref: /schemas/types.yaml#/definitions/flag description: | The last layer is used to display a black background (C_USE_BACKGROUND). The layer must still be registered. xylon,layers-configurable: - $ref: "/schemas/types.yaml#/definitions/flag" + $ref: /schemas/types.yaml#/definitions/flag description: | Configuration of layers' size, position and offset is enabled (C_USE_SIZE_POSITION). @@ -131,7 +131,7 @@ properties: maxItems: 1 xylon,layer-depth: - $ref: "/schemas/types.yaml#/definitions/uint32" + $ref: /schemas/types.yaml#/definitions/uint32 description: Layer depth (C_LAYER_X_DATA_WIDTH). xylon,layer-colorspace: @@ -151,19 +151,19 @@ properties: description: Alpha mode for the layer (C_LAYER_X_ALPHA_MODE). xylon,layer-base-offset: - $ref: "/schemas/types.yaml#/definitions/uint32" + $ref: /schemas/types.yaml#/definitions/uint32 description: | Offset in number of lines (C_LAYER_X_OFFSET) starting from the video RAM base (C_VMEM_BASEADDR), only for version 3. xylon,layer-buffer-offset: - $ref: "/schemas/types.yaml#/definitions/uint32" + $ref: /schemas/types.yaml#/definitions/uint32 description: | Offset in number of lines (C_BUFFER_*_OFFSET) starting from the layer base offset for the second buffer used in double-buffering. xylon,layer-primary: - $ref: "/schemas/types.yaml#/definitions/flag" + $ref: /schemas/types.yaml#/definitions/flag description: | Layer should be registered as a primary plane (exactly one is required). diff --git a/Documentation/devicetree/bindings/firmware/arm,scmi.yaml b/Documentation/devicetree/bindings/firmware/arm,scmi.yaml index 2f7c51c75e85..5824c43e9893 100644 --- a/Documentation/devicetree/bindings/firmware/arm,scmi.yaml +++ b/Documentation/devicetree/bindings/firmware/arm,scmi.yaml @@ -56,17 +56,38 @@ properties: description: Specifies the mailboxes used to communicate with SCMI compliant firmware. - items: - - const: tx - - const: rx + oneOf: + - items: + - const: tx + - const: rx + minItems: 1 + - items: + - const: tx + - const: tx_reply + - const: rx + minItems: 2 mboxes: description: List of phandle and mailbox channel specifiers. It should contain - exactly one or two mailboxes, one for transmitting messages("tx") - and another optional for receiving the notifications("rx") if supported. + exactly one, two or three mailboxes; the first one or two for transmitting + messages ("tx") and another optional ("rx") for receiving notifications + and delayed responses, if supported by the platform. + The number of mailboxes needed for transmitting messages depends on the + type of channels exposed by the specific underlying mailbox controller; + one single channel descriptor is enough if such channel is bidirectional, + while two channel descriptors are needed to represent the SCMI ("tx") + channel if the underlying mailbox channels are of unidirectional type. + The effective combination in numbers of mboxes and shmem descriptors let + the SCMI subsystem determine unambiguosly which type of SCMI channels are + made available by the underlying mailbox controller and how to use them. + 1 mbox / 1 shmem => SCMI TX over 1 mailbox bidirectional channel + 2 mbox / 2 shmem => SCMI TX and RX over 2 mailbox bidirectional channels + 2 mbox / 1 shmem => SCMI TX over 2 mailbox unidirectional channels + 3 mbox / 2 shmem => SCMI TX and RX over 3 mailbox unidirectional channels + Any other combination of mboxes and shmem is invalid. minItems: 1 - maxItems: 2 + maxItems: 3 shmem: description: @@ -228,13 +249,20 @@ $defs: maxItems: 1 mbox-names: - items: - - const: tx - - const: rx + oneOf: + - items: + - const: tx + - const: rx + minItems: 1 + - items: + - const: tx + - const: tx_reply + - const: rx + minItems: 2 mboxes: minItems: 1 - maxItems: 2 + maxItems: 3 shmem: minItems: 1 diff --git a/Documentation/devicetree/bindings/firmware/qcom,scm.yaml b/Documentation/devicetree/bindings/firmware/qcom,scm.yaml index a66e99812b1f..367d04ad1923 100644 --- a/Documentation/devicetree/bindings/firmware/qcom,scm.yaml +++ b/Documentation/devicetree/bindings/firmware/qcom,scm.yaml @@ -24,9 +24,11 @@ properties: - qcom,scm-apq8064 - qcom,scm-apq8084 - qcom,scm-ipq4019 + - qcom,scm-ipq5332 - qcom,scm-ipq6018 - qcom,scm-ipq806x - qcom,scm-ipq8074 + - qcom,scm-ipq9574 - qcom,scm-mdm9607 - qcom,scm-msm8226 - qcom,scm-msm8660 @@ -38,10 +40,12 @@ properties: - qcom,scm-msm8994 - qcom,scm-msm8996 - qcom,scm-msm8998 + - qcom,scm-qcm2290 - qcom,scm-qdu1000 - qcom,scm-sa8775p - qcom,scm-sc7180 - qcom,scm-sc7280 + - qcom,scm-sc8180x - qcom,scm-sc8280xp - qcom,scm-sdm670 - qcom,scm-sdm845 @@ -107,6 +111,7 @@ allOf: - qcom,scm-msm8960 - qcom,scm-msm8974 - qcom,scm-msm8976 + - qcom,scm-qcm2290 - qcom,scm-sm6375 then: required: @@ -125,6 +130,7 @@ allOf: - qcom,scm-apq8064 - qcom,scm-msm8660 - qcom,scm-msm8960 + - qcom,scm-qcm2290 - qcom,scm-sm6375 then: properties: @@ -166,6 +172,7 @@ allOf: compatible: contains: enum: + - qcom,scm-qdu1000 - qcom,scm-sm8450 - qcom,scm-sm8550 then: diff --git a/Documentation/devicetree/bindings/gpio/fcs,fxl6408.yaml b/Documentation/devicetree/bindings/gpio/fcs,fxl6408.yaml new file mode 100644 index 000000000000..65b6970e42fb --- /dev/null +++ b/Documentation/devicetree/bindings/gpio/fcs,fxl6408.yaml @@ -0,0 +1,58 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/gpio/fcs,fxl6408.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Fairchild FXL6408 I2C GPIO Expander + +maintainers: + - Emanuele Ghidoli <emanuele.ghidoli@toradex.com> + +properties: + compatible: + enum: + - fcs,fxl6408 + + reg: + maxItems: 1 + + "#gpio-cells": + const: 2 + + gpio-controller: true + + gpio-line-names: + minItems: 1 + maxItems: 8 + +patternProperties: + "^(hog-[0-9]+|.+-hog(-[0-9]+)?)$": + required: + - gpio-hog + +required: + - compatible + - reg + - gpio-controller + - "#gpio-cells" + +additionalProperties: false + +examples: + - | + i2c { + #address-cells = <1>; + #size-cells = <0>; + + gpio_expander_43: gpio-expander@43 { + compatible = "fcs,fxl6408"; + reg = <0x43>; + gpio-controller; + #gpio-cells = <2>; + gpio-line-names = "Wi-Fi_W_DISABLE", "Wi-Fi_WKUP_WLAN", + "PWR_EN_+V3.3_WiFi_N", "PCIe_REF_CLK_EN", + "USB_RESET_N", "USB_BYPASS_N", "Wi-Fi_PDn", + "Wi-Fi_WKUP_BT"; + }; + }; diff --git a/Documentation/devicetree/bindings/gpio/gpio.txt b/Documentation/devicetree/bindings/gpio/gpio.txt index 5663e71b751f..d82c32217fff 100644 --- a/Documentation/devicetree/bindings/gpio/gpio.txt +++ b/Documentation/devicetree/bindings/gpio/gpio.txt @@ -154,18 +154,35 @@ of the GPIOs that can't be used. Optionally, a GPIO controller may have a "gpio-line-names" property. This is an array of strings defining the names of the GPIO lines going out of the -GPIO controller. This name should be the most meaningful producer name -for the system, such as a rail name indicating the usage. Package names -such as pin name are discouraged: such lines have opaque names (since they -are by definition generic purpose) and such names are usually not very -helpful. For example "MMC-CD", "Red LED Vdd" and "ethernet reset" are -reasonable line names as they describe what the line is used for. "GPIO0" -is not a good name to give to a GPIO line. Placeholders are discouraged: -rather use the "" (blank string) if the use of the GPIO line is undefined -in your design. The names are assigned starting from line offset 0 from -left to right from the passed array. An incomplete array (where the number -of passed named are less than ngpios) will still be used up until the last -provided valid line index. +GPIO controller. + +For lines which are routed to on-board devices, this name should be +the most meaningful producer name for the system, such as a rail name +indicating the usage. Package names, such as a pin name, are discouraged: +such lines have opaque names (since they are by definition general-purpose) +and such names are usually not very helpful. For example "MMC-CD", "Red LED +Vdd" and "ethernet reset" are reasonable line names as they describe what +the line is used for. "GPIO0" is not a good name to give to a GPIO line +that is hard-wired to a specific device. + +However, in the case of lines that are routed to a general purpose header +(e.g. the Raspberry Pi 40-pin header), and therefore are not hard-wired to +specific devices, using a pin number or the names on the header is fine +provided these are real (preferably unique) names. Using an SoC's pad name +or package name, or names made up from kernel-internal software constructs, +are strongly discouraged. For example "pin8 [gpio14/uart0_txd]" is fine +if the board's documentation labels pin 8 as such. However "PortB_24" (an +example of a name from an SoC's reference manual) would not be desirable. + +In either case placeholders are discouraged: rather use the "" (blank +string) if the use of the GPIO line is undefined in your design. Ideally, +try to add comments to the dts file describing the naming the convention +you have chosen, and specifying from where the names are derived. + +The names are assigned starting from line offset 0, from left to right, +from the passed array. An incomplete array (where the number of passed +names is less than ngpios) will be used up until the last provided valid +line index. Example: diff --git a/Documentation/devicetree/bindings/gpio/loongson,ls-gpio.yaml b/Documentation/devicetree/bindings/gpio/loongson,ls-gpio.yaml new file mode 100644 index 000000000000..fb86e8ce6349 --- /dev/null +++ b/Documentation/devicetree/bindings/gpio/loongson,ls-gpio.yaml @@ -0,0 +1,126 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/gpio/loongson,ls-gpio.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Loongson GPIO controller. + +maintainers: + - Yinbo Zhu <zhuyinbo@loongson.cn> + +properties: + compatible: + enum: + - loongson,ls2k-gpio + - loongson,ls7a-gpio + + reg: + maxItems: 1 + + ngpios: + minimum: 1 + maximum: 64 + + "#gpio-cells": + const: 2 + + gpio-controller: true + + gpio-ranges: true + + interrupts: + minItems: 1 + maxItems: 64 + +required: + - compatible + - reg + - ngpios + - "#gpio-cells" + - gpio-controller + - gpio-ranges + - interrupts + +additionalProperties: false + +examples: + - | + #include <dt-bindings/interrupt-controller/irq.h> + + gpio0: gpio@1fe00500 { + compatible = "loongson,ls2k-gpio"; + reg = <0x1fe00500 0x38>; + ngpios = <64>; + #gpio-cells = <2>; + gpio-controller; + gpio-ranges = <&pctrl 0 0 15>, + <&pctrl 16 16 15>, + <&pctrl 32 32 10>, + <&pctrl 44 44 20>; + interrupt-parent = <&liointc1>; + interrupts = <28 IRQ_TYPE_LEVEL_LOW>, + <29 IRQ_TYPE_LEVEL_LOW>, + <30 IRQ_TYPE_LEVEL_LOW>, + <30 IRQ_TYPE_LEVEL_LOW>, + <26 IRQ_TYPE_LEVEL_LOW>, + <26 IRQ_TYPE_LEVEL_LOW>, + <26 IRQ_TYPE_LEVEL_LOW>, + <26 IRQ_TYPE_LEVEL_LOW>, + <26 IRQ_TYPE_LEVEL_LOW>, + <26 IRQ_TYPE_LEVEL_LOW>, + <26 IRQ_TYPE_LEVEL_LOW>, + <26 IRQ_TYPE_LEVEL_LOW>, + <26 IRQ_TYPE_LEVEL_LOW>, + <26 IRQ_TYPE_LEVEL_LOW>, + <26 IRQ_TYPE_LEVEL_LOW>, + <>, + <26 IRQ_TYPE_LEVEL_LOW>, + <26 IRQ_TYPE_LEVEL_LOW>, + <26 IRQ_TYPE_LEVEL_LOW>, + <26 IRQ_TYPE_LEVEL_LOW>, + <26 IRQ_TYPE_LEVEL_LOW>, + <26 IRQ_TYPE_LEVEL_LOW>, + <26 IRQ_TYPE_LEVEL_LOW>, + <26 IRQ_TYPE_LEVEL_LOW>, + <26 IRQ_TYPE_LEVEL_LOW>, + <26 IRQ_TYPE_LEVEL_LOW>, + <26 IRQ_TYPE_LEVEL_LOW>, + <26 IRQ_TYPE_LEVEL_LOW>, + <26 IRQ_TYPE_LEVEL_LOW>, + <26 IRQ_TYPE_LEVEL_LOW>, + <26 IRQ_TYPE_LEVEL_LOW>, + <26 IRQ_TYPE_LEVEL_LOW>, + <27 IRQ_TYPE_LEVEL_LOW>, + <27 IRQ_TYPE_LEVEL_LOW>, + <27 IRQ_TYPE_LEVEL_LOW>, + <27 IRQ_TYPE_LEVEL_LOW>, + <27 IRQ_TYPE_LEVEL_LOW>, + <>, + <27 IRQ_TYPE_LEVEL_LOW>, + <27 IRQ_TYPE_LEVEL_LOW>, + <27 IRQ_TYPE_LEVEL_LOW>, + <27 IRQ_TYPE_LEVEL_LOW>, + <>, + <>, + <27 IRQ_TYPE_LEVEL_LOW>, + <27 IRQ_TYPE_LEVEL_LOW>, + <27 IRQ_TYPE_LEVEL_LOW>, + <27 IRQ_TYPE_LEVEL_LOW>, + <27 IRQ_TYPE_LEVEL_LOW>, + <27 IRQ_TYPE_LEVEL_LOW>, + <27 IRQ_TYPE_LEVEL_LOW>, + <27 IRQ_TYPE_LEVEL_LOW>, + <27 IRQ_TYPE_LEVEL_LOW>, + <27 IRQ_TYPE_LEVEL_LOW>, + <27 IRQ_TYPE_LEVEL_LOW>, + <27 IRQ_TYPE_LEVEL_LOW>, + <27 IRQ_TYPE_LEVEL_LOW>, + <27 IRQ_TYPE_LEVEL_LOW>, + <27 IRQ_TYPE_LEVEL_LOW>, + <27 IRQ_TYPE_LEVEL_LOW>, + <27 IRQ_TYPE_LEVEL_LOW>, + <27 IRQ_TYPE_LEVEL_LOW>, + <27 IRQ_TYPE_LEVEL_LOW>, + <27 IRQ_TYPE_LEVEL_LOW>; + }; diff --git a/Documentation/devicetree/bindings/gpio/loongson,ls1x-gpio.yaml b/Documentation/devicetree/bindings/gpio/loongson,ls1x-gpio.yaml new file mode 100644 index 000000000000..1a472c05697c --- /dev/null +++ b/Documentation/devicetree/bindings/gpio/loongson,ls1x-gpio.yaml @@ -0,0 +1,49 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/gpio/loongson,ls1x-gpio.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Loongson-1 GPIO controller + +maintainers: + - Keguang Zhang <keguang.zhang@gmail.com> + +properties: + compatible: + const: loongson,ls1x-gpio + + reg: + maxItems: 1 + + gpio-controller: true + + "#gpio-cells": + const: 2 + + ngpios: + minimum: 1 + maximum: 32 + +required: + - compatible + - reg + - gpio-controller + - "#gpio-cells" + - ngpios + +additionalProperties: false + +examples: + - | + gpio0: gpio@1fd010c0 { + compatible = "loongson,ls1x-gpio"; + reg = <0x1fd010c0 0x4>; + + gpio-controller; + #gpio-cells = <2>; + + ngpios = <32>; + }; + +... diff --git a/Documentation/devicetree/bindings/gpu/arm,mali-bifrost.yaml b/Documentation/devicetree/bindings/gpu/arm,mali-bifrost.yaml index 78964c140b46..0400a361875d 100644 --- a/Documentation/devicetree/bindings/gpu/arm,mali-bifrost.yaml +++ b/Documentation/devicetree/bindings/gpu/arm,mali-bifrost.yaml @@ -19,6 +19,8 @@ properties: - enum: - amlogic,meson-g12a-mali - mediatek,mt8183-mali + - mediatek,mt8183b-mali + - mediatek,mt8186-mali - realtek,rtd1619-mali - renesas,r9a07g044-mali - renesas,r9a07g054-mali @@ -27,6 +29,11 @@ properties: - const: arm,mali-bifrost # Mali Bifrost GPU model/revision is fully discoverable - items: - enum: + - mediatek,mt8195-mali + - const: mediatek,mt8192-mali + - const: arm,mali-valhall-jm # Mali Valhall GPU model/revision is fully discoverable + - items: + - enum: - mediatek,mt8192-mali - const: arm,mali-valhall-jm # Mali Valhall GPU model/revision is fully discoverable @@ -63,7 +70,11 @@ properties: power-domains: minItems: 1 - maxItems: 3 + maxItems: 5 + + power-domain-names: + minItems: 2 + maxItems: 5 resets: minItems: 1 @@ -93,6 +104,13 @@ properties: dma-coherent: true + nvmem-cell-names: + items: + - const: speed-bin + + nvmem-cells: + maxItems: 1 + required: - compatible - reg @@ -109,6 +127,10 @@ allOf: contains: const: amlogic,meson-g12a-mali then: + properties: + power-domains: + maxItems: 1 + power-domain-names: false required: - resets - if: @@ -131,6 +153,9 @@ allOf: - const: gpu - const: bus - const: bus_ace + power-domains: + maxItems: 1 + power-domain-names: false resets: minItems: 3 reset-names: @@ -152,6 +177,7 @@ allOf: properties: power-domains: minItems: 3 + maxItems: 3 power-domain-names: items: - const: core0 @@ -164,13 +190,65 @@ allOf: - power-domain-names else: properties: - power-domains: - maxItems: 1 sram-supply: false - if: properties: compatible: contains: + const: mediatek,mt8183b-mali + then: + properties: + power-domains: + minItems: 3 + maxItems: 3 + power-domain-names: + items: + - const: core0 + - const: core1 + - const: core2 + required: + - power-domains + - power-domain-names + - if: + properties: + compatible: + contains: + const: mediatek,mt8186-mali + then: + properties: + power-domains: + minItems: 2 + maxItems: 2 + power-domain-names: + items: + - const: core0 + - const: core1 + required: + - power-domains + - power-domain-names + - if: + properties: + compatible: + contains: + const: mediatek,mt8192-mali + then: + properties: + power-domains: + minItems: 5 + power-domain-names: + items: + - const: core0 + - const: core1 + - const: core2 + - const: core3 + - const: core4 + required: + - power-domains + - power-domain-names + - if: + properties: + compatible: + contains: const: rockchip,rk3568-mali then: properties: @@ -180,6 +258,9 @@ allOf: items: - const: gpu - const: bus + power-domains: + maxItems: 1 + power-domain-names: false required: - clock-names diff --git a/Documentation/devicetree/bindings/gpu/host1x/nvidia,tegra210-nvdec.yaml b/Documentation/devicetree/bindings/gpu/host1x/nvidia,tegra210-nvdec.yaml index ed9554c837ef..ba4c6473ff92 100644 --- a/Documentation/devicetree/bindings/gpu/host1x/nvidia,tegra210-nvdec.yaml +++ b/Documentation/devicetree/bindings/gpu/host1x/nvidia,tegra210-nvdec.yaml @@ -1,8 +1,8 @@ # SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) %YAML 1.2 --- -$id: "http://devicetree.org/schemas/gpu/host1x/nvidia,tegra210-nvdec.yaml#" -$schema: "http://devicetree.org/meta-schemas/core.yaml#" +$id: http://devicetree.org/schemas/gpu/host1x/nvidia,tegra210-nvdec.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# title: NVIDIA Tegra NVDEC diff --git a/Documentation/devicetree/bindings/gpu/host1x/nvidia,tegra210-nvenc.yaml b/Documentation/devicetree/bindings/gpu/host1x/nvidia,tegra210-nvenc.yaml index 8199e5fa8211..c23dae713eb8 100644 --- a/Documentation/devicetree/bindings/gpu/host1x/nvidia,tegra210-nvenc.yaml +++ b/Documentation/devicetree/bindings/gpu/host1x/nvidia,tegra210-nvenc.yaml @@ -1,8 +1,8 @@ # 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#" +$id: http://devicetree.org/schemas/gpu/host1x/nvidia,tegra210-nvenc.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# title: NVIDIA Tegra NVENC diff --git a/Documentation/devicetree/bindings/gpu/host1x/nvidia,tegra210-nvjpg.yaml b/Documentation/devicetree/bindings/gpu/host1x/nvidia,tegra210-nvjpg.yaml index 895fb346ac72..99a33a5eac3f 100644 --- a/Documentation/devicetree/bindings/gpu/host1x/nvidia,tegra210-nvjpg.yaml +++ b/Documentation/devicetree/bindings/gpu/host1x/nvidia,tegra210-nvjpg.yaml @@ -1,8 +1,8 @@ # 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#" +$id: http://devicetree.org/schemas/gpu/host1x/nvidia,tegra210-nvjpg.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# title: NVIDIA Tegra NVJPG diff --git a/Documentation/devicetree/bindings/gpu/host1x/nvidia,tegra234-nvdec.yaml b/Documentation/devicetree/bindings/gpu/host1x/nvidia,tegra234-nvdec.yaml index 4bdc19a2bccf..0b7561c8b9bb 100644 --- a/Documentation/devicetree/bindings/gpu/host1x/nvidia,tegra234-nvdec.yaml +++ b/Documentation/devicetree/bindings/gpu/host1x/nvidia,tegra234-nvdec.yaml @@ -1,8 +1,8 @@ # SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) %YAML 1.2 --- -$id: "http://devicetree.org/schemas/gpu/host1x/nvidia,tegra234-nvdec.yaml#" -$schema: "http://devicetree.org/meta-schemas/core.yaml#" +$id: http://devicetree.org/schemas/gpu/host1x/nvidia,tegra234-nvdec.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# title: NVIDIA Tegra234 NVDEC diff --git a/Documentation/devicetree/bindings/i2c/apple,i2c.yaml b/Documentation/devicetree/bindings/i2c/apple,i2c.yaml index 4ac61fec90e2..3f0e94189f2d 100644 --- a/Documentation/devicetree/bindings/i2c/apple,i2c.yaml +++ b/Documentation/devicetree/bindings/i2c/apple,i2c.yaml @@ -23,6 +23,7 @@ properties: items: - enum: - apple,t8103-i2c + - apple,t8112-i2c - apple,t6000-i2c - const: apple,i2c diff --git a/Documentation/devicetree/bindings/interrupt-controller/apple,aic2.yaml b/Documentation/devicetree/bindings/interrupt-controller/apple,aic2.yaml index 06948c0e36a5..2bde6cc6fe0a 100644 --- a/Documentation/devicetree/bindings/interrupt-controller/apple,aic2.yaml +++ b/Documentation/devicetree/bindings/interrupt-controller/apple,aic2.yaml @@ -31,19 +31,22 @@ description: | properties: compatible: items: - - const: apple,t6000-aic + - enum: + - apple,t8112-aic + - apple,t6000-aic - const: apple,aic2 interrupt-controller: true '#interrupt-cells': - const: 4 + minimum: 3 + maximum: 4 description: | The 1st cell contains the interrupt type: - 0: Hardware IRQ - 1: FIQ - The 2nd cell contains the die ID. + The 2nd cell contains the die ID (only present on apple,t6000-aic). The next cell contains the interrupt number. - HW IRQs: interrupt number @@ -109,6 +112,19 @@ additionalProperties: false allOf: - $ref: /schemas/interrupt-controller.yaml# + - if: + properties: + compatible: + contains: + const: apple,t8112-aic + then: + properties: + '#interrupt-cells': + const: 3 + else: + properties: + '#interrupt-cells': + const: 4 examples: - | diff --git a/Documentation/devicetree/bindings/interrupt-controller/loongarch,cpu-interrupt-controller.yaml b/Documentation/devicetree/bindings/interrupt-controller/loongson,cpu-interrupt-controller.yaml index 2a1cf885c99d..adf989976dcc 100644 --- a/Documentation/devicetree/bindings/interrupt-controller/loongarch,cpu-interrupt-controller.yaml +++ b/Documentation/devicetree/bindings/interrupt-controller/loongson,cpu-interrupt-controller.yaml @@ -1,7 +1,7 @@ # SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause %YAML 1.2 --- -$id: http://devicetree.org/schemas/interrupt-controller/loongarch,cpu-interrupt-controller.yaml# +$id: http://devicetree.org/schemas/interrupt-controller/loongson,cpu-interrupt-controller.yaml# $schema: http://devicetree.org/meta-schemas/core.yaml# title: LoongArch CPU Interrupt Controller @@ -11,7 +11,7 @@ maintainers: properties: compatible: - const: loongarch,cpu-interrupt-controller + const: loongson,cpu-interrupt-controller '#interrupt-cells': const: 1 @@ -28,7 +28,7 @@ required: examples: - | interrupt-controller { - compatible = "loongarch,cpu-interrupt-controller"; + compatible = "loongson,cpu-interrupt-controller"; #interrupt-cells = <1>; interrupt-controller; }; 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 63bc89e13480..4e98261f2948 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 @@ -59,6 +59,7 @@ properties: - enum: - sifive,fu540-c000-plic - starfive,jh7100-plic + - starfive,jh7110-plic - canaan,k210-plic - const: sifive,plic-1.0.0 - items: diff --git a/Documentation/devicetree/bindings/iommu/apple,sart.yaml b/Documentation/devicetree/bindings/iommu/apple,sart.yaml index 1524fa3094ef..e87c1520fea6 100644 --- a/Documentation/devicetree/bindings/iommu/apple,sart.yaml +++ b/Documentation/devicetree/bindings/iommu/apple,sart.yaml @@ -28,9 +28,13 @@ description: properties: compatible: - enum: - - apple,t6000-sart - - apple,t8103-sart + oneOf: + - items: + - const: apple,t8112-sart + - const: apple,t6000-sart + - enum: + - apple,t6000-sart + - apple,t8103-sart reg: maxItems: 1 diff --git a/Documentation/devicetree/bindings/mailbox/apple,mailbox.yaml b/Documentation/devicetree/bindings/mailbox/apple,mailbox.yaml index 5c5c328b3134..4c0668e5f0bd 100644 --- a/Documentation/devicetree/bindings/mailbox/apple,mailbox.yaml +++ b/Documentation/devicetree/bindings/mailbox/apple,mailbox.yaml @@ -29,6 +29,7 @@ properties: items: - enum: - apple,t8103-asc-mailbox + - apple,t8112-asc-mailbox - apple,t6000-asc-mailbox - const: apple,asc-mailbox-v4 @@ -39,6 +40,7 @@ properties: items: - enum: - apple,t8103-m3-mailbox + - apple,t8112-m3-mailbox - apple,t6000-m3-mailbox - const: apple,m3-mailbox-v2 diff --git a/Documentation/devicetree/bindings/media/allwinner,sun4i-a10-ir.yaml b/Documentation/devicetree/bindings/media/allwinner,sun4i-a10-ir.yaml index 53945c61325c..42dfe22ad5f1 100644 --- a/Documentation/devicetree/bindings/media/allwinner,sun4i-a10-ir.yaml +++ b/Documentation/devicetree/bindings/media/allwinner,sun4i-a10-ir.yaml @@ -11,7 +11,7 @@ maintainers: - Maxime Ripard <mripard@kernel.org> allOf: - - $ref: "rc.yaml#" + - $ref: rc.yaml# properties: compatible: diff --git a/Documentation/devicetree/bindings/media/allwinner,sun50i-h6-vpu-g2.yaml b/Documentation/devicetree/bindings/media/allwinner,sun50i-h6-vpu-g2.yaml index 9d44236f2deb..a4f06bbdfe49 100644 --- a/Documentation/devicetree/bindings/media/allwinner,sun50i-h6-vpu-g2.yaml +++ b/Documentation/devicetree/bindings/media/allwinner,sun50i-h6-vpu-g2.yaml @@ -2,8 +2,8 @@ %YAML 1.2 --- -$id: "http://devicetree.org/schemas/media/allwinner,sun50i-h6-vpu-g2.yaml#" -$schema: "http://devicetree.org/meta-schemas/core.yaml#" +$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 diff --git a/Documentation/devicetree/bindings/media/amlogic,axg-ge2d.yaml b/Documentation/devicetree/bindings/media/amlogic,axg-ge2d.yaml index e551be5e680e..f23fa6d06ad0 100644 --- a/Documentation/devicetree/bindings/media/amlogic,axg-ge2d.yaml +++ b/Documentation/devicetree/bindings/media/amlogic,axg-ge2d.yaml @@ -2,8 +2,8 @@ # Copyright 2020 BayLibre, SAS %YAML 1.2 --- -$id: "http://devicetree.org/schemas/media/amlogic,axg-ge2d.yaml#" -$schema: "http://devicetree.org/meta-schemas/core.yaml#" +$id: http://devicetree.org/schemas/media/amlogic,axg-ge2d.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# title: Amlogic GE2D Acceleration Unit diff --git a/Documentation/devicetree/bindings/media/amlogic,gx-vdec.yaml b/Documentation/devicetree/bindings/media/amlogic,gx-vdec.yaml index b827edabcafa..55930f6107c9 100644 --- a/Documentation/devicetree/bindings/media/amlogic,gx-vdec.yaml +++ b/Documentation/devicetree/bindings/media/amlogic,gx-vdec.yaml @@ -2,8 +2,8 @@ # Copyright 2019 BayLibre, SAS %YAML 1.2 --- -$id: "http://devicetree.org/schemas/media/amlogic,gx-vdec.yaml#" -$schema: "http://devicetree.org/meta-schemas/core.yaml#" +$id: http://devicetree.org/schemas/media/amlogic,gx-vdec.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# title: Amlogic Video Decoder diff --git a/Documentation/devicetree/bindings/media/amlogic,meson-ir-tx.yaml b/Documentation/devicetree/bindings/media/amlogic,meson-ir-tx.yaml index 4432fea32650..377acce93423 100644 --- a/Documentation/devicetree/bindings/media/amlogic,meson-ir-tx.yaml +++ b/Documentation/devicetree/bindings/media/amlogic,meson-ir-tx.yaml @@ -2,8 +2,8 @@ %YAML 1.2 --- -$id: "http://devicetree.org/schemas/media/amlogic,meson-ir-tx.yaml#" -$schema: "http://devicetree.org/meta-schemas/core.yaml#" +$id: http://devicetree.org/schemas/media/amlogic,meson-ir-tx.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# title: Amlogic Meson IR transmitter diff --git a/Documentation/devicetree/bindings/media/amlogic,meson6-ir.yaml b/Documentation/devicetree/bindings/media/amlogic,meson6-ir.yaml new file mode 100644 index 000000000000..3f9fa92703bb --- /dev/null +++ b/Documentation/devicetree/bindings/media/amlogic,meson6-ir.yaml @@ -0,0 +1,47 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/media/amlogic,meson6-ir.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Amlogic Meson IR remote control receiver + +maintainers: + - Neil Armstrong <neil.armstrong@linaro.org> + +allOf: + - $ref: rc.yaml# + +properties: + compatible: + oneOf: + - enum: + - amlogic,meson6-ir + - amlogic,meson8b-ir + - amlogic,meson-gxbb-ir + - items: + - const: amlogic,meson-gx-ir + - const: amlogic,meson-gxbb-ir + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + +required: + - compatible + - reg + - interrupts + +unevaluatedProperties: false + +examples: + - | + #include <dt-bindings/interrupt-controller/irq.h> + #include <dt-bindings/interrupt-controller/arm-gic.h> + ir-receiver@c8100480 { + compatible = "amlogic,meson6-ir"; + reg = <0xc8100480 0x20>; + interrupts = <GIC_SPI 15 IRQ_TYPE_EDGE_RISING>; + }; diff --git a/Documentation/devicetree/bindings/media/exynos-fimc-lite.txt b/Documentation/devicetree/bindings/media/exynos-fimc-lite.txt deleted file mode 100644 index 0bf6fb7fbeab..000000000000 --- a/Documentation/devicetree/bindings/media/exynos-fimc-lite.txt +++ /dev/null @@ -1,16 +0,0 @@ -Exynos4x12/Exynos5 SoC series camera host interface (FIMC-LITE) - -Required properties: - -- compatible : should be one of: - "samsung,exynos4212-fimc-lite" for Exynos4212/4412 SoCs, - "samsung,exynos5250-fimc-lite" for Exynos5250 compatible - devices; -- reg : physical base address and size of the device memory mapped - registers; -- interrupts : should contain FIMC-LITE interrupt; -- clocks : FIMC LITE gate clock should be specified in this property. -- clock-names : should contain "flite" entry. - -Each FIMC device should have an alias in the aliases node, in the form of -fimc-lite<n>, where <n> is an integer specifying the IP block instance. diff --git a/Documentation/devicetree/bindings/media/exynos4-fimc-is.txt b/Documentation/devicetree/bindings/media/exynos4-fimc-is.txt deleted file mode 100644 index 32ced99d4244..000000000000 --- a/Documentation/devicetree/bindings/media/exynos4-fimc-is.txt +++ /dev/null @@ -1,50 +0,0 @@ -Exynos4x12 SoC series Imaging Subsystem (FIMC-IS) - -The FIMC-IS is a subsystem for processing image signal from an image sensor. -The Exynos4x12 SoC series FIMC-IS V1.5 comprises of a dedicated ARM Cortex-A5 -processor, ISP, DRC and FD IP blocks and peripheral devices such as UART, I2C -and SPI bus controllers, PWM and ADC. - -fimc-is node ------------- - -Required properties: -- compatible : should be "samsung,exynos4212-fimc-is" for Exynos4212 and - Exynos4412 SoCs; -- reg : physical base address and length of the registers set; -- interrupts : must contain two FIMC-IS interrupts, in order: ISP0, ISP1; -- clocks : list of clock specifiers, corresponding to entries in - clock-names property; -- clock-names : must contain "ppmuispx", "ppmuispx", "lite0", "lite1" - "mpll", "sysreg", "isp", "drc", "fd", "mcuisp", "gicisp", - "pwm_isp", "mcuctl_isp", "uart", "ispdiv0", "ispdiv1", - "mcuispdiv0", "mcuispdiv1", "aclk200", "div_aclk200", - "aclk400mcuisp", "div_aclk400mcuisp" entries, - matching entries in the clocks property. -pmu subnode ------------ - -Required properties: - - reg : must contain PMU physical base address and size of the register set. - -The following are the FIMC-IS peripheral device nodes and can be specified -either standalone or as the fimc-is node child nodes. - -i2c-isp (ISP I2C bus controller) nodes ------------------------------------------- - -Required properties: - -- compatible : should be "samsung,exynos4212-i2c-isp" for Exynos4212 and - Exynos4412 SoCs; -- reg : physical base address and length of the registers set; -- clocks : must contain gate clock specifier for this controller; -- clock-names : must contain "i2c_isp" entry. - -For the above nodes it is required to specify a pinctrl state named "default", -according to the pinctrl bindings defined in ../pinctrl/pinctrl-bindings.txt. - -Device tree nodes of the image sensors' controlled directly by the FIMC-IS -firmware must be child nodes of their corresponding ISP I2C bus controller node. -The data link of these image sensors must be specified using the common video -interfaces bindings, defined in video-interfaces.txt. diff --git a/Documentation/devicetree/bindings/media/gpio-ir-receiver.yaml b/Documentation/devicetree/bindings/media/gpio-ir-receiver.yaml index 61072745b983..008c007ed702 100644 --- a/Documentation/devicetree/bindings/media/gpio-ir-receiver.yaml +++ b/Documentation/devicetree/bindings/media/gpio-ir-receiver.yaml @@ -23,6 +23,9 @@ properties: description: autosuspend delay time in milliseconds $ref: /schemas/types.yaml#/definitions/uint32 + wakeup-source: + description: IR receiver can wake-up the system. + required: - compatible - gpios diff --git a/Documentation/devicetree/bindings/media/i2c/chrontel,ch7322.yaml b/Documentation/devicetree/bindings/media/i2c/chrontel,ch7322.yaml index af8ada55b3f2..4e69b6a7ffcc 100644 --- a/Documentation/devicetree/bindings/media/i2c/chrontel,ch7322.yaml +++ b/Documentation/devicetree/bindings/media/i2c/chrontel,ch7322.yaml @@ -1,8 +1,8 @@ # SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) %YAML 1.2 --- -$id: "http://devicetree.org/schemas/media/i2c/chrontel,ch7322.yaml#" -$schema: "http://devicetree.org/meta-schemas/core.yaml#" +$id: http://devicetree.org/schemas/media/i2c/chrontel,ch7322.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# title: Chrontel HDMI-CEC Controller diff --git a/Documentation/devicetree/bindings/media/i2c/dongwoon,dw9768.yaml b/Documentation/devicetree/bindings/media/i2c/dongwoon,dw9768.yaml index 82d3d18c16a1..a0855d3b7577 100644 --- a/Documentation/devicetree/bindings/media/i2c/dongwoon,dw9768.yaml +++ b/Documentation/devicetree/bindings/media/i2c/dongwoon,dw9768.yaml @@ -38,7 +38,7 @@ properties: dongwoon,aac-mode: description: Indication of AAC mode select. - $ref: "/schemas/types.yaml#/definitions/uint32" + $ref: /schemas/types.yaml#/definitions/uint32 enum: - 1 # AAC2 mode(operation time# 0.48 x Tvib) - 2 # AAC3 mode(operation time# 0.70 x Tvib) @@ -50,7 +50,7 @@ properties: description: Number of AAC Timing count that controlled by one 6-bit period of vibration register AACT[5:0], the unit of which is 100 us. - $ref: "/schemas/types.yaml#/definitions/uint32" + $ref: /schemas/types.yaml#/definitions/uint32 default: 0x20 minimum: 0x00 maximum: 0x3f @@ -59,7 +59,7 @@ properties: description: Indication of VCM internal clock dividing rate select, as one multiple factor to calculate VCM ring periodic time Tvib. - $ref: "/schemas/types.yaml#/definitions/uint32" + $ref: /schemas/types.yaml#/definitions/uint32 enum: - 0 # Dividing Rate - 2 - 1 # Dividing Rate - 1 diff --git a/Documentation/devicetree/bindings/media/i2c/maxim,max9286.yaml b/Documentation/devicetree/bindings/media/i2c/maxim,max9286.yaml index 0c4213adbf6a..8df859136047 100644 --- a/Documentation/devicetree/bindings/media/i2c/maxim,max9286.yaml +++ b/Documentation/devicetree/bindings/media/i2c/maxim,max9286.yaml @@ -86,7 +86,7 @@ properties: is 100000 micro volts maxim,gpio-poc: - $ref: '/schemas/types.yaml#/definitions/uint32-array' + $ref: /schemas/types.yaml#/definitions/uint32-array minItems: 2 maxItems: 2 description: | diff --git a/Documentation/devicetree/bindings/media/i2c/ov2685.txt b/Documentation/devicetree/bindings/media/i2c/ov2685.txt deleted file mode 100644 index 625c4a8c0d53..000000000000 --- a/Documentation/devicetree/bindings/media/i2c/ov2685.txt +++ /dev/null @@ -1,41 +0,0 @@ -* Omnivision OV2685 MIPI CSI-2 sensor - -Required Properties: -- compatible: shall be "ovti,ov2685" -- clocks: reference to the xvclk input clock -- clock-names: shall be "xvclk" -- avdd-supply: Analog voltage supply, 2.8 volts -- dovdd-supply: Digital I/O voltage supply, 1.8 volts -- dvdd-supply: Digital core voltage supply, 1.8 volts -- reset-gpios: Low active reset gpio - -The device node shall contain one 'port' child node with an -'endpoint' subnode for its digital output video port, -in accordance with the video interface bindings defined in -Documentation/devicetree/bindings/media/video-interfaces.txt. -The endpoint optional property 'data-lanes' shall be "<1>". - -Example: -&i2c7 { - ov2685: camera-sensor@3c { - compatible = "ovti,ov2685"; - reg = <0x3c>; - pinctrl-names = "default"; - pinctrl-0 = <&clk_24m_cam>; - - clocks = <&cru SCLK_TESTCLKOUT1>; - clock-names = "xvclk"; - - avdd-supply = <&pp2800_cam>; - dovdd-supply = <&pp1800>; - dvdd-supply = <&pp1800>; - reset-gpios = <&gpio2 3 GPIO_ACTIVE_LOW>; - - port { - ucam_out: endpoint { - remote-endpoint = <&mipi_in_ucam>; - data-lanes = <1>; - }; - }; - }; -}; diff --git a/Documentation/devicetree/bindings/media/i2c/ov8856.yaml b/Documentation/devicetree/bindings/media/i2c/ov8856.yaml index e17288d57981..57f5e48fd8e0 100644 --- a/Documentation/devicetree/bindings/media/i2c/ov8856.yaml +++ b/Documentation/devicetree/bindings/media/i2c/ov8856.yaml @@ -8,7 +8,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml# title: Omnivision OV8856 CMOS Sensor maintainers: - - Dongchun Zhu <dongchun.zhu@mediatek.com> + - Sakari Ailus <sakari.ailus@linux.intel.com> description: |- The Omnivision OV8856 is a high performance, 1/4-inch, 8 megapixel, CMOS diff --git a/Documentation/devicetree/bindings/media/i2c/ovti,ov02a10.yaml b/Documentation/devicetree/bindings/media/i2c/ovti,ov02a10.yaml index 54df9d73dc86..763cebe03dc2 100644 --- a/Documentation/devicetree/bindings/media/i2c/ovti,ov02a10.yaml +++ b/Documentation/devicetree/bindings/media/i2c/ovti,ov02a10.yaml @@ -88,7 +88,7 @@ properties: properties: link-frequencies: true ovti,mipi-clock-voltage: - $ref: "/schemas/types.yaml#/definitions/uint32" + $ref: /schemas/types.yaml#/definitions/uint32 description: Definition of MIPI clock voltage unit. This entry corresponds to the link speed defined by the 'link-frequencies' property. diff --git a/Documentation/devicetree/bindings/media/i2c/ovti,ov2685.yaml b/Documentation/devicetree/bindings/media/i2c/ovti,ov2685.yaml new file mode 100644 index 000000000000..8b389314c352 --- /dev/null +++ b/Documentation/devicetree/bindings/media/i2c/ovti,ov2685.yaml @@ -0,0 +1,101 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/media/i2c/ovti,ov2685.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: OmniVision OV2685 Image Sensor + +maintainers: + - Shunqian Zheng <zhengsq@rock-chips.com> + +properties: + compatible: + const: ovti,ov2685 + + reg: + maxItems: 1 + + clocks: + items: + - description: XVCLK clock + + clock-names: + items: + - const: xvclk + + dvdd-supply: + description: Digital Domain Power Supply + + avdd-supply: + description: Analog Domain Power Supply + + dovdd-supply: + description: I/O Domain Power Supply + + reset-gpios: + maxItems: 1 + description: Reset Pin GPIO Control (active low) + + port: + description: MIPI CSI-2 transmitter port + $ref: /schemas/graph.yaml#/$defs/port-base + additionalProperties: false + + properties: + endpoint: + $ref: /schemas/media/video-interfaces.yaml# + unevaluatedProperties: false + + properties: + data-lanes: + maxItems: 2 + + required: + - data-lanes + +required: + - compatible + - reg + - clocks + - clock-names + - dvdd-supply + - avdd-supply + - dovdd-supply + - port + +additionalProperties: false + +examples: + - | + #include <dt-bindings/clock/rk3399-cru.h> + #include <dt-bindings/gpio/gpio.h> + + i2c { + #address-cells = <1>; + #size-cells = <0>; + + ov2685: camera-sensor@3c { + compatible = "ovti,ov2685"; + reg = <0x3c>; + pinctrl-names = "default"; + pinctrl-0 = <&clk_24m_cam>; + + clocks = <&cru SCLK_TESTCLKOUT1>; + clock-names = "xvclk"; + + avdd-supply = <&pp2800_cam>; + dovdd-supply = <&pp1800>; + dvdd-supply = <&pp1800>; + reset-gpios = <&gpio2 3 GPIO_ACTIVE_LOW>; + + port { + ucam_out: endpoint { + remote-endpoint = <&mipi_in_ucam>; + data-lanes = <1>; + }; + }; + }; + }; + +... diff --git a/Documentation/devicetree/bindings/media/i2c/samsung,s5k5baf.yaml b/Documentation/devicetree/bindings/media/i2c/samsung,s5k5baf.yaml new file mode 100644 index 000000000000..c8f2955e0825 --- /dev/null +++ b/Documentation/devicetree/bindings/media/i2c/samsung,s5k5baf.yaml @@ -0,0 +1,101 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/media/i2c/samsung,s5k5baf.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Samsung S5K5BAF UXGA 1/5" 2M CMOS Image Sensor with embedded SoC ISP + +maintainers: + - Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> + +properties: + compatible: + const: samsung,s5k5baf + + reg: + maxItems: 1 + + clocks: + maxItems: 1 + + clock-names: + items: + - const: mclk + + clock-frequency: + default: 24000000 + description: mclk clock frequency + + rstn-gpios: + maxItems: 1 + description: RSTN pin + + stbyn-gpios: + maxItems: 1 + description: STDBYN pin + + vdda-supply: + description: Analog power supply 2.8V (2.6V to 3.0V) + + vddio-supply: + description: I/O power supply 1.8V (1.65V to 1.95V) or 2.8V (2.5V to 3.1V) + + vddreg-supply: + description: + Regulator input power supply 1.8V (1.7V to 1.9V) or 2.8V (2.6V to 3.0) + + port: + $ref: /schemas/graph.yaml#/$defs/port-base + additionalProperties: false + + properties: + endpoint: + $ref: /schemas/media/video-interfaces.yaml# + unevaluatedProperties: false + + properties: + data-lanes: + items: + - const: 1 + +required: + - compatible + - clocks + - clock-names + - rstn-gpios + - stbyn-gpios + - vdda-supply + - vddio-supply + - vddreg-supply + +additionalProperties: false + +examples: + - | + #include <dt-bindings/gpio/gpio.h> + + i2c { + #address-cells = <1>; + #size-cells = <0>; + + sensor@2d { + compatible = "samsung,s5k5baf"; + reg = <0x2d>; + clocks = <&camera 0>; + clock-names = "mclk"; + clock-frequency = <24000000>; + rstn-gpios = <&gpl2 1 GPIO_ACTIVE_LOW>; + stbyn-gpios = <&gpl2 0 GPIO_ACTIVE_LOW>; + vdda-supply = <&cam_io_en_reg>; + vddio-supply = <&vtcam_reg>; + vddreg-supply = <&vt_core_15v_reg>; + + port { + endpoint { + remote-endpoint = <&csis1_ep>; + data-lanes = <1>; + }; + }; + }; + }; diff --git a/Documentation/devicetree/bindings/media/i2c/samsung,s5k6a3.yaml b/Documentation/devicetree/bindings/media/i2c/samsung,s5k6a3.yaml new file mode 100644 index 000000000000..7e83a94124b5 --- /dev/null +++ b/Documentation/devicetree/bindings/media/i2c/samsung,s5k6a3.yaml @@ -0,0 +1,98 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/media/i2c/samsung,s5k6a3.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Samsung S5K6A3(YX) raw image sensor + +maintainers: + - Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> + +description: + S5K6A3(YX) is a raw image sensor with MIPI CSI-2 and CCP2 image data + interfaces and CCI (I2C compatible) control bus. + +properties: + compatible: + const: samsung,s5k6a3 + + reg: + maxItems: 1 + + clocks: + maxItems: 1 + + clock-names: + items: + - const: extclk + + clock-frequency: + default: 24000000 + description: extclk clock frequency + + gpios: + maxItems: 1 + description: GPIO connected to the RESET pin + + afvdd-supply: + description: AF (actuator) voltage supply + + svdda-supply: + description: Core voltage supply + + svddio-supply: + description: I/O voltage supply + + port: + $ref: /schemas/graph.yaml#/$defs/port-base + additionalProperties: false + + properties: + endpoint: + $ref: /schemas/media/video-interfaces.yaml# + unevaluatedProperties: false + + properties: + data-lanes: + items: + - const: 1 + +required: + - compatible + - clocks + - clock-names + - gpios + - afvdd-supply + - svdda-supply + - svddio-supply + +additionalProperties: false + +examples: + - | + #include <dt-bindings/gpio/gpio.h> + + i2c { + #address-cells = <1>; + #size-cells = <0>; + + sensor@10 { + compatible = "samsung,s5k6a3"; + reg = <0x10>; + clock-frequency = <24000000>; + clocks = <&camera 1>; + clock-names = "extclk"; + gpios = <&gpm1 6 GPIO_ACTIVE_LOW>; + afvdd-supply = <&ldo19_reg>; + svdda-supply = <&cam_io_reg>; + svddio-supply = <&ldo19_reg>; + + port { + endpoint { + remote-endpoint = <&csis1_ep>; + data-lanes = <1>; + }; + }; + }; + }; diff --git a/Documentation/devicetree/bindings/media/i2c/sony,imx290.yaml b/Documentation/devicetree/bindings/media/i2c/sony,imx290.yaml index 21377daae026..a531badc16c9 100644 --- a/Documentation/devicetree/bindings/media/i2c/sony,imx290.yaml +++ b/Documentation/devicetree/bindings/media/i2c/sony,imx290.yaml @@ -12,15 +12,26 @@ maintainers: description: |- The Sony IMX290 is a 1/2.8-Inch CMOS Solid-state image sensor with Square - Pixel for Color Cameras. It is programmable through I2C and 4-wire - interfaces. The sensor output is available via CMOS logic parallel SDR - output, Low voltage LVDS DDR output and CSI-2 serial data output. The CSI-2 - bus is the default. No bindings have been defined for the other busses. + Pixel, available in either mono or colour variants. It is programmable + through I2C and 4-wire interfaces. + + The sensor output is available via CMOS logic parallel SDR output, Low voltage + LVDS DDR output and CSI-2 serial data output. The CSI-2 bus is the default. + No bindings have been defined for the other busses. + + imx290lqr is the full model identifier for the colour variant. "sony,imx290" + is treated the same as this as it was the original compatible string. + imx290llr is the mono version of the sensor. properties: compatible: - enum: - - sony,imx290 + oneOf: + - enum: + - sony,imx290lqr # Colour + - sony,imx290llr # Monochrome + - sony,imx327lqr # Colour + - const: sony,imx290 + deprecated: true reg: maxItems: 1 @@ -101,7 +112,7 @@ examples: #size-cells = <0>; imx290: camera-sensor@1a { - compatible = "sony,imx290"; + compatible = "sony,imx290lqr"; reg = <0x1a>; pinctrl-names = "default"; diff --git a/Documentation/devicetree/bindings/media/i2c/sony,imx334.yaml b/Documentation/devicetree/bindings/media/i2c/sony,imx334.yaml index f5055b9db693..09533496b20c 100644 --- a/Documentation/devicetree/bindings/media/i2c/sony,imx334.yaml +++ b/Documentation/devicetree/bindings/media/i2c/sony,imx334.yaml @@ -82,7 +82,7 @@ examples: imx334: endpoint { remote-endpoint = <&cam>; data-lanes = <1 2 3 4>; - link-frequencies = /bits/ 64 <891000000>; + link-frequencies = /bits/ 64 <891000000 445500000>; }; }; }; diff --git a/Documentation/devicetree/bindings/media/mediatek,mdp3-rdma.yaml b/Documentation/devicetree/bindings/media/mediatek,mdp3-rdma.yaml index 9cfc0c7d23e0..7032c7e15039 100644 --- a/Documentation/devicetree/bindings/media/mediatek,mdp3-rdma.yaml +++ b/Documentation/devicetree/bindings/media/mediatek,mdp3-rdma.yaml @@ -27,7 +27,7 @@ properties: maxItems: 1 mediatek,gce-client-reg: - $ref: '/schemas/types.yaml#/definitions/phandle-array' + $ref: /schemas/types.yaml#/definitions/phandle-array items: items: - description: phandle of GCE diff --git a/Documentation/devicetree/bindings/media/mediatek,vcodec-subdev-decoder.yaml b/Documentation/devicetree/bindings/media/mediatek,vcodec-subdev-decoder.yaml index c4f20acdc1f8..dca9b0c5e106 100644 --- a/Documentation/devicetree/bindings/media/mediatek,vcodec-subdev-decoder.yaml +++ b/Documentation/devicetree/bindings/media/mediatek,vcodec-subdev-decoder.yaml @@ -2,8 +2,8 @@ %YAML 1.2 --- -$id: "http://devicetree.org/schemas/media/mediatek,vcodec-subdev-decoder.yaml#" -$schema: "http://devicetree.org/meta-schemas/core.yaml#" +$id: http://devicetree.org/schemas/media/mediatek,vcodec-subdev-decoder.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# title: Mediatek Video Decode Accelerator With Multi Hardware @@ -61,7 +61,10 @@ properties: - mediatek,mt8195-vcodec-dec reg: - maxItems: 1 + minItems: 1 + items: + - description: VDEC_SYS register space + - description: VDEC_RACING_CTRL register space iommus: minItems: 1 @@ -76,11 +79,6 @@ properties: The node of system control processor (SCP), using the remoteproc & rpmsg framework. - dma-ranges: - maxItems: 1 - description: | - Describes the physical address space of IOMMU maps to memory. - "#address-cells": const: 2 @@ -91,17 +89,19 @@ properties: # Required child node: patternProperties: - '^vcodec-lat@[0-9a-f]+$': + '^video-codec@[0-9a-f]+$': type: object properties: compatible: enum: + - mediatek,mtk-vcodec-core - mediatek,mtk-vcodec-lat - mediatek,mtk-vcodec-lat-soc reg: maxItems: 1 + description: VDEC_MISC register space interrupts: maxItems: 1 @@ -114,68 +114,13 @@ patternProperties: Refer to bindings/iommu/mediatek,iommu.yaml. clocks: + minItems: 4 maxItems: 5 clock-names: - items: - - const: sel - - const: soc-vdec - - const: soc-lat - - const: vdec - - const: top - - assigned-clocks: - maxItems: 1 - - assigned-clock-parents: - maxItems: 1 - - power-domains: - maxItems: 1 - - required: - - compatible - - reg - - iommus - - clocks - - clock-names - - assigned-clocks - - assigned-clock-parents - - power-domains - - additionalProperties: false - - '^vcodec-core@[0-9a-f]+$': - type: object - - properties: - compatible: - const: mediatek,mtk-vcodec-core - - reg: - maxItems: 1 - - interrupts: - maxItems: 1 - - iommus: - minItems: 1 - maxItems: 32 - description: | - List of the hardware port in respective IOMMU block for current Socs. - Refer to bindings/iommu/mediatek,iommu.yaml. - - clocks: + minItems: 4 maxItems: 5 - clock-names: - items: - - const: sel - - const: soc-vdec - - const: soc-lat - - const: vdec - - const: top - assigned-clocks: maxItems: 1 @@ -188,7 +133,6 @@ patternProperties: required: - compatible - reg - - interrupts - iommus - clocks - clock-names @@ -203,7 +147,6 @@ required: - reg - iommus - mediatek,scp - - dma-ranges - ranges if: @@ -211,12 +154,45 @@ if: compatible: contains: enum: + - mediatek,mtk-vcodec-core - mediatek,mtk-vcodec-lat then: required: - interrupts +allOf: + - if: + properties: + compatible: + contains: + enum: + - mediatek,mt8192-vcodec-dec + then: + properties: + clock-names: + items: + - const: sel + - const: soc-vdec + - const: soc-lat + - const: vdec + - const: top + + - if: + properties: + compatible: + contains: + enum: + - mediatek,mt8195-vcodec-dec + then: + properties: + clock-names: + items: + - const: sel + - const: vdec + - const: lat + - const: top + additionalProperties: false examples: @@ -236,12 +212,11 @@ examples: compatible = "mediatek,mt8192-vcodec-dec"; mediatek,scp = <&scp>; iommus = <&iommu0 M4U_PORT_L4_VDEC_MC_EXT>; - dma-ranges = <0x1 0x0 0x0 0x40000000 0x0 0xfff00000>; #address-cells = <2>; #size-cells = <2>; ranges = <0 0 0 0x16000000 0 0x40000>; reg = <0 0x16000000 0 0x1000>; /* VDEC_SYS */ - vcodec-lat@10000 { + video-codec@10000 { compatible = "mediatek,mtk-vcodec-lat"; reg = <0 0x10000 0 0x800>; interrupts = <GIC_SPI 426 IRQ_TYPE_LEVEL_HIGH 0>; @@ -264,7 +239,7 @@ examples: power-domains = <&spm MT8192_POWER_DOMAIN_VDEC>; }; - vcodec-core@25000 { + video-codec@25000 { compatible = "mediatek,mtk-vcodec-core"; reg = <0 0x25000 0 0x1000>; interrupts = <GIC_SPI 425 IRQ_TYPE_LEVEL_HIGH 0>; diff --git a/Documentation/devicetree/bindings/media/meson-ir.txt b/Documentation/devicetree/bindings/media/meson-ir.txt deleted file mode 100644 index efd9d29a8f10..000000000000 --- a/Documentation/devicetree/bindings/media/meson-ir.txt +++ /dev/null @@ -1,20 +0,0 @@ -* Amlogic Meson IR remote control receiver - -Required properties: - - compatible : depending on the platform this should be one of: - - "amlogic,meson6-ir" - - "amlogic,meson8b-ir" - - "amlogic,meson-gxbb-ir" - - reg : physical base address and length of the device registers - - interrupts : a single specifier for the interrupt from the device - -Optional properties: - - linux,rc-map-name: see rc.txt file in the same directory. - -Example: - - ir-receiver@c8100480 { - compatible= "amlogic,meson6-ir"; - reg = <0xc8100480 0x20>; - interrupts = <0 15 1>; - }; diff --git a/Documentation/devicetree/bindings/media/microchip,sama5d4-vdec.yaml b/Documentation/devicetree/bindings/media/microchip,sama5d4-vdec.yaml index 4b77103ca913..59b805ca47c5 100644 --- a/Documentation/devicetree/bindings/media/microchip,sama5d4-vdec.yaml +++ b/Documentation/devicetree/bindings/media/microchip,sama5d4-vdec.yaml @@ -2,8 +2,8 @@ %YAML 1.2 --- -$id: "http://devicetree.org/schemas/media/microchip,sama5d4-vdec.yaml#" -$schema: "http://devicetree.org/meta-schemas/core.yaml#" +$id: http://devicetree.org/schemas/media/microchip,sama5d4-vdec.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# title: Hantro G1 VPU codec implemented on Microchip SAMA5D4 SoCs diff --git a/Documentation/devicetree/bindings/media/nxp,imx8-isi.yaml b/Documentation/devicetree/bindings/media/nxp,imx8-isi.yaml new file mode 100644 index 000000000000..6038b9b5ab36 --- /dev/null +++ b/Documentation/devicetree/bindings/media/nxp,imx8-isi.yaml @@ -0,0 +1,173 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/media/nxp,imx8-isi.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: i.MX8 Image Sensing Interface + +maintainers: + - Laurent Pinchart <laurent.pinchart@ideasonboard.com> + +description: | + The Image Sensing Interface (ISI) combines image processing pipelines with + DMA engines to process and capture frames originating from a variety of + sources. The inputs to the ISI go through Pixel Link interfaces, and their + number and nature is SoC-dependent. They cover both capture interfaces (MIPI + CSI-2 RX, HDMI RX, ...) and display engine outputs for writeback support. + +properties: + compatible: + enum: + - fsl,imx8mn-isi + - fsl,imx8mp-isi + + reg: + maxItems: 1 + + clocks: + items: + - description: The AXI clock + - description: The APB clock + # TODO: Check if the per-channel ipg_proc_clk clocks need to be specified + # as well, in case some SoCs have the ability to control them separately. + # This may be the case of the i.MX8[DQ]X(P) + + clock-names: + items: + - const: axi + - const: apb + + fsl,blk-ctrl: + $ref: /schemas/types.yaml#/definitions/phandle + description: + A phandle referencing the block control that contains the CSIS to ISI + gasket. + + interrupts: + description: Processing pipeline interrupts, one per pipeline + minItems: 1 + maxItems: 2 + + power-domains: + maxItems: 1 + + ports: + $ref: /schemas/graph.yaml#/properties/ports + description: | + Ports represent the Pixel Link inputs to the ISI. Their number and + assignment are model-dependent. Each port shall have a single endpoint. + +required: + - compatible + - reg + - interrupts + - clocks + - clock-names + - fsl,blk-ctrl + - ports + +allOf: + - if: + properties: + compatible: + contains: + const: fsl,imx8mn-isi + then: + properties: + interrupts: + maxItems: 1 + ports: + properties: + port@0: + description: MIPI CSI-2 RX + required: + - port@0 + + - if: + properties: + compatible: + contains: + const: fsl,imx8mp-isi + then: + properties: + interrupts: + maxItems: 2 + ports: + properties: + port@0: + description: MIPI CSI-2 RX 0 + port@1: + description: MIPI CSI-2 RX 1 + required: + - port@0 + - port@1 + +additionalProperties: false + +examples: + - | + #include <dt-bindings/clock/imx8mn-clock.h> + #include <dt-bindings/interrupt-controller/arm-gic.h> + #include <dt-bindings/interrupt-controller/irq.h> + #include <dt-bindings/power/imx8mn-power.h> + + isi@32e20000 { + compatible = "fsl,imx8mn-isi"; + reg = <0x32e20000 0x100>; + interrupts = <GIC_SPI 16 IRQ_TYPE_LEVEL_HIGH>; + clocks = <&clk IMX8MN_CLK_DISP_AXI_ROOT>, + <&clk IMX8MN_CLK_DISP_APB_ROOT>; + clock-names = "axi", "apb"; + fsl,blk-ctrl = <&disp_blk_ctrl>; + power-domains = <&disp_blk_ctrl IMX8MN_DISPBLK_PD_ISI>; + + ports { + #address-cells = <1>; + #size-cells = <0>; + + port@0 { + reg = <0>; + isi_in: endpoint { + remote-endpoint = <&mipi_csi_out>; + }; + }; + }; + }; + + - | + #include <dt-bindings/clock/imx8mp-clock.h> + #include <dt-bindings/interrupt-controller/arm-gic.h> + #include <dt-bindings/interrupt-controller/irq.h> + + isi@32e00000 { + compatible = "fsl,imx8mp-isi"; + reg = <0x32e00000 0x4000>; + interrupts = <GIC_SPI 16 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 42 IRQ_TYPE_LEVEL_HIGH>; + clocks = <&clk IMX8MP_CLK_MEDIA_AXI_ROOT>, + <&clk IMX8MP_CLK_MEDIA_APB_ROOT>; + clock-names = "axi", "apb"; + fsl,blk-ctrl = <&media_blk_ctrl>; + power-domains = <&mediamix_pd>; + + ports { + #address-cells = <1>; + #size-cells = <0>; + + port@0 { + reg = <0>; + isi_in_0: endpoint { + remote-endpoint = <&mipi_csi_0_out>; + }; + }; + + port@1 { + reg = <1>; + isi_in_1: endpoint { + remote-endpoint = <&mipi_csi_1_out>; + }; + }; + }; + }; +... diff --git a/Documentation/devicetree/bindings/media/nxp,imx8mq-vpu.yaml b/Documentation/devicetree/bindings/media/nxp,imx8mq-vpu.yaml index 7dc13a4b1805..3d58f02b0c5d 100644 --- a/Documentation/devicetree/bindings/media/nxp,imx8mq-vpu.yaml +++ b/Documentation/devicetree/bindings/media/nxp,imx8mq-vpu.yaml @@ -2,8 +2,8 @@ %YAML 1.2 --- -$id: "http://devicetree.org/schemas/media/nxp,imx8mq-vpu.yaml#" -$schema: "http://devicetree.org/meta-schemas/core.yaml#" +$id: http://devicetree.org/schemas/media/nxp,imx8mq-vpu.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# title: Hantro G1/G2 VPU codecs implemented on i.MX8M SoCs diff --git a/Documentation/devicetree/bindings/media/qcom,msm8916-camss.yaml b/Documentation/devicetree/bindings/media/qcom,msm8916-camss.yaml index 12ec3e1ea869..eb1499912c58 100644 --- a/Documentation/devicetree/bindings/media/qcom,msm8916-camss.yaml +++ b/Documentation/devicetree/bindings/media/qcom,msm8916-camss.yaml @@ -2,8 +2,8 @@ %YAML 1.2 --- -$id: "http://devicetree.org/schemas/media/qcom,msm8916-camss.yaml#" -$schema: "http://devicetree.org/meta-schemas/core.yaml#" +$id: http://devicetree.org/schemas/media/qcom,msm8916-camss.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# title: Qualcomm CAMSS ISP diff --git a/Documentation/devicetree/bindings/media/qcom,msm8916-venus.yaml b/Documentation/devicetree/bindings/media/qcom,msm8916-venus.yaml index 2abb7d21c0d1..2350bf4b370e 100644 --- a/Documentation/devicetree/bindings/media/qcom,msm8916-venus.yaml +++ b/Documentation/devicetree/bindings/media/qcom,msm8916-venus.yaml @@ -1,11 +1,10 @@ # SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) - %YAML 1.2 --- -$id: "http://devicetree.org/schemas/media/qcom,msm8916-venus.yaml#" -$schema: "http://devicetree.org/meta-schemas/core.yaml#" +$id: http://devicetree.org/schemas/media/qcom,msm8916-venus.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# -title: Qualcomm Venus video encode and decode accelerators +title: Qualcomm MSM8916 Venus video encode and decode accelerators maintainers: - Stanimir Varbanov <stanimir.varbanov@linaro.org> @@ -14,16 +13,13 @@ description: | The Venus IP is a video encode and decode accelerator present on Qualcomm platforms +allOf: + - $ref: qcom,venus-common.yaml# + properties: compatible: const: qcom,msm8916-venus - reg: - maxItems: 1 - - interrupts: - maxItems: 1 - power-domains: maxItems: 1 @@ -39,9 +35,6 @@ properties: iommus: maxItems: 1 - memory-region: - maxItems: 1 - video-decoder: type: object @@ -66,57 +59,36 @@ properties: additionalProperties: false - video-firmware: - type: object - additionalProperties: false - - description: | - Firmware subnode is needed when the platform does not - have TrustZone. - - properties: - iommus: - maxItems: 1 - - required: - - iommus - required: - compatible - - reg - - interrupts - - power-domains - - clocks - - clock-names - iommus - - memory-region - video-decoder - video-encoder -additionalProperties: false +unevaluatedProperties: false examples: - | - #include <dt-bindings/interrupt-controller/arm-gic.h> - #include <dt-bindings/clock/qcom,gcc-msm8916.h> - - video-codec@1d00000 { - compatible = "qcom,msm8916-venus"; - reg = <0x01d00000 0xff000>; - interrupts = <GIC_SPI 44 IRQ_TYPE_LEVEL_HIGH>; - clocks = <&gcc GCC_VENUS0_VCODEC0_CLK>, - <&gcc GCC_VENUS0_AHB_CLK>, - <&gcc GCC_VENUS0_AXI_CLK>; - clock-names = "core", "iface", "bus"; - power-domains = <&gcc VENUS_GDSC>; - iommus = <&apps_iommu 5>; - memory-region = <&venus_mem>; - - video-decoder { - compatible = "venus-decoder"; - }; - - video-encoder { - compatible = "venus-encoder"; - }; + #include <dt-bindings/interrupt-controller/arm-gic.h> + #include <dt-bindings/clock/qcom,gcc-msm8916.h> + + video-codec@1d00000 { + compatible = "qcom,msm8916-venus"; + reg = <0x01d00000 0xff000>; + interrupts = <GIC_SPI 44 IRQ_TYPE_LEVEL_HIGH>; + clocks = <&gcc GCC_VENUS0_VCODEC0_CLK>, + <&gcc GCC_VENUS0_AHB_CLK>, + <&gcc GCC_VENUS0_AXI_CLK>; + clock-names = "core", "iface", "bus"; + power-domains = <&gcc VENUS_GDSC>; + iommus = <&apps_iommu 5>; + memory-region = <&venus_mem>; + + video-decoder { + compatible = "venus-decoder"; + }; + + video-encoder { + compatible = "venus-encoder"; }; + }; diff --git a/Documentation/devicetree/bindings/media/qcom,msm8996-camss.yaml b/Documentation/devicetree/bindings/media/qcom,msm8996-camss.yaml index 6aeb3d6d02d5..8a10aa1cafc5 100644 --- a/Documentation/devicetree/bindings/media/qcom,msm8996-camss.yaml +++ b/Documentation/devicetree/bindings/media/qcom,msm8996-camss.yaml @@ -2,8 +2,8 @@ %YAML 1.2 --- -$id: "http://devicetree.org/schemas/media/qcom,msm8996-camss.yaml#" -$schema: "http://devicetree.org/meta-schemas/core.yaml#" +$id: http://devicetree.org/schemas/media/qcom,msm8996-camss.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# title: Qualcomm CAMSS ISP diff --git a/Documentation/devicetree/bindings/media/qcom,msm8996-venus.yaml b/Documentation/devicetree/bindings/media/qcom,msm8996-venus.yaml index 29d0cb6c6ebe..3a4d817e544e 100644 --- a/Documentation/devicetree/bindings/media/qcom,msm8996-venus.yaml +++ b/Documentation/devicetree/bindings/media/qcom,msm8996-venus.yaml @@ -1,11 +1,10 @@ # SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) - %YAML 1.2 --- -$id: "http://devicetree.org/schemas/media/qcom,msm8996-venus.yaml#" -$schema: "http://devicetree.org/meta-schemas/core.yaml#" +$id: http://devicetree.org/schemas/media/qcom,msm8996-venus.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# -title: Qualcomm Venus video encode and decode accelerators +title: Qualcomm MSM8996 Venus video encode and decode accelerators maintainers: - Stanimir Varbanov <stanimir.varbanov@linaro.org> @@ -14,16 +13,13 @@ description: | The Venus IP is a video encode and decode accelerator present on Qualcomm platforms +allOf: + - $ref: qcom,venus-common.yaml# + properties: compatible: const: qcom,msm8996-venus - reg: - maxItems: 1 - - interrupts: - maxItems: 1 - power-domains: maxItems: 1 @@ -37,12 +33,17 @@ properties: - const: bus - const: mbus + interconnects: + maxItems: 2 + + interconnect-names: + items: + - const: video-mem + - const: cpu-cfg + iommus: maxItems: 20 - memory-region: - maxItems: 1 - video-decoder: type: object @@ -93,83 +94,62 @@ properties: additionalProperties: false - video-firmware: - type: object - additionalProperties: false - - description: | - Firmware subnode is needed when the platform does not - have TrustZone. - - properties: - iommus: - maxItems: 1 - - required: - - iommus - required: - compatible - - reg - - interrupts - - power-domains - - clocks - - clock-names - iommus - - memory-region - video-decoder - video-encoder -additionalProperties: false +unevaluatedProperties: false examples: - | - #include <dt-bindings/interrupt-controller/arm-gic.h> - #include <dt-bindings/clock/qcom,mmcc-msm8996.h> - - video-codec@c00000 { - compatible = "qcom,msm8996-venus"; - reg = <0x00c00000 0xff000>; - interrupts = <GIC_SPI 287 IRQ_TYPE_LEVEL_HIGH>; - clocks = <&mmcc VIDEO_CORE_CLK>, - <&mmcc VIDEO_AHB_CLK>, - <&mmcc VIDEO_AXI_CLK>, - <&mmcc VIDEO_MAXI_CLK>; - clock-names = "core", "iface", "bus", "mbus"; - power-domains = <&mmcc VENUS_GDSC>; - iommus = <&venus_smmu 0x00>, - <&venus_smmu 0x01>, - <&venus_smmu 0x0a>, - <&venus_smmu 0x07>, - <&venus_smmu 0x0e>, - <&venus_smmu 0x0f>, - <&venus_smmu 0x08>, - <&venus_smmu 0x09>, - <&venus_smmu 0x0b>, - <&venus_smmu 0x0c>, - <&venus_smmu 0x0d>, - <&venus_smmu 0x10>, - <&venus_smmu 0x11>, - <&venus_smmu 0x21>, - <&venus_smmu 0x28>, - <&venus_smmu 0x29>, - <&venus_smmu 0x2b>, - <&venus_smmu 0x2c>, - <&venus_smmu 0x2d>, - <&venus_smmu 0x31>; - memory-region = <&venus_mem>; - - video-decoder { - compatible = "venus-decoder"; - clocks = <&mmcc VIDEO_SUBCORE0_CLK>; - clock-names = "core"; - power-domains = <&mmcc VENUS_CORE0_GDSC>; - }; - - video-encoder { - compatible = "venus-encoder"; - clocks = <&mmcc VIDEO_SUBCORE1_CLK>; - clock-names = "core"; - power-domains = <&mmcc VENUS_CORE1_GDSC>; - }; + #include <dt-bindings/interrupt-controller/arm-gic.h> + #include <dt-bindings/clock/qcom,mmcc-msm8996.h> + + video-codec@c00000 { + compatible = "qcom,msm8996-venus"; + reg = <0x00c00000 0xff000>; + interrupts = <GIC_SPI 287 IRQ_TYPE_LEVEL_HIGH>; + clocks = <&mmcc VIDEO_CORE_CLK>, + <&mmcc VIDEO_AHB_CLK>, + <&mmcc VIDEO_AXI_CLK>, + <&mmcc VIDEO_MAXI_CLK>; + clock-names = "core", "iface", "bus", "mbus"; + power-domains = <&mmcc VENUS_GDSC>; + iommus = <&venus_smmu 0x00>, + <&venus_smmu 0x01>, + <&venus_smmu 0x0a>, + <&venus_smmu 0x07>, + <&venus_smmu 0x0e>, + <&venus_smmu 0x0f>, + <&venus_smmu 0x08>, + <&venus_smmu 0x09>, + <&venus_smmu 0x0b>, + <&venus_smmu 0x0c>, + <&venus_smmu 0x0d>, + <&venus_smmu 0x10>, + <&venus_smmu 0x11>, + <&venus_smmu 0x21>, + <&venus_smmu 0x28>, + <&venus_smmu 0x29>, + <&venus_smmu 0x2b>, + <&venus_smmu 0x2c>, + <&venus_smmu 0x2d>, + <&venus_smmu 0x31>; + memory-region = <&venus_mem>; + + video-decoder { + compatible = "venus-decoder"; + clocks = <&mmcc VIDEO_SUBCORE0_CLK>; + clock-names = "core"; + power-domains = <&mmcc VENUS_CORE0_GDSC>; + }; + + video-encoder { + compatible = "venus-encoder"; + clocks = <&mmcc VIDEO_SUBCORE1_CLK>; + clock-names = "core"; + power-domains = <&mmcc VENUS_CORE1_GDSC>; }; + }; diff --git a/Documentation/devicetree/bindings/media/qcom,sc7180-venus.yaml b/Documentation/devicetree/bindings/media/qcom,sc7180-venus.yaml index 42ee3f06c6be..5cec1d077cda 100644 --- a/Documentation/devicetree/bindings/media/qcom,sc7180-venus.yaml +++ b/Documentation/devicetree/bindings/media/qcom,sc7180-venus.yaml @@ -1,11 +1,10 @@ # SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) - %YAML 1.2 --- -$id: "http://devicetree.org/schemas/media/qcom,sc7180-venus.yaml#" -$schema: "http://devicetree.org/meta-schemas/core.yaml#" +$id: http://devicetree.org/schemas/media/qcom,sc7180-venus.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# -title: Qualcomm Venus video encode and decode accelerators +title: Qualcomm SC7180 Venus video encode and decode accelerators maintainers: - Stanimir Varbanov <stanimir.varbanov@linaro.org> @@ -14,16 +13,13 @@ description: | The Venus IP is a video encode and decode accelerator present on Qualcomm platforms +allOf: + - $ref: qcom,venus-common.yaml# + properties: compatible: const: qcom,sc7180-venus - reg: - maxItems: 1 - - interrupts: - maxItems: 1 - power-domains: minItems: 2 maxItems: 3 @@ -60,6 +56,10 @@ properties: - const: video-mem - const: cpu-cfg + operating-points-v2: true + opp-table: + type: object + video-decoder: type: object @@ -84,63 +84,42 @@ properties: additionalProperties: false - video-firmware: - type: object - additionalProperties: false - - description: | - Firmware subnode is needed when the platform does not - have TrustZone. - - properties: - iommus: - maxItems: 1 - - required: - - iommus - required: - compatible - - reg - - interrupts - - power-domains - power-domain-names - - clocks - - clock-names - iommus - - memory-region - video-decoder - video-encoder -additionalProperties: false +unevaluatedProperties: false examples: - | - #include <dt-bindings/interrupt-controller/arm-gic.h> - #include <dt-bindings/clock/qcom,videocc-sc7180.h> - - venus: video-codec@aa00000 { - compatible = "qcom,sc7180-venus"; - reg = <0x0aa00000 0xff000>; - interrupts = <GIC_SPI 174 IRQ_TYPE_LEVEL_HIGH>; - power-domains = <&videocc VENUS_GDSC>, - <&videocc VCODEC0_GDSC>; - power-domain-names = "venus", "vcodec0"; - clocks = <&videocc VIDEO_CC_VENUS_CTL_CORE_CLK>, - <&videocc VIDEO_CC_VENUS_AHB_CLK>, - <&videocc VIDEO_CC_VENUS_CTL_AXI_CLK>, - <&videocc VIDEO_CC_VCODEC0_CORE_CLK>, - <&videocc VIDEO_CC_VCODEC0_AXI_CLK>; - clock-names = "core", "iface", "bus", - "vcodec0_core", "vcodec0_bus"; - iommus = <&apps_smmu 0x0c00 0x60>; - memory-region = <&venus_mem>; - - video-decoder { - compatible = "venus-decoder"; - }; - - video-encoder { - compatible = "venus-encoder"; - }; + #include <dt-bindings/interrupt-controller/arm-gic.h> + #include <dt-bindings/clock/qcom,videocc-sc7180.h> + + venus: video-codec@aa00000 { + compatible = "qcom,sc7180-venus"; + reg = <0x0aa00000 0xff000>; + interrupts = <GIC_SPI 174 IRQ_TYPE_LEVEL_HIGH>; + power-domains = <&videocc VENUS_GDSC>, + <&videocc VCODEC0_GDSC>; + power-domain-names = "venus", "vcodec0"; + clocks = <&videocc VIDEO_CC_VENUS_CTL_CORE_CLK>, + <&videocc VIDEO_CC_VENUS_AHB_CLK>, + <&videocc VIDEO_CC_VENUS_CTL_AXI_CLK>, + <&videocc VIDEO_CC_VCODEC0_CORE_CLK>, + <&videocc VIDEO_CC_VCODEC0_AXI_CLK>; + clock-names = "core", "iface", "bus", + "vcodec0_core", "vcodec0_bus"; + iommus = <&apps_smmu 0x0c00 0x60>; + memory-region = <&venus_mem>; + + video-decoder { + compatible = "venus-decoder"; + }; + + video-encoder { + compatible = "venus-encoder"; }; + }; diff --git a/Documentation/devicetree/bindings/media/qcom,sc7280-venus.yaml b/Documentation/devicetree/bindings/media/qcom,sc7280-venus.yaml index cf361dd9de08..8f9b6433aeb8 100644 --- a/Documentation/devicetree/bindings/media/qcom,sc7280-venus.yaml +++ b/Documentation/devicetree/bindings/media/qcom,sc7280-venus.yaml @@ -1,11 +1,10 @@ # SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) - %YAML 1.2 --- -$id: "http://devicetree.org/schemas/media/qcom,sc7280-venus.yaml#" -$schema: "http://devicetree.org/meta-schemas/core.yaml#" +$id: http://devicetree.org/schemas/media/qcom,sc7280-venus.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# -title: Qualcomm Venus video encode and decode accelerators +title: Qualcomm SC7280 Venus video encode and decode accelerators maintainers: - Stanimir Varbanov <stanimir.varbanov@linaro.org> @@ -14,16 +13,13 @@ description: | The Venus Iris2 IP is a video encode and decode accelerator present on Qualcomm platforms +allOf: + - $ref: qcom,venus-common.yaml# + properties: compatible: const: qcom,sc7280-venus - reg: - maxItems: 1 - - interrupts: - maxItems: 1 - power-domains: minItems: 2 maxItems: 3 @@ -49,9 +45,6 @@ properties: iommus: maxItems: 2 - memory-region: - maxItems: 1 - interconnects: maxItems: 2 @@ -60,6 +53,10 @@ properties: - const: cpu-cfg - const: video-mem + operating-points-v2: true + opp-table: + type: object + video-decoder: type: object @@ -84,79 +81,58 @@ properties: additionalProperties: false - video-firmware: - type: object - additionalProperties: false - - description: | - Firmware subnode is needed when the platform does not - have TrustZone. - - properties: - iommus: - maxItems: 1 - - required: - - iommus - required: - compatible - - reg - - interrupts - - power-domains - power-domain-names - - clocks - - clock-names - iommus - - memory-region - video-decoder - video-encoder -additionalProperties: false +unevaluatedProperties: false examples: - | - #include <dt-bindings/interrupt-controller/arm-gic.h> - #include <dt-bindings/clock/qcom,videocc-sc7280.h> - #include <dt-bindings/interconnect/qcom,sc7280.h> - #include <dt-bindings/power/qcom-rpmpd.h> - - venus: video-codec@aa00000 { - compatible = "qcom,sc7280-venus"; - reg = <0x0aa00000 0xd0600>; - interrupts = <GIC_SPI 174 IRQ_TYPE_LEVEL_HIGH>; - - clocks = <&videocc VIDEO_CC_MVSC_CORE_CLK>, - <&videocc VIDEO_CC_MVSC_CTL_AXI_CLK>, - <&videocc VIDEO_CC_VENUS_AHB_CLK>, - <&videocc VIDEO_CC_MVS0_CORE_CLK>, - <&videocc VIDEO_CC_MVS0_AXI_CLK>; - clock-names = "core", "bus", "iface", - "vcodec_core", "vcodec_bus"; - - power-domains = <&videocc MVSC_GDSC>, - <&videocc MVS0_GDSC>, - <&rpmhpd SC7280_CX>; - power-domain-names = "venus", "vcodec0", "cx"; - - interconnects = <&gem_noc MASTER_APPSS_PROC 0 &cnoc2 SLAVE_VENUS_CFG 0>, - <&mmss_noc MASTER_VIDEO_P0 0 &mc_virt SLAVE_EBI1 0>; - interconnect-names = "cpu-cfg", "video-mem"; - - iommus = <&apps_smmu 0x2180 0x20>, - <&apps_smmu 0x2184 0x20>; - - memory-region = <&video_mem>; - - video-decoder { - compatible = "venus-decoder"; - }; - - video-encoder { - compatible = "venus-encoder"; - }; - - video-firmware { - iommus = <&apps_smmu 0x21a2 0x0>; - }; + #include <dt-bindings/interrupt-controller/arm-gic.h> + #include <dt-bindings/clock/qcom,videocc-sc7280.h> + #include <dt-bindings/interconnect/qcom,sc7280.h> + #include <dt-bindings/power/qcom-rpmpd.h> + + venus: video-codec@aa00000 { + compatible = "qcom,sc7280-venus"; + reg = <0x0aa00000 0xd0600>; + interrupts = <GIC_SPI 174 IRQ_TYPE_LEVEL_HIGH>; + + clocks = <&videocc VIDEO_CC_MVSC_CORE_CLK>, + <&videocc VIDEO_CC_MVSC_CTL_AXI_CLK>, + <&videocc VIDEO_CC_VENUS_AHB_CLK>, + <&videocc VIDEO_CC_MVS0_CORE_CLK>, + <&videocc VIDEO_CC_MVS0_AXI_CLK>; + clock-names = "core", "bus", "iface", + "vcodec_core", "vcodec_bus"; + + power-domains = <&videocc MVSC_GDSC>, + <&videocc MVS0_GDSC>, + <&rpmhpd SC7280_CX>; + power-domain-names = "venus", "vcodec0", "cx"; + + interconnects = <&gem_noc MASTER_APPSS_PROC 0 &cnoc2 SLAVE_VENUS_CFG 0>, + <&mmss_noc MASTER_VIDEO_P0 0 &mc_virt SLAVE_EBI1 0>; + interconnect-names = "cpu-cfg", "video-mem"; + + iommus = <&apps_smmu 0x2180 0x20>, + <&apps_smmu 0x2184 0x20>; + + memory-region = <&video_mem>; + + video-decoder { + compatible = "venus-decoder"; + }; + + video-encoder { + compatible = "venus-encoder"; + }; + + video-firmware { + iommus = <&apps_smmu 0x21a2 0x0>; }; + }; diff --git a/Documentation/devicetree/bindings/media/qcom,sdm660-camss.yaml b/Documentation/devicetree/bindings/media/qcom,sdm660-camss.yaml index b28c8e17f158..0a109e126064 100644 --- a/Documentation/devicetree/bindings/media/qcom,sdm660-camss.yaml +++ b/Documentation/devicetree/bindings/media/qcom,sdm660-camss.yaml @@ -2,8 +2,8 @@ %YAML 1.2 --- -$id: "http://devicetree.org/schemas/media/qcom,sdm660-camss.yaml#" -$schema: "http://devicetree.org/meta-schemas/core.yaml#" +$id: http://devicetree.org/schemas/media/qcom,sdm660-camss.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# title: Qualcomm CAMSS ISP diff --git a/Documentation/devicetree/bindings/media/qcom,sdm660-venus.yaml b/Documentation/devicetree/bindings/media/qcom,sdm660-venus.yaml index 45e3f58f52bd..a51835b22045 100644 --- a/Documentation/devicetree/bindings/media/qcom,sdm660-venus.yaml +++ b/Documentation/devicetree/bindings/media/qcom,sdm660-venus.yaml @@ -1,11 +1,10 @@ # SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) - %YAML 1.2 --- -$id: "http://devicetree.org/schemas/media/qcom,sdm660-venus.yaml#" -$schema: "http://devicetree.org/meta-schemas/core.yaml#" +$id: http://devicetree.org/schemas/media/qcom,sdm660-venus.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# -title: Qualcomm Venus video encode and decode accelerators +title: Qualcomm SDM660 Venus video encode and decode accelerators maintainers: - Stanimir Varbanov <stanimir.varbanov@linaro.org> @@ -15,13 +14,13 @@ description: | The Venus IP is a video encode and decode accelerator present on Qualcomm platforms +allOf: + - $ref: qcom,venus-common.yaml# + properties: compatible: const: qcom,sdm660-venus - reg: - maxItems: 1 - clocks: maxItems: 4 @@ -40,15 +39,9 @@ properties: - const: cpu-cfg - const: video-mem - interrupts: - maxItems: 1 - iommus: maxItems: 20 - memory-region: - maxItems: 1 - power-domains: maxItems: 1 @@ -102,86 +95,65 @@ properties: additionalProperties: false - video-firmware: - type: object - additionalProperties: false - - description: | - Firmware subnode is needed when the platform does not - have TrustZone. - - properties: - iommus: - maxItems: 1 - - required: - - iommus - required: - compatible - - reg - - clocks - - clock-names - - interrupts - iommus - - memory-region - - power-domains - video-decoder - video-encoder -additionalProperties: false +unevaluatedProperties: false examples: - | - #include <dt-bindings/clock/qcom,mmcc-sdm660.h> - #include <dt-bindings/interrupt-controller/arm-gic.h> - - video-codec@cc00000 { - compatible = "qcom,sdm660-venus"; - reg = <0x0cc00000 0xff000>; - clocks = <&mmcc VIDEO_CORE_CLK>, - <&mmcc VIDEO_AHB_CLK>, - <&mmcc VIDEO_AXI_CLK>, - <&mmcc THROTTLE_VIDEO_AXI_CLK>; - clock-names = "core", "iface", "bus", "bus_throttle"; - interconnects = <&gnoc 0 &mnoc 13>, - <&mnoc 4 &bimc 5>; - interconnect-names = "cpu-cfg", "video-mem"; - interrupts = <GIC_SPI 287 IRQ_TYPE_LEVEL_HIGH>; - iommus = <&mmss_smmu 0x400>, - <&mmss_smmu 0x401>, - <&mmss_smmu 0x40a>, - <&mmss_smmu 0x407>, - <&mmss_smmu 0x40e>, - <&mmss_smmu 0x40f>, - <&mmss_smmu 0x408>, - <&mmss_smmu 0x409>, - <&mmss_smmu 0x40b>, - <&mmss_smmu 0x40c>, - <&mmss_smmu 0x40d>, - <&mmss_smmu 0x410>, - <&mmss_smmu 0x421>, - <&mmss_smmu 0x428>, - <&mmss_smmu 0x429>, - <&mmss_smmu 0x42b>, - <&mmss_smmu 0x42c>, - <&mmss_smmu 0x42d>, - <&mmss_smmu 0x411>, - <&mmss_smmu 0x431>; - memory-region = <&venus_region>; - power-domains = <&mmcc VENUS_GDSC>; - - video-decoder { - compatible = "venus-decoder"; - clocks = <&mmcc VIDEO_SUBCORE0_CLK>; - clock-names = "vcodec0_core"; - power-domains = <&mmcc VENUS_CORE0_GDSC>; - }; - - video-encoder { - compatible = "venus-encoder"; - clocks = <&mmcc VIDEO_SUBCORE0_CLK>; - clock-names = "vcodec0_core"; - power-domains = <&mmcc VENUS_CORE0_GDSC>; - }; + #include <dt-bindings/clock/qcom,mmcc-sdm660.h> + #include <dt-bindings/interrupt-controller/arm-gic.h> + + video-codec@cc00000 { + compatible = "qcom,sdm660-venus"; + reg = <0x0cc00000 0xff000>; + clocks = <&mmcc VIDEO_CORE_CLK>, + <&mmcc VIDEO_AHB_CLK>, + <&mmcc VIDEO_AXI_CLK>, + <&mmcc THROTTLE_VIDEO_AXI_CLK>; + clock-names = "core", "iface", "bus", "bus_throttle"; + interconnects = <&gnoc 0 &mnoc 13>, + <&mnoc 4 &bimc 5>; + interconnect-names = "cpu-cfg", "video-mem"; + interrupts = <GIC_SPI 287 IRQ_TYPE_LEVEL_HIGH>; + iommus = <&mmss_smmu 0x400>, + <&mmss_smmu 0x401>, + <&mmss_smmu 0x40a>, + <&mmss_smmu 0x407>, + <&mmss_smmu 0x40e>, + <&mmss_smmu 0x40f>, + <&mmss_smmu 0x408>, + <&mmss_smmu 0x409>, + <&mmss_smmu 0x40b>, + <&mmss_smmu 0x40c>, + <&mmss_smmu 0x40d>, + <&mmss_smmu 0x410>, + <&mmss_smmu 0x421>, + <&mmss_smmu 0x428>, + <&mmss_smmu 0x429>, + <&mmss_smmu 0x42b>, + <&mmss_smmu 0x42c>, + <&mmss_smmu 0x42d>, + <&mmss_smmu 0x411>, + <&mmss_smmu 0x431>; + memory-region = <&venus_region>; + power-domains = <&mmcc VENUS_GDSC>; + + video-decoder { + compatible = "venus-decoder"; + clocks = <&mmcc VIDEO_SUBCORE0_CLK>; + clock-names = "vcodec0_core"; + power-domains = <&mmcc VENUS_CORE0_GDSC>; + }; + + video-encoder { + compatible = "venus-encoder"; + clocks = <&mmcc VIDEO_SUBCORE0_CLK>; + clock-names = "vcodec0_core"; + power-domains = <&mmcc VENUS_CORE0_GDSC>; }; + }; diff --git a/Documentation/devicetree/bindings/media/qcom,sdm845-camss.yaml b/Documentation/devicetree/bindings/media/qcom,sdm845-camss.yaml index f9a003882f84..1530ad0d80bd 100644 --- a/Documentation/devicetree/bindings/media/qcom,sdm845-camss.yaml +++ b/Documentation/devicetree/bindings/media/qcom,sdm845-camss.yaml @@ -2,8 +2,8 @@ %YAML 1.2 --- -$id: "http://devicetree.org/schemas/media/qcom,sdm845-camss.yaml#" -$schema: "http://devicetree.org/meta-schemas/core.yaml#" +$id: http://devicetree.org/schemas/media/qcom,sdm845-camss.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# title: Qualcomm CAMSS ISP diff --git a/Documentation/devicetree/bindings/media/qcom,sdm845-venus-v2.yaml b/Documentation/devicetree/bindings/media/qcom,sdm845-venus-v2.yaml index 8edc8a2f43a5..d5f80976f4cf 100644 --- a/Documentation/devicetree/bindings/media/qcom,sdm845-venus-v2.yaml +++ b/Documentation/devicetree/bindings/media/qcom,sdm845-venus-v2.yaml @@ -1,11 +1,10 @@ # SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) - %YAML 1.2 --- -$id: "http://devicetree.org/schemas/media/qcom,sdm845-venus-v2.yaml#" -$schema: "http://devicetree.org/meta-schemas/core.yaml#" +$id: http://devicetree.org/schemas/media/qcom,sdm845-venus-v2.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# -title: Qualcomm Venus video encode and decode accelerators +title: Qualcomm SDM845 Venus v2 video encode and decode accelerators maintainers: - Stanimir Varbanov <stanimir.varbanov@linaro.org> @@ -14,16 +13,13 @@ description: | The Venus IP is a video encode and decode accelerator present on Qualcomm platforms +allOf: + - $ref: qcom,venus-common.yaml# + properties: compatible: const: qcom,sdm845-venus-v2 - reg: - maxItems: 1 - - interrupts: - maxItems: 1 - power-domains: minItems: 3 maxItems: 4 @@ -52,8 +48,9 @@ properties: iommus: maxItems: 2 - memory-region: - maxItems: 1 + operating-points-v2: true + opp-table: + type: object video-core0: type: object @@ -79,68 +76,47 @@ properties: additionalProperties: false - video-firmware: - type: object - additionalProperties: false - - description: | - Firmware subnode is needed when the platform does not - have TrustZone. - - properties: - iommus: - maxItems: 1 - - required: - - iommus - required: - compatible - - reg - - interrupts - - power-domains - power-domain-names - - clocks - - clock-names - iommus - - memory-region - video-core0 - video-core1 -additionalProperties: false +unevaluatedProperties: false examples: - | - #include <dt-bindings/interrupt-controller/arm-gic.h> - #include <dt-bindings/clock/qcom,videocc-sdm845.h> - - video-codec@aa00000 { - compatible = "qcom,sdm845-venus-v2"; - reg = <0x0aa00000 0xff000>; - interrupts = <GIC_SPI 174 IRQ_TYPE_LEVEL_HIGH>; - clocks = <&videocc VIDEO_CC_VENUS_CTL_CORE_CLK>, - <&videocc VIDEO_CC_VENUS_AHB_CLK>, - <&videocc VIDEO_CC_VENUS_CTL_AXI_CLK>, - <&videocc VIDEO_CC_VCODEC0_CORE_CLK>, - <&videocc VIDEO_CC_VCODEC0_AXI_CLK>, - <&videocc VIDEO_CC_VCODEC1_CORE_CLK>, - <&videocc VIDEO_CC_VCODEC1_AXI_CLK>; - clock-names = "core", "iface", "bus", - "vcodec0_core", "vcodec0_bus", - "vcodec1_core", "vcodec1_bus"; - power-domains = <&videocc VENUS_GDSC>, - <&videocc VCODEC0_GDSC>, - <&videocc VCODEC1_GDSC>; - power-domain-names = "venus", "vcodec0", "vcodec1"; - iommus = <&apps_smmu 0x10a0 0x8>, - <&apps_smmu 0x10b0 0x0>; - memory-region = <&venus_mem>; - - video-core0 { - compatible = "venus-decoder"; - }; - - video-core1 { - compatible = "venus-encoder"; - }; + #include <dt-bindings/interrupt-controller/arm-gic.h> + #include <dt-bindings/clock/qcom,videocc-sdm845.h> + + video-codec@aa00000 { + compatible = "qcom,sdm845-venus-v2"; + reg = <0x0aa00000 0xff000>; + interrupts = <GIC_SPI 174 IRQ_TYPE_LEVEL_HIGH>; + clocks = <&videocc VIDEO_CC_VENUS_CTL_CORE_CLK>, + <&videocc VIDEO_CC_VENUS_AHB_CLK>, + <&videocc VIDEO_CC_VENUS_CTL_AXI_CLK>, + <&videocc VIDEO_CC_VCODEC0_CORE_CLK>, + <&videocc VIDEO_CC_VCODEC0_AXI_CLK>, + <&videocc VIDEO_CC_VCODEC1_CORE_CLK>, + <&videocc VIDEO_CC_VCODEC1_AXI_CLK>; + clock-names = "core", "iface", "bus", + "vcodec0_core", "vcodec0_bus", + "vcodec1_core", "vcodec1_bus"; + power-domains = <&videocc VENUS_GDSC>, + <&videocc VCODEC0_GDSC>, + <&videocc VCODEC1_GDSC>; + power-domain-names = "venus", "vcodec0", "vcodec1"; + iommus = <&apps_smmu 0x10a0 0x8>, + <&apps_smmu 0x10b0 0x0>; + memory-region = <&venus_mem>; + + video-core0 { + compatible = "venus-decoder"; + }; + + video-core1 { + compatible = "venus-encoder"; }; + }; diff --git a/Documentation/devicetree/bindings/media/qcom,sdm845-venus.yaml b/Documentation/devicetree/bindings/media/qcom,sdm845-venus.yaml index 57d503373efe..eabc0957b241 100644 --- a/Documentation/devicetree/bindings/media/qcom,sdm845-venus.yaml +++ b/Documentation/devicetree/bindings/media/qcom,sdm845-venus.yaml @@ -1,11 +1,10 @@ # SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) - %YAML 1.2 --- -$id: "http://devicetree.org/schemas/media/qcom,sdm845-venus.yaml#" -$schema: "http://devicetree.org/meta-schemas/core.yaml#" +$id: http://devicetree.org/schemas/media/qcom,sdm845-venus.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# -title: Qualcomm Venus video encode and decode accelerators +title: Qualcomm SDM845 Venus video encode and decode accelerators maintainers: - Stanimir Varbanov <stanimir.varbanov@linaro.org> @@ -14,16 +13,13 @@ description: | The Venus IP is a video encode and decode accelerator present on Qualcomm platforms +allOf: + - $ref: qcom,venus-common.yaml# + properties: compatible: const: qcom,sdm845-venus - reg: - maxItems: 1 - - interrupts: - maxItems: 1 - power-domains: maxItems: 1 @@ -39,9 +35,6 @@ properties: iommus: maxItems: 2 - memory-region: - maxItems: 1 - video-core0: type: object @@ -94,66 +87,45 @@ properties: additionalProperties: false - video-firmware: - type: object - additionalProperties: false - - description: | - Firmware subnode is needed when the platform does not - have TrustZone. - - properties: - iommus: - maxItems: 1 - - required: - - iommus - required: - compatible - - reg - - interrupts - - power-domains - - clocks - - clock-names - iommus - - memory-region - video-core0 - video-core1 -additionalProperties: false +unevaluatedProperties: false examples: - | - #include <dt-bindings/interrupt-controller/arm-gic.h> - #include <dt-bindings/clock/qcom,videocc-sdm845.h> - - video-codec@aa00000 { - compatible = "qcom,sdm845-venus"; - reg = <0x0aa00000 0xff000>; - interrupts = <GIC_SPI 174 IRQ_TYPE_LEVEL_HIGH>; - clocks = <&videocc VIDEO_CC_VENUS_CTL_CORE_CLK>, - <&videocc VIDEO_CC_VENUS_AHB_CLK>, - <&videocc VIDEO_CC_VENUS_CTL_AXI_CLK>; - clock-names = "core", "iface", "bus"; - power-domains = <&videocc VENUS_GDSC>; - iommus = <&apps_smmu 0x10a0 0x8>, - <&apps_smmu 0x10b0 0x0>; - memory-region = <&venus_mem>; - - video-core0 { - compatible = "venus-decoder"; - clocks = <&videocc VIDEO_CC_VCODEC0_CORE_CLK>, - <&videocc VIDEO_CC_VCODEC0_AXI_CLK>; - clock-names = "core", "bus"; - power-domains = <&videocc VCODEC0_GDSC>; - }; - - video-core1 { - compatible = "venus-encoder"; - clocks = <&videocc VIDEO_CC_VCODEC1_CORE_CLK>, - <&videocc VIDEO_CC_VCODEC1_AXI_CLK>; - clock-names = "core", "bus"; - power-domains = <&videocc VCODEC1_GDSC>; - }; + #include <dt-bindings/interrupt-controller/arm-gic.h> + #include <dt-bindings/clock/qcom,videocc-sdm845.h> + + video-codec@aa00000 { + compatible = "qcom,sdm845-venus"; + reg = <0x0aa00000 0xff000>; + interrupts = <GIC_SPI 174 IRQ_TYPE_LEVEL_HIGH>; + clocks = <&videocc VIDEO_CC_VENUS_CTL_CORE_CLK>, + <&videocc VIDEO_CC_VENUS_AHB_CLK>, + <&videocc VIDEO_CC_VENUS_CTL_AXI_CLK>; + clock-names = "core", "iface", "bus"; + power-domains = <&videocc VENUS_GDSC>; + iommus = <&apps_smmu 0x10a0 0x8>, + <&apps_smmu 0x10b0 0x0>; + memory-region = <&venus_mem>; + + video-core0 { + compatible = "venus-decoder"; + clocks = <&videocc VIDEO_CC_VCODEC0_CORE_CLK>, + <&videocc VIDEO_CC_VCODEC0_AXI_CLK>; + clock-names = "core", "bus"; + power-domains = <&videocc VCODEC0_GDSC>; + }; + + video-core1 { + compatible = "venus-encoder"; + clocks = <&videocc VIDEO_CC_VCODEC1_CORE_CLK>, + <&videocc VIDEO_CC_VCODEC1_AXI_CLK>; + clock-names = "core", "bus"; + power-domains = <&videocc VCODEC1_GDSC>; }; + }; diff --git a/Documentation/devicetree/bindings/media/qcom,sm8250-camss.yaml b/Documentation/devicetree/bindings/media/qcom,sm8250-camss.yaml index 07a2af12f37d..fa5073c0fd1e 100644 --- a/Documentation/devicetree/bindings/media/qcom,sm8250-camss.yaml +++ b/Documentation/devicetree/bindings/media/qcom,sm8250-camss.yaml @@ -2,8 +2,8 @@ %YAML 1.2 --- -$id: "http://devicetree.org/schemas/media/qcom,sm8250-camss.yaml#" -$schema: "http://devicetree.org/meta-schemas/core.yaml#" +$id: http://devicetree.org/schemas/media/qcom,sm8250-camss.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# title: Qualcomm CAMSS ISP diff --git a/Documentation/devicetree/bindings/media/qcom,sm8250-venus.yaml b/Documentation/devicetree/bindings/media/qcom,sm8250-venus.yaml index 4b7a12523dcf..7915dcd2d99f 100644 --- a/Documentation/devicetree/bindings/media/qcom,sm8250-venus.yaml +++ b/Documentation/devicetree/bindings/media/qcom,sm8250-venus.yaml @@ -1,11 +1,10 @@ # SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) - %YAML 1.2 --- -$id: "http://devicetree.org/schemas/media/qcom,sm8250-venus.yaml#" -$schema: "http://devicetree.org/meta-schemas/core.yaml#" +$id: http://devicetree.org/schemas/media/qcom,sm8250-venus.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# -title: Qualcomm Venus video encode and decode accelerators +title: Qualcomm SM8250 Venus video encode and decode accelerators maintainers: - Stanimir Varbanov <stanimir.varbanov@linaro.org> @@ -14,16 +13,13 @@ description: | The Venus IP is a video encode and decode accelerator present on Qualcomm platforms +allOf: + - $ref: qcom,venus-common.yaml# + properties: compatible: const: qcom,sm8250-venus - reg: - maxItems: 1 - - interrupts: - maxItems: 1 - power-domains: minItems: 2 maxItems: 3 @@ -47,9 +43,6 @@ properties: iommus: maxItems: 1 - memory-region: - maxItems: 1 - interconnects: maxItems: 2 @@ -58,6 +51,10 @@ properties: - const: cpu-cfg - const: video-mem + operating-points-v2: true + opp-table: + type: object + resets: maxItems: 2 @@ -90,78 +87,57 @@ properties: additionalProperties: false - video-firmware: - type: object - additionalProperties: false - - description: | - Firmware subnode is needed when the platform does not - have TrustZone. - - properties: - iommus: - maxItems: 1 - - required: - - iommus - required: - compatible - - reg - - interrupts - - power-domains - power-domain-names - - clocks - - clock-names - interconnects - interconnect-names - iommus - - memory-region - resets - reset-names - video-decoder - video-encoder -additionalProperties: false +unevaluatedProperties: false examples: - | - #include <dt-bindings/interrupt-controller/arm-gic.h> - #include <dt-bindings/clock/qcom,videocc-sm8250.h> - #include <dt-bindings/interconnect/qcom,sm8250.h> - #include <dt-bindings/clock/qcom,gcc-sm8250.h> - #include <dt-bindings/power/qcom-rpmpd.h> - - venus: video-codec@aa00000 { - compatible = "qcom,sm8250-venus"; - reg = <0x0aa00000 0xff000>; - interrupts = <GIC_SPI 174 IRQ_TYPE_LEVEL_HIGH>; - power-domains = <&videocc MVS0C_GDSC>, - <&videocc MVS0_GDSC>, - <&rpmhpd SM8250_MX>; - power-domain-names = "venus", "vcodec0", "mx"; - - clocks = <&gcc GCC_VIDEO_AXI0_CLK>, - <&videocc VIDEO_CC_MVS0C_CLK>, - <&videocc VIDEO_CC_MVS0_CLK>; - clock-names = "iface", "core", "vcodec0_core"; - - interconnects = <&gem_noc MASTER_AMPSS_M0 &config_noc SLAVE_VENUS_CFG>, - <&mmss_noc MASTER_VIDEO_P0 &mc_virt SLAVE_EBI_CH0>; - interconnect-names = "cpu-cfg", "video-mem"; - - iommus = <&apps_smmu 0x2100 0x0400>; - memory-region = <&video_mem>; - - resets = <&gcc GCC_VIDEO_AXI0_CLK_ARES>, - <&videocc VIDEO_CC_MVS0C_CLK_ARES>; - reset-names = "bus", "core"; - - video-decoder { - compatible = "venus-decoder"; - }; - - video-encoder { - compatible = "venus-encoder"; - }; + #include <dt-bindings/interrupt-controller/arm-gic.h> + #include <dt-bindings/clock/qcom,videocc-sm8250.h> + #include <dt-bindings/interconnect/qcom,sm8250.h> + #include <dt-bindings/clock/qcom,gcc-sm8250.h> + #include <dt-bindings/power/qcom-rpmpd.h> + + venus: video-codec@aa00000 { + compatible = "qcom,sm8250-venus"; + reg = <0x0aa00000 0xff000>; + interrupts = <GIC_SPI 174 IRQ_TYPE_LEVEL_HIGH>; + power-domains = <&videocc MVS0C_GDSC>, + <&videocc MVS0_GDSC>, + <&rpmhpd SM8250_MX>; + power-domain-names = "venus", "vcodec0", "mx"; + + clocks = <&gcc GCC_VIDEO_AXI0_CLK>, + <&videocc VIDEO_CC_MVS0C_CLK>, + <&videocc VIDEO_CC_MVS0_CLK>; + clock-names = "iface", "core", "vcodec0_core"; + + interconnects = <&gem_noc MASTER_AMPSS_M0 &config_noc SLAVE_VENUS_CFG>, + <&mmss_noc MASTER_VIDEO_P0 &mc_virt SLAVE_EBI_CH0>; + interconnect-names = "cpu-cfg", "video-mem"; + + iommus = <&apps_smmu 0x2100 0x0400>; + memory-region = <&video_mem>; + + resets = <&gcc GCC_VIDEO_AXI0_CLK_ARES>, + <&videocc VIDEO_CC_MVS0C_CLK_ARES>; + reset-names = "bus", "core"; + + video-decoder { + compatible = "venus-decoder"; + }; + + video-encoder { + compatible = "venus-encoder"; }; + }; diff --git a/Documentation/devicetree/bindings/media/qcom,venus-common.yaml b/Documentation/devicetree/bindings/media/qcom,venus-common.yaml new file mode 100644 index 000000000000..3153d91f9d18 --- /dev/null +++ b/Documentation/devicetree/bindings/media/qcom,venus-common.yaml @@ -0,0 +1,73 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/media/qcom,venus-common.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Qualcomm SoC Venus Video Encode and Decode Accelerators Common Properties + +maintainers: + - Stanimir Varbanov <stanimir.k.varbanov@gmail.com> + - Vikash Garodia <quic_vgarodia@quicinc.com> + +description: | + The Venus IP is a video encode and decode accelerator present + on Qualcomm platforms + +properties: + reg: + maxItems: 1 + + clocks: + minItems: 3 + maxItems: 7 + + clock-names: + minItems: 3 + maxItems: 7 + + firmware-name: + maxItems: 1 + + interrupts: + maxItems: 1 + + iommus: + minItems: 1 + maxItems: 20 + + memory-region: + maxItems: 1 + + power-domains: + minItems: 1 + maxItems: 4 + + power-domain-names: + minItems: 1 + maxItems: 4 + + video-firmware: + type: object + additionalProperties: false + + description: | + Firmware subnode is needed when the platform does not + have TrustZone. + + properties: + iommus: + maxItems: 1 + + required: + - iommus + +required: + - reg + - clocks + - clock-names + - interrupts + - memory-region + - power-domains + +additionalProperties: true diff --git a/Documentation/devicetree/bindings/media/rc.yaml b/Documentation/devicetree/bindings/media/rc.yaml index e732b7f3a635..7bbe580c80f7 100644 --- a/Documentation/devicetree/bindings/media/rc.yaml +++ b/Documentation/devicetree/bindings/media/rc.yaml @@ -18,7 +18,7 @@ properties: description: Specifies the scancode/key mapping table defined in-kernel for the remote controller. - $ref: '/schemas/types.yaml#/definitions/string' + $ref: /schemas/types.yaml#/definitions/string enum: - rc-adstech-dvb-t-pci - rc-alink-dtu-m @@ -39,6 +39,7 @@ properties: - rc-avertv-303 - rc-azurewave-ad-tu700 - rc-beelink-gs1 + - rc-beelink-mxiii - rc-behold - rc-behold-columbus - rc-budget-ci-old @@ -55,6 +56,7 @@ properties: - rc-dm1105-nec - rc-dntv-live-dvb-t - rc-dntv-live-dvbt-pro + - rc-dreambox - rc-dtt200u - rc-dvbsky - rc-dvico-mce diff --git a/Documentation/devicetree/bindings/media/renesas,csi2.yaml b/Documentation/devicetree/bindings/media/renesas,csi2.yaml index b520d6c5c102..977ab188d654 100644 --- a/Documentation/devicetree/bindings/media/renesas,csi2.yaml +++ b/Documentation/devicetree/bindings/media/renesas,csi2.yaml @@ -31,6 +31,7 @@ properties: - renesas,r8a77980-csi2 # R-Car V3H - renesas,r8a77990-csi2 # R-Car E3 - renesas,r8a779a0-csi2 # R-Car V3U + - renesas,r8a779g0-csi2 # R-Car V4H reg: maxItems: 1 diff --git a/Documentation/devicetree/bindings/media/renesas,fcp.yaml b/Documentation/devicetree/bindings/media/renesas,fcp.yaml index 43f2fed8cd33..c6abe719881b 100644 --- a/Documentation/devicetree/bindings/media/renesas,fcp.yaml +++ b/Documentation/devicetree/bindings/media/renesas,fcp.yaml @@ -21,15 +21,22 @@ description: | properties: compatible: - enum: - - renesas,fcpv # FCP for VSP - - renesas,fcpf # FCP for FDP + oneOf: + - enum: + - renesas,fcpv # FCP for VSP + - renesas,fcpf # FCP for FDP + - items: + - enum: + - renesas,r9a07g044-fcpvd # RZ/G2{L,LC} + - renesas,r9a07g054-fcpvd # RZ/V2L + - const: renesas,fcpv # Generic FCP for VSP fallback reg: maxItems: 1 - clocks: - maxItems: 1 + clocks: true + + clock-names: true iommus: maxItems: 1 @@ -49,6 +56,34 @@ required: additionalProperties: false +allOf: + - if: + properties: + compatible: + contains: + enum: + - renesas,r9a07g044-fcpvd + - renesas,r9a07g054-fcpvd + then: + properties: + clocks: + items: + - description: Main clock + - description: Register access clock + - description: Video clock + clock-names: + items: + - const: aclk + - const: pclk + - const: vclk + required: + - clock-names + else: + properties: + clocks: + maxItems: 1 + clock-names: false + examples: # R8A7795 (R-Car H3) FCP for VSP-D1 - | diff --git a/Documentation/devicetree/bindings/media/renesas,isp.yaml b/Documentation/devicetree/bindings/media/renesas,isp.yaml index 514857d36f6b..33650a1ea034 100644 --- a/Documentation/devicetree/bindings/media/renesas,isp.yaml +++ b/Documentation/devicetree/bindings/media/renesas,isp.yaml @@ -21,6 +21,7 @@ properties: items: - enum: - renesas,r8a779a0-isp # V3U + - renesas,r8a779g0-isp # V4H reg: maxItems: 1 diff --git a/Documentation/devicetree/bindings/media/renesas,vin.yaml b/Documentation/devicetree/bindings/media/renesas,vin.yaml index c0442e79cbb4..7073d1936c34 100644 --- a/Documentation/devicetree/bindings/media/renesas,vin.yaml +++ b/Documentation/devicetree/bindings/media/renesas,vin.yaml @@ -53,6 +53,7 @@ properties: - renesas,vin-r8a77990 # R-Car E3 - renesas,vin-r8a77995 # R-Car D3 - renesas,vin-r8a779a0 # R-Car V3U + - renesas,vin-r8a779g0 # R-Car V4H reg: maxItems: 1 diff --git a/Documentation/devicetree/bindings/media/renesas,vsp1.yaml b/Documentation/devicetree/bindings/media/renesas,vsp1.yaml index 7a8f32473852..3265e922647c 100644 --- a/Documentation/devicetree/bindings/media/renesas,vsp1.yaml +++ b/Documentation/devicetree/bindings/media/renesas,vsp1.yaml @@ -16,10 +16,15 @@ description: properties: compatible: - enum: - - renesas,r9a07g044-vsp2 # RZ/G2L - - renesas,vsp1 # R-Car Gen2 and RZ/G1 - - renesas,vsp2 # R-Car Gen3 and RZ/G2 + oneOf: + - enum: + - renesas,r9a07g044-vsp2 # RZ/G2L + - renesas,vsp1 # R-Car Gen2 and RZ/G1 + - renesas,vsp2 # R-Car Gen3 and RZ/G2 + - items: + - enum: + - renesas,r9a07g054-vsp2 # RZ/V2L + - const: renesas,r9a07g044-vsp2 # RZ/G2L fallback reg: maxItems: 1 diff --git a/Documentation/devicetree/bindings/media/rockchip,rk3568-vepu.yaml b/Documentation/devicetree/bindings/media/rockchip,rk3568-vepu.yaml index 81b26eb4cd35..9d90d8d0565a 100644 --- a/Documentation/devicetree/bindings/media/rockchip,rk3568-vepu.yaml +++ b/Documentation/devicetree/bindings/media/rockchip,rk3568-vepu.yaml @@ -2,8 +2,8 @@ %YAML 1.2 --- -$id: "http://devicetree.org/schemas/media/rockchip,rk3568-vepu.yaml#" -$schema: "http://devicetree.org/meta-schemas/core.yaml#" +$id: http://devicetree.org/schemas/media/rockchip,rk3568-vepu.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# title: Hantro G1 VPU encoders implemented on Rockchip SoCs diff --git a/Documentation/devicetree/bindings/media/rockchip-isp1.yaml b/Documentation/devicetree/bindings/media/rockchip-isp1.yaml index b3661d7d4357..0bad7e640148 100644 --- a/Documentation/devicetree/bindings/media/rockchip-isp1.yaml +++ b/Documentation/devicetree/bindings/media/rockchip-isp1.yaml @@ -212,12 +212,19 @@ examples: compatible = "ovti,ov2685"; reg = <0x3c>; - port { - ucam_out: endpoint { - remote-endpoint = <&mipi_in_ucam>; - data-lanes = <1>; - }; - }; + clocks = <&cru SCLK_TESTCLKOUT1>; + clock-names = "xvclk"; + + avdd-supply = <&pp2800_cam>; + dovdd-supply = <&pp1800>; + dvdd-supply = <&pp1800>; + + port { + ucam_out: endpoint { + remote-endpoint = <&mipi_in_ucam>; + data-lanes = <1>; + }; + }; }; }; }; diff --git a/Documentation/devicetree/bindings/media/rockchip-vpu.yaml b/Documentation/devicetree/bindings/media/rockchip-vpu.yaml index 6cc4d3e5a61d..ee622a8ee1cc 100644 --- a/Documentation/devicetree/bindings/media/rockchip-vpu.yaml +++ b/Documentation/devicetree/bindings/media/rockchip-vpu.yaml @@ -2,8 +2,8 @@ %YAML 1.2 --- -$id: "http://devicetree.org/schemas/media/rockchip-vpu.yaml#" -$schema: "http://devicetree.org/meta-schemas/core.yaml#" +$id: http://devicetree.org/schemas/media/rockchip-vpu.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# title: Hantro G1 VPU codecs implemented on Rockchip SoCs diff --git a/Documentation/devicetree/bindings/media/samsung,exynos4210-csis.yaml b/Documentation/devicetree/bindings/media/samsung,exynos4210-csis.yaml new file mode 100644 index 000000000000..dd6cc7ac1f7c --- /dev/null +++ b/Documentation/devicetree/bindings/media/samsung,exynos4210-csis.yaml @@ -0,0 +1,170 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/media/samsung,exynos4210-csis.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Samsung S5P/Exynos SoC series MIPI CSI-2 receiver (MIPI CSIS) + +maintainers: + - Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> + - Sylwester Nawrocki <s.nawrocki@samsung.com> + +properties: + compatible: + enum: + - samsung,s5pv210-csis + - samsung,exynos4210-csis + - samsung,exynos4212-csis + - samsung,exynos5250-csis + + reg: + maxItems: 1 + + '#address-cells': + const: 1 + + '#size-cells': + const: 0 + + bus-width: + $ref: /schemas/types.yaml#/definitions/uint32 + enum: [2, 4] + description: + Number of data lines supported. + + clocks: + maxItems: 2 + + clock-names: + items: + - const: csis + - const: sclk_csis + + clock-frequency: + default: 166000000 + description: + The IP's main (system bus) clock frequency in Hz. + + interrupts: + maxItems: 1 + + phys: + maxItems: 1 + + phy-names: + items: + - const: csis + + power-domains: + maxItems: 1 + + vddio-supply: + description: MIPI CSIS I/O and PLL voltage supply (e.g. 1.8V). + + vddcore-supply: + description: MIPI CSIS Core voltage supply (e.g. 1.1V). + +patternProperties: + "^port@[34]$": + $ref: /schemas/graph.yaml#/$defs/port-base + additionalProperties: false + description: + Camera input port. + + properties: + reg: + enum: [3, 4] + + endpoint: + $ref: video-interfaces.yaml# + unevaluatedProperties: false + + properties: + data-lanes: + minItems: 1 + maxItems: 4 + + samsung,csis-hs-settle: + $ref: /schemas/types.yaml#/definitions/uint32 + description: Differential receiver (HS-RX) settle time. + + samsung,csis-wclk: + type: boolean + description: + CSI-2 wrapper clock selection. If this property is present external clock + from CMU will be used, or the bus clock if it's not specified. + + required: + - data-lanes + + required: + - reg + +required: + - compatible + - reg + - bus-width + - clocks + - clock-names + - interrupts + - vddio-supply + - vddcore-supply + +anyOf: + - required: + - port@3 + - required: + - port@4 + +allOf: + - if: + required: + - samsung,isp-wb + then: + required: + - samsung,sysreg + +additionalProperties: false + +examples: + - | + #include <dt-bindings/clock/exynos4.h> + #include <dt-bindings/interrupt-controller/arm-gic.h> + + csis@11890000 { + compatible = "samsung,exynos4210-csis"; + reg = <0x11890000 0x4000>; + clocks = <&clock CLK_CSIS1>, + <&clock CLK_SCLK_CSIS1>; + clock-names = "csis", "sclk_csis"; + assigned-clocks = <&clock CLK_MOUT_CSIS1>, + <&clock CLK_SCLK_CSIS1>; + assigned-clock-parents = <&clock CLK_MOUT_MPLL_USER_T>; + assigned-clock-rates = <0>, <176000000>; + + interrupts = <GIC_SPI 80 IRQ_TYPE_LEVEL_HIGH>; + + bus-width = <2>; + power-domains = <&pd_cam>; + phys = <&mipi_phy 2>; + phy-names = "csis"; + + vddcore-supply = <&ldo8_reg>; + vddio-supply = <&ldo10_reg>; + + #address-cells = <1>; + #size-cells = <0>; + + /* Camera D (4) MIPI CSI-2 (CSIS1) */ + port@4 { + reg = <4>; + + endpoint { + remote-endpoint = <&is_s5k6a3_ep>; + data-lanes = <1>; + samsung,csis-hs-settle = <18>; + samsung,csis-wclk; + }; + }; + }; diff --git a/Documentation/devicetree/bindings/media/samsung,exynos4210-fimc.yaml b/Documentation/devicetree/bindings/media/samsung,exynos4210-fimc.yaml new file mode 100644 index 000000000000..271d0577a83c --- /dev/null +++ b/Documentation/devicetree/bindings/media/samsung,exynos4210-fimc.yaml @@ -0,0 +1,152 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/media/samsung,exynos4210-fimc.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Samsung S5P/Exynos SoC Fully Integrated Mobile Camera + +maintainers: + - Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> + - Sylwester Nawrocki <s.nawrocki@samsung.com> + +description: + Each FIMC device should have an alias in the aliases node, in the form of + fimc<n>, where <n> is an integer specifying the IP block instance. + +properties: + compatible: + enum: + - samsung,exynos4210-fimc + - samsung,exynos4212-fimc + - samsung,s5pv210-fimc + + reg: + maxItems: 1 + + clocks: + maxItems: 2 + + clock-names: + items: + - const: fimc + - const: sclk_fimc + + clock-frequency: + description: + Maximum FIMC local clock (LCLK) frequency. + + interrupts: + maxItems: 1 + + iommus: + maxItems: 1 + + power-domains: + maxItems: 1 + + samsung,cam-if: + type: boolean + description: + The FIMC IP block includes the camera input interface. + + samsung,isp-wb: + type: boolean + description: | + The FIMC IP block has the ISP writeback input. + + samsung,lcd-wb: + type: boolean + description: | + The FIMC IP block has the LCD writeback input. + + samsung,mainscaler-ext: + type: boolean + description: + FIMC IP supports extended image size and has CIEXTEN register. + + samsung,min-pix-alignment: + $ref: /schemas/types.yaml#/definitions/uint32-array + items: + - description: Minimum supported image height alignment. + - description: Horizontal image offset. + description: + The values are in pixels and default is <2 1>. + + samsung,min-pix-sizes: + $ref: /schemas/types.yaml#/definitions/uint32-array + maxItems: 2 + description: | + An array specyfing minimum image size in pixels at the FIMC input and + output DMA, in the first and second cell respectively. Default value + is <16 16>. + + samsung,pix-limits: + $ref: /schemas/types.yaml#/definitions/uint32-array + maxItems: 4 + description: | + An array of maximum supported image sizes in pixels, for details refer to + Table 2-1 in the S5PV210 SoC User Manual. The meaning of each cell is as + follows: + 0 - scaler input horizontal size + 1 - input horizontal size for the scaler bypassed + 2 - REAL_WIDTH without input rotation + 3 - REAL_HEIGHT with input rotation + + samsung,rotators: + $ref: /schemas/types.yaml#/definitions/uint32 + default: 0x11 + description: | + A bitmask specifying whether this IP has the input and the output + rotator. Bits 4 and 0 correspond to input and output rotator + respectively. If a rotator is present its corresponding bit should be + set. + + samsung,sysreg: + $ref: /schemas/types.yaml#/definitions/phandle + description: + System Registers (SYSREG) node. + +required: + - compatible + - reg + - clocks + - clock-names + - samsung,pix-limits + +allOf: + - if: + required: + - samsung,isp-wb + then: + required: + - samsung,sysreg + +additionalProperties: false + +examples: + - | + #include <dt-bindings/clock/exynos4.h> + #include <dt-bindings/interrupt-controller/arm-gic.h> + + fimc@11800000 { + compatible = "samsung,exynos4212-fimc"; + reg = <0x11800000 0x1000>; + clocks = <&clock CLK_FIMC0>, + <&clock CLK_SCLK_FIMC0>; + clock-names = "fimc", "sclk_fimc"; + interrupts = <GIC_SPI 84 IRQ_TYPE_LEVEL_HIGH>; + iommus = <&sysmmu_fimc0>; + power-domains = <&pd_cam>; + samsung,sysreg = <&sys_reg>; + + samsung,pix-limits = <4224 8192 1920 4224>; + samsung,mainscaler-ext; + samsung,isp-wb; + samsung,cam-if; + + assigned-clocks = <&clock CLK_MOUT_FIMC0>, + <&clock CLK_SCLK_FIMC0>; + assigned-clock-parents = <&clock CLK_MOUT_MPLL_USER_T>; + assigned-clock-rates = <0>, <176000000>; + }; diff --git a/Documentation/devicetree/bindings/media/samsung,exynos4212-fimc-is.yaml b/Documentation/devicetree/bindings/media/samsung,exynos4212-fimc-is.yaml new file mode 100644 index 000000000000..3691cd4962b2 --- /dev/null +++ b/Documentation/devicetree/bindings/media/samsung,exynos4212-fimc-is.yaml @@ -0,0 +1,220 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/media/samsung,exynos4212-fimc-is.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Samsung Exynos4212/4412 SoC Imaging Subsystem (FIMC-IS) + +maintainers: + - Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> + - Sylwester Nawrocki <s.nawrocki@samsung.com> + +description: + The FIMC-IS is a subsystem for processing image signal from an image sensor. + The Exynos4x12 SoC series FIMC-IS V1.5 comprises of a dedicated ARM Cortex-A5 + processor, ISP, DRC and FD IP blocks and peripheral devices such as UART, I2C + and SPI bus controllers, PWM and ADC. + +properties: + compatible: + enum: + - samsung,exynos4212-fimc-is + + reg: + maxItems: 1 + + ranges: true + + '#address-cells': + const: 1 + + '#size-cells': + const: 1 + + clocks: + maxItems: 21 + + clock-names: + items: + - const: lite0 + - const: lite1 + - const: ppmuispx + - const: ppmuispmx + - const: isp + - const: drc + - const: fd + - const: mcuisp + - const: gicisp + - const: mcuctl_isp + - const: pwm_isp + - const: ispdiv0 + - const: ispdiv1 + - const: mcuispdiv0 + - const: mcuispdiv1 + - const: mpll + - const: aclk200 + - const: aclk400mcuisp + - const: div_aclk200 + - const: div_aclk400mcuisp + - const: uart + + interrupts: + maxItems: 2 + + iommus: + maxItems: 4 + + iommu-names: + items: + - const: isp + - const: drc + - const: fd + - const: mcuctl + + power-domains: + maxItems: 1 + +patternProperties: + "^pmu@[0-9a-f]+$": + type: object + additionalProperties: false + description: + Node representing the SoC's Power Management Unit (duplicated with the + correct PMU node in the SoC). + + properties: + reg: + maxItems: 1 + + required: + - reg + + "^i2c-isp@[0-9a-f]+$": + type: object + $ref: /schemas/i2c/i2c-controller.yaml# + unevaluatedProperties: false + description: + ISP I2C bus controller + + properties: + compatible: + const: samsung,exynos4212-i2c-isp + + reg: + maxItems: 1 + + + clocks: + maxItems: 1 + + clock-names: + items: + - const: i2c_isp + + pinctrl-0: true + pinctrl-names: + items: + - const: default + + required: + - compatible + - reg + - clocks + - clock-names + +required: + - compatible + - reg + - '#address-cells' + - clocks + - clock-names + - interrupts + - ranges + - '#size-cells' + +additionalProperties: false + +examples: + - | + #include <dt-bindings/clock/exynos4.h> + #include <dt-bindings/gpio/gpio.h> + #include <dt-bindings/interrupt-controller/arm-gic.h> + + fimc-is@12000000 { + compatible = "samsung,exynos4212-fimc-is"; + reg = <0x12000000 0x260000>; + interrupts = <GIC_SPI 90 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 95 IRQ_TYPE_LEVEL_HIGH>; + clocks = <&isp_clock CLK_ISP_FIMC_LITE0>, + <&isp_clock CLK_ISP_FIMC_LITE1>, + <&isp_clock CLK_ISP_PPMUISPX>, + <&isp_clock CLK_ISP_PPMUISPMX>, + <&isp_clock CLK_ISP_FIMC_ISP>, + <&isp_clock CLK_ISP_FIMC_DRC>, + <&isp_clock CLK_ISP_FIMC_FD>, + <&isp_clock CLK_ISP_MCUISP>, + <&isp_clock CLK_ISP_GICISP>, + <&isp_clock CLK_ISP_MCUCTL_ISP>, + <&isp_clock CLK_ISP_PWM_ISP>, + <&isp_clock CLK_ISP_DIV_ISP0>, + <&isp_clock CLK_ISP_DIV_ISP1>, + <&isp_clock CLK_ISP_DIV_MCUISP0>, + <&isp_clock CLK_ISP_DIV_MCUISP1>, + <&clock CLK_MOUT_MPLL_USER_T>, + <&clock CLK_ACLK200>, + <&clock CLK_ACLK400_MCUISP>, + <&clock CLK_DIV_ACLK200>, + <&clock CLK_DIV_ACLK400_MCUISP>, + <&clock CLK_UART_ISP_SCLK>; + clock-names = "lite0", "lite1", "ppmuispx", + "ppmuispmx", "isp", + "drc", "fd", "mcuisp", + "gicisp", "mcuctl_isp", "pwm_isp", + "ispdiv0", "ispdiv1", "mcuispdiv0", + "mcuispdiv1", "mpll", "aclk200", + "aclk400mcuisp", "div_aclk200", + "div_aclk400mcuisp", "uart"; + iommus = <&sysmmu_fimc_isp>, <&sysmmu_fimc_drc>, + <&sysmmu_fimc_fd>, <&sysmmu_fimc_mcuctl>; + iommu-names = "isp", "drc", "fd", "mcuctl"; + power-domains = <&pd_isp>; + + #address-cells = <1>; + #size-cells = <1>; + ranges; + + pmu@10020000 { + reg = <0x10020000 0x3000>; + }; + + i2c-isp@12140000 { + compatible = "samsung,exynos4212-i2c-isp"; + reg = <0x12140000 0x100>; + clocks = <&isp_clock CLK_ISP_I2C1_ISP>; + clock-names = "i2c_isp"; + pinctrl-0 = <&fimc_is_i2c1>; + pinctrl-names = "default"; + #address-cells = <1>; + #size-cells = <0>; + + image-sensor@10 { + compatible = "samsung,s5k6a3"; + reg = <0x10>; + svdda-supply = <&cam_io_reg>; + svddio-supply = <&ldo19_reg>; + afvdd-supply = <&ldo19_reg>; + clock-frequency = <24000000>; + clocks = <&camera 1>; + clock-names = "extclk"; + gpios = <&gpm1 6 GPIO_ACTIVE_LOW>; + + port { + endpoint { + remote-endpoint = <&csis1_ep>; + data-lanes = <1>; + }; + }; + }; + }; + }; diff --git a/Documentation/devicetree/bindings/media/samsung,exynos4212-fimc-lite.yaml b/Documentation/devicetree/bindings/media/samsung,exynos4212-fimc-lite.yaml new file mode 100644 index 000000000000..f80eca0a4f41 --- /dev/null +++ b/Documentation/devicetree/bindings/media/samsung,exynos4212-fimc-lite.yaml @@ -0,0 +1,63 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/media/samsung,exynos4212-fimc-lite.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Samsung Exynos SoC series camera host interface (FIMC-LITE) + +maintainers: + - Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> + - Sylwester Nawrocki <s.nawrocki@samsung.com> + +description: + Each FIMC device should have an alias in the aliases node, in the form of + fimc-lite<n>, where <n> is an integer specifying the IP block instance. + +properties: + compatible: + enum: + - samsung,exynos4212-fimc-lite + - samsung,exynos5250-fimc-lite + + reg: + maxItems: 1 + + clocks: + maxItems: 1 + + clock-names: + items: + - const: flite + + interrupts: + maxItems: 1 + + iommus: + maxItems: 1 + + power-domains: + maxItems: 1 + +required: + - compatible + - reg + - clocks + - clock-names + - interrupts + +additionalProperties: false + +examples: + - | + #include <dt-bindings/clock/exynos4.h> + #include <dt-bindings/interrupt-controller/arm-gic.h> + fimc-lite@12390000 { + compatible = "samsung,exynos4212-fimc-lite"; + reg = <0x12390000 0x1000>; + clocks = <&isp_clock CLK_ISP_FIMC_LITE0>; + clock-names = "flite"; + interrupts = <GIC_SPI 105 IRQ_TYPE_LEVEL_HIGH>; + power-domains = <&pd_isp>; + iommus = <&sysmmu_fimc_lite0>; + }; diff --git a/Documentation/devicetree/bindings/media/samsung,fimc.yaml b/Documentation/devicetree/bindings/media/samsung,fimc.yaml new file mode 100644 index 000000000000..79ff6d83a9fd --- /dev/null +++ b/Documentation/devicetree/bindings/media/samsung,fimc.yaml @@ -0,0 +1,279 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/media/samsung,fimc.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Samsung S5P/Exynos SoC Camera Subsystem (FIMC) + +maintainers: + - Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> + - Sylwester Nawrocki <s.nawrocki@samsung.com> + +description: | + The S5P/Exynos SoC Camera subsystem comprises of multiple sub-devices + represented by separate device tree nodes. Currently this includes: Fully + Integrated Mobile Camera (FIMC, in the S5P SoCs series known as CAMIF), MIPI + CSIS, FIMC-LITE and FIMC-IS (ISP). + +properties: + compatible: + const: samsung,fimc + + ranges: true + + '#address-cells': + const: 1 + + '#size-cells': + const: 1 + + '#clock-cells': + const: 1 + description: | + The clock specifier cell stores an index of a clock: 0, 1 for + CAM_A_CLKOUT, CAM_B_CLKOUT clocks respectively. + + clocks: + minItems: 2 + maxItems: 4 + + clock-names: + minItems: 2 + items: + - const: sclk_cam0 + - const: sclk_cam1 + - const: pxl_async0 + - const: pxl_async1 + + clock-output-names: + maxItems: 2 + + parallel-ports: + $ref: /schemas/graph.yaml#/properties/ports + description: + Active parallel video input ports. + + patternProperties: + "^port@[01]$": + $ref: /schemas/graph.yaml#/$defs/port-base + description: + Camera A and camera B inputs. + + properties: + endpoint: + $ref: /schemas/media/video-interfaces.yaml# + unevaluatedProperties: false + + pinctrl-names: + minItems: 1 + items: + - const: default + - const: idle + - const: active_a + - const: active_b + +patternProperties: + "^csis@[0-9a-f]+$": + type: object + $ref: samsung,exynos4210-csis.yaml# + description: MIPI CSI-2 receiver. + + "^fimc@[0-9a-f]+$": + type: object + $ref: samsung,exynos4210-fimc.yaml# + description: Fully Integrated Mobile Camera. + + "^fimc-is@[0-9a-f]+$": + type: object + $ref: samsung,exynos4212-fimc-is.yaml# + description: Imaging Subsystem (FIMC-IS). + + "^fimc-lite@[0-9a-f]+$": + type: object + $ref: samsung,exynos4212-fimc-lite.yaml# + description: Camera host interface (FIMC-LITE). + +required: + - compatible + - '#address-cells' + - '#clock-cells' + - clocks + - clock-names + - clock-output-names + - ranges + - '#size-cells' + +additionalProperties: false + +examples: + - | + #include <dt-bindings/clock/exynos4.h> + #include <dt-bindings/gpio/gpio.h> + #include <dt-bindings/interrupt-controller/arm-gic.h> + + camera@11800000 { + compatible = "samsung,fimc"; + #clock-cells = <1>; + #address-cells = <1>; + #size-cells = <1>; + ranges = <0x0 0x0 0x18000000>; + + clocks = <&clock CLK_SCLK_CAM0>, <&clock CLK_SCLK_CAM1>, + <&clock CLK_PIXELASYNCM0>, <&clock CLK_PIXELASYNCM1>; + clock-names = "sclk_cam0", "sclk_cam1", "pxl_async0", "pxl_async1"; + clock-output-names = "cam_a_clkout", "cam_b_clkout"; + + assigned-clocks = <&clock CLK_MOUT_CAM0>, + <&clock CLK_MOUT_CAM1>; + assigned-clock-parents = <&clock CLK_XUSBXTI>, + <&clock CLK_XUSBXTI>; + + pinctrl-0 = <&cam_port_a_clk_active &cam_port_b_clk_active>; + pinctrl-names = "default"; + + fimc@11800000 { + compatible = "samsung,exynos4212-fimc"; + reg = <0x11800000 0x1000>; + interrupts = <GIC_SPI 84 IRQ_TYPE_LEVEL_HIGH>; + clocks = <&clock CLK_FIMC0>, + <&clock CLK_SCLK_FIMC0>; + clock-names = "fimc", "sclk_fimc"; + power-domains = <&pd_cam>; + samsung,sysreg = <&sys_reg>; + iommus = <&sysmmu_fimc0>; + + samsung,pix-limits = <4224 8192 1920 4224>; + samsung,mainscaler-ext; + samsung,isp-wb; + samsung,cam-if; + }; + + /* ... FIMC 1-3 */ + + csis@11880000 { + compatible = "samsung,exynos4210-csis"; + reg = <0x11880000 0x4000>; + interrupts = <GIC_SPI 78 IRQ_TYPE_LEVEL_HIGH>; + clocks = <&clock CLK_CSIS0>, + <&clock CLK_SCLK_CSIS0>; + clock-names = "csis", "sclk_csis"; + assigned-clocks = <&clock CLK_MOUT_CSIS0>, + <&clock CLK_SCLK_CSIS0>; + assigned-clock-parents = <&clock CLK_MOUT_MPLL_USER_T>; + assigned-clock-rates = <0>, <176000000>; + + bus-width = <4>; + power-domains = <&pd_cam>; + phys = <&mipi_phy 0>; + phy-names = "csis"; + #address-cells = <1>; + #size-cells = <0>; + + vddcore-supply = <&ldo8_reg>; + vddio-supply = <&ldo10_reg>; + + /* Camera C (3) MIPI CSI-2 (CSIS0) */ + port@3 { + reg = <3>; + endpoint { + remote-endpoint = <&s5c73m3_ep>; + data-lanes = <1 2 3 4>; + samsung,csis-hs-settle = <12>; + }; + }; + }; + + /* ... CSIS 1 */ + + fimc-lite@12390000 { + compatible = "samsung,exynos4212-fimc-lite"; + reg = <0x12390000 0x1000>; + interrupts = <GIC_SPI 105 IRQ_TYPE_LEVEL_HIGH>; + power-domains = <&pd_isp>; + clocks = <&isp_clock CLK_ISP_FIMC_LITE0>; + clock-names = "flite"; + iommus = <&sysmmu_fimc_lite0>; + }; + + /* ... FIMC-LITE 1 */ + + fimc-is@12000000 { + compatible = "samsung,exynos4212-fimc-is"; + reg = <0x12000000 0x260000>; + interrupts = <GIC_SPI 90 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 95 IRQ_TYPE_LEVEL_HIGH>; + clocks = <&isp_clock CLK_ISP_FIMC_LITE0>, + <&isp_clock CLK_ISP_FIMC_LITE1>, + <&isp_clock CLK_ISP_PPMUISPX>, + <&isp_clock CLK_ISP_PPMUISPMX>, + <&isp_clock CLK_ISP_FIMC_ISP>, + <&isp_clock CLK_ISP_FIMC_DRC>, + <&isp_clock CLK_ISP_FIMC_FD>, + <&isp_clock CLK_ISP_MCUISP>, + <&isp_clock CLK_ISP_GICISP>, + <&isp_clock CLK_ISP_MCUCTL_ISP>, + <&isp_clock CLK_ISP_PWM_ISP>, + <&isp_clock CLK_ISP_DIV_ISP0>, + <&isp_clock CLK_ISP_DIV_ISP1>, + <&isp_clock CLK_ISP_DIV_MCUISP0>, + <&isp_clock CLK_ISP_DIV_MCUISP1>, + <&clock CLK_MOUT_MPLL_USER_T>, + <&clock CLK_ACLK200>, + <&clock CLK_ACLK400_MCUISP>, + <&clock CLK_DIV_ACLK200>, + <&clock CLK_DIV_ACLK400_MCUISP>, + <&clock CLK_UART_ISP_SCLK>; + clock-names = "lite0", "lite1", "ppmuispx", + "ppmuispmx", "isp", + "drc", "fd", "mcuisp", + "gicisp", "mcuctl_isp", "pwm_isp", + "ispdiv0", "ispdiv1", "mcuispdiv0", + "mcuispdiv1", "mpll", "aclk200", + "aclk400mcuisp", "div_aclk200", + "div_aclk400mcuisp", "uart"; + iommus = <&sysmmu_fimc_isp>, <&sysmmu_fimc_drc>, + <&sysmmu_fimc_fd>, <&sysmmu_fimc_mcuctl>; + iommu-names = "isp", "drc", "fd", "mcuctl"; + power-domains = <&pd_isp>; + + #address-cells = <1>; + #size-cells = <1>; + ranges; + + pmu@10020000 { + reg = <0x10020000 0x3000>; + }; + + i2c-isp@12140000 { + compatible = "samsung,exynos4212-i2c-isp"; + reg = <0x12140000 0x100>; + clocks = <&isp_clock CLK_ISP_I2C1_ISP>; + clock-names = "i2c_isp"; + pinctrl-0 = <&fimc_is_i2c1>; + pinctrl-names = "default"; + #address-cells = <1>; + #size-cells = <0>; + + image-sensor@10 { + compatible = "samsung,s5k6a3"; + reg = <0x10>; + svdda-supply = <&cam_io_reg>; + svddio-supply = <&ldo19_reg>; + afvdd-supply = <&ldo19_reg>; + clock-frequency = <24000000>; + /* CAM_B_CLKOUT */ + clocks = <&camera 1>; + clock-names = "extclk"; + gpios = <&gpm1 6 GPIO_ACTIVE_LOW>; + + port { + endpoint { + remote-endpoint = <&csis1_ep>; + data-lanes = <1>; + }; + }; + }; + }; + }; + }; diff --git a/Documentation/devicetree/bindings/media/samsung,s5c73m3.yaml b/Documentation/devicetree/bindings/media/samsung,s5c73m3.yaml new file mode 100644 index 000000000000..1b75390fdaac --- /dev/null +++ b/Documentation/devicetree/bindings/media/samsung,s5c73m3.yaml @@ -0,0 +1,165 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/media/samsung,s5c73m3.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Samsung S5C73M3 8Mp camera ISP + +maintainers: + - Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> + - Sylwester Nawrocki <s.nawrocki@samsung.com> + +description: + The S5C73M3 camera ISP supports MIPI CSI-2 and parallel (ITU-R BT.656) + video data busses. The I2C bus is the main control bus and additionally the + SPI bus is used, mostly for transferring the firmware to and from the + device. Two slave device nodes corresponding to these control bus + interfaces are required and should be placed under respective bus + controller nodes. + +properties: + compatible: + const: samsung,s5c73m3 + + reg: + maxItems: 1 + + clocks: + maxItems: 1 + + clock-names: + items: + - const: cis_extclk + + clock-frequency: + default: 24000000 + description: cis_extclk clock frequency. + + standby-gpios: + maxItems: 1 + description: STANDBY pin. + + vdda-supply: + description: Analog power supply (1.2V). + + vdd-af-supply: + description: lens power supply (2.8V). + + vddio-cis-supply: + description: CIS I/O power supply (1.2V to 1.8V). + + vddio-host-supply: + description: Host I/O power supply (1.8V to 2.8V). + + vdd-int-supply: + description: Digital power supply (1.2V). + + vdd-reg-supply: + description: Regulator input power supply (2.8V). + + xshutdown-gpios: + maxItems: 1 + description: XSHUTDOWN pin. + + port: + $ref: /schemas/graph.yaml#/$defs/port-base + additionalProperties: false + + properties: + endpoint: + $ref: /schemas/media/video-interfaces.yaml# + unevaluatedProperties: false + + properties: + data-lanes: + items: + - const: 1 + - const: 2 + - const: 3 + - const: 4 + +required: + - compatible + - reg + +allOf: + - $ref: /schemas/spi/spi-peripheral-props.yaml# + - if: + required: + - spi-max-frequency + then: + properties: + # The SPI node is simplified firmware-transfer interface only + clocks: false + clock-names: false + standby-gpios: false + vdda-supply: false + vdd-af-supply: false + vddio-cis-supply: false + vddio-host-supply: false + vdd-int-supply: false + vdd-reg-supply: false + xshutdown-gpios: false + port: false + else: + required: + - clocks + - clock-names + - standby-gpios + - vdda-supply + - vdd-af-supply + - vddio-cis-supply + - vddio-host-supply + - vdd-int-supply + - vdd-reg-supply + - xshutdown-gpios + - port + +unevaluatedProperties: false + +examples: + - | + #include <dt-bindings/gpio/gpio.h> + + i2c { + #address-cells = <1>; + #size-cells = <0>; + + image-sensor@3c { + compatible = "samsung,s5c73m3"; + reg = <0x3c>; + clock-frequency = <24000000>; + clocks = <&camera 0>; + clock-names = "cis_extclk"; + standby-gpios = <&gpm0 6 GPIO_ACTIVE_LOW>; + vdda-supply = <&cam_vdda_reg>; + vdd-af-supply = <&cam_af_reg>; + vddio-cis-supply = <&ldo9_reg>; + vddio-host-supply = <&ldo18_reg>; + vdd-int-supply = <&buck9_reg>; + vdd-reg-supply = <&cam_io_reg>; + xshutdown-gpios = <&gpf1 3 GPIO_ACTIVE_LOW>; /* ISP_RESET */ + + port { + s5c73m3_ep: endpoint { + remote-endpoint = <&csis0_ep>; + data-lanes = <1 2 3 4>; + }; + }; + }; + }; + + spi { + #address-cells = <1>; + #size-cells = <0>; + + image-sensor@0 { + compatible = "samsung,s5c73m3"; + reg = <0>; + spi-max-frequency = <50000000>; + controller-data { + samsung,spi-feedback-delay = <2>; + }; + }; + }; diff --git a/Documentation/devicetree/bindings/media/samsung-fimc.txt b/Documentation/devicetree/bindings/media/samsung-fimc.txt deleted file mode 100644 index 20447529c985..000000000000 --- a/Documentation/devicetree/bindings/media/samsung-fimc.txt +++ /dev/null @@ -1,209 +0,0 @@ -Samsung S5P/Exynos SoC Camera Subsystem (FIMC) ----------------------------------------------- - -The S5P/Exynos SoC Camera subsystem comprises of multiple sub-devices -represented by separate device tree nodes. Currently this includes: FIMC (in -the S5P SoCs series known as CAMIF), MIPI CSIS, FIMC-LITE and FIMC-IS (ISP). - -The sub-subdevices are defined as child nodes of the common 'camera' node which -also includes common properties of the whole subsystem not really specific to -any single sub-device, like common camera port pins or the CAMCLK clock outputs -for external image sensors attached to an SoC. - -Common 'camera' node --------------------- - -Required properties: - -- compatible: must be "samsung,fimc", "simple-bus" -- clocks: list of clock specifiers, corresponding to entries in - the clock-names property; -- clock-names : must contain "sclk_cam0", "sclk_cam1", "pxl_async0", - "pxl_async1" entries, matching entries in the clocks property. - -- #clock-cells: from the common clock bindings (../clock/clock-bindings.txt), - must be 1. A clock provider is associated with the 'camera' node and it should - be referenced by external sensors that use clocks provided by the SoC on - CAM_*_CLKOUT pins. The clock specifier cell stores an index of a clock. - The indices are 0, 1 for CAM_A_CLKOUT, CAM_B_CLKOUT clocks respectively. - -- clock-output-names: from the common clock bindings, should contain names of - clocks registered by the camera subsystem corresponding to CAM_A_CLKOUT, - CAM_B_CLKOUT output clocks respectively. - -The pinctrl bindings defined in ../pinctrl/pinctrl-bindings.txt must be used -to define a required pinctrl state named "default" and optional pinctrl states: -"idle", "active-a", active-b". These optional states can be used to switch the -camera port pinmux at runtime. The "idle" state should configure both the camera -ports A and B into high impedance state, especially the CAMCLK clock output -should be inactive. For the "active-a" state the camera port A must be activated -and the port B deactivated and for the state "active-b" it should be the other -way around. - -The 'camera' node must include at least one 'fimc' child node. - - -'fimc' device nodes -------------------- - -Required properties: - -- compatible: "samsung,s5pv210-fimc" for S5PV210, "samsung,exynos4210-fimc" - for Exynos4210 and "samsung,exynos4212-fimc" for Exynos4x12 SoCs; -- reg: physical base address and length of the registers set for the device; -- interrupts: should contain FIMC interrupt; -- clocks: list of clock specifiers, must contain an entry for each required - entry in clock-names; -- clock-names: must contain "fimc", "sclk_fimc" entries. -- samsung,pix-limits: an array of maximum supported image sizes in pixels, for - details refer to Table 2-1 in the S5PV210 SoC User Manual; The meaning of - each cell is as follows: - 0 - scaler input horizontal size, - 1 - input horizontal size for the scaler bypassed, - 2 - REAL_WIDTH without input rotation, - 3 - REAL_HEIGHT with input rotation, -- samsung,sysreg: a phandle to the SYSREG node. - -Each FIMC device should have an alias in the aliases node, in the form of -fimc<n>, where <n> is an integer specifying the IP block instance. - -Optional properties: - -- clock-frequency: maximum FIMC local clock (LCLK) frequency; -- samsung,min-pix-sizes: an array specyfing minimum image size in pixels at - the FIMC input and output DMA, in the first and second cell respectively. - Default value when this property is not present is <16 16>; -- samsung,min-pix-alignment: minimum supported image height alignment (first - cell) and the horizontal image offset (second cell). The values are in pixels - and default to <2 1> when this property is not present; -- samsung,mainscaler-ext: a boolean property indicating whether the FIMC IP - supports extended image size and has CIEXTEN register; -- samsung,rotators: a bitmask specifying whether this IP has the input and - the output rotator. Bits 4 and 0 correspond to input and output rotator - respectively. If a rotator is present its corresponding bit should be set. - Default value when this property is not specified is 0x11. -- samsung,cam-if: a bolean property indicating whether the IP block includes - the camera input interface. -- samsung,isp-wb: this property must be present if the IP block has the ISP - writeback input. -- samsung,lcd-wb: this property must be present if the IP block has the LCD - writeback input. - - -'parallel-ports' node ---------------------- - -This node should contain child 'port' nodes specifying active parallel video -input ports. It includes camera A and camera B inputs. 'reg' property in the -port nodes specifies data input - 1, 2 indicates input A, B respectively. - -Optional properties - -- samsung,camclk-out (deprecated) : specifies clock output for remote sensor, - 0 - CAM_A_CLKOUT, 1 - CAM_B_CLKOUT; - -Image sensor nodes ------------------- - -The sensor device nodes should be added to their control bus controller (e.g. -I2C0) nodes and linked to a port node in the csis or the parallel-ports node, -using the common video interfaces bindings, defined in video-interfaces.txt. - -Example: - - aliases { - fimc0 = &fimc_0; - }; - - /* Parallel bus IF sensor */ - i2c_0: i2c@13860000 { - s5k6aa: sensor@3c { - compatible = "samsung,s5k6aafx"; - reg = <0x3c>; - vddio-supply = <...>; - - clock-frequency = <24000000>; - clocks = <&camera 1>; - clock-names = "mclk"; - - port { - s5k6aa_ep: endpoint { - remote-endpoint = <&fimc0_ep>; - bus-width = <8>; - hsync-active = <0>; - vsync-active = <1>; - pclk-sample = <1>; - }; - }; - }; - - /* MIPI CSI-2 bus IF sensor */ - s5c73m3: sensor@1a { - compatible = "samsung,s5c73m3"; - reg = <0x1a>; - vddio-supply = <...>; - - clock-frequency = <24000000>; - clocks = <&camera 0>; - clock-names = "mclk"; - - port { - s5c73m3_1: endpoint { - data-lanes = <1 2 3 4>; - remote-endpoint = <&csis0_ep>; - }; - }; - }; - }; - - camera { - compatible = "samsung,fimc", "simple-bus"; - clocks = <&clock 132>, <&clock 133>, <&clock 351>, - <&clock 352>; - clock-names = "sclk_cam0", "sclk_cam1", "pxl_async0", - "pxl_async1"; - #clock-cells = <1>; - clock-output-names = "cam_a_clkout", "cam_b_clkout"; - pinctrl-names = "default"; - pinctrl-0 = <&cam_port_a_clk_active>; - #address-cells = <1>; - #size-cells = <1>; - - /* parallel camera ports */ - parallel-ports { - /* camera A input */ - port@1 { - reg = <1>; - fimc0_ep: endpoint { - remote-endpoint = <&s5k6aa_ep>; - bus-width = <8>; - hsync-active = <0>; - vsync-active = <1>; - pclk-sample = <1>; - }; - }; - }; - - fimc_0: fimc@11800000 { - compatible = "samsung,exynos4210-fimc"; - reg = <0x11800000 0x1000>; - interrupts = <0 85 0>; - }; - - csis_0: csis@11880000 { - compatible = "samsung,exynos4210-csis"; - reg = <0x11880000 0x1000>; - interrupts = <0 78 0>; - /* camera C input */ - port@3 { - reg = <3>; - csis0_ep: endpoint { - remote-endpoint = <&s5c73m3_ep>; - data-lanes = <1 2 3 4>; - samsung,csis-hs-settle = <12>; - }; - }; - }; - }; - -The MIPI-CSIS device binding is defined in samsung-mipi-csis.txt. diff --git a/Documentation/devicetree/bindings/media/samsung-mipi-csis.txt b/Documentation/devicetree/bindings/media/samsung-mipi-csis.txt deleted file mode 100644 index a4149c9434ea..000000000000 --- a/Documentation/devicetree/bindings/media/samsung-mipi-csis.txt +++ /dev/null @@ -1,81 +0,0 @@ -Samsung S5P/Exynos SoC series MIPI CSI-2 receiver (MIPI CSIS) -------------------------------------------------------------- - -Required properties: - -- compatible : "samsung,s5pv210-csis" for S5PV210 (S5PC110), - "samsung,exynos4210-csis" for Exynos4210 (S5PC210), - "samsung,exynos4212-csis" for Exynos4212/Exynos4412, - "samsung,exynos5250-csis" for Exynos5250; -- reg : offset and length of the register set for the device; -- interrupts : should contain MIPI CSIS interrupt; the format of the - interrupt specifier depends on the interrupt controller; -- bus-width : maximum number of data lanes supported (SoC specific); -- vddio-supply : MIPI CSIS I/O and PLL voltage supply (e.g. 1.8V); -- vddcore-supply : MIPI CSIS Core voltage supply (e.g. 1.1V); -- clocks : list of clock specifiers, corresponding to entries in - clock-names property; -- clock-names : must contain "csis", "sclk_csis" entries, matching entries - in the clocks property. - -Optional properties: - -- clock-frequency : The IP's main (system bus) clock frequency in Hz, default - value when this property is not specified is 166 MHz; -- samsung,csis-wclk : CSI-2 wrapper clock selection. If this property is present - external clock from CMU will be used, or the bus clock if - if it's not specified. - -The device node should contain one 'port' child node with one child 'endpoint' -node, according to the bindings defined in Documentation/devicetree/bindings/ -media/video-interfaces.txt. The following are properties specific to those nodes. - -port node ---------- - -- reg : (required) must be 3 for camera C input (CSIS0) or 4 for - camera D input (CSIS1); - -endpoint node -------------- - -- data-lanes : (required) an array specifying active physical MIPI-CSI2 - data input lanes and their mapping to logical lanes; the - array's content is unused, only its length is meaningful; - -- samsung,csis-hs-settle : (optional) differential receiver (HS-RX) settle time; - - -Example: - - reg0: regulator@0 { - }; - - reg1: regulator@1 { - }; - -/* SoC properties */ - - csis_0: csis@11880000 { - compatible = "samsung,exynos4210-csis"; - reg = <0x11880000 0x1000>; - interrupts = <0 78 0>; - #address-cells = <1>; - #size-cells = <0>; - }; - -/* Board properties */ - - csis_0: csis@11880000 { - clock-frequency = <166000000>; - vddio-supply = <®0>; - vddcore-supply = <®1>; - port { - reg = <3>; /* 3 - CSIS0, 4 - CSIS1 */ - csis0_ep: endpoint { - remote-endpoint = <...>; - data-lanes = <1>, <2>; - samsung,csis-hs-settle = <12>; - }; - }; - }; diff --git a/Documentation/devicetree/bindings/media/samsung-s5c73m3.txt b/Documentation/devicetree/bindings/media/samsung-s5c73m3.txt deleted file mode 100644 index f0ea9adad442..000000000000 --- a/Documentation/devicetree/bindings/media/samsung-s5c73m3.txt +++ /dev/null @@ -1,97 +0,0 @@ -Samsung S5C73M3 8Mp camera ISP ------------------------------- - -The S5C73M3 camera ISP supports MIPI CSI-2 and parallel (ITU-R BT.656) video -data busses. The I2C bus is the main control bus and additionally the SPI bus -is used, mostly for transferring the firmware to and from the device. Two -slave device nodes corresponding to these control bus interfaces are required -and should be placed under respective bus controller nodes. - -I2C slave device node ---------------------- - -Required properties: - -- compatible : "samsung,s5c73m3"; -- reg : I2C slave address of the sensor; -- vdd-int-supply : digital power supply (1.2V); -- vdda-supply : analog power supply (1.2V); -- vdd-reg-supply : regulator input power supply (2.8V); -- vddio-host-supply : host I/O power supply (1.8V to 2.8V); -- vddio-cis-supply : CIS I/O power supply (1.2V to 1.8V); -- vdd-af-supply : lens power supply (2.8V); -- xshutdown-gpios : specifier of GPIO connected to the XSHUTDOWN pin; -- standby-gpios : specifier of GPIO connected to the STANDBY pin; -- clocks : should contain list of phandle and clock specifier pairs - according to common clock bindings for the clocks described - in the clock-names property; -- clock-names : should contain "cis_extclk" entry for the CIS_EXTCLK clock; - -Optional properties: - -- clock-frequency : the frequency at which the "cis_extclk" clock should be - configured to operate, in Hz; if this property is not - specified default 24 MHz value will be used. - -The common video interfaces bindings (see video-interfaces.txt) should be used -to specify link from the S5C73M3 to an external image data receiver. The S5C73M3 -device node should contain one 'port' child node with an 'endpoint' subnode for -this purpose. The data link from a raw image sensor to the S5C73M3 can be -similarly specified, but it is optional since the S5C73M3 ISP and a raw image -sensor are usually inseparable and form a hybrid module. - -Following properties are valid for the endpoint node(s): - -endpoint subnode ----------------- - -- data-lanes : (optional) specifies MIPI CSI-2 data lanes as covered in - video-interfaces.txt. This sensor doesn't support data lane remapping - and physical lane indexes in subsequent elements of the array should - be only consecutive ascending values. - -SPI device node ---------------- - -Required properties: - -- compatible : "samsung,s5c73m3"; - -For more details see description of the SPI busses bindings -(../spi/spi-bus.txt) and bindings of a specific bus controller. - -Example: - -i2c@138a000000 { - ... - s5c73m3@3c { - compatible = "samsung,s5c73m3"; - reg = <0x3c>; - vdd-int-supply = <&buck9_reg>; - vdda-supply = <&ldo17_reg>; - vdd-reg-supply = <&cam_io_reg>; - vddio-host-supply = <&ldo18_reg>; - vddio-cis-supply = <&ldo9_reg>; - vdd-af-supply = <&cam_af_reg>; - clock-frequency = <24000000>; - clocks = <&clk 0>; - clock-names = "cis_extclk"; - xshutdown-gpios = <&gpf1 3 1>; - standby-gpios = <&gpm0 1 1>; - port { - s5c73m3_ep: endpoint { - remote-endpoint = <&csis0_ep>; - data-lanes = <1 2 3 4>; - }; - }; - }; -}; - -spi@1392000 { - ... - s5c73m3_spi: s5c73m3@0 { - compatible = "samsung,s5c73m3"; - reg = <0>; - ... - }; -}; diff --git a/Documentation/devicetree/bindings/media/samsung-s5k5baf.txt b/Documentation/devicetree/bindings/media/samsung-s5k5baf.txt deleted file mode 100644 index 1f51e0439c96..000000000000 --- a/Documentation/devicetree/bindings/media/samsung-s5k5baf.txt +++ /dev/null @@ -1,58 +0,0 @@ -Samsung S5K5BAF UXGA 1/5" 2M CMOS Image Sensor with embedded SoC ISP --------------------------------------------------------------------- - -Required properties: - -- compatible : "samsung,s5k5baf"; -- reg : I2C slave address of the sensor; -- vdda-supply : analog power supply 2.8V (2.6V to 3.0V); -- vddreg-supply : regulator input power supply 1.8V (1.7V to 1.9V) - or 2.8V (2.6V to 3.0); -- vddio-supply : I/O power supply 1.8V (1.65V to 1.95V) - or 2.8V (2.5V to 3.1V); -- stbyn-gpios : GPIO connected to STDBYN pin; -- rstn-gpios : GPIO connected to RSTN pin; -- clocks : list of phandle and clock specifier pairs - according to common clock bindings for the - clocks described in clock-names; -- clock-names : should include "mclk" for the sensor's master clock; - -Optional properties: - -- clock-frequency : the frequency at which the "mclk" clock should be - configured to operate, in Hz; if this property is not - specified default 24 MHz value will be used. - -The device node should contain one 'port' child node with one child 'endpoint' -node, according to the bindings defined in Documentation/devicetree/bindings/ -media/video-interfaces.txt. The following are properties specific to those -nodes. - -endpoint node -------------- - -- data-lanes : (optional) specifies MIPI CSI-2 data lanes as covered in - video-interfaces.txt. If present it should be <1> - the device - supports only one data lane without re-mapping. - -Example: - -s5k5bafx@2d { - compatible = "samsung,s5k5baf"; - reg = <0x2d>; - vdda-supply = <&cam_io_en_reg>; - vddreg-supply = <&vt_core_15v_reg>; - vddio-supply = <&vtcam_reg>; - stbyn-gpios = <&gpl2 0 1>; - rstn-gpios = <&gpl2 1 1>; - clock-names = "mclk"; - clocks = <&clock_cam 0>; - clock-frequency = <24000000>; - - port { - s5k5bafx_ep: endpoint { - remote-endpoint = <&csis1_ep>; - data-lanes = <1>; - }; - }; -}; diff --git a/Documentation/devicetree/bindings/media/samsung-s5k6a3.txt b/Documentation/devicetree/bindings/media/samsung-s5k6a3.txt deleted file mode 100644 index cce01e82f3e3..000000000000 --- a/Documentation/devicetree/bindings/media/samsung-s5k6a3.txt +++ /dev/null @@ -1,33 +0,0 @@ -Samsung S5K6A3(YX) raw image sensor ---------------------------------- - -S5K6A3(YX) is a raw image sensor with MIPI CSI-2 and CCP2 image data interfaces -and CCI (I2C compatible) control bus. - -Required properties: - -- compatible : "samsung,s5k6a3"; -- reg : I2C slave address of the sensor; -- svdda-supply : core voltage supply; -- svddio-supply : I/O voltage supply; -- afvdd-supply : AF (actuator) voltage supply; -- gpios : specifier of a GPIO connected to the RESET pin; -- clocks : should contain list of phandle and clock specifier pairs - according to common clock bindings for the clocks described - in the clock-names property; -- clock-names : should contain "extclk" entry for the sensor's EXTCLK clock; - -Optional properties: - -- clock-frequency : the frequency at which the "extclk" clock should be - configured to operate, in Hz; if this property is not - specified default 24 MHz value will be used. - -The common video interfaces bindings (see video-interfaces.txt) should be -used to specify link to the image data receiver. The S5K6A3(YX) device -node should contain one 'port' child node with an 'endpoint' subnode. - -Following properties are valid for the endpoint node: - -- data-lanes : (optional) specifies MIPI CSI-2 data lanes as covered in - video-interfaces.txt. The sensor supports only one data lane. diff --git a/Documentation/devicetree/bindings/media/si470x.txt b/Documentation/devicetree/bindings/media/si470x.txt deleted file mode 100644 index a9403558362e..000000000000 --- a/Documentation/devicetree/bindings/media/si470x.txt +++ /dev/null @@ -1,26 +0,0 @@ -* Silicon Labs FM Radio receiver - -The Silicon Labs Si470x is family of FM radio receivers with receive power scan -supporting 76-108 MHz, programmable through an I2C interface. -Some of them includes an RDS encoder. - -Required Properties: -- compatible: Should contain "silabs,si470x" -- reg: the I2C address of the device - -Optional Properties: -- interrupts : The interrupt number -- reset-gpios: GPIO specifier for the chips reset line - -Example: - -&i2c2 { - si470x@63 { - compatible = "silabs,si470x"; - reg = <0x63>; - - interrupt-parent = <&gpj2>; - interrupts = <4 IRQ_TYPE_EDGE_FALLING>; - reset-gpios = <&gpj2 5 GPIO_ACTIVE_HIGH>; - }; -}; diff --git a/Documentation/devicetree/bindings/media/silabs,si470x.yaml b/Documentation/devicetree/bindings/media/silabs,si470x.yaml new file mode 100644 index 000000000000..a3d19c562ca3 --- /dev/null +++ b/Documentation/devicetree/bindings/media/silabs,si470x.yaml @@ -0,0 +1,48 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/media/silabs,si470x.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Silicon Labs Si470x FM Radio Receiver + +maintainers: + - Hans Verkuil <hverkuil@xs4all.nl> + - PaweÅ‚ Chmiel <pawel.mikolaj.chmiel@gmail.com> + +properties: + compatible: + const: silabs,si470x + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + reset-gpios: + maxItems: 1 + +required: + - compatible + - reg + +additionalProperties: false + +examples: + - | + #include <dt-bindings/gpio/gpio.h> + #include <dt-bindings/interrupt-controller/irq.h> + + i2c { + #address-cells = <1>; + #size-cells = <0>; + + fmradio@10 { + compatible = "silabs,si470x"; + reg = <0x10>; + interrupt-parent = <&gpj2>; + interrupts = <4 IRQ_TYPE_EDGE_FALLING>; + reset-gpios = <&gpj2 5 GPIO_ACTIVE_HIGH>; + }; + }; diff --git a/Documentation/devicetree/bindings/media/st,stm32-cec.yaml b/Documentation/devicetree/bindings/media/st,stm32-cec.yaml deleted file mode 100644 index 7f545a587a39..000000000000 --- a/Documentation/devicetree/bindings/media/st,stm32-cec.yaml +++ /dev/null @@ -1,53 +0,0 @@ -# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) -%YAML 1.2 ---- -$id: http://devicetree.org/schemas/media/st,stm32-cec.yaml# -$schema: http://devicetree.org/meta-schemas/core.yaml# - -title: STMicroelectronics STM32 CEC - -maintainers: - - Yannick Fertre <yannick.fertre@foss.st.com> - -properties: - compatible: - const: st,stm32-cec - - reg: - maxItems: 1 - - interrupts: - maxItems: 1 - - clocks: - items: - - description: Module Clock - - description: Bus Clock - - clock-names: - items: - - const: cec - - const: hdmi-cec - -required: - - compatible - - reg - - interrupts - - clocks - - clock-names - -additionalProperties: false - -examples: - - | - #include <dt-bindings/interrupt-controller/arm-gic.h> - #include <dt-bindings/clock/stm32mp1-clks.h> - cec: cec@40006c00 { - compatible = "st,stm32-cec"; - reg = <0x40006c00 0x400>; - interrupts = <GIC_SPI 94 IRQ_TYPE_LEVEL_HIGH>; - clocks = <&rcc CEC_K>, <&clk_lse>; - clock-names = "cec", "hdmi-cec"; - }; - -... diff --git a/Documentation/devicetree/bindings/media/ti,cal.yaml b/Documentation/devicetree/bindings/media/ti,cal.yaml index f8e4d260d10a..478bdbe3d759 100644 --- a/Documentation/devicetree/bindings/media/ti,cal.yaml +++ b/Documentation/devicetree/bindings/media/ti,cal.yaml @@ -47,7 +47,7 @@ properties: maxItems: 1 ti,camerrx-control: - $ref: "/schemas/types.yaml#/definitions/phandle-array" + $ref: /schemas/types.yaml#/definitions/phandle-array items: - items: - description: phandle to device control module diff --git a/Documentation/devicetree/bindings/memory-controllers/mediatek,smi-common.yaml b/Documentation/devicetree/bindings/memory-controllers/mediatek,smi-common.yaml index a8fda30cccbb..2f36ac23604c 100644 --- a/Documentation/devicetree/bindings/memory-controllers/mediatek,smi-common.yaml +++ b/Documentation/devicetree/bindings/memory-controllers/mediatek,smi-common.yaml @@ -43,6 +43,7 @@ properties: - mediatek,mt8195-smi-common-vdo - mediatek,mt8195-smi-common-vpp - mediatek,mt8195-smi-sub-common + - mediatek,mt8365-smi-common - description: for mt7623 items: @@ -133,6 +134,7 @@ allOf: - mediatek,mt8192-smi-common - mediatek,mt8195-smi-common-vdo - mediatek,mt8195-smi-common-vpp + - mediatek,mt8365-smi-common then: properties: diff --git a/Documentation/devicetree/bindings/memory-controllers/mediatek,smi-larb.yaml b/Documentation/devicetree/bindings/memory-controllers/mediatek,smi-larb.yaml index 5f4ac3609887..aee7f6cf1300 100644 --- a/Documentation/devicetree/bindings/memory-controllers/mediatek,smi-larb.yaml +++ b/Documentation/devicetree/bindings/memory-controllers/mediatek,smi-larb.yaml @@ -34,6 +34,10 @@ properties: - const: mediatek,mt7623-smi-larb - const: mediatek,mt2701-smi-larb + - items: + - const: mediatek,mt8365-smi-larb + - const: mediatek,mt8186-smi-larb + reg: maxItems: 1 diff --git a/Documentation/devicetree/bindings/memory-controllers/renesas,dbsc.yaml b/Documentation/devicetree/bindings/memory-controllers/renesas,dbsc.yaml index 7056ccb7eb30..8e3822314b25 100644 --- a/Documentation/devicetree/bindings/memory-controllers/renesas,dbsc.yaml +++ b/Documentation/devicetree/bindings/memory-controllers/renesas,dbsc.yaml @@ -1,8 +1,8 @@ # SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) %YAML 1.2 --- -$id: "http://devicetree.org/schemas/memory-controllers/renesas,dbsc.yaml#" -$schema: "http://devicetree.org/meta-schemas/core.yaml#" +$id: http://devicetree.org/schemas/memory-controllers/renesas,dbsc.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# title: Renesas DDR Bus Controllers diff --git a/Documentation/devicetree/bindings/memory-controllers/renesas,rpc-if.yaml b/Documentation/devicetree/bindings/memory-controllers/renesas,rpc-if.yaml index 30a403b1b79a..56e62cd0b36a 100644 --- a/Documentation/devicetree/bindings/memory-controllers/renesas,rpc-if.yaml +++ b/Documentation/devicetree/bindings/memory-controllers/renesas,rpc-if.yaml @@ -20,7 +20,7 @@ description: | - if it contains "cfi-flash", then HyperFlash is used. allOf: - - $ref: "/schemas/spi/spi-controller.yaml#" + - $ref: /schemas/spi/spi-controller.yaml# properties: compatible: diff --git a/Documentation/devicetree/bindings/memory-controllers/samsung,exynos5422-dmc.yaml b/Documentation/devicetree/bindings/memory-controllers/samsung,exynos5422-dmc.yaml index 098348b2b815..783ac984d898 100644 --- a/Documentation/devicetree/bindings/memory-controllers/samsung,exynos5422-dmc.yaml +++ b/Documentation/devicetree/bindings/memory-controllers/samsung,exynos5422-dmc.yaml @@ -42,7 +42,7 @@ properties: maxItems: 8 devfreq-events: - $ref: '/schemas/types.yaml#/definitions/phandle-array' + $ref: /schemas/types.yaml#/definitions/phandle-array minItems: 1 maxItems: 16 items: @@ -50,7 +50,7 @@ properties: description: phandles of the PPMU events used by the controller. device-handle: - $ref: '/schemas/types.yaml#/definitions/phandle' + $ref: /schemas/types.yaml#/definitions/phandle description: | phandle of the connected DRAM memory device. For more information please refer to jedec,lpddr3.yaml. @@ -73,7 +73,7 @@ properties: - description: registers of DREX1 samsung,syscon-clk: - $ref: '/schemas/types.yaml#/definitions/phandle' + $ref: /schemas/types.yaml#/definitions/phandle description: | Phandle of the clock register set used by the controller, these registers are used for enabling a 'pause' feature and are not exposed by clock diff --git a/Documentation/devicetree/bindings/mfd/dlg,da9063.yaml b/Documentation/devicetree/bindings/mfd/dlg,da9063.yaml index e8e74e91070c..c5a7e10d7d80 100644 --- a/Documentation/devicetree/bindings/mfd/dlg,da9063.yaml +++ b/Documentation/devicetree/bindings/mfd/dlg,da9063.yaml @@ -12,6 +12,11 @@ maintainers: description: | For device-tree bindings of other sub-modules refer to the binding documents under the respective sub-system directories. + Using regulator-{uv,ov}-{warn,error,protection}-microvolt requires special + handling: First, when GP_FB2 is used, it must be ensured that there is no + moment where all voltage monitors are disabled. Next, as da9063 only supports + UV *and* OV monitoring, both must be set to the same severity and value + (0: disable, 1: enable). properties: compatible: @@ -121,11 +126,19 @@ examples: regulator-max-microamp = <2000000>; regulator-boot-on; }; + ldo6 { + /* UNUSED */ + regulator-name = "LDO_6"; + regulator-uv-protection-microvolt = <0>; + regulator-ov-protection-microvolt = <0>; + }; ldo11 { regulator-name = "LDO_11"; regulator-min-microvolt = <900000>; - regulator-max-microvolt = <3600000>; - regulator-boot-on; + regulator-max-microvolt = <900000>; + regulator-uv-protection-microvolt = <1>; + regulator-ov-protection-microvolt = <1>; + regulator-always-on; }; }; }; diff --git a/Documentation/devicetree/bindings/mtd/allwinner,sun4i-a10-nand.yaml b/Documentation/devicetree/bindings/mtd/allwinner,sun4i-a10-nand.yaml index e7ec0c59bca6..9a88870cd865 100644 --- a/Documentation/devicetree/bindings/mtd/allwinner,sun4i-a10-nand.yaml +++ b/Documentation/devicetree/bindings/mtd/allwinner,sun4i-a10-nand.yaml @@ -7,7 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml# title: Allwinner A10 NAND Controller allOf: - - $ref: "nand-controller.yaml" + - $ref: nand-controller.yaml maintainers: - Chen-Yu Tsai <wens@csie.org> diff --git a/Documentation/devicetree/bindings/mtd/arasan,nand-controller.yaml b/Documentation/devicetree/bindings/mtd/arasan,nand-controller.yaml index d028269cdbaa..2fe53cbfbee0 100644 --- a/Documentation/devicetree/bindings/mtd/arasan,nand-controller.yaml +++ b/Documentation/devicetree/bindings/mtd/arasan,nand-controller.yaml @@ -7,7 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml# title: Arasan NAND Flash Controller with ONFI 3.1 support allOf: - - $ref: "nand-controller.yaml" + - $ref: nand-controller.yaml maintainers: - Naga Sureshkumar Relli <naga.sureshkumar.relli@xilinx.com> diff --git a/Documentation/devicetree/bindings/mtd/arm,pl353-nand-r2p1.yaml b/Documentation/devicetree/bindings/mtd/arm,pl353-nand-r2p1.yaml index e552875040e2..f8c0f606f451 100644 --- a/Documentation/devicetree/bindings/mtd/arm,pl353-nand-r2p1.yaml +++ b/Documentation/devicetree/bindings/mtd/arm,pl353-nand-r2p1.yaml @@ -7,7 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml# title: PL353 NAND Controller allOf: - - $ref: "nand-controller.yaml" + - $ref: nand-controller.yaml maintainers: - Miquel Raynal <miquel.raynal@bootlin.com> diff --git a/Documentation/devicetree/bindings/mtd/gpmi-nand.yaml b/Documentation/devicetree/bindings/mtd/gpmi-nand.yaml index 8487089b6e16..ba086c34626d 100644 --- a/Documentation/devicetree/bindings/mtd/gpmi-nand.yaml +++ b/Documentation/devicetree/bindings/mtd/gpmi-nand.yaml @@ -93,7 +93,7 @@ required: unevaluatedProperties: false allOf: - - $ref: "nand-controller.yaml" + - $ref: nand-controller.yaml - if: properties: diff --git a/Documentation/devicetree/bindings/mtd/intel,lgm-ebunand.yaml b/Documentation/devicetree/bindings/mtd/intel,lgm-ebunand.yaml index 8c62c7d3d0cd..cc3def758e00 100644 --- a/Documentation/devicetree/bindings/mtd/intel,lgm-ebunand.yaml +++ b/Documentation/devicetree/bindings/mtd/intel,lgm-ebunand.yaml @@ -7,7 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml# title: Intel LGM SoC NAND Controller allOf: - - $ref: "nand-controller.yaml" + - $ref: nand-controller.yaml maintainers: - Ramuthevar Vadivel Murugan <vadivel.muruganx.ramuthevar@linux.intel.com> diff --git a/Documentation/devicetree/bindings/mtd/jedec,spi-nor.yaml b/Documentation/devicetree/bindings/mtd/jedec,spi-nor.yaml index 3fe981b14e2c..89959e5c47ba 100644 --- a/Documentation/devicetree/bindings/mtd/jedec,spi-nor.yaml +++ b/Documentation/devicetree/bindings/mtd/jedec,spi-nor.yaml @@ -10,7 +10,7 @@ maintainers: - Rob Herring <robh@kernel.org> allOf: - - $ref: "mtd.yaml#" + - $ref: mtd.yaml# - $ref: /schemas/spi/spi-peripheral-props.yaml# properties: @@ -76,6 +76,13 @@ properties: If "broken-flash-reset" is present then having this property does not make any difference. + spi-cpol: true + spi-cpha: true + +dependencies: + spi-cpol: [ spi-cpha ] + spi-cpha: [ spi-cpol ] + unevaluatedProperties: false examples: diff --git a/Documentation/devicetree/bindings/mtd/mtd-physmap.yaml b/Documentation/devicetree/bindings/mtd/mtd-physmap.yaml index 44cd4476d1d3..f8c976898a95 100644 --- a/Documentation/devicetree/bindings/mtd/mtd-physmap.yaml +++ b/Documentation/devicetree/bindings/mtd/mtd-physmap.yaml @@ -14,7 +14,7 @@ description: | file systems on embedded devices. allOf: - - $ref: "mtd.yaml#" + - $ref: mtd.yaml# - $ref: /schemas/memory-controllers/mc-peripheral-props.yaml# properties: diff --git a/Documentation/devicetree/bindings/mtd/mxc-nand.yaml b/Documentation/devicetree/bindings/mtd/mxc-nand.yaml index 7f6f7c9596c4..cf4198e43d7f 100644 --- a/Documentation/devicetree/bindings/mtd/mxc-nand.yaml +++ b/Documentation/devicetree/bindings/mtd/mxc-nand.yaml @@ -10,7 +10,7 @@ maintainers: - Uwe Kleine-König <u.kleine-koenig@pengutronix.de> allOf: - - $ref: "nand-controller.yaml" + - $ref: nand-controller.yaml properties: compatible: diff --git a/Documentation/devicetree/bindings/mtd/nand-chip.yaml b/Documentation/devicetree/bindings/mtd/nand-chip.yaml index 33d079f76c05..609d4a4ddd80 100644 --- a/Documentation/devicetree/bindings/mtd/nand-chip.yaml +++ b/Documentation/devicetree/bindings/mtd/nand-chip.yaml @@ -10,7 +10,7 @@ maintainers: - Miquel Raynal <miquel.raynal@bootlin.com> allOf: - - $ref: "mtd.yaml#" + - $ref: mtd.yaml# description: | This file covers the generic description of a NAND chip. It implies that the diff --git a/Documentation/devicetree/bindings/mtd/nand-controller.yaml b/Documentation/devicetree/bindings/mtd/nand-controller.yaml index efcd415f8641..f70a32d2d9d4 100644 --- a/Documentation/devicetree/bindings/mtd/nand-controller.yaml +++ b/Documentation/devicetree/bindings/mtd/nand-controller.yaml @@ -51,7 +51,7 @@ properties: patternProperties: "^nand@[a-f0-9]$": - $ref: "nand-chip.yaml#" + $ref: nand-chip.yaml# properties: reg: diff --git a/Documentation/devicetree/bindings/mtd/partitions/brcm,bcm4908-partitions.yaml b/Documentation/devicetree/bindings/mtd/partitions/brcm,bcm4908-partitions.yaml index 5bbb1c01ddee..94f0742b375c 100644 --- a/Documentation/devicetree/bindings/mtd/partitions/brcm,bcm4908-partitions.yaml +++ b/Documentation/devicetree/bindings/mtd/partitions/brcm,bcm4908-partitions.yaml @@ -31,7 +31,7 @@ properties: patternProperties: "^partition@[0-9a-f]+$": - $ref: "partition.yaml#" + $ref: partition.yaml# properties: compatible: const: brcm,bcm4908-firmware diff --git a/Documentation/devicetree/bindings/mtd/partitions/linksys,ns-partitions.yaml b/Documentation/devicetree/bindings/mtd/partitions/linksys,ns-partitions.yaml index 213858f60375..c5fa78ff7125 100644 --- a/Documentation/devicetree/bindings/mtd/partitions/linksys,ns-partitions.yaml +++ b/Documentation/devicetree/bindings/mtd/partitions/linksys,ns-partitions.yaml @@ -32,7 +32,7 @@ properties: patternProperties: "^partition@[0-9a-f]+$": - $ref: "partition.yaml#" + $ref: partition.yaml# properties: compatible: items: diff --git a/Documentation/devicetree/bindings/mtd/qcom,nandc.yaml b/Documentation/devicetree/bindings/mtd/qcom,nandc.yaml index 07024ee45951..00c991ffa6c4 100644 --- a/Documentation/devicetree/bindings/mtd/qcom,nandc.yaml +++ b/Documentation/devicetree/bindings/mtd/qcom,nandc.yaml @@ -46,7 +46,7 @@ patternProperties: - 512 allOf: - - $ref: "nand-controller.yaml#" + - $ref: nand-controller.yaml# - if: properties: diff --git a/Documentation/devicetree/bindings/mtd/renesas-nandc.yaml b/Documentation/devicetree/bindings/mtd/renesas-nandc.yaml index f0dc78bb0515..cc6b8274e6a2 100644 --- a/Documentation/devicetree/bindings/mtd/renesas-nandc.yaml +++ b/Documentation/devicetree/bindings/mtd/renesas-nandc.yaml @@ -10,7 +10,7 @@ maintainers: - Miquel Raynal <miquel.raynal@bootlin.com> allOf: - - $ref: "nand-controller.yaml" + - $ref: nand-controller.yaml properties: compatible: diff --git a/Documentation/devicetree/bindings/mtd/rockchip,nand-controller.yaml b/Documentation/devicetree/bindings/mtd/rockchip,nand-controller.yaml index 566f330851f7..7eb1d0a38565 100644 --- a/Documentation/devicetree/bindings/mtd/rockchip,nand-controller.yaml +++ b/Documentation/devicetree/bindings/mtd/rockchip,nand-controller.yaml @@ -7,7 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml# title: Rockchip SoCs NAND FLASH Controller (NFC) allOf: - - $ref: "nand-controller.yaml#" + - $ref: nand-controller.yaml# maintainers: - Heiko Stuebner <heiko@sntech.de> diff --git a/Documentation/devicetree/bindings/mtd/spi-nand.yaml b/Documentation/devicetree/bindings/mtd/spi-nand.yaml index 4d095e613204..77a8727c7966 100644 --- a/Documentation/devicetree/bindings/mtd/spi-nand.yaml +++ b/Documentation/devicetree/bindings/mtd/spi-nand.yaml @@ -10,7 +10,7 @@ maintainers: - Miquel Raynal <miquel.raynal@bootlin.com> allOf: - - $ref: "nand-chip.yaml#" + - $ref: nand-chip.yaml# - $ref: /schemas/spi/spi-peripheral-props.yaml# properties: diff --git a/Documentation/devicetree/bindings/mtd/st,stm32-fmc2-nand.yaml b/Documentation/devicetree/bindings/mtd/st,stm32-fmc2-nand.yaml index 19cf1f18b61c..986e85ccebc7 100644 --- a/Documentation/devicetree/bindings/mtd/st,stm32-fmc2-nand.yaml +++ b/Documentation/devicetree/bindings/mtd/st,stm32-fmc2-nand.yaml @@ -45,7 +45,7 @@ patternProperties: enum: [1, 4, 8] allOf: - - $ref: "nand-controller.yaml#" + - $ref: nand-controller.yaml# - if: properties: diff --git a/Documentation/devicetree/bindings/mtd/ti,gpmc-nand.yaml b/Documentation/devicetree/bindings/mtd/ti,gpmc-nand.yaml index 4ac198814b7a..115682fa81b7 100644 --- a/Documentation/devicetree/bindings/mtd/ti,gpmc-nand.yaml +++ b/Documentation/devicetree/bindings/mtd/ti,gpmc-nand.yaml @@ -63,10 +63,10 @@ properties: patternProperties: "@[0-9a-f]+$": - $ref: "/schemas/mtd/partitions/partition.yaml" + $ref: /schemas/mtd/partitions/partition.yaml allOf: - - $ref: "/schemas/memory-controllers/ti,gpmc-child.yaml" + - $ref: /schemas/memory-controllers/ti,gpmc-child.yaml required: - compatible diff --git a/Documentation/devicetree/bindings/mtd/ti,gpmc-onenand.yaml b/Documentation/devicetree/bindings/mtd/ti,gpmc-onenand.yaml index 8a79ad300216..7d3ace4f5505 100644 --- a/Documentation/devicetree/bindings/mtd/ti,gpmc-onenand.yaml +++ b/Documentation/devicetree/bindings/mtd/ti,gpmc-onenand.yaml @@ -36,10 +36,10 @@ properties: patternProperties: "@[0-9a-f]+$": - $ref: "/schemas/mtd/partitions/partition.yaml" + $ref: /schemas/mtd/partitions/partition.yaml allOf: - - $ref: "/schemas/memory-controllers/ti,gpmc-child.yaml" + - $ref: /schemas/memory-controllers/ti,gpmc-child.yaml required: - compatible diff --git a/Documentation/devicetree/bindings/net/ti,k3-am654-cpsw-nuss.yaml b/Documentation/devicetree/bindings/net/ti,k3-am654-cpsw-nuss.yaml index 900063411a20..837d6db299c4 100644 --- a/Documentation/devicetree/bindings/net/ti,k3-am654-cpsw-nuss.yaml +++ b/Documentation/devicetree/bindings/net/ti,k3-am654-cpsw-nuss.yaml @@ -222,7 +222,6 @@ additionalProperties: false examples: - | - #include <dt-bindings/pinctrl/k3.h> #include <dt-bindings/soc/ti,sci_pm_domain.h> #include <dt-bindings/net/ti-dp83867.h> #include <dt-bindings/interrupt-controller/irq.h> diff --git a/Documentation/devicetree/bindings/nvme/apple,nvme-ans.yaml b/Documentation/devicetree/bindings/nvme/apple,nvme-ans.yaml index 34dd1cc67124..fc6555724e18 100644 --- a/Documentation/devicetree/bindings/nvme/apple,nvme-ans.yaml +++ b/Documentation/devicetree/bindings/nvme/apple,nvme-ans.yaml @@ -14,6 +14,7 @@ properties: items: - enum: - apple,t8103-nvme-ans2 + - apple,t8112-nvme-ans2 - apple,t6000-nvme-ans2 - const: apple,nvme-ans2 @@ -65,7 +66,9 @@ if: properties: compatible: contains: - const: apple,t8103-nvme-ans2 + enum: + - apple,t8103-nvme-ans2 + - apple,t8112-nvme-ans2 then: properties: power-domains: diff --git a/Documentation/devicetree/bindings/pci/apple,pcie.yaml b/Documentation/devicetree/bindings/pci/apple,pcie.yaml index aa38680aaaca..215ff9a9c835 100644 --- a/Documentation/devicetree/bindings/pci/apple,pcie.yaml +++ b/Documentation/devicetree/bindings/pci/apple,pcie.yaml @@ -33,6 +33,7 @@ properties: items: - enum: - apple,t8103-pcie + - apple,t8112-pcie - apple,t6000-pcie - const: apple,pcie diff --git a/Documentation/devicetree/bindings/pinctrl/apple,pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/apple,pinctrl.yaml index d3b11351ca45..684c03a6bd40 100644 --- a/Documentation/devicetree/bindings/pinctrl/apple,pinctrl.yaml +++ b/Documentation/devicetree/bindings/pinctrl/apple,pinctrl.yaml @@ -19,6 +19,7 @@ properties: items: - enum: - apple,t8103-pinctrl + - apple,t8112-pinctrl - apple,t6000-pinctrl - const: apple,pinctrl diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,sm8550-lpass-lpi-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/qcom,sm8550-lpass-lpi-pinctrl.yaml index 5e90051ed314..8f60a9113e7a 100644 --- a/Documentation/devicetree/bindings/pinctrl/qcom,sm8550-lpass-lpi-pinctrl.yaml +++ b/Documentation/devicetree/bindings/pinctrl/qcom,sm8550-lpass-lpi-pinctrl.yaml @@ -96,9 +96,11 @@ $defs: 2: Lower Slew rate (slower edges) 3: Reserved (No adjustments) + bias-bus-hold: true bias-pull-down: true bias-pull-up: true bias-disable: true + input-enable: true output-high: true output-low: true diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,tlmm-common.yaml b/Documentation/devicetree/bindings/pinctrl/qcom,tlmm-common.yaml index cb5ba1bd6f8d..90b7d75840c1 100644 --- a/Documentation/devicetree/bindings/pinctrl/qcom,tlmm-common.yaml +++ b/Documentation/devicetree/bindings/pinctrl/qcom,tlmm-common.yaml @@ -75,7 +75,9 @@ $defs: bias-pull-down: true bias-pull-up: true bias-disable: true - input-enable: true + input-enable: false + output-disable: true + output-enable: true output-high: true output-low: true diff --git a/Documentation/devicetree/bindings/power/apple,pmgr-pwrstate.yaml b/Documentation/devicetree/bindings/power/apple,pmgr-pwrstate.yaml index 94d369eb85de..59a6af735a21 100644 --- a/Documentation/devicetree/bindings/power/apple,pmgr-pwrstate.yaml +++ b/Documentation/devicetree/bindings/power/apple,pmgr-pwrstate.yaml @@ -32,6 +32,7 @@ properties: items: - enum: - apple,t8103-pmgr-pwrstate + - apple,t8112-pmgr-pwrstate - apple,t6000-pmgr-pwrstate - const: apple,pmgr-pwrstate diff --git a/Documentation/devicetree/bindings/regulator/anatop-regulator.yaml b/Documentation/devicetree/bindings/regulator/anatop-regulator.yaml index 0a66338c7e5a..17250378542a 100644 --- a/Documentation/devicetree/bindings/regulator/anatop-regulator.yaml +++ b/Documentation/devicetree/bindings/regulator/anatop-regulator.yaml @@ -10,7 +10,7 @@ maintainers: - Ying-Chun Liu (PaulLiu) <paul.liu@linaro.org> allOf: - - $ref: "regulator.yaml#" + - $ref: regulator.yaml# properties: compatible: @@ -19,43 +19,43 @@ properties: regulator-name: true anatop-reg-offset: - $ref: '/schemas/types.yaml#/definitions/uint32' + $ref: /schemas/types.yaml#/definitions/uint32 description: u32 value representing the anatop MFD register offset. anatop-vol-bit-shift: - $ref: '/schemas/types.yaml#/definitions/uint32' + $ref: /schemas/types.yaml#/definitions/uint32 description: u32 value representing the bit shift for the register. anatop-vol-bit-width: - $ref: '/schemas/types.yaml#/definitions/uint32' + $ref: /schemas/types.yaml#/definitions/uint32 description: u32 value representing the number of bits used in the register. anatop-min-bit-val: - $ref: '/schemas/types.yaml#/definitions/uint32' + $ref: /schemas/types.yaml#/definitions/uint32 description: u32 value representing the minimum value of this register. anatop-min-voltage: - $ref: '/schemas/types.yaml#/definitions/uint32' + $ref: /schemas/types.yaml#/definitions/uint32 description: u32 value representing the minimum voltage of this regulator. anatop-max-voltage: - $ref: '/schemas/types.yaml#/definitions/uint32' + $ref: /schemas/types.yaml#/definitions/uint32 description: u32 value representing the maximum voltage of this regulator. anatop-delay-reg-offset: - $ref: '/schemas/types.yaml#/definitions/uint32' + $ref: /schemas/types.yaml#/definitions/uint32 description: u32 value representing the anatop MFD step time register offset. anatop-delay-bit-shift: - $ref: '/schemas/types.yaml#/definitions/uint32' + $ref: /schemas/types.yaml#/definitions/uint32 description: u32 value representing the bit shift for the step time register. anatop-delay-bit-width: - $ref: '/schemas/types.yaml#/definitions/uint32' + $ref: /schemas/types.yaml#/definitions/uint32 description: u32 value representing the number of bits used in the step time register. anatop-enable-bit: - $ref: '/schemas/types.yaml#/definitions/uint32' + $ref: /schemas/types.yaml#/definitions/uint32 description: u32 value representing regulator enable bit offset. vin-supply: diff --git a/Documentation/devicetree/bindings/regulator/dlg,da9121.yaml b/Documentation/devicetree/bindings/regulator/dlg,da9121.yaml index 63e1161a87de..dc626517c2ad 100644 --- a/Documentation/devicetree/bindings/regulator/dlg,da9121.yaml +++ b/Documentation/devicetree/bindings/regulator/dlg,da9121.yaml @@ -109,7 +109,7 @@ properties: description: Specify a valid GPIO for platform control of the regulator dlg,ripple-cancel: - $ref: "/schemas/types.yaml#/definitions/uint32" + $ref: /schemas/types.yaml#/definitions/uint32 enum: [ 0, 1, 2, 3 ] description: | Defined in include/dt-bindings/regulator/dlg,da9121-regulator.h diff --git a/Documentation/devicetree/bindings/regulator/fcs,fan53555.yaml b/Documentation/devicetree/bindings/regulator/fcs,fan53555.yaml index c0dbba843f70..69bae90fc4b2 100644 --- a/Documentation/devicetree/bindings/regulator/fcs,fan53555.yaml +++ b/Documentation/devicetree/bindings/regulator/fcs,fan53555.yaml @@ -14,12 +14,21 @@ allOf: properties: compatible: - enum: - - fcs,fan53555 - - fcs,fan53526 - - silergy,syr827 - - silergy,syr828 - - tcs,tcs4525 + oneOf: + - enum: + - fcs,fan53555 + - fcs,fan53526 + - rockchip,rk8600 + - rockchip,rk8602 + - silergy,syr827 + - silergy,syr828 + - tcs,tcs4525 + - items: + - const: rockchip,rk8601 + - const: rockchip,rk8600 + - items: + - const: rockchip,rk8603 + - const: rockchip,rk8602 reg: maxItems: 1 diff --git a/Documentation/devicetree/bindings/regulator/fixed-regulator.yaml b/Documentation/devicetree/bindings/regulator/fixed-regulator.yaml index 48af7cba4652..ac0281b1cceb 100644 --- a/Documentation/devicetree/bindings/regulator/fixed-regulator.yaml +++ b/Documentation/devicetree/bindings/regulator/fixed-regulator.yaml @@ -17,7 +17,7 @@ description: to be the same. allOf: - - $ref: "regulator.yaml#" + - $ref: regulator.yaml# - if: properties: compatible: diff --git a/Documentation/devicetree/bindings/regulator/google,cros-ec-regulator.yaml b/Documentation/devicetree/bindings/regulator/google,cros-ec-regulator.yaml index 0921f012c901..e0ff5012b763 100644 --- a/Documentation/devicetree/bindings/regulator/google,cros-ec-regulator.yaml +++ b/Documentation/devicetree/bindings/regulator/google,cros-ec-regulator.yaml @@ -14,7 +14,7 @@ description: regulator.yaml, can also be used. allOf: - - $ref: "regulator.yaml#" + - $ref: regulator.yaml# properties: compatible: diff --git a/Documentation/devicetree/bindings/regulator/gpio-regulator.yaml b/Documentation/devicetree/bindings/regulator/gpio-regulator.yaml index 6c3371d706bb..f4c1f36e52e9 100644 --- a/Documentation/devicetree/bindings/regulator/gpio-regulator.yaml +++ b/Documentation/devicetree/bindings/regulator/gpio-regulator.yaml @@ -15,7 +15,7 @@ description: regulator.txt, can also be used. allOf: - - $ref: "regulator.yaml#" + - $ref: regulator.yaml# properties: compatible: diff --git a/Documentation/devicetree/bindings/regulator/max77650-regulator.yaml b/Documentation/devicetree/bindings/regulator/max77650-regulator.yaml index 01b9775a92d1..27d5e9c2bb93 100644 --- a/Documentation/devicetree/bindings/regulator/max77650-regulator.yaml +++ b/Documentation/devicetree/bindings/regulator/max77650-regulator.yaml @@ -25,7 +25,7 @@ properties: patternProperties: "^regulator-(ldo|sbb[0-2])$": - $ref: "regulator.yaml#" + $ref: regulator.yaml# unevaluatedProperties: false required: diff --git a/Documentation/devicetree/bindings/regulator/max8660.yaml b/Documentation/devicetree/bindings/regulator/max8660.yaml index 35792a927b03..f05f4644c8ee 100644 --- a/Documentation/devicetree/bindings/regulator/max8660.yaml +++ b/Documentation/devicetree/bindings/regulator/max8660.yaml @@ -25,7 +25,7 @@ properties: patternProperties: "^regulator-.+$": - $ref: "regulator.yaml#" + $ref: regulator.yaml# unevaluatedProperties: false additionalProperties: false diff --git a/Documentation/devicetree/bindings/regulator/max8893.yaml b/Documentation/devicetree/bindings/regulator/max8893.yaml index 2b5e977bf409..e40ee798e198 100644 --- a/Documentation/devicetree/bindings/regulator/max8893.yaml +++ b/Documentation/devicetree/bindings/regulator/max8893.yaml @@ -25,7 +25,7 @@ properties: patternProperties: "^(ldo[1-5]|buck)$": - $ref: "regulator.yaml#" + $ref: regulator.yaml# additionalProperties: false diff --git a/Documentation/devicetree/bindings/regulator/mediatek,mt6331-regulator.yaml b/Documentation/devicetree/bindings/regulator/mediatek,mt6331-regulator.yaml index 771cc134393c..79e5198e1c73 100644 --- a/Documentation/devicetree/bindings/regulator/mediatek,mt6331-regulator.yaml +++ b/Documentation/devicetree/bindings/regulator/mediatek,mt6331-regulator.yaml @@ -18,7 +18,7 @@ description: | patternProperties: "^buck-v(core2|io18|dvfs11|dvfs12|dvfs13|dvfs14)$": type: object - $ref: "regulator.yaml#" + $ref: regulator.yaml# properties: regulator-name: @@ -28,7 +28,7 @@ patternProperties: "^ldo-v(avdd32aud|auxa32)$": type: object - $ref: "regulator.yaml#" + $ref: regulator.yaml# properties: regulator-name: @@ -38,7 +38,7 @@ patternProperties: "^ldo-v(dig18|emc33|ibr|mc|mch|mipi|rtc|sram|usb10)$": type: object - $ref: "regulator.yaml#" + $ref: regulator.yaml# properties: regulator-name: @@ -48,7 +48,7 @@ patternProperties: "^ldo-vcam(a|af|d|io)$": type: object - $ref: "regulator.yaml#" + $ref: regulator.yaml# properties: regulator-name: @@ -58,7 +58,7 @@ patternProperties: "^ldo-vtcxo[12]$": type: object - $ref: "regulator.yaml#" + $ref: regulator.yaml# properties: regulator-name: @@ -71,7 +71,7 @@ patternProperties: "^ldo-vgp[1234]$": type: object - $ref: "regulator.yaml#" + $ref: regulator.yaml# properties: regulator-name: diff --git a/Documentation/devicetree/bindings/regulator/mediatek,mt6332-regulator.yaml b/Documentation/devicetree/bindings/regulator/mediatek,mt6332-regulator.yaml index 3218f43e6957..2eb512c29a0d 100644 --- a/Documentation/devicetree/bindings/regulator/mediatek,mt6332-regulator.yaml +++ b/Documentation/devicetree/bindings/regulator/mediatek,mt6332-regulator.yaml @@ -18,7 +18,7 @@ description: | patternProperties: "^buck-v(dram|dvfs2|pa|rf18a|rf18b|sbst)$": type: object - $ref: "regulator.yaml#" + $ref: regulator.yaml# properties: regulator-name: @@ -28,7 +28,7 @@ patternProperties: "^ldo-v(bif28|dig18|sram|usb33)$": type: object - $ref: "regulator.yaml#" + $ref: regulator.yaml# properties: regulator-name: diff --git a/Documentation/devicetree/bindings/regulator/mps,mp5416.yaml b/Documentation/devicetree/bindings/regulator/mps,mp5416.yaml index 7023c597c3ed..2e720d152890 100644 --- a/Documentation/devicetree/bindings/regulator/mps,mp5416.yaml +++ b/Documentation/devicetree/bindings/regulator/mps,mp5416.yaml @@ -28,11 +28,11 @@ properties: patternProperties: "^buck[1-4]$": - $ref: "regulator.yaml#" + $ref: regulator.yaml# type: object "^ldo[1-4]$": - $ref: "regulator.yaml#" + $ref: regulator.yaml# type: object additionalProperties: false diff --git a/Documentation/devicetree/bindings/regulator/mps,mp886x.yaml b/Documentation/devicetree/bindings/regulator/mps,mp886x.yaml index 9245b7199439..374a4f6b1e23 100644 --- a/Documentation/devicetree/bindings/regulator/mps,mp886x.yaml +++ b/Documentation/devicetree/bindings/regulator/mps,mp886x.yaml @@ -28,7 +28,7 @@ properties: mps,fb-voltage-divider: description: An array of two integers containing the resistor values R1 and R2 of the feedback voltage divider in kilo ohms. - $ref: "/schemas/types.yaml#/definitions/uint32-array" + $ref: /schemas/types.yaml#/definitions/uint32-array maxItems: 2 mps,switch-frequency-hz: diff --git a/Documentation/devicetree/bindings/regulator/mps,mpq7920.yaml b/Documentation/devicetree/bindings/regulator/mps,mpq7920.yaml index c2e8c54e5311..f3fcfc8be72f 100644 --- a/Documentation/devicetree/bindings/regulator/mps,mpq7920.yaml +++ b/Documentation/devicetree/bindings/regulator/mps,mpq7920.yaml @@ -29,7 +29,7 @@ properties: properties: mps,switch-freq: - $ref: "/schemas/types.yaml#/definitions/uint8" + $ref: /schemas/types.yaml#/definitions/uint8 enum: [0, 1, 2, 3] default: 2 description: | @@ -51,14 +51,14 @@ properties: properties: mps,buck-softstart: - $ref: "/schemas/types.yaml#/definitions/uint8" + $ref: /schemas/types.yaml#/definitions/uint8 enum: [0, 1, 2, 3] description: | defines the soft start time of this buck, must be one of the following corresponding values 150us, 300us, 610us, 920us mps,buck-phase-delay: - $ref: "/schemas/types.yaml#/definitions/uint8" + $ref: /schemas/types.yaml#/definitions/uint8 enum: [0, 1, 2, 3] description: | defines the phase delay of this buck, must be one of the following diff --git a/Documentation/devicetree/bindings/regulator/mt6315-regulator.yaml b/Documentation/devicetree/bindings/regulator/mt6315-regulator.yaml index 364b58730be2..6317daf76d1f 100644 --- a/Documentation/devicetree/bindings/regulator/mt6315-regulator.yaml +++ b/Documentation/devicetree/bindings/regulator/mt6315-regulator.yaml @@ -28,7 +28,7 @@ properties: patternProperties: "^vbuck[1-4]$": type: object - $ref: "regulator.yaml#" + $ref: regulator.yaml# unevaluatedProperties: false properties: diff --git a/Documentation/devicetree/bindings/regulator/mt6359-regulator.yaml b/Documentation/devicetree/bindings/regulator/mt6359-regulator.yaml index 8cc413eb482d..d6b3b5a5c0b3 100644 --- a/Documentation/devicetree/bindings/regulator/mt6359-regulator.yaml +++ b/Documentation/devicetree/bindings/regulator/mt6359-regulator.yaml @@ -17,7 +17,7 @@ description: | patternProperties: "^buck_v(s1|gpu11|modem|pu|core|s2|pa|proc2|proc1|core_sshub)$": type: object - $ref: "regulator.yaml#" + $ref: regulator.yaml# properties: regulator-name: @@ -27,7 +27,7 @@ patternProperties: "^ldo_v(ibr|rf12|usb|camio|efuse|xo22)$": type: object - $ref: "regulator.yaml#" + $ref: regulator.yaml# properties: regulator-name: @@ -37,7 +37,7 @@ patternProperties: "^ldo_v(rfck|emc|a12|a09|ufs|bbck)$": type: object - $ref: "regulator.yaml#" + $ref: regulator.yaml# properties: regulator-name: @@ -47,7 +47,7 @@ patternProperties: "^ldo_vcn(18|13|33_1_bt|13_1_wifi|33_2_bt|33_2_wifi)$": type: object - $ref: "regulator.yaml#" + $ref: regulator.yaml# properties: regulator-name: @@ -57,7 +57,7 @@ patternProperties: "^ldo_vsram_(proc2|others|md|proc1|others_sshub)$": type: object - $ref: "regulator.yaml#" + $ref: regulator.yaml# properties: regulator-name: @@ -67,7 +67,7 @@ patternProperties: "^ldo_v(fe|bif|io)28$": type: object - $ref: "regulator.yaml#" + $ref: regulator.yaml# properties: regulator-name: @@ -77,7 +77,7 @@ patternProperties: "^ldo_v(aud|io|aux|rf|m)18$": type: object - $ref: "regulator.yaml#" + $ref: regulator.yaml# properties: regulator-name: @@ -87,7 +87,7 @@ patternProperties: "^ldo_vsim[12]$": type: object - $ref: "regulator.yaml#" + $ref: regulator.yaml# properties: regulator-name: diff --git a/Documentation/devicetree/bindings/regulator/mt6360-regulator.yaml b/Documentation/devicetree/bindings/regulator/mt6360-regulator.yaml index 8a0931dc2f30..9c879bc3c360 100644 --- a/Documentation/devicetree/bindings/regulator/mt6360-regulator.yaml +++ b/Documentation/devicetree/bindings/regulator/mt6360-regulator.yaml @@ -26,11 +26,11 @@ properties: patternProperties: "^buck[12]$": - $ref: "regulator.yaml#" + $ref: regulator.yaml# unevaluatedProperties: false "^ldo[123567]$": - $ref: "regulator.yaml#" + $ref: regulator.yaml# unevaluatedProperties: false required: diff --git a/Documentation/devicetree/bindings/regulator/nxp,pca9450-regulator.yaml b/Documentation/devicetree/bindings/regulator/nxp,pca9450-regulator.yaml index 835b53302db8..d2383e523875 100644 --- a/Documentation/devicetree/bindings/regulator/nxp,pca9450-regulator.yaml +++ b/Documentation/devicetree/bindings/regulator/nxp,pca9450-regulator.yaml @@ -57,7 +57,7 @@ properties: properties: nxp,dvs-run-voltage: - $ref: "/schemas/types.yaml#/definitions/uint32" + $ref: /schemas/types.yaml#/definitions/uint32 minimum: 600000 maximum: 2187500 description: @@ -65,7 +65,7 @@ properties: dvs(dynamic voltage scaling) property. nxp,dvs-standby-voltage: - $ref: "/schemas/types.yaml#/definitions/uint32" + $ref: /schemas/types.yaml#/definitions/uint32 minimum: 600000 maximum: 2187500 description: diff --git a/Documentation/devicetree/bindings/regulator/nxp,pf8x00-regulator.yaml b/Documentation/devicetree/bindings/regulator/nxp,pf8x00-regulator.yaml index aabf50f5b39e..6b1c6a176dbe 100644 --- a/Documentation/devicetree/bindings/regulator/nxp,pf8x00-regulator.yaml +++ b/Documentation/devicetree/bindings/regulator/nxp,pf8x00-regulator.yaml @@ -38,12 +38,6 @@ properties: description: Properties for single LDO regulator. - properties: - regulator-name: - pattern: "^ldo[1-4]$" - description: - should be "ldo1", ..., "ldo4" - unevaluatedProperties: false "^buck[1-7]$": @@ -53,13 +47,8 @@ properties: Properties for single BUCK regulator. properties: - regulator-name: - pattern: "^buck[1-7]$" - description: - should be "buck1", ..., "buck7" - nxp,ilim-ma: - $ref: "/schemas/types.yaml#/definitions/uint32" + $ref: /schemas/types.yaml#/definitions/uint32 minimum: 2100 maximum: 4500 deprecated: true @@ -75,7 +64,7 @@ properties: 4500 nxp,phase-shift: - $ref: "/schemas/types.yaml#/definitions/uint32" + $ref: /schemas/types.yaml#/definitions/uint32 default: 0 enum: [ 0, 45, 90, 135, 180, 225, 270, 315 ] description: @@ -90,12 +79,6 @@ properties: description: Properties for single VSNVS regulator. - properties: - regulator-name: - pattern: "^vsnvs$" - description: - should be "vsnvs" - unevaluatedProperties: false additionalProperties: false diff --git a/Documentation/devicetree/bindings/regulator/pfuze100.yaml b/Documentation/devicetree/bindings/regulator/pfuze100.yaml index a26bbd68b729..67a30b23b92c 100644 --- a/Documentation/devicetree/bindings/regulator/pfuze100.yaml +++ b/Documentation/devicetree/bindings/regulator/pfuze100.yaml @@ -63,19 +63,19 @@ properties: patternProperties: "^sw([1-4]|[1-4][a-c]|[1-4][a-c][a-c])$": - $ref: "regulator.yaml#" + $ref: regulator.yaml# type: object "^vgen[1-6]$": - $ref: "regulator.yaml#" + $ref: regulator.yaml# type: object "^vldo[1-4]$": - $ref: "regulator.yaml#" + $ref: regulator.yaml# type: object "^(vsnvs|vref|vrefddr|swbst|coin|v33|vccsd)$": - $ref: "regulator.yaml#" + $ref: regulator.yaml# type: object additionalProperties: false diff --git a/Documentation/devicetree/bindings/regulator/qcom,rpmh-regulator.yaml b/Documentation/devicetree/bindings/regulator/qcom,rpmh-regulator.yaml index 297a75069f60..b9498504ad79 100644 --- a/Documentation/devicetree/bindings/regulator/qcom,rpmh-regulator.yaml +++ b/Documentation/devicetree/bindings/regulator/qcom,rpmh-regulator.yaml @@ -75,9 +75,12 @@ properties: - qcom,pm8550ve-rpmh-regulators - qcom,pm8550vs-rpmh-regulators - qcom,pm8998-rpmh-regulators + - qcom,pmc8180-rpmh-regulators + - qcom,pmc8180c-rpmh-regulators - qcom,pmg1110-rpmh-regulators - qcom,pmi8998-rpmh-regulators - qcom,pmm8155au-rpmh-regulators + - qcom,pmm8654au-rpmh-regulators - qcom,pmr735a-rpmh-regulators - qcom,pmx55-rpmh-regulators - qcom,pmx65-rpmh-regulators @@ -105,18 +108,18 @@ properties: bob: type: object - $ref: "regulator.yaml#" + $ref: regulator.yaml# description: BOB regulator node. dependencies: - regulator-allow-set-load: ["regulator-allowed-modes"] + regulator-allow-set-load: [ regulator-allowed-modes ] patternProperties: "^(smps|ldo|lvs|bob)[0-9]+$": type: object - $ref: "regulator.yaml#" + $ref: regulator.yaml# description: smps/ldo regulator nodes(s). dependencies: - regulator-allow-set-load: ["regulator-allowed-modes"] + regulator-allow-set-load: [ regulator-allowed-modes ] required: - compatible @@ -144,6 +147,8 @@ allOf: compatible: enum: - qcom,pm6150l-rpmh-regulators + - qcom,pm8150l-rpmh-regulators + - qcom,pmc8180c-rpmh-regulators then: properties: vdd-bob-supply: @@ -232,6 +237,7 @@ allOf: compatible: enum: - qcom,pm8150-rpmh-regulators + - qcom,pmc8180-rpmh-regulators - qcom,pmm8155au-rpmh-regulators then: properties: @@ -248,18 +254,17 @@ allOf: properties: compatible: enum: - - qcom,pm8150l-rpmh-regulators + - qcom,pmm8654au-rpmh-regulators then: properties: - vdd-bob-supply: - description: BOB regulator parent supply phandle. - vdd-l1-l8-supply: true + vdd-l1-supply: true vdd-l2-l3-supply: true - vdd-l4-l5-l6-supply: true - vdd-l7-l11-supply: true - vdd-l9-l10-supply: true + vdd-l4-supply: true + vdd-l5-supply: true + vdd-l6-l7-supply: true + vdd-l8-l9-supply: true patternProperties: - "^vdd-s[1-8]-supply$": true + "^vdd-s[1-9]-supply$": true - if: properties: @@ -308,16 +313,15 @@ allOf: compatible: enum: - qcom,pm8550-rpmh-regulators - - qcom,pm8550ve-rpmh-regulators - - qcom,pm8550vs-rpmh-regulators then: properties: + vdd-l1-l4-l10-supply: true vdd-l2-l13-l14-supply: true vdd-l5-l16-supply: true vdd-l6-l7-supply: true vdd-l8-l9-supply: true patternProperties: - "^vdd-l([1-4]|1[0-7])-supply$": true + "^vdd-l(3|1[1-7])-supply$": true "^vdd-s[1-6]-supply$": true "^vdd-bob[1-2]-supply$": true @@ -325,6 +329,17 @@ allOf: properties: compatible: enum: + - qcom,pm8550ve-rpmh-regulators + - qcom,pm8550vs-rpmh-regulators + then: + patternProperties: + "^vdd-l[1-3]-supply$": true + "^vdd-s[1-6]-supply$": true + + - if: + properties: + compatible: + enum: - qcom,pm8998-rpmh-regulators then: properties: diff --git a/Documentation/devicetree/bindings/regulator/qcom,smd-rpm-regulator.yaml b/Documentation/devicetree/bindings/regulator/qcom,smd-rpm-regulator.yaml index 8c45f53212b1..a8ca8e0b27f8 100644 --- a/Documentation/devicetree/bindings/regulator/qcom,smd-rpm-regulator.yaml +++ b/Documentation/devicetree/bindings/regulator/qcom,smd-rpm-regulator.yaml @@ -22,7 +22,7 @@ description: Each sub-node is identified using the node's name, with valid values listed for each of the pmics below. - For mp5496, s2 + For mp5496, s1, s2 For pm2250, s1, s2, s3, s4, l1, l2, l3, l4, l5, l6, l7, l8, l9, l10, l11, l12, l13, l14, l15, l16, l17, l18, l19, l20, l21, l22 diff --git a/Documentation/devicetree/bindings/regulator/raspberrypi,7inch-touchscreen-panel-regulator.yaml b/Documentation/devicetree/bindings/regulator/raspberrypi,7inch-touchscreen-panel-regulator.yaml index 0ae25d119b6f..41678400e63f 100644 --- a/Documentation/devicetree/bindings/regulator/raspberrypi,7inch-touchscreen-panel-regulator.yaml +++ b/Documentation/devicetree/bindings/regulator/raspberrypi,7inch-touchscreen-panel-regulator.yaml @@ -15,7 +15,7 @@ description: | and control the backlight. allOf: - - $ref: "regulator.yaml#" + - $ref: regulator.yaml# properties: compatible: diff --git a/Documentation/devicetree/bindings/regulator/regulator.yaml b/Documentation/devicetree/bindings/regulator/regulator.yaml index 53b81d8a2d41..e158c2d3d3f9 100644 --- a/Documentation/devicetree/bindings/regulator/regulator.yaml +++ b/Documentation/devicetree/bindings/regulator/regulator.yaml @@ -13,7 +13,7 @@ maintainers: properties: regulator-name: description: A string used as a descriptive name for regulator outputs - $ref: "/schemas/types.yaml#/definitions/string" + $ref: /schemas/types.yaml#/definitions/string regulator-min-microvolt: description: smallest voltage consumers may set @@ -23,7 +23,7 @@ properties: regulator-microvolt-offset: description: Offset applied to voltages to compensate for voltage drops - $ref: "/schemas/types.yaml#/definitions/uint32" + $ref: /schemas/types.yaml#/definitions/uint32 regulator-min-microamp: description: smallest current consumers may set @@ -59,7 +59,7 @@ properties: description: ramp delay for regulator(in uV/us) For hardware which supports disabling ramp rate, it should be explicitly initialised to zero (regulator-ramp-delay = <0>) for disabling ramp delay. - $ref: "/schemas/types.yaml#/definitions/uint32" + $ref: /schemas/types.yaml#/definitions/uint32 regulator-enable-ramp-delay: description: The time taken, in microseconds, for the supply rail to @@ -68,7 +68,7 @@ properties: required due to the combination of internal ramping of the regulator itself, and board design issues such as trace capacitance and load on the supply. - $ref: "/schemas/types.yaml#/definitions/uint32" + $ref: /schemas/types.yaml#/definitions/uint32 regulator-settling-time-us: description: Settling time, in microseconds, for voltage change if regulator @@ -95,7 +95,7 @@ properties: description: initial operating mode. The set of possible operating modes depends on the capabilities of every hardware so each device binding documentation explains which values the regulator supports. - $ref: "/schemas/types.yaml#/definitions/uint32" + $ref: /schemas/types.yaml#/definitions/uint32 regulator-allowed-modes: description: list of operating modes that software is allowed to configure @@ -103,12 +103,12 @@ properties: The set of possible operating modes depends on the capabilities of every hardware so each device binding document explains which values the regulator supports. - $ref: "/schemas/types.yaml#/definitions/uint32-array" + $ref: /schemas/types.yaml#/definitions/uint32-array regulator-system-load: description: Load in uA present on regulator that is not captured by any consumer request. - $ref: "/schemas/types.yaml#/definitions/uint32" + $ref: /schemas/types.yaml#/definitions/uint32 regulator-pull-down: description: Enable pull down resistor when the regulator is disabled. @@ -206,14 +206,14 @@ properties: 0: Disable active discharge. 1: Enable active discharge. Absence of this property will leave configuration to default. - $ref: "/schemas/types.yaml#/definitions/uint32" + $ref: /schemas/types.yaml#/definitions/uint32 enum: [0, 1] regulator-coupled-with: description: Regulators with which the regulator is coupled. The linkage is 2-way - all coupled regulators should be linked with each other. A regulator should not be coupled with its supplier. - $ref: "/schemas/types.yaml#/definitions/phandle-array" + $ref: /schemas/types.yaml#/definitions/phandle-array items: maxItems: 1 @@ -221,7 +221,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-array" + $ref: /schemas/types.yaml#/definitions/uint32-array regulator-max-step-microvolt: description: Maximum difference between current and target voltages @@ -269,7 +269,7 @@ patternProperties: of possible operating modes depends on the capabilities of every hardware so the valid modes are documented on each regulator device tree binding document. - $ref: "/schemas/types.yaml#/definitions/uint32" + $ref: /schemas/types.yaml#/definitions/uint32 additionalProperties: false diff --git a/Documentation/devicetree/bindings/regulator/richtek,rt4803.yaml b/Documentation/devicetree/bindings/regulator/richtek,rt4803.yaml new file mode 100644 index 000000000000..6ceba022e550 --- /dev/null +++ b/Documentation/devicetree/bindings/regulator/richtek,rt4803.yaml @@ -0,0 +1,68 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/regulator/richtek,rt4803.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Richtek RT4803 Boost Regulator + +maintainers: + - ChiYuan Huang <cy_huang@richtek.com> + +description: | + RT4803 is a boost regulator that's designed to provide the minimum output + voltage, even if the input voltage is lower than the required voltage. It + supports boost and auto bypass mode that depends on the difference between the + input and output voltage. If the input is lower than the output, mode will + transform to boost mode. Otherwise, turn on bypass switch to enter bypass mode. + + Datasheet is available at + https://www.richtek.com/assets/product_file/RT4803/DS4803-03.pdf + https://www.richtek.com/assets/product_file/RT4803A/DS4803A-06.pdf + +allOf: + - $ref: regulator.yaml# + +properties: + compatible: + enum: + - richtek,rt4803 + + reg: + maxItems: 1 + + richtek,vsel-active-high: + type: boolean + description: Specify the VSEL register group is using when system is active + + regulator-allowed-modes: + description: | + Available operating mode + 1: Auto PFM/PWM + 2: Force PWM + items: + enum: [1, 2] + +required: + - compatible + - reg + +unevaluatedProperties: false + +examples: + - | + i2c { + #address-cells = <1>; + #size-cells = <0>; + + regulator@75 { + compatible = "richtek,rt4803"; + reg = <0x75>; + richtek,vsel-active-high; + regulator-name = "rt4803-regulator"; + regulator-min-microvolt = <2850000>; + regulator-max-microvolt = <4400000>; + regulator-allowed-modes = <1 2>; + regulator-always-on; + }; + }; diff --git a/Documentation/devicetree/bindings/regulator/richtek,rt5739.yaml b/Documentation/devicetree/bindings/regulator/richtek,rt5739.yaml new file mode 100644 index 000000000000..358297dd3fb7 --- /dev/null +++ b/Documentation/devicetree/bindings/regulator/richtek,rt5739.yaml @@ -0,0 +1,72 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/regulator/richtek,rt5739.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Richtek RT5739 Step-Down Buck Converter + +maintainers: + - ChiYuan Huang <cy_huang@richtek.com> + +description: | + The RT5739 is a step-down switching buck converter that can deliver the + programmable output voltage from 300mV to 1300mV with wide input voltage + supply of 2.5V to 5.5V. It can provide up to 3.5A continuous current + capability at over 80% high efficiency. + +allOf: + - $ref: regulator.yaml# + +properties: + compatible: + enum: + - richtek,rt5739 + + reg: + maxItems: 1 + + enable-gpios: + maxItems: 1 + + richtek,vsel-active-high: + description: | + If property is present, use the 'VSEL1' register group for buck control. + Else, use the 'VSEL0' register group. This depends on external hardware + 'VSEL' pin connection. + type: boolean + + regulator-allowed-modes: + description: | + buck allowed operating mode + 0: Auto PFM/PWM mode + 1: Forced PWM mode + items: + enum: [0, 1] + +required: + - compatible + - reg + +unevaluatedProperties: false + +examples: + - | + #include <dt-bindings/gpio/gpio.h> + + i2c { + #address-cells = <1>; + #size-cells = <0>; + + regulator@50 { + compatible = "richtek,rt5739"; + reg = <0x50>; + enable-gpios = <&gpio26 1 GPIO_ACTIVE_HIGH>; + richtek,vsel-active-high; + regulator-name = "richtek,rt5739-buck"; + regulator-min-microvolt = <300000>; + regulator-max-microvolt = <1300000>; + regulator-allowed-modes = <0 1>; + regulator-boot-on; + }; + }; diff --git a/Documentation/devicetree/bindings/regulator/richtek,rt6245-regulator.yaml b/Documentation/devicetree/bindings/regulator/richtek,rt6245-regulator.yaml index e983d0e70c9b..b73762e151bb 100644 --- a/Documentation/devicetree/bindings/regulator/richtek,rt6245-regulator.yaml +++ b/Documentation/devicetree/bindings/regulator/richtek,rt6245-regulator.yaml @@ -32,7 +32,7 @@ properties: maxItems: 1 richtek,oc-level-select: - $ref: "/schemas/types.yaml#/definitions/uint8" + $ref: /schemas/types.yaml#/definitions/uint8 enum: [0, 1, 2, 3] description: | Over current level selection. Each respective value means the current @@ -40,7 +40,7 @@ properties: in chip default. richtek,ot-level-select: - $ref: "/schemas/types.yaml#/definitions/uint8" + $ref: /schemas/types.yaml#/definitions/uint8 enum: [0, 1, 2] description: | Over temperature level selection. Each respective value means the degree @@ -48,7 +48,7 @@ properties: default. richtek,pgdly-time-select: - $ref: "/schemas/types.yaml#/definitions/uint8" + $ref: /schemas/types.yaml#/definitions/uint8 enum: [0, 1, 2, 3] description: | Power good signal delay time selection. Each respective value means the @@ -57,7 +57,7 @@ properties: richtek,switch-freq-select: - $ref: "/schemas/types.yaml#/definitions/uint8" + $ref: /schemas/types.yaml#/definitions/uint8 enum: [0, 1, 2] description: | Buck switch frequency selection. Each respective value means 400KHz, diff --git a/Documentation/devicetree/bindings/regulator/richtek,rtmv20-regulator.yaml b/Documentation/devicetree/bindings/regulator/richtek,rtmv20-regulator.yaml index a8ccb5cb8d77..446ec5127d1f 100644 --- a/Documentation/devicetree/bindings/regulator/richtek,rtmv20-regulator.yaml +++ b/Documentation/devicetree/bindings/regulator/richtek,rtmv20-regulator.yaml @@ -120,7 +120,7 @@ properties: lsw: description: load switch current regulator description. type: object - $ref: "regulator.yaml#" + $ref: regulator.yaml# required: - compatible diff --git a/Documentation/devicetree/bindings/regulator/rohm,bd71815-regulator.yaml b/Documentation/devicetree/bindings/regulator/rohm,bd71815-regulator.yaml index 027fab3dc181..cc4ceb32e9d6 100644 --- a/Documentation/devicetree/bindings/regulator/rohm,bd71815-regulator.yaml +++ b/Documentation/devicetree/bindings/regulator/rohm,bd71815-regulator.yaml @@ -56,7 +56,7 @@ patternProperties: PMIC "RUN" state voltage in uV when PMIC HW states are used. See comments below for bucks/LDOs which support this. 0 means regulator should be disabled at RUN state. - $ref: "/schemas/types.yaml#/definitions/uint32" + $ref: /schemas/types.yaml#/definitions/uint32 minimum: 0 maximum: 3300000 @@ -67,7 +67,7 @@ patternProperties: keeps regulator enabled. BD71815 does not change voltage level when PMIC transitions to SNVS.SNVS voltage depends on the previous state (from which the PMIC transitioned to SNVS). - $ref: "/schemas/types.yaml#/definitions/uint32" + $ref: /schemas/types.yaml#/definitions/uint32 minimum: 0 maximum: 3300000 @@ -76,7 +76,7 @@ patternProperties: PMIC "SUSPEND" state voltage in uV when PMIC HW states are used. See comments below for bucks/LDOs which support this. 0 means regulator should be disabled at SUSPEND state. - $ref: "/schemas/types.yaml#/definitions/uint32" + $ref: /schemas/types.yaml#/definitions/uint32 minimum: 0 maximum: 3300000 @@ -85,7 +85,7 @@ patternProperties: PMIC "LPSR" state voltage in uV when PMIC HW states are used. See comments below for bucks/LDOs which support this. 0 means regulator should be disabled at LPSR state. - $ref: "/schemas/types.yaml#/definitions/uint32" + $ref: /schemas/types.yaml#/definitions/uint32 minimum: 0 maximum: 3300000 diff --git a/Documentation/devicetree/bindings/regulator/rohm,bd71828-regulator.yaml b/Documentation/devicetree/bindings/regulator/rohm,bd71828-regulator.yaml index 3cbe3b76ccee..19b253c09e97 100644 --- a/Documentation/devicetree/bindings/regulator/rohm,bd71828-regulator.yaml +++ b/Documentation/devicetree/bindings/regulator/rohm,bd71828-regulator.yaml @@ -52,7 +52,7 @@ patternProperties: description: PMIC default "RUN" state voltage in uV. See below table for bucks which support this. 0 means disabled. - $ref: "/schemas/types.yaml#/definitions/uint32" + $ref: /schemas/types.yaml#/definitions/uint32 minimum: 0 maximum: 3300000 @@ -60,7 +60,7 @@ patternProperties: description: PMIC default "IDLE" state voltage in uV. See below table for bucks which support this. 0 means disabled. - $ref: "/schemas/types.yaml#/definitions/uint32" + $ref: /schemas/types.yaml#/definitions/uint32 minimum: 0 maximum: 3300000 @@ -68,7 +68,7 @@ patternProperties: description: PMIC default "SUSPEND" state voltage in uV. See below table for bucks which support this. 0 means disabled. - $ref: "/schemas/types.yaml#/definitions/uint32" + $ref: /schemas/types.yaml#/definitions/uint32 minimum: 0 maximum: 3300000 @@ -76,7 +76,7 @@ patternProperties: description: PMIC default "LPSR" state voltage in uV. See below table for bucks which support this. 0 means disabled. - $ref: "/schemas/types.yaml#/definitions/uint32" + $ref: /schemas/types.yaml#/definitions/uint32 minimum: 0 maximum: 3300000 diff --git a/Documentation/devicetree/bindings/regulator/rohm,bd71837-regulator.yaml b/Documentation/devicetree/bindings/regulator/rohm,bd71837-regulator.yaml index ab842817d847..6e693fee3493 100644 --- a/Documentation/devicetree/bindings/regulator/rohm,bd71837-regulator.yaml +++ b/Documentation/devicetree/bindings/regulator/rohm,bd71837-regulator.yaml @@ -55,7 +55,7 @@ patternProperties: should be "buck1", ..., "buck8" rohm,dvs-run-voltage: - $ref: "/schemas/types.yaml#/definitions/uint32" + $ref: /schemas/types.yaml#/definitions/uint32 minimum: 0 maximum: 1300000 description: @@ -63,7 +63,7 @@ patternProperties: bucks which support this. 0 means disabled. rohm,dvs-idle-voltage: - $ref: "/schemas/types.yaml#/definitions/uint32" + $ref: /schemas/types.yaml#/definitions/uint32 minimum: 0 maximum: 1300000 description: @@ -71,7 +71,7 @@ patternProperties: bucks which support this. 0 means disabled. rohm,dvs-suspend-voltage: - $ref: "/schemas/types.yaml#/definitions/uint32" + $ref: /schemas/types.yaml#/definitions/uint32 minimum: 0 maximum: 1300000 description: diff --git a/Documentation/devicetree/bindings/regulator/rohm,bd71847-regulator.yaml b/Documentation/devicetree/bindings/regulator/rohm,bd71847-regulator.yaml index 65fc3d15f693..1d3dcfba58b0 100644 --- a/Documentation/devicetree/bindings/regulator/rohm,bd71847-regulator.yaml +++ b/Documentation/devicetree/bindings/regulator/rohm,bd71847-regulator.yaml @@ -54,7 +54,7 @@ patternProperties: should be "buck1", ..., "buck6" rohm,dvs-run-voltage: - $ref: "/schemas/types.yaml#/definitions/uint32" + $ref: /schemas/types.yaml#/definitions/uint32 minimum: 0 maximum: 1300000 description: @@ -62,7 +62,7 @@ patternProperties: bucks which support this. 0 means disabled. rohm,dvs-idle-voltage: - $ref: "/schemas/types.yaml#/definitions/uint32" + $ref: /schemas/types.yaml#/definitions/uint32 minimum: 0 maximum: 1300000 description: @@ -70,7 +70,7 @@ patternProperties: bucks which support this. 0 means disabled. rohm,dvs-suspend-voltage: - $ref: "/schemas/types.yaml#/definitions/uint32" + $ref: /schemas/types.yaml#/definitions/uint32 minimum: 0 maximum: 1300000 description: diff --git a/Documentation/devicetree/bindings/regulator/rohm,bd9576-regulator.yaml b/Documentation/devicetree/bindings/regulator/rohm,bd9576-regulator.yaml index 89b8592db81d..f573128da06f 100644 --- a/Documentation/devicetree/bindings/regulator/rohm,bd9576-regulator.yaml +++ b/Documentation/devicetree/bindings/regulator/rohm,bd9576-regulator.yaml @@ -25,7 +25,7 @@ patternProperties: type: object description: Properties for single regulator. - $ref: "regulator.yaml#" + $ref: regulator.yaml# properties: rohm,ocw-fet-ron-micro-ohms: diff --git a/Documentation/devicetree/bindings/regulator/socionext,uniphier-regulator.yaml b/Documentation/devicetree/bindings/regulator/socionext,uniphier-regulator.yaml index a6949a581cd1..ddaa112252e5 100644 --- a/Documentation/devicetree/bindings/regulator/socionext,uniphier-regulator.yaml +++ b/Documentation/devicetree/bindings/regulator/socionext,uniphier-regulator.yaml @@ -42,7 +42,7 @@ properties: reset-names: true allOf: - - $ref: "regulator.yaml#" + - $ref: regulator.yaml# - if: properties: compatible: diff --git a/Documentation/devicetree/bindings/regulator/st,stm32-booster.yaml b/Documentation/devicetree/bindings/regulator/st,stm32-booster.yaml index c82f6f885d97..c863100f6e7d 100644 --- a/Documentation/devicetree/bindings/regulator/st,stm32-booster.yaml +++ b/Documentation/devicetree/bindings/regulator/st,stm32-booster.yaml @@ -14,7 +14,7 @@ description: | to supply ADC analog input switches. allOf: - - $ref: "regulator.yaml#" + - $ref: regulator.yaml# properties: compatible: @@ -23,7 +23,7 @@ properties: - st,stm32mp1-booster st,syscfg: - $ref: "/schemas/types.yaml#/definitions/phandle" + $ref: /schemas/types.yaml#/definitions/phandle description: phandle to system configuration controller. vdda-supply: diff --git a/Documentation/devicetree/bindings/regulator/st,stm32-vrefbuf.yaml b/Documentation/devicetree/bindings/regulator/st,stm32-vrefbuf.yaml index c1bf1f90490a..05f4ad2c7d3a 100644 --- a/Documentation/devicetree/bindings/regulator/st,stm32-vrefbuf.yaml +++ b/Documentation/devicetree/bindings/regulator/st,stm32-vrefbuf.yaml @@ -15,7 +15,7 @@ maintainers: - Fabrice Gasnier <fabrice.gasnier@foss.st.com> allOf: - - $ref: "regulator.yaml#" + - $ref: regulator.yaml# properties: compatible: diff --git a/Documentation/devicetree/bindings/regulator/st,stm32mp1-pwr-reg.yaml b/Documentation/devicetree/bindings/regulator/st,stm32mp1-pwr-reg.yaml index bd07b9c81570..7d53cfa2c288 100644 --- a/Documentation/devicetree/bindings/regulator/st,stm32mp1-pwr-reg.yaml +++ b/Documentation/devicetree/bindings/regulator/st,stm32mp1-pwr-reg.yaml @@ -26,7 +26,7 @@ patternProperties: "^(reg11|reg18|usb33)$": type: object - $ref: "regulator.yaml#" + $ref: regulator.yaml# required: - compatible diff --git a/Documentation/devicetree/bindings/regulator/ti,tps62360.yaml b/Documentation/devicetree/bindings/regulator/ti,tps62360.yaml index 12aeddedde05..90c39275c150 100644 --- a/Documentation/devicetree/bindings/regulator/ti,tps62360.yaml +++ b/Documentation/devicetree/bindings/regulator/ti,tps62360.yaml @@ -19,7 +19,7 @@ description: | https://www.ti.com/lit/gpn/tps62360 allOf: - - $ref: "regulator.yaml#" + - $ref: regulator.yaml# properties: compatible: diff --git a/Documentation/devicetree/bindings/regulator/vqmmc-ipq4019-regulator.yaml b/Documentation/devicetree/bindings/regulator/vqmmc-ipq4019-regulator.yaml index dd7a2f92634c..3b16a25ba3b8 100644 --- a/Documentation/devicetree/bindings/regulator/vqmmc-ipq4019-regulator.yaml +++ b/Documentation/devicetree/bindings/regulator/vqmmc-ipq4019-regulator.yaml @@ -15,7 +15,7 @@ description: | controller is also embedded. allOf: - - $ref: "regulator.yaml#" + - $ref: regulator.yaml# properties: compatible: diff --git a/Documentation/devicetree/bindings/regulator/wlf,arizona.yaml b/Documentation/devicetree/bindings/regulator/wlf,arizona.yaml index 7b4ae5d23351..011819c10988 100644 --- a/Documentation/devicetree/bindings/regulator/wlf,arizona.yaml +++ b/Documentation/devicetree/bindings/regulator/wlf,arizona.yaml @@ -21,19 +21,19 @@ properties: wlf,ldoena: description: GPIO specifier for the GPIO controlling LDOENA. - $ref: "/schemas/types.yaml#/definitions/phandle-array" + $ref: /schemas/types.yaml#/definitions/phandle-array maxItems: 1 ldo1: description: Initial data for the LDO1 regulator. - $ref: "regulator.yaml#" + $ref: regulator.yaml# type: object micvdd: description: Initial data for the MICVDD regulator. - $ref: "regulator.yaml#" + $ref: regulator.yaml# type: object additionalProperties: true diff --git a/Documentation/devicetree/bindings/riscv/cpus.yaml b/Documentation/devicetree/bindings/riscv/cpus.yaml index 001931d526ec..14b5b7ea0ce0 100644 --- a/Documentation/devicetree/bindings/riscv/cpus.yaml +++ b/Documentation/devicetree/bindings/riscv/cpus.yaml @@ -35,6 +35,7 @@ properties: - sifive,e7 - sifive,e71 - sifive,rocket0 + - sifive,s7 - sifive,u5 - sifive,u54 - sifive,u7 diff --git a/Documentation/devicetree/bindings/riscv/sunxi.yaml b/Documentation/devicetree/bindings/riscv/sunxi.yaml index 9edb5e5992b1..b36e313e13a6 100644 --- a/Documentation/devicetree/bindings/riscv/sunxi.yaml +++ b/Documentation/devicetree/bindings/riscv/sunxi.yaml @@ -64,6 +64,11 @@ properties: - const: widora,mangopi-mq-pro - const: allwinner,sun20i-d1 + - description: MangoPi MQ-R board + items: + - const: widora,mangopi-mq-r-f133 + - const: allwinner,sun20i-d1s + additionalProperties: true ... diff --git a/Documentation/devicetree/bindings/serial/renesas,scif.yaml b/Documentation/devicetree/bindings/serial/renesas,scif.yaml index 1989bd67d04e..54e4f41be9b4 100644 --- a/Documentation/devicetree/bindings/serial/renesas,scif.yaml +++ b/Documentation/devicetree/bindings/serial/renesas,scif.yaml @@ -92,7 +92,7 @@ properties: - description: Error interrupt - description: Receive buffer full interrupt - description: Transmit buffer empty interrupt - - description: Transmit End interrupt + - description: Break interrupt - items: - description: Error interrupt - description: Receive buffer full interrupt @@ -107,7 +107,7 @@ properties: - const: eri - const: rxi - const: txi - - const: tei + - const: bri - items: - const: eri - const: rxi diff --git a/Documentation/devicetree/bindings/soc/amlogic/amlogic,canvas.yaml b/Documentation/devicetree/bindings/soc/amlogic/amlogic,canvas.yaml index c3c599096353..cd06865e1f2a 100644 --- a/Documentation/devicetree/bindings/soc/amlogic/amlogic,canvas.yaml +++ b/Documentation/devicetree/bindings/soc/amlogic/amlogic,canvas.yaml @@ -2,8 +2,8 @@ # Copyright 2019 BayLibre, SAS %YAML 1.2 --- -$id: "http://devicetree.org/schemas/soc/amlogic/amlogic,canvas.yaml#" -$schema: "http://devicetree.org/meta-schemas/core.yaml#" +$id: http://devicetree.org/schemas/soc/amlogic/amlogic,canvas.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# title: Amlogic Canvas Video Lookup Table diff --git a/Documentation/devicetree/bindings/soc/amlogic/amlogic,meson-gx-clk-measure.yaml b/Documentation/devicetree/bindings/soc/amlogic/amlogic,meson-gx-clk-measure.yaml new file mode 100644 index 000000000000..77c281153010 --- /dev/null +++ b/Documentation/devicetree/bindings/soc/amlogic/amlogic,meson-gx-clk-measure.yaml @@ -0,0 +1,40 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/soc/amlogic/amlogic,meson-gx-clk-measure.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Amlogic Internal Clock Measurer + +description: + The Amlogic SoCs contains an IP to measure the internal clocks. + The precision is multiple of MHz, useful to debug the clock states. + +maintainers: + - Neil Armstrong <neil.armstrong@linaro.org> + +properties: + compatible: + enum: + - amlogic,meson-gx-clk-measure + - amlogic,meson8-clk-measure + - amlogic,meson8b-clk-measure + - amlogic,meson-axg-clk-measure + - amlogic,meson-g12a-clk-measure + - amlogic,meson-sm1-clk-measure + + reg: + maxItems: 1 + +required: + - compatible + - reg + +unevaluatedProperties: false + +examples: + - | + clock-measure@8758 { + compatible = "amlogic,meson-gx-clk-measure"; + reg = <0x8758 0x10>; + }; diff --git a/Documentation/devicetree/bindings/soc/amlogic/clk-measure.txt b/Documentation/devicetree/bindings/soc/amlogic/clk-measure.txt deleted file mode 100644 index 3dd563cec794..000000000000 --- a/Documentation/devicetree/bindings/soc/amlogic/clk-measure.txt +++ /dev/null @@ -1,21 +0,0 @@ -Amlogic Internal Clock Measurer -=============================== - -The Amlogic SoCs contains an IP to measure the internal clocks. -The precision is multiple of MHz, useful to debug the clock states. - -Required properties: -- compatible: Shall contain one of the following : - "amlogic,meson-gx-clk-measure" for GX SoCs - "amlogic,meson8-clk-measure" for Meson8 SoCs - "amlogic,meson8b-clk-measure" for Meson8b SoCs - "amlogic,meson-axg-clk-measure" for AXG SoCs - "amlogic,meson-g12a-clk-measure" for G12a SoCs - "amlogic,meson-sm1-clk-measure" for SM1 SoCs -- reg: base address and size of the Clock Measurer register space. - -Example: - clock-measure@8758 { - compatible = "amlogic,meson-gx-clk-measure"; - reg = <0x0 0x8758 0x0 0x10>; - }; diff --git a/Documentation/devicetree/bindings/soc/imx/fsl,imx8mm-disp-blk-ctrl.yaml b/Documentation/devicetree/bindings/soc/imx/fsl,imx8mm-disp-blk-ctrl.yaml index ecd86cfb3da4..a02a09d574a2 100644 --- a/Documentation/devicetree/bindings/soc/imx/fsl,imx8mm-disp-blk-ctrl.yaml +++ b/Documentation/devicetree/bindings/soc/imx/fsl,imx8mm-disp-blk-ctrl.yaml @@ -70,7 +70,7 @@ examples: #include <dt-bindings/clock/imx8mm-clock.h> #include <dt-bindings/power/imx8mm-power.h> - disp_blk_ctl: blk_ctrl@32e28000 { + blk-ctrl@32e28000 { compatible = "fsl,imx8mm-disp-blk-ctrl", "syscon"; reg = <0x32e28000 0x100>; power-domains = <&pgc_dispmix>, <&pgc_dispmix>, <&pgc_dispmix>, diff --git a/Documentation/devicetree/bindings/soc/imx/fsl,imx8mm-vpu-blk-ctrl.yaml b/Documentation/devicetree/bindings/soc/imx/fsl,imx8mm-vpu-blk-ctrl.yaml index d71bb20d4907..25109376d7d4 100644 --- a/Documentation/devicetree/bindings/soc/imx/fsl,imx8mm-vpu-blk-ctrl.yaml +++ b/Documentation/devicetree/bindings/soc/imx/fsl,imx8mm-vpu-blk-ctrl.yaml @@ -150,7 +150,7 @@ examples: #include <dt-bindings/clock/imx8mm-clock.h> #include <dt-bindings/power/imx8mm-power.h> - vpu_blk_ctrl: blk-ctrl@38330000 { + blk-ctrl@38330000 { compatible = "fsl,imx8mm-vpu-blk-ctrl", "syscon"; reg = <0x38330000 0x100>; power-domains = <&pgc_vpumix>, <&pgc_vpu_g1>, 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 index fbeaac399c50..eeec9965b091 100644 --- a/Documentation/devicetree/bindings/soc/imx/fsl,imx8mn-disp-blk-ctrl.yaml +++ b/Documentation/devicetree/bindings/soc/imx/fsl,imx8mn-disp-blk-ctrl.yaml @@ -71,7 +71,7 @@ examples: #include <dt-bindings/clock/imx8mn-clock.h> #include <dt-bindings/power/imx8mn-power.h> - disp_blk_ctl: blk_ctrl@32e28000 { + blk-ctrl@32e28000 { compatible = "fsl,imx8mn-disp-blk-ctrl", "syscon"; reg = <0x32e28000 0x100>; power-domains = <&pgc_dispmix>, <&pgc_dispmix>, diff --git a/Documentation/devicetree/bindings/soc/imx/fsl,imx8mp-hsio-blk-ctrl.yaml b/Documentation/devicetree/bindings/soc/imx/fsl,imx8mp-hsio-blk-ctrl.yaml index 1fe68b53b1d8..4214c1ab4971 100644 --- a/Documentation/devicetree/bindings/soc/imx/fsl,imx8mp-hsio-blk-ctrl.yaml +++ b/Documentation/devicetree/bindings/soc/imx/fsl,imx8mp-hsio-blk-ctrl.yaml @@ -76,7 +76,7 @@ examples: #include <dt-bindings/clock/imx8mp-clock.h> #include <dt-bindings/power/imx8mp-power.h> - hsio_blk_ctrl: blk-ctrl@32f10000 { + blk-ctrl@32f10000 { compatible = "fsl,imx8mp-hsio-blk-ctrl", "syscon"; reg = <0x32f10000 0x24>; clocks = <&clk IMX8MP_CLK_USB_ROOT>, diff --git a/Documentation/devicetree/bindings/soc/imx/fsl,imx8mp-media-blk-ctrl.yaml b/Documentation/devicetree/bindings/soc/imx/fsl,imx8mp-media-blk-ctrl.yaml index dadb6108e321..ea9aa876ed13 100644 --- a/Documentation/devicetree/bindings/soc/imx/fsl,imx8mp-media-blk-ctrl.yaml +++ b/Documentation/devicetree/bindings/soc/imx/fsl,imx8mp-media-blk-ctrl.yaml @@ -23,6 +23,12 @@ properties: reg: maxItems: 1 + '#address-cells': + const: 1 + + '#size-cells': + const: 1 + '#power-domain-cells': const: 1 @@ -78,9 +84,16 @@ properties: - const: isp1 - const: dwe + bridge@5c: + type: object + $ref: /schemas/display/bridge/fsl,ldb.yaml# + unevaluatedProperties: false + required: - compatible - reg + - '#address-cells' + - '#size-cells' - '#power-domain-cells' - power-domains - power-domain-names @@ -94,7 +107,7 @@ examples: #include <dt-bindings/clock/imx8mp-clock.h> #include <dt-bindings/power/imx8mp-power.h> - media_blk_ctl: blk-ctl@32ec0000 { + blk-ctrl@32ec0000 { compatible = "fsl,imx8mp-media-blk-ctrl", "syscon"; reg = <0x32ec0000 0x138>; power-domains = <&mediamix_pd>, <&mipi_phy1_pd>, <&mipi_phy1_pd>, @@ -114,5 +127,43 @@ examples: clock-names = "apb", "axi", "cam1", "cam2", "disp1", "disp2", "isp", "phy"; #power-domain-cells = <1>; + #address-cells = <1>; + #size-cells = <1>; + + bridge@5c { + compatible = "fsl,imx8mp-ldb"; + reg = <0x5c 0x4>, <0x128 0x4>; + reg-names = "ldb", "lvds"; + clocks = <&clk IMX8MP_CLK_MEDIA_LDB>; + clock-names = "ldb"; + + ports { + #address-cells = <1>; + #size-cells = <0>; + + port@0 { + reg = <0>; + + ldb_from_lcdif2: endpoint { + remote-endpoint = <&lcdif2_to_ldb>; + }; + }; + + port@1 { + reg = <1>; + + ldb_lvds_ch0: endpoint { + remote-endpoint = <&ldb_to_lvdsx4panel>; + }; + }; + + port@2 { + reg = <2>; + + ldb_lvds_ch1: endpoint { + }; + }; + }; + }; }; ... diff --git a/Documentation/devicetree/bindings/soc/imx/fsl,imx8mq-vpu-blk-ctrl.yaml b/Documentation/devicetree/bindings/soc/imx/fsl,imx8mq-vpu-blk-ctrl.yaml index 7263ebedf09f..ea5c90c6a1b6 100644 --- a/Documentation/devicetree/bindings/soc/imx/fsl,imx8mq-vpu-blk-ctrl.yaml +++ b/Documentation/devicetree/bindings/soc/imx/fsl,imx8mq-vpu-blk-ctrl.yaml @@ -59,7 +59,7 @@ examples: #include <dt-bindings/clock/imx8mq-clock.h> #include <dt-bindings/power/imx8mq-power.h> - vpu_blk_ctrl: blk-ctrl@38320000 { + blk-ctrl@38320000 { compatible = "fsl,imx8mq-vpu-blk-ctrl"; reg = <0x38320000 0x100>; power-domains = <&pgc_vpu>, <&pgc_vpu>, <&pgc_vpu>; diff --git a/Documentation/devicetree/bindings/soc/imx/fsl,imx93-media-blk-ctrl.yaml b/Documentation/devicetree/bindings/soc/imx/fsl,imx93-media-blk-ctrl.yaml index 792ebecec22d..b3554e7f9e76 100644 --- a/Documentation/devicetree/bindings/soc/imx/fsl,imx93-media-blk-ctrl.yaml +++ b/Documentation/devicetree/bindings/soc/imx/fsl,imx93-media-blk-ctrl.yaml @@ -60,7 +60,7 @@ examples: #include <dt-bindings/clock/imx93-clock.h> #include <dt-bindings/power/fsl,imx93-power.h> - media_blk_ctrl: system-controller@4ac10000 { + system-controller@4ac10000 { compatible = "fsl,imx93-media-blk-ctrl", "syscon"; reg = <0x4ac10000 0x10000>; power-domains = <&mediamix>; diff --git a/Documentation/devicetree/bindings/soc/mediatek/mediatek,mutex.yaml b/Documentation/devicetree/bindings/soc/mediatek/mediatek,mutex.yaml index 15c133cac315..ba2014a8725c 100644 --- a/Documentation/devicetree/bindings/soc/mediatek/mediatek,mutex.yaml +++ b/Documentation/devicetree/bindings/soc/mediatek/mediatek,mutex.yaml @@ -35,6 +35,8 @@ properties: - mediatek,mt8188-disp-mutex - mediatek,mt8192-disp-mutex - mediatek,mt8195-disp-mutex + - mediatek,mt8195-vpp-mutex + - mediatek,mt8365-disp-mutex reg: maxItems: 1 @@ -70,12 +72,30 @@ properties: 4 arguments defined in this property. Each GCE subsys id is mapping to a client defined in the header include/dt-bindings/gce/<chip>-gce.h. +allOf: + - if: + properties: + compatible: + contains: + enum: + - mediatek,mt2701-disp-mutex + - mediatek,mt2712-disp-mutex + - mediatek,mt6795-disp-mutex + - mediatek,mt8173-disp-mutex + - mediatek,mt8186-disp-mutex + - mediatek,mt8186-mdp3-mutex + - mediatek,mt8192-disp-mutex + - mediatek,mt8195-disp-mutex + then: + required: + - clocks + + required: - compatible - reg - interrupts - power-domains - - clocks additionalProperties: false diff --git a/Documentation/devicetree/bindings/soc/qcom/qcom,aoss-qmp.yaml b/Documentation/devicetree/bindings/soc/qcom/qcom,aoss-qmp.yaml index ab607efbb64c..798f15588ee2 100644 --- a/Documentation/devicetree/bindings/soc/qcom/qcom,aoss-qmp.yaml +++ b/Documentation/devicetree/bindings/soc/qcom/qcom,aoss-qmp.yaml @@ -25,6 +25,7 @@ properties: compatible: items: - enum: + - qcom,qdu1000-aoss-qmp - qcom,sc7180-aoss-qmp - qcom,sc7280-aoss-qmp - qcom,sc8180x-aoss-qmp diff --git a/Documentation/devicetree/bindings/soc/qcom/qcom,apr.yaml b/Documentation/devicetree/bindings/soc/qcom/qcom,apr.yaml index 6026c21736d8..4502458b0669 100644 --- a/Documentation/devicetree/bindings/soc/qcom/qcom,apr.yaml +++ b/Documentation/devicetree/bindings/soc/qcom/qcom,apr.yaml @@ -62,7 +62,14 @@ properties: maxItems: 1 qcom,intents: - $ref: /schemas/types.yaml#/definitions/uint32-array + $ref: /schemas/types.yaml#/definitions/uint32-matrix + minItems: 1 + maxItems: 32 + items: + items: + - description: size of each intent to preallocate + - description: amount of intents to preallocate + minimum: 1 description: List of (size, amount) pairs describing what intents should be preallocated for this virtual channel. This can be used to tweak the diff --git a/Documentation/devicetree/bindings/soc/qcom/qcom,pmic-glink.yaml b/Documentation/devicetree/bindings/soc/qcom/qcom,pmic-glink.yaml index cf863683c21a..6440dc801387 100644 --- a/Documentation/devicetree/bindings/soc/qcom/qcom,pmic-glink.yaml +++ b/Documentation/devicetree/bindings/soc/qcom/qcom,pmic-glink.yaml @@ -25,6 +25,8 @@ properties: - qcom,sc8180x-pmic-glink - qcom,sc8280xp-pmic-glink - qcom,sm8350-pmic-glink + - qcom,sm8450-pmic-glink + - qcom,sm8550-pmic-glink - const: qcom,pmic-glink '#address-cells': diff --git a/Documentation/devicetree/bindings/soc/qcom/qcom,smd-rpm.yaml b/Documentation/devicetree/bindings/soc/qcom/qcom,smd-rpm.yaml index 16fd67c0bd1f..94765fbc868e 100644 --- a/Documentation/devicetree/bindings/soc/qcom/qcom,smd-rpm.yaml +++ b/Documentation/devicetree/bindings/soc/qcom/qcom,smd-rpm.yaml @@ -33,6 +33,7 @@ properties: enum: - qcom,rpm-apq8084 - qcom,rpm-ipq6018 + - qcom,rpm-ipq9574 - qcom,rpm-msm8226 - qcom,rpm-msm8909 - qcom,rpm-msm8916 @@ -40,6 +41,7 @@ properties: - qcom,rpm-msm8953 - qcom,rpm-msm8974 - qcom,rpm-msm8976 + - qcom,rpm-msm8994 - qcom,rpm-msm8996 - qcom,rpm-msm8998 - qcom,rpm-sdm660 @@ -84,6 +86,7 @@ if: - qcom,rpm-msm8974 - qcom,rpm-msm8976 - qcom,rpm-msm8953 + - qcom,rpm-msm8994 then: properties: qcom,glink-channels: false diff --git a/Documentation/devicetree/bindings/soc/renesas/renesas.yaml b/Documentation/devicetree/bindings/soc/renesas/renesas.yaml index 2789022b52eb..60190d84d9b3 100644 --- a/Documentation/devicetree/bindings/soc/renesas/renesas.yaml +++ b/Documentation/devicetree/bindings/soc/renesas/renesas.yaml @@ -212,12 +212,12 @@ properties: - renesas,silk # SILK (RTP0RC7794LCB00011S) - const: renesas,r8a7794 - - description: R-Car H3 (R8A77950) + # Note: R-Car H3 ES1.* (R8A77950) is not supported upstream anymore! + + - description: R-Car H3 ES2.0 and later (R8A77951) items: - enum: - # H3ULCB (R-Car Starter Kit Premier, RTP0RC7795SKBX0010SA00 (H3 ES1.1)) - # H3ULCB (R-Car Starter Kit Premier, RTP0RC77951SKBX010SA00 (H3 ES2.0)) - - renesas,h3ulcb + - renesas,h3ulcb # H3ULCB (R-Car Starter Kit Premier, RTP0RC77951SKBX010SA00 (H3 ES2.0)) - renesas,salvator-x # Salvator-X (RTP0RC7795SIPB0010S) - renesas,salvator-xs # Salvator-XS (Salvator-X 2nd version, RTP0RC7795SIPB0012S) - const: renesas,r8a7795 @@ -431,6 +431,13 @@ properties: - renesas,rzn1d400-db # RZN1D-DB (RZ/N1D Demo Board for the RZ/N1D 400 pins package) - const: renesas,r9a06g032 + - description: RZ/N1{D,S} EB + items: + - enum: + - renesas,rzn1d400-eb # RZN1D-EB (Expansion Board when using a RZN1D-DB) + - const: renesas,rzn1d400-db + - const: renesas,r9a06g032 + - description: RZ/Five and RZ/G2UL (R9A07G043) items: - enum: diff --git a/Documentation/devicetree/bindings/soc/rockchip/grf.yaml b/Documentation/devicetree/bindings/soc/rockchip/grf.yaml index e697c928900d..65a2d5a4f28d 100644 --- a/Documentation/devicetree/bindings/soc/rockchip/grf.yaml +++ b/Documentation/devicetree/bindings/soc/rockchip/grf.yaml @@ -80,13 +80,17 @@ allOf: properties: compatible: contains: - const: rockchip,px30-grf + enum: + - rockchip,px30-grf then: properties: lvds: - description: - Documentation/devicetree/bindings/display/rockchip/rockchip-lvds.txt + type: object + + $ref: /schemas/display/rockchip/rockchip,lvds.yaml# + + unevaluatedProperties: false - if: properties: diff --git a/Documentation/devicetree/bindings/soc/samsung/exynos-pmu.yaml b/Documentation/devicetree/bindings/soc/samsung/exynos-pmu.yaml index f7c141dd11ec..5d8d9497f18e 100644 --- a/Documentation/devicetree/bindings/soc/samsung/exynos-pmu.yaml +++ b/Documentation/devicetree/bindings/soc/samsung/exynos-pmu.yaml @@ -48,6 +48,9 @@ properties: - const: syscon - items: - enum: + - samsung,exynos3250-pmu + - samsung,exynos4210-pmu + - samsung,exynos4412-pmu - samsung,exynos5250-pmu - samsung,exynos5420-pmu - samsung,exynos5433-pmu @@ -138,18 +141,34 @@ allOf: compatible: contains: enum: + - samsung,exynos3250-pmu + - samsung,exynos4210-pmu + - samsung,exynos4412-pmu - samsung,exynos5250-pmu - samsung,exynos5420-pmu - samsung,exynos5433-pmu then: properties: - dp-phy: true mipi-phy: true else: properties: - dp-phy: false mipi-phy: false + - if: + properties: + compatible: + contains: + enum: + - samsung,exynos5250-pmu + - samsung,exynos5420-pmu + - samsung,exynos5433-pmu + then: + properties: + dp-phy: true + else: + properties: + dp-phy: false + examples: - | #include <dt-bindings/clock/exynos5250.h> diff --git a/Documentation/devicetree/bindings/sram/qcom,imem.yaml b/Documentation/devicetree/bindings/sram/qcom,imem.yaml index ba694ce4a037..0548e8e0d30b 100644 --- a/Documentation/devicetree/bindings/sram/qcom,imem.yaml +++ b/Documentation/devicetree/bindings/sram/qcom,imem.yaml @@ -26,6 +26,7 @@ properties: - qcom,sdm845-imem - qcom,sdx55-imem - qcom,sdx65-imem + - qcom,sm6375-imem - qcom,sm8450-imem - const: syscon - const: simple-mfd diff --git a/Documentation/devicetree/bindings/timer/sifive,clint.yaml b/Documentation/devicetree/bindings/timer/sifive,clint.yaml index aada6957216c..94bef9424df1 100644 --- a/Documentation/devicetree/bindings/timer/sifive,clint.yaml +++ b/Documentation/devicetree/bindings/timer/sifive,clint.yaml @@ -31,6 +31,7 @@ properties: - enum: - sifive,fu540-c000-clint - starfive,jh7100-clint + - starfive,jh7110-clint - canaan,k210-clint - const: sifive,clint0 - items: diff --git a/Documentation/devicetree/bindings/vendor-prefixes.yaml b/Documentation/devicetree/bindings/vendor-prefixes.yaml index ed64e06ecca4..c3fe8c136721 100644 --- a/Documentation/devicetree/bindings/vendor-prefixes.yaml +++ b/Documentation/devicetree/bindings/vendor-prefixes.yaml @@ -240,6 +240,8 @@ patternProperties: description: CellWise Microelectronics Co., Ltd "^ceva,.*": description: Ceva, Inc. + "^chargebyte,.*": + description: chargebyte GmbH "^checkpoint,.*": description: Check Point Software Technologies Ltd. "^chefree,.*": @@ -516,6 +518,8 @@ patternProperties: description: GlobalTop Technology, Inc. "^gmt,.*": description: Global Mixed-mode Technology, Inc. + "^goldelico,.*": + description: Golden Delicious Computers GmbH & Co. KG "^goodix,.*": description: Shenzhen Huiding Technology Co., Ltd. "^google,.*": @@ -721,6 +725,8 @@ patternProperties: description: Lantiq Semiconductor "^lattice,.*": description: Lattice Semiconductor + "^lctech,.*": + description: Shenzen LC Technology Co., Ltd. "^leadtek,.*": description: Shenzhen Leadtek Technology Co., Ltd. "^leez,.*": @@ -977,6 +983,8 @@ patternProperties: description: OpenCores.org "^openembed,.*": description: OpenEmbed + "^openpandora,.*": + description: OpenPandora GmbH "^openrisc,.*": description: OpenRISC.io "^option,.*": @@ -1243,6 +1251,8 @@ patternProperties: description: Solomon Systech Limited "^sony,.*": description: Sony Corporation + "^sourceparts,.*": + description: Source Parts Inc. "^spansion,.*": description: Spansion Inc. "^sparkfun,.*": @@ -1528,6 +1538,8 @@ patternProperties: description: Yes Optoelectronics Co.,Ltd. "^yic,.*": description: YIC System Co., Ltd. + "^yiming,.*": + description: Henan Yiming Technology Co., Ltd. "^ylm,.*": description: Shenzhen Yangliming Electronic Technology Co., Ltd. "^yna,.*": diff --git a/Documentation/devicetree/bindings/watchdog/apple,wdt.yaml b/Documentation/devicetree/bindings/watchdog/apple,wdt.yaml index e58c56a6fdf6..3d7e2a2bf1f1 100644 --- a/Documentation/devicetree/bindings/watchdog/apple,wdt.yaml +++ b/Documentation/devicetree/bindings/watchdog/apple,wdt.yaml @@ -17,6 +17,7 @@ properties: items: - enum: - apple,t8103-wdt + - apple,t8112-wdt - apple,t6000-wdt - const: apple,wdt diff --git a/Documentation/devicetree/bindings/watchdog/snps,dw-wdt.yaml b/Documentation/devicetree/bindings/watchdog/snps,dw-wdt.yaml index 92df6e453f64..e7a87ce94772 100644 --- a/Documentation/devicetree/bindings/watchdog/snps,dw-wdt.yaml +++ b/Documentation/devicetree/bindings/watchdog/snps,dw-wdt.yaml @@ -29,6 +29,7 @@ properties: - rockchip,rk3368-wdt - rockchip,rk3399-wdt - rockchip,rk3568-wdt + - rockchip,rk3588-wdt - rockchip,rv1108-wdt - const: snps,dw-wdt diff --git a/Documentation/driver-api/clk.rst b/Documentation/driver-api/clk.rst index 3cad45d14187..93bab5336dfd 100644 --- a/Documentation/driver-api/clk.rst +++ b/Documentation/driver-api/clk.rst @@ -258,6 +258,11 @@ clocks properly but rely on them being on from the bootloader, bypassing the disabling means that the driver will remain functional while the issues are sorted out. +You can see which clocks have been disabled by booting your kernel with these +parameters:: + + tp_printk trace_event=clk:clk_disable + To bypass this disabling, include "clk_ignore_unused" in the bootargs to the kernel. diff --git a/Documentation/driver-api/device-io.rst b/Documentation/driver-api/device-io.rst index 4d2baac0311c..2c7abd234f4e 100644 --- a/Documentation/driver-api/device-io.rst +++ b/Documentation/driver-api/device-io.rst @@ -410,7 +410,7 @@ ioremap_uc() ioremap_uc() behaves like ioremap() except that on the x86 architecture without 'PAT' mode, it marks memory as uncached even when the MTRR has designated -it as cacheable, see Documentation/x86/pat.rst. +it as cacheable, see Documentation/arch/x86/pat.rst. Portable drivers should avoid the use of ioremap_uc(). diff --git a/Documentation/driver-api/dma-buf.rst b/Documentation/driver-api/dma-buf.rst index 2e8dfd1a66b6..f92a32d095d9 100644 --- a/Documentation/driver-api/dma-buf.rst +++ b/Documentation/driver-api/dma-buf.rst @@ -164,6 +164,12 @@ DMA Fence Signalling Annotations .. kernel-doc:: drivers/dma-buf/dma-fence.c :doc: fence signalling annotation +DMA Fence Deadline Hints +~~~~~~~~~~~~~~~~~~~~~~~~ + +.. kernel-doc:: drivers/dma-buf/dma-fence.c + :doc: deadline hints + DMA Fences Functions Reference ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ @@ -197,8 +203,8 @@ DMA Fence unwrap .. kernel-doc:: include/linux/dma-fence-unwrap.h :internal: -DMA Fence uABI/Sync File -~~~~~~~~~~~~~~~~~~~~~~~~ +DMA Fence Sync File +~~~~~~~~~~~~~~~~~~~ .. kernel-doc:: drivers/dma-buf/sync_file.c :export: @@ -206,6 +212,12 @@ DMA Fence uABI/Sync File .. kernel-doc:: include/linux/sync_file.h :internal: +DMA Fence Sync File uABI +~~~~~~~~~~~~~~~~~~~~~~~~ + +.. kernel-doc:: include/uapi/linux/sync_file.h + :internal: + Indefinite DMA Fences ~~~~~~~~~~~~~~~~~~~~~ diff --git a/Documentation/driver-api/firmware/fw_search_path.rst b/Documentation/driver-api/firmware/fw_search_path.rst index a360f1009fa3..d7cb1e8f0076 100644 --- a/Documentation/driver-api/firmware/fw_search_path.rst +++ b/Documentation/driver-api/firmware/fw_search_path.rst @@ -22,5 +22,10 @@ can use the file: * /sys/module/firmware_class/parameters/path -You would echo into it your custom path and firmware requested will be -searched for there first. +You would echo into it your custom path and firmware requested will be searched +for there first. Be aware that newline characters will be taken into account +and may not produce the intended effects. For instance you might want to use: + +echo -n /path/to/script > /sys/module/firmware_class/parameters/path + +to ensure that your script is being used. diff --git a/Documentation/driver-api/gpio/driver.rst b/Documentation/driver-api/gpio/driver.rst index 6baaeab79534..bf6319cc531b 100644 --- a/Documentation/driver-api/gpio/driver.rst +++ b/Documentation/driver-api/gpio/driver.rst @@ -218,10 +218,10 @@ not support open drain/open source in hardware, the GPIO library will instead use a trick: when a line is set as output, if the line is flagged as open drain, and the IN output value is low, it will be driven low as usual. But if the IN output value is set to high, it will instead *NOT* be driven high, -instead it will be switched to input, as input mode is high impedance, thus -achieving an "open drain emulation" of sorts: electrically the behaviour will -be identical, with the exception of possible hardware glitches when switching -the mode of the line. +instead it will be switched to input, as input mode is an equivalent to +high impedance, thus achieving an "open drain emulation" of sorts: electrically +the behaviour will be identical, with the exception of possible hardware glitches +when switching the mode of the line. For open source configuration the same principle is used, just that instead of actively driving the line low, it is set to input. diff --git a/Documentation/driver-api/gpio/legacy.rst b/Documentation/driver-api/gpio/legacy.rst index a0559d93efd1..78372853c6d4 100644 --- a/Documentation/driver-api/gpio/legacy.rst +++ b/Documentation/driver-api/gpio/legacy.rst @@ -238,8 +238,6 @@ setup or driver probe/teardown code, so this is an easy constraint.):: ## gpio_free_array() gpio_free() - gpio_set_debounce() - Claiming and Releasing GPIOs @@ -716,27 +714,6 @@ gpiochip nodes (possibly in conjunction with schematics) to determine the correct GPIO number to use for a given signal. -Exporting from Kernel code --------------------------- -Kernel code can explicitly manage exports of GPIOs which have already been -requested using gpio_request():: - - /* export the GPIO to userspace */ - int gpio_export(unsigned gpio, bool direction_may_change); - - /* reverse gpio_export() */ - void gpio_unexport(); - -After a kernel driver requests a GPIO, it may only be made available in -the sysfs interface by gpio_export(). The driver can control whether the -signal direction may change. This helps drivers prevent userspace code -from accidentally clobbering important system state. - -This explicit exporting can help with debugging (by making some kinds -of experiments easier), or can provide an always-there interface that's -suitable for documenting as part of a board support package. - - API Reference ============= diff --git a/Documentation/driver-api/media/drivers/ccs/ccs.rst b/Documentation/driver-api/media/drivers/ccs/ccs.rst index b461c8aa2a16..7389204afcb8 100644 --- a/Documentation/driver-api/media/drivers/ccs/ccs.rst +++ b/Documentation/driver-api/media/drivers/ccs/ccs.rst @@ -56,6 +56,28 @@ analogue data is never read from the pixel matrix that are outside the configured selection rectangle that designates crop. The difference has an effect in device timing and likely also in power consumption. +CCS static data +--------------- + +The MIPI CCS driver supports CCS static data for all compliant devices, +including not just those compliant with CCS 1.1 but also CCS 1.0 and SMIA(++). +For CCS the file names are formed as + + ccs/ccs-sensor-vvvv-mmmm-rrrr.fw (sensor) and + ccs/ccs-module-vvvv-mmmm-rrrr.fw (module). + +For SMIA++ compliant devices the corresponding file names are + + ccs/smiapp-sensor-vv-mmmm-rr.fw (sensor) and + ccs/smiapp-module-vv-mmmm-rrrr.fw (module). + +For SMIA (non-++) compliant devices the static data file name is + + ccs/smia-sensor-vv-mmmm-rr.fw (sensor). + +vvvv or vv denotes MIPI and SMIA manufacturer IDs respectively, mmmm model ID +and rrrr or rr revision number. + Register definition generator ----------------------------- diff --git a/Documentation/driver-api/mtd/spi-nor.rst b/Documentation/driver-api/mtd/spi-nor.rst index 4a3adca417fd..c22f8c0f7950 100644 --- a/Documentation/driver-api/mtd/spi-nor.rst +++ b/Documentation/driver-api/mtd/spi-nor.rst @@ -63,6 +63,3 @@ The main API is spi_nor_scan(). Before you call the hook, a driver should initialize the necessary fields for spi_nor{}. Please see drivers/mtd/spi-nor/spi-nor.c for detail. Please also refer to spi-fsl-qspi.c when you want to write a new driver for a SPI NOR controller. -Another API is spi_nor_restore(), this is used to restore the status of SPI -flash chip such as addressing mode. Call it whenever detach the driver from -device or reboot the system. diff --git a/Documentation/filesystems/erofs.rst b/Documentation/filesystems/erofs.rst index a43aacf1494e..4654ee57c1d5 100644 --- a/Documentation/filesystems/erofs.rst +++ b/Documentation/filesystems/erofs.rst @@ -40,8 +40,8 @@ Here are the main features of EROFS: - Support multiple devices to refer to external blobs, which can be used for container images; - - 4KiB block size and 32-bit block addresses for each device, therefore - 16TiB address space at most for now; + - 32-bit block addresses for each device, therefore 16TiB address space at + most with 4KiB block size for now; - Two inode layouts for different requirements: diff --git a/Documentation/filesystems/idmappings.rst b/Documentation/filesystems/idmappings.rst index b9b31066aef2..ad6d21640576 100644 --- a/Documentation/filesystems/idmappings.rst +++ b/Documentation/filesystems/idmappings.rst @@ -241,7 +241,7 @@ according to the filesystem's idmapping as this would give the wrong owner if the caller is using an idmapping. So the kernel will map the id back up in the idmapping of the caller. Let's -assume the caller has the slighly unconventional idmapping +assume the caller has the somewhat unconventional idmapping ``u3000:k20000:r10000`` then ``k21000`` would map back up to ``u4000``. Consequently the user would see that this file is owned by ``u4000``. @@ -320,6 +320,10 @@ and equally wrong:: from_kuid(u20000:k0:r10000, u1000) = k21000 ~~~~~ +Since userspace ids have type ``uid_t`` and ``gid_t`` and kernel ids have type +``kuid_t`` and ``kgid_t`` the compiler will throw an error when they are +conflated. So the two examples above would cause a compilation failure. + Idmappings when creating filesystem objects ------------------------------------------- @@ -623,42 +627,105 @@ privileged users in the initial user namespace. However, it is perfectly possible to combine idmapped mounts with filesystems mountable inside user namespaces. We will touch on this further below. +Filesystem types vs idmapped mount types +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +With the introduction of idmapped mounts we need to distinguish between +filesystem ownership and mount ownership of a VFS object such as an inode. The +owner of a inode might be different when looked at from a filesystem +perspective than when looked at from an idmapped mount. Such fundamental +conceptual distinctions should almost always be clearly expressed in the code. +So, to distinguish idmapped mount ownership from filesystem ownership separate +types have been introduced. + +If a uid or gid has been generated using the filesystem or caller's idmapping +then we will use the ``kuid_t`` and ``kgid_t`` types. However, if a uid or gid +has been generated using a mount idmapping then we will be using the dedicated +``vfsuid_t`` and ``vfsgid_t`` types. + +All VFS helpers that generate or take uids and gids as arguments use the +``vfsuid_t`` and ``vfsgid_t`` types and we will be able to rely on the compiler +to catch errors that originate from conflating filesystem and VFS uids and gids. + +The ``vfsuid_t`` and ``vfsgid_t`` types are often mapped from and to ``kuid_t`` +and ``kgid_t`` types similar how ``kuid_t`` and ``kgid_t`` types are mapped +from and to ``uid_t`` and ``gid_t`` types:: + + uid_t <--> kuid_t <--> vfsuid_t + gid_t <--> kgid_t <--> vfsgid_t + +Whenever we report ownership based on a ``vfsuid_t`` or ``vfsgid_t`` type, +e.g., during ``stat()``, or store ownership information in a shared VFS object +based on a ``vfsuid_t`` or ``vfsgid_t`` type, e.g., during ``chown()`` we can +use the ``vfsuid_into_kuid()`` and ``vfsgid_into_kgid()`` helpers. + +To illustrate why this helper currently exists, consider what happens when we +change ownership of an inode from an idmapped mount. After we generated +a ``vfsuid_t`` or ``vfsgid_t`` based on the mount idmapping we later commit to +this ``vfsuid_t`` or ``vfsgid_t`` to become the new filesytem wide ownership. +Thus, we are turning the ``vfsuid_t`` or ``vfsgid_t`` into a global ``kuid_t`` +or ``kgid_t``. And this can be done by using ``vfsuid_into_kuid()`` and +``vfsgid_into_kgid()``. + +Note, whenever a shared VFS object, e.g., a cached ``struct inode`` or a cached +``struct posix_acl``, stores ownership information a filesystem or "global" +``kuid_t`` and ``kgid_t`` must be used. Ownership expressed via ``vfsuid_t`` +and ``vfsgid_t`` is specific to an idmapped mount. + +We already noted that ``vfsuid_t`` and ``vfsgid_t`` types are generated based +on mount idmappings whereas ``kuid_t`` and ``kgid_t`` types are generated based +on filesystem idmappings. To prevent abusing filesystem idmappings to generate +``vfsuid_t`` or ``vfsgid_t`` types or mount idmappings to generate ``kuid_t`` +or ``kgid_t`` types filesystem idmappings and mount idmappings are different +types as well. + +All helpers that map to or from ``vfsuid_t`` and ``vfsgid_t`` types require +a mount idmapping to be passed which is of type ``struct mnt_idmap``. Passing +a filesystem or caller idmapping will cause a compilation error. + +Similar to how we prefix all userspace ids in this document with ``u`` and all +kernel ids with ``k`` we will prefix all VFS ids with ``v``. So a mount +idmapping will be written as: ``u0:v10000:r10000``. + Remapping helpers ~~~~~~~~~~~~~~~~~ Idmapping functions were added that translate between idmappings. They make use -of the remapping algorithm we've introduced earlier. We're going to look at -two: +of the remapping algorithm we've introduced earlier. We're going to look at: -- ``i_uid_into_mnt()`` and ``i_gid_into_mnt()`` +- ``i_uid_into_vfsuid()`` and ``i_gid_into_vfsgid()`` - The ``i_*id_into_mnt()`` functions translate filesystem's kernel ids into - kernel ids in the mount's idmapping:: + The ``i_*id_into_vfs*id()`` functions translate filesystem's kernel ids into + VFS ids in the mount's idmapping:: /* Map the filesystem's kernel id up into a userspace id in the filesystem's idmapping. */ from_kuid(filesystem, kid) = uid - /* Map the filesystem's userspace id down ito a kernel id in the mount's idmapping. */ + /* Map the filesystem's userspace id down ito a VFS id in the mount's idmapping. */ make_kuid(mount, uid) = kuid - ``mapped_fsuid()`` and ``mapped_fsgid()`` The ``mapped_fs*id()`` functions translate the caller's kernel ids into kernel ids in the filesystem's idmapping. This translation is achieved by - remapping the caller's kernel ids using the mount's idmapping:: + remapping the caller's VFS ids using the mount's idmapping:: - /* Map the caller's kernel id up into a userspace id in the mount's idmapping. */ + /* Map the caller's VFS id up into a userspace id in the mount's idmapping. */ from_kuid(mount, kid) = uid /* Map the mount's userspace id down into a kernel id in the filesystem's idmapping. */ make_kuid(filesystem, uid) = kuid +- ``vfsuid_into_kuid()`` and ``vfsgid_into_kgid()`` + + Whenever + Note that these two functions invert each other. Consider the following idmappings:: caller idmapping: u0:k10000:r10000 filesystem idmapping: u0:k20000:r10000 - mount idmapping: u0:k10000:r10000 + mount idmapping: u0:v10000:r10000 Assume a file owned by ``u1000`` is read from disk. The filesystem maps this id to ``k21000`` according to its idmapping. This is what is stored in the @@ -669,20 +736,21 @@ would usually simply use the crossmapping algorithm and map the filesystem's kernel id up to a userspace id in the caller's idmapping. But when the caller is accessing the file on an idmapped mount the kernel will -first call ``i_uid_into_mnt()`` thereby translating the filesystem's kernel id -into a kernel id in the mount's idmapping:: +first call ``i_uid_into_vfsuid()`` thereby translating the filesystem's kernel +id into a VFS id in the mount's idmapping:: - i_uid_into_mnt(k21000): + i_uid_into_vfsuid(k21000): /* Map the filesystem's kernel id up into a userspace id. */ from_kuid(u0:k20000:r10000, k21000) = u1000 - /* Map the filesystem's userspace id down ito a kernel id in the mount's idmapping. */ - make_kuid(u0:k10000:r10000, u1000) = k11000 + /* Map the filesystem's userspace id down into a VFS id in the mount's idmapping. */ + make_kuid(u0:v10000:r10000, u1000) = v11000 Finally, when the kernel reports the owner to the caller it will turn the -kernel id in the mount's idmapping into a userspace id in the caller's +VFS id in the mount's idmapping into a userspace id in the caller's idmapping:: + k11000 = vfsuid_into_kuid(v11000) from_kuid(u0:k10000:r10000, k11000) = u1000 We can test whether this algorithm really works by verifying what happens when @@ -696,18 +764,19 @@ fails. But when the caller is accessing the file on an idmapped mount the kernel will first call ``mapped_fs*id()`` thereby translating the caller's kernel id into -a kernel id according to the mount's idmapping:: +a VFS id according to the mount's idmapping:: mapped_fsuid(k11000): /* Map the caller's kernel id up into a userspace id in the mount's idmapping. */ from_kuid(u0:k10000:r10000, k11000) = u1000 /* Map the mount's userspace id down into a kernel id in the filesystem's idmapping. */ - make_kuid(u0:k20000:r10000, u1000) = k21000 + make_kuid(u0:v20000:r10000, u1000) = v21000 -When finally writing to disk the kernel will then map ``k21000`` up into a +When finally writing to disk the kernel will then map ``v21000`` up into a userspace id in the filesystem's idmapping:: + k21000 = vfsuid_into_kuid(v21000) from_kuid(u0:k20000:r10000, k21000) = u1000 As we can see, we end up with an invertible and therefore information @@ -725,7 +794,7 @@ Example 2 reconsidered caller id: u1000 caller idmapping: u0:k10000:r10000 filesystem idmapping: u0:k20000:r10000 - mount idmapping: u0:k10000:r10000 + mount idmapping: u0:v10000:r10000 When the caller is using a non-initial idmapping the common case is to attach the same idmapping to the mount. We now perform three steps: @@ -734,12 +803,12 @@ the same idmapping to the mount. We now perform three steps: make_kuid(u0:k10000:r10000, u1000) = k11000 -2. Translate the caller's kernel id into a kernel id in the filesystem's +2. Translate the caller's VFS id into a kernel id in the filesystem's idmapping:: - mapped_fsuid(k11000): - /* Map the kernel id up into a userspace id in the mount's idmapping. */ - from_kuid(u0:k10000:r10000, k11000) = u1000 + mapped_fsuid(v11000): + /* Map the VFS id up into a userspace id in the mount's idmapping. */ + from_kuid(u0:v10000:r10000, v11000) = u1000 /* Map the userspace id down into a kernel id in the filesystem's idmapping. */ make_kuid(u0:k20000:r10000, u1000) = k21000 @@ -759,7 +828,7 @@ Example 3 reconsidered caller id: u1000 caller idmapping: u0:k10000:r10000 filesystem idmapping: u0:k0:r4294967295 - mount idmapping: u0:k10000:r10000 + mount idmapping: u0:v10000:r10000 The same translation algorithm works with the third example. @@ -767,12 +836,12 @@ The same translation algorithm works with the third example. make_kuid(u0:k10000:r10000, u1000) = k11000 -2. Translate the caller's kernel id into a kernel id in the filesystem's +2. Translate the caller's VFS id into a kernel id in the filesystem's idmapping:: - mapped_fsuid(k11000): - /* Map the kernel id up into a userspace id in the mount's idmapping. */ - from_kuid(u0:k10000:r10000, k11000) = u1000 + mapped_fsuid(v11000): + /* Map the VFS id up into a userspace id in the mount's idmapping. */ + from_kuid(u0:v10000:r10000, v11000) = u1000 /* Map the userspace id down into a kernel id in the filesystem's idmapping. */ make_kuid(u0:k0:r4294967295, u1000) = k1000 @@ -792,7 +861,7 @@ Example 4 reconsidered file id: u1000 caller idmapping: u0:k10000:r10000 filesystem idmapping: u0:k0:r4294967295 - mount idmapping: u0:k10000:r10000 + mount idmapping: u0:v10000:r10000 In order to report ownership to userspace the kernel now does three steps using the translation algorithm we introduced earlier: @@ -802,17 +871,18 @@ the translation algorithm we introduced earlier: make_kuid(u0:k0:r4294967295, u1000) = k1000 -2. Translate the kernel id into a kernel id in the mount's idmapping:: +2. Translate the kernel id into a VFS id in the mount's idmapping:: - i_uid_into_mnt(k1000): + i_uid_into_vfsuid(k1000): /* Map the kernel id up into a userspace id in the filesystem's idmapping. */ from_kuid(u0:k0:r4294967295, k1000) = u1000 - /* Map the userspace id down into a kernel id in the mounts's idmapping. */ - make_kuid(u0:k10000:r10000, u1000) = k11000 + /* Map the userspace id down into a VFS id in the mounts's idmapping. */ + make_kuid(u0:v10000:r10000, u1000) = v11000 -3. Map the kernel id up into a userspace id in the caller's idmapping:: +3. Map the VFS id up into a userspace id in the caller's idmapping:: + k11000 = vfsuid_into_kuid(v11000) from_kuid(u0:k10000:r10000, k11000) = u1000 Earlier, the caller's kernel id couldn't be crossmapped in the filesystems's @@ -828,7 +898,7 @@ Example 5 reconsidered file id: u1000 caller idmapping: u0:k10000:r10000 filesystem idmapping: u0:k20000:r10000 - mount idmapping: u0:k10000:r10000 + mount idmapping: u0:v10000:r10000 Again, in order to report ownership to userspace the kernel now does three steps using the translation algorithm we introduced earlier: @@ -838,17 +908,18 @@ steps using the translation algorithm we introduced earlier: make_kuid(u0:k20000:r10000, u1000) = k21000 -2. Translate the kernel id into a kernel id in the mount's idmapping:: +2. Translate the kernel id into a VFS id in the mount's idmapping:: - i_uid_into_mnt(k21000): + i_uid_into_vfsuid(k21000): /* Map the kernel id up into a userspace id in the filesystem's idmapping. */ from_kuid(u0:k20000:r10000, k21000) = u1000 - /* Map the userspace id down into a kernel id in the mounts's idmapping. */ - make_kuid(u0:k10000:r10000, u1000) = k11000 + /* Map the userspace id down into a VFS id in the mounts's idmapping. */ + make_kuid(u0:v10000:r10000, u1000) = v11000 -3. Map the kernel id up into a userspace id in the caller's idmapping:: +3. Map the VFS id up into a userspace id in the caller's idmapping:: + k11000 = vfsuid_into_kuid(v11000) from_kuid(u0:k10000:r10000, k11000) = u1000 Earlier, the file's kernel id couldn't be crossmapped in the filesystems's @@ -899,23 +970,23 @@ from above::: caller id: u1125 caller idmapping: u0:k0:r4294967295 filesystem idmapping: u0:k0:r4294967295 - mount idmapping: u1000:k1125:r1 + mount idmapping: u1000:v1125:r1 1. Map the caller's userspace ids into kernel ids in the caller's idmapping:: make_kuid(u0:k0:r4294967295, u1125) = k1125 -2. Translate the caller's kernel id into a kernel id in the filesystem's +2. Translate the caller's VFS id into a kernel id in the filesystem's idmapping:: - mapped_fsuid(k1125): - /* Map the kernel id up into a userspace id in the mount's idmapping. */ - from_kuid(u1000:k1125:r1, k1125) = u1000 + mapped_fsuid(v1125): + /* Map the VFS id up into a userspace id in the mount's idmapping. */ + from_kuid(u1000:v1125:r1, v1125) = u1000 /* Map the userspace id down into a kernel id in the filesystem's idmapping. */ make_kuid(u0:k0:r4294967295, u1000) = k1000 -2. Verify that the caller's kernel ids can be mapped to userspace ids in the +2. Verify that the caller's filesystem ids can be mapped to userspace ids in the filesystem's idmapping:: from_kuid(u0:k0:r4294967295, k1000) = u1000 @@ -930,24 +1001,25 @@ on their work computer: file id: u1000 caller idmapping: u0:k0:r4294967295 filesystem idmapping: u0:k0:r4294967295 - mount idmapping: u1000:k1125:r1 + mount idmapping: u1000:v1125:r1 1. Map the userspace id on disk down into a kernel id in the filesystem's idmapping:: make_kuid(u0:k0:r4294967295, u1000) = k1000 -2. Translate the kernel id into a kernel id in the mount's idmapping:: +2. Translate the kernel id into a VFS id in the mount's idmapping:: - i_uid_into_mnt(k1000): + i_uid_into_vfsuid(k1000): /* Map the kernel id up into a userspace id in the filesystem's idmapping. */ from_kuid(u0:k0:r4294967295, k1000) = u1000 - /* Map the userspace id down into a kernel id in the mounts's idmapping. */ - make_kuid(u1000:k1125:r1, u1000) = k1125 + /* Map the userspace id down into a VFS id in the mounts's idmapping. */ + make_kuid(u1000:v1125:r1, u1000) = v1125 -3. Map the kernel id up into a userspace id in the caller's idmapping:: +3. Map the VFS id up into a userspace id in the caller's idmapping:: + k1125 = vfsuid_into_kuid(v1125) from_kuid(u0:k0:r4294967295, k1125) = u1125 So ultimately the caller will be reported that the file belongs to ``u1125`` diff --git a/Documentation/filesystems/mount_api.rst b/Documentation/filesystems/mount_api.rst index 63204d2094fd..9aaf6ef75eb5 100644 --- a/Documentation/filesystems/mount_api.rst +++ b/Documentation/filesystems/mount_api.rst @@ -79,7 +79,6 @@ context. This is represented by the fs_context structure:: unsigned int sb_flags; unsigned int sb_flags_mask; unsigned int s_iflags; - unsigned int lsm_flags; enum fs_context_purpose purpose:8; ... }; diff --git a/Documentation/filesystems/proc.rst b/Documentation/filesystems/proc.rst index 9d5fd9424e8b..59db0bed35e1 100644 --- a/Documentation/filesystems/proc.rst +++ b/Documentation/filesystems/proc.rst @@ -85,7 +85,7 @@ contact Bodo Bauer at bb@ricochet.net. We'll be happy to add them to this document. The latest version of this document is available online at -http://tldp.org/LDP/Linux-Filesystem-Hierarchy/html/proc.html +https://www.kernel.org/doc/html/latest/filesystems/proc.html If the above direction does not works for you, you could try the kernel mailing list at linux-kernel@vger.kernel.org and/or try to reach me at @@ -232,7 +232,7 @@ asynchronous manner and the value may not be very precise. To see a precise snapshot of a moment, you can see /proc/<pid>/smaps file and scan page table. It's slow but very precise. -.. table:: Table 1-2: Contents of the status files (as of 4.19) +.. table:: Table 1-2: Contents of the status fields (as of 4.19) ========================== =================================================== Field Content @@ -305,7 +305,7 @@ It's slow but very precise. ========================== =================================================== -.. table:: Table 1-3: Contents of the statm files (as of 2.6.8-rc3) +.. table:: Table 1-3: Contents of the statm fields (as of 2.6.8-rc3) ======== =============================== ============================== Field Content @@ -323,7 +323,7 @@ It's slow but very precise. ======== =============================== ============================== -.. table:: Table 1-4: Contents of the stat files (as of 2.6.30-rc7) +.. table:: Table 1-4: Contents of the stat fields (as of 2.6.30-rc7) ============= =============================================================== Field Content @@ -1321,9 +1321,9 @@ many times the slaves link has failed. 1.4 SCSI info ------------- -If you have a SCSI host adapter in your system, you'll find a subdirectory -named after the driver for this adapter in /proc/scsi. You'll also see a list -of all recognized SCSI devices in /proc/scsi:: +If you have a SCSI or ATA host adapter in your system, you'll find a +subdirectory named after the driver for this adapter in /proc/scsi. +You'll also see a list of all recognized SCSI devices in /proc/scsi:: >cat /proc/scsi/scsi Attached devices: @@ -1449,16 +1449,18 @@ Various pieces of information about kernel activity are available in the since the system first booted. For a quick look, simply cat the file:: > cat /proc/stat - cpu 2255 34 2290 22625563 6290 127 456 0 0 0 - cpu0 1132 34 1441 11311718 3675 127 438 0 0 0 - cpu1 1123 0 849 11313845 2614 0 18 0 0 0 - intr 114930548 113199788 3 0 5 263 0 4 [... lots more numbers ...] - ctxt 1990473 - btime 1062191376 - processes 2915 - procs_running 1 + cpu 237902850 368826709 106375398 1873517540 1135548 0 14507935 0 0 0 + cpu0 60045249 91891769 26331539 468411416 495718 0 5739640 0 0 0 + cpu1 59746288 91759249 26609887 468860630 312281 0 4384817 0 0 0 + cpu2 59489247 92985423 26904446 467808813 171668 0 2268998 0 0 0 + cpu3 58622065 92190267 26529524 468436680 155879 0 2114478 0 0 0 + intr 8688370575 8 3373 0 0 0 0 0 0 1 40791 0 0 353317 0 0 0 0 224789828 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 190974333 41958554 123983334 43 0 224593 0 0 0 <more 0's deleted> + ctxt 22848221062 + btime 1605316999 + processes 746787147 + procs_running 2 procs_blocked 0 - softirq 183433 0 21755 12 39 1137 231 21459 2263 + softirq 12121874454 100099120 3938138295 127375644 2795979 187870761 0 173808342 3072582055 52608 224184354 The very first "cpu" line aggregates the numbers in all of the other "cpuN" lines. These numbers identify the amount of time the CPU has spent performing @@ -1520,8 +1522,8 @@ softirq. Information about mounted ext4 file systems can be found in /proc/fs/ext4. Each mounted filesystem will have a directory in /proc/fs/ext4 based on its device name (i.e., /proc/fs/ext4/hdc or -/proc/fs/ext4/dm-0). The files in each per-device directory are shown -in Table 1-12, below. +/proc/fs/ext4/sda9 or /proc/fs/ext4/dm-0). The files in each per-device +directory are shown in Table 1-12, below. .. table:: Table 1-12: Files in /proc/fs/ext4/<devname> @@ -1601,12 +1603,12 @@ can inadvertently disrupt your system, it is advisable to read both documentation and source before actually making adjustments. In any case, be very careful when writing to any of these files. The entries in /proc may change slightly between the 2.1.* and the 2.2 kernel, so if there is any doubt -review the kernel documentation in the directory /usr/src/linux/Documentation. +review the kernel documentation in the directory linux/Documentation. This chapter is heavily based on the documentation included in the pre 2.2 kernels, and became part of it in version 2.2.1 of the Linux kernel. -Please see: Documentation/admin-guide/sysctl/ directory for descriptions of these -entries. +Please see: Documentation/admin-guide/sysctl/ directory for descriptions of +these entries. Summary ------- diff --git a/Documentation/filesystems/vfs.rst b/Documentation/filesystems/vfs.rst index f3b344f0c0a4..769be5230210 100644 --- a/Documentation/filesystems/vfs.rst +++ b/Documentation/filesystems/vfs.rst @@ -107,7 +107,7 @@ file /proc/filesystems. struct file_system_type ----------------------- -This describes the filesystem. As of kernel 2.6.39, the following +This describes the filesystem. The following members are defined: .. code-block:: c @@ -115,14 +115,24 @@ members are defined: struct file_system_type { const char *name; int fs_flags; + int (*init_fs_context)(struct fs_context *); + const struct fs_parameter_spec *parameters; struct dentry *(*mount) (struct file_system_type *, int, - const char *, void *); + const char *, void *); void (*kill_sb) (struct super_block *); struct module *owner; struct file_system_type * next; - struct list_head fs_supers; + struct hlist_head fs_supers; + struct lock_class_key s_lock_key; struct lock_class_key s_umount_key; + struct lock_class_key s_vfs_rename_key; + struct lock_class_key s_writers_key[SB_FREEZE_LEVELS]; + + struct lock_class_key i_lock_key; + struct lock_class_key i_mutex_key; + struct lock_class_key invalidate_lock_key; + struct lock_class_key i_mutex_dir_key; }; ``name`` @@ -132,6 +142,15 @@ members are defined: ``fs_flags`` various flags (i.e. FS_REQUIRES_DEV, FS_NO_DCACHE, etc.) +``init_fs_context`` + Initializes 'struct fs_context' ->ops and ->fs_private fields with + filesystem-specific data. + +``parameters`` + Pointer to the array of filesystem parameters descriptors + 'struct fs_parameter_spec'. + More info in Documentation/filesystems/mount_api.rst. + ``mount`` the method to call when a new instance of this filesystem should be mounted @@ -148,7 +167,11 @@ members are defined: ``next`` for internal VFS use: you should initialize this to NULL - s_lock_key, s_umount_key: lockdep-specific +``fs_supers`` + for internal VFS use: hlist of filesystem instances (superblocks) + + s_lock_key, s_umount_key, s_vfs_rename_key, s_writers_key, + i_lock_key, i_mutex_key, invalidate_lock_key, i_mutex_dir_key: lockdep-specific The mount() method has the following arguments: @@ -222,33 +245,42 @@ struct super_operations ----------------------- This describes how the VFS can manipulate the superblock of your -filesystem. As of kernel 2.6.22, the following members are defined: +filesystem. The following members are defined: .. code-block:: c struct super_operations { struct inode *(*alloc_inode)(struct super_block *sb); void (*destroy_inode)(struct inode *); + void (*free_inode)(struct inode *); void (*dirty_inode) (struct inode *, int flags); - int (*write_inode) (struct inode *, int); - void (*drop_inode) (struct inode *); - void (*delete_inode) (struct inode *); + int (*write_inode) (struct inode *, struct writeback_control *wbc); + int (*drop_inode) (struct inode *); + void (*evict_inode) (struct inode *); void (*put_super) (struct super_block *); int (*sync_fs)(struct super_block *sb, int wait); + int (*freeze_super) (struct super_block *); int (*freeze_fs) (struct super_block *); + int (*thaw_super) (struct super_block *); int (*unfreeze_fs) (struct super_block *); int (*statfs) (struct dentry *, struct kstatfs *); int (*remount_fs) (struct super_block *, int *, char *); - void (*clear_inode) (struct inode *); void (*umount_begin) (struct super_block *); int (*show_options)(struct seq_file *, struct dentry *); + int (*show_devname)(struct seq_file *, struct dentry *); + int (*show_path)(struct seq_file *, struct dentry *); + int (*show_stats)(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 (*nr_cached_objects)(struct super_block *); - void (*free_cached_objects)(struct super_block *, int); + struct dquot **(*get_dquots)(struct inode *); + + long (*nr_cached_objects)(struct super_block *, + struct shrink_control *); + long (*free_cached_objects)(struct super_block *, + struct shrink_control *); }; All methods are called without any locks being held, unless otherwise @@ -269,6 +301,11 @@ or bottom half). ->alloc_inode was defined and simply undoes anything done by ->alloc_inode. +``free_inode`` + this method is called from RCU callback. If you use call_rcu() + in ->destroy_inode to free 'struct inode' memory, then it's + better to release memory in this method. + ``dirty_inode`` this method is called by the VFS when an inode is marked dirty. This is specifically for the inode itself being marked dirty, @@ -296,8 +333,12 @@ or bottom half). practice of using "force_delete" in the put_inode() case, but does not have the races that the "force_delete()" approach had. -``delete_inode`` - called when the VFS wants to delete an inode +``evict_inode`` + called when the VFS wants to evict an inode. Caller does + *not* evict the pagecache or inode-associated metadata buffers; + the method has to use truncate_inode_pages_final() to get rid + of those. Caller makes sure async writeback cannot be running for + the inode while (or after) ->evict_inode() is called. Optional. ``put_super`` called when the VFS wishes to free the superblock @@ -308,14 +349,25 @@ or bottom half). superblock. The second parameter indicates whether the method should wait until the write out has been completed. Optional. +``freeze_super`` + Called instead of ->freeze_fs callback if provided. + Main difference is that ->freeze_super is called without taking + down_write(&sb->s_umount). If filesystem implements it and wants + ->freeze_fs to be called too, then it has to call ->freeze_fs + explicitly from this callback. Optional. + ``freeze_fs`` called when VFS is locking a filesystem and forcing it into a consistent state. This method is currently used by the Logical - Volume Manager (LVM). + Volume Manager (LVM) and ioctl(FIFREEZE). Optional. + +``thaw_super`` + called when VFS is unlocking a filesystem and making it writable + again after ->freeze_super. Optional. ``unfreeze_fs`` called when VFS is unlocking a filesystem and making it writable - again. + again after ->freeze_fs. Optional. ``statfs`` called when the VFS needs to get filesystem statistics. @@ -324,22 +376,37 @@ or bottom half). called when the filesystem is remounted. This is called with the kernel lock held -``clear_inode`` - called then the VFS clears the inode. Optional - ``umount_begin`` called when the VFS is unmounting a filesystem. ``show_options`` - called by the VFS to show mount options for /proc/<pid>/mounts. + called by the VFS to show mount options for /proc/<pid>/mounts + and /proc/<pid>/mountinfo. (see "Mount Options" section) +``show_devname`` + Optional. Called by the VFS to show device name for + /proc/<pid>/{mounts,mountinfo,mountstats}. If not provided then + '(struct mount).mnt_devname' will be used. + +``show_path`` + Optional. Called by the VFS (for /proc/<pid>/mountinfo) to show + the mount root dentry path relative to the filesystem root. + +``show_stats`` + Optional. Called by the VFS (for /proc/<pid>/mountstats) to show + filesystem-specific mount statistics. + ``quota_read`` called by the VFS to read from filesystem quota file. ``quota_write`` called by the VFS to write to filesystem quota file. +``get_dquots`` + called by quota to get 'struct dquot' array for a particular inode. + Optional. + ``nr_cached_objects`` called by the sb cache shrinking function for the filesystem to return the number of freeable cached objects it contains. diff --git a/Documentation/gpu/amdgpu/display/display-manager.rst b/Documentation/gpu/amdgpu/display/display-manager.rst index b7abb18cfc82..be2651ecdd7f 100644 --- a/Documentation/gpu/amdgpu/display/display-manager.rst +++ b/Documentation/gpu/amdgpu/display/display-manager.rst @@ -173,7 +173,7 @@ The alpha blending equation is configured from DRM to DC interface by the following path: 1. When updating a :c:type:`drm_plane_state <drm_plane_state>`, DM calls - :c:type:`fill_blending_from_plane_state()` that maps + :c:type:`amdgpu_dm_plane_fill_blending_from_plane_state()` that maps :c:type:`drm_plane_state <drm_plane_state>` attributes to :c:type:`dc_plane_info <dc_plane_info>` struct to be handled in the OS-agnostic component (DC). diff --git a/Documentation/index.rst b/Documentation/index.rst index 76d1a3ec9be3..9dfdc826618c 100644 --- a/Documentation/index.rst +++ b/Documentation/index.rst @@ -99,7 +99,7 @@ Architecture-specific documentation .. toctree:: :maxdepth: 2 - arch + arch/index Other documentation diff --git a/Documentation/kbuild/llvm.rst b/Documentation/kbuild/llvm.rst index bfb51685073c..c3851fe1900d 100644 --- a/Documentation/kbuild/llvm.rst +++ b/Documentation/kbuild/llvm.rst @@ -171,6 +171,10 @@ Getting Help Getting LLVM ------------- +We provide prebuilt stable versions of LLVM on `kernel.org <https://kernel.org/pub/tools/llvm/>`_. +Below are links that may be useful for building LLVM from source or procuring +it through a distribution's package manager. + - https://releases.llvm.org/download.html - https://github.com/llvm/llvm-project - https://llvm.org/docs/GettingStarted.html diff --git a/Documentation/kernel-hacking/false-sharing.rst b/Documentation/kernel-hacking/false-sharing.rst new file mode 100644 index 000000000000..122b0e124656 --- /dev/null +++ b/Documentation/kernel-hacking/false-sharing.rst @@ -0,0 +1,206 @@ +.. SPDX-License-Identifier: GPL-2.0 + +============= +False Sharing +============= + +What is False Sharing +===================== +False sharing is related with cache mechanism of maintaining the data +coherence of one cache line stored in multiple CPU's caches; then +academic definition for it is in [1]_. Consider a struct with a +refcount and a string:: + + struct foo { + refcount_t refcount; + ... + char name[16]; + } ____cacheline_internodealigned_in_smp; + +Member 'refcount'(A) and 'name'(B) _share_ one cache line like below:: + + +-----------+ +-----------+ + | CPU 0 | | CPU 1 | + +-----------+ +-----------+ + / | + / | + V V + +----------------------+ +----------------------+ + | A B | Cache 0 | A B | Cache 1 + +----------------------+ +----------------------+ + | | + ---------------------------+------------------+----------------------------- + | | + +----------------------+ + | | + +----------------------+ + Main Memory | A B | + +----------------------+ + +'refcount' is modified frequently, but 'name' is set once at object +creation time and is never modified. When many CPUs access 'foo' at +the same time, with 'refcount' being only bumped by one CPU frequently +and 'name' being read by other CPUs, all those reading CPUs have to +reload the whole cache line over and over due to the 'sharing', even +though 'name' is never changed. + +There are many real-world cases of performance regressions caused by +false sharing. One of these is a rw_semaphore 'mmap_lock' inside +mm_struct struct, whose cache line layout change triggered a +regression and Linus analyzed in [2]_. + +There are two key factors for a harmful false sharing: + +* A global datum accessed (shared) by many CPUs +* In the concurrent accesses to the data, there is at least one write + operation: write/write or write/read cases. + +The sharing could be from totally unrelated kernel components, or +different code paths of the same kernel component. + + +False Sharing Pitfalls +====================== +Back in time when one platform had only one or a few CPUs, hot data +members could be purposely put in the same cache line to make them +cache hot and save cacheline/TLB, like a lock and the data protected +by it. But for recent large system with hundreds of CPUs, this may +not work when the lock is heavily contended, as the lock owner CPU +could write to the data, while other CPUs are busy spinning the lock. + +Looking at past cases, there are several frequently occurring patterns +for false sharing: + +* lock (spinlock/mutex/semaphore) and data protected by it are + purposely put in one cache line. +* global data being put together in one cache line. Some kernel + subsystems have many global parameters of small size (4 bytes), + which can easily be grouped together and put into one cache line. +* data members of a big data structure randomly sitting together + without being noticed (cache line is usually 64 bytes or more), + like 'mem_cgroup' struct. + +Following 'mitigation' section provides real-world examples. + +False sharing could easily happen unless they are intentionally +checked, and it is valuable to run specific tools for performance +critical workloads to detect false sharing affecting performance case +and optimize accordingly. + + +How to detect and analyze False Sharing +======================================== +perf record/report/stat are widely used for performance tuning, and +once hotspots are detected, tools like 'perf-c2c' and 'pahole' can +be further used to detect and pinpoint the possible false sharing +data structures. 'addr2line' is also good at decoding instruction +pointer when there are multiple layers of inline functions. + +perf-c2c can capture the cache lines with most false sharing hits, +decoded functions (line number of file) accessing that cache line, +and in-line offset of the data. Simple commands are:: + + $ perf c2c record -ag sleep 3 + $ perf c2c report --call-graph none -k vmlinux + +When running above during testing will-it-scale's tlb_flush1 case, +perf reports something like:: + + Total records : 1658231 + Locked Load/Store Operations : 89439 + Load Operations : 623219 + Load Local HITM : 92117 + Load Remote HITM : 139 + + #---------------------------------------------------------------------- + 4 0 2374 0 0 0 0xff1100088366d880 + #---------------------------------------------------------------------- + 0.00% 42.29% 0.00% 0.00% 0.00% 0x8 1 1 0xffffffff81373b7b 0 231 129 5312 64 [k] __mod_lruvec_page_state [kernel.vmlinux] memcontrol.h:752 1 + 0.00% 13.10% 0.00% 0.00% 0.00% 0x8 1 1 0xffffffff81374718 0 226 97 3551 64 [k] folio_lruvec_lock_irqsave [kernel.vmlinux] memcontrol.h:752 1 + 0.00% 11.20% 0.00% 0.00% 0.00% 0x8 1 1 0xffffffff812c29bf 0 170 136 555 64 [k] lru_add_fn [kernel.vmlinux] mm_inline.h:41 1 + 0.00% 7.62% 0.00% 0.00% 0.00% 0x8 1 1 0xffffffff812c3ec5 0 175 108 632 64 [k] release_pages [kernel.vmlinux] mm_inline.h:41 1 + 0.00% 23.29% 0.00% 0.00% 0.00% 0x10 1 1 0xffffffff81372d0a 0 234 279 1051 64 [k] __mod_memcg_lruvec_state [kernel.vmlinux] memcontrol.c:736 1 + +A nice introduction for perf-c2c is [3]_. + +'pahole' decodes data structure layouts delimited in cache line +granularity. Users can match the offset in perf-c2c output with +pahole's decoding to locate the exact data members. For global +data, users can search the data address in System.map. + + +Possible Mitigations +==================== +False sharing does not always need to be mitigated. False sharing +mitigations should balance performance gains with complexity and +space consumption. Sometimes, lower performance is OK, and it's +unnecessary to hyper-optimize every rarely used data structure or +a cold data path. + +False sharing hurting performance cases are seen more frequently with +core count increasing. Because of these detrimental effects, many +patches have been proposed across variety of subsystems (like +networking and memory management) and merged. Some common mitigations +(with examples) are: + +* Separate hot global data in its own dedicated cache line, even if it + is just a 'short' type. The downside is more consumption of memory, + cache line and TLB entries. + + - Commit 91b6d3256356 ("net: cache align tcp_memory_allocated, tcp_sockets_allocated") + +* Reorganize the data structure, separate the interfering members to + different cache lines. One downside is it may introduce new false + sharing of other members. + + - Commit 802f1d522d5f ("mm: page_counter: re-layout structure to reduce false sharing") + +* Replace 'write' with 'read' when possible, especially in loops. + Like for some global variable, use compare(read)-then-write instead + of unconditional write. For example, use:: + + if (!test_bit(XXX)) + set_bit(XXX); + + instead of directly "set_bit(XXX);", similarly for atomic_t data:: + + if (atomic_read(XXX) == AAA) + atomic_set(XXX, BBB); + + - Commit 7b1002f7cfe5 ("bcache: fixup bcache_dev_sectors_dirty_add() multithreaded CPU false sharing") + - Commit 292648ac5cf1 ("mm: gup: allow FOLL_PIN to scale in SMP") + +* Turn hot global data to 'per-cpu data + global data' when possible, + or reasonably increase the threshold for syncing per-cpu data to + global data, to reduce or postpone the 'write' to that global data. + + - Commit 520f897a3554 ("ext4: use percpu_counters for extent_status cache hits/misses") + - Commit 56f3547bfa4d ("mm: adjust vm_committed_as_batch according to vm overcommit policy") + +Surely, all mitigations should be carefully verified to not cause side +effects. To avoid introducing false sharing when coding, it's better +to: + +* Be aware of cache line boundaries +* Group mostly read-only fields together +* Group things that are written at the same time together +* Separate frequently read and frequently written fields on + different cache lines. + +and better add a comment stating the false sharing consideration. + +One note is, sometimes even after a severe false sharing is detected +and solved, the performance may still have no obvious improvement as +the hotspot switches to a new place. + + +Miscellaneous +============= +One open issue is that kernel has an optional data structure +randomization mechanism, which also randomizes the situation of cache +line sharing of data members. + + +.. [1] https://en.wikipedia.org/wiki/False_sharing +.. [2] https://lore.kernel.org/lkml/CAHk-=whoqV=cX5VC80mmR9rr+Z+yQ6fiQZm36Fb-izsanHg23w@mail.gmail.com/ +.. [3] https://joemario.github.io/blog/2016/09/01/c2c-blog/ diff --git a/Documentation/kernel-hacking/index.rst b/Documentation/kernel-hacking/index.rst index f53027652290..79c03bac99a2 100644 --- a/Documentation/kernel-hacking/index.rst +++ b/Documentation/kernel-hacking/index.rst @@ -9,3 +9,4 @@ Kernel Hacking Guides hacking locking + false-sharing diff --git a/Documentation/litmus-tests/README b/Documentation/litmus-tests/README index 7f5c6c3ed6c3..658d37860d39 100644 --- a/Documentation/litmus-tests/README +++ b/Documentation/litmus-tests/README @@ -9,7 +9,7 @@ a kernel test module based on a litmus test, please see tools/memory-model/README. -atomic (/atomic derectory) +atomic (/atomic directory) -------------------------- Atomic-RMW+mb__after_atomic-is-stronger-than-acquire.litmus diff --git a/Documentation/litmus-tests/locking/DCL-broken.litmus b/Documentation/litmus-tests/locking/DCL-broken.litmus new file mode 100644 index 000000000000..bfb7ba4316d6 --- /dev/null +++ b/Documentation/litmus-tests/locking/DCL-broken.litmus @@ -0,0 +1,54 @@ +C DCL-broken + +(* + * Result: Sometimes + * + * This litmus test demonstrates more than just locking is required to + * correctly implement double-checked locking. + *) + +{ + int flag; + int data; +} + +P0(int *flag, int *data, spinlock_t *lck) +{ + int r0; + int r1; + int r2; + + r0 = READ_ONCE(*flag); + if (r0 == 0) { + spin_lock(lck); + r1 = READ_ONCE(*flag); + if (r1 == 0) { + WRITE_ONCE(*data, 1); + WRITE_ONCE(*flag, 1); + } + spin_unlock(lck); + } + r2 = READ_ONCE(*data); +} + +P1(int *flag, int *data, spinlock_t *lck) +{ + int r0; + int r1; + int r2; + + r0 = READ_ONCE(*flag); + if (r0 == 0) { + spin_lock(lck); + r1 = READ_ONCE(*flag); + if (r1 == 0) { + WRITE_ONCE(*data, 1); + WRITE_ONCE(*flag, 1); + } + spin_unlock(lck); + } + r2 = READ_ONCE(*data); +} + +locations [flag;data;0:r0;0:r1;1:r0;1:r1] +exists (0:r2=0 \/ 1:r2=0) diff --git a/Documentation/litmus-tests/locking/DCL-fixed.litmus b/Documentation/litmus-tests/locking/DCL-fixed.litmus new file mode 100644 index 000000000000..d1b60bcb0c8f --- /dev/null +++ b/Documentation/litmus-tests/locking/DCL-fixed.litmus @@ -0,0 +1,55 @@ +C DCL-fixed + +(* + * Result: Never + * + * This litmus test demonstrates that double-checked locking can be + * reliable given proper use of smp_load_acquire() and smp_store_release() + * in addition to the locking. + *) + +{ + int flag; + int data; +} + +P0(int *flag, int *data, spinlock_t *lck) +{ + int r0; + int r1; + int r2; + + r0 = smp_load_acquire(flag); + if (r0 == 0) { + spin_lock(lck); + r1 = READ_ONCE(*flag); + if (r1 == 0) { + WRITE_ONCE(*data, 1); + smp_store_release(flag, 1); + } + spin_unlock(lck); + } + r2 = READ_ONCE(*data); +} + +P1(int *flag, int *data, spinlock_t *lck) +{ + int r0; + int r1; + int r2; + + r0 = smp_load_acquire(flag); + if (r0 == 0) { + spin_lock(lck); + r1 = READ_ONCE(*flag); + if (r1 == 0) { + WRITE_ONCE(*data, 1); + smp_store_release(flag, 1); + } + spin_unlock(lck); + } + r2 = READ_ONCE(*data); +} + +locations [flag;data;0:r0;0:r1;1:r0;1:r1] +exists (0:r2=0 \/ 1:r2=0) diff --git a/Documentation/litmus-tests/locking/RM-broken.litmus b/Documentation/litmus-tests/locking/RM-broken.litmus new file mode 100644 index 000000000000..b7ef30cedfe5 --- /dev/null +++ b/Documentation/litmus-tests/locking/RM-broken.litmus @@ -0,0 +1,41 @@ +C RM-broken + +(* + * Result: DEADLOCK + * + * This litmus test demonstrates that the old "roach motel" approach + * to locking, where code can be freely moved into critical sections, + * cannot be used in the Linux kernel. + *) + +{ + int x; + atomic_t y; +} + +P0(int *x, atomic_t *y, spinlock_t *lck) +{ + int r2; + + spin_lock(lck); + r2 = atomic_inc_return(y); + WRITE_ONCE(*x, 1); + spin_unlock(lck); +} + +P1(int *x, atomic_t *y, spinlock_t *lck) +{ + int r0; + int r1; + int r2; + + spin_lock(lck); + r0 = READ_ONCE(*x); + r1 = READ_ONCE(*x); + r2 = atomic_inc_return(y); + spin_unlock(lck); +} + +locations [x;0:r2;1:r0;1:r1;1:r2] +filter (1:r0=0 /\ 1:r1=1) +exists (1:r2=1) diff --git a/Documentation/litmus-tests/locking/RM-fixed.litmus b/Documentation/litmus-tests/locking/RM-fixed.litmus new file mode 100644 index 000000000000..b62817559616 --- /dev/null +++ b/Documentation/litmus-tests/locking/RM-fixed.litmus @@ -0,0 +1,41 @@ +C RM-fixed + +(* + * Result: Never + * + * This litmus test demonstrates that the old "roach motel" approach + * to locking, where code can be freely moved into critical sections, + * cannot be used in the Linux kernel. + *) + +{ + int x; + atomic_t y; +} + +P0(int *x, atomic_t *y, spinlock_t *lck) +{ + int r2; + + spin_lock(lck); + r2 = atomic_inc_return(y); + WRITE_ONCE(*x, 1); + spin_unlock(lck); +} + +P1(int *x, atomic_t *y, spinlock_t *lck) +{ + int r0; + int r1; + int r2; + + r0 = READ_ONCE(*x); + r1 = READ_ONCE(*x); + spin_lock(lck); + r2 = atomic_inc_return(y); + spin_unlock(lck); +} + +locations [x;0:r2;1:r0;1:r1;1:r2] +filter (1:r0=0 /\ 1:r1=1) +exists (1:r2=1) diff --git a/Documentation/livepatch/module-elf-format.rst b/Documentation/livepatch/module-elf-format.rst index d48f530c0881..a03ed02ec57e 100644 --- a/Documentation/livepatch/module-elf-format.rst +++ b/Documentation/livepatch/module-elf-format.rst @@ -1,8 +1,8 @@ =========================== -Livepatch module Elf format +Livepatch module ELF format =========================== -This document outlines the Elf format requirements that livepatch modules must follow. +This document outlines the ELF format requirements that livepatch modules must follow. .. Table of Contents @@ -20,17 +20,17 @@ code. So, instead of duplicating code and re-implementing what the module loader can already do, livepatch leverages existing code in the module loader to perform the all the arch-specific relocation work. Specifically, livepatch reuses the apply_relocate_add() function in the module loader to -write relocations. The patch module Elf format described in this document +write relocations. The patch module ELF format described in this document enables livepatch to be able to do this. The hope is that this will make livepatch more easily portable to other architectures and reduce the amount of arch-specific code required to port livepatch to a particular architecture. Since apply_relocate_add() requires access to a module's section header -table, symbol table, and relocation section indices, Elf information is +table, symbol table, and relocation section indices, ELF information is preserved for livepatch modules (see section 5). Livepatch manages its own relocation sections and symbols, which are described in this document. The -Elf constants used to mark livepatch symbols and relocation sections were +ELF constants used to mark livepatch symbols and relocation sections were selected from OS-specific ranges according to the definitions from glibc. Why does livepatch need to write its own relocations? @@ -43,7 +43,7 @@ reject the livepatch module. Furthermore, we cannot apply relocations that affect modules not yet loaded at patch module load time (e.g. a patch to a driver that is not loaded). Formerly, livepatch solved this problem by embedding special "dynrela" (dynamic rela) sections in the resulting patch -module Elf output. Using these dynrela sections, livepatch could resolve +module ELF output. Using these dynrela sections, livepatch could resolve symbols while taking into account its scope and what module the symbol belongs to, and then manually apply the dynamic relocations. However this approach required livepatch to supply arch-specific code in order to write @@ -80,7 +80,7 @@ Example: 3. Livepatch relocation sections ================================ -A livepatch module manages its own Elf relocation sections to apply +A livepatch module manages its own ELF relocation sections to apply relocations to modules as well as to the kernel (vmlinux) at the appropriate time. For example, if a patch module patches a driver that is not currently loaded, livepatch will apply the corresponding livepatch @@ -95,7 +95,7 @@ also possible for a livepatch module to have no livepatch relocation sections, as in the case of the sample livepatch module (see samples/livepatch). -Since Elf information is preserved for livepatch modules (see Section 5), a +Since ELF information is preserved for livepatch modules (see Section 5), a livepatch relocation section can be applied simply by passing in the appropriate section index to apply_relocate_add(), which then uses it to access the relocation section and apply the relocations. @@ -291,12 +291,12 @@ Examples: Note that the 'Ndx' (Section index) for these symbols is SHN_LIVEPATCH (0xff20). "OS" means OS-specific. -5. Symbol table and Elf section access +5. Symbol table and ELF section access ====================================== A livepatch module's symbol table is accessible through module->symtab. Since apply_relocate_add() requires access to a module's section headers, -symbol table, and relocation section indices, Elf information is preserved for +symbol table, and relocation section indices, ELF information is preserved for livepatch modules and is made accessible by the module loader through module->klp_info, which is a :c:type:`klp_modinfo` struct. When a livepatch module loads, this struct is filled in by the module loader. diff --git a/Documentation/mm/physical_memory.rst b/Documentation/mm/physical_memory.rst index 1bc888d36ea1..531e73b003dd 100644 --- a/Documentation/mm/physical_memory.rst +++ b/Documentation/mm/physical_memory.rst @@ -19,7 +19,7 @@ a bank of memory very suitable for DMA near peripheral devices. Each bank is called a node and the concept is represented under Linux by a ``struct pglist_data`` even if the architecture is UMA. This structure is -always referenced to by it's typedef ``pg_data_t``. ``A pg_data_t`` structure +always referenced by its typedef ``pg_data_t``. A ``pg_data_t`` structure for a particular node can be referenced by ``NODE_DATA(nid)`` macro where ``nid`` is the ID of that node. @@ -114,6 +114,25 @@ RAM equally split between two nodes, there will be ``ZONE_DMA32``, | DMA32 | NORMAL | MOVABLE | | NORMAL | MOVABLE | +---------+----------+-----------+ +------------+-------------+ + +Memory banks may belong to interleaving nodes. In the example below an x86 +machine has 16 Gbytes of RAM in 4 memory banks, even banks belong to node 0 +and odd banks belong to node 1:: + + + 0 4G 8G 12G 16G + +-------------+ +-------------+ +-------------+ +-------------+ + | node 0 | | node 1 | | node 0 | | node 1 | + +-------------+ +-------------+ +-------------+ +-------------+ + + 0 16M 4G + +-----+-------+ +-------------+ +-------------+ +-------------+ + | DMA | DMA32 | | NORMAL | | NORMAL | | NORMAL | + +-----+-------+ +-------------+ +-------------+ +-------------+ + +In this case node 0 will span from 0 to 12 Gbytes and node 1 will span from +4 to 16 Gbytes. + .. _nodes: Nodes diff --git a/Documentation/mm/zsmalloc.rst b/Documentation/mm/zsmalloc.rst index 64d127bfc221..a3c26d587752 100644 --- a/Documentation/mm/zsmalloc.rst +++ b/Documentation/mm/zsmalloc.rst @@ -39,13 +39,12 @@ With CONFIG_ZSMALLOC_STAT, we could see zsmalloc internal information via # cat /sys/kernel/debug/zsmalloc/zram0/classes - class size almost_full almost_empty obj_allocated obj_used pages_used pages_per_zspage + class size 10% 20% 30% 40% 50% 60% 70% 80% 90% 99% 100% obj_allocated obj_used pages_used pages_per_zspage freeable ... ... - 9 176 0 1 186 129 8 4 - 10 192 1 0 2880 2872 135 3 - 11 208 0 1 819 795 42 2 - 12 224 0 1 219 159 12 4 + 30 512 0 12 4 1 0 1 0 0 1 0 414 3464 3346 433 1 14 + 31 528 2 7 2 2 1 0 1 0 0 2 117 4154 3793 536 4 44 + 32 544 6 3 4 1 2 1 0 0 0 1 260 4170 3965 556 2 26 ... ... @@ -54,10 +53,28 @@ class index size object size zspage stores -almost_empty - the number of ZS_ALMOST_EMPTY zspages(see below) -almost_full - the number of ZS_ALMOST_FULL zspages(see below) +10% + the number of zspages with usage ratio less than 10% (see below) +20% + the number of zspages with usage ratio between 10% and 20% +30% + the number of zspages with usage ratio between 20% and 30% +40% + the number of zspages with usage ratio between 30% and 40% +50% + the number of zspages with usage ratio between 40% and 50% +60% + the number of zspages with usage ratio between 50% and 60% +70% + the number of zspages with usage ratio between 60% and 70% +80% + the number of zspages with usage ratio between 70% and 80% +90% + the number of zspages with usage ratio between 80% and 90% +99% + the number of zspages with usage ratio between 90% and 99% +100% + the number of zspages with usage ratio 100% obj_allocated the number of objects allocated obj_used @@ -66,19 +83,14 @@ pages_used the number of pages allocated for the class pages_per_zspage the number of 0-order pages to make a zspage +freeable + the approximate number of pages class compaction can free -We assign a zspage to ZS_ALMOST_EMPTY fullness group when n <= N / f, where - -* n = number of allocated objects -* N = total number of objects zspage can store -* f = fullness_threshold_frac(ie, 4 at the moment) - -Similarly, we assign zspage to: - -* ZS_ALMOST_FULL when n > N / f -* ZS_EMPTY when n == 0 -* ZS_FULL when n == N - +Each zspage maintains inuse counter which keeps track of the number of +objects stored in the zspage. The inuse counter determines the zspage's +"fullness group" which is calculated as the ratio of the "inuse" objects to +the total number of objects the zspage can hold (objs_per_zspage). The +closer the inuse counter is to objs_per_zspage, the better. Internals ========= @@ -94,10 +106,10 @@ of objects that each zspage can store. For instance, consider the following size classes::: - class size almost_full almost_empty obj_allocated obj_used pages_used pages_per_zspage freeable + class size 10% .... 100% obj_allocated obj_used pages_used pages_per_zspage freeable ... - 94 1536 0 0 0 0 0 3 0 - 100 1632 0 0 0 0 0 2 0 + 94 1536 0 .... 0 0 0 0 3 0 + 100 1632 0 .... 0 0 0 0 2 0 ... @@ -134,10 +146,11 @@ reduces memory wastage. Let's take a closer look at the bottom of `/sys/kernel/debug/zsmalloc/zramX/classes`::: - class size almost_full almost_empty obj_allocated obj_used pages_used pages_per_zspage freeable + class size 10% .... 100% obj_allocated obj_used pages_used pages_per_zspage freeable + ... - 202 3264 0 0 0 0 0 4 0 - 254 4096 0 0 0 0 0 1 0 + 202 3264 0 .. 0 0 0 0 4 0 + 254 4096 0 .. 0 0 0 0 1 0 ... Size class #202 stores objects of size 3264 bytes and has a maximum of 4 pages @@ -151,40 +164,42 @@ efficient storage of large objects. For zspage chain size of 8, huge class watermark becomes 3632 bytes::: - class size almost_full almost_empty obj_allocated obj_used pages_used pages_per_zspage freeable + class size 10% .... 100% obj_allocated obj_used pages_used pages_per_zspage freeable + ... - 202 3264 0 0 0 0 0 4 0 - 211 3408 0 0 0 0 0 5 0 - 217 3504 0 0 0 0 0 6 0 - 222 3584 0 0 0 0 0 7 0 - 225 3632 0 0 0 0 0 8 0 - 254 4096 0 0 0 0 0 1 0 + 202 3264 0 .. 0 0 0 0 4 0 + 211 3408 0 .. 0 0 0 0 5 0 + 217 3504 0 .. 0 0 0 0 6 0 + 222 3584 0 .. 0 0 0 0 7 0 + 225 3632 0 .. 0 0 0 0 8 0 + 254 4096 0 .. 0 0 0 0 1 0 ... For zspage chain size of 16, huge class watermark becomes 3840 bytes::: - class size almost_full almost_empty obj_allocated obj_used pages_used pages_per_zspage freeable + class size 10% .... 100% obj_allocated obj_used pages_used pages_per_zspage freeable + ... - 202 3264 0 0 0 0 0 4 0 - 206 3328 0 0 0 0 0 13 0 - 207 3344 0 0 0 0 0 9 0 - 208 3360 0 0 0 0 0 14 0 - 211 3408 0 0 0 0 0 5 0 - 212 3424 0 0 0 0 0 16 0 - 214 3456 0 0 0 0 0 11 0 - 217 3504 0 0 0 0 0 6 0 - 219 3536 0 0 0 0 0 13 0 - 222 3584 0 0 0 0 0 7 0 - 223 3600 0 0 0 0 0 15 0 - 225 3632 0 0 0 0 0 8 0 - 228 3680 0 0 0 0 0 9 0 - 230 3712 0 0 0 0 0 10 0 - 232 3744 0 0 0 0 0 11 0 - 234 3776 0 0 0 0 0 12 0 - 235 3792 0 0 0 0 0 13 0 - 236 3808 0 0 0 0 0 14 0 - 238 3840 0 0 0 0 0 15 0 - 254 4096 0 0 0 0 0 1 0 + 202 3264 0 .. 0 0 0 0 4 0 + 206 3328 0 .. 0 0 0 0 13 0 + 207 3344 0 .. 0 0 0 0 9 0 + 208 3360 0 .. 0 0 0 0 14 0 + 211 3408 0 .. 0 0 0 0 5 0 + 212 3424 0 .. 0 0 0 0 16 0 + 214 3456 0 .. 0 0 0 0 11 0 + 217 3504 0 .. 0 0 0 0 6 0 + 219 3536 0 .. 0 0 0 0 13 0 + 222 3584 0 .. 0 0 0 0 7 0 + 223 3600 0 .. 0 0 0 0 15 0 + 225 3632 0 .. 0 0 0 0 8 0 + 228 3680 0 .. 0 0 0 0 9 0 + 230 3712 0 .. 0 0 0 0 10 0 + 232 3744 0 .. 0 0 0 0 11 0 + 234 3776 0 .. 0 0 0 0 12 0 + 235 3792 0 .. 0 0 0 0 13 0 + 236 3808 0 .. 0 0 0 0 14 0 + 238 3840 0 .. 0 0 0 0 15 0 + 254 4096 0 .. 0 0 0 0 1 0 ... Overall the combined zspage chain size effect on zsmalloc pool configuration::: @@ -214,9 +229,10 @@ zram as a build artifacts storage (Linux kernel compilation). zsmalloc classes stats::: - class size almost_full almost_empty obj_allocated obj_used pages_used pages_per_zspage freeable + class size 10% .... 100% obj_allocated obj_used pages_used pages_per_zspage freeable + ... - Total 13 51 413836 412973 159955 3 + Total 13 .. 51 413836 412973 159955 3 zram mm_stat::: @@ -227,9 +243,10 @@ zram as a build artifacts storage (Linux kernel compilation). zsmalloc classes stats::: - class size almost_full almost_empty obj_allocated obj_used pages_used pages_per_zspage freeable + class size 10% .... 100% obj_allocated obj_used pages_used pages_per_zspage freeable + ... - Total 18 87 414852 412978 156666 0 + Total 18 .. 87 414852 412978 156666 0 zram mm_stat::: diff --git a/Documentation/networking/devlink/ice.rst b/Documentation/networking/devlink/ice.rst index 10f282c2117c..2f60e34ab926 100644 --- a/Documentation/networking/devlink/ice.rst +++ b/Documentation/networking/devlink/ice.rst @@ -7,6 +7,21 @@ ice devlink support This document describes the devlink features implemented by the ``ice`` device driver. +Parameters +========== + +.. list-table:: Generic parameters implemented + + * - Name + - Mode + - Notes + * - ``enable_roce`` + - runtime + - mutually exclusive with ``enable_iwarp`` + * - ``enable_iwarp`` + - runtime + - mutually exclusive with ``enable_roce`` + Info versions ============= diff --git a/Documentation/networking/ip-sysctl.rst b/Documentation/networking/ip-sysctl.rst index 87dd1c5283e6..58a78a316697 100644 --- a/Documentation/networking/ip-sysctl.rst +++ b/Documentation/networking/ip-sysctl.rst @@ -340,6 +340,8 @@ tcp_app_win - INTEGER Reserve max(window/2^tcp_app_win, mss) of window for application buffer. Value 0 is special, it means that nothing is reserved. + Possible values are [0, 31], inclusive. + Default: 31 tcp_autocorking - BOOLEAN diff --git a/Documentation/networking/xdp-rx-metadata.rst b/Documentation/networking/xdp-rx-metadata.rst index aac63fc2d08b..25ce72af81c2 100644 --- a/Documentation/networking/xdp-rx-metadata.rst +++ b/Documentation/networking/xdp-rx-metadata.rst @@ -23,10 +23,13 @@ metadata is supported, this set will grow: An XDP program can use these kfuncs to read the metadata into stack variables for its own consumption. Or, to pass the metadata on to other consumers, an XDP program can store it into the metadata area carried -ahead of the packet. +ahead of the packet. Not all packets will necessary have the requested +metadata available in which case the driver returns ``-ENODATA``. Not all kfuncs have to be implemented by the device driver; when not -implemented, the default ones that return ``-EOPNOTSUPP`` will be used. +implemented, the default ones that return ``-EOPNOTSUPP`` will be used +to indicate the device driver have not implemented this kfunc. + Within an XDP frame, the metadata layout (accessed via ``xdp_buff``) is as follows:: diff --git a/Documentation/process/coding-style.rst b/Documentation/process/coding-style.rst index 007e49ef6cec..6db37a46d305 100644 --- a/Documentation/process/coding-style.rst +++ b/Documentation/process/coding-style.rst @@ -1267,5 +1267,5 @@ gcc internals and indent, all available from https://www.gnu.org/manual/ WG14 is the international standardization working group for the programming language C, URL: http://www.open-std.org/JTC1/SC22/WG14/ -Kernel :ref:`process/coding-style.rst <codingstyle>`, by greg@kroah.com at OLS 2002: +Kernel CodingStyle, by greg@kroah.com at OLS 2002: http://www.kroah.com/linux/talks/ols_2002_kernel_codingstyle_talk/html/ diff --git a/Documentation/process/contribution-maturity-model.rst b/Documentation/process/contribution-maturity-model.rst new file mode 100644 index 000000000000..b87ab34de22c --- /dev/null +++ b/Documentation/process/contribution-maturity-model.rst @@ -0,0 +1,109 @@ +.. SPDX-License-Identifier: GPL-2.0 + +======================================== +Linux Kernel Contribution Maturity Model +======================================== + + +Background +========== + +As a part of the 2021 Linux Kernel Maintainers’ Summit, there was a +`discussion <https://lwn.net/Articles/870581/>`_ about the challenges in +recruiting kernel maintainers as well as maintainer succession. Some of +the conclusions from that discussion included that companies which are a +part of the Linux Kernel community need to allow engineers to be +maintainers as part of their job, so they can grow into becoming +respected leaders and eventually, kernel maintainers. To support a +strong talent pipeline, developers should be allowed and encouraged to +take on upstream contributions such as reviewing other people’s patches, +refactoring kernel infrastructure, and writing documentation. + +To that end, the Linux Foundation Technical Advisory Board (TAB) +proposes this Linux Kernel Contribution Maturity Model. These common +expectations for upstream community engagement aim to increase the +influence of individual developers, increase the collaboration of +organizations, and improve the overall health of the Linux Kernel +ecosystem. + +The TAB urges organizations to continuously evaluate their Open Source +maturity model and commit to improvements to align with this model. To +be effective, this evaluation should incorporate feedback from across +the organization, including management and developers at all seniority +levels. In the spirit of Open Source, we encourage organizations to +publish their evaluations and plans to improve their engagement with the +upstream community. + +Level 0 +======= + +* Software Engineers are not allowed to contribute patches to the Linux + kernel. + + +Level 1 +======= + +* Software Engineers are allowed to contribute patches to the Linux + kernel, either as part of their job responsibilities or on their own + time. + +Level 2 +======= + +* Software Engineers are expected to contribute to the Linux Kernel as + part of their job responsibilities. +* Software Engineers will be supported to attend Linux-related + conferences as a part of their job. +* A Software Engineer’s upstream code contributions will be considered + in promotion and performance reviews. + +Level 3 +======= + +* Software Engineers are expected to review patches (including patches + authored by engineers from other companies) as part of their job + responsibilities +* Contributing presentations or papers to Linux-related or academic + conferences (such those organized by the Linux Foundation, Usenix, + ACM, etc.), are considered part of an engineer’s work. +* A Software Engineer’s community contributions will be considered in + promotion and performance reviews. +* Organizations will regularly report metrics of their open source + contributions and track these metrics over time. These metrics may be + published only internally within the organization, or at the + organization’s discretion, some or all may be published externally. + Metrics that are strongly suggested include: + + * The number of upstream kernel contributions by team or organization + (e.g., all people reporting up to a manager, director, or VP). + * The percentage of kernel developers who have made upstream + contributions relative to the total kernel developers in the + organization. + * The time interval between kernels used in the organization’s servers + and/or products, and the publication date of the upstream kernel + upon which the internal kernel is based. + * The number of out-of-tree commits present in internal kernels. + +Level 4 +======= + +* Software Engineers are encouraged to spend a portion of their work + time focused on Upstream Work, which is defined as reviewing patches, + serving on program committees, improving core project infrastructure + such as writing or maintaining tests, upstream tech debt reduction, + writing documentation, etc. +* Software Engineers are supported in helping to organize Linux-related + conferences. +* Organizations will consider community member feedback in official + performance reviews. + +Level 5 +======= + +* Upstream kernel development is considered a formal job position, with + at least a third of the engineer’s time spent doing Upstream Work. +* Organizations will actively seek out community member feedback as a + factor in official performance reviews. +* Organizations will regularly report internally on the ratio of + Upstream Work to work focused on directly pursuing business goals. diff --git a/Documentation/process/howto.rst b/Documentation/process/howto.rst index cb6abcb2b6d0..deb8235e20ff 100644 --- a/Documentation/process/howto.rst +++ b/Documentation/process/howto.rst @@ -138,7 +138,7 @@ required reading: philosophy and is very important for people moving to Linux from development on other Operating Systems. - :ref:`Documentation/admin-guide/security-bugs.rst <securitybugs>` + :ref:`Documentation/process/security-bugs.rst <securitybugs>` If you feel you have found a security problem in the Linux kernel, please follow the steps in this document to help notify the kernel developers, and help solve the issue. diff --git a/Documentation/process/index.rst b/Documentation/process/index.rst index d4b6217472b0..b501cd977053 100644 --- a/Documentation/process/index.rst +++ b/Documentation/process/index.rst @@ -35,6 +35,14 @@ Below are the essential guides that every developer should read. kernel-enforcement-statement kernel-driver-statement +For security issues, see: + +.. toctree:: + :maxdepth: 1 + + security-bugs + embargoed-hardware-issues + Other guides to the community that are of interest to most developers are: .. toctree:: @@ -47,9 +55,9 @@ Other guides to the community that are of interest to most developers are: submit-checklist kernel-docs deprecated - embargoed-hardware-issues maintainers researcher-guidelines + contribution-maturity-model These are some overall technical guides that have been put here for now for lack of a better place. diff --git a/Documentation/process/kernel-docs.rst b/Documentation/process/kernel-docs.rst index 1c6e2ab92f4e..46f927aae6eb 100644 --- a/Documentation/process/kernel-docs.rst +++ b/Documentation/process/kernel-docs.rst @@ -75,13 +75,39 @@ On-line docs Published books --------------- + * Title: **Linux Kernel Debugging: Leverage proven tools and advanced techniques to effectively debug Linux kernels and kernel modules** + + :Author: Kaiwan N Billimoria + :Publisher: Packt Publishing Ltd + :Date: August, 2022 + :Pages: 638 + :ISBN: 978-1801075039 + :Notes: Debugging book + * Title: **Linux Kernel Programming: A Comprehensive Guide to Kernel Internals, Writing Kernel Modules, and Kernel Synchronization** - :Author: Kaiwan N. Billimoria - :Publisher: Packt Publishing Ltd - :Date: 2021 - :Pages: 754 - :ISBN: 978-1789953435 + :Author: Kaiwan N Billimoria + :Publisher: Packt Publishing Ltd + :Date: March, 2021 + :Pages: 754 + :ISBN: 978-1789953435 + + * Title: **Linux Kernel Programming Part 2 - Char Device Drivers and Kernel Synchronization: Create user-kernel interfaces, work with peripheral I/O, and handle hardware interrupts** + + :Author: Kaiwan N Billimoria + :Publisher: Packt Publishing Ltd + :Date: March, 2021 + :Pages: 452 + :ISBN: 978-1801079518 + + * Title: **Linux System Programming: Talking Directly to the Kernel and C Library** + + :Author: Robert Love + :Publisher: O'Reilly Media + :Date: June, 2013 + :Pages: 456 + :ISBN: 978-1449339531 + :Notes: Foundational book * Title: **Linux Kernel Development, 3rd Edition** diff --git a/Documentation/process/maintainer-tip.rst b/Documentation/process/maintainer-tip.rst index 572a3289c9cb..178c95fd17dc 100644 --- a/Documentation/process/maintainer-tip.rst +++ b/Documentation/process/maintainer-tip.rst @@ -128,8 +128,8 @@ uppercase letter and should be written in imperative tone. Changelog ^^^^^^^^^ -The general rules about changelogs in the process documentation, see -:ref:`Documentation/process/ <submittingpatches>`, apply. +The general rules about changelogs in the :ref:`Submitting patches guide +<describe_changes>`, apply. The tip tree maintainers set value on following these rules, especially on the request to write changelogs in imperative mood and not impersonating diff --git a/Documentation/process/researcher-guidelines.rst b/Documentation/process/researcher-guidelines.rst index afc944e0e898..9fcfed3c350b 100644 --- a/Documentation/process/researcher-guidelines.rst +++ b/Documentation/process/researcher-guidelines.rst @@ -68,7 +68,7 @@ Before contributing, carefully read the appropriate documentation: * Documentation/process/development-process.rst * Documentation/process/submitting-patches.rst * Documentation/admin-guide/reporting-issues.rst -* Documentation/admin-guide/security-bugs.rst +* Documentation/process/security-bugs.rst Then send a patch (including a commit log with all the details listed below) and follow up on any feedback from other developers. diff --git a/Documentation/admin-guide/security-bugs.rst b/Documentation/process/security-bugs.rst index 82e29837d589..82e29837d589 100644 --- a/Documentation/admin-guide/security-bugs.rst +++ b/Documentation/process/security-bugs.rst diff --git a/Documentation/process/stable-kernel-rules.rst b/Documentation/process/stable-kernel-rules.rst index 2fd8aa593a28..51df1197d5ab 100644 --- a/Documentation/process/stable-kernel-rules.rst +++ b/Documentation/process/stable-kernel-rules.rst @@ -39,7 +39,7 @@ Procedure for submitting patches to the -stable tree Security patches should not be handled (solely) by the -stable review process but should follow the procedures in - :ref:`Documentation/admin-guide/security-bugs.rst <securitybugs>`. + :ref:`Documentation/process/security-bugs.rst <securitybugs>`. For all other submissions, choose one of the following procedures ----------------------------------------------------------------- diff --git a/Documentation/process/submitting-patches.rst b/Documentation/process/submitting-patches.rst index 69ce64e03c70..7a5619fecb38 100644 --- a/Documentation/process/submitting-patches.rst +++ b/Documentation/process/submitting-patches.rst @@ -223,20 +223,17 @@ patch. Select the recipients for your patch ------------------------------------ -You should always copy the appropriate subsystem maintainer(s) on any patch -to code that they maintain; look through the MAINTAINERS file and the -source code revision history to see who those maintainers are. The -script scripts/get_maintainer.pl can be very useful at this step (pass paths to -your patches as arguments to scripts/get_maintainer.pl). If you cannot find a +You should always copy the appropriate subsystem maintainer(s) and list(s) on +any patch to code that they maintain; look through the MAINTAINERS file and the +source code revision history to see who those maintainers are. The script +scripts/get_maintainer.pl can be very useful at this step (pass paths to your +patches as arguments to scripts/get_maintainer.pl). If you cannot find a maintainer for the subsystem you are working on, Andrew Morton (akpm@linux-foundation.org) serves as a maintainer of last resort. -You should also normally choose at least one mailing list to receive a copy -of your patch set. linux-kernel@vger.kernel.org should be used by default -for all patches, but the volume on that list has caused a number of -developers to tune it out. Look in the MAINTAINERS file for a -subsystem-specific list; your patch will probably get more attention there. -Please do not spam unrelated lists, though. +linux-kernel@vger.kernel.org should be used by default for all patches, but the +volume on that list has caused a number of developers to tune it out. Please +do not spam unrelated lists and unrelated people, though. Many kernel-related lists are hosted on vger.kernel.org; you can find a list of them at http://vger.kernel.org/vger-lists.html. There are @@ -254,7 +251,7 @@ If you have a patch that fixes an exploitable security bug, send that patch to security@kernel.org. For severe bugs, a short embargo may be considered to allow distributors to get the patch out to users; in such cases, obviously, the patch should not be sent to any public lists. See also -Documentation/admin-guide/security-bugs.rst. +Documentation/process/security-bugs.rst. Patches that fix a severe bug in a released kernel should be directed toward the stable maintainers by putting a line like this:: diff --git a/Documentation/riscv/vm-layout.rst b/Documentation/riscv/vm-layout.rst index 3be44e74ec5d..5462c84f4723 100644 --- a/Documentation/riscv/vm-layout.rst +++ b/Documentation/riscv/vm-layout.rst @@ -47,7 +47,7 @@ RISC-V Linux Kernel SV39 | Kernel-space virtual memory, shared between all processes: ____________________________________________________________|___________________________________________________________ | | | | - ffffffc6fee00000 | -228 GB | ffffffc6feffffff | 2 MB | fixmap + ffffffc6fea00000 | -228 GB | ffffffc6feffffff | 6 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 @@ -83,7 +83,7 @@ RISC-V Linux Kernel SV48 | Kernel-space virtual memory, shared between all processes: ____________________________________________________________|___________________________________________________________ | | | | - ffff8d7ffee00000 | -114.5 TB | ffff8d7ffeffffff | 2 MB | fixmap + ffff8d7ffea00000 | -114.5 TB | ffff8d7ffeffffff | 6 MB | fixmap ffff8d7fff000000 | -114.5 TB | ffff8d7fffffffff | 16 MB | PCI io ffff8d8000000000 | -114.5 TB | ffff8f7fffffffff | 2 TB | vmemmap ffff8f8000000000 | -112.5 TB | ffffaf7fffffffff | 32 TB | vmalloc/ioremap space @@ -119,7 +119,7 @@ RISC-V Linux Kernel SV57 | Kernel-space virtual memory, shared between all processes: ____________________________________________________________|___________________________________________________________ | | | | - ff1bfffffee00000 | -57 PB | ff1bfffffeffffff | 2 MB | fixmap + ff1bfffffea00000 | -57 PB | ff1bfffffeffffff | 6 MB | fixmap ff1bffffff000000 | -57 PB | ff1bffffffffffff | 16 MB | PCI io ff1c000000000000 | -57 PB | ff1fffffffffffff | 1 PB | vmemmap ff20000000000000 | -56 PB | ff5fffffffffffff | 16 PB | vmalloc/ioremap space diff --git a/Documentation/rust/arch-support.rst b/Documentation/rust/arch-support.rst index ed7f4f5b3cf1..b91e9ef4d0c2 100644 --- a/Documentation/rust/arch-support.rst +++ b/Documentation/rust/arch-support.rst @@ -15,7 +15,7 @@ support corresponds to ``S`` values in the ``MAINTAINERS`` file. ============ ================ ============================================== Architecture Level of support Constraints ============ ================ ============================================== -``x86`` Maintained ``x86_64`` only. ``um`` Maintained ``x86_64`` only. +``x86`` Maintained ``x86_64`` only. ============ ================ ============================================== diff --git a/Documentation/sound/hd-audio/models.rst b/Documentation/sound/hd-audio/models.rst index 9b52f50a6854..120430450014 100644 --- a/Documentation/sound/hd-audio/models.rst +++ b/Documentation/sound/hd-audio/models.rst @@ -704,7 +704,7 @@ ref no-jd BIOS setup but without jack-detection intel - Intel DG45* mobos + Intel D*45* mobos dell-m6-amic Dell desktops/laptops with analog mics dell-m6-dmic diff --git a/Documentation/staging/tee.rst b/Documentation/staging/tee.rst index 498343c7ab08..22baa077a3b9 100644 --- a/Documentation/staging/tee.rst +++ b/Documentation/staging/tee.rst @@ -214,6 +214,57 @@ 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. +OPTEE_INSECURE_LOAD_IMAGE Kconfig option +---------------------------------------- + +The OPTEE_INSECURE_LOAD_IMAGE Kconfig option enables the ability to load the +BL32 OP-TEE image from the kernel after the kernel boots, rather than loading +it from the firmware before the kernel boots. This also requires enabling the +corresponding option in Trusted Firmware for Arm. The Trusted Firmware for Arm +documentation [8] explains the security threat associated with enabling this as +well as mitigations at the firmware and platform level. + +There are additional attack vectors/mitigations for the kernel that should be +addressed when using this option. + +1. Boot chain security. + + * Attack vector: Replace the OP-TEE OS image in the rootfs to gain control of + the system. + + * Mitigation: There must be boot chain security that verifies the kernel and + rootfs, otherwise an attacker can modify the loaded OP-TEE binary by + modifying it in the rootfs. + +2. Alternate boot modes. + + * Attack vector: Using an alternate boot mode (i.e. recovery mode), the + OP-TEE driver isn't loaded, leaving the SMC hole open. + + * Mitigation: If there are alternate methods of booting the device, such as a + recovery mode, it should be ensured that the same mitigations are applied + in that mode. + +3. Attacks prior to SMC invocation. + + * Attack vector: Code that is executed prior to issuing the SMC call to load + OP-TEE can be exploited to then load an alternate OS image. + + * Mitigation: The OP-TEE driver must be loaded before any potential attack + vectors are opened up. This should include mounting of any modifiable + filesystems, opening of network ports or communicating with external + devices (e.g. USB). + +4. Blocking SMC call to load OP-TEE. + + * Attack vector: Prevent the driver from being probed, so the SMC call to + load OP-TEE isn't executed when desired, leaving it open to being executed + later and loading a modified OS. + + * Mitigation: It is recommended to build the OP-TEE driver as builtin driver + rather than as a module to prevent exploits that may cause the module to + not be loaded. + AMD-TEE driver ============== @@ -309,3 +360,5 @@ References [6] include/linux/psp-tee.h [7] drivers/tee/amdtee/amdtee_if.h + +[8] https://trustedfirmware-a.readthedocs.io/en/latest/threat_model/threat_model.html diff --git a/Documentation/trace/ftrace.rst b/Documentation/trace/ftrace.rst index b927fb2b94dc..e8bca5fea7cc 100644 --- a/Documentation/trace/ftrace.rst +++ b/Documentation/trace/ftrace.rst @@ -3510,7 +3510,7 @@ directories, the rmdir will fail with EBUSY. Stack trace ----------- Since the kernel has a fixed sized stack, it is important not to -waste it in functions. A kernel developer must be conscience of +waste it in functions. A kernel developer must be conscious of what they allocate on the stack. If they add too much, the system can be in danger of a stack overflow, and corruption will occur, usually leading to a system panic. diff --git a/Documentation/translations/it_IT/admin-guide/security-bugs.rst b/Documentation/translations/it_IT/admin-guide/security-bugs.rst index 18a5822c7d9a..20994f4bfa31 100644 --- a/Documentation/translations/it_IT/admin-guide/security-bugs.rst +++ b/Documentation/translations/it_IT/admin-guide/security-bugs.rst @@ -1,6 +1,6 @@ .. include:: ../disclaimer-ita.rst -:Original: :ref:`Documentation/admin-guide/security-bugs.rst <securitybugs>` +:Original: :ref:`Documentation/process/security-bugs.rst <securitybugs>` .. _it_securitybugs: diff --git a/Documentation/translations/it_IT/core-api/symbol-namespaces.rst b/Documentation/translations/it_IT/core-api/symbol-namespaces.rst index 0f6898860d6d..17abc25ee4c1 100644 --- a/Documentation/translations/it_IT/core-api/symbol-namespaces.rst +++ b/Documentation/translations/it_IT/core-api/symbol-namespaces.rst @@ -1,7 +1,6 @@ .. include:: ../disclaimer-ita.rst -:Original: :doc:`../../../core-api/symbol-namespaces` -:Translator: Federico Vaga <federico.vaga@vaga.pv.it> +:Original: Documentation/core-api/symbol-namespaces.rst =========================== Spazio dei nomi dei simboli diff --git a/Documentation/translations/it_IT/doc-guide/parse-headers.rst b/Documentation/translations/it_IT/doc-guide/parse-headers.rst index 993d549ee2b8..c7076a21667a 100644 --- a/Documentation/translations/it_IT/doc-guide/parse-headers.rst +++ b/Documentation/translations/it_IT/doc-guide/parse-headers.rst @@ -1,7 +1,6 @@ .. include:: ../disclaimer-ita.rst -.. note:: Per leggere la documentazione originale in inglese: - :ref:`Documentation/doc-guide/index.rst <doc_guide>` +:Original: Documentation/doc-guide/index.rst ========================================= Includere gli i file di intestazione uAPI @@ -190,7 +189,7 @@ COPYRIGHT Copyright (c) 2016 by Mauro Carvalho Chehab <mchehab@s-opensource.com>. -Licenza GPLv2: GNU GPL version 2 <http://gnu.org/licenses/gpl.html>. +Licenza GPLv2: GNU GPL version 2 <https://gnu.org/licenses/gpl.html>. Questo è software libero: siete liberi di cambiarlo e ridistribuirlo. Non c'è alcuna garanzia, nei limiti permessi dalla legge. diff --git a/Documentation/translations/it_IT/index.rst b/Documentation/translations/it_IT/index.rst index fc5f39814e83..b95dfa1ded04 100644 --- a/Documentation/translations/it_IT/index.rst +++ b/Documentation/translations/it_IT/index.rst @@ -2,9 +2,9 @@ .. _it_linux_doc: -=================== -Traduzione italiana -=================== +================================== +La documentazione del kernel Linux +================================== .. raw:: latex @@ -12,6 +12,18 @@ Traduzione italiana :manutentore: Federico Vaga <federico.vaga@vaga.pv.it> +Questo è il livello principale della documentazione del kernel in +lingua italiana. La traduzione è incompleta, noterete degli avvisi +che vi segnaleranno la mancanza di una traduzione o di un gruppo di +traduzioni. + +Più in generale, la documentazione, come il kernel stesso, sono in +costante sviluppo; particolarmente vero in quanto stiamo lavorando +alla riorganizzazione della documentazione in modo più coerente. +I miglioramenti alla documentazione sono sempre i benvenuti; per cui, +se vuoi aiutare, iscriviti alla lista di discussione linux-doc presso +vger.kernel.org. + .. _it_disclaimer: Avvertenze @@ -54,23 +66,8 @@ Se avete bisogno d'aiuto per comunicare con la comunità Linux ma non vi sentite a vostro agio nello scrivere in inglese, potete chiedere aiuto al manutentore della traduzione. -La documentazione del kernel Linux -================================== - -Questo è il livello principale della documentazione del kernel in -lingua italiana. La traduzione è incompleta, noterete degli avvisi -che vi segnaleranno la mancanza di una traduzione o di un gruppo di -traduzioni. - -Più in generale, la documentazione, come il kernel stesso, sono in -costante sviluppo; particolarmente vero in quanto stiamo lavorando -alla riorganizzazione della documentazione in modo più coerente. -I miglioramenti alla documentazione sono sempre i benvenuti; per cui, -se vuoi aiutare, iscriviti alla lista di discussione linux-doc presso -vger.kernel.org. - Lavorare con la comunità di sviluppo ------------------------------------- +==================================== Le guide fondamentali per l'interazione con la comunità di sviluppo del kernel e su come vedere il proprio lavoro integrato. @@ -85,7 +82,7 @@ su come vedere il proprio lavoro integrato. Manuali sull'API interna ------------------------- +======================== Di seguito una serie di manuali per gli sviluppatori che hanno bisogno di interfacciarsi con il resto del kernel. @@ -96,7 +93,7 @@ interfacciarsi con il resto del kernel. core-api/index Strumenti e processi per lo sviluppo ------------------------------------- +==================================== Di seguito una serie di manuali contenenti informazioni utili a tutti gli sviluppatori del kernel. @@ -109,7 +106,7 @@ sviluppatori del kernel. kernel-hacking/index Documentazione per gli utenti ------------------------------ +============================= Di seguito una serie di manuali per gli *utenti* del kernel - ovvero coloro che stanno cercando di farlo funzionare al meglio per un dato sistema, ma anche @@ -120,16 +117,16 @@ Consultate anche `Linux man pages <https://www.kernel.org/doc/man-pages/>`_, che vengono mantenuti separatamente dalla documentazione del kernel Linux Documentazione relativa ai firmware ------------------------------------ +=================================== Di seguito informazioni sulle aspettative del kernel circa i firmware. Documentazione specifica per architettura ------------------------------------------ +========================================= Documentazione varia --------------------- +==================== Ci sono documenti che sono difficili da inserire nell'attuale organizzazione della documentazione; altri hanno bisogno di essere migliorati e/o convertiti diff --git a/Documentation/translations/it_IT/kernel-hacking/locking.rst b/Documentation/translations/it_IT/kernel-hacking/locking.rst index 05d362b16bf0..a9e781d2e323 100644 --- a/Documentation/translations/it_IT/kernel-hacking/locking.rst +++ b/Documentation/translations/it_IT/kernel-hacking/locking.rst @@ -1029,6 +1029,11 @@ Dato che questo è un problema abbastanza comune con una propensione alle corse critiche, dovreste usare timer_delete_sync() (``include/linux/timer.h``) per gestire questo caso. +Prima di rilasciare un temporizzatore dovreste chiamare la funzione +timer_shutdown() o timer_shutdown_sync() di modo che non venga più ricarmato. +Ogni successivo tentativo di riarmare il temporizzatore verrà silenziosamente +ignorato. + Velocità della sincronizzazione =============================== diff --git a/Documentation/translations/it_IT/process/5.Posting.rst b/Documentation/translations/it_IT/process/5.Posting.rst index cf92a16ed7e5..a7e2a3238415 100644 --- a/Documentation/translations/it_IT/process/5.Posting.rst +++ b/Documentation/translations/it_IT/process/5.Posting.rst @@ -265,15 +265,18 @@ Le etichette in uso più comuni sono: :ref:`Documentation/translations/it_IT/process/submitting-patches.rst <it_submittingpatches>` - Reported-by: menziona l'utente che ha riportato il problema corretto da - questa patch; quest'etichetta viene usata per dare credito alle persone - che hanno verificato il codice e ci hanno fatto sapere quando le cose non - funzionavano correttamente. + questa patch; quest'etichetta viene usata per dare credito alle persone che + hanno verificato il codice e ci hanno fatto sapere quando le cose non + funzionavano correttamente. Se esiste un rapporto disponibile sul web, allora + L'etichetta dovrebbe essere seguita da un collegamento al suddetto rapporto. - Cc: la persona menzionata ha ricevuto una copia della patch ed ha avuto l'opportunità di commentarla. -State attenti ad aggiungere queste etichette alla vostra patch: solo -"Cc:" può essere aggiunta senza il permesso esplicito della persona menzionata. +State attenti ad aggiungere queste etichette alla vostra patch: solo "Cc:" può +essere aggiunta senza il permesso esplicito della persona menzionata. Il più +delle volte anche Reported-by: va bene, ma è sempre meglio chiedere specialmente +se il baco è stato riportato in una comunicazione privata. Inviare la modifica ------------------- diff --git a/Documentation/translations/it_IT/process/changes.rst b/Documentation/translations/it_IT/process/changes.rst index 473ec2cc558e..f37c53f8b524 100644 --- a/Documentation/translations/it_IT/process/changes.rst +++ b/Documentation/translations/it_IT/process/changes.rst @@ -36,7 +36,7 @@ GNU C 5.1 gcc --version Clang/LLVM (optional) 11.0.0 clang --version GNU make 3.81 make --version bash 4.2 bash --version -binutils 2.23 ld -v +binutils 2.25 ld -v flex 2.5.35 flex --version bison 2.0 bison --version pahole 1.16 pahole --version @@ -97,7 +97,7 @@ Questo richiede bash 4.2 o successivo. Binutils -------- -Per generare il kernel è necessario avere Binutils 2.23 o superiore. +Per generare il kernel è necessario avere Binutils 2.25 o superiore. pkg-config ---------- diff --git a/Documentation/translations/it_IT/process/clang-format.rst b/Documentation/translations/it_IT/process/clang-format.rst index 77eac809a639..29f83c198025 100644 --- a/Documentation/translations/it_IT/process/clang-format.rst +++ b/Documentation/translations/it_IT/process/clang-format.rst @@ -40,7 +40,7 @@ Linux più popolari. Cercate ``clang-format`` nel vostro repositorio. Altrimenti, potete scaricare una versione pre-generata dei binari di LLVM/clang oppure generarlo dai codici sorgenti: - http://releases.llvm.org/download.html + https://releases.llvm.org/download.html Troverete più informazioni ai seguenti indirizzi: diff --git a/Documentation/translations/it_IT/process/coding-style.rst b/Documentation/translations/it_IT/process/coding-style.rst index a393ee4182af..5f244e16f511 100644 --- a/Documentation/translations/it_IT/process/coding-style.rst +++ b/Documentation/translations/it_IT/process/coding-style.rst @@ -1204,10 +1204,10 @@ ISBN 0-201-61586-X. Manuali GNU - nei casi in cui sono compatibili con K&R e questo documento - per indent, cpp, gcc e i suoi dettagli interni, tutto disponibile qui -http://www.gnu.org/manual/ +https://www.gnu.org/manual/ WG14 è il gruppo internazionale di standardizzazione per il linguaggio C, -URL: http://www.open-std.org/JTC1/SC22/WG14/ +URL: https://www.open-std.org/JTC1/SC22/WG14/ -Kernel process/coding-style.rst, by greg@kroah.com at OLS 2002: +Kernel CodingStyle, by greg@kroah.com at OLS 2002: http://www.kroah.com/linux/talks/ols_2002_kernel_codingstyle_talk/html/ diff --git a/Documentation/translations/it_IT/process/deprecated.rst b/Documentation/translations/it_IT/process/deprecated.rst index febf83897783..57b501f0dfa4 100644 --- a/Documentation/translations/it_IT/process/deprecated.rst +++ b/Documentation/translations/it_IT/process/deprecated.rst @@ -332,7 +332,7 @@ zero come risultato:: Il valore di ``size`` nell'ultima riga sarà ``zero``, quando uno invece si aspetterebbe che il suo valore sia la dimensione totale in -byte dell'allocazione dynamica che abbiamo appena fatto per l'array +byte dell'allocazione dinamica che abbiamo appena fatto per l'array ``items``. Qui un paio di esempi reali del problema: `collegamento 1 <https://git.kernel.org/linus/f2cd32a443da694ac4e28fbf4ac6f9d5cc63a539>`_, `collegamento 2 @@ -381,4 +381,29 @@ combinazione con struct_size() e flex_array_size():: instance = kmalloc(struct_size(instance, items, count), GFP_KERNEL); instance->count = count; - memcpy(instance->items, source, flex_array_size(instance, items, instance->count)); + memcpy(instance->items, source, flex_array_size(instance, items, instance->count)); + +Ci sono due casi speciali dove è necessario usare la macro DECLARE_FLEX_ARRAY() +(da notare che la stessa macro è chiamata __DECLARE_FLEX_ARRAY() nei file di +intestazione UAPI). Uno è quando l'array flessibile è l'unico elemento di una +struttura, e l'altro è quando è parti un unione. Per motivi non tecnici, entrambi +i casi d'uso non sono permessi dalla specifica C99. Per esempio, per +convertire il seguente codice:: + + struct something { + ... + union { + struct type1 one[0]; + struct type2 two[0]; + }; + }; + +La macro di supporto dev'essere usata:: + + struct something { + ... + union { + DECLARE_FLEX_ARRAY(struct type1, one); + DECLARE_FLEX_ARRAY(struct type2, two); + }; + }; diff --git a/Documentation/translations/it_IT/process/email-clients.rst b/Documentation/translations/it_IT/process/email-clients.rst index 970671cd91af..76ca3226c8cd 100644 --- a/Documentation/translations/it_IT/process/email-clients.rst +++ b/Documentation/translations/it_IT/process/email-clients.rst @@ -364,3 +364,28 @@ un editor esterno. Un altro problema è che Gmail usa la codifica base64 per tutti quei messaggi che contengono caratteri non ASCII. Questo include cose tipo i nomi europei. + +Proton Mail +*********** + +Il servizio Proton Mail ha una funzionalità che cripta tutti i messaggi verso +ogni destinatario per cui è possibile trovare una chiave usando il *Web Key +Directory* (WKD). Il servizio kernel.org pubblica il WKD per ogni sviluppatore +in possesso di un conto kernel.org. Di conseguenza, tutti i messaggi inviati +usando Proton Mail verso indirizzi kernel.org verranno criptati. + +Proton Mail non fornisce alcun meccanismo per disabilitare questa funzionalità +perché verrebbe considerato un problema per la riservatezza. Questa funzionalità +è attiva anche quando si inviano messaggi usando il Proton Mail Bridge. Dunque +tutta la posta in uscita verrà criptata, incluse le patch inviate con ``git +send-email``. + +I messaggi criptati sono una fonte di problemi; altri sviluppatori potrebbero +non aver configurato i loro programmi, o strumenti, per gestire messaggi +criptati; inoltre, alcuni programmi di posta elettronica potrebbero criptare le +risposte a messaggi criptati per tutti i partecipanti alla discussione, inclusa +la lista di discussione stessa. + +A meno che non venga introdotta una maniera per disabilitare questa +funzionalità , non è consigliato usare Proton Mail per contribuire allo sviluppo +del kernel. diff --git a/Documentation/translations/it_IT/process/index.rst b/Documentation/translations/it_IT/process/index.rst index 25602c1a97d1..cd7977905fb8 100644 --- a/Documentation/translations/it_IT/process/index.rst +++ b/Documentation/translations/it_IT/process/index.rst @@ -10,6 +10,7 @@ .. _it_process_index: +=============================================== Lavorare con la comunità di sviluppo del kernel =============================================== diff --git a/Documentation/translations/it_IT/process/maintainer-pgp-guide.rst b/Documentation/translations/it_IT/process/maintainer-pgp-guide.rst index 5526bcabeb0a..cdc43c4a9b0b 100644 --- a/Documentation/translations/it_IT/process/maintainer-pgp-guide.rst +++ b/Documentation/translations/it_IT/process/maintainer-pgp-guide.rst @@ -68,42 +68,24 @@ stesso. Strumenti PGP ============= -Usare GnuPG v2 --------------- +Usare GnuPG 2.2 o successivo +---------------------------- La vostra distribuzione potrebbe avere già installato GnuPG, dovete solo -verificare che stia utilizzando la versione 2.x e non la serie 1.4 -- -molte distribuzioni forniscono entrambe, di base il comando ''gpg'' -invoca GnuPG v.1. Per controllate usate:: +verificare che stia utilizzando la versione abbastanza recente. Per controllate +usate:: $ gpg --version | head -n1 -Se visualizzate ``gpg (GnuPG) 1.4.x``, allora state usando GnuPG v.1. -Provate il comando ``gpg2`` (se non lo avete, potreste aver bisogno -di installare il pacchetto gnupg2):: - - $ gpg2 --version | head -n1 - -Se visualizzate ``gpg (GnuPG) 2.x.x``, allora siete pronti a partire. -Questa guida assume che abbiate la versione 2.2.(o successiva) di GnuPG. -Se state usando la versione 2.0, alcuni dei comandi indicati qui non -funzioneranno, in questo caso considerate un aggiornamento all'ultima versione, -la 2.2. Versioni di gnupg-2.1.11 e successive dovrebbero essere compatibili -per gli obiettivi di questa guida. - -Se avete entrambi i comandi: ``gpg`` e ``gpg2``, assicuratevi di utilizzare -sempre la versione V2, e non quella vecchia. Per evitare errori potreste creare -un alias:: - - $ alias gpg=gpg2 - -Potete mettere questa opzione nel vostro ``.bashrc`` in modo da essere sicuri. +Se state utilizzando la version 2.2 o successiva, allora siete pronti a partire. +Se invece state usando una versione precedente, allora alcuni comandi elencati +in questa guida potrebbero non funzionare. Configurare le opzioni di gpg-agent ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ L'agente GnuPG è uno strumento di aiuto che partirà automaticamente ogni volta -che userete il comando ``gpg`` e funzionerà in background con l'obiettivo di +che userete il comando ``gpg`` e funzionerà in *background* con l'obiettivo di individuare la passphrase. Ci sono due opzioni che dovreste conoscere per personalizzare la scadenza della passphrase nella cache: @@ -131,19 +113,7 @@ valori:: riguarda vecchie le versioni di GnuPG, poiché potrebbero non svolgere più bene il loro compito. -Impostare un *refresh* con cronjob -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -Potreste aver bisogno di rinfrescare regolarmente il vostro portachiavi in -modo aggiornare le chiavi pubbliche di altre persone, lavoro che è svolto -al meglio con un cronjob giornaliero:: - - @daily /usr/bin/gpg2 --refresh >/dev/null 2>&1 - -Controllate il percorso assoluto del vostro comando ``gpg`` o ``gpg2`` e usate -il comando ``gpg2`` se per voi ``gpg`` corrisponde alla versione GnuPG v.1. - -.. _it_master_key: +.. _it_protect_your_key: Proteggere la vostra chiave PGP primaria ======================================== @@ -155,55 +125,62 @@ al documento "`Protecting Code Integrity`_" che abbiamo menzionato prima. Dovreste inoltre creare una nuova chiave se quella attuale è inferiore a 2048 bit (RSA). -Chiave principale o sottochiavi -------------------------------- - -Le sottochiavi sono chiavi PGP totalmente indipendenti, e sono collegate alla -chiave principale attraverso firme certificate. È quindi importante -comprendere i seguenti punti: - -1. Non ci sono differenze tecniche tra la chiave principale e la sottochiave. -2. In fase di creazione, assegniamo limitazioni funzionali ad ogni chiave - assegnando capacità specifiche. -3. Una chiave PGP può avere 4 capacità : +Le sottochiavi PGP +------------------ - - **[S]** può essere usata per firmare - - **[E]** può essere usata per criptare - - **[A]** può essere usata per autenticare - - **[C]** può essere usata per certificare altre chiavi +Raramente le chiavi PGP sono composte da una singola coppia -- solitamente, sono +una collezione di sottochiavi indipendenti usate per diversi scopi in funzione +delle capacità assegnate al momento della creazione. Una chiave PGP può avere +quattro capacità : + +- **[S]** può essere usata per firmare +- **[E]** può essere usata per criptare +- **[A]** può essere usata per autenticare +- **[C]** può essere usata per certificare altre chiavi + +La chiave con la capacità **[C]** viene spesso chiamata chiave "passepartout" +(*master key*), ma è una terminologia fuorviante perché lascia intendere che la +chiave di certificato possa essere usate in sostituzione delle altre (proprio +come le vere chiavi passpartout in grado di aprire diverse serrature). Dato che +questo non è il caso, per evitare fraintendimenti, in questa guida ci riferiremo +a questa chiave chiamandola "La chiave di certificazione". + +I seguenti punti sono molto importanti: + +1. Tutte le sottochiavi sono indipendenti. Se perdete una sottochiave privata + non potrete recuperarla usando le altre. +2. Ad eccezione della chiave di certificazione, ci possono essere più + sottochiavi con le stesse capacità (per esempio, potete avere 2 sottochiavi + per criptare, 3 per firmare, ma solo una per una sola per certificare). Tutte + le sottochiavi sono indipendenti -- un messaggio criptato usando una chiave + **[E]** non può essere decriptato usano altre sottochiavi **[E]**. +3. Una sottochiave può avere più capacità (per esempio, la chiave **[C]** può + anche essere una chiave **[S]**). + +La chiave con capacità **[C]** (certificazione) è la sola che può essere usata +per indicare relazioni fra chiavi. Solo la chiave **[C]** può essere usata per: + +- aggiungere o revocare altre chiavi (sottochiavi) che hanno capacità S/E/A; +- aggiungere, modificare o eliminare le identità (unids) associate alla chiave; +- aggiungere o modificare la propria data di scadenza o delle sottochiavi; +- firmare le chiavi di altre persone a scopo di creare una rete di fiducia. -4. Una singola chiave può avere più capacità -5. Una sottochiave è completamente indipendente dalla chiave principale. - Un messaggio criptato con la sottochiave non può essere decrittato con - quella principale. Se perdete la vostra sottochiave privata, non può - essere rigenerata in nessun modo da quella principale. +Di base, alla creazione di nuove chiavi, GnuPG genera quanto segue: -La chiave con capacità **[C]** (certify) è identificata come la chiave -principale perché è l'unica che può essere usata per indicare la relazione -con altre chiavi. Solo la chiave **[C]** può essere usata per: +- Una chiave la capacità di certificazione che quella di firma (**[SC]**) +- Una sottochiave separata con capacità di criptare (**[E]**) -- Aggiungere o revocare altre chiavi (sottochiavi) che hanno capacità S/E/A -- Aggiungere, modificare o eliminare le identità (unids) associate alla chiave -- Aggiungere o modificare la data di termine di sé stessa o di ogni sottochiave -- Firmare le chiavi di altre persone a scopo di creare una rete di fiducia -Di base, alla creazione di nuove chiavi, GnuPG genera quanto segue: -- Una chiave madre che porta sia la capacità di certificazione che quella - di firma (**[SC]**) -- Una sottochiave separata con capacità di criptaggio (**[E]**) -Se avete usato i parametri di base per generare la vostra chiave, quello +Se avete usato i parametri predefiniti per generare la vostra chiave, quello sarà il risultato. Potete verificarlo utilizzando ``gpg --list-secret-keys``, per esempio:: - sec rsa2048 2018-01-23 [SC] [expires: 2020-01-23] + sec ed25519 2022-12-20 [SC] [expires: 2024-12-19] 000000000000000000000000AAAABBBBCCCCDDDD uid [ultimate] Alice Dev <adev@kernel.org> - ssb rsa2048 2018-01-23 [E] [expires: 2020-01-23] - -Qualsiasi chiave che abbia la capacità **[C]** è la vostra chiave madre, -indipendentemente da quali altre capacità potreste averle assegnato. + ssb cv25519 2022-12-20 [E] [expires: 2024-12-19] La lunga riga sotto la voce ``sec`` è la vostra impronta digitale -- negli esempi che seguono, quando vedere ``[fpr]`` ci si riferisce a questa @@ -238,20 +215,10 @@ possano ricevere la vostra nuova sottochiave:: $ gpg --send-key [fpr] .. note:: Supporto ECC in GnuPG - GnuPG 2.1 e successivi supportano pienamente *Elliptic Curve Cryptography*, - con la possibilità di combinare sottochiavi ECC con le tradizionali chiavi - primarie RSA. Il principale vantaggio della crittografia ECC è che è molto - più veloce da calcolare e crea firme più piccole se confrontate byte per - byte con le chiavi RSA a più di 2048 bit. A meno che non pensiate di - utilizzare un dispositivo smartcard che non supporta le operazioni ECC, vi - raccomandiamo ti creare sottochiavi di firma ECC per il vostro lavoro col - kernel. - - Se per qualche ragione preferite rimanere con sottochiavi RSA, nel comando - precedente, sostituite "ed25519" con "rsa2048". In aggiunta, se avete - intenzione di usare un dispositivo hardware che non supporta le chiavi - ED25519 ECC, come la Nitrokey Pro o la Yubikey, allora dovreste usare - "nistp256" al posto di "ed25519". + + Tenete presente che se avete intenzione di usare un dispositivo che non + supporta chiavi ED25519 ECC, allora dovreste usare "nistp256" al posto di + "ed25519". Più avanti ci sono alcune raccomandazioni per i dispositivi. Copia di riserva della chiave primaria per gestire il recupero da disastro -------------------------------------------------------------------------- @@ -360,13 +327,13 @@ Per prima cosa, identificate il keygrip della vostra chiave primaria:: L'output assomiglierà a questo:: - pub rsa2048 2018-01-24 [SC] [expires: 2020-01-24] + pub ed25519 2022-12-20 [SC] [expires: 2022-12-19] 000000000000000000000000AAAABBBBCCCCDDDD Keygrip = 1111000000000000000000000000000000000000 uid [ultimate] Alice Dev <adev@kernel.org> - sub rsa2048 2018-01-24 [E] [expires: 2020-01-24] + sub cv25519 2022-12-20 [E] [expires: 2022-12-19] Keygrip = 2222000000000000000000000000000000000000 - sub ed25519 2018-01-24 [S] + sub ed25519 2022-12-20 [S] Keygrip = 3333000000000000000000000000000000000000 Trovate la voce keygrid che si trova sotto alla riga ``pub`` (appena sotto @@ -389,11 +356,11 @@ Ora, se eseguite il comando ``--list-secret-keys``, vedrete che la chiave primaria non compare più (il simbolo ``#`` indica che non è disponibile):: $ gpg --list-secret-keys - sec# rsa2048 2018-01-24 [SC] [expires: 2020-01-24] + sec# ed25519 2022-12-20 [SC] [expires: 2024-12-19] 000000000000000000000000AAAABBBBCCCCDDDD uid [ultimate] Alice Dev <adev@kernel.org> - ssb rsa2048 2018-01-24 [E] [expires: 2020-01-24] - ssb ed25519 2018-01-24 [S] + ssb cv25519 2022-12-20 [E] [expires: 2024-12-19] + ssb ed25519 2022-12-20 [S] Dovreste rimuovere anche i file ``secring.gpg`` che si trovano nella cartella ``~/.gnupg``, in quanto rimasugli delle versioni precedenti di GnuPG. @@ -461,18 +428,20 @@ soluzioni disponibili: computer portatili più recenti. In aggiunta, offre altre funzionalità di sicurezza come FIDO, U2F, e ora supporta anche le chiavi ECC (NISTP) -`Su LWN c'è una buona recensione`_ dei modelli elencati qui sopra e altri. -La scelta dipenderà dal costo, dalla disponibilità nella vostra area -geografica e vostre considerazioni sull'hardware aperto/proprietario. +La vostra scelta dipenderà dal costo, la disponibilità nella vostra regione, e +sulla scelta fra dispositivi aperti e proprietari. -Se volete usare chiavi ECC, la vostra migliore scelta sul mercato è la -Nitrokey Start. +.. note:: + + Se siete nella lista MAINTAINERS o avete un profilo su kernel.org, allora + `potrete avere gratuitamente una Nitrokey Start`_ grazie alla fondazione + Linux. .. _`Nitrokey Start`: https://shop.nitrokey.com/shop/product/nitrokey-start-6 .. _`Nitrokey Pro 2`: https://shop.nitrokey.com/shop/product/nitrokey-pro-2-3 .. _`Yubikey 5`: https://www.yubico.com/product/yubikey-5-overview/ -.. _Gnuk: http://www.fsij.org/doc-gnuk/ -.. _`Su LWN c'è una buona recensione`: https://lwn.net/Articles/736231/ +.. _Gnuk: https://www.fsij.org/doc-gnuk/ +.. _`potrete avere gratuitamente una Nitrokey Start`: https://www.kernel.org/nitrokey-digital-tokens-for-kernel-developers.html Configurare il vostro dispositivo smartcard ------------------------------------------- @@ -513,6 +482,12 @@ altre informazioni sulla carta che potrebbero trapelare in caso di smarrimento. A dispetto del nome "PIN", né il PIN utente né quello dell'amministratore devono essere esclusivamente numerici. +.. warning:: + + Alcuni dispositivi richiedono la presenza delle sottochiavi nel dispositivo + stesso prima che possiate cambiare la passphare. Verificate la + documentazione del produttore. + Spostare le sottochiavi sulla smartcard --------------------------------------- @@ -525,11 +500,11 @@ dell'amministratore:: Secret subkeys are available. - pub rsa2048/AAAABBBBCCCCDDDD - created: 2018-01-23 expires: 2020-01-23 usage: SC + pub ed25519/AAAABBBBCCCCDDDD + created: 2022-12-20 expires: 2024-12-19 usage: SC trust: ultimate validity: ultimate - ssb rsa2048/1111222233334444 - created: 2018-01-23 expires: never usage: E + ssb cv25519/1111222233334444 + created: 2022-12-20 expires: never usage: E ssb ed25519/5555666677778888 created: 2017-12-07 expires: never usage: S [ultimate] (1). Alice Dev <adev@kernel.org> @@ -594,11 +569,11 @@ Ora, se doveste usare l'opzione ``--list-secret-keys``, vedrete una sottile differenza nell'output:: $ gpg --list-secret-keys - sec# rsa2048 2018-01-24 [SC] [expires: 2020-01-24] + sec# ed25519 2022-12-20 [SC] [expires: 2024-12-19] 000000000000000000000000AAAABBBBCCCCDDDD uid [ultimate] Alice Dev <adev@kernel.org> - ssb> rsa2048 2018-01-24 [E] [expires: 2020-01-24] - ssb> ed25519 2018-01-24 [S] + ssb> cv25519 2022-12-20 [E] [expires: 2024-12-19] + ssb> ed25519 2022-12-20 [S] Il simbolo ``>`` in ``ssb>`` indica che la sottochiave è disponibile solo nella smartcard. Se tornate nella vostra cartella delle chiavi segrete e @@ -661,7 +636,7 @@ eseguite:: Se per voi è più facile da memorizzare, potete anche utilizzare una data specifica (per esempio, il vostro compleanno o capodanno):: - $ gpg --quick-set-expire [fpr] 2020-07-01 + $ gpg --quick-set-expire [fpr] 2025-07-01 Ricordatevi di inviare l'aggiornamento ai keyserver:: @@ -676,6 +651,21 @@ dovreste importarle nella vostra cartella di lavoro abituale:: $ gpg --export | gpg --homedir ~/.gnupg --import $ unset GNUPGHOME +Usare gpg-agent con ssh +~~~~~~~~~~~~~~~~~~~~~~~ + +Se dovete firmare tag o commit su un sistema remoto, potete ridirezionare il +vostro gpg-agent attraverso ssh. Consultate le istruzioni disponibili nella wiki +GnuPG: + +- `Agent Forwarding over SSH`_ + +Funziona senza troppi intoppi se avete la possibilità di modificare le +impostazioni di sshd sul sistema remoto. + +.. _`Agent Forwarding over SSH`: https://wiki.gnupg.org/AgentForwarding + +.. _it_pgp_with_git: Usare PGP con Git ================= @@ -709,11 +699,6 @@ avere più chiavi segrete, potete dire a git quale dovrebbe usare (``[fpg]`` $ git config --global user.signingKey [fpr] -**IMPORTANTE**: se avete una comando dedicato per ``gpg2``, allora dovreste -dire a git di usare sempre quello piuttosto che il vecchio comando ``gpg``:: - - $ git config --global gpg.program gpg2 - Come firmare i tag ------------------ @@ -812,6 +797,61 @@ Potete dire a git di firmare sempre i commit:: .. _it_verify_identities: +Come lavorare con patch firmate +------------------------------- + +Esiste la possibilità di usare la vostra chiave PGP per firmare le patch che +invierete alla liste di discussione del kernel. I meccanismi esistenti per la +firma delle email (PGP-Mime o PGP-inline) tendono a causare problemi +nell'attività di revisione del codice. Si suggerisce, invece, di utilizare lo +strumento sviluppato da kernel.org che mette nell'intestazione del messaggio +un'attestazione delle firme crittografiche (tipo DKIM): + +- `Patatt Patch Attestation`_ + +.. _`Patatt Patch Attestation`: https://pypi.org/project/patatt/ + +Installare e configurate patatt +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +Lo strumento patatt è disponibile per diverse distribuzioni, dunque cercatelo +prima lì. Oppure potete installarlo usano pypi "``pip install patatt``" + +Se avete già configurato git con la vostra chiave PGP (usando +``user.signingKey``), allora patatt non ha bisogno di alcuna configurazione +aggiuntiva. Potete iniziare a firmare le vostre patch aggiungendo un aggancio a +git-send-email nel vostro repositorio:: + + patatt install-hook + +Ora, qualsiasi patch che invierete con ``git send-email`` verrà automaticamente +firmata usando la vostra firma crittografica. + +Verificare le firme di patatt +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +Se usate ``b4`` per verificare ed applicare le patch, allora tenterà +automaticamente di verificare tutte le firme DKIM e patatt disponibili. Per +esempio:: + + $ b4 am 20220720205013.890942-1-broonie@kernel.org + [...] + Checking attestation on all messages, may take a moment... + --- + ✓ [PATCH v1 1/3] kselftest/arm64: Correct buffer allocation for SVE Z registers + ✓ [PATCH v1 2/3] arm64/sve: Document our actual ABI for clearing registers on syscall + ✓ [PATCH v1 3/3] kselftest/arm64: Enforce actual ABI for SVE syscalls + --- + ✓ Signed: openpgp/broonie@kernel.org + ✓ Signed: DKIM/kernel.org + +.. note:: + + Lo sviluppo di patatt e b4 è piuttosto attivo. Si consiglia di verificare la + documentazione più recente. + +.. _it_kernel_identities: + Come verificare l'identità degli sviluppatori del kernel ======================================================== @@ -884,64 +924,18 @@ di base di GnuPG v2). Per farlo, aggiungete (o modificate) l'impostazione trust-model tofu+pgp -Come usare i keyserver in sicurezza ------------------------------------ -Se ottenete l'errore "No public key" quando cercate di validate il tag di -qualcuno, allora dovreste cercare quella chiave usando un keyserver. È -importante tenere bene a mente che non c'è alcuna garanzia che la chiave -che avete recuperato da un keyserver PGP appartenga davvero alla persona -reale -- è progettato così. Dovreste usare il Web of Trust per assicurarvi -che la chiave sia valida. - -Come mantenere il Web of Trust va oltre gli scopi di questo documento, -semplicemente perché farlo come si deve richiede sia sforzi che perseveranza -che tendono ad andare oltre al livello di interesse della maggior parte degli -esseri umani. Qui di seguito alcuni rapidi suggerimenti per aiutarvi a ridurre -il rischio di importare chiavi maligne. - -Primo, diciamo che avete provato ad eseguire ``git verify-tag`` ma restituisce -un errore dicendo che la chiave non è stata trovata:: - - $ git verify-tag sunxi-fixes-for-4.15-2 - gpg: Signature made Sun 07 Jan 2018 10:51:55 PM EST - gpg: using RSA key DA73759BF8619E484E5A3B47389A54219C0F2430 - gpg: issuer "wens@...org" - gpg: Can't check signature: No public key - -Cerchiamo nel keyserver per maggiori informazioni sull'impronta digitale -della chiave (l'impronta digitale, probabilmente, appartiene ad una -sottochiave, dunque non possiamo usarla direttamente senza trovare prima -l'ID della chiave primaria associata ad essa):: - - $ gpg --search DA73759BF8619E484E5A3B47389A54219C0F2430 - gpg: data source: hkp://keys.gnupg.net - (1) Chen-Yu Tsai <wens@...org> - 4096 bit RSA key C94035C21B4F2AEB, created: 2017-03-14, expires: 2019-03-15 - Keys 1-1 of 1 for "DA73759BF8619E484E5A3B47389A54219C0F2430". Enter number(s), N)ext, or Q)uit > q - -Localizzate l'ID della chiave primaria, nel nostro esempio -``C94035C21B4F2AEB``. Ora visualizzate le chiavi di Linus Torvalds -che avete nel vostro portachiavi:: - - $ gpg --list-key torvalds@kernel.org - pub rsa2048 2011-09-20 [SC] - ABAF11C65A2970B130ABE3C479BE3E4300411886 - uid [ unknown] Linus Torvalds <torvalds@kernel.org> - sub rsa2048 2011-09-20 [E] - -Poi, cercate un percorso affidabile da Linux Torvalds alla chiave che avete -trovato con ``gpg --search`` usando la chiave sconosciuta.Per farlo potete usare -diversi strumenti come https://github.com/mricon/wotmate, -https://git.kernel.org/pub/scm/docs/kernel/pgpkeys.git/tree/graphs, e -https://the.earth.li/~noodles/pathfind.html. - -Se trovate un paio di percorsi affidabili è un buon segno circa la validità -della chiave. Ora, potete aggiungerla al vostro portachiavi dal keyserver:: - - $ gpg --recv-key C94035C21B4F2AEB - -Questa procedura non è perfetta, e ovviamente state riponendo la vostra -fiducia nell'amministratore del servizio *PGP Pathfinder* sperando che non -sia malintenzionato (infatti, questo va contro :ref:`it_devs_not_infra`). -Tuttavia, se mantenete con cura la vostra rete di fiducia sarà un deciso -miglioramento rispetto alla cieca fiducia nei keyserver. +Usare il repositorio kernel.org per il web of trust +--------------------------------------------------- + +Il progetto kernel.org mantiene un repositorio git con le chiavi pubbliche degli sviluppatori in alternativa alla replica dei server di chiavi che negli ultimi anni sono spariti. La documentazione completa su come impostare il repositorio come vostra sorgente di chiavi pubbliche può essere trovato qui: + +- `Kernel developer PGP Keyring`_ + +Se siete uno sviluppatore del kernel, per favore valutate l'idea di inviare la +vostra chiave per l'inclusione in quel portachiavi. + + +If you are a kernel developer, please consider submitting your key for +inclusion into that keyring. + +.. _`Kernel developer PGP Keyring`: https://korg.docs.kernel.org/pgpkeys.html diff --git a/Documentation/translations/it_IT/process/programming-language.rst b/Documentation/translations/it_IT/process/programming-language.rst index c1a9b481a6f9..5bc5b9d42f31 100644 --- a/Documentation/translations/it_IT/process/programming-language.rst +++ b/Documentation/translations/it_IT/process/programming-language.rst @@ -18,10 +18,6 @@ Linux supporta anche ``clang`` [it-clang]_, leggete la documentazione Questo dialetto contiene diverse estensioni al linguaggio [it-gnu-extensions]_, e molte di queste vengono usate sistematicamente dal kernel. -Il kernel offre un certo livello di supporto per la compilazione con -``icc`` [it-icc]_ su diverse architetture, tuttavia in questo momento -il supporto non è completo e richiede delle patch aggiuntive. - Attributi --------- @@ -43,11 +39,30 @@ possono usare e/o per accorciare il codice. Per maggiori informazioni consultate il file d'intestazione ``include/linux/compiler_attributes.h``. +Rust +---- + +Il kernel supporta sperimentalmente il linguaggio di programmazione Rust +[it-rust-language]_ abilitando l'opzione di configurazione ``CONFIG_RUST``. Il +codice verrà compilato usando ``rustc`` [it-rustc]_ con l'opzione +``--edition=2021`` [it-rust-editions]_. Le edizioni Rust sono un modo per +introdurre piccole modifiche senza compatibilità all'indietro._ + +In aggiunta, nel kernel vengono utilizzate alcune funzionalità considerate +instabili [it-rust-unstable-features]_. Queste funzionalità potrebbero cambiare +in futuro, dunque è un'obiettivo importante è quello di far uso solo di +funzionalità stabili. + +Per maggiori informazioni fate riferimento a Documentation/rust/index.rst . + .. [it-c-language] http://www.open-std.org/jtc1/sc22/wg14/www/standards .. [it-gcc] https://gcc.gnu.org .. [it-clang] https://clang.llvm.org -.. [it-icc] https://software.intel.com/en-us/c-compilers .. [it-gcc-c-dialect-options] https://gcc.gnu.org/onlinedocs/gcc/C-Dialect-Options.html .. [it-gnu-extensions] https://gcc.gnu.org/onlinedocs/gcc/C-Extensions.html .. [it-gcc-attribute-syntax] https://gcc.gnu.org/onlinedocs/gcc/Attribute-Syntax.html .. [it-n2049] http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2049.pdf +.. [it-rust-language] https://www.rust-lang.org +.. [it-rustc] https://doc.rust-lang.org/rustc/ +.. [it-rust-editions] https://doc.rust-lang.org/edition-guide/editions/ +.. [it-rust-unstable-features] https://github.com/Rust-for-Linux/linux/issues/2 diff --git a/Documentation/translations/it_IT/process/stable-kernel-rules.rst b/Documentation/translations/it_IT/process/stable-kernel-rules.rst index 0be675b03199..248bf1e4b171 100644 --- a/Documentation/translations/it_IT/process/stable-kernel-rules.rst +++ b/Documentation/translations/it_IT/process/stable-kernel-rules.rst @@ -106,6 +106,12 @@ al messaggio della patch, così: commit <sha1> upstream. +o in alternativa: + +.. code-block:: none + + [ Upstream commit <sha1> ] + In aggiunta, alcune patch inviate attraverso l':ref:`it_option_1` potrebbero dipendere da altre che devo essere incluse. Questa situazione può essere indicata nel seguente modo nell'area dedicata alle firme: diff --git a/Documentation/translations/it_IT/process/submitting-patches.rst b/Documentation/translations/it_IT/process/submitting-patches.rst index c2cfa0948b2b..447b18792e61 100644 --- a/Documentation/translations/it_IT/process/submitting-patches.rst +++ b/Documentation/translations/it_IT/process/submitting-patches.rst @@ -272,7 +272,7 @@ embargo potrebbe essere preso in considerazione per dare il tempo alle distribuzioni di prendere la patch e renderla disponibile ai loro utenti; in questo caso, ovviamente, la patch non dovrebbe essere inviata su alcuna lista di discussione pubblica. Leggete anche -Documentation/admin-guide/security-bugs.rst. +Documentation/process/security-bugs.rst. Patch che correggono bachi importanti su un kernel già rilasciato, dovrebbero essere inviate ai manutentori dei kernel stabili aggiungendo la seguente riga:: @@ -429,7 +429,7 @@ poi dovete solo aggiungere una riga che dice:: Signed-off-by: Random J Developer <random@developer.example.org> -usando il vostro vero nome (spiacenti, non si accettano pseudonimi o +usando il vostro vero nome (spiacenti, non si accettano contributi anonimi). Questo verrà fatto automaticamente se usate ``git commit -s``. Anche il ripristino di uno stato precedente dovrebbe includere "Signed-off-by", se usate ``git revert -s`` questo verrà @@ -785,7 +785,7 @@ Riferimenti ----------- Andrew Morton, "La patch perfetta" (tpp). - <http://www.ozlabs.org/~akpm/stuff/tpp.txt> + <https://www.ozlabs.org/~akpm/stuff/tpp.txt> Jeff Garzik, "Formato per la sottomissione di patch per il kernel Linux" <https://web.archive.org/web/20180829112450/http://linux.yyz.us/patch-format.html> diff --git a/Documentation/translations/it_IT/process/volatile-considered-harmful.rst b/Documentation/translations/it_IT/process/volatile-considered-harmful.rst index efc640cac596..4fff9a59b548 100644 --- a/Documentation/translations/it_IT/process/volatile-considered-harmful.rst +++ b/Documentation/translations/it_IT/process/volatile-considered-harmful.rst @@ -119,9 +119,9 @@ concorrenza siano stati opportunamente considerati. Riferimenti =========== -[1] http://lwn.net/Articles/233481/ +[1] https://lwn.net/Articles/233481/ -[2] http://lwn.net/Articles/233482/ +[2] https://lwn.net/Articles/233482/ Crediti ======= diff --git a/Documentation/translations/ja_JP/howto.rst b/Documentation/translations/ja_JP/howto.rst index 9b0b3436dfcf..8d856ebe873c 100644 --- a/Documentation/translations/ja_JP/howto.rst +++ b/Documentation/translations/ja_JP/howto.rst @@ -167,7 +167,7 @@ linux-api@vger.kernel.org ã«é€ã‚‹ã“ã¨ã‚’勧ã‚ã¾ã™ã€‚ ã“ã®ãƒ‰ã‚ュメント㯠Linux 開発ã®æ€æƒ³ã‚’ç†è§£ã™ã‚‹ã®ã«éžå¸¸ã«é‡è¦ã§ã™ã€‚ ãã—ã¦ã€ä»–ã®OSã§ã®é–‹ç™ºè€…㌠Linux ã«ç§»ã‚‹æ™‚ã«ã¨ã¦ã‚‚é‡è¦ã§ã™ã€‚ - :ref:`Documentation/admin-guide/security-bugs.rst <securitybugs>` + :ref:`Documentation/process/security-bugs.rst <securitybugs>` ã‚‚ã— Linux カーãƒãƒ«ã§ã‚»ã‚ュリティå•é¡Œã‚’発見ã—ãŸã‚ˆã†ã«æ€ã£ãŸã‚‰ã€ã“ ã®ãƒ‰ã‚ュメントã®ã‚¹ãƒ†ãƒƒãƒ—ã«å¾“ã£ã¦ã‚«ãƒ¼ãƒãƒ«é–‹ç™ºè€…ã«é€£çµ¡ã—ã€å•é¡Œè§£æ±ºã‚’ 支æ´ã—ã¦ãã ã•ã„。 diff --git a/Documentation/translations/ko_KR/howto.rst b/Documentation/translations/ko_KR/howto.rst index 969e91a95bb0..34f14899c155 100644 --- a/Documentation/translations/ko_KR/howto.rst +++ b/Documentation/translations/ko_KR/howto.rst @@ -157,7 +157,7 @@ mtk.manpages@gmail.comì˜ ë©”ì¸í…Œì´ë„ˆì—게 보낼 ê²ƒì„ ê¶Œìž¥í•œë‹¤. 리눅스로 ì „í–¥í•˜ëŠ” 사람들ì—게는 매우 중요하다. - :ref:`Documentation/admin-guide/security-bugs.rst <securitybugs>` + :ref:`Documentation/process/security-bugs.rst <securitybugs>` ì—¬ëŸ¬ë¶„ë“¤ì´ ë¦¬ëˆ…ìŠ¤ 커ë„ì˜ ë³´ì•ˆ ë¬¸ì œë¥¼ ë°œê²¬í–ˆë‹¤ê³ ìƒê°í•œë‹¤ë©´ ì´ ë¬¸ì„œì— ë‚˜ì˜¨ ë‹¨ê³„ì— ë”°ë¼ì„œ ì»¤ë„ ê°œë°œìžë“¤ì—게 ì•Œë¦¬ê³ ê·¸ ë¬¸ì œë¥¼ í•´ê²°í• ìˆ˜ 있ë„ë¡ ë„와 달ë¼. diff --git a/Documentation/translations/sp_SP/howto.rst b/Documentation/translations/sp_SP/howto.rst index f9818d687b54..f1629738b49d 100644 --- a/Documentation/translations/sp_SP/howto.rst +++ b/Documentation/translations/sp_SP/howto.rst @@ -135,7 +135,7 @@ de obligada lectura: de Linux y es muy importante para las personas que se mudan a Linux tras desarrollar otros sistemas operativos. - :ref:`Documentation/admin-guide/security-bugs.rst <securitybugs>` + :ref:`Documentation/process/security-bugs.rst <securitybugs>` Si cree que ha encontrado un problema de seguridad en el kernel de Linux, siga los pasos de este documento para ayudar a notificar a los desarrolladores del kernel y ayudar a resolver el problema. diff --git a/Documentation/translations/sp_SP/memory-barriers.txt b/Documentation/translations/sp_SP/memory-barriers.txt index f62bd797216d..27097a808c88 100644 --- a/Documentation/translations/sp_SP/memory-barriers.txt +++ b/Documentation/translations/sp_SP/memory-barriers.txt @@ -604,7 +604,7 @@ READ_ONCE() para DEC Alpha, lo que significa que las únicas personas que necesitan prestar atención a esta sección son aquellas que trabajan en el código especÃfico de la arquitectura DEC Alpha y aquellas que trabajan en READ_ONCE() por dentro. Para aquellos que lo necesitan, y para aquellos que -estén interesados ​​desde un punto de vista histórico, aquà está la historia +estén interesados desde un punto de vista histórico, aquà está la historia de las barreras de dependencia de dirección. [!] Si bien las dependencias de direcciones se observan tanto en carga a diff --git a/Documentation/translations/sp_SP/process/deprecated.rst b/Documentation/translations/sp_SP/process/deprecated.rst new file mode 100644 index 000000000000..d52120e0d753 --- /dev/null +++ b/Documentation/translations/sp_SP/process/deprecated.rst @@ -0,0 +1,381 @@ +.. include:: ../disclaimer-sp.rst + +:Original: :ref:`Documentation/process/deprecated.rst <deprecated>` +:Translator: Sergio Gonzalez <sergio.collado@gmail.com> + +.. _sp_deprecated: + +============================================================================ +Interfaces obsoletos, CaracterÃsticas del lenguaje, Atributos y Convenciones +============================================================================ + +En un mundo perfecto, serÃa posible convertir todas las instancias de +alguna API obsoleta en una nueva API y quitar la API anterior en un +único ciclo de desarrollo. Desafortunadamente, debido al tamaño del kernel, +la jerarquÃa de mantenimiento, y el tiempo, no siempre es posible hacer +estos cambios de una única vez. Esto significa que las nuevas instancias +han de ir creándose en el kernel, mientras que las antiguas se quitan, +haciendo que la cantidad de trabajo para limpiar las APIs crezca. Para +informar a los desarrolladores sobre qué ha sido declarado obsoleto y por +qué, ha sido creada esta lista como un lugar donde indicar cuando los usos +obsoletos son propuestos para incluir en el kernel. + +__deprecated +------------ +Mientras que este atributo señala visualmente que un interface ha sido +declarado obsoleto, este `no produce más avisos durante las compilaciones +<https://git.kernel.org/linus/771c035372a036f83353eef46dbb829780330234>`_ +porque uno de los objetivos del kernel es que compile sin avisos, y +nadie ha hecho nada para quitar estos interfaces obsoletos. Mientras +que usar `__deprecated` es sencillo para anotar una API obsoleta en +un archivo de cabecera, no es la solución completa. Dichos interfaces +deben o bien ser quitados por completo, o añadidos a este archivo para +desanimar a otros a usarla en el futuro. + +BUG() y BUG_ON() +---------------- +Use WARN() y WARN_ON() en su lugar, y gestione las condiciones de error +"imposibles" tan elegantemente como se pueda. Mientras que la familia de +funciones BUG() fueron originalmente diseñadas para actuar como una +"situación imposible", confirmar y disponer de un hilo del kernel de forma +"segura", estas funciones han resultado ser demasiado arriesgadas. (e.g. +"¿en qué orden se necesitan liberar los locks? ¿Se han restaurado sus +estados?). La popular función BUG() desestabilizará el sistema o lo romperá +totalmente, lo cual hace imposible depurarlo o incluso generar reportes de +crash. Linus tiene una `opinión muy fuerte +<https://lore.kernel.org/lkml/CA+55aFy6jNLsywVYdGp83AMrXBo_P-pkjkphPGrO=82SPKCpLQ@mail.gmail.com/>`_ +y sentimientos `sobre esto +<https://lore.kernel.org/lkml/CAHk-=whDHsbK3HTOpTF=ue_o04onRwTEaK_ZoJp_fjbqq4+=Jw@mail.gmail.com/>`_. + +Nótese que la familia de funciones WARN() únicamente deberÃa ser usada +en situaciones que se "esperan no sean alcanzables". Si se quiere +avisar sobre situaciones "alcanzables pero no deseadas", úsese la familia +de funciones pr_warn(). Los responsables del sistema pueden haber definido +*panic_on_warn* sysctl para asegurarse que sus sistemas no continúan +ejecutándose en presencia del condiciones "no alcanzables". (Por ejemplo, +véase commits como `este +<https://git.kernel.org/linus/d4689846881d160a4d12a514e991a740bcb5d65a>`_.) + +Operaciones aritméticas en los argumentos de reserva de memoria +--------------------------------------------------------------- +Los cálculos dinámicos de tamaño (especialmente multiplicaciones) no +deberÃan realizarse en los argumentos de reserva de memoria (o similares) +debido al riesgo de desbordamiento. Esto puede llevar a valores rotando y +que se realicen reservas de memoria menores que las que se esperaban. El +uso de esas reservas puede llevar a desbordamientos en el 'heap' de memoria +y otros funcionamientos incorrectos. (Una excepción a esto son los valores +literales donde el compilador si puede avisar si estos puede desbordarse. +De todos modos, el método recomendado en estos caso es reescribir el código +como se sugiere a continuación para evitar las operaciones aritméticas en +la reserva de memoria.) + +Por ejemplo, no utilice `count * size`` como argumento, como en:: + + foo = kmalloc(count * size, GFP_KERNEL); + +En vez de eso, utilice la reserva con dos argumentos:: + + foo = kmalloc_array(count, size, GFP_KERNEL); + +EspecÃficamente, kmalloc() puede ser sustituido con kmalloc_array(), +kzalloc() puede ser sustituido con kcalloc(). + +Si no existen funciones con dos argumentos, utilice las funciones que se +saturan, en caso de desbordamiento:: + + bar = vmalloc(array_size(count, size)); + +Otro caso común a evitar es calcular el tamaño de una estructura com +la suma de otras estructuras, como en:: + + header = kzalloc(sizeof(*header) + count * sizeof(*header->item), + GFP_KERNEL); + +En vez de eso emplee:: + + header = kzalloc(struct_size(header, item, count), GFP_KERNEL); + +.. note:: Si se usa struct_size() en una estructura que contiene un elemento + de longitud cero o un array de un único elemento como un array miembro, + por favor reescribir ese uso y cambiar a un `miembro array flexible + <#zero-length-and-one-element-arrays>`_ + + +Para otros cálculos, por favor use las funciones de ayuda: size_mul(), +size_add(), and size_sub(). Por ejemplo, en el caso de:: + + foo = krealloc(current_size + chunk_size * (count - 3), GFP_KERNEL); + +Re-escrÃbase, como:: + + foo = krealloc(size_add(current_size, + size_mul(chunk_size, + size_sub(count, 3))), GFP_KERNEL); + +Para más detalles, mire también array3_size() y flex_array_size(), +como también la familia de funciones relacionadas check_mul_overflow(), +check_add_overflow(), check_sub_overflow(), y check_shl_overflow(). + + +simple_strtol(), simple_strtoll(), simple_strtoul(), simple_strtoull() +---------------------------------------------------------------------- +Las funciones: simple_strtol(), simple_strtoll(), simple_strtoul(), y +simple_strtoull() explÃcitamente ignoran los desbordamientos, lo que puede +llevar a resultados inesperados por las funciones que las llaman. Las +funciones respectivas kstrtol(), kstrtoll(), kstrtoul(), y kstrtoull() +tienden a ser reemplazos correctos, aunque nótese que necesitarán que la +cadena de caracteres termine en NUL o en el carácter de lÃnea nueva. + + +strcpy() +-------- +strcpy() no realiza verificaciones de los lÃmites del buffer de destino. +Esto puede resultar en desbordamientos lineals más allá del fin del buffer, +causando todo tipo de errores. Mientras `CONFIG_FORTIFY_SOURCE=y` otras +varias opciones de compilación reducen el riesgo de usar esta función, no +hay ninguna buena razón para añadir nuevos usos de esta. El remplazo seguro +es la función strscpy(), aunque se ha de tener cuidado con cualquier caso +en el el valor retornado por strcpy() sea usado, ya que strscpy() no +devuelve un puntero a el destino, sino el número de caracteres no nulos +compilados (o el valor negativo de errno cuando se trunca la cadena de +caracteres). + +strncpy() en cadenas de caracteres terminadas en NUL +---------------------------------------------------- +El uso de strncpy() no garantiza que el buffer de destino esté terminado en +NUL. Esto puede causar varios errores de desbordamiento en lectura y otros +tipos de funcionamiento erróneo debido a que falta la terminación en NUL. +Esta función también termina la cadena de caracteres en NUL en el buffer de +destino si la cadena de origen es más corta que el buffer de destino, lo +cual puede ser una penalización innecesaria para funciones usen esta +función con cadenas de caracteres que sà están terminadas en NUL. + +Cuando se necesita que la cadena de destino sea terminada en NUL, +el mejor reemplazo es usar la función strscpy(), aunque se ha de tener +cuidado en los casos en los que el valor de strncpy() fuera usado, ya que +strscpy() no devuelve un puntero al destino, sino el número de +caracteres no nulos copiados (o el valor negativo de errno cuando se trunca +la cadena de caracteres). Cualquier caso restante que necesitase todavÃa +ser terminado en el caracter nulo, deberÃa usar strscpy_pad(). + +Si una función usa cadenas de caracteres que no necesitan terminar en NUL, +deberÃa usarse strtomem(), y el destino deberÃa señalarse con el atributo +`__nonstring +<https://gcc.gnu.org/onlinedocs/gcc/Common-Variable-Attributes.html>`_ +para evitar avisos futuros en el compilador. Para casos que todavÃa +necesitan cadenas de caracteres que se rellenen al final con el +caracter NUL, usar strtomem_pad(). + +strlcpy() +--------- +strlcpy() primero lee por completo el buffer de origen (ya que el valor +devuelto intenta ser el mismo que el de strlen()). Esta lectura puede +sobrepasar el lÃmite de tamaño del destino. Esto ineficiente y puede causar +desbordamientos de lectura si la cadena de origen no está terminada en el +carácter NUL. El reemplazo seguro de esta función es strscpy(), pero se ha +de tener cuidado que en los casos en lso que se usase el valor devuelto de +strlcpy(), ya que strscpy() devolverá valores negativos de erno cuando se +produzcan truncados. + +Especificación de formato %p +---------------------------- +Tradicionalmente,el uso de "%p" en el formato de cadenas de caracteres +resultarÃa en exponer esas direcciones en dmesg, proc, sysfs, etc. En vez +de dejar que sean una vulnerabilidad, todos los "%p" que se usan en el +kernel se imprimen como un hash, haciéndolos efectivamente inutilizables +para usarlos como direcciones de memoria. Nuevos usos de "%p" no deberÃan +ser añadidos al kernel. Para textos de direcciones, usar "%pS" es +mejor, ya que resulta en el nombre del sÃmbolo. Para prácticamente el +resto de casos, mejor no usar "%p" en absoluto. + +Parafraseando las actuales `direcciones de Linus <https://lore.kernel.org/lkml/CA+55aFwQEd_d40g4mUCSsVRZzrFPUJt74vc6PPpb675hYNXcKw@mail.gmail.com/>`_: + +- Si el valor "hasheado" "%p" no tienen ninguna finalidad, preguntarse si el + puntero es realmente importante. ¿Quizás se podrÃa quitar totalmente? +- Si realmente se piensa que el valor del puntero es importante, ¿porqué + algún estado del sistema o nivel de privilegio de usuario es considerado + "especial"? Si piensa que puede justificarse (en comentarios y mensajes + del commit), de forma suficiente como para pasar el escrutinio de Linux, + quizás pueda usar el "%p", a la vez que se asegura que tiene los permisos + correspondientes. + +Si está depurando algo donde el "%p" hasheado está causando problemas, +se puede arrancar temporalmente con la opción de depuración "`no_hash_pointers +<https://git.kernel.org/linus/5ead723a20e0447bc7db33dc3070b420e5f80aa6>`_". + + +Arrays de longitud variable (VLAs) +---------------------------------- +Usando VLA en la pila (stack) produce un código mucho peor que los arrays +de tamaño estático. Mientras que estos errores no triviales de `rendimiento +<https://git.kernel.org/linus/02361bc77888>`_ son razón suficiente +para no usar VLAs, esto además son un riesgo de seguridad. El crecimiento +dinámico del array en la pila, puede exceder la memoria restante en +el segmento de la pila. Esto podrÃa llevara a un fallo, posible sobre-escritura +de contenido al final de la pila (cuando se construye sin +`CONFIG_THREAD_INFO_IN_TASK=y`), o sobre-escritura de la memoria adyacente +a la pila (cuando se construye sin `CONFIG_VMAP_STACK=y`). + + +Switch case fall-through implÃcito +---------------------------------- +El lenguaje C permite a las sentencias 'switch' saltar de un caso al +siguiente caso cuando la sentencia de ruptura "break" no aparece al final +del caso. Esto, introduce ambigüedad en el código, ya que no siempre está +claro si el 'break' que falta es intencionado o un olvido. Por ejemplo, no +es obvio solamente mirando al código si `STATE_ONE` está escrito para +intencionadamente saltar en `STATE_TWO`:: + + switch (value) { + case STATE_ONE: + do_something(); + case STATE_TWO: + do_other(); + break; + default: + WARN("unknown state"); + } + +Ya que ha habido una larga lista de defectos `debidos a declaraciones de "break" +que faltan <https://cwe.mitre.org/data/definitions/484.html>`_, no se +permiten 'fall-through' implÃcitos. Para identificar 'fall-through' +intencionados, se ha adoptado la pseudo-palabra-clave macro "falltrhrough", +que expande las extensiones de gcc `__attribute__((__fallthrough__)) +<https://gcc.gnu.org/onlinedocs/gcc/Statement-Attributes.html>`_. +(Cuando la sintaxis de C17/c18 `[[fallthrough]]` sea más comúnmente +soportadas por los compiladores de C, analizadores estáticos, e IDEs, +se puede cambiar a usar esa sintaxis para esa pseudo-palabra-clave. + +Todos los bloques switch/case deben acabar en uno de: + +* break; +* fallthrough; +* continue; +* goto <label>; +* return [expression]; + + +Arrays de longitud cero y un elemento +------------------------------------- +Hay una necesidad habitual en el kernel de proveer una forma para declarar +un grupo de elementos consecutivos de tamaño dinámico en una estructura. +El código del kernel deberÃa usar siempre `"miembros array flexible" <https://en.wikipedia.org/wiki/Flexible_array_member>`_ +en estos casos. El estilo anterior de arrays de un elemento o de longitud +cero, no deben usarse más. + +En el código C más antiguo, los elementos finales de tamaño dinámico se +obtenÃan especificando un array de un elemento al final de una estructura:: + + struct something { + size_t count; + struct foo items[1]; + }; + +En código C más antiguo, elementos seguidos de tamaño dinámico eran creados +especificando una array de un único elemento al final de una estructura:: + + struct something { + size_t count; + struct foo items[1]; + }; + +Esto llevó a resultados incorrectos en los cálculos de tamaño mediante +sizeof() (el cual hubiera necesitado eliminar el tamaño del último elemento +para tener un tamaño correcto de la "cabecera"). Una `extensión de GNU C +<https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html>`_ se empezó a usar +para permitir los arrays de longitud cero, para evitar estos tipos de +problemas de tamaño:: + + struct something { + size_t count; + struct foo items[0]; + }; + +Pero esto llevó a otros problemas, y no solucionó algunos otros problemas +compartidos por ambos estilos, como no ser capaz de detectar cuando ese array +accidentalmente _no_ es usado al final de la estructura (lo que podÃa pasar +directamente, o cuando dicha estructura era usada en uniones, estructuras +de estructuras, etc). + +C99 introdujo "los arrays miembros flexibles", los cuales carecen de un +tamaño numérico en su declaración del array:: + + struct something { + size_t count; + struct foo items[]; + }; + +Esta es la forma en la que el kernel espera que se declaren los elementos +de tamaño dinámico concatenados. Esto permite al compilador generar +errores, cuando el array flexible no es declarado en el último lugar de la +estructura, lo que ayuda a prevenir errores en él código del tipo +`comportamiento indefinido <https://git.kernel.org/linus/76497732932f15e7323dc805e8ea8dc11bb587cf>`_. +Esto también permite al compilador analizar correctamente los tamaños de +los arrays (via sizeof(), `CONFIG_FORTIFY_SOURCE`, y `CONFIG_UBSAN_BOUNDS`). +Por ejemplo, si no hay un mecanismo que avise que el siguiente uso de +sizeof() en un array de longitud cero, siempre resulta en cero:: + + struct something { + size_t count; + struct foo items[0]; + }; + + struct something *instance; + + instance = kmalloc(struct_size(instance, items, count), GFP_KERNEL); + instance->count = count; + + size = sizeof(instance->items) * instance->count; + memcpy(instance->items, source, size); + +En la última lÃnea del código anterior, ``zero`` vale ``cero``, cuando uno +podrÃa esperar que representa el tamaño total en bytes de la memoria dinámica +reservada para el array consecutivo ``items``. Aquà hay un par de ejemplos +más sobre este tema: `link 1 +<https://git.kernel.org/linus/f2cd32a443da694ac4e28fbf4ac6f9d5cc63a539>`_, +`link 2 +<https://git.kernel.org/linus/ab91c2a89f86be2898cee208d492816ec238b2cf>`_. +Sin embargo, los array de miembros flexibles tienen un type incompleto, y +no se ha de aplicar el operador sizeof()<https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html>`_, +asà cualquier mal uso de dichos operadores será detectado inmediatamente en +el momento de compilación. + +Con respecto a los arrays de un único elemento, se ha de ser consciente de +que dichos arrays ocupan al menos tanto espacio como un único objeto del +tipo https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html>`_, de ahà que +estos contribuyan al tamaño de la estructura que los contiene. Esto es +proclive a errores cada vez que se quiere calcular el tamaño total de la +memoria dinámica para reservar una estructura que contenga un array de este +tipo como su miembro:: + + struct something { + size_t count; + struct foo items[1]; + }; + + struct something *instance; + + instance = kmalloc(struct_size(instance, items, count - 1), GFP_KERNEL); + instance->count = count; + + size = sizeof(instance->items) * instance->count; + memcpy(instance->items, source, size); + +En el ejemplo anterior, hemos de recordar calcular ``count - 1``, cuando se +usa la función de ayuda struct_size(), de otro modo estarÃamos +--desintencionadamente--reservando memoria para un ``items`` de más. La +forma más clara y menos proclive a errores es implementar esto mediante el +uso de `array miembro flexible`, junto con las funciones de ayuda: +struct_size() y flex_array_size():: + + struct something { + size_t count; + struct foo items[]; + }; + + struct something *instance; + + instance = kmalloc(struct_size(instance, items, count), GFP_KERNEL); + instance->count = count; + + memcpy(instance->items, source, flex_array_size(instance, items, instance->count)); diff --git a/Documentation/translations/sp_SP/process/index.rst b/Documentation/translations/sp_SP/process/index.rst index 0f1e131b3bb1..3b0c32593726 100644 --- a/Documentation/translations/sp_SP/process/index.rst +++ b/Documentation/translations/sp_SP/process/index.rst @@ -18,3 +18,4 @@ email-clients magic-number programming-language + deprecated diff --git a/Documentation/translations/sp_SP/process/submitting-patches.rst b/Documentation/translations/sp_SP/process/submitting-patches.rst index bf95ceb5e865..c2757d9ab216 100644 --- a/Documentation/translations/sp_SP/process/submitting-patches.rst +++ b/Documentation/translations/sp_SP/process/submitting-patches.rst @@ -276,7 +276,7 @@ parche a security@kernel.org. Para errores graves, se debe mantener un poco de discreción y permitir que los distribuidores entreguen el parche a los usuarios; en esos casos, obviamente, el parche no debe enviarse a ninguna lista pública. Revise también -Documentation/admin-guide/security-bugs.rst. +Documentation/process/security-bugs.rst. Los parches que corrigen un error grave en un kernel en uso deben dirigirse hacia los maintainers estables poniendo una lÃnea como esta:: diff --git a/Documentation/translations/zh_CN/admin-guide/mm/damon/lru_sort.rst b/Documentation/translations/zh_CN/admin-guide/mm/damon/lru_sort.rst index 812ef315c8f6..03d33c710604 100644 --- a/Documentation/translations/zh_CN/admin-guide/mm/damon/lru_sort.rst +++ b/Documentation/translations/zh_CN/admin-guide/mm/damon/lru_sort.rst @@ -250,7 +250,7 @@ LRU的优先级的æå‡ï¼ŒåŒæ—¶é™ä½Žé‚£äº›è¶…过120ç§’æ— äººè®¿é—®çš„å†…å˜åŒ ç†è¢«é™åˆ¶åœ¨æœ€å¤š1%çš„CPU以é¿å…DAMON_LRU_SORT消费过多CPU时间。在系统空闲内å˜è¶…过50% æ—¶DAMON_LRU_SORTåœæ¢å·¥ä½œï¼Œå¹¶åœ¨ä½ŽäºŽ40%æ—¶é‡æ–°å¼€å§‹å·¥ä½œã€‚如果DAMON_RECLAIM没有å–å¾— 进展且空闲内å˜ä½ŽäºŽ20%，å†æ¬¡è®©DAMON_LRU_SORTåœæ¢å·¥ä½œï¼Œä»¥æ¤å›žé€€åˆ°ä»¥LRU链表为基础 -以页é¢ä¸ºå•ä½çš„内å˜å›žæ”¶ä¸Šã€‚ +以页é¢ä¸ºå•ä½çš„内å˜å›žæ”¶ä¸Šã€‚ :: # cd /sys/modules/damon_lru_sort/parameters # echo 500 > hot_thres_access_freq diff --git a/Documentation/translations/zh_CN/admin-guide/security-bugs.rst b/Documentation/translations/zh_CN/admin-guide/security-bugs.rst index b8120391755d..d6b8f8a4e7f6 100644 --- a/Documentation/translations/zh_CN/admin-guide/security-bugs.rst +++ b/Documentation/translations/zh_CN/admin-guide/security-bugs.rst @@ -1,6 +1,6 @@ .. include:: ../disclaimer-zh_CN.rst -:Original: :doc:`../../../admin-guide/security-bugs` +:Original: :doc:`../../../process/security-bugs` :译者: diff --git a/Documentation/translations/zh_CN/arch.rst b/Documentation/translations/zh_CN/arch/index.rst index 690e173d8b2a..908ea131bb1c 100644 --- a/Documentation/translations/zh_CN/arch.rst +++ b/Documentation/translations/zh_CN/arch/index.rst @@ -8,12 +8,12 @@ .. toctree:: :maxdepth: 2 - mips/index - arm64/index - riscv/index + ../mips/index + ../arm64/index + ../riscv/index openrisc/index parisc/index - loongarch/index + ../loongarch/index TODOList: diff --git a/Documentation/translations/zh_CN/openrisc/index.rst b/Documentation/translations/zh_CN/arch/openrisc/index.rst index 9ad6cc600884..da21f8ab894b 100644 --- a/Documentation/translations/zh_CN/openrisc/index.rst +++ b/Documentation/translations/zh_CN/arch/openrisc/index.rst @@ -1,8 +1,8 @@ .. SPDX-License-Identifier: GPL-2.0 -.. include:: ../disclaimer-zh_CN.rst +.. include:: ../../disclaimer-zh_CN.rst -:Original: Documentation/openrisc/index.rst +:Original: Documentation/arch/openrisc/index.rst :翻译: diff --git a/Documentation/translations/zh_CN/openrisc/openrisc_port.rst b/Documentation/translations/zh_CN/arch/openrisc/openrisc_port.rst index b8a67670492d..cadc580fa23b 100644 --- a/Documentation/translations/zh_CN/openrisc/openrisc_port.rst +++ b/Documentation/translations/zh_CN/arch/openrisc/openrisc_port.rst @@ -1,6 +1,6 @@ -.. include:: ../disclaimer-zh_CN.rst +.. include:: ../../disclaimer-zh_CN.rst -:Original: Documentation/openrisc/openrisc_port.rst +:Original: Documentation/arch/openrisc/openrisc_port.rst :翻译: diff --git a/Documentation/translations/zh_CN/openrisc/todo.rst b/Documentation/translations/zh_CN/arch/openrisc/todo.rst index 63c38717edb1..1f6f95616633 100644 --- a/Documentation/translations/zh_CN/openrisc/todo.rst +++ b/Documentation/translations/zh_CN/arch/openrisc/todo.rst @@ -1,6 +1,6 @@ -.. include:: ../disclaimer-zh_CN.rst +.. include:: ../../disclaimer-zh_CN.rst -:Original: Documentation/openrisc/todo.rst +:Original: Documentation/arch/openrisc/todo.rst :翻译: diff --git a/Documentation/translations/zh_CN/parisc/debugging.rst b/Documentation/translations/zh_CN/arch/parisc/debugging.rst index 68b73eb57105..c6b9de6d3175 100644 --- a/Documentation/translations/zh_CN/parisc/debugging.rst +++ b/Documentation/translations/zh_CN/arch/parisc/debugging.rst @@ -1,6 +1,6 @@ -.. include:: ../disclaimer-zh_CN.rst +.. include:: ../../disclaimer-zh_CN.rst -:Original: Documentation/parisc/debugging.rst +:Original: Documentation/arch/parisc/debugging.rst :翻译: diff --git a/Documentation/translations/zh_CN/parisc/index.rst b/Documentation/translations/zh_CN/arch/parisc/index.rst index 0cc553fc8272..9f69283bd1c9 100644 --- a/Documentation/translations/zh_CN/parisc/index.rst +++ b/Documentation/translations/zh_CN/arch/parisc/index.rst @@ -1,7 +1,7 @@ .. SPDX-License-Identifier: GPL-2.0 -.. include:: ../disclaimer-zh_CN.rst +.. include:: ../../disclaimer-zh_CN.rst -:Original: Documentation/parisc/index.rst +:Original: Documentation/arch/parisc/index.rst :翻译: diff --git a/Documentation/translations/zh_CN/parisc/registers.rst b/Documentation/translations/zh_CN/arch/parisc/registers.rst index d2ab1874a602..a55250afcc27 100644 --- a/Documentation/translations/zh_CN/parisc/registers.rst +++ b/Documentation/translations/zh_CN/arch/parisc/registers.rst @@ -1,6 +1,6 @@ -.. include:: ../disclaimer-zh_CN.rst +.. include:: ../../disclaimer-zh_CN.rst -:Original: Documentation/parisc/registers.rst +:Original: Documentation/arch/parisc/registers.rst :翻译: diff --git a/Documentation/translations/zh_CN/driver-api/gpio/legacy.rst b/Documentation/translations/zh_CN/driver-api/gpio/legacy.rst index 74fa473bb504..84ce2322fdba 100644 --- a/Documentation/translations/zh_CN/driver-api/gpio/legacy.rst +++ b/Documentation/translations/zh_CN/driver-api/gpio/legacy.rst @@ -219,7 +219,6 @@ GPIO 值的命令需è¦ç‰å¾…其信æ¯æŽ’到队首æ‰å‘é€å‘½ä»¤ï¼Œå†èŽ·å¾—å…¶ ## gpio_free_array() gpio_free() - gpio_set_debounce() @@ -654,25 +653,6 @@ GPIO 控制器的路径类似 /sys/class/gpio/gpiochip42/ (对于从#42 GPIO 确定给定信å·æ‰€ç”¨çš„ GPIO ç¼–å·ã€‚ -ä»Žå†…æ ¸ä»£ç ä¸å¯¼å‡º ----------------- - -å†…æ ¸ä»£ç å¯ä»¥æ˜Žç¡®åœ°ç®¡ç†é‚£äº›å·²é€šè¿‡ gpio_request()申请的 GPIO 的导出:: - - /* 导出 GPIO 到用户空间 */ - int gpio_export(unsigned gpio, bool direction_may_change); - - /* gpio_export()的逆æ“作 */ - void gpio_unexport(); - -åœ¨ä¸€ä¸ªå†…æ ¸é©±åŠ¨ç”³è¯·ä¸€ä¸ª GPIO 之åŽï¼Œå®ƒå¯ä»¥é€šè¿‡ gpio_export()使其在 sysfs -接å£ä¸å¯è§ã€‚该驱动å¯ä»¥æŽ§åˆ¶ä¿¡å·æ–¹å‘是å¦å¯ä¿®æ”¹ã€‚这有助于防æ¢ç”¨æˆ·ç©ºé—´ä»£ç æ— æ„é—´ -ç ´åé‡è¦çš„系统状æ€ã€‚ - -这个明确的导出有助于(通过使æŸäº›å®žéªŒæ›´å®¹æ˜“æ¥)调试，也å¯ä»¥æ供一个始终å˜åœ¨çš„接å£ï¼Œ -与文档é…åˆä½œä¸ºæ¿çº§æ”¯æŒåŒ…的一部分。 - - APIå‚考 ======= diff --git a/Documentation/translations/zh_CN/index.rst b/Documentation/translations/zh_CN/index.rst index 7c3216845b71..299704c0818d 100644 --- a/Documentation/translations/zh_CN/index.rst +++ b/Documentation/translations/zh_CN/index.rst @@ -120,7 +120,7 @@ TODOList: .. toctree:: :maxdepth: 2 - arch + arch/index 其他文档 -------- diff --git a/Documentation/translations/zh_CN/process/howto.rst b/Documentation/translations/zh_CN/process/howto.rst index 10254751df6a..cc47be356dd3 100644 --- a/Documentation/translations/zh_CN/process/howto.rst +++ b/Documentation/translations/zh_CN/process/howto.rst @@ -125,7 +125,7 @@ Linuxå†…æ ¸ä»£ç ä¸åŒ…å«æœ‰å¤§é‡çš„文档。这些文档对于å¦ä¹ 如何与 这篇文档对于ç†è§£Linuxçš„å¼€å‘哲å¦è‡³å…³é‡è¦ã€‚对于将开å‘å¹³å°ä»Žå…¶ä»–æ“作系 统转移到Linux的人æ¥è¯´ä¹Ÿå¾ˆé‡è¦ã€‚ - :ref:`Documentation/admin-guide/security-bugs.rst <securitybugs>` + :ref:`Documentation/process/security-bugs.rst <securitybugs>` å¦‚æžœä½ è®¤ä¸ºè‡ªå·±å‘现了Linuxå†…æ ¸çš„å®‰å…¨æ€§é—®é¢˜ï¼Œè¯·æ ¹æ®è¿™ç¯‡æ–‡æ¡£ä¸çš„æ¥éª¤æ¥ æé†’å…¶ä»–å†…æ ¸å¼€å‘者并帮助解决这个问题。 diff --git a/Documentation/translations/zh_TW/admin-guide/security-bugs.rst b/Documentation/translations/zh_TW/admin-guide/security-bugs.rst index eed260ef0c37..15f8e9005071 100644 --- a/Documentation/translations/zh_TW/admin-guide/security-bugs.rst +++ b/Documentation/translations/zh_TW/admin-guide/security-bugs.rst @@ -2,7 +2,7 @@ .. include:: ../disclaimer-zh_TW.rst -:Original: :doc:`../../../admin-guide/security-bugs` +:Original: :doc:`../../../process/security-bugs` :è¯è€…: diff --git a/Documentation/translations/zh_TW/gpio.txt b/Documentation/translations/zh_TW/gpio.txt index 1b986bbb0909..62e560ffe628 100644 --- a/Documentation/translations/zh_TW/gpio.txt +++ b/Documentation/translations/zh_TW/gpio.txt @@ -226,7 +226,6 @@ GPIO 值的命令需è¦ç‰å¾…其信æ¯æŽ’到隊首æ‰ç™¼é€å‘½ä»¤ï¼Œå†ç²å¾—å…¶ ## gpio_free_array() gpio_free() - gpio_set_debounce() @@ -615,21 +614,3 @@ GPIO 控制器的路徑類似 /sys/class/gpio/gpiochip42/ (å°æ–¼å¾ž#42 GPIO 固定的,例如在擴展å¡ä¸Šçš„ GPIOæœƒæ ¹æ“šæ‰€ä½¿ç”¨çš„ä¸»æ¿æˆ–æ‰€åœ¨å †ç–Šæž¶æ§‹ä¸å…¶ä»–çš„æ¿å而 有所ä¸åŒã€‚在這種情æ³ä¸‹,ä½ å¯èƒ½éœ€è¦ä½¿ç”¨ gpiochip 節點(儘å¯èƒ½åœ°çµåˆé›»è·¯åœ–)來 確定給定信號所用的 GPIO 編號。 - - -å¾žå…§æ ¸ä»£ç¢¼ä¸å°Žå‡º -------------- -å…§æ ¸ä»£ç¢¼å¯ä»¥æ˜Žç¢ºåœ°ç®¡ç†é‚£äº›å·²é€šéŽ gpio_request()申請的 GPIO 的導出: - - /* 導出 GPIO 到用戶空間 */ - int gpio_export(unsigned gpio, bool direction_may_change); - - /* gpio_export()的逆æ“作 */ - void gpio_unexport(); - -åœ¨ä¸€å€‹å…§æ ¸é©…å‹•ç”³è«‹ä¸€å€‹ GPIO 之後，它å¯ä»¥é€šéŽ gpio_export()使其在 sysfs -接å£ä¸å¯è¦‹ã€‚該驅動å¯ä»¥æŽ§åˆ¶ä¿¡è™Ÿæ–¹å‘是å¦å¯ä¿®æ”¹ã€‚這有助於防æ¢ç”¨æˆ¶ç©ºé–“代碼無æ„é–“ -ç ´å£žé‡è¦çš„系統狀態。 - -這個明確的導出有助於(通éŽä½¿æŸäº›å¯¦é©—更容易來)調試，也å¯ä»¥æ供一個始終å˜åœ¨çš„接å£ï¼Œ -與文檔é…åˆä½œçˆ²æ¿ç´šæ”¯æŒåŒ…的一部分。 diff --git a/Documentation/translations/zh_TW/process/howto.rst b/Documentation/translations/zh_TW/process/howto.rst index 8fb8edcaee66..ea2f468d3e58 100644 --- a/Documentation/translations/zh_TW/process/howto.rst +++ b/Documentation/translations/zh_TW/process/howto.rst @@ -128,7 +128,7 @@ Linuxå…§æ ¸ä»£ç¢¼ä¸åŒ…å«æœ‰å¤§é‡çš„文檔。這些文檔å°æ–¼å¸ç¿’如何與 這篇文檔å°æ–¼ç†è§£Linux的開發哲å¸è‡³é—œé‡è¦ã€‚å°æ–¼å°‡é–‹ç™¼å¹³å°å¾žå…¶ä»–æ“作系 統轉移到Linux的人來說也很é‡è¦ã€‚ - :ref:`Documentation/admin-guide/security-bugs.rst <securitybugs>` + :ref:`Documentation/process/security-bugs.rst <securitybugs>` å¦‚æžœä½ èªçˆ²è‡ªå·±ç™¼ç¾äº†Linuxå…§æ ¸çš„å®‰å…¨æ€§å•é¡Œï¼Œè«‹æ ¹æ“šé€™ç¯‡æ–‡æª”ä¸çš„æ¥é©Ÿä¾† æé†’å…¶ä»–å…§æ ¸é–‹ç™¼è€…ä¸¦å¹«åŠ©è§£æ±ºé€™å€‹å•é¡Œã€‚ diff --git a/Documentation/usb/gadget_uvc.rst b/Documentation/usb/gadget_uvc.rst new file mode 100644 index 000000000000..6d22faceb1a0 --- /dev/null +++ b/Documentation/usb/gadget_uvc.rst @@ -0,0 +1,352 @@ +======================= +Linux UVC Gadget Driver +======================= + +Overview +-------- +The UVC Gadget driver is a driver for hardware on the *device* side of a USB +connection. It is intended to run on a Linux system that has USB device-side +hardware such as boards with an OTG port. + +On the device system, once the driver is bound it appears as a V4L2 device with +the output capability. + +On the host side (once connected via USB cable), a device running the UVC Gadget +driver *and controlled by an appropriate userspace program* should appear as a UVC +specification compliant camera, and function appropriately with any program +designed to handle them. The userspace program running on the device system can +queue image buffers from a variety of sources to be transmitted via the USB +connection. Typically this would mean forwarding the buffers from a camera sensor +peripheral, but the source of the buffer is entirely dependent on the userspace +companion program. + +Configuring the device kernel +----------------------------- +The Kconfig options USB_CONFIGFS, USB_LIBCOMPOSITE, USB_CONFIGFS_F_UVC and +USB_F_UVC must be selected to enable support for the UVC gadget. + +Configuring the gadget through configfs +--------------------------------------- +The UVC Gadget expects to be configured through configfs using the UVC function. +This allows a significant degree of flexibility, as many of a UVC device's +settings can be controlled this way. + +Not all of the available attributes are described here. For a complete enumeration +see Documentation/ABI/testing/configfs-usb-gadget-uvc + +Assumptions +~~~~~~~~~~~ +This section assumes that you have mounted configfs at `/sys/kernel/config` and +created a gadget as `/sys/kernel/config/usb_gadget/g1`. + +The UVC Function +~~~~~~~~~~~~~~~~ + +The first step is to create the UVC function: + +.. code-block:: bash + + # These variables will be assumed throughout the rest of the document + CONFIGFS="/sys/kernel/config" + GADGET="$CONFIGFS/usb_gadget/g1" + FUNCTION="$GADGET/functions/uvc.0" + + mkdir -p $FUNCTION + +Formats and Frames +~~~~~~~~~~~~~~~~~~ + +You must configure the gadget by telling it which formats you support, as well +as the frame sizes and frame intervals that are supported for each format. In +the current implementation there is no way for the gadget to refuse to set a +format that the host instructs it to set, so it is important that this step is +completed *accurately* to ensure that the host never asks for a format that +can't be provided. + +Formats are created under the streaming/uncompressed and streaming/mjpeg configfs +groups, with the framesizes created under the formats in the following +structure: + +:: + + uvc.0 + + | + + streaming + + | + + mjpeg + + | | + | + mjpeg + + | | + | + 720p + | | + | + 1080p + | + + uncompressed + + | + + yuyv + + | + + 720p + | + + 1080p + +Each frame can then be configured with a width and height, plus the maximum +buffer size required to store a single frame, and finally with the supported +frame intervals for that format and framesize. Width and height are enumerated in +units of pixels, frame interval in units of 100ns. To create the structure +above with 2, 15 and 100 fps frameintervals for each framesize for example you +might do: + +.. code-block:: bash + + create_frame() { + # Example usage: + # create_frame <width> <height> <group> <format name> + + WIDTH=$1 + HEIGHT=$2 + FORMAT=$3 + NAME=$4 + + wdir=$FUNCTION/streaming/$FORMAT/$NAME/${HEIGHT}p + + mkdir -p $wdir + echo $WIDTH > $wdir/wWidth + echo $HEIGHT > $wdir/wHeight + echo $(( $WIDTH * $HEIGHT * 2 )) > $wdir/dwMaxVideoFrameBufferSize + cat <<EOF > $wdir/dwFrameInterval + 666666 + 100000 + 5000000 + EOF + } + + create_frame 1280 720 mjpeg mjpeg + create_frame 1920 1080 mjpeg mjpeg + create_frame 1280 720 uncompressed yuyv + create_frame 1920 1080 uncompressed yuyv + +The only uncompressed format currently supported is YUYV, which is detailed at +Documentation/userspace-api/media/v4l/pixfmt-packed.yuv.rst. + +Color Matching Descriptors +~~~~~~~~~~~~~~~~~~~~~~~~~~ +It's possible to specify some colometry information for each format you create. +This step is optional, and default information will be included if this step is +skipped; those default values follow those defined in the Color Matching Descriptor +section of the UVC specification. + +To create a Color Matching Descriptor, create a configfs item and set its three +attributes to your desired settings and then link to it from the format you wish +it to be associated with: + +.. code-block:: bash + + # Create a new Color Matching Descriptor + + mkdir $FUNCTION/streaming/color_matching/yuyv + pushd $FUNCTION/streaming/color_matching/yuyv + + echo 1 > bColorPrimaries + echo 1 > bTransferCharacteristics + echo 4 > bMatrixCoefficients + + popd + + # Create a symlink to the Color Matching Descriptor from the format's config item + ln -s $FUNCTION/streaming/color_matching/yuyv $FUNCTION/streaming/uncompressed/yuyv + +For details about the valid values, consult the UVC specification. Note that a +default color matching descriptor exists and is used by any format which does +not have a link to a different Color Matching Descriptor. It's possible to +change the attribute settings for the default descriptor, so bear in mind that if +you do that you are altering the defaults for any format that does not link to +a different one. + + +Header linking +~~~~~~~~~~~~~~ + +The UVC specification requires that Format and Frame descriptors be preceded by +Headers detailing things such as the number and cumulative size of the different +Format descriptors that follow. This and similar operations are acheived in +configfs by linking between the configfs item representing the header and the +config items representing those other descriptors, in this manner: + +.. code-block:: bash + + mkdir $FUNCTION/streaming/header/h + + # This section links the format descriptors and their associated frames + # to the header + cd $FUNCTION/streaming/header/h + ln -s ../../uncompressed/yuyv + ln -s ../../mjpeg/mjpeg + + # This section ensures that the header will be transmitted for each + # speed's set of descriptors. If support for a particular speed is not + # needed then it can be skipped here. + cd ../../class/fs + ln -s ../../header/h + cd ../../class/hs + ln -s ../../header/h + cd ../../class/ss + ln -s ../../header/h + cd ../../../control + mkdir header/h + ln -s header/h class/fs + ln -s header/h class/ss + + +Extension Unit Support +~~~~~~~~~~~~~~~~~~~~~~ + +A UVC Extension Unit (XU) basically provides a distinct unit to which control set +and get requests can be addressed. The meaning of those control requests is +entirely implementation dependent, but may be used to control settings outside +of the UVC specification (for example enabling or disabling video effects). An +XU can be inserted into the UVC unit chain or left free-hanging. + +Configuring an extension unit involves creating an entry in the appropriate +directory and setting its attributes appropriately, like so: + +.. code-block:: bash + + mkdir $FUNCTION/control/extensions/xu.0 + pushd $FUNCTION/control/extensions/xu.0 + + # Set the bUnitID of the Processing Unit as the source for this + # Extension Unit + echo 2 > baSourceID + + # Set this XU as the source of the default output terminal. This inserts + # the XU into the UVC chain between the PU and OT such that the final + # chain is IT > PU > XU.0 > OT + cat bUnitID > ../../terminal/output/default/baSourceID + + # Flag some controls as being available for use. The bmControl field is + # a bitmap with each bit denoting the availability of a particular + # control. For example to flag the 0th, 2nd and 3rd controls available: + echo 0x0d > bmControls + + # Set the GUID; this is a vendor-specific code identifying the XU. + echo -e -n "\x01\x02\x03\x04\x05\x06\x07\x08\x09\x0a\x0b\x0c\x0d\x0e\x0f\x10" > guidExtensionCode + + popd + +The bmControls attribute and the baSourceID attribute are multi-value attributes. +This means that you may write multiple newline separated values to them. For +example to flag the 1st, 2nd, 9th and 10th controls as being available you would +need to write two values to bmControls, like so: + +.. code-block:: bash + + cat << EOF > bmControls + 0x03 + 0x03 + EOF + +The multi-value nature of the baSourceID attribute belies the fact that XUs can +be multiple-input, though note that this currently has no significant effect. + +The bControlSize attribute reflects the size of the bmControls attribute, and +similarly bNrInPins reflects the size of the baSourceID attributes. Both +attributes are automatically increased / decreased as you set bmControls and +baSourceID. It is also possible to manually increase or decrease bControlSize +which has the effect of truncating entries to the new size, or padding entries +out with 0x00, for example: + +:: + + $ cat bmControls + 0x03 + 0x05 + + $ cat bControlSize + 2 + + $ echo 1 > bControlSize + $ cat bmControls + 0x03 + + $ echo 2 > bControlSize + $ cat bmControls + 0x03 + 0x00 + +bNrInPins and baSourceID function in the same way. + +Custom Strings Support +~~~~~~~~~~~~~~~~~~~~~~ + +String descriptors that provide a textual description for various parts of a +USB device can be defined in the usual place within USB configfs, and may then +be linked to from the UVC function root or from Extension Unit directories to +assign those strings as descriptors: + +.. code-block:: bash + + # Create a string descriptor in us-EN and link to it from the function + # root. The name of the link is significant here, as it declares this + # descriptor to be intended for the Interface Association Descriptor. + # Other significant link names at function root are vs0_desc and vs1_desc + # For the VideoStreaming Interface 0/1 Descriptors. + + mkdir -p $GADGET/strings/0x409/iad_desc + echo -n "Interface Associaton Descriptor" > $GADGET/strings/0x409/iad_desc/s + ln -s $GADGET/strings/0x409/iad_desc $FUNCTION/iad_desc + + # Because the link to a String Descriptor from an Extension Unit clearly + # associates the two, the name of this link is not significant and may + # be set freely. + + mkdir -p $GADGET/strings/0x409/xu.0 + echo -n "A Very Useful Extension Unit" > $GADGET/strings/0x409/xu.0/s + ln -s $GADGET/strings/0x409/xu.0 $FUNCTION/control/extensions/xu.0 + +The interrupt endpoint +~~~~~~~~~~~~~~~~~~~~~~ + +The VideoControl interface has an optional interrupt endpoint which is by default +disabled. This is intended to support delayed response control set requests for +UVC (which should respond through the interrupt endpoint rather than tying up +endpoint 0). At present support for sending data through this endpoint is missing +and so it is left disabled to avoid confusion. If you wish to enable it you can +do so through the configfs attribute: + +.. code-block:: bash + + echo 1 > $FUNCTION/control/enable_interrupt_ep + +Bandwidth configuration +~~~~~~~~~~~~~~~~~~~~~~~ + +There are three attributes which control the bandwidth of the USB connection. +These live in the function root and can be set within limits: + +.. code-block:: bash + + # streaming_interval sets bInterval. Values range from 1..255 + echo 1 > $FUNCTION/streaming_interval + + # streaming_maxpacket sets wMaxPacketSize. Valid values are 1024/2048/3072 + echo 3072 > $FUNCTION/streaming_maxpacket + + # streaming_maxburst sets bMaxBurst. Valid values are 1..15 + echo 1 > $FUNCTION/streaming_maxburst + + +The values passed here will be clamped to valid values according to the UVC +specification (which depend on the speed of the USB connection). To understand +how the settings influence bandwidth you should consult the UVC specifications, +but a rule of thumb is that increasing the streaming_maxpacket setting will +improve bandwidth (and thus the maximum possible framerate), whilst the same is +true for streaming_maxburst provided the USB connection is running at SuperSpeed. +Increasing streaming_interval will reduce bandwidth and framerate. + +The userspace application +------------------------- +By itself, the UVC Gadget driver cannot do anything particularly interesting. It +must be paired with a userspace program that responds to UVC control requests and +fills buffers to be queued to the V4L2 device that the driver creates. How those +things are achieved is implementation dependent and beyond the scope of this +document, but a reference application can be found at https://gitlab.freedesktop.org/camera/uvc-gadget diff --git a/Documentation/usb/index.rst b/Documentation/usb/index.rst index b656c9be23ed..27955dad95e1 100644 --- a/Documentation/usb/index.rst +++ b/Documentation/usb/index.rst @@ -16,6 +16,7 @@ USB support gadget_multi gadget_printer gadget_serial + gadget_uvc gadget-testing iuu_phoenix mass-storage diff --git a/Documentation/userspace-api/ELF.rst b/Documentation/userspace-api/ELF.rst new file mode 100644 index 000000000000..ac8aeacd458d --- /dev/null +++ b/Documentation/userspace-api/ELF.rst @@ -0,0 +1,34 @@ +.. SPDX-License-Identifier: GPL-2.0 + +================================= +Linux-specific ELF idiosyncrasies +================================= + +Definitions +=========== + +"First" program header is the one with the smallest offset in the file: +e_phoff. + +"Last" program header is the one with the biggest offset in the file: +e_phoff + (e_phnum - 1) * sizeof(Elf_Phdr). + +PT_INTERP +========= + +First PT_INTERP program header is used to locate the filename of ELF +interpreter. Other PT_INTERP headers are ignored (since Linux 2.4.11). + +PT_GNU_STACK +============ + +Last PT_GNU_STACK program header defines userspace stack executability +(since Linux 2.6.6). Other PT_GNU_STACK headers are ignored. + +PT_GNU_PROPERTY +=============== + +ELF interpreter's last PT_GNU_PROPERTY program header is used (since +Linux 5.8). If interpreter doesn't have one, then the last PT_GNU_PROPERTY +program header of an executable is used. Other PT_GNU_PROPERTY headers +are ignored. diff --git a/Documentation/userspace-api/index.rst b/Documentation/userspace-api/index.rst index f16337bdb852..72a65db0c498 100644 --- a/Documentation/userspace-api/index.rst +++ b/Documentation/userspace-api/index.rst @@ -23,6 +23,7 @@ place where this information is gathered. spec_ctrl accelerators/ocxl ebpf/index + ELF ioctl/index iommu iommufd diff --git a/Documentation/userspace-api/media/v4l/dev-overlay.rst b/Documentation/userspace-api/media/v4l/dev-overlay.rst index 4f4b23b95b9b..d52977120b41 100644 --- a/Documentation/userspace-api/media/v4l/dev-overlay.rst +++ b/Documentation/userspace-api/media/v4l/dev-overlay.rst @@ -67,6 +67,7 @@ ioctls must be supported by all video overlay devices. Setup ===== +*Note: support for this has been removed.* Before overlay can commence applications must program the driver with frame buffer parameters, namely the address and size of the frame buffer and the image format, for example RGB 5:6:5. The @@ -92,11 +93,13 @@ A driver may support any (or none) of five clipping/blending methods: 1. Chroma-keying displays the overlaid image only where pixels in the primary graphics surface assume a certain color. -2. A bitmap can be specified where each bit corresponds to a pixel in +2. *Note: support for this has been removed.* + A bitmap can be specified where each bit corresponds to a pixel in the overlaid image. When the bit is set, the corresponding video pixel is displayed, otherwise a pixel of the graphics surface. -3. A list of clipping rectangles can be specified. In these regions *no* +3. *Note: support for this has been removed.* + A list of clipping rectangles can be specified. In these regions *no* video is displayed, so the graphics surface can be seen here. 4. The framebuffer has an alpha channel that can be used to clip or @@ -185,6 +188,7 @@ struct v4l2_window be 0xRRGGBB on a little endian, 0xBBGGRR on a big endian host. ``struct v4l2_clip * clips`` + *Note: support for this has been removed.* When chroma-keying has *not* been negotiated and :ref:`VIDIOC_G_FBUF <VIDIOC_G_FBUF>` indicated this capability, applications can set this field to point to an array of clipping @@ -201,6 +205,7 @@ struct v4l2_window are undefined. ``__u32 clipcount`` + *Note: support for this has been removed.* When the application set the ``clips`` field, this field must contain the number of clipping rectangles in the list. When clip lists are not supported the driver ignores this field, its contents @@ -208,6 +213,7 @@ struct v4l2_window supported but no clipping is desired this field must be set to zero. ``void * bitmap`` + *Note: support for this has been removed.* When chroma-keying has *not* been negotiated and :ref:`VIDIOC_G_FBUF <VIDIOC_G_FBUF>` indicated this capability, applications can set this field to point to a clipping bit mask. diff --git a/Documentation/userspace-api/media/v4l/pixfmt-compressed.rst b/Documentation/userspace-api/media/v4l/pixfmt-compressed.rst index 506dd3c98884..06b78e5589d2 100644 --- a/Documentation/userspace-api/media/v4l/pixfmt-compressed.rst +++ b/Documentation/userspace-api/media/v4l/pixfmt-compressed.rst @@ -88,6 +88,11 @@ Compressed Formats - ``V4L2_PIX_FMT_H263`` - 'H263' - H263 video elementary stream. + * .. _V4L2-PIX-FMT-SPK: + + - ``V4L2_PIX_FMT_SPK`` + - 'SPK0' + - Sorenson Spark is an implementation of H.263 for use in Flash Video and Adobe Flash files * .. _V4L2-PIX-FMT-MPEG1: - ``V4L2_PIX_FMT_MPEG1`` @@ -232,6 +237,26 @@ Compressed Formats Metadata associated with the frame to decode is required to be passed through the ``V4L2_CID_STATELESS_FWHT_PARAMS`` control. See the :ref:`associated Codec Control ID <codec-stateless-fwht>`. + * .. _V4L2-PIX-FMT-RV30: + + - ``V4L2_PIX_FMT_RV30`` + - 'RV30' + - RealVideo, or also spelled as Real Video, is a suite of + proprietary video compression formats developed by + RealNetworks - the specific format changes with the version. + RealVideo codecs are identified by four-character codes. + RV30 corresponds to RealVideo 8, suspected to be based + largely on an early draft of H.264 + * .. _V4L2-PIX-FMT-RV40: + + - ``V4L2_PIX_FMT_RV40`` + - 'RV40' + - RV40 represents RealVideo 9 and RealVideo 10. + RealVideo 9, suspected to be based on H.264. + RealVideo 10, aka RV9 EHQ, This refers to an improved encoder + for the RV9 format that is fully backwards compatible with + RV9 players - the format and decoder did not change, only + the encoder did. As a result, it uses the same FourCC. .. raw:: latex diff --git a/Documentation/userspace-api/media/v4l/pixfmt-packed-yuv.rst b/Documentation/userspace-api/media/v4l/pixfmt-packed-yuv.rst index 24a771542059..9f111ed594d2 100644 --- a/Documentation/userspace-api/media/v4l/pixfmt-packed-yuv.rst +++ b/Documentation/userspace-api/media/v4l/pixfmt-packed-yuv.rst @@ -257,6 +257,34 @@ the second byte and Y'\ :sub:`7-0` in the third byte. - The padding bits contain undefined values that must be ignored by all applications and drivers. +The next table lists the packed YUV 4:4:4 formats with 12 bits per component. +Expand the bits per component to 16 bits, data in the high bits, zeros in the low bits, +arranged in little endian order, storing 1 pixel in 6 bytes. + +.. flat-table:: Packed YUV 4:4:4 Image Formats (12bpc) + :header-rows: 1 + :stub-columns: 0 + + * - Identifier + - Code + - Byte 1-0 + - Byte 3-2 + - Byte 5-4 + - Byte 7-6 + - Byte 9-8 + - Byte 11-10 + + * .. _V4L2-PIX-FMT-YUV48-12: + + - ``V4L2_PIX_FMT_YUV48_12`` + - 'Y312' + + - Y'\ :sub:`0` + - Cb\ :sub:`0` + - Cr\ :sub:`0` + - Y'\ :sub:`1` + - Cb\ :sub:`1` + - Cr\ :sub:`1` 4:2:2 Subsampling ================= diff --git a/Documentation/userspace-api/media/v4l/pixfmt-rgb.rst b/Documentation/userspace-api/media/v4l/pixfmt-rgb.rst index d330aeb4d3eb..b71b80d634d6 100644 --- a/Documentation/userspace-api/media/v4l/pixfmt-rgb.rst +++ b/Documentation/userspace-api/media/v4l/pixfmt-rgb.rst @@ -778,7 +778,7 @@ number of bits for each component. \tiny \setlength{\tabcolsep}{2pt} -.. tabularcolumns:: |p{2.8cm}|p{2.0cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}| +.. tabularcolumns:: |p{3.2cm}|p{0.8cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}| .. flat-table:: RGB Formats 10 Bits Per Color Component @@ -868,7 +868,6 @@ number of bits for each component. - r\ :sub:`4` - r\ :sub:`3` - r\ :sub:`2` - - * .. _V4L2-PIX-FMT-RGBA1010102: - ``V4L2_PIX_FMT_RGBA1010102`` @@ -909,7 +908,6 @@ number of bits for each component. - r\ :sub:`4` - r\ :sub:`3` - r\ :sub:`2` - - * .. _V4L2-PIX-FMT-ARGB2101010: - ``V4L2_PIX_FMT_ARGB2101010`` @@ -950,12 +948,53 @@ number of bits for each component. - r\ :sub:`6` - r\ :sub:`5` - r\ :sub:`4` - - .. raw:: latex \endgroup +12 Bits Per Component +============================== + +These formats store an RGB triplet in six or eight bytes, with 12 bits per component. +Expand the bits per component to 16 bits, data in the high bits, zeros in the low bits, +arranged in little endian order. + +.. raw:: latex + + \small + +.. flat-table:: RGB Formats With 12 Bits Per Component + :header-rows: 1 + + * - Identifier + - Code + - Byte 1-0 + - Byte 3-2 + - Byte 5-4 + - Byte 7-6 + * .. _V4L2-PIX-FMT-BGR48-12: + + - ``V4L2_PIX_FMT_BGR48_12`` + - 'B312' + + - B\ :sub:`15-4` + - G\ :sub:`15-4` + - R\ :sub:`15-4` + - + * .. _V4L2-PIX-FMT-ABGR64-12: + + - ``V4L2_PIX_FMT_ABGR64_12`` + - 'B412' + + - B\ :sub:`15-4` + - G\ :sub:`15-4` + - R\ :sub:`15-4` + - A\ :sub:`15-4` + +.. raw:: latex + + \normalsize Deprecated RGB Formats ====================== diff --git a/Documentation/userspace-api/media/v4l/pixfmt-yuv-luma.rst b/Documentation/userspace-api/media/v4l/pixfmt-yuv-luma.rst index 62078a01de76..cf8e4dfbfbd4 100644 --- a/Documentation/userspace-api/media/v4l/pixfmt-yuv-luma.rst +++ b/Documentation/userspace-api/media/v4l/pixfmt-yuv-luma.rst @@ -103,6 +103,17 @@ are often referred to as greyscale formats. - ... - ... + * .. _V4L2-PIX-FMT-Y012: + + - ``V4L2_PIX_FMT_Y012`` + - 'Y012' + + - Y'\ :sub:`0`\ [3:0] `0000` + - Y'\ :sub:`0`\ [11:4] + - ... + - ... + - ... + * .. _V4L2-PIX-FMT-Y14: - ``V4L2_PIX_FMT_Y14`` @@ -146,3 +157,7 @@ are often referred to as greyscale formats. than 16 bits. For example, 10 bits per pixel uses values in the range 0 to 1023. For the IPU3_Y10 format 25 pixels are packed into 32 bytes, which leaves the 6 most significant bits of the last byte padded with 0. + + For Y012 and Y12 formats, Y012 places its data in the 12 high bits, with + padding zeros in the 4 low bits, in contrast to the Y12 format, which has + its padding located in the most significant bits of the 16 bit word. diff --git a/Documentation/userspace-api/media/v4l/pixfmt-yuv-planar.rst b/Documentation/userspace-api/media/v4l/pixfmt-yuv-planar.rst index f1d5bb7b806d..72324274f20c 100644 --- a/Documentation/userspace-api/media/v4l/pixfmt-yuv-planar.rst +++ b/Documentation/userspace-api/media/v4l/pixfmt-yuv-planar.rst @@ -123,6 +123,20 @@ All components are stored with the same number of bits per component. - Cb, Cr - Yes - 4x4 tiles + * - V4L2_PIX_FMT_P012 + - 'P012' + - 12 + - 4:2:0 + - Cb, Cr + - Yes + - Linear + * - V4L2_PIX_FMT_P012M + - 'PM12' + - 12 + - 4:2:0 + - Cb, Cr + - No + - Linear * - V4L2_PIX_FMT_NV16 - 'NV16' - 8 @@ -586,6 +600,86 @@ Data in the 10 high bits, zeros in the 6 low bits, arranged in little endian ord - Cb\ :sub:`11` - Cr\ :sub:`11` +.. _V4L2-PIX-FMT-P012: +.. _V4L2-PIX-FMT-P012M: + +P012 and P012M +-------------- + +P012 is like NV12 with 12 bits per component, expanded to 16 bits. +Data in the 12 high bits, zeros in the 4 low bits, arranged in little endian order. + +.. flat-table:: Sample 4x4 P012 Image + :header-rows: 0 + :stub-columns: 0 + + * - start + 0: + - Y'\ :sub:`00` + - Y'\ :sub:`01` + - Y'\ :sub:`02` + - Y'\ :sub:`03` + * - start + 8: + - Y'\ :sub:`10` + - Y'\ :sub:`11` + - Y'\ :sub:`12` + - Y'\ :sub:`13` + * - start + 16: + - Y'\ :sub:`20` + - Y'\ :sub:`21` + - Y'\ :sub:`22` + - Y'\ :sub:`23` + * - start + 24: + - Y'\ :sub:`30` + - Y'\ :sub:`31` + - Y'\ :sub:`32` + - Y'\ :sub:`33` + * - start + 32: + - Cb\ :sub:`00` + - Cr\ :sub:`00` + - Cb\ :sub:`01` + - Cr\ :sub:`01` + * - start + 40: + - Cb\ :sub:`10` + - Cr\ :sub:`10` + - Cb\ :sub:`11` + - Cr\ :sub:`11` + +.. flat-table:: Sample 4x4 P012M Image + :header-rows: 0 + :stub-columns: 0 + + * - start0 + 0: + - Y'\ :sub:`00` + - Y'\ :sub:`01` + - Y'\ :sub:`02` + - Y'\ :sub:`03` + * - start0 + 8: + - Y'\ :sub:`10` + - Y'\ :sub:`11` + - Y'\ :sub:`12` + - Y'\ :sub:`13` + * - start0 + 16: + - Y'\ :sub:`20` + - Y'\ :sub:`21` + - Y'\ :sub:`22` + - Y'\ :sub:`23` + * - start0 + 24: + - Y'\ :sub:`30` + - Y'\ :sub:`31` + - Y'\ :sub:`32` + - Y'\ :sub:`33` + * - + * - start1 + 0: + - Cb\ :sub:`00` + - Cr\ :sub:`00` + - Cb\ :sub:`01` + - Cr\ :sub:`01` + * - start1 + 8: + - Cb\ :sub:`10` + - Cr\ :sub:`10` + - Cb\ :sub:`11` + - Cr\ :sub:`11` + Fully Planar YUV Formats ======================== diff --git a/Documentation/userspace-api/media/v4l/user-func.rst b/Documentation/userspace-api/media/v4l/user-func.rst index 228c1521f190..15ff0bf7bbe6 100644 --- a/Documentation/userspace-api/media/v4l/user-func.rst +++ b/Documentation/userspace-api/media/v4l/user-func.rst @@ -72,6 +72,7 @@ Function Reference vidioc-subdev-g-frame-interval vidioc-subdev-g-routing vidioc-subdev-g-selection + vidioc-subdev-g-client-cap vidioc-subdev-querycap vidioc-subscribe-event func-mmap 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 892cfeb8b988..5292d5e1a91f 100644 --- a/Documentation/userspace-api/media/v4l/vidioc-g-ext-ctrls.rst +++ b/Documentation/userspace-api/media/v4l/vidioc-g-ext-ctrls.rst @@ -185,6 +185,16 @@ still cause this situation. - ``p_u32`` - A pointer to a matrix control of unsigned 32-bit values. Valid if this control is of type ``V4L2_CTRL_TYPE_U32``. + * - __u32 * + - ``p_s32`` + - A pointer to a matrix control of signed 32-bit values. Valid if + this control is of type ``V4L2_CTRL_TYPE_INTEGER`` and + ``V4L2_CTRL_FLAG_HAS_PAYLOAD`` is set. + * - __u32 * + - ``p_s64`` + - A pointer to a matrix control of signed 64-bit values. Valid if + this control is of type ``V4L2_CTRL_TYPE_INTEGER64`` and + ``V4L2_CTRL_FLAG_HAS_PAYLOAD`` is set. * - struct :c:type:`v4l2_area` * - ``p_area`` - A pointer to a struct :c:type:`v4l2_area`. Valid if this control is diff --git a/Documentation/userspace-api/media/v4l/vidioc-g-fbuf.rst b/Documentation/userspace-api/media/v4l/vidioc-g-fbuf.rst index b6cc1a823207..b651e53643dd 100644 --- a/Documentation/userspace-api/media/v4l/vidioc-g-fbuf.rst +++ b/Documentation/userspace-api/media/v4l/vidioc-g-fbuf.rst @@ -49,6 +49,9 @@ of a graphics card. A non-destructive overlay blends video images into a VGA signal or graphics into a video signal. *Video Output Overlays* are always non-destructive. +Destructive overlay support has been removed: with modern GPUs and CPUs +this is no longer needed, and it was always a very dangerous feature. + To get the current parameters applications call the :ref:`VIDIOC_G_FBUF <VIDIOC_G_FBUF>` ioctl with a pointer to a struct :c:type:`v4l2_framebuffer` structure. The driver fills all fields of the structure or returns an @@ -63,18 +66,12 @@ this structure, the driver prepares for the overlay and returns the framebuffer parameters as :ref:`VIDIOC_G_FBUF <VIDIOC_G_FBUF>` does, or it returns an error code. -To set the parameters for a *non-destructive Video Overlay*, +To set the parameters for a *Video Capture Overlay* applications must initialize the ``flags`` field, the ``fmt`` substructure, and call :ref:`VIDIOC_S_FBUF <VIDIOC_G_FBUF>`. Again the driver prepares for the overlay and returns the framebuffer parameters as :ref:`VIDIOC_G_FBUF <VIDIOC_G_FBUF>` does, or it returns an error code. -For a *destructive Video Overlay* applications must additionally provide -a ``base`` address. Setting up a DMA to a random memory location can -jeopardize the system security, its stability or even damage the -hardware, therefore only the superuser can set the parameters for a -destructive video overlay. - .. tabularcolumns:: |p{3.5cm}|p{3.5cm}|p{3.5cm}|p{6.6cm}| .. c:type:: v4l2_framebuffer @@ -100,17 +97,14 @@ destructive video overlay. - ``base`` - - Physical base address of the framebuffer, that is the address of - the pixel in the top left corner of the framebuffer. [#f1]_ - * - - - - - - - This field is irrelevant to *non-destructive Video Overlays*. For - *destructive Video Overlays* applications must provide a base - address. The driver may accept only base addresses which are a - multiple of two, four or eight bytes. For *Video Output Overlays* - the driver must return a valid base address, so applications can + the pixel in the top left corner of the framebuffer. + For :ref:`VIDIOC_S_FBUF <VIDIOC_G_FBUF>` this field is no longer supported + and the kernel will always set this to NULL. + For *Video Output Overlays* + the driver will return a valid base address, so applications can find the corresponding Linux framebuffer device (see - :ref:`osd`). + :ref:`osd`). For *Video Capture Overlays* this field will always be + NULL. * - struct - ``fmt`` - @@ -136,8 +130,7 @@ destructive video overlay. * - - - - - For *destructive Video Overlays* applications must initialize this - field. For *Video Output Overlays* the driver must return a valid + - For *Video Output Overlays* the driver must return a valid format. * - - @@ -165,13 +158,6 @@ destructive video overlay. This field is irrelevant to *non-destructive Video Overlays*. - For *destructive Video Overlays* both applications and drivers can - set this field to request padding bytes at the end of each line. - Drivers however may ignore the requested value, returning - ``width`` times bytes-per-pixel or a larger value required by the - hardware. That implies applications can just set this field to - zero to get a reasonable default. - For *Video Output Overlays* the driver must return a valid value. Video hardware may access padding bytes, therefore they must @@ -190,9 +176,8 @@ destructive video overlay. * - - __u32 - ``sizeimage`` - - This field is irrelevant to *non-destructive Video Overlays*. For - *destructive Video Overlays* applications must initialize this - field. For *Video Output Overlays* the driver must return a valid + - This field is irrelevant to *non-destructive Video Overlays*. + For *Video Output Overlays* the driver must return a valid format. Together with ``base`` it defines the framebuffer memory @@ -232,9 +217,11 @@ destructive video overlay. * - ``V4L2_FBUF_CAP_LIST_CLIPPING`` - 0x0004 - The device supports clipping using a list of clip rectangles. + Note that this is no longer supported. * - ``V4L2_FBUF_CAP_BITMAP_CLIPPING`` - 0x0008 - The device supports clipping using a bit mask. + Note that this is no longer supported. * - ``V4L2_FBUF_CAP_LOCAL_ALPHA`` - 0x0010 - The device supports clipping/blending using the alpha channel of @@ -342,10 +329,3 @@ EPERM EINVAL The :ref:`VIDIOC_S_FBUF <VIDIOC_G_FBUF>` parameters are unsuitable. - -.. [#f1] - A physical base address may not suit all platforms. GK notes in - theory we should pass something like PCI device + memory region + - offset instead. If you encounter problems please discuss on the - linux-media mailing list: - `https://linuxtv.org/lists.php <https://linuxtv.org/lists.php>`__. diff --git a/Documentation/userspace-api/media/v4l/vidioc-subdev-enum-frame-size.rst b/Documentation/userspace-api/media/v4l/vidioc-subdev-enum-frame-size.rst index 3ef361c0dca7..e3ae84df5486 100644 --- a/Documentation/userspace-api/media/v4l/vidioc-subdev-enum-frame-size.rst +++ b/Documentation/userspace-api/media/v4l/vidioc-subdev-enum-frame-size.rst @@ -31,18 +31,30 @@ Arguments Description =========== -This ioctl allows applications to enumerate all frame sizes supported by -a sub-device on the given pad for the given media bus format. Supported -formats can be retrieved with the +This ioctl allows applications to access the enumeration of frame sizes +supported by a sub-device on the specified pad +for the specified media bus format. +Supported formats can be retrieved with the :ref:`VIDIOC_SUBDEV_ENUM_MBUS_CODE` ioctl. -To enumerate frame sizes applications initialize the ``pad``, ``which`` -, ``code`` and ``index`` fields of the struct -:c:type:`v4l2_subdev_mbus_code_enum` and -call the :ref:`VIDIOC_SUBDEV_ENUM_FRAME_SIZE` ioctl with a pointer to the -structure. Drivers fill the minimum and maximum frame sizes or return an -EINVAL error code if one of the input parameters is invalid. +The enumerations are defined by the driver, and indexed using the ``index`` field +of the struct :c:type:`v4l2_subdev_frame_size_enum`. +Each pair of ``pad`` and ``code`` correspond to a separate enumeration. +Each enumeration starts with the ``index`` of 0, and +the lowest invalid index marks the end of the enumeration. + +Therefore, to enumerate frame sizes allowed on the specified pad +and using the specified mbus format, initialize the +``pad``, ``which``, and ``code`` fields to desired values, +and set ``index`` to 0. +Then call the :ref:`VIDIOC_SUBDEV_ENUM_FRAME_SIZE` ioctl with a pointer to the +structure. + +A successful call will return with minimum and maximum frame sizes filled in. +Repeat with increasing ``index`` until ``EINVAL`` is received. +``EINVAL`` means that either no more entries are available in the enumeration, +or that an input parameter was invalid. Sub-devices that only support discrete frame sizes (such as most sensors) will return one or more frame sizes with identical minimum and @@ -72,26 +84,28 @@ information about try formats. * - __u32 - ``index`` - - Number of the format in the enumeration, set by the application. + - Index of the frame size in the enumeration belonging to the given pad + and format. Filled in by the application. * - __u32 - ``pad`` - Pad number as reported by the media controller API. + Filled in by the application. * - __u32 - ``code`` - The media bus format code, as defined in - :ref:`v4l2-mbus-format`. + :ref:`v4l2-mbus-format`. Filled in by the application. * - __u32 - ``min_width`` - - Minimum frame width, in pixels. + - Minimum frame width, in pixels. Filled in by the driver. * - __u32 - ``max_width`` - - Maximum frame width, in pixels. + - Maximum frame width, in pixels. Filled in by the driver. * - __u32 - ``min_height`` - - Minimum frame height, in pixels. + - Minimum frame height, in pixels. Filled in by the driver. * - __u32 - ``max_height`` - - Maximum frame height, in pixels. + - Maximum frame height, in pixels. Filled in by the driver. * - __u32 - ``which`` - Frame sizes to be enumerated, from enum diff --git a/Documentation/userspace-api/media/v4l/vidioc-subdev-enum-mbus-code.rst b/Documentation/userspace-api/media/v4l/vidioc-subdev-enum-mbus-code.rst index 248f6f9ee7c5..4ad7dec27e25 100644 --- a/Documentation/userspace-api/media/v4l/vidioc-subdev-enum-mbus-code.rst +++ b/Documentation/userspace-api/media/v4l/vidioc-subdev-enum-mbus-code.rst @@ -31,15 +31,28 @@ Arguments Description =========== -To enumerate media bus formats available at a given sub-device pad -applications initialize the ``pad``, ``which`` and ``index`` fields of -struct -:c:type:`v4l2_subdev_mbus_code_enum` and -call the :ref:`VIDIOC_SUBDEV_ENUM_MBUS_CODE` ioctl with a pointer to this -structure. Drivers fill the rest of the structure or return an ``EINVAL`` -error code if either the ``pad`` or ``index`` are invalid. All media bus -formats are enumerable by beginning at index zero and incrementing by -one until ``EINVAL`` is returned. +This call is used by the application to access the enumeration +of media bus formats for the selected pad. + +The enumerations are defined by the driver, and indexed using the ``index`` field +of struct :c:type:`v4l2_subdev_mbus_code_enum`. +Each enumeration starts with the ``index`` of 0, and +the lowest invalid index marks the end of enumeration. + +Therefore, to enumerate media bus formats available at a given sub-device pad, +initialize the ``pad``, and ``which`` fields to desired values, +and set ``index`` to 0. +Then call the :ref:`VIDIOC_SUBDEV_ENUM_MBUS_CODE` ioctl +with a pointer to this structure. + +A successful call will return with the ``code`` field filled in +with a mbus code value. +Repeat with increasing ``index`` until ``EINVAL`` is received. +``EINVAL`` means that either ``pad`` is invalid, +or that there are no more codes available at this pad. + +The driver must not return the same value of ``code`` for different indices +at the same pad. Available media bus formats may depend on the current 'try' formats at other pads of the sub-device, as well as on the current active links. @@ -57,14 +70,16 @@ information about the try formats. * - __u32 - ``pad`` - - Pad number as reported by the media controller API. + - Pad number as reported by the media controller API. Filled in by the + application. * - __u32 - ``index`` - - Number of the format in the enumeration, set by the application. + - Index of the mbus code in the enumeration belonging to the given pad. + Filled in by the application. * - __u32 - ``code`` - The media bus format code, as defined in - :ref:`v4l2-mbus-format`. + :ref:`v4l2-mbus-format`. Filled in by the driver. * - __u32 - ``which`` - Media bus format codes to be enumerated, from enum diff --git a/Documentation/userspace-api/media/v4l/vidioc-subdev-g-client-cap.rst b/Documentation/userspace-api/media/v4l/vidioc-subdev-g-client-cap.rst new file mode 100644 index 000000000000..20f12a1cc0f7 --- /dev/null +++ b/Documentation/userspace-api/media/v4l/vidioc-subdev-g-client-cap.rst @@ -0,0 +1,83 @@ +.. SPDX-License-Identifier: GFDL-1.1-no-invariants-or-later +.. c:namespace:: V4L + +.. _VIDIOC_SUBDEV_G_CLIENT_CAP: + +************************************************************ +ioctl VIDIOC_SUBDEV_G_CLIENT_CAP, VIDIOC_SUBDEV_S_CLIENT_CAP +************************************************************ + +Name +==== + +VIDIOC_SUBDEV_G_CLIENT_CAP - VIDIOC_SUBDEV_S_CLIENT_CAP - Get or set client +capabilities. + +Synopsis +======== + +.. c:macro:: VIDIOC_SUBDEV_G_CLIENT_CAP + +``int ioctl(int fd, VIDIOC_SUBDEV_G_CLIENT_CAP, struct v4l2_subdev_client_capability *argp)`` + +.. c:macro:: VIDIOC_SUBDEV_S_CLIENT_CAP + +``int ioctl(int fd, VIDIOC_SUBDEV_S_CLIENT_CAP, struct v4l2_subdev_client_capability *argp)`` + +Arguments +========= + +``fd`` + File descriptor returned by :ref:`open() <func-open>`. + +``argp`` + Pointer to struct :c:type:`v4l2_subdev_client_capability`. + +Description +=========== + +These ioctls are used to get and set the client (the application using the +subdevice ioctls) capabilities. The client capabilities are stored in the file +handle of the opened subdev device node, and the client must set the +capabilities for each opened subdev separately. + +By default no client capabilities are set when a subdev device node is opened. + +The purpose of the client capabilities are to inform the kernel of the behavior +of the client, mainly related to maintaining compatibility with different +kernel and userspace versions. + +The ``VIDIOC_SUBDEV_G_CLIENT_CAP`` ioctl returns the current client capabilities +associated with the file handle ``fd``. + +The ``VIDIOC_SUBDEV_S_CLIENT_CAP`` ioctl sets client capabilities for the file +handle ``fd``. The new capabilities fully replace the current capabilities, the +ioctl can therefore also be used to remove capabilities that have previously +been set. + +``VIDIOC_SUBDEV_S_CLIENT_CAP`` modifies the struct +:c:type:`v4l2_subdev_client_capability` to reflect the capabilities that have +been accepted. A common case for the kernel not accepting a capability is that +the kernel is older than the headers the userspace uses, and thus the capability +is unknown to the kernel. + +.. flat-table:: Client Capabilities + :header-rows: 1 + + * - Capability + - Description + * - ``V4L2_SUBDEV_CLIENT_CAP_STREAMS`` + - The client is aware of streams. Setting this flag enables the use + of 'stream' fields (referring to the stream number) with various + ioctls. If this is not set (which is the default), the 'stream' fields + will be forced to 0 by the kernel. + +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. + +ENOIOCTLCMD + The kernel does not support this ioctl. diff --git a/Documentation/virt/coco/sev-guest.rst b/Documentation/virt/coco/sev-guest.rst index bf593e88cfd9..68b0d2363af8 100644 --- a/Documentation/virt/coco/sev-guest.rst +++ b/Documentation/virt/coco/sev-guest.rst @@ -37,11 +37,11 @@ along with a description: the return value. General error numbers (-ENOMEM, -EINVAL) are not detailed, but errors with specific meanings are. -The guest ioctl should be issued on a file descriptor of the /dev/sev-guest device. -The ioctl accepts struct snp_user_guest_request. The input and output structure is -specified through the req_data and resp_data field respectively. If the ioctl fails -to execute due to a firmware error, then fw_err code will be set otherwise the -fw_err will be set to 0x00000000000000ff. +The guest ioctl should be issued on a file descriptor of the /dev/sev-guest +device. The ioctl accepts struct snp_user_guest_request. The input and +output structure is specified through the req_data and resp_data field +respectively. If the ioctl fails to execute due to a firmware error, then +the fw_error code will be set, otherwise fw_error will be set to -1. The firmware checks that the message sequence counter is one greater than the guests message sequence counter. If guest driver fails to increment message @@ -57,8 +57,14 @@ counter (e.g. counter overflow), then -EIO will be returned. __u64 req_data; __u64 resp_data; - /* firmware error code on failure (see psp-sev.h) */ - __u64 fw_err; + /* bits[63:32]: VMM error code, bits[31:0] firmware error code (see psp-sev.h) */ + union { + __u64 exitinfo2; + struct { + __u32 fw_error; + __u32 vmm_error; + }; + }; }; 2.1 SNP_GET_REPORT diff --git a/Documentation/virt/kvm/api.rst b/Documentation/virt/kvm/api.rst index 62de0768d6aa..841e9d1987bd 100644 --- a/Documentation/virt/kvm/api.rst +++ b/Documentation/virt/kvm/api.rst @@ -7456,7 +7456,7 @@ system fingerprint. To prevent userspace from circumventing such restrictions by running an enclave in a VM, KVM prevents access to privileged attributes by default. -See Documentation/x86/sgx.rst for more details. +See Documentation/arch/x86/sgx.rst for more details. 7.26 KVM_CAP_PPC_RPT_INVALIDATE ------------------------------- @@ -8296,11 +8296,11 @@ ENOSYS for the others. 8.35 KVM_CAP_PMU_CAPABILITY --------------------------- -:Capability KVM_CAP_PMU_CAPABILITY +:Capability: KVM_CAP_PMU_CAPABILITY :Architectures: x86 :Type: vm :Parameters: arg[0] is bitmask of PMU virtualization capabilities. -:Returns 0 on success, -EINVAL when arg[0] contains invalid bits +:Returns: 0 on success, -EINVAL when arg[0] contains invalid bits This capability alters PMU virtualization in KVM. |