diff options
Diffstat (limited to 'Documentation')
197 files changed, 9734 insertions, 2804 deletions
diff --git a/Documentation/ABI/testing/debugfs-hisi-hpre b/Documentation/ABI/testing/debugfs-hisi-hpre index 396de7bc735d..82abf92df429 100644 --- a/Documentation/ABI/testing/debugfs-hisi-hpre +++ b/Documentation/ABI/testing/debugfs-hisi-hpre @@ -104,6 +104,20 @@ Description: Dump the status of the QM. Four states: initiated, started, stopped and closed. Available for both PF and VF, and take no other effect on HPRE. +What: /sys/kernel/debug/hisi_hpre/<bdf>/qm/diff_regs +Date: Mar 2022 +Contact: linux-crypto@vger.kernel.org +Description: QM debug registers(regs) read hardware register value. This + node is used to show the change of the qm register values. This + node can be help users to check the change of register values. + +What: /sys/kernel/debug/hisi_hpre/<bdf>/hpre_dfx/diff_regs +Date: Mar 2022 +Contact: linux-crypto@vger.kernel.org +Description: HPRE debug registers(regs) read hardware register value. This + node is used to show the change of the register values. This + node can be help users to check the change of register values. + What: /sys/kernel/debug/hisi_hpre/<bdf>/hpre_dfx/send_cnt Date: Apr 2020 Contact: linux-crypto@vger.kernel.org diff --git a/Documentation/ABI/testing/debugfs-hisi-sec b/Documentation/ABI/testing/debugfs-hisi-sec index 2bf84ced484b..93c530d1bf0f 100644 --- a/Documentation/ABI/testing/debugfs-hisi-sec +++ b/Documentation/ABI/testing/debugfs-hisi-sec @@ -84,6 +84,20 @@ Description: Dump the status of the QM. Four states: initiated, started, stopped and closed. Available for both PF and VF, and take no other effect on SEC. +What: /sys/kernel/debug/hisi_sec2/<bdf>/qm/diff_regs +Date: Mar 2022 +Contact: linux-crypto@vger.kernel.org +Description: QM debug registers(regs) read hardware register value. This + node is used to show the change of the qm register values. This + node can be help users to check the change of register values. + +What: /sys/kernel/debug/hisi_sec2/<bdf>/sec_dfx/diff_regs +Date: Mar 2022 +Contact: linux-crypto@vger.kernel.org +Description: SEC debug registers(regs) read hardware register value. This + node is used to show the change of the register values. This + node can be help users to check the change of register values. + What: /sys/kernel/debug/hisi_sec2/<bdf>/sec_dfx/send_cnt Date: Apr 2020 Contact: linux-crypto@vger.kernel.org diff --git a/Documentation/ABI/testing/debugfs-hisi-zip b/Documentation/ABI/testing/debugfs-hisi-zip index bf1258bc6495..fd3f314cf8d1 100644 --- a/Documentation/ABI/testing/debugfs-hisi-zip +++ b/Documentation/ABI/testing/debugfs-hisi-zip @@ -97,6 +97,20 @@ Description: Dump the status of the QM. Four states: initiated, started, stopped and closed. Available for both PF and VF, and take no other effect on ZIP. +What: /sys/kernel/debug/hisi_zip/<bdf>/qm/diff_regs +Date: Mar 2022 +Contact: linux-crypto@vger.kernel.org +Description: QM debug registers(regs) read hardware register value. This + node is used to show the change of the qm registers value. This + node can be help users to check the change of register values. + +What: /sys/kernel/debug/hisi_zip/<bdf>/zip_dfx/diff_regs +Date: Mar 2022 +Contact: linux-crypto@vger.kernel.org +Description: ZIP debug registers(regs) read hardware register value. This + node is used to show the change of the registers value. this + node can be help users to check the change of register values. + What: /sys/kernel/debug/hisi_zip/<bdf>/zip_dfx/send_cnt Date: Apr 2020 Contact: linux-crypto@vger.kernel.org diff --git a/Documentation/ABI/testing/sysfs-class-cxl b/Documentation/ABI/testing/sysfs-class-cxl index 3c77677e0ca7..594fda254130 100644 --- a/Documentation/ABI/testing/sysfs-class-cxl +++ b/Documentation/ABI/testing/sysfs-class-cxl @@ -103,8 +103,8 @@ What: /sys/class/cxl/<afu>/api_version_compatible Date: September 2014 Contact: linuxppc-dev@lists.ozlabs.org Description: read only - Decimal value of the the lowest version of the userspace API - this this kernel supports. + Decimal value of the lowest version of the userspace API + this kernel supports. Users: https://github.com/ibm-capi/libcxl diff --git a/Documentation/ABI/testing/sysfs-driver-ccp b/Documentation/ABI/testing/sysfs-driver-ccp new file mode 100644 index 000000000000..7aded9b75553 --- /dev/null +++ b/Documentation/ABI/testing/sysfs-driver-ccp @@ -0,0 +1,87 @@ +What: /sys/bus/pci/devices/<BDF>/fused_part +Date: June 2022 +KernelVersion: 5.19 +Contact: mario.limonciello@amd.com +Description: + The /sys/bus/pci/devices/<BDF>/fused_part file reports + whether the CPU or APU has been fused to prevent tampering. + 0: Not fused + 1: Fused + +What: /sys/bus/pci/devices/<BDF>/debug_lock_on +Date: June 2022 +KernelVersion: 5.19 +Contact: mario.limonciello@amd.com +Description: + The /sys/bus/pci/devices/<BDF>/debug_lock_on reports + whether the AMD CPU or APU has been unlocked for debugging. + Possible values: + 0: Not locked + 1: Locked + +What: /sys/bus/pci/devices/<BDF>/tsme_status +Date: June 2022 +KernelVersion: 5.19 +Contact: mario.limonciello@amd.com +Description: + The /sys/bus/pci/devices/<BDF>/tsme_status file reports + the status of transparent secure memory encryption on AMD systems. + Possible values: + 0: Not active + 1: Active + +What: /sys/bus/pci/devices/<BDF>/anti_rollback_status +Date: June 2022 +KernelVersion: 5.19 +Contact: mario.limonciello@amd.com +Description: + The /sys/bus/pci/devices/<BDF>/anti_rollback_status file reports + whether the PSP is enforcing rollback protection. + Possible values: + 0: Not enforcing + 1: Enforcing + +What: /sys/bus/pci/devices/<BDF>/rpmc_production_enabled +Date: June 2022 +KernelVersion: 5.19 +Contact: mario.limonciello@amd.com +Description: + The /sys/bus/pci/devices/<BDF>/rpmc_production_enabled file reports + whether Replay Protected Monotonic Counter support has been enabled. + Possible values: + 0: Not enabled + 1: Enabled + +What: /sys/bus/pci/devices/<BDF>/rpmc_spirom_available +Date: June 2022 +KernelVersion: 5.19 +Contact: mario.limonciello@amd.com +Description: + The /sys/bus/pci/devices/<BDF>/rpmc_spirom_available file reports + whether an Replay Protected Monotonic Counter supported SPI is installed + on the system. + Possible values: + 0: Not present + 1: Present + +What: /sys/bus/pci/devices/<BDF>/hsp_tpm_available +Date: June 2022 +KernelVersion: 5.19 +Contact: mario.limonciello@amd.com +Description: + The /sys/bus/pci/devices/<BDF>/hsp_tpm_available file reports + whether the HSP TPM has been activated. + Possible values: + 0: Not activated or present + 1: Activated + +What: /sys/bus/pci/devices/<BDF>/rom_armor_enforced +Date: June 2022 +KernelVersion: 5.19 +Contact: mario.limonciello@amd.com +Description: + The /sys/bus/pci/devices/<BDF>/rom_armor_enforced file reports + whether RomArmor SPI protection is enforced. + Possible values: + 0: Not enforced + 1: Enforced diff --git a/Documentation/ABI/testing/sysfs-driver-chromeos-acpi b/Documentation/ABI/testing/sysfs-driver-chromeos-acpi new file mode 100644 index 000000000000..c308926e1568 --- /dev/null +++ b/Documentation/ABI/testing/sysfs-driver-chromeos-acpi @@ -0,0 +1,137 @@ +What: /sys/bus/platform/devices/GGL0001:*/BINF.2 +Date: May 2022 +KernelVersion: 5.19 +Description: + Returns active EC firmware of current boot (boolean). + + == =============================== + 0 Read only (recovery) firmware. + 1 Rewritable firmware. + == =============================== + +What: /sys/bus/platform/devices/GGL0001:*/BINF.3 +Date: May 2022 +KernelVersion: 5.19 +Description: + Returns main firmware type for current boot (integer). + + == ===================================== + 0 Recovery. + 1 Normal. + 2 Developer. + 3 Netboot (factory installation only). + == ===================================== + +What: /sys/bus/platform/devices/GGL0001:*/CHSW +Date: May 2022 +KernelVersion: 5.19 +Description: + Returns switch position for Chrome OS specific hardware + switches when the firmware is booted (integer). + + ==== =========================================== + 0 No changes. + 2 Recovery button was pressed. + 4 Recovery button was pressed (EC firmware). + 32 Developer switch was enabled. + 512 Firmware write protection was disabled. + ==== =========================================== + +What: /sys/bus/platform/devices/GGL0001:*/FMAP +Date: May 2022 +KernelVersion: 5.19 +Description: + Returns physical memory address of the start of the main + processor firmware flashmap. + +What: /sys/bus/platform/devices/GGL0001:*/FRID +Date: May 2022 +KernelVersion: 5.19 +Description: + Returns firmware version for the read-only portion of the + main processor firmware. + +What: /sys/bus/platform/devices/GGL0001:*/FWID +Date: May 2022 +KernelVersion: 5.19 +Description: + Returns firmware version for the rewritable portion of the + main processor firmware. + +What: /sys/bus/platform/devices/GGL0001:*/GPIO.X/GPIO.0 +Date: May 2022 +KernelVersion: 5.19 +Description: + Returns type of the GPIO signal for the Chrome OS specific + GPIO assignments (integer). + + =========== ================================== + 1 Recovery button. + 2 Developer mode switch. + 3 Firmware write protection switch. + 256 to 511 Debug header GPIO 0 to GPIO 255. + =========== ================================== + +What: /sys/bus/platform/devices/GGL0001:*/GPIO.X/GPIO.1 +Date: May 2022 +KernelVersion: 5.19 +Description: + Returns signal attributes of the GPIO signal (integer bitfield). + + == ======================= + 0 Signal is active low. + 1 Signal is active high. + == ======================= + +What: /sys/bus/platform/devices/GGL0001:*/GPIO.X/GPIO.2 +Date: May 2022 +KernelVersion: 5.19 +Description: + Returns the GPIO number on the specified GPIO + controller. + +What: /sys/bus/platform/devices/GGL0001:*/GPIO.X/GPIO.3 +Date: May 2022 +KernelVersion: 5.19 +Description: + Returns name of the GPIO controller. + +What: /sys/bus/platform/devices/GGL0001:*/HWID +Date: May 2022 +KernelVersion: 5.19 +Description: + Returns hardware ID for the Chromebook. + +What: /sys/bus/platform/devices/GGL0001:*/MECK +Date: May 2022 +KernelVersion: 5.19 +Description: + Returns the SHA-1 or SHA-256 hash that is read out of the + Management Engine extended registers during boot. The hash + is exported via ACPI so the OS can verify that the Management + Engine firmware has not changed. If Management Engine is not + present, or if the firmware was unable to read the extended registers, this buffer size can be zero. + +What: /sys/bus/platform/devices/GGL0001:*/VBNV.0 +Date: May 2022 +KernelVersion: 5.19 +Description: + Returns offset in CMOS bank 0 of the verified boot non-volatile + storage block, counting from the first writable CMOS byte + (that is, 'offset = 0' is the byte following the 14 bytes of + clock data). + +What: /sys/bus/platform/devices/GGL0001:*/VBNV.1 +Date: May 2022 +KernelVersion: 5.19 +Description: + Return the size in bytes of the verified boot non-volatile + storage block. + +What: /sys/bus/platform/devices/GGL0001:*/VDAT +Date: May 2022 +KernelVersion: 5.19 +Description: + Returns the verified boot data block shared between the + firmware verification step and the kernel verification step + (binary). diff --git a/Documentation/ABI/testing/sysfs-kernel-mm-damon b/Documentation/ABI/testing/sysfs-kernel-mm-damon index 9e282065cbcf..08b9df323560 100644 --- a/Documentation/ABI/testing/sysfs-kernel-mm-damon +++ b/Documentation/ABI/testing/sysfs-kernel-mm-damon @@ -23,9 +23,10 @@ Date: Mar 2022 Contact: SeongJae Park <sj@kernel.org> Description: Writing 'on' or 'off' to this file makes the kdamond starts or stops, respectively. Reading the file returns the keywords - based on the current status. Writing 'update_schemes_stats' to - the file updates contents of schemes stats files of the - kdamond. + based on the current status. Writing 'commit' to this file + makes the kdamond reads the user inputs in the sysfs files + except 'state' again. Writing 'update_schemes_stats' to the + file updates contents of schemes stats files of the kdamond. What: /sys/kernel/mm/damon/admin/kdamonds/<K>/pid Date: Mar 2022 @@ -40,14 +41,24 @@ Description: Writing a number 'N' to this file creates the number of directories for controlling each DAMON context named '0' to 'N-1' under the contexts/ directory. +What: /sys/kernel/mm/damon/admin/kdamonds/<K>/contexts/<C>/avail_operations +Date: Apr 2022 +Contact: SeongJae Park <sj@kernel.org> +Description: Reading this file returns the available monitoring operations + sets on the currently running kernel. + What: /sys/kernel/mm/damon/admin/kdamonds/<K>/contexts/<C>/operations Date: Mar 2022 Contact: SeongJae Park <sj@kernel.org> Description: Writing a keyword for a monitoring operations set ('vaddr' for - virtual address spaces monitoring, and 'paddr' for the physical - address space monitoring) to this file makes the context to use - the operations set. Reading the file returns the keyword for - the operations set the context is set to use. + virtual address spaces monitoring, 'fvaddr' for fixed virtual + address ranges monitoring, and 'paddr' for the physical address + space monitoring) to this file makes the context to use the + operations set. Reading the file returns the keyword for the + operations set the context is set to use. + + Note that only the operations sets that listed in + 'avail_operations' file are valid inputs. What: /sys/kernel/mm/damon/admin/kdamonds/<K>/contexts/<C>/monitoring_attrs/intervals/sample_us Date: Mar 2022 diff --git a/Documentation/PCI/pci.rst b/Documentation/PCI/pci.rst index 67a850b55617..cced568d78e9 100644 --- a/Documentation/PCI/pci.rst +++ b/Documentation/PCI/pci.rst @@ -273,12 +273,12 @@ Set the DMA mask size While all drivers should explicitly indicate the DMA capability (e.g. 32 or 64 bit) of the PCI bus master, devices with more than 32-bit bus master capability for streaming data need the driver -to "register" this capability by calling pci_set_dma_mask() with +to "register" this capability by calling dma_set_mask() with appropriate parameters. In general this allows more efficient DMA on systems where System RAM exists above 4G _physical_ address. Drivers for all PCI-X and PCIe compliant devices must call -set_dma_mask() as they are 64-bit DMA devices. +dma_set_mask() as they are 64-bit DMA devices. Similarly, drivers must also "register" this capability if the device can directly address "coherent memory" in System RAM above 4G physical diff --git a/Documentation/admin-guide/blockdev/zram.rst b/Documentation/admin-guide/blockdev/zram.rst index 54fe63745ed8..c73b16930449 100644 --- a/Documentation/admin-guide/blockdev/zram.rst +++ b/Documentation/admin-guide/blockdev/zram.rst @@ -343,6 +343,11 @@ Admin can request writeback of those idle pages at right timing via:: With the command, zram will writeback idle pages from memory to the storage. +Additionally, if a user choose to writeback only huge and idle pages +this can be accomplished with:: + + echo huge_idle > /sys/block/zramX/writeback + If an admin wants to write a specific page in zram device to the backing device, they could write a page index into the interface. diff --git a/Documentation/admin-guide/bootconfig.rst b/Documentation/admin-guide/bootconfig.rst index a1860fc0ca88..d99994345d41 100644 --- a/Documentation/admin-guide/bootconfig.rst +++ b/Documentation/admin-guide/bootconfig.rst @@ -158,9 +158,15 @@ Each key-value pair is shown in each line with following style:: Boot Kernel With a Boot Config ============================== -Since the boot configuration file is loaded with initrd, it will be added -to the end of the initrd (initramfs) image file with padding, size, -checksum and 12-byte magic word as below. +There are two options to boot the kernel with bootconfig: attaching the +bootconfig to the initrd image or embedding it in the kernel itself. + +Attaching a Boot Config to Initrd +--------------------------------- + +Since the boot configuration file is loaded with initrd by default, +it will be added to the end of the initrd (initramfs) image file with +padding, size, checksum and 12-byte magic word as below. [initrd][bootconfig][padding][size(le32)][checksum(le32)][#BOOTCONFIG\n] @@ -196,6 +202,25 @@ To remove the config from the image, you can use -d option as below:: Then add "bootconfig" on the normal kernel command line to tell the kernel to look for the bootconfig at the end of the initrd file. +Embedding a Boot Config into Kernel +----------------------------------- + +If you can not use initrd, you can also embed the bootconfig file in the +kernel by Kconfig options. In this case, you need to recompile the kernel +with the following configs:: + + CONFIG_BOOT_CONFIG_EMBED=y + CONFIG_BOOT_CONFIG_EMBED_FILE="/PATH/TO/BOOTCONFIG/FILE" + +``CONFIG_BOOT_CONFIG_EMBED_FILE`` requires an absolute path or a relative +path to the bootconfig file from source tree or object tree. +The kernel will embed it as the default bootconfig. + +Just as when attaching the bootconfig to the initrd, you need ``bootconfig`` +option on the kernel command line to enable the embedded bootconfig. + +Note that even if you set this option, you can override the embedded +bootconfig by another bootconfig which attached to the initrd. Kernel parameters via Boot Config ================================= diff --git a/Documentation/admin-guide/cgroup-v2.rst b/Documentation/admin-guide/cgroup-v2.rst index 38aa01939e1e..176298f2f4de 100644 --- a/Documentation/admin-guide/cgroup-v2.rst +++ b/Documentation/admin-guide/cgroup-v2.rst @@ -1208,6 +1208,34 @@ PAGE_SIZE multiple when read back. high limit is used and monitored properly, this limit's utility is limited to providing the final safety net. + memory.reclaim + A write-only nested-keyed file which exists for all cgroups. + + This is a simple interface to trigger memory reclaim in the + target cgroup. + + This file accepts a single key, the number of bytes to reclaim. + No nested keys are currently supported. + + Example:: + + echo "1G" > memory.reclaim + + The interface can be later extended with nested keys to + configure the reclaim behavior. For example, specify the + type of memory to reclaim from (anon, file, ..). + + Please note that the kernel can over or under reclaim from + the target cgroup. If less bytes are reclaimed than the + specified amount, -EAGAIN is returned. + + memory.peak + A read-only single value file which exists on non-root + cgroups. + + The max memory usage recorded for the cgroup and its + descendants since the creation of the cgroup. + memory.oom.group A read-write single value file which exists on non-root cgroups. The default value is "0". @@ -1326,6 +1354,12 @@ PAGE_SIZE multiple when read back. Amount of cached filesystem data that is swap-backed, such as tmpfs, shm segments, shared anonymous mmap()s + zswap + Amount of memory consumed by the zswap compression backend. + + zswapped + Amount of application memory swapped out to zswap. + file_mapped Amount of cached filesystem data mapped with mmap() @@ -1516,6 +1550,21 @@ PAGE_SIZE multiple when read back. higher than the limit for an extended period of time. This reduces the impact on the workload and memory management. + memory.zswap.current + A read-only single value file which exists on non-root + cgroups. + + The total amount of memory consumed by the zswap compression + backend. + + memory.zswap.max + A read-write single value file which exists on non-root + cgroups. The default is "max". + + Zswap usage hard limit. If a cgroup's zswap pool reaches this + limit, it will refuse to take any more stores before existing + entries fault back in or are written out to disk. + memory.pressure A read-only nested-keyed file. diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt index a9066cfb85a0..710b52d87bdd 100644 --- a/Documentation/admin-guide/kernel-parameters.txt +++ b/Documentation/admin-guide/kernel-parameters.txt @@ -1705,16 +1705,16 @@ boot-time allocation of gigantic hugepages is skipped. hugetlb_free_vmemmap= - [KNL] Reguires CONFIG_HUGETLB_PAGE_FREE_VMEMMAP + [KNL] Reguires CONFIG_HUGETLB_PAGE_OPTIMIZE_VMEMMAP enabled. Allows heavy hugetlb users to free up some more memory (7 * PAGE_SIZE for each 2MB hugetlb page). - Format: { on | off (default) } + Format: { [oO][Nn]/Y/y/1 | [oO][Ff]/N/n/0 (default) } - on: enable the feature - off: disable the feature + [oO][Nn]/Y/y/1: enable the feature + [oO][Ff]/N/n/0: disable the feature - Built with CONFIG_HUGETLB_PAGE_FREE_VMEMMAP_DEFAULT_ON=y, + Built with CONFIG_HUGETLB_PAGE_OPTIMIZE_VMEMMAP_DEFAULT_ON=y, the default is on. This is not compatible with memory_hotplug.memmap_on_memory. @@ -4099,6 +4099,15 @@ please report a bug. nocrs [X86] Ignore PCI host bridge windows from ACPI. If you need to use this, please report a bug. + use_e820 [X86] Use E820 reservations to exclude parts of + PCI host bridge windows. This is a workaround + for BIOS defects in host bridge _CRS methods. + If you need to use this, please report a bug to + <linux-pci@vger.kernel.org>. + no_e820 [X86] Ignore E820 reservations for PCI host + bridge windows. This is the default on modern + hardware. If you need to use this, please report + a bug to <linux-pci@vger.kernel.org>. routeirq Do IRQ routing for all PCI devices. This is normally done in pci_enable_device(), so this option is a temporary workaround diff --git a/Documentation/admin-guide/mm/damon/reclaim.rst b/Documentation/admin-guide/mm/damon/reclaim.rst index 0af51a9705b1..46306f1f34b1 100644 --- a/Documentation/admin-guide/mm/damon/reclaim.rst +++ b/Documentation/admin-guide/mm/damon/reclaim.rst @@ -66,6 +66,17 @@ Setting it as ``N`` disables DAMON_RECLAIM. Note that DAMON_RECLAIM could do no real monitoring and reclamation due to the watermarks-based activation condition. Refer to below descriptions for the watermarks parameter for this. +commit_inputs +------------- + +Make DAMON_RECLAIM reads the input parameters again, except ``enabled``. + +Input parameters that updated while DAMON_RECLAIM is running are not applied +by default. Once this parameter is set as ``Y``, DAMON_RECLAIM reads values +of parametrs except ``enabled`` again. Once the re-reading is done, this +parameter is set as ``N``. If invalid parameters are found while the +re-reading, DAMON_RECLAIM will be disabled. + min_age ------- diff --git a/Documentation/admin-guide/mm/damon/usage.rst b/Documentation/admin-guide/mm/damon/usage.rst index 592ea9a50881..1bb7b72414b2 100644 --- a/Documentation/admin-guide/mm/damon/usage.rst +++ b/Documentation/admin-guide/mm/damon/usage.rst @@ -68,7 +68,7 @@ comma (","). :: │ kdamonds/nr_kdamonds │ │ 0/state,pid │ │ │ contexts/nr_contexts - │ │ │ │ 0/operations + │ │ │ │ 0/avail_operations,operations │ │ │ │ │ monitoring_attrs/ │ │ │ │ │ │ intervals/sample_us,aggr_us,update_us │ │ │ │ │ │ nr_regions/min,max @@ -121,10 +121,11 @@ In each kdamond directory, two files (``state`` and ``pid``) and one directory Reading ``state`` returns ``on`` if the kdamond is currently running, or ``off`` if it is not running. Writing ``on`` or ``off`` makes the kdamond be -in the state. Writing ``update_schemes_stats`` to ``state`` file updates the -contents of stats files for each DAMON-based operation scheme of the kdamond. -For details of the stats, please refer to :ref:`stats section -<sysfs_schemes_stats>`. +in the state. Writing ``commit`` to the ``state`` file makes kdamond reads the +user inputs in the sysfs files except ``state`` file again. Writing +``update_schemes_stats`` to ``state`` file updates the contents of stats files +for each DAMON-based operation scheme of the kdamond. For details of the +stats, please refer to :ref:`stats section <sysfs_schemes_stats>`. If the state is ``on``, reading ``pid`` shows the pid of the kdamond thread. @@ -143,17 +144,28 @@ be written to the file. contexts/<N>/ ------------- -In each context directory, one file (``operations``) and three directories -(``monitoring_attrs``, ``targets``, and ``schemes``) exist. +In each context directory, two files (``avail_operations`` and ``operations``) +and three directories (``monitoring_attrs``, ``targets``, and ``schemes``) +exist. DAMON supports multiple types of monitoring operations, including those for -virtual address space and the physical address space. You can set and get what -type of monitoring operations DAMON will use for the context by writing one of -below keywords to, and reading from the file. +virtual address space and the physical address space. You can get the list of +available monitoring operations set on the currently running kernel by reading +``avail_operations`` file. Based on the kernel configuration, the file will +list some or all of below keywords. - vaddr: Monitor virtual address spaces of specific processes + - fvaddr: Monitor fixed virtual address ranges - paddr: Monitor the physical address space of the system +Please refer to :ref:`regions sysfs directory <sysfs_regions>` for detailed +differences between the operations sets in terms of the monitoring target +regions. + +You can set and get what type of monitoring operations DAMON will use for the +context by writing one of the keywords listed in ``avail_operations`` file and +reading from the ``operations`` file. + contexts/<N>/monitoring_attrs/ ------------------------------ @@ -192,6 +204,8 @@ If you wrote ``vaddr`` to the ``contexts/<N>/operations``, each target should be a process. You can specify the process to DAMON by writing the pid of the process to the ``pid_target`` file. +.. _sysfs_regions: + targets/<N>/regions ------------------- @@ -202,9 +216,10 @@ can be covered. However, users could want to set the initial monitoring region to specific address ranges. In contrast, DAMON do not automatically sets and updates the monitoring target -regions when ``paddr`` monitoring operations set is being used (``paddr`` is -written to the ``contexts/<N>/operations``). Therefore, users should set the -monitoring target regions by themselves in the case. +regions when ``fvaddr`` or ``paddr`` monitoring operations sets are being used +(``fvaddr`` or ``paddr`` have written to the ``contexts/<N>/operations``). +Therefore, users should set the monitoring target regions by themselves in the +cases. For such cases, users can explicitly set the initial monitoring target regions as they want, by writing proper values to the files under this directory. diff --git a/Documentation/admin-guide/mm/hugetlbpage.rst b/Documentation/admin-guide/mm/hugetlbpage.rst index 0166f9de3428..a90330d0a837 100644 --- a/Documentation/admin-guide/mm/hugetlbpage.rst +++ b/Documentation/admin-guide/mm/hugetlbpage.rst @@ -164,7 +164,7 @@ default_hugepagesz will all result in 256 2M huge pages being allocated. Valid default huge page size is architecture dependent. hugetlb_free_vmemmap - When CONFIG_HUGETLB_PAGE_FREE_VMEMMAP is set, this enables freeing + When CONFIG_HUGETLB_PAGE_OPTIMIZE_VMEMMAP is set, this enables optimizing unused vmemmap pages associated with each HugeTLB page. When multiple huge page sizes are supported, ``/proc/sys/vm/nr_hugepages`` diff --git a/Documentation/admin-guide/mm/ksm.rst b/Documentation/admin-guide/mm/ksm.rst index 97d816791aca..b244f0202a03 100644 --- a/Documentation/admin-guide/mm/ksm.rst +++ b/Documentation/admin-guide/mm/ksm.rst @@ -184,6 +184,24 @@ The maximum possible ``pages_sharing/pages_shared`` ratio is limited by the ``max_page_sharing`` tunable. To increase the ratio ``max_page_sharing`` must be increased accordingly. +Monitoring KSM events +===================== + +There are some counters in /proc/vmstat that may be used to monitor KSM events. +KSM might help save memory, it's a tradeoff by may suffering delay on KSM COW +or on swapping in copy. Those events could help users evaluate whether or how +to use KSM. For example, if cow_ksm increases too fast, user may decrease the +range of madvise(, , MADV_MERGEABLE). + +cow_ksm + is incremented every time a KSM page triggers copy on write (COW) + when users try to write to a KSM page, we have to make a copy. + +ksm_swpin_copy + is incremented every time a KSM page is copied when swapping in + note that KSM page might be copied when swapping in because do_swap_page() + cannot do all the locking needed to reconstitute a cross-anon_vma KSM page. + -- Izik Eidus, Hugh Dickins, 17 Nov 2009 diff --git a/Documentation/admin-guide/nfs/nfs-client.rst b/Documentation/admin-guide/nfs/nfs-client.rst index 6adb6457bc69..36760685dd34 100644 --- a/Documentation/admin-guide/nfs/nfs-client.rst +++ b/Documentation/admin-guide/nfs/nfs-client.rst @@ -36,10 +36,9 @@ administrative requirements that require particular behavior that does not work well as part of an nfs_client_id4 string. The nfs.nfs4_unique_id boot parameter specifies a unique string that can be -used instead of a system's node name when an NFS client identifies itself to -a server. Thus, if the system's node name is not unique, or it changes, its -nfs.nfs4_unique_id stays the same, preventing collision with other clients -or loss of state during NFS reboot recovery or transparent state migration. +used together with a system's node name when an NFS client identifies itself to +a server. Thus, if the system's node name is not unique, its +nfs.nfs4_unique_id can help prevent collisions with other clients. The nfs.nfs4_unique_id string is typically a UUID, though it can contain anything that is believed to be unique across all NFS clients. An @@ -53,8 +52,12 @@ outstanding NFSv4 state has expired, to prevent loss of NFSv4 state. This string can be stored in an NFS client's grub.conf, or it can be provided via a net boot facility such as PXE. It may also be specified as an nfs.ko -module parameter. Specifying a uniquifier string is not support for NFS -clients running in containers. +module parameter. + +This uniquifier string will be the same for all NFS clients running in +containers unless it is overridden by a value written to +/sys/fs/nfs/net/nfs_client/identifier which will be local to the network +namespace of the process which writes. The DNS resolver diff --git a/Documentation/admin-guide/pm/intel-speed-select.rst b/Documentation/admin-guide/pm/intel-speed-select.rst index 0a1fbdb54bfe..a2bfb971654f 100644 --- a/Documentation/admin-guide/pm/intel-speed-select.rst +++ b/Documentation/admin-guide/pm/intel-speed-select.rst @@ -262,6 +262,28 @@ Which shows that the base frequency now increased from 2600 MHz at performance level 0 to 2800 MHz at performance level 4. As a result, any workload, which can use fewer CPUs, can see a boost of 200 MHz compared to performance level 0. +Changing performance level via BMC Interface +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +It is possible to change SST-PP level using out of band (OOB) agent (Via some +remote management console, through BMC "Baseboard Management Controller" +interface). This mode is supported from the Sapphire Rapids processor +generation. The kernel and tool change to support this mode is added to Linux +kernel version 5.18. To enable this feature, kernel config +"CONFIG_INTEL_HFI_THERMAL" is required. The minimum version of the tool +is "v1.12" to support this feature, which is part of Linux kernel version 5.18. + +To support such configuration, this tool can be used as a daemon. Add +a command line option --oob:: + + # intel-speed-select --oob + Intel(R) Speed Select Technology + Executing on CPU model:143[0x8f] + OOB mode is enabled and will run as daemon + +In this mode the tool will online/offline CPUs based on the new performance +level. + Check presence of other Intel(R) SST features --------------------------------------------- diff --git a/Documentation/admin-guide/sysctl/vm.rst b/Documentation/admin-guide/sysctl/vm.rst index f4804ce37c58..5c9aa171a0d3 100644 --- a/Documentation/admin-guide/sysctl/vm.rst +++ b/Documentation/admin-guide/sysctl/vm.rst @@ -62,6 +62,7 @@ Currently, these files are in /proc/sys/vm: - overcommit_memory - overcommit_ratio - page-cluster +- page_lock_unfairness - panic_on_oom - percpu_pagelist_high_fraction - stat_interval @@ -561,6 +562,45 @@ Change the minimum size of the hugepage pool. See Documentation/admin-guide/mm/hugetlbpage.rst +hugetlb_optimize_vmemmap +======================== + +This knob is not available when memory_hotplug.memmap_on_memory (kernel parameter) +is configured or the size of 'struct page' (a structure defined in +include/linux/mm_types.h) is not power of two (an unusual system config could +result in this). + +Enable (set to 1) or disable (set to 0) the feature of optimizing vmemmap pages +associated with each HugeTLB page. + +Once enabled, the vmemmap pages of subsequent allocation of HugeTLB pages from +buddy allocator will be optimized (7 pages per 2MB HugeTLB page and 4095 pages +per 1GB HugeTLB page), whereas already allocated HugeTLB pages will not be +optimized. When those optimized HugeTLB pages are freed from the HugeTLB pool +to the buddy allocator, the vmemmap pages representing that range needs to be +remapped again and the vmemmap pages discarded earlier need to be rellocated +again. If your use case is that HugeTLB pages are allocated 'on the fly' (e.g. +never explicitly allocating HugeTLB pages with 'nr_hugepages' but only set +'nr_overcommit_hugepages', those overcommitted HugeTLB pages are allocated 'on +the fly') instead of being pulled from the HugeTLB pool, you should weigh the +benefits of memory savings against the more overhead (~2x slower than before) +of allocation or freeing HugeTLB pages between the HugeTLB pool and the buddy +allocator. Another behavior to note is that if the system is under heavy memory +pressure, it could prevent the user from freeing HugeTLB pages from the HugeTLB +pool to the buddy allocator since the allocation of vmemmap pages could be +failed, you have to retry later if your system encounter this situation. + +Once disabled, the vmemmap pages of subsequent allocation of HugeTLB pages from +buddy allocator will not be optimized meaning the extra overhead at allocation +time from buddy allocator disappears, whereas already optimized HugeTLB pages +will not be affected. If you want to make sure there are no optimized HugeTLB +pages, you can set "nr_hugepages" to 0 first and then disable this. Note that +writing 0 to nr_hugepages will make any "in use" HugeTLB pages become surplus +pages. So, those surplus pages are still optimized until they are no longer +in use. You would need to wait for those surplus pages to be released before +there are no optimized pages in the system. + + nr_hugepages_mempolicy ====================== @@ -754,6 +794,14 @@ extra faults and I/O delays for following faults if they would have been part of that consecutive pages readahead would have brought in. +page_lock_unfairness +==================== + +This value determines the number of times that the page lock can be +stolen from under a waiter. After the lock is stolen the number of times +specified in this file (default is 5), the "fair lock handoff" semantics +will apply, and the waiter will only be awakened if the lock can be taken. + panic_on_oom ============ diff --git a/Documentation/arm/marvell.rst b/Documentation/arm/marvell.rst index 2f41caa0096c..370721518987 100644 --- a/Documentation/arm/marvell.rst +++ b/Documentation/arm/marvell.rst @@ -374,8 +374,6 @@ PXA 2xx/3xx/93x/95x family Linux kernel mach directory: arch/arm/mach-pxa - Linux kernel plat directory: - arch/arm/plat-pxa MMP/MMP2/MMP3 family (communication processor) ---------------------------------------------- @@ -429,8 +427,6 @@ MMP/MMP2/MMP3 family (communication processor) Linux kernel mach directory: arch/arm/mach-mmp - Linux kernel plat directory: - arch/arm/plat-pxa Berlin family (Multimedia Solutions) ------------------------------------- @@ -518,9 +514,6 @@ Long-term plans Business Unit) in a single mach-<foo> directory. The plat-orion/ would therefore disappear. - * Unify the mach-mmp/ and mach-pxa/ into the same mach-pxa - directory. The plat-pxa/ would therefore disappear. - Credits ------- diff --git a/Documentation/arm64/cpu-feature-registers.rst b/Documentation/arm64/cpu-feature-registers.rst index 749ae970c319..04ba83e1965f 100644 --- a/Documentation/arm64/cpu-feature-registers.rst +++ b/Documentation/arm64/cpu-feature-registers.rst @@ -290,6 +290,8 @@ infrastructure: +------------------------------+---------+---------+ | RPRES | [7-4] | y | +------------------------------+---------+---------+ + | WFXT | [3-0] | y | + +------------------------------+---------+---------+ Appendix I: Example diff --git a/Documentation/arm64/elf_hwcaps.rst b/Documentation/arm64/elf_hwcaps.rst index f8d818eaaff5..3d116fb536c5 100644 --- a/Documentation/arm64/elf_hwcaps.rst +++ b/Documentation/arm64/elf_hwcaps.rst @@ -297,6 +297,10 @@ HWCAP2_SME_FA64 Functionality implied by ID_AA64SMFR0_EL1.FA64 == 0b1. +HWCAP2_WFXT + + Functionality implied by ID_AA64ISAR2_EL1.WFXT == 0b0010. + 4. Unused AT_HWCAP bits ----------------------- diff --git a/Documentation/dev-tools/kasan.rst b/Documentation/dev-tools/kasan.rst index 7614a1fc30fa..1772fd457fed 100644 --- a/Documentation/dev-tools/kasan.rst +++ b/Documentation/dev-tools/kasan.rst @@ -4,39 +4,76 @@ The Kernel Address Sanitizer (KASAN) Overview -------- -KernelAddressSANitizer (KASAN) is a dynamic memory safety error detector -designed to find out-of-bound and use-after-free bugs. KASAN has three modes: +Kernel Address Sanitizer (KASAN) is a dynamic memory safety error detector +designed to find out-of-bounds and use-after-free bugs. -1. generic KASAN (similar to userspace ASan), -2. software tag-based KASAN (similar to userspace HWASan), -3. hardware tag-based KASAN (based on hardware memory tagging). +KASAN has three modes: -Generic KASAN is mainly used for debugging due to a large memory overhead. -Software tag-based KASAN can be used for dogfood testing as it has a lower -memory overhead that allows using it with real workloads. Hardware tag-based -KASAN comes with low memory and performance overheads and, therefore, can be -used in production. Either as an in-field memory bug detector or as a security -mitigation. +1. Generic KASAN +2. Software Tag-Based KASAN +3. Hardware Tag-Based KASAN -Software KASAN modes (#1 and #2) use compile-time instrumentation to insert -validity checks before every memory access and, therefore, require a compiler -version that supports that. +Generic KASAN, enabled with CONFIG_KASAN_GENERIC, is the mode intended for +debugging, similar to userspace ASan. This mode is supported on many CPU +architectures, but it has significant performance and memory overheads. -Generic KASAN is supported in GCC and Clang. With GCC, it requires version -8.3.0 or later. Any supported Clang version is compatible, but detection of -out-of-bounds accesses for global variables is only supported since Clang 11. +Software Tag-Based KASAN or SW_TAGS KASAN, enabled with CONFIG_KASAN_SW_TAGS, +can be used for both debugging and dogfood testing, similar to userspace HWASan. +This mode is only supported for arm64, but its moderate memory overhead allows +using it for testing on memory-restricted devices with real workloads. -Software tag-based KASAN mode is only supported in Clang. +Hardware Tag-Based KASAN or HW_TAGS KASAN, enabled with CONFIG_KASAN_HW_TAGS, +is the mode intended to be used as an in-field memory bug detector or as a +security mitigation. This mode only works on arm64 CPUs that support MTE +(Memory Tagging Extension), but it has low memory and performance overheads and +thus can be used in production. -The hardware KASAN mode (#3) relies on hardware to perform the checks but -still requires a compiler version that supports memory tagging instructions. -This mode is supported in GCC 10+ and Clang 12+. +For details about the memory and performance impact of each KASAN mode, see the +descriptions of the corresponding Kconfig options. -Both software KASAN modes work with SLUB and SLAB memory allocators, -while the hardware tag-based KASAN currently only supports SLUB. +The Generic and the Software Tag-Based modes are commonly referred to as the +software modes. The Software Tag-Based and the Hardware Tag-Based modes are +referred to as the tag-based modes. -Currently, generic KASAN is supported for the x86_64, arm, arm64, xtensa, s390, -and riscv architectures, and tag-based KASAN modes are supported only for arm64. +Support +------- + +Architectures +~~~~~~~~~~~~~ + +Generic KASAN is supported on x86_64, arm, arm64, powerpc, riscv, s390, and +xtensa, and the tag-based KASAN modes are supported only on arm64. + +Compilers +~~~~~~~~~ + +Software KASAN modes use compile-time instrumentation to insert validity checks +before every memory access and thus require a compiler version that provides +support for that. The Hardware Tag-Based mode relies on hardware to perform +these checks but still requires a compiler version that supports the memory +tagging instructions. + +Generic KASAN requires GCC version 8.3.0 or later +or any Clang version supported by the kernel. + +Software Tag-Based KASAN requires GCC 11+ +or any Clang version supported by the kernel. + +Hardware Tag-Based KASAN requires GCC 10+ or Clang 12+. + +Memory types +~~~~~~~~~~~~ + +Generic KASAN supports finding bugs in all of slab, page_alloc, vmap, vmalloc, +stack, and global memory. + +Software Tag-Based KASAN supports slab, page_alloc, vmalloc, and stack memory. + +Hardware Tag-Based KASAN supports slab, page_alloc, and non-executable vmalloc +memory. + +For slab, both software KASAN modes support SLUB and SLAB allocators, while +Hardware Tag-Based KASAN only supports SLUB. Usage ----- @@ -45,18 +82,59 @@ To enable KASAN, configure the kernel with:: CONFIG_KASAN=y -and choose between ``CONFIG_KASAN_GENERIC`` (to enable generic KASAN), -``CONFIG_KASAN_SW_TAGS`` (to enable software tag-based KASAN), and -``CONFIG_KASAN_HW_TAGS`` (to enable hardware tag-based KASAN). +and choose between ``CONFIG_KASAN_GENERIC`` (to enable Generic KASAN), +``CONFIG_KASAN_SW_TAGS`` (to enable Software Tag-Based KASAN), and +``CONFIG_KASAN_HW_TAGS`` (to enable Hardware Tag-Based KASAN). -For software modes, also choose between ``CONFIG_KASAN_OUTLINE`` and +For the software modes, also choose between ``CONFIG_KASAN_OUTLINE`` and ``CONFIG_KASAN_INLINE``. Outline and inline are compiler instrumentation types. -The former produces a smaller binary while the latter is 1.1-2 times faster. +The former produces a smaller binary while the latter is up to 2 times faster. To include alloc and free stack traces of affected slab objects into reports, enable ``CONFIG_STACKTRACE``. To include alloc and free stack traces of affected physical pages, enable ``CONFIG_PAGE_OWNER`` and boot with ``page_owner=on``. +Boot parameters +~~~~~~~~~~~~~~~ + +KASAN is affected by the generic ``panic_on_warn`` command line parameter. +When it is enabled, KASAN panics the kernel after printing a bug report. + +By default, KASAN prints a bug report only for the first invalid memory access. +With ``kasan_multi_shot``, KASAN prints a report on every invalid access. This +effectively disables ``panic_on_warn`` for KASAN reports. + +Alternatively, independent of ``panic_on_warn``, the ``kasan.fault=`` boot +parameter can be used to control panic and reporting behaviour: + +- ``kasan.fault=report`` or ``=panic`` controls whether to only print a KASAN + report or also panic the kernel (default: ``report``). The panic happens even + if ``kasan_multi_shot`` is enabled. + +Hardware Tag-Based KASAN mode (see the section about various modes below) is +intended for use in production as a security mitigation. Therefore, it supports +additional boot parameters that allow disabling KASAN or controlling features: + +- ``kasan=off`` or ``=on`` controls whether KASAN is enabled (default: ``on``). + +- ``kasan.mode=sync``, ``=async`` or ``=asymm`` controls whether KASAN + is configured in synchronous, asynchronous or asymmetric mode of + execution (default: ``sync``). + Synchronous mode: a bad access is detected immediately when a tag + check fault occurs. + Asynchronous mode: a bad access detection is delayed. When a tag check + fault occurs, the information is stored in hardware (in the TFSR_EL1 + register for arm64). The kernel periodically checks the hardware and + only reports tag faults during these checks. + Asymmetric mode: a bad access is detected synchronously on reads and + asynchronously on writes. + +- ``kasan.vmalloc=off`` or ``=on`` disables or enables tagging of vmalloc + allocations (default: ``on``). + +- ``kasan.stacktrace=off`` or ``=on`` disables or enables alloc and free stack + traces collection (default: ``on``). + Error reports ~~~~~~~~~~~~~ @@ -146,7 +224,7 @@ is either 8 or 16 aligned bytes depending on KASAN mode. Each number in the memory state section of the report shows the state of one of the memory granules that surround the accessed address. -For generic KASAN, the size of each memory granule is 8. The state of each +For Generic KASAN, the size of each memory granule is 8. The state of each granule is encoded in one shadow byte. Those 8 bytes can be accessible, partially accessible, freed, or be a part of a redzone. KASAN uses the following encoding for each shadow byte: 00 means that all 8 bytes of the corresponding @@ -171,47 +249,6 @@ traces point to places in code that interacted with the object but that are not directly present in the bad access stack trace. Currently, this includes call_rcu() and workqueue queuing. -Boot parameters -~~~~~~~~~~~~~~~ - -KASAN is affected by the generic ``panic_on_warn`` command line parameter. -When it is enabled, KASAN panics the kernel after printing a bug report. - -By default, KASAN prints a bug report only for the first invalid memory access. -With ``kasan_multi_shot``, KASAN prints a report on every invalid access. This -effectively disables ``panic_on_warn`` for KASAN reports. - -Alternatively, independent of ``panic_on_warn`` the ``kasan.fault=`` boot -parameter can be used to control panic and reporting behaviour: - -- ``kasan.fault=report`` or ``=panic`` controls whether to only print a KASAN - report or also panic the kernel (default: ``report``). The panic happens even - if ``kasan_multi_shot`` is enabled. - -Hardware tag-based KASAN mode (see the section about various modes below) is -intended for use in production as a security mitigation. Therefore, it supports -additional boot parameters that allow disabling KASAN or controlling features: - -- ``kasan=off`` or ``=on`` controls whether KASAN is enabled (default: ``on``). - -- ``kasan.mode=sync``, ``=async`` or ``=asymm`` controls whether KASAN - is configured in synchronous, asynchronous or asymmetric mode of - execution (default: ``sync``). - Synchronous mode: a bad access is detected immediately when a tag - check fault occurs. - Asynchronous mode: a bad access detection is delayed. When a tag check - fault occurs, the information is stored in hardware (in the TFSR_EL1 - register for arm64). The kernel periodically checks the hardware and - only reports tag faults during these checks. - Asymmetric mode: a bad access is detected synchronously on reads and - asynchronously on writes. - -- ``kasan.vmalloc=off`` or ``=on`` disables or enables tagging of vmalloc - allocations (default: ``on``). - -- ``kasan.stacktrace=off`` or ``=on`` disables or enables alloc and free stack - traces collection (default: ``on``). - Implementation details ---------------------- @@ -250,49 +287,46 @@ outline-instrumented kernel. Generic KASAN is the only mode that delays the reuse of freed objects via quarantine (see mm/kasan/quarantine.c for implementation). -Software tag-based KASAN +Software Tag-Based KASAN ~~~~~~~~~~~~~~~~~~~~~~~~ -Software tag-based KASAN uses a software memory tagging approach to checking +Software Tag-Based KASAN uses a software memory tagging approach to checking access validity. It is currently only implemented for the arm64 architecture. -Software tag-based KASAN uses the Top Byte Ignore (TBI) feature of arm64 CPUs +Software Tag-Based KASAN uses the Top Byte Ignore (TBI) feature of arm64 CPUs to store a pointer tag in the top byte of kernel pointers. It uses shadow memory to store memory tags associated with each 16-byte memory cell (therefore, it dedicates 1/16th of the kernel memory for shadow memory). -On each memory allocation, software tag-based KASAN generates a random tag, tags +On each memory allocation, Software Tag-Based KASAN generates a random tag, tags the allocated memory with this tag, and embeds the same tag into the returned pointer. -Software tag-based KASAN uses compile-time instrumentation to insert checks +Software Tag-Based KASAN uses compile-time instrumentation to insert checks before each memory access. These checks make sure that the tag of the memory that is being accessed is equal to the tag of the pointer that is used to access -this memory. In case of a tag mismatch, software tag-based KASAN prints a bug +this memory. In case of a tag mismatch, Software Tag-Based KASAN prints a bug report. -Software tag-based KASAN also has two instrumentation modes (outline, which +Software Tag-Based KASAN also has two instrumentation modes (outline, which emits callbacks to check memory accesses; and inline, which performs the shadow memory checks inline). With outline instrumentation mode, a bug report is printed from the function that performs the access check. With inline instrumentation, a ``brk`` instruction is emitted by the compiler, and a dedicated ``brk`` handler is used to print bug reports. -Software tag-based KASAN uses 0xFF as a match-all pointer tag (accesses through +Software Tag-Based KASAN uses 0xFF as a match-all pointer tag (accesses through pointers with the 0xFF pointer tag are not checked). The value 0xFE is currently reserved to tag freed memory regions. -Software tag-based KASAN currently only supports tagging of slab, page_alloc, -and vmalloc memory. - -Hardware tag-based KASAN +Hardware Tag-Based KASAN ~~~~~~~~~~~~~~~~~~~~~~~~ -Hardware tag-based KASAN is similar to the software mode in concept but uses +Hardware Tag-Based KASAN is similar to the software mode in concept but uses hardware memory tagging support instead of compiler instrumentation and shadow memory. -Hardware tag-based KASAN is currently only implemented for arm64 architecture +Hardware Tag-Based KASAN is currently only implemented for arm64 architecture and based on both arm64 Memory Tagging Extension (MTE) introduced in ARMv8.5 Instruction Set Architecture and Top Byte Ignore (TBI). @@ -302,21 +336,18 @@ access, hardware makes sure that the tag of the memory that is being accessed is equal to the tag of the pointer that is used to access this memory. In case of a tag mismatch, a fault is generated, and a report is printed. -Hardware tag-based KASAN uses 0xFF as a match-all pointer tag (accesses through +Hardware Tag-Based KASAN uses 0xFF as a match-all pointer tag (accesses through pointers with the 0xFF pointer tag are not checked). The value 0xFE is currently reserved to tag freed memory regions. -Hardware tag-based KASAN currently only supports tagging of slab, page_alloc, -and VM_ALLOC-based vmalloc memory. - -If the hardware does not support MTE (pre ARMv8.5), hardware tag-based KASAN +If the hardware does not support MTE (pre ARMv8.5), Hardware Tag-Based KASAN will not be enabled. In this case, all KASAN boot parameters are ignored. Note that enabling CONFIG_KASAN_HW_TAGS always results in in-kernel TBI being enabled. Even when ``kasan.mode=off`` is provided or when the hardware does not support MTE (but supports TBI). -Hardware tag-based KASAN only reports the first found bug. After that, MTE tag +Hardware Tag-Based KASAN only reports the first found bug. After that, MTE tag checking gets disabled. Shadow memory @@ -414,19 +445,18 @@ generic ``noinstr`` one. Note that disabling compiler instrumentation (either on a per-file or a per-function basis) makes KASAN ignore the accesses that happen directly in that code for software KASAN modes. It does not help when the accesses happen -indirectly (through calls to instrumented functions) or with the hardware -tag-based mode that does not use compiler instrumentation. +indirectly (through calls to instrumented functions) or with Hardware +Tag-Based KASAN, which does not use compiler instrumentation. For software KASAN modes, to disable KASAN reports in a part of the kernel code for the current task, annotate this part of the code with a ``kasan_disable_current()``/``kasan_enable_current()`` section. This also disables the reports for indirect accesses that happen through function calls. -For tag-based KASAN modes (include the hardware one), to disable access -checking, use ``kasan_reset_tag()`` or ``page_kasan_tag_reset()``. Note that -temporarily disabling access checking via ``page_kasan_tag_reset()`` requires -saving and restoring the per-page KASAN tag via -``page_kasan_tag``/``page_kasan_tag_set``. +For tag-based KASAN modes, to disable access checking, use +``kasan_reset_tag()`` or ``page_kasan_tag_reset()``. Note that temporarily +disabling access checking via ``page_kasan_tag_reset()`` requires saving and +restoring the per-page KASAN tag via ``page_kasan_tag``/``page_kasan_tag_set``. Tests ~~~~~ diff --git a/Documentation/devicetree/bindings/arm/mediatek/mediatek,mt8186-clock.yaml b/Documentation/devicetree/bindings/arm/mediatek/mediatek,mt8186-clock.yaml new file mode 100644 index 000000000000..cf1002c3efa6 --- /dev/null +++ b/Documentation/devicetree/bindings/arm/mediatek/mediatek,mt8186-clock.yaml @@ -0,0 +1,56 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +%YAML 1.2 +--- +$id: "http://devicetree.org/schemas/arm/mediatek/mediatek,mt8186-clock.yaml#" +$schema: "http://devicetree.org/meta-schemas/core.yaml#" + +title: MediaTek Functional Clock Controller for MT8186 + +maintainers: + - Chun-Jie Chen <chun-jie.chen@mediatek.com> + +description: | + The clock architecture in MediaTek like below + PLLs --> + dividers --> + muxes + --> + clock gate + + The devices provide clock gate control in different IP blocks. + +properties: + compatible: + items: + - enum: + - mediatek,mt8186-imp_iic_wrap + - mediatek,mt8186-mfgsys + - mediatek,mt8186-wpesys + - mediatek,mt8186-imgsys1 + - mediatek,mt8186-imgsys2 + - mediatek,mt8186-vdecsys + - mediatek,mt8186-vencsys + - mediatek,mt8186-camsys + - mediatek,mt8186-camsys_rawa + - mediatek,mt8186-camsys_rawb + - mediatek,mt8186-mdpsys + - mediatek,mt8186-ipesys + reg: + maxItems: 1 + + '#clock-cells': + const: 1 + +required: + - compatible + - reg + +additionalProperties: false + +examples: + - | + imp_iic_wrap: clock-controller@11017000 { + compatible = "mediatek,mt8186-imp_iic_wrap"; + reg = <0x11017000 0x1000>; + #clock-cells = <1>; + }; diff --git a/Documentation/devicetree/bindings/arm/mediatek/mediatek,mt8186-sys-clock.yaml b/Documentation/devicetree/bindings/arm/mediatek/mediatek,mt8186-sys-clock.yaml new file mode 100644 index 000000000000..0886e2e335bb --- /dev/null +++ b/Documentation/devicetree/bindings/arm/mediatek/mediatek,mt8186-sys-clock.yaml @@ -0,0 +1,54 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +%YAML 1.2 +--- +$id: "http://devicetree.org/schemas/arm/mediatek/mediatek,mt8186-sys-clock.yaml#" +$schema: "http://devicetree.org/meta-schemas/core.yaml#" + +title: MediaTek System Clock Controller for MT8186 + +maintainers: + - Chun-Jie Chen <chun-jie.chen@mediatek.com> + +description: | + The clock architecture in MediaTek like below + PLLs --> + dividers --> + muxes + --> + clock gate + + The apmixedsys provides most of PLLs which generated from SoC 26m. + The topckgen provides dividers and muxes which provide the clock source to other IP blocks. + The infracfg_ao provides clock gate in peripheral and infrastructure IP blocks. + The mcusys provides mux control to select the clock source in AP MCU. + The device nodes also provide the system control capacity for configuration. + +properties: + compatible: + items: + - enum: + - mediatek,mt8186-mcusys + - mediatek,mt8186-topckgen + - mediatek,mt8186-infracfg_ao + - mediatek,mt8186-apmixedsys + - const: syscon + + reg: + maxItems: 1 + + '#clock-cells': + const: 1 + +required: + - compatible + - reg + +additionalProperties: false + +examples: + - | + topckgen: syscon@10000000 { + compatible = "mediatek,mt8186-topckgen", "syscon"; + reg = <0x10000000 0x1000>; + #clock-cells = <1>; + }; diff --git a/Documentation/devicetree/bindings/arm/tegra/nvidia,tegra-ccplex-cluster.yaml b/Documentation/devicetree/bindings/arm/tegra/nvidia,tegra-ccplex-cluster.yaml new file mode 100644 index 000000000000..8c6543b5c0dc --- /dev/null +++ b/Documentation/devicetree/bindings/arm/tegra/nvidia,tegra-ccplex-cluster.yaml @@ -0,0 +1,52 @@ +# 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#" + +title: NVIDIA Tegra CPU COMPLEX CLUSTER area device tree bindings + +maintainers: + - Sumit Gupta <sumitg@nvidia.com> + - Mikko Perttunen <mperttunen@nvidia.com> + - Jon Hunter <jonathanh@nvidia.com> + - Thierry Reding <thierry.reding@gmail.com> + +description: |+ + The Tegra CPU COMPLEX CLUSTER area contains memory-mapped + registers that initiate CPU frequency/voltage transitions. + +properties: + $nodename: + pattern: "ccplex@([0-9a-f]+)$" + + compatible: + enum: + - nvidia,tegra186-ccplex-cluster + - nvidia,tegra234-ccplex-cluster + + reg: + maxItems: 1 + + nvidia,bpmp: + $ref: '/schemas/types.yaml#/definitions/phandle' + description: | + Specifies the BPMP node that needs to be queried to get + operating point data for all CPUs. + +additionalProperties: false + +required: + - compatible + - reg + - nvidia,bpmp + - status + +examples: + - | + ccplex@e000000 { + compatible = "nvidia,tegra234-ccplex-cluster"; + reg = <0x0e000000 0x5ffff>; + nvidia,bpmp = <&bpmp>; + status = "okay"; + }; diff --git a/Documentation/devicetree/bindings/clock/airoha,en7523-scu.yaml b/Documentation/devicetree/bindings/clock/airoha,en7523-scu.yaml new file mode 100644 index 000000000000..d60e74654809 --- /dev/null +++ b/Documentation/devicetree/bindings/clock/airoha,en7523-scu.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/airoha,en7523-scu.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: EN7523 Clock Device Tree Bindings + +maintainers: + - Felix Fietkau <nbd@nbd.name> + - John Crispin <nbd@nbd.name> + +description: | + This node defines the System Control Unit of the EN7523 SoC, + a collection of registers configuring many different aspects of the SoC. + + The clock driver uses it to read and configure settings of the + PLL controller, which provides clocks for the CPU, the bus and + other SoC internal peripherals. + + Each clock is assigned an identifier and client nodes use this identifier + to specify which clock they consume. + + All these identifiers can be found in: + [1]: <include/dt-bindings/clock/en7523-clk.h>. + + The clocks are provided inside a system controller node. + +properties: + compatible: + items: + - const: airoha,en7523-scu + + reg: + maxItems: 2 + + "#clock-cells": + description: + The first cell indicates the clock number, see [1] for available + clocks. + const: 1 + +required: + - compatible + - reg + - '#clock-cells' + +additionalProperties: false + +examples: + - | + #include <dt-bindings/clock/en7523-clk.h> + scu: system-controller@1fa20000 { + compatible = "airoha,en7523-scu"; + reg = <0x1fa20000 0x400>, + <0x1fb00000 0x1000>; + #clock-cells = <1>; + }; diff --git a/Documentation/devicetree/bindings/clock/clock-bindings.txt b/Documentation/devicetree/bindings/clock/clock-bindings.txt index f2ea53832ac6..6fe541368889 100644 --- a/Documentation/devicetree/bindings/clock/clock-bindings.txt +++ b/Documentation/devicetree/bindings/clock/clock-bindings.txt @@ -1,186 +1,2 @@ -This binding is a work-in-progress, and are based on some experimental -work by benh[1]. - -Sources of clock signal can be represented by any node in the device -tree. Those nodes are designated as clock providers. Clock consumer -nodes use a phandle and clock specifier pair to connect clock provider -outputs to clock inputs. Similar to the gpio specifiers, a clock -specifier is an array of zero, one or more cells identifying the clock -output on a device. The length of a clock specifier is defined by the -value of a #clock-cells property in the clock provider node. - -[1] https://patchwork.ozlabs.org/patch/31551/ - -==Clock providers== - -Required properties: -#clock-cells: Number of cells in a clock specifier; Typically 0 for nodes - with a single clock output and 1 for nodes with multiple - clock outputs. - -Optional properties: -clock-output-names: Recommended to be a list of strings of clock output signal - names indexed by the first cell in the clock specifier. - However, the meaning of clock-output-names is domain - specific to the clock provider, and is only provided to - encourage using the same meaning for the majority of clock - providers. This format may not work for clock providers - using a complex clock specifier format. In those cases it - is recommended to omit this property and create a binding - specific names property. - - Clock consumer nodes must never directly reference - the provider's clock-output-names property. - -For example: - - oscillator { - #clock-cells = <1>; - clock-output-names = "ckil", "ckih"; - }; - -- this node defines a device with two clock outputs, the first named - "ckil" and the second named "ckih". Consumer nodes always reference - clocks by index. The names should reflect the clock output signal - names for the device. - -clock-indices: If the identifying number for the clocks in the node - is not linear from zero, then this allows the mapping of - identifiers into the clock-output-names array. - -For example, if we have two clocks <&oscillator 1> and <&oscillator 3>: - - oscillator { - compatible = "myclocktype"; - #clock-cells = <1>; - clock-indices = <1>, <3>; - clock-output-names = "clka", "clkb"; - } - - This ensures we do not have any empty strings in clock-output-names - - -==Clock consumers== - -Required properties: -clocks: List of phandle and clock specifier pairs, one pair - for each clock input to the device. Note: if the - clock provider specifies '0' for #clock-cells, then - only the phandle portion of the pair will appear. - -Optional properties: -clock-names: List of clock input name strings sorted in the same - order as the clocks property. Consumers drivers - will use clock-names to match clock input names - with clocks specifiers. -clock-ranges: Empty property indicating that child nodes can inherit named - clocks from this node. Useful for bus nodes to provide a - clock to their children. - -For example: - - device { - clocks = <&osc 1>, <&ref 0>; - clock-names = "baud", "register"; - }; - - -This represents a device with two clock inputs, named "baud" and "register". -The baud clock is connected to output 1 of the &osc device, and the register -clock is connected to output 0 of the &ref. - -==Example== - - /* external oscillator */ - osc: oscillator { - compatible = "fixed-clock"; - #clock-cells = <0>; - clock-frequency = <32678>; - clock-output-names = "osc"; - }; - - /* phase-locked-loop device, generates a higher frequency clock - * from the external oscillator reference */ - pll: pll@4c000 { - compatible = "vendor,some-pll-interface" - #clock-cells = <1>; - clocks = <&osc 0>; - clock-names = "ref"; - reg = <0x4c000 0x1000>; - clock-output-names = "pll", "pll-switched"; - }; - - /* UART, using the low frequency oscillator for the baud clock, - * and the high frequency switched PLL output for register - * clocking */ - uart@a000 { - compatible = "fsl,imx-uart"; - reg = <0xa000 0x1000>; - interrupts = <33>; - clocks = <&osc 0>, <&pll 1>; - clock-names = "baud", "register"; - }; - -This DT fragment defines three devices: an external oscillator to provide a -low-frequency reference clock, a PLL device to generate a higher frequency -clock signal, and a UART. - -* The oscillator is fixed-frequency, and provides one clock output, named "osc". -* The PLL is both a clock provider and a clock consumer. It uses the clock - signal generated by the external oscillator, and provides two output signals - ("pll" and "pll-switched"). -* The UART has its baud clock connected the external oscillator and its - register clock connected to the PLL clock (the "pll-switched" signal) - -==Assigned clock parents and rates== - -Some platforms may require initial configuration of default parent clocks -and clock frequencies. Such a configuration can be specified in a device tree -node through assigned-clocks, assigned-clock-parents and assigned-clock-rates -properties. The assigned-clock-parents property should contain a list of parent -clocks in the form of a phandle and clock specifier pair and the -assigned-clock-rates property should contain a list of frequencies in Hz. Both -these properties should correspond to the clocks listed in the assigned-clocks -property. - -To skip setting parent or rate of a clock its corresponding entry should be -set to 0, or can be omitted if it is not followed by any non-zero entry. - - uart@a000 { - compatible = "fsl,imx-uart"; - reg = <0xa000 0x1000>; - ... - clocks = <&osc 0>, <&pll 1>; - clock-names = "baud", "register"; - - assigned-clocks = <&clkcon 0>, <&pll 2>; - assigned-clock-parents = <&pll 2>; - assigned-clock-rates = <0>, <460800>; - }; - -In this example the <&pll 2> clock is set as parent of clock <&clkcon 0> and -the <&pll 2> clock is assigned a frequency value of 460800 Hz. - -Configuring a clock's parent and rate through the device node that consumes -the clock can be done only for clocks that have a single user. Specifying -conflicting parent or rate configuration in multiple consumer nodes for -a shared clock is forbidden. - -Configuration of common clocks, which affect multiple consumer devices can -be similarly specified in the clock provider node. - -==Protected clocks== - -Some platforms or firmwares may not fully expose all the clocks to the OS, such -as in situations where those clks are used by drivers running in ARM secure -execution levels. Such a configuration can be specified in device tree with the -protected-clocks property in the form of a clock specifier list. This property should -only be specified in the node that is providing the clocks being protected: - - clock-controller@a000f000 { - compatible = "vendor,clk95; - reg = <0xa000f000 0x1000> - #clocks-cells = <1>; - ... - protected-clocks = <UART3_CLK>, <SPI5_CLK>; - }; +This file has moved to the clock binding schema: +https://github.com/devicetree-org/dt-schema/blob/main/dtschema/schemas/clock/clock.yaml diff --git a/Documentation/devicetree/bindings/clock/qcom,gcc-apq8064.yaml b/Documentation/devicetree/bindings/clock/qcom,gcc-apq8064.yaml index 97936411b6b4..9fafcb080069 100644 --- a/Documentation/devicetree/bindings/clock/qcom,gcc-apq8064.yaml +++ b/Documentation/devicetree/bindings/clock/qcom,gcc-apq8064.yaml @@ -20,12 +20,10 @@ description: | See also: - dt-bindings/clock/qcom,gcc-msm8960.h - dt-bindings/reset/qcom,gcc-msm8960.h - - dt-bindings/clock/qcom,gcc-apq8084.h - - dt-bindings/reset/qcom,gcc-apq8084.h properties: compatible: - const: qcom,gcc-apq8084 + const: qcom,gcc-apq8064 nvmem-cells: minItems: 1 diff --git a/Documentation/devicetree/bindings/clock/qcom,gcc-apq8084.yaml b/Documentation/devicetree/bindings/clock/qcom,gcc-apq8084.yaml new file mode 100644 index 000000000000..397fb918e032 --- /dev/null +++ b/Documentation/devicetree/bindings/clock/qcom,gcc-apq8084.yaml @@ -0,0 +1,42 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/clock/qcom,gcc-apq8084.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Qualcomm Global Clock & Reset Controller Binding for APQ8084 + +maintainers: + - Stephen Boyd <sboyd@kernel.org> + - Taniya Das <quic_tdas@quicinc.com> + +description: | + Qualcomm global clock control module which supports the clocks, resets and + power domains on APQ8084. + + See also:: + - dt-bindings/clock/qcom,gcc-apq8084.h + - dt-bindings/reset/qcom,gcc-apq8084.h + +allOf: + - $ref: qcom,gcc.yaml# + +properties: + compatible: + const: qcom,gcc-apq8084 + +required: + - compatible + +unevaluatedProperties: false + +examples: + - | + clock-controller@fc400000 { + compatible = "qcom,gcc-apq8084"; + reg = <0xfc400000 0x4000>; + #clock-cells = <1>; + #reset-cells = <1>; + #power-domain-cells = <1>; + }; +... diff --git a/Documentation/devicetree/bindings/clock/qcom,gcc-sc8280xp.yaml b/Documentation/devicetree/bindings/clock/qcom,gcc-sc8280xp.yaml new file mode 100644 index 000000000000..0bcdc69c6f89 --- /dev/null +++ b/Documentation/devicetree/bindings/clock/qcom,gcc-sc8280xp.yaml @@ -0,0 +1,128 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/clock/qcom,gcc-sc8280xp.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Qualcomm Global Clock & Reset Controller Binding for SC8280xp + +maintainers: + - Bjorn Andersson <bjorn.andersson@linaro.org> + +description: | + Qualcomm global clock control module which supports the clocks, resets and + power domains on SC8280xp. + + See also: + - include/dt-bindings/clock/qcom,gcc-sc8280xp.h + +properties: + compatible: + const: qcom,gcc-sc8280xp + + clocks: + items: + - description: XO reference clock + - description: Sleep clock + - description: UFS memory first RX symbol clock + - description: UFS memory second RX symbol clock + - description: UFS memory first TX symbol clock + - description: UFS card first RX symbol clock + - description: UFS card second RX symbol clock + - description: UFS card first TX symbol clock + - description: Primary USB SuperSpeed pipe clock + - description: USB4 PHY pipegmux clock source + - description: USB4 PHY DP gmux clock source + - description: USB4 PHY sys piegmux clock source + - description: USB4 PHY PCIe pipe clock + - description: USB4 PHY router max pipe clock + - description: Primary USB4 RX0 clock + - description: Primary USB4 RX1 clock + - description: Secondary USB SuperSpeed pipe clock + - description: Second USB4 PHY pipegmux clock source + - description: Second USB4 PHY DP gmux clock source + - description: Second USB4 PHY sys pipegmux clock source + - description: Second USB4 PHY PCIe pipe clock + - description: Second USB4 PHY router max pipe clock + - description: Secondary USB4 RX0 clock + - description: Secondary USB4 RX1 clock + - description: Multiport USB first SupserSpeed pipe clock + - description: Multiport USB second SuperSpeed pipe clock + - description: PCIe 2a pipe clock + - description: PCIe 2b pipe clock + - description: PCIe 3a pipe clock + - description: PCIe 3b pipe clock + - description: PCIe 4 pipe clock + - description: First EMAC controller reference clock + - description: Second EMAC controller reference clock + + '#clock-cells': + const: 1 + + '#reset-cells': + const: 1 + + '#power-domain-cells': + const: 1 + + reg: + maxItems: 1 + + protected-clocks: + maxItems: 389 + +required: + - compatible + - clocks + - reg + - '#clock-cells' + - '#reset-cells' + - '#power-domain-cells' + +additionalProperties: false + +examples: + - | + #include <dt-bindings/clock/qcom,rpmh.h> + clock-controller@100000 { + compatible = "qcom,gcc-sc8280xp"; + reg = <0x00100000 0x1f0000>; + clocks = <&rpmhcc RPMH_CXO_CLK>, + <&sleep_clk>, + <&ufs_phy_rx_symbol_0_clk>, + <&ufs_phy_rx_symbol_1_clk>, + <&ufs_phy_tx_symbol_0_clk>, + <&ufs_card_rx_symbol_0_clk>, + <&ufs_card_rx_symbol_1_clk>, + <&ufs_card_tx_symbol_0_clk>, + <&usb_0_ssphy>, + <&gcc_usb4_phy_pipegmux_clk_src>, + <&gcc_usb4_phy_dp_gmux_clk_src>, + <&gcc_usb4_phy_sys_pipegmux_clk_src>, + <&usb4_phy_gcc_usb4_pcie_pipe_clk>, + <&usb4_phy_gcc_usb4rtr_max_pipe_clk>, + <&qusb4phy_gcc_usb4_rx0_clk>, + <&qusb4phy_gcc_usb4_rx1_clk>, + <&usb_1_ssphy>, + <&gcc_usb4_1_phy_pipegmux_clk_src>, + <&gcc_usb4_1_phy_dp_gmux_clk_src>, + <&gcc_usb4_1_phy_sys_pipegmux_clk_src>, + <&usb4_1_phy_gcc_usb4_pcie_pipe_clk>, + <&usb4_1_phy_gcc_usb4rtr_max_pipe_clk>, + <&qusb4phy_1_gcc_usb4_rx0_clk>, + <&qusb4phy_1_gcc_usb4_rx1_clk>, + <&usb_2_ssphy>, + <&usb_3_ssphy>, + <&pcie2a_lane>, + <&pcie2b_lane>, + <&pcie3a_lane>, + <&pcie3b_lane>, + <&pcie4_lane>, + <&rxc0_ref_clk>, + <&rxc1_ref_clk>; + + #clock-cells = <1>; + #reset-cells = <1>; + #power-domain-cells = <1>; + }; +... diff --git a/Documentation/devicetree/bindings/clock/qcom,rpmcc.txt b/Documentation/devicetree/bindings/clock/qcom,rpmcc.txt deleted file mode 100644 index da295c3c004b..000000000000 --- a/Documentation/devicetree/bindings/clock/qcom,rpmcc.txt +++ /dev/null @@ -1,63 +0,0 @@ -Qualcomm RPM Clock Controller Binding ------------------------------------------------- -The RPM is a dedicated hardware engine for managing the shared -SoC resources in order to keep the lowest power profile. It -communicates with other hardware subsystems via shared memory -and accepts clock requests, aggregates the requests and turns -the clocks on/off or scales them on demand. - -Required properties : -- compatible : shall contain only one of the following. The generic - compatible "qcom,rpmcc" should be also included. - - "qcom,rpmcc-mdm9607", "qcom,rpmcc" - "qcom,rpmcc-msm8660", "qcom,rpmcc" - "qcom,rpmcc-apq8060", "qcom,rpmcc" - "qcom,rpmcc-msm8226", "qcom,rpmcc" - "qcom,rpmcc-msm8916", "qcom,rpmcc" - "qcom,rpmcc-msm8936", "qcom,rpmcc" - "qcom,rpmcc-msm8953", "qcom,rpmcc" - "qcom,rpmcc-msm8974", "qcom,rpmcc" - "qcom,rpmcc-msm8976", "qcom,rpmcc" - "qcom,rpmcc-apq8064", "qcom,rpmcc" - "qcom,rpmcc-ipq806x", "qcom,rpmcc" - "qcom,rpmcc-msm8992",·"qcom,rpmcc" - "qcom,rpmcc-msm8994",·"qcom,rpmcc" - "qcom,rpmcc-msm8996", "qcom,rpmcc" - "qcom,rpmcc-msm8998", "qcom,rpmcc" - "qcom,rpmcc-qcm2290", "qcom,rpmcc" - "qcom,rpmcc-qcs404", "qcom,rpmcc" - "qcom,rpmcc-sdm660", "qcom,rpmcc" - "qcom,rpmcc-sm6115", "qcom,rpmcc" - "qcom,rpmcc-sm6125", "qcom,rpmcc" - -- #clock-cells : shall contain 1 - -The clock enumerators are defined in <dt-bindings/clock/qcom,rpmcc.h> -and come in pairs: FOO_CLK followed by FOO_A_CLK. The latter clock -is an "active" clock, which means that the consumer only care that the -clock is available when the apps CPU subsystem is active, i.e. not -suspended or in deep idle. If it is important that the clock keeps running -during system suspend, you need to specify the non-active clock, the one -not containing *_A_* in the enumerator name. - -Example: - smd { - compatible = "qcom,smd"; - - rpm { - interrupts = <0 168 1>; - qcom,ipc = <&apcs 8 0>; - qcom,smd-edge = <15>; - - rpm_requests { - compatible = "qcom,rpm-msm8916"; - qcom,smd-channels = "rpm_requests"; - - rpmcc: clock-controller { - compatible = "qcom,rpmcc-msm8916", "qcom,rpmcc"; - #clock-cells = <1>; - }; - }; - }; - }; diff --git a/Documentation/devicetree/bindings/clock/qcom,rpmcc.yaml b/Documentation/devicetree/bindings/clock/qcom,rpmcc.yaml new file mode 100644 index 000000000000..9d296b89a8d0 --- /dev/null +++ b/Documentation/devicetree/bindings/clock/qcom,rpmcc.yaml @@ -0,0 +1,75 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/clock/qcom,rpmcc.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Qualcomm RPM Clock Controller + +maintainers: + - Bjorn Andersson <bjorn.andersson@linaro.org> + - Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> + +description: | + The clock enumerators are defined in <dt-bindings/clock/qcom,rpmcc.h> and + come in pairs:: FOO_CLK followed by FOO_A_CLK. The latter clock is + an "active" clock, which means that the consumer only care that the clock is + available when the apps CPU subsystem is active, i.e. not suspended or in + deep idle. If it is important that the clock keeps running during system + suspend, you need to specify the non-active clock, the one not containing + *_A_* in the enumerator name. + +properties: + compatible: + items: + - enum: + - qcom,rpmcc-apq8060 + - qcom,rpmcc-apq8064 + - qcom,rpmcc-ipq806x + - qcom,rpmcc-mdm9607 + - qcom,rpmcc-msm8226 + - qcom,rpmcc-msm8660 + - qcom,rpmcc-msm8916 + - qcom,rpmcc-msm8936 + - qcom,rpmcc-msm8953 + - qcom,rpmcc-msm8974 + - qcom,rpmcc-msm8976 + - qcom,rpmcc-msm8992 + - qcom,rpmcc-msm8994 + - qcom,rpmcc-msm8996 + - qcom,rpmcc-msm8998 + - qcom,rpmcc-qcm2290 + - qcom,rpmcc-qcs404 + - qcom,rpmcc-sdm660 + - qcom,rpmcc-sm6115 + - qcom,rpmcc-sm6125 + - const: qcom,rpmcc + + '#clock-cells': + const: 1 + + clocks: + maxItems: 1 + + clock-names: + const: xo + +required: + - compatible + - '#clock-cells' + +additionalProperties: false + +examples: + - | + rpm { + rpm-requests { + compatible = "qcom,rpm-msm8916"; + qcom,smd-channels = "rpm_requests"; + + clock-controller { + compatible = "qcom,rpmcc-msm8916", "qcom,rpmcc"; + #clock-cells = <1>; + }; + }; + }; diff --git a/Documentation/devicetree/bindings/clock/renesas,cpg-mssr.yaml b/Documentation/devicetree/bindings/clock/renesas,cpg-mssr.yaml index e0b86214f0f5..e57bc40d307a 100644 --- a/Documentation/devicetree/bindings/clock/renesas,cpg-mssr.yaml +++ b/Documentation/devicetree/bindings/clock/renesas,cpg-mssr.yaml @@ -49,6 +49,7 @@ properties: - renesas,r8a77995-cpg-mssr # R-Car D3 - renesas,r8a779a0-cpg-mssr # R-Car V3U - renesas,r8a779f0-cpg-mssr # R-Car S4-8 + - renesas,r8a779g0-cpg-mssr # R-Car V4H reg: maxItems: 1 diff --git a/Documentation/devicetree/bindings/clock/renesas,r9a06g032-sysctrl.yaml b/Documentation/devicetree/bindings/clock/renesas,r9a06g032-sysctrl.yaml index 25dbb0fac065..95bf485c6cec 100644 --- a/Documentation/devicetree/bindings/clock/renesas,r9a06g032-sysctrl.yaml +++ b/Documentation/devicetree/bindings/clock/renesas,r9a06g032-sysctrl.yaml @@ -39,6 +39,17 @@ properties: '#power-domain-cells': const: 0 + '#address-cells': + const: 1 + + '#size-cells': + const: 1 + +patternProperties: + "^dma-router@[a-f0-9]+$": + type: object + $ref: "../dma/renesas,rzn1-dmamux.yaml#" + required: - compatible - reg diff --git a/Documentation/devicetree/bindings/clock/renesas,rzg2l-cpg.yaml b/Documentation/devicetree/bindings/clock/renesas,rzg2l-cpg.yaml index bd3af8fc616b..8880b834f264 100644 --- a/Documentation/devicetree/bindings/clock/renesas,rzg2l-cpg.yaml +++ b/Documentation/devicetree/bindings/clock/renesas,rzg2l-cpg.yaml @@ -4,14 +4,15 @@ $id: "http://devicetree.org/schemas/clock/renesas,rzg2l-cpg.yaml#" $schema: "http://devicetree.org/meta-schemas/core.yaml#" -title: Renesas RZ/{G2L,V2L} Clock Pulse Generator / Module Standby Mode +title: Renesas RZ/{G2L,V2L,V2M} Clock Pulse Generator / Module Standby Mode maintainers: - Geert Uytterhoeven <geert+renesas@glider.be> description: | - On Renesas RZ/{G2L,V2L} SoC, the CPG (Clock Pulse Generator) and Module - Standby Mode share the same register block. + On Renesas RZ/{G2L,V2L}-alike SoC's, the CPG (Clock Pulse Generator) and Module + Standby Mode share the same register block. On RZ/V2M, the functionality is + similar, but does not have Clock Monitor Registers. They provide the following functionalities: - The CPG block generates various core clocks, @@ -23,8 +24,10 @@ description: | properties: compatible: enum: - - renesas,r9a07g044-cpg # RZ/G2{L,LC} - - renesas,r9a07g054-cpg # RZ/V2L + - renesas,r9a07g043-cpg # RZ/G2UL{Type-1,Type-2} + - renesas,r9a07g044-cpg # RZ/G2{L,LC} + - renesas,r9a07g054-cpg # RZ/V2L + - renesas,r9a09g011-cpg # RZ/V2M reg: maxItems: 1 @@ -42,9 +45,10 @@ properties: description: | - For CPG core clocks, the two clock specifier cells must be "CPG_CORE" and a core clock reference, as defined in - <dt-bindings/clock/r9a07g*-cpg.h> + <dt-bindings/clock/r9a0*-cpg.h> - For module clocks, the two clock specifier cells must be "CPG_MOD" and - a module number, as defined in the <dt-bindings/clock/r9a07g0*-cpg.h>. + a module number, as defined in the <dt-bindings/clock/r9a07g0*-cpg.h> or + <dt-bindings/clock/r9a09g011-cpg.h>. const: 2 '#power-domain-cells': @@ -58,7 +62,7 @@ properties: '#reset-cells': description: The single reset specifier cell must be the module number, as defined in - the <dt-bindings/clock/r9a07g0*-cpg.h>. + the <dt-bindings/clock/r9a07g0*-cpg.h> or <dt-bindings/clock/r9a09g011-cpg.h>. const: 1 required: diff --git a/Documentation/devicetree/bindings/clock/rockchip,px30-cru.txt b/Documentation/devicetree/bindings/clock/rockchip,px30-cru.txt deleted file mode 100644 index 55e78cddec8c..000000000000 --- a/Documentation/devicetree/bindings/clock/rockchip,px30-cru.txt +++ /dev/null @@ -1,70 +0,0 @@ -* Rockchip PX30 Clock and Reset Unit - -The PX30 clock controller generates and supplies clock to various -controllers within the SoC and also implements a reset controller for SoC -peripherals. - -Required Properties: - -- compatible: PMU for CRU should be "rockchip,px30-pmu-cru" -- compatible: CRU should be "rockchip,px30-cru" -- reg: physical base address of the controller and length of memory mapped - region. -- clocks: A list of phandle + clock-specifier pairs for the clocks listed - in clock-names -- clock-names: Should contain the following: - - "xin24m" for both PMUCRU and CRU - - "gpll" for CRU (sourced from PMUCRU) -- #clock-cells: should be 1. -- #reset-cells: should be 1. - -Optional Properties: - -- rockchip,grf: phandle to the syscon managing the "general register files" - If missing, pll rates are not changeable, due to the missing pll lock status. - -Each clock is assigned an identifier and client nodes can use this identifier -to specify the clock which they consume. All available clocks are defined as -preprocessor macros in the dt-bindings/clock/px30-cru.h headers and can be -used in device tree sources. Similar macros exist for the reset sources in -these files. - -External clocks: - -There are several clocks that are generated outside the SoC. It is expected -that they are defined using standard clock bindings with following -clock-output-names: - - "xin24m" - crystal input - required, - - "xin32k" - rtc clock - optional, - - "i2sx_clkin" - external I2S clock - optional, - - "gmac_clkin" - external GMAC clock - optional - -Example: Clock controller node: - - pmucru: clock-controller@ff2bc000 { - compatible = "rockchip,px30-pmucru"; - reg = <0x0 0xff2bc000 0x0 0x1000>; - #clock-cells = <1>; - #reset-cells = <1>; - }; - - cru: clock-controller@ff2b0000 { - compatible = "rockchip,px30-cru"; - reg = <0x0 0xff2b0000 0x0 0x1000>; - rockchip,grf = <&grf>; - #clock-cells = <1>; - #reset-cells = <1>; - }; - -Example: UART controller node that consumes the clock generated by the clock - controller: - - uart0: serial@ff030000 { - compatible = "rockchip,px30-uart", "snps,dw-apb-uart"; - reg = <0x0 0xff030000 0x0 0x100>; - interrupts = <GIC_SPI 15 IRQ_TYPE_LEVEL_HIGH>; - clocks = <&pmucru SCLK_UART0_PMU>, <&pmucru PCLK_UART0_PMU>; - clock-names = "baudclk", "apb_pclk"; - reg-shift = <2>; - reg-io-width = <4>; - }; diff --git a/Documentation/devicetree/bindings/clock/rockchip,px30-cru.yaml b/Documentation/devicetree/bindings/clock/rockchip,px30-cru.yaml new file mode 100644 index 000000000000..3eec381c7cf5 --- /dev/null +++ b/Documentation/devicetree/bindings/clock/rockchip,px30-cru.yaml @@ -0,0 +1,119 @@ +# SPDX-License-Identifier: GPL-2.0 +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/clock/rockchip,px30-cru.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Rockchip PX30 Clock and Reset Unit (CRU) + +maintainers: + - Elaine Zhang <zhangqing@rock-chips.com> + - Heiko Stuebner <heiko@sntech.de> + +description: | + The PX30 clock controller generates and supplies clocks to various + controllers within the SoC and also implements a reset controller for SoC + peripherals. + Each clock is assigned an identifier and client nodes can use this identifier + to specify the clock which they consume. All available clocks are defined as + preprocessor macros in the dt-bindings/clock/px30-cru.h headers and can be + used in device tree sources. Similar macros exist for the reset sources in + these files. + There are several clocks that are generated outside the SoC. It is expected + that they are defined using standard clock bindings with following + clock-output-names: + - "xin24m" - crystal input - required + - "xin32k" - rtc clock - optional + - "i2sx_clkin" - external I2S clock - optional + - "gmac_clkin" - external GMAC clock - optional + +properties: + compatible: + enum: + - rockchip,px30-cru + - rockchip,px30-pmucru + + reg: + maxItems: 1 + + "#clock-cells": + const: 1 + + "#reset-cells": + const: 1 + + clocks: + minItems: 1 + items: + - description: Clock for both PMUCRU and CRU + - description: Clock for CRU (sourced from PMUCRU) + + clock-names: + minItems: 1 + items: + - const: xin24m + - const: gpll + + rockchip,grf: + $ref: /schemas/types.yaml#/definitions/phandle + description: + Phandle to the syscon managing the "general register files" (GRF), + if missing pll rates are not changeable, due to the missing pll + lock status. + +required: + - compatible + - reg + - clocks + - clock-names + - "#clock-cells" + - "#reset-cells" + +allOf: + - if: + properties: + compatible: + contains: + const: rockchip,px30-cru + + then: + properties: + clocks: + minItems: 2 + + clock-names: + minItems: 2 + + else: + properties: + clocks: + maxItems: 1 + + clock-names: + maxItems: 1 + +additionalProperties: false + +examples: + - | + #include <dt-bindings/clock/px30-cru.h> + + pmucru: clock-controller@ff2bc000 { + compatible = "rockchip,px30-pmucru"; + reg = <0xff2bc000 0x1000>; + clocks = <&xin24m>; + clock-names = "xin24m"; + rockchip,grf = <&grf>; + #clock-cells = <1>; + #reset-cells = <1>; + }; + + cru: clock-controller@ff2b0000 { + compatible = "rockchip,px30-cru"; + reg = <0xff2b0000 0x1000>; + clocks = <&xin24m>, <&pmucru PLL_GPLL>; + clock-names = "xin24m", "gpll"; + rockchip,grf = <&grf>; + #clock-cells = <1>; + #reset-cells = <1>; + }; diff --git a/Documentation/devicetree/bindings/clock/rockchip,rk3036-cru.txt b/Documentation/devicetree/bindings/clock/rockchip,rk3036-cru.txt deleted file mode 100644 index 20df350b9ef3..000000000000 --- a/Documentation/devicetree/bindings/clock/rockchip,rk3036-cru.txt +++ /dev/null @@ -1,56 +0,0 @@ -* Rockchip RK3036 Clock and Reset Unit - -The RK3036 clock controller generates and supplies clock to various -controllers within the SoC and also implements a reset controller for SoC -peripherals. - -Required Properties: - -- compatible: should be "rockchip,rk3036-cru" -- reg: physical base address of the controller and length of memory mapped - region. -- #clock-cells: should be 1. -- #reset-cells: should be 1. - -Optional Properties: - -- rockchip,grf: phandle to the syscon managing the "general register files" - If missing pll rates are not changeable, due to the missing pll lock status. - -Each clock is assigned an identifier and client nodes can use this identifier -to specify the clock which they consume. All available clocks are defined as -preprocessor macros in the dt-bindings/clock/rk3036-cru.h headers and can be -used in device tree sources. Similar macros exist for the reset sources in -these files. - -External clocks: - -There are several clocks that are generated outside the SoC. It is expected -that they are defined using standard clock bindings with following -clock-output-names: - - "xin24m" - crystal input - required, - - "ext_i2s" - external I2S clock - optional, - - "rmii_clkin" - external EMAC clock - optional - -Example: Clock controller node: - - cru: cru@20000000 { - compatible = "rockchip,rk3036-cru"; - reg = <0x20000000 0x1000>; - rockchip,grf = <&grf>; - - #clock-cells = <1>; - #reset-cells = <1>; - }; - -Example: UART controller node that consumes the clock generated by the clock - controller: - - uart0: serial@20060000 { - compatible = "snps,dw-apb-uart"; - reg = <0x20060000 0x100>; - interrupts = <GIC_SPI 20 IRQ_TYPE_LEVEL_HIGH>; - reg-shift = <2>; - reg-io-width = <4>; - clocks = <&cru SCLK_UART0>; - }; diff --git a/Documentation/devicetree/bindings/clock/rockchip,rk3036-cru.yaml b/Documentation/devicetree/bindings/clock/rockchip,rk3036-cru.yaml new file mode 100644 index 000000000000..1376230fede6 --- /dev/null +++ b/Documentation/devicetree/bindings/clock/rockchip,rk3036-cru.yaml @@ -0,0 +1,72 @@ +# SPDX-License-Identifier: GPL-2.0 +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/clock/rockchip,rk3036-cru.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Rockchip RK3036 Clock and Reset Unit (CRU) + +maintainers: + - Elaine Zhang <zhangqing@rock-chips.com> + - Heiko Stuebner <heiko@sntech.de> + +description: | + The RK3036 clock controller generates and supplies clocks to various + controllers within the SoC and also implements a reset controller for SoC + peripherals. + Each clock is assigned an identifier and client nodes can use this identifier + to specify the clock which they consume. All available clocks are defined as + preprocessor macros in the dt-bindings/clock/rk3036-cru.h headers and can be + used in device tree sources. Similar macros exist for the reset sources in + these files. + There are several clocks that are generated outside the SoC. It is expected + that they are defined using standard clock bindings with following + clock-output-names: + - "xin24m" - crystal input - required + - "ext_i2s" - external I2S clock - optional + - "rmii_clkin" - external EMAC clock - optional + +properties: + compatible: + enum: + - rockchip,rk3036-cru + + reg: + maxItems: 1 + + "#clock-cells": + const: 1 + + "#reset-cells": + const: 1 + + clocks: + maxItems: 1 + + clock-names: + const: xin24m + + rockchip,grf: + $ref: /schemas/types.yaml#/definitions/phandle + description: + Phandle to the syscon managing the "general register files" (GRF), + if missing pll rates are not changeable, due to the missing pll + lock status. + +required: + - compatible + - reg + - "#clock-cells" + - "#reset-cells" + +additionalProperties: false + +examples: + - | + cru: clock-controller@20000000 { + compatible = "rockchip,rk3036-cru"; + reg = <0x20000000 0x1000>; + rockchip,grf = <&grf>; + #clock-cells = <1>; + #reset-cells = <1>; + }; diff --git a/Documentation/devicetree/bindings/clock/rockchip,rk3188-cru.txt b/Documentation/devicetree/bindings/clock/rockchip,rk3188-cru.txt deleted file mode 100644 index 7f368530a2e4..000000000000 --- a/Documentation/devicetree/bindings/clock/rockchip,rk3188-cru.txt +++ /dev/null @@ -1,61 +0,0 @@ -* Rockchip RK3188/RK3066 Clock and Reset Unit - -The RK3188/RK3066 clock controller generates and supplies clock to various -controllers within the SoC and also implements a reset controller for SoC -peripherals. - -Required Properties: - -- compatible: should be "rockchip,rk3188-cru", "rockchip,rk3188a-cru" or - "rockchip,rk3066a-cru" -- reg: physical base address of the controller and length of memory mapped - region. -- #clock-cells: should be 1. -- #reset-cells: should be 1. - -Optional Properties: - -- rockchip,grf: phandle to the syscon managing the "general register files" - If missing pll rates are not changeable, due to the missing pll lock status. - -Each clock is assigned an identifier and client nodes can use this identifier -to specify the clock which they consume. All available clocks are defined as -preprocessor macros in the dt-bindings/clock/rk3188-cru.h and -dt-bindings/clock/rk3066-cru.h headers and can be used in device tree sources. -Similar macros exist for the reset sources in these files. - -External clocks: - -There are several clocks that are generated outside the SoC. It is expected -that they are defined using standard clock bindings with following -clock-output-names: - - "xin24m" - crystal input - required, - - "xin32k" - rtc clock - optional, - - "xin27m" - 27mhz crystal input on rk3066 - optional, - - "ext_hsadc" - external HSADC clock - optional, - - "ext_cif0" - external camera clock - optional, - - "ext_rmii" - external RMII clock - optional, - - "ext_jtag" - externalJTAG clock - optional - -Example: Clock controller node: - - cru: cru@20000000 { - compatible = "rockchip,rk3188-cru"; - reg = <0x20000000 0x1000>; - rockchip,grf = <&grf>; - - #clock-cells = <1>; - #reset-cells = <1>; - }; - -Example: UART controller node that consumes the clock generated by the clock - controller: - - uart0: serial@10124000 { - compatible = "snps,dw-apb-uart"; - reg = <0x10124000 0x400>; - interrupts = <GIC_SPI 34 IRQ_TYPE_LEVEL_HIGH>; - reg-shift = <2>; - reg-io-width = <1>; - clocks = <&cru SCLK_UART0>; - }; diff --git a/Documentation/devicetree/bindings/clock/rockchip,rk3188-cru.yaml b/Documentation/devicetree/bindings/clock/rockchip,rk3188-cru.yaml new file mode 100644 index 000000000000..ddd7e46af0f2 --- /dev/null +++ b/Documentation/devicetree/bindings/clock/rockchip,rk3188-cru.yaml @@ -0,0 +1,78 @@ +# SPDX-License-Identifier: GPL-2.0 +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/clock/rockchip,rk3188-cru.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Rockchip RK3188/RK3066 Clock and Reset Unit (CRU) + +maintainers: + - Elaine Zhang <zhangqing@rock-chips.com> + - Heiko Stuebner <heiko@sntech.de> + +description: | + The RK3188/RK3066 clock controller generates and supplies clocks to various + controllers within the SoC and also implements a reset controller for SoC + peripherals. + Each clock is assigned an identifier and client nodes can use this identifier + to specify the clock which they consume. All available clocks are defined as + preprocessor macros in the dt-bindings/clock/rk3188-cru.h and + dt-bindings/clock/rk3066-cru.h headers and can be used in device tree sources. + Similar macros exist for the reset sources in these files. + There are several clocks that are generated outside the SoC. It is expected + that they are defined using standard clock bindings with following + clock-output-names: + - "xin24m" - crystal input - required + - "xin32k" - RTC clock - optional + - "xin27m" - 27mhz crystal input on RK3066 - optional + - "ext_hsadc" - external HSADC clock - optional + - "ext_cif0" - external camera clock - optional + - "ext_rmii" - external RMII clock - optional + - "ext_jtag" - external JTAG clock - optional + +properties: + compatible: + enum: + - rockchip,rk3066a-cru + - rockchip,rk3188-cru + - rockchip,rk3188a-cru + + reg: + maxItems: 1 + + "#clock-cells": + const: 1 + + "#reset-cells": + const: 1 + + clocks: + maxItems: 1 + + clock-names: + const: xin24m + + rockchip,grf: + $ref: /schemas/types.yaml#/definitions/phandle + description: + Phandle to the syscon managing the "general register files" (GRF), + if missing pll rates are not changeable, due to the missing pll + lock status. + +required: + - compatible + - reg + - "#clock-cells" + - "#reset-cells" + +additionalProperties: false + +examples: + - | + cru: clock-controller@20000000 { + compatible = "rockchip,rk3188-cru"; + reg = <0x20000000 0x1000>; + rockchip,grf = <&grf>; + #clock-cells = <1>; + #reset-cells = <1>; + }; diff --git a/Documentation/devicetree/bindings/clock/rockchip,rk3228-cru.txt b/Documentation/devicetree/bindings/clock/rockchip,rk3228-cru.txt deleted file mode 100644 index f323048127eb..000000000000 --- a/Documentation/devicetree/bindings/clock/rockchip,rk3228-cru.txt +++ /dev/null @@ -1,58 +0,0 @@ -* Rockchip RK3228 Clock and Reset Unit - -The RK3228 clock controller generates and supplies clock to various -controllers within the SoC and also implements a reset controller for SoC -peripherals. - -Required Properties: - -- compatible: should be "rockchip,rk3228-cru" -- reg: physical base address of the controller and length of memory mapped - region. -- #clock-cells: should be 1. -- #reset-cells: should be 1. - -Optional Properties: - -- rockchip,grf: phandle to the syscon managing the "general register files" - If missing pll rates are not changeable, due to the missing pll lock status. - -Each clock is assigned an identifier and client nodes can use this identifier -to specify the clock which they consume. All available clocks are defined as -preprocessor macros in the dt-bindings/clock/rk3228-cru.h headers and can be -used in device tree sources. Similar macros exist for the reset sources in -these files. - -External clocks: - -There are several clocks that are generated outside the SoC. It is expected -that they are defined using standard clock bindings with following -clock-output-names: - - "xin24m" - crystal input - required, - - "ext_i2s" - external I2S clock - optional, - - "ext_gmac" - external GMAC clock - optional - - "ext_hsadc" - external HSADC clock - optional - - "phy_50m_out" - output clock of the pll in the mac phy - -Example: Clock controller node: - - cru: cru@20000000 { - compatible = "rockchip,rk3228-cru"; - reg = <0x20000000 0x1000>; - rockchip,grf = <&grf>; - - #clock-cells = <1>; - #reset-cells = <1>; - }; - -Example: UART controller node that consumes the clock generated by the clock - controller: - - uart0: serial@10110000 { - compatible = "snps,dw-apb-uart"; - reg = <0x10110000 0x100>; - interrupts = <GIC_SPI 55 IRQ_TYPE_LEVEL_HIGH>; - reg-shift = <2>; - reg-io-width = <4>; - clocks = <&cru SCLK_UART0>; - }; diff --git a/Documentation/devicetree/bindings/clock/rockchip,rk3228-cru.yaml b/Documentation/devicetree/bindings/clock/rockchip,rk3228-cru.yaml new file mode 100644 index 000000000000..cf7dc01d9478 --- /dev/null +++ b/Documentation/devicetree/bindings/clock/rockchip,rk3228-cru.yaml @@ -0,0 +1,74 @@ +# SPDX-License-Identifier: GPL-2.0 +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/clock/rockchip,rk3228-cru.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Rockchip RK3228 Clock and Reset Unit (CRU) + +maintainers: + - Elaine Zhang <zhangqing@rock-chips.com> + - Heiko Stuebner <heiko@sntech.de> + +description: | + The RK3228 clock controller generates and supplies clocks to various + controllers within the SoC and also implements a reset controller for SoC + peripherals. + Each clock is assigned an identifier and client nodes can use this identifier + to specify the clock which they consume. All available clocks are defined as + preprocessor macros in the dt-bindings/clock/rk3228-cru.h headers and can be + used in device tree sources. Similar macros exist for the reset sources in + these files. + There are several clocks that are generated outside the SoC. It is expected + that they are defined using standard clock bindings with following + clock-output-names: + - "xin24m" - crystal input - required + - "ext_i2s" - external I2S clock - optional + - "ext_gmac" - external GMAC clock - optional + - "ext_hsadc" - external HSADC clock - optional + - "phy_50m_out" - output clock of the pll in the mac phy + +properties: + compatible: + enum: + - rockchip,rk3228-cru + + reg: + maxItems: 1 + + "#clock-cells": + const: 1 + + "#reset-cells": + const: 1 + + clocks: + maxItems: 1 + + clock-names: + const: xin24m + + rockchip,grf: + $ref: /schemas/types.yaml#/definitions/phandle + description: + Phandle to the syscon managing the "general register files" (GRF), + if missing pll rates are not changeable, due to the missing pll + lock status. + +required: + - compatible + - reg + - "#clock-cells" + - "#reset-cells" + +additionalProperties: false + +examples: + - | + cru: clock-controller@20000000 { + compatible = "rockchip,rk3228-cru"; + reg = <0x20000000 0x1000>; + rockchip,grf = <&grf>; + #clock-cells = <1>; + #reset-cells = <1>; + }; diff --git a/Documentation/devicetree/bindings/clock/rockchip,rk3288-cru.txt b/Documentation/devicetree/bindings/clock/rockchip,rk3288-cru.txt deleted file mode 100644 index bf3a9ec19241..000000000000 --- a/Documentation/devicetree/bindings/clock/rockchip,rk3288-cru.txt +++ /dev/null @@ -1,67 +0,0 @@ -* Rockchip RK3288 Clock and Reset Unit - -The RK3288 clock controller generates and supplies clock to various -controllers within the SoC and also implements a reset controller for SoC -peripherals. - -A revision of this SoC is available: rk3288w. The clock tree is a bit -different so another dt-compatible is available. Noticed that it is only -setting the difference but there is no automatic revision detection. This -should be performed by bootloaders. - -Required Properties: - -- compatible: should be "rockchip,rk3288-cru" or "rockchip,rk3288w-cru" in - case of this revision of Rockchip rk3288. -- reg: physical base address of the controller and length of memory mapped - region. -- #clock-cells: should be 1. -- #reset-cells: should be 1. - -Optional Properties: - -- rockchip,grf: phandle to the syscon managing the "general register files" - If missing pll rates are not changeable, due to the missing pll lock status. - -Each clock is assigned an identifier and client nodes can use this identifier -to specify the clock which they consume. All available clocks are defined as -preprocessor macros in the dt-bindings/clock/rk3288-cru.h headers and can be -used in device tree sources. Similar macros exist for the reset sources in -these files. - -External clocks: - -There are several clocks that are generated outside the SoC. It is expected -that they are defined using standard clock bindings with following -clock-output-names: - - "xin24m" - crystal input - required, - - "xin32k" - rtc clock - optional, - - "ext_i2s" - external I2S clock - optional, - - "ext_hsadc" - external HSADC clock - optional, - - "ext_edp_24m" - external display port clock - optional, - - "ext_vip" - external VIP clock - optional, - - "ext_isp" - external ISP clock - optional, - - "ext_jtag" - external JTAG clock - optional - -Example: Clock controller node: - - cru: cru@20000000 { - compatible = "rockchip,rk3188-cru"; - reg = <0x20000000 0x1000>; - rockchip,grf = <&grf>; - - #clock-cells = <1>; - #reset-cells = <1>; - }; - -Example: UART controller node that consumes the clock generated by the clock - controller: - - uart0: serial@10124000 { - compatible = "snps,dw-apb-uart"; - reg = <0x10124000 0x400>; - interrupts = <GIC_SPI 34 IRQ_TYPE_LEVEL_HIGH>; - reg-shift = <2>; - reg-io-width = <1>; - clocks = <&cru SCLK_UART0>; - }; diff --git a/Documentation/devicetree/bindings/clock/rockchip,rk3288-cru.yaml b/Documentation/devicetree/bindings/clock/rockchip,rk3288-cru.yaml new file mode 100644 index 000000000000..96bc05749e1a --- /dev/null +++ b/Documentation/devicetree/bindings/clock/rockchip,rk3288-cru.yaml @@ -0,0 +1,85 @@ +# SPDX-License-Identifier: GPL-2.0 +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/clock/rockchip,rk3288-cru.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Rockchip RK3288 Clock and Reset Unit (CRU) + +maintainers: + - Elaine Zhang <zhangqing@rock-chips.com> + - Heiko Stuebner <heiko@sntech.de> + +description: | + The RK3288 clock controller generates and supplies clocks to various + controllers within the SoC and also implements a reset controller for SoC + peripherals. + + A revision of this SoC is available: rk3288w. The clock tree is a bit + different so another dt-compatible is available. Noticed that it is only + setting the difference but there is no automatic revision detection. This + should be performed by boot loaders. + + Each clock is assigned an identifier and client nodes can use this identifier + to specify the clock which they consume. All available clocks are defined as + preprocessor macros in the dt-bindings/clock/rk3288-cru.h headers and can be + used in device tree sources. Similar macros exist for the reset sources in + these files. + + There are several clocks that are generated outside the SoC. It is expected + that they are defined using standard clock bindings with following + clock-output-names: + - "xin24m" - crystal input - required, + - "xin32k" - rtc clock - optional, + - "ext_i2s" - external I2S clock - optional, + - "ext_hsadc" - external HSADC clock - optional, + - "ext_edp_24m" - external display port clock - optional, + - "ext_vip" - external VIP clock - optional, + - "ext_isp" - external ISP clock - optional, + - "ext_jtag" - external JTAG clock - optional + +properties: + compatible: + enum: + - rockchip,rk3288-cru + - rockchip,rk3288w-cru + + reg: + maxItems: 1 + + "#clock-cells": + const: 1 + + "#reset-cells": + const: 1 + + clocks: + maxItems: 1 + + clock-names: + const: xin24m + + rockchip,grf: + $ref: /schemas/types.yaml#/definitions/phandle + description: + Phandle to the syscon managing the "general register files" (GRF), + if missing pll rates are not changeable, due to the missing pll + lock status. + +required: + - compatible + - reg + - "#clock-cells" + - "#reset-cells" + +additionalProperties: false + +examples: + - | + cru: clock-controller@ff760000 { + compatible = "rockchip,rk3288-cru"; + reg = <0xff760000 0x1000>; + rockchip,grf = <&grf>; + #clock-cells = <1>; + #reset-cells = <1>; + }; diff --git a/Documentation/devicetree/bindings/clock/rockchip,rk3308-cru.txt b/Documentation/devicetree/bindings/clock/rockchip,rk3308-cru.txt deleted file mode 100644 index 9b151c5b0c90..000000000000 --- a/Documentation/devicetree/bindings/clock/rockchip,rk3308-cru.txt +++ /dev/null @@ -1,60 +0,0 @@ -* Rockchip RK3308 Clock and Reset Unit - -The RK3308 clock controller generates and supplies clock to various -controllers within the SoC and also implements a reset controller for SoC -peripherals. - -Required Properties: - -- compatible: CRU should be "rockchip,rk3308-cru" -- reg: physical base address of the controller and length of memory mapped - region. -- #clock-cells: should be 1. -- #reset-cells: should be 1. - -Optional Properties: - -- rockchip,grf: phandle to the syscon managing the "general register files" - If missing, pll rates are not changeable, due to the missing pll lock status. - -Each clock is assigned an identifier and client nodes can use this identifier -to specify the clock which they consume. All available clocks are defined as -preprocessor macros in the dt-bindings/clock/rk3308-cru.h headers and can be -used in device tree sources. Similar macros exist for the reset sources in -these files. - -External clocks: - -There are several clocks that are generated outside the SoC. It is expected -that they are defined using standard clock bindings with following -clock-output-names: - - "xin24m" - crystal input - required, - - "xin32k" - rtc clock - optional, - - "mclk_i2s0_8ch_in", "mclk_i2s1_8ch_in", "mclk_i2s2_8ch_in", - "mclk_i2s3_8ch_in", "mclk_i2s0_2ch_in", - "mclk_i2s1_2ch_in" - external I2S or SPDIF clock - optional, - - "mac_clkin" - external MAC clock - optional - -Example: Clock controller node: - - cru: clock-controller@ff500000 { - compatible = "rockchip,rk3308-cru"; - reg = <0x0 0xff500000 0x0 0x1000>; - rockchip,grf = <&grf>; - #clock-cells = <1>; - #reset-cells = <1>; - }; - -Example: UART controller node that consumes the clock generated by the clock - controller: - - uart0: serial@ff0a0000 { - compatible = "rockchip,rk3308-uart", "snps,dw-apb-uart"; - reg = <0x0 0xff0a0000 0x0 0x100>; - interrupts = <GIC_SPI 18 IRQ_TYPE_LEVEL_HIGH>; - clocks = <&cru SCLK_UART0>, <&cru PCLK_UART0>; - clock-names = "baudclk", "apb_pclk"; - reg-shift = <2>; - reg-io-width = <4>; - status = "disabled"; - }; diff --git a/Documentation/devicetree/bindings/clock/rockchip,rk3308-cru.yaml b/Documentation/devicetree/bindings/clock/rockchip,rk3308-cru.yaml new file mode 100644 index 000000000000..523ee578a586 --- /dev/null +++ b/Documentation/devicetree/bindings/clock/rockchip,rk3308-cru.yaml @@ -0,0 +1,76 @@ +# SPDX-License-Identifier: GPL-2.0 +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/clock/rockchip,rk3308-cru.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Rockchip RK3308 Clock and Reset Unit (CRU) + +maintainers: + - Elaine Zhang <zhangqing@rock-chips.com> + - Heiko Stuebner <heiko@sntech.de> + +description: | + The RK3308 clock controller generates and supplies clocks to various + controllers within the SoC and also implements a reset controller for SoC + peripherals. + Each clock is assigned an identifier and client nodes can use this identifier + to specify the clock which they consume. All available clocks are defined as + preprocessor macros in the dt-bindings/clock/rk3308-cru.h headers and can be + used in device tree sources. Similar macros exist for the reset sources in + these files. + There are several clocks that are generated outside the SoC. It is expected + that they are defined using standard clock bindings with following + clock-output-names: + - "xin24m" - crystal input - required + - "xin32k" - rtc clock - optional + - "mclk_i2s0_8ch_in", "mclk_i2s1_8ch_in", + "mclk_i2s2_8ch_in", "mclk_i2s3_8ch_in", + "mclk_i2s0_2ch_in", "mclk_i2s1_2ch_in" - external I2S or + SPDIF clock - optional + - "mac_clkin" - external MAC clock - optional + +properties: + compatible: + enum: + - rockchip,rk3308-cru + + reg: + maxItems: 1 + + "#clock-cells": + const: 1 + + "#reset-cells": + const: 1 + + clocks: + maxItems: 1 + + clock-names: + const: xin24m + + rockchip,grf: + $ref: /schemas/types.yaml#/definitions/phandle + description: + Phandle to the syscon managing the "general register files" (GRF), + if missing pll rates are not changeable, due to the missing pll + lock status. + +required: + - compatible + - reg + - "#clock-cells" + - "#reset-cells" + +additionalProperties: false + +examples: + - | + cru: clock-controller@ff500000 { + compatible = "rockchip,rk3308-cru"; + reg = <0xff500000 0x1000>; + rockchip,grf = <&grf>; + #clock-cells = <1>; + #reset-cells = <1>; + }; diff --git a/Documentation/devicetree/bindings/clock/rockchip,rk3368-cru.txt b/Documentation/devicetree/bindings/clock/rockchip,rk3368-cru.txt deleted file mode 100644 index 7c8bbcfed8d2..000000000000 --- a/Documentation/devicetree/bindings/clock/rockchip,rk3368-cru.txt +++ /dev/null @@ -1,61 +0,0 @@ -* Rockchip RK3368 Clock and Reset Unit - -The RK3368 clock controller generates and supplies clock to various -controllers within the SoC and also implements a reset controller for SoC -peripherals. - -Required Properties: - -- compatible: should be "rockchip,rk3368-cru" -- reg: physical base address of the controller and length of memory mapped - region. -- #clock-cells: should be 1. -- #reset-cells: should be 1. - -Optional Properties: - -- rockchip,grf: phandle to the syscon managing the "general register files" - If missing, pll rates are not changeable, due to the missing pll lock status. - -Each clock is assigned an identifier and client nodes can use this identifier -to specify the clock which they consume. All available clocks are defined as -preprocessor macros in the dt-bindings/clock/rk3368-cru.h headers and can be -used in device tree sources. Similar macros exist for the reset sources in -these files. - -External clocks: - -There are several clocks that are generated outside the SoC. It is expected -that they are defined using standard clock bindings with following -clock-output-names: - - "xin24m" - crystal input - required, - - "xin32k" - rtc clock - optional, - - "ext_i2s" - external I2S clock - optional, - - "ext_gmac" - external GMAC clock - optional - - "ext_hsadc" - external HSADC clock - optional, - - "ext_isp" - external ISP clock - optional, - - "ext_jtag" - external JTAG clock - optional - - "ext_vip" - external VIP clock - optional, - - "usbotg_out" - output clock of the pll in the otg phy - -Example: Clock controller node: - - cru: clock-controller@ff760000 { - compatible = "rockchip,rk3368-cru"; - reg = <0x0 0xff760000 0x0 0x1000>; - rockchip,grf = <&grf>; - #clock-cells = <1>; - #reset-cells = <1>; - }; - -Example: UART controller node that consumes the clock generated by the clock - controller: - - uart0: serial@10124000 { - compatible = "snps,dw-apb-uart"; - reg = <0x10124000 0x400>; - interrupts = <GIC_SPI 34 IRQ_TYPE_LEVEL_HIGH>; - reg-shift = <2>; - reg-io-width = <1>; - clocks = <&cru SCLK_UART0>; - }; diff --git a/Documentation/devicetree/bindings/clock/rockchip,rk3368-cru.yaml b/Documentation/devicetree/bindings/clock/rockchip,rk3368-cru.yaml new file mode 100644 index 000000000000..adb67877720d --- /dev/null +++ b/Documentation/devicetree/bindings/clock/rockchip,rk3368-cru.yaml @@ -0,0 +1,78 @@ +# SPDX-License-Identifier: GPL-2.0 +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/clock/rockchip,rk3368-cru.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Rockchip RK3368 Clock and Reset Unit (CRU) + +maintainers: + - Elaine Zhang <zhangqing@rock-chips.com> + - Heiko Stuebner <heiko@sntech.de> + +description: | + The RK3368 clock controller generates and supplies clocks to various + controllers within the SoC and also implements a reset controller for SoC + peripherals. + Each clock is assigned an identifier and client nodes can use this identifier + to specify the clock which they consume. All available clocks are defined as + preprocessor macros in the dt-bindings/clock/rk3368-cru.h headers and can be + used in device tree sources. Similar macros exist for the reset sources in + these files. + There are several clocks that are generated outside the SoC. It is expected + that they are defined using standard clock bindings with following + clock-output-names: + - "xin24m" - crystal input - required + - "xin32k" - rtc clock - optional + - "ext_i2s" - external I2S clock - optional + - "ext_gmac" - external GMAC clock - optional + - "ext_hsadc" - external HSADC clock - optional + - "ext_isp" - external ISP clock - optional + - "ext_jtag" - external JTAG clock - optional + - "ext_vip" - external VIP clock - optional + - "usbotg_out" - output clock of the pll in the otg phy + +properties: + compatible: + enum: + - rockchip,rk3368-cru + + reg: + maxItems: 1 + + "#clock-cells": + const: 1 + + "#reset-cells": + const: 1 + + clocks: + maxItems: 1 + + clock-names: + const: xin24m + + rockchip,grf: + $ref: /schemas/types.yaml#/definitions/phandle + description: + Phandle to the syscon managing the "general register files" (GRF), + if missing pll rates are not changeable, due to the missing pll + lock status. + +required: + - compatible + - reg + - "#clock-cells" + - "#reset-cells" + +additionalProperties: false + +examples: + - | + cru: clock-controller@ff760000 { + compatible = "rockchip,rk3368-cru"; + reg = <0xff760000 0x1000>; + rockchip,grf = <&grf>; + #clock-cells = <1>; + #reset-cells = <1>; + }; diff --git a/Documentation/devicetree/bindings/clock/rockchip,rk3399-cru.yaml b/Documentation/devicetree/bindings/clock/rockchip,rk3399-cru.yaml index 72b286a1beba..54da1e31ea73 100644 --- a/Documentation/devicetree/bindings/clock/rockchip,rk3399-cru.yaml +++ b/Documentation/devicetree/bindings/clock/rockchip,rk3399-cru.yaml @@ -7,7 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml# title: Rockchip RK3399 Clock and Reset Unit maintainers: - - Xing Zheng <zhengxing@rock-chips.com> + - Elaine Zhang <zhangqing@rock-chips.com> - Heiko Stuebner <heiko@sntech.de> description: | @@ -22,11 +22,11 @@ description: | There are several clocks that are generated outside the SoC. It is expected that they are defined using standard clock bindings with following clock-output-names: - - "xin24m" - crystal input - required, - - "xin32k" - rtc clock - optional, - - "clkin_gmac" - external GMAC clock - optional, - - "clkin_i2s" - external I2S clock - optional, - - "pclkin_cif" - external ISP clock - optional, + - "xin24m" - crystal input - required, + - "xin32k" - rtc clock - optional, + - "clkin_gmac" - external GMAC clock - optional, + - "clkin_i2s" - external I2S clock - optional, + - "pclkin_cif" - external ISP clock - optional, - "clk_usbphy0_480m" - output clock of the pll in the usbphy0 - "clk_usbphy1_480m" - output clock of the pll in the usbphy1 @@ -46,24 +46,15 @@ properties: const: 1 clocks: - minItems: 1 - - assigned-clocks: - minItems: 1 - maxItems: 64 - - assigned-clock-parents: - minItems: 1 - maxItems: 64 + maxItems: 1 - assigned-clock-rates: - minItems: 1 - maxItems: 64 + clock-names: + const: xin24m rockchip,grf: $ref: /schemas/types.yaml#/definitions/phandle - description: > - phandle to the syscon managing the "general register files". It is used + description: + Phandle to the syscon managing the "general register files". It is used for GRF muxes, if missing any muxes present in the GRF will not be available. @@ -77,7 +68,7 @@ additionalProperties: false examples: - | - pmucru: pmu-clock-controller@ff750000 { + pmucru: clock-controller@ff750000 { compatible = "rockchip,rk3399-pmucru"; reg = <0xff750000 0x1000>; #clock-cells = <1>; diff --git a/Documentation/devicetree/bindings/clock/rockchip,rk3568-cru.yaml b/Documentation/devicetree/bindings/clock/rockchip,rk3568-cru.yaml index b2c26097827f..fc7546f521c5 100644 --- a/Documentation/devicetree/bindings/clock/rockchip,rk3568-cru.yaml +++ b/Documentation/devicetree/bindings/clock/rockchip,rk3568-cru.yaml @@ -34,6 +34,19 @@ properties: "#reset-cells": const: 1 + clocks: + maxItems: 1 + + clock-names: + const: xin24m + + rockchip,grf: + $ref: /schemas/types.yaml#/definitions/phandle + description: + Phandle to the syscon managing the "general register files" (GRF), + if missing pll rates are not changeable, due to the missing pll + lock status. + required: - compatible - reg diff --git a/Documentation/devicetree/bindings/clock/rockchip,rv1108-cru.txt b/Documentation/devicetree/bindings/clock/rockchip,rv1108-cru.txt deleted file mode 100644 index 161326a4f9c1..000000000000 --- a/Documentation/devicetree/bindings/clock/rockchip,rv1108-cru.txt +++ /dev/null @@ -1,59 +0,0 @@ -* Rockchip RV1108 Clock and Reset Unit - -The RV1108 clock controller generates and supplies clock to various -controllers within the SoC and also implements a reset controller for SoC -peripherals. - -Required Properties: - -- compatible: should be "rockchip,rv1108-cru" -- reg: physical base address of the controller and length of memory mapped - region. -- #clock-cells: should be 1. -- #reset-cells: should be 1. - -Optional Properties: - -- rockchip,grf: phandle to the syscon managing the "general register files" - If missing pll rates are not changeable, due to the missing pll lock status. - -Each clock is assigned an identifier and client nodes can use this identifier -to specify the clock which they consume. All available clocks are defined as -preprocessor macros in the dt-bindings/clock/rv1108-cru.h headers and can be -used in device tree sources. Similar macros exist for the reset sources in -these files. - -External clocks: - -There are several clocks that are generated outside the SoC. It is expected -that they are defined using standard clock bindings with following -clock-output-names: - - "xin24m" - crystal input - required, - - "ext_vip" - external VIP clock - optional - - "ext_i2s" - external I2S clock - optional - - "ext_gmac" - external GMAC clock - optional - - "hdmiphy" - external clock input derived from HDMI PHY - optional - - "usbphy" - external clock input derived from USB PHY - optional - -Example: Clock controller node: - - cru: cru@20200000 { - compatible = "rockchip,rv1108-cru"; - reg = <0x20200000 0x1000>; - rockchip,grf = <&grf>; - - #clock-cells = <1>; - #reset-cells = <1>; - }; - -Example: UART controller node that consumes the clock generated by the clock - controller: - - uart0: serial@10230000 { - compatible = "rockchip,rv1108-uart", "snps,dw-apb-uart"; - reg = <0x10230000 0x100>; - interrupts = <GIC_SPI 44 IRQ_TYPE_LEVEL_HIGH>; - reg-shift = <2>; - reg-io-width = <4>; - clocks = <&cru SCLK_UART0>; - }; diff --git a/Documentation/devicetree/bindings/clock/rockchip,rv1108-cru.yaml b/Documentation/devicetree/bindings/clock/rockchip,rv1108-cru.yaml new file mode 100644 index 000000000000..20421c22f184 --- /dev/null +++ b/Documentation/devicetree/bindings/clock/rockchip,rv1108-cru.yaml @@ -0,0 +1,75 @@ +# SPDX-License-Identifier: GPL-2.0 +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/clock/rockchip,rv1108-cru.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Rockchip RV1108 Clock and Reset Unit (CRU) + +maintainers: + - Elaine Zhang <zhangqing@rock-chips.com> + - Heiko Stuebner <heiko@sntech.de> + +description: | + The RV1108 clock controller generates and supplies clocks to various + controllers within the SoC and also implements a reset controller for SoC + peripherals. + Each clock is assigned an identifier and client nodes can use this identifier + to specify the clock which they consume. All available clocks are defined as + preprocessor macros in the dt-bindings/clock/rv1108-cru.h headers and can be + used in device tree sources. Similar macros exist for the reset sources in + these files. + There are several clocks that are generated outside the SoC. It is expected + that they are defined using standard clock bindings with following + clock-output-names: + - "xin24m" - crystal input - required + - "ext_vip" - external VIP clock - optional + - "ext_i2s" - external I2S clock - optional + - "ext_gmac" - external GMAC clock - optional + - "hdmiphy" - external clock input derived from HDMI PHY - optional + - "usbphy" - external clock input derived from USB PHY - optional + +properties: + compatible: + enum: + - rockchip,rv1108-cru + + reg: + maxItems: 1 + + "#clock-cells": + const: 1 + + "#reset-cells": + const: 1 + + clocks: + maxItems: 1 + + clock-names: + const: xin24m + + rockchip,grf: + $ref: /schemas/types.yaml#/definitions/phandle + description: + Phandle to the syscon managing the "general register files" (GRF), + if missing pll rates are not changeable, due to the missing pll + lock status. + +required: + - compatible + - reg + - "#clock-cells" + - "#reset-cells" + +additionalProperties: false + +examples: + - | + cru: clock-controller@20200000 { + compatible = "rockchip,rv1108-cru"; + reg = <0x20200000 0x1000>; + rockchip,grf = <&grf>; + #clock-cells = <1>; + #reset-cells = <1>; + }; diff --git a/Documentation/devicetree/bindings/clock/st,stm32mp1-rcc.yaml b/Documentation/devicetree/bindings/clock/st,stm32mp1-rcc.yaml index 45b94124366c..f8c474227807 100644 --- a/Documentation/devicetree/bindings/clock/st,stm32mp1-rcc.yaml +++ b/Documentation/devicetree/bindings/clock/st,stm32mp1-rcc.yaml @@ -41,6 +41,7 @@ description: | The list of valid indices for STM32MP1 is available in: include/dt-bindings/reset-controller/stm32mp1-resets.h + include/dt-bindings/reset-controller/stm32mp13-resets.h This file implements defines like: #define LTDC_R 3072 @@ -57,6 +58,7 @@ properties: - enum: - st,stm32mp1-rcc-secure - st,stm32mp1-rcc + - st,stm32mp13-rcc - const: syscon clocks: true clock-names: true diff --git a/Documentation/devicetree/bindings/clock/stericsson,u8500-clks.yaml b/Documentation/devicetree/bindings/clock/stericsson,u8500-clks.yaml index 9bc95a308477..2150307219a0 100644 --- a/Documentation/devicetree/bindings/clock/stericsson,u8500-clks.yaml +++ b/Documentation/devicetree/bindings/clock/stericsson,u8500-clks.yaml @@ -109,6 +109,25 @@ properties: additionalProperties: false + clkout-clock: + description: A subnode with three clock cells for externally routed clocks, + output clocks. These are two PRCMU-internal clocks that can be divided and + muxed out on the pads of the DB8500 SoC. + type: object + + properties: + '#clock-cells': + description: + The first cell indicates which output clock we are using, + possible values are 0 (CLKOUT1) and 1 (CLKOUT2). + The second cell indicates which clock we want to use as source, + possible values are 0 thru 7, see the defines for the different + source clocks. + The third cell is a divider, legal values are 1 thru 63. + const: 3 + + additionalProperties: false + required: - compatible - reg @@ -119,3 +138,41 @@ required: - smp-twd-clock additionalProperties: false + +examples: + - | + #include <dt-bindings/clock/ste-db8500-clkout.h> + clocks@8012 { + compatible = "stericsson,u8500-clks"; + reg = <0x8012f000 0x1000>, <0x8011f000 0x1000>, + <0x8000f000 0x1000>, <0xa03ff000 0x1000>, + <0xa03cf000 0x1000>; + + prcmu_clk: prcmu-clock { + #clock-cells = <1>; + }; + + prcc_pclk: prcc-periph-clock { + #clock-cells = <2>; + }; + + prcc_kclk: prcc-kernel-clock { + #clock-cells = <2>; + }; + + prcc_reset: prcc-reset-controller { + #reset-cells = <2>; + }; + + rtc_clk: rtc32k-clock { + #clock-cells = <0>; + }; + + smp_twd_clk: smp-twd-clock { + #clock-cells = <0>; + }; + + clkout_clk: clkout-clock { + #clock-cells = <3>; + }; + }; diff --git a/Documentation/devicetree/bindings/clock/ti,am654-ehrpwm-tbclk.yaml b/Documentation/devicetree/bindings/clock/ti,am654-ehrpwm-tbclk.yaml index 9b537bc876b5..66765116aff5 100644 --- a/Documentation/devicetree/bindings/clock/ti,am654-ehrpwm-tbclk.yaml +++ b/Documentation/devicetree/bindings/clock/ti,am654-ehrpwm-tbclk.yaml @@ -15,6 +15,7 @@ properties: - enum: - ti,am654-ehrpwm-tbclk - ti,am64-epwm-tbclk + - ti,am62-epwm-tbclk - const: syscon "#clock-cells": diff --git a/Documentation/devicetree/bindings/cpufreq/cpufreq-mediatek.txt b/Documentation/devicetree/bindings/cpufreq/cpufreq-mediatek.txt index b8233ec91d3d..e0a4ba599abc 100644 --- a/Documentation/devicetree/bindings/cpufreq/cpufreq-mediatek.txt +++ b/Documentation/devicetree/bindings/cpufreq/cpufreq-mediatek.txt @@ -20,6 +20,13 @@ Optional properties: Vsram to fit SoC specific needs. When absent, the voltage scaling flow is handled by hardware, hence no software "voltage tracking" is needed. +- mediatek,cci: + Used to confirm the link status between cpufreq and mediatek cci. Because + cpufreq and mediatek cci could share the same regulator in some MediaTek SoCs. + To prevent the issue of high frequency and low voltage, we need to use this + property to make sure mediatek cci is ready. + For details of mediatek cci, please refer to + Documentation/devicetree/bindings/interconnect/mediatek,cci.yaml - #cooling-cells: For details, please refer to Documentation/devicetree/bindings/thermal/thermal-cooling-devices.yaml diff --git a/Documentation/devicetree/bindings/crypto/ti,sa2ul.yaml b/Documentation/devicetree/bindings/crypto/ti,sa2ul.yaml index a410d2cedde6..02f47c2e7998 100644 --- a/Documentation/devicetree/bindings/crypto/ti,sa2ul.yaml +++ b/Documentation/devicetree/bindings/crypto/ti,sa2ul.yaml @@ -15,6 +15,7 @@ properties: - ti,j721e-sa2ul - ti,am654-sa2ul - ti,am64-sa2ul + - ti,am62-sa3ul reg: maxItems: 1 diff --git a/Documentation/devicetree/bindings/dma/allwinner,sun50i-a64-dma.yaml b/Documentation/devicetree/bindings/dma/allwinner,sun50i-a64-dma.yaml index b6e1ebfaf366..ff0a5c58d78c 100644 --- a/Documentation/devicetree/bindings/dma/allwinner,sun50i-a64-dma.yaml +++ b/Documentation/devicetree/bindings/dma/allwinner,sun50i-a64-dma.yaml @@ -20,9 +20,11 @@ properties: compatible: oneOf: - - const: allwinner,sun50i-a64-dma - - const: allwinner,sun50i-a100-dma - - const: allwinner,sun50i-h6-dma + - enum: + - allwinner,sun20i-d1-dma + - allwinner,sun50i-a64-dma + - allwinner,sun50i-a100-dma + - allwinner,sun50i-h6-dma - items: - const: allwinner,sun8i-r40-dma - const: allwinner,sun50i-a64-dma @@ -58,6 +60,7 @@ if: properties: compatible: enum: + - allwinner,sun20i-d1-dma - allwinner,sun50i-a100-dma - allwinner,sun50i-h6-dma diff --git a/Documentation/devicetree/bindings/dma/altr,msgdma.yaml b/Documentation/devicetree/bindings/dma/altr,msgdma.yaml index b193ee2db4a7..b53ac7631a76 100644 --- a/Documentation/devicetree/bindings/dma/altr,msgdma.yaml +++ b/Documentation/devicetree/bindings/dma/altr,msgdma.yaml @@ -7,7 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml# title: Altera mSGDMA IP core maintainers: - - Olivier Dautricourt <olivier.dautricourt@orolia.com> + - Olivier Dautricourt <olivierdautricourt@gmail.com> description: | Altera / Intel modular Scatter-Gather Direct Memory Access (mSGDMA) diff --git a/Documentation/devicetree/bindings/dma/arm,pl330.yaml b/Documentation/devicetree/bindings/dma/arm,pl330.yaml index decab185cf4d..2bec69b308f8 100644 --- a/Documentation/devicetree/bindings/dma/arm,pl330.yaml +++ b/Documentation/devicetree/bindings/dma/arm,pl330.yaml @@ -55,6 +55,9 @@ properties: dma-coherent: true + power-domains: + maxItems: 1 + resets: minItems: 1 maxItems: 2 diff --git a/Documentation/devicetree/bindings/dma/mmp-dma.txt b/Documentation/devicetree/bindings/dma/mmp-dma.txt index 8f7364a7b349..ec18bf0a802a 100644 --- a/Documentation/devicetree/bindings/dma/mmp-dma.txt +++ b/Documentation/devicetree/bindings/dma/mmp-dma.txt @@ -10,10 +10,12 @@ Required properties: or one irq for pdma device Optional properties: -- #dma-channels: Number of DMA channels supported by the controller (defaults +- dma-channels: Number of DMA channels supported by the controller (defaults to 32 when not specified) -- #dma-requests: Number of DMA requestor lines supported by the controller +- #dma-channels: deprecated +- dma-requests: Number of DMA requestor lines supported by the controller (defaults to 32 when not specified) +- #dma-requests: deprecated "marvell,pdma-1.0" Used platforms: pxa25x, pxa27x, pxa3xx, pxa93x, pxa168, pxa910, pxa688. @@ -33,7 +35,7 @@ pdma: dma-controller@d4000000 { reg = <0xd4000000 0x10000>; interrupts = <0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15>; interrupt-parent = <&intcmux32>; - #dma-channels = <16>; + dma-channels = <16>; }; /* @@ -45,7 +47,7 @@ pdma: dma-controller@d4000000 { compatible = "marvell,pdma-1.0"; reg = <0xd4000000 0x10000>; interrupts = <47>; - #dma-channels = <16>; + dma-channels = <16>; }; diff --git a/Documentation/devicetree/bindings/dma/nvidia,tegra186-gpc-dma.yaml b/Documentation/devicetree/bindings/dma/nvidia,tegra186-gpc-dma.yaml new file mode 100644 index 000000000000..9dd1476d1849 --- /dev/null +++ b/Documentation/devicetree/bindings/dma/nvidia,tegra186-gpc-dma.yaml @@ -0,0 +1,110 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/dma/nvidia,tegra186-gpc-dma.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: NVIDIA Tegra GPC DMA Controller Device Tree Bindings + +description: | + The Tegra General Purpose Central (GPC) DMA controller is used for faster + data transfers between memory to memory, memory to device and device to + memory. + +maintainers: + - Jon Hunter <jonathanh@nvidia.com> + - Rajesh Gumasta <rgumasta@nvidia.com> + +allOf: + - $ref: "dma-controller.yaml#" + +properties: + compatible: + oneOf: + - const: nvidia,tegra186-gpcdma + - items: + - const: nvidia,tegra194-gpcdma + - const: nvidia,tegra186-gpcdma + + "#dma-cells": + const: 1 + + reg: + maxItems: 1 + + interrupts: + description: + Should contain all of the per-channel DMA interrupts in + ascending order with respect to the DMA channel index. + minItems: 1 + maxItems: 31 + + resets: + maxItems: 1 + + reset-names: + const: gpcdma + + iommus: + maxItems: 1 + + dma-coherent: true + +required: + - compatible + - reg + - interrupts + - resets + - reset-names + - "#dma-cells" + - iommus + +additionalProperties: false + +examples: + - | + #include <dt-bindings/interrupt-controller/arm-gic.h> + #include <dt-bindings/memory/tegra186-mc.h> + #include <dt-bindings/reset/tegra186-reset.h> + + dma-controller@2600000 { + compatible = "nvidia,tegra186-gpcdma"; + reg = <0x2600000 0x210000>; + resets = <&bpmp TEGRA186_RESET_GPCDMA>; + reset-names = "gpcdma"; + interrupts = <GIC_SPI 76 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 77 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 78 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 79 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 80 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 81 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 82 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 83 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 84 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 85 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 86 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 87 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 88 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 89 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 90 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 91 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 92 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 93 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 94 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 95 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 96 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 97 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 98 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 99 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 100 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 101 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 102 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 103 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 104 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 105 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 106 IRQ_TYPE_LEVEL_HIGH>; + #dma-cells = <1>; + iommus = <&smmu TEGRA186_SID_GPCDMA_0>; + dma-coherent; + }; +... diff --git a/Documentation/devicetree/bindings/dma/qcom,gpi.yaml b/Documentation/devicetree/bindings/dma/qcom,gpi.yaml index d09d79d7406a..7d2fc4eb5530 100644 --- a/Documentation/devicetree/bindings/dma/qcom,gpi.yaml +++ b/Documentation/devicetree/bindings/dma/qcom,gpi.yaml @@ -19,9 +19,12 @@ allOf: properties: compatible: enum: + - qcom,sc7280-gpi-dma - qcom,sdm845-gpi-dma - qcom,sm8150-gpi-dma - qcom,sm8250-gpi-dma + - qcom,sm8350-gpi-dma + - qcom,sm8450-gpi-dma reg: maxItems: 1 diff --git a/Documentation/devicetree/bindings/dma/renesas,rcar-dmac.yaml b/Documentation/devicetree/bindings/dma/renesas,rcar-dmac.yaml index 7c6badf39921..7202cd68e759 100644 --- a/Documentation/devicetree/bindings/dma/renesas,rcar-dmac.yaml +++ b/Documentation/devicetree/bindings/dma/renesas,rcar-dmac.yaml @@ -42,11 +42,10 @@ properties: - const: renesas,rcar-dmac - items: - - const: renesas,dmac-r8a779a0 # R-Car V3U - - - items: - - const: renesas,dmac-r8a779f0 # R-Car S4-8 - - const: renesas,rcar-gen4-dmac + - enum: + - renesas,dmac-r8a779a0 # R-Car V3U + - renesas,dmac-r8a779f0 # R-Car S4-8 + - const: renesas,rcar-gen4-dmac # R-Car Gen4 reg: true @@ -121,7 +120,6 @@ if: compatible: contains: enum: - - renesas,dmac-r8a779a0 - renesas,rcar-gen4-dmac then: properties: diff --git a/Documentation/devicetree/bindings/dma/renesas,rzn1-dmamux.yaml b/Documentation/devicetree/bindings/dma/renesas,rzn1-dmamux.yaml new file mode 100644 index 000000000000..d83013b0dd74 --- /dev/null +++ b/Documentation/devicetree/bindings/dma/renesas,rzn1-dmamux.yaml @@ -0,0 +1,51 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/dma/renesas,rzn1-dmamux.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Renesas RZ/N1 DMA mux + +maintainers: + - Miquel Raynal <miquel.raynal@bootlin.com> + +allOf: + - $ref: "dma-router.yaml#" + +properties: + compatible: + const: renesas,rzn1-dmamux + + reg: + maxItems: 1 + description: DMA mux first register offset within the system control parent. + + '#dma-cells': + const: 6 + description: + The first four cells are dedicated to the master DMA controller. The fifth + cell gives the DMA mux bit index that must be set starting from 0. The + sixth cell gives the binary value that must be written there, ie. 0 or 1. + + dma-masters: + minItems: 1 + maxItems: 2 + + dma-requests: + const: 32 + +required: + - reg + - dma-requests + +additionalProperties: false + +examples: + - | + dma-router@a0 { + compatible = "renesas,rzn1-dmamux"; + reg = <0xa0 4>; + #dma-cells = <6>; + dma-masters = <&dma0 &dma1>; + dma-requests = <32>; + }; diff --git a/Documentation/devicetree/bindings/dma/sifive,fu540-c000-pdma.yaml b/Documentation/devicetree/bindings/dma/sifive,fu540-c000-pdma.yaml index 47c46af25536..3271755787b4 100644 --- a/Documentation/devicetree/bindings/dma/sifive,fu540-c000-pdma.yaml +++ b/Documentation/devicetree/bindings/dma/sifive,fu540-c000-pdma.yaml @@ -28,7 +28,15 @@ allOf: properties: compatible: items: - - const: sifive,fu540-c000-pdma + - enum: + - sifive,fu540-c000-pdma + - const: sifive,pdma0 + description: + Should be "sifive,<chip>-pdma" and "sifive,pdma<version>". + Supported compatible strings are - + "sifive,fu540-c000-pdma" for the SiFive PDMA v0 as integrated onto the + SiFive FU540 chip resp and "sifive,pdma0" for the SiFive PDMA v0 IP block + with no chip integration tweaks. reg: maxItems: 1 @@ -37,6 +45,12 @@ properties: minItems: 1 maxItems: 8 + dma-channels: + description: For backwards-compatibility, the default value is 4 + minimum: 1 + maximum: 4 + default: 4 + '#dma-cells': const: 1 @@ -50,8 +64,9 @@ unevaluatedProperties: false examples: - | dma-controller@3000000 { - compatible = "sifive,fu540-c000-pdma"; + compatible = "sifive,fu540-c000-pdma", "sifive,pdma0"; reg = <0x3000000 0x8000>; + dma-channels = <4>; interrupts = <23>, <24>, <25>, <26>, <27>, <28>, <29>, <30>; #dma-cells = <1>; }; diff --git a/Documentation/devicetree/bindings/dma/snps,dma-spear1340.yaml b/Documentation/devicetree/bindings/dma/snps,dma-spear1340.yaml index 6b35089ac017..c13649bf7f19 100644 --- a/Documentation/devicetree/bindings/dma/snps,dma-spear1340.yaml +++ b/Documentation/devicetree/bindings/dma/snps,dma-spear1340.yaml @@ -15,7 +15,13 @@ allOf: properties: compatible: - const: snps,dma-spear1340 + oneOf: + - const: snps,dma-spear1340 + - items: + - enum: + - renesas,r9a06g032-dma + - const: renesas,rzn1-dma + "#dma-cells": minimum: 3 diff --git a/Documentation/devicetree/bindings/dma/sprd-dma.txt b/Documentation/devicetree/bindings/dma/sprd-dma.txt index adccea9941f1..c7e9b5fd50e7 100644 --- a/Documentation/devicetree/bindings/dma/sprd-dma.txt +++ b/Documentation/devicetree/bindings/dma/sprd-dma.txt @@ -8,10 +8,13 @@ Required properties: - interrupts: Should contain one interrupt shared by all channel. - #dma-cells: must be <1>. Used to represent the number of integer cells in the dmas property of client device. -- #dma-channels : Number of DMA channels supported. Should be 32. +- dma-channels : Number of DMA channels supported. Should be 32. - clock-names: Should contain the clock of the DMA controller. - clocks: Should contain a clock specifier for each entry in clock-names. +Deprecated properties: +- #dma-channels : Number of DMA channels supported. Should be 32. + Example: Controller: @@ -20,7 +23,7 @@ apdma: dma-controller@20100000 { reg = <0x20100000 0x4000>; interrupts = <GIC_SPI 50 IRQ_TYPE_LEVEL_HIGH>; #dma-cells = <1>; - #dma-channels = <32>; + dma-channels = <32>; clock-names = "enable"; clocks = <&clk_ap_ahb_gates 5>; }; diff --git a/Documentation/devicetree/bindings/dma/xilinx/xilinx_dma.txt b/Documentation/devicetree/bindings/dma/xilinx/xilinx_dma.txt index 325aca52cd43..d1700a5c36bf 100644 --- a/Documentation/devicetree/bindings/dma/xilinx/xilinx_dma.txt +++ b/Documentation/devicetree/bindings/dma/xilinx/xilinx_dma.txt @@ -110,7 +110,11 @@ axi_vdma_0: axivdma@40030000 { Required properties: - dmas: a list of <[Video DMA device phandle] [Channel ID]> pairs, where Channel ID is '0' for write/tx and '1' for read/rx - channel. + channel. For MCMDA, MM2S channel(write/tx) ID start from + '0' and is in [0-15] range. S2MM channel(read/rx) ID start + from '16' and is in [16-31] range. These channels ID are + fixed irrespective of IP configuration. + - dma-names: a list of DMA channel names, one per "dmas" entry Example: diff --git a/Documentation/devicetree/bindings/gpio/gpio-consumer-common.yaml b/Documentation/devicetree/bindings/gpio/gpio-consumer-common.yaml new file mode 100644 index 000000000000..40d0be31e200 --- /dev/null +++ b/Documentation/devicetree/bindings/gpio/gpio-consumer-common.yaml @@ -0,0 +1,64 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/gpio/gpio-consumer-common.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Common GPIO lines + +maintainers: + - Bartosz Golaszewski <brgl@bgdev.pl> + - Linus Walleij <linus.walleij@linaro.org> + +description: + Pay attention to using proper GPIO flag (e.g. GPIO_ACTIVE_LOW) for the GPIOs + using inverted signal (e.g. RESETN). + +select: true + +properties: + enable-gpios: + maxItems: 1 + description: + GPIO connected to the enable control pin. + + reset-gpios: + description: + GPIO (or GPIOs for power sequence) connected to the device reset pin + (e.g. RESET or RESETN). + + powerdown-gpios: + maxItems: 1 + description: + GPIO connected to the power down pin (hardware power down or power cut, + e.g. PD or PWDN). + + pwdn-gpios: + maxItems: 1 + description: Use powerdown-gpios + deprecated: true + + wakeup-gpios: + maxItems: 1 + description: + GPIO connected to the pin waking up the device from suspend or other + power-saving modes. + +allOf: + - if: + properties: + compatible: + contains: + enum: + - mmc-pwrseq-simple + then: + properties: + reset-gpios: + minItems: 1 + maxItems: 32 + else: + properties: + reset-gpios: + maxItems: 1 + +additionalProperties: true diff --git a/Documentation/devicetree/bindings/gpio/gpio-pca95xx.yaml b/Documentation/devicetree/bindings/gpio/gpio-pca95xx.yaml index dc0fc8fc4839..977b14db09b0 100644 --- a/Documentation/devicetree/bindings/gpio/gpio-pca95xx.yaml +++ b/Documentation/devicetree/bindings/gpio/gpio-pca95xx.yaml @@ -30,6 +30,7 @@ properties: - maxim,max7325 - maxim,max7326 - maxim,max7327 + - nxp,pca6408 - nxp,pca6416 - nxp,pca9505 - nxp,pca9506 diff --git a/Documentation/devicetree/bindings/gpio/realtek,otto-gpio.yaml b/Documentation/devicetree/bindings/gpio/realtek,otto-gpio.yaml index 100f20cebd76..39fd959c45d2 100644 --- a/Documentation/devicetree/bindings/gpio/realtek,otto-gpio.yaml +++ b/Documentation/devicetree/bindings/gpio/realtek,otto-gpio.yaml @@ -28,10 +28,11 @@ properties: - enum: - realtek,rtl8380-gpio - realtek,rtl8390-gpio + - realtek,rtl9300-gpio + - realtek,rtl9310-gpio - const: realtek,otto-gpio - reg: - maxItems: 1 + reg: true "#gpio-cells": const: 2 @@ -50,6 +51,23 @@ properties: interrupts: maxItems: 1 +if: + properties: + compatible: + contains: + const: realtek,rtl9300-gpio +then: + properties: + reg: + items: + - description: GPIO and interrupt control + - description: interrupt CPU map +else: + properties: + reg: + items: + - description: GPIO and interrupt control + required: - compatible - reg @@ -74,5 +92,17 @@ examples: interrupt-parent = <&rtlintc>; interrupts = <23>; }; + - | + gpio@3300 { + compatible = "realtek,rtl9300-gpio", "realtek,otto-gpio"; + reg = <0x3300 0x1c>, <0x3338 0x8>; + gpio-controller; + #gpio-cells = <2>; + ngpios = <24>; + interrupt-controller; + #interrupt-cells = <2>; + interrupt-parent = <&rtlintc>; + interrupts = <13>; + }; ... diff --git a/Documentation/devicetree/bindings/gpio/renesas,rcar-gpio.yaml b/Documentation/devicetree/bindings/gpio/renesas,rcar-gpio.yaml index f2541739ee3b..0681a4790cd6 100644 --- a/Documentation/devicetree/bindings/gpio/renesas,rcar-gpio.yaml +++ b/Documentation/devicetree/bindings/gpio/renesas,rcar-gpio.yaml @@ -51,6 +51,11 @@ properties: - items: - const: renesas,gpio-r8a779a0 # R-Car V3U + - items: + - enum: + - renesas,gpio-r8a779f0 # R-Car S4-8 + - const: renesas,rcar-gen4-gpio # R-Car Gen4 + reg: maxItems: 1 diff --git a/Documentation/devicetree/bindings/gpio/socionext,uniphier-gpio.yaml b/Documentation/devicetree/bindings/gpio/socionext,uniphier-gpio.yaml index bcafa494ed7a..228fa27ffdc3 100644 --- a/Documentation/devicetree/bindings/gpio/socionext,uniphier-gpio.yaml +++ b/Documentation/devicetree/bindings/gpio/socionext,uniphier-gpio.yaml @@ -52,6 +52,23 @@ properties: <child-interrupt-base parent-interrupt-base length> triplets. $ref: /schemas/types.yaml#/definitions/uint32-matrix +patternProperties: + "^.+-hog(-[0-9]+)?$": + type: object + properties: + gpio-hog: true + gpios: true + input: true + output-high: true + output-low: true + line-name: true + + required: + - gpio-hog + - gpios + + additionalProperties: false + required: - compatible - reg diff --git a/Documentation/devicetree/bindings/i2c/renesas,rcar-i2c.yaml b/Documentation/devicetree/bindings/i2c/renesas,rcar-i2c.yaml index c30107833a51..f9929578c761 100644 --- a/Documentation/devicetree/bindings/i2c/renesas,rcar-i2c.yaml +++ b/Documentation/devicetree/bindings/i2c/renesas,rcar-i2c.yaml @@ -46,11 +46,11 @@ properties: - renesas,i2c-r8a77980 # R-Car V3H - renesas,i2c-r8a77990 # R-Car E3 - renesas,i2c-r8a77995 # R-Car D3 - - renesas,i2c-r8a779a0 # R-Car V3U - const: renesas,rcar-gen3-i2c # R-Car Gen3 and RZ/G2 - items: - enum: + - renesas,i2c-r8a779a0 # R-Car V3U - renesas,i2c-r8a779f0 # R-Car S4-8 - const: renesas,rcar-gen4-i2c # R-Car Gen4 diff --git a/Documentation/devicetree/bindings/i3c/cdns,i3c-master.txt b/Documentation/devicetree/bindings/i3c/cdns,i3c-master.txt deleted file mode 100644 index 3716589d6999..000000000000 --- a/Documentation/devicetree/bindings/i3c/cdns,i3c-master.txt +++ /dev/null @@ -1,43 +0,0 @@ -Bindings for cadence I3C master block -===================================== - -Required properties: --------------------- -- compatible: shall be "cdns,i3c-master" -- clocks: shall reference the pclk and sysclk -- clock-names: shall contain "pclk" and "sysclk" -- interrupts: the interrupt line connected to this I3C master -- reg: I3C master registers - -Mandatory properties defined by the generic binding (see -Documentation/devicetree/bindings/i3c/i3c.yaml for more details): - -- #address-cells: shall be set to 1 -- #size-cells: shall be set to 0 - -Optional properties defined by the generic binding (see -Documentation/devicetree/bindings/i3c/i3c.yaml for more details): - -- i2c-scl-hz -- i3c-scl-hz - -I3C device connected on the bus follow the generic description (see -Documentation/devicetree/bindings/i3c/i3c.yaml for more details). - -Example: - - i3c-master@0d040000 { - compatible = "cdns,i3c-master"; - clocks = <&coreclock>, <&i3csysclock>; - clock-names = "pclk", "sysclk"; - interrupts = <3 0>; - reg = <0x0d040000 0x1000>; - #address-cells = <1>; - #size-cells = <0>; - i2c-scl-hz = <100000>; - - nunchuk: nunchuk@52 { - compatible = "nintendo,nunchuk"; - reg = <0x52 0x0 0x10>; - }; - }; diff --git a/Documentation/devicetree/bindings/i3c/cdns,i3c-master.yaml b/Documentation/devicetree/bindings/i3c/cdns,i3c-master.yaml new file mode 100644 index 000000000000..cc40d25358ec --- /dev/null +++ b/Documentation/devicetree/bindings/i3c/cdns,i3c-master.yaml @@ -0,0 +1,60 @@ +# SPDX-License-Identifier: GPL-2.0 +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/i3c/cdns,i3c-master.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Cadence I3C master block + +maintainers: + - Boris Brezillon <bbrezillon@kernel.org> + +allOf: + - $ref: i3c.yaml# + +properties: + compatible: + const: cdns,i3c-master + + reg: + maxItems: 1 + + clocks: + maxItems: 2 + + clock-names: + items: + - const: pclk + - const: sysclk + + interrupts: + maxItems: 1 + +required: + - compatible + - reg + - clocks + - clock-names + - interrupts + +unevaluatedProperties: false + +examples: + - | + i3c-master@d040000 { + compatible = "cdns,i3c-master"; + clocks = <&coreclock>, <&i3csysclock>; + clock-names = "pclk", "sysclk"; + interrupts = <3 0>; + reg = <0x0d040000 0x1000>; + #address-cells = <3>; + #size-cells = <0>; + i2c-scl-hz = <100000>; + + eeprom@57{ + compatible = "atmel,24c01"; + reg = <0x57 0x0 0x10>; + pagesize = <0x8>; + }; + }; +... diff --git a/Documentation/devicetree/bindings/i3c/snps,dw-i3c-master.txt b/Documentation/devicetree/bindings/i3c/snps,dw-i3c-master.txt deleted file mode 100644 index 07f35f36085d..000000000000 --- a/Documentation/devicetree/bindings/i3c/snps,dw-i3c-master.txt +++ /dev/null @@ -1,41 +0,0 @@ -Bindings for Synopsys DesignWare I3C master block -================================================= - -Required properties: --------------------- -- compatible: shall be "snps,dw-i3c-master-1.00a" -- clocks: shall reference the core_clk -- interrupts: the interrupt line connected to this I3C master -- reg: Offset and length of I3C master registers - -Mandatory properties defined by the generic binding (see -Documentation/devicetree/bindings/i3c/i3c.yaml for more details): - -- #address-cells: shall be set to 3 -- #size-cells: shall be set to 0 - -Optional properties defined by the generic binding (see -Documentation/devicetree/bindings/i3c/i3c.yaml for more details): - -- i2c-scl-hz -- i3c-scl-hz - -I3C device connected on the bus follow the generic description (see -Documentation/devicetree/bindings/i3c/i3c.yaml for more details). - -Example: - - i3c-master@2000 { - compatible = "snps,dw-i3c-master-1.00a"; - #address-cells = <3>; - #size-cells = <0>; - reg = <0x02000 0x1000>; - interrupts = <0>; - clocks = <&i3cclk>; - - eeprom@57{ - compatible = "atmel,24c01"; - reg = <0x57 0x0 0x10>; - pagesize = <0x8>; - }; - }; diff --git a/Documentation/devicetree/bindings/i3c/snps,dw-i3c-master.yaml b/Documentation/devicetree/bindings/i3c/snps,dw-i3c-master.yaml new file mode 100644 index 000000000000..7a76fd32962a --- /dev/null +++ b/Documentation/devicetree/bindings/i3c/snps,dw-i3c-master.yaml @@ -0,0 +1,52 @@ +# SPDX-License-Identifier: GPL-2.0 +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/i3c/snps,dw-i3c-master.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Synopsys DesignWare I3C master block + +maintainers: + - Alexandre Belloni <alexandre.belloni@bootlin.com> + +allOf: + - $ref: i3c.yaml# + +properties: + compatible: + const: snps,dw-i3c-master-1.00a + + reg: + maxItems: 1 + + clocks: + maxItems: 1 + + interrupts: + maxItems: 1 + +required: + - compatible + - reg + - clocks + - interrupts + +unevaluatedProperties: false + +examples: + - | + i3c-master@2000 { + compatible = "snps,dw-i3c-master-1.00a"; + #address-cells = <3>; + #size-cells = <0>; + reg = <0x02000 0x1000>; + interrupts = <0>; + clocks = <&i3cclk>; + + eeprom@57{ + compatible = "atmel,24c01"; + reg = <0x57 0x0 0x10>; + pagesize = <0x8>; + }; + }; +... diff --git a/Documentation/devicetree/bindings/input/allwinner,sun4i-a10-lradc-keys.yaml b/Documentation/devicetree/bindings/input/allwinner,sun4i-a10-lradc-keys.yaml index d74f2002409e..3399fc288afb 100644 --- a/Documentation/devicetree/bindings/input/allwinner,sun4i-a10-lradc-keys.yaml +++ b/Documentation/devicetree/bindings/input/allwinner,sun4i-a10-lradc-keys.yaml @@ -18,10 +18,20 @@ properties: - items: - const: allwinner,sun50i-a64-lradc - const: allwinner,sun8i-a83t-r-lradc + - const: allwinner,sun50i-r329-lradc + - items: + - const: allwinner,sun20i-d1-lradc + - const: allwinner,sun50i-r329-lradc reg: maxItems: 1 + clocks: + maxItems: 1 + + resets: + maxItems: 1 + interrupts: maxItems: 1 @@ -68,6 +78,18 @@ required: - interrupts - vref-supply +if: + properties: + compatible: + contains: + enum: + - allwinner,sun50i-r329-lradc + +then: + required: + - clocks + - resets + additionalProperties: false examples: diff --git a/Documentation/devicetree/bindings/input/azoteq,iqs7222.yaml b/Documentation/devicetree/bindings/input/azoteq,iqs7222.yaml new file mode 100644 index 000000000000..a3a1e5a65306 --- /dev/null +++ b/Documentation/devicetree/bindings/input/azoteq,iqs7222.yaml @@ -0,0 +1,960 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/input/azoteq,iqs7222.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Azoteq IQS7222A/B/C Capacitive Touch Controller + +maintainers: + - Jeff LaBundy <jeff@labundy.com> + +description: | + The Azoteq IQS7222A, IQS7222B and IQS7222C are multichannel capacitive touch + controllers that feature additional sensing capabilities. + + Link to datasheets: https://www.azoteq.com/ + +properties: + compatible: + enum: + - azoteq,iqs7222a + - azoteq,iqs7222b + - azoteq,iqs7222c + + reg: + maxItems: 1 + + irq-gpios: + maxItems: 1 + description: + Specifies the GPIO connected to the device's active-low RDY output. + + reset-gpios: + maxItems: 1 + description: + Specifies the GPIO connected to the device's active-low MCLR input. The + device is temporarily held in hardware reset prior to initialization if + this property is present. + + azoteq,rf-filt-enable: + type: boolean + description: Enables the device's internal RF filter. + + azoteq,max-counts: + $ref: /schemas/types.yaml#/definitions/uint32 + enum: [0, 1, 2, 3] + description: | + Specifies the maximum number of conversion periods (counts) that can be + reported as follows: + 0: 1023 + 1: 2047 + 2: 4095 + 3: 16384 + + azoteq,auto-mode: + $ref: /schemas/types.yaml#/definitions/uint32 + enum: [0, 1, 2, 3] + description: | + Specifies the number of conversions to occur before an interrupt is + generated as follows: + 0: 4 + 1: 8 + 2: 16 + 3: 32 + + azoteq,ati-frac-div-fine: + $ref: /schemas/types.yaml#/definitions/uint32 + minimum: 0 + maximum: 31 + description: Specifies the preloaded ATI fine fractional divider. + + azoteq,ati-frac-div-coarse: + $ref: /schemas/types.yaml#/definitions/uint32 + minimum: 0 + maximum: 31 + description: Specifies the preloaded ATI coarse fractional divider. + + azoteq,ati-comp-select: + $ref: /schemas/types.yaml#/definitions/uint32 + minimum: 0 + maximum: 1023 + description: Specifies the preloaded ATI compensation selection. + + azoteq,lta-beta-lp: + $ref: /schemas/types.yaml#/definitions/uint32 + minimum: 0 + maximum: 15 + description: + Specifies the long-term average filter damping factor to be applied during + low-power mode. + + azoteq,lta-beta-np: + $ref: /schemas/types.yaml#/definitions/uint32 + minimum: 0 + maximum: 15 + description: + Specifies the long-term average filter damping factor to be applied during + normal-power mode. + + azoteq,counts-beta-lp: + $ref: /schemas/types.yaml#/definitions/uint32 + minimum: 0 + maximum: 15 + description: + Specifies the counts filter damping factor to be applied during low-power + mode. + + azoteq,counts-beta-np: + $ref: /schemas/types.yaml#/definitions/uint32 + minimum: 0 + maximum: 15 + description: + Specifies the counts filter damping factor to be applied during normal- + power mode. + + azoteq,lta-fast-beta-lp: + $ref: /schemas/types.yaml#/definitions/uint32 + minimum: 0 + maximum: 15 + description: + Specifies the long-term average filter fast damping factor to be applied + during low-power mode. + + azoteq,lta-fast-beta-np: + $ref: /schemas/types.yaml#/definitions/uint32 + minimum: 0 + maximum: 15 + description: + Specifies the long-term average filter fast damping factor to be applied + during normal-power mode. + + azoteq,timeout-ati-ms: + multipleOf: 500 + minimum: 0 + maximum: 32767500 + description: + Specifies the delay (in ms) before ATI is retried following an ATI error. + + azoteq,rate-ati-ms: + minimum: 0 + maximum: 65535 + description: Specifies the rate (in ms) at which ATI status is evaluated. + + azoteq,timeout-np-ms: + minimum: 0 + maximum: 65535 + description: + Specifies the length of time (in ms) to wait for an event before moving + from normal-power mode to low-power mode. + + azoteq,rate-np-ms: + minimum: 0 + maximum: 3000 + description: Specifies the report rate (in ms) during normal-power mode. + + azoteq,timeout-lp-ms: + minimum: 0 + maximum: 65535 + description: + Specifies the length of time (in ms) to wait for an event before moving + from low-power mode to ultra-low-power mode. + + azoteq,rate-lp-ms: + minimum: 0 + maximum: 3000 + description: Specifies the report rate (in ms) during low-power mode. + + azoteq,timeout-ulp-ms: + minimum: 0 + maximum: 65535 + description: + Specifies the rate (in ms) at which channels not regularly sampled during + ultra-low-power mode are updated. + + azoteq,rate-ulp-ms: + minimum: 0 + maximum: 3000 + description: Specifies the report rate (in ms) during ultra-low-power mode. + +patternProperties: + "^cycle-[0-9]$": + type: object + description: Represents a conversion cycle serving two sensing channels. + + properties: + azoteq,conv-period: + $ref: /schemas/types.yaml#/definitions/uint32 + minimum: 0 + maximum: 255 + description: Specifies the cycle's conversion period. + + azoteq,conv-frac: + $ref: /schemas/types.yaml#/definitions/uint32 + minimum: 0 + maximum: 255 + description: Specifies the cycle's conversion frequency fraction. + + azoteq,tx-enable: + $ref: /schemas/types.yaml#/definitions/uint32-array + minItems: 1 + maxItems: 9 + items: + minimum: 0 + maximum: 8 + description: Specifies the CTx pin(s) associated with the cycle. + + azoteq,rx-float-inactive: + type: boolean + description: Floats any inactive CRx pins instead of grounding them. + + azoteq,dead-time-enable: + type: boolean + description: + Increases the denominator of the conversion frequency formula by one. + + azoteq,tx-freq-fosc: + type: boolean + description: + Fixes the conversion frequency to that of the device's core clock. + + azoteq,vbias-enable: + type: boolean + description: Enables the bias voltage for use during inductive sensing. + + azoteq,sense-mode: + $ref: /schemas/types.yaml#/definitions/uint32 + enum: [0, 1, 2, 3] + description: | + Specifies the cycle's sensing mode as follows: + 0: None + 1: Self capacitive + 2: Mutual capacitive + 3: Inductive + + Note that in the case of IQS7222A, cycles 5 and 6 are restricted to + Hall-effect sensing. + + azoteq,iref-enable: + type: boolean + description: + Enables the current reference for use during various sensing modes. + + azoteq,iref-level: + $ref: /schemas/types.yaml#/definitions/uint32 + minimum: 0 + maximum: 15 + description: Specifies the cycle's current reference level. + + azoteq,iref-trim: + $ref: /schemas/types.yaml#/definitions/uint32 + minimum: 0 + maximum: 15 + description: Specifies the cycle's current reference trim. + + dependencies: + azoteq,iref-level: ["azoteq,iref-enable"] + azoteq,iref-trim: ["azoteq,iref-enable"] + + additionalProperties: false + + "^channel-([0-9]|1[0-9])$": + type: object + description: + Represents a single sensing channel. A channel is active if defined and + inactive otherwise. + + Note that in the case of IQS7222A, channels 10 and 11 are restricted to + Hall-effect sensing with events reported on channel 10 only. + + properties: + azoteq,ulp-allow: + type: boolean + description: + Permits the device to enter ultra-low-power mode while the channel + lies in a state of touch or proximity. + + azoteq,ref-select: + $ref: /schemas/types.yaml#/definitions/uint32 + minimum: 0 + maximum: 9 + description: Specifies a separate reference channel to be followed. + + azoteq,ref-weight: + $ref: /schemas/types.yaml#/definitions/uint32 + minimum: 0 + maximum: 65535 + description: Specifies the relative weight of the reference channel. + + azoteq,use-prox: + type: boolean + description: + Activates the reference channel in response to proximity events + instead of touch events. + + azoteq,ati-band: + $ref: /schemas/types.yaml#/definitions/uint32 + enum: [0, 1, 2, 3] + description: | + Specifies the channel's ATI band as a fraction of its ATI target as + follows: + 0: 1/16 + 1: 1/8 + 2: 1/4 + 3: 1/2 + + azoteq,global-halt: + type: boolean + description: + Specifies that the channel's long-term average is to freeze if any + other participating channel lies in a proximity or touch state. + + azoteq,invert-enable: + type: boolean + description: + Inverts the polarity of the states reported for proximity and touch + events relative to their respective thresholds. + + azoteq,dual-direction: + type: boolean + description: + Specifies that the channel's long-term average is to freeze in the + presence of either increasing or decreasing counts, thereby permit- + ting events to be reported in either direction. + + azoteq,rx-enable: + $ref: /schemas/types.yaml#/definitions/uint32-array + minItems: 1 + maxItems: 4 + items: + minimum: 0 + maximum: 7 + description: Specifies the CRx pin(s) associated with the channel. + + azoteq,samp-cap-double: + type: boolean + description: Doubles the sampling capacitance from 40 pF to 80 pF. + + azoteq,vref-half: + type: boolean + description: Halves the discharge threshold from 1.0 V to 0.5 V. + + azoteq,proj-bias: + $ref: /schemas/types.yaml#/definitions/uint32 + enum: [0, 1, 2, 3] + description: | + Specifies the bias current applied during mutual (projected) + capacitive sensing as follows: + 0: 2 uA + 1: 5 uA + 2: 7 uA + 3: 10 uA + + azoteq,ati-target: + $ref: /schemas/types.yaml#/definitions/uint32 + multipleOf: 8 + minimum: 0 + maximum: 2040 + description: Specifies the channel's ATI target. + + azoteq,ati-base: + $ref: /schemas/types.yaml#/definitions/uint32 + multipleOf: 16 + minimum: 0 + maximum: 496 + description: Specifies the channel's ATI base. + + azoteq,ati-mode: + $ref: /schemas/types.yaml#/definitions/uint32 + enum: [0, 1, 2, 3, 4, 5] + description: | + Specifies the channel's ATI mode as follows: + 0: Disabled + 1: Compensation + 2: Compensation divider + 3: Fine fractional divider + 4: Coarse fractional divider + 5: Full + + azoteq,ati-frac-div-fine: + $ref: /schemas/types.yaml#/definitions/uint32 + minimum: 0 + maximum: 31 + description: Specifies the channel's ATI fine fractional divider. + + azoteq,ati-frac-mult-coarse: + $ref: /schemas/types.yaml#/definitions/uint32 + minimum: 0 + maximum: 15 + description: Specifies the channel's ATI coarse fractional multiplier. + + azoteq,ati-frac-div-coarse: + $ref: /schemas/types.yaml#/definitions/uint32 + minimum: 0 + maximum: 31 + description: Specifies the channel's ATI coarse fractional divider. + + azoteq,ati-comp-div: + $ref: /schemas/types.yaml#/definitions/uint32 + minimum: 0 + maximum: 31 + description: Specifies the channel's ATI compensation divider. + + azoteq,ati-comp-select: + $ref: /schemas/types.yaml#/definitions/uint32 + minimum: 0 + maximum: 1023 + description: Specifies the channel's ATI compensation selection. + + azoteq,debounce-enter: + $ref: /schemas/types.yaml#/definitions/uint32 + minimum: 0 + maximum: 15 + description: Specifies the channel's debounce entrance factor. + + azoteq,debounce-exit: + $ref: /schemas/types.yaml#/definitions/uint32 + minimum: 0 + maximum: 15 + description: Specifies the channel's debounce exit factor. + + patternProperties: + "^event-(prox|touch)$": + type: object + description: + Represents a proximity or touch event reported by the channel. + + properties: + azoteq,gpio-select: + $ref: /schemas/types.yaml#/definitions/uint32-array + minItems: 1 + maxItems: 3 + items: + minimum: 0 + maximum: 2 + description: | + Specifies one or more GPIO mapped to the event as follows: + 0: GPIO0 + 1: GPIO3 (IQS7222C only) + 2: GPIO4 (IQS7222C only) + + Note that although multiple events can be mapped to a single + GPIO, they must all be of the same type (proximity, touch or + slider gesture). + + azoteq,thresh: + $ref: /schemas/types.yaml#/definitions/uint32 + description: + Specifies the threshold for the event. Valid entries range from + 0-127 and 0-255 for proximity and touch events, respectively. + + azoteq,hyst: + $ref: /schemas/types.yaml#/definitions/uint32 + minimum: 0 + maximum: 255 + description: + Specifies the hysteresis for the event (touch events only). + + azoteq,timeout-press-ms: + multipleOf: 500 + minimum: 0 + maximum: 127500 + description: + Specifies the length of time (in ms) to wait before automatically + releasing a press event. Specify zero to allow the press state to + persist indefinitely. + + The IQS7222B does not feature channel-specific timeouts; the time- + out specified for any one channel applies to all channels. + + linux,code: + $ref: /schemas/types.yaml#/definitions/uint32 + description: + Numeric key or switch code associated with the event. Specify + KEY_RESERVED (0) to opt out of event reporting. + + linux,input-type: + $ref: /schemas/types.yaml#/definitions/uint32 + enum: [1, 5] + default: 1 + description: + Specifies whether the event is to be interpreted as a key (1) + or a switch (5). + + required: + - linux,code + + additionalProperties: false + + dependencies: + azoteq,ref-weight: ["azoteq,ref-select"] + azoteq,use-prox: ["azoteq,ref-select"] + + additionalProperties: false + + "^slider-[0-1]$": + type: object + description: Represents a slider comprising three or four channels. + + properties: + azoteq,channel-select: + $ref: /schemas/types.yaml#/definitions/uint32-array + minItems: 3 + maxItems: 4 + items: + minimum: 0 + maximum: 9 + description: + Specifies the order of the channels that participate in the slider. + + azoteq,slider-size: + $ref: /schemas/types.yaml#/definitions/uint32 + minimum: 0 + maximum: 65535 + description: + Specifies the slider's one-dimensional resolution, equal to the + maximum coordinate plus one. + + azoteq,lower-cal: + $ref: /schemas/types.yaml#/definitions/uint32 + minimum: 0 + maximum: 255 + description: Specifies the slider's lower starting point. + + azoteq,upper-cal: + $ref: /schemas/types.yaml#/definitions/uint32 + minimum: 0 + maximum: 255 + description: Specifies the slider's upper starting point. + + azoteq,top-speed: + $ref: /schemas/types.yaml#/definitions/uint32 + minimum: 0 + maximum: 65535 + description: + Specifies the speed of movement after which coordinate filtering is + no longer applied. + + azoteq,bottom-speed: + $ref: /schemas/types.yaml#/definitions/uint32 + multipleOf: 4 + minimum: 0 + maximum: 1020 + description: + Specifies the speed of movement after which coordinate filtering is + linearly reduced. + + azoteq,bottom-beta: + $ref: /schemas/types.yaml#/definitions/uint32 + minimum: 0 + maximum: 7 + description: + Specifies the coordinate filter damping factor to be applied + while the speed of movement is below that which is specified + by azoteq,bottom-speed. + + azoteq,static-beta: + type: boolean + description: + Applies the coordinate filter damping factor specified by + azoteq,bottom-beta regardless of the speed of movement. + + azoteq,use-prox: + type: boolean + description: + Directs the slider to respond to the proximity states of the selected + channels instead of their corresponding touch states. Note the slider + cannot report granular coordinates during a state of proximity. + + linux,axis: + $ref: /schemas/types.yaml#/definitions/uint32 + description: + Specifies the absolute axis to which coordinates are mapped. Specify + ABS_WHEEL to operate the slider as a wheel (IQS7222C only). + + patternProperties: + "^event-(press|tap|(swipe|flick)-(pos|neg))$": + type: object + description: + Represents a press or gesture (IQS7222A only) event reported by + the slider. + + properties: + linux,code: + $ref: /schemas/types.yaml#/definitions/uint32 + description: Numeric key code associated with the event. + + azoteq,gesture-max-ms: + multipleOf: 4 + minimum: 0 + maximum: 1020 + description: + Specifies the length of time (in ms) within which a tap, swipe + or flick gesture must be completed in order to be acknowledged + by the device. The number specified for any one swipe or flick + gesture applies to all remaining swipe or flick gestures. + + azoteq,gesture-min-ms: + multipleOf: 4 + minimum: 0 + maximum: 124 + description: + Specifies the length of time (in ms) for which a tap gesture must + be held in order to be acknowledged by the device. + + azoteq,gesture-dist: + $ref: /schemas/types.yaml#/definitions/uint32 + multipleOf: 16 + minimum: 0 + maximum: 4080 + description: + Specifies the distance across which a swipe or flick gesture must + travel in order to be acknowledged by the device. The number spec- + ified for any one swipe or flick gesture applies to all remaining + swipe or flick gestures. + + azoteq,gpio-select: + $ref: /schemas/types.yaml#/definitions/uint32-array + minItems: 1 + maxItems: 1 + items: + minimum: 0 + maximum: 0 + description: | + Specifies an individual GPIO mapped to a tap, swipe or flick + gesture as follows: + 0: GPIO0 + 1: GPIO3 (reserved) + 2: GPIO4 (reserved) + + Note that although multiple events can be mapped to a single + GPIO, they must all be of the same type (proximity, touch or + slider gesture). + + required: + - linux,code + + additionalProperties: false + + required: + - azoteq,channel-select + + additionalProperties: false + + "^gpio-[0-2]$": + type: object + description: | + Represents a GPIO mapped to one or more events as follows: + gpio-0: GPIO0 + gpio-1: GPIO3 (IQS7222C only) + gpio-2: GPIO4 (IQS7222C only) + + allOf: + - $ref: ../pinctrl/pincfg-node.yaml# + + properties: + drive-open-drain: true + + additionalProperties: false + +allOf: + - if: + properties: + compatible: + contains: + const: azoteq,iqs7222b + + then: + patternProperties: + "^cycle-[0-9]$": + properties: + azoteq,iref-enable: false + + "^channel-([0-9]|1[0-9])$": + properties: + azoteq,ref-select: false + + patternProperties: + "^event-(prox|touch)$": + properties: + azoteq,gpio-select: false + + "^slider-[0-1]$": false + + "^gpio-[0-2]$": false + + - if: + properties: + compatible: + contains: + const: azoteq,iqs7222a + + then: + patternProperties: + "^channel-([0-9]|1[0-9])$": + patternProperties: + "^event-(prox|touch)$": + properties: + azoteq,gpio-select: + maxItems: 1 + items: + maximum: 0 + + "^slider-[0-1]$": + properties: + azoteq,slider-size: + multipleOf: 16 + maximum: 4080 + + azoteq,top-speed: + multipleOf: 4 + maximum: 1020 + + else: + patternProperties: + "^channel-([0-9]|1[0-9])$": + properties: + azoteq,ulp-allow: false + + "^slider-[0-1]$": + patternProperties: + "^event-(press|tap|(swipe|flick)-(pos|neg))$": + properties: + azoteq,gesture-max-ms: false + + azoteq,gesture-min-ms: false + + azoteq,gesture-dist: false + + azoteq,gpio-select: false + +required: + - compatible + - reg + - irq-gpios + +additionalProperties: false + +examples: + - | + #include <dt-bindings/gpio/gpio.h> + #include <dt-bindings/input/input.h> + + i2c { + #address-cells = <1>; + #size-cells = <0>; + + iqs7222a@44 { + compatible = "azoteq,iqs7222a"; + reg = <0x44>; + irq-gpios = <&gpio 4 GPIO_ACTIVE_LOW>; + azoteq,lta-beta-lp = <7>; + azoteq,lta-beta-np = <8>; + azoteq,counts-beta-lp = <2>; + azoteq,counts-beta-np = <3>; + azoteq,lta-fast-beta-lp = <3>; + azoteq,lta-fast-beta-np = <4>; + + cycle-0 { + azoteq,conv-period = <5>; + azoteq,conv-frac = <127>; + azoteq,tx-enable = <1>, <2>, <4>, <5>; + azoteq,dead-time-enable; + azoteq,sense-mode = <2>; + }; + + cycle-1 { + azoteq,conv-period = <5>; + azoteq,conv-frac = <127>; + azoteq,tx-enable = <5>; + azoteq,dead-time-enable; + azoteq,sense-mode = <2>; + }; + + cycle-2 { + azoteq,conv-period = <5>; + azoteq,conv-frac = <127>; + azoteq,tx-enable = <4>; + azoteq,dead-time-enable; + azoteq,sense-mode = <2>; + }; + + cycle-3 { + azoteq,conv-period = <5>; + azoteq,conv-frac = <127>; + azoteq,tx-enable = <2>; + azoteq,dead-time-enable; + azoteq,sense-mode = <2>; + }; + + cycle-4 { + azoteq,conv-period = <5>; + azoteq,conv-frac = <127>; + azoteq,tx-enable = <1>; + azoteq,dead-time-enable; + azoteq,sense-mode = <2>; + }; + + cycle-5 { + azoteq,conv-period = <2>; + azoteq,conv-frac = <0>; + }; + + cycle-6 { + azoteq,conv-period = <2>; + azoteq,conv-frac = <0>; + }; + + channel-0 { + azoteq,ulp-allow; + azoteq,global-halt; + azoteq,invert-enable; + azoteq,rx-enable = <3>; + azoteq,ati-target = <800>; + azoteq,ati-base = <208>; + azoteq,ati-mode = <5>; + }; + + channel-1 { + azoteq,global-halt; + azoteq,invert-enable; + azoteq,rx-enable = <3>; + azoteq,ati-target = <496>; + azoteq,ati-base = <208>; + azoteq,ati-mode = <5>; + }; + + channel-2 { + azoteq,global-halt; + azoteq,invert-enable; + azoteq,rx-enable = <3>; + azoteq,ati-target = <496>; + azoteq,ati-base = <208>; + azoteq,ati-mode = <5>; + }; + + channel-3 { + azoteq,global-halt; + azoteq,invert-enable; + azoteq,rx-enable = <3>; + azoteq,ati-target = <496>; + azoteq,ati-base = <208>; + azoteq,ati-mode = <5>; + }; + + channel-4 { + azoteq,global-halt; + azoteq,invert-enable; + azoteq,rx-enable = <3>; + azoteq,ati-target = <496>; + azoteq,ati-base = <208>; + azoteq,ati-mode = <5>; + }; + + channel-5 { + azoteq,ulp-allow; + azoteq,global-halt; + azoteq,invert-enable; + azoteq,rx-enable = <6>; + azoteq,ati-target = <800>; + azoteq,ati-base = <144>; + azoteq,ati-mode = <5>; + }; + + channel-6 { + azoteq,global-halt; + azoteq,invert-enable; + azoteq,rx-enable = <6>; + azoteq,ati-target = <496>; + azoteq,ati-base = <160>; + azoteq,ati-mode = <5>; + + event-touch { + linux,code = <KEY_MUTE>; + }; + }; + + channel-7 { + azoteq,global-halt; + azoteq,invert-enable; + azoteq,rx-enable = <6>; + azoteq,ati-target = <496>; + azoteq,ati-base = <160>; + azoteq,ati-mode = <5>; + + event-touch { + linux,code = <KEY_VOLUMEDOWN>; + }; + }; + + channel-8 { + azoteq,global-halt; + azoteq,invert-enable; + azoteq,rx-enable = <6>; + azoteq,ati-target = <496>; + azoteq,ati-base = <160>; + azoteq,ati-mode = <5>; + + event-touch { + linux,code = <KEY_VOLUMEUP>; + }; + }; + + channel-9 { + azoteq,global-halt; + azoteq,invert-enable; + azoteq,rx-enable = <6>; + azoteq,ati-target = <496>; + azoteq,ati-base = <160>; + azoteq,ati-mode = <5>; + + event-touch { + linux,code = <KEY_POWER>; + }; + }; + + channel-10 { + azoteq,ulp-allow; + azoteq,ati-target = <496>; + azoteq,ati-base = <112>; + + event-touch { + linux,code = <SW_LID>; + linux,input-type = <EV_SW>; + }; + }; + + channel-11 { + azoteq,ati-target = <496>; + azoteq,ati-base = <112>; + }; + + slider-0 { + azoteq,channel-select = <1>, <2>, <3>, <4>; + azoteq,slider-size = <4080>; + azoteq,upper-cal = <50>; + azoteq,lower-cal = <30>; + azoteq,top-speed = <200>; + azoteq,bottom-speed = <1>; + azoteq,bottom-beta = <3>; + + event-tap { + linux,code = <KEY_PLAYPAUSE>; + azoteq,gesture-max-ms = <600>; + azoteq,gesture-min-ms = <24>; + }; + + event-flick-pos { + linux,code = <KEY_NEXTSONG>; + azoteq,gesture-max-ms = <600>; + azoteq,gesture-dist = <816>; + }; + + event-flick-neg { + linux,code = <KEY_PREVIOUSSONG>; + }; + }; + }; + }; + +... diff --git a/Documentation/devicetree/bindings/input/google,cros-ec-keyb.yaml b/Documentation/devicetree/bindings/input/google,cros-ec-keyb.yaml index aa61fe64be63..e05690b3e963 100644 --- a/Documentation/devicetree/bindings/input/google,cros-ec-keyb.yaml +++ b/Documentation/devicetree/bindings/input/google,cros-ec-keyb.yaml @@ -15,14 +15,16 @@ description: | Google's ChromeOS EC Keyboard is a simple matrix keyboard implemented on a separate EC (Embedded Controller) device. It provides a message for reading key scans from the EC. These are then converted - into keycodes for processing by the kernel. - -allOf: - - $ref: "/schemas/input/matrix-keymap.yaml#" + into keycodes for processing by the kernel. This device also supports + switches/buttons like power and volume buttons. properties: compatible: - const: google,cros-ec-keyb + oneOf: + - description: ChromeOS EC with only buttons/switches + const: google,cros-ec-keyb-switches + - description: ChromeOS EC with keyboard and possibly buttons/switches + const: google,cros-ec-keyb google,needs-ghost-filter: description: @@ -42,15 +44,31 @@ properties: where the lower 16 bits are reserved. This property is specified only when the keyboard has a custom design for the top row keys. +dependencies: + function-row-phsymap: [ 'linux,keymap' ] + google,needs-ghost-filter: [ 'linux,keymap' ] + required: - compatible +if: + properties: + compatible: + contains: + const: google,cros-ec-keyb +then: + $ref: "/schemas/input/matrix-keymap.yaml#" + required: + - keypad,num-rows + - keypad,num-columns + - linux,keymap + unevaluatedProperties: false examples: - | #include <dt-bindings/input/input.h> - cros-ec-keyb { + keyboard-controller { compatible = "google,cros-ec-keyb"; keypad,num-rows = <8>; keypad,num-columns = <13>; @@ -114,3 +132,9 @@ examples: /* UP LEFT */ 0x070b0067 0x070c0069>; }; + - | + /* No matrix keyboard, just buttons/switches */ + keyboard-controller { + compatible = "google,cros-ec-keyb-switches"; + }; +... diff --git a/Documentation/devicetree/bindings/interrupt-controller/qcom,pdc.txt b/Documentation/devicetree/bindings/interrupt-controller/qcom,pdc.txt index 3b7b1134dea9..159a423e5586 100644 --- a/Documentation/devicetree/bindings/interrupt-controller/qcom,pdc.txt +++ b/Documentation/devicetree/bindings/interrupt-controller/qcom,pdc.txt @@ -22,6 +22,7 @@ Properties: - "qcom,sc7280-pdc": For SC7280 - "qcom,sdm845-pdc": For SDM845 - "qcom,sm6350-pdc": For SM6350 + - "qcom,sm8150-pdc": For SM8150 - "qcom,sm8250-pdc": For SM8250 - "qcom,sm8350-pdc": For SM8350 diff --git a/Documentation/devicetree/bindings/iommu/arm,smmu.yaml b/Documentation/devicetree/bindings/iommu/arm,smmu.yaml index da5381c8ee11..76fc2c0f4d54 100644 --- a/Documentation/devicetree/bindings/iommu/arm,smmu.yaml +++ b/Documentation/devicetree/bindings/iommu/arm,smmu.yaml @@ -37,8 +37,10 @@ properties: - qcom,sc7180-smmu-500 - qcom,sc7280-smmu-500 - qcom,sc8180x-smmu-500 + - qcom,sc8280xp-smmu-500 - qcom,sdm845-smmu-500 - qcom,sdx55-smmu-500 + - qcom,sdx65-smmu-500 - qcom,sm6350-smmu-500 - qcom,sm8150-smmu-500 - qcom,sm8250-smmu-500 @@ -62,8 +64,9 @@ properties: for improved performance. items: - enum: - - nvidia,tegra194-smmu - nvidia,tegra186-smmu + - nvidia,tegra194-smmu + - nvidia,tegra234-smmu - const: nvidia,smmu-500 - items: - const: arm,mmu-500 @@ -157,6 +160,17 @@ properties: power-domains: maxItems: 1 + nvidia,memory-controller: + description: | + A phandle to the memory controller on NVIDIA Tegra186 and later SoCs. + The memory controller needs to be programmed with a mapping of memory + client IDs to ARM SMMU stream IDs. + + If this property is absent, the mapping programmed by early firmware + will be used and it is not guaranteed that IOMMU translations will be + enabled for any given device. + $ref: /schemas/types.yaml#/definitions/phandle + required: - compatible - reg @@ -172,13 +186,20 @@ allOf: compatible: contains: enum: - - nvidia,tegra194-smmu - nvidia,tegra186-smmu + - nvidia,tegra194-smmu + - nvidia,tegra234-smmu then: properties: reg: minItems: 1 maxItems: 2 + + # The reference to the memory controller is required to ensure that the + # memory client to stream ID mapping can be done synchronously with the + # IOMMU attachment. + required: + - nvidia,memory-controller else: properties: reg: diff --git a/Documentation/devicetree/bindings/iommu/mediatek,iommu.yaml b/Documentation/devicetree/bindings/iommu/mediatek,iommu.yaml index 97e8c471a5e8..2ae3bbad7f1a 100644 --- a/Documentation/devicetree/bindings/iommu/mediatek,iommu.yaml +++ b/Documentation/devicetree/bindings/iommu/mediatek,iommu.yaml @@ -76,7 +76,11 @@ properties: - mediatek,mt8167-m4u # generation two - mediatek,mt8173-m4u # generation two - mediatek,mt8183-m4u # generation two + - mediatek,mt8186-iommu-mm # generation two - mediatek,mt8192-m4u # generation two + - mediatek,mt8195-iommu-vdo # generation two + - mediatek,mt8195-iommu-vpp # generation two + - mediatek,mt8195-iommu-infra # generation two - description: mt7623 generation one items: @@ -119,7 +123,9 @@ properties: dt-binding/memory/mt8167-larb-port.h for mt8167, dt-binding/memory/mt8173-larb-port.h for mt8173, dt-binding/memory/mt8183-larb-port.h for mt8183, + dt-binding/memory/mt8186-memory-port.h for mt8186, dt-binding/memory/mt8192-larb-port.h for mt8192. + dt-binding/memory/mt8195-memory-port.h for mt8195. power-domains: maxItems: 1 @@ -128,7 +134,6 @@ required: - compatible - reg - interrupts - - mediatek,larbs - '#iommu-cells' allOf: @@ -140,7 +145,10 @@ allOf: - mediatek,mt2701-m4u - mediatek,mt2712-m4u - mediatek,mt8173-m4u + - mediatek,mt8186-iommu-mm - mediatek,mt8192-m4u + - mediatek,mt8195-iommu-vdo + - mediatek,mt8195-iommu-vpp then: required: @@ -150,12 +158,26 @@ allOf: properties: compatible: enum: + - mediatek,mt8186-iommu-mm - mediatek,mt8192-m4u + - mediatek,mt8195-iommu-vdo + - mediatek,mt8195-iommu-vpp then: required: - power-domains + - if: # The IOMMUs don't have larbs. + not: + properties: + compatible: + contains: + const: mediatek,mt8195-iommu-infra + + then: + required: + - mediatek,larbs + additionalProperties: false examples: @@ -173,13 +195,3 @@ examples: <&larb3>, <&larb4>, <&larb5>; #iommu-cells = <1>; }; - - - | - #include <dt-bindings/memory/mt8173-larb-port.h> - - /* Example for a client device */ - display { - compatible = "mediatek,mt8173-disp"; - iommus = <&iommu M4U_PORT_DISP_OVL0>, - <&iommu M4U_PORT_DISP_RDMA0>; - }; diff --git a/Documentation/devicetree/bindings/iommu/samsung,sysmmu.yaml b/Documentation/devicetree/bindings/iommu/samsung,sysmmu.yaml index 783c6b37c9f0..672a0beea600 100644 --- a/Documentation/devicetree/bindings/iommu/samsung,sysmmu.yaml +++ b/Documentation/devicetree/bindings/iommu/samsung,sysmmu.yaml @@ -86,16 +86,6 @@ examples: - | #include <dt-bindings/clock/exynos5250.h> - gsc_0: scaler@13e00000 { - compatible = "samsung,exynos5-gsc"; - reg = <0x13e00000 0x1000>; - interrupts = <0 85 0>; - power-domains = <&pd_gsc>; - clocks = <&clock CLK_GSCL0>; - clock-names = "gscl"; - iommus = <&sysmmu_gsc0>; - }; - sysmmu_gsc0: iommu@13e80000 { compatible = "samsung,exynos-sysmmu"; reg = <0x13E80000 0x1000>; diff --git a/Documentation/devicetree/bindings/leds/kinetic,ktd2692.yaml b/Documentation/devicetree/bindings/leds/kinetic,ktd2692.yaml new file mode 100644 index 000000000000..bac95a51afa1 --- /dev/null +++ b/Documentation/devicetree/bindings/leds/kinetic,ktd2692.yaml @@ -0,0 +1,87 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/leds/kinetic,ktd2692.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: KTD2692 Flash LED Driver from Kinetic Technologies + +maintainers: + - Markuss Broks <markuss.broks@gmail.com> + +description: | + KTD2692 is the ideal power solution for high-power flash LEDs. + It uses ExpressWire single-wire programming for maximum flexibility. + + The ExpressWire interface through CTRL pin can control LED on/off and + enable/disable the IC, Movie(max 1/3 of Flash current) / Flash mode current, + Flash timeout, LVP(low voltage protection). + + Also, When the AUX pin is pulled high while CTRL pin is high, + LED current will be ramped up to the flash-mode current level. + +properties: + compatible: + const: kinetic,ktd2692 + + ctrl-gpios: + maxItems: 1 + description: Specifier of the GPIO connected to CTRL pin. + + aux-gpios: + maxItems: 1 + description: Specifier of the GPIO connected to CTRL pin. + + vin-supply: + description: LED supply (2.7V to 5.5V). + + led: + type: object + $ref: common.yaml# + description: Properties for the LED. + properties: + function: true + color: true + flash-max-timeout-us: + description: Flash LED maximum timeout. + + led-max-microamp: + maximum: 300000 + description: Minimum Threshold for Timer protection + is defined internally (Maximum 300mA). + + flash-max-microamp: + maximum: 300000 + description: Flash LED maximum current + Formula - I(uA) = 15000000 / Rset. + + additionalProperties: false + +required: + - compatible + - ctrl-gpios + - led + +additionalProperties: false + +examples: + - | + #include <dt-bindings/gpio/gpio.h> + #include <dt-bindings/leds/common.h> + + ktd2692 { + compatible = "kinetic,ktd2692"; + ctrl-gpios = <&gpc0 1 0>; + aux-gpios = <&gpc0 2 0>; + vin-supply = <&vbat>; + + led { + function = LED_FUNCTION_FLASH; + color = <LED_COLOR_ID_WHITE>; + flash-max-timeout-us = <250000>; + flash-max-microamp = <150000>; + led-max-microamp = <25000>; + }; + }; + +... diff --git a/Documentation/devicetree/bindings/leds/leds-class-multicolor.yaml b/Documentation/devicetree/bindings/leds/leds-class-multicolor.yaml index 37445c68cdef..f41d021ed677 100644 --- a/Documentation/devicetree/bindings/leds/leds-class-multicolor.yaml +++ b/Documentation/devicetree/bindings/leds/leds-class-multicolor.yaml @@ -20,7 +20,7 @@ description: | within this documentation directory. patternProperties: - "^multi-led@([0-9a-f])$": + "^multi-led(@[0-9a-f])?$": type: object description: Represents the LEDs that are to be grouped. properties: diff --git a/Documentation/devicetree/bindings/leds/leds-ktd2692.txt b/Documentation/devicetree/bindings/leds/leds-ktd2692.txt deleted file mode 100644 index 853737452580..000000000000 --- a/Documentation/devicetree/bindings/leds/leds-ktd2692.txt +++ /dev/null @@ -1,50 +0,0 @@ -* Kinetic Technologies - KTD2692 Flash LED Driver - -KTD2692 is the ideal power solution for high-power flash LEDs. -It uses ExpressWire single-wire programming for maximum flexibility. - -The ExpressWire interface through CTRL pin can control LED on/off and -enable/disable the IC, Movie(max 1/3 of Flash current) / Flash mode current, -Flash timeout, LVP(low voltage protection). - -Also, When the AUX pin is pulled high while CTRL pin is high, -LED current will be ramped up to the flash-mode current level. - -Required properties: -- compatible : Should be "kinetic,ktd2692". -- ctrl-gpios : Specifier of the GPIO connected to CTRL pin. -- aux-gpios : Specifier of the GPIO connected to AUX pin. - -Optional properties: -- vin-supply : "vin" LED supply (2.7V to 5.5V). - See Documentation/devicetree/bindings/regulator/regulator.txt - -A discrete LED element connected to the device must be represented by a child -node - See Documentation/devicetree/bindings/leds/common.txt - -Required properties for flash LED child nodes: - See Documentation/devicetree/bindings/leds/common.txt -- led-max-microamp : Minimum Threshold for Timer protection - is defined internally (Maximum 300mA). -- flash-max-microamp : Flash LED maximum current - Formula : I(mA) = 15000 / Rset. -- flash-max-timeout-us : Flash LED maximum timeout. - -Optional properties for flash LED child nodes: -- label : See Documentation/devicetree/bindings/leds/common.txt - -Example: - -ktd2692 { - compatible = "kinetic,ktd2692"; - ctrl-gpios = <&gpc0 1 0>; - aux-gpios = <&gpc0 2 0>; - vin-supply = <&vbat>; - - flash-led { - label = "ktd2692-flash"; - led-max-microamp = <300000>; - flash-max-microamp = <1500000>; - flash-max-timeout-us = <1835000>; - }; -}; diff --git a/Documentation/devicetree/bindings/leds/leds-pwm-multicolor.yaml b/Documentation/devicetree/bindings/leds/leds-pwm-multicolor.yaml new file mode 100644 index 000000000000..6625a528f727 --- /dev/null +++ b/Documentation/devicetree/bindings/leds/leds-pwm-multicolor.yaml @@ -0,0 +1,79 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/leds/leds-pwm-multicolor.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Multi-color LEDs connected to PWM + +maintainers: + - Sven Schwermer <sven.schwermer@disruptive-technologies.com> + +description: | + This driver combines several monochrome PWM LEDs into one multi-color + LED using the multicolor LED class. + +properties: + compatible: + const: pwm-leds-multicolor + + multi-led: + type: object + + patternProperties: + "^led-[0-9a-z]+$": + type: object + $ref: common.yaml# + + additionalProperties: false + + properties: + pwms: + maxItems: 1 + + pwm-names: true + + color: true + + required: + - pwms + - color + +required: + - compatible + +allOf: + - $ref: leds-class-multicolor.yaml# + +additionalProperties: false + +examples: + - | + #include <dt-bindings/leds/common.h> + + led-controller { + compatible = "pwm-leds-multicolor"; + + multi-led { + color = <LED_COLOR_ID_RGB>; + function = LED_FUNCTION_INDICATOR; + max-brightness = <65535>; + + led-red { + pwms = <&pwm1 0 1000000>; + color = <LED_COLOR_ID_RED>; + }; + + led-green { + pwms = <&pwm2 0 1000000>; + color = <LED_COLOR_ID_GREEN>; + }; + + led-blue { + pwms = <&pwm3 0 1000000>; + color = <LED_COLOR_ID_BLUE>; + }; + }; + }; + +... diff --git a/Documentation/devicetree/bindings/leds/leds-qcom-lpg.yaml b/Documentation/devicetree/bindings/leds/leds-qcom-lpg.yaml new file mode 100644 index 000000000000..409a4c7298e1 --- /dev/null +++ b/Documentation/devicetree/bindings/leds/leds-qcom-lpg.yaml @@ -0,0 +1,174 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/leds/leds-qcom-lpg.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Qualcomm Light Pulse Generator + +maintainers: + - Bjorn Andersson <bjorn.andersson@linaro.org> + +description: > + The Qualcomm Light Pulse Generator consists of three different hardware blocks; + a ramp generator with lookup table, the light pulse generator and a three + channel current sink. These blocks are found in a wide range of Qualcomm PMICs. + +properties: + compatible: + enum: + - qcom,pm8150b-lpg + - qcom,pm8150l-lpg + - qcom,pm8350c-pwm + - qcom,pm8916-pwm + - qcom,pm8941-lpg + - qcom,pm8994-lpg + - qcom,pmc8180c-lpg + - qcom,pmi8994-lpg + - qcom,pmi8998-lpg + + "#pwm-cells": + const: 2 + + "#address-cells": + const: 1 + + "#size-cells": + const: 0 + + qcom,power-source: + $ref: /schemas/types.yaml#/definitions/uint32 + description: + power-source used to drive the output, as defined in the datasheet. + Should be specified if the TRILED block is present + enum: [0, 1, 3] + + qcom,dtest: + $ref: /schemas/types.yaml#/definitions/uint32-matrix + description: > + A list of integer pairs, where each pair represent the dtest line the + particular channel should be connected to and the flags denoting how the + value should be outputed, as defined in the datasheet. The number of + pairs should be the same as the number of channels. + items: + items: + - description: dtest line to attach + - description: flags for the attachment + + multi-led: + type: object + $ref: leds-class-multicolor.yaml# + properties: + "#address-cells": + const: 1 + + "#size-cells": + const: 0 + + patternProperties: + "^led@[0-9a-f]$": + type: object + $ref: common.yaml# + +patternProperties: + "^led@[0-9a-f]$": + type: object + $ref: common.yaml# + + properties: + reg: true + + required: + - reg + +required: + - compatible + +additionalProperties: false + +examples: + - | + #include <dt-bindings/leds/common.h> + + led-controller { + compatible = "qcom,pmi8994-lpg"; + + #address-cells = <1>; + #size-cells = <0>; + + qcom,power-source = <1>; + + qcom,dtest = <0 0>, + <0 0>, + <0 0>, + <4 1>; + + led@1 { + reg = <1>; + color = <LED_COLOR_ID_GREEN>; + function = LED_FUNCTION_INDICATOR; + function-enumerator = <1>; + }; + + led@2 { + reg = <2>; + color = <LED_COLOR_ID_GREEN>; + function = LED_FUNCTION_INDICATOR; + function-enumerator = <0>; + default-state = "on"; + }; + + led@3 { + reg = <3>; + color = <LED_COLOR_ID_GREEN>; + function = LED_FUNCTION_INDICATOR; + function-enumerator = <2>; + }; + + led@4 { + reg = <4>; + color = <LED_COLOR_ID_GREEN>; + function = LED_FUNCTION_INDICATOR; + function-enumerator = <3>; + }; + }; + - | + #include <dt-bindings/leds/common.h> + + led-controller { + compatible = "qcom,pmi8994-lpg"; + + #address-cells = <1>; + #size-cells = <0>; + + qcom,power-source = <1>; + + multi-led { + color = <LED_COLOR_ID_RGB>; + function = LED_FUNCTION_STATUS; + + #address-cells = <1>; + #size-cells = <0>; + + led@1 { + reg = <1>; + color = <LED_COLOR_ID_RED>; + }; + + led@2 { + reg = <2>; + color = <LED_COLOR_ID_GREEN>; + }; + + led@3 { + reg = <3>; + color = <LED_COLOR_ID_BLUE>; + }; + }; + }; + - | + pwm-controller { + compatible = "qcom,pm8916-pwm"; + #pwm-cells = <2>; + }; +... diff --git a/Documentation/devicetree/bindings/leds/regulator-led.yaml b/Documentation/devicetree/bindings/leds/regulator-led.yaml new file mode 100644 index 000000000000..3e020d700c00 --- /dev/null +++ b/Documentation/devicetree/bindings/leds/regulator-led.yaml @@ -0,0 +1,55 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/leds/regulator-led.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Device Tree Bindings for Regulator LEDs + +maintainers: + - Linus Walleij <linus.walleij@linaro.org> + +description: | + Regulator LEDs are powered by a single regulator such that they can + be turned on or off by enabling or disabling the regulator. The available + brightness settings will be inferred from the available voltages on the + regulator, and any constraints on the voltage or current will need to be + specified on the regulator. + +allOf: + - $ref: common.yaml# + +properties: + $nodename: + pattern: '^led.*$' + + compatible: + const: regulator-led + + vled-supply: + description: + The regulator controlling the current to the LED. + + function: true + color: true + linux,default-trigger: true + default-state: true + +required: + - compatible + - vled-supply + +additionalProperties: false + +examples: + - | + #include <dt-bindings/leds/common.h> + + led-heartbeat { + compatible = "regulator-led"; + vled-supply = <®ulator>; + function = LED_FUNCTION_STATUS; + color = <LED_COLOR_ID_BLUE>; + linux,default-trigger = "heartbeat"; + }; +... diff --git a/Documentation/devicetree/bindings/mailbox/mtk,adsp-mbox.yaml b/Documentation/devicetree/bindings/mailbox/mtk,adsp-mbox.yaml index fe454a1fba17..72c1d9e82c89 100644 --- a/Documentation/devicetree/bindings/mailbox/mtk,adsp-mbox.yaml +++ b/Documentation/devicetree/bindings/mailbox/mtk,adsp-mbox.yaml @@ -11,14 +11,15 @@ maintainers: description: | The MTK ADSP mailbox Inter-Processor Communication (IPC) enables the SoC - to ommunicate with ADSP by passing messages through two mailbox channels. + to communicate with ADSP by passing messages through two mailbox channels. The MTK ADSP mailbox IPC also provides the ability for one processor to signal the other processor using interrupts. properties: compatible: - items: - - const: mediatek,mt8195-adsp-mbox + enum: + - mediatek,mt8195-adsp-mbox + - mediatek,mt8186-adsp-mbox "#mbox-cells": const: 0 diff --git a/Documentation/devicetree/bindings/mailbox/nvidia,tegra186-hsp.yaml b/Documentation/devicetree/bindings/mailbox/nvidia,tegra186-hsp.yaml index 9f7a7296b57f..a3e87516d637 100644 --- a/Documentation/devicetree/bindings/mailbox/nvidia,tegra186-hsp.yaml +++ b/Documentation/devicetree/bindings/mailbox/nvidia,tegra186-hsp.yaml @@ -26,6 +26,15 @@ description: | second cell is used to identify the mailbox that the client is going to use. + For shared mailboxes, the first cell composed of two fields: + - bits 15..8: + A bit mask of flags that further specifies the type of shared + mailbox to be used (based on the data size). If no flag is + specified then, 32-bit shared mailbox is used. + - bits 7..0: + Defines the type of the mailbox to be used. This field should be + TEGRA_HSP_MBOX_TYPE_SM for shared mailboxes. + For doorbells, the second cell specifies the index of the doorbell to use. diff --git a/Documentation/devicetree/bindings/mailbox/qcom-ipcc.yaml b/Documentation/devicetree/bindings/mailbox/qcom-ipcc.yaml index c57dd423e98c..1994be858940 100644 --- a/Documentation/devicetree/bindings/mailbox/qcom-ipcc.yaml +++ b/Documentation/devicetree/bindings/mailbox/qcom-ipcc.yaml @@ -62,23 +62,14 @@ additionalProperties: false examples: - | - #include <dt-bindings/interrupt-controller/arm-gic.h> - #include <dt-bindings/mailbox/qcom-ipcc.h> + #include <dt-bindings/interrupt-controller/arm-gic.h> + #include <dt-bindings/mailbox/qcom-ipcc.h> - mailbox@408000 { - compatible = "qcom,sm8250-ipcc", "qcom,ipcc"; - reg = <0x408000 0x1000>; - interrupts = <GIC_SPI 229 IRQ_TYPE_LEVEL_HIGH>; - interrupt-controller; - #interrupt-cells = <3>; - #mbox-cells = <2>; - }; - - smp2p-modem { - compatible = "qcom,smp2p"; - interrupts-extended = <&ipcc_mproc IPCC_CLIENT_MPSS - IPCC_MPROC_SIGNAL_SMP2P IRQ_TYPE_EDGE_RISING>; - mboxes = <&ipcc_mproc IPCC_CLIENT_MPSS IPCC_MPROC_SIGNAL_SMP2P>; - - /* Other SMP2P fields */ - }; + mailbox@408000 { + compatible = "qcom,sm8250-ipcc", "qcom,ipcc"; + reg = <0x408000 0x1000>; + interrupts = <GIC_SPI 229 IRQ_TYPE_LEVEL_HIGH>; + interrupt-controller; + #interrupt-cells = <3>; + #mbox-cells = <2>; + }; diff --git a/Documentation/devicetree/bindings/mailbox/st,stm32-ipcc.yaml b/Documentation/devicetree/bindings/mailbox/st,stm32-ipcc.yaml index 8eb4bf52ea27..2c8b47285aa3 100644 --- a/Documentation/devicetree/bindings/mailbox/st,stm32-ipcc.yaml +++ b/Documentation/devicetree/bindings/mailbox/st,stm32-ipcc.yaml @@ -30,15 +30,11 @@ properties: items: - description: rx channel occupied - description: tx channel free - - description: wakeup source - minItems: 2 interrupt-names: items: - const: rx - const: tx - - const: wakeup - minItems: 2 wakeup-source: true @@ -70,10 +66,9 @@ examples: #mbox-cells = <1>; reg = <0x4c001000 0x400>; st,proc-id = <0>; - interrupts-extended = <&intc GIC_SPI 100 IRQ_TYPE_NONE>, - <&intc GIC_SPI 101 IRQ_TYPE_NONE>, - <&aiec 62 1>; - interrupt-names = "rx", "tx", "wakeup"; + interrupts-extended = <&exti 61 1>, + <&intc GIC_SPI 101 IRQ_TYPE_LEVEL_HIGH>; + interrupt-names = "rx", "tx"; clocks = <&rcc_clk IPCC>; wakeup-source; }; diff --git a/Documentation/devicetree/bindings/mfd/da9063.txt b/Documentation/devicetree/bindings/mfd/da9063.txt index 91b79a21d403..aa8b800cc4ad 100644 --- a/Documentation/devicetree/bindings/mfd/da9063.txt +++ b/Documentation/devicetree/bindings/mfd/da9063.txt @@ -64,10 +64,13 @@ Sub-nodes: and KEY_SLEEP. - watchdog : This node defines settings for the Watchdog timer associated - with the DA9063 and DA9063L. There are currently no entries in this - binding, however compatible = "dlg,da9063-watchdog" should be added - if a node is created. + with the DA9063 and DA9063L. The node should contain the compatible property + with the value "dlg,da9063-watchdog". + Optional watchdog properties: + - dlg,use-sw-pm: Add this property to disable the watchdog during suspend. + Only use this option if you can't use the watchdog automatic suspend + function during a suspend (see register CONTROL_B). Example: diff --git a/Documentation/devicetree/bindings/mfd/google,cros-ec.yaml b/Documentation/devicetree/bindings/mfd/google,cros-ec.yaml index afec0bd2f1de..e25caf8ef9f4 100644 --- a/Documentation/devicetree/bindings/mfd/google,cros-ec.yaml +++ b/Documentation/devicetree/bindings/mfd/google,cros-ec.yaml @@ -57,7 +57,7 @@ properties: mediatek,rpmsg-name: description: Must be defined if the cros-ec is a rpmsg device for a Mediatek - ARM Cortex M4 Co-processor. Contains the name pf the rpmsg + ARM Cortex M4 Co-processor. Contains the name of the rpmsg device. Used to match the subnode to the rpmsg device announced by the SCP. $ref: "/schemas/types.yaml#/definitions/string" diff --git a/Documentation/devicetree/bindings/mfd/rk808.txt b/Documentation/devicetree/bindings/mfd/rk808.txt deleted file mode 100644 index 23a17a6663ec..000000000000 --- a/Documentation/devicetree/bindings/mfd/rk808.txt +++ /dev/null @@ -1,465 +0,0 @@ -RK8XX Power Management Integrated Circuit - -The rk8xx family current members: -rk805 -rk808 -rk809 -rk817 -rk818 - -Required properties: -- compatible: "rockchip,rk805" -- compatible: "rockchip,rk808" -- compatible: "rockchip,rk809" -- compatible: "rockchip,rk817" -- compatible: "rockchip,rk818" -- reg: I2C slave address -- interrupts: the interrupt outputs of the controller. -- #clock-cells: from common clock binding; shall be set to 1 (multiple clock - outputs). See <dt-bindings/clock/rockchip,rk808.h> for clock IDs. - -Optional properties: -- clock-output-names: From common clock binding to override the - default output clock name -- rockchip,system-power-controller: Telling whether or not this pmic is controlling - the system power. -- wakeup-source: Device can be used as a wakeup source. - -Optional RK805 properties: -- vcc1-supply: The input supply for DCDC_REG1 -- vcc2-supply: The input supply for DCDC_REG2 -- vcc3-supply: The input supply for DCDC_REG3 -- vcc4-supply: The input supply for DCDC_REG4 -- vcc5-supply: The input supply for LDO_REG1 and LDO_REG2 -- vcc6-supply: The input supply for LDO_REG3 - -Optional RK808 properties: -- vcc1-supply: The input supply for DCDC_REG1 -- vcc2-supply: The input supply for DCDC_REG2 -- vcc3-supply: The input supply for DCDC_REG3 -- vcc4-supply: The input supply for DCDC_REG4 -- vcc6-supply: The input supply for LDO_REG1 and LDO_REG2 -- vcc7-supply: The input supply for LDO_REG3 and LDO_REG7 -- vcc8-supply: The input supply for SWITCH_REG1 -- vcc9-supply: The input supply for LDO_REG4 and LDO_REG5 -- vcc10-supply: The input supply for LDO_REG6 -- vcc11-supply: The input supply for LDO_REG8 -- vcc12-supply: The input supply for SWITCH_REG2 -- dvs-gpios: buck1/2 can be controlled by gpio dvs, this is GPIO specifiers - for 2 host gpio's used for dvs. The format of the gpio specifier depends in - the gpio controller. If DVS GPIOs aren't present, voltage changes will happen - very quickly with no slow ramp time. - -Optional shared RK809 and RK817 properties: -- vcc1-supply: The input supply for DCDC_REG1 -- vcc2-supply: The input supply for DCDC_REG2 -- vcc3-supply: The input supply for DCDC_REG3 -- vcc4-supply: The input supply for DCDC_REG4 -- vcc5-supply: The input supply for LDO_REG1, LDO_REG2, LDO_REG3 -- vcc6-supply: The input supply for LDO_REG4, LDO_REG5, LDO_REG6 -- vcc7-supply: The input supply for LDO_REG7, LDO_REG8, LDO_REG9 - -Optional RK809 properties: -- vcc8-supply: The input supply for SWITCH_REG1 -- vcc9-supply: The input supply for DCDC_REG5, SWITCH_REG2 - -Optional RK817 properties: -- clocks: The input clock for the audio codec -- clock-names: The clock name for the codec clock. Should be "mclk". -- #sound-dai-cells: Needed for the interpretation of sound dais. Should be 0. - -- vcc8-supply: The input supply for BOOST -- vcc9-supply: The input supply for OTG_SWITCH -- codec: The child node for the codec to hold additional properties. - If no additional properties are required for the codec, this - node can be omitted. - -- rockchip,mic-in-differential: Telling if the microphone uses differential - mode. Should be under the codec child node. - -Optional RK818 properties: -- vcc1-supply: The input supply for DCDC_REG1 -- vcc2-supply: The input supply for DCDC_REG2 -- vcc3-supply: The input supply for DCDC_REG3 -- vcc4-supply: The input supply for DCDC_REG4 -- boost-supply: The input supply for DCDC_BOOST -- vcc6-supply: The input supply for LDO_REG1 and LDO_REG2 -- vcc7-supply: The input supply for LDO_REG3, LDO_REG5 and LDO_REG7 -- vcc8-supply: The input supply for LDO_REG4, LDO_REG6 and LDO_REG8 -- vcc9-supply: The input supply for LDO_REG9 and SWITCH_REG -- h_5v-supply: The input supply for HDMI_SWITCH -- usb-supply: The input supply for OTG_SWITCH - -Regulators: All the regulators of RK8XX to be instantiated shall be -listed in a child node named 'regulators'. Each regulator is represented -by a child node of the 'regulators' node. - - regulator-name { - /* standard regulator bindings here */ - }; - -Following regulators of the RK805 PMIC regulators are supported. Note that -the 'n' in regulator name, as in DCDC_REGn or LDOn, represents the DCDC or LDO -number as described in RK805 datasheet. - - - DCDC_REGn - - valid values for n are 1 to 4. - - LDO_REGn - - valid values for n are 1 to 3 - -Following regulators of the RK808 PMIC block are supported. Note that -the 'n' in regulator name, as in DCDC_REGn or LDOn, represents the DCDC or LDO -number as described in RK808 datasheet. - - - DCDC_REGn - - valid values for n are 1 to 4. - - LDO_REGn - - valid values for n are 1 to 8. - - SWITCH_REGn - - valid values for n are 1 to 2 - -Following regulators of the RK809 and RK817 PMIC blocks are supported. Note that -the 'n' in regulator name, as in DCDC_REGn or LDOn, represents the DCDC or LDO -number as described in RK809 and RK817 datasheets. - - - DCDC_REGn - - valid values for n are 1 to 5 for RK809. - - valid values for n are 1 to 4 for RK817. - - LDO_REGn - - valid values for n are 1 to 9 for RK809. - - valid values for n are 1 to 9 for RK817. - - SWITCH_REGn - - valid values for n are 1 to 2 for RK809. - - BOOST for RK817 - - OTG_SWITCH for RK817 - -Following regulators of the RK818 PMIC block are supported. Note that -the 'n' in regulator name, as in DCDC_REGn or LDOn, represents the DCDC or LDO -number as described in RK818 datasheet. - - - DCDC_REGn - - valid values for n are 1 to 4. - - LDO_REGn - - valid values for n are 1 to 9. - - SWITCH_REG - - HDMI_SWITCH - - OTG_SWITCH - -It is necessary to configure three pins for both the RK809 and RK817, the three -pins are "gpio_ts" "gpio_gt" "gpio_slp". - The gpio_gt and gpio_ts pins support the gpio function. - The gpio_slp pin is for controlling the pmic states, as below: - - reset - - power down - - sleep - -Standard regulator bindings are used inside regulator subnodes. Check - Documentation/devicetree/bindings/regulator/regulator.txt -for more details - -Example: - rk808: pmic@1b { - compatible = "rockchip,rk808"; - clock-output-names = "xin32k", "rk808-clkout2"; - interrupt-parent = <&gpio0>; - interrupts = <4 IRQ_TYPE_LEVEL_LOW>; - pinctrl-names = "default"; - pinctrl-0 = <&pmic_int &dvs_1 &dvs_2>; - dvs-gpios = <&gpio7 11 GPIO_ACTIVE_HIGH>, - <&gpio7 15 GPIO_ACTIVE_HIGH>; - reg = <0x1b>; - rockchip,system-power-controller; - wakeup-source; - #clock-cells = <1>; - - vcc8-supply = <&vcc_18>; - vcc9-supply = <&vcc_io>; - vcc10-supply = <&vcc_io>; - vcc12-supply = <&vcc_io>; - vddio-supply = <&vccio_pmu>; - - regulators { - vdd_cpu: DCDC_REG1 { - regulator-always-on; - regulator-boot-on; - regulator-min-microvolt = <750000>; - regulator-max-microvolt = <1300000>; - regulator-name = "vdd_arm"; - }; - - vdd_gpu: DCDC_REG2 { - regulator-always-on; - regulator-boot-on; - regulator-min-microvolt = <850000>; - regulator-max-microvolt = <1250000>; - regulator-name = "vdd_gpu"; - }; - - vcc_ddr: DCDC_REG3 { - regulator-always-on; - regulator-boot-on; - regulator-name = "vcc_ddr"; - }; - - vcc_io: DCDC_REG4 { - regulator-always-on; - regulator-boot-on; - regulator-min-microvolt = <3300000>; - regulator-max-microvolt = <3300000>; - regulator-name = "vcc_io"; - }; - - vccio_pmu: LDO_REG1 { - regulator-always-on; - regulator-boot-on; - regulator-min-microvolt = <3300000>; - regulator-max-microvolt = <3300000>; - regulator-name = "vccio_pmu"; - }; - - vcc_tp: LDO_REG2 { - regulator-always-on; - regulator-boot-on; - regulator-min-microvolt = <3300000>; - regulator-max-microvolt = <3300000>; - regulator-name = "vcc_tp"; - }; - - vdd_10: LDO_REG3 { - regulator-always-on; - regulator-boot-on; - regulator-min-microvolt = <1000000>; - regulator-max-microvolt = <1000000>; - regulator-name = "vdd_10"; - }; - - vcc18_lcd: LDO_REG4 { - regulator-always-on; - regulator-boot-on; - regulator-min-microvolt = <1800000>; - regulator-max-microvolt = <1800000>; - regulator-name = "vcc18_lcd"; - }; - - vccio_sd: LDO_REG5 { - regulator-always-on; - regulator-boot-on; - regulator-min-microvolt = <1800000>; - regulator-max-microvolt = <3300000>; - regulator-name = "vccio_sd"; - }; - - vdd10_lcd: LDO_REG6 { - regulator-always-on; - regulator-boot-on; - regulator-min-microvolt = <1000000>; - regulator-max-microvolt = <1000000>; - regulator-name = "vdd10_lcd"; - }; - - vcc_18: LDO_REG7 { - regulator-always-on; - regulator-boot-on; - regulator-min-microvolt = <1800000>; - regulator-max-microvolt = <1800000>; - regulator-name = "vcc_18"; - }; - - vcca_codec: LDO_REG8 { - regulator-always-on; - regulator-boot-on; - regulator-min-microvolt = <3300000>; - regulator-max-microvolt = <3300000>; - regulator-name = "vcca_codec"; - }; - - vcc_wl: SWITCH_REG1 { - regulator-always-on; - regulator-boot-on; - regulator-name = "vcc_wl"; - }; - - vcc_lcd: SWITCH_REG2 { - regulator-always-on; - regulator-boot-on; - regulator-name = "vcc_lcd"; - }; - }; - }; - - rk817: pmic@20 { - compatible = "rockchip,rk817"; - reg = <0x20>; - interrupt-parent = <&gpio0>; - interrupts = <RK_PB2 IRQ_TYPE_LEVEL_LOW>; - clock-output-names = "rk808-clkout1", "xin32k"; - clock-names = "mclk"; - clocks = <&cru SCLK_I2S1_OUT>; - pinctrl-names = "default"; - pinctrl-0 = <&pmic_int>, <&i2s1_2ch_mclk>; - wakeup-source; - #clock-cells = <1>; - #sound-dai-cells = <0>; - - vcc1-supply = <&vccsys>; - vcc2-supply = <&vccsys>; - vcc3-supply = <&vccsys>; - vcc4-supply = <&vccsys>; - vcc5-supply = <&vccsys>; - vcc6-supply = <&vccsys>; - vcc7-supply = <&vccsys>; - - regulators { - vdd_logic: DCDC_REG1 { - regulator-name = "vdd_logic"; - regulator-min-microvolt = <950000>; - regulator-max-microvolt = <1150000>; - regulator-ramp-delay = <6001>; - regulator-always-on; - regulator-boot-on; - - regulator-state-mem { - regulator-on-in-suspend; - regulator-suspend-microvolt = <950000>; - }; - }; - - vdd_arm: DCDC_REG2 { - regulator-name = "vdd_arm"; - regulator-min-microvolt = <950000>; - regulator-max-microvolt = <1350000>; - regulator-ramp-delay = <6001>; - regulator-always-on; - regulator-boot-on; - - regulator-state-mem { - regulator-off-in-suspend; - regulator-suspend-microvolt = <950000>; - }; - }; - - vcc_ddr: DCDC_REG3 { - regulator-name = "vcc_ddr"; - regulator-always-on; - regulator-boot-on; - - regulator-state-mem { - regulator-on-in-suspend; - }; - }; - - vcc_3v3: DCDC_REG4 { - regulator-name = "vcc_3v3"; - regulator-min-microvolt = <3300000>; - regulator-max-microvolt = <3300000>; - regulator-always-on; - regulator-boot-on; - - regulator-state-mem { - regulator-off-in-suspend; - regulator-suspend-microvolt = <3300000>; - }; - }; - - vcc_1v8: LDO_REG2 { - regulator-name = "vcc_1v8"; - regulator-min-microvolt = <1800000>; - regulator-max-microvolt = <1800000>; - regulator-always-on; - regulator-boot-on; - - regulator-state-mem { - regulator-on-in-suspend; - regulator-suspend-microvolt = <1800000>; - }; - }; - - vdd_1v0: LDO_REG3 { - regulator-name = "vdd_1v0"; - regulator-min-microvolt = <1000000>; - regulator-max-microvolt = <1000000>; - regulator-always-on; - regulator-boot-on; - - regulator-state-mem { - regulator-on-in-suspend; - regulator-suspend-microvolt = <1000000>; - }; - }; - - vcc3v3_pmu: LDO_REG4 { - regulator-name = "vcc3v3_pmu"; - regulator-min-microvolt = <3300000>; - regulator-max-microvolt = <3300000>; - regulator-always-on; - regulator-boot-on; - - regulator-state-mem { - regulator-on-in-suspend; - regulator-suspend-microvolt = <3300000>; - }; - }; - - vccio_sd: LDO_REG5 { - regulator-name = "vccio_sd"; - regulator-min-microvolt = <1800000>; - regulator-max-microvolt = <3300000>; - regulator-always-on; - regulator-boot-on; - - regulator-state-mem { - regulator-on-in-suspend; - regulator-suspend-microvolt = <3300000>; - }; - }; - - vcc_sd: LDO_REG6 { - regulator-name = "vcc_sd"; - regulator-min-microvolt = <3300000>; - regulator-max-microvolt = <3300000>; - regulator-boot-on; - - regulator-state-mem { - regulator-on-in-suspend; - regulator-suspend-microvolt = <3300000>; - }; - }; - - vcc_bl: LDO_REG7 { - regulator-name = "vcc_bl"; - regulator-min-microvolt = <3300000>; - regulator-max-microvolt = <3300000>; - - regulator-state-mem { - regulator-off-in-suspend; - regulator-suspend-microvolt = <3300000>; - }; - }; - - vcc_lcd: LDO_REG8 { - regulator-name = "vcc_lcd"; - regulator-min-microvolt = <2800000>; - regulator-max-microvolt = <2800000>; - - regulator-state-mem { - regulator-off-in-suspend; - regulator-suspend-microvolt = <2800000>; - }; - }; - - vcc_cam: LDO_REG9 { - regulator-name = "vcc_cam"; - regulator-min-microvolt = <3000000>; - regulator-max-microvolt = <3000000>; - - regulator-state-mem { - regulator-off-in-suspend; - regulator-suspend-microvolt = <3000000>; - }; - }; - }; - - rk817_codec: codec { - rockchip,mic-in-differential; - }; - }; diff --git a/Documentation/devicetree/bindings/mfd/rockchip,rk805.yaml b/Documentation/devicetree/bindings/mfd/rockchip,rk805.yaml new file mode 100644 index 000000000000..4992f71b6fc3 --- /dev/null +++ b/Documentation/devicetree/bindings/mfd/rockchip,rk805.yaml @@ -0,0 +1,219 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/mfd/rockchip,rk805.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: RK805 Power Management Integrated Circuit + +maintainers: + - Chris Zhong <zyw@rock-chips.com> + - Zhang Qing <zhangqing@rock-chips.com> + +description: | + Rockchip RK805 series PMIC. This device consists of an i2c controlled MFD + that includes multiple switchable regulators. + +properties: + compatible: + enum: + - rockchip,rk805 + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + '#clock-cells': + description: + See <dt-bindings/clock/rockchip,rk808.h> for clock IDs. + minimum: 0 + maximum: 1 + + clock-output-names: + description: + From common clock binding to override the default output clock name. + + gpio-controller: true + + '#gpio-cells': + const: 2 + + rockchip,system-power-controller: + type: boolean + description: + Telling whether or not this PMIC is controlling the system power. + + wakeup-source: + type: boolean + description: + Device can be used as a wakeup source. + + vcc1-supply: + description: + The input supply for DCDC_REG1. + + vcc2-supply: + description: + The input supply for DCDC_REG2. + + vcc3-supply: + description: + The input supply for DCDC_REG3. + + vcc4-supply: + description: + The input supply for DCDC_REG4. + + vcc5-supply: + description: + The input supply for LDO_REG1 and LDO_REG2. + + vcc6-supply: + description: + The input supply for LDO_REG3. + + regulators: + type: object + patternProperties: + "^(DCDC_REG[1-4]|LDO_REG[1-3])$": + type: object + $ref: ../regulator/regulator.yaml# + unevaluatedProperties: false + +allOf: + - if: + properties: + '#clock-cells': + const: 0 + + then: + properties: + clock-output-names: + maxItems: 1 + + else: + properties: + clock-output-names: + maxItems: 2 + +required: + - compatible + - reg + - interrupts + - "#clock-cells" + +additionalProperties: false + +examples: + - | + #include <dt-bindings/pinctrl/rockchip.h> + #include <dt-bindings/interrupt-controller/irq.h> + #include <dt-bindings/gpio/gpio.h> + i2c { + #address-cells = <1>; + #size-cells = <0>; + + pmic@18 { + compatible = "rockchip,rk805"; + reg = <0x18>; + interrupt-parent = <&gpio2>; + interrupts = <RK_PA6 IRQ_TYPE_LEVEL_LOW>; + pinctrl-names = "default"; + pinctrl-0 = <&pmic_int_l>; + rockchip,system-power-controller; + wakeup-source; + #clock-cells = <0>; + + vcc1-supply = <&vcc_sys>; + vcc2-supply = <&vcc_sys>; + vcc3-supply = <&vcc_sys>; + vcc4-supply = <&vcc_sys>; + vcc5-supply = <&vcc_io>; + vcc6-supply = <&vcc_io>; + + regulators { + vdd_logic: DCDC_REG1 { + regulator-name = "vdd_logic"; + regulator-min-microvolt = <700000>; + regulator-max-microvolt = <1350000>; + regulator-always-on; + regulator-boot-on; + regulator-state-mem { + regulator-on-in-suspend; + regulator-suspend-microvolt = <1000000>; + }; + }; + + vdd_arm: DCDC_REG2 { + regulator-name = "vdd_arm"; + regulator-min-microvolt = <700000>; + regulator-max-microvolt = <1350000>; + regulator-always-on; + regulator-boot-on; + regulator-state-mem { + regulator-on-in-suspend; + regulator-suspend-microvolt = <950000>; + }; + }; + + vcc_ddr: DCDC_REG3 { + regulator-name = "vcc_ddr"; + regulator-always-on; + regulator-boot-on; + regulator-state-mem { + regulator-on-in-suspend; + }; + }; + + vcc_io: DCDC_REG4 { + regulator-name = "vcc_io"; + regulator-min-microvolt = <3300000>; + regulator-max-microvolt = <3300000>; + regulator-always-on; + regulator-boot-on; + regulator-state-mem { + regulator-on-in-suspend; + regulator-suspend-microvolt = <3300000>; + }; + }; + + vdd_18: LDO_REG1 { + regulator-name = "vdd_18"; + regulator-min-microvolt = <1800000>; + regulator-max-microvolt = <1800000>; + regulator-always-on; + regulator-boot-on; + regulator-state-mem { + regulator-on-in-suspend; + regulator-suspend-microvolt = <1800000>; + }; + }; + + vcc18_emmc: LDO_REG2 { + regulator-name = "vcc_18emmc"; + regulator-min-microvolt = <1800000>; + regulator-max-microvolt = <1800000>; + regulator-always-on; + regulator-boot-on; + regulator-state-mem { + regulator-on-in-suspend; + regulator-suspend-microvolt = <1800000>; + }; + }; + + vdd_11: LDO_REG3 { + regulator-name = "vdd_11"; + regulator-min-microvolt = <1100000>; + regulator-max-microvolt = <1100000>; + regulator-always-on; + regulator-boot-on; + regulator-state-mem { + regulator-on-in-suspend; + regulator-suspend-microvolt = <1100000>; + }; + }; + }; + }; + }; diff --git a/Documentation/devicetree/bindings/mfd/rockchip,rk808.yaml b/Documentation/devicetree/bindings/mfd/rockchip,rk808.yaml new file mode 100644 index 000000000000..f5908fa01a61 --- /dev/null +++ b/Documentation/devicetree/bindings/mfd/rockchip,rk808.yaml @@ -0,0 +1,257 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/mfd/rockchip,rk808.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: RK808 Power Management Integrated Circuit + +maintainers: + - Chris Zhong <zyw@rock-chips.com> + - Zhang Qing <zhangqing@rock-chips.com> + +description: | + Rockchip RK808 series PMIC. This device consists of an i2c controlled MFD + that includes regulators, an RTC, and a power button. + +properties: + compatible: + enum: + - rockchip,rk808 + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + '#clock-cells': + description: + See <dt-bindings/clock/rockchip,rk808.h> for clock IDs. + const: 1 + + clock-output-names: + description: + From common clock binding to override the default output clock name. + maxItems: 2 + + rockchip,system-power-controller: + type: boolean + description: + Telling whether or not this PMIC is controlling the system power. + + wakeup-source: + type: boolean + description: + Device can be used as a wakeup source. + + vcc1-supply: + description: + The input supply for DCDC_REG1. + + vcc2-supply: + description: + The input supply for DCDC_REG2. + + vcc3-supply: + description: + The input supply for DCDC_REG3. + + vcc4-supply: + description: + The input supply for DCDC_REG4. + + vcc6-supply: + description: + The input supply for LDO_REG1 and LDO_REG2. + + vcc7-supply: + description: + The input supply for LDO_REG3 and LDO_REG7. + + vcc8-supply: + description: + The input supply for SWITCH_REG1. + + vcc9-supply: + description: + The input supply for LDO_REG4 and LDO_REG5. + + vcc10-supply: + description: + The input supply for LDO_REG6. + + vcc11-supply: + description: + The input supply for LDO_REG8. + + vcc12-supply: + description: + The input supply for SWITCH_REG2. + + vddio-supply: + description: + The input supply for digital IO. + + dvs-gpios: + description: | + buck1/2 can be controlled by gpio dvs, this is GPIO specifiers for + 2 host gpio's used for dvs. The format of the gpio specifier + depends in the gpio controller. If DVS GPIOs aren't present, + voltage changes will happen very quickly with no slow ramp time. + maxItems: 2 + + regulators: + type: object + patternProperties: + "^(DCDC_REG[1-4]|LDO_REG[1-8]|SWITCH_REG[1-2])$": + type: object + $ref: ../regulator/regulator.yaml# + unevaluatedProperties: false + +required: + - compatible + - reg + - interrupts + - "#clock-cells" + +additionalProperties: false + +examples: + - | + #include <dt-bindings/pinctrl/rockchip.h> + #include <dt-bindings/interrupt-controller/irq.h> + #include <dt-bindings/gpio/gpio.h> + i2c { + #address-cells = <1>; + #size-cells = <0>; + + rk808: pmic@1b { + compatible = "rockchip,rk808"; + clock-output-names = "xin32k", "rk808-clkout2"; + interrupt-parent = <&gpio0>; + interrupts = <4 IRQ_TYPE_LEVEL_LOW>; + pinctrl-names = "default"; + pinctrl-0 = <&pmic_int &dvs_1 &dvs_2>; + dvs-gpios = <&gpio7 11 GPIO_ACTIVE_HIGH>, + <&gpio7 15 GPIO_ACTIVE_HIGH>; + reg = <0x1b>; + rockchip,system-power-controller; + wakeup-source; + #clock-cells = <1>; + + vcc8-supply = <&vcc_18>; + vcc9-supply = <&vcc_io>; + vcc10-supply = <&vcc_io>; + vcc12-supply = <&vcc_io>; + vddio-supply = <&vccio_pmu>; + + regulators { + vdd_cpu: DCDC_REG1 { + regulator-always-on; + regulator-boot-on; + regulator-min-microvolt = <750000>; + regulator-max-microvolt = <1300000>; + regulator-name = "vdd_arm"; + }; + + vdd_gpu: DCDC_REG2 { + regulator-always-on; + regulator-boot-on; + regulator-min-microvolt = <850000>; + regulator-max-microvolt = <1250000>; + regulator-name = "vdd_gpu"; + }; + + vcc_ddr: DCDC_REG3 { + regulator-always-on; + regulator-boot-on; + regulator-name = "vcc_ddr"; + }; + + vcc_io: DCDC_REG4 { + regulator-always-on; + regulator-boot-on; + regulator-min-microvolt = <3300000>; + regulator-max-microvolt = <3300000>; + regulator-name = "vcc_io"; + }; + + vccio_pmu: LDO_REG1 { + regulator-always-on; + regulator-boot-on; + regulator-min-microvolt = <3300000>; + regulator-max-microvolt = <3300000>; + regulator-name = "vccio_pmu"; + }; + + vcc_tp: LDO_REG2 { + regulator-always-on; + regulator-boot-on; + regulator-min-microvolt = <3300000>; + regulator-max-microvolt = <3300000>; + regulator-name = "vcc_tp"; + }; + + vdd_10: LDO_REG3 { + regulator-always-on; + regulator-boot-on; + regulator-min-microvolt = <1000000>; + regulator-max-microvolt = <1000000>; + regulator-name = "vdd_10"; + }; + + vcc18_lcd: LDO_REG4 { + regulator-always-on; + regulator-boot-on; + regulator-min-microvolt = <1800000>; + regulator-max-microvolt = <1800000>; + regulator-name = "vcc18_lcd"; + }; + + vccio_sd: LDO_REG5 { + regulator-always-on; + regulator-boot-on; + regulator-min-microvolt = <1800000>; + regulator-max-microvolt = <3300000>; + regulator-name = "vccio_sd"; + }; + + vdd10_lcd: LDO_REG6 { + regulator-always-on; + regulator-boot-on; + regulator-min-microvolt = <1000000>; + regulator-max-microvolt = <1000000>; + regulator-name = "vdd10_lcd"; + }; + + vcc_18: LDO_REG7 { + regulator-always-on; + regulator-boot-on; + regulator-min-microvolt = <1800000>; + regulator-max-microvolt = <1800000>; + regulator-name = "vcc_18"; + }; + + vcca_codec: LDO_REG8 { + regulator-always-on; + regulator-boot-on; + regulator-min-microvolt = <3300000>; + regulator-max-microvolt = <3300000>; + regulator-name = "vcca_codec"; + }; + + vcc_wl: SWITCH_REG1 { + regulator-always-on; + regulator-boot-on; + regulator-name = "vcc_wl"; + }; + + vcc_lcd: SWITCH_REG2 { + regulator-always-on; + regulator-boot-on; + regulator-name = "vcc_lcd"; + }; + }; + }; + }; diff --git a/Documentation/devicetree/bindings/mfd/rockchip,rk809.yaml b/Documentation/devicetree/bindings/mfd/rockchip,rk809.yaml new file mode 100644 index 000000000000..7fb849ac74a7 --- /dev/null +++ b/Documentation/devicetree/bindings/mfd/rockchip,rk809.yaml @@ -0,0 +1,284 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/mfd/rockchip,rk809.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: RK809 Power Management Integrated Circuit + +maintainers: + - Chris Zhong <zyw@rock-chips.com> + - Zhang Qing <zhangqing@rock-chips.com> + +description: | + Rockchip RK809 series PMIC. This device consists of an i2c controlled MFD + that includes regulators, an RTC, and power button. + +properties: + compatible: + enum: + - rockchip,rk809 + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + '#clock-cells': + description: | + See <dt-bindings/clock/rockchip,rk808.h> for clock IDs. + minimum: 0 + maximum: 1 + + clock-output-names: + description: + From common clock binding to override the default output clock name. + + rockchip,system-power-controller: + type: boolean + description: + Telling whether or not this PMIC is controlling the system power. + + wakeup-source: + type: boolean + description: + Device can be used as a wakeup source. + + vcc1-supply: + description: + The input supply for DCDC_REG1. + + vcc2-supply: + description: + The input supply for DCDC_REG2. + + vcc3-supply: + description: + The input supply for DCDC_REG3. + + vcc4-supply: + description: + The input supply for DCDC_REG4. + + vcc5-supply: + description: + The input supply for LDO_REG1, LDO_REG2, and LDO_REG3. + + vcc6-supply: + description: + The input supply for LDO_REG4, LDO_REG5, and LDO_REG6. + + vcc7-supply: + description: + The input supply for LDO_REG7, LDO_REG8, and LDO_REG9. + + vcc8-supply: + description: + The input supply for SWITCH_REG1. + + vcc9-supply: + description: + The input supply for DCDC_REG5 and SWITCH_REG2. + + regulators: + type: object + patternProperties: + "^(LDO_REG[1-9]|DCDC_REG[1-5]|SWITCH_REG[1-2])$": + type: object + $ref: ../regulator/regulator.yaml# + unevaluatedProperties: false + +allOf: + - if: + properties: + '#clock-cells': + const: 0 + + then: + properties: + clock-output-names: + maxItems: 1 + + else: + properties: + clock-output-names: + maxItems: 2 + +required: + - compatible + - reg + - interrupts + - "#clock-cells" + +additionalProperties: false + +examples: + - | + #include <dt-bindings/pinctrl/rockchip.h> + #include <dt-bindings/interrupt-controller/irq.h> + #include <dt-bindings/gpio/gpio.h> + i2c { + #address-cells = <1>; + #size-cells = <0>; + + rk808: pmic@1b { + compatible = "rockchip,rk808"; + reg = <0x1b>; + #clock-cells = <1>; + clock-output-names = "xin32k", "rk808-clkout2"; + interrupt-parent = <&gpio3>; + interrupts = <10 IRQ_TYPE_LEVEL_LOW>; + pinctrl-names = "default"; + pinctrl-0 = <&pmic_int_l_pin>; + rockchip,system-power-controller; + wakeup-source; + + vcc1-supply = <&vcc_sysin>; + vcc2-supply = <&vcc_sysin>; + vcc3-supply = <&vcc_sysin>; + vcc4-supply = <&vcc_sysin>; + vcc6-supply = <&vcc_sysin>; + vcc7-supply = <&vcc_sysin>; + vcc8-supply = <&vcc3v3_sys>; + vcc9-supply = <&vcc_sysin>; + vcc10-supply = <&vcc_sysin>; + vcc11-supply = <&vcc_sysin>; + vcc12-supply = <&vcc3v3_sys>; + + regulators { + vdd_center: DCDC_REG1 { + regulator-name = "vdd_center"; + regulator-always-on; + regulator-boot-on; + regulator-min-microvolt = <750000>; + regulator-max-microvolt = <1350000>; + regulator-ramp-delay = <6001>; + regulator-state-mem { + regulator-off-in-suspend; + }; + }; + + vdd_cpu_l: DCDC_REG2 { + regulator-name = "vdd_cpu_l"; + regulator-always-on; + regulator-boot-on; + regulator-min-microvolt = <750000>; + regulator-max-microvolt = <1350000>; + regulator-ramp-delay = <6001>; + regulator-state-mem { + regulator-off-in-suspend; + }; + }; + + vcc_ddr: DCDC_REG3 { + regulator-name = "vcc_ddr"; + regulator-always-on; + regulator-boot-on; + regulator-state-mem { + regulator-on-in-suspend; + }; + }; + + vcc_1v8: vcc_wl: DCDC_REG4 { + regulator-name = "vcc_1v8"; + regulator-always-on; + regulator-boot-on; + regulator-min-microvolt = <1800000>; + regulator-max-microvolt = <1800000>; + regulator-state-mem { + regulator-on-in-suspend; + regulator-suspend-microvolt = <1800000>; + }; + }; + + vcc1v8_pmupll: LDO_REG3 { + regulator-name = "vcc1v8_pmupll"; + regulator-always-on; + regulator-boot-on; + regulator-min-microvolt = <1800000>; + regulator-max-microvolt = <1800000>; + regulator-state-mem { + regulator-on-in-suspend; + regulator-suspend-microvolt = <1800000>; + }; + }; + + vcc_sdio: LDO_REG4 { + regulator-name = "vcc_sdio"; + regulator-always-on; + regulator-boot-on; + regulator-min-microvolt = <1800000>; + regulator-max-microvolt = <3000000>; + regulator-state-mem { + regulator-on-in-suspend; + regulator-suspend-microvolt = <3000000>; + }; + }; + + vcca3v0_codec: LDO_REG5 { + regulator-name = "vcca3v0_codec"; + regulator-always-on; + regulator-boot-on; + regulator-min-microvolt = <3000000>; + regulator-max-microvolt = <3000000>; + regulator-state-mem { + regulator-off-in-suspend; + }; + }; + + vcc_1v5: LDO_REG6 { + regulator-name = "vcc_1v5"; + regulator-always-on; + regulator-boot-on; + regulator-min-microvolt = <1500000>; + regulator-max-microvolt = <1500000>; + regulator-state-mem { + regulator-on-in-suspend; + regulator-suspend-microvolt = <1500000>; + }; + }; + + vcca1v8_codec: LDO_REG7 { + regulator-name = "vcca1v8_codec"; + regulator-always-on; + regulator-boot-on; + regulator-min-microvolt = <1800000>; + regulator-max-microvolt = <1800000>; + regulator-state-mem { + regulator-off-in-suspend; + }; + }; + + vcc_3v0: LDO_REG8 { + regulator-name = "vcc_3v0"; + regulator-always-on; + regulator-boot-on; + regulator-min-microvolt = <3000000>; + regulator-max-microvolt = <3000000>; + regulator-state-mem { + regulator-on-in-suspend; + regulator-suspend-microvolt = <3000000>; + }; + }; + + vcc3v3_s3: SWITCH_REG1 { + regulator-name = "vcc3v3_s3"; + regulator-always-on; + regulator-boot-on; + regulator-state-mem { + regulator-off-in-suspend; + }; + }; + + vcc3v3_s0: SWITCH_REG2 { + regulator-name = "vcc3v3_s0"; + regulator-always-on; + regulator-boot-on; + regulator-state-mem { + regulator-off-in-suspend; + }; + }; + }; + }; + }; diff --git a/Documentation/devicetree/bindings/mfd/rockchip,rk817.yaml b/Documentation/devicetree/bindings/mfd/rockchip,rk817.yaml new file mode 100644 index 000000000000..bfc1720adc43 --- /dev/null +++ b/Documentation/devicetree/bindings/mfd/rockchip,rk817.yaml @@ -0,0 +1,330 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/mfd/rockchip,rk817.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: RK817 Power Management Integrated Circuit + +maintainers: + - Chris Zhong <zyw@rock-chips.com> + - Zhang Qing <zhangqing@rock-chips.com> + +description: | + Rockchip RK817 series PMIC. This device consists of an i2c controlled MFD + that includes regulators, an RTC, a power button, an audio codec, and a + battery charger manager. + +properties: + compatible: + enum: + - rockchip,rk817 + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + '#clock-cells': + description: + See <dt-bindings/clock/rockchip,rk808.h> for clock IDs. + minimum: 0 + maximum: 1 + + clock-output-names: + description: + From common clock binding to override the default output clock name. + + rockchip,system-power-controller: + type: boolean + description: + Telling whether or not this PMIC is controlling the system power. + + wakeup-source: + type: boolean + description: + Device can be used as a wakeup source. + + vcc1-supply: + description: + The input supply for DCDC_REG1. + + vcc2-supply: + description: + The input supply for DCDC_REG2. + + vcc3-supply: + description: + The input supply for DCDC_REG3. + + vcc4-supply: + description: + The input supply for DCDC_REG4. + + vcc5-supply: + description: + The input supply for LDO_REG1, LDO_REG2, and LDO_REG3. + + vcc6-supply: + description: + The input supply for LDO_REG4, LDO_REG5, and LDO_REG6. + + vcc7-supply: + description: + The input supply for LDO_REG7, LDO_REG8, and LDO_REG9. + + vcc8-supply: + description: + The input supply for BOOST. + + vcc9-supply: + description: + The input supply for OTG_SWITCH. + + regulators: + type: object + patternProperties: + "^(LDO_REG[1-9]|DCDC_REG[1-4]|BOOST|OTG_SWITCH)$": + type: object + $ref: ../regulator/regulator.yaml# + unevaluatedProperties: false + + clocks: + description: + The input clock for the audio codec. + + clock-names: + description: + The clock name for the codec clock. + items: + - const: mclk + + '#sound-dai-cells': + description: + Needed for the interpretation of sound dais. + const: 0 + + codec: + description: | + The child node for the codec to hold additional properties. If no + additional properties are required for the codec, this node can be + omitted. + type: object + properties: + rockchip,mic-in-differential: + type: boolean + description: + Describes if the microphone uses differential mode. + +allOf: + - if: + properties: + '#clock-cells': + const: 0 + + then: + properties: + clock-output-names: + maxItems: 1 + + else: + properties: + clock-output-names: + maxItems: 2 + +required: + - compatible + - reg + - interrupts + - "#clock-cells" + +additionalProperties: false + +examples: + - | + #include <dt-bindings/clock/px30-cru.h> + #include <dt-bindings/pinctrl/rockchip.h> + #include <dt-bindings/interrupt-controller/irq.h> + #include <dt-bindings/gpio/gpio.h> + i2c { + #address-cells = <1>; + #size-cells = <0>; + + rk817: pmic@20 { + compatible = "rockchip,rk817"; + reg = <0x20>; + interrupt-parent = <&gpio0>; + interrupts = <RK_PB2 IRQ_TYPE_LEVEL_LOW>; + clock-output-names = "rk808-clkout1", "xin32k"; + clock-names = "mclk"; + clocks = <&cru SCLK_I2S1_OUT>; + pinctrl-names = "default"; + pinctrl-0 = <&pmic_int>, <&i2s1_2ch_mclk>; + wakeup-source; + #clock-cells = <1>; + #sound-dai-cells = <0>; + + vcc1-supply = <&vccsys>; + vcc2-supply = <&vccsys>; + vcc3-supply = <&vccsys>; + vcc4-supply = <&vccsys>; + vcc5-supply = <&vccsys>; + vcc6-supply = <&vccsys>; + vcc7-supply = <&vccsys>; + + regulators { + vdd_logic: DCDC_REG1 { + regulator-name = "vdd_logic"; + regulator-min-microvolt = <950000>; + regulator-max-microvolt = <1150000>; + regulator-ramp-delay = <6001>; + regulator-always-on; + regulator-boot-on; + + regulator-state-mem { + regulator-on-in-suspend; + regulator-suspend-microvolt = <950000>; + }; + }; + + vdd_arm: DCDC_REG2 { + regulator-name = "vdd_arm"; + regulator-min-microvolt = <950000>; + regulator-max-microvolt = <1350000>; + regulator-ramp-delay = <6001>; + regulator-always-on; + regulator-boot-on; + + regulator-state-mem { + regulator-off-in-suspend; + regulator-suspend-microvolt = <950000>; + }; + }; + + vcc_ddr: DCDC_REG3 { + regulator-name = "vcc_ddr"; + regulator-always-on; + regulator-boot-on; + + regulator-state-mem { + regulator-on-in-suspend; + }; + }; + + vcc_3v3: DCDC_REG4 { + regulator-name = "vcc_3v3"; + regulator-min-microvolt = <3300000>; + regulator-max-microvolt = <3300000>; + regulator-always-on; + regulator-boot-on; + + regulator-state-mem { + regulator-off-in-suspend; + regulator-suspend-microvolt = <3300000>; + }; + }; + + vcc_1v8: LDO_REG2 { + regulator-name = "vcc_1v8"; + regulator-min-microvolt = <1800000>; + regulator-max-microvolt = <1800000>; + regulator-always-on; + regulator-boot-on; + + regulator-state-mem { + regulator-on-in-suspend; + regulator-suspend-microvolt = <1800000>; + }; + }; + + vdd_1v0: LDO_REG3 { + regulator-name = "vdd_1v0"; + regulator-min-microvolt = <1000000>; + regulator-max-microvolt = <1000000>; + regulator-always-on; + regulator-boot-on; + + regulator-state-mem { + regulator-on-in-suspend; + regulator-suspend-microvolt = <1000000>; + }; + }; + + vcc3v3_pmu: LDO_REG4 { + regulator-name = "vcc3v3_pmu"; + regulator-min-microvolt = <3300000>; + regulator-max-microvolt = <3300000>; + regulator-always-on; + regulator-boot-on; + + regulator-state-mem { + regulator-on-in-suspend; + regulator-suspend-microvolt = <3300000>; + }; + }; + + vccio_sd: LDO_REG5 { + regulator-name = "vccio_sd"; + regulator-min-microvolt = <1800000>; + regulator-max-microvolt = <3300000>; + regulator-always-on; + regulator-boot-on; + + regulator-state-mem { + regulator-on-in-suspend; + regulator-suspend-microvolt = <3300000>; + }; + }; + + vcc_sd: LDO_REG6 { + regulator-name = "vcc_sd"; + regulator-min-microvolt = <3300000>; + regulator-max-microvolt = <3300000>; + regulator-boot-on; + + regulator-state-mem { + regulator-on-in-suspend; + regulator-suspend-microvolt = <3300000>; + }; + }; + + vcc_bl: LDO_REG7 { + regulator-name = "vcc_bl"; + regulator-min-microvolt = <3300000>; + regulator-max-microvolt = <3300000>; + + regulator-state-mem { + regulator-off-in-suspend; + regulator-suspend-microvolt = <3300000>; + }; + }; + + vcc_lcd: LDO_REG8 { + regulator-name = "vcc_lcd"; + regulator-min-microvolt = <2800000>; + regulator-max-microvolt = <2800000>; + + regulator-state-mem { + regulator-off-in-suspend; + regulator-suspend-microvolt = <2800000>; + }; + }; + + vcc_cam: LDO_REG9 { + regulator-name = "vcc_cam"; + regulator-min-microvolt = <3000000>; + regulator-max-microvolt = <3000000>; + + regulator-state-mem { + regulator-off-in-suspend; + regulator-suspend-microvolt = <3000000>; + }; + }; + }; + + rk817_codec: codec { + rockchip,mic-in-differential; + }; + }; + }; diff --git a/Documentation/devicetree/bindings/mfd/rockchip,rk818.yaml b/Documentation/devicetree/bindings/mfd/rockchip,rk818.yaml new file mode 100644 index 000000000000..b57c4b005cf4 --- /dev/null +++ b/Documentation/devicetree/bindings/mfd/rockchip,rk818.yaml @@ -0,0 +1,282 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/mfd/rockchip,rk818.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: RK818 Power Management Integrated Circuit + +maintainers: + - Chris Zhong <zyw@rock-chips.com> + - Zhang Qing <zhangqing@rock-chips.com> + +description: | + Rockchip RK818 series PMIC. This device consists of an i2c controlled MFD + that includes regulators, an RTC, and a power button. + +properties: + compatible: + enum: + - rockchip,rk818 + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + '#clock-cells': + description: | + See <dt-bindings/clock/rockchip,rk808.h> for clock IDs. + const: 1 + + clock-output-names: + description: + From common clock binding to override the default output clock name. + maxItems: 2 + + rockchip,system-power-controller: + type: boolean + description: + Telling whether or not this PMIC is controlling the system power. + + wakeup-source: + type: boolean + description: + Device can be used as a wakeup source. + + vcc1-supply: + description: + The input supply for DCDC_REG1. + + vcc2-supply: + description: + The input supply for DCDC_REG2. + + vcc3-supply: + description: + The input supply for DCDC_REG3. + + vcc4-supply: + description: + The input supply for DCDC_REG4. + + boost-supply: + description: + The input supply for DCDC_BOOST + + vcc6-supply: + description: + The input supply for LDO_REG1 and LDO_REG2. + + vcc7-supply: + description: + The input supply for LDO_REG3, LDO_REG5, and LDO_REG7. + + vcc8-supply: + description: + The input supply for LDO_REG4, LDO_REG6, and LDO_REG8. + + vcc9-supply: + description: + The input supply for LDO_REG9 and SWITCH_REG. + + vddio-supply: + description: + The input supply for digital IO. + + h_5v-supply: + description: + The input supply for HDMI_SWITCH. + + usb-supply: + description: + The input supply for OTG_SWITCH. + + regulators: + type: object + patternProperties: + "^(DCDC_REG[1-4]|DCDC_BOOST|LDO_REG[1-9]|SWITCH_REG|HDMI_SWITCH|OTG_SWITCH)$": + type: object + $ref: ../regulator/regulator.yaml# + unevaluatedProperties: false + +required: + - compatible + - reg + - interrupts + - "#clock-cells" + +additionalProperties: false + +examples: + - | + #include <dt-bindings/clock/px30-cru.h> + #include <dt-bindings/pinctrl/rockchip.h> + #include <dt-bindings/interrupt-controller/irq.h> + #include <dt-bindings/gpio/gpio.h> + i2c { + #address-cells = <1>; + #size-cells = <0>; + + rk818: pmic@1c { + compatible = "rockchip,rk818"; + reg = <0x1c>; + interrupt-parent = <&gpio0>; + interrupts = <4 IRQ_TYPE_LEVEL_LOW>; + pinctrl-names = "default"; + pinctrl-0 = <&pmic_int>; + rockchip,system-power-controller; + wakeup-source; + #clock-cells = <1>; + + vcc1-supply = <&vdd_sys>; + vcc2-supply = <&vdd_sys>; + vcc3-supply = <&vdd_sys>; + vcc4-supply = <&vdd_sys>; + boost-supply = <&vdd_in_otg_out>; + vcc6-supply = <&vdd_sys>; + vcc7-supply = <&vdd_misc_1v8>; + vcc8-supply = <&vdd_misc_1v8>; + vcc9-supply = <&vdd_3v3_io>; + vddio-supply = <&vdd_3v3_io>; + + regulators { + vdd_log: DCDC_REG1 { + regulator-name = "vdd_log"; + regulator-always-on; + regulator-boot-on; + regulator-min-microvolt = <1100000>; + regulator-max-microvolt = <1100000>; + regulator-state-mem { + regulator-off-in-suspend; + }; + }; + + vdd_gpu: DCDC_REG2 { + regulator-name = "vdd_gpu"; + regulator-always-on; + regulator-boot-on; + regulator-min-microvolt = <800000>; + regulator-max-microvolt = <1250000>; + regulator-state-mem { + regulator-on-in-suspend; + regulator-suspend-microvolt = <1000000>; + }; + }; + + vcc_ddr: DCDC_REG3 { + regulator-name = "vcc_ddr"; + regulator-always-on; + regulator-boot-on; + regulator-state-mem { + regulator-on-in-suspend; + }; + }; + + vdd_3v3_io: DCDC_REG4 { + regulator-name = "vdd_3v3_io"; + regulator-always-on; + regulator-boot-on; + regulator-min-microvolt = <3300000>; + regulator-max-microvolt = <3300000>; + regulator-state-mem { + regulator-on-in-suspend; + regulator-suspend-microvolt = <3300000>; + }; + }; + + vdd_sys: DCDC_BOOST { + regulator-name = "vdd_sys"; + regulator-always-on; + regulator-boot-on; + regulator-min-microvolt = <5000000>; + regulator-max-microvolt = <5000000>; + regulator-state-mem { + regulator-on-in-suspend; + regulator-suspend-microvolt = <5000000>; + }; + }; + + vdd_sd: SWITCH_REG { + regulator-name = "vdd_sd"; + regulator-always-on; + regulator-boot-on; + regulator-state-mem { + regulator-off-in-suspend; + }; + }; + + vdd_eth_2v5: LDO_REG2 { + regulator-name = "vdd_eth_2v5"; + regulator-always-on; + regulator-boot-on; + regulator-min-microvolt = <2500000>; + regulator-max-microvolt = <2500000>; + regulator-state-mem { + regulator-on-in-suspend; + regulator-suspend-microvolt = <2500000>; + }; + }; + + vdd_1v0: LDO_REG3 { + regulator-name = "vdd_1v0"; + regulator-always-on; + regulator-boot-on; + regulator-min-microvolt = <1000000>; + regulator-max-microvolt = <1000000>; + regulator-state-mem { + regulator-on-in-suspend; + regulator-suspend-microvolt = <1000000>; + }; + }; + + vdd_1v8_lcd_ldo: LDO_REG4 { + regulator-name = "vdd_1v8_lcd_ldo"; + regulator-always-on; + regulator-boot-on; + regulator-min-microvolt = <1800000>; + regulator-max-microvolt = <1800000>; + regulator-state-mem { + regulator-on-in-suspend; + regulator-suspend-microvolt = <1800000>; + }; + }; + + vdd_1v0_lcd: LDO_REG6 { + regulator-name = "vdd_1v0_lcd"; + regulator-always-on; + regulator-boot-on; + regulator-min-microvolt = <1000000>; + regulator-max-microvolt = <1000000>; + regulator-state-mem { + regulator-on-in-suspend; + regulator-suspend-microvolt = <1000000>; + }; + }; + + vdd_1v8_ldo: LDO_REG7 { + regulator-name = "vdd_1v8_ldo"; + regulator-always-on; + regulator-boot-on; + regulator-min-microvolt = <1800000>; + regulator-max-microvolt = <1800000>; + regulator-state-mem { + regulator-off-in-suspend; + regulator-suspend-microvolt = <1800000>; + }; + }; + + vdd_io_sd: LDO_REG9 { + regulator-name = "vdd_io_sd"; + regulator-always-on; + regulator-boot-on; + regulator-min-microvolt = <1800000>; + regulator-max-microvolt = <3300000>; + regulator-state-mem { + regulator-off-in-suspend; + }; + }; + }; + }; + }; diff --git a/Documentation/devicetree/bindings/mfd/samsung,exynos5433-lpass.yaml b/Documentation/devicetree/bindings/mfd/samsung,exynos5433-lpass.yaml index f7bb67d10eff..b97b06848729 100644 --- a/Documentation/devicetree/bindings/mfd/samsung,exynos5433-lpass.yaml +++ b/Documentation/devicetree/bindings/mfd/samsung,exynos5433-lpass.yaml @@ -79,8 +79,8 @@ examples: clocks = <&cmu_aud CLK_ACLK_DMAC>; clock-names = "apb_pclk"; #dma-cells = <1>; - #dma-channels = <8>; - #dma-requests = <32>; + dma-channels = <8>; + dma-requests = <32>; power-domains = <&pd_aud>; }; diff --git a/Documentation/devicetree/bindings/mfd/syscon.yaml b/Documentation/devicetree/bindings/mfd/syscon.yaml index 13baa452cc9d..fb784045013f 100644 --- a/Documentation/devicetree/bindings/mfd/syscon.yaml +++ b/Documentation/devicetree/bindings/mfd/syscon.yaml @@ -100,12 +100,4 @@ examples: compatible = "allwinner,sun8i-h3-system-controller", "syscon"; reg = <0x01c00000 0x1000>; }; - - - | - gpr: iomuxc-gpr@20e0000 { - compatible = "fsl,imx6q-iomuxc-gpr", "syscon"; - reg = <0x020e0000 0x38>; - hwlocks = <&hwlock1 1>; - }; - ... diff --git a/Documentation/devicetree/bindings/mfd/wlf,arizona.yaml b/Documentation/devicetree/bindings/mfd/wlf,arizona.yaml index 9e762d474218..ea3337dafaf5 100644 --- a/Documentation/devicetree/bindings/mfd/wlf,arizona.yaml +++ b/Documentation/devicetree/bindings/mfd/wlf,arizona.yaml @@ -14,6 +14,7 @@ description: | range of analogue I/O. allOf: + - $ref: /schemas/spi/spi-peripheral-props.yaml - $ref: /schemas/sound/wlf,arizona.yaml# - $ref: /schemas/regulator/wlf,arizona.yaml# - $ref: /schemas/extcon/wlf,arizona.yaml# diff --git a/Documentation/devicetree/bindings/mux/reg-mux.yaml b/Documentation/devicetree/bindings/mux/reg-mux.yaml index 3b030b8fb47c..dfd9ea582bb7 100644 --- a/Documentation/devicetree/bindings/mux/reg-mux.yaml +++ b/Documentation/devicetree/bindings/mux/reg-mux.yaml @@ -100,7 +100,6 @@ examples: #include <dt-bindings/mux/mux.h> syscon@1000 { - compatible = "fsl,imx7d-iomuxc-gpr", "fsl,imx6q-iomuxc-gpr", "syscon", "simple-mfd"; reg = <0x1000 0x100>; mux2: mux-controller { diff --git a/Documentation/devicetree/bindings/net/adi,adin.yaml b/Documentation/devicetree/bindings/net/adi,adin.yaml index 77750df0c2c4..929cf8c0b0fd 100644 --- a/Documentation/devicetree/bindings/net/adi,adin.yaml +++ b/Documentation/devicetree/bindings/net/adi,adin.yaml @@ -7,7 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml# title: Analog Devices ADIN1200/ADIN1300 PHY maintainers: - - Alexandru Ardelean <alexandru.ardelean@analog.com> + - Alexandru Tachici <alexandru.tachici@analog.com> description: | Bindings for Analog Devices Industrial Ethernet PHYs @@ -37,7 +37,8 @@ properties: default: 8 adi,phy-output-clock: - description: Select clock output on GP_CLK pin. Two clocks are available: + description: | + Select clock output on GP_CLK pin. Two clocks are available: A 25MHz reference and a free-running 125MHz. The phy can alternatively automatically switch between the reference and the 125MHz clocks based on its internal state. diff --git a/Documentation/devicetree/bindings/opp/opp-v2-kryo-cpu.yaml b/Documentation/devicetree/bindings/opp/opp-v2-kryo-cpu.yaml index 8c2e9ac5f68d..30f7b596d609 100644 --- a/Documentation/devicetree/bindings/opp/opp-v2-kryo-cpu.yaml +++ b/Documentation/devicetree/bindings/opp/opp-v2-kryo-cpu.yaml @@ -17,10 +17,10 @@ description: | the CPU frequencies subset and voltage value of each OPP varies based on the silicon variant in use. Qualcomm Technologies, Inc. Process Voltage Scaling Tables - defines the voltage and frequency value based on the msm-id in SMEM - and speedbin blown in the efuse combination. - The qcom-cpufreq-nvmem driver reads the msm-id and efuse value from the SoC - to provide the OPP framework with required information (existing HW bitmap). + defines the voltage and frequency value based on the speedbin blown in + the efuse combination. + The qcom-cpufreq-nvmem driver reads the efuse value from the SoC to provide + the OPP framework with required information (existing HW bitmap). This is used to determine the voltage and frequency value for each OPP of operating-points-v2 table when it is parsed by the OPP framework. @@ -50,15 +50,11 @@ patternProperties: description: | A single 32 bit bitmap value, representing compatible HW. Bitmap: - 0: MSM8996 V3, speedbin 0 - 1: MSM8996 V3, speedbin 1 - 2: MSM8996 V3, speedbin 2 - 3: unused - 4: MSM8996 SG, speedbin 0 - 5: MSM8996 SG, speedbin 1 - 6: MSM8996 SG, speedbin 2 - 7-31: unused - maximum: 0x77 + 0: MSM8996, speedbin 0 + 1: MSM8996, speedbin 1 + 2: MSM8996, speedbin 2 + 3-31: unused + maximum: 0x7 clock-latency-ns: true @@ -184,19 +180,19 @@ examples: opp-307200000 { opp-hz = /bits/ 64 <307200000>; opp-microvolt = <905000 905000 1140000>; - opp-supported-hw = <0x77>; + opp-supported-hw = <0x7>; clock-latency-ns = <200000>; }; - opp-1593600000 { - opp-hz = /bits/ 64 <1593600000>; + opp-1401600000 { + opp-hz = /bits/ 64 <1401600000>; opp-microvolt = <1140000 905000 1140000>; - opp-supported-hw = <0x71>; + opp-supported-hw = <0x5>; clock-latency-ns = <200000>; }; - opp-2188800000 { - opp-hz = /bits/ 64 <2188800000>; + opp-1593600000 { + opp-hz = /bits/ 64 <1593600000>; opp-microvolt = <1140000 905000 1140000>; - opp-supported-hw = <0x10>; + opp-supported-hw = <0x1>; clock-latency-ns = <200000>; }; }; @@ -209,25 +205,25 @@ examples: opp-307200000 { opp-hz = /bits/ 64 <307200000>; opp-microvolt = <905000 905000 1140000>; - opp-supported-hw = <0x77>; + opp-supported-hw = <0x7>; clock-latency-ns = <200000>; }; - opp-1593600000 { - opp-hz = /bits/ 64 <1593600000>; + opp-1804800000 { + opp-hz = /bits/ 64 <1804800000>; opp-microvolt = <1140000 905000 1140000>; - opp-supported-hw = <0x70>; + opp-supported-hw = <0x6>; clock-latency-ns = <200000>; }; - opp-2150400000 { - opp-hz = /bits/ 64 <2150400000>; + opp-1900800000 { + opp-hz = /bits/ 64 <1900800000>; opp-microvolt = <1140000 905000 1140000>; - opp-supported-hw = <0x31>; + opp-supported-hw = <0x4>; clock-latency-ns = <200000>; }; - opp-2342400000 { - opp-hz = /bits/ 64 <2342400000>; + opp-2150400000 { + opp-hz = /bits/ 64 <2150400000>; opp-microvolt = <1140000 905000 1140000>; - opp-supported-hw = <0x10>; + opp-supported-hw = <0x1>; clock-latency-ns = <200000>; }; }; diff --git a/Documentation/devicetree/bindings/pci/layerscape-pci.txt b/Documentation/devicetree/bindings/pci/layerscape-pci.txt index f36efa73a470..ee8a4791a78b 100644 --- a/Documentation/devicetree/bindings/pci/layerscape-pci.txt +++ b/Documentation/devicetree/bindings/pci/layerscape-pci.txt @@ -23,6 +23,7 @@ Required properties: "fsl,ls1012a-pcie" "fsl,ls1028a-pcie" EP mode: + "fsl,ls1028a-pcie-ep", "fsl,ls-pcie-ep" "fsl,ls1046a-pcie-ep", "fsl,ls-pcie-ep" "fsl,ls1088a-pcie-ep", "fsl,ls-pcie-ep" "fsl,ls2088a-pcie-ep", "fsl,ls-pcie-ep" @@ -30,39 +31,49 @@ Required properties: - reg: base addresses and lengths of the PCIe controller register blocks. - interrupts: A list of interrupt outputs of the controller. Must contain an entry for each entry in the interrupt-names property. -- interrupt-names: Must include the following entries: - "intr": The interrupt that is asserted for controller interrupts +- interrupt-names: It could include the following entries: + "aer": Used for interrupt line which reports AER events when + non MSI/MSI-X/INTx mode is used + "pme": Used for interrupt line which reports PME events when + non MSI/MSI-X/INTx mode is used + "intr": Used for SoCs(like ls2080a, lx2160a, ls2080a, ls2088a, ls1088a) + which has a single interrupt line for miscellaneous controller + events(could include AER and PME events). - fsl,pcie-scfg: Must include two entries. The first entry must be a link to the SCFG device node - The second entry must be '0' or '1' based on physical PCIe controller index. + The second entry is the physical PCIe controller index starting from '0'. This is used to get SCFG PEXN registers - dma-coherent: Indicates that the hardware IP block can ensure the coherency of the data transferred from/to the IP block. This can avoid the software cache flush/invalid actions, and improve the performance significantly. +Optional properties: +- big-endian: If the PEX_LUT and PF register block is in big-endian, specify + this property. + Example: - pcie@3400000 { - compatible = "fsl,ls1021a-pcie"; - reg = <0x00 0x03400000 0x0 0x00010000 /* controller registers */ - 0x40 0x00000000 0x0 0x00002000>; /* configuration space */ - reg-names = "regs", "config"; - interrupts = <GIC_SPI 177 IRQ_TYPE_LEVEL_HIGH>; /* controller interrupt */ - interrupt-names = "intr"; - fsl,pcie-scfg = <&scfg 0>; - #address-cells = <3>; - #size-cells = <2>; - device_type = "pci"; - dma-coherent; - num-lanes = <4>; - bus-range = <0x0 0xff>; - ranges = <0x81000000 0x0 0x00000000 0x40 0x00010000 0x0 0x00010000 /* downstream I/O */ - 0xc2000000 0x0 0x20000000 0x40 0x20000000 0x0 0x20000000 /* prefetchable memory */ - 0x82000000 0x0 0x40000000 0x40 0x40000000 0x0 0x40000000>; /* non-prefetchable memory */ - #interrupt-cells = <1>; - interrupt-map-mask = <0 0 0 7>; - interrupt-map = <0000 0 0 1 &gic GIC_SPI 91 IRQ_TYPE_LEVEL_HIGH>, - <0000 0 0 2 &gic GIC_SPI 188 IRQ_TYPE_LEVEL_HIGH>, - <0000 0 0 3 &gic GIC_SPI 190 IRQ_TYPE_LEVEL_HIGH>, - <0000 0 0 4 &gic GIC_SPI 192 IRQ_TYPE_LEVEL_HIGH>; - }; + pcie@3400000 { + compatible = "fsl,ls1088a-pcie"; + reg = <0x00 0x03400000 0x0 0x00100000>, /* controller registers */ + <0x20 0x00000000 0x0 0x00002000>; /* configuration space */ + reg-names = "regs", "config"; + interrupts = <0 108 IRQ_TYPE_LEVEL_HIGH>; /* aer interrupt */ + interrupt-names = "aer"; + #address-cells = <3>; + #size-cells = <2>; + device_type = "pci"; + dma-coherent; + num-viewport = <256>; + bus-range = <0x0 0xff>; + ranges = <0x81000000 0x0 0x00000000 0x20 0x00010000 0x0 0x00010000 /* downstream I/O */ + 0x82000000 0x0 0x40000000 0x20 0x40000000 0x0 0x40000000>; /* non-prefetchable memory */ + msi-parent = <&its>; + #interrupt-cells = <1>; + interrupt-map-mask = <0 0 0 7>; + interrupt-map = <0000 0 0 1 &gic 0 0 0 109 IRQ_TYPE_LEVEL_HIGH>, + <0000 0 0 2 &gic 0 0 0 110 IRQ_TYPE_LEVEL_HIGH>, + <0000 0 0 3 &gic 0 0 0 111 IRQ_TYPE_LEVEL_HIGH>, + <0000 0 0 4 &gic 0 0 0 112 IRQ_TYPE_LEVEL_HIGH>; + iommu-map = <0 &smmu 0 1>; /* Fixed-up by bootloader */ + }; diff --git a/Documentation/devicetree/bindings/pci/qcom,pcie.txt b/Documentation/devicetree/bindings/pci/qcom,pcie.txt deleted file mode 100644 index 0adb56d5645e..000000000000 --- a/Documentation/devicetree/bindings/pci/qcom,pcie.txt +++ /dev/null @@ -1,397 +0,0 @@ -* Qualcomm PCI express root complex - -- compatible: - Usage: required - Value type: <stringlist> - Definition: Value should contain - - "qcom,pcie-ipq8064" for ipq8064 - - "qcom,pcie-ipq8064-v2" for ipq8064 rev 2 or ipq8065 - - "qcom,pcie-apq8064" for apq8064 - - "qcom,pcie-apq8084" for apq8084 - - "qcom,pcie-msm8996" for msm8996 or apq8096 - - "qcom,pcie-ipq4019" for ipq4019 - - "qcom,pcie-ipq8074" for ipq8074 - - "qcom,pcie-qcs404" for qcs404 - - "qcom,pcie-sc8180x" for sc8180x - - "qcom,pcie-sdm845" for sdm845 - - "qcom,pcie-sm8250" for sm8250 - - "qcom,pcie-sm8450-pcie0" for PCIe0 on sm8450 - - "qcom,pcie-sm8450-pcie1" for PCIe1 on sm8450 - - "qcom,pcie-ipq6018" for ipq6018 - -- reg: - Usage: required - Value type: <prop-encoded-array> - Definition: Register ranges as listed in the reg-names property - -- reg-names: - Usage: required - Value type: <stringlist> - Definition: Must include the following entries - - "parf" Qualcomm specific registers - - "dbi" DesignWare PCIe registers - - "elbi" External local bus interface registers - - "config" PCIe configuration space - - "atu" ATU address space (optional) - -- device_type: - Usage: required - Value type: <string> - Definition: Should be "pci". As specified in snps,dw-pcie.yaml - -- #address-cells: - Usage: required - Value type: <u32> - Definition: Should be 3. As specified in snps,dw-pcie.yaml - -- #size-cells: - Usage: required - Value type: <u32> - Definition: Should be 2. As specified in snps,dw-pcie.yaml - -- ranges: - Usage: required - Value type: <prop-encoded-array> - Definition: As specified in snps,dw-pcie.yaml - -- interrupts: - Usage: required - Value type: <prop-encoded-array> - Definition: MSI interrupt - -- interrupt-names: - Usage: required - Value type: <stringlist> - Definition: Should contain "msi" - -- #interrupt-cells: - Usage: required - Value type: <u32> - Definition: Should be 1. As specified in snps,dw-pcie.yaml - -- interrupt-map-mask: - Usage: required - Value type: <prop-encoded-array> - Definition: As specified in snps,dw-pcie.yaml - -- interrupt-map: - Usage: required - Value type: <prop-encoded-array> - Definition: As specified in snps,dw-pcie.yaml - -- clocks: - Usage: required - Value type: <prop-encoded-array> - Definition: List of phandle and clock specifier pairs as listed - in clock-names property - -- clock-names: - Usage: required - Value type: <stringlist> - Definition: Should contain the following entries - - "iface" Configuration AHB clock - -- clock-names: - Usage: required for ipq/apq8064 - Value type: <stringlist> - Definition: Should contain the following entries - - "core" Clocks the pcie hw block - - "phy" Clocks the pcie PHY block - - "aux" Clocks the pcie AUX block - - "ref" Clocks the pcie ref block -- clock-names: - Usage: required for apq8084/ipq4019 - Value type: <stringlist> - Definition: Should contain the following entries - - "aux" Auxiliary (AUX) clock - - "bus_master" Master AXI clock - - "bus_slave" Slave AXI clock - -- clock-names: - Usage: required for msm8996/apq8096 - Value type: <stringlist> - Definition: Should contain the following entries - - "pipe" Pipe Clock driving internal logic - - "aux" Auxiliary (AUX) clock - - "cfg" Configuration clock - - "bus_master" Master AXI clock - - "bus_slave" Slave AXI clock - -- clock-names: - Usage: required for ipq8074 - Value type: <stringlist> - Definition: Should contain the following entries - - "iface" PCIe to SysNOC BIU clock - - "axi_m" AXI Master clock - - "axi_s" AXI Slave clock - - "ahb" AHB clock - - "aux" Auxiliary clock - -- clock-names: - Usage: required for ipq6018 - Value type: <stringlist> - Definition: Should contain the following entries - - "iface" PCIe to SysNOC BIU clock - - "axi_m" AXI Master clock - - "axi_s" AXI Slave clock - - "axi_bridge" AXI bridge clock - - "rchng" - -- clock-names: - Usage: required for qcs404 - Value type: <stringlist> - Definition: Should contain the following entries - - "iface" AHB clock - - "aux" Auxiliary clock - - "master_bus" AXI Master clock - - "slave_bus" AXI Slave clock - -- clock-names: - Usage: required for sdm845 - Value type: <stringlist> - Definition: Should contain the following entries - - "aux" Auxiliary clock - - "cfg" Configuration clock - - "bus_master" Master AXI clock - - "bus_slave" Slave AXI clock - - "slave_q2a" Slave Q2A clock - - "tbu" PCIe TBU clock - - "pipe" PIPE clock - -- clock-names: - Usage: required for sc8180x and sm8250 - Value type: <stringlist> - Definition: Should contain the following entries - - "aux" Auxiliary clock - - "cfg" Configuration clock - - "bus_master" Master AXI clock - - "bus_slave" Slave AXI clock - - "slave_q2a" Slave Q2A clock - - "tbu" PCIe TBU clock - - "ddrss_sf_tbu" PCIe SF TBU clock - - "pipe" PIPE clock - -- clock-names: - Usage: required for sm8450-pcie0 and sm8450-pcie1 - Value type: <stringlist> - Definition: Should contain the following entries - - "aux" Auxiliary clock - - "cfg" Configuration clock - - "bus_master" Master AXI clock - - "bus_slave" Slave AXI clock - - "slave_q2a" Slave Q2A clock - - "tbu" PCIe TBU clock - - "ddrss_sf_tbu" PCIe SF TBU clock - - "pipe" PIPE clock - - "pipe_mux" PIPE MUX - - "phy_pipe" PIPE output clock - - "ref" REFERENCE clock - - "aggre0" Aggre NoC PCIe0 AXI clock, only for sm8450-pcie0 - - "aggre1" Aggre NoC PCIe1 AXI clock - -- resets: - Usage: required - Value type: <prop-encoded-array> - Definition: List of phandle and reset specifier pairs as listed - in reset-names property - -- reset-names: - Usage: required for ipq/apq8064 - Value type: <stringlist> - Definition: Should contain the following entries - - "axi" AXI reset - - "ahb" AHB reset - - "por" POR reset - - "pci" PCI reset - - "phy" PHY reset - -- reset-names: - Usage: required for apq8084 - Value type: <stringlist> - Definition: Should contain the following entries - - "core" Core reset - -- reset-names: - Usage: required for ipq/apq8064 - Value type: <stringlist> - Definition: Should contain the following entries - - "axi_m" AXI master reset - - "axi_s" AXI slave reset - - "pipe" PIPE reset - - "axi_m_vmid" VMID reset - - "axi_s_xpu" XPU reset - - "parf" PARF reset - - "phy" PHY reset - - "axi_m_sticky" AXI sticky reset - - "pipe_sticky" PIPE sticky reset - - "pwr" PWR reset - - "ahb" AHB reset - - "phy_ahb" PHY AHB reset - - "ext" EXT reset - -- reset-names: - Usage: required for ipq8074 - Value type: <stringlist> - Definition: Should contain the following entries - - "pipe" PIPE reset - - "sleep" Sleep reset - - "sticky" Core Sticky reset - - "axi_m" AXI Master reset - - "axi_s" AXI Slave reset - - "ahb" AHB Reset - - "axi_m_sticky" AXI Master Sticky reset - -- reset-names: - Usage: required for ipq6018 - Value type: <stringlist> - Definition: Should contain the following entries - - "pipe" PIPE reset - - "sleep" Sleep reset - - "sticky" Core Sticky reset - - "axi_m" AXI Master reset - - "axi_s" AXI Slave reset - - "ahb" AHB Reset - - "axi_m_sticky" AXI Master Sticky reset - - "axi_s_sticky" AXI Slave Sticky reset - -- reset-names: - Usage: required for qcs404 - Value type: <stringlist> - Definition: Should contain the following entries - - "axi_m" AXI Master reset - - "axi_s" AXI Slave reset - - "axi_m_sticky" AXI Master Sticky reset - - "pipe_sticky" PIPE sticky reset - - "pwr" PWR reset - - "ahb" AHB reset - -- reset-names: - Usage: required for sc8180x, sdm845, sm8250 and sm8450 - Value type: <stringlist> - Definition: Should contain the following entries - - "pci" PCIe core reset - -- power-domains: - Usage: required for apq8084 and msm8996/apq8096 - Value type: <prop-encoded-array> - Definition: A phandle and power domain specifier pair to the - power domain which is responsible for collapsing - and restoring power to the peripheral - -- vdda-supply: - Usage: required - Value type: <phandle> - Definition: A phandle to the core analog power supply - -- vdda_phy-supply: - Usage: required for ipq/apq8064 - Value type: <phandle> - Definition: A phandle to the analog power supply for PHY - -- vdda_refclk-supply: - Usage: required for ipq/apq8064 - Value type: <phandle> - Definition: A phandle to the analog power supply for IC which generates - reference clock -- vddpe-3v3-supply: - Usage: optional - Value type: <phandle> - Definition: A phandle to the PCIe endpoint power supply - -- phys: - Usage: required for apq8084 and qcs404 - Value type: <phandle> - Definition: List of phandle(s) as listed in phy-names property - -- phy-names: - Usage: required for apq8084 and qcs404 - Value type: <stringlist> - Definition: Should contain "pciephy" - -- <name>-gpios: - Usage: optional - Value type: <prop-encoded-array> - Definition: List of phandle and GPIO specifier pairs. Should contain - - "perst-gpios" PCIe endpoint reset signal line - - "wake-gpios" PCIe endpoint wake signal line - -* Example for ipq/apq8064 - pcie@1b500000 { - compatible = "qcom,pcie-apq8064", "qcom,pcie-ipq8064", "snps,dw-pcie"; - reg = <0x1b500000 0x1000 - 0x1b502000 0x80 - 0x1b600000 0x100 - 0x0ff00000 0x100000>; - reg-names = "dbi", "elbi", "parf", "config"; - device_type = "pci"; - linux,pci-domain = <0>; - bus-range = <0x00 0xff>; - num-lanes = <1>; - #address-cells = <3>; - #size-cells = <2>; - ranges = <0x81000000 0 0 0x0fe00000 0 0x00100000 /* I/O */ - 0x82000000 0 0 0x08000000 0 0x07e00000>; /* memory */ - interrupts = <GIC_SPI 238 IRQ_TYPE_NONE>; - interrupt-names = "msi"; - #interrupt-cells = <1>; - interrupt-map-mask = <0 0 0 0x7>; - interrupt-map = <0 0 0 1 &intc 0 36 IRQ_TYPE_LEVEL_HIGH>, /* int_a */ - <0 0 0 2 &intc 0 37 IRQ_TYPE_LEVEL_HIGH>, /* int_b */ - <0 0 0 3 &intc 0 38 IRQ_TYPE_LEVEL_HIGH>, /* int_c */ - <0 0 0 4 &intc 0 39 IRQ_TYPE_LEVEL_HIGH>; /* int_d */ - clocks = <&gcc PCIE_A_CLK>, - <&gcc PCIE_H_CLK>, - <&gcc PCIE_PHY_CLK>, - <&gcc PCIE_AUX_CLK>, - <&gcc PCIE_ALT_REF_CLK>; - clock-names = "core", "iface", "phy", "aux", "ref"; - resets = <&gcc PCIE_ACLK_RESET>, - <&gcc PCIE_HCLK_RESET>, - <&gcc PCIE_POR_RESET>, - <&gcc PCIE_PCI_RESET>, - <&gcc PCIE_PHY_RESET>, - <&gcc PCIE_EXT_RESET>; - reset-names = "axi", "ahb", "por", "pci", "phy", "ext"; - pinctrl-0 = <&pcie_pins_default>; - pinctrl-names = "default"; - }; - -* Example for apq8084 - pcie0@fc520000 { - compatible = "qcom,pcie-apq8084", "snps,dw-pcie"; - reg = <0xfc520000 0x2000>, - <0xff000000 0x1000>, - <0xff001000 0x1000>, - <0xff002000 0x2000>; - reg-names = "parf", "dbi", "elbi", "config"; - device_type = "pci"; - linux,pci-domain = <0>; - bus-range = <0x00 0xff>; - num-lanes = <1>; - #address-cells = <3>; - #size-cells = <2>; - ranges = <0x81000000 0 0 0xff200000 0 0x00100000 /* I/O */ - 0x82000000 0 0x00300000 0xff300000 0 0x00d00000>; /* memory */ - interrupts = <GIC_SPI 243 IRQ_TYPE_NONE>; - interrupt-names = "msi"; - #interrupt-cells = <1>; - interrupt-map-mask = <0 0 0 0x7>; - interrupt-map = <0 0 0 1 &intc 0 244 IRQ_TYPE_LEVEL_HIGH>, /* int_a */ - <0 0 0 2 &intc 0 245 IRQ_TYPE_LEVEL_HIGH>, /* int_b */ - <0 0 0 3 &intc 0 247 IRQ_TYPE_LEVEL_HIGH>, /* int_c */ - <0 0 0 4 &intc 0 248 IRQ_TYPE_LEVEL_HIGH>; /* int_d */ - clocks = <&gcc GCC_PCIE_0_CFG_AHB_CLK>, - <&gcc GCC_PCIE_0_MSTR_AXI_CLK>, - <&gcc GCC_PCIE_0_SLV_AXI_CLK>, - <&gcc GCC_PCIE_0_AUX_CLK>; - clock-names = "iface", "master_bus", "slave_bus", "aux"; - resets = <&gcc GCC_PCIE_0_BCR>; - reset-names = "core"; - power-domains = <&gcc PCIE0_GDSC>; - vdda-supply = <&pma8084_l3>; - phys = <&pciephy0>; - phy-names = "pciephy"; - perst-gpio = <&tlmm 70 GPIO_ACTIVE_LOW>; - pinctrl-0 = <&pcie0_pins_default>; - pinctrl-names = "default"; - }; diff --git a/Documentation/devicetree/bindings/pci/qcom,pcie.yaml b/Documentation/devicetree/bindings/pci/qcom,pcie.yaml new file mode 100644 index 000000000000..0b69b12b849e --- /dev/null +++ b/Documentation/devicetree/bindings/pci/qcom,pcie.yaml @@ -0,0 +1,714 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/pci/qcom,pcie.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Qualcomm PCI express root complex + +maintainers: + - Bjorn Andersson <bjorn.andersson@linaro.org> + - Stanimir Varbanov <svarbanov@mm-sol.com> + +description: | + Qualcomm PCIe root complex controller is bansed on the Synopsys DesignWare + PCIe IP. + +properties: + compatible: + enum: + - qcom,pcie-ipq8064 + - qcom,pcie-ipq8064-v2 + - qcom,pcie-apq8064 + - qcom,pcie-apq8084 + - qcom,pcie-msm8996 + - qcom,pcie-ipq4019 + - qcom,pcie-ipq8074 + - qcom,pcie-qcs404 + - qcom,pcie-sc7280 + - qcom,pcie-sc8180x + - qcom,pcie-sdm845 + - qcom,pcie-sm8150 + - qcom,pcie-sm8250 + - qcom,pcie-sm8450-pcie0 + - qcom,pcie-sm8450-pcie1 + - qcom,pcie-ipq6018 + + reg: + minItems: 4 + maxItems: 5 + + reg-names: + minItems: 4 + maxItems: 5 + + interrupts: + maxItems: 1 + + interrupt-names: + items: + - const: msi + + # Common definitions for clocks, clock-names and reset. + # Platform constraints are described later. + clocks: + minItems: 3 + maxItems: 12 + + clock-names: + minItems: 3 + maxItems: 12 + + resets: + minItems: 1 + maxItems: 12 + + resets-names: + minItems: 1 + maxItems: 12 + + vdda-supply: + description: A phandle to the core analog power supply + + vdda_phy-supply: + description: A phandle to the core analog power supply for PHY + + vdda_refclk-supply: + description: A phandle to the core analog power supply for IC which generates reference clock + + vddpe-3v3-supply: + description: A phandle to the PCIe endpoint power supply + + phys: + maxItems: 1 + + phy-names: + items: + - const: pciephy + + power-domains: + maxItems: 1 + + perst-gpios: + description: GPIO controlled connection to PERST# signal + maxItems: 1 + + wake-gpios: + description: GPIO controlled connection to WAKE# signal + maxItems: 1 + +required: + - compatible + - reg + - reg-names + - interrupts + - interrupt-names + - "#interrupt-cells" + - interrupt-map-mask + - interrupt-map + - clocks + - clock-names + +allOf: + - $ref: /schemas/pci/pci-bus.yaml# + - if: + properties: + compatible: + contains: + enum: + - qcom,pcie-apq8064 + - qcom,pcie-ipq4019 + - qcom,pcie-ipq8064 + - qcom,pcie-ipq8064v2 + - qcom,pcie-ipq8074 + - qcom,pcie-qcs404 + then: + properties: + reg: + minItems: 4 + maxItems: 4 + reg-names: + items: + - const: dbi # DesignWare PCIe registers + - const: elbi # External local bus interface registers + - const: parf # Qualcomm specific registers + - const: config # PCIe configuration space + + - if: + properties: + compatible: + contains: + enum: + - qcom,pcie-ipq6018 + then: + properties: + reg: + minItems: 5 + maxItems: 5 + reg-names: + items: + - const: dbi # DesignWare PCIe registers + - const: elbi # External local bus interface registers + - const: atu # ATU address space + - const: parf # Qualcomm specific registers + - const: config # PCIe configuration space + + - if: + properties: + compatible: + contains: + enum: + - qcom,pcie-apq8084 + - qcom,pcie-msm8996 + - qcom,pcie-sdm845 + then: + properties: + reg: + minItems: 4 + maxItems: 4 + reg-names: + items: + - const: parf # Qualcomm specific registers + - const: dbi # DesignWare PCIe registers + - const: elbi # External local bus interface registers + - const: config # PCIe configuration space + + - if: + properties: + compatible: + contains: + enum: + - qcom,pcie-sc7280 + - qcom,pcie-sc8180x + - qcom,pcie-sm8250 + - qcom,pcie-sm8450-pcie0 + - qcom,pcie-sm8450-pcie1 + then: + properties: + reg: + minItems: 5 + maxItems: 5 + reg-names: + items: + - const: parf # Qualcomm specific registers + - const: dbi # DesignWare PCIe registers + - const: elbi # External local bus interface registers + - const: atu # ATU address space + - const: config # PCIe configuration space + + - if: + properties: + compatible: + contains: + enum: + - qcom,pcie-apq8064 + - qcom,pcie-ipq8064 + - qcom,pcie-ipq8064v2 + then: + properties: + clocks: + minItems: 3 + maxItems: 5 + clock-names: + minItems: 3 + items: + - const: core # Clocks the pcie hw block + - const: iface # Configuration AHB clock + - const: phy # Clocks the pcie PHY block + - const: aux # Clocks the pcie AUX block, not on apq8064 + - const: ref # Clocks the pcie ref block, not on apq8064 + resets: + minItems: 5 + maxItems: 6 + reset-names: + minItems: 5 + items: + - const: axi # AXI reset + - const: ahb # AHB reset + - const: por # POR reset + - const: pci # PCI reset + - const: phy # PHY reset + - const: ext # EXT reset, not on apq8064 + required: + - vdda-supply + - vdda_phy-supply + - vdda_refclk-supply + + - if: + properties: + compatible: + contains: + enum: + - qcom,pcie-apq8084 + then: + properties: + clocks: + minItems: 4 + maxItems: 4 + clock-names: + items: + - const: iface # Configuration AHB clock + - const: master_bus # Master AXI clock + - const: slave_bus # Slave AXI clock + - const: aux # Auxiliary (AUX) clock + resets: + maxItems: 1 + reset-names: + items: + - const: core # Core reset + + - if: + properties: + compatible: + contains: + enum: + - qcom,pcie-ipq4019 + then: + properties: + clocks: + minItems: 3 + maxItems: 3 + clock-names: + items: + - const: aux # Auxiliary (AUX) clock + - const: master_bus # Master AXI clock + - const: slave_bus # Slave AXI clock + resets: + minItems: 12 + maxItems: 12 + reset-names: + items: + - const: axi_m # AXI master reset + - const: axi_s # AXI slave reset + - const: pipe # PIPE reset + - const: axi_m_vmid # VMID reset + - const: axi_s_xpu # XPU reset + - const: parf # PARF reset + - const: phy # PHY reset + - const: axi_m_sticky # AXI sticky reset + - const: pipe_sticky # PIPE sticky reset + - const: pwr # PWR reset + - const: ahb # AHB reset + - const: phy_ahb # PHY AHB reset + + - if: + properties: + compatible: + contains: + enum: + - qcom,pcie-msm8996 + then: + oneOf: + - properties: + clock-names: + items: + - const: pipe # Pipe Clock driving internal logic + - const: aux # Auxiliary (AUX) clock + - const: cfg # Configuration clock + - const: bus_master # Master AXI clock + - const: bus_slave # Slave AXI clock + - properties: + clock-names: + items: + - const: pipe # Pipe Clock driving internal logic + - const: bus_master # Master AXI clock + - const: bus_slave # Slave AXI clock + - const: cfg # Configuration clock + - const: aux # Auxiliary (AUX) clock + properties: + clocks: + minItems: 5 + maxItems: 5 + resets: false + reset-names: false + + - if: + properties: + compatible: + contains: + enum: + - qcom,pcie-ipq8074 + then: + properties: + clocks: + minItems: 5 + maxItems: 5 + clock-names: + items: + - const: iface # PCIe to SysNOC BIU clock + - const: axi_m # AXI Master clock + - const: axi_s # AXI Slave clock + - const: ahb # AHB clock + - const: aux # Auxiliary clock + resets: + minItems: 7 + maxItems: 7 + reset-names: + items: + - const: pipe # PIPE reset + - const: sleep # Sleep reset + - const: sticky # Core Sticky reset + - const: axi_m # AXI Master reset + - const: axi_s # AXI Slave reset + - const: ahb # AHB Reset + - const: axi_m_sticky # AXI Master Sticky reset + + - if: + properties: + compatible: + contains: + enum: + - qcom,pcie-ipq6018 + then: + properties: + clocks: + minItems: 5 + maxItems: 5 + clock-names: + items: + - const: iface # PCIe to SysNOC BIU clock + - const: axi_m # AXI Master clock + - const: axi_s # AXI Slave clock + - const: axi_bridge # AXI bridge clock + - const: rchng + resets: + minItems: 8 + maxItems: 8 + reset-names: + items: + - const: pipe # PIPE reset + - const: sleep # Sleep reset + - const: sticky # Core Sticky reset + - const: axi_m # AXI Master reset + - const: axi_s # AXI Slave reset + - const: ahb # AHB Reset + - const: axi_m_sticky # AXI Master Sticky reset + - const: axi_s_sticky # AXI Slave Sticky reset + + - if: + properties: + compatible: + contains: + enum: + - qcom,pcie-qcs404 + then: + properties: + clocks: + minItems: 4 + maxItems: 4 + clock-names: + items: + - const: iface # AHB clock + - const: aux # Auxiliary clock + - const: master_bus # AXI Master clock + - const: slave_bus # AXI Slave clock + resets: + minItems: 6 + maxItems: 6 + reset-names: + items: + - const: axi_m # AXI Master reset + - const: axi_s # AXI Slave reset + - const: axi_m_sticky # AXI Master Sticky reset + - const: pipe_sticky # PIPE sticky reset + - const: pwr # PWR reset + - const: ahb # AHB reset + + - if: + properties: + compatible: + contains: + enum: + - qcom,pcie-sc7280 + then: + properties: + clocks: + minItems: 11 + maxItems: 11 + clock-names: + items: + - const: pipe # PIPE clock + - const: pipe_mux # PIPE MUX + - const: phy_pipe # PIPE output clock + - const: ref # REFERENCE clock + - const: aux # Auxiliary clock + - const: cfg # Configuration clock + - const: bus_master # Master AXI clock + - const: bus_slave # Slave AXI clock + - const: slave_q2a # Slave Q2A clock + - const: tbu # PCIe TBU clock + - const: ddrss_sf_tbu # PCIe SF TBU clock + resets: + maxItems: 1 + reset-names: + items: + - const: pci # PCIe core reset + + - if: + properties: + compatible: + contains: + enum: + - qcom,pcie-sdm845 + then: + oneOf: + # Unfortunately the "optional" ref clock is used in the middle of the list + - properties: + clocks: + minItems: 8 + maxItems: 8 + clock-names: + items: + - const: pipe # PIPE clock + - const: aux # Auxiliary clock + - const: cfg # Configuration clock + - const: bus_master # Master AXI clock + - const: bus_slave # Slave AXI clock + - const: slave_q2a # Slave Q2A clock + - const: ref # REFERENCE clock + - const: tbu # PCIe TBU clock + - properties: + clocks: + minItems: 7 + maxItems: 7 + clock-names: + items: + - const: pipe # PIPE clock + - const: aux # Auxiliary clock + - const: cfg # Configuration clock + - const: bus_master # Master AXI clock + - const: bus_slave # Slave AXI clock + - const: slave_q2a # Slave Q2A clock + - const: tbu # PCIe TBU clock + properties: + resets: + maxItems: 1 + reset-names: + items: + - const: pci # PCIe core reset + + - if: + properties: + compatible: + contains: + enum: + - qcom,pcie-sc8180x + - qcom,pcie-sm8150 + - qcom,pcie-sm8250 + then: + oneOf: + # Unfortunately the "optional" ref clock is used in the middle of the list + - properties: + clocks: + minItems: 9 + maxItems: 9 + clock-names: + items: + - const: pipe # PIPE clock + - const: aux # Auxiliary clock + - const: cfg # Configuration clock + - const: bus_master # Master AXI clock + - const: bus_slave # Slave AXI clock + - const: slave_q2a # Slave Q2A clock + - const: ref # REFERENCE clock + - const: tbu # PCIe TBU clock + - const: ddrss_sf_tbu # PCIe SF TBU clock + - properties: + clocks: + minItems: 8 + maxItems: 8 + clock-names: + items: + - const: pipe # PIPE clock + - const: aux # Auxiliary clock + - const: cfg # Configuration clock + - const: bus_master # Master AXI clock + - const: bus_slave # Slave AXI clock + - const: slave_q2a # Slave Q2A clock + - const: tbu # PCIe TBU clock + - const: ddrss_sf_tbu # PCIe SF TBU clock + properties: + resets: + maxItems: 1 + reset-names: + items: + - const: pci # PCIe core reset + + - if: + properties: + compatible: + contains: + enum: + - qcom,pcie-sm8450-pcie0 + then: + properties: + clocks: + minItems: 12 + maxItems: 12 + clock-names: + items: + - const: pipe # PIPE clock + - const: pipe_mux # PIPE MUX + - const: phy_pipe # PIPE output clock + - const: ref # REFERENCE clock + - const: aux # Auxiliary clock + - const: cfg # Configuration clock + - const: bus_master # Master AXI clock + - const: bus_slave # Slave AXI clock + - const: slave_q2a # Slave Q2A clock + - const: ddrss_sf_tbu # PCIe SF TBU clock + - const: aggre0 # Aggre NoC PCIe0 AXI clock + - const: aggre1 # Aggre NoC PCIe1 AXI clock + resets: + maxItems: 1 + reset-names: + items: + - const: pci # PCIe core reset + + - if: + properties: + compatible: + contains: + enum: + - qcom,pcie-sm8450-pcie1 + then: + properties: + clocks: + minItems: 11 + maxItems: 11 + clock-names: + items: + - const: pipe # PIPE clock + - const: pipe_mux # PIPE MUX + - const: phy_pipe # PIPE output clock + - const: ref # REFERENCE clock + - const: aux # Auxiliary clock + - const: cfg # Configuration clock + - const: bus_master # Master AXI clock + - const: bus_slave # Slave AXI clock + - const: slave_q2a # Slave Q2A clock + - const: ddrss_sf_tbu # PCIe SF TBU clock + - const: aggre1 # Aggre NoC PCIe1 AXI clock + resets: + maxItems: 1 + reset-names: + items: + - const: pci # PCIe core reset + + - if: + not: + properties: + compatible: + contains: + enum: + - qcom,pcie-apq8064 + - qcom,pcie-ipq4019 + - qcom,pcie-ipq8064 + - qcom,pcie-ipq8064v2 + - qcom,pcie-ipq8074 + - qcom,pcie-qcs404 + then: + required: + - power-domains + + - if: + not: + properties: + compatibles: + contains: + enum: + - qcom,pcie-msm8996 + then: + required: + - resets + - reset-names + +unevaluatedProperties: false + +examples: + - | + #include <dt-bindings/interrupt-controller/arm-gic.h> + pcie@1b500000 { + compatible = "qcom,pcie-ipq8064"; + reg = <0x1b500000 0x1000>, + <0x1b502000 0x80>, + <0x1b600000 0x100>, + <0x0ff00000 0x100000>; + reg-names = "dbi", "elbi", "parf", "config"; + device_type = "pci"; + linux,pci-domain = <0>; + bus-range = <0x00 0xff>; + num-lanes = <1>; + #address-cells = <3>; + #size-cells = <2>; + ranges = <0x81000000 0 0 0x0fe00000 0 0x00100000>, + <0x82000000 0 0 0x08000000 0 0x07e00000>; + interrupts = <GIC_SPI 238 IRQ_TYPE_LEVEL_HIGH>; + interrupt-names = "msi"; + #interrupt-cells = <1>; + interrupt-map-mask = <0 0 0 0x7>; + interrupt-map = <0 0 0 1 &intc 0 36 IRQ_TYPE_LEVEL_HIGH>, + <0 0 0 2 &intc 0 37 IRQ_TYPE_LEVEL_HIGH>, + <0 0 0 3 &intc 0 38 IRQ_TYPE_LEVEL_HIGH>, + <0 0 0 4 &intc 0 39 IRQ_TYPE_LEVEL_HIGH>; + clocks = <&gcc 41>, + <&gcc 43>, + <&gcc 44>, + <&gcc 42>, + <&gcc 248>; + clock-names = "core", "iface", "phy", "aux", "ref"; + resets = <&gcc 27>, + <&gcc 26>, + <&gcc 25>, + <&gcc 24>, + <&gcc 23>, + <&gcc 22>; + reset-names = "axi", "ahb", "por", "pci", "phy", "ext"; + pinctrl-0 = <&pcie_pins_default>; + pinctrl-names = "default"; + vdda-supply = <&pm8921_s3>; + vdda_phy-supply = <&pm8921_lvs6>; + vdda_refclk-supply = <&ext_3p3v>; + }; + - | + #include <dt-bindings/interrupt-controller/arm-gic.h> + #include <dt-bindings/gpio/gpio.h> + pcie@fc520000 { + compatible = "qcom,pcie-apq8084"; + reg = <0xfc520000 0x2000>, + <0xff000000 0x1000>, + <0xff001000 0x1000>, + <0xff002000 0x2000>; + reg-names = "parf", "dbi", "elbi", "config"; + device_type = "pci"; + linux,pci-domain = <0>; + bus-range = <0x00 0xff>; + num-lanes = <1>; + #address-cells = <3>; + #size-cells = <2>; + ranges = <0x81000000 0 0 0xff200000 0 0x00100000>, + <0x82000000 0 0x00300000 0xff300000 0 0x00d00000>; + interrupts = <GIC_SPI 243 IRQ_TYPE_LEVEL_HIGH>; + interrupt-names = "msi"; + #interrupt-cells = <1>; + interrupt-map-mask = <0 0 0 0x7>; + interrupt-map = <0 0 0 1 &intc 0 244 IRQ_TYPE_LEVEL_HIGH>, + <0 0 0 2 &intc 0 245 IRQ_TYPE_LEVEL_HIGH>, + <0 0 0 3 &intc 0 247 IRQ_TYPE_LEVEL_HIGH>, + <0 0 0 4 &intc 0 248 IRQ_TYPE_LEVEL_HIGH>; + clocks = <&gcc 324>, + <&gcc 325>, + <&gcc 327>, + <&gcc 323>; + clock-names = "iface", "master_bus", "slave_bus", "aux"; + resets = <&gcc 81>; + reset-names = "core"; + power-domains = <&gcc 1>; + vdda-supply = <&pma8084_l3>; + phys = <&pciephy0>; + phy-names = "pciephy"; + perst-gpios = <&tlmm 70 GPIO_ACTIVE_LOW>; + pinctrl-0 = <&pcie0_pins_default>; + pinctrl-names = "default"; + }; +... diff --git a/Documentation/devicetree/bindings/pci/rockchip-dw-pcie.yaml b/Documentation/devicetree/bindings/pci/rockchip-dw-pcie.yaml index 142bbe577763..bc0a9d1db750 100644 --- a/Documentation/devicetree/bindings/pci/rockchip-dw-pcie.yaml +++ b/Documentation/devicetree/bindings/pci/rockchip-dw-pcie.yaml @@ -19,20 +19,10 @@ description: |+ allOf: - $ref: /schemas/pci/pci-bus.yaml# -# We need a select here so we don't match all nodes with 'snps,dw-pcie' -select: - properties: - compatible: - contains: - const: rockchip,rk3568-pcie - required: - - compatible - properties: compatible: items: - const: rockchip,rk3568-pcie - - const: snps,dw-pcie reg: items: @@ -110,7 +100,7 @@ examples: #size-cells = <2>; pcie3x2: pcie@fe280000 { - compatible = "rockchip,rk3568-pcie", "snps,dw-pcie"; + compatible = "rockchip,rk3568-pcie"; reg = <0x3 0xc0800000 0x0 0x390000>, <0x0 0xfe280000 0x0 0x10000>, <0x3 0x80000000 0x0 0x100000>; diff --git a/Documentation/devicetree/bindings/pinctrl/aspeed,ast2500-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/aspeed,ast2500-pinctrl.yaml index 7c25c8d51116..9db904a528ee 100644 --- a/Documentation/devicetree/bindings/pinctrl/aspeed,ast2500-pinctrl.yaml +++ b/Documentation/devicetree/bindings/pinctrl/aspeed,ast2500-pinctrl.yaml @@ -76,73 +76,24 @@ additionalProperties: false examples: - | #include <dt-bindings/clock/aspeed-clock.h> - apb { - compatible = "simple-bus"; - #address-cells = <1>; - #size-cells = <1>; - ranges; - - syscon: scu@1e6e2000 { - compatible = "aspeed,ast2500-scu", "syscon", "simple-mfd"; - reg = <0x1e6e2000 0x1a8>; - #clock-cells = <1>; - #reset-cells = <1>; - - pinctrl: pinctrl { - compatible = "aspeed,ast2500-pinctrl"; - aspeed,external-nodes = <&gfx>, <&lhc>; - - pinctrl_i2c3_default: i2c3_default { - function = "I2C3"; - groups = "I2C3"; - }; - - pinctrl_gpioh0_unbiased_default: gpioh0 { - pins = "A18"; - bias-disable; - }; + scu@1e6e2000 { + compatible = "aspeed,ast2500-scu", "syscon", "simple-mfd"; + reg = <0x1e6e2000 0x1a8>; + #clock-cells = <1>; + #reset-cells = <1>; + + pinctrl: pinctrl { + compatible = "aspeed,ast2500-pinctrl"; + aspeed,external-nodes = <&gfx>, <&lhc>; + + pinctrl_i2c3_default: i2c3_default { + function = "I2C3"; + groups = "I2C3"; }; - }; - - gfx: display@1e6e6000 { - compatible = "aspeed,ast2500-gfx", "syscon"; - reg = <0x1e6e6000 0x1000>; - reg-io-width = <4>; - clocks = <&syscon ASPEED_CLK_GATE_D1CLK>; - resets = <&syscon ASPEED_RESET_CRT1>; - interrupts = <0x19>; - syscon = <&syscon>; - memory-region = <&gfx_memory>; - }; - }; - - lpc: lpc@1e789000 { - compatible = "aspeed,ast2500-lpc", "simple-mfd"; - reg = <0x1e789000 0x1000>; - - #address-cells = <1>; - #size-cells = <1>; - ranges = <0x0 0x1e789000 0x1000>; - - lpc_host: lpc-host@80 { - compatible = "aspeed,ast2500-lpc-host", "simple-mfd", "syscon"; - reg = <0x80 0x1e0>; - reg-io-width = <4>; - #address-cells = <1>; - #size-cells = <1>; - ranges = <0x0 0x80 0x1e0>; - - lhc: lhc@20 { - compatible = "aspeed,ast2500-lhc"; - reg = <0x20 0x24>, <0x48 0x8>; + pinctrl_gpioh0_unbiased_default: gpioh0 { + pins = "A18"; + bias-disable; }; }; }; - - gfx_memory: framebuffer { - size = <0x01000000>; - alignment = <0x01000000>; - compatible = "shared-dma-pool"; - reusable; - }; diff --git a/Documentation/devicetree/bindings/pinctrl/fsl,imx7d-pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/fsl,imx7d-pinctrl.txt deleted file mode 100644 index bfab5ca49fd1..000000000000 --- a/Documentation/devicetree/bindings/pinctrl/fsl,imx7d-pinctrl.txt +++ /dev/null @@ -1,87 +0,0 @@ -* Freescale i.MX7 Dual IOMUX Controller - -iMX7D supports two iomuxc controllers, fsl,imx7d-iomuxc controller is similar -as previous iMX SoC generation and fsl,imx7d-iomuxc-lpsr which provides low -power state retention capabilities on gpios that are part of iomuxc-lpsr -(GPIO1_IO7..GPIO1_IO0). While iomuxc-lpsr provides its own set of registers for -mux and pad control settings, it shares the input select register from main -iomuxc controller for daisy chain settings, the fsl,input-sel property extends -fsl,imx-pinctrl driver to support iomuxc-lpsr controller. - -iomuxc_lpsr: iomuxc-lpsr@302c0000 { - compatible = "fsl,imx7d-iomuxc-lpsr"; - reg = <0x302c0000 0x10000>; - fsl,input-sel = <&iomuxc>; -}; - -iomuxc: iomuxc@30330000 { - compatible = "fsl,imx7d-iomuxc"; - reg = <0x30330000 0x10000>; -}; - -Peripherals using pads from iomuxc-lpsr support low state retention power -state, under LPSR mode GPIO's state of pads are retain. - -Please refer to fsl,imx-pinctrl.txt in this directory for common binding part -and usage. - -Required properties: -- compatible: "fsl,imx7d-iomuxc" for main IOMUXC controller, or - "fsl,imx7d-iomuxc-lpsr" for Low Power State Retention IOMUXC controller. -- fsl,pins: each entry consists of 6 integers and represents the mux and config - setting for one pin. The first 5 integers <mux_reg conf_reg input_reg mux_val - input_val> are specified using a PIN_FUNC_ID macro, which can be found in - imx7d-pinfunc.h under device tree source folder. The last integer CONFIG is - the pad setting value like pull-up on this pin. Please refer to i.MX7 Dual - Reference Manual for detailed CONFIG settings. -- fsl,input-sel: required property for iomuxc-lpsr controller, this property is - a phandle for main iomuxc controller which shares the input select register for - daisy chain settings. - -CONFIG bits definition: -PAD_CTL_PUS_100K_DOWN (0 << 5) -PAD_CTL_PUS_5K_UP (1 << 5) -PAD_CTL_PUS_47K_UP (2 << 5) -PAD_CTL_PUS_100K_UP (3 << 5) -PAD_CTL_PUE (1 << 4) -PAD_CTL_HYS (1 << 3) -PAD_CTL_SRE_SLOW (1 << 2) -PAD_CTL_SRE_FAST (0 << 2) -PAD_CTL_DSE_X1 (0 << 0) -PAD_CTL_DSE_X4 (1 << 0) -PAD_CTL_DSE_X2 (2 << 0) -PAD_CTL_DSE_X6 (3 << 0) - -Examples: -While iomuxc-lpsr is intended to be used by dedicated peripherals to take -advantages of LPSR power mode, is also possible that an IP to use pads from -any of the iomux controllers. For example the I2C1 IP can use SCL pad from -iomuxc-lpsr controller and SDA pad from iomuxc controller as: - -i2c1: i2c@30a20000 { - pinctrl-names = "default"; - pinctrl-0 = <&pinctrl_i2c1_1>, <&pinctrl_i2c1_2>; -}; - -iomuxc-lpsr@302c0000 { - compatible = "fsl,imx7d-iomuxc-lpsr"; - reg = <0x302c0000 0x10000>; - fsl,input-sel = <&iomuxc>; - - pinctrl_i2c1_1: i2c1grp-1 { - fsl,pins = < - MX7D_PAD_GPIO1_IO04__I2C1_SCL 0x4000007f - >; - }; -}; - -iomuxc@30330000 { - compatible = "fsl,imx7d-iomuxc"; - reg = <0x30330000 0x10000>; - - pinctrl_i2c1_2: i2c1grp-2 { - fsl,pins = < - MX7D_PAD_I2C1_SDA__I2C1_SDA 0x4000007f - >; - }; -}; diff --git a/Documentation/devicetree/bindings/pinctrl/fsl,imx7d-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/fsl,imx7d-pinctrl.yaml new file mode 100644 index 000000000000..621038662188 --- /dev/null +++ b/Documentation/devicetree/bindings/pinctrl/fsl,imx7d-pinctrl.yaml @@ -0,0 +1,113 @@ +# SPDX-License-Identifier: GPL-2.0 +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/pinctrl/fsl,imx7d-pinctrl.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Freescale IMX7D IOMUX Controller + +maintainers: + - Dong Aisheng <aisheng.dong@nxp.com> + +description: + Please refer to fsl,imx-pinctrl.txt and pinctrl-bindings.txt in this directory + for common binding part and usage. + +properties: + compatible: + oneOf: + - enum: + - fsl,imx7d-iomuxc + - fsl,imx7d-iomuxc-lpsr + + reg: + maxItems: 1 + + fsl,input-sel: + description: + phandle for main iomuxc controller which shares the input select + register for daisy chain settings. + $ref: /schemas/types.yaml#/definitions/phandle + +# Client device subnode's properties +patternProperties: + 'grp$': + type: object + description: + Pinctrl node's client devices use subnodes for desired pin configuration. + Client device subnodes use below standard properties. + + properties: + fsl,pins: + description: + each entry consists of 6 integers and represents the mux and config + setting for one pin. The first 5 integers <mux_reg conf_reg input_reg + mux_val input_val> are specified using a PIN_FUNC_ID macro, which can + be found in <arch/arm/boot/dts/imx7d-pinfunc.h>. The last integer + CONFIG is the pad setting value like pull-up on this pin. Please + refer to i.MX7D Reference Manual for detailed CONFIG settings. + $ref: /schemas/types.yaml#/definitions/uint32-matrix + items: + items: + - description: | + "mux_reg" indicates the offset of mux register. + - description: | + "conf_reg" indicates the offset of pad configuration register. + - description: | + "input_reg" indicates the offset of select input register. + - description: | + "mux_val" indicates the mux value to be applied. + - description: | + "input_val" indicates the select input value to be applied. + - description: | + "pad_setting" indicates the pad configuration value to be applied. + + required: + - fsl,pins + + additionalProperties: false + +allOf: + - $ref: "pinctrl.yaml#" + +required: + - compatible + - reg + +if: + properties: + compatible: + contains: + enum: + - fsl,imx7d-iomuxc-lpsr + +then: + required: + - fsl,input-sel + +additionalProperties: false + +examples: + - | + iomuxc: pinctrl@30330000 { + compatible = "fsl,imx7d-iomuxc"; + reg = <0x30330000 0x10000>; + + pinctrl_uart5: uart5grp { + fsl,pins = + <0x0160 0x03D0 0x0714 0x1 0x0 0x7e>, + <0x0164 0x03D4 0x0000 0x1 0x0 0x76>; + }; + }; + - | + iomuxc_lpsr: pinctrl@302c0000 { + compatible = "fsl,imx7d-iomuxc-lpsr"; + reg = <0x302c0000 0x10000>; + fsl,input-sel = <&iomuxc>; + + pinctrl_gpio_lpsr: gpio1-grp { + fsl,pins = + <0x0008 0x0038 0x0000 0x0 0x0 0x59>, + <0x000C 0x003C 0x0000 0x0 0x0 0x59>; + }; + }; diff --git a/Documentation/devicetree/bindings/pinctrl/fsl,imxrt1170.yaml b/Documentation/devicetree/bindings/pinctrl/fsl,imxrt1170.yaml new file mode 100644 index 000000000000..2e880b3e537c --- /dev/null +++ b/Documentation/devicetree/bindings/pinctrl/fsl,imxrt1170.yaml @@ -0,0 +1,77 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/pinctrl/fsl,imxrt1170.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Freescale i.MXRT1170 IOMUX Controller + +maintainers: + - Giulio Benetti <giulio.benetti@benettiengineering.com> + - Jesse Taube <Mr.Bossman075@gmail.com> + +description: + Please refer to fsl,imx-pinctrl.txt and pinctrl-bindings.txt in this directory + for common binding part and usage. + +properties: + compatible: + const: fsl,imxrt1170-iomuxc + + reg: + maxItems: 1 + +# Client device subnode's properties +patternProperties: + 'grp$': + type: object + description: + Pinctrl node's client devices use subnodes for desired pin configuration. + Client device subnodes use below standard properties. + + properties: + fsl,pins: + description: + each entry consists of 6 integers and represents the mux and config + setting for one pin. The first 5 integers <mux_reg conf_reg input_reg + mux_val input_val> are specified using a PIN_FUNC_ID macro, which can + be found in <arch/arm/boot/dts/imxrt1170-pinfunc.h>. The last + integer CONFIG is the pad setting value like pull-up on this pin. Please + refer to i.MXRT1170 Reference Manual for detailed CONFIG settings. + $ref: /schemas/types.yaml#/definitions/uint32-matrix + items: + items: + - description: | + "mux_reg" indicates the offset of mux register. + - description: | + "conf_reg" indicates the offset of pad configuration register. + - description: | + "input_reg" indicates the offset of select input register. + - description: | + "mux_val" indicates the mux value to be applied. + - description: | + "input_val" indicates the select input value to be applied. + - description: | + "pad_setting" indicates the pad configuration value to be applied. + required: + - fsl,pins + + additionalProperties: false + +required: + - compatible + - reg + +additionalProperties: false + +examples: + - | + iomuxc: iomuxc@400e8000 { + compatible = "fsl,imxrt1170-iomuxc"; + reg = <0x400e8000 0x4000>; + pinctrl_lpuart1: lpuart1grp { + fsl,pins = + <0x16C 0x3B0 0x620 0x0 0x0 0xf1>, + <0x170 0x3B4 0x61C 0x0 0x0 0xf1>; + }; + }; diff --git a/Documentation/devicetree/bindings/pinctrl/marvell,ac5-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/marvell,ac5-pinctrl.yaml new file mode 100644 index 000000000000..a651b2744caf --- /dev/null +++ b/Documentation/devicetree/bindings/pinctrl/marvell,ac5-pinctrl.yaml @@ -0,0 +1,72 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/pinctrl/marvell,ac5-pinctrl.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Marvell AC5 pin controller + +maintainers: + - Chris Packham <chris.packham@alliedtelesis.co.nz> + +description: + Bindings for Marvell's AC5 memory-mapped pin controller. + +properties: + compatible: + items: + - const: marvell,ac5-pinctrl + + reg: + maxItems: 1 + +patternProperties: + '-pins$': + type: object + $ref: pinmux-node.yaml# + + properties: + marvell,function: + $ref: "/schemas/types.yaml#/definitions/string" + description: + Indicates the function to select. + enum: [ dev_init_done, ge, gpio, i2c0, i2c1, int_out, led, nand, pcie, ptp, sdio, + spi0, spi1, synce, tsen_int, uart0, uart1, uart2, uart3, uartsd, wd_int, xg ] + + marvell,pins: + $ref: /schemas/types.yaml#/definitions/string-array + description: + Array of MPP pins to be used for the given function. + minItems: 1 + items: + enum: [ mpp0, mpp1, mpp2, mpp3, mpp4, mpp5, mpp6, mpp7, mpp8, mpp9, + mpp10, mpp11, mpp12, mpp13, mpp14, mpp15, mpp16, mpp17, mpp18, mpp19, + mpp20, mpp21, mpp22, mpp23, mpp24, mpp25, mpp26, mpp27, mpp28, mpp29, + mpp30, mpp31, mpp32, mpp33, mpp34, mpp35, mpp36, mpp37, mpp38, mpp39, + mpp40, mpp41, mpp42, mpp43, mpp44, mpp45 ] + +allOf: + - $ref: "pinctrl.yaml#" + +required: + - compatible + - reg + +additionalProperties: false + +examples: + - | + pinctrl@80020100 { + compatible = "marvell,ac5-pinctrl"; + reg = <0x80020100 0x20>; + + i2c0_pins: i2c0-pins { + marvell,pins = "mpp26", "mpp27"; + marvell,function = "i2c0"; + }; + + i2c0_gpio: i2c0-gpio-pins { + marvell,pins = "mpp26", "mpp27"; + marvell,function = "gpio"; + }; + }; diff --git a/Documentation/devicetree/bindings/pinctrl/mediatek,pinctrl-mt6795.yaml b/Documentation/devicetree/bindings/pinctrl/mediatek,pinctrl-mt6795.yaml new file mode 100644 index 000000000000..73ae6e11410b --- /dev/null +++ b/Documentation/devicetree/bindings/pinctrl/mediatek,pinctrl-mt6795.yaml @@ -0,0 +1,224 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/pinctrl/mediatek,pinctrl-mt6795.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Mediatek MT6795 Pin Controller + +maintainers: + - AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> + - Sean Wang <sean.wang@kernel.org> + +description: | + The Mediatek's Pin controller is used to control SoC pins. + +properties: + compatible: + const: mediatek,mt6795-pinctrl + + gpio-controller: true + + '#gpio-cells': + description: | + Number of cells in GPIO specifier. Since the generic GPIO binding is used, + the amount of cells must be specified as 2. See the below + mentioned gpio binding representation for description of particular cells. + const: 2 + + gpio-ranges: + description: GPIO valid number range. + maxItems: 1 + + reg: + description: + Physical address base for gpio base and eint registers. + minItems: 2 + + reg-names: + items: + - const: base + - const: eint + + interrupt-controller: true + + '#interrupt-cells': + const: 2 + + interrupts: + description: The interrupt outputs to sysirq. + maxItems: 1 + +# PIN CONFIGURATION NODES +patternProperties: + '-pins$': + type: object + additionalProperties: false + patternProperties: + '^pins': + type: object + additionalProperties: false + description: | + A pinctrl node should contain at least one subnodes representing the + pinctrl groups available on the machine. Each subnode will list the + pins it needs, and how they should be configured, with regard to muxer + configuration, pullups, drive strength, input enable/disable and + input schmitt. + An example of using macro: + pincontroller { + /* GPIO0 set as multifunction GPIO0 */ + gpio-pins { + pins { + pinmux = <PINMUX_GPIO0__FUNC_GPIO0>; + } + }; + /* GPIO45 set as multifunction SDA0 */ + i2c0-pins { + pins { + pinmux = <PINMUX_GPIO45__FUNC_SDA0>; + } + }; + }; + $ref: "pinmux-node.yaml" + + properties: + pinmux: + description: | + Integer array, represents gpio pin number and mux setting. + Supported pin number and mux varies for different SoCs, and are + defined as macros in dt-bindings/pinctrl/<soc>-pinfunc.h + directly. + + drive-strength: + enum: [2, 4, 6, 8, 10, 12, 14, 16] + + bias-pull-down: + oneOf: + - type: boolean + - enum: [100, 101, 102, 103] + description: mt6795 pull down PUPD/R0/R1 type define value. + description: | + For normal pull down type, it is not necessary to specify R1R0 + values; When pull down type is PUPD/R0/R1, adding R1R0 defines + will set different resistance values. + + bias-pull-up: + oneOf: + - type: boolean + - enum: [100, 101, 102, 103] + description: mt6795 pull up PUPD/R0/R1 type define value. + description: | + For normal pull up type, it is not necessary to specify R1R0 + values; When pull up type is PUPD/R0/R1, adding R1R0 defines + will set different resistance values. + + bias-disable: true + + output-high: true + + output-low: true + + input-enable: true + + input-disable: true + + input-schmitt-enable: true + + input-schmitt-disable: true + + mediatek,pull-up-adv: + description: | + Pull up setings for 2 pull resistors, R0 and R1. User can + configure those special pins. Valid arguments are described as below: + 0: (R1, R0) = (0, 0) which means R1 disabled and R0 disabled. + 1: (R1, R0) = (0, 1) which means R1 disabled and R0 enabled. + 2: (R1, R0) = (1, 0) which means R1 enabled and R0 disabled. + 3: (R1, R0) = (1, 1) which means R1 enabled and R0 enabled. + $ref: /schemas/types.yaml#/definitions/uint32 + enum: [0, 1, 2, 3] + + mediatek,pull-down-adv: + description: | + Pull down settings for 2 pull resistors, R0 and R1. User can + configure those special pins. Valid arguments are described as below: + 0: (R1, R0) = (0, 0) which means R1 disabled and R0 disabled. + 1: (R1, R0) = (0, 1) which means R1 disabled and R0 enabled. + 2: (R1, R0) = (1, 0) which means R1 enabled and R0 disabled. + 3: (R1, R0) = (1, 1) which means R1 enabled and R0 enabled. + $ref: /schemas/types.yaml#/definitions/uint32 + enum: [0, 1, 2, 3] + + required: + - pinmux + +allOf: + - $ref: "pinctrl.yaml#" + +required: + - compatible + - reg + - reg-names + - interrupts + - interrupt-controller + - '#interrupt-cells' + - gpio-controller + - '#gpio-cells' + - gpio-ranges + +additionalProperties: false + +examples: + - | + #include <dt-bindings/interrupt-controller/arm-gic.h> + #include <dt-bindings/interrupt-controller/irq.h> + #include <dt-bindings/pinctrl/mt6795-pinfunc.h> + + soc { + #address-cells = <2>; + #size-cells = <2>; + + pio: pinctrl@10005000 { + compatible = "mediatek,mt6795-pinctrl"; + reg = <0 0x10005000 0 0x1000>, <0 0x1000b000 0 0x1000>; + reg-names = "base", "eint"; + gpio-controller; + #gpio-cells = <2>; + gpio-ranges = <&pio 0 0 196>; + interrupt-controller; + interrupts = <GIC_SPI 153 IRQ_TYPE_LEVEL_HIGH>; + #interrupt-cells = <2>; + + i2c0-pins { + pins-sda-scl { + pinmux = <PINMUX_GPIO45__FUNC_SDA0>, + <PINMUX_GPIO46__FUNC_SCL0>; + }; + }; + + mmc0-pins { + pins-cmd-dat { + pinmux = <PINMUX_GPIO154__FUNC_MSDC0_DAT0>, + <PINMUX_GPIO155__FUNC_MSDC0_DAT1>, + <PINMUX_GPIO156__FUNC_MSDC0_DAT2>, + <PINMUX_GPIO157__FUNC_MSDC0_DAT3>, + <PINMUX_GPIO158__FUNC_MSDC0_DAT4>, + <PINMUX_GPIO159__FUNC_MSDC0_DAT5>, + <PINMUX_GPIO160__FUNC_MSDC0_DAT6>, + <PINMUX_GPIO161__FUNC_MSDC0_DAT7>, + <PINMUX_GPIO162__FUNC_MSDC0_CMD>; + input-enable; + bias-pull-up = <MTK_PUPD_SET_R1R0_01>; + }; + + pins-clk { + pinmux = <PINMUX_GPIO163__FUNC_MSDC0_CLK>; + bias-pull-down = <MTK_PUPD_SET_R1R0_10>; + }; + + pins-rst { + pinmux = <PINMUX_GPIO165__FUNC_MSDC0_RSTB>; + bias-pull-up = <MTK_PUPD_SET_R1R0_10>; + }; + }; + }; + }; diff --git a/Documentation/devicetree/bindings/pinctrl/mscc,ocelot-pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/mscc,ocelot-pinctrl.txt deleted file mode 100644 index 5d84fd299ccf..000000000000 --- a/Documentation/devicetree/bindings/pinctrl/mscc,ocelot-pinctrl.txt +++ /dev/null @@ -1,42 +0,0 @@ -Microsemi Ocelot pin controller Device Tree Bindings ----------------------------------------------------- - -Required properties: - - compatible : Should be "mscc,ocelot-pinctrl", - "mscc,jaguar2-pinctrl", "microchip,sparx5-pinctrl", - "mscc,luton-pinctrl", "mscc,serval-pinctrl", - "microchip,lan966x-pinctrl" or "mscc,servalt-pinctrl" - - reg : Address and length of the register set for the device - - gpio-controller : Indicates this device is a GPIO controller - - #gpio-cells : Must be 2. - The first cell is the pin number and the - second cell specifies GPIO flags, as defined in - <dt-bindings/gpio/gpio.h>. - - gpio-ranges : Range of pins managed by the GPIO controller. - - -The ocelot-pinctrl driver uses the generic pin multiplexing and generic pin -configuration documented in pinctrl-bindings.txt. - -The following generic properties are supported: - - function - - pins - -Example: - gpio: pinctrl@71070034 { - compatible = "mscc,ocelot-pinctrl"; - reg = <0x71070034 0x28>; - gpio-controller; - #gpio-cells = <2>; - gpio-ranges = <&gpio 0 0 22>; - - uart_pins: uart-pins { - pins = "GPIO_6", "GPIO_7"; - function = "uart"; - }; - - uart2_pins: uart2-pins { - pins = "GPIO_12", "GPIO_13"; - function = "uart2"; - }; - }; diff --git a/Documentation/devicetree/bindings/pinctrl/mscc,ocelot-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/mscc,ocelot-pinctrl.yaml new file mode 100644 index 000000000000..98d547c34ef3 --- /dev/null +++ b/Documentation/devicetree/bindings/pinctrl/mscc,ocelot-pinctrl.yaml @@ -0,0 +1,116 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/pinctrl/mscc,ocelot-pinctrl.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Microsemi Ocelot pin controller + +maintainers: + - Alexandre Belloni <alexandre.belloni@bootlin.com> + - Lars Povlsen <lars.povlsen@microchip.com> + +properties: + compatible: + enum: + - microchip,lan966x-pinctrl + - microchip,sparx5-pinctrl + - mscc,jaguar2-pinctrl + - mscc,luton-pinctrl + - mscc,ocelot-pinctrl + - mscc,serval-pinctrl + - mscc,servalt-pinctrl + + reg: + items: + - description: Base address + - description: Extended pin configuration registers + minItems: 1 + + gpio-controller: true + + '#gpio-cells': + const: 2 + + gpio-ranges: true + + interrupts: + maxItems: 1 + + interrupt-controller: true + + "#interrupt-cells": + const: 2 + + resets: + maxItems: 1 + + reset-names: + description: Optional shared switch reset. + items: + - const: switch + +patternProperties: + '-pins$': + type: object + allOf: + - $ref: "pinmux-node.yaml" + - $ref: "pincfg-node.yaml" + + properties: + function: true + pins: true + output-high: true + output-low: true + drive-strength: true + + required: + - function + - pins + + additionalProperties: false + +required: + - compatible + - reg + - gpio-controller + - '#gpio-cells' + - gpio-ranges + +allOf: + - $ref: "pinctrl.yaml#" + - if: + properties: + compatible: + contains: + enum: + - microchip,lan966x-pinctrl + - microchip,sparx5-pinctrl + then: + properties: + reg: + minItems: 2 + +additionalProperties: false + +examples: + - | + gpio: pinctrl@71070034 { + compatible = "mscc,ocelot-pinctrl"; + reg = <0x71070034 0x28>; + gpio-controller; + #gpio-cells = <2>; + gpio-ranges = <&gpio 0 0 22>; + + uart_pins: uart-pins { + pins = "GPIO_6", "GPIO_7"; + function = "uart"; + }; + + uart2_pins: uart2-pins { + pins = "GPIO_12", "GPIO_13"; + function = "uart2"; + }; + }; + +... diff --git a/Documentation/devicetree/bindings/pinctrl/pinctrl-mt8192.yaml b/Documentation/devicetree/bindings/pinctrl/pinctrl-mt8192.yaml index 3c84676a167d..c90a132fbc79 100644 --- a/Documentation/devicetree/bindings/pinctrl/pinctrl-mt8192.yaml +++ b/Documentation/devicetree/bindings/pinctrl/pinctrl-mt8192.yaml @@ -29,6 +29,8 @@ properties: description: gpio valid number range. maxItems: 1 + gpio-line-names: true + reg: description: | Physical address base for gpio base registers. There are 11 GPIO @@ -51,62 +53,92 @@ properties: #PIN CONFIGURATION NODES patternProperties: - '^pins': + '-pins$': type: object - description: | - A pinctrl node should contain at least one subnodes representing the - pinctrl groups available on the machine. Each subnode will list the - pins it needs, and how they should be configured, with regard to muxer - configuration, pullups, drive strength, input enable/disable and - input schmitt. - An example of using macro: - pincontroller { - /* GPIO0 set as multifunction GPIO0 */ - state_0_node_a { - pinmux = <PINMUX_GPIO0__FUNC_GPIO0>; - }; - /* GPIO1 set as multifunction PWM */ - state_0_node_b { - pinmux = <PINMUX_GPIO1__FUNC_PWM_1>; - }; - }; - $ref: "pinmux-node.yaml" - - properties: - pinmux: - description: | - Integer array, represents gpio pin number and mux setting. - Supported pin number and mux varies for different SoCs, and are defined - as macros in dt-bindings/pinctrl/<soc>-pinfunc.h directly. - - drive-strength: - description: | - It can support some arguments, such as MTK_DRIVE_4mA, MTK_DRIVE_6mA, etc. See - dt-bindings/pinctrl/mt65xx.h. It can only support 2/4/6/8/10/12/14/16mA in mt8192. - enum: [2, 4, 6, 8, 10, 12, 14, 16] - - bias-pull-down: true - - bias-pull-up: true - - bias-disable: true - - output-high: true - - output-low: true - - input-enable: true - - input-disable: true - - input-schmitt-enable: true - - input-schmitt-disable: true - - required: - - pinmux - additionalProperties: false + patternProperties: + '^pins': + type: object + description: | + A pinctrl node should contain at least one subnodes representing the + pinctrl groups available on the machine. Each subnode will list the + pins it needs, and how they should be configured, with regard to muxer + configuration, pullups, drive strength, input enable/disable and + input schmitt. + $ref: "pinmux-node.yaml" + + properties: + pinmux: + description: | + Integer array, represents gpio pin number and mux setting. + Supported pin number and mux varies for different SoCs, and are defined + as macros in dt-bindings/pinctrl/<soc>-pinfunc.h directly. + + drive-strength: + description: | + It can support some arguments, such as MTK_DRIVE_4mA, MTK_DRIVE_6mA, etc. See + dt-bindings/pinctrl/mt65xx.h. It can only support 2/4/6/8/10/12/14/16mA in mt8192. + enum: [2, 4, 6, 8, 10, 12, 14, 16] + + mediatek,drive-strength-adv: + description: | + Describe the specific driving setup property. + For I2C pins, the existing generic driving setup can only support + 2/4/6/8/10/12/14/16mA driving. But in specific driving setup, they + can support 0.125/0.25/0.5/1mA adjustment. If we enable specific + driving setup, the existing generic setup will be disabled. + The specific driving setup is controlled by E1E0EN. + When E1=0/E0=0, the strength is 0.125mA. + When E1=0/E0=1, the strength is 0.25mA. + When E1=1/E0=0, the strength is 0.5mA. + When E1=1/E0=1, the strength is 1mA. + EN is used to enable or disable the specific driving setup. + Valid arguments are described as below: + 0: (E1, E0, EN) = (0, 0, 0) + 1: (E1, E0, EN) = (0, 0, 1) + 2: (E1, E0, EN) = (0, 1, 0) + 3: (E1, E0, EN) = (0, 1, 1) + 4: (E1, E0, EN) = (1, 0, 0) + 5: (E1, E0, EN) = (1, 0, 1) + 6: (E1, E0, EN) = (1, 1, 0) + 7: (E1, E0, EN) = (1, 1, 1) + So the valid arguments are from 0 to 7. + $ref: /schemas/types.yaml#/definitions/uint32 + enum: [0, 1, 2, 3, 4, 5, 6, 7] + + mediatek,pull-up-adv: + description: | + Pull up settings for 2 pull resistors, R0 and R1. User can + configure those special pins. Valid arguments are described as below: + 0: (R1, R0) = (0, 0) which means R1 disabled and R0 disabled. + 1: (R1, R0) = (0, 1) which means R1 disabled and R0 enabled. + 2: (R1, R0) = (1, 0) which means R1 enabled and R0 disabled. + 3: (R1, R0) = (1, 1) which means R1 enabled and R0 enabled. + $ref: /schemas/types.yaml#/definitions/uint32 + enum: [0, 1, 2, 3] + + bias-pull-down: true + + bias-pull-up: true + + bias-disable: true + + output-high: true + + output-low: true + + input-enable: true + + input-disable: true + + input-schmitt-enable: true + + input-schmitt-disable: true + + required: + - pinmux + + additionalProperties: false allOf: - $ref: "pinctrl.yaml#" @@ -151,8 +183,17 @@ examples: interrupts = <GIC_SPI 212 IRQ_TYPE_LEVEL_HIGH 0>; #interrupt-cells = <2>; - pins { - pinmux = <PINMUX_GPIO0__FUNC_GPIO0>; - output-low; + spi1-default-pins { + pins-cs-mosi-clk { + pinmux = <PINMUX_GPIO157__FUNC_SPI1_A_CSB>, + <PINMUX_GPIO159__FUNC_SPI1_A_MO>, + <PINMUX_GPIO156__FUNC_SPI1_A_CLK>; + bias-disable; + }; + + pins-miso { + pinmux = <PINMUX_GPIO158__FUNC_SPI1_A_MI>; + bias-pull-down; + }; }; }; diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,pmic-gpio.yaml b/Documentation/devicetree/bindings/pinctrl/qcom,pmic-gpio.yaml index fe2bcf0694d9..6f2efc3772cb 100644 --- a/Documentation/devicetree/bindings/pinctrl/qcom,pmic-gpio.yaml +++ b/Documentation/devicetree/bindings/pinctrl/qcom,pmic-gpio.yaml @@ -20,6 +20,7 @@ properties: - qcom,pm2250-gpio - qcom,pm660-gpio - qcom,pm660l-gpio + - qcom,pm6125-gpio - qcom,pm6150-gpio - qcom,pm6150l-gpio - qcom,pm6350-gpio @@ -32,6 +33,7 @@ properties: - qcom,pm8058-gpio - qcom,pm8150-gpio - qcom,pm8150b-gpio + - qcom,pm8150l-gpio - qcom,pm8226-gpio - qcom,pm8350-gpio - qcom,pm8350b-gpio @@ -49,10 +51,12 @@ properties: - qcom,pmi8994-gpio - qcom,pmi8998-gpio - qcom,pmk8350-gpio + - qcom,pmm8155au-gpio - qcom,pmr735a-gpio - qcom,pmr735b-gpio - qcom,pms405-gpio - qcom,pmx55-gpio + - qcom,pmx65-gpio - enum: - qcom,spmi-gpio @@ -71,6 +75,16 @@ properties: gpio-ranges: maxItems: 1 + gpio-line-names: + minItems: 2 + maxItems: 44 + + gpio-reserved-ranges: + minItems: 1 + # maxItems as half of total number of GPIOs, as there has to be at + # least one usable GPIO between each reserved range. + maxItems: 22 + '#gpio-cells': const: 2 description: @@ -87,13 +101,278 @@ required: - gpio-ranges - interrupt-controller +allOf: + - if: + properties: + compatible: + contains: + enum: + - qcom,pm8008-gpio + - qcom,pmi8950-gpio + then: + properties: + gpio-line-names: + minItems: 2 + maxItems: 2 + gpio-reserved-ranges: + maxItems: 1 + + - if: + properties: + compatible: + contains: + enum: + - qcom,pm8005-gpio + - qcom,pm8450-gpio + - qcom,pm8916-gpio + - qcom,pmk8350-gpio + - qcom,pmr735a-gpio + - qcom,pmr735b-gpio + then: + properties: + gpio-line-names: + minItems: 4 + maxItems: 4 + gpio-reserved-ranges: + minItems: 1 + maxItems: 2 + + - if: + properties: + compatible: + contains: + enum: + - qcom,pm8018-gpio + - qcom,pm8019-gpio + then: + properties: + gpio-line-names: + minItems: 6 + maxItems: 6 + gpio-reserved-ranges: + minItems: 1 + maxItems: 3 + + - if: + properties: + compatible: + contains: + enum: + - qcom,pm8350b-gpio + - qcom,pm8950-gpio + then: + properties: + gpio-line-names: + minItems: 8 + maxItems: 8 + gpio-reserved-ranges: + minItems: 1 + maxItems: 4 + + - if: + properties: + compatible: + contains: + enum: + - qcom,pm6350-gpio + - qcom,pm8350c-gpio + then: + properties: + gpio-line-names: + minItems: 9 + maxItems: 9 + gpio-reserved-ranges: + minItems: 1 + maxItems: 5 + + - if: + properties: + compatible: + contains: + enum: + - qcom,pm2250-gpio + - qcom,pm6150-gpio + - qcom,pm7325-gpio + - qcom,pm8150-gpio + - qcom,pm8350-gpio + - qcom,pmc8180-gpio + - qcom,pmi8994-gpio + - qcom,pmm8155au-gpio + then: + properties: + gpio-line-names: + minItems: 10 + maxItems: 10 + gpio-reserved-ranges: + minItems: 1 + maxItems: 5 + + - if: + properties: + compatible: + contains: + enum: + - qcom,pmx55-gpio + then: + properties: + gpio-line-names: + minItems: 11 + maxItems: 11 + gpio-reserved-ranges: + minItems: 1 + maxItems: 6 + + - if: + properties: + compatible: + contains: + enum: + - qcom,pm660l-gpio + - qcom,pm6150l-gpio + - qcom,pm8038-gpio + - qcom,pm8150b-gpio + - qcom,pm8150l-gpio + - qcom,pmc8180c-gpio + - qcom,pms405-gpio + then: + properties: + gpio-line-names: + minItems: 12 + maxItems: 12 + gpio-reserved-ranges: + minItems: 1 + maxItems: 6 + + - if: + properties: + compatible: + contains: + enum: + - qcom,pm660-gpio + then: + properties: + gpio-line-names: + minItems: 13 + maxItems: 13 + gpio-reserved-ranges: + minItems: 1 + maxItems: 7 + + - if: + properties: + compatible: + contains: + enum: + - qcom,pmi8998-gpio + then: + properties: + gpio-line-names: + minItems: 14 + maxItems: 14 + gpio-reserved-ranges: + minItems: 1 + maxItems: 7 + + - if: + properties: + compatible: + contains: + enum: + - qcom,pmx65-gpio + then: + properties: + gpio-line-names: + minItems: 16 + maxItems: 16 + gpio-reserved-ranges: + minItems: 1 + maxItems: 8 + + - if: + properties: + compatible: + contains: + enum: + - qcom,pm8994-gpio + - qcom,pma8084-gpio + then: + properties: + gpio-line-names: + minItems: 22 + maxItems: 22 + gpio-reserved-ranges: + minItems: 1 + maxItems: 11 + + - if: + properties: + compatible: + contains: + enum: + - qcom,pm8998-gpio + then: + properties: + gpio-line-names: + minItems: 26 + maxItems: 26 + gpio-reserved-ranges: + minItems: 1 + maxItems: 13 + + - if: + properties: + compatible: + contains: + enum: + - qcom,pm8941-gpio + then: + properties: + gpio-line-names: + minItems: 36 + maxItems: 36 + gpio-reserved-ranges: + minItems: 1 + maxItems: 18 + + - if: + properties: + compatible: + contains: + enum: + - qcom,pm8917-gpio + then: + properties: + gpio-line-names: + minItems: 38 + maxItems: 38 + gpio-reserved-ranges: + minItems: 1 + maxItems: 19 + + - if: + properties: + compatible: + contains: + enum: + - qcom,pm8058-gpio + - qcom,pm8921-gpio + then: + properties: + gpio-line-names: + minItems: 44 + maxItems: 44 + gpio-reserved-ranges: + minItems: 1 + maxItems: 22 + patternProperties: '-state$': oneOf: - $ref: "#/$defs/qcom-pmic-gpio-state" - patternProperties: - ".*": + "(pinconf|-pins)$": $ref: "#/$defs/qcom-pmic-gpio-state" + additionalProperties: false $defs: qcom-pmic-gpio-state: @@ -106,6 +385,7 @@ $defs: description: List of gpio pins affected by the properties specified in this subnode. Valid pins are + - gpio1-gpio9 for pm6125 - gpio1-gpio10 for pm6150 - gpio1-gpio12 for pm6150l - gpio1-gpio9 for pm6350 @@ -134,12 +414,14 @@ $defs: - gpio1-gpio2 for pmi8950 - gpio1-gpio10 for pmi8994 - gpio1-gpio4 for pmk8350 + - gpio1-gpio10 for pmm8155au - gpio1-gpio4 for pmr735a - gpio1-gpio4 for pmr735b - gpio1-gpio12 for pms405 (holes on gpio1, gpio9 and gpio10) - gpio1-gpio11 for pmx55 (holes on gpio3, gpio7, gpio10 and gpio11) + - gpio1-gpio16 for pmx65 items: pattern: "^gpio([0-9]+)$" @@ -174,6 +456,7 @@ $defs: bias-high-impedance: true input-enable: true + input-disable: true output-high: true output-low: true output-enable: true @@ -232,7 +515,7 @@ examples: #gpio-cells = <2>; pm8921_gpio_keys: gpio-keys-state { - volume-keys { + volume-keys-pins { pins = "gpio20", "gpio21"; function = "normal"; diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,qcm2290-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/qcom,qcm2290-pinctrl.yaml index 206f4f238736..3f4f1c0360b5 100644 --- a/Documentation/devicetree/bindings/pinctrl/qcom,qcm2290-pinctrl.yaml +++ b/Documentation/devicetree/bindings/pinctrl/qcom,qcm2290-pinctrl.yaml @@ -42,8 +42,7 @@ properties: gpio-ranges: maxItems: 1 - wakeup-parent: - maxItems: 1 + wakeup-parent: true #PIN CONFIGURATION NODES patternProperties: diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,sc7280-lpass-lpi-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/qcom,sc7280-lpass-lpi-pinctrl.yaml new file mode 100644 index 000000000000..d32ee32776e8 --- /dev/null +++ b/Documentation/devicetree/bindings/pinctrl/qcom,sc7280-lpass-lpi-pinctrl.yaml @@ -0,0 +1,115 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/pinctrl/qcom,sc7280-lpass-lpi-pinctrl.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Qualcomm Technologies, Inc. Low Power Audio SubSystem (LPASS) + Low Power Island (LPI) TLMM block + +maintainers: + - Srinivasa Rao Mandadapu <srivasam@codeaurora.org> + - Srinivas Kandagatla <srinivas.kandagatla@linaro.org> + +description: | + This binding describes the Top Level Mode Multiplexer block found in the + LPASS LPI IP on most Qualcomm SoCs + +properties: + compatible: + const: qcom,sc7280-lpass-lpi-pinctrl + + reg: + minItems: 2 + maxItems: 2 + + gpio-controller: true + + '#gpio-cells': + description: Specifying the pin number and flags, as defined in + include/dt-bindings/gpio/gpio.h + const: 2 + + gpio-ranges: + maxItems: 1 + +#PIN CONFIGURATION NODES +patternProperties: + '-pins$': + type: object + description: + Pinctrl node's client devices use subnodes for desired pin configuration. + Client device subnodes use below standard properties. + $ref: "/schemas/pinctrl/pincfg-node.yaml" + + properties: + pins: + description: + List of gpio pins affected by the properties specified in this + subnode. + items: + oneOf: + - pattern: "^gpio([0-9]|[1-9][0-9])$" + minItems: 1 + maxItems: 15 + + function: + enum: [ gpio, swr_tx_clk, qua_mi2s_sclk, swr_tx_data, qua_mi2s_ws, + qua_mi2s_data, swr_rx_clk, swr_rx_data, dmic1_clk, i2s1_clk, + dmic1_data, i2s1_ws, dmic2_clk, dmic2_data, i2s1_data, + i2s2_clk, wsa_swr_clk, i2s2_ws, wsa_swr_data, dmic3_clk, + dmic3_data, i2s2_data ] + description: + Specify the alternative function to be configured for the specified + pins. + + drive-strength: + enum: [2, 4, 6, 8, 10, 12, 14, 16] + default: 2 + description: + Selects the drive strength for the specified pins, in mA. + + slew-rate: + enum: [0, 1, 2, 3] + default: 0 + description: | + 0: No adjustments + 1: Higher Slew rate (faster edges) + 2: Lower Slew rate (slower edges) + 3: Reserved (No adjustments) + + bias-pull-down: true + + bias-pull-up: true + + bias-disable: true + + output-high: true + + output-low: true + + required: + - pins + - function + + additionalProperties: false + +required: + - compatible + - reg + - gpio-controller + - '#gpio-cells' + - gpio-ranges + +additionalProperties: false + +examples: + - | + lpass_tlmm: pinctrl@33c0000 { + compatible = "qcom,sc7280-lpass-lpi-pinctrl"; + reg = <0x33c0000 0x20000>, + <0x3550000 0x10000>; + gpio-controller; + #gpio-cells = <2>; + gpio-ranges = <&lpass_tlmm 0 0 15>; + }; diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,sc7280-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/qcom,sc7280-pinctrl.yaml index 6c7c3f6a140e..2d228164357c 100644 --- a/Documentation/devicetree/bindings/pinctrl/qcom,sc7280-pinctrl.yaml +++ b/Documentation/devicetree/bindings/pinctrl/qcom,sc7280-pinctrl.yaml @@ -42,8 +42,7 @@ properties: gpio-ranges: maxItems: 1 - wakeup-parent: - maxItems: 1 + wakeup-parent: true #PIN CONFIGURATION NODES patternProperties: diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,sm6115-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/qcom,sm6115-pinctrl.yaml index cfcde405d30a..a7a2bb8bff46 100644 --- a/Documentation/devicetree/bindings/pinctrl/qcom,sm6115-pinctrl.yaml +++ b/Documentation/devicetree/bindings/pinctrl/qcom,sm6115-pinctrl.yaml @@ -49,8 +49,7 @@ properties: gpio-ranges: maxItems: 1 - wakeup-parent: - maxItems: 1 + wakeup-parent: true #PIN CONFIGURATION NODES patternProperties: diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,lpass-lpi-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/qcom,sm8250-lpass-lpi-pinctrl.yaml index 5c5542f1627c..06efb1382876 100644 --- a/Documentation/devicetree/bindings/pinctrl/qcom,lpass-lpi-pinctrl.yaml +++ b/Documentation/devicetree/bindings/pinctrl/qcom,sm8250-lpass-lpi-pinctrl.yaml @@ -1,7 +1,7 @@ # SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) %YAML 1.2 --- -$id: http://devicetree.org/schemas/pinctrl/qcom,lpass-lpi-pinctrl.yaml# +$id: http://devicetree.org/schemas/pinctrl/qcom,sm8250-lpass-lpi-pinctrl.yaml# $schema: http://devicetree.org/meta-schemas/core.yaml# title: Qualcomm Technologies, Inc. Low Power Audio SubSystem (LPASS) diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,sm8250-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/qcom,sm8250-pinctrl.yaml index cfa2c50fdb93..15bb1018cf21 100644 --- a/Documentation/devicetree/bindings/pinctrl/qcom,sm8250-pinctrl.yaml +++ b/Documentation/devicetree/bindings/pinctrl/qcom,sm8250-pinctrl.yaml @@ -49,8 +49,7 @@ properties: gpio-ranges: maxItems: 1 - wakeup-parent: - maxItems: 1 + wakeup-parent: true #PIN CONFIGURATION NODES patternProperties: diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,tlmm-common.yaml b/Documentation/devicetree/bindings/pinctrl/qcom,tlmm-common.yaml index 780f15bb5e40..c88c8dcb69d9 100644 --- a/Documentation/devicetree/bindings/pinctrl/qcom,tlmm-common.yaml +++ b/Documentation/devicetree/bindings/pinctrl/qcom,tlmm-common.yaml @@ -42,7 +42,6 @@ properties: description: Specifying the interrupt-controller used to wake up the system when the TLMM block has been powered down. - maxItems: 1 gpio-reserved-ranges: description: diff --git a/Documentation/devicetree/bindings/pinctrl/ralink,mt7620-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/ralink,mt7620-pinctrl.yaml new file mode 100644 index 000000000000..4d820df24b89 --- /dev/null +++ b/Documentation/devicetree/bindings/pinctrl/ralink,mt7620-pinctrl.yaml @@ -0,0 +1,91 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/pinctrl/ralink,mt7620-pinctrl.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Ralink MT7620 Pin Controller + +maintainers: + - Arınç ÃœNAL <arinc.unal@arinc9.com> + - Sergio Paracuellos <sergio.paracuellos@gmail.com> + +description: + Ralink MT7620 pin controller for MT7620, MT7628 and MT7688 SoCs. + The pin controller can only set the muxing of pin groups. Muxing individual + pins is not supported. There is no pinconf support. + +properties: + compatible: + const: ralink,mt7620-pinctrl + +patternProperties: + '-pins$': + type: object + patternProperties: + '^(.*-)?pinmux$': + type: object + description: node for pinctrl. + $ref: pinmux-node.yaml# + + properties: + groups: + description: The pin group to select. + enum: [ + # For MT7620 SoC + ephy, i2c, mdio, nd_sd, pa, pcie, rgmii1, rgmii2, spi, spi refclk, + uartf, uartlite, wdt, wled, + + # For MT7628 and MT7688 SoCs + gpio, i2c, i2s, p0led_an, p0led_kn, p1led_an, p1led_kn, p2led_an, + p2led_kn, p3led_an, p3led_kn, p4led_an, p4led_kn, perst, pwm0, + pwm1, refclk, sdmode, spi, spi cs1, spis, uart0, uart1, uart2, + wdt, wled_an, wled_kn, + ] + + function: + description: The mux function to select. + enum: [ + # For MT7620 SoC + ephy, gpio, gpio i2s, gpio uartf, i2c, i2s uartf, mdio, nand, pa, + pcie refclk, pcie rst, pcm gpio, pcm i2s, pcm uartf, refclk, + rgmii1, rgmii2, sd, spi, spi refclk, uartf, uartlite, wdt refclk, + wdt rst, wled, + + # For MT7628 and MT7688 SoCs + antenna, debug, gpio, i2c, i2s, jtag, p0led_an, p0led_kn, + p1led_an, p1led_kn, p2led_an, p2led_kn, p3led_an, p3led_kn, + p4led_an, p4led_kn, pcie, pcm, perst, pwm, pwm0, pwm1, pwm_uart2, + refclk, rsvd, sdxc, sdxc d5 d4, sdxc d6, sdxc d7, spi, spi cs1, + spis, sw_r, uart0, uart1, uart2, utif, wdt, wled_an, wled_kn, -, + ] + + required: + - groups + - function + + additionalProperties: false + + additionalProperties: false + +allOf: + - $ref: "pinctrl.yaml#" + +required: + - compatible + +additionalProperties: false + +examples: + # Pinmux controller node + - | + pinctrl { + compatible = "ralink,mt7620-pinctrl"; + + i2c_pins: i2c0-pins { + pinmux { + groups = "i2c"; + function = "i2c"; + }; + }; + }; diff --git a/Documentation/devicetree/bindings/pinctrl/ralink,rt2880-pinmux.yaml b/Documentation/devicetree/bindings/pinctrl/ralink,mt7621-pinctrl.yaml index 9de8b0c075e2..61e5c847e8c8 100644 --- a/Documentation/devicetree/bindings/pinctrl/ralink,rt2880-pinmux.yaml +++ b/Documentation/devicetree/bindings/pinctrl/ralink,mt7621-pinctrl.yaml @@ -1,21 +1,23 @@ # SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause %YAML 1.2 --- -$id: http://devicetree.org/schemas/pinctrl/ralink,rt2880-pinmux.yaml# +$id: http://devicetree.org/schemas/pinctrl/ralink,mt7621-pinctrl.yaml# $schema: http://devicetree.org/meta-schemas/core.yaml# -title: Ralink rt2880 pinmux controller +title: Ralink MT7621 Pin Controller maintainers: + - Arınç ÃœNAL <arinc.unal@arinc9.com> - Sergio Paracuellos <sergio.paracuellos@gmail.com> description: - The rt2880 pinmux can only set the muxing of pin groups. Muxing indiviual pins - is not supported. There is no pinconf support. + Ralink MT7621 pin controller for MT7621 SoC. + The pin controller can only set the muxing of pin groups. Muxing individual + pins is not supported. There is no pinconf support. properties: compatible: - const: ralink,rt2880-pinmux + const: ralink,mt7621-pinctrl patternProperties: '-pins$': @@ -28,14 +30,15 @@ patternProperties: properties: groups: - description: Name of the pin group to use for the functions. - enum: [i2c, jtag, mdio, pcie, rgmii1, rgmii2, sdhci, spi, - uart1, uart2, uart3, wdt] + description: The pin group to select. + enum: [i2c, jtag, mdio, pcie, rgmii1, rgmii2, sdhci, spi, uart1, + uart2, uart3, wdt] + function: - description: The mux function to select + description: The mux function to select. enum: [gpio, i2c, i2s, jtag, mdio, nand1, nand2, pcie refclk, - pcie rst, pcm, rgmii1, rgmii2, sdhci, spdif2, spdif3, - spi, uart1, uart2, uart3, wdt refclk, wdt rst] + pcie rst, pcm, rgmii1, rgmii2, sdhci, spdif2, spdif3, spi, + uart1, uart2, uart3, wdt refclk, wdt rst] required: - groups @@ -57,7 +60,7 @@ examples: # Pinmux controller node - | pinctrl { - compatible = "ralink,rt2880-pinmux"; + compatible = "ralink,mt7621-pinctrl"; i2c_pins: i2c0-pins { pinmux { diff --git a/Documentation/devicetree/bindings/pinctrl/ralink,rt2880-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/ralink,rt2880-pinctrl.yaml new file mode 100644 index 000000000000..56e5becabcfd --- /dev/null +++ b/Documentation/devicetree/bindings/pinctrl/ralink,rt2880-pinctrl.yaml @@ -0,0 +1,68 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/pinctrl/ralink,rt2880-pinctrl.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Ralink RT2880 Pin Controller + +maintainers: + - Arınç ÃœNAL <arinc.unal@arinc9.com> + - Sergio Paracuellos <sergio.paracuellos@gmail.com> + +description: + Ralink RT2880 pin controller for RT2880 SoC. + The pin controller can only set the muxing of pin groups. Muxing individual + pins is not supported. There is no pinconf support. + +properties: + compatible: + const: ralink,rt2880-pinctrl + +patternProperties: + '-pins$': + type: object + patternProperties: + '^(.*-)?pinmux$': + type: object + description: node for pinctrl. + $ref: pinmux-node.yaml# + + properties: + groups: + description: The pin group to select. + enum: [i2c, spi, uartlite, jtag, mdio, sdram, pci] + + function: + description: The mux function to select. + enum: [gpio, i2c, spi, uartlite, jtag, mdio, sdram, pci] + + required: + - groups + - function + + additionalProperties: false + + additionalProperties: false + +allOf: + - $ref: "pinctrl.yaml#" + +required: + - compatible + +additionalProperties: false + +examples: + # Pinmux controller node + - | + pinctrl { + compatible = "ralink,rt2880-pinctrl"; + + i2c_pins: i2c0-pins { + pinmux { + groups = "i2c"; + function = "i2c"; + }; + }; + }; diff --git a/Documentation/devicetree/bindings/pinctrl/ralink,rt305x-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/ralink,rt305x-pinctrl.yaml new file mode 100644 index 000000000000..425401c54269 --- /dev/null +++ b/Documentation/devicetree/bindings/pinctrl/ralink,rt305x-pinctrl.yaml @@ -0,0 +1,92 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/pinctrl/ralink,rt305x-pinctrl.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Ralink RT305X Pin Controller + +maintainers: + - Arınç ÃœNAL <arinc.unal@arinc9.com> + - Sergio Paracuellos <sergio.paracuellos@gmail.com> + +description: + Ralink RT305X pin controller for RT3050, RT3052, RT3350, RT3352 and RT5350 + SoCs. + The pin controller can only set the muxing of pin groups. Muxing individual + pins is not supported. There is no pinconf support. + +properties: + compatible: + const: ralink,rt305x-pinctrl + +patternProperties: + '-pins$': + type: object + patternProperties: + '^(.*-)?pinmux$': + type: object + description: node for pinctrl. + $ref: pinmux-node.yaml# + + properties: + groups: + description: The pin group to select. + enum: [ + # For RT3050, RT3052 and RT3350 SoCs + i2c, jtag, mdio, rgmii, sdram, spi, uartf, uartlite, + + # For RT3352 SoC + i2c, jtag, led, lna, mdio, pa, rgmii, spi, spi_cs1, uartf, + uartlite, + + # For RT5350 SoC + i2c, jtag, led, spi, spi_cs1, uartf, uartlite, + ] + + function: + description: The mux function to select. + enum: [ + # For RT3050, RT3052 and RT3350 SoCs + gpio, gpio i2s, gpio uartf, i2c, i2s uartf, jtag, mdio, pcm gpio, + pcm i2s, pcm uartf, rgmii, sdram, spi, uartf, uartlite, + + # For RT3352 SoC + gpio, gpio i2s, gpio uartf, i2c, i2s uartf, jtag, led, lna, mdio, + pa, pcm gpio, pcm i2s, pcm uartf, rgmii, spi, spi_cs1, uartf, + uartlite, wdg_cs1, + + # For RT5350 SoC + gpio, gpio i2s, gpio uartf, i2c, i2s uartf, jtag, led, pcm gpio, + pcm i2s, pcm uartf, spi, spi_cs1, uartf, uartlite, wdg_cs1, + ] + + required: + - groups + - function + + additionalProperties: false + + additionalProperties: false + +allOf: + - $ref: "pinctrl.yaml#" + +required: + - compatible + +additionalProperties: false + +examples: + # Pinmux controller node + - | + pinctrl { + compatible = "ralink,rt305x-pinctrl"; + + i2c_pins: i2c0-pins { + pinmux { + groups = "i2c"; + function = "i2c"; + }; + }; + }; diff --git a/Documentation/devicetree/bindings/pinctrl/ralink,rt3883-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/ralink,rt3883-pinctrl.yaml new file mode 100644 index 000000000000..feb6e66dcb61 --- /dev/null +++ b/Documentation/devicetree/bindings/pinctrl/ralink,rt3883-pinctrl.yaml @@ -0,0 +1,71 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/pinctrl/ralink,rt3883-pinctrl.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Ralink RT3883 Pin Controller + +maintainers: + - Arınç ÃœNAL <arinc.unal@arinc9.com> + - Sergio Paracuellos <sergio.paracuellos@gmail.com> + +description: + Ralink RT3883 pin controller for RT3883 SoC. + The pin controller can only set the muxing of pin groups. Muxing individual + pins is not supported. There is no pinconf support. + +properties: + compatible: + const: ralink,rt3883-pinctrl + +patternProperties: + '-pins$': + type: object + patternProperties: + '^(.*-)?pinmux$': + type: object + description: node for pinctrl. + $ref: pinmux-node.yaml# + + properties: + groups: + description: The pin group to select. + enum: [ge1, ge2, i2c, jtag, lna a, lna g, mdio, pci, spi, uartf, + uartlite] + + function: + description: The mux function to select. + enum: [ge1, ge2, gpio, gpio i2s, gpio uartf, i2c, i2s uartf, jtag, + lna a, lna g, mdio, pci-dev, pci-fnc, pci-host1, pci-host2, + pcm gpio, pcm i2s, pcm uartf, spi, uartf, uartlite] + + required: + - groups + - function + + additionalProperties: false + + additionalProperties: false + +allOf: + - $ref: "pinctrl.yaml#" + +required: + - compatible + +additionalProperties: false + +examples: + # Pinmux controller node + - | + pinctrl { + compatible = "ralink,rt3883-pinctrl"; + + i2c_pins: i2c0-pins { + pinmux { + groups = "i2c"; + function = "i2c"; + }; + }; + }; diff --git a/Documentation/devicetree/bindings/pinctrl/renesas,rzg2l-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/renesas,rzg2l-pinctrl.yaml index 9ccf54870aa4..52df1b146174 100644 --- a/Documentation/devicetree/bindings/pinctrl/renesas,rzg2l-pinctrl.yaml +++ b/Documentation/devicetree/bindings/pinctrl/renesas,rzg2l-pinctrl.yaml @@ -11,8 +11,8 @@ maintainers: - Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com> description: - The Renesas SoCs of the RZ/{G2L,V2L} series feature a combined Pin and GPIO - controller. + The Renesas SoCs of the RZ/{G2L,V2L} alike series feature a combined Pin and + GPIO controller. Pin multiplexing and GPIO configuration is performed on a per-pin basis. Each port features up to 8 pins, each of them configurable for GPIO function (port mode) or in alternate function mode. @@ -23,6 +23,7 @@ properties: oneOf: - items: - enum: + - renesas,r9a07g043-pinctrl # RZ/G2UL{Type-1,Type-2} - renesas,r9a07g044-pinctrl # RZ/G2{L,LC} - items: diff --git a/Documentation/devicetree/bindings/pinctrl/rockchip,pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/rockchip,pinctrl.yaml index b0eae3a67ab1..677a285ca416 100644 --- a/Documentation/devicetree/bindings/pinctrl/rockchip,pinctrl.yaml +++ b/Documentation/devicetree/bindings/pinctrl/rockchip,pinctrl.yaml @@ -33,6 +33,7 @@ properties: enum: - rockchip,px30-pinctrl - rockchip,rk2928-pinctrl + - rockchip,rk3036-pinctrl - rockchip,rk3066a-pinctrl - rockchip,rk3066b-pinctrl - rockchip,rk3128-pinctrl @@ -44,6 +45,7 @@ properties: - rockchip,rk3368-pinctrl - rockchip,rk3399-pinctrl - rockchip,rk3568-pinctrl + - rockchip,rk3588-pinctrl - rockchip,rv1108-pinctrl rockchip,grf: @@ -129,7 +131,7 @@ additionalProperties: description: Pin bank index. - minimum: 0 - maximum: 6 + maximum: 10 description: Mux 0 means GPIO and mux 1 to N means the specific device function. diff --git a/Documentation/devicetree/bindings/powerpc/fsl/cache_sram.txt b/Documentation/devicetree/bindings/powerpc/fsl/cache_sram.txt deleted file mode 100644 index 781955f5217d..000000000000 --- a/Documentation/devicetree/bindings/powerpc/fsl/cache_sram.txt +++ /dev/null @@ -1,20 +0,0 @@ -* Freescale PQ3 and QorIQ based Cache SRAM - -Freescale's mpc85xx and some QorIQ platforms provide an -option of configuring a part of (or full) cache memory -as SRAM. This cache SRAM representation in the device -tree should be done as under:- - -Required properties: - -- compatible : should be "fsl,p2020-cache-sram" -- fsl,cache-sram-ctlr-handle : points to the L2 controller -- reg : offset and length of the cache-sram. - -Example: - -cache-sram@fff00000 { - fsl,cache-sram-ctlr-handle = <&L2>; - reg = <0 0xfff00000 0 0x10000>; - compatible = "fsl,p2020-cache-sram"; -}; diff --git a/Documentation/devicetree/bindings/pwm/atmel,at91sam-pwm.yaml b/Documentation/devicetree/bindings/pwm/atmel,at91sam-pwm.yaml new file mode 100644 index 000000000000..ab45df80345d --- /dev/null +++ b/Documentation/devicetree/bindings/pwm/atmel,at91sam-pwm.yaml @@ -0,0 +1,47 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +# Copyright (C) 2022 Microchip Technology, Inc. and its subsidiaries +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/pwm/atmel,at91sam-pwm.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Atmel/Microchip PWM controller + +maintainers: + - Claudiu Beznea <claudiu.beznea@microchip.com> + +allOf: + - $ref: "pwm.yaml#" + +properties: + compatible: + oneOf: + - items: + - enum: + - atmel,at91sam9rl-pwm + - atmel,sama5d3-pwm + - atmel,sama5d2-pwm + - microchip,sam9x60-pwm + - items: + - const: microchip,sama7g5-pwm + - const: atmel,sama5d2-pwm + + reg: + maxItems: 1 + + "#pwm-cells": + const: 3 + +required: + - compatible + - reg + +unevaluatedProperties: false + +examples: + - | + pwm0: pwm@f8034000 { + compatible = "atmel,at91sam9rl-pwm"; + reg = <0xf8034000 0x400>; + #pwm-cells = <3>; + }; diff --git a/Documentation/devicetree/bindings/pwm/atmel-pwm.txt b/Documentation/devicetree/bindings/pwm/atmel-pwm.txt deleted file mode 100644 index fbb5325be1f0..000000000000 --- a/Documentation/devicetree/bindings/pwm/atmel-pwm.txt +++ /dev/null @@ -1,35 +0,0 @@ -Atmel PWM controller - -Required properties: - - compatible: should be one of: - - "atmel,at91sam9rl-pwm" - - "atmel,sama5d3-pwm" - - "atmel,sama5d2-pwm" - - "microchip,sam9x60-pwm" - - reg: physical base address and length of the controller's registers - - #pwm-cells: Should be 3. See pwm.yaml in this directory for a - description of the cells format. - -Example: - - pwm0: pwm@f8034000 { - compatible = "atmel,at91sam9rl-pwm"; - reg = <0xf8034000 0x400>; - #pwm-cells = <3>; - }; - - pwmleds { - compatible = "pwm-leds"; - - d1 { - label = "d1"; - pwms = <&pwm0 3 5000 0> - max-brightness = <255>; - }; - - d2 { - label = "d2"; - pwms = <&pwm0 1 5000 1> - max-brightness = <255>; - }; - }; diff --git a/Documentation/devicetree/bindings/pwm/google,cros-ec-pwm.yaml b/Documentation/devicetree/bindings/pwm/google,cros-ec-pwm.yaml index 7ab6912a845f..c8577bdf6c94 100644 --- a/Documentation/devicetree/bindings/pwm/google,cros-ec-pwm.yaml +++ b/Documentation/devicetree/bindings/pwm/google,cros-ec-pwm.yaml @@ -21,7 +21,14 @@ allOf: properties: compatible: - const: google,cros-ec-pwm + oneOf: + - description: PWM controlled using EC_PWM_TYPE_GENERIC channels. + items: + - const: google,cros-ec-pwm + - description: PWM controlled using CROS_EC_PWM_DT_<...> types. + items: + - const: google,cros-ec-pwm-type + "#pwm-cells": description: The cell specifies the PWM index. const: 1 diff --git a/Documentation/devicetree/bindings/pwm/mediatek,pwm-disp.yaml b/Documentation/devicetree/bindings/pwm/mediatek,pwm-disp.yaml new file mode 100644 index 000000000000..e4fe2d1bfef5 --- /dev/null +++ b/Documentation/devicetree/bindings/pwm/mediatek,pwm-disp.yaml @@ -0,0 +1,75 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/pwm/mediatek,pwm-disp.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: MediaTek DISP_PWM Controller Device Tree Bindings + +maintainers: + - Jitao Shi <jitao.shi@mediatek.com> + - Xinlei Lee <xinlei.lee@mediatek.com> + +allOf: + - $ref: pwm.yaml# + +properties: + compatible: + oneOf: + - enum: + - mediatek,mt2701-disp-pwm + - mediatek,mt6595-disp-pwm + - mediatek,mt8173-disp-pwm + - mediatek,mt8183-disp-pwm + - items: + - const: mediatek,mt8167-disp-pwm + - const: mediatek,mt8173-disp-pwm + - items: + - enum: + - mediatek,mt8186-disp-pwm + - mediatek,mt8192-disp-pwm + - mediatek,mt8195-disp-pwm + - const: mediatek,mt8183-disp-pwm + + reg: + maxItems: 1 + + "#pwm-cells": + const: 2 + + interrupts: + maxItems: 1 + + clocks: + items: + - description: Main Clock + - description: Mm Clock + + clock-names: + items: + - const: main + - const: mm + +required: + - compatible + - reg + - "#pwm-cells" + - clocks + - clock-names + +additionalProperties: false + +examples: + - | + #include <dt-bindings/interrupt-controller/arm-gic.h> + #include <dt-bindings/clock/mt8173-clk.h> + #include <dt-bindings/interrupt-controller/irq.h> + + pwm0: pwm@1401e000 { + compatible = "mediatek,mt8173-disp-pwm"; + reg = <0x1401e000 0x1000>; + #pwm-cells = <2>; + clocks = <&mmsys CLK_MM_DISP_PWM026M>, + <&mmsys CLK_MM_DISP_PWM0MM>; + clock-names = "main", "mm"; + }; diff --git a/Documentation/devicetree/bindings/pwm/pwm-mediatek.txt b/Documentation/devicetree/bindings/pwm/pwm-mediatek.txt index 25ed214473d7..033d1fc0f405 100644 --- a/Documentation/devicetree/bindings/pwm/pwm-mediatek.txt +++ b/Documentation/devicetree/bindings/pwm/pwm-mediatek.txt @@ -3,6 +3,7 @@ MediaTek PWM controller Required properties: - compatible: should be "mediatek,<name>-pwm": - "mediatek,mt2712-pwm": found on mt2712 SoC. + - "mediatek,mt6795-pwm": found on mt6795 SoC. - "mediatek,mt7622-pwm": found on mt7622 SoC. - "mediatek,mt7623-pwm": found on mt7623 SoC. - "mediatek,mt7628-pwm": found on mt7628 SoC. diff --git a/Documentation/devicetree/bindings/pwm/pwm-mtk-disp.txt b/Documentation/devicetree/bindings/pwm/pwm-mtk-disp.txt deleted file mode 100644 index 691e58b6c223..000000000000 --- a/Documentation/devicetree/bindings/pwm/pwm-mtk-disp.txt +++ /dev/null @@ -1,45 +0,0 @@ -MediaTek display PWM controller - -Required properties: - - compatible: should be "mediatek,<name>-disp-pwm": - - "mediatek,mt2701-disp-pwm": found on mt2701 SoC. - - "mediatek,mt6595-disp-pwm": found on mt6595 SoC. - - "mediatek,mt8167-disp-pwm", "mediatek,mt8173-disp-pwm": found on mt8167 SoC. - - "mediatek,mt8173-disp-pwm": found on mt8173 SoC. - - "mediatek,mt8183-disp-pwm": found on mt8183 SoC.$ - - reg: physical base address and length of the controller's registers. - - #pwm-cells: must be 2. See pwm.yaml in this directory for a description of - the cell format. - - clocks: phandle and clock specifier of the PWM reference clock. - - clock-names: must contain the following: - - "main": clock used to generate PWM signals. - - "mm": sync signals from the modules of mmsys. - - pinctrl-names: Must contain a "default" entry. - - pinctrl-0: One property must exist for each entry in pinctrl-names. - See pinctrl/pinctrl-bindings.txt for details of the property values. - -Example: - pwm0: pwm@1401e000 { - compatible = "mediatek,mt8173-disp-pwm", - "mediatek,mt6595-disp-pwm"; - reg = <0 0x1401e000 0 0x1000>; - #pwm-cells = <2>; - clocks = <&mmsys CLK_MM_DISP_PWM026M>, - <&mmsys CLK_MM_DISP_PWM0MM>; - clock-names = "main", "mm"; - pinctrl-names = "default"; - pinctrl-0 = <&disp_pwm0_pins>; - }; - - backlight_lcd: backlight_lcd { - compatible = "pwm-backlight"; - pwms = <&pwm0 0 1000000>; - brightness-levels = < - 0 16 32 48 64 80 96 112 - 128 144 160 176 192 208 224 240 - 255 - >; - default-brightness-level = <9>; - power-supply = <&mt6397_vio18_reg>; - enable-gpios = <&pio 95 GPIO_ACTIVE_HIGH>; - }; diff --git a/Documentation/devicetree/bindings/pwm/sunplus,sp7021-pwm.yaml b/Documentation/devicetree/bindings/pwm/sunplus,sp7021-pwm.yaml new file mode 100644 index 000000000000..d4fc9e8db1d1 --- /dev/null +++ b/Documentation/devicetree/bindings/pwm/sunplus,sp7021-pwm.yaml @@ -0,0 +1,42 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +# Copyright (C) Sunplus Co., Ltd. 2021 +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/pwm/sunplus,sp7021-pwm.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Sunplus SoC SP7021 PWM Controller + +maintainers: + - Hammer Hsieh <hammerh0314@gmail.com> + +allOf: + - $ref: pwm.yaml# + +properties: + compatible: + const: sunplus,sp7021-pwm + + reg: + maxItems: 1 + + clocks: + maxItems: 1 + + '#pwm-cells': + const: 2 + +unevaluatedProperties: false + +required: + - reg + - clocks + +examples: + - | + pwm: pwm@9c007a00 { + compatible = "sunplus,sp7021-pwm"; + reg = <0x9c007a00 0x80>; + clocks = <&clkc 0xa2>; + #pwm-cells = <2>; + }; diff --git a/Documentation/devicetree/bindings/remoteproc/fsl,imx-rproc.yaml b/Documentation/devicetree/bindings/remoteproc/fsl,imx-rproc.yaml index fc16d903353e..3a1f59ad79e2 100644 --- a/Documentation/devicetree/bindings/remoteproc/fsl,imx-rproc.yaml +++ b/Documentation/devicetree/bindings/remoteproc/fsl,imx-rproc.yaml @@ -15,14 +15,15 @@ maintainers: properties: compatible: enum: - - fsl,imx8mq-cm4 + - fsl,imx6sx-cm4 + - fsl,imx7d-cm4 + - fsl,imx7ulp-cm4 - fsl,imx8mm-cm4 - fsl,imx8mn-cm7 - fsl,imx8mp-cm7 + - fsl,imx8mq-cm4 - fsl,imx8ulp-cm33 - - fsl,imx7d-cm4 - - fsl,imx7ulp-cm4 - - fsl,imx6sx-cm4 + - fsl,imx93-cm33 clocks: maxItems: 1 diff --git a/Documentation/devicetree/bindings/remoteproc/mtk,scp.yaml b/Documentation/devicetree/bindings/remoteproc/mtk,scp.yaml index 5b693a2d049c..eec3b9c4c713 100644 --- a/Documentation/devicetree/bindings/remoteproc/mtk,scp.yaml +++ b/Documentation/devicetree/bindings/remoteproc/mtk,scp.yaml @@ -23,11 +23,13 @@ properties: reg: description: - Should contain the address ranges for memory regions SRAM, CFG, and - L1TCM. + Should contain the address ranges for memory regions SRAM, CFG, and, + on some platforms, L1TCM. + minItems: 2 maxItems: 3 reg-names: + minItems: 2 items: - const: sram - const: cfg @@ -42,21 +44,48 @@ properties: clock-names: const: main + interrupts: + maxItems: 1 + + firmware-name: + $ref: /schemas/types.yaml#/definitions/string + description: + If present, name (or relative path) of the file within the + firmware search path containing the firmware image used when + initializing SCP. + + memory-region: + maxItems: 1 + required: - compatible - reg - reg-names -if: - properties: - compatible: - enum: - - mediatek,mt8183-scp - - mediatek,mt8192-scp -then: - required: - - clocks - - clock-names +allOf: + - if: + properties: + compatible: + enum: + - mediatek,mt8183-scp + - mediatek,mt8192-scp + then: + required: + - clocks + - clock-names + + - if: + properties: + compatible: + enum: + - mediatek,mt8183-scp + - mediatek,mt8186-scp + then: + properties: + reg: + maxItems: 2 + reg-names: + maxItems: 2 additionalProperties: type: object @@ -76,10 +105,10 @@ additionalProperties: examples: - | - #include <dt-bindings/clock/mt8183-clk.h> + #include <dt-bindings/clock/mt8192-clk.h> scp@10500000 { - compatible = "mediatek,mt8183-scp"; + compatible = "mediatek,mt8192-scp"; reg = <0x10500000 0x80000>, <0x10700000 0x8000>, <0x10720000 0xe0000>; diff --git a/Documentation/devicetree/bindings/remoteproc/qcom,adsp.yaml b/Documentation/devicetree/bindings/remoteproc/qcom,adsp.yaml index a4409c398193..947f94548d0e 100644 --- a/Documentation/devicetree/bindings/remoteproc/qcom,adsp.yaml +++ b/Documentation/devicetree/bindings/remoteproc/qcom,adsp.yaml @@ -16,6 +16,7 @@ description: properties: compatible: enum: + - qcom,msm8226-adsp-pil - qcom,msm8974-adsp-pil - qcom,msm8996-adsp-pil - qcom,msm8996-slpi-pil @@ -29,6 +30,9 @@ properties: - qcom,sc8180x-adsp-pas - qcom,sc8180x-cdsp-pas - qcom,sc8180x-mpss-pas + - qcom,sc8280xp-adsp-pas + - qcom,sc8280xp-nsp0-pas + - qcom,sc8280xp-nsp1-pas - qcom,sdm660-adsp-pas - qcom,sdm845-adsp-pas - qcom,sdm845-cdsp-pas @@ -159,6 +163,7 @@ allOf: compatible: contains: enum: + - qcom,msm8226-adsp-pil - qcom,msm8974-adsp-pil - qcom,msm8996-adsp-pil - qcom,msm8996-slpi-pil @@ -169,6 +174,9 @@ allOf: - qcom,sc8180x-adsp-pas - qcom,sc8180x-cdsp-pas - qcom,sc8180x-mpss-pas + - qcom,sc8280xp-adsp-pas + - qcom,sc8280xp-nsp0-pas + - qcom,sc8280xp-nsp1-pas - qcom,sdm845-adsp-pas - qcom,sdm845-cdsp-pas - qcom,sm6350-adsp-pas @@ -274,6 +282,7 @@ allOf: compatible: contains: enum: + - qcom,msm8226-adsp-pil - qcom,msm8974-adsp-pil - qcom,msm8996-adsp-pil - qcom,msm8996-slpi-pil @@ -284,6 +293,9 @@ allOf: - qcom,qcs404-wcss-pas - qcom,sc8180x-adsp-pas - qcom,sc8180x-cdsp-pas + - qcom,sc8280xp-adsp-pas + - qcom,sc8280xp-nsp0-pas + - qcom,sc8280xp-nsp1-pas - qcom,sdm845-adsp-pas - qcom,sdm845-cdsp-pas - qcom,sm6350-adsp-pas @@ -364,6 +376,7 @@ allOf: compatible: contains: enum: + - qcom,msm8226-adsp-pil - qcom,msm8996-adsp-pil - qcom,msm8998-adsp-pas then: @@ -471,6 +484,7 @@ allOf: enum: - qcom,sc8180x-adsp-pas - qcom,sc8180x-cdsp-pas + - qcom,sc8280xp-adsp-pas - qcom,sm6350-adsp-pas - qcom,sm8150-slpi-pas - qcom,sm8250-adsp-pas @@ -513,6 +527,22 @@ allOf: compatible: contains: enum: + - qcom,sc8280xp-nsp0-pas + - qcom,sc8280xp-nsp1-pas + then: + properties: + power-domains: + items: + - description: NSP power domain + power-domain-names: + items: + - const: nsp + + - if: + properties: + compatible: + contains: + enum: - qcom,qcs404-cdsp-pas then: properties: @@ -546,6 +576,7 @@ allOf: compatible: contains: enum: + - qcom,msm8226-adsp-pil - qcom,msm8974-adsp-pil - qcom,msm8996-adsp-pil - qcom,msm8996-slpi-pil diff --git a/Documentation/devicetree/bindings/remoteproc/st,stm32-rproc.yaml b/Documentation/devicetree/bindings/remoteproc/st,stm32-rproc.yaml index be3d9b0e876b..da50f0e99fe2 100644 --- a/Documentation/devicetree/bindings/remoteproc/st,stm32-rproc.yaml +++ b/Documentation/devicetree/bindings/remoteproc/st,stm32-rproc.yaml @@ -43,8 +43,8 @@ properties: items: - items: - description: Phandle of syscon block - - description: FIXME - - description: FIXME + - description: The offset of the trust zone setting register + - description: The field mask of the trust zone state interrupts: description: Should contain the WWDG1 watchdog reset interrupt @@ -101,8 +101,8 @@ properties: items: - items: - description: Phandle of syscon block - - description: FIXME - - description: FIXME + - description: The offset of the power setting register + - description: The field mask of the PDDS selection st,syscfg-m4-state: $ref: "/schemas/types.yaml#/definitions/phandle-array" @@ -111,8 +111,8 @@ properties: items: - items: - description: Phandle of syscon block with the tamp register - - description: FIXME - - description: FIXME + - description: The offset of the tamp register + - description: The field mask of the Cortex-M4 state st,syscfg-rsc-tbl: $ref: "/schemas/types.yaml#/definitions/phandle-array" @@ -122,8 +122,8 @@ properties: items: - items: - description: Phandle of syscon block with the tamp register - - description: FIXME - - description: FIXME + - description: The offset of the tamp register + - description: The field mask of the Cortex-M4 resource table address st,auto-boot: $ref: /schemas/types.yaml#/definitions/flag diff --git a/Documentation/devicetree/bindings/rtc/nxp,pcf85063.txt b/Documentation/devicetree/bindings/rtc/nxp,pcf85063.txt index 6439682c9319..217b7cd06c11 100644 --- a/Documentation/devicetree/bindings/rtc/nxp,pcf85063.txt +++ b/Documentation/devicetree/bindings/rtc/nxp,pcf85063.txt @@ -2,6 +2,7 @@ Required properties: - compatible: Should one of contain: + "nxp,pca85073a", "nxp,pcf85063", "nxp,pcf85063a", "nxp,pcf85063tp", diff --git a/Documentation/devicetree/bindings/rtc/renesas,rzn1-rtc.yaml b/Documentation/devicetree/bindings/rtc/renesas,rzn1-rtc.yaml new file mode 100644 index 000000000000..2d4741f51663 --- /dev/null +++ b/Documentation/devicetree/bindings/rtc/renesas,rzn1-rtc.yaml @@ -0,0 +1,70 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/rtc/renesas,rzn1-rtc.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Renesas RZ/N1 SoCs Real-Time Clock DT bindings + +maintainers: + - Miquel Raynal <miquel.raynal@bootlin.com> + +allOf: + - $ref: rtc.yaml# + +properties: + compatible: + items: + - enum: + - renesas,r9a06g032-rtc + - const: renesas,rzn1-rtc + + reg: + maxItems: 1 + + interrupts: + minItems: 3 + maxItems: 3 + + interrupt-names: + items: + - const: alarm + - const: timer + - const: pps + + clocks: + maxItems: 1 + + clock-names: + const: hclk + + power-domains: + maxItems: 1 + +required: + - compatible + - reg + - interrupts + - interrupt-names + - clocks + - clock-names + - power-domains + +unevaluatedProperties: false + +examples: + - | + #include <dt-bindings/interrupt-controller/arm-gic.h> + #include <dt-bindings/clock/r9a06g032-sysctrl.h> + rtc@40006000 { + compatible = "renesas,r9a06g032-rtc", "renesas,rzn1-rtc"; + reg = <0x40006000 0x1000>; + interrupts = <GIC_SPI 66 IRQ_TYPE_EDGE_RISING>, + <GIC_SPI 67 IRQ_TYPE_EDGE_RISING>, + <GIC_SPI 68 IRQ_TYPE_EDGE_RISING>; + interrupt-names = "alarm", "timer", "pps"; + clocks = <&sysctrl R9A06G032_HCLK_RTC>; + clock-names = "hclk"; + power-domains = <&sysctrl>; + start-year = <2000>; + }; diff --git a/Documentation/devicetree/bindings/soc/qcom/qcom,smd-rpm.yaml b/Documentation/devicetree/bindings/soc/qcom/qcom,smd-rpm.yaml index 2a4b6c06e7c9..f0f1bf06aea6 100644 --- a/Documentation/devicetree/bindings/soc/qcom/qcom,smd-rpm.yaml +++ b/Documentation/devicetree/bindings/soc/qcom/qcom,smd-rpm.yaml @@ -47,6 +47,10 @@ properties: - qcom,rpm-qcm2290 - qcom,rpm-qcs404 + clock-controller: + $ref: /schemas/clock/qcom,rpmcc.yaml# + unevaluatedProperties: false + qcom,smd-channels: $ref: /schemas/types.yaml#/definitions/string-array description: Channel name used for the RPM communication diff --git a/Documentation/devicetree/bindings/timer/xlnx,xps-timer.yaml b/Documentation/devicetree/bindings/timer/xlnx,xps-timer.yaml new file mode 100644 index 000000000000..dd168d41d2e0 --- /dev/null +++ b/Documentation/devicetree/bindings/timer/xlnx,xps-timer.yaml @@ -0,0 +1,92 @@ +# SPDX-License-Identifier: GPL-2.0 OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/timer/xlnx,xps-timer.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Xilinx LogiCORE IP AXI Timer Device Tree Binding + +maintainers: + - Sean Anderson <sean.anderson@seco.com> + +properties: + compatible: + contains: + const: xlnx,xps-timer-1.00.a + + clocks: + maxItems: 1 + + clock-names: + const: s_axi_aclk + + interrupts: + maxItems: 1 + + reg: + maxItems: 1 + + '#pwm-cells': true + + xlnx,count-width: + $ref: /schemas/types.yaml#/definitions/uint32 + enum: [8, 16, 32] + default: 32 + description: + The width of the counter(s), in bits. + + xlnx,one-timer-only: + $ref: /schemas/types.yaml#/definitions/uint32 + enum: [ 0, 1 ] + description: + Whether only one timer is present in this block. + +required: + - compatible + - reg + - xlnx,one-timer-only + +allOf: + - if: + required: + - '#pwm-cells' + then: + allOf: + - required: + - clocks + - properties: + xlnx,one-timer-only: + const: 0 + else: + required: + - interrupts + - if: + required: + - clocks + then: + required: + - clock-names + +additionalProperties: false + +examples: + - | + timer@800e0000 { + clock-names = "s_axi_aclk"; + clocks = <&zynqmp_clk 71>; + compatible = "xlnx,xps-timer-1.00.a"; + reg = <0x800e0000 0x10000>; + interrupts = <0 39 2>; + xlnx,count-width = <16>; + xlnx,one-timer-only = <0x0>; + }; + + timer@800f0000 { + #pwm-cells = <0>; + clock-names = "s_axi_aclk"; + clocks = <&zynqmp_clk 71>; + compatible = "xlnx,xps-timer-1.00.a"; + reg = <0x800e0000 0x10000>; + xlnx,count-width = <32>; + xlnx,one-timer-only = <0x0>; + }; diff --git a/Documentation/devicetree/bindings/trivial-devices.yaml b/Documentation/devicetree/bindings/trivial-devices.yaml index 05f01f4acca8..6aafa71806a3 100644 --- a/Documentation/devicetree/bindings/trivial-devices.yaml +++ b/Documentation/devicetree/bindings/trivial-devices.yaml @@ -47,7 +47,9 @@ properties: - at,24c08 # i2c trusted platform module (TPM) - atmel,at97sc3204t - # i2c h/w symmetric crypto module + # ATSHA204 - i2c h/w symmetric crypto module + - atmel,atsha204 + # ATSHA204A - i2c h/w symmetric crypto module - atmel,atsha204a # i2c h/w elliptic curve crypto module - atmel,atecc508a diff --git a/Documentation/devicetree/bindings/watchdog/da9062-wdt.txt b/Documentation/devicetree/bindings/watchdog/da9062-wdt.txt index 950e4fba8dbc..354314d854ef 100644 --- a/Documentation/devicetree/bindings/watchdog/da9062-wdt.txt +++ b/Documentation/devicetree/bindings/watchdog/da9062-wdt.txt @@ -10,6 +10,12 @@ Optional properties: - dlg,use-sw-pm: Add this property to disable the watchdog during suspend. Only use this option if you can't use the watchdog automatic suspend function during a suspend (see register CONTROL_B). +- dlg,wdt-sd: Set what happens on watchdog timeout. If this bit is set the + watchdog timeout triggers SHUTDOWN, if cleared the watchdog triggers + POWERDOWN. Can be 0 or 1. Only use this option if you want to change the + default chip's OTP setting for WATCHDOG_SD bit. If this property is NOT + set the WATCHDOG_SD bit and on timeout watchdog behavior will match the + chip's OTP settings. Example: DA9062 diff --git a/Documentation/devicetree/bindings/watchdog/faraday,ftwdt010.txt b/Documentation/devicetree/bindings/watchdog/faraday,ftwdt010.txt deleted file mode 100644 index 9ecdb502e605..000000000000 --- a/Documentation/devicetree/bindings/watchdog/faraday,ftwdt010.txt +++ /dev/null @@ -1,22 +0,0 @@ -Faraday Technology FTWDT010 watchdog - -This is an IP part from Faraday Technology found in the Gemini -SoCs and others. - -Required properties: -- compatible : must be one of - "faraday,ftwdt010" - "cortina,gemini-watchdog", "faraday,ftwdt010" -- reg : shall contain base register location and length -- interrupts : shall contain the interrupt for the watchdog - -Optional properties: -- timeout-sec : the default watchdog timeout in seconds. - -Example: - -watchdog@41000000 { - compatible = "faraday,ftwdt010"; - reg = <0x41000000 0x1000>; - interrupts = <3 IRQ_TYPE_LEVEL_HIGH>; -}; diff --git a/Documentation/devicetree/bindings/watchdog/faraday,ftwdt010.yaml b/Documentation/devicetree/bindings/watchdog/faraday,ftwdt010.yaml new file mode 100644 index 000000000000..ca9e1beff76b --- /dev/null +++ b/Documentation/devicetree/bindings/watchdog/faraday,ftwdt010.yaml @@ -0,0 +1,67 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/watchdog/faraday,ftwdt010.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Faraday Technology FTWDT010 watchdog + +maintainers: + - Linus Walleij <linus.walleij@linaro.org> + - Corentin Labbe <clabbe@baylibre.com> + +description: | + This is an IP part from Faraday Technology found in the Gemini + SoCs and others. + +allOf: + - $ref: "watchdog.yaml#" + +properties: + compatible: + oneOf: + - const: faraday,ftwdt010 + - items: + - enum: + - cortina,gemini-watchdog + - moxa,moxart-watchdog + - const: faraday,ftwdt010 + + reg: + maxItems: 1 + + resets: + maxItems: 1 + + clocks: + maxItems: 1 + + clock-names: + const: PCLK + + interrupts: + maxItems: 1 + +required: + - compatible + - reg + +unevaluatedProperties: false + +examples: + - | + #include <dt-bindings/interrupt-controller/irq.h> + watchdog@41000000 { + compatible = "faraday,ftwdt010"; + reg = <0x41000000 0x1000>; + interrupts = <3 IRQ_TYPE_LEVEL_HIGH>; + timeout-secs = <5>; + }; + - | + watchdog: watchdog@98500000 { + compatible = "moxa,moxart-watchdog", "faraday,ftwdt010"; + reg = <0x98500000 0x10>; + clocks = <&clk_apb>; + clock-names = "PCLK"; + }; +... diff --git a/Documentation/devicetree/bindings/watchdog/fsl-imx7ulp-wdt.yaml b/Documentation/devicetree/bindings/watchdog/fsl-imx7ulp-wdt.yaml index 4ca8a31359a5..8562978aa0c8 100644 --- a/Documentation/devicetree/bindings/watchdog/fsl-imx7ulp-wdt.yaml +++ b/Documentation/devicetree/bindings/watchdog/fsl-imx7ulp-wdt.yaml @@ -19,6 +19,7 @@ properties: - items: - const: fsl,imx8ulp-wdt - const: fsl,imx7ulp-wdt + - const: fsl,imx93-wdt reg: maxItems: 1 diff --git a/Documentation/devicetree/bindings/watchdog/mtk-wdt.txt b/Documentation/devicetree/bindings/watchdog/mtk-wdt.txt index a97418c74f6b..762c62e428ef 100644 --- a/Documentation/devicetree/bindings/watchdog/mtk-wdt.txt +++ b/Documentation/devicetree/bindings/watchdog/mtk-wdt.txt @@ -16,6 +16,7 @@ Required properties: "mediatek,mt7629-wdt", "mediatek,mt6589-wdt": for MT7629 "mediatek,mt7986-wdt", "mediatek,mt6589-wdt": for MT7986 "mediatek,mt8183-wdt": for MT8183 + "mediatek,mt8186-wdt", "mediatek,mt6589-wdt": for MT8186 "mediatek,mt8516-wdt", "mediatek,mt6589-wdt": for MT8516 "mediatek,mt8192-wdt": for MT8192 "mediatek,mt8195-wdt", "mediatek,mt6589-wdt": for MT8195 diff --git a/Documentation/devicetree/bindings/watchdog/qcom-wdt.yaml b/Documentation/devicetree/bindings/watchdog/qcom-wdt.yaml index 16c6f82a13ca..2bd6b4a52637 100644 --- a/Documentation/devicetree/bindings/watchdog/qcom-wdt.yaml +++ b/Documentation/devicetree/bindings/watchdog/qcom-wdt.yaml @@ -14,22 +14,29 @@ allOf: properties: compatible: - enum: - - qcom,apss-wdt-qcs404 - - qcom,apss-wdt-sc7180 - - qcom,apss-wdt-sc7280 - - qcom,apss-wdt-sdm845 - - qcom,apss-wdt-sdx55 - - qcom,apss-wdt-sm6350 - - qcom,apss-wdt-sm8150 - - qcom,apss-wdt-sm8250 - - qcom,kpss-timer - - qcom,kpss-wdt - - qcom,kpss-wdt-apq8064 - - qcom,kpss-wdt-ipq4019 - - qcom,kpss-wdt-ipq8064 - - qcom,kpss-wdt-msm8960 - - qcom,scss-timer + oneOf: + - items: + - enum: + - qcom,apss-wdt-qcs404 + - qcom,apss-wdt-sc7180 + - qcom,apss-wdt-sc7280 + - qcom,apss-wdt-sc8180x + - qcom,apss-wdt-sc8280xp + - qcom,apss-wdt-sdm845 + - qcom,apss-wdt-sdx55 + - qcom,apss-wdt-sm6350 + - qcom,apss-wdt-sm8150 + - qcom,apss-wdt-sm8250 + - const: qcom,kpss-wdt + - items: + - enum: + - qcom,kpss-wdt + - qcom,kpss-timer + - qcom,kpss-wdt-apq8064 + - qcom,kpss-wdt-ipq4019 + - qcom,kpss-wdt-ipq8064 + - qcom,kpss-wdt-msm8960 + - qcom,scss-timer reg: maxItems: 1 diff --git a/Documentation/devicetree/bindings/watchdog/renesas,wdt.yaml b/Documentation/devicetree/bindings/watchdog/renesas,wdt.yaml index d060438e1402..a8d7dde5271b 100644 --- a/Documentation/devicetree/bindings/watchdog/renesas,wdt.yaml +++ b/Documentation/devicetree/bindings/watchdog/renesas,wdt.yaml @@ -21,8 +21,15 @@ properties: - items: - enum: + - renesas,r9a06g032-wdt # RZ/N1D + - const: renesas,rzn1-wdt # RZ/N1 + + - items: + - enum: + - renesas,r9a07g043-wdt # RZ/G2UL - renesas,r9a07g044-wdt # RZ/G2{L,LC} - - const: renesas,rzg2l-wdt # RZ/G2L + - renesas,r9a07g054-wdt # RZ/V2L + - const: renesas,rzg2l-wdt - items: - enum: @@ -52,11 +59,11 @@ properties: - renesas,r8a77980-wdt # R-Car V3H - renesas,r8a77990-wdt # R-Car E3 - renesas,r8a77995-wdt # R-Car D3 - - renesas,r8a779a0-wdt # R-Car V3U - const: renesas,rcar-gen3-wdt # R-Car Gen3 and RZ/G2 - items: - enum: + - renesas,r8a779a0-wdt # R-Car V3U - renesas,r8a779f0-wdt # R-Car S4-8 - const: renesas,rcar-gen4-wdt # R-Car Gen4 @@ -94,6 +101,7 @@ allOf: contains: enum: - renesas,rza-wdt + - renesas,rzn1-wdt then: required: - power-domains diff --git a/Documentation/devicetree/bindings/watchdog/socionext,uniphier-wdt.yaml b/Documentation/devicetree/bindings/watchdog/socionext,uniphier-wdt.yaml index a059d16cb4f2..90698cfa8f94 100644 --- a/Documentation/devicetree/bindings/watchdog/socionext,uniphier-wdt.yaml +++ b/Documentation/devicetree/bindings/watchdog/socionext,uniphier-wdt.yaml @@ -19,7 +19,7 @@ properties: required: - compatible -additionalProperties: false +unevaluatedProperties: false examples: - | diff --git a/Documentation/devicetree/bindings/watchdog/sunplus,sp7021-wdt.yaml b/Documentation/devicetree/bindings/watchdog/sunplus,sp7021-wdt.yaml new file mode 100644 index 000000000000..d90271013191 --- /dev/null +++ b/Documentation/devicetree/bindings/watchdog/sunplus,sp7021-wdt.yaml @@ -0,0 +1,47 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +# Copyright (C) Sunplus Co., Ltd. 2021 +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/watchdog/sunplus,sp7021-wdt.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Sunplus SoCs Watchdog + +maintainers: + - XianTao Hu <xt.hu@cqplus1.com> + +allOf: + - $ref: watchdog.yaml# + +properties: + compatible: + const: sunplus,sp7021-wdt + + reg: + items: + - description: watchdog registers regions + - description: miscellaneous control registers regions + + clocks: + maxItems: 1 + + resets: + maxItems: 1 + +required: + - compatible + - reg + - clocks + - resets + +additionalProperties: false + +examples: + - | + watchdog: watchdog@9c000630 { + compatible = "sunplus,sp7021-wdt"; + reg = <0x9c000630 0x08>, <0x9c000274 0x04>; + clocks = <&clkc 0x24>; + resets = <&rstc 0x14>; + }; +... diff --git a/Documentation/driver-api/dmaengine/provider.rst b/Documentation/driver-api/dmaengine/provider.rst index 0072c9c7efd3..1e0f1f85d10e 100644 --- a/Documentation/driver-api/dmaengine/provider.rst +++ b/Documentation/driver-api/dmaengine/provider.rst @@ -206,6 +206,12 @@ Currently, the types available are: - The device is able to perform parity check using RAID6 P+Q algorithm against a memory buffer. +- DMA_MEMSET + + - The device is able to fill memory with the provided pattern + + - The pattern is treated as a single byte signed value. + - DMA_INTERRUPT - The device is able to trigger a dummy transfer that will @@ -457,7 +463,7 @@ supported. - Should use dma_set_residue to report it - In the case of a cyclic transfer, it should only take into - account the current period. + account the total size of the cyclic buffer. - Should return DMA_OUT_OF_ORDER if the device does not support in order completion and is completing the operation out of order. diff --git a/Documentation/driver-api/gpio/driver.rst b/Documentation/driver-api/gpio/driver.rst index a1ddefa1f55f..70ff43ac4fcc 100644 --- a/Documentation/driver-api/gpio/driver.rst +++ b/Documentation/driver-api/gpio/driver.rst @@ -429,7 +429,8 @@ call into the core gpiolib code: static void my_gpio_mask_irq(struct irq_data *d) { - struct gpio_chip *gc = irq_desc_get_handler_data(d); + struct gpio_chip *gc = irq_data_get_irq_chip_data(d); + irq_hw_number_t hwirq = irqd_to_hwirq(d); /* * Perform any necessary action to mask the interrupt, @@ -437,14 +438,15 @@ call into the core gpiolib code: * state. */ - gpiochip_disable_irq(gc, d->hwirq); + gpiochip_disable_irq(gc, hwirq); } static void my_gpio_unmask_irq(struct irq_data *d) { - struct gpio_chip *gc = irq_desc_get_handler_data(d); + struct gpio_chip *gc = irq_data_get_irq_chip_data(d); + irq_hw_number_t hwirq = irqd_to_hwirq(d); - gpiochip_enable_irq(gc, d->hwirq); + gpiochip_enable_irq(gc, hwirq); /* * Perform any necessary action to unmask the interrupt, @@ -501,7 +503,8 @@ the interrupt separately and go with it: static void my_gpio_mask_irq(struct irq_data *d) { - struct gpio_chip *gc = irq_desc_get_handler_data(d); + struct gpio_chip *gc = irq_data_get_irq_chip_data(d); + irq_hw_number_t hwirq = irqd_to_hwirq(d); /* * Perform any necessary action to mask the interrupt, @@ -509,14 +512,15 @@ the interrupt separately and go with it: * state. */ - gpiochip_disable_irq(gc, d->hwirq); + gpiochip_disable_irq(gc, hwirq); } static void my_gpio_unmask_irq(struct irq_data *d) { - struct gpio_chip *gc = irq_desc_get_handler_data(d); + struct gpio_chip *gc = irq_data_get_irq_chip_data(d); + irq_hw_number_t hwirq = irqd_to_hwirq(d); - gpiochip_enable_irq(gc, d->hwirq); + gpiochip_enable_irq(gc, hwirq); /* * Perform any necessary action to unmask the interrupt, @@ -576,7 +580,8 @@ In this case the typical set-up will look like this: static void my_gpio_mask_irq(struct irq_data *d) { - struct gpio_chip *gc = irq_desc_get_handler_data(d); + struct gpio_chip *gc = irq_data_get_irq_chip_data(d); + irq_hw_number_t hwirq = irqd_to_hwirq(d); /* * Perform any necessary action to mask the interrupt, @@ -584,15 +589,16 @@ In this case the typical set-up will look like this: * state. */ - gpiochip_disable_irq(gc, d->hwirq); + gpiochip_disable_irq(gc, hwirq); irq_mask_mask_parent(d); } static void my_gpio_unmask_irq(struct irq_data *d) { - struct gpio_chip *gc = irq_desc_get_handler_data(d); + struct gpio_chip *gc = irq_data_get_irq_chip_data(d); + irq_hw_number_t hwirq = irqd_to_hwirq(d); - gpiochip_enable_irq(gc, d->hwirq); + gpiochip_enable_irq(gc, hwirq); /* * Perform any necessary action to unmask the interrupt, diff --git a/Documentation/driver-api/pwm.rst b/Documentation/driver-api/pwm.rst index ccb06e485756..fd26c3d895b6 100644 --- a/Documentation/driver-api/pwm.rst +++ b/Documentation/driver-api/pwm.rst @@ -49,6 +49,12 @@ After being requested, a PWM has to be configured using:: This API controls both the PWM period/duty_cycle config and the enable/disable state. + +As a consumer, don't rely on the output's state for a disabled PWM. If it's +easily possible, drivers are supposed to emit the inactive state, but some +drivers cannot. If you rely on getting the inactive state, use .duty_cycle=0, +.enabled=true. + There is also a usage_power setting: If set, the PWM driver is only required to maintain the power output but has more freedom regarding signal form. If supported by the driver, the signal can be optimized, for example to improve diff --git a/Documentation/driver-api/vfio-mediated-device.rst b/Documentation/driver-api/vfio-mediated-device.rst index 784bbeb22adc..eded8719180f 100644 --- a/Documentation/driver-api/vfio-mediated-device.rst +++ b/Documentation/driver-api/vfio-mediated-device.rst @@ -262,10 +262,10 @@ Translation APIs for Mediated Devices The following APIs are provided for translating user pfn to host pfn in a VFIO driver:: - extern int vfio_pin_pages(struct device *dev, unsigned long *user_pfn, + int vfio_pin_pages(struct vfio_device *device, unsigned long *user_pfn, int npage, int prot, unsigned long *phys_pfn); - extern int vfio_unpin_pages(struct device *dev, unsigned long *user_pfn, + int vfio_unpin_pages(struct vfio_device *device, unsigned long *user_pfn, int npage); These functions call back into the back-end IOMMU module by using the pin_pages diff --git a/Documentation/filesystems/erofs.rst b/Documentation/filesystems/erofs.rst index bef6d3040ce4..05e03d54af1a 100644 --- a/Documentation/filesystems/erofs.rst +++ b/Documentation/filesystems/erofs.rst @@ -1,63 +1,82 @@ .. SPDX-License-Identifier: GPL-2.0 ====================================== -Enhanced Read-Only File System - EROFS +EROFS - Enhanced Read-Only File System ====================================== Overview ======== -EROFS file-system stands for Enhanced Read-Only File System. Different -from other read-only file systems, it aims to be designed for flexibility, -scalability, but be kept simple and high performance. +EROFS filesystem stands for Enhanced Read-Only File System. It aims to form a +generic read-only filesystem solution for various read-only use cases instead +of just focusing on storage space saving without considering any side effects +of runtime performance. -It is designed as a better filesystem solution for the following scenarios: +It is designed to meet the needs of flexibility, feature extendability and user +payload friendly, etc. Apart from those, it is still kept as a simple +random-access friendly high-performance filesystem to get rid of unneeded I/O +amplification and memory-resident overhead compared to similar approaches. + +It is implemented to be a better choice for the following scenarios: - read-only storage media or - part of a fully trusted read-only solution, which means it needs to be immutable and bit-for-bit identical to the official golden image for - their releases due to security and other considerations and + their releases due to security or other considerations and - hope to minimize extra storage space with guaranteed end-to-end performance by using compact layout, transparent file compression and direct access, especially for those embedded devices with limited memory and high-density - hosts with numerous containers; + hosts with numerous containers. Here is the main features of EROFS: - Little endian on-disk design; - - Currently 4KB block size (nobh) and therefore maximum 16TB address space; - - - Metadata & data could be mixed by design; + - 4KiB block size and 32-bit block addresses, therefore 16TiB address space + at most for now; - - 2 inode versions for different requirements: + - Two inode layouts for different requirements: - ===================== ============ ===================================== + ===================== ============ ====================================== compact (v1) extended (v2) - ===================== ============ ===================================== + ===================== ============ ====================================== Inode metadata size 32 bytes 64 bytes - Max file size 4 GB 16 EB (also limited by max. vol size) + Max file size 4 GiB 16 EiB (also limited by max. vol size) Max uids/gids 65536 4294967296 Per-inode timestamp no yes (64 + 32-bit timestamp) Max hardlinks 65536 4294967296 - Metadata reserved 4 bytes 14 bytes - ===================== ============ ===================================== + Metadata reserved 8 bytes 18 bytes + ===================== ============ ====================================== + + - Metadata and data could be mixed as an option; - Support extended attributes (xattrs) as an option; - - Support xattr inline and tail-end data inline for all files; + - Support tailpacking data and xattr inline compared to byte-addressed + unaligned metadata or smaller block size alternatives; - Support POSIX.1e ACLs by using xattrs; - Support transparent data compression as an option: - LZ4 algorithm with the fixed-sized output compression for high performance; + LZ4 and MicroLZMA algorithms can be used on a per-file basis; In addition, + inplace decompression is also supported to avoid bounce compressed buffers + and page cache thrashing. + + - Support direct I/O on uncompressed files to avoid double caching for loop + devices; - - Multiple device support for multi-layer container images. + - Support FSDAX on uncompressed images for secure containers and ramdisks in + order to get rid of unnecessary page cache. + + - Support multiple devices for multi blob container images; + + - Support file-based on-demand loading with the Fscache infrastructure. The following git tree provides the file system user-space tools under -development (ex, formatting tool mkfs.erofs): +development, such as a formatting tool (mkfs.erofs), an on-disk consistency & +compatibility checking tool (fsck.erofs), and a debugging tool (dump.erofs): - git://git.kernel.org/pub/scm/linux/kernel/git/xiang/erofs-utils.git @@ -91,6 +110,7 @@ dax={always,never} Use direct access (no page cache). See Documentation/filesystems/dax.rst. dax A legacy option which is an alias for ``dax=always``. device=%s Specify a path to an extra device to be used together. +fsid=%s Specify a filesystem image ID for Fscache back-end. =================== ========================================================= Sysfs Entries @@ -226,8 +246,8 @@ Note that apart from the offset of the first filename, nameoff0 also indicates the total number of directory entries in this block since it is no need to introduce another on-disk field at all. -Chunk-based file ----------------- +Chunk-based files +----------------- In order to support chunk-based data deduplication, a new inode data layout has been supported since Linux v5.15: Files are split in equal-sized data chunks with ``extents`` area of the inode metadata indicating how to get the chunk diff --git a/Documentation/filesystems/locking.rst b/Documentation/filesystems/locking.rst index 515bc48ab58b..c0fe711f14d3 100644 --- a/Documentation/filesystems/locking.rst +++ b/Documentation/filesystems/locking.rst @@ -258,8 +258,9 @@ prototypes:: int (*launder_folio)(struct folio *); bool (*is_partially_uptodate)(struct folio *, size_t from, size_t count); int (*error_remove_page)(struct address_space *, struct page *); - int (*swap_activate)(struct file *); + int (*swap_activate)(struct swap_info_struct *sis, struct file *f, sector_t *span) int (*swap_deactivate)(struct file *); + int (*swap_rw)(struct kiocb *iocb, struct iov_iter *iter); locking rules: All except dirty_folio and free_folio may block @@ -287,6 +288,7 @@ is_partially_uptodate: yes error_remove_page: yes swap_activate: no swap_deactivate: no +swap_rw: yes, unlocks ====================== ======================== ========= =============== ->write_begin(), ->write_end() and ->read_folio() may be called from @@ -386,15 +388,19 @@ cleaned, or an error value if not. Note that in order to prevent the folio getting mapped back in and redirtied, it needs to be kept locked across the entire operation. -->swap_activate will be called with a non-zero argument on -files backing (non block device backed) swapfiles. A return value -of zero indicates success, in which case this file can be used for -backing swapspace. The swapspace operations will be proxied to the -address space operations. +->swap_activate() will be called to prepare the given file for swap. It +should perform any validation and preparation necessary to ensure that +writes can be performed with minimal memory allocation. It should call +add_swap_extent(), or the helper iomap_swapfile_activate(), and return +the number of extents added. If IO should be submitted through +->swap_rw(), it should set SWP_FS_OPS, otherwise IO will be submitted +directly to the block device ``sis->bdev``. ->swap_deactivate() will be called in the sys_swapoff() path after ->swap_activate() returned success. +->swap_rw will be called for swap IO if SWP_FS_OPS was set by ->swap_activate(). + file_lock_operations ==================== @@ -428,6 +434,8 @@ prototypes:: void (*lm_break)(struct file_lock *); /* break_lease callback */ int (*lm_change)(struct file_lock **, int); bool (*lm_breaker_owns_lease)(struct file_lock *); + bool (*lm_lock_expirable)(struct file_lock *); + void (*lm_expire_lock)(void); locking rules: @@ -439,6 +447,8 @@ lm_grant: no no no lm_break: yes no no lm_change yes no no lm_breaker_owns_lease: yes no no +lm_lock_expirable yes no no +lm_expire_lock no no yes ====================== ============= ================= ========= buffer_head diff --git a/Documentation/filesystems/nfs/client-identifier.rst b/Documentation/filesystems/nfs/client-identifier.rst new file mode 100644 index 000000000000..5147e15815a1 --- /dev/null +++ b/Documentation/filesystems/nfs/client-identifier.rst @@ -0,0 +1,216 @@ +.. SPDX-License-Identifier: GPL-2.0 + +======================= +NFSv4 client identifier +======================= + +This document explains how the NFSv4 protocol identifies client +instances in order to maintain file open and lock state during +system restarts. A special identifier and principal are maintained +on each client. These can be set by administrators, scripts +provided by site administrators, or tools provided by Linux +distributors. + +There are risks if a client's NFSv4 identifier and its principal +are not chosen carefully. + + +Introduction +------------ + +The NFSv4 protocol uses "lease-based file locking". Leases help +NFSv4 servers provide file lock guarantees and manage their +resources. + +Simply put, an NFSv4 server creates a lease for each NFSv4 client. +The server collects each client's file open and lock state under +the lease for that client. + +The client is responsible for periodically renewing its leases. +While a lease remains valid, the server holding that lease +guarantees the file locks the client has created remain in place. + +If a client stops renewing its lease (for example, if it crashes), +the NFSv4 protocol allows the server to remove the client's open +and lock state after a certain period of time. When a client +restarts, it indicates to servers that open and lock state +associated with its previous leases is no longer valid and can be +destroyed immediately. + +In addition, each NFSv4 server manages a persistent list of client +leases. When the server restarts and clients attempt to recover +their state, the server uses this list to distinguish amongst +clients that held state before the server restarted and clients +sending fresh OPEN and LOCK requests. This enables file locks to +persist safely across server restarts. + +NFSv4 client identifiers +------------------------ + +Each NFSv4 client presents an identifier to NFSv4 servers so that +they can associate the client with its lease. Each client's +identifier consists of two elements: + + - co_ownerid: An arbitrary but fixed string. + + - boot verifier: A 64-bit incarnation verifier that enables a + server to distinguish successive boot epochs of the same client. + +The NFSv4.0 specification refers to these two items as an +"nfs_client_id4". The NFSv4.1 specification refers to these two +items as a "client_owner4". + +NFSv4 servers tie this identifier to the principal and security +flavor that the client used when presenting it. Servers use this +principal to authorize subsequent lease modification operations +sent by the client. Effectively this principal is a third element of +the identifier. + +As part of the identity presented to servers, a good +"co_ownerid" string has several important properties: + + - The "co_ownerid" string identifies the client during reboot + recovery, therefore the string is persistent across client + reboots. + - The "co_ownerid" string helps servers distinguish the client + from others, therefore the string is globally unique. Note + that there is no central authority that assigns "co_ownerid" + strings. + - Because it often appears on the network in the clear, the + "co_ownerid" string does not reveal private information about + the client itself. + - The content of the "co_ownerid" string is set and unchanging + before the client attempts NFSv4 mounts after a restart. + - The NFSv4 protocol places a 1024-byte limit on the size of the + "co_ownerid" string. + +Protecting NFSv4 lease state +---------------------------- + +NFSv4 servers utilize the "client_owner4" as described above to +assign a unique lease to each client. Under this scheme, there are +circumstances where clients can interfere with each other. This is +referred to as "lease stealing". + +If distinct clients present the same "co_ownerid" string and use +the same principal (for example, AUTH_SYS and UID 0), a server is +unable to tell that the clients are not the same. Each distinct +client presents a different boot verifier, so it appears to the +server as if there is one client that is rebooting frequently. +Neither client can maintain open or lock state in this scenario. + +If distinct clients present the same "co_ownerid" string and use +distinct principals, the server is likely to allow the first client +to operate normally but reject subsequent clients with the same +"co_ownerid" string. + +If a client's "co_ownerid" string or principal are not stable, +state recovery after a server or client reboot is not guaranteed. +If a client unexpectedly restarts but presents a different +"co_ownerid" string or principal to the server, the server orphans +the client's previous open and lock state. This blocks access to +locked files until the server removes the orphaned state. + +If the server restarts and a client presents a changed "co_ownerid" +string or principal to the server, the server will not allow the +client to reclaim its open and lock state, and may give those locks +to other clients in the meantime. This is referred to as "lock +stealing". + +Lease stealing and lock stealing increase the potential for denial +of service and in rare cases even data corruption. + +Selecting an appropriate client identifier +------------------------------------------ + +By default, the Linux NFSv4 client implementation constructs its +"co_ownerid" string starting with the words "Linux NFS" followed by +the client's UTS node name (the same node name, incidentally, that +is used as the "machine name" in an AUTH_SYS credential). In small +deployments, this construction is usually adequate. Often, however, +the node name by itself is not adequately unique, and can change +unexpectedly. Problematic situations include: + + - NFS-root (diskless) clients, where the local DCHP server (or + equivalent) does not provide a unique host name. + + - "Containers" within a single Linux host. If each container has + a separate network namespace, but does not use the UTS namespace + to provide a unique host name, then there can be multiple NFS + client instances with the same host name. + + - Clients across multiple administrative domains that access a + common NFS server. If hostnames are not assigned centrally + then uniqueness cannot be guaranteed unless a domain name is + included in the hostname. + +Linux provides two mechanisms to add uniqueness to its "co_ownerid" +string: + + nfs.nfs4_unique_id + This module parameter can set an arbitrary uniquifier string + via the kernel command line, or when the "nfs" module is + loaded. + + /sys/fs/nfs/client/net/identifier + This virtual file, available since Linux 5.3, is local to the + network namespace in which it is accessed and so can provide + distinction between network namespaces (containers) when the + hostname remains uniform. + +Note that this file is empty on name-space creation. If the +container system has access to some sort of per-container identity +then that uniquifier can be used. For example, a uniquifier might +be formed at boot using the container's internal identifier: + + sha256sum /etc/machine-id | awk '{print $1}' \\ + > /sys/fs/nfs/client/net/identifier + +Security considerations +----------------------- + +The use of cryptographic security for lease management operations +is strongly encouraged. + +If NFS with Kerberos is not configured, a Linux NFSv4 client uses +AUTH_SYS and UID 0 as the principal part of its client identity. +This configuration is not only insecure, it increases the risk of +lease and lock stealing. However, it might be the only choice for +client configurations that have no local persistent storage. +"co_ownerid" string uniqueness and persistence is critical in this +case. + +When a Kerberos keytab is present on a Linux NFS client, the client +attempts to use one of the principals in that keytab when +identifying itself to servers. The "sec=" mount option does not +control this behavior. Alternately, a single-user client with a +Kerberos principal can use that principal in place of the client's +host principal. + +Using Kerberos for this purpose enables the client and server to +use the same lease for operations covered by all "sec=" settings. +Additionally, the Linux NFS client uses the RPCSEC_GSS security +flavor with Kerberos and the integrity QOS to prevent in-transit +modification of lease modification requests. + +Additional notes +---------------- +The Linux NFSv4 client establishes a single lease on each NFSv4 +server it accesses. NFSv4 mounts from a Linux NFSv4 client of a +particular server then share that lease. + +Once a client establishes open and lock state, the NFSv4 protocol +enables lease state to transition to other servers, following data +that has been migrated. This hides data migration completely from +running applications. The Linux NFSv4 client facilitates state +migration by presenting the same "client_owner4" to all servers it +encounters. + +======== +See Also +======== + + - nfs(5) + - kerberos(7) + - RFC 7530 for the NFSv4.0 specification + - RFC 8881 for the NFSv4.1 specification. diff --git a/Documentation/filesystems/nfs/index.rst b/Documentation/filesystems/nfs/index.rst index 288d8ddb2bc6..8536134f31fd 100644 --- a/Documentation/filesystems/nfs/index.rst +++ b/Documentation/filesystems/nfs/index.rst @@ -6,6 +6,8 @@ NFS .. toctree:: :maxdepth: 1 + client-identifier + exporting pnfs rpc-cache rpc-server-gss diff --git a/Documentation/filesystems/proc.rst b/Documentation/filesystems/proc.rst index 6a0dd99786f9..1bc91fb8c321 100644 --- a/Documentation/filesystems/proc.rst +++ b/Documentation/filesystems/proc.rst @@ -942,56 +942,73 @@ can be substantial. In many cases there are other means to find out additional memory using subsystem specific interfaces, for instance /proc/net/sockstat for TCP memory allocations. -The following is from a 16GB PIII, which has highmem enabled. -You may not have all of these fields. +Example output. You may not have all of these fields. :: > cat /proc/meminfo - MemTotal: 16344972 kB - MemFree: 13634064 kB - MemAvailable: 14836172 kB - Buffers: 3656 kB - Cached: 1195708 kB - SwapCached: 0 kB - Active: 891636 kB - Inactive: 1077224 kB - HighTotal: 15597528 kB - HighFree: 13629632 kB - LowTotal: 747444 kB - LowFree: 4432 kB - SwapTotal: 0 kB - SwapFree: 0 kB - Dirty: 968 kB - Writeback: 0 kB - AnonPages: 861800 kB - Mapped: 280372 kB - Shmem: 644 kB - KReclaimable: 168048 kB - Slab: 284364 kB - SReclaimable: 159856 kB - SUnreclaim: 124508 kB - PageTables: 24448 kB - NFS_Unstable: 0 kB - Bounce: 0 kB - WritebackTmp: 0 kB - CommitLimit: 7669796 kB - Committed_AS: 100056 kB - VmallocTotal: 112216 kB - VmallocUsed: 428 kB - VmallocChunk: 111088 kB - Percpu: 62080 kB - HardwareCorrupted: 0 kB - AnonHugePages: 49152 kB - ShmemHugePages: 0 kB - ShmemPmdMapped: 0 kB + MemTotal: 32858820 kB + MemFree: 21001236 kB + MemAvailable: 27214312 kB + Buffers: 581092 kB + Cached: 5587612 kB + SwapCached: 0 kB + Active: 3237152 kB + Inactive: 7586256 kB + Active(anon): 94064 kB + Inactive(anon): 4570616 kB + Active(file): 3143088 kB + Inactive(file): 3015640 kB + Unevictable: 0 kB + Mlocked: 0 kB + SwapTotal: 0 kB + SwapFree: 0 kB + Zswap: 1904 kB + Zswapped: 7792 kB + Dirty: 12 kB + Writeback: 0 kB + AnonPages: 4654780 kB + Mapped: 266244 kB + Shmem: 9976 kB + KReclaimable: 517708 kB + Slab: 660044 kB + SReclaimable: 517708 kB + SUnreclaim: 142336 kB + KernelStack: 11168 kB + PageTables: 20540 kB + NFS_Unstable: 0 kB + Bounce: 0 kB + WritebackTmp: 0 kB + CommitLimit: 16429408 kB + Committed_AS: 7715148 kB + VmallocTotal: 34359738367 kB + VmallocUsed: 40444 kB + VmallocChunk: 0 kB + Percpu: 29312 kB + HardwareCorrupted: 0 kB + AnonHugePages: 4149248 kB + ShmemHugePages: 0 kB + ShmemPmdMapped: 0 kB + FileHugePages: 0 kB + FilePmdMapped: 0 kB + CmaTotal: 0 kB + CmaFree: 0 kB + HugePages_Total: 0 + HugePages_Free: 0 + HugePages_Rsvd: 0 + HugePages_Surp: 0 + Hugepagesize: 2048 kB + Hugetlb: 0 kB + DirectMap4k: 401152 kB + DirectMap2M: 10008576 kB + DirectMap1G: 24117248 kB MemTotal Total usable RAM (i.e. physical RAM minus a few reserved bits and the kernel binary code) MemFree - The sum of LowFree+HighFree + Total free RAM. On highmem systems, the sum of LowFree+HighFree MemAvailable An estimate of how much memory is available for starting new applications, without swapping. Calculated from MemFree, @@ -1005,8 +1022,9 @@ Buffers Relatively temporary storage for raw disk blocks shouldn't get tremendously large (20MB or so) Cached - in-memory cache for files read from the disk (the - pagecache). Doesn't include SwapCached + In-memory cache for files read from the disk (the + pagecache) as well as tmpfs & shmem. + Doesn't include SwapCached. SwapCached Memory that once was swapped out, is swapped back in but still also is in the swapfile (if memory is needed it @@ -1018,6 +1036,11 @@ Active Inactive Memory which has been less recently used. It is more eligible to be reclaimed for other purposes +Unevictable + Memory allocated for userspace which cannot be reclaimed, such + as mlocked pages, ramfs backing pages, secret memfd pages etc. +Mlocked + Memory locked with mlock(). HighTotal, HighFree Highmem is all memory above ~860MB of physical memory. Highmem areas are for use by userspace programs, or @@ -1034,26 +1057,20 @@ SwapTotal SwapFree Memory which has been evicted from RAM, and is temporarily on the disk +Zswap + Memory consumed by the zswap backend (compressed size) +Zswapped + Amount of anonymous memory stored in zswap (original size) Dirty Memory which is waiting to get written back to the disk Writeback Memory which is actively being written back to the disk AnonPages Non-file backed pages mapped into userspace page tables -HardwareCorrupted - The amount of RAM/memory in KB, the kernel identifies as - corrupted. -AnonHugePages - Non-file backed huge pages mapped into userspace page tables Mapped files which have been mmaped, such as libraries Shmem Total memory used by shared memory (shmem) and tmpfs -ShmemHugePages - Memory used by shared memory (shmem) and tmpfs allocated - with huge pages -ShmemPmdMapped - Shared memory mapped into userspace with huge pages KReclaimable Kernel allocations that the kernel will attempt to reclaim under memory pressure. Includes SReclaimable (below), and other @@ -1064,9 +1081,10 @@ SReclaimable Part of Slab, that might be reclaimed, such as caches SUnreclaim Part of Slab, that cannot be reclaimed on memory pressure +KernelStack + Memory consumed by the kernel stacks of all tasks PageTables - amount of memory dedicated to the lowest level of page - tables. + Memory consumed by userspace page tables NFS_Unstable Always zero. Previous counted pages which had been written to the server, but has not been committed to stable storage. @@ -1098,7 +1116,7 @@ Committed_AS has been allocated by processes, even if it has not been "used" by them as of yet. A process which malloc()'s 1G of memory, but only touches 300M of it will show up as - using 1G. This 1G is memory which has been "committed" to + using 1G. This 1G is memory which has been "committed" to by the VM and can be used at any time by the allocating application. With strict overcommit enabled on the system (mode 2 in 'vm.overcommit_memory'), allocations which would @@ -1107,7 +1125,7 @@ Committed_AS not fail due to lack of memory once that memory has been successfully allocated. VmallocTotal - total size of vmalloc memory area + total size of vmalloc virtual address space VmallocUsed amount of vmalloc area which is used VmallocChunk @@ -1115,6 +1133,30 @@ VmallocChunk Percpu Memory allocated to the percpu allocator used to back percpu allocations. This stat excludes the cost of metadata. +HardwareCorrupted + The amount of RAM/memory in KB, the kernel identifies as + corrupted. +AnonHugePages + Non-file backed huge pages mapped into userspace page tables +ShmemHugePages + Memory used by shared memory (shmem) and tmpfs allocated + with huge pages +ShmemPmdMapped + Shared memory mapped into userspace with huge pages +FileHugePages + Memory used for filesystem data (page cache) allocated + with huge pages +FilePmdMapped + Page cache mapped into userspace with huge pages +CmaTotal + Memory reserved for the Contiguous Memory Allocator (CMA) +CmaFree + Free remaining memory in the CMA reserves +HugePages_Total, HugePages_Free, HugePages_Rsvd, HugePages_Surp, Hugepagesize, Hugetlb + See Documentation/admin-guide/mm/hugetlbpage.rst. +DirectMap4k, DirectMap2M, DirectMap1G + Breakdown of page table sizes used in the kernel's + identity mapping of RAM vmallocinfo ~~~~~~~~~~~ diff --git a/Documentation/filesystems/vfs.rst b/Documentation/filesystems/vfs.rst index 12a011d2cbc6..08069ecd49a6 100644 --- a/Documentation/filesystems/vfs.rst +++ b/Documentation/filesystems/vfs.rst @@ -749,8 +749,9 @@ cache in your filesystem. The following members are defined: size_t count); void (*is_dirty_writeback)(struct folio *, bool *, bool *); int (*error_remove_page) (struct mapping *mapping, struct page *page); - int (*swap_activate)(struct file *); + int (*swap_activate)(struct swap_info_struct *sis, struct file *f, sector_t *span) int (*swap_deactivate)(struct file *); + int (*swap_rw)(struct kiocb *iocb, struct iov_iter *iter); }; ``writepage`` @@ -948,15 +949,21 @@ cache in your filesystem. The following members are defined: unless you have them locked or reference counts increased. ``swap_activate`` - Called when swapon is used on a file to allocate space if - necessary and pin the block lookup information in memory. A - return value of zero indicates success, in which case this file - can be used to back swapspace. + + Called to prepare the given file for swap. It should perform + any validation and preparation necessary to ensure that writes + can be performed with minimal memory allocation. It should call + add_swap_extent(), or the helper iomap_swapfile_activate(), and + return the number of extents added. If IO should be submitted + through ->swap_rw(), it should set SWP_FS_OPS, otherwise IO will + be submitted directly to the block device ``sis->bdev``. ``swap_deactivate`` Called during swapoff on files where swap_activate was successful. +``swap_rw`` + Called to read or write swap pages when SWP_FS_OPS is set. The File Object =============== diff --git a/Documentation/firmware-guide/acpi/chromeos-acpi-device.rst b/Documentation/firmware-guide/acpi/chromeos-acpi-device.rst new file mode 100644 index 000000000000..f37fc90ce340 --- /dev/null +++ b/Documentation/firmware-guide/acpi/chromeos-acpi-device.rst @@ -0,0 +1,363 @@ +.. SPDX-License-Identifier: GPL-2.0 + +===================== +Chrome OS ACPI Device +===================== + +Hardware functionality specific to Chrome OS is exposed through a Chrome OS ACPI device. +The plug and play ID of a Chrome OS ACPI device is GGL0001. GGL is a valid PNP ID of Google. +PNP ID can be used with the ACPI devices according to the guidelines. The following ACPI +objects are supported: + +.. flat-table:: Supported ACPI Objects + :widths: 1 2 + :header-rows: 1 + + * - Object + - Description + + * - CHSW + - Chrome OS switch positions + + * - HWID + - Chrome OS hardware ID + + * - FWID + - Chrome OS firmware version + + * - FRID + - Chrome OS read-only firmware version + + * - BINF + - Chrome OS boot information + + * - GPIO + - Chrome OS GPIO assignments + + * - VBNV + - Chrome OS NVRAM locations + + * - VDTA + - Chrome OS verified boot data + + * - FMAP + - Chrome OS flashmap base address + + * - MLST + - Chrome OS method list + +CHSW (Chrome OS switch positions) +================================= +This control method returns the switch positions for Chrome OS specific hardware switches. + +Arguments: +---------- +None + +Result code: +------------ +An integer containing the switch positions as bitfields: + +.. flat-table:: + :widths: 1 2 + + * - 0x00000002 + - Recovery button was pressed when x86 firmware booted. + + * - 0x00000004 + - Recovery button was pressed when EC firmware booted. (required if EC EEPROM is + rewritable; otherwise optional) + + * - 0x00000020 + - Developer switch was enabled when x86 firmware booted. + + * - 0x00000200 + - Firmware write protection was disabled when x86 firmware booted. (required if + firmware write protection is controlled through x86 BIOS; otherwise optional) + +All other bits are reserved and should be set to 0. + +HWID (Chrome OS hardware ID) +============================ +This control method returns the hardware ID for the Chromebook. + +Arguments: +---------- +None + +Result code: +------------ +A null-terminated ASCII string containing the hardware ID from the Model-Specific Data area of +EEPROM. + +Note that the hardware ID can be up to 256 characters long, including the terminating null. + +FWID (Chrome OS firmware version) +================================= +This control method returns the firmware version for the rewritable portion of the main +processor firmware. + +Arguments: +---------- +None + +Result code: +------------ +A null-terminated ASCII string containing the complete firmware version for the rewritable +portion of the main processor firmware. + +FRID (Chrome OS read-only firmware version) +=========================================== +This control method returns the firmware version for the read-only portion of the main +processor firmware. + +Arguments: +---------- +None + +Result code: +------------ +A null-terminated ASCII string containing the complete firmware version for the read-only +(bootstrap + recovery ) portion of the main processor firmware. + +BINF (Chrome OS boot information) +================================= +This control method returns information about the current boot. + +Arguments: +---------- +None + +Result code: +------------ + +.. code-block:: + + Package { + Reserved1 + Reserved2 + Active EC Firmware + Active Main Firmware Type + Reserved5 + } + +.. flat-table:: + :widths: 1 1 2 + :header-rows: 1 + + * - Field + - Format + - Description + + * - Reserved1 + - DWORD + - Set to 256 (0x100). This indicates this field is no longer used. + + * - Reserved2 + - DWORD + - Set to 256 (0x100). This indicates this field is no longer used. + + * - Active EC firmware + - DWORD + - The EC firmware which was used during boot. + + - 0 - Read-only (recovery) firmware + - 1 - Rewritable firmware. + + Set to 0 if EC firmware is always read-only. + + * - Active Main Firmware Type + - DWORD + - The main firmware type which was used during boot. + + - 0 - Recovery + - 1 - Normal + - 2 - Developer + - 3 - netboot (factory installation only) + + Other values are reserved. + + * - Reserved5 + - DWORD + - Set to 256 (0x100). This indicates this field is no longer used. + +GPIO (Chrome OS GPIO assignments) +================================= +This control method returns information about Chrome OS specific GPIO assignments for +Chrome OS hardware, so the kernel can directly control that hardware. + +Arguments: +---------- +None + +Result code: +------------ +.. code-block:: + + Package { + Package { + // First GPIO assignment + Signal Type //DWORD + Attributes //DWORD + Controller Offset //DWORD + Controller Name //ASCIIZ + }, + ... + Package { + // Last GPIO assignment + Signal Type //DWORD + Attributes //DWORD + Controller Offset //DWORD + Controller Name //ASCIIZ + } + } + +Where ASCIIZ means a null-terminated ASCII string. + +.. flat-table:: + :widths: 1 1 2 + :header-rows: 1 + + * - Field + - Format + - Description + + * - Signal Type + - DWORD + - Type of GPIO signal + + - 0x00000001 - Recovery button + - 0x00000002 - Developer mode switch + - 0x00000003 - Firmware write protection switch + - 0x00000100 - Debug header GPIO 0 + - ... + - 0x000001FF - Debug header GPIO 255 + + Other values are reserved. + + * - Attributes + - DWORD + - Signal attributes as bitfields: + + - 0x00000001 - Signal is active-high (for button, a GPIO value + of 1 means the button is pressed; for switches, a GPIO value + of 1 means the switch is enabled). If this bit is 0, the signal + is active low. Set to 0 for debug header GPIOs. + + * - Controller Offset + - DWORD + - GPIO number on the specified controller. + + * - Controller Name + - ASCIIZ + - Name of the controller for the GPIO. + Currently supported names: + "NM10" - Intel NM10 chip + +VBNV (Chrome OS NVRAM locations) +================================ +This control method returns information about the NVRAM (CMOS) locations used to +communicate with the BIOS. + +Arguments: +---------- +None + +Result code: +------------ +.. code-block:: + + Package { + NV Storage Block Offset //DWORD + NV Storage Block Size //DWORD + } + +.. flat-table:: + :widths: 1 1 2 + :header-rows: 1 + + * - Field + - Format + - Description + + * - NV Storage Block Offset + - DWORD + - Offset in CMOS bank 0 of the verified boot non-volatile storage block, counting from + the first writable CMOS byte (that is, offset=0 is the byte following the 14 bytes of + clock data). + + * - NV Storage Block Size + - DWORD + - Size in bytes of the verified boot non-volatile storage block. + +FMAP (Chrome OS flashmap address) +================================= +This control method returns the physical memory address of the start of the main processor +firmware flashmap. + +Arguments: +---------- +None + +NoneResult code: +---------------- +A DWORD containing the physical memory address of the start of the main processor firmware +flashmap. + +VDTA (Chrome OS verified boot data) +=================================== +This control method returns the verified boot data block shared between the firmware +verification step and the kernel verification step. + +Arguments: +---------- +None + +Result code: +------------ +A buffer containing the verified boot data block. + +MECK (Management Engine Checksum) +================================= +This control method returns the SHA-1 or SHA-256 hash that is read out of the Management +Engine extended registers during boot. The hash is exported via ACPI so the OS can verify that +the ME firmware has not changed. If Management Engine is not present, or if the firmware was +unable to read the extended registers, this buffer can be zero. + +Arguments: +---------- +None + +Result code: +------------ +A buffer containing the ME hash. + +MLST (Chrome OS method list) +============================ +This control method returns a list of the other control methods supported by the Chrome OS +hardware device. + +Arguments: +---------- +None + +Result code: +------------ +A package containing a list of null-terminated ASCII strings, one for each control method +supported by the Chrome OS hardware device, not including the MLST method itself. +For this version of the specification, the result is: + +.. code-block:: + + Package { + "CHSW", + "FWID", + "HWID", + "FRID", + "BINF", + "GPIO", + "VBNV", + "FMAP", + "VDTA", + "MECK" + } diff --git a/Documentation/firmware-guide/acpi/index.rst b/Documentation/firmware-guide/acpi/index.rst index b053b0c3d696..b6a42f4ffe03 100644 --- a/Documentation/firmware-guide/acpi/index.rst +++ b/Documentation/firmware-guide/acpi/index.rst @@ -29,3 +29,4 @@ ACPI Support non-d0-probe extcon-intel-int3496 intel-pmc-mux + chromeos-acpi-device diff --git a/Documentation/i2c/writing-clients.rst b/Documentation/i2c/writing-clients.rst index 978cc8210bf3..e3b126cf4a3b 100644 --- a/Documentation/i2c/writing-clients.rst +++ b/Documentation/i2c/writing-clients.rst @@ -46,7 +46,7 @@ driver model device node, and its I2C address. }, .id_table = foo_idtable, - .probe = foo_probe, + .probe_new = foo_probe, .remove = foo_remove, /* if device autodetection is needed: */ .class = I2C_CLASS_SOMETHING, @@ -155,8 +155,7 @@ those devices, and a remove() method to unbind. :: - static int foo_probe(struct i2c_client *client, - const struct i2c_device_id *id); + static int foo_probe(struct i2c_client *client); static int foo_remove(struct i2c_client *client); Remember that the i2c_driver does not create those client handles. The @@ -165,8 +164,12 @@ handle may be used during foo_probe(). If foo_probe() reports success foo_remove() returns. That binding model is used by most Linux drivers. The probe function is called when an entry in the id_table name field -matches the device's name. It is passed the entry that was matched so -the driver knows which one in the table matched. +matches the device's name. If the probe function needs that entry, it +can retrieve it using + +:: + + const struct i2c_device_id *id = i2c_match_id(foo_idtable, client); Device Creation diff --git a/Documentation/kbuild/kconfig-language.rst b/Documentation/kbuild/kconfig-language.rst index 93a5b6e1fabd..a7173843a294 100644 --- a/Documentation/kbuild/kconfig-language.rst +++ b/Documentation/kbuild/kconfig-language.rst @@ -693,6 +693,8 @@ in documenting basic Kconfig syntax a more precise definition of Kconfig semantics is welcomed. One project deduced Kconfig semantics through the use of the xconfig configurator [1]_. Work should be done to confirm if the deduced semantics matches our intended Kconfig design goals. +Another project formalized a denotational semantics of a core subset of +the Kconfig language [10]_. Having well defined semantics can be useful for tools for practical evaluation of dependencies, for instance one such case was work to @@ -700,6 +702,8 @@ express in boolean abstraction of the inferred semantics of Kconfig to translate Kconfig logic into boolean formulas and run a SAT solver on this to find dead code / features (always inactive), 114 dead features were found in Linux using this methodology [1]_ (Section 8: Threats to validity). +The kismet tool, based on the semantics in [10]_, finds abuses of reverse +dependencies and has led to dozens of committed fixes to Linux Kconfig files [11]_. Confirming this could prove useful as Kconfig stands as one of the leading industrial variability modeling languages [1]_ [2]_. Its study would help @@ -738,3 +742,5 @@ https://kernelnewbies.org/KernelProjects/kconfig-sat .. [7] https://vamos.cs.fau.de .. [8] https://undertaker.cs.fau.de .. [9] https://www4.cs.fau.de/Publications/2011/tartler_11_eurosys.pdf +.. [10] https://paulgazzillo.com/papers/esecfse21.pdf +.. [11] https://github.com/paulgazz/kmax diff --git a/Documentation/leds/leds-qcom-lpg.rst b/Documentation/leds/leds-qcom-lpg.rst new file mode 100644 index 000000000000..de7ceead9337 --- /dev/null +++ b/Documentation/leds/leds-qcom-lpg.rst @@ -0,0 +1,78 @@ +.. SPDX-License-Identifier: GPL-2.0 + +============================== +Kernel driver for Qualcomm LPG +============================== + +Description +----------- + +The Qualcomm LPG can be found in a variety of Qualcomm PMICs and consists of a +number of PWM channels, a programmable pattern lookup table and a RGB LED +current sink. + +To facilitate the various use cases, the LPG channels can be exposed as +individual LEDs, grouped together as RGB LEDs or otherwise be accessed as PWM +channels. The output of each PWM channel is routed to other hardware +blocks, such as the RGB current sink, GPIO pins etc. + +The each PWM channel can operate with a period between 27us and 384 seconds and +has a 9 bit resolution of the duty cycle. + +In order to provide support for status notifications with the CPU subsystem in +deeper idle states the LPG provides pattern support. This consists of a shared +lookup table of brightness values and per channel properties to select the +range within the table to use, the rate and if the pattern should repeat. + +The pattern for a channel can be programmed using the "pattern" trigger, using +the hw_pattern attribute. + +/sys/class/leds/<led>/hw_pattern +-------------------------------- + +Specify a hardware pattern for a Qualcomm LPG LED. + +The pattern is a series of brightness and hold-time pairs, with the hold-time +expressed in milliseconds. The hold time is a property of the pattern and must +therefor be identical for each element in the pattern (except for the pauses +described below). As the LPG hardware is not able to perform the linear +transitions expected by the leds-trigger-pattern format, each entry in the +pattern must be followed a zero-length entry of the same brightness. + +Simple pattern:: + + "255 500 255 0 0 500 0 0" + + ^ + | + 255 +----+ +----+ + | | | | ... + 0 | +----+ +---- + +----------------------> + 0 5 10 15 time (100ms) + +The LPG supports specifying a longer hold-time for the first and last element +in the pattern, the so called "low pause" and "high pause". + +Low-pause pattern:: + + "255 1000 255 0 0 500 0 0 255 500 255 0 0 500 0 0" + + ^ + | + 255 +--------+ +----+ +----+ +--------+ + | | | | | | | | ... + 0 | +----+ +----+ +----+ +---- + +-----------------------------> + 0 5 10 15 20 25 time (100ms) + +Similarily, the last entry can be stretched by using a higher hold-time on the +last entry. + +In order to save space in the shared lookup table the LPG supports "ping-pong" +mode, in which case each run through the pattern is performed by first running +the pattern forward, then backwards. This mode is automatically used by the +driver when the given pattern is a palindrome. In this case the "high pause" +denotes the wait time before the pattern is run in reverse and as such the +specified hold-time of the middle item in the pattern is allowed to have a +different hold-time. diff --git a/Documentation/networking/ip-sysctl.rst b/Documentation/networking/ip-sysctl.rst index b882d4238581..04216564a03c 100644 --- a/Documentation/networking/ip-sysctl.rst +++ b/Documentation/networking/ip-sysctl.rst @@ -2474,21 +2474,16 @@ drop_unsolicited_na - BOOLEAN By default this is turned off. -accept_unsolicited_na - BOOLEAN - Add a new neighbour cache entry in STALE state for routers on receiving an - unsolicited neighbour advertisement with target link-layer address option - specified. This is as per router-side behavior documented in RFC9131. - This has lower precedence than drop_unsolicited_na. +accept_untracked_na - BOOLEAN + Add a new neighbour cache entry in STALE state for routers on receiving a + neighbour advertisement (either solicited or unsolicited) with target + link-layer address option specified if no neighbour entry is already + present for the advertised IPv6 address. Without this knob, NAs received + for untracked addresses (absent in neighbour cache) are silently ignored. + + This is as per router-side behaviour documented in RFC9131. - ==== ====== ====== ============================================== - drop accept fwding behaviour - ---- ------ ------ ---------------------------------------------- - 1 X X Drop NA packet and don't pass up the stack - 0 0 X Pass NA packet up the stack, don't update NC - 0 1 0 Pass NA packet up the stack, don't update NC - 0 1 1 Pass NA packet up the stack, and add a STALE - NC entry - ==== ====== ====== ============================================== + This has lower precedence than drop_unsolicited_na. This will optimize the return path for the initial off-link communication that is initiated by a directly connected host, by ensuring that diff --git a/Documentation/powerpc/dawr-power9.rst b/Documentation/powerpc/dawr-power9.rst index e55ac6a24b97..310f2e0cea81 100644 --- a/Documentation/powerpc/dawr-power9.rst +++ b/Documentation/powerpc/dawr-power9.rst @@ -2,15 +2,23 @@ DAWR issues on POWER9 ===================== -On POWER9 the Data Address Watchpoint Register (DAWR) can cause a checkstop -if it points to cache inhibited (CI) memory. Currently Linux has no way to -distinguish CI memory when configuring the DAWR, so (for now) the DAWR is -disabled by this commit:: - - commit 9654153158d3e0684a1bdb76dbababdb7111d5a0 - Author: Michael Neuling <mikey@neuling.org> - Date: Tue Mar 27 15:37:24 2018 +1100 - powerpc: Disable DAWR in the base POWER9 CPU features +On older POWER9 processors, the Data Address Watchpoint Register (DAWR) can +cause a checkstop if it points to cache inhibited (CI) memory. Currently Linux +has no way to distinguish CI memory when configuring the DAWR, so on affected +systems, the DAWR is disabled. + +Affected processor revisions +============================ + +This issue is only present on processors prior to v2.3. The revision can be +found in /proc/cpuinfo:: + + processor : 0 + cpu : POWER9, altivec supported + clock : 3800.000000MHz + revision : 2.3 (pvr 004e 1203) + +On a system with the issue, the DAWR is disabled as detailed below. Technical Details: ================== diff --git a/Documentation/powerpc/kasan.txt b/Documentation/powerpc/kasan.txt new file mode 100644 index 000000000000..f032b4eaf205 --- /dev/null +++ b/Documentation/powerpc/kasan.txt @@ -0,0 +1,58 @@ +KASAN is supported on powerpc on 32-bit and Radix 64-bit only. + +32 bit support +============== + +KASAN is supported on both hash and nohash MMUs on 32-bit. + +The shadow area sits at the top of the kernel virtual memory space above the +fixmap area and occupies one eighth of the total kernel virtual memory space. + +Instrumentation of the vmalloc area is optional, unless built with modules, +in which case it is required. + +64 bit support +============== + +Currently, only the radix MMU is supported. There have been versions for hash +and Book3E processors floating around on the mailing list, but nothing has been +merged. + +KASAN support on Book3S is a bit tricky to get right: + + - It would be good to support inline instrumentation so as to be able to catch + stack issues that cannot be caught with outline mode. + + - Inline instrumentation requires a fixed offset. + + - Book3S runs code with translations off ("real mode") during boot, including a + lot of generic device-tree parsing code which is used to determine MMU + features. + + - Some code - most notably a lot of KVM code - also runs with translations off + after boot. + + - Therefore any offset has to point to memory that is valid with + translations on or off. + +One approach is just to give up on inline instrumentation. This way boot-time +checks can be delayed until after the MMU is set is up, and we can just not +instrument any code that runs with translations off after booting. This is the +current approach. + +To avoid this limitiation, the KASAN shadow would have to be placed inside the +linear mapping, using the same high-bits trick we use for the rest of the linear +mapping. This is tricky: + + - We'd like to place it near the start of physical memory. In theory we can do + this at run-time based on how much physical memory we have, but this requires + being able to arbitrarily relocate the kernel, which is basically the tricky + part of KASLR. Not being game to implement both tricky things at once, this + is hopefully something we can revisit once we get KASLR for Book3S. + + - Alternatively, we can place the shadow at the _end_ of memory, but this + requires knowing how much contiguous physical memory a system has _at compile + time_. This is a big hammer, and has some unfortunate consequences: inablity + to handle discontiguous physical memory, total failure to boot on machines + with less memory than specified, and that machines with more memory than + specified can't use it. This was deemed unacceptable. diff --git a/Documentation/tools/rtla/Makefile b/Documentation/tools/rtla/Makefile index 9f2b84af1a6c..093af6d7a0e9 100644 --- a/Documentation/tools/rtla/Makefile +++ b/Documentation/tools/rtla/Makefile @@ -17,9 +17,21 @@ DOC_MAN1 = $(addprefix $(OUTPUT),$(_DOC_MAN1)) RST2MAN_DEP := $(shell command -v rst2man 2>/dev/null) RST2MAN_OPTS += --verbose +TEST_RST2MAN = $(shell sh -c "rst2man --version > /dev/null 2>&1 || echo n") + $(OUTPUT)%.1: %.rst ifndef RST2MAN_DEP - $(error "rst2man not found, but required to generate man pages") + $(info ********************************************) + $(info ** NOTICE: rst2man not found) + $(info **) + $(info ** Consider installing the latest rst2man from your) + $(info ** distribution, e.g., 'dnf install python3-docutils' on Fedora,) + $(info ** or from source:) + $(info **) + $(info ** https://docutils.sourceforge.io/docs/dev/repository.html ) + $(info **) + $(info ********************************************) + $(error NOTICE: rst2man required to generate man pages) endif rst2man $(RST2MAN_OPTS) $< > $@ diff --git a/Documentation/trace/ftrace.rst b/Documentation/trace/ftrace.rst index 45b8c56af67a..b37dc19e4d40 100644 --- a/Documentation/trace/ftrace.rst +++ b/Documentation/trace/ftrace.rst @@ -517,6 +517,18 @@ of ftrace. Here is a list of some of the key files: processing should be able to handle them. See comments in the ktime_get_boot_fast_ns() function for more information. + tai: + This is the tai clock (CLOCK_TAI) and is derived from the wall- + clock time. However, this clock does not experience + discontinuities and backwards jumps caused by NTP inserting leap + seconds. Since the clock access is designed for use in tracing, + side effects are possible. The clock access may yield wrong + readouts in case the internal TAI offset is updated e.g., caused + by setting the system time or using adjtimex() with an offset. + These effects are rare and post processing should be able to + handle them. See comments in the ktime_get_tai_fast_ns() + function for more information. + To set a clock, simply echo the clock name into this file:: # echo global > trace_clock diff --git a/Documentation/trace/timerlat-tracer.rst b/Documentation/trace/timerlat-tracer.rst index 64d1fe6e9b93..d643c95c01eb 100644 --- a/Documentation/trace/timerlat-tracer.rst +++ b/Documentation/trace/timerlat-tracer.rst @@ -74,8 +74,9 @@ directory. The timerlat configs are: - stop_tracing_total_us: stop the system tracing if a timer latency at the *thread* context is higher than the configured value happens. Writing 0 disables this option. - - print_stack: save the stack of the IRQ occurrence, and print - it after the *thread context* event". + - print_stack: save the stack of the IRQ occurrence. The stack is printed + after the *thread context* event, or at the IRQ handler if *stop_tracing_us* + is hit. timerlat and osnoise ---------------------------- diff --git a/Documentation/userspace-api/media/lirc.h.rst.exceptions b/Documentation/userspace-api/media/lirc.h.rst.exceptions index 913d17b49831..1aeb7d7afe13 100644 --- a/Documentation/userspace-api/media/lirc.h.rst.exceptions +++ b/Documentation/userspace-api/media/lirc.h.rst.exceptions @@ -30,6 +30,8 @@ ignore define LIRC_CAN_REC ignore define LIRC_CAN_SEND_MASK ignore define LIRC_CAN_REC_MASK +ignore define LIRC_CAN_SET_REC_FILTER +ignore define LIRC_CAN_NOTIFY_DECODE # Obsolete ioctls diff --git a/Documentation/virt/kvm/api.rst b/Documentation/virt/kvm/api.rst index c8e2e9cd84dc..11e00a46c610 100644 --- a/Documentation/virt/kvm/api.rst +++ b/Documentation/virt/kvm/api.rst @@ -982,12 +982,22 @@ memory. __u8 pad2[30]; }; -If the KVM_XEN_HVM_CONFIG_INTERCEPT_HCALL flag is returned from the -KVM_CAP_XEN_HVM check, it may be set in the flags field of this ioctl. -This requests KVM to generate the contents of the hypercall page -automatically; hypercalls will be intercepted and passed to userspace -through KVM_EXIT_XEN. In this case, all of the blob size and address -fields must be zero. +If certain flags are returned from the KVM_CAP_XEN_HVM check, they may +be set in the flags field of this ioctl: + +The KVM_XEN_HVM_CONFIG_INTERCEPT_HCALL flag requests KVM to generate +the contents of the hypercall page automatically; hypercalls will be +intercepted and passed to userspace through KVM_EXIT_XEN. In this +ase, all of the blob size and address fields must be zero. + +The KVM_XEN_HVM_CONFIG_EVTCHN_SEND flag indicates to KVM that userspace +will always use the KVM_XEN_HVM_EVTCHN_SEND ioctl to deliver event +channel interrupts rather than manipulating the guest's shared_info +structures directly. This, in turn, may allow KVM to enable features +such as intercepting the SCHEDOP_poll hypercall to accelerate PV +spinlock operation for the guest. Userspace may still use the ioctl +to deliver events if it was advertised, even if userspace does not +send this indication that it will always do so No other flags are currently valid in the struct kvm_xen_hvm_config. @@ -1476,14 +1486,43 @@ Possible values are: [s390] KVM_MP_STATE_LOAD the vcpu is in a special load/startup state [s390] + KVM_MP_STATE_SUSPENDED the vcpu is in a suspend state and is waiting + for a wakeup event [arm64] ========================== =============================================== On x86, this ioctl is only useful after KVM_CREATE_IRQCHIP. Without an in-kernel irqchip, the multiprocessing state must be maintained by userspace on these architectures. -For arm64/riscv: -^^^^^^^^^^^^^^^^ +For arm64: +^^^^^^^^^^ + +If a vCPU is in the KVM_MP_STATE_SUSPENDED state, KVM will emulate the +architectural execution of a WFI instruction. + +If a wakeup event is recognized, KVM will exit to userspace with a +KVM_SYSTEM_EVENT exit, where the event type is KVM_SYSTEM_EVENT_WAKEUP. If +userspace wants to honor the wakeup, it must set the vCPU's MP state to +KVM_MP_STATE_RUNNABLE. If it does not, KVM will continue to await a wakeup +event in subsequent calls to KVM_RUN. + +.. warning:: + + If userspace intends to keep the vCPU in a SUSPENDED state, it is + strongly recommended that userspace take action to suppress the + wakeup event (such as masking an interrupt). Otherwise, subsequent + calls to KVM_RUN will immediately exit with a KVM_SYSTEM_EVENT_WAKEUP + event and inadvertently waste CPU cycles. + + Additionally, if userspace takes action to suppress a wakeup event, + it is strongly recommended that it also restores the vCPU to its + original state when the vCPU is made RUNNABLE again. For example, + if userspace masked a pending interrupt to suppress the wakeup, + the interrupt should be unmasked before returning control to the + guest. + +For riscv: +^^^^^^^^^^ The only states that are valid are KVM_MP_STATE_STOPPED and KVM_MP_STATE_RUNNABLE which reflect if the vcpu is paused or not. @@ -1887,22 +1926,25 @@ the future. 4.55 KVM_SET_TSC_KHZ -------------------- -:Capability: KVM_CAP_TSC_CONTROL +:Capability: KVM_CAP_TSC_CONTROL / KVM_CAP_VM_TSC_CONTROL :Architectures: x86 -:Type: vcpu ioctl +:Type: vcpu ioctl / vm ioctl :Parameters: virtual tsc_khz :Returns: 0 on success, -1 on error Specifies the tsc frequency for the virtual machine. The unit of the frequency is KHz. +If the KVM_CAP_VM_TSC_CONTROL capability is advertised, this can also +be used as a vm ioctl to set the initial tsc frequency of subsequently +created vCPUs. 4.56 KVM_GET_TSC_KHZ -------------------- -:Capability: KVM_CAP_GET_TSC_KHZ +:Capability: KVM_CAP_GET_TSC_KHZ / KVM_CAP_VM_TSC_CONTROL :Architectures: x86 -:Type: vcpu ioctl +:Type: vcpu ioctl / vm ioctl :Parameters: none :Returns: virtual tsc-khz on success, negative value on error @@ -2601,6 +2643,24 @@ EINVAL. After the vcpu's SVE configuration is finalized, further attempts to write this register will fail with EPERM. +arm64 bitmap feature firmware pseudo-registers have the following bit pattern:: + + 0x6030 0000 0016 <regno:16> + +The bitmap feature firmware registers exposes the hypercall services that +are available for userspace to configure. The set bits corresponds to the +services that are available for the guests to access. By default, KVM +sets all the supported bits during VM initialization. The userspace can +discover the available services via KVM_GET_ONE_REG, and write back the +bitmap corresponding to the features that it wishes guests to see via +KVM_SET_ONE_REG. + +Note: These registers are immutable once any of the vCPUs of the VM has +run at least once. A KVM_SET_ONE_REG in such a scenario will return +a -EBUSY to userspace. + +(See Documentation/virt/kvm/arm/hypercalls.rst for more details.) + MIPS registers are mapped using the lower 32 bits. The upper 16 of that is the register group type: @@ -3754,12 +3814,18 @@ in case of KVM_S390_MEMOP_F_CHECK_ONLY), the ioctl returns a positive error number indicating the type of exception. This exception is also raised directly at the corresponding VCPU if the flag KVM_S390_MEMOP_F_INJECT_EXCEPTION is set. +On protection exceptions, unless specified otherwise, the injected +translation-exception identifier (TEID) indicates suppression. If the KVM_S390_MEMOP_F_SKEY_PROTECTION flag is set, storage key protection is also in effect and may cause exceptions if accesses are prohibited given the access key designated by "key"; the valid range is 0..15. KVM_S390_MEMOP_F_SKEY_PROTECTION is available if KVM_CAP_S390_MEM_OP_EXTENSION is > 0. +Since the accessed memory may span multiple pages and those pages might have +different storage keys, it is possible that a protection exception occurs +after memory has been modified. In this case, if the exception is injected, +the TEID does not indicate suppression. Absolute read/write: ^^^^^^^^^^^^^^^^^^^^ @@ -5216,7 +5282,25 @@ have deterministic behavior. struct { __u64 gfn; } shared_info; - __u64 pad[4]; + struct { + __u32 send_port; + __u32 type; /* EVTCHNSTAT_ipi / EVTCHNSTAT_interdomain */ + __u32 flags; + union { + struct { + __u32 port; + __u32 vcpu; + __u32 priority; + } port; + struct { + __u32 port; /* Zero for eventfd */ + __s32 fd; + } eventfd; + __u32 padding[4]; + } deliver; + } evtchn; + __u32 xen_version; + __u64 pad[8]; } u; }; @@ -5247,6 +5331,30 @@ KVM_XEN_ATTR_TYPE_SHARED_INFO KVM_XEN_ATTR_TYPE_UPCALL_VECTOR Sets the exception vector used to deliver Xen event channel upcalls. + This is the HVM-wide vector injected directly by the hypervisor + (not through the local APIC), typically configured by a guest via + HVM_PARAM_CALLBACK_IRQ. + +KVM_XEN_ATTR_TYPE_EVTCHN + This attribute is available when the KVM_CAP_XEN_HVM ioctl indicates + support for KVM_XEN_HVM_CONFIG_EVTCHN_SEND features. It configures + an outbound port number for interception of EVTCHNOP_send requests + from the guest. A given sending port number may be directed back + to a specified vCPU (by APIC ID) / port / priority on the guest, + or to trigger events on an eventfd. The vCPU and priority can be + changed by setting KVM_XEN_EVTCHN_UPDATE in a subsequent call, + but other fields cannot change for a given sending port. A port + mapping is removed by using KVM_XEN_EVTCHN_DEASSIGN in the flags + field. + +KVM_XEN_ATTR_TYPE_XEN_VERSION + This attribute is available when the KVM_CAP_XEN_HVM ioctl indicates + support for KVM_XEN_HVM_CONFIG_EVTCHN_SEND features. It configures + the 32-bit version code returned to the guest when it invokes the + XENVER_version call; typically (XEN_MAJOR << 16 | XEN_MINOR). PV + Xen guests will often use this to as a dummy hypercall to trigger + event channel delivery, so responding within the kernel without + exiting to userspace is beneficial. 4.127 KVM_XEN_HVM_GET_ATTR -------------------------- @@ -5258,7 +5366,8 @@ KVM_XEN_ATTR_TYPE_UPCALL_VECTOR :Returns: 0 on success, < 0 on error Allows Xen VM attributes to be read. For the structure and types, -see KVM_XEN_HVM_SET_ATTR above. +see KVM_XEN_HVM_SET_ATTR above. The KVM_XEN_ATTR_TYPE_EVTCHN +attribute cannot be read. 4.128 KVM_XEN_VCPU_SET_ATTR --------------------------- @@ -5285,6 +5394,13 @@ see KVM_XEN_HVM_SET_ATTR above. __u64 time_blocked; __u64 time_offline; } runstate; + __u32 vcpu_id; + struct { + __u32 port; + __u32 priority; + __u64 expires_ns; + } timer; + __u8 vector; } u; }; @@ -5326,6 +5442,27 @@ KVM_XEN_VCPU_ATTR_TYPE_RUNSTATE_ADJUST or RUNSTATE_offline) to set the current accounted state as of the adjusted state_entry_time. +KVM_XEN_VCPU_ATTR_TYPE_VCPU_ID + This attribute is available when the KVM_CAP_XEN_HVM ioctl indicates + support for KVM_XEN_HVM_CONFIG_EVTCHN_SEND features. It sets the Xen + vCPU ID of the given vCPU, to allow timer-related VCPU operations to + be intercepted by KVM. + +KVM_XEN_VCPU_ATTR_TYPE_TIMER + This attribute is available when the KVM_CAP_XEN_HVM ioctl indicates + support for KVM_XEN_HVM_CONFIG_EVTCHN_SEND features. It sets the + event channel port/priority for the VIRQ_TIMER of the vCPU, as well + as allowing a pending timer to be saved/restored. + +KVM_XEN_VCPU_ATTR_TYPE_UPCALL_VECTOR + This attribute is available when the KVM_CAP_XEN_HVM ioctl indicates + support for KVM_XEN_HVM_CONFIG_EVTCHN_SEND features. It sets the + per-vCPU local APIC upcall vector, configured by a Xen guest with + the HVMOP_set_evtchn_upcall_vector hypercall. This is typically + used by Windows guests, and is distinct from the HVM-wide upcall + vector configured with HVM_PARAM_CALLBACK_IRQ. + + 4.129 KVM_XEN_VCPU_GET_ATTR --------------------------- @@ -5645,6 +5782,25 @@ enabled with ``arch_prctl()``, but this may change in the future. The offsets of the state save areas in struct kvm_xsave follow the contents of CPUID leaf 0xD on the host. +4.135 KVM_XEN_HVM_EVTCHN_SEND +----------------------------- + +:Capability: KVM_CAP_XEN_HVM / KVM_XEN_HVM_CONFIG_EVTCHN_SEND +:Architectures: x86 +:Type: vm ioctl +:Parameters: struct kvm_irq_routing_xen_evtchn +:Returns: 0 on success, < 0 on error + + +:: + + struct kvm_irq_routing_xen_evtchn { + __u32 port; + __u32 vcpu; + __u32 priority; + }; + +This ioctl injects an event channel interrupt directly to the guest vCPU. 5. The kvm_run structure ======================== @@ -5987,6 +6143,9 @@ should put the acknowledged interrupt vector into the 'epr' field. #define KVM_SYSTEM_EVENT_SHUTDOWN 1 #define KVM_SYSTEM_EVENT_RESET 2 #define KVM_SYSTEM_EVENT_CRASH 3 + #define KVM_SYSTEM_EVENT_WAKEUP 4 + #define KVM_SYSTEM_EVENT_SUSPEND 5 + #define KVM_SYSTEM_EVENT_SEV_TERM 6 __u32 type; __u32 ndata; __u64 data[16]; @@ -6011,6 +6170,13 @@ Valid values for 'type' are: has requested a crash condition maintenance. Userspace can choose to ignore the request, or to gather VM memory core dump and/or reset/shutdown of the VM. + - KVM_SYSTEM_EVENT_SEV_TERM -- an AMD SEV guest requested termination. + The guest physical address of the guest's GHCB is stored in `data[0]`. + - KVM_SYSTEM_EVENT_WAKEUP -- the exiting vCPU is in a suspended state and + KVM has recognized a wakeup event. Userspace may honor this event by + marking the exiting vCPU as runnable, or deny it and call KVM_RUN again. + - KVM_SYSTEM_EVENT_SUSPEND -- the guest has requested a suspension of + the VM. If KVM_CAP_SYSTEM_EVENT_DATA is present, the 'data' field can contain architecture specific information for the system-level event. Only @@ -6027,6 +6193,32 @@ Previous versions of Linux defined a `flags` member in this struct. The field is now aliased to `data[0]`. Userspace can assume that it is only written if ndata is greater than 0. +For arm/arm64: +-------------- + +KVM_SYSTEM_EVENT_SUSPEND exits are enabled with the +KVM_CAP_ARM_SYSTEM_SUSPEND VM capability. If a guest invokes the PSCI +SYSTEM_SUSPEND function, KVM will exit to userspace with this event +type. + +It is the sole responsibility of userspace to implement the PSCI +SYSTEM_SUSPEND call according to ARM DEN0022D.b 5.19 "SYSTEM_SUSPEND". +KVM does not change the vCPU's state before exiting to userspace, so +the call parameters are left in-place in the vCPU registers. + +Userspace is _required_ to take action for such an exit. It must +either: + + - Honor the guest request to suspend the VM. Userspace can request + in-kernel emulation of suspension by setting the calling vCPU's + state to KVM_MP_STATE_SUSPENDED. Userspace must configure the vCPU's + state according to the parameters passed to the PSCI function when + the calling vCPU is resumed. See ARM DEN0022D.b 5.19.1 "Intended use" + for details on the function parameters. + + - Deny the guest request to suspend the VM. See ARM DEN0022D.b 5.19.2 + "Caller responsibilities" for possible return values. + :: /* KVM_EXIT_IOAPIC_EOI */ @@ -7147,6 +7339,15 @@ The valid bits in cap.args[0] are: Additionally, when this quirk is disabled, KVM clears CPUID.01H:ECX[bit 3] if IA32_MISC_ENABLE[bit 18] is cleared. + + KVM_X86_QUIRK_FIX_HYPERCALL_INSN By default, KVM rewrites guest + VMMCALL/VMCALL instructions to match the + vendor's hypercall instruction for the + system. When this quirk is disabled, KVM + will no longer rewrite invalid guest + hypercall instructions. Executing the + incorrect hypercall instruction will + generate a #UD within the guest. =================================== ============================================ 8. Other capabilities. @@ -7624,8 +7825,9 @@ PVHVM guests. Valid flags are:: #define KVM_XEN_HVM_CONFIG_HYPERCALL_MSR (1 << 0) #define KVM_XEN_HVM_CONFIG_INTERCEPT_HCALL (1 << 1) #define KVM_XEN_HVM_CONFIG_SHARED_INFO (1 << 2) - #define KVM_XEN_HVM_CONFIG_RUNSTATE (1 << 2) - #define KVM_XEN_HVM_CONFIG_EVTCHN_2LEVEL (1 << 3) + #define KVM_XEN_HVM_CONFIG_RUNSTATE (1 << 3) + #define KVM_XEN_HVM_CONFIG_EVTCHN_2LEVEL (1 << 4) + #define KVM_XEN_HVM_CONFIG_EVTCHN_SEND (1 << 5) The KVM_XEN_HVM_CONFIG_HYPERCALL_MSR flag indicates that the KVM_XEN_HVM_CONFIG ioctl is available, for the guest to set its hypercall page. @@ -7649,6 +7851,14 @@ The KVM_XEN_HVM_CONFIG_EVTCHN_2LEVEL flag indicates that IRQ routing entries of the type KVM_IRQ_ROUTING_XEN_EVTCHN are supported, with the priority field set to indicate 2 level event channel delivery. +The KVM_XEN_HVM_CONFIG_EVTCHN_SEND flag indicates that KVM supports +injecting event channel events directly into the guest with the +KVM_XEN_HVM_EVTCHN_SEND ioctl. It also indicates support for the +KVM_XEN_ATTR_TYPE_EVTCHN/XEN_VERSION HVM attributes and the +KVM_XEN_VCPU_ATTR_TYPE_VCPU_ID/TIMER/UPCALL_VECTOR vCPU attributes. +related to event channel delivery, timers, and the XENVER_version +interception. + 8.31 KVM_CAP_PPC_MULTITCE ------------------------- @@ -7736,6 +7946,16 @@ At this time, KVM_PMU_CAP_DISABLE is the only capability. Setting this capability will disable PMU virtualization for that VM. Usermode should adjust CPUID leaf 0xA to reflect that the PMU is disabled. +8.36 KVM_CAP_ARM_SYSTEM_SUSPEND +------------------------------- + +:Capability: KVM_CAP_ARM_SYSTEM_SUSPEND +:Architectures: arm64 +:Type: vm + +When enabled, KVM will exit to userspace with KVM_EXIT_SYSTEM_EVENT of +type KVM_SYSTEM_EVENT_SUSPEND to process the guest suspend request. + 9. Known KVM API problems ========================= diff --git a/Documentation/virt/kvm/arm/hypercalls.rst b/Documentation/virt/kvm/arm/hypercalls.rst new file mode 100644 index 000000000000..3e23084644ba --- /dev/null +++ b/Documentation/virt/kvm/arm/hypercalls.rst @@ -0,0 +1,138 @@ +.. SPDX-License-Identifier: GPL-2.0 + +======================= +ARM Hypercall Interface +======================= + +KVM handles the hypercall services as requested by the guests. New hypercall +services are regularly made available by the ARM specification or by KVM (as +vendor services) if they make sense from a virtualization point of view. + +This means that a guest booted on two different versions of KVM can observe +two different "firmware" revisions. This could cause issues if a given guest +is tied to a particular version of a hypercall service, or if a migration +causes a different version to be exposed out of the blue to an unsuspecting +guest. + +In order to remedy this situation, KVM exposes a set of "firmware +pseudo-registers" that can be manipulated using the GET/SET_ONE_REG +interface. These registers can be saved/restored by userspace, and set +to a convenient value as required. + +The following registers are defined: + +* KVM_REG_ARM_PSCI_VERSION: + + KVM implements the PSCI (Power State Coordination Interface) + specification in order to provide services such as CPU on/off, reset + and power-off to the guest. + + - Only valid if the vcpu has the KVM_ARM_VCPU_PSCI_0_2 feature set + (and thus has already been initialized) + - Returns the current PSCI version on GET_ONE_REG (defaulting to the + highest PSCI version implemented by KVM and compatible with v0.2) + - Allows any PSCI version implemented by KVM and compatible with + v0.2 to be set with SET_ONE_REG + - Affects the whole VM (even if the register view is per-vcpu) + +* KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_1: + Holds the state of the firmware support to mitigate CVE-2017-5715, as + offered by KVM to the guest via a HVC call. The workaround is described + under SMCCC_ARCH_WORKAROUND_1 in [1]. + + Accepted values are: + + KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_1_NOT_AVAIL: + KVM does not offer + firmware support for the workaround. The mitigation status for the + guest is unknown. + KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_1_AVAIL: + The workaround HVC call is + available to the guest and required for the mitigation. + KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_1_NOT_REQUIRED: + The workaround HVC call + is available to the guest, but it is not needed on this VCPU. + +* KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2: + Holds the state of the firmware support to mitigate CVE-2018-3639, as + offered by KVM to the guest via a HVC call. The workaround is described + under SMCCC_ARCH_WORKAROUND_2 in [1]_. + + Accepted values are: + + KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2_NOT_AVAIL: + A workaround is not + available. KVM does not offer firmware support for the workaround. + KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2_UNKNOWN: + The workaround state is + unknown. KVM does not offer firmware support for the workaround. + KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2_AVAIL: + The workaround is available, + and can be disabled by a vCPU. If + KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2_ENABLED is set, it is active for + this vCPU. + KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2_NOT_REQUIRED: + The workaround is always active on this vCPU or it is not needed. + + +Bitmap Feature Firmware Registers +--------------------------------- + +Contrary to the above registers, the following registers exposes the +hypercall services in the form of a feature-bitmap to the userspace. This +bitmap is translated to the services that are available to the guest. +There is a register defined per service call owner and can be accessed via +GET/SET_ONE_REG interface. + +By default, these registers are set with the upper limit of the features +that are supported. This way userspace can discover all the usable +hypercall services via GET_ONE_REG. The user-space can write-back the +desired bitmap back via SET_ONE_REG. The features for the registers that +are untouched, probably because userspace isn't aware of them, will be +exposed as is to the guest. + +Note that KVM will not allow the userspace to configure the registers +anymore once any of the vCPUs has run at least once. Instead, it will +return a -EBUSY. + +The pseudo-firmware bitmap register are as follows: + +* KVM_REG_ARM_STD_BMAP: + Controls the bitmap of the ARM Standard Secure Service Calls. + + The following bits are accepted: + + Bit-0: KVM_REG_ARM_STD_BIT_TRNG_V1_0: + The bit represents the services offered under v1.0 of ARM True Random + Number Generator (TRNG) specification, ARM DEN0098. + +* KVM_REG_ARM_STD_HYP_BMAP: + Controls the bitmap of the ARM Standard Hypervisor Service Calls. + + The following bits are accepted: + + Bit-0: KVM_REG_ARM_STD_HYP_BIT_PV_TIME: + The bit represents the Paravirtualized Time service as represented by + ARM DEN0057A. + +* KVM_REG_ARM_VENDOR_HYP_BMAP: + Controls the bitmap of the Vendor specific Hypervisor Service Calls. + + The following bits are accepted: + + Bit-0: KVM_REG_ARM_VENDOR_HYP_BIT_FUNC_FEAT + The bit represents the ARM_SMCCC_VENDOR_HYP_KVM_FEATURES_FUNC_ID + and ARM_SMCCC_VENDOR_HYP_CALL_UID_FUNC_ID function-ids. + + Bit-1: KVM_REG_ARM_VENDOR_HYP_BIT_PTP: + The bit represents the Precision Time Protocol KVM service. + +Errors: + + ======= ============================================================= + -ENOENT Unknown register accessed. + -EBUSY Attempt a 'write' to the register after the VM has started. + -EINVAL Invalid bitmap written to the register. + ======= ============================================================= + +.. [1] https://developer.arm.com/-/media/developer/pdf/ARM_DEN_0070A_Firmware_interfaces_for_mitigating_CVE-2017-5715.pdf diff --git a/Documentation/virt/kvm/arm/index.rst b/Documentation/virt/kvm/arm/index.rst index 78a9b670aafe..e84848432158 100644 --- a/Documentation/virt/kvm/arm/index.rst +++ b/Documentation/virt/kvm/arm/index.rst @@ -8,6 +8,6 @@ ARM :maxdepth: 2 hyp-abi - psci + hypercalls pvtime ptp_kvm diff --git a/Documentation/virt/kvm/arm/psci.rst b/Documentation/virt/kvm/arm/psci.rst deleted file mode 100644 index d52c2e83b5b8..000000000000 --- a/Documentation/virt/kvm/arm/psci.rst +++ /dev/null @@ -1,77 +0,0 @@ -.. SPDX-License-Identifier: GPL-2.0 - -========================================= -Power State Coordination Interface (PSCI) -========================================= - -KVM implements the PSCI (Power State Coordination Interface) -specification in order to provide services such as CPU on/off, reset -and power-off to the guest. - -The PSCI specification is regularly updated to provide new features, -and KVM implements these updates if they make sense from a virtualization -point of view. - -This means that a guest booted on two different versions of KVM can -observe two different "firmware" revisions. This could cause issues if -a given guest is tied to a particular PSCI revision (unlikely), or if -a migration causes a different PSCI version to be exposed out of the -blue to an unsuspecting guest. - -In order to remedy this situation, KVM exposes a set of "firmware -pseudo-registers" that can be manipulated using the GET/SET_ONE_REG -interface. These registers can be saved/restored by userspace, and set -to a convenient value if required. - -The following register is defined: - -* KVM_REG_ARM_PSCI_VERSION: - - - Only valid if the vcpu has the KVM_ARM_VCPU_PSCI_0_2 feature set - (and thus has already been initialized) - - Returns the current PSCI version on GET_ONE_REG (defaulting to the - highest PSCI version implemented by KVM and compatible with v0.2) - - Allows any PSCI version implemented by KVM and compatible with - v0.2 to be set with SET_ONE_REG - - Affects the whole VM (even if the register view is per-vcpu) - -* KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_1: - Holds the state of the firmware support to mitigate CVE-2017-5715, as - offered by KVM to the guest via a HVC call. The workaround is described - under SMCCC_ARCH_WORKAROUND_1 in [1]. - - Accepted values are: - - KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_1_NOT_AVAIL: - KVM does not offer - firmware support for the workaround. The mitigation status for the - guest is unknown. - KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_1_AVAIL: - The workaround HVC call is - available to the guest and required for the mitigation. - KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_1_NOT_REQUIRED: - The workaround HVC call - is available to the guest, but it is not needed on this VCPU. - -* KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2: - Holds the state of the firmware support to mitigate CVE-2018-3639, as - offered by KVM to the guest via a HVC call. The workaround is described - under SMCCC_ARCH_WORKAROUND_2 in [1]_. - - Accepted values are: - - KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2_NOT_AVAIL: - A workaround is not - available. KVM does not offer firmware support for the workaround. - KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2_UNKNOWN: - The workaround state is - unknown. KVM does not offer firmware support for the workaround. - KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2_AVAIL: - The workaround is available, - and can be disabled by a vCPU. If - KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2_ENABLED is set, it is active for - this vCPU. - KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2_NOT_REQUIRED: - The workaround is always active on this vCPU or it is not needed. - -.. [1] https://developer.arm.com/-/media/developer/pdf/ARM_DEN_0070A_Firmware_interfaces_for_mitigating_CVE-2017-5715.pdf diff --git a/Documentation/virt/kvm/x86/mmu.rst b/Documentation/virt/kvm/x86/mmu.rst index 5b1ebad24c77..8739120f4300 100644 --- a/Documentation/virt/kvm/x86/mmu.rst +++ b/Documentation/virt/kvm/x86/mmu.rst @@ -202,6 +202,10 @@ Shadow pages contain the following information: Is 1 if the MMU instance cannot use A/D bits. EPT did not have A/D bits before Haswell; shadow EPT page tables also cannot use A/D bits if the L1 hypervisor does not enable them. + role.passthrough: + The page is not backed by a guest page table, but its first entry + points to one. This is set if NPT uses 5-level page tables (host + CR4.LA57=1) and is shadowing L1's 4-level NPT (L1 CR4.LA57=1). gfn: Either the guest page table containing the translations shadowed by this page, or the base page frame for linear translations. See role.direct. diff --git a/Documentation/vm/highmem.rst b/Documentation/vm/highmem.rst index 0f69a9fec34d..c9887f241c6c 100644 --- a/Documentation/vm/highmem.rst +++ b/Documentation/vm/highmem.rst @@ -50,61 +50,74 @@ space when they use mm context tags. Temporary Virtual Mappings ========================== -The kernel contains several ways of creating temporary mappings: +The kernel contains several ways of creating temporary mappings. The following +list shows them in order of preference of use. -* vmap(). This can be used to make a long duration mapping of multiple - physical pages into a contiguous virtual space. It needs global - synchronization to unmap. - -* kmap(). This permits a short duration mapping of a single page. It needs - global synchronization, but is amortized somewhat. It is also prone to - deadlocks when using in a nested fashion, and so it is not recommended for - new code. - -* kmap_atomic(). This permits a very short duration mapping of a single - page. Since the mapping is restricted to the CPU that issued it, it - performs well, but the issuing task is therefore required to stay on that - CPU until it has finished, lest some other task displace its mappings. +* kmap_local_page(). This function is used to require short term mappings. + It can be invoked from any context (including interrupts) but the mappings + can only be used in the context which acquired them. - kmap_atomic() may also be used by interrupt contexts, since it is does not - sleep and the caller may not sleep until after kunmap_atomic() is called. + This function should be preferred, where feasible, over all the others. - It may be assumed that k[un]map_atomic() won't fail. + These mappings are thread-local and CPU-local, meaning that the mapping + can only be accessed from within this thread and the thread is bound the + CPU while the mapping is active. Even if the thread is preempted (since + preemption is never disabled by the function) the CPU can not be + unplugged from the system via CPU-hotplug until the mapping is disposed. + It's valid to take pagefaults in a local kmap region, unless the context + in which the local mapping is acquired does not allow it for other reasons. -Using kmap_atomic -================= + kmap_local_page() always returns a valid virtual address and it is assumed + that kunmap_local() will never fail. -When and where to use kmap_atomic() is straightforward. It is used when code -wants to access the contents of a page that might be allocated from high memory -(see __GFP_HIGHMEM), for example a page in the pagecache. The API has two -functions, and they can be used in a manner similar to the following:: + Nesting kmap_local_page() and kmap_atomic() mappings is allowed to a certain + extent (up to KMAP_TYPE_NR) but their invocations have to be strictly ordered + because the map implementation is stack based. See kmap_local_page() kdocs + (included in the "Functions" section) for details on how to manage nested + mappings. - /* Find the page of interest. */ - struct page *page = find_get_page(mapping, offset); +* kmap_atomic(). This permits a very short duration mapping of a single + page. Since the mapping is restricted to the CPU that issued it, it + performs well, but the issuing task is therefore required to stay on that + CPU until it has finished, lest some other task displace its mappings. - /* Gain access to the contents of that page. */ - void *vaddr = kmap_atomic(page); + kmap_atomic() may also be used by interrupt contexts, since it does not + sleep and the callers too may not sleep until after kunmap_atomic() is + called. - /* Do something to the contents of that page. */ - memset(vaddr, 0, PAGE_SIZE); + Each call of kmap_atomic() in the kernel creates a non-preemptible section + and disable pagefaults. This could be a source of unwanted latency. Therefore + users should prefer kmap_local_page() instead of kmap_atomic(). - /* Unmap that page. */ - kunmap_atomic(vaddr); + It is assumed that k[un]map_atomic() won't fail. -Note that the kunmap_atomic() call takes the result of the kmap_atomic() call -not the argument. +* kmap(). This should be used to make short duration mapping of a single + page with no restrictions on preemption or migration. It comes with an + overhead as mapping space is restricted and protected by a global lock + for synchronization. When mapping is no longer needed, the address that + the page was mapped to must be released with kunmap(). -If you need to map two pages because you want to copy from one page to -another you need to keep the kmap_atomic calls strictly nested, like:: + Mapping changes must be propagated across all the CPUs. kmap() also + requires global TLB invalidation when the kmap's pool wraps and it might + block when the mapping space is fully utilized until a slot becomes + available. Therefore, kmap() is only callable from preemptible context. - vaddr1 = kmap_atomic(page1); - vaddr2 = kmap_atomic(page2); + All the above work is necessary if a mapping must last for a relatively + long time but the bulk of high-memory mappings in the kernel are + short-lived and only used in one place. This means that the cost of + kmap() is mostly wasted in such cases. kmap() was not intended for long + term mappings but it has morphed in that direction and its use is + strongly discouraged in newer code and the set of the preceding functions + should be preferred. - memcpy(vaddr1, vaddr2, PAGE_SIZE); + On 64-bit systems, calls to kmap_local_page(), kmap_atomic() and kmap() have + no real work to do because a 64-bit address space is more than sufficient to + address all the physical memory whose pages are permanently mapped. - kunmap_atomic(vaddr2); - kunmap_atomic(vaddr1); +* vmap(). This can be used to make a long duration mapping of multiple + physical pages into a contiguous virtual space. It needs global + synchronization to unmap. Cost of Temporary Mappings @@ -145,3 +158,10 @@ The general recommendation is that you don't use more than 8GiB on a 32-bit machine - although more might work for you and your workload, you're pretty much on your own - don't expect kernel developers to really care much if things come apart. + + +Functions +========= + +.. kernel-doc:: include/linux/highmem.h +.. kernel-doc:: include/linux/highmem-internal.h diff --git a/Documentation/vm/index.rst b/Documentation/vm/index.rst index e72736d53604..575ccd40e30c 100644 --- a/Documentation/vm/index.rst +++ b/Documentation/vm/index.rst @@ -63,5 +63,6 @@ above structured documentation, or deleted if it has served its purpose. transhuge unevictable-lru vmalloced-kernel-stacks + vmemmap_dedup z3fold zsmalloc diff --git a/Documentation/vm/page_owner.rst b/Documentation/vm/page_owner.rst index 7e0c3f574e78..f5c954afe97c 100644 --- a/Documentation/vm/page_owner.rst +++ b/Documentation/vm/page_owner.rst @@ -121,6 +121,14 @@ Usage -r Sort by memory release time. -s Sort by stack trace. -t Sort by times (default). + --sort <order> Specify sorting order. Sorting syntax is [+|-]key[,[+|-]key[,...]]. + Choose a key from the **STANDARD FORMAT SPECIFIERS** section. The "+" is + optional since default direction is increasing numerical or lexicographic + order. Mixed use of abbreviated and complete-form of keys is allowed. + + Examples: + ./page_owner_sort <input> <output> --sort=n,+pid,-tgid + ./page_owner_sort <input> <output> --sort=at additional function:: @@ -129,7 +137,6 @@ Usage Specify culling rules.Culling syntax is key[,key[,...]].Choose a multi-letter key from the **STANDARD FORMAT SPECIFIERS** section. - <rules> is a single argument in the form of a comma-separated list, which offers a way to specify individual culling rules. The recognized keywords are described in the **STANDARD FORMAT SPECIFIERS** section below. @@ -137,7 +144,6 @@ Usage the STANDARD SORT KEYS section below. Mixed use of abbreviated and complete-form of keys is allowed. - Examples: ./page_owner_sort <input> <output> --cull=stacktrace ./page_owner_sort <input> <output> --cull=st,pid,name @@ -147,17 +153,44 @@ Usage -f Filter out the information of blocks whose memory has been released. Select: - --pid <PID> Select by pid. - --tgid <TGID> Select by tgid. - --name <command> Select by task command name. + --pid <pidlist> Select by pid. This selects the blocks whose process ID + numbers appear in <pidlist>. + --tgid <tgidlist> Select by tgid. This selects the blocks whose thread + group ID numbers appear in <tgidlist>. + --name <cmdlist> Select by task command name. This selects the blocks whose + task command name appear in <cmdlist>. + + <pidlist>, <tgidlist>, <cmdlist> are single arguments in the form of a comma-separated list, + which offers a way to specify individual selecting rules. + + + Examples: + ./page_owner_sort <input> <output> --pid=1 + ./page_owner_sort <input> <output> --tgid=1,2,3 + ./page_owner_sort <input> <output> --name name1,name2 STANDARD FORMAT SPECIFIERS ========================== :: + For --sort option: + + KEY LONG DESCRIPTION + p pid process ID + tg tgid thread group ID + n name task command name + st stacktrace stack trace of the page allocation + T txt full text of block + ft free_ts timestamp of the page when it was released + at alloc_ts timestamp of the page when it was allocated + ator allocator memory allocator for pages + + For --curl option: + KEY LONG DESCRIPTION p pid process ID tg tgid thread group ID n name task command name f free whether the page has been released or not - st stacktrace stace trace of the page allocation + st stacktrace stack trace of the page allocation + ator allocator memory allocator for pages diff --git a/Documentation/vm/vmemmap_dedup.rst b/Documentation/vm/vmemmap_dedup.rst new file mode 100644 index 000000000000..c9c495f62d12 --- /dev/null +++ b/Documentation/vm/vmemmap_dedup.rst @@ -0,0 +1,223 @@ +.. SPDX-License-Identifier: GPL-2.0 + +========================================= +A vmemmap diet for HugeTLB and Device DAX +========================================= + +HugeTLB +======= + +The struct page structures (page structs) are used to describe a physical +page frame. By default, there is a one-to-one mapping from a page frame to +it's corresponding page struct. + +HugeTLB pages consist of multiple base page size pages and is supported by many +architectures. See Documentation/admin-guide/mm/hugetlbpage.rst for more +details. On the x86-64 architecture, HugeTLB pages of size 2MB and 1GB are +currently supported. Since the base page size on x86 is 4KB, a 2MB HugeTLB page +consists of 512 base pages and a 1GB HugeTLB page consists of 4096 base pages. +For each base page, there is a corresponding page struct. + +Within the HugeTLB subsystem, only the first 4 page structs are used to +contain unique information about a HugeTLB page. __NR_USED_SUBPAGE provides +this upper limit. The only 'useful' information in the remaining page structs +is the compound_head field, and this field is the same for all tail pages. + +By removing redundant page structs for HugeTLB pages, memory can be returned +to the buddy allocator for other uses. + +Different architectures support different HugeTLB pages. For example, the +following table is the HugeTLB page size supported by x86 and arm64 +architectures. Because arm64 supports 4k, 16k, and 64k base pages and +supports contiguous entries, so it supports many kinds of sizes of HugeTLB +page. + ++--------------+-----------+-----------------------------------------------+ +| Architecture | Page Size | HugeTLB Page Size | ++--------------+-----------+-----------+-----------+-----------+-----------+ +| x86-64 | 4KB | 2MB | 1GB | | | ++--------------+-----------+-----------+-----------+-----------+-----------+ +| | 4KB | 64KB | 2MB | 32MB | 1GB | +| +-----------+-----------+-----------+-----------+-----------+ +| arm64 | 16KB | 2MB | 32MB | 1GB | | +| +-----------+-----------+-----------+-----------+-----------+ +| | 64KB | 2MB | 512MB | 16GB | | ++--------------+-----------+-----------+-----------+-----------+-----------+ + +When the system boot up, every HugeTLB page has more than one struct page +structs which size is (unit: pages):: + + struct_size = HugeTLB_Size / PAGE_SIZE * sizeof(struct page) / PAGE_SIZE + +Where HugeTLB_Size is the size of the HugeTLB page. We know that the size +of the HugeTLB page is always n times PAGE_SIZE. So we can get the following +relationship:: + + HugeTLB_Size = n * PAGE_SIZE + +Then:: + + struct_size = n * PAGE_SIZE / PAGE_SIZE * sizeof(struct page) / PAGE_SIZE + = n * sizeof(struct page) / PAGE_SIZE + +We can use huge mapping at the pud/pmd level for the HugeTLB page. + +For the HugeTLB page of the pmd level mapping, then:: + + struct_size = n * sizeof(struct page) / PAGE_SIZE + = PAGE_SIZE / sizeof(pte_t) * sizeof(struct page) / PAGE_SIZE + = sizeof(struct page) / sizeof(pte_t) + = 64 / 8 + = 8 (pages) + +Where n is how many pte entries which one page can contains. So the value of +n is (PAGE_SIZE / sizeof(pte_t)). + +This optimization only supports 64-bit system, so the value of sizeof(pte_t) +is 8. And this optimization also applicable only when the size of struct page +is a power of two. In most cases, the size of struct page is 64 bytes (e.g. +x86-64 and arm64). So if we use pmd level mapping for a HugeTLB page, the +size of struct page structs of it is 8 page frames which size depends on the +size of the base page. + +For the HugeTLB page of the pud level mapping, then:: + + struct_size = PAGE_SIZE / sizeof(pmd_t) * struct_size(pmd) + = PAGE_SIZE / 8 * 8 (pages) + = PAGE_SIZE (pages) + +Where the struct_size(pmd) is the size of the struct page structs of a +HugeTLB page of the pmd level mapping. + +E.g.: A 2MB HugeTLB page on x86_64 consists in 8 page frames while 1GB +HugeTLB page consists in 4096. + +Next, we take the pmd level mapping of the HugeTLB page as an example to +show the internal implementation of this optimization. There are 8 pages +struct page structs associated with a HugeTLB page which is pmd mapped. + +Here is how things look before optimization:: + + HugeTLB struct pages(8 pages) page frame(8 pages) + +-----------+ ---virt_to_page---> +-----------+ mapping to +-----------+ + | | | 0 | -------------> | 0 | + | | +-----------+ +-----------+ + | | | 1 | -------------> | 1 | + | | +-----------+ +-----------+ + | | | 2 | -------------> | 2 | + | | +-----------+ +-----------+ + | | | 3 | -------------> | 3 | + | | +-----------+ +-----------+ + | | | 4 | -------------> | 4 | + | PMD | +-----------+ +-----------+ + | level | | 5 | -------------> | 5 | + | mapping | +-----------+ +-----------+ + | | | 6 | -------------> | 6 | + | | +-----------+ +-----------+ + | | | 7 | -------------> | 7 | + | | +-----------+ +-----------+ + | | + | | + | | + +-----------+ + +The value of page->compound_head is the same for all tail pages. The first +page of page structs (page 0) associated with the HugeTLB page contains the 4 +page structs necessary to describe the HugeTLB. The only use of the remaining +pages of page structs (page 1 to page 7) is to point to page->compound_head. +Therefore, we can remap pages 1 to 7 to page 0. Only 1 page of page structs +will be used for each HugeTLB page. This will allow us to free the remaining +7 pages to the buddy allocator. + +Here is how things look after remapping:: + + HugeTLB struct pages(8 pages) page frame(8 pages) + +-----------+ ---virt_to_page---> +-----------+ mapping to +-----------+ + | | | 0 | -------------> | 0 | + | | +-----------+ +-----------+ + | | | 1 | ---------------^ ^ ^ ^ ^ ^ ^ + | | +-----------+ | | | | | | + | | | 2 | -----------------+ | | | | | + | | +-----------+ | | | | | + | | | 3 | -------------------+ | | | | + | | +-----------+ | | | | + | | | 4 | ---------------------+ | | | + | PMD | +-----------+ | | | + | level | | 5 | -----------------------+ | | + | mapping | +-----------+ | | + | | | 6 | -------------------------+ | + | | +-----------+ | + | | | 7 | ---------------------------+ + | | +-----------+ + | | + | | + | | + +-----------+ + +When a HugeTLB is freed to the buddy system, we should allocate 7 pages for +vmemmap pages and restore the previous mapping relationship. + +For the HugeTLB page of the pud level mapping. It is similar to the former. +We also can use this approach to free (PAGE_SIZE - 1) vmemmap pages. + +Apart from the HugeTLB page of the pmd/pud level mapping, some architectures +(e.g. aarch64) provides a contiguous bit in the translation table entries +that hints to the MMU to indicate that it is one of a contiguous set of +entries that can be cached in a single TLB entry. + +The contiguous bit is used to increase the mapping size at the pmd and pte +(last) level. So this type of HugeTLB page can be optimized only when its +size of the struct page structs is greater than 1 page. + +Notice: The head vmemmap page is not freed to the buddy allocator and all +tail vmemmap pages are mapped to the head vmemmap page frame. So we can see +more than one struct page struct with PG_head (e.g. 8 per 2 MB HugeTLB page) +associated with each HugeTLB page. The compound_head() can handle this +correctly (more details refer to the comment above compound_head()). + +Device DAX +========== + +The device-dax interface uses the same tail deduplication technique explained +in the previous chapter, except when used with the vmemmap in +the device (altmap). + +The following page sizes are supported in DAX: PAGE_SIZE (4K on x86_64), +PMD_SIZE (2M on x86_64) and PUD_SIZE (1G on x86_64). + +The differences with HugeTLB are relatively minor. + +It only use 3 page structs for storing all information as opposed +to 4 on HugeTLB pages. + +There's no remapping of vmemmap given that device-dax memory is not part of +System RAM ranges initialized at boot. Thus the tail page deduplication +happens at a later stage when we populate the sections. HugeTLB reuses the +the head vmemmap page representing, whereas device-dax reuses the tail +vmemmap page. This results in only half of the savings compared to HugeTLB. + +Deduplicated tail pages are not mapped read-only. + +Here's how things look like on device-dax after the sections are populated:: + + +-----------+ ---virt_to_page---> +-----------+ mapping to +-----------+ + | | | 0 | -------------> | 0 | + | | +-----------+ +-----------+ + | | | 1 | -------------> | 1 | + | | +-----------+ +-----------+ + | | | 2 | ----------------^ ^ ^ ^ ^ ^ + | | +-----------+ | | | | | + | | | 3 | ------------------+ | | | | + | | +-----------+ | | | | + | | | 4 | --------------------+ | | | + | PMD | +-----------+ | | | + | level | | 5 | ----------------------+ | | + | mapping | +-----------+ | | + | | | 6 | ------------------------+ | + | | +-----------+ | + | | | 7 | --------------------------+ + | | +-----------+ + | | + | | + | | + +-----------+ |